[SK네트웍스 Family 엔코아AI캠퍼스] AI 오케스트레이션 캠프 1기_3개월차 회고

About this offer

3개월차 교육을 시작한 지도 벌써 3개월이 지났다. 이번 달에는 크게 CI/CD 와 Multi-Agent System 에 대해서 배웠다. CI/CD에서는 Docker, GitHub Actions, AWS를 이용해 코드가 실제 환경까지 배포되는 과정과 반복 작업을 자동화하는 방법을 배웠고, Multi-Agent에서는 하나의 목표를 여러 Task로 나누고 여러 Agent가 역할을 나눠 작업하도록 만드는 방법을 배웠다. 처음에는 두 주제가 크게 관련 없어 보였다. 하지만 한 달 동안 배운 내용을 다시 정리해보니 결국 둘 다 작업을 더 잘하기 위해 필요한 구조를 명시적으로 만드는 방법 이라는 공통점이 있었다. 사람이 일을 하든, 소프트웨어가 실행하든, AI가 작업하든 결국 비슷한 질문이 필요하다. 왜 하는가? ↓ 무엇을 해야 하는가? ↓ 어떻게 나눌 것인가? ↓ 누가 할 것인가? ↓ 어떤 순서와 관계로 실행할 것인가? ↓ 무엇을 주고받을 것인가? ↓ 현재 어디까지 진행됐는가? ↓ 실행 ↓ 잘했는지 확인 ↓ 다음 작업에 반영 이번 달에는 이런 질문들이 실제 기술에서는 어떤 개념과 구조로 표현되는지를 많이 확인했던 것 같다. 1. 배운 내용 CI/CD CI와 CD CI(Continuous Integration) 는 코드 변경을 지속적으로 통합하면서 Build와 Test를 통해 문제가 있는지를 빠르게 확인하는 과정이다. Code Change ↓ Integration ↓ Build ↓ Test ↓ Feedback CD 는 CI를 통과한 결과물을 배포 가능한 상태로 유지하거나 실제 실행 환경까지 전달하는 과정이다. Continuous Delivery → 언제든 배포할 수 있는 상태까지 자동화 Continuous Deployment → 검증된 변경을 실제 환경까지 자동 배포 결국 CI/CD는 코드 변경 ↓ 검증 ↓ Build ↓ 배포 가능한 결과물 ↓ 실제 실행 환경 이라는 과정을 반복 가능하게 만드는 것이라고 볼 수 있다. GitHub Actions CI/CD를 실제로 구성할 때는 GitHub Actions를 이용했다. 기본 구조는 Workflow → 전체 자동화 흐름 Event / Trigger → 언제 실행할 것인가 Job → 어떤 작업 묶음을 실행할 것인가 Step → 실제 실행 단위 Runner → 어디에서 실행할 것인가 정도로 나눌 수 있다. 예를 들어 코드가 Push되면 Push ↓ GitHub Actions ↓ Test ↓ Docker Image Build ↓ Registry Push ↓ Deploy 같은 작업을 자동으로 실행할 수 있다. 직접 배포할 때는 사람이 알고 있던 순서대로 명령을 실행하면 됐지만 자동화하려면 무엇을 언제 어떤 조건에서 실행할지를 명시적인 Workflow로 만들어야 한다. 그래서 CI/CD는 단순히 명령을 대신 실행하는 것보다 사람이 반복해서 하던 작업 절차를 시스템이 실행할 수 있는 형태로 바꾸는 것 에 가까운 것 같다. Docker와 AWS 배포 Docker를 이용하면 애플리케이션과 실행에 필요한 Runtime, Dependency 등을 이미지 형태로 묶을 수 있다. Application + Runtime + Dependency ↓ Docker Image 만들어진 이미지는 Registry에 저장하고 실제 서버에서 가져와 실행할 수 있다. 이번에는 AWS의 여러 서비스를 연결해 실제 배포 과정도 경험했다. OIDC / IAM → GitHub Actions가 AWS에서 사용할 권한 ECR → Docker Image 저장 EC2 → 애플리케이션 실행 RDS → 영속 데이터 저장 ElastiCache → Redis와 같은 인메모리 저장소 SSM → 서버에 명령 전달 및 관리 전체 흐름은 대략 GitHub ↓ GitHub Actions ↓ AWS 인증 ↓ Build / Test ↓ Docker Image ↓ ECR ↓ EC2 ↓ Container 실행 ↓ RDS / Redis 등과 연결 ↓ Service 로 볼 수 있었다. 각 서비스를 따로 배우는 것보다 실제 배포 흐름에서 어떤 역할을 담당하는지 보니 훨씬 단순하게 이해할 수 있었다. Kubernetes와 GitOps도 개념적으로 접했지만 이번 달에는 실제 활용보다는 이런 방식으로 실행 상태를 관리할 수 있다는 정도로 이해했다. Multi-Agent System Multi-Agent와 Orchestration Multi-Agent 자체는 크게 낯설지 않았다. AI를 어느 정도 일을 빠르게 처리할 수 있는 작업자라고 생각하면 Single Agent → 한 명에게 일을 맡긴다. Multi-Agent → 여러 명에게 일을 나눠 맡긴다. Orchestration → 여러 작업자를 하나의 목표에 맞게 조율한다. 정도로 생각할 수 있다. 실제로는 Goal ↓ Task Decomposition ↓ Task 관계 정의 ↓ Agent Assignment ↓ Execution ↓ Communication ↓ Result Merge ↓ Evaluation 같은 구조가 필요하다. 결국 Multi-Agent에서 중요한 것은 Agent의 숫자보다 작업을 어떻게 나누고 여러 실행 주체를 어떻게 연결할 것인가 라고 생각한다. Role과 Task Agent를 여러 개 사용할 때는 Role 과 Task 를 구분할 수 있다. Role → 이 Agent가 어떤 책임을 가지는가 Task → 지금 실제로 수행해야 하는 일 예를 들면 Role: Researcher Task: 특정 기술 조사 Role: Reviewer Task: 조사 결과 검증 처럼 볼 수 있다. 사람이 팀에서 맡고 있는 역할과 지금 처리해야 하는 일이 다른 것과 크게 다르지 않다. Task Decomposition과 Dependency 큰 일을 여러 Agent에게 맡기려면 먼저 Task를 나눠야 한다. Goal ↓ Task Decomposition ↓ Task A Task B Task C 하지만 Task를 나눴다고 모두 동시에 실행할 수 있는 것은 아니다. A → B → C 처럼 앞의 결과가 필요하다면 순차적으로 실행해야 한다. 반대로 → A → Input → B → Merge → C → 처럼 서로 독립적이라면 병렬로 처리할 수 있다. 따라서 Multi-Agent에서 먼저 봐야 하는 것은 Agent의 수보다 Task 사이의 Dependency 다. Goal ↓ Task Decomposition ↓ Dependency ↓ Execution Strategy ↓ Agent Assignment 작업 관계는 Graph로 표현할 수 있고, 순환이 없는 의존 관계라면 DAG(Directed Acyclic Graph) 형태로 볼 수도 있다. Workflow Pattern Task를 어떤 관계로 실행할지에도 반복되는 Pattern이 있다. Sequential / Chain A → B → C 앞 작업의 결과를 다음 작업이 사용한다. Parallel / Fan-out, Fan-in → A → Input → → B → Merge → C → 독립적인 작업을 동시에 수행하고 마지막에 합친다. Router → Agent A Input → Router → Agent B → Agent C 입력이나 상태에 따라 적절한 실행 경로를 선택한다. Evaluator–Optimizer Generate ↓ Evaluate ↓ Pass? ─ YES → Result │ NO ↓ Improve ↺ 결과를 평가하고 기준을 만족하지 못하면 다시 개선한다. 처음부터 특별히 새로운 개념이라기보다 작업 사이의 관계에 이미 존재하던 구조들에 이름이 붙어 있는 느낌 에 가까웠다. Contract와 Interface Agent들이 독립적으로 동작하려면 서로 무엇을 주고받을지에 대한 약속이 필요하다. Task Input Constraints Expected Output Status Error Metadata 같은 정보를 정해진 형태로 전달할 수 있다. Agent A ↓ Contract / Interface ↓ Agent B 이 부분 역시 기존 소프트웨어의 Interface나 Contract 개념과 크게 다르지 않았다. 내부 구현이 달라져도 Contract가 유지된다면 다른 구성요소에 주는 영향을 줄일 수 있다. 결국 Agent를 독립적으로 나눈다는 것도 경계를 명확하게 정의하는 문제 라고 생각할 수 있다. Router, Supervisor, Handoff 여러 Agent 사이에서 작업을 전달하거나 관리하는 방법도 나눌 수 있다. Router "누구에게 보낼 것인가?" 입력이나 현재 상태를 보고 적절한 Agent를 선택한다. → Research Input → Router → Coding → Review Supervisor "전체 작업을 어떻게 조율할 것인가?" 전체 목표와 진행 상태를 보고 여러 Agent에게 Task를 배분하거나 다음 행동을 결정한다. ┌→ Agent A Goal → Supervisor → Agent B └→ Agent C Handoff "현재 하던 작업을 누구에게 넘길 것인가?" 현재 Agent가 다른 Agent가 더 적합하다고 판단하면 필요한 Context와 함께 작업의 제어권을 넘긴다. Agent A ↓ 작업 수행 ↓ 다른 Agent가 더 적합 ↓ Handoff ↓ Agent B 정리하면 Router → 선택 Supervisor → 전체 조율 Handoff → 작업과 제어권 이전 정도로 볼 수 있다. 사람이 여러 명 모여서 일할 때도 자연스럽게 생기는 역할들이라 개념 자체가 어렵게 느껴지지는 않았다. State와 Context 여러 Agent가 작업하면 전체 Workflow가 현재 어떤 상태인지 관리해야 한다. Global State 현재 Task 완료된 Task Agent별 Result Error 다음 실행 대상 하지만 모든 정보를 모든 Agent에게 전달할 필요는 없다. Global State ↓ 필요한 정보 선택 ↓ Local Context ↓ Agent 각 Agent가 현재 작업을 처리하는 데 필요한 정보만 전달할 수 있다. 단일 Agent에서도 생각했던 문제지만 Multi-Agent에서는 실행 주체가 늘어나면서 누가 어떤 정보를 알아야 하는가 가 더 명시적인 문제가 되는 것 같다. A2A와 MCP 여러 Agent와 Tool을 연결하면서 A2A 와 MCP 의 역할도 볼 수 있었다. A2A → Agent ↔ Agent MCP → Agent ↔ Tool / Resource 하나의 시스템에서는 Agent A │ A2A ↓ Agent B │ MCP ↓ Tool / API / Data 처럼 함께 사용할 수도 있다. 서로 경쟁하는 기술이라기보다 연결하는 대상이 다른 도구 로 보는 편이 자연스럽다. Trace와 Evaluation Agent가 여러 개가 되면 최종 결과만 봐서는 내부에서 어떤 일이 있었는지 알기 어렵다. 그래서 Trace를 통해 어떤 Agent가 실행됐는가 어떤 Task를 수행했는가 어떤 Tool을 사용했는가 어디에서 실패했는가 얼마나 많은 비용과 시간이 들었는가 같은 실행 과정을 확인할 수 있다. Evaluation도 결과 하나만 보는 것이 아니라 Result Quality → 최종 결과가 좋은가 Task Quality → 각 Agent가 맡은 일을 잘했는가 Trajectory → 실행 경로가 적절했는가 Latency → 시간이 적절한가 Cost → 자원을 얼마나 사용했는가 Reliability → 반복해도 안정적인가 처럼 여러 기준을 사용할 수 있다. Agent가 늘어나면 능력뿐 아니라 관찰하고 평가해야 하는 범위도 같이 늘어난다. 결국 모두 작업을 잘하기 위한 도구 이번 달에 배운 내용을 다시 생각해보면 CI/CD와 Multi-Agent는 구체적으로 전혀 다른 기술이지만 더 위에서는 비슷한 질문에 답하고 있었다. 사람이든 AI든 소프트웨어든 일을 하려면 결국 왜 하는가? ↓ 무엇을 해야 하는가? ↓ 어떻게 나눌 것인가? ↓ 누가 할 것인가? ↓ 어떤 순서와 관계로 실행할 것인가? ↓ 어떤 정보를 주고받을 것인가? ↓ 현재 상태는 무엇인가? ↓ 실행 ↓ 잘했는지 확인 ↓ 다음 작업에 반영 이 필요하다. 이번 달에 배운 개념들을 여기에 대응하면 Goal / Intent → 왜 하는가 Task → 무엇을 해야 하는가 Task Decomposition → 어떻게 나눌 것인가 Dependency / DAG → 작업들은 어떤 관계인가 Role / Agent → 누가 할 것인가 Workflow Pattern → 어떤 흐름으로 실행할 것인가 Contract / Interface → 무엇을 어떤 형태로 주고받을 것인가 State → 지금 어디까지 진행됐는가 Context → 현재 작업에 무엇을 알아야 하는가 Router → 누구에게 보낼 것인가 Supervisor → 전체를 어떻게 조율할 것인가 Handoff → 다른 실행 주체에게 어떻게 넘길 것인가 A2A → Agent와 Agent가 어떻게 협력할 것인가 MCP → 외부 Tool과 Resource를 어떻게 사용할 것인가 Trace → 실제로 무엇이 일어났는가 Evaluation → 잘했는가 정도로 볼 수 있다. CI/CD는 이 중에서 특히 이미 방법이 정해진 반복 작업을 어떻게 안정적으로 실행할 것인가 에 대한 도구라고 생각할 수 있다. 사람이 반복하던 작업 ↓ 명시적인 Workflow ↓ 자동 실행 Multi-Agent는 한 주체가 모두 처리하기 어려운 작업을 어떻게 나누고 여러 실행 주체가 협력하게 할 것인가 에 더 가깝다. 복잡한 Goal ↓ Task 분리 ↓ 역할 분배 ↓ 관계 정의 ↓ 협력 ↓ 결과 결국 이번 달에 배운 기술들은 새로운 작업 원리를 만든다기보다 사람이 일을 잘하기 위해 원래 필요했던 구조들을 소프트웨어와 AI가 실행할 수 있는 형태로 명시한 것 처럼 보인다. AI가 특별해서 완전히 새로운 질문이 생긴 것이 아니라, 왜 하는가? 무엇을 해야 하는가? 누가 하는 것이 좋은가? 어떤 정보를 알아야 하는가? 어떻게 협력할 것인가? 잘했는지는 어떻게 알 것인가? 같은 질문에 답하는 방식이 조금씩 달라지고 있는 것 같다. 2. 소감 이번 달에는 새로운 개념을 이해하는 데 어렵거나 헷갈린다는 느낌은 거의 없었다. 단일 Agent를 배우면서 이미 역할, Task, Context, State, Tool, Trace, Evaluation 등에 대해서 많이 생각했고, AI를 어느 정도 똑똑한 사람이 일을 빠르게 처리해주는 것처럼 생각하고 있었기 때문에 Multi-Agent의 개념들도 대부분 바로 이해할 수 있었다. Supervisor는 여러 작업자를 관리하는 사람, Handoff는 더 적절한 사람에게 일을 넘기는 것, Contract는 서로 일을 주고받기 위한 약속이라고 생각하면 특별히 새롭게 느껴질 부분이 많지 않았다. 처음에는 내가 이전에 비슷한 생각을 많이 해봤기 때문에 쉬운 것이라고 생각했다. 그런데 이번 달 내용을 다시 정리하면서 꼭 그것만은 아닌 것 같다는 생각도 들었다. Role, Task, Workflow, Supervisor, Handoff, Contract 같은 개념은 결국 사람이 여러 명이서 일을 잘하려고 해도 자연스럽게 필요한 것들 이다. 누가 어떤 일을 할지 정하고, 일을 작은 단위로 나누고, 순서를 정하고, 관리자가 전체 상황을 보고, 더 적절한 사람이 있으면 일을 넘기고, 서로 결과를 주고받기 위한 약속을 만드는 것은 AI가 없어도 원래 존재했던 문제다. 소프트웨어도 마찬가지다. 모듈 사이에는 Interface가 필요하고, 여러 작업에는 Dependency가 생기고, 반복 작업에는 Workflow가 필요하다. AI가 들어오면서 완전히 새로운 방식으로 일이 바뀐다기보다 기존 작업 구조 안에 스스로 판단할 수 있는 새로운 실행 주체가 추가되고 있다는 느낌 이 더 강했다. CI/CD도 비슷했다. Test, Build, Image 생성, 배포를 사람이 직접 할 수도 있지만 방법이 충분히 명확하고 반복된다면 사람이 매번 할 이유가 없다. 사람이 판단하며 반복 ↓ 과정을 명시 ↓ 자동화 라는 흐름이다. 어떻게 보면 Multi-Agent도 같은 방향에 있다. 사람이 직접 여러 AI에게 하나씩 일을 나눠주고 결과를 확인할 수도 있지만 역할과 작업 흐름이 어느 정도 반복된다면 그 관계 역시 시스템으로 만들 수 있다. 이렇게 생각하니 이번 달에 배운 여러 기술들이 모두 사람이 직접 하던 판단과 작업 중 어떤 부분을 명시적으로 만들고 시스템에 맡길 수 있는가 라는 문제로도 보였다. 그래서 새로운 기술을 볼 때 이름이나 사용법을 외우는 것보다 이 기술은 일을 하는 과정에서 어떤 질문에 답하기 위해 필요한가? 를 먼저 생각하는 방식이 나에게는 더 잘 맞는 것 같다. 기술이 달라져도 해결하려는 질문이 같으면 전체 구조에서 어디에 들어가는지도 금방 이해할 수 있다. 앞으로는 새로운 개념을 더 많이 아는 것보다 실제 작업을 하나 선택해서 이런 구조가 어디까지 도움이 되는지 직접 확인해보는 것이 더 중요할 것 같다. 생각으로는 자연스럽게 연결되지만 실제로 사용했을 때도 항상 효과적인지는 별개의 문제이기 때문이다. 3. KPT Keep 기술보다 먼저 "왜 필요한가"를 생각하기 새로운 개념을 배울 때 무엇인가? 만 보는 것보다 왜 필요한가? 어떤 문제를 해결하는가? 를 먼저 생각하는 방식은 계속 유지하고 싶다. 이번 달에도 Router → 적절한 실행 주체 선택 Handoff → 작업 이전 Contract → 협업을 위한 약속 CI/CD → 반복 실행의 자동화 처럼 목적을 기준으로 보니 새로운 개념을 빠르게 이해할 수 있었다. 이미 알고 있는 작업 구조와 연결하기 AI의 개념을 AI 안에서만 생각하지 않고 사람이나 기존 소프트웨어가 일하는 방식과 비교하는 것이 도움이 됐다. 구체적인 구현은 달라도 어떤 문제가 반복되는지를 찾으면 전체 구조를 이해하기 쉬웠다. 직접 실행해서 확인하기 AWS 배포와 GitHub Actions처럼 실제로 해봤을 때 각 기술의 역할이 더 명확해지는 경우가 많았다. 생각으로 이해한 것과 실제로 효과가 있는 것은 다를 수 있기 때문에 작은 범위라도 직접 실행하는 것은 계속 유지하고 싶다. Problem 생각보다 구현과 검증에 훨씬 많은 시간이 든다 구조 자체는 비교적 빠르게 이해하고 설계할 수 있지만 실제 코드로 만들고 여러 상황에서 정상적으로 동작하는지 확인하려면 훨씬 많은 시간이 필요하다. AI를 사용하면 만드는 속도는 빠르지만 사람이 결과를 이해하고 검증하는 속도는 그만큼 빠르게 늘어나지 않는다. 사용할 수 있는 도구가 너무 많다 Framework, A2A, MCP, Observability, Evaluation 등 사용할 수 있는 기술이 굉장히 많다. 문제는 각각 좋은 기술이라는 이유만으로 추가하면 시스템이 실제 필요 이상으로 복잡해질 수 있다는 것이다. 어디까지 기존 기술을 사용하고 어디부터 직접 만들지 결정하기 어렵다 이미 잘 만들어진 도구를 사용하면 빠르지만 내가 직접 보고 싶은 구조가 내부에 숨겨질 수 있고, 전부 직접 구현하면 이미 해결된 문제에 많은 시간을 쓰게 된다. 현재 목적에서 무엇을 확인하려는지를 기준으로 선택할 필요가 있다. 생각하는 범위가 계속 커진다 하나의 문제를 생각하면 자연스럽게 다음 문제도 보인다. Agent ↓ State ↓ Trace ↓ Evaluation ↓ Policy ↓ Memory ... 계속 연결해서 생각하는 것은 도움이 되지만 실제 실험 전에 범위가 지나치게 커지지 않게 조절할 필요가 있다. Try 1. 작업의 "왜"부터 적어보기 새로운 기술이나 구조를 선택하기 전에 왜 이 작업을 하는가? ↓ 무엇이 성공인가? ↓ 무엇을 해야 하는가? 부터 정리해보려고 한다. 목적이 명확해야 이후의 Task, Role, Workflow도 결정할 수 있다. 2. Task를 먼저 구조화하고 기술을 나중에 선택하기 Goal ↓ Task ↓ Dependency ↓ Workflow ↓ Role ↓ Executor ↓ Technology 순서로 보는 습관을 만들고 싶다. 특히 Multi-Agent 자체를 목적으로 사용하지 않고 Task 구조상 필요할 때 선택하려고 한다. 3. 작은 구조부터 실제로 비교하기 Single Agent ↓ 작은 Workflow ↓ Multi-Agent 로 단계적으로 늘리면서 품질 시간 비용 안정성 이 실제로 어떻게 달라지는지 비교해보고 싶다. 4. 기존 기술은 해결하려는 문제를 기준으로 선택하기 어떤 문제가 있는가? ↓ 이미 해결한 기술이 있는가? ↓ 현재 목적에 맞는가? ↓