항해 플러스 7기 2주차

드엔트론프·2025년 11월 2일

항해플러스

목록 보기
2/9

2주차

2주차가 시작됐다. 2주차 과제는 AI를 지대로 활용해서 테스트 코드 작성과 테스트 코드를 기반으로 UI 설계까지 모두 자동으로 (!) 동작하게 구현하는 일이었다.

1. 발제 이후

처음 발제 이후, 과제를 이해하는 듯 이해하기 어려웠다. 그래서 테스트 코드를 AI 갖고 짜라는 거 같은데, 이걸 어디서부터 시작해야되는거지?

다시금 발제 내용을 읽는데도 알쏭달쏭한 느낌.. 학습메이트님이 어떻게 만드셨는지도 주말에 열심히 보고 아 대충 저런 느낌인가..? 암튼 AI 써서 만들라는거지? 아 이해했다!

2. 과제 준비

한참을 발제만 읽고 있다가 어느새 수요일이 됐다..(?)
이게 참 신기한 일인데, 나는 분명 새벽 한 시까지 이래저래 찾아보고 공부하는 데 진도가 안나간다. 그리고 하루는 멘토링 듣고나면 하루도 없어짐; 분명 회사 엥간함 칼퇴하면서 과제 시간을 가져보려 하는데, 쫌 쉽지 않다.

그렇게 수요일이 되고, 화요일에 모각코 이야기가 나와서 가기 귀찮았지만 다들 또 간다는데 안가는 건 예의가 아닌 듯하여, 퇴근후 팀원들과 오프라인에서 만나 모각코를 진행했다 ㅎㅎ

근데 모각코 하길 참 잘했다. 하며 일단 내가 왜 진행을 망설이고?있는지와 다들 어떻게 시작했는지를 물어보고, 하나 둘 준비를 하기 시작했다.

에이전트가 먼저 무엇인지 묻고, 어떻게 하면 될 까 생각하면 되는구나

팀원들의 도움으로, 첫 준비를 시작다. 에이전트의 의미를 다시 한 번 새기고, 심화의 내용으로 에이전트 여럿을 만들어 운영하는 오케스트레이터가 내가 준 요구사항을 자동으로 해결하는 로직을 짜야되는구나 생각했다.

3. 과제 시작

무엇에 망설이며 진행을 뒤늦게 시작했는지,, 빠르게 진행해보려 애썼다.

GPT에게 Ai agent가 뭔지, Bmad 문서 던져주며 설명 요청했다.
왜냐면 발제에서도, 또 다른 여러 많은 분들도 Bmad를 많이 참고하며 작성했다고 하기에.

GPT가 적당히 몇 개 만들어주길래 가지고 커서에 물어보다가, 발제 자료랑 비교하고 이전 학습메이트가 말해준 내용과는 조금 다른 에이전트의 구현이 나온 것 같았다.
어느정도 잘 나왔다 생각했는데, 작성하고 다시 발제 자료를 읽어보니 많이 부족한것같아 다시 질문을 했다.

근데 작성하면서 BMAD-METHOD 참고해서 작성할라고 보니까 V6로 바뀌면서 뭐가 많이 바뀐듯?하다.
저녁에 BMAD 깃 레포를 보고 있는데 갑자기 V6로 바뀐듯, 앞서 봤던 오케스트레이터와 여러 하위 에이전트를 다루는 부분에서 조금 바뀐 것 같다. 다시 V6의 방향을 공부해보고 적용해볼까 했다가, 일단은 발제처럼 진행하기로 마음먹고 이전 내용을 보며 다시 요청했다.

내용을 참고하며 작성한 내 프롬프트 원문은 아래와 같다.

테스트 결과와 전체적인 흐름을 봤는데, 전반적으로 수정을 한 번 해줘야 할 것 같아.
난 최종적으로 Intergrator가 모든 에이전트를 지휘하는 형태로 가긴 할건데,
에이전트의 구분을 조금 다르게, 그리고 세분화해야할 것 같아.

첨부된 이미지를 보면 알 수 있듯, 내게는 6개의 에이전트가 필요해. (첨부된 이미지는 참고 사항이지 저게 무조건이라는 말은 아니야)
이들의 공통되는 조건들이 몇 가지 있어.

- 각각 명확한 페르소나가 있음.
- 에이전트들은 사진처럼 연결돼 돌아가는 형태.
    - 각 에이전트들은 작업을 하며 변경 사항이 있을 때, 스스로 커밋을 해야 해.
    - **각 에이전트는 자기 단계가 끝났을 때 최종적으로 나에게 다음 작업을 해도 될 지 꼭 확인을 받아야 해. (필수)**
- 기본적으로 @kent-beck-tdd.md 파일을 참고하여 TDD 작성하기.

그럼 각 에이전트에 대해 간략히 설명해볼게.

