수탁 개발의 PM(Project Manager)을 하고 있으면, 어느 날 갑자기 이런 요청이 날아옵니다.

「이 기능, 대략적으로라도 좋으니 견적 부탁드립니다🙏」

첨부된 것은 이슈 티켓 1장, 고객사로부터 받은 채팅 스크린샷, 그리고 구두로 들은 단편적인 정보들. 이것을 그대로 엔지니어에게 「견적 내주세요」라고 던지면…… 대개 이렇게 됩니다.

• 엔지니어: "이거, 외부 서비스 연동은 API를 직접 호출하는 방식인가요? SDK를 내장하는 방식인가요?"
• 나: "어... 확인해 보겠습니다..." (고객사에게 물으러 감)
• 며칠 후, 또 다른 논점이 발견되어 다시 왕복

그리고 가장 무서운 것은, 논점이 누락된 채로 개략적인 수치를 내놓았다가, 나중에 "그 부분은 듣지 못했습니다"라는 상황이 발생하는 경우입니다.

견적이란, 주의를 기울이면 방지할 수 있는 실수임에도 불구하고 주의를 기울여도 발생하곤 합니다. 왜냐하면 정확도를 "PM의 주의력"에 의존하고 있기 때문입니다. 그리고 주의력은, 유독 바쁜 날에만 배신하곤 하죠.

그래서, 「견적을 내기 전에 엔지니어에게 전달할 기술 브리프(Technical Brief)」를 AI가 "구조"를 갖추어 구성하도록 하는 스킬을 만들었습니다. 이 기사에서는 그 고통의 정체와, 누구나 오늘부터 바로 사용할 수 있는 셋업 및 사용법을 전부 작성하겠습니다.

🔗 리포지토리는 여기 있습니다 (clone 하여 바로 사용할 수 있습니다)

이 기사를 통해 알 수 있는 것:

• ✅ 왜 "날것의 견적 요청"을 그대로 던지면 사고가 나는가
• ✅ 이 스킬이 무엇을 해주는가 (완성 이미지 포함)
• ✅ 기존 수정·기능 추가 시에는 실제 소스 코드를 읽어 정확도를 높이는 메커니즘
• ✅ 무엇을 인풋(Input)해야 하는가
• ✅ Claude Code / Claude.ai에서의 도입 절차
• ✅ 실제 대화의 흐름 (재촉해도 대충된 숫자를 내놓지 않는 메커니즘 포함)

그렇습니다, 괴롭습니다. 저도 계속 그랬습니다. 고통을 분해해 보면 대략 이 5가지로 수렴합니다.

요컨대, 견적의 정확도를 개인의 노력으로 지탱하고 있는 상태입니다. 이것이 가장 큰 사고의 원인입니다.

"아니, 요구사항을 제대로 읽으면 되는 거 아니냐"라고 생각하실 수도 있습니다. 저도 그렇게 생각했습니다. 하지만 요구사항은 대개 **산문(Prose)**입니다. "회원에게 알림을 보낼 수 있고, 로그인도 편하게 하고, 나중에 이용 상황도 보고 싶고..."처럼 목적과 사양, 논점이 모두 하나의 단락에 녹아 있습니다. 여기서 공수를 산출할 논점만을 매번 빠짐없이 골라내는 것은 구조적인 도움 없이는 불가능에 가까운 게임(Impossible game)입니다.

이 스킬이 하는 일은, 어질러진 요구사항을 엔지니어가 위에서부터 읽기만 해도 공수를 쌓을 수 있는 한 장의 Markdown으로 정리하는 것입니다.

핵심은 모든 항목을 동일한 순서로 고정하는 것입니다.

배경 → 만드는 것 → 논점·난점 → 공수 드라이버(Cost Driver) → 의존성

엔지니어는 "일단 논점·난점만 먼저 보고 싶다"고 생각하면 모든 항목의 해당 칸으로 바로 직행할 수 있습니다. 정확도를 "주의력"이 아닌 "구조"로 담보한다는 발상입니다. 난점이나 의존성을 산문에 묻어두지 않고, 독립된 칸으로서 반드시 표면으로 드러냅니다. 드러내는 것 자체가 품질을 보장하는 메커니즘이 됩니다.

백문이 불여일견입니다. 출력되는 브리프는 다음과 같은 모습입니다 (※ 모두 가상의 샘플입니다).

# 회원 앱 기능 추가 — 견적용 기술 브리프
> 출처: 이슈 티켓 #XXX (◯◯님, 2026/06/01)
> 견적 근거: 실제 코드 확인 완료 (인증 플로우·알림 주변 확인)
...

