Sierra 4개월 로컬라이징, AI 코딩 에이전트의 배치 루프

Sierra engineer Stephen Burgess가 2026년 5월 28일 AI-native product localization 글에서 Agent Studio localization 사례를 공개했습니다. 약 10년 전 Slack에서 비슷한 localization 작업을 할 때는 10명 팀이 9-12개월을 썼고, 이번 Sierra 작업은 한 명의 engineer가 AI coding agents를 orchestrate해 4개월 미만으로 처리했다는 비교가 글의 출발점입니다. 숫자만 보면 생산성 사례처럼 보입니다. 개발팀이 봐야 할 부분은 더 좁습니다. Sierra는 AI agent가 대규모 code migration에서 어디를 빠르게 만들고, 어디서 다시 병목을 만드는지 구체적인 실패 경로까지 적었습니다.

이번 사례는 “AI가 번역했다”는 이야기가 아닙니다. localization 준비는 React component 안의 English text, API string, pluralization helper, concatenated string을 찾아내는 일에서 시작합니다. 이후 여러 언어를 표현할 수 있는 ICU MessageFormat으로 바꾸고, translation file을 만들고, 긴 번역문 때문에 깨지는 UI를 고칩니다. 새 string이 다시 English-only로 들어오지 않도록 lint와 CI를 붙이는 작업도 포함됩니다. Sierra 글은 Agent Studio가 English text를 코드에 직접 품고 있었고, user-facing strings가 900개 이상의 frontend files에 퍼져 있었다고 설명합니다.

Slack 비교도 과장 없이 읽어야 합니다. Sierra의 글쓴이는 자신이 Slack localization 경험을 갖고 있었고, 두 제품의 surface area와 maturity가 다르며, native speakers, internal dogfooding, human review가 계속 필요했다고 적었습니다. Sierra가 처음 지원한 locale도 Spanish와 Japanese 2개이고 4개 locale은 추가 예정입니다. 그러므로 “10명 일을 1명이 완전히 대체했다”보다 정확한 문장은 “AI agent와 batch pipeline이 coordination overhead를 크게 줄였지만, quality review와 architecture decision은 남았다”입니다.

Sierra가 처음 택한 방식은 IDE agent였습니다. Cursor에 individual files를 localization-ready로 바꿔 달라고 요청했습니다. 결과 품질은 좋았지만 workflow가 blocking and sequential이었다고 합니다. 큰 codebase에서 한 파일씩 처리하는 방식은 사람이 agent 옆에 계속 붙어 있어야 합니다. 900개 이상의 frontend files가 대상이면, prompt를 잘 쓰는 능력보다 queue를 어떻게 만들고 review를 어떻게 묶느냐가 먼저 문제가 됩니다.

두 번째 방식은 cloud agents였습니다. 여러 agent가 여러 파일을 동시에 다루면 throughput은 바로 올라갑니다. Sierra가 공개한 문제는 tracking mistakes at scale입니다. agent는 대체로 string wrapping을 잘했지만, concatenated strings를 잘못 다루거나, ICU syntax를 미묘하게 틀리거나, variable 주변 possessive 표현을 어색하게 만드는 작은 오류가 남았습니다. 각 agent가 자기 pull request를 만들면서 또 다른 review queue가 생겼습니다. 혼자 일하는 engineer에게는 병렬성이 review 대기열로 되돌아온 셈입니다.

Sierra가 정착한 세 번째 방식은 Claude API를 직접 호출하는 batch script였습니다. script는 file list 또는 glob pattern을 받고, 각 file을 localization skills documentation과 함께 API에 보내고, configurable concurrency로 결과를 disk에 씁니다. 이 구조는 agent UI를 우회합니다. 사람이 매번 대화창을 열고 파일을 지정하는 대신, migration을 반복 가능한 transformation pipeline으로 바꿉니다. Sierra는 약 30개 파일씩 batch를 돌리고, batch마다 모든 changed file을 수동 review했습니다. 모델이 대체로 맞더라도 틀렸을 때 pattern을 빨리 잡아야 했기 때문입니다.

이 사례에서 눈에 띄는 부분은 agent output보다 review 단위입니다. Sierra는 batch마다 모든 changed file을 사람이 봤습니다. 이유는 단순합니다. AI가 틀릴 때 개별 파일의 한 줄만 틀리는 것이 아니라 같은 pattern을 다음 수백 파일에 반복할 수 있습니다. localization migration에서는 i18n.t()로 감싸는 기계적 변경보다 sentence order, pluralization, variable interpolation, translator context가 더 어렵습니다. batch size를 약 30개로 잡은 것은 throughput과 failure containment 사이의 운영 선택입니다.

