완벽한 코드 생성 프롬프트 설계 가이드

LLM으로 정확한 코드를 생성하기 위한 프롬프트 작성 기법을 실무 관점에서 다룹니다. Instruction-Context-Example 구조부터 실전 템플릿 라이브러리 구축까지, 초급 개발자도 쉽게 따라할 수 있는 베스트셀러 스타일의 완벽 가이드입니다.

---

목차

1. Instruction-Context-Example 구조 적용
2. 요구사항 명세를 프롬프트로 변환
3. 코드 스타일 가이드 주입
4. 에러 처리와 엣지 케이스 고려
5. External Dependencies
6. 실습: 프롬프트 템플릿 라이브러리 구축
7. 에러 케이스: {error_cases}
8. 실습: 언어별/프레임워크별 템플릿 작성

---

1. Instruction-Context-Example 구조 적용

입사 2개월 차인 김개발 씨는 ChatGPT에게 코드를 요청했습니다. "로그인 기능 만들어줘"라고 입력했지만, 돌아온 코드는 실무에 쓸 수 없는 간단한 예제였습니다.

왜 원하는 결과가 나오지 않았을까요?

ICE 구조는 Instruction-Context-Example의 약자로, LLM에게 명확한 지시를 전달하는 프롬프트 설계 패턴입니다. 마치 신입 사원에게 업무를 지시할 때 '무엇을(Instruction)', '왜 필요한지(Context)', '어떻게 하는지(Example)'를 모두 알려주는 것과 같습니다.

이 구조를 사용하면 LLM이 정확히 원하는 코드를 생성할 확률이 크게 높아집니다.

다음 코드를 살펴봅시다.

# ICE 구조를 적용한 프롬프트 템플릿
prompt_template = """
# Instruction (명령)
{task_description}을(를) 구현하는 Python 함수를 작성해주세요.

# Context (맥락)
- 프로젝트: {project_type}
- 사용 환경: {environment}
- 제약사항: {constraints}

# Example (예시)
입력: {input_example}
출력: {output_example}

# 추가 요구사항
- {requirement_1}
- {requirement_2}
"""

# 실제 사용 예
prompt = prompt_template.format(
    task_description="이메일 유효성 검사",
    project_type="FastAPI 백엔드 서비스",
    environment="Python 3.11, Pydantic 사용",
    constraints="정규표현식 사용 금지, 외부 라이브러리 최소화",
    input_example="user@example.com",
    output_example="True",
    requirement_1="국제 도메인 지원",
    requirement_2="명확한 에러 메시지 반환"
)

김개발 씨는 퇴근길에 선배 박시니어 씨와 저녁을 먹으며 고민을 털어놓았습니다. "GPT한테 코드 부탁하면 맨날 이상한 게 나와요.

실무에선 못 쓰겠더라고요." 박시니어 씨가 고개를 끄덕이며 말했습니다. "아, 프롬프트를 어떻게 작성했는데?" 김개발 씨가 핸드폰을 꺼내 보여줍니다.

"로그인 기능 만들어줘"라고 적혀 있었습니다. "문제를 찾았네요.

이건 마치 식당에서 '밥 주세요'라고만 하는 것과 같아요. 무슨 밥인지, 어떻게 요리할건지, 어떤 양념을 쓸건지 하나도 안 알려줬잖아요." ICE 구조란 정확히 무엇일까요?

쉽게 비유하자면, ICE 구조는 요리사에게 레시피를 전달하는 것과 같습니다. Instruction은 "불고기를 만들어주세요"라는 주문이고, Context는 "손님이 매운 걸 못 드셔요, 간장 베이스로 해주세요"라는 배경 정보입니다.

Example은 "지난번에 만들어준 닭갈비처럼 양념이 배도록 해주세요"라는 참고 사례입니다. LLM도 마찬가지입니다.

명확한 지시(Instruction), 상황 설명(Context), 구체적인 예시(Example)를 모두 제공해야 정확한 결과를 얻을 수 있습니다. 왜 ICE 구조가 필요할까요? 초창기 개발자들은 LLM에게 "함수 만들어줘"라는 식의 짧은 명령만 내렸습니다.

결과는 천차만별이었습니다. 어떤 때는 훌륭한 코드가, 어떤 때는 전혀 쓸모없는 코드가 나왔습니다.

더 큰 문제는 재현성이었습니다. 같은 질문을 해도 매번 다른 답이 나왔습니다.

프로젝트가 커질수록 이런 불확실성은 치명적이었습니다. 팀원마다 다른 스타일의 코드를 받아오면 코드베이스가 난장판이 되기 때문입니다.

ICE 구조로 해결하는 방법 바로 이런 문제를 해결하기 위해 ICE 구조가 등장했습니다. ICE 구조를 사용하면 일관성 있는 코드 생성이 가능해집니다.

같은 프롬프트는 언제나 비슷한 품질의 결과를 내놓습니다. 또한 팀 전체가 동일한 기준으로 LLM을 활용할 수 있습니다.

무엇보다 명확한 요구사항 전달로 수정 작업이 크게 줄어듭니다. 프롬프트 템플릿 코드 분석 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 2번째 줄의 Instruction 섹션을 보면 무엇을 만들어야 하는지 명확히 지시하고 있습니다. 단순히 "코드 만들어줘"가 아니라 "Python 함수를 작성해주세요"라고 구체적으로 명시합니다.

5번째 줄부터의 Context 섹션에서는 프로젝트 타입, 사용 환경, 제약사항을 알려줍니다. 이 정보가 있으면 LLM은 FastAPI에 맞는 코드를 생성하고, Python 3.11의 최신 문법을 활용하며, Pydantic 모델과 호환되는 코드를 작성합니다.

10번째 줄의 Example 섹션은 입출력 예시를 보여줍니다. 이것이 핵심입니다.

말로 설명하는 것보다 예시 하나가 훨씬 명확하기 때문입니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

예를 들어 전자상거래 플랫폼을 개발하는 스타트업이 있다고 가정해봅시다. 결제 모듈을 만들어야 하는데, 개발자마다 LLM에게 다르게 요청하면 일관성 없는 코드가 쌓입니다.

하지만 ICE 구조의 표준 템플릿을 만들어두면, 신입이든 시니어든 동일한 품질의 초안을 받을 수 있습니다. 네이버, 카카오 같은 대기업에서도 사내 LLM 활용 가이드라인에 ICE 패턴을 권장하고 있습니다.

