[Vibe Coding Playbook] 2026 금융취약점분석평가 대응 인프라 진단 스크립트 고도화

Claude와 Codex 중심으로 진행한 경험기

 

토큰 리셋을 기다리며 작성하는 포스팅..

 

Summary

LLM은 단순한 자동 코드 작성기가 아니다. 규정 준수, 운영 안정성, 기존 파이프라인 호환성을 함께 맞춰야 하는 작업에서 가장 큰 효과를 낸다.
필자는 2026년 개정 금융취약점분석평가 기준을 기존 인프라 진단 스크립트에 반영하는 과정에서 Claude(Opus 4.6)와 Codex(GPT-5.4)의 사용을 병행했다. Claude는 기준 해석, 요약, 분기 전략 수립에 강했고, Codex는 실제 코드 정합성 점검과 구현 루틴 정리에 강점을 보였다.
결국 품질 차이를 만든 것은 모델의 크기 자체보다 질문의 구조와 역할 분리였다. 무엇을 어떤 모델에 맡길지 명확히 나누고, 마지막에는 반드시 AI가 작성하고 인간이 검증하며 테스트가 증명하는 구조를 유지해야 전체 코드베이스에서도 신뢰성을 확보할 수 있다.

 

1. 들어가며

 

이제 LLM 활용은 선택이 아니라 점점 업무 표준에 가까워지고 있다. 특히 인프라 진단이나 보안 점검 스크립트처럼 범용성, 적용 범위, 규정 대응 속도가 중요한 업무에서는 생산성 차이를 빠르게 체감하게 된다.
이번 작업에서는 2026년 개정 금융취약점분석평가 항목을 기준으로 기존 진단 스크립트를 재정비하는 실험을 진행했다. 목표는 단순히 AI로 코드를 많이 생성하는 것이 아니라, 사람이 반복적으로 확인해야 하는 부담을 줄이면서도 누락과 오탐 가능성을 최소화하는 것이었다.

여기서 중요한 점은 AI에게 막연히 “수정해 달라”고 요청하는 것이 아니라, 무엇을 왜 수정해야 하는지를 구조적으로 전달하는 것이다. 결국 이 작업의 핵심은 모델이 잘하는 정보 정리와 맥락 연결은 AI에 맡기고, 변경 책임과 최종 판단은 사람이 가져가는 구조를 만드는 데 있었다.

 

"현재 프로젝트 경로 실행 구조 및 목 검토 요청"

 

실제 초기 탐색 단계에서는 첨부한 이미지처럼 기준서, 스크립트, 파이프라인 계약을 한 번에 섞지 않고 분리해서 병렬로 검토했다. 예를 들어 금취분평 기준서(.xlsx)의 헤더 및 항목 추출, 각 인프라 시스템별 진단 스크립트 구조 분석, 테스트 기준 정합성 확인을 각각 별도의 서브 에이전트가 담당하도록 구성했다.
이 방식은 “한 번에 다 처리하려다 전체 흐름의 갈피를 잃는 문제”를 줄여준다. 특히 금융 점검처럼 항목 하나의 누락이 치명적인 영역에서는 이런 구조화가 결과의 일관성을 크게 좌우한다.

 

2. 질문에 구체적인 맥락이 필요한 이유

 

LLM은 의도 추론은 잘하지만, 작성자의 목적이나 비즈니스 제약까지 자동으로 완벽하게 이해하지는 못한다.
따라서 “이 스크립트를 고쳐줘” 같은 요청보다는 목표, 입력 파일, 출력 형식, 제약 조건, 검증 기준을 명확하게 지정해야 한다. 내가 지금 무엇을 하려는지 한 문장으로 요약해 주는 것만으로도 모델의 판단 범위는 훨씬 안정된다.

예를 들어 다음과 같이 선을 분명히 긋는 방식이 효과적이다.

금융취약점분석평가 2026 개정 기준에 따라 dbms/ 경로의 스크립트만 수정, 기존 파서 호환 유지, output schema 변화 없음

 

이런 규칙이 중요한 이유는 보안 스크립트의 특성 때문이다. 작은 오해 하나가 오탐, 누락, 혹은 계약 파손으로 이어질 수 있다. 특히 이미 운영 중인 파이프라인에 연결된 스크립트는 “기능 추가”보다 “호환성 유지”가 더 중요할 때가 많다.

실제로 사용했던 프롬프트 구조는 아래와 비슷했다.

