DB 개발자를 위한 조언
향상된 PL/SQL 엔지니어링

최광호 이사 l Kwangho.choy@quest.com｜퀘스트소프트웨어코리아

PL/SQL은 DB 환경에서 실행되는 절차적인 데이터베이스 프로그래밍 언어로 비교적 익히기 쉽고 오라클 데이터베이스와 긴밀히 통합되는 특성을 지니고 있어, 복잡한 대규모의 데이터베이스 작업을 수행하는 데 있어서 가장 효율적인 방법으로 꼽히고 있다. 지난 수 십 년 간 PL/SQL은 발전을 거듭해 왔으며, 최근 들어 강력하고 고도의 기능을 자랑하는 성숙한 데이터베이스 언어로 자리 잡고 있다.

익히기 쉽고 강력한 PL/SQL이라 하더라도 판독 및 유지 보수의 용이성과 프로그램의 효율 등이 자동으로 보증되는 것은 아니다. 실제로 PL/SQL을 현실의 운영 환경에서 실행했을 때, 심각한 위기가 초래될 때까지 PL/SQL의 코드 오류가 발견되지 않는 경우가 상당히 많았다.

해결 과제들

문제는 ‘PL/SQL을 보다 효과적으로 설계하는 방법은 무엇인가’라는 점이다. 여기서는 일반적으로 널리 사용된 일부 수작업 방식의 문제점을 검토하고, PL/SQL 개발 프로세스를 향상시키는 방법에 대해 조언하고자 한다.

소프트웨어 결함으로 인한 손실

보다 향상된 PL/SQL 엔지니어링을 통해 실현되는 총 가치를 파악하기 위해서는, 먼저 그렇게 하지 않았을 경우의 결과를 이해하고 이를 올바르게 인식해야 한다. 제대로 엔지니어링 되지 못한 코드에서 발생하는 손실은 어떤 것일까 그것은 바로 심각한 혼란이다. 한 조사에 따르면, 수준 낮은 소프트웨어 엔지니어링과 불충분한 테스트만으로 미국에서 총 594억 달러에 이르는 손실이 발생했다고 한다. 이와 관련해 오늘날의 현황을 분석하면 다음과 같다.

- 개발자들이 소프트웨어 결함을 수정하는 데 업무 시간의 40%를 소비하고 있다.
- 유지보수에 소프트웨어 비용의 60~70%가 지출되고 있다.

즉, 개발자들이 버그를 수정하는 데 일반적으로 지나치게 많은 시간을 투입하고 있을 뿐 아니라, IT 부서 역시 너무 많은 예산을 지출하고 있음을 지적할 수 있다.

‘베스트 프랙티스’의 실패

개발자들이 코딩을 시작할 때는 비록 그것이 길고 어려운 절차이더라도 마음속으로는 최상의 목표를 정할 것이다. 하지만, 실제로 대부분의 개발자들이 베스트 프랙티스의 정신만을 따른다고는 말할 수 없고, 또한 항상 베스트 프랙티스에 따라 데이터베이스 애플리케이션을 개발하고 실행할 수 있는 것은 아니다. 오늘날의 복잡한 대규모 데이터베이스 애플리케이션에서는 모든 것을 포착해 내는 품질 보증(QA)을 기대하기가 어렵다. 애플리케이션 코드는 근본적으로 견고해야 하지만, QA는 단순히 예외를 파악하는 데 그치고 있는 것이다. 이것이 바로 베스트 프랙티스가 근본적으로 결점을 지닌다고 평가되는 이유다. 방법론적으로 베스트 프랙티스는 현실성과 일관성, 측정 가능성, 그리고 효율성 등에 대해 한계를 지니고 있다.

코드 검토의 문제

코드 검토는 개발자가 자신의 프로그램 단위를 작성해 테스트를 수행하고 프로젝트 관리자에게 제출해 피어 리뷰(peer review)를 수행하는 프로세스를 반복해 품질을 확인하는 방식으로 이뤄진다. 이러한 방식의 장점은 이상적인 조건 하에서 품질 측면의 우수한 결과를 도출할 수 있다는 것이다. 그러나 이 방법은 시간과 비용 모두가 증가한다는 단점이 있다. 또한 방법론적으로 모든 사람이 모든 규칙을 동일한 방식으로 해석하며 동일한 규칙을 적용할 수 있는가라는 일관성의 문제를 적절하게 해결할 수 없으므로 이 역시 실패라고 볼 수 있다.

