32일차 회고｜Git 협업·Workflow·AI Agent·Tool 설계｜AI 오케스트레이션 개발자 국비지원

오늘은 팀 미니 프로젝트를 실제로 통합하고 코드를 점검하면서, AI 코딩 도구를 활용한 협업에서 무엇을 신경 써야 하는지를 많이 배운 날이었다.

특히 단순히 기능을 구현하는 것에서 끝나는 것이 아니라, 여러 사람이 만든 코드를 하나의 프로젝트로 통합하고 Workflow와 AI Agent의 차이를 실제 주차 시스템에 적용해보는 과정이 인상적이었다.

참고로 오늘 진행한 프로젝트 저장소는 GitHub 저장소⁠를 기준으로 확인하려 했지만, 현재 외부에서 저장소 내용을 직접 불러오지 못했다. 따라서 아래 회고는 오늘 채팅에서 실제로 확인한 수업 내용과 작업 과정 중심으로 작성했다.

⸻

오늘 배운 내용

오늘은 크게 네 가지 흐름으로 진행됐다.

* Git merge와 팀 코드 통합
* AI 코딩 도구를 활용한 협업과 코드 리뷰
* Workflow와 AI Agent의 차이
* Tool을 활용한 데이터 조회와 실제 Action 수행

기존에는 AI를 활용해서 코드를 빠르게 만드는 것에 초점을 맞췄다면, 오늘은 **“AI가 만들어준 코드를 어떻게 팀의 코드로 만들 것인가?”**라는 부분을 더 많이 생각하게 됐다.

⸻

Git merge를 하면서 느낀 팀 개발의 현실

오전에는 팀원들이 각자 작업한 코드를 develop에 통합하는 과정에서 실제 충돌이 발생했다.

특히 config.py의 설정값이나 __pycache__ 같은 파일 때문에 충돌이 발생할 수 있다는 것을 확인했다.

혼자 개발할 때는 내가 수정한 파일을 내가 알고 있기 때문에 문제가 크지 않지만, 여러 명이 동시에 같은 프로젝트를 수정하면 이야기가 달라진다.

팀원 A 작업
      ↓
팀원 B 작업
      ↓
각자 다른 부분 수정
      ↓
develop에 merge
      ↓
충돌 발생
      ↓
어떤 변경을 남길지 판단

여기서 단순히 충돌 표시를 지우는 것이 아니라 각 변경사항이 왜 만들어졌는지를 확인하고 필요한 코드를 남겨야 한다는 점이 중요했다.

또 로컬 develop과 원격 develop을 구분하고, 원격 변경사항을 내려받는 것인지 내 작업을 원격에 올리는 것인지도 정확하게 이해해야 했다.

⸻

AI 코딩을 여러 명이 함께하면 “기준”이 필요하다

오늘 가장 기억에 남았던 내용 중 하나다.

팀원들이 각각 AI 코딩 도구를 사용하면 개발 속도는 빨라질 수 있지만, 반대로 사람마다 코드 구조와 스타일이 달라질 가능성도 커진다.

그래서 강사님은 다음과 같이 계획을 세분화하는 것을 강조했다.

Plan
↓
Sub Plan
↓
상세 MD
↓
코드 작성
↓
코드 리뷰
↓
리팩토링

특히 MD 파일에 프로젝트의 요구사항과 개발 기준을 충분히 구체적으로 작성해야 한다는 점이 중요했다.

AI에게 단순히

“이 기능을 만들어줘.”

라고 하는 것보다,

“우리 프로젝트에서는 이런 구조를 사용하고, 이런 데이터를 받고, 이런 방식으로 결과를 반환한다.”

라고 기준을 명확하게 제공해야 원하는 코드에 가까워진다.

⸻

“돌아가는 코드”와 “납품할 수 있는 코드”는 다르다

오늘 가장 크게 와닿았던 부분이다.

AI를 이용하면 생각보다 빠르게 기능이 만들어진다.

하지만 실행된다는 것과 좋은 코드라는 것은 같은 의미가 아니다.

개인 프로젝트라면 내가 만든 코드를 내가 이해하고 사용하는 것으로 끝날 수도 있다.

하지만 회사에서 다른 사람에게 납품하는 코드라면 이야기가 달라진다.

* 코드 구조를 이해할 수 있는가?
* 요구사항대로 구현됐는가?
* 팀의 코드 스타일과 맞는가?
* 다른 기능을 추가하기 쉬운가?
* 불필요한 코드가 들어가 있지는 않은가?
* AI가 잘못 판단해서 만든 부분은 없는가?

이런 것들을 다시 확인해야 한다.

그래서 AI 코딩 시대에는 코드를 직접 작성하는 능력뿐만 아니라 AI가 만든 코드를 분석하고 검수하는 능력도 중요하다는 생각이 들었다.