역할: 금융 인프라 진단 스크립트 리뷰어
목표: 2026 금융취약점분석평가 개정항목 반영 기준으로 scripts/*과 파싱 스크립트(.py) 수정안 제안
입력: scripts/ 디렉토리 + 금취분평기준.xlsx + 현재 테스트 결과
출력: ① 변경 대상 목록 ② 영향도 높은 리스크 항목 ③ diff 제안 ④ 재실행 명령 ⑤ 롤백 포인트
제약: 기존 출력 스키마 호환 유지, 진단 항목명 절대 변경 금지

 

반복 작업에서는 이런 컨텍스트를 템플릿으로 고정해 두면 실수가 크게 줄어든다.

 

# 컨텍스트 템플릿 활용
cat > .tmp/context_prompt.txt <<'EOF'
목표:
입력:
출력:
제약:
검증:
EOF

 

첫 번째 이미지에서도 비슷한 방식으로 작업 단위를 분해하고, 병렬 위임 전에 기준을 먼저 고정하는 흐름을 확인할 수 있다.
실무에서 LLM 품질은 종종 모델보다 초기 문맥 설계에서 먼저 갈린다.

 

3. 모델 선택은 성능보다 실패 기회비용 기준으로 나눈다.

 

모델을 무조건 큰 것으로 통일하는 것이 항상 효율적인 것은 아니다.
작은 스크립트 정리, 구조 정렬, 반복 비교 같은 작업은 오히려 경량 모델이나 단일 추론 단계가 더 빠르고 비용 효율적일 수 있다. 반대로 규정 문서, 기존 소스, 테스트 리포트를 동시에 해석해야 하는 경우에는 컨텍스트 정밀도가 중요해지므로 큰 모델이 유리하다.

핵심은 작업 종류가 아니라 작업 목표와 실패 비용으로 모델을 구분하는 것이다.
필자의 경우 Claude는 기준 판단과 요약 중심, Codex는 구현 제안과 코드 정합성 검토 중심으로 나눠 쓰는 구조가 가장 안정적이었다.

 

권장 분할
- 큰 모델: 규정 대응 항목 매핑, 전체 변경 전략 수립, 충돌 가능성 분석
- 경량 모델: 파일 단위 정규화, 반복 규칙 추출, 테스트 케이스 보강
- 공통: 최종 단계에서는 항상 동일한 검증 커맨드로 통합

 

이 구조의 장점은 명확하다. 큰 모델 하나에 모든 책임을 몰아주면 비용과 응답 시간이 커지고, 반대로 경량 모델만 사용하면 장기 맥락 연결이 쉽게 끊긴다.
모델 간 역할을 나누고, 교차 검토 지점을 만들면 실제 리뷰 시간도 줄고 결과의 안정성도 높아진다.

다만 여기서 한 가지 짚고 넘어가야 한다. “큰 모델이 무조건 더 정확하다”는 생각은 실무에서 종종 틀릴 수 있다.
규정 해석은 잘하더라도, 구현 단계에서는 기존 코드 스타일이나 예외 처리 흐름을 과도하게 재구성하려는 경향이 있을 수 있다. 이런 경우에는 오히려 범위를 좁힌 구현 모델이 더 예측 가능하게 동작한다. 그 점을 분리하지 않으면 AI를 썼는데도 변경량만 커지고 품질이 낮아질 수 있다.

 

4. CLAUDE.md 가 중요한 이유

 

CLAUDE.md는 단순한 메모 파일이 아니다.
Claude 세션이 시작될 때 이 파일을 읽고 프로젝트 문맥을 바탕으로 응답하기 때문에, 이 파일이 부실하면 규칙 누락이 쉽게 발생한다. 특히 규정, 권한, 테스트 시나리오가 얽혀 있는 보안 프로젝트에서는 정확한 계약 문서 자체가 곧 성능이다.

실무적으로는 최소한 다음 요소를 넣어 두는 것이 좋다.

• 기술 스택
• 실행 진입점
• 테스트 명령
• 보안 민감 항목
• 예외 처리 원칙
• 출력 포맷
• 검토가 반드시 필요한 경로

 

# CLAUDE.md 예시
- 기술 스택: Python 3.11, Bash, Git
- 실행 진입점: scripts/run_audit.py
- 테스트: pytest tests/ + bash -n scripts/**/*.sh

 

이 파일이 있으면 멀티세션 환경에서도 공통 기준이 유지된다. 새로 시작한 세션도 이전과 비슷한 판단을 하게 되고, 매번 같은 설명을 반복하는 비용도 줄어든다.
스크린샷의 흐름 역시 먼저 AGENTS, 기준 파일, 파이프라인을 이해한 뒤 계획을 세우고 각 역할을 분산시키는 구조였다. 결국 잘 정리된 프로젝트 문맥이 있어야 세션이 바뀌어도 판단이 흔들리지 않는다.

 

