온라인상의 프롬프트 엔지니어링 (Prompt engineering) 논의는 코드 생성과 RAG 파이프라인에 심하게 치우쳐 있습니다. 거의 주목받지 못하는 반복적이고 구조화된 비즈니스 작문이라는 카테고리가 통째로 존재하며, 알고 보니 동일한 원칙(명시적 역할, 근거 데이터, 정의된 제약 조건, 엄격한 출력 형식)이 똑같이 적용됩니다.

대표적인 사례가 바로 재무 변동성 분석 (financial variance analysis) 코멘터리입니다. 이는 월간 보고서에서 예산 대비 실제 실적 비교에 수반되는 짧은 서면 설명을 의미합니다. 구조적으로 이는 LLM에 매우 적합합니다. 추론 패턴(비교, 플래그 지정, 설명, 후속 질문)이 숫자만 바뀔 뿐 매 기간 반복되기 때문입니다. 또한, 이는 단순한 프롬프트가 매우 구체적이고 흔한 방식으로 실패하는 작업이기도 합니다.

실패 모드

프롬프트: "이번 달에 왜 비용이 증가했는지 설명해 주세요."

데이터도 없고, 임계값(threshold)도 없으며, 제약 조건도 없습니다. 모델은 답변의 근거로 삼을 다른 것이 없기 때문에, 유창하고 그럴듯하며 완전히 허구인 설명을 만들어냅니다. 이는 LLM에게 diff가 첨부되지 않은 커밋 메시지를 작성하라고 요청하는 것과 같습니다. 모델은 요청에 따르겠지만, 그 출력물은 아무런 의미가 없을 것입니다.

이를 해결하는 4단계 구조

1. 역할(Role) 및 대상(Audience)
페르소나(Persona)가 다르면 의미 있게 다른 결과물이 생성됩니다. "CFO를 위해" 작성하는 "재무 컨트롤러(financial controller)"는 "내부 검토를 위해" 작성하는 "스태프 회계사(staff accountant)"와는 다르게 읽힙니다. 매번 이 두 가지를 모두 명시적으로 기술하십시오. 이는 모든 에이전트 기반 설정(agentic setup)에서 역할 기반 시스템 프롬프트(role-based system prompts)의 원리와 동일하며, 페르소나의 구체성은 출력 분포를 당신이 실제로 원하는 방향으로 좁혀줍니다.

2. 근거가 되는 입력 데이터(Grounded input data)
데이터에 대한 텍스트 설명이 아니라, 실제 테이블을 붙여넣으세요. 이것은 데이터 분석 프롬프트에서 수행할 수 있는 가장 영향력 있는 단일 변화입니다. 모델이 제공받지 않은 숫자를 추론하게 만들지 마십시오. 데이터가 스프레드시트에 있다면, 관련 행을 일반 텍스트나 간단한 마크다운(markdown) 테이블로 복사하여 프롬프트에 직접 붙여넣으세요.

3. 명시적 제약 조건 (임계값 + 컨텍스트)
중요성 임계값(예: "5% 또는 $10,000를 초과하는 모든 항목에 플래그를 표시하세요")을 설정하고 알려진 컨텍스트(context)를 제공하세요. 매우 중요한 점은, 사용자가 컨텍스트를 제공하지 않았을 때 모델이 원인을 추론하는 대신 "제공된 컨텍스트 없음"이라고 명시하도록 지시하는 것입니다. 이는 RAG (Retrieval-Augmented Generation) 설정에서 환각 (hallucination)을 줄이기 위해 LLM (Large Language Model)에게 "모른다고 말하세요"라고 지시하는 것과 기능적으로 유사하며, 이를 검색 대신 구조화된 재무 추론에 적용한 것입니다.

Anthropic의 자체 프롬프팅 문서에서도 구조에 관한 관련 사항을 언급합니다. 데이터, 컨텍스트, 지침을 명확하게 분리하면(일반 레이블 또는 XML 스타일 태그 사용), 모델이 데이터와 지시 사항을 혼동하는 것을 줄일 수 있습니다. 이는 프롬프트에 전체 테이블과 서술된 노트가 포함될 때 매우 중요합니다. 참조

4. 출력 형식
정확한 구조를 지정하세요: 테이블, 번호가 매겨진 목록, 항목당 문장 수 제한 등입니다. 재무 담당자들은 숫자와 원인을 빠르게 훑어봅니다. 구조화되지 않은 긴 산문은 이 과정을 자동화하려는 목적 자체를 무색하게 만듭니다.

작동 가능한 템플릿

당신은 월간 결산 작업서(workpaper)를 위한 비용 변동 분석 노트를 작성하는 선임 회계사입니다. 대상: 보고서가 CFO에게 전달되기 전 내부 검토를 위한 컨트롤러(controller).
...

이를 실제 업무에 적용하기 전에 알아두어야 할 사항

• LLM은 계산기가 아닙니다. 모델이 수행하는 모든 산술 연산, 백분율 계산, 다단계 합계는 독립적인 검증이 필요합니다. 모델의 출력물은 새로운 기여자의 PR(Pull Request)을 다루듯, 검증되지 않은 초안으로 취급하십시오.
• 반복적이고 설명 가능한 변동 사항에는 상시 컨텍스트 블록(standing context block)이 필요합니다. 급여 지급 시기, 연간 갱신, 계절적 패턴 등은 매 주기마다 반복됩니다. 이를 설명하는 지속적인 노트가 없다면, 모델은 매번 동일한 비이상적(non-anomaly) 사항을 다시 플래그(flag)로 표시하게 되며, 이는 독자가 플래그 자체를 신뢰하지 않게 만드는 결과를 초래합니다.
• 형식의 일관성은 모델마다 유의미한 차이가 있습니다. 길고 여러 섹션으로 구성된 보고서를 대상으로 테스트한 결과, Claude는 일반적인 채팅 인터페이스보다 지정된 형식을 더 안정적으로 유지하는 경향이 있었습니다. 이는 보고서에 동일한 구조가 필요한 항목이 10개 이상일 때 유용합니다. 짧고 단일 섹션으로 구성된 보고서는 주요 도구 중 어떤 것을 사용해도 무방합니다.
• 데이터 처리 약관은 계정 등급에 따라 다릅니다. 실제 고객의 재무 데이터가 이러한 프롬프트에 입력되는 경우, 식별 가능한 내용을 붙여넣기 전에 데이터 보유 약관이 정의된 비즈니스/엔터프라이즈(business/enterprise) 등급을 사용 중인지 확인하십시오.

전체 글

저는 매출, 매출원가(COGS), 현금 흐름 변동 사항을 위한 별도의 템플릿, 도구 비교표, 그리고 전체 FAQ 섹션을 포함하여 이 내용의 더 긴 버전을 작성했습니다: AI Prompts for Variance Analysis Commentary

변동 분석에 앞서 수행되는 조정(reconciliation) 및 분류(categorization) 작업의 에이전트 기반 자동화라는 인접한 문제에 관심이 있으시다면, 해당 내용은 여기서 별도로 다루었습니다: AI Agents for Month-End Close in Small Firms

이것을 실제 파이프라인(채팅 인터페이스에 수동으로 복사하여 붙여넣는 대신, 조정된 원장(reconciled ledger) 내보내기에 의해 트리거되는 API 호출 방식)으로 구축해 본 분이 계신지 궁금합니다. 그것이 자연스러운 다음 단계이며, 이 특정 워크플로우의 프로덕션화(productionized)된 버전에 대해서는 아직 많은 글을 보지 못했습니다.