테크회사 어썸블로그

AI 에이전트로 카카오톡 추천 지표 분석 자동화하기

2026-06-16T00:00:00+09:00

AI 에이전트로 카카오톡 추천 지표 분석 자동화하기: Hadoop 기반 도입 사례 안녕하세요. 소셜추천엔진팀에서 숏폼 추천 모델을 개발하고 있는 루퍼트(rupert)입니다. 추천 시스템을 개발하다 보면 코드를 짜는 시간만큼이나 데이터를 들여다보는 시간이 길어집니다. 지표가 조금만 움직여도 “이번 주 CTR이 왜 떨어졌지?”, “실험군 반응은 어땠지?”, “배포 이후 특정 사용자군에서 달라진 점은 없을까?” 같은 질문이 이어집니다. 질문은 한 문장이지만,...

Vibe Coding하는 비개발자는 개발자인가(3)

2026-06-16T00:00:00+09:00

2편을 쓴 뒤 시간이 꽤 지났습니다. 그 사이 AI 도구들은 더 많은 일을 하게 되었고, 저도 이전보다 훨씬 자주 AI 에이전트와 함께 일하게 되었습니다. 처음에는 업무에 실제적으로 도움을 주는 도구를 직접 만드는 일이 신났습니다. 개선하고 싶은 기능을 설명하면 화면이 생기고, 입력값을 넣으면 일정하게 필요한 결과가 나왔습니다. 이렇게 만든 도구들을 실제 업무에 계속쓰다 보니, 관심사가 자연스럽게 다음 단계로 넘어갔습니다. 혼자 쓰던 도구를 다른 사람에...

ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온

2026-06-17T12:00:00+09:00

안녕하세요. LY Corporation에서 인증·인가 기반 Athenz의 개발·운영을 담당하고 있는 보안 플랫폼 엔지니어 김정우입니다.지난 글 AI 시대에 인증 과제를 해결할 차세...

스펙만 바꾸면 프롬프트가 따라옵니다 - 답변 생성 모델 자동화 파이프라인

2026-06-18T19:17:54+09:00

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2026(5월)에서 발표되었던 세션을 공개합니다.

발표 내용

입력 스펙이 자주 바뀌는 쇼핑 에이전트 답변 모델 개발에서, 변경된 스펙만 입력하면 결함 탐지/프롬프트 최적화/SFT 학습 데이터 생성을 에이전트가 폐쇄 루프로 돌리는 자동화 파이프라인을 설계하며 얻은 구조와 적용 경험을 공유합니다.

발표 대상

AI 서비스를 위한 스펙기반 프롬프트 최적화를 적용하고자 하시는 기획/AI엔지니어 분들

◎ NAVER Engineering Day란?

NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요.
2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기)
올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다.

도구에서 동료로 — AI 에이전트 자율 성장 프레임워크

2026-06-17T20:31:17+09:00

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2026(5월)에서 발표되었던 세션을 공개합니다.

발표 내용

매 세션 초기화되는 AI의 한계를 넘어, 경험을 축적하고 스스로 성장하는 에이전트 프레임워크 GNOSIS의 설계 원칙과 구현 사례를 소개합니다.

발표 대상

AI Agent 프레임워크 활용에 관심 있는 개발자

PROLOGUE — 당신의 AI는 어제와 똑같다
INTRODUCTION — GNOSIS 30초 요약
ARCHITECTURE — 3-Loop + Constitution + 5층 기억
ALGORITHMS — 13 공리 · 17 메커니즘 · 7 알고리즘
THEORY — 수학적 안전 보장
EXPERIMENTS — 검증과 외부 근거
IMPLEMENTATION — Phase -1 → 3
DISCUSSION — 모르는 것은 모른다고 말한다
SUMMARY & Q&A — 5분 핵심 요약

◎ NAVER Engineering Day란?

NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요.
2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기)
올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다.

SaaS 대체하기: AI와 함께한 광고SDK 에러 모니터링 시스템 구축기

2026-06-16T23:14:39+09:00

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2026(5월)에서 발표되었던 세션을 공개합니다.

발표 내용

서드파티 SDK 환경에서 범용 에러 모니터링 도구 연동 시 발생하는 구조적 한계를 극복하기 위해, AI Agent를 활용해 전용 Javascript 에러 모니터링 시스템을 직접 구축한 경험과 그 가능성을 공유합니다.

발표 대상

외부 SaaS 도구의 한계를 경험해본 개발자
프론트엔드/SDK 에러 모니터링에 관심 있는 개발자
AI Agent를 활용한 개발 생산성 향상에 관심 있는 개발자
사내 인프라를 활용한 자체 도구 구축을 고민 중인 팀

◎ NAVER Engineering Day란?

NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요.
2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기)
올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다.

AI 에이전트를 위한 Playwright E2E 테스트 하네스 구축하기

2026-06-15T19:51:03+09:00

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2026(5월)에서 발표되었던 세션을 공개합니다.

발표 내용

AI 에이전트가 코드를 짜는 시대, 우리는 그 코드를 어떻게 믿을 수 있을까요? Playwright 기반 E2E 테스트를 구축하고, 에이전트가 직접 테스트 코드를 작성 및 검증하는 워크플로우를 만든 여정을 공유합니다.

발표 대상

특히 이런 분들에게 추천 드립니다.
- "에이전트로 '딸깍'할 수 있는 대규모 코드베이스를 만들고 싶어요"
- "E2E 테스트, 어디서부터 시작해야 할지 모르겠어요"
- "테스트 짜본 적 없는데, 에이전트한테 시키고 싶어요"
- "테스트 깨질 때마다 사람이 고치느라, 오히려 생산성이 줄었어요"
- "테스트가 실패하면 에이전트가 알아서 고치게 하고 싶어요"

◎ NAVER Engineering Day란?

NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요.
2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기)
올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다.

MLXP : Kubernetes LLM Serving 최적화 기술 도입기

2026-06-11T20:16:31+09:00

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2026(5월)에서 발표되었던 세션을 공개합니다.

발표 내용

LLM 추론 성능을 극대화하기 위한 최신 기술들(KV Cache 인지 라우팅, Prefix Cache, 분산 멀티노드 서빙 등)을 Kubernetes 프로덕션 환경에 도입하는 과정에서 기존 인프라 스택(Istio 서비스 메시, 스케줄러, Pod 보호 정책)과 충돌하며 발생한 실전 문제들을 어떻게 진단하고 해결했는지 공유합니다.

발표 대상

Kubernetes 위에서 GPU 워크로드를 운영하는 플랫폼 엔지니어
LLM 서빙 인프라를 직접 구축·운영하는 MLOps / Infra 엔지니어
Istio 서비스 메시 환경에서 AI 워크로드를 다루는 DevOps 엔지니어

◎ NAVER Engineering Day란?

NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요.
2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기)
올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다.

비개발자의 AI 협업 도전기 — 생산성 측정하려다 서버까지 띄운 9일

2026-06-13T01:08:37+09:00

"조직이 잘하고 있는지 어떻게 알 수 있을까?" 이 질문에서 출발해 사내 가이드 문서와 AI를 붙들고 직접 측정 도구를 완성하기까지 9일이 걸렸습니다. 그 과정을 기록으로 남깁니다.

사내 생산성 측정에 관한 고민

기술 PM으로 일하면서 조직과 프로젝트의 생산성을 어떻게 측정할지는 늘 풀리지 않는 과제였습니다. 스프린트를 원활하게 진행하는 것 같아도 막상 이를 수치로 보여달라고 하면 난감했습니다. 속도가 빨라지는지, 병목이 어디서 발생하는지, 지난 분기보다 나아지고 있는지 감각적으로는 알 수 있었지만 데이터로 명확히 설명하기는 어려웠습니다.

사내에는 이미 'DevOps board'라는 시스템이 있어 배포 빈도와 리드타임을 포함한 DORA 지표를 제공하고 있습니다. 소프트웨어 딜리버리 흐름을 측정한다는 점에서 제가 찾던 도구에 가까웠습니다. 다만 저는 분석 지표와 상황에 맞추어 조금 더 세분화된 데이터를 들여다보고 싶었습니다.

그래서 먼저 Jira 대시보드를 만들어 리치 필터(rich filter)로 데이터를 추출해 보았습니다. 이슈 완료 수, 스프린트 완료율, 컴포넌트별 작업량 등 여러 수치가 모였지만, 수집한 숫자만으로는 조직의 작업 속도를 한눈에 파악하기 어려웠습니다. 작업이 어디서 얼마나 걸리는지도 보이지 않았습니다. Jira는 업무를 관리하는 도구일 뿐 소프트웨어 딜리버리 흐름 전체를 측정하는 도구는 아니기 때문입니다.

결국 특정 컴포넌트 기준의 분류, 팀 고유의 이슈 타입 정의, 팀 내 업무 흐름을 세밀하게 들여다볼 수 있는 맞춤형 도구가 필요했습니다. 기존 DevOps board를 대체하려는 것이 아니라, 팀의 상황에 맞추어 데이터를 직접 구성해 보고 싶었습니다.

문제는 제가 이를 직접 구현할 기술적 역량이 부족하다는 점이었습니다. 개발자에게 부탁하기에는 작업 규모가 작았고, 백로그에 등록하더라도 언제 진행될지 기약할 수 없었습니다. 그래서 AI의 도움을 받아 직접 만들어 보기로 했습니다.

1단계: HTML 파일 하나로 가설 검증

처음에는 배포, 서버, 인증 과정을 모두 생략하고 HTML 파일 하나로 가볍게 시작했습니다. 브라우저에서 Jira 변경 기록(changelog) CSV 파일을 파싱해 바로 시각화하는 구조였습니다.

AI에게 전달한 첫 프롬프트에는 현재 상황과 맥락을 최대한 자세히 담았습니다.

Jira 이슈별 changelog CSV에는 'Issue Key', 'Status', 'Created' 칼럼이 있어.

각 이슈가 'In Progress'로 처음 전환된 시각과 'Done'으로 전환된 시각의 차이를 일(day) 단위로 계산하고 싶어. 팀별, 이슈 타입별로 집계해서 주차별 트렌드를 보여주는 웹 대시보드를 만들고 싶은데,

구조는 이해하지만 직접 구현은 못 해.

이 프롬프트에는 데이터 형식, 원하는 결과물, 그리고 저의 기술적 한계가 모두 들어가 있습니다.

AI는 곧바로 코드를 작성하는 대신 발생할 수 있는 예외 상황(edge case)을 먼저 짚어 주었습니다.

이슈가 In Progress → Backlog → In Progress로 다시 이동했다가 Done이 되는 경우, 리드타임 기산점을 첫 번째 In Progress로 할지 마지막으로 할지 정의가 필요해요. Done 이후 재오픈 케이스는요?

이 질문을 받기 전까지는 저 역시 이러한 예외 상황을 생각하지 못했습니다. 실제로 확인해 보니 데이터에 해당 사례가 적지 않게 포함되어 있었습니다. 결국 AI와 대화하는 과정 자체가 요구사항 정의 세션이 된 셈입니다.

물론 초기에는 버그도 있었습니다. Jira CSV의 타임스탬프가 UTC 기준이라 KST로 변환해 날짜를 계산해야 했고, 내보내기 설정에 따라 이슈 타입 필드명이 달라지는 문제도 있었습니다. 이럴 때는 문제를 말로 설명하기보다 실제 CSV 헤더와 샘플 데이터 일부를 AI에게 그대로 보여주는 편이 훨씬 효과적이었습니다.

이렇게 해서 대시보드 화면에 리드타임 수치가 나타났습니다. 하지만 그 숫자를 보면서 새로운 의문이 생겼습니다. 이 수치가 좋은 편인지 나쁜 편인지는 어떻게 알 수 있을까요?

2단계: DORA 지표를 통한 기준 마련

리드타임을 측정하는 것과 그 수치의 의미를 파악하는 것은 별개의 문제였습니다. 그래서 소프트웨어 딜리버리 성과를 측정하는 프레임워크인 DORA 지표를 참고했습니다. DORA 지표는 수많은 팀과 프로젝트의 데이터를 분석해 도출한 네 가지 핵심 지표로 구성됩니다.

배포 빈도
변경 리드타임
변경 실패율
서비스 복구 시간

여러 연구를 통해 이 네 가지 지표가 팀의 딜리버리 역량을 가장 잘 설명한다는 사실이 검증되었습니다.

제가 측정한 Jira 리드타임은 이 중 '변경 리드타임'에 해당했습니다. 작업 시작부터 실제 배포까지 걸리는 시간입니다. 나머지 지표를 확인하려면 추가 데이터가 필요했습니다. 배포 빈도는 배포 이벤트 로그에서, 변경 실패율과 복구 시간은 PR(Pull Request) 및 이슈 데이터에서 얻을 수 있었습니다.

결국 Jira 데이터만으로는 전체 딜리버리 흐름의 절반만 볼 수 있었습니다. 나머지 절반을 채우려면 사내 GitHub 데이터를 연동해야 했습니다.

3단계: AI를 활용한 서버 구축과 가이드 문서

GitHub API를 주기적으로 호출하고 이를 Jira 데이터와 결합하려면 단순한 브라우저용 HTML 환경으로는 부족했습니다. 별도의 서버가 필요해진 것입니다.

사실 이 시점에서 진행을 포기할까 고민도 했습니다. Dockerfile을 한 번도 작성해 본 적 없는 비개발자가 컨테이너 기반 배포를 직접 해낼 수 있을지 확신이 서지 않았기 때문입니다.

일단 사내 공통 컨테이너 플랫폼인 'n3r'의 가이드 문서부터 찾아보았습니다. 하지만 낯선 용어가 많아 문서 첫 페이지부터 막막했습니다. 그래서 접근 방식을 바꿨습니다. 가이드 문서를 혼자 끙끙대며 읽는 대신, 그 내용을 AI에게 전달하고 함께 해석해 나가기 시작한 것입니다.

이 가이드에 이렇게 나와 있는데, 파이썬 FastAPI 앱에 적용하면 Dockerfile을 어떻게 써야 해? [가이드 해당 섹션 붙여넣기]

가이드 문서에는 사내 환경과 표준 규칙이 담겨 있습니다. AI는 그 내용을 제 상황에 맞게 구체화해 주었습니다. 둘 중 어느 한쪽만으로는 해결이 어려웠지만, 가이드 문서와 AI를 교차로 활용함으로써 무사히 서버를 띄울 수 있었습니다.

4단계: 스케줄러 설정과 데이터 누락 문제 해결

서버를 구축했다고 해서 데이터가 저절로 모이는 것은 아닙니다. Jira와 GitHub API를 주기적으로 호출해 줄 스케줄러가 필요했습니다. 다행히 사내에는 이미 Self-Hosted Runner 환경과 관련 설정 가이드 문서가 마련되어 있었습니다.

돌이켜보면 9일 중 가장 많은 시간을 이 구간에서 소요했습니다. Runner 환경 변수 설정, 인증 토큰 발급, API 페이지네이션(pagination) 처리 등 예상치 못한 문제가 꼬리를 물고 나타났기 때문입니다.

그중에서도 가장 애를 먹었던 부분은 API 페이지네이션이었습니다. 조회할 이슈가 1,000개를 넘어가면 API 응답이 중간에 잘리는데, 초기에 AI가 작성한 코드에는 이 예외 처리가 누락되어 있었습니다. 오류 메시지조차 없이 데이터만 조용히 누락되고 있었고, 나중에 직접 숫자를 대조하며 검증하다가 우연히 발견했습니다.

이 과정을 거치며 제가 AI에게 질문하는 방식도 달라졌습니다. 초반에는 "이거 어떻게 해요?"에 가까웠다면, 나중에는 가이드 내용, 현재 설정 파일, 오류 메시지를 함께 붙여 "이 값을 내 상황에 어떻게 적용하면 돼?"라고 물었습니다. 상황과 맥락을 자세히 전달할수록 AI의 답변은 훨씬 정확해졌습니다.

5단계: 사내 스토리지 연동과 사람의 역할

수집한 데이터를 저장하고 필요할 때 화면에 제공하려면 스토리지가 필요했습니다. 사내에서 제공하는 Redis 기반 스토리지인 nBase-ARC를 활용하기로 하고 관련 가이드 문서를 참고했습니다.

AI는 보편적인 Redis 사용법은 훌륭하게 알려 주었습니다. 하지만 사내의 특수한 네트워크 정책, 고유한 TTL 설정 방식, 접근 권한 신청 프로세스 같은 내부 정보는 알지 못했습니다. 이런 부분에서는 사내 가이드 문서와 사내 AI 기반 문의 채널 ASK가 도움이 되었습니다.

널리 공개된 기술 스택을 다룰 때 AI는 탁월한 조력자입니다. 하지만 사내 특화 환경, 내부 정책, 조직 고유의 관행은 AI가 파악할 수 없는 영역입니다. 이 영역은 결국 사람이, 문서가, 동료가 채워야 합니다.

완성된 대시보드의 효과

이제 Jira와 GitHub 데이터는 매일 자동으로 수집됩니다. 대시보드에 접속하면 조직과 프로젝트의 전반적인 딜리버리 흐름을 한눈에 확인하고 다음과 같은 것들을 쉽게 파악할 수 있습니다.

리드타임이 유독 길어지는 구간
특정 이슈 타입에서 반복되는 병목 현상
스프린트 후반부에 배포 이벤트가 몰리는 패턴

'요즘 왠지 개발 속도가 느려진 것 같다'는 막연한 느낌을 이제는 데이터를 근거로 설명할 수 있게 되었습니다.

물론 이 대시보드가 완벽한 측정 도구는 아닙니다. DORA 지표를 온전히 구현한 것도 아닙니다. 하지만 측정 도구가 아예 없었을 때와 비교하면 확실한 차이가 있습니다. 가장 큰 변화는 조직 회고 시간의 논의 수준이 달라졌다는 점입니다. 막연한 감이 아니라 실제 데이터를 보면서 이야기하게 되었습니다.

프로젝트를 진행하며 배운 점

기획의 재발견: AI는 마법사가 아니라 정밀한 조각가다

AI는 사용자가 원하는 바를 구현하는 데 탁월한 능력을 보여줍니다. 하지만 그 전제는 사용자 스스로 '무엇을 원하는지'를 명확히 알고 있어야 한다는 것입니다.

작업을 하면서 특히 효과적이라고 느낀 소통 방식은 다음 세 가지였습니다.

실제 데이터를 예시로 보여주기
발생 가능한 예외 상황을 미리 정의하기
기대한 결과와 실제 결과의 차이를 명확히 짚어 주기

이 세 가지 요건이 충족될 때 AI는 가장 정확한 결과물을 내놓았습니다. 결국 기획이란 필요한 기능을 나열하는 작업이 아니라, AI가 올바르게 이해하고 작업할 수 있도록 꼼꼼한 설계도를 그리는 과정이었습니다. 얼마나 명확하고 구체적으로 지시하느냐가 최종 결과물의 품질을 결정했습니다.

인프라의 벽: 가이드와 AI, 둘 다 필요했다

서버를 구축하는 과정에서는 사내 가이드 문서와 AI를 함께 활용해야 했습니다. 가이드 문서는 사내 환경을 정확히 설명해 주었지만 제 프로젝트 상황에 딱 맞는 답을 주지는 못했습니다. 반대로 AI는 기술적 원리를 잘 설명해 주었지만 사내 환경의 특수성은 알지 못했습니다.

따라서 이 둘을 교차해서 쓰는 것이 가장 효율적이었습니다. 가이드 문서의 내용을 AI에게 알려 주고 그 의미를 함께 해석하는 방식입니다. 가이드 문서가 '무엇을' 해야 하는지 알려주면, AI가 '어떻게' 해야 하는지 구체화했습니다.

새로운 아이디어의 실현은 도구의 발전에서 비롯되지만, 그것이 지속 가능하게 유지하는 힘은 안정적인 인프라에서 나옵니다. 그리고 비개발자조차 그 인프라에 접근해 활용할 수 있도록 길을 열어 주는 것은 결국 잘 작성된 가이드 문서입니다.

토큰의 무게: AI는 공짜가 아니다

AI를 활용하면서 토큰(비용)이 유독 많이 소모되는 구간이 있었습니다. 대체로 다음과 같은 상황이었습니다.

AI가 매번 코드 전체를 새로 읽게 했던 초반
대화 맥락을 정리하지 않고 질문을 무분별하게 이어 갔던 중반
분석 탭에서 AI API를 3번 순차 호출하던 구조

해법은 '역할 분리'였습니다. 데이터 파싱이나 집계 같은 단순 계산은 JavaScript 코드가 직접 처리하도록 하고, AI에게는 최종적으로 요약된 수치만 전달해 의미 해석을 맡기는 구조로 바꿨습니다. 그러자 토큰 사용량이 눈에 띄게 줄었고 응답 속도도 훨씬 빨라졌습니다.

어떤 기능을 구현하기 전에는 "이 작업을 반드시 AI가 처리해야 하는가?"를 먼저 자문해 볼 필요가 있습니다. 명확한 규칙으로 처리할 수 있는 작업은 코드로 해결하고, AI는 문맥 판단이나 해석이 필요한 영역에만 제한적으로 활용하는 편이 효율적입니다.

