Awesome-Copilot × 바이브 코딩으로 효율적으로 업무를 끝내고 싶다 (소망)

수고 많으십니다. 지난 업데이트 이후 시간이 꽤 흘러버려, 지속적으로 테크 블로그를 올리지 못했던 점을 반성하고 있습니다.

조금 규모가 큰 릴리스(Release) 작업들이 겹쳐 있었습니다.

그동안에도 여러 가지를 만들고 시도해 보았기에, 그것들을 조금씩 기사로 만들어 가려고 합니다.

그래서 이번에는 바이브 코딩(Vibe Coding)과 Awesome-Copilot을 사용해 보았더니, 평소의 개발보다 빠르게 개발할 수 있었기에 기사로 남겨두려 합니다.

먼저, 이제 와서 하는 느낌도 있습니다만, Vibe Coding에 대해 간단히 적어두겠습니다.

바이브 코딩(Vibe Coding)은 '분위기(Vibe)로 코딩한다'는 뜻으로, 자연어로 설계서를 아주 꼼꼼하게 만들어 놓고 코딩하는 것이 아니라,

무엇을 만들고 싶은지·어떻게 움직이게 하고 싶은지라는 의도를 AI 에이전트(AI Agent)에게 전달하여 작성하게 하는 것이 특징인 개발 기법입니다.

바이브 코딩에서 특히 중요한 것이 **프롬프트(Prompt)**입니다.

AI에게 '무엇을 만들고 싶은지'를 전달하는 것이 프롬프트이지만, 모호한 지시를 내리면 의도와 전혀 다른 코드가 생성되어 버립니다.

반대로, 적절한 프롬프트를 작성할 수 있다면 AI는 놀라울 정도로 정확하게 움직여 줍니다.

프롬프트는 똑똑한 분들이 매일같이 연구·개량하고 있어 따라잡기가 힘들지만,

프롬프트 기법을 모두 나열하면 끝이 없으므로, 대략 중요해 보이는 부분만 나열해 두겠습니다.

목적을 명확히 하기— 「~를 만들고 싶다」가 아니라 「~라는 기능을 가진 ~를 구현하고 싶다」와 같이 구체적으로 전달 -
제약·조건 덧붙이기— 사용 언어, 프레임워크, 기존 코드와의 정합성 등 전제 정보를 전달 -
기대하는 출력 보여주기— 함수 단위인지, 파일 전체인지, 어디에 포함시킬 것인지를 명시

Awesome-Copilot은 GitHub가 호스트하는 커뮤니티 주도의 리포지토리(Repository)로, GitHub Copilot을 더욱 효과적으로 활용하기 위한 에이전트(Agent)·인스트럭션(Instruction)·스킬(Skill)·워크플로우(Workflow) 등을 정리한 컬렉션입니다.

커뮤니티가 실제로 사용해서 효과적이었던 것들을 모아두었기 때문에, 처음부터 스스로 프롬프트를 생각하지 않아도 즉시 높은 품질의 설정을 사용할 수 있습니다.

주요 구성 요소는 대략 다음과 같습니다.

Agents— MCP 서버와 통합하는 전문 에이전트. 특정 도메인의 작업을 통째로 맡길 수 있음 -
Instructions— 파일 패턴에 따라 자동 적용되는 코딩 표준. 리포지토리 전체에 AI의 행동을 통일할 수 있음 -
Skills— 인스트럭션과 관련 에셋(Asset)을 하나로 묶은 자기 완결형 기능 팩 -
Plugins— 특정 워크플로우를 위해 에이전트와 스킬을 번들(Bundle)한 세트. copilot plugin install로 즉시 도입 가능 -
Hooks— Copilot 에이전트의 세션 중에 자동으로 트리거되는 액션 -
Agentic Workflows— 마크다운(Markdown)으로 기술하는 AI 구동 GitHub Actions 자동화 -
Cookbook— Copilot API를 사용한 복사 붙여넣기로 바로 쓸 수 있는 레시피 모음

요컨대, '선배들의 지혜를 그대로 빌려와서 바이브 코딩의 정밀도를 끌어올리기' 위한 리소스 모음입니다.

도입에 대해서는 다양한 기사나 공식 문서에서 제공하고 있으니 그쪽을 확인해 주세요.

먼저 무엇을 만들 것인가의 페이즈(Phase)입니다.

무엇을 만들면 좋을지 몰라서 상사에게 상담했습니다.

나「바이브 코딩으로 무엇을 하면 좋을까요?」
상사「경로 최적화 문제 같은 통계학 문제를 푸는 툴을 만들면 어때?」

라는 분위기로 경로 최적화 문제를 풀기로 했습니다.

