하나의 프롬프트가 프로세스가 될 때: AI 스킬 내부에서 책임을 분리하는 방법

저는 개발 작업을 위한 간단한 AI 프롬프트로 시작했습니다.

그것은 역할(role), 작업(task), 출력 형식(output format), 몇 가지 제약 조건(constraints)과 같은 일반적인 요소들을 포함하고 있었습니다. 작은 작업들을 수행하기에는 그것으로 충분했습니다:

• 이 함수를 리뷰하세요;
• 이 에러를 설명하세요;
• 계획을 제안하세요;
• 이 노트를 정리하세요.

그러다 작업들이 실제 엔지니어링 작업에 가까워졌습니다.

한 가지 짧은 요청이 프롬프트의 형태를 바꾸어 놓았습니다:

머지(merge) 전 이 풀 리퀘스트(pull request)를 리뷰하세요.

단순하게 들리겠지만, 그렇지 않습니다.

유용한 PR 리뷰를 하려면 변경 사항을 읽고, 의도를 이해하며, 누락된 컨텍스트를 파악하고, 심각한 리스크와 사소한 제안을 구분하며, 테스트를 고려하고, 개발자가 실행에 옮길 수 있는 결과를 제공해야 합니다.

저의 첫 번째 반응은 프롬프트에 규칙을 계속 추가하는 것이었습니다.

만약 AI가 너무 빨리 수정 사항으로 건너뛴다면, 작업 경계(task boundary)를 먼저 이해하라는 규칙을 추가했습니다. 만약 차단 요소(blockers)와 스타일 코멘트를 섞어서 말한다면, 우선순위 지정(prioritization)에 관한 규칙을 추가했습니다. 만약 충분한 근거 없이 확신에 찬 어조로 말한다면, 증거(evidence)에 관한 규칙을 추가했습니다. 만약 답변은 정확하지만 읽기 어렵다면, 최종 형식(final format)에 관한 규칙을 추가했습니다.

각각의 규칙은 유용했습니다. 하지만 프롬프트 자체가 문제가 되고 있었습니다.

입력 분석(input analysis), 구현 리뷰(implementation review), 아키텍처(architecture), 리스크(risk), 테스트(tests), 그리고 최종 작성(final writing)까지 모든 것이 하나의 긴 지시문 안에 살고 있었습니다. 출력물은 여전히 다듬어진 것처럼 보일 수 있었지만, 실제 검증 과정은 확인하기 어려웠습니다.

그래서 저는 프롬프트를 하나의 커다란 텍스트로 취급하는 것을 멈추고, 하나의 작은 프로세스(process)로 취급하기 시작했습니다.

AI 스킬(AI Skill)이란 무엇인가

제가 말하는 AI 스킬이란 한 종류의 작업을 위한 반복 가능한 AI 워크플로우(workflow)를 의미합니다.

이것은 Codex 스킬, 커스텀 어시스턴트(custom assistant), 시스템 프롬프트(system prompt), 리포지토리 규칙(repository rules), 또는 다른 메커니즘이 될 수 있습니다. 도구 자체보다는 패턴이 더 중요합니다. 즉, 사용자가 반복되는 종류의 작업을 가져오면 AI가 이를 예측 가능한 방식으로 처리하는 것입니다.

예시:

• 풀 리퀘스트(pull request) 리뷰;
• 버그 트리아지(triage);
• 안전한 수정 계획 준비;
• 릴리스 목록(release list) 확인;
• 인수인계를 위한 긴 작업 요약;
• 기술 문서(technical documentation) 정리.

아주 작은 작업의 경우, 짧은 프롬프트(prompt)로도 충분한 경우가 많습니다.

하지만 반복되는 개발자 업무의 경우, 프롬프트가 더 많은 책임을 지게 됩니다.
무엇이 입력(input)으로 간주되는지, 무엇이 리스크(risk)인지, 무엇이 테스트(test)를 필요로 하는지, 무엇이 작업을 차단(block)할 수 있는지, 그리고 최종 답변이 인간의 의사결정을 어떻게 도와야 하는지를 알아야 합니다.

