HUHS.net 2.0 백엔드 개발기 #1 : 어떤 기술을 쓸 것인가?

HUHS.net 2.0을 만들게 된 계기

제 이력을 보신 분들은 아시겠지만, 저는 한양대학교 컴퓨터 중앙동아리인 HUHS에서 굉장히 오래 활동했습니다. 1학년이었던 2015년에 입부해서, 현재까지 활동을 하고 있으니, 글을 쓴 2023년 기준으로 벌써 8년차 회원이 됬네요. 동아리에서 회장/부회장 1번씩 해 보고, 거의 매 년 스터디를 1회 이상 열면서 열심히 활동했고, 그 덕분에 좋은 사람들을 참 많이 만나게 되었습니다.

저희 동아리에는 휴즈넷이라는 웹사이트가 있습니다. 2015년이었나, 16년이었나... 그 때쯤에 제 동기와 선배님들이 만드신 동아리 소개 및 게시판, 출석, 위키 등의 기능을 담고 있는 웹사이트죠. 몇 년간 유용하게 사용하고 있었지만, 이걸 만들었던 회원들이 전부 졸업을 하면서 인수인계가 거의 이루어지지 않았고, 코드 또한 거의 개선된 적이 없었습니다. 이 때문에, 가면 갈수록 여러 불편함과 버그가 눈에 띄게 되었지만, 유지보수를 할 방법은 거의 전무한 상황이었습니다.

작년 말에, 당시 동아리 부회장으로부터 위 문제를 전해 듣게 되었고, 둘이서 이야기를 하다가 '이왕 이렇게 된 거, 나 졸업하기 전에 휴즈넷 2.0을 새로 만들어볼까?'라는 생각을 하게 되었습니다. 처음에는 생각만 있었지만, 저랑 이 이야기를 했던 후배가 적극적으로 이 프로젝트를 추진하려고 했고, 결국 이번 1월부터 3월까지 휴즈넷 2.0을 개발하는 팀이 꾸려지게 되었습니다.

현재 팀원은 기획+검수 2명, 디자인 2명, 웹 프론트 1명, 서버 1명으로 구성되어 있으며, 제가 담당한 부분은 서버입니다. 이 개발기는, 휴즈넷 2.0을 개발하면서 겪었던 다양한 일들과, 그 과정에서 제가 어떤 생각을 했는지, 왜 그런 결정을 내렸는지 정리하기 위해 쓰는 글입니다.

HUHS.net 2.0, 뭐로 개발할 것인가?

우선, 휴즈넷 2.0 서버를 개발하기에 앞서, 어떤 DB를 쓸 지,어떤 프레임워크와 언어를 쓸 지 고민을 했습니다. 제 스스로도 생각해보고, 주변 개발자들에게 조언을 구한 결과, 아래의 기술 스택을 사용하기로 했습니다.

• DB : MySQL
• 프레임워크 : Node.js + Express (+TypeORM)
• 언어 : TypeScript
  

왜 Node.js + Express를 사용하기로 했는가?

휴즈넷 백엔드를 구현할 기술을 선택하는 기준

우선, 기술 스택을 선택하기 위한 기준을 먼저 세웠습니다. 그 기준은 아래와 같습니다.

1. 학습하기 쉬운 기술이어야 한다.
   정확히는, 초기에 입문하기 쉬운 기술이어야 한다.
2. 인터넷에 자료가 많고, 사용하는 사람이 많은 기술이어야 한다.
3. 유지보수하기 쉬운 기술이어야 한다.
   
   

위와 같은 기준을 세운 이유

각 기준에 대한 이유는 다음과 같습니다.

1. 초기에 입문하기 쉬운 기술
   a. HUHS 회원들 중, 처음부터 개발을 잘 아는 상태로 들어오는 분들은 거의 없었습니다. 오히려 개발을 잘 모르는 상태로 입부하고, 이 동아리에서 다양한 활동을 하면서 개발 지식을 익히고, 성장하는 사람들이 대부분이었습니다. 즉, 처음부터 개발에 익숙한 사람은 거의 없었습니다.

   b. 또한, 백엔드 개발자를 지망하는 사람도, 백엔드를 할 줄 아는 사람도 굉장히 적은 편이었습니다.

   ⇒ 이 때문에, 저 다음에 휴즈넷 서버를 맡게 될 사람은 백엔드에 익숙하지 않은 초보 개발자가 될 가능성이 더 높다고 생각했습니다. 그리고 이런 측면 때문에, 초보 개발자들이 초기에 입문하기 쉬운 기술로 서버를 짜야 휴즈넷을 계속 발전시켜 나갈 수 있다고 봤습니다.
   

