덜어내고 나서야 보인 것들 - 도구 과잉 시대의 실패 회고

3분기부터 본격적으로 플랫폼 팀을 리드하면서 개발뿐만 아니라 디자인, 기획, 데이터까지 함께 살펴보게 되었다. 리더 미팅에서는 우리 팀이 어떤 성과를 내고 있는지, 서비스를 유지하기 위해 얼마나 비용을 쓰고 있는지 공유해야 했다. 배포 일정을 지키는 것에 더해 프로젝트에서 세운 가설을 어떻게 검증하고 있는지, 배포 이후 유저가 어떤 행동을 보이는지, 앱을 사용하다가 어디서 많이 이탈하는지도 알아야 했다.책임지는 범위가 넓어지면서 부담도 커졌다. 이런 내용을 제대로 파악하고 팀이 더 높은 수준으로 일하려면, 우선 필요한 정보를 볼 수 있는 환경부터 갖춰야겠다고 생각했다.그래서 기기의 고장률을 낮추기 위해 기기 관측 시스템을 만들었고, 기획자와 디자이너가 데이터를 직접 살펴볼 수 있도록 메타베이스를 도입했다..

• format_list_bulleted 커리어 · 일상/회고
• · 2026. 9. 20.

AI가 대신 해주는데 기술을 공부해야할까?

서론AI 모델은 이제 대부분의 코딩 작업을 맡기고 리뷰와 검수까지 시킬 수 있을 만큼 좋아졌다. 주변 개발자분들께 여쭤보면 코드를 입력하는 시간보다 프롬프트를 입력하는 시간이 더 많고, 자동화 스크립트 대신 에이전트에 쓸 스킬을 만들고 있다고 할 만큼 개발 업무의 형태가 많이 변했다.AI가 코딩을 하고 리뷰까지 하는 방식으로 일하다 보니, 이전과 달라진 업무 흐름에 혼란스러워하는 사람도 많고 지금 하고 있는 일에 확신을 갖지 못하는 분들도 늘기 시작했다. 나 역시 과거와 많이 달라진 업무와 프로세스를 보며 이렇게 하는 게 맞는지 의문을 가지고, 때로는 비판적으로 바라보곤 한다.이전의 개발자과거의 개발은 전문가의 영역에 가까웠다. 의사나 파일럿 같은 전문직이라기보다는, 목수나 건축가처럼 고객이 원하는 요구..

• format_list_bulleted 커리어 · 일상/회고
• · 2026. 8. 17.

MQTT로 기기를 제어하고 있지만, 사실 잘 몰랐습니다

들어가며지금 운영 중인 서비스에서 AWS IoT Core를 통해 MQTT로 기기를 제어하고 있다. 명령을 publish 하면 기기의 내판과 외판이 동작하고, 기기의 상태가 변경되면 서버가 받아서 반영한다. 외적으로는 잘 돌아가지만 문제는 왜 잘 돌아가는지 깊게 설명할 수 없었다는 것이다.QoS란 무엇인지, 기기가 오프라인일 때 보낸 명령은 어떻게 되는지, 연결이 끊긴 기기를 서버는 어떻게 알아채는지 잘 설명할 수 없었다. 장애가 나기 전에 이해해두자는 마음으로, MQTT의 내부 동작을 표준 스펙과 AWS IoT Core의 실제 구현을 오가며 정리해봤다.미리 말해두면, AWS IoT Core는 표준 MQTT 브로커가 아니다. 표준과 다르게 동작하는 지점이 꽤 많고, 그 차이를 제대로 이해하지 못하면 실제 ..

• format_list_bulleted CS/네트워크
• · 2026. 7. 19.

3년 만에 다시 돌아온 스타트업, 생존형 엔지니어링을 넘어

3년 만에 다시, 스타트업3년 전, 나는 "그래도 또 스타트업에 갈 거냐"는 질문에 망설임 없이 "예스"라고 적으며 글을 맺었다. 그리고 정말로, 그때의 다짐대로 다시 스타트업에 들어와 개발자로 일하고 있다.그때의 나와 지금의 나는 무엇이 달라졌을까. 3년 전 써 둔 글을 다시 펼쳐 읽으며, 그동안 겪은 이야기와 조금은 달라진 마음가짐을 정리해보려 한다.정신없이 시작된 인수인계인원이 적은 스타트업에서 새로운 사람을 뽑는 경우는 대체로 둘 중 하나다. 기존 인력이 빠져나가 그 빈자리를 메워야 하거나, 사업이 커지면서 손이 더 필요해지거나. 나는 전자였다.전임 개발자가 건강 문제로 급하게 자리를 비우게 되면서 채용이 진행됐고, 마침 일자리를 찾고 있던 나에게 오퍼가 왔다. 양쪽 모두 급했던 만큼 절차도 빨랐..

• format_list_bulleted 커리어 · 일상/이직 · 커리어
• · 2026. 6. 20.

사가패턴을 통해 데이터 정합성을 보장하기

잘못된 설계가 만드는 오차운영 환경에서 잘못된 설계 탓에 어긋난 데이터는 원인을 추적하기가 쉽지 않다. 실제 사용자가 서비스를 쓰고 여러 시스템이 맞물려 돌아가다 보니 버그를 재현하기 어렵고, 문제 자체도 불규칙하고 간헐적으로 나타나기 때문이다.그렇다면 이렇게 어긋난 데이터를 막는 것은 불가능할까? 그렇지 않다. 로그를 심어 사후에 추적하는 방법도 있지만, 더 근본적인 해결은 설계 단계에서부터 트랜잭션의 경계와 예외 발생 시 로직의 흐름을 명확히 정의하는 데서 출발한다.실제 주문 로직을 통해 알아보기@Transactionalpublic PaymentResponse requestPayment(Long memberId, Long orderId) { Order order = orderRepository...

• format_list_bulleted CS/설계 · 아키텍처
• · 2026. 6. 16.

백엔드에서 동시성 이슈를 제어하는 6가지 방법

트래픽이 별로 없는 서비스에서는 동시성 문제를 마주칠 일이 거의 없다. 그래서 몇 년을 개발하면서 한 번도 안 터뜨려본 사람도 많다. 나도 동시성 이슈를 해결한 경험이 많지는 않다. 하지만 트래픽이 적다고 안 터지는 건 아니다. 클라이언트의 더블 클릭, 네트워크 재시도, 비동기로 동작하는 컴포넌트. 이런 것만으로도 같은 요청이 거의 동시에 도착한다. 그 순간 데이터 정합성은 깨진다.그래서 결국 알아야 한다. 언젠가는 마주칠 문제이고 이런 설계 미스로 인해 서비스 신뢰도와 매출의 하락이 발생할 수 있기 때문이다.이 글에서는 가장 흔한 동시성 문제인 갱신 분실(lost update)을 재고 차감 시나리오로 재현하고, 이걸 막는 다섯 가지 방법을 비교해보려고 한다. Redis 분산락, DB 격리수준 + Un..

• format_list_bulleted CS/설계 · 아키텍처
• · 2026. 5. 31.