1. 왜 월급은 들어오는데 돈은 남지 않을까

직장인이 되고 처음 월급을 받으면 이상한 자신감이 생긴다. 학생 때와는 다르게 매달 정해진 돈이 들어오고, 이제는 내 힘으로 생활할 수 있다는 감각도 생긴다. 그래서 자연스럽게 소비의 범위도 넓어진다. 출근길 커피를 조금 더 편하게 사 마시고, 점심은 대충 때우기보다 제대로 먹고 싶어진다. 주말에는 평일의 스트레스를 풀기 위해 쇼핑을 하거나 배달 음식을 시키기도 한다. 구독 서비스 몇 개쯤은 큰 부담이 아니라고 느끼고, 운동이나 자기계발에도 돈을 써야 한다는 생각이 든다.

문제는 여기서부터 시작된다. 월급은 분명 들어오는데, 이상하게 통장에 남는 돈은 없다. 분명 사치한다고 느끼지는 않는데도 잔고는 늘지 않고, 카드값이 빠져나가고 나면 이번 달도 또 비슷하게 지나갔다는 생각이 든다. 그래서 많은 사람이 이렇게 말한다.

“내가 너무 많이 쓰는 건가?”
“이제부터는 진짜 아껴야겠다.”

그런데 동기들의 초년생시절 자산관리를 옆에서 지켜보면, 돈이 모이지 않는 이유는 단순히 소비를 많이 해서가 아닌 경우가 많다. 오히려 문제는 더 근본적인 데 있다. 소비의 양이 아니라 소비의 구조다. 같은 월급을 받아도 어떤 사람은 1년 만에 종잣돈을 만들고, 어떤 사람은 늘 월급날만 기다리며 산다. 그 차이는 의외로 “얼마나 검소한가”보다는 “지출을 어떻게 분류하고 통제하는가”에서 갈린다.

이 질문은 반은 맞고, 반은 틀리다.
문제는 소비의 ‘양’이 아니라, 소비의 ‘구조’에 있다.

2. 기업은 비용을 이렇게 관리한다

나는 이 지점을 기업의 비용 관리 방식으로 설명하면 훨씬 이해가 쉬워진다고 생각한다.
회사는 거의 “이번 달은 그냥 좀 아껴보자” 같은 식으로 말하지 않는다. 다만, 아껴야 하는구나 느끼게 만든다.

먼저, 비용을 구조적으로 나눈다. 제품을 만들기 위해 반드시 필요한 비용이 있고, 사람을 유지하고 성장시키는 데 들어가는 비용이 있고, 운영 편의를 위해 들어가는 각종 비용이 있다. 그리고 이 비용들을 다시, 매달 거의 고정적으로 나가는 돈과 상황에 따라 달라지는 돈으로 구분한다. 그래야 어디서 돈이 새는지, 어떤 비용은 줄이면 안 되고 어떤 비용은 바로 손봐야 하는지 판단할 수 있기 때문이다.

개인의 소비도 사실 다르지 않다. 다만 우리는 대부분 그걸 구조로 보지 않는다. 보통 가계부를 쓴다고 해도 식비, 교통비, 쇼핑, 카페, 통신비처럼 항목을 쭉 나열하는 데 그친다. 물론 이것도 필요하다. 하지만 이 방식에는 결정적인 한계가 있다. 지출의 성격이 보이지 않는다.
같은 식비라도 생존을 위한 기본 비용인지, 스트레스 때문에 늘어난 변동비인지가 다르고, 같은 구독료라도 내 삶에 꼭 필요한 인프라인지, 무심코 방치된 새는 돈인지가 다르다. 항목만 봐서는 통제의 우선순위가 드러나지 않는다.

그래서 직장인 초년생의 소비는 조금 다르게 봐야 한다. 나는 개인의 지출을 기업의 비용 구조처럼 두 축으로 나누는 방식이 가장 실용적이라고 본다. 첫 번째 축은 비용의 성격이다. 자재비, 인건비, 경비라는 기업의 개념을 개인에게 가져오면 각각 이렇게 바꿔볼 수 있다.

자재비는 살아가기 위해 반드시 필요한 비용이다. 주거비, 기본 식비, 출퇴근 교통비처럼 생활의 바닥을 이루는 돈이다.
인건비는 나를 유지하고 성장시키는 비용이다. 운동, 건강관리, 공부, 강의, 책, 자격증, 커리어를 위한 투자 등이 여기에 들어간다.
경비는 생활의 편의와 만족을 위해 쓰는 돈이다. 카페, 배달, 쇼핑, 각종 구독, 취미, 여가가 대표적이다.

두 번째 축은 지출 방식이다. 고정비와 변동비다. 고정비는 매달 거의 자동으로 같은 규모로 빠져나가는 돈이고, 변동비는 생활 습관과 감정, 일정에 따라 달라지는 돈이다.

이 두 가지 축을 겹치면, 개인의 소비는 여섯 칸으로 나뉜다. 그리고 이 여섯 칸을 보는 순간, 돈 문제는 막연한 절약의 영역이 아니라 훨씬 더 선명한 관리의 영역으로 바뀐다. 나는 이를 비용의 공간화라고 부르고 싶다.

3. 개인도 같은 방식으로 봐야 한다

우리는 보통 소비를 이렇게 본다.

• 식비
• 교통비
• 쇼핑
• 카페

하지만 이 방식으로는 절대 돈이 모이지 않는다.
왜냐하면 통제 기준이 없기 때문이다.

대신 이렇게 봐야 한다.

“이 돈은 어떤 성격의 비용이고, 어떤 방식으로 나가고 있는가?”

4. 소비를 6칸으로 나누는 순간 시야가 바뀐다.

개인의 소비는 다음 6가지로 나눌 수 있다.

첫 번째는 고정 + 자재비다. 월세, 관리비, 정기 교통비, 기본적인 통신 인프라처럼 “살기 위해 어쩔 수 없이 매달 내는 돈”이다. 이 영역은 보통 초년생의 지출에서 가장 큰 비중을 차지한다. 그래서 많은 사람이 줄이기 어렵다고 생각한다. 맞다. 당장 크게 줄이기는 쉽지 않다. 하지만 동시에 가장 강력한 구조 효과가 나는 영역이기도 하다. 월세 10만 원 차이는 한 달로 보면 작아 보여도 1년이면 120만 원이고, 여기에 관리비와 생활 동선까지 합치면 체감 차이는 훨씬 커진다. 회사와 가까운 집을 선택해 교통비와 시간, 체력까지 줄이는 것도 결국 이 카테고리의 최적화다. 이 영역은 ‘아끼는 기술’보다 ‘선택의 구조’가 훨씬 중요하다.

두 번째는 변동 + 자재비다. 이것도 생존 영역이지만, 습관에 따라 생각보다 많이 흔들린다. 예를 들어 기본 식비는 자재비지만, 야근 후 매번 배달로 해결하는 식사나 주말마다 외식으로 늘어나는 비용은 변동 자재비에 가깝다. 교통도 마찬가지다. 평소에는 대중교통으로 충분하지만 피곤하다고 택시를 자주 타기 시작하면 기본 생활비처럼 보이지만 사실은 습관이 만든 변동비가 된다. 많은 사람이 “이건 어쩔 수 없는 비용”이라고 생각하는데, 막상 들여다보면 생활 리듬과 선택이 크게 작용하는 구간이다. 그래서 여기는 무작정 줄이기보다, 생활 방식을 조금만 바꿔도 꽤 많은 차이가 난다.

