Rails로 다시 작성하기

 (dirkjonker.bearblog.dev)
3P by GN⁺ | ★ favorite | 댓글 2개
  • 세관 신고서 작성 애플리케이션은 여러 스택을 검토한 끝에, 익숙한 Ruby on Rails가 새 선택지보다 체감상 훨씬 빠르게 기능을 만들 수 있어 초기 구현에 쓰임
  • Rust 백엔드와 SvelteKit 프런트엔드로 만든 “version 2”는 빠르고 보기 좋았지만, 필요한 기능은 약 10%에 그쳤고 비즈니스 코드보다 배관 작업이 커짐
  • 점진적 이전은 라우팅, 데이터 접근, 권한, 변경 추적, 검색, 백그라운드 작업, pub/sub, 이메일, OAuth 2.0, SMTP/POP, 객체 저장소, PDF 생성까지 직접 엮어야 해 사용자 가치를 거의 늘리지 못함
  • 새 스택으로 옮긴 부분만 다시 Rails로 되돌리기로 했고, 혼자 Rails 앱을 유지하던 상황과 사용자 요구를 충족하지 못하는 스트레스, 여러 곳을 동시에 고쳐야 하는 복잡성이 결정에 영향을 줌
  • Rails 복귀 후 기능 개발, 기존 기능 개선, UI 업데이트, 버그 수정 속도가 다시 붙었고, Ruby/Rails의 단점은 테스트·리팩터링·Turbo·캐싱으로 다루며 제품 개발에 집중하는 쪽을 택함

Rails를 임시 선택지로 고른 출발점

  • 2022년에 세관 신고서 작성 애플리케이션을 만들기 시작하면서 .NET/F#, Go, Rust, React 같은 여러 언어와 프레임워크를 검토하고 실제로 코드를 작성해 봄
  • 최종 선택은 Ruby on Rails였음
    • 이미 익숙한 도구였고, 새로 배우는 선택지보다 체감상 10배 빠르게 진행할 수 있었음
  • 당시 Rails 구현은 임시 개념 증명에 가까웠고, 나중에는 Ruby처럼 실수하기 쉬운 언어가 아닌 다른 언어로 다시 작성할 계획이었음
  • Rails 애플리케이션은 빠르게 기능을 늘렸고, 동료들도 결과물을 좋아함
    • 생산성을 높이는 기능을 빠르게 만들 수 있었음
    • 처음에는 자주 발생하던 오류 상황을 코드로 막을 수 있었음

Rust와 SvelteKit “version 2”가 막힌 지점

  • “version 2”는 백엔드에 Rust, 프런트엔드에 SvelteKit을 선택함
  • 초기 버전은 보기 좋고 빠르게 동작했지만 필요한 기능은 약 10% 만 갖춘 상태였음
  • Rust에는 Rails와 비교할 만한 통합 프레임워크가 없어, 비즈니스 로직보다 기반 코드와 연결 작업을 더 많이 작성해야 했음
  • 완전한 version 2를 만들려면 version 1 개발을 완전히 멈춰야 한다는 점이 분명해졌고, 결국 version 2는 폐기됨
  • 다시 작성은 원래 애플리케이션을 처음 만드는 데 걸린 시간과 비슷하게 걸릴 수 있음을 확인함

점진적 이전이 만든 운영 복잡성

  • Rust의 강한 타입, 빠른 성능, 컴파일 성공 시의 확신 때문에 애플리케이션에 Rust를 넣고 싶다는 생각은 계속 남아 있었음
  • Ruby를 4년 넘게 사용했지만 런타임 문제도 계속 발생함
    • 주로 null 값과 처리되지 않은 예외가 문제였음
    • 배포 후 오류 리포팅 도구를 보며 프로덕션 문제를 빠르게 고쳤음
  • Rails 프런트엔드에서는 로직과 마크업이 여러 파일에 흩어지는 점이 불만이었고, Svelte는 관련 로직을 한 파일에 묶기 쉬웠음
  • 새 프런트엔드는 SvelteKit, 새 백엔드는 Rust로 천천히 작성하고, 기존 Rails 부분도 점진적으로 대체해 최종적으로 Rails를 제거하려는 계획을 세움
  • 초반에는 레코드 목록과 필터가 있는 “index” 페이지들을 새 스택으로 옮기는 일이 빠르게 진행됨
    • 새 스택은 빠르게 동작했고 Rust 부분은 런타임 문제가 거의 없었음
    • 어떤 라우트가 Rails, Rust, SvelteKit으로 가야 하는지 정하는 배포 규칙이 복잡해짐
    • 이 복잡성은 전체 전환 전까지의 임시 상태로 받아들임

