Salesforce를 위한 llms.txt 구축 — AI가 더 이상 폐기된 Apex를 작성하지 않도록

문제점: AI의 Salesforce 지식은 구조적으로 오래되었습니다

Salesforce는 일 년에 세 번의 릴리스(Release)를 진행합니다. 대규모 언어 모델(Large Language Models, LLM)은 6~18개월 전의 데이터로 학습됩니다. 따라서 영구적인 격차가 존재합니다. 모델이 Salesforce 패턴을 "알게" 될 때쯤이면, 플랫폼은 이미 다음 단계로 넘어가 있는 경우가 많습니다.

그 결과, 코드가 맞아 보이고 컴파일은 되지만, 두세 번의 릴리스 전의 패턴을 사용하는 코드가 생성됩니다. 잔인한 점은 가장 최근에 변경된 사항들 — 보안 기본값(Security defaults) 및 API 버전 — 이 모델이 가장 틀리기 쉬운 부분이라는 것입니다. 왜냐하면 이것들이 가장 최신 지식이며 학습 데이터에 반영되기까지 가장 마지막 단계에 있기 때문입니다.

Claude, GPT, Copilot에서 제가 지속적으로 목격하는 몇 가지 예시는 다음과 같습니다:

• SOQL에서의 WITH SECURITY_ENFORCED — User Mode (WITH USER_MODE)로 대체되었습니다.
• 액세스 레벨(Access level)이 없는 DML — Database.update(records, AccessLevel.USER_MODE) 대신 사용됩니다.
• System.assertEquals(...) — 레거시(Legacy) 단언(Assertion) API입니다. 현대적인 Assert 클래스(Assert.areEqual, Assert.isNull)는 Winter '23에 출시되었습니다.
• Workflow Rules / Process Builder — 둘 다 은퇴(Retired)되었습니다. 모든 것은 Flow로 처리되어야 합니다.
• 현재 버전이 v67.0임에도 불구하고 새로운 클래스에 v50대의 API 버전을 사용하는 경우.

이 중 어느 것도 생소한 것은 아닙니다. 시니어 개발자라면 코드 리뷰(Code review)에서 지적할 기본 사항들입니다. 하지만 자율적인 AI 파이프라인에는 그러한 리뷰어가 없습니다. 대신 (오래된) 사전 확률(Priors)만을 가지고 있습니다.

해결책: 에이전트에게 최신 근거(Ground truth)를 제공하십시오

llms.txt는 떠오르는 규약(Convention)입니다. 즉, AI 에이전트에게 당신의 콘텐츠를 어떻게 사용하는지 알려주는, 알려진 위치의 Markdown 파일입니다. 저는 이를 사용하여 코딩 에이전트를 정조준한 작고 주관이 뚜렷한 Salesforce 지식 베이스인 sf-llms-context를 구축했습니다.

설계 원칙:

1. 인간 중심이 아닌, AI 중심 (AI-first, not human-first). 모든 파일은 에이전트를 위한 한 줄의 지침으로 시작하며, 그 뒤에 밀도 높은 구조화된 콘텐츠가 이어집니다. 마케팅 문구나 내비게이션 UI 요소는 포함하지 않습니다.
2. 잘못된 사례와 올바른 사례를 모두 제시 (Show wrong AND right). 모든 폐기된 패턴 (deprecated pattern)은 현재 패턴 옆에 배치되며, 그 이유(거버너 제한 (governor limit) / 보안 / 폐기)를 명시합니다.
3. 토큰 효율성 (Token-efficient). 간결함 자체가 하나의 기능입니다. 모든 패턴은 최대 몇 백 토큰 이내로 구성됩니다.
4. 추측이 아닌 검증 (Verified, not guessed). 모든 거버너 제한 (governor-limit) 수치와 API 버전은 공식 Summer '26 (v67.0) 문서와 대조하여 확인합니다. (심지어 제가 API v57.0에서 Salesforce가 제거한 제한 사항을 그대로 가지고 있었던 것을 발견하기도 했습니다. 검증은 매우 중요합니다.)

