개요25년 3월 4일, 백엔드 개발자로서 근무하며 배운 내용들을 되짚어볼겸. 기획부터 디자인, 개발까지 주체적으로 누군가에게 도움이 될 수 있는 서비스를 개발해보고 싶은 생각에 'realstatelab.com'을 출시하게 되었습니다. 아직 개발 초기라서 그런지 다소 엉성한 부분이 있어 다양한 시행착오가 있었는데, 그중에 가장 인상깊었던 사례들을 틈틈이 공유해보고자 합니다. 이번 게시글에서는 Http 로그를 남기는 과정에서 알게된 문제 상황과 그 문제를 해결한 과정을 소개하려고 합니다. HTTP 로그를 남긴 이유?처음에는 단순히 사용자의 행동 패턴을 분석하여, 사용자 맞춤 추천 매물 데이터를 제공하는 기능 개발에 필요한 자료로서 로그를 남기기로 했습니다. 작은 규모의 서비스이기에 별도의 로깅 서비스를 사용..

최근, 컴포트 존에 들어와서 익숙한데로 업무를 진행하려고 하는 경향을 갖게 된 것 같다.현재 회사에서는 올바른 성장 롤모델을 보여줄 사수나 시니어는 없는 상황이라, 지금처럼 업무만 진행한다면, 좋은 개발자가 되기는 어려울 것 같다는 생각이 들었다. 현재, 개발에서는 도메인 주도 개발이 유행하고 실제로 많은 회사들이 이 DDD를 우대사항으로 내거는 회사들이 많은데, 습관적으로 개발을 해왔던 나로서는 왜 DDD가 유행이고 중요한지 전혀 알길이 없었다. 그래서, 이번에 블로그 글을 정리하여 습관적으로 작성한 코드안에 녹아있는 도메인과 아키텍처의 내용을 정리하고, 앞으로의 학습 방향을 확고히 하고자 한다.누구나 잘 알면서 잘 모르는 도메인혹시 '코끼리와 시각장애인'이라는 이야기를 알고 있는가?이야기를 대략 요약..

개요 현재 Payment-lab에서 가장 큰 고민은 결제 승인 데이터의 손실을 최소화하는 것입니다. payment-lab에서는 사용자의 결제 승인 데이터의 정합성을 최대한 맞추기 위해, 무조건 PG api의 결제 승인 요청이 성공한 다음에 해당 로그를 DB에 기록하는 방식을 채택하고 있습니다. CA(Consistency, Availablilty)를 최대한 보장하기 위해 결제 승인 프로세스는 동기 방식으로 진행하기에 실제로 결제가 수행되는 시간이 지연될 수 있습니다. 결제 알림의 경우, 사실 결제 승인이 실제로 이루어지기 이전 시점에 수행한다면 사용자의 편의성을 침해하는 경우를 방지할 수 있을 것입니다. PG사의 결제 서비스 자체가 실패하는 경우는 드물고, MySQL과 같은 관계형 데이터베이스는 일관성과 ..

업무수행을 위해 ncp에 서버를 배포하여 도메인을 지정하고, ssl을 적용해야할 일이 생겼습니다. 단순 블로깅으로도 충분히 진행이 가능하지만, 이렇게 업무를 진행하면 금방 잊어먹을 수 있으므로 글로 정리하여 되새김질을 해볼까 합니다. 도메인 사전적 의미로 영역이지만, 사실 이 도메인이라는 단어는 종사하는 직종에 따라 매우 달라집니다. 해당 도메인에 대한 내용을 다루는 글은 아니므로 자세한 설명은 생략하겠습니다. 여기서 도메인은 '서비스 제공자의 영역'입니다. 서비스의 구조에 따라 이 영역을 이루는 서버는 단 하나일수도 있고, 여러개일수도 있습니다. 일반적으로 사용자는 DNS라는 서비스를 통해 지정된 웹 url을 통해 접근합니다. SSL(Secure Sockets Layer) pki 기반의 보안 소켓 계층..

이 게시글은 payment-lab이라고 하는 결제모듈 연동 사이드프로젝트를 진행하던 중 발생한 기술적 이슈를 해결하기 위해 정리하는 글입니다. 스프링 프레임워크에는 로깅을 직관적으로 사용하도록 도와주는 Log 관련 라이브러리들이 있습니다. 구체적으로는 log4j, logback 등을 사용하지만 스프링에서는 ‘slf4j’ 로그 통합 인터페이스를 제공하는 라이브러리를 통해 로깅을 합니다. payment-lab 에서는 로그를 단순히 애플리케이션의 동작 이력 및 디버깅 참고용으로 기록하는 것을 넘어서, 결제 정산 및 백업 그리고 복구를 수행하는데 활용됩니다. 그래서 처음에는 logback 설정을 통해 별도의 로거를 생성하여 결제 이력을 기록했습니다. logback-spring.xml logs/applicatio..

이 게시글은 payment-lab이라고 하는 결제모듈 연동 사이드프로젝트를 진행하던 중 발생한 기술적 이슈를 해결하기 위해 정리하는 글입니다. 결제 모듈을 개발하던 중 한가지 고민에 빠졌습니다.. 바로 사용자가 실수로 중복 결제(일명 따닥이)를 하게될 경우 어떻게 대비할지에 대한 고민이죠. 현재 진행하는 프로젝트는 토스페이먼츠로 결제 연동을 수행하고 있습니다. 토스페이먼츠의 경우 이러한 중복 결제 혹은 취소를 방지하기 위해 멱등키를 제공하고 있습니다. 이러한 멱등키를 적용하는 것은 너무나도 당연합니다. 그러나 그 멱등키를 어떻게 생성해야할까요? 만약 그냥 결제 요청마다 무작위의 uuid로 적용한다면 무슨일이 일어날까요? 사실상 멱등키를 적용하나마나일겁니다. 어차피 결제 요청 한번 할때마다 유일한 멱등키를..