코드 생성 프롬프트 완벽 가이드

LLM을 활용한 효과적인 코드 생성 프롬프트 작성법을 배웁니다. 언어별 특성, 테스트 케이스 포함 전략, 그리고 실전 예제를 통해 프롬프트 엔지니어링의 핵심을 익힙니다.

1. 코드 생성 프롬프트 패턴

김개발 씨는 최근 ChatGPT를 사용해서 코드를 생성해보려 했지만, 번번이 원하는 결과를 얻지 못했습니다. "파이썬으로 정렬 함수 만들어줘"라고 했더니, 너무 간단하거나 아니면 너무 복잡한 코드가 나왔습니다.

박시니어 씨가 그의 화면을 보고는 말했습니다. "프롬프트 패턴을 알면 훨씬 좋은 결과를 얻을 수 있어요."

코드 생성 프롬프트 패턴은 LLM에게 코드를 요청할 때 사용하는 효과적인 질문 구조입니다. 마치 요리 레시피처럼, 무엇을(What), 어떻게(How), 왜(Why)를 명확히 전달해야 좋은 결과를 얻습니다.

좋은 프롬프트는 역할(Role), 맥락(Context), 요구사항(Requirement), 제약조건(Constraint)을 포함합니다. 이 패턴을 익히면 코드 생성의 정확도가 크게 향상됩니다.

다음 코드를 살펴봅시다.

# 나쁜 프롬프트 예시
"정렬 함수 만들어줘"

# 좋은 프롬프트 예시 (패턴 적용)
"""
당신은 파이썬 전문가입니다.
다음 요구사항에 맞는 정렬 함수를 작성해주세요:

맥락: 학생 성적 관리 시스템
요구사항:
- 학생 객체 리스트를 성적 기준 내림차순 정렬
- 성적이 같으면 이름 기준 오름차순
- 타입 힌트 포함
- docstring 포함

제약조건:
- Python 3.9+ 표준 라이브러리만 사용
- 시간복잡도 O(n log n)
"""

김개발 씨는 입사 2개월 차 주니어 개발자입니다. 최근 회사에서 LLM을 활용한 개발 도구를 도입했는데, 동료들은 뚝딱뚝딱 코드를 만들어내는데 자신만 제대로 된 결과를 얻지 못했습니다.

답답한 마음에 박시니어 씨에게 물어봤습니다. "시니어님, 저는 왜 자꾸 이상한 코드가 나올까요?" 박시니어 씨가 김개발 씨의 프롬프트를 보더니 고개를 끄덕였습니다.

"아, 프롬프트가 너무 애매하네요. 패턴을 따라서 작성해보세요." 그렇다면 코드 생성 프롬프트 패턴이란 정확히 무엇일까요?

쉽게 비유하자면, 프롬프트 패턴은 마치 음식점에서 주문하는 방법과 같습니다. "음식 주세요"라고 하면 뭘 줘야 할지 모르지만, "매운 떡볶이 1인분, 치즈 추가, 덜 맵게 해주세요"라고 하면 정확히 원하는 음식을 받을 수 있습니다.

LLM도 마찬가지입니다. 구체적이고 구조화된 요청을 해야 원하는 코드를 얻을 수 있습니다.

패턴이 없던 시절에는 어땠을까요? 개발자들은 "함수 만들어줘", "버그 고쳐줘" 같은 모호한 요청을 했고, LLM은 추측으로 코드를 생성했습니다.

결과는 대부분 쓸모없거나 잘못된 코드였습니다. 더 큰 문제는 여러 번 시도해도 원하는 결과를 얻지 못해 시간만 낭비한다는 것이었습니다.

프롬프트를 수정할 때마다 완전히 다른 코드가 나와서 일관성도 없었습니다. 바로 이런 문제를 해결하기 위해 프롬프트 패턴이 등장했습니다.

프롬프트 패턴을 사용하면 LLM이 정확히 무엇을 만들어야 하는지 이해할 수 있습니다. 또한 일관된 품질의 코드를 반복적으로 생성할 수 있습니다.

무엇보다 한 번에 원하는 결과를 얻을 확률이 크게 높아진다는 이점이 있습니다. 효과적인 프롬프트 패턴은 네 가지 핵심 요소로 구성됩니다.

첫 번째는 **역할(Role)**입니다. "당신은 파이썬 전문가입니다" 같은 문장으로 LLM의 전문성을 설정합니다.

이렇게 하면 LLM이 해당 분야의 베스트 프랙티스를 적용한 코드를 생성합니다. 두 번째는 **맥락(Context)**입니다.

코드가 사용될 환경과 목적을 설명합니다. "학생 성적 관리 시스템"이라고 하면, LLM은 교육 도메인에 맞는 변수명과 로직을 사용합니다.

세 번째는 **요구사항(Requirement)**입니다. 구체적인 기능을 나열합니다.

"성적 기준 내림차순 정렬", "타입 힌트 포함" 같은 명확한 항목들이 여기에 속합니다. 네 번째는 **제약조건(Constraint)**입니다.

사용할 수 있는 라이브러리, 성능 요구사항, 코드 스타일 등을 명시합니다. "Python 3.9+ 표준 라이브러리만 사용"이라고 하면, 외부 패키지를 사용하지 않는 코드가 생성됩니다.

위의 코드 예시를 비교해보겠습니다. 나쁜 프롬프트 "정렬 함수 만들어줘"는 너무 애매합니다.

무엇을 정렬할지, 어떤 기준으로 정렬할지, 어떤 언어로 작성할지 전혀 알 수 없습니다. 반면 좋은 프롬프트는 네 가지 요소를 모두 포함하고 있습니다.

역할을 설정하고, 맥락을 제공하고, 구체적인 요구사항을 나열하고, 제약조건까지 명시했습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 전자상거래 시스템의 결제 모듈을 개발한다고 가정해봅시다. "결제 함수 만들어줘"라고 하는 대신, "당신은 보안 전문가입니다.

PCI-DSS 규정을 준수하는 신용카드 결제 검증 함수를 작성해주세요. 카드번호 형식 검증, Luhn 알고리즘 적용, 민감정보 로깅 금지" 같은 패턴을 사용합니다.

이렇게 하면 보안 요구사항을 충족하는 코드를 한 번에 얻을 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 너무 긴 프롬프트를 작성하는 것입니다. 정보가 많다고 좋은 것은 아닙니다.

핵심 정보만 간결하게 전달하는 것이 더 효과적입니다. 또한 모든 경우에 똑같은 패턴을 사용하는 것도 문제입니다.

간단한 헬퍼 함수를 만들 때는 역할과 요구사항만으로도 충분합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언을 듣고 프롬프트를 다시 작성한 김개발 씨는 놀라운 결과를 얻었습니다. "와, 제가 원하던 코드가 바로 나왔어요!" 프롬프트 패턴을 제대로 이해하면 LLM을 훨씬 효과적으로 활용할 수 있습니다.

여러분도 오늘 배운 네 가지 요소를 기억하고 실제 작업에 적용해 보세요.

실전 팁

💡 - 프롬프트는 간결하되 핵심 정보는 빠뜨리지 마세요

생성된 코드를 바로 사용하지 말고 항상 검토하세요
같은 패턴을 템플릿으로 저장해두고 재사용하세요

2. 언어별 프롬프트 차이

김개발 씨가 파이썬 프롬프트 패턴에 익숙해지자, 이번에는 자바스크립트 코드를 생성해야 하는 상황이 왔습니다. 파이썬에서 쓰던 프롬프트를 그대로 사용했더니, 이상하게 ES5 문법의 오래된 코드가 나왔습니다.

박시니어 씨가 말했습니다. "언어마다 프롬프트 작성법이 조금씩 달라요."

언어별 프롬프트 차이는 각 프로그래밍 언어의 특성과 생태계를 고려한 프롬프트 작성법입니다. 파이썬은 타입 힌트와 PEP 표준을, 자바스크립트는 ES 버전과 런타임을, 자바는 버전과 프레임워크를 명시해야 합니다.

같은 기능을 요청해도 언어마다 다른 방식으로 접근해야 최신 베스트 프랙티스를 반영한 코드를 얻을 수 있습니다.

다음 코드를 살펴봅시다.

# Python 프롬프트
"""
Python 3.10+ 전문가로서 다음 함수를 작성해주세요:
- 타입 힌트 사용 (from typing import List, Dict)
- dataclass 활용
- PEP 8 스타일 준수
"""

# JavaScript 프롬프트
"""
당신은 모던 JavaScript (ES2022+) 전문가입니다:
- async/await 패턴 사용
- 화살표 함수 사용
- 구조 분해 할당 활용
- Node.js 18+ 환경
"""

# Java 프롬프트
"""
Java 17+ Spring Boot 전문가로서:
- record 클래스 사용
- Optional 활용
- Stream API 사용
- Lombok 어노테이션 적용
"""

김개발 씨는 파이썬으로 프롬프트 작성에 자신감이 붙었습니다. 이제는 프론트엔드 작업을 위해 자바스크립트 코드를 생성해야 했습니다.

"똑같이 하면 되겠지" 생각하며 파이썬 프롬프트를 살짝 수정해서 사용했습니다. 그런데 이게 웬일입니까.

나온 코드를 보니 var 키워드에 function 선언식, 콜백 지옥까지. 마치 10년 전 코드를 보는 것 같았습니다.