Sierra는 review 뒤에 mistake를 모으고, agent에게 왜 발생했는지 설명하게 한 다음, skills documentation에 명시적 지침을 추가했습니다. 이 과정은 AI coding agent를 “한 번 실행하는 도구”가 아니라 feedback loop의 한 구성요소로 쓰는 방식입니다. 사람이 failure pattern을 분류하고, agent가 원인을 설명하고, 문서가 바뀌고, 다음 batch가 그 문서를 읽습니다. 결과적으로 migration pipeline 자체가 학습 대상이 됩니다. 모델 weights를 바꾸는 것은 아니지만, project-specific instruction과 lint rule이 점점 좁아집니다.

Linter 부분은 별도 뉴스 가치가 있습니다. Sierra는 user-facing string이 t()로 감싸져 있지 않으면 flag하는 linter rule을 만들었습니다. 이 rule 자체도 AI가 많이 작성했습니다. engineer가 원하는 behavior를 설명하면 agent가 rule을 생성하거나 수정했고, iteration loop가 빨라져 거의 real time으로 다듬을 수 있었다고 합니다. 이후 workflow는 linter 실행, flagged files batch 처리, 다시 linter 실행, 남은 warning 조사로 고정됐습니다. 남은 warning 중 일부는 실제 migration miss였고, 대부분은 false positive였습니다.

여기서 migration pipeline과 linter가 서로를 검증합니다. linter가 놓친 pattern은 batch migration의 결함을 드러내고, batch 결과가 만든 이상한 warning은 linter의 false positive를 드러냅니다. Sierra는 두 시스템이 독립적으로 완벽하지 않았지만 함께 쓰면 file이 localization-ready인지 판단하는 신호가 강해졌다고 설명합니다. 개발팀이 가져갈 교훈은 “AI에게 lint rule도 맡겨라”가 아닙니다. static analysis, codemod, agent transformation을 같은 loop 안에 두면 AI output을 사람이 일일이 기억하지 않아도 recurring failure를 줄일 수 있다는 점입니다.

가장 실무적인 실패는 context window에서 나왔습니다. Sierra는 Cursor로 돌아가 linter edge case와 skills documentation을 계속 다듬는 과정에서 error rate가 다시 올라갔다고 적었습니다. 더 이상한 점은 이미 skills file에 금지된 pattern이 다시 나왔다는 사실입니다. 원인은 documentation이 너무 커진 것이었습니다. agent가 실패를 발견할 때마다 verbose explanation과 큰 code example을 넣었고, 어느 순간 interactive Cursor session이 문서 전체를 안정적으로 처리하지 못했습니다. 문서 앞부분은 읽고 뒤쪽 instruction은 조용히 놓치는 문제가 생겼습니다.

이 대목은 AGENTS.md, Cursor rules, Claude Code skills, Copilot instructions를 쓰는 팀에게 직접적입니다. instruction file은 길수록 좋아지지 않습니다. 실패 사례를 다 넣으면 사람이 보기에는 친절하지만 agent에게는 retrieval 부담이 됩니다. Sierra의 fix는 문서를 더 짧게 쓰고, examples를 줄이고, 한 줄당 signal을 높이는 것이었습니다. 또한 하나의 거대한 문서 대신 panels-and-typing, what-not-to-translate처럼 focused files로 나눴습니다. agent가 모든 규칙을 항상 읽는 구조가 아니라 작업 종류에 맞는 작은 파일을 선택해 읽는 구조입니다.

batch script와 interactive session의 차이도 분명합니다. batch script는 file마다 stateless API call을 만들 수 있습니다. 같은 compact instruction과 현재 file을 넣고 결과를 받습니다. 반면 Cursor 같은 interactive session은 conversation history, tool result, file read가 turn을 거치며 쌓입니다. 이 상태에서 긴 skills docs를 계속 붙이면 중요한 rule이 context 안에 있어도 모델이 안정적으로 쓰지 못할 수 있습니다. Sierra 사례는 “context를 많이 넣으면 agent가 더 잘한다”는 단순한 믿음을 깨는 현장 보고입니다.

string description 설계도 제품팀이 볼 만합니다. localization에서는 “close”가 dialog를 닫는 뜻인지, session을 종료하는 뜻인지, 거리상 가까움을 뜻하는지 translator가 알아야 합니다. Slack에서는 @i18n comment를 source code 위에 두고 extraction 때 translation file로 가져갔다고 합니다. Sierra도 처음에는 같은 방식을 따랐고, AI가 comment를 빠르게 생성했습니다. 하지만 comment가 너무 verbose해져 UI files를 읽기 어려워졌습니다. 사람이 거의 읽지 않는 metadata가 source code를 점유하는 문제가 생겼습니다.

