10월 3주차에는 AI 에이전트 워크플로우의 설계와 검증부터 바이브 코딩을 활용한 애플리케이션 개발, RAG 검색 품질 개선까지 학습 범위를 확장했다. 67일차부터 71일차까지의 일일 회고를 바탕으로, 이번 주에 다룬 기술을 나열하는 데 그치지 않고 각 개념이 어떻게 연결되는지 정리했다.

1. 이번 주 학습 요약

이번 주 학습을 관통하는 주제는 AI가 코드를 만들고 작업을 수행하도록 하는 것에서 나아가, 그 결과를 검증하고 안정적으로 운영할 수 있는 구조를 설계하는 것이었다.

초반에는 Docker Compose와 n8n을 활용해 서비스 실행 환경과 AI 에이전트 워크플로우를 살펴봤다. 이어서 요구사항을 개발 명세로 구체화하고, CLI 기반 코딩 에이전트를 활용해 구현 계획을 세우는 방법을 학습했다.

이후에는 멀티 에이전트의 역할 분리, 오류 발생 시 처리 방식, 공통 로직의 모듈화와 회귀 테스트 등 실제 운영을 고려한 설계로 주제를 넓혔다. 후반부에는 RAG 검색 품질을 평가하고 개선하는 방법, 로컬 문서 검색 도구의 구조, Python 기반 애플리케이션과 프론트엔드·백엔드 분리까지 살펴봤다.

이번 주의 흐름을 정리하면 다음과 같다.

• 실행 환경: Docker Compose로 서비스와 컨테이너 관리하기

• 워크플로우 설계: n8n으로 작업 흐름과 조건별 분기 구성하기

• AI 기반 개발: 요구사항·명세·구현 계획을 바탕으로 코딩 에이전트 활용하기

• 안정성 확보: 예외 처리, 역할 분리, 테스트와 실행 기록으로 검증하기

• 검색 품질 개선: RAG의 검색 결과와 근거를 평가하고 개선하기

• 애플리케이션 구조화: 공통 기능 재사용과 프론트엔드·백엔드 분리 고려하기

2. AI 에이전트는 만드는 것보다 제대로 동작하게 하는 것이 중요하다

이번 주에는 n8n 기반의 IT 지원 에이전트와 업무 자동화 워크플로우를 중심으로, AI 에이전트가 어떤 과정을 거쳐 결과를 만드는지 살펴봤다.

IT 지원 에이전트에서는 FAQ 검색과 티켓 조회를 구분하고, 사용자의 요청에 따라 적절한 도구를 선택하는 구조를 다뤘다. 회의록을 활용하는 워크플로우에서는 필수 자료가 누락된 경우를 처리하고, 여러 에이전트가 협력하는 구조에서는 각 역할의 책임과 결과 검토 과정을 구분하는 것이 중요했다.

특히 Writer와 Reviewer처럼 작성과 검토를 분리하면 결과를 한 번 생성하는 것으로 끝내지 않고, 검토 결과에 따라 수정하거나 재시도할 수 있다. 다만 재시도가 무한히 반복되지 않도록 횟수를 제한하고, 해결되지 않는 문제는 담당자가 확인하도록 설계해야 한다.

이때 중요하게 연결되는 개념이 Fail Open과 Fail Closed다.

• Fail Open: 일부 작업에 실패해도 가능한 결과를 활용하거나 나머지 처리를 계속하는 방식이다.

• Fail Closed: 필수 검증이나 보안 절차에 실패하면 처리를 중단하는 방식이다.

두 방식 중 어느 하나가 항상 정답인 것은 아니다. 실패한 작업의 결과를 계속 활용해도 되는지, 검증되지 않은 결과가 외부로 전달되면 위험한지를 기준으로 선택해야 한다.

또한 최종 결과만 확인해서는 내부 처리 과정에서 발생한 문제를 찾기 어렵다. 단계별 실행 기록과 각 에이전트의 입출력을 확인하면 어떤 단계에서 실패했는지, 재시도가 발생했는지, 오류가 적절하게 처리됐는지 파악할 수 있다.

결국 AI 에이전트의 완성도는 답변을 생성하는 능력뿐 아니라 실패를 감지하고, 잘못된 결과를 차단하며, 문제가 발생했을 때 적절한 경로로 처리하는 능력에도 달려 있다.

3. 바이브 코딩의 핵심은 요구사항과 검증 기준을 명확하게 만드는 것

이번 주에는 Codex, Claude Code, Gemini 등의 CLI 기반 코딩 에이전트를 활용하는 개발 방식도 다뤘다.

AI에게 자연어로 요청하면 코드를 생성할 수 있지만, 요청이 모호하면 결과 역시 기대와 달라질 수 있다. 따라서 원하는 기능을 구체적인 요구사항으로 정리하고, 구현 범위와 제약 조건을 명시하는 과정이 중요하다.

예를 들어 워크플로우의 구조를 시각화하는 프로그램을 만든다면 단순히 '워크플로우를 보기 쉽게 만들어 달라'고 요청하는 것만으로는 부족하다.

노드의 역할과 연결 관계를 표시할 것인지, 특정 노드를 선택했을 때 설정을 보여줄 것인지, 연결 오류를 감지할 것인지, 외부 API 없이도 동작해야 하는지 등을 구체화해야 한다. 이렇게 요구사항을 나누면 구현할 기능뿐 아니라 결과를 평가할 기준도 명확해진다.

이번 주에 다룬 개발 문서와 작업 흐름은 다음과 같이 정리할 수 있다.

1. SPEC.md에 필요한 기능과 제약 조건을 정리한다.

2. IMPLEMENTATION_PLAN.md에 구현 단계를 나눈다.

3. AGENTS.md에 프로젝트 공통 개발 규칙을 작성한다.

4. 계획에 따라 기능을 구현한다.

5. 테스트와 실행 결과를 확인하고 필요한 부분을 수정한다.

이 문서들은 각각 목적이 다르다. 스펙은 무엇을 만들어야 하는지 정의하고, 구현 계획은 어떤 순서로 작업할지 정리하며, 공통 규칙은 코딩 에이전트가 프로젝트 전반에서 지켜야 할 기준을 전달한다.

모든 작업에 반드시 같은 문서를 적용해야 하는 것은 아니지만, 프로젝트가 복잡해질수록 명세와 작업 계획을 먼저 정리하는 편이 변경 사항을 관리하기 쉽다.

여러 코딩 에이전트의 결과를 비교하는 과정에서도 같은 원칙이 적용된다. 도구마다 생성하는 코드와 파일 구조, 설명의 깊이, 테스트 범위가 다를 수 있기 때문에 특정 도구의 결과를 그대로 정답으로 받아들이기보다 실제 요구사항을 충족하는지 확인해야 한다.

이번 주 학습을 통해 바이브 코딩은 단순히 AI에게 코드를 작성하게 하는 방법이 아니라, 요구사항을 구체화하고 AI의 작업을 관리하며 결과를 검증하는 개발 방식으로 이해할 수 있었다.

4. 공통 로직의 모듈화와 회귀 테스트

워크플로우가 복잡해지고 기능이 늘어날수록 모든 기능을 개별적으로 구현하고 관리하는 방식에는 한계가 생긴다. 이번 주에는 공통 로직을 분리해 재사용하고, 변경으로 인해 기존 기능이 영향을 받지 않는지 확인하는 방법을 다뤘다.

예를 들어 유지보수 공지, 보안 공지, 교육 공지는 목적과 필수 문구가 다르지만 글자 수 확인이나 필수 조건 검증 같은 공통 작업을 수행한다.

이때 공통 검증 로직은 별도의 모듈이나 서브워크플로우로 분리하고, 공지 유형에 따른 차이는 설정으로 관리할 수 있다. 이렇게 하면 새로운 공지 유형이 추가되더라도 기존 코드를 반복해서 작성할 필요가 줄어든다.

모듈을 분리할 때는 입력과 출력의 규칙도 중요하다.

• 입력 계약: 모듈이 어떤 데이터를 받아야 하는가?

