새로운:개발 일지/오픈나무 초창기와 지금의 웹 개발 분위기의 변화 그리고 나아갈 길

이 문서 내용은 좀 낡았습니다.
60일이나 편집 안된 오래된 망한 문서니 개발 문서인 경우 참고할 때 조심하세요. 최신 정보를 알고 싶으면 게시판에 글 써주세요

목차

1. 서론
2. 2016년 당시 분위기
2.1. ES6도 안 나온 시절
2.2. 백엔드에서 대부분 처리
2.3. Spring, PHP 천하
3. 당시 선택에서 아쉬웠던 점
4. 애매한 점
5. 그래도 정말 잘 했다고 생각하는 것들...

1. 서론 _{✎ ⊖}

오픈나무를 완전히 처음 시작한 건

2016년이였다 당시의 웹 개발 풍경과 현재의 웹 풍경을 비교하면서

~~왜 최신 오픈나무 개발에 애를 먹고 있는 건지~~ 얼마나 개발 풍경이 많이 달라졌는 지 한탄 비교하는 문서이다

2. 2016년 당시 분위기 _{✎ ⊖}

2.1. ES6도 안 나온 시절 _{✎ ⊖}

ES6가 이제 막 나와서 브라우저들에게 막 적용 시작하던 시절이 2016년이였다

그 때 당시에는 자바스크립트 한다고 하면 거의 제이쿼리 한다는 말과 동치인 시절이였고

바닐라 자바스크립트 쓴다고 하면 그렇게 불편한 걸 어떻게 쓰냐고 생각하던 시절이였다...

2.2. 백엔드에서 대부분 처리 _{✎ ⊖}

2016년 당시까지만 해도 API를 이용해서 백 프론트 분리는 고사하고 백엔드 내부에서도 로직 부분과 프론트 처리가 마구 섞여 있던 코드가 대부분이였다⁽¹⁾

당시 백엔드 대세는 Spring + JSP와 PHP였으며 이 두 개는 진짜 프론트 백을 마구 잡이로 섞어서 쓰기 최적화였다

오픈나무도 그에 영향을 많이 받아서 지금도 여전히 그렇지만 백 프론트가 제대로 분리되지 않은 경향이 크다...

2.3. Spring, PHP 천하 _{✎ ⊖}

당시에는 웹 개발한다고 하면 대부분 Spring이나 PHP + 제이쿼리를 한다고 생각했다

게다 PHP도 PHP 7 나온 지도 얼마 안되었고 모던 PHP 개념도 제대로 정립 안되던 시절이였다...

대규모에선 Spring을 쓰고 소규모에서는 PHP로 백엔드를 만드는 시대였으나 오픈나무는 좀 특이하게 파이썬을 도입했다

3. 당시 선택에서 아쉬웠던 점 _{✎ ⊖}

REST API를 제대로 도입하지 않은 점

API 기반의 동작 구조를 채택하지 않고 DB에서 바로 커넥트해서 바로 템플릿 엔진으로 전부 렌더링해서 보여주는 구조로 인해 구조 자체가 경직되었고 현재와서 기능이 많아지니 유지보수가 어려워졌다...

물론 2016년 당시에는 리액트나 뷰가 대중화 되던 시점도 아니였고 다들 템플릿 엔진으로 작성하던 시절이라서 그 당시엔 이상한 구조가 아니였으나 2020년 쯤에 리팩토링 한번 했어야 했는데 제대로 하지 못한 점이 2024년 현재에선 아쉬운 점으로 남는다

4. 애매한 점 _{✎ ⊖}

템플릿을 이용한 점

현재는 리액트나 뷰 프론트 엔드 라이브러리를 이용한 개발이 대중화되어 있으나 오픈나무에는 딱히 적용되어 있지 않고 여전히 템플릿 기반의 구조를 가지고 있다

이에 대해서 사실 아쉽게 생각할 수도 있으나 오픈나무의 특수성을 생각해보면 만약 프론트엔드 라이브러리를 완전히 따로 분리한 경우 사용자들이 설치할 때 프론트엔드 라이브러리 설치 및 구동 과정도 추가되는데

예전에도 그랬고 지금도 대부분의 일반 사용자들은 여전히 그냥 FTP로 호스팅에 바로 PHP 파일만 던지면 되는 PHP 기반 웹 빌더나 아님 아예 바이너리로 실행만 하면 되는 것을 더 선호하는 사람이 대부분이다⁽²⁾

사실 그 사람들에겐 파이썬 + PIP 설치도 까다롭게 생각하는 사람들이 대다수라 여기서 JS 라이브러리도 따로 요구했다면... 음... 과연 설치 했을까?

