RLHF로 학습된 코딩 모델 완벽 활용 가이드

ChatGPT, Claude, Gemini 같은 RLHF 기반 코딩 모델들의 차이를 비교하고, 프롬프트 엔지니어링으로 원하는 코드를 정확하게 생성하는 실전 노하우를 배웁니다. 초급 개발자도 실무에서 바로 활용할 수 있는 구체적인 실습 가이드를 제공합니다.

GPT-4, Claude, Gemini 코딩 능력 비교
Instruction Following으로 정확한 코드 생성
System 프롬프트로 코딩 스타일 지정
Few-shot으로 코드 패턴 학습시키기
실습: 3개 모델로 같은 과제 비교 실험
문서화 (주석, 독스트링)
실습: 나만의 코딩 스타일 시스템 프롬프트 작성

1. GPT-4, Claude, Gemini 코딩 능력 비교

김개발 씨는 오늘도 AI 코딩 어시스턴트에게 코드를 요청했습니다. 같은 질문인데 ChatGPT와 Claude가 완전히 다른 코드를 내놓았습니다.

"도대체 어느 모델을 써야 할까?" 팀장님은 웃으며 말했습니다. "각 모델의 특성을 알아야 제대로 활용할 수 있지."

RLHF로 학습된 코딩 모델들은 각자 고유한 강점을 가지고 있습니다. GPT-4는 광범위한 지식과 창의적인 솔루션에 강하고, Claude는 긴 컨텍스트 이해와 안전한 코드 생성에 뛰어나며, Gemini는 최신 정보 반영과 멀티모달 처리에 특화되어 있습니다.

모델별 특성을 이해하면 상황에 맞는 최적의 도구를 선택할 수 있습니다.

다음 코드를 살펴봅시다.

# 세 모델에게 같은 작업 요청 예시
prompt = """
사용자 인증 API를 FastAPI로 작성해주세요.
JWT 토큰 발급, 검증 포함
"""

# GPT-4 응답 특징: 완전한 구현 + 추가 기능 제안
# Claude 응답 특징: 단계별 설명 + 보안 중점
# Gemini 응답 특징: 최신 라이브러리 + 간결한 구조

# 실제 비교를 위한 평가 항목
evaluation_criteria = {
    "code_quality": 0,      # 코드 품질
    "explanation": 0,       # 설명 상세도
    "security": 0,          # 보안 고려사항
    "completeness": 0       # 완성도
}

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 AI 코딩 도구 라이선스를 구매하기로 했는데, 어떤 모델을 선택할지 고민이 깊어졌습니다.

ChatGPT Plus, Claude Pro, Gemini Advanced 중 무엇을 써야 할까요? 팀장 박시니어 씨가 회의실로 불러 말했습니다.

"김개발 씨, 각 모델의 특성을 제대로 비교해보고 보고서를 작성해주세요. 우리 팀에 가장 적합한 도구를 골라야 하니까요." RLHF란 무엇일까요? 먼저 RLHF가 무엇인지 이해해야 합니다.

RLHF는 Reinforcement Learning from Human Feedback의 약자입니다. 쉽게 비유하자면, 선생님이 학생의 답안을 채점하며 가르치는 것과 같습니다.

AI가 코드를 생성하면 인간 전문가들이 평가하고, 그 피드백으로 모델이 점점 더 나은 코드를 작성하도록 학습됩니다. 이 방식 덕분에 최신 LLM들은 단순히 문법적으로 맞는 코드를 넘어서, 실무에서 선호하는 스타일과 패턴을 익힐 수 있게 되었습니다.

GPT-4의 강점은 무엇일까요? 김개발 씨는 먼저 GPT-4를 테스트해봤습니다. "사용자 인증 시스템을 만들어주세요"라고 요청했더니, GPT-4는 JWT 토큰 발급뿐만 아니라 리프레시 토큰, 비밀번호 해싱, 이메일 인증까지 포함한 완전한 시스템을 제안했습니다.

GPT-4의 가장 큰 장점은 광범위한 지식 베이스입니다. 다양한 프로그래밍 언어와 프레임워크에 대해 깊은 이해를 가지고 있으며, 복잡한 아키텍처 설계도 잘 제안합니다.

특히 창의적인 문제 해결이 필요할 때 빛을 발합니다. 하지만 때로는 과하게 복잡한 솔루션을 제안하기도 합니다.

간단한 기능만 필요한데 엔터프라이즈급 시스템을 설계해버릴 수 있습니다. Claude는 어떤 특징이 있을까요? 다음으로 Claude를 테스트했습니다.

같은 질문을 던졌더니, Claude는 단계별로 매우 상세한 설명과 함께 코드를 제공했습니다. 특히 인상적이었던 것은 보안 취약점에 대한 경고였습니다.

"SQL Injection을 방지하기 위해 ORM을 사용하세요", "비밀번호는 반드시 bcrypt로 해싱하세요", "환경변수로 시크릿 키를 관리하세요" 등 실무에서 꼭 필요한 보안 가이드를 자세히 알려줬습니다. Claude의 강점은 긴 컨텍스트 이해와 안전성입니다.

최대 200K 토큰까지 처리할 수 있어서 대규모 코드베이스를 분석할 때 유리합니다. 또한 잠재적인 보안 문제나 버그를 미리 짚어주는 경향이 있습니다.

Gemini는 무엇이 다를까요? 마지막으로 Gemini를 테스트했습니다. Gemini는 가장 최신 라이브러리와 베스트 프랙티스를 반영한 코드를 제공했습니다.

2024년에 출시된 라이브러리 버전까지 정확하게 반영했습니다. Gemini의 특징은 최신 정보 반영과 멀티모달 능력입니다.

이미지를 업로드하면 UI를 분석해서 코드로 변환해주는 기능이 매우 강력합니다. 또한 Google 검색과 연동되어 최신 문서와 업데이트를 빠르게 반영합니다.

실제 비교 결과는? 김개발 씨는 3일간 세 모델을 집중적으로 테스트했습니다. REST API 개발, 데이터베이스 쿼리 최적화, 프론트엔드 컴포넌트 작성 등 다양한 작업을 시켰습니다.

결과는 흥미로웠습니다. 복잡한 알고리즘이나 새로운 아키텍처 설계가 필요할 때는 GPT-4가 가장 우수했습니다.

레거시 코드 리팩토링이나 보안이 중요한 작업에서는 Claude가 뛰어났습니다. 최신 프레임워크를 사용하거나 UI 디자인을 코드로 변환할 때는 Gemini가 최고였습니다.

어떤 모델을 선택해야 할까요? 박시니어 팀장은 보고서를 읽고 고개를 끄덕였습니다. "좋은 분석이네요.

그런데 김개발 씨, 우리가 꼭 하나만 선택할 필요는 없어요." 실제로 많은 개발 팀들은 상황에 따라 여러 모델을 함께 사용합니다. 설계 단계에서는 GPT-4로 브레인스토밍하고, 구현 단계에서는 Claude로 안전한 코드를 작성하고, 최신 라이브러리 정보가 필요할 때는 Gemini를 참고하는 식입니다.

비용 대비 효율은? 물론 예산도 중요합니다. GPT-4는 가장 비싸지만 가장 범용적입니다.

Claude는 중간 가격대에 긴 컨텍스트를 제공합니다. Gemini는 상대적으로 저렴하면서도 Google Workspace와의 통합이 뛰어납니다.

김개발 씨의 팀은 결국 GPT-4를 메인으로, Claude를 코드 리뷰용으로 구독하기로 결정했습니다. 각 모델의 장점을 이해하고 적재적소에 활용하는 것이 가장 현명한 선택이었습니다.

실전 팁

💡 - 복잡한 문제 해결이 필요하면 GPT-4, 보안이 중요하면 Claude, 최신 정보가 필요하면 Gemini를 우선 고려하세요

한 모델의 답변이 만족스럽지 않다면 다른 모델에게 같은 질문을 던져보세요. 서로 다른 관점의 솔루션을 얻을 수 있습니다
긴 코드를 분석할 때는 Claude의 200K 컨텍스트 윈도우를 활용하세요

2. Instruction Following으로 정확한 코드 생성

이상한 일이 벌어졌습니다. 김개발 씨가 "로그인 기능 만들어줘"라고 요청했더니 AI가 회원가입까지 만들어버렸습니다.

반대로 선배 박시니어 씨가 같은 작업을 요청하니 딱 필요한 코드만 깔끔하게 나왔습니다. "프롬프트를 어떻게 작성하느냐에 따라 천지 차이예요."

Instruction Following은 AI가 사용자의 지시사항을 정확하게 따르는 능력입니다. RLHF 학습 과정에서 모델은 명확한 지시를 따르는 훈련을 집중적으로 받았습니다.

구체적이고 명확한 지시를 내릴수록 원하는 결과를 얻을 확률이 높아집니다. 프롬프트 작성 기술이 곧 코드 품질을 결정합니다.

다음 코드를 살펴봅시다.

# 나쁜 예시: 모호한 지시
bad_prompt = "로그인 기능 만들어줘"

# 좋은 예시: 구체적인 지시
good_prompt = """
FastAPI로 로그인 API를 작성해주세요.
요구사항:
- POST /login 엔드포인트만 작성
- 입력: email, password (JSON)
- 출력: access_token (JWT)
- 비밀번호 검증은 bcrypt 사용
- 토큰 만료시간 30분
- 에러 처리 포함
- 타입 힌트 필수
"""

# 더 나은 예시: 예상 출력 형식까지 명시
best_prompt = good_prompt + """
응답 형식:
{
    "access_token": "eyJ...",
    "token_type": "bearer"
}
"""

김개발 씨는 AI 코딩 도구를 쓰기 시작한 지 일주일이 되었습니다. 하지만 만족스러운 코드를 얻기가 쉽지 않았습니다.

"장바구니 기능 만들어줘"라고 하면 너무 복잡한 코드가 나오고, "간단하게 해줘"라고 하면 이번엔 너무 단순했습니다. 옆자리 박시니어 선배는 같은 AI를 쓰는데 항상 딱 맞는 코드를 받아냈습니다.

도대체 무슨 차이일까요? 명령을 따르는 능력, Instruction Following 비밀은 바로 Instruction Following 능력을 제대로 활용하는 것이었습니다.

RLHF로 훈련된 최신 코딩 모델들은 사용자의 지시사항을 정확하게 따르도록 특별히 학습되었습니다. 마치 레스토랑에서 주문하는 것과 같습니다.

"파스타 하나요"라고 하면 셰프가 임의로 선택한 파스타가 나옵니다. 하지만 "토마토 소스 파스타, 면은 알덴테, 마늘 빼고, 파마산 치즈 추가"라고 구체적으로 주문하면 정확히 원하는 요리가 나옵니다.

모호한 프롬프트의 문제점 김개발 씨의 실패 사례를 봅시다. "사용자 관리 시스템 만들어줘"라고 요청했더니 AI는 무려 500줄짜리 코드를 생성했습니다.

CRUD 전체, 권한 관리, 이메일 인증, 프로필 사진 업로드까지 포함되어 있었습니다. 문제는 김개발 씨가 원했던 건 단순히 사용자 목록을 조회하는 API 하나였다는 점입니다.

나머지 기능들은 이미 다른 팀원이 만들어둔 상태였습니다. 불필요한 코드를 지우고 통합하느라 오히려 시간이 더 걸렸습니다.

구체적인 지시의 힘 박시니어 선배는 어떻게 요청했을까요? 선배의 프롬프트를 훔쳐봤습니다.

"FastAPI로 사용자 목록 조회 API를 작성해주세요. GET /users 엔드포인트만 필요합니다.

페이지네이션은 limit과 offset 쿼리 파라미터로 구현하고, 각 사용자는 id, email, name만 반환하세요. SQLAlchemy ORM을 사용하고, 응답은 List[UserResponse] 타입으로 주세요." 결과는 놀라웠습니다.

딱 30줄짜리 깔끔한 코드가 나왔고, 바로 프로젝트에 통합할 수 있었습니다. 수정할 부분이 거의 없었습니다.

좋은 프롬프트의 5가지 요소 박시니어 선배가 점심시간에 노하우를 알려줬습니다. 좋은 프롬프트에는 다섯 가지 요소가 들어가야 합니다.

첫째, 기술 스택을 명시하세요. "Python으로", "FastAPI로", "SQLAlchemy 사용" 같은 구체적인 도구를 지정합니다.

둘째, 정확한 범위를 설정하세요. "전체 시스템"이 아니라 "GET /users 엔드포인트만" 같이 명확하게 범위를 좁힙니다.

셋째, 입출력 형식을 명시하세요. 어떤 파라미터를 받고, 어떤 형태로 응답할지 구체적으로 작성합니다.

넷째, 제약사항을 추가하세요. "타입 힌트 필수", "에러 처리 포함", "주석 달지 말것" 같은 세부 요구사항을 명시합니다.

다섯째, 예제를 제공하세요. 원하는 코드 스타일이나 응답 형식의 예시를 보여주면 AI가 더 정확하게 이해합니다.

단계별 지시의 효과 복잡한 작업일수록 단계별로 나누어 지시하는 것이 효과적입니다. 한 번에 "쇼핑몰 백엔드 전체"를 요청하는 대신, 먼저 "상품 모델 정의", 다음에 "상품 CRUD API", 그 다음 "장바구니 기능" 식으로 나누어 진행합니다.

김개발 씨는 이 방법을 시도해봤습니다. "먼저 User 모델을 SQLAlchemy로 정의해주세요.

id, email, hashed_password, created_at 필드만 포함하세요." 완벽한 모델이 나왔습니다. 다음 단계로 "위 User 모델을 사용해서 회원가입 API를 작성해주세요.