• 처리 로직: 전달받은 데이터를 어떤 기준으로 처리하는가?

• 출력 계약: 어떤 형식으로 결과를 반환하는가?

공통 모듈을 수정할 때는 이 모듈을 사용하는 다른 기능에도 영향이 생길 수 있다. 예를 들어 기존에는 true 또는 false를 반환하던 기능이 새로운 버전에서 allow, warning, block을 반환하도록 변경되면 기존 호출 코드가 예상대로 동작하지 않을 수 있다.

이런 문제를 방지하려면 변경된 기능뿐 아니라 기존 기능도 다시 테스트해야 한다. 이것이 **회귀 테스트(Regression Test)**의 핵심이다.

회귀 테스트는 새로운 기능을 추가하거나 기존 코드를 수정한 뒤, 이전에 정상적으로 동작하던 기능이 여전히 올바르게 작동하는지 확인하는 테스트다.

이 개념은 RAG 검색 품질을 개선할 때도 연결된다. 검색 설정을 변경해 특정 질문의 결과가 좋아졌더라도, 다른 질문의 검색 품질이 나빠지지는 않았는지 함께 확인해야 한다.

즉, 모듈화는 코드 중복을 줄이는 방법이고 회귀 테스트는 변경으로 인한 부작용을 확인하는 방법이다. 두 가지를 함께 적용해야 기능을 확장하면서도 기존 동작을 안정적으로 유지할 수 있다.

5. RAG 검색 품질과 근거 검증

이번 주 후반부에는 RAG(Retrieval-Augmented Generation, 검색 증강 생성)의 검색 품질을 평가하고 개선하는 방법을 살펴봤다.

RAG는 관련 문서를 검색한 뒤 검색 결과를 바탕으로 LLM이 답변을 생성하는 구조다. 하지만 RAG를 구현했다고 해서 질문에 필요한 정보가 항상 검색되거나 답변이 정확해지는 것은 아니다.

검색 결과가 여러 개 반환되더라도 실제 답변에 필요한 근거가 포함되어 있는지는 별도로 확인해야 한다.

이번 주에 다룬 주요 개선 방향은 다음과 같다.

• 검색 결과 평가: 질문에 필요한 문서가 상위 검색 결과에 포함되는지 확인한다.

• 청킹 방식 비교: 일정한 길이로 문서를 나누는 방식과 Markdown의 제목·섹션 구조를 활용하는 방식을 비교한다.

• 쿼리 재작성: 사용자의 일상적인 표현을 규정이나 문서에서 사용하는 용어에 맞게 바꿔 검색을 개선한다.

• 회귀 테스트: 검색 설정을 바꾼 뒤 기존 질문에서도 품질이 유지되는지 확인한다.

• 출처 확인: 답변에 사용된 문서와 관련 구간을 확인할 수 있도록 구성한다.

특히 청킹은 문서를 검색하기 적절한 단위로 나누는 과정이다. 문서를 지나치게 크게 나누면 검색 결과에 불필요한 내용이 포함될 수 있고, 지나치게 작게 나누면 문맥이 끊길 수 있다. 문서의 구조와 실제 질문의 유형을 고려해 적절한 단위를 선택해야 한다.

또한 검색 결과의 순위만으로 답변의 정확성을 보장할 수는 없다. 유사도가 높은 문서가 반환되더라도 질문에 필요한 내용이 실제로 존재하지 않을 수 있기 때문이다.

이 점은 앞서 배운 워크플로우의 실패 처리와도 연결된다. 근거가 부족한 상황에서 AI가 임의로 답변을 생성하거나, 검증되지 않은 결과를 정상적인 응답으로 처리하면 안 된다. 답변할 근거가 없다면 그 사실을 명확히 안내하거나 담당자에게 연결하는 경로가 필요하다.

6. 로컬 문서 검색과 애플리케이션 구조 설계

RAG 학습은 n8n 워크플로우에만 머무르지 않고 로컬 문서 검색 도구를 설계하는 방향으로 확장됐다.

지정된 폴더의 Markdown 문서를 검색하는 프로그램을 만든다고 가정하면, 단순히 문서를 읽고 검색 결과를 출력하는 기능 외에도 고려할 부분이 많다.

문서가 추가되거나 수정될 때마다 모든 파일을 다시 처리하면 비효율적일 수 있다. 따라서 변경된 파일만 다시 색인하고, 삭제된 문서의 기존 색인도 정리할 수 있도록 설계하는 것이 중요하다.

검색 결과를 보여줄 때도 단순히 관련 문장만 출력하기보다는 파일명, 관련 구간, 유사도 등을 함께 제공하면 사용자가 결과를 검토하기 쉽다. 필요할 때 원문 전체를 확인할 수 있다면 검색 결과의 신뢰성을 판단하는 데도 도움이 된다.

마지막 교시에서는 Python 기반 애플리케이션 개발과 프론트엔드·백엔드 분리, 프로젝트 공통 규칙을 관리하는 방법도 다뤘다.

여기서 중요한 것은 사용자에게 보여주는 화면과 실제 데이터를 처리하는 로직을 구분하는 설계다. 화면 구성과 데이터 처리의 책임을 분리하면 각각의 기능을 수정하거나 확장하기 쉬워질 수 있다.

또한 기존에 작성된 코드를 참고해 새로운 프로그램을 만들 때는 기존 코드와 공통 규칙, 구현 명세를 함께 제공하는 편이 좋다. 코딩 에이전트가 기존 기능을 재사용할 수 있는지 판단하고, 프로젝트의 일관성을 유지하는 데 도움이 되기 때문이다.

다만 이번 주 일일 회고에서 확인되는 내용은 이러한 구조와 개발 흐름을 학습하고 살펴본 것이다. 모든 기능을 직접 구현하고 완성했다는 의미로 확대해서 해석하지는 않는다.

7. 이번 주에 새롭게 연결된 개념

이번 주 학습에서 의미 있었던 부분은 개별적으로 배웠던 기술들이 하나의 개발 과정으로 연결된다는 점이다.

이 흐름은 모든 프로젝트가 반드시 동일한 순서로 진행된다는 뜻은 아니다. 다만 이번 주에 배운 개념을 하나로 연결해 보면, AI 기반 개발에서도 요구사항 정의부터 구현, 검증, 예외 처리까지 일반적인 소프트웨어 개발의 기본 원칙이 중요하다는 점을 확인할 수 있다.

8. 어려웠던 점과 앞으로 보완할 부분

이번 주에 다룬 내용은 개별 기술을 사용하는 방법뿐 아니라 여러 구성 요소가 함께 동작하는 시스템을 어떻게 설계하고 검증할 것인지에 관한 것이었다.

워크플로우의 노드가 많아질수록 각 노드의 역할과 데이터 전달 관계를 파악해야 한다. 공통 모듈을 수정할 때는 다른 기능에 미치는 영향을 확인해야 하고, RAG에서는 검색 결과와 실제 답변의 근거가 일치하는지도 살펴봐야 한다.

이런 문제는 단순히 코드를 생성하거나 한 번 실행하는 것만으로 해결하기 어렵다.

앞으로 보완할 부분은 다음과 같다.

• 요구사항을 작은 기능 단위로 나누고 테스트 가능한 기준으로 작성하기

• 워크플로우의 실행 기록과 입출력을 따라가며 오류가 발생한 위치 파악하기

• 공통 로직을 변경할 때 입력·출력 계약과 기존 호출자 확인하기

• 정상 사례뿐 아니라 자료 누락, 잘못된 입력, 검증 실패 사례도 테스트하기

• RAG의 검색 결과와 답변 근거를 별도로 평가하기

• AI가 생성한 코드의 변경 사항과 실제 실행 결과를 직접 확인하기

위 항목은 이번 주에 다룬 내용을 바탕으로 정리한 복습 및 개선 과제다. 실제로 모든 항목을 수행해 해결했다는 의미는 아니다.

9. 다음 주 계획

다음 주에는 이번 주에 학습한 내용을 실제 구현과 검증 관점에서 더 확실하게 연결하는 데 집중하고 싶다.

