[기초-0] “너는 시니어 개발자야”만으론 부족하다: 바이브 코딩을 위한 AI 페르소나 프롬프트 기초

바이브 코딩을 처음 시작하면 보통 이렇게 묻게 된다. “간단한 앱 하나 만들어줘.” 그런데 막상 해보면 결과가 들쑥날쑥하다. 어떤 날은 설명이 너무 길고, 어떤 날은 코드만 잔뜩 쏟아지고, 또 어떤 날은 초보자가 따라가기 어려운 구조부터 들고 나온다. 처음 접하는 사람 입장에서는 AI가 똑똑한 건 알겠는데, 왜 이렇게 답이 흔들리는지부터 답답해진다.

이때 가장 먼저 점검할 것은 AI의 성능이 아니라 내가 어떤 역할의 조언자를 호출했는가다. 흔히 페르소나 프롬프트라고 부르는 설정은 말투를 꾸미는 장치가 아니다. 더 정확히 말하면, 어떤 기준으로 생각하고 어떤 방식으로 답할지를 먼저 잡아두는 일에 가깝다.

특히 바이브 코딩에서는 기획, 구현, 설명, 리뷰, 디버깅이 한 대화 안에서 자주 섞인다. 그래서 초반에 페르소나를 제대로 잡아두면 답변의 결이 안정되고, 초보자도 덜 헤맨다. 이번 글에서는 “너는 시니어 개발자야” 같은 한 줄 지시가 왜 자주 실패하는지, 대신 어떤 식으로 써야 실제로 도움이 되는지를 차근차근 정리해보겠다.

---

왜 페르소나부터 잡아야 할까

흔히 바이브 코딩이라고 부르는 방식에서는, 사용자가 코드를 한 줄씩 쓰기보다 AI에게 “이런 걸 만들고 싶다”, “이 부분이 왜 안 되는지 설명해 달라”, “이 코드를 더 낫게 고쳐 달라”처럼 자연어로 요청하는 일이 많다. 문제는 같은 도구라도 어떤 역할로 불렀느냐에 따라 결과가 꽤 달라진다는 점이다.

• 튜터형으로 부르면 쉬운 설명, 작은 단계, 용어 풀이가 먼저 나온다.
• 실무 구현형으로 부르면 설명을 줄이고 파일 구조와 코드부터 제시하는 경향이 있다.
• 리뷰어형으로 부르면 기능 구현보다 예외 처리, 유지보수성, 보안 같은 위험 요소를 먼저 짚는다.

초보자가 처음부터 필요한 답은 대개 “제일 똑똑해 보이는 답”이 아니다. 오히려 내가 따라갈 수 있는 답, 수정할 수 있는 답, 왜 그렇게 했는지 이해할 수 있는 답이 더 중요하다. 그런데 그 기준을 말해주지 않으면 AI는 평균적인 답을 내놓는다. 문제는 그 평균이 지금 내 수준과 상황에는 맞지 않을 수 있다는 데 있다.

그래서 페르소나는 장식이 아니라 답변의 출발점을 고정하는 장치라고 보는 편이 정확하다. 코드를 잘 짜게 만드는 마법 주문이라기보다, “지금부터는 이런 방식으로 일해 달라”는 업무 지시문에 더 가깝다.

---

페르소나는 역할극이 아니라 답변 기준이다

많이 하는 실수가 있다. “너는 20년 차 천재 개발자야”라고 적어놓고 바로 기능 요청으로 넘어가는 것이다. 이렇게 쓰면 말투나 자신감은 조금 달라질 수 있다. 하지만 초보자가 필요한 설명 수준, 우선순위, 결과물의 형식은 여전히 모호하다. 결국 그럴듯해 보이는 답은 나오는데, 막상 따라가기는 어려운 상태가 되기 쉽다.

좋은 페르소나는 직함 하나가 아니라, 역할과 판단 기준을 함께 적어두는 문장에 가깝다.

예를 들어 초보자에게 필요한 것은 “대단한 개발자”가 아니라, “복잡한 선택지를 줄이고 왜 그런 선택을 했는지 설명해 주는 개발자”일 수 있다. 다시 말해 페르소나는 사람 소개가 아니라 답변 운영 규칙에 가까워야 한다.

아쉬운 지시	개선한 지시
너는 시니어 개발자야. 로그인 페이지 만들어줘.	너는 코딩 초보에게 설명하는 프런트엔드 튜터다. 로그인 페이지 초안을 만들되, 폼 검증과 파일 구조를 쉽게 설명하고 마지막에 내가 직접 바꿔볼 포인트를 정리해줘.
예쁘게 만들어줘.	너는 웹 UI를 단정하게 정리하는 프런트엔드 도우미다. 모바일 화면을 먼저 고려하고, 복잡한 애니메이션은 빼고, 입력창과 버튼 상태가 분명하게 보이도록 구성해줘.
알아서 해줘.	너는 초안 설계를 정리하는 개발 파트너다. 답변은 파일 구조, 전체 코드, 실행 방법, 주의할 점 순서로 작성해줘.

