65일차 회고｜Docker·n8n·AI 에이전트 자동화｜AI 오케스트레이션 개발자 국비지원

 

오늘은 Docker와 WSL을 활용한 개발 환경 구성부터 n8n을 이용한 워크플로 자동화, LLM 기반 문의 분류, CLI 코딩 에이전트를 활용한 바이브 코딩까지 폭넓게 학습했다.

이전까지는 주로 Python 코드를 작성하고 AI 에이전트의 동작 원리를 이해하는 데 집중했다면, 오늘은 이미 만들어진 코드와 도구를 연결하고 자동으로 실행되도록 구성하는 방법을 배웠다. 또한 AI 코딩 에이전트가 생성한 코드를 단계별로 검증하고, Git으로 변경 이력을 관리하는 방법도 살펴봤다.

특히 n8n과 Python 미니 플로우를 연결하는 과정, 장애 발생 시 대체 경로로 처리하는 폴백(Fallback), 그리고 코딩 에이전트에게 복잡한 작업을 단계별로 맡기는 방식이 인상 깊었다.

1. WSL과 Docker로 개발 환경 구성하기

1-1. WSL과 Ubuntu 기본 명령어

먼저 Windows에서 Linux 개발 환경을 사용할 수 있도록 해주는 WSL(Windows Subsystem for Linux)을 살펴봤다.

WSL은 Windows 안에서 Ubuntu 같은 Linux 배포판을 실행할 수 있도록 해주는 환경이다. Windows를 사용하면서도 Linux 명령어와 개발 도구를 활용할 수 있다는 장점이 있다.

수업에서는 다음과 같은 명령어를 다뤘다.

wsl -l -v
wsl -d Ubuntu

sudo apt update
sudo apt upgrade

pwd
cd ~
ls -a
which
echo $HOME

각 명령어의 역할을 정리하면 다음과 같다.

• wsl -l -v: 설치된 WSL 배포판과 버전을 확인한다.

• wsl -d Ubuntu: Ubuntu 배포판을 실행한다.

• sudo apt update: 패키지 목록을 최신 상태로 갱신한다.

• sudo apt upgrade: 설치된 패키지를 업그레이드한다.

• pwd: 현재 작업 디렉터리를 확인한다.

• cd ~: 홈 디렉터리로 이동한다.

• ls -a: 숨김 파일을 포함해 파일과 디렉터리를 확인한다.

• which: 명령어 실행 파일의 위치를 확인한다.

• echo $HOME: 홈 디렉터리 경로를 출력한다.

여기서 기억해야 할 부분은 apt update와 apt upgrade의 차이다. update는 패키지 목록을 갱신하는 작업이고, upgrade는 해당 정보를 바탕으로 설치된 패키지를 업그레이드하는 작업이다.

단순히 명령어를 외우는 것보다 현재 어떤 환경에서 작업하고 있는지 확인하고, 명령어가 어떤 역할을 하는지 이해하는 것이 중요했다.

1-2. Docker 이미지와 컨테이너

Docker는 애플리케이션 실행에 필요한 파일과 라이브러리, 환경 등을 이미지로 구성하고 이를 컨테이너로 실행할 수 있도록 해주는 도구다.

이미지(Image)는 프로그램을 실행하기 위한 템플릿이고, 컨테이너(Container)는 그 이미지를 바탕으로 생성된 실행 환경이다.

예를 들어 Docker 이미지를 내려받았다고 해서 반드시 프로그램이 실행 중인 것은 아니다. 이미지는 로컬에 저장되어 있을 수 있고, 컨테이너는 생성되었더라도 실행이 종료된 상태일 수 있다.

수업에서는 다음 명령어를 이용해 Docker 설치와 실행 환경을 확인하는 방법을 살펴봤다.

docker --version
docker compose version
docker info
docker run hello-world

