하네스만 있으면 (거의) 충분하다

https://github.blog/ai-and-ml/github-copilot/the-harness-is-all-you-need-mostly/

요즘 AI에 압도당하는 기분이 든다면, 그런 사람이 여러분만은 아닙니다.

매일같이 새로운 도구, 새로운 MCP, 새로운 모델, 새로운 스킬, 새로운 워크플로, 새로운 기능이 쏟아지고, "이것 보세요! 이 신기한 프롬프트 하나로 AI를 완전히 정복했습니다" 같은 소셜 미디어 게시물이 올라옵니다.

글쎄요… 저는 안 믿습니다.

저는 매일 AI와 함께 일하는데, 갈수록 느끼는 건 덜어낼수록 오히려 훨씬 낫다는 점입니다. 무엇을 설치하고, 어떻게 설정하고, 에이전트를 어떤 꾀로 움직이게 하느냐는 실질적인 차이를 만들지 못합니다. 그런 것들도 흥미롭긴 하지만, 결국은 잔재주처럼 느껴집니다.

제 생산성이 가장 크게 오르는 지점은 하네스(harness)를 어떻게 쓰고 얼마나 깊이 이해하느냐에 있습니다.

그래서 이 글에서는 GitHub Copilot의 기존 기능만으로 AI 활용 효과를 크게 끌어올릴 수 있는 간단한 워크플로를 소개합니다. 이상한 프롬프트도, 남들만 다 아는 것 같은 비법 스킬도 필요 없습니다. 하네스면 됩니다. 하네스만 있으면 충분합니다 — 거의요.

[면책 사항]
이 글에서 "하네스"라는 용어는 "GitHub Copilot"과 같은 뜻으로 쓰고 있습니다. 이 글의 취지가 단순하게 가자는 것이니, GitHub Copilot이 에이전트 하네스라는 점만 알아 두시면 됩니다.
스킬, MCP, 지침, 커스텀 에이전트 같은 것들이 앞으로도 전혀 필요 없을 거라는 뜻은 아닙니다. 오히려 활용이 깊어져서 복잡한 워크플로를 정의하고 팀을 위한 자동화가 필요해지면 이런 것들이 꽤 중요해집니다. 실제로 저도 이 글 곳곳에서 몇 가지를 쓰고 있고요!
여기서 말하고 싶은 건, AI로 큰 성과를 내는 데 그런 것들이 하나도 필요하지 않다는 점입니다.
그리고 세상에는 조잡한 결과물(slop)이 정말 많습니다. 못 믿겠다면 에이전트에게 아무 일이나 하는 스킬을 만들어 달라고 해 보세요. 기꺼이 만들어 줄 겁니다. 그렇게 생성된 스킬이 실제로 작동하든 말든, 스킬이나 MCP 레지스트리 어디에든 손쉽게 게시할 수 있습니다.

1. 도구 하나를 고르세요, 어떤 것이든

너무 당연한 얘기죠? 도구를 고르라니, 참 쉽습니다!

하지만 GitHub Copilot 제품군 안에서도 선택지가 많습니다. CLI, 새로 나온 GitHub Copilot 앱, VS Code, Visual Studio, JetBrains 등이 대표적입니다.

다행인 점은 이들 경험이 점점 같은 하네스 위로 통합되고 있다는 것입니다. 세부 사항은 도구마다 다를 수 있지만, 핵심 워크플로는 동일합니다. 하네스를 한 번 익히면 어디서나 쓸 수 있습니다.

그렇더라도 하네스를 익히는 일이 핵심이고, 가장 좋은 학습 방법은 하네스에 최대한 가까이 붙어 있는 것이라고 생각합니다. 그래서 이제 막 시작하는 분이라면 GitHub Copilot CLI부터 써 보시길 권합니다. 터미널 인터페이스라 모든 게 텍스트입니다. 익혀야 할 UI가 별로 없습니다. 프롬프트를 입력하면 에이전트가 일을 합니다. 그런데 그 상호작용이 더 직접적이고 즉각적이며, 솔직히 꽤나 만족스럽습니다.

이 글의 시연에는 새로 나온 GitHub Copilot 앱을 사용하겠습니다. 하지만 이 앱이 쓰는 하네스는 GitHub Copilot CLI, Visual Studio Code를 비롯해 GitHub Copilot이 들어간 다른 여러 곳에서 쓰게 될 하네스와 정확히 같은 것입니다.