"이거 왜 이렇게 나와요?" 박시니어 씨가 프롬프트를 보더니 웃으며 말했습니다. "언어마다 특성이 다르니까 프롬프트도 달라져야죠." 언어별 프롬프트 차이는 왜 중요할까요?

마치 같은 요리를 만들어도 지역마다 조리법이 다른 것과 같습니다. 김치찌개를 끓이는데 한국식, 일본식, 중국식이 다르듯이, 코드 생성도 언어의 문화와 생태계를 반영해야 합니다.

파이썬은 "명확함이 암묵보다 낫다"는 철학을, 자바스크립트는 빠른 진화와 다양한 런타임을, 자바는 엔터프라이즈 환경과 강타입 시스템을 중요시합니다. 언어 특성을 고려하지 않으면 어떤 일이 벌어질까요?

개발자들은 LLM에게 "함수 만들어줘"라고 똑같이 요청했습니다. 그러면 LLM은 가장 보편적이고 안전한, 즉 가장 오래된 문법으로 코드를 생성했습니다.

자바스크립트는 ES5, 파이썬은 타입 힌트 없이, 자바는 Java 8 스타일로 나왔습니다. 현대적인 기능을 사용하지 않으니 코드가 장황하고 유지보수하기 어려웠습니다.

바로 이런 문제를 해결하기 위해 언어별 프롬프트 전략이 필요합니다. 각 언어의 최신 버전과 주요 기능을 명시하면 현대적인 코드를 얻을 수 있습니다.

또한 해당 언어의 커뮤니티 표준과 베스트 프랙티스를 반영한 코드가 생성됩니다. 무엇보다 언어의 강점을 최대한 활용하는 효율적인 코드를 작성할 수 있습니다.

파이썬 프롬프트의 핵심을 살펴보겠습니다. 파이썬은 타입 힌트를 강조해야 합니다.

"타입 힌트 사용"이라고 명시하면 def process(data: List[Dict[str, Any]]) -> Optional[str] 같은 명확한 시그니처가 나옵니다. 또한 PEP 표준을 언급하면 일관된 스타일의 코드가 생성됩니다.

dataclass, pathlib, f-string 같은 현대적 기능도 적극 활용됩니다. 자바스크립트는 접근 방식이 다릅니다.

가장 중요한 것은 ES 버전입니다. "ES2022+" 같이 명시하면 최신 문법을 사용합니다.

const, let, 화살표 함수, async/await가 기본이 됩니다. 또한 런타임 환경도 중요합니다.

"Node.js 18+"이라고 하면 top-level await를 사용하고, "브라우저 환경"이라고 하면 Web API를 활용합니다. 자바는 또 다른 특징이 있습니다.

Java 버전과 함께 프레임워크를 명시해야 합니다. "Java 17+ Spring Boot"라고 하면 record 클래스, sealed 클래스, Stream API를 적극 활용합니다.

Lombok 같은 도구를 언급하면 보일러플레이트 코드를 줄인 깔끔한 코드가 나옵니다. 실제 프로젝트에서 어떻게 활용할까요?

마이크로서비스 아키텍처를 구축한다고 가정해봅시다. 백엔드는 Java Spring Boot, 프론트엔드는 React(TypeScript), 데이터 처리는 Python으로 개발합니다.

각 언어마다 프롬프트를 다르게 작성해야 합니다. Java는 "Spring Boot 3.x, WebFlux, R2DBC", TypeScript는 "React 18, TypeScript 5.x, 함수형 컴포넌트", Python은 "FastAPI, Pydantic, async/await" 같은 키워드를 포함합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 너무 많은 기술 스택을 한 번에 요청하는 것입니다.

"Java Spring Boot JPA QueryDSL Redis Kafka" 같이 나열하면 오히려 초점이 흐려집니다. 핵심 기술 2-3개만 명시하는 것이 효과적입니다.

또한 프로젝트 환경에 맞지 않는 최신 기능을 요청하는 것도 문제입니다. 레거시 시스템을 유지보수한다면 "Java 8 호환" 같은 제약을 명시해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언대로 "ES2022+, async/await, Node.js 18"을 명시하자 깔끔한 모던 자바스크립트 코드가 생성되었습니다.

"이제야 제대로 된 코드가 나오네요!" 언어별 특성을 이해하고 프롬프트에 반영하면 훨씬 좋은 품질의 코드를 얻을 수 있습니다. 여러분도 사용하는 언어의 최신 버전과 주요 기능을 프롬프트에 포함해 보세요.

실전 팁

💡 - 각 언어의 공식 스타일 가이드를 프롬프트에 포함하세요 (PEP 8, Airbnb JavaScript Style 등)

프로젝트에서 사용 중인 주요 라이브러리 버전을 명시하세요
레거시 프로젝트는 호환성 제약조건을 반드시 포함하세요

3. 테스트 케이스 포함 전략

김개발 씨가 LLM으로 생성한 코드를 배포했더니, 프로덕션에서 예상치 못한 버그가 발생했습니다. "왜 로컬에서는 잘 됐는데..." 코드 리뷰를 하던 박시니어 씨가 물었습니다.

"테스트 코드는 작성했나요?" 김개발 씨는 얼굴이 빨개졌습니다. 프롬프트에 테스트 케이스를 포함하지 않았던 것입니다.

테스트 케이스 포함 전략은 코드 생성 프롬프트에 테스트 요구사항을 명시하여 프로덕션 레벨의 신뢰성 있는 코드를 얻는 방법입니다. 단순히 "테스트 코드 작성해줘"가 아니라, 테스트 프레임워크, 커버리지 목표, 엣지 케이스, 모킹 전략을 구체적으로 요청해야 합니다.

좋은 테스트 케이스는 정상 케이스, 경계값 테스트, 예외 처리, 성능 테스트를 모두 포함합니다.

다음 코드를 살펴봅시다.

