미래를 꿈꾸고 성공을 희망하며

Django MVC 프로젝트가 Micro-frontend React 프로젝트로 탈바꿈하는 과정

* 인프라 패키지 : 동일한 빌드 툴링을 공유
* 라이브러리 패키지 : 공통 소스코드를 관리
* 서비스 패키지 : 페이지에서 독립적으로 작동

위의 방식을 통해, 소스와 빌드 설정을 완벽히 격리시키고, 서비스별 의존성 문제를 해결하여 빌드업 시간, 소스 동기화 시간을 해결할 수 있습니다. 

Monolithic에서 MSA전환 사례?

MSA(MicroService Architecture)는 Netflix에서 도입되어 IT에서 많이 화자가 되고 있습니다. 다양한 서비스들이 서로 의존성에 대한 걱정없이 배포하고 운영되는 것에 많은 흥미를 가졌습니다.

하지만, 이미 대규모의 웹, 앱을 안정적으로 운영하는 기업 입장에서 100에 +1, +2를 더하는 것은 쉬우나, 이것을 다시 1+1+1+1...(100번) 하여 재구축하는 것은 전면 재구축이라, 단순 MSA로 전환에 따른 이점이 크지 않아 도입하는게 좋은 선택이 아닐 수 있습니다. 또한, MSA에 대한 충분한 이해없이, 서비스간 의존성을 최소화하면서, 빌드, 분산 배포 계획까지 마련한 사례가 없어 참고자료가 마땅치 않습니다. 

MSA의 대표 사례인 Netflix경우, 서비스가 다양하지 않고, 일부 오류(제안, 검색 화면 등)가 나더라도 크리티컬하지 않지만, 금융거래 또는 개인정보 처리 및 전자서명하는 거래의 경우에는 거래의 무결성을 보장해야 하기에 오히려 부적합할 수도 있습니다. 

토스는 다른 전략을 갖고 개발되는 제품(서비스)들이 다르게 개발될 수 있는 문화가 이미 정착되어 있고, 그런 환경이기에 MSA가 적합해 보입니다. 그래서 제품 전략적으로 독립된 제품들이 기술적으로도 독립할 수 있는 것입니다. 따라, 각자 다른 엔지니어와의 커뮤니케이션을 최소화하여 개발에 집중할 수 있지만, 다른 측면으로는 추후 업무 이관 등 관리적면에서는 또다른 문제가 있을 수 있습니다. 기존 Monolithic 방식의 장점이 이런 관리 운영적인 측면에서 체계적이었기 때문입니다. 

빌드 시간 최소화

전체 소스빌드가 아닌 incremental build를 이용하여 변경된 소스만 빌드하고, 기존 소스는 빌드하지 않고, 그대로 이용하면 됩니다. Eclipse 기반에서는 build는 auto를 설정하면, 기본적으로 지금 수정된 파일만 incremental build를 수행하고, "clean"을 명령해야 전체 소스를 build합니다. 또한, 상용/무료 형상관리 프로그램 역시 두가지 버전(clean, incremental)을 모두 지원하고 있습니다. 

우리가 사용하는 서버의 Java 버전이 변경되는 경우는 매우 드믑니다. 없다고 생각하셔도 좋습니다.

• 전체 소스코드를 rebuild해야 하며, 그과정에서 일부 소스 수정이 필요할 수도 있습니다. 따라 전체 메뉴에 대한 기능 테스트를 수행
• 이용하고 있는 암호화 솔루션, 프린트 솔루션 등 자바 버전이 충돌되어 오작동하는 솔루션이 있는지 미리 체크
• Java 버전 변경의 장점이 매우 적어 버전업을 하지 않지만, 너무 오래된 버전(1.3 등)의 경우에는 신기술 도입을 위해 전면 재개발을 할 때, 신규 서버에 Java 버전을 최신의 안정화 버전으로 Up

Java 버전이 변경되는 경우가 아니라면, 굳이 전체 소스를 build, 배포할 필요가 없으며, 배포할 필요가 없는 소스를 굳이 build할 필요 역시 없습니다. 