코드 리뷰 시간이 30% 이상 단축되었다는 보고도 있습니다. 초보자가 흔히 하는 실수 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 Context를 너무 길게 작성하는 것입니다. 10줄이 넘는 배경 설명을 쓰면 오히려 LLM이 핵심을 놓칠 수 있습니다.

따라서 핵심 정보 3-5개로 압축하는 것이 좋습니다. 또 다른 실수는 Example을 생략하는 것입니다.

"설명만으로 충분하겠지"라고 생각하지만, 예시가 없으면 LLM의 해석이 엇나갈 확률이 급증합니다. 다시 김개발 씨의 이야기로 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, 그래서 제 코드가 이상했군요! 정보를 너무 안 줬네요." 다음 날, 김개발 씨는 ICE 구조로 프롬프트를 다시 작성했습니다.

놀랍게도 첫 시도에서 실무에 바로 적용 가능한 코드가 나왔습니다. 더 이상 여러 번 수정 요청을 할 필요가 없었습니다.

ICE 구조를 제대로 이해하면 LLM을 단순한 코드 생성기가 아닌, 신뢰할 수 있는 개발 파트너로 활용할 수 있습니다. 여러분도 오늘 배운 내용을 다음 프롬프트 작성에 적용해 보세요.

실전 팁

💡 - Context는 3-5개 핵심 정보로 제한하세요

• Example은 입출력 형식을 명확히 보여주는 것이 중요합니다
• 템플릿을 만들어두고 재사용하면 생산성이 3배 이상 높아집니다

---

2. 요구사항 명세를 프롬프트로 변환

기획팀에서 20페이지짜리 요구사항 명세서가 날아왔습니다. 김개발 씨는 한숨을 쉬며 문서를 열었습니다.

"이걸 다 읽고 코드로 옮기려면 며칠은 걸리겠는데..." 그때 박시니어 씨가 다가왔습니다. "요구사항을 프롬프트로 변환하는 기법을 알려드릴까요?"

요구사항-프롬프트 변환은 자연어로 작성된 비즈니스 요구사항을 LLM이 이해할 수 있는 구조화된 프롬프트로 번역하는 기술입니다. 마치 통역사가 한국어를 영어로 옮기듯, 기획서를 코드 생성 지시로 바꾸는 것입니다.

이 기법을 익히면 요구사항 분석 시간을 70% 이상 단축할 수 있습니다.

다음 코드를 살펴봅시다.

# 요구사항 명세를 프롬프트로 변환하는 파서
class RequirementToPrompt:
    def __init__(self, requirement_doc):
        self.requirement = requirement_doc

    def extract_functional_requirements(self):
        """기능 요구사항 추출"""
        return {
            "main_feature": self._parse_main_feature(),
            "sub_features": self._parse_sub_features(),
            "business_rules": self._parse_business_rules()
        }

    def to_prompt(self):
        """프롬프트 템플릿 생성"""
        req = self.extract_functional_requirements()

        prompt = f"""
# 구현할 기능
{req['main_feature']}

# 세부 요구사항
{chr(10).join(f"- {item}" for item in req['sub_features'])}

# 비즈니스 규칙
{chr(10).join(f"- {rule}" for rule in req['business_rules'])}

# 기술 스택
- 언어: Python 3.11
- 프레임워크: {self._detect_framework()}

# 예상 입출력
{self._generate_io_examples()}
"""
        return prompt

# 사용 예시
requirement = "사용자가 상품을 장바구니에 담을 때 재고를 확인하고, 재고가 부족하면 알림을 표시한다."
converter = RequirementToPrompt(requirement)
generated_prompt = converter.to_prompt()

김개발 씨는 화면 가득 펼쳐진 요구사항 문서를 보며 막막함을 느꼈습니다. "사용자 인증 시스템 개선", "결제 플로우 최적화", "알림 기능 추가"...

해야 할 일이 산더미였습니다. 박시니어 씨가 옆자리에 앉으며 물었습니다.

"요구사항서 받았어? 어때, 읽어봤어?" 김개발 씨가 힘없이 대답했습니다.

"네... 근데 이걸 어디서부터 시작해야 할지 모르겠어요." "그럴 줄 알았지.

나도 예전엔 그랬어. 요구사항서를 처음부터 끝까지 읽고, 머릿속으로 코드 구조를 그리고, 그제야 코딩을 시작했거든.

하지만 지금은 다른 방법을 쓰지." 요구사항-프롬프트 변환이란 무엇일까요? 쉽게 비유하자면, 요리 레시피북을 요리사용 지시서로 바꾸는 것과 같습니다.

레시피북에는 "부드럽고 촉촉한 케이크"라고 적혀 있지만, 요리사에게는 "박력분 200g, 설탕 150g, 180도 오븐에 25분"이라고 구체적으로 알려줘야 합니다. 마찬가지로 기획서의 "사용자 친화적인 로그인"이라는 표현을 "이메일/비밀번호 입력, OAuth 소셜 로그인 지원, 5회 실패 시 계정 잠금, JWT 토큰 발급"처럼 구체적인 기술 요구사항으로 변환해야 LLM이 정확한 코드를 생성할 수 있습니다.

기존 방식의 문제점 요구사항서를 받으면 개발자는 보통 어떻게 할까요? 문서를 꼼꼼히 읽고, 중요한 부분에 형광펜을 칩니다.

그다음 마인드맵을 그리거나 메모장에 정리합니다. 이 과정에서 평균 2-3시간이 소요됩니다.

20페이지짜리 문서라면 하루가 걸릴 수도 있습니다. 더 큰 문제는 해석의 차이입니다.

같은 문서를 읽어도 개발자마다 이해한 내용이 다릅니다. "직관적인 UI"라는 표현을 누군가는 미니멀 디자인으로, 누군가는 상세한 가이드 툴팁으로 받아들입니다.

체계적인 변환 프로세스 바로 이런 문제를 해결하기 위해 요구사항-프롬프트 변환 기법이 등장했습니다. 이 기법을 사용하면 자동화된 파싱으로 요구사항의 핵심을 빠르게 추출할 수 있습니다.

또한 표준화된 템플릿으로 팀원 간 해석 차이를 최소화합니다. 무엇보다 즉시 LLM에 투입 가능하여 코드 초안을 몇 분 만에 받아볼 수 있습니다.