# 테스트 포함 프롬프트 예시
"""
Python 전문가로서 사용자 나이 검증 함수를 작성해주세요.

요구사항:
- 입력: 나이 (정수)
- 반환: 성인 여부 (boolean)
- 성인 기준: 만 19세 이상

테스트 요구사항 (pytest 사용):

4. 커버리지: 100%

김개발 씨는 기능 개발 속도가 빨라졌다고 자랑했습니다. LLM 덕분에 하루에 여러 기능을 뚝딱 만들어낼 수 있었으니까요.

하지만 문제는 곧 찾아왔습니다. 프로덕션에 배포한 결제 검증 함수에서 특정 입력값에 대해 크래시가 발생한 것입니다.

급히 로그를 확인해보니 None 값이 들어왔을 때 처리하지 못한 것이었습니다. 로컬에서는 항상 정상적인 데이터로만 테스트했기 때문에 발견하지 못했습니다.

박시니어 씨가 말했습니다. "코드만 생성하지 말고, 테스트 케이스도 함께 요청해야 해요." 테스트 케이스 포함 전략은 왜 필수적일까요?

마치 자동차를 출고하기 전에 안전 검사를 하는 것과 같습니다. 엔진이 잘 돌아가는지만 확인하는 것이 아니라, 급정거 시 브레이크가 작동하는지, 빗길에서 미끄러지지 않는지, 충돌 시 에어백이 터지는지 모두 검증합니다.

코드도 마찬가지입니다. 정상 동작만 확인하면 실제 환경에서 예상치 못한 문제가 발생합니다.

테스트 없이 코드만 생성하면 어떤 일이 벌어질까요? 개발자들은 LLM이 만든 코드를 바로 사용했습니다.

겉보기에는 잘 작동하는 것처럼 보였습니다. 하지만 사용자가 예상 밖의 입력을 넣거나, 네트워크가 끊기거나, 데이터베이스 연결이 실패하면 프로그램이 멈췄습니다.

더 심각한 것은 보안 취약점이었습니다. SQL 인젝션, XSS 같은 공격에 무방비로 노출되었습니다.

바로 이런 문제를 예방하기 위해 테스트 케이스를 프롬프트에 포함해야 합니다. 테스트 케이스를 명시하면 LLM이 엣지 케이스를 고려한 방어적 코드를 작성합니다.

또한 테스트 코드를 함께 생성하므로 배포 전에 검증할 수 있습니다. 무엇보다 코드의 의도와 동작을 명확히 문서화하는 효과가 있습니다.

효과적인 테스트 케이스 프롬프트의 구조를 살펴보겠습니다. 첫 번째는 테스트 프레임워크 명시입니다.

"pytest 사용", "Jest 사용", "JUnit 5 사용" 같이 구체적으로 지정합니다. 이렇게 하면 해당 프레임워크의 관례와 헬퍼 함수를 활용한 테스트가 생성됩니다.

두 번째는 정상 케이스입니다. 기본적인 입력에 대한 예상 출력을 나열합니다.

"19세는 True, 18세는 False" 같이 명확한 예시를 제공하면 LLM이 의도를 정확히 파악합니다. 세 번째는 경계값 테스트입니다.

0, 음수, 최대값, 최소값 같은 극단적인 경우를 명시합니다. 이것이 가장 많은 버그를 발견합니다.

네 번째는 예외 케이스입니다. 잘못된 타입, None, 빈 문자열 등 비정상 입력에 대한 처리를 요청합니다.

"음수, 문자열, None은 ValueError 발생" 같이 구체적으로 지정합니다. 다섯 번째는 커버리지 목표입니다.

"커버리지 100%"라고 명시하면 모든 분기를 테스트하는 코드가 생성됩니다. 실제 프로젝트에서 어떻게 활용할까요?

사용자 인증 시스템을 개발한다고 가정해봅시다. 단순히 "로그인 함수 만들어줘"가 아니라, 다음과 같이 요청합니다.

"pytest 사용, 정상 로그인(200), 잘못된 비밀번호(401), 존재하지 않는 사용자(404), SQL 인젝션 방어, 레이트 리미팅 테스트, 모킹은 pytest-mock 사용". 이렇게 하면 보안과 성능까지 고려한 완전한 코드를 얻습니다.

주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 너무 많은 테스트 케이스를 한 번에 요청하는 것입니다.

100개의 케이스를 나열하면 오히려 집중력이 떨어집니다. 핵심적인 5-7개 케이스만 명시하는 것이 효과적입니다.

또한 테스트만 요청하고 구현 코드를 수정하지 않으면 테스트가 실패할 수 있습니다. "테스트를 통과하도록 코드 수정"이라는 요청을 추가해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언대로 테스트 케이스를 포함한 프롬프트를 작성했더니, None 처리부터 타입 검증까지 완벽한 코드가 생성되었습니다.

"이제야 안심하고 배포할 수 있겠어요!" 테스트 케이스를 프롬프트에 포함하면 신뢰성 있는 프로덕션 코드를 얻을 수 있습니다. 여러분도 오늘부터 테스트 요구사항을 꼭 명시해 보세요.

실전 팁

💡 - AAA 패턴(Arrange-Act-Assert)을 명시하면 구조화된 테스트가 생성됩니다

모킹이 필요한 외부 의존성(DB, API)을 미리 명시하세요
성능이 중요한 함수는 "O(n) 복잡도 테스트 포함" 같은 요구사항을 추가하세요

4. 실습 다양한 언어 코드 생성

김개발 씨는 이제 프롬프트 작성에 자신감이 붙었습니다. 오늘은 실제로 여러 언어로 같은 기능을 구현해보기로 했습니다.

"사용자 데이터를 JSON 파일로 저장하고 읽는 함수를 파이썬, 자바스크립트, 자바로 각각 만들어볼게요." 박시니어 씨가 고개를 끄덕이며 말했습니다. "좋아요.

언어마다 어떻게 다르게 요청하는지 보여주세요."

다양한 언어 코드 생성 실습은 동일한 기능을 여러 프로그래밍 언어로 구현하면서 언어별 특성을 반영한 프롬프트 작성법을 익히는 과정입니다. 같은 기능이라도 파이썬은 간결함과 타입 힌트를, 자바스크립트는 비동기 처리를, 자바는 타입 안정성과 예외 처리를 강조해야 합니다.

이 실습을 통해 각 언어의 강점을 최대한 활용하는 코드를 생성하는 방법을 배웁니다.

다음 코드를 살펴봅시다.

# Python 프롬프트
"""
Python 3.10+ 전문가로서 사용자 데이터 JSON 저장/로드 함수 작성:
- pathlib 사용
- 타입 힌트: TypedDict 또는 dataclass
- 예외: FileNotFoundError, JSONDecodeError 처리
- pytest 테스트 포함
"""

# JavaScript 프롬프트
"""
Node.js 18+ 전문가로서 사용자 데이터 JSON 저장/로드 함수 작성:
- fs.promises 사용 (async/await)
- TypeScript 타입 정의
- 에러 핸들링: try-catch
- Jest 테스트 포함
"""

# Java 프롬프트
"""
Java 17+ 전문가로서 사용자 데이터 JSON 저장/로드 메서드 작성:
- record 클래스로 User 정의
- Jackson ObjectMapper 사용
- Optional<User> 반환
- JUnit 5 테스트 포함
"""

김개발 씨는 팀에서 멀티 언어 프로젝트를 맡게 되었습니다. 백엔드는 자바, 관리자 도구는 파이썬, 프론트엔드는 자바스크립트로 개발하는 마이크로서비스 아키텍처였습니다.

"모든 서비스에서 사용자 데이터를 JSON으로 저장하고 읽어야 해요." 문제는 각 언어마다 어떻게 다르게 요청해야 할지 막막했습니다. 박시니어 씨가 조언했습니다.

"같은 기능이라도 언어의 철학과 생태계를 반영해야 해요. 파이썬은 명시적이고 간결하게, 자바스크립트는 비동기 우선으로, 자바는 타입 안정성과 객체지향적으로 접근하세요." 다양한 언어로 코드 생성할 때 핵심은 무엇일까요?

마치 같은 이야기를 다른 나라 말로 번역하는 것과 같습니다. 단순히 단어만 바꾸는 것이 아니라, 그 나라의 문화와 표현 방식을 고려해야 합니다.

"I love you"를 한국어로 번역할 때 상황에 따라 "사랑해", "좋아해", "아껴" 등으로 다르게 표현하듯이, 코드도 언어의 특성을 살려야 자연스럽습니다. 언어별 차이를 무시하고 똑같은 프롬프트를 사용하면 어떻게 될까요?

개발자들은 "JSON 파일 읽고 쓰는 함수 만들어줘"라고 모든 언어에 동일하게 요청했습니다. 결과는 어색했습니다.

파이썬은 open() 함수로 파일을 열었지만 pathlib의 장점을 활용하지 못했습니다. 자바스크립트는 동기 API인 fs.readFileSync를 사용해서 Node.js의 비동기 장점을 살리지 못했습니다.

자바는 raw FileReader를 써서 Jackson 같은 표준 라이브러리를 무시했습니다. 바로 이런 문제를 해결하려면 언어별 맞춤 프롬프트가 필요합니다.

각 언어의 현대적인 API와 라이브러리를 명시하면 깔끔한 코드를 얻습니다. 또한 언어 커뮤니티의 베스트 프랙티스를 자동으로 반영합니다.

무엇보다 유지보수하기 쉽고 팀원들이 이해하기 쉬운 관용적 코드가 생성됩니다. 파이썬 프롬프트를 자세히 살펴보겠습니다.

pathlib을 명시한 이유는 현대 파이썬의 파일 처리 표준이기 때문입니다. Path 객체는 OS에 독립적이고 체이닝이 가능해서 코드가 간결합니다.

타입 힌트는 TypedDict 또는 dataclass로 사용자 데이터 구조를 명확히 정의합니다. 이렇게 하면 IDE 자동완성과 타입 체킹이 가능해집니다.

예외 처리는 파이썬 스타일로 try-except를 사용하되, 구체적인 예외(JSONDecodeError)를 잡도록 요청합니다. 자바스크립트 프롬프트는 접근이 다릅니다.

fs.promises와 async/await을 강조한 이유는 Node.js가 비동기 I/O를 기반으로 하기 때문입니다. 파일 읽기는 시간이 걸리는 작업이므로 비동기로 처리해야 다른 요청을 블로킹하지 않습니다.

TypeScript 타입 정의를 요청하면 인터페이스로 사용자 데이터를 정의해서 타입 안정성을 확보합니다. 에러 핸들링은 try-catch로 Promise rejection을 처리합니다.

자바 프롬프트는 또 다른 특징이 있습니다. record 클래스는 Java 17의 현대적 기능으로 불변 데이터를 간결하게 표현합니다.

record User(String name, int age)만으로 getter, equals, hashCode를 자동 생성합니다. Jackson ObjectMapper는 자바 생태계의 사실상 표준 JSON 라이브러리입니다.

Optional 반환은 null 안정성을 보장하는 자바의 모던 프랙티스입니다. 실제로 생성된 코드를 비교해보겠습니다.

파이썬 코드는 10줄 이내로 간결합니다. json.load()와 json.dump()가 핵심이고, pathlib의 read_text()로 한 줄에 파일을 읽습니다.

자바스크립트는 async 함수로 비동기 처리가 명확하고, JSON.parse()와 JSON.stringify()로 변환합니다. 자바는 타입이 명확하고 예외 처리가 체계적이며, ObjectMapper가 자동으로 JSON을 객체로 매핑합니다.

실무에서는 어떻게 활용할까요? 마이크로서비스마다 최적의 언어로 개발하는 것이 트렌드입니다.

데이터 처리는 파이썬, 고성능 API는 Go나 Rust, 엔터프라이즈 로직은 Java, 프론트엔드는 TypeScript로 나눕니다. 각 서비스에 맞는 프롬프트를 작성하면 언어 간 일관성을 유지하면서도 각 언어의 장점을 최대한 활용할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들은 한 언어에 익숙한 패턴을 다른 언어에 그대로 적용하려 합니다.

예를 들어 파이썬의 덕 타이핑 사고방식을 자바에 적용하면 타입 시스템을 제대로 활용하지 못합니다. 각 언어의 철학을 존중하고 그에 맞는 코드를 요청해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 언어별로 최적화된 프롬프트를 작성한 결과, 각 서비스가 자연스럽고 효율적인 코드로 구현되었습니다.

"이제 각 언어의 강점이 뭔지 확실히 알겠어요!" 같은 기능도 언어에 맞게 다르게 요청하면 훨씬 좋은 코드를 얻습니다. 여러분도 멀티 언어 프로젝트에서 오늘 배운 전략을 활용해 보세요.

실전 팁

💡 - 각 언어의 공식 문서에서 권장하는 라이브러리를 먼저 확인하세요

팀의 코딩 컨벤션이 있다면 프롬프트에 포함하세요 (예: Airbnb Style Guide)
여러 언어로 같은 기능을 구현할 때는 API 인터페이스를 먼저 설계하세요

5. 실습 버그 수정 프롬프트

김개발 씨는 프로덕션에서 발생한 버그 리포트를 받았습니다. "사용자 목록 조회가 간헐적으로 실패한다"는 내용이었습니다.

코드를 보니 복잡한 로직이라 어디가 문제인지 파악하기 어려웠습니다. "LLM에게 버그를 찾아달라고 해볼까요?" 박시니어 씨가 말했습니다.

"좋은 생각이지만, 버그 수정 프롬프트는 일반 코드 생성과 다르게 접근해야 해요."

버그 수정 프롬프트는 문제가 있는 코드를 LLM에게 제공하고 원인 분석과 해결 방법을 요청하는 특별한 프롬프트 패턴입니다. 단순히 "버그 고쳐줘"가 아니라, 증상, 재현 방법, 예상 동작, 실제 동작, 환경 정보를 구체적으로 제공해야 합니다.

효과적인 버그 수정 프롬프트는 문제 코드, 에러 메시지, 로그, 테스트 케이스를 모두 포함하며, LLM이 단계적으로 분석하고 여러 해결책을 제시하도록 유도합니다.

다음 코드를 살펴봅시다.

# 버그 수정 프롬프트 템플릿
"""
당신은 시니어 디버깅 전문가입니다.
다음 버그를 분석하고 수정해주세요.

