백엔드와 DevOps 그 사이 어딘가

한번쯤은 정형적인 자기소개서가 아닌, '내가 왜 이 길을 택했는지' , '앞으로의 계획은 무엇인지' 를 정리해두고 싶었다.

몇 번이고 언급했듯이 이 블로그는 내가 현업에 들어간 이후에도 꾸준히 업데이트하고, 스스로를 점검하는 스케치북처럼 활용할 예정이기 때문에 이 글 역시 누군가에게 보여주기 위함이라기보다 몇 년 후의 내가 다시 돌아봤을 때 지금의 마음가짐과 방향성이 얼마나 변했는지, 그리고 어떤 계획을 이뤘는지를 돌아보는 척도가 될 거라고 생각하며 이 글을 시작해본다.

백엔드를 선택한 이유

예전에는 웹마스터 혹은 웹프로그래머라는 이름 아래 지금의 백엔드와 프론트엔드라는 직군의 경계조차 없었던 시절이 있었다. 지금 말하는 풀스택 개발자가 그때는 디폴트였었다.

그러다 AJAX와 JQuery의 등장을 계기로 웹디자이너와 퍼블리셔가 분리되고, 그 속에서 점차 프론트엔드라는 개념이 생기기 시작하면서, 점점 각자의 역할이 분리되며 지금은 아예 전혀 다른 개발 생태계를 구축하게 되었다고 알고 있다.

그 흐름에 따라 나는 개발을 시작하면서 두 직군 중 하나를 선택해야만 했는데, 지금까지도 바뀌지 않은 확고한 신념이 있다.

"백엔드는 잇몸, 프론트엔드는 이빨이다."

이빨이 없어도 잇몸으로 씹을 순 있다. 하지만 잇몸이 없는 이빨은 그 자체로 설 곳이 없다.
그렇다고 내가 프론트엔드의 중요성을 간과한다거나 무시하는 건 아니다. 오히려 패션과 디자인에도 관심이 많고, 취미로 그림까지 그릴 만큼 시각적 감성의 중요성도 잘 알고 있다.

다만, 무엇이 먼저 존재해야 하는가? 를 기준으로 생각했을 때, 나는 백엔드가 훨씬 더 핵심적인 분야라고 느꼈고, 그런 관점에서 백엔드를 선택했다.

그리고 만약 풀스택을 목표로 한다면, 프론트에서 백엔드로 가는 것보다 백엔드에서 프론트로 넘어가는 흐름이 더 자연스럽다고 판단했다.

많은 언어들 중에서 파이썬을 택한 이유

한마디로 정리하자면,

홍대병 혹은 힙스터.

한국은 소위 말하는 '자바공화국' 이다.
대다수의 IT 산업구조가 공공기관 프로젝트를 위시한 정부 + 대기업 주도의 SI 프로젝트이고, 안정성을 최우선으로 삼는 그 구조에서는 자바(Spring)의 점유율이 과장을 조금 보태 90%에 달한다고 해도 무리가 없다. 그에 따라 수많은 부트캠프들도 절대다수가 자바(Spring)였고, 그 외에 선택지라곤 주류 언어 중에서는 파이썬이 거의 유일했다.

난 그런 틀에 박힌 기술 선택 구조가 맘에 들지 않았다. 흔해빠진 주류보다는 비주류를 택하고 싶었다. 그 선택이 나만의 기준과 정체성의 표현이라고 느꼈다. 솔직히 말하면 지금도 딱히 후회는 없다.

다만 내가 취업을 준비 중인 일본 시장에서는 파이썬이 한국보다 더 마이너하다는 게 문제라면 문제다.
한국은 그래도 스타트업을 중심으로 FastAPI나 Django 등의 도입 사례가 늘고 있지만, 일본은 아직도 '파이썬 = AI' 라는 고정관념이 업계 전체에 뿌리 깊게 박혀있다는 느낌을 받았다.
실제로 취업 준비를 하면서 공고들을 살펴보면 파이썬은 백엔드 언어가 아닌 '머신러닝을 위한 언어' 처럼 취급된다.

