이번 주 학습 요약

이번 주에는 AI 에이전트와 워크플로우를 단순히 구현하는 것을 넘어, 실제 서비스로 운영하기 위해 필요한 기술들을 집중적으로 학습했다.

지금까지는 LLM을 연결하고 n8n으로 여러 작업을 자동화하는 방법을 주로 배웠다면, 이번 주에는 서비스가 실패했을 때 어떻게 복구할 것인지, 개인정보를 어떻게 보호할 것인지, 배포 전 품질을 어떻게 검증할 것인지, 운영 비용은 어떻게 관리할 것인지에 초점이 맞춰졌다.

또한 Electron을 활용한 데스크톱 애플리케이션 개발, AI 코딩 에이전트와 바이브 코딩, 프론트엔드와 백엔드의 아키텍처 등 개발 전반에 관한 내용도 함께 살펴봤다.

이번 주의 핵심은 AI가 정상적으로 동작하는 것과 실제 운영할 수 있는 서비스를 만드는 것은 다르다는 점이었다.

1. 인상 깊었던 배움

1-1. 오류가 발생해도 서비스를 유지하는 설계

가장 중요하게 다룬 내용 중 하나는 장애 대응과 오류 처리였다.

AI 서비스를 운영하다 보면 LLM 응답이 늦어지거나, 외부 API가 중단되거나, 여러 작업 중 일부만 실패하는 상황이 발생할 수 있다.

이러한 상황에 대비하기 위해 다음 개념을 학습했다.

• Timeout: 응답을 무한정 기다리지 않도록 제한 시간을 설정한다.
• Retry: 일시적인 오류가 발생하면 정해진 조건에 따라 다시 시도한다.
• Backoff: 재시도 사이에 대기 시간을 두어 서버 부하를 줄인다.
• Fallback: 기존 처리 방식이 실패했을 때 대체 경로를 사용한다.
• DLQ(Dead Letter Queue): 정상적으로 처리하지 못한 작업을 별도로 보관해 나중에 확인하거나 재처리한다.

특히 재시도 기능이 항상 좋은 해결책은 아니라는 점이 인상 깊었다.

예를 들어 고객 문의를 접수하는 API에서 서버가 요청을 정상적으로 처리했지만 응답을 전달하지 못했다고 가정해 보자.

이때 클라이언트가 무조건 다시 요청하면 같은 고객 문의가 두 번 접수될 수 있다.

이를 방지하기 위해 학습한 개념이 **멱등성(Idempotency)**이다.

멱등성은 같은 요청을 여러 번 실행하더라도 최종 결과가 중복되지 않도록 만드는 성질이다.

또한 여러 작업을 묶어 처리하는 배치 워크플로우에서는 전체 요청을 무조건 다시 실행하는 대신 성공한 작업과 실패한 작업을 구분해야 한다는 점도 배웠다.

단순히 오류를 잡는 것보다 오류가 발생했을 때 데이터와 처리 결과를 안전하게 유지하는 설계가 중요하다는 것을 확인할 수 있었다.

1-2. AI 에이전트의 보안과 가드레일

AI가 생성한 답변을 사용자에게 그대로 전달하는 것이 항상 안전한 것은 아니다.

답변에 개인정보나 API 키, 내부 시스템 정보가 포함될 수 있기 때문이다.

이번 주에는 이러한 문제를 방지하기 위한 출력 필터와 보안 가드레일을 학습했다.

출력 필터는 AI가 생성한 최종 답변을 사용자에게 전달하기 전에 민감한 정보가 포함되어 있는지 검사하는 장치다.

예를 들어 전화번호나 이메일 주소를 마스킹하거나, API 키가 노출되는 경우 응답을 차단하도록 설계할 수 있다.

또한 보안 검사 자체에 문제가 발생했을 때 요청을 어떻게 처리할 것인지도 중요하다.

• Fail-Open: 보안 검사가 실패해도 요청을 통과시킨다.
• Fail-Closed: 보안 검사가 실패하면 요청을 차단한다.

보안이 중요한 서비스에서는 검사가 정상적으로 이루어지지 않았다는 이유로 위험한 요청을 통과시키지 않도록 설계할 필요가 있다.

이와 연결해 개발자가 Git에 코드를 올리기 전에 민감한 정보를 검사하는 T-Scan 도구의 요구사항도 살펴봤다.