코드 구조 분석 위의 코드를 단계별로 살펴보겠습니다. 5번째 줄의 extract_functional_requirements 메서드는 요구사항 문서에서 기능적 요구사항만 추출합니다.

비기능적 요구사항(성능, 보안 등)과 분리하는 이유는 코드 생성 단계를 나누기 위함입니다. 14번째 줄의 to_prompt 메서드가 핵심입니다.

추출한 요구사항을 ICE 구조에 맞게 재배치합니다. 자연어 문장이었던 것이 "구현할 기능", "세부 요구사항", "비즈니스 규칙"이라는 명확한 섹션으로 나뉩니다.

26번째 줄의 _detect_framework 메서드는 요구사항 문서에서 언급된 기술 스택을 자동으로 찾아냅니다. "웹 서비스"라는 단어를 발견하면 FastAPI나 Django를 추천할 수 있습니다.

실전 활용 사례 실제 프로젝트에서는 어떻게 쓰일까요? 한 핀테크 스타트업은 매주 새로운 금융 상품을 출시합니다.

기획팀에서 상품 명세서를 전달하면, 개발팀은 이 변환 시스템으로 즉시 프롬프트를 생성합니다. 생성된 프롬프트로 LLM에게 초안 코드를 요청하면, 30분 이내에 리뷰 가능한 수준의 코드가 나옵니다.

과거에는 요구사항 분석에 2일, 코딩에 3일이 걸렸습니다. 지금은 요구사항 분석이 2시간으로 줄었고, 초안 생성은 30분이면 됩니다.

남은 시간은 코드 품질 향상에 투자합니다. 주의해야 할 함정 하지만 조심할 점이 있습니다.

초보자들은 모든 요구사항을 한 번에 프롬프트로 만들려고 합니다. 20개의 기능을 하나의 거대한 프롬프트에 담으면 LLM이 혼란스러워합니다.

기능별로 분할하여 각각 독립적인 프롬프트로 만드는 것이 좋습니다. 또 다른 실수는 비즈니스 용어를 그대로 사용하는 것입니다.

"고객 만족도 향상"이라는 표현은 개발자에게도 모호하고 LLM에게도 모호합니다. 이것을 "응답 시간 2초 이내", "에러율 1% 미만"처럼 측정 가능한 지표로 바꿔야 합니다.

김개발 씨의 변화 박시니어 씨가 알려준 대로, 김개발 씨는 요구사항서를 섹션별로 나누어 프롬프트로 변환했습니다. 놀랍게도 20페이지 문서를 분석하는 데 1시간밖에 걸리지 않았습니다.

변환된 프롬프트를 LLM에 입력하자, 각 기능별 초안 코드가 순식간에 생성되었습니다. 물론 수정은 필요했지만, 백지에서 시작하는 것보다 10배는 빨랐습니다.

요구사항-프롬프트 변환을 마스터하면 개발 속도가 비약적으로 향상됩니다. 기획서를 두려워할 필요가 없어집니다.

여러분도 다음 프로젝트에서 이 기법을 시도해 보세요.

실전 팁

💡 - 기능별로 프롬프트를 분할하면 결과물의 품질이 높아집니다

• 비즈니스 용어는 반드시 측정 가능한 기술 지표로 변환하세요
• 변환 템플릿을 팀 내 공유하면 일관성이 유지됩니다

---

3. 코드 스타일 가이드 주입

김개발 씨가 LLM으로 생성한 코드를 PR에 올렸습니다. 리뷰어 박시니어 씨가 댓글을 달았습니다.

"코드는 잘 작동하는데, 우리 팀 컨벤션이랑 달라요. 변수명도 카멜케이스로 바꿔주세요." 김개발 씨는 생각했습니다.

"LLM한테 우리 스타일을 미리 알려줄 순 없을까?"

스타일 가이드 주입은 프롬프트에 팀의 코딩 컨벤션, 네이밍 규칙, 포맷 규칙을 명시하여 LLM이 처음부터 일관된 스타일로 코드를 생성하게 만드는 기법입니다. 마치 신입 사원에게 회사의 복장 규정을 알려주는 것처럼, LLM에게도 "이렇게 코드를 작성해달라"고 정확히 지시하는 것입니다.

다음 코드를 살펴봅시다.

# 팀 코딩 스타일 가이드를 프롬프트에 주입
TEAM_STYLE_GUIDE = """
# 코딩 스타일 가이드
- 변수명: snake_case (예: user_name, order_list)
- 함수명: snake_case with verb prefix (예: get_user, validate_email)
- 클래스명: PascalCase (예: UserService, OrderRepository)
- 상수: UPPER_SNAKE_CASE (예: MAX_RETRY_COUNT)
- 들여쓰기: 스페이스 4칸 (탭 금지)
- 최대 줄 길이: 100자
- Docstring: Google Style
- Type Hints: 모든 함수에 필수
- 에러 처리: try-except보다 early return 선호
"""

def generate_code_with_style(task_description):
    """스타일 가이드가 포함된 프롬프트 생성"""
    prompt = f"""
{TEAM_STYLE_GUIDE}

# 구현할 기능
{task_description}

위 스타일 가이드를 엄격히 준수하여 코드를 작성해주세요.
특히 변수명과 함수명은 반드시 규칙을 따라야 합니다.
"""
    return prompt

# 사용 예시
task = "사용자 이메일 유효성 검사 함수"
styled_prompt = generate_code_with_style(task)
print(styled_prompt)

김개발 씨는 코드 리뷰 댓글을 보며 한숨을 쉬었습니다. 기능은 완벽하게 작동했지만, 스타일이 팀 규칙과 달라서 전체를 다시 수정해야 했습니다.

변수명을 하나하나 바꾸는 작업만 1시간이 걸렸습니다. 점심시간에 박시니어 씨가 물었습니다.

"코드 수정 다 했어?" 김개발 씨가 지친 목소리로 답했습니다. "네...

근데 LLM한테 우리 스타일을 처음부터 알려줄 방법은 없나요?" "당연히 있지! 바로 스타일 가이드 주입이야.

프롬프트에 우리 팀 규칙을 넣으면 돼." 스타일 가이드 주입이란 정확히 무엇일까요? 비유하자면, 건축가에게 설계 도면을 주면서 "우리 회사는 모든 건물에 빨간 벽돌을 사용합니다"라고 알려주는 것과 같습니다.