docker run hello-world는 Docker가 정상적으로 이미지를 내려받고 컨테이너를 실행할 수 있는지 확인하는 간단한 테스트다. 실행 결과를 출력한 뒤 종료되는 컨테이너이므로, 실행이 끝난 컨테이너가 중지 상태로 보일 수도 있다.

또한 Docker Desktop과 WSL의 연동 상태, 명령어가 설치된 위치, PATH 설정에 따라 명령어 실행 결과가 달라질 수 있다는 점도 다뤘다.

Windows와 WSL, Docker 컨테이너는 서로 연결되어 있지만 완전히 같은 환경은 아니다. 문제가 발생하면 무조건 재설치하기보다 어느 환경에서 명령어를 실행하고 있는지, Docker 엔진에 연결되어 있는지부터 확인해야 한다.

1-3. Docker Compose로 여러 서비스 관리하기

Docker Compose는 여러 컨테이너로 구성된 애플리케이션을 하나의 설정 파일로 관리하고 실행할 수 있도록 해주는 도구다.

Compose 설정 파일에는 서비스, 포트, 볼륨, 환경 변수 등의 정보를 정의할 수 있다. .env 파일을 사용하면 환경 변수를 별도로 관리할 수도 있다.

수업에서 다룬 주요 명령어는 다음과 같다.

docker compose up -d
docker compose stop
docker compose start
docker compose down
docker compose logs

각 명령어의 차이는 다음과 같다.

• docker compose up -d: 필요한 컨테이너를 생성하거나 실행하고 백그라운드에서 동작하도록 한다.

• docker compose stop: 실행 중인 컨테이너를 중지한다.

• docker compose start: 기존에 중지된 컨테이너를 다시 실행한다.

• docker compose down: Compose가 관리하는 컨테이너와 네트워크 등을 제거한다.

• docker compose logs: 서비스의 실행 로그를 확인한다.

볼륨을 어떻게 설정했는지에 따라 컨테이너를 제거한 뒤에도 데이터가 유지될 수 있다. 따라서 컨테이너의 실행 상태와 데이터의 저장 위치는 구분해서 이해해야 한다.

Docker를 사용하는 목적은 단순히 프로그램을 실행하는 데 그치지 않는다. 개발 환경을 일정한 형태로 구성해 다른 환경에서도 비슷한 방식으로 실행할 수 있도록 만드는 것이 핵심이다.

2. n8n으로 워크플로 자동화하기

2-1. n8n의 기본 구조

n8n은 여러 서비스와 API, 코드 등을 연결해 자동화 작업을 구성할 수 있는 워크플로 자동화 도구다. 노드(Node)를 연결하는 방식으로 처리 과정을 설계할 수 있으며, 필요에 따라 코드와 AI 모델도 활용할 수 있다.

기본적인 워크플로는 다음과 같은 흐름으로 이해할 수 있다.

1. Trigger: 워크플로 실행을 시작한다.

2. Action 또는 처리 노드: 데이터를 가공하거나 API를 호출한다.

3. Condition: 조건을 검사하고 처리 경로를 나눈다.

4. Output: 처리 결과를 반환하거나 다음 작업으로 전달한다.

수업에서는 Docker 환경에서 n8n을 실행하고 Windows 브라우저에서 http://localhost:5678 주소로 접속하는 방법을 다뤘다.

컨테이너 내부에서 실행되는 서비스라도 포트가 적절하게 연결되어 있으면 호스트 컴퓨터의 브라우저에서 접근할 수 있다. 이 과정에서 WSL, Docker 컨테이너, Windows 브라우저가 어떻게 연결되는지도 함께 살펴봤다.

2-2. IF 노드로 조건 분기 만들기

첫 번째 워크플로에서는 Manual Trigger로 실행을 시작하고, Edit Fields 노드에서 사용자와 문의 내용을 입력하도록 구성했다.

이후 IF 노드에서 문의 내용에 긴급이라는 문자열이 포함되어 있는지 검사하도록 조건을 설정했다.

예를 들어 다음과 같은 JSON 데이터가 입력된다고 가정할 수 있다.

{
  "user": "Kim",
  "text": "긴급 VPN 연결 문제"
}

문의 내용에 긴급이라는 문자열이 포함되어 있으므로 긴급 처리 경로로 분기할 수 있다.

조건을 충족하면 담당자에게 즉시 연결하는 경로로 보내고, 충족하지 않으면 일반 문의 처리 경로로 보낼 수 있다.

이 과정에서 Include Other Input Fields 옵션도 살펴봤다. 이 옵션은 새로운 필드를 추가할 때 기존 입력 데이터도 유지할지 결정한다. 기존 필드가 유지되지 않으면 다음 노드에서 사용자 정보나 문의 내용을 사용할 수 없게 될 수 있다.

단순히 노드를 연결하는 것뿐 아니라, 각 노드에서 어떤 데이터가 입력되고 출력되는지 확인하는 것이 중요했다.

2-3. IF와 Switch의 차이

IF와 Switch는 모두 처리 경로를 나누는 데 사용하지만 목적이 다르다.

구분역할예시

IF	조건의 참·거짓에 따라 분기	문의에 긴급이라는 단어가 포함되어 있는가?
Switch	여러 값이나 범주에 따라 분기	계정, 네트워크, 소프트웨어, 보안 중 어디에 해당하는가?

Switch를 사용하면 문의 유형에 따라 여러 경로로 분기할 수 있다. 예를 들어 계정 문제는 계정 담당 경로로, 네트워크 문제는 네트워크 담당 경로로, 보안 문제는 보안 담당 경로로 보낼 수 있다.

여기서 인상 깊었던 부분은 규칙의 순서가 결과에 영향을 줄 수 있다는 점이었다.

문의 내용에 보안 관련 키워드가 포함되어 있더라도 소프트웨어 분류 규칙이 먼저 적용되면 소프트웨어 문의로 처리될 수 있다. 이 경우 보안 규칙을 앞쪽으로 이동해 우선순위를 조정할 수 있다.

조건을 여러 개 만들었다고 해서 원하는 결과가 자동으로 나오는 것은 아니다. 조건이 겹칠 때 어떤 규칙을 먼저 적용할지 고려해야 한다.

3. Webhook으로 외부 프로그램과 연결하기

Webhook은 외부에서 특정 HTTP 요청을 보내면 이를 계기로 워크플로를 실행할 수 있도록 해주는 기능이다.

HTTP는 프로그램끼리 데이터를 주고받을 때 사용하는 통신 규칙이다. POST 요청은 주로 서버에 데이터를 전달할 때 사용한다.

수업에서는 다음과 같은 구조로 Webhook 워크플로를 구성하는 방법을 다뤘다.

1. Webhook 노드에서 POST 요청을 받는다.

2. Edit Fields 노드에서 전달받은 데이터를 확인한다.

3. IF 노드에서 조건을 검사한다.

4. 조건에 따라 처리 경로를 나눈다.

5. Respond to Webhook 노드에서 결과를 JSON 형태로 반환한다.

외부에서 요청을 보내는 예시로는 curl을 사용할 수 있다.

curl -X POST "WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{"user":"Kim","text":"긴급 VPN 연결 문제"}'

위 코드는 요청 구조를 이해하기 위한 예시이며, 실제 실행 시에는 n8n에서 제공하는 Webhook URL을 사용해야 한다.

테스트 URL과 운영 URL의 차이

Webhook을 테스트하는 과정에서는 테스트용 URL과 운영용 URL을 구분해야 한다.

테스트 URL은 테스트 실행 상태에 맞춰 사용해야 하며, 게시된 워크플로를 호출할 때는 운영용 URL을 사용해야 한다.

수업에서는 URL과 워크플로의 실행 상태를 확인하는 과정에서 혼동이 있었다. 이를 통해 요청을 보냈다는 사실만으로 워크플로가 정상 작동했다고 판단해서는 안 된다는 점을 알게 됐다.

또한 n8n에서는 개별 노드를 실행하는 Execute Step, 전체 워크플로를 실행하는 Execute Workflow, 워크플로를 서비스로 사용할 수 있도록 공개하는 Publish의 차이도 살펴봤다.

Webhook은 URL뿐 아니라 워크플로 실행 상태, 요청 데이터 구조, 응답 노드 설정까지 함께 확인해야 한다.

HTTP 응답 코드 이해하기

외부 프로그램과 연동할 때는 요청이 어떤 결과로 처리되었는지 명확하게 전달해야 한다.

• 200 OK: 요청이 정상적으로 처리되었음을 나타낸다.

• 400 Bad Request: 요청 데이터가 잘못되었거나 유효하지 않을 때 사용한다.

• 401 Unauthorized: 인증이 필요하거나 인증 정보가 유효하지 않을 때 사용한다.

• 404 Not Found: 요청한 경로나 리소스를 찾을 수 없을 때 사용한다.

• 500 Internal Server Error: 서버 내부에서 처리 중 오류가 발생했을 때 사용한다.

이전에 학습한 FastAPI의 응답 코드와도 연결되는 내용이었다. 어떤 기술을 사용하든 요청과 응답의 의미를 명확하게 정의해야 다른 프로그램과 안정적으로 연동할 수 있다.

4. n8n의 데이터 전달과 실행 기록

n8n에서는 각 노드가 데이터를 받아 처리하고, 그 결과를 다음 노드로 전달한다. 일반적으로 JSON 객체 형태의 데이터를 사용한다.

예를 들어 다음과 같은 데이터가 있다고 가정할 수 있다.

{
  "user": "Kim",
  "text": "긴급 VPN 연결 문제"
}

n8n의 표현식에서는 $json을 이용해 현재 노드에서 사용할 수 있는 입력 데이터에 접근할 수 있다.

{{$json.user}}
{{$json.text}}

각 표현식은 입력 데이터의 user와 text 필드를 참조한다.

다만 Webhook으로 전달된 데이터가 body 아래에 포함되어 있다면 실제 데이터 구조에 맞춰 $json.body 등의 경로를 사용해야 한다. 따라서 표현식을 작성하기 전에 해당 노드의 입력 데이터를 확인하는 과정이 필요하다.

또한 n8n은 워크플로의 실행 기록을 통해 어떤 노드가 실행되었고, 어떤 경로로 분기했으며, 각 노드에서 어떤 결과가 나왔는지 확인할 수 있다.

이러한 실행 기록은 예상과 다른 결과가 나왔을 때 문제의 원인을 추적하는 데 도움이 된다.

5. LLM 기반 문의 분류와 자동 응답

LLM(Large Language Model)은 대규모 언어 모델로, 자연어를 이해하고 분류하거나 답변을 생성하는 데 사용할 수 있다.

수업에서는 사내 IT 지원 시스템을 예로 들어 AI가 문의 내용을 분석하고 적절한 처리 경로를 선택하는 흐름을 살펴봤다.

예를 들어 다음과 같은 문의가 들어올 수 있다.

• VPN 연결이 되지 않는다는 문의

• 비밀번호를 잊어버렸다는 문의

• 기존 FAQ에서 답변을 찾기 어려운 문의

이런 요청을 처리할 때 모든 문의를 사람이 직접 확인하기보다, AI가 먼저 내용을 분석하고 적절한 경로로 전달하도록 구성할 수 있다.

수업에서 다룬 처리 흐름은 다음과 같다.

1. 사용자가 문의를 입력한다.

2. LLM이 문의 내용을 분석하고 분류한다.

3. FAQ에서 적절한 답변을 찾을 수 있는지 확인한다.

4. 답변을 찾으면 안내 메시지를 반환한다.

5. 답변을 찾지 못하면 담당자에게 전달하는 경로로 분기한다.

실행 기록에서는 VPN 문제나 비밀번호 관련 문의가 안내 경로로 연결되는 사례와, FAQ에서 적절한 답변을 찾지 못해 담당자에게 전달하는 경로를 확인했다.

여기서 중요한 것은 AI가 답변을 생성하는 것만이 아니다. 답변할 수 있는 요청과 사람이 확인해야 하는 요청을 구분하는 것도 자동화 시스템의 중요한 역할이다.

AI가 모든 질문에 무조건 답변하도록 만드는 것보다, 확실한 답변이 없을 때 담당자에게 넘기는 구조가 더 안전하고 실용적일 수 있다.

6. n8n과 Python 미니 플로우의 폴백 구조

오늘 가장 의미 있게 이해한 개념 중 하나는 폴백(Fallback)이었다.

폴백은 우선적으로 사용하려던 기능이나 서비스가 실패했을 때 다른 경로를 통해 작업을 이어가는 방식이다.

수업에서는 n8n 워크플로와 Python으로 만든 미니 플로우를 연결한 구조를 살펴봤다.

처음에는 n8n 워크플로를 먼저 호출하고, 해당 경로가 실패하면 Python 미니 플로우의 자체 구현으로 처리하는 방식이었다.

이후 n8n 서비스를 중지한 상태에서 요청을 다시 보내며 장애 상황을 확인했다. n8n을 이용할 수 없는 상황에서 대체 경로가 어떻게 동작하는지 살펴본 것이다. 이어서 Python 미니 플로우를 먼저 사용하도록 실행 순서를 변경하는 방식도 확인했다.

이 과정을 통해 다음 두 가지를 구분할 수 있었다.

• 중복 구현: 같은 기능을 여러 곳에 만들어 두는 것

• 폴백: 우선 경로의 실패를 감지하고 대체 경로로 전환하는 것

두 가지 기능이 존재한다고 해서 자동으로 장애 대응이 되는 것은 아니다. 어느 경로에서 실패했는지 판단하고, 실패했을 때 어떤 경로로 넘어갈지 정의해야 한다.

이전 프로젝트에서 장애 복구 기능을 다루면서도 느꼈지만, 장애 대응은 단순히 복구 코드를 작성하는 것으로 끝나지 않는다. 실패를 어떻게 감지하고, 복구 성공을 어떻게 판단하며, 대체 경로가 실제로 작동하는지 검증하는 과정이 함께 필요하다.

오늘 배운 폴백도 이런 관점에서 이해할 수 있었다.

7. CLI 코딩 에이전트와 바이브 코딩

후반부에는 Claude Code, Codex, Gemini 계열 도구 등 CLI 기반 코딩 에이전트를 활용하는 방법을 살펴봤다.

CLI(Command-Line Interface)는 터미널에서 명령어를 입력해 프로그램을 조작하는 방식이다.

일반적인 채팅 인터페이스가 질문에 대한 답변이나 코드 조각을 제공하는 데 초점을 둔다면, CLI 코딩 에이전트는 실행 권한과 환경에 따라 프로젝트 파일을 읽고 수정하거나 명령어를 실행하는 작업까지 수행할 수 있다.

이때 중요한 것은 단순히 프롬프트를 잘 작성하는 것만이 아니었다. 에이전트가 프로젝트 구조와 작업 규칙을 이해하고, 변경 사항을 안전하게 관리할 수 있도록 개발 환경을 구성하는 것이 중요했다.

7-1. 프로젝트 규칙 파일과 작업 계획

코딩 에이전트에게 기존 프로젝트를 수정하도록 요청하기 전에 프로젝트 구조와 현재 구현 상태를 분석하게 하고, 큰 작업은 여러 단계로 나누어 진행하는 방식을 다뤘다.

에이전트별 규칙 파일에는 프로젝트에서 지켜야 할 개발 규칙이나 명령어 사용 방법 등을 기록할 수 있다. 예를 들어 Python 프로젝트에서 UV를 사용해 패키지를 관리한다면, 에이전트가 임의의 방식으로 환경을 구성하지 않도록 관련 규칙을 명시할 수 있다.

