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

 

9월 2주는 두 번째 미니프로젝트인 법률 AI Agent 서비스 ‘LawPath’를 실제 서비스 형태로 통합하고 최종 발표까지 마무리한 주였다.

주 초반에는 Frontend와 Backend, MCP, Database를 연결하면서 여러 기능을 하나의 흐름으로 맞추는 데 집중했고, 중반에는 결과 저장과 질의 이력, 상담사례 검색, 상태 처리 등을 추가했다. 그리고 마지막에는 최종 발표를 진행하면서 프로젝트를 마무리했다.

주 후반에는 미니프로젝트에서 한 단계 더 나아가 Docker, Docker Compose, MCP HTTP 통신, Docker Hub 등을 학습하면서 지금까지 배운 기술을 실제 배포 가능한 구조로 연결하는 과정까지 경험했다. (랩보다 AI 더 잘해지기)

---

1. 이번 주 학습 요약

이번 주의 학습 흐름을 크게 나누면 다음과 같다.

① 법률 AI Agent 프로젝트 통합

• Frontend ↔ Backend ↔ Agent ↔ MCP ↔ Database 연결
• 법령·상담사례·판례 검색
• 입력 정보 충분성 판단 및 추가 질문
• 분석 결과 저장 및 질의 이력
• API 요청·응답 구조 정리
• Mock 데이터와 실제 API 구분

② LawPath 최종 완성 및 발표

• Frontend 최종 수정
• 사용자 흐름 점검
• 검색 결과 및 근거자료 표시
• 테스트 데이터셋 및 테스트 실행기 구성
• 발표자료와 시연 준비
• 팀원들의 작업을 develop 브랜치로 통합

③ Docker 기반 서비스 구성

• Dockerfile과 Docker Compose
• 환경변수와 .env
• Docker Hub
• MCP의 STDIO → HTTP 전환
• Frontend / Backend / Travel MCP / Policy MCP 컨테이너 구성
• 컨테이너 간 통신 및 End-to-End 테스트

결국 이번 주는 “기능을 하나씩 구현하는 단계”에서 “여러 기술을 하나의 서비스로 연결하고 실행하는 단계”로 넘어간 한 주였다고 생각한다. (랩보다 AI 더 잘해지기)

---

2. 가장 인상 깊었던 학습

“기능을 구현하는 것”과 “서비스를 만드는 것”은 다르다

이번 주에 가장 크게 배운 것은 이 차이였다.

두 번째 미니프로젝트를 시작했을 때만 해도 AI Agent 프로젝트에서 가장 중요한 것은 LLM과 MCP Tool을 연결해서 원하는 결과를 만들어내는 것이라고 생각했다.

하지만 실제로 LawPath를 만들어보니 그것만으로는 서비스가 완성되지 않았다.

실제 사용자 입장에서는

사용자 질문
↓
정보 충분성 판단
↓
필요하면 추가 질문
↓
AI Agent
↓
MCP Tool
↓
법령 / 상담사례 / 판례 검색
↓
Database
↓
분석 결과
↓
Frontend
↓
결과 저장
↓
질의 이력

까지 자연스럽게 이어져야 한다.

특히 저장 기능을 구현하면서 이 부분을 확실하게 느꼈다.

단순히 화면에 “저장” 버튼을 하나 추가하는 것으로 끝나는 것이 아니라,

저장 버튼
↓
run_id
↓
Backend 저장 API
↓
인증 Token
↓
conversation_id
↓
이력 목록
↓
상세 조회
↓
삭제

처럼 여러 요소가 함께 연결되어야 했다. (랩보다 AI 더 잘해지기)

결국 AI 서비스라고 해서 AI 부분만 잘 만들면 되는 것이 아니라 Frontend, Backend, API, Database, 인증, 저장, 오류 처리, UX까지 모두 연결되어야 실제 사용 가능한 서비스가 된다는 것을 경험했다.

---

3. 어려웠던 점과 해결 과정

① 가장 어려웠던 것은 코드보다 데이터 흐름이었다

이번 프로젝트에서 가장 어려웠던 부분은 특정 코드를 작성하는 것보다 각 영역에서 데이터가 어떻게 이동하는지를 이해하는 것이었다.

프로젝트 구조가 커지면서

Frontend
Backend
Agent
MCP
Repository
Database

가 서로 연결되기 시작했다.

