Skip to content

[3팀 주민수] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발#87

Open
Thomas97-J wants to merge 36 commits intohanghae-plus:mainfrom
Thomas97-J:main
Open

[3팀 주민수] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발#87
Thomas97-J wants to merge 36 commits intohanghae-plus:mainfrom
Thomas97-J:main

Conversation

@Thomas97-J
Copy link

과제 체크포인트

필수 스펙

    1. 반복 유형 선택
    • 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
    • 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
      • 31일에 매월을 선택한다면 → 매월 마지막이 아닌, 31일에만 생성하세요.
      • 윤년 29일에 매년을 선택한다면 → 29일에만 생성하세요!
    • 반복일정은 일정 겹침을 고려하지 않는다.
  1. 반복 일정 표시
    • 캘린더 뷰에서 반복 일정을 아이콘을 넣어 구분하여 표시한다.
  2. 반복 종료
    • 반복 종료 조건을 지정할 수 있다.
    • 옵션: 특정 날짜까지
      • 예제 특성상, 2025-12-31까지 최대 일자를 만들어 주세요.
  3. 반복 일정 수정
    1. ‘해당 일정만 수정하시겠어요?’ 라는 텍스트에서 ‘예’라고 누르는 경우 단일 수정
      • 반복일정을 수정하면 단일 일정으로 변경됩니다.
      • 반복일정 아이콘도 사라집니다.
    2. ‘해당 일정만 수정하시겠어요?’ 라는 텍스트에서 ‘아니오’라고 누르는 경우 전체 수정
      • 이 경우 반복 일정은 유지됩니다.
      • 반복일정 아이콘도 유지됩니다.
  4. 반복 일정 삭제
    1. ‘해당 일정만 삭제하시겠어요?’ 라는 텍스트에서 ‘예’라고 누르는 경우 단일 수정
      1. 해당 일정만 삭제합니다.
    2. ‘해당 일정만 삭제하시겠어요?’ 라는 텍스트에서 ‘아니오’라고 누르는 경우 전체 수정
      1. 반복 일정의 모든 일정을 삭제할 수 있다.

기본 과제

공통 제출

  • 테스트를 잘 작성할 수 있는 규칙 명세
  • 명세에 있는 기능을 구현하기 위한 테스트를 모두 작성하고 올바르게 구현했는지
  • 명세에 있는 기능을 모두 올바르게 구현하고 잘 동작하는지

기본 과제(Easy)

  • AI 코드를 잘 작성하기 위해 추가로 작성했던 지침
  • 커밋별 올바르게 단계에 대한 작업
  • AI 도구 활용을 개선하기 위해 노력한 점 PR에 작성

기본 과제(Hard)

  • Agent 구현 명세 문서 또는 코드
  • 커밋별 올바르게 단계에 대한 작업
  • 결과를 올바로 얻기위한 history 또는 log
  • AI 도구 활용을 개선하기 위해 노력한 점 PR에 작성

심화 과제

  • 모든 질문에 대해 꼼꼼하게 정리했는지

과제 셀프회고

처음으로 에이전트를 구현해 보았다. 평소 AI는 코파일럿을 통해 단순작업을 진행하고, 로그를 분석하는 등으로 사용하는데 그쳤는데, 이번 과정을 통해 클로드 CLI도 처음으로 활용해 보았고, 평소라면 생각도 하지 않았을 고민들을 할 수 있었다. 그러면서 AI를 단순한 도구로 사용하는 것이 아니라, 조금 더 인공지능이라는 이름에 걸맞게 사용하는 법에 대해 관심을 가져야 한다는 생각을 하게 되었다.

이번 과제를 진행하며 나는 에이전트에서 에이전트로 어떤 정보가 넘어가는지 내가 사이에서 명확하게 확인할 수 있는 것을 목표로 했다. 이를 위해 각 에이전트가 이전 에이전트의 산출물을 읽고, 자신 또한 산출물을 전달하는 과정에 집중했다. 이 모든 중간과정들은 results 폴더 하단에 각 단계 이름과 타임스탬프를 넣어 작성된 명세, 테스트 코드, 구현 코드, 리팩토링된 코드를 모두 기록하도록 했고, 이 과정에서 참고한 컨텍스트 역시 log 폴더에 기록하도록 진행했다. 또 각 단계에서 활용하는 동일한 기능들, 예를들어 커밋 등은 사정에 정의된 명령어를 그대로 실행할 수 있도록 진행했다.
그 외에도 전체적인 프로젝트의 컨텍스트는 첫 벨리데이션 에이전트만 확인할 수 있도록 했고, 각 단계의 문제에 대해서는 내가 개입하는 형태를 취하고자 했다. 예를들어 그린 단계에 문제가 발생하면, 직접 구현을 수정시켜 단계를 넘기거나, 다시 그린 단계를 재시도 할 수 있도록 명령어를 작성했다.

이런 방향으로 구현하다 보니, 오케스트레이터는 절차적으로 에이전트의 작업 순서와 파일 관리 등을 담당하는 쉘 명령어가 되었다. 이런저런 이유로 구현이 조금 다른 팀원과는 다르게 되었는데, 다른 팀원분들의 이야기를 들어도 내 방식에 적용하기 막막해 조금 어려움을 겪었다.

