F monologue

원문 : http://codebetter.com/blogs/jeremy.miller/archive/2006/05/25/145450.aspx

나는 스스로 다른 포스트에서 저장 프로시저에 관해서는 다루지 않겠노라고 했지만, sproc에 관한 에릭의 포스트가 내 뚜껑을 열리게 하고 말았어. 애자일 이전 시기인 4년 전에, VB6/ASP 코딩을 하던 나는 에릭의 pro-sproc 입장에 열렬히 동의했으며, PL/SQL을 가득 채워서 작성했지만, 요즘 sproc 질문에 관한 나의 대답은 확고하게 “필요없음” 또는 최소한 “결백을 입증하기 전까지는 유죄” 라는 입장이야. 게다가 나는 sql server 가게의 Oracle 사나이이고, T-SQL을 경멸해.

첫째, 몇가지 근거들. 나는 1998년 경, ASP 코드에 adhoc SQL을 사용했던 사실은 모두가 경멸할 것이라고 생각해. CRUD에 sproc을 사용해서 큰 문제는 없었지만, O/R 매핑에 의한 도메인 모델 접근법은 모든 중요한 개발시간의 항목들에서 좀 더 효율적이며, 도메인 모델 접근법은 좀 더 나은 코드를 도출한다고 생각해. 우리 애플리케이션의 새로운 부분은 간단히 NHibernate 매핑을 변경함으로서 데이터베이스 변경사항을 처리하지. sproc은 더 이상 필요하지 않아.

에릭의 포스트는 이러한 점을 먼저 지적해.

TDD 진영에서 저장 프로시저와 뷰를 배척하는 것을 목격했을 때 나는 무척이나 혼란스러웠다.

그 답은 무척간단하다고, 에릭. 저장 프로시저는 TDD를 느리게 만들고, 비생산적이야. 저장 프로시저의 업무 로직은 도메인 모델 클래스에 대응하는 로직보다 테스트 하기 위해 더 많은 일을 하도록 하지. 참조 무결성은 단순히 테스트에 필요한 데이터를 삽입하기 위해 다수의 다른 데이터를 준비하도록 종종 당신을 속박해(우리처럼 아무런 외래키가 없는 낡은 데이터베이스 환경에서 일하는 경우는 제외하고 ). 저장 프로시저는 태생적으로 절차적이고, 따라서, 고립된 테스트들을 만들기 어렵고, 코드 중복(중복된 “where”절은 중복된 코드이고 중복은 나쁜 것이지)을 만들기 일쑤야. 또 다른 고려사항으론, 데이터베이스를 사용하는 어떠한 자동화된 테스트는 애플리케이션 영역 내부에서 동작하는 테스트보다 느리다는 사실은, 대규모 애플리케이션에선 아주 훌륭한 거래라는 거야. 느린 테스트는 긴 피드백 사이클을 유도하지. 이것 하나만은 나를 믿어. 20분의 CI 빌드와 5분의 빌드시간 중 어느 것이 팀을 더 느리게 하는지…..

내기 하나 하지. 나는 내가 최근 6개월 내에 ADO.Net을 직접 조작하는 코드를 100줄 이상 작성한 적이 없다에 걸겠어. 물론 이 기간동안 기능상 새로운 것들이 다수 포함되었어. 난 그리고 그동안 아주 작지만 사소하지 않은 SQL을 작성했지. 우리가 개발한 작은 OO 쿼리 엔진과 NHibernate 둘 다 데이터 접근 혼란에 시간을 낭비할 필요가 없도록 해줬어. 제프 애투드는 저장 프로시저는 데이터베이스의 어셈블리어라고 이야기 했지. 난 앞으로 sproc을 성능상 이득이 필요할때 사용하겠지만 성급한 최적화이기 때문에 아마 그럴 일은 없을거야.

내 생각에 sproc에 관한 생각의 격차는 애플리케이션에서 데이터베이스의 역할을 어떻게 보느냐에 있는 것 같아. 데이터 베이스가 하나의 지속(persistence) 매커니즘으로서 또는 단지 .Net 코드로서 UI는 앞으로 보내고 데이터를 뒷단으로 가져오기 위한 방법인지 이야기 해볼까?  내가 빌드한 애플리케이션들은 업무(business) 규칙에 기반하지 단지 리포팅을 위한 것만은 아니야. 나에게 데이터베이스는 단순히 우리 도메인 객체들과 메시지들을 위한 지속 메커니즘일 뿐이야. 이렇게 하면, 테스트용이성과 거의 같은 말인, 유지용이성이 아주 끝내줘. 수용(acceptance)과 단위 테스트 수준에서 크고 포괄적인 자동화된 테스트들의 핵심은, 적어도 내 생각으론, 이것들을 수용하는 가장 좋은 방법은, 바로 코드를 변경하는 것이야.

다시 에릭의 포스트로 돌아가서, 이 부분이 정말 날 열받게 만들었어 (이건 에릭 당신에게 직접적인건 아냐)

당신네 DBA 팀은 프로그래밍 팀과 완벽하게 독립적으로 일할 수 있고, 요구사항이 무엇이든 수행하고, 애플리케이션은 신경쓰지 않아!

제길, 아니야 아니야 아니야!!!!!  DBA는 거의 확실히 프로그래밍팀과 독립적으로 일하지 않는다고. 저장 프로시저는 코드이고, 그렇기 때문에 잠재적으로 코드를 파괴할 수 있어. 만약에 저장 프로시저를 변경하면 제품화 되기 전에 *반드시* 저장 프로시저에 대응하는 애플리케이션을 통합하고 테스트 해야 해. 난 이것 땜에 열받은 적이 한두번이 아니야. 저장 프로시저 코드는 절대적으로 CI 빌드로 빌드되고 버전화되어야 해. 코드와 동기화 되지 않은 sproc으로 인한 버그 때문에 괴로워. DBA 또는 유지보수 개발자의 생각은 각각 다른 버전의 sproc을 데이터베이스에 심자라는 것인데 이건 진짜 나쁘고 위험한 방식이야.

추가 설정 관리라는 부담은 대부분의 애자일 팀들이 저장 프로시저로부터 떠나게 된 하나의 이유야. 코드에서 NHibernate 매핑이나 파라미터화된 SQL에 의존하면 SQL은 C# 코드와 함께 자동으로 빌드되고 버전화 될 거야. sproc과 C# 코드의 불일치로 일어나는 손실을 훌륭하게 최소화하지. 우리 C#은 CruiseControl.Net 빌드 번호로 표시되어 조립되고 그것으로 간단하게 불일치를 줄일 수 있지. 저장프로시저들은 음….. 자….. 어…. 꽤나 솔직히 말하자면 테스트 된 대응코드와 그게 같은 버전인지 알 수가 없어

가장 최악인 건, sproc과 미들티어 코드사이의 기능 분리라는 이 사실이 끔찍하게도  마이크로소프트 개발 세계의 상식이라는 것. 부르르르르… 당신은 단순히 코드를 망가 뜨리고 시스템을 이해하는데 지적 부하를 가중시킬 뿐이야.