Vibe Coding / Agentic Flow 면접 문제집

참고: 이 문제집은 유일한 정답이 없습니다. 본문에 제시된 “참고 답안”은 사고를 돕기 위한 것으로, 독자가 자신의 판단 프레임을 세우는 데 활용하도록 돕는 용도로 사용됩니다.

적용 대상: 매일 Claude Code, Codex 등 agentic CLI 도구를 사용하는 개발자, 특히 AI 코딩을 “사람-컴퓨터 대화”에서 “공학적 워크플로우”로 업그레이드하려는 사용자.

목차

1. 배경 지식 편 2. 세부 정리 편 3. 워크플로우 편 4. 시스템 설계 편: 열린 성찰 5. 개념 철학 편: 열린 성찰 6. 부록: 추천 학습 경로 7. 참고 링크

1. 배경 지식 편

Q1. /command는 무엇인가요? skill과의 차이는 무엇인가요? 언제 command를 쓰고 언제 skill을 써야 하나요?

참고 답안

/command는 Claude Code의 초기 확장 메커니즘입니다. 사용자는 .claude/commands/ 아래에 .md 파일을 두고, 대화에서 /command-name을 입력해 실행할 수 있습니다. 본질적으로 이는 “사용자가 명시적으로 호출하는 한 덩어리의 prompt”입니다.

Skill은 차세대 확장 메커니즘으로, 일반적으로 .claude/skills/<name>/SKILL.md, ~/.claude/skills/, 또는 플러그인에 배치됩니다. command와의 핵심 차이는 다음과 같습니다.

실무에서는 거의 모든 신규 시나리오에서 skill을 우선 고려하는 것이 좋습니다. 특히 모델이 적절한 시점에 자동으로 규칙 집합을 활성화해야 하거나, 스크립트·예시 파일·템플릿이 함께 필요할 때 skill이 더 적합합니다.

command는 여전히 소수의 단순 시나리오에서 사용할 수 있습니다. 예컨대 팀 유산 자산이거나 사용자가 명시적으로 반드시 실행해야 하는 한 줄 프롬프트 래퍼가 필요한 경우입니다. 하지만 새 프로젝트에서는 command에 대한 과도한 의존은 권장되지 않습니다.

Q2. Agent란 무엇인가요? 어떤 경우에 agent를 사용하고 어떤 경우에 skill을 사용하나요?

참고 답안

Agent는 특히 Sub-agent의 경우, 독립적인 system prompt, 독립 컨텍스트 윈도우, 독립적인 tool allowlist를 가진 “작은 Claude”로 이해할 수 있습니다. Claude Code에서 sub-agent는 보통 .claude/agents/<name>.md로 정의되며, 주 대화에서 작업이 할당됩니다. Sub-agent는 작업 완료 후 요약만 반환하고, 중간의 다량 검색/읽기/로그 출력은 주 컨텍스트를 오염시키지 않습니다.

반면 Skill은 일련의 지시 또는 규범입니다. 별도의 새 컨텍스트를 만들지 않고 현재 대화에서 Claude가 다음에 무엇을 해야 하는지 안내합니다.

간단한 판단 기준은 다음과 같습니다.

• Claude에게 “커밋 전에는 lint와 테스트를 먼저 실행” 같은 작업 규칙을 가르치고 싶다면 skill을 사용하세요.
• 수십 개의 파일을 읽거나, 많은 grep 실행, 로그 분석 등 대량 도구 출력이 발생할 것으로 보이면 agent를 사용하세요.
• 이미 알려진 단일 파일을 읽는 작업이라면 주 대화에서 바로 읽기만 하면 되고, 굳이 agent를 열 필요가 없습니다.
• 전체 추론 과정이 주 대화에 남아야 하는 작업이라면 sub-agent로 보내지 말아야 합니다.

Q3. Sub-agent란 무엇인가요? Sub-agent끼리 서로 소통할 수 있나요?

참고 답안

Sub-agent의 핵심 특성은 독립 컨텍스트, 독립 도구 세트, 그리고 주 대화로 summary만 반환한다는 점입니다.

기본적으로 sub-agent끼리는 직접 소통할 수 없습니다. 그들의 통신 모델은 스타 토폴로지처럼, 주 대화가 중앙 노드이고 모든 sub-agent가 주 대화와만 통신합니다. 즉, A agent의 발견을 B agent에 전달하려면 보통 주 대화가 전달해 줍니다.

이 설계의 장점은 다음과 같습니다.