세 번째는 고정 + 인건비다. 이 부분은 초년생이 가장 헷갈려하는 영역이다. 헬스장, 정기 PT, 어학 수업, 온라인 강의 구독, 정기적인 건강관리 같은 것들이 여기에 들어간다. 언뜻 보면 “돈 아끼려면 제일 먼저 줄여야 할 것 같은 항목”처럼 보인다. 하지만 나는 오히려 반대로 봐야 한다고 생각한다. 이건 단순 소비가 아니라, 내 몸과 실력을 유지하는 데 드는 비용이다. 기업으로 치면 숙련된 인력을 유지하고 생산성을 관리하는 비용에 가깝다. 물론 아무 자기계발이나 다 좋은 건 아니다. 하지만 장기적으로 내 수입 가능성을 높이거나 생활의 리듬을 안정시키는 지출이라면, 이건 단기 절약을 위해 없애야 할 비용이 아니라 선별해서 유지해야 할 비용이다. 초년생의 자산관리는 여기서 많이 갈린다. 당장 아끼겠다고 성장 비용을 다 잘라내면, 숫자는 잠깐 좋아질 수 있어도 몇 년 뒤의 경쟁력은 약해질 수 있다.

네 번째는 변동 + 인건비다. 책을 사는 비용, 세미나 참가비, 네트워킹 모임, 필요할 때 듣는 단기 강의 같은 것들이 여기에 들어간다. 이 영역은 기회형 지출이라는 특징이 있다. 꼭 매달 나가지는 않지만, 잘 쓰면 꽤 값진 비용이 될 수 있다. 다만 여기에도 함정이 있다. 사람은 “배우는 데 쓰는 돈”에 관대해지기 쉽다. 그래서 실제로는 끝까지 보지 않는 강의를 충동적으로 결제하거나, 실질적인 도움이 없는 모임에 반복적으로 돈을 쓰기도 한다. 인건비라고 해서 무조건 선한 지출은 아니다. 중요한 건 이 지출이 정말 내 커리어와 삶의 질을 높이는지, 아니면 단지 ‘성장하는 사람처럼 느끼게 해주는 소비’인지 구분하는 일이다.

다섯 번째는 고정 + 경비다. 이건 정말 많은 초년생의 통장에서 조용히 돈을 빼가는 영역이다. 음악 스트리밍, OTT, 클라우드 저장공간, 유료 앱, 각종 멤버십, 습관처럼 유지하는 소액 정기결제들이 대표적이다. 하나하나는 작아 보여서 부담이 없어 보인다. 하지만 문제는 이런 지출이 한 번 연결되면 거의 의식되지 않는다는 데 있다. 직접 꺼내 쓰는 돈이 아니라 자동으로 빠져나가니 심리적 저항이 약하다. 그리고 어느 순간 보면 “내가 이걸 아직도 쓰고 있었네?” 싶은 항목이 몇 개씩 나온다. 고정 경비는 금액 자체보다 ‘무의식성’이 더 위험하다. 그래서 1년에 한두 번만이라도 이 항목들을 전부 점검하면, 의외로 큰 여유가 생긴다.

여섯 번째는 변동 + 경비다. 카페, 배달, 쇼핑, 취미, 술자리, 소소한 리워드 소비가 여기에 해당한다. 그리고 현실적으로, 대부분의 사람이 돈이 안 모이는 가장 큰 이유도 이 구간에 있다. 이 소비들은 대개 악의가 없고, 금액도 한 번 한 번은 크지 않다. 그래서 자신이 과소비하고 있다는 자각이 잘 생기지 않는다. 오늘 하루 힘들었으니 커피 한 잔, 이번 주 고생했으니 배달 한 번, 월급 받았으니 옷 한 벌. 각각은 다 이해 가능한 선택이다. 문제는 그 선택들이 한 달 단위로 쌓일 때다. 변동 경비는 감정과 아주 강하게 연결되어 있어서, 스트레스가 많을수록 커지고 피곤할수록 통제가 어려워진다. 그래서 이 영역은 의지로만 잡으려 하면 실패하기 쉽다. 예산을 미리 정해두고, 그 안에서는 죄책감 없이 쓰는 방식이 오히려 훨씬 지속 가능하다.

이렇게 보면 한 가지 사실이 분명해진다. 돈이 안 모이는 사람은 꼭 사치를 해서가 아니라, 어떤 돈은 지켜야 하고 어떤 돈은 통제해야 하는지 우선순위가 없어서 어려움을 겪는다. 예를 들어 고정 인건비는 함부로 줄이면 안 될 수 있다. 반대로 고정 경비는 바로 점검해야 할 가능성이 크다. 변동 자재비는 생활 방식의 개선으로 낮출 수 있고, 변동 경비는 감정 소비를 예산 안으로 끌어들이는 전략이 필요하다. 이 차이를 모르면 모든 소비를 한꺼번에 “줄여야 할 것”처럼 느끼게 되고, 결국 관리가 오래가지 못한다.

많은 초년생이 자산관리를 시작할 때 가장 먼저 하는 실수가 있다. 바로 절약을 의지의 문제로 보는 것이다. “이번 달은 커피를 줄여야지”, “배달을 끊어야지”, “쇼핑하지 말아야지” 같은 결심은 누구나 해본다. 하지만 대부분 오래가지 못한다. 이유는 간단하다. 구조는 그대로인데 행동만 바꾸려 하기 때문이다. 야근은 계속되고, 스트레스는 쌓이고, 동선은 비효율적이고, 자동결제는 계속 돌아가는데, 오직 마음가짐만으로 소비를 이기려 하니 쉽게 지칠 수밖에 없다.

그래서 소비관리의 핵심은 절약이 아니다. 설계다.
회사가 잘 운영되려면 비용을 무조건 줄이는 것이 아니라, 어떤 비용은 유지하고 어떤 비용은 바꾸고 어떤 비용은 없애야 하는지 알아야 한다. 개인도 마찬가지다. 월급이 적어서 돈이 안 모이는 경우도 물론 있다. 하지만 같은 소득 안에서도 돈의 흐름을 구조적으로 관리하는 사람은 분명히 다르게 쌓아간다. 그 사람들은 소비를 죄악처럼 보지 않는다. 대신 소비를 역할별로 나누고, 그 역할에 맞게 통제한다.

나는 직장인 초년생의 자산관리에서 가장 먼저 배워야 할 것이 바로 이것이라고 생각한다. 저축법보다 먼저, 투자법보다 먼저, 내 지출이 어떤 구조로 이루어져 있는지 보는 눈이 필요하다. 그래야 지금 내가 힘들게 아끼고 있는 돈이 사실은 별 효과 없는 곳에서 새고 있지는 않은지, 반대로 미래를 위해 꼭 필요한 비용까지 잘라내고 있지는 않은지 판단할 수 있다. 예를들어, 변동인건비에 해당하는 특강비용은 당장은 지출이지만, 향후 그 투자로 내 수입원이 얼마나 늘어날지는 모르는 것이다.

돈을 모으는 사람은 무조건 덜 쓰는 사람이 아니다.
정확히 말하면, 어디에 써야 하고 어디서 새는지를 아는 사람이다.
그리고 그 차이는 단순한 절약 습관이 아니라, 지출을 보는 관점에서 시작된다.

이번 글은 그 관점을 세우기 위한 첫 번째 이야기다. 다음 글에서는 이 여섯 칸 중에서도 가장 먼저 손봐야 할 영역인 고정비에 대해 이야기해보려고 한다. 왜 고정비는 한 번만 잘 설계해도 몇 년 동안 효과가 이어지는지, 그리고 초년생이 가장 쉽게 놓치는 고정비의 함정이 무엇인지 구체적으로 다뤄보겠다.

AI 코딩 변화 연대기 ②

