왓챠 직원 누구나 AI 앱을 만들 수 있게 된 이유

현재 왓챠에서는 마케터가 스스로 KPI 대시보드를 만들어 레포트를 작성하고, 운영자가 자동화 도구를 만들어 업무를 자동화하고 있습니다. ML 엔지니어는 자체 데이터 분석 플랫폼을 제작해 데이터를 분석하고, 사업팀에서는 자체 CRM을 구축해 SaaS를 대체하고 있습니다. 사내 직원들은 누구나 원하는 도구나 앱이 있다면 이를 직접 만들어 직접 문제를 해결하고 있습니다.

지난 몇 년 동안, 플랫폼이나 자동화 앱을 제작하는 것은 개발자만의 전유물이었습니다. 소프트웨어 제작에는 특정한 지식이나 경험이 필요한 개발 능력이 필요했기 때문입니다. 마케팅 팀이 월별 활성 사용자 대시보드를 볼 수 있으려면 어느 정도 시간이 필요했을까요? 정답은 "대시보드 개발자의 백로그에 따라 다르다" 였습니다. 이처럼 개발 능력의 부재는 비개발자 팀에게 병목으로 작용하곤 했습니다.

이제는 상황이 변했습니다. LLM의 발전으로 비개발자 직군도 쉽고 빠르게 개발할 수 있게 되었기 때문입니다. 이제 소프트웨어를 개발하는 행위는 개발자만의 능력이 아니게 되었습니다. 하지만 사내 직원들은 생각만큼 매끄러운 자동화 앱을 쉽게 제작할 수 없었습니다. 이에는 단순히 개발 지식의 부족이 아닌 다른 문제가 존재했습니다.

이 글에서는 왓챠의 플랫폼 팀에서 조직이 AI 기반으로 앱을 개발하기 어려워하는 문제를 해결하기 위해 ADP, AI Development Platform를 구현한 과정을 서술합니다. 플랫폼 팀에서는 ADP를 왜 만들었는지, ADP를 배포하며 어떤 문제를 마주했는지, ADP로 어떤 문제를 해결할 수 있었는지 알아봅니다.

문제 정의

왓챠 사내 직원들이 생산성 향상에 필요한 앱을 LLM으로 제작하는데 어려움을 겪었던 이유는 다음과 같았습니다. 비단 왓챠뿐 아니라 LLM을 통해 앱을 개발하고자 했던 유저라면 누구나 아래와 같은 문제들을 마주했을 것입니다.

1. 아무도 데이터를 찾지 못한다 : 사내 직원들이 앱을 제작하기 위해서는 사내에서 관리하는 데이터가 필요했습니다. 보통 직원들은 사내 정보를 시각화하거나 메트릭을 추출하는 등 사내 데이터 를 기반으로 인사이트를 얻으려 하기 때문입니다. 하지만 이에 필요한 데이터를 소유하고 관리하는 주체는 보통 데이터 팀, 혹은 개발 조직이었습니다. 이러한 조직에 속하지 않은 직원들은 데이터가 어디 있는지 , 심지어 데이터가 존재는 하는지 등의 정보를 알 수 없다는 문제가 있었습니다.
2. 너무 많은 권한 요청 : 어느 날 플랫폼팀에 GCP 권한 요청이 평소보다 많이 들어온 적이 있었습니다. 원인은 많은 사내 직원들이 LLM으로 앱을 만드는 과정에서 Google Drive 접근이 필요했기 때문에 관련 권한을 요청해야 한다고 판단(혹은 LLM이 가이드) 했던 것이었습니다. 하지만 플랫폼 팀은 대부분의 권한 요청을 보류할 수밖에 없었습니다. 플랫폼 팀 인원이 모든 직원들의 권한 요청에 대응할 수 없었을뿐더러, 많은 직원에게 API Key나 Token이 발급되는 것은 보안 공격 표면이 커질 수 있었기 때문입니다.
3. 어디에도 배포할 수 없다 : 사내 직원들이 LLM을 통해 만든 앱 대부분은 외부 호스팅 플랫폼(Vercel, Github pages, Netlify ..)에 배포되어 있었습니다. 이는 LLM이 특정 호스팅 플랫폼에 앱을 배포하려는 편향도 있었지만, 사내에 앱을 배포하기 위한 환경이 부재하다는 것이 외부 호스팅 플랫폼을 통해 배포된 결정적인 원인이었습니다. 사내에서 운영하는 배포 환경은 "개발자"가 제작한 앱, 혹은 서비스를 배포하기 위한 것이지 전사 직원들을 위한 것은 아니었기 때문입니다. 하지만 모든 직원들이 각자의 앱을 외부에 배포하면 사내 정보가 유출될 위험이 커지며, 용량이나 스펙 부족으로 인해 원하는 생산성을 얻기 힘들 것이라는 문제가 있었습니다.
4. 데이터 유출 위험 : 무엇보다 가장 큰 문제는 LLM을 통해 생성된 코드가 사내에서 요구하는 보안 수준을 만족하기 어려웠다는 것입니다. 특히 OpenClaw 사내 데이터 유출 문제가 있었던 것처럼, 왓챠에서도 로컬 환경에서 LLM으로 제작한 앱을 구동한 직원들이 사내 정보나 데이터를 외부로 유출시킬 위험이 존재했습니다. 이러한 위협은 조직에게는 직원들의 LLM 사용을 제한하려는 동기를 가지게 하며, 직원들은 적극적인 LLM 사용이 어려워지는 문제가 있었습니다.

