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

1. 이번 주 학습 요약

이번 주는 세 번째 미니프로젝트를 마무리하고, AI 워크플로우와 업무 자동화 기술로 학습 범위를 확장한 한 주였다.

미니프로젝트에서는 어르신 돌봄 서비스를 개발하며 AutoHealing 기능을 보완하고, 장애 상황에서 시스템이 어떻게 대응하는지 검증했다. 이후 MiniFlow, Docker, n8n을 학습하면서 여러 작업을 연결하고 자동화하는 방법을 살펴봤다. 마지막으로 AI 코딩 에이전트를 활용해 코드를 분석하고 수정할 때 필요한 요구사항 정의와 결과 검증의 중요성도 배웠다.

이번 주의 핵심 학습은 크게 세 가지로 정리할 수 있다.

• 시스템 안정성: 장애 대응, 복구 성공 기준, 데이터 무결성, 통합 테스트

• AI 워크플로우와 자동화: MiniFlow, Docker, n8n, 노드 기반 작업 흐름

• AI 개발 도구 활용: AI 코딩 에이전트, 요구사항 구체화, 생성 결과 검증

처음에는 개별 기능을 구현하고 실행하는 데 집중했다면, 이번 주에는 기능들이 연결된 전체 시스템이 올바르게 작동하는지 확인하고 반복 업무를 어떻게 자동화할 것인지 고민하는 단계로 나아갔다.

2. 미니프로젝트에서 배운 시스템 안정성

실행 성공과 복구 성공은 다르다

세 번째 미니프로젝트에서는 어르신 돌봄 서비스의 AutoHealing 기능을 보완하고 장애 상황을 검증했다.

AutoHealing은 시스템에 장애가 발생했을 때 이를 감지하고 복구를 시도하는 기능이다. 단순히 오류를 처리하거나 재시도하는 것에서 끝나는 것이 아니라, 실제로 기능이 정상 상태로 돌아왔는지 확인하는 과정이 중요하다.

예를 들어 바이탈 데이터를 가져오는 과정에서 오류가 발생했다고 가정해 보자.

재시도 후 응답을 받았더라도 필수 데이터가 누락되어 있다면 정상적으로 복구됐다고 보기 어렵다. 반대로 일부 기능에 문제가 생겼더라도 대체 경로를 통해 서비스를 유지할 수 있다면, 정해진 기준에 따라 복구 여부를 판단할 수 있다.

프로젝트에서는 장애 시험 12회가 모두 기대한 동작을 수행했지만 실제 복구율은 50%로 나타났다.

처음에는 두 결과가 서로 모순되는 것처럼 보일 수 있다. 하지만 장애를 예상한 방식으로 처리했다는 것과 실제 기능이 복구됐다는 것은 서로 다른 기준이다.

이 경험을 통해 테스트 결과를 해석할 때는 단순히 성공과 실패를 기록하는 것이 아니라, 무엇을 성공으로 정의했는지 먼저 명확하게 해야 한다는 점을 배웠다.

데이터가 없다는 사실도 중요하다

바이탈 데이터를 저장할 때는 일부 항목만 전달되는 상황도 고려해야 했다.

심박수는 전달됐지만 혈압 데이터가 없다면, 혈압을 임의의 정상값으로 채워서는 안 된다. 데이터가 누락됐다는 사실을 정상이라는 의미로 바꾸면 이후 위험 분석이나 알림 과정에서 잘못된 판단으로 이어질 수 있기 때문이다.

따라서 실제로 수집된 데이터와 수집되지 않은 데이터를 구분하고, 누락된 값은 정해진 방식으로 처리해야 한다.

데이터베이스 구조를 변경할 때도 새로운 컬럼을 추가하는 것만으로 끝나지 않는다. 기존 데이터와 ID가 유지되는지, 변경 도중 문제가 발생하면 데이터를 안전하게 보호할 수 있는지도 확인해야 한다.

이 과정에서 데이터베이스 마이그레이션, 트랜잭션, 롤백의 필요성을 이해했다.

• 마이그레이션(Migration): 데이터베이스 구조를 변경하는 과정