개발을 시작한 지도 어느덧 9개월 정도가 지났다. 그러면서 느낀 점은 파이썬이든, 자바든, 고랭이든 하나의 언어를 자유롭게 다룰 수 있게 되면, 결국 컴퓨터 언어라는 건 서로 통하는 부분이 많기 때문에 진짜로 당장 빌어먹을 정도로 취업이 안된다면 그때는 자바 공부를 하지 않을까 싶다.

하지만 지금 이 순간까지는 9개월 동안 함께하며 직접 결과물을 내면서 익혀온 파이썬이라는 언어에 큰 불만이 없다. 그래서 당분간은, 그리고 앞으로도 한동안은 파이썬을 조금 더 깊이 있게 파고들어볼 생각이다.

프레임워크 선택 - Django VS FastAPI

이건 사실 힙스터 픽이 아니었다. 과거 포스팅인 Trade-Off에 관한 고찰에서도 언급했지만, 부트캠프 당시 커리큘럼은 Flask -> Django -> FastAPI 순서였고, 강의량은 Django가 제일 많았다.

Flask 강의 말미에 주어진 첫 실전 과제는 간단한 심리테스트 웹앱이었다. 예제 코드가 주어졌고, 그것을 분석하고, 템플릿을 약간 수정해서 결과를 내보면 되는 그런 과제.

위에서 힙스터 픽이 아니라고 했지만 지금 다시 생각해보니까 난 원래 천성이 그런 놈인 것 같다. 그 과제가 맘에 들지 않았다. 남이 짠 코드를 분석하는 것도 짜증났고, 이왕 만드는 거 제대로 만들어보자라는 생각이 들어, 다시 강의를 돌려가며 바닥부터 제작했다.

그렇게 온몸비틀기를 하며 제작한 내 첫 프로젝트는 지금 다시보면 구데기지만 그때 수준을 감안하면 나쁘지 않았고, 멘토님에게 주워들은 Supabase와 Koyeb을 사용해서 배포까지 성공했기에 나중에 후배 기수들에게도 참고용 레퍼런스로 사용되었다는 말을 들었다. 그렇게 Flask와 친해진 나는 다시 멘토님과 함께하는 즐거운 심화 과제에게 탈탈 털려가며 Django는 시작도 못한 상태였다.

그러다 어느 날, 팀 프로젝트가 내부 불화로 깨져서, 혼자 프로젝트를 하게 되었는데, 원래 개인 프로젝트가 허락된 환경이 아니었던지라 가이드라인이랄 것도 없었고, 주제도 정해지지 않은 상태였다.
프레임워크 선택부터 온전히 내 몫이었다. 참고로 팀이 깨진 이유는 백엔드와 프론트엔드간의 충돌이었고, 백엔드끼리는 사이가 괜찮았다. 나를 제외한 팀원들은 Django에 익숙했기에 Django를 쓴다고 했다.

난 그때 Django도 FastAPI도 제대로 학습한 상태가 아니었고, Django보단 Flask에 익숙했기에 구조가 비슷하면서 좀 더 진보된 FastAPI를 사용하기로 결정했다.

그 선택은 결과적으로 내 성향에 가장 잘 맞는 선택이었다.

틈틈히 다른 팀원들과 소통하며 Django의 코드나 구조를 몇번 살펴볼 기회가 있었는데, 너무 엄격하고 정해진 틀 속에 코드를 집어넣는 듯한 구조였다. 한마디로 정리하자면 내가 프레임워크를 쓰는 게 아닌, 프레임워크에게 나를 맞춰야 하는 느낌이었다.

그렇게 난 Django를 유기했다.

DevOps 뽕맛을 느끼게 된 계기

바로 위에서 언급한 그 프로젝트가 바로 지금 당신이 읽고 있는 이 cliche.life다. 프로젝트의 총 기간은 20일이었고, 이미 불화로 팀이 깨진 시점은 2주차가 거의 끝날 때 쯤이었다. 혼자서 문서를 작성하고, 개발을 시작해야 했고, 빠른 MVP 개발이 필요했다.