첫째, 코딩 에이전트에 작업을 맡기기 전에 요구사항과 완료 조건을 명확하게 정리하는 습관을 갖추고 싶다. 구현 결과가 나왔다는 사실보다 처음 정의한 조건을 충족했는지 확인하는 것이 중요하기 때문이다.

둘째, 워크플로우와 RAG를 구성할 때 정상 동작뿐 아니라 실패했을 때의 처리 경로도 함께 살펴보고 싶다. 특히 근거가 없는 답변이나 검증되지 않은 결과가 정상적인 결과로 처리되지 않도록 확인하는 기준이 필요하다.

셋째, 기능을 수정할 때 기존 기능까지 함께 검증하는 습관을 기르고 싶다. 새로운 기능이 추가될수록 회귀 테스트와 공통 모듈의 관리가 중요해지기 때문이다.

마지막으로 AI가 생성한 코드를 단순히 받아들이는 데서 끝내지 않고, 코드의 구조와 실행 흐름을 직접 설명할 수 있는 수준까지 이해하는 것을 목표로 삼고 싶다.

10. 이번 주 회고

이번 주에는 Docker Compose와 n8n을 통한 실행 환경 및 워크플로우 구성부터 바이브 코딩, 멀티 에이전트 설계, 모듈화와 회귀 테스트, RAG 검색 품질 개선까지 폭넓게 다뤘다.

각 기술은 서로 다른 문제를 해결하지만 공통적으로 요구사항을 명확하게 정의하고, 작업을 적절히 나누며, 결과를 검증해야 한다는 원칙으로 연결된다.

AI 코딩 에이전트가 코드를 빠르게 생성할 수 있다는 사실만으로 프로그램의 완성도가 보장되는 것은 아니다. 요구사항이 잘못 전달되거나, 기존 기능과의 호환성이 깨지거나, 검색 근거가 부족한데도 답변이 생성된다면 실제 사용 환경에서는 문제가 발생할 수 있다.

따라서 앞으로는 AI를 얼마나 많이 활용하는가보다 AI가 만든 결과를 어떤 기준으로 확인하고, 오류를 어떻게 감지하며, 안정적으로 유지할 수 있는 구조를 어떻게 설계하는가에 더 집중하고 싶다.

이번 주에 배운 개념을 단순히 기억하는 데 그치지 않고, 실제 프로젝트에서 요구사항 정의부터 구현과 테스트까지 연결해 활용할 수 있도록 복습해 나가야겠다.

1. 프로그래밍 오버뷰 강의를 시작하며

이번에는 코드잇(Codeit)의 「01_프로그래밍 오버뷰」 강의를 수강했다.

그동안 Python, FastAPI, 데이터베이스, API 등을 학습하면서 실제 서비스를 개발하는 경험을 쌓았지만, 이번 강의에서는 개별 기술보다 프로그래밍이라는 분야의 전체적인 구조를 다시 살펴볼 수 있었다.

코딩이 무엇인지부터 웹과 모바일 앱이 동작하는 원리, 개발자의 다양한 직무, 프로그래밍 언어 선택 방법, 좋은 코드를 작성하기 위해 필요한 역량까지 폭넓게 다루는 입문 과정이었다.

이미 접해 본 개념도 있었지만, 각각의 기술이 어떤 역할을 하고 서로 어떻게 연결되는지 정리하는 데 초점을 맞췄다.

2. 코딩이란 무엇인가?

코딩의 기본 개념

코딩(Coding)은 컴퓨터가 특정 작업을 수행할 수 있도록 프로그래밍 언어로 명령을 작성하는 과정이다.

컴퓨터는 사람이 일상적으로 사용하는 언어를 그대로 이해하지 못하기 때문에 Python, JavaScript, Java 등의 프로그래밍 언어를 사용한다.

강의에서는 Python의 max() 함수를 예시로 소개했다.

max(27, 45, 36)

이 코드는 세 숫자 중 가장 큰 숫자인 45를 반환한다.

간단한 예제지만, 프로그래밍의 기본적인 흐름을 보여준다.

사람이 명령을 작성하면 컴퓨터가 이를 처리하고 결과를 반환하는 것이다.

코딩을 배우는 이유

코딩은 개발자가 되기 위해서만 배우는 기술이 아니다.

강의에서는 코딩을 활용하는 방향을 크게 세 가지로 설명했다.

1. 기술의 흐름과 프로그래밍의 기본 원리를 이해하기
2. 일상생활이나 업무에서 필요한 프로그램을 직접 만들기
3. 전문적인 소프트웨어 개발자로 진출하기

특히 반복적인 업무를 자동화하거나 자신의 아이디어를 실제 서비스로 구현할 수 있다는 점이 인상적인 활용 사례였다.

3. 프로그램을 구성하는 기본 문법

프로그래밍에서는 복잡한 기능도 여러 기본 개념을 조합해 구현한다.

이번 강의에서는 변수, 함수, 조건문, 반복문을 핵심 요소로 소개했다.

변수와 함수

변수(Variable)는 프로그램에서 데이터를 저장하거나 참조하기 위해 사용하는 이름이다.

함수(Function)는 특정 작업을 수행하는 코드를 묶어 재사용할 수 있도록 만든 것이다.

예를 들어 Python에서는 다음과 같이 사용할 수 있다.

price = 20000

def discount(price):
    return price * 0.9

print(discount(price))

변수에 상품 가격을 저장하고, 함수를 이용해 할인된 가격을 계산하는 예제다.

조건문과 반복문

조건문은 조건에 따라 실행할 코드를 결정하고, 반복문은 같은 작업을 여러 번 실행할 때 사용한다.

for i in range(3):
    print("HELLO WORLD")

위 코드는 HELLO WORLD를 세 번 출력한다.

country = "한국"

if country == "한국":
    print("안녕하세요")
else:
    print("HELLO")

이 코드는 조건에 따라 서로 다른 인사말을 출력한다.

실제 서비스에서는 이러한 기본 문법을 조합해 로그인, 회원가입, 상품 조회, 결제 등의 기능을 구현한다.

위 Python 코드는 강의 개념을 복습하기 위해 재구성한 예제다.

4. 웹 서비스는 어떻게 동작할까?

이번 강의에서 중요한 부분 중 하나는 클라이언트, 서버, 데이터베이스의 관계였다.

클라이언트와 서버

웹 서비스는 기본적으로 클라이언트가 서버에 요청을 보내고, 서버가 이를 처리한 뒤 결과를 응답하는 방식으로 동작한다.

• 클라이언트(Client): 사용자가 직접 이용하는 웹 브라우저나 앱
• 서버(Server): 사용자의 요청을 받아 처리하는 시스템
• 데이터베이스(Database): 서비스에 필요한 데이터를 저장하고 관리하는 시스템

예를 들어 사용자가 쇼핑몰에서 상품 목록을 조회한다면 다음과 같은 과정이 진행된다.

1. 사용자가 상품 조회 버튼을 클릭한다.
2. 클라이언트가 서버에 상품 목록을 요청한다.
3. 서버가 데이터베이스에서 상품 정보를 조회한다.
4. 서버가 조회 결과를 클라이언트에 전달한다.
5. 클라이언트가 상품 목록을 화면에 표시한다.

이러한 구조는 대부분의 웹 서비스에서 공통적으로 활용된다.

프론트엔드와 백엔드

웹 개발은 크게 프론트엔드와 백엔드로 나뉜다.

구분프론트엔드백엔드

프론트엔드는 사용자가 보는 화면을 구현하고, 백엔드는 화면 뒤에서 필요한 데이터를 처리한다.

두 영역은 API를 통해 통신할 수 있다.

API와 DNS

API(Application Programming Interface)는 서로 다른 프로그램이 기능이나 데이터를 주고받을 수 있도록 정의한 인터페이스다.

예를 들어 상품 조회 API는 다음과 같이 표현할 수 있다.

GET /products

클라이언트가 요청을 보내면 서버는 상품 정보를 JSON 형식으로 반환할 수 있다.

DNS(Domain Name System)는 youtube.com처럼 사람이 기억하기 쉬운 도메인 이름을 서버 접속에 필요한 IP 주소로 변환하는 역할을 한다.