요약
• 수평적인 애자일 조직(각자 다른 서비스앱을 개발하는 것이 아니라, 여러팀이 각자 서비스를 단일 앱에 올리는 경우)에 MSA는 좋은 선택
• 변경한 소스만 build : Zero-Build

DB 이중화, DR센터를 구축해야 하나요?

• 금융회사라면 전자금융감독규정을 확인해보세요.
• 인터넷 쇼핑몰이라면 4시간 장애로 인한 판매 중단시 발생하는 손실 금액을 확인해보세요.
• 대기업이라면 회사 홈페이지 마비에 따른 업무 중단 또는 회사 이미지를 생각해보세요.

시스템 HA구성을 얘기할 때, 3tier 구조(WEB Server - Application Server - DBMS 의 구성) 부터 시작합니다. 추가로 L3 또는 L4 같은 네트워크 장비와 WEB 방화벽 등 정보보호 시스템을 붙여 나갑니다. HA 구성은 이중화를 통해 로드 밸런싱외에도 장애 발생시 Fail-Over 기능을 수행합니다. 서버 장비가 2대 이상 구성함에 따라 많은 비용이 발생합니다. 물론 처음부터 100의 능력을 가진 서버가 아닌 50~70의 서버를 2대 이상 구성하는 것이 비용 측면에서는 좋을 선택일 수 있습니다. 

비용   VS  시스템 구성 복잡도, 장애 포인트 증가

DBMS(DataBase Management System)은 보통 유료버전의 경우 RAC, TAC 처럼 단일 Datafile을 이용하는 여러 instance를 이용하는 방법외에도 Master-Slave 방식의 방법도 제공하고 있습니다. 대부분의 웹서비스는 조회와 데이터처리(등록/정정/삭제) 거래량을 비교하면, 조회가 10배 이상이라 생각됩니다. 주식거래를 하다보면, 우리 자산을 하루에도 10번 이상 체크하지만 거래는 자주 하지 않는 것과 같습니다. 

그래서 데이터를 처리하는 Master가 있고, Master의 변동분을 읽어 동기화하는 N개의 Slave가 있습니다.그래서 이렇게 설계해야 데이터 동기화가 꼬이지 않고 Simple해지기 때문입니다. 동기화하는 전문 솔루션을 이용하거나 OS레벨에서 동기화 지원하는 Disk 제품도 있습니다. 이런 구성은 최소 비용으로 데이터의 성능을 올려 HA를 올리는 방법이고, 여기에 Active-Stanby 구성을 추가합니다. 그러면 Active 서버 장애 발생시 모니터링 서버가 인지하여, 자동(수동)으로 동기화된  Stanby서버로 거래가 들어오면서 서비스를 유지할 수 있습니다. 

여기까지가 주센터에서 할 수있는 HA입니다. 

만약 주센터에서 해결할 수 없다고 판단된다면, DR 전환을 수행해야 합니다. 사실상 금융권은 전자금융감독규정에 따라 주기적으로 DR 전환훈련(재해복구 전환훈련) 을 수행하고 있습니다. 그래서 데이터 동기화도 실시간으로 진행되고 있습니다. 물론 이런 경우 추가로 고려해야 할 사항이 있습니다.

• RTO(Recovery Time Objective, 목표 복구 시간) : 업무 중단 시점으로부터 복구되어 가동될 때까지의 소요시간, 장애 발생 후 4시간 이내 복구 가능
• RPO(Recovery Point Objective, 목표 복구 시점) : 비상사태 또는 업무 중단 시점으로부터 데이터를 복구할 수 있는 기준점, 장애 발생 전인 지난 주 목요일에 백업시켜 둔 복원 시점으로 복구 가능 등

금융권외에 다른 권역에서는 백업을 주단위 또는 월단위로 할 수 있기에 복구 시점을 정확히 인지하고, 복구 이후 이후 변경에 대해 대책을 세워야 합니다. 또한, DR 전환이 성공할지라도 DR-주센터가 전환된게 아니기에 다시 안전하게 주센터로 전화해야 한다는 걸 고려해야 합니다. 따라, DR전환은 정말 주센터가 상당 기간 동안 정상화될 수 없다고 판단이 되면 시행해야 합니다. 

