테크 블로그 TechBlog

우리가 만든 앱, 그리고 폐기한 앱

솔직히 고백하면 — 우리는 모바일 앱을 만들었다. 포털도 만들었다. 그리고 폐기했다.

이유는 단순하고 아팠다.

사용자는 우리 앱에 안 들어왔다. 이미 Teams에 살고 있었다.

좋은 지식 AI를 만드는 것과, 사용자가 그걸 쓰게 만드는 것은 완전히 다른 일이었다. 멋진 새 집(앱)을 지었는데, 사용자는 이사 올 생각이 없었다. 하루 종일 일하는 곳은 워크스페이스(Teams, Google Chat)였으니까.

채널은 글로벌 업체를 못 이긴다 — 그래서 Thin 플랫폼

방향을 틀면서 우리가 인정한 게 하나 있다. 채널 그 자체(메신저 UX, 알림, 첨부, 카드 렌더링…)는 글로벌 업체가 수십 년 투자한 영역이고, 우리가 그 수준으로 만들 수 없다. Teams를, Google Chat을 우리가 다시 만들 수는 없다.

그리고 하나에 락인(lock-in) 되는 것도 위험했다. 한 플랫폼에 올인하면 그 플랫폼 정책 하나에 서비스가 흔들린다.

그래서 택한 게 Thin 플랫폼이다 — 채널을 _소유_하지 않는다. 대신 각 채널에 얇게 연결만 하고, 무거운 지능(검색·권한·근거·rerank)은 우리 쪽 공통 substrate에 둔다. 채널은 갈아 끼울 수 있는 얇은 어댑터가 되고, 우리는 벤더와 경쟁하는 대신 그 위에 올라탄다.

        [디지털 동료]  (1~3탄: 저장 · 권한 · 대화)
             │  공통 substrate (검색/권한/rerank/근거)   ← 무겁게, 우리가 소유
   ┌─────────┼──────────┬───────────┐
 Teams봇   Google Chat   Outlook    A2A(에이전트 연동)    ← 얇게, 갈아끼움

디지털 동료 하나 → 채널 N개

Thin 플랫폼의 보상은 여기서 나온다. 신원 확인과 UX 포장을 채널별로 한 번씩만 풀어두면, 그 다음부터는 —

• 디지털 동료 하나를 추가하면 이미 연결된 모든 채널에 동시에 나타난다.
• 채널 하나를 연결하면 이미 있는 모든 동료가 그 채널에서 한 번에 쓸 수 있게 된다.

동료 M명 × 채널 N개를 M×N번 따로 만드는 게 아니라, M + N번만 만들면 되는 구조다. 이게 "직접 UI를 안 만든다"가 단순 비용 절감을 넘어 _구조적 레버리지_가 되는 지점이다.

같은 답, 다른 얼굴

인증만 채널마다 다른 게 아니었다. 같은 질문에 같은 근거로 답해도, 그걸 _보여주는 방식_은 채널마다 달라야 했다. Teams에선 풍부한 카드(Adaptive Card)로, Google Chat에선 그 채널의 카드 포맷으로, 사람이 보지 않는 에이전트 연동 채널에선 애초에 "보여줄" 필요 없이 구조화된 데이터로 — 같은 답을 그 채널이 이해하는 언어로 다시 포장한다.

여기서 데인 교훈 하나: pod에서 함수로 찍어 본 게 사용자 화면이 아니다. 이건 그냥 넘어갈 얘기가 아니라 심화에서 따로 다룬다.

직접 UI를 안 만든다는 원칙

• 모바일·포털은 폐기. 워크스페이스 플랫폼 + 채널 + 디지털 동료 연결로 통합.
• 새 기능 = 새 화면을 또 만드는 게 아니라, 기존 채널에 동료의 능력을 더하는 것.
• 운영 작업(관리자)은 별도 UI 대신 CLI·슬래시 명령으로.

우리는 _프론트엔드를 다시 만드는 일_을 줄이고, _동료의 능력_에 집중할 수 있게 됐다.

심화 — 채널마다 다른 인증, 그리고 렌더링은 화면에서 검증한다

이 절은 깊다. 채널을 얇게 연결한다는 게 코드에서 뭘 뜻하는지 궁금한 분을 위한 detail이다. 바쁘면 맺음으로 건너뛰어도 좋다.

① 같은 "누구인지" 확인인데, grant 타입이 다르다

채널을 하나 늘릴 때마다 가장 먼저 부딪힌 건 신원 확인 방식이 제각각이라는 점이었다. 두 개만 나란히 놓아 보자.