• 트랜잭션(Transaction): 여러 데이터 변경 작업을 하나의 논리적 단위로 처리하는 방법

• 롤백(Rollback): 문제가 발생했을 때 변경 작업을 취소하고 이전 상태로 되돌리는 것

이러한 개념은 AI 워크플로우에서도 중요하다. 담당자나 마감일이 확인되지 않았을 때 임의로 값을 만들어 넣기보다, 미지정 또는 미정 상태로 표현하고 다음 단계에서 적절하게 처리해야 한다.

협업에서는 데이터 계약이 중요하다

팀 프로젝트에서는 각자 구현한 기능이 개별적으로 정상 작동하더라도, 하나의 서비스로 연결했을 때 문제가 발생할 수 있다.

이때 중요한 개념이 데이터 계약(Data Contract)이다. 데이터 계약은 기능 사이에서 어떤 데이터를 어떤 형식과 의미로 주고받을지 정한 약속이다.

입력 항목이나 상태값, 오류 응답 형식이 서로 다르면 기능을 연결하는 과정에서 문제가 발생할 수 있다. 따라서 개인이 작성한 코드만 확인하는 것으로는 충분하지 않다. 팀에서 합의한 최신 데이터 구조와 실제 구현이 일치하는지도 확인해야 한다.

재시도 횟수와 타임아웃도 마찬가지다.

예를 들어 '3회 재시도'라는 표현은 최초 호출을 포함해 총 3회 실행한다는 의미일 수도 있고, 최초 호출 이후 3회 더 실행한다는 의미일 수도 있다. 타임아웃 역시 전체 요청에 적용하는지, 내부 모델 호출에 적용하는지에 따라 동작이 달라진다.

협업에서는 코드를 나누어 작성하는 것만큼이나 같은 규칙을 공유하고, 연결된 결과를 함께 검증하는 과정이 중요하다.

이번 미니프로젝트를 통해 오류를 무조건 없애는 것보다, 장애가 발생하더라도 잘못된 데이터나 검증되지 않은 결과가 다음 단계로 전달되지 않도록 만드는 것이 중요하다는 점을 배웠다.

우리 팀은 최종 발표에서 1등을 기록했다. 의미 있는 결과였지만, 앞으로 다른 프로젝트에서도 활용할 수 있는 중요한 배움은 기능을 구현하고 검증하는 과정에 있었다.

관련 회고: 62일차 회고 · 63일차 회고

3. MiniFlow로 이해한 AI 워크플로우

미니프로젝트를 마친 뒤에는 AI를 활용해 여러 작업을 연결하고 반복 업무를 자동화하는 방법을 학습했다.

워크플로우(Workflow)는 여러 작업을 일정한 순서로 연결해 실행하는 구조다. 각 작업을 노드(Node)라고 하고, 노드 사이의 실행 순서와 데이터 전달 관계를 엣지(Edge)라고 한다.

예를 들어 사용자가 날씨를 물어보는 서비스를 만든다면 다음과 같이 구성할 수 있다.

1. 사용자가 지역과 질문을 입력한다.

2. 날씨 조회 도구가 필요한 데이터를 가져온다.

3. LLM이 조회 결과를 바탕으로 답변을 생성한다.

4. 사용자에게 최종 결과를 전달한다.

LLM(Large Language Model)은 자연어를 이해하고 생성하는 대규모 언어 모델이다.

모든 작업을 LLM에 맡기는 대신, 정해진 데이터를 조회하는 작업은 도구가 담당하고 결과를 해석해 자연스러운 답변을 만드는 작업은 LLM이 담당하도록 역할을 나눌 수 있다.

수업에서는 Python 기반의 간단한 워크플로우 엔진인 MiniFlow를 통해 LLM, 외부 도구, 메모리, FAQ 데이터를 조합하는 사례를 살펴봤다.

특히 JSON 파일에 정의된 노드와 연결 관계를 수정해 워크플로우에 기능을 추가하는 방식이 인상적이었다. 기존 구조를 이해한 뒤 필요한 부분을 변경하면 전체 시스템을 처음부터 다시 만들지 않고도 기능을 확장할 수 있다.

