내가 요즘 서버 개발을 거의 하지 않는 이유

나는 첫 커리어를 서버 개발자로 시작했다. Android 개발자로 최초 구직활동을 했었지만, 만든 앱이 바둑이라 그런가 서버 개발자로 채용됐다. 이직할 때마다 서버 개발자였으며, 지금도 서버 테크리더로 채용되었다만... 그럼에도 불구하고 요즘은 서버 개발을 거의 안 하고 있다. 내가 월급 루팡이라 그런 건 절대 아니다😂

개인적인 생각: 항상 시대의 흐름에 편승한다

내가 최초 구직활동을 하던 시기는 19년도이고, 당시에는 웹에서 모바일로 트래픽이 상당수 넘어간 시점이었다. 웹을 개발하더라도 반응형을 고려하지만, 반드시 모바일을 먼저 생각할 정도는 아니었던, 그런 과도기였다. 나는 이러한 흐름 때문에 모바일 개발에 항상 관심이 있었고, 기회가 될 때마다 모바일 개발을 도전했었다.

서버 개발은 트렌디하지 못한가

서버 개발이 트렌디하지 못하다고 생각하지는 않는다. 오히려 필요한 경우가 많고, 트래픽이 커지면 어쩔 수 없이 지금 사용하던 것을 마이그레이션해야 할 것이다. 단지 클라우드의 발전으로 스타트업에서 서버 개발이 필요한 경우가 생각보다 별로 없어졌을 뿐이다. 만약 클라우드 서비스를 이용하는 것보다, 직접 개발하는 것이 충분히 빠르다면, 그런 선택을 하는 게 더 스타트업스럽다. 나는 클라우드 서비스를 학습해서 사용하는 게 이득이라고 봤고, 이 서비스들을 적극적으로 활용할 뿐이다.

내 서버 개발을 대체한 소프트웨어들

Firebase의 authentication, firestore, storage 등이 있다. AWS에는 cognito 정도만 서버개발 대체용으로 사용하는 듯. Google은 firebase외에도 무궁무진하다. 이미 G-suit을 사용하고 있다면, goole apps(Spreadsheet, Docs, Forms 등) + google apps script 조합이란 선택지가 강력해진다.

마지막으로 Notion과 Slack이 있다. Notion은 19년도부터 사용해왔는데, 25년쯤 되니까 버튼 트리거도 구현 가능해지더라. 버튼을 구현하면, Notion에서 각종 API 호출도 가능하다. 덕분에 CMS 개발(클라이언트 개발 포함)시간을 적게는 수주, 많게는 수개월을 절약할 수 있었다.

아주 가끔 API 서버(알림 보내기, 메일 보내기, 복잡한 트랜잭션 처리, 스케줄러 등)가 필요한데, 이 경우에만 서버 개발을 하게 되었다.

비용적 이점

비용이란 것에 정답은 없긴 하다. 보통 개발자 인건비가 가장 많은 부분을 차지하니, 개발 공수를 적게 잡을 수 있으면 돈을 많이 아낄 수 있다. 만약 Notion도, Slack도, G-suit도 사용하지 않는 회사이고, 전형적인 서버 개발을 자주 하던 회사라면 오히려 비용이 늘어날지도 모르겠다.

내 기술 스택 특수성

나는 서버 개발 시에 NestJS를 가장 많이 사용한다. NestJS 서버의 약점은 원자적 처리가 약할 수 있다는 것이다. 프로세스 종료 직전 로직을 구현하지 않으면, 컨테이너 종료 명령어에 의해 로직 실행 도중 종료되어 버그를 발생시킬 수 있다.

이런 환경에서 원자성을 최대한 보장 받기 위해 Serverless 서비스를 이용하는데, AWS lambda나 GCP cloud run이 적합했다. 근데 serverless 모델이 개발의 양을 줄여주진 않더라. 특히 개발환경 구축이 복잡했다. 이 복잡성을 덜어내면서 원자성을 보장 받으려니, 서버 코드를 줄여야 했고, 설계를 더 신경쓰는 방법 밖에 없었다.

보안은? 유효성 검사는?

보안 처리

Firestore의 rules를 이용하면, 접근 제어는 충분히 가능하다. 대신 데이터모델링(설계)에 많은 시간을 투자해야 한다. 이전엔 사용자 화면 관점을 기준으로 논리적 데이터모델링을 하고, 액션/트래픽/원자성 기준으로 물리 설계를 고려하면 되었지만... 이젠 접근 제어까지 고려해서 설계해야 한다.

아쉽게도 연산 결과에 대한 보안 처리는 서버에서 하는 게 맞다. 연산적 보안이 보장되어야 한다면 스케줄러로 연산을 하던, API호출 시 계산하던, 메모리에 상주하는 프로세스가 필요하다. 서비스에 따라 다르겠으나, 내가 경험한 스타트업의 CRUD는 절반 정도는 연산적 보안 처리가 불필요했다. 그저 접근 제어만 필요했을 뿐.

유효성 검사

유효성 검사는 어차피 클라이언트에서도 해야 한다. 클라이언트에서 데이터를 입력받을 때, 데이터를 보여주려고 불러왔을 때 한번씩은 해야 한다. 이건 서버 개발자가 훌륭하다 하더라도, 장기적으론 필요하다. API가 v2로 마이그레이션 될 수 있기 때문이다. 개발하다보면 데이터 유효성 검사를 위해 서버를 추가할 이유는 별로 없다. 해킹을 통해 이상값을 넣더라도, 보여주려고 불러온 순간 이상값을 필터하기 때문에 보통은 큰 문제가 없다. 또 해커도 그 짓을 해서 얻는 게 어느정도는 있어야 하는데, 보통은 고생 대비 얻을 게 없는 경우가 많은 것도 한 몫 한다. 애초에 접근 제어만 잘 처리하면, 해커가 할 거라곤 자기 접근 권한 내에서 이상값을 넣거나 지우는 정도 뿐이다.

내가 구글 드라이브에 악성코드를 올린들, 구글 드라이브 서버는 안전하지 않겠는가? 같은 맥락이다.

기술적 이유로 서버 개발을 하는 경우

아쉽게도 전형적인 DBMS를 주로 사용하는 경우, 서버 코드 작성이 빠른 것 같다. Firestore의 rules를 구현해서 관계형 DBMS에 적용할 순 없으니... 이론상 가능은 하겠지만, 스타트업스럽지 않기 때문에 내가 선택할 것 같지는 않다. Rules를 구현하고 있느니, NestJS를 포기하고, Django를 쓰고 말지.

또 기존 시스템이 있다는 것 자체가 접근제어체계가 갖춰져 있을 확률이 높다.

서버 개발을 적게 할 뿐, 백엔드 개발은 종종 한다

전형적인 API 서버 개발량이 크게 줄어들었을 뿐, 여전히 백엔드 개발은 이전과 비슷한 비율로 한다. CLI라거나, CI/CD 구축을 위한 코드파이프라인 작성이라거나, Scheduler 개발이라거나...