• Google Chat — 서비스 신원(OIDC) 검증. Google이 발급한 OIDC id_token을 우리 쪽 verifier가 검증한다(정해진 발신자 allowlist인 service_account 모드, 또는 도메인 정책상 허용된 사용자 이메일 토큰). 핵심은 "이 요청이 신뢰된 발신자(서비스)에서 왔는가" 를 토큰으로 확인하는, machine-to-machine에 가까운 모델이다.
• 에이전트 연동(A2A) — 위임 토큰 교환(OBO). 여기선 사람이 채널에 로그인하는 게 아니라, 에이전트가 사용자를 대신해(on-behalf-of) 통신한다. 사용자 동의로 얻은 토큰을 downstream 토큰으로 교환(On-Behalf-Of) 해서, 그 위임 신원으로 다음 시스템에 접근한다. authorization-code에서 파생된 위임(delegated) 모델이다.

같은 "이 사용자가 누구인지 확인한다"인데, 한쪽은 _서비스 신원을 검증_하고 다른 쪽은 _사용자 위임을 교환_한다 — grant 타입 자체가 다르다. 그래서 채널 하나 = 인증 어댑터 하나였다. (이 위임 교환은 실제로 한 번 크게 데였다 — invalid_grant가 무더기로 나 별도 원인분석을 했다.) 각 채널의 인증을 2탄의 출입증(payload 권한)에 다시 맞물리는 게 Thin 플랫폼의 진짜 일이었다.

② 영리한 선택 — 채널을 소유하지 않는다

기각한 대안은 명확했다: 자체 채널·앱을 만들어 그 안에서 모든 걸 통제하기(모바일·포털이 그거였고, 폐기했다). Thin 플랫폼은 그 반대다 — 채널 UX는 벤더에게 맡기고, 우리는 그 위에 얇은 어댑터로만 붙는다. 잃는 것: 채널 화면을 100% 우리 맘대로 못 함. 얻는 것: 벤더와 경쟁 안 함 + 락인 회피 + M+N 레버리지.

③ 숫자, 정직하게

여기엔 자랑할 하드 넘버가 없다. M+N의 이득은 "채널·동료를 늘려도 연결 작업이 곱이 아니라 합으로 는다"는 구조적 사실이지 측정된 %가 아니다. 없는 숫자는 안 만든다.

④ 우리가 처음엔 틀렸다 — pod에서 찍은 건 사용자 화면이 아니다

가장 아팠던 채널 사고는 렌더링이었다. Teams 카드가 단일 줄바꿈을 공백으로 뭉개 잘 정리한 답이 한 덩어리 벽처럼 나온 적이 있다. 또 한 번은 카드를 감싸던 내부 호환 마커(__ADAPTIVE_CARD__)가 안 벗겨져 raw JSON이 그대로 사용자에게 노출된 적도 있다. 둘 다 pod 안에서 함수를 호출해 찍어 보면 멀쩡했다 — "함수 출력이 맞다"와 "그 채널에서 실제로 그렇게 보인다"는 다른 일이었으니까.

그래서 렌더링을 화면 기준으로 강제하는 4겹을 깔았다: commit 훅(원시 마커 누출 차단) · CI(카드 골든 렌더 테스트) · 런타임(발신 직전 outbound guard) · Datadog 모니터(마커 누출·렌더 실패율). 채널을 얇게 연결한다는 건, 역설적으로 각 채널의 화면을 더 깐깐하게 검증한다는 뜻이었다. (사실 문서를 한 도구에서 다른 도구로 옮길 때마다 겪는 일이다 — 원본에선 멀쩡한데 옮긴 화면에선 깨지는. 규모만 다를 뿐 같은 교훈이다.)

맺음 — 그런데 좋은 지식이 없으면 다 소용없다

저장(1) → 권한(2) → 대화(3) → 채널(4). 이제 사용자는 자기 자리에서, 권한 안에서, 근거 있는 답을 받는다.

그런데 이 모든 건 _좋은 지식이 들어와 있을 때_만 의미가 있다. 쓰레기가 들어가면 쓰레기가 나온다. 그 지식을 _어떻게 모으고, 들이기 전에 무엇을 검수했는지_는 — 번외편 — 좋은 답변의 90%는 검색 전에 결정된다에서.

---

시리즈: 1탄 저장 · 2탄 권한 · 3탄-1부 대화 · 3탄-2부 대화 · 4탄 채널 (이 글) · 번외 수집

김헌기 Darion · AX본부 > AI데이터부문 > AI혁신지원팀

AI 및 공통 Tech 기반의 기술 표준화 업무를 수행하고 있습니다. 동료들과 함께 기술 문화 만들기와 낯선 기술자와의 인연의 시작에 관심이 많습니다.