AI의 한계: 오류가 없다고 올바른 것은 아니다

가장 많은 시간을 낭비하게 만든 것은 역설적이게도 AI가 확신에 차서 작성해 준 코드였습니다. 앞서 언급한 API 페이지네이션 코드는 겉보기에는 아무런 오류 없이 매끄럽게 동작했습니다. 하지만 이슈가 1,000개를 넘어가는 순간부터 데이터가 시스템 내부에서 조용히 누락되고 있었습니다. 출력된 수치를 꼼꼼히 검증해 보지 않았다면 끝까지 몰랐을 문제였습니다.

따라서 AI가 만들어 준 코드는 오류 없이 실행되는지 확인하는 선에서 그쳐서는 안 됩니다. 도출된 결과가 실제로 정확한지 정합성을 검증하는 단계가 반드시 필요합니다. 샘플 데이터로 직접 계산한 값과 AI의 결과물을 대조해 보는 과정은 번거롭지만 생략할 수 없습니다.

생태계의 제언: '데이터 민주주의'를 위한 조건

비개발자인 제가 이 프로젝트를 무사히 마칠 수 있었던 것은 AI의 능력 덕분만은 아니었습니다. 든든한 사내 가이드 문서가 뒷받침되었기에 가능한 일이었습니다. 가이드 문서가 없었다면 아무리 훌륭한 AI라도 사내 환경에 맞는 결과물을 만들어내기 어려웠을 것입니다.

회사에는 방대한 데이터와 훌륭한 인프라가 있습니다. 하지만 권한은 열려 있어도 이를 실제로 활용할 수 있는 사람은 극소수인, 이른바 '접근은 가능하지만 접근할 수 있는 사람은 없는' 상태에 머무는 경우가 많습니다.

API 사용 가이드를 조금 더 체계적으로 다듬고, 자주 쓰이는 템플릿 코드를 사내에 공유하고, 보안 가이드라인을 명확히 제시해 주는 것만으로도 수많은 사내 맞춤형 도구가 새롭게 만들어질 수 있습니다. 비개발자가 AI와 협업해 가치 있는 무언가를 만들어 내는 진정한 전제 조건은 결국 '친절하고 정확한 가이드 문서'입니다. AI는 사용자가 그 가이드를 조금 더 쉽게 소화하고 자기 상황에 적용할 수 있도록 돕는 훌륭한 조력자일 뿐입니다.

마치며

불과 9일 전의 저는 스스로 서버를 구축할 수 있을 거라고는 생각도 못 했습니다. 그런데 결국 Dockerfile을 작성하고, 컨테이너를 빌드해 배포하고, API를 주기적으로 호출하는 스케줄러를 구성했으며, Redis에 데이터를 읽고 쓰는 경험까지 했습니다. 코드는 대부분 AI가 작성해 주었지만, '무엇을 만들 것인지', '어떤 구조로 설계할 것인지', '최종 결과물이 올바른지'를 판단하는 몫은 온전히 제게 있었습니다.

대시보드의 숫자를 보며 종종 생각합니다. '우리 조직과 프로젝트는 잘 나아가고 있나?' 예전에는 막연했던 그 질문에, 이제는 데이터를 근거로 조금은 명확한 답을 할 수 있게 되었습니다.

동료에게서 "이거 어떻게 만드셨어요?"라는 질문을 받을 때마다 저는 이렇게 답하곤 합니다.

"AI한테 말로 시켰어요. 그런데 뭘 시킬지는 제가 알아야 했어요."

이 글을 통해 전하고 싶은 메시지는 단 하나입니다. AI를 잘 활용하는 조직은 성능 좋은 AI 도구를 선별하는 데 그치지 않고, AI가 역량을 제대로 발휘할 수 있는 밑바탕 환경을 먼저 탄탄하게 갖춘 조직입니다.

데이터를 같은 기준으로 관리하려는 조직적 합의
누구나 안전하게 접근하여 실험할 수 있는 열린 인프라
비개발자도 천천히 따라갈 수 있도록 작성된 가이드 문서

이 세 가지가 바로 AI 시대에 필요한 인프라입니다.

LLM·하네스로 더 좋은 n8n 워크플로 생성하기

2026-06-17T09:00:00+09:00

LLM에 정확한 정보와 도구를 제대로 쥐여 주면 더 높은 품질의 n8n 워크플로를 생성할 수 있습니다. 이 글은 LLM의 작업 환경 전체를 설계하는 접근 방식인 '하네스(Harness)'를 만들어 실험한 내용을 다뤘습니다. 같은 모델과 같은 요청을 두고 하네스 수준만 바꿨을 때 모델이 생성한 n8n 워크플로 품질이 어떻게 달라지는지 소개합니다.

AI 시대의 브랜드 그래픽 시스템 구축기

2026-06-19T14:56:11+09:00

여기어때 트립홀릭 그래픽 언어 리뉴얼 프로젝트

여기어때에는 우수한 후기를 남겨주시는 상위 0.1% 여행자들의 커뮤니티가 있다는 사실, 알고 계셨나요? 바로 <트립홀릭> 입니다.🚩

<트립홀릭>이 어떤 브랜드인지 궁금하시다면 지난 글 🔗리뷰를 쓰면 한정판 굿즈를 준다고? 에서 자세히 확인하실 수 있습니다.

이번 글에서는 트립홀릭의 새로운 얼굴이 된 그래픽 에셋을 소개하고, AI 시대에 일관된 비주얼 브랜딩을 유지하기 위해 고민했던 과정을 공유해보려 합니다. ☺️

브랜드가 성장할수록 그래픽은 다양한 채널과 작업자들을 통해 확장되며 그 과정에서 단순히 새로운 그래픽을 만드는 것을 넘어, 트립홀릭만의 그래픽 언어를 정의하고 이를 누구나 활용할 수 있는 그래픽 생성 시스템으로 발전시키고자 했습니다.

이 글은 그래픽 에셋 제작기보다는, 브랜드 그래픽을 어떻게 관리하고 확장할 것인가에 대한 고민의 기록에 더 가까울지도 모르겠습니다.

그 과정에서 얻은 경험과 나름의 해결 방안을 함께 소개해보겠습니다. 💁🏻‍♂️

왜 그래픽이 필요했을까?

트립홀릭은 지난 4년간 다양한 프로젝트와 이벤트를 통해 성장해왔습니다.👏

그 과정에서 웰컴파티, 굿즈, SNS 콘텐츠, 이벤트 등 각 접점의 목적에 맞는 다양한 그래픽이 만들어졌고, 이는 트립홀릭의 활동과 경험을 더욱 풍성하게 만들어 주었습니다. 🎉

하지만 브랜드가 성장하고 활동 영역이 넓어질수록 새로운 고민이 생겼습니다.

각 프로젝트마다 완성도 높은 그래픽이 사용되고 있었지만, 트립홀릭을 하나의 브랜드로 연결해 주는 공통된 비주얼은 부족했습니다.

그래서 자연스럽게 이런 질문에 도달하게 되었습니다.

“트립홀릭을 어떻게 표현해야 하나의 브랜드로 보여줄 수 있을까?” 🤔

말풍선에서 시작된 그래픽

그래픽 모티프

BXD1팀은 트립홀릭의 일관된 비주얼 브랜딩을 위해 가장 먼저 브랜드의 본질을 다시 살펴봤습니다.

트립홀릭은 단순히 여행지를 소개하는 서비스가 아닙니다.

여행 경험을 공유하고, 좋은 여행 정보를 나누며, 사람들과 소통하는 커뮤니티입니다. 🧳 🤝

우리는 이 과정에서 반복적으로 등장하는 세 가지 키워드를 발견했습니다.

<리뷰, 소통, 커뮤니티>

그리고 이 세 가지를 가장 직관적으로 표현할 수 있는 형태로 말풍선을 선택했습니다. 💬

말풍선은 여행 경험을 공유하는 행동을 상징하는 동시에, 사람과 사람을 연결하는 트립홀릭의 정체성을 담고 있었습니다.

이후 우리는 말풍선을 하나의 그래픽 모티프로 확장해 트립홀릭만의 그래픽 언어를 만들어 나가기 시작했습니다. 🛠️

하나의 브랜드 하나의 그래픽언어

트립홀릭 그래픽 에셋 중 일부

트립홀릭은 다양한 외부 협력사와 함께 운영되는 브랜드로, SNS 콘텐츠부터 이벤트 제작물까지 다양한 작업이 동시에 진행됩니다.

그래픽 에셋이 있더라도 프로젝트에 맞춰 새로운 그래픽은 계속 필요하게 됩니다.

자연스럽게 이런 고민이 생겼습니다.

“새롭게 만들어지는 작업물들도 트립홀릭처럼 보일 수 있을까?”

또한 기존 방식에서는 새로운 그래픽이 필요할 때마다

그래픽 요청 → 디자인 → 커뮤니케이션 → 검수 → 배포

과정을 반복했으며 기존 에셋을 활용해 작업하더라도 지속적인 확인과 피드백이 필요했습니다. 😅

디자인 파일 형태의 에셋이 많아질수록 관리와 공유의 범위가 넓어지고, 작업자마다 그래픽을 해석하는 방식 역시 달라질 수 있기 때문에 결국 브랜드의 일관성을 유지하기 위해 많은 커뮤니케이션과 제작 리소스가 발생하고 있었습니다. 🫠

그래서 우리는 브랜드 일관성과 작업 효율성을 동시에 해결할 수 있는 방법을 찾기 시작했습니다.

그래픽 에셋을 처음부터 구축하는 과정이었기에 오히려 새로운 접근이 가능했습니다.

마침 생성형 AI가 빠르게 발전하면서, 많은 사람들이 동일한 프롬프트를 활용해 특정 스타일의 이미지를 생성하는 사례들이 등장하고 있었습니다. 🤖

이를 보며 하나의 아이디어가 떠올랐습니다. 기존처럼 그래픽 에셋과 디자인 가이드를 공유하는 것이 아니라,

“누구나 트립홀릭 그래픽을 생성할 수 있는 규칙 자체를 공유하면 어떨까?”

그래픽 결과물을 전달하는 대신, 그래픽을 만들어내는 언어를 전달하는 것입니다. 그렇게 우리는 트립홀릭 그래픽 에셋을 프롬프트로 정의하고,

이를 기반으로 누구나 동일한 그래픽 언어를 사용할 수 있는

<트립홀릭 그래픽 생성 시스템> 구축을 시작했습니다. 👩‍💻

AI 시대의 그래픽 에셋

먼저 기존에 제작되어 있던 트립홀릭 그래픽들을 ChatGPT와 Gemini에 학습시키며, 그래픽이 공통적으로 가지고 있는 특징들을 분석했습니다. 🧐

분석 과정에서 그래픽의 특성을 크게

형태(Shape), 스타일(Style), 표현 방식(Rendering)

세 가지 요소로 구분했습니다.

이후 각 요소를 프롬프트 언어로 변환하고, 반복적인 생성 테스트를 통해 하나의 구조화된 프롬프트로 정리해 나갔습니다.

생성 결과를 검증하며 형태가 달라지는 경우, 불필요한 디테일이 추가되는 경우 등 다양한 예외 상황을 보완했고, 그 결과 최종적으로는 트립홀릭 그래픽의 특징과 톤앤매너를 안정적으로 재현할 수 있는 생성 규칙을 구축할 수 있었습니다.

Chat GPT를 활용한 실제 생성 사례

에셋을 넘어 비주얼 시스템으로

트립홀릭 비주얼 시스템 가이드 중 일부

그래픽 생성 시스템을 구축한 이후에는 이를 실제 브랜드 운영에 적용하기 위한 비주얼 가이드 정리가 이어졌습니다.

BXD1팀의 라이카와 함께 로고, 컬러, 폰트, 그래픽 에셋은 물론 그래픽 생성 시스템까지 하나의 체계로 정리하며 트립홀릭 비주얼 가이드를 구축했습니다. 🤝

이를 통해 트립홀릭은 단순한 그래픽 에셋 모음을 넘어, 누구나 동일한 브랜드 경험을 만들 수 있는 비주얼 시스템을 갖추게 되었습니다. 🎨 ⚙️

에셋을 넘어 비주얼 시스템으로

이번 프로젝트는 단순히 그래픽 에셋을 제작하고 비주얼 가이드를 만드는 것을 넘어, 트립홀릭을 표현하는 일관된 시각 언어를 구축하고 이를 누구나 활용할 수 있도록 시스템화하는 과정이었습니다. 🧑‍🔧

과거에는 그래픽 파일과 에셋을 공유했다면, 이제는 AI를 활용해 동일한 그래픽을 만들어낼 수 있는 규칙과 언어를 공유하는 시대가 되었습니다.

트립홀릭 그래픽 리뉴얼 역시 이러한 변화에 맞춰 브랜드 에셋을 관리하고 확장하는 새로운 방식을 실험한 프로젝트였습니다.

물론 아직 완성된 답을 찾았다고 생각하지는 않습니다. 브랜드가 성장하고 새로운 경험이 만들어질수록 그래픽 시스템 역시 함께 발전해야 하기 때문입니다. 🏃‍➡️

무엇보다 시스템은 가이드북 안에서 완성되지 않습니다. 실제 브랜드 경험 속에서 사용되고 확장될 때 비로소 의미를 갖게 됩니다.

트립홀릭 그래픽 시스템 또한 그래픽 에셋과 프롬프트를 정리하는 것에서 끝나지 않고, 다양한 접점에서 하나의 브랜드 경험으로 연결되는 것을 목표로 하고 있습니다. 🧗‍♂️

다음 글에서는 이번에 구축한 트립홀릭 그래픽 시스템이 6기 웰컴파티에 어떻게 적용되었는지, 하나의 그래픽 언어가 공간, 콘텐츠, 굿즈 전반으로 확장되며 실제 브랜드 경험으로 구현된 과정을 소개해 드리겠습니다.

여행의 경험을 공유하는 트립홀릭처럼, 이번 프로젝트를 통해 얻은 경험 역시 여러분과 함께 나누며 글을 마치겠습니다. 🫰✈️

Written by Bigo

AI 시대의 브랜드 그래픽 시스템 구축기 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

90일 동안 내 편이 생겼다! 짝꿍 제도

2026-06-16T10:46:24+09:00

여기어때 컬처 라운지 ep. 19

안녕하세요! 여기어때의 조직문화와 사람 이야기를 전하는 <컬처 라운지>입니다. 😊

지난 3편에 걸쳐 서류 지원부터 대망의 입사 첫날 ‘웰컴 세션’까지의 여정을 함께 살펴보았는데요. 혹시 글을 읽으시면서 이런 걱정이 들진 않으셨나요?

‘첫날 오후 3시, 온보딩 교육이 모두 끝나고 나면… 이제 진짜 나 혼자 남겨지는 걸까?’

‘팀원들 모두 바빠보이는데, 이런 질문 자꾸 해도 되는걸까?’

새로운 환경에 홀로 던져진 것 같은 막막함과 두근거림, 누구나 한 번쯤 느껴보셨을 텐데요. 여기어때에서는 그런 걱정을 하실 필요가 전혀 없답니다. 문을 열고 나서는 순간, 여러분의 손을 따뜻하게 잡아줄 ‘짝꿍’이 기다리고 있으니까요!

오늘은 신규 입사자들이 입을 모아 “가장 만족스러웠던 온보딩 프로그램”으로 꼽는 여기어때만의 특별한 문화, 🧩‘짝꿍 제도’를 소개해 드릴게요.

🤝 ‘짝꿍’이라는 든든한 존재

많은 IT 기업에서 신규 입사자의 적응을 돕는 ‘버디(Buddy)’나 ‘사수’ 제도를 운영하고 있어요. 여기어때는 정겨운 ‘짝꿍’이라는 단어를 사용하고 있는데요! 단순히 업무만 가르쳐주는 관계를 넘어, 새로운 환경에 첫발을 디딘 동료에게 단짝 친구처럼 친근하고 편안한 조력자가 되기를 바라는 마음이 담겨있답니다.

실제로 신규 입사자분들께 “여기어때에 적응하며 가장 좋았던 점이 무엇인가요?”라고 여쭤보면, 단연 이 ‘짝꿍 제도’를 꼽는 분들이 많아요.

“새로 입사하면 이것저것 물어볼 게 정말 많잖아요. 그런데 다들 바빠 보일 때면 선뜻 말을 걸기가 망설여지곤 하거든요. 그때 ‘짝꿍’이라는 지정된 소통 창구가 있으니 미안해할 필요 없이 언제든 편하게 질문할 수 있어서 정말 든든했어요. 짝꿍분도 강한 책임감을 가지고 친절하게 알려주셔서 회사 생활에 빠르게 적응할 수 있었어요.”

이처럼 짝꿍은 신규 구성원이 여기어때라는 새로운 여행지에 무사히 도착해 안전하고 부드럽게 체크인(Soft Landing)할 수 있도록, 입사 후 90일 동안 가장 가까이서 길잡이가 되어주고 있어요. 👼

📋 꼼꼼한 ‘짝꿍 가이드북’

여기어때의 짝꿍 제도는 단순히 “새로 오신 분 잘 챙겨주세요~”라는 말 한마디로 끝나지 않아요. 신규 구성원이 방치되거나 헤매지 않도록 꼼꼼하게 설계되어 있답니다.

인사팀에서는 짝꿍이 된 선배 젊은이에게 90일 동안 시기별로 해야 할 미션들이 담긴 [짝꿍 가이드]북을 전달하는데요. 짝꿍은 가이드의 타임라인을 따라 크게 5가지 핵심 역할을 수행하며 새로운 동료의 안착을 돕습니다.

❤ ️팀에 대한 이해 돕기: 입사 첫날, 교육장 앞으로 직접 마중을 나가 팀원들과의 첫인사를 주선하고 첫 점심 식사를 함께해요. 이후 팀의 고유한 문화와 일하는 방식을 자연스럽게 익힐 수 있도록 도와줘요.
️❤ 전사 공통 시스템 & 협업 툴 사용 돕기: 매일 사용하는 메신저와 업무 협업 툴 세팅, 필수 권한 신청 등 보안 가이드까지 꼼꼼하게 챙겨주어 초반의 막막함을 덜어줘요.
❤ 업무 적응 돕기: 직무 관련 히스토리와 참고 자료들을 적극적으로 공유하고, 실제 업무 피드백을 주며 담당 업무에 연착륙할 수 있도록 실무적으로 지원해요.
❤ 회사 내 소셜 네트워킹 돕기: 타 팀 동료들과의 캐주얼한 소통을 도와 회사 내 인맥을 넓혀주고 네트워킹을 도와요.
❤ 심리적 안정감 : 정기적인 티타임 시간을 가지며 새로운 조직에 적응하며 겪는 정서적 부담을 낮춰줘요.

입사 첫날 픽업부터 팀원들과 다 같이 참여하는 ‘소통 맥주’ 까지, 가이드에 적힌 미션들을 타임라인에 맞춰 하나씩 지워가다 보면 신규 구성원도 자연스럽게 조직에 녹아들게 된답니다.

💡 실제 짝꿍들은 어떤 도움을 주고 있을까요?

여기어때는 프로덕트, 개발, 리서치, 촬영, 마케팅 다양한 직무가 모여서 서비스를 만드는 만큼, 짝꿍들의 케어 방식도 직무마다 조금씩 달라요.

실제로 90일 동안 짝꿍들은 구체적으로 어떤 순간에 함께하며 새로운 구성원의 안착을 돕고 있을까요?

짝꿍이 제출한 미션 카드의 내용을 슬쩍 보여드릴게요! 🔎

💻 개발 직군 #아키텍처_설계공유 #과거히스토리_브리핑

대규모 프로젝트 구조를 빠르게 파악할 수 있도록 주요 프레임워크들의 역할과 모듈화 구조, 아키텍처 설계 의도를 일대일로 세심하게 공유했어요. 또한, 눈앞의 소스 코드만 봐서는 알기 어려운 과거의 변경 히스토리와 API 리프레시 정책, 앱 전반의 날짜 변경 동기화 정책까지 상세히 브리핑하며 첫 피쳐 개발을 성공적으로 도왔습니다.

🤝 영업 직군 #제휴점_동반미팅 #정산데이터_피벗테이블

주요 제휴점과 만나는 미팅 자리에 동반하여 세일즈 담당자분들을 소개해드리고, 수수료 인상도 함께 협의하며 소통 물꼬를 터드렸어요. 또한, 까다로운 양도양수 계약 과정과 실적 데이터를 쉽게 추출하는 엑셀 피벗 테이블 노하우도 전수해드렸습니다!

📊 리서치 직군 #전사유관팀_런치챗 #리서치실사_밀착참여

리서치 직군 특성상 유관 팀과의 협업/소통이 많으므로, 신규 구성원이 어색해하지 않도록 프로덕트센터 내 모든 팀과 릴레이 점심 티타임을 주선했어요. 또한, 복잡한 리서치 단계를 쉽게 이해할 수 있도록 말로만 설명하지 않고 실제 리서치 과정 중에 보조 역할로 밀착 참여해 든든하게 서포트했습니다.