⸻

Workflow와 AI Agent를 비교하다

오늘 프로젝트에서 가장 핵심적인 학습 내용은 Workflow와 AI Agent를 같은 문제에 적용해 비교하는 것이었다.

현재 프로젝트의 주차 시스템을 예로 들면 차량 사진을 입력받고 차량번호를 확인한 다음 등록 차량인지 판단하고 주차장 문을 여는 흐름을 생각할 수 있다.

Workflow 방식

차량 이미지
↓
차량번호 추출
↓
DB에서 등록 여부 확인
↓
등록 차량인가?
├─ Yes → 문 열기
└─ No  → 문 열지 않기

이런 흐름은 정해진 규칙을 그대로 실행하면 된다.

따라서 굳이 매 단계마다 LLM이 판단할 필요가 없다.

강사님도 현재 주차 시스템처럼 입력과 처리 과정이 명확하고 변화가 적은 업무라면 Workflow가 적합할 수 있다고 설명했다.

⸻

반대로 AI Agent에서는 Tool을 사용한다

AI Agent에서는 LLM이 외부 데이터를 확인하거나 실제 행동을 수행할 수 있도록 Tool을 연결한다.

오늘 설명한 Tool의 역할은 크게 두 가지로 정리할 수 있었다.

1. 데이터를 조회하는 Tool

예를 들어:

"이 차량번호가 등록되어 있는가?"

를 DB에서 확인하는 기능이다.

2. Action을 수행하는 Tool

예를 들어:

"주차장 문을 열어라."

처럼 실제 시스템에서 행동을 수행하는 기능이다.

그래서 이번 주차 시스템에서는 최소한 다음과 같은 Tool 구조를 생각할 수 있었다.

AI Agent
   │
   ├── 차량번호 조회 Tool
   │       ↓
   │     DB 확인
   │
   └── 문 열기 Tool
           ↓
        Action 수행

이 부분을 통해 Tool은 단순한 함수 하나를 만드는 것이 아니라 AI가 외부 세계와 데이터를 주고받거나 행동할 수 있도록 연결하는 인터페이스라는 것을 조금 더 명확하게 이해했다.

⸻

차량 이미지 분석에서 System Message가 중요한 이유

차량 사진을 LLM에 전달해서 차량번호를 추출하는 과정도 코드 리뷰를 통해 확인했다.

여기서 단순히 이미지를 보내고

“차량번호 알려줘.”

라고 하는 것만으로는 충분하지 않을 수 있다.

차량번호판은 다양한 형태가 존재하기 때문에 LLM에게 정확히 무엇을 찾아야 하는지 명확하게 알려줘야 한다.

예를 들어 차량번호 외의 다른 글자나 숫자가 이미지에 같이 있다면 잘못된 정보를 가져올 수도 있다.

따라서 이미지 분석을 위한 System Message를 직접 검토하고 튜닝하는 과정이 필요하다.

AI 코딩 도구가 코드를 만들어줬다고 해서 이 부분까지 AI에게 맡겨놓는 것이 아니라, 실제 요구사항을 알고 있는 개발자가 프롬프트를 검수해야 한다는 점을 배웠다.

⸻

Structured Output도 다시 확인했다

차량번호를 추출한 결과를 단순한 자연어 문장으로 받는 것보다 애플리케이션에서 사용할 수 있도록 일정한 구조로 받는 것이 중요하다.

이를 **Structured Output(구조화된 출력)**이라고 한다.

예를 들어:

LLM
↓
차량번호 추출
↓
정해진 데이터 구조
↓
Backend
↓
DB 조회

와 같은 형태로 이어질 수 있다.

특히 AI Agent나 Workflow와 연결할 때는 LLM의 결과를 다음 단계에서 안정적으로 사용할 수 있는 형태로 만드는 것이 중요하다는 점을 다시 생각하게 됐다.

⸻

Workflow는 왜 여전히 필요한가?

AI Agent를 공부하다 보면 모든 것을 AI Agent로 만드는 것이 더 발전된 방식처럼 느껴질 수 있다.

하지만 오늘 수업에서는 오히려 모든 업무에 AI가 필요한 것은 아니라는 점을 배웠다.

예를 들어:

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

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

오히려 정해진 Workflow를 사용하면 결과를 예측하기 쉽고 안정적으로 관리할 수 있다.

반대로 상황에 따라 어떤 Tool을 사용할지 판단해야 하거나, 정해진 흐름만으로 처리하기 어려운 업무라면 AI Agent가 더 적합할 수 있다.

결국 중요한 것은

Workflow가 좋은가, AI Agent가 좋은가가 아니라 어떤 업무에 어떤 방식을 적용해야 하는가