또 다른 한편으로는 현재는 그런 라이브러리 중 가장 유명한 걸 고르라하면 대부분 리액트나 뷰를 고르겠지만 예전엔 아직 피튀기는 경쟁 중이였다

만약 현재 와서는 이름이 무색해져버린 라이브러리를 골랐다면 음... 또 리팩토링에 애를 먹었을 것 같다

타입스크립트를 도입하지 않은 점
그와 마찬가지로 파이썬 코드에 타입 힌트를 도입하지 않은 점

이 두 개는 사실 얼마 전에 도입하려고 찍먹 해봤으나 개발 안정성은 늘어나는 것이 사실이지만 컴파일 과정이 추가로 생기니까 개발 생산성이 확 떨어지는 것 같은 기분도 들어서...⁽³⁾

차라리 이럴꺼면 컴파일 언어나 웹 어셈블리를 쓰는 게 더 나은 것 같아서 Golang을 차기 백엔드 언어로 지정하는 과정까지 와버렸기에 좀 더 옛날에 했어도 똑같은 결론을 내지 않았을까 싶다...

5. 그래도 정말 잘 했다고 생각하는 것들... _{✎ ⊖}

Python 2를 고르지 않은 점

2016년 시점에서는 파이썬 2의 라이브러리가 더 풍성하고 파이썬 3은 3.5까지 밖에 안 나와서 많이 편의성이 개선된 파이썬 3.6도 나오지 않았던 시절이였다 그래서 그 당시엔 파이썬 2가 유망해 보였으나...

파이썬 2는 2020년에 죽고 말았다 진짜 다행이다 물론 마이그레이션이 어려운 건 아니였지만 귀찮았을 것 같다

그 와 동시에 개발 언어로 파이썬을 고른 점

처음에는 Node.js에 express를 기반으로 개발을 시작하였으나 얼마 지나지 않아서 Python과 flask 기반으로 갈아엎었다

당시에는 JS고 Python이고 소규모는 PHP 대규모는 Java가 대세인 시점에서 둘 다 백엔드로 사용하기엔 생소한 느낌이 강했고 또한 express도 나쁘지 않았으나...

시대가 흘러서 2024년 파이썬이 언어 순위 1위를 찍고 대 AI 시대가 열리면서 파이썬 라이브러리가 물 밀듯이 마구 쏟아져나오기 시작했다

대부분의 사람들이 다른 언어는 몰라도 파이썬은 아는 시대가 도래하면서 조금만 검색해서 엥간한 솔루션은 다 있어서... 개발하기 참 편했던 것 같다

물론 JS도 세상을 평정하고 있으나 그건 프론트 이야기지 백엔드는 사실 예전이랑 별 반 차이 없는지라...

제이쿼리를 도입하지 않은 점

사실 당시엔 ES6도 없던 시절이라 대부분은 바닐라 자바스크립트 쓴다고 하면 아니 그런 불편한 걸 어떻게 쓰냐고 하던 시절이였다... 프론트 개발하면 제이쿼리고 제이쿼리하면 프론트 개발로 생각하던 시절이였으나...

리액트나 뷰가 등장하면서 급속도로 제이쿼리의 시대는 막을 내리고 말았다... 오히려 지금의 제이쿼리는 웹 사이트 속도에 발목 잡는 역할을 하고 있다⁽⁴⁾

사실 그런 광경을 보고나니 프론트 라이브러리를 도입하기가... 거부감이 들기 시작해서 아직도 오픈나무는 바닐라 자바스크립트를 기반으로 하고 있다

(1) 특히 JSP와 PHP를 사용하는 프로젝트에서
(2) 즉 대부분의 일반 사용자들은 설치 과정 복잡하면 안 쓰려고한다...
(3) 자동 컴파일 있다 해도 프로그램 실행 시간이 확 늘어나니까...
(4) 물론 제이쿼리 4가 나오면서 많이 경량화 되었지만 마이그레이션은 개발자의 몫...

1. 서론 ✎ ⊖

2. 2016년 당시 분위기 ✎ ⊖

2.1. ES6도 안 나온 시절 ✎ ⊖

2.2. 백엔드에서 대부분 처리 ✎ ⊖

2.3. Spring, PHP 천하 ✎ ⊖

3. 당시 선택에서 아쉬웠던 점 ✎ ⊖

4. 애매한 점 ✎ ⊖

5. 그래도 정말 잘 했다고 생각하는 것들... ✎ ⊖