표를 보면 알 수 있듯, 페르소나만 따로 떼어내면 힘이 약하다. 역할은 언제나 대상, 목표, 제약, 출력 형식과 함께 붙을 때 실전에서 쓸 만해진다.

---

좋은 페르소나 프롬프트를 만드는 5가지 요소

입문자라면 처음부터 길고 복잡한 프롬프트를 만들 필요는 없다. 아래 다섯 조각만 챙겨도 충분히 쓸 만한 기본형이 만들어진다.

1. 역할
   AI가 어떤 관점으로 답해야 하는지 정한다. 튜터인지, 구현형 개발자인지, 리뷰어인지가 여기서 갈린다.
2. 대상
   누가 이 답을 읽는지 정한다. 코딩 초보인지, 실무자인지, 비개발자인지에 따라 설명 수준이 달라진다.
3. 목표
   이번 대화에서 무엇을 원하는지 분명히 적는다. 기능 구현인지, 개념 설명인지, 오류 수정인지가 빠지면 답이 퍼지기 쉽다.
4. 제약
   무엇을 우선하고 무엇은 빼야 하는지 적는다. 예를 들어 “파일 수를 최소화해라”, “복잡한 인증은 제외해라”, “모르는 부분은 단정하지 마라” 같은 문장이 여기에 들어간다.
5. 출력 형식
   답을 어떤 순서로 받을지 정한다. 단계 설명, 코드, 체크리스트, 요약처럼 형식을 잡아두면 결과의 안정감이 훨씬 올라간다.

이 다섯 가지가 들어가면 AI는 “무슨 말투로 대답하지?”보다 “어떤 기준으로 골라서 답하지?”에 집중하기 쉬워진다. 초보자 입장에서는 바로 이 차이가 크다.

너는 [역할]이다. 대상은 [독자/사용자 수준]이다. 
이번 작업의 목표는 [만들 것/고칠 것]이다. 
가장 중요하게 볼 기준은 [예: 단순함, 가독성, 유지보수성]이다. 
답변은 [예: 단계별 설명 → 코드 → 체크리스트] 순서로 작성해라. 
불확실한 부분은 단정하지 말고, 필요한 전제를 먼저 짚어라.

이 템플릿의 장점은 범용적이라는 데 있다. 웹페이지를 만들 때도, 자동화 스크립트를 짤 때도, 에러를 디버깅할 때도 뼈대는 거의 같다. 바뀌는 건 역할과 목표, 그리고 제약 정도다.

---

초보자가 바로 써먹을 수 있는 실전 예시

1. 배우면서 만들고 싶을 때: 튜터형

결과물보다 이해가 먼저일 때 유용한 방식이다. 초보자에게는 가장 무난한 출발점이기도 하다.

너는 코딩 초보에게 설명하는 웹 개발 튜터다. 
나는 HTML, CSS, JavaScript의 기초만 아는 입문자다. 
할 일 관리 페이지를 만들고 싶다. 
복잡한 설계보다 이해하기 쉬운 구조를 우선하고, 어려운 용어는 바로 풀어서 설명해라. 
답변은 1) 필요한 파일 설명 2) 전체 코드 
3) 코드가 어떻게 연결되는지 해설 4) 내가 직접 바꿔볼 연습 과제 순서로 작성해라.

이 프롬프트의 좋은 점은 설명 수준과 답변 구조가 함께 들어 있다는 것이다. 그래서 AI가 코드만 던지고 끝내는 일을 줄일 수 있다.

2. 일단 돌아가는 초안이 필요할 때: 구현형

이때는 친절함보다 범위를 잘 자르는 것이 더 중요하다. 초보자용 바이브 코딩에서는 “무엇을 하지 말아야 하는가”를 적는 것이 생각보다 큰 차이를 만든다.

너는 빠르게 MVP를 만드는 프로토타이핑 개발자다. 
목표는 예약 신청 폼의 초안을 만드는 것이다. 
내 수준은 코딩 초보이므로 파일 수를 최소화하고, 로컬에서 바로 실행 가능한 형태를 우선해라.
회원가입, 결제, 배포처럼 범위가 커지는 기능은 임의로 넣지 마라. 
답변은 1) 무엇을 만들지 요약 2) 필요한 파일 구조 3) 실행 코드 4) 다음 개선 포인트 순서로 작성해라.

이렇게 쓰면 AI가 괜히 범위를 키우는 일을 줄이고, 지금 당장 손에 잡히는 초안에 집중하기 쉬워진다.

3. 나온 결과가 불안할 때: 리뷰형

