MCP 서버를 만들며 AI가 디자인시스템 규칙을 어떤 날은 지키고 어떤 날은 통째로 무시하는 문제를 겪은 기록이다. 처음엔 "프롬프트를 더 자세히 더 많이 넣으면 나아지겠지"라고 접근했지만 그것이 정확히 반대 효과를 낸다는 것을 확인했다. 어텐션·컨텍스트 윈도우·아첨 경향이라는 세 가지 작동 원리에서 출발해 하네스를 다시 설계했고, 규칙 위반 빈도를 5번에 1~2번에서 10번에 1번 미만으로 줄였다.
핵심 포인트- 입력이 길수록 어텐션 계산량이 제곱으로 늘고 주의가 분산된다. 가이드와 자료 사이에 상관없는 내용이 끼면 관련도가 희석된다.
- "Lost in the Middle" — 중요한 지시가 입력 중간에 있으면 활용도가 떨어진다. 앞이나 끝에 둬야 한다.
- RLHF 부작용인 아첨 경향 때문에 "이 설계 괜찮지?"라고 물으면 동의로 기운다. "약점과 반례부터 찾아줘"로 물어야 한다.
- 60단어에 규칙 6개를 뭉쳐둔 지시를 원자 단위로 쪼개고 결정 소유권을 한 레이어에 고정하니 실행마다 달라지던 흔들림이 줄었다.
- 절차를 떠먹이는 대신 사후 검증 규칙셋 16개와 "완성형 → 빌딩블록 → 토큰 기반 custom → raw" 선택 사다리를 줬다.
상세 정리- 증상의 구체성: 정의된 스페이싱 토큰 대신 raw dp를 쓰거나, 디자인시스템 컴포넌트 대신 커스텀 스타일을 만들거나, 기본값 명시 여부가 실행마다 달라졌다.
- 어텐션 메커니즘: LLM은 순서대로 읽는 것이 아니라 모든 단어 쌍의 관련도를 한꺼번에 따진다. 그래서 길이가 늘면 비용이 제곱으로 오르고 정확도는 떨어진다.
- 컨텍스트 윈도우: 시스템 프롬프트·대화 이력·도구 결과·생성 중인 답이 유한한 작업 공간을 나눠 쓴다. 무엇을 올릴지가 곧 설계다.
- 아첨 경향의 근거: OpenAI가 2025년 4월 GPT-4o를 "과도하게 아첨적"이라는 이유로 롤백한 사례를 든다.
- 패러다임 전환: 한 줄을 영리하게 쓰는 프롬프트 엔지니어링에서, 모델이 볼 토큰 전체를 무엇으로 얼마나 어떤 순서로 채울지 정하는 컨텍스트 엔지니어링으로 옮겨간다.
- 모델 세대에 따른 역전: 최신 추론 모델은 단계를 스스로 나누므로 "단계별로 생각해", 과한 few-shot, 깐깐한 절차 지시가 오히려 방해가 된다.
- 두 갈래 설계: 가이드라인은 "무엇을 알아야 하는가"(규칙·컴포넌트 정의·예시), 하네스는 "어떻게 행동해야 하는가"(출력 형식 계약·검증 루프·입력 안정화)로 역할을 갈랐다.
- 원자화 이전: 아이콘 id 확인, import 추가, _fill/_line 접미사 선택 규칙이 60단어 넘는 한 문장에 뭉쳐 있어 모델이 실행마다 일부를 빠뜨렸다.
- 원자화 이후: 각 규칙을 독립 항목으로 쪼개고, 토큰 해석·간격 방출·추론 경계를 같은 레이어에서 처리하도록 결정 소유권을 고정했다.
- 검증 규칙셋: 생성된 코드를 manifest·토큰·아이콘 카탈로그와 대조한다. 예컨대 컴포넌트 검색이 비면 그럴듯한 이름을 지어내지 말고 빌딩블록이나 토큰 기반 custom으로 만들라는 식이다.
- 검증 범위의 명시: 픽셀 단위 시각 일치처럼 도구가 확정할 수 없는 영역은 검증 대상에서 빼두었다. 못 하는 것을 못 한다고 적는 것도 계약의 일부다.
- 경계를 원리로: "dp 값은 반드시 spacing 토큰으로"라고 못 박았더니 모델이 이미지 크기 108dp까지 토큰 조합으로 계산했다. "간격과 여백은 토큰, 아이콘·이미지 크기는 로우 dp"처럼 원리로 다시 썼다.
- 측정 방법: 같은 Figma 입력을 4회 반복 실행하고 산출 코드의 컴포넌트·토큰·아이콘 사용과 추론 주석 위치를 비교했다. 결과는 위반 빈도 5회 중 1~2회에서 10회 중 1회 미만으로 감소.
- 서브에이전트의 트레이드오프: 슈퍼바이저의 지저분한 컨텍스트를 정제해 하위 에이전트에 깨끗한 공간을 주는 이점이 있지만, 버린 맥락에 진짜 제약이 숨어 있으면 빠뜨린다. 어려움이 사라지는 게 아니라 "무엇을 넘기고 뺄지" 고르는 일로 옮겨갈 뿐이다.
- 적용 한계: 이 습관들은 추론이 좋은 최신 모델을 전제한다. 오래됐거나 추론이 약한 모델, 경량 모델의 하위 작업에는 few-shot과 촘촘한 절차가 여전히 유효하다.