POST /signup 엔드포인트, 입력은 email과 password, 비밀번호는 bcrypt로 해싱하세요." 역시 정확한 코드가 생성되었습니다. 부정 지시도 중요합니다 "하지 말아야 할 것"을 명시하는 것도 중요합니다.

"주석을 달지 마세요", "타입 체크 코드는 제외하세요", "예외 처리는 나중에 추가할 예정이니 생략하세요" 같은 부정 지시를 활용하세요. AI는 기본적으로 완전한 코드를 만들려고 합니다.

때로는 너무 친절해서 불필요한 부분까지 추가합니다. 명확하게 "필요없다"고 말해주면 더 깔끔한 코드를 얻을 수 있습니다.

컨텍스트 제공의 중요성 기존 코드베이스가 있다면 관련 코드를 함께 제공하세요. "우리 프로젝트는 이런 구조를 사용합니다"라며 예시 코드를 보여주면, AI가 프로젝트의 코딩 스타일을 학습해서 일관된 코드를 생성합니다.

예를 들어 "우리 팀은 이런 식으로 응답 모델을 정의합니다"라며 기존 코드를 첨부하면, 새로운 응답 모델도 같은 패턴으로 만들어집니다. 반복적 개선 한 번에 완벽한 코드가 나오지 않아도 괜찮습니다.

첫 결과물을 보고 "좋은데, 여기에 에러 처리를 추가해주세요", "타입 힌트를 더 구체적으로 해주세요" 같이 추가 지시를 내리세요. RLHF 모델들은 대화 맥락을 이해하므로, 이전 코드를 기억하고 수정해줍니다.

마치 페어 프로그래밍하듯이 점진적으로 개선할 수 있습니다. 결과의 차이 한 달 후, 김개발 씨의 생산성이 눈에 띄게 향상되었습니다.

같은 AI 도구를 쓰지만 이제는 원하는 코드를 정확하게 받아냅니다. 비결은 간단했습니다.

명확하고 구체적인 지시를 내리는 것, 그것이 전부였습니다.

실전 팁

💡 - 프롬프트에 "정확히", "오직", "반드시" 같은 강조 단어를 사용하면 AI가 지시사항을 더 엄격하게 따릅니다

코드 스타일 가이드를 프롬프트에 포함하세요. "PEP 8 준수", "함수명은 동사로 시작" 같은 규칙을 명시하면 일관된 코드를 얻습니다
원하지 않는 결과가 나오면 프롬프트를 조금씩 수정해가며 실험하세요. 어떤 표현이 효과적인지 패턴을 익히게 됩니다

3. System 프롬프트로 코딩 스타일 지정

김개발 씨는 AI가 생성한 코드를 리뷰받을 때마다 같은 지적을 받았습니다. "타입 힌트가 없네요", "독스트링을 추가하세요", "우리 팀 네이밍 규칙과 달라요".

매번 수동으로 고치기 귀찮았습니다. 박시니어 선배가 말했습니다.

"System 프롬프트를 설정해보세요. AI의 기본 행동을 바꿀 수 있어요."

System 프롬프트는 AI의 전체 대화 세션에 적용되는 기본 지시사항입니다. 마치 AI에게 "당신은 이런 성격의 개발자입니다"라고 역할을 부여하는 것과 같습니다.

코딩 스타일, 주석 작성 방식, 선호하는 라이브러리, 네이밍 규칙 등을 미리 설정해두면 모든 생성 코드가 일관된 스타일을 따르게 됩니다.

다음 코드를 살펴봅시다.

# OpenAI API를 사용한 System 프롬프트 설정 예시
import openai

system_prompt = """
당신은 Python 백엔드 전문 개발자입니다.
다음 규칙을 항상 따르세요:

코딩 스타일:
- PEP 8 스타일 가이드 준수
- 모든 함수에 타입 힌트 필수
- Google 스타일 독스트링 작성
- 변수명은 snake_case, 클래스명은 PascalCase

기술 스택:
- FastAPI 프레임워크 우선 사용
- SQLAlchemy ORM 사용
- Pydantic으로 데이터 검증
- pytest로 테스트 작성

코드 구조:
- 각 함수는 단일 책임 원칙 준수
- 매직 넘버 사용 금지, 상수로 정의
- 에러 처리는 명시적으로 작성
"""

response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": "사용자 생성 API를 만들어주세요"}
    ]
)

김개발 씨는 AI가 만들어준 코드를 PR로 올렸다가 10개의 코멘트를 받았습니다. "타입 힌트 추가", "독스트링 작성", "변수명을 우리 컨벤션에 맞게 수정" 등등.

분명 잘 동작하는 코드인데 스타일 때문에 계속 수정해야 했습니다. 점심시간에 박시니어 선배에게 하소연했습니다.

"AI한테 코드 받을 때마다 팀 컨벤션에 안 맞아서 고치느라 시간이 더 걸려요." 선배가 웃으며 답했습니다. "System 프롬프트를 써보세요.

게임 체인저예요." System 프롬프트란 무엇일까요? System 프롬프트는 AI와의 대화가 시작될 때 설정하는 기본 지시사항입니다. 일반 프롬프트가 "이 작업을 해주세요"라는 단발성 요청이라면, System 프롬프트는 "당신은 항상 이렇게 행동하세요"라는 지속적인 규칙입니다.

비유하자면 회사 입사 첫날 받는 온보딩 교육과 같습니다. "우리 회사는 이런 문화를 가지고 있고, 이런 방식으로 일합니다"라는 기본 틀을 설정하는 것입니다.

이후 모든 작업은 이 틀 안에서 진행됩니다. 왜 System 프롬프트가 중요할까요? 매번 "타입 힌트 붙여주세요", "PEP 8 따라주세요"라고 요청하는 것은 비효율적입니다.

System 프롬프트에 한 번 설정해두면 모든 대화에서 자동으로 적용됩니다. 더 중요한 것은 일관성입니다.

팀 전체가 같은 System 프롬프트를 사용하면, AI가 생성한 코드가 마치 한 사람이 작성한 것처럼 통일된 스타일을 가지게 됩니다. 실전 System 프롬프트 작성법 박시니어 선배가 팀에서 사용하는 System 프롬프트를 공유해줬습니다.

크게 네 부분으로 구성되어 있었습니다. 첫 번째는 역할 정의입니다.

"당신은 10년 경력의 Python 백엔드 개발자입니다" 같은 페르소나를 부여합니다. 이렇게 하면 AI가 해당 분야의 베스트 프랙티스를 더 잘 따릅니다.

두 번째는 코딩 스타일 규칙입니다. 들여쓰기, 네이밍 규칙, 주석 작성법, 타입 힌트 사용 여부 등을 명시합니다.

"모든 public 함수는 독스트링 필수", "클래스는 반드시 Pydantic BaseModel 상속" 같은 구체적인 규칙을 넣습니다. 세 번째는 기술 스택 선호도입니다.

"데이터베이스 ORM은 SQLAlchemy 사용", "비동기 처리는 asyncio 기반", "HTTP 클라이언트는 httpx 우선" 같이 팀에서 선호하는 도구를 명시합니다. 네 번째는 금지 사항입니다.

"절대 eval() 함수 사용 금지", "print() 디버깅 코드 포함하지 말 것", "하드코딩된 비밀번호나 API 키 금지" 같은 규칙을 넣습니다. 실제 효과는 어땠을까요? 김개발 씨는 팀의 System 프롬프트를 설정하고 같은 작업을 다시 요청해봤습니다.

"사용자 생성 API 만들어주세요"라고만 했는데, 결과물이 완전히 달랐습니다. 모든 함수에 타입 힌트가 붙어있고, Google 스타일 독스트링이 자동으로 작성되었습니다.

변수명도 팀 컨벤션인 snake_case를 정확히 따랐습니다. FastAPI 데코레이터 사용법도 팀에서 선호하는 패턴과 일치했습니다.

코드 리뷰를 올렸더니 단 2개의 코멘트만 받았습니다. 이전에는 10개가 넘었는데 말이죠.

시간이 5배 이상 절약되었습니다. 프로젝트별로 다른 프롬프트 사용하기 재미있는 점은 프로젝트마다 다른 System 프롬프트를 사용할 수 있다는 것입니다.

백엔드 프로젝트에서는 FastAPI 중심 프롬프트를, 프론트엔드 프로젝트에서는 React 중심 프롬프트를 사용합니다. 김개발 씨는 자주 사용하는 프롬프트들을 파일로 저장해뒀습니다.

backend_system_prompt.txt, frontend_system_prompt.txt, data_analysis_system_prompt.txt 등으로 분류해서 상황에 맞게 불러쓰니 매우 편리했습니다. 주의할 점도 있습니다 System 프롬프트가 너무 길거나 복잡하면 오히려 역효과가 날 수 있습니다.

AI가 모든 규칙을 완벽하게 따르려다 보니 코드가 과도하게 복잡해지거나, 너무 많은 규칙 때문에 혼란스러워할 수 있습니다. 적정 길이는 200-500 단어 정도가 좋습니다.

핵심적인 규칙 10-15개 정도만 명시하고, 너무 세부적인 사항은 개별 프롬프트에서 지시하는 것이 효과적입니다. 팀 표준화의 도구 박시니어 선배는 팀 위키에 공식 System 프롬프트를 올려뒀습니다.

신입 개발자가 들어오면 가장 먼저 이 프롬프트를 설정하도록 안내합니다. 덕분에 팀 전체의 코드 스타일이 빠르게 통일되었습니다.

심지어 외주 개발자와 협업할 때도 이 프롬프트를 공유합니다. "AI 사용하실 때 이 System 프롬프트를 써주세요"라고 요청하면, 외부 개발자가 작성한 코드도 팀 스타일과 일치하게 됩니다.

동적으로 업데이트하기 System 프롬프트는 고정된 것이 아닙니다. 팀의 컨벤션이 바뀌거나, 새로운 라이브러리를 도입하거나, 더 나은 패턴을 발견하면 프롬프트도 업데이트합니다.

김개발 씨 팀은 한 달에 한 번 회고 미팅에서 System 프롬프트를 리뷰합니다. "이번 달에 자주 받은 코드 리뷰 코멘트를 프롬프트에 추가하자"는 식으로 계속 개선해나갑니다.

결과적으로 System 프롬프트는 AI를 팀의 일원으로 만드는 강력한 도구입니다. 단순히 코드를 생성하는 도구를 넘어서, 팀의 문화와 스타일을 이해하는 동료로 변신시킵니다.

김개발 씨는 이제 AI를 쓸 때마다 "우리 팀 스타일로 작성해줘"라고 일일이 말하지 않아도 됩니다. System 프롬프트가 자동으로 그 역할을 대신해주기 때문입니다.

실전 팁

💡 - System 프롬프트를 Git 저장소에 포함시켜 팀원들과 공유하세요. .ai-prompts/ 폴더를 만들어 버전 관리하면 좋습니다

프롬프트 마지막에 "이 규칙을 어길 경우 경고해주세요"를 추가하면, AI가 스스로 체크하고 알려줍니다
여러 모델(GPT-4, Claude 등)을 함께 쓴다면 각 모델별로 최적화된 System 프롬프트를 따로 만드세요. 모델마다 표현에 반응하는 방식이 다릅니다

4. Few-shot으로 코드 패턴 학습시키기

팀에 새로운 아키텍처가 도입되었습니다. Repository 패턴을 사용하기로 했는데, AI는 이 패턴을 몰랐습니다.

김개발 씨가 "Repository 패턴으로 작성해줘"라고 했더니 완전히 다른 스타일의 코드가 나왔습니다. 박시니어 선배가 조언했습니다.

"예시를 몇 개 보여주세요. Few-shot learning이라고, 예제로 패턴을 가르치는 겁니다."

Few-shot learning은 AI에게 몇 가지 예시를 보여주고 패턴을 학습시키는 기법입니다. "이런 입력에는 이런 출력"이라는 예제를 2-5개 제시하면, AI가 패턴을 파악해서 새로운 상황에 적용합니다.

팀의 고유한 아키텍처, 독특한 코딩 패턴, 프로젝트 특화 구조를 AI에게 가르치는 가장 효과적인 방법입니다.

다음 코드를 살펴봅시다.

# Few-shot 프롬프트 예시
few_shot_prompt = """
우리 팀의 Repository 패턴 예시를 보여드립니다.

예시 1 - User Repository:
class UserRepository:
    def __init__(self, db: Session):
        self.db = db

    async def find_by_id(self, user_id: int) -> Optional[User]:
        return await self.db.query(User).filter(User.id == user_id).first()

    async def create(self, user_data: UserCreate) -> User:
        user = User(**user_data.dict())
        self.db.add(user)
        await self.db.commit()
        return user

예시 2 - Product Repository:
class ProductRepository:
    def __init__(self, db: Session):
        self.db = db

    async def find_by_id(self, product_id: int) -> Optional[Product]:
        return await self.db.query(Product).filter(Product.id == product_id).first()

    async def create(self, product_data: ProductCreate) -> Product:
        product = Product(**product_data.dict())
        self.db.add(product)
        await self.db.commit()
        return product

위 패턴을 참고해서 Order Repository를 작성해주세요.
"""

김개발 씨의 팀은 코드 아키텍처를 대대적으로 리팩토링하기로 했습니다. Clean Architecture를 도입하고, Repository 패턴으로 데이터 레이어를 분리하기로 결정했습니다.

문제는 AI가 팀의 구체적인 Repository 구현 방식을 모른다는 것이었습니다. "Repository 패턴으로 Order 클래스 만들어줘"라고 요청했더니, 완전히 다른 스타일의 코드가 나왔습니다.

인터페이스를 먼저 정의하고, 추상 클래스를 만들고, 너무 복잡했습니다. 팀의 간결한 스타일과 전혀 맞지 않았습니다.

