31일차에는 기존에 배웠던 Workflow, AI Agent, Tool, 실제 데이터베이스 연동을 하나의 서비스로 연결하는 미니 프로젝트 과제를 진행했다.
이번 과제의 주제는 자동차 번호판을 인식해 등록 차량인지 확인하고 주차장 출입 여부를 결정하는 시스템이다. 단순히 기능을 구현하는 것보다, 같은 업무를 Workflow와 AI Agent로 각각 구현하면서 두 방식의 차이를 직접 확인하는 것이 핵심이었다.
특히 이번 수업에서는 코드를 작성하는 것보다 먼저 전체 시스템을 어떻게 구성하고 5명이 어떻게 나눠서 개발할 것인지를 고민하는 시간이 중요했다.
1. 오늘 배운 내용
오늘 과제의 전체 흐름은 다음과 같다.
카메라로 번호판 촬영
↓
번호판에서 차량 번호 추출
↓
차량 등록 여부 확인
↓
Workflow 또는 AI Agent 실행
↓
출입 여부 판단
↓
출입문 제어 Tool 실행
↓
결과를 화면에 표시여기서 중요한 것은 번호판을 이미지에서 추출하는 부분 자체가 Workflow의 시작은 아니라는 것이었다.
번호판 이미지를 촬영하고 차량 번호를 추출한 뒤, 그 차량 번호를 가지고 실제 업무를 처리하는 단계부터 Workflow나 AI Agent가 개입한다.
즉,
이미지 촬영 → 차량 번호 추출과
차량 번호 → 등록 여부 확인 → 출입 결정을 구분해서 생각해야 했다.
2. 같은 Tool을 Workflow와 AI Agent에서 사용한다
이번 과제에서 가장 중요하게 이해한 부분 중 하나다.
Workflow와 AI Agent가 서로 완전히 다른 기능을 사용하는 것이 아니라, 가능한 한 동일한 Tool을 사용하고 업무를 처리하는 방식만 다르게 구성한다.
예를 들어 다음과 같은 Tool을 만든다고 생각할 수 있다.
check_vehicle()
open_gate()
deny_gate()check_vehicle()은 차량 번호를 데이터베이스에서 조회하고 등록 여부를 확인하는 역할이다.
등록된 차량이라면:
check_vehicle()
↓
등록 차량
↓
open_gate()등록되지 않은 차량이라면:
check_vehicle()
↓
미등록 차량
↓
deny_gate()이 Tool을 Workflow에서도 사용하고 AI Agent에서도 사용한다.
3. Workflow와 AI Agent의 차이
처음에는 둘 다 Tool을 사용한다면 결국 비슷한 것 아닌가 하는 생각이 들었다.
하지만 핵심적인 차이는 누가 다음 행동을 결정하느냐에 있다.
Workflow
Workflow는 미리 정해놓은 흐름대로 실행한다.
차량 번호
↓
차량 조회
↓
IF 등록 차량
├─ YES → 문 열기
└─ NO → 출입 거부개발자가 흐름을 직접 정의하기 때문에 결과를 예측하기 쉽다.
AI Agent
AI Agent에서는 LLM이 Tool을 사용하면서 상황에 따라 다음 행동을 판단한다.
차량 번호
↓
AI Agent
↓
차량 조회 Tool
↓
조회 결과
↓
LLM 판단
↓
출입문 Tool따라서 이번 과제는 단순히 "AI Agent가 더 좋다"를 보여주는 것이 아니라,
같은 업무를 Workflow로 만들 수도 있고 AI Agent로 만들 수도 있으며, 상황에 따라 어떤 방식이 적합한지 생각해보는 것
이 목적이라는 점을 이해하게 됐다.
4. 실제 데이터베이스를 연동하는 이유
이번 과제에서는 기존에 사용했던 외부 서비스 형태의 데이터베이스 대신 로컬에서 직접 운영하는 PostgreSQL 데이터베이스를 사용하기로 했다.
강사님께서는 작은 규모의 서비스라면 외부에서 제공하는 데이터베이스 서비스를 이용하는 것도 괜찮지만, 전국 단위의 대규모 서비스처럼 데이터와 시스템을 직접 관리해야 하는 경우에는 직접 데이터베이스를 운영하는 구조를 고려해야 한다는 점을 설명해주셨다.
이번 과제는 단순히 데이터베이스를 사용하는 것에서 끝나는 것이 아니라,
Frontend
↓
Backend
↓
Workflow / AI Agent
↓
Tool
↓
PostgreSQL처럼 각 시스템이 어떻게 연결되는지 경험하는 것에 의미가 있었다.
5. 5명이서 어떻게 나눠 개발할 것인가
이번 과제에서 생각보다 중요했던 부분은 코드를 작성하기 전에 팀의 작업 범위를 나누는 것이었다.
5명이 동시에 개발하려면 각자 아무 파일이나 수정하는 방식으로는 충돌이 발생하기 쉽다.
그래서 전체 시스템을 다음과 같이 나누는 방향으로 정리했다.
① Frontend
- 카메라 화면
- 번호판 촬영
- 이미지 업로드
- Workflow / AI Agent 화면
- 결과 표시
- Backend API 연결
② Backend / API
- API 서버
- 이미지 요청 처리
- 번호판 인식 연결
- Workflow 호출
- AI Agent 호출
- 결과 반환
③ Database / Tool
- PostgreSQL
- 차량 테이블
- 테스트 데이터
- 차량 조회 Tool
- 출입문 제어 Tool
④ Workflow
- 정해진 업무 흐름 설계
- 차량 조회
- 등록 여부 분기
- 출입문 Tool 호출
⑤ AI Agent
- Agent 구성
- System Prompt
- Tool 연결
- Tool 호출
- 조회 결과를 바탕으로 출입 여부 판단
이렇게 각자의 Boundary, 즉 담당 영역을 명확하게 나누는 것이 중요했다.
6. 개발 순서도 중요했다
처음부터 5명이 각자 코딩을 시작하는 것이 아니라 공통으로 사용할 규칙부터 정해야 한다.
내가 이번 과제를 정리하면서 가장 중요하다고 생각한 순서는 다음과 같다.
1. 전체 시스템 구조 확정
↓
2. API / Tool 인터페이스 확정
↓
3. Database + Tool 구현
↓
4. Backend API 구현
↓
5. Workflow / AI Agent 병렬 개발
↓
6. Frontend 연결
↓
7. 통합 테스트특히 Tool 인터페이스를 먼저 맞추는 것이 중요하다고 생각했다.
예를 들어 한 사람이
check_vehicle()라는 Tool을 만들었는데 다른 사람이
get_car_info()라는 이름으로 생각하고 개발하면 서로 연결할 때 문제가 생긴다.
그래서 코드를 만들기 전에 입력값과 반환값을 먼저 약속하는 것이 팀 개발에서 중요하다는 것을 알게 됐다.
7. 실제 개발 환경까지 고려해야 했다
이번에는 단순히 하나의 컴퓨터에서 모든 프로그램을 실행하는 것을 목표로 하지 않았다.
5명이 각각 개발하기 때문에 최종적으로는 각자의 컴퓨터에서 실행되는 Frontend, Backend, DB 등의 시스템을 어떻게 연결할지도 고려해야 했다.
예를 들어 Frontend가 한 팀원의 컴퓨터에서 실행되고 Backend가 다른 팀원의 컴퓨터에서 실행된다면 Frontend에서는 자신의 localhost가 아니라 Backend 담당자의 IP 주소와 포트를 사용해야 한다.
즉,
내 컴퓨터의 Frontend
↓
다른 팀원의 Backend
↓
Database와 같은 구조를 실제로 구성해야 한다.
강사님께서 강조하신 것도 단순히 코덱스에게 코드를 생성시키는 것이 아니라,
어떤 서버를 어디에 배치하고, 각 기능을 어떻게 연결할 것인지 시스템 전체를 설계할 수 있어야 한다
는 부분이었다.
8. Codex를 잘 사용하는 것도 개발의 일부라는 생각
이번 수업에서는 AI 코딩 도구를 사용하는 것 자체보다 어떻게 사용하느냐가 중요하다는 점도 다시 생각하게 됐다.
예를 들어 Codex에게
주차장 시스템 전체 만들어줘.라고 요청하면 편해 보이지만 팀 프로젝트에서는 문제가 생길 가능성이 높다.
대신 내가 맡은 역할과 수정 가능한 영역을 명확하게 전달해야 한다.
예를 들어 Workflow 담당이라면,
나는 Workflow 담당이다.
master.md의 Workflow 범위 안에서만 작업한다.
다른 담당자의 코드는 수정하지 않는다.
정의된 Tool을 사용해서
차량 등록 여부에 따라 출입을 결정하는 Workflow를 구현한다.처럼 전체 설계와 담당 범위를 먼저 정한 뒤 AI에게 코딩을 맡기는 방식이 필요하다.
결국 AI가 코드를 잘 작성하는 것과 별개로, 사람이 전체 시스템을 이해하고 있어야 한다는 이야기였다.
9. 오늘 새롭게 이해한 점
이번 수업을 통해 가장 크게 느낀 것은 AI 오케스트레이션에서 중요한 것이 단순히 AI를 사용하는 것이 아니라는 점이다.
예전에는 AI Agent를 공부하면서
"LLM이 Tool을 호출해서 일을 처리한다."
정도로 이해했다.
그런데 이번 과제를 설계하면서 보니 실제 서비스에서는 그보다 훨씬 많은 고민이 필요했다.
어떤 데이터를 사용할 것인가?
↓
어떤 Tool을 만들 것인가?
↓
Workflow로 처리할 것인가?
Agent가 판단하게 할 것인가?
↓
각 기능은 어느 서버에 배치할 것인가?
↓
Frontend와 Backend는 어떻게 연결할 것인가?
↓
5명이 어떻게 충돌 없이 개발할 것인가?결국 기술 하나하나를 아는 것뿐만 아니라 어떤 상황에서 어떤 기술을 조합할지 판단하는 능력이 중요하다는 것을 조금 더 구체적으로 이해하게 됐다.
10. 아직 부족한 부분
아직은 Workflow와 AI Agent를 실제 프로젝트 수준에서 직접 설계하고 구현하는 과정이 익숙하지 않다.
특히 다음 부분은 더 복습해야 할 것 같다.
- Workflow와 AI Agent의 적절한 사용 기준
- Tool의 입력과 출력 설계
- Backend와 Agent/Workflow 연결
- 실제 PostgreSQL 연동
- 여러 컴퓨터에서 실행되는 시스템 구성
- API와 서버 간 통신
- 팀 프로젝트에서 Git Branch와 Merge 관리
무엇보다 각 기술을 따로 이해하는 것과 여러 기술을 하나의 시스템으로 연결하는 것은 다른 문제라는 점을 느꼈다.
11. 오늘의 회고
31일차는 코드를 많이 작성한 날이라기보다 앞으로 진행할 프로젝트의 구조를 고민한 날에 가까웠다.
특히 이번 과제에서는 같은 주차 업무를 Workflow와 AI Agent 두 가지 방식으로 구현한다는 점이 흥미로웠다.
두 방식 모두 같은 Tool을 사용할 수 있지만, Workflow는 사람이 정해놓은 흐름을 따라가고 AI Agent는 LLM이 상황에 따라 Tool을 활용하며 판단한다는 차이가 있다.
그리고 이 차이를 제대로 비교하려면 각각을 따로 만드는 것이 아니라 가능한 한 동일한 Tool과 데이터를 사용해야 한다는 것도 알게 됐다.
또 5명이 함께 개발하면서 단순히 "각자 기능 하나씩 맡으면 된다"가 아니라, API와 Tool의 인터페이스를 먼저 맞추고 각자의 Boundary를 명확하게 정하는 것이 중요하다는 것을 배웠다.
이번 과제에서 내가 가장 기억하고 싶은 것은 이것이다.
AI 시대에도 개발자가 알아야 하는 것은 코드를 작성하는 방법만이 아니라, 어떤 기술을 어디에 배치하고 어떻게 연결할지를 설계하는 방법이다.
Codex가 코드를 대신 작성해줄 수 있는 시대가 되었지만, 무엇을 만들어야 하는지 정의하고 전체 시스템을 설계하는 것은 여전히 개발자의 몫이라는 점을 생각하게 된 31일차였다.
핵심 정리
- 번호판 촬영 → 차량 번호 추출 → 차량 등록 확인 → 출입 결정의 전체 흐름을 설계했다.
- Workflow와 AI Agent가 동일한 Tool을 사용할 수 있다는 점을 이해했다.
- Workflow는 정해진 흐름을 실행하고, AI Agent는 LLM이 Tool을 활용해 판단한다.
- 실제 PostgreSQL 데이터베이스를 연결하는 구조를 고려했다.
- 5명이 개발하기 위해 Frontend / Backend / DB·Tool / Workflow / AI Agent로 역할을 분리했다.
- 코딩 전에 API와 Tool의 입력·출력 규격을 정하는 것이 중요하다는 것을 배웠다.
- AI 코딩 도구를 활용하더라도 전체 시스템 구조와 개발 Boundary를 사람이 설계해야 한다는 점을 느꼈다.
댓글