그게 지금 바로 전 포스트인 이사인 줄 알았는데 사실은 재건축이었던 건에 대하여의 변명이라고도 볼 수 있다. 왜 초기 설계를 그따구로 했냐고? '초기 설계를 할 시간이란 게 없었다' 가 내 대답이다. 웹앱이라고 하기엔 애매한 스크래퍼 MusicLab과 로그인도 없고 admin만 존재했던 빌어먹을 심리테스트를 제외하면 내 첫 웹 어플리케이션이라고 할 수 있기 때문이다.

잡설이 길어졌지만, DevOps의 진가를 알게 된 건 프로젝트 발표 때였다.
프로젝트의 필수 요건은 AWS를 통한 배포였는데, 난 항상 Docker를 사용해야 한다는 강박이 있었다. 강박이라기보단 내 정신적 지주인 심화반 멘토님의 가르침이었는데, "로컬 실행을 지향하라, Docker를 이용하면 모든 환경에서 같은 환경을 유지할 수 있다."에 충실히 따르고 있었지만 그 이유는 이해를 하지 못하고 있었다.

하지만 정작 배포를 할 때가 다가오자 그 이유를 알았는데, 난 배포에 걸린 시간이 길게 잡아야 한 시간 정도였다. AWS 콘솔의 설정 같은 걸 합쳐서, 다른 팀으로 이적간 기존 팀원의 상황을 보니 매번 호스트로 접속해서 git pull을 치고 있었고, 프론트엔드는 따로 vercel로 배포를 해서 그 둘 사이의 연동도 제대로 이어지지 못하는 걸 보면서 이게 이렇게 어려울 일인가? 라는 생각이 들었다.

그리고 발표날이 되었는데, 결과적으로 배포에 성공한 건 1인팀인 나밖에 없었다. 그때서야 멘토님의 깊은 뜻을 이해했다. "Docker는 신이구나" 라는.

그때부터 지금까지 이 블로그를 디벨롭하는 과정에서 GitHub Actions를 이용한 배포 자동화나, ELK 스택을 이용한 로그 시각화 & 관리와 같은 운영 중심의 작업을 하나씩 도입했다. 과거 게시글을 보면 알겠지만, 이는 '있어보여서' 도입한 게 아닌 실제로 운영을 하다보니 '필요를 느껴서' 도입하게 된 것들이고, API 설계도 물론 중요하지만 '서비스를 안정적으로 운영하고, 생산성을 끌어올리는 것' 그게 얼마나 결정적인 가치이며 역할인지를 실감했다.

그래서 지금 내 목표는 명확하다. 백엔드에서 실무 경험을 쌓고, DevOps로 확장한다." 물론 DevOps는 신입이 진입하기에는 무리가 있는 직무기에, 우선은 백엔드에서 시스템을 다뤄보며 실력을 쌓고, 그 경험을 기반으로 개발과 운영 모두를 책임질 수 있는 개발자로 성장하고 싶다.

결론

난 욕심이 많다. 백엔드도 하고 싶고, 데브옵스도 하고 싶고, 가끔씩 들어오는 봇 공격에도 민감한 걸 보면 보안도 챙겨야 직성이 풀리고, 아임웹이나 워드프레스의 템플릿보다는 나은 지금의 디자인에도 만족 못하는 걸 보면 디자인도 하고싶고.

결론은 '1인 개발자' 인 것 같다. 여기서의 1인은 '협업을 못하는' 이 아닌 정말로 다재다능한, 혼자서도 모든 걸 할 수 있지만 협업이라는 과정을 통해 더 많은 산출물을 만들 수 있는 개발자가 되는 게 목표인 것 같다. 그 모든 흐름을 온전히 이해하고, 적재적소에 적절한 리소스를 사용할 수 있다면, 그리고 내가 약하거나 미처 생각하지 못한 부분을 협업을 통해 더 개선할 수 있다면, 즉, 내가 원하는 개발자의 모습은 단순히 기술을 아는 사람이 아닌, 전체 시스템의 맥락을 설계하고 운영할 수 있는 사람이다.

앞으로 내가 어떤 선택을 하게 되든 그 모든 선택은 내가 직접 맞아보고, 판단하고, 책임지는 방식으로 이루어질 것 같다. 이 블로그는 그 과정과 삽질, 결과를 기록하고 증명하는 도구로 누군가에게 조금이나마 참고라도 되었으면 한다.