위의 문제들로 인해 왓챠의 사내 직원들은 강력한 LLM을 활용할 수 있었음에도 그들이 원하는 도구나 앱을 제작할 수 없었습니다. 이러한 현상은 회사가 LLM 발전으로 인해 얻을 수 있는 생산성 향상이 개발 조직으로 한정되는 결과로 나타났습니다.

문제 해결을 위한 설계

이러한 현상을 해결하기 위해 문제를 기반으로 구체적인 설계에 들어가야 했습니다. 설계의 기본적인 골격은 Spotify의 Honk를 참조하되, 왓챠의 상황에 맞는 디자인을 기획했어야 했습니다. 따라서 문제를 해결하기 위한 3개의 Design Principle을 정의했습니다.

1. 플랫폼은 Self-service 형태로 사내 직원이 스스로 Claude-Code를 통해 앱을 개발·테스트·배포할 수 있어야 한다.
2. 플랫폼은 중앙화된 구조 로데이터에 접근할 수 있는 단일 진입점 및 데이터 카탈로그 역할을 수행해야 한다.
3. 플랫폼은 가드레일 및 로직을 내장해 앱 배포 과정에서 보안 관점에서 안전하게 개발할 수 있어야 한다.
4. 플랫폼은 샌드박싱된 개발 환경을 제공해 사내 문서 및 파일 유출에 대한 위협을 제거해야 한다.

플랫폼 팀이 이를 구현하기 위해 의도적으로 제외하거나 다루지 않은 영역(Non-Goals)는 다음과 같았습니다.

1. Claude-Code 외의 LLM 도구의 사용 : 글 작성 당시 사내에서는 Claude Code 교육을 진행했기 때문에 사내 직원들 대다수가 이미 Claude Code의 사용에 익숙해져 있는 상황이었습니다. 사용자들에게 친숙한 도구를 기반으로 플랫폼을 제공하기 위해 Gemini, GPT 등 다른 Provider는 설계 단계에서 고려하지 않았습니다.
2. AI 개발 플랫폼 관련 SaaS 또는 솔루션의 도입 : 시중에 AI 개발 플랫폼 관련 도구들이 이미 SaaS 형태 다수 존재했지만, 리서치 결과 왓챠의 Built-in된 배포 환경과 연동되거나 보안 문제를 뚜렷하게 해결할 수 있는 도구가 존재하지 않았습니다. 때문에 SaaS 형태의 도구를 도입하는 것은 고려하지 않았습니다.

위의 기술적인 결정들 외에 개발이 빠른 피드백 루프로 이루어져야 한다는 것을 의도했습니다. 일반적으로 LLM과의 개발은 유저가 LLM에게 프롬프트를 제공하면 LLM은 이를 통해 코드를 작성하고, 유저는 코드를 확인하고 다시 프롬프트를 작성하는 짧은 루프로 이루어져 있습니다. 때문에 LLM과의 개발 경험은 유저들에게 몰입감을 제공하며, 생산성을 높일 수 있는 레버로 작용합니다.