소프트웨어 엔지니어링의 위기 탈출

그럼 소프트웨어 엔지니어링과 관련해 고려해야 할 프로세스에는 어떤 것들이 있을까 이를 3단계로 나눠 살펴보자.

1단계 : 베스트 프랙티스 및 코드 검토 자동화

앞에서 언급한 기법 가운데 일부, 즉 베스트 프랙티스와 코드 검토에 대해 다시 살펴보자. 아마도 이들 기법들이 기본적인 결함으로 인해 실패한 것이 아님을 알 수 있을 것이다. 오히려 두 방법 모두 완전 수동 프로세스에 크게 의존하기 때문에 신뢰할 수 없거나 일관된 결과의 산출을 보장할 수 없었다. 하지만, 이와 같은 결함은 ‘Toad for Oracle’과 같은 효과적인 데이터베이스 개발 툴을 사용함으로써 쉽게 극복할 수 있다. 이를 통해 해당 CodeXpert 기술을 쉽게 활용할 수 있고, 나아가 포괄적인 베스트 프랙티스의 확인이나 기본 코드 검토 모두를 완전히 자동화할 수 있다. 이는 다음과 같이 4단계의 간단한 프로세스로 이뤄진다.

첫째, Toad의 SQL이나 Procedure Editors에서 CodeXpert를 사용할 수 있는지(즉, 표시되는지) 확인해야 한다. <화면 1>에 표시된 것처럼 하단 패널 탭에 마우스를 갖다 대고 오른쪽 마우스의 메뉴 옵션을 누른 후, Desktop을 선택해 CodeXpert 메뉴 항목이 체크되어 있는지를 확인하기만 하면 된다. 이제 CodeX pert에 완벽하게 액세스해서 활용할 수 있다.

<화면 1> CodeXpert 메뉴의 체크 확인

둘째, PL/SQL 코드를 검사하는 데 사용할 규칙 모음(‘규칙집합’이라고도 함)을 선택해야 한다. <화면 1>을 다시 참조해 하단 패널 도구모음 중간의 드롭다운 상자에 표시된 기존 규칙집합 영역에서 규칙집합을 하나 선택한다. 사전 준비된(혹은 기존의) 규칙집합이 기업 표준으로 충분하지 않다면 맞춤형 규칙집합을 작성해야 한다. 이를 실행하려면 규칙집합 선택 드롭다운 메뉴의 오른쪽에 위치한 빨간 깃발이 있는 폴더 모양의 하단 패널 도구모음 아이콘을 누른다. 그러면 <화면 2>처럼 규칙집합 정의 화면이 실행된다.

<화면 2> 규칙집합 정의 화면의 실행

CodeXpert 규칙 영역에는 모두 144개의 베스트 프랙티스 규칙이 포함되어 있고, 이들 중 상당수는 세계적으로 유명한 PL/ SQL 작성자 및 전문가들이 정의한 것이다. 또한 12개 이상의 사전 정의한 규칙집합이 존재하고, 이들은 권장되는 유용한 그룹화 및 활성화 규칙 가운데 몇 가지를 포함하고 있다. 이들 규칙 중 하나가 프로젝트나 기업표준으로 충분치 않은 경우에는 원하는 규칙들만 활성화해 자신만의 고유한 규칙집합을 간단히 작성할 수 있다.

셋째, 이제 CodeXpert를 간단히 호출해 검사 작업을 수행할 수 있다. <화면 3>을 보면 3개의 중요한 도구모음 버튼이 존재한다. 가장 왼쪽에 있는 이중 화살표 도구모음 버튼은 검사를 시작하는 것이고한다. 두 번째 버튼(안에 빨간색 깃발이 있고 그 위에 손모양이 있는 폴더)을 누르면 CodeXpert 검사는 사용자가 선택한 규칙집합 및 해당규칙들을 적용해 완전히 자동으로 베스트 프랙티스 코드 검토를 수행한다. 일반적으로 이 프로세스는 불과 몇 초 밖에 걸리지 않는다(비교적 큰 PL/SQL 프로그램 단위의 경우에도 마찬가지다). 세 번째 버튼(‘SQL’이란 글자가 반짝이는 플래시)을 누르면 CodeXpert 검사가 자동화된 상세한 SQL 튜닝이나 최적화 분석을 수행하며 이는 다음 섹션에도 적용된다.

<화면 3> CodeXpert 검사 작업을 위한 도구모음 버튼

