웹 프레임워크를 직접 만들며 배우는 설계 철학
Go 언어로 웹 서버를 짜본 분이라면 Gin이라는 프레임워크를 한 번쯤 들어봤을 거예요. 가볍고 빠르기로 유명하죠. 이번 글은 그 Gin 같은 프레임워크를 직접 만들어보면서, 그 밑에 깔린 설계 철학인 'Simple over Easy(쉬움보다 단순함)'를 풀어낸 이야기예요. 단순히 코드를 따라 치는 튜토리얼이 아니라, '좋은 설계란 대체 뭔가'를 생각하게 만드는 글이죠.
잠깐, '단순'과 '쉬움'이 다른 말이라고요?
우리말론 둘 다 비슷하게 들리는데, 소프트웨어 설계에선 완전히 다른 개념이에요. 이건 클로저(Clojure) 언어를 만든 리치 히키(Rich Hickey)가 'Simple Made Easy'라는 유명한 강연에서 정리한 구분이에요.
Simple(단순함)은 객관적인 개념이에요. '하나가 다른 것과 얼마나 얽혀 있지 않은가'를 뜻해요. 어원이 'sim-plex', 즉 '한 겹'이라는 뜻인데, 여러 관심사가 서로 꼬여 있지 않고 딱 하나의 역할만 하면 단순한 거예요.
반면 Easy(쉬움)는 주관적이에요. '나한테 얼마나 익숙하고 손 닿기 편한가'를 뜻해요. 어원도 '가까이 있다'는 뜻이거든요. 내가 늘 쓰던 익숙한 도구는 '쉽지만', 그게 내부적으로 여러 기능을 뒤엉키게 묶어놨다면 '단순하지 않을' 수 있어요.
핵심은 이거예요. 당장 쓰기 편한(Easy) 게 반드시 좋은 설계(Simple)는 아니라는 것. 마법처럼 다 알아서 해주는 프레임워크는 처음엔 쉽지만, 규모가 커지고 문제가 생기면 뭐가 어디서 꼬였는지 못 찾아서 오히려 발목을 잡거든요.
Gin이 택한 길
Gin이나 이 글에서 만든 프레임워크는 '단순함' 쪽을 택해요. 예를 들어 웹 프레임워크의 핵심 부품 몇 개를 볼게요.
라우팅(routing), 그러니까 '/users/123 같은 주소가 들어오면 어느 함수로 보낼지 정하는' 부분은 그 일만 딱 해요. 미들웨어(middleware)는 요청이 처리되기 전후에 끼어드는 로그 남기기, 인증 확인 같은 작업을 담당하는데, 이것도 서로 독립적으로 겹겹이 쌓을 수 있게 만들어요. 각 조각이 자기 일만 하고 서로 안 얽히니까, 필요한 것만 골라 조립하고 문제가 생겨도 어느 조각인지 바로 짚을 수 있죠.
Go 언어 자체가 원래 이런 철학이에요. 상속이나 마법 같은 기능을 일부러 빼고, 명시적이고 단순한 걸 선호하죠. 그래서 Go로 프레임워크를 만들면 자연스럽게 이 방향으로 흘러가게 돼요.
업계 흐름에서 보면
이 논쟁은 웹 프레임워크 세계의 오랜 주제예요. 한쪽엔 레일즈(Rails)나 장고(Django)처럼 '다 해주는' 풀스택 프레임워크가 있어요. 처음 시작할 땐 정말 쉽고 빠르죠. 반대쪽엔 Gin이나 Flask, Express처럼 '핵심만 주고 나머진 네가 골라' 하는 미니멀한 쪽이 있어요. 조립할 게 많아 처음엔 손이 더 가지만, 각 부분을 이해하고 통제하기가 좋아요.
어느 쪽이 무조건 옳다는 건 아니에요. 다만 'Easy(쉬움)'만 좇다 보면 나중에 복잡함의 대가를 치른다는 걸, 이 글은 프레임워크를 직접 만들어보며 몸으로 보여줘요.
한국 개발자에게
라이브러리나 프레임워크를 고를 때 '이거 시작하기 쉽대'만 보고 결정한 적 없으신가요? 이 글의 교훈은, 도입할 때의 편함과 오래 유지보수할 때의 단순함을 나눠서 보라는 거예요. 특히 팀 규모가 커지거나 서비스가 오래갈수록, 마법 같은 편리함보다 '뭐가 어떻게 도는지 훤히 보이는' 단순함이 훨씬 값져요.
그리고 무엇보다, 자기가 매일 쓰는 프레임워크를 축소판으로라도 직접 만들어보는 건 최고의 공부예요. 라우터가 어떻게 주소를 매칭하는지, 미들웨어가 어떻게 체인으로 엮이는지 직접 짜보면, 남이 만든 도구도 훨씬 깊이 이해하게 되거든요.
마무리
"쉬운 것에 끌리되, 단순한 것을 택하라." 이게 이 글이 남기는 한 문장이에요. 여러분이 지금 쓰는 도구는 '쉬운' 쪽인가요, '단순한' 쪽인가요? 그 선택이 6개월 뒤의 여러분을 편하게 할지 괴롭게 할지, 한번 떠올려보면 좋겠어요.
🔗 출처: Hacker News