2. YOLO 모드를 켜세요

YOLO 모드는 "모두 허용(Allow All)"이라고도 불립니다. 에이전트가 허락을 구하지 않고 어떤 명령이든 실행할 수 있게 해 주는 기능입니다. 사용하는 도구에 따라 방법이 다를 수 있지만, 대부분은 채팅에서 /allow-all 명령만 입력하면 됩니다. 이걸 켜지 않으면 에이전트는 일을 할 때마다 매번 멈춰서 승인을 기다리게 됩니다.

생산성 향상을 체감하려면 에이전트에게 자율성이 필요합니다. 에이전트가 하는 일을 일일이 승인해야 한다면, 차라리 직접 하는 편이 낫습니다. 게다가 그건 사용자 경험으로도 끔찍합니다. 하루 종일 책상에 앉아 "승인" 버튼만 누르는 신세가 되고 싶은 사람은 없습니다. 그리고 "승인"을 반복해서 누르다 보면 정작 무엇을 승인해 달라는 것인지 읽지 않는 습관만 들게 되어, 승인 절차의 의미 자체가 사라집니다.

다만 에이전트는 안전하게 써야 합니다. 착한 사람에게도 나쁜 일은 일어나니까요. YOLO 모드를 쓸 때는 에이전트를 로컬 머신에서 돌리지 않는 게 좋습니다. 특히 회사에서 쓸 때는 더욱 그렇습니다. 조직 시스템의 데이터는 기밀이고, 실수는 큰 대가로 돌아올 수 있습니다.

다행히 에이전트를 샌드박스에서 돌릴 방법은 많습니다. 시작하기 쉬운 선택지로는 GitHub Codespaces나 개발 컨테이너가 있습니다.

3. 프로토타입부터 시작하세요

AI의 가장 마법 같은 점 하나는 무엇이든 미리 손쉽게 프로토타입으로 만들어 볼 수 있다는 것입니다. 예전에는 그렇지 않았습니다. 프로토타이핑은 프로젝트의 한 단계를 통째로 차지했고, 사치인 경우도 많았습니다. 이제는 프롬프트 하나로 만들 수 있습니다.

몇 가지 예를 보겠습니다.

날짜 선택기(date picker) 웹 컴포넌트를 만든다고 해 봅시다. 단순해 보이지만 실제로는 꽤 복잡합니다. 이 컴포넌트로 하고 싶은 온갖 일들을 떠올려 보세요.

• 컴포넌트 안에서는 어떻게 이동하나요?
• 선택된 날짜는 어떻게 표시되나요?
• 선택된 기간은 어떻게 표시되나요?
• 일·월·연도 사이는 어떻게 오가나요?

간단한 프로토타입으로 시작해 여러 가지 변형을 받아 보세요. 저는 보통 이렇게 시작합니다.

날짜 선택기 웹 컴포넌트 목업 20개를 만들어 줘. 비교할 수 있게 전부 HTML 파일 하나에 넣어 줘.

이번 경우 AI는 다양한 레이아웃을 만들어 냈는데, 그중 하나가 연도 화면에서 시작하는 목업이었습니다. 흥미롭죠. 제 날짜 선택기는 사용자가 연도로 축소했다가 월로, 다시 일로 확대해 들어갈 수 있으면 좋겠습니다. 이런 건 직접 눈으로 보기 전에는 떠올리지 못하는 부분입니다.

인간은 이미지, 도형, 손에 잡히는 레이아웃처럼 감각 정보가 풍부한 형태를 빽빽한 텍스트보다 훨씬 빨리 받아들입니다. 초반에 가볍게 프로토타입을 만들어 두면 복잡한 개념도 즉시 직관적으로 이해할 수 있습니다.

그리고 이는 시각적이지 않은 작업에도 똑같이 적용됩니다.

예를 들어 새 API 엔드포인트를 추가하고 싶을 때도, 구현에 뛰어들기 전에 요구사항과 제약을 파악하기 위해 시각적인 프로토타입을 먼저 만듭니다.

이 프로젝트의 API를 시각적인 목업으로 만들어 줘. 사용자가 자신의 분석 데이터를 내려받을 수 있는 새 API 엔드포인트를 어떻게 처리할지 다섯 가지 안을 추가해 줘.

GitHub Copilot 앱은 Mermaid 다이어그램을 지원하므로, 에이전트가 이 API 엔드포인트를 구현할 수 있는 다섯 가지 방식을 Markdown 다이어그램으로 정리해 보여 줍니다.

