토스뱅크 테크 밋업 Tech Picnic, Tech.nic! 참석 후기
개발자들을 위한 기술 세미나 등등 각종 행사가 점점 많아지는데
많아지는 만큼 높아지는 경쟁률!
세미나에 가고 싶었을 뿐인데... ?? 탈락해버리는 경험을 여러 번 하던 중 ㅋㅋ
오래간만에 진짜 가고 싶은 세미나에 당첨됐다!
ㄱ ㄱ ㅑ ~~~~ 당첨!
0. 가고 싶었던 이유
'토스 뱅크 밋업인데... 당연히....??? ' 싶지만 굳이 좀 더 적어보자면 ~
1) 현재 핀테크 스타트업에 재직 중이라 자연스레 핀테크 기업에 대한 관심 ++
핀테크는 다른 도메인들과는 다르게, 망 분리를 대표적으로 각종 제약사항에 얽매여있는 분야인 것 같다.
나와 비슷한 환경의 개발자들은 어떤 방법으로 일하는지 궁금했다.
2) 그중에서도 토스 뱅크에 관심이 가는 이유는 인터넷 은행의 폭발적인 성장!
기존 은행과 같이 업무를 했던 몇 번의 경험을 돌아봤을 때, 금융권은 상당히 경직되어 있음을 느꼈다.
기존 은행 수준의 안정적인 서비스 + 기술 혁신이 인터넷 은행의 비약적인 성장을 가져왔을 텐데
그 과정에서의 어려움, 그걸 어떻게 해결했는지 궁금했다.
3) 무료한 개발자 일상에 자극받기
'출근 - 퇴근' 무한 반복의 굴레에서 벗어나 토스 뱅크 구경도 하고, 다른 개발자들 구경도 하고 싶었다.
커리어에 대한 고민이 많은 요즘, 새로운 자극을 통해 환기 + 탈출구 마련에 도움이 되길 바라며!
여느 때처럼 눈알이 빠지게 업무를 하고 충혈된 눈으로 토스 뱅크 건물로 향했다.
1층에서부터 환영해 주시는 토스 뱅크 스탭분들, 이미 자리를 많이 채운 개발자분들, 세심한 도시락까지!
충혈된 눈으로 기쁘게 시작을 기다렸다.
기억에 남는 점부터 남겨보자면
1. 부러워서 배 아팠다.
(쓰면서도 부러워서 한숨이 먼저 나오는데...)
어려운 문제들을 해결하고 그것을 행복해하는 개발자들이었다.
개발자로 일을 하다 보면 다양한 문제를 만나게 된다. 문제 자체의 복잡성이 높은 경우, 과거의 기술이나 코드가 발목 잡는 경우,
새로운 요구사항의 등장 등등 개발자는 문제를 해결하는 사람이라고 생각한다.
발표에 나선 10여 명의 개발자들은 모두 자신이 개발하면서 직면한 문제들을 해결한 경험을 공유해 줬고
그 표정이 사뭇 행복해 보였다.
발표를 하면서도 고개를 가로저으며 얼마나 지독했던 문제였는지 몸소 표현해 주셨지만
그걸 해결해서 개인적으로는 물론, 개발자로서, 조직의 일원으로서 행복해 보였다.
본인 손으로 가져온 혁신을 자랑스럽게 생각하는 모습이 보였다.
회사 내부적으로 사용하는 admin을 얼마나 기깔나게 만들었길래 admin이라고 부르기 아까워서
이름을 따로 지었다는 얘기를 들으면서 참 부러웠다.
'유저가 보는 것도 아닌데~', '버그 나와도 어드민인데 뭐~' 라는 마음으로 어드민을 작업했던 내가 떠올라서 부끄럽기도 했다.
물론 지금 회사에서는 나 말고 다른 개발자들도 그렇게 생각하는 것 같지만,
내가 토스 뱅크 개발자 같은 마인드로 어드민을 작업했다면, 다른 개발자들도 나랑 같이 '멋진 어드민'을 만드는데 동참했을까?
내가 맡은 이슈들을, 그러니까 내가 해결해야 하는 문제들을 어떻게 정의하냐에 따라서
해결 방법뿐 아니라 해결의 방향, 결과의 퀄리티도 달라진다.
개발자가 코드뿐 아니라 프로덕트와 회사의 비전을 충분히 이해해야 하는 이유라고 생각한다.
2. 우물 안 개구리
msa 구조에 있는 500여 개의 서비스
40여 개의 케이스
270개 이상의 테스트 코드
얽히고설킨 164개의 배치
발표를 들으면서 인상 깊었던 숫자들을 써봤다.
'천만 명 정도 쓰는 서비스라면 당연히 복잡하겠지~'싶지만, 저걸 손수 작업하는 입장이라면... 아득하다.
지금 회사에서도 온보딩 일부 코드에서 16개 정도 케이스가 발생하는 경우가 있었다.
기존 코드에 조금씩 기능이 추가된 거라 처음에는 케이스가 이렇게 많지 않았는데
앞서 작업한 개발자들이 조금씩 키운 폭탄을 내가 딱 받았다.
코드 작업을 할 게 아니라 일단 케이스에 대한 정의부터 시작해서 놓친 케이스는 없는지, 통합할 케이스는 없는지 문서 작성을 했다.
관련 부서에도 케이스에 대한 검토 받고 나서야 기존 코드 정리를 하고 요청했던 작업을 시작할 수 있었다.
복잡한 케이스에 대해서는 어느 정도 일가견이 있다고 생각했는데 우물 안 개구리였음을 깨달았다.
금융권 경험이 있는 개발자를 선호하는 것이 백번 이해가 된다.
3. '코어뱅킹 시스템 기술스택 교체'
업무를 하면서 기존 은행권과 같이 일할 기회가 몇 번 있었다. 몇 년 전부터 사용했을지 모를 전문을 받아서 연동하는 작업을 했었다.
무슨 단어를 줄인 건지도 모를 단축어와 필요 없는 필드가 많은 전문이었지만 슈퍼 을이라는 생각에 받은 대로 작업했다.
안정적인 서비스가 굉장히, 상당히, 무엇보다 중요한 만큼
이미 잘 돌아가고 있는 코드를 개선하는 일은 잘 없을 거라고 어렴풋이 생각했다.
그런 와중에 '코어뱅킹 시스템 기술스택 교체'를 진행하는 토스 뱅크가 기술 혁신을 이루는 건 당연한 일이랄까?
외부 업체가 작업한 코어뱅킹 시스템을 온전히 내부적으로 운영, 개발하기 위해서 기술 스택을 교체한다고 한다.
linux vm -> k8s
svn -> git
mdd -> no mdd
jeus > tomcat
devon -> spring
발표자분이 워낙 어려움 없이 쉽게 말씀하셨지만 운영 중인 시스템에 사용하는 기술을 바꾸는 일이 결코 쉽지 않을 텐데 감탄..!!
4. '하루 300억 건 로그 받아보기'
안정적인 시스템 운영을 위해서 로그를 잘 남기는 것이 중요하다.
당연한 얘기지만 300억 건의 로그를 관리하는 일이라니 정말 탐이 난다.
- 로그 레벨 분리 : error 로그를 밀리지 않고 확인할 수 있도록 info, warn / error 레벨을 구분
- 로그 lag 줄이기 : api 호출 자체를 줄이는 방법
5. 각각 문제 해결에 적합한 디자인 패턴 적용
- 전략 패턴
- 상태 패턴
- saga 패턴
- strangler fig 패턴
- compositon 패턴
6. 각각 문제 해결에 적합한 기술 도입
- 1회성 데이터 적재 : redis
- 카프카
- air flow
7. 머신 러닝 멋있다..!! 배워보고 싶다..!!
업무와 전혀 무관하게, 순수한 호기심으로 뭔가 배우고 싶다는 생각을 오래간만에 했다.
8. 마무리
1) 기술적으로는...
다른 회사에서는 어떤 기술 스택을 쓰는지, 문제를 해결하는 방향, 방법이 어떤지 1차원적인 궁금증이 조금이나마 해소됐다.
당연한 얘기지만 당장 하고 있는 업무에 적용하기에는 환경도, 규모도, 문화도 다르기에 다소 무리가 있다.
미래의 내가 비슷한 문제를 해결해야 하는 상황이 와서 유용하게 사용하게 되길 바란다.
세미나를 통해들었던 키워드 중에 자신 있게 설명하기 어려운 것들, 처음 들어보는 것들은 따로 정리해 봐야겠다.
특히 실무에서 디자인 패턴을 생각하면서 작업했던 적이 별로 없었던 거 같은데
토스 뱅크 사례를 보면서 디자인 패턴을 다시 공부해 봐야겠다.
2) 심적으로는...
적절한 타이밍에, 좋은 기회를 갖게 되어 감사하다.
비슷한 환경에서 몇 년 간 일을 하다 보니 여러모로 지루함을 느끼던 찰나였다.
도메인, 회사라는 조직, 개발자라는 직업, 일을 하는 방식, 동료와의 관계 등 여러 가지 측면에서 생각이 많아졌다.
생각이 많아져서 글이 안 이어진다.
음..
즐거운 picnic의 의미를 담은 Tech,nic에서 즐겁기도 했고,
앞으로 즐거운 개발자로 오래 일하기 위해서 내가 어떻게 해야 할지 생각해 봐야겠다.