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

 

8월은 지금까지 배운 웹 개발 기술 위에 AI를 실제 서비스에 연결하는 방법을 본격적으로 배우기 시작한 달이었다.

월초에는 Streamlit, FastAPI, Supabase를 연결해 팀 미니프로젝트를 완성하는 데 집중했다. 이후 JWT와 RLS를 이용한 인증·권한 관리, Docker와 PostgreSQL, Redis, pgvector, Ollama 등 AI 서비스를 만들기 위한 개발 환경을 학습했다. (랩보다 AI 더 잘해지기)

그리고 중순 이후부터는 LLM, AI Agent, Tool, MCP, RAG까지 학습 범위가 빠르게 확장됐다. 단순히 LLM을 호출하는 수준에서 벗어나 AI가 판단하고, 필요한 도구를 선택하고, 외부 API나 데이터베이스와 연결되어 실제 작업을 수행하는 구조를 이해하기 시작했다. (랩보다 AI 더 잘해지기)

무엇보다 8월을 지나면서 개발을 바라보는 관점이 조금 달라졌다.

예전에는 새로운 기술을 배우면 "이걸 어떻게 구현하지?"를 먼저 생각했다면, 이제는 조금씩 "이 문제에 정말 AI가 필요한가?", "어떤 구조가 가장 적합한가?"를 먼저 생각하게 됐다.

---

1. 8월 학습 흐름

8월의 학습을 크게 나누면 다음과 같은 흐름이었다.

서비스 개발 → 프로젝트 완성 → 서버·데이터 환경 구성 → LLM → AI Agent → Tool → MCP → RAG

월초에는 회원 인증과 데이터베이스 설계부터 이미지 업로드와 CRUD까지 구현하면서 프론트엔드와 백엔드, 데이터베이스가 연결되는 전체 흐름을 다시 확인했다.

팀 미니프로젝트에서는 공공임대 청약 공고를 검색할 수 있는 서비스를 만들었다. 관리자 공고 등록과 사용자 검색 기능을 구현했고, 이후 다중 이미지 업로드와 Gemini를 활용한 공고문 자동 등록 기능까지 추가하면서 하나의 서비스를 완성했다. (랩보다 AI 더 잘해지기)

프로젝트가 끝난 뒤에는 개발 환경 자체를 직접 구성하는 단계로 넘어갔다.

Docker를 이용해 PostgreSQL과 Redis를 실행하고, pgvector와 Ollama를 사용하면서 앞으로 AI Agent와 RAG를 구현하기 위한 기반 환경을 준비했다. (랩보다 AI 더 잘해지기)

그리고 8월 3주차부터는 본격적으로 AI 오케스트레이션을 공부했다.

LLM과 Agent의 차이부터 Routing과 Orchestration, Prompt Engineering, Structured Output, Tool, Agent 구조를 배우고 기존 부산 여행 프로젝트를 Agent 구조로 리팩터링했다. (랩보다 AI 더 잘해지기)

4주차에는 여기서 더 나아가 Workflow와 AI Agent를 비교하고, Tool Calling과 MCP를 학습했다. 실제 기상청 API를 연결한 MCP 서버를 구현하면서 외부 API와 AI 시스템을 연결하는 과정도 경험했다. 마지막에는 RAG와 임베딩, 벡터 검색까지 학습 범위를 확장했다. (랩보다 AI 더 잘해지기)

---

2. 가장 인상 깊었던 학습

"LLM을 사용하는 것"과 "AI 서비스를 만드는 것"은 다르다

8월에 가장 크게 달라진 생각은 이것이었다.

처음에는 AI 서비스를 단순하게 생각했다.

사용자 질문
↓
LLM
↓
답변

하지만 실제 서비스를 만들려면 훨씬 많은 과정이 필요했다.

사용자 입력
↓
Prompt
↓
Routing
↓
Agent
↓
Tool
↓
외부 API / DB
↓
결과 검증
↓
Structured Output
↓
Frontend

LLM은 자연어를 이해하고 판단하고 생성하는 데 강점이 있지만, 실제 데이터를 검색하거나 저장하는 역할까지 모두 맡기는 것은 적절하지 않다.

API는 실제 데이터를 가져오고, 데이터베이스는 데이터를 저장하며, 프론트엔드는 사용자에게 결과를 보여준다.

Agent는 그 사이에서 무엇을 해야 할지 판단하고 필요한 Tool을 선택하는 역할을 할 수 있다. (랩보다 AI 더 잘해지기)

이 구조를 이해하면서 'AI 오케스트레이션'이라는 말도 이전보다 구체적으로 이해할 수 있게 됐다.

---

3. AI Agent를 배우면서 달라진 생각

처음에는 AI Agent를 단순히 LLM보다 조금 더 똑똑한 챗봇 정도로 생각했다.

하지만 Agent는 단순히 답변을 생성하는 것이 아니라,