즉, 웹사이트에 접속하는 과정에는 화면을 보여주는 기술뿐 아니라 네트워크 통신과 서버 처리 과정도 포함되어 있다.

5. 웹 개발과 모바일 앱 개발의 차이

웹사이트와 모바일 앱은 사용자에게 서비스를 제공한다는 점에서는 비슷하지만, 화면을 구현하는 기술에는 차이가 있다.

웹 개발에서는 주로 HTML, CSS, JavaScript를 사용한다.

반면 모바일 앱은 운영체제에 따라 다른 기술을 사용할 수 있다.

• iOS 앱: Swift
• Android 앱: Kotlin
• 크로스 플랫폼 앱: React Native, Flutter

크로스 플랫폼 개발

iOS와 Android 앱을 각각 개발하면 서로 다른 코드와 개발 환경을 관리해야 할 수 있다.

이러한 부담을 줄이기 위해 사용하는 방식이 크로스 플랫폼 개발이다.

대표적인 기술은 React Native와 Flutter다.

React Native는 JavaScript나 TypeScript를 활용하고, Flutter는 Dart 언어를 사용한다.

하나의 코드베이스를 여러 운영체제에서 활용할 수 있다는 장점이 있지만, 운영체제별 기능을 구현할 때는 추가 작업이 필요할 수 있다.

이번 내용을 통해 같은 서비스를 만들더라도 웹으로 제공할지, 모바일 앱으로 제공할지에 따라 기술 선택이 달라진다는 점을 정리할 수 있었다.

6. 데이터와 인공지능 분야의 다양한 직무

이번 강의에서는 데이터 관련 개발 직무도 자세히 소개했다.

처음에는 모두 데이터를 다루는 직업처럼 보일 수 있지만, 실제로는 담당하는 역할이 다르다.

직무주요 역할

데이터 엔지니어와 데이터 애널리스트

데이터 엔지니어는 데이터를 안정적으로 수집하고 저장할 수 있는 환경을 구축한다.

데이터 애널리스트는 이렇게 준비된 데이터를 분석해 의미 있는 정보를 찾아낸다.

예를 들어 서비스의 사용자 수가 감소했다면 데이터 애널리스트는 이용 기록을 분석해 변화가 발생한 시점과 원인을 파악하는 데 도움을 줄 수 있다.

데이터 사이언티스트와 머신러닝 엔지니어

데이터 사이언티스트는 통계와 머신러닝을 활용해 데이터를 분석하고 예측 모델을 개발할 수 있다.

머신러닝 엔지니어는 이러한 모델을 실제 서비스에서 사용할 수 있도록 구현하고 운영한다.

머신러닝 리서처는 기존 모델을 개선하거나 새로운 알고리즘을 연구하는 역할을 맡는다.

같은 AI 분야라도 데이터를 준비하는 일부터 분석, 모델 개발, 서비스 적용, 연구까지 다양한 전문 영역이 존재한다는 점을 알 수 있었다.

7. 게임, 블록체인, 임베디드, IoT 개발

소프트웨어 개발은 웹과 모바일 앱, AI 분야에만 한정되지 않는다.

이번 강의에서는 다른 개발 분야도 소개했다.

게임 개발

게임 개발에서는 Unity와 Unreal Engine 같은 게임 엔진을 사용한다.

• Unity: 주로 C# 사용
• Unreal Engine: 주로 C++과 블루프린트 사용

게임 엔진은 그래픽, 물리 처리, 애니메이션 등 게임 개발에 필요한 기능을 제공한다.

블록체인 개발

블록체인은 여러 참여자가 데이터를 공유하고 검증하는 분산원장 기술이다.

대표적인 개념은 탈중앙화(Decentralization)이며, 블록체인을 활용한 애플리케이션을 DApp이라고 한다.

스마트 계약 개발에는 Solidity 같은 프로그래밍 언어를 사용할 수 있다.

임베디드 시스템과 IoT

임베디드 시스템은 냉장고, 세탁기, 자동차처럼 특정 기기 내부에서 동작하는 컴퓨터 시스템이다.

IoT(Internet of Things)는 이러한 기기나 센서 등을 네트워크로 연결해 데이터를 주고받도록 하는 기술이다.

예를 들어 온도 센서가 측정한 데이터를 서버에 전달하고, 그 결과에 따라 에어컨을 제어하는 시스템을 생각할 수 있다.

이러한 분야에서는 C와 C++ 같은 언어가 자주 활용된다.

8. 개발 분야별 프로그래밍 언어와 학습 로드맵

이번 강의에서는 개발 분야에 따라 학습해야 하는 기술이 달라진다는 점을 강조했다.

대표적인 학습 경로를 정리하면 다음과 같다.

개발 분야주요 학습 기술

SQL과 NoSQL

백엔드 개발에서는 데이터베이스를 이해하는 것도 중요하다.

SQL 기반 관계형 데이터베이스에는 PostgreSQL과 MySQL 등이 있다.

NoSQL 데이터베이스에는 MongoDB처럼 문서 형태로 데이터를 저장하는 방식도 있다.

두 방식은 데이터 구조와 활용 목적이 다르므로 서비스의 요구사항에 따라 선택해야 한다.

기술 선택에서 중요한 것

강의에서는 모든 프로그래밍 언어를 배우려고 하기보다 자신이 원하는 개발 분야를 먼저 정하는 것이 중요하다고 설명했다.

또한 희망하는 기업의 채용 공고를 살펴보면 실제로 어떤 언어와 프레임워크를 사용하는지 파악하는 데 도움이 된다.

특히 국내 백엔드 개발에서는 Java와 Spring을 사용하는 기업이 많다는 점도 소개했다.

다만 처음 학습한 언어와 실제 취업 후 사용하는 언어가 반드시 같을 필요는 없다.

프로그래밍의 기본 원리를 이해하면 다른 언어와 기술을 배우는 데에도 도움이 되기 때문이다.

9. 개발자가 아니어도 코딩을 활용할 수 있다

이번 강의에서는 개발자 외의 직무에서도 코딩이 유용하게 사용된다는 점을 소개했다.

대표적인 사례는 업무 자동화와 데이터 분석이다.

Python을 활용한 업무 자동화

반복적으로 수행하는 업무를 Python으로 자동화할 수 있다.

예를 들어 다음과 같은 작업이다.

1. 엑셀 파일에서 데이터 가져오기
2. 필요한 정보만 추출하고 정리하기
3. 결과를 새로운 파일로 저장하기
4. 이메일로 결과 전달하기

매일 같은 작업을 반복해야 한다면 자동화를 통해 시간을 절약할 수 있다.

A/B 테스트와 데이터 분석

A/B 테스트는 서로 다른 두 가지 디자인이나 기능을 사용자에게 보여주고 결과를 비교하는 방법이다.

강의에서는 구독 버튼의 디자인을 변경했을 때 클릭 비율이 달라지는 사례를 소개했다.

이러한 실험은 사용자의 행동 데이터를 바탕으로 서비스를 개선하는 데 활용할 수 있다.

다만 실제 결과를 판단할 때는 표본 크기와 통계적 유의성도 고려해야 한다.

개발자와 비개발자의 협업

소프트웨어 서비스는 개발자 혼자 만드는 것이 아니다.

프로젝트 매니저(PM), 프로덕트 매니저, UX/UI 디자이너 등 다양한 직무가 함께 참여한다.

기획자나 디자이너도 API, 데이터베이스, 프론트엔드와 백엔드의 기본 구조를 이해하면 개발자와 더 구체적으로 소통할 수 있다.

코딩 지식은 직접 개발할 때뿐 아니라 협업 과정에서도 도움이 되는 역량이다.

10. 좋은 개발자가 되기 위해 필요한 능력

강의 마지막 부분에서는 코딩 문법을 배우는 것과 좋은 프로그램을 만드는 것은 다르다고 설명했다.

문제 해결 능력

프로그래밍에서 중요한 것은 문법을 많이 외우는 것보다 문제를 작은 단위로 나누고 해결 방법을 생각하는 능력이다.

