6월 8일 23년도 slash 토스 온라인 컨퍼런스를 사전예약해서 시청하게 되었다. 상세한 내용을 알아보고 싶다면 앞의 링크 사이트를 통해 토스 slash23페이지를 통해서 알아보자.
트랙은 2가지로 나뉘어 졌는데 트랙만 봤을땐 A트랙은 프론트와 DevOps의 내용같았고,
B트랙은 서버개발자를 위한 내용 같았다. 실제 메일에 전송된 안내문 또한 내 예상과 크게 다르지는 않았다.
1. AI와 함께 가짜 신분증 찾아내기
😀내가 최근에 가장 고민했던 부분이다. BNB프로젝트를 진행하면서 HOST를 검증하는데 신분증을 받으면 어떻게 검증할 것인가? 고민하면서 openAPI도 찾아보고 여기저기 둘러봤지만 답을 찾지못해서 차선책으로 신분증이 아닌 전화번호를 받고 전화연결을 통한 수기검증 방식을 진행했다.
토스는 사용자의 신원확인을 위해 신분증 사진을 제출받고 있다. 신분증 사진원본 자체를 받는것을 원칙으로 하고 신분증이 아닌라 신분증을 찍은 화면이나 출력물을 제출하는 것을 막고 있다. 신분증을 찍은 화면이나 출력물은 도촬한 신분증 사진을 가지고 타인의 통장을 개설 및 대출받는 등의 문제를 발생 시킬 수 있다.
😀어떻게 사진과 찍은화면 or 출력물을 구분할 수 있는걸까?
토스에서는 해당 신분증이 원본인지 아닌지 사람이 직접 한땀 한땀 확인한다고 한다.
😀AirBNB도 그랬을까? 잘 모르겠지만 조금 위안이 된다.
하지만 사람이기에 실수를 할 수도 있고, 해당 실수를 바로 잡아주거나 걸러낼 방법이 없어서, 휴먼에러를 더블체크해주고, 위조신분증을 걸러서 거래제한을 해 줄 수 있는 AI를 개발하는 아이디어를 생각해내게 되었다고 한다.
2. Server-driven UI로 다이나믹한 서비스 효율화하기
😀내가 신선한 충격을 주었던 방법이었다. UI/UX는 프론트엔드 담당이며 백엔드는 프론트의 요청으로 데이터를 넘겨주면 프론트는 해당데이터를 가지고 화면을 꾸며주는게 당연한 방법이라 생각하고 있었다.
😀기존에 내가 생각하던 백에서 프론트로 데이터를 넘겨주고 프론트는 해당 데이터를 가지고 화면을 보여주는 형식을 토스팀에서는 데이터 기반 설계로 부르며, 토스의 홈팀(어플리케이션 홈화면 팀을 의미하는 것 같다.) 또한 기존에는 위와같은 방법을 사용했다고 한다.
하지만 이러한 설계방식은 단점이 존재한다.
- 홈 화면에 기능을 배포할 때마다 사용자는 최신 버전으로 앱을 업데이트 해야한다.
- 또한 업데이트로 인해 마켓에서 설치하고 설치하는 동안의 시간이 낭비된다.
😀실제로 우리는 거의 모든 App(어플리케이션)을 모바일에서 다운로드 하면 이후 주기적인 업데이트로 인해 불편함을 느끼기도 한다. 나는 웹에서만 작업을 해 보았기 때문에 홈팀의 역할을 맡은 프론트가 그냥 배포를 완료하기만 하여도 웹에서는 바로 적용되기 때문에 이러한 고민을 해본적이 없었다. 만약 android나 ios와 같이 어플리케이션이라면 이런 고민을 한번쯤 하게 되었을까?
그래서 사용자가 필요로 하는 기능을 빠르게 만들어서 배포하고, 최고의 사용자 경험을 제공하기 위해서 만들게 된 것이 HomeDST(Home Desgin Syntax Tree)로 서버에서 UI나 동작등의 정보를 앞단으로 넘겨주는 방식이다.
😀하지만 토스팀또한 DST만으로 서버를 만들지 않고 여러 화면구성요소 중 하나로 사용한다고 했다. 여러가지 문제가 있기 때문이라는데 무순 문제였을까? 만약 처음부터 해당 방식을 채용해서 만들게 된다면, 실질적으로 화면을 DST만으로 구성할 수 도 있지 않을까?
3. 토스는 Gateway를 이렇게 씁니다.
😀Gateway 실제로 사용해 본 적이 없는 기술이다. 하지만 MSA에 꼭 필요한 기술로 되는 것이 API Gateway로 각 서버에 정보에 대한 요청을 하기 전 거처가는 정보의 통로? 중계소? 와 같은 역할을 하는 것으로 알고 있다.
설명또한 Gateway에 대해 한줄로 설명하기 어려워 GPT의 도움을 받아서 설명해 주었다. "MSA의 중개자 역할을 하는 서버로 Gateway를 통해 MSA는 Client와 독립적인 확장을 할 수 있고, 보안, 모니터링을 위한 단일 지점을 제공한다."고 설명했다.
😀Gateway는 여러 서버로 들어가는 하나의 입구의 서버라고 생각하면 쉬울것 같다. 만약 인증서버에 각 서버가 인증요청을 보내는 방식인데 인증서버의 업데이트로 인해 로직이나 데이터가 변경되거나 에러가 발생하면 그 인증서버에 맞춰 각 서버들 또한 업데이트해줘야한다. 하지만 각 서버에서 필요한 공통로직을 Gateway에서 처리하면 Gateway에서 인증을 받고나서 각 서버로 넘겨주는 방식이 된다면, 앞서 설명한 불필요한 업데이트나 비효율적인 방식을 고려하지 않아도 된다.
토스에서 BFF패턴, Ingress/Egress패턴 등을 토대로 Gateway를 구성하여 서버 API요청을 담당한다. spring Cloud Gateway / Kotlin / Istio 를 대표적으로 사용하여 개발하고 있다고 한다.
😀하.. 스프링이랑 코틀린 러스트 등 공부해야할게 참 많은데도.. 내 발전은 더딘것 같아 마음이 무겁다. 아직 노드 밖에 경험해 보지 않아서 그런가 빨리 다른 언어나 프레임워크를 하나더 배워봐야 뭐가 어떻게 비슷하고 다른지 알 수 있을 것만 같다.
이 외에도 Gateway의 보안쪽 내용은 종단간 데이터의 암호화(E2EE), JWT, OAuth2.0, 내부적인 보안로직, API 차단(특정 유저, IP, device 등), Istio 인증서 인증/인가, 사내웹서비스 인증/인가 등 굉장히 많은 보안쪽 내용을 발표해 주었다.
😀금융관련이여서 이렇게 많은 보안서비스가 필요한 것인지, 회사가 크기때문에 그런것인지, 원래 최소 저 정도는 해주는게 일반적인 보안인지 아직 실무를 경험해 보지 못한 나는 잘 모르겠지만, 모두 필요한 보안 로직이라는 것은 이해가 된다.
다음으로 Gateway의 유지 관리에 대해서 Mono레포에서 게이트웨이별로 레포를 분리하여 관리하고, 공통로직은 라이브러리화 해서 관리하고, JAVA코드를 yaml형식으로 변경하는 등을 통해 Gateway서비스 관리를 하였다고 한다.
😀주요 내용은 Gateway를 사용하면서 불편했던 점을 개선하고, 휴먼 에러가 나는 부분을 수정하며, 너 나은 개발 환경을 만들기 위해 여러가지 설정관리를 하였다는 내용있었다. 일반적인 서비스도 진행함에 따라서 불편함을 느끼게 되면 수정하고 고쳐 나아가야 하는 것과 같이 이 대목은 Gateway서버를 잘 모르는 나에게도 친숙하게 다가올 수 있는 내용이었다고 생각한다.
4. 라운드테이블 : 토스 시니어 개발자가 말하는 커리어 패스
😀이 부분은 나에게는 많이 와닿지 않는 부분이었다. 주로 TPO와 10년이상의 시니어 개발자에 대한 내용이었는데 아직 1년차도 안된 나에게는 너무 거리감있는 내용이었다. TPO(Technical Product Owner)는 토스 내에서 서비스를 관리하는 작은 하나의 팀의 팀장 또는 대표의 포지션이라는 것을 알았고, 진짜 시니어 개발자분들이 시니어 개발자와 주니어 개발자를 가르는 기준 같은 것을들 들을 수 있었다. 아직 공감되는 내용은 아니지만 몇년이고 더 이 개발업계에 내가 뛰어들고 있다면 언젠가 마주하게 될 수 있지 않을까?
5. 연결되면 비로소 보이는 것들
😀토스에서 Observility를 확보하기 위한 노력과 이를 이용해서 서비스를 개선한 구체적인 사례를 발표해 주었다. naver에서 개발한 오픈소스 APM Pinpoint를 이용해서 각 유저의 요청과 서버가 받은 요청들을 분산추적하여 그에 대한 데이터를 확인할 수 있다.
😀또한 비동기 방식의 프로그래밍을 하기 위해 Kotlin Coroutine사용하여 코드를 구성하였는데 Pinpoint가 Coroutine을 지원하지 않기 때문에 직접 Coroutine플러그인을 만들어서 진행하였고 해당 과정에 대해서 발표해 주었다.
😀과정을 요약하면 Pinpoint에서 지원하는 비동기 방식을 어떻게 진행하는지 간단한 라이브러리 1개를 파보고 어느시점에서 어떻게 비동기 처리된 내용을 추적하는지 파악하고, 해당 지점들을 Corountine에 맞게 적용시키는 과정이었다. 코드 로직에서 중요지점을 파악하고 해당 지점을 어떻게 연결 짓는지에 대한 로직에 대한 설명이 많아서 저작권때문에 생략하지만 하나하나 추적해 나가면서 파악하는게 멋져보였다.
😀기존에 연결이 안되는 Pinpoint를 kotlinCoroutine과 연결하면서 각 유저의 요청과 서버가 받은 요청 등의 데이터들을 볼 수 있게 되어 세션의 제목이 "연결되면 비로소 보이는 것들"인가 보다.
6. 실시간 시세 데이터 안전하고 빠르게 처리하기
😀시세플렛폼 서버 개발중 일어났던 사례를 바탕으로 발표해 주었다.
한국 거래소에서 받은 시세정보를 시세플렛폼에서 가공하여 내부 토스 서비스들에게 전달해 주는데, 시세플렛폼에서 장애가 발생하면 서비스로 까지 오염된 정보가 전달될 수 있기 때문에 DB를 두개로 나눠 하나를 사용하다가 장애가 발생하면 복구하기 보다는 오염되지 않은 나머지 DB를 사용하는 방법으로 장애발생에 대한 빠른 대처를 진행하였다고 한다.
😀그렇다면 DB를 두배로 사용하게 되니까 비용도 두 배가 되는게 아닌가? 그 비용 두 배 보다는 서비스 복구 및 장애로 인한 피해복구의 비용이 훨씬 클 것으로 예상되지만, 장애를 그 전에 차단할 방법은 없었을까? 고민하게 된다.
그 외에 Redis Pub/Sub과 이벤트루프 등의 내용을 설명해 주었다.
😀내겐 좀.. 어려웠던 것 같다. Redis Pub/Sub은 UDP와 kafka등의 비교를 통해 보여주어 대충 이해할 수 있었지만, 이벤트루프는 내가 아는 내용이 javascript의 동작원리의 이벤트루프 뿐이라서 그런지 이벤트루프의 갯수를 늘리고 줄이고 갯수를 제한하는 등의 내용은 많이 어렵게 다가왔다.
7. 프로파일러로 시스템 성능 향상시키기
서비스 운영중 갑작스러운 시스템 리소스 사용중이나 응답 속도 저하 등의 여러 장애가 발생하였을 때, 대부분은 로직의 변화를 파악하여 해결할 수 있지만, 그렇지 않은 부분에 있어서, 프로파일링을 진행하여 서비 내부에 어떤 문제의 원인이 있는지 파악할 수 있다. 이러한 서버 플랫폼 팀의 프로파일러와 겪은 사례를 발표해 주었다.
😀프로파일링은 결국엔 역추적이다. 어떠한 일이 일어났을 때 상황을 기반으로 하나하나 찾아서 올라간다. 코드의 장애원인도 똑같이 찾아서 가다보면 어디서 어떻게 장애가 발생했는지 확인할 수 있다.
MSA구조에서 분산 트랜잭션 분석을 위한 Pinpoint
JVM 힙 분석에 자주 사용되는 Heapdump
네이티브 메모리 분석에 Je malloc
CPU와 메모리 사용 분석에 용이한 Async-Profiler
시스템 분석의 Strace, Perf Trace,
리버스 엔지니어링의 Binary Ninja
😀이 후 위의 내용을들 이용한 사례들을 발표해 주었는데, 하나의? 서비스를 운용하는데 이렇게 많은 분석툴을 사용해야 하며, 각각 동작을 하는 방식도 다르고, 만약 위의 모든 종류를 하나의 툴로 만들어 내면 좋지 않을까? 라는 생각도 하게 된다.
😀첫날의 발표는 총 7가지로 초반에는 좀더 내게 와닿는 내용들 이었지만 뒤로 갈수록 아직 내가 이해하기 어려운 부분이 많았다. 6월 9일 이어지는 slash23을 시청하고 좀 더 많은 것을 얻어보자.
PS. 장황하게 내용까지 포함해서 글을 썻었는데 나중에 저작권관련 내용이 눈에 들어와서 내용의 90퍼센트를 삭제하고 나의 생각만을 정리해서 적는 쪽으로 변경하였다.
