삶을 개발하는 Developer

2주간의 야근.. 그리고 여차저차한 마무리 약속이 있는 금요일(성시경 콘서트)을 제외하고는 4일은 연장 야근한 주간이었다. 9-10pm 퇴근 집에 오면, 느긋하게 저녁을 먹고, 일기를 쓰고, 보고 싶었던 영상을 보는 등의 저녁이 있는 삶을 즐길 여유도 없이 골아떨어져야 했다. 아마도 이렇게까지 야근을 하게된 여러 이유들이 있을 것. 1) 아직 확정되지 않은 기획들2) 개발 시점이 되서야 혹은 TC 중에 스물 스물 수면 위로 올라오는 미확정 안건들3) 자잘하게 잠수함 패치되는 디자인들 4) 서비스 특성 상(결제 도메인), 다른 팀의 의존적인 부분들이 많다보니 테스트가 쉽지 않은 것도.. 5) 확정되지 않은 부분들에 대한 논의를 이어가느라 개발할 시간이 부족해지는 것도 덤. 좀 더 나은 디자인에 대한 고민보..

일정이 너무 촉박해 놓치는 것들 최근에 일정이 빠듯한 프로젝트에 중간에 투입되어 바쁘게 개발 중에 있다. (이번주엔 야근을 3번 정도 했다..)바쁘게 개발하다보니 지켜왔던 것들을 조금 놓치게 되는 것들 그리고 어떻게 개선하면 좋을지 혹은 개선했는지를 정리해 보려고 한다.  1. 코드 리뷰일정이 바쁘다 보니 각 기능들이 특정 브랜치에서 연속적으로 작업된게 아닌 부모 브랜치에서 병렬적으로 작업되었다. 이렇게 했을 때, 보다 상위 기능에 추가 작업이 이뤄졌을 때, 직접접인 영향도가 하위 브랜치엔 없다는 장점이 있을 수 있는데, 병렬적으로 작업되다보니 서로의 개발 내용을 몰라 중복 코드가 왕왕 생긴 점각 PR 에서 개발된 기능들이 꽤나 의존적이었던 관계로 병합 과정 및 기능 재점검을 위한 통합 테스트가 진행되어..

보호되어 있는 글입니다.

상품  판매 시스템 요구사항1. 초당 수천개의 요청을 감당할 수 있는 시스템을 구축해야 합니다.2. 계정 별로 구매 가능한 상품 수 제한이 있습니다. 3. 재고 관리가 엄격하게 되어야 합니다. 1. 사용자 별 구매 수량 관리사용자 식별 값으로 분산락을 걸어 동일 사용자의 상품 구매 작업 동시에 처리되지 않도록 한다. 또한, 요청 마다 구매 수량 계산에 의해 트랜잭션 시간의 증가로 부하가 발생할 수 있으니사용자의 구매 수량을 Redis 로 관리하도록 해 총 구매 수량 계산 연산이 매번 수행하지 않도록 한다.2. 상품 재고 관리상품의 판매 유무 조회 후, 사용처리를 진행할 때, 해당 상품을 동시에 사용처리하는 요청이 많을 경우, 동시성 문제가 발생할 수 있다. 상품은 하나이나, 모든 요청이 구매 가능하다고 ..

결제 도메인의 추상화 보존기 - 비효율적 연동 구조에서의 교훈: 소통 비용과 인터페이스 개선 경험  결제 서버는 여러 서비스들이 연동되는 플랫폼이다 보니 당연하게도 어떤 설계를 디자인할 때 추상화에 많은 신경을 쓰게된다. 다만, 이번에 진행하고 있는 프로젝트에서 각 서비스들의 리소스가 부족하다보니 특정 데이터를 전달받을 때, 각 서비스에서 이미 사용하고 있던 API 를 전달받게 되었다. 우리가 원하는 타입 A로 전달받지 않으니 서비스 별 서로 다른 응답값들을 A 타입으로 조합 및 가공해야하는 추가 공수가 발생했고, 이는 하기 2가지의 문제가 있었다.  결제 도메인에서 불필요한 서비스 도메인 지식을 알아야 한다는 점서비스 종속 코드 증가서비스 지식을 알기 위한 상호간 소통 비용이 증가하는 점 모든 응답 케..

