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