피그마 링크 하나만 받기로 하자 번역 도구가 쓸 만해졌어요

장바구니 화면 하나에는 번역할 문구가 79개 있어요.

올해 초까지 이런 화면에 번역을 올리려면 79개 문구를 하나씩 번역 관리 웹페이지로 옮겨야 했어요. 피그마에서 문구를 복사하고, 웹페이지에서 이미 있는 키인지 검색하고, 없으면 등록 폼을 채우고. 다시 피그마로 돌아가 다음 문구를 복사하고요.

개발자도 같은 웹페이지를 오갔어요. 화면을 구현하다가 문구가 나오면 웹페이지에 들어가 그 문구를 검색해서 키를 찾았어요. 같은 화면을 두고 한쪽은 키를 등록하느라, 한쪽은 키를 찾느라 피그마와 웹페이지 사이를 계속 오간 거예요.

번역 관리 시스템은 서버 개발자의 웹페이지였어요

번역 관리 시스템은 앱과 웹에 나가는 문구를 번역 키로 관리하는 사내 시스템이에요(이 글에서는 줄여서 번역 시스템이라고 부를게요). 한국어 문구를 키로 등록하면 번역가가 다른 언어를 채우고, 앱과 웹은 그 키로 문구를 받아 가요. 서버 개발자가 만들고 관리하는 웹페이지라, 화면도 데이터를 넣고 고치는 관리 도구에 가까웠어요.

그런데 저희가 실제로 일하는 곳은 피그마예요. 기획과 디자인이 피그마에서 화면을 만들고, 개발자는 그 화면을 보며 코드를 짜요. 문구는 피그마에 있는데 키는 웹페이지에 있으니, 둘을 잇는 일은 사람이 손으로 할 수밖에 없었어요.

그래서 도구를 만들었어요, 네 번이나

그 번거로움을 줄이려고 프론트엔드 팀이 만든 도구는 이래요.

• 3월, 피그마 플러그인. 텍스트 레이어를 고르면 번역 키를 검색해 주고, 클릭하면 그 키를 레이어에 붙여요. 페이지를 훑어 키가 안 붙은 문구를 CSV로 뽑을 수도 있었어요.
• 4월, CLI. 등록, 수정, 승격 같은 번역 시스템 API를 명령으로 감쌌어요. 웹페이지에서 폼을 채우던 일을 터미널 한 줄로 했어요.
• 7월, 데스크톱 앱. 플러그인이 내보낸 문구 목록을 받아 번역 시스템에 한꺼번에 등록하는 앱이에요. 이때 키를 판단하는 엔진도 따로 뗐어요. 문구가 똑같은 키가 있으면 그걸 쓰고, 규칙으로 못 정한 것만 LLM에게 물어요.
• 9월, MCP. CLI 명령을 MCP 툴로 열어서 "이 문구 등록해 줘"를 말로 시킬 수 있게 했어요. 10월에는 데스크톱 앱에 채팅 탭까지 붙였어요.

하나하나는 다 쓸모가 있었어요. 79번 폼을 채우던 일이 플러그인과 앱으로 한 번에 끝나게 됐으니까요. 뒤에 쓰겠지만 이것들은 지금도 그대로 돌고 있어요.

그런데 돌아보면 전부 같은 질문에 대한 답이었어요. 번역 시스템의 등록 API, 수정 API, 승격 API를 어떻게 하면 더 편하게 부를 수 있을까. 웹 폼 대신 명령으로, 명령 대신 버튼으로, 버튼 대신 말로. 부르는 방법은 점점 편해졌지만, 부르는 사람이 번역 시스템이 어떻게 생겼는지 알아야 한다는 건 그대로였어요.

말로 시킬 수 있게 된 MCP도 그랬어요. "등록해 줘"라고 말하려면 먼저 무엇을 등록할지 알아야 하잖아요. 화면에서 번역할 문구를 골라내고, 이미 있는 키와 겹치는지 보고, 숫자나 아이콘처럼 번역하지 않을 걸 빼는 일. 그건 여전히 사람이 했어요. 정작 제일 귀찮은 일이 사람 손에 남아 있었던 거예요.

제품 조직 입장에서 보면 더 그랬을 거예요. 기획자는 dev 리소스가 뭔지, 승격과 릴리스가 왜 다른 단계인지 알 이유가 없어요. 그런데 저희는 기능이 하나 생길 때마다 그걸 이해시키려고 애썼어요. dev에 먼저 넣고, 승격하고, 번역을 요청하고, 끝나면 릴리스하고. 이 순서를 알아야 도구를 쓸 수 있게 만들어 놓았으니까요.

기획자는 이미 피그마를 들고 있었어요

발상을 뒤집은 건 이 질문이었어요. 이걸 쓸 사람은 하루 대부분을 어디서 보내지?