저의 해결책은 동일한 스킬(skill) 내부에서 이러한 책임들을 분리하는 것이었습니다.

사용자는 여전히 하나의 AI 스킬과 대화하고 하나의 답변을 받습니다. 하지만 스킬 내부에서 작업은 여러 종류의 업무로 처리됩니다.

거대한 프롬프트의 문제점

거대한 프롬프트는 종종 합리적인 수정 사항들로부터 커지기 마련입니다.

AI가 컨텍스트(context)를 놓치면 컨텍스트 규칙을 추가합니다. AI가 리스크를 무시하면 리스크 규칙을 추가합니다. AI가 모호한 조언을 작성하면 출력(output) 규칙을 추가합니다. AI가 테스트를 잊어버리면 검증(verification) 규칙을 추가합니다.

시간이 흐른 뒤, 프롬프트에는 많은 좋은 규칙들이 포함되지만, AI는 여전히 그 모든 규칙을 한꺼번에 사용해야 합니다.

코드 리뷰(code review)의 경우, 이는 단 한 번의 패스(pass)로 다음 사항들을 수행할 것을 기대한다는 의미입니다:

• 디프(diff) 읽기;
• 의도(intent) 추론;
• 누락된 정보 감지;
• 구현(implementation) 이해;
• 가능한 사용자 영향 확인;
• 권한, 데이터, 호환성 및 실패 경로(failure paths)에 대한 고려;
• 머지(merge)를 차단하는 요소 결정;
• 테스트 제안;
• 명확한 리뷰 작성.

이는 하나의 매끄러운 답변 뒤에 숨기기에는 너무나 많은 작업입니다.

리뷰가 합리적으로 들릴 수는 있지만, 개발자는 여전히 다음과 같은 질문을 던져야 합니다:

• 어떤 코멘트가 차단 요소(blocker)인가?
• 어떤 것이 제안(suggestion)인가?
• AI가 무엇을 사실(fact)로 취급했는가?
• 무엇이 단지 가정(assumption)인가?
• 머지 전에 무엇을 테스트해야 하는가?
• 결론이 실행에 옮길 만큼 충분히 강력한가?

이러한 질문들이 구조적으로 보이지 않을 때, AI 답변은 엔지니어링 도구로서의 유용성이 떨어지게 됩니다.

책임의 분리

저는 동일한 AI 스킬 내부에서 작업을 책임(responsibilities) 단위로 분리하기 시작했습니다.

정확한 명칭은 중요하지 않습니다. 개발자 작업의 경우, 분리는 대개 다음과 같은 형태를 띱니다:

책임 (Responsibility)	확인 사항 (What It Checks)
입력 수용 (Input intake)	무엇이 제공되었는지, 무엇이 누락되었는지, 그리고 무엇을 가정할 수 없는지
...

이것은 여전히 하나의 스킬 (skill)입니다. 사용자가 여섯 개의 별도 보고서를 읽어야 할 필요는 없습니다.

핵심은 내부 작업을 더 명확하게 만드는 것입니다. 최종 답변은 짧게 유지될 수 있지만, 이러한 점검들의 결과물인 '알려진 사실', '위험 요소', '의사결정을 가로막는 요소', '검증이 필요한 요소', 그리고 '기다려도 되는 요소'를 담고 있어야 합니다.

Pull Request 리뷰 예시

취약한 AI 리뷰는 다음과 같을 수 있습니다:

- 이 변수의 이름을 변경하는 것을 고려해보세요.
- 테스트를 추가하면 좋을 것 같습니다.
- 권한 처리를 확인하세요.
...

각 줄은 그럴듯합니다. 하지만 이들을 합쳐놓으면 큰 도움이 되지 않습니다.

스타일 관련 코멘트, 누락된 테스트, 발생 가능한 권한 문제, 그리고 가독성 관련 메모는 모두 동일한 비중을 가집니다. Pull Request (PR) 작성자는 머지 (merge) 전에 무엇이 중요한지 여전히 직접 결정해야 합니다.

책임을 분리하면, 동일한 리뷰가 훨씬 더 실용적으로 변할 수 있습니다.