건축가는 처음부터 빨간 벽돌로 설계하므로, 나중에 다시 바꿀 필요가 없습니다. LLM도 마찬가지입니다.

프롬프트에 "변수명은 snake_case를 사용하세요", "Type Hints를 필수로 붙이세요"라고 명시하면, 생성된 코드가 이미 팀 규칙을 따르고 있습니다. 수정 작업이 거의 필요 없어집니다.

스타일 불일치의 대가 스타일 가이드를 주입하지 않으면 어떤 일이 벌어질까요? LLM은 기본적으로 인터넷에서 학습한 수많은 코드 스타일을 혼합해서 사용합니다.

어떤 함수는 카멜케이스, 어떤 함수는 스네이크케이스로 나옵니다. 들여쓰기도 탭과 스페이스가 섞여 있을 수 있습니다.

코드 리뷰에서 "스타일이 다릅니다"라는 댓글이 반복되면 팀 전체의 생산성이 떨어집니다. 리뷰어는 기능보다 형식에 시간을 쏟고, 작성자는 의미 없는 수정 작업에 시간을 허비합니다.

한 조사에 따르면 스타일 수정에 전체 리뷰 시간의 40%가 소비된다고 합니다. 사전 예방이 핵심 바로 이런 낭비를 막기 위해 스타일 가이드 주입이 필요합니다.

스타일 가이드를 프롬프트에 포함하면 첫 생성부터 완벽한 스타일로 코드가 나옵니다. 리뷰어는 로직과 알고리즘에만 집중할 수 있습니다.

또한 팀원 간 코드 일관성이 자동으로 유지됩니다. 신입이든 시니어든, LLM이 생성한 코드든 사람이 작성한 코드든 모두 같은 스타일입니다.

코드 구조 이해하기 위의 코드를 살펴보겠습니다. 2번째 줄부터 시작하는 TEAM_STYLE_GUIDE 변수가 핵심입니다.

여기에 팀의 모든 코딩 규칙을 문자열로 정의합니다. 이것은 한 번만 작성하면 모든 프롬프트에 재사용할 수 있습니다.

3번째 줄의 "변수명: snake_case"처럼 구체적인 예시를 함께 제공하는 것이 중요합니다. 단순히 "스네이크케이스 사용"이라고만 하면 LLM이 정확히 이해하지 못할 수 있습니다.

user_name, order_list처럼 실제 예시를 보여주면 학습 효과가 극대화됩니다. 14번째 줄의 generate_code_with_style 함수는 스타일 가이드와 작업 설명을 결합합니다.

이렇게 템플릿화하면 매번 스타일 가이드를 복사-붙여넣기 할 필요가 없습니다. 21번째 줄의 "위 스타일 가이드를 엄격히 준수"라는 문구는 강조 효과가 있습니다.

LLM에게 이것이 선택 사항이 아닌 필수 요구사항임을 알립니다. 대기업의 실전 사례 실제 현업에서는 어떻게 활용될까요?

구글, 에어비앤비 같은 대기업은 수백 페이지 분량의 스타일 가이드를 보유하고 있습니다. 이것을 모두 프롬프트에 넣기는 어렵습니다.

그래서 핵심 규칙 10-15개만 추출하여 프롬프트에 포함합니다. 한 국내 커머스 기업은 스타일 가이드 주입 도입 후 코드 리뷰 시간이 평균 30분에서 15분으로 줄었습니다.

"스타일 수정 요청" 댓글이 80% 감소했기 때문입니다. 개발자들은 남은 시간을 테스트 코드 작성과 리팩토링에 활용했습니다.

흔한 실수와 해결책 주의해야 할 점이 있습니다. 초보자들은 스타일 가이드를 너무 상세하게 작성합니다.

"함수의 여는 중괄호는 같은 줄에", "클래스 사이에는 빈 줄 2개" 같은 세세한 규칙까지 모두 넣으면 프롬프트가 너무 길어집니다. 중요도 순으로 10-15개 규칙만 선정하세요.

또 다른 실수는 규칙을 애매하게 작성하는 것입니다. "깔끔한 코드를 작성하세요"는 해석의 여지가 큽니다.

"함수는 최대 20줄 이내, 하나의 기능만 수행"처럼 측정 가능하게 작성해야 합니다. 김개발 씨의 성공 다음 날, 김개발 씨는 스타일 가이드를 프롬프트에 포함했습니다.

LLM이 생성한 코드를 확인하니, 모든 변수명이 스네이크케이스였고, Type Hints도 완벽하게 붙어 있었습니다. PR을 올리자 박시니어 씨가 즉시 승인했습니다.

"완벽해요! 스타일 수정이 하나도 없네요.

이제 제대로 하는군요!" 스타일 가이드 주입을 마스터하면 코드 리뷰가 즐거워집니다. 형식이 아닌 본질에 집중할 수 있기 때문입니다.

여러분도 팀 스타일 가이드를 정리해서 프롬프트 템플릿에 추가해 보세요.

실전 팁

💡 - 스타일 가이드는 10-15개 핵심 규칙으로 압축하세요

• 규칙마다 구체적인 예시를 함께 제공하면 효과가 배가됩니다
• "엄격히 준수", "반드시 따라야" 같은 강조 표현을 추가하세요

---

4. 에러 처리와 엣지 케이스 고려

김개발 씨가 LLM으로 만든 로그인 함수를 테스트했습니다. 정상적인 입력은 완벽하게 작동했습니다.

그런데 빈 문자열을 입력하자 서버가 크래시했습니다. "LLM이 에러 처리를 안 넣었네..." 박시니어 씨가 말했습니다.

"프롬프트에 엣지 케이스를 명시했어야죠."

에러 처리와 엣지 케이스 고려는 프롬프트에 예외 상황, 경계값, 비정상 입력을 명시하여 LLM이 견고한 코드를 생성하도록 유도하는 기법입니다. 정상 경로만 다루는 코드가 아니라, 실제 운영 환경에서 발생할 수 있는 모든 상황을 대비한 프로덕션급 코드를 만들어냅니다.

다음 코드를 살펴봅시다.