여기서는 API 키나 개인정보를 탐지하는 기능뿐 아니라 정상적인 데이터까지 잘못 차단하지 않도록 오탐과 미탐을 줄이는 과정도 중요하게 다뤘다.

1-3. AI 서비스의 품질 검증과 릴리스 관리

LLM 기반 서비스는 코드를 수정하지 않더라도 모델이나 프롬프트가 바뀌면 응답 결과가 달라질 수 있다.

따라서 단순히 프로그램이 실행되는지만 확인해서는 서비스의 품질을 보장하기 어렵다.

이번 주에는 릴리스별 검증과 품질 게이트(Quality Gate)를 학습했다.

품질 게이트는 미리 정한 기준을 충족한 버전만 다음 단계로 진행할 수 있도록 하는 검증 절차다.

예를 들어 새로운 버전의 AI 워크플로우를 배포하기 전에 동일한 테스트 질문을 실행하고, 답변 정확도와 응답 시간 등을 이전 버전과 비교할 수 있다.

또한 AI 코딩 에이전트가 워크플로우를 수정할 때 변경 이력을 기록하고 이전 버전과 비교하는 방법도 살펴봤다.

AI가 빠르게 코드를 작성해 주더라도 변경 사항을 이해하고 검증하는 책임은 여전히 개발자에게 있다는 점을 생각하게 하는 내용이었다.

1-4. FinOps와 LLM 운영 비용 관리

이번 주에는 AI 서비스의 운영 비용을 관리하는 FinOps(Financial Operations)도 학습했다.

FinOps는 클라우드 자원의 사용량과 비용을 측정하고 최적화해 효율적으로 운영하는 방식이다.

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

1. Measure: 현재 비용과 사용량을 측정한다.
2. Optimize: 불필요한 비용이 발생하는 부분을 찾아 개선한다.
3. Operate: 개선된 상태를 지속적으로 관리한다.

특히 LLM 서비스는 API 호출 횟수와 토큰 사용량에 따라 비용이 달라지기 때문에 요청 단위로 비용을 추적하는 것이 중요하다.

하나의 워크플로우 안에서도 문서 분석, 정보 검색, 답변 생성 등 여러 단계에서 LLM을 호출할 수 있다.

따라서 전체 비용만 확인하는 것보다 어떤 단계에서 얼마나 많은 토큰을 사용하는지 파악해야 최적화할 수 있다.

또한 Docker 기반 모니터링과 서버 자원 사용량도 함께 살펴보면서 LLM API 비용뿐 아니라 CPU, 메모리, 스토리지 등 전체 시스템 운영 비용을 고려해야 한다는 점을 배웠다.

2. AI 코딩 에이전트와 개발 방식의 확장

이번 주에는 서비스 운영에 관한 내용 외에도 AI를 활용한 개발 방식에 대해 살펴봤다.

Electron과 데스크톱 애플리케이션

Electron은 HTML, CSS, JavaScript와 같은 웹 기술을 활용해 데스크톱 애플리케이션을 개발할 수 있는 프레임워크다.

웹 개발 기술을 활용할 수 있다는 장점이 있지만 메모리 사용량이나 배포 파일 크기 등도 고려해야 한다.

Qt, GTK, Flutter 등 다른 UI 기술과 비교하면서 개발 목적과 환경에 따라 적절한 도구를 선택하는 것이 중요하다는 점을 배웠다.

바이브 코딩과 AI 코딩 에이전트

AI 코딩 에이전트를 활용하는 개발 방식도 계속해서 다뤘다.

단순히 AI에게 코드를 작성해 달라고 요청하는 것이 아니라, 프로젝트 규칙과 요구사항을 먼저 정리하고 명세서와 실행 계획을 바탕으로 개발을 진행하는 방식이다.

특히 AGENTS.md와 같은 파일에 프로젝트 규칙을 정의하면 AI 에이전트가 작업할 때 참고할 수 있다.

AI가 코드를 빠르게 생성하는 것은 분명 장점이지만, 요구사항이 불명확하거나 결과를 검증하지 않으면 오히려 수정할 부분이 늘어날 수 있다.

결국 AI를 잘 활용하기 위해서는 코드를 생성하는 능력뿐 아니라 문제를 정의하고, 작업을 나누고, 결과를 검토하는 능력이 중요하다는 점을 다시 확인했다.

3. 팀 프로젝트와 연결되는 부분

