[멋쟁이사자처럼] 프로젝트 'TtaBook' 회고

멋쟁이사자들 프론트엔드 심화 부트캠프에서 개인적인 목표로 하루에 한 개씩 공부한 내용을 포스트 하는 것을 개인 목표로 삼았으나, 프로젝트에 집중하여 목표를 놓쳤습니다. 다시 하루에 한 개씩 배운 내용을 포스트 하겠습니다.

---

프로젝트 '따북'을 하며 느낀 점에 대하여 KPT 방식의 개인 회고를 작성하겠습니다.

KEEP (앞으로도 계속 이어갈 좋은 습관 및 활동)

API 명세에 대한 깊이 있는 토론 : PUT과 DELETE의 역할을 두고 동료와 나눈 토론이 매우 긍정적이었습니다. 이는 단순히 기능을 구현하는 것이 아닌, "왜 이 기술을 이렇게 사용해야 하는가"에 대한 근본적인 이해를 높이는 데 큰 도움이 되었습니다. 이러한 기술 토론은 계속 이어 나가겠습니다.

클린 아키텍처 원칙에 대한 고민 : 프로젝트 진행 중, "이것이 클린 아키텍처에 맞는가?" 질문에 대하여 계속 생각했습니다. 코드의 구조와 유지보수성을 생각하는 습관에 대하여 배웠습니다.
포기하지 않는 점진적인 디버깅 : 처음에는 동기화 문제, 그 다음엔 API 설계 문제, 마지막에는 타입 에러 문제까지 단계별로 문제를 해결했습니다. 복잡한 문제를 마주친 경우, 한 번에 해결하는 것이 아닌 천천히 하나씩 원인을 분석하고 해결하는 접근 방식을 배웠습니다.

명확한 요구사항 전달 및 피드백 : "POST를 사용하면 안 된다" 와 같이 막히는 부분에서 명확하게 지향하는 바와 제약사항에 대하여 인지하고 작업을 이어나갔습니다. 이는 불필요한 커뮤니케이션 줄이고 문제 해결의 방향을 명확하게 설정하는 데 큰 도움이 되었습니다.

Problem (개선이 필요한 문제점 및 어려움)

API 설계와 실제 구현 간의 초기 괴리 : PUT은 리소스 전체를 교체한다는 '설계 원칙'과, '현실적인 구현'의 차이를 초기에 명확히 인지하지 못했습니다. 이로 인해 클라이언트와 서버 간 데이터 동기화 로직이 누락되었습니다.

암묵적인 가정에 따른 불필요한 작업 : 처음에는 "새로운 공간을 생성할 수도 있다"는 암묵적인 가정 하에 POST 로직을 포함하여 코드를 작성하였으나, "공간은 이미 존재한다"는 핵심 제약 조건이 나중에 명확해져 로직을 수정해야 했습니다.

계층 간 데이터 타입(DTO)의 불일치: UpdateRequest 타입에 spaceId가 누락되어 발생한 타입 에러는, 각 계층(Controller-Usecase-Repository)을 데이터가 이동할 때 타입 정의가 일관되지 않으면 어떤 문제가 발생하는지 명확히 보여주었습니다.

상태 동기화 로직의 복잡성: 클라이언트의 최종 상태(rooms 배열)를 기준으로 서버 DB의 데이터를 C/U/D 처리하는 '상태 동기화' 로직이 직관적이지 않으며, 구현 시 고려해야 할 상황이 많아 처음 접근하기에 다소 복잡하게 느껴졌습니다.

TRY (문제점을 해결하기 위해 다음에 시도해 볼 것)

API 설계 시, '서버 구현 시나리오' 함께 정의하기 : 앞으로 API 엔드포인트를 설계할 때, 명세(PUT /api/spaces/{id}) 뿐만 아니라, 해당 요청을 받았을 때 서버가 수행해야 할 작업의 순서(e.g., 1. 기존 데이터 조회 -> 2. 비교 -> 3. 생성/수정/삭제 실행)를 함께 구상하고 문서화하는 습관을 들이겠습니다.

'타입 우선 설계(Type-First Design)' 접근법 시도 : 기능을 구현하기 전에, 해당 기능에 필요한 데이터의 흐름을 먼저 정의하고 그에 맞는 타입(Type/Interface)도 함께 생각하겠습니다. 특히 서버와 클라이언트가 주고받는 데이터 객체(DTO)의 타입을 가장 먼저 확정하여, 계층 간 타입 불일치 문제를 원천적으로 방지하겠습니다.

핵심 제약 조건 및 유저 스토리 명시적으로 공유 : 새로운 기능 개발 착수 전, "사용자는 ~를 할 수 있다/없다", "이 데이터는 항상 존재한다/할 수 있다" 와 같은 핵심적인 제약 조건을 먼저 확인하고 팀원과 공유하는 절차를 갖겠습니다.

복잡한 로직에 대한 패턴 학습 및 적용 : 이번에 배운 '상태 동기화(State Synchronization)' 패턴을 잘 기억하고 문서화 하겠습니다.
다음에 유사한 "목록 전체를 편집하는 UI"를 구현할 때, 개발 시간을 단축하고 버그를 줄이겠습니다.