DB를 빨리 복구하는 방법

동기화하는 DR센터가 없는 상태에서 DB datafile이 깨진 경우를 대비하여, 거래량이 적어 Datafile의 변경이 적은 매일 새벽마다 Datafile을 복제하는 방법이 있습니다. 오늘이 6월 27일이면, 복제DB는 6월 27일 02시 기준의 자료입니다. 오늘이 6월 28일이면, 복제DB는 6월 28일 02시 기준의 자료가 됩니다. 복제DB는 관리 목적이 당일 02시 기준의 상태로 복구하는 것입니다. 따라 Full Copy할 테이블과 append하여 전일 변경분만 Copy할 테이블을 정리하여 복제하면 됩니다. DBMS에 따라 Datafile을 복제해도 가능합니다. 

물론, 데이터 복구 이후, 복구시점 이후 거래나 변동에 대해 조치를 취해야 합니다. Log파일이나, 다른 매체에 기록된 정보를 활용해서 재거래(Re-transaction)를 할 수 있는 프로그램(솔루션)을 개발해야 합니다. 재거래는 속도가 생명이지만(복구시간), 거래순서가 중요할 경우 적절히 거래를 Divide하여 병렬처리하면 됩니다. 

요약
• 장애 발생에 대한 피해 정도, 법적 의무를 확인하여 비용내에 적절하게 HA 구성
• RTO가 길다면, 월1회에 직접 Datafile을 복제하여 별도 장소에 보관(복구 훈련 필요)
• DR전환은 성공하더라도 주센터로 전환까지 해야 하므로, 주센터 내에서 최대한 복구 대책 마련

https://www.youtube.com/watch?v=t96l6ry_qmw 

성장하는 스타트업은 완벽 보다는 필요한 것부터 차근차근

통계전문가, 빅데이터 전문가의 역할은 무엇일까요? 비즈니스 전문가, IT기획자 또는 개발자가 데이터 항목간의 연관성, 의사결정을 위한 통계, 판매 실적 추이, 특이점 등을 찾아낼 수 있도록 DW 환경을 구축하는 것입니다. 그렇게 하기 위해서 실거래 DB부터, 디멘젼 테이블, ODS, 메타관리, 데이터품질관리 마지막으로 효율적인 협업 시스템을 구축해야 합니다. 

스타트업으로 시작한 토스는 Simplicity21에서 나온 "오직 한사람, 사장님을 위해" 같은 다양한 통계를 활용한 서비스를 기획할 수 있는 큰 규모 DW를 구축할 수 있었습니다. 그들은 6개의 원칙을 갖고 성장할 수 있었습니다. 

DW업무를 처음 접하시는 분들은 토스의 과정을 보시면서, 막연한 DW에 대해 감을 잡으시기 바랍니다. 

DB Review

IT직원이 30명이 넘는 규모의 회사에서도 별도의 DBA를 두지 않고, 개발자가 임의로 테이블을 추가, 수정하면서 데이터의 중복, 비효율적인 Index생성/누락 이 빈번한 회사가 많습니다. 토스는 DBA가 컴플라이언스(개인정보, 암호화, 권한 관리 등)와 데이터 모델, 성능과 안정, 운영 효율성 관점에서 리뷰를 진행하고, 안전하고 효율적인 방법으로 DB 변경 작업을 수행합니다. 운영DB의 품질(중복 최소화, 적절한 Index, 용어 통일, Null값 관리, FK, comment 설 등)이 낮으면, DW의 품질 또한 높을 수 없습니다. 또한 용어 통일이 되지 않으면 커뮤니케이션 오류, 데이터 중복관리 등 불필요한 업무가 계속 발생합니다. 

디멘젼 테이블