4.1 CLAUDE.md 작성이 막힐 때에는 LLM에게 초안을 맡기자

처음부터 완벽한 CLAUDE.md를 직접 작성하려고 하면 생각보다 시간이 오래 걸린다. 이럴 때는 초안 생성 자체를 LLM에 맡기는 편이 훨씬 효율적이다.
필자는 종종 아래 문장을 거의 그대로 사용한다.

 

이 프로젝트를 분석하고 CLAUDE.md를 작성해줘. 기술 스택, 빌드 명령어, 코딩 컨벤션, 프로젝트 구조, 테스트 방법을 포함해.

 

이렇게 요청하면 모델이 프로젝트 구조를 바탕으로 기본 스켈레톤(뼈대)을 만들어준다. 이후 사람은 거기에 보안 정책, 예외 처리 원칙, 민감 경로 같은 디테일만 보강하면 된다.
특히 보안 점검용 레포는 파일 구조와 실행 방식이 자주 바뀌지 않기 때문에, 초안 이후 몇 차례 수정만으로도 실사용 가능한 수준까지 빠르게 정리된다.

예시 템플릿은 아래와 같다.

 

CLAUDE.md 작성 요청 템플릿
- 역할: 시니어 보안 엔지니어
- 산출물 형식: markdown
- 필수 항목: 기술 스택 / 빌드 / 테스트 / 코딩 규약 / 예외 / 보안 정책
- 금지: 진단 항목, 항목명, 진단 기준 변경
- 산출: 프로젝트 루트에 바로 배치 가능한 버전

스크립트 수정내용에 대한 검증 에이전트 동작 시 다음 내용을 포함하도록 추가.
 -수정 범위 위반 차단
   > 스크립트 파일명 변경 여부(금지)
   > 새 의존성 추가 여부(금지)
   > 실행 진입점 변경 여부(금지)
   
 - analyze 호환성 보장
   > CHK_N / SET CHK_N 포맷 유지
   > 코드 중복 여부
   > 항목명 중복/누락 여부
   > 자산군별 항목 수 이상치
 - Local Runtime Validation
   > 쉘 문법 검사
   > 배치 문법 검사
   > 샘플 입력 기반 실행
 - Analyze/Report Compatibility
   > {입력경로} 입력 생성
   > {분석 스크립트} 정상 실행 성공
   > {분석 스크립트 결과 폴더 내 결과 파일} 생성 확인

중요한 것은 “한 번에 완성”이 아니라 초안 → 검토 → 보강의 짧은 순환을 만드는 것이다. 구현이 필요한 프로젝트에서는 이 한 번의 순환만으로도 체감 품질이 크게 올라간다.

 

5. 바이브 코딩 작업 플로우

 

바이브 코딩을 할 때에는 Explore → Plan → Implement → Commit 루프를 의도적으로 강제하고 있다.
이 네 단계는 단순한 취향이 아니라, 실패 모드를 통제하기 위한 안전장치에 가깝다.

• Explore: 기준 문서, 기존 코드, 테스트 계약을 먼저 확인한다.
• Plan: 변경 범위를 자산군 또는 디렉터리 단위로 분할한다.
• Implement: 책임 범위를 좁혀 구현한다.
• Commit: 누가, 왜, 무엇을 바꿨는지 추적 가능하게 남긴다.

Explore 단계에서 기준과 계약을 먼저 고정하면 구현이 흔들리지 않는다. Plan 단계에서 변경 범위를 자산군별로 잘라두면 병합 충돌과 중복 수정이 줄어든다. Implement 단계에서는 한 번에 너무 넓은 범위를 건드리지 않고, Commit 단계에서는 변경 이유를 명시적으로 기록한다.

 

계획 수립 후 병렬 에이전트 수행 과정

 

이미지처럼 “1차 구현 구간(UNIX/Windows/DBMS/미들웨어)”을 분리하고, 각 파트의 작업 권한을 나눠 병렬 실행한 뒤 마지막에 통합하는 방식이 특히 효과적이었다.
에이전트 생성 실패 같은 이벤트도 로그로 남는데, 병렬 처리 중 일부가 실패하더라도 전체 영향 범위를 좁혀 놓았기 때문에 복구 지점이 명확해진다.

 

6. 멀티세션 워크플로우는 역할과 수정 경계를 명확히 한다.