입력 수용 (Input intake) 단계는 AI가 diff, 작업 설명, 그리고 제약 사항들을 모두 갖추었는지 확인합니다. 구현 리뷰 (implementation review)는 변경 사항이 실제 문제를 해결하는지 확인합니다. 리스크 리뷰 (risk review)는 작은 변경이 사용자, 데이터, 권한 또는 호환성에 영향을 미칠 수 있는 사례를 찾아냅니다. 품질 점검 (quality check)은 결론을 어떻게 검증할 수 있는지 묻습니다.

최종 답변은 다음과 같은 형태가 될 수 있습니다:

차단 요소 (Blockers):
- 권한 인증 실패 후, 코드가 캐시된 결과를 반환할 수 있습니다. 이는 현재 사용자에게 오래되었거나 권한이 없는 데이터를 보여줄 수 있습니다.
...

가치는 답변을 길게 만드는 것이 아니라, 순서(order)에서 나옵니다.

중요한 이슈는 명확한 위치를 갖게 됩니다. 질문은 권장 사항과 분리됩니다. 제안 사항이 차단 요소를 숨기지 않습니다. 결론은 리뷰가 어떤 의사결정을 지지하는지 개발자에게 알려줍니다.

버그 트리아지 (Bug Triage)를 위한 동일한 패턴

요청이 다음과 같을 때도 동일한 분리가 도움이 됩니다:

여기에 에러가 있습니다. 수정하세요.

AI는 종종 즉시 관련이 있어 보이는 파일로 점프하여 패치 (patch)를 제안하고 싶어 합니다. 이는 명백한 문제의 경우에는 유용할 수 있습니다. 하지만 실제 버그의 경우, 유용한 작업은 종종 그보다 한 단계 앞선 지점에서 시작됩니다.

입력 수집 (Input intake)은 사실과 추측을 분리합니다:

• 정확히 어떤 일이 발생했는가?
• 스택 트레이스 (stack trace)가 있는가?
• 문제를 재현 (reproduce)할 수 있는가?
• 어떤 환경과 버전이 연관되어 있는가?
• 이미 확인된 사항은 무엇인가?

구현 검토 (Implementation review)는 원인이 될 법한 영역을 찾습니다.

실행 계획 (Action planning)은 버그를 광범위한 리팩터링 (refactor)으로 만드는 대신, 코드 내에서 작은 경로를 선택합니다.

리스크 검토 (Risk review)는 수정 사항이 데이터, 권한, 마이그레이션 (migrations), 공개 API (public APIs), 백그라운드 작업 (background jobs) 또는 프로덕션 동작에 영향을 미치는지 묻습니다.

품질 확인 (Quality check)은 수정을 어떻게 증명할지 묻습니다:

• 변경 전 실패하는 테스트;
• 변경 후 통과하는 동일한 테스트;
• 재현 명령 (reproduction command);
• 수동 확인 (manual check);
• 검증할 수 없었던 사항에 대한 명확한 기록.

최종 답변은 간결하게 유지될 수 있습니다. 답변은 개발자에게 원인, 변경 사항, 검증 방법, 그리고 남아있는 리스크를 알려주어야 합니다.

이것은 숙련된 엔지니어가 보통 머릿속에 담아두는 부분입니다. 스킬 (skill)은 단지 AI가 따를 수 있을 만큼 이를 명시적으로 만들어 줄 뿐입니다.

이것이 도움이 되는 이유

첫 번째 이점은 숨겨진 가정이 줄어든다는 것입니다.

스킬에 입력 단계가 있으면, 확신에 찬 답변을 작성하기 전에 무엇이 누락되었는지 말할 가능성이 더 높습니다. 이는 코드 리뷰 (code review)와 버그 분류 (bug triage)에서 중요한데, 확신에 찬 추측은 솔직한 질문보다 더 많은 시간을 낭비할 수 있기 때문입니다.

두 번째 이점은 더 나은 우선순위 지정입니다.

유용한 검토는 가능한 개선 사항의 목록 그 이상입니다. 그것은 개발자에게 무엇이 의사결정을 가로막고 있는지, 무엇이 답변을 필요로 하는지, 그리고 무엇이 단순한 제안인지 알려줍니다.

