백엔드 개발을 공부하며 들었던 생각들

· Column, Backend

베스트 프랙티스가 뭘까

백엔드 개발을 많이 많이 하고 싶지만 항상 생산성 측면에서 걸리는 부분이 있다. 베스트 프랙티스에 대한 노하우가 없다는 점이다. 예를 들어 스프링에서 예외를 다룰 때 어느 레이어에서 처리하는게 옳은가?라던지, 동작 여부 자체와는 크게 관련이 없는 아키텍쳐 관점에서의 베스트 프랙티스를 알지 못한다는 점이 계속 생산성의 발목을 잡는다. 짜면서도 이게 맞는 설계인지에 대한 확신이 없을 때가 많다.

열심히 이것저것 찾고 토비의 스프링도 읽고 이펙티브 자바 같은 책도 읽으면서 최대한 간극을 좁혀나가보려 애쓰고 있지만 마치 대학에 처음 들어갔을 때 느끼는, 답지 없는 교재를 푸는 그런 느낌이 계속되는 것 같다.

넓고 넓은 백엔드 세상

프론트엔드나 데브옵스와는 비교도 안될 정도로 백엔드의 범위가 넓다고 느꼈다. 프론트엔드, 백엔드, 데브옵스 중 어떤 것이 더 깊은지 단정지을 수는 없지만 어떤 것의 범위가 가장 넓냐고 하면 백엔드라고 생각한다. 무엇을 하겠다고 확실하게 다짐하지 않으면 어느 순간 이것저것 찔끔찔끔 하고 있는 나 자신을 발견하게 될 것만 같다.

스프링의 세계

자바를 싫어했었다. 학부 2학년 자료구조 강의 이후로 자바를 쓴 적이 없다. 길고 긴 클래스 이름들과 새로운 라이브러리를 추가할 때마다 배워야하는 클래스 정보들, 타입 관리 등 스크립트 언어에 길들여졌던 나에게는 너무나 귀찮은 점들이였다. 그러던 중 대학원에서 디자인패턴 강의를 들을 기회가 생겼고 나에게 새로운 관점을 열어주었다. 토비의 스프링을 읽으며 스프링에 빠져들었다. 스프링의 의존성 주입과 싱글톤의 보장, 객체의 프록싱과 AOP 등 너무나 흥미로운 것들 투성이였다. 이걸로 뭘 만들어볼까 고민했다. 프론트엔드를 짤 수 있지만 프론트엔드 개발에 쓸 시간조차 스프링 코드를 짜는데 쓰고 싶었다. 그래서 디스코드 봇을 만들었다. 디스코드 봇은 디스코드가 클라이언트 역할을 해주니까. 비록 REST가 아닌 TCP 통신으로 연결되는 프로젝트였지만 스프링의 철학을 느끼며 코드를 짜기에는 충분했다.

스프링이 내게 가르쳐준 것

몇 달 간 스프링을 보면서 한동안은 스프링만이 정답이라는 생각이 들었었다. 하지만 요즘 들어 생각이 조금씩 바뀌고 있는데, 굳이 스프링이 아니여도 스프링의 철학을 지키면서 코드를 짠다면 그 어떤 언어의 어떤 프레임워크여도 상관없지 않을까.

개발은 언어와 프레임워크가 아니라 철학으로 하는 것이라는 점. 스프링이 내게 가르쳐준 것이다. 어떤 생각, 어떤 철학을 가지고 소프트웨어를 설계할 것인가. 그리고 그 철학을 위반하지 않으면서 소프트웨어를 개발할 수 있는 방법은 무엇인가. 철학을 지키는 방법은 무엇일까. 스프링은 철학을 지킬 수 있도록 여러 가지 방법으로 유도하고 강제한다. 그렇다면 다른 언어, 다른 프레임워크에서도 철학을 지키며 개발할 수 있도록 마련된 장치가 있을까? 없다면 내가 만들 수도 있지 않을까?

JVM, Servlet과 같은 스프링의 기반이 되는 기술을 공부하면서 과거를 되짚어 보았다. 나 자신을 반성할 수 있는 시간이기도 했다. 내가 프론트엔드 개발자로 일할 때 V8 엔진에 대해, 브라우저의 동작 원리에 대해 공부한 적이 있던가? 이벤트루프가 있고 싱글스레드에 비동기로 동작한다는 점 정도만 알고 있었다. 브라우저 동작 원리는 간단하게만 짚었었다. repaint 뭐시깽이… 내가 데브옵스 엔지니어로 일할 때 쿠버네티스의 어디까지 공부했었지? 등 과거를 반성하게 되는 시간이기도 했다.

딥다이브와 코드짜기

개발은 이론과 실습의 조화가 중요한 것 같다고 느낀다. 코드를 많이 쳐봐야 하는 것 같다. 이론적 딥다이브가 된다면 그 다음은 코드를 무조건 많이 쳐봐야 하는데 그게 생각보다 쉽지 않다. 매번 맥북 앞에 앉아서 프로덕트를 만들기 위한 코딩이 아닌 공부를 위한 코드를 치는 작업은 생각보다 지루하다. 항상 반성한다. 코드를 많이 쳐야지.

엔지니어로 살아남기

어떤 회사를 가게될지 아직 모르겠다. 전문연 구직에 시간을 좀 두고 여유롭게 구하고자 한다. 급할 수록 돌아가라고 했으니 조금 돌아가보려 한다. 회사를 구할 때 가장 중요한 점은 내가 좋아하는 프로덕트에 기여할 수 있냐는 점이다. 내가 좋아하는 프로덕트를 만들 때는 일이라는 생각이 들지 않으니까 즐겁게 임할 수 있지 않을까.