제품 조직은 피그마에서 일해요. 번역할 문구도 이미 거기 다 있어요. 그렇다면 그들이 도구에 줘야 할 건 피그마 링크 하나면 충분해요. 어떤 문구를 번역할지, 그게 기존 키인지 새 키인지, dev에 먼저 넣어야 하는지 같은 건 그들이 알 필요가 없는 일이에요. 몰라도 되는 걸 화면에 보일 이유도 없고요.

그래서 다섯 번째 도구인 번역 데스크톱 앱은 이렇게 쓰게 만들었어요. 기획자는 피그마에서 섹션 링크를 복사해 앱에 붙여 넣어요. 앱이 보여 주는 카드 몇 장을 넘기고 「피그마에 등록」을 눌러요. 기획자가 하는 일은 이게 전부예요.

처음에 말한 장바구니 화면을 넣어 봤어요. 문구 79개 중 기획자가 직접 확인한 카드는 13장이었어요.

링크를 붙여 넣으면 안에서는 이런 일이 일어나요

기획자 눈에는 링크 칸과 카드 몇 장이 전부예요. 그 뒤에서는 이런 순서로 일이 돌아가요.

flowchart TD
  A[피그마 링크] --> B[문구 읽기]
  B --> C[규칙으로 판단]
  C -->|못 정한 문구| D[LLM으로 판단]
  C --> E[확인 카드]
  D --> E
  E --> F[피그마에 등록]

1. 피그마에서 문구를 읽어요

링크한 섹션에서 화면에 보이는 문구만 모아요. 숨긴 레이어나 프레임 밖에 적어 둔 설명은 빼요. 번역 시스템의 키 목록도 이때 같이 받아요.

2. 규칙이 먼저 판단해요

판단 엔진이 문구마다 이런 것들을 차례로 따져요.

1. 번역하지 않아도 되는 문구인가 (숫자, 시각, 아이콘)
2. 예전에 정해 둔 키가 있나
3. 문구가 똑같은 키가 있나
4. 값만 다른 템플릿 키가 있나
5. 조금만 다른 비슷한 키가 있나

예를 들면 이래요.

피그마 문구	판단
28,500원	숫자는 코드에서 만들고, 원만 단위 키를 써요
8/29(목) 도착 예정	기존 템플릿 키에 값 세 개로 맞아요
40,000KRW 결제하기	띄어쓰기만 다른 키가 있어서 카드로 물어요

3. 남은 것만 LLM이 판단해요

규칙으로 못 정한 문구만 LLM에게 보내요.

LLM의 답은 엔진이 한 번 더 검사해요. 통과하지 못하면 다시 묻고, 그래도 안 되거나 확신이 낮으면 카드로 넘겨요.

4. 사람은 카드만 봐요

카드에는 프레임 사진이 있고, 문구 자리에 빨간 테두리가 그려져 있어요. 결론 한 줄과 고를 것이 있고, 기본값은 미리 골라 둬요.

카드로 묻는 건 기획자가 판단할 수 있는 것뿐이에요. 「원」이냐 「KRW」냐, 기존 키를 고쳐 쓸지 새로 만들지 같은 것들이요. 태그, 줄바꿈, 서버 문구처럼 개발자가 정할 일은 「개발 확인 필요」로 적어서 넘겨요.

5. 「피그마에 등록」을 누르면

새 키는 개발용 키로 등록돼요. 텍스트 레이어마다 키 링크가 붙고, 새 키에는 화면 사진이 예시로 함께 올라가요. 중간에 앱이 꺼져도 다시 켜면 남은 단계부터 이어요.

6. 운영에 올리고 배포하는 건 다른 탭에서 해요

등록한 키는 「개발용 언어팩」 탭에 쌓여요. 개발자가 「개발 확인 필요」 항목을 보고 「운영에 올리기」를 누르면 운영 승격과 번역 요청이 한 번에 돼요. 번역이 끝나면 제품 조직이 「운영용 언어팩」 탭에서 「배포」를 눌러요.

새로 만든 기능은 거의 없어요

이 앱을 만들면서 새로 만든 기능이 거의 없다는 게 저희에게는 제일 큰 발견이었어요.

피그마 문구를 읽는 건 플러그인 때부터 하던 일이고, 키를 판단하는 엔진은 7월에 떼어 둔 걸 그대로 가져왔어요. 번역 시스템에 등록하는 건 CLI가 부르던 API예요. 채팅 탭은 MCP를 붙인 거고요. 새로 짠 건 대부분 이것들을 잇는 배관과, 사람에게 무엇을 보이고 무엇을 감출지 정하는 화면이었어요.

기능은 이미 다 있었어요. 없었던 건 쓰는 사람의 자리에서 그 기능들을 엮은 순서였어요.

