토스

72 개의 포스트

toss.tech

태그로 필터

toss원문

양자컴퓨터 시대에 대비한 양자내성암호 적용, 왜 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 팀의 유기적 협업이 성공의 열쇠였습니다. * **민간 보안 선도:** 정부의 '양자내성암호 전환 마스터플랜'에 발맞추어 민간 결제 생태계에서 선제적으로 기술 실증을 완료하여 결제 보안의 새로운 표준을 제시했습니다. 결제 서비스의 보안은 단순히 서버 설정을 바꾸는 기술적 작업을 넘어, 연결된 수많은 파트너와 함께 호흡하며 신뢰를 쌓아가는 과정입니다. 미래의 보안 위협은 이미 시작되었기에, 가맹점 환경을 배려하면서도 선제적으로 암호 체계를 전환하는 결단이 지속 가능한 비즈니스를 위한 필수 조건입니다.

toss원문

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)를 시스템의 최상위 데이터 원천으로 관리하는 원칙을 지킬 때 장애 복구와 데이터 정합성 유지가 훨씬 용이해집니다.

toss원문

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

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

toss원문

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시간 동안 직접 선물을 배치하여, "일 년 더 다닐 이유가 생겼다"는 정서적 반응을 이끌어냈습니다. **인터널 브랜딩 프로젝트를 위한 체크리스트** - 프로젝트의 존재 이유를 한 문장으로 설명할 수 있는가? - 시각적 레퍼런스를 찾기 전, 결과물이 충족해야 할 조건을 먼저 정의했는가? - 첫 대면부터 마지막 순간까지의 경험 흐름을 통째로 설계했는가? - 타협의 유혹이 올 때 돌아갈 명확한 기준이 있는가? - 이 결과물이 구성원에게 "이 팀과 함께하고 싶다"는 감정을 불러일으키는가?

toss원문

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

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

toss원문

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은 최선의 선택이 될 것입니다.

toss원문

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

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

toss원문

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가 가진 강력한 추론 능력을 신뢰하되, 이를 올바른 방향으로 이끌 수 있는 환경을 구축하는 것이 보안 자동화의 핵심입니다.

toss원문

소프트웨어 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을 단순한 자동완성 도구가 아닌 신뢰할 수 있는 협력자로 구축하는 능력이 핵심 경쟁력이 될 것입니다.

toss원문

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

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

toss원문

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

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

toss원문

쓰기 쉬운 Toss Front SDK (새 탭에서 열림)

좋은 SDK는 단순히 기능을 제공하는 것을 넘어, 사용자가 올바른 방법으로만 사용하도록 유도하고 휴먼 에러를 구조적으로 방지해야 합니다. 이를 위해 복잡한 내부 로직을 사용자의 ‘의도’를 중심으로 추상화하는 퍼사드(Facade) 패턴을 적용하여, 사용자가 최소한의 코드로도 안정적인 결과물을 만들 수 있는 환경을 구축해야 합니다. 고수준 인터페이스를 통해 대다수의 유즈케이스를 해결하면서도, 특수한 상황을 위한 저수준 인터페이스라는 ‘탈출구’를 마련하는 것이 설계의 핵심입니다. ### 의도 기반의 퍼사드(Facade) 패턴 재정의 - 퍼사드 패턴의 본질은 단순히 복잡한 기능을 숨기는 것이 아니라, 내부 구현을 ‘사용자의 의도(Intent)’를 기준으로 재구성하는 데 있습니다. - "서버를 열고, 핸들러를 등록하고, 에러를 처리한다"는 개별적인 절차를 "서버를 시작한다"는 하나의 자연스러운 목적으로 통합합니다. - 인증, 재시도 로직, 상태 관리, 클린업(Cleanup) 등 인지 부하를 일으키는 요소들을 SDK 내부로 은닉하여 사용자 측의 실수를 원천 차단합니다. ### AWS CDK 사례를 통한 추상화 계층의 이해 - AWS CDK의 L1 구문은 리소스의 모든 속성을 제어하는 저수준(low-level) 인터페이스인 반면, L2 구문은 직관적인 의도 기반의 고수준(high-level) 추상화를 제공합니다. - S3 버킷 생성 시 L1은 모든 세부 설정을 직접 챙겨야 하지만, L2는 자주 쓰이는 옵션을 간단한 프로퍼티로 제공하고 내부적인 변환은 SDK가 담당합니다. - SDK 설계 시에도 이와 같이 복잡한 주변 구성을 자연스러운 API 흐름으로 이어 붙일 수 있도록 설계해야 합니다. ### 파레토 법칙을 적용한 인터페이스 설계 - 전체 사용 사례의 80%에 해당하는 공통 유즈케이스는 고수준 인터페이스(Facade)를 통해 워크플로우를 자동화하여 제공합니다. - 나머지 20%의 특수한 요구사항이나 세밀한 제어가 필요한 상황을 위해 저수준 API인 ‘탈출구(Escape Hatch)’를 함께 유지합니다. - 이러한 이중 구조는 단기적인 개발자 경험(DX) 향상뿐만 아니라, SDK의 장기적인 호환성과 확장성을 보장하는 핵심 전략이 됩니다. ### 편의성과 유연성 사이의 트레이드오프 관리 - 추상화 수준이 높아지면 사용자는 편리해지지만, SDK 내부에서는 더 정교한 오케스트레이션 로직을 관리해야 하는 유지보수 비용이 발생합니다. - 세밀한 제어가 차단될 경우 특정 상황에서 제약이 될 수 있으므로, 고수준 인터페이스에만 의존하지 않고 저수준 조작이 가능한 균형점을 찾는 것이 중요합니다. - 결과적으로 잘 설계된 인터페이스는 사용자가 별도의 가이드 없이도 올바른 패턴을 유지하며 메모리 누수와 같은 장애 상황을 방지하게 합니다. 단순히 "동작하는" SDK를 만드는 단계를 넘어, 사용자가 직관적으로 이해하고 안전하게 사용할 수 있는 "쓰기 쉬운" SDK를 지향해야 합니다. 이를 위해 사용자의 의도를 최우선으로 고려한 추상화 계층을 설계하고, 대다수의 편의성과 소수의 유연성을 동시에 잡을 수 있는 다층적 구조를 도입할 것을 권장합니다.