2. 인터넷에 자료가 많고, 사용하는 사람이 많은 기술
   a. 위의 1번 내용과 연결되는 부분입니다. 인터넷에 자료가 많고, 물어볼 사람이 많은 기술을 쓰면, 문제에 대처하기도 더 편합니다. 구글링하면 거의 모든 것이 나오기 때문입니다.

   b. ‘사용하는 사람이 많은 기술’을 중요하게 여긴 이유는, 실제로 휴즈넷 백엔드를 관리하면서 얻게 되는 포트폴리오와 지식을 실제 취업 현장에서도 활용할 수 있게 하고 싶었기 때문입니다. 만약 사용하는 사람이 많지 않은, 특히 실무에서 잘 쓰지 않는 기술로 서버를 짜게 될 경우, 여기서 얻는 포트폴리오를 취업할 때 써먹기 쉽지 않을 것이라고 생각했습니다. 저 뒤에 이 프로젝트를 맡게 될 개발자 분이, 이 프로젝트를 유지보수하고 개선하는 경험을 하고, 그런 경험이 그 분들의 취직과 취업에 도움이 되었으면 하는 바람이 있었습니다.

3. 유지보수하기 쉬운 기술
   : 유지보수가 어렵다면, 사실상 제가 만든 백엔드 서버 코드를 다른 누군가가 이해하거나 건드릴 수가 없게 되고, 그 상태가 유지되면 결국 휴즈넷 3.0을 만들어야 하는 사태가 나올 것이라고 생각했습니다.
   
   

위 조건에 맞는 기술 후보군

1. Flask
   • 파이썬 기반
   • 장점 : 초기 학습 곡선이 굉장히 낮고, 개발 속도가 빠릅니다. 인터넷에 관련 자료도 풍부한 편입니다.
   • 단점 : 유지보수가 어렵고, 실무에서 사용하는 빈도가 높지 않습니다.
2. Node.js + Express
   - JavaScript / TypeScript 기반
   - 장점 : 초기 학습 곡선이 꽤 낮은 편이고, 이용자 수가 굉장히 많습니다. 실무에서도 많이 쓰이는 편이고, 유지보수성도 괜찮은 편입니다.
   - 단점 : 아무래도 파이썬 기반 기술들보다는 입문 난이도가 상대적으로 높은 편입니다.
   
   

주변 개발자들의 조언

1. 박** (HUHS 37기)
   • 중요 포인트는 다음 두 가지라고 생각한다.
     • 가장 많은 사람이 관심을 갖고 참여할 수 있는 플랫폼인가?
     • 해당 플랫폼으로 가이드를 줄수 있는 실무자가 있는가?
   • 장기적으로 Python으로 개발하려는 사람이 많으면 → Django나 Flask
     반대로, 장기적으로 JavaScript로 개발하려는 사람이 많으면 → Express
     가 좋다고 생각한다.
   • Node.js에 대한 평가 : 커뮤니티도 많고, 배우기 쉽다.
   • Express에 대한 평가 : 보통 Node.js + Express 조합을 많이 사용한다. 이게 학습 곡선도 더 낮은 편.
2. 홍** (HUHS 37기)
   • Flask가 제일 나아보이긴 하는데, 자료는 Express가 더 많다.
     • 부트캠프에서 Node.js를 많이 가르치다 보니, 여기서 공부한 사람들이 남긴 Node.js + Express 관련 자료가 압도적으로 많다.