마지막 네 번째로는 CodeXpert 검사의 결과를 조사하고 표준을 위반한 모든 문제들을 수정하기만 하면 된다. <화면 4>를 통해 PL/SQL 코드의 몇 행이 얼마나 단순하게 보이는지를 확인할 수 있다. 하지만 CodeXpert는 5개의 중요한 베스트 프랙티스 코딩 규칙을 위반했는지, 또는 커서 열기만 포함하고 닫기는 포함하지 않았는지를 확인했다. 이처럼 CodeXpert를 통해 신뢰할 수 있고 일관된 베스트 프랙티스 코드 검토 작업을 완벽하게 자동화 할 수 있다.

<화면 4> PL/SQL 코드의 확인

2단계 : 개별 SQL 문 튜닝 자동화

이는 Toad의 CodeXpert와 같은 개발 프로세스 자동화 툴을 사용해서 실제적으로 성과를 거두고 있는 부분이다. 기본적으로 일반적인 코드 검토는 단순히 이전 섹션에서 적용한 항목처럼 비즈니스 로직 및 언어 구성체에 초점을 맞춘다. 그 결과, 해당 코드 내 SQL 문의 효율성을 검토하는 데 매우 짧은 시간과 적은 노력만이 필요한 경우가 종종 있다. 코드를 검토하는 개발자들은 Explain Plan 또는 기타 관련된(때로는 막연한) 튜닝 문제들을 모두 검토하는 데 충분한 시간을 가지고 있지 않다. QA 프로세스가 충분한 크기의 데이터베이스에서 해당 PL/SQL 코드를 실행하지 않는다면 문제가 있는 현업 환경으로 이동할 때까지 알아채지 못할 것이다. 따라서 ‘튜닝해야 하는 SQL을 어떻게 식별해 낼 수 있는가’라는 과제에 직면하게 된다.

개발자는 비즈니스 요구 사항과 코드 자체를 훨씬 정확하게 알고 있어야 한다. 또한 개발자는 코드상호 작용에 대한 보다 우수한 통찰력(즉, 해당 코드가 전체 애플리케이션에 어떻게 적용되는지, 또는 영향을 미치거나 영향을 받는 다른 코드는 무엇인지 등과 관련된)을 갖춰야 한다. 따라서 개발자가 실제 문제에 집중할 수 있도록 지원하며 최소한의 노력으로 최적의 솔루션을 발견할 수 있도록 하는 툴이 필요하다.

CodeXpert와 같은 기술이 현재 각광 받고 있는 것도 바로 이런 이유 때문이다. CodeXpert는 복잡하거나 문제의 소지가 있고, 혹은 유효하지 않은 SQL 문을 발견해 수정하는 작업을 완전히 자동화하도록 지원하기 때문이다. 이는 다음과 같이 4단계의 프로세스로 수행된다.

첫째, 코드 검토 검사 중 적용해야 할 SQL 스캐너 튜닝 옵션이 무엇인지를 정의해야 한다. 이를 실행하려면 ‘SQL’이란 글자가 반짝이는 플래시 오른쪽에 위치한 도구상자(체크마크가 있는) 형태의 하단 패널 도구모음 아이콘을 누르기만 하면 된다. 그러면 <화면 5>와 같이 SQL 스캐너 옵션 화면이 실행된다. 이 화면에는 SQL 튜닝 탭과 최적화 옵션 탭이 포함되어 있다. 여기서는 주석 내에 포함되거나 SYS.DUAL 테이블만 참조하는 SQL 문을 제외시키도록 선택하는 방법에 유의해야 한다. 간단한 SQL 문이나 복잡한 SQL 문, 그리고 문제가 있는 SQL 문 등을 구성하도록 자세한 특징 설정을 지원하는 사용자 환경 설정 기능도 제공된다. 예를 들어 3~5개의 조인을 포함한 모든 SQL 문은 복잡하거나 문제로 발전될 소지가 있다. 또한 조인이 6개 이상 포함된 SQL 문은 문제가 있는 SQL 문이 되기 때문에 사용 중인 부분을 전체에 맞춰 최적화하는 데는 사용자의 상당한 노력이 요구된다. 여기에서 실제로 정의되는 것은 검사 툴이 해당 결과를 분류하는 방법이다. 즉, CodeXpert는 마치 ‘백사장에서 바늘 찾기’와 유사하게 세심한 부분까지 찾아내고, 아울러 관련 처리에 대한 결과를 분류한다.

<화면 5> SQL 스캐너 옵션