포인트는 세 가지입니다.

• 📌 가장 큰 함정이 굵은 글씨로 맨 앞에 위치함
• 📌 방식에 따라 공수가 갈리는 것은 (a)가벼운 안 / (b)무거운 안을 병기하여 "범위"를 보여줌
• 📌 미확정 사항은 묵묵히 숫자에 포함하지 않고, 말미의 「확정해야 할 전제」로 분리함

이것을 받은 엔지니어는 망설임 없이 공수를 산출할 수 있습니다.

사람이 할 경우, 항목마다 작성 방식이 들쭉날쭉합니다. 어떤 항목은 논점이 두껍고, 다른 항목은 빈약합니다. 이 스킬은 모든 항목을 고정된 템플릿으로 통일하기 때문에, 읽는 사람이 원하는 칸으로 바로 이동할 수 있습니다.

단순히 템플릿을 채우는 것만 아닙니다. 이 스킬은 **8개의 페이즈와 각 페이즈의 '통과 조건(Exit Gate)'**을 거쳐 진행됩니다. 중간에 건너뛰지 못하게 하는 구조입니다.

특히 효과적인 것이 Phase 5 → 6입니다. 논점을 다 꺼내기 전에 최종본 작성을 막는 가드(Guard) 역할을 합니다. '겉보기에는 정돈되어 있지만 최대 함정이 빠져 있는' 가장 위험한 브리프를 방지합니다.

여기서 이번에 가장 추천하고 싶은 부분입니다. 기존 시스템의 개수정이나 기능 추가라면, 요구사항의 말만으로 상상하지 않고 실제 소스 코드를 읽으러 갑니다 (Phase 4).

처음에 '이것은 신규인가요, 기존 개수정인가요? 소스를 공유해 주시면 실 코드로 확인하겠습니다'라고 물어보고, 리포지토리나 해당 파일을 전달하면, 각 항목에 대해 다음을 실 코드에서 추출합니다.

• 📂 영향 파일・개수정 포인트 (어디에 손이 들어가는가) - ♻️ 재사용 가능 여부 (기존 메커니즘을 재활용할 수 있음 = 가벼움 / 처음부터 다시 만들 것 = 무거움) - 🔗 결합도・부작용 범위 (밀접 결합・기존 제약으로 개수정이 광범위하게 미치는 함정) - 🧹 기술적 부채 (테스트 없음・밀접 결합으로 회귀 확인 공수가 추가되는 것 등)

'가볍다고 생각했는데 밀접 결합이라 대개수정', '무거울 거라고 생각했는데 기존 것을 재활용해서 순식간에 끝남'――이런 착수한 후에 밝혀져서 문제가 되는 것을, 견적 단계에서 미리 막아낼 수 있습니다. 코드를 읽을 수 없거나 (전달할 수 없다) 경우에는 요구사항 기반으로 진행하고, 브리프 초반에 '요구사항만 (코드 미접지)'라고 솔직하게 명기합니다.

미확정 전제를 가만히 숫자로 돌려 쓰지 않습니다. '이것이 결정되지 않으면 공수가 두 배로 바뀝니다'라고 Phase 7에서 반드시 외출(도출)해 줍니다. 게다가 브리프 초반의 '견적 근거'에 실 코드를 읽었는지・요구사항 기반인지 명시하므로, 읽는 사람이 견적의 신뢰도를 판단할 수 있습니다. ⚠️ 여기가 나중에 문제가 되는 것을 막아주는 생명선입니다.

긴장할 필요 없습니다. 손에 있는 어지러운 정보를 그대로 붙여넣기만 하면 됩니다.

✅ 던져도 좋은 것 (오히려 원본 상태를 권장)

• 과제 티켓의 텍스트
• 고객사로부터 온 메일・채팅 댓글 ('OO에 대응하고 싶다' 수준으로 충분함)
• 사양서・화면 안 (있다면)
• 회의록 발췌
• 기존 개수정이라면, 리포지토리 또는 해당 소스 파일 (있으면 정확도가 차원이 다름)

깔끔하게 정리할 필요는 없습니다. 정리가 AI의 역할이니까요. '이것과 이것, 그리고 구두로 들은 것' 같은 상태 그대로 붙여넣어 주세요.

도입한 후에는 평소처럼 말만 걸면 됩니다.

당신: 이 기능 견적 부탁드립니다.
(과제 티켓이나 고객사 채팅을 붙여넣기)

'견적', '개산', '공수', '스코프 정리' 같은 단어에 반응하여, 명시적으로 '브리프 만들어 줘'라고 말하지 않아도 스킬이 작동합니다.