Frontend에서 어떤 데이터를 보여주려면 Backend가 어떤 형태로 데이터를 보내는지 알아야 하고, Backend가 정상적으로 응답하려면 MCP와 Database가 제대로 동작해야 했다.

따라서 문제가 생겼을 때도 단순히 내가 작성한 코드만 확인해서는 해결하기 어려웠다.

“이 값은 누가 만들었고, 어디로 전달되고, 최종적으로 어디에서 사용하는가?”

를 따라가야 했다. (랩보다 AI 더 잘해지기)

이 경험을 통해 다른 사람이 작성한 코드를 읽고 전체 흐름에 맞춰 연결하는 능력도 개발에서 상당히 중요하다는 것을 느꼈다.

---

② 팀원들의 코드를 하나로 합치는 과정

팀 프로젝트에서는 각자가 자신의 기능을 개발한다고 해서 프로젝트가 자동으로 완성되지 않았다.

Frontend가 정상적으로 실행되어도 Backend API의 응답 형식이 다르면 문제가 생기고, Backend와 MCP가 정상적으로 동작해도 Frontend가 그 결과를 제대로 처리하지 못하면 사용자에게는 기능이 고장난 것처럼 보인다.

그래서 이번 주에는 계속해서

• API 요청/응답 구조
• Agent 상태
• MCP Tool 연결
• 검색 결과 형태
• 오류 처리
• Mock과 실제 API
• Git branch와 merge
• 서버 연결 상태

등을 확인했다. (랩보다 AI 더 잘해지기)

결국 각자의 코드가 잘 작동하는 것과 전체 서비스가 잘 작동하는 것은 전혀 다른 문제라는 것을 직접 경험했다.

---

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

AI 오케스트레이션은 “연결”의 문제라는 것

이번 주 전까지는 AI 오케스트레이션을 조금 추상적으로 생각했던 것 같다.

LLM이 있고, Agent가 있고, MCP Tool이 있으면 AI 오케스트레이션이 만들어지는 것처럼 생각했다.

하지만 프로젝트를 직접 진행하면서 조금 다르게 이해하게 됐다.

LLM
+
Agent
+
Tool
+
Database
+
API
+
Frontend
+
Authentication
+
Testing
+
UX

이 구성요소들이 각각 존재하는 것보다 서로 올바른 순서와 방식으로 협력하도록 만드는 것이 중요했다. (랩보다 AI 더 잘해지기)

특히 법률 서비스에서는 더욱 그랬다.

AI가 그럴듯한 답변을 만들어내는 것만으로는 부족하다.

어떤 법령이나 판례를 검색했는지, 어떤 상담사례를 참고했는지, 그 근거가 질문과 관련이 있는지 사용자가 확인할 수 있어야 한다.

그래서 AI 서비스에서는 모델의 답변뿐만 아니라 검색 데이터와 근거를 어떻게 연결하고 사용자에게 보여줄 것인지도 중요하다는 것을 알게 됐다.

---

5. 두 번째 미니프로젝트를 통해 달라진 나의 시선

이번 프로젝트에서 개인적으로 가장 큰 변화는 개발을 바라보는 범위가 넓어진 것이다.

처음에는

“내 코드가 잘 돌아가는가?”

가 중요했다면,

이번 프로젝트를 마치면서는

“팀의 코드가 하나의 서비스로 연결되는가?”

를 생각하게 됐다. (랩보다 AI 더 잘해지기)

특히 Frontend를 담당하면서 Backend API와 데이터 구조를 이해해야 했고, 팀 리더 역할까지 맡으면서 Backend, MCP, Database 쪽 작업도 계속 확인해야 했다.

그래서 예전보다 프로젝트 전체 구조를 보는 시야는 조금 넓어진 것 같다.

물론 Python, Backend, Database 같은 기초적인 부분은 아직 부족하다.

특히 내가 직접 처음부터 Backend나 Database 구조를 설계하고 구현하는 능력은 더 키워야 한다.

이번 프로젝트를 통해 오히려 이런 부족한 부분이 더 명확하게 보였다는 점도 의미가 있었다.

---

6. 프로젝트 이후 Docker까지 이어지면서

미니프로젝트가 끝난 뒤에는 Docker를 배우면서 또 다른 관점의 변화가 있었다.

그동안은 개발 환경에서