이번 주에는 기업형 AI 프로젝트를 어떤 방향으로 설계할 것인지도 논의했다.

프로젝트 주제를 선정할 때는 단순히 AI를 활용할 수 있는지보다 실제로 해결할 문제가 있는지를 먼저 살펴봐야 한다.

주제를 검토하는 기준으로는 필요성, 데이터 확보 가능성, 구현 난이도, 결과물의 직관성, 팀원들의 관심도 등을 고려했다.

POS, 콘텐츠, 공공데이터, 쇼핑몰 고객 상담, 대학교 수업 관리 등 여러 도메인을 후보로 살펴봤다.

특히 고객 상담 자동화는 이번 주에 학습한 운영 기술과 연결할 수 있는 주제다.

예를 들어 쇼핑몰 고객 상담 시스템을 개발한다고 가정하면 다음과 같은 문제를 함께 고려해야 한다.

• 고객의 개인정보가 AI 응답에 노출되지 않도록 필터링한다.
• 외부 API 호출이 실패하면 재시도하거나 상담원 연결로 전환한다.
• 동일한 고객 문의가 중복 접수되지 않도록 처리한다.
• AI 답변의 정확도를 테스트하고 배포 기준을 마련한다.
• 상담 요청별 LLM 사용량과 운영 비용을 측정한다.

이렇게 생각해 보면 이번 주에 배운 내용들이 서로 독립적인 기술이 아니라 하나의 서비스를 안정적으로 운영하기 위해 연결되는 요소라는 것을 알 수 있다.

4. 어려웠던 부분과 앞으로 해결할 과제

이번 주에는 개별 기술의 사용법보다 여러 기술을 함께 고려해야 하는 부분이 어려운 학습 과제로 남았다.

예를 들어 재시도 기능만 놓고 보면 실패한 작업을 다시 실행하는 단순한 기능처럼 보인다.

하지만 실제 서비스에서는 재시도로 인해 중복 데이터가 발생할 수 있고, LLM 호출 비용이 증가할 수도 있으며, 외부 API에 과도한 요청이 몰릴 수도 있다.

따라서 재시도 횟수와 대기 시간, 멱등성, DLQ, 비용 관리까지 함께 고려해야 한다.

보안과 품질 검증도 마찬가지다.

개념을 이해하는 것과 실제 워크플로우에서 예외 상황을 설계하고 검증하는 것은 별개의 문제이기 때문에 앞으로 직접 구현하며 확인할 필요가 있다.

이번 주에 학습한 개념들을 단순히 암기하는 것보다 실제 프로젝트의 어느 부분에 적용해야 하는지 연결해서 복습하는 것이 중요할 것 같다.

5. 새롭게 이해한 점

이번 주 학습을 통해 AI 서비스 개발에서 중요하게 생각해야 할 범위가 더 넓어졌다.

처음에는 LLM을 연결하고 원하는 답변을 생성하는 것 자체가 주요 목표였다면, 이제는 그 결과를 얼마나 안정적이고 안전하게 제공할 수 있는지까지 고려해야 한다.

특히 다음 세 가지가 서로 연결된다는 점이 중요했다.

첫째, 안정성이다. 오류가 발생해도 전체 서비스가 중단되지 않도록 설계해야 한다.

둘째, 신뢰성이다. 개인정보를 보호하고 AI의 출력 결과를 검증할 수 있어야 한다.

셋째, 운영 효율성이다. 품질을 유지하면서도 비용과 자원을 적절하게 관리해야 한다.

이러한 요소들이 갖춰져야 AI 워크플로우가 단순한 실습 결과물을 넘어 실제 서비스로 발전할 수 있다.

6. 현재 할 수 있는 것과 부족한 부분

이번 주에 학습한 내용을 기준으로 현재 이해한 부분과 앞으로 보완할 부분을 구분해 봤다.

현재 이해한 부분

• 타임아웃, 재시도, 백오프, 폴백의 역할과 차이
• 멱등성과 DLQ가 필요한 이유
• 개인정보 출력 필터와 Fail-Closed의 개념
• 릴리스 검증과 품질 게이트의 필요성
• FinOps와 LLM 토큰 사용량 추적의 기본 구조
• AI 코딩 에이전트를 활용한 명세 중심 개발 방식

추가 학습이 필요한 부분