프롬프트가 코드가 된 순간

1편에서 다룬 바이브 코딩의 초창기는 “AI가 코드를 써 주기 시작한 순간”에 대한 이야기였다. 2편은 그다음 장면이다. 개발자들이 AI에게 코드를 부탁하기 시작하자, 곧바로 더 중요한 문제가 드러났다. AI가 코드를 못 쓰는 게 아니라, 내가 애매하게 말하면 애매하게 만든다는 사실이었다. 이때부터 개발자들은 코드를 짜는 대신, 먼저 질문을 설계하는 법을 배우기 시작한다.

같은 질문인데, 결과는 왜 매번 달랐을까

초기의 AI 코딩 경험은 놀라웠지만 동시에 불안정했다. 같은 요청을 던져도 어떤 날은 괜찮은 코드가 나오고, 어떤 날은 너무 얕거나 엉뚱한 결과가 나왔다. 그래서 개발자들은 곧 “모델 성능”만 탓할 수 없다는 걸 알게 된다. OpenAI는 프롬프트 엔지니어링의 기본 원칙으로 명확하고 구체적인 지시와 반복적인 수정을 강조하고, Anthropic 역시 프롬프트를 고치기 전에 먼저 성공 기준과 검증 방법부터 정하라고 권한다. 즉 문제는 AI가 멍청해서가 아니라, 우리가 원하는 결과를 충분히 구조화하지 못했기 때문이었다. (OpenAI Help Center)

예를 들어 이런 요청은 너무 넓다.

로그인 API 만들어줘

이 한 문장 안에는 인증 방식도 없고, 보안 수준도 없고, 출력 형식도 없다. 그러니 AI는 JWT를 쓸 수도 있고 세션을 쓸 수도 있고, 심하면 튜토리얼 수준의 예제를 가져올 수도 있다. 초창기 AI 코딩이 흔들렸던 이유는 여기 있다. 코드는 정답처럼 보여도, 요청은 아직 명세가 아니었다.

그래서 개발자들은 “질문”을 설계하기 시작했다

이 지점에서 프롬프트는 더 이상 채팅창에 던지는 한 줄 문장이 아니게 된다. OpenAI의 프롬프팅 가이드는 역할 지침은 system message에 두고, 작업 세부사항과 예시는 user message에 두라고 설명한다. 또 프롬프트를 저장하고, 버전 관리하고, 변수로 치환하고, 팀 내에서 공유할 수 있는 대상으로 다룬다. 이건 중요한 변화다. 프롬프트가 즉흥적인 말이 아니라, 반복 사용과 개선이 가능한 작업 설계물이 되기 시작했다는 뜻이기 때문이다. (OpenAI)

예전에는 개발자가 “무엇을 만들까”를 생각한 뒤 바로 코드로 들어갔다. 하지만 이 시기부터는 그 사이에 한 단계가 더 생겼다. 먼저 AI가 오해하지 않도록 문제의 경계와 기대 결과를 언어로 설계해야 했다. 그래서 개발자는 코드 작성자이면서 동시에 일종의 디렉터가 된다. 코드를 타이핑하는 속도보다, AI가 헛나가지 않게 질문을 잡아 주는 능력이 더 중요해지기 시작한 것이다.

프롬프트는 점점 작은 프로그램처럼 보이기 시작했다

프롬프트 엔지니어링이 흥미로운 이유는, 그것이 단순한 “말 잘하기”가 아니었다는 데 있다. 구조가 생기면 프롬프트는 거의 작은 프로그램처럼 동작한다. 역할을 부여하고, 조건을 걸고, 출력 형식을 강제하고, 예시를 몇 개 붙이면 모델의 행동이 눈에 띄게 달라진다. OpenAI와 Anthropic의 가이드가 공통적으로 강조하는 것도 이 부분이다. 좋은 프롬프트는 멋있는 문장이 아니라, 모델이 따라야 할 작업 규칙의 묶음이다. (OpenAI)

예를 들면 이런 식이다.

너는 시니어 Spring Boot 개발자다.
JWT 기반 로그인 API를 작성하라.

요구사항:
- REST API
- Controller / Service / Repository 구조
- 예외 처리 포함
- 테스트 코드 초안 포함

출력 형식:
1. 디렉터리 구조
2. 각 파일 코드
3. 보안상 주의점

이 프롬프트는 단순한 질문이 아니다. 이미 역할, 요구사항, 출력 포맷, 검토 기준이 들어 있다. 그러니까 이 시기의 개발자는 코드를 짜기 전에, 먼저 AI가 따라야 할 미니 명세서를 써내려가고 있었던 셈이다.

그래서 프롬프트 패턴이 생겨났다

프롬프트가 구조물이 되자, 개발자들은 곧 서로의 패턴을 복제하기 시작했다. “너는 시니어 백엔드 개발자다” 같은 역할 지정, “단계적으로 풀어라” 같은 추론 유도, “JSON으로 반환하라” 같은 형식 제어가 빠르게 표준처럼 퍼졌다. 이 흐름에는 2022년의 Chain-of-Thought Prompting 연구도 큰 영향을 줬다. 이 논문은 중간 추론 과정을 예시로 넣는 것만으로도 복잡한 추론 문제의 성능이 크게 좋아질 수 있음을 보여줬고, 이후 “step by step” 프롬프트는 거의 기본 습관처럼 자리 잡았다. 프롬프트는 여기서 처음으로 “질문”을 넘어서 행동을 유도하는 인터페이스가 된다. (arXiv.gg)

이 시기의 개발자 커뮤니티를 떠올려 보면, 코드 스니펫만큼이나 프롬프트 스니펫이 돌아다니기 시작했다. 어떤 사람은 역할 프롬프트를 공유했고, 어떤 사람은 few-shot 예시 묶음을 템플릿처럼 썼다. 코드 조각을 복붙하듯 프롬프트 조각도 복붙되던 시기였다. 한마디로 말해, 프롬프트가 새로운 생산성 단위가 되었다.

“프롬프트 엔지니어”라는 말이 뜬 것도 이때였다

프롬프트 엔지니어링이 얼마나 뜨거웠는지는, 아예 “Prompt Engineer”라는 직함이 언론에 등장했다는 사실만 봐도 알 수 있다. Axios는 2023년 초 생성형 AI의 급부상과 함께 prompt engineer라는 새로운 직함이 생겨나고 있다고 보도했다. 이 기사에서 핵심은 단순한 유행이 아니라, 기업들이 프롬프트 설계를 실제 업무 역량으로 보기 시작했다는 점이다. 프롬프트를 잘 짜는 사람은 그냥 말 잘하는 사람이 아니라, 모델의 출력을 더 안정적이고 더 유용하게 만드는 사람으로 여겨졌다. (Axios)

지금 돌아보면 다소 과열된 면이 있었던 것도 사실이다. 하지만 그 과열 자체가 이 시대의 공기를 잘 보여준다. 당시 사람들은 정말로 프롬프트를 하나의 신기술처럼 다뤘다. “좋은 프롬프트 하나가 나쁜 모델보다 강하다”는 식의 말도 자주 나왔다. 그만큼 많은 개발자들이, AI와의 협업에서 성패를 가르는 것은 모델 이름보다 입력의 설계라고 느끼고 있었다.

하지만 곧, 프롬프트만으로는 안 된다는 사실이 드러났다