3. 정** (HUHS 34기)
   • 대중적이고, 오래갈 웹 기술이라면 노드가 낫다.
   • Flask 프로젝트는 유지보수하기 힘들다. 구조가 딱히 잡혀 있지 않다 보니, 오히려 구조를 잡을 줄 아는 사람이 계속 작업해야 한다는 문제가 있다.
   • 구조가 안잡혀있다는 건, 사람 손 거치면서 빠르게 망가지고, 결국 유지 보수가 불가능한 상황이 나올 거라고 본다. 그래서 Flask는 추천하지 않는다.
   • 백엔드를 하겠다고 나올 사람은 별로 없다. 그러니 그냥 대중적이고 자료가 많은 Node.js로 작업하는 게 속 편할 거다.
4. 2023.01.13 추가 : 우리 회사 백엔드 개발자님
   • 유지보수 고려하시는 거라면, 사실 Node.js보단 Nest.js가 더 나을 거라고 생각한다. Node.js + express 조합으로 유지보수가 쉬운 코드를 만드는 일은 쉽지 않다.
   • TypeORM은 보통 TypeScript랑 같이 쓴다. JavaScript랑 같이 쓰는 경우는 거의 없다. 만약 JavaScript로 작업하신다면 TypeORM 대신 다른 패키지를 써야 하는데, 이 경우 SQL문을 알아야 작업을 할 수 있다.
   • 내 질문 : TypeORM을 쓰는 대신 TypeScript를 익히는 것 VS JavaScript로 작업하는 대신 SQL문도 익혀서 작업하기, 어느 쪽이 더 학습 곡선이 낮고 유지보수가 좋을까요?
     -> 백엔드 개발자님 대답 : 당연히 TypeORM + TypeScript 쪽이 더 낫죠. TypeScript 학습 곡선이 그렇게 높지는 않다고 생각합니다.
     
     

최종 결정

• 처음에는 Flask + Python 조합을 생각하고 있었습니다. 왜냐하면, 저희 동아리는 다들 들어오면 Python을 먼저 배우기 때문입니다.
• 하지만, 과거에 제가 Flask로 서버를 짰을 때 유지보수와 인수인계가 쉽지 않다고 느끼기도 했고, 취업에도 큰 도움이 되진 않는다고 느꼈습니다. 그리고 주변 개발자들의 이야기를 들을 수록, Flask보단 Node.js가 더 낫다고 느꼈습니다.

결론 : 그래서 Node.js + Express를 선택했습니다.

왜 TypeScript를 썼는가?

(2023.01.13 변경)
: 원래는 JavaScript보다 TypeScript가 학습 곡선이 높고, 따로 배워야 한다는 부담감이 있다는 문제점 때문에 JavaScript를 사용하려고 했습니다.

그러나, TypeORM을 도입하려고 하니 TypeScript를 거의 필수적으로 써야 한다는 점을 알게 되었습니다. 이 때문에, TypeORM을 쓰고 JavaScript를 버리느냐 VS JavaScript를 유지하고 TypeORM을 버리느냐의 고민이 생겼습니다.

이 문제에 대해 저희 회사 백엔드 개발자분과 대화를 나눠봤는데, 그 분께서는 절대적으로 TypeScript를 쓰는 쪽을 추천하시더라고요. 다양한 이유가 있었습니다.

1. JavaScript보단 TypeScript를 쓰는 프로젝트가 유지보수하기 더 쉽습니다. (타입이 존재하기 때문입니다.)
2. TypeScript는 타입이 존재하기 때문에, 디버깅하기도 더 쉽습니다.
3. TypeORM 없이 SQL문 기반으로 백엔드를 작업하는 것보단, 차라리 TypeScript + TypeORM을 익히는 쪽이 학습 곡선도 더 낮습니다.

위 이유들 때문에, JavaScript 대신 TypeScript를 선택했습니다.

왜 TypeORM을 도입했는가?

그냥 SQL문을 서버에 쓰는 것과 비교했을 때, 상대적으로 코드를 이해하기 위한 난이도가 더 낮고, 유지보수성은 더 높다고 느꼈기 때문에 도입했습니다.

1. SQL문을 그대로 쓰는 것과 비교했을 때, 상대적으로 코드 읽기가 더 편하기 때문에, 난이도가 더 낮기도 하고, 유지보수성도 높일 수 있습니다.
2. SQL문을 몰라도 DB에서 데이터를 불러오고, 저장할 수 있기 때문에 난이도 측면에서 이점이 있다고 생각했습니다.