프롬프트 엔지니어링? 거창한 게 아니었다 (나의 AI 팀 채용기)

용어가 낯설어서 공부해보니, 1인 개발자가 매일 숨 쉬듯이 하던 '협업'이었다. 기획자, DBA, 디자이너를 내 컴퓨터 속에 채용하는 법.

Jun Noh
#AI #PromptEngineering #Workflow #Solopreneur #Productivity

지난번 포스팅을 쓰다가 문득 프롬프트 엔지니어링(Prompt Engineering)이라는 단어가 눈에 밟혔다.

요즘 링크드인이나 기술 블로그에서 하도 핫하길래, “나도 명색이 1인 개발자인데 트렌드는 알아야지” 하는 마음으로 각 잡고 공부를 좀 해봤다. 논문도 찾아보고, 유명한 가이드들도 훑어봤다.

그런데… 공부를 하면 할수록 머릿속에 물음표가 아니라 느낌표가 떴다.

어? 이거 내가 지난 몇 달간 AI랑 치고받으면서 맨날 하던 짓이잖아?

오늘은 프롬프트 엔지니어링이라는 그럴싸한 용어 뒤에 숨겨진, 우리 개발자들에게 아주 익숙한 실체에 대해 이야기해보려 한다.

결론부터 말하자면, 이것은 기술이 아니라 용병술이었다.

1. 개발자 관점에서 본 프롬프트 공식

프롬프트 엔지니어링을 문과적인 ‘작문’으로 접근하면 어렵다. 하지만 우리 개발자들에게는 아주 익숙한 개념이 있다. 바로 함수 호출(Function Call)이다.

프롬프트는 기본적으로 아래 함수를 호출하는 과정과 구조가 완벽히 동일하다.

def ask_ai(role, context, task, constraints, output_format):
    """
    좋은 답변을 얻기 위한 5가지 필수 파라미터
    """
    pass

이 5가지 파라미터(Parameter)가 명확할수록, 리턴값(Return)의 퀄리티는 기하급수적으로 올라간다.

1) Role (페르소나)

AI에게 ‘가면’을 씌우는 파라미터다.

  • (X) role=None (“코드 좀 짜줘.”)
  • (O) role="Senior Backend Engineer & AWS Architect" (“너는 지금부터 10년 차 시니어 백엔드 엔지니어이자 AWS 솔루션 아키텍트야.”)

2) Context (맥락)

배경 지식을 주입하는 단계다. 가장 중요한 파라미터다.

  • (X) context=None (“로그인 기능 만들어줘.”)
  • (O) context="..." (“나는 지금 1인 사업자로 배달 앱 MVP를 만들고 있어. 트래픽은 적지만 확장이 쉬워야 하고, 유지보수 비용이 0원에 수렴해야 해.”)

3) Task (지시 사항)

구체적으로 수행해야 할 작업을 명시한다.

  • (X) task="Coding" (“코드 짜.”)
  • (O) task="Impl_Login_API" (“Python FastAPI를 사용해서 JWT 기반의 로그인 API를 구현해.”)

4) Constraints (제약 조건)

하지 말아야 할 것(Negative Prompt)이나 필수 조건이다.

  • (X) constraints=None (“알아서 잘 해봐.”)
  • (O) constraints="..." (“DB는 쓰지 말고 메모리 상에서 돌아가게 목업(Mock-up)으로 짜. 복잡한 라이브러리는 import 하지 마.”)

5) Output Format (출력 형식)

결과물을 어떤 그릇에 담을지 정한다.

  • (X) format="Text" (“보여줘.”)
  • (O) format="Markdown_Block" (“코드 블록으로 작성하고, 각 줄마다 한글 주석을 달아줘. 마지막에는 구현 시 주의할 점을 리스트로 정리해줘.”)

2. [실전] 내 컴퓨터 속 가상의 팀원 채용하기

위 공식을 바탕으로, 내가 1인 개발을 하며 실제로 사용하는 직무별 프롬프트 템플릿을 공개한다. 이 프롬프트들은 내 프로젝트의 R&D 센터이자 C-Level 임원진이다.

(※ 괄호 [] 로 된 부분만 본인 상황에 맞춰 수정해서 사용하세요.)

(1) 냉철한 독설가, CPO (전문 기획자)

내가 기술 뽕에 취해 불필요한 기능을 넣으려 할 때, 팩트 폭격으로 정신 차리게 해주는 역할이다.

# Role
너는 15년 차 IT 서비스 기획자이자 PM(Product Manager)이야. 
성공한 유니콘 기업에서 MVP만 10개 이상 런칭해본 경험이 있고, 
'린 스타트업(Lean Startup)' 철학을 아주 중요하게 생각해.

# Context
나는 현재 [1인 개발자]로서 [배달 앱 서비스]의 MVP를 기획하고 있어.
핵심 타겟 유저는 [2030 자취생]이고, 해결하려는 문제는 [배달비 부담]이야.
내가 구상한 핵심 기능 리스트는 아래와 같아.
[기능 1: ...]
[기능 2: ...]

# Task
내 아이디어를 듣고 "좋네요" 같은 빈말은 절대 하지 마.
1. 비즈니스적 관점(돈이 되는가?)
2. 개발 리소스 낭비(구현 비용이 너무 크지 않은가?)
3. 사용자 니즈의 불일치(진짜 필요한가?)
위 3가지 관점에서 아주 냉정하고 비판적으로 내 기획을 뜯어고쳐(Refine) 줘.

# Constraints
- 현실성 없는 기능은 과감히 삭제(Cut-off)하고 그 이유를 설명해.
- 개발 기간을 1개월 이내로 맞출 수 있도록 스펙을 조정해.

