Tech Diary Tech Diary

이커머스 설계 과제를 하면서 배운 것들 — "요구사항 정리"가 이렇게 어려운 거였나?이커머스 서비스의 설계 문서를 작성하면서 배운 것들을 정리합니다.요구사항 분석, 시퀀스 다이어그램, 클래스 다이어그램, ERD — 각 단계에서 어떤 함정이 있었고, 어떤 기준을 세웠는지이번 주에 한 것감성 이커머스 서비스의 설계 문서를 작성했다. 브랜드, 상품, 좋아요, 주문. 도메인 자체는 흔하다. 좋아요 누르고, 여러 상품을 한 번에 담아 주문하는 서비스. 대고객 API(/api/v1)와 어드민 API(/api-admin/v1)가 분리되어 있고, 주문 시 상품 스냅샷 저장과 재고 차감이 핵심 요구사항이다. "이 정도면 금방 끝나겠지"라고 생각했다. 전혀 아니었다.1. 요구사항 정리는 API 명세의 한글 번역이 아니다처..

요구사항 분석 → 시퀀스 다이어그램 → 클래스 다이어그램 → ERD4개의 설계 문서를 작성하고, 셀프 리뷰를 반복하면서 깨달은 것들을 정리합니다.들어가며브랜드, 상품, 좋아요, 주문.어디서든 볼 수 있는 평범한 이커머스 도메인이다. 처음엔 "이 정도면 금방 끝나겠지"라고 생각했다. 요구사항 정리하고, 다이어그램 그리고, ERD 짜면 끝 아닌가?그런데 막상 요구사항 분석서를 작성하고 나서 스스로 리뷰를 해보니, 처음 버전에서는 유스케이스 몇개가 빠져 있었다. 어드민 브랜드 등록/수정? 상품 상세 조회? 어드민 주문 목록? API 테이블에는 떡하니 있는데, 유스케이스 흐름이 없었다."아 이건 당연한 거니까..."라고 넘긴 부분이 결국 전부 구멍이었다.이 글에서는 설계 문서 4종(요구사항 분석 · 시퀀스 다이..

TDD를 실제로 직접 구현회원 API를 TDD로 만들어야 했다. Red → Green → Refactor. 개념은 알고 있었다. 그런데 막상 빈 프로젝트를 열고 나니 손이 멈췄다.DTO도 없고, 도메인 모델도 없고, Repository 인터페이스도 없다. 테스트를 먼저 작성하라는데, 대체 뭘 테스트하라는 건지 감이 안 왔다. 이번 주는 그 막막함에서 시작해서, 테스트 더블이라는 개념을 처음 배우고, 멘토링에서 실무 기준을 잡기까지의 기록이다.1. 테스트 더블회사에서 테스트를 작성할 때 mock()을 쓰고 verify()를 쓰긴 했다. 그런데 그게 "Mock"인지 "Stub"인지 구분해서 쓴 적은 없었다. 이번 주 발제에서 테스트 더블이라는 개념을 제대로 배웠다.역할목적핵심Dummy자리만 채움 (사용되지 ..

회원가입, 내 정보 조회, 비밀번호 변경의 어디서든 볼 수 있는 평범한 CRUD API를 만들어 보았습니다.하지만 이 세 개의 API를 TDD로 구현하고, 이후 여러번의 리팩토링을 거치면서 생각보다 많은 설계 결정을 내려야 했습니다.이 글에서는 기능을 "일단 돌아가게" 만든 뒤, 어떤 문제를 발견하고 왜 그렇게 고쳤는지를 중심으로 이야기하려 합니다. 리팩토링 자체보다는 그 과정에서 마주한 질문들이 더 재미있었기 때문입니다.먼저, TDD로 뼈대를 세우기Clean Architecture 기반의 레이어 구조(Controller → Facade → Service → Repository)를 따랐고, Red → Green → Refactor 사이클로 진행했습니다. 처음에는 MemberModelTest로 엔티티 생성..

왜 이 글을 쓰게 되었을까? 최근 부서에서 특정 유저의 요청을 1만번 카운트하고 자정마다 리셋하는 기능을 개발하면서, Mock을 사용한 테스트 코드를 작성하게 되었다. 처음에는 "Mock을 왜 만드는 거지? Mock으로 어떤 것들을 테스트하는 거지?"라는 의문이 들었다. 특히 "Mock을 쓰면 테스트를 위한 테스트를 하는 게 아닌가?"라는 생각이 들어서 Mock 사용을 꺼려했었다. 하지만 실제 테스트 코드를 작성하고 실행해보니, Redis를 직접 호출하지 않고도 Redis가 호출된 기록만으로 테스트를 돌리는 것이 신기했다. 이 경험을 바탕으로, Mock을 통한 테스트가 왜 유용한지, 그리고 실제로 어떤 가치를 제공하는지를 정리해보려 한다. 특히 두 가지 측면에서 Mock 테스트가 유용했다.외부 의존성(R..

왜 이 글을 쓰게 되었을까?개발을 처음 배울 땐 컨트롤러, 서비스, 리포지토리. 딱 세 개의 레이어로 프로젝트를 나눴다. 그리고 대부분의 로직은 서비스에 몰아넣었다. 그때는 그것만으로도 어느 정도는 역할이 분리 된다고 생각했다. 그런데 시간이 지나고 개발을 조금씩 더 하다 보니, ‘서비스에 로직을 넣는다’는 말 자체가 점점 모호하게 느껴졌다. ‘서비스’라는게 무엇인지, ‘비즈니스 로직’은 어디까지고, ‘도메인 로직’은 어디까지인지 고민이 되었다. 이런 고민이 깊어질 즈음, 회사에서 프론트엔드 업무도 같이 하게 됐다. 프론트엔드는 백엔드보다 훨씬 얕게 알고 있지만, 프론트 역시설계에서 ‘의존성’은 굉장히 중요한 문제라는 것을 느꼈다. 의존성이 한 번 꼬이기 시작하면 유지보수와 기능 변경이 굉장히 힘들어진다..

왜 이 글을 쓰게 되었을까?부서에서 사용하는 Java 프로젝트를 Kotlin으로 전환하는 작업을 맡게 되었다.문제는, 이 프로젝트의 도메인도 제대로 알지 못했고, 기존 개발자가 부서에 남아 있지도 않았다. 게다가 전환 작업만 할 수 있는 것도 아니고, 기존의 다른 업무들도 병행해야 하는 상황이었다.이런 조건이라면 당연히 실수가 나올 수밖에 없다. 코드 한 줄 수정할 때마다 ‘이게 정말 원래 기능대로 동작할까?’라는 의문이 들었다. 다행히도, 이 프로젝트에는 테스트 코드가 잘 작성되어 있었다. 덕분에 테스트 코드가 없었다면 훨씬 더 많은 시행착오를 겪었을 것이라는 생각이 들었다.이 경험을 바탕으로, 이번 글에서는 Java에서 Kotlin으로 전환하는 과정에서 테스트 코드가 어떤 도움이 되었는지를 정리하려 ..

배포 환경 변수, 어떻게 관리하는 게 좋을까?작년에 진행한 프로젝트에서 쿠버네티스 기반의 사내 배포 툴을 활용해 개발, 스테이징, 운영 환경을 구축하게 되었다. 그런데 배포 환경별로 환경 변수를 어떻게 효율적으로 관리할지 고민이 생겼다.왜 이 문제를 고민했을까?기존 방식에서는 사내 배포 툴에서 직접 Docker에 환경 변수를 입력해야 했다. 이렇게 하면 운영 환경과 개발 환경을 분리할 수는 있지만, 문제는 코드상에서 어떤 환경이 적용되는지 확인할 수 없다는 점이었다. 배포 설정이 사내 툴 내부에서만 관리되다 보니, 코드만 봐서는 어떤 환경에서 실행되는지 알기 어려웠다.그래서 환경 변수를 코드에서도 명확히 확인할 수 있으면서도, 관리가 더 편리한 방법을 찾기로 했다. 처음에는 Dockerfile에서 환경을..