• n8n에서 오류 처리 워크플로우를 실제로 구성하고 검증하기
• 멱등성 키와 중복 요청 방지 로직 구현하기
• DLQ에 저장된 실패 작업의 재처리 흐름 만들기
• AI 응답의 품질을 정량적으로 평가하는 기준 설정하기
• 요청별 LLM 비용과 시스템 자원을 모니터링하기

개념을 설명할 수 있는 수준에서 나아가 실제 코드와 워크플로우로 구현하는 연습이 필요하다.

7. 다음 주 학습 계획

다음 주에는 이번 주에 학습한 운영 개념을 팀 프로젝트와 연결해 보는 것이 목표다.

특히 고객 상담 자동화와 같은 서비스를 가정하고 정상적인 처리 과정뿐 아니라 오류가 발생했을 때의 흐름까지 함께 설계해 보고 싶다.

우선 구현할 기능과 데이터 구조를 명확히 정의하고, 이후 오류 처리와 보안, 검증 기준을 단계적으로 추가하는 방향으로 접근할 계획이다.

또한 AI 코딩 에이전트를 사용할 때도 요구사항을 충분히 정리하고 생성된 코드를 검토하는 습관을 유지하려고 한다.

8. 이번 주 KPT 회고

Keep — 유지할 점

• 새로운 개념을 단순히 외우지 않고 실제 서비스 사례와 연결해 이해하기
• AI 코딩 에이전트의 결과를 그대로 받아들이기보다 요구사항과 비교하기
• 팀 프로젝트 주제를 선정할 때 기술보다 해결할 문제와 데이터 확보 가능성을 먼저 고려하기

Problem — 개선할 점

• 운영 관련 개념이 많아지면서 기술 간 관계를 한 번에 이해하기 어려운 부분이 있음
• 개념 학습과 실제 구현 사이의 차이를 줄일 필요가 있음
• 프로젝트에 적용할 기능의 범위를 구체적으로 정리할 필요가 있음

Try — 다음에 시도할 점

• n8n으로 재시도와 오류 분기 워크플로우를 직접 구성해 보기
• 멱등성과 DLQ를 간단한 고객 문의 처리 예제로 구현해 보기
• AI 응답 품질과 비용을 확인할 수 있는 기본적인 평가 항목 정의하기
• 팀 프로젝트 요구사항과 역할을 명확히 정리한 뒤 구현 범위 확정하기

9. 이번 주를 마치며

이번 주는 AI 오케스트레이션을 바라보는 관점을 확장할 수 있는 내용이 많았다.

지금까지는 여러 AI 에이전트와 외부 도구를 연결해 하나의 작업을 자동화하는 방법에 집중했다면, 이번에는 그 자동화가 실제 환경에서 안정적으로 동작하기 위해 무엇이 필요한지 살펴봤다.

특히 장애 대응, 보안, 품질 검증, 비용 관리가 별개의 문제가 아니라 서로 영향을 주고받는다는 점이 핵심이었다.

AI가 코드를 작성하고 워크플로우를 구성해 주더라도 서비스의 요구사항을 정의하고, 위험 요소를 판단하고, 결과를 검증하는 과정은 여전히 중요하다.

앞으로는 단순히 기능이 동작하는 프로젝트를 만드는 것에서 한 단계 더 나아가 실패 상황까지 고려하고, 운영할 수 있는 AI 서비스를 설계하는 개발자가 되는 것을 목표로 학습을 이어가려고 한다.

1. 오늘 배운 내용

73일차에는 AI 에이전트의 보안 강화부터 바이브 코딩을 활용한 도구 개발, 그리고 웹 애플리케이션의 프론트엔드와 백엔드가 분리된 배경까지 폭넓게 살펴봤다.

앞부분에서는 LLM이 생성한 답변에 개인정보나 내부 정보가 포함되지 않도록 검증하는 방법을 다뤘다. 이후에는 개발자가 직접 필요한 도구를 기획하고 구현하는 실습으로 이어졌다. 마지막에는 바이브 코딩으로 무언가를 만드는 것에서 그치지 않고, 실제 사용자를 찾고 제품을 운영하는 과정까지 생각해 봤다.

2. 핵심 개념 정리

2-1. LLM 워크플로우의 최종 출력 필터

AI 에이전트가 질문에 적절한 답변을 생성하더라도, 그 답변에 개인정보나 내부 정보가 포함되어 있다면 그대로 사용자에게 전달해서는 안 된다.