원하는 기능이 무엇인지 정의하고, 필요한 작업을 순서대로 구성해야 한다.

라이브러리와 프레임워크 활용

실제 개발에서는 모든 기능을 처음부터 구현하지 않는다.

라이브러리는 재사용 가능한 기능을 제공하고, 프레임워크는 프로그램 개발에 필요한 구조와 규칙을 제공한다.

이러한 도구를 적절히 활용하면 개발 시간을 줄이고 복잡한 기능을 효율적으로 구현할 수 있다.

디버깅(Debugging)

디버깅은 프로그램에서 발생한 오류의 원인을 찾아 수정하는 과정이다.

기본적인 흐름은 다음과 같다.

문제 발생 → 원인 분석 → 코드 수정 → 재실행 및 결과 확인

오류 메시지를 확인하고 문제가 발생한 위치와 원인을 파악하는 능력은 실제 개발에서 중요하다.

리팩토링(Refactoring)

리팩토링은 프로그램의 외부 동작을 유지하면서 내부 코드 구조를 개선하는 작업이다.

반복된 코드를 함수로 분리하거나 복잡한 로직을 단순하게 만드는 것이 대표적인 예시다.

리팩토링을 통해 코드의 가독성과 유지보수성을 높일 수 있다.

확장성과 유지보수성

서비스가 커지고 사용자가 증가하면 기존 코드가 처리해야 하는 작업도 많아진다.

따라서 개발자는 프로그램이 현재 정상적으로 동작하는 것뿐 아니라 앞으로 수정하거나 확장하기 쉬운 구조인지도 고려해야 한다.

이번 강의에서 강조한 내용은 단순히 실행되는 코드를 작성하는 것과 좋은 코드를 작성하는 것은 다르다는 점이었다.

11. 이번 강의를 통해 정리한 내용

이번 프로그래밍 오버뷰 강의는 새로운 문법을 깊이 있게 학습하는 과정이라기보다 프로그래밍 분야 전체를 이해하는 과정이었다.

코딩의 기본 개념에서 시작해 클라이언트와 서버의 관계, 프론트엔드와 백엔드의 차이, 모바일 앱 개발, 데이터와 AI 직무, 게임과 IoT 개발까지 폭넓게 살펴봤다.

특히 이전에 학습했던 Python, FastAPI, 데이터베이스, API가 웹 서비스 구조 안에서 각각 어떤 역할을 하는지 다시 연결해 볼 수 있었다.

또한 개발자의 역할이 단순히 코드를 작성하는 데 그치지 않는다는 점도 중요했다.

요구사항을 이해하고, 문제를 해결하고, 오류를 수정하고, 다른 사람이 이해하기 쉬운 코드를 작성하는 능력까지 개발 역량에 포함된다는 것이다.

12. 앞으로 복습할 부분

이번 강의는 프로그래밍 분야를 전체적으로 소개하는 과정이었기 때문에 각 기술의 세부적인 구현 방법까지 다루지는 않았다.

앞으로는 다음 내용을 중심으로 복습하려고 한다.

• 웹 서비스 구조: 클라이언트, 서버, API, 데이터베이스의 연결 과정
• Python 기본 문법: 변수, 함수, 조건문, 반복문
• 백엔드 개발: API 설계와 데이터베이스 연동
• 데이터 및 AI: 데이터 처리부터 머신러닝 모델의 서비스 적용까지의 과정
• 코드 품질: 디버깅, 리팩토링, 유지보수성, 확장성

특히 코드를 작성할 때 단순히 실행 결과만 확인하는 것이 아니라 왜 이런 구조로 작성했는지 설명할 수 있는 수준까지 이해하는 것이 중요하다고 생각한다.

13. 오늘의 회고

이번 「프로그래밍 오버뷰」 강의를 통해 코딩의 기본 원리부터 개발 분야와 학습 방향까지 전체적인 흐름을 정리했다.

이미 접해 본 기술도 있었지만, 개별 기술을 배우는 것과 그 기술이 전체 소프트웨어 구조에서 어떤 역할을 하는지 이해하는 것은 다른 문제였다.

웹 개발과 모바일 앱 개발의 차이, 데이터 분야의 직무 구분, 개발 언어와 프레임워크의 관계 등을 한 번에 살펴보면서 앞으로 어떤 내용을 더 공부해야 할지 정리할 수 있었다.

무엇보다 기억에 남는 내용은 좋은 개발자가 되기 위해 필요한 것이 단순한 코딩 문법만은 아니라는 점이다.

AI가 코드를 작성하는 데 도움을 줄 수 있는 환경에서도 요구사항을 정확히 이해하고, 생성된 코드의 동작을 검증하고, 오류를 해결하고, 전체 구조를 판단하는 능력은 중요하다.

앞으로는 새로운 기술을 무작정 많이 배우기보다 기본 원리를 이해하고, 직접 구현하고, 문제가 발생했을 때 스스로 원인을 설명할 수 있는 능력을 키우는 방향으로 학습을 이어가고 싶다.

핵심 정리

이번 강의에서 학습한 내용을 정리하면 다음과 같다.

1. 코딩은 컴퓨터에 명령을 전달해 문제를 해결하는 과정이다.
2. 실제 서비스는 클라이언트, 서버, API, 데이터베이스 등 여러 요소가 연결되어 동작한다.
3. 개발 분야에 따라 필요한 프로그래밍 언어와 기술이 달라진다.
4. 코딩은 개발뿐 아니라 업무 자동화, 데이터 분석, 협업에도 활용할 수 있다.
5. 좋은 개발자가 되기 위해서는 문제 해결, 디버깅, 리팩토링, 유지보수 능력이 중요하다.

결국 프로그래밍을 잘한다는 것은 단순히 코드를 많이 작성하는 것이 아니라, 문제를 이해하고 적절한 기술로 해결할 수 있다는 의미에 가깝다.

해시태그

#코드잇 #Codeit #프로그래밍오버뷰 #코딩공부 #개발자공부 #Python #웹개발 #백엔드개발 #AI개발자 #개발회고

오늘 배운 내용

70일차에는 AI 코딩 에이전트를 활용해 반복적인 업무를 자동화하는 워크플로를 설계하고, 명세를 바탕으로 실제 애플리케이션을 구현하는 과정을 살펴봤다. 단순히 코드를 생성하는 것을 넘어 기존 기능을 모듈화하고, 테스트를 통해 동작을 확인하며, 새로운 요구사항에 맞춰 프로그램을 확장하는 것이 핵심이었다.

오전에는 n8n 워크플로를 중심으로 공통 기능을 분리하고 재사용하는 방법을 다뤘다. 이후에는 Codex, Claude Code, Gemini 등 여러 AI 코딩 도구의 결과를 비교하고, 워크플로 자동화와 데스크톱 애플리케이션 개발로 범위를 넓혔다.

1. 공통 로직을 모듈화하고 재사용하기

처음에는 유지보수 공지, 보안 공지, 교육 공지처럼 목적은 다르지만 비슷한 처리 과정을 가진 워크플로를 비교했다.

각 워크플로를 개별적으로 관리하면 같은 규칙을 수정할 때 여러 곳을 변경해야 한다. 반면 공통 처리 로직과 유형별 설정을 분리하면 중복을 줄이고 새로운 기능을 추가하기 쉬워진다.

예를 들어 공지 유형별로 제목, 글자 수 제한, 필수 문구를 설정으로 관리하고, 실제 검증 과정은 공통 모듈에서 처리할 수 있다. 새로운 설문 공지가 추가되더라도 기존 로직을 복제하기보다 설정을 추가하는 방식으로 확장할 수 있다.

이 과정에서 중요한 것은 새로운 기능을 추가한 뒤 기존 기능이 정상적으로 작동하는지 확인하는 것이다. 기존 공지 유형과 새 설문 유형, 잘못된 입력을 각각 테스트해야 한다.

서브워크플로와 입력·출력 계약

반복적으로 사용되는 검증 로직은 별도의 서브워크플로로 분리할 수 있다. 메인 워크플로는 검증 기능을 직접 구현하는 대신 필요한 데이터를 전달하고 결과를 받아 다음 단계를 진행한다.