# 에러 처리와 엣지 케이스를 명시한 프롬프트 템플릿
ERROR_HANDLING_TEMPLATE = """
# 구현할 기능
{task_description}

# 처리해야 할 에러 케이스

---

3. External Dependencies

김개발 씨는 자신이 만든 함수가 크래시하는 것을 보며 당황했습니다. 테스트 케이스 10개 중 7개는 통과했지만, 빈 문자열, None 값, 음수 입력에서 모두 실패했습니다.

박시니어 씨가 코드를 보더니 고개를 저었습니다. "LLM한테 해피 패스만 알려줬구나.

엣지 케이스를 프롬프트에 넣었어야지." 김개발 씨가 되묻습니다. "엣지 케이스요?

그게 뭔가요?" 에러 처리와 엣지 케이스란 무엇일까요? 쉽게 비유하자면, 자동차 설계할 때 정상 주행만 고려하는 것이 아니라 급정거, 빗길 미끄러짐, 타이어 펑크 같은 비정상 상황도 대비하는 것과 같습니다.

해피 패스는 모든 입력이 완벽하고, 네트워크도 안정적이고, DB도 항상 응답하는 이상적인 시나리오입니다. 하지만 현실은 다릅니다.

사용자는 이상한 값을 입력하고, 네트워크는 불안정하며, DB는 가끔 죽습니다. 엣지 케이스는 경계값, 극단적 입력, 예외 상황을 의미합니다.

나이 입력 함수라면 0세, 150세, -1세, "abc" 같은 입력이 엣지 케이스입니다. 에러 처리 없는 코드의 문제점 에러 처리를 하지 않으면 어떤 일이 벌어질까요?

프로덕션 환경에서 사용자가 예상치 못한 값을 입력하면 서버가 크래시합니다. 한 번의 크래시로 전체 서비스가 다운될 수 있습니다.

2021년, 한 대형 커머스 사이트는 NULL 값 처리 미흡으로 블랙프라이데이에 1시간 동안 서비스가 중단되어 수십억 원의 손실을 입었습니다. 더 심각한 것은 보안 취약점입니다.

SQL Injection, XSS 같은 공격은 대부분 입력값 검증 누락에서 시작됩니다. 에러 처리가 없으면 공격자에게 시스템 내부 정보를 노출할 수도 있습니다.

프롬프트에 명시하는 방법 바로 이런 재앙을 막기 위해 프롬프트에 에러 처리를 명시해야 합니다. 프롬프트에 "None 값이 입력되면 ValueError를 발생시키세요"라고 구체적으로 작성하면, LLM은 해당 검증 로직을 포함한 코드를 생성합니다.

"DB 연결 실패 시 3회 재시도"라고 명시하면, retry 로직이 자동으로 들어갑니다. 코드 템플릿 분석 위의 코드를 단계별로 살펴보겠습니다.

5번째 줄부터의 "Input Validation" 섹션은 가장 기본적인 검증입니다. None, 빈 문자열, 타입 불일치는 거의 모든 함수에서 체크해야 하는 항목입니다.

이것을 템플릿화하면 매번 반복해서 작성할 필요가 없습니다. 11번째 줄의 "Business Logic Errors"는 도메인 특화 에러입니다.

나이 계산 함수라면 "음수 입력", "150세 초과"가 비즈니스 규칙 위반입니다. 이것은 프로젝트마다 다르므로 변수로 받습니다.

15번째 줄의 "External Dependencies"는 외부 시스템 의존성입니다. DB, API, 파일 시스템 같은 외부 자원은 언제든 실패할 수 있습니다.

Retry 정책, 타임아웃, 기본값 처리 전략을 명시해야 합니다. 23번째 줄의 에러 응답 형식은 통일성을 위해 중요합니다.

모든 함수가 같은 구조의 에러를 반환하면, 상위 레이어에서 일관되게 처리할 수 있습니다. 글로벌 기업의 실전 예시 실제 현업에서는 어떻게 적용할까요?

넷플릭스는 "카오스 엔지니어링"으로 유명합니다. 의도적으로 서버를 죽여가며 시스템 견고성을 테스트합니다.

이들은 LLM으로 코드를 생성할 때도 "네트워크 장애", "DB 지연", "메모리 부족" 같은 장애 시나리오를 프롬프트에 필수로 포함합니다. 아마존은 "에러 처리 없는 코드는 코드 리뷰 통과 불가"라는 원칙을 가지고 있습니다.

LLM이 생성한 코드도 예외가 아닙니다. 프롬프트 템플릿 자체에 "최소 5개 이상의 에러 케이스 처리"를 명시합니다.

초보자의 실수 주의해야 할 함정이 있습니다. 초보자들은 모든 가능한 에러를 잡으려고 합니다.

하지만 과도한 에러 처리는 오히려 코드를 복잡하게 만들고 성능을 저하시킵니다. 발생 가능성이 높은 에러 5-7개에 집중하는 것이 현명합니다.

또 다른 실수는 에러 메시지를 대충 작성하는 것입니다. "에러 발생"이라는 메시지는 디버깅에 도움이 안 됩니다.

"사용자 ID가 양수가 아닙니다. 입력값: -5"처럼 구체적으로 작성해야 합니다.

김개발 씨의 개선 박시니어 씨의 조언대로, 김개발 씨는 프롬프트를 다시 작성했습니다. 이번에는 None 값, 빈 문자열, 음수, 극단값 처리를 모두 명시했습니다.

새로 생성된 코드를 테스트하니 10개 케이스가 모두 통과했습니다. 심지어 김개발 씨가 생각하지 못한 동시성 문제까지 LLM이 알아서 처리했습니다.

"이제 프로덕션에 배포해도 되겠어요!" 김개발 씨가 자신감 있게 말했습니다. 박시니어 씨가 미소를 지으며 답했습니다.

"그래, 이제 제대로 배우고 있네." 에러 처리와 엣지 케이스 고려를 마스터하면 야근이 줄어듭니다. 버그가 줄어들기 때문입니다.

여러분도 다음 프롬프트에 에러 시나리오를 추가해 보세요.

실전 팁

💡 - 발생 가능성 높은 5-7개 에러에 집중하세요

• 에러 메시지는 디버깅에 필요한 정보를 모두 포함해야 합니다
• 외부 의존성(DB, API)은 반드시 retry와 timeout을 명시하세요

---

5. 실습: 프롬프트 템플릿 라이브러리 구축

김개발 씨는 매번 프롬프트를 처음부터 작성하는 것이 번거로웠습니다. "자주 쓰는 패턴을 템플릿으로 만들어두면 어떨까?" 박시니어 씨가 고개를 끄덕였습니다.

"좋은 생각이야. 우리 팀 전체가 쓸 수 있는 프롬프트 라이브러리를 만들어보자."

프롬프트 템플릿 라이브러리는 자주 사용하는 코드 생성 패턴을 재사용 가능한 템플릿으로 정리한 모음입니다. API 엔드포인트, 데이터 검증, 테스트 코드 등 반복되는 작업마다 최적화된 프롬프트를 미리 만들어두면, 팀 전체의 생산성이 3배 이상 향상됩니다.

다음 코드를 살펴봅시다.

# 프롬프트 템플릿 라이브러리 구현
class PromptTemplateLibrary:
    """재사용 가능한 프롬프트 템플릿 모음"""

    TEMPLATES = {
        "api_endpoint": """
