토스

개발자는 AI에게 대체될 것인가 (새 탭에서 열림)

현재의 AI 열풍은 막대한 자본이 투입된 버블의 성격을 띠고 있지만, 장기적으로는 개발자의 업무를 근본적으로 재정의하는 도구로 자리 잡을 것입니다. 개발자는 단순히 코드를 생산하는 역할에서 벗어나, 어떤 업무를 AI에게 '추상화(위임)'하고 어떤 핵심 판단력을 유지할지 결정하는 설계자이자 디렉터의 역량을 요구받게 됩니다. 결국 AI 시대의 생존은 기술적 위임의 경계를 설정하고 시스템의 복잡성을 관리하는 '추상화 능력'에 달려 있습니다. ## AI 하이프와 경제적 불균형의 실체 * **아마라의 법칙과 버블:** 기술의 효과는 단기적으로 과대평가되는 경향이 있으며, 현재 AI 시장은 투자 대비 매출 비율이 16:1(설비투자 5,600억 달러 대비 매출 350억 달러)에 달할 정도로 극심한 불균형 상태입니다. * **실질 수익의 부재:** 생성형 AI 도입 프로젝트의 약 95%가 실패하거나 뚜렷한 효율 개선을 보이지 못하고 있으며, 빅테크의 매출조차 상당 부분 내부 거래에 의존하고 있는 실정입니다. * **인력 감축의 역설:** 현재의 개발자 감원은 AI가 업무를 대체했기 때문이라기보다, 막대한 AI 투자 비용을 충당하기 위한 기업의 비용 절감 전략에서 기인한 측면이 큽니다. ## 제번스 패러독스와 직무의 재정의 * **수요의 폭발:** 에어컨 보급률이 높아질수록 관련 산업이 커지듯, AI로 코딩의 문턱이 낮아지면 소프트웨어에 대한 전체 수요와 활용처는 오히려 기하급수적으로 늘어날 것입니다. * **도구로서의 AI:** 과거 게임 엔진이 소규모 팀에게 프로급 역량을 부여했듯, AI는 개발자를 보조하는 강력한 '파워 툴'이 되어 상위 실력자의 생산성을 극대화합니다. * **역할의 변화:** 개발자의 정체성은 코드 작성자에서 '코드 크리에이티브 디렉터'로 변모하며, 시스템 설계, 에이전트 지휘, 결과물 검증이 업무의 중심이 됩니다. ## 위임의 사분면과 추상화의 본질 * **위임의 기준:** '위임하기 쉬운가(기술적 난이도)'는 모델의 발전에 따라 계속 변하는 일시적인 경계일 뿐이며, 중요한 것은 '위임해야 하는가(책임과 판단)'라는 가치 판단의 축입니다. * **추상화로서의 위임:** AI에게 업무를 맡기는 것은 프로그래밍의 '추상화'와 같습니다. 이는 세부 사항을 숨기고 더 이상 신경 쓰지 않겠다는 선언이며, 복잡성을 미래로 이동시키는 레버리지 역할을 합니다. * **유형별 위임 전략:** 단순 CRUD나 보일러플레이트 코드, 테스트 케이스 등 잘 정의된 문제는 AI에게 맡기되, 아키텍처 결정이나 보안 정책, 법규 대응처럼 인간의 판단이 필수적인 영역은 분리해야 합니다. ## 잘못된 추상화와 미래의 리스크 * **추상화의 붕괴:** 트래픽 급증, 법률 개정(GDPR 등), 제로데이 보안 취약점 같은 예외 상황이 발생하면 AI에게 위임했던 '추상화된 업무'가 한꺼번에 무너질 수 있습니다. * **시니어의 역할:** 시스템의 근본이 흔들릴 때 이를 해결할 수 있는 능력은 결국 풍부한 경험을 가진 시니어 개발자의 몫이며, AI 결과물을 맹목적으로 수용할 경우 추상화가 없는 것보다 더 큰 재앙을 초래할 수 있습니다. * **지속 가능한 리팩토링:** 개발자는 AI에게 어떤 컨텍스트를 제공하고 어떤 부분을 직접 통제할지 업무 프로세스를 끊임없이 리팩토링하며 '좋은 추상화'를 구축해야 합니다. 성공적인 AI 활용을 위해서는 AI를 단순한 대체재가 아닌, 복잡성을 관리하는 추상화 도구로 바라봐야 합니다. 기술 발전 속도에 일희일비하기보다, 기술이 해결할 수 없는 '비즈니스 임팩트'와 '시스템의 안정성'에 대한 인간의 판단력을 고도화하는 것이 AI 시대 개발자의 핵심 경쟁력이 될 것입니다.

레거시 인프라 작살내고 하이브리드 클라우드 만든 썰 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 인프라의 비효율성을 극복하기 위해 오픈소스 기반의 OpenStack 프라이빗 클라우드를 직접 구축하고, 이를 퍼블릭 클라우드와 결합한 'Active-Active 하이브리드 클라우드' 환경을 구현했습니다. 단 2명의 엔지니어가 운영 경험 없이 시작했음에도 불구하고 자동화와 고가용성 전략을 통해 인프라 제어권을 100% 확보했으며, 결과적으로 어떤 환경에서도 즉시 배포 가능한 유연한 기술 기반을 마련했습니다. ### 1,997개의 라우팅이 보여주는 레거시 인프라의 한계 * 과거 인수한 인프라는 네트워크 장비가 아닌 개별 서버가 직접 라우팅 정보를 관리하는 비정상적인 구조로, 서버당 약 2,000개의 라우팅 경로가 설정되어 있었습니다. * 새로운 경로 추가 시 모든 서버를 일일이 수정해야 하는 관리 포인트의 과부하가 발생했으며, 이는 서비스 확장의 심각한 병목 현상이 되었습니다. * 초기에는 퍼블릭 클라우드 도입으로 대응했으나 비용 증가, 환율 변동, 하이브리드 DR 구성의 어려움 및 가시성 부족이라는 새로운 문제에 직면했습니다. ### OpenStack 기반 프라이빗 클라우드 내재화 * 상용 솔루션 대신 오픈소스인 OpenStack을 선택하여 기술 내재화와 유연한 인스턴스 타입(VM, Container, K8S) 대응력을 확보했습니다. * 부족한 운영 경험을 극복하기 위해 3가지 버전의 OpenStack을 수십 번 설치하고 장애 시나리오를 반복 재현하며 아키텍처 이해도를 높였습니다. * 로드밸런서인 옥타비아(Octavia)의 소스 코드를 직접 수정하여 비즈니스 요구에 맞는 로그 포맷을 생성하는 등 오픈소스의 이점을 극대화했습니다. ### 자동화와 모니터링을 통한 운영 효율 극대화 * Ansible과 Terraform 코드를 활용해 모든 자원의 라이프사이클을 자동화했으며, 골든 이미지를 통해 신규 인스턴스 생성 시간을 10초 이내로 단축했습니다. * Zabbix, Prometheus, Mimir, Grafana 등 다양한 오픈소스 툴을 조합하여 모든 메트릭을 수집하고, 실시간 알람 체계를 구축해 장애 감지 능력을 높였습니다. * 운영 인력의 한계를 극복하기 위해 CMDB와 연동된 봇(Bot)을 구현하여 인프라 현황을 실시간으로 조회하고 관리할 수 있도록 했습니다. ### 고가용성을 위한 다중 클러스터 및 Cluster API 전략 * 장애 발생 시 서비스 가용성을 즉시 확보하기 위해 서로 독립된 3개의 OpenStack 클러스터를 구축하고 평상시 Active-Active로 운영합니다. * 특정 클러스터 장애 시 트래픽을 즉시 차단하는 방식으로 복구 시간을 최소화했으며, 클러스터 간 의존성을 완전히 제거했습니다. * K8S 관리를 위해 Cluster API(CAPI)를 도입하여 쿠버네티스 클러스터 자체를 쿠버네티스 리소스로 관리함으로써 퍼블릭 클라우드 수준의 관리 편의성을 프라이빗 환경에서도 구현했습니다. 전통적인 금융 인프라의 보수성을 탈피하고 오픈소스 기술을 깊이 있게 내재화한다면, 퍼블릭 클라우드의 편리함과 온프레미스의 통제권을 동시에 거머쥘 수 있습니다. 인력 부족이나 기술적 난도는 자동화와 표준화된 도구(CAPI, Terraform 등)를 통해 충분히 극복 가능하므로, 비용 최적화와 기술적 가시성이 필요한 조직이라면 하이브리드 클라우드 전략을 적극 권장합니다.

