Instruction Design 패턴 완벽 가이드

LLM과 효과적으로 소통하기 위한 프롬프트 설계 패턴을 배웁니다. Clear-Specific-Complete 원칙부터 복잡한 태스크 분해까지, 실무에서 바로 활용할 수 있는 Instruction 작성법을 소개합니다.

---

목차

1. Clear_Specific_Complete_Instruction
2. 타입 힌트 포함
3. Instruction_Context_Example_구조
4. Step_by_Step_지시
5. 제약과_가이드라인_설정
6. 실습_Instruction_템플릿_라이브러리
7. 실습_복잡한_태스크_분해와_Instruction
8. get_cart_total(cart_id)

---

1. Clear Specific Complete Instruction

어느 날 최개발 씨는 AI에게 "코드 좀 만들어줘"라고 요청했습니다. 그런데 돌아온 결과는 예상과 전혀 달랐습니다.

선배 이시니어 씨가 말했습니다. "Instruction이 너무 애매해서 그래요."

Clear, Specific, Complete Instruction은 AI에게 명확하고 구체적이며 완전한 지시를 내리는 원칙입니다. 마치 레스토랑에서 주문할 때 "음식 주세요"가 아니라 "김치찌개 1인분, 밥 곁들여서, 덜 맵게 해주세요"라고 말하는 것처럼, AI에게도 정확한 요구사항을 전달해야 합니다.

다음 코드를 살펴봅시다.

# 나쁜 예: 애매한 Instruction
prompt_bad = "데이터 처리 코드 만들어줘"

# 좋은 예: Clear, Specific, Complete Instruction
prompt_good = """
CSV 파일을 읽어서 다음 작업을 수행하는 Python 함수를 작성해주세요:

---

5. 타입 힌트 포함

최개발 씨는 프로젝트 마감이 다가오는 월요일 오전, AI 도구를 활용해 코드를 빠르게 생성하려고 했습니다. "코드 좀 만들어줘"라고 입력했지만 결과는 기대와 달랐습니다.

어떤 언어로 작성할지, 어떤 기능을 구현할지 전혀 명시하지 않았기 때문입니다. 이시니어 씨가 최개발 씨의 화면을 보더니 웃으며 말했습니다.

"AI는 마음을 읽을 수 없어요. 정확히 말해줘야죠." Instruction Design이란 무엇일까요?

쉽게 비유하자면, Instruction은 마치 요리 레시피와 같습니다. "맛있는 요리 만들어줘"라고 하면 요리사는 무엇을 만들어야 할지 모릅니다.

하지만 "토마토 2개, 양파 1개, 올리브유 2스푼을 넣어 중불에서 15분간 볶은 후 소금으로 간해주세요"라고 하면 정확한 결과를 얻을 수 있습니다. 왜 이렇게 구체적으로 작성해야 할까요?

초창기 프로그래밍 시대에는 컴퓨터에게 모든 것을 0과 1로 설명해야 했습니다. 지금은 자연어로 소통할 수 있지만, 여전히 명확성이 중요합니다.

AI는 맥락을 추론할 수 있지만 완벽하지 않습니다. 애매한 지시는 예상 밖의 결과를 낳습니다.

Clear, Specific, Complete 원칙이 바로 이 문제를 해결합니다. Clear는 명확성을 의미합니다.

"좋은 코드"가 아니라 "PEP8 스타일 가이드를 따르는 코드"라고 말해야 합니다. Specific은 구체성입니다.

"데이터 처리"가 아니라 "결측치 제거와 정규화"처럼 정확히 무엇을 원하는지 명시합니다. Complete는 완전성입니다.

필요한 모든 정보, 제약사항, 출력 형식을 빠짐없이 포함합니다. 위의 코드를 살펴보겠습니다.

나쁜 예는 "데이터 처리 코드 만들어줘"라고만 했습니다. 어떤 데이터인지, 어떻게 처리할지, 어떤 언어를 쓸지 전혀 알 수 없습니다.

반면 좋은 예는 입력 형식(CSV), 구체적인 작업 단계(결측치 처리, 소문자 변환), 사용 라이브러리(pandas), 코드 스타일(타입 힌트)까지 명시했습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 플랫폼의 추천 시스템을 개발한다고 가정해봅시다. "추천 알고리즘 만들어줘"보다는 "사용자의 최근 30일 구매 이력과 클릭 로그를 기반으로 협업 필터링 방식의 상품 추천 함수를 Python으로 작성해주세요.

scikit-learn 사용, 추천 개수는 10개로 제한"이라고 요청하면 훨씬 정확한 결과를 얻습니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수는 너무 많은 정보를 한 번에 요구하는 것입니다. "회원가입, 로그인, 게시판, 결제 시스템을 포함한 완전한 웹사이트를 만들어줘"처럼 복잡한 요청은 오히려 결과물의 품질을 떨어뜨립니다.

적절히 작업을 분해해야 합니다. 다시 최개발 씨의 이야기로 돌아가봅시다.

이시니어 씨의 조언을 들은 최개발 씨는 Instruction을 다시 작성했습니다. 이번에는 원하는 결과를 정확히 얻을 수 있었습니다.

Clear, Specific, Complete 원칙을 기억하면 AI와의 협업이 훨씬 효율적이 됩니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해보세요.

실전 팁

💡 - 요청하기 전에 "이 지시만 보고 내가 직접 코드를 작성할 수 있을까?"를 자문해보세요

• 출력 형식, 사용 라이브러리, 에러 처리 방식까지 구체적으로 명시하세요
• 한 번에 하나의 명확한 작업에 집중하세요

---

2. Instruction Context Example 구조

박개발 씨는 AI에게 "REST API 엔드포인트 만들어줘"라고 했지만 결과물이 프로젝트와 맞지 않았습니다. 선배 정시니어 씨가 코드를 보더니 말했습니다.

"프로젝트 맥락을 알려줬어야죠."

Instruction-Context-Example 구조는 지시사항, 맥락 정보, 구체적 예시를 체계적으로 제공하는 패턴입니다. 마치 신입사원에게 업무를 설명할 때 "무엇을 할지(Instruction)", "왜 하는지와 환경 정보(Context)", "이렇게 하면 돼요(Example)"를 모두 알려주는 것과 같습니다.

다음 코드를 살펴봅시다.

# Instruction-Context-Example 구조로 작성한 프롬프트
prompt = """
[Instruction]
FastAPI를 사용해 사용자 정보를 조회하는 GET 엔드포인트를 작성해주세요.