차원에 대한 테이블(일별, 월별, 코드별 등 집계 기준)은 자동화를 위한 선제 조건입니다. 주요 행위나 서비스에 대한 정의(d_act_type, d_svc), 각종 수수료 및 매출 계약정보 등을 분류 기준을 만들어 집계시 하드코딩하지 않고 디멘젼 테이블로 관리해야 일관성을 유지할 수 있습니다. 코드명별로 Min, Max값에 따라 코드값으로 값을 적절히 분류하면, ODS 테이블에 적재시 동일한 기준으로 Summary 테이블 생성 가능합니다.

토스는 구글스프레드시트로 Python으로 MySQL 같은 RDB 데이터를 동기화하는 프로그램을 만들어 사용.

* 중견기업 이상, 금융권에서는 DW를 구축하면서 ETL(Extract Transform Load) 프로그램을 통해 설정된 Mapping rule대로 적재하며, 네티짜의 경우 SQL문으로 메모리에서 DB to DB 데이터를 적재(매우 효율적임)

ODS 설계 및 운영

ODS(Operational Data Store)란 집계효율을 위 중간 가동단계의 데이터들의 저장소입니다. 운영시스템의 복잡한 형태를 단순화하거나 표준에 맞지 않는 부분을 전처리 과정(Null값 통일)을 통해 맞추기도 합니다. 또한, 필요에 따라 Summary 테이블로 구성할 수도 있습니다. 

* AARRR : 데이터를 보는 하나의 방법론으로 이용자의 유입에서 매출로 연결되기까지 단계별로 분석하는 방법

이런 공통된 지표들을 윗 단계(Dimension 테이블)에서 정의하여 관리합니다. 그래야 모든 팀에서 공통으로 활용할 수 있습니다. 

행위(공통된 지표)에 대해 정의하였기에 단순한 SQL으로도 다양한 행동들에 대한 상관관계를 쉽게 파악할 수 있습니다. 

이런 모든 일련의 과정을 Sql 스크립트를 작성해서 돌릴 수도 있지만, 토스는 AirFlow를 사용하고 있습니다. 이미 정보계를 구축한 회사에서는 이미 자체적으로 개별 스크립트를 모듈로 작성해서 Diagram을 만들어 운영 중일 것입니다. 

효율적인 협업을 위한 도구

Jenkins를 이용하면 사용방법이 쉬워 비개발자들도 쉽게 배치를 등록할 수 있었으나, 관리가 어려워 체계적인 관리를 할 수 있는 체계를 마련할 필요가 있습니다. 간단하거나 지엽적인 것은 비개발자들에게 허용할 수 있지만, 영향도가 높은 경우에는 IT부와 협의를 통한 관리가 필요합니다. 

통계 프로그램(SQL) 역시 형상관리가 필요하며, 문제 발생시 담당자를 확인할 수 있게 명시하고, 작업이력도 관리할 수 있어야 합니다. 또한 작업 상세 설명을 검색할 수 있어야 중복 작업을 없앨 수 있습니다.

메타정보 관리

테이블명, 컬럼마다 comment를 등록해야 합니다. (우선 용어 정리를 먼저 해야겠군요.) 항목에 대한 의존성을 체크할 수 있는 기능이 있으면 좋겠지만, 필드에서는 의존성 검색하는 경우가 매우 드문 것 대비, DB 항목별 의존성(이용 메뉴)를 찾고 관리하는 비용이 매우 높아 주요 필드 위주만 관리하는 것도 방법입니다. 

과거에는 ERD를 그리고 PK와 FK를 연결하는 매우 고가의 솔루션들을 많이 도입했었지만, 실제 변경이 적어 관리에 소홀하다보니, 최신화가 되지 않는 현장들이 많습니다. 또한, FK를 설계할지라도 운영상 오류 방지를 위해 FK를 설정하지 않아, ERD의 그림과 DB의 스키마의 설정이 달랐습니다. 따라, ERD를 통하지 않아 직접 DB를 정의하다보니 차츰 ERD를 관리하지 않아 요즘에는 거의 유명무실해졌습니다. 

오히려 엑셀에 표로 테이블 구조를 관리하는 것이 적합할 수 있습니다.