사실 첫 반복 유형 선택, 생성 작업을 진행하던 중 클로드 CLI의 토큰이 떨어져 이후 작업은 일부 직접 구현하였다.

기술적 성장

AI를 에이전트로 분리하여, 각 관심사를 한정하고, 유기적으로 연결하는 과정을 처음 연습해 보았다. 막연하게만 느껴지던 AI 에이전트가 어떤 것인지 대략적으로 느낄 수 있었다.
그러나 오케스트레이터를 sh로 작성하는 전략이 과제 후반부에 와서는 정말 좋은 전략이었는지 의문이 들었다. 다른 팀원들의 에이전트의 동작과 너무 다른 방식이라 다른분들의 방식이 잘 이해가 되지 않았다. 이런 의문들이 언젠가는 다른 학습의 동기가 될 것이라고 생각한다.

코드 품질

아쉬운 점 :

시간에 쫒겨 직접 기능을 구현하던 중 소스코드의 품질을 하나도 고려하지 않은 코드가 양산되었다.
각 에이전트별 프롬프트와 유틸들이 통일된 스타일로 작성되지 않았다.
에이전트가 작성한 코드의 리팩토링 과정이 과연 더 나은 코드가 되었는지 제대로 검증하지 못했다.
각 에이전트가 매번 작성할때마다 다른 스타일의 코드를 작성하는 구조로 에이전트들이 구성되었다.

좋은 점:

각 에이전트가 공통적으로 사용해야 하는 기능들(커밋 등)은 sh 파일에서 관리해 각 에이전트별로 스타일의 차이를 최대한 줄이고자 했다.
절차적으로 각 에이전트의 동작, 반복 등을 명확하게 구분하고자 했다.

학습 효과 분석

에이전트 분업에 대해 조금 이해할 수 있었다. 그리고 생각보다 내가 이해하지 못하고 있는 영역이 많다는 것을 알게 되었다.

과제 피드백

과제에 투자하는 시간을 하루 3시간~4시간 이상으로 늘렸지만 아직 과제를 따라가기 조금 벅차다는 느낌입니다. 에이전트 활용에 대한 이해도가 낮은 것이 원인이라고 생각하지만, 수면 시간을 줄이는 것이 회사 업무의 부담으로 이어지는 것 같아 걱정입니다. 시간이 지날수록 조금씩 더 적응해 나갈것이라고 생각하지만 지금으로서는 약간의 부담이 있습니다.

리뷰 받고 싶은 내용

현제 제 에이전트들은

  1. validation : 주어진 명세를 확인하고 프로젝트 구조를 분석한 뒤, 구체적인 테스트 작성을 위한 명세 md를 작성한다.
  2. design : validation가 작성한 명세 md를 확인하고, 이를 기반으로 테스트 전략을 작성한다.
  3. red : 작성된 테스트 전략을 기반으로 테스트를 구현한다.
  4. green : 작성된 테스트 코드를 기반으로 실제 구현을 진행한다.
  5. refactor : 그린에서 작성된 구현을 리팩토링한다.
    이런 방식으로 동작합니다. 처음 벨리데이션에서 확인한 프로젝트 구조 이외에 나머지 에이전트들은 제 프로젝트와는 독립적으로 자신이 이전 에이전트에게서 전달받은 정보만을 활용하여 자신의 목표를 달성하도록 작성했습니다.

이 과정에서 오케스트레이터는 각 에이전트를 실행하고, 파일을 연결하는 용도로만 사용되었고, 이를 sh 파일로 작성해, 에이전트가 아니라 사전에 정의된 명령어의 집합이 되었습니다.

나름대로는 각 에이전트의 행동을 명확하게 통제하고, 코드를 직접 확인하고자 하는 의도가 있었지만, 코드를 반복적으로 생성할 때 매번 스타일이 변경되고, 단계의 후반으로 갈 수록 생성되는 코드의 품질이 떨어진다는 생각이 들었습니다. 특히 리팩터 단계의 경우 그린보다 그다지 나아지지 않는 코드를 재생산하는 등의 이슈가 있었습니다. 제 이런 전략이 에이전트가 생성하는 코드를 보수적으로 사용하고자 하는 목적이 있다면 효용성이 있는 방식인지, 에이전트를 이렇게 활용하는 것은 원래 취지에 부합하지 않는 일인지 궁금합니다.

minsu added 30 commits October 27, 2025 22:44
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
✅ GREEN 단계 - 테스트 통과하는 구현
- 최소한의 구현
- 모든 테스트 통과

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
✅ GREEN 단계 - 테스트 통과하는 구현
- 최소한의 구현
- 모든 테스트 통과

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
✅ GREEN 단계 - 테스트 통과하는 구현
- 최소한의 구현
- 모든 테스트 통과

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
✅ GREEN 단계 - 테스트 통과하는 구현
- 최소한의 구현
- 모든 테스트 통과

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
✅ GREEN 단계 - 테스트 통과하는 구현
- 최소한의 구현
- 모든 테스트 통과

Generated by TDD Orchestrator
📝 RED 단계 - 실패하는 테스트 작성
- AAA 패턴 적용
- 엣지 케이스 포함

Generated by TDD Orchestrator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant