백엔드 개발에서 코드 레벨의 개발과 DB 레벨의 개발이 몇 퍼센트 비율로 진행되나요?

Question

현재 Next.js + Supabase 기반의 개인 프로젝트를 진행 중입니다.백엔드 취준생이지만 만들고 싶은 게 있어서 개인 프로젝트를 진행하다 보니 프론트랑 Supabase같은 솔루션을 이용하게 됐습니다. 그런데 백엔드를 Supabase로 대체하니 오히려 DB 차원에서 신경쓸 것들이 많아지더라고요. 스프링으로 프로젝트를 했을 때는 대부분 코드 레벨에서 처리하던 로직, 또는 아예 신경쓰지 않았던 기능들이 DB에 내장 기능으로 포함되어 있다는 사실을 알게 됐습니다. Supabase로 인증/인가, 보안을 대체하게 되니까 오히려 DB 내장 기능 의존도가 올라가서 안 쓸 수도 없게 됐구요. 그래서 PostgreSQL의 RLS를 비롯해서 함수, 트리거, 인덱싱 부분을 백엔드 프로젝트를 하던 때보다 더 공부하고 있습니다. 그런데 그러다 보니까 드는 궁금증이, 백엔드 개발자가 PostgreSQL같은 DB에 자체적으로 내장된 RLS나 함수, 트리거 등 다양한 기능을 얼마나 활용할지 모르겠더라고요. 사실 같은 기능을 코드 레벨에서 구현하면 테스트가 더 쉬울 것 같기도 하고요. 프로젝트 진행하다가 데이터 모델링 강의를 들었는데 거기서는 "DB 차원에서 지원하는 함수가 당연히 성능 면에서는 코드로 처리하는 것보다 좋다."라고 하더라고요. 그런데 테스트가 불편할 것 같아서 현업에서 얼마나 쓸 지는 모르겠고요.질문입니다. -> 그래서 실제 현업에서 [스프링에서 코딩, DB 내장 기능 처리(쿼리 작성 포함)] 비율이 몇 대 몇 정도 되나요? DB 내장 기능 쓰기는 쓰나요? 하는 일에 따라 다를 것 같긴 한데 전반적인 분위기가 어떤지 궁금합니다.

chytonpide · Answer

DB관련 해서는 주로 동시성 관련해서 transaction 범위를 어떻게 나눌지, 이떻게 인덱싱할지, SELECT FOR UPDATE 같은 쿼리를 사용할지 이런걸 고민하는것 같습니다.mysql 도 쓰고 PostgreSQL 도 써봤지만 이런것 외에 뭔가 DB 레벨의 내장기능을 사용해본적은 별로 없는것 같아요.

WLM · Answer

퍼포먼스 측면에서 문제가 있거나.. DB단에서만 가능한게 아니라면 DB에서 직접 처리하는건 지양하는편이죠특정 DBMS에 의존성이 생깁니다. 백엔드 개발자의 핵심 비즈니스 애플리케이션은 백엔드 서버지 남이 만든 DBMS가 아니니 의존성은 최대한 없애야죠. PostgreSQL을 MySQL로 바꾼다고 비즈니스 레벨 코드를 뜯어고친다..? 품질 낮은 코드가 되어버림..물론 표준 인터페이스로 확정된 것들은 위와 같은 문제에서 상대적으로 자유로우니 사용할 만 합니다.

바람을바람 · Answer

여러 상황에 맞춰서 부하 분산과 기능 독립이 필요한 것 같습니다저는 퀀트 프로그램 개발하고 있는데rust 애플리케이션 내에서도 쓰레드 간에 공유하는 스마트 포인트 Arc<AppState> 같은 전역 상태 데이터 그리고 전역 상태 데이터가 관리하는 애플리케이션 캐시 <- rust 애플리케이션이 재실행 되면 다 날아가버리기 때문에 다른 서버에서 가동되는 redis에도 캐시를 저장하고 우선 참조하도록 하고실시간 시계열 틱 데이터 같은건 postgresql timescaledb table에 기록하고 timescaledb의 시계열 함수 사용해서 통계지표들 생산합니다. 그리고 거래기록이나 포트폴리오, 거래계정 같은 장기데이터는 postgresql table에 저장하고요아래는 분리된 앱과 DB의 각자의 역할API 통신/트레이딩 로직(서버1)과 DB/통계 계산(서버2) 분리에 대한 의견관심사의 분리 (Separation of Concerns):서버1 (Rust 앱): 이 서버의 역할은 *'실시간성'과 '빠른 응답'*이 핵심입니다. API를 통해 시세 데이터를 수신하고, 순간적인 시장 변화에 맞춰 트레이딩 로직을 계산하고, 주문을 실행하는 작업은 지연에 매우 민감합니다.서버2 (PostgreSQL/TimescaleDB): 이 서버의 역할은 *'데이터의 안정적인 저장'과 '무거운 분석 작업'*입니다. 대량의 시계열 데이터를 저장(File I/O)하고, 과거 데이터를 바탕으로 통계를 내거나 복잡한 쿼리를 실행하는 작업은 상당한 CPU와 디스크 자원을 소모할 수 있습니다.이러한 분리의 장점:성능 보장: 가장 큰 장점입니다. 만약 하나의 서버에서 모든 작업을 처리한다면, DB에서 무거운 통계 쿼리가 실행되는 동안 Rust 앱의 실시간 데이터 처리나 주문 실행이 지연될 수 있습니다. 이는 퀀트 트레이딩에서 치명적일 수 있습니다. 서버를 분리함으로써, DB의 부하가 실시간 트레이딩 로직의 성능에 영향을 주지 않도록 완벽하게 격리했습니다.안정성 및 장애 격리: 한쪽 서버에 문제가 생겨도 다른 쪽 서버에 미치는 영향이 최소화됩니다. 예를 들어, DB 서버가 유지보수로 잠시 중단되더라도, Rust 앱은 (과거 데이터 조회가 필요한 로직을 제외하고) 실시간 시세 수신 및 기본적인 로직을 계속 수행할 수 있습니다.독립적인 확장성 (Scalability): 향후 시스템을 확장할 때 매우 유리합니다. 만약 모니터링하는 종목이 늘어나서 트레이딩 로직 계산 부하가 커진다면 서버1만 증설하면 됩니다. 반대로, 저장하는 데이터가 많아지고 분석이 복잡해져서 DB 성능이 저하된다면 서버2만 업그레이드하면 됩니다. 이는 비용 효율적인 시스템 운영으로 이어집니다.

ExpoProvider · Answer

supabase 같은 서버리스 환경으로 넘어가면 사실 백엔드라는 개념이 연기처럼 흩어져 사라지죠.말씀하신 대로, RLS, 트리거, 엣지 펑션, 웹훅 등으로 고전적인 백엔드의 태스크는 거의 모두 해결됩니다. 덤으로, cascade 와 트리거 펑션으로 데이터 무결성도 보다 탄탄해지죠.supabase 는 cron 또한 제공하기 때문에, 백엔드는 사실상 필요 없어집니다.전통적인 의미에서의 백엔드란, 결국 'Last Guard' 라는 느낌이 없지 않아요. 아직 현업에 종사하는 백엔드 분들에겐 불편한 진실이겠지만..... 코드와 관련한 환경 관리는 프론트에게도 어렵지는 않은 일입니다.

장독깨기 · Answer

비지니스용 어플리케이션은 DB 역할, 중요도가 7~8할 입니다.특히, 모델링이 굉장히 중요합니다. 이 부분을 잘해야 합니다. : )

캐티 · Answer

위에 처럼 그런데 데이터 처리가 주류인 어플이 있고, 데이터 출력이 주류인 어플이 있어요. 이럼 비중은 현저하게 달라지는 거이고 어디서는 프로시저에서 모든 데이터를 처리하는 거로 하기도 하여쩌.대중이 없는 거여요.

백엔드 개발에서 코드 레벨의 개발과 DB 레벨의 개발이 몇 퍼센트 비율로 진행되나요?

6개의 답변

Q&A 목록