사용자 가치보다 커진 기술 작업

  • 시간이 지나면서 Rails 쪽에는 유용한 새 기능이 계속 추가되고, 기존 기능도 더 깊고 정교해짐
  • 초기의 잘못된 가정을 고치기 위해 여러 리팩터링을 했고, 잘 설계된 데이터베이스 스키마는 어떤 버전에도 도움이 된다고 판단함
  • Rails UI는 곧 교체될 예정이라고 보고 더 이상 많은 시간을 들이지 않기로 함
  • 몇 달 뒤 사업이 충분히 성공해 정규 개발자를 고용할 수 있게 되었고, Rust 전환이 빨라질 것으로 기대함
  • 실제로는 새 스택에서 많은 시간을 추상화와 메커니즘 작성에 썼음
    • 데이터베이스 접근
    • 사용자가 허용된 데이터만 보도록 하는 권한 처리
    • 모든 변경 사항 추적
    • 검색과 필터
    • 타입 시스템을 통한 제약 강제
  • 이어서 필요한 기능 목록도 계속 늘어남
    • 백그라운드 작업
    • 클라이언트 업데이트를 위한 pub/sub 시스템
    • 이메일 기능
    • 외부 서비스 연결을 위한 OAuth 2.0
    • SMTP와 POP
    • 객체 저장소
    • PDF 생성
  • Rust 라이브러리는 충분히 있었지만, 적절한 라이브러리를 고르고 모두 연결하는 작업이 컸음
  • Rust ORM 선택, Svelte 5 출시 시점과 개선점 같은 기술 구현 세부사항 논의가 많아짐
  • 약 1년 동안 Rust와 Svelte를 작성한 뒤, 사용자는 이 작업에서 거의 이익을 얻지 못한다는 점이 분명해짐
    • 새 스택의 일부 화면은 매끄럽고 빠르지만 원래 문제가 되던 부분이 아니었음
    • 가장 많이 쓰는 페이지들은 여전히 Rails에서 동작했고, 새 스택의 “베타 버전”보다 기능이 10배 더 많았음
    • 며칠 또는 몇 주씩 직접적인 가치를 추가하지 않는 작업에 시간을 쓰게 됨

다시 Rails로 돌아간 결정

  • 새 스택으로 실행 중이던 부분만 Rails로 다시 작성하기로 결정함
  • 전체 애플리케이션을 다시 쓰는 것이 아니라, Rust/SvelteKit으로 옮긴 부분을 Rails로 되돌리는 선택이었음
  • 결정은 어렵지만 합리적이었음
    • 이미 많은 시간과 코드를 투자했음
    • 팀원들이 Ruby나 Rails를 좋아하지 않을 가능성도 있었음
    • 다행히 팀은 결정을 이해했고 새로 배우는 데 열려 있었음
  • Rails의 강점은 많은 기능이 기본 포함되어 있고, 성숙하고 안정적인 라이브러리 생태계가 있으며, 관례와 의견이 강한 설계 덕분에 코드가 간결하다는 점임
  • Rails는 제품을 만드는 데 집중하게 해 주고, 하부 지원 코드를 직접 작성하는 부담을 줄여줌

Rails 복귀 후 남은 교훈

  • Rust와 Svelte 시도가 완전한 낭비는 아니었음
    • 새 언어와 프레임워크를 배우며 다른 언어에서도 도움이 되는 통찰과 아이디어를 얻었음
    • 웹 애플리케이션 작성은 선택과 절충의 연속임
    • 프레임워크의 결함을 받아들이거나 직접 구현에 투자해야 하며, 그 투자가 경쟁 우위와 장기 보상을 줄지 따져야 함
  • Rails로 되돌리는 작업은 상당 부분 간단했고 스트레스도 줄어듦
  • 최근 몇 주 동안 새 기능 개발, 기존 기능 개선, UI 업데이트, 버그 수정에서 다시 생산성을 느끼게 됨
  • Ruby와 Rails의 단점은 코드 작성 시 고려해야 할 조건으로 받아들임
    • 런타임 문제가 많으면 더 테스트해야 함
    • 유지보수하기 어려운 스파게티 코드는 언어나 프레임워크보다 개발자가 만들기 쉬움
    • 리팩터링과 코드 구성에 더 많은 시간을 써야 함
    • Rails 확장이 어렵다면 다른 것도 확장하기 어렵다고 봄
    • Rails는 충분히 빠르고, Turbo와 캐싱으로 우회할 방법이 있음
  • 사용자 입장에서 Rust 스택은 눈에 띄게 더 빠르지 않았음
  • Rails에서 가장 무거운 페이지의 P95 duration은 338ms이며, 개선 여지는 있지만 충분히 빠르게 느껴지는 수준임
  • 완벽한 언어나 프레임워크는 없고, 강점과 약점을 알고 다루는 방식이 필요함
  • Rails는 좋은 제품을 만드는 데 집중하려는 사람에게 매우 좋은 프레임워크 중 하나이며, 오래 유지되고 활발한 기여자가 많은 다른 프레임워크들도 비슷하게 좋은 선택지가 될 수 있음