이를 방지하기 위해 최종 응답이 외부로 전달되기 직전에 한 번 더 검사하는 출력 필터를 적용할 수 있다.

• 전화번호, 이메일, 직원 식별 정보 등 개인정보 패턴 검사

• API 키나 내부 비밀 코드 등 민감한 정보의 노출 방지

• 필요한 경우 민감한 문자열을 마스킹하거나 응답 차단

• 차단한 이유와 처리 결과를 감사 로그로 기록

강의에서는 개인정보 마스킹과 필터링을 테스트하는 과정에서 일부 테스트가 실패하는 상황을 확인했다. 단순히 필터를 추가하는 것만으로 끝나는 것이 아니라, 정상적인 답변을 잘못 차단하는 오탐과 민감한 정보를 놓치는 미탐을 함께 점검해야 한다는 점이 중요하다.

2-2. Fail-Closed와 보안 테스트

보안 검사를 수행하는 구성 요소가 실패했을 때 어떻게 처리할지도 중요한 설계 요소다.

• Fail-Open: 검사에 실패하더라도 요청을 통과시킨다.

• Fail-Closed: 검사에 실패하면 요청을 차단한다.

보안이 중요한 워크플로우에서는 판별 모델이 공격 여부를 확실하게 판단하지 못하거나 검사 자체에 실패했을 때, 요청을 통과시키지 않는 Fail-Closed 방식을 고려할 수 있다.

또한 정상 요청과 공격 요청을 테스트 케이스로 만들어 반복 실행하고, 실패한 사례를 바탕으로 규칙과 코드를 개선해야 한다. 강의에서는 이러한 보안 테스트를 단계적으로 확장하고, 최종 출력 필터와 감사 로그를 추가하는 흐름을 살펴봤다.

2-3. 바이브 코딩으로 만드는 개발자용 보안 검사 도구

오늘 실습 주제로 제시된 도구는 T-Scan이라는 이름의 로컬 보안 검사 도구였다.

개발자가 Git 저장소에 코드를 커밋하기 전에 API 키나 개인정보가 포함되어 있는지 검사하는 것이 목적이다.

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

• 지정한 폴더와 하위 폴더를 재귀적으로 검사한다.

• .env 파일의 API 키나 비밀번호뿐 아니라 다른 파일에 복사된 동일한 값도 탐지한다.

• 주민등록번호, 전화번호, 이메일 등 개인정보 패턴을 검사한다.

• 탐지된 파일명과 줄 번호를 표시한다.

• 민감한 값 전체를 출력하지 않고 일부 문자만 남겨 마스킹한다.

• 날짜나 주문번호처럼 비슷하게 보이는 일반적인 숫자를 과도하게 탐지하지 않는다.

• 테스트용 가짜 키나 예외 처리 대상을 구분할 수 있도록 한다.

• Git 커밋 전에 검사를 실행하고, 위험한 항목이 발견되면 커밋을 중단하는 방식으로 확장할 수 있다.

기존 명령어인 grep이나 ripgrep(rg)로도 문자열을 검색할 수 있지만, 이번 과제는 이를 넘어 민감 정보 유형을 구분하고, 결과를 안전하게 표시하며, 개발 과정에 연결할 수 있는 작은 도구를 직접 설계하는 데 초점이 있었다.

강의에서 강조한 점은 도구를 만드는 것뿐 아니라 요구사항을 구체적으로 정의하는 과정도 중요하다는 것이다. 무엇을 찾을지, 어떤 결과를 보여줄지, 어떤 오탐을 줄여야 할지 명확하게 정리해야 AI 코딩 에이전트가 원하는 결과에 가까운 도구를 만들 수 있다.

2-4. 바이브 코딩은 구현 이후가 더 중요하다

강의에서는 헬스장에서 복근 사진을 촬영하면 AI가 점수를 매기고 맞춤 운동 계획을 제공하는 앱 사례를 소개했다.

이 사례에서 주목할 점은 단순히 AI로 앱을 만들었다는 사실이 아니다. 아이디어를 발견하고, 초기 구현을 시도하고, 방향을 수정한 다음 실제 고객에게 도달할 방법을 찾았다는 점이다.

제품을 만들 때 고려해야 할 흐름은 다음과 같다.

1. 문제 발견: 사람들이 실제로 불편해하거나 필요로 하는 것이 무엇인지 찾는다.

2. 수요 검증: 본격적으로 개발하기 전에 잠재 고객의 반응을 확인한다.

