프롬프트를 팀의 자산으로 관리하기

요지

프롬프트(생성형 AI에 입력하는 요청문)는 한 번 쓰고 버리는 메모로 다루기 쉽다. 그러나 주간 보고, 회의록, 변경요청 검토처럼 되풀이되는 일의 프롬프트는 팀이 함께 쓰는 서식과 같다. 모아 두고, 버전을 매기고, 고칠 때 테스트하고, 고친 이유를 남기면 사람이 바뀌어도 결과의 흔들림을 줄일 수 있다. 프롬프트 한 장에 무엇을 함께 적어야 다음 사람이 그대로 이어 쓸 수 있는지가 관리의 핵심이다.

그 프롬프트는 지금 어디 있나

석 달 전 잘 나왔던 주간 보고 프롬프트를 지금 찾을 수 있는가. 상조 회사 고객센터 시스템 운영 프로젝트에서 이런 일이 있었다고 하자(가상의 예). 주간 보고를 맡던 팀원이 다른 프로젝트로 옮기자, 새 담당자는 프롬프트를 처음부터 다시 만들었다. 보고서의 항목 순서가 바뀌고, 장애 건수를 세는 기준이 달라졌다. 발주처는 지난주 보고와 숫자가 맞지 않는다고 물어 왔다.

프롬프트가 개인의 대화 기록 속에만 있으면 이런 일이 생긴다. 사람에게 붙어 있던 노하우가 사람과 함께 빠져나간다.

무엇을 모을 것인가

모든 프롬프트를 모을 필요는 없다. 아래 셋 가운데 하나에 해당하면 모아 둔다.

• 같은 일을 정기적으로 되풀이한다(주간 보고, 회의록, 월간 리스크 검토)
• 결과가 발주처나 경영진에게 나간다
• 결과의 형식이 다른 문서와 맞아야 한다(지난주 보고와 비교, 리스크 관리대장 양식)

반대로 한 번 묻고 끝나는 질문, 개인이 생각을 정리하려고 쓴 프롬프트는 모으지 않아도 된다.

프롬프트 카드에 적을 것

프롬프트 본문만 모아 두면, 다음 사람은 무엇을 넣어야 하는지, 결과에서 무엇을 확인해야 하는지 알 수 없다. 본문을 포함해 아래 항목을 한 장에 적는다.

표는 가로로 밀어서 볼 수 있습니다.

채운 카드의 예

위 항목을 실제로 채우면 아래와 같은 모양이 된다(가상의 예).

• 이름과 용도: 주간 운영 보고 초안. 매주 금요일 오전, 발주처 운영 담당에게 보내는 보고의 초안을 만든다.
• 버전과 고친 날: 버전 3, 9월 20일에 고침. 버전 2에서 장애 등급 이름을 발주처 기준으로 바꿨다.
• 프롬프트 본문: 「아래 장애 처리 현황표와 변경 작업 목록만 써서 주간 운영 보고 초안을 만든다. 항목은 1) 이번 주 요약 세 줄 2) 장애 건수(등급별, 지난주와 비교) 3) 끝난 변경 작업 4) 다음 주 예정 작업 5) 발주처 확인이 필요한 사항 순서로 쓴다. 장애 건수는 현황표의 ‘종료’ 상태만 센다. 표에 없는 숫자는 쓰지 않고 ’확인 필요’라고 적는다.」
• 넣을 자료: 장애 처리 현황표(이번 주와 지난주), 변경 작업 목록
• 넣으면 안 되는 자료: 고객 이름과 전화번호가 들어 있는 상담 원문, 발주처와의 계약 금액
• 결과에서 확인할 점: 등급별 장애 건수 합계, 지난주 숫자가 지난 보고와 같은지, 「확인 필요」 표시가 남았는지
• 테스트 입력: 9월 둘째 주와 셋째 주 자료(고객 정보를 가린 버전)
• 관리 담당과 고친 이유: 운영 파트 책임자. 「장애 건수를 세는 기준을 프롬프트에 적지 않아 담당자가 바뀐 주에 숫자가 달라졌다」

