Dev Stories

정해진 순서를 따르는 워크플로우를 넘어, 스스로 판단하는 에이전트로 - kode:crew 2편

1편: 코드보다 기획·설계가 중요해진 시대, AIDx로 답하다 — kode:crew


kode:crew는 PO·BA가 브라우저에서 여러 역할의 AI와 함께 기획·설계부터 표준·보안 검토까지 진행하는 AI 웹 포털입니다. 1편에서는 이 서비스를 활용하는 모습을 소개했습니다. 이번에는 서비스를 구현하고 고도화하면서, 백엔드 작동 방식을 정해진 순서를 따르는 워크플로우 방식에서 AI 주도의 에이전트 방식으로 바꾼 이야기를 하려 합니다.



LangGraph·LangChain·Deep Agents 핵심 정리

초기 개발 단계의 워크플로우 방식은 LangGraph로, 지금의 에이전트 방식은 LangChain을 바탕으로 한 Deep Agents로 구현되었습니다. 본격적인 내용에 앞서 이 세 기술의 관계를 간단히 설명하겠습니다.

02-framework-roles-comparison-v8-2-v3.png


LangGraph는 작업의 실행 흐름을 설계하고 제어하는 프레임워크입니다. 작업을 어떤 순서로 실행할지, 어떤 조건에서 반복하거나 다음 작업을 실행할지 구성 가능합니다.


LangChain은 에이전트 개발 프레임워크입니다. 모델이 도구를 호출하고 결과를 바탕으로 다음 행동을 판단하는 에이전트의 기본 구조를 제공합니다. 대화 요약·서브에이전트 호출과 같은 기능을 추가적으로 구성할 수 있으며, 어떤 기능을 사용하고 어떻게 동작시킬지는 개발자가 선택합니다.


Deep Agents는 복잡하고 긴 작업을 수행하는 에이전트를 위해 하네스를 제공하는 라이브러리입니다. 복잡하고 긴 작업을 위해서는 작업 자료를 보관하고, 쌓인 대화를 요약하는 기능들이 필요합니다. Deep Agents는 LangChain을 바탕으로 이러한 기능을 갖추고 있어, 개발자가 이를 하나씩 구성하는 부담을 줄여 줍니다.





1. 워크플로우로 시작한 초기 개발 단계

02-skill-stage-workflow-flat-v8-2-v2.png
초기 워크플로우 방식

초기 개발 단계에서는 PO·BA가 쉽게 쓸 수 있는 서비스를 빠르게 갖추는 데 집중했습니다. kode:crew의 AI들은 Skill이라는 업무 지침을 따라 일합니다. 예를 들어 요구사항을 정리하는 Skill에는 사용자에게 무엇을 물어보고, 어떤 문서를 어떻게 작성해야 하는지가 적혀 있습니다. 처음에는 Skill의 지침에 따라 질문하고 문서를 쓰는 작업은 AI 모델에 맡기고, 작업 간의 흐름을 코드로 구성한 워크플로우를 만들었습니다. 초기 개발 단계에서는 이 방식으로 충분했습니다.


다만 Skill마다 절차와 지침 구성이 달랐기 때문에, Skill 원본을 그대로 쓰지 못하고 각 Skill의 지침을 워크플로우에 맞추어 고친 kode:crew용 수정본을 사용했습니다.





2. 기능 고도화하면서 드러난 한계

03-skill-changes-party-mode-v8-2-v3.png


Skill을 워크플로우에 맞춰 수정하는 방식은 지원할 업무가 늘면서 개발 부담으로 이어졌습니다. 새 Skill을 추가하거나 기존 Skill의 지침이 조금만 바뀌어도, 변경 내용을 확인하고 kode:crew용 수정본에 반영해야 했습니다. 지원하는 Skill이 늘수록 이렇게 관리해야 할 수정본도 많아졌습니다.


