토스

양자 컴퓨터가 등장하기 10년 전 우리가 양자 내성 암호를 도입한 이유 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 시스템을 개편하며 수만 가맹점의 결제 안정성을 유지하는 동시에, 미래의 보안 위협에 대비한 기술적 도약을 시도했습니다. 특히 기존 암호화 체계를 무력화할 수 있는 양자 컴퓨팅의 위협에 선제적으로 대응하기 위해, 4년에 걸친 단계적 로드맵을 통해 양자 내성 암호(PQC)를 성공적으로 도입했습니다. 이는 단순히 기술적 업그레이드를 넘어 가맹점과의 복잡한 이해관계를 조정하며 이뤄낸 보안 인프라 현대화의 결실입니다. **레거시 보안 개편의 현실적 난관** * **가맹점 호환성 문제**: 브라우저와 달리 서버 간 통신(API)은 노후화된 인프라에서 실행되는 경우가 많아, 최신 보안 프로토콜 적용 시 수만 가맹점의 결제가 중단될 위험이 큼. * **기술적 소통의 장벽**: 보안 업그레이드에 필요한 복잡한 기술 용어는 전담 개발팀이 없는 영세 가맹점주들에게 큰 부담이 되며, 이는 전체 보안 수준을 높이는 데 병목 현상을 일으킴. * **보수적 운영 원칙의 충돌**: "망가지지 않았다면 건드리지 않는다"는 안정성 최우선의 원칙이 보안 고도화라는 변화의 의지와 충돌하는 지점이 발생함. **양자 컴퓨팅과 기존 암호 체계의 위협** * **전통적 암호 알고리즘의 한계**: 현재 널리 쓰이는 RSA, ECDSA는 소인수분해나 타원곡선 연산의 어려움에 기반하지만, 양자 컴퓨터는 이를 수 시간 내에 풀어낼 수 있음. * **Q-Day와 선점 공격(HNDL)**: 양자 컴퓨터가 암호를 해독하게 되는 'Q-Day'에 대비해야 함. 특히 지금 암호화된 데이터를 미리 수집해 두었다가 나중에 양자 컴퓨터로 복호화하는 'Harvest Now, Decrypt Later' 공격은 현재의 데이터 안전을 실질적으로 위협함. * **결제 데이터의 가치 유지**: 결제 정보는 시간이 지나도 가치가 유효하므로, 미래의 해킹 위협으로부터 보호하기 위해 지금 당장 강력한 암호 체계 도입이 필요함. **4단계 보안 프로토콜 고도화 과정** * **HTTP/3 도입 (2022)**: PG 업계 최초로 최신 웹 프로토콜을 도입하여 결제 속도를 개선하고, 최신 보안 규격인 TLS 1.3 사용을 강제할 수 있는 기반을 마련함. * **취약한 암호 스위트 제거 및 TLS 1.3 확산 (2022~2025)**: 보안성이 낮은 구형 암호화 방식들을 단계적으로 퇴출하고, 가맹점들의 환경을 최신 전송 계층 보안 프로토콜로 전환하도록 유도함. * **양자 내성 암호(PQC) 구현 (2026)**: 양자 컴퓨터의 공격에도 견딜 수 있는 차세대 암호 알고리즘을 최종적으로 적용하여 미래 지향적인 보안 체계를 완성함. 보안은 "현재 문제가 없다"고 해서 안주할 수 있는 영역이 아닙니다. 특히 결제 시스템처럼 민감한 정보를 다루는 서비스는 가맹점의 기술적 부채를 고려하면서도, 미래의 잠재적 위협인 양자 컴퓨팅 공격 등에 대비해 끊임없이 인프라를 현대화하는 선제적인 자세가 필요합니다.

StarRocks 운영기: Resource Group으로 멀티테넌트 워크로드 격리하기 (새 탭에서 열림)

토스는 서비스 조회와 대규모 분석 쿼리를 하나의 플랫폼에서 처리하기 위해 StarRocks를 실시간 OLAP 엔진으로 도입하고, 다양한 워크로드가 공존하는 환경에서 리소스 그룹(Resource Group)을 통해 안정적인 운영 체계를 구축했습니다. 특히 CPU 우선순위 설정과 전용 코어 할당 방식을 전략적으로 선택하여, 대규모 배치 작업이 진행되는 중에도 서비스 쿼리의 응답 속도(SLA)를 일관되게 유지하는 최적의 격리 구조를 설계했습니다. **비즈니스 중요도에 따른 워크로드 분류** * 워크로드의 성격에 따라 서비스 쿼리, 서버 배치, 대규모 적재·백필, 모니터링·사용자 도구 순으로 우선순위를 정의했습니다. * 실시간 응답이 필수적인 서비스 쿼리는 가장 먼저 보호하고, 클러스터 전체에 부하를 줄 수 있는 대규모 적재나 단순 모니터링 조회는 하위 순위나 상한선을 두어 관리합니다. **가중치 기반의 유연한 리소스 분배 (cpu_weight)** * CPU 경합이 발생할 때 설정된 비율에 따라 리소스를 분배하는 방식으로, Linux CFS(Completely Fair Scheduler)와 유사한 자체 스케줄링 메커니즘을 사용합니다. * 리소스가 여유로울 때는 다른 그룹의 남는 자원을 빌려 쓸 수 있어(Borrowing), 일반적인 멀티테넌트 환경에서 리소스 효율성을 극대화하는 기본 설정으로 활용됩니다. * 내부적으로 파이프라인 드라이버가 100ms 타임 슬라이스 단위로 양보하며 동작하므로, 중요도가 높은 그룹이 더 많은 CPU 시간을 확보하게 됩니다. **물리적 코어 예약을 통한 배타적 격리 (exclusive_cpu_cores)** * 높은 SLA가 요구되는 특정 서비스의 경우, 물리적 코어를 전용으로 예약하여 다른 워크로드의 간섭을 완전히 차단합니다. * 이 설정은 단순히 논리적 할당에 그치지 않고, `pthread_setaffinity_np`를 통해 스레드를 코어에 바인딩하며 쿼리 실행을 위한 3벌의 ThreadPool(Driver, Scan, ConnectorScan)을 별도로 생성합니다. * 공유 리소스 풀과의 경합이 원천적으로 제거되므로, 헤비 배치 작업과 서비스 조회가 겹치는 상황에서도 응답 시간이 튀는 현상을 방지할 수 있습니다. **토스쇼핑 사례를 통한 단계적 최적화** * 초기에는 `cpu_weight` 조정을 통해 서비스 계정에 높은 우선순위를 부여했으나, 대규모 배치 작업 시 서비스 응답 속도가 불안정해지는 한계가 있었습니다. * 이를 해결하기 위해 서비스 전용 리소스 그룹에 `exclusive_cpu_cores`를 적용하여 물리적인 리소스 벽을 세웠습니다. * 결과적으로 분당 1,500건 이상의 서비스 요청이 발생하는 구간에서도 배치 작업의 영향 없이 안정적인 레이턴시를 확보하는 데 성공했습니다. **정교한 쿼리 매칭을 위한 Classifier 설계** * `user`, `role`, `query_type`, `db` 등의 속성을 기반으로 쿼리를 적절한 리소스 그룹에 할당하는 Classifier 규칙을 수립했습니다. * 운영 안정성을 위해 가급적 `user` 또는 `db` 단위로 그룹을 묶는 패턴을 권장하며, 이를 통해 특정 서비스나 배치 주체가 정해진 리소스 범위 내에서만 동작하도록 강제합니다. * CPU 제어 외에도 `mem_limit`과 `concurrency_limit`을 병행 설정하여 풀 스캔 쿼리의 메모리 독점이나 과도한 동시 접속으로 인한 클러스터 마비를 방지합니다. **실용적인 운영 제언** 가장 효율적인 운영 전략은 기본적으로 `cpu_weight`를 사용하여 리소스 효율을 높이되, 실시간 서비스와 같이 지연 시간에 민감한 워크로드에 한해서만 `exclusive_cpu_cores`를 단계적으로 도입하는 것입니다. 또한 리소스 그룹 설정 시 실제 물리 코어 수와 워크로드 간의 의존 관계를 면밀히 검토해야 예상치 못한 성능 저하를 막을 수 있습니다.