• 정보가 주 대화로 집약되어 사용자 감사가 용이함
• agent 간의 통제되지 않은 순환 대화 방지
• 컨텍스트 및 도구 호출 비용 통제

실험적 Agent Teams 모델에서는 같은 계층의 agent 간 메시지 통신 기능이 도입될 수 있지만, 그때는 이미 훨씬 더 복잡한 협업 모델입니다.

Q4. Agent Team과 Sub-agent의 가장 큰 차이점은 무엇인가요?

참고 답안

Sub-agent는 “한 일거리 하나를 맡겨서 보고받는 임시직”에 가깝습니다. 보통 일회성으로, 주 대화가 작업을 시작해 실행 후 summary를 받습니다.

Agent Team은 “장기 협업 소규모 팀”에 가깝습니다. 각 teammate는 독립 역할과 독립 컨텍스트를 가질 수 있으며, 메시지 메커니즘으로 서로 소통할 수도 있습니다.

현실적으로 대부분의 일상 개발 작업은 sub-agent만으로 충분합니다. Agent Team은 다중 agent 협업 연구 방향에 더 가깝고, 복잡한 프로젝트에 적합하지만 디버깅 난이도도 높습니다.

Q5. MCP란 무엇인가요? API 인터페이스와의 차이점은?

참고 답안

MCP(Model Context Protocol)는 외부 도구, 자원, prompt를 LLM 클라이언트에 표준 형식으로 노출하는 프로토콜입니다. MCP 서버는 어떤 tool, resource, prompt를 제공하는지 선언할 수 있으며, 클라이언트가 연결하면 자동으로 탐색해 호출할 수 있습니다.

순수 API와 MCP의 차이는 다음처럼 정리할 수 있습니다.

비유하자면 API는 “가게마다 모양이 다른 전원 플러그”이고, MCP는 “LLM 도구 호출용 USB-C”에 가깝습니다.

핵심 가치는 데이터 전달만이 아니라 도구의 “자기 서술 능력”입니다. 모델이 도구 이름·파라미터·쓰기 가능 여부·확인 필요성을 알 수 있어 언제 어떻게 호출할지 추론할 수 있습니다.

Q6. Sub-agent는 자기 자신만의 sub-agent를 더 생성할 수 있나요?

참고 답안

일반적으로 불가능합니다. Sub-agent는 자기 자신의 sub-agent를 다시 시작해서는 안 됩니다.

이 설계는 세 가지 문제를 피하기 위한 것입니다.

1. 무한 재귀: agent가 무한히 하위 agent를 만들 수 있다면 호출 트리가 곧 제어 불능이 됩니다. 2. 감사 불가능성: 중첩이 너무 깊어지면 주 대화에서 어느 레벨에서 무엇이 일어났는지 알기 어려워집니다. 3. 컨텍스트 및 비용 폭증: 계층마다 독립 컨텍스트가 생기면 비용과 지연이 급격히 증가합니다.

정말로 “중첩 위임”이 필요하다면 더 나은 방법은 다음과 같습니다.

• 주 대화가 평면적으로 여러 sub-agent를 배분
• sub-agent 내부에서 skill로 단계를 구성
• 극도로 복잡한 작업은 Agent Team 고려(명확한 경계와 예산 설정 필요)

2. 세부 정리 편

Q7. CLAUDE.md / AGENTS.md는 무엇인가요? 로드 순서와 우선순위는?

참고 답안

CLAUDE.md와 AGENTS.md는 프로젝트/사용자 수준의 “영구 prompt 주입”으로 볼 수 있습니다. 코드 스타일, 테스트 명령, 수정 금지 파일, 커밋 규칙 등 매번 agent가 기동할 때 반드시 알아야 할 규칙을 선언합니다.

일반적인 계층은 다음과 같습니다.

이 파일을 프로젝트 소개 글처럼 쓰지 말고, agent가 반드시 지켜야 할 하드 규칙으로 써야 합니다. 예:

• 코드 수정 전 관련 테스트 먼저 확인
• .env와 키 파일은 수정하지 않음
• 완료 후 반드시 npm run typecheck 실행
• 불필요한 의존성 추가 금지

실무 경험상 각 파일은 가능하면 200줄 이내로 유지하는 편이 좋습니다. 너무 길면 독립 문서로 분리하고 참조로 구성하세요.

Q8. Hooks란 무엇인가요? 자주 쓰는 hook 사례를 열거해 주세요.

참고 답안

Hook은 Claude Code나 유사한 agentic 도구의 라이프사이클 이벤트에 등록되는 결정론적 콜백입니다. 모델이 “기억해서 하겠다”는 방식이 아니라, 런타임이 강제 실행합니다.

