← RenameDP General 백엔드

2026-03

프로젝트 생성 흐름을 화면과 API 병합 단계에서 맞춘 경험

프론트엔드와 API 병합 시 순차 저장·최종 일괄 저장의 이해 차이를 확인하고, 기본정보·작업 구조·인원 배정의 세 호출을 통합 생성 요청으로 묶었다. 2026-03-27 커밋 확인, 협업 과정은 사용자 진술.

경험 정보

  • 프로젝트: RenameDP General 백엔드 (renamedp-general-backend)
  • 기간: 2026-03-27 전후. 사건의 정확한 날짜는 확인 필요
  • 역할: 프로젝트 생성 API의 백엔드 설계·구현
  • 정리 상태: draft
  • 관련 역량: 협업, 요구사항 해석, API 설계
  • 관련 문항: nh-bank-2026-09 / f21e7409-7b67-446a-82ae-6cd43e9d0c14 (실제 사용)
  • 마지막 확인: 2026-09-17

상황과 과제

기획자와 프론트엔드 개발자와 함께 프로젝트 생성 화면을 구현했다. 초기 백엔드 설계는 프로젝트 기본정보를 저장한 후 작업 구조와 인원을 순차 등록하는 흐름으로 이해했다. 사용자의 2026-09-17 진술에 따르면, 각자 구현을 마치고 프론트엔드 화면과 API를 병합하는 단계에서 실제 기획은 마지막 저장 버튼으로 한 번에 등록하는 흐름임을 확인했다.

본인의 행동과 판단

사용자는 이 차이 때문에 프로젝트 생성 흐름의 API 설계를 다시 구현했으며, 당초 화면 흐름에서 사용하려던 세 호출(프로젝트 기본정보 저장, 작업 구조 등록, 인원 배정)을 하나의 통합 생성 호출로 합쳐야 했다고 진술했다. 세 호출의 구체적 대상은 2026-09-17 후속 답변으로 확인했다. 이후 복잡한 화면은 데일리 스크럼에서 화이트보드로 각자의 화면·데이터 흐름을 그려 이해 차이를 확인했다고 자기소개서에 기록했다. 화이트보드의 구체적인 장면과 반복 여부는 추가 확인이 필요하다.

고려한 대안과 선택 이유

초기 이해는 기본정보를 먼저 저장하고 후속 단계에서 작업 구조·인원을 등록하는 순차 방식이었다. 합의한 화면 흐름은 마지막 저장 시점에 전체 설정을 전달하는 방식이었다. 각 방식의 기획상 판단 근거와 임시저장 범위는 사용자에게 추가 확인이 필요하다.

결과

코드에서 2026-03-27 커밋 c12cfe8a는 ProjectCreateRequest에 작업 구조와 인원 배정을 추가했고, b3e80d2b는 ProjectManageUseCase에 프로젝트 생성→작업 구조 생성→인원 배정→작업 할당을 단일 트랜잭션으로 묶었다. 기존 개별 기능 API를 모두 제거한 것은 확인되지 않았다. 따라서 'API 세 개를 삭제했다'가 아니라 '프로젝트 생성 화면의 호출 세 단계를 하나의 통합 생성 요청으로 묶었다'고 표현한다. 유사 기능의 시행착오 감소는 사용자 진술이나 측정 근거를 추가 확인해야 한다.

배운 점과 이후 행동

자기소개서에서 사용자는 도구로 기획 정보를 전달하는 것만으로 공통 이해가 보장되지 않으므로, 복잡한 기능은 구현 전에 화면·데이터 흐름을 서로 눈에 보이게 표현하고 합의한다고 설명한다. 이는 사용자 진술이며 별도 행동 기록은 아직 확인되지 않았다.

근거와 확인 수준

  • 코드/커밋 확인: 2026-03-27 c12cfe8a (통합 생성 요청), b3e80d2b (통합 UseCase). 로컬 저장소: /Users/jwsong/projects/RenameDP/applications/rename-dp-general/rename-dp-general-backend
  • 사용자 진술: 2026-09-17 현재 대화 — 구현 후 프론트엔드와 API 병합 시 흐름 차이를 발견했고, 프로젝트 기본정보 저장·작업 구조 등록·인원 배정의 세 호출을 하나로 합쳐야 했음
  • 자기소개서 진술: nh-bank-2026-09 1번 — 화이트보드 공유와 시행착오 감소. 독립 근거 미확인
  • 구현 범위를 넘어서는 재작업 규모·팀 성과·소요 시간은 미확인

후속 단서 (미확인)

  • 2026-09-17 사용자 진술: 도면 관리 기능에서도 여러 화면에 걸친 저장 흐름 때문에 비슷한 이해 차이가 있었던 것 같다고 기억한다. 프론트엔드 코드에는 버전 관리 저장과 도면 관리 저장의 분리, 첫 도면의 업로드→활성화→동기화 순서가 있으나, 그때 화이트보드로 오해를 사전에 해소했다는 협업 사건은 확인되지 않았다. 성과 사례로 쓰기 전 실제 장면 확인 필요.

남은 질문

  1. 프론트엔드와 병합할 때 누가 어떤 합의를 했는가?
  2. 재구현 소요와 이후 화이트보드 방식의 실제 반복 사례 또는 관찰 가능한 변화는 무엇인가?