토스인컴 QA Platform: ‘누구나 테스트할 수 있는’ 도구의 시작 (새 탭에서 열림)

토스 QA 팀은 반복되는 테스트 데이터 생성과 복잡한 API 호출 문제를 해결하기 위해 기존 Swagger API를 GUI 기반으로 추상화한 'QA Platform'을 구축했습니다. 이 도구는 테스트의 진입 장벽을 낮춰 QA뿐만 아니라 모든 팀원이 품질 검증에 참여하게 함으로써 제품 개발 속도를 획기적으로 높이는 결과를 가져왔습니다. 단순히 테스트를 자동화하는 것을 넘어, 품질을 제품 설계 과정의 일환으로 내재화하여 팀 전체가 확신을 가지고 움직일 수 있는 환경을 조성한 것이 핵심입니다. **Swagger 기반의 접근성 개선 (Phase 1)** * Swagger에 흩어져 있는 테스트 API들을 한곳에 모으고, 복잡한 JSON 작성 없이 버튼 클릭만으로 실행할 수 있는 GUI를 도입했습니다. * 사용자의 숙련도에 따라 입력 방식을 이원화했습니다. 'Normal 모드'는 복잡한 필드를 숨겨 누구나 쉽게 쓰게 했고, 'Swagger 모드'는 QA 매니저나 엔지니어가 세부적인 파라미터를 제어할 수 있도록 설계했습니다. * 환경 스위칭, 최근 실행 값 저장, API 응답 값의 자동 복사 기능 등 사소하지만 빈번한 번거로움을 줄여주는 UX 요소를 배치해 심리적 장벽을 낮췄습니다. **자동화의 대중화와 통합 관리 (Phase 2 & 3)** * QA 팀 내부에서만 활용되던 기존의 자동화 스크립트를 플랫폼 내 컨트롤러로 이식하여, 개발자나 기획자도 버튼 하나로 자동화 테스트를 수행할 수 있게 했습니다. * 복잡한 환경 설정이나 스크립트 실행 지식 없이도 자동화 자산을 활용할 수 있게 되어, 검증의 주체가 QA 팀에서 제품 팀 전체로 확장되었습니다. * 외부 도구에 의존하는 대신 조직의 고유한 테스트 방식에 최적화된 통합 관리 시스템을 구축하여, 테스트 설계부터 실행 및 관리까지의 전 과정을 하나로 연결하고 있습니다. **품질 검증에서 품질 설계로의 관점 전환** * 테스트가 '시간을 내서 해야 하는 특별한 작업'이 아니라 '생각나면 바로 하는 일상'이 되면서, 제품의 병목 현상이 제거되고 의사결정 속도가 빨라졌습니다. * 개발자가 기능을 완성하자마자 직접 검증할 수 있는 환경이 마련됨에 따라, 품질은 마지막 단계의 체크리스트가 아닌 개발 흐름 속에 자연스럽게 녹아드는 요소가 되었습니다. * QA 팀은 단순 반복적인 테스트 데이터 세팅 작업에서 벗어나, 더 고도화된 비즈니스 로직 분석과 리스크 관리에 집중할 수 있는 환경을 확보했습니다. 테스트가 쉬워지면 제품의 속도는 자연스럽게 빨라집니다. 기술적인 고도화만큼이나 중요한 것은 "누가 하느냐"에 갇혀 있던 테스트 권한을 "누구나 할 수 있는 구조"로 만드는 것이며, 이를 통해 팀 전체가 품질에 대한 공동의 책임과 확신을 갖는 것이 실질적인 제품 경쟁력으로 이어집니다.

토스의 새로운 얼굴 만들기 (새 탭에서 열림)

토스는 서비스의 인상과 신뢰감을 효과적으로 전달하기 위해 기존의 인물 그래픽을 고도화했습니다. 기존의 귀엽고 어린 이미지를 탈피하여 똑똑하고 믿음직한 '토스다운' 인상을 구축하고, 글로벌 확장에 발맞춰 다인종·다문화 환경을 포용할 수 있는 보편적인 디자인 체계를 마련하는 데 집중했습니다. 이를 통해 어떤 화면에서도 완성도를 유지하며 사용자에게 친근하면서도 전문적인 가치를 전달하는 새로운 페르소나를 완성했습니다. **토스다운 신뢰감을 주는 인물 비율 조정** - 기존 그래픽은 얼굴의 세로 비율이 짧아 다소 어려 보이고 신뢰감이 부족하다는 피드백이 있었습니다. - 얼굴 형태를 크게 바꾸어 이질감을 주는 대신, 눈·코·입의 배치와 표현을 미세하게 조정하여 지적이고 성숙한 인상의 균형점을 찾았습니다. - 도형을 단순히 이어 붙인 구조에서 탈피하여 목과 어깨의 곡선을 다듬고 입체감을 더해 조형적 완성도를 높였습니다. - 단정하고 전문적인 분위기를 자아낼 수 있도록 과한 디테일이 배제된 짧은 목폴라 형태의 의상을 기본 착장으로 설정했습니다. **성별과 인종의 경계를 허무는 중립적 디자인** - 특정 성별로 치우치지 않는 중성적인 헤어 스타일을 개발하여 성별 중립적인 인상을 구현했습니다. - 헤어의 부피감을 보완하고 라인을 정돈하여 화면 크기가 커지더라도 그래픽의 밀도가 떨어져 보이지 않도록 개선했습니다. - 단일한 스킨톤에서 벗어나 이모지의 표준을 참고한 다섯 가지 스킨톤 체계를 정의함으로써 다양성을 수용했습니다. - 여러 인물이 등장하는 화면에서는 다양한 스킨톤을 섞어 배치할 수 있도록 가이드를 마련하여 유니버설 디자인의 가치를 투영했습니다. **글로벌 확장을 고려한 포용적 그래픽 시스템** - 한국 중심의 서비스에서 글로벌 시장으로 확장함에 따라 특정 문화권에 국한되지 않는 보편적인 얼굴이 필요해졌습니다. - 노란색과 같은 추상적인 중립 컬러 대신 실제 인종의 다양성을 반영한 컬러 시스템을 선택하여 사용자들의 공감을 유도했습니다. - 디자인 개선 후 실제 앱 적용 시 주변 인터페이스 요소들과 자연스럽게 어우러지며 브랜드의 지향점을 명확히 드러내고 있습니다. 이러한 개편은 단순한 시각적 변화를 넘어 토스가 지향하는 포용성과 신뢰라는 브랜드 가치를 사용자에게 더 가깝게 전달하는 역할을 합니다. 향후에도 인종, 성별, 연령에 관계없이 누구나 자신을 투영할 수 있는 중립적이고 포용적인 그래픽 시스템을 지속적으로 확장해 나갈 것으로 기대됩니다.