[Context]
- 기존 프로젝트는 FastAPI + SQLAlchemy + PostgreSQL 구조입니다
- User 모델은 이미 정의되어 있으며 id, name, email 필드를 가집니다
- JWT 인증이 구현되어 있어 @require_auth 데코레이터를 사용합니다
- 응답은 Pydantic BaseModel을 사용한 타입 검증이 필요합니다

[Example]
기존 POST 엔드포인트 예시:
@router.post("/users")
@require_auth
async def create_user(user: UserCreate, db: Session = Depends(get_db)):
    return {"user": user_dict}

위와 유사한 스타일로 GET 엔드포인트를 작성해주세요.
"""

박개발 씨는 수요일 오후, 신규 기능 개발을 위해 AI에게 코드 생성을 요청했습니다. "REST API 엔드포인트 만들어줘"라는 간단한 요청이었습니다.

결과는 문법적으로 완벽했지만 문제가 있었습니다. 프로젝트에서 사용하는 프레임워크도 다르고, 인증 방식도 달랐습니다.

정시니어 씨가 다가와 물었습니다. "프로젝트 구조는 알려줬어요?" Instruction-Context-Example 구조란 정확히 무엇일까요?

이것을 이해하려면 마치 외국인 친구에게 서울 지하철 타는 법을 설명하는 상황을 생각해보세요. "2호선 타세요(Instruction)"라고만 하면 부족합니다.

"출근 시간이라 혼잡할 거예요. 여기서는 교통카드를 미리 충전해야 해요(Context)", "이렇게 개찰구에 카드를 찍고 들어가면 됩니다(Example)"까지 알려줘야 합니다.

AI도 마찬가지입니다. 단순 지시만으로는 한계가 있습니다.

과거에는 프로그래머가 모든 것을 처음부터 작성했습니다. 하지만 현대 개발은 기존 코드베이스 위에 새로운 기능을 추가하는 방식입니다.

프로젝트마다 고유한 컨벤션, 아키텍처, 라이브러리 선택이 있습니다. 이런 맥락 없이 코드를 생성하면 일관성이 깨집니다.

Instruction-Context-Example 패턴이 이 문제를 해결합니다. Instruction 부분에서는 명확한 작업 지시를 합니다.

"FastAPI GET 엔드포인트 작성"처럼 구체적으로 무엇을 원하는지 명시합니다. Context 부분에서는 프로젝트 환경, 기술 스택, 제약사항, 코딩 컨벤션을 설명합니다.

"FastAPI + SQLAlchemy 사용 중", "JWT 인증 필요" 같은 정보입니다. Example 부분에서는 비슷한 기존 코드를 보여줍니다.

이를 통해 AI는 코드 스타일과 패턴을 학습합니다. 코드 예시를 자세히 살펴보겠습니다.

Instruction 섹션에서 "GET 엔드포인트 작성"이라는 명확한 목표를 제시했습니다. Context 섹션에서는 네 가지 핵심 정보를 제공했습니다.

기술 스택(FastAPI, SQLAlchemy, PostgreSQL), 데이터 모델 구조, 인증 방식, 응답 검증 방법입니다. Example 섹션에서는 기존 POST 엔드포인트를 보여줘 코드 스타일을 명확히 전달했습니다.

실무에서 이 패턴은 매우 강력합니다. 예를 들어 대규모 레거시 시스템에 새 기능을 추가한다고 가정해봅시다.

"로그인 API 만들어줘"만으로는 부족합니다. 하지만 "기존 시스템은 Spring Boot를 사용하며, 세션 기반 인증을 사용합니다.

SecurityConfig에서 CORS 설정이 되어 있고, 모든 컨트롤러는 @RestController와 @RequestMapping을 사용합니다"라는 맥락과 함께 기존 회원가입 코드를 예시로 제공하면, AI는 프로젝트 스타일에 완벽히 맞는 코드를 생성합니다. 물론 주의할 점도 있습니다.

초보자들은 Example을 너무 길게 제공하는 경우가 많습니다. 전체 파일을 복사해 붙여넣기보다는 핵심 패턴을 보여주는 10-20줄 정도가 적당합니다.

또한 Context에 불필요한 정보를 과도하게 포함하면 오히려 혼란을 줄 수 있습니다. 관련 있는 정보만 선별해 제공하세요.

박개발 씨는 정시니어 씨의 조언대로 Instruction을 다시 작성했습니다. 이번에는 프로젝트 맥락과 예시 코드를 함께 제공했고, 결과물은 바로 사용할 수 있을 정도로 완벽했습니다.

Instruction-Context-Example 구조를 활용하면 AI가 여러분의 프로젝트를 이해하고 일관된 코드를 생성할 수 있습니다. 다음 프로젝트에서 꼭 시도해보세요.

실전 팁

💡 - Context는 기술 스택, 컨벤션, 제약사항 순으로 구조화하세요

• Example은 가장 유사한 기존 코드 조각을 선택하세요
• 너무 많은 정보보다는 핵심적인 맥락만 제공하세요

---

3. Step by Step 지시

김개발 씨는 AI에게 "데이터 파이프라인 만들어줘"라고 요청했지만 결과물이 너무 단순했습니다. 선배 송시니어 씨가 말했습니다.

"복잡한 작업은 단계별로 나눠서 지시해야죠."

Step-by-Step 지시는 복잡한 작업을 작은 단계들로 분해해 순차적으로 지시하는 패턴입니다. 마치 요리 레시피가 "1.

야채를 썬다, 2. 기름을 두른다, 3.

볶는다"처럼 단계별로 나뉘듯이, AI에게도 명확한 순서로 작업을 안내합니다.

다음 코드를 살펴봅시다.

# Step-by-Step으로 작성한 데이터 처리 Instruction
prompt = """
다음 단계를 순서대로 수행하는 Python 함수를 작성해주세요:

Step 1: CSV 파일 읽기
- pandas.read_csv() 사용
- encoding='utf-8' 설정

Step 2: 데이터 검증
- 필수 컬럼 존재 확인: ['user_id', 'timestamp', 'amount']
- 없으면 ValueError 발생

Step 3: 데이터 전처리
- timestamp를 datetime 타입으로 변환
- amount에서 음수 값 제거
- user_id 중복 제거 (최신 것만 유지)

Step 4: 집계 및 계산
- user_id별로 그룹화
- amount 합계 계산
- 결과를 딕셔너리로 반환 {user_id: total_amount}

각 단계는 명확히 구분되는 함수나 코드 블록으로 작성해주세요.
"""

김개발 씨는 금요일 오전, 데이터 분석 팀으로부터 급한 요청을 받았습니다. "사용자별 구매 금액을 집계하는 파이프라인이 필요해요." 시간이 촉박해 AI의 도움을 받기로 했습니다.

"데이터 파이프라인 만들어줘"라고 입력했지만 결과물은 기본적인 CSV 읽기 코드뿐이었습니다. 송시니어 씨가 김개발 씨의 모니터를 보며 말했습니다.

"파이프라인은 여러 단계로 이뤄져 있잖아요. 각 단계를 명확히 알려줘야죠." Step-by-Step 지시란 무엇을 의미할까요?

일상에서 가구를 조립할 때를 떠올려보세요. 설명서는 "1단계: 다리 4개를 바닥판에 나사로 고정", "2단계: 상판을 다리 위에 올리기", "3단계: 보강재 끼우기"처럼 세세하게 나뉘어 있습니다.

만약 "가구 조립하세요"라고만 적혀 있다면 어떻게 해야 할지 막막할 것입니다. AI에게 복잡한 작업을 지시할 때도 마찬가지입니다.

초기 프로그래밍 교육에서는 "문제를 작게 나눠라"는 원칙을 강조합니다. 이것을 **분해(Decomposition)**라고 부릅니다.

큰 문제는 작은 문제들의 조합입니다. "데이터 파이프라인"이라는 큰 개념은 실제로는 읽기, 검증, 전처리, 계산, 저장 같은 여러 하위 작업으로 구성됩니다.

Step-by-Step 지시는 이 분해 원칙을 Instruction에 적용한 것입니다. 각 단계를 명확히 정의하면 여러 장점이 있습니다.

첫째, AI가 각 단계의 목적을 정확히 이해합니다. 둘째, 중간 단계에서 에러가 발생했을 때 디버깅이 쉽습니다.

셋째, 코드 가독성이 높아집니다. 각 단계가 독립적인 함수나 블록으로 구현되기 때문입니다.

코드 예시를 단계별로 살펴보겠습니다. Step 1에서는 파일 읽기라는 명확한 작업과 함께 구체적인 파라미터(encoding)까지 지정했습니다.

Step 2에서는 데이터 품질 검증을 다룹니다. 필수 컬럼이 없으면 즉시 에러를 발생시켜야 합니다.

Step 3은 실제 데이터 정제 작업입니다. 타입 변환, 이상치 제거, 중복 처리를 순서대로 수행합니다.

Step 4에서는 비즈니스 로직인 집계 계산을 처리하고 원하는 형식으로 반환합니다. 실무에서 이 패턴의 위력을 느낄 수 있습니다.

예를 들어 이미지 처리 파이프라인을 개발한다고 가정해봅시다. "이미지 전처리 코드 작성"이라는 모호한 요청 대신, "Step 1: PIL로 이미지 로드, Step 2: 크기를 224x224로 리사이즈, Step 3: numpy 배열로 변환, Step 4: 정규화(0-1 범위), Step 5: 배치 차원 추가"처럼 세분화하면 정확히 원하는 전처리 코드를 얻습니다.

하지만 주의해야 할 점이 있습니다. 너무 세세하게 나누면 오히려 복잡도가 증가합니다.

"Step 1-1: import pandas 작성, Step 1-2: 파일 경로 변수 선언"처럼 지나치게 미시적인 단계는 불필요합니다. 적절한 추상화 수준을 유지하세요.

또한 단계 간 의존성을 명확히 해야 합니다. Step 3이 Step 2의 결과에 의존한다면 이를 명시하세요.

김개발 씨는 송시니어 씨의 조언을 받아들여 작업을 4단계로 나눴습니다. 각 단계에 필요한 구체적인 작업과 파라미터를 명시했고, 결과물은 완벽했습니다.

데이터 분석 팀도 만족했습니다. Step-by-Step 지시를 활용하면 복잡한 작업도 체계적으로 처리할 수 있습니다.

여러분의 다음 프로젝트에서 이 패턴을 적용해보세요.

실전 팁

💡 - 각 단계는 하나의 명확한 목적을 가져야 합니다

• 단계 간 입력과 출력을 명시하면 더욱 정확합니다
• 3-7단계가 적당하며, 너무 많으면 오히려 복잡해집니다

---

4. 제약과 가이드라인 설정

이개발 씨는 AI가 생성한 코드를 보고 놀랐습니다. 수백 줄의 복잡한 클래스가 나왔기 때문입니다.

선배 강시니어 씨가 웃으며 말했습니다. "제약 조건을 안 알려줬으니 AI가 최대한 복잡하게 만든 거예요."

제약과 가이드라인 설정은 코드 길이, 사용 가능한 라이브러리, 성능 요구사항, 코딩 스타일 같은 제한 사항을 명시하는 패턴입니다. 마치 건축가에게 "예산 1억, 면적 30평, 2층 이하"라는 조건을 주듯이, AI에게도 명확한 경계를 설정합니다.

다음 코드를 살펴봅시다.

# 제약과 가이드라인이 포함된 Instruction
prompt = """
사용자 인증 함수를 작성해주세요.