프롬프트 엔지니어링은 분명 유효했다. 다만 오래 지나지 않아 한계도 선명해졌다. 질문을 아무리 정교하게 써도, 모델이 내 코드베이스를 모르고 팀 규칙을 모르고 사내 문서를 모르면 결과는 어느 지점에서 막힌다. 그래서 업계의 관심은 점차 “어떻게 물을까”에서 “무엇을 함께 넣어줄까”로 이동한다. OpenAI의 Retrieval 가이드는 semantic search와 vector store를 통해 모델 바깥의 데이터를 불러오는 방식을 설명하고, File search 가이드는 업로드된 파일을 검색해 모델이 답변 전에 필요한 정보를 가져오도록 하는 구조를 제시한다. (OpenAI)

이 변화는 꽤 본질적이다. 프롬프트 엔지니어링 시대에는 모델이 가진 내장 지식 안에서 최대한 잘 말하게 만드는 것이 목표였다. 반면 그다음 시대에는, 모델이 모르는 것을 찾아와서 붙인 뒤 말하게 만드는 것이 더 중요해진다. 다시 말해, 질문을 잘 쓰는 것만으로는 부족했고, 이제는 정답에 필요한 문맥 자체를 공급하는 일이 핵심 문제가 되었다.

그래서 문제의 중심이 “프롬프트”에서 “컨텍스트”로 옮겨갔다

나는 이 지점이 AI 코딩 역사에서 아주 중요한 분기점이라고 본다. 프롬프트 엔지니어링은 AI에게 잘 말하는 기술이었다. 하지만 컨텍스트 엔지니어링은 AI가 무엇을 알고 답해야 하는지 설계하는 기술이다. Retrieval과 file search 같은 방식은 바로 그 전환을 기술적으로 가능하게 만든다. 모델은 더 이상 자기 파라미터 안의 기억만으로 답하는 존재가 아니라, 필요할 때 외부 정보를 가져와 조합하는 시스템이 되기 시작했다. (OpenAI)

그래서 프롬프트 엔지니어링은 사라진 개념이라기보다, 다음 단계로 넘어가기 위한 훈련기였다고 보는 편이 정확하다. 이 시기에 개발자들은 적어도 두 가지를 배웠다. 첫째, AI는 좋은 질문 앞에서 훨씬 좋아진다. 둘째, 하지만 좋은 질문만으로는 끝나지 않는다. 결국 다음 단계는 필연적이었다.

다음 편: 프롬프트 이후에는 왜 컨텍스트가 남았는가

3편에서는 이 흐름이 어떻게 Context Engineering으로 이어졌는지를 다룰 생각이다. RAG, 코드베이스 인덱싱, 벡터 스토어, 사내 문서 연결 같은 기술이 왜 갑자기 중요해졌는지, 그리고 왜 AI 코딩의 중심이 “질문하는 기술”에서 “정보를 공급하는 기술”로 옮겨갔는지를 이어서 풀 수 있다. 2편의 핵심을 한 줄로 정리하면 이렇다.

프롬프트 엔지니어링의 시대는, 개발자가 AI에게 잘 말하는 법을 배운 시대였다.
그리고 바로 그 성공 때문에, 사람들은 곧 말보다 문맥이 더 중요하다는 사실을 깨닫게 되었다.

Codex 모델에서 Copilot을 지나, Cursor와 Karpathy까지

바이브 코딩은 어느 날 갑자기 떨어진 유행어처럼 보인다. 하지만 실제로는 그렇지 않다. 2025년 2월 Andrej Karpathy가 그 표현을 붙이기 훨씬 전부터, 개발자들은 이미 코드를 “직접 쓰는” 방식에서 조금씩 멀어지고 있었다. 내 생각에 바이브 코딩은 하나의 발명이 아니라, 몇 년에 걸쳐 형성된 개발 감각에 나중에 이름이 붙은 사건에 가깝다. 그 감각의 시작점은 2021년의 Codex 모델과 Copilot이었다. (Simon Willison’s Weblog)

먼저 이름부터 정리할 필요가 있다. 이 글에서 말하는 Codex는 2021년에 GitHub와의 협업 속에서 등장한 multilingual Codex model이다. OpenAI가 2025년에 공개한 클라우드 기반 소프트웨어 엔지니어링 에이전트 Codex와는 다른 대상이다. 둘은 같은 이름을 쓰지만, 연대기상 맡는 역할이 다르다. 2021년의 Codex는 “코드를 생성하는 모델”이고, 2025년의 Codex는 “작업을 위임받아 수행하는 에이전트” 쪽에 더 가깝다. (The GitHub Blog)

1. 2021년: AI가 처음으로 “코드를 쓰기 시작한” 순간

GitHub의 설명에 따르면, OpenAI는 2021년에 GitHub와 함께 만든 multilingual Codex model을 공개했다. 이 모델은 GPT-3의 갈래였지만, 수십억 줄의 공개 코드를 학습해 자연어뿐 아니라 코드 제안까지 만들어낼 수 있었다. 이 지점이 중요한 이유는 단순하다. 여기서 처음으로 AI는 검색 결과를 보여주는 도구가 아니라, 설명을 받아 코드를 산출하는 시스템이 되었기 때문이다. (The GitHub Blog)

이 변화는 겉보기보다 크다. 그전까지 개발자의 기본 동작은 “생각하고, 문법으로 번역하고, 직접 타이핑한다”에 가까웠다. 그런데 Codex가 등장하면서 작업의 최소 단위가 조금 바뀌기 시작했다. 이제 개발자는 구현을 머릿속에서 완성한 뒤 그대로 손으로 옮기는 사람이라기보다, 무엇을 만들고 싶은지 설명하는 사람이 될 수 있었다. 아직 거칠고 제한적이었지만, “코드”보다 “의도”가 먼저 오는 개발 방식의 씨앗은 이때 심어졌다. 이게 바이브 코딩의 가장 먼 기원이다. (The GitHub Blog)

2. Copilot: 모델이 IDE 안으로 들어오다

그 씨앗이 실제 개발 습관으로 번지기 시작한 건 2021년 6월 29일 GitHub Copilot 기술 프리뷰가 공개되면서부터다. GitHub는 Copilot을 “AI pair programmer”라고 소개했고, 이 도구가 현재 작업 중인 코드 문맥을 읽어 whole lines or entire functions를 제안한다고 설명했다. 또 Copilot이 OpenAI Codex로 구동되며, 테스트 작성이나 새로운 API 탐색 같은 작업을 빠르게 돕는다고 밝혔다. (The GitHub Blog)

이때 일어난 진짜 변화는 성능만이 아니라 인터페이스의 변화였다. Codex가 “가능성”이었다면, Copilot은 그 가능성을 개발자의 손가락 바로 아래에 붙여놓았다. 검색창도 아니고 별도 데모도 아니었다. 에디터 안에서 내가 몇 글자를 쓰면, 나머지를 기계가 먼저 제안했다. 그래서 Copilot은 단순한 자동완성처럼 보였지만, 사실은 자동완성보다 한 단계 더 나아간 경험이었다. 개발자는 빈 화면에서 모든 줄을 직접 짜기보다, AI가 내민 초안을 채택하거나 버리는 쪽으로 움직이기 시작했다. (The GitHub Blog)

하지만 이 시점을 곧바로 바이브 코딩이라고 부르기는 어렵다. Copilot 시대의 중심은 여전히 인간 개발자에게 있었다. 구조를 정하고, 파일을 열고, 흐름을 잡고, 제안을 받아들일지 말지를 결정하는 쪽은 여전히 사람이었다. 말하자면 이 시기의 AI 코딩은 “대신 만들어주는 개발”이라기보다 **“옆에서 잘 받아치는 개발”**에 가까웠다. 바이브 코딩의 핵심이 “구현을 직접 통제하지 않고도 계속 전진하는 감각”이라면, Copilot은 그 전조였다. 아직은 본격적인 탄생 이전 단계였다. (The GitHub Blog)