toss원문

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의 마켓플레이스와 같은 도구를 활용해 팀 내에 흩어진 암묵지를 명시적인 워크플로우로 엮어내고, 우리 조직에 최적화된 '시스템 하네스'를 구축하는 것부터 시작해 보기를 추천합니다.

toss원문

경계 보안부터 제로트러스트 보안까지, 고도화 여정 (새 탭에서 열림)

토스페이먼츠는 기존의 단일 방어선 중심의 열악한 보안 환경을 극복하고, 지난 4년간 IDC와 AWS를 아우르는 하이브리드 환경에서 체계적인 다층 방어(Defense in Depth) 체계를 구축했습니다. 암호화 트래픽 가시성 확보부터 컨테이너 런타임 보안까지 단계별 방어 전략을 수립하여, 외부 공격 차단은 물론 내부 침투와 이상 행위까지 실시간으로 탐지하고 대응할 수 있는 고도화된 보안 기틀을 마련했습니다. ### 경계보안 고도화 및 하이브리드 체계 구축 * **암호화 트래픽 가시성 확보**: HTTPS로 암호화된 트래픽 속에 숨겨진 악성 페이로드를 탐지하기 위해 SSL/TLS 복호화 기능을 전면 도입하여 보안 사각지대를 해소했습니다. * **하이브리드 보안 아키텍처**: IDC에는 DDoS 방어, SSL 복호화, IPS/WAF 이중 보안을 배치하고, AWS에는 AWS WAF와 GuardDuty를 활용한 AI 기반 위협 탐지 체계를 구축했습니다. * **가맹점 협력적 대응**: 가맹점을 통한 악성 트래픽 유입 시 단순히 차단하는 데 그치지 않고, 공격 유형과 조치 가이드를 포함한 상세 안내를 통해 가맹점과 함께 보안 수준을 높이는 생태계를 조성했습니다. ### 서버단 내부망 보안 및 측면 이동 방어 * **Wazuh 통합 모니터링(IDC)**: 오픈소스 보안 플랫폼인 Wazuh를 도입하여 서버 간 측면 이동(Lateral Movement) 공격을 감시하고, 여러 OS의 시스템 및 인증 로그를 중앙에서 통합 관리합니다. * **지능형 위협 탐지(AWS)**: GuardDuty의 Malware Protection을 활용해 EC2 인스턴스의 악성코드를 스캔하고, 일반 계정의 루트 권한 획득(Privilege Escalation)과 같은 이상 징후를 실시간으로 포착합니다. * **실시간 알림 및 화이트리스트**: 서버 내 이상 행위에 대한 실시간 알림 체계를 구축하고, 화이트리스트 기반의 예외 관리를 통해 탐지 효율성을 극대화했습니다. ### 컨테이너 런타임 보안과 최후의 방어선 * **Falco 기반 실시간 감시**: 빠르게 변하는 컨테이너 환경을 보호하기 위해 CNCF 오픈소스 도구인 Falco를 도입, 시스템 호출(Syscall)을 실시간으로 분석하여 비정상적인 행동을 탐지합니다. * **런타임 위협 식별**: 컨테이너 내부에서의 민감 파일(`/etc/shadow` 등) 접근, 신규 바이너리 실행, 컨테이너 탈출 시도 등을 즉각적으로 식별합니다. * **이벤트 전달 체계**: Falco Sidekick을 통합하여 탐지된 보안 이벤트를 실시간으로 관련 시스템에 전달함으로써, 경계 및 서버 보안을 우회한 공격에 대해서도 즉각적인 대응이 가능하도록 설계했습니다. 단순히 외부 침입을 막는 것을 넘어, 내부망의 모든 움직임을 검증하고 가맹점과 보안 가치를 공유하는 다각적인 접근이 현대적인 금융 보안의 핵심입니다. 기술적 솔루션 도입과 더불어 보안 사고 발생 시 파트너사가 자생력을 가질 수 있도록 돕는 협력 모델을 구축하는 것이 지속 가능한 보안 환경을 만드는 실무적인 정답이 될 것입니다.