에이전트와 일하다 보면 모든 일에 미묘한 구석이 있다는 사실을 잊기 쉽습니다. 프로토타이핑은 그런 미묘한 지점을 미리 드러내 주어, 소중한 시간과 토큰을 재작업에 낭비하지 않게 해 줍니다.

대부분의 작업에는 GPT 5.6 Terra나 Claude Sonnet 같은 중간 크기 모델을 중간 추론 수준으로 쓰기를 권합니다. 그리고 일단 모델을 골랐다면 해당 기능, 버그, 개선 작업이 끝날 때까지는 그 모델을 유지하는 게 좋습니다. 프롬프트 캐싱 덕분에 토큰을 아낄 수 있기 때문입니다. 다른 모델이나 추론 수준으로 바꾸지 않는 한 이전 대화가 모델에 캐시된 상태로 남아, 이후 요청에서 할인을 받게 됩니다.

4. 체계적으로 계획하세요

처음에 원한다고 생각했던 것과 실제로 원하는 것이 무엇인지 알게 되었으니, 이제 구현을 계획할 차례입니다.

새 세션을 시작하지 말고 GitHub Copilot에서 플랜 모드로 전환하세요.

/plan 날짜 선택기 웹 컴포넌트를 만들어 줘. 사용자가 연도, 월, 일 사이를 확대·축소하며 오갈 수 있으면 좋겠어.

꽤 두루뭉술한 프롬프트입니다. 실제로는 여기 제 예시보다 모델에 줄 컨텍스트가 더 많겠지만, 이건 어디까지나 시연이니까요. 컨텍스트가 더 없어도 괜찮습니다. 바로 그럴 때를 위한 단계가 이것이니까요.

이론적으로는 완벽한 프롬프트에 완벽한 컨텍스트를 완벽한 순서로 담아내면 모델이 무엇이든 한 번에 해내게 할 수 있습니다. 어디까지나 이론상으로요.

하지만 그런 걸 해낼 수 있는 사람은 없습니다. 그래도 계획 단계는 이 기능을 직접 손으로 만들었다면 스스로 답해야 했을 질문들을 대신 던져 주면서, 그 이상에 한 걸음 더 다가가게 해 줍니다.

• 시작일과 종료일이 같아도 되나요?
• 부분 선택도 유효한가요?
• 사용자가 날짜를 지울 수 있어야 하나요?
• "오늘"은 항상 보이는 선택지여야 하나요?
• 직접 입력을 허용하나요?
• 날짜는 어떤 형식으로 저장하나요?
• 날짜 붙여넣기를 허용해야 하나요?

이런 질문은 끝도 없이 이어집니다. 이 모든 예외 상황을 혼자 다 떠올릴 수는 없지만, 모델이 그중 상당수를 찾아내도록 도와줄 수 있습니다.

Matt Pocock이 만든 "grill-me" 스킬을 설치하면 플랜 모드가 던지는 질문과 예외 상황의 수를 한층 더 공격적으로 늘릴 수 있습니다.

/plan /grill-me 날짜 선택기 웹 컴포넌트를 만들어 줘. 사용자가 연도, 월, 일 사이를 확대·축소하며 오갈 수 있으면 좋겠어.

이 계획 단계는 매우 중요합니다. 핵심은 AI의 제안을 전부 그대로 받아들이는 게 아닙니다. 그렇게 하면 이 계획 과정의 가치를 스스로 없애는 셈입니다. 핵심은 문제에 깊이 파고들어 모델을 이끄는 것입니다. 바로 여기서 여러분의 전문성이 힘을 발휘합니다.

모델에게 되물을 수도 있습니다. 아래 스크린샷에서 모델이 "비연속 날짜(non-contiguous dates)"에 대해 묻는데, 무슨 뜻인지 대략 알 것 같긴 하지만 서로 같은 그림을 그리고 있는지 확인하기 위해 다시 설명을 요청하려고 합니다.

중간에 끼어들어 확인 질문을 던져도 계획 과정은 계속 이어집니다.

5. Autopilot으로 구현하세요

계획이 완성되면 GitHub Copilot이 Autopilot으로 전환해 계획 구현을 시작하자고 제안할 겁니다.

