AI 에이전트의 시스템 프롬프트(System Prompt)에는 보통 '무엇을 할 것인가'를 적습니다. 우리는 그곳에 '어떤 엔지니어가 되어야 하는가'를 대량으로 적었습니다.

이 기사는 20대 대상 커뮤니티 'Coelia'의 운영 기반(Web 서비스, HP, 콘텐츠 생산)을 Claude Code / Codex 등의 AI 에이전트로 거의 자율 운용하고 있는 개발 현장에서, 시스템 프롬프트에 '마음가짐'을 계속 주입해 온 약 1개월간의 실록입니다. 무엇을 적었는지, 그리고 실제로 에이전트의 거동이 어떻게 변했는지를 기술합니다 (사내 설계 기록인 ADR이나 PR을 근거로 하고 있으나, 리포지토리는 비공개이므로 번호는 밝히지 않고 내용을 본문에서 자기 완결적으로 다룹니다).

왜 '마음가짐'을 프롬프트에 적는가

출발점은 리포지토리의 AGENTS.md

(모든 에이전트 공통의 시스템 프롬프트 상당)에 적은 이 한 문장입니다.

생성 AI는 '세상의 표준적인 답변'을 최단 거리로 반환하는 도구일 뿐이다 ── 브랜드 이해와 KPI에 대한 해상도가 낮은 상태로 사용하면, 평균점에 머무는 양산형(템플릿 느낌, AI Slop)으로 전락한다.

태스크의 절차를 아무리 정밀하게 적어도, 에이전트는 '시킨 일을 그럴싸하게' 수행합니다. 문제는 시킨 일이 틀렸을 때, 혹은 시키지 않은 것이 중요할 때 아무렇지 않게 밀고 나간다는 점이었습니다. 절차가 아닌 판단 축을 주지 않으면 실무에서는 쓸모가 없습니다. 그래서 인간 엔지니어에게 요구되는 자질을 그대로 프롬프트화하는 방침을 세웠습니다.

실제로 기입한 4가지 기둥

1. Renaissance Developer (시스템 사고 · 오너십 · 폴리매스)

클라우드 사업자의 CTO가 말하는 '앞으로의 엔지니어상'에 관한 논의를 바탕으로, 우리만의 언어로 3가지로 압축하여 명문화했습니다 (원 발언의 1차 소스는 사내 기록에 남아 있지 않아, 출처로서는 미확인 상태입니다. 아래 내용은 우리의 정의로 읽어주세요).

시스템 사고 (System Thinking): 1개의 변경이 어느 레이어 · 테스트 · 로그 · 운용으로 파급되는지 조망하며 국소 최적화를 피한다 -
오너십 (Ownership): AI 생성 코드라도 최종 품질과 결과에 책임을 진다. "아웃풋(만든 것)은 아웃컴(KPI가 움직인 것)의 필요조건일 뿐이다" -
폴리매스 (Polymath): 기술적 올바름에 더해, 사용자 측면(사용하고 싶은가) × 운영 측면(운용하기 쉬운가)의 두 축으로 판단한다

2. 에이전트 메타 인지 (4가지 관점의 상시 유지)

'작업 대상뿐만 아니라, 자기 자신 · 의뢰의 문맥 · 시스템의 현황 · 기대 아웃컴을 객관적으로 바라보며 움직이라'는 지시입니다. ①시스템 ②의뢰 ③자신 ④아웃컴,의 4가지 관점을 유지하고, 승인을 요청하기 전과 완료 보고 전에 자기 평가를 수행하게 합니다. 이는 ADR로서 정식 채택되었습니다 (coelia-system ADR 0058).

3. 지시를 액면 그대로 믿지 않기 ('구현하기' 전에 '검증하기')

의뢰된 수단이 곧 해결해야 할 과제는 아니라는 규율입니다. 지시 내용과 목적 자체를 착수 전에 객관적으로 재평가하고, 의문 · 대안 · 누락 사항은 마음대로 대응하지 않고 확인합니다. 단, 과도한 이의 제기나 마음대로 스코프를 확장하는 것도 재작업을 유발하므로, 리스크에 비례하여 교정합니다 (ADR 0026).

4. 접지 프로토콜 (생성하기 전에 먼저 전제를 확인하기)

'생성이 먼저, 접지가 나중'인 것이 최대의 실패 원인임을 깨닫고, 착수 전 7단계(전제의 PAC 분해 → 접지 → 수단을 의심하기 → 생성 게이트 → 확인 → 아웃컴 확인 → 교훈의 전파)를 필수화했습니다. 이는 별도의 기사에서 자세히 다루겠습니다.

그래서, 실제로 어떻게 변했는가

이 부분이 본론입니다. 마음가짐 주입 전후로 PR의 내용이 눈에 띄게 변했습니다.

먼저 검증 범위를 적어둡니다. 대조 실험은 하지 않았습니다 (동일한 과제를 마음가짐이 있을 때와 없을 때로 나누어 비교하지 않음). 아래는 전후로 관측된 거동의 예시이며, '이 마음가짐을 넣으면 품질이 몇 % 올라간다'는 정량적 수치는 미검증 상태입니다. 셀 수 있는 것은 후술할 토큰량과 게이트 통과 상황뿐입니다.

변화 1: '시킨 대로 만들기'에서 '데이터로 의뢰를 재정의하기'로

마음가짐 주입 후의 HP 리포지토리에는 다음과 같은 규율이 작동하기 시작했습니다.

의뢰된 수단이 곧 해결해야 할 과제는 아니다. 수단을 목적으로 되돌리고, 재정의의 근거는 추론뿐만 아니라

