안녕하세요! 오늘의집 프로덕트 디자인팀 Yohan, Lucy 입니다. 저희 프로덕트 디자인팀은 사용자에게 더 나은 서비스 경험을 제공하기 위해 UX를 고민하고 설계합니다. 현재는 이러한 디자인 고민에 깊이 몰입할 수 있도록 AI Transformation을 준비하고 있습니다. 디자인 과정에서 반복되는 작업을 찾아내고, 이를 자동화와 AI로 해결해 팀 전체의 생산성을 끌어올리는 것이 목표예요.
그 첫 번째 성과로 AI Workflow Operator인 Lucy님과 함께, 글로벌 서비스의 필수 관문이지만 수작업과 휴먼 에러로 가득했던 ‘로컬라이즈(번역) 키 생성’ 업무를 완전히 자동화한 이야기를 들려드리려 합니다. 사실 국내 선례가 없어 10개의 워크플로우를 직접 설계하고 엮어내는 과정이 쉽지만은 않았습니다. 하지만 고민 끝에 탄생한 ‘마스터 플러그인(Master Plugin)’은 기대 이상의 변화를 가져왔어요. 전사 협업 시스템에 성공적으로 안착하며, 디자이너의 관련 리소스를 무려 8배나 절감할 수 있었거든요. 단순 반복 업무에서 벗어나 팀 전체가 더 본질적인 디자인 고민에 집중할 수 있게 된 그 치열한 여정을 지금부터 하나씩 공유해 볼게요!
그럼에도 불구하고, 자동화여야만 했던 이유
들어가기 전에 : 소스코드에서 텍스트를 관리하는 방법
본격적인 프로젝트 이야기에 앞서, 이해를 돕기 위한 짧은 배경지식을 먼저 공유해 드릴게요. 우리가 매일 마주하는 앱 화면 속 수많은 텍스트, 과연 코드에서는 어떻게 관리되고 있을까요? 보통은 하드코딩과 Key 관리, 크게 두 가지 방식을 사용하곤 합니다.
하드코딩(Hardcoding)은 텍스트를 소스코드에 바로 직접 입력하는 방식이에요. 개발 속도는 빠를 수 있지만, 규모 있는 프로덕트에서는 관리가 어려워요. 특정 문구를 수정할 때마다 코드를 일일이 찾아야 하고, 자칫 코드 속에 숨은 옛날 문구가 유저에게 노출되는 리스크도 있거든요. String ID(Key 관리)는 텍스트마다 고유한 ID(이름표)를 붙여주고, 실제 문구는 별도의 문서에서 관리하는 방식이에요. 나중에 수정하기는 아주 편리하지만, 매번 새로운 ID를 만들고 등록해야 해서 관리 리소스가 꽤 드는 편이죠.
“그럼 무조건 String ID 방식이 좋은 건가요?”라고 물으신다면, 정답은 ‘회사의 규모와 상황에 따라 다르다’입니다. 빠른 성장이 제일 중요한 초기 스타트업에는 하드코딩이 효율적일 수 있어요. 하지만 오늘의집처럼 서비스 규모가 커지고, 특히 이미 글로벌 서비스를 활발히 운영하고 있는 단계라면 이야기가 달라집니다. 텍스트 하나를 고치기 위해 수만 줄의 코드를 뒤져야 하거나, 코드 어딘가에 숨어있던 문구가 유저에게 갑자기 노출되는 리스크가 커지기 때문이죠.
오늘의집도 본격적인 글로벌 확장을 시작한 2022년부터 이 ‘텍스트 리소스 관리’를 깊게 고민하기 시작했습니다. 규모 있는 서비스에서 시스템 없이 텍스트를 관리하다 보면 생각보다 꽤 치명적인 문제들이 발생하곤 하거든요. 대표적으로 다음과 같은 페인 포인트들이 생겨납니다.
- 프로덕트 디자이너와 엔지니어 사이의 불필요한 커뮤니케이션 비용 증가
- 맞춤법 오류나 레거시 문구가 의도치 않게 노출되는 리스크
- 글로벌 서비스로 나아갈 때 다국어 대응의 한계
‘그냥’ 하기엔 너무 많았던 레거시
사실 오늘의집도 오랫동안 하드코딩 방식을 유지해 왔기에 이런 문제들에서 자유롭지 못했어요. 오랜 시간 쌓여온 소스코드 속에서 하드코딩된 텍스트들을 일일이 찾아 String ID로 전환하고, 이를 모든 신규 지면에 적용하는 일은 결코 쉬운 과제가 아니었죠.
우선 수정해야 할 텍스트가 얼마나 되는지조차 파악하기 어려웠고, 수많은 예외 케이스를 아우를 수 있는 탄탄한 ID 규칙을 만드는 일 또한 큰 숙제였습니다. 무엇보다 ID를 직접 정하고 등록하는 과정에 워낙 손이 많이 가다 보니, 확실한 체계 없이 시작했다가 나중에 되돌리기엔 팀 전체의 리소스 부담이 너무나 큰 상황이었어요.
문제는 리소스에 있었습니다. 그동안 텍스트 키를 생성하고 등록하는 전반적인 관리 업무는 오롯이 프로덕트 디자이너분들의 몫이었거든요. 본질적인 UX 고민만으로도 바쁜 디자이너들에게 복잡한 String ID 관리까지 챙겨야 하는 환경은 무척 버거울 수밖에 없었죠. 실제로 디자이너분들의 목소리를 들어보니, 이 업무가 전체 리소스의 상당 부분을 차지할 만큼 큰 부담이 되고 있었어요.
이런 리소스의 한계는 결국 서비스 운영 전반의 불균형으로 이어졌습니다.
국내 서비스의 경우, 이미 코드 전반에 상당 부분 하드코딩이 자리 잡고 있었어요. 새로운 관리 방식을 도입하려면 기존 텍스트들을 일일이 찾아 String ID로 교체하는 작업이 선행되어야 했는데요. 오랜 기간 쌓여온 레거시 텍스트가 정확히 몇 개인지조차 파악하기 힘들 만큼 그 양이 너무나 방대했습니다. 결국 현실적인 공수 한계에 부딪혔고, 국내 지면의 String ID 전환은 아쉽게도 우선순위에서 밀리게 되었습니다.
글로벌 서비스의 경우 다국어 대응이 필수였던 글로벌 서비스는 모든 텍스트에 String ID를 사용하고 있었지만, 상황이 그리 좋지는 않았습니다. 잦은 담당자 변경과 시스템 미비로 인해 관리 규칙이 상당 부분 무너진 상태였거든요. 기존 키를 무분별하게 재사용하거나, 키 이름만 보고는 도저히 맥락을 추측하기 힘든 파편화된 ID들만 생성되고 있었습니다.
4,000개의 텍스트를 일일이 수동으로 교체해야 한다고요?
글로벌 확장이 본격화될수록 이 문제는 더 이상 미룰 수 없는 풀어야만 하는 숙제가 되었습니다. 관리되지 않는 텍스트들이 쌓일수록 유저에게 잘못된 정보를 보여줄 위험은 커지고, 서비스 전체의 완성도를 높이는 데에도 큰 걸림돌이 되었기 때문입니다. 결국 이 문제를 정면으로 돌파하기로 결심했습니다. 하드코딩 텍스트를 모두 뽑아내어 제대로 된 관리 체계를 만드는 대공사를 시작하기로 한 것이죠.
프로젝트 초기, 주어진 첫 번째 미션은 소스코드 곳곳에 흩어져 있는 레거시 하드코딩 텍스트 약 4,000개를 하나하나 String ID로 교체하는 작업이었습니다. 하지만 단순히 눈앞의 레거시를 하나하나 없애는 것만으로는 본질적인 문제를 해결할 수 없었어요. 언젠가 또다시 하드코딩이 쌓이거나 관리 규칙이 무너지는 악순환이 반복될 게 뻔했으니까요.
그래서 이번 기회에 아예 ‘자동화’를 통해 일하기 좋은 환경을 만들고, 시스템의 지속 가능성을 높이는 방향을 선택했습니다. 수동으로 4,000개를 옮기는 고통스러운 작업 대신, 누구나 쉽고 정확하게 텍스트 리소스를 관리할 수 있는 근본적인 해결책을 고민하기 시작한 것이죠. 그렇게 자동화 프로젝트를 기획하고 개발하며, 오늘의집만의 새로운 시스템을 설계해 나갔습니다.
본격적인 변화의 시작 : Master Plugin의 탄생
히스토리 파악부터 솔루션 도출까지
1️⃣ 업무 히스토리와 실무 워크플로우 추적하기
무엇을 자동화할지 결정하기 위해 가장 먼저 한 일은 실무진분들을 찾아가 인터뷰하는 것이었어요. 업무 히스토리를 파악하고 워크플로우를 처음부터 끝까지 나열해 본 뒤, 네 가지 기준을 세워 자동화 가능 영역을 확정했습니다.
[자동화 영역 확정 기준]
- Code만으로 구현이 가능한가?
- AI가 추론하는 것이 반드시 필요한가?
- AI 추론을 통해 만족스러운 결과물이 나올 수 있는가?
- 기존에 적재된 DB 품질이 활용 가능한 상태인가?
2️⃣ Task를 쪼개고, 우선순위 산정하기
실무를 이해한 뒤에는 Task를 쪼개고 구현 복잡도, 리소스 절감 효과, 시급도를 기준으로 우선순위를 정했습니다. 직접 테스트 코드를 짜보고 LLM과 아이데이션 하며 난이도를 구체화했죠.
우선 로컬라이즈 툴 등록(2)과 번역 요청 슬랙 알림(3)은 리소스를 가장 많이 잡아먹는 작업이었지만, 코드만으로도 충분히 자동화가 가능했어요. 투입 공수 대비 효율이 가장 크다고 판단해 이를 1, 2순위로 두고 먼저 해결하기로 했습니다.
반면 String ID(Key)를 생성하는 작업(1)은 고려해야 할 점이 무척 많았습니다. 텍스트를 인식하는 Vision 성능부터 복잡한 명명 규칙 확정까지 구현 난이도가 상당히 높았거든요. 게다가 당장 수동으로 관리하는 것이 불가능한 수준은 아니었기에, 시급도를 고려해 3순위 과제로 미루어 두었습니다.
3️⃣ 자동화 방법 구상하기
자동화 시스템의 방향은 철저히 ‘사용자 관점’에서 고민했어요. 특히 실제 업무가 시작되고 끝나는 지점인 트리거(Trigger)와 엔드포인트(Endpoint)를 사용자가 가장 익숙한 환경에 두는 것이 중요했죠. 대부분의 시간을 피그마에서 보내는 프로덕트 디자이너의 작업 패턴을 고려해, 피그마 플러그인을 트리거로 활용하는 자동화를 구상했습니다.
마침내 탄생한 플러그인 피쳐
프로덕트 디자이너분들이 가장 많이 사용하는 Figma를 트리거로, 가장 번거로운 일부터 하나씩 해결해 나갔습니다.
✅ 번역 요청: 이제 슬랙 메시지 복사·붙여넣기는 그만!
사실 번역 요청은 프로덕트 디자이너와 번역가 사이의 긴밀한 협업이 필요한 영역입니다. 특히 번역 누락을 방지하기 위해서는 슬랙 메시지에 상당히 상세한 정보들을 담아야 했는데요. 텍스트 키(Key) 하나하나마다 개별 링크를 첨부하고, 키 이름과 한국어 원문 값을 일일이 대조해 적어주는 식이었죠. 이런 단순 반복적인 메시지 작성 작업은 지루할 뿐만 아니라, 디자이너의 소중한 리소스를 끊임없이 잡아먹고 있었어요.
이 문제를 해결하기 위해 도입한 ‘번역 요청 자동화 기능’은 의외로 간단한 구조로 구현할 수 있었습니다. 시스템 설계 시 집중한 핵심 기능은 두 가지였어요.
- 요청 사항, Key 정보, 각종 링크 등을 슬랙 양식에 맞춰 메시지로 전송한다.
- 각 Key에 대한 URL을 자동으로 생성한다.
전체적인 구동 방식은 이렇습니다. 우선 피그마 플러그인이 디자인 파일 내의 데이터를 추출해 n8n* 워크플로우로 전송하고, 데이터를 전달받은 n8n은 이를 전처리해 약속된 슬랙 메시지 양식으로 가공한 뒤 전송하는 역할을 수행합니다.
이 기능을 도입한 덕분에 손이 많이 가던 번역 요청 메시지 작성 업무의 공수 문제를 깔끔하게 해결할 수 있었습니다.
*n8n : 다양한 서비스와 API를 유기적으로 연결해 복잡한 업무 프로세스를 자동화해주는 워크플로우 툴
✅ 로컬라이즈 등록: 다량의 키도 한 번에 슥!
오늘의집은 텍스트 리소스 관리 툴로 Lokalise를 사용하고 있습니다. 개발자와 디자이너, 번역가가 협업하기에 무척 유용한 도구이지만, 새로운 String ID를 등록하는 과정은 결코 만만치 않았어요. 수많은 키를 하나하나 직접 입력하며 등록해야 했기에 상당한 리소스가 할애될 수밖에 없었죠. 이 번거로움을 해결하기 위해 필요한 기능은 세 가지였습니다.
- 다량의 키를 한번에 등록한다
- 등록 작업의 결과(성공/실패)를 확인한다
- 주석 문구, 태그 등을 규칙에 맞게 삽입한다
이 기능 역시 피그마 플러그인과 n8n 워크플로우의 연동으로 구현했습니다. 먼저 플러그인에서 String ID와 플랫폼, 태그 정보를 n8n으로 전송하면, n8n의 Code 노드가 이 데이터를 로컬라이즈 서비스에 적합한 형태로 전처리합니다. 이후 API를 통해 키 정보를 등록하고, 그 결과를 다시 플러그인으로 보내 UI에 노출해 주는 구조입니다.
이제는 다량의 키를 클릭 몇 번으로 한 번에 등록할 수 있게 되어, 로컬라이즈 관리 업무에 들어가던 막대한 공수를 획기적으로 줄일 수 있게 되었습니다.
✅ String ID 추천 : 레거시 텍스트 해결을 위한 한방
앞서 소개한 두 가지 기능은 글로벌 프로덕트 디자이너분들의 당장 급한 리소스 부담을 덜어주는 데 획기적인 역할을 했습니다. 하지만 약 4,000개가 넘는 방대한 하드코딩 텍스트를 처리하고, 앞으로 쌓일 텍스트들에 통일된 규칙을 적용하기 위해서는 결국 Key 생성 자체를 자동화하는 기능이 반드시 필요했어요.
당시 Key 생성 업무는 크게 세 가지 문제에 직면해 있었어요. 우선 명명 규칙을 해석하는 방식이 디자이너마다 달라 양식이 파편화되어 있었고, 이미 등록된 키를 찾아 재사용하기가 무척 불편한 환경이었습니다. 무엇보다 대대적인 레거시 제거 작업을 위해 다량의 키를 한꺼번에 생성할 수 있는 시스템이 절실했습니다.
이런 고민 끝에 탄생한 ‘Key 생성 자동화’는 5개의 n8n 워크플로우와 플러그인 코드가 유기적으로 맞물려 ‘키 추천’ 작업을 수행합니다. 필요한 기능은 다음과 같았습니다.
- 규칙에 맞게, 수정할 필요 없는 높은 정확도의 Key를 생성한다.
- 키 재사용이 가능하도록 연관된 기등록 키 정보를 노출시킨다.
- 줄바꿈, 변수 등 규칙적인 양식을 자동으로 반영한다.
구체적인 메커니즘을 살펴보면, 먼저 피그마의 UI 이미지와 원본 텍스트, 텍스트의 좌표(bbox) 등의 정보가 각 구성요소를 추론하는 n8n 워크플로우로 송출됩니다. 특히 정확도를 높이기 위해 추론 워크플로우를 분리했는데요. 각 워크플로우에 배치된 개별 LLM이 모듈 이름과 컴포넌트 이름을 각각 추론하며, 각 구성요소에 최적화된 프롬프트를 바탕으로 답변의 정밀도를 극대화했습니다.
동시에 원본 텍스트와 지면 이름을 바탕으로 Key DB를 실시간 조회하여, 재사용 가능한 기존 키 정보를 플러그인 UI에 함께 노출해 줍니다. 그 밖의 피그마 프레임 생성이나 한국어 줄바꿈(\n), 변수([%s]) 처리와 같은 정형화된 작업들은 플러그인 코드 내에서 즉시 처리되도록 구현했습니다.
높은 만족도, 그리고 팀의 변화
이 플러그인의 등장은 프로덕트 디자이너의 업무 리소스를 획기적으로 낮추었을 뿐만 아니라, 팀 전체에도 변화를 이끌어냈습니다. 시스템을 경험하며 자동화의 효용을 체감한 디자이너분들 사이에서 직접 본인의 업무에 필요한 플러그인을 ‘바이브 코딩’으로 개발해 보려는 니즈가 생겨나기 시작한 것이죠. 이러한 흐름에 발맞춰 자동화 관련 팀 내 특강과 업무 지원을 통해, 디자이너분들이 AI Native로서 역량을 펼칠 수 있도록 적극적으로 돕고 있습니다.
프로덕트 디자인팀에서는 앞으로도 AI를 활용해 한계를 뛰어넘는 다양한 사례들을 공유해 나갈 계획이에요. 저희가 만들어갈 변화의 여정에 많은 관심 부탁드립니다. 😊