📸 콘텐츠 직군 #드론_시뮬레이터 #포트폴리오_공유

인테리어 촬영이 처음이라 구도에 어려움을 겪는 신규 구성원에게 유명 건축 사진가들의 작례와 전문 잡지를 공유하며 구도 감각을 다질 수 있게 도왔어요. 더불어, 드론 시뮬레이터를 이용해 언제든지 드론 조작을 연습할 수 있는 환경을 지원해드렸습니다!

이처럼 각 직무의 언어와 환경에 맞춰 깊이 고민해 주는 짝꿍이 있기에, 신규 구성원들은 실무의 막막함을 빠르게 지워낼 수 있습니다. 이 친절한 가이드북 미션 중에서도 유독 ‘더 가벼운 마음’으로 대화를 건넬 수 있는 장치가 있습니다.

☕ 어색함이 사르르, ‘짝꿍 티타임 쿠폰’

바로 짝꿍과 쓸 수 있는 티타임 쿠폰인데요!

지하 1층 사내 라운지 카페에서 사용할 수 있는 이 쿠폰은 짝꿍에게 자연스럽게 다가가 티타임을 요청할 수 있는 아주 유용한 ‘명분’이 되어줍니다.

D+30 / D+60 / D+90 루틴: 한 달에 한 번씩, 총 3개월 동안 짝꿍과 함께 카페로 내려가 편안하게 커피 브레이크를 가질 수 있는 무료 음료 쿠폰입니다. (쿠폰 1장당 음료 2잔 이용 가능!)

평소 바빠 보이는 팀원들에게 차마 물어보기 힘들었던 소소한 질문들이나, 적응하면서 겪었던 작은 고민들을 이 시간을 통해 편안하게 풀어낼 수 있도록 배려한 세심한 장치랍니다.

누군가의 짝꿍이 되어 90일 동안 세심하게 마음을 쓴다는 건 분명 멋지지만, 그만큼의 에너지와 정성이 들어가는 일이죠.

여기어때는 선배 구성원들의 이러한 따뜻한 노력을 당연하게 여기지 않죠!

90일간 짝꿍과의 여정을 마무리하면, 고생한 짝꿍을 위해 소소하지만 선물도 드린답니다.🎁

낯선 환경에서 먼저 다정하게 손을 내밀어 주는 동료들이 있는 곳.

든든한 짝꿍과 함께 여기어때에서 여러분의 새로운 커리어를 시작해 보는 건 어때요?

여러분의 든든한 짝꿍이 되어줄 멋진 동료들이 오피스 라운지에서 여러분을 기다리고 있습니다. 😊

👉 [지금 진행 중인 여기어때 채용 공고 확인하고 내 짝꿍 만나러 가기]

90일 동안 내 편이 생겼다! 짝꿍 제도 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

에이전틱 리소스 디스커버리 규격 발표 등 6월 셋째 주 Google for Developers 위클리 업데이트를 지금 확인하세요!

2026-06-19T18:09:27.367+09:00

개발자 여러분, 안녕하세요!

6월 셋째 주 블로그에 발표된 Google의 주요 개발자 제품별 최신 소식을 살펴보세요.

[주요 개발자 블로그 업데이트]

AI & Machine Learning

에이전틱 리소스 디스커버리 규격 발표 (Announcing the Agentic Resource Discovery specification)
의료 AI 'AMIE'가 건강 관리에 기여할 수 있음을 증명한 새로운 연구 결과 (New research shows how AMIE, our medical AI, could help manage health conditions)
A2UI와 MCP 앱의 만남: 선언형 UI와 맞춤형 에이전틱 UI의 장점 결합하기 (A2UI + MCP Apps: Combining the best of declarative and custom agentic UIs)
보안 및 신뢰성 강화: Google 계정 로그인에 새로운 세션 메타데이터 추가 (Enhance Security and Trust: New Session Metadata in Sign in with Google)

Android

Android 17 정식 출시 (Android 17 is here)
Android 개발자 신원 확인: 함께 만들어가는 더 안전한 생태계 (Android developer verification: Building a safer ecosystem together)
Android XR, Geospatial API, Gemini를 활용한 혼합현실(MR) 투어 가이드 앱 빌드하기 (Building a Mixed-Reality Tour Guide with Android XR, the Geospatial API, and Gemini)
Android XR 신규 기능 살펴보기: 개발 도구, 엔진 지원, 생태계 업데이트 (What’s New in Android XR: Tooling, Engine Support, and Ecosystem Updates)

Flutter

Flutter 2분기 개발자 설문조사 참여하기 (Flutter Q2 survey)

* 국문 번역본으로 보시려면 Chrome 창에서 각 영문 링크로 이동한 후 마우스 우측 버튼을 눌러 ‘한국어로 번역'을 선택하시면 됩니다.

* 최신 개발자 문서에 대한 알림을 받아보려면, 여기에서 Google 개발자 프로필을 생성하여 손쉽게 살펴보세요. 다양한 개발자 학습 과정과 커뮤니티 이벤트에 참여하면 여러분의 프로필에 표시할 수 있는 온라인 인증 배지도 함께 드립니다.

Google for Developers

Gemini 3.5 라이브 번역 출시 등 6월 둘째 주 Google for Developers 위클리 업데이트를 지금 확인하세요!

2026-06-12T10:58:54.443+09:00

개발자 여러분, 안녕하세요!

6월 둘째 주 블로그에 발표된 Google의 주요 개발자 제품별 최신 소식을 살펴보세요.

[주요 개발자 블로그 업데이트]

AI & Machine Learning

‘Gemini 3.5 라이브 번역’을 통한 매끄럽고 자연스러운 음성 번역 (국문)
개발자를 위한 DiffusionGemma 핵심 가이드 (DiffusionGemma: The Developer Guide)
2026년 5월에 발표된 최신 AI 소식 총정리 (The latest AI news we announced in May 2026)
Google Colab CLI 출시 소식 살펴보기 (Introducing the Google Colab CLI)

Android

Android 개발자 생산성 향상을 위한 주요 업데이트 3가지 (Top 3 updates for Android developer productivity)
Datadog이 ProfilingManager를 통해 깊이 있는 성능 데이터를 제공하는 방법 (Datadog delivers millions of in-depth performance insights with ProfilingManager)

Firebase

