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

 

8월 4주차는 AI Agent를 실제 시스템에 어떻게 연결할 것인가를 한 단계 더 구체적으로 이해하게 된 주였다.

앞서 배웠던 Workflow와 AI Agent의 차이를 팀 미니프로젝트에 적용해보고, Git을 이용한 협업과 코드 통합을 경험했다. 이후에는 Tool Calling → MCP → 외부 API 연동 → RAG와 벡터 검색으로 학습 범위가 자연스럽게 확장됐다. (랩보다 AI 더 잘해지기)

특히 이번 주에는 단순히 새로운 기술을 하나씩 배우는 것보다, 각각의 기술이 실제 서비스에서 어떤 역할을 하고 서로 어떻게 연결되는지를 생각하게 된 점이 가장 컸다.

---

1. 이번 주 학습 요약

이번 주 초에는 Workflow와 AI Agent를 실제 주차 시스템에 적용하면서 두 방식의 차이를 비교했다.

Workflow는 개발자가 정해놓은 순서대로 작업을 수행하는 방식이고, AI Agent는 LLM이 상황에 따라 어떤 Tool을 사용할지 판단하는 방식이다. 예를 들어 차량번호를 확인하고 등록 여부에 따라 주차장 문을 여는 것처럼 절차가 명확한 업무라면 Workflow가 적합할 수 있고, 상황에 따라 여러 Tool을 선택해야 하는 업무라면 Agent가 더 적합할 수 있다는 점을 이해했다. (랩보다 AI 더 잘해지기)

동시에 팀 프로젝트를 진행하면서 Git merge, 코드 충돌, 역할 분담, API와 Tool의 인터페이스도 경험했다. 특히 AI 코딩 도구를 여러 명이 함께 사용하려면 Plan → Sub Plan → 상세 MD → 코드 작성 → 코드 리뷰 → 리팩토링처럼 개발 기준을 먼저 정하는 것이 중요하다는 점을 배웠다. (랩보다 AI 더 잘해지기)

주 후반에는 AI Agent가 Tool을 선택하고 실행하는 Tool Calling을 학습하고, MCP Server를 통해 Tool을 독립적으로 관리하고 공유하는 구조까지 확장했다. 이후 팀에서는 실제 기상청 공공 API를 연결한 날씨 MCP 서버를 구현하면서 외부 API와 AI 시스템을 연결하는 과정도 경험했다. (랩보다 AI 더 잘해지기)

마지막으로 RAG에서는 임베딩, 청크, 벡터 데이터베이스, 유사도 검색의 개념을 다시 정리하고 이를 MCP Tool과 연결하는 구조까지 학습했다. (랩보다 AI 더 잘해지기)

결국 이번 주의 흐름을 하나로 정리하면 다음과 같다.

Workflow와 Agent 이해 → Tool 설계 → Tool Calling → MCP → 외부 API 연동 → RAG·벡터 검색

---

2. 가장 인상 깊었던 학습

"AI Agent를 만드는 것"보다 "AI가 무엇을 하게 할 것인가"가 중요했다

이번 주 가장 인상 깊었던 부분은 AI Agent를 바라보는 관점이 조금 달라졌다는 것이다.

처음에는 AI Agent라고 하면 LLM에게 질문을 던지고 답변을 받아오는 프로그램 정도로 생각했다.

하지만 Tool Calling을 학습하면서 실제 Agent의 역할은 훨씬 구체적이라는 것을 알게 됐다.

사용자 질문
   ↓
사용 가능한 Tool 확인
   ↓
LLM이 사용할 Tool 선택
   ↓
arguments 생성
   ↓
Tool 실행
   ↓
실행 결과 전달
   ↓
LLM이 최종 답변 생성

즉 LLM이 모든 일을 직접 하는 것이 아니라, 무엇을 해야 할지 판단하고 실제 작업은 Tool이 수행하는 구조였다. (랩보다 AI 더 잘해지기)

이렇게 생각하니 MCP나 RAG도 각각 따로 떨어진 기술이 아니라 하나의 AI 시스템을 구성하는 요소라는 점이 조금씩 연결되기 시작했다.

---

3. Workflow와 AI Agent를 비교하면서 생긴 생각

이번 주 초 주차 시스템을 설계하면서 특히 기억에 남았던 것은 AI를 무조건 사용하는 것이 좋은 설계는 아니라는 것이었다.