프롬프트 본문에 세는 기준을 적어 둔 것이 앞의 장면에서 빠져 있던 부분이다. 카드가 있으면 담당자가 바뀌어도 숫자를 세는 기준이 흔들릴 일이 줄어든다. 다만 같은 프롬프트라도 AI의 답이 매번 똑같지는 않으므로, 결과에서 확인할 점은 여전히 사람이 본다.

고칠 때는 테스트하고, 이유를 남긴다

프롬프트를 고치게 되는 때로 세 가지를 들 수 있다. 결과가 마음에 들지 않을 때, 보고 형식이나 기준이 바뀌었을 때, 쓰는 AI 서비스의 모델이 바뀌었을 때다. 마지막 경우는 프롬프트를 한 글자도 바꾸지 않았는데 결과가 달라질 수 있어 특히 눈여겨본다.

한 AI 서비스 회사의 개발자 문서(참고 절 첫째 자료)는 프롬프트를 바꾸기 전에 대표적인 입력으로 테스트해 결과가 어떻게 달라지는지 확인하고, 쓰는 모델의 버전을 고정해 두라고 권한다. 개발자를 위한 안내지만, 팀의 프롬프트 관리에도 그대로 옮겨 쓸 수 있는 생각이다.

방법은 간단하다. 프롬프트 카드에 적어 둔 테스트 입력(지난 두 주의 자료처럼 결과를 이미 아는 것)을 고치기 전 프롬프트와 고친 뒤 프롬프트에 각각 넣고, 결과를 나란히 놓고 본다. 나아진 곳과 나빠진 곳을 적고, 수정본을 쓸지 정한다.

고친 이유 가운데 다른 프로젝트에도 쓸모 있는 것은 교훈 관리대장에 옮겨 적는다. 예를 들어 「숫자를 세는 기준을 프롬프트에 적지 않으면 담당자가 바뀔 때마다 기준이 흔들렸다」는 다음 프로젝트에도 통하는 교훈이다.

어디에 두고, 누가 고치나

프롬프트 카드는 팀원 모두가 찾을 수 있는 공용 위치에 둔다. 프로젝트 문서를 두는 곳에 폴더 하나를 따로 만드는 정도면 충분하다. 다만 카드 안에 넣으면 안 되는 자료의 예를 적을 때, 실제 자료를 붙여 두지 않도록 주의한다.

고치는 사람은 정해 둔다. 누구나 고칠 수 있으면 버전이 뒤섞인다. 카드마다 관리 담당을 한 명 두고, 다른 사람은 고칠 점을 담당에게 건의한다. 발주처에 나가는 보고서의 프롬프트처럼 영향이 큰 것은 고치기 전에 PM이 확인한다.

프롬프트 관리 확인 목록

• 되풀이되거나 밖으로 나가는 일의 프롬프트를 골라 모았는가
• 카드마다 버전, 고친 날, 관리 담당을 적었는가
• 넣을 자료와 넣으면 안 되는 자료를 프롬프트 옆에 적었는가
• 결과에서 확인할 점을 적었는가
• 결과를 이미 아는 테스트 입력을 카드에 적어 두었는가(가린 버전)
• 고칠 때 고치기 전과 뒤의 결과를 비교하고 그 기록을 남겼는가
• 쓰는 서비스의 모델이 바뀌었을 때 결과가 달라졌는지 다시 테스트하는가
• 다른 프로젝트에도 쓸 만한 교훈을 교훈 관리대장에 옮겼는가

참고

• OpenAI, 「Prompt engineering」, OpenAI 개발자 문서, https://developers.openai.com/api/docs/guides/prompt-engineering (페이지에 날짜 표시 없음, 2026년 10월 12일 확인). 프롬프트를 바꾸기 전에 대표적인 입력으로 테스트해 결과 변화를 확인하고, 모델의 버전을 고정해 두라는 생각을 따랐다. 프롬프트에 버전을 매겨 관리하는 방법은 이 자료에서 따른 것이 아니라 이 글이 보탠 것이다. 문장은 옮기지 않았다.
• 상조 회사 고객센터 시스템 운영 프로젝트 장면과 프롬프트 카드의 예는 이 글을 위해 만든 가상의 예다.