하지만 기획한 AI 개발 플랫폼은 상황이 달랐습니다. 개발이 진행되는 환경이 샌드박싱된 외부 서버여야 하기 때문에 로컬에서 접근할 수 있는 테스트 서버를 띄우는 것이 어려웠으며, 구현 결과를 보려면 긴 배포 과정을 거쳐야 했기 때문입니다. 개발 과정에서 이러한 단계가 추가되는 것은 짧은 피드백 루프를 길게 늘리기 때문에 몰입감과 생산성을 해치는 결과로 이어질 수 있었습니다. 따라서 설계 단계에서 이러한 피드백 루프를 최대한 짧게 유지하도록 의도했습니다.

위와 같은 설계 과정을 통해 결과적으로 플랫폼 팀이 원했던 것은 "사내 모든 직원들이 LLM으로 만든 앱을 빠르고 안전하게 배포할 수 있는 플랫폼을 구현"하는 것이었습니다.

설계를 구현하기 위한 결정

Multi-tenant 문제

앞선 핵심 설계 중 하나는 많은 직원들이 데이터 접근 권한을 요청하는 문제를 해결하기 위해 플랫폼이 "데이터 접근을 위한 단일 진입점 역할을 해야 한다"는 것이었습니다. 또한 로컬 환경의 데이터 유출을 방지하기 위해 플랫폼은 "샌드박싱 된 개발 환경을 제공"해야 했습니다. 이 두 설계를 구현하기 위해 플랫폼은 각 유저들의 환경에서 개별로 동작하는 형태가 아니라 중앙화된 단일 서버로 제공되어야 했습니다. 그러면서도 서버는 각 유저 별로 격리된 환경을 제공하는 Multi-tenant환경이어야 했습니다. 각 유저들이 대화한 세션이나 코드 결과물이 다른 유저에게 접근 가능하면 안되기 때문입니다.

이를 해결하기 위해 여러 레이어에 걸쳐 유저별 격리를 구현했습니다. 이러한 격리를 구현하기 위해 Linux OS의 메커니즘을 그대로 활용했습니다. 플랫폼 서버 자체가 Linux OS에서 동작하기 때문입니다. 유저가 플랫폼 서버에 접근하면 두 가지 일이 일어납니다. 첫째, 접근하는 유저의 디렉토리가 생성됩니다. 둘째, 유저 이름의 Hash값을 기반으로 고유 UID가 할당됩니다. 유저는 플랫폼에 접속하면 할당받은 UID로 switch되며, 자신에게 할당된 디렉토리에 한해서만 UID 기반으로 권한을 얻게 됩니다.

이는 각 직원에게 자신만의 고유 키 와 해당 키로만 열 수 있는 캐비넷을 지급하는 것으로 비유할 수 있습니다. 플랫폼은 고유 키와 캐비넷을 준비하고 직원들에게 제공하는 역할을 합니다. 이를 통해 각 직원들은 단일 서버 형태로 제공된 플랫폼에서 Claude Code 세션이나 코드가 섞이는 일 없이 그들만의 공간을 사용할 수 있습니다.

데이터 접근 및 카탈로그 제공

플랫폼이 수행해야 할 역할에는 직원들에게 데이터의 위치를 알려주고, 데이터에 접근할 수 있는 단일 진입점을 제공해야 한다는 것이었습니다. 이를 구현하기 위해 플랫폼 팀은 사내에서 운영 중인 데이터 카탈로그 및 데이터 저장소 MCP를 Claude Code에 내장했습니다.

여기서 데이터 카탈로그 MCP는 사용자에게 어떤 데이터가 어디에 존재하는지 알려주는 역할을 합니다. "이번 달 주간 활성 사용자 수에 대한 데이터는 어디 있어?", "비활성 유저에 대한 정보를 얻을 수 있는 테이블이 있을까?" 와 같은 질문에 답변할 수 있는 정보를 제공합니다. 또한 데이터 저장소 MCP는 사내 데이터가 저장되어 있는 웨어하우스에 접근할 수 있는 진입점 역할을 합니다. 이를 통해 LLM으로 하여금 데이터 카탈로그로 얻은 데이터 저장소의 위치를 기반으로 실제 데이터를 가져올 수 있도록 합니다.

이러한 중앙화된 플랫폼을 통해 사내 데이터를 필요로 하는 직원들이 각각의 API Key, Token을 받을 필요가 없어졌으며, 데이터의 위치를 쉽게 파악하고 가져올 수 있게 되었습니다.