수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기 (새 탭에서 열림)

토스페이먼츠는 수천 개의 API 서버와 배치 설정을 관리하기 위해 설정을 단순한 텍스트가 아닌 '진화하는 코드'로 정의하여 운영합니다. 복사-붙여넣기식의 중복 설정을 제거하기 위해 오버레이 아키텍처와 템플릿 패턴을 도입했으며, 이를 통해 오타나 설정 오류로 인한 대규모 정산 장애 리스크를 원천 차단합니다. 결과적으로 인프라 설정을 테스트 가능한 영역으로 끌어올려 대규모 하이브리드 클라우드 환경에서도 높은 안정성과 유연성을 확보했습니다. ### 실시간 API 서버: 오버레이와 템플릿의 결합 * **오버레이 아키텍처:** 설정을 `global`, `cluster`, `phase`, `application` 순서의 계층형 구조로 설계하여 하위 계층이 상위 계층의 기본값을 덮어쓰도록 구성했습니다. 이를 통해 공통 설정은 한 번만 정의하고 각 환경에 필요한 차이점만 관리할 수 있습니다. * **템플릿 패턴 도입:** YAML의 단순 오버레이만으로는 해결하기 어려운 긴 문자열(예: JVM 옵션) 내의 특정 값만 수정하기 위해 `{{MAX_HEAP}}`과 같은 변수 치환 방식을 사용합니다. * **동적 설정 주입:** 설정 파일 내부에 파이썬 스크립트를 삽입하여 랜덤 포트 생성이나 외부 API 호출을 통한 동적 값 할당이 가능하며, 클러스터 이름에 따른 조건부 로직을 적용해 복잡한 환경 변수 요구사항을 해결합니다. ### 배치 서버: DSL과 GitOps를 통한 단순화 * **Jenkins 기반의 단순화:** 대규모 정산 데이터를 다루는 배치 환경일수록 단순함이 강력하다는 원칙 아래, Jenkins를 활용하면서도 수동 조작의 단점을 보완하는 방향을 택했습니다. * **Groovy DSL 활용:** Jenkins의 웹 UI를 통한 수동 설정을 배제하고, Groovy 기반의 자체 DSL(Domain Specific Language)을 구축하여 수천 개의 배치 Job을 코드 형태로 관리합니다. * **GitOps 체계:** 모든 배치 설정을 코드 저장소에서 관리하고 CI/CD 파이프라인과 통합함으로써, 개발자가 직접 Jenkins에 접속하지 않고도 표준화된 환경에서 배치 작업을 배포할 수 있도록 개선했습니다. ### 인프라의 코드화와 검증 자동화 * **테스트 가능한 설정:** 설정값에 대한 오타나 논리적 오류를 방지하기 위해 설정 코드에 대한 유닛 테스트를 수행합니다. 이를 통해 수천 개의 설정 중 단 하나의 오타가 치명적인 금융 장애로 이어지는 것을 사전에 방지합니다. * **유연한 확장성:** 고정된 설정 체계에 안주하지 않고, 인프라의 변화와 개발자의 요구사항에 맞춰 설정 인프라 자체가 계속해서 진화할 수 있는 구조를 지향합니다. 단순히 설정 파일을 잘 작성하는 것에 그치지 않고, 인프라 설정을 애플리케이션 코드와 동일한 수준의 설계와 테스트를 거쳐 관리하는 것이 대규모 시스템의 안정성을 보장하는 핵심입니다. 초기에 다소 복잡해 보일 수 있는 오버레이나 DSL 도입은 장기적으로 중복을 제거하고 휴먼 에러를 막는 가장 확실한 투자입니다.

디자인 시스템 다시 생각해보기 (새 탭에서 열림)

디자인 시스템은 성장에 따라 경직되기 마련이며, 시스템이 제품 팀의 변화하는 요구사항을 제때 수용하지 못할 경우 팀은 시스템을 우회하거나 파편화된 코드를 생성하게 됩니다. 토스의 디자인 시스템(TDS)은 디자인 시스템을 통제 수단이 아닌 '하나의 제품'으로 정의하고, 수요자의 니즈에 따라 유연하게 대응할 수 있는 설계 구조를 지향합니다. 이를 위해 단순함과 유연함을 동시에 잡을 수 있는 하이브리드 API 전략을 도입하여 일관성과 생산성을 모두 확보하는 해결책을 제시합니다. ### 시스템의 경직성과 파편화 문제 * 조직이 커지고 제품이 다양해지면 기존 시스템의 제약 내에서 해결할 수 없는 UI 요구사항이 빈번하게 발생합니다. * 제품 팀은 빠른 해결을 위해 피그마 컴포넌트를 해제(detach)하거나 라이브러리 코드를 복제(fork)하여 로컬에서 수정해 사용하게 됩니다. * 이러한 우회 방식은 시스템 업데이트와의 연결을 끊어버려 UI 불일치를 초래하고, 장기적으로 디자인 시스템의 핵심 가치를 무너뜨립니다. * 결국 디자인 시스템이 팀의 속도를 늦추는 장애물이 되지 않으려면, 강력한 규칙보다 '우회할 이유를 줄이는 유연한 설계'가 필요합니다. ### 확장성을 고려한 컴포넌트 API 패턴 비교 * **Flat 패턴**: 내부 구조를 숨기고 모든 변형을 props로 처리하는 방식입니다. 사용이 직관적이고 간결하지만, 예외적인 요구사항이 늘어날수록 props가 기하급수적으로 증가하여 유지보수가 어려워집니다. * **Compound 패턴**: 하위 컴포넌트(Header, Body, Footer 등)를 제공하여 사용자가 직접 조합하는 방식입니다. 시스템이 예측하지 못한 레이아웃도 유연하게 구현할 수 있으나, 코드량이 늘어나고 구조에 대한 학습 비용이 발생한다는 단점이 있습니다. * 두 패턴은 상충하는 장단점을 가지고 있으므로, 단순히 하나의 패턴을 강요하는 것은 사용자의 이탈을 막기에 부족합니다. ### TDS의 하이브리드 전략과 Primitive 레이어 * TDS는 단순하고 빈번한 케이스를 위한 **Flat API**와 복잡한 커스텀을 위한 **Compound API**를 동시에 제공합니다. * 사용자는 별도의 커스텀이 필요 없을 때는 간결한 Flat 형식을 선택하고, 세밀한 제어가 필요할 때는 Compound 형식을 선택하여 시스템 내부에서 문제를 해결할 수 있습니다. * 디자인 시스템 팀은 관리 효율을 위해 **Primitive(기초 단위)** 레이어를 먼저 구축합니다. * 내부적으로는 동일한 Primitive 컴포넌트를 공유하면서 외부로 드러나는 API만 두 가지 형태로 노출함으로써, 유지보수 부담을 최소화하면서도 사용자 경험을 극대화합니다. 디자인 시스템은 팀을 가두는 울타리가 아니라 안전하게 안내하는 가드레일이 되어야 합니다. 중앙에서 모든 것을 통제하려 하기보다, 규칙에서 벗어난 예외 상황까지 시스템 안에서 지원할 수 있는 유연한 설계를 갖출 때 진정한 일관성을 유지할 수 있습니다.