# API 엔드포인트 생성
경로: {endpoint_path}
메서드: {http_method}
요청 형식: {request_format}
응답 형식: {response_format}

# 필수 검증
- 인증: JWT 토큰 필수
- Rate Limiting: 분당 {rate_limit}회
- Input Validation: Pydantic 모델 사용

# 에러 처리
- 401: 인증 실패
- 422: 입력 검증 실패
- 500: 서버 내부 에러
""",

        "data_validator": """
# 데이터 검증 함수
검증 대상: {target_data}
검증 규칙:
{validation_rules}

# 반환 형식
성공: (True, validated_data)
실패: (False, error_message)

# 체크 항목
- 타입 검사
- 범위 검사
- 비즈니스 규칙 검사
""",

        "test_code": """
# 단위 테스트 생성
테스트 대상: {function_name}

# 테스트 케이스

---

3. 에러 케이스: {error cases}

김개발 씨는 지난 한 주간 작성한 프롬프트를 검토했습니다. API 엔드포인트를 5개 만들었는데, 프롬프트 구조가 거의 비슷했습니다.

"이거 매번 복사-붙여넣기 하는 것도 귀찮은데..." 박시니어 씨가 옆에서 말했습니다. "그럴 때 쓰라고 템플릿 라이브러리가 있는 거야.

한 번 만들어두면 계속 재사용할 수 있거든." 프롬프트 템플릿 라이브러리란 무엇일까요? 쉽게 비유하자면, 요리할 때 자주 쓰는 소스를 미리 만들어두는 것과 같습니다.

간장 소스, 고추장 소스, 크림 소스를 병에 담아두면, 요리할 때마다 재료를 섞을 필요가 없습니다. 병에서 꺼내서 바로 쓰면 됩니다.

프롬프트도 마찬가지입니다. "API 엔드포인트 생성", "데이터 검증 함수", "테스트 코드" 같은 패턴은 프로젝트마다 반복됩니다.

이것들을 템플릿으로 만들어두면, 필요할 때 변수만 채워서 즉시 사용할 수 있습니다. 반복 작업의 고통 템플릿 라이브러리가 없으면 어떻게 될까요?

개발자는 비슷한 프롬프트를 매번 처음부터 작성합니다. "이번에도 API 만들어야 하는데, 지난번 프롬프트가 뭐였더라?" 하면서 과거 채팅 기록을 뒤집니다.

찾는 데만 5분, 수정하는 데 5분이 걸립니다. 더 큰 문제는 품질 불일치입니다.

어떤 날은 에러 처리를 꼼꼼히 명시하고, 어떤 날은 빼먹습니다. 컨디션에 따라 프롬프트 품질이 들쭉날쭉합니다.

결과적으로 생성된 코드의 품질도 불안정해집니다. 체계적인 템플릿 관리 바로 이런 문제를 해결하기 위해 템플릿 라이브러리가 필요합니다.

라이브러리를 구축하면 일관된 품질이 보장됩니다. 모든 팀원이 검증된 템플릿을 사용하므로, 코드 품질의 편차가 줄어듭니다.

또한 시간 절약이 엄청납니다. 프롬프트 작성 시간이 10분에서 1분으로 줄어듭니다.

무엇보다 지식 공유가 자동으로 이루어집니다. 시니어가 만든 좋은 프롬프트를 주니어도 똑같이 활용할 수 있습니다.

코드 구조 파헤치기 위의 코드를 상세히 분석해봅시다. 3번째 줄의 PromptTemplateLibrary 클래스는 모든 템플릿을 중앙에서 관리합니다.

흩어진 프롬프트를 한곳에 모으는 것이 핵심입니다. 5번째 줄의 TEMPLATES 딕셔너리는 템플릿 저장소입니다.

키는 템플릿 이름(api_endpoint, data_validator 등), 값은 프롬프트 문자열입니다. 이 구조 덕분에 템플릿을 쉽게 추가하고 수정할 수 있습니다.

6번째 줄부터의 "api_endpoint" 템플릿을 보면, 중괄호로 감싼 변수({endpoint_path}, {http_method})가 있습니다. 이것은 파이썬의 str.format() 메서드로 채워집니다.

고정된 부분과 가변적인 부분을 명확히 분리한 것입니다. 52번째 줄의 get_template 메서드는 템플릿을 가져오고 변수를 채웁니다.

**kwargs를 사용하여 어떤 변수든 동적으로 받을 수 있습니다. 60번째 줄의 사용 예시를 보면, 단 7줄의 코드로 완성된 API 프롬프트를 만듭니다.

만약 템플릿이 없었다면 20-30줄을 직접 작성해야 했을 것입니다. 실제 팀에서의 활용 실무에서는 어떻게 쓰일까요?

한 스타트업은 템플릿 라이브러리를 Git 저장소에 올려 팀원이 공유합니다. 누군가 더 좋은 프롬프트를 발견하면 PR을 통해 템플릿을 개선합니다.

마치 오픈소스처럼 집단 지성으로 진화하는 것입니다. 어떤 팀은 주간 회의에서 "이번 주 베스트 프롬프트"를 선정하여 라이브러리에 추가합니다.

6개월 후, 50개의 검증된 템플릿이 쌓였고, 신입 개발자도 첫날부터 시니어 수준의 프롬프트를 사용할 수 있게 되었습니다. 피해야 할 함정 주의할 점이 있습니다.

초보자들은 템플릿을 너무 많이 만듭니다. 100개의 템플릿이 있으면 오히려 어떤 것을 써야 할지 헷갈립니다.