※ 경로 최적화 문제란, 여러 지점을 순회할 때 '거리·시간·비용이 최소가 되는 순서·경로'를 구하는 문제입니다. 유명한 것으로는 '순회 외판원 문제(TSP)'가 이에 해당합니다. 지점 수가 늘어나면 모든 패턴을 전수 조사하는 것이 현실적으로 불가능해지기 때문에, 알고리즘이나 통계적 기법으로 근사해(Approximate solution)를 구하는 것이 일반적이라고 합니다.

그렇다고는 해도, 제대로 서비스처럼 만들고 싶으므로, 차로 5명을 데리러 가는 최단 경로를 계산하는 툴로 하겠습니다.

다음은 요구사항 정의(Requirement Definition)인데, 무엇을 결정해야 AI 에이전트에게 빠짐없이 오해 없이 전달될지 몰랐기에, Awesome-Copilot에게 물어보겠습니다.

Awesome-Copilot은 MCP 서버로 이용할 수 있으므로, 우선 "요건 정의(Requirements Definition)에 필요한 항목을 알려달라고 하기" 단계부터 MCP를 사용합니다.

다음 명령을 실행하여, 경로 최적화 문제(Route Optimization Problem)에서 차량으로 5명을 데리러 가는 최단 경로를 계산하는 툴을 만들기 위한 요건 정의를 prompts/phase1.md에 작성하고 싶다.
/mcp_awesome-copil_search_instructions keywords:"requirements definition project planning"

라고 입력했습니다.

▼ search_instructions의 응답 (실제로는 전체 카탈로그가 반환됨):

Agents (일부 발췌):
- prd.agent.md : Generate a comprehensive Product Requirements Document (PRD) in Markdown,
detailing user stories, acceptance criteria, technical considerations, and metrics.
...

키워드로 필터링되는 것이 아니라, Awesome-Copilot에 있는 모든 콘텐츠의 목록이 반환됩니다.

목록의 설명문을 읽은 후, 요건 정의에 사용할 수 있을 법한 prd.agent.md

("Generate a comprehensive Product Requirements Document...")를 GitHub Copilot이 추천해 주었기에, 로드해 보겠습니다.

이하를 실행하여 요건 정의의 상세 내용을 구체화하고자 합니다.
/mcp_awesome-copil_load_instruction filename:prd.agent.md mode:agents
prompts/phase1.md를 작성함에 있어 필요한 항목을 알려주세요

▼ load_instruction (prd.agent.md)의 응답 (발췌):

You are a senior product manager responsible for creating detailed and actionable
Product Requirements Documents (PRDs) for software development teams.
PRD Outline:
...

여기서 중요한 점은, MCP로 취득한 내용이 AI의 컨텍스트 (Context)에 자동으로 주입된다는 점입니다.

즉, "요건 정의는 이렇게 진행해야 한다"라는 프레임워크를 AI가 사전에 보유한 상태에서, 자신이 하고 싶은 것을 전달할 수 있다는 것이 포인트입니다.

MCP로부터 취득 (요건 정의 프레임워크)
↓
사용자가 만들고 싶은 것을 입력 (자신이 하고 싶은 것)
...

① MCP가 AI에 주입한 컨텍스트 (prd.agent.md로부터):

prd.agent.md는 시니어 프로덕트 매니저(Senior Product Manager)로서 PRD (Product Requirements Document, 제품 요구사항 정의서)를 작성하는 에이전트이며, 다음과 같은 프레임워크를 AI에게 읽히는 것으로 보입니다.

그리고 다음과 같은 항목에 대해 질문을 받았기에 입력했습니다.

섹션	내용
Product overview	프로젝트의 목적·스코프(Scope) 개요
...

② 내가 입력한 내용:

항목	내용
목적	5명을 데리러 가는 최단 경로를 계산한다
...

③ 상기 답변에 의해 생성된 prompts/phase1.md

위 과정을 실시한 후, 요건 정의에서 부족한 정보는 없는지 확인 작업을 수행했습니다.

기본 설계(Basic Design)로 넘어가기에 앞서, 불명확한 부분이나 잘못된 부분이 있는지 관점에서 리뷰해 주세요.

위의 리뷰 → 대응 과정을 몇 차례 반복한 결과, 일부 발췌이지만 다음과 같이 완성되었습니다.

데이터 모델 정의 (Data Model Definition)—User (복수 주소 대응) / DistanceMatrix / Route / Constraint 등의 Go 구조체 정의 -
API 엔드포인트 설계 (API Endpoint Design)—POST /api/v1/users (친구 추가 + 거리 행렬 자동 생성) / POST /api/v1/routes/optimize (최적화 실행) 등 -
디렉토리 구성 (Directory Structure)—cmd/ internal/handler

internal/service