세금 환급 자동화 : AI-driven UI 테스트 자동화 일지 (새 탭에서 열림)

토스인컴의 복잡한 세금 환급 서비스 QA를 위해 1명의 매니저가 AI를 팀원으로 활용하여 4~5명 규모의 자동화 성과를 낸 과정을 다룹니다. AI 에이전트에게 코드 작성과 설계를 맡기고 사람은 문제 정의와 검증에 집중함으로써, 5개월 만에 35개의 고난도 E2E 테스트 시나리오를 성공적으로 구축하고 운영화했습니다. 이 실험은 기술적 난도가 높은 환경에서도 AI와의 협업을 통해 자동화 효율을 극대화할 수 있음을 입증했습니다. **AI 자동화 도입 배경과 도구 구성** * 복잡한 환급 플로우(15~20단계)와 빈번한 UI/정책 변경, 외부 연동 시스템의 불안정성 때문에 전통적인 수동 자동화 방식으로는 대응이 불가능했습니다. * 메인 개발자인 Claude Sonnet 4.5를 비롯해 Cursor(IDE 페어 프로그래밍), Codex(코드 분석) 등 각기 다른 강점을 가진 AI 도구들을 조합하여 사용했습니다. * AI를 SDET 에이전트(설계), 문서화 전문가(기록), Git 마스터(형상 관리)라는 세 가지 페르소나로 분리하여 역할 분담을 명확히 했습니다. **기술적 문제 해결과 아키텍처 고도화** * **Page Object Model(POM) 도입:** 중복 셀렉터 문제를 해결하고 유지보수성을 높이기 위해 AI와 협업하여 모든 페이지 요소를 객체화하는 POM 구조를 설계했습니다. * **React 타이밍 이슈 해결:** 요소가 화면에는 보이지만 이벤트 핸들러가 바인딩되지 않아 발생하는 클릭 실패를 해결하기 위해, UI 안정화와 상호작용 준비 상태를 분리해 감지하는 'Interaction Readiness' 전략을 구현했습니다. * **Fallback 클릭 로직:** 표준 클릭 실패 시 키보드 엔터 입력, 자바스크립트 직접 클릭 순으로 시도하는 안전한 클릭 함수를 만들어 테스트의 견고함을 높였습니다. * **동적 약관 처리:** 서비스별로 상이하고 복잡한 약관 동의 플로우를 AI가 자동으로 감지하고 처리하도록 설계하여, 약관이 변경되어도 테스트가 중단되지 않는 구조를 만들었습니다. **운영 효율화를 위한 협업 시스템 구축** * **문서화 및 일지 자동 생성:** 매일 커밋 기록을 기반으로 AI가 회고 일지와 가이드 문서를 작성하게 하여, 수십 분이 걸리던 기록 업무를 1~2분 내외의 검토 수준으로 단축했습니다. * **메신저 기반 리포팅 루프:** 테스트 결과, 실패 지점 스크린샷, 오류 로그(EventID 등)를 사내 메신저에 자동으로 연동하여 개발팀과의 빠른 논의가 가능하도록 환경을 조성했습니다. * **테스트 격리 및 리팩토링:** 수천 줄의 단일 파일을 분리하고 테스트 데이터(userNo) 충돌 방지 로직을 도입하여 자동화 품질을 관리 가능한 수준으로 끌어올렸습니다. 단순히 AI에게 코드를 짜게 하는 수준을 넘어, 아키텍처 설계와 운영 프로세스 전반을 AI와 함께 고민하는 'AI-First' 접근 방식은 리소스가 제한된 환경에서 QA 품질을 혁신적으로 높일 수 있는 실질적인 해법이 됩니다. 6개월간의 여정은 AI를 도구가 아닌 실제 팀원으로 대우할 때 자동화의 본질인 '안정적인 반복 실행'을 달성할 수 있음을 보여줍니다.

LLM을 이용한 서비스 취약점 분석 자동화 #1 (새 탭에서 열림)

토스 보안 연구팀은 구글의 'Project Naptime'에서 영감을 얻어 LLM 기반의 취약점 분석 자동화 시스템을 구축했습니다. 대용량 코드 처리, 결과의 불확실성, 운영 비용 등 실무 적용 과정에서 마주한 네 가지 핵심 기술적 난제를 단계별로 해결하며 최종적으로 95% 이상의 분석 정확도를 달성했습니다. 기술적 가능성을 넘어 실제 수백 개의 서비스에 지속적으로 적용 가능한 수준의 보안 자동화 환경을 마련했다는 점에 의의가 있습니다. **대용량 소스코드 분석을 위한 MCP 도입** * 단순히 소스코드 전체를 LLM에 입력하는 방식은 토큰 한계와 환각(Hallucination) 문제로 인해 대규모 프로젝트 분석에는 부적합했습니다. * 대안으로 RAG(검색 증강 생성)를 시도했으나 코드 간의 복잡한 연관 관계를 파악하는 데 한계가 있었습니다. * 최종적으로 MCP(Model Context Protocol)를 구축하여 LLM 에이전트가 필요할 때마다 함수 정의나 변수 사용처를 도구 호출(Tool Calling) 방식으로 자유롭게 탐색하도록 설계했습니다. **SAST 결합을 통한 분석 일관성 확보** * 동일한 코드에 대해서도 분석 결과가 매번 달라지는 LLM의 비결정성 문제를 해결하기 위해 정적 분석 도구(SAST)를 결합했습니다. * 빌드 과정이 복잡하고 무거운 CodeQL 대신, 가볍고 빠른 오픈소스 도구인 Semgrep을 활용하여 모든 입력 경로(Source)에서 위험 지점(Sink)까지의 경로를 먼저 수집했습니다. * SAST가 추출한 잠재적 취약 경로를 LLM이 집중 분석하게 함으로써 탐지 누락을 방지하고 분석의 신뢰도를 높였습니다. **멀티 에이전트 체계를 통한 비용 최적화** * 모든 코드 경로를 심층 분석할 경우 발생하는 막대한 토큰 비용을 줄이기 위해 역할을 분담한 세 가지 에이전트를 도입했습니다. * **Discovery 에이전트:** 수집된 경로 중 실제 취약점 가능성이 높은 경로를 1차로 선별하는 거름망 역할을 수행합니다. * **Analysis 에이전트:** 선별된 경로를 심층 분석하여 실제 취약 여부를 판별합니다. * **Review 에이전트:** 최종 결과를 검토하여 오탐(False Positive)을 제거함으로써 분석의 정교함을 더했습니다. **지속 가능한 운영을 위한 오픈 모델 전환** * 상용 클라우드 모델(Claude 등)의 높은 비용 문제를 해결하기 위해 직접 호스팅 가능한 오픈 모델(Open Model)로 전환했습니다. * Qwen3:30B, gpt-oss:20B, llama3.1:8B 등 다양한 모델의 ROI를 비교 분석한 결과, 취약점 분석 정확도와 도구 호출 성능이 가장 우수한 'Qwen3:30B'를 최종 선택했습니다. * 오픈 모델의 성능을 보완하기 위해 프롬프트 엔지니어링과 퓨샷 러닝(Few-shot Learning)을 적용하여 클라우드 모델 못지않은 성능을 구현했습니다. 단순히 최신 기술을 도입하는 것에 그치지 않고, 기업 환경에서 실제 운영 가능한 수준의 '비용 대비 성능'을 확보하는 것이 중요합니다. LLM 취약점 분석 시스템을 구축할 때는 모든 판단을 모델에 맡기기보다 Semgrep과 같은 전통적인 보안 도구로 분석 범위를 좁혀주고, 멀티 에이전트 구조로 단계별 필터링을 거치는 설계가 실무적으로 가장 효과적입니다.

