
설계를 진행하기 전의 나의 생각은 최근에는 AI가 설계 방향까지 제안해주다 보니, 어느 순간 "AI가 해준대로 가도 되지 않을까"라는 생각이 들었지만 생각이 바뀌었다.
설계에 대한 판단은 내가 해야 한다.
단순한 상품 삭제 하나만 봐도 소프트 삭제 VS 하드 삭제 트레이드오프를 마주하게 된다.
소프트 삭제는 데이터를 복구할 수 있고 주문 이력도 유지할 수 있지만, 조회 조건마다 삭제 여부를 신경 써야 하고 데이터가 계속 쌓인다. 반대로 하드 삭제는 구조는 단순해지지만, 이미 주문된 상품이 삭제되었을 때 주문 이력과 정합성이 깨질 수 있다.
결국 어떤 방식이 정답이라기보다, 서비스 상황에서 무엇을 더 중요하게 볼지 개발자가 선택해야 했다.
주문 결제 시스템을 하나 더 예로 든다면
AI는 주문 생성, 재고 차감, 결제 승인 API, 웹훅 처리까지 그럴듯하게 구현해 줄 수 있다.
그러면 AI는 이런 생각도 대신해 줄 수 있을까?
"결제 성공 후 재고 차감이 실패하면 어떻게 할 것인가?"
" 사용자가 결제 도중 새로고침 하면? "
" 환불 중 장애가 발생하면? "
내가 생각할 때 대신 해주지 못한다고 생각하지만 개발자가 이런 상황을 인지하고 장애 대응이나 사용자 경험에 좋은 판단을 하고 AI에게 도움을 구하는 것은 가능하다고 생각한다.
AI에게 판단조차 맡긴다면 아마 개발자라는 직업은 기획자 + AI 에이전트에게 자리를 뺏길 것이다.
문서화는 AI에게 도움을 받자
반대로 문서화에서는 AI의 도움을 정말 많이 받을 수 있었다.
요구사항을 명시해 준다면 유스케이스나 클래스 다이어그램 흐름도 같은 거는 간단하게 만들 수 있다.

한 가지 아쉬웠던 점은, 이 문서를 "왜 만드는가"에 대한 고민이 부족했다는 것이다.
개발자가 봐도 한눈에 이해하기 어려운 구조인데, 비개발자의 관점에서는 더욱 복잡하게 느껴질 수 있다는 생각이 들었다.
단순히 정보를 나열하는 문서가 아니라, 누가 보더라도 흐름과 의도를 이해할 수 있는 문서를 만드는 방향에 대해서도 고민을 했으면 좋았을 것 같다.
'루퍼스 4기' 카테고리의 다른 글
| 쇼핑몰에서 안전하게 재고 차감하기 (0) | 2026.06.12 |
|---|---|
| 주문 생성 흐름에서 책임을 어디까지 나눌 것인가 (0) | 2026.05.29 |
| 이커머스 도메인을 설계하면서 나는 어떤 고민을 했을까 (0) | 2026.05.22 |
| 루퍼스 1주차 WIL (TDD & 테스트 가능한 구조) (0) | 2026.05.15 |
| 좋은 테스트 코드는 어떻게 작성하면 좋을까? (0) | 2026.05.15 |