서비스를 고도화하면서 새로운 기능도 필요해졌습니다. 대표적인 예가 여러 역할의 AI가 토론하는 '파티모드'입니다. 이를 구현하려면 어떤 AI를 어떤 순서로 호출하고, 앞선 AI의 의견을 다음 AI에게 어떻게 전달할지 정해 워크플로우로 구성해야 했습니다.


결국 Skill의 변경을 계속 반영하는 일과, 여러 AI가 협업하는 흐름을 코드로 설계하는 일에 많은 개발 부담이 생겼고, 에이전트 방식으로의 전환을 고려하였습니다.





3. 워크플로우에서 에이전트로

04-skill-workflow-agent-comparison-v8-2-v5.png

워크플로우 방식과 에이전트 방식 비교


초기 개발 단계처럼 지원하는 Skill이 적고 작업 순서와 분기 조건을 미리 정할 수 있다면 워크플로우도 적합합니다. 하지만 kode:crew는 개발 과정에서 Skill과 기능의 변경이 잦았습니다. 에이전트가 Skill 원본을 직접 읽고 진행하도록 하면, 지침을 워크플로우에 맞춰 고치는 부담을 줄일 수 있다고 보았습니다.


또한 다른 역할의 AI가 필요한 시점과 다음 작업을 에이전트가 판단하도록 하면, AI 간 호출 순서를 일일이 코드로 구성하는 부담을 줄이고 논의 상황에 따라 유연하게 대응할 수 있다고 판단하였습니다.





4. 에이전트 방식 구현에 Deep Agents를 선택한 이유

deep-agents-harness-capabilities-v8-2-v4.png



에이전트 방식의 구현 기반으로 Deep Agents를 선택했습니다. Deep Agents는 모델이 판단하고 도구를 사용하는 에이전트 구조에, 긴 작업을 이어 가는 데 필요한 하네스를 갖추고 있습니다. kode:crew에서는 이를 바탕으로 에이전트가 Skill과 자료를 읽고, 대화 맥락을 유지하며, 다른 역할의 AI에게 작업을 맡기도록 구성했습니다.


LangChain으로 필요한 기능을 직접 구성할 수도 있었습니다. 하지만 Deep Agents는 에이전트에 필요한 실행 기능과 도구 사용·작업 위임을 위한 기본 지침을 하네스로 제공합니다. 이를 활용하면 직접 구성하면서 놓치기 쉬운 부분을 줄이고, kode:crew의 업무에 필요한 도구와 규칙을 다듬는 데 집중할 수 있다고 판단했습니다.





5. Deep Agents를 활용하면서 달라진 개발 방식

agent-transition-gains-v8-2-v7.png



Skill 변경을 반영하는 부담이 줄었습니다. Deep Agents의 파일 도구와 Skill 로딩 기능을 활용해, 필요한 지침과 자료를 직접 찾아 읽도록 했습니다. 기존 도구와 권한으로 수행할 수 있는 업무라면, Skill의 절차가 바뀌어도 워크플로우에 맞추어 Skill을 수정할 필요가 없어졌습니다.


긴 대화를 관리하는 데는 기본 요약 기능을 활용했습니다. 앞선 논의는 요약으로 이어 주고 필요한 자료는 파일 도구로 다시 찾아 읽도록 했습니다. 이에 따라 단계마다 전달할 내용을 정하고 요약 흐름을 개별적으로 구성하는 부담이 줄었습니다.


파티모드는 에이전트 호출 기능을 활용했습니다. 작업에 필요한 정보를 전달하고 결과를 돌려받는 구성이 갖춰져 있어, 호출 구조부터 구현하는 대신 참여할 역할과 토론 규칙을 정하는 데 집중할 수 있었습니다.


Deep Agents가 파일 작업과 대화 요약, 에이전트 호출을 맡아 주면서, 개발팀은 kode:crew에서 어떤 업무를 수행하고 어떤 규칙을 따르게 할지에 더 집중할 수 있었습니다. 예를 들어 파티모드에서는 AI를 호출하고 결과를 받는 구조보다 어떤 역할이 참여하고, 무엇을 논의하며, 결과를 어떻게 정리할지를 다듬는 데 개발 노력을 쓸 수 있었습니다.