Autopilot은 내장된 반복 루프입니다. 모델이 하겠다고 말한 일을 실제로 했는지 확인하면서 작업을 계속하도록 강제합니다. 여기서는 계획의 모든 항목을 완료하는 것이 그 기준입니다.

이 단계에서 GitHub Copilot은 자동으로 오케스트레이터 역할을 합니다. 코드베이스의 파일을 읽어야 하면 작은 모델을 쓰는 "Explore" 서브에이전트를 사용하고, 비교적 복잡하다고 판단되는 작업에는 더 큰 모델을 쓰는 "General Purpose" 서브에이전트를 고를 겁니다. 커스텀 에이전트와 지침으로 GitHub Copilot의 오케스트레이션을 세밀하게 제어할 수도 있지만, 서브에이전트와 멀티모델 워크플로의 이점을 누리기 위해 특별히 뭔가 할 필요는 없습니다. 이런 것들이 존재하는지 몰랐더라도 기본 설정 그대로 작동합니다.

6. 사람이 검토하고 다듬기

도파민이 솟는 순간입니다. AI가 만들어 낸 결과물을 드디어 보게 되니까요.

하지만 원하던 결과가 그대로 나오지 않을 가능성이 큽니다. 정상이고, 예상된 일입니다. 모델은 마음을 읽지 못하고, 실수도 잦습니다. 실제로 원하는 결과가 나올 때까지 모델과 함께 반복해서 다듬으세요. 그것이 코드든 개선된 UI든, 최종 결과물의 품질은 이 단계에서 여러분의 안목이 결정합니다.

예를 들어 GitHub Copilot이 저에게 만들어 준 날짜 선택기는 이렇습니다.

벌써 몇 가지 문제가 눈에 띕니다.

• 애니메이션이 일관되지 않습니다
• 선택된 날짜에 마우스를 올리면 색 대비 때문에 글자를 읽을 수 없습니다
• 상단에 "12 YEARS"라고 적혀 있을 필요가 없습니다
• 월이나 연도 화면에서 "Today"를 클릭해도 해당 일 화면으로 이동하지 않습니다

그리고 디자인이 썩 마음에 들지는 않습니다. AI가 만든 티가 좀 많이 나는데, 실제로 AI가 만들었으니까요!

이제부터는 후속 요청을 이어 가는 단계입니다. 저는 제가 만든 Postrboard라는 CSS 프레임워크를 쓰려고 합니다. 해당 CSS를 가리키면서 에이전트에게 사용법을 알려 주는 스킬로 추가해 두었습니다. 써 보고 싶다면 직접 설치해도 좋고, 마음에 드는 다른 CSS 프레임워크를 골라도 됩니다. 모델에게 디자인 방향을 어느 정도 잡아 주면 꽤 도움이 되는데, CSS 프레임워크 하나면 충분한 경우가 많습니다.

좋아 - 여기 랜딩 페이지는 필요 없어 - 미니멀한 구성으로 컴포넌트, 출력, 설정 패널만 있으면 돼. 디자인과 색상은 /postboard 스킬을 사용해 줘.

날짜 선택기에서 일을 클릭하면 더 확대하려고 하는데, 확대할 대상이 없어서 안 돼. 거기서는 확대가 없어야 해.

상단에 "Zoom Out"이라고 적혀 있을 필요 없어

선택된 날짜가 포함된 월이나 연도에 마우스를 올리면 호버 텍스트를 읽을 수가 없어.

"Today"를 클릭하면 월이나 연도 화면에 있더라도 해당 일 화면으로 이동해야 해.

월 아래에 숫자는 필요 없고 상자 안에 들어 있을 필요도 없어

연도도 마찬가지야. 그리고 상단에 "12 years"라고 적혀 있을 필요 없어.

얼마나 대화하듯 쓰였는지 보세요. 너무 고민하지 마세요. 이런 자잘한 것들을 한꺼번에 고칠 때는 그냥 모델에게 던져 주면 됩니다. 컨텍스트가 머릿속에 있다면 프롬프트는 이미 완성된 셈입니다.

가장 중요한 건 "이 정도면 됐다" 싶은 AI 결과물에 안주하지 않는 것입니다. 품질을 끝까지 요구하세요. 가차 없이요. 그 부분은 여전히 여러분의 책임이고, 좋은 결과물과 그렇지 않은 것을 가려내는 안목이야말로 여러분이 기여하는 가치입니다. 어떤 AI도 인간의 손길과 창의성을 대신할 수는 없습니다.