셀 수 있는 것을 세어서 가져온다 (GA4 / GSC / 공개 HTML의 실제 출현 수). 데이터가 의뢰와 다른 과제를 가리킨다면, 구현보다 먼저 차이(diff)를 도출한다.

실례로, 계측 화면 개선을 의뢰했을 때 에이전트가 구현에 들어가기 전 퍼널 정의(Funnel Definition) 자체의 모순을 지적한 적이 있습니다. "이 정의대로라면 회유(Circulation)가 회유를 설명하는 동의어 반복(Tautology)이 되어 의사결정에 사용할 수 없다", "관심도를 측정해야 할 이벤트가 계측되지 않고 있다"라고, 의뢰받은 화면을 만들기 전에 말하는 것입니다. 이전에는 나타나지 않았던 움직임입니다.

변화 2: "만들지 않는 안"이 비교표에 올라오게 되었다

시스템 프롬프트(System Prompt)에 다음과 같이 작성했습니다.

안에는 "만들지 않는 안"을 반드시 하나 나란히 두어 비교할 것 (원천 측에서 수정 · 기존 메커니즘이나 운용으로 해결 · 애초에 내보내지 않음). 비교 축은 초기 비용이 아니라

운용과 유지보수의 지속 비용.

이를 넣은 뒤부터 기능 추가 제안이 "채택안 · 기각안 · 기각 이유"의 3종 세트로 나오기 시작했습니다. CI 러너(CI Runner)를 외부 서비스로 이전하는 것을 검토했을 때, 에이전트가 스스로 과금과 실행 시간을 측정한 후 "이전하지 않음"을 결론으로 내놓았습니다. AI에게 "만들지 마라"는 판단을 시킬 수 있게 된 것이, 마음가짐 주입을 통해 얻은 가장 큰 변화입니다 (단, 앞서 언급했듯이 비교 실험을 통한 뒷받침은 없습니다).

변화 3: 자신의 완료 보고를 신뢰하지 않게 되었다

"자신의 자기 신고만으로 확정되지 않는다", "더블 체크는 반드시 독립된 서브 에이전트(Sub-agent)가 수행한다"라는 규율을 넣은 뒤로, 에이전트는 자신의 성과물을 독립된 별도의 컨텍스트를 가진 리뷰어에게 통과시킨 후 머지(Merge)하게 되었습니다. 셀프 리뷰 과정에서 장부의 회계 처리 · 리마인드 전송 · 멤버 감사라는 세 곳의 버그를 스스로 찾아내 수정하는 등의 움직임이 상시화되었습니다.

변화 4: 실패가 "학습"으로서 리포지토리(Repository)에 퇴적되게 되었다

"아웃풋 · 학습은 Git 관리 영역으로 착지시킨다"라는 규율의 효과입니다. 동영상 업로드가 6개 경로 모두 실패한 기록("브라우저를 통한 동영상 업로드 불가 (6개 경로 실측)")과 같은 **실패의 실측 로그가 PR(Pull Request)로서 커밋(Commit)**되게 되었습니다. 다음 세션의 에이전트는 같은 실패를 반복하지 않습니다.

효과가 없었던 것 · 부작용

좋은 점만 있었던 것은 아닙니다.

쓰면 쓸수록 상시 로드(Load)가 무거워진다. 마음가짐을 계속 추가한 결과, 시스템 프롬프트의 고정비(매 세션 읽어들이는 토큰량)가 팽창하여 오히려 에이전트의 집중력을 깎아먹기 시작했습니다. 이에 대한 대책으로 "genshijin식 토큰 압축" (ADR 0068)이나 "상시 로드 예산"이라는 메커니즘이 탄생했으며, 입력 파일을 31.5% 절감하는 재구성까지 하게 됩니다 (이 이야기는 별도 기사에서 다루겠습니다).

"만약을 위해 재확인해줘" 계열의 지시는 역효과. 최신 모델(Claude Opus 5세대 이후)은 기본적으로 자기 검증을 수행하기 때문에, "마지막에 검증 단계를 넣는다", "중대한 문제만 보고한다" 형태의 지시를 추가하면 기본 동작과 중복되어 오히려 보고가 줄어드는 현상을 겪었습니다. 현재는 "추가하지 말아야 할 지시"로 명문화하고 있습니다.

마음가짐은 한 번 쓴다고 정착되지 않는다. 모델이나 하네스(Harness)의 업데이트로 동작은 변합니다. 그래서 마음가짐 자체도 ADR · 리뷰 학습 · 실패 패턴 모음으로서 버전 관리하며, 실측을 통해 계속 개정하는 운용 방식을 택했습니다.

요약: 프롬프트는 "절차서"에서 "행동 강령"으로

약 1개월 · 3개 리포지토리 · 수백 건의 PR을 통해 얻은 결론은 다음과 같습니다.

AI 에이전트를 "빠르기만 한 작업자"에서 "믿고 맡길 수 있는 동료"로 가깝게 만드는 가장 빠른 길은, 도구의 설정도 모델의 교체도 아닌, 인간 엔지니어에게 요구해 왔던 자질을 명문화하여 프롬프트에 다 써 내려가는 것이었습니다.

이 시리즈에서는 접지 프로토콜(Grounding Protocol) · 적대적 검증 · 토큰 압축 · 실패 패턴 진단 · CI 비용 규율 · 모델 라우팅 · 루프 엔지니어링을 각각 실측 데이터와 함께 깊이 있게 다룰 예정입니다.

커뮤니티 운영과 커리어 설계 관련 발신은 obata-tomu.jp/articles 에 있습니다.

Discussion