Sierra의 해법은 description을 code에 영구 저장하지 않는 방식이었습니다. extraction 단계에서 각 string의 file location과 source position을 기록하고, 후속 enrichment step이 주변 code window를 Claude에 보내 contextual description을 생성합니다. description은 application code 옆이 아니라 translation files에 저장됩니다. AI가 description을 만들고 AI translation model과 translator가 그것을 소비한다면, 사람이 매일 읽는 component file에 그 metadata를 붙일 이유가 줄어듭니다. 이것은 AI-first workflow가 source code layout까지 바꿀 수 있다는 작은 사례입니다.

이 글이 AI coding agent 시장에서 중요한 이유는 제품 이름보다 운영 패턴에 있습니다. 최근 도구들은 “agent가 PR을 만든다”, “cloud에서 병렬 실행한다”, “review comment를 수정한다”를 경쟁적으로 말합니다. Sierra 사례는 그다음 질문을 보여줍니다. agent PR이 많아지면 누가 review queue를 줄이는가. 실패 pattern은 어디에 기록되는가. instruction file이 커질 때 누가 줄이는가. linter와 CI는 agent output을 어떤 단위로 검증하는가. 사람이 확인해야 할 locale nuance는 어디서 걸러지는가.

비용도 token price만으로 보이지 않습니다. IDE agent에서 cloud agents로 넘어가면 병렬 실행 비용이 생기고, cloud agents가 만든 pull request는 review 비용을 만듭니다. API batch script는 UI overhead를 줄이지만, concurrency와 retry를 설계해야 하고, 잘못된 instruction이 들어가면 같은 오류를 빠르게 확산시킬 수 있습니다. Sierra는 batch마다 사람이 모든 changed file을 봤습니다. 이 human review 비용을 숨기면 AI migration의 경제성은 과장됩니다. 반대로 review 단위를 잘 설계하면 한 명이 감당할 수 있는 migration surface가 커집니다.

개발팀이 바로 가져갈 checklist는 네 가지입니다. 첫째, migration을 agent chat이 아니라 batchable transformation으로 정의합니다. 둘째, batch size를 정하고, pattern failure가 퍼지기 전에 멈출 review gate를 둡니다. 셋째, instruction file은 실패를 추가할수록 길어지는 문서가 아니라 선택적으로 읽히는 작은 playbook 묶음으로 관리합니다. 넷째, AI output을 다시 AI로 검사하는 데서 멈추지 말고 linter, CI, human review를 함께 둡니다. Sierra가 공개한 성공은 이 네 가지가 맞물린 결과입니다.

한계도 기사에서 지워서는 안 됩니다. Sierra 글은 native speakers와 human review가 필요했다고 명시합니다. 덜 방문되는 화면에는 untranslated string이 숨어 있을 수 있다고도 적었습니다. language nuance, overall UX correctness, locale별 문화적 기대는 agent가 혼자 닫을 수 있는 영역이 아닙니다. localization은 code migration과 product quality가 겹치는 일입니다. AI가 string wrapping과 반복 변환을 빠르게 해도, 실제 사용자 언어 경험은 사람이 확인해야 합니다.

Sierra 사례는 AI agent가 개발자를 없앴다는 증거가 아닙니다. 오히려 senior engineer의 역할이 더 선명해진 사례입니다. 어떤 작업을 batch로 묶을지, 어떤 failure를 pattern으로 볼지, 어떤 instruction을 줄일지, 어떤 metadata를 source code 밖으로 뺄지, 어느 warning을 false positive로 판단할지 모두 engineer의 결정입니다. AI가 실행 비용을 낮추자, 반복 작업을 직접 하는 시간은 줄었습니다. 대신 migration system을 설계하고, 검증하고, 실패에서 규칙을 뽑는 일이 중심이 됐습니다.

그래서 이 뉴스의 결론은 “AI로 localization을 빨리 하자”가 아닙니다. 더 정확한 결론은 “대규모 migration은 agent UI 경쟁보다 batch loop, review gate, compact instructions, static analysis가 성패를 가른다”입니다. Sierra는 이를 Agent Studio localization이라는 실제 제품 작업에서 공개했습니다. 코딩 에이전트를 도입한 팀이 다음에 부딪힐 문제도 비슷할 가능성이 높습니다. 모델이 파일을 고치는 순간보다, 고친 파일 30개를 어떤 evidence로 받아들일지가 더 어려워집니다.