이 방식은 일반적인 프로그래밍의 함수나 모듈과 비슷하다.

•  

• 입력 계약: 어떤 데이터를 전달해야 하는가?

• 처리 로직: 전달받은 데이터를 어떻게 검사하는가?

• 출력 계약: 어떤 형식으로 결과를 반환하는가?

예를 들어 공지 작성과 SMS 발송이 동일한 검증 모듈을 사용하더라도, 허용 글자 수나 필수 조건은 서로 다를 수 있다.

특히 기존 모듈의 출력 형식을 변경하면 이를 사용하는 다른 워크플로가 영향을 받을 수 있다. 기존 호출자는 true/false를 기대하는데 새로운 모듈이 allow, warning, block을 반환한다면 호환성 문제가 발생할 수 있다.

따라서 변경 범위를 확인하고, 필요한 경우 새 버전을 분리하며, 기존 호출자까지 포함해 회귀 테스트를 수행하는 것이 중요하다.

2. 여러 AI 코딩 도구의 결과 비교하기

이후에는 Codex, Claude Code, Gemini 등 여러 AI 코딩 도구를 활용해 비슷한 작업을 수행하고 결과를 비교했다.

각 도구에 수업에서 배운 내용을 바탕으로 자동화할 만한 업무를 제안하도록 요청하고, 학습 내용을 정리한 문서와 워크플로 구현 결과를 살펴봤다.

예시로 다뤄진 자동화 아이디어는 다음과 같다.

• 회의록 요약 및 후속 작업 배분

• 공지 작성과 채널별 문구 변환

• 고객 문의 분류 및 답변 초안 작성

• 이메일과 보고서 처리

• 영수증 및 비용 청구 내역 검증

• 뉴스와 경쟁사 정보 모니터링

• 신규 구성원 온보딩

같은 요구사항을 전달해도 도구마다 결과의 구성, 설명의 깊이, 파일 구조, 테스트 포함 여부가 달라질 수 있다. 따라서 특정 도구가 생성한 결과를 그대로 정답으로 받아들이기보다, 실제 요구사항에 부합하는지 비교하는 태도가 필요하다.

AI에게 작업을 맡길 때 필요한 기준

AI 코딩 에이전트가 워크플로를 생성했다고 해서 곧바로 운영 환경에 적용하는 것은 위험하다. 요구사항을 먼저 정의하고, 구현 계획과 테스트 항목을 확인한 다음 실행 결과를 검토해야 한다.

특히 외부 시스템에 워크플로를 등록하거나 원격 저장소에 코드를 푸시하는 작업은 결과에 영향을 줄 수 있다. 이러한 작업은 명시적인 지시와 검토 절차를 두는 것이 좋다.

여러 에이전트가 동일한 프로젝트 폴더를 동시에 수정하면 파일 충돌이나 예상하지 못한 변경이 발생할 수도 있다. 각 도구의 작업 범위와 생성 파일을 확인하고, 최종 변경 사항을 검토하는 과정이 필요하다.

3. AGENTS.md와 프로젝트 지침 관리

여러 AI 코딩 도구를 사용하면서 프로젝트의 공통 규칙을 문서로 관리하는 방법도 다뤘다.

AGENTS.md는 프로젝트에서 작업하는 에이전트가 따라야 할 지침을 정리하는 데 사용할 수 있다. 예를 들어 다음과 같은 내용을 명시할 수 있다.

• Python 패키지 관리에 uv를 우선 사용한다.

• 워크플로를 자동으로 푸시하지 않는다.

• 등록하기 전에 동일한 이름의 워크플로가 있는지 확인한다.

• 새로 생성한 기능을 검토 없이 바로 활성화하지 않는다.

• 테스트를 작성하고 실행 결과를 확인한다.

이렇게 프로젝트 규칙을 파일로 관리하면 매번 긴 프롬프트를 반복해서 작성하는 부담을 줄일 수 있다.

다만 모든 AI 도구가 같은 지침 파일을 동일하게 읽는 것은 아니다. 공통 지침과 도구별 설정을 구분하고, 변경한 지침이 현재 세션에 반영되었는지도 확인해야 한다.

또한 uv와 같은 도구가 이미 설치되어 있는지, 어떤 Python 인터프리터를 사용할 수 있는지, 기존 워크플로를 조회할 수 있는 명령어가 무엇인지 확인하는 등 개발 환경을 파악하는 것도 중요하다.

4. 명세부터 실행 가능한 계산기 앱까지

오후에는 n8n 워크플로를 넘어 데스크톱 애플리케이션을 만드는 과정으로 확장했다.

계산기 앱을 예로 들어 요구사항을 정리하고, 제품 명세와 실행 계획을 작성한 뒤 코드를 생성하고 빌드하는 흐름을 살펴봤다.

단순히 계산기 화면을 만들어 달라고 요청하는 것이 아니라 다음과 같은 요구사항을 구체화하는 방식이다.

• 수식을 입력할 수 있는 화면

• 계산 버튼과 결과 표시 영역

• Enter 키를 통한 계산

• 잘못된 수식에 대한 오류 처리

• 최근 계산 내역을 다시 확인하는 기능

이후 작업을 구현 단계로 나누고, 필요한 코드와 테스트를 작성하며 실행 가능한 앱으로 빌드한다.

Windows에서는 C#/.NET 및 WinForms, macOS에서는 Swift와 Xcode 등 플랫폼에 맞는 기술을 사용할 수 있다. 개발 환경과 운영체제에 따라 빌드 결과물과 실행 방식도 달라진다.

강사의 시연에서는 계산기 앱을 실행한 뒤 거듭제곱 연산이 기대대로 처리되지 않는 문제를 확인하고, 해당 기능을 추가하도록 에이전트에 요청하는 과정도 나왔다.

이 사례에서 중요한 점은 UI만 수정하는 것으로 모든 기능이 해결되는 것은 아니라는 것이다. 수식 처리 방식이나 연산자 파싱 로직을 변경해야 할 수도 있으므로, 실제 오류를 확인하고 관련 로직과 테스트까지 함께 점검해야 한다.

5. 메뉴 바 유틸리티와 AI 사용량 관리

마지막으로 기존 앱을 확장해 시스템 정보를 간단히 확인할 수 있는 유틸리티 아이디어를 다뤘다.

macOS의 메뉴 바나 Windows의 시스템 트레이와 같은 영역에 CPU 사용률을 표시하면 별도의 큰 창을 열지 않고도 현재 상태를 확인할 수 있다.

이 아이디어를 AI 코딩 도구의 사용량 관리에도 적용할 수 있다. 예를 들어 현재 사용량, 남은 한도, 갱신 시점 등을 한눈에 볼 수 있다면 작업 도중 사용 제한에 도달하는 상황을 줄이는 데 도움이 된다.

다만 CPU 사용률은 운영체제에서 측정할 수 있지만, AI 서비스의 사용량은 서비스가 제공하는 조회 기능이나 API에 따라 확인 방법이 달라진다. 단순한 호출 횟수만으로 실제 토큰 사용량이나 남은 한도를 정확히 알 수 있는 것은 아니다.

또한 기능을 추가할 때는 TODO.md, SPEC.md, IMPL_PLAN.md와 같은 문서에도 변경 내용을 반영해야 한다. 코드와 문서가 서로 다른 상태로 남지 않도록 관리하는 것이 중요하다.

새롭게 정리한 점

70일차 수업에서 반복해서 등장한 공통점은 AI가 작업을 수행할 수 있도록 명확한 구조와 기준을 먼저 제공해야 한다는 것이다.

워크플로에서는 입력·출력 계약과 공통 모듈이 중요했고, AI 코딩 도구를 사용할 때는 프로젝트 지침과 실행 계획이 중요했다. 애플리케이션 개발에서도 요구사항과 명세를 구체화한 다음 구현하고 테스트하는 흐름이 이어졌다.