데이터 품질

DW환경이 어느정도 안정화되면, DQ(데이터 품질, Data Quality)를 고려해야 합니다. 데이터 완결성, 유일성, 유효성 등은 메타 데이터를 가지고 검증할 수 있으며, 시의적절성, 정확성, 일관성 등은 검증 로직을 활용하여 체크해야 합니다. 그외 데이터 분포, 이상거래 탐지 등이 있습니다. 

실시간 검증이 필요한 영역이 있고, ETL, DW 처럼 일, 주, 월 배치로 작업을 해야 하는 것도 있습니다. 최근에는 LOG, 변동분 기록을 새벽에 전날 기록을 옮기지 않고(일배치), 실시간으로 DW에 기록할 수 있도록 구성하는 회사도 있습니다. 이것은 이동시간(거래량에 따라 1~2시간 소요)를 최소화하고, 실시간으로 검증 로직을 활용하기 위해서입니다.

요약
• Risk의 크기를 고려하여 통제는 꼭 필요한 곳에만 적용, 기본적으로는 빠른 탐지와 대응 중심.
• 전사차원의 효율성을 고려하여 자동화, 체계화 진행 시기 결정
• 관리시스템 개발시 처음부터 완벽한 시스템을 만들려고 하지 않는다.

한명의 친구처럼 말을 하는 앱

알림, 안내문구 등을 사람처럼 따뜻하고 부드럽게, 그리고 나의 불편함을 공감하듯이 말해준다면 많은 사람들이 좋아할 것입니다. Humanized Writing이 바로 6개월만에 토스가 이뤄낸 것입니다. 토스앱에는 은행, 증권, 혜택, 통신 등 아래의 메뉴와 같이 다양한 서비스를 제공하고 있습니다. 많은 개발자, 디자이너들이 각자 문구 등을 작성할 때 가이드라인을 참고하지만, 가이드라인이 많으면 많을 수록 놓치는 부분이 많아집니다.

'이체 완료했습니다.', '이체 완료했어요', '이체 완료' 등 동일한 표현을 각자 다르게 하는 경우가 종종 발생합니다. 사실 본인이 UX담당도 아닌데 수십페이지의 가이드를 모두 외우기도 힘들거니와 모두 체크하기는 너무 비효율적입니다. 그래서 아무리 완벽한 가이드문서를 만들어도 결국 보는 사람이 보지 않는다면 의미가 없습니다.  

그래서 토스는 가이드문서를 시스템화 했습니다.

개발툴에서 제공하는 코드 문법을 체크해서 표시해주는 기능을 활용하여, 컴퓨터가 문구를 읽고 용어를 변경하거나 동일한 어투로 바꿀 수 있게 가이드해주는 것을 개발했다고 합니다. 이 보이스톤 메이커를 만들기 위해 8,000개가 넘는 규칙을 만들어 데이터베이스화했다고 합니다. 이제는 사람이 아니라 컴퓨터가 수정해야 할 문구를 잡아주니 사람들은 더 고부가가치적인 업무에 집중할 수 있을 것 같습니다.

또한, 어투를 더 사람답게 만들었습니다.

'해피모먼트'를 발견하여, '대출 갚느라 고생했어요', '생일 축하해요' 등 축하와 격려를 수시로 하고, 어떤 변경사항(개선)에 대해서도 '그 동안 진짜 불편했을 것 같아요' 라고 공감해주기도 합니다. 사실 이런 공감하는 말투는 자칫 잘못을 인정하는 것이라고 생각하는 사람들도 있어서 대부분의 앱에서는 사용하지 않는 표현들입니다. 더 사람답게 다가가기 위해 이런 공감적인 표현을 하는 것은 정말 대단하다고 생각됩니다. 

 

UI리서치님의 인터뷰를 보면서 정말 그래? 다른 이유도 있을 것 같은데

UI/UX 를 위해 이용자에게 직접 인터뷰 통해 피드백을 받고 업무를 진행하는 모습이 정말 토스는 다르구나 싶습니다. 물론 약간(?)의 추정도 있어 보이긴 합니다.