둘째로는 <화면 6>에 표시된 대로 ‘SQL’이란 글자가 반짝이는 플래시의 왼쪽에서 세 번째 버튼을 누른다. 이어 검사를 시작하기 위해 맨 왼쪽에 있는 이중 화살표 도구모음 버튼을 누르면 자동화된 자세한 SQL 튜닝 및 최적화 분석도 수행된다.

<화면 6> SQL 튜닝과 최적화 분석을 위한 버튼

셋째, CodeXpert 최적화 검사의 결과를 조사하고 최대한 주의를 기울여 작성한 모든 SQL 문을 튜닝한다. <화면 7>에서는 SQL Editor의 매우 긴 스크립트를 단지 열기만 했는데 CodeX pert는 문제가 있는 4개의 SQL 문이 있다는 사실을 파악했다. 실제로 해당 명령문을 실행하지도 않고 이를 수행한 것이다.

<화면 7> 문제가 있는 4개의 SQL 문 확인

이것이 얼마나 중요한지를 말로 설명하는 것은 쉽지 않다. 이는 마치 튜닝 전문가가 옆에 앉아 최적화 후보들을 모두 지적하거나, 혹은 튜닝을 수행하는 데 더 많은 시간을 보낸 것에 대해 상을 주는 것과 같다.

시스템에 부담을 주는 실행 취소를 추가하지 않고도 이 모든 것을 수행한다는 점도 주목할 만하다. 아울러 개발자들은 CodeXpert를 이용해 약간의 추가적인 노력과 매우 적은 시스템 오버헤드만으로 신뢰할 수 있고 일관성 있는 SQL 튜닝 및 분석을 수행할 수 있다.

3단계 : 입증된 과학적 측정 지표를 통한 코드 향상

앞의 두 단계는 명확하게 올바른 방향으로 이끄는 것이다. SEI 완성 모델은 프로젝트 관리, 개발 표준, 적응성 측정, 지속적인 향상 등을 수행함으로써 소프트웨어 개발 프로세스 성과를 높였다는 점을 기억해야 할 것이다. 현재 많은 개발업체들이 우수한 프로젝트 관리 기법 및 툴을 사용한 덕분에 레벨 1(초기 단계)에서 레벨 2(반복 단계)로 발전할 수 있었다. 하지만, 지나치게 많은 기업들이 등급을 더욱 높이기 위해 베스트 프랙티스나 코드 검토를 위한 수동 애플리케이션을 주로 활용함에 따라 신뢰성과 일관성을 잃는 결과를 초래했다.
실제로 이들은 레벨 3(정의 단계)에 도달하기 위해 지속적으로 노력하고 있다. 이에 CodeXpert는 우수한 코딩과 튜닝 표준에 대한 신뢰할 수 있고 일관된 애플리케이션을 자동화함으로써 이와 같은 목표를 달성할 수 있도록 지원달하려면 어떻게 해야 할까

SEI 완성 레벨 4(관리 단계)에 도달하기 위해 중요한 첫 번째 단계는 정량분석을 이해, 수용 및 구현하는 것이다. 정량분석에 대한 정의는 다음과 같이 내릴 수 있다. 정량분석이란 복잡한 수학 및 통계 모델링, 측정, 연구를 사용하여 동작을 이해하려는 분석기법으로 수치 값을 변수 분석자, 양적 분석자에게 할당하여 실체를 수학적으로 해독하려는 것이다.