사내 헬프데스크 FAQ 자동화 사례에서는 직원의 로그인 오류나 비밀번호 관련 문의를 입력받고, 준비된 FAQ 데이터에서 관련 항목을 찾아 안내하는 흐름을 살펴봤다.

이 사례를 통해 자동화는 정상적인 입력을 처리하는 것뿐 아니라, 검색 결과가 없거나 필요한 정보가 부족할 때 어떻게 대응할지도 함께 설계해야 한다는 점을 이해했다.

4. Docker와 n8n으로 업무 자동화 이해하기

Docker: 실행 환경을 일관되게 관리하기

Docker는 애플리케이션 실행에 필요한 환경을 이미지와 컨테이너 형태로 구성하는 도구다.

개발 환경을 일정하게 유지하고 다른 환경에서도 비슷한 방식으로 실행할 수 있도록 돕는다.

이번 주에는 Windows와 WSL, Ubuntu, Docker 컨테이너가 서로 연결되어 있지만 동일한 환경은 아니라는 점을 살펴봤다.

Docker 이미지를 내려받았다는 사실과 컨테이너가 실행 중이라는 사실도 구분해야 한다. 명령어가 작동하지 않을 때 무조건 재설치하기보다는 현재 어떤 환경에서 명령어를 실행하고 있는지, Docker 엔진과 정상적으로 연결되어 있는지부터 확인해야 한다.

또한 Docker Compose를 이용해 여러 컨테이너의 실행 설정을 관리하는 방법과 컨테이너 실행, 중지, 로그 확인 등의 기본 명령어를 학습했다.

n8n: 노드를 연결해 반복 작업 자동화하기

n8n은 여러 서비스와 API, 코드, AI 모델을 노드로 연결해 자동화 워크플로우를 구성할 수 있는 도구다.

수업에서는 Manual Trigger로 워크플로우를 시작하고, Edit Fields 노드에서 데이터를 입력한 뒤 IF 노드로 조건을 검사해 처리 경로를 나누는 구조를 살펴봤다.

예를 들어 문의 내용에 '긴급'이라는 문자열이 포함되어 있다면 긴급 처리 경로로 보내고, 그렇지 않으면 일반 문의 경로로 전달할 수 있다.

여기서 중요한 것은 조건을 설정하는 것만이 아니다. 각 노드에서 데이터가 어떻게 전달되는지도 확인해야 한다.

중간 노드에서 기존 입력 필드가 유지되지 않으면 다음 단계에서 사용자 정보나 문의 내용을 활용하지 못할 수도 있기 때문이다.

워크플로우가 복잡해질수록 각 단계의 입력과 출력, 조건 분기, 데이터 변환 과정을 확인하는 습관이 중요하다.

모든 작업에 AI를 사용할 필요는 없다

n8n과 AI 워크플로우를 학습하면서 중요하게 느낀 점은 모든 작업에 AI를 사용할 필요는 없다는 것이었다.

자연어의 의미를 해석해야 하는 작업은 LLM에 맡길 수 있지만, 날짜를 비교하거나 필수 값이 비어 있는지 검사하는 작업은 일반 코드로 처리하는 편이 명확하다.

예를 들어 다음과 같이 역할을 구분할 수 있다.

• 회의록에서 할 일과 담당자 추출: LLM 활용

• 필수 값이 비어 있는지 확인: 일반 코드

• 조건에 따른 처리 경로 분기: IF·Switch 노드

• 여러 데이터 항목 분리 및 결합: Split Out·Aggregate·Merge 노드

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

따라서 워크플로우를 설계할 때는 사용할 수 있는 도구부터 선택하는 것이 아니라, 먼저 문제의 성격을 파악하고 각 단계에 적합한 도구를 배치해야 한다.

관련 회고: 64일차 회고 — AI 워크플로우·MiniFlow·업무 자동화 설계 · 65일차 회고 — Docker·n8n·AI 에이전트 자동화

5. AI 코딩 에이전트 활용과 결과 검증

이번 주 후반부에는 AI 코딩 에이전트를 활용해 기존 코드를 분석하고 수정하는 방법도 다뤘다.