3. 바이브 코딩의 전제: 코드를 쓰는 것보다, 코드를 유도하는 것

그래도 Copilot은 개발자의 몸에 아주 중요한 습관 하나를 남겼다. 코드를 한 줄 한 줄 “생산”하는 것보다, 원하는 방향으로 유도하는 것이 더 중요해지는 습관이다. 테스트를 먼저 쓰게 만들고, 반복적인 보일러플레이트를 맡기고, 주석이나 함수 시그니처만으로 다음 덩어리를 끌어내는 경험이 쌓이면서 개발자는 점점 “작성자”에서 “조향자”로 이동했다. 이 변화는 아직 문화적 이름을 얻지 못했지만, 뒤에서 돌아보면 분명 바이브 코딩으로 가는 첫 번째 학습 단계였다. (The GitHub Blog)

예전에는 “정확한 구현”이 먼저였고 “설명”은 부차적이었다. 하지만 Copilot 이후에는 설명, 주석, 함수 이름, 현재 파일의 문맥 자체가 생성의 레버가 되기 시작했다. 개발자는 점점 코드의 모든 줄을 써 내려가는 사람이 아니라, AI가 좋은 초안을 내놓도록 프레임을 잡아주는 사람이 되었다. 이 시점부터 AI 코딩의 단위는 서서히 “문법”에서 “의도”로 옮겨간다. (The GitHub Blog)

4. Cursor: 프로젝트 전체가 컨텍스트가 되다

바이브 코딩이 정말로 가능한 분위기로 넘어간 건, AI가 한 줄 완성을 넘어 코드베이스 단위로 작동하기 시작하면서부터다. Cursor의 공식 문서는 이 도구가 각 파일의 임베딩을 계산해 코드베이스를 인덱싱하고, 프로젝트를 열면 자동으로 인덱싱을 시작하며, 새 파일도 점진적으로 인덱싱한다고 설명한다. 이 말은 곧 AI가 단지 눈앞의 함수 몇 줄만 보는 게 아니라, 프로젝트를 더 넓은 맥락에서 참고할 수 있게 되었다는 뜻이다. (Cursor Documentation)

여기서 “Cursor가 프로젝트 전체를 이해한다”는 표현은 과장해서 받아들이면 안 된다. Cursor가 magically 모든 코드를 완전하게 이해하는 것이 아니라, 공식 설명대로라면 코드베이스를 인덱싱하고 필요한 맥락을 검색해 답변 정확도를 높이는 구조에 가깝다. 하지만 사용자 경험 차원에서는 이 차이가 결정적이었다. 개발자는 더 이상 “이 함수 하나만 완성해줘”가 아니라, “이 프로젝트에서 인증 흐름을 이렇게 바꿔줘” 같은 요청을 던질 수 있게 되었기 때문이다. 구현 단위가 함수에서 프로젝트로 넓어진 순간, AI 코딩은 도우미에서 협업자로 성격이 바뀌기 시작했다. (Cursor Documentation)

그 변화는 2024년 11월 24일 Cursor의 공식 changelog에서 더 분명하게 보인다. 이 업데이트는 Composer UI, inline diffs, 그리고 “자기 스스로 컨텍스트를 고르고 터미널을 사용할 수 있는 early version of an agent in composer”를 소개했다. 이 문장은 중요하다. 왜냐하면 여기서부터 AI는 추천만 하는 도구가 아니라, 맥락을 집고, 편집하고, 실행하는 흐름으로 나아가기 때문이다. (Cursor)

이 지점이 바로 Copilot과 Cursor 사이의 질적 차이다. Copilot이 “현재 타이핑 중인 코드 문맥”을 기반으로 다음 줄을 제안했다면, Cursor는 “코드베이스 전체를 어떻게 읽어와서 작업에 투입할 것인가”를 전면으로 끌어냈다. 그래서 2021년 Copilot이 심어놓은 감각은 Cursor에서 더 급진적으로 확장된다. 이제 개발자는 코드를 쓰는 사람이라기보다, AI에게 프로젝트를 설명하고 결과를 선택하는 사람이 된다. 바이브 코딩이 가능해질 도구적 토대는 사실상 여기서 완성된다. (The GitHub Blog)

5. 2025년 2월: Andrej Karpathy가 그 감각에 이름을 붙이다

이제 2025년 2월로 가보자. Simon Willison은 2025년 3월 글에서, “vibe coding”이라는 용어가 Andrej Karpathy에 의해 2025년 2월 6일 만들어졌다고 짚는다. 그리고 Karpathy의 원문을 인용하며, 그가 이 방식을 Cursor Composer와 Sonnet, 그리고 SuperWhisper 같은 도구와 함께 설명했다고 소개한다. 즉 바이브 코딩이라는 말은 추상적 철학이 아니라, 실제로는 이미 성숙해 가던 툴 체인 위에서 나온 현장 용어였다. (Simon Willison’s Weblog)

Karpathy의 문장에서 가장 유명한 부분은 이것이다. 그는 “There’s a new kind of coding I call ‘vibe coding’”라고 썼다. 그리고 이어서 코드를 꼼꼼히 읽기보다, AI가 내놓는 결과를 받아들이고, 에러를 복붙해서 다시 던지고, 필요하면 UI를 말로 수정시키는 흐름을 묘사했다. 중요한 건 이 표현이 “AI로 코딩한다”는 일반론을 말한 게 아니라는 점이다. 그가 이름 붙인 것은 구현의 세부를 붙들지 않은 채, 말하고 실행하고 수정하며 앞으로 나아가는 개발 감각이었다. (Simon Willison’s Weblog)

그래서 Simon Willison의 구분이 중요하다. 그의 글 제목 자체가 “모든 AI 보조 프로그래밍이 바이브 코딩은 아니다”다. 즉 LLM이 모든 줄을 써도, 개발자가 그 코드를 검토하고 테스트하고 이해했다면 그건 넓은 의미의 AI-assisted programming이지, Karpathy가 말한 의미의 vibe coding과는 다르다. 바이브 코딩의 핵심은 AI 사용 여부가 아니라, 구현 통제권을 어디까지 모델에게 넘기느냐에 있다. 이 구분을 놓치면 Copilot, ChatGPT, Cursor, Claude Code를 전부 같은 범주로 섞어버리게 된다. (Simon Willison’s Weblog)

6. 정리: 바이브 코딩은 “발명”보다 “명명”에 가까웠다

이렇게 보면 1편의 결론은 분명하다. 바이브 코딩은 2025년 2월 어느 날 갑자기 생겨난 개발 방식이 아니다. 2021년 Codex 모델이 자연어에서 코드로 넘어가는 첫 문을 열었고, 같은 해 Copilot이 그 능력을 IDE 안의 일상 습관으로 옮겼으며, 이후 Cursor가 코드베이스 인덱싱과 agentic editing을 통해 그 경험을 프로젝트 단위로 확장했다. Karpathy는 그 누적된 변화가 만들어낸 새로운 감각을 보고, 가장 적확한 이름 하나를 붙인 셈이다. (The GitHub Blog)

그래서 초창기 AI 코딩의 변화는 이렇게 요약할 수 있다.
처음에 AI는 코드를 생성했다.
다음에는 개발자의 에디터 안에서 코드를 제안했다.
그다음에는 프로젝트 전체를 읽고 코드를 수정하기 시작했다.
그리고 마침내 개발자는 구현자가 아니라, AI에게 방향을 제시하고 결과를 판단하는 조향자가 되었다. 나는 1편의 핵심을 바로 이 변화라고 본다. 바이브 코딩은 기술의 이름이 아니라, 개발자의 역할이 바뀌는 순간에 붙은 이름이다. (The GitHub Blog)