안전한 배포를 위한 가드레일

앞서 Openclaw 데이터 유출 문제를 언급했던 것처럼 플랫폼이 해결해야 할 가장 중요한 문제는 보안이었습니다. 따라서 플랫폼에 보안을 강화하기 위한 가드레일 및 하네스를 구현했습니다.

플랫폼은 민감 정보 유출을 방지하기 위해 배포되는 코드에 raw한 민감 정보를 직접 넣지 못하도록 되어있습니다. 데이터베이스 접속 정보, 토큰 값, API Key, 사내 이메일 등의 값들은 코드에 직접 삽입하는 것이 아니라 외부 Secret manager를 통해서 retrive 하도록 하네스를 구성했습니다. LLM이 민감 정보를 코드에 삽입했더라도 배포 과정의 코드 리뷰에서 이를 잡아낼 수 있도록 이중 장치를 두었습니다.

플랫폼을 통해 개발된 앱은 데이터 카탈로그, 저장소, 깃 레포지토리 접근에 별도의 자격 증명을 삽입하지 않도록 구현했습니다. 사내 서비스 접근에 필요한 자격 증명들은 플랫폼 서버에 AWS의 IRSA, GCP의 WIF를 통해 short-lived credential로 저장되고, 플랫폼을 통해 배포된 앱 또한 이 credential을 기반으로 인증하기 때문에 코드나 환경 변수 어디에서도 자격 증명 값을 노출하지 않습니다.

또한 플랫폼은 Multi-tenant 설계로 샌드박싱된 환경을 제공하기 때문에 로컬 코드 및 데이터가 의도치 않게 유출될 가능성을 차단합니다. 작성된 코드들은 별도의 깃 레포지토리에 저장되어 사용자는 로컬 환경에 코드가 저장되지 않고 개발부터 배포까지의 과정을 수행할 수 있습니다.

위와 같은 구현들을 통해 플랫폼은 민감 정보, 자격 증명 및 코드의 유출을 방지하기 때문에 사내 직원들에게 안전하게 개발할 수 있는 가드레일을 제공할 수 있었습니다.

빠른 피드백 루프를 위한 구현

플랫폼은 로컬 개발 못지않은 빠른 피드백 루프로 개발이 가능해야 했습니다. 개발 과정에서 피드백 루프가 느려지면 개발 몰입감 및 생산성을 저하시키는 문제가 존재하기 때문입니다. 이를 해결하기 위한 2가지 구현이 존재합니다.

첫 번째는 **"Preview"**기능의 제공입니다. Preview 기능은 사내 직원이 플랫폼을 통해 진행한 개발의 중간 결과물을 실제로 확인할 수 있도록 제공하는 기능입니다. 플랫폼 환경은 로컬 환경과 달리 코드의 구현체를 로컬에서 접근 가능한 진입점을 제공할 수 없습니다. 사용자가 중간 결과물에 접근하기 위해서는 프로세스를 띄우고 외부 진입점을 구성하는 서비스 배포 수준의 과정이 필요했습니다.

이러한 문제를 해결하기 위해 플랫폼에 **"Cloudflare Tunnel"**을 내장해 플랫폼에서 띄운 프로세스를 외부 URL로 접근 가능하도록 구성했습니다. Cloudflare Tunnel은 사용자의 프로세스 로컬 주소를 임시적인 Cloudflare 소유의 URL로 매핑하는 기능을 제공합니다. 이를 통해 사용자들은 "내가 만든 앱 결과 보고 싶어","지금까지의 결과 보여줘"와 같은 명령을 통해 개발 중인 결과물을 빠르게 확인할 수 있습니다.

두 번째는 **"Slack"**을 통한 알림 기능의 제공입니다. 플랫폼을 통해 배포가 정상적으로 수행되려면 LLM의 코드 리뷰를 포함한 배포 파이프라인을 통과하는 과정이 필요합니다. 이 단계들은 앱 배포의 lead time을 추가하기 때문에 피드백 루프를 느려지게 만드는 문제를 유발합니다. 이를 해결하기 위해 사내 메신저인 Slack이 유저들에게 배포 상태를 알릴 수 있도록 구성했습니다. 사용자는 Slack에 올라온 알림을 보고 코드 리뷰 결과, 배포 상태 등의 정보를 알 수 있습니다. 이와 같은 알림을 통해 사용자들은 빠르게 배포 상태를 알 수 있어 개발 과정을 가속할 수 있습니다.