AST로 Outdated 없는 퍼널 문서 만들기 (새 탭에서 열림)

토스팀은 복잡한 판매자 입점 퍼널을 효율적으로 관리하기 위해 코드를 정적으로 분석하여 자동으로 업데이트되는 퍼널 문서를 구축했습니다. 기존의 수동 문서는 빈번한 코드 변경을 따라가지 못해 실효성을 잃었으나, `ts-morph`와 AST(Abstract Syntax Tree) 분석을 통해 코드와 100% 일치하는 흐름도를 생성할 수 있게 되었습니다. 이를 통해 개발자는 복잡한 조건부 분기와 페이지 이동 로직을 별도의 문서 작업 없이도 시각적으로 정확하게 파악할 수 있게 되었습니다. **수동 문서화의 한계와 정적 분석의 선택** * **문서의 파편화:** 수기로 작성된 다이어그램은 코드가 수정될 때마다 즉시 업데이트되지 않아 실제 동작과 문서가 불일치하는 'Outdated' 문제가 발생합니다. * **복잡한 분기 처리의 어려움:** 수십 개의 페이지와 80여 개의 조건부 분기를 시각적 도구로 일일이 표현하는 것은 휴먼 에러의 위험이 크고 관리가 불가능합니다. * **정적 분석 채택:** 런타임 분석은 모든 경로를 직접 실행해야 하는 번거로움이 있지만, AST를 활용한 정적 분석은 코드를 텍스트로 읽어 모든 잠재적 경로를 빠르고 안전하게 추출할 수 있습니다. **Navigation Edge 데이터 구조 설계** * **맥락 정보 포함:** 단순한 이동 경로(A → B)를 넘어, 이동 방식(`push` vs `replace`), 실행 조건, 쿼리 파라미터 등의 상세 데이터를 포함하는 `NavigationEdge` 인터페이스를 설계했습니다. * **추적 가능성 확보:** 코드 내 정확한 위치(`lineNumber`)와 호출 출처(`sourceType`)를 저장하여 다이어그램에서 실제 소스 코드로 즉시 연결될 수 있는 기반을 마련했습니다. **AST를 활용한 로직 추출 및 조건문 파싱** * **패턴 감지:** `ts-morph`를 사용하여 프로젝트 내 페이지 파일을 탐색하고, `router.push()` 또는 `router.replace()`와 같은 함수 호출 패턴을 감지합니다. * **상위 노드 추적:** 특정 이동 로직이 발견되면 AST의 부모 방향으로 거슬러 올라가 가장 가까운 `if`문이나 삼항 연산자의 텍스트를 추출함으로써 이동 조건(Condition)을 파악합니다. **커스텀 훅 및 URL 상수의 역추적** * **숨은 로직 탐색:** 페이지 컴포넌트 내부뿐만 아니라, `import` 구문을 분석하여 커스텀 훅 내부에 숨겨진 이동 로직까지 추적하여 데이터 누락을 방지합니다. * **상수 해독:** `URLS.FUNNEL.PAY_METHOD`와 같이 상수로 정의된 목적지를 실제 URL 경로로 변환하기 위해 상수 정의 파일을 별도로 파싱하여 매핑 테이블을 구축했습니다. **실용적인 결론** 복잡도가 높은 서비스일수록 문서와 코드의 동기화는 자동화되어야 합니다. `ts-morph`와 같은 도구를 활용해 소스 코드를 단일 진실 공급원(Single Source of Truth)으로 삼는 자동화 문서를 구축하면, 불필요한 커뮤니케이션 비용을 줄이고 퍼널 전체의 비즈니스 로직을 명확하게 시각화할 수 있습니다.

토스의 AI 기술력, 세계 최고 권위 NeurIPS 2025에서 인정받다: FedLPA 연구 (새 탭에서 열림)

토스는 데이터 주권 문제를 해결하면서도 미지의 데이터를 효과적으로 학습할 수 있는 새로운 연합학습 알고리즘 'FedLPA'를 개발하여 세계 최고 권위의 AI 학회인 NeurIPS 2025에 게재했습니다. 이 기술은 국가별로 상이하고 라벨이 부족한 현실 세계의 데이터 분포를 클라이언트 스스로 파악하여 모델을 최적화함으로써, 개인정보를 보호하는 동시에 글로벌 서비스의 정확도를 획기적으로 높입니다. 이를 통해 토스는 규제 리스크 없는 글로벌 진출과 초개인화된 금융 서비스 제공을 위한 독보적인 기술적 토대를 마련했습니다. ### 연합학습의 도입 배경과 기존 기술의 한계 - **데이터 주권과 보안**: '페이스페이'와 같은 서비스가 해외에 진출할 때, 현지 법령에 따라 생체 데이터를 국외로 반출할 수 없는 문제를 해결하기 위해 데이터를 서버로 모으지 않고 기기 내에서 학습하는 연합학습(Federated Learning)이 필수적입니다. - **데이터 불균형(Non-IID)**: 기존 연합학습은 모든 사용자의 데이터 분포가 유사하다고 가정하지만, 실제로는 국가나 지역별로 얼굴형, 조명, 결제 패턴 등이 판이하게 달라 성능이 저하되는 한계가 있습니다. - **미지 범주 대응 불가**: 서비스 운영 중 발생하는 새로운 인종적 특성이나 신종 부정 결제 패턴(Novel Class)을 기존 기술은 '알고 있는 범주'로만 분류하려다 보니 새로운 변화에 유연하게 대응하지 못했습니다. ### FedLPA의 3단계 혁신 파이프라인 - **신뢰도 기반 로컬 구조 발견(CLSD)**: 단순히 이미지 특징을 비교하는 수준을 넘어, 모델이 확신하는 데이터(High-confidence)의 예측 결과를 활용해 데이터 간의 유사도 그래프를 정교하게 구축하고 정제합니다. - **인포맵 클러스터링(InfoMap)**: 사람이 범주의 개수를 미리 정해주지 않아도, 그래프 내에서 데이터들이 자연스럽게 뭉치는 커뮤니티를 찾아내는 알고리즘을 통해 클라이언트가 스스로 데이터 내의 범주 개수를 파악합니다. - **로컬 사전 확률 정렬(LPA)**: 모델의 예측 결과 분포가 앞서 파악한 실제 데이터의 분포(Empirical Prior)와 일치하도록 강제하는 정규화 과정을 거칩니다. 이를 통해 특정 클래스에 데이터가 쏠려 있어도 모델이 편향되지 않고 균형 잡힌 학습을 수행할 수 있습니다. ### 기술 도입에 따른 비즈니스 기대 효과 - **글로벌 진출 가속화**: 각국의 금융 및 개인정보 규제를 준수하면서도 현지 데이터를 활용한 고성능 모델을 구축할 수 있어, 기술적 진입 장벽 없이 동남아나 유럽 등 글로벌 시장에 빠르게 안착할 수 있습니다. - **초개인화 금융 서비스**: 개별 사용자의 로컬 환경과 특이 패턴을 실시간으로 학습하여, 이상거래탐지(FDS)의 정확도를 높이고 국가별 특수성을 반영한 정교한 신용평가(CSS) 모델을 운영할 수 있습니다. - **운영 효율 극대화**: 새로운 유형의 데이터가 등장할 때마다 사람이 직접 라벨링하고 재학습시키는 과정을 줄여주며, AI가 스스로 새로운 패턴을 감지하고 학습하므로 모델 업데이트 주기와 운영 비용을 획기적으로 단축합니다. FedLPA는 데이터 보안과 모델 성능이라는 상충하는 목표를 동시에 달성함으로써 AI 기술의 실질적인 비즈니스 적용 가능성을 입증했습니다. 데이터 규제가 엄격한 글로벌 환경이나 사용자마다 데이터 특성이 극명하게 다른 금융 도메인에서 AI 서비스를 운영하고자 한다면, FedLPA와 같은 자가 학습 기반의 연합학습 구조를 적극적으로 검토할 것을 권장합니다.