internal/repository

internal/optimizer

의 역할 분담 -
알고리즘 방침 (Algorithm Policy)— Greedy Nearest Neighbor → 2-opt Local Search 의 2단계 최적화 -
범위 외 명시 (Out of Scope)— 시간 제약·상세 CRUD·실시간 정체 고려는 향후 확장 대상으로 취급

다음으로 페이즈 2로서, 페이즈 1의 요구사항 정의를 바탕으로 기본 설계 및 데이터 정의를 수행합니다.

여기에서도 동일한 메커니즘으로 MCP를 사용합니다. 이번에는 go.instructions.md를 직접 로드하여, Go의 코딩 규칙을 AI에 주입한 후 지시를 내렸습니다.

다음 명령을 실시하여, prompts/phase1.md를 바탕으로 기본 설계 및 데이터 정의를 prompts/phase2.md에 작성하고 싶다.
/mcp_awesome-copil_load_instruction filename:go.instructions.md mode:instructions

라고 입력했습니다.

▼ load_instruction (go.instructions.md)의 응답 (발췌):

# Go Coding Standards
Based on:
- Effective Go (https://go.dev/doc/effective_go)
...

페이즈 1과 마찬가지로, MCP로 취득한 내용은 AI의 컨텍스트 (Context)에 자동으로 주입되기 때문에,

「Go는 이렇게 작성해야 한다」라는 지식을 AI가 사전에 가진 상태에서, 자신의 설계 지시를 전달할 수 있습니다.

MCP로부터 취득 (구현 규칙·골격 패턴)
↓
사용자가 「이 구성으로 구현해줘」라고 지시
...

① MCP가 AI에 주입한 컨텍스트 (페이즈 2에서 특히 효과적이었던 부분):

카테고리	AI에 주입된 규칙
DI (의존성 주입)	생성자 NewXxx()에 의존성을 모두 전달한다. 서비스 계층은 인터페이스 타입 필드를 가진다
...	gofmt / go vet / go test ./... / go build를 모두 통과하는 것을 전제로 한다

② 내가 입력한 내용:

항목	내용
구현 대상	페이즈 1에서 정의한 요구사항대로의 모든 파일 구성
...

③ 상기 응답에 의해 생성된 prompts/phase2.md

위 작업을 실시한 후, 페이즈 1과 마찬가지로 리뷰를 요청했습니다.

구현으로 넘어가기에 앞서, 불명확한 부분이나 잘못된 부분이 있는지 관점에서 리뷰해줘.

상기 리뷰 → 대응을 몇 차례 반복한 뒤, 「그럼 구현해줘」라고 입력했습니다.

이하 사항들은 준수되었습니다.

• 모든 핸들러가 「바인딩(Bind) → 조기 리턴 유효성 검사(Early Return Validation) → 서비스 호출 → JSON 응답」의 일관된 구조로 생성
• NewOptimizerService(userRepo, staffRepo, ...)와 같이 DI 패턴이 모든 레이어에서 철저히 적용
• 레이어 간의 에러 래핑(Error Wrap)·명명(Naming)·구조가 첫 단계부터 통일되어 있어, 수정 없이 바로 동작

실제로 완성된 제품에 대한 소감입니다만, 주요 기능은 문제없이 동작했고 버그나 불편함도 제로였습니다. 그렇게 많이 돌려보지 못했다는 점도 있겠지만 말입니다.

제가 지정한 알고리즘도 사용해 주는 것 같아서, 조건을 바꿔도 적절하게 경로를 최적화해 주었습니다.

실패했다고 생각하는 점은, 화면 목업(Mock)을 먼저 만들고 그에 맞춘 요구사항으로 설정했어야 했다는 것입니다.

「이걸 입력하고 싶은데 안 된다」라거나 「마중 나가는 것뿐인데 공정이 너무 많다」 등, 신경 쓰이는 점이 많았습니다.

또 하나는, 도중에 마중 나가는 순서에 우선순위를 매기고 싶어서 그 부분을 페이즈 3로 추가했는데, 이것이 실패였습니다.

기존 API에 통합되는 것이 아니라 새로운 기능으로 추가되어 버려서, 화면에는 반영되지 않고 결국 어디에서도 호출되지 않는 코드가 되어 버렸습니다.

애초에 컨텍스트 엔지니어링 (Context Engineering)을 이해하고 관리할 수 있었다면 어떻게든 되었을지도 모른다고 되돌아보고 있습니다만, 공부가 부족했습니다.

다음에 할 때는 스케일 업 (Scale-up)하기 쉬운 구성을 생각하여, 멀티 에이전트 (Multi-agent)로 추가 기능에도 문제없이 대응할 수 있는 형태로 만들고 싶습니다.