제 최종 날짜 선택기는 이렇게 생겼습니다. 실제로 동작하는 모습은 이 글 맨 끝에서 확인하세요.

7. 결과물을 러버덕 리뷰하세요

반복해서 다듬은 결과물이 만족스러워졌다면, 이제 최종 검토를 할 차례입니다.

GitHub Copilot에 러버덕(Rubber Duck) 리뷰를 요청하세요. 그냥 이렇게 부탁하면 됩니다.

이 날짜 선택기 컴포넌트 구현에 대해 러버덕 리뷰를 수행해 줘

러버덕 리뷰에서 GitHub Copilot은 다른 AI 계열의 모델에게 리뷰를 요청합니다. 예컨대 저는 GPT 5.6 Terra를 쓰고 있었으므로 Sonnet에게 리뷰를 요청했습니다. 모델마다 학습한 데이터가 달라서 사각지대도 서로 다릅니다. 러버덕 리뷰는 모델 하나만으로는 놓칠 수 있는 잠재적 문제를 찾아내는 데 도움이 됩니다.

이 워크플로의 어느 시점에서든 쓸 수 있다는 점도 알아 두세요. 프로토타입도, 계획도 러버덕 리뷰를 받을 수 있습니다. 무언가에 대해 두 번째 AI의 검토를 받고 싶은지에 달려 있을 뿐입니다.

한 걸음 더 나아가고 싶다면 러버덕을 Autopilot과 결합해, 모델들이 루프를 돌며 함께 최종 결과물을 개선하게 할 수도 있습니다.

/autopilot 이 날짜 선택기 구현을 러버덕 리뷰해 줘. 결과가 나오면 꼼꼼히 검토해서 필요한 부분을 수정해 줘. 남은 항목이 더 손봐도 얻을 게 별로 없는 것들뿐이라고 너와 리뷰 모델이 모두 동의할 때까지 러버덕 리뷰를 반복해 줘.

이 단계를 거치면 결과물이 이전보다 한층 더 다듬어지고, 예외 상황도 여럿 더 찾아냈을 가능성이 큽니다. 토큰이 더 들긴 하지만, 코드를 제대로 담금질하는 과정입니다. 지금 문제를 잡아 둔 덕분에 나중에 같은 문제로 고생하지 않을 미래의 자신에게 하는 투자라고 생각하세요.

8. 결실을 거두세요

이 시점이면 스테이징하고 커밋할 준비가 된 것입니다. 아니면 이 풀 리퀘스트에 함께 담을 다음 기능으로 넘어가도 됩니다.

다음에 할 일이 이 날짜 선택기와 무관하다면 새 채팅 세션을 시작하기를 권합니다. 채팅 세션은 주제 단위라고 생각하면 됩니다. 본래 주제에서 너무 멀어지기 시작하면 새 세션을 열 때가 된 것입니다.

이 글을 위해 날짜 선택기를 만든 제 워크플로의 최종 결과물입니다.

다소 작위적인 예시라는 건 압니다. 그래도 잠시 멈춰서, 이제 AI로 해낼 수 있는 일들에 함께 감탄해 보면 어떨까요? 날짜 선택기 만들기는 한때 도전할 수 있는 일 중 가장 어려운 축에 들었습니다. 직접 만들어 본 영웅들에게 물어보세요.

복잡할 필요가 없습니다

이 간단한 워크플로면 대부분의 사람에게 충분합니다. 단순함은 멀티태스킹에도 도움이 됩니다. 단순하게 유지할수록 어떤 에이전트가 어떤 상태인지, 마지막에 무엇을 하고 있었는지 파악하기 쉽습니다. 여러분의 컨텍스트 윈도 역시 한정되어 있으니까요.

지금 AI 분야에서는 정말 많은 일이 벌어지고 있습니다. 만들고 실험해 볼 수 있는 것에는 상한이 없습니다. MCP 서버, 스킬, 지침, 커스텀 에이전트를 추가할 수 있습니다. 워크플로와 루프를 구성하고, 에이전트가 에이전트에게 프롬프트를 보내게 하고, 가상 개발팀 전체를 꾸릴 수도 있습니다.

다만 지금은 누구도 자기가 뭘 하고 있는지 제대로 모른다는 사실을 기억하세요. 우리 모두 부딪히며 알아 가는 중입니다. 오늘의 마법 주문처럼 보이는 AI 기법 상당수가 내일이면 안티패턴이 될 것입니다.