Few-shot learning이란? 박시니어 선배가 알려준 해결책은 Few-shot learning이었습니다. 이것은 AI에게 문제 해결 방법을 설명하는 대신, 예시를 보여주는 기법입니다.

마치 요리를 배울 때와 같습니다. "볶음밥은 밥을 기름에 볶고 야채를 넣고..."라고 긴 설명을 듣는 것보다, 요리사가 실제로 만드는 과정을 2-3번 보는 것이 훨씬 효과적입니다.

AI도 마찬가지입니다. Zero-shot vs Few-shot vs Many-shot 용어를 정리해봅시다.

Zero-shot은 예시 없이 지시만으로 작업하는 것입니다. "로그인 API 만들어줘"처럼 설명만 주는 방식입니다.

Few-shot은 2-5개 정도의 예시를 주는 것입니다. "이런 입력에는 이런 출력, 저런 입력에는 저런 출력" 식으로 패턴을 보여줍니다.

Many-shot은 수십 개 이상의 예시를 주는 것인데, 일반적으로 필요하지 않습니다. 대부분의 패턴은 2-5개 예시면 충분히 학습됩니다.

실전 Few-shot 적용 사례 김개발 씨는 팀의 User Repository와 Product Repository 코드를 복사해서 프롬프트에 넣었습니다. 그리고 말했습니다.

"위 두 개의 예시를 참고해서 Order Repository를 만들어주세요." 결과는 놀라웠습니다. AI가 생성한 Order Repository는 기존 두 클래스와 완벽하게 일치하는 구조를 가졌습니다.

생성자에서 self.db를 받고, find_by_id 메서드와 create 메서드를 같은 패턴으로 구현했습니다. 심지어 타입 힌트 스타일까지 똑같았습니다.

패턴 일반화 능력 Few-shot learning의 진짜 힘은 패턴 일반화입니다. 단순히 예시를 따라 하는 것이 아니라, 예시에서 규칙을 찾아내서 새로운 상황에 적용합니다.

예를 들어 User와 Product 예시에서 AI는 이런 패턴을 학습했습니다. "클래스명은 엔티티명 + Repository", "생성자는 db를 받는다", "find_by_id는 Optional을 반환한다", "create는 데이터 객체를 받아 엔티티를 반환한다" 등등.

이 패턴을 Order에 적용하니, 한 번도 본 적 없는 Order Repository를 완벽하게 만들어냈습니다. 몇 개의 예시가 적절할까요? 연구 결과에 따르면 대부분의 경우 2-3개 예시가 최적입니다.

1개만 주면 우연일 수 있어 패턴을 확신하지 못합니다. 4-5개 이상은 토큰을 낭비할 뿐 성능 향상이 미미합니다.

단, 패턴이 복잡하거나 다양한 변형이 있다면 5개까지 보여주는 것이 좋습니다. 예를 들어 에러 처리 방식이 경우에 따라 다르다면, 각 경우를 대표하는 예시를 하나씩 제공합니다.

예시 선정의 기준 좋은 Few-shot 예시는 대표성과 다양성을 모두 갖춰야 합니다. 가장 자주 사용되는 전형적인 패턴을 보여주되, 약간씩 다른 상황을 커버해야 합니다.

김개발 씨는 Repository 예시를 선택할 때 이렇게 했습니다. User는 가장 기본적인 CRUD를, Product는 비즈니스 로직이 포함된 경우를 보여줍니다.

두 예시가 겹치지 않으면서도 핵심 패턴은 공유하고 있습니다. 주석으로 패턴 강조하기 예시 코드에 주석을 추가하면 효과가 더 좋습니다.

AI가 어떤 부분에 주목해야 하는지 명확해지기 때문입니다. "여기서 주목할 점: 모든 Repository는 db를 생성자로 받습니다", "중요: find 메서드는 항상 Optional을 반환합니다" 같은 주석을 달아주면, AI가 핵심 패턴을 더 정확하게 파악합니다.

Anti-pattern도 보여주기 때로는 "이렇게 하지 말 것"이라는 예시도 유용합니다. 잘못된 코드와 올바른 코드를 쌍으로 보여주면, AI가 실수를 피하게 됩니다.

"이전 방식 (사용 금지):"와 "새로운 방식 (사용할 것):"을 나란히 보여주면, AI가 명확하게 차이를 인식합니다. 팀이 레거시에서 마이그레이션 중일 때 특히 유용합니다.

변형 생성도 가능합니다 Few-shot의 또 다른 장점은 변형 생성입니다. 예시를 주고 "이 패턴을 비동기 버전으로 바꿔주세요"라고 하면, 모든 예시를 async/await 패턴으로 변환해줍니다.

김개발 씨는 동기 버전 Repository 2개를 보여주고 "이 패턴을 FastAPI의 비동기 방식으로 변환해서 Order Repository를 만들어주세요"라고 요청했습니다. AI는 패턴을 이해하고, 비동기로 변환하고, Order 엔티티에 적용하는 세 가지를 동시에 해냈습니다.

프로젝트 온보딩 자동화 팀은 Few-shot 예시 모음집을 만들었습니다. Repository, Service, Controller, DTO 등 각 레이어별로 대표 예시 2-3개를 문서화했습니다.

신입 개발자가 오면 이 예시집을 주고 "AI한테 코드 받을 때 이 예시들을 함께 제공하세요"라고 안내합니다. 덕분에 신입도 첫날부터 팀 스타일에 맞는 코드를 작성할 수 있게 되었습니다.

업데이트와 유지보수 Few-shot 예시는 살아있는 문서입니다. 팀의 코딩 패턴이 개선되면 예시도 함께 업데이트합니다.

더 나은 패턴을 발견하면 예시를 교체합니다. 김개발 씨 팀은 분기마다 예시를 리뷰합니다.

"이 패턴은 deprecated 됐으니 제거하자", "새로운 에러 처리 방식을 예시에 추가하자" 같은 논의를 거쳐 계속 개선해나갑니다. 결론 Few-shot learning은 AI를 팀의 코딩 스타일에 빠르게 적응시키는 마법 같은 도구입니다.

긴 설명보다 2-3개의 좋은 예시가 훨씬 효과적입니다. 김개발 씨는 이제 새로운 기능을 추가할 때마다 기존 코드 2개를 복사해서 프롬프트에 넣는 습관이 생겼습니다.

실전 팁

💡 - 예시 코드는 실제로 작동하는 완전한 코드를 사용하세요. 슈도코드나 일부만 보여주면 효과가 떨어집니다

예시들 사이의 차이점을 주석으로 명시하면 AI가 변형 요소를 더 잘 이해합니다. "이 예시는 페이지네이션 포함", "이 예시는 필터링 추가" 같은 식으로요
너무 긴 예시는 피하세요. 각 예시는 20-30줄 이내로, 핵심 패턴만 보여주는 것이 효과적입니다

5. 실습: 3개 모델로 같은 과제 비교 실험

팀 회의에서 결정을 내려야 했습니다. "어떤 AI 코딩 도구를 공식 도구로 채택할까?" 의견이 분분했습니다.

김개발 씨는 실험을 제안했습니다. "실제 과제를 주고 GPT-4, Claude, Gemini의 결과를 직접 비교해보는 건 어떨까요?" 팀장님이 웃으며 고개를 끄덕였습니다.

"좋아요. 실험 설계부터 시작해봅시다."

동일한 코딩 과제를 여러 모델에게 주고 결과를 비교하는 실험입니다. 각 모델의 강점과 약점을 객관적으로 파악할 수 있습니다.

코드 품질, 설명 상세도, 에러 처리, 보안 고려사항, 실행 가능성 등 여러 기준으로 평가합니다. 실제 프로젝트에 어떤 모델이 적합한지 데이터 기반으로 판단할 수 있습니다.

다음 코드를 살펴봅시다.

# 비교 실험 과제 예시
experiment_prompt = """
RESTful API 설계 과제:
블로그 게시글 관리 시스템의 백엔드 API를 작성하세요.

요구사항:
- POST /posts : 게시글 생성
- GET /posts/{id} : 게시글 조회
- PUT /posts/{id} : 게시글 수정
- DELETE /posts/{id} : 게시글 삭제
- GET /posts : 게시글 목록 (페이지네이션 포함)

기술 스택: FastAPI + SQLAlchemy
검증 항목:

5. 문서화 (주석, 독스트링)

김개발 씨는 비교 실험 책임자가 되었습니다. 공정한 테스트를 위해 실험 설계부터 신중하게 시작했습니다.

먼저 어떤 과제를 줄지 고민했습니다. 너무 쉬우면 차이가 안 나고, 너무 어려우면 모두 실패할 수 있습니다.

팀과 논의 끝에 실무에서 자주 마주치는 중간 난이도 과제를 선택했습니다. 블로그 게시글 CRUD API 만들기.

기본적이지만 에러 처리, 보안, 데이터 검증 등 여러 측면을 평가할 수 있는 과제였습니다. 공정한 실험 설계 실험의 핵심은 공정성입니다.

세 모델에게 완전히 동일한 프롬프트를 주기로 했습니다. 한 모델에게만 더 자세한 설명을 주면 결과가 왜곡되니까요.

프롬프트는 최대한 중립적으로 작성했습니다. 특정 모델이 유리한 표현이나 힌트는 피했습니다.

"FastAPI로 CRUD API를 만들어주세요"라는 간단명료한 지시와 함께 구체적인 요구사항 리스트를 제공했습니다. 실험 진행 월요일 오전, 김개발 씨는 세 모델에게 동시에 같은 프롬프트를 보냈습니다.

각 모델의 응답 시간도 측정했습니다. GPT-4가 45초, Claude가 38초, Gemini가 42초 정도 걸렸습니다.

첫 인상은 흥미로웠습니다. GPT-4는 가장 긴 코드를 생성했습니다.

요구사항에 없던 인증 시스템까지 추가해서 제안했습니다. Claude는 단계별 설명과 함께 깔끔한 코드를 주었습니다.

Gemini는 가장 최신 FastAPI 문법을 사용했고 코드가 가장 간결했습니다. 평가 기준 설정 팀은 다섯 가지 기준으로 평가하기로 했습니다.

첫째, 코드 완성도입니다. 실제로 실행 가능한가?

의존성이 명확한가? 복사해서 바로 쓸 수 있는가?

둘째, 에러 처리입니다. 예외 상황을 고려했는가?

적절한 HTTP 상태 코드를 반환하는가? 사용자 친화적인 에러 메시지를 제공하는가?

셋째, 보안입니다. SQL Injection 방지했는가?

입력 검증을 하는가? 민감한 정보 노출은 없는가?

넷째, 코드 품질입니다. 가독성은 어떤가?

함수가 적절히 분리되어 있는가? 네이밍이 명확한가?

다섯째, 문서화입니다. 주석이 적절한가?

독스트링이 있는가? 사용 방법 설명이 있는가?

GPT-4 결과 분석 GPT-4의 코드는 가장 포괄적이었습니다. CRUD 기본 기능뿐 아니라 JWT 인증, 권한 검사, 로깅까지 포함되어 있었습니다.

코드 품질도 우수했고, 각 함수마다 상세한 독스트링이 달려있었습니다. 하지만 과하다는 느낌도 있었습니다.

요구사항에 없던 기능들이 많아서 코드가 복잡했습니다. 초보 개발자가 이해하기엔 난이도가 높았습니다.

또한 일부 최신 라이브러리 문법이 구버전으로 작성되어 있었습니다. 점수는 완성도 9점, 에러 처리 10점, 보안 9점, 코드 품질 8점, 문서화 10점이었습니다.

Claude 결과 분석 Claude의 코드는 가장 균형 잡혔습니다. 요구사항을 정확히 만족하면서도 과하지 않았습니다.

특히 인상적이었던 것은 보안에 대한 설명이었습니다. "이 부분에서 SQLAlchemy ORM을 사용해 SQL Injection을 방지합니다", "Pydantic으로 입력 검증을 자동화합니다" 같은 상세한 설명이 코드 블록 아래에 달려있었습니다.

실제 코드에는 과도한 주석이 없어 깔끔했지만, 별도 설명에서 원리를 자세히 알려줬습니다. 에러 처리도 꼼꼼했습니다.

404 Not Found, 400 Bad Request, 500 Internal Server Error를 모두 구분해서 처리했습니다. 점수는 완성도 10점, 에러 처리 10점, 보안 10점, 코드 품질 9점, 문서화 8점이었습니다.

Gemini 결과 분석 Gemini의 코드는 가장 현대적이었습니다. FastAPI 0.104 버전의 최신 문법을 정확히 사용했고, Python 3.12의 새로운 타입 힌트 문법도 활용했습니다.

코드가 가장 간결하고 읽기 쉬웠습니다. 다만 설명이 다소 부족했습니다.

코드는 훌륭한데 왜 이렇게 작성했는지에 대한 설명이 간략했습니다. 또한 에러 처리가 기본적인 수준에 그쳤습니다.

복잡한 예외 상황은 고려하지 않았습니다. 점수는 완성도 9점, 에러 처리 7점, 보안 8점, 코드 품질 10점, 문서화 6점이었습니다.

실제 실행 테스트 김개발 씨는 세 모델의 코드를 실제로 실행해봤습니다. 모두 잘 작동했습니다.

GPT-4 코드는 의존성 설치가 조금 복잡했지만, 실행되면 가장 많은 기능을 제공했습니다. Claude 코드는 바로 실행되었고 안정적으로 동작했습니다.

잘못된 입력을 주어도 적절한 에러 메시지를 반환했습니다. Gemini 코드도 즉시 실행되었고, 응답 속도가 가장 빨랐습니다.

최신 비동기 처리 방식을 활용한 덕분이었습니다. 종합 평가 회의 팀원들이 모여 결과를 논의했습니다.

총점은 Claude 47점, GPT-4 46점, Gemini 40점이었습니다. 하지만 단순 점수보다 중요한 것은 각 모델의 특성을 파악한 것이었습니다.

"GPT-4는 기능을 많이 제안하니까, 아이디어 브레인스토밍할 때 좋겠어요." "Claude는 안전하고 설명이 자세하니까, 중요한 보안 기능을 만들 때 쓰면 되겠네요." "Gemini는 최신 문법을 잘 아니까, 새로운 프레임워크를 배울 때 유용하겠어요." 추가 실험들 첫 실험이 성공적이어서 추가 실험도 진행했습니다. 프론트엔드 컴포넌트 만들기, 알고리즘 최적화, 데이터베이스 쿼리 튜닝 등 다양한 과제를 테스트했습니다.

흥미롭게도 과제 유형에 따라 순위가 바뀌었습니다. 알고리즘 문제에서는 GPT-4가 압도적이었고, UI 컴포넌트에서는 Gemini가 뛰어났으며, 리팩토링 과제에서는 Claude가 최고였습니다.

데이터 기반 의사결정 팀은 실험 결과를 바탕으로 합리적인 결정을 내렸습니다. 메인 도구로 Claude를 채택하되, GPT-4와 Gemini도 보조로 구독하기로 했습니다.

각 모델의 강점을 활용하는 전략이었습니다. 김개발 씨는 실험 보고서를 작성해서 팀 위키에 올렸습니다.

앞으로 신입 개발자들이 참고할 수 있도록 말이죠. 체계적인 실험과 객관적인 데이터가 최선의 선택을 만들었습니다.

실전 팁

💡 - 실험 과제는 실제 업무와 유사한 난이도로 설정하세요. 너무 쉽거나 어려우면 차이가 명확하지 않습니다

여러 유형의 과제를 테스트하세요. CRUD API, 알고리즘, UI 컴포넌트, 리팩토링 등 다양한 작업에서 모델 성능이 다르게 나타납니다
평가 기준을 사전에 명확히 정의하고 점수표를 만드세요. 주관적 판단을 최소화할 수 있습니다

6. 실습: 나만의 코딩 스타일 시스템 프롬프트 작성

3개월간 AI 코딩 도구를 사용한 김개발 씨는 깨달았습니다. "매번 같은 말을 반복하고 있네." 타입 힌트 추가해달라고, 주석은 간단하게 해달라고, 변수명은 명확하게 해달라고.

박시니어 선배가 조언했습니다. "나만의 System 프롬프트를 만들어보세요.

한 번 작성해두면 계속 재사용할 수 있어요."

자신만의 코딩 스타일을 반영한 System 프롬프트를 작성하는 실습입니다. 선호하는 프로그래밍 언어, 자주 쓰는 프레임워크, 코딩 컨벤션, 금지 사항 등을 체계적으로 정리합니다.

이 프롬프트 하나로 모든 AI 대화에서 일관된 스타일의 코드를 받을 수 있습니다. 개인 개발자뿐 아니라 팀 전체가 공유할 수도 있습니다.

다음 코드를 살펴봅시다.

# 나만의 System 프롬프트 템플릿
my_system_prompt = """
# 당신의 역할
당신은 {경력}년 차 {분야} 개발자입니다.
{프로그래밍_언어}와 {프레임워크}에 전문성을 가지고 있습니다.