세 번째 이점은 스킬 자체를 개선하기가 더 쉽다는 것입니다.

만약 모든 규칙이 하나의 거대한 프롬프트 (prompt)에 들어 있다면, 무엇이 실패했는지 파악하기 어렵습니다. AI가 입력 경계 (input boundary)를 놓쳤나요? 리스크를 놓쳤나요? 증거를 요청하는 데 실패했나요? 아니면 나쁜 형식으로 좋은 기술적 답변을 작성했나요?

책임이 분리되어 있다면, 다음 수정(edit)은 더 정밀한 타겟팅이 가능합니다.

만약 AI가 누락된 사실을 지어낸다면, 입력 수집(input intake) 단계를 개선하십시오. 만약 권한 리스크(permission risks)를 놓친다면, 리스크 검토(risk review) 단계를 개선하십시오. 만약 길고 초점이 맞지 않는 답변을 내놓는다면, 최종 편집(final editing) 단계를 개선하십시오. 스킬은 실제로 실패하는 지점에서 성장할 수 있습니다.

사용 사례

저는 답변이 의사결정을 뒷받침해야 하는 다음과 같은 작업들에 이 구조를 사용할 것입니다:

• 풀 리퀘스트(pull request) 병합 또는 보류;
• 공개 API(public API) 변경;
• 원인이 불분명한 버그 수정;
• 릴리스 체크(release check) 준비;
• 사용자 데이터 또는 권한 처리;
• 긴 작업을 다른 세션이나 사람에게 인계;
• 게시될 자료 검토.

작은 요청의 경우, 이 구조는 불필요한 무게(extra weight)가 됩니다.

Git 명령어가 필요하거나, 컴파일러 에러에 대한 빠른 설명, 혹은 작은 코드 예제가 필요한 경우, 전체 검토 프로세스는 오히려 방해가 됩니다. 스킬은 작업의 무게에 맞게 설계되어야 합니다.

반대 방향의 실패 모드도 존재합니다: 서로 중복되는 역할들입니다. 만약 모든 책임(responsibility)이 똑같은 말을 하고 있다면, 그 결과는 그저 노이즈(noise)일 뿐입니다. 각 책임은 서로 다른 종류의 문제를 포착하거나, 서로 다른 결정을 내려야 합니다.

공개 데모

이 아이디어를 보여주기 위해 작은 공개 저장소(public repository)를 만들었습니다:

이것은 코드 리뷰를 위한 텍스트 기반 데모 스킬입니다. SKILL.md로 시작하여 샘플 리뷰 출력물을 살펴보십시오.

저장소는 의도적으로 작게 구성되었습니다. 이는 입력 검토(review input), 구현(implementation), 리스크(risk), 품질(quality), 그리고 최종 답변(final answer)이라는 구조를 보여줍니다. 특정 프로세스를 그대로 복사하지 않고도, 동일한 패턴을 여러분만의 리뷰 워크플로우에 맞게 조정할 수 있습니다.

이를 통해 얻은 교훈

유용한 변화는 간단했습니다: 하나의 완벽한 프롬프트가 모든 규칙을 한곳에 담으려고 시도하는 것을 멈추는 것입니다.

개발자 작업의 경우, AI 스킬이 가시적인 규율(discipline)을 갖추고 있을 때 더 신뢰하기 쉬워집니다. AI는 자신이 어떤 입력을 받았는지, 무엇이 여전히 누락되었는지, 리스크가 어디에 있는지, 무엇을 검증해야 하는지, 그리고 최종 답변이 어떤 의사결정을 뒷받침하는지를 알고 있어야 합니다.

사용자는 여전히 의사결정권을 가집니다. AI는 여전히 실수를 합니다. 하지만 작업 과정은 덜 불투명해집니다.

저에게 있어, 이것이 많은 실용적인 AI 스킬 (AI skills)이 나아가고 있는 방향입니다. 즉, 하나의 긴 프롬프트 (long prompt)에서 벗어나, 하나의 도구 내부에서 명확한 책임 관계를 가진 작은 프로세스 (small process)로 나아가는 것입니다.