[제약 조건]
- 코드 길이: 50줄 이내
- 외부 라이브러리: 표준 라이브러리만 사용 (no pip install)
- Python 버전: 3.8+ 호환
- 성능: O(1) 시간 복잡도로 검증

[가이드라인]
- 함수명: snake_case 사용
- 독스트링: Google 스타일로 작성
- 타입 힌트: 모든 파라미터와 반환값에 명시
- 에러 처리: try-except 대신 명시적 검증 선호
- 보안: 비밀번호는 절대 로그에 출력하지 않음

[필수 기능]
- 이메일과 비밀번호 검증
- 간단한 해싱 (실제 배포용 아님)
- True/False 반환
"""

이개발 씨는 화요일 오후, 간단한 인증 로직이 필요했습니다. "사용자 인증 함수 만들어줘"라고 AI에게 요청했습니다.

결과물을 보고 깜짝 놀랐습니다. JWT 토큰, Redis 캐싱, 복잡한 암호화 라이브러리까지 포함된 200줄짜리 코드가 생성됐습니다.

강시니어 씨가 화면을 보고 웃었습니다. "AI는 제약이 없으면 최대한 포괄적으로 만들려고 해요.

필요한 것만 만들도록 경계를 설정해야죠." 제약과 가이드라인이란 정확히 무엇일까요? 프로젝트를 발주할 때를 생각해보세요.

"웹사이트 만들어주세요"만 말하면 제작사는 어떤 규모로 만들어야 할지 모릅니다. 하지만 "예산 500만원, 페이지 5개, 반응형 디자인 필수, 2주 내 완성"이라는 제약을 주면 명확해집니다.

제약은 방향을 제시하고 불필요한 작업을 막습니다. AI 코드 생성에서도 같은 원리가 적용됩니다.

과거 소프트웨어 개발에서는 "골드 플레이팅(Gold Plating)"이라는 문제가 있었습니다. 요구하지 않은 기능까지 과도하게 구현하는 것입니다.

이것은 시간 낭비이자 유지보수 부담입니다. AI도 제약이 없으면 비슷한 경향을 보입니다.

최대한 범용적이고 확장 가능한 코드를 생성하려 합니다. 제약과 가이드라인 설정이 이를 방지합니다.

제약 조건에는 여러 종류가 있습니다. 기술적 제약은 사용 가능한 라이브러리, 언어 버전, 호환성 요구사항을 다룹니다.

성능 제약은 시간 복잡도, 메모리 사용량, 응답 시간을 명시합니다. 규모 제약은 코드 길이, 파일 개수, 함수 개수를 제한합니다.

스타일 가이드라인은 네이밍 컨벤션, 주석 스타일, 에러 처리 방식을 정의합니다. 코드 예시를 자세히 분석해보겠습니다.

제약 조건 섹션에서 네 가지 명확한 한계를 설정했습니다. 50줄 이내로 코드 크기를 제한하고, 표준 라이브러리만 사용하도록 했습니다.

Python 3.8 호환성을 요구하고, O(1) 시간 복잡도를 명시했습니다. 가이드라인 섹션에서는 다섯 가지 코딩 스타일을 정의했습니다.

네이밍, 문서화, 타입 힌트, 에러 처리, 보안 사항입니다. 실무에서 이 패턴은 매우 중요합니다.

예를 들어 임베디드 시스템용 코드를 작성한다고 가정해봅시다. "센서 데이터 처리 코드"만 요청하면 AI는 numpy, pandas 같은 무거운 라이브러리를 사용할 수 있습니다.

하지만 "제약: 메모리 512KB 이내, 외부 라이브러리 없음, C 표준 라이브러리만 사용, 실시간 처리 필수(1ms 이내)"라고 명시하면 제약에 맞는 최적화된 코드를 얻습니다. 주의할 점도 있습니다.

제약을 너무 엄격하게 설정하면 구현 자체가 불가능해질 수 있습니다. "10줄 이내로 머신러닝 모델 작성"처럼 모순된 요구는 피해야 합니다.

또한 제약과 가이드라인이 충돌하지 않도록 주의하세요. "최대 성능 필요"와 "표준 라이브러리만 사용"은 때로 양립하기 어렵습니다.

이개발 씨는 강시니어 씨의 조언대로 제약 조건을 추가했습니다. 50줄 이내, 표준 라이브러리만 사용, 간단한 해싱이라고 명시했습니다.

결과물은 딱 필요한 만큼만 구현된 깔끔한 코드였습니다. 제약과 가이드라인을 명확히 설정하면 과도한 엔지니어링을 방지하고 요구사항에 정확히 맞는 코드를 얻을 수 있습니다.

다음 프로젝트에서 꼭 활용해보세요.

실전 팁

💡 - 제약은 "반드시 지켜야 할 것", 가이드라인은 "선호하는 방식"으로 구분하세요

• 성능 제약은 구체적인 숫자로 명시하세요 (예: "1초 이내", "메모리 100MB 이하")
• 프로젝트 초기에 팀 전체의 제약과 가이드라인을 문서화해두면 재사용이 쉽습니다

---

5. 실습 Instruction 템플릿 라이브러리

조개발 씨는 매번 비슷한 요청을 할 때마다 Instruction을 처음부터 작성했습니다. 선배 한시니어 씨가 말했습니다.

"자주 쓰는 패턴은 템플릿으로 만들어두면 훨씬 효율적이에요."

Instruction 템플릿 라이브러리는 자주 사용하는 작업 패턴을 재사용 가능한 템플릿으로 저장하는 방법입니다. 마치 개발자가 코드 스니펫을 모아두듯이, 효과적인 Instruction 패턴을 라이브러리화하면 생산성이 크게 향상됩니다.

다음 코드를 살펴봅시다.

# Instruction 템플릿 라이브러리 예시
templates = {
    "api_endpoint": """
    [Instruction]
    {method} 메서드로 {resource} API 엔드포인트를 작성해주세요.

    [Context]
    - 프레임워크: {framework}
    - 인증: {auth_method}
    - DB: {database}

    [Requirements]
    - 입력 검증 포함
    - 에러 핸들링 필수
    - {response_format} 형식으로 응답
    """,

    "data_processing": """
    [Task]
    {input_format} 파일을 읽어 다음 작업 수행:
    {steps}

    [Constraints]
    - 라이브러리: {allowed_libs}
    - 성능: {performance_req}
    - 코드 길이: {max_lines}줄 이내
    """,

    "unit_test": """
    다음 함수에 대한 pytest 테스트를 작성해주세요:
    {function_code}

    [Test Cases]
    - 정상 케이스: {normal_cases}
    - 예외 케이스: {edge_cases}
    - Mock 필요: {mocks}
    """
}

# 사용 예시
api_instruction = templates["api_endpoint"].format(
    method="POST",
    resource="사용자 등록",
    framework="FastAPI",
    auth_method="JWT",
    database="PostgreSQL",
    response_format="JSON"
)

조개발 씨는 목요일 오전, 새로운 API 엔드포인트 10개를 구현해야 했습니다. 첫 번째 엔드포인트를 위해 상세한 Instruction을 작성했고 좋은 결과를 얻었습니다.

하지만 두 번째, 세 번째를 만들 때도 계속 비슷한 내용을 반복해서 작성해야 했습니다. 한시니어 씨가 조개발 씨의 작업을 보고 조언했습니다.

"첫 번째 Instruction을 템플릿으로 만들어두세요. 필요한 부분만 바꿔서 재사용하면 됩니다." Instruction 템플릿 라이브러리란 무엇일까요?

소프트웨어 개발에서 디자인 패턴을 떠올려보세요. 싱글톤, 팩토리, 옵저버 같은 패턴들은 반복되는 문제에 대한 검증된 해결책입니다.

매번 처음부터 설계하지 않고 패턴을 적용합니다. Instruction도 마찬가지입니다.

API 생성, 데이터 처리, 테스트 작성 같은 작업은 프로젝트마다 반복됩니다. 이런 반복 작업을 템플릿화하면 효율이 극대적으로 올라갑니다.

과거에는 개발자가 모든 것을 직접 타이핑했습니다. 하지만 IDE의 발전과 함께 코드 스니펫, 라이브 템플릿 같은 도구가 등장했습니다.

"for"만 입력하면 전체 for 루프가 자동 완성되는 것처럼요. Instruction 템플릿은 이 개념을 프롬프트 작성에 적용한 것입니다.

템플릿 라이브러리를 구축하는 방법을 알아봅시다. 먼저 자주 수행하는 작업 유형을 파악합니다.

API 엔드포인트 생성, 데이터 처리 파이프라인, 유닛 테스트, 리팩토링, 문서화 같은 카테고리로 분류합니다. 각 카테고리마다 기본 템플릿을 만듭니다.

템플릿에는 **변수(placeholder)**를 사용합니다. Python의 format 메서드나 f-string을 활용하면 편리합니다.

코드 예시를 살펴보겠습니다. 세 가지 템플릿을 정의했습니다.

api_endpoint 템플릿은 REST API 생성에 특화되어 있습니다. method, resource, framework 같은 변수를 두어 유연하게 사용할 수 있습니다.

data_processing 템플릿은 ETL 작업에 적합합니다. input_format, steps, allowed_libs 같은 파라미터로 커스터마이징합니다.

unit_test 템플릿은 테스트 코드 생성에 최적화되어 있습니다. 사용 예시를 보면 매우 간단합니다.

templates 딕셔너리에서 원하는 템플릿을 선택하고 format 메서드로 변수만 채우면 됩니다. 몇 줄의 코드로 상세한 Instruction이 완성됩니다.

실무에서 이것의 효과는 엄청납니다. 대규모 마이크로서비스 프로젝트를 개발한다고 가정해봅시다.

수십 개의 서비스마다 비슷한 CRUD API가 필요합니다. 템플릿 없이는 매번 "FastAPI 사용, PostgreSQL 연결, JWT 인증, Pydantic 검증, 에러 핸들링..."을 반복해서 작성해야 합니다.

하지만 템플릿이 있다면 리소스 이름만 바꿔서 일관된 Instruction을 생성할 수 있습니다. 템플릿 관리에도 노하우가 있습니다.

개인적으로는 노션이나 Obsidian 같은 도구에 템플릿을 저장합니다. 팀 단위로는 Git 저장소에 markdown 파일로 관리하면 좋습니다.

버전 관리가 되고 팀원 간 공유도 쉽습니다. 더 나아가 Python 스크립트나 CLI 도구로 만들어 터미널에서 바로 생성하는 방법도 있습니다.

주의할 점도 있습니다. 템플릿이 너무 복잡하면 오히려 사용하기 어렵습니다.

변수가 10개 이상이면 차라리 직접 작성하는 게 나을 수 있습니다. 또한 템플릿은 지속적으로 개선해야 합니다.

처음 만든 템플릿이 완벽할 수 없습니다. 사용하면서 피드백을 반영해 업데이트하세요.

조개발 씨는 한시니어 씨의 조언을 따라 자신만의 템플릿 라이브러리를 만들었습니다. API, 데이터 처리, 테스트 세 가지 템플릿으로 시작했습니다.

10개의 엔드포인트를 절반의 시간에 완성할 수 있었습니다. Instruction 템플릿 라이브러리를 구축하면 반복 작업이 크게 줄어듭니다.

오늘부터 자주 쓰는 패턴을 모아보세요. 3개월 후 여러분의 생산성은 놀랍게 향상될 것입니다.

실전 팁

💡 - 처음에는 3-5개의 핵심 템플릿으로 시작하세요

• 템플릿에 사용 예시를 함께 저장하면 나중에 참고하기 좋습니다
• 팀 템플릿 라이브러리를 만들면 일관성과 품질이 모두 향상됩니다

---

6. 실습 복잡한 태스크 분해와 Instruction

윤개발 씨는 "전자상거래 시스템 만들어줘"라고 AI에게 요청했지만 결과물은 엉망이었습니다. 선배 오시니어 씨가 말했습니다.

"복잡한 시스템은 작은 태스크로 분해해야 해요."

복잡한 태스크 분해는 큰 프로젝트를 독립적이고 관리 가능한 작은 작업 단위로 나누는 기법입니다. 마치 퍼즐을 맞추듯이, 각 조각을 완성한 후 조합하면 전체 시스템이 완성됩니다.

각 조각마다 명확한 Instruction을 작성합니다.

다음 코드를 살펴봅시다.

# 복잡한 태스크를 분해한 예시: 전자상거래 장바구니 시스템

# Task 1: 데이터 모델 정의
task_1 = """
장바구니 시스템의 데이터 모델을 SQLAlchemy로 작성해주세요.