다음 2편은 자연스럽게 그다음 질문으로 넘어간다.
그렇다면 개발자는 AI에게 “어떻게 말해야” 했을까?
그 지점에서 프롬프트 엔지니어링이 등장한다.

신기해서 적어봄

오픈코드 - 하나의 개발환경에서 여러개 모델을 돌아가면서 쓸 수 있는 코딩 툴

오 마이 오픈코드의 핵심 전략은 여러명의 에이전트가 자기가 잘하는거만 하는거

• 시지프스
• 라이브러리안
• 오라클
• 익스플로러
• 프론트엔드 엔지니어

각각의 역할에 맞는 모델이 임의로 존재하며 각각 맡은 역할을 수행하는 것이 핵심

랄프 루프

시도한다 될때까지 기본은 100번 정도

바이브 코딩이 되나? 이 정도 과금을 해본 적 없으니 알 방법은 없지만

이걸 일반적 글쓰기에 적용할 방법을 찾아보는건 어떨까 싶다

프롬프트는 단순히 모델에게 지시를 내리는 문장이 아니라, 모델이 어떤 역할로 사고하고 어떤 기준으로 응답할지를 정의하는 작동 규약에 가깝다. 따라서 좋은 프롬프트 규칙은 문장을 예쁘게 쓰는 기술이 아니라, 결과물의 품질과 일관성을 높이기 위한 설계 원칙이어야 한다.
이때 중요한 것은 규칙이 많아지는 것 자체가 아니라, 모델이 이해하기 쉬운 구조로 정리되어 있고, 충돌 없이 적용 가능하며, 실제 사례를 통해 재사용 가능해야 한다는 점이다.

아래 다섯 가지 축은 이러한 규칙 체계를 설계할 때 핵심이 된다.

1. 페르소나(Persona)의 명시

익히 알려진 바와 같이, 페르소나를 규정하는 것은 비교적 적은 비용으로 LLM의 응답 품질을 끌어올릴 수 있는 효과적인 방법이다.
모델은 기본적으로 매우 범용적인 응답 성향을 갖기 때문에, 아무런 역할 지정 없이 질문을 던지면 답변의 깊이, 어조, 판단 기준이 매번 달라질 수 있다. 반면 페르소나를 부여하면, 모델은 특정한 시각과 책임 범위 안에서 더 안정적으로 응답하게 된다.

여기서 중요한 것은 페르소나를 단순히 “친절한 AI”, “전문가처럼 답해라” 수준으로 적는 데 그치지 않는 것이다. 좋은 페르소나는 최소한 다음 요소를 포함해야 한다.

• 역할(Role): 무엇을 하는 존재인지
  예: 전략 컨설턴트, 기술 문서 작성자, 코드 리뷰어, 에디터
• 전문성(Expertise): 어떤 지식 수준을 가정하는지
  예: 초급자 대상 설명, 실무자 수준 분석, 학술적 엄밀성 요구
• 어조(Tone): 어떤 말투와 태도를 유지할지
  예: 간결하고 단정한 문체, 친절하지만 군더더기 없는 설명
• 의사결정 기준(Decision Criteria): 무엇을 우선시할지
  예: 정확성 우선, 실행 가능성 우선, 사용자 이해도 우선
• 금지사항(Boundaries): 하지 말아야 할 것
  예: 불확실한 내용을 단정하지 않기, 장황한 서론 피하기

즉, 페르소나는 “분위기”가 아니라 모델의 판단 프레임이다.
이 프레임이 명확할수록 답변은 덜 흔들리고, 같은 입력에 대해 더 일관된 출력이 나온다.

예를 들어 다음 두 프롬프트는 차이가 크다.

나쁜 예:

전문가처럼 답해줘.

좋은 예:

당신은 실무 중심의 기술 문서 작성자다.
초급자도 이해할 수 있게 설명하되, 핵심 용어는 정확히 사용한다.
장황한 배경 설명보다 실행 절차와 판단 기준을 우선한다.
확실하지 않은 내용은 추정이라고 명시한다.

전자는 분위기만 전달하지만, 후자는 역할, 대상 독자, 우선순위, 금지사항까지 포함한다.
따라서 규칙 문서에서 페르소나는 선택 요소가 아니라, 가장 먼저 정의해야 하는 기본 축으로 다루는 것이 바람직하다.

2. 바람직한 패턴과 안티 패턴의 정의

프롬프트 규칙은 추상적인 선언만으로는 잘 작동하지 않는다.
“구체적으로 써라”, “명확하게 요청하라”, “모호함을 줄여라” 같은 문장은 맞는 말이지만, 실제 작성자가 바로 적용하기는 어렵다. 그래서 규칙 문서에는 반드시 좋은 패턴과 안티 패턴을 예시와 함께 제시해야 한다.

이 방식의 핵심은 모델을 직접 훈련시키는 것이 아니라, 프롬프트를 작성하는 사람을 훈련시키는 것이다.
즉, 어떤 문장이 좋은 프롬프트로 이어지고 어떤 문장이 문제를 만드는지, 읽는 사람이 곧바로 비교할 수 있어야 한다.

좋은 패턴은 보통 다음 특징을 가진다.

• 요청의 목적이 분명하다.
• 산출물의 형식이 명시되어 있다.
• 대상 독자나 사용 맥락이 드러난다.
• 성공 기준이 포함되어 있다.
• 필요 시 제외 조건이나 금지사항이 함께 적혀 있다.

반대로 안티 패턴은 다음과 같은 문제를 가진다.

• 너무 추상적이다.
• 요청의 범위가 넓고 경계가 없다.
• 형식은 요구하지만 목적은 없다.
• 맥락 없이 표현만 통제한다.
• 여러 지시가 한 문장 안에서 충돌한다.

예를 들면 다음과 같다.

예시 1: 모호한 요청

안티 패턴:

이 문장을 더 좋게 고쳐줘.

문제점:

• 무엇이 “좋은지” 기준이 없다.
• 길이를 줄일지, 설득력을 높일지, 격식을 높일지 판단할 수 없다.

바람직한 패턴:

이 문장을 임원 보고용으로 다듬어줘.
핵심 메시지는 유지하고, 분량은 20% 줄이며, 단정하고 간결한 문체로 수정해줘.

예시 2: 형식만 있고 목적이 없는 요청

안티 패턴:

5줄로 요약해줘.

문제점:

• 왜 5줄이어야 하는지 이유가 없다.
• 사용자에게 필요한 정보가 무엇인지 드러나지 않는다.

바람직한 패턴:

이 문서를 경영진이 1분 안에 파악할 수 있도록 5줄로 요약해줘.
각 줄은 결론 중심으로 작성하고, 세부 배경은 제외해줘.

예시 3: 지시 충돌

안티 패턴:

자세하고 짧게 써줘. 쉬우면서도 전문적으로 써줘.

문제점:

• “자세함”과 “짧음”, “쉬움”과 “전문성” 사이의 균형 기준이 없다.
• 모델이 무엇을 우선해야 하는지 판단하기 어렵다.

바람직한 패턴:

전문 용어는 유지하되, 각 용어 옆에 짧은 풀이를 붙여 초급자도 이해할 수 있게 써줘.
전체 분량은 500자 이내로 제한해줘.

좋은 규칙 문서는 이런 식으로 단순 명령문이 아니라, 왜 이 표현이 문제인지, 어떻게 바꾸면 더 잘 작동하는지까지 보여줘야 한다.
그래야 사용자가 규칙을 외우는 것이 아니라, 패턴을 체득하게 된다.

