외산 DBMS에서 수행되는 모든 SQL은 티베로에서 수행 실패(Sql Execution Fail)가 없어야 한다(실패율 0%). 만약 수행되지 않는 SQL이 존재한다면 적어도 티베로가 운영을 시작하기 전까지는 모두 수행되도록 조치되어야 하며 이를 위해서는 먼저 어떠한 SQL에 어떤 문제가 있는지 파악해야 한다.

그리고 어플리케이션의 위험성을 최소화하기 위해 대부분의 문제들은 티베로 엔진 패치를 통해 SQL이 정상 작동되어야 하며 어쩔 수 없는 경우에 대해서만 SQL을 수정하는 것이 프로젝트 시작전 소속 회사가 제시한 요건이며 전환을 고려하는 다른 회사들도 동일한 요건을 제시할 것이라고 생각된다.

그리고 본 요건을 만족하기 위해서는 외산 DBMS에 대한 티베로의 호환성이 최소한 99% 이상이어야 엔진 혹은, SQL을 수정하며 프로젝트 기간 안에 100% 호환성을 달성할 수 있을 것이다. 따라서 외산 DBMS에서 수집한 SQL을 리플레이를 통해 티베로에 최초 수행했을 때 실패율이 과연 몇 %일 것이냐에 많은 걱정과 기대를 했었는데 다행히도 상당히 양호한 0.3%의 실패율(99.7%의호환율)을 기록하는 것으로 분석되었다(2015년 2차 POC를 통해 밝혀낸 6개의 실패 패턴(당시 실패율 2.1%)이 모두 처리된 이후 프로젝트가 시작되었기 때문에 더욱 양호한 호환성을 보인 것으로 생각된다).

0.3%의 수치는 약 3백만 번의 SQL 수행 중 9,000번에 해당하는 것이며 이는 다음 소개하는 7개의 실패 패턴이 반복 수행된 것^주1)으로 최종 분석되었다. 그리고 7개의패턴을 보유한 SQL의 개수는 정확하게 파악하지는 못했지만 선임 개발자가 작성한 유사 패턴의 SQL을 그대로 사용하게 되는 개발 특성상 상당한 양의 SQL들이 동일한 방식으로 작성 및 사용되고 있었던 것으로 생각된다.

따라서 엔진의 패치 없이 모두 SQL을 수정해야만 했다면 어플리케이션 변경량이 매우 컸을 것이고 그에 따라 어플리케이션 안정성 또한 큰 위협을 받았을 것이다. 그러나 소속 회사는 엔진 패치가 도저히 불가능하거나 표준에 맞지 않는 2개의 패턴만 SQL을 수정하고 사용빈도가 많은 5개의 패턴은 엔진 패치를 통해 해결하여 짧은 시간 안에 SQL Fail 이슈는 모두 처리할 수 있었다.

|주1| 위 7개의 실패 패턴 이외에도 한두 개의 SQL에만 적용되어 있던 독특한 실패 패턴들이 몇몇 존재했었는데, 이는 매우 독특한 형태이고 반복 사용되지 않아 SQL 수정으로 처리하였으며 타사에는 사용될 가능성이 적다고 판단되어 소개하지 않기로 한다.

• [그림 4-1] 리플레이 수행 시 발생한 SQL Fail 로그 - 참고로 소속 회사에서 적용한 리플레이는 분석 기능이 존재하지 않아 웨어벨리 샤크라 제품을 통해 SQL Fail 및 성능 분석을 진행하였다.
•