이런 API가 생겼으니 이렇게 쓰세요, 이 명령은 이럴 때 쓰세요. 그동안 저희가 한 말은 대부분 이런 식이었어요. 그런데 기획자에게 필요한 건 API가 아니라 "이 화면 번역 올려 주세요"가 끝나는 거였어요.

감추는 데 시간을 제일 많이 썼어요

링크만 받고 나머지를 감추겠다고 정하자, 할 일이 생각보다 많았어요. 대부분 '무엇을 안 보일지'를 정하는 일이었어요.

시스템 용어를 지웠어요

번역 시스템 안에는 저장소가 셋 있어요. dev 리소스, 운영 수정 대기분, 운영 배포본. 키를 옮기는 단계에도 승격, 릴리스 같은 이름이 붙어 있고요. 전부 개발자가 시스템을 만들면서 붙인 이름이에요. 제품 조직이 알아야 할 이유가 없는 말이고, 안다고 해도 어려워요.

그래서 화면의 말을 바꿨어요. 운영은 「서비스 중인 키」, 운영 대기는 「배포 전 키」, dev는 「개발용 키」. 승격은 「운영에 올리기」, 릴리스는 「배포」가 됐어요. 카드도 키 이름과 저장소 이름을 나열하는 대신 결론 한 줄로 시작하게 했어요. 「기존 키(delivery_day_desc)를 쓸 수 있어 보여요.」처럼요.

위험한 버튼은 아예 안 보여요

피그마 작업 화면에서 번역 시스템에 쓸 수 있는 건 정해져 있어요. dev 등록, 이번 작업에서 만든 dev 키의 문구 고치기, 예시 사진 올리기. 이 세 가지뿐이에요. 운영 승격이나 릴리스는 이 화면에서 부를 수 없게 막아 뒀어요. 링크를 읽고 판단하고 카드를 넘기는 동안에는 피그마와 번역 시스템을 읽기만 하고요.

감추는 게 편의만은 아니었어요. 기획자가 실수로 운영을 건드릴 길 자체가 없어졌어요.

개발자도 피그마만 보면 돼요

이 앱이 피그마에 남기는 키 링크는 개발자에게 가는 메모예요. 텍스트 레이어의 Dev Resources에 붙고, 결정과 키, 값의 의미, 개발이 확인할 것이 들어 있어요.

flowchart LR
  P[기획자: 링크 붙여넣고 카드 확인] --> F[피그마 텍스트 레이어에 키 링크]
  F --> D[개발자: 같은 화면을 보며 구현]

개발자는 원래 피그마를 보며 개발해요. 이제 그 화면의 문구에 키가 이미 붙어 있어요. 웹페이지에서 "이 문구 키가 뭐였지"를 검색할 필요가 없어요. MCP가 생긴 뒤에도 사실 그 검색은 AI 에이전트가 대신 해 줄 뿐 토큰을 써서 찾아야 하는 건 같았는데, 이제는 찾을 게 없어요. 피그마 링크를 AI 에이전트에게 주면 레이어에 붙은 키 링크에서 문구와 키 표를 바로 받아요. Android와 iOS는 그 표를 상수 정의 줄로도 받고요.

이 부분도 따로 새로 만든 건 많지 않아요. 기획자 쪽에서 레이어에 링크를 남기기로 하니, 개발자 쪽은 그 링크를 읽기만 하면 됐어요.

다섯 번째에서야 보인 것

네 번의 도구는 실패가 아니었어요. 그게 없었으면 다섯 번째는 만들 수 없었어요. 판단 엔진도, API를 감싼 CLI도, MCP도 이 앱 안에서 그대로 돌고 있으니까요.

다만 순서가 반대였다는 생각은 들어요. 저희는 기능을 먼저 만들고, 그걸 쓸 사람을 설득하려고 했어요. 이번에는 쓸 사람이 어디서 일하는지를 먼저 보고, 그 자리에 기능을 가져다 놓았어요. 그러자 설명할 게 거의 없어졌어요.

제품 조직은 피그마 링크를 넣고 카드 몇 장을 넘기면 끝이에요. 개발자는 피그마를 보고 개발하면 끝이고요. 그 사이에 dev 등록이 있고, 승격이 있고, 번역 요청과 릴리스가 있다는 건 이제 저희만 알면 되는 일이에요.

얼마 전 정리한 Laurie Voss의 발표에서 Laurie는 코드를 짜는 일은 점점 에이전트에게 넘어가고, 개발자에게 남는 건 사람들에게 필요한 게 뭔지 알아내는 일이라고 했어요. 이번 일이 딱 그랬어요. 코드는 이미 다 있었고, 남은 일은 기획자가 어디서 일하는지, 무엇까지 알아야 하는지 알아내는 거였어요.