프로시져를 써야 하는 상황은 어떤 경우 일까요?

Question

전전 직장에서는 프로시저를 적극적으로 활용했습니다. 인터넷 쇼핑몰 전문 SI 업체였는데, 별도의 재고 관리를 위한 ERP 시스템이 존재하는 환경이었습니다.ERP 팀에서 DB 관리 및 설계를 전담했기 때문에, 결제 도메인의 경우 웹 개발팀이 직접 테이블을 건드리지 않고 프로시저를 호출하여 재고, 주문, 포인트 등을 일괄 관리했습니다. 저희는 ERP 팀에서 제공해 준 프로시저 명세와 인자값에 맞춰 호출만 하는 식이었죠. (결제 외의 도메인은 별도 쿼리를 직접 작성했습니다.)그러다 문득 '프로시저는 언제 쓰는 게 좋은가' 궁금해하던 차에 프로시저에 업무로직(비지니스로직)을 넣으면 안되는 이유라는 글을 보게 되었습니다. 결론은 테스트 코드 작성과 로직 분산의 어려움 때문에 지양해야 한다는 것이었습니다.머리로는 이해가 가지만, 여전히 현업에서는 프로시저를 자주 사용하는 케이스가 많아 혼란스럽습니다. 기술은 트레이드오프라고 생각합니다. 분명히 프로시저를 쓰는 선택이 맞는 특정 상황도 있을 것 같은데, 그것이 구체적으로 어떤 경우인지 궁금합니다.

집킨 · Accepted Answer

지금의 보편화된 클라우드 환경, 컴퓨팅 파워, 손쉬운 스케일 아웃 기반 위에 꽃을 피고 있는 유지보수성 높은 설계 기법들이 빛을 보지 못했을땐데이터 중심의 개발과 틈없는 원자성 보장, DB서버라는 거인의 어깨위에서 데이터와 가까이 위치한 지리적 이점 기반 고성능까지 가능한 프로시저가 아주 현명한 선택이였죠개인적인 견해로 오늘날의 소프트웨어 규모나 복잡성, 그리고 많이 진화된 인프라와 개발 문화를 봤을때 이제는 트레이드오프의 대상으로 프로시저는 제외해야한다고 생각합니다옛날에 이미 구축된 프로시저를 여러 이유로 일단 끌고가는게 아닌 이상은요

천사와악마 · Answer

제 생각에 프로시저를 써야할 곳은 성능 몰빵이 필요할 때이미 구축되어 있는 곳일 경우 무중단 배포가 필요한데 환경 구성이 요건에 충족하지 않을 때 연동 데이터가 db 기반인데 실시간 프로그래밍이 필요한 경우 등이정도겠네요. 신규 구축하면서 전 다 걷어내는 쪽을 택했습니다.디비에 비중 두는걸 선호하지 않아서요.

밀수나라 · Answer

DBA가 있을때 입니다. 로직이 DB에 일부 있는건 긴급 상황시 DB단에서도 장애처리가 가능할 수 있습니다.물른 트레이드 오프로 그 부분 때문에 장애가 발생할 수도 있습니다.업계나 도메인에 따라 다릅니다. 게임쪽은 sp를 많이 쓰기도 합니다.

캐티 · Answer

실력이 모자르다 이럼 프로시저에 1억개 데이터 처리를 넣음 안대겠쩌. 서버 성능에 상한이 있어서 터지는 여지가 있어요.아이 .. ERP가 입대사업 방식에 솔루션 이어서 처리량이 지나치게 많았다 이럼 난리가 나겠어도 위에서 이만큼 대단한 ERP를 만드느라 프로시저로 하면 안된다고 하더나요.이런거 정도는 인류 최강에 컴퓨터를 믿어도 대빈담.물론 트롤 개발자가 자꾸 서버를 터뜨리는 코드를 올린다 이럼 프로시저가 아니어도 터지는 운명이기에 댔쩌.

dw kim · Answer

SQL 유지보수 하기 힘들어서요1000줄 짜리 쿼리 1개보다100줄 짜리 쿼리 10개가 낫고100줄 짜리 10개보다10줄 짜리 쿼리 100개가 낫다고 생각합니다아니 한 200개 300개여도 1000줄 짜리 쿼리 보단 나을 거 같아요

코끼리마리오 · Answer

프로시저도 유닛테스트 가능합니다.ms 쪽 문서가 있지요. 대체 프로시저 쓰지마라는사람들은 언제적이야기인지 DB 는 불가하다고만 생각하는지... 모르겠습니다.DB 부하를 낮추고 웹서버단에서 하겠다 이러면 안해도 되지만웹서버 부하가 높고 DB 쪽은 높지 않은데 많은 쿼리를 불러와야된다? 이러면 해야되죠.

