AI에게 역할과 이름을 부여하기
Source: Dev.to
위에 제공된 소스 링크만 포함되어 있어 번역할 본문이 없습니다. 번역을 원하는 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.
불안정성 문제
AI에게 같은 질문을 두 번 물어보세요. 서로 다른 답변을 얻게 됩니다.
틀린 답변이 아니라—그저 일관성이 없습니다. 강조점이 다르고, 구조가 다르고, 깊이가 다릅니다. AI는 고정점이 없어서 떠다닙니다.
이는 결함이 아니라 범용 시스템의 특징입니다. AI는 관련성이 있어 보이는 방향으로 도움을 주려고 합니다. 제약이 없으면 “관련성”은 매 상호작용마다 달라집니다.
다재다능함의 대가가 예측 불가능성입니다.
목적의 안정화 효과
| 프롬프트 | 출력 경향 |
|---|---|
| “이 코드를 검토하세요” | 다양함: 스타일, 보안, 성능, 모두 혼합 |
| “보안 검토자로서 이 코드를 검토하세요” | 일관됨: 보안 문제에 초점을 맞춤 |
역할은 가능성 공간을 제한합니다. AI는 모든 것이 되려고 하던 것을 멈추고 구체적인 무언가가 되기 시작합니다.
이는 AI를 제한하는 것이 아니라—AI를 집중시키는 것입니다.
라벨 없음 vs. 라벨 있음: 차이점
| 항목 | 라벨 없음 | 역할 포함 |
|---|---|---|
| 출력 일관성 | 낮음 — 세션마다 다름 | 높음 — 목적에 고정됨 |
| 관련성 | 흩어짐 — 모든 것을 다루려 함 | 집중됨 — 역할별 관심사를 다룸 |
| 품질 | 예측 불가 — 때로는 깊고 때로는 얕음 | 예측 가능 — 범위 내 일관된 깊이 |
| 협업 | 매번 새로운 사람과 작업하는 느낌 | 알고 있는 전문가와 작업하는 느낌 |
라벨은 지식을 추가하지 않습니다. 방향을 추가합니다.
AI는 전능하지 않다
불편한 진실: 하나의 AI 역할만으로 모든 문제를 해결할 수 없습니다.
- 구현은 검토와 다른 사고방식이 필요합니다.
- 테스트는 설계와 다른 초점이 필요합니다.
- 문서는 디버깅과 다른 기술이 필요합니다.
“일반 어시스턴트”는 이 모든 것을 시도할 수 있습니다. 전문가(전문가)는 하나에 뛰어납니다.
다재다능함과 탁월함은 상충합니다. 각 분야에서 탁월함을 선택하세요.
다중 역할 솔루션
| Role | Focus |
|---|---|
| 구현 전문가 | 프로덕션 코드 작성 |
| 테스트 설계자 | 테스트 전략 및 케이스 생성 |
| 검토자 | 코드를 기준에 따라 평가 |
| 환경 전문가 | 인프라, 배포, 운영 |
| 문서 작성자 | 사용자를 위한 명확한 커뮤니케이션 |
각 역할은:
- 정의된 범위 (처리하는 내용)
- 정의된 관점 (문제에 접근하는 방식)
- 일관된 행동 (예측 가능한 출력)
당신은 여러 AI를 만드는 것이 아니라, AI가 작동하는 여러 렌즈를 만드는 것입니다.
역할이 부족할 때
옵션 1: 새 역할 만들기
격차가 범주적일 때—다루어지지 않은 작업 유형.
예시: 구현 및 테스트 역할은 있지만 진행 상황을 관리하고 조정할 사람이 필요합니다. 프로젝트 관리 역할을 만들세요.
옵션 2: 기존 역할 심화
격차가 구체성일 때—역할은 존재하지만 세부 사항이 부족합니다.
예시: “검토자” 역할이 문제를 잡아내지만 특정 아키텍처 패턴을 놓칩니다. 역할 정의에 아키텍처 지식을 추가하세요.
| 신호 | 응답 |
|---|---|
| “다른 종류의 작업이 필요합니다” | 새 역할 |
| “이 작업을 더 많은 맥락에서 수행해야 합니다” | 기존 역할 심화 |
이름 효과
이름은 단순한 라벨이 아닙니다. 그것은 정체성 앵커입니다.
역할을 “Implementation AI” 대신 “Naruse”라고 이름 붙이면 무언가가 변합니다:
- 역할을 일관되게 지칭합니다.
- 역할이 인식 가능한 패턴을 형성합니다.
- 협업이 거래적 느낌보다 덜합니다.
- “팀”이 구체적으로 느껴집니다.
이것은 심리적인 것이며, 기술적인 것이 아닙니다. 하지만 심리학은 작업 방식에 영향을 미칩니다. 이름이 붙은 팀원은 도구에게는 설명하기 번거로운 맥락을 제공합니다.
역할 정의 구조
유용한 역할 정의에는 다음이 포함됩니다:
[Name]: [Title]
Scope
이 역할이 담당하는 내용. 명시적으로 담당하지 않는 내용.
Perspective
이 역할이 문제에 접근하는 방식. 우선순위.
Standards
이 역할이 적용하는 품질 기준.
Boundaries
에스컬레이션 시점. 다른 역할에 위임해야 할 시점.
The more specific the definition, the more stable the output.
안정성의 보상
정의된 역할과 함께:
| 이전 | 이후 |
|---|---|
| “이번엔 AI가 뭐라고 할까?” | “이번엔 나루세가 뭐라고 할까?” |
| 상호작용마다 기대치를 조정한다 | 기대할 것을 알다 |
| 반복 프롬프트로 드리프트에 맞선다 | 역할에 안정성을 내재한다 |
| 하나의 AI가 모든 일을 적절히 수행한다 | 여러 전문가가 각자의 역할을 뛰어나게 수행한다 |
역할은 AI를 제한하지 않는다. 일관된 탁월함을 열어준다.
이 내용은 “프롬프트 엔지니어링을 넘어” 시리즈의 일부로, 구조적·문화적 접근이 AI‑지원 개발에서 프롬프트 최적화를 능가하는 방식을 탐구한다.