AI 코딩 에이전트는 자연어로 전달한 요구사항을 바탕으로 코드를 분석하거나 파일을 수정하는 작업을 지원하는 도구다. 개발자가 모든 코드를 처음부터 작성하지 않아도 된다는 장점이 있지만, 생성된 결과가 요구사항을 정확하게 충족한다는 보장은 없다.

요구사항을 구체적으로 작성하기

예를 들어 회의록에서 할 일을 추출하도록 요청한다고 가정해 보자.

단순히 '회의록의 할 일을 정리해 줘'라고 요청하면 일부 항목이 빠지거나 담당자와 마감일이 임의로 해석될 수 있다.

반면 다음과 같이 기준을 명확하게 제시하면 결과를 검증하기 쉬워진다.

• 회의록에 등장하는 모든 할 일을 항목별로 추출한다.

• 담당자가 명시되지 않았다면 미지정으로 표시한다.

• 마감일이 확인되지 않으면 미정으로 표시한다.

• 원본 회의록과 추출 결과를 비교해 누락된 항목이 있는지 확인한다.

요구사항을 구체화하면 AI가 임의로 해석할 수 있는 범위를 줄이고, 결과가 올바른지 확인할 기준을 만들 수 있다.

자연스러운 결과와 정확한 결과는 다르다

원본 회의록에 네 가지 할 일이 있는데 결과에는 세 가지만 들어 있다면, 문장이 자연스럽게 작성됐더라도 작업이 성공했다고 판단할 수 없다.

따라서 원본과 결과를 대조하고 누락된 항목을 확인한 뒤 프롬프트를 개선해야 한다.

이는 미니프로젝트에서 장애 복구 결과를 검증했던 경험과도 연결된다.

시스템이 정상적으로 실행됐다는 로그만으로 실제 복구를 단정할 수 없었던 것처럼, AI가 결과를 생성했다는 사실만으로 결과의 정확성을 보장할 수는 없다.

두 경우 모두 중요한 것은 기대하는 결과를 명확하게 정의하고, 실제 결과가 그 기준을 충족하는지 확인하는 과정이다.

AI가 수정한 코드도 직접 확인하기

MiniFlow에서는 JSON 파일에 정의된 워크플로우를 수정하고, VS Code의 파일 비교 기능으로 변경 사항을 확인하는 방법을 살펴봤다.

또한 n8n의 데이터 흐름을 바탕으로 회의록 자동화와 가위바위보 게임의 입력·처리·출력 구조를 설계하는 사례를 다뤘다. CLI와 TUI 등 개발 환경의 개념, 프로젝트 규칙과 라이선스 확인에 관한 내용도 학습했다.

AI 코딩 에이전트를 활용할 때는 다음 순서로 작업하는 것이 중요하다고 생각했다.

1. 기존 코드와 파일 구조를 먼저 파악한다.

2. 변경할 내용과 지켜야 할 제약 조건을 구체적으로 전달한다.

3. 수정된 코드와 기존 코드의 차이를 확인한다.

4. 실행 결과와 테스트를 통해 요구사항 충족 여부를 검증한다.

5. 문제가 발생하면 원인을 확인하고 필요한 부분을 수정한다.

AI를 활용하면 구현 속도를 높일 수 있지만, 결과에 대한 책임까지 AI에 맡길 수는 없다. 도구를 잘 활용하는 능력과 결과를 판단하는 능력은 함께 필요하다.

관련 회고: 66일차 회고 — n8n 워크플로 자동화와 AI 코딩 에이전트 활용

6. 이번 주에 새롭게 이해한 점

이번 주 학습을 통해 기존에 알고 있던 개념을 조금 다른 관점에서 바라보게 됐다.

첫째, 기능 구현과 시스템 완성은 다르다.

개별 기능이 정상 작동해도 데이터 계약이 맞지 않거나 복구 결과가 검증되지 않으면 전체 시스템을 신뢰하기 어렵다. 기능을 연결한 뒤에는 통합된 상태에서 테스트해야 한다.

둘째, 자동화는 단순히 작업을 연결하는 일이 아니다.

정상적인 상황뿐 아니라 데이터 누락, 검색 실패, 잘못된 입력, 대체 경로가 없는 상황까지 고려해야 한다. 자동화할 범위와 사람이 개입해야 하는 시점을 함께 설계해야 한다.