사용자 요청
↓
의도 판단
↓
필요한 기능 선택
↓
Tool 사용
↓
결과 확인
↓
최종 답변

과 같은 과정을 거쳐 실제 작업을 수행할 수 있다. (랩보다 AI 더 잘해지기)

특히 기억에 남았던 것은 모든 기능에 Agent를 사용할 필요는 없다는 것이었다.

예를 들어

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

처럼 절차와 조건이 명확한 작업이라면 굳이 LLM에게 판단을 맡길 필요가 없다.

반면 사용자의 자연어 요청을 이해하고 여러 기능 중 적절한 것을 선택해야 한다면 Agent가 유용할 수 있다. (랩보다 AI 더 잘해지기)

그래서 이제는 새로운 AI 기술을 보면 무조건

"이 기술을 어디에 사용할 수 있을까?"

라고 생각하기보다,

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

를 먼저 생각해야겠다는 기준이 생겼다.

---

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

8월에는 새로운 기술이 많았던 만큼 오류도 다양하게 경험했다.

특히 Docker 환경에서는 Windows, WSL, Container, Image, Port, 환경변수 등 여러 요소가 동시에 연결되어 있어 단순히 에러 메시지만 보고 해결하기 어려웠다.

PostgreSQL을 Docker에서 실행하면서도 로컬의 5433 포트와 컨테이너 내부의 5432 포트가 다를 수 있다는 것을 실제 환경에서 확인했다. (랩보다 AI 더 잘해지기)

AI Agent 프로젝트를 배포할 때는 localhost 문제도 경험했다.

로컬에서는 127.0.0.1:8000으로 백엔드에 접근할 수 있지만, 배포된 Streamlit에서는 자신의 서버를 의미하기 때문에 실제 배포된 Backend 주소를 사용해야 했다.

Render 배포 과정에서는 Build Command의 작은 따옴표 하나 때문에 빌드가 실패하기도 했고, Kakao API 403 오류나 SDK 버전 문제처럼 코드 외적인 원인도 확인해야 했다. (랩보다 AI 더 잘해지기)

이런 경험을 하면서 오류가 발생했을 때 무조건 코드를 수정하는 것이 아니라,

코드 문제인가?
↓
환경변수 문제인가?
↓
SDK 버전 문제인가?
↓
외부 API 설정 문제인가?
↓
배포 환경 문제인가?

처럼 원인을 하나씩 좁혀가는 습관이 필요하다는 것을 배웠다.

---

5. AI 코딩 도구를 바라보는 방식도 달라졌다

8월에 기술적인 내용만큼 중요하게 느낀 부분이 AI 코딩 도구를 사용하는 방법이었다.

AI에게 코드를 만들어달라고 하면 확실히 개발 속도는 빨라진다.

하지만 여러 사람이 같은 프로젝트에서 AI 코딩 도구를 사용하면 오히려 코드 구조나 변수명, 파일 구성 등이 서로 달라질 수 있었다. (랩보다 AI 더 잘해지기)

그래서 단순히

"이 기능 만들어줘."

라고 요청하는 것보다,

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

등을 먼저 명확하게 전달해야 했다.

결국 AI에게 코드를 잘 작성시키는 능력과 AI가 작성한 코드를 검수하는 능력 모두 개발 과정의 일부라는 생각을 하게 됐다.

특히 AI가 만들어준 코드를 그대로 사용하면 당장은 빠르지만, 프로젝트 구조가 조금만 달라져도 수정하기 어려워진다.

그래서 앞으로는

프로젝트 분석
↓
구현 계획
↓
사람이 계획 검토
↓
AI를 활용한 구현
↓
변경된 코드 확인
↓
직접 이해하고 테스트

라는 흐름을 유지하려고 한다. (랩보다 AI 더 잘해지기)

---

6. 한 달 동안 새롭게 이해한 것

8월 초에는 기술을 각각 따로 바라보는 느낌이 강했다.

LLM
AI Agent
Tool
MCP
RAG
Database
API

하지만 한 달 동안 학습하면서 이 기술들이 하나의 시스템 안에서 연결될 수 있다는 것을 조금씩 이해하게 됐다.

예를 들면,

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

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

여기에 RAG를 적용하면 서비스가 가지고 있는 문서를 임베딩하고 벡터 데이터베이스에 저장한 뒤, 사용자 질문과 의미적으로 가까운 데이터를 검색해서 LLM의 답변에 활용할 수도 있다. (랩보다 AI 더 잘해지기)

특히 임베딩도 단순히 "텍스트를 숫자로 바꾸는 것"이라고 생각했던 것에서 벗어나, 문장의 의미를 벡터로 표현하고 이를 이용해 의미적으로 비슷한 데이터를 검색하는 과정이라는 개념을 조금 더 구체적으로 이해하게 됐다. (랩보다 AI 더 잘해지기)

---

7. 현재 나의 상태