보안 점검 스크립트처럼 맥락이 긴 작업을 단일 세션 하나로 끝내려 하면 컨텍스트 한계와 추론 편차가 쉽게 나타난다.
반면 멀티세션은 역할만 제대로 고정하면 오히려 품질을 높여준다.

예를 들어 다음처럼 세션을 나눌 수 있다.

• A 세션: 규정 매핑
• B 세션: 코드 구형
• C 세션: 구현 검증 및 테스트

이 방식의 핵심은 역할 자체보다 누가 어떤 파일을 수정할 수 있는지를 먼저 명시하는 것이다.
공유 파일 경계가 모호하면 같은 파일을 서로 다른 방식으로 수정하거나, 테스트는 통과했지만 논리적으로 충돌하는 변경이 누락되는 문제가 발생한다.

실제로는 다음처럼 공유 아티팩트를 정리해 두면 좋다.

 

멀티세션 역할 정의 예시
- Session A (Analyze): 기준 파일 해석 + 항목 매핑
- Session B (Implement): 대상 파일 수정(파티션 단위)
- Session C (Verify): scope guard + contract check + smoke test
- 공유 아티팩트: shared_scope.json, changed_files.txt, verify_report.md

 

# 공유 스키마 예시
state = {
  "scope": ["server_unix", "server_windows", "dbms"],
  "allowed_paths": {
    "A": ["docs/", "ruleset/"],
    "B": ["scripts/script/", "scripts/_common/"],
    "C": ["tests/", "tools/"]
  },
  "handoff": ["diff_report.md", "verify_report.md"]
}

 

최종 검증 단계에서는 자산군별 건수, 변경 파일 범위, 컨트랙트 체크, smoke test 결과를 한 번에 볼 수 있어야 신뢰 가능한 판단이 가능하다.
이 구조는 한 번 정형화해 두면 다음 개정 주기에도 재사용할 수 있다. 특히 실무에서 더 위험한 것은 오탐보다도 검증 갭이다. 코드가 커밋되었는지보다, 테스트가 어느 범위를 실제로 커버했는지가 훨씬 중요하다.

 

멀티 세션 오케스트레이션

 

7. 마치며

 

LLM을 도입했다고 해서 코드 수준이 자동으로 올라가지는 않는다. 시행착오가 많이 필요하다. 필자도 이것저것 시도해보면서 수도 없이 롤백과 깃 커밋 revert를 거쳤다. 
문서화, 계약화, 검증 루틴이 잘 잡혀 있을수록 AI 도입 효과가 커진다.

이번 작업에서 가장 중요했던 것은 “큰 모델의 능력”이 아니라, 이미지와 실행 로그를 포함한 작업 흐름 자체를 고정한 것이었다. 탐색, 계획, 실행, 검증이 분리된 구조 덕분에 중간 실패가 발생해도 회복이 가능했고, 변경 범위도 투명하게 추적할 수 있었다.
그래서 팀에 바로 적용하려면 거창하게 시작할 필요는 없지만, 최소한 shared_context + CLAUDE.md + 테스트 게이트는 기본값으로 고정해 두는 편이 좋다.

아래의 최종 결과 예시처럼, 자산군별 항목 수, 체크 결과, 테스트 pass/fail 상태가 한 화면에 남아야 운영자가 빠르게 의사결정할 수 있다.
실무에서는 결국 코드 그 자체보다 어디까지 검증되었는가가 더 중요하다. 그런 의미에서 이번 작업이 의미가 있었다고 생각한다.

 

 

 

8. 잊지말아야할 원칙

모든 코드는 AI가 제안할 수는 있어도, 최종 판단 책임까지 대신할 수는 없다.
특히 중요한 판단 로직은 반드시 사람이 직접 리뷰를 거쳐 승인해야 한다. 필자는 항상 별도의 검토 단계를 둔다. 기능적으로 동작하더라도 정책 위반 가능성, 예외 처리 누락, 로그 오염 가능성은 추가적인 인적 검토가 필요하기 때문이다.

이 원칙이 없는 팀은 초반에는 빠르게 움직이는 것처럼 보여도, 결국 리뷰나 수동검증 시점에서 다시 처음으로 되돌아가는 경우가 많다.
속도를 높이고 싶다면 오히려 검증 단계를 더 명확하게 분리해야 한다. 그것이 장기적으로 가장 빠른 방법이다.

 

9. References

작업을 하면서 참고한 좋은 아티클들이다.

https://claudeguide-dv5ktqnq.manus.space/
https://code.claude.com/docs/en/best-practices

Best Practices for Claude Code - Claude Code Docs

 

Claude Code 마스터 가이드 2026 — 실전 꿀팁 & 워크플로우 완전 정복