요구사항 정의서와 화면 정의서를 바탕으로 기획과 개발의 연결 약속인 API 계약서(API Contract)를 작성하고, 각 문서 간의 불일치 및 누락 항목을 식별하며, 변경에 따른 UI 및 API 종속 영향 분석과 테스팅을 자동화하는 최첨단 인터페이스 협업 아키텍처에 대한 핵심 요약 정보를 담고 있습니다.
프로젝트 현장에서 기획, 디자인, 개발 간의 이해 오차는 데이터베이스의 누락과 정합성 붕괴로 직결됩니다. 설계 단계에서의 정합성 보장이 왜 중요한지 알아봅니다.
기획 문서나 화면 디자인과 실제 배포된 API Spec의 필드가 달라 통신 에러가 나거나 화면에 특정 값이 나오지 않는 결함이 속출합니다.
프론트엔드와 백엔드 개발자 간의 구두 약속으로만 필드를 정의해 개발하다가, 이름(Camel vs Snake Case)이나 형식이 맞지 않아 매번 회의를 반복하게 됩니다.
가격이나 주문 단계 등 비즈니스 요구사항 하나만 바뀌어도 이에 연결된 API와 프론트 화면, 테스트 코드까지 어떤 수정 범위가 발생하는지 확인하는 데 막대한 분석 코스트가 발생합니다.
단일 대화 컨텍스트에 국한된 ChatGPT와 달리, 폴더 구조 전체와 다중 파일 간 종속 관계를 인지하는 Codex Client의 특성을 비교합니다.
| 비교 항목 | ChatGPT (일반 대화형 AI) | Codex Client (Workspace 기반 AI) |
|---|---|---|
| 컨텍스트 인지 | 기획서, 화면 설계서, 백엔드 API 명세 파일 간의 실제 필드 매핑 및 기능 부합 여부 교차 검증 | 기획-화면-API로 이어지는 다중 산출물의 속성을 추적하여 평점, 에러 코드 누락 등을 입체적으로 검출 |
| API 불일치 검출 | 일회성 API 코드 템플릿만 대충 구성해 줌 | 프로젝트 표준 용어 사전을 기반으로 일관된 표준 네이밍 및 DB 컬럼명 자율 추천 |
| 영향 범위 분석 | 단편적인 스키마 오류나 가상의 테이블 수정안 제시 수준 | 스키마의 미세한 변경(예: 컬럼 추가)에 따른 API 규격과 화면 수정 부위 목록 역추론 |
Day 4 세션 동안 학습자가 생성해 내는 최종 결과물 목록과 해당 산출물의 목적입니다.
자연어 기획서에서 엔티티 및 관계를 추출해 렌더링한 Mermaid ERD 스크립트 및 명세서 (출력: erd-schema.md)
파편화된 한글/영문 기획 용어들을 영문 표준 컬럼 형식으로 정의한 프로젝트 표준 용어 사전 (출력: project-glossary.md)
예약 승인제(WAIT_APPROVE) 추가에 따른 API 및 화면 수정 리스트 변경 영향도 분석서 (출력: change-impact-report.md)
정규화 및 데이터 설계 결정 사유와 기각된 대안을 아카이빙한 Design Decision Log (DDL) (출력: design-decision-log.md)
동시성 결제 오류, 참조 무결성 탈퇴 유실, 트랜잭션 롤백에 대한 DB 개선책을 담은 Edge Case 분석 보고서 (출력: edge-case-analysis.md)
실습 단계에서 활용되는 입력 값과 Codex Workspace 추론을 거쳐 생성되는 결과물의 매핑입니다.
회의 시나리오 줄글을 입력하여 정밀 정규화 관계(1:N, 1:1)와 Mermaid 코드를 도출합니다.
제공된 요구사항 정의서와 화면 정의서 내용을 기반으로, 필요한 API 목록을 도출하고 요청(Request) 및 응답(Response) 필드의 타입과 영문 변수명을 정의하여 표준 API 계약서(API Contract)를 작성해 주세요.
Figma 기획서 용어와 DB 개발 명세의 격차를 비교 분석해 도메인 용어 마스터 사전을 빌드합니다.
제공된 day4_requirements.md, day4_screen_definition.md, day4_api_specification_v1.md 파일들을 교차 대조하여 기획 요구사항이나 화면 UI 설계와 불일치하거나 누락된 API 엔드포인트 및 필드를 찾아 검토 보고서를 작성해 주세요.
예약 절차에 '승인' 단계가 추가되는 릴리즈 계획 변경 시의 API 및 테이블 영향 범위를 파악합니다.
제공된 API 변경 요청서(day4_api_change_request.md) 내용을 분석하여, 예약 신청 API 수정 시 영향을 받는 다른 시스템 영역과 문서의 목록을 도출하고, 팀원들에게 즉시 작업 공유가 가능한 API 영향도 분석서를 작성해 주세요.
정규화 결정, 예약 이력의 물리 분리 결정 등에 관한 기각 사유와 합의를 로그화합니다.
제공된 day4_api_specification_v1.md의 API 명세서를 검토하여, REST API 설계 표준(HTTP Method 용도, URL 명명법), 일관된 오류 처리 구조, 확장성을 기준으로 개선점을 분석하고 API 리뷰 보고서를 작성해 주세요.
참조 무결성 위배(탈퇴) 및 트랜잭션 붕괴를 예방하기 위한 시스템 취약점 오디팅을 진행합니다.
현재 정의된 예약 및 결제 API 명세를 기반으로, 정상 등록 흐름(Happy Path)과 필수 파라미터 누락, 날짜 형식 오류, 한도 초과 및 권한 만료 등의 예외 케이스를 모두 포함하는 API 테스트 시나리오 및 검증 체크리스트를 작성해 주세요.
단순 텍스트 매칭을 넘어 엔티티의 참조 무결성(FK) 관계 및 트랜잭션 수명 주기를 파악하여, 자연어 기획안을 DDL DDL(Data Definition Language) 쿼리 및 상태 기계 규칙으로 자동 역추론해냅니다.
서로 다르게 표기된 용어(고객명 vs Nickname)를 의미론적으로 의미 군집화(Clustering)하여 전사 용어 마스터 사전을 도출하고, 이를 바탕으로 데이터 사전의 정합성을 동기화합니다.
각 단계별로 도출된 데이터와 분석 정보가 기술설계 루프를 돌며 어떻게 품질을 극대화하는지 확인합니다.
이 인터페이스 검증 파이프라인은 코드를 단 한 줄도 짜기 전에 모든 오차와 설계 모순을 제거하여, 프론트와 백엔드가 한 번에 통합 빌드에 성공할 수 있도록 완성도 높은 인터페이스 품질을 확보해 줍니다.
교육 과정 중 토의하거나 면접 질문으로 활용하기 좋은 주제 리스트입니다.
"에러 발생 시 HTTP Status를 무조건 200 OK로 전달하고 본문에 에러 상세 코드를 표기하는 관례(Custom Error)와 HTTP 표준 Status(4xx, 5xx)를 이용하는 구조 중, 마이크로서비스 아키텍처(MSA) 관점에서의 장단점은 무엇일까요?"
"API 불일치 검출 사전을 작성하지 않고 프로젝트를 중반까지 진행했을 때, 개발팀 내부에서 발생하는 '용어 부채' 비용은 실제 일정에 어떤 여파를 주나요?"
Day 4에 다루는 전체 실습 과제 및 미션의 구성도입니다.
| Task | 주제 | AI 활용 방안 |
|---|---|---|
| Task 01 | API 계약서 생성 | 기획서와 화면 설계를 분석하여 RESTful API 계약서 스펙 자동 도출 |
| Task 02 | API 불일치 검출 | 기획 명세와 API 스펙의 불일치(평점 누락 등)를 자동으로 잡아내어 리포트 생성 |
| Task 03 | API 변경 영향 분석 | API 파라미터나 상태 변경 시 연동해야 할 화면 및 스펙의 연쇄 영향 추적 |
| Mission 01 | API 리뷰 및 개선 | 명사형 URL, 에러 코드 예외 스키마 등을 표준화하여 개선안을 도출한 API Review Report |
| Mission 02 | API 테스트 시나리오 생성 | 정상 작동 흐름뿐 아니라 필수 키 누락, 포맷 에러에 대응하는 예외 테스트 매트릭스 도출 |