자주 쓰는 10-15개로 시작하는 것이 좋습니다. 또 다른 실수는 템플릿을 너무 유연하게 만드는 것입니다.

변수가 20개나 되면 채우는 것 자체가 일이 됩니다. 필수 변수 5개 이내로 제한하고, 나머지는 기본값을 제공하세요.

김개발 씨의 라이브러리 김개발 씨는 지난 프로젝트에서 자주 쓴 패턴 10개를 추출했습니다. API 엔드포인트, CRUD 함수, 데이터 검증, 테스트 코드 등을 템플릿으로 만들었습니다.

다음 날부터 생산성이 눈에 띄게 향상되었습니다. API 10개를 만드는 데 과거에는 2일이 걸렸지만, 이제는 4시간이면 충분했습니다.

프롬프트 작성 시간이 줄어든 만큼, 코드 리뷰와 테스트에 시간을 더 쓸 수 있었습니다. 팀 회의에서 김개발 씨가 라이브러리를 공유하자, 모든 팀원이 환호했습니다.

"이거 진작 만들었으면 좋았을 걸!" 이제 팀 전체가 동일한 템플릿을 사용하며, 코드 품질이 한층 높아졌습니다. 프롬프트 템플릿 라이브러리를 구축하면 팀의 집단 지성이 코드로 저장됩니다.

한 번의 노력으로 지속적인 효과를 얻을 수 있습니다. 여러분도 오늘부터 자주 쓰는 프롬프트 3개를 템플릿으로 만들어보세요.

실전 팁

💡 - 자주 쓰는 10-15개 패턴으로 시작하세요

• 필수 변수는 5개 이내로 제한하면 사용성이 좋아집니다
• Git으로 관리하여 팀원과 공유하고 지속적으로 개선하세요

---

6. 실습: 언어별/프레임워크별 템플릿 작성

김개발 씨의 팀은 Python, TypeScript, Go를 함께 사용합니다. 같은 API라도 언어마다 작성 방식이 달라서, 프롬프트도 각각 만들어야 했습니다.

"언어별로 템플릿을 따로 관리하면 어떨까요?" 박시니어 씨가 답했습니다. "정확히 맞는 방향이야.

언어 특성을 반영한 전문 템플릿이 필요해."

언어별/프레임워크별 템플릿은 Python, TypeScript, Go, React, FastAPI 등 각 기술 스택의 관습과 베스트 프랙티스를 반영한 맞춤형 프롬프트입니다. 같은 "API 생성" 작업이라도 FastAPI와 Express.js는 완전히 다른 코드가 필요하므로, 언어 특화 템플릿을 사용하면 정확도가 크게 향상됩니다.

다음 코드를 살펴봅시다.

# 언어별/프레임워크별 프롬프트 템플릿
class LanguageSpecificTemplates:
    """언어 및 프레임워크에 특화된 템플릿 모음"""

    PYTHON_FASTAPI = """
# FastAPI 엔드포인트 생성
from fastapi import APIRouter, HTTPException, Depends
from pydantic import BaseModel

# 요구사항
경로: {endpoint_path}
메서드: {http_method}
기능: {description}

# FastAPI 특화 요구사항
- Pydantic 모델로 request/response 정의
- async/await 사용 (비동기 처리)
- Dependency Injection으로 DB 연결
- HTTPException으로 에러 처리
- 자동 OpenAPI 문서 생성을 위한 docstring 작성

# 타입 힌팅
모든 함수에 타입 힌트 필수 (Python 3.11 문법)
"""

    TYPESCRIPT_REACT = """
# React 컴포넌트 생성
// {component_name} 컴포넌트

# 요구사항
컴포넌트 타입: {component_type}  // 'functional' or 'page'
Props: {props_definition}
상태 관리: {state_management}  // 'useState' or 'zustand' or 'none'

# React/TypeScript 특화 요구사항
- 함수형 컴포넌트 (FC 타입 사용하지 않음)
- Props는 interface로 정의
- useState, useEffect 등 Hooks 활용
- 조건부 렌더링 시 early return 패턴
- CSS는 Tailwind 클래스 사용
- 모든 이벤트 핸들러에 타입 지정

# 파일 구조
- 컴포넌트: {component_name}.tsx
- 타입 정의: types.ts (별도 분리)
"""

    GO_FIBER = """
// Go Fiber API 핸들러 생성
package handlers

# 요구사항
경로: {endpoint_path}
메서드: {http_method}
기능: {description}

# Go/Fiber 특화 요구사항
- fiber.Ctx 컨텍스트 활용
- struct로 request/response 정의 (json 태그 포함)
- 에러는 fiber.NewError 사용
- defer로 리소스 정리
- context.Context로 타임아웃 처리
- goroutine 사용 시 sync.WaitGroup 활용

# 네이밍 규칙
- Public 함수: PascalCase
- Private 함수: camelCase
- 상수: UPPER_SNAKE_CASE
"""

    @classmethod
    def get_template(cls, stack_name):
        """기술 스택별 템플릿 반환"""
        stack_map = {
            "python-fastapi": cls.PYTHON_FASTAPI,
            "typescript-react": cls.TYPESCRIPT_REACT,
            "go-fiber": cls.GO_FIBER
        }
        return stack_map.get(stack_name, "템플릿을 찾을 수 없습니다")

# 사용 예시
templates = LanguageSpecificTemplates()
fastapi_prompt = templates.get_template("python-fastapi").format(
    endpoint_path="/api/products",
    http_method="POST",
    description="상품 등록"
)

react_prompt = templates.get_template("typescript-react").format(
    component_name="ProductCard",
    component_type="functional",
    props_definition="{ product: Product; onAddToCart: (id: string) => void }",
    state_management="useState"
)

print("=== FastAPI 템플릿 ===")
print(fastapi_prompt)
print("\n=== React 템플릿 ===")
print(react_prompt)

김개발 씨는 Python으로 백엔드 API를 만들다가, 프론트엔드 팀에서 TypeScript 코드를 요청받았습니다. 같은 "데이터 검증 함수"인데, Python과 TypeScript는 완전히 다른 코드였습니다.

"Python 템플릿으로 TypeScript 코드를 만들려니까 이상한 게 나와요." 김개발 씨가 박시니어 씨에게 하소연했습니다. 박시니어 씨가 고개를 끄덕였습니다.