Apple의 Foundation Models 프레임워크에 탑재된 Gemini 살펴보기 (Gemini in Apple's Foundation Models framework)

* 국문 번역본으로 보시려면 Chrome 창에서 각 영문 링크로 이동한 후 마우스 우측 버튼을 눌러 ‘한국어로 번역'을 선택하시면 됩니다.

Google for Developers

화이트햇 해커 취업, 어떤 직종이 있을까? - 사이버 보안 6개 직종 정리

2026-06-17T14:37:31+09:00

보안 업계 취업을 준비한다면 직종부터 알아야죠. 보안관제, 모의해킹, 포렌식, 컨설턴트 등 6개 직종이 실제로 무슨 일을 하는지 확인해 보세요.

디자이너에게 AI로 뭐든 만들어보라고 한다면

2026-06-19T21:40:00+09:00

지난 3월, 토스 디자인 챕터는 AI Contest를 열었어요. 규칙은 단 하나였어요. AI로 뭐든 만들어보기.

형식도 결과물도 자유예요. 업무와 관련 없어도 괜찮았고, 단순 재미로 만들어도 되고, 완성도가 높지 않아도 됐어요. 중요한 건 AI를 직접 만져보고, 자신의 문제를 스스로 해결해 보는 경험이었죠.

그렇게 한 달 동안 122개의 작업이 모였어요. 흥미로운 점은, 디자이너들이 AI를 활용하는 방식이 몇 가지 공통된 방향으로 나뉘었다는 거예요. 그중 인상적이었던 네 가지 사례를 소개할게요.

반복되는 일을 AI에 넘기다

컬러 추출 자동화 로직

이미지를 넣으면 UI에 쓸 색을 자동으로 추출·보정해 주는 로직이에요. 색 추출은 사진마다 결과가 제각각이라, 토스에서 몇 년째 진전이 없던 과제였어요. AI와 함께 보정 로직 초안을 코드로 만든 뒤, 샘플 이미지를 잔뜩 넣어 만들고, 확인하고, 고치는 사이클을 빠르게 반복했어요. 그렇게 깎아낸 로직이 지금 토스 쇼핑 상품 카드의 색상에 실제로 적용되고 있어요.

나를 복제해 협업 비용을 줄이다

나의 지식과 커뮤니케이션을 통째로 학습시킨 슬랙(메신저) 봇이에요. 디자인·요건 질문이 하루에도 수십 번 들어왔는데 답변하는 데 시간이 너무 많이 들었어요. 이 문제를 해결하려고 봇을 만들었죠. 이제 팀원이 질문을 던지면, 봇이 과거 논의 메시지와 정리해 둔 참고 자료를 근거로 답변 초안을 만들어줘요. 사람은 그 초안을 보고 바로 보낼지 수정할지 결정하면 돼요. 게다가 초안을 고쳐 보내면 봇이 그 수정 방향까지 학습해, 다음 비슷한 질문엔 더 정확하게 답해요. "내가 1.5명으로 늘어난 느낌"이라 했을 만큼 효과가 또렷했고, 토스의 다른 디자이너들도 각자 봇을 만들기 시작했어요.

말 대신 동작하는 걸로 설득하다

주식을 사고파는 증권 PC 화면을, 그림이 아니라 '진짜로 움직이는' 화면으로 만든 프로토타입이에요. 보통 디자이너는 멈춰 있는 시안을 그리고, 화면이 어떻게 움직이는지는 말이나 영상으로 설명해 넘기잖아요. 그러면 그 의도가 개발 단계에서 흐려지기도 하고요. 그래서 실제 제품 코드를 직접 만져서, 패널을 끌어다 자리를 바꾸거나 창 크기를 줄이면 화면이 알아서 반응하는 것까지 동작하게 만들었어요. 멈춘 시안이었다면 말로 설명했을 인터랙션을 직접 움직여 보여주며, 개발자와 눈높이를 맞추고 PO까지 설득했어요.

짧은 시간에 퀄리티를 끝까지 밀어붙이다

토스뱅크 공채 웹페이지의 키비주얼에 들어간, AI로 만든 직군별 모션그래픽이에요. 직군마다 모션을 다 만들어야 하는데 일정이 아주 촉박했어요. 모션의 뼈대 이미지는 직접 만들고, AI(kling)로는 원하는 결과가 나올 때까지 프롬프트를 집요하게 수정했죠. 시작과 끝 프레임은 사람 손을 거쳤지만, 직군별 모션을 단 하루 만에 완성했어요.

적용해 보기

디자이너들은 AI로 완전히 새로운 일을 하기보다, 이미 하고 있는 일을 더 빠르게, 더 설득력 있게, 더 높은 완성도로 만드는 데 AI를 활용하고 있었어요. AI를 써보고 싶은데 어디서 시작해야 할지 모르겠다면, 아래 네 가지 방향 중 하나를 생각해보세요.

Editor 유아란

Spark Connect on Kubernetes #1: 견고한 Spark Connect 만들기

2026-06-19T16:35:00+09:00

안녕하세요. 토스증권 Data Infra팀 박지원입니다.

토스증권은 분석가와 엔지니어가 복잡한 설정 없이 Spark를 쓸 수 있도록, Spark Connect를 Kubernetes에서 서비스로 운영하고 있습니다. 사내 여러 팀의 분석과 데이터 파이프라인이 이 위에서 돌아가는 만큼, 안정성을 확보하는 것을 가장 중요한 목표로 두고 있습니다.

이 시리즈에서는 Spark Connect를 Production 수준의 서비스로 만들어온 과정을 풀어보려고 합니다. 첫 주제는 견고한 Spark Connect 만들기 — 여러 사용자가 함께 써도 각자의 작업을 서로 지키며, 안정적으로 운영하는 방법입니다. Spark Connect가 처음인 분도 부담 없이 따라올 수 있게, 개념부터 차근차근 짚어 보겠습니다.

Spark는 원래 어떻게 동작하나요

Spark Connect가 무엇인지 이해하려면, 먼저 Spark가 원래 어떻게 동작하는지부터 봐야 합니다.

Spark에는 두 종류의 프로세스가 있습니다. 작업을 계획하고 지휘하는 Driver, 그리고 실제 연산을 나눠 수행하는 Executor입니다. Driver가 코드를 받아 실행 계획을 세우고, Executor들에게 Task를 나눠주고, 결과를 모읍니다.

Classic Spark에는 이 Driver를 어디서 실행하느냐에 따라 두 가지 배포 모드가 있습니다.

① Client mode는 Driver가 클라이언트 프로세스 안에 있습니다. 클라이언트가 곧 Driver죠. ② Cluster mode는 Driver가 클러스터 노드에서 실행돼, 작업을 제출할 때마다 떴다가 끝나면 사라집니다. 대신 클라이언트가 죽어도 앱은 계속 돌아가고요.

중요한 건 두 모드의 공통점입니다. 둘 다 App마다 Driver가 새로 뜨고, 그 Driver는 App의 수명과 함께 살고 죽습니다.

그리고 작업을 제출하려면 클라이언트 쪽에도 Spark 라이브러리와 설정이 갖춰져 있어야 하죠.

Spark Connect가 바로 이 지점을 개선했습니다. 2022년 SPIP로 출발해 Spark 3.4에 처음 들어왔어요. 초기에는 클라이언트에서 쓸 수 없는 API가 적지 않았지만 버전을 거듭하며 공백이 메워졌고, 4.0에서는 기존 Dataset/DataFrame API와 동등한 수준에 올라섰습니다. 4.1에서도 사용성과 성능 개선이 이어지고 있고요. 저희는 4.1 버전을 운영하고, 글의 코드·설정도 4.1 기준이에요.

Spark Connect는 무엇이 다른가요

Spark Connect는 Driver를 애플리케이션마다 뜨는 것에서, 미리 떠있는 서버로 만들었습니다.

클라이언트는 더 이상 Driver를 갖고 있지 않습니다. DataFrame이나 SQL 연산을 Unresolved Logical Plan으로 바꿔 Protocol Buffer로 인코딩하고, 이걸 gRPC로 서버에 보냅니다. 이미 떠 있는 서버가 분석·최적화·스케줄링·실행을 맡고, 결과는 Arrow로 다시 스트리밍됩니다. 마치 JDBC Client로 데이터베이스에 질의하는 모델과 유사합니다.

그래서 좋은 점

Driver를 서버로 분리해 미리 띄워두면, 이런 이점이 생깁니다.

가벼운 클라이언트 — 클라이언트는 gRPC로 명세만 주고받는 Thin Client입니다. 무거운 Spark 의존성과 JVM 없이도 접속할 수 있습니다.
언어·플랫폼 독립 — 서버가 연산을 맡으니 클라이언트 쪽은 어떤 언어든, 노트북이든 BI 도구든 SQL 클라이언트든 상관없습니다. 같은 서버에 여러 종류의 클라이언트가 붙습니다.
즉시 세션 생성 — 서버가 이미 떠 있는 상태로 대기하니, 접속하면 곧바로 세션이 열립니다. 매번 Driver를 띄우고 리소스를 협상하며 기다릴 필요가 없습니다.
클라이언트 장애에 강함 — 연산 주체가 서버라서, 클라이언트가 끊기거나 노트북을 닫아도 서버 쪽 작업은 보호됩니다. 세션만 정리하면 됩니다.

여기까지만 보면 이상적입니다. 그런데 미리 띄워둔 long-running 서버 하나에 여러 클라이언트가 붙는다는 모델은, 동시에 새로운 문제들을 만들었습니다.

Spark Connect 서버가 만드는 문제들

미리 말해두면, 이 문제들의 근본적인 원인은 하나입니다. Spark의 기본 설계 곳곳이 ‘앱 하나 = 워크로드 하나’를 전제하는데, 우리는 그 앱을 여러 사용자가 공유하는 long-running 서버로 쓰고 있다는 것. 아래 문제들은 전부 이 전제가 깨지는 지점에서 나옵니다.

문제 ①, Driver = 단일 장애점

Spark Connect 서버 하나에 여러 세션이 붙으면, 그 세션들은 하나의 SparkContext를 공유합니다. Driver JVM이 하나라는 뜻입니다.

세션이 아무리 늘어도 Driver는 하나입니다. 그래서 Driver 프로세스에 문제가 생겨 내려가는 순간, 영향은 한 세션에 그치지 않고 그 서버에 붙은 모든 세션으로 번집니다. 진행 중이던 job과 캐시도 함께 사라지죠.

실제로 한 사용자의 쿼리 하나가 서버 전체를 내릴 수 있습니다. Spark는 executor 실패가 임계값(spark.executor.maxNumFailures, 기본값 max(3, 2 × executor 수))을 넘으면 앱을 종료하는데, 이 로직이 바로 ‘앱 하나 = 워크로드 하나’ 전제로 설계돼 있거든요. Kubernetes 환경의 실제 코드를 보면:

stopApplication이 하는 일이 곧 sys.exit(11)입니다. gRPC 서버도, SparkContext도, 모든 세션도 이 한 줄에 함께 내려갑니다.

이 카운터의 두 가지 성질이 멀티세션 서버에서 위험을 키웁니다. 첫째, Executor 단위 글로벌 카운터라 개별 쿼리의 Task 수준 fault tolerance(spark.task.maxFailures)와 무관하게 쌓이고, 시간이 지나도 사라지지 않습니다.

둘째, 모든 세션의 실패를 합산합니다. 그래서 OOM을 일으키는 쿼리가 반복되거나 여러 사용자의 executor 실패가 누적되면, 그 합이 임계값을 넘는 순간 서버 전체가 종료되고 원인을 만든 세션과 함께 아무 잘못 없는 다른 세션까지 함께 사라집니다.

문제 ②, 리소스 경합과 Task Scheduling 한계

서버가 세션마다 newSession()을 만들긴 하지만, 이건 세션 로컬 상태(SQL 네임스페이스)만 격리할 뿐입니다. CPU·메모리·Executor 같은 실행 리소스는 모두가 나눠 씁니다. 그래서 한 사용자가 Job을 대량으로 제출하면 다른 사용자의 응답이 느려집니다.

이건 Driver의 Task Scheduling 구조 때문입니다. 한 Driver의 스케줄러는 모든 세션의 Task를 함께 놓고, Executor의 Task 슬롯이 빌 때마다 하나씩 나눠줍니다. 기본 정책이 FIFO라 경합이 생기면 먼저 제출된 작업이 우선이고, 선점(Preemption)이 없어서 이미 슬롯을 차지한 Task를 중단시키지도 못합니다. 무거운 작업이 슬롯을 전부 채우면 뒤에 온 가벼운 쿼리는 그 Task들이 끝나 슬롯이 반환되기만 기다려야 합니다.

Scheduler가 다루는 건 어디까지나 Task 슬롯의 순서뿐이라, 사용자별로 CPU·메모리를 보장하거나 우선순위를 세밀하게 나누는 데는 구조적 한계가 있습니다. Spark에는 작업을 풀(Pool)로 나눠 가중치를 주는 Fair Scheduler도 있지만, 이 역시 빈 슬롯을 누구에게 먼저 줄지 순서를 바꿀 뿐 CPU·메모리를 격리해주지는 못합니다.

사실 Spark Connect에서는 이 Fair Scheduler의 Pool 분리조차 동작하지 않습니다. spark.scheduler.pool은 Job을 제출하는 실행 스레드에 thread-local로 얹혀 있어야 스케줄러가 인식하는데요. Classic Spark에서는 클라이언트가 곧 Driver라 setLocalProperty() 한 줄이면 그 스레드에 바로 적용되었지만, Spark Connect는 클라이언트와 Driver가 떨어져 있어 서버가 요청을 실행하는 스레드에 이 값을 대신 넣어줘야 합니다. 그런데 서버는 다른 값은 전파하면서 정작 Scheduler Pool만 빠뜨려요. 그래서 모든 쿼리가 Default Pool 하나에 들어갑니다. 커뮤니티에도 알려진 공백인데, 저희는 요청을 실행하는 서버 스레드에 사용자별 Pool을 직접 넣어주는 방식으로 메웠어요. 다만 Pool을 '사용자별'로 가르려면 먼저 그 요청이 누구 것인지 알아야 하죠. 이 사용자 식별이 인증·인가의 몫이라 자세한 건 3편에서 다룰게요.

어쨌거나 Pool이 다루는 건 어디까지나 Task 슬롯의 순서입니다. CPU·메모리 격리는 스케줄러로는 불가능하고, 결국 Spark 바깥에서 풀어야 했습니다.

문제 ③, 고정된 스케일

마지막은 이번 편에서는 다루지 않는 문제입니다. 서버는 미리 정해진 스펙(이미지, Driver·Executor 리소스, Spark 설정)으로 뜹니다. Dynamic Resource Allocation으로 Executor 수는 부하에 따라 늘었다 줄었다 할 수 있지만, 서버 자체의 스펙은 실행 시점에 고정됩니다. 서버를 그때그때 만들고 교체할 수 있어야 풀리니, 이건 다음 편 몫이에요.

그래서, 어떻게 풀었나

이 문제들을 한 번에 없애는 단일 해법은 없었습니다. 단일 장애점(①)과 리소스 경합(②)은 이번 편에서, 고정된 스케일(③)과 팀 단위 격리는 다음 편에서 다룰게요. 단일 장애점부터 보겠습니다.

공유 Driver의 SPOF를 어떻게 극복했나

단일 장애점은 두 단계로 풀었습니다. 먼저 서버가 죽는 일 자체를 줄이고, 그걸로도 못 막는 장애는 여러 Replica로 다중화해 받아냈어요.

먼저, 죽는 일 자체부터 줄이기

Replica를 늘리기 전에, 앞에서 본 ‘실패가 누적돼 서버를 죽이는’ 경로부터 끊었습니다. 글로벌 Executor 실패 카운터를 사실상 비활성화하고, 문제 쿼리의 정리는 Task·Stage·Job 단위의 Fault Tolerance에 맡긴 거예요.

핵심은 첫 줄, 글로벌 카운터를 끄는 것입니다. failuresValidityInterval은 흔히 오래된 실패를 잊는 설정으로 소개되지만 카운터를 꺼둔 저희에게는 long-running 서버에 실패 기록이 끝없이 쌓이지 않게 주기적으로 비워주는 쪽에 가깝습니다. 나머지 두 값은 Bad query가 Executor를 붙잡는 시간을 줄이기 위한 저희 환경의 선택이라, 워크로드에 따라 달라질 수 있어요. 다만 task.maxFailures를 기본값보다 공격적으로 낮추면, 문제 쿼리를 빨리 끊는 대신 일시적인 장애에도 멀쩡한 쿼리까지 실패할 수 있어서 조금 여유를 두는 편이 안전해요.

task.maxFailures와 stage.maxConsecutiveAttempts는 같은 일을 단계만 달리해 막는 게 아니라, 서로 다른 실패를 맡습니다. 앞은 같은 Task가 거듭 실패하는 경우(OOM·예외)를, 뒤는 Shuffle Fetch 실패로 Stage가 통째로 다시 도는 경우를 끊어요.

이제 Executor가 반복해서 죽어도 서버는 살아남고, 문제를 일으킨 쿼리만 실패합니다. 에러도 달라졌어요. 전에는 서버가 죽어 모두가 ‘SparkContext에 접근할 수 없음’을 받았다면, 지금은 해당 쿼리를 보낸 사용자만 어떤 Executor가 어떤 Exit code로 죽었는지 담긴 Stage failure 에러를 받습니다. 원인 추적이 가능한 실패가 된 거죠.

Executor 실패만이 아니라, 쿼리 결과 그 자체도 서버를 위협합니다. Spark Connect에서는 모든 세션의 쿼리 결과가 Driver를 거쳐 클라이언트로 스트리밍되니까, 누군가 거대한 테이블을 Collect하면 그 데이터가 전부 Driver 메모리로 향하거든요. 여기는 spark.driver.maxResultSize가 막아줍니다. 한 액션의 Task 결과 누적 크기가 한도를 넘으면 job을 abort하는데, 눈여겨볼 건 차단 시점이에요. executor에 쌓인 큰 결과는 Driver가 가져오기 전에 크기부터 검사하고, 한도를 넘으면 Fetch 자체를 포기합니다. 위험한 데이터가 Driver 메모리에 발을 들이기 전에 끊는 거죠.

다만 기본값 1g은 이것도 ‘앱 하나 = 워크로드 하나’ 시절의 숫자입니다. 한도가 쿼리 단위라서, 여러 세션이 동시에 큰 결과를 받아 가면 각자 한도까지 통과합니다. 멀티세션 서버에서는 동시 쿼리 수를 감안해 이 값을 보수적으로 잡아야 합니다.

그래도 서버는 죽을 수 있습니다. Driver 자체가 OOM으로 내려가거나 노드가 통째로 사라지는 것까지 설정으로 막을 수는 없으니까요. 그래서 다음 단계가 필요했습니다.

하나의 Spark Connect 서버를 여러 replica로

가장 확실한 격리는 SparkContext 자체를 나누는 것입니다. 그래서 Spark Connect를 서버 한 대가 아니라, 같은 스펙의 서버 여러 대(Replica)로 구성할 수 있게 했어요. 각 Replica는 자기만의 SparkContext·Driver·Executor를 가지므로, 한 대가 장애로 내려가도 같은 Spark Connect의 다른 replica가 세션을 받습니다. 단일 장애점의 영향 범위가 Spark Connect 전체에서 replica 한 대로 줄어든 거죠.

Replica 수와 Executor 정책은 워크로드에 따라 조합합니다. 부하 변동이 크고 가용성이 중요한 워크로드라면 여러 replica(HA)에 Dynamic Resource Allocation을 얹어 한가한 replica는 Driver만 두고 Task가 쌓일 때만 Executor를 띄워요. 반대로 부하가 일정하거나 한 대로 충분하면 단일 replica에 Executor를 고정해 둡니다. DRA를 쓰는 쪽에선 부하가 replica들로 나뉘니, Executor 총량은 replica 수가 아니라 실제 작업량에 비례하고요.

요청을 어느 서버로 보낼까

하나의 Spark Connect가 여러 replica로 늘었으니, 이제 들어온 요청을 그중 어느 서버로 보낼지 정해야 합니다. 여기가 까다로웠어요. 새 세션은 한가한 서버에 놓여야 하고, 기존 세션은 늘 같은 서버로 가야 하거든요.

처음엔 Istio로 풀어봤어요. Spark Connect의 replica들을 하나의 Aggregate Service로 묶고, consistent hash로 세션을 고정했습니다.

session affinity — Spark Connect 세션은 특정 Driver의 JVM 메모리에만 존재하니, 같은 세션의 요청은 늘 같은 replica로 가야 합니다.
consistent hash — DestinationRule이 Client에서 따로 주입해준 x-spark-session-id 헤더를 해시해서 같은 세션을 같은 pod에 고정합니다.

session affinity는 이걸로 잡혔습니다. 여기에도 명확한 한계가 있어요.

Istio는 Spark를 모른다

consistent hash는 우리가 원한 session affinity를 정확히 만들어줬습니다. 같은 x-spark-session-id는 늘 같은 pod로 갔으니까요. 문제는 affinity가 아니라 새 세션을 어디에 둘지였습니다.

consistent hash는 오직 해시값으로만 pod를 정합니다. 그 서버가 지금 메모리를 얼마나 쓰는지, 무거운 쿼리가 몇 개 돌고 있는지는 전혀 보지 않습니다. 그래서 이미 바쁜 Spark Connect 서버에도 해시가 그쪽을 가리키면 새 세션을 계속 얹습니다. 한 서버는 터질 듯한데 옆 서버는 놀고 있어도, Istio 입장에선 그냥 균일한 백엔드 주소일 뿐 이 Spark 서버가 얼마나 바쁜지 알 수 없습니다.

우리가 원한 건 두 가지였어요. 기존 세션은 원래 서버에 묶어두는 것, 새 세션은 서버 부하를 보고 할당하는 것. 범용 프록시의 로드밸런싱 정책은 이 둘을 동시에 만족하지 못합니다. consistent hash는 앞의 것만, Least request 같은 부하 기반 정책은 뒤의 것만 해주거든요.

부하를 분산하려면, 단순한 주소가 아니라 Spark 서버의 상태를 아는 router가 필요했습니다.

그래서 Gateway를 개발했어요

만들기 전에 기존 프로젝트부터 살펴봤어요. Kyuubi는 멀티테넌트 게이트웨이라는 방향이 같고 성숙한 프로젝트지만, 제공하는 인터페이스가 Thrift/JDBC(HiveServer2 프로토콜) — SQL Only입니다. 우리는 분석가와 파이프라인이 쓰는 DataFrame API를 그대로 서비스해야 한다는 요구사항이 확실했고, 그걸 표준 프로토콜로 제공하는 건 Spark Connect뿐이었어요. Kyuubi의 Spark Connect 프로토콜 지원은 아직 커뮤니티에서 논의가 진행 중이고요. 그래서 우리 요구에 맞는 대안이 없었습니다.

결국 Spark Connect 서버의 부하를 이해하는 Gateway를 직접 만들었습니다. 이 Gateway, 그리고 다음 편에서 다룰 테넌트의 생성·교체·삭제를 맡는 Controller — 이 둘을 묶어 우리는 Spark Connect Hub라고 부릅니다. 이번 편은 그중 트래픽을 받아 나누는 Data Plane, 즉 Gateway 이야기예요. 핵심은 새 세션을 가장 한가한 서버에 배치하는 것입니다. 그러려면 먼저 이 서버가 지금 얼마나 바쁜지 관측할 수 있어야 합니다.

서버 부하를 어떻게 점수로 만드나

Spark는 Driver마다 모니터링용 REST API를 열어둡니다. Gateway는 이걸 폴링해 세 가지 숫자를 읽어요. 지금 executor에서 돌고 있는 Task 수(active), 슬롯을 못 잡고 줄 서 있는 Task 수(pending), 그리고 이 서버가 동시에 굴릴 수 있는 Task 슬롯의 총량(maxTasks)입니다. maxTasks는 executor마다의 슬롯(≈ 코어 수)을 전부 더한 값, 곧 그 서버의 동시 처리 용량이에요.

보는 건 메모리 사용량이 아니라 이 슬롯이 얼마나 꽉 찼고 얼마나 밀려 있나입니다. 그래서 부하를 (active + pending) / maxTasks로 잡아요 — 처리 중이거나 대기 중인 Task를 전체 슬롯으로 나눈 거죠. 슬롯이 다 차고 대기까지 쌓인 서버는 1을 넘고, 노는 서버는 0에 가까우니, 무거운 쿼리가 도는 서버를 집어내는 신호가 됩니다. 다만 폴링 스냅샷이라 측정할 때마다 출렁여서, 지수가중이동평균(EWMA)으로 다듬어 순간 스파이크가 아니라 그 서버의 평소 바쁨이 점수에 남게 했습니다.

여기에 보조 신호로 활성 세션 수를 더합니다. REST 폴링은 갱신에 지연이 있어, 짧은 시간에 새 세션이 몰리면 측정값이 갱신되기 전까지 전부 같은 한가한 서버로 쏠리거든요. 세션 수는 저장소에서 즉시 읽히니 배치하는 순간 바로 반영돼, 그 폴링 공백을 메워 줍니다.

utilization을 지배적으로(0.9) 두고 세션 수는 보조로(0.1) 얹습니다. 점수가 같은 서버가 여럿이면 한쪽으로 쏠리지 않게 무작위로 고르고요.

세션은 한 번 정한 서버를 끝까지

새 세션은 위 점수로 배치하지만, 이미 자리를 잡은 세션은 부하와 무관하게 원래 서버로 보냅니다. 세션 상태가 그 Driver의 메모리에만 있으니 다른 데로 보내면 안 되거든요.

요청이 올 때마다 idle 타이머를 리셋하는 방식이라, 활발히 쓰는 세션은 계속 유지되고 한참 안 쓴 세션만 만료됩니다. 부하 인지 배치(새 세션)와 고정 affinity(기존 세션), 이 두 규칙으로 consistent hash가 못 하던 문제를 풀면서도 세션은 안전하게 지킵니다. 하나였던 Driver를 여러 대로 나눠 세션들이 한 SparkContext를 공유하지 않게 되었고, 새 세션은 그중 가장 한가한 서버로 갑니다. 이렇게 리소스 경합을 풀었어요.

라우팅 상태는 어디에 있을까 — ServerPool·SessionStore

새 세션은 한가한 서버로, 기존 세션은 원래 서버로 — 이런 결정을 내리려면 Gateway는 두 가지 상태를 들고 있어야 합니다. 어떤 서버가 있나(ServerPool), 이 세션은 어디 붙었나(SessionStore). 둘 다 ‘풀’이지만, 누가 Redis에 쓰고, Gateway가 그걸 어떻게 들고 있는지가 서로 다릅니다.

ServerPool — 어떤 서버가 살아있나. 서버 목록을 healthy/draining/generation과 함께 들고, 앞서 본 부하 인지 라우팅이 여기에서 일어납니다. 후보는 healthy하고 draining이 아닌 서버, 그중 가장 최신 세대로 좁힙니다. (세대로 좁히는 게 무중단 교체의 핵심인데, 다음 편에서 다뤄요.) 다만 이 풀의 원본을 Gateway가 직접 만드는 게 아닙니다. Controller가 Redis에 올려둔 서버 상태를 각 Gateway가 폴링해 자기 메모리에 캐싱해 둔 거예요.
SessionStore — 이 세션은 어느 서버에 붙었나. 새 세션을 배치하는 순간 매핑을 기록하고, 이후 같은 세션은 이 기록을 따라 같은 서버로 갑니다. 이건 Gateway가 Redis에 직접 씁니다. Gateway도 여러 대라, 앞단 로드밸런서가 요청을 아무 replica로 보내도 모두 같은 Redis를 보고 같은 서버로 보내야 하거든요.

정리하면, 세션 매핑은 Gateway가 Redis에 직접 써서 모든 Gateway가 공유하고, 서버 목록은 Controller가 Redis로 흘려준 걸 각 Gateway가 메모리에 캐싱해 들고 있습니다. 그런데 ServerPool은 채우는 주체가 Gateway가 아니라고 했죠. 그 이야기를 할 차례입니다.

Gateway는 Kubernetes를 몰라도 돼요

살아있는 서버 목록(ServerPool)을 채우려면, 보통은 각 Gateway가 Kubernetes API를 직접 watch하게 만듭니다. 하지만 그러면 Gateway를 늘릴 때마다 watch가 replica 수만큼 API 서버에 붙고, Data Plane인 Gateway가 K8S 접근 권한과 informer까지 떠안아야 합니다. 무엇보다 트래픽을 받는 Data Plane이 Control Plane에 묶이는 게 안정성 면에서 좋지 않습니다 — Controller나 K8S API가 흔들리면 라우팅까지 같이 흔들리니까요.

그래서 K8S를 보는 일은 Controller 하나에 몰아줬습니다. Controller는 Kubernetes Operator로 구현했어요. 단일 Spark Connect 서버의 라이프사이클은 이미 Spark Operator가 다루는 영역이라, 우리는 그 위에 한 계층을 더 올렸습니다. Controller는 서버를 직접 만들지 않고, 이 operator들이 관리하는 서버 리소스를 여러 대 묶음으로 선언·조율하죠 — 즉 우리가 푼 문제는 ‘서버 한 대를 어떻게 띄우나’가 아니라 ‘여러 대를 한 묶음으로, 무중단으로 어떻게 굴리나’입니다. 복제본 수 유지, 스펙 변경 시 Blue-Green 교체, 스케일 인/아웃 시 drain이 여기 들어갑니다(Controller의 자세한 동작은 다음 편에서 다룹니다). 이렇게 Controller가 파악한 서버 상태를 Redis instance store에 Publish하면, Gateway는 K8S API를 전혀 보지 않고 이 Redis만 짧은 주기로 폴링해 ServerPool을 맞춥니다.

폴링할 때마다 Instance store와 ServerPool을 비교해, 새 서버는 더하고 사라진 서버는 빼면서 그 서버에 묶인 세션 매핑까지 정리합니다. 살아있는 서버는 Controller가 주기적으로 갱신하고, 사라진 서버는 TTL이 지나 저절로 빠집니다. 그래서 서버가 생기든 없어지든 Gateway는 다음 폴링이면 따라잡습니다.

덕분에 Gateway를 아무리 늘려도 K8S API 부하는 그대로고, Controller가 잠시 죽어도 Gateway는 마지막 ServerPool로 계속 라우팅합니다. Data Plane은 Redis만 보면 되니 책임이 깔끔하게 나뉩니다.

마치며

정리하면, Spark Connect는 Driver를 미리 띄운 서버로 옮겨 가벼운 클라이언트와 즉시 세션을 얻는 대신, 서버 하나에 세션이 몰려 단일 장애점(①)과 리소스 경합(②)을 안게 됩니다.

먼저 서버가 죽는 일을 줄이려고, 멀티세션에서 깨지는 Spark 기본값을 다시 잡았습니다. 앞에서 짚은 값들에, Driver heap을 함께 나눠 쓰며 위험을 키우는 몇 가지를 더해 아래에 모았어요. 기존 Spark 운영에선 건드릴 일 없던 값들이라, Spark Connect를 운영한다면 여기부터 점검해 보면 좋습니다.

설정

기본값

가이드

spark.driver.maxResultSize

1g

쿼리 단위로 한도가 적용되므로, 동시 쿼리 수를 감안해 보수적으로 설정

spark.driver.memory

1g

모든 세션이 하나의 Driver heap을 공유하므로, 동시 세션 수를 고려해 여유 있게 설정

spark.driver.memoryOverhead

max(384m, 0.1×driver)

off-heap·네이티브 메모리가 한도를 넘으면 driver pod가 OOMKill되므로, heap과 함께 여유 있게 설정

spark.executor.failuresValidityInterval

(none)

장기 실행 서버에 실패 기록이 끝없이 쌓이지 않도록 주기적으로 비움

spark.executor.maxNumFailures

max(3, 2×executor)

executor 실패가 전 세션에 걸쳐 합산돼 서버를 종료시키므로, 사실상 무한대로 두어 비활성화

spark.sql.autoBroadcastJoinThreshold

10m

broadcast 해시 테이블이 공유 Driver heap에 빌드되고 동시 broadcast가 합산되므로, 키울 때는 압축 해제 후 실제 크기와 동시 쿼리 수를 함께 고려

spark.stage.maxConsecutiveAttempts

4

shuffle fetch 실패로 stage가 통째로 재시도되는 것을 끊는 한도라, task.maxFailures와 짝으로 워크로드에 맞춰 조정

spark.task.maxFailures

4

문제 쿼리가 executor를 오래 붙잡지 않도록 워크로드에 맞춰 조정

spark.ui.store.path

(none)

Job·Stage·Task·SQL 실행 UI 상태가 모두 Driver heap의 in-memory store에 쌓이므로, 디스크(RocksDB)로 분리

그래도 막지 못하는 장애는 여러 Replica로 받고, 그 앞에 Spark Connect Hub의 Gateway를 둔 뒤 새 세션은 한가한 서버로·기존 세션은 원래 서버로 보냈습니다. 덕분에 장애 범위는 replica 한 대로 줄고(①), 경합도 풀었죠(②).

다음 편에서는 고정된 스케일(③)과 테넌트 격리를 맡는 Control Plane·무중단 Blue-Green 교체를, 3편에서는 인증·인가로 사용자를 식별해 각자 허용된 범위 안에서만 데이터에 접근하도록 만드는 이야기를 다룹니다.

2. 전문성 밖으로 나아가기

2026-06-19T11:01:00+09:00

TW가 제품 오너로 일한다는 것

앞서 토스의 Technical Writer(이하 TW)가 하는 일을 네 가지로 나눠 소개했어요. 그중 첫 번째가 '제품을 만든다'였죠. TW가 제품을 만든다는 게 어떤 의미인지, 제 이야기부터 풀어볼게요.

저는 지금 Knowledge System Team이라는 제품 팀의 리더로 일하고 있어요. 개발자·디자이너·TW와 함께 제품의 방향을 잡고, 로드맵과 우선순위를 정합니다. 사용자를 직접 인터뷰해 인사이트를 팀에 가져오고, 기능을 기획하고, AI 도구로 직접 만들기도 하고요. 단순히 문서와 관련된 요구사항을 전달하는 사람이 아니라, 제품에 대한 판단을 내리고 실제로 만드는 메이커로 일하고 있는 거죠.

TW가 왜 제품을 만들고 있을까요? 이 제품의 핵심이 문서와 지식을 다룬다는 점 때문인데요. TW들은 왜 어떤 문서는 읽기가 어려운지, 무엇이 좋은 문서인지, 어떤 구조여야 AI가 잘 활용할 수 있는지 같은 질문들을 가장 오랫동안 고민하며 기준을 세워왔어요. 그래서 이를 녹인 제품을 만드는데 가장 중요한 인사이트를 제공할 수 있습니다.

저희가 만들고 싶은 끝그림은 TW의 전문성이 하나의 제품으로 확장되어 문서와 실제 업무 워크플로우가 연결되고, 일만 하면 지식이 자동으로 쌓이고, 누구나 쉽게 그 지식에 접근하고 활용하는 모습이에요. 그 목표를 위해 만들고 있는 제품을 소개드릴게요.

TW의 고민이 담긴 제품, ‘토독(todoc)’

문서화 도구가 오랫동안 지속적으로 작동하고, 다른 조직으로도 스케일업을 하려면 어떻게 해야 할까요? 오랜 고민 끝에 작년 10월, 사내 문서 플랫폼 토독(todoc)을 런칭했어요.

작년 10월 베타 오픈 공지를 올리자마자 "지금 바로 써보고 싶어요", "드디어 원하던 문서 플랫폼이 나왔어요" 같은 긍정적인 반응이 많아 놀랐는데요. 이미 문서화를 하고 있는 조직에서도, 아직 문서가 잘 정리되지 않은 조직에서도 AI로 쉽게 연결할 수 있고, 팀의 지식을 쉽게 쌓을 수 있는 플랫폼이 절실했던 것으로 이해했어요.

반년이 지난 지금 토독에는 약 500개 이상의 문서, 40,000개 이상의 유효한 페이지가 쌓였고, 매달 1000명 이상이 사용하고 있습니다.

GitHub이나 문서 툴을 사용하면 되는데 왜 새로운 제품을 만들었을까요? 기존의 내부 문서들은 몇 가지 문제가 있었어요.

먼저 기존에 정적 사이트 생성기(SSG, Static Site Generator)로 만들어져 있는 문서는 비개발자가 사용하기는 어려웠어요. 문서 하나를 고치려면 저장소를 클론해, 마크다운을 작성한 뒤, PR을 올려 리뷰를 받는 등의 과정이 필요한데요. 개발자에게는 익숙해도, 디자이너나 PM에게는 문서를 쓰기도 전에 포기하게 만드는 허들이었습니다.

그리고 기존 문서 툴에는 너무 많은 메모와 '쓰레기 지식'들이 누적되어 있었어요. 누가 언제 왜 썼는지 알 수 없는 내용들, 이미 바뀐 정책을 가리키는 낡은 문서들, 쓰다 만 메모들 등등… 다들 경험해 보신 적 있을 거예요. 이런 상태에서는 기존 문서 툴 자체가 문서 부채라서 양질의 지식을 판별하고 관리하는 것이 거의 불가능해요.

마지막으로 이렇게 지식들이 각자 혹은 팀별로 선택한 도구에 파편화되어 있었어요. SSG로 만든 문서에, 각종 문서 툴에, 코드에, 협업 메신저 속 논의에, 누군가의 머릿속에 흩어져 있었죠. 이렇게 흩어진 소스를 한곳에 모으지 않으면 조직의 지식이 잘 쌓일 수도, 활용할 수도 없을 거라고 판단했습니다.

그래서 토독은 네 가지를 핵심 가치로 잡았어요.

1. 누구나 문서를 쉽게 쓸 수 있어요.

문서화의 모든 장벽을 없앴어요. 토독에서 누구나 곧바로 문서를 만들고 고칠 수 있고, GitHub, 문서 툴, 사내 메신저 등 어떤 소스로 시작하든 토독으로 연결할 수 있어요.

2. 토독에 있는 지식은 AI로 쉽게 활용할 수 있어요.

잘 모으고 관리한 지식은 결국 AI가 쓰기 위한 것이기도 해요. 토독에 문서를 쓰면 AI 활용이 무척 쉬워요. 팀 별로 사용하는 봇과 연결해서 쓸 수 있고, API/CLI/MCP 모두 자유롭게 사용할 수 있죠. 그래서 각 팀에서 요청 봇이나 제품 스펙을 정리하기 위한 용도 등으로 다양하게 활용하고 있어요.

3. 모든 사내 지식을 한 곳에 모아 단일 진실 공급원(SSoT, Single Source of Truth) 역할을 해요.

토독은 흩어진 소스들을 한곳으로 연결해서 완결된 문서를 만들고, "이건 어디서 찾지?"를 고민할 필요가 없게 만들어요. 무엇이 지금도 유효한 최신 지식인지 한곳에서 판별할 수 있으니, 토독이 조직의 단일 진실 공급원 역할을 하는 거죠.

4. 확장 가능한 구조가 된다

어떤 조직이 문서화를 하고 싶을 때 툴을 선택하거나 새로 구축하는 게 아니라, 이미 돌아가는 토독 위에서 시작하면 돼요. 하나의 플랫폼 위에서 각자의 문서 공간을 가질 수 있죠. 지금까지는 문서를 쓰려면 팀마다, 챕터마다 따로 도구를 정해야 하고 인프라를 세팅하거나 관리해야 하는 공수가 들었어요. 토독이 생겼기 때문에 이제 팀원들은 문서를 쓰는데만 집중하면 돼요. 이런 구조를 이제 계열사로도 확장하고 있어요.

남은 과제들

문서의 진입 장벽을 낮추면 많은 사람들이 문서를 쉽게 쓸 수 있지만 동시에 문서의 질은 유지하기가 힘들다는 문제도 생깁니다. 그래서 "어떻게 문서의 질까지 유지할까"도 TW들이 자주 하는 고민인데요. 이전에는 이 고민을 TW가 직접 문서를 리뷰하고, 낡은 문서가 없는지 확인하면서 해결했습니다. 토독에서는 이런 TW의 일을 TW가 판단해온 "좋은 문서의 기준"을 바탕으로 자동화해서 AI 교정 기능이나 문서 봇을 통한 초안 자동화를 제공하기도 했습니다.

그치만 이런 기능들은 여전히 사람들이 직접 문서를 쓴다는 것을 전제로 합니다. 그리고 사용자들을 봤을 때 저는 이것으로는 충분하지 않다고 느꼈어요.

'문서를 쓰겠다'고 따로 마음먹고 완성하기까지는 많은 노력과 시간이 들어요. 그래서 일을 하다 보면 자연스럽게 문서가 생기게끔 하고 있어요. 토독은 사내 메신저에서 오가는 의사결정, 코드, 논의를 자동으로 문서로 만들어줘요. 코드 변경, 의사결정 이후 논의 모니터링을 통해 누군가의 의지에 기대지 않아도 문서가 갱신되는 구조도 만들고 있고요.

단순한 정보 수집과 문서 생성을 넘어, 무엇이 지금도 유효한 지식인지를 가려내는 것이 문서의 핵심이라고 생각해요. 정책과 실제 반영된 코드가 어긋나지 않는지, 이 지식이 실제로 쓰이고 있는지, 얼마나 최신인지 까지 토독 시스템 위에서 풀어 나가고 있어요.

전문성의 확장과 이동

예전에 TW에게 중요한 역량이 좋은 문서를 직접 잘 쓰는 능력에 가까웠다면, 이제는 좋은 문서가 반복해서 나오도록 시스템을 설계하는 능력을 중심으로 일해야 한다고 생각해요. TW가 쌓아온 전문성은 사라지지 않고 다음과 같이 시스템 속에 녹아있습니다.

"왜 문서가 안 읽히는가"를 고민하던 경험은 → 누구나 쉽게 쓰고, AI가 잘 읽는 문서의 기준이 됐어요.
"좋은 문서란 무엇인가"에 대한 판단은 → AI 교정과 자동 리뷰의 기준으로 옮겨갔고요.
문서가 낡았는지 확인하고, 유효한 지식을 판단하는 역량은 → 무엇이 지금도 유효한 지식인지 판별하는 시스템이 됐습니다.

이 변화 속에서 저희가 하는 일은 명확해요.

흩어진 지식이 모일 곳을 만든다.
좋은 문서의 기준을 정의한다.
그 기준을 사람의 판단이 아니라 시스템으로 옮긴다.
일하는 과정 속에서 문서가 자연스럽게 만들어진다.
그 위에서 지식이 스스로 갱신되게 한다.

토독이 모든 과제를 마친 뒤, 제품 팀 리더이자 TW로써 저의 하루는 이런 모습입니다.

1달 넘은 문서 확인해 달라는 공지를 할 필요가 없어졌다. 토독이 낡은 문서를 감지해서 담당자에게 직접 알림을 보내고 개선점을 제안하고 있었다. 누가 챙기지 않아도 문서는 신뢰할 수 있는 상태였다. 더 이상 프로젝트 관리 도구를 직접 업데이트하지 않았다. 팀이 일하면서 남긴 흔적들이 이미 정리되어 있었다. 주연님은 다음 방향을 고민하는 데만 시간을 썼다. 릴리즈마다 썼던 공지, 문의마다 반복했던 설명들이 남아있어서 새로 온 팀원도, 처음 연동하는 팀원도 같은 질문을 다시 하지 않았다. 이렇게 한 번 일하면 흔적이 남아 모두의 업무 실행 시간이 줄었다. 어느 날 주연님은 노트북을 열었다가 조용히 닫았다. 할 일이 없었다. 토독이 너무 잘 돌아가고 있었다.

이렇게 토스의 Technical Writing Chapter는 TW의 전문성, 기준 자체가 시스템화 되는 것에 집중하고, 나아가 지식 관리 거버넌스를 만들어서 조직마다 문서화를 잘 할 수 있게 만들어 두고 다음 일을 하러 갈 예정입니다.

1. 세상에 없던 직무를 만들어가기

2026-06-19T11:00:00+09:00

안녕하세요, 토스 Technical Writing Chapter Lead 한주연입니다. 이번 시리즈에서는 토스의 Technical Writer(이하 TW)들이 어떻게 '문서를 쓰는 사람'에서 '조직의 지식 시스템을 설계하는 사람'으로 일을 넓혀왔는지 이야기해보려고 해요.

"이거 왜 이렇게 되어 있나요?" 회사에서 일하다 보면 하루에도 몇 번씩 듣고, 또 묻는 질문이에요. 코드를 짠 사람의 기억을 함께 더듬거나, 1년 전 업무 메신저 스레드까지 뒤져가며 맥락을 찾으신 적 많으실 거예요. 심지어 이미 사람이 자리를 비우거나 회사를 떠나서 답을 얻을 수 없는 경우도 있죠.

특히 요즘은 AI에게 일을 맡기다 보면 이 문제를 더 자주 느끼실 거예요. AI는 일반적인 지식은 잘 알고 있지만, 우리 조직만의 맥락과 히스토리는 모르기 때문에 매번 맥락과 정보를 넣어줘야 해요. 흔히 코드가 SSoT(Single Source of Truth)라고들 해요. 그런데 코드에는 '결과'만 남아요. 무엇을 하는지는 적혀 있어도, 왜 이렇게 짰는지, 어떤 결정을 거쳐 여기까지 왔는지는 빠져 있죠. 주석 하나 없는 코드 앞에서 한참 헤매본 경험, 다들 있으실 거예요.

저는 그래서 문서화가 여전히 중요하다고 생각해요. 진짜 SSoT는 코드와, 그 코드를 둘러싼 맥락이 함께 있어야 비로소 완성됩니다. 코드가 왜 그런지는 결국 우리가 알려줘야 하죠. AI에게 일을 시키려면, 우리가 아는 걸 먼저 어딘가에 남겨야 합니다. 그래서 Technical Writing Chapter는 이 부분을 채우기 위한 일을 하고 있습니다.

그런데 단순히 이 맥락을 채우기 위한 문서를 쓰는 것이 저희의 일은 아닙니다. 제가 처음 토스 커뮤니티에 합류했던 5년 전과 지금을 비교해 보면, TW가 하는 일은 많이 달라졌습니다.

또, 일의 목표도 달라졌습니다. 올해 목표는 사람이 문서를 직접 쓰지 않아도 지식이 쌓이게 만드는 것입니다. 그리고, Technical Writing Chapter의 궁극적인 목표는 사라지는 것입니다.

TW를 떠올렸을 때 어떤 일을 할 거라고 생각하셨나요? 사실 저는 TW가 AI에게 가장 먼저 대체될 거라고 생각했었는데요. 제 예상과는 반대로 할 일이 더 넓어지고 많아진다고 느낍니다. 기술 문서를 쓰는 역할을 하던 TW가 어떻게 위와 같은 일을 하고, 이런 목표를 가지게 됐을까요?

문서를 쓰는 일에서, 직접 찾아가는 방향으로

제가 사내 문서화를 처음 시작했을 때 가장 먼저 했던 일은 프론트엔드 챕터의 온보딩 문서 만들기였어요. 그런데 내부 문서를 만들면서 계속 마음에 걸리는 게 있었어요. 저는 Technical Writing의 목표가 글을 잘 쓰는 게 아니라 독자가 문제를 해결하고 목표를 이루도록 돕는 것이라고 생각하거든요. 그런데 문서가 아무리 좋아도, 사람들은 필요한 것만 찾지 처음부터 끝까지 읽진 않습니다. 사실 저조차도 그렇고요. 그래서 문서를 쓴 뒤 링크를 던지는 것 말고, 어떻게 하면 사람들이 이 내용을 실제로 활용하게 할지를 고민하게 됐어요.

고민하다 만든 게 ‘박씨’라는 챗봇이었어요. (*참고: TMC25 - 100번 실패하고 살려 낸 문서 시스템) 사람들이 매일 쓰는 메신저와 IDE 안에서, 대화하듯 물어보면 기존 문서를 근거로 출처까지 달아 답해주는 챗봇이에요. 지금은 많은 곳에서 익숙해진 것처럼 문서를 찾아오게 하는 대신, 문서가 사람들이 일하는 자리로 찾아가게 만든 거죠.

흥미로운 건 그다음이었어요. 문서를 쓰는 것도 읽는 것도 관심이 없었던 팀원들이 찾아오기 시작했어요. "우리 챕터도, 우리 조직도 이런 걸 만들고 싶다"고 하면서요. 조직의 크기가 커지면서 다들 반복되는 질문에 답하는 데 지쳤고, 암묵지를 사람이 아니라 시스템에서 얻고 싶어 했어요. 마침 AI가 빠르게 발전하면서 "AI에게 일을 시키려면 문서가 필요하다"는 흐름까지 더해졌죠.

오랫동안 귀찮은 일 취급받던 문서가 갑자기 모두가 원하는 것이 된 게 신기하기도 했습니다. 이런 흐름 속에서 저는 팀원 모두가 쓸 수 있는 지식 시스템 제품을 만들기 시작했습니다. 이 제품은 다음 글에서 자세히 소개할게요.

문서에서 지식 시스템으로

그때부터 TW들은 직무에 갇히지 않고 일을 넓혔어요. TW는 이제 문서를 쓰는 사람이 아니라, 위와 같이 각 조직에 맞는 지식 시스템을 설계하는 사람이 되어야 한다고 판단했어요. AI가 점점 더 많은 일을 하는 지금, 조직에 흩어진 지식과 암묵지가 문서화되는 게 정말 중요하다는 생각도 들었습니다.

잘 만든 지식 시스템은 두 가지 가치를 가집니다. 위로는 조직 전체의 생산성을 끌어올리고, 아래로는 모든 팀원이 쉽고 빠르게 적응할 수 있도록 하방을 막아줍니다. 조직이 커질수록 질문이 늘고 커뮤니케이션 비용이 급증하기 때문에 잘 설계된 지식 시스템은 우리가 일하는 속도와 품질을 지켜주는 중요한 인프라입니다.

지금 토스의 Technical Writing Chapter가 하는 일은 크게 네 파트로 나뉩니다.

첫 번째, 제품을 만들어요. 사내 지식을 관리하는 플랫폼 '토독'을 직접 만들고 운영하는 팀을 이끌고 있어요.

두 번째, 각 조직에 들어가 문서화를 주도해요. 각 조직에 맞는 방식으로 흩어진 지식을 모으고, 활용도를 극대화합니다. 조직마다 필요한 지식 시스템의 성격이 달라서 접근 방식도 달라져요.

세 번째, 이 과정에서 사람이 하는 Technical Writing을 없앱니다. AI 워크플로와 자동화로 모두가 비슷한 품질로 문서를 쓰고 리뷰 받을 수 있게 합니다.

마지막으로, 토스의 문서화 문화를 만듭니다. 전 커뮤니티 대상으로 AI가 잘 읽을 수 있는 문서를 쓰는 방법 같은 주제로 세션을 열어요. 또 조직별로 문서화 길드와 지식 커미티를 운영하며 토스 곳곳에서 지식을 다루는 방식 자체를 바꿔 나가고 있어요.

이 시리즈에서 다룰 이야기

이 시리즈에서는 앞으로 이런 이야기를 들려드릴게요.

저희 직무의 이름은 여전히 ‘Technical Writer’지만, 실제로 하는 일은 조직의 지식 인프라를 설계하는 것에 가까워요. 정해진 직무를 수행한 게 아니라, 풀어야 할 문제를 따라가다 직무를 새로 그린 거죠. 그러다 어느새 업계 어디에도 없는 모습이 됐습니다.

그리고 이건 Technical Writing만의 이야기가 아니라고 생각해요. AI가 모든 직군의 일을 다시 정의하는 지금, 자기 직무의 외연을 스스로 넓히는 일은 누구에게나 열려 있는 선택지니까요. 한 명이었던 챕터가 셋이 되고 더 많은 동료를 찾고 있는 지금, 저희 이야기를 하나씩 풀어볼게요.

매일 하던 업무를 디자인하기

2026-06-17T14:06:00+09:00

안녕하세요. 토스뱅크에서 주택담보대출을 디자인하고 있는 Product Designer 김혜미입니다.

이번 글에서는 프로덕트가 아니라, 제가 일하는 방식을 디자인했던 이야기를 해보려고 해요.

매일 할 일을 손으로 옮겨 적었다

토스에 입사한 첫 주부터 저는 할 일을 매일 손으로 정리했어요. 처음엔 노션이었고, 나중에는 슬랙이었죠. 제 일의 대부분은 슬랙에서 시작되는데, 피드백이나 요청 스레드, 논의 링크를 다시 노션으로 옮기는 일이 번거로웠거든요.

하지만 채널이 바뀌었을 뿐 본질은 같았어요. 매일 아침 할 일을 정리하고, 끝난 일은 체크하고, 새 업무를 추가하고, 참고 링크를 붙였죠. 이렇게 2년 반을 했어요.

이게 이상하다고 생각해본 적은 없었어요. 할 일을 정리하고, 흩어진 맥락을 모으는 일은 원래 업무의 일부라고 생각했거든요.

그래서 한 번도 이런 의문을 가진 적이 없었죠.

"이걸 꼭 내가, 손으로, 매일 해야 하나?"

참을 문제가 아니라, 디자인할 문제

그러다가 할 일을 도저히 제가 관리할 수 없는 시기가 왔어요. 올해 초, 세 팀을 동시에 맡게 되면서 업무량이 크게 늘었거든요.

처음 슬랙에 할 일을 정리하던 시절엔 하루 10개 안팎이었는데, 어느 순간 20개가 넘었어요. 이제 더 이상 수기로는 할 수 없는 수준이 됐다고 생각했죠.

보통 여기서 더 좋은 할 일 앱을 찾거나, 더 열심히 관리하는 쪽으로 가잖아요. 저는 세 번째 길을 골랐어요. 이 불편을 제가 매일 쓰는 프로덕트라고 생각하고 디자인하기로 한 거예요.

프로덕트를 디자인할 때 늘 하던 방식을 그대로 적용했어요.

사용자는 누구인가? → 나
진짜 하려는 일은 무엇인가? → 할 일을 정리하는 게 아니라, 지금 가장 중요한 일을 놓치지 않고 처리하는 것
어디에서 마찰이 발생하는가? → 할 일을 옮겨 적고, 정리하고, 출처를 찾아가는 반복 작업
무엇이 잘된 상태인가? → 해야 할 일이 자동으로 모이고, 우선순위만 판단하면 되는 상태

이렇게 문제를 정의하고 나니 만들어야 할 것도 자연스럽게 따라왔어요.

할 일은 슬랙에서 생기는데, 그걸 옮겨 적는 게 일이다 → AI가 알아서 등록하게 하자
옮겨 적다 보면 왜 하는지 잊는다 → 출처 스레드와 문서 링크를 함께 남기자
뭐부터 해야 할지 모르겠고, 안 보이면 잊는다 → 우선순위를 붙이고 항상 보이는 위젯으로 두자

할 일 앱은 넘쳐나지만, 세상 어떤 앱도 제가 어떤 채널을 보는지, 무엇을 중요하게 생각하는지, 왜 이 일을 하는지까지는 모르잖아요. 그 맥락을 아는 사람은 저뿐이었어요. 그래서 직접 만드는 게 답이었죠.

AI에게 내 일을 이해시키기

위젯 동작 자체는 단순해요. 슬랙에서 특정 이모지를 달면 메시지가 한 채널에 모이고, Claude Code가 그 내용을 읽어 할 일로 등록해요. 출처 스레드 링크도 함께요.

말로는 간단해보이지만 실제로는 전혀 그렇지 않았어요.

가장 어려웠던 건 긴 맥락의 메시지를 한 줄의 할 일로 바꾸는 것이었어요.

슬랙 메시지는 길고 맥락이 잔뜩 붙어 있잖아요. 이걸 한눈에 알아볼 수 있는 한 줄의 할 일로 바꾸고, 알맞은 팀까지 연결해야 했어요. 군더더기를 걷어내고, 진짜 해야 할 일만 남기는 일이었죠.

예를 들어 "대출에서 연장 신청할 때 이런 에러가 떠요. 봐주실 수 있을까요?"라는 메시지가 오면, 위젯에는 "대출 연장 에러 케이스 확인"이라는 한 줄의 할 일로, 해당 팀 태그와 함께 들어와야 했죠.

처음부터 잘 되지는 않았어요. 요약이 너무 길어지기도 하고, 핵심을 놓치기도 하고, 엉뚱한 팀에 들어가기도 했어요.

그래서 UX 라이팅 가이드를 만들듯 접근했어요.

좋은 할 일은 어떤 형태인지, 어떤 기준으로 팀을 나눌지, 어떤 표현을 사용할지를 예시와 규칙으로 하나씩 정의했죠.

그리고 결과가 "내가 직접 적었을 법한 문장"이 될 때까지 계속 다듬었어요.

돌이켜보면 이 과정이 가장 디자인에 가까웠어요.

코드를 짠 게 아니라, 무엇이 진짜 할 일인지, 그걸 어떤 언어로 표현해야 하는지에 대한 제 판단을 AI가 따라 할 수 있게 만드는 일이었거든요.

위젯을 실제로 쓰고 싶을 만큼 자연스럽게 만드는 것도 힘들었어요.

작게 접힌 상태에서 펼쳐지는 동작 하나를 다듬다가 코드를 전부 갈아엎고 다시 만든 적도 있었고, 드래그 기능은 일주일 가까이 붙잡고 있었어요.

두 경우 모두 결국 중요한 건 AI에게 어떻게 설명하느냐였어요. 머릿속에서는 너무 당연한 것도 한 줄 한 줄 풀어서 설명해야 했어요. AI에게 내 일을 이해시키는 일은, 결국 제 요구를 더 또렷한 언어로 정의하는 과정이었어요.

놓칠 걱정 대신 우선순위 고민하기

이제 할 일을 보기 위해 슬랙이나 노션을 열지 않아요. 위젯이 늘 화면 위에 떠 있으니까요. 별것 아닌 것 같지만, 저는 하루에도 수십 번 "할 일이 뭐였더라?" 하며 다른 창을 열고 있었더라고요. 불편한 줄도 모르던 불편이 사라진 거예요.

진짜 달라진 건 제 머릿속이에요. 예전에는 할 일을 모으고 정리하는 데 계속 에너지를 썼어요. 지금은 그 일을 AI가 대신 해주니까, 저는 무엇부터 해야 하는지만 고민하면 돼요. 무언가 놓칠 것 같은 불안감이 없으니, 우선순위를 판단하는 데 더 많은 시간을 쓰게 됐죠.

사실은 모두의 문제였다

저 혼자 쓰려고 만든 도구였지만, 지금은 팀의 많은 분들이 사용하고 있어요. 돈 주고서라도 쓰고 싶은 서비스라고 말씀해 주신 분도 계시고요.

특히 개발자분들의 반응이 의외였어요. 저는 개발자분들은 이미 더 좋은 도구를 쓰고 있거나, 필요하면 직접 만들어서 해결할 거라고 생각했거든요.

그런데 오히려 먼저 찾아와 버그를 제보하고 기능을 제안해주시더라고요.

평소에는 디자이너인 제가 개발자분들께 "이것 좀 고쳐주세요"라고 요청하는 입장이었는데, 이번에는 반대의 그림이 펼쳐진 거죠.

개발자분이 버그를 알려주고, 제가 수정해서 다시 배포하는 모습이요.

그 역할이 뒤바뀐 것도 신기했지만, 그보다 더 흥미로웠던 건 제가 개인적인 문제라고 생각했던 불편이 사실은 여러 사람이 함께 겪고 있는 문제였다는 점이었어요. 할 일을 정리하고, 우선순위를 관리하고, 흩어진 맥락을 모으는 일은 직무와 상관없이 많은 사람들이 비슷하게 겪고 있었던 거죠.

이 위젯이 퍼진 이유도 획기적인 아이디어여서가 아니라, 많은 사람들이 이미 겪고 있던 불편을 해결했기 때문인 것 같아요. 회사에서 제품을 디자인할 때도 마찬가지잖아요. 새로운 문제를 찾는 것보다, 이미 겪고 있는 문제를 해결하는 게 더 중요하니까요.

적용해보기

AI로 바꾼 제품 설계의 순서

2026-06-17T13:56:00+09:00

안녕하세요. 토스에서 고객센터 챗봇 설계를 담당하고 있는 Product Designer 김유라입니다. 이번 글에서는 토스 고객센터 AI 챗봇을 만들면서 시도했던 새로운 설계 방식을 이야기해 보려고 해요.

배경

고객센터 방문자는 한 달에 약 60만 명이고, 그 중 약 17만 명이 채팅 상담을 시도해요. 그런데 챗봇에 들어온 사용자의 약 60%가 중간에 이탈했어요. 가장 큰 문제는 챗봇의 구조였죠.

통신3사와 관련된 문의를 하려면 거쳐야 하는 과정

원하는 답을 찾으려면 메뉴를 하나씩 눌러가며 탐색해야 했어요. 문제는 사용자는 자신의 문제는 알아도, 서비스가 그걸 어떤 카테고리로 분류했는지는 모른다는 거예요.

"결제가 안 돼요."

"프리미엄 멤버십을 해지하고 싶어요."

"송금을 잘못 보냈어요."

사용자가 아는 건 이게 전부예요. 그래서 카테고리를 찾아야 하는 구조 자체를 없애고, 자연어로 말하면 AI가 의도를 파악해서 필요한 행동으로 바로 연결해 주는 경험으로 바꾸기로 했죠.

설계 방식을 뒤집다

챗봇은 보통 이런 순서로 만들어져요.

고객 문의 분석 → 유형 정리 → 시나리오 작성 → 리뷰 및 수정 → 프로토타입 제작 → 개발

시나리오란 특정 문의가 들어왔을 때 챗봇이 어떤 순서로 무슨 말을 할지 미리 짜놓은 대화 흐름인데요. 가장 설계하기 복잡한 부분이에요. 예를 들어 "프리미엄 멤버십을 해지하고 싶어요"라는 하나의 문의에도 전혀 다른 여러 상황이 숨어 있거든요.

이번 달 이용료를 이미 결제한 고객
아직 결제하지 않은 고객
혜택을 이미 사용한 고객
혜택을 한 번도 사용하지 않은 고객
해지 예약이 이미 되어 있는 고객

사용자는 모두 같은 말로 시작하지만, 확인해야 할 정보도 안내할 내용도 달라요. 하나의 문의처럼 보여도 뒤에서는 수십 개의 분기가 생기죠. 보통은 모든 시나리오를 완성한 뒤 프로토타입을 만들어요. 그런데 이번에는 순서를 조금 바꿔보기로 했어요.

시나리오를 먼저 완성하는 대신, AI로 시나리오 초안을 만들고 곧바로 프로토타입에서 검증하기 시작한 거예요. 시나리오와 프로토타입을 함께 발전시키는 방식으로요.

1단계) 실제 상담 데이터로 시나리오 초안 만들기