# 코딩 스타일
- 언어: {언어} ({버전})
- 프레임워크: {프레임워크}
- 들여쓰기: {탭_또는_스페이스} ({개수})
- 최대 줄 길이: {숫자}자
- 네이밍 규칙:
  * 변수: {snake_case/camelCase}
  * 함수: {snake_case/camelCase}
  * 클래스: {PascalCase}
  * 상수: {UPPER_CASE}

# 필수 사항
- [ ] 모든 함수에 타입 힌트 추가
- [ ] {독스트링_스타일} 스타일 독스트링
- [ ] 에러 처리는 {try-except/Result_타입} 사용
- [ ] 테스트 코드는 {pytest/jest} 사용

# 금지 사항
- [ ] print() 디버깅 금지
- [ ] 하드코딩된 비밀번호/API키 금지
- [ ] {사용하지_않는_라이브러리} 사용 금지

# 선호 라이브러리
- HTTP 클라이언트: {httpx/requests}
- 날짜 처리: {arrow/pendulum/datetime}
- 환경변수: {python-dotenv/pydantic-settings}
"""

# 실제 작성 예시
actual_prompt = """
# 당신의 역할
당신은 5년차 백엔드 개발자입니다.
Python과 FastAPI에 전문성을 가지고 있습니다.

# 코딩 스타일
- 언어: Python 3.11+
- 프레임워크: FastAPI
- 들여쓰기: 스페이스 4개
- 최대 줄 길이: 88자 (Black 스타일)
- 네이밍: snake_case (변수/함수), PascalCase (클래스)

# 필수 사항
- 모든 함수에 타입 힌트
- Google 스타일 독스트링
- Pydantic으로 데이터 검증
- pytest로 테스트 작성

# 금지 사항
- print() 대신 logging 사용
- 환경변수 하드코딩 금지
- pandas 사용 금지 (polars 사용)

