그것은 바로 토스의 「SLASH 22」의 "왜 은행은 무한스크롤이 안되나요" 영상이다.
은행에서 개발하지 않은 사람에게도 유용한 영상이다.
왜냐하면, "서비스를 위해 백엔드를 어떻게 구성해야 하는지"에 대한 고민의 흐름이 보이기 때문이다.
0. 스타트업에서의 백엔드?
※ 참고) 이 글을 쓰는 저는 클라이언트 개발만 해봤습니다. (프론트엔드 / 안드로이드 클라이언트) 그러므로 이 글에 공감되지 않는다면 깊게 듣지 않아도 된다는 장점이 있습니다. 한마디로 뇌피셜이라는 말씀.
우선 백엔드 개발자가 하는 일을 100%라고 한다면, 우선 장애대응은 없다고 가정한다.
실제로 클라우드의 메모리나 CPU 점유율 등 서버에 대한 트래픽이 폭증했을 때가 가장 일이 많고 짜증나겠지만,
일단 처음 시작하는 단계에서의 백엔드 개발자를 상정하기 때문에 "기능을 개발하는 것"에 대해서만 얘기해 보자.
주변의 백엔드 개발자와 내가 경험했던 백엔드 개발자들이 하는 일을 단순화하라면 거의 불가능하다.
"데이터베이스에서 데이터를 가져와 암호화해서 클라이언트로 보내는 일" 정도로 말하기에는 너무 해야 할 일이 많다.
대략 내가 직접 경험하면서 옆에서 봤던 작업들을 얘기해 보자면,
- 클라이언트로부터 받아온 데이터를 DB에 쌓는 것
- 관리자 페이지를 구현하기 위해 계정별로 다른 권한과 하나의 테이블로 합치는 작업(비정규화 - 더 빠른 읽기를 위해)
- 회원가입과 로그인(인증), 그리고 코드 검증과 자동 배포를 위한 CI/CD 구성
- 운영자가 보기 편하게 데이터베이스 로깅(logging)을 정리하는 것 (정확히 말하자면 데이터 규격을 정리한다. 시각화나 디스플레이하는 작업은 프론트엔드 개발자의 영역이다.)
- 프론트엔드 개발자를 위한 데이터 규격 문서 작업
.. 등등 평소에는 10개 20개씩 많이 생각났는데 막상 글을 적으라니까 쉽지 않다.
리스트를 살펴보면 알겠지만,
스타트업이라고 해서 "제품만 만들지" 않는다.
초기에는 데이터를 쌓아야 하기 때문에 데이터를 쌓을 수 있는 백엔드 기능을 만들어야 한다. 물론 개별 데이터에 대해서는 프론트엔드 개발자들이 데이터를 보내주겠지만 이것마저도 구현하기 나름이다.
여하튼, 그래서 MVP만 구현했다가 회사가 커지는 과정에서 백엔드 개발자는 온갖 고생과 추가적인 작업을 하게 되는데
저 영상은 그 과정을 겉핥기로 겪어보기 딱 좋다.
1. 전체적인 구조를 알아야 한다.
백엔드 개발자는 싫든 좋든 간에 회사 제품에 대한 대략적인 구조를 알게 될 수밖에 없다.
그리고 알아야만 한다.
은행업에 대한 이해가 없다고 가정하고 들어보자.
토스 앱과 채널계 그리고 계정계가 통신한다고 한다. (전체적인 인프라 구조를 대충 알아야 함)
DB가 여러 개가 나뉘어서 트랜잭션 처리가 어려울 수 있다고 한다. 하지만 여러 개로 쪼개져있기 때문에 그만큼 스케일을 키우거나 오류를 잡기가 쉬운 편이다. (엄청 큰 서비스를 만들 때 MSA를 하는 기본 이유랄까..)
그리고 계정계라는 것은 성능을 희생하더라도 안정성이 중요해서 하나의 서버 애플리케이션, 데이터베이스 서버도 하나라고 한다.
그러니까 해당 데이터베이스 로직을 처리하는 코드 뭉치도 크게 보면 한 개라는 것이고,
그것을 처리하는 데이터베이스 프로그램도 통으로 하나가 되어있다는 것이다.
(단일한 프로그램은 단일한 파일을 말하는 것이 아닙니다. 이 정도는 아시죠?)
영상을 보면 아키텍처에 대한 장단점과 그 구조를 설명하고 있다.
스타트업도 마찬가지다. 제품이 커지기 전에는 굉장히 단순하게 서버를 구성할 것이다.
이 상태에서 어느 부분을 어떻게 바꿀 수 있을지를 미리 염두에 두면 좋다. (초창기에 그걸 몰라서 못하는 게 아니지만)
그래서 아키텍처에 대한 장단점을 미리 정리해 놓거나 자사와 비슷한 제품인 다른 오픈소스 코드를 공부해 두면 좋을 것 같다.
2. 여러 상황을 가정해 보고, 해결책을 찾는다.
4:43초쯤을 보면, 이런 설명이 나온다.
송금 서버의 DB에 저장해 두기만 하면 되지 않을까?
하지만 이러면 다른 은행 앱에서 토스로 송금한 것을 확인할 수가 없다.
이 가정적인 상황을 통해 타행 서버와 통신이 필요하며, 이것을 기록으로 동기화시켜야 한다는 사실을 알 수 있다.
백엔드 개발자에게 중요한 것 중 하나가 바로 "예외 처리"이다.
사실 거의 예외처리가 절반 이상이라고 보면 되는데, (백엔드 개발자와 일하면서 굉장히 많이 느낀 것)
예외 처리는 애초에 "예외 처리가 필요한 상황"을 인지해야지만 코딩이 가능하다.
돌이 어떤 방식으로 날아올지 모르는데 어떻게 돌을 위한 방어막을 쌓겠는가.
그래서 최대한 제품을 사용하면서 문제가 발생할 포인트를 미리 가정해 보는 습관이 중요하다.
몇 줄만 더 적어놨는데 나중에 큰 대참사를 피할 수도 있기 때문이다.
3. 고민하는 과정을 시각화한다.
프로그램을 만들 때 중요한 것은 무엇일까?
나는 작성하기 전에 손으로 대충 그려보는 것이라고 생각한다.
토스의 영상을 보면
중복 송금 문제방지 / 오래된 지연 송금 실패 처리 / 성공했는데 실패로 처리되는 문제 부분이 모두 단계별로 시각화되어 있다.
물론 유튜브를 만들기 위해 발표 자료를 만들어야 하니 시각화한 것을 보고 있는 것이지만
실제로 제품을 대충 말로만 하는 것보다 어떻게 데이터가 흐르는 지를 대충 적어보는 것은 매우 중요하다.
이를 전문용어로 DFD - 데이터 흐름도라고 부르곤 하는데,
(단어를 아는 것은 중요한 건 아니고)
미리 데이터가 어떻게 흐르는 지를 모듈별로 알고 있는 것이 백엔드 개발자에게는 매우 중요하다.
A라는 모듈과 C라는 모듈이 어떤 순서로 어떻게 작동하는지를 알아야 가운데에 개발할 B를 생각해내지 않겠는가.
이것과 비슷한 영상을 찾았는데
바로 위의 영상에서 얘기하는 기능별로 적어놓는 습관이다.
저 영상은 모바일 애플리케이션에 대한 이야기여서 백엔드와는 정확히 같지는 않지만,
해야 할 작업들을 세부적으로 쪼개고, 그다음 과정을 생각하는 것을 꼭 시각화해 보자.
정말로 중요한 작업이다.
4. 63빌딩도 벽돌 한 개부터
한 번에 네이버, 구글 같은 제품을 만들 수는 없다.
너무 당연한 거 아니겠는가.
그 두 가지 제품은 단순한 아이디어에서 시작했다.
네이버는 삼성 SDS의 사내벤처로, 구글은 논문의 "페이지랭크"라는 아이디어에서 시작된 제품이다.
어떤 것들은 너무 커서 시작이 보이지 않지만,
결국은 시작이 있었으니 큰 제품이 된 것이다.
백엔드 개발자는 보이지 않지만 제품을 구성하는 중요한 토양을 만드는 작업이다.
예쁘게 만들었어도 돌아가지 않는 웹페이지, 앱, 게임이 시장에서 성공할 리 있는가.
천리 길도 한 걸음부터라고 하나하나 순서대로 데이터의 흐름을 차분하게 살펴보고
작게 하나씩 하나씩 구현하면서 데이터를 주고받는 것을 연습해 보자.
변1) 바람의 나라는 초창기에 데이터베이스로 txt(메모장) 파일을 썼다고 한다. 그리고 일정 규모의 유저가 모인 이후에나 데이터베이스 프로그램을 도입했다고. 어떤 경우에는 일단 닥치고 구현하는 것이 제품의 성장을 따라잡는 것일지도 모르겠다.
변2) 사실 스타트업은 생존의 문제가 중요하기 때문에, 기능 개발이며 죽지 않는 서버며 여러 가지를 닥치는 대로 개발해야 할 때가 있다. 그러니까 생존하면 된 거지 완벽한 건 없다는 것으로 알아주셨으면.
변3) 요새는 직군이 다양해졌습니다. DevOps 엔지니어, DBA(원래 있긴 했음), 여러개를 다 하는 인프라 엔지니어 등. 직군 이름이야 사실 붙이기 나름 아니겠습니까. 모두 백엔드로 이해하고 작성했습니다.