함께 보면 좋은 글 β

lemonmint   [-]

Rewrite It In Ruby
Rewrite It In Rails

답변달기
GN⁺   [-]
Hacker News 의견들

  • Rails는 Django나 Laravel까지 포함해 웹 앱을 만들 때 다른 스택보다 훨씬 앞서 있다고 봄
    지루한 부분을 다 처리해 왔고, 필요한 요구사항을 알고 있으며, 실제 앱을 만들 때 방해가 덜 됨. 15년 동안 웹 앱을 개발하면서 Meteor, Remix, Next.js, Express 기반 Node.js 등을 써봤지만, 웹 개발은 이미 상당히 풀린 문제라고 느낌. JavaScript 쪽은 대기업 자금에 밀려 개발자들이 새 장난감을 만지는 쪽에 가깝고, Rust나 Go는 시스템 개발·배포 인프라에는 좋지만 웹 개발에 억지로 끼워 넣는 건 말이 안 된다고 봄

    • 유행하는 스택은 아니어도 Spring Framework/Spring Boot가 전반적으로 가장 좋은 웹 애플리케이션 스택이라고 느낌
      수많은 Java 라이브러리와 쉽게 통합되고, 정적 타입 언어라 여러 상황에서 도움이 됨. Jackson을 통한 관례 기반 데이터 바인딩만 해도 오래전부터 훌륭했고, 동적 타입 언어에서는 이런 부분이 나중에 덧붙여진 느낌이 강함
    • 이런 프레임워크들은 큰 결정을 할 필요가 없어서 프로젝트를 시작하는 고속 차선 같음
      하지만 Rails, Django, Laravel에 깊이 들어간 뒤 관례에서 벗어난 일을 해야 하면 까다로워질 수 있음. 접착 코드를 직접 쓰지 않았기 때문에 기술적 장벽보다는 이해의 공백이 생기는 경우가 많음. 그래도 내부를 제대로 배우면 코드를 읽는 것만으로 엄청난 코딩 시간을 아낄 수 있음. 물론 실제로 그렇게 하지는 않고, 전부 다시 쓰는 게 너무 재미있어서 비즈니스적으로 말이 안 돼도 새 시도를 즐기게 됨
    • 동의하지 않음. Rails는 기능과 생산성 면에서는 훌륭하지만 만능 해결책은 아님
      내 의견만 믿지 말고 데이터를 보면 됨: https://www.youtube.com/watch?v=Qp9SOOtgmS4
      사용자 수나 초당 요청 수를 확실히 모르는 서비스에 Rails를 쓰면 출시 시점의 비용은 아끼지만 서버 비용을 더 쓰게 될 수 있음
    • AOLServer를 썼고, 1999년에 Tcl로 Rails 비슷한 걸 만들던 스타트업에 있었던 입장에서는 그다지 동의하지 않음
      Rails 데모는 채택과 주목을 받는 운이 얼마나 중요한지 보여준 것 말고는 크게 매력적이지 않았음. 지금도 가치를 잘 모르겠고 Spring이나 ASP.NET을 택하겠음. 그 Tcl 기반 스타트업 창업자들은 이후 OutSystems를 만들었는데, 엔터프라이즈 규모 웹 개발에서 성공한 몇 안 되는 RAD 도구이자 포르투갈 IT 업계의 성공 사례 중 하나임
    • 이 얘기는 대부분 Django에도 적용됨
      예전에는 Rails를 더 선호했지만, 지난 10년 넘게 Python이 크게 성장하면서 Django가 더 실용적인 선택지가 됨. 머신러닝과 데이터 과학 개발자들은 이미 Python에 익숙하고, Django 문서가 워낙 좋아서 필요하면 아주 짧은 시간 안에 생산성을 낼 수 있음. 여러 프로젝트에서 직접 봤음
      Django는 덜 독단적인 라이브러리나 마이크로프레임워크보다 애플리케이션 구조를 두고 생기는 결정과 논쟁도 줄여 줌. Django/FLOSS 커뮤니티도 예상보다 훨씬 활발하고, 상호작용도 즐거웠음. 다만 Rails 같은 생성기와 내장 데이터 시딩, 예를 들면 rake db:seed 같은 기능이 있었으면 좋겠음

  • Rails를 17년째 쓰고 있고, 아직도 좋아하며 프런트엔드에도 선호함
    Angular 앱에서 보이는 것처럼 파일 머리가 불필요하게 긴 includes 목록이 되지 않으면서도 코드를 분리할 선택지를 모두 줌. 프런트엔드에서 로직과 마크업을 나누는 데 단점은 없다고 봄. 로직을 독립적으로 테스트할 수 있고, 보통 버그를 찾을 때 마크업 문제인지 로직 문제인지 알 수 있어 추적이 더 쉬워짐. 200줄 넘는 Ruby 메서드도 꽤 많이 썼지만 그건 정말 내 잘못이고, 더 세밀한 단위 테스트 체계가 있으면 막을 수 있음

    • 긴 includes 목록을 피하는 또 다른 방법은 모든 걸 전역으로 만드는 것임
      이게 장점인지는 잘 모르겠음. 가져오기가 공간을 많이 차지할 수는 있지만, 모든 것이 어떻게 연결되는지 명시적으로 보여줌. 방해된다면 IDE에서 접어 두면 됨

  • 현실적인 글이라 좋음. 핵심 문장은 항상 머리맡에 두고 볼 만함
    “흥미롭게도 예전에 Ruby와 Rails에서 짜증 나던 것들이 이제는 훨씬 덜 거슬린다. 완벽한 언어나 프레임워크는 없다는 걸 받아들였다. 강점과 약점을 알고 다루면 된다”

    • 글이 실용적이라 좋음. 무언가를 다시 작성하기 전에 읽기 좋은 입문서처럼 느껴짐
    • 프레임워크를 두고 불평하는 사람들은 보통 타협하고 싶지 않은 완벽한 세계관을 갖고 있다고 느낄 때가 많음
      많은 경우 프레임워크를 충분히 이해하지 못했고, 왜 그렇게 되어 있는지도 모름. 하지만 한계를 알고 프레임워크와 함께 일하는 편이 훨씬 효율적임. 자신이 쓰는 도구를 제대로 이해하는 데 시간을 써야 함
    • 그 문장은 이런 시도 뒤에 나온 맥락임
      “그동안 애플리케이션의 ‘버전 2’를 만들기 시작했다. 백엔드 언어로 Rust를, 프런트엔드로 SvelteKit을 골랐다.”
      v1이 Rails로 시작했으니, 이미 잘 작동하는 프레임워크를 버릴 때 조심하라는 글로 읽힘
    • 나도 이게 가장 중요하게 깨달은 부분이었음. 이제는 “Rust 열거형만 있었더라면!” 같은 생각을 계속하지 않아서 훨씬 행복함

  • Rust는 아주 똑똑한 사람들이 만든 언어지만, 초점이 나 같은 현장 개발자가 유용하고 일관된 것을 만들기보다는 타입 이론과 몇 번의 할당 절약에 더 가 있는 듯함
    2020년부터 Rust를 쓰고 있는데도 Rust 블로그 글을 읽으면 문자 그대로 절반은 이해하지 못함

    • Rust에서 일관성이 없다고 느낀 예를 공유해 줄 수 있나? 오히려 작고 잘 설계된, 매우 일관적인 언어라고 느낌
      거대한 주류 언어와 비교하면 특히 그렇다. 예를 들어 트레이트는 C++의 추상 클래스와 콘셉트, Python의 추상 클래스와 프로토콜 사용 사례를 모두 포괄함. 예외를 쓸지 값을 반환해 오류를 처리할지에 대한 불일치도 없음. 패닉은 있지만 단언문처럼 쓰임. if-else가 표현식이면 별도의 삼항 연산자도 필요 없음
    • Rust는 시스템 언어이고, 그 영역에서는 훌륭함. 같은 계열끼리 비교하면 C++ 블로그 글이 훨씬 덜 일관적으로 느껴짐
      최근 Rust를 모든 것에 쓰려는 흐름이 있지만, CRUD 앱에 쓰라고 만든 언어는 아님. 이 글은 결국 “일에 맞는 도구를 써라. 여가 시간에 좋아하는 언어나 최신 유행 언어가 꼭 맞는 건 아니다”라는 사례 연구에 가까움
    • Rust는 본질적으로 C++ 대체재임
      가비지 컬렉터를 감당할 수 있다면 Rust나 C++를 쓰며 메모리 관리를 걱정할 필요가 없음. Rust를 범용 프로그래밍 언어로 홍보하는 사람들도 있고 이론적으로는 맞지만, 90년대 C++도 그렇게 홍보됐음. 메모리 할당을 최소화하는 건 보통 Rust나 C++를 선택할 때 원하는 바로 그 특성임

  • Rust로 큰 웹 애플리케이션을 빠르게 작성하기는 어려움
    Rails로 작성한 큰 애플리케이션은 빠르게 돌지 않을 수 있고, 버그가 많거나 유지보수와 확장이 어려울 수도 있음. Java, C#, Go 같은 선택은 섹시하거나 멋져 보이지 않을 수 있지만 Rails만큼 빠르게 일을 끝내면서 Rust에 가까운 속도로 실행될 수 있음. 보통 버그도 줄고, 유지보수와 확장이 쉬운 프로젝트가 됨

    • Go 같은 저수준 시스템 언어가 CRUD 애플리케이션을 위한 고수준 프레임워크인 Rails만큼 생산적이라고 진지하게 말할 수는 없음
      Rails를 얼마나 싫어하든, 이건 C++로 WordPress보다 블로그를 더 빨리 만들 수 있다고 말하는 것과 비슷함
    • “Rails로 작성한 큰 애플리케이션은 빠르지 않고, 버그가 많고, 유지보수와 확장이 어려울 수 있다”는 건 너무 과도한 일반화라고 봄
      신경 써서 만들면 반드시 그렇지는 않음. 크고 버그가 거의 없으며 안정적이고 수정하기 쉬운 Rails 앱도 많이 봤고, 엉망인 Rails 앱과 Go 앱도 봤음. 어떤 언어나 프레임워크는 그런 상태에 빠지기 쉽게 만들 수 있지만, 무엇이든 가능성은 있고 다른 이유로 어려워지는 절충점도 있음. 규율이 있으면 무엇이든 작동하게 만들 수 있음
    • Rails로도 빠르고, 버그가 적고, 유지보수와 확장이 어렵지 않은 대형 애플리케이션을 만들 수 있음. 실제 사례가 많음
      비슷한 실력의 개발자라면 대부분의 웹 애플리케이션 기능에서 Rails가 Java, C#, Go보다 빠르게 개발됨. 내 경험으로는 최대 3배까지 빨랐음. 대형 모놀리스와 서비스 지향 아키텍처를 모두 다뤘고 Java 팀과도 함께 일했음. 한때는 같은 믿음으로 Rails 조직에 Go를 도입하기도 했음
      결국 진짜 문제는 MVC가 모든 것에 맞지는 않는다는 점과 네임스페이스를 충분히 엄격하게 쓰지 않았다는 점이었음. 작고 표적화된 영역에서 그 문제를 고치면 Rails는 충분히 괜찮음
    • Basecamp를 써본 적은 없지만 제품이 잘 작성되어 있고 괜찮다고 믿음
      따라서 충분한 관리, 좋은 아키텍처, 유지보수가 있다면 Rails로도 가능하다고 봄

  • 최근 Rails의 TypeScript 대안으로 AdonisJS를 테스트하기 시작함
    “TypeScript로 된 Rails”에 관심이 있다면 한번 써보길 권함. 가장 인기 있는 TypeScript 스택들보다 Rails나 Laravel에 훨씬 더 가깝게 느껴지고, 스택의 모든 부분을 직접 고르거나 서드파티 템플릿을 믿게 두는 대신 배터리 포함 방식임

    • AdonisJS가 궁금했는데 이 댓글 덕분에 한번 써볼 생각이 듦
      최근 Rails, Laravel, Django 같은 배터리 포함 백엔드 프레임워크에 끌리고 있지만, 커리어 내내 거의 TypeScript를 써왔기 때문에 지금 바꾸는 것보다 그대로 가는 게 더 쉬움. 테스트해 본 소감이 궁금하고, 언급한 다른 프레임워크들과 비교할 수 있는지도 궁금함
    • AdonisJS를 써보려고 했는데 좋은 소식임
      최근 개인 프로젝트에서는 NestJS를 골랐지만 곧 Adonis를 알게 됐고, 실제로 옮길까 고민 중임

  • Next.js와 SvelteKit 같은 기술이 JavaScript 개발자들 사이에서 인기 있는 이유는 Node.js의 백엔드 개발 경험이 좋지 않은 문제를 완화해 주기 때문임
    TypeScript로 백엔드를 만드는 건 C#으로 만드는 것과 비슷하지만, 제대로 설계된 언어의 장점은 빠진 느낌임. Rails로 백엔드를 만드는 경험과는 큰 차이가 있음. Node.js 개발자들도 생태계와 도구만의 문제가 아니라, 애플리케이션을 만드는 전체적인 해법을 제공하는 프레임워크가 중요하다는 걸 깨닫기 시작함. Next.js와 SvelteKit이 도와주는 부분이 그 지점이고, Rails가 2006년에 혁신했던 것도 그 부분임

    • TypeScript를 좋아함. C#과 비교했을 때 어떤 점에서 제대로 설계된 언어가 아니라는 건지 궁금함
    • Next.js나 Remix 등을 Rails, Django, Laravel과 비교하는 건 무리임
      백엔드에서 코드를 실행할 수 있다는 것과 Rails를 비교하는 건가? 데이터베이스 접근, 마이그레이션, ORM, 큐, 예약 작업, 검증, 번역, 인증, 권한 부여 지원이 어디에 있나? Next.js가 돕는 유일한 건 사람들을 Vercel 플랫폼으로 밀어 넣는 것뿐임
    • C#과 TypeScript 중 고르라면 백엔드에서는 기꺼이 C# 을 고르겠음
      프런트엔드라면 JavaScript보다 TypeScript를 선호함

  • Rust가 웹 백엔드에 별로라는 댓글들이 조금 혼란스러움
    beampaint.com이나 probablyup.net 같은 작은 서비스를 주로 만들면서는 반대 경험을 했음. 더 큰 앱을 만들면 복잡도가 크게 올라갈 수도 있고 아마 분명 그럴 것 같지만, 큰 코드베이스에서 필요한 자신감을 주는 데는 Rust가 훌륭함

    • 프레임워크 영역의 기능이 더 많이 필요해지는 순간 난이도가 급격히 올라가지 않겠나?
      오래된 프레임워크들은 그런 것들을 기본으로 갖고 있지만, Rust 프레임워크는 나이 때문에 그럴 가능성이 낮음. 빠진 기능이 두 개에서 여섯 개로 늘어난다고 상상해 보면 됨

  • 이 글은 거의 내 인생 이야기 같음
    Rails를 쓰다가 2013년에 Go로 작성한 SaaS 앱을 출시했는데, 모든 걸 직접 알아내야 했음. 마이그레이션, 데이터베이스 계층, 에셋 파이프라인, 배포, 검증, 로깅, 결제 등 Rails가 그냥 제공해 주는 것들이 너무 많았음

    • 그래도 그 경험 덕분에 더 숙련된 개발자가 됐을 가능성이 큼
    • 시스템 지향의 뼈대만 있는 저수준 프로그래밍 언어를, 아주 고수준 언어 위의 아주 고수준 프레임워크와 비교하고 있음
      Go를 좋아하진 않지만 여기서 탓할 대상은 Go가 아님. CRUD 애플리케이션에 Go를 쓰는 건 애초부터 끔찍한 결정임

  • Django도 비슷하게 느낌
    성능 문제는 Django 자체보다 데이터베이스 쿼리 때문에 생기는 경우가 훨씬 많았음

    • 거의 항상 데이터베이스 쿼리가 가장 오래 걸리겠지만, 인덱스 생성 같은 기본 최적화조차 안 하는 엔지니어를 너무 많이 봤음
      자주 잊히는 쉬운 최적화로는 데이터베이스 인덱스 생성, 코드보다 데이터베이스에 더 많은 로직 위임하기, 예를 들어 MongoDB 파이프라인이나 Postgres 부분 인덱스 사용, 대부분의 요청에 Brotli/zstd 압축 켜기, Redis 같은 메모리 캐시로 객체나 요청 캐싱하기, 적절한 캐시 제어 헤더 설정하기가 있음. 프런트엔드에서는 수천 개 객체를 DOM 노드로 렌더링하지 말고 canvas를 쓰는 식의 최적화도 필요함. 최근 지도 애플리케이션에서 이런 문제를 봤음
답변달기