토스머니를 사용하는 아이들이 과연 부모님이 엄격해서 계좌개설을 안해주는 것일까요? 

23년 상반기까지, 미성년자(특히, 만14세미만)는 전자금융서비스 가입을 하기 위해서는 법정대리인(보통 부모님)의 동의가 필요합니다. 그래서 카카오뱅크 같은 인터넷은행의 경우 미성년자의 가입을 제한하였습니다.  시중은행에서 부모와 자녀가 함께 방문해야만 만들 수 있었습니다.

만약 아이에게 카드를 줘야 한다면 부모님들은 본인 명의로 한도를 낮게 설정하여 발급받아 주었습니다. 계좌의 경우 부모님이 본인 명의로 별도 계좌를 개설하여 대신 관리해 주었습니다. 

즉, 부모님이 엄격한게 아니라 다른 이유가 더 컸다고 생각됩니다.

2023년 4월 금융위원회는 "모바일에서 아이 통장 만들기, 미성년 자녀 명의 계좌 부모가 비대면으로 개설 가능" 이라는 보도자료를 발표하였습니다. 법정대리권을 가진 부모가 비대면 방식으로 자녀 명의의 계좌를 개설할 수 있도록 "비대면 실명확인 가이드라인"을 개편하기로 했습니다. 금융회사는 부모님의 신분증, 가족관계증명서 등을 통해 부모의 신원과 권한, 자녀의 실지명의를 직접 확인한 후 계좌 개설을 할 수 있습니다.(단, 1~2영업일 소요) 대부분의 은행과 증권사에서 금년 중에 도입할 예정입니다. 

14세 미만 이용자는 법정대리인의 별도 동의 필요

특히, 개인정보처리방침 가이드 라인이 22년에 개정되었습니다. "정보주체와 법정대리인의 권리.의무 및 그 행사방법에 관한 사항"이 추가되어, 14세 미만 이용자의 개인정보를 수집할 경우 법정대리인의 동의를 별도로 받아야 합니다. EBS 사이트에서 회원가입해 보시면, 어른과 자녀가 다름을 알 수 있을 것입니다. 그외 쇼핑몰 등에서는 14세미만이면 회원 가입을 거부하기도 합니다. 

요약
• 개인정보를 수집한다면, 14세 미만 이용자 가입 허용할지 고민
• 개인정보 수집시 14세 미만 이용자는 법정대리인의 별도의 동의 필요
• 비대면으로 자녀 은행, 증권 계좌 개설이 가능합니다. 
• 비대면 자녀 계좌 개설 준비물 [부모님 신분증, 휴대폰, 가족관계증명서(3개월이내), 기본증명서(3개월이내)]

* 저는 이제 자녀의 계좌로 본인 용돈으로 주식투자를 같이 해볼까 합니다. 

2년동안 금융권에는 큰 변화가 있었다.(오픈뱅킹, 마이데이터)

 USB은행은 핀테크 기업들도 금융회사와 동등한 금융서비스를 제공할 수 있도록 Open API를 제공하고 있습니다. 빅테크와 금융회사간 치열한 경쟁 속에서 은행은 기존의 직접판매 채널이 아닌 핀테크 등과 같은 비금융 사업회사의 플랫폼 채널을 통해 금융서비스를 제공하는 서비스형 뱅킹(Bass, Banking as A Service)으로 확장하고 있습니다. API를 통해 비금융사에 Plug&Play 서비스를 제공하여 빅테크 이용자들이 자연스럽게 금융을 이용할 수 있도록 USB의 금융 생태계를 만들고 있습니다.

하지만, 우리나라는 다릅니다. 금융당국이 정책적으로 모든 은행, 증권사, 저축은행이 핀테크 회사들 위해 금융서비스를 이용할 수 있도록 Open API를 제공하도록 강제했습니다. 덕분에 우리나라는 특정은행의 생태계가 아닌 대한민국의 공통 금융 생태계를 만들고 있습니다. 그 이후 마이데이터 사업까지 추진하였습니다. 