toss원문

마케팅 문구 클릭률을 올리는 6가지 원칙 (새 탭에서 열림)

사용자를 기만하거나 불안을 자극하지 않는 토스의 엄격한 라이팅 원칙 속에서도 높은 클릭률과 전환율을 달성할 수 있는 구체적인 카피라이팅 전략을 제시합니다. 수백 번의 A/B 테스트를 통해 증명된 이 원칙들은 화려한 수식어보다 사용자의 심리적 장벽을 낮추고 행동의 명확성을 높이는 데 집중합니다. 결국 마케팅 성과는 자극적인 문구가 아니라, 사용자가 지금 당장 무엇을 해야 하고 무엇을 얻을 수 있는지 직관적으로 이해시키는 디테일에서 결정된다는 것이 핵심 결론입니다. ### 단 하나의 핵심 가치에 집중하기 * 여러 장점을 나열하기보다 사용자가 지금 당장 클릭해야 할 단 하나의 이유만 전달할 때 반응이 더 좋습니다. * 복잡한 혜택 설명(예: 신혼부부 지원금 등)을 모두 제거하고 '10문제 찍고 결과 보기'처럼 즉각적인 행동 하나에만 집중했을 때 노출과 클릭률이 10배 이상 상승했습니다. * 긴 설명은 문장을 복잡하게 만들 뿐이며, 구체적인 가치는 클릭 이후의 상세 페이지에서 경험하게 해도 충분합니다. ### 불확실한 대박보다 확실한 보상 약속하기 * 사용자는 '최대 혜택'이라는 막연한 기대보다 소액이라도 '무조건 받을 수 있다'는 확실성에 더 민감하게 반응합니다. * '최대 100만 원'보다 '최소 100원'을 강조했을 때 노출이 20배 더 잘 되었으며, '마음껏 받기'보다 '1장은 무조건 받기'가 더 높은 클릭률을 기록했습니다. * 지나치게 큰 금액은 오히려 광고라는 거부감을 주거나 조건이 까다로울 것이라는 인상을 줄 수 있으므로, 보상의 확실성을 강조하는 것이 유리합니다. ### 심리적 문턱을 낮추는 단어 선택 * 동일한 행동이라도 어떤 단어를 쓰느냐에 따라 사용자가 느끼는 심리적 무게가 달라집니다. * 절차와 서류가 떠오르는 '가입하기' 대신, 금방 끝날 것 같은 느낌을 주는 '준비하기'를 사용해 사용자의 부담을 줄일 수 있습니다. * 사용자가 행동을 완료하기까지 걸리는 시간을 짧게 명시하는 것도 효과적인 방법입니다. ### 정보의 성격과 출처 명시하기 * 혜택을 설명하기 전, 해당 정보가 어떤 성격인지(모음집인지, 신규 소식인지) 먼저 알려주면 신뢰도가 높아집니다. * 상품 하나를 제안하기보다 '대출 목록 모아보기'처럼 정보의 형태를 언급하거나, '새로 나온 혜택'임을 강조했을 때 클릭률이 최대 6배까지 높아졌습니다. * 사용자가 정보를 탐색하기 전에 기대치를 설정해 주는 것이 중요합니다. ### 조건과 행동의 구체적인 수치화 * 사용자는 자신이 수행해야 할 과업의 양을 정확히 알 때 행동에 나설 확률이 높습니다. * 단순히 '미션 도전'이라고 하기보다 '미션 4개', '빈칸 채우기'보다 '8칸 채우기'처럼 숫자를 명시했을 때 전환율이 최대 4배까지 상승했습니다. * 막연함은 고민을 낳고 고민은 이탈로 이어지므로, "얼마나 해야 하지?"라는 의문이 들지 않도록 목표를 명확히 제시해야 합니다. ### 일상의 직관적인 경험 연결 * 화면 속의 동작을 일상에서 자주 하는 익숙한 행동으로 묘사하면 별다른 설명 없이도 이해도를 높일 수 있습니다. * 퀴즈 서비스에서 단순히 '정답 보기'라고 하기보다 손가락으로 가볍게 선택하는 느낌의 '정답 찍기'라는 표현을 사용해 클릭률과 전환율을 모두 높였습니다. * 단어의 뉘앙스에 맞는 이모지(예: 도장 이모티콘)를 활용하면 시각적인 직관성을 더욱 보완할 수 있습니다. --- **실용적 제언** 성과가 나지 않는 마케팅 문구를 수정하고 싶다면, 미사여구를 더하기보다 사용자의 '심리적 비용'을 줄이는 방향으로 접근해보세요. "무엇을 얻는가"만큼이나 "내가 무엇을, 얼마나, 어떻게 해야 하는가"를 친절하고 구체적으로 알려주는 것이 토스가 증명한 가장 강력한 전환의 기술입니다.