고객센터에서 가장 많이 발생하는 상담 유형 20개를 뽑아서 AI가 시나리오 초안을 만들도록 했어요. 학습에 활용한 데이터는 개인정보를 제거하고 가명·익명 처리한 뒤 활용했죠.

우리가 만들고 싶었던 건 정책을 잘 설명하는 챗봇이 아니었어요. 고객의 문제를 이해하고, 필요한 정보를 확인하고, 해결 방법까지 자연스럽게 안내하는 ‘사람 같은 챗봇’이었죠.

그래서 시나리오를 만들 때 AI가 어떤 정보를 참고하게 할지 고민했어요. 상담 가이드에는 정책과 기능이 잘 정리되어 있었지만, 실제 상담이 어떻게 진행되는지는 담겨 있지 않았어요. 반면 상담 데이터에는 고객이 어떤 표현으로 질문하는지, 상담사가 어떤 순서로 문제를 해결하는지 생생한 정보가 그대로 담겨 있었어요.

고객은 "결제가 왜 안 되죠?"처럼 넓은 문제를 이야기하지만, 상담사는 필요한 정보를 확인하고 원인을 하나씩 좁혀가며 문제를 해결하잖아요. 복잡한 정책과 기능도 고객이 이해할 수 있는 언어로 풀어서 설명하고요.