무리하면, 업무에 지장이 가니깐 무리하면 안 된다는 생각을 달고 살았다. 너무 무리하지 말자. 오늘은 이정도 했으니깐, 쉬어야 내일 컨디션에 지장이 없다.  아마 한 두번의 경험이 그렇게 믿게 만들었으리라.  그러다 이번에 동생과 한계에 대해 이야기하게 되었는데, 그간의 나의 생활을 돌이켜 보게 되었다.  누나, 우리는 안정적인 삶에 길들여져서 이 안정적인 삶을 깨부술 도전을 하지 못해. 왜냐면, 굳이 깨수부지 않더라도 행복한 삶을 살아와서 위험을 짊어질 필요성을 못 찾는 거지.그래서 누나도 그렇겠지만, 우리가 한계를 넘어설 기회가 많지 않았던 거야. 그동안 항상 너무 무리하지 않는 선에서 적당히 머든 꾸준히 할 수 있을 정도만 했다. 러닝도 항상 같은 속도로 적당히 숨이 찰 정도만 했고, 일과 후, 업..

또 한번의. 성장의 기로에 서 있다고 느껴진다. 이번에 팀장님의 안식 기간 동안 대행직을 수행해야 한다. 팀장님이 하고계셨던 다양한 업무의 팔로업을 해야하기 때문에 한 두달 전부터 미리 그런 다양한 업무들을(팀원들이 진행하고 있는 내용들, 그 외 도메인 관련 대외적인 내용들) 정리하기 시작했다. 그러다 한 일주일정도 예행연습을 할 기회가 있었다. 그 기간동안 나 나름 최선을 다했디. 그간 정리해둔 컨텍스트를 토데로 팀원들이 겪은 문제에 해결책을 제시해 주도록 노력했고, 마땅한 근거를 제시하여 불필요한 작업에는 리소스를 쏟게 하지 않도록 했다. 하지만, 문제는 일주일간의 예행 연습을 마친 뒤에 나타났다. 평소 내 루틴에 약간의 무리를 더했더니 탈이 났고, 증상들 중 하나는 잘해냈다는 뿌듯함과 더불어 급속도..

기력과 의욕은 충분히 쉬었다는 만족감 으로부터 회복된다. 그간 정립해온 나만의 방법이 있기는 하나 (충분한 수면, 회고 등의 생각 정리)같은 패턴속에서도 더 큰 만족감을 얻고자 하는 주간이 있는 것 같다. (지나친 보상 심리의 발동)아마, 다른 때보다 더 많은 에너지를 쏟은 주이지 않을까한다. 이때는 복잡한 생각들을 완전히 off 하고 싶다는 마음이 자연스레 쉽고 편한 방향으로(도파민을 쫓는 행위 등) 풀릴 때가 있다. 평상시에는 그런 행동들의 제어가 보다 쉽기 때문에 괜찮지만,이번 주와 같이 지나친 보상 심리가 발동할 때는 제어가 쉽지 않을 수 있다. 또, 그런 행위의 결과는 주말 컨디션에 영향이 있다. 자연스레 그렇게 되는 이유가 쉽고 편한 방법이어서 이기도 했겠지만, 그것말고 다른 방법을 찾지 못해..

결제 키가 중복해서 저장되는 원인 분석하면서 느낀점분석과정에서 여러 방법들을 활용합니다.Loki(로그), 묶혀있던 로그 테이블, ...요청 별 로깅의 중요성실제로 그런 값을 받았는지, 내부적으로 그렇게 처리한 것인지 확인에 용이했음요청 데이터와 적재된 데이터들 간의 관계를 따져보면서 이상 현상들을 확인함결제 실패 시, 결제 재시도마지막으로 재시도된 데이터만 관리됨.동일 pgRequestId 로 재요청결론: 실제로 서버로의 요청/응답 이력들이 원인을 분석하는데 도움이 많이 됐다.그간 불필요하다고 생각했던 로그 테이블의 뜻밖의 활용socar-payment socar-pg 간 연결고리가 pg_request_id 이다.socar-pg 에서 중복해서 결제 요청된 사실 발견 (다행히 중복 결제 요청해도 결제 실패..

SQS 적용 과정에서 아래와 같은 중복 수신 상황을 다룬 과정을 소개하려고 한다. 아래와 같이 동일한 바디(Message Body)를 가진 메세지를 중복하여 수신할 수 있는 상황이 존재한다. Source Queue 에서 처리 완료되지 못한 메세지를 MaxReceiveCount 만큼 재시도한다. 메세지 처리 불가 상태로 추정되어 DLQ 로 이동된 이후에 재시도된다. 메세지가 Visibility Timeout (가시성 타임아웃) 내에 정상적으로 처리되지 못하여 재시도되는 상황은 다음과 같다. 메세지 처리시간이 Visibility Timeout 을 초과할 경우 메세지 처리 중, 예외가 발생했을 경우 재시도 상황 1 설명에 앞서, Visibility Timeout 이 무엇이고, 어떻게 동작하는 것이며, Visi..