결국 도구가 달라져도 개발 과정의 기본 원리는 크게 다르지 않다. 요구사항을 정의하고, 작업을 나누고, 구현 결과를 검증하며, 변경으로 인해 기존 기능이 깨지지 않았는지 확인하는 과정이 필요하다.

또한 여러 AI 코딩 도구가 서로 다른 결과를 내놓을 수 있다는 점을 고려하면, 도구를 선택하는 것만큼 결과를 평가하는 기준을 갖추는 것도 중요하다.

복습할 부분

• 서브워크플로의 입력·출력 계약과 일반 함수의 매개변수·반환값 비교

• 모듈의 출력 형식이 변경될 때 발생할 수 있는 하위 호환성 문제

• 회귀 테스트가 필요한 이유와 테스트 대상 선정 방법

• AGENTS.md와 도구별 지침 파일의 역할

• TODO.md, SPEC.md, IMPL_PLAN.md의 차이

• AI 코딩 에이전트가 생성한 앱의 빌드·실행·검증 과정

• AI 서비스의 사용량과 한도를 확인할 때 주의할 점

오늘의 회고

오늘 수업은 AI 코딩 에이전트를 활용하는 범위가 단순한 코드 생성에서 워크플로 설계, 모듈화, 테스트, 앱 빌드까지 넓어질 수 있다는 점을 보여줬다.

특히 비슷한 워크플로를 하나의 공통 모듈로 정리하더라도 출력 계약이 바뀌면 기존 호출자에 문제가 생길 수 있다는 점이 중요했다. 기능을 재사용하는 것 자체보다, 어떤 입력을 받고 어떤 결과를 반환하며 변경이 다른 기능에 어떤 영향을 미치는지 함께 관리해야 한다.

또한 여러 AI 코딩 도구를 활용할 때는 생성 결과의 분량이나 형태만 비교할 것이 아니라, 요구사항 충족 여부와 테스트 결과, 외부 시스템에 영향을 주는 작업까지 확인해야 한다.

계산기 앱과 메뉴 바 유틸리티 사례에서도 같은 원칙이 이어졌다. 아이디어를 명세로 구체화하고, 구현 계획을 세우며, 실제로 실행해 본 뒤 부족한 부분을 수정하는 과정이 필요하다.

이번 교시는 다양한 도구를 활용하는 방법과 함께, AI에게 작업을 맡기더라도 개발 방향과 검증 기준은 명확하게 관리해야 한다는 점을 정리한 하루였다.

1. 오늘 배운 내용

69일차에는 AI 에이전트가 단순히 결과물을 생성하는 것을 넘어, 여러 역할이 협업하는 워크플로우를 어떻게 설계하고 검증할 것인지 학습했다. 또한 Docker 기반의 서비스 운영, 데이터베이스 선택, 바이브 코딩 에이전트를 활용한 개발 방식까지 함께 살펴봤다.

특히 오늘 수업에서 중요하게 다가온 부분은 AI가 코드를 만들어 주는 것과 그 코드가 올바르게 동작하도록 설계하고 검증하는 것은 별개의 문제라는 점이다.

워크플로우를 구성하는 노드가 많아지고 에이전트 간 협업이 복잡해질수록 정상적인 결과뿐만 아니라 실패했을 때의 동작까지 확인해야 한다. 이를 위해 실행 기록과 처리 단계, 역할별 결과를 살펴보고, 오류가 발생하면 무조건 성공으로 처리하지 않도록 설계하는 방법을 배웠다.

2. 핵심 개념

2-1. 멀티 에이전트 워크플로우와 역할 분리

수업에서는 공지문 작성 과정을 예시로 Writer와 Reviewer의 역할을 분리한 워크플로우를 다뤘다.

Writer가 공지 초안을 작성하면 Reviewer가 내용을 검토한다. 검토에 실패하면 작성 단계로 돌아가 수정하고, 다시 검토하는 방식이다. 이 과정에서 무한 반복이 발생하지 않도록 재시도 횟수를 제한하고, 정해진 횟수 안에 해결되지 않으면 담당자가 확인하도록 설계했다.

이 구조에서 중요한 것은 단순히 에이전트를 여러 개 사용하는 것이 아니다. 각 에이전트의 책임을 명확히 나누고, 실행 결과를 확인하며, 실패했을 때 다음 행동을 미리 정해 놓는 것이다.

2-2. Fail Open과 Fail Closed

오늘은 워크플로우에서 오류가 발생했을 때 어떻게 처리할 것인지도 비교했다.

• Fail Open: 일부 처리에 실패하더라도 성공한 결과를 반환하거나 나머지 처리를 계속하는 방식이다. 실패한 작업이 있어도 결과를 활용할 수 있는 상황에 적합하다.

• Fail Closed: 필수 검증이나 보안 절차가 실패하면 처리를 중단하는 방식이다. 검증되지 않은 결과가 외부로 나가면 문제가 되는 상황에서 중요하다.

공지문 검토 사례에서는 Reviewer가 응답하지 않는다면 공지를 게시하지 않는 것이 요구사항이었다. 검토가 이루어지지 않았는데도 통과로 간주하면 개인정보나 잘못된 정보가 포함된 공지가 게시될 수 있기 때문이다.

이 사례를 통해 오류 없이 실행되는 것만큼이나 실패를 올바르게 처리하는 것이 중요하다는 점을 확인했다.

2-3. 실행 추적과 검증

워크플로우의 최종 결과만 확인하면 어느 단계에서 문제가 발생했는지 파악하기 어렵다. 따라서 실행 단계별 기록인 steps, Writer와 Reviewer의 실행 기록, 각 단계의 입출력을 함께 확인하는 방식이 소개됐다.

정상적으로 한 번에 검토를 통과한 경우와 첫 번째 검토에 실패해 두 번째 라운드에서 통과한 경우는 최종 결과가 비슷하더라도 내부 실행 과정은 다르다.

실행 기록을 남기면 다음을 확인할 수 있다.

• 어떤 역할이 실행됐는가?

• 몇 번째 라운드에서 통과했는가?

• 어느 단계에서 실패했는가?

• 에이전트가 응답하지 않을 때 어떤 결과를 반환했는가?

바이브 코딩으로 생성한 코드를 무조건 신뢰하기보다, 실제로 실행해 보고 결과와 실행 경로를 확인하는 검증 과정이 필요하다는 점과 연결된다.

2-4. 바이브 코딩과 코드 검증

오늘 수업에서는 바이브 코딩으로 만든 프로그램을 단순히 실행하는 데서 그치지 않고, 내부 구조와 동작 결과를 확인하는 과정도 강조됐다.

코딩 에이전트에게 작은 수정을 요청하더라도 실제로는 여러 위치의 코드가 변경될 수 있다. 수정 범위가 커지면 기존 기능이 손상되거나 예상하지 못한 문제가 생길 가능성도 있다.

따라서 문제가 발생했을 때는 무조건 다시 코딩을 요청하기보다 다음 순서로 접근할 필요가 있다.

1. 현재 실행 결과와 오류를 확인한다.

2. 문제가 발생한 노드나 코드의 역할을 파악한다.

3. 간단한 수정으로 해결할 수 있는지 확인한다.

4. 수정 후 기존 테스트와 관련 시나리오를 다시 실행한다.

5. 결과뿐 아니라 실행 경로와 실패 처리까지 확인한다.

수업에서는 이러한 검증을 바탕으로 기존 멀티 에이전트 워크플로우를 터미널에서 확인할 수 있는 TUI(Text User Interface, 텍스트 기반 사용자 인터페이스) 형태로 확장하는 요구사항도 다뤘다.

작성자와 검토자의 결과를 구분해 표시하고, 처리 시간과 실행 기록을 남기며, 재시도 횟수를 제한하는 기능 등이 주요 요구사항이었다. 여기에 역할별 지시문을 설정 파일로 관리하고, 필요할 때 번역 담당과 같은 역할을 추가할 수 있도록 확장하는 방향도 제시됐다.

2-5. 데이터베이스 선택과 아키텍처 설계

데이터베이스에 관한 설명에서는 프로젝트 규모와 데이터의 특성에 따라 저장소를 구분하는 이유를 살펴봤다.