3. 제품 구현: AI 코딩 도구를 활용해 필요한 기능을 빠르게 만든다.

4. 배포와 운영: 앱을 배포하고 사용자 관리, 데이터 저장, 결제 등의 환경을 구성한다.

5. 고객 확보와 수익화: 목표 고객이 있는 채널을 찾고 적절한 가격 및 구독 모델을 설계한다.

강사는 앱 개발에 활용할 수 있는 데이터베이스·백엔드 서비스, 구독 결제, 분석 도구 등의 사례도 언급했다. 바이브 코딩으로 구현 비용이 낮아진 만큼, 처음 만든 결과물에 집착하기보다는 사용자 반응을 확인하고 필요하다면 방향을 수정하는 태도가 중요하다.

조회수나 다운로드 수만 보는 것이 아니라, 실제로 고객이 비용을 지불할 만큼 필요로 하는 제품인지 확인해야 한다는 점도 핵심이다.

2-5. 프론트엔드와 백엔드가 분리된 이유

후반부에는 웹 애플리케이션의 구조와 기술 발전 과정을 설명했다.

초기의 서버 중심 웹 애플리케이션에서는 화면을 표시하는 코드와 업무 규칙, 데이터베이스 접근 코드가 한 파일에 섞여 있는 경우가 많았다. 이런 구조는 기능이 늘어날수록 수정과 유지보수가 어려워지고, 여러 개발자가 같은 파일을 수정할 때 충돌이 발생하기 쉬웠다.

이러한 문제를 줄이기 위해 역할을 분리하는 구조가 발전했다.

• 프론트엔드: 사용자가 보는 화면과 사용자 입력을 담당한다.

• 백엔드: 업무 규칙을 처리하고 요청에 응답하며, 데이터와 외부 시스템을 다룬다.

• 데이터 저장소: 데이터베이스 등을 통해 필요한 정보를 저장하고 조회한다.

• API: 프론트엔드와 백엔드 등 서로 다른 구성 요소가 정해진 방식으로 데이터를 주고받도록 한다.

강의에서는 PHP 등 서버 사이드 스크립트의 역사, REST API의 등장, Node.js를 통한 서버 측 JavaScript 활용, SPA(Single Page Application)의 특징 등을 연결해 설명했다.

특히 바이브 코딩이 발전하더라도 소프트웨어의 구조를 이해하는 일이 사라지는 것은 아니다. AI가 코드를 만들어 주더라도 화면, 업무 로직, 데이터 저장소가 어떤 역할을 하는지 알아야 결과물을 검토하고 수정할 수 있다.

3. 오늘의 실습과 시연

T-Scan 보안 검사 도구

강의에서는 요구사항을 바탕으로 보안 검사 도구를 만드는 과정을 살펴봤다. 전사문에는 한 수강생이 Codex를 활용해 요구사항과 구현 명세를 먼저 정리하고, 설치형 프로그램 대신 터미널에서 실행할 수 있는 TUI(Text User Interface) 형태로 방향을 수정했다고 설명하는 부분이 있다.

또한 검사 결과에서 민감한 값을 마스킹해 표시하는 방식과 폴더를 지정해 검사하는 흐름을 시연했다. 결과를 한꺼번에 출력하는 대신 스트리밍 방식으로 중간 결과를 보여주는 개선 방향도 언급됐다.

다만 이 내용은 전사문상 강의 중 공유된 구현 사례이며, 내가 직접 동일한 도구를 구현하거나 테스트를 완료했다고 볼 근거는 없다.

사다리 타기 프로그램

시간이 남는 수강생을 위한 바이브 코딩 과제로 사다리 타기 프로그램도 제안됐다.

• 참가자 수 입력

• 참가자 이름 또는 번호 설정

• 결과 항목 입력

• 사다리 가로줄 생성

• 시작 버튼을 눌러 이동 경로와 결과 확인

터미널에서 동작하는 TUI 방식과 Python 기반 UI, 웹 페이지 방식 등 여러 구현 방법이 언급됐다. 강의 후반에는 실제로 만든 사다리 프로그램의 화면과 동작을 공유하며, 같은 요구사항이라도 도구와 구현 방식에 따라 결과물이 달라질 수 있음을 보여줬다.

4. 프로젝트와 협업에 관해 생각해 볼 점