셋째, AI는 모든 문제를 해결하는 도구가 아니다.

자연어 해석은 LLM에 맡기고, 명확한 규칙에 따른 처리는 일반 코드와 조건 분기를 활용할 수 있다. 문제의 특성에 맞게 역할을 나누는 것이 효율적인 설계로 이어진다.

넷째, 검증하려면 먼저 성공 기준을 정의해야 한다.

장애 복구율을 계산할 때도, 회의록에서 할 일을 추출할 때도 무엇이 성공이고 어떤 결과를 누락으로 볼 것인지 기준이 있어야 한다.

마지막으로 AI 코딩 에이전트가 발전할수록 개발자가 직접 코드를 작성하는 능력뿐 아니라 기존 코드를 이해하고, 요구사항을 구체화하고, 변경 결과를 검증하는 능력도 중요해진다고 느꼈다.

7. 현재 나의 상태와 부족한 부분

이번 주를 마치면서 현재 이해하고 있는 부분과 앞으로 더 공부해야 할 부분을 구분해 봤다.

AutoHealing과 데이터베이스

장애 감지, 복구 시도, 실제 복구 성공의 차이를 이해하고 데이터 누락을 임의의 값으로 채우면 안 되는 이유를 배웠다.

앞으로는 다양한 장애 유형에 따른 복구 기준과 테스트 설계, 데이터베이스 트랜잭션과 마이그레이션의 세부 동작을 더 공부해야 한다.

Docker와 n8n

컨테이너 실행 환경과 노드 기반 자동화의 기본 구조를 살펴봤다.

앞으로는 환경 설정 문제를 스스로 해결하고, 각 노드의 입력과 출력이 어떻게 연결되는지 추적하는 연습이 필요하다.

AI 코딩 에이전트

요구사항을 구체화하고 생성된 결과를 비교·검증하는 과정의 중요성을 이해했다.

앞으로는 테스트 자동화와 생성 코드의 품질 평가 능력을 키우고, 수정된 코드가 어떤 원리로 동작하는지 직접 설명할 수 있는 수준까지 이해를 높이고 싶다.

현재는 각 개념의 역할과 필요한 이유를 이해하고 예제의 처리 흐름을 살펴보는 단계에 가깝다. 복잡한 자동화 시스템을 처음부터 설계하고 예외 상황까지 충분히 검증하는 능력은 더 길러야 한다.

8. 다음 주 학습 계획

다음 주에는 새로운 도구를 무작정 추가하기보다 지금 배운 개념을 실제 코드와 실행 결과에 연결하는 연습에 집중하려고 한다.

1. 장애 복구 테스트 체계화하기

정상 응답, 응답 지연, 필수 데이터 누락, 잘못된 결과, 복구 불가능한 상황을 구분하고 각 상황에서 기대하는 결과를 정리할 계획이다.

2. n8n 데이터 흐름 추적하기

각 노드의 입력과 출력을 확인하고, IF·Switch를 통한 조건 분기와 Split Out·Aggregate를 통한 데이터 분리 및 결합을 복습할 계획이다.

3. Docker 기본 명령어 복습하기

이미지와 컨테이너의 차이, 컨테이너 실행 상태, 로그 확인, Compose 명령어의 역할을 정리하고 환경에 문제가 생겼을 때 확인해야 할 항목을 순서대로 익히고 싶다.

4. AI 코딩 에이전트의 결과 검증하기

요구사항과 제약 조건을 명확하게 작성하고, 생성된 코드의 변경 사항과 테스트 결과를 확인하는 과정을 반복할 계획이다.

특히 자동화 결과가 자연스러운지에만 집중하지 않고, 원본 데이터와 비교해 필요한 항목이 빠지지 않았는지 확인하고 싶다.

새로운 기술을 익히는 것만큼이나 지금 배운 개념을 직접 설명하고, 실행 결과를 확인하고, 문제가 발생했을 때 스스로 원인을 좁혀가는 능력을 키우는 것이 우선이다.

9. KPT 회고

Keep — 계속 유지할 것

