특히 팀 구성인원의 변동이 크지 않을 시절에는 이게 진짜 좋았다.
https://x.com/i/web/status/1849398004228464887
특히 팀 구성인원의 변동이 크지 않을 시절에는 이게 진짜 좋았다. django를 정말 잘하시는 몇 분이 계셔주신게(특히 이분 ㅎㅎ) 특히 더 시너지가 있었다. 테이블을 추가하고 crud api 추가는 진짜 30분도 안되어 뚝딱이었다. 이제 우리 django 앱은 15만줄이 넘었지만 여전히 좋다. https://x.com/pakyoungrok/status/1849389031861428246
https://x.com/i/web/status/1849398004228464887
다만 적절한 시점에 디비와 앱을 좀 찢어서 서비스를 분리해가는 시점을 잘 찾으면 더 좋았을것 같다. 대체로 django가 문제라고 하는 것의 많은 지분이 단 하나의 서비스에 기능들을 끝없이 덧붙이다 각 기능들의 장애가능성의 곱으로 인해 불필요하게 전체 장애의 가능성이 높아지는 부분인 것 같다
https://x.com/i/web/status/1849399698500821398
이건 django의 문제가 아니다. 뭘로 만들던 대부분의 초기 프로젝트가 커지면서 발생하는 문제이고 아마 주로 django로 만든 서비스가 잘 커져서 더 눈에 잘 들어오는 걸지도? 서비스 규모에 따라 적절히 구성을 하는 능력이 참 중요한 것 같다.
https://x.com/i/web/status/1849400809022484868
요즘은 go로도 서비스를 만들면서 아니 이런것 까지 직접 다 구현해야되나? 싶은 지점을 많이 만나지만 솔직히 분리 그 자체에서 느끼는 상쾌함이 크다. 이걸 go로 떼던 django로 떼던 크게 다를바는 없을 것 같다.