ioh's Development

"CDC가 좋다"는 말은 많이 들었다. 하지만 언제 전환해야 하는가? "처리량이 부족할 때"라는 답은 너무 모호하다. 성능 테스트에서 측정한 135건/초가 그 기준선이 되었다.Polling과 CDC — 같은 문제, 다른 접근둘 다 Outbox 테이블의 이벤트를 Kafka로 전달하는 방법이다.Polling (현재 구현)애플리케이션 → SELECT ... FOR UPDATE SKIP LOCKED → Kafka send → markPublished애플리케이션이 주기적으로 DB를 조회하여 이벤트를 가져간다. 간단하고 인프라 추가 없이 구현 가능.CDC (Change Data Capture)DB binlog → Debezium Connector → Kafka → (Outbox 변환)DB의 변경 로그(binlog/..

SELECT ... FOR UPDATE는 대부분 알고 있다. 하지만 SKIP LOCKED를 아는 개발자는 드물다. Outbox Relay에서 멀티 인스턴스 중복 발행을 방지하는 핵심이 바로 이 2단어다.문제: 같은 이벤트를 두 인스턴스가 동시에 발행한다Outbox Relay는 outbox_event 테이블을 폴링하여 Kafka에 발행한다. 인스턴스가 1개면 문제 없다. 하지만 2개 이상이면:인스턴스 A: SELECT * FROM outbox_event WHERE status = 'PENDING' LIMIT 500인스턴스 B: SELECT * FROM outbox_event WHERE status = 'PENDING' LIMIT 500→ 같은 500건을 조회! → 같은 이벤트를 Kafka에 두 번 발행!F..

비관적 락으로 선착순 쿠폰을 구현했다가, Kafka 파티션 순차 처리로 전환했다. 락이 없는데 어떻게 동시성을 보장하는가? 파티션 내부에서 실제로 벌어지는 일을 추적한다.원래 구현: 비관적 락@Transactionalpublic void issue(Long templateId, Long userId) { CouponTemplate template = couponTemplateRepository .findByIdForUpdate(templateId); // SELECT ... FOR UPDATE if (template.getRemainingQuantity() 100명이 동시에 요청하면:99명은 FOR UPDATE에서 대기 (행 잠금)1명씩 순차적으로 잔여 수량 확인 → 발급 → 락..

"멱등성 체크에 왜 Redis가 아니라 DB를 쓰나요?" 이 질문에 답하려면 10.9ms의 의미와, Redis SET NX가 숨기고 있는 함정을 알아야 한다.왜 멱등성이 필요한가Kafka Consumer는 at-least-once 전달을 기본으로 한다. 네트워크 장애, 리밸런싱, Consumer 재시작 시 같은 메시지를 두 번 이상 받을 수 있다.Broker → Consumer: 메시지 전달Consumer: 처리 완료, ACK 전송 시도네트워크 끊김: ACK 미도달Broker: "ACK 안 왔네, 다시 보내자"Consumer: 같은 메시지를 또 받음멱등성이 없으면:좋아요 수가 이중으로 증가 (비멱등 연산)쿠폰이 이중으로 발급포인트가 이중으로 적립현재 구현: DB event_handled 테이블@Trans..

Outbox Relay에서 Kafka 발행을 비동기로 바꿨더니 markPublished()가 DB에 반영되지 않았다. 별도 랩 프로젝트에서 발견한 이 버그가 동기 .get() 전환의 결정적 근거가 됐다.발단: 비동기가 당연히 더 빠르니까Outbox Relay의 Phase 2는 Kafka에 이벤트를 발행한다. 처음에는 비동기 방식으로 구현했다:kafkaTemplate.send(producerRecord).whenComplete((result, ex) -> { if (ex == null) { event.markPublished(); // 상태 변경 metrics.recordPublishSuccess(); } else { event.markFailed..

교과서대로 했다. "TX 커밋 후 이벤트를 발행하라." 그래서 AFTER_COMMIT에서 Outbox를 저장했다. 그런데 실행되지 않았다. 왜?배경: Outbox Pattern의 핵심 요구사항Outbox Pattern의 전제는 단순하다:비즈니스 로직 + Outbox INSERT → 같은 TX → 원자적DB 커밋이 성공하면 Outbox에도 이벤트가 있고, 실패하면 둘 다 없다. 이 원자성이 Dual Write Problem을 해결하는 핵심이다.그런데 이벤트를 "언제" 저장하느냐에 따라 이 원자성이 깨진다.첫 번째 시도: AFTER_COMMIT에서 Outbox 저장Spring의 @TransactionalEventListener는 TX 생명주기에 바인딩되는 이벤트 리스너다.@TransactionalEventL..

"멱등성 체크에 왜 Redis가 아니라 DB를 쓰나요?" 이 질문에 답하려면 10.9ms의 의미와, Redis SET NX가 숨기고 있는 함정을 알아야 한다.왜 멱등성이 필요한가Kafka Consumer는 at-least-once 전달을 기본으로 한다. 네트워크 장애, 리밸런싱, Consumer 재시작 시 같은 메시지를 두 번 이상 받을 수 있다.Broker → Consumer: 메시지 전달Consumer: 처리 완료, ACK 전송 시도네트워크 끊김: ACK 미도달Broker: "ACK 안 왔네, 다시 보내자"Consumer: 같은 메시지를 또 받음멱등성이 없으면:좋아요 수가 이중으로 증가 (비멱등 연산)쿠폰이 이중으로 발급포인트가 이중으로 적립현재 구현: DB event_handled 테이블@Trans..

Kafka Consumer 안에서 @Transactional 메서드를 호출했는데, 트랜잭션이 안 걸렸다. 원인은 Spring AOP의 가장 유명한 함정 — self-invocation이었다.발단: 쿠폰 발급은 됐는데 event_handled가 안 남았다선착순 쿠폰 Consumer를 테스트하던 중 이상한 현상을 발견했다:쿠폰은 정상 발급됨하지만 event_handled 테이블에 기록이 남지 않음같은 이벤트가 다시 오면 중복 발급@Transactional로 감싸서 쿠폰 발급 + event_handled 저장을 원자적으로 처리했는데, 왜 event_handled만 빠졌는가?원인: self-invocation — 같은 클래스 내부 호출은 프록시를 우회한다문제가 된 코드 (리팩토링 전)@Componentpubli..

Outbox Relay 최적화: 10건/초에서 155건/초까지TL;DROutbox Relay의 초기 구현은 10건/초였다. PROCESSING 상태 추가 + FOR UPDATE SKIP LOCKED + parallelStream으로 155건/초까지 개선했다. 부하 테스트로 병목이 Phase 2(Kafka 동기 발행)임을 확인했고, 5분 PROCESSING 복구 threshold가 충분히 안전한 것을 수치로 증명했다.1. 초기 구현의 한계 — 왜 10건/초인가[이전 글](커밋 후 발행 vs 발행 후 커밋)에서 Outbox Pattern을 "왜" 선택했는지 다뤘다.이 글은 그 다음 질문에 답한다. Outbox를 선택했으면, 처리량은 어떻게 끌어올리는가?초기 구현은 단순했다.5초 간격 폴링 × 50건 배치 =..

트래픽이 몰려도 데이터를 잃지 않는 Kafka 파이프라인 설계TL;DR100명이 동시에 선착순 쿠폰을 요청하면, 10장만 정확히 발급되어야 한다. 11장도 안 되고, 9장도 안 된다. 이 글에서는 이커머스 프로젝트에서 Kafka 파이프라인을 설계하고 구현하면서 마주한 실제 문제들 — Topic 설계, Producer/Consumer 전략, 장애 시나리오와 방어 메커니즘 — 을 다룬다. 이론이 아니라 직접 깨지고 고친 경험이다.1. 5개 토픽, 각각 다른 이유로 존재한다토픽은 "메시지를 담는 곳"이 아니라 "도메인 경계"다토픽을 하나로 합치고 eventType 헤더로 구분하면 안 되나? 기술적으로는 가능하다. 하지만 Consumer Group이 토픽 단위로 묶이기 때문에, 하나의 토픽에 서로 다른 도메인의..

커밋 후 발행 vs 발행 후 커밋: 왜 둘 다 충분하지 않은가TL;DRDB에 쓰고, Kafka에 쓴다. 이 두 쓰기를 원자적으로 묶을 수 없다면? 하나만 쓰고 나머지는 비동기로 전파한다. Transactional Outbox Pattern은 이벤트를 DB에 함께 저장하여 단일 트랜잭션으로 원자성을 확보하고, Relay가 비동기로 Kafka에 발행하는 구조다. 이 글에서는 "커밋 후 발행"과 "발행 후 커밋"이 왜 근본적으로 불완전한지 분석하고, Outbox Pattern으로 해결한 실제 구현과 부하 테스트 결과를 공유한다.1. 이벤트 발행, 언제 해야 하는가?주문이 생성되면 재고를 감소시켜야 한다. Event-Driven Architecture(EDA)에서는 주문 서비스가 재고 서비스를 직접 호출하는 대..

이번 주에 새로 배운 것"모른다"를 설계에 담는 법이번 주 루퍼스 과제는 PG 연동이었다. 결제 요청을 보내고 응답이 안 오면 어떻게 할 것인가. 처음엔 단순하게 생각했다. 타임아웃이 나면 실패로 처리하고 롤백하면 되지 않나.틀렸다. 타임아웃은 실패가 아니다. "모른다"는 뜻이다. PG가 요청을 아예 못 받았을 수도 있고, 받아서 승인까지 했는데 응답만 유실됐을 수도 있다. 이 세 가지 가능성을 구분할 수 없는 상태에서 "실패"로 단정하면, 사용자 카드에서는 돈이 빠졌는데 주문은 취소되는 사고가 난다. 반대로 "성공"으로 단정하면, 돈을 안 받았는데 상품이 나간다.결국 UNKNOWN이라는 상태를 만들었다. "아직 모른다"를 명시적으로 표현하는 상태다. 모르면 행동하지 않고, 알아낸 다음에 행동한다. 이 ..

들어가며PG사 결제 API를 연동하면서 가장 먼저 마주친 질문은 이거였다."결제 요청을 보냈는데 응답이 안 오면, 실패로 처리하면 되지 않나?"직관적으로 맞는 것 같았다. 타임아웃이 나면 실패인 거고, 실패면 롤백하면 된다고 생각했다.틀렸다.타임아웃은 실패가 아니다. "모른다"는 뜻이다. 이 한 줄을 이해하는 데 설계 전체가 바뀌었고, 그 과정에서 내가 세운 원칙이 하나 있다.응답을 받았으면 결과를 안다. 못 받았으면 모른다. 모르면 행동하지 말고, 알아낸 다음에 행동한다.이 글은 이 원칙을 발견하기까지의 과정이다.1. 왜 타임아웃이 실패가 아닌가DB와 PG는 근본적으로 다르다. DB 트랜잭션은 하나의 프로세스 안에서 ACID를 보장하지만, PG 연동은 네트워크를 사이에 둔 분산 트랜잭션(distribu..

"주니어 백엔드 개발자가 반드시 알아야 할 실무 지식" 2장·3장을 읽고, CS 개념과 실무 경험을 엮어 정리한 글입니다.들어가며서비스가 느려지면 가장 먼저 떠오르는 생각은 "코드를 최적화해야 하나?"이다. for문을 줄이고, 알고리즘을 개선하고, 불필요한 연산을 없애는 것. 물론 중요하다. 하지만 실무에서 마주치는 대부분의 성능 문제는 코드의 계산 복잡도가 아니라 I/O 경계에서 발생한다.이 책의 2장과 3장은 그 경계를 정확히 짚는다. DB 연동, 외부 API 호출, 커넥션 풀 설정, 캐시 전략, 인덱스 설계. 이것들이 실제 서비스 응답 시간의 70~90%를 지배한다는 사실을 데이터로 보여준다.이 글에서는 책에서 다루는 핵심 키워드들을 CS 관점에서 깊이 있게 풀어보고, 내가 실무에서 겪었던 경험을 ..

인덱스를 만들었는데 왜 안 타죠? — 옵티마이저의 비용 계산을 파헤치다인덱스를 걸었는데 풀스캔이 나왔다프로젝트에서 Soft Delete를 쓰고 있었다. 상품 조회 쿼리에 WHERE deleted_at IS NULL 조건이 붙는데, deleted_at에 인덱스를 걸어봤자 EXPLAIN을 찍으면 type: ALL — 풀 테이블 스캔이 나온다.인덱스가 분명히 있는데 왜 안 쓸까? "선택도가 낮아서"라는 답은 알고 있었지만, 왜 선택도가 낮으면 풀스캔이 더 나은 건지 — 그 물리적인 이유를 몰랐다.이번에 옵티마이저의 비용 계산 구조를 파면서, 그 "왜"를 찾았다.옵티마이저 — SQL의 "어떻게"를 결정하는 두뇌SQL을 던지면 MySQL이 바로 실행하는 게 아니다. 3단계를 거친다.SQL 입력 → [1] Par..

이번 주에 새로 배운 것"왜?"라는 질문이 깊이를 만든다이번 주는 유독 "왜?"를 많이 물었다. 복합 인덱스를 공부하다가 "카디널리티가 높은 컬럼을 앞에 놓으라"는 규칙을 만났다. 예전 같았으면 그대로 외웠을 것이다. 그런데 이번엔 "왜?"를 던져봤다. 왜 카디널리티가 높으면 앞이어야 하지? B+Tree에서 실제로 어떤 차이가 생기지? 등호 조건과 범위 조건이 섞이면 어떻게 되지? 파고 들어가니까 답이 달라졌다. 카디널리티보다 등호 조건이 먼저라는 게 진짜 규칙이었다. 카디널리티가 아무리 높아도 범위 조건이면 그 뒤 컬럼은 인덱스를 못 탄다. B+Tree의 리프 노드가 정렬되는 방식을 이해하고 나니, "왜 그런지"가 보였다. 외운 규칙이 아니라 원리에서 나온 판단이 되니까, 새로운 상황을 만나도 스스로 ..

redisTemplate.opsForValue().set(key, json, ttl) — 이 한 줄 뒤에 뭐가 있는지 모르고 쓰면, 캐시가 서비스를 살리는 게 아니라 죽인다 TL;DR이커머스 프로젝트에 Cache-Aside 패턴을 직접 구현했다. @Cacheable 대신 RedisTemplate으로 캐시 흐름을 직접 제어했는데, 구현하면서 get() 한 줄이 Master/Replica 라우팅을 거친다는 것, 커밋 전에 캐시를 삭제하면 stale 데이터가 영구화된다는 것, 같은 캐시 삭제인데 트랜잭션 관리 방식에 따라 무효화 전략이 달라야 한다는 것을 알게 됐다. RedisTemplate의 동작 흐름을 코드 레벨로 추적하고 나서야, 왜 이런 처리를 해줘야 하는지 납득이 됐다."그냥 쓰면 되지, 왜 까봐?"..

복합 인덱스 컬럼 순서의 진짜 1순위는 카디널리티가 아니었다 TL;DR복합 인덱스를 설계할 때 "카디널리티 높은 컬럼을 앞에"라는 규칙을 따랐다. 근데 EXPLAIN을 찍어보니 인덱스를 걸었는데도 filesort가 사라지지 않았다. 원인을 파보니 컬럼 순서의 진짜 1순위는 카디널리티가 아니라 조건 유형(등호 vs 범위)이었다. B+Tree 리프 노드의 정렬 원리를 이해하고 나서야 인덱스 설계가 풀렸다."카디널리티 높은 컬럼을 앞에" 이 규칙을 의심 없이 따랐다상품 목록 API에 복합 인덱스를 걸어야 했다. products 테이블 약 20만 건, 자주 쓰이는 WHERE 조건은 status와 brand_id.brand_id: 카디널리티 500 (고유 값 500개)status: 카디널리티 3 (ACTI..

afterCommit DELETE면 충분하지 않나? — Cache-Aside 레이스 컨디션을 발견하고, 근본 원인을 찾기까지 TL;DRCache-Aside + afterCommit DELETE면 캐시 무효화는 끝이라고 생각했습니다. 그런데 "DB 읽기와 캐시 SET 사이의 시간 간격"이라는 구조적 허점을 발견했고, 처음에는 캐시 레이어에서 사후 패치하려 했습니다. 한 발 물러서 보니, 이 문제의 근본 원인은 캐시가 아니라 DB 쓰기 프로세스의 동시성 제어였습니다. 쓰기 쪽을 비관적 락과 원자적 UPDATE로 잠근 뒤에는, afterCommit DELETE + TTL 안전망만으로 충분했습니다.캐시가 필요한 이유: 속도가 아니라 DB 보호인덱스 최적화 + Cursor 페이지네이션까지 적용하고 나니, 상품 목..

이커머스 프로젝트에서 재고 차감에 비관적 락을 적용하고 나서, 하나 궁금한 게 생겼다.배타락을 걸면 다른 트랜잭션이 이 데이터를 아예 못 읽나? 못 읽을 줄 알았다. 근데 읽힌다. 일반 SELECT는 배타락을 무시하고 데이터를 그냥 가져온다.공식 문서를 찾아봤는데 이렇게 적혀있다.Consistent reads ignore any locks set on the recordsthat exist in the read view.Consistent read는 읽기 뷰에 존재하는 레코드에 설정된 모든 잠금을 무시합니다.출처: MySQL 8.0 - InnoDB Locking ReadsConsistent read is the default mode in which InnoDB processesSELECT stateme..

혹시 이런 상황, 생각해본 적 있으신가요?분산락을 공부하면 보통 이런 흐름으로 배운다."Redis에 Lock을 잡고 → 작업하고 → Lock을 해제한다"여기까지는 별로 어렵지 않다. 근데 공부하다가 문득 이런 생각이 들었다."Lock에 TTL이 5초인데... 내 트랜잭션이 6초 걸리면 어떻게 되지?" 처음엔 "설마 그런 일이 있겠어?" 하고 넘겼다. 근데 생각해보면 현실에서 충분히 일어날 수 있다. GC가 길어질 수도 있고, 네트워크가 느려질 수도 있고, 쿼리가 걸릴 수도 있다. 이 글은 그 "만약"이 실제로 터졌을 때 어떻게 대응할 수 있는지 정리한 내용이다.먼저, 문제 상황을 정확히 그려보자클라이언트 A Redis 클라이언트 B━━━━━━━━..

이번 주에 새로 배운 것이상과 현실 사이에서 할 수 있는 건 생각보다 많다회사에서 새 프로젝트가 들어왔다. 보험 도메인이다. 처음 기획서를 받았을 때 정책이 빠져 있는 부분이 많았고, 고려사항도 불명확했다. 예전 같았으면 "기획이 덜 된 거 아닌가"라고 생각하고 기다렸을 것이다.이번엔 다르게 움직였다. AI를 활용해서 보험 도메인의 일반적인 정책, 예외 케이스, 고려해야 할 사항들을 먼저 정리했다. 다른 프로젝트에서 사람들이 어떤 부분을 놓쳤는지, 어떤 정책이 나중에 문제가 됐는지를 조사하고 참고했다. 그걸 바탕으로 기획 쪽에 질문을 던지고, 정책을 같이 구체화해나갔다.결과는 예상 밖이었다. 정책이 명확해지니 단순 CRUD는 물론이고, 복잡한 비즈니스 로직도 흐름이 보였다. 데드라인보다 빠르게 치고 나갈..

락을 잘 골랐는데 왜 더 위험해졌을까 — 주문 트랜잭션의 락 3개를 1개로 줄인 이야기TL;DR이커머스 주문 흐름에 동시성 제어를 붙이면서, 도메인마다 "맞는 락"을 골랐더니 하나의 트랜잭션에 비관적 락 2개 + 낙관적 락 1개가 공존하게 됐다. 데드락 위험, 락 보유 시간 증가, 팀원이 알아야 할 규칙 증가. 결국 "락을 잘 고르는 것"보다 "공유 자원 자체를 줄이는 것"이 더 근본적인 해법이었고, 원자적 UPDATE로 트랜잭션 내 락을 1개로 줄였다.동시성 문제가 뭔지부터 고민을 시작했다.과제를 받고 처음 든 생각은 단순했다. "공유 자원이면 동시성 문제가 생긴다." 재고, 포인트, 쿠폰, 좋아요, 여러 사용자가 건드리는 데이터를 쭉 나열했다.근데 이 정의가 틀렸다. 상품 상세를 100명이 동시에 조..

이번 주에 새로 배운 것같은 질문에 다른 답이 나올 수 있다이번 주 과제는 도메인 모델링 + 레이어드 아키텍처 + DIP 적용이었다. 코드를 짜는 것보다 더 많이 배운 건, 여러 시각의 피드백을 비교 분석하면서였다."Repository 호출은 누구의 책임인가?"라는 질문 하나에 대해서도 사람마다 답이 달랐다. Application에서 직접 호출해야 한다는 관점, 도메인이 이미 필요한 상태를 가지고 있어야 한다는 관점, 비즈니스 로직의 위치를 먼저 정하면 자연스럽게 따라온다는 관점. 전부 근거가 있고, 전부 틀린 말은 아니다.나는 Blue Book 스타일(Domain Service → Repository 직접 호출)을 택했는데, 이 방식에 직접 동의하는 시각은 많지 않았다. 대부분 "Repository 호..

"왜 과한지"를 모르면서 "과하다"고 말하고 싶지 않았다TL;DR이커머스 프로젝트에서 도메인 모델을 순수 POJO로 분리하고 JPA Entity를 Infrastructure에 배치하는 Entity-level DIP를 끝까지 적용해봤다. Dirty Checking을 포기하고 36곳에 명시적 save()를 호출하는 비용을 치렀지만, "과하다"는 것을 아는 것과 "왜 과한지"를 직접 체감하는 것은 완전히 다른 경험이었다. 이 글을 쓰게 된 배경나는 기술적으로 넓은 경험을 쌓아오기 위해 노력했다. 다양한 프로젝트를 거치면서 여러 기술 스택을 다루고, 실무에서 마주치는 문제들을 부딪히며 해결해 왔다.그런데 이번에 이커머스 서비스의 핵심 도메인 상품, 브랜드, 좋아요, 주문, 결제을 레이어드 아키텍처 + DIP(의..

블로그 포스팅이 길어질수록 독자들은 원하는 정보를 찾기 힘들어합니다. 이때 꼭 필요한 게 바로 목차라고 생각합니다.!구글 SEO(검색 최적화)에도 도움이 된다는 사실, 알고 계셨나요?하지만 인터넷에 나온 코드를 그대로 따라 해도 "클래스명이 달라서 안 보이거나", "클래식하면 해당 위치로 이동하지 않는" 문제로 고생하시는 분들이 많습니다. 오늘은 어떤 스킨에서도 완벽하게 작동하는 자동 목차 설치법을 정리하겠습니다. 1. 왜 자동 목차를 써야 할까?사용자 편의성: 독자가 원하는 부분으로 바로 점프할 수 있습니다.SEO 점수 상승: 구글 로봇이 글의 구조를 파악하기 쉬워져 검색 노출에 유리합니다.체류 시간 증가: 깔끔한 정돈은 블로그의 전문성을 높여줍니다.2. 1분 만에 끝내는 자동 목차 설치법Step 1:..

소프트웨어 아키텍처 스터디가 2월 12일을 마지막으로 마무리됐다.회사 업무가 바빠지면서 몇 번은 참석하지 못했지만, 이번 스터디는 결과적으로 혼자 읽는 독서와는 다른 종류의 완주였다. 단순히 책을 끝까지 읽었다는 성취보다, 읽는 과정에서 아키텍처를 바라보는 시야와 의사결정 습관이 더 분명해졌다.스터디를 하면서 가장 자주 떠올랐던 문장은 이것이다.아키텍처는 정답을 맞히는 일이 아니라, 무엇을 포기할지 합의하는 일이다.혼자 읽을 때는 “개념을 이해했는가”에 초점이 갔다면, 함께 읽을 때는 자연스럽게 “이 개념이 실무 의사결정에서 어떤 역할을 하는가”로 질문이 이동했다. 이 이동이 이번 스터디의 가장 큰 가치였다.1) 약속이 만든 실행력, 실행이 만든 학습출석률이 완벽하진 않았지만, 스터디가 약속이라는 사실은..

이번 주에 새로 배운 것이번 주 과제는 이커머스 도메인(상품, 브랜드, 좋아요, 주문 등)을 대상으로 설계 산출물만으로 PR을 제출하는 것이었다. 요구사항 정리부터 시퀀스 다이어그램, 클래스 다이어그램, ERD까지. 코드 없이 설계를 완성한다는 게 처음엔 막막했다.그래서 나는 시작점부터 명확히 잡았다.유비쿼터스 언어(Glossary)를 가장 먼저 정의하고, 그 언어 위에서 설계를 진행한다.이 선택은 “문서 작성 순서”가 아니라 “설계의 품질을 결정하는 규약”을 먼저 고정하는 일이었다.실무에서 설계가 흔들리는 순간을 떠올려보면, 대부분은 기술이 아니라 단어의 혼용에서 시작한다.“상품”과 “아이템”을 같은 의미로 쓰거나“주문”과 “결제”를 동일시하거나“장바구니”와 “주문서” 경계를 흐리거나이런 상태로 ERD..

TL;DR이번 이커머스 설계 과제에서 AI를 "도메인별 전문가"로 세워놓고 브레인스토밍하며 요구사항을 명확히 했다. 대화에서 나온 결정을 문서(결정 로그)로 고정했다. AI 시대에 문서화는 단순한 이해 도구가 아니라, “왜 이 결정을 했는지”를 남겨 팀이 다시 흔들리지 않게 하는 운영 자산이 된다.1. AI에게 "당신의 의견이 궁금합니다"라고 물었다이번 과제의 도메인은 이커머스였다. 상품, 브랜드, 주문, 재고, 쿠폰, 결제. 각각이 하나의 전문 영역이고, 나 혼자 모든 도메인을 깊이 있게 설계하기엔 한계가 있었다. 각 도메인은 결국 서로 얽히고, 작은 정책 차이가 데이터 모델과 트랜잭션 경계를 흔든다. 혼자 모든 도메인을 깊이 있게 설계하려 하면, 금방 “그럴듯한 정답”에 기대게 된다.그래서 AI를..

법령 프로젝트에서 전제 조건이 깨진 경험이, 이커머스 설계에서 내 판단을 어떻게 바꿨는지에 대한 이야기 TL;DR회사에서 법령 번역 서비스를 만들며, 기획과 함께 꼼꼼하게 정의한 전제 조건이 한 번에 무너지는 걸 경험했다. "외국 법령은 수정 불가"라는 핵심 제약이 깨지면서 데이터 정합성이 무너졌고, 운영 데이터가 쌓인 상황에서 DB를 쉽게 바꾸지 못해 애플리케이션 레벨에서 분기 처리를 억지로 끼워 맞추느라 코드가 복잡해졌다. 그 결과 코드가 빠르게 복잡해졌고, 그 경험이 이번 이커머스 설계 과제에서 "요구사항을 꼼꼼하게 보고, 전제가 바뀌어도 테이블이 흔들리지 않는 최소한의 여유"를 우선으로 두게 되었다.1. 기획과 분명히 합의했는데, 그게 깨졌다회사에서 세무법인을 위한 법령 서비스를 맡았던 적이 있다..