양자컴퓨터 시대에 대비한 양자내성암호 적용, 왜 10년 먼저 서비스에 적용했을까? (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 시스템을 개편하며 수만 개 가맹점의 안정성을 유지하는 동시에, 양자컴퓨터 시대를 대비한 보안 프로토콜 고도화를 성공적으로 완수했습니다. 보안은 '현재의 안전'뿐만 아니라 미래의 위협까지 선제적으로 대응해야 하는 영역이기에, 4년에 걸친 단계적 로드맵을 통해 가맹점의 부담을 최소화하며 양자내성암호(PQC)를 도입했습니다. 결제 데이터의 장기적 안전을 확보하기 위해 기술적 한계를 넘어서는 전사적 협업과 가맹점 밀착 지원이 이 과정의 핵심이었습니다. **보안 프로토콜 개선을 가로막는 관성과 현실적 제약** * **보수적 운영 원칙:** "돌아가면 건들지 마라"는 미션 크리티컬한 결제 서비스의 불문율이 보안 업데이트의 큰 장벽이 됩니다. * **가맹점의 낙후된 기술 스택:** 수만 개 가맹점 중에는 수십 년 전 기술 스택을 그대로 사용하는 곳이 많아, 최신 보안 정책 적용 시 결제가 중단될 위험이 큽니다. * **기술 지원의 한계:** 보안 용어에 익숙하지 않은 소상공인이나 전담 개발팀이 없는 가맹점은 단순 안내문만으로 대응하기 어려워 세밀한 기술 컨설팅이 필수적입니다. **양자컴퓨터의 위협과 '선수집·후복호화' 공격** * **기존 암호 체계의 붕괴:** 현재 사용되는 RSA, ECDSA 등은 양자컴퓨터의 압도적인 계산 능력 앞에서 사실상 무용지물이 됩니다. * **선수집·후복호화(Harvest Now, Decrypt Later):** 지금 암호화된 데이터를 미리 수집해두었다가 나중에 양자컴퓨터로 풀어보는 공격 방식으로, 결제 데이터처럼 장기적 가치를 지닌 정보에 치명적입니다. * **Q-Day 대비:** 실용 수준의 양자컴퓨터가 등장할 2030년경을 대비해, 데이터 유효 기간을 고려하면 지금 당장 암호 체계를 전환해야 합니다. **4단계 보안 프로토콜 고도화 로드맵** * **HTTP/3 도입 (2022):** 브라우저가 자동으로 최신 규약을 선택하게 함으로써 가맹점 작업 없이 보안성과 속도를 동시에 개선했습니다. * **취약 Cipher Suite 제거 (2022~2025):** 가장 고된 작업으로, 가맹점별 사용 환경을 분석해 3년 넘게 개별 기술 지원과 유예 기간을 거쳐 안전하지 않은 알고리즘을 퇴출했습니다. * **TLS 1.3 전면 도입 (2022~2025):** 구형 환경과의 호환성을 위해 TLS 1.2를 유지하면서도, 지원 가능한 클라이언트는 자동으로 더 안전한 1.3 버전을 쓰도록 기본값을 상향했습니다. * **양자내성암호(PQC) 도입 (2026):** PQC 지원 브라우저에는 최상위 보안 채널을 제공하고 미지원 환경에는 기존 암호를 제공하는 하이브리드 방식으로 연동 부담 없이 미래 위협에 대응했습니다. **조직적 협업과 실증적 성과** * **다학제적 팀워크:** 자체 데이터센터(IDC)를 관리하는 인프라 팀, AWS 환경을 담당하는 서버 플랫폼 팀, 그리고 가맹점 접점에서 기술 상담을 수행하는 TAM 팀의 유기적 협업이 성공의 열쇠였습니다. * **민간 보안 선도:** 정부의 '양자내성암호 전환 마스터플랜'에 발맞추어 민간 결제 생태계에서 선제적으로 기술 실증을 완료하여 결제 보안의 새로운 표준을 제시했습니다. 결제 서비스의 보안은 단순히 서버 설정을 바꾸는 기술적 작업을 넘어, 연결된 수많은 파트너와 함께 호흡하며 신뢰를 쌓아가는 과정입니다. 미래의 보안 위협은 이미 시작되었기에, 가맹점 환경을 배려하면서도 선제적으로 암호 체계를 전환하는 결단이 지속 가능한 비즈니스를 위한 필수 조건입니다.

토스플레이스 데이터봇 ‘판다(PANDA)’를 소개합니다 : 모든 팀원이 데이터 전문가처럼 일하는 방법 (새 탭에서 열림)

토스플레이스는 데이터 분석가에게 집중된 단순 추출 요청을 해결하고 전사적인 데이터 민주주의를 실현하기 위해 AI 데이터 분석 어시스턴트 ‘판다(PANDA)’를 개발했습니다. 판다는 단순한 챗봇을 넘어 표준 데이터 마트 정비와 에이전트 기반의 자율 루프 시스템을 통해 데이터 조회부터 실무 인사이트 제공까지 수행하며, 출시 후 전사 구성원의 70%가 활용하는 필수적인 도구로 자리 잡았습니다. 기술적 복잡함보다 비즈니스 맥락과 데이터 거버넌스에 집중함으로써, 누구나 데이터 분석가의 도움 없이도 정확한 의사결정을 내릴 수 있는 환경을 구축했다는 데 큰 의의가 있습니다. ### 데이터 신뢰성을 위한 표준 데이터 마트(SSOT) 구축 * AI가 일관된 답을 낼 수 있도록 Data Analysis와 Platform 팀이 협업하여 핵심 데이터를 단일화된 테이블로 정비했습니다. * **표준 네이밍 컨벤션:** 테이블명은 `{역할}_{도메인}_{주제}`(예: fact_device_error_log)로, 컬럼명은 `{접두어}_{대상}_{속성}_{접미어}`(예: is_merchant_active)로 규칙화하여 AI가 이름만으로도 데이터의 목적을 이해하게 했습니다. * 모든 테이블과 컬럼에 상세 설명을 추가하여 AI가 데이터를 정확하게 탐색할 수 있는 기반 정보를 제공했습니다. ### 데이터 선택의 정확도를 높이는 Scoring & Ranking 시스템 * 질문에 대해 매번 다른 테이블을 선택하는 문제를 방지하기 위해 유사도와 신뢰도를 결합한 점수 체계를 도입했습니다. * **최종 점수 산출:** `(질문-테이블 유사도) × (데이터 계층 가중치)` 공식을 적용합니다. * **계층별 가중치:** 전사 주요 지표(SSOT)는 4배, 검증된 표준 마트는 3배, 도메인 마트는 2배, 원시 로그 데이터는 1배의 가중치를 부여하여 가장 신뢰할 수 있는 소스를 우선 선택하게 합니다. * dbt tags를 활용해 관리되는 테이블만 Manifest 파일로 가져와 탐색 범위를 최적화했습니다. ### 비즈니스 맥락 연결과 에이전틱 루프(Agentic Loop) * ‘설치 매장’이나 ‘업종 분류’와 같은 비즈니스 용어 정의를 데이터 구조와 연결하여 AI가 단순 수치 이상의 맥락을 파악하도록 설계했습니다. * AI가 스스로 상황에 맞는 도구를 선택하고, 결과가 부정확할 경우 스키마를 다시 확인하여 쿼리를 수정 및 재실행하는 자율적 재시도 과정을 거칩니다. * '테이블 탐색 → 쿼리 실행 → 결과 검증 → 수정 → 최종 결과 도출'의 과정을 반복하며 정답률을 높이는 구조를 갖췄습니다. ### 실무 활용성을 고려한 답변 구조 및 성과 * 단순 숫자 나열이 아니라 **결과, 조회 기준, 실무 인사이트**라는 3단계 구조로 답변을 제공하여 사용자의 해석 시간을 단축했습니다. * 출시 직후 전체 팀원의 절반 이상이 사용했으며, 현재는 70%의 사용률을 기록하며 데이터 요청에 대한 심리적 문턱을 낮추고 실질적인 업무 방식의 변화를 이끌어냈습니다. * 개발자, 기획자 등 비데이터 직군에서도 활발히 사용하며 데이터 분석가의 리소스를 고부가가치 분석 업무에 집중할 수 있도록 지원합니다. 성질 급한 AI 모델의 성능에만 의존하기보다, **데이터의 표준화와 비즈니스 로직의 명확한 정의(Governance)**가 선행될 때 비로소 실효성 있는 AI 서비스가 완성된다는 점을 시사합니다. 사내 데이터 민주화를 고민한다면, 기술적 기교 이전에 AI가 읽기 좋은 데이터 환경을 만드는 것부터 시작할 것을 추천합니다.

Apache Flink + RocksDB 튜닝으로 광고 Frequency Capping 실시간 집계를 일주일까지 확장하기 (새 탭에서 열림)

토스 데이터 서비스 플랫폼 팀은 광고 노출 집계의 정확성을 높이고 서빙 효율을 개선하기 위해, 기존 Airflow 배치와 Flink 스트리밍이 혼재된 시스템을 전면 Flink 기반의 실시간 슬라이딩 집계 시스템으로 전환했습니다. 1분부터 7일까지의 광범위한 집계 구간을 단일 Redis 조회로 제공하기 위해 집계 특성별로 Flink 앱을 분리하고, RocksDB 및 런타임 설정을 최적화하여 비즈니스 오차를 최소화했습니다. 이 과정에서 대규모 상태(State) 관리와 초기 데이터 적재의 정합성 문제를 해결하며 운영 신뢰성을 확보했습니다. ### 광고 노출 제어(Frequency Capping)의 중요성 * 광고주 예산 낭비를 막고 노출 기회 손실을 방지하기 위해 사용자별 광고 노출 횟수를 정확하게 카운트하고 제어하는 메커니즘입니다. * 광고 상품에 따라 '하루 3회', '7일간 1회' 등 집계 구간이 다양하므로, 1분부터 7일까지의 모든 구간에 대해 이벤트 단위의 정밀한 슬라이딩 윈도우 집계가 필요합니다. ### 기존 시스템의 한계와 개선 동기 * 기존에는 Airflow를 이용해 당일(Head), 과거(Mid), 경계 보정(Tail)의 3단계로 나누어 처리하는 배치 구조를 사용했으나, 유지보수해야 할 DAG가 너무 많고 구조가 복잡했습니다. * 서빙 시점에 구간별로 Redis를 최대 4회 조회해야 하는 구조적 번거로움이 있었으며, 실시간으로 변하는 슬라이딩 윈도우를 정밀하게 구현하는 데 한계가 있었습니다. ### 병목 패턴에 따른 앱 분리 및 아키텍처 * 집계 구간별 병목 현상이 다르다는 점에 착안하여 시스템을 **Minutes**(1~30분), **Hours**(최대 12시간), **Days**(최대 7일)의 3개 앱으로 분리했습니다. * **Minutes**: 빈번한 만료 처리로 인한 Write Stall이 주요 병목이며, RocksDB Write 경로 튜닝이 핵심입니다. * **Hours**: 대량의 광고 ID 누적으로 인한 Filter Block Cache Miss와 CPU 포화가 발생하여 Managed Memory 증설이 필요합니다. * **Days**: Savepoint가 230GB에 달하는 대규모 상태가 병목이며, Checkpoint I/O 문제를 해결하기 위해 Changelog State Backend를 활용합니다. * Flink State를 '단일 진실 공급원(SSOT)'으로 삼아, 장애 발생 시에도 Redis를 State로부터 언제든 다시 구성할 수 있도록 설계했습니다. ### 초기 적재와 전환 정합성 확보 * 7일치의 과거 데이터를 채우는 과정에서 '백필(카운트만 수행)'과 '캐치업(카운트와 만료 타이머 함께 등록)' 파이프라인을 분리하는 2단계 구조를 설계했습니다. * 백필 도중 만료 타이머가 미리 발화하여 집계가 틀어지는 문제를 방지하기 위해, 백필 완료 후 특정 시점부터만 Redis에 쓰기가 수행되도록 제어했습니다. * `withIdleness` 설정을 통해 특정 파티션의 지연이 전체 Watermark 진행을 막지 않도록 하고, `timerState`의 TTL을 윈도우보다 길게 설정해 지연 상황에서도 감소 로직이 누락되지 않도록 보장했습니다. ### RocksDB와 런타임 최적화 * **Minutes 앱**: Write Buffer Manager(WBM) 압박을 완화하여 RocksDB가 쓰기를 멈추는 Write Stall 현상을 방지했습니다. * **Hours 앱**: Bloom Filter 및 메모리 설정을 통해 캐시 미스를 줄여 CPU 효율을 높였습니다. * **Days 앱**: 거대한 SST 파일로 인한 체크포인트 부하를 줄이기 위해 레벨 최적화와 Changelog 메커니즘을 적용했습니다. 대규모 데이터를 다루는 실시간 집계 시스템에서는 모든 구간을 하나의 설정으로 처리하기보다, 데이터의 규모와 병목 지점에 따라 앱을 분리하고 각기 다른 RocksDB 튜닝 전략을 적용하는 것이 운영 안정성 측면에서 효과적입니다. 또한, 상태(State)를 시스템의 최상위 데이터 원천으로 관리하는 원칙을 지킬 때 장애 복구와 데이터 정합성 유지가 훨씬 용이해집니다.

하마터면 못생겨질 뻔했다 - 토스 프론트 2 제작기 (새 탭에서 열림)

토스플레이스의 결제 단말기 '프론트 2'는 단순히 기능을 나열하는 것을 넘어, 1세대 사용 현장에서 발견한 불편함을 집요하게 개선하여 심미성과 사용성을 동시에 확보한 결과물입니다. 개발팀은 기술적으로 가능한 답에 안주하지 않고 소재의 변화와 내부 설계의 전면 재구성을 통해 NFC 인식 개선과 리더기 교체 편의성이라는 난제를 해결했습니다. 결과적으로 완성도는 우연이 아닌 '더 나은 답'을 찾기 위한 치열한 고민과 집착에서 비롯됨을 보여줍니다. **NFC 인식률과 사용성을 위한 소재의 혁신** * 1세대 단말기는 기술적 안정성 때문에 NFC 안테나가 우측에 배치되어 좁은 매대에서 결제가 불편했던 점을 개선하고자 NFC를 전면으로 이동시켰습니다. * 디스플레이 뒤쪽의 금속 성분이 NFC 신호를 차단하는 문제를 해결하기 위해, 카드 리더기 위치 변경이나 단말기 크기 확장 등의 시안을 검토했으나 심미성과 인식률 저하로 폐기했습니다. * 결국 '디스플레이 뒷면은 금속이어야 한다'는 고정관념을 깨고, 전파 간섭이 없는 플라스틱 소재로 교체하되 강화유리로 내구성을 보완하는 커스터마이징 공정을 도입하여 전면 NFC 인식을 구현했습니다. **C타입 도킹 구조를 통한 수리 편의성 확보** * 고장 시 기기 전체를 입고해야 했던 일체형 구조의 불편함을 해결하기 위해, 사장님이 현장에서 직접 교체할 수 있는 분리형 카드 리더기를 설계했습니다. * 별도의 나사나 복잡한 고정 장치 없이도 깔끔한 디자인을 유지하기 위해 누구나 익숙한 C타입 단자 결합 방식을 채택했습니다. * 이를 통해 대리점의 재고 부담을 줄이고 매장 운영 공백을 최소화하면서도, 외관상으로는 하나의 완성된 제품처럼 보이는 심리스(Seamless)한 디자인을 완성했습니다. **내부 설계를 뒤집는 역발상으로 구현한 유지보수** * C타입으로 결합된 리더기를 도구 없이 쉽게 분리하기 위해, 리더기 일부를 돌출시키는 대신 '뒤에서 밀어 빼는' 구조를 고안했습니다. * 하지만 뒷면의 전원 및 인터넷 단자 공간 문제로 초기 설계상 구현이 불가능하자, 내부 회로 기판을 위아래로 뒤집고 비스듬히 기울여 재배치하는 전면 재설계를 단행했습니다. * 케이블 단자 부품까지 모두 반전된 형태로 새로 수급하는 과정을 거쳐, 결과적으로 리더기 교체는 물론 케이블 연결까지 더 쉬워진 내부 구조를 만들어냈습니다. **실천적 결론: 완성도를 높이는 4가지 질문** 제품의 완성도를 높이기 위해서는 기술적으로 '되는' 답이 아니라 사용자에게 '맞는' 답을 찾아야 하며, 이를 위해 다음의 질문을 반복할 것을 권장합니다. 1. **사용성 점검:** 모든 사용자(Edge case 포함)가 이 디자인을 쉽고 편하게 누릴 수 있는가? 2. **본질 정의:** 당면한 여러 문제 상황을 관통하는 근본적인 원인은 무엇인가? 3. **최선 의심:** 현재 도출된 해결책이 정말 본질을 해결하는 최선의 방법인가? 4. **방향 재정의:** 현재의 답이 부족하다면, 해결책의 방향성 자체를 처음부터 다시 설정할 수 있는가?

Layers of your time : 토스와 함께한 시간을 기념하기 (새 탭에서 열림)

토스의 인터널 브랜딩은 단순히 예쁜 물건을 만드는 것이 아니라, 구성원이 팀과 함께 보낸 '시간의 가치'를 정의하고 이를 감동적인 경험으로 설계하는 과정입니다. 8개월간 진행된 N주년 굿즈 리뉴얼 프로젝트는 "왜 존재하는가"라는 본질적인 질문에서 시작하여, 타협하지 않는 디테일과 받는 순간의 시나리오까지 정교하게 설계함으로써 팀원들에게 소속감과 자부심을 전달했습니다. 결국 좋은 인터널 브랜딩이란 구성원이 '좋은 팀에서 일하고 있다'는 확신을 갖게 하여 업무의 몰입과 품질로 이어지게 만드는 강력한 동기부여 수단이 됩니다. **기존 굿즈의 한계와 새로운 목표 설정** - 과거 메달, 와인 등 다양한 굿즈를 제공했으나 시간이 흐르며 '소중한 선물'이 아닌 '정리해야 할 물건'으로 인식되는 문제가 발생했습니다. - "10년, 20년의 헤리티지를 보석처럼 모아가는 개념"으로 관점을 전환하여, 물건 제작이 아닌 '시간을 축하하는 방식'을 설계하는 것을 목표로 삼았습니다. - 팀원 개인의 시간을 진심으로 축하하고, 리뉴얼을 기다려준 이들에게 감사의 마음을 시각화하여 전달하고자 했습니다. **시간의 깊이를 담은 'Layered Lighting'** - 받자마자 서랍에 넣지 않고 실생활에 쓰이며, 시간이 쌓이는 감각이 물리적으로 보여야 한다는 3가지 기준을 세웠습니다. - 길가의 조명에서 영감을 얻어, 입사 주년마다 디스크를 한 장씩 쌓아 올리는 조명 아이디어를 도출했습니다. - 디스크가 쌓일수록 빛의 레이어가 깊어지는 구조를 통해 디자인적 장식보다 구조 자체가 의미를 설명하도록 설계했습니다. - 1~10주년은 화이트 버전으로, 11주년부터는 블랙 버전으로 나누어 '새로운 시간의 차원'이라는 상징성을 부여했습니다. **하드웨어 제작에서의 집요한 디테일 구현** - 조명 디스크의 두께 0.5mm 차이가 빛의 확산에 미치는 영향, 본체와의 간격 등을 수없이 테스트하며 완성도를 높였습니다. - 납품 직전 발견된 수십 가지 불량품 문제 앞에서 일정을 미루더라도 퀄리티와 타협하지 않는 원칙을 고수했습니다. - 약 5,000개의 조명을 전수 검품하며, '구성원이 매일 마주하는 물건'으로서 부끄럽지 않은 품질을 확보했습니다. **따뜻한 언어와 경험의 흐름 설계** - 'Layered Lighting'이라는 이름과 "Layers of your time at toss"라는 문구를 새겨 미션보다는 개인의 시간에 집중한 감성적 접근을 취했습니다. - 딱딱한 고딕체 대신 세리프 서체를 사용하고, 개인의 이름을 수기로 적은 카드를 동봉하여 인간적인 온기를 더했습니다. - 단순히 라운지에서 수령하는 방식이 아닌, 월요일 아침 출근했을 때 자신의 자리에 선물이 놓여 있는 깜짝 이벤트를 기획했습니다. - 3,900명의 자리 배치도를 확인하며 2,500명의 자리에 26시간 동안 직접 선물을 배치하여, "일 년 더 다닐 이유가 생겼다"는 정서적 반응을 이끌어냈습니다. **인터널 브랜딩 프로젝트를 위한 체크리스트** - 프로젝트의 존재 이유를 한 문장으로 설명할 수 있는가? - 시각적 레퍼런스를 찾기 전, 결과물이 충족해야 할 조건을 먼저 정의했는가? - 첫 대면부터 마지막 순간까지의 경험 흐름을 통째로 설계했는가? - 타협의 유혹이 올 때 돌아갈 명확한 기준이 있는가? - 이 결과물이 구성원에게 "이 팀과 함께하고 싶다"는 감정을 불러일으키는가?

토스가 디자인 직무를 2개로 줄인 이유 (새 탭에서 열림)

토스 디자인 챕터는 기술의 발전으로 도구 활용에 대한 장벽이 낮아짐에 따라, 기존의 세분화된 6개 직무를 'Product Designer'와 'Visual Designer' 2개로 전격 통합했습니다. 이번 개편은 "어떤 도구를 사용하는가" 혹은 "어떤 화면을 만드는가"라는 수단 중심의 경계를 허물고, "무엇이 좋은 경험인가"를 판단하는 디자이너 본연의 감각과 판단력에 집중하기 위한 결정입니다. 이를 통해 디자이너가 고민할 수 있는 영역을 넓히고, 매체나 기법에 갇히지 않는 본질적인 문제 해결을 지향합니다. **수단과 매체가 만든 직무 경계의 한계** * 기존의 직무 세분화(Platform, Interaction, Graphic, Brand 등)는 조직의 성장에 따라 전문성을 쌓는 데 기여했으나, 실무에서는 점차 경계가 모호해지는 문제가 발생했습니다. * 인터랙션 적용이나 디자인 시스템 구축 시 특정 직무의 영역인지 모호한 상황이 반복되었으며, 이는 협업의 효율을 저해하는 요소가 되었습니다. * 과거의 직무 구분은 "무엇을 판단하느냐"가 아니라 Lottie, 코드, PC/모바일 등 다루는 도구와 화면의 크기라는 '수단'에 매몰되어 있었다는 점이 한계로 지적되었습니다. **기술 발전과 하드스킬 장벽의 붕괴** * AI와 디자인 도구(Figma 등)의 비약적인 발전으로 영상 제작, 프로토타이핑, 코드 구현 등 과거 전문 영역이었던 기술적 난이도가 낮아졌습니다. * 이미 실무에서는 직무에 구애받지 않고 브랜드 디자이너가 제품을 디자인하거나, 그래픽 디자이너가 시스템을 구축하는 등 '경계를 넘는 디자이너'들이 등장하고 있었습니다. * 하드스킬 습득 시간이 단축됨에 따라 디자이너에게 가장 중요한 역량은 도구 숙련도가 아닌, 결과물의 질을 결정하는 '판단력'과 '감각'으로 이동했습니다. **통합된 두 가지 핵심 직무** * **Product Designer**: 기존의 제품 디자이너와 툴즈 제품 디자이너를 통합하여, 모바일과 PC라는 화면 구분을 없앴습니다. 사용자의 맥락과 문제를 발견하고 해결책을 설계하는 본질에 집중합니다. * **Visual Designer**: 플랫폼, 인터랙션, 그래픽, 브랜드 디자이너를 통합했습니다. 특정 매체에 국한되지 않고 "무엇이 아름답고 올바른 시각적 판단인가"를 고민하며, 필요에 따라 아이콘 제작부터 인터랙티브 웹까지 직접 수행하는 조형 전문가를 지향합니다. **산업 전반에서 나타나는 역할 수렴 현상** * 디즈니 애니메이션이 복잡한 물리적 공정을 소프트웨어로 대체하고 기획 중심의 구조로 바뀐 것처럼, 디자인 역시 도구 중심에서 판단 중심으로 진화하고 있습니다. * 음악 산업에서 DAW(디지털 오디오 워크스테이션)의 등장으로 작곡과 엔지니어링의 경계가 사라진 사례처럼, 도구가 하나로 모이면 역할도 자연스럽게 하나로 흐려집니다. * 영화와 TV 연출의 경계가 디지털 시네마 등장 이후 사라진 것과 마찬가지로, 디자인 매체의 통합은 거스를 수 없는 흐름입니다. **디자이너를 위한 실용적인 제언** 이제 디자이너는 특정 툴의 숙련도에 안주하기보다, 자신이 만드는 결과물이 사용자에게 어떤 가치를 전달하는지 '판단하는 힘'을 길러야 합니다. 직무의 이름에 스스로를 가두지 않고 문제 해결을 위해 필요한 모든 수단을 자유롭게 활용할 수 있는 역량을 갖추는 것이 중요합니다. 토스의 사례처럼 조직 차원에서도 디자이너가 더 넓은 범위에서 사고할 수 있도록 제도적 제약을 제거해 나가는 변화가 필요할 것입니다.

97% 더 작고 2배 더 빠르게: es-toolkit이 주간 다운로드 1,000만 건을 달성한 방법 (새 탭에서 열림)

es-toolkit은 lodash를 대체하기 위해 토스(Toss)에서 처음부터 다시 설계한 현대적인 JavaScript 유틸리티 라이브러리입니다. 최신 웹 표준인 ES Modules와 TypeScript를 기반으로 제작되어 lodash 대비 번들 크기는 최대 97% 줄이고 실행 속도는 2배 이상 높였습니다. 현재 마이크로소프트, IBM 등 글로벌 기업들이 도입하며 주간 1,000만 회 이상의 다운로드를 기록하는 등 차세대 표준 유틸리티로 자리 잡고 있습니다. ### lodash의 한계와 탄생 배경 * **구식 아키텍처:** lodash는 10년 전 JavaScript 환경에 맞춰 설계되어, 최신 웹의 표준인 ES Modules 기반의 트리 셰이킹(Tree-shaking)을 완벽히 활용하지 못합니다. * **불필요한 의존성:** lodash는 단일 함수를 임포트하더라도 내부적인 헬퍼 함수들이 함께 포함되어 번들 크기가 커지는 구조적 한계를 가집니다. * **현대적 엔진 최적화 미비:** V8이나 SpiderMonkey와 같은 현대적 엔진은 과거에 느렸던 패턴들을 최적화했지만, lodash는 하위 호환성 문제로 이러한 최신 성능 이점을 충분히 누리지 못합니다. ### 독보적인 번들 사이즈와 실행 성능 * **완전한 독립성:** 모든 함수가 처음부터 독립적으로 설계되어 숨겨진 내부 의존성이 없습니다. 예를 들어 주요 함수 5개를 사용할 때 lodash는 약 30KB를 차지하지만, es-toolkit은 1KB에 불과합니다. * **런타임 최적화:** 현대 JavaScript 엔진에 최적화된 패턴을 적용하여 대부분의 함수가 2배 이상 빠르며, 특정 함수(`omit`)의 경우 11배 이상의 성능 향상을 보여줍니다. * **실질적 절감 효과:** `sample` 함수의 경우 lodash 대비 번들 크기를 96%까지 줄이는 등, 실제 프로젝트의 Core Web Vitals 지표 개선에 직접적인 도움을 줍니다. ### TypeScript 우선 설계 및 호환성 * **정밀한 타입 추론:** 별도의 `@types` 패키지 없이 소스 코드와 타입 정의가 함께 제공되어 타입 정확도가 매우 높고, 복잡한 타입도 정확히 추론합니다. * **드롭인 교체 지원:** `es-toolkit/compat` 레이어를 통해 lodash와 100% 호환성을 보장합니다. 이는 Storybook, Recharts 등 대규모 오픈소스 프로젝트의 성공적인 마이그레이션으로 검증되었습니다. * **활발한 생태계:** 토스 프런트엔드 챕터의 오픈소스 위원회가 주도하며, `overlay-kit`, `use-funnel` 등과 함께 지속적으로 관리되고 업데이트됩니다. ### 손쉬운 마이그레이션 방법 * **단축 경로:** `package.json`의 의존성 설정에서 `lodash`를 `npm:es-toolkit`으로 별칭(alias) 지정하는 것만으로 코드 수정 없이 즉시 성능 이점을 얻을 수 있습니다. * **점진적 전환:** 단순한 임포트 경로 변경만으로도 도입이 가능하며, 대규모 코드베이스를 위해 공식 codemod 도구(`@es-toolkit/codemod`)를 제공하여 전환 비용을 최소화합니다. 번들 크기 최적화와 런타임 성능이 중요한 현대 프런트엔드 환경에서 lodash를 유지할 이유는 점차 사라지고 있습니다. 단 5분의 투자로 `package.json` 설정을 변경하여 즉각적인 성능 향상을 경험해 보길 권장하며, 특히 TypeScript를 활발히 사용하는 프로젝트라면 타입 안전성 측면에서도 es-toolkit은 최선의 선택이 될 것입니다.

Metric Review, 실행을 이끌다 (새 탭에서 열림)

토스플레이스는 데이터 분석이 실질적인 제품 성장과 사업적 변화로 이어지지 못하는 문제를 해결하기 위해 '메트릭 리뷰(Metric Review)'를 도입했습니다. 메트릭 리뷰는 데이터 분석가가 단순한 리포트 작성자를 넘어 '메트릭 오너(Metric Owner)'로서 조직의 목표와 정렬된 지표를 관리하고, 가설 검증과 실행을 독려하는 핵심 운영 체계입니다. 이를 통해 전사 구성원이 데이터 리터러시를 갖추고 "어떤 지표를 움직일 것인가"를 고민하며 의사결정하는 구조를 확립했습니다. **메트릭 리뷰의 운영 원칙과 분석 사이클** * **OKR 기반의 메트릭 하이어라키(Metric Hierarchy):** 전사 목표인 Key Result를 각 팀의 하위 지표인 드라이버 메트릭(Driver Metric)으로 세분화하여, 무엇이 위협 요소이고 기회인지를 명확히 파악합니다. * **주간 단위의 분석 리듬:** 매주 지표를 검토함으로써 월간 단위로는 놓치기 쉬운 이상 신호를 조기에 포착하고, 수치 변화의 원인을 파고드는 과정에서 데이터 분석가의 도메인 지식을 강화합니다. * **실행으로 연결되는 분석 루프:** 단순 현황 공유에 그치지 않고 '지표 분석 → 가설 검증 → 인사이트 제시 → 실행 독려' 순으로 이어지는 사이클을 반복하며, 탐색적 데이터 분석(EDA)을 통해 도출된 가설을 실제 액션 아이템으로 전환합니다. **실제 사례로 증명된 메트릭 기반의 변화** * **전사 협업 구조 최적화 (Growth Tribe):** 지표를 중심으로 디자이너는 로그 설계 방향을 제안하고, 개발자는 분석에 용이한 서버 테이블 구조를 설계하는 등 전 직군이 목표 지표 달성을 위한 유기적인 협업 체계를 구축했습니다. * **군집 분석을 통한 맞춤형 전략 (POS Tribe):** 대리점별 확산 편차를 해결하기 위해 군집 분석을 수행하고, 설치 비율이 낮은 군집에는 온보딩 강화를, 높은 군집에는 사용성 개선을 제안하는 등 데이터 기반의 정교한 처방을 실행했습니다. * **예측 기반의 공급망 관리 (SCM):** 단말기 출고 및 설치 현황을 모니터링하여 재고 및 발주를 예측함으로써, 유통 구조의 최적화와 비용 절감이라는 실질적인 사업적 성과를 거두었습니다. **데이터 분석가가 지향해야 할 실무 방향** * 화려한 분석 기법보다는 '실행으로 연결되는 분석'에 가치를 두고, 문제를 구조화하며 가설을 검증 가능한 형태로 만드는 것이 중요합니다. * 데이터 분석가는 단순 지원 조직이 아니라 제품과 사업의 임팩트에 집중하는 주체로서, 액션 이후의 검증 지표까지 끝까지 추적하는 책무를 가져야 합니다. * 조직의 언어를 "무엇을 만들까"에서 "어떤 지표를 변화시킬까"로 바꾸는 것이 데이터 리터러시 향상의 본질이며, 이는 꾸준한 메트릭 리뷰를 통해 완성됩니다.

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

AI 기술의 비약적인 발전으로 취약점 분석 자동화가 새로운 국면을 맞이한 가운데, 대규모 소스코드를 효율적으로 분석하기 위한 구체적인 기술적 구현 방법과 보안 관점의 변화가 필요합니다. 본 글은 MCP(Model Context Protocol)를 통한 정밀한 코드 탐색과 SAST 도구를 활용한 분석 후보군 추출을 결합하여 분석의 일관성과 정확도를 높인 사례를 제시합니다. 결과적으로 AI가 단순한 보조 도구를 넘어 복합적인 추론을 수행하는 능동적인 보안 분석 주체로 진화하고 있음을 강조합니다. **MCP를 활용한 효율적인 소스코드 탐색** * 기존의 단순 패턴 매칭 방식은 불필요한 탐색으로 토큰을 낭비하거나 정확한 정의를 찾지 못하는 한계가 있어, 이를 개선하기 위해 ctags와 tree-sitter를 결합한 MCP 서버를 구축했습니다. * AI에게 IDE의 'Go to Definition'과 유사한 능력을 부여하기 위해 `find_references`(참조 검색), `read_definition`(심볼 정의 및 함수 범위 감지), `read_source`(주변 코드 읽기), `get_project_structure`(전체 구조 파악) 등 4가지 핵심 도구를 구현했습니다. * 이 시스템은 AI가 원격 서버 환경에서도 프로젝트의 전체적인 청사진을 이해하고, 분석이 필요한 코드의 맥락을 정확하게 짚어낼 수 있도록 돕습니다. **SAST와 AI의 결합을 통한 분석 범위 확장** * 분석의 일관성을 확보하기 위해 SAST(Semgrep 등)를 취약점 탐지용이 아닌, AI가 반드시 검토해야 할 '모든 입력 경로(Taint Path)'를 추출하는 보조 도구로 활용했습니다. * Spring 프레임워크의 @RequestParam, @RequestBody 등 모든 입력 지점(Source)에서 함수 호출(Sink)까지의 도달 경로를 추출하는 규칙을 설정하여 분석 후보군을 빠짐없이 확보했습니다. * 취약점 유무를 판단하기 어려운 복잡한 비즈니스 로직이나 보안 필터링의 유효성을 AI가 직접 검토하게 함으로써, 기존 정적 분석 도구의 한계를 AI의 문맥 이해 능력으로 보완했습니다. **체계적인 추론 과정(CoT) 설계** * AI가 분석을 시작하기 전 '계획 수립 - 도구 실행 - 검증 - 결과 분석'의 단계를 거치도록 Chain of Thought(CoT) 방식을 적용하여 분석 결과의 신뢰도를 높였습니다. * 단순히 코드를 단편적으로 보는 것이 아니라, MCP 도구를 활용해 연관된 코드와 비즈니스 로직을 충분히 탐색한 후 최종 판단을 내리도록 설계하여 오탐(False Positive)을 획기적으로 줄였습니다. * 이러한 구조화된 추론 과정을 통해 AI는 10개의 취약점 중 일부만 찾는 불완전한 분석에서 벗어나, 정해진 후보군 전체를 일관성 있게 전수 조사할 수 있게 되었습니다. **보안 패러다임의 전환** 현재의 AI는 단순한 챗봇을 넘어 보안 전문가의 사고 과정을 모사하는 에이전트로 진화하고 있습니다. 보안 담당자는 이제 AI에게 효율적인 코드 탐색 도구(MCP)를 제공하고 정밀한 분석 경로(SAST 활용)를 설계해 주는 'AI 오케스트레이터'로서의 역할을 고민해야 합니다. AI가 가진 강력한 추론 능력을 신뢰하되, 이를 올바른 방향으로 이끌 수 있는 환경을 구축하는 것이 보안 자동화의 핵심입니다.

소프트웨어 3.0 시대를 맞이하며 (새 탭에서 열림)

소프트웨어 개발은 명시적 코딩(1.0)과 데이터 기반 학습(2.0)을 거쳐, 자연어 프롬프트가 프로그램이 되는 '소프트웨어 3.0' 시대로 진입하고 있습니다. 하지만 강력한 LLM 모델이라도 실질적인 업무를 수행하기 위해서는 모델의 능력을 제어하고 연결하는 '하네스(Harness)'라는 도구적 환경이 필수적이며, 이를 설계하는 데 있어 기존 소프트웨어 1.0의 계층형 아키텍처 원칙은 여전히 유효한 가이드가 됩니다. 결국 미래의 개발은 전통적인 설계 원칙을 유지하면서도, 에이전트가 인간과 소통하며 의사결정을 내리는 'Human-in-the-Loop(HITL)' 모델을 결합하는 방향으로 진화할 것입니다. **소프트웨어 3.0과 하네스의 필요성** - 안드레 카파시는 소프트웨어 3.0을 자연어로 된 프롬프트가 코드를 대신하는 시대로 정의하며, 이것이 이전 세대의 패러다임을 흡수할 것이라고 예측했습니다. - 하지만 LLM 단독으로는 코드베이스를 읽거나 데이터베이스에 접근하는 등의 실질적인 작업을 수행할 수 없다는 한계가 있습니다. - 이를 해결하기 위해 등장한 것이 '하네스(Harness)' 개념으로, 앤스로픽의 'Claude Code'처럼 모델이 도구(Skills)를 사용하고 외부와 통신하며 에이전트로 동작하게 만드는 실행 환경을 의미합니다. **계층형 아키텍처로 매핑한 에이전트 구조** - **슬래시 커맨드(Slash Command) = 컨트롤러(Controller):** `/review`, `/refactor`와 같은 명령어는 사용자 요청을 받아 적절한 워크플로우를 실행하는 서비스의 진입점 역할을 합니다. - **서브 에이전트(Sub-agent) = 서비스 계층(Service Layer):** 여러 기술(Skills)을 조합해 특정 비즈니스 로직을 완수하며, 독립적인 컨텍스트를 유지하는 단위입니다. - **기술(Skills) = 도메인 컴포넌트:** 단일 책임 원칙(SRP)에 따라 코드 리뷰, 테스트 생성 등 명확한 한 가지 기능만 수행하는 가장 작은 단위의 기능 모듈입니다. - **MCP(Model Context Protocol) = 인프라/어댑터:** 외부 API나 DB와의 연결을 추상화하여 내부 로직이 외부 시스템의 구현 상세를 몰라도 동작하게 돕습니다. - **CLAUDE.md = 프로젝트 헌장:** 기술 스택, 코딩 컨벤션 등 프로젝트의 변하지 않는 근간 원칙을 정의하며 시스템의 안정성을 보장합니다. **에이전트 설계에서 경계해야 할 안티패턴** - **God Sub-agent:** 하나의 서브 에이전트가 너무 많은 역할과 권한을 가지게 되면 관리 효율이 떨어지므로 적절한 분리가 필요합니다. - **기능 편애(Feature Envy):** 특정 기술이 자신의 역할 범위를 벗어나 다른 기술의 데이터나 프롬프트에 과도하게 의존하는 경우입니다. - **프롬프트 중복:** 동일한 프롬프트 내용이 여러 기술에 중복되어 포함될 경우 유지보수가 어려워지므로 공통화가 필요합니다. **에이전트만의 핵심 차별점: 질문하는 능력(HITL)** - 전통적인 소프트웨어는 예외 상황에서 미리 정의된 에러를 던지지만, 3.0 시대의 에이전트는 `UserAskQuestion` 기술을 통해 모호한 상황에서 사용자에게 직접 질문을 던질 수 있습니다. - 에이전트는 삭제나 배포처럼 되돌리기 어려운 작업, 혹은 여러 대안 중 선택이 필요한 고위험 상황에서 인간의 판단을 구하는 'Human-in-the-Loop' 구조를 가집니다. - 반면, 관습적으로 처리 가능한 일이나 안전한 반복 작업은 질문 없이 자율적으로 수행함으로써 효율성과 안정성 사이의 균형을 맞춥니다. 소프트웨어 3.0 시대에 적응하기 위해서는 모든 로직을 명시적으로 작성하려는 강박에서 벗어나야 합니다. 대신 계층 분리, 추상화, 단일 책임 원칙과 같은 전통적인 소프트웨어 공학의 정수를 에이전트 설계에 투영하여, LLM을 단순한 자동완성 도구가 아닌 신뢰할 수 있는 협력자로 구축하는 능력이 핵심 경쟁력이 될 것입니다.

외국인 유저 리서치: 캐나다인 "B"씨는 왜 토스 인증에 실패했을까 (새 탭에서 열림)

토스는 '모두를 위한 금융'이라는 비전을 실현하기 위해 외국인 사용자가 국내 금융 앱 가입 과정에서 겪는 본인 인증 실패 원인을 심층 분석했습니다. 산업단지와 다문화 센터를 직접 찾아가 진행한 리서치를 통해 이름 입력 포맷의 불일치와 주소 검색의 어려움이 핵심 이탈 요인임을 확인했습니다. 이를 바탕으로 인증 로직과 UI를 개선한 결과, 외국인 사용자의 인증 통과율을 약 15% 끌어올리며 내국인 수준의 서비스 접근성을 확보했습니다. ### 현장 리서치를 통한 사용자 페인 포인트 발굴 * 정보 접근성이 상대적으로 낮은 블루칼라 외국인 노동자들의 금융 생활을 파헤치기 위해 시화공단과 포천 다문화 센터 등에서 현장 인터뷰를 수행했습니다. * 외국인들이 모바일 앱 대신 오프라인 은행 창구를 선호하는 이유가 단순한 선호도가 아닌, 가입 단계부터 발생하는 기술적 허들 때문임을 파악했습니다. * 정형화된 설문조사 대신 친근한 방식의 길거리 인터뷰와 심층 인터뷰를 병행하여, 실제 사용자가 겪는 맥락적인 어려움을 수집했습니다. ### 본인 인증의 최대 걸림돌: 이름 입력 방식 * 외국인 등록증상의 이름과 통신사, 은행 등에 등록된 이름의 포맷(성·이름 순서, 띄어쓰기 등)이 서로 달라 본인 인증에 반복적으로 실패하는 문제가 가장 컸습니다. * 'BRAD PITT'를 'BR AD'로 띄어 써야 인증이 되는 등, 시스템마다 요구하는 형식이 달라 사용자가 스스로 성공 케이스를 학습해야 하는 불합리한 상황이 발생했습니다. * 인증 실패 시 구체적인 원인 안내가 부족하고, 5회 오류 시 시도가 차단되는 정책은 외국인 사용자들을 8년 넘게 온라인 인증에서 소외시키기도 했습니다. ### 한국어 주소 입력 및 검색의 난관 * 한국어 타이핑이 서툰 외국인들에게 주소 입력은 가입을 포기하게 만드는 주요 허들이었습니다. * 영문 주소나 우편번호로 검색하더라도 검색 결과 리스트가 너무 방대하여, 본인의 정확한 거주지를 스크롤 내에서 찾아내기가 매우 어려웠습니다. * 입력 방식의 반복된 시도에도 불구하고 원하는 결과를 얻지 못해 결국 서비스 이용 자체를 중도에 포기하는 이탈 구간이 발생했습니다. ### 리서치 기반의 개선 성과 * 유저리서치 결과를 바탕으로 담당 팀에서 이름 입력 구조를 유연하게 변경하고 인증 절차 전반을 고도화했습니다. * 개선 이후 외국인 사용자의 인증 퍼널 통과율이 15% 상승하는 가시적인 성과를 거두었습니다. * 현재는 외국인과 내국인 간의 인증 통과율 격차가 거의 해소되었으며, 디지털 금융 소외 계층을 위한 장벽을 낮추는 기술적 기틀을 마련했습니다. 디지털 금융 서비스에서 외국인 사용자의 접근성을 높이려면 단순한 번역을 넘어, 국내 인증 체계(통신사, 실명확인 기관)와 사용자 입력 데이터 간의 '포맷 불일치' 문제를 기술적으로 해결하는 것이 필수적입니다. 사용자가 직접 시스템에 맞추게 하는 것이 아니라, 시스템이 다양한 케이스를 수용할 수 있도록 설계를 개선하는 것이 진정한 금융 포용의 시작입니다.

인턴에서 1인 디자이너로: 뾰족한 가설이 만든 성장 (새 탭에서 열림)

토스뱅크의 신입 디자이너가 비회원 가입 전환율을 높이기 위해 수행한 실험 설계 과정은 데이터 분석과 가설 검증의 유기적인 반복을 통해 정교해집니다. 실험의 성공 여부보다 중요한 것은 '왜'라는 질문을 바탕으로 선명한 가설을 세우는 것이며, 과거의 실험 데이터를 구조적으로 분석하여 승패의 패턴을 학습하는 것이 성장의 핵심입니다. 결국 명확한 문제 정의와 사용자 맥락을 반영한 작은 개선들이 모여 제품의 유의미한 비즈니스 임팩트를 만들어냅니다. **속도와 임팩트 중심의 우선순위 설정** * 비회원 가입 퍼널 중 이탈이 발생하는 인트로, 동의 화면, 신분증 인증 단계를 데이터로 분석했습니다. * 리걸(Legal) 및 컴플라이언스 검토가 필요한 공통 모듈 영역보다는, 수정이 자유롭고 첫 유입에 직접적인 영향을 주는 '인트로 화면'을 실험 대상으로 선정했습니다. * 즉각적인 반복 실험이 가능한 '속도'와 전체 전환율에 기여하는 '임팩트'를 기준으로 리소스를 배분하는 효율적인 접근 방식을 택했습니다. **과거 실험 데이터를 통한 위닝 패턴 학습** * 단순히 새로운 시안을 만드는 데 집중하기보다, 기존에 진행된 수많은 실험의 가설 구조와 문제 정의 방식을 먼저 분석했습니다. * 특정 시안의 승패 결과 자체보다는 어떤 맥락에서 해당 가설이 세워졌는지 '이유'에 집중하여 실패와 성공의 패턴을 흡수했습니다. * 실험 경험이 부족할수록 아이디어를 내는 시간보다 기존의 러닝(Learning)을 구조적으로 읽고 현재 맥락에 적용할 지점을 찾는 시간이 중요함을 확인했습니다. **명확한 가설 수립과 기술적 최적화** * 첫 실험의 실패를 통해 가설이 모호하거나 사용자 맥락을 놓치면 결과 분석이 어렵다는 점을 깨닫고, 한 번에 하나의 변수만 검증하는 원칙을 세웠습니다. * 사용자 반응이 좋았던 '고금리', '매일 이자 받기' 등의 키워드를 문구에 반영하고, 저사양 기기에서도 원활하도록 이미지 로딩 속도를 최적화(저용량 확장자 사용 등)하여 실제 전환율 상승을 이끌어냈습니다. * 기능 설명 중심의 문구에서 벗어나 유저가 혜택을 체감하는 장면을 상상하게 만드는 구체적인 표현으로 개선하여 CTR(클릭률)과 CVR(전환율)을 동시에 높였습니다. **신입 디자이너를 위한 실험 설계 제언** * 실험은 단순히 성공을 확인하는 도구가 아니라 다음 선택을 더 명확하게 하기 위한 과정임을 인지해야 합니다. * 거창한 해답을 찾으려 하기보다 퍼널을 세분화하고, 핵심 문제를 정의한 뒤 가설이 선명하게 드러나는 실험안을 설계하는 것이 중요합니다. * 실패한 실험에서도 다음 가설을 위한 힌트를 얻을 수 있도록 가설과 성공 지표를 사전에 정교하게 설정할 것을 권장합니다.

Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기 (새 탭에서 열림)

현재 많은 개발팀이 LLM을 도입하고 있지만, 실제 생산성은 엔지니어 개개인의 'LLM 리터러시'에 따라 극심한 격차를 보이고 있습니다. 이러한 '각자도생'의 한계를 극복하기 위해서는 LLM을 개인의 도구가 아닌 팀 차원의 시스템으로 편입시켜 전체적인 생산성의 저점(Floor)을 높이는 전략이 필요합니다. Claude Code와 같은 생태계를 활용해 팀의 노하우를 '실행 가능한 지식(Executable SSOT)'으로 자산화하는 것이 Software 3.0 시대의 핵심 경쟁력이 될 것입니다. **컨텍스트 엔지니어링과 LLM 리터러시의 격차** * 단순 질문을 반복하는 방식과 작업 전 팀의 가이드라인, 린트 규칙, 코드 패턴 등 '컨텍스트'를 먼저 주입하는 방식은 결과물에서 큰 차이를 만듭니다. * 이러한 생산성 격차는 코딩 실력이 아닌 LLM을 제어하는 노하우의 차이이며, 이를 개인의 센스에만 맡기는 것은 조직적 손실입니다. * 팀 전체의 역량을 상향 평준화하기 위해서는 누구나 최적의 맥락 위에서 작업할 수 있도록 돕는 시스템적 장치(Harness)가 필요합니다. **Claude Code와 마찰 없는 워크플로우 이식** * 브라우저 기반 챗봇으로 코드를 복사·붙여넣기 하는 과정에서 발생하는 문맥 교환(Context Switching) 비용을 최소화해야 합니다. * Claude Code가 제공하는 TUI(Terminal User Interface) 환경은 터미널 안에서 자연어와 코드가 끊김 없이 섞이는 매끄러운 경험을 제공합니다. * 이러한 낮은 진입 장벽은 설계된 AI 워크플로우를 팀원들에게 저항감 없이 전파할 수 있는 기반이 됩니다. **실행 가능한 진실의 원천(Executable SSOT)** * 기존의 위키나 노션 문서는 작성 즉시 낡은 정보가 되지만, 플러그인 형태의 지식은 사람이 읽는 매뉴얼인 동시에 LLM이 즉시 실행하는 시스템 프롬프트가 됩니다. * RAG(검색 증강 생성) 방식은 내부 로직의 불투명성으로 인해 어떤 컨텍스트가 주입될지 예측하기 어렵다는 단점이 있습니다. * 반면 플러그인 방식은 명시적인 코드로서 개발자가 주입되는 맥락을 100% 통제할 수 있어 높은 예측 가능성과 신뢰성을 제공합니다. **계층화된 아키텍처를 통한 거버넌스와 전파** * 지식을 전사 공통(Global), 팀/비즈니스 도메인(Domain), 특정 프로젝트(Local)의 3단계 레이어로 계층화하여 관리함으로써 지식의 파편화를 방지합니다. * `/new-feature`와 같은 슬래시 커맨드를 통해 숙련된 엔지니어의 노하우(이슈 발급, 브랜치 생성, 구현 계획 수립 등)를 모든 팀원에게 즉시 배포할 수 있습니다. * 단순한 린터를 넘어, 메인 브랜치 커밋 시도를 감지하고 정책에 맞는 브랜치 생성을 가이드하는 등 AI 에이전트 기반의 강력한 거버넌스 구현이 가능합니다. **엔지니어링의 본질: 플랫폼 엔지니어링과 데이터 플라이휠** * Software 1.0 시대에 공통 라이브러리로 중복 작업을 줄였듯, Software 3.0에서는 AI 워크플로우 플러그인을 통해 팀의 생산성을 최적화해야 합니다. * 규격화된 플러그인을 통해 축적된 양질의 데이터는 향후 도메인 특화 모델(sLLM)을 파인튜닝하고 평가하는 기반이 됩니다. * 사용자가 많아질수록 데이터가 쌓이고 모델이 정교해지는 '데이터 플라이휠' 구조를 구축하는 것이 AI-Native 조직의 최종 목표입니다. 이제 LLM 활용 능력은 개인의 역량을 넘어 팀이 설계하고 배포해야 할 시스템의 영역입니다. Claude Code의 마켓플레이스와 같은 도구를 활용해 팀 내에 흩어진 암묵지를 명시적인 워크플로우로 엮어내고, 우리 조직에 최적화된 '시스템 하네스'를 구축하는 것부터 시작해 보기를 추천합니다.