첫 번째 중요한 측정 지표는 Halstead Complexity Measure (http://www.sei.cmu.edu/str/descriptions/halstead.html 참조)이다. 이 측정 지표는 단순히 소스 코드에서 연산자 및 피연산자의 수를 바탕으로 수치적 복잡도 등급을 분류하며 그 추론방법은 다음과 같다.

먼저 코드를 표시하고 계산한다. 여기서,

n1 = 개별 연산자의 수
n2 = 개별 피연산자의 수
N1 = 연산자의 총계
N2 = 피연산자의 총계

Halstead 계산은 <표 1>과 같이 적용된다.

<표 1> Halstead 계산

Volume(V)의 결과는 실제 상황에서 이해하고 적용하기 쉽다. 프로그램 단위의 이상적인 범위는 20~1,000개 사이이며 등급이 높을수록 코드는 더 복잡해진다. 프로그램 단위가 1,000개 이상이면 매우 복잡해진다. 기본 개념은 프로그램 단위의 수가 낮을수록 코드는 더 단순해지고 효율이 더 향상된다는 것이다.

두 번째로 중요한 측정 지표는 McCabe의 Cyclomatic Complexity(http://www.sei.cmu.edu/str/descriptions/ cyclomatic.html 참조)이다. 이는 폭넓게 사용되는 측정 지표로 프로그램의 적절성 및 확실성을 광범위하게 측정한다. 프로그램 단위를 통해 1차의 독립적인 경로 수를 측정하고 다른 프로그램의 복잡도와 비교할 수 있는 단일서수를 할당한다. 추론 방법은 다음과 같다.

Cyclomatic complexity (CC) = E - N + p
(여기서 E = 그래프의 가장자리 수)
N = 그래프의 노드 수
p = 연결된 구성 요소의 수

이 공식은 매우 간단해 보인다. 하지만 이 측정 지표는 사실 가장 복잡한 계산공식 중 하나로 매우 복잡한 수학 및 그래프 이론에 기초하고 있다. Cyclomatic Complexity는 일반적으로 실행 경로를 표시하는 노드 사이의 화살표와 그래프의 노드가 되는 소스 코드의 각 행으로 소스 코드의 그래프를 작성해 계산한다. 이 측정 지표는 고도로 수학적인 특징을 지니므로 이를 계산하도록 고안된 소프트웨어 툴을 사용해야만 계산할 수 있는 경우도 종종 있다.

그러나 McCabe의 Cyclomatic Complexity 측정 지표는 코드의 복잡도를 판단하는 수치평가를 이해하고 향상시키는 가장 쉬운 방법 중 하나로 제공된다. <표 2>를 살펴보자.

<표 2> CYCLOMATIC COMPLEXITY

이 측정 지표는 조건부 구성체나 루핑 메커니즘(소스 코드를 통해 추가 경로를 작성하는 2개의 핵심항목)과 매우 긴밀하게 연결되어 있으므로 실제로 보다 높은 점수를 받기 위해서는 매우 손쉽게 이를 조사한 다음, 코드를 적용할 수 있다. 또한 복잡도가 높은 프로그램 단위는 더 낮은 기능적 응집도를 가지는 경향이 있다고 예상하는 것이 타당하다. 즉 결정 위치가 늘어날수록 하나의 완벽하게 정의된 기능이 될 가능성이 낮아지는 상관관계를 가지는 셈이다. 이 측정 지표가 개발자들이 코드의 행을 기능적으로 더욱 세분화하도록 만든다는 것이 이에 대한 공통적인 결론이다. 이 모든 장점들은 단지 하나의 단순한 작은 수치 등급을 통해 획득할 수 있다.

세 번째로 중요한 측정 지표는 Maintainability Index 또는 MI이다(http://www.sei.cmu.edu/str/descriptions/mitmpm. html 참조). 이 측정 지표는 중요한 Halstead 측정 지표, McCabe의 Cyclomatic Complexity, 코드의 행 및 주석 수를 결합한 매우 복잡한 다항방정식을 이용해 계산되며 추론 방법은 다음과 같다.

171 - 5.2 * ln(aveV) - 0.23 * aveV(g’) - 16.2 * ln (aveLOC) + 50 * sin (sqrt(2.4 * perCM))

aveV = 모듈당 평균 Halstead Volume V
aveV(g’) = 모듈당 평균확장된 Cyclomatic Complexity
aveLOC = 모듈당 코드행(LOC)의 평균수
perCM = 모듈당 주석행의 평균 비율

McCabe의 측정 지표에서처럼 이 측정 지표 역시 이를 계산하도록 고안된 소프트웨어 툴을 사용해야만 계산할 수 있다. 수학적인 것 이상을 보고, 이와 함께 이 측정 지표가 의미하는 바에 대한 근거를 이해한다면 다음의 항목들을 측정해 수량화하려는 것을 이해할 수 있다.

- 연산자 및 피연산자의 밀도(사용된 변수의 수 및 사용 방법)
- 로직 복잡도(코드에 있는 실행 경로의 수)
- 크기(존재하는 코드의 수)
- 사용자의 통찰력(코드에 있는 주석)

이 개념 역시 단순한 수치등급으로 분류되지만 이전의 두 측정 지표보다 더 본질적인 토대 및 근거를 가진다. HP가 내놓은 자료를 보면 Maintainability Index 수치 해석에 대해 다음과 같이 분류할 것을 제안하고 있다.

<표 3> MAINTAINABILITY INDEX

그럼 앞으로 우리가 실생활에서 이 개념을 사용하려면 어떻게 해야 할까 Toad의 CodeXpert로 되돌아가 보면 CodeXpert가 이들 모든 측정 지표에 대한 지원을 제공하고, 이전과 마찬가지로 버튼을 누르면 모두 수행된다는 사실을 확인할 수 있다.

<리스트 1>은 의도적으로 매우 어설프게 작성한 PL/SQL 프로시저이다. 기본적으로 입력 매개변수 p를 1이라고 가정하면 이 코드는 댈러스시의 모든 고객들을 텍사스 주로 업데이트할 것이다. 이 코드는 한편으론 불필요한 루프계층의 단순한 로직을 묻어버리고 필요 이상으로 복잡한 조건부 로직을 구현하고 있다.

<리스트 1> 어설프게 작성된 PL/SQL 프로시저

CREATE OR REPLACE procedure demo1 (p in out integer)
is
x integer;
y integer;
z integer;
begin
for a in 1 .. 100 loop
for b in 1 .. 100 loop
for c in 1 .. 100 loop
for d in 1 .. 100 loop
x := a + b + c + d;
if (p=1) and (x>399) then
update customer
set state = 'TX'
where city = 'DALLAS';
end if;
end loop;
end loop;
end loop;
end loop;
end;

<화면 8>은 Toad의 CodeXpert가 프로그램 단위의 측정 지표 등급으로 표시되는 것을 보여주고 있다.

이제 이와 동일한 내용을 수행하는 훨씬 간단하고 명료한 코드를 작성한다. 가능한 최상의 측정 지표 등급을 얻기 위해 CodeXpert를 써서 PL/SQL 코딩의 베스트 프랙티스 표준을 시행하고 코드를 수정했다. 과도하거나 어리석은 루프는 모두 제거하고 조건부 로직 또한 간소하게 구현했다(즉, 더 이상은 400번째 반복에 대한 테스트 및 루프 카운터를 모두 계산하지 않는다). 결과 코드는 매우 읽기 쉽고 유지보수가 용이해 보이며 훨씬 효율적이다.

<리스트 2> 간소화된 코드

CREATE OR REPLACE procedure demo3 (var_p in out integer)
is
var_city varchar2(6) := 'DALLAS';
var_state varchar2(2) := 'TX';
begin
if (var_p = 1) then
update customer
set state = var_state
where city = var_city;
end if;
end demo3;

<화면 9>는 Toad의 CodeXpert가 향상된 프로그램 단위의 측정 지표 등급으로 표시하는 것을 보여준다. 여기서는 세 가지 측정 지표를 모두 다음과 같이 향상시켰다는 사실에 주목해야 한다. Halstead Complexity Volume은 336%, McCabe의 Cyclo matic Complexity는 300%가 각각 줄었고, Maintainability Index는 32% 감소했다. 이제 코드의 신뢰성과 관련해 정확한 양적 평가를 할 수 있으므로 SEI 완성 등급인 레벨 4(관리)에 거의 도달한 것으로 볼 수 있다.

그러나 이에 그치지 않고 프로젝트 관리와 품질 보증 테스트를 비롯한 전체 소프트웨어 개발 프로세스의 기타 많은 측면에도 유사한 양적 측정 기법을 적용해야 한다. 그렇더라도 PL/SQL 코드의 올바른 정량분석을 이루는 것이 해당 분야에서 가장 첫 번째 단계임에는 틀림없다. 여기에서는 우수한 것만이 도출된다.

아마도 완벽한 프로그램이란 존재하지 않을 것이다. 또한, 도달하기 어려운 목표를 이루기 위해 지나치게 많은 리소스를 허비해서는 안 된다. 하지만 이는 가능한 시점이나 가능한 상황에서 우수한 코드를 작성하려는 노력을 중단할 것을 의미하지는 않는다.

특히 이와 같은 상황에서 개발자를 돕는 입증된 기법과 툴이 모두 있을 때는 더욱 그렇다. 고급 프로젝트 관리나 올바른 소프트웨어 엔지니어링과 관련된 관행을 손쉽게 수용해 이용할 수 있다면 PL/SQL 프로그램을 훨씬 쉽게 판독 및 유지보수하며, 보다 효율적이고 정확하게 만들 수 있다. 더불어 이런 노력을 돕는 Toad 등의 개발 툴을 이용한다면 더욱 빠르고 쉽게 우수한 코드를 작성할 수 있고, 지속적으로 시간과 비용을 절약해 고객과 관리자, 프로그래머 모두가 만족할 수 있는 결과를 얻게 될 것이다.