[3팀 주민수] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발#87
Open
Thomas97-J wants to merge 36 commits intohanghae-plus:mainfrom
Open
[3팀 주민수] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발#87Thomas97-J wants to merge 36 commits intohanghae-plus:mainfrom
Thomas97-J wants to merge 36 commits intohanghae-plus:mainfrom
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
과제 체크포인트
필수 스펙
기본 과제
공통 제출
기본 과제(Easy)
기본 과제(Hard)
심화 과제
과제 셀프회고
처음으로 에이전트를 구현해 보았다. 평소 AI는 코파일럿을 통해 단순작업을 진행하고, 로그를 분석하는 등으로 사용하는데 그쳤는데, 이번 과정을 통해 클로드 CLI도 처음으로 활용해 보았고, 평소라면 생각도 하지 않았을 고민들을 할 수 있었다. 그러면서 AI를 단순한 도구로 사용하는 것이 아니라, 조금 더 인공지능이라는 이름에 걸맞게 사용하는 법에 대해 관심을 가져야 한다는 생각을 하게 되었다.
이번 과제를 진행하며 나는 에이전트에서 에이전트로 어떤 정보가 넘어가는지 내가 사이에서 명확하게 확인할 수 있는 것을 목표로 했다. 이를 위해 각 에이전트가 이전 에이전트의 산출물을 읽고, 자신 또한 산출물을 전달하는 과정에 집중했다. 이 모든 중간과정들은 results 폴더 하단에 각 단계 이름과 타임스탬프를 넣어 작성된 명세, 테스트 코드, 구현 코드, 리팩토링된 코드를 모두 기록하도록 했고, 이 과정에서 참고한 컨텍스트 역시 log 폴더에 기록하도록 진행했다. 또 각 단계에서 활용하는 동일한 기능들, 예를들어 커밋 등은 사정에 정의된 명령어를 그대로 실행할 수 있도록 진행했다.
그 외에도 전체적인 프로젝트의 컨텍스트는 첫 벨리데이션 에이전트만 확인할 수 있도록 했고, 각 단계의 문제에 대해서는 내가 개입하는 형태를 취하고자 했다. 예를들어 그린 단계에 문제가 발생하면, 직접 구현을 수정시켜 단계를 넘기거나, 다시 그린 단계를 재시도 할 수 있도록 명령어를 작성했다.
이런 방향으로 구현하다 보니, 오케스트레이터는 절차적으로 에이전트의 작업 순서와 파일 관리 등을 담당하는 쉘 명령어가 되었다. 이런저런 이유로 구현이 조금 다른 팀원과는 다르게 되었는데, 다른 팀원분들의 이야기를 들어도 내 방식에 적용하기 막막해 조금 어려움을 겪었다.
사실 첫 반복 유형 선택, 생성 작업을 진행하던 중 클로드 CLI의 토큰이 떨어져 이후 작업은 일부 직접 구현하였다.
기술적 성장
AI를 에이전트로 분리하여, 각 관심사를 한정하고, 유기적으로 연결하는 과정을 처음 연습해 보았다. 막연하게만 느껴지던 AI 에이전트가 어떤 것인지 대략적으로 느낄 수 있었다.
그러나 오케스트레이터를 sh로 작성하는 전략이 과제 후반부에 와서는 정말 좋은 전략이었는지 의문이 들었다. 다른 팀원들의 에이전트의 동작과 너무 다른 방식이라 다른분들의 방식이 잘 이해가 되지 않았다. 이런 의문들이 언젠가는 다른 학습의 동기가 될 것이라고 생각한다.
코드 품질
아쉬운 점 :
시간에 쫒겨 직접 기능을 구현하던 중 소스코드의 품질을 하나도 고려하지 않은 코드가 양산되었다.
각 에이전트별 프롬프트와 유틸들이 통일된 스타일로 작성되지 않았다.
에이전트가 작성한 코드의 리팩토링 과정이 과연 더 나은 코드가 되었는지 제대로 검증하지 못했다.
각 에이전트가 매번 작성할때마다 다른 스타일의 코드를 작성하는 구조로 에이전트들이 구성되었다.
좋은 점:
각 에이전트가 공통적으로 사용해야 하는 기능들(커밋 등)은 sh 파일에서 관리해 각 에이전트별로 스타일의 차이를 최대한 줄이고자 했다.
절차적으로 각 에이전트의 동작, 반복 등을 명확하게 구분하고자 했다.
학습 효과 분석
에이전트 분업에 대해 조금 이해할 수 있었다. 그리고 생각보다 내가 이해하지 못하고 있는 영역이 많다는 것을 알게 되었다.
과제 피드백
과제에 투자하는 시간을 하루 3시간~4시간 이상으로 늘렸지만 아직 과제를 따라가기 조금 벅차다는 느낌입니다. 에이전트 활용에 대한 이해도가 낮은 것이 원인이라고 생각하지만, 수면 시간을 줄이는 것이 회사 업무의 부담으로 이어지는 것 같아 걱정입니다. 시간이 지날수록 조금씩 더 적응해 나갈것이라고 생각하지만 지금으로서는 약간의 부담이 있습니다.
리뷰 받고 싶은 내용
현제 제 에이전트들은
이런 방식으로 동작합니다. 처음 벨리데이션에서 확인한 프로젝트 구조 이외에 나머지 에이전트들은 제 프로젝트와는 독립적으로 자신이 이전 에이전트에게서 전달받은 정보만을 활용하여 자신의 목표를 달성하도록 작성했습니다.
이 과정에서 오케스트레이터는 각 에이전트를 실행하고, 파일을 연결하는 용도로만 사용되었고, 이를 sh 파일로 작성해, 에이전트가 아니라 사전에 정의된 명령어의 집합이 되었습니다.
나름대로는 각 에이전트의 행동을 명확하게 통제하고, 코드를 직접 확인하고자 하는 의도가 있었지만, 코드를 반복적으로 생성할 때 매번 스타일이 변경되고, 단계의 후반으로 갈 수록 생성되는 코드의 품질이 떨어진다는 생각이 들었습니다. 특히 리팩터 단계의 경우 그린보다 그다지 나아지지 않는 코드를 재생산하는 등의 이슈가 있었습니다. 제 이런 전략이 에이전트가 생성하는 코드를 보수적으로 사용하고자 하는 목적이 있다면 효용성이 있는 방식인지, 에이전트를 이렇게 활용하는 것은 원래 취지에 부합하지 않는 일인지 궁금합니다.