AI 오케스트레이션 캠프/일차별 회고

66일차 회고｜n8n 워크플로 자동화와 AI 코딩 에이전트 활용｜AI 오케스트레이션 개발자 국비지원

랩보다 AI 더 잘해지기 2026. 10. 16. 18:45
728x90

 

오늘 학습의 핵심은 AI 코딩 에이전트를 활용해 워크플로를 만들고, 생성된 결과를 직접 검증하는 과정이었다. n8n의 노드와 데이터 흐름을 이해하는 것부터 시작해 회의록을 정리하는 자동화, 가위바위보 게임의 로직 설계, CLI·TUI 기반 도구 개발 구상, 프로젝트 규칙과 라이선스 확인까지 폭넓게 다뤘다.

 

특히 인상 깊었던 점은 AI에게 원하는 결과를 요청하는 것과 실제로 올바르게 동작하는 결과물을 만드는 것은 별개의 문제라는 사실이다. 요구사항을 구체적으로 정의하고, 결과를 원본과 비교하고, 오류를 근거로 수정하는 과정이 중요했다.

1. 오늘 배운 내용: n8n 워크플로와 데이터 흐름

n8n은 여러 작업을 노드(Node) 단위로 연결해 자동화하는 도구다. 각 노드는 특정 작업을 수행하고, 앞선 노드의 결과를 다음 노드에 전달한다. 오늘은 회의록에서 할 일을 추출하는 시나리오를 중심으로 노드의 역할과 데이터 흐름을 살펴봤다.

주요 노드의 역할

노드·기능역할
Trigger 워크플로 실행을 시작한다.
LLM 회의록처럼 자연어로 된 내용을 해석하고 필요한 정보를 추출한다.
Code 정해진 규칙에 따라 데이터를 가공하거나 계산한다.
IF / Switch 조건에 따라 서로 다른 경로로 분기한다.
Split Out 배열에 담긴 여러 항목을 개별 데이터로 분리한다.
Aggregate 여러 개의 항목을 다시 모아 하나의 데이터 구조로 만든다.
Merge 서로 다른 경로에서 나온 데이터를 결합한다.
Edit Fields 데이터의 필드를 추가하거나 수정한다.

처음에는 노드의 이름과 기능을 익히는 데 집중했다면, 이번에는 각 노드가 어떤 데이터를 입력받고 무엇을 출력하며, 그 결과가 다음 단계로 어떻게 전달되는지를 함께 살펴보는 것이 중요했다.

예를 들어 회의록을 처리하는 자동화는 다음과 같은 흐름으로 구성할 수 있다.

회의록 입력

회의 제목과 본문

LLM을 이용한 내용 분석

참석자와 할 일, 담당자, 마감일 추출

데이터 정리 및 규칙 적용

필드 정규화, 누락값 처리, 우선순위 설정

조건별 처리와 결과 출력

정리된 할 일 목록과 보고서

이 흐름은 이해를 돕기 위한 개념도다. 실제 워크플로의 노드 구성과 연결 방식은 요구사항에 따라 달라질 수 있다.

LLM과 일반 코드의 역할 구분

오늘 학습에서 중요하게 다뤄진 부분은 어떤 작업을 LLM에 맡기고, 어떤 작업을 일반 코드로 처리할 것인가였다.

  • LLM이 적합한 작업: 자연어 회의록에서 할 일이나 담당자, 일정처럼 의미를 해석해야 하는 정보 추출

  • 일반 코드가 적합한 작업: 빈 값 확인, 날짜 비교, 우선순위 설정, 데이터 형식 변환

  • IF·Switch가 적합한 작업: 이미 정해진 조건에 따라 실행 경로를 나누는 작업

모든 작업을 LLM으로 처리하면 불필요한 호출이 늘어나고 비용과 응답 시간이 증가할 수 있다. 반대로 의미를 해석해야 하는 작업까지 단순한 조건문으로 처리하려 하면 규칙이 복잡해질 수 있다.

따라서 자동화를 설계할 때는 문제의 성격을 먼저 파악하고, 각 단계에 적합한 도구를 선택해야 한다.

2. JSON과 데이터 구조 이해하기

워크플로를 연결하려면 각 노드 사이에서 데이터가 어떤 형태로 전달되는지 이해해야 한다. 이때 자주 사용하는 형식이 JSON이다.

JSON은 데이터를 키와 값의 형태로 표현하는 형식이다. 객체(Object), 배열(Array), 문자열(String), 숫자(Number), 불리언(Boolean), null 등을 사용해 정보를 구조화할 수 있다.