그래서 AI에게 정책을 학습시키기보다 상담 경험을 학습시키는 게 더 효과적이라고 판단했어요. 결과적으로 AI는 단순히 정보를 나열하는 대신, 실제 상담사가 고객을 응대하는 방식에 더 가까운 시나리오를 만들 수 있었어요.

2단계 ) 수십 개의 상황을 빠르게 검증하기

시나리오 초안을 만들고 바로 프로토타입을 만들었어요. 답변이 어색한지, 질문 순서가 이상한지 실제로 대화를 해봐야 알 수 있으니까요.

그런데 위에서 말했듯, 하나의 문의에도 수십 개의 상황 조합이 존재했어요. 매번 조건을 바꿔가며 테스트하는 건 너무 비효율적이었죠.

그래서 다양한 상황을 빠르게 검증할 수 있는 시나리오 허브를 만들었어요.

같은 '프리미엄 멤버십 해지' 문의라도 '이미 이번 달 결제를 완료한 고객', '혜택을 사용한 고객'처럼 여러 상황이 있을 수 있잖아요. 이런 조합을 미리 저장해두고 원하는 시나리오를 선택할 수 있도록 했어요. 상황을 선택하면 오른쪽에서 해당 조건이 적용된 상태로 챗봇 대화가 바로 시작됐고요.

덕분에 시나리오를 수정한 뒤에도 해당 상황으로 바로 들어가서 답변이 의도대로 나오는지 빠르게 확인할 수 있었어요. 새로운 분기가 추가되거나 규칙이 변경될 때도 같은 방식으로 반복 검증할 수 있었고요.

무엇보다 좋았던 건 진짜 같은 결과물을 바로 만들어볼 수 있었다는 점이었어요. 시나리오만 봤을 때는 괜찮아 보였던 흐름도 실제로 대화를 해보면 어색한 경우가 많았거든요.

실제 데이터를 적용한 상태로 프로토타입을 만들 수 있으니 고객이 겪게 될 경험을 훨씬 현실적으로 볼 수 있었어요. 덕분에 '이럴 것 같다'가 아니라 '실제로 이렇다'를 기준으로 판단할 수 있었죠.

결과적으로 이 프로토타입은 단순한 목업이 아니라, AI가 생성한 시나리오를 테스트하고 개선하기 위한 실험 환경이 되었어요.

3단계) 시나리오를 고치기보다 규칙을 만들기

시나리오 허브를 만들고 실제로 대화를 검증해 보니 예상하지 못한 문제들이 계속 발견됐어요.

이미 알고 있는 정보를 다시 물어보기도 하고, 같은 설명을 반복하기도 하고, 틀린 정보를 추측해서 답변하기도 했어요.

처음에는 문제를 발견할 때마다 시나리오를 하나씩 수정했어요. 그런데 검증할수록 비슷한 문제가 반복해서 나타났어요. 그래서 개별 시나리오를 수정하는 대신, 이런 문제를 방지하기 위한 규칙을 만들기 시작했어요.

예를 들면 이런 원칙들이요.

해결이 먼저, 설명은 나중에
추측하지 말고 모르면 모른다고 하기
상담사 연결은 특정 조건에서 진행하기
AI의 권한 경계 확실히 하기

시나리오를 검증할 때마다 규칙이 하나씩 늘어났고, 그 규칙을 다시 AI에게 반영했어요.

시나리오를 수정하면 하나만 좋아지는데, 규칙 하나를 수정하면 모든 시나리오가 같이 좋아지기 때문에 규칙을 만들수록 검증 속도가 빨라졌죠.

경험을 먼저 만들고, 나머지는 나중에 정의하기

이번 프로젝트에서 가장 재밌었던 점은 이상적인 사용자 경험을 먼저 그려보고, 그 경험을 구현하는 데 필요한 것들을 하나씩 역산해 나갔다는 거예요. 보통은 데이터 구조를 정의하고, 운영 도구를 만들고, 시스템을 설계한 뒤 그 위에 사용자 경험을 고민하죠. 그런데 이번에는 반대로 진행했어요.

그러다 보니 오히려 그다음에 필요한 것들이 선명하게 보이기 시작했어요.

"이 경험을 구현하려면 어떤 데이터가 필요하지?"

"어떤 API가 필요하지?"

"어떤 운영 도구가 필요하지?"

이렇게 하니까 처음부터 모든 걸 설계하는 대신, 정말 필요한 것만 빠르게 정의할 수 있었어요. 팀에 합류하고 약 3주 만에 현황 분석부터 경험 설계, 시나리오 생성, 프로토타입 제작, 검증, 고도화까지 진행할 수 있었죠.

AI가 바꾼 것은 단순한 생산성이 아니라 제품을 설계하는 순서였어요. 구현을 전제로 경험을 설계하는 것이 아니라, 경험을 먼저 그려보고 검증한 뒤 필요한 것들을 정의하는 방식으로요. 그래서 AI는 일을 대신 해주는 도구라기보다, 좋은 경험을 훨씬 빠르게 검증할 수 있게 해주는 도구에 가까웠어요.

디자이너가 시간을 쓰는 지점도 달라졌어요.

예전에는 화면을 그리고 시나리오를 작성하는 데 많은 시간을 썼어요. 좋은 아이디어가 있어도 구현 비용이 크다 보니 실제로 검증해 보기 전에 포기하는 경우도 많았고요.

그런데 이번 프로젝트에서는 상황이 조금 달랐어요. AI 덕분에 시나리오를 만들고, 프로토타입을 구현하고, 검증하는 비용이 크게 줄어들었거든요. 덕분에 화면을 그리거나 시나리오를 작성하는 시간보다, 어떤 경험이 더 좋은 경험인지, 어떤 규칙이 더 좋은 규칙인지, 무엇을 검증해야 하는지를 판단하는 시간이 더 중요해졌어요.

AI가 대신 만들어준 게 아니라, 더 많은 선택지를 빠르게 검증할 수 있게 된 거죠.

이런 방식은 챗봇을 만드는 과정뿐 아니라, 새로운 제품이나 기능을 설계할 때도 충분히 적용될 수 있을 것 같아요.

적용해 보기

1️⃣ 완벽하게 설계하려고 하지 말고 먼저 만들어보기

구현이 어렵거나 비용이 많이 들 것 같아서 미뤄두고 있는 아이디어가 있나요? AI를 활용하면 생각보다 빠르게 프로토타입을 만들 수 있어요. 완벽한 설계가 끝날 때까지 기다리기보다 먼저 만들어보고 검증해 보세요. 어떤 문제가 있는지, 어떤 방향이 맞는지 훨씬 빨리 알 수 있어요.

2️⃣ 가이드보다 실제 데이터를 먼저 살펴보기

실제 사용자 데이터에는 문서에 없는 맥락이 숨어 있는 경우가 많아요. 사용자가 어떤 표현을 쓰는지, 어디에서 막히는지, 실제로 어떻게 문제를 해결하는지 먼저 살펴보세요. 생각보다 많은 답이 이미 사용자 행동 안에 들어있을 수 있어요.

3️⃣ 같은 문제를 반복해서 고치고 있다면 규칙을 찾아보기

비슷한 문제가 여러 번 반복된다면 개별 수정보다 공통 원칙을 만드는 편이 더 효과적일 수 있어요. 규칙 하나가 수십 개의 케이스를 동시에 개선하기도 하니까요.

디자이너가 시안 대신 앱을 만든 이유

2026-06-16T10:06:00+09:00

디자인 과정에서 AI를 쓰며 달라진 것 중 하나는, 디자이너가 직접 동작하는 시안을 만들 수 있게 되었다는 점이에요. 예전에는 디자인을 만들고, 문서로 설명하고, 개발자가 다시 구현하는 과정이 필요했어요. 그런데 AI와 함께 코드를 다루기 시작하면서 디자인과 개발 사이의 번역 과정이 크게 줄어들기 시작했죠.

이번 글에서는 토스의 underlay 컴포넌트를 만들며 경험했던 변화를 이야기해 보려고 해요.

경험이 끝난 뒤를 설계하기

토스 앱에는 경험이 끝나는 화면들이 있어요.

송금을 마치고 나오는 송금 완료 화면, 결제가 끝난 뒤의 결제 완료 화면처럼 사용자가 할 일을 모두 마친 화면들이죠. 대부분은 거기서 앱을 닫고요.

이런 화면들을 '데드엔드'라고 불렀어요. 데드엔드를 더 이상 경험의 끝이 아니라, 다음 경험의 시작점으로 만들고 싶었죠. 그렇게 데드엔드 프로젝트가 시작됐어요.

목표는 특정 화면 하나를 개선하는 것이 아니었어요. 앱 안 어디에서든 다음 경험으로 자연스럽게 이어질 수 있도록 돕는 공통된 장치가 필요했죠. 그래서 먼저 컴포넌트를 만드는 것부터 시작하기로 했어요.

택배 송장이 준 힌트

컴포넌트를 만들기로 하고 가장 먼저 조건을 정리했어요. 기능으로 인지되어야 하고, 기존 사용자 경험을 해치면 안 되고, 앱 안 어디서든 재사용할 수 있어야 했죠.

여러 가지 방향을 시도해 봤어요. 전화가 오는 것처럼 등장하는 방식, 화면 한쪽에 나타나는 방식, 채팅창처럼 올라오는 방식… 그런데 전부 사용자의 동작을 방해할 수밖에 없는 구조였어요.

바텀시트, 토스트, 푸시처럼 우리가 익숙하게 사용하는 UI는 대부분 화면 위에 올라오는 구조예요. 사용자의 시선을 끌 수는 있지만, 동시에 사용자가 보고 있던 화면이나 하려던 행동을 방해할 수도 있죠.

그래서 기존의 알림성 UI와는 다른 방식이 필요했어요.

실마리는 예상치 못한 곳에서 왔어요.

이사를 하던 중 택배 상자에 붙어 있던 송장을 떼어냈는데, 그 밑에 가려져 있던 책의 문구가 드러난 거예요. 새로운 것이 나타난 게 아니라 원래 거기 있던 것이 모습을 드러낸 거였죠. 그 순간 관점을 바꿔보게 됐어요.

“위에 띄우는 것이 아니라 아래에 존재하던 것이 드러난다면 어떨까?”

그렇게 화면 위(overlay)가 아니라 아래에 깔린 컴포넌트, underlay를 만들기로 했어요.

인터랙션 툴 대신 코드로 디자인하다

디자인을 시작하면서 곧바로 다른 문제가 생겼어요.

처음에는 피그마로 시안을 만들었어요. 이 컴포넌트는 실제 손안의 화면에서 경험하게 되는 인터랙션이잖아요. 그래서 시안을 폰에 띄워두고 밥을 먹을 때도, 이동할 때도 계속 들고 다니면서 봤어요. "이 느낌이 맞나?" 계속 확인하면서요.

피그마 시안을 통해 깨달았어요. underlay는 어떻게 생겼는가보다 어떻게 움직이는가가 더 중요한 컴포넌트였거든요. 인터랙션 자체가 디자인이었죠.

문제는 제가 인터랙션 툴을 제대로 다뤄본 적이 없다는 거였어요. 프로토파이 경험도 없고, 프레이머 경험도 없었어요. 대신 다른 방법을 선택했어요. 인터랙션이 중요한 작업이라 웹 개발 대신 SwiftUI 기반으로 Xcode에서 iOS 앱을 직접 만들었어요.

작업 환경

물론 저는 SwiftUI를 다뤄본 적이 없었어요. 하지만 AI가 있었죠. Xcode를 열고, 만들려는 걸 AI에게 시켰어요. 문법은 AI가 알고 있었고, 원하는 결과물은 이미 제 머릿속에 있었어요.

제 역할은 세 가지였어요.

어떤 경험을 만들고 싶은지 설명하기
AI가 제안한 방향 중 더 좋은 것을 선택하기
실제 기기에서 결과물을 보고 판단하기

AI와 함께 디자인하는 과정은 결국 설계하고, 선택하고, 판단하는 일의 연속이었어요.

작업 순서

1. 기본 환경 세팅하기

먼저 이것저것 그려보고 지울 수 있는 저만의 플레이그라운드를 만들었어요. 피그마에서 새 파일을 파는 것처럼요. 컴포넌트가 들어갈 화면 구조를 만들고, 기본 디자인을 올렸어요. 이때 피그마로 작업한 시안을 AI에게 예시로 주기도 했고요.

디자인 시안 갤러리

인터랙션 효과 구현을 위한 테스트 그라운드

2. 실제로 움직여보며 디자인하기

그다음 버튼, 텍스트, 레이아웃 같은 디테일을 하나씩 다듬었어요. 중요한 건 정지 화면으로 보지 않았다는 점이에요. underlay는 인터랙션 자체가 디자인인 컴포넌트였기 때문에, 수정할 때마다 실제 기기에서 직접 움직여봤어요. 상상한 것과 실제로 구현돼서 움직이는 건 생각보다 느낌이 많이 달랐거든요. 그래서 진짜 몇백 번씩 수정했어요.

3. 원하는 질감이 나올 때까지 다듬기

이 컴포넌트는 화면을 읽고 그 맥락에 맞는 정보를 제공하는 역할을 해요. 그래서 "AI가 화면을 읽고 알맞은 정보를 찾아준다"라는 심상을 만들어보고 싶었어요. 여러 표현을 고민하다가, 빛이 화면을 훑고 지나가는 스캔 인터랙션을 만들기로 했어요. 스캔 효과는 Metal 셰이더로 구현했어요.

