AI에게 매번 똑같이 설명하다 지쳤다면: 대형 시스템 프롬프트 운영의 개념

작성자

카테고리:

같은 설명을 매번 다시 하고 있다면, 그건 프롬프트 운영이 없는 상태입니다

키움헌터v2를 만들 때 가장 비효율적이었던 순간은 복잡한 매매 로직을 짤 때가 아니라, 새 대화를 열 때마다 "이 봇은 이런 구조고, 이런 규칙을 지켜야 하고, 이건 절대 하면 안 된다"를 처음부터 다시 타이핑하던 때였습니다. 설명을 빠뜨린 날이면 AI는 멀쩡히 돌아가던 모듈을 제멋대로 뜯어고쳐 놓곤 했습니다.

AI로 무언가를 만든다고 하면 사람들은 보통 '좋은 질문 하나'를 떠올립니다. 하지만 봇처럼 여러 세션에 걸쳐 조금씩 쌓아 올리는 작업에서는, 매번 던지는 단발 질문보다 'AI가 항상 깔고 들어가는 기본 전제'를 어떻게 관리하느냐가 결과를 좌우합니다.

이 기본 전제를 한곳에 모아 둔 것이 바로 시스템 프롬프트입니다. 쉽게 말해 "너는 누구고, 무엇을 목표로 하며, 어떤 규칙과 금지선을 지켜야 하는가"를 미리 선언해 두는 설계도입니다. 개별 요청 위에 항상 겹쳐지는 배경 설정이라고 보면 됩니다.

핵심은 시스템 프롬프트가 AI를 더 똑똑하게 만들어 주는 장치가 아니라는 점입니다. 대신 AI가 매번 같은 역할과 같은 규칙 위에서 움직이도록 붙잡아 줍니다. 자동매매처럼 작은 실수 하나가 실제 주문으로 이어지는 작업일수록, 이 일관성의 가치는 커집니다.

  • 핵심 포인트 1: 시스템 프롬프트는 단발 질문이 아니라, 모든 요청에 깔리는 '기본 전제'를 한곳에 고정해 AI의 역할과 규칙을 일관되게 유지하는 장치입니다.
  • 핵심 포인트 2: 이 전제를 관리하지 않으면 세션마다 AI의 판단 기준이 흔들려, 어제 지킨 규칙을 오늘 어기는 일이 반복됩니다.

대형 시스템 프롬프트는 네 개의 층으로 쌓입니다

프롬프트가 한두 줄일 때는 운영이랄 것도 없습니다. 문제는 봇이 커지면서 지켜야 할 규칙이 수십 가지로 불어날 때입니다. 키움헌터v2를 다루며 정리한 대형 프롬프트는 크게 네 개의 층으로 나뉘었고, 각 층은 역할이 분명히 달랐습니다.

역할과 목표: 네가 누구인지 못 박기

AI에게 "너는 자동매매 봇의 코드를 책임지는 개발 파트너"라는 정체성을 먼저 심는 층입니다. 이 선언이 없으면 같은 질문에도 어떤 날은 교과서적인 일반론을, 어떤 날은 엉뚱한 범위의 참견을 돌려줍니다.

규칙과 제약: 반드시 지킬 것

코딩 컨벤션, 모듈 경계, 손대면 안 되는 파일처럼 '항상 참이어야 하는 조건'을 적어 두는 층입니다. 여기에 명시된 규칙이 많고 구체적일수록, AI가 멋대로 구조를 바꾸는 사고가 줄어듭니다.

금지선과 안전장치: 절대 하지 말 것

실제 돈이 오가는 작업에서 가장 중요한 층입니다. 검증 없이 실매매 로직을 바꾸지 않기, 리스크 한도를 임의로 넓히지 않기처럼 '넘으면 안 되는 선'을 또렷이 걸어 둡니다.

출력 형식: 어떻게 답할지

답변을 코드 블록으로 줄지, 변경 이유를 먼저 설명할지 같은 응답의 형태를 정하는 층입니다. 사소해 보여도 이 층이 흔들리면 결과를 검토하는 데 드는 사람의 시간이 크게 늘어납니다.

층 담는 내용 빠졌을 때 생기는 문제
역할·목표 AI의 정체성과 작업 목적 답변 범위가 매번 달라짐
규칙·제약 컨벤션·모듈 경계 멀쩡한 구조를 임의 변경
금지선·안전 넘으면 안 되는 선 검증 없는 실매매 변경 위험
출력 형식 응답의 형태·순서 검토 시간 증가