위와 같은 구현을 통해 플랫폼은 개발부터 테스트, 배포까지 수행해야 하는 환경에서 유저들에게 빠른 피드백 루프를 통해 몰입감 있는 개발 경험을 제공할 수 있었습니다.

구현으로 얻은 것들

위의 설계와 구현 과정을 통해 AI Development Platform, ADP라 부르는 왓챠 사내 AI 개발 플랫폼을 성공적으로 구현할 수 있었습니다. 그 결과 유의미한 성과를 확인할 수 있었습니다.

ADP를 사내에 런칭한 이후 현재까지 60개 가 넘는 사내 앱이 ADP를 통해 제작되었습니다. 이 중 95% 이상이 비 개발 직군 구성원 이 직접 개발한 앱으로, 이 앱들은 실시간 대시보드, 자동화 시스템, 레포트 생성기, CRM, 플랫폼 등 다양한 형태로 각 구성원들의 문제를 해결하고 있습니다. 현재 ADP의 사용자들은 하루 평균 30건 이 넘는 배포를 수행하고 있으며, 평균 2분 이내 의 배포 시간으로 빠르게 개발 및 배포를 수행하고 있습니다. 한 사내 직원은 ADP를 통해 개발한 앱으로 24시간이 넘는 작업 시간을 5분 이내로 단축할 수 있었다고 합니다.

하지만 무엇보다 중요한 것은, ADP가 사내 구성원들의 AI를 통한 생산성 향상의 레버리지로 작용했다는 것입니다. ADP를 통해 수행한 LLM과의 협업 경험 자체가 미래의 자산으로 축적되기도 합니다.

플랫폼 팀 또한 ADP의 구현 및 운영을 통해 많은 것을 배울 수 있었습니다. ADP에 시스템 프롬프트를 제공할수록 정확도가 떨어지는 것을 보면서 하네스는 많을 \수록 좋은 것이 아니라는 것을 피부로 느낄 수 있었습니다. 또한 플랫폼의 활성 사용자 수 추이를 보며 사용자 경험에서 빠른 피드백 루프 가 주는 긍정적인 효과를 직접 확인할 수 있었습니다. 앱 배포와 같이 Deterministic 함이 필요한 부분은 프롬프트보다는 코드로 수행하도록 하는 것이 훨씬 안정적인 결과를 가져올 수 있다는 것을 깨달았습니다.

다음 여정

ADP 플랫폼의 개발은 여기서 끝나지 않습니다. 현재는 Claude-Code 의존적인 구성을 추후에는 Provider-agnostic한 형태로 변경해 다른 도구를 사용해 개발하고자 하는 유저들의 니즈를 충족시키고자 합니다.

또한 연동되는 데이터의 수를 더 늘리고자 합니다. 현재 ADP는 데이터 웨어하우스에서 제공되는 구조화된 데이터만을 제공하고 있으며, 최근 구현된 KnowledgeBase를 통해 사내 문서와 같은 비구조적인 데이터를 실험적으로만 제공하고 있습니다. 추후에는 Knowledgebase를 안정화하고 파일 기반 데이터 또한 연동하고자 계획하고 있습니다.

ADP의 격리된 환경을 더 공고하게 만들어 보안을 강화할 예정입니다. 현재는 3자리 수 인원 수준에서 중복 가능성이 희귀한 Hash값을 UID로 할당하고 있지만, 확장성을 위해 더 uniqueness를 보장받을 수 있는 방법을 적용하고자 합니다. 또한 격리된 환경에서 jailbreak가 가능한 경로를 탐색해 코드나 데이터가 유출될 가능성을 줄이고자 합니다.

앞으로도 ADP에 많은 변화들이 적용될 예정이지만, 전달하고자 하는 가치는 변함이 없을 것입니다. 누구나 AI 발전의 혜택을 볼 수 있게 하자는 것입니다. 이를 위해 ADP는 언제나 AI와의 협업으로 개발한 코드를 안전하게 배포할 수 있는 플랫폼으로 본분을 다할 것입니다.

---

왓챠 직원 누구나 AI 앱을 만들 수 있게 된 이유 was originally published in WATCHA on Medium, where people are continuing the conversation by highlighting and responding to this story.