예를 들어,

차량번호 확인
↓
DB 조회
↓
등록 여부 확인
↓
문 열기

처럼 과정과 조건이 명확하다면 굳이 LLM에게 매번 판단을 맡길 필요가 없다.

반대로 사용자의 요청에 따라 여러 Tool 중 하나를 선택하거나, 상황에 따라 다음 행동이 달라지는 문제라면 AI Agent가 더 적합할 수 있다. (랩보다 AI 더 잘해지기)

예전에는 새로운 기술을 배우면 "이 기술을 어디에 사용할 수 있을까?"부터 생각했다면, 이번 주에는 조금 다르게 생각하게 됐다.

"이 문제에 정말 AI가 필요한가?"

이 질문을 먼저 해야 한다는 것이다.

AI를 사용하는 것 자체가 목적이 아니라 문제의 성격에 맞는 구조를 선택하는 것이 개발자의 역할이라는 점을 배웠다.

---

4. 가장 어려웠던 부분과 해결 과정

① AI가 만들어준 코드가 항상 좋은 코드는 아니었다

이번 주 팀 프로젝트에서는 여러 사람이 AI 코딩 도구를 활용했다.

AI를 사용하면 기능을 빠르게 만들 수 있다는 장점이 있지만, 여러 사람이 동시에 사용하면 오히려 문제가 생길 수도 있었다.

사람마다 AI에게 요청하는 방식이 다르면 코드 구조나 변수명, 파일 구성 등이 달라질 수 있기 때문이다.

그래서 단순히

"이 기능 만들어줘."

라고 요청하는 것보다,

• 프로젝트 구조
• 담당 영역
• 입력과 출력
• 사용해야 하는 Tool
• 수정하면 안 되는 영역
• 코드 작성 기준

등을 먼저 명확하게 전달해야 했다. (랩보다 AI 더 잘해지기)

결국 AI에게 코드를 잘 시키는 능력도 개발 과정의 일부라는 생각이 들었다.

그리고 더 중요한 것은 AI가 만든 결과물을 그대로 사용하는 것이 아니라 직접 읽고 검수할 수 있어야 한다는 것이었다.

---

② Git merge 과정에서 협업의 현실을 경험했다

혼자 개발할 때는 내가 어떤 파일을 수정했는지 알고 있기 때문에 Git이 크게 어렵지 않았다.

하지만 팀원들이 각각 작업한 내용을 하나의 브랜치에 통합하는 과정에서는 이야기가 달랐다.

실제로 config.py 같은 설정 파일이나 불필요하게 추적된 파일 때문에 충돌이 발생할 수 있었고, 단순히 충돌 표시를 지우는 것이 아니라 각 변경사항이 왜 생겼는지 확인한 뒤 어떤 코드를 남길지 판단해야 했다. (랩보다 AI 더 잘해지기)

이번 경험을 통해 Git은 단순히 코드를 저장하고 올리는 도구가 아니라 여러 명의 개발자가 하나의 코드를 함께 관리하기 위한 협업 도구라는 것을 조금 더 현실적으로 이해하게 됐다.

---

③ 기상청 API는 생각보다 단순하지 않았다

주 후반에는 팀에서 날씨 MCP 서버를 담당하면서 기상청 공공 API를 직접 연결했다.

처음에는 현재 날씨를 API 하나 호출하면 간단하게 만들 수 있을 것이라고 생각했다.

그런데 실제로 확인해보니 초단기실황 API에는 기온, 습도, 강수량 등의 정보는 있지만 원하는 하늘상태 SKY 정보가 없었다.

결국 초단기실황과 초단기예보를 함께 호출해서 필요한 정보를 조합해야 했다. (랩보다 AI 더 잘해지기)

이 과정에서 API를 사용할 때 단순히 "API를 호출한다"에서 끝나는 것이 아니라,

어떤 데이터를 제공하는 API인지 확인하고, 필요한 데이터를 얻기 위해 어떤 API들을 조합해야 하는지 파악하는 과정

이 중요하다는 것을 알게 됐다.

---

④ Docker 환경 문제도 직접 확인했다

PostgreSQL과 pgvector 환경을 확인하는 과정에서는 Docker 컨테이너와 포트 연결 구조도 다시 확인했다.

