기술이 실행되기 전에 누가 말하는지 파악하세요

요약(TL;DR): 누구의 관점이 실행을 주도하는지 알 수 있도록, 모든 기술(skill) 파일의 최상단에 명확한 역할을 항상 정의하세요.

흔한 실수 ❌

규칙으로 가득 찬 기술을 작성하지만, 역할을 할당하지 않습니다.

AI는 자신이 주니어 개발자인지, 숙련된 아키텍트(Architect)인지, 아니면 QA 엔지니어(QA Engineer)인지 모르는 상태에서 실행을 시작합니다.

그 결과, 답변이 일반적이거나 권위가 부족하거나, 실행할 때마다 관점이 바뀌는 느낌을 받게 됩니다.

해결되는 문제들 😔

• AI가 무작위적인 목소리를 선택하여, 세션마다 출력이 예측 불가능하게 달라집니다.
• 누구의 판단이 적용되는지 알 수 없기 때문에 기술을 감사(Audit)할 수 없습니다.
• AI가 단일 실행 내에서 톤(Tone)과 전문성 수준을 혼합합니다.
• 각 기술이 서로 다른 암묵적 페르소나(Persona)를 가정하기 때문에 기술 체이닝(Skill chaining)이 깨집니다.
• 책임 소재를 잃게 됩니다: 누가 출력을 승인했는지 아무도 모르게 됩니다.

방법 🛠️

1. 기술 파일을 열고 가장 첫 번째 지침으로 역할 선언(Role declaration)을 추가합니다.
2. 다른 어떤 규칙보다 먼저 "당신은 [도메인(Domain)] 분야의 전문성을 가진 [역할(Role)]입니다"라고 작성합니다.
3. 해당 역할의 제약 사항과 책임을 설명하는 문장을 한두 문장 추가합니다.
4. 파일 내의 이어지는 모든 지침을 통해 페르소나를 일관되게 유지합니다.
5. 기술을 체이닝(Chain skills)할 때, 각 기술이 자신의 페르소나를 명시적으로 선언하는지 확인합니다.

이점 🎯

1. 일관된 목소리 (Consistent voice): AI가 매 실행마다 동일한 전문성 수준에서 실행되므로, 출력이 예측 가능해집니다.

2. 감사 가능한 출력 (Auditable output): 누구의 관점에서 결과가 생성되었는지 알 수 있으므로, 리뷰가 더 빨라집니다.

3. 더 나은 보정 (Better calibration): 자신이 시니어 리뷰어임을 아는 AI는 역할이 없는 AI보다 더 어려운 질문을 던집니다.

4. 안전한 체이닝 (Safe chaining): 기술(Skill)을 체이닝할 때, 각 기술은 추측하는 대신 선언된 정체성으로부터 발언합니다.

5. 더 빠른 디버깅 (Faster debugging): 기술이 잘못된 답을 내놓을 때, 누구의 관점을 의심해야 하는지 알 수 있습니다.

문맥 (Context) 🧠

페르소나가 없는 기술은 지휘관이 없는 명령과 같습니다.

파일의 모든 지침을 읽더라도 누가 무엇을 말하는지, 혹은 왜 말하는지 알 수 없을 수 있습니다.

역할을 선언하면 AI에게 안정적인 참조 프레임 (stable frame of reference)을 제공하게 됩니다.

AI는 추측을 멈추고 특정 관점에서 실행을 시작합니다.

이는 또한 기술을 설계하는 데 도움이 됩니다. AI가 "엄격한 코드 리뷰어"라는 것을 안다면, 어떤 규칙을 포함하고 어떤 규칙을 제외해야 할지 알 수 있습니다.

분석이 아닌 분석가를 요청할 때, 여러분은 이미 프롬프트 수준에서 이 아이디어를 적용하고 있는 것입니다.

기술은 이를 한 단계 더 발전시킵니다. 매번 반복할 필요가 없도록 정의 안에 역할을 구워 넣는(bake) 것입니다.

