목차1. 서론2. 과거에 비해서 달라진 개발 환경3. 이 만큼의 트레이드 오프를 제공할만한 가치가 있을까? 과거의 오픈나무와 현재의 오픈나무의 구조는 상당히 다르다
이를 통해서 얻은 이점도 있지만 트레이드오프가 너무 큰 것 같아서 심히 진지하게 고민해보는 글이다
2. 과거에 비해서 달라진 개발 환경 ✎ ⊖
과거의 경우 사실상 파이썬 Only 개발 환경이였다
프론트도 파이썬 내에서 해결했고 백엔드도 파이썬 내에서 해결하였다
그 결과 그냥 파이썬만 고치면 되니까 프로그램 자체 속도는 느렸지만 개발 속도는 나름 쭉쭉 잘 나왔다
하지만 지금은 다르다
프론트는 JS로 일부 떨어져 나갔고 백엔드로 Golang으로 일부 떨어져 나갔다
그 결과 한 파트를 고치려고하니 JS, Golang, Python 파트를 전부 고쳐야 하는 문제가 발생했다
물론 대기업처럼 정규화되고 인력이 많은 환경이면 파트별 분할은 당연한 거지만...
오픈나무의 유지보수 인력은 1명이라는 점을 내가 너무 간과했던 것 같다...
물론 JS를 본격적으로 프론트에 도입해서 브라우저와 상호 소통하는 UI를 만들 수 있게 되었고
Golang을 본격적으로 백엔드에 도입해서 이런저런 병목 부분에서 프로그램 속도를 개선할 수 있었던 것은 사실이지만
그 반동으로 개발 속도가 확 느려지고 코드가 난잡하게 되었다... 솔직히 로직도 그려보라하면 그릴 자신이 없다
3. 이 만큼의 트레이드 오프를 제공할만한 가치가 있을까? ✎ ⊖
물론 그 이후로 오픈나무 기능상으로 발전한 부분이 많이 생겼고 API도 제대로 만들기 시작했지만
이게 이 만큼의 개발 속도 저하를 감소하면서 유지할만한 기능일까?
솔직히 잘 모르겠다 매일 고민이 된다
차라리 덜 중요한 기능을 덜어내고 중요 기능을 위주로 개발 속도를 쭉쭉 뽑아내는 게 훨씬 올바른 방향이 아닐까?
솔직히 이런 생각을 자주한다... 생산성이 안 나온다
그렇다고 이 기능을 덜어낸다고 말하자니 반발도 있을 것 같고 솔직히 어떻게 해야할 지 잘 모르겠다
줬던 기능을 뺐는 것도 이상하고 선택과 집중을 해야한다고 생각은 하는데 그게 참 안되니까
오히려 손도 안 가고 고심만 깊어지는 것 같다...
이게 현재 구조가 현대적인 구조긴 한데 이게 생산성이 높은 구조냐 하면 그건 답을 못하겠네