고객은 절대 기다려주지 않는다: 빠른 데이터 서빙으로 고객 만족도를 수직 상승 시키는 법 (새 탭에서 열림)

토스페이먼츠는 가파른 성장세에 따른 데이터 조회 부하를 해결하기 위해 CQRS 아키텍처를 도입하고 Apache Druid를 중심으로 한 데이터 서빙 환경을 구축했습니다. 초기에는 Elasticsearch와 Druid를 결합하여 대규모 시계열 데이터의 실시간 집계와 검색 성능을 확보했으며, 이를 통해 비용 효율성과 시스템 안정성을 동시에 달성했습니다. 현재는 Druid의 조인 제약과 멱등성 문제를 해결하기 위해 StarRocks를 도입하며, 도메인 간 결합이 자유로운 통합 원장 시스템으로 진화하고 있습니다. ### CQRS와 Apache Druid 도입 배경 * **MSA 전환과 DB 분리:** 서비스 규모가 커지며 모놀리식에서 MSA로 전환했으나, DB가 분산되면서 도메인 간 조인이나 통합 조회가 어려워지는 문제가 발생했습니다. * **명령과 조회의 분리:** 읽기 전용 저장소로 Apache Druid를 선택하여 원장 DB(MySQL)의 부하를 줄이고, 수십억 건의 데이터를 저지연으로 조회하는 CQRS 구조를 설계했습니다. * **Druid의 기술적 이점:** 시계열 데이터 최적화, SQL 지원을 통한 낮은 러닝 커브, 모든 컬럼의 비트맵 인덱스(Bitmap Index)화, 그리고 클라우드 네이티브 구조를 통한 비용 효율성을 고려했습니다. ### 데이터 가공 및 메시지 발행 방식 * **CDC 대신 메시지 발행 선택:** 데이터팀이 도메인 로직을 직접 소유해야 하는 CDC 방식 대신, 각 도메인 팀에서 완성된 데이터를 발행하는 방식을 채택하여 시스템 의존성을 Kafka로 단순화했습니다. * **역정규화 테이블 구성:** 복잡한 수단별 원장 데이터를 조회 친화적인 역정규화 테이블로 변환하여 적재했으며, JSON 필드 단위까지 비트맵 인덱스가 생성되어 효율적인 질의가 가능해졌습니다. ### AWS 환경에서의 비용 및 성능 최적화 * **컴퓨팅과 스토리지 분리:** 고가의 네트워크 스토리지(EBS) 대신 S3를 영구 저장소로 활용하고, 쿼리 수행 시에는 로컬 SSD를 사용하여 성능을 9배 이상 향상했습니다. * **스팟 인스턴스 활용:** 데이터가 S3에 안전하게 보관되는 특성을 이용해 개발/테스트 환경에서 스팟 인스턴스를 적극적으로 사용하여 월 5,000만 원 이상의 클라우드 비용을 절감했습니다. * **고가용성 확보:** 네트워크 스토리지 의존성을 제거함으로써 가용 영역(AZ) 간 분산 배치가 유연해져 시스템의 안정성을 높였습니다. ### Druid 운영의 기술적 도전과 극복 * **파편화 및 멱등성 문제:** 데이터가 시점별로 분산되는 파편화 현상을 해결하기 위해 60초 주기 탐지 프로세스와 자동 컴팩션(Compaction)을 도입했습니다. * **Rollup을 통한 성능 극대화:** 동일 차원의 데이터를 자동 집계하여 저장하는 Rollup 기능을 적용해, 수십 초 걸리던 집계 쿼리 응답 속도를 0.5~1초 내외로 99% 이상 개선했습니다. * **ES 하이브리드 아키텍처:** 단일 ID 기반의 고속 검색은 Elasticsearch가 담당하고, 필터링된 결과의 대규모 집계는 Druid가 처리하도록 역할을 분담해 검색 성능을 안정화했습니다. ### StarRocks 도입을 통한 통합 원장 구축 * **조인 및 멱등성 한계 극복:** Druid의 제한적인 조인 기능과 멱등성 처리의 어려움을 해결하기 위해 StarRocks를 새롭게 도입했습니다. * **도메인 간 데이터 결합:** 결제부터 매입, 정산까지 이르는 전체 라이프사이클을 한눈에 볼 수 있는 통합 원장을 구현하여 비즈니스 요구사항에 유연하게 대응하고 있습니다. **결론적으로** 대규모 트래픽 환경에서는 단순한 DB 분리를 넘어 검색(ES), 시계열 집계(Druid), 그리고 복잡한 조인과 멱등성 보장(StarRocks)이라는 각 도구의 장점을 살린 하이브리드 아키텍처 설계가 필수적입니다. 특히 스토리지와 컴퓨팅을 분리한 구조는 비용 절감뿐만 아니라 운영의 유연성을 확보하는 핵심 전략이 됩니다.

달리는 기차 바퀴 칠하기: 7년만의 컬러 시스템 업데이트 (새 탭에서 열림)