Python 실행
Backend 실행
Frontend 실행
MCP 실행
Database 연결

하는 방식으로 생각했다면, Docker를 배우면서 이 실행 환경 자체를 하나의 패키지처럼 구성할 수 있다는 것을 알게 됐다.

특히 Docker Compose를 사용하면 여러 서비스를 하나의 설정으로 관리할 수 있었다.

이번 실습에서는

Frontend
   ↓
Backend
   ↓
Travel MCP
Policy MCP

를 각각 컨테이너로 구성하고 연결했다.

또한 MCP를 기존 STDIO 방식에서 HTTP 방식으로 전환하면서 MCP가 단순히 Tool을 만드는 기술이 아니라 서로 다른 서비스 사이에서 AI Agent가 기능을 사용할 수 있도록 연결하는 구조라는 것도 조금 더 명확하게 이해할 수 있었다. (랩보다 AI 더 잘해지기)

---

7. Docker를 배우면서 알게 된 또 하나의 차이

이번 주에는 Dockerfile과 Docker Compose의 역할도 구분하게 됐다.

간단하게 정리하면,

Dockerfile = 하나의 서비스를 어떤 환경에서 실행할지 만드는 설명서

Docker Compose = 여러 서비스를 어떻게 연결해서 실행할지 정의하는 구성도

라고 이해했다.

그리고 Docker Hub를 통해 만들어진 이미지를 저장하고 공유하는 과정도 실습했다.

Dockerfile
↓
Image Build
↓
Tag
↓
Docker Hub Push
↓
다른 환경에서 Pull
↓
Docker Compose
↓
Container 실행

이 과정을 경험하면서 Docker를 단순히 “프로그램을 실행하는 도구”라고 생각했던 이전보다 훨씬 구체적인 개념을 갖게 됐다. (랩보다 AI 더 잘해지기)

---

8. 현재 나의 상태

이번 주를 마친 현재 나는 AI Agent 서비스를 구성하는 여러 기술이 서로 어떻게 연결되는지 전체적인 구조를 볼 수 있는 단계까지는 왔다고 생각한다.

현재 이해하고 있는 흐름은 대략 다음과 같다.

사용자
↓
Frontend
↓
Backend API
↓
AI Agent
↓
MCP Tool
↓
Database / 외부 데이터
↓
검색 및 분석
↓
Frontend

그리고 이것을 Docker까지 확장하면

Source Code
↓
Dockerfile
↓
Docker Image
↓
Docker Hub
↓
Docker Compose
↓
여러 Container
↓
실행 가능한 서비스

라는 흐름도 이해하기 시작했다. (랩보다 AI 더 잘해지기)

다만 아직 “이해하고 있다”와 “혼자 처음부터 구현할 수 있다” 사이에는 차이가 크다.

특히 다음 부분은 아직 부족하다.

• Python 기본기
• Backend 구조 이해
• Database 설계 및 SQL
• RAG와 Vector Search
• MCP 통신 구조
• Docker 네트워크
• 실제 서버 배포
• 여러 서버에서 발생하는 오류 추적

따라서 지금 단계에서 스스로를 완성된 개발자라고 생각하기보다는 전체 구조를 이해하기 시작했고, 부족한 기술 영역이 무엇인지 조금 더 명확하게 알게 된 상태라고 보는 것이 맞을 것 같다.

---

9. 다음 주에는 무엇을 보완할 것인가

앞으로는 새로운 기술을 무작정 추가하기보다는 이번 프로젝트에서 부족했던 기초를 다시 확인하는 것에 집중하려고 한다.

특히 다음 부분을 다시 공부할 필요가 있다.

① Python 기본기

프로젝트 코드를 따라가는 것과 직접 코드를 작성하는 것은 다르기 때문에 Python 문법과 자료구조를 다시 정리할 필요가 있다.

② Backend

Frontend에서 API를 호출하는 수준을 넘어 FastAPI와 Backend 내부 구조를 조금 더 이해하고 싶다.

③ Database

PostgreSQL, SQL, Repository 구조와 실제 데이터가 저장되고 조회되는 과정을 더 명확하게 이해해야 한다.

④ RAG / Embedding / Vector Search

이번 LawPath에서 실제로 사용했던 기술이기 때문에 단순히 용어만 아는 수준에서 벗어나 전체 검색 과정을 다시 정리할 필요가 있다.