수업에서는 에이전트별 작업 디렉터리와 규칙 파일을 분리해 여러 코딩 에이전트의 결과를 비교하는 방식도 소개했다.

작업 계획을 문서로 작성하고 단계를 나누면 다음과 같은 장점이 있다.

• 기존 코드와 프로젝트 구조를 먼저 파악할 수 있다.

• 변경 범위를 단계별로 확인할 수 있다.

• 각 단계가 끝날 때마다 실행과 테스트를 진행할 수 있다.

• 문제가 발생하면 어느 단계에서 문제가 생겼는지 확인하기 쉽다.

작은 수정은 한 번의 요청으로 처리할 수도 있지만, 여러 기능이 연결된 작업은 계획을 세우고 단계별로 구현하는 편이 결과를 검증하기 쉽다.

7-2. Python 테트리스 게임으로 살펴본 단계별 구현

수업에서는 Python을 이용해 테트리스 게임을 만드는 예제를 통해 바이브 코딩 과정을 살펴봤다.

바이브 코딩은 자연어로 원하는 기능을 설명하고 AI 코딩 도구의 도움을 받아 코드를 생성하거나 수정하는 개발 방식이다. 하지만 코드를 생성하는 것만으로 개발이 완료되는 것은 아니다.

게임 구현 예제에서는 프로젝트를 분석하고 계획을 작성한 뒤, 초기 구조와 게임 로직을 구현하고 이후 기능을 추가하는 식으로 작업을 나누었다. 다음 조각 미리 보기, 고스트 피스, 일시 정지, 효과음 등 다양한 기능도 확장 가능한 항목으로 다뤄졌다.

또한 구현 단계를 나누고 각 단계의 결과를 확인한 뒤 다음 작업을 진행하는 방식이 소개됐다. 실행 스크립트를 통해 게임을 실행하고 결과를 확인하는 과정도 시연됐다.

여기서 기억해야 할 점은 AI가 코드를 생성하는 속도와 그 코드가 제대로 동작한다는 사실은 별개라는 것이다.

코드가 생성되었다고 해서 요구사항이 모두 충족된 것은 아니다. 실행해 보고, 결과를 확인하고, 문제가 있으면 수정해야 한다. 에이전트가 테스트를 수행했다고 보고하더라도 실제 결과와 변경 내용을 확인하는 과정이 필요하다.

또한 여러 코딩 에이전트가 동일한 프로젝트를 서로 다른 방식으로 구현할 수 있다는 점도 살펴봤다. 도구마다 결과가 다를 수 있기 때문에 하나의 도구가 항상 정답이라고 생각하기보다 결과물을 비교하고 검증하는 태도가 중요하다.

7-3. Git으로 변경 사항 관리하기

코딩 에이전트가 프로젝트 파일을 직접 수정하는 환경에서는 버전 관리가 특히 중요하다.

Git은 파일의 변경 이력을 기록하고, 특정 시점의 변경 사항을 비교하거나 이전 상태로 돌아갈 수 있도록 도와주는 버전 관리 도구다.

수업에서는 git init으로 로컬 저장소를 만들고, 변경된 파일을 스테이징한 뒤 커밋하는 흐름을 다뤘다.

git init
git status
git add .
git commit -m "Implement phase 1"

각 명령어의 역할은 다음과 같다.

• git init: 현재 디렉터리를 Git 저장소로 초기화한다.

• git status: 변경된 파일과 현재 저장소 상태를 확인한다.

• git add: 커밋에 포함할 변경 사항을 스테이징한다.

• git commit: 스테이징한 변경 사항을 하나의 이력으로 기록한다.