일반적인 이벤트는 다음과 같습니다.

• 도구 호출 전: 예를 들어 위험한 명령 차단
• 도구 호출 후: 예를 들어 파일 변경 후 자동 포맷
• Session 시작 시: 예를 들어 현재 git 상태 주입
• 종료 시: 예를 들어 데스크톱 알림 발송

일반적인 활용 시나리오는 다음과 같습니다.

Hook의 가치는 “결정론성”에 있습니다. 프롬프트는 모델이 무시할 수 있지만, hook은 도구 계층의 제약입니다.

Q9. Permission Mode에는 어떤 종류가 있고 각각 어떤 시나리오에 적합하나요?

참고 답안

Permission Mode는 agent가 파일 읽기/쓰기, 명령 실행, 외부 도구 호출 시 사용자 확인이 필요한지를 결정합니다.

원칙적으로 운영 환경에 가까울수록 권한은 보수적으로, 실험용/격리된 샌드박스에 가까울수록 개방적으로 설정합니다.

Q10. /compact 시 어떤 컨텍스트가 유지되고, 어떤 것이 사라지나요?

참고 답안

/compact는 대화 컨텍스트를 압축하는 것입니다. 일부 우선순위 정보는 유지되지만, 과거 도구 호출의 전체 상세는 유지되지 않습니다.

일반적으로 유지되거나 다시 주입되는 항목:

• System prompt
• 프로젝트 규칙 파일(예: CLAUDE.md)
• 사용자 또는 프로젝트 메모리
• 대화 요약
• 일부 고우선순위 skill 설명

사라지기 쉬운 항목:

• 과거 도구 호출의 전체 출력
• 쓰기 없이 읽기만 했던 디테일(영구 파일에 남지 않음)
• 대화 안에서만 존재한 임시 합의
• 일부 on-demand로 로드되는 도구의 전체 스키마

실무에서는 장기 제약을 채팅창에만 두지 말아야 합니다. 중요한 규칙은 CLAUDE.md, AGENTS.md, memory, PROGRESS.md, 또는 프로젝트 문서에 기록하세요.

Q11. Plugin과 Skill의 관계는 무엇인가요?

참고 답안

Skill은 능력 단위입니다. Plugin은 패키지로 묶어 배포되는 확장 번들입니다.

하나의 plugin은 다음을 포함할 수 있습니다.

• 여러 skills
• sub-agent 정의
• hooks
• MCP server
• LSP server
• 바이너리 도구
• 기본 settings

이 관계는 부품이 skill이고, 도구함이 plugin입니다. 팀 내부에 안정적인 AI 코딩 프로세스가 있다면 그것을 plugin으로 묶어 새 구성원이 원클릭 설치할 수 있게 할 수 있습니다.

Q12. ToolSearch / Deferred Tools은 무엇인가요? 왜 이런 설계인가요?

참고 답안

Deferred Tools의 핵심은 “기동 시 모든 도구 스키마를 컨텍스트에 통째로 넣지 않는다”는 점입니다. 먼저 도구 이름만 모델에 알린 뒤, 실제로 필요할 때 ToolSearch 또는 유사 메커니즘으로 상세 파라미터 스키마를 로드합니다.

이 설계 이유는 다음과 같습니다.

1. 토큰 절약: 대형 MCP server는 수십에서 백여 개의 도구를 가질 수 있어 전체 스키마만으로도 컨텍스트를 크게 점유합니다. 2. 주의력 잡음 감소: 관련 없는 도구가 계속 프롬프트에 떠 있으면 모델 판단을 방해합니다. 3. 필요 시 로딩: 진짜 필요할 때만 상세 설명을 로드.

대가로 처음 사용하는 도구에서 한 번의 추가 round trip이 발생할 수 있지만, 전반적으로는 더 효율적입니다.

3. 워크플로우 편

Q13. 중간 복잡도 신규 기능 작업을 받으면 agentic 도구로 어떻게 분해해야 하나요?

참고 답안

전형적인 흐름은 다음과 같습니다.

