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.

인프라 공방전 2주차 IaC - 코드로 CI/CD 파이프라인을 구축해보자

배경모든 프로젝트에서 결과물은 코드로 남기면서, 왜 인프라는 손맛으로만 만들고 있었을까요?인프라 공방전 스터디를 진행하며 모든 과정을 코드와 문서로 꼼꼼히 기록하던 중, 유독 인프라 영역만 빈 페이지로 남아 있다는 사실을 깨달았습니다. AWS 콘솔에서 마우스로 뚝딱뚝딱 만든 리소스들은, 스터디가 끝나거나 계정이 삭제되면 함께 사라지는 휘발성 작품이었거든요."이번엔 다르게 해보자." 그렇게 미뤄왔던 Terraform을 꺼내 들었습니다. 인프라를 코드로 적어두면 언제든 똑같이 재현할 수 있고, 누구나 읽고 리뷰할 수 있으니까요. 마침 Jenkins 파이프라인 구축을 앞둔 시점이라, 이보다 더 좋은 실험 무대는 없어 보였습니다.테라폼이란?테라폼 공식 사이트에서는 아래와 같이 테라폼을 설명하고 있습니다. 요약하..

• format_list_bulleted devops/aws
• · 2026. 5. 7.

인프라 공방전 스터디 1주차 - VPC를 처음부터 구축해보기

인프라 공방전 스터디를 열게 된 이유?AI 기술 발전으로 개발 영역이 빠르게 대체되는 시대에, 개발자는 비즈니스 성장과 안정적인 시스템 구축이라는 두 마리 토끼를 모두 잡아야 합니다.그러기 위해서는 비즈니스에 적절한 시점에 적합한 기술을 도입하고 비즈니스의 변화를 염두해두고 디자인하는 사람이 되어야 되는데 이를 하기 위해서는 경험과 지식이 필요한데 안정적인 서비스 운영은 직접 경험을 통해 배울 수 있기 때문에 이 스터디를 만들게 되었습니다. SSH 없이 EC2 접속하기 — AWS SSM 터널링 완전 정복이 글은 실제 세팅 과정에서 마주친 에러들을 하나씩 해결하며 작성한 실전 경험 기반의 글입니다. Private Subnet EC2에 SSM으로 접속하는 전 과정을 정리해보았습니다.왜 SSM인가?전통적인 S..

• format_list_bulleted devops/aws
• · 2026. 4. 18.