localhost:5433
      ↓
Docker
      ↓
PostgreSQL 5432
      ↓
agent_db

처럼 로컬에서 접근하는 포트와 컨테이너 내부 포트가 다를 수 있다는 점을 실제 프로젝트 환경에서 확인했다. (랩보다 AI 더 잘해지기)

이런 부분은 코드만 봐서는 이해하기 어려웠는데 실제 개발환경에서 확인하니 조금 더 명확해졌다.

---

5. 이번 주에 새롭게 이해한 점

이번 주를 지나면서 AI 오케스트레이션을 바라보는 시각이 가장 많이 달라졌다.

처음에는 각각의 기술을 따로 생각했다.

LLM
AI Agent
Tool
MCP
RAG
Database
API

그런데 이번 주에는 이것들이 하나의 시스템 안에서 연결될 수 있다는 것이 조금씩 보이기 시작했다.

예를 들어,

사용자
 ↓
AI Agent
 ↓
Tool 선택
 ↓
MCP Server
 ↓
외부 API / Database
 ↓
검색 결과
 ↓
LLM
 ↓
최종 답변

과 같은 구조를 생각할 수 있게 됐다.

여기에 RAG가 들어가면 외부 데이터를 단순히 조회하는 것을 넘어 우리 서비스가 가지고 있는 문서를 검색하고 그 결과를 LLM의 답변 근거로 사용하는 구조도 만들 수 있다. (랩보다 AI 더 잘해지기)

특히 RAG를 다시 공부하면서 임베딩에 대한 이해도 조금 달라졌다.

임베딩은 단순히 텍스트를 숫자로 바꾸는 것이 아니라 문장의 의미를 벡터로 표현하는 과정이고, 이 벡터를 이용해 질문과 의미적으로 비슷한 데이터를 검색할 수 있다. 또한 문서를 저장할 때 사용한 임베딩 모델과 검색할 때 사용하는 모델의 일관성도 중요하다는 것을 알게 됐다. (랩보다 AI 더 잘해지기)

---

6. 현재 나의 상태

이번 주를 마치면서 적어도 AI Agent가 실제 서비스에서 어떤 구조로 동작하는지 설명하는 수준은 이전보다 나아졌다.

특히 다음과 같은 개념들은 서로 연결해서 생각할 수 있게 됐다.

• Workflow와 AI Agent의 차이
• Tool Calling의 동작 과정
• Tool의 조회와 Action 역할
• MCP Server의 필요성
• 외부 API와 MCP 연결
• Structured Output
• RAG의 기본 구조
• 임베딩과 벡터 검색
• PostgreSQL + pgvector 구조

하지만 아직 부족한 부분도 분명하다.

가장 큰 문제는 코드를 봤을 때 모든 동작을 바로 설명할 수 있는 수준은 아니라는 것이다.

특히 AI 코딩 도구가 작성한 코드를 빠르게 받아들이는 것과 그 코드의 구조와 동작 원리를 직접 이해하는 것은 완전히 다른 문제라는 것을 느꼈다.

또 MCP, RAG, Agent를 각각 이해하는 것과 이들을 하나의 서비스로 직접 연결해 안정적으로 구현하는 것 사이에도 아직 큰 차이가 있다.

---

7. 다음 주에는 무엇을 보완할까?

다음 주부터는 단순히 새로운 기술을 추가로 배우는 것보다 이번 주에 배운 기술을 실제 프로젝트에 적용하면서 이해도를 높이는 것에 집중하고 싶다.

특히 다음 부분을 보완할 계획이다.

① MCP Tool 구조 다시 복습하기

Tool의 입력값과 반환값을 어떻게 설계해야 하는지 다시 확인하고, MCP Server와 Agent 사이에서 데이터가 어떻게 이동하는지 직접 따라가 볼 예정이다.

② RAG 전체 흐름 직접 구현해보기

문서
↓
Chunk
↓
Embedding
↓
Vector DB
↓
Similarity Search
↓
검색 결과
↓
LLM

이 흐름을 코드 단위로 다시 확인하면서 각 단계가 왜 필요한지 이해하는 것이 목표다.

③ AI 코딩 도구를 사용할 때 결과물을 더 많이 읽기

