구현: 단계별 프롬프트 구성

Git 환경 설정 프롬프트

인베스트(INVEST) 원칙

독립성 (Idependent)

• 각 티켓은 가급적 다른 티켓에 의존하지 않고
  독립적으로 구현 및 배포 가능해야 함

• AI가 특정 기능에만 집중하여 병목 현상 없이 코드를 생성할 수 있도록 함

협상가능성 (Negotiable)

• 세부 구현 방식은 개발자가 조정할 수 있는 여지를 둠

• 세부 구현 방식에 유연성을 두어
  AI가 최적의 코딩 방식이나 라이브러리를 제안할 수 있도록 함

가치(Valuable)

• 각 모든 티켓의 완료는 프로젝트에 실질적인 진전을 준수/의미해야 함

추정가능성(Estimable)

• 작업 범위를 명확히 하여 공수 산정이 가능해야 함

• AI가 직접 구현과 테스트를 진행하는 환경에서 작업 범위를 명확히 하여
  성공 가능성을 예측할 수 있기 때문에 매우 중요함

작은 크기(Small)

• 하나의 티켓은 보통 1~2일 내에 완료할 수 있는 크기여야 함

• AI의 컨텍스트(context) 유지력을 극대화

테스트 가능성(Testable)

• 작업 완료 여부를 확인할 수 있는 구체적인 기준이 있어야 함

페이즈(Phase) 분할의 기대효과

• 별도의 단계 구분 없이 모든 작업을 한꺼번에 진행하는 빅뱅(Big Bang) 방식에서는 여러 코드가 섞여 의존성 엉킴 현상이 일어남

• 기초 설정부터 시작하여 API를 구축하고,
  그 다음에 UI를 얹는 논리적 빌드업 과정을 거침
  따라서 선행 작업이 완벽히 마무리된 후에 다음 단계로 넘어가기 때문에
  불필요한 병목 현상을 원천적으로 차단 가능함

• 위의 모든 과정은 프로젝트의 추적성 (Traceability)을 확보해줌

TechSpec과 Tasks 비교

초기 설정

• TechSpec에서는 전체 시스템 환경 구축의 하나의 단계로 표현되지만,
  Tasks 단계에서는 프론트엔드와 백엔드로 나누어 서로 다른 기술 스택을 가짐
  이를 분리함으로써 두 영역 간의 결합도를 낮추고
  각 영역이 독립적으로 개발될 수 있는 병렬성 확보

UI 개발

• 레이아웃과 컴포넌트 스타일링으로 세분화하여,
  시각적 구조의 정밀도를 높이기 위함

로직 구현

• Seperation of Concerns(관심사의 분리)를 철저히 따름

고도화

• 시스템의 성능과 사용자 경험의 품질을 상용 수준으로 끌어올리기 위한 과정

마무리

• 게임 종료와 재시작이라는 상태 전이를 명확히 함으로써,
  메모리 누수나 상태 초기화 같은 오류 같은 잠재적 위험 제거

• 이러한 세분화의 기저에는 인베스트 원칙이 내재되어 있음
  각 태스크가 독립적이고 가치 있으며 테스트 가능하도록 작게 쪼개는 것
  (이렇게 하면 동작하는 결과물을 확인할 수 있는 testability가 확보됨)

• 개발자가 한번에 집중해야 할 정보의 양을 조절하여
  인지적 과부화를 방지하고, 프로젝트의 진척도를 가시적으로 측정

Ticket 예시

• 가장 핵심적인 대목은 작업 완료 후 AI가 수행하는
  자가 검증 프로세스인 수용 기준 확인 단계
  테스트가 실패하게 되면 성공할 때 까지 스스로 코드를 수정 및 검증 반복

이슈 라벨 생성

라벨을 생성하는 이유

• 시각적 가시성 확보 (Visual Visibility)
  색상별로 구분한 라벨을 통해
  현재 어떤 영역의 작업이 많이 진행되고 있는지 직관적으로 파악

• 효율적인 필터링 (Efficient Filtering)
  라벨은 강력한 검색 도구가 됨

• 단계별 개발 지원 (Phase based Development)
  아키텍쳐 계층에 따른 진행 상황을 명확히 관리

• 프롬프트의 핵심은 실행 로직(Execution Logic)에 담긴
  멱등성 (Idempotency) 확보에 있음
  (동일한 연산을 여러 번 반복해서 수행하더라도
  최종 결과가 달라지지 않는 성질)

• 라벨을 만드는 것에 그치지 않고,
  기존에 라벨이 없다면 생성하고 존재한다면 최신 정보로 업데이트

• AI가 스스로 작업 범위를 식별하고 보고하는 데 있어 이정표 역할

이슈(티켓) 등록 프롬프트

• 해당 과정에서 AI는 각 티켓의 성격을 스스로 분석함 (Labeling Logic)

• TechSpec이라는 추상적인 설계도를
  깃허브 이슈(GitHub Issue)라는 구체적인 실행 단위로 연결

칸반 보드 생성

• Issue는 우리가 해결해야 할 원재료인 데이터

• 프로젝트 보드(Project Board), 즉 칸반 보드는
  이 데이터들을 한눈에 볼 수 있게 배치해주는 그릇이자 시각적인 View
  전체 작업 흐름인 워크플로우(work flow)를 최적화

구현-테스트-PR 생성

PR 리뷰

• 코드의 품질을 유지하고 기술 부채를 방지하는 것
  사람이 직접 코드를 읽으며 AI가 놓친 엣지 케이스를 잡아내는 것

• Human in the Loop: 인간 참여형
  인공지능이 모든 과정을 자동화 하더라도
  가장 중요한 결정과 최종 판단의 고리에는 반드시 사람이 머물러야 함

• LGTM(Looks Good To Me)
  AI가 작성한 코드를 승인하고 남기는 코멘트