• 무엇을 보고 견적을 짜나요? (티켓 / 사양서 / 고객사 댓글)
• 이 브리프는 누가 읽나요? (사내 엔지니어 / 협력 회사 / 발주처)
• 이번 대상 범위는 어디까지인가요?
• 이미 있는 스코프표나 설계 메모가 있나요?
• 발주처와 이미 합의된 전제가 있나요?
• 이것은 신규인가요, 기존 개수정・기능 추가인가요? (기존 개수정이라면, 소스를 공유해 주시면 실 코드로 정확도를 높일 수 있습니다)

여기에 답하면, 나머지는 거의 자동으로 진행됩니다. 기존 개수정으로 리포지토리를 전달할 수 있다면, 꼭 전달해 주세요. 견적의 신뢰도가 차원이 달라집니다.

여기서 은근히 대단한 점입니다. '이제 세세한 건 됐으니까, 빨리 숫자로 줘'라고 재촉해도, 이 스킬은 가만히 어설픈 개산치를 내놓지 않습니다.

이 전제가 미확정이라, 이대로 내면 공수가 두 배로 흔들립니다.

A) 그 전제를 확정한다 (발주처에 1점 확인)

B) 전제 조건을 명시한 위에서, 폭넓은 개산치를 낸다

어느 쪽을 선택하시겠습니까?

라는 선택지를 제시합니다. "일단 내놓고 나중에 분쟁이 생기는 상황"을 구조적으로 방지해 줍니다.

"재료는 전부 다 준비했습니다"라고 말하더라도, 첨부한 자료 안에 미정의된 참조 (Undefined Reference) (연계 대상, 대상 환경 등)가 있다면, 그 구체적인 지점을 인용하며 "이 부분이 특정되지 않았습니다"라고 지적합니다. 일반론적인 "더 있나요?"가 아니라, 근거(Evidence)를 바탕으로 질문한다는 점이 포인트입니다.

이 스킬은 Claude의 「스킬 (Skill)」 기능으로 동작합니다. Claude Code에서도 Claude.ai에서도 사용할 수 있습니다.

git clone https://github.com/enomoso-pm/estimation-tech-brief.git

내용물은 SKILL.md (본체)와 references/ (각 페이즈의 상세 내용 6개)뿐입니다. 매우 심플합니다.

~/.claude/skills/ 아래에 두기만 하면 됩니다.

mkdir -p ~/.claude/skills
cp -r estimation-tech-brief ~/.claude/skills/

그 후 Claude Code와의 대화에서 "이 기능의 견적을 부탁해"라고 말하면 스킬이 자동으로 발화합니다 (SKILL.md의 설명문에 트리거 조건이 적혀 있으므로, 명시적으로 호출하지 않아도 실행됩니다).

Claude.ai의 설정 → Capabilities / Skills에서 이 폴더를 스킬로 업로드하여 활성화합니다. 그 후 대화에서 요구사항을 붙여넣기만 하면 됩니다. 출력된 Markdown은 그대로 다운로드할 수 있습니다.

💡 Backlog나 Confluence는 표준 Markdown 형식을 지원하므로 대부분 그대로 붙여넣을 수 있습니다. PPTX로 변환하고 싶은 경우에도 변환 방법을 상담할 수 있습니다.

견적 사고는 능력의 문제라기보다 "논점을 구조적으로 포착하지 못한" 문제라고 생각합니다. 이 스킬은 그 구조를 AI에게 대신 맡기는 시도입니다.

• 📥 인풋은 어질러진 가공되지 않은 요구사항 그대로여도 OK
• 🤖 Claude Code 또는 Claude.ai에 스킬로 넣기만 하면 끝
• 🧱 8개 페이즈 + Exit Gate를 통해 논점 누락 및 사후 분쟁(炎上)을 "구조"로 방지
• 🔍 기존 코드 수정의 경우 **실제 코드를 읽고 "접지(Grounding)"**하므로 정확도가 차원이 다름
• 🙅 재촉을 받더라도 대충된 숫자를 내놓지 않으며, 미확정 사항은 솔직하게 외부로 분리함

"견적 의뢰가 올 때마다 속이 쓰리다", "엔지니어와의 커뮤니케이션 왕복 과정에서 소모된다"라고 느끼는 수탁 개발 PM·PL 분들은 꼭 한번 시도해 보세요!

🔗

clone 하여 바로 사용할 수 있습니다. 개선 PR 및 Issue도 환영합니다 🙌

끝까지 읽어주셔서 감사합니다. "우리 회사는 이런 방식으로 운영하고 있다"와 같은 이야기가 있다면 꼭 댓글로 알려주세요 ☕