최근에 프로젝트를 하면서 기존 방식이 흔한 db에 프로시져 만들고 business 로직
거의 프로시져에 두는 방식이 싫어서
ef,.Net 8.0 , 병렬처리 ,윈도우 서비스 배포 등등 최신 기술 쓰다가
실패까지는 아닌데 참 여러모로 개발 속도나 퍼포먼스나 고객 만족(?)
여러모로 쓰디쓴 실패를 맛봤네요
아 제가 부족한것도 있지만 최신기술이 개발속도와 퍼포먼스를 보장하는것 아니다라는
진리 를 알고 덤벼도 결과가 안좋아서 속상하네요
뭐 당연한 말이지만 최신 기술을 많이 안다고
일을 잘하는것 아닌것 같습니다.
개발 욕심과 일 욕심은 다른 것 같습니다
개발자의 욕심을 내려놓는 게 중요하죠
경험하지 않은 기술을 넣고 싶으면 10% 이내만
근데 그게 항상 잘 안되죠
저는 지금 같은팀 개발자들이 너무 맘에 안드는 나머지 엿먹어봐라 하고 최대한도로 최신 문법을 적용해서 개발 중입니다.
덕분에 저도 늦어지긴 하는데요. 뭐 점점 좋아지겠죠. ㅎㅎ
이것과는 별개로 리펙토링을 여유롭게 하는 경우가 아니라면 사실 최신기술 적용이 좋은것만은 분명히 아니죠.
개인적으로는 일단 개발을 하고 좀 여유롭게 리펙토링을 하면서 기술을 충분하게 익힐 수 있게 해주는 회사가 있다면 참 좋을 것 같습니다.
유명하고 많이 쓰이는 것들 대부분 직접 만든 것보다 못한 경우가 많습니다.
직접 만든 건 자기 프로젝트 특성 고려해서 최적화를 하기 때문에 기술과 경험이 충분하다면 그렇죠
최신 기술 검증하고 최적화 하는 비용이 훨씬 크다고 봅니다.
이게 어떤 의미인지 참 궁금하군요.
데이터 베이스 조작에 관해서는 프로시져의 성능을 따라 갈 게 없는 건 사실이나, 비지니스 로직까지 포함하는 것은 여전히 재고할 필요가 있다고 생각합니다.
예전에 유튜버 널널한 개발자님도 성능 보다는 유지 보수를 높게 평가한 적이 있었죠.
그분도 "남이 손 대지 못하는 코드"가 양산되는 현실의 고충을 잘 알고 계시기에 그런 것 아닐까요?
개인적으로 저장 프로시저가 아무리 좋아도, EF 의 타입 안정성은 이길 수 없다… 라고 생각합니다.
AI 가 아무리 좋은 코드를 뽑아 줘도, 그걸 유지보수할 능력이 안되면 글자에 지나지 않듯이 말이죠.
제가 등장할 차례군요 크큭…
sp에 로직을 두는게 싫다고 하셨는데 업종에 따라 다릅니다.
DBA가 계시면 sp는 DBA의 영역입니다. DBA가 단순히 DB 떨어지지만 말라고 빌고 있는 직종이 아니죠.
소켓 서버 같은 경우는 sp에 로직을 넣어야 서버를 내리지 않고 로직을 변경하거나 장애처리가 가능한 경우도 있습니다.
모든 서버가 웹 서버만 있다고 생각하시면 안됩니다. 업종에 따라 sp에 로직을 넣어서 돌리는 이유 또한 다 존재합니다.
ㅎㅎ
똑같이 ef 가 웹서버에만 쓸수있다는 것도 편견입니다
음 생각보다 필드에서 EF 를 사용하는곳은 별로 없습니다.
아마도 상담수 실무에서 RDB 에 프로시져로 비지니스 로직 두는
개발방식이 절반 이상이라고 생각합니다.
글쎼요 Linq랑 EF를 구분못하는 분들도 많아요 ;;
SP 에 로직을 둘때 일단 Unmanage 성 리소스로 분류 될수 있죠?
그 프로시져를 만든 사람에 종속되는 코드 같습니다.
프로시져가 몇개 안될때는 구분이 잘가죠 근데 어느순가
수백 수천개 될때 관리가 안되고
만들었어도 이런 프로시가 있어나 하면서 중복하면서 만들게
되고요 그리고 프로시져 무서워서 스키마 변경이나 확장에 걸리는 경우가 많죠
아마도 java mybatis , JPA 를 쓰는 이유도 이렇게 PROC 관리가 안되서
쓸것라고 생각합니다.
EF 는 DB First로 개발할때는 좀 문제가 많지만 Code First 일때는
장점이 있다고 봅니다.
SP 랑 EF 는 상황에 따라 적절히 배분되는것이 좋다고 생각합니다. 저같은 경우는 EF로 대부분을 작성하긴 합니다. transaction을 이용하면 왠만해선 SP 가 필요없다고 느낄정도에요. 하지만 댓글에 있는 내용처럼 SP 변경만으로 해결할수 있는 부분도 있는 것이고 상황의 변수는 너무나 많아서 병행하고 있습니다. .net 프로젝트들은 대부분 일반적으로 코딩지식만 있다고 해서 잘할 수 있는 것 같진 않습니다. 단순히 코드를 잘 짜는 것 이상의 역할을 해야 해요. 서버와 네트워크 인프라, 그리고 사용자 제공 서비스의 속성과 사용 패턴, 관리자 운영 방식 등 전체 시스템의 모든 요소를 깊이 이해하고 이를 바탕으로 최적의 아키텍처를 구성할 수 있어야 합니다. 이런 포괄적인 분석력과 문제 해결 능력이 프로젝트의 전반적인 성공과 안정성에 결정적인 역할을 한다고 생각해요. 결국 .net 개발자들은 전체적인 설계자로서의 소양을 키워가는게 좋다고 생각합니다. 그리고 .net 개발을 계속 하다보면 그쪽으로 점점 진화하게 되는 것 같아요.
한참 예전글이 다시 수면위로(?) 떠올라 보았는데 스레드 내용중
이 내용 부분에 있어 오해의 소지가 있을거 같아 댓글을 달아 봅니다.
sp를 좋아하고, 지향하시는 분들의 주장중 하나가 바로 “sp를 사용하면 서비스 재시작이나 재부팅 없이 업데이트가 용이하다” 부분을 많이 보았는데…
사실 이 얘기는 반대로 그 회사의 인프라중 Continuous Delivery/Deployment 부분이 제대로 안되어 있거나 아예 구축이 안되어 있다라는 얘기와도 같다고 볼 수 있습니다.
인프라가 갖추어져 있다면 무중단 배포 전략을 통해 얼마든지 간편하고 빠르게 서버 업데이트가 가능합니다.
때문에 그 기반으로 많은 개발자 또는 데브옵스 직군 역량에 도커/쿠버네티스 등 경험을 요구하고 있는 이유 중 하나 이기도 합니다.
꼭 모든 상황이 그렇지 않습니다.
프로덕트가 stateful이냐 stateless냐에 따라 SP를 사용해야만 무중단 배포를 실현 할 수 있는 상황이 있습니다.
대표적인 예가 게임서버의 월드서버와 같습니다.
SP가 아니라 어플리케이션에 로직이 탑재되어 있다면 점검은 불가피합니다.
"적정 기술"이라는 것, "유지 관리 가능성"이라는 것, 그리고 “요구 사항에 충실한가” 라는 질문들에 자신있게 답할 수 있어야 한다고 생각합니다. 아쉽게도, 최신 기술이 이런 부분들에 대한 답을 주는 경우는 많지 않습니다.
지금 가지고 있는 기술 스택에 분명한 한계를 느끼고 문제를 인식할 때, 그 문제를 해결할 새로운 시도나 기술을 찾아나가는 과정이 있어야 한다고 생각합니다. 그렇지 않다면 말씀하신대로 기술만 연구하다 아무것도 하지 못하고 끝날 가능성이 크죠. ㅎㅎ
어… 근데 댓글과 제목이 달라지는 양상인뎅
저는 자꾸 이 글의 제목에 낚이는 느낌이군욤… ㅋㅅㅋ
그래서 제가 일부러 대댓을 달지 않는 이유입니다.
제가 하고싶었던 말은 sbluemin님이 다 해주셨으니 대신 감사드립니다.
저도 무중단 배포에 관해서는 안정적이긴 하나 모든 상황에서 완벽할 수는 없는것 같습니다. 배포 1회에 한해서라면 몰라도 업데이트 기간이 짧고 배포가 잦을수록 구버전에 남아있는 사용자 때문에 무중단 배포의 의미는 좀 희석되는 것 같아요.