이렇게 층을 나눠 두면, AI가 엉뚱하게 답할 때 "어느 층이 비었거나 약했나"로 원인을 좁힐 수 있습니다. 막연히 "AI가 말을 안 듣는다"가 "금지선 층에 이 조건이 빠져 있었다"로 바뀝니다.

프롬프트가 길어질수록 생기는 함정

대형 시스템 프롬프트는 길게 쓰면 쓸수록 좋아지는 물건이 아닙니다. 키움헌터v2에서도 규칙을 욕심껏 늘렸다가 오히려 AI가 혼란스러워하는 구간을 여러 번 만났습니다. 운영 관점에서 최소한 다음 세 가지는 경계해야 합니다.

첫째, 서로 충돌하는 규칙입니다. 앞에서는 "최대한 간결하게"라고 해 놓고 뒤에서는 "모든 변경에 상세한 주석을 달라"고 하면, AI는 둘 중 하나를 버리거나 어정쩡하게 타협합니다. 규칙을 추가할 때는 기존 규칙과 부딪치지 않는지 먼저 확인해야 합니다.

둘째, 지키지 않는 규칙의 누적입니다. 한번 적어 두고 실제로는 매번 어기는 조항이 쌓이면, AI는 어떤 규칙이 진짜 강제인지 가늠하지 못합니다. 쓰지 않는 규칙은 지우는 편이 전체의 신뢰도를 높입니다.

셋째, 버전 관리의 부재입니다. 프롬프트도 코드처럼 조금씩 고쳐지는 문서입니다. 어제 버전과 오늘 버전이 어디가 다른지 남겨 두지 않으면, AI의 행동이 갑자기 달라졌을 때 원인을 추적할 길이 사라집니다. 중요한 운영 프롬프트는 날짜와 변경 사유를 함께 기록해 두는 것이 안전합니다.

이 세 가지는 프롬프트를 더 똑똑하게 만드는 요령이 아니라, 길어진 프롬프트가 스스로 무너지지 않게 떠받치는 관리 원칙입니다. 좋은 시스템 프롬프트는 분량이 아니라 일관성과 추적 가능성에서 판가름 납니다.

봇에 적용하기 전 점검 4항목

시스템 프롬프트를 본격적으로 운영하기 전에, 지금 쓰고 있는 프롬프트가 '관리되는 문서'인지 네 가지만 자문해 보시기 바랍니다.

  1. 역할·규칙·금지선이 한곳에 정리돼 있는가: 새 대화를 열 때마다 같은 전제를 다시 설명하고 있다면, 아직 프롬프트 운영이 시작되지 않은 상태입니다.
  2. 서로 충돌하는 규칙이 섞여 있지 않은가: 모순된 지시는 AI를 똑똑하게 만들기는커녕, 어느 쪽도 믿지 못하게 만듭니다.
  3. 실제 돈이 걸린 금지선이 또렷한가: 검증 없는 실매매 변경, 리스크 한도 임의 확대 같은 선은 가장 강한 표현으로 못 박혀 있어야 합니다.
  4. 프롬프트의 변경 이력이 남는가: 날짜와 사유 없이 고치면, AI의 행동이 바뀌어도 원인을 되짚을 수 없습니다.

이 네 가지 중 하나라도 비어 있다면, 그 프롬프트는 아직 '그때그때 손대는 메모'에 가깝습니다.

AI로 자동매매 봇을 만드는 일에서 시스템 프롬프트를 운영하는 작업은 좋은 질문 하나를 던지는 일과는 결이 다릅니다. 더 영리한 답을 얻기 위한 것이 아니라, 여러 세션에 걸쳐 AI가 같은 역할과 같은 금지선 위에서 흔들림 없이 움직이도록 틀을 세우는 작업입니다. 로직이 봇의 머리라면, 시스템 프롬프트는 그 머리가 매번 같은 사람으로 깨어나게 하는 기억에 가깝습니다.

이 글은 특정 전략의 수익을 보장하거나 종목을 추천하지 않으며, 자동매매는 언제든 원금 손실이 발생할 수 있습니다. 여기서 다룬 내용은 AI와 프로그래밍으로 매매 로직을 직접 만들어가는 과정을 기록·공유하기 위한 교육 목적의 개념 정리입니다.

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다