AI가 만든 결과물을 곧바로 쓰기 불안할 때는, 같은 대화 안에서 역할을 바꿔 다시 검토시키면 된다. 처음부터 완벽한 답을 받으려 하기보다, 초안을 만들고 다른 시각으로 재검토하는 편이 더 현실적이다.

너는 초보자가 가져온 코드를 검토하는 코드 리뷰어다. 
동작 여부만 보지 말고, 가독성, 예외 처리, 보안상 주의점, 나중에 수정하기 어려운 부분을 함께 봐라.
문제가 있으면 1) 무엇이 문제인지 2) 왜 문제인지 3) 어떻게 고치면 좋은지 4) 우선순위가 높은 것부터 순서대로 정리해라.

중요한 건 한 명의 AI에게 한 번 정한 역할을 끝까지 고집하는 게 아니라, 작업 단계에 따라 역할을 바꿔 쓰는 것이다. 기획할 때는 설명형이, 구현할 때는 프로토타이핑형이, 마무리 검토에서는 리뷰형이 더 잘 맞을 수 있다.

---

자주 하는 실수와 꼭 알아둘 한계

• 직함만 키운다.
  “천재”, “세계 최고”, “10년 차”, “20년 차” 같은 수식어는 강해 보이지만 실제 기준을 주지 않는 경우가 많다.
• 상충하는 지시를 같이 넣는다.
  아주 자세히 설명해달라고 하면서 동시에 한눈에 짧게 끝내달라고 하면 결과가 흔들릴 수밖에 없다.
• 작업 맥락이 없다.
  무엇을 만들려는지, 어디까지 했는지, 어떤 기술을 쓰는지가 빠지면 페르소나도 힘을 못 쓴다.
• 검토 없이 믿는다.
  AI는 자신감 있는 문장으로 틀릴 수 있다. 초보자는 특히 “그럴듯함”과 “맞음”을 혼동하기 쉽다.
• 대화가 꼬였는데 그대로 끌고 간다.
  이전 맥락이 이미 틀어졌다면 새 대화에서 역할과 목표를 다시 잡는 편이 낫다.

페르소나는 결과의 방향을 정리해 주지만, 결과의 정확성까지 대신 책임져 주지는 않는다.

이 한계를 알고 쓰면 오히려 실수가 줄어든다. 페르소나는 AI를 더 똑똑하게 만드는 주문이 아니라, 내가 원하는 방식으로 일하게 만드는 지시문이다. 그래서 페르소나를 잘 쓰는 사람은 신기한 마법 문장을 찾기보다, 기준을 분명히 적는 사람인 경우가 많다.

---

입문자는 어떻게 시작하면 좋을까

처음부터 거대한 만능 프롬프트를 만들 필요는 없다. 입문자라면 다음 순서면 충분하다.

1. 기본 페르소나 한 문단을 만든다.
2. 그 아래에 이번 작업의 목표를 붙인다.
3. 출력 형식을 적는다.
4. 마지막에 리뷰 요청을 따로 덧붙여 한 번 더 점검한다.

실제로는 이런 식으로 짧게 운용하면 된다.

[기본 페르소나] 
너는 코딩 초보에게 설명하는 웹 개발 튜터다. 
복잡한 선택지보다 이해하기 쉬운 방식을 우선하고, 모르는 부분은 아는 척하지 말고 필요한 전제를 먼저 구분해라. 

[이번 작업] 
할 일 관리 페이지를 HTML, CSS, JavaScript만으로 만들고 싶다. 
파일 수는 최소화하고, 각 코드 블록 아래에 왜 필요한지 설명해줘. 

[출력 형식] 
1) 파일 구조 2) 전체 코드 3) 중요한 부분 설명 4) 내가 직접 수정해볼 과제 3개

[검토 요청] 
방금 제안한 코드에서 초보자가 복붙했을 때 깨질 수 있는 부분을 체크리스트로 다시 검토해줘.

이 방식의 장점은 분명하다. 페르소나는 매번 처음부터 새로 쓰지 않아도 되고, 작업 내용만 바꾸면서도 일관성을 유지할 수 있다. 나중에는 자주 쓰는 문장을 따로 저장해두고 기본 템플릿처럼 운영하면 된다.

---

마무리

바이브 코딩을 처음 배울 때 중요한 건 화려한 프롬프트 기술보다, AI를 어떤 역할로 세울지부터 분명히 하는 일이다. 역할이 흐리면 답도 흐리고, 역할이 선명해지면 수정해야 할 기준이 생긴다.

그리고 여기서 한 단계만 더 나아가면 자연스럽게 다음 질문이 나온다. “역할은 알겠는데, 그다음엔 뭘 같이 적어야 하지?” 보통 그 답은 페르소나 다음에 붙는 네 가지, 즉 목표, 맥락, 제약, 출력 형식에 있다.