지금 우리는 모든 금융회사앱에서 타행의 내계좌번호, 잔액을 조회할 수 있습니다. 심지어 이체도 가능합니다.

과거에는 이체를 하기 위해서 계좌번호를 외우거나 자주 쓰는 번호를 등록했어야 했습니다. 그나마 토스는 과거 이체기록을 통해 혹시 사용하려는 계좌가 이것인지 제안을 했었습니다. 당시에는 불편함을 줄이는 방안이 었으나 지금은 오히려 그 방식이 더 불편해 졌습니다. 

하지만, 이렇게 타행의 계좌를 조회해주는 것은 토스만의 서비스가 아닙니다. 대한민국은 오픈뱅킹, 마이데이터로 대한민국 모든 금융회사가 개발할 수 있습니다. 물론, 개인적으로 UI가 토스가 좀(?) 편하고 눈에 잘 들어 오지만, 해당 서비스는 여러분이 이용하는 금융앱에도 있습니다. 

금융시장은 매우 빠르게 변하고 있습니다. 지금의 개선이 1~2년 뒤에 오히려 불편함이 될 수도 있다는 걸 기억해야 합니다. 

https://www.youtube.com/watch?v=mY9_6nupAv8&list=PL1DJtS1Hv1PgAekdTPF0lKtfsqAis3HXR&index=8 

혜택을 다양하게, 과감하게 

혜택이란 서비스는 아마 쇼핑몰에서 쿠폰을 지급하면서부터 우리에게 아주 익숙한 개념이 되었습니다.
초기에는 (아직도) 쇼핑몰에서는

• 23~24시 구매시(시간 제한)
• 3만원, 5만원, 10만원 이상시(금액 제한)
• 첫 고객이라면(고객 제한)
• 3년만에 돌아온 고객이라면(고객 제한)
• 전자제품을 구매한다면(제품 제한)

모든 소비자에게 두루두루 혜택이 가고, 다양한 방식으로 신규 가입자 등을 유치하거나 특정 제품의 판촉을 위해 쿠폰을 지급하고 있습니다.

쿠폰(혜택)이 금융에서는 포인트(=머니)로 지급되고 있습니다. 최근 유행하는 DX(Digital Transformation)에서는 플랫폼에 대해 많이 강조하고 있습니다. 즉, 어떤 서비스를 위한 앱(웹)이 아니라 플랫폼화하여 이 플랫폼 위에 다양한 서비스를 제공하는 생태계를 만들어야 한다는 것입니다. 따라, DAU(Daily Active User) 숫자를 높이는데 매우 노력하고 있습니다. 그래서 Gamificatin(게임성)을 강조하고 있습니다. 매일 출근도장을 찍거나, 퀴즈를 풀거나, 걷기 등 "재미있다"는 경험과 금융을 합쳐 꾸준히 즐길 수 있게 하는 것입니다. 

토스는 브랜드를 자연스럽게 홍보할 수 있는 퀴즈를 통해 소량의 포인트를 주고, 바로 이용 제한(조건)이 없는 쿠폰(혜택)을 지급합니다. 홍보와 구매를 Seamless하게 자연스럽게 연결한 것입니다. 

중요한 것은 이런 생각을 하고 6개월동안 52번의 다양한 실험을 통해 입증하였다는 것입니다. 

"친구와 함께 토스 켜고" - DAU를 목적으로 혜자

또한, 올해 "친구와 함께 토스 켜고"는 정말 히트였습니다. 블루투스 통신(근거리 통신, 5~10m정도)을 이용해서 주변에 토스 이용자가 있다면, 클릭시 10원을 주는 혜택입니다. 초반에 직장인들이 점심시간에 인구 밀집지역에 모여 5~6천원을 1시간이내 모았다는 기사도 있었습니다. 혜택이 너무 커서 50번(?)으로 제한하는 정책이 생기긴 했지만, 여타 다른 캐시슬라이드 등 대비 인구 밀집 지역에 거주하는 사람에게는 훌륭한 재테크앱이 분명합니다. 