Git 저장소는 원격 저장소가 없어도 로컬에서 변경 이력을 관리할 수 있다. 따라서 코딩 에이전트가 작업한 내용을 단계별로 커밋해 두면 다음 작업에서 문제가 발생했을 때 이전 상태와 비교하거나 복구하기가 쉬워진다.

물론 커밋 자체가 코드의 정상 작동을 보장하는 것은 아니다. 테스트와 코드 검토를 함께 진행해야 한다.

7-4. .gitignore와 UV로 프로젝트 환경 관리하기

Python 프로젝트의 파일과 실행 환경을 관리하는 방법도 함께 다뤘다.

.gitignore는 Git이 추적하지 않아야 할 파일이나 디렉터리를 지정하는 설정 파일이다. 예를 들어 Python 실행 중 생성되는 캐시 파일이나 가상환경 디렉터리 등은 프로젝트의 목적에 따라 추적 대상에서 제외할 수 있다.

UV는 Python 버전과 프로젝트 의존성을 관리하는 도구다. 의존성은 프로그램이 실행되는 데 필요한 외부 라이브러리를 의미한다.

수업에서는 pyproject.toml과 UV를 활용해 프로젝트 환경을 구성하고, uv sync로 의존성을 동기화하는 흐름을 살펴봤다.

uv sync
uv run python main.py

uv sync는 프로젝트 설정과 잠금 파일 등을 바탕으로 필요한 의존성을 동기화한다. uv run은 프로젝트 환경에서 명령어를 실행할 때 사용한다.

이처럼 규칙 파일, 작업 계획, Git, .gitignore, UV를 함께 활용하면 코딩 에이전트가 생성한 코드를 보다 일관된 환경에서 관리할 수 있다.

8. 오늘 어려웠던 점과 해결 방향

오늘은 새로운 도구가 여러 개 등장한 만큼, 각각의 역할을 구분해서 이해하는 것이 중요했다.

8-1. Windows, WSL, Docker 환경 구분

Windows와 WSL, Docker 컨테이너는 서로 연결되어 있지만 완전히 같은 환경은 아니다. 명령어가 설치된 위치나 PATH 설정, Docker Desktop과 WSL의 연동 상태에 따라 같은 명령어도 다르게 동작할 수 있다.

따라서 문제가 생겼을 때 무조건 재설치부터 하기보다 현재 어떤 환경에서 명령어를 실행하고 있는지, Docker 엔진에 연결되어 있는지, 필요한 경로가 설정되어 있는지부터 확인해야 한다.

8-2. Webhook 요청과 데이터 구조 확인

Webhook을 테스트할 때는 URL뿐 아니라 워크플로의 실행 상태와 테스트·운영 모드, 요청 데이터의 구조, 응답 설정까지 확인해야 한다.

특히 외부에서 전달한 JSON이 어느 필드에 들어오는지에 따라 $json이나 $json.body처럼 참조해야 하는 경로가 달라질 수 있다. 다음 노드에서 필요한 데이터가 실제로 전달되는지도 확인해야 한다.

8-3. 규칙 우선순위와 실행 경로 확인

Switch와 같은 조건 분기에서는 규칙의 순서가 결과에 영향을 줄 수 있다. 보안 관련 키워드가 소프트웨어 관련 규칙에 먼저 걸리는 경우처럼, 조건이 겹칠 때는 우선순위를 조정해야 한다.

또한 n8n의 실행 기록을 확인하면 어떤 조건이 적용되었고 어느 경로로 분기했는지 파악하는 데 도움이 된다.

8-4. AI 코딩 결과 검증

코딩 에이전트에게 한 번에 많은 기능을 요청하면 빠르게 결과물을 만들 수 있지만, 문제가 발생했을 때 원인을 찾기 어려울 수 있다.

반대로 작업을 단계별로 나누고 각 단계의 변경 사항을 확인하면 구현 범위를 명확하게 관리할 수 있다. 여기에 Git 커밋을 더하면 이전 상태와 비교할 수 있어 문제를 되돌리기도 수월해진다.