토스 디자인 시스템(TDS)은 서비스의 글로벌 확장과 다양한 플랫폼 대응을 위해 7년 만에 컬러 시스템을 전면 개편했습니다. 인지적으로 균일한 색공간인 OKLCH를 도입하여 시각적 일관성과 접근성을 확보하고, 디자이너가 직접 제어하는 자동화된 토큰 관리 체계를 구축했습니다. 이번 개편을 통해 TDS는 단순한 디자인 가이드를 넘어, 비즈니스 성장을 뒷받침하는 확장 가능한 기술 인프라로 진화했습니다. ### 기존 컬러 시스템의 한계와 부채 - **명도 불일치**: 동일한 명도 단계(예: 100)임에도 색상(Grey, Blue, Red 등)에 따라 실제 느껴지는 밝기가 달라 UI가 얼룩덜룩해 보이는 문제가 있었습니다. - **모드 간 이격**: 라이트모드와 다크모드의 명도 기준이 달라 다크모드에서 특정 색이 너무 튀거나 가독성이 떨어지는 현상이 발생했습니다. - **관리 체계의 파편화**: 웹, iOS, 안드로이드, 디자인 에디터 등 각 플랫폼에서 컬러를 개별 관리하면서 싱글 소스 오브 트루스(SSOT)가 무너지고 커뮤니케이션 비용이 증가했습니다. ### OKLCH 색공간을 통한 인지적 균일함 확보 - **지각적 평등성**: 수치상 명도와 인간이 느끼는 밝기가 다른 HSL 모델 대신, 인지적으로 균일한 OKLCH 및 HSLuv 색공간을 활용해 모든 색상의 명도를 통일했습니다. - **접근성 자동화**: 정의된 명도 체계를 바탕으로, 외부 브랜드 컬러를 입력하더라도 TDS 기준에 맞는 배경-텍스트 대비를 자동으로 추출하는 로직을 구현했습니다. - **디바이스 최적화**: RGB 환경에서 표현하기 어려운 OKLCH 색상을 위해 채도(Chroma)를 클램핑(Clamp)하여 색조와 명도를 유지하면서도 기기 호환성을 높였습니다. ### 심미성과 접근성을 위한 시각 보정 - **Dark Yellow 문제 해결**: 수치적으로만 맞춘 노란색은 탁해 보이거나 너무 진해 보일 수 있어, 노란색 계열에 한해 별도의 명도 진행 단계를 적용하는 시각 보정을 거쳤습니다. - **다크모드 시인성 강화**: 인간의 눈이 어두운 배경에서 대비를 더 낮게 인식하는 특성을 고려하여, 최신 명도대비 메트릭인 APCA를 참고해 다크모드의 대비를 더 강하게 설계했습니다. - **시맨틱 토큰 정비**: 색상의 값(Primitive)이 아닌 사용 의도(Semantic)에 집중한 토큰 체계를 정립하여 디자인 결정 시간을 단축하고 일관성을 보장했습니다. ### 디자이너 중심의 토큰 자동화 시스템 - **통합 파이프라인**: Figma 플러그인(Token Studio)과 GitHub를 연동하여 디자이너가 컬러를 수정하고 커밋하면 모든 플랫폼의 코드가 자동으로 생성되도록 구축했습니다. - **실험적 환경**: 개발자의 수동 작업 없이도 디자이너가 직접 토큰을 변경하고 빠르게 실험할 수 있는 환경을 만들어 디자인 시스템의 운영 효율을 극대화했습니다. 성공적인 디자인 시스템 개편을 위해서는 단순한 심미적 수정을 넘어, 데이터 기반의 색공간 설계와 엔지니어링 관점의 자동화가 필수적입니다. 특히 비즈니스가 확장되는 시점이라면 컬러 시스템을 개별 컴포넌트가 아닌, 모든 플랫폼을 관통하는 하나의 '코드'이자 '인프라'로 접근하는 태도가 필요합니다.

레거시 정산 개편기: 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지 (새 탭에서 열림)

토스페이먼츠는 20년 동안 운영되어 온 레거시 정산 시스템의 한계를 극복하기 위해 대대적인 개편을 진행했습니다. 거대하고 복잡한 단일 쿼리 기반의 로직을 객체지향적인 코드로 분산하고, 데이터 모델링을 집계 중심에서 거래 단위로 전환하여 정산의 정확성과 추적 가능성을 확보했습니다. 이를 통해 폭발적인 거래량 증가에도 대응할 수 있는 고성능·고효율의 현대적인 정산 플랫폼을 구축하는 데 성공했습니다. ### 거대 쿼리 중심 로직의 분할 정복 * **문제점:** 수많은 JOIN과 중첩된 DECODE/CASE WHEN 문으로 이루어진 거대한 공통 쿼리가 모든 비즈니스 로직을 처리하고 있어 유지보수와 테스트가 매우 어려웠습니다. * **도메인 및 기능 분리:** 거대 쿼리를 분석하여 도메인별, 세부 기능별로 카테고리를 나누는 분할 정복 방식을 적용했습니다. * **비즈니스 규칙의 가시화:** 복잡한 SQL 로직을 Kotlin 기반의 명확한 객체와 메서드로 재구성하여, 코드상에서 비즈니스 규칙이 명확히 드러나도록 개선했습니다. * **점진적 전환:** 기능을 단위별로 분할한 덕분에 전체 시스템 개편 전이라도 특정 기능부터 우선적으로 새 시스템으로 전환하며 실질적인 가치를 빠르게 창출했습니다. ### 데이터 모델링 개선을 통한 추적 가능성 확보 * **최소 단위 데이터 관리:** 기존의 집계(Sum) 기반 저장 방식에서 벗어나 모든 거래를 1:1 단위로 관리함으로써, 오류 발생 시 원인 추적을 용이하게 하고 데이터 재활용성을 높였습니다. * **설정 정보 스냅샷 도입:** 계산 결과와 함께 당시의 계약 조건(수수료율 등)을 스냅샷 형태로 저장하여, 시간이 지나도 과거의 정산 맥락을 완벽히 복원할 수 있게 했습니다. * **상태 기반 재처리:** 거래별로 독립적인 상태를 기록하는 설계를 통해, 장애 발생 시 전체 재처리가 아닌 실패한 건만 선별적으로 복구할 수 있도록 효율화했습니다. ### 고해상도 데이터 대응을 위한 DB 최적화 * **파티셔닝 및 인덱스 전략:** 정산일자 기준의 Range 파티셔닝과 복합 인덱스를 활용해 데이터량 증가에 따른 조회 성능 저하를 방지했습니다. * **조회 전용 테이블 및 데이터 플랫폼 활용:** 실시간 조회가 필요한 핵심 기능은 전용 테이블로 대응하고, 복잡한 어드민 통계는 고성능 데이터 플랫폼에 위임하여 시스템 부하를 분산했습니다. ### 배치 시스템 성능 극대화 * **I/O 횟수 최소화:** 배치 실행 시점에 가맹점 설정 정보를 전역 캐시에 로드하여 반복적인 DB 조회를 제거했습니다. * **Bulk 조회 및 처리:** Spring Batch의 `ItemProcessor`에서 개별 건별로 I/O가 발생하지 않도록 Wrapper 구조를 도입하여 묶음 단위(Bulk)로 조회하도록 개선했습니다. * **멀티 스레드 활용:** `AsyncItemProcessor`와 `AsyncItemWriter`를 도입하여 단일 스레드 제약을 극복하고 처리 속도를 비약적으로 향상시켰습니다. 이번 개편은 단순히 기술적인 스택을 바꾸는 것을 넘어, 레거시 시스템에 숨겨진 복잡한 비즈니스 맥락을 명확한 도메인 모델로 추출해냈다는 점에서 큰 의미가 있습니다. 대규모 트래픽과 복잡한 정산 규칙을 다루는 시스템이라면, 데이터를 최소 단위로 관리하고 I/O 최적화와 캐싱을 적극적으로 활용하는 아키텍처를 검토해볼 것을 추천합니다.

업무 효율화, 작은 단계부터 다시 보기 (새 탭에서 열림)