또한 모든 기술을 함정 파일(pitfalls file)과 쌍을 이룰 수도 있어, 페르소나가 절대 해서는 안 될 행동을 정의할 수 있습니다.

프롬프트 참조 (Prompt Reference) 📝

나쁜 프롬프트 (Bad Prompt) 🚫

---
name: technosignature-analyzer
version: 1.0.0
...

좋은 프롬프트 (Good Prompt) 👉

---
name: technosignature-analyzer
version: 1.0.0
...

고려 사항 (Considerations) ⚠️

페르소나(Persona) 선언은 짧게 유지하세요: 최대 한 문장에서 세 문장 이내로 작성합니다.

긴 페르소나 설명은 노이즈를 추가하고 실제 기술 규칙을 희석시킵니다.

"당신은 코딩하는 마법사입니다"와 같은 허구의 페르소나를 만들어내지 마세요.

실제 전문적인 역할(Professional roles)을 사용하세요.

페르소나가 기술의 도메인(Domain)과 일치할 때 AI는 최상의 성능을 발휘합니다.

유형 (Type) 📝

[X] 반자동 (Semi-Automatic)

제한 사항 (Limitations) ⚠️

AI는 당신이 할당한 페르소나를 강제하는 것이 아니라, 이를 컨텍스트 (Context)로 채택합니다.

만약 지침이 페르소나와 모순되면, AI는 두 가지를 혼합하여 일관성 없는 출력을 생성할 수 있습니다.

태그 (Tags) 🏷️

• 지식 관리 (Knowledge Management)

레벨 (Level) 🔋

[X] 초급 (Beginner)

관련 팁 (Related Tips) 🔗

AI 코딩 팁 004 - 모듈형 기술 사용하기 (Use Modular Skills)

Maxi Contieri

Maxi Contieri

Maxi Contieri

팔로우 (Follow)

1월 27일

AI 코딩 팁 004 - 모듈형 기술 사용하기 (Use Modular Skills)

#ai #webdev #programming #beginners

3개 반응댓글 추가 (Add Comment)

읽는 시간 4분

AI 코딩 팁 006 - 커밋 전 모든 라인 검토하기 (Review Every Line Before Commit)

Maxi Contieri

Maxi Contieri

Maxi Contieri

팔로우 (Follow)

2월 13일

AI 코딩 팁 006 - 커밋 전 모든 라인 검토하기 (Review Every Line Before Commit)

#ai #programming #development #softwaredevelopment

댓글 1개

읽는 시간 7분

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

읽는 시간 7분

AI Coding Tip 011 - Initialize Agents.md

Maxi Contieri

Maxi Contieri

Maxi Contieri

Follow

3월 18일

AI Coding Tip 011 - Initialize Agents.md

#ai #programming

1 반응댓글 추가

3분 읽기

AI Coding Tip 017 - Ask for the Analyst, Not the Analysis

Maxi Contieri

Maxi Contieri

Maxi Contieri

Follow

4월 28일

AI Coding Tip 017 - Ask for the Analyst, Not the Analysis

#ai #webdev #programming #tutorial

1 반응댓글 추가

5분 읽기

AI Coding Tip 019 - Tell the AI Why, Not Just What

Maxi Contieri

Maxi Contieri

Maxi Contieri

Follow

5월 12일

AI Coding Tip 019 - Tell the AI Why, Not Just What

#ai #coding #llm #productivity

3 reactions
3 comments

4분 분량

AI Coding Tip 025 - 모든 기술에 실패 사례(Pitfalls) 파일을 연결하세요

Maxi Contieri

Maxi Contieri

Maxi Contieri

팔로우

23년 6월

AI Coding Tip 025 - 모든 기술에 실패 사례(Pitfalls) 파일을 연결하세요

#ai #webdev #programming #tutorial

2 reactions1 comment

5분 분량

결론 🏁

페르소나가 없는 기술은 지휘관이 없는 명령과 같습니다.

누가 그것을 만들었는지 알면 항상 결과물을 더 잘 이해하게 됩니다.

먼저 역할을 부여하세요.

매번요.