예를 들어 회의에서 추출한 할 일을 다음과 같이 표현할 수 있다.

{
  "task": "회의실 예약 규칙 개선",
  "owner": null,
  "deadline": null,
  "priority": "medium"
}

이 예시는 개념 설명을 위한 데이터다. 담당자와 마감일이 확인되지 않았을 때는 임의로 값을 만들어 넣기보다, 미지정 또는 미정 상태로 표현하는 것이 안전하다.

여기서 주의할 점은 JSON처럼 보이는 문자열과 실제 JSON 객체가 항상 같지는 않다는 것이다. LLM이 JSON 형식의 텍스트를 반환하더라도 다음 노드에서 바로 객체처럼 사용할 수 없는 경우가 있다. 이때는 결과가 실제 데이터 구조로 변환되어 있는지 확인하고, 필요하면 파싱(Parsing)을 거쳐야 한다.

Split Out과 Aggregate도 이 데이터 구조와 연결된다. 배열을 개별 항목으로 분리한 뒤 각각 처리하고, 필요하다면 결과를 다시 모을 수 있다.

이 개념은 단순히 n8n을 사용하는 데서 끝나지 않는다. API 응답을 처리하거나 여러 서비스 사이에서 데이터를 주고받을 때도 중요하다.

3. AI 코딩 에이전트가 만든 결과를 검증하기

오늘은 AI 코딩 에이전트가 기존 워크플로를 분석하거나 새로운 워크플로를 구성하도록 하는 사례를 살펴봤다. 다만 강의에서 시연한 내용과 내가 직접 완료한 실습을 구분할 필요가 있다. 강사가 보여준 OCR, 원격 접속, TUI 도구 제작 등의 사례를 모두 직접 구현한 것은 아니다.

같은 요구사항에도 결과가 달라질 수 있다

강의에서는 가위바위보 게임을 예시로 입력, 처리, 출력을 설계하는 방법을 다뤘다.

  • 입력: 사용자가 바위·보·가위 중 하나를 선택한다.

  • 처리: 컴퓨터가 선택을 무작위로 결정하고 두 선택을 비교한다.

  • 출력: 사용자 승리, 컴퓨터 승리 또는 무승부를 반환한다.

이처럼 간단한 기능도 AI 코딩 에이전트에 어떤 방식으로 구현하라고 요청하는지에 따라 워크플로 구조가 달라질 수 있다.

예를 들어 어떤 구성은 Code 노드 하나에 로직을 모으고, 다른 구성은 IF 또는 Switch 노드로 분기할 수 있다. 자연어 판단이 필요한 것처럼 요청하면 LLM 노드가 추가될 수도 있다.

여기서 중요한 것은 하나의 구현 방식만 정답이라고 생각하지 않는 것이다. 요구사항을 충족하는지, 데이터가 올바르게 전달되는지, 불필요한 노드가 추가되지는 않았는지를 기준으로 결과를 평가해야 한다.

필요한 경우 프롬프트에 제약 조건을 명시할 수도 있다.

  • LLM 노드를 사용하지 않고 조건문으로 구현한다.

  • Code 노드 대신 기본 제공 노드를 사용한다.

  • 각 노드의 입력과 출력을 명확하게 정의한다.

  • 실행 결과와 테스트 방법을 문서로 남긴다.

AI에게 단순히 기능을 만들어 달라고 요청하는 것보다 어떤 방식으로 구현해야 하고, 어떤 조건을 만족해야 하는지까지 전달하는 것이 더 중요하다는 점을 배웠다.

4. 회의록 자동화에서 발견한 문제: 할 일을 누락하는 경우

회의록 자동화 사례에서는 프롬프트를 작성하는 것만큼 결과를 검증하는 과정이 중요했다.

회의록에는 여러 가지 업무가 섞여 있다. 어떤 항목은 담당자와 마감일이 명확하지만, 어떤 항목은 아직 담당자가 정해지지 않았거나 다음 회의에서 결정해야 한다. 이런 상황에서 AI가 일부 항목을 추출하지 않거나, 할 일을 임의로 생략할 수 있다.

강의에서는 예상한 할 일의 개수와 실제 추출 결과가 다른 상황을 살펴보고, 누락된 항목을 확인한 뒤 프롬프트를 개선하는 과정을 다뤘다.