"당연하지. Python은 덕 타이핑이고 TypeScript는 정적 타입이잖아.

같은 템플릿을 쓸 수가 없어. 언어별로 따로 만들어야 해." 언어별/프레임워크별 템플릿이란 무엇일까요?

쉽게 비유하자면, 한국 요리와 이탈리아 요리의 레시피가 다른 것과 같습니다. 똑같이 "파스타"를 만들어도, 한국식은 고추장을 넣고 이탈리아식은 토마토 소스를 씁니다.

재료와 조리법이 완전히 다릅니다. 프로그래밍 언어도 마찬가지입니다.

Python의 FastAPI는 async def와 Pydantic을 쓰고, TypeScript의 Express는 Promise와 Zod를 씁니다. Go의 Fiber는 goroutine과 struct를 활용합니다.

같은 "API 엔드포인트"라도 언어마다 완전히 다른 코드가 나와야 합니다. 통합 템플릿의 한계 하나의 범용 템플릿으로 모든 언어를 커버하면 어떻게 될까요?

LLM은 혼란스러워합니다. "Python 코드를 써야 하는데 TypeScript 문법을 써야 하나?"라고 고민하다가 이상한 혼종 코드를 만듭니다.

실제로 작동하지 않는 코드가 나올 확률이 높습니다. 더 큰 문제는 베스트 프랙티스 누락입니다.

Python에서는 Type Hints가 중요하지만 JavaScript에서는 선택 사항입니다. Go에서는 에러 반환이 표준이지만 Python에서는 예외를 던집니다.

이런 언어별 관습을 범용 템플릿은 담을 수 없습니다. 기술 스택 특화의 중요성 바로 이런 문제를 해결하기 위해 언어별 템플릿이 필요합니다.

언어 특화 템플릿을 사용하면 해당 언어의 이디엄을 자동으로 따릅니다. Python 템플릿은 리스트 컴프리헨션과 데코레이터를 쓰고, Go 템플릿은 defer와 goroutine을 씁니다.

또한 프레임워크 규칙도 자동으로 적용됩니다. FastAPI 템플릿은 Dependency Injection을, React 템플릿은 Hooks 패턴을 사용합니다.

코드 구조 뜯어보기 위의 코드를 언어별로 분석해봅시다. 7번째 줄부터의 PYTHON_FASTAPI 템플릿을 보면, 10번째 줄에 FastAPI의 핵심 import가 명시되어 있습니다.

APIRouter, HTTPException, Depends, BaseModel은 FastAPI 개발자라면 누구나 아는 필수 요소입니다. 17번째 줄의 "Pydantic 모델로 request/response 정의"는 FastAPI의 핵심 철학입니다.

Flask나 Django와 다른 점이 바로 이것입니다. 이것을 프롬프트에 명시하면 LLM이 자동으로 Pydantic 모델을 생성합니다.

25번째 줄부터의 TYPESCRIPT_REACT 템플릿은 완전히 다른 구조입니다. 34번째 줄의 "함수형 컴포넌트"는 React 18 이후의 표준입니다.

옛날 클래스 컴포넌트가 아닌 최신 패턴을 따르도록 유도합니다. 36번째 줄의 "Props는 interface로 정의"는 TypeScript 관습입니다.

type을 쓸 수도 있지만, React 커뮤니티에서는 interface를 선호합니다. 46번째 줄부터의 GO_FIBER 템플릿은 또 다릅니다.

58번째 줄의 "defer로 리소스 정리"는 Go의 고유 패턴입니다. Python이나 TypeScript에는 없는 개념입니다.

글로벌 팀의 실전 사례 실제 다국적 프로젝트에서는 어떻게 쓰일까요? 한 글로벌 핀테크 기업은 마이크로서비스로 구성되어 있습니다.

결제 서비스는 Go, 사용자 서비스는 Python, 프론트는 React입니다. 각 팀이 언어별 템플릿을 만들어 공유합니다.

신입 개발자가 Go 팀에 합류하면, Go 템플릿을 받아서 바로 사용합니다. Python을 주로 쓰던 사람도 Go 템플릿 덕분에 첫날부터 Go 베스트 프랙티스를 따르는 코드를 작성합니다.

초보자의 함정 주의할 점이 있습니다. 초보자들은 언어별 템플릿을 너무 세분화합니다.

"Python FastAPI GET 요청", "Python FastAPI POST 요청"처럼 나누면 관리가 어렵습니다. 언어-프레임워크 단위로 묶고, 메서드는 변수로 처리하세요.

또 다른 실수는 최신 버전을 반영하지 않는 것입니다. React 16 시절 템플릿을 React 18에 쓰면 deprecated 코드가 나옵니다.

분기별로 업데이트하여 최신 관습을 따르도록 관리해야 합니다. 김개발 씨의 멀티 랭귀지 마스터 김개발 씨는 Python, TypeScript, Go 템플릿을 각각 만들었습니다.

이제 어떤 언어로든 API를 만들 수 있게 되었습니다. 백엔드 API를 Go로 만들어야 할 때, Go 템플릿을 불러와서 변수만 채웠습니다.

LLM이 생성한 코드는 defer, context.Context, sync.WaitGroup 같은 Go 관용구를 완벽히 포함하고 있었습니다. 프론트엔드 작업으로 넘어가자, React 템플릿을 사용했습니다.

useState, useEffect, Tailwind CSS가 자동으로 적용된 깔끔한 컴포넌트가 나왔습니다. "이제 언어를 몰라도 템플릿만 있으면 되겠는데요?" 김개발 씨가 농담했습니다.

박시니어 씨가 웃으며 답했습니다. "그래도 기본은 알아야지.

템플릿은 도구일 뿐이야. 도구를 제대로 쓰려면 기초가 탄탄해야 해." 언어별/프레임워크별 템플릿을 마스터하면 멀티 랭귀지 개발자로 성장할 수 있습니다.

낯선 기술 스택도 빠르게 습득하고 활용할 수 있습니다. 여러분도 주력 언어 3개의 템플릿을 만들어보세요.

실전 팁

💡 - 언어-프레임워크 단위로 템플릿을 구성하고, 세부 항목은 변수로 처리하세요

• 분기별로 최신 버전의 베스트 프랙티스를 반영하여 업데이트하세요
• 공식 문서의 "Best Practices" 섹션을 참고하면 좋은 템플릿을 만들 수 있습니다

---

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