예를 들어 서비스 설정처럼 속성이 자주 바뀌는 데이터와 시스템 모니터링처럼 시간에 따라 계속 누적되는 데이터는 서로 다른 특성을 가진다. 모든 데이터를 하나의 데이터베이스에 저장하는 방법도 가능하지만, 시스템이 커지면 데이터의 특성에 맞는 저장소를 선택하는 것이 유리할 수 있다.

또한 처음 선택한 데이터베이스나 클라우드 서비스에 지나치게 의존하면 나중에 다른 환경으로 이전하기 어려워질 수 있다. 강사는 특정 환경에 종속되지 않도록 설계하는 관점과 Docker Compose 등을 활용해 여러 실행 환경에서 서비스를 운영할 수 있는 구조의 중요성을 설명했다.

핵심은 처음부터 무조건 여러 데이터베이스를 도입하는 것이 아니라, 데이터의 특성·서비스 규모·이전 가능성을 고려해 아키텍처를 설계하는 것이다.

2-6. Docker Compose와 서비스 확장

서비스 운영 규모에 따른 배포 방식도 다뤘다.

• Docker Compose: 하나의 환경에서 여러 컨테이너로 구성된 서비스를 관리할 때 유용하다.

• Docker Swarm: 여러 노드에 컨테이너를 배포하고 관리하는 데 활용할 수 있다.

• Kubernetes: 대규모 컨테이너 운영, 배포 관리, 확장 및 롤링 업데이트 등을 지원한다.

모든 서비스에 처음부터 Kubernetes를 적용할 필요는 없다. 서비스의 규모와 운영 요구사항에 따라 적절한 방식을 선택해야 한다.

특히 롤링 업데이트는 기존 서비스를 한꺼번에 중단하고 새 버전으로 바꾸는 대신, 일부 인스턴스부터 순차적으로 교체해 서비스 중단을 줄이는 배포 방식이다.

바이브 코딩 에이전트의 활용 범위도 코드 작성에만 한정되지 않는다. Docker Compose 설정을 이해하고 수정하거나, 운영 중 발생한 문제의 원인과 해결 방법을 조사하는 데도 활용할 수 있다. 다만 운영 환경에서는 권한, 변경 범위, 보안 및 실행 결과를 반드시 확인해야 한다.

3. 오늘의 실습 및 시연

오늘 수업에서는 기존에 구성한 Writer·Reviewer 워크플로우를 중심으로 여러 상황을 확인했다.

• 정상적으로 검토를 통과하는 경우

• 첫 번째 검토에서 실패한 뒤 재시도하는 경우

• 검토자가 응답하지 않는 경우

• 실패했을 때 공지를 게시하지 않고 담당자 확인으로 처리하는 경우

• 실행 기록을 통해 각 역할과 라운드의 진행 상황을 확인하는 경우

이러한 과정은 강사가 진행한 워크플로우 시연과 테스트를 중심으로 정리했다. 전사문만으로는 모든 테스트를 직접 수행했는지 확인할 수 없으므로, 이를 개인이 완성한 실습 결과로 단정하지 않았다.

또한 강사는 새로운 TUI 프로그램을 만들기 위한 요구사항을 제시하고, 별도의 작업 폴더에서 코딩 에이전트가 스펙을 정리하고 프로그램을 구성하도록 진행하는 과정을 설명했다.

주요 요구사항은 다음과 같았다.

• Writer와 Reviewer의 처리 과정을 순서대로 표시하기

• 역할별 결과와 실행 시간을 구분해 보여주기

• 재시도 횟수를 제한하고 해결되지 않으면 사용자에게 알리기

• 역할별 지시문과 추가 역할을 설정 파일로 관리하기

• 검토 결과와 실행 기록을 남기되 API 키 등 민감한 정보는 기록하지 않기

이 작업의 목적은 단순히 프로그램을 하나 더 만드는 것이 아니라, 기존 워크플로우의 동작을 직접 확인하고 수정할 수 있는 도구를 만드는 데 있다.

4. 오늘 새롭게 정리한 관점

오늘 수업의 여러 내용을 연결해 보면 세 가지 관점이 중요하다.

첫째, 에이전트의 역할 분리와 제어 흐름은 별도로 설계해야 한다. 역할을 나누는 것만으로 안정적인 워크플로우가 완성되는 것은 아니다. 실패 시 재시도할지, 중단할지, 사람에게 넘길지를 함께 결정해야 한다.

둘째, 검증되지 않은 결과를 성공으로 처리하지 않아야 한다. 최종 응답이 나왔다는 사실만으로 정상적인 처리가 이루어졌다고 판단할 수 없다. 중간 단계의 실행 기록과 실제 결과를 함께 확인해야 한다.

셋째, 코드 생성 능력과 시스템 설계 능력은 다르다. 코딩 에이전트가 코드를 작성하고 설정 파일을 수정해 줄 수는 있지만, 어떤 구조가 필요한지와 어떤 실패를 막아야 하는지를 판단하려면 개발자가 시스템의 구성 원리를 이해해야 한다.

특히 데이터베이스 선택, 컨테이너 운영, 서비스 확장과 같은 문제는 단순히 코드를 생성하는 것만으로 해결되지 않는다. 요구사항에 맞는 구조를 선택하고, 그 구조가 실제로 의도대로 동작하는지 검증하는 과정이 필요하다.

5. 복습할 부분

오늘 학습한 내용을 바탕으로 다음 항목을 다시 확인할 필요가 있다.

• Writer와 Reviewer의 역할 분리 및 재시도 흐름

• Fail Open과 Fail Closed의 차이와 적용 기준

• 실행 단계별 기록을 통해 오류 발생 위치를 추적하는 방법

• TUI와 기존 워크플로우 엔진의 관계

• 관계형 데이터베이스, NoSQL, 시계열 데이터베이스의 선택 기준

• Docker Compose, Docker Swarm, Kubernetes의 차이

• 코딩 에이전트가 만든 코드와 설정을 검증하는 방법

강사는 다음 단계로 각자 업무에 적용할 수 있는 워크플로우 시나리오를 선정하고, 코딩 에이전트를 활용해 직접 만들어 보는 방향을 제시했다. 따라서 앞으로는 기존 예제를 따라가는 것뿐만 아니라, 내가 해결하고 싶은 문제를 구체적인 요구사항으로 정리하고 이를 워크플로우로 구현하는 연습이 중요할 것이다.

6. 오늘의 회고

69일차에는 AI 에이전트의 협업 구조를 설계하는 것에서 한 걸음 더 나아가, 실행 과정과 실패 상황을 어떻게 통제하고 검증할 것인지 살펴봤다.

멀티 에이전트 워크플로우에서 중요한 것은 여러 에이전트가 결과를 주고받는 것만이 아니다. 각자의 역할을 분명하게 나누고, 처리 과정이 기록되도록 하며, 검토가 실패했을 때 안전하게 중단할 수 있어야 한다.

또한 바이브 코딩으로 개발하는 환경에서도 데이터베이스 선택과 서비스 아키텍처에 대한 이해는 여전히 필요하다. 코드를 직접 작성하는 부담이 줄어들더라도, 어떤 구조를 만들어야 하는지 판단하고 생성된 결과가 요구사항을 만족하는지 검증하는 역할까지 사라지는 것은 아니기 때문이다.

오늘 배운 내용을 실제 개발 역량으로 연결하려면 기존 예제를 반복해서 따라가는 데 그치지 않고, 작은 업무 시나리오 하나를 직접 설계하고 구현해 보는 과정이 필요하다. 특히 정상적인 경우뿐 아니라 실패와 재시도, 담당자 확인까지 고려한 워크플로우를 만들어 보면 오늘 배운 개념을 더 구체적으로 이해할 수 있을 것이다.

핵심 정리: AI 에이전트 개발에서는 역할 분리, 실패 처리, 실행 추적, 아키텍처 설계가 함께 이루어져야 한다. 바이브 코딩은 구현을 돕는 수단이며, 안정적인 시스템을 만드는 데 필요한 설계와 검증은 여전히 중요하다.