[Models]

---

4. get cart total(cart id)

윤개발 씨는 월요일 아침, 새로운 프로젝트를 시작했습니다. "전자상거래 플랫폼을 만들어야 해요." 야심 찬 마음으로 AI에게 "전자상거래 시스템 전체를 만들어줘"라고 입력했습니다.

결과는 실망스러웠습니다. 일부 기능은 빠져있고, 코드는 서로 맞지 않았으며, 구조도 엉망이었습니다.

오시니어 씨가 윤개발 씨의 화면을 보고 고개를 저었습니다. "코끼리를 한 입에 먹을 순 없잖아요.

작게 나눠서 하나씩 해결해야죠." 복잡한 태스크 분해란 정확히 무엇을 의미할까요? 집을 짓는 과정을 상상해보세요.

"집을 지어주세요"라고만 하면 불가능합니다. 하지만 "1단계: 기초 공사, 2단계: 골조 세우기, 3단계: 지붕 올리기, 4단계: 내부 마감"처럼 나누면 관리 가능해집니다.

각 단계는 독립적으로 완성되고, 순서대로 진행되며, 최종적으로 집이 완성됩니다. 소프트웨어 개발도 동일한 원리입니다.

컴퓨터 과학에서는 이것을 분할 정복(Divide and Conquer) 알고리즘이라고 부릅니다. 큰 문제를 작은 문제로 나누고, 각각을 해결한 후, 결과를 합칩니다.