**증상**: 사용자 목록 조회 시 간헐적으로 빈 배열 반환

**환경**:
- Python 3.10, FastAPI 0.104
- PostgreSQL 14
- 동시 사용자 100명 이상일 때 발생

**문제 코드**:
async def get_users():
    users = []
    for user_id in user_ids:
        user = await db.get_user(user_id)
        users.append(user)
    return users

**에러 로그**: (없음, 단순히 빈 배열 반환)

**예상 동작**: 모든 사용자 반환
**실제 동작**: 간헐적으로 빈 배열

**요청사항**:

4. 수정된 코드와 단위 테스트

김개발 씨는 또 다시 프로덕션 버그로 고민에 빠졌습니다. 이번에는 더 복잡했습니다.

로컬 환경에서는 완벽하게 작동하는데, 프로덕션에서만 간헐적으로 실패했습니다. 재현도 어려웠습니다.

100명 이상이 동시에 접속할 때만 문제가 발생했으니까요. "일단 LLM에게 물어봐야겠다" 싶어서 코드를 복사해서 "이 코드 버그 고쳐줘"라고 요청했습니다.

돌아온 답변은 일반적인 코드 개선 제안이었습니다. 변수명을 바꾸라거나, 주석을 추가하라는 내용이었습니다.

정작 버그 원인은 찾지 못했습니다. 박시니어 씨가 김개발 씨의 프롬프트를 보고 말했습니다.

"버그 수정은 다르게 접근해야 해요. 의사가 환자를 진단하듯이, 증상과 상황을 자세히 설명해야 합니다." 버그 수정 프롬프트는 왜 특별할까요?

마치 의사에게 "아파요"라고만 말하는 것과 "어제부터 오른쪽 배가 아프고, 식사 후에 더 심해지며, 열은 37.8도입니다"라고 말하는 차이와 같습니다. 후자가 정확한 진단을 받을 확률이 훨씬 높습니다.

버그도 마찬가지입니다. 상황을 구체적으로 설명할수록 정확한 해결책을 얻습니다.

막연한 버그 수정 요청은 어떤 문제가 있을까요? 개발자들은 코드만 던지고 "고쳐줘"라고 했습니다.

LLM은 코드 자체의 문제점을 찾으려 했지만, 실제 버그는 환경이나 데이터에서 발생했습니다. 타임아웃, 레이스 컨디션, 메모리 누수 같은 런타임 이슈는 코드만 봐서는 발견하기 어렵습니다.

결국 시간만 낭비하고 버그는 해결되지 않았습니다. 바로 이런 문제를 해결하려면 구조화된 버그 리포트가 필요합니다.

증상, 환경, 재현 방법, 로그를 모두 제공하면 LLM이 문맥을 이해하고 정확한 분석을 합니다. 또한 여러 해결책을 요청하면 상황에 맞는 최선의 방법을 선택할 수 있습니다.

무엇보다 테스트 케이스를 함께 요청하면 수정 후 재발을 방지할 수 있습니다. 효과적인 버그 수정 프롬프트의 구조를 살펴보겠습니다.

첫 번째는 증상 설명입니다. "간헐적으로 빈 배열 반환"처럼 구체적으로 무엇이 잘못되었는지 기술합니다.

"가끔 안 돼요"는 너무 애매합니다. 두 번째는 환경 정보입니다.

프로그래밍 언어 버전, 프레임워크, 데이터베이스, 동시 사용자 수 등 재현 조건을 명시합니다. "Python 3.10, FastAPI, PostgreSQL, 동시 사용자 100명 이상"처럼 구체적일수록 좋습니다.

세 번째는 문제 코드입니다. 버그가 있는 함수나 클래스를 제공합니다.

전체 파일을 다 주는 것보다 핵심 부분만 추출하는 것이 효과적입니다. 네 번째는 에러 로그입니다.

스택 트레이스, 에러 메시지, 애플리케이션 로그를 포함합니다. 에러가 없더라도 "에러 로그 없음, 단순히 빈 배열 반환"처럼 명시합니다.

다섯 번째는 예상/실제 동작입니다. 무엇을 기대했고 실제로는 어떻게 동작했는지 대비합니다.

이것이 LLM이 의도를 파악하는 핵심 정보입니다. 여섯 번째는 요청사항입니다.

단순 수정만이 아니라 "근본 원인 분석", "여러 해결 방법 제시", "테스트 케이스 작성"을 명시합니다. 위 프롬프트의 예시를 분석해보겠습니다.

코드를 보면 async/await을 사용하지만 순차적으로 처리하고 있습니다. 동시 사용자가 많을 때 데이터베이스 연결 풀이 고갈될 수 있습니다.

LLM은 이를 분석하고, 병렬 처리(asyncio.gather), 배치 쿼리(단일 SELECT), 연결 풀 확장 같은 여러 해결책을 제시할 것입니다. 실무에서는 어떻게 활용할까요?

프로덕션 장애가 발생하면 모니터링 도구에서 로그와 메트릭을 수집합니다. 이 정보를 버그 수정 프롬프트에 포함합니다.

"CPU 사용률 90%, 데이터베이스 연결 풀 고갈, 응답 시간 30초 이상" 같은 메트릭은 LLM이 성능 문제를 분석하는 데 결정적입니다. 또한 Git blame으로 언제 코드가 변경되었는지, 어떤 커밋에서 버그가 유입되었는지 추적한 정보도 유용합니다.

하지만 주의할 점도 있습니다. 초보 개발자들은 민감한 정보를 프롬프트에 포함하는 실수를 합니다.

API 키, 비밀번호, 사용자 개인정보가 로그에 있다면 반드시 마스킹해야 합니다. 또한 LLM의 답변을 맹신하면 안 됩니다.

제시된 해결책을 검증하고, 테스트 환경에서 충분히 확인한 후 프로덕션에 적용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨가 알려준 대로 구조화된 프롬프트를 작성했더니, LLM이 레이스 컨디션을 정확히 지적하고 asyncio.gather로 병렬 처리하는 해결책을 제시했습니다. 테스트 케이스까지 생성되어 수정 후 재발 방지도 가능했습니다.

"이제 버그 수정도 체계적으로 할 수 있겠어요!" 버그 수정 프롬프트는 증상, 환경, 로그를 구체적으로 제공하고 여러 해결책을 요청하는 것이 핵심입니다. 여러분도 다음 버그를 만나면 오늘 배운 템플릿을 활용해 보세요.

실전 팁

💡 - 재현 가능한 최소 코드(Minimal Reproducible Example)를 제공하면 분석이 빨라집니다

버그가 발생하는 조건과 발생하지 않는 조건을 대비해서 설명하세요
LLM이 제시한 해결책은 반드시 코드 리뷰를 거쳐야 합니다

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

#LLM#프롬프트엔지니어링#코드생성#테스트케이스#디버깅#LLM,코드생성,프롬프트

코드 생성 프롬프트 완벽 가이드