라는 점이었다.

⸻

오늘 실제로 확인한 Docker PostgreSQL

오늘 프로젝트 작업 과정에서는 DB 환경도 직접 확인했다.

팀 프로젝트의 .env.example에는 다음과 같은 PostgreSQL 연결 정보가 있었다.

postgresql+psycopg://agent_user:agent_password@localhost:5433/agent_db

그리고 실제로 내 환경에서 Docker를 확인해보니:

pgvector/pgvector:pg16
0.0.0.0:5433->5432/tcp
aidevs-pgvector

형태로 PostgreSQL 컨테이너가 실행되고 있었다.

즉 내 PC에서는:

localhost:5433
      ↓
Docker
      ↓
PostgreSQL 5432
      ↓
agent_db

형태로 연결되는 구조라는 것을 확인했다.

이 과정에서 .env.example의 설정을 보고 무조건 로컬 PostgreSQL을 새로 설치하는 것이 아니라, 실제 프로젝트의 Docker 환경을 먼저 확인해야 한다는 것도 배웠다.

다만 오늘 대화에서 확인된 범위에서는 car_plate.sql을 실제 DB에 성공적으로 적용한 결과까지는 확인하지 않았기 때문에, 이 부분은 오늘의 완료 작업으로 적지 않았다.

⸻

오늘 새롭게 이해한 점

오늘은 AI 오케스트레이션을 단순히

“LLM을 연결해서 AI 기능을 만드는 것”

으로 생각했던 것에서 조금 더 나아간 것 같다.

실제 서비스를 만들려면 그 앞뒤에 여러 요소가 연결된다.

사용자 입력
   ↓
Router
   ↓
이미지 / 데이터 처리
   ↓
LLM
   ↓
Structured Output
   ↓
Workflow 또는 AI Agent
   ↓
Tool
   ↓
DB / 외부 시스템
   ↓
최종 Action

그리고 이 구조를 실제 코드로 구현하는 것뿐만 아니라 왜 Workflow를 선택했는지, 왜 Agent가 필요한지, Tool은 어떤 역할을 하는지 설명할 수 있어야 한다.

⸻

오늘의 회고

오늘은 코드를 많이 작성한 날이라기보다 코드를 바라보는 관점이 달라진 날에 가까웠다.

특히 팀 프로젝트에서 AI 코딩 도구를 사용하면서 “AI가 만들어주니까 개발이 쉬워졌다”라고만 생각하면 안 된다는 것을 느꼈다.

여러 사람이 동시에 AI를 활용하면 오히려 코드의 기준과 요구사항을 명확하게 정하는 일이 더 중요해진다.

또한 Workflow와 AI Agent를 비교하면서 AI를 무조건 넣는 것이 좋은 설계가 아니라는 것도 이해하게 됐다.

정해진 규칙을 정확하게 수행하는 업무는 Workflow로 처리하고, 상황에 따라 판단하거나 여러 Tool을 활용해야 하는 업무에는 AI Agent를 사용하는 식으로 문제의 성격에 따라 구조를 선택해야 한다.

아직은 코드를 봤을 때 각 컴포넌트가 정확히 어떤 역할을 하는지 바로 설명할 수 있는 수준은 아니다. 특히 팀원이 작성한 Backend 코드와 AI Agent 관련 코드를 더 많이 읽어보고, “이 코드가 왜 이렇게 만들어졌는가?“를 설명할 수 있는 능력을 보완해야겠다고 느꼈다.

오늘 배운 내용 중 가장 중요한 한 가지를 남긴다면 이것이다.

AI에게 코드를 만드는 일을 맡길 수는 있지만, 어떤 코드를 만들어야 하는지 결정하고 그 코드가 제대로 만들어졌는지 검수하는 것은 결국 개발자의 몫이다.

오늘 복습할 부분

* Git merge와 충돌 해결 과정
* 로컬 develop과 원격 develop의 관계
* Plan → Sub Plan → MD 기반 개발
* Workflow와 AI Agent의 차이
* Tool의 조회 기능과 Action 기능
* Structured Output
* 이미지 분석 System Message 설계
* Docker PostgreSQL과 DATABASE_URL 연결 구조
* 팀원이 작성한 Backend 코드 분석하기

⸻

마무리

오늘 프로젝트는 단순히 하나의 기능을 구현하는 미니 프로젝트라기보다, AI 코딩 도구를 활용한 협업과 AI 오케스트레이션의 실제 구조를 경험해보는 과정에 가까웠다.

특히 앞으로 프로젝트 규모가 커질수록 “내 기능이 돌아간다”에서 끝나는 것이 아니라 팀 전체 코드와 연결했을 때도 일관된 구조를 유지할 수 있는가를 계속 고민해야 할 것 같다.