셰이더는 화면의 픽셀 하나하나를 어떻게 그릴지 직접 계산하는 그래픽 코드인데, 빛이 번지고 퍼지는 질감은 일반적인 UI 코드로는 표현하기 어렵거든요.

처음에는 AI가 작성한 코드를 사용했지만, 계속 수정하다 보니 어느 순간부터는 직접 값을 조정하고 있더라고요. 빛의 번짐, 틴트, 폭, 지나가는 속도, 배경이 어두워지는 정도 같은 요소들을 바꿔가며 원하는 질감을 찾았어요.

실제 작업한 메탈 코드

스캔 효과 1차 안

스캔 효과 최종안

스캔이 지나갈 때나 컴포넌트가 등장할 때 미세하게 출렁거리는 디테일도 같은 방식으로 다듬었고요.

등장 시 디테일 다듬기

스캔 시 디테일 다듬기

인터랙션 툴을 한 번도 써본 적 없는 사람이 어느새 셰이더 코드의 숫자를 만지고 있었던 거예요.

디자인 가이드 대신 레포를 전달하다

시안이 완성되고 개발을 시작했어요. 이 미세한 인터랙션을 개발자에게 어떻게 전달해야 할지 고민이 됐죠. 보통이라면 등장 타이밍, 이징 커브, 딜레이 값을 정리한 인터랙션 가이드 문서를 만들었을 거예요.

그런데 이번에는 방식을 조금 바꿔봤어요. 인터랙션에 대한 자세한 가이드 없이 간략한 플로우만 정리하고, 제가 디자인하며 만든 레포를 그대로 전달했죠.

솔직히 괜찮을까 싶었어요. 그런데 개발자분들이 레포를 보더니 "일단 이 정도면 될 것 같다"라고 하시더라고요. 그리고 실제로 첫 개발 버전부터 시안의 기본 구조를 거의 그대로 구현해 주셨어요. 제가 예상했던 것보다 디자인 완성도가 훨씬 높았죠.

완성도를 끌어올리는 파인튜닝 단계에서는 더 재미있는 일이 생겼어요. UI 디테일을 조정할 때마다 개발자분들이 저한테 노트북을 주시더라고요.

opacity 같은 값은 "0.4로 해주세요 → 빌드 → 음, 0.5로요 → 빌드"를 반복하는 것보다, 직접 보면서 수정하는 편이 훨씬 빠르니까요.

그러다 등장 인터랙션 차례가 왔을 때는 개발자분 노트북에서 제가 AI에게 직접 명령을 내리기 시작했어요. 머릿속의 모션을 설명하고, 결과를 보고, 다시 수정하고 명령을 내렸죠. 그랬더니 인터랙션 퀄리티가 확 높아졌어요. 옆에서 보던 개발자분이 그러시더라고요.

"얘가 민지 님 말을 더 잘 듣네요…"

이 과정이 수월했던 이유 중 하나는 동작하는 레퍼런스가 있었기 때문이에요.

시안 단계에서 직접 만들었던 코드가 있었기 때문에, "느낌이 이상해요" 같은 추상적인 표현 대신 어떤 동작을 원하는지 구체적으로 설명할 수 있었어요. AI와도, 개발자분들과도 같은 결과물을 보며 이야기할 수 있었죠.

이런 과정을 거쳐 underlay는 실제 서비스에 적용됐어요. 아직 실험이 진행 중이기는 하지만, 예상했던 것보다 좋은 결과가 나오고 있고요.

보이는 것을 넘어, 구조까지 디자인하기

이번 프로젝트에서 가장 신기했던 건 실제 개발된 버전의 코드 구조가 제가 디자인했던 레포와 거의 동일했다는 점이었어요(iOS 기준).

처음부터 개발을 염두에 둔 건 아니었어요. UT를 하면서 여러 버전을 빠르게 바꿔보고 싶었고, 제가 테스트하기 편한 구조를 만들다 보니 자연스럽게 그렇게 된 거였죠. 그런데 나중에 보니 그 구조가 실제 개발에도 그대로 활용할 수 있는 형태였어요. 그래서 파인튜닝 과정에서도 수정 사항을 말로 설명하기보다 코드로 전달할 수 있었고요.

이게 이 프로젝트에서 가장 크게 배운 점이었어요.

좋은 시안은 단순히 보기 좋은 화면만을 의미하지는 않는다는 점이요. "보이는 것"만이 아니라 "만들어진 방식"까지 괜찮아야 하죠. 화면은 같아 보여도 일회용 코드 덩어리였다면 개발자분들은 결국 처음부터 다시 만들었을 거예요. 하지만 개발할 수 있는 구조로 만들어진 시안은 그대로 스펙이 될 수 있었어요.

이제 디자이너가 코드로 디자인하는 일 자체는 점점 특별한 일이 아니게 될 것 같아요. 오히려 차이를 만드는 건 그다음이에요. "어떻게 만들지"는 AI가 알고 있으니, 디자이너에게 남는 질문은 "뭘 만들까"거든요. 툴의 제약 때문에 포기했던 것들이 사라진 자리에서, 뭘 상상하고 뭘 만들기로 결정하느냐. 그게 디자인의 전부가 되는 것 같아요.

적용해 보기

underlay의 이야기는 여기까지지만, 이 방식은 어떤 프로젝트에서든 시도해볼 수 있어요.

1️⃣ 툴의 제약 없이 가장 좋은 디자인부터 생각하기

디자인하고 싶은 게 있다면 더 이상 툴의 제약은 없어요. "만들 수 있는 디자인"이 아니라 "가장 좋은 디자인"부터 그려보세요. 어떻게 만들지는 AI와 풀면 되니까요

2️⃣ 그림이 아니라 실물 만들기

시안을 그림으로 두지 말고, AI와 코드로 실제로 동작하는 걸 만들어보세요. 실물에서만 보이는 디테일이 있고, 툴로는 표현하지 못하던 질감까지 만들 수 있어요.

3️⃣ 가이드 문서 대신 동작하는 코드 전달하기

개발자에게 인터랙션을 넘길 때, 말로 설명한 문서보다 직접 만든 레포 하나가 더 정확하게 전달돼요.

2,800만 MAU를 이해하는 유저 Segmentation, TUES

2026-06-16T10:00:00+09:00

안녕하세요, 토스 Director of Data Analytics 우찬희입니다.

저는 Data Intelligence and Analytics Team을 이끌며 전사적으로 주요한 의사결정을 잘 내릴 수 있도록 데이터를 분석하고, 새로운 프레임워크를 만들고 데이터 분석 거버넌스를 만드는 업무를 하고 있어요.

오늘은 토스의 2,800만 MAU를 분석할 때 활발히 활용하고 있는 유저 세그먼트, TUES(Toss User Engagement Segment) 를 소개해 드릴게요.

TUES가 무엇인가요?

토스와 같은 플랫폼 앱에서 유저 분석을 하다보면 이런 고민이 자연스레 들게 돼요.

“유저들은 왜, 무엇을 위해 우리 앱을 이용하는 걸까?” “앱 이용의 주 목적이 A 서비스인 유저는 얼마나 될까?” “A 서비스는 우리 앱 MAU와 다른 지표에 얼마나 영향을 끼치는 걸까? B 서비스랑 비교하면 어떨까?” “각 유저의 이용 패턴을 안다면 각 패턴마다 더 적절한 전략을 취할 수 있지 않을까?”

토스에서도 비슷한 고민이 계속 있었어요.

각 서비스 내에서 ‘A 서비스를 이용한 유저’, ‘B 서비스를 이용한 유저’와 같은 방식으로 정의해서 진행하긴 했지만, 이건 MECE(Mutually Exclusive, Collectively Exhaustive) 하지 않죠. 유저는 둘 다 이용할 수 있으니까요.

즉, 플랫폼 관점의 유저 세그먼테이션이 필요했습니다. 이를 위해 만들어진 것이 바로 TUES입니다. 각 유저의 서비스 이용 패턴을 기준으로 비슷한 유저들끼리 묶어둔 세그먼트라고 봐주시면 돼요. (참고로 ‘튜스’라고 읽습니다.)

결과적으로 TUES는 각 유저가 어떤 유저인지, 우리 앱의 어떤 서비스를 좋아하고 주로 이용하는지를 바로 파악할 수 있는 도구의 역할을 합니다.

이 TUES는 진화를 거듭해 현재 V2가 적용되어 있습니다. 그 여정을 하나씩 소개해 드릴게요.

TUES V1은 어떻게 만들어졌나요?

TUES V1을 정의하는 핵심 개념을 간단히 설명해 드릴게요.

토스가 제공하고 있는 서비스는 매우 많고, 유저는 각자가 원하는 서비스를 선택적으로 써요. 이걸 하나하나 조합을 만들어 파악하는 건 불가능했어요. 그래서 인사이트를 얻기 위해 머신러닝(ML) 알고리즘을 이용하기로 했습니다.

먼저 각 유저가 1회 앱오픈 시 각 서비스를 이용할 확률을 계산했어요. 예를 들어 한 달간 60번 앱을 켠 유저가 그 중 20번 토스페이를 썼다면, 이 유저의 토스페이 이용률은 33%가 되는 식이에요.

그러면 유저마다 각 서비스의 이용률 분포를 갖게 됩니다. 그리고 이 이용률 분포가 비슷한 유저들끼리 묶었어요. 묶는 도구로는 K-Means Clustering을 썼습니다. 다만 이 결과를 그대로 쓰지 않고 왜 이런 결과가 나왔는지를 분석해, 주요 키 서비스와 포인트를 찾은 뒤 전략·제품 관점에서 더 직관적으로 이해하고 활용할 수 있도록 각색하는 과정을 거쳤어요.

그렇게 만들어진 TUES V1의 세그먼트는 이렇게 구성됩니다.

TUES로 무엇을 할 수 있나요?

TUES 같은 세그먼테이션은 그 자체보다 활용에 더 가치가 있습니다. TUES는 아래와 같이 활용하고 있어요.

1️⃣ 세그먼트별 Transition 전략 수립의 기준이 됩니다.

각 세그먼트별로 특징이 꽤 명확해요. 이 특징을 활용해 세그먼트별 Retention Rate 제고, 타 서비스로의 Cross Activation, UX 개선 등의 전략을 세울 수 있습니다. 특히 고관여 유저의 MoM Retention이 매우 높은 반면, 단순 방문 유저는 낮아요. 중간에 있는 각 서비스 지향 세그먼트는 그 사이에 있고요.

그래서

“어떻게 하면 단순 방문 유저들을 각 서비스 지향 세그먼트로, 이들을 고관여로 보낼 수 있을까?”

라는 질문에 대한 대답을 큰 관점에서 찾을 수 있었어요.

2️⃣ 각 제품의 Growth 전략에 쓰입니다.

각 제품 입장에서는 “우리 제품을 어떤 유저가 많이 쓰고 있나” 를 TUES로 빠르게 파악할 수 있어요. 이 힌트를 바탕으로 1번에서 구한 대답과 결합하여 제품 Growth 전략을 세울 수 있었습니다.

3️⃣ 유저의 행동을 더 다각화하여 볼 수 있어요.

TUES를 통해 그동안 보기 힘들었던 유저의 행동 패턴들이 보이기 시작했어요. 세그먼트는 언제 무엇에 의해 바뀌는지, 언제 이탈하기 시작하는지, 부활하는 유저는 어떤 모습인지 등 유저의 행동을 플랫폼 관점에서 더 잘 이해할 수 있었습니다.

4️⃣ 탑라인 지표 분석의 기본 도구가 됩니다.

전사 MAU 같은 탑라인 지표가 흔들렸을 때 어떤 세그먼트가 움직였는지 보면, 어떤 서비스가 영향을 줬는지 쉽게 파악할 수 있어요. 탑라인 지표를 유저단위로 MECE 하게 증감 사유를 분석할 수 있게 된 거죠.

5️⃣ 푸시 같은 타겟마케팅에 매우 강력한 소스가 됩니다.

마케팅하려는 서비스 상황에 알맞은 세그먼트를 찾아 마케팅을 했을 때 그 효율이 크게 높아진 사례가 자주 나오고 있어요. 타겟 마케팅에서 어떤 조건보다도 활용도가 높아, TUES를 자주 쓰는 직군 중 하나가 마케터분들이라고 할 수 있을 정도입니다. 사내 마케팅 툴인 TUBA에도 기본 제공 세그먼트로 등록되어 있어 누구나 손쉽게 쓸 수 있습니다.

TUES V2 — 문제점 보완

V1을 2년 정도 쓰면서 “이걸 더 잘 할 수는 없을까” 라는 갈증이 점점 커졌어요. TUES가 풀고자 하는 문제는 그대로지만, 그 문제를 푸는 방법을 손볼 필요가 생긴 거죠.

V1이 아쉬웠던 점들은 이랬어요.

‘횟수’, 즉 ‘깊이’ 개념이 없었어요. V1은 ‘앱오픈 시 이용 확률’만 봤기 때문에, 한 번의 앱오픈에서 혜택서비스를 1번 이용한 유저와 10번 이용한 유저가 같이 취급됐어요. 깊이가 담기지 않았습니다.
각 세그먼트 유저의 다른 카테고리 Engagement가 안 보였어요. 같은 조회서비스 지향 유저라도 어떤 사람은 혜택서비스도 조금씩 같이 쓰고 어떤 사람은 조회서비스만 써요. 그런데 V1은 이 차이를 보여주지 못했어요. 서비스별 관여도 정보가 없었기 때문입니다.
한 유저는 한 세그먼트에만 속했어요. V1의 근간이 되는 K-Means Clustering은 Hard Clustering 알고리즘이에요. 실제 유저는 여러 서비스를 동시에 쓰는데, V1 로직 안에서는 그 복합성을 담을 수 없었어요.
새로 생긴 핵심 서비스가 누락돼 있었어요. 2년 사이 토스쇼핑·앱인토스·토스페이 등 중요한 서비스가 늘었는데 V1 로직 안에서는 모두 ETC로 처리됐어요.

결과적으로 V2는 세 가지 변화로 이 한계들을 풀었습니다.

1️⃣ 측정 방식이 횟수 기반으로 바뀌었어요.

‘앱오픈 시 이용 확률’ 대신 ‘서비스별 이용 횟수’를 그대로 다루기 시작했어요. 즉 앱오픈 1회당 이용 횟수를 Feature로 넣음으로써 V1에서는 부재했던 ‘깊이’를 반영했습니다.

2️⃣ Soft Clustering 알고리즘 적용

기존 Hard Clustering 알고리즘에서 Soft Clustering 알고리즘으로 바꾸면서, 한 유저가 하나의 세그먼트에만 속하는 게 아니라 각 세그먼트에 속할 확률(정확히 확률 개념은 아니지만)을 구하고 그것을 선별적으로 가져가는 구조로 바꿨어요. 이를 통해 V1에서는 담을 수 없었던 ‘복합성’까지 담을 수 있었어요.

3️⃣ 세그먼트 구조가 세 층으로 바뀌었어요.

한 유저를 ‘전체 앱 관여도’와 ‘주 이용 서비스’, ‘서비스별 관여도’ 세 가지로 동시에 표현할 수 있게 됐어요.

서비스별 관여도 정의 → 앱 전체 관여도 정의 → 주 이용 서비스 정의

이 세 개의 층을 단계적으로 쌓아 세그먼트를 만들기 때문에, 유저가 그 세그먼트에 배치된 이유를 더 자세히 알 수 있을 뿐만 아니라 Next Action도 더 효율적으로 수립할 수 있게 되었습니다.

TUES V1

TUES V2

Feature 기준

앱오픈 1회당 이용률

앱오픈 1회당 이용 횟수

결과물

전사 세그먼트

서비스별 관여도 세그먼트 앱 전체 관여도 세그먼트 주 이용 서비스 세그먼트

기반 모델

K-means (Hard) → Rule 생성

NMF (Soft) → Rule 생성

이용 서비스

6개

10개

Engagement 구분

3개

6개

V2로 어떤 것을 더 할 수 있나요?

크게 보면 V2는 V1에서 ‘서비스별 관여도’라는 차원이 더해진 거예요. 그래서 이런 일들이 가능해졌습니다.

실제로 Silo에서 서비스 관련 전략 분석을 할 때 어떤 세그먼트를 공략해야 할지를 빠르고 간편하게, 더 자세하게 볼 수 있는 환경이 마련되었습니다.

다음 단계

TUES는 앞으로 더욱 진화할 예정입니다.

활용 방안에 대해서 더 발전시킬 여지가 많아요. 앞으로 다양한 팀과 더 고도화해 나갈 예정입니다.

마무리하며

토스의 MAU는 계속해서 성장하고 있습니다. TUES는 이 MAU를 더 잘 이해하고 어떤 유저를 타겟해 어떤 액션을 해야 하는지, 그리고 그 액션이 전사적으로 어떻게 작동하는지를 해석할 수 있는 플랫폼 관점의 세그먼트입니다. 이 세그먼트 덕분에 MAU가 계속 늘어나더라도 유저들을 빠르고 직관적으로 그룹화하여 더 빠르고 정교한 분석과 전략을 짤 수 있어요.

토스의 Data Analyst 분들은 서비스를 효율적으로 성장시키기 위해 데이터 분석에 기반한 전략을 수립하는 업무와 더불어, 이런 분석이 더 빠르고 잘 진행될 수 있도록 TUES, MTVi 같은 분석 프레임워크를 만드는 업무도 함께 하고 있어요. 방대한 데이터로 유저의 행동을 분석하는 방법을 만들고, 그 방법으로 분석하고, 그 분석이 의사결정과 서비스의 성장으로 이어지게 만드는 일에 관심 있으신 분들은 토스 Data Analyst에 많은 관심 부탁드립니다.

소프트웨어 공급망 공격, pnpm으로 1차 방어선 구축하기

2026-06-19T00:00:00+09:00

안녕하세요. 인프랩 백엔드 개발자 후니입니다.

최근 공급망 공격(Supply-Chain-Attack)에 대한 보안 사고가 연이어 발생하고 있습니다. 올해 초 가장 논란이 되었던 LiteLLM 공급망 공격 사건, 자바스크립트 생태계에서 가장 널리 사용되는 HTTP 클라이언트 라이브러리인 Axios 패키지 배포망 오염까지 정말 많은 보안 사고가 발생했습니다. 이 글에서는 공급망 공격이 어떻게 일어나는지 살펴보고, 인프랩에서 어떤 방어 대책을 세우고 있는지 공유하고자 합니다.

소프트웨어 공급망 공격(Software Supply-Chain-Attack)

소프트웨어 공급망 공격(Software Supply-Chain-Attack)은 최종 공격 대상이 되는 서비스나 기업의 인프라를 직접 타격하지 않고, 대상이 개발 과정에서 신뢰하고 끌어다 쓰는 외부 자산(오픈소스 패키지, 빌드 환경, 서드파티 서비스 등)을 먼저 침해한 뒤 이를 징검다리 삼아 최종 내부 망으로 침투하는 고도의 우회 공격 기법입니다. 신뢰할 수 있는 개발 공급망의 일부가 오염되면 해당 공급망에 의존하고 있는 인프랩 시스템 역시 연쇄적으로 오염될 수밖에 없는 구조를 가지고 있습니다.

Axios 패키지의 사례

올해 3월경 발생한 Axios 사례를 간단히 설명하겠습니다. 이 사고는 개발자가 직접 작성한 코드나 명시적으로 선언한 직접 의존성이 아니라, 그 하위에 숨겨진 간접 의존성(transitive dependency) 트리를 오염시키는 방식으로 진행되었습니다. 해당 사례는 저희 사내 슬랙에서도 긴급히 공지되었는데요.

이 공격 사례를 간단히 정리하면 다음과 같습니다.

악성 공격자가 axios 리드 메인테이너의 npm 계정 탈취
공격자가 axios 의존성 트리에 악성 코드인 plain-crypto-js@4.2.1 강제 주입
탈취한 계정 토큰으로 npm CLI로 직접 수동 배포
이 사실을 몰랐던 사용자 환경에서 npm install 실행
postinstall 스크립트를 통해 백그라운드에서 악성 코드(드로퍼) setup.js 를 실행
드로퍼가 임의 명령실행이 가능한 RAT를 설치하였고, 그 공격자가 RAT을 통해 자격증명을 포함한 시스템 정보가 탈취될 수 있는 상태가 됨

해당 링크에서 Axios 공격 사례를 자세히 볼 수 있습니다.

이처럼 악성 코드가 사용자도 모르게 자동으로 실행될 수 있었던 것은 공격자가 npm lifecycle scripts를 악용했기 때문입니다.

lifecycle scripts의 실행 순서

lifecycle scripts는 패키지 설치나 배포 등 특정 상황이나 이벤트가 발생할 때, 그 전후에 자동으로 맞물려 실행되도록 미리 약속된 특별한 스크립트 단계입니다.

npm install 및 npm ci 명령어를 실행하면 아래 이미지와 같은 순서로 스크립트가 실행됩니다.

이 스크립트들은 node_modules에 실제 모듈이 설치된 직후에 실행됩니다