이것이 실제로 출력 결과를 바꿀까요?

저는 세 가지 모델 — Opus 4.8, Sonnet 4.6, 그리고 무료 ChatGPT — 을 대상으로 통제된 테스트를 수행했습니다. 각 모델에 동일한 사용자 스토리 (user story)를 제공하되, 이 컨텍스트 파일이 있는 경우와 없는 경우로 나누어 테스트했습니다:

"Account의 Industry가 변경되면, 새로운 값을 모든 하위 Contact의 필드에 복사하세요. 테스트 코드를 포함하세요."

결과에 대해 솔직하게 말씀드리자면, 저조차 놀랐습니다. 모델들은 이미 훌륭합니다. 컨텍스트가 없는 상태에서의 모든 실행 결과는 핸들러로 위임하는 로직 없는 트리거 (trigger), with sharing, 그리고 벌키파이드 맵 (bulkified maps)을 생성했습니다. 심지어 어떤 모델은 수천 개의 하위 Contact를 가진 Account를 위해 비동기 Queueable 폴백 (async Queueable fallback)을 추가하기도 했습니다. 만약 제가 일부러 잘못된 사례를 골라냈다면, 이를 재현하려는 첫 번째 독자가 저를 잡아냈을 것입니다.

하지만 모델들을 나란히 놓고 보면 일관된 격차가 나타납니다:

모델 (컨텍스트 없음)	SOQL/DML 모드	어서션 (Assertions)
Opus 4.8	system mode	modern Assert
...

세 모델 모두 기본적으로 system-mode SOQL 및 DML을 사용했습니다 — 작업 시 FLS, CRUD 또는 공유 강제 (sharing enforcement)가 적용되지 않았습니다. Summer '26 (API v67.0)에서 보안 기본값은 User Mode입니다:

// 기본 출력 — system mode
for (Contact c : [SELECT Id, AccountId, Account_Industry__c
                  FROM Contact WHERE AccountId IN :changedIds]) { ... }
...

// 컨텍스트 파일과 함께 — 사용자 모드 (user mode)
for (Contact c : [SELECT Id, AccountId, Account_Industry__c
FROM Contact WHERE AccountId IN :changedIds
...

단순한 전/후 비교보다 테스트를 더 흥미롭게 만든 두 가지 세부 사항이 있었습니다:

• 값이 균일하지 않습니다. Opus는 요청하지 않아도 이미 현대적인 Assert 클래스를 사용합니다. 반면 Sonnet과 GPT는 여전히 System.assertEquals를 출력합니다. 모델이 오래될수록 컨텍스트(Context)의 가치는 더욱 빛을 발합니다. (부끄럽게도 제 예제들이 System.assertEquals를 사용하고 있었습니다. 즉, 콘텐츠가 레거시 스타일을 강화하고 있었던 셈입니다. 이를 수정했습니다.)

• 컨텍스트는 마법이 아닙니다. 파일을 로드했음에도 불구하고

• 단일 페치 컨텍스트 (One-fetch context, 웹 액세스가 가능한 도구): https://sf-llms-context.github.io/llms-full.txt

• 웹 액세스 불가 시 (예: 무료 버전 ChatGPT): 콘텐츠를 붙여넣거나 파일을 업로드하세요. URL만 입력하면 조용히 무시됩니다.

• 찾아보기 또는 기여하기: https://github.com/sf-llms-context/sf-llms-context

만약 사용 중인 AI 도구가 여전히 잘못된 Salesforce 패턴을 생성한다면, 이를 위한 이슈 템플릿(issue template)이 준비되어 있습니다. 그러한 피드백이야말로 릴리스(releases)가 진행됨에 따라 이 컨텍스트를 최신 상태로 유지하는 핵심 동력입니다.