# 코드 생성 프롬프트 완벽 가이드 LLM을 활용한 효과적인 코드 생성 프롬프트 작성법을 배웁니다. 언어별 특성, 테스트 케이스 포함 전략, 그리고 실전 예제를 통해 프롬프트 엔지니어링의 핵심을 익힙니다. --- ## 목차 1. [코드_생성_프롬프트_패턴](#코드-생성-프롬프트-패턴) 2. [언어별_프롬프트_차이](#언어별-프롬프트-차이) 3. [테스트_케이스_포함_전략](#테스트-케이스-포함-전략) 4. [커버리지: 100%](#커버리지:-100%) 4. [실습_다양한_언어_코드_생성](#실습-다양한-언어-코드-생성) 5. [실습_버그_수정_프롬프트](#실습-버그-수정-프롬프트) 4. [수정된 코드와 단위 테스트](#수정된-코드와-단위-테스트) --- ## 1. 코드_생성_프롬프트_패턴 김개발 씨는 최근 ChatGPT를 사용해서 코드를 생성해보려 했지만, 번번이 원하는 결과를 얻지 못했습니다. "파이썬으로 정렬 함수 만들어줘"라고 했더니, 너무 간단하거나 아니면 너무 복잡한 코드가 나왔습니다. 박시니어 씨가 그의 화면을 보고는 말했습니다. "프롬프트 패턴을 알면 훨씬 좋은 결과를 얻을 수 있어요." **코드 생성 프롬프트 패턴**은 LLM에게 코드를 요청할 때 사용하는 효과적인 질문 구조입니다. 마치 요리 레시피처럼, 무엇을(What), 어떻게(How), 왜(Why)를 명확히 전달해야 좋은 결과를 얻습니다. 좋은 프롬프트는 역할(Role), 맥락(Context), 요구사항(Requirement), 제약조건(Constraint)을 포함합니다. 이 패턴을 익히면 코드 생성의 정확도가 크게 향상됩니다. 다음 코드를 살펴봅시다. ```python # 나쁜 프롬프트 예시 "정렬 함수 만들어줘" # 좋은 프롬프트 예시 (패턴 적용) """ 당신은 파이썬 전문가입니다. 다음 요구사항에 맞는 정렬 함수를 작성해주세요: 맥락: 학생 성적 관리 시스템 요구사항: - 학생 객체 리스트를 성적 기준 내림차순 정렬 - 성적이 같으면 이름 기준 오름차순 - 타입 힌트 포함 - docstring 포함 제약조건: - Python 3.9+ 표준 라이브러리만 사용 - 시간복잡도 O(n log n) """ ``` 김개발 씨는 입사 2개월 차 주니어 개발자입니다. 최근 회사에서 LLM을 활용한 개발 도구를 도입했는데, 동료들은 뚝딱뚝딱 코드를 만들어내는데 자신만 제대로 된 결과를 얻지 못했습니다. 답답한 마음에 박시니어 씨에게 물어봤습니다. "시니어님, 저는 왜 자꾸 이상한 코드가 나올까요?" 박시니어 씨가 김개발 씨의 프롬프트를 보더니 고개를 끄덕였습니다. "아, 프롬프트가 너무 애매하네요. 패턴을 따라서 작성해보세요." 그렇다면 **코드 생성 프롬프트 패턴**이란 정확히 무엇일까요? 쉽게 비유하자면, 프롬프트 패턴은 마치 음식점에서 주문하는 방법과 같습니다. "음식 주세요"라고 하면 뭘 줘야 할지 모르지만, "매운 떡볶이 1인분, 치즈 추가, 덜 맵게 해주세요"라고 하면 정확히 원하는 음식을 받을 수 있습니다. LLM도 마찬가지입니다. 구체적이고 구조화된 요청을 해야 원하는 코드를 얻을 수 있습니다. 패턴이 없던 시절에는 어땠을까요? 개발자들은 "함수 만들어줘", "버그 고쳐줘" 같은 모호한 요청을 했고, LLM은 추측으로 코드를 생성했습니다. 결과는 대부분 쓸모없거나 잘못된 코드였습니다. 더 큰 문제는 여러 번 시도해도 원하는 결과를 얻지 못해 시간만 낭비한다는 것이었습니다. 프롬프트를 수정할 때마다 완전히 다른 코드가 나와서 일관성도 없었습니다. 바로 이런 문제를 해결하기 위해 **프롬프트 패턴**이 등장했습니다. 프롬프트 패턴을 사용하면 LLM이 정확히 무엇을 만들어야 하는지 이해할 수 있습니다. 또한 일관된 품질의 코드를 반복적으로 생성할 수 있습니다. 무엇보다 한 번에 원하는 결과를 얻을 확률이 크게 높아진다는 이점이 있습니다. 효과적인 프롬프트 패턴은 네 가지 핵심 요소로 구성됩니다. 첫 번째는 **역할(Role)**입니다. "당신은 파이썬 전문가입니다" 같은 문장으로 LLM의 전문성을 설정합니다. 이렇게 하면 LLM이 해당 분야의 베스트 프랙티스를 적용한 코드를 생성합니다. 두 번째는 **맥락(Context)**입니다. 코드가 사용될 환경과 목적을 설명합니다. "학생 성적 관리 시스템"이라고 하면, LLM은 교육 도메인에 맞는 변수명과 로직을 사용합니다. 세 번째는 **요구사항(Requirement)**입니다. 구체적인 기능을 나열합니다. "성적 기준 내림차순 정렬", "타입 힌트 포함" 같은 명확한 항목들이 여기에 속합니다. 네 번째는 **제약조건(Constraint)**입니다. 사용할 수 있는 라이브러리, 성능 요구사항, 코드 스타일 등을 명시합니다. "Python 3.9+ 표준 라이브러리만 사용"이라고 하면, 외부 패키지를 사용하지 않는 코드가 생성됩니다. 위의 코드 예시를 비교해보겠습니다. 나쁜 프롬프트 "정렬 함수 만들어줘"는 너무 애매합니다. 무엇을 정렬할지, 어떤 기준으로 정렬할지, 어떤 언어로 작성할지 전혀 알 수 없습니다. 반면 좋은 프롬프트는 네 가지 요소를 모두 포함하고 있습니다. 역할을 설정하고, 맥락을 제공하고, 구체적인 요구사항을 나열하고, 제약조건까지 명시했습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 전자상거래 시스템의 결제 모듈을 개발한다고 가정해봅시다. "결제 함수 만들어줘"라고 하는 대신, "당신은 보안 전문가입니다. PCI-DSS 규정을 준수하는 신용카드 결제 검증 함수를 작성해주세요. 카드번호 형식 검증, Luhn 알고리즘 적용, 민감정보 로깅 금지" 같은 패턴을 사용합니다. 이렇게 하면 보안 요구사항을 충족하는 코드를 한 번에 얻을 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 긴 프롬프트를 작성하는 것입니다. 정보가 많다고 좋은 것은 아닙니다. 핵심 정보만 간결하게 전달하는 것이 더 효과적입니다. 또한 모든 경우에 똑같은 패턴을 사용하는 것도 문제입니다. 간단한 헬퍼 함수를 만들 때는 역할과 요구사항만으로도 충분합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 듣고 프롬프트를 다시 작성한 김개발 씨는 놀라운 결과를 얻었습니다. "와, 제가 원하던 코드가 바로 나왔어요!" 프롬프트 패턴을 제대로 이해하면 LLM을 훨씬 효과적으로 활용할 수 있습니다. 여러분도 오늘 배운 네 가지 요소를 기억하고 실제 작업에 적용해 보세요. **실전 팁** 💡 - 프롬프트는 간결하되 핵심 정보는 빠뜨리지 마세요 - 생성된 코드를 바로 사용하지 말고 항상 검토하세요 - 같은 패턴을 템플릿으로 저장해두고 재사용하세요 --- ## 2. 언어별_프롬프트_차이 김개발 씨가 파이썬 프롬프트 패턴에 익숙해지자, 이번에는 자바스크립트 코드를 생성해야 하는 상황이 왔습니다. 파이썬에서 쓰던 프롬프트를 그대로 사용했더니, 이상하게 ES5 문법의 오래된 코드가 나왔습니다. 박시니어 씨가 말했습니다. "언어마다 프롬프트 작성법이 조금씩 달라요." **언어별 프롬프트 차이**는 각 프로그래밍 언어의 특성과 생태계를 고려한 프롬프트 작성법입니다. 파이썬은 타입 힌트와 PEP 표준을, 자바스크립트는 ES 버전과 런타임을, 자바는 버전과 프레임워크를 명시해야 합니다. 같은 기능을 요청해도 언어마다 다른 방식으로 접근해야 최신 베스트 프랙티스를 반영한 코드를 얻을 수 있습니다. 다음 코드를 살펴봅시다. ```python # Python 프롬프트 """ Python 3.10+ 전문가로서 다음 함수를 작성해주세요: - 타입 힌트 사용 (from typing import List, Dict) - dataclass 활용 - PEP 8 스타일 준수 """ # JavaScript 프롬프트 """ 당신은 모던 JavaScript (ES2022+) 전문가입니다: - async/await 패턴 사용 - 화살표 함수 사용 - 구조 분해 할당 활용 - Node.js 18+ 환경 """ # Java 프롬프트 """ Java 17+ Spring Boot 전문가로서: - record 클래스 사용 - Optional 활용 - Stream API 사용 - Lombok 어노테이션 적용 """ ``` 김개발 씨는 파이썬으로 프롬프트 작성에 자신감이 붙었습니다. 이제는 프론트엔드 작업을 위해 자바스크립트 코드를 생성해야 했습니다. "똑같이 하면 되겠지" 생각하며 파이썬 프롬프트를 살짝 수정해서 사용했습니다. 그런데 이게 웬일입니까. 나온 코드를 보니 `var` 키워드에 `function` 선언식, 콜백 지옥까지. 마치 10년 전 코드를 보는 것 같았습니다. "이거 왜 이렇게 나와요?" 박시니어 씨가 프롬프트를 보더니 웃으며 말했습니다. "언어마다 특성이 다르니까 프롬프트도 달라져야죠." **언어별 프롬프트 차이**는 왜 중요할까요? 마치 같은 요리를 만들어도 지역마다 조리법이 다른 것과 같습니다. 김치찌개를 끓이는데 한국식, 일본식, 중국식이 다르듯이, 코드 생성도 언어의 문화와 생태계를 반영해야 합니다. 파이썬은 "명확함이 암묵보다 낫다"는 철학을, 자바스크립트는 빠른 진화와 다양한 런타임을, 자바는 엔터프라이즈 환경과 강타입 시스템을 중요시합니다. 언어 특성을 고려하지 않으면 어떤 일이 벌어질까요? 개발자들은 LLM에게 "함수 만들어줘"라고 똑같이 요청했습니다. 그러면 LLM은 가장 보편적이고 안전한, 즉 가장 오래된 문법으로 코드를 생성했습니다. 자바스크립트는 ES5, 파이썬은 타입 힌트 없이, 자바는 Java 8 스타일로 나왔습니다. 현대적인 기능을 사용하지 않으니 코드가 장황하고 유지보수하기 어려웠습니다. 바로 이런 문제를 해결하기 위해 **언어별 프롬프트 전략**이 필요합니다. 각 언어의 최신 버전과 주요 기능을 명시하면 현대적인 코드를 얻을 수 있습니다. 또한 해당 언어의 커뮤니티 표준과 베스트 프랙티스를 반영한 코드가 생성됩니다. 무엇보다 언어의 강점을 최대한 활용하는 효율적인 코드를 작성할 수 있습니다. 파이썬 프롬프트의 핵심을 살펴보겠습니다. 파이썬은 **타입 힌트**를 강조해야 합니다. "타입 힌트 사용"이라고 명시하면 `def process(data: List[Dict[str, Any]]) -> Optional[str]` 같은 명확한 시그니처가 나옵니다. 또한 **PEP 표준**을 언급하면 일관된 스타일의 코드가 생성됩니다. `dataclass`, `pathlib`, `f-string` 같은 현대적 기능도 적극 활용됩니다. 자바스크립트는 접근 방식이 다릅니다. 가장 중요한 것은 **ES 버전**입니다. "ES2022+" 같이 명시하면 최신 문법을 사용합니다. `const`, `let`, 화살표 함수, `async/await`가 기본이 됩니다. 또한 **런타임 환경**도 중요합니다. "Node.js 18+"이라고 하면 top-level await를 사용하고, "브라우저 환경"이라고 하면 Web API를 활용합니다. 자바는 또 다른 특징이 있습니다. **Java 버전**과 함께 **프레임워크**를 명시해야 합니다. "Java 17+ Spring Boot"라고 하면 record 클래스, sealed 클래스, Stream API를 적극 활용합니다. **Lombok** 같은 도구를 언급하면 보일러플레이트 코드를 줄인 깔끔한 코드가 나옵니다. 실제 프로젝트에서 어떻게 활용할까요? 마이크로서비스 아키텍처를 구축한다고 가정해봅시다. 백엔드는 Java Spring Boot, 프론트엔드는 React(TypeScript), 데이터 처리는 Python으로 개발합니다. 각 언어마다 프롬프트를 다르게 작성해야 합니다. Java는 "Spring Boot 3.x, WebFlux, R2DBC", TypeScript는 "React 18, TypeScript 5.x, 함수형 컴포넌트", Python은 "FastAPI, Pydantic, async/await" 같은 키워드를 포함합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 너무 많은 기술 스택을 한 번에 요청하는 것입니다. "Java Spring Boot JPA QueryDSL Redis Kafka" 같이 나열하면 오히려 초점이 흐려집니다. 핵심 기술 2-3개만 명시하는 것이 효과적입니다. 또한 프로젝트 환경에 맞지 않는 최신 기능을 요청하는 것도 문제입니다. 레거시 시스템을 유지보수한다면 "Java 8 호환" 같은 제약을 명시해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언대로 "ES2022+, async/await, Node.js 18"을 명시하자 깔끔한 모던 자바스크립트 코드가 생성되었습니다. "이제야 제대로 된 코드가 나오네요!" 언어별 특성을 이해하고 프롬프트에 반영하면 훨씬 좋은 품질의 코드를 얻을 수 있습니다. 여러분도 사용하는 언어의 최신 버전과 주요 기능을 프롬프트에 포함해 보세요. **실전 팁** 💡 - 각 언어의 공식 스타일 가이드를 프롬프트에 포함하세요 (PEP 8, Airbnb JavaScript Style 등) - 프로젝트에서 사용 중인 주요 라이브러리 버전을 명시하세요 - 레거시 프로젝트는 호환성 제약조건을 반드시 포함하세요 --- ## 3. 테스트_케이스_포함_전략 김개발 씨가 LLM으로 생성한 코드를 배포했더니, 프로덕션에서 예상치 못한 버그가 발생했습니다. "왜 로컬에서는 잘 됐는데..." 코드 리뷰를 하던 박시니어 씨가 물었습니다. "테스트 코드는 작성했나요?" 김개발 씨는 얼굴이 빨개졌습니다. 프롬프트에 테스트 케이스를 포함하지 않았던 것입니다. **테스트 케이스 포함 전략**은 코드 생성 프롬프트에 테스트 요구사항을 명시하여 프로덕션 레벨의 신뢰성 있는 코드를 얻는 방법입니다. 단순히 "테스트 코드 작성해줘"가 아니라, 테스트 프레임워크, 커버리지 목표, 엣지 케이스, 모킹 전략을 구체적으로 요청해야 합니다. 좋은 테스트 케이스는 정상 케이스, 경계값 테스트, 예외 처리, 성능 테스트를 모두 포함합니다. 다음 코드를 살펴봅시다. ```python # 테스트 포함 프롬프트 예시 """ Python 전문가로서 사용자 나이 검증 함수를 작성해주세요. 요구사항: - 입력: 나이 (정수) - 반환: 성인 여부 (boolean) - 성인 기준: 만 19세 이상 테스트 요구사항 (pytest 사용): ``` --- ## 4. 커버리지: 100% 김개발 씨는 기능 개발 속도가 빨라졌다고 자랑했습니다. LLM 덕분에 하루에 여러 기능을 뚝딱 만들어낼 수 있었으니까요. 하지만 문제는 곧 찾아왔습니다. 프로덕션에 배포한 결제 검증 함수에서 특정 입력값에 대해 크래시가 발생한 것입니다. 급히 로그를 확인해보니 `None` 값이 들어왔을 때 처리하지 못한 것이었습니다. 로컬에서는 항상 정상적인 데이터로만 테스트했기 때문에 발견하지 못했습니다. 박시니어 씨가 말했습니다. "코드만 생성하지 말고, 테스트 케이스도 함께 요청해야 해요." **테스트 케이스 포함 전략**은 왜 필수적일까요? 마치 자동차를 출고하기 전에 안전 검사를 하는 것과 같습니다. 엔진이 잘 돌아가는지만 확인하는 것이 아니라, 급정거 시 브레이크가 작동하는지, 빗길에서 미끄러지지 않는지, 충돌 시 에어백이 터지는지 모두 검증합니다. 코드도 마찬가지입니다. 정상 동작만 확인하면 실제 환경에서 예상치 못한 문제가 발생합니다. 테스트 없이 코드만 생성하면 어떤 일이 벌어질까요? 개발자들은 LLM이 만든 코드를 바로 사용했습니다. 겉보기에는 잘 작동하는 것처럼 보였습니다. 하지만 사용자가 예상 밖의 입력을 넣거나, 네트워크가 끊기거나, 데이터베이스 연결이 실패하면 프로그램이 멈췄습니다. 더 심각한 것은 보안 취약점이었습니다. SQL 인젝션, XSS 같은 공격에 무방비로 노출되었습니다. 바로 이런 문제를 예방하기 위해 **테스트 케이스를 프롬프트에 포함**해야 합니다. 테스트 케이스를 명시하면 LLM이 엣지 케이스를 고려한 방어적 코드를 작성합니다. 또한 테스트 코드를 함께 생성하므로 배포 전에 검증할 수 있습니다. 무엇보다 코드의 의도와 동작을 명확히 문서화하는 효과가 있습니다. 효과적인 테스트 케이스 프롬프트의 구조를 살펴보겠습니다. 첫 번째는 **테스트 프레임워크 명시**입니다. "pytest 사용", "Jest 사용", "JUnit 5 사용" 같이 구체적으로 지정합니다. 이렇게 하면 해당 프레임워크의 관례와 헬퍼 함수를 활용한 테스트가 생성됩니다. 두 번째는 **정상 케이스**입니다. 기본적인 입력에 대한 예상 출력을 나열합니다. "19세는 True, 18세는 False" 같이 명확한 예시를 제공하면 LLM이 의도를 정확히 파악합니다. 세 번째는 **경계값 테스트**입니다. 0, 음수, 최대값, 최소값 같은 극단적인 경우를 명시합니다. 이것이 가장 많은 버그를 발견합니다. 네 번째는 **예외 케이스**입니다. 잘못된 타입, `None`, 빈 문자열 등 비정상 입력에 대한 처리를 요청합니다. "음수, 문자열, None은 ValueError 발생" 같이 구체적으로 지정합니다. 다섯 번째는 **커버리지 목표**입니다. "커버리지 100%"라고 명시하면 모든 분기를 테스트하는 코드가 생성됩니다. 실제 프로젝트에서 어떻게 활용할까요? 사용자 인증 시스템을 개발한다고 가정해봅시다. 단순히 "로그인 함수 만들어줘"가 아니라, 다음과 같이 요청합니다. "pytest 사용, 정상 로그인(200), 잘못된 비밀번호(401), 존재하지 않는 사용자(404), SQL 인젝션 방어, 레이트 리미팅 테스트, 모킹은 pytest-mock 사용". 이렇게 하면 보안과 성능까지 고려한 완전한 코드를 얻습니다. 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 너무 많은 테스트 케이스를 한 번에 요청하는 것입니다. 100개의 케이스를 나열하면 오히려 집중력이 떨어집니다. 핵심적인 5-7개 케이스만 명시하는 것이 효과적입니다. 또한 테스트만 요청하고 구현 코드를 수정하지 않으면 테스트가 실패할 수 있습니다. "테스트를 통과하도록 코드 수정"이라는 요청을 추가해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언대로 테스트 케이스를 포함한 프롬프트를 작성했더니, `None` 처리부터 타입 검증까지 완벽한 코드가 생성되었습니다. "이제야 안심하고 배포할 수 있겠어요!" 테스트 케이스를 프롬프트에 포함하면 신뢰성 있는 프로덕션 코드를 얻을 수 있습니다. 여러분도 오늘부터 테스트 요구사항을 꼭 명시해 보세요. **실전 팁** 💡 - AAA 패턴(Arrange-Act-Assert)을 명시하면 구조화된 테스트가 생성됩니다 - 모킹이 필요한 외부 의존성(DB, API)을 미리 명시하세요 - 성능이 중요한 함수는 "O(n) 복잡도 테스트 포함" 같은 요구사항을 추가하세요 --- ## 4. 실습_다양한_언어_코드_생성 김개발 씨는 이제 프롬프트 작성에 자신감이 붙었습니다. 오늘은 실제로 여러 언어로 같은 기능을 구현해보기로 했습니다. "사용자 데이터를 JSON 파일로 저장하고 읽는 함수를 파이썬, 자바스크립트, 자바로 각각 만들어볼게요." 박시니어 씨가 고개를 끄덕이며 말했습니다. "좋아요. 언어마다 어떻게 다르게 요청하는지 보여주세요." **다양한 언어 코드 생성 실습**은 동일한 기능을 여러 프로그래밍 언어로 구현하면서 언어별 특성을 반영한 프롬프트 작성법을 익히는 과정입니다. 같은 기능이라도 파이썬은 간결함과 타입 힌트를, 자바스크립트는 비동기 처리를, 자바는 타입 안정성과 예외 처리를 강조해야 합니다. 이 실습을 통해 각 언어의 강점을 최대한 활용하는 코드를 생성하는 방법을 배웁니다. 다음 코드를 살펴봅시다. ```python # Python 프롬프트 """ Python 3.10+ 전문가로서 사용자 데이터 JSON 저장/로드 함수 작성: - pathlib 사용 - 타입 힌트: TypedDict 또는 dataclass - 예외: FileNotFoundError, JSONDecodeError 처리 - pytest 테스트 포함 """ # JavaScript 프롬프트 """ Node.js 18+ 전문가로서 사용자 데이터 JSON 저장/로드 함수 작성: - fs.promises 사용 (async/await) - TypeScript 타입 정의 - 에러 핸들링: try-catch - Jest 테스트 포함 """ # Java 프롬프트 """ Java 17+ 전문가로서 사용자 데이터 JSON 저장/로드 메서드 작성: - record 클래스로 User 정의 - Jackson ObjectMapper 사용 - Optional 반환 - JUnit 5 테스트 포함 """ ``` 김개발 씨는 팀에서 멀티 언어 프로젝트를 맡게 되었습니다. 백엔드는 자바, 관리자 도구는 파이썬, 프론트엔드는 자바스크립트로 개발하는 마이크로서비스 아키텍처였습니다. "모든 서비스에서 사용자 데이터를 JSON으로 저장하고 읽어야 해요." 문제는 각 언어마다 어떻게 다르게 요청해야 할지 막막했습니다. 박시니어 씨가 조언했습니다. "같은 기능이라도 언어의 철학과 생태계를 반영해야 해요. 파이썬은 명시적이고 간결하게, 자바스크립트는 비동기 우선으로, 자바는 타입 안정성과 객체지향적으로 접근하세요." **다양한 언어로 코드 생성**할 때 핵심은 무엇일까요? 마치 같은 이야기를 다른 나라 말로 번역하는 것과 같습니다. 단순히 단어만 바꾸는 것이 아니라, 그 나라의 문화와 표현 방식을 고려해야 합니다. "I love you"를 한국어로 번역할 때 상황에 따라 "사랑해", "좋아해", "아껴" 등으로 다르게 표현하듯이, 코드도 언어의 특성을 살려야 자연스럽습니다. 언어별 차이를 무시하고 똑같은 프롬프트를 사용하면 어떻게 될까요? 개발자들은 "JSON 파일 읽고 쓰는 함수 만들어줘"라고 모든 언어에 동일하게 요청했습니다. 결과는 어색했습니다. 파이썬은 `open()` 함수로 파일을 열었지만 `pathlib`의 장점을 활용하지 못했습니다. 자바스크립트는 동기 API인 `fs.readFileSync`를 사용해서 Node.js의 비동기 장점을 살리지 못했습니다. 자바는 raw `FileReader`를 써서 Jackson 같은 표준 라이브러리를 무시했습니다. 바로 이런 문제를 해결하려면 **언어별 맞춤 프롬프트**가 필요합니다. 각 언어의 현대적인 API와 라이브러리를 명시하면 깔끔한 코드를 얻습니다. 또한 언어 커뮤니티의 베스트 프랙티스를 자동으로 반영합니다. 무엇보다 유지보수하기 쉽고 팀원들이 이해하기 쉬운 관용적 코드가 생성됩니다. 파이썬 프롬프트를 자세히 살펴보겠습니다. **pathlib**을 명시한 이유는 현대 파이썬의 파일 처리 표준이기 때문입니다. `Path` 객체는 OS에 독립적이고 체이닝이 가능해서 코드가 간결합니다. **타입 힌트**는 `TypedDict` 또는 `dataclass`로 사용자 데이터 구조를 명확히 정의합니다. 이렇게 하면 IDE 자동완성과 타입 체킹이 가능해집니다. 예외 처리는 파이썬 스타일로 `try-except`를 사용하되, 구체적인 예외(`JSONDecodeError`)를 잡도록 요청합니다. 자바스크립트 프롬프트는 접근이 다릅니다. **fs.promises**와 **async/await**을 강조한 이유는 Node.js가 비동기 I/O를 기반으로 하기 때문입니다. 파일 읽기는 시간이 걸리는 작업이므로 비동기로 처리해야 다른 요청을 블로킹하지 않습니다. **TypeScript 타입 정의**를 요청하면 인터페이스로 사용자 데이터를 정의해서 타입 안정성을 확보합니다. 에러 핸들링은 `try-catch`로 Promise rejection을 처리합니다. 자바 프롬프트는 또 다른 특징이 있습니다. **record 클래스**는 Java 17의 현대적 기능으로 불변 데이터를 간결하게 표현합니다. `record User(String name, int age)`만으로 getter, equals, hashCode를 자동 생성합니다. **Jackson ObjectMapper**는 자바 생태계의 사실상 표준 JSON 라이브러리입니다. **Optional** 반환은 null 안정성을 보장하는 자바의 모던 프랙티스입니다. 실제로 생성된 코드를 비교해보겠습니다. 파이썬 코드는 10줄 이내로 간결합니다. `json.load()`와 `json.dump()`가 핵심이고, `pathlib`의 `read_text()`로 한 줄에 파일을 읽습니다. 자바스크립트는 `async` 함수로 비동기 처리가 명확하고, `JSON.parse()`와 `JSON.stringify()`로 변환합니다. 자바는 타입이 명확하고 예외 처리가 체계적이며, `ObjectMapper`가 자동으로 JSON을 객체로 매핑합니다. 실무에서는 어떻게 활용할까요? 마이크로서비스마다 최적의 언어로 개발하는 것이 트렌드입니다. 데이터 처리는 파이썬, 고성능 API는 Go나 Rust, 엔터프라이즈 로직은 Java, 프론트엔드는 TypeScript로 나눕니다. 각 서비스에 맞는 프롬프트를 작성하면 언어 간 일관성을 유지하면서도 각 언어의 장점을 최대한 활용할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들은 한 언어에 익숙한 패턴을 다른 언어에 그대로 적용하려 합니다. 예를 들어 파이썬의 덕 타이핑 사고방식을 자바에 적용하면 타입 시스템을 제대로 활용하지 못합니다. 각 언어의 철학을 존중하고 그에 맞는 코드를 요청해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 언어별로 최적화된 프롬프트를 작성한 결과, 각 서비스가 자연스럽고 효율적인 코드로 구현되었습니다. "이제 각 언어의 강점이 뭔지 확실히 알겠어요!" 같은 기능도 언어에 맞게 다르게 요청하면 훨씬 좋은 코드를 얻습니다. 여러분도 멀티 언어 프로젝트에서 오늘 배운 전략을 활용해 보세요. **실전 팁** 💡 - 각 언어의 공식 문서에서 권장하는 라이브러리를 먼저 확인하세요 - 팀의 코딩 컨벤션이 있다면 프롬프트에 포함하세요 (예: Airbnb Style Guide) - 여러 언어로 같은 기능을 구현할 때는 API 인터페이스를 먼저 설계하세요 --- ## 5. 실습_버그_수정_프롬프트 김개발 씨는 프로덕션에서 발생한 버그 리포트를 받았습니다. "사용자 목록 조회가 간헐적으로 실패한다"는 내용이었습니다. 코드를 보니 복잡한 로직이라 어디가 문제인지 파악하기 어려웠습니다. "LLM에게 버그를 찾아달라고 해볼까요?" 박시니어 씨가 말했습니다. "좋은 생각이지만, 버그 수정 프롬프트는 일반 코드 생성과 다르게 접근해야 해요." **버그 수정 프롬프트**는 문제가 있는 코드를 LLM에게 제공하고 원인 분석과 해결 방법을 요청하는 특별한 프롬프트 패턴입니다. 단순히 "버그 고쳐줘"가 아니라, 증상, 재현 방법, 예상 동작, 실제 동작, 환경 정보를 구체적으로 제공해야 합니다. 효과적인 버그 수정 프롬프트는 문제 코드, 에러 메시지, 로그, 테스트 케이스를 모두 포함하며, LLM이 단계적으로 분석하고 여러 해결책을 제시하도록 유도합니다. 다음 코드를 살펴봅시다. ```python # 버그 수정 프롬프트 템플릿 """ 당신은 시니어 디버깅 전문가입니다. 다음 버그를 분석하고 수정해주세요. **증상**: 사용자 목록 조회 시 간헐적으로 빈 배열 반환 **환경**: - Python 3.10, FastAPI 0.104 - PostgreSQL 14 - 동시 사용자 100명 이상일 때 발생 **문제 코드**: async def get_users(): users = [] for user_id in user_ids: user = await db.get_user(user_id) users.append(user) return users **에러 로그**: (없음, 단순히 빈 배열 반환) **예상 동작**: 모든 사용자 반환 **실제 동작**: 간헐적으로 빈 배열 **요청사항**: ``` --- ## 4. 수정된 코드와 단위 테스트 김개발 씨는 또 다시 프로덕션 버그로 고민에 빠졌습니다. 이번에는 더 복잡했습니다. 로컬 환경에서는 완벽하게 작동하는데, 프로덕션에서만 간헐적으로 실패했습니다. 재현도 어려웠습니다. 100명 이상이 동시에 접속할 때만 문제가 발생했으니까요. "일단 LLM에게 물어봐야겠다" 싶어서 코드를 복사해서 "이 코드 버그 고쳐줘"라고 요청했습니다. 돌아온 답변은 일반적인 코드 개선 제안이었습니다. 변수명을 바꾸라거나, 주석을 추가하라는 내용이었습니다. 정작 버그 원인은 찾지 못했습니다. 박시니어 씨가 김개발 씨의 프롬프트를 보고 말했습니다. "버그 수정은 다르게 접근해야 해요. 의사가 환자를 진단하듯이, 증상과 상황을 자세히 설명해야 합니다." **버그 수정 프롬프트**는 왜 특별할까요? 마치 의사에게 "아파요"라고만 말하는 것과 "어제부터 오른쪽 배가 아프고, 식사 후에 더 심해지며, 열은 37.8도입니다"라고 말하는 차이와 같습니다. 후자가 정확한 진단을 받을 확률이 훨씬 높습니다. 버그도 마찬가지입니다. 상황을 구체적으로 설명할수록 정확한 해결책을 얻습니다. 막연한 버그 수정 요청은 어떤 문제가 있을까요? 개발자들은 코드만 던지고 "고쳐줘"라고 했습니다. LLM은 코드 자체의 문제점을 찾으려 했지만, 실제 버그는 환경이나 데이터에서 발생했습니다. 타임아웃, 레이스 컨디션, 메모리 누수 같은 런타임 이슈는 코드만 봐서는 발견하기 어렵습니다. 결국 시간만 낭비하고 버그는 해결되지 않았습니다. 바로 이런 문제를 해결하려면 **구조화된 버그 리포트**가 필요합니다. 증상, 환경, 재현 방법, 로그를 모두 제공하면 LLM이 문맥을 이해하고 정확한 분석을 합니다. 또한 여러 해결책을 요청하면 상황에 맞는 최선의 방법을 선택할 수 있습니다. 무엇보다 테스트 케이스를 함께 요청하면 수정 후 재발을 방지할 수 있습니다. 효과적인 버그 수정 프롬프트의 구조를 살펴보겠습니다. 첫 번째는 **증상 설명**입니다. "간헐적으로 빈 배열 반환"처럼 구체적으로 무엇이 잘못되었는지 기술합니다. "가끔 안 돼요"는 너무 애매합니다. 두 번째는 **환경 정보**입니다. 프로그래밍 언어 버전, 프레임워크, 데이터베이스, 동시 사용자 수 등 재현 조건을 명시합니다. "Python 3.10, FastAPI, PostgreSQL, 동시 사용자 100명 이상"처럼 구체적일수록 좋습니다. 세 번째는 **문제 코드**입니다. 버그가 있는 함수나 클래스를 제공합니다. 전체 파일을 다 주는 것보다 핵심 부분만 추출하는 것이 효과적입니다. 네 번째는 **에러 로그**입니다. 스택 트레이스, 에러 메시지, 애플리케이션 로그를 포함합니다. 에러가 없더라도 "에러 로그 없음, 단순히 빈 배열 반환"처럼 명시합니다. 다섯 번째는 **예상/실제 동작**입니다. 무엇을 기대했고 실제로는 어떻게 동작했는지 대비합니다. 이것이 LLM이 의도를 파악하는 핵심 정보입니다. 여섯 번째는 **요청사항**입니다. 단순 수정만이 아니라 "근본 원인 분석", "여러 해결 방법 제시", "테스트 케이스 작성"을 명시합니다. 위 프롬프트의 예시를 분석해보겠습니다. 코드를 보면 `async/await`을 사용하지만 순차적으로 처리하고 있습니다. 동시 사용자가 많을 때 데이터베이스 연결 풀이 고갈될 수 있습니다. LLM은 이를 분석하고, **병렬 처리**(asyncio.gather), **배치 쿼리**(단일 SELECT), **연결 풀 확장** 같은 여러 해결책을 제시할 것입니다. 실무에서는 어떻게 활용할까요? 프로덕션 장애가 발생하면 모니터링 도구에서 로그와 메트릭을 수집합니다. 이 정보를 버그 수정 프롬프트에 포함합니다. "CPU 사용률 90%, 데이터베이스 연결 풀 고갈, 응답 시간 30초 이상" 같은 메트릭은 LLM이 성능 문제를 분석하는 데 결정적입니다. 또한 Git blame으로 언제 코드가 변경되었는지, 어떤 커밋에서 버그가 유입되었는지 추적한 정보도 유용합니다. 하지만 주의할 점도 있습니다. 초보 개발자들은 민감한 정보를 프롬프트에 포함하는 실수를 합니다. API 키, 비밀번호, 사용자 개인정보가 로그에 있다면 반드시 마스킹해야 합니다. 또한 LLM의 답변을 맹신하면 안 됩니다. 제시된 해결책을 검증하고, 테스트 환경에서 충분히 확인한 후 프로덕션에 적용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨가 알려준 대로 구조화된 프롬프트를 작성했더니, LLM이 레이스 컨디션을 정확히 지적하고 `asyncio.gather`로 병렬 처리하는 해결책을 제시했습니다. 테스트 케이스까지 생성되어 수정 후 재발 방지도 가능했습니다. "이제 버그 수정도 체계적으로 할 수 있겠어요!" 버그 수정 프롬프트는 증상, 환경, 로그를 구체적으로 제공하고 여러 해결책을 요청하는 것이 핵심입니다. 여러분도 다음 버그를 만나면 오늘 배운 템플릿을 활용해 보세요. **실전 팁** 💡 - 재현 가능한 최소 코드(Minimal Reproducible Example)를 제공하면 분석이 빨라집니다 - 버그가 발생하는 조건과 발생하지 않는 조건을 대비해서 설명하세요 - LLM이 제시한 해결책은 반드시 코드 리뷰를 거쳐야 합니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: LLM,코드생성,프롬프트

언어: Python

태그: LLM, 프롬프트엔지니어링, 코드생성, 테스트케이스, 디버깅, LLM,코드생성,프롬프트

작성자: AI Generated

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

CodeDeck

코드 생성 프롬프트 완벽 가이드

목차

1. 코드 생성 프롬프트 패턴

2. 언어별 프롬프트 차이

3. 테스트 케이스 포함 전략

4. 커버리지: 100%

4. 실습 다양한 언어 코드 생성

5. 실습 버그 수정 프롬프트

4. 수정된 코드와 단위 테스트

댓글 (0)

함께 보면 좋은 카드 뉴스

ReAct 패턴 마스터 완벽 가이드

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

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

RAG 캐싱 전략 완벽 가이드

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