오늘 강의에서는 단위 프로젝트와 최종 프로젝트를 앞두고, 팀 안에서 자신의 역할을 찾는 태도도 강조됐다.

팀 프로젝트에서는 일부 인원만 구현을 맡고 나머지는 참여하지 않는 상황을 피해야 한다. 작은 기능이라도 역할을 나누고, 각자가 맡은 부분을 구현하거나 검증하는 경험을 쌓는 것이 중요하다.

또한 업무를 지시받을 때까지 기다리기보다 프로젝트에 필요한 일을 스스로 찾아 제안하는 태도가 필요하다는 이야기도 있었다.

이는 바이브 코딩을 활용할 때도 마찬가지다. AI에게 코드를 생성해 달라고 요청하는 것에서 끝나지 않고, 무엇을 만들지 정의하고 결과를 확인하며 다음 개선점을 찾아야 한다.

5. 새롭게 연결해 볼 내용

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

• 보안: AI가 생성한 결과에 민감한 정보가 포함되지 않도록 검증한다.

• 개발 도구: 반복적인 검사 작업을 자동화하는 도구를 직접 설계한다.

• 제품 기획: 사용자의 문제를 발견하고 실제로 필요한 기능을 만든다.

• 아키텍처: 구현된 기능이 프론트엔드, 백엔드, 데이터 저장소에서 어떤 역할을 하는지 이해한다.

• 협업: 팀에서 필요한 일을 찾고 작은 단위로 나누어 함께 완성한다.

결국 AI가 코드 작성의 많은 부분을 도와주더라도, 무엇을 만들고 어떤 기준으로 검증하며 어떻게 사용자에게 전달할지는 개발자가 판단해야 한다.

6. 복습할 부분

• Fail-Open과 Fail-Closed가 실제 워크플로우에서 어떻게 다르게 동작하는지 설명하기

• 개인정보 마스킹과 민감 정보 탐지에서 오탐·미탐이 발생하는 이유 정리하기

• T-Scan의 요구사항을 기능 단위로 나누고, 커밋 전 검사 흐름을 설계해 보기

• 제품의 수요 검증과 구현, 배포, 고객 확보가 어떻게 연결되는지 정리하기

• 프론트엔드, 백엔드, API, 데이터 저장소의 역할을 구분하고 설명하기

• Node.js와 SPA가 기존 웹 애플리케이션 구조에서 어떤 변화를 가져왔는지 복습하기

7. 오늘의 회고

오늘은 AI를 활용해 기능을 만드는 방법뿐 아니라, 만든 결과물을 어떻게 검증하고 실제로 활용할 것인지까지 생각해 볼 수 있는 시간이었다.

보안 워크플로우에서는 답변을 생성하는 것만으로 충분하지 않으며, 최종 결과에 민감한 정보가 남아 있는지 확인하고 실패 상황까지 고려해야 한다. 개발 도구를 만드는 과제에서도 단순히 문자열을 검색하는 기능보다 정확한 탐지, 안전한 출력, 오탐 감소 등 실제 사용 환경에서 필요한 조건을 구체적으로 정의하는 일이 중요했다.

바이브 코딩으로 제품을 만드는 사례에서는 구현 자체가 최종 목표가 아니라는 점도 인상적인 주제였다. 제품을 완성하더라도 실제 사용자가 필요로 하지 않거나 적절한 고객에게 도달하지 못하면 의미 있는 결과로 이어지기 어렵다.

또한 웹 아키텍처의 역사를 살펴보면서 AI가 코드를 작성하는 시대에도 기존 기술의 구조와 역할을 이해하는 것이 중요하다는 점을 확인했다. 코드가 생성되는 속도가 빨라질수록 결과물을 판단하고 검증하는 기준이 필요하기 때문이다.

앞으로 단위 프로젝트와 최종 프로젝트를 진행할 때는 단순히 주어진 기능을 구현하는 데 그치지 않고, 내가 맡을 수 있는 역할을 먼저 찾고 요구사항을 구체화하는 것부터 시작해 보고 싶다. 다만 이번 수업에서 소개된 도구와 사례를 실제로 어느 수준까지 구현하고 검증했는지는 별도로 확인하면서 학습 내용을 정리할 필요가 있다.

#AI오케스트레이션 #바이브코딩 #LLM보안 #프롬프트인젝션 #개인정보마스킹 #TUI #개발자동화 #프론트엔드 #백엔드 #국비지원개발자