1. 먼저 plan mode로 진입해 읽기만 하며 코드를 탐색, 즉시 수정하지 않음. 2. Explore sub-agent를 병렬로 띄워 관련 파일, 진입점, 데이터 흐름, 테스트 위치 탐색. 3. 주 대화 또는 Plan sub-agent가 TDD 스타일 계획 산출: 수용 기준, 테스트 케이스, 최소 구현, 검증 전략. 4. 두 번째 모델이나 review agent로 교차 검토하여 맹점을 보완. 5. 중요 설계 분기점에서는 사용자에게 질문, 임의의 고영향 변경은 피함. 6. plan mode를 종료하고 편집 모드 진입. 7. 먼저 테스트 작성 또는 갱신 후 구현. 8. 구현 후 관련 테스트, typecheck, lint 실행. 9. 마지막으로 review skill 또는 code-review agent로 자가 점검.

이 흐름의 핵심은 “많은 agent를 켜서 고급스러워 보이는 것”이 아니라 탐색/설계/구현/검증/회고를 분리하는 것입니다.

Q14. 언제 sub-agent를 열고, 언제 열지 말아야 하나요?

참고 답안

열어야 하는 경우:

• 조사를 위해 10개 이상의 파일을 읽어야 함
• 대량 grep, find, 로그 분석 필요
• 독립 코드 리뷰나 보안 리뷰 수행
• 여러 무관한 하위 작업을 병렬 처리
• 도구 출력이 길어 주 컨텍스트를 오염시키기 쉬움

열지 말아야 하는 경우:

• 도구 호출이 1–3회면 충분
• 이미 알고 있는 경로를 하나 읽는 작업
• 사용자 확인이 잦은 작업
• 추론 전체 과정을 주 대화에 남겨야 하는 경우

한마디로: sub-agent는 “무거운 검색/무거운 읽기/무거운 로그” 작업에 적합하고, “짧고 빠른” 작업에는 부적합합니다.

Q15. 주 대화 컨텍스트 오염을 어떻게 막나요?

참고 답안

여러 방식으로 조절할 수 있습니다.

• 대량 읽기/조사는 Explore sub-agent에 맡겨 summary만 받음
• 긴 출력은 head, tail, grep으로 축약, 수천 줄 로그를 그대로 대화에 넣지 않음
• 반복적인 절차는 rule를 skill로 패키징, 매번 규칙을 길게 재전송하지 않음
• 단계 완료 시점마다 /compact 수행
• 장기 핵심 정보는 CLAUDE.md, AGENTS.md, memory, PROGRESS.md에 기록
• 같은 파일을 반복해서 읽지 않게 함; 파일 상태는 diff, 테스트, 버전관리로 확인

원칙은 단순합니다. 컨텍스트는 많을수록 좋은 게 아니라 신호 대 잡음 비율이 높을수록 좋습니다.

Q16. 코드에 버그가 났을 때 agentic 도구로 어떻게 디버깅하나요?

참고 답안

안전한 흐름은 다음과 같습니다.

1. 즉시 수정에 들어가지 말고 먼저 버그를 재현 2. 안정적으로 실패하는 최소 테스트 또는 최소 재현 케이스 작성 3. 테스트가 실제로 실패함을 확인해 문제 이해를 검증 4. Explore로 버그 발생 경로의 관련 파일 식별 5. 가설을 세운 뒤 추측 보완식 패치가 아니라 하나씩 검증 6. 수정 후 관련 테스트 실행 7. 마지막에 전체 또는 핵심 검증 명령 실행 8. 동일 컨텍스트에서 agent가 여러 번 실패한다면, 컨텍스트를 초기화하고 다른 관점으로 접근하거나 다른 모델에 독립 진단 요청

agent 디버깅에서 가장 위험한 것은 “추측하며 계속 수정”입니다. 재현 가능한 케이스가 없으면 모델이 코드를 점점 더 망칠 가능성이 높습니다.

Q17. 다인 협업 저장소에서 agentic 워크플로우를 팀화하려면?

참고 답안

팀화의 핵심은 개인 노하우를 저장소 자산으로 전환하는 것입니다.

공유 레이어:

• 저장소 루트 CLAUDE.md / AGENTS.md: 팀 하드 규칙
• .claude/skills/: 공유 워크플로우
• .claude/agents/: 공유 sub-agent
• .claude/settings.json: 공유 permission, hooks, 도구 allowlist
• PR 템플릿: AI 참여의 핵심 결정 및 검증 명령 명시

개인 레이어:

• CLAUDE.local.md: 개인 선호도(보통 커밋하지 않음)
• .claude/settings.local.json: 개인 권한 오버라이드

더 나아가 팀 공통 기능을 plugin으로 패키징하면 설치, 업그레이드, 유지보수를 통일할 수 있습니다.

4. 시스템 설계 편: 열린 성찰

아래 질문에는 정답이 없습니다. 핵심은 선택 프레임과 리스크 인식을 훈련하는 것입니다.

