발자취

최근 개발을 하는 것에 대한 목적을 잃어버렸다는 생각이 많이 심하게 들었고, 이를 극복하기 위해 항해플러스에 등록을 진행했다. 이를 통해서 문제를 해결하는 능력과 좋은 개발자들과 많이 알게 되어 장기적으로 개발자로서 좋은 영향을 널리 퍼트리는 것이 목표이다.이를 실현하기 위해 개인적으로 하루에 30분이라도 개발에 대한 나의 생각을 정리하는 시간을 가지려고 한다. 일을 진행하더라도 회고가 없으면 나의 성장에 걸림돌이 되기 때문이다.항해플러스 과정을 무사히 마치고, 이를 기회로 삼아 장기적으로 도움이 되는 인사이트를 얻어낼 것이다.

최근 디커플링이 필요한 작업을 맡게 되었다. 이 때 보편적으로 사용한 AWS 서비스 중 SQS 를 사용하기로 했는데, 비슷한 서비스로 SNS 가 있는 것을 보았다. 그래서 SQS 와 SNS 의 차이점에 대해서 확실히 알고 가기로 했다. 서비스 사용 기반SQS 는 풀 기반이다. 수신자가 메시지를 직접 받아야 한다.SNS 는 푸시 기반이다. 관계 유형SQS 는 한개의 소비자만 가능하다.SNS 는 구독자가 많다.공통적으로 메시지 생성자는 다수가 가능하다.소비자SQS 는 SQS API 를 사용한다.SNS 는 다양한 목적지로 전송이 가능하다. 람다, SQS, 키테시스, HTTP, 문자메시지 등등...보존SQS 는 일정 기간 동안 보존이 가능하다. 해당 기간 내 메시지를 확인하지 않으면 삭제된다.SNS 는 메시지 ..

회사에서 MongoDB 를 구축할 필요가 생겼다. 원래 Atlas 를 사용해서 구축할 예정이였으나, 관리 포인트가 늘어난다는 점 때문에 직접 MongoDB 를 구축 하기로 했다. AWS 에서도 NOSQL 기반 DB 를 서비스하고 있었는데, DocumentDB 는 너무 비싸고 외부 접속이 안 되며 DynamoDB 는 사용 목적과 달라서 직접 구축하기로 했다. 사전 지식일단 나는 MongoDB 자체를 써 본 적이 없는 상황이라 MongoDB 및 NoSQL 에 대해서 간단히 정리가 필요했다.NoSQL 장점유연한 스키마를 제공하여 비정형 데이터에 적합하다.분산형 클러스터를 사용하여 유연하고, 확장성 있게 설계하기 쉽다. 이로 인해 신뢰도가 증가한다.NoSQL 단점DB 의 일관성이 부족하다.데이터의 중복으로 인해..

2025년에 쓰는 어딘가 이상한 연말 개발 회고록이다. 2024년은 참으로 다사다난 해 였던 것 같다. 올해 초부터 한번 복기를 해 보자. 올해 초에는 이전 직장의 재정 상황이 안 좋아져서 살면서 처름으로 정리해고를 당했다. 해고를 당하고 나서 한 2달 동안은 아무 생각이 없던 것 같다. 일단은 다시 백수가 된 몸이라서 몇 달은 좀 쉬고 싶었다. 다행히도 실업급여도 받을 수 있어서 백수인 상태임에도 불구하고 돈이 계속 들어와서, 심적으로 안정되기는 했다. 이 때 개인적인 개발도 종종 하면서 이래저래 심적 안정을 받을 수 있었다. 하지만 다시 회사를 다니기 위해서 이래저래 이력서도 많이 쓰고 면접도 보러 갔는데, 시장이 차갑다는 것을 잘 알수 있는 상태였다. 기술 스택이 맞는 곳도 별로 없었고, 실제로 채..