3. 문맥(Context) 기반의 해결책 제시

프롬프트 개선에서 가장 흔한 실수는 “무조건 짧게”, “무조건 구체적으로”, “무조건 친절하게” 같은 단선적인 처방을 내리는 것이다.
하지만 실제로는 어떤 지시가 좋은지 여부는 항상 맥락에 따라 달라진다.

예를 들어 설명을 줄이는 것이 항상 좋은 것은 아니다.
초급자 대상 튜토리얼에서는 오히려 배경 설명이 부족하면 이해가 무너질 수 있고, 반대로 임원 보고나 운영 문서에서는 핵심만 남기지 않으면 전달력이 떨어질 수 있다.
따라서 프롬프트 규칙은 단순히 수정안을 제시하는 데서 끝나면 안 되고, 반드시 다음 두 가지를 함께 제공해야 한다.

• 왜(Why) 이 수정이 필요한가
• 어떤 상황(Context)에서 이 규칙을 적용해야 하는가

즉, 규칙은 표현의 문제가 아니라 판단의 조건까지 포함해야 한다.

좋은 규칙 문서에서는 각 항목을 아래 구조로 설명하는 것이 효과적이다.

• 문제 상황
• 왜 문제가 되는가
• 어떤 맥락에서 특히 치명적인가
• 어떻게 수정해야 하는가
• 수정 예시

예를 들면 다음과 같이 쓸 수 있다.

예시: “짧게 써라” 규칙의 문맥화

단순 규칙:

가능한 짧게 작성한다.

문제점:

• 모든 작업에 동일하게 적용되면 정보 손실이 발생한다.

개선된 규칙:

핵심 전달 속도가 중요한 상황에서는 답변을 짧게 작성한다.
예: 임원 보고, 채팅 응답, 요약 카드, 운영 알림
다만 학습용 설명, 설계 문서, 의사결정 근거 제시가 필요한 상황에서는 단순 축약보다 구조화된 상세 설명을 우선한다.

왜 필요한가:

• 길이 자체가 목적이 아니라, 전달 효율이 목적이기 때문이다.

이런 식의 문맥 설명은 프롬프트 작성자가 규칙을 기계적으로 적용하지 않도록 돕는다.
결국 강한 프롬프트는 “어떻게 말할지”만 정의하는 것이 아니라, 언제 어떤 원칙을 꺼내 써야 하는지까지 명시하는 설계 문서여야 한다.

4. 규칙 간 우선순위 정의

규칙이 늘어날수록 반드시 발생하는 문제가 있다. 바로 규칙 충돌이다.
예를 들어 어떤 규칙은 “간결하게 답하라”고 하고, 다른 규칙은 “충분한 근거를 들어 설명하라”고 요구할 수 있다. 또 어떤 규칙은 “친절한 어조”를 원하지만, 다른 규칙은 “직설적이고 짧은 피드백”을 요구할 수도 있다.

이때 우선순위가 정해져 있지 않으면, 프롬프트는 많아질수록 오히려 품질이 떨어진다. 모델 입장에서는 어느 규칙을 먼저 따라야 하는지 불명확해지기 때문이다.
따라서 규칙 문서에는 각 항목 자체만큼이나, 규칙 간 서열과 충돌 해결 원칙이 중요하다.

실무적으로는 다음과 같은 계층 구조를 두는 것이 유용하다.

권장 우선순위 구조

1. 안전성 / 금지 규칙
   • 허용되지 않는 행동, 추정 금지, 민감 정보 처리 등
2. 핵심 과업 목표
   • 사용자가 진짜로 원하는 결과가 무엇인지
3. 도메인 규칙
   • 예: 법률 문서는 정확성 우선, 마케팅 문구는 설득력 우선
4. 문맥 규칙
   • 예: 임원 보고용, 초급자 대상, 회의 요약용
5. 페르소나 및 톤
   • 예: 단정한 문체, 코치형 피드백, 분석가적 태도
6. 출력 형식
   • 예: bullet 3개, 표 형태, 500자 이내
7. 선호 규칙
   • 예: 이모지 사용 금지, 영어 표현 최소화 등

이 순서를 두는 이유는 명확하다.
예를 들어 사용자가 “짧고 강하게 써달라”고 요청했더라도, 정확성이나 안전성보다 우선될 수는 없다.
마찬가지로 “친절한 톤”은 중요하지만, 과업 목표를 희생하면서까지 지켜야 할 1순위는 아니다.

규칙 문서에는 이런 원칙을 선언적으로 적는 것만으로도 큰 효과가 있다. 예를 들면 다음과 같이 쓸 수 있다.

규칙이 충돌할 경우, 안전성 > 과업 목표 > 문맥 적합성 > 형식적 선호 순으로 우선 적용한다.
형식 제약 때문에 정보 손실이 발생할 경우, 형식보다 의미 보존을 우선한다.

이 한 줄이 있느냐 없느냐에 따라, 규칙 집합은 단순 체크리스트가 아니라 운영 가능한 판단 체계가 된다.

5. 규칙의 단일 파일 통합

규칙이 여러 문서, 메모, 예시 프롬프트, 슬랙 대화, 노션 페이지 등에 흩어져 있으면 실제 사용 단계에서 거의 무력화된다.
사람은 분산된 규칙을 기억하지 못하고, 모델 역시 일관되게 적용하기 어렵다.
따라서 규칙은 가능한 한 단일 파일 또는 단일 진입점으로 통합해 관리해야 한다.

단일 파일 통합의 장점은 다음과 같다.

• 현재 유효한 규칙이 무엇인지 한 번에 확인할 수 있다.
• 중복 규칙과 충돌 규칙을 쉽게 발견할 수 있다.
• 버전 관리와 변경 이력 추적이 가능하다.
• 팀 단위로 공유하고 수정하기 쉬워진다.
• 프롬프트를 조립할 때 기준 문서로 재사용할 수 있다.

여기서 중요한 것은 단지 한 파일에 몰아넣는 것이 아니라, 탐색 가능한 구조로 정리하는 것이다.
권장 구조는 아래와 같다.

단일 파일 권장 구조

• 문서 목적
• 적용 범위
• 핵심 원칙 요약
• 페르소나 정의
• 규칙 목록
• 규칙 우선순위
• 좋은 예시 / 나쁜 예시
• 문맥별 적용 가이드
• 예외 처리 원칙
• 변경 이력

이렇게 정리하면 이 파일은 단순한 참고자료가 아니라, 일종의 프롬프트 스타일 가이드가 된다.
특히 팀 단위 운영에서는 각 규칙에 ID를 붙여 관리하는 것도 좋다.

예:

• P-01: 페르소나는 역할, 전문성, 어조를 포함해야 한다.
• C-02: 수정 제안에는 적용 맥락과 이유를 함께 제시한다.
• X-03: “더 좋게”, “적당히”, “깔끔하게” 같은 모호한 표현을 단독 지시로 사용하지 않는다.
• O-01: 규칙 충돌 시 안전성, 과업 목표, 문맥 순으로 판단한다.

이렇게 되면 팀원 간 대화도 쉬워진다.
“이 프롬프트는 P-01은 지켰는데 C-02가 빠졌다”처럼 구체적으로 피드백할 수 있기 때문이다.

추가로 붙이면 좋은 운영 원칙

위 다섯 가지가 골자라면, 실제 문서 완성도를 높이기 위해 아래 항목들도 함께 넣는 것이 좋다.

6. 규칙은 추상 명제가 아니라 실행 문장으로 작성할 것

“명확해야 한다”, “구체적이어야 한다” 같은 선언은 맞지만 모호하다.
규칙은 가능한 한 바로 적용 가능한 문장이어야 한다.