⑤ Docker

이번에는 강의와 실습을 따라가며 구성했기 때문에 Dockerfile, Compose, 네트워크, 환경변수를 혼자서 처음부터 구성해보는 연습이 필요하다.

결국 다음 단계에서는 “프로젝트 코드를 이해하는 능력”에서 “내가 직접 필요한 부분을 구현할 수 있는 능력”으로 넘어가는 것을 목표로 하고 싶다.

---

10. KPT 회고

Keep

프로젝트 전체 흐름을 보면서 개발하려는 습관

이번 프로젝트를 통해 내 코드만 보는 것이 아니라 Frontend → Backend → MCP → DB까지 연결해서 확인하는 습관이 중요하다는 것을 경험했다. 이 부분은 앞으로도 계속 유지하고 싶다.

Problem

기초 기술에 대한 이해 부족

프로젝트가 복잡해질수록 Python, Backend, Database 같은 기본기가 부족한 부분이 눈에 띄었다.

또한 오류가 발생했을 때 어느 영역의 문제인지 빠르게 좁혀가는 능력도 아직 부족하다.

Try

프로젝트에서 사용했던 기술을 직접 다시 만들어보기

이번에 사용했던 기술들을 단순히 프로젝트에서 끝내지 않고,

Python
→ FastAPI
→ PostgreSQL
→ RAG
→ MCP
→ Docker

순서로 다시 복습하면서 각각을 직접 구현해보는 시간을 가져볼 생각이다.

---

11. 9월 2주차를 마치며

9월 2주는 지금까지의 교육 과정 중에서도 “AI Agent를 어떻게 만드는가”에서 “AI Agent 서비스를 어떻게 구성하는가”로 생각이 바뀐 주였다.

두 번째 미니프로젝트를 통해 LawPath를 만들면서 LLM, Agent, MCP, RAG, Database, API, Frontend가 각각 따로 존재하는 기술이 아니라 하나의 서비스 안에서 연결되어야 한다는 것을 경험했다.

그리고 최종 발표를 끝낸 뒤 Docker와 Docker Compose를 배우면서 그 서비스를 실제 실행 환경으로 옮기는 과정까지 조금씩 경험했다. (랩보다 AI 더 잘해지기)

무엇보다 이번 주에는 내가 잘하는 부분과 부족한 부분이 동시에 명확해졌다.

Frontend와 사용자 흐름을 구성하고 팀원들의 작업을 연결하는 부분은 이전보다 자신감이 생겼지만, 반대로 Python, Backend, Database처럼 기본적인 개발 역량은 더 보완해야 한다는 것도 분명해졌다.

그래서 다음 단계에서는 새로운 기술을 계속 추가하는 것보다 이번 프로젝트에서 사용했던 기술을 다시 직접 구현하면서 내 것으로 만드는 과정이 필요할 것 같다.

이번 주를 지나면서 AI 개발을 바라보는 시선도 조금 달라졌다.

처음에는

“AI Agent를 만들어보자.”

였다면,

이제는

“사용자가 실제로 사용할 수 있는 AI 서비스를 만들려면 무엇이 필요한가?”

를 생각하게 됐다.

아직 갈 길은 멀지만, 적어도 어떤 부분을 더 공부해야 하는지는 이전보다 명확해진 한 주였다.

---

핵심 정리

• 두 번째 미니프로젝트 LawPath 최종 발표 및 마무리
• Frontend ↔ Backend ↔ Agent ↔ MCP ↔ Database 통합 경험
• 법령·상담사례·판례 검색 및 근거 제공 구조 이해
• 분석 결과 저장 및 질의 이력 기능 연결
• API 계약과 Git 협업의 중요성 경험
• Mock과 실제 기능을 구분하는 방법 학습
• Dockerfile과 Docker Compose의 역할 구분
• MCP STDIO → HTTP 통신 전환 실습
• Docker Hub 이미지 Build / Tag / Push / Pull 경험
• 여러 서비스를 컨테이너로 구성하고 End-to-End 테스트
• AI Agent는 LLM만의 문제가 아니라 전체 서비스 구조와 연결의 문제라는 점을 이해

해시태그

#SK네트웍스 #엔코아AI캠퍼스 #AI오케스트레이션 #AI에이전트 #멀티에이전트 #MCP #RAG #Docker #미니프로젝트 #개발자국비지원