🤖
1209 in / 4208 out / 5417 total tokens
🔥 핫 토픽
Simon Willison, Claude의 <dl> 처리 능력 분석
Simon Willison이 자신의 블로그에서 Claude가 HTML <dl>(definition list) 태그를 다루는 방식에 대해 깊이 있는 분석을 올렸다. 이 글이 중요한 이유는 단순히 HTML 태그 하나의 처리 성능을 넘어, Claude가 구조화된 데이터를 어떻게 이해하고 생성하는지에 대한 핵심을 보여주기 때문이다. 게임 개발하면서 UI 마크업이나 데이터 구조를 LLM에 맡기는 일이 많은데, 이런 디테일이 실무에서 바로 체감된다.
Willison은 보통 LLM이 구조화된 출력을 생성할 때 흔히 저지르는 실수들을 정확히 짚어낸다. 예를 들어, <dl> 태그는 <dt>(용어)와 <dd>(정의)의 쌍을 유지해야 하는데, 많은 모델들이 이 짝을 놓치거나 중첩 구조를 망친다. Claude는 이 부분에서 꽤 꽤 괜찮은 성능을 보여준다는 게 그의 평가. 특히 긴 컨텍스트에서도 태그 쌍을 유지하는 능력은, 대규모 데이터 스키마나 설정 파일을 생성할 때 직접적인 차이를 만든다.
왜 이게 중요한가. 게임 클라이언트 개발자로서 XML/JSON/HTML 같은 구조화된 데이터를 LLM에 생성시키는 일은 이제 일상이다. 아이템 DB 스키마, 퀘스트 데이터, UI 레이아웃 등등. 이때 모델이 구조를 정확히 유지하는지 아닌지가, 생성 후 수동 수정에 30초 걸리느냐 30분 걸리느냐의 차이다. Claude가 이 영역에서 강하다는 건 실무적 이점이 확실하다는 뜻이다.
Anthropic이 Claude를 설계할 때 구조화된 출력에 신경을 많이 쓴 게 보인다. 경쟁 모델들도 비슷한 방향으로 가고 있지만, Claude의 "instruction following" 능력, 특히 형식 관련 지시사항에 대한 충실도가 확실히 체감된다. 이건 아마 RLHF 과정에서 코드 생성뿐 아니라 마크업/구조화된 데이터 생성에도 보상 신호를 준 게 아닐까 추측한다. 확실한 건, 게임 데이터 파이프라인에 LLM을 통합할 때 Claude는 꽤 믿을 만한 선택지라는 것.
한 가지 더. Willison은 "atom-everything"이라는 키워드도 언급하는데, 이건 모든 것을 최소 단위(atom)로 분해해서 처리하겠는 철학이다. Claude가 복잡한 구조를 다룰 때 이 원칙을 따르는지, 아니면 더 거시적인 패턴 매칭에 의존하는지는 추가적인 테스트가 필요하다. 하지만 적어도 <dl> 정도의 복잡도에서는 꽤 원자적인 처리를 하고 있는 것으로 보인다.
💡 개발자 관점에서의 분석
구조화된 출력, 왜 게임 개발자에게 중요한가
게임 서버 아키텍처를 짤 때, 데이터 기반 설계(data-driven design)는 기본이다. 아이템, 스킬, 퀘스트, 몬스터 데이터를 코드에 하드코딩하지 않고 외부 파일(XML, JSON, DataTable 등)로 관리한다. 이 작업을 LLM에 맡기면 생산성이 급상승하는데, 문제는 모델이 구조를 깨먹을 때다. 하나의 괄호가 빠지면 전체 파싱이 실패하고, 디버깅에 몇 시간을 쏟는다.
Claude가 <dl> 같은 HTML 태그를 정확히 처리한다는 건, JSON이나 XML 같은 다른 구조화된 형식에서도 비슷한 신뢰성을 보여줄 가능성이 높다는 의미다. 실제로 테스트해보면, Claude는 JSON 스키마 생성에서도 꽤 정확하다. 특히 중첩 구조(nested structure)에서 괄호 쌍을 잘 유지하는 편이다. GPT-4도 물론 훌륭하지만, 가끔 긴 출력의 끝부분에서 구조가 무너지는 걸 경험했다. Claude는 그런 경우가 상대적으로 적다.
이 차이가 미묘해 보일 수 있지만, 자동화 파이프라인에서는 치명적이다. 예를 들어, 하루에 100개의 아이템 데이터를 LLM으로 생성하는 파이프라인이 있다고 치자. 95% 정확도면 하루에 5개씩 수동 수정이 필요하고, 99%면 일주일에 5개 정도. 이 차이가 장기적으로 엄청난 공수 차이로 이어진다.
Claude의 강점과 한계
Claude가 구조화된 출력에서 강한 이유는, 아마 Anthropic의 "Constitutional AI" 접근 방식과 관련이 있을 것이다. 모델이 스스로 출력을 검토하고 수정하는 과정에서, 구조적 오류를 잡아내는 능력이 함께 훈련되는 게 아닐까. 물론 이건 추측이고, 실제로는 학습 데이터의 질이나 토크나이제이션 방식의 영향일 수도 있다.
한계도 있다. Claude는 여전히 매우 긴 출력(수천 줄 이상)에서는 구조가 흔들릴 때가 있다. 이건 아마 컨텍스트 윈도우의 한계와 관련이 있을 텐데, 앞부분의 구조를 기억하면서 끝부분까지 일관성을 유지하는 게 모든 LLM의 공통 과제다. UE5의 C++ 헤더 파일 하나가 수천 줄인 걸 생각하면, 아직 완전히 자동화하기엔 이른 감이 있다.
그래도 방향은 맞다. Claude 3.5 Sonnet 정도 되면, 꽤 복잡한 데이터 구조도 8090% 정확도로 한 번에 생성한다. 나머지 1020%를 수동으로 고치는 건, 처음부터 다 쓰는 것보다 훨씬 낫다. 특히 반복적인 데이터 작업에서는 LLM이 생성하고 human-in-the-loop로 검수하는 방식이 현실적인 최적해다.
🔮 업계 전망
이 Willison의 글이 시사하는 바는, LLM 평가의 초점이 "똑똑한 답변"에서 "정확한 구조 생성"으로 이동하고 있다는 점이다. 이건 개발자들에게 환영할 만한 변화다. 철학적 대화보다는 내 프로젝트에 바로 써먹을 수 있는 출력이 중요하니까.
Anthropic은 이 흐름을 잘 타고 있다. 최근 Claude의 업데이트들을 보면, 코딩 능력과 구조화된 출력에 집중하는 게 보인다. 이건 경쟁에서 차별화되는 포지셔닝이기도 하다. OpenAI가 범용적인 성능으로 리드하고, Google이 멀티모달에서 경쟁한다면, Anthropic은 "개발자 도구로서의 LLM"에서 강력한 대안이 되는 셈이다.
앞으로는 이런 구조화 능력이 더 중요해질 것이다. AI 에이전트가 코드를 생성하고, 데이터를 수정하고, 설정 파일을 관리하는 시대가 오면, 구조를 정확히 유지하는 능력은 필수적이다. Claude는 그 미래를 위한 꽤 괜찮은 후보다.
LLM의 진짜 실력은 뭘 아는지가 아니라, 뭘 정확히 생성할 수 있는지로 평가받는다. 구조가 무너지면 지식은 무의미하다.