8월을 마치면서 적어도 AI Agent가 실제 서비스에서 어떤 구조로 동작하는지는 이전보다 설명할 수 있게 됐다.

현재 연결해서 이해할 수 있게 된 개념은 다음과 같다.

• LLM과 AI Agent의 차이
• Workflow와 AI Agent의 차이
• Routing과 Orchestration
• Prompt Engineering
• Structured Output
• Tool Calling
• Agent → Tool → Service 구조
• MCP Server
• 외부 API 연동
• Docker와 PostgreSQL
• Redis
• pgvector
• RAG
• 임베딩과 벡터 검색
• AI 코딩 도구를 활용한 개발 방식

하지만 아직 코드를 봤을 때 모든 동작을 바로 설명할 수 있는 수준은 아니다.

특히 AI 코딩 도구가 만들어준 코드를 빠르게 받아들이는 것과 그 코드가 왜 그렇게 작성됐는지 이해하는 것은 완전히 다른 문제라는 것을 느꼈다. (랩보다 AI 더 잘해지기)

결국 지금 나에게 필요한 것은 새로운 기술을 더 많이 추가하는 것보다 배운 기술을 직접 코드 단위로 따라가면서 이해하는 것이라고 생각한다.

---

8. 8월 KPT 회고

Keep

새로운 기술을 단순히 개념으로 외우지 않고 실제 프로젝트 구조에 대입해서 생각하는 방식은 계속 유지하고 싶다.

특히 문제가 발생했을 때 로그와 환경설정, 코드 구조를 먼저 확인하고 원인을 좁혀가는 습관을 계속 가져가려고 한다.

그리고 AI 코딩 도구를 사용할 때도 무조건 빠르게 구현하는 것보다 계획 → 구현 → 검수의 과정을 유지하고 싶다.

Problem

가장 큰 문제는 역시 코드 이해도다.

AI를 활용하면 기능을 빠르게 구현할 수 있지만, 내가 작성하지 않은 코드가 많아질수록 전체 구조를 이해하는 데 시간이 필요하다.

또한 Agent, Tool, MCP, RAG, Database, API가 하나의 시스템으로 연결되기 시작하면서 각각의 역할을 구분하는 것도 아직 완전히 익숙하지 않다.

Try

다음 달에는 새로운 기술을 무조건 많이 배우기보다 하나의 기능을 처음부터 끝까지 따라가는 연습을 더 많이 해보려고 한다.

사용자 입력
↓
Agent
↓
Tool
↓
MCP
↓
API / DB
↓
검색 결과
↓
LLM
↓
최종 응답

이 흐름을 코드 단위로 직접 확인하면서 각 단계에서 어떤 데이터가 전달되는지 이해하는 것이 목표다.

특히 RAG의

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

전체 흐름을 직접 구현해보면서 개념을 확실하게 잡아보고 싶다. (랩보다 AI 더 잘해지기)

---

9. 8월을 마치며

8월은 개인적으로 개발을 바라보는 관점이 가장 많이 바뀐 달이었다.

월초에는 여전히 화면을 만들고 API를 연결하고 데이터를 저장하는 것처럼 기능을 구현하는 것에 집중했다.

하지만 한 달 동안 학습하면서 점점

어떤 기술을 사용할 것인가?

보다

어떤 문제를 어떤 구조로 해결할 것인가?

가 더 중요하다는 것을 느끼게 됐다.

특히 AI Agent를 배우면서 AI를 무조건 많이 사용하는 것이 좋은 개발이 아니라는 것도 알게 됐다.

명확한 규칙으로 해결할 수 있는 문제라면 Workflow가 더 적합할 수 있고, 사용자의 의도를 해석하거나 여러 도구 중 하나를 선택해야 하는 문제라면 Agent가 더 적합할 수 있다.

또한 AI가 코드를 만들어주는 시대일수록 개발자는 코드를 직접 타이핑하는 능력만큼 문제를 정의하고, 구조를 설계하고, AI가 만든 결과를 검증하는 능력이 중요해질 것이라는 생각도 들었다. (랩보다 AI 더 잘해지기)

아직은 부족한 부분이 많다.

특히 코드를 읽고 전체 동작을 머릿속에서 연결하는 능력은 더 연습해야 한다.

그래도 8월을 시작할 때와 비교하면 지금은 적어도 LLM → Agent → Tool → API/DB → 결과로 이어지는 AI 서비스의 전체적인 그림을 생각할 수 있게 됐다.

9월에는 새로운 개념을 많이 추가하는 것보다 지금까지 배운 것들을 실제 프로젝트에 적용하면서 "알고 있다"에서 "직접 설명하고 수정할 수 있다"로 넘어가는 것을 목표로 해보려고 한다.

8월은 AI를 사용하는 방법을 배운 달이었다면,
9월은 AI 서비스를 직접 설계하고 이해하는 힘을 키우는 달로 만들어보고 싶다.