퀵소트, 병합정렬 같은 알고리즘이 이 원리를 사용합니다. AI Instruction에서도 같은 접근이 유효합니다.

태스크 분해를 어떻게 수행할까요? 먼저 시스템을 레이어로 나눕니다.

데이터 레이어(모델, 스키마), 비즈니스 레이어(로직, 서비스), 인터페이스 레이어(API, UI), 테스트 레이어로 구분합니다. 각 레이어는 독립적으로 개발 가능합니다.

다음으로 각 레이어를 기능 단위로 세분화합니다. 장바구니, 주문, 결제, 배송처럼 도메인별로 나눕니다.

각 태스크는 SMART 원칙을 따라야 합니다. Specific(구체적), Measurable(측정 가능), Achievable(달성 가능), Relevant(관련성), Time-bound(시간 제한).

"인증 시스템"보다는 "JWT 기반 로그인 API, 회원가입 API, 토큰 갱신 API 작성"이 SMART합니다. 코드 예시를 단계별로 분석해봅시다.

Task 1은 데이터 모델 정의입니다. 장바구니와 장바구니 아이템이라는 두 개의 엔티티만 다룹니다.

관계, 제약, 인덱스까지 명시했습니다. 이 태스크는 독립적으로 완성되고 테스트 가능합니다.