# 선호 라이브러리
- HTTP: httpx
- 날짜: pendulum
- 환경변수: pydantic-settings
"""

김개발 씨는 노트북을 열고 지난 3개월간 AI에게 했던 요청들을 정리해봤습니다. "타입 힌트 추가해줘"를 27번, "주석은 간단하게 해줘"를 19번, "print 대신 logging 써줘"를 15번 반복했더군요.

이걸 매번 말하는 건 비효율의 극치였습니다. 드디어 나만의 System 프롬프트를 작성할 시간입니다.

1단계: 자기 분석 먼저 자신의 개발 스타일을 객관적으로 분석해야 합니다. 김개발 씨는 질문지를 만들었습니다.

"주로 어떤 언어로 개발하나?" - Python "자주 쓰는 프레임워크는?" - FastAPI, SQLAlchemy "코딩 컨벤션은?" - Black 포맷터 사용, 88자 제한, snake_case "절대 하지 않는 것은?" - print() 디버깅, 하드코딩 "항상 하는 것은?" - 타입 힌트, Google 독스트링, 단위 테스트 이렇게 질문에 답하다 보니 자신의 스타일이 명확해졌습니다. 2단계: 역할 정의 System 프롬프트는 AI에게 역할을 부여하는 것부터 시작합니다.

"당신은 5년차 Python 백엔드 개발자입니다"라고 명시하면, AI가 그 수준과 전문성에 맞는 코드를 생성합니다. 김개발 씨는 "당신은 실용주의 Python 개발자입니다.

완벽한 코드보다 동작하는 코드를 선호하지만, 보안과 테스트는 절대 타협하지 않습니다"라고 작성했습니다. 이 한 문장이 AI의 전체적인 태도를 결정합니다.

3단계: 기술 스택 명시 다음은 구체적인 기술 스택입니다. Python 버전, 주요 프레임워크, 선호하는 라이브러리를 명확히 합니다.

"Python 3.11 이상 사용", "FastAPI 프레임워크 우선", "SQLAlchemy 2.0 문법", "httpx로 HTTP 클라이언트 구현" 같은 구체적인 지시를 넣었습니다. 특히 중요한 것은 버전입니다.

"SQLAlchemy 2.0"이라고 명시하지 않으면 AI가 구버전 문법을 사용할 수 있습니다. 4단계: 코딩 컨벤션 네이밍 규칙, 들여쓰기, 줄 길이 같은 세부 컨벤션을 정리합니다.

김개발 씨는 Black 포맷터를 쓰므로 "88자 제한", "스페이스 4개 들여쓰기"를 명시했습니다. 또한 "변수와 함수는 snake_case, 클래스는 PascalCase, 상수는 UPPER_CASE"라고 구체적으로 작성했습니다.

이렇게 하면 AI가 일관된 네이밍을 사용합니다. 5단계: 필수 요구사항 항상 포함되어야 하는 요소들을 체크리스트로 만듭니다.

모든 public 함수에 타입 힌트 필수 - Google 스타일 독스트링 작성 - Pydantic BaseModel로 데이터 검증 - 비즈니스 로직은 서비스 레이어에 - 데이터베이스 접근은 Repository 패턴 이 체크리스트가 있으면 AI가 코드를 생성할 때 자동으로 확인합니다. 6단계: 금지 사항 "절대 하지 말아야 할 것"도 명시합니다.

김개발 씨의 금지 리스트는 이렇습니다. - print() 디버깅 금지 (logging 사용할 것) - 환경변수 하드코딩 금지 - eval() 함수 사용 금지 - 전역 변수 남용 금지 - pandas 사용 금지 (polars 사용할 것) 마지막 항목이 흥미롭습니다.

김개발 씨 팀은 성능 이유로 pandas 대신 polars로 마이그레이션 중입니다. 이런 팀 특화 규칙도 프롬프트에 반영할 수 있습니다.

7단계: 응답 형식 지정 코드만 달랑 주는 게 아니라, 어떻게 설명해줬으면 좋을지도 명시합니다. "코드 블록 위에 간단한 설명 추가", "복잡한 로직은 단계별 주석", "보안 고려사항이 있으면 별도 언급", "성능에 영향 주는 부분은 경고" 같은 응답 스타일 가이드를 넣었습니다.

8단계: 예시 첨부 프롬프트 마지막에 "좋은 코드 예시"를 하나 첨부했습니다. 팀에서 가장 잘 작성된 함수 하나를 복사해서 "이런 스타일을 지향합니다"라고 명시했습니다.

이 예시가 앞서 설명한 모든 규칙을 실제로 구현한 샘플이 됩니다. AI는 이 예시를 참고해서 비슷한 품질의 코드를 생성합니다.

실전 테스트 김개발 씨는 새로 만든 System 프롬프트를 GPT-4에 설정하고 테스트했습니다. "사용자 등록 API를 만들어줘"라고만 했는데, 결과물이 놀라웠습니다.

타입 힌트가 완벽하게 붙어있고, Google 스타일 독스트링이 작성되어 있고, Pydantic으로 입력 검증을 하고, logging으로 에러를 기록하고, 환경변수는 settings.py에서 불러오고, SQLAlchemy 2.0 문법을 정확히 사용했습니다. 단 한 줄의 추가 요청 없이, 프롬프트 하나만으로 완벽한 코드가 나왔습니다.

반복 개선 첫 버전이 완벽할 순 없습니다. 김개발 씨는 일주일간 사용하면서 프롬프트를 계속 다듬었습니다.

"아, AI가 async 함수를 만들 때 await를 빼먹네. 명시해야겠다." "독스트링에 예제가 없으면 이해하기 어려워.

예제 포함하라고 추가하자." "에러 메시지가 너무 기술적이야. 사용자 친화적으로 작성하라고 명시해야지." 이렇게 실사용 피드백을 반영해 프롬프트를 업데이트했습니다.

버전 관리 김개발 씨는 System 프롬프트를 Git으로 관리하기 시작했습니다. .ai-prompts/backend-v1.0.md 파일로 저장하고, 변경할 때마다 버전을 올렸습니다.

커밋 메시지에 "Add async/await 명시", "Update polars 사용 권장사항" 같이 변경 내역을 기록했습니다. 마치 코드를 관리하듯 프롬프트도 관리하는 겁니다.

팀 공유 효과가 좋아서 팀원들과 공유했습니다. 각자 자기 스타일대로 커스터마이징했지만, 기본 틀은 같았습니다.

덕분에 팀 전체 코드의 일관성이 크게 향상되었습니다. 박시니어 선배는 프론트엔드용 System 프롬프트도 만들었습니다.

React, TypeScript, TailwindCSS 기반으로요. 디자이너와 협업할 때도 이 프롬프트를 공유해서, 디자이너가 AI로 코드를 생성할 때도 팀 스타일을 따르게 했습니다.

결과 한 달 후, 김개발 씨의 생산성은 눈에 띄게 올랐습니다. 코드 리뷰에서 받는 스타일 관련 지적이 거의 사라졌습니다.

AI가 처음부터 팀 컨벤션에 맞는 코드를 생성하니까요. 더 중요한 것은 멘탈 에너지 절약입니다.

매번 같은 요구사항을 반복할 필요가 없으니 피로도가 줄었습니다. 정작 중요한 비즈니스 로직에 집중할 수 있게 되었습니다.

나만의 System 프롬프트, 한 번 만들면 평생 가는 자산입니다.

실전 팁

💡 - System 프롬프트는 300-500단어가 적정합니다. 너무 길면 AI가 모든 규칙을 완벽히 따르기 어렵습니다

주기적으로(한 달에 한 번) 프롬프트를 리뷰하고 업데이트하세요. 코딩 스타일도 계속 진화합니다
프로젝트별로 다른 프롬프트를 만들어 폴더로 관리하세요. prompts/backend.md, prompts/frontend.md, prompts/data.md 같은 식으로 분류하면 편리합니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Python#RLHF#GPT-4#Claude#Gemini#LLM,RLHF,모델비교

RLHF로 학습된 코딩 모델 완벽 활용 가이드

# RLHF로 학습된 코딩 모델 완벽 활용 가이드 ChatGPT, Claude, Gemini 같은 RLHF 기반 코딩 모델들의 차이를 비교하고, 프롬프트 엔지니어링으로 원하는 코드를 정확하게 생성하는 실전 노하우를 배웁니다. 초급 개발자도 실무에서 바로 활용할 수 있는 구체적인 실습 가이드를 제공합니다. --- ## 목차 1. [GPT-4, Claude, Gemini 코딩 능력 비교](#gpt-4,-claude,-gemini-코딩-능력-비교) 2. [Instruction Following으로 정확한 코드 생성](#instruction-following으로-정확한-코드-생성) 3. [System 프롬프트로 코딩 스타일 지정](#system-프롬프트로-코딩-스타일-지정) 4. [Few-shot으로 코드 패턴 학습시키기](#few-shot으로-코드-패턴-학습시키기) 5. [실습: 3개 모델로 같은 과제 비교 실험](#실습:-3개-모델로-같은-과제-비교-실험) 5. [문서화 (주석, 독스트링)](#문서화-(주석,-독스트링)) 6. [실습: 나만의 코딩 스타일 시스템 프롬프트 작성](#실습:-나만의-코딩-스타일-시스템-프롬프트-작성) --- ## 1. GPT-4, Claude, Gemini 코딩 능력 비교 김개발 씨는 오늘도 AI 코딩 어시스턴트에게 코드를 요청했습니다. 같은 질문인데 ChatGPT와 Claude가 완전히 다른 코드를 내놓았습니다. "도대체 어느 모델을 써야 할까?" 팀장님은 웃으며 말했습니다. "각 모델의 특성을 알아야 제대로 활용할 수 있지." RLHF로 학습된 코딩 모델들은 각자 고유한 강점을 가지고 있습니다. GPT-4는 광범위한 지식과 창의적인 솔루션에 강하고, Claude는 긴 컨텍스트 이해와 안전한 코드 생성에 뛰어나며, Gemini는 최신 정보 반영과 멀티모달 처리에 특화되어 있습니다. 모델별 특성을 이해하면 상황에 맞는 최적의 도구를 선택할 수 있습니다. 다음 코드를 살펴봅시다. ```python # 세 모델에게 같은 작업 요청 예시 prompt = """ 사용자 인증 API를 FastAPI로 작성해주세요. JWT 토큰 발급, 검증 포함 """ # GPT-4 응답 특징: 완전한 구현 + 추가 기능 제안 # Claude 응답 특징: 단계별 설명 + 보안 중점 # Gemini 응답 특징: 최신 라이브러리 + 간결한 구조 # 실제 비교를 위한 평가 항목 evaluation_criteria = { "code_quality": 0, # 코드 품질 "explanation": 0, # 설명 상세도 "security": 0, # 보안 고려사항 "completeness": 0 # 완성도 } ``` 김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 AI 코딩 도구 라이선스를 구매하기로 했는데, 어떤 모델을 선택할지 고민이 깊어졌습니다. ChatGPT Plus, Claude Pro, Gemini Advanced 중 무엇을 써야 할까요? 팀장 박시니어 씨가 회의실로 불러 말했습니다. "김개발 씨, 각 모델의 특성을 제대로 비교해보고 보고서를 작성해주세요. 우리 팀에 가장 적합한 도구를 골라야 하니까요." **RLHF란 무엇일까요?** 먼저 RLHF가 무엇인지 이해해야 합니다. RLHF는 Reinforcement Learning from Human Feedback의 약자입니다. 쉽게 비유하자면, 선생님이 학생의 답안을 채점하며 가르치는 것과 같습니다. AI가 코드를 생성하면 인간 전문가들이 평가하고, 그 피드백으로 모델이 점점 더 나은 코드를 작성하도록 학습됩니다. 이 방식 덕분에 최신 LLM들은 단순히 문법적으로 맞는 코드를 넘어서, 실무에서 선호하는 스타일과 패턴을 익힐 수 있게 되었습니다. **GPT-4의 강점은 무엇일까요?** 김개발 씨는 먼저 GPT-4를 테스트해봤습니다. "사용자 인증 시스템을 만들어주세요"라고 요청했더니, GPT-4는 JWT 토큰 발급뿐만 아니라 리프레시 토큰, 비밀번호 해싱, 이메일 인증까지 포함한 완전한 시스템을 제안했습니다. GPT-4의 가장 큰 장점은 **광범위한 지식 베이스**입니다. 다양한 프로그래밍 언어와 프레임워크에 대해 깊은 이해를 가지고 있으며, 복잡한 아키텍처 설계도 잘 제안합니다. 특히 **창의적인 문제 해결**이 필요할 때 빛을 발합니다. 하지만 때로는 과하게 복잡한 솔루션을 제안하기도 합니다. 간단한 기능만 필요한데 엔터프라이즈급 시스템을 설계해버릴 수 있습니다. **Claude는 어떤 특징이 있을까요?** 다음으로 Claude를 테스트했습니다. 같은 질문을 던졌더니, Claude는 단계별로 매우 상세한 설명과 함께 코드를 제공했습니다. 특히 인상적이었던 것은 보안 취약점에 대한 경고였습니다. "SQL Injection을 방지하기 위해 ORM을 사용하세요", "비밀번호는 반드시 bcrypt로 해싱하세요", "환경변수로 시크릿 키를 관리하세요" 등 실무에서 꼭 필요한 보안 가이드를 자세히 알려줬습니다. Claude의 강점은 **긴 컨텍스트 이해**와 **안전성**입니다. 최대 200K 토큰까지 처리할 수 있어서 대규모 코드베이스를 분석할 때 유리합니다. 또한 잠재적인 보안 문제나 버그를 미리 짚어주는 경향이 있습니다. **Gemini는 무엇이 다를까요?** 마지막으로 Gemini를 테스트했습니다. Gemini는 가장 최신 라이브러리와 베스트 프랙티스를 반영한 코드를 제공했습니다. 2024년에 출시된 라이브러리 버전까지 정확하게 반영했습니다. Gemini의 특징은 **최신 정보 반영**과 **멀티모달 능력**입니다. 이미지를 업로드하면 UI를 분석해서 코드로 변환해주는 기능이 매우 강력합니다. 또한 Google 검색과 연동되어 최신 문서와 업데이트를 빠르게 반영합니다. **실제 비교 결과는?** 김개발 씨는 3일간 세 모델을 집중적으로 테스트했습니다. REST API 개발, 데이터베이스 쿼리 최적화, 프론트엔드 컴포넌트 작성 등 다양한 작업을 시켰습니다. 결과는 흥미로웠습니다. **복잡한 알고리즘**이나 **새로운 아키텍처 설계**가 필요할 때는 GPT-4가 가장 우수했습니다. **레거시 코드 리팩토링**이나 **보안이 중요한 작업**에서는 Claude가 뛰어났습니다. **최신 프레임워크**를 사용하거나 **UI 디자인을 코드로 변환**할 때는 Gemini가 최고였습니다. **어떤 모델을 선택해야 할까요?** 박시니어 팀장은 보고서를 읽고 고개를 끄덕였습니다. "좋은 분석이네요. 그런데 김개발 씨, 우리가 꼭 하나만 선택할 필요는 없어요." 실제로 많은 개발 팀들은 **상황에 따라 여러 모델을 함께 사용**합니다. 설계 단계에서는 GPT-4로 브레인스토밍하고, 구현 단계에서는 Claude로 안전한 코드를 작성하고, 최신 라이브러리 정보가 필요할 때는 Gemini를 참고하는 식입니다. **비용 대비 효율은?** 물론 예산도 중요합니다. GPT-4는 가장 비싸지만 가장 범용적입니다. Claude는 중간 가격대에 긴 컨텍스트를 제공합니다. Gemini는 상대적으로 저렴하면서도 Google Workspace와의 통합이 뛰어납니다. 김개발 씨의 팀은 결국 GPT-4를 메인으로, Claude를 코드 리뷰용으로 구독하기로 결정했습니다. 각 모델의 장점을 이해하고 적재적소에 활용하는 것이 가장 현명한 선택이었습니다. **실전 팁** 💡 - 복잡한 문제 해결이 필요하면 GPT-4, 보안이 중요하면 Claude, 최신 정보가 필요하면 Gemini를 우선 고려하세요 - 한 모델의 답변이 만족스럽지 않다면 다른 모델에게 같은 질문을 던져보세요. 서로 다른 관점의 솔루션을 얻을 수 있습니다 - 긴 코드를 분석할 때는 Claude의 200K 컨텍스트 윈도우를 활용하세요 --- ## 2. Instruction Following으로 정확한 코드 생성 이상한 일이 벌어졌습니다. 김개발 씨가 "로그인 기능 만들어줘"라고 요청했더니 AI가 회원가입까지 만들어버렸습니다. 반대로 선배 박시니어 씨가 같은 작업을 요청하니 딱 필요한 코드만 깔끔하게 나왔습니다. "프롬프트를 어떻게 작성하느냐에 따라 천지 차이예요." **Instruction Following**은 AI가 사용자의 지시사항을 정확하게 따르는 능력입니다. RLHF 학습 과정에서 모델은 명확한 지시를 따르는 훈련을 집중적으로 받았습니다. 구체적이고 명확한 지시를 내릴수록 원하는 결과를 얻을 확률이 높아집니다. 프롬프트 작성 기술이 곧 코드 품질을 결정합니다. 다음 코드를 살펴봅시다. ```python # 나쁜 예시: 모호한 지시 bad_prompt = "로그인 기능 만들어줘" # 좋은 예시: 구체적인 지시 good_prompt = """ FastAPI로 로그인 API를 작성해주세요. 요구사항: - POST /login 엔드포인트만 작성 - 입력: email, password (JSON) - 출력: access_token (JWT) - 비밀번호 검증은 bcrypt 사용 - 토큰 만료시간 30분 - 에러 처리 포함 - 타입 힌트 필수 """ # 더 나은 예시: 예상 출력 형식까지 명시 best_prompt = good_prompt + """ 응답 형식: { "access_token": "eyJ...", "token_type": "bearer" } """ ``` 김개발 씨는 AI 코딩 도구를 쓰기 시작한 지 일주일이 되었습니다. 하지만 만족스러운 코드를 얻기가 쉽지 않았습니다. "장바구니 기능 만들어줘"라고 하면 너무 복잡한 코드가 나오고, "간단하게 해줘"라고 하면 이번엔 너무 단순했습니다. 옆자리 박시니어 선배는 같은 AI를 쓰는데 항상 딱 맞는 코드를 받아냈습니다. 도대체 무슨 차이일까요? **명령을 따르는 능력, Instruction Following** 비밀은 바로 **Instruction Following** 능력을 제대로 활용하는 것이었습니다. RLHF로 훈련된 최신 코딩 모델들은 사용자의 지시사항을 정확하게 따르도록 특별히 학습되었습니다. 마치 레스토랑에서 주문하는 것과 같습니다. "파스타 하나요"라고 하면 셰프가 임의로 선택한 파스타가 나옵니다. 하지만 "토마토 소스 파스타, 면은 알덴테, 마늘 빼고, 파마산 치즈 추가"라고 구체적으로 주문하면 정확히 원하는 요리가 나옵니다. **모호한 프롬프트의 문제점** 김개발 씨의 실패 사례를 봅시다. "사용자 관리 시스템 만들어줘"라고 요청했더니 AI는 무려 500줄짜리 코드를 생성했습니다. CRUD 전체, 권한 관리, 이메일 인증, 프로필 사진 업로드까지 포함되어 있었습니다. 문제는 김개발 씨가 원했던 건 단순히 사용자 목록을 조회하는 API 하나였다는 점입니다. 나머지 기능들은 이미 다른 팀원이 만들어둔 상태였습니다. 불필요한 코드를 지우고 통합하느라 오히려 시간이 더 걸렸습니다. **구체적인 지시의 힘** 박시니어 선배는 어떻게 요청했을까요? 선배의 프롬프트를 훔쳐봤습니다. "FastAPI로 사용자 목록 조회 API를 작성해주세요. GET /users 엔드포인트만 필요합니다. 페이지네이션은 limit과 offset 쿼리 파라미터로 구현하고, 각 사용자는 id, email, name만 반환하세요. SQLAlchemy ORM을 사용하고, 응답은 List[UserResponse] 타입으로 주세요." 결과는 놀라웠습니다. 딱 30줄짜리 깔끔한 코드가 나왔고, 바로 프로젝트에 통합할 수 있었습니다. 수정할 부분이 거의 없었습니다. **좋은 프롬프트의 5가지 요소** 박시니어 선배가 점심시간에 노하우를 알려줬습니다. 좋은 프롬프트에는 다섯 가지 요소가 들어가야 합니다. 첫째, **기술 스택을 명시**하세요. "Python으로", "FastAPI로", "SQLAlchemy 사용" 같은 구체적인 도구를 지정합니다. 둘째, **정확한 범위를 설정**하세요. "전체 시스템"이 아니라 "GET /users 엔드포인트만" 같이 명확하게 범위를 좁힙니다. 셋째, **입출력 형식을 명시**하세요. 어떤 파라미터를 받고, 어떤 형태로 응답할지 구체적으로 작성합니다. 넷째, **제약사항을 추가**하세요. "타입 힌트 필수", "에러 처리 포함", "주석 달지 말것" 같은 세부 요구사항을 명시합니다. 다섯째, **예제를 제공**하세요. 원하는 코드 스타일이나 응답 형식의 예시를 보여주면 AI가 더 정확하게 이해합니다. **단계별 지시의 효과** 복잡한 작업일수록 **단계별로 나누어 지시**하는 것이 효과적입니다. 한 번에 "쇼핑몰 백엔드 전체"를 요청하는 대신, 먼저 "상품 모델 정의", 다음에 "상품 CRUD API", 그 다음 "장바구니 기능" 식으로 나누어 진행합니다. 김개발 씨는 이 방법을 시도해봤습니다. "먼저 User 모델을 SQLAlchemy로 정의해주세요. id, email, hashed_password, created_at 필드만 포함하세요." 완벽한 모델이 나왔습니다. 다음 단계로 "위 User 모델을 사용해서 회원가입 API를 작성해주세요. POST /signup 엔드포인트, 입력은 email과 password, 비밀번호는 bcrypt로 해싱하세요." 역시 정확한 코드가 생성되었습니다. **부정 지시도 중요합니다** "하지 말아야 할 것"을 명시하는 것도 중요합니다. "주석을 달지 마세요", "타입 체크 코드는 제외하세요", "예외 처리는 나중에 추가할 예정이니 생략하세요" 같은 부정 지시를 활용하세요. AI는 기본적으로 완전한 코드를 만들려고 합니다. 때로는 너무 친절해서 불필요한 부분까지 추가합니다. 명확하게 "필요없다"고 말해주면 더 깔끔한 코드를 얻을 수 있습니다. **컨텍스트 제공의 중요성** 기존 코드베이스가 있다면 관련 코드를 함께 제공하세요. "우리 프로젝트는 이런 구조를 사용합니다"라며 예시 코드를 보여주면, AI가 프로젝트의 코딩 스타일을 학습해서 일관된 코드를 생성합니다. 예를 들어 "우리 팀은 이런 식으로 응답 모델을 정의합니다"라며 기존 코드를 첨부하면, 새로운 응답 모델도 같은 패턴으로 만들어집니다. **반복적 개선** 한 번에 완벽한 코드가 나오지 않아도 괜찮습니다. 첫 결과물을 보고 "좋은데, 여기에 에러 처리를 추가해주세요", "타입 힌트를 더 구체적으로 해주세요" 같이 추가 지시를 내리세요. RLHF 모델들은 대화 맥락을 이해하므로, 이전 코드를 기억하고 수정해줍니다. 마치 페어 프로그래밍하듯이 점진적으로 개선할 수 있습니다. **결과의 차이** 한 달 후, 김개발 씨의 생산성이 눈에 띄게 향상되었습니다. 같은 AI 도구를 쓰지만 이제는 원하는 코드를 정확하게 받아냅니다. 비결은 간단했습니다. 명확하고 구체적인 지시를 내리는 것, 그것이 전부였습니다. **실전 팁** 💡 - 프롬프트에 "정확히", "오직", "반드시" 같은 강조 단어를 사용하면 AI가 지시사항을 더 엄격하게 따릅니다 - 코드 스타일 가이드를 프롬프트에 포함하세요. "PEP 8 준수", "함수명은 동사로 시작" 같은 규칙을 명시하면 일관된 코드를 얻습니다 - 원하지 않는 결과가 나오면 프롬프트를 조금씩 수정해가며 실험하세요. 어떤 표현이 효과적인지 패턴을 익히게 됩니다 --- ## 3. System 프롬프트로 코딩 스타일 지정 김개발 씨는 AI가 생성한 코드를 리뷰받을 때마다 같은 지적을 받았습니다. "타입 힌트가 없네요", "독스트링을 추가하세요", "우리 팀 네이밍 규칙과 달라요". 매번 수동으로 고치기 귀찮았습니다. 박시니어 선배가 말했습니다. "System 프롬프트를 설정해보세요. AI의 기본 행동을 바꿀 수 있어요." **System 프롬프트**는 AI의 전체 대화 세션에 적용되는 기본 지시사항입니다. 마치 AI에게 "당신은 이런 성격의 개발자입니다"라고 역할을 부여하는 것과 같습니다. 코딩 스타일, 주석 작성 방식, 선호하는 라이브러리, 네이밍 규칙 등을 미리 설정해두면 모든 생성 코드가 일관된 스타일을 따르게 됩니다. 다음 코드를 살펴봅시다. ```python # OpenAI API를 사용한 System 프롬프트 설정 예시 import openai system_prompt = """ 당신은 Python 백엔드 전문 개발자입니다. 다음 규칙을 항상 따르세요: 코딩 스타일: - PEP 8 스타일 가이드 준수 - 모든 함수에 타입 힌트 필수 - Google 스타일 독스트링 작성 - 변수명은 snake_case, 클래스명은 PascalCase 기술 스택: - FastAPI 프레임워크 우선 사용 - SQLAlchemy ORM 사용 - Pydantic으로 데이터 검증 - pytest로 테스트 작성 코드 구조: - 각 함수는 단일 책임 원칙 준수 - 매직 넘버 사용 금지, 상수로 정의 - 에러 처리는 명시적으로 작성 """ response = openai.ChatCompletion.create( model="gpt-4", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": "사용자 생성 API를 만들어주세요"} ] ) ``` 김개발 씨는 AI가 만들어준 코드를 PR로 올렸다가 10개의 코멘트를 받았습니다. "타입 힌트 추가", "독스트링 작성", "변수명을 우리 컨벤션에 맞게 수정" 등등. 분명 잘 동작하는 코드인데 스타일 때문에 계속 수정해야 했습니다. 점심시간에 박시니어 선배에게 하소연했습니다. "AI한테 코드 받을 때마다 팀 컨벤션에 안 맞아서 고치느라 시간이 더 걸려요." 선배가 웃으며 답했습니다. "System 프롬프트를 써보세요. 게임 체인저예요." **System 프롬프트란 무엇일까요?** System 프롬프트는 AI와의 대화가 시작될 때 설정하는 **기본 지시사항**입니다. 일반 프롬프트가 "이 작업을 해주세요"라는 단발성 요청이라면, System 프롬프트는 "당신은 항상 이렇게 행동하세요"라는 지속적인 규칙입니다. 비유하자면 회사 입사 첫날 받는 온보딩 교육과 같습니다. "우리 회사는 이런 문화를 가지고 있고, 이런 방식으로 일합니다"라는 기본 틀을 설정하는 것입니다. 이후 모든 작업은 이 틀 안에서 진행됩니다. **왜 System 프롬프트가 중요할까요?** 매번 "타입 힌트 붙여주세요", "PEP 8 따라주세요"라고 요청하는 것은 비효율적입니다. System 프롬프트에 한 번 설정해두면 모든 대화에서 자동으로 적용됩니다. 더 중요한 것은 **일관성**입니다. 팀 전체가 같은 System 프롬프트를 사용하면, AI가 생성한 코드가 마치 한 사람이 작성한 것처럼 통일된 스타일을 가지게 됩니다. **실전 System 프롬프트 작성법** 박시니어 선배가 팀에서 사용하는 System 프롬프트를 공유해줬습니다. 크게 네 부분으로 구성되어 있었습니다. 첫 번째는 **역할 정의**입니다. "당신은 10년 경력의 Python 백엔드 개발자입니다" 같은 페르소나를 부여합니다. 이렇게 하면 AI가 해당 분야의 베스트 프랙티스를 더 잘 따릅니다. 두 번째는 **코딩 스타일 규칙**입니다. 들여쓰기, 네이밍 규칙, 주석 작성법, 타입 힌트 사용 여부 등을 명시합니다. "모든 public 함수는 독스트링 필수", "클래스는 반드시 Pydantic BaseModel 상속" 같은 구체적인 규칙을 넣습니다. 세 번째는 **기술 스택 선호도**입니다. "데이터베이스 ORM은 SQLAlchemy 사용", "비동기 처리는 asyncio 기반", "HTTP 클라이언트는 httpx 우선" 같이 팀에서 선호하는 도구를 명시합니다. 네 번째는 **금지 사항**입니다. "절대 eval() 함수 사용 금지", "print() 디버깅 코드 포함하지 말 것", "하드코딩된 비밀번호나 API 키 금지" 같은 규칙을 넣습니다. **실제 효과는 어땠을까요?** 김개발 씨는 팀의 System 프롬프트를 설정하고 같은 작업을 다시 요청해봤습니다. "사용자 생성 API 만들어주세요"라고만 했는데, 결과물이 완전히 달랐습니다. 모든 함수에 타입 힌트가 붙어있고, Google 스타일 독스트링이 자동으로 작성되었습니다. 변수명도 팀 컨벤션인 snake_case를 정확히 따랐습니다. FastAPI 데코레이터 사용법도 팀에서 선호하는 패턴과 일치했습니다. 코드 리뷰를 올렸더니 단 2개의 코멘트만 받았습니다. 이전에는 10개가 넘었는데 말이죠. 시간이 5배 이상 절약되었습니다. **프로젝트별로 다른 프롬프트 사용하기** 재미있는 점은 프로젝트마다 다른 System 프롬프트를 사용할 수 있다는 것입니다. 백엔드 프로젝트에서는 FastAPI 중심 프롬프트를, 프론트엔드 프로젝트에서는 React 중심 프롬프트를 사용합니다. 김개발 씨는 자주 사용하는 프롬프트들을 파일로 저장해뒀습니다. `backend_system_prompt.txt`, `frontend_system_prompt.txt`, `data_analysis_system_prompt.txt` 등으로 분류해서 상황에 맞게 불러쓰니 매우 편리했습니다. **주의할 점도 있습니다** System 프롬프트가 너무 길거나 복잡하면 오히려 역효과가 날 수 있습니다. AI가 모든 규칙을 완벽하게 따르려다 보니 코드가 과도하게 복잡해지거나, 너무 많은 규칙 때문에 혼란스러워할 수 있습니다. 적정 길이는 200-500 단어 정도가 좋습니다. 핵심적인 규칙 10-15개 정도만 명시하고, 너무 세부적인 사항은 개별 프롬프트에서 지시하는 것이 효과적입니다. **팀 표준화의 도구** 박시니어 선배는 팀 위키에 공식 System 프롬프트를 올려뒀습니다. 신입 개발자가 들어오면 가장 먼저 이 프롬프트를 설정하도록 안내합니다. 덕분에 팀 전체의 코드 스타일이 빠르게 통일되었습니다. 심지어 외주 개발자와 협업할 때도 이 프롬프트를 공유합니다. "AI 사용하실 때 이 System 프롬프트를 써주세요"라고 요청하면, 외부 개발자가 작성한 코드도 팀 스타일과 일치하게 됩니다. **동적으로 업데이트하기** System 프롬프트는 고정된 것이 아닙니다. 팀의 컨벤션이 바뀌거나, 새로운 라이브러리를 도입하거나, 더 나은 패턴을 발견하면 프롬프트도 업데이트합니다. 김개발 씨 팀은 한 달에 한 번 회고 미팅에서 System 프롬프트를 리뷰합니다. "이번 달에 자주 받은 코드 리뷰 코멘트를 프롬프트에 추가하자"는 식으로 계속 개선해나갑니다. **결과적으로** System 프롬프트는 AI를 팀의 일원으로 만드는 강력한 도구입니다. 단순히 코드를 생성하는 도구를 넘어서, 팀의 문화와 스타일을 이해하는 동료로 변신시킵니다. 김개발 씨는 이제 AI를 쓸 때마다 "우리 팀 스타일로 작성해줘"라고 일일이 말하지 않아도 됩니다. System 프롬프트가 자동으로 그 역할을 대신해주기 때문입니다. **실전 팁** 💡 - System 프롬프트를 Git 저장소에 포함시켜 팀원들과 공유하세요. `.ai-prompts/` 폴더를 만들어 버전 관리하면 좋습니다 - 프롬프트 마지막에 "이 규칙을 어길 경우 경고해주세요"를 추가하면, AI가 스스로 체크하고 알려줍니다 - 여러 모델(GPT-4, Claude 등)을 함께 쓴다면 각 모델별로 최적화된 System 프롬프트를 따로 만드세요. 모델마다 표현에 반응하는 방식이 다릅니다 --- ## 4. Few-shot으로 코드 패턴 학습시키기 팀에 새로운 아키텍처가 도입되었습니다. Repository 패턴을 사용하기로 했는데, AI는 이 패턴을 몰랐습니다. 김개발 씨가 "Repository 패턴으로 작성해줘"라고 했더니 완전히 다른 스타일의 코드가 나왔습니다. 박시니어 선배가 조언했습니다. "예시를 몇 개 보여주세요. Few-shot learning이라고, 예제로 패턴을 가르치는 겁니다." **Few-shot learning**은 AI에게 몇 가지 예시를 보여주고 패턴을 학습시키는 기법입니다. "이런 입력에는 이런 출력"이라는 예제를 2-5개 제시하면, AI가 패턴을 파악해서 새로운 상황에 적용합니다. 팀의 고유한 아키텍처, 독특한 코딩 패턴, 프로젝트 특화 구조를 AI에게 가르치는 가장 효과적인 방법입니다. 다음 코드를 살펴봅시다. ```python # Few-shot 프롬프트 예시 few_shot_prompt = """ 우리 팀의 Repository 패턴 예시를 보여드립니다. 예시 1 - User Repository: class UserRepository: def __init__(self, db: Session): self.db = db async def find_by_id(self, user_id: int) -> Optional[User]: return await self.db.query(User).filter(User.id == user_id).first() async def create(self, user_data: UserCreate) -> User: user = User(**user_data.dict()) self.db.add(user) await self.db.commit() return user 예시 2 - Product Repository: class ProductRepository: def __init__(self, db: Session): self.db = db async def find_by_id(self, product_id: int) -> Optional[Product]: return await self.db.query(Product).filter(Product.id == product_id).first() async def create(self, product_data: ProductCreate) -> Product: product = Product(**product_data.dict()) self.db.add(product) await self.db.commit() return product 위 패턴을 참고해서 Order Repository를 작성해주세요. """ ``` 김개발 씨의 팀은 코드 아키텍처를 대대적으로 리팩토링하기로 했습니다. Clean Architecture를 도입하고, Repository 패턴으로 데이터 레이어를 분리하기로 결정했습니다. 문제는 AI가 팀의 구체적인 Repository 구현 방식을 모른다는 것이었습니다. "Repository 패턴으로 Order 클래스 만들어줘"라고 요청했더니, 완전히 다른 스타일의 코드가 나왔습니다. 인터페이스를 먼저 정의하고, 추상 클래스를 만들고, 너무 복잡했습니다. 팀의 간결한 스타일과 전혀 맞지 않았습니다. **Few-shot learning이란?** 박시니어 선배가 알려준 해결책은 **Few-shot learning**이었습니다. 이것은 AI에게 문제 해결 방법을 설명하는 대신, **예시를 보여주는** 기법입니다. 마치 요리를 배울 때와 같습니다. "볶음밥은 밥을 기름에 볶고 야채를 넣고..."라고 긴 설명을 듣는 것보다, 요리사가 실제로 만드는 과정을 2-3번 보는 것이 훨씬 효과적입니다. AI도 마찬가지입니다. **Zero-shot vs Few-shot vs Many-shot** 용어를 정리해봅시다. **Zero-shot**은 예시 없이 지시만으로 작업하는 것입니다. "로그인 API 만들어줘"처럼 설명만 주는 방식입니다. **Few-shot**은 2-5개 정도의 예시를 주는 것입니다. "이런 입력에는 이런 출력, 저런 입력에는 저런 출력" 식으로 패턴을 보여줍니다. **Many-shot**은 수십 개 이상의 예시를 주는 것인데, 일반적으로 필요하지 않습니다. 대부분의 패턴은 2-5개 예시면 충분히 학습됩니다. **실전 Few-shot 적용 사례** 김개발 씨는 팀의 User Repository와 Product Repository 코드를 복사해서 프롬프트에 넣었습니다. 그리고 말했습니다. "위 두 개의 예시를 참고해서 Order Repository를 만들어주세요." 결과는 놀라웠습니다. AI가 생성한 Order Repository는 기존 두 클래스와 완벽하게 일치하는 구조를 가졌습니다. 생성자에서 `self.db`를 받고, `find_by_id` 메서드와 `create` 메서드를 같은 패턴으로 구현했습니다. 심지어 타입 힌트 스타일까지 똑같았습니다. **패턴 일반화 능력** Few-shot learning의 진짜 힘은 **패턴 일반화**입니다. 단순히 예시를 따라 하는 것이 아니라, 예시에서 규칙을 찾아내서 새로운 상황에 적용합니다. 예를 들어 User와 Product 예시에서 AI는 이런 패턴을 학습했습니다. "클래스명은 엔티티명 + Repository", "생성자는 db를 받는다", "find_by_id는 Optional을 반환한다", "create는 데이터 객체를 받아 엔티티를 반환한다" 등등. 이 패턴을 Order에 적용하니, 한 번도 본 적 없는 Order Repository를 완벽하게 만들어냈습니다. **몇 개의 예시가 적절할까요?** 연구 결과에 따르면 대부분의 경우 **2-3개 예시**가 최적입니다. 1개만 주면 우연일 수 있어 패턴을 확신하지 못합니다. 4-5개 이상은 토큰을 낭비할 뿐 성능 향상이 미미합니다. 단, 패턴이 복잡하거나 다양한 변형이 있다면 5개까지 보여주는 것이 좋습니다. 예를 들어 에러 처리 방식이 경우에 따라 다르다면, 각 경우를 대표하는 예시를 하나씩 제공합니다. **예시 선정의 기준** 좋은 Few-shot 예시는 **대표성**과 **다양성**을 모두 갖춰야 합니다. 가장 자주 사용되는 전형적인 패턴을 보여주되, 약간씩 다른 상황을 커버해야 합니다. 김개발 씨는 Repository 예시를 선택할 때 이렇게 했습니다. User는 가장 기본적인 CRUD를, Product는 비즈니스 로직이 포함된 경우를 보여줍니다. 두 예시가 겹치지 않으면서도 핵심 패턴은 공유하고 있습니다. **주석으로 패턴 강조하기** 예시 코드에 주석을 추가하면 효과가 더 좋습니다. AI가 어떤 부분에 주목해야 하는지 명확해지기 때문입니다. "여기서 주목할 점: 모든 Repository는 db를 생성자로 받습니다", "중요: find 메서드는 항상 Optional을 반환합니다" 같은 주석을 달아주면, AI가 핵심 패턴을 더 정확하게 파악합니다. **Anti-pattern도 보여주기** 때로는 "이렇게 하지 말 것"이라는 예시도 유용합니다. 잘못된 코드와 올바른 코드를 쌍으로 보여주면, AI가 실수를 피하게 됩니다. "이전 방식 (사용 금지):"와 "새로운 방식 (사용할 것):"을 나란히 보여주면, AI가 명확하게 차이를 인식합니다. 팀이 레거시에서 마이그레이션 중일 때 특히 유용합니다. **변형 생성도 가능합니다** Few-shot의 또 다른 장점은 **변형 생성**입니다. 예시를 주고 "이 패턴을 비동기 버전으로 바꿔주세요"라고 하면, 모든 예시를 async/await 패턴으로 변환해줍니다. 김개발 씨는 동기 버전 Repository 2개를 보여주고 "이 패턴을 FastAPI의 비동기 방식으로 변환해서 Order Repository를 만들어주세요"라고 요청했습니다. AI는 패턴을 이해하고, 비동기로 변환하고, Order 엔티티에 적용하는 세 가지를 동시에 해냈습니다. **프로젝트 온보딩 자동화** 팀은 Few-shot 예시 모음집을 만들었습니다. Repository, Service, Controller, DTO 등 각 레이어별로 대표 예시 2-3개를 문서화했습니다. 신입 개발자가 오면 이 예시집을 주고 "AI한테 코드 받을 때 이 예시들을 함께 제공하세요"라고 안내합니다. 덕분에 신입도 첫날부터 팀 스타일에 맞는 코드를 작성할 수 있게 되었습니다. **업데이트와 유지보수** Few-shot 예시는 **살아있는 문서**입니다. 팀의 코딩 패턴이 개선되면 예시도 함께 업데이트합니다. 더 나은 패턴을 발견하면 예시를 교체합니다. 김개발 씨 팀은 분기마다 예시를 리뷰합니다. "이 패턴은 deprecated 됐으니 제거하자", "새로운 에러 처리 방식을 예시에 추가하자" 같은 논의를 거쳐 계속 개선해나갑니다. **결론** Few-shot learning은 AI를 팀의 코딩 스타일에 빠르게 적응시키는 마법 같은 도구입니다. 긴 설명보다 2-3개의 좋은 예시가 훨씬 효과적입니다. 김개발 씨는 이제 새로운 기능을 추가할 때마다 기존 코드 2개를 복사해서 프롬프트에 넣는 습관이 생겼습니다. **실전 팁** 💡 - 예시 코드는 실제로 작동하는 완전한 코드를 사용하세요. 슈도코드나 일부만 보여주면 효과가 떨어집니다 - 예시들 사이의 차이점을 주석으로 명시하면 AI가 변형 요소를 더 잘 이해합니다. "이 예시는 페이지네이션 포함", "이 예시는 필터링 추가" 같은 식으로요 - 너무 긴 예시는 피하세요. 각 예시는 20-30줄 이내로, 핵심 패턴만 보여주는 것이 효과적입니다 --- ## 5. 실습: 3개 모델로 같은 과제 비교 실험 팀 회의에서 결정을 내려야 했습니다. "어떤 AI 코딩 도구를 공식 도구로 채택할까?" 의견이 분분했습니다. 김개발 씨는 실험을 제안했습니다. "실제 과제를 주고 GPT-4, Claude, Gemini의 결과를 직접 비교해보는 건 어떨까요?" 팀장님이 웃으며 고개를 끄덕였습니다. "좋아요. 실험 설계부터 시작해봅시다." 동일한 코딩 과제를 여러 모델에게 주고 결과를 비교하는 실험입니다. 각 모델의 강점과 약점을 객관적으로 파악할 수 있습니다. 코드 품질, 설명 상세도, 에러 처리, 보안 고려사항, 실행 가능성 등 여러 기준으로 평가합니다. 실제 프로젝트에 어떤 모델이 적합한지 데이터 기반으로 판단할 수 있습니다. 다음 코드를 살펴봅시다. ```python # 비교 실험 과제 예시 experiment_prompt = """ RESTful API 설계 과제: 블로그 게시글 관리 시스템의 백엔드 API를 작성하세요. 요구사항: - POST /posts : 게시글 생성 - GET /posts/{id} : 게시글 조회 - PUT /posts/{id} : 게시글 수정 - DELETE /posts/{id} : 게시글 삭제 - GET /posts : 게시글 목록 (페이지네이션 포함) 기술 스택: FastAPI + SQLAlchemy 검증 항목: ``` --- ## 5. 문서화 (주석, 독스트링) 김개발 씨는 비교 실험 책임자가 되었습니다. 공정한 테스트를 위해 실험 설계부터 신중하게 시작했습니다. 먼저 어떤 과제를 줄지 고민했습니다. 너무 쉬우면 차이가 안 나고, 너무 어려우면 모두 실패할 수 있습니다. 팀과 논의 끝에 실무에서 자주 마주치는 중간 난이도 과제를 선택했습니다. 블로그 게시글 CRUD API 만들기. 기본적이지만 에러 처리, 보안, 데이터 검증 등 여러 측면을 평가할 수 있는 과제였습니다. **공정한 실험 설계** 실험의 핵심은 **공정성**입니다. 세 모델에게 완전히 동일한 프롬프트를 주기로 했습니다. 한 모델에게만 더 자세한 설명을 주면 결과가 왜곡되니까요. 프롬프트는 최대한 중립적으로 작성했습니다. 특정 모델이 유리한 표현이나 힌트는 피했습니다. "FastAPI로 CRUD API를 만들어주세요"라는 간단명료한 지시와 함께 구체적인 요구사항 리스트를 제공했습니다. **실험 진행** 월요일 오전, 김개발 씨는 세 모델에게 동시에 같은 프롬프트를 보냈습니다. 각 모델의 응답 시간도 측정했습니다. GPT-4가 45초, Claude가 38초, Gemini가 42초 정도 걸렸습니다. 첫 인상은 흥미로웠습니다. GPT-4는 가장 긴 코드를 생성했습니다. 요구사항에 없던 인증 시스템까지 추가해서 제안했습니다. Claude는 단계별 설명과 함께 깔끔한 코드를 주었습니다. Gemini는 가장 최신 FastAPI 문법을 사용했고 코드가 가장 간결했습니다. **평가 기준 설정** 팀은 다섯 가지 기준으로 평가하기로 했습니다. 첫째, **코드 완성도**입니다. 실제로 실행 가능한가? 의존성이 명확한가? 복사해서 바로 쓸 수 있는가? 둘째, **에러 처리**입니다. 예외 상황을 고려했는가? 적절한 HTTP 상태 코드를 반환하는가? 사용자 친화적인 에러 메시지를 제공하는가? 셋째, **보안**입니다. SQL Injection 방지했는가? 입력 검증을 하는가? 민감한 정보 노출은 없는가? 넷째, **코드 품질**입니다. 가독성은 어떤가? 함수가 적절히 분리되어 있는가? 네이밍이 명확한가? 다섯째, **문서화**입니다. 주석이 적절한가? 독스트링이 있는가? 사용 방법 설명이 있는가? **GPT-4 결과 분석** GPT-4의 코드는 가장 포괄적이었습니다. CRUD 기본 기능뿐 아니라 JWT 인증, 권한 검사, 로깅까지 포함되어 있었습니다. 코드 품질도 우수했고, 각 함수마다 상세한 독스트링이 달려있었습니다. 하지만 과하다는 느낌도 있었습니다. 요구사항에 없던 기능들이 많아서 코드가 복잡했습니다. 초보 개발자가 이해하기엔 난이도가 높았습니다. 또한 일부 최신 라이브러리 문법이 구버전으로 작성되어 있었습니다. 점수는 완성도 9점, 에러 처리 10점, 보안 9점, 코드 품질 8점, 문서화 10점이었습니다. **Claude 결과 분석** Claude의 코드는 가장 균형 잡혔습니다. 요구사항을 정확히 만족하면서도 과하지 않았습니다. 특히 인상적이었던 것은 보안에 대한 설명이었습니다. "이 부분에서 SQLAlchemy ORM을 사용해 SQL Injection을 방지합니다", "Pydantic으로 입력 검증을 자동화합니다" 같은 상세한 설명이 코드 블록 아래에 달려있었습니다. 실제 코드에는 과도한 주석이 없어 깔끔했지만, 별도 설명에서 원리를 자세히 알려줬습니다. 에러 처리도 꼼꼼했습니다. 404 Not Found, 400 Bad Request, 500 Internal Server Error를 모두 구분해서 처리했습니다. 점수는 완성도 10점, 에러 처리 10점, 보안 10점, 코드 품질 9점, 문서화 8점이었습니다. **Gemini 결과 분석** Gemini의 코드는 가장 현대적이었습니다. FastAPI 0.104 버전의 최신 문법을 정확히 사용했고, Python 3.12의 새로운 타입 힌트 문법도 활용했습니다. 코드가 가장 간결하고 읽기 쉬웠습니다. 다만 설명이 다소 부족했습니다. 코드는 훌륭한데 왜 이렇게 작성했는지에 대한 설명이 간략했습니다. 또한 에러 처리가 기본적인 수준에 그쳤습니다. 복잡한 예외 상황은 고려하지 않았습니다. 점수는 완성도 9점, 에러 처리 7점, 보안 8점, 코드 품질 10점, 문서화 6점이었습니다. **실제 실행 테스트** 김개발 씨는 세 모델의 코드를 실제로 실행해봤습니다. 모두 잘 작동했습니다. GPT-4 코드는 의존성 설치가 조금 복잡했지만, 실행되면 가장 많은 기능을 제공했습니다. Claude 코드는 바로 실행되었고 안정적으로 동작했습니다. 잘못된 입력을 주어도 적절한 에러 메시지를 반환했습니다. Gemini 코드도 즉시 실행되었고, 응답 속도가 가장 빨랐습니다. 최신 비동기 처리 방식을 활용한 덕분이었습니다. **종합 평가 회의** 팀원들이 모여 결과를 논의했습니다. 총점은 Claude 47점, GPT-4 46점, Gemini 40점이었습니다. 하지만 단순 점수보다 중요한 것은 각 모델의 **특성**을 파악한 것이었습니다. "GPT-4는 기능을 많이 제안하니까, 아이디어 브레인스토밍할 때 좋겠어요." "Claude는 안전하고 설명이 자세하니까, 중요한 보안 기능을 만들 때 쓰면 되겠네요." "Gemini는 최신 문법을 잘 아니까, 새로운 프레임워크를 배울 때 유용하겠어요." **추가 실험들** 첫 실험이 성공적이어서 추가 실험도 진행했습니다. 프론트엔드 컴포넌트 만들기, 알고리즘 최적화, 데이터베이스 쿼리 튜닝 등 다양한 과제를 테스트했습니다. 흥미롭게도 과제 유형에 따라 순위가 바뀌었습니다. 알고리즘 문제에서는 GPT-4가 압도적이었고, UI 컴포넌트에서는 Gemini가 뛰어났으며, 리팩토링 과제에서는 Claude가 최고였습니다. **데이터 기반 의사결정** 팀은 실험 결과를 바탕으로 합리적인 결정을 내렸습니다. 메인 도구로 Claude를 채택하되, GPT-4와 Gemini도 보조로 구독하기로 했습니다. 각 모델의 강점을 활용하는 전략이었습니다. 김개발 씨는 실험 보고서를 작성해서 팀 위키에 올렸습니다. 앞으로 신입 개발자들이 참고할 수 있도록 말이죠. 체계적인 실험과 객관적인 데이터가 최선의 선택을 만들었습니다. **실전 팁** 💡 - 실험 과제는 실제 업무와 유사한 난이도로 설정하세요. 너무 쉽거나 어려우면 차이가 명확하지 않습니다 - 여러 유형의 과제를 테스트하세요. CRUD API, 알고리즘, UI 컴포넌트, 리팩토링 등 다양한 작업에서 모델 성능이 다르게 나타납니다 - 평가 기준을 사전에 명확히 정의하고 점수표를 만드세요. 주관적 판단을 최소화할 수 있습니다 --- ## 6. 실습: 나만의 코딩 스타일 시스템 프롬프트 작성 3개월간 AI 코딩 도구를 사용한 김개발 씨는 깨달았습니다. "매번 같은 말을 반복하고 있네." 타입 힌트 추가해달라고, 주석은 간단하게 해달라고, 변수명은 명확하게 해달라고. 박시니어 선배가 조언했습니다. "나만의 System 프롬프트를 만들어보세요. 한 번 작성해두면 계속 재사용할 수 있어요." 자신만의 코딩 스타일을 반영한 System 프롬프트를 작성하는 실습입니다. 선호하는 프로그래밍 언어, 자주 쓰는 프레임워크, 코딩 컨벤션, 금지 사항 등을 체계적으로 정리합니다. 이 프롬프트 하나로 모든 AI 대화에서 일관된 스타일의 코드를 받을 수 있습니다. 개인 개발자뿐 아니라 팀 전체가 공유할 수도 있습니다. 다음 코드를 살펴봅시다. ```python # 나만의 System 프롬프트 템플릿 my_system_prompt = """ # 당신의 역할 당신은 {경력}년 차 {분야} 개발자입니다. {프로그래밍_언어}와 {프레임워크}에 전문성을 가지고 있습니다. # 코딩 스타일 - 언어: {언어} ({버전}) - 프레임워크: {프레임워크} - 들여쓰기: {탭_또는_스페이스} ({개수}) - 최대 줄 길이: {숫자}자 - 네이밍 규칙: * 변수: {snake_case/camelCase} * 함수: {snake_case/camelCase} * 클래스: {PascalCase} * 상수: {UPPER_CASE} # 필수 사항 - [ ] 모든 함수에 타입 힌트 추가 - [ ] {독스트링_스타일} 스타일 독스트링 - [ ] 에러 처리는 {try-except/Result_타입} 사용 - [ ] 테스트 코드는 {pytest/jest} 사용 # 금지 사항 - [ ] print() 디버깅 금지 - [ ] 하드코딩된 비밀번호/API키 금지 - [ ] {사용하지_않는_라이브러리} 사용 금지 # 선호 라이브러리 - HTTP 클라이언트: {httpx/requests} - 날짜 처리: {arrow/pendulum/datetime} - 환경변수: {python-dotenv/pydantic-settings} """ # 실제 작성 예시 actual_prompt = """ # 당신의 역할 당신은 5년차 백엔드 개발자입니다. Python과 FastAPI에 전문성을 가지고 있습니다. # 코딩 스타일 - 언어: Python 3.11+ - 프레임워크: FastAPI - 들여쓰기: 스페이스 4개 - 최대 줄 길이: 88자 (Black 스타일) - 네이밍: snake_case (변수/함수), PascalCase (클래스) # 필수 사항 - 모든 함수에 타입 힌트 - Google 스타일 독스트링 - Pydantic으로 데이터 검증 - pytest로 테스트 작성 # 금지 사항 - print() 대신 logging 사용 - 환경변수 하드코딩 금지 - pandas 사용 금지 (polars 사용) # 선호 라이브러리 - HTTP: httpx - 날짜: pendulum - 환경변수: pydantic-settings """ ``` 김개발 씨는 노트북을 열고 지난 3개월간 AI에게 했던 요청들을 정리해봤습니다. "타입 힌트 추가해줘"를 27번, "주석은 간단하게 해줘"를 19번, "print 대신 logging 써줘"를 15번 반복했더군요. 이걸 매번 말하는 건 비효율의 극치였습니다. 드디어 나만의 System 프롬프트를 작성할 시간입니다. **1단계: 자기 분석** 먼저 자신의 개발 스타일을 객관적으로 분석해야 합니다. 김개발 씨는 질문지를 만들었습니다. "주로 어떤 언어로 개발하나?" - Python "자주 쓰는 프레임워크는?" - FastAPI, SQLAlchemy "코딩 컨벤션은?" - Black 포맷터 사용, 88자 제한, snake_case "절대 하지 않는 것은?" - print() 디버깅, 하드코딩 "항상 하는 것은?" - 타입 힌트, Google 독스트링, 단위 테스트 이렇게 질문에 답하다 보니 자신의 스타일이 명확해졌습니다. **2단계: 역할 정의** System 프롬프트는 AI에게 **역할**을 부여하는 것부터 시작합니다. "당신은 5년차 Python 백엔드 개발자입니다"라고 명시하면, AI가 그 수준과 전문성에 맞는 코드를 생성합니다. 김개발 씨는 "당신은 실용주의 Python 개발자입니다. 완벽한 코드보다 동작하는 코드를 선호하지만, 보안과 테스트는 절대 타협하지 않습니다"라고 작성했습니다. 이 한 문장이 AI의 전체적인 태도를 결정합니다. **3단계: 기술 스택 명시** 다음은 구체적인 기술 스택입니다. Python 버전, 주요 프레임워크, 선호하는 라이브러리를 명확히 합니다. "Python 3.11 이상 사용", "FastAPI 프레임워크 우선", "SQLAlchemy 2.0 문법", "httpx로 HTTP 클라이언트 구현" 같은 구체적인 지시를 넣었습니다. 특히 중요한 것은 **버전**입니다. "SQLAlchemy 2.0"이라고 명시하지 않으면 AI가 구버전 문법을 사용할 수 있습니다. **4단계: 코딩 컨벤션** 네이밍 규칙, 들여쓰기, 줄 길이 같은 세부 컨벤션을 정리합니다. 김개발 씨는 Black 포맷터를 쓰므로 "88자 제한", "스페이스 4개 들여쓰기"를 명시했습니다. 또한 "변수와 함수는 snake_case, 클래스는 PascalCase, 상수는 UPPER_CASE"라고 구체적으로 작성했습니다. 이렇게 하면 AI가 일관된 네이밍을 사용합니다. **5단계: 필수 요구사항** 항상 포함되어야 하는 요소들을 체크리스트로 만듭니다. - 모든 public 함수에 타입 힌트 필수 - Google 스타일 독스트링 작성 - Pydantic BaseModel로 데이터 검증 - 비즈니스 로직은 서비스 레이어에 - 데이터베이스 접근은 Repository 패턴 이 체크리스트가 있으면 AI가 코드를 생성할 때 자동으로 확인합니다. **6단계: 금지 사항** "절대 하지 말아야 할 것"도 명시합니다. 김개발 씨의 금지 리스트는 이렇습니다. - print() 디버깅 금지 (logging 사용할 것) - 환경변수 하드코딩 금지 - eval() 함수 사용 금지 - 전역 변수 남용 금지 - pandas 사용 금지 (polars 사용할 것) 마지막 항목이 흥미롭습니다. 김개발 씨 팀은 성능 이유로 pandas 대신 polars로 마이그레이션 중입니다. 이런 팀 특화 규칙도 프롬프트에 반영할 수 있습니다. **7단계: 응답 형식 지정** 코드만 달랑 주는 게 아니라, 어떻게 설명해줬으면 좋을지도 명시합니다. "코드 블록 위에 간단한 설명 추가", "복잡한 로직은 단계별 주석", "보안 고려사항이 있으면 별도 언급", "성능에 영향 주는 부분은 경고" 같은 응답 스타일 가이드를 넣었습니다. **8단계: 예시 첨부** 프롬프트 마지막에 "좋은 코드 예시"를 하나 첨부했습니다. 팀에서 가장 잘 작성된 함수 하나를 복사해서 "이런 스타일을 지향합니다"라고 명시했습니다. 이 예시가 앞서 설명한 모든 규칙을 실제로 구현한 샘플이 됩니다. AI는 이 예시를 참고해서 비슷한 품질의 코드를 생성합니다. **실전 테스트** 김개발 씨는 새로 만든 System 프롬프트를 GPT-4에 설정하고 테스트했습니다. "사용자 등록 API를 만들어줘"라고만 했는데, 결과물이 놀라웠습니다. 타입 힌트가 완벽하게 붙어있고, Google 스타일 독스트링이 작성되어 있고, Pydantic으로 입력 검증을 하고, logging으로 에러를 기록하고, 환경변수는 settings.py에서 불러오고, SQLAlchemy 2.0 문법을 정확히 사용했습니다. 단 한 줄의 추가 요청 없이, 프롬프트 하나만으로 완벽한 코드가 나왔습니다. **반복 개선** 첫 버전이 완벽할 순 없습니다. 김개발 씨는 일주일간 사용하면서 프롬프트를 계속 다듬었습니다. "아, AI가 async 함수를 만들 때 await를 빼먹네. 명시해야겠다." "독스트링에 예제가 없으면 이해하기 어려워. 예제 포함하라고 추가하자." "에러 메시지가 너무 기술적이야. 사용자 친화적으로 작성하라고 명시해야지." 이렇게 실사용 피드백을 반영해 프롬프트를 업데이트했습니다. **버전 관리** 김개발 씨는 System 프롬프트를 Git으로 관리하기 시작했습니다. `.ai-prompts/backend-v1.0.md` 파일로 저장하고, 변경할 때마다 버전을 올렸습니다. 커밋 메시지에 "Add async/await 명시", "Update polars 사용 권장사항" 같이 변경 내역을 기록했습니다. 마치 코드를 관리하듯 프롬프트도 관리하는 겁니다. **팀 공유** 효과가 좋아서 팀원들과 공유했습니다. 각자 자기 스타일대로 커스터마이징했지만, 기본 틀은 같았습니다. 덕분에 팀 전체 코드의 일관성이 크게 향상되었습니다. 박시니어 선배는 프론트엔드용 System 프롬프트도 만들었습니다. React, TypeScript, TailwindCSS 기반으로요. 디자이너와 협업할 때도 이 프롬프트를 공유해서, 디자이너가 AI로 코드를 생성할 때도 팀 스타일을 따르게 했습니다. **결과** 한 달 후, 김개발 씨의 생산성은 눈에 띄게 올랐습니다. 코드 리뷰에서 받는 스타일 관련 지적이 거의 사라졌습니다. AI가 처음부터 팀 컨벤션에 맞는 코드를 생성하니까요. 더 중요한 것은 **멘탈 에너지 절약**입니다. 매번 같은 요구사항을 반복할 필요가 없으니 피로도가 줄었습니다. 정작 중요한 비즈니스 로직에 집중할 수 있게 되었습니다. 나만의 System 프롬프트, 한 번 만들면 평생 가는 자산입니다. **실전 팁** 💡 - System 프롬프트는 300-500단어가 적정합니다. 너무 길면 AI가 모든 규칙을 완벽히 따르기 어렵습니다 - 주기적으로(한 달에 한 번) 프롬프트를 리뷰하고 업데이트하세요. 코딩 스타일도 계속 진화합니다 - 프로젝트별로 다른 프롬프트를 만들어 폴더로 관리하세요. `prompts/backend.md`, `prompts/frontend.md`, `prompts/data.md` 같은 식으로 분류하면 편리합니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: LLM,RLHF,모델비교

언어: Python

태그: Python, RLHF, GPT-4, Claude, Gemini, LLM,RLHF,모델비교

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

RLHF로 학습된 코딩 모델 완벽 활용 가이드

목차

1. GPT-4, Claude, Gemini 코딩 능력 비교

2. Instruction Following으로 정확한 코드 생성

3. System 프롬프트로 코딩 스타일 지정

4. Few-shot으로 코드 패턴 학습시키기

5. 실습: 3개 모델로 같은 과제 비교 실험

5. 문서화 (주석, 독스트링)

6. 실습: 나만의 코딩 스타일 시스템 프롬프트 작성

댓글 (0)

함께 보면 좋은 카드 뉴스

ReAct 패턴 마스터 완벽 가이드

AI 에이전트의 모든 것 - 개념부터 실습까지

프로덕션 RAG 시스템 완벽 가이드

RAG 캐싱 전략 완벽 가이드

실시간으로 답변하는 RAG 시스템 만들기