© 2025 Shelled Nuts Blog. All rights reserved.
Capture your moments quietly and securely
Learn discreet, professional methods to capture company dinners and client entertainment—preserve receipts, seating, and moments for expenses and follow-up without disrupting the occasion.
Shelled AI (Global)
Discover how llama.cpp enables fast, efficient LLM inference on CPUs without GPUs, unlocking powerful local AI with optimization and security benefits.
Shelled AI (Global)
Learn how to set up and configure a VPN server using OpenVPN or WireGuard in a practical lab environment with step-by-step guidance for beginners.
Shelled AI (Global)
Hey, welcome back! 지난번 포스트 "Learn prompt engineering techniques specific to coding AI" 어떠셨나요? 댓글에서 Prompt Evaluation과 Iteration for Coding Tasks에 대해 궁금해하신 분들이 정말 많았죠. 그래서 오늘은 이 주제를 제대로 파헤쳐보려고 해요.
혹시 이런 경험 있으신가요? 완벽하다고 생각한 프롬프트를 입력했는데, AI 코딩 어시스턴트가 내놓은 결과물이… 음, 뭔가 엉뚱한 코드였던 적. 저도 정말 많이 겪었어요. 솔직히 말하면, 셀 수 없이요! 사실 좋은 프롬프트를 쓰는 게 전부가 아니에요. 진짜 마법은, 결과를 평가하고, 반복해서 다듬고, 그 과정을 통해 프롬프트를 발전시킬 때 일어나죠.
왜 이게 중요할까요? AI 기반 코딩 툴이 점점 우리 개발 워크플로의 중심이 되면서, 그 효과는 우리가 얼마나 의도를 명확하게 전달하느냐에 달려 있어요. 살짝 애매한 프롬프트 하나가 버그 없는 솔루션과 몇 시간짜리 디버깅의 차이를 만들 수 있거든요. 테크 리드, AI 개발자, 또는 코딩 AI를 개발 스택에 통합하는 모든 분들께, 프롬프트 평가와 반복은 “있으면 좋은 것”이 아니라, 신뢰할 수 있고 효율적이며 유지보수 가능한 소프트웨어를 만드는 데 필수입니다.
오늘 포스트에서는 이런 내용을 다룹니다:
가장 중요한 건, 처음부터 완벽할 필요 없다는 거예요. 프롬프트 엔지니어링은 계속되는 과정이고, 매번의 반복이 이 새로운 소프트웨어 개발 세계를 마스터하는 한 걸음이에요. 저도 아직 배우는 중이고, 실험하고, 실수하고, 질문하는 게 완전히 괜찮아요.
경험 많은 AI 개발자든, 프롬프트 엔지니어든, 아니면 그냥 코딩 툴을 더 잘 써보고 싶은 개발자든—커피 한 잔 들고, 프롬프트 평가와 반복의 핵심을 함께 파헤쳐봐요. 이 글 끝날 때쯤이면, “애매한” AI 코드도 믿고 쓸 만한 결과로 바꿀 수 있는 실전 방법을 손에 넣으실 거예요. 그럼 시작해볼까요?
자, 본격적으로 시작해볼게요. AI로 코딩할 때 모든 것은 프롬프트에서 시작합니다. “write a function to sort a list” 같은 걸 입력해본 적 있으시죠? 가끔은 딱 원하는 코드가 나오지만, 또 어떤 때는 “어? 왜 자바스크립트로 버블소트를 썼지? 난 파이썬에 퀵소트가 필요했는데…” 이런 생각이 들 때도 있죠. 저도 처음엔 헷갈렸어요. 프롬프트가 AI의 설계도라는 걸 그때 깨달았거든요.
잠깐 정리하자면, 프롬프트는 AI에게 주는 지침이고, 이게 얼마나 명확하고 구체적인지에 따라 결과물이 완전히 달라져요. 예를 들어 “Write a Python function using quicksort to sort a list of integers in ascending order”처럼 명확하게 쓰면, 훨씬 더 정확한 코드가 나옵니다. 반대로 애매하게 쓰면, 엉뚱한 언어로, 혹은 불완전한 코드가 나올 수 있어요. 저도 처음에 “sort a list”라고만 썼다가, 엉뚱한 언어로 코드가 나와서 당황했던 기억이 있네요. 여러분도 이런 경험 있으시죠?
그런데, 결과물이 마음에 안 들면 어떻게 해야 할까요? 여기서 프롬프트 평가와 반복이 등장합니다. 그냥 포기하지 말고, 프롬프트를 조금씩 수정해보세요. 입력/출력 예시를 추가하거나, 에러 핸들링을 명시하거나, 코딩 스타일을 지정하는 식으로요. 저도 복잡한 API 연동 코드를 만들 때, 여러 번 프롬프트를 바꿔가며 원하는 결과를 얻었어요. 그때 진짜 속이 다 시원하더라고요!
실전 팁:
AI가 처음 내놓은 코드를 꼼꼼히 확인하세요. “내 요구사항을 다 충족했나?” 스스로 물어보고, 부족하다면 프롬프트를 수정하세요. 이 반복 사이클—평가, 수정, 재시도—이게 진짜 협업의 시작입니다. 연습할수록 AI를 더 잘 다룰 수 있게 돼요. 실리콘밸리든, 서울이든, 상파울루든, 어디서든 마찬가지죠.
이제, 프롬프트가 얼마나 “좋은지” 실제로 측정하는 방법을 살펴볼게요. 그냥 “느낌상 괜찮다”는 안 되죠. 숫자가 필요해요. 저도 처음엔 “음, 괜찮아 보이는데?” 하다가, 실제로 테스트해보니 엉뚱한 결과가 나와서 당황한 적이 많았어요. 그래서 정량적 평가가 중요합니다.
대부분 처음 확인하는 건, 생성된 코드가 실제로 “제대로” 동작하는지죠. 즉, 정확성과 올바름입니다. 실제로는 테스트 케이스를 돌려보는 거예요. 다 통과하면 OK! 아니면… 다시 프롬프트 수정!
예시: Pytest로 자동 테스트하기
# add 함수 프롬프트 예시
def add(a, b):
return a + b
def test_add():
assert add(2, 3) == 5
assert add(-1, 1) == 0
assert add(0, 0) == 0
pytest로 돌려서 모두 통과하면 성공! 저도 예전엔 자동화 안 하고 수동으로 체크했다가, 엣지 케이스 놓쳐서 3시간 날린 적 있어요… 자동화는 진짜 필수입니다. 글로벌 팀에서는 언어별로 Jest, JUnit 등으로 표준화하면 더 좋아요.
생성된 코드가 “정답” 코드와 얼마나 비슷한지 보고 싶을 때 BLEU 점수를 씁니다. 원래 번역 품질 평가용이지만, 요즘은 코드 비교에도 쓰여요.
간단 예시:
from nltk.translate.bleu_score import sentence_bleu
reference = [['def', 'add', '(', 'a', ',', 'b', ')', ':', 'return', 'a', '+', 'b']]
candidate = ['def', 'add', '(', 'a', ',', 'b', ')', ':', 'return', 'a', '+', 'b']
score = sentence_bleu(reference, candidate)
print("BLEU score:", score)
근데 BLEU 점수만 믿으면 안 돼요! 저도 처음엔 “점수 높으니 완벽하겠지?” 했다가, 실제론 테스트 통과 못하는 코드가 나와서 좌절했죠. BLEU는 참고용, 실제 테스트는 필수입니다.
Mocha, Pytest, Jasmine 등 자동화 테스트 툴은 정말 구세주예요. 출력 검증, 엣지 케이스, 성능까지 한 번에 체크할 수 있죠. 특히 CI/CD 파이프라인에 통합하면, 팀원 모두가 프롬프트 품질 변화를 실시간으로 볼 수 있어요. 저도 이걸 도입한 뒤로 버그가 확 줄었어요.
잠깐, 여기서 숨 좀 돌리고 갈게요.
자동화 테스트(정확성) + BLEU 점수(유사성) 조합이 프롬프트 품질을 입체적으로 평가하는 데 최고입니다. 숫자가 좋아도, 항상 결과를 직접 확인하세요—실수는 언제든 나올 수 있거든요. 저도 아직 배우는 중이지만, 이 방법들 덕분에 진짜 많이 구원받았어요!
숫자만으로는 다 설명이 안 되는 부분, 있죠? 코드가 “맞긴 한데, 도저히 못 읽겠다” 싶은 경우요. 이럴 때는 사람의 눈, 그리고 실제 사용자 피드백이 정말 중요해요.
자동화 툴이 못 잡는 미묘한 부분, 전문가 리뷰어가 캐치해줍니다. 예전에 AI가 만든 파이썬 함수가 테스트는 다 통과했는데, 변수명이 너무 난해해서 팀원들이 다들 “이게 뭐야…” 했던 적이 있어요. 한 전문가가 리뷰해주면서, 변수명뿐 아니라 정적 분석기가 못 잡은 보안 취약점까지 발견! 그때 정말 놀랐어요.
실제 사용자(개발자, 엔드유저) 피드백은 보물창고예요. 브라질 시장에 코드 생성 프롬프트를 적용했을 때, “코드는 잘 나오는데 주석이 영어라서 불편하다”는 피드백이 있었어요. 프롬프트를 포르투갈어 주석으로 바꿨더니, 만족도가 확 올라갔죠. 의외로 이런 사소한 부분이 현장에선 엄청 중요하더라고요.
정리하자면,
저도 처음엔 숫자만 믿다가, 사용자 불만이 쏟아진 뒤에야 깨달았어요. 코드는 기계만 보는 게 아니라, 사람이 읽고 쓰는 거니까요. 실수도 괜찮으니, 피드백을 적극적으로 받아들이세요!
이제 반복적인 프롬프트 개선, 즉 Iterative Prompt Refinement Techniques에 대해 알아볼게요.
처음엔 저도 “그냥 프롬프트 조금 바꿔보자” 식으로 접근했다가, 결과가 더 엉망이 된 적이 많았어요. 실패 케이스를 꼼꼼히 분석하는 게 훨씬 효과적이더라고요.
예를 들어,
Write a Python function that returns the sum of even numbers in a list.
이렇게 요청했는데,
def sum_even_numbers(numbers):
return sum(numbers)
이렇게 나오면, “even numbers” 조건이 빠졌죠!
실전 팁:
뭐가 잘못됐는지 리스트업하세요. 지시가 모호했나? 제약조건이 빠졌나? 저도 “어떻게 짝수만 더해야 하는지”를 명확히 안 써서 이런 실수를 했어요. 그래서 프롬프트를 이렇게 바꿨죠:
Write a Python function that takes a list of integers and returns the sum of only the even numbers in that list.
그랬더니,
def sum_even_numbers(numbers):
return sum(num for num in numbers if num % 2 == 0)
이제야 제대로 된 결과!
변경이 실제로 개선됐는지 확인하려면, 다양한 테스트 케이스로 비교해보세요.
test_cases = [
[1,2,3,4], # 혼합
[2,4,6], # 모두 짝수
[1,3,5], # 모두 홀수
[], # 빈 리스트
]
for case in test_cases:
print(sum_even_numbers(case))
처음 함수는 “모두 홀수”나 “빈 리스트”에서 실패했지만, 개선된 버전은 모두 통과! 이런 작은 승리가 쌓이면, 진짜 뿌듯해요.
실전 팁:
테스트 자동화하세요. 수동으로 하다가는 실수하기 쉽고, 시간도 엄청 걸려요.
저도 “이 케이스만 통과하면 됐다!” 하다가, 다른 케이스에서 다 깨지는 경험을 했어요. 이게 바로 오버피팅이죠.
도움이 되는 방법:
일본, 유럽 코딩 대회에서 나온 엣지 케이스를 추가하니까, 프롬프트가 훨씬 튼튼해졌어요. 글로벌 다양성, 정말 중요합니다!
휴, 복잡하죠? 천천히 다시 볼게요.
반복적인 프롬프트 개선은 실수 분석, 체계적인 비교, 오버피팅 방지의 조합입니다. 저도 아직 완벽하지 않지만, 이 과정을 거치면서 훨씬 더 신뢰할 수 있는 코드를 얻고 있어요. 여러분도 실수 두려워 말고, 계속 시도해보세요!
이제, 도메인 특화 제약조건과 예시를 프롬프트에 녹여내는 방법을 알아볼게요. “코드는 맞는데, 우리 프로젝트엔 안 맞네?” 이런 경험, 다들 있으시죠? 저도 진짜 많이 겪었어요.
예를 들어, 금융 앱에서 “generate code to validate transactions”라고만 하면,
def validate_transaction(amount):
if amount > 0:
return True
return False
이렇게 단순한 코드가 나올 수 있어요. 근데 실제로는 사기 방지, 통화 체크, 규제 준수 등 훨씬 복잡한 조건이 필요하죠. 이럴 때, 도메인 제약조건을 프롬프트에 명확히 써주는 게 핵심입니다.
저도 “트랜잭션 한도, 사용자 권한 체크” 같은 걸 빼먹었다가, 완전 망한 적이 있어요. 그래서 이렇게 바꿔봤죠:
Write a Python function to validate a financial transaction.
Constraints:
- Only allow amounts between $1 and $10,000.
- Ensure the user has ‘active’ status.
- Transactions above $5,000 require a manager’s approval.
Example:
validate_transaction(500, 'active', False) → True
validate_transaction(6000, 'active', False) → False # Manager approval needed
이제 AI가 훨씬 현실적인 코드를 내놓더라고요.
def validate_transaction(amount, user_status, manager_approval):
if user_status != 'active':
return False
if not (1 <= amount <= 10000):
return False
if amount > 5000 and not manager_approval:
return False
return True
임베디드 시스템 프로젝트에서 “메모리 최적화, 동적 할당 금지” 같은 제약을 명확히 쓰니까, AI가 훨씬 더 적합한 코드를 내놓더라고요. 그 전엔 malloc()이 계속 나와서 진짜 골치 아팠는데, 한 줄 추가로 해결!
잠깐, 여기서 정리하고 넘어갈게요.
도메인 제약과 예시를 프롬프트에 명확히 넣으면, 디버깅 시간도 줄고, 원하는 결과에 훨씬 빨리 도달할 수 있어요. 다음엔 꼭 시도해보세요!
실제 현업에서 프롬프트 평가와 반복이 어떻게 쓰이는지, 몇 가지 사례로 살펴볼게요.
한 스타트업에서, AI가 자동으로 코드 리뷰 코멘트를 생성하도록 프롬프트를 설계했어요. 처음엔 “코드 스타일 지적”만 했는데, 반복적으로 “보안 취약점도 함께 체크해줘”라고 프롬프트를 개선하니, 실제 리뷰 품질이 크게 향상됐습니다.
글로벌 SaaS 기업에서는, “주석을 현지 언어로 달아줘”라는 프롬프트 반복을 통해, 각국 개발자들이 더 빠르게 코드를 이해할 수 있게 만들었어요. 사용자 피드백을 적극 반영한 결과죠.
테스트 자동화 팀에서는, “특정 프레임워크(예: Pytest, Jest) 스타일로 테스트 코드를 생성해줘”라고 프롬프트를 반복 개선해, 테스트 커버리지를 30% 이상 높였다고 해요.
아쉽게도, 프롬프트 평가와 반복에도 한계가 있어요.
저도 한 번은, 프롬프트를 10번 넘게 바꿨는데, 결국 원점으로 돌아온 적이 있어요. 그때 느꼈죠—“적당한 선에서 멈추는 것도 기술이다!”
정리해볼게요.
프롬프트 평가와 반복은, 코딩 AI를 제대로 활용하려면 반드시 익혀야 할 핵심 역량입니다. 정량적 지표와 정성적 피드백을 함께 활용하면, 어떤 프롬프트가 효과적인지 체계적으로 파악할 수 있어요. 도메인 제약과 실전 예시를 적극적으로 녹이면, 결과물이 훨씬 신뢰할 만해집니다.
실전 팁 한 번 더!
프롬프트 엔지니어링의 여정은 끝이 아니라, 계속되는 성장의 과정이에요. 매번의 반복이 더 나은 결과로 이어집니다. 실수해도 괜찮으니, 호기심과 인내심을 갖고, 작은 개선 하나하나를 즐겨보세요. 여러분이 바로 AI 기반 개발의 미래를 만들어가는 주인공입니다!
Write a Python function that returns the sum of even numbers in a list.
def sum_even_numbers(numbers):
return sum(numbers)
Write a Python function that takes a list of integers and returns the sum of only the even numbers in that list.
def sum_even_numbers(numbers):
return sum(num for num in numbers if num % 2 == 0)
Write a Python function with comments that takes a list of integers and returns the sum of only the even numbers in that list. Handle empty lists gracefully.
def sum_even_numbers(numbers):
"""
Returns the sum of even numbers in the given list.
If the list is empty, returns 0.
"""
return sum(num for num in numbers if num % 2 == 0)
효과적인 프롬프트로 LLM이 정확하고 효율적인 코드를 생성하도록 유도하는 방법.
AI가 생성한 코드의 정확성, 효율성, 가독성, 유지보수성 등을 체계적으로 평가하는 방법.
프롬프트 반복 과정에 사람의 피드백을 통합해 AI 코드 품질을 높이는 전략.
AI가 만든 코드에서 자주 발생하는 오류를 식별, 분류, 해결하는 방법.
여러분도 “완벽한 프롬프트”를 향해 한 걸음씩 나아가고 계신 거예요. 실패해도 괜찮아요. 저도 아직 배우는 중이니까요! 궁금한 점이나 공유하고 싶은 경험이 있다면 언제든 댓글로 남겨주세요. 다음 포스트에서 또 만나요!
AI editor introducing IT services and the latest technology trends.