1. 기능 설계 에이전트
    - 내가 전달하는 요구사항을 토대로, 명세 / 기능에 대해 구체적이게 작성, 현재 프로젝트의 상태를 보고 어떤 것이 부족한지, 어떤 건 잘 됐는지를 확인하고 수락하는 에이전트야.
2. 테스트 설계 에이전트
    - 앞서 기능 선정 에이전트가 정리한 문서를 바탕으로, 테스트를 설계하는 에이전트야.
    - 이 에이전트는 특히 @kent-beck-tdd.md 을 제대로 참고하고 적용해야하는 에이전트야.
3. 테스트 작성 에이전트 (RED - 검증 - GREEN 반복)
    - 이름처럼 이제 설계된 테스트를 통해 테스트를 작성하는 에이전트야. 앞서 만든것처럼 easy, medium 처럼 테스트 파일을 나눌 필요는 없지만 필요하다면, 혹은 구분해야 좋겠다 싶다면 테스트를 구분지어 작성해도 돼. 하지만 테스트 작성 에이전트는 전체적인 테스트의 틀을 만드는 일이지. 완벽한 테스트 동작까지 구현하는건 아니야.
    - 작성한 테스트 문서를 보고, 잘 짜여진 테스트인지를 **가볍게 테스트** 하는거야. 이 검증이 통과하지 못하면 다시 테스트 작성 에이전트가 동작해야겠지?
    - 이젠 정말 테스트를 개발할 차례야. 가벼운 검증을 마친 테스트 작성 코드를, 이제는 동작할 수 있도록 (GREEN).
    - 또, 작성할 게 너무 많다면 테스트 별로 잘게 쪼갠다음 커밋을 해. 잘게 쪼갠 커밋이 5개를 초과할 때마다 나에게 다시 한 번 검사를 맡아야 해.
4. 코드 작성 에이전트
    - 이러한 테스트 코드를 토대로, 실제 기능을 구현해야겠지? 테스트 코드를 잘 참고해서, 실제 코드를 작성하면 돼.
    - 여기서 중요한 건, 앞서 만든 테스트를 제대로 구현하지 못하겠다고 테스트 자체를 수정해서는 **절대 안돼**. 명심해야해.
    - 코드를 작성할 때는 기존의 모듈을 잘 파악하여 올바른 위치에 알맞게 작성해야 해.
    - 코드 작성이 완료 되었다면, 어떻게 작성했는지를 내게 알려줘야 해.
    - 그리고 당연하겠지만, 작성이 완료됐다면 내가 요구한 기능을 모두 잘 구현했는지를 한번 더 스스로 테스트하는걸 잊지마.
5. 리팩터링 에이전트
    - 혹여나 더 나은 방식의 작성이 있을지, 작성 부분에 문제는 없을지, 테스트 코드에 맞게 됐는지를 한번 더 확인하고 코드를 정리하는 에이전트야.
    - 내가 갖고있는 라이브러리 혹은 유틸, 모듈을 잘 사용해서 작성한 게 맞는지도 보고.

추가 확인.

- 나는 위 에이전트들을 통합할 6번. 'Orcastrator 에이전트'를 하나 둘 것이지만, 지금은 위 6개의 에이전트들이 제대로 작성될 지, 동작할 지 모르니 추후 각각의 에이전트들을 테스트한 후에 작성할 계획이야.

노션 AI의 도움
작성하고 내용의 맞춤법을 정리하려 노션에 붙여넣기 했는데, 노션 AI가 있는걸 봤다. 얘한테 한번 더 물어볼까? 싶어 물어봤는데, 엥.. 내가 놓친 여러 테스트 내용과 더 적절한 내용을 설명해주잖슴?

notion_prompt - 네 제안을 모두 수락한 다음 프롬프트를 작성해줘!

아래는 노션이 추가적으로 정리해준 내용 일부!

- 각각 명확한 페르소나가 있음.
- 에이전트들은 사진처럼 연결돼 돌아가는 형태.
    - 각 에이전트들은 작업을 하며 변경 사항이 있을 때, 스스로 커밋을 해야 해.
    - **각 에이전트는 자기 단계가 끝났을 때 최종적으로 나에게 다음 작업을 해도 될지 꼭 확인을 받아야 해. (필수)**
    - 각 에이전트가 실패했을 때는 최대 3번까지 재시도하며, 그래도 실패하면 이전 단계로 롤백하여 나에게 보고해야 해.
- 기본적으로 @kent-beck-tdd.md 파일을 참고하여 TDD 작성하기.
- 커밋 메시지는 다음 규칙을 따라야 해: "[에이전트명] 작업타입: 간단한 설명" (예: "[테스트설계] feat: 사용자 인증 테스트 케이스 설계")

### 에이전트 간 통신 프로토콜

각 에이전트는 다음 에이전트에게 작업 결과를 전달할 때 다음 형식을 따라야 해:

- **작업 요약**: 무엇을 했는지 간단히 설명
- **주요 결정사항**: 왜 그렇게 했는지 이유
- **다음 에이전트를 위한 노트**: 특별히 주의해야 할 사항
- **참조 파일/커밋**: 관련된 파일이나 커밋 정보

그럼 각 에이전트에 대해 구체적으로 설명해볼게.

1. 기능 설계 에이전트
    - **역할**: 내가 전달하는 요구사항을 토대로, 명세/기능에 대해 구체적이게 작성, 현재 프로젝트의 상태를 보고 어떤 것이 부족한지, 어떤 건 잘 됐는지를 확인하고 수락하는 에이전트야.
    - **출력 문서 형식**: 기능 명세서에는 반드시 다음 항목이 포함되어야 해:
        - 기능 목적 및 목표
        - 구체적인 요구사항 (기능적/비기능적)
        - 제외 범위 (out-of-scope)
        - 성공 기준 (acceptance criteria)
        - 기존 코드베이스와의 연관성
    - **완료 조건**: 모든 요구사항이 명확하게 정의되었고, 내가 승인했을 때.
2. 테스트 설계 에이전트
    - **역할**: 앞서 기능 선정 에이전트가 정리한 문서를 바탕으로, 테스트를 설계하는 에이전트야.
    - 이 에이전트는 특히 @kent-beck-tdd.md를 제대로 참고하고 적용해야 하는 에이전트야.
    - **출력 문서 형식**: 테스트 계획서에는 다음이 포함되어야 해:
        - 테스트할 기능 목록
        - 각 테스트의 목적과 검증할 사항
        - 테스트 우선순위 (중요도/난이도 기준)
        - 예상되는 엣지 케이스
        - 테스트 파일 구조 제안
    - **완료 조건**: 모든 요구사항에 대한 테스트가 설계되었고, 커버리지가 충분하며, 내가 승인했을 때.
3. 테스트 작성 에이전트 (RED — 검증 — GREEN 반복)
    - **3-1. RED 단계**: 실패하는 테스트 틀 작성
        - 설계된 테스트를 바탕으로 테스트 코드의 구조를 작성해. 이 단계에서는 완벽한 구현이 아니라 ..~~~
  • 작성 후 놓친 내용은 없을까 전체적으로 읽어보다 server.js 가 있는걸 확인하여, server.js가 API 명세 역할 한다는 걸 알려주어 수정했다.

  • 또 놓친게 없나 수정된 md 파일을 읽다가, 테스트하는 내용 it( ~~~ 이 영어로 나오는 것을 확인. describe는 함수 같은걸 정의할 때가 있으니 어쩔수 없지만 it 부분은 한글로 작성해 명확히 읽어지길 요청했다.

  • 다시 또 읽어보다가, 아 TDD의 순서가 RED-GREEN-REFACTOR의 반복인데 RED-검증-GREEN / REFACTOR로 작성하도록 요청한 것을 발견. 다시 RED-GREEN-REFACTOR의 순서로 요청. → 중간 살펴보니 커서도 RED-GREEN-REFACTOR의 순서가 더 명확함을 알고 수정했다.

  • 혹시나 싶어, 기존 hooks나 utils에도 공통된 내용이 많으니 사용해야 기존 형태를 잘 유지할 수 있을거라 했더니 그 내용에 대해 추가로 수정했다.

  • 마지막으로, 오케스트레이터를 만들기 전 각자의 에이전트가 잘 돌아가는 지 확인하려 진행했다.


4. 과제 후기

  • AI에 대해 항상 가볍게 질문하고 문제에 대해서만 쉽게 질문했었는데, 에이전트라는 개념과 실제 사용을 통해 많이 배웠다 !
  • 이러한 키워드가 있다는 걸 아는 것, 또 조금씩 사용한 것이 좋은 기회였다고 생각한다.
  • 이 체계적인(?) AI 에이전트의 활용을 어떻게 더 활용하면 좋을지를 고민해보면 좋은 일이라 생각하고, 실제 회사에서도 작은 부분이라도 이를 활용하여 적용할 준비를 해보려 한다.

2주차 후기

  • 이번에도 완벽한 과제 해결을 한 건 아니었지만, 모르는 걸 배워간다는 즐거움에 조금씩 스며드는 중이다.

  • 물론 스며들긴하는데, 목요일에 밤새고 출근하게 되는건 국룰인가? 진짜 죽겠다..

  • 일요일에 더 빡시게 하면 되는데, 일요일엔 왜또 나를 이렇게 공부 못하게 막을까 나 자신이? ..

  • 회사 근처 호떡집, 겨울은 역시 호떡 😋😋😋

profile
왜? 를 깊게 고민하고 해결하는 사람이 되고 싶은 개발자

0개의 댓글