Q18. agentic 로우코드 플랫폼을 설계한다면 어떤 원칙을 우선 고려해야 하나요?

토론 방향

먼저 source of truth를 정해야 합니다. 결국 최종 기준이 agent가 생성한 코드인지, 아니면 로우코드 DSL인지입니다. 양방향 동기화는 이상적으로 보이지만 실제로는 엔지니어링 지옥으로 가기 쉽습니다.

또한 다음을 고민해야 합니다.

• 역전 가능성 및 버전 관리: agent가 한 번에 50개 컴포넌트를 변경해도 diff, revert, review가 가능해야 함
• 샌드박스와 권한 단계화: 플랫폼 사용자 agent가 DB에 직접 접근하지 못하고 권한 게이트웨이를 통과해야 함
• 컨텍스트 공급: 비즈니스 지식은 사용자 규칙으로 넣을지, 기존 문서를 자동 추출해 반영할지
• 실패 가시성: agent가 외부 API나 MCP 호출 실패 시 재생 가능해야 함
• 중요 결정 확인: 사용자의 판단을 대체하지 말고, 고영향 결정은 반드시 명시적 확인
• 비용 가시성: 각 작업의 token, API 호출, 지연이 모두 확인 가능해야 함

좋은 agentic 로우코드 플랫폼은 “마법 버튼”이 아니라, 감사 가능하고 롤백 가능하며 조합 가능한 공학 시스템입니다.

Q19. 기업 내부 MCP 게이트웨이를 설계할 때 권한, 감사, 트래픽 제한은 어떻게 할까요?

토론 방향

엔터프라이즈급 MCP 게이트웨이는 최소 다음 문제를 다뤄야 합니다.

• 권한: 역할별로 다른 도구 노출. 읽기 전용 역할은 delete_* 스키마를 보지 못해야 함
• 감사: 매 tool call마다 user, agent_id, 파라미터, 응답 크기, 소요 시간, 결과 상태 기록
• 트래픽 제한: 동일 사용자/동일 agent의 QPS, 동시성, 일일 호출량 제한
• 데이터 마스킹: agent에 반환되기 전에 PII, 키, 내부 민감 필드 마스킹
• 폴백 전략: 백엔드 장애 시 무한 대기 대신 구조화된 에러 반환
• 버전 관리: tool 스키마 변경 시 버전 관리로 구 버전 클라이언트 호환성 확보
• 테넌트 격리: 팀/프로젝트별 도구 및 데이터 분리

MCP 게이트웨이의 핵심은 “더 많은 도구 연결”이 아니라 “모델이 도구를 안전하게 쓰게 하는 것”입니다.

Q20. 다중 agent 협업 모델은 스타형이 좋을까요, 메시형이 좋을까요? 왜요?

토론 방향

스타형 구조는 명확하고 통제 쉬우며 감사가 쉽습니다. 주 대화가 중심이고 모든 sub-agent가 그곳으로 보고합니다. 단점은 주 대화 병목과 병렬도 한계입니다.

메시형 구조는 실제 팀과 더 유사해 여러 agent가 서로 소통해 병렬성이 높아질 수 있습니다. 하지만 문제가 분명합니다.

• agent 간 순환 대화 가능
• 컨텍스트 폭발
• 책임 경계 불명확
• 디버깅 난도 급상승

현실적으로 대부분의 작업은 스타형으로 충분합니다. 복잡한 다역할 과제에서만 메시형 협업을 시도할 가치가 있으며, 그 경우 메시지 예산, 스레드 한도, 대화 그래프 시각화, 강한 감사 메커니즘이 필수입니다.

한 단계 더 깊은 질문은 이것입니다. 다중 agent 협업의 ROI가 “더 강한 단일 agent”를 쓰는 것보다 정말 높은가? 모델 성능이 계속 증가한다면, 다중 편성은 특정 복잡한 경우에서만 안정적 가치를 가질 수 있습니다.

Q21. AI 보안 review agent를 설계할 때 어떤 함정이 있나요?

토론 방향

보안 review agent는 diff만 보아서는 안 됩니다. 많은 보안 이슈는 호출 체인과 컨텍스트에서 나오며, 현재 변경된 몇 줄 안에만 존재하지 않습니다.

또한 피해야 할 것들:

• 테스트 통과 맹신: 커버되지 않는 지점이 오히려 취약점 다발지인 경우가 많음
• 공격 명령 실행: review 단계는 최대한 읽기 전용으로 두어 review agent 자체가 공격면이 되지 않게 함
• 오경보 0% 추구: 보안 리뷰는 오탐을 합리적 범위로 허용하더라도 고위험 누락을 피하는 것이 우선
• 우선순위 부재: P0/P1/P2 등급을 구분해 사람이 집중할 수 있게 해야 함
• 설명 불가: “unsafe”만 말하지 말고 왜 위험한지, 영향 범위와 수정 방향을 제시해야 함

더 안정적인 방식은 모델 하나의 review 후 다른 모델로 cross-check하고, 최종 판단은 사람이 하는 것입니다.

Q22. 장기 메모리 메커니즘을 설계한다면 무엇을 기억하고 무엇을 안 할지 어떻게 정하나요?

토론 방향

기억해야 할 항목:

• 사용자가 반복해 교정한 코드 스타일
• 프로젝트 하드 제약
• 자주 쓰는 명령
• 장기적으로 유효한 엔지니어링 정보(포트, 테스트 진입점, 문서 위치 등)

기억하면 안 되는 항목:

• 일회성 임시 대화
• 민감 데이터가 포함된 내용
• 이미 오래된 버그 상태
• 장기 유효성이 불분명한 추측

장기 메모리는 갱신 메커니즘도 필요합니다. 작성 시 중복 병합, 정기적인 오래된 항목 정리, 사용자 검토·편집·삭제가 가능해야 합니다. 프로젝트 간 공유도 신중해야 합니다. 선호도는 공유될 수 있어도 프로젝트 지식은 무턱대고 공유하면 안 됩니다.

5. 개념 철학 편: 열린 성찰

Q23. 왜 context를 단순하게 유지해야 하나요? 가득 채운 prompt가 더 낫지 않나요?

토론 방향

컨텍스트의 가치는 길이에서 오지 않고 신호 대 잡음 비에서 옵니다.

정보를 과하게 넣으면 생기는 문제:

• 주의력 희석: 핵심 규칙이 불필요한 정보에 묻힘
• 비용 증가: 매 추론마다 처리 토큰이 증가
• 지연 증가: 긴 컨텍스트는 보통 응답 속도 저하로 이어짐
• 디버깅 어려움: 문제 발생 시 어떤 규칙 충돌인지 찾기 어려움
• 진화 곤란: 복잡한 prompt는 거미줄처럼 엉켜 수정이 어려워짐

좋은 컨텍스트는 “적은 정보”가 아니라 “현재 작업에 정말 필요한 정보만” 담는 것입니다.

Q24. Agent는 능동적으로 행동해야 하나요, 수동적이어야 하나요? 언제 사용자에게 물어보고 언제 스스로 결정해야 하나요?

토론 방향

판단 기준은 세 가지입니다.

1. 행동의 가역성: 로컬에서 되돌릴 수 있는 변경은 스스로 결정 가능, push/delete/send email처럼 되돌리기 어려운 행동은 반드시 사용자 확인 필요 2. 영향 반경: 로컬에만 영향이 미치면 더 적극적으로, 팀/프로덕션/고객에 영향은 신중히 3. 불확실성: 모델이 확신이 없으면 추측하지 말고 질문

좋은 agent는 “아무거나 다 묻는 것”도, “아무거나 다 결정하는 것”도 아닙니다. 핵심 분기만 질문하고 사소한 일은 방해하지 않는 균형이 중요합니다.

Q25. Vibe Coding은 과장된 유행어인가, 패러다임 혁신인가?

토론 방향

과장파는 이렇게 말합니다. 이는 단지 더 똑똑한 자동 완성일 뿐이며, 복잡한 프로젝트에서는 여전히 기초 실수가 잦고 유지보수 비용이 과소평가됩니다.

패러다임론자는 이렇게 봅니다. 코딩의 기본 단위가 “행/함수”에서 “의도/제약”으로 이동하고 있다고 봅니다. 엔지니어는 타이핑 담당자에서 설계자·리뷰어·시스템 설계자로 바뀝니다.

안전한 중간 입장은 이것입니다. Vibe Coding은 패러다임 변화이지만 1:1 대체는 아닙니다. 고급 엔지니어의 능력을 증폭시키며, 그들이 더 나은 spec과 리뷰를 제공하면 결과가 좋아집니다. 반대로 낮은 역량 사용자는 더 빨리 나쁜 코드를 생산할 수 있습니다.

핵심 추궁은 다음과 같습니다.