예를 들어 원본 회의록에 네 가지 할 일이 있는데 결과에는 세 가지만 들어 있다면, 결과가 자연스럽게 작성되었다는 이유만으로 성공했다고 판단할 수 없다. 원본과 결과를 대조해 어떤 항목이 빠졌는지 확인해야 한다.

프롬프트를 구체적으로 작성하는 방법

모호한 지시보다 처리 기준을 명확하게 정하는 편이 좋다.

모호한 지시구체적인 지시
할 일을 정리해 줘. 회의록에 등장하는 모든 할 일을 항목별로 추출한다.
담당자를 정리해 줘. 담당자가 명시되지 않았다면 미지정으로 표시한다.
일정을 정리해 줘. 마감일이 확인되지 않으면 미정으로 표시한다.
중요한 일을 먼저 보여 줘. 마감일 등 사전에 정의한 기준에 따라 우선순위를 설정한다.
결과를 확인해 줘. 원본에 있는 할 일과 추출 결과를 대조하고 누락 여부를 확인한다.

마감일에 따른 우선순위 역시 명시적인 규칙으로 정의할 수 있다. 강의에서 다룬 예시처럼 오늘까지 처리해야 하는 업무는 높은 우선순위로, 이번 주 안에 처리할 업무는 중간 우선순위로 분류하는 방식이다.

단, 이런 규칙은 실제 업무의 요구사항에 맞게 조정해야 한다.

이번 내용을 통해 프롬프트 개선은 단순히 문장을 더 길게 쓰는 일이 아니라, AI가 임의로 해석할 수 있는 부분을 줄이고 검증 가능한 기준을 만드는 과정이라는 점을 이해했다.

5. CLI·TUI·GUI와 원격 개발 환경

오늘은 AI 코딩 에이전트의 활용 범위를 넓혀 터미널 환경과 원격 개발, 간단한 도구 제작에 관한 내용도 다뤘다.

CLI, TUI, GUI의 차이

 
 

CLI (Command-Line Interface)

터미널에 명령어를 입력해 작업하는 방식이다. 파일 관리, 프로그램 실행, 자동화 스크립트, 서버 관리 등에 활용할 수 있다.

 
 

TUI (Text User Interface)

터미널 안에서 메뉴, 목록, 선택 화면 등을 제공하는 방식이다. 일반적인 명령어 입력보다 상호작용이 편리하면서도 GUI보다 가벼운 도구를 만들 수 있다.

 
 

GUI (Graphical User Interface)

버튼, 창, 아이콘 등 그래픽 요소를 이용하는 방식이다. Postman처럼 API 요청을 설정하고 응답을 확인하는 도구가 대표적이다.

강의에서는 파일과 폴더의 용량을 확인하는 CLI 도구인 dua를 살펴보고, 이를 바탕으로 폴더를 탐색할 수 있는 TUI 도구를 만드는 아이디어도 다뤘다. Python의 Textual 같은 라이브러리를 활용하면 터미널에서도 대화형 화면을 구성할 수 있다.

또한 HTTP 요청을 보내는 도구를 직접 만든다면 URL, HTTP 메서드, 요청 본문을 입력하고 응답을 확인하는 화면을 구성할 수 있다. 내부적으로 curl을 활용하는 방법도 생각할 수 있다.

이 부분은 강의에서 소개하고 시연한 개발 아이디어를 정리한 것이며, 해당 도구를 완성해 실행까지 검증했다고 의미하는 것은 아니다.

SSH와 SCP

원격 개발 환경에 관한 설명도 있었다.

  • SSH: 다른 컴퓨터에 원격으로 접속해 명령을 실행하는 프로토콜

  • SCP: SSH를 기반으로 파일을 복사하는 도구

  • ~/.ssh/config: 원격 서버의 접속 정보를 별칭 등으로 관리하는 설정 파일

  • ~/.ssh/authorized_keys: 공개키 기반 인증에서 허용할 공개키를 등록하는 파일

SSH 키를 이용할 때는 공개키를 원격 서버에 등록하고, 개인키는 안전하게 보관해야 한다. 개인키를 공유하거나 저장소에 올리지 않도록 주의해야 한다.

강의에서는 로컬 환경에서 원격 Linux 서버로 접속하고, 파일을 전송해 작업하는 과정을 설명했다. 이런 방식은 로컬 컴퓨터와 서버의 역할을 나누어 개발할 때 유용하다.

6. Rust와 메모리 안전성

강의에서는 시스템 프로그래밍 언어인 C와 Rust의 차이도 설명했다.

