들어가면서
이번 주차에선 AI와 테스트를 활용한 안정적인 기능 개발 이라는 주제로 과제를 진행했습니다.
TDD의 개념을 이해하고 AI를 활용한 TDD 방식을 통해 기존 서비스에 새로운 기능을 점진적으로 추가하는 과정을 경험하며 TDD의 장점을 알 수 있었고, AI를 잘 활용하는 방법에 대해 생각해볼 수 있었습니다. 또한 어렵게만 느껴졌던 AI 에이전트라는 주제에 대한 두려움을 없애주었던 주차였습니다.
TDD란?
TDD(Test-Driven Development, 테스트 주도 개발)는 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하여 기능 개발을 하는 소프트웨어 개발 방법론 중 하나입니다.
실패하는 테스트 코드를 작성하는 단계를 RED, 테스트 코드를 통과하는 최소한의 기능 코드를 작성하는 단계를 GREEN, 기능 코드에 대한 리팩토링을 진행하는 단계를 REFACTOR 단계라고 합니다.
즉, TDD는 반복적인 RED -> GREEN -> REFACTOR 단계를 거쳐 기능을 구현하는 방법론으로 이해할 수 있습니다.
AI 에이전트란?
AI 에이전트란, LLM을 핵심 엔진으로 사용하여 행동을 수행하는 '실행자'입니다. AI 에이전트는 LLM, 계획, 도구, 피드백 등의 구성 요소를 가질 수 있습니다.
즉, 사용자의 지시를 받아 LLM을 통해 답변을 생성하고 답변을 생성하는 과정에서 정의된 계획 or 도구 등을 활용하는 것을 의미합니다. 마지막엔 피드백 or 평가 단계를 두어 AI 에이전트가 스스로 적절한 결과물인지 판단하도록 할 수도 있습니다.
과제에선 AI 에이전트를 어떻게 구성했는가
이번 과제에서 저는 총 6개의 AI 에이전트를 만들었습니다. (학습 메이트님들 좀 부려먹었어요 ㅎ.ㅎ)
- Doeun : 사용자로부터 입력받은 기능에 대한 기능 상세 문서를 만드는 에이전트
- Taeyoung : 기능 상세 문서를 바탕으로 세세한 작업 단위(story)를 나누는 에이전트
- Haneul : story 별 테스트 코드를 설계하고 작성하는, 즉 TDD RED 단계를 담당하는 에이전트
- Yeongseo : 작성된 테스트 코드를 통과하는 기능 코드를 작성하는, 즉 TDD GREEN 단계를 담당하는 에이전트
- Junhyeoung : 작성된 기능 코드를 리팩토링하는, 즉 TDD REFACTOR 단계를 담당하는 에이전트
- Jaehyun : 5개 에이전트를 총괄하는 오케스트레이션 에이전트
각각의 에이전트를 개별적으로 실행했을 때는 만족스러운 결과물을 얻을 수 있었지만, 오케스트레이션 에이전트를 활용했을 때는 문제가 발생했습니다.
오케스트레이션 에이전트가 각 에이전트에게 업무를 분배하고, 각자가 역할에 맞게 작업을 수행하는 자동화된 협업 프로세스를 구축하고 싶었지만, 오케스트레이션 에이전트가 다른 에이전트를 호출하지 않고 스스로 모든 작업을 처리하려는 문제가 발생했습니다.
아직 오케스트레이션 구조를 어떻게 설계해야 할지 명확히 감이 오진 않지만, 팀원분들과 학습 메이트의 노하우를 공유받아 제 에이전트를 고도화해볼 계획입니다.
👍 Keep
두려워하지 말고 적극적으로 나서기
이번 과제를 하면서 코치님과 페어 프로그래밍을 하는 경험을 했습니다.
예전의 저였다면
내 코드가 공개되는 게 너무 부끄럽다…, 내가 짠 코드가 형편없으면 어떡하지?
이런 생각들에 사로잡혀 아예 시도조차 하지 못했을 겁니다.
두려움을 극복한 결과로 너무나도 소중한 경험을 할 수 있었습니다. 기회를 만들어주신 분들께 감사함을 전합니다🙇
다음에도 좋은 기회가 주어진다면, 주저하지 않고 적극적으로 참여하여 또 다른 귀중한 경험을 쌓고 싶습니다.
‼️ Problem
모든 걸 AI에게 위임하고자 한 것
과제 초반에는 "나보다 AI가 더 똑똑하니깐 ~" 라는 생각으로, 에이전트 설계부터 기능 구현까지 모든 과정을 AI에게 위임했습니다.
하지만 그 결과, AI가 결과물을 만들어내긴 했으나 그 결과가 올바른지 스스로 판단하기 어려운 문제가 발생했습니다.
또한 결과물의 작성 포맷을 명확히 정해주지 않다 보니 매번 다른 형태의 결과물이 생성되었고, 이로 인해 결과의 정확성을 평가하기 어려웠습니다.
이 경험을 통해 중간중간 인간의 개입이 반드시 필요하다는 것을 깨달았습니다. 결과물에 대한 판단이 이루어지지 않으면 결과물이 산으로 갈 수 있기 때문입니다. 또한 입력(input)과 출력(output)에 대한 템플릿을 제공하고, 에이전트의 작업 워크플로우를 명시적으로 설계함으로써 매번 유사한 구조와 품질의 결과물을 도출하는 것이 중요하다는 점을 배웠습니다.
🔥 Try
과제 제출 보단 학습에 의미를 두기
욕심이 많아서일까요… 자꾸만 과제를 pass 받고 싶다는 생각에 자꾸만 무리를 하게 되는 것 같습니다.
사실 과제를 통과하지 못하더라도 조금이라도 배운 것이 있다면 혹은 어제보다 더 나은 오늘의 내가 됐다면 그 자체만으로 충분히 의미가 있는데, 막상 과제 pass를 받지 못하면 실패라고 느껴져, 스스로를 괜히 옥죄이게 되는 것 같습니다.
그런 마음 때문에 오히려 스스로에게 지나친 부담을 주고, 무리하게 되는 것 같습니다.
과제 pass에 대한 압박에서 벗어나, 양질의 지식을 흡수하고 그것을 내 것으로 만드는 데 집중해야겠습니다.
마무리하면서
지난주 과제에서 0.5 BP를 받았습니다 😊
예상치 못한 결과라 더욱 기뻤고, 수료하기 전에는 BP 1번을 받아보고 싶다는 의지도 생겼습니다 ㅎ.ㅎ
아직 항해 초반이지만, 이전과 달리 변화된 부분도 있고 얻는 것도 많아, 항해 플러스를 신청하기 잘 했다는 생각이 듭니다. 남은 8주 동안에도 지금처럼 열심히 참여하여 많은 것을 배우고 얻어가기 위해 노력해야겠습니다.🔥