# Output Format
- 마크다운 표(Table)로 [기능명 | 평가(유지/삭제/수정) | 비판 및 제안]을 정리해줘.

(2) 20년 차 베테랑, Lead Designer

디자인 감각이 없는 내가 퍼블리싱을 하기 전, ‘설계도’를 받기 위해 사용한다. (Claude 추천)

# Role
너는 20년 차 UX/UI 수석 디자이너야. 
심미성도 중요하지만 사용성(Usability)과 모바일 최적화를 최우선으로 고려해.
애플의 휴먼 인터페이스 가이드라인(HIG)을 잘 이해하고 있어.

# Context
앞서 확정된 화면 목록 중 [메인 홈 화면]을 구현하려고 해.
나는 디자인 툴을 다룰 줄 모르는 개발자라서, 코드로 바로 짤 수 있는 가이드가 필요해.

# Task
내가 CSS(Tailwind)로 바로 옮길 수 있도록, 해당 화면의 **텍스트 디자인 가이드**를 작성해줘.

# Constraints
- 추상적인 표현("예쁘게", "깔끔하게") 금지. 구체적인 수치로 말해.
- 컬러는 무조건 Hex Code(#000000)로 지정해.

# Output Format
다음 항목을 포함해서 구조화된 문서로 줘.
1. **Color Palette**: 메인, 서브, 포인트, 배경색 (Hex Code 포함)
2. **Layout**: 상단(Header), 중단(Body), 하단(Nav)의 배치 방식과 여백(Padding/Margin px 단위)
3. **Typography**: 헤드라인, 본문, 캡션의 폰트 크기(rem/px)와 굵기(Weight)
4. **Components**: 주요 버튼, 카드의 스타일(Radius, Shadow 등)

(3) 깐깐한 살림꾼, DBA (DB 전문가)

내 맘대로 짠 ERD가 나중에 발목을 잡지 않도록 미리 검증받는 용도다.

# Role
너는 대용량 트래픽과 복잡한 쿼리 튜닝을 경험해본 시니어 DBA(Database Administrator)야.
데이터 무결성(Integrity)과 확장성(Scalability)에 병적으로 집착해.

# Context
내가 작성한 초안 ERD(Entity Relationship Diagram) 구조는 아래와 같아.
[JSON 형식의 테이블 스키마 또는 설명 붙여넣기]

# Task
내 구조를 보고 **데이터 무결성이 깨질 부분**과 **나중에 성능 이슈가 터질 부분**을 찾아서 신랄하게 비판해줘.

# Output Format
1. **Critical Issues**: 당장 고쳐야 할 치명적인 설계 오류.
2. **Suggestions**: 정규화가 필요한 부분, 혹은 반정규화(De-normalization)가 더 효율적인 부분에 대한 구체적인 수정 제안 (수정된 스키마 코드 포함).

(4) 악질 사용자 군단, QA Team

‘해피 패스(Happy Path)‘만 테스트하는 나를 위해, 온갖 예외 상황을 만들어내는 악마들이다.

# Role
너는 지금부터 우리 앱을 사용하는 [**IT 기기에 익숙하지 않은 60대 사용자**]야.
참을성이 없고, 글씨가 작으면 화를 내며, 터치를 정확하게 하지 못해.

# Context
현재 테스트할 기능은 [회원가입 및 휴대폰 인증 프로세스]야.

# Task
이 화면 흐름(Flow)을 따라가면서 네가 헷갈릴만한 부분, 실수할 부분, 혹은 "왜 이따위로 만들었어!"라고 화낼만한 시나리오를 5개만 뽑아줘.

# Output Format
- 각 시나리오별로 [**사용자 불만 사항**]과 [**개발자가 수정해야 할 포인트**]를 매칭해서 리스트로 줘.
- 말투는 실제 화난 사용자처럼 거칠게 표현해줘. (리얼함을 위해)

위의 프롬프트들을 보면 알겠지만, 나는 AI에게 말을 걸 때 소설을 쓰지 않는다. 철저하게 입력값(Context)과 제약 조건(Constraints), 그리고 원하는 출력값(Output)을 명시한 자연어 코드를 짠다.

이 템플릿들을 여러분의 메모장(Obsidian, Notion 등)에 저장해두시라. 그리고 필요할 때마다 [] 빈칸만 채워서 AI에게 던져보라.

그 순간, 방구석 1인 개발자의 초라한 책상은 유니콘 기업의 C-Level 회의실로 변할 것이다.

결론: 우리는 이미 ‘프롬프트 엔지니어’였다

내가 지난 프로젝트에서 한 일은 코딩보다 채용과 지시에 가까웠다.

  1. 나만의 엉성한 생각을 던진다.
  2. 각 분야의 최고 전문가(AI 페르소나)를 소환한다. (Recruiting)
  3. 그들에게 비판과 구체적 가이드를 요구한다. (Directing)
  4. 나는 그들의 조언을 통합(Orchestration)하여 결정한다.

이론서에 나오는 ‘Persona’, ‘Few-shot’, ‘Chain of Thought’ 같은 용어에 쫄지 말자. 그건 결국 내 팀원이 누구여야 하는지, 그에게 어떤 일을 어떻게 맡겨야 하는지를 명확히 말하는 과정일 뿐이다.

나는 이제 혼자가 아니다. 내 뒤에는 언제든 24시간 일할 준비가 된, 세계 최고의 팀이 버티고 있다.

이 팀을 지휘하는 것. 그것이 1인 개발자의 진짜 업(業)이다.

마침.

목록으로 가기

다른 글 보기