C는 운영체제나 저수준 시스템 개발에서 오랫동안 사용되어 온 언어다. 하지만 메모리를 직접 다루는 과정에서 잘못된 메모리 접근과 같은 문제가 발생할 수 있다.

Rust는 소유권(Ownership)과 대여(Borrowing) 등의 규칙을 통해 많은 메모리 안전성 문제를 컴파일 단계에서 방지하도록 설계된 언어다.

여기서 메모리 안전성과 메모리 누수는 구분할 필요가 있다. 메모리 누수는 더 이상 필요하지 않은 메모리가 해제되지 않아 계속 사용되는 문제이고, 메모리 안전성은 메모리에 올바르게 접근하고 사용하는 것과 관련된다. Rust가 모든 메모리 문제를 자동으로 해결해 주는 것은 아니다.

이번 강의에서 Rust를 직접 활용한 프로젝트를 완성했다기보다는, 시스템 도구를 개발할 때 언어의 특성과 안전성을 고려해야 한다는 점을 이해하는 데 의미가 있었다.

7. AI 코딩 에이전트를 활용할 때 지켜야 할 기준

오늘 후반부에서는 AI 코딩 에이전트가 코드를 작성하는 것뿐 아니라 프로젝트 구조를 만들고, 작업 계획을 세우고, 문서를 작성하고, 테스트를 실행하도록 활용하는 방법을 다뤘다.

하지만 에이전트가 생성한 결과를 그대로 받아들이면 문제가 생길 수 있다. 프로젝트마다 요구사항이 다르고, 같은 요청에도 서로 다른 구조나 라이브러리 버전을 선택할 수 있기 때문이다.

프로젝트 규칙과 작업 기록

AGENTS.md 같은 프로젝트 지침 파일을 활용하면 코딩 에이전트가 따라야 할 규칙을 명시할 수 있다. 사용하는 도구에 따라 지침 파일의 이름과 적용 방식은 다를 수 있으므로, 실제로 해당 에이전트가 지침을 읽고 따르는지도 확인해야 한다.

지침에 포함할 수 있는 항목은 다음과 같다.

  • 프로젝트에서 사용할 언어와 라이브러리

  • 디렉터리 및 파일 구성 규칙

  • 코드 작성과 테스트 기준

  • 문서화 방식

  • 작업 단계와 완료 조건

  • 실행 결과 및 오류 기록 방법

작업 계획도 대화창에만 남겨두기보다 Markdown 문서로 기록하면 이후에 다시 확인하기 쉽다. 날짜별 작업 폴더에 요구사항, 구현 단계, 테스트 결과를 정리하는 방식도 소개됐다.

이런 기록은 에이전트가 작업한 내용을 사람이 검토할 수 있게 하고, 문제가 발생했을 때 어느 단계에서 오류가 생겼는지 추적하는 데 도움이 된다.

라이브러리 버전과 Python 호환성 확인

AI가 프로젝트를 생성하면서 특정 Python 버전을 최소 요구사항으로 지정할 수도 있다. 하지만 그 버전이 실제로 필요한지는 별도로 확인해야 한다.

예를 들어 다음 항목을 검토할 수 있다.

  1. 사용하려는 라이브러리가 지원하는 Python 버전

  2. 프로젝트 코드에서 실제로 사용하는 문법과 기능

  3. pyproject.toml에 정의된 의존성 및 버전 범위

  4. 테스트와 실행 결과

AI가 Python 3.11 이상을 요구한다고 해서 반드시 그 버전이 필요한 것은 아니다. 라이브러리의 지원 범위와 코드에서 사용하는 기능을 확인한 뒤 적절한 버전을 결정해야 한다.

오픈소스 라이선스 확인

GitHub에 공개된 프로젝트를 가져와 수정하거나 다른 언어로 변환하는 사례도 다뤘다.

오픈소스라는 이유만으로 모든 코드를 제한 없이 사용할 수 있는 것은 아니다. 라이선스에 따라 저작권 고지, 라이선스 사본 포함, 소스 코드 공개와 관련된 의무 등이 달라질 수 있다.

라이선스확인할 사항
MIT 저작권 및 라이선스 고지 유지 등
BSD 라이선스 종류별 고지 및 배포 조건
Apache 2.0 라이선스 조건, 고지, 특허 관련 조항 등
GNU GPL 배포 방식 등에 따른 소스 코드 제공 의무 등