6. 이번 전환에서 얻은 선택 기준

이번 전환에서는 두 가지를 결정해야 했습니다. 업무 진행을 워크플로우와 에이전트 중 어디에 맡길지, 그리고 에이전트의 기본 기능을 직접 조합할지 이미 갖춰진 구성을 쓸지입니다. 이때 고려한 점은 다른 업무를 구성할 때도 참고할 수 있습니다.


6.1 업무의 진행 방식 고르기

07-workflow-agent-selection-tradeoffs-v8-2-v4.png


작업 순서와 분기 조건을 미리 정해 코드로 관리할 수 있다면 워크플로우가 적합합니다. 모델이 판단한 결과에 따라 다른 작업으로 넘어가거나 같은 작업을 반복할 수 있지만, 가능한 진행 경로는 코드로 정해 둡니다. 필요한 작업과 순서를 미리 정해 두기 어렵다면, 모델이 상황에 맞춰 다음 작업을 선택하는 에이전트가 적합합니다.


1편에서 소개한 상위 설계나 표준·보안 검토처럼, kode:crew의 Skill 업무는 여러 관점을 함께 고려해야 하는 일이 많습니다. 설계 내용과 검토 결과에 따라 필요한 확인과 보완이 달라져, 진행 경로를 코드로 하나씩 구성하기보다 에이전트가 상황에 맞춰 다음 작업을 선택하며 이어 가는 방식이 적합하다고 봤습니다. Skill이 늘거나 원본이 바뀌어도, 지침을 실행 방식에 맞춰 고쳐 쓰지 않고 에이전트가 그대로 읽게 할 수 있다는 점도 이 선택의 이유였습니다. 다만 판단과 도구 사용을 위한 호출이 늘 수 있으므로, 응답 시간과 비용도 함께 고려해야 합니다.


6.2 에이전트의 기본 구성 고르기

agent-harness-selection-v8-2-v2.png


에이전트의 기본 구성을 고를 때는 필요한 실행 기능을 어디까지 직접 조합하고 유지할지를 봤습니다. 필요한 기능이 적거나 구성을 직접 정하고 싶다면, LangChain의 기본 에이전트에서 시작해 필요한 기능을 붙일 수 있습니다.


kode:crew는 장기 작업을 위한 파일 작업·대화 요약이 함께 필요했으므로 Deep Agents의 하네스에서 시작하는 쪽을 선택했습니다. 하네스를 하나씩 구성 대신, 그 위에서 업무 도구와 규칙을 조정하는 데 집중할 수 있었기 때문입니다.





7. 마치며

초기 개발 단계의 워크플로우 방식은 서비스를 빠르게 개발하기 좋은 선택이었습니다. 그렇지만 지원할 업무와 기능을 늘려 가면서 한계를 느꼈고, 에이전트로 옮겨 가는 계기가 됐습니다.


이번 전환으로 개발 코스트가 들어가는 곳이 달라졌습니다. 업무 판단을 에이전트에게 맡기고 하네스는 Deep Agents를 활용하면서, 에이전트가 업무를 잘 수행할 수 있도록 kode:crew에 추가적으로 필요한 기능을 다듬는 데 집중할 수 있었습니다.


kode:crew를 통해 PO·BA가 이런 내부 구조를 신경 쓰지 않고도 AI와 이야기하며 요구사항과 설계를 다듬고 문서를 완성하는 일에 집중할 수 있기를 바랍니다. 이를 뒷받침할 수 있도록 kode:crew의 실행 환경도 계속 보완해 나가겠습니다.





8. 참고 자료

양예준

안녕하세요. IT부문 IT전략본부에서 AIDD 플랫폼 개발 중인 양예준입니다.

←이전 글