• 오류가 발생하면 결과만 수정하기보다 원인과 데이터 흐름을 확인하기

• 기능 구현 후 실행 결과와 테스트 기준을 함께 확인하기

• 팀에서 합의한 데이터 계약과 변경 사항을 확인하기

• AI가 생성한 코드를 그대로 받아들이지 않고 직접 검증하기

Problem — 개선할 점

• 장애 대응과 실제 복구 성공을 구분하는 세부 기준을 더 체계적으로 정리할 필요가 있다.

• Docker, n8n, JSON 데이터 구조를 연결해 이해하는 경험이 아직 충분하지 않다.

• AI 코딩 에이전트가 수정한 코드의 품질을 판단하고 테스트하는 능력을 더 키워야 한다.

Try — 다음 주에 시도할 것

• 장애 유형별 기대 결과와 복구 성공 조건 정리하기

• n8n 워크플로우의 노드별 입력·출력을 확인하며 데이터 흐름 추적하기

• AI 코딩 에이전트에 제약 조건과 검증 기준까지 포함해 요청하기

• 실행 결과를 원본 데이터와 비교하고 누락이나 오류를 직접 찾아보기

10. 10월 2주차를 마치며

이번 주는 미니프로젝트를 마무리하고 새로운 자동화 도구를 학습하면서 AI 오케스트레이션 개발에 필요한 관점을 넓힐 수 있었던 한 주였다.

미니프로젝트에서는 장애가 발생했을 때 시스템이 어떻게 대응하고 실제로 복구됐는지를 검증하는 일이 중요했다. 이후 MiniFlow와 n8n을 학습하면서는 여러 작업을 연결하고, 데이터가 다음 단계로 전달되는 흐름을 설계하는 방법을 살펴봤다. AI 코딩 에이전트를 활용하는 과정에서는 요구사항을 구체적으로 정의하고 생성된 결과를 검증하는 일도 중요하다는 점을 확인했다.

이 세 가지 학습은 서로 다른 주제처럼 보이지만 결국 하나의 원칙으로 연결된다.

시스템이 실행됐다는 사실과 시스템이 올바르게 동작한다는 사실은 다르다.

장애 복구에서는 실제 기능이 회복됐는지 확인해야 한다. 워크플로우에서는 각 단계의 데이터가 올바르게 전달되는지 확인해야 한다. AI가 만든 결과물도 요구사항을 충족하고 있는지 검증해야 한다.

이번 주에 우리 팀이 미니프로젝트에서 1등을 기록한 것은 기쁜 성과였다. 하지만 그 결과만으로 모든 기능의 완성도나 실제 운영 환경에서의 안정성이 증명되는 것은 아니다. 구현한 기능의 범위와 한계를 이해하고, 검증하지 못한 부분을 찾아 보완하는 과정은 계속 필요하다.

아직 Docker와 n8n을 활용한 자동화, 복잡한 데이터 흐름의 추적, AI 생성 코드의 검증 능력은 더 발전시켜야 한다.

다음 주에는 새로운 기술을 익히는 것만큼이나 지금 배운 개념을 직접 설명하고, 실행 결과를 확인하고, 문제를 스스로 해결하는 연습에 시간을 투자하고 싶다.

기능을 만드는 개발자에서 한 걸음 더 나아가, 기능들이 연결된 전체 흐름을 이해하고 그 결과를 검증할 수 있는 개발자가 되는 것을 다음 학습 목표로 삼겠다.

핵심 정리

• 미니프로젝트를 통해 장애 대응과 실제 복구 성공의 차이, 데이터 계약, 통합 테스트의 중요성을 배웠다.

• MiniFlow와 n8n을 통해 노드 기반 워크플로우와 업무 자동화의 기본 구조를 이해했다.

• Docker와 WSL을 활용한 개발 환경 구성 및 컨테이너 관리 개념을 학습했다.

• LLM과 일반 코드의 역할을 구분하고 자동화 과정에서 예외 상황을 설계하는 방법을 살펴봤다.

• AI 코딩 에이전트를 활용할 때는 구체적인 요구사항과 검증 기준을 제시하고 결과를 직접 확인해야 한다는 점을 배웠다.