나쁜 예:

프롬프트는 구체적으로 작성한다.

좋은 예:

프롬프트에는 최소한 목적, 대상 독자, 출력 형식, 제약 조건 중 2개 이상을 포함한다.

이처럼 규칙이 행동으로 번역되어야 실제 사용 가능성이 높아진다.

7. 예시는 규칙보다 강력하다

사람은 규칙만 읽을 때보다 예시를 볼 때 훨씬 빠르게 학습한다.
따라서 각 규칙에는 가능하면 최소 1개의 좋은 예시와 1개의 안티 패턴 예시를 붙이는 것이 좋다.

특히 예시는 아래 세 유형으로 나누면 유용하다.

• 입력 프롬프트 예시
• 기대 출력 예시
• 잘못된 출력 예시

이렇게 하면 “어떤 프롬프트가 좋은가”뿐 아니라 “어떤 결과를 유도하려는가”까지 분명해진다.

8. 규칙은 모든 상황에 동일하게 적용되지 않음을 명시할 것

좋은 규칙 문서는 강한 규정만 있는 문서가 아니다.
오히려 어디까지 적용되고 어디서부터 예외가 생기는지를 분명히 적는 문서가 더 강하다.

예:

“항상 짧게”가 아니라, “요약 응답에서는 짧게, 교육 목적 설명에서는 구조화된 상세 답변 허용”
“항상 친절하게”가 아니라, “오류 지적이나 리뷰 상황에서는 친절함보다 명확성을 우선”

이런 예외 규정이 있어야 문서가 현실적인 운영 문서가 된다.

9. 평가 기준까지 같이 정의할 것

좋은 프롬프트 규칙은 작성 원칙만 말하지 않고, 나중에 결과를 점검할 수 있는 기준도 제공해야 한다.
예를 들면 다음 질문으로 점검할 수 있다.

• 이 프롬프트는 역할이 명확한가?
• 출력 형식이 충분히 지정되었는가?
• 맥락과 목적이 드러나는가?
• 불필요하게 추상적인 표현이 남아 있는가?
• 서로 충돌하는 지시가 포함되어 있는가?
• 모델이 스스로 추정해야 하는 빈칸이 많은가?

이 기준이 있으면 규칙 문서는 정적 문서가 아니라 품질 검수 체크리스트로도 활용 가능하다.

바로 문서에 넣을 수 있는 정리본

아래는 위 내용을 바탕으로 한, 조금 더 문서형에 가까운 정리본입니다.

프롬프트 작성 규칙의 기본 원칙

프롬프트 작성 규칙은 단순한 표현 가이드가 아니라, 모델의 응답 품질과 일관성을 통제하기 위한 운영 규약이다. 따라서 규칙은 추상적 선언이 아니라, 실제 작성과 검수에 바로 적용할 수 있는 수준으로 구체화되어야 한다.

1. 페르소나를 먼저 정의한다

프롬프트에는 모델이 어떤 역할로 응답해야 하는지가 명확히 포함되어야 한다.
이때 페르소나는 역할명만 적는 것이 아니라, 전문성 수준, 대상 독자, 어조, 판단 기준, 금지사항까지 포함해야 한다.
페르소나가 분명할수록 모델의 응답은 더 일관되고 예측 가능해진다.

2. 좋은 패턴과 안티 패턴을 함께 제시한다

규칙은 선언만으로는 충분하지 않다.
각 규칙에는 바람직한 프롬프트 예시와 피해야 할 안티 패턴을 함께 제공해야 한다.
이를 통해 작성자는 무엇을 따라야 하고 무엇을 피해야 하는지를 직관적으로 학습할 수 있다.

3. 모든 규칙은 문맥과 이유를 동반해야 한다

규칙은 “어떻게 쓰라”에서 끝나면 안 된다.
왜 그 규칙이 필요한지, 어떤 상황에서 적용되는지를 함께 설명해야 한다.
같은 규칙이라도 보고용 문서, 교육용 설명, 설득용 카피, 검토용 피드백 등 맥락에 따라 적용 방식이 달라질 수 있기 때문이다.

4. 규칙 충돌에 대비해 우선순위를 정의한다

여러 규칙이 동시에 적용될 경우 충돌이 발생할 수 있으므로, 우선순위를 사전에 명시해야 한다.
권장 우선순위는 안전성, 핵심 과업 목표, 도메인 요구사항, 문맥 적합성, 페르소나와 톤, 출력 형식, 사용자 선호 순이다.
이 원칙이 있어야 프롬프트가 많아져도 일관된 판단이 가능하다.

5. 규칙은 단일 파일로 통합 관리한다

규칙이 여러 위치에 분산되어 있으면 활용성과 유지보수성이 급격히 떨어진다.
모든 규칙은 하나의 기준 문서에 통합하고, 필요 시 버전과 변경 이력을 관리해야 한다.
이 문서는 작성 가이드이자 검수 기준이며, 팀 차원의 공통 운영 문서로 기능해야 한다.

AI-Coding 도구 적용에 따른 효율화 측정 방안

조직은 크게 개발조직과 운영조직으로 나뉘어 해당 지표를 구성한다.

다만, 현재 운영조직의 측정지표 설정이 우선적이므로 해당 지표만을 상술한다.

운영조직 측정 지표

1. AI-Coding 도구 적용 전후의 운영 효율성 측정

1-1. https://youtu.be/_iDgRoeWCRg?si=PLsqX8NFdrGsy0iu

2. AI-Coding 도구 적용 전후의 코드 품질 측정

2-1. 타사 사례에서는 코드 품질을 기반으로 운영조직의 효율성 측정을 수행함을 알 수 있었다.
    2-1-1. https://youtu.be/la5GF1Dtwh8?si=KBKYaf5mlzFwRImM

2-2. 해당 지표를 적용하기는 힘들다.
    2-2-1. 어떤 코드가 앞으로 얼마나 유지보수 될지도 모르는데 전체 코드 품질 = 운영의 효율화라고 동치할 수는 없다.
    2-2-2. 운영이라는 본질에 집중하고자 한다면, 해당 지표로는 개발조직의 수장을 설득할 수 있을 수는 있어도 
            운영조직의 효율성 측정은 어렵다고 판단된다.
2-3. 따라서, 운영 효율성 측정은 개발 조직의 효율성 측정과 별도로 수행한다.

3. 주 지표로 SR 리드타임을 사용한다. 라기보다는 이거밖에 없다.

3-1. 고민을 했는데, 애자일이나 스크럼이 실버불렛이라는 상황과 현재 AI 에이전트가 실버불렛 일 수 있다는 상황을 
유추해서 해당 결론을 낼 수 있다.
한 건 업무의 시간이 유의미하게 줄어들었다.
이 접근에 대해서 샘플링도 가능하고, 특정 타겟을 정하는 것도 가능하다.

4. 보조 지표로 해당 AI도구의 사용 횟수 * 단위시간을 사용한다.

4-1. AI도구의 사용 횟수 * 단위시간을 사용하는 이유는 AI도구의 사용 횟수를 사용하면 
        AI도구의 사용 횟수에 따른 효율성 측정이 가능하다.
4-2. 사용시간만큼 사용자의 시간이 절감됨을 가정한다. 

5. 두번째 보조 지표로 AI 코드 채택율 * 단위시간 지표를 사용한다.

5-1. AI 코드 채택율 * 단위시간 지표를 사용하는 이유는 AI 코드 채택율을 사용하면 
        AI 코드 채택율에 따른 효율성 측정이 가능하다.
5-2. 이 경우 채택률 만큼 사용자의 시간이 절감됨을 가정한다.