yeori · Answer

3 tier 아키텍쳐가 자리잡기 전이던 20여년 전에는 디비 제품들이 미들웨어 역할을 도맡던 시기가 잠깐 있었습니다.지금과 같은 웹애플리케이션이 개화하기 전에 벤더들이 디비에 프로그래밍 기능을 넣어서 팔았고, 이 흔적이 남은 게 프로시저입니다.그 시절에는 디비가 VIEW 역할도 했습니다.지금도 남아있는 formatting 함수들이 바로 그 흔적이죠. 세로 줄맞춤, 정렬, 금액 포매팅 등등...걍 디비로 다 하려고 했지만, 시장의 요구를 기민하게 충족하지는 못했습니다. 디비벤더의 정체성이 데이터 저장, 관리이다보니 프로그래밍은 곁가지로 보는 시각이 강했습니다.과거 IBM이 운영체제를 바라보던 그 시각과 비슷했습니다. 기계가 중심이고 운영체제를 보조 수단, 유틸리티 정도로 여긴 것처럼 프로시저가 딱 그 포지션이었음.이 공백을 서블릿같은 표준 스펙이 메꿔주며 지금의 3tier아키텍쳐가 보편화됩니다.이 레이어에서 장고, 플라스크, expressjs 같은 기술들도 등장하고 다 같이 먹고 사는 중이죠.자연스럽게 디비는 원래 디비가 해오던 일, 데이터를 잘 관리하는 본래의 용도로 한정됩니다. 다른 레이어보다 디비가 병목지점이라 데이터 넣고 빼는 일만으로도 디비는 빡쎕니다. 굳이 여기다 프로그래밍까지 돌려서 자원을 낭비할 이유가 없다고나 할까... 확실히 자원 낭비입니다. 굳이 하려고 애쓰면 가능은 한데, 하지 않습니다.이후 2010년도 들어서서 웹에서도 데스크탑애플리케이션같은 UI 경험을 느낄 수 없을까 고민이 생깁니다. 하지만 View기술을 제공하던 jsp같은 스펙은 이 요구를 충족하지 못했죠.그리고 다시 이 공백을 SPA가 메꿔주며 자리를 잡습니다. View는 오롯이 이 기술들이 전담하고, 스프링같은 기술들은 이제는 "백엔드"라는 이름으로 더 자주 언급됩니다.10여년 전에는 프론트엔드 백엔드를 칼같이 구분하지 않았습니다. 하나의 IDE안에서 양쪽 구현을 모두 해왔으니 지금처럼 경계를 선명하게 인지하지 않았습니다.SPA가 주류로 자리잡고, 개발 도구가 갈라지면서 사람들은 프론트와 백의 경계를 분명하게 인식합니다.이것은 디비에서 프로시저가 밀려난 것과 똑같습니다.

nippori · Answer

개인적으론 한시대 유행했던 개발방식이라고 생각합니다. 언제쓰면 좋은가는 이론상 서버의 부담을 분담한다 할때겠지만 대체 방법은 많으니 예전 방식 같고요. 여전히 현업에서 많이 사용한다는건 대부분 예전 개발 방식을 선호하는 시니어분이 짰거나 오래전 프로젝트의 코드로 남아있는 케이스가 아닐까 생각합니다.

BlueFestival · Answer

하나의 SQL 쿼리로 해결하는 것이 어려워서 웹 서버 <-> DB 서버 간에 여러 번의 커넥션이 벌어져야 할 때.근데 그나마도 이제 JPA 같은 ORM이 보급되기 시작하면서 더 안 쓰는 추세가 됬죠.왠만한 데이터 로직도 웹 서버에서 해결하니깐.

jghjghjg · Answer

절대라는건 없고 프로시저를 사용해야하는경우가 있겠지만 프로시저를 사용해야할 그 상황에 도달한것 자체가 문제일거 같습니다

퓨리오사 · Answer

프로시저는 DB 내부에서만 처리 작업할게 있을 때만 사용하는 것 같아요.예를 들면 테이블에서 다른 테이블로 넣어 줘야 한다던지 가끔 그런 작업이 필요할 때가 있는데 그럴 때 사용합니다.

나릉 · Answer

그 떄 기준으로는 쓸 이유가 있었지만지금 기준으로 쓴다면 그건 틀딱 개발자의 미련이라 볼 수 있습니다탈출해야할정도

프로시져를 써야 하는 상황은 어떤 경우 일까요?

12개의 답변

기타 목록