앞으로는 AI에게 코드를 생성시키는 것 자체보다 생성된 코드가 왜 그렇게 작성됐는지 설명할 수 있는가를 기준으로 삼으려고 한다.

특히 프로젝트에서 내가 수정하는 파일뿐만 아니라 팀원이 작성한 코드도 적극적으로 읽어보면서 전체 구조를 이해하는 연습을 해야겠다.

---

8. KPT 회고

Keep

이번 주처럼 새로운 기술을 배울 때 단순히 개념만 외우지 않고 직접 프로젝트 구조에 대입해서 생각하는 방식은 계속 유지하고 싶다.

특히 "이 기술을 어디에 쓰는가?"뿐만 아니라 "정말 이 기술이 필요한가?"를 함께 고민하는 습관을 계속 가져가려고 한다.

Problem

아직 AI 코딩 도구가 작성한 코드를 빠르게 이해하고 검수하는 능력이 부족하다.

또한 MCP, Agent, RAG, Database, API가 연결되면서 시스템 구조가 복잡해질수록 각각의 코드가 어떤 역할을 하는지 한 번에 파악하기 어려운 부분이 있다.

Try

다음 주에는 새로운 코드를 무조건 많이 작성하기보다 하나의 기능을 처음부터 끝까지 따라가 보는 연습을 해보려고 한다.

사용자 입력부터 Agent, Tool, MCP, API 또는 DB, 그리고 최종 응답까지 데이터가 어떻게 이동하는지 직접 확인하면서 전체 흐름을 이해해보겠다.

---

마무리

이번 주는 새로운 기술을 많이 배운 한 주이기도 했지만, 개인적으로는 개발을 바라보는 관점이 조금 바뀐 한 주였다.

예전에는 새로운 기술을 보면 "이걸 어떻게 구현하지?"라는 생각부터 했다면, 이제는 조금씩

"이 문제에는 어떤 구조가 적합하고, 각각의 기술은 어디에 배치해야 할까?"

를 먼저 생각하게 됐다.

특히 AI 코딩 도구를 사용하면서 개발자의 역할이 줄어드는 것이 아니라 오히려 무엇을 만들지 정의하고, 시스템을 설계하고, AI가 만든 결과물을 검증하는 능력이 더 중요해질 수 있겠다는 생각도 들었다. (랩보다 AI 더 잘해지기)

아직 모르는 것도 많고 코드를 읽는 속도도 부족하지만, 적어도 지금은 AI Agent를 단순한 챗봇이 아니라 LLM이 판단하고 Tool과 외부 시스템을 연결해 실제 작업을 수행하는 구조로 바라볼 수 있게 됐다.

이번 주에 배운 내용을 하나씩 직접 구현해보면서, 다음 주에는 "이해했다"에서 "직접 연결해서 만들 수 있다"로 한 단계 더 나아가고 싶다.

조금씩 복잡해지고 있지만, 그만큼 내가 바라볼 수 있는 시스템의 범위도 넓어지고 있다.
이번 주도 잘 버텼고, 다음 주에는 이번 주보다 한 단계 더 이해해보자.

---

핵심 정리

• Workflow와 AI Agent는 같은 문제에도 적용할 수 있지만 적합한 상황이 다르다.
• AI Agent는 Tool Calling을 통해 필요한 Tool을 선택하고 실제 작업을 수행할 수 있다.
• MCP는 Tool을 독립적인 서버 형태로 관리하고 여러 Agent에서 활용할 수 있게 해준다.
• 외부 API를 MCP Tool과 연결하면 실제 데이터를 사용하는 Agent를 만들 수 있다.
• RAG는 외부 문서를 검색하고 그 결과를 LLM에 전달해 근거 기반 답변을 만드는 구조다.
• 임베딩, Chunk, Vector DB, Similarity Search가 RAG의 핵심 구성요소라는 것을 다시 정리했다.
• AI 코딩 도구가 코드를 만들어주더라도 전체 구조를 설계하고 결과물을 검수하는 것은 개발자의 역할이다.
• 이번 주의 가장 큰 변화는 개별 기술을 배우는 것에서 기술들을 연결해 하나의 시스템으로 바라보기 시작했다는 것이다.

해시태그

#SK네트웍스 #엔코아AI캠퍼스 #AI오케스트레이션 #AI에이전트 #MCP #ToolCalling #RAG #벡터검색 #Python #개발자국비지원