토스가 왜 이렇게 DAU에 목숨을 걸까요? 우리가 아는 Fintech로 출발한 회사에서 제대로 된 수익이 나는 회사는 인터넷은행뿐입니다. 핀다, 뱅크샐러드, 핀크 등 많은 Fintech가 자산관리를 할 수 있는 것으로 시작하여 투자를 많이 받아왔지만, 사실상 수익을 낼 수 있는 구조를 만들지 못해 힘들어 하고 있습니다.
대환대출 시장을 장악하여 금융회사로 부터 수수료를 받는 구조를 만들려고 하였으나, 정부의 대출 규제, 일부 플랫폼(대형 핀테크회사) 횡포로 기존 금융회사의 반발로 협업이 어려워졌습니다. 또한, 잠깐 핀테크회사의 영역인 자산관리가 오픈뱅킹, 마이데이터 등으로 금융회사도 동일한 서비스를 시작하였습니다.

지금 핀테크 업체의 서비스는 대동소이하기에 살아남기 위해서는 사용자가 자주 이용하여 타사와의 제휴를 이끌어내야 합니다. 타회사의 제휴를 통해 사람들이 모이고, 또다른 회사와 제휴하여 신규 서비스를 런칭하는 순환 구조를 만들수 있어야 살아남을 수 있습니다.

"만보기" - 부모님 세대(60대 이상)에 Hit

부모님들이 건강을 위해 걷는데, 그러면서 100원을 받고자 토스앱 만보기를 키십니다. 걸어서 40원, 특정지역 방문(5군데)해서 100원을 매일 받을 수 있습니다. 최근 지인말로는 '어머니가 동네 친구들하고 얘기하시는데, 자기만 토스앱이 없다, 나도 설치해달라'라고 하셨다 합니다. 저도 만보기를 해봤지만, 사실 40원 벌고자 이렇게까지 매일 해야 하나? 했는데, 지하철 타면서 보니, 2정거장을 지나면서 특정지역 방문(5군데)를 모두 지나쳐서 100원이 벌어지는 것을 보면서, 매일 아침 출근길에 지하철에서 토스앱 5분만 보면, 한달에 커피 한잔 정도는 벌겠구나 싶었습니다. 

토스 만보기는 정말 다른 재테크앱보다는 확실히 베푼다는 느낌이 들었습니다. 은행앱에서 출석해서 행운 상자 열면 '1원' 나오는 것 보다 100배 낫다는 생각이 들었습니다. 

요약
• 정말 혜택을 쉽게 받을 수 있어야 하고, 소소할 정도는 되야 할 만한 것 같습니다.
• 흥행 실패보단, 초반에 통크게 베풀고 차츰 줄여가는 게 좋습니다.
• 게임요소는 중요합니다. 더 중요한 것은 게임+목적(판매 등)의 연계 기술입니다. 

https://www.youtube.com/watch?v=M5407fsxxEU&list=PL1DJtS1Hv1PgAekdTPF0lKtfsqAis3HXR&index=9 

앱, 웹, 실물까지 단하나의 서체..

모든 상황에서 최적의 폰트를 찾아 운용하다 보면, 다른 폰트를 사용하게 됩니다. 웹에서 보여지는 것과 모바일, 포스트(실물) 등 해상도 등에 따라 보여지는 느낌이 다르기 때문입니다.

하지만, 이것을 해결하기 위해 자신만의 폰트를 만들었다는 토스가 놀랍습니다. 마치 애플처럼 그들만의 생태계를 보이지 않는 공기부터 차근차근 만들어가는 느낌이 듭니다. 

일반적으로 이렇게까지 하는 회사는 없을 거라 생각됩니다. 리더가 주도하는 세상이 아닌, 이런 자체 폰트를 제작하겠다고 나선 이들이 정말 진정한 Fintech의 리더라고 생각됩니다. 

해당 내용은 토스 블로그에도 나와있습니다.

토스ㅣSimplicity 21 - 모두를 위한 단 하나의 서체 - YouTube