현재 사내 프로그램은 PM2를 사용하여 배포를 하고 있다. 이 때 PM2 로그를 로컬에서 트래킹 하는 것이 아닌, CloudWatch를 사용해서 인스턴스가 아닌 인스턴스 외부에 로그를 저장하고, 거기서 로그를 확인하는 인프라를 간단히 구축해 보았다. 전체적인 기획은 다음과 같다. NestJS 로그를 배포 환경에서는 JSON으로 출력하게 하기EC2 인스턴스에 Cloudwach Agent 설치CloudWatch 에서 로그를 잘 출력하는지 확인하기 해당 시스템 구축 이후 진행한 과정을 정리해 보았다.먼저 pm2 로그는 ~/.pm2/log 에 쌓이게 된다. 해당 폴더를 조회하면 app 이름을 가진 파일을 확인할 수 있다. 해당 로그 파일을 CloudWatch 에 지속적으로 전송시키면 될 것 같다.  여기서 더 ..

글을 작성하기 전에 먼저 기존 쿼리가 연산에 불리하게 작성되어 있었다는 점 (비즈니스 로직에서 사용하기 위한 이슈) 이 있었다는 점을 참고 바란다. 현재 회사에서 운영하는 서버에서 특정 쿼리 (유저의 구매 데이터의 요약본을 알려줌) 에서 상당히 느린 쿼리가 있다는 것을 알게 되었다. 서비스 특성상 해당 쿼리를 자주 호출할 일은 없지만, 평균 10초정도 걸리는 쿼리가 있다는 것 조차 문제가 있다고 생각하여 해당 쿼리를 확인해 보았다. SELECT DISTINCT "i".*FROM ( SELECT "department"."name" AS "target", "department"."id" AS "id" FROM "order_info_entity" "oi" IN..

현재 상황은 예전 계정인 A에 호스팅 되어 있는 설정들을 현재 계정인 B 계정으로 모두 이동하는 작업이 필요한 상태이다. 현재 생성된 레코드는 100개가 조금 넘는 상황으로, 수동으로 옮기기에는 문제가 있는 상황이다. 그래서 AWS의 document를 참고하여 호스팅 영역을 이전한 내용을 정리하려 한다. 다음의 문서를 참고했다.https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/hosted-zones-migrating.html 호스팅 영역을 다른 AWS 계정으로 이전 - Amazon Route 53새 호스팅 영역을 위한 이름 서버를 사용하도록 도메인 등록을 업데이트하지 않으면 Route 53가 계속 기존 호스팅 영역을 사용하여 도메인에 대한 ..

최근에 대량의 데이터 (4개의 칼럼, 200만개 가까이 되는 row)를 입력해야 할 일이 생겨서 NestJS 로직에서 데이터를 생성하는 중, Entity 생성 후 repository를 통해 데이터를 입력하는 방법은 상당히 속도가 느리다는 것을 알고 데이터 insert 속도를 찾기 위해 방법을 강구하던 중, bulk insert를 통해 속도를 올릴 수 있다는 것을 알게 되었다. 테스트를 위해서 간단히 환경을 만들어 보았다. AppService@Injectable()export class AppService { constructor( @InjectRepository(UserEntity) private usersRepository: Repository, ) {} async createUsers..

최근 NestJS 개발에 사용한 IDE를 vscode에서 Webstorm으로 바꾸면서 사용중인데, 만족감이 매우 높다. 메서드 분리, getter 및 setter 추가, 리팩토링 제안, import 자동 리팩토링 등의 다양한 기능을 사용하면서 역시 비싼 IDE(?)를 사용하는 것이 생산성에 좋다고 생각이 들었다. 이 때 vscode에서 어려움이 있던 디버깅 설정을 Webstorm에서도 해 보기로 했다. 먼저 NodeJS 환경에서 디버그를 할수 있도록 공식 문서를 확인해 보았다. https://www.jetbrains.com/help/webstorm/running-and-debugging-node-js.html#before_you_start Running and debugging Node.js | WebS..

사이드 프로젝트를 하던 중, 요금이 너무 많이 나오는 것 같아서 요금을 추적해 보니, IPv4에 대한 새로운 요금 정산 방식이 추가되어서 그렇다고 한다. https://aws.amazon.com/ko/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/ New – AWS Public IPv4 Address Charge + Public IP Insights | Amazon Web Services We are introducing a new charge for public IPv4 addresses. Effective February 1, 2024 there will be a charge of $0.005 per IP per hour for al..