Task 2는 비즈니스 로직입니다. CRUD 함수 네 개를 정의했습니다.

각 함수의 책임이 명확하고, Task 1의 모델을 사용합니다. Task 3은 API 레이어입니다.

Task 2의 함수를 활용하므로 의존성이 명확합니다. 이런 분해의 장점은 여러 가지입니다.

첫째, 병렬 작업이 가능합니다. 팀원 A는 데이터 모델을, B는 비즈니스 로직을 동시에 개발할 수 있습니다.

둘째, 디버깅이 쉽습니다. 문제가 생기면 어느 태스크에서 발생했는지 빠르게 찾을 수 있습니다.

셋째, 테스트가 간단합니다. 각 태스크마다 유닛 테스트를 작성하면 전체 시스템의 품질이 보장됩니다.

실무 사례를 살펴봅시다. 넷플릭스 같은 스트리밍 서비스를 개발한다고 가정해봅시다.

"스트리밍 플랫폼 만들기"는 너무 큽니다. 하지만 "1.

사용자 인증 시스템, 2. 비디오 메타데이터 관리, 3.

스트리밍 서버 연동, 4. 추천 알고리즘, 5.

결제 시스템"으로 나누고, 각각을 더 작은 태스크로 분해하면 관리 가능해집니다. 각 태스크마다 명확한 Instruction을 작성하고 순차적으로 구현합니다.

