서론AI 모델은 이제 대부분의 코딩 작업을 맡기고 리뷰와 검수까지 시킬 수 있을 만큼 좋아졌다. 주변 개발자분들께 여쭤보면 코드를 입력하는 시간보다 프롬프트를 입력하는 시간이 더 많고, 자동화 스크립트 대신 에이전트에 쓸 스킬을 만들고 있다고 할 만큼 개발 업무의 형태가 많이 변했다.AI가 코딩을 하고 리뷰까지 하는 방식으로 일하다 보니, 이전과 달라진 업무 흐름에 혼란스러워하는 사람도 많고 지금 하고 있는 일에 확신을 갖지 못하는 분들도 늘기 시작했다. 나 역시 과거와 많이 달라진 업무와 프로세스를 보며 이렇게 하는 게 맞는지 의문을 가지고, 때로는 비판적으로 바라보곤 한다.이전의 개발자과거의 개발은 전문가의 영역에 가까웠다. 의사나 파일럿 같은 전문직이라기보다는, 목수나 건축가처럼 고객이 원하는 요구..
3년 만에 다시, 스타트업3년 전, 나는 "그래도 또 스타트업에 갈 거냐"는 질문에 망설임 없이 "예스"라고 적으며 글을 맺었다. 그리고 정말로, 그때의 다짐대로 다시 스타트업에 들어와 개발자로 일하고 있다.그때의 나와 지금의 나는 무엇이 달라졌을까. 3년 전 써 둔 글을 다시 펼쳐 읽으며, 그동안 겪은 이야기와 조금은 달라진 마음가짐을 정리해보려 한다.정신없이 시작된 인수인계인원이 적은 스타트업에서 새로운 사람을 뽑는 경우는 대체로 둘 중 하나다. 기존 인력이 빠져나가 그 빈자리를 메워야 하거나, 사업이 커지면서 손이 더 필요해지거나. 나는 전자였다.전임 개발자가 건강 문제로 급하게 자리를 비우게 되면서 채용이 진행됐고, 마침 일자리를 찾고 있던 나에게 오퍼가 왔다. 양쪽 모두 급했던 만큼 절차도 빨랐..
잘못된 설계가 만드는 오차운영 환경에서 잘못된 설계 탓에 어긋난 데이터는 원인을 추적하기가 쉽지 않다. 실제 사용자가 서비스를 쓰고 여러 시스템이 맞물려 돌아가다 보니 버그를 재현하기 어렵고, 문제 자체도 불규칙하고 간헐적으로 나타나기 때문이다.그렇다면 이렇게 어긋난 데이터를 막는 것은 불가능할까? 그렇지 않다. 로그를 심어 사후에 추적하는 방법도 있지만, 더 근본적인 해결은 설계 단계에서부터 트랜잭션의 경계와 예외 발생 시 로직의 흐름을 명확히 정의하는 데서 출발한다.실제 주문 로직을 통해 알아보기@Transactionalpublic PaymentResponse requestPayment(Long memberId, Long orderId) { Order order = orderRepository...
트래픽이 별로 없는 서비스에서는 동시성 문제를 마주칠 일이 거의 없다. 그래서 몇 년을 개발하면서 한 번도 안 터뜨려본 사람도 많다. 나도 동시성 이슈를 해결한 경험이 많지는 않다. 하지만 트래픽이 적다고 안 터지는 건 아니다. 클라이언트의 더블 클릭, 네트워크 재시도, 비동기로 동작하는 컴포넌트. 이런 것만으로도 같은 요청이 거의 동시에 도착한다. 그 순간 데이터 정합성은 깨진다.그래서 결국 알아야 한다. 언젠가는 마주칠 문제이고 이런 설계 미스로 인해 서비스 신뢰도와 매출의 하락이 발생할 수 있기 때문이다.이 글에서는 가장 흔한 동시성 문제인 갱신 분실(lost update)을 재고 차감 시나리오로 재현하고, 이걸 막는 다섯 가지 방법을 비교해보려고 한다. Redis 분산락, DB 격리수준 + Un..