토스 리서치 플랫폼 팀은 업무 효율화를 거창한 시스템 구축이 아닌, 개별 액션 단위의 세밀한 분석과 점진적인 개선 과정으로 정의합니다. 프로세스를 잘게 쪼개어 불필요한 단계를 제거하고 반복되는 작은 작업을 자동화함으로써, 팀 전체의 리소스를 절약하고 더 본질적인 리서치 업무에 집중할 수 있는 환경을 구축했습니다. 이를 통해 효율화는 완벽한 결과물을 한 번에 만드는 것이 아니라, 사소한 불편함을 꾸준히 덜어내는 과정임을 증명했습니다. ### 액션 단위의 정밀한 현황 파악 * 프로세스를 단순히 단계별로 나열하는 '겉핥기식 정리'에서 벗어나, '누가, 어디서(툴/채널), 무엇을, 왜' 하는지 구체적인 개별 액션으로 쪼개어 분석합니다. * 시간, 담당자, 도구 등 일관된 기준을 적용하여 과정을 정리해야 예외 상황을 명확히 파악하고 읽는 사람이 오해 없이 이해할 수 있습니다. * 가끔 발생하는 예외 케이스까지 함께 정리함으로써 기존 프로세스의 부족한 점을 보완하는 힌트를 얻습니다. ### 본질적인 질문을 통한 문제 정의 * 각 액션에 대해 "이 작업이 왜 필요한가?"라는 질문을 던져, 목적이 불분명한 단계는 과감히 삭제하고 꼭 필요한 단계는 더 쉬운 방법을 모색합니다. * 예를 들어, 인터뷰 일정 생성은 자동화하되 팀원들이 이미 캘린더를 잘 확인한다면 별도의 메시지 전송 단계는 생략하는 식의 의사결정을 내립니다. * 개별적으로는 몇 초 걸리지 않는 사소한 업무라도 여러 사람이 반복하면 큰 비효율이 되므로, 반복되는 작은 액션을 줄이는 데 집중합니다. ### 이해관계자 중심의 우선순위 선정 * 우선순위를 정할 때는 자신의 리소스나 시급성뿐만 아니라 '많은 사람에게 영향을 미치는지', '다른 업무에 연관되는지', '소요 시간이 얼마나 긴지'를 종합적으로 판단합니다. * 내 업무에는 큰 영향이 없더라도 운영 담당자나 협업자의 더블 체크 시간을 줄여줄 수 있다면 해당 업무를 우선 개선 대상으로 삼습니다. * '내 기준'이 아닌 이 일에 영향을 받는 '모든 이해관계자'의 관점에서 임팩트를 측정하는 것이 핵심입니다. ### 리스크를 최소화하는 점진적 해결책 적용 * 처음부터 모든 과정을 완벽하게 자동화하려 하기보다, 현재 기술로 가능한 작은 부분부터 개선을 시작합니다. * 새로운 방식 도입이 우려될 경우 전체에 바로 적용하기보다 일부 케이스에만 테스트 기간을 두어 점진적으로 적용하며 피드백을 수렴합니다. * 완벽한 준비보다는 '언제든 이전 방식으로 돌아갈 수 있다'는 유연한 사고를 바탕으로 작은 실험을 반복하며 해결책을 정교화합니다. 업무 효율화가 막막하게 느껴진다면 지금 하고 있는 일을 클릭, 입력, 공유와 같은 최소 단위로 쪼개보세요. 거대한 시스템을 새로 만들지 않아도, 매일 반복되는 자잘한 수고를 덜어내는 것만으로도 팀 전체에 체감되는 큰 변화를 만들어낼 수 있습니다.

사업자 데이터 리터러시 높이기: BC Monthly Report 발행기 (새 탭에서 열림)

토스는 각 사업부별로 흩어져 있던 사업자(Business Customer, BC) 데이터를 통합하여 '단일 진실의 근원(SSOT)'인 데이터 마트를 구축하고, 이를 기반으로 전사적인 월간 리포트를 발행하여 비즈니스 의사결정 구조를 혁신했습니다. 이 과정에서 파편화된 지표 정의를 하나로 모으고 현업의 니즈를 반영한 결과, 전사 구성원들이 동일한 기준으로 사업 현황을 파악하고 데이터에 기반해 실질적인 액션 아이템을 도출할 수 있는 환경이 마련되었습니다. 이러한 여정은 단순한 데이터 정리를 넘어 토스 전반의 데이터 리터러시를 높이고 비즈니스 성장을 가속화하는 기폭제가 되었습니다. **단일 진실의 근원(SSOT)을 위한 데이터 마트 구축** * 쇼핑, 광고, 페이 등 각 사업부별로 분산되어 관리되던 사업자 데이터를 통합하여 전사적으로 공통된 언어를 사용하는 'BC 데이터 마트'를 설계했습니다. * 사업부별로 상이했던 매출과 비용 발생 기준을 표준화하기 위해 도메인 담당자들과의 소통을 거쳐 '토스에서 활동하는 사업자'에 대한 명확한 정의를 수립했습니다. * 이를 통해 "이번 달 매출을 발생시킨 사업자가 몇 명인가?"라는 기초적인 질문에 대해 전사가 동일한 숫자로 답변할 수 있는 기술적 기반을 마련했습니다. **통찰을 제공하는 Monthly BC Report 설계 및 자동화** * 데이터의 전파력을 높이기 위해 신규(New), 이탈(Churn), 유지(Retained) 트렌드와 매출 규모별 티어(Tier) 분석을 포함한 월간 리포트를 기획했습니다. * 단순 지표 나열이 아닌, 코호트 리텐션(Cohort Retention) 분석을 통해 플랫폼 만족도를 확인하고, 이탈 가맹점 리스트 등 실무자가 즉시 활용 가능한 로우 데이터(Raw Data)를 함께 제공했습니다. * 데이터 파이프라인은 Airflow를 통해 마트를 구축하고 Jenkins로 배치 작업을 수행하며, 최종적으로 태블로(Tableau)와 SQL을 연동해 매달 자동으로 업데이트되는 환경을 구현했습니다. **현업 피드백을 통한 리포트의 고도화와 데이터 리터러시 확산** * PO, 세일즈 팀장 등 실제 사용자의 니즈를 파악하기 위해 심층 인터뷰를 진행하고, 이를 바탕으로 '회원 가입' 단계 분석이나 도메인 간 활성화 순서 등 구체적인 지표를 리포트에 추가했습니다. * 리포트 발행 이후 사업자 데이터에 대한 전사적 관심이 급증하며, 이탈 가맹점 상세 분석이나 데일리 트래킹 등 후속 심화 분석 프로젝트로 이어지는 성과를 거두었습니다. * 고정된 포맷에 안주하지 않고 매달 현업의 피드백을 반영하여 지표를 개선함으로써, 조직 전체의 데이터 이해도와 활용 능력을 점진적으로 상향 평준화했습니다. 데이터 마트 구축과 리포트 발행은 끝이 아닌 시작이며, 현업과의 지속적인 피드백 루프를 통해 리포트를 ' 살아있는 문서'로 관리하는 것이 중요합니다. 조직 내 데이터 리터러시를 높이고 싶다면 표준화된 지표 정의부터 시작해 구성원들이 실제 업무에 바로 적용할 수 있는 액션 중심의 데이터를 제공하는 단계적 접근이 필요합니다.