오늘 배운 내용을 통해 AI 코딩 도구를 잘 활용한다는 것은 단순히 코드를 많이 생성하는 것이 아니라, 작업을 적절하게 나누고 결과를 확인하며 안전하게 변경 이력을 관리하는 것이라는 점을 이해했다.

9. 현재 나의 상태와 복습할 부분

오늘은 Docker와 n8n의 기본 구조, 워크플로의 조건 분기, Webhook 연동 방식, LLM 기반 문의 처리, 폴백 개념, CLI 코딩 에이전트의 작업 관리 방식을 폭넓게 접했다.

특히 Python 미니 플로우를 n8n과 연결하는 흐름을 통해 직접 작성한 코드가 다른 자동화 도구와 어떻게 연동될 수 있는지 살펴볼 수 있었다.

다만 여러 도구를 한 번에 다룬 만큼 모든 설정과 명령어를 완전히 익혔다고 보기는 어렵다. 다음 부분은 추가로 복습할 필요가 있다.

• Docker 이미지, 컨테이너, 볼륨, 네트워크의 역할과 차이

• Docker Compose 명령어별 동작 차이

• WSL과 Docker Desktop의 연동 및 실행 환경 확인

• n8n의 IF와 Switch, 데이터 전달 및 표현식

• Webhook 테스트 URL과 운영 URL의 차이

• HTTP 요청과 응답 코드의 의미

• 장애 감지와 대체 경로를 연결하는 폴백 설계

• Git의 스테이징, 커밋, 변경 사항 비교와 복구

• UV를 이용한 Python 의존성 관리

• 코딩 에이전트의 단계별 작업 계획과 생성 코드 검증

앞으로는 각 도구의 개념을 따로 외우는 데 그치지 않고, 작은 예제를 직접 구성하면서 연결 관계를 익히는 것이 좋겠다.

10. 오늘의 회고

오늘 학습에서 가장 크게 느낀 점은 AI를 활용한 개발에서 중요한 것은 코드 생성 자체보다 코드를 실행하고, 여러 서비스를 연결하고, 실패 상황에 대응하며, 변경 사항을 관리하는 전체 과정이라는 것이다.

n8n에서는 노드를 연결해 업무 흐름을 만들고, Webhook으로 외부 프로그램과 통신하며, LLM으로 문의를 분류할 수 있다. Python 미니 플로우와 연결하면 한 경로에 문제가 발생했을 때 다른 경로로 처리하도록 설계할 수도 있다.

CLI 코딩 에이전트 역시 마찬가지다. 원하는 기능을 자연어로 요청하는 것만으로 개발이 끝나는 것이 아니라, 프로젝트를 분석하고 작업 계획을 세우며 단계별로 구현하고 테스트해야 한다. Git으로 변경 이력을 남기는 것도 이런 과정의 중요한 일부다.

앞으로 AI 오케스트레이션 개발자로 성장하기 위해서는 개별 기술의 사용법뿐 아니라 여러 구성 요소가 함께 동작하도록 연결하는 능력을 길러야 한다.

오늘 배운 Docker, n8n, Webhook, 폴백, Git, 코딩 에이전트 활용법을 하나의 개발 흐름으로 연결해 이해하는 것을 다음 학습 목표로 삼고 싶다.

핵심 정리

• WSL과 Docker: Linux 개발 환경과 컨테이너 기반 실행 환경 구성

• Docker Compose: 여러 서비스의 실행 및 관리

• n8n: 노드 기반 워크플로 자동화와 조건 분기

• Webhook: HTTP 요청을 통한 외부 프로그램 연동

• LLM: 문의 분류, FAQ 기반 응답, 담당자 전달

• Fallback: 우선 경로에 장애가 발생했을 때 대체 경로로 전환

• CLI 코딩 에이전트: 프로젝트 분석, 작업 계획, 단계별 코드 생성

• Git과 UV: 코드 변경 이력 및 Python 개발 환경 관리