예를 들어 아래와 같이 package.json이 작성된 패키지를 npm install 하면, 각 단계의 스크립트가 정해진 순서대로 실행되어 터미널에 출력되는 결과를 쉽게 예상할 수 있습니다.

lifecycle scripts 사용 예시

여기까지가 lifecycle scripts의 기본 동작입니다. 그렇다면 이 메커니즘을 악용한 악성 버전의 Axios는 node_modules를 어떤 구조로 만들어 두었을까요?

node_modules/
├── axios/                    <- 1.14.1 (악성 게시 버전)
│   ├── dist/
│   ├── lib/
│   ├── index.js
│   ├── package.json          ⚠️ dependencies에 plain-crypto-js 추가됨
│   ├── LICENSE
│   └── README.md
├── plain-crypto-js/          ⚠️ 4.2.1 (악성 의존성 crypto-js 타이포스쿼팅)
│   ├── setup.js              ⚠️ 드로퍼 (약 4209 bytes) postinstall로 자동 실행
│   ├── package.json          ⚠️ "postinstall": "node setup.js" 포함
│   ├── package.md            ⚠️ 깨끗한 4.2.0용 package.json 사본 (위장 대기)
│   ├── index.js                  (crypto-js 원본 그대로 복사)
│   ├── core.js
│   ├── aes.js
│   └── ... (나머지 crypto-js 파일들)
├── follow-redirects/         ✅ 정상 axios 의존성
├── form-data/                ✅ 정상 axios 의존성
└── proxy-from-env/           ✅ 정상 axios 의존성

이 구조에서 주목할 점은, 공격자가 plain-crypto-js@4.2.1을 코드 어디에서도 import하지 않았다는 것입니다. 오로지 postinstall로 자동 실행되는 것만을 노리고, 악성 게시 버전의 의존성에 몰래 추가해 두었습니다. 그리고 그 postinstall 단계에서 실제 공격을 수행한 것이 바로 setup.js 드로퍼입니다.

setup.js 드로퍼는 무슨 일을 했나

setup.js(약 4.2KB)는 postinstall 단계에서 자동 실행되며, 대략 다음과 같은 순서로 동작하는 전형적인 자격증명 탈취형 드로퍼(credential-stealing dropper) 였습니다.

실행 환경 판별 - 운영체제, CI 환경 여부, 분석 샌드박스로 의심되는 흔적 등을 확인합니다. 분석 환경으로 판단되면 아무 일도 하지 않고 조용히 종료해 탐지를 회피합니다.
민감 정보 수집 - 작업 디렉터리의 .env 파일, ~/.aws/credentials, ~/.ssh 등 자격증명이 위치하는 알려진 경로를 훑어 토큰, 키, 시크릿을 긁어모읍니다.
외부 전송(Exfiltration) - 수집한 데이터를 인코딩해 공격자가 통제하는 C2 서버로 전송합니다. 보통 한 번의 단발성 요청으로 끝나 흔적을 최소화합니다.
흔적 은폐 - 함께 들어있던 package.md(깨끗한 4.2.0용 package.json 사본)로 자신의 package.json을 덮어써, 사후 점검 시 정상 패키지처럼 보이도록 위장합니다.

여기서 무서운 점은, 이 모든 과정이 개발자가 코드를 단 한 줄도 실행하기 전에, 그저 npm install 한 번으로 백그라운드에서 모든 공격을 끝냈다는 점입니다.

그래서 인프랩은 어떻게 대비하였나요?

앞서 사례로 언급드린 Axios의 경우, Axios에 주입된 악성 간접 의존성 plain-crypto-js@4.2.1은 게시 6분 만에 자동 분석 시스템에 탐지 되었습니다. 또한 주요 공급망 공격 10건을 분석한 결과, 이중 8건의 사례가 악성 버전이 배포된 뒤 발견되어 제거되기까지 1주일채 걸리지 않았다고 보고되었습니다.

결국 저희가 세운 방어 전략은 다음 두 가지로 모아집니다.

Cool-Down 적용 - 갓 게시된 버전이 곧바로 설치되지 않도록 지연시켜, 그 사이에 보안 커뮤니티의 탐지 및 신고가 이루어지도록 합니다.
설치 시점 임의 코드 실행 차단 - Cool-Down 기간이 지나 악성 버전이 설치되더라도, postinstall 같은 lifecycle scripts가 자동 실행되지 못하게 막습니다.

이 두 전략은 pnpm 10부터 공식 설정으로 지원되기 시작했습니다. 저희 팀에서도 Axios 사건 직후 Cool-Down 도입에 대한 논의가 빠르게 이루어졌습니다.

동료의 쿨다운 제안.

패키지 매니저 통합: pnpm으로의 마이그레이션

당시 인프랩 Node.js 백엔드 저장소들은 어떤 곳은 pnpm을, 어떤 곳은 yarn을 사용하는 식으로 패키지 매니저가 통일된 상태는 아니었습니다. 패키지 매니저마다 보안 설정 방식이 다르기 때문에, 이런 상태에서는 앞서 이야기한 전략을 모든 저장소에 똑같이 적용하기 어려웠습니다. 그래서 보안 설정을 일관되게 적용하려면 패키지 매니저부터 하나로 맞출 필요가 있었고, 저희는 이번 기회에 모든 저장소를 pnpm으로 통합하기로 결정하였습니다. 위 사유와 더불어 아래와 같은 배경들 덕분에 패키지 매니저 통합 결정을 빠르게 할 수 있었습니다.

레거시 코드가 존재하는 일부 저장소를 제외하면, 대부분의 저장소가 이미 pnpm을 사용 중이었습니다.
논의를 진행하는 동안 pnpm 11 버전이 릴리스되었고, 이 버전에서는 10 버전에서 도입된 보안 설정들이 기본값으로 더욱 엄격하게 적용되었습니다.
pnpm 11은 Node.js 22 버전부터 지원하는데, 이미 일부 서비스에서 Node.js 22를 운영 환경에 적용하여 안정성이 어느 정도 검증된 상태였습니다.

pnpm 11의 보안 강화 기능

pnpm 11에서는 공급망 공격에 대비할 수 있는 보안 설정들이 기본으로 활성화됩니다. 커뮤니티에서 추천하는 설정과 각 옵션의 역할을 소개합니다.

# pnpm-workspace.yaml
minimumReleaseAge: 1440
minimumReleaseAgeStrict: true
blockExoticSubdeps: true
strictDepBuilds: true
dangerouslyAllowAllBuilds: false
trustPolicy: no-downgrade

# CI에서는 install이 암묵적으로 돌기보다 실패하게 하고 싶다면:
verifyDepsBeforeRun: error

minimumReleaseAge

항목	값
기본값	`1440` (pnpm 11부터, 이전 버전은 `0`)
설정값	분 단위 숫자

레지스트리에 게시된 지 지정된 시간(분)이 지나지 않은 버전은 설치 대상에서 제외합니다. 1440은 24시간을 의미합니다. ^1.14.0 같은 캐럿 범위로 선언된 의존성이라 하더라도, 게시된 지 24시간이 지나지 않은 버전은 설치되지 않습니다. Axios 사례처럼 악성 버전이 게시 후 6분 만에 탐지된다면, 24시간의 Cool-Down은 탐지와 대응에 넉넉한 시간을 확보해 줍니다.

minimumReleaseAgeStrict

항목	값
기본값	`true` (minimumReleaseAge를 명시적으로 설정한 경우), `false` (그 외)
설정값	`true` / `false`

Cool-Down 조건을 만족하는 버전이 하나도 없을 때의 동작을 결정합니다.

true: 설치를 실패 시킵니다. 안전하지 않은 버전이 조용히 설치되는 것보다 설치가 실패하는 편이 안전하므로, true로 두는 것이 권장됩니다.
false: 경고를 출력하되, 조건을 만족하지 않는 버전으로 폴백하여 설치를 진행합니다.

strictDepBuilds

항목	값
기본값	`true` (pnpm 11부터)
설정값	`true` / `false`

의존성 패키지에 빌드 스크립트(preinstall, install, postinstall)가 포함되어 있는데 아직 허용 목록에 등록되지 않은 경우, 설치를 비정상 종료(non-zero exit) 시킵니다. Axios 사례에서 plain-crypto-js가 postinstall로 악성 코드를 실행했던 것과 같은 공격을 원천 차단할 수 있습니다.

allowBuilds

항목	값
기본값	빈 목록 (아무 패키지도 빌드 스크립트를 실행하지 못함)
설정값	`패키지명: true` 형태의 목록

strictDepBuilds가 모든 빌드 스크립트를 막아버리기 때문에, 빌드 스크립트가 정상적인 동작에 꼭 필요한 패키지까지 함께 차단되는 문제가 생깁니다. 예를 들어 esbuild, sharp처럼 네이티브 바이너리를 직접 컴파일하는 패키지는 postinstall로 바이너리를 받거나 빌드해야 정상 동작합니다. 이런 패키지를 allowBuilds에 등록하면, 해당 패키지에 한해 빌드 스크립트 실행을 명시적으로 허용할 수 있습니다.

# pnpm-workspace.yaml
allowBuilds:
  esbuild: true
  sharp: true

즉, strictDepBuilds가 기본적으로 모든 문을 잠그는 설정이라면, allowBuilds는 신뢰할 수 있는 패키지에만 열쇠를 내어주는 화이트리스트 역할을 합니다.

다만 주의할 점이 있습니다.

패키지를 등록한다는 것은 곧 그 패키지의 빌드 스크립트가 임의 코드를 실행하도록 허용한다는 의미입니다. 등록 전에 정말 빌드 스크립트가 필요한 패키지인지, 신뢰할 수 있는 출처인지 반드시 확인해야 합니다.
설치가 실패한다고 해서 습관적으로 목록에 추가하지 말고, 목록은 최소한으로 유지하는 것이 좋습니다. 허용 항목이 늘어날수록 그만큼 공격 표면도 함께 넓어집니다.
번거롭다는 이유로 뒤에 설명할 dangerouslyAllowAllBuilds: true로 한 번에 열어버리면 strictDepBuilds의 의미가 사라지므로, 반드시 allowBuilds로 패키지를 하나씩 허용하는 방식을 권장합니다.

dangerouslyAllowAllBuilds

항목	값
기본값	`false`
설정값	`true` / `false`

이름에 dangerously가 붙어 있는 것에서 알 수 있듯이, 이 옵션을 true로 설정하면 모든 의존성의 빌드 스크립트를 무조건 허용합니다. strictDepBuilds를 무력화하므로, 반드시 false로 유지해야 합니다.

blockExoticSubdeps

항목	값
기본값	`true` (pnpm 11부터)
설정값	`true` / `false`

간접 의존성(transitive dependency)이 npm 레지스트리가 아닌 이질적인(exotic) 소스(Git URL, HTTP tarball 등)에서 설치되는 것을 차단합니다. 직접 의존성은 개발자가 의도적으로 선언한 것이므로 허용하되, 하위 의존성 트리에서 예상치 못한 외부 소스로 우회하는 공격을 방지합니다.

trustPolicy

항목	값
기본값	미설정 (비활성)
설정값	`no-downgrade` / `off`

no-downgrade로 설정하면, 이전 버전 대비 패키지의 신뢰 수준이 하락한 경우 설치를 실패시킵니다.

npm 패키지의 신뢰 수준은 게시 방식에 따라 크게 세 단계로 나뉩니다. 위에서 아래로 갈수록 신뢰 수준이 낮아집니다.

신뢰 수준	게시 방식	검증 범위
Trusted Publisher	GitHub Actions 등 CI/CD에서 자동 게시	게시자 신원과 빌드 출처를 모두 검증
Provenance	서명·attestation은 있으나 Trusted Publisher는 아님	빌드 출처는 검증되나 게시자 신원은 미검증
None	npm CLI로 수동 게시	아무런 증명 없음, 누가 어디서 빌드했는지 알 수 없음

trustPolicy: no-downgrade는 신뢰 수준이 유지되거나 높아지는 변경은 허용하고, 낮아지는 방향의 변경만 차단합니다. 예를 들어 axios@1.14.0에서 axios@1.14.1로 올라갈 때, 신뢰 수준 변화에 따라 다음과 같이 동작합니다.

변경 전 → 변경 후	신뢰 수준	설치
Trusted Publisher → Trusted Publisher	유지	허용
Provenance → Trusted Publisher	상승	허용
None → Provenance	상승	허용
Trusted Publisher → Provenance	하락	차단
Trusted Publisher → None	하락 (Axios 공격 사례)	차단
Provenance → None	하락	차단

Axios 공격 사례에서 공격자는 탈취한 계정 토큰으로 npm CLI를 통해 수동 배포했습니다. 기존 Axios는 Trusted Publisher로 게시되고 있었으므로, 신뢰 수준이 Trusted Publisher → None으로 급락하게 됩니다. trustPolicy: no-downgrade가 설정되어 있었다면, 이 시점에서 설치가 차단되어 공격을 사전에 막을 수 있었습니다.

verifyDepsBeforeRun

항목	값
기본값	`install`
설정값	`install` / `warn` / `error` / `prompt` / `false`

pnpm run이나 pnpm exec를 실행하기 전에 의존성 상태를 검증합니다. CI 환경에서 의존성이 불완전한 상태로 스크립트가 실행되는 것을 막으려면 error로 두는 것이 권장됩니다.

install: 의존성이 불완전하면 자동으로 pnpm install을 실행합니다.
warn: 경고만 출력하고 계속 진행합니다.
error: 의존성이 불완전하면 실행을 중단합니다.
prompt: 사용자에게 설치 여부를 대화형으로 묻습니다.
false: 검증을 하지 않습니다.

이처럼 pnpm 11은 대부분의 보안 설정이 기본값만으로도 강력하게 보호를 할 수 있습니다. 악성 버전의 게시 자체를 막을 수는 없지만, 라이브러리를 소비하는 입장에서 즉시 자동 전파되는 구조를 “지연”으로 전환하여, 그 사이에 보안 커뮤니티의 탐지와 신고가 이루어지도록 시간을 벌 수 있습니다.

패키지 매니저 마이그레이션 팁

이미 pnpm을 쓰고 있다면 (버전 업데이트)

앞서 소개한 보안 설정들은 pnpm 11 기준입니다. 그렇다면 이미 구버전 pnpm을 사용하고 있는 저장소는 어떻게 11까지 올려야 할까요?

여기서 한 가지 유의할 점이 있습니다. pnpm의 마이그레이션 가이드는 메이저 버전을 한 단계씩 올릴 때를 기준으로 제공됩니다. 예를 들어 8 → 9, 9 → 10, 10 → 11처럼 각 단계별로 변경된 동작과 마이그레이션 방법이 문서화되어 있습니다.

따라서 pnpm 8에서 11로 곧장 점프하기보다는, 한 메이저 버전씩 차근차근 올리는 방식을 권장합니다.

각 단계마다 어떤 동작이 바뀌었는지 공식 마이그레이션 가이드로 확인할 수 있습니다.
한 번에 여러 버전을 건너뛰면, 어느 단계에서 문제가 생겼는지 원인을 추적하기 어렵습니다.
단계별로 올리면 pnpm install과 테스트를 거치며 변경 사항을 점진적으로 검증할 수 있어, 잠금 파일(pnpm-lock.yaml)이나 의존성 해석 방식의 차이로 인한 문제를 조기에 발견할 수 있습니다.

저희도 혼용하던 패키지 매니저를 pnpm으로 통합하고 11까지 올리는 과정에서, 단계별 업데이트가 디버깅 부담을 크게 줄여준다는 것을 체감할 수 있었습니다.

다른 패키지 매니저(npm, yarn)를 쓰고 있다면

한편 아직 yarn이나 npm을 쓰고 있어 pnpm으로 처음 넘어와야 하는 저장소라면, pnpm import 명령으로 기존 yarn.lock이나 package-lock.json을 기반으로 pnpm-lock.yaml을 생성할 수 있습니다. 의존성 버전을 처음부터 다시 해석하지 않고 기존 잠금 상태를 그대로 가져올 수 있어, 마이그레이션 초기의 버전 변동을 줄이는 데 도움이 됩니다.

마무리

이번 글에서 다룬 공격 경로는 postinstall 스크립트를 악용한 설치 시점 공격이었습니다. 하지만 이 경로만 차단한다고 해서 공급망 공격을 완벽하게 막을 수 있는 것은 아닙니다. 설치 스크립트에 대한 방어가 강화될수록, 공격자들은 다음 공격 지점으로 옮겨갈 가능성이 큽니다.

일종의 두더지 잡기와 같습니다. 설치 스크립트 차단과 Cool-Down은 가장 흔한 설치 시점 공격을 효과적으로 줄여주지만, import 시점이나 런타임에서 실행되는 악성 코드에는 무력합니다. 예를 들어 패키지의 정상적인 모듈 코드 내부에 난독화된 악성 로직을 삽입하는 방식은 설치 스크립트 차단만으로는 탐지할 수 없습니다.

따라서 설치 시점 방어는 개발자들이 지켜내야할 최소한의 기본 방어선이며, 앞으로는 더 다양한 방어 체계를 고려해야 합니다.

긴 글 읽어주셔서 감사합니다.

테크회사 어썸블로그

AI 에이전트로 카카오톡 추천 지표 분석 자동화하기

Vibe Coding하는 비개발자는 개발자인가(3)

ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온

스펙만 바꾸면 프롬프트가 따라옵니다 - 답변 생성 모델 자동화 파이프라인

발표 내용

발표 대상

목차

◎ NAVER Engineering Day란?

도구에서 동료로 — AI 에이전트 자율 성장 프레임워크

발표 내용

발표 대상

목차

◎ NAVER Engineering Day란?

SaaS 대체하기: AI와 함께한 광고SDK 에러 모니터링 시스템 구축기

발표 내용

발표 대상

목차

◎ NAVER Engineering Day란?

AI 에이전트를 위한 Playwright E2E 테스트 하네스 구축하기

발표 내용

발표 대상

목차

◎ NAVER Engineering Day란?

MLXP : Kubernetes LLM Serving 최적화 기술 도입기

발표 내용

발표 대상

목차

◎ NAVER Engineering Day란?

비개발자의 AI 협업 도전기 — 생산성 측정하려다 서버까지 띄운 9일

사내 생산성 측정에 관한 고민

1단계: HTML 파일 하나로 가설 검증

2단계: DORA 지표를 통한 기준 마련

3단계: AI를 활용한 서버 구축과 가이드 문서

4단계: 스케줄러 설정과 데이터 누락 문제 해결

5단계: 사내 스토리지 연동과 사람의 역할

완성된 대시보드의 효과

프로젝트를 진행하며 배운 점

기획의 재발견: AI는 마법사가 아니라 정밀한 조각가다

인프라의 벽: 가이드와 AI, 둘 다 필요했다

토큰의 무게: AI는 공짜가 아니다

AI의 한계: 오류가 없다고 올바른 것은 아니다

생태계의 제언: '데이터 민주주의'를 위한 조건

마치며

LLM·하네스로 더 좋은 n8n 워크플로 생성하기

AI 시대의 브랜드 그래픽 시스템 구축기

여기어때 트립홀릭 그래픽 언어 리뉴얼 프로젝트

왜 그래픽이 필요했을까?

말풍선에서 시작된 그래픽

하나의 브랜드 하나의 그래픽언어

AI 시대의 그래픽 에셋

에셋을 넘어 비주얼 시스템으로

에셋을 넘어 비주얼 시스템으로

90일 동안 내 편이 생겼다! 짝꿍 제도

여기어때 컬처 라운지 ep. 19

🤝 ‘짝꿍’이라는 든든한 존재

📋 꼼꼼한 ‘짝꿍 가이드북’

💡 실제 짝꿍들은 어떤 도움을 주고 있을까요?

☕ 어색함이 사르르, ‘짝꿍 티타임 쿠폰’

에이전틱 리소스 디스커버리 규격 발표 등 6월 셋째 주 Google for Developers 위클리 업데이트를 지금 확인하세요!

Gemini 3.5 라이브 번역 출시 등 6월 둘째 주 Google for Developers 위클리 업데이트를 지금 확인하세요!

화이트햇 해커 취업, 어떤 직종이 있을까? - 사이버 보안 6개 직종 정리

디자이너에게 AI로 뭐든 만들어보라고 한다면

반복되는 일을 AI에 넘기다

나를 복제해 협업 비용을 줄이다

말 대신 동작하는 걸로 설득하다

짧은 시간에 퀄리티를 끝까지 밀어붙이다

적용해 보기

Spark Connect on Kubernetes #1: 견고한 Spark Connect 만들기

Spark는 원래 어떻게 동작하나요

Spark Connect는 무엇이 다른가요

그래서 좋은 점

Spark Connect 서버가 만드는 문제들

문제 ①, Driver = 단일 장애점

문제 ②, 리소스 경합과 Task Scheduling 한계

문제 ③, 고정된 스케일

그래서, 어떻게 풀었나

공유 Driver의 SPOF를 어떻게 극복했나

먼저, 죽는 일 자체부터 줄이기

하나의 Spark Connect 서버를 여러 replica로