분해할 때 주의사항이 있습니다. 너무 작게 나누면 오버헤드가 증가합니다.

"변수 선언", "import 문 작성" 같은 미시적 태스크는 불필요합니다. 적절한 추상화 수준을 유지하세요.

또한 태스크 간 의존성을 명확히 해야 합니다. "Task 3은 Task 2 완료 후 시작"처럼 순서를 정의하세요.

순환 의존성은 피해야 합니다. 윤개발 씨는 오시니어 씨와 함께 프로젝트를 분해했습니다.

전자상거래 시스템을 20개의 작은 태스크로 나눴습니다. 각 태스크마다 명확한 Instruction을 작성하고 하나씩 구현했습니다.

3주 후, 윤개발 씨는 첫 버전을 성공적으로 완성했습니다. 복잡한 태스크 분해는 대규모 프로젝트를 성공시키는 핵심 기술입니다.

처음에는 어렵지만 연습하면 자연스러워집니다. 여러분의 다음 프로젝트에서 이 기법을 적용해보세요.

실전 팁

💡 - 분해 단계: 시스템 → 레이어 → 도메인 → 기능 → 태스크 순으로 나눠갑니다

• 각 태스크는 1-3일 내에 완료 가능한 크기가 적당합니다
• 태스크 간 의존성을 그래프로 그려보면 순서를 정하기 쉽습니다
• 완료된 태스크는 즉시 통합 테스트를 수행해 문제를 조기에 발견하세요

---

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