저는 Oracle EBS 관련 업무에 18년 이상 종사해왔으며, 11i부터 R12까지의 완전한 진화 과정을 경험했습니다. 이 긴 경력 동안 맞춤형 보고서 개발은 항상 피할 수 없는 핵심 업무였습니다. 그리고 이 업무를 둘러싸고 해마다 동일한 문제들이 반복적으로 발생했으며, 근본적인 개선은 이루어지지 않았습니다.
저는 Oracle EBS 관련 업무에 18년 이상 종사해왔으며, 11i부터 R12까지의 완전한 진화 과정을 경험했습니다. 이 긴 경력 동안 맞춤형 보고서 개발은 항상 피할 수 없는 핵심 업무였습니다. 그리고 이 업무를 둘러싸고 해마다 동일한 문제들이 반복적으로 발생했으며, 근본적인 개선은 이루어지지 않았습니다.
이 글은 이야기를 전달하려는 것이 아닙니다. 단지 제가 수년간 관찰하고 경험한 문제들과, 그 문제들을 바탕으로 시도한 것들을 솔직하게 기록하려는 것입니다. 동일한 고민을 겪고 있는 동료들에게 작은 참고라도 되길 바랍니다.
EBS 체계에서 맞춤형 보고서는 SQL 작성이 완료된 후 사용자가 실행할 수 있기까지 고정된 절차를 거쳐야 합니다. 이 프로세스는 EBS 설계 프레임워크 내에서 합리적이고 필수적입니다——보안, 다중 조직 격리, 매개변수 검증, 요청 스케줄링을 보장하기 때문입니다. 하지만 개발 효율성 측면에서 볼 때 그 비용은 분명히 높은 편입니다.
구체적으로, 개발자가 SQL 작성과 테스트를 완료한 후에도 다음 작업을 순차적으로 수행해야 합니다:
이러한 단계들은 복잡한 비즈니스 로직을 포함하지 않으며 순수한 구성 작업일 뿐입니다. 그러나 단순하고 일회성일 가능성이 높은 임시 보고서의 경우 이 프로세스의 시작 비용은 지나치게 높습니다. SQL 작성에 20분밖에 걸리지 않는 보고서도 전체 프로세스를 완료하는 데 1시간 이상 소요되는 경우가 많으며, 대부분의 시간은 메뉴 탐색, 필드 입력, 페이지 응답 대기에 소비됩니다.
더 중요한 것은, 테스트 후 SQL 로직이나 매개변수 정의를 조정해야 할 경우 위 단계의 상당 부분을 반복해야 한다는 점입니다. 이는 빠른 반복이 필요한 개발 시나리오에서 분명한 효율성 병목 현상입니다.
이것이 제가 가장 핵심적이며 사용자 경험에 가장 큰 영향을 미치는 문제라고 생각하는 부분입니다.
EBS 동시 프로그램의 기본 출력 형식은 텍스트 파일(일반적으로 .out 또는 .txt)입니다. Report Builder로 개발된 .rdf 보고서든 PL/SQL 저장 프로시저의 출력이든, 최종적으로 사용자에게 전달되는 것은 본질적으로 고정 너비 또는 구분자로 분리된 텍스트입니다.
그러나 업무 사용자가 실제 업무에서 필요로 하는 것은 거의 예외 없이 Excel 형식의 데이터 파일입니다. 이로 인해 오랫동안 존재해온 "중간 단계"가 발생합니다: 사용자는 텍스트 파일의 내용을 복사하여 Excel에 붙여넣은 후 "텍스트 나누기" 기능을 사용하여 여러 열로 분할해야 합니다.
이 단계에는 몇 가지 구체적인 기술적 문제가 있습니다:
첫째, 필드 너비 문제입니다. 보고서 개발자는 각 출력 필드에 대해 표시 너비를 사전에 지정해야 합니다. 특정 필드의 실제 데이터 길이가 이 사전 설정 너비를 초과하는 경우(예: 품목 설명, 공급업체 이름 등 자유 텍스트 필드), EBS는 자동 줄 바꿈을 처리하여 텍스트 파일에 줄 바꿈 문자를 삽입합니다. 이 줄 바꿈 문자는 텍스트 뷰어에서 정상적으로 보입니다——내용이 줄바꿈되어 표시됩니다. 그러나 사용자가 전체 텍스트를 복사하여 Excel에서 텍스트 나누기를 수행하면 Excel은 이 줄 바꿈 문자를 행 종결자로 인식하여 하나의 레코드가 잘못되어 두 줄 이상으로 분할됩니다. 이후 모든 레코드의 열 정렬이 완전히 깨집니다. 사용자는 이러한 오류를 수동으로 찾아서 수정하거나, 보고서 필드 너비를 다시 조정한 후 요청을 다시 제출해야 합니다.
둘째, 문자 인코딩 문제입니다. 텍스트 파일의 기본 인코딩 형식과 Excel의 기본 열기 인코딩이 일치하지 않는 경우가 많습니다. 특히 중국어, 일본어 등 멀티바이트 문자를 처리할 때 문자가 깨지는 현상이 자주 발생합니다. 사용자는 텍스트 파일을 열 때 올바른 인코딩을 수동으로 선택하거나, Excel 가져오기 시 인코딩 형식을 지정해야 합니다. 이는 기술적 배경이 없는 업무 사용자에게 추가적이고 불필요한 부담입니다.
셋째, 숫자 형식과 날짜 형식 처리입니다. 텍스트 파일로 내보낸 숫자와 날짜는 일반적으로 일반 텍스트 형식이며, 사용자는 Excel에 붙여넣은 후 수동으로 셀 형식을 설정해야 합계, 평균 등의 계산 작업을 수행할 수 있습니다. 천 단위 구분 기호, 소수점 정밀도, 날짜 표시 형식이 관련된 경우 추가 수동 조정 단계가 필요합니다.
넷째, 대량 데이터 처리 효율성입니다. 보고서가 반환하는 데이터 양이 많은 경우(예: 1만 행 초과), 복사-붙여넣기 및 수동 열 분할 작업 자체가 매우 시간이 많이 걸리며, Excel은 대량 텍스트 붙여넣기 처리 시 성능이 항상 안정적이지 않아 지연이나 응답 없음이 자주 발생합니다.
이러한 문제는 EBS 표준 보고서와 맞춤형 보고서 모두에서 널리 존재합니다. 엄밀히 말해 이것은 "버그"가 아니라 EBS가 탄생한 시대의 설계 선택입니다——그 시대에는 텍스트 출력이 크로스플랫폼 데이터 교환의 주류 방식이었습니다. 그러나 오늘날의 비즈니스 환경에 적용하면 이 설계 선택은 사용자의 실제 사용 시나리오와 심각하게 단절되어 있습니다.
업무 부서는 실제 운영에서 비주기적인 데이터 분석 수요를 자주 발생시킵니다. 예를 들어:
이러한 수요의 특징은: SQL 로직이 비교적 명확하고, 데이터 범위가 제한적이며, 시의성 요구사항이 높고, 한 번만 사용되고 반복되지 않을 가능성이 높다는 점입니다.
EBS의 표준 개발 경로에서는 일회성 임시 보고서라도 실행 파일 정의부터 요청 그룹 마운트까지 전체 등록 프로세스를 완료해야 합니다. 이는 개발자가 이러한 임시 수요에 대응할 때마다 비즈니스 로직과 무관한 구성 작업을 반복해야 함을 의미합니다.
또 다른 일반적인 우회 방법은 개발자가 데이터베이스 도구(예: PL/SQL Developer 또는 Toad)에서 SQL을 직접 실행하고 결과를 복사하여 Excel로 사용자에게 보내는 방식입니다. 이 방법은 EBS의 등록 프로세스를 우회하여 훨씬 빠르지만, EBS의 다중 조직 접근 제어 및 데이터 권한 검증을 우회하므로 잠재적인 데이터 보안 위험이 존재하며, 동시 관리자를 통한 통합 스케줄링 및 로그 관리도 불가능합니다.
위 문제들은 오늘 갑자기 나타난 것이 아닙니다. 실제로 EBS 사용자 커뮤니티와 실무자들 사이에서 이러한 고충은 오랫동안 공공연한 비밀이었습니다. 그러나 수년간 업계의 해결책은 주로 다음과 같은 측면에 집중되었으며, 효과는 제한적이었습니다:
이러한 방식들은 EBS 보고서 개발 모델을 근본적으로 변경하지 못했습니다. 개발자는 여전히 SQL 작성과 시스템 구성 두 가지 수준에서 노력을 투입해야 하며, 사용자는 여전히 데이터 획득과 데이터 정제 두 단계에서 추가 시간을 지출해야 합니다.
위 문제들을 바탕으로 SQLVantage라는 독립적인 보고서 도구 레이어를 구축하기로 시도했습니다. 이것은 EBS의 동시 관리자를 대체하기 위한 것이 아니라, 다음과 같은 시나리오를 포괄하는 보완적 빠른 대응 레이어로 위치시켰습니다:
이 도구의 핵심 설계 사상은: EBS 보고서 개발에서 가장 시간이 많이 소요되지만 비즈니스 로직과 무관한 프로세스 작업을 분리하여, 개발자가 SQL과 매개변수 구성이라는 두 가지 핵심 요소에 직접 집중할 수 있도록 하는 것입니다.
구체적인 접근 방식은 다음과 같습니다:
개발 측면에서, 개발자는 도구에 보고서 이름을 입력하고 SQL 문을 작성하며 쿼리 매개변수(매개변수명, 데이터 유형, 표시 레이블, 기본값)를 정의하기만 하면, 저장 후 보고서가 즉시 사용 가능한 상태가 됩니다. 실행 파일 정의, 동시 프로그램 등록, 값 집합 구성, 요청 그룹 마운트가 전혀 필요하지 않습니다. 전체 구성 프로세스는 3~5분 이내에 완료됩니다.
데이터 보안 측면에서, 도구는 EBS의 사용자 인증 메커니즘을 재사용하여 적절한 EBS 책임을 가진 사용자만 보고서에 접근하고 실행할 수 있도록 보장합니다. SQL 쿼리에 포함된 다중 조직 접근 제어(MOAC) 로직은 SQL 문 자체에 남아 있으며, 개발자가 실제 비즈니스 요구사항에 따라 제어합니다.
출력 형식 측면에서, 도구는 .xlsx 형식의 Excel 파일을 직접 생성합니다. 각 쿼리 결과 필드는 Excel의 한 열에 해당하며, 각 데이터 행은 Excel의 한 행에 해당합니다. 필드 너비는 내용에 자동으로 적응하며, 긴 텍스트 내용이 데이터를 손상시키는 줄 바꿈을 유발하지 않습니다. 숫자, 날짜 등의 데이터 유형은 내보내기 시 원래 데이터 유형 속성을 유지하므로, 사용자는 Excel을 연 후 바로 정렬, 필터링, 계산 작업을 수행할 수 있습니다.
확장성 측면에서, Excel 외에도 도구는 JSON 형식의 출력을 지원하여 외부 데이터 플랫폼이나 BI 시스템과의 연동이 용이합니다.
일정 기간 내부 사용 후, 이 도구는 다음과 같은 측면에서 확실히 효율성 향상을 가져왔습니다:
동시에 이 도구의 한계도 지적할 필요가 있습니다:
18년 동안 EBS는 엔터프라이즈급 애플리케이션 플랫폼으로서 핵심 아키텍처의 안정성과 엄격함이 의심할 여지가 없습니다. 그러나 바로 이러한 안정성 때문에, 당시에는 합리적이었던 일부 설계 선택이 오늘날의 사용 시나리오에서는 지체되고 무거워 보입니다.
보고서 개발의 프로세스 비용, 텍스트 형식의 출력 방식, 임시 수요의 대응 경로——이러한 문제들은 오늘 갑자기 나타난 것이 아닙니다. 다만 오늘날의 환경에서는 그 대가가 더욱 뚜렷해졌을 뿐입니다. 비즈니스 리듬은 빨라지고, 기업의 데이터 응답 요구사항은 높아지고 있으며, 우리가 사용하는 도구와 프로세스는 여전히 이전 시대에 머물러 있습니다.
SQLVantage는 제가 이러한 문제들에 기반하여 시도한 것이며, 혁신이라기보다는 기존 프로세스의 단순화 및 재구성에 가깝습니다. 이 글이 동료들의 공감을 얻거나, 유사한 문제를 고민하는 사람들에게 참고 관점을 제공할 수 있다면 그 목적은 달성된 것입니다.
여기까지 쓰면서, 저는 이것을 "성공 이야기"로 포장하려는 의도가 없음을 밝힙니다. 이는 단지 구체적인 업무 현장에서 구체적인 문제에 반복적으로 시달려온 한 사람이, 자신만의 방식으로 그 문제들을 개선하려고 시도한 것일 뿐입니다. 이 길이 얼마나 갈 수 있을지는 실천을 통해 계속 검증해야 합니다. 하지만 적어도 방향은 옳습니다——개발자를 SQL 자체로 돌려보내고, 사용자를 데이터 자체로 돌려보내며, 그 사이의 불필요한 것들은 도구가 처리하도록 하는 것입니다.