실제 프로젝트를 재사용할 때는 저장소의 LICENSE 파일뿐 아니라 포함된 라이브러리와 의존성의 라이선스도 확인해야 한다. 상업적 이용 가능 여부는 라이선스 전문과 사용·배포 방식에 따라 판단해야 한다.

8. 오늘 새롭게 이해한 점

오늘 배운 내용은 서로 다른 주제처럼 보이지만 하나의 흐름으로 연결된다.

첫째, 자동화는 노드를 연결하는 것만으로 완성되지 않는다. 각 단계에서 어떤 데이터를 받고, 어떻게 처리하고, 무엇을 다음 단계로 전달하는지 명확해야 한다.

둘째, AI가 만든 결과는 실행된다는 사실만으로 올바르다고 판단할 수 없다. 원본과 결과를 비교하고, 요구사항을 충족하는지 확인하고, 누락과 오류를 수정해야 한다.

셋째, 좋은 프롬프트는 결과를 구체적으로 설명하는 데서 끝나지 않는다. 사용할 도구와 구현 방식, 예외 처리, 누락값 처리, 검증 기준까지 명확하게 정의해야 한다.

넷째, 개발 과정에서는 코드 외에도 프로젝트 규칙, 버전 관리, 라이선스, 작업 기록과 보안이 중요하다. AI가 개발 속도를 높여 주더라도 최종적인 검토와 판단은 개발자의 몫이다.

9. 복습할 부분과 앞으로의 학습 계획

오늘 다룬 내용을 바탕으로 다음 항목을 복습할 필요가 있다.

  • n8n의 IF와 Switch, Split Out과 Aggregate의 차이 이해하기
  • JSON 객체와 배열, 문자열로 반환된 JSON의 차이 확인하기
  • 회의록에서 추출한 할 일과 원본을 비교해 누락 여부를 검증하는 방법 익히기
  • LLM 처리와 일반 코드 처리의 기준 정리하기
  • SSH 키 인증과 원격 파일 전송의 기본 흐름 복습하기
  • AI가 생성한 프로젝트의 Python 버전과 라이브러리 호환성 확인하기
  • 프로젝트 지침 파일과 Markdown 작업 기록을 활용하는 방법 정리하기
  • 오픈소스 라이선스의 기본적인 차이 이해하기

특히 n8n에서는 노드별 기능을 암기하는 것보다 작은 워크플로를 구성하고, 입력 데이터가 각 노드를 통과하면서 어떻게 바뀌는지 확인하는 연습이 필요하다. AI 코딩 에이전트 역시 결과를 생성하는 데 그치지 않고, 요구사항과 테스트 결과를 기준으로 검토하는 습관을 들이고 싶다.

10. 오늘의 회고

오늘은 AI 코딩 에이전트를 활용하는 방법을 단순한 코드 생성에서 워크플로 설계, 데이터 처리, 검증, 문서화로 확장해 살펴봤다.

가장 중요하게 느낀 점은 AI를 잘 활용하는 능력은 요청을 잘 작성하는 것뿐 아니라, 결과가 올바른지 판단할 수 있는 기준을 갖추는 데서 나온다는 것이다.

회의록에서 할 일을 추출하는 과정에서는 누락 여부를 확인해야 하고, 워크플로를 설계할 때는 각 노드의 역할과 데이터 흐름을 이해해야 한다. 코드 생성에서도 라이브러리 버전, 프로젝트 규칙, 라이선스와 보안까지 살펴야 한다.

아직 모든 도구와 개념을 능숙하게 활용할 수 있는 단계는 아니다. 앞으로는 AI가 만든 결과를 그대로 받아들이기보다 요구사항을 먼저 정리하고, 작은 단위로 실행하고, 결과를 확인하고, 수정한 내용을 기록하는 방식으로 학습해 나가고 싶다.

자동화를 만드는 기술과 자동화의 결과를 검증하는 능력은 함께 성장해야 한다. 오늘 학습은 그 두 가지를 함께 바라보는 계기가 됐다.

핵심 정리

  • n8n은 노드 간 데이터 흐름과 역할 분담을 이해해야 제대로 활용할 수 있다.

  • LLM은 자연어 해석에, 일반 코드는 명확한 규칙 처리에 적합하다.

  • AI가 생성한 결과는 원본 대조와 테스트를 통해 검증해야 한다.

  • 프로젝트 지침, 버전 호환성, 라이선스, 보안과 작업 기록도 개발의 일부다.

  • AI 코딩 에이전트의 결과를 검토하고 판단하는 능력이 중요하다.