• agent가 코드를 쓸 때 지식은 어디에 축적되나? 저장소·문서·테스트, 아니면 개인 두뇌?
• 코드 리뷰의 중요성은 코딩 자체보다 커질까요?
• 초급 포지션과 코딩 교육은 어떻게 변할까요?

Q26. 같은 버그를 agent가 계속 못 고칠 때, 계속 시도하게 둘까요, 아니면 중단해야 할까요?

토론 방향

agent가 반복해서 같은 잘못된 해결책을 시도한다면, 컨텍스트 오염 가능성이 큽니다. 계속 토큰을 태우며 반복하면 미로를 더 깊게 파는 결과가 됩니다.

더 나은 방법은:

• 실패 횟수 상한 설정(예: 연속 3회 실패 시 중단)
• 현재 패치 루프를 멈추고 최소 재현, 로그, 실패 테스트를 정리
• 다른 모델로 독립 진단 수행
• 필요 시 사람 손으로 핵심 경로 직접 처리

agent가 막히는 대부분의 경우는 “추론이 부족해서”가 아니라 정보 누락, 불명확한 테스트, 컨텍스트 오염, 또는 방향 오류 때문입니다.

Q27. agentic 워크플로우에서 왜 TDD가 전통 워크플로우보다 더 중요한가요?

토론 방향

agent는 자신감 있게 틀리기 쉽습니다. API를 잘못 만들고, 필드를 잘못 정하고, 반환값을 잘못 맞추는 일이 발생합니다. 테스트는 거의 유일하게 agent가 실제로 작업을 끝냈는지 객관적으로 판단할 수 있는 장치입니다.

agentic 워크플로우에서 TDD가 특히 중요한 이유:

• 테스트는 agent와의 계약
• 실패 테스트는 명확한 피드백 루프 제공
• 모호한 요구사항을 실행 가능한 규약으로 전환
• 인수 테스트가 “겉으로는 완료된 것처럼 보이는데 실제로는 안 된 상태”를 방지

다만 주의할 점: agent가 스스로 테스트 쓰고 스스로 구현하고 스스로 통과라고 선언하는 구조만으로 끝내지 말아야 합니다. 핵심 인수 테스트와 보안 테스트는 사람이 작성하거나, 별도 모델이 독립 리뷰해야 합니다.

Q28. “agent가 쓴 코드는 가독성이 떨어진다”는 문제는 어떻게 처리하나요? 도구 문제인가, 사용법 문제인가요?

토론 방향

둘 다 있습니다.

도구 관점에서 모델은 과도한 추상화, 과잉 방어 코드, 과한 주석을 만들기 쉬워요. 사용법 관점에서 사용자 제한을 두지 않고 review를 건너뛰며 first try를 곧바로 수용하면 나쁜 코드가 쌓입니다.

실행 가능한 개선책:

• CLAUDE.md 또는 AGENTS.md에 가독성 하드 규칙 작성
• 함수 길이 제한, 네이밍 스타일, 주석 규칙 지정
• “단순화/리팩터/중복 제거”를 별도 단계로 강제
• code-review skill로 agent 자가점검 강제
• 중요 모듈은 사람이 diff를 직접 한 번 읽기

agent가 작성한 코드를 아예 보지 않으면, 본질적으로 책임이 없는 초보 인턴에게 운영 코드를 아웃소싱하는 것과 다르지 않습니다.

Q29. “agent에게 밤새 작업을 시켰는데 뭘 했는지 모르겠다” — 이것은 agent의 문제인가, 사용자 문제인가?

토론 방향

책임은 양쪽에 모두 있습니다.

도구 제공 측은 관측 가능성을 제공해야 합니다. 파일 diff, 명령 로그, 핵심 의사결정 지점, 실패 기록, 단계별 요약이 필요합니다.

사용자 측도 경계를 설정해야 합니다. 제약 없이 overnight로 agent를 풀어 두면 안 됩니다. 긴 작업은 단계별로 나누고, 각 단계마다 명확한 목표·권한 범위·체크포인트를 설정해야 합니다.

장시간 자율 작업일수록 제약이 강화되어야 합니다. 완전 무감시 장거리 agent는 “무감시 초보 인턴 + sudo 권한”과 유사하며, 운영 환경에서는 위험도가 매우 높습니다.

Q30. Agentic 도구가 결국 프로그래머 직업을 사라지게 할까요?

토론 방향

더 현실적인 가능성은 “프로그래머가 사라지는 것”이 아니라 “프로그래머의 추상화 레벨이 올라가는 것”입니다.

약화되는 일은 명확한 spec을 코드로 번역하는 단순 역할입니다. 여전히 중요한 것은 요구사항 이해, 시스템 분해, 판별 판단, 책임, 장기 아키텍처 유지입니다.

앞으로 더 중요해질 수 있는 역할:

• Agent 아키텍트: agent 협업 그래프, skill 라이브러리, 컨텍스트 전략 설계
• AI 리뷰어: agent 출력의 고속 review
• 컨텍스트 엔지니어: 도메인 지식을 agent가 소화할 수 있는 형태로 구조화
• 엔지니어링 오너십 담당: 어떤 작업을 자동화할지, 무엇은 인간 검토가 필수인지 결정

역사적 비유를 들면, 컴파일러가 프로그래머를 없애지는 않았지만 수작업 어셈블리를 다루던 인원을 크게 줄였습니다. AI agent도 비슷할 수 있습니다. 즉 엔지니어를 제거하는 것이 아니라 더 높은 추상계로 이동시키는 방향입니다.

6. 부록: 추천 학습 경로

입문 단계

공식 문서를 먼저 읽고 기본 능력을 실행해 보세요.

• 프로젝트 규칙 파일: CLAUDE.md / AGENTS.md
• skill
• agent
• hooks
• /compact
• memory
• Codex / Claude Code 기본 permission 모드

목표는 개념을 외우는 게 아니라 각자가 어떤 문제를 해결하는지 아는 것입니다.

심화 단계

자주 하는 3가지를 패키지화하세요. 예:

1. commit message 생성 2. PR 요약 작성 3. 코드 수정 후 자동 테스트 및 typecheck 실행

핵심은 “매번 AI에게 내가 반복 설명하는 습관”에서 “프로세스를 프로젝트 자산으로 축적”하는 전환입니다.

고급 단계

팀 또는 개인 프로젝트를 위한 agentic workflow를 구축하세요.

• CLAUDE.md / AGENTS.md: 장기 규칙
• skills/: 재사용 가능한 절차
• agents/: 조사, review, debug 등 전용 역할
• hooks/: 결정론적 제약
• PROGRESS.md: 장기 작업 상태 기록
• TASKS.md: 작업 분해

전문가 단계

더 복잡한 문제를 연구하세요.

• PreToolUse 단계에서 hooks의 권한 판단
• MCP 게이트웨이와 기업 권한 모델
• 다중 agent 협업의 메시지 예산 및 감사
• 장시간 overnight 워크플로우의 checkpoint 설계
• 테스트, 문서, 규칙 파일이 어떻게 함께 agent의 신뢰 가능한 컨텍스트가 되는지

7. 참고 링크

• Claude Code Docs: llms.txt
• Claude Code Docs: Hooks Reference
• Claude Code Docs: Automate workflows with hooks
• OpenAI Codex: Get started
• OpenAI Codex GitHub Repository
• OpenAI Codex: Installation Docs
• OpenAI Cookbook: Codex Prompting Guide

더 많은 Codex 실무 사례는 《깊이 쓰는 Codex》를 참고하세요. Claude 도구 간 빠르게 전환하려면 CC Switch 도구 소개를 참조하세요.

자주 묻는 질문

이 글은 어떤 수준의 개발자에게 적합한가요?

본문의 “적용 대상” 섹션을 참고하세요. 이 사이트의 프로그래밍 카테고리 글은 입문부터 AI 코딩 워크플로우까지 여러 수준을 커버하며, 각 글마다 서로 다른 선행 지식이 제시됩니다.

글의 도구나 명령은 시스템마다 차이가 있나요?

있습니다. macOS, Linux, Windows는 터미널 환경, 경로 형식, 명령 문법이 다르므로, 본문에서 특정 운영체제를 명시하지 않은 경우 공식 문서를 참고해 각 시스템에 맞춰 조정해야 합니다.

어떤 AI 도구를 함께 써서 코딩을 배우면 좋을까요?

Claude Code와 Codex는 현재 강력한 프로그래밍 AI 도구로, 코드 설명, 로직 보완, 디버깅, 스크립트 생성에 활용할 수 있습니다. 관련 도구 소개는 본 사이트의 CC Switch 도구 글과 Vibe Coding 면접 문제집에서 볼 수 있습니다.

프로그래밍을 배우는 데 가장 중요한 습관은 무엇인가요?

실전으로 손을 많이 대는 것이 중요합니다. 가능한 한 빨리 작고 실제적인 프로젝트를 하나라도 잡고, 문제를 만났을 때 이론을 끝까지 공부한 뒤가 아니라 문서와 코드를 읽으며 직접 해결해 보세요.