SQL을 모르는 현업 담당자도 필요한 데이터를 찾고 활용할 수 있도록

현장 FDE로서 고객 요구사항을 기술적으로 직접 책임지는 창구였습니다. 고객 피드백으로 요청된 개발 대부분을 직접 수행했고, 검색 결과 화면 개선, 데이터 거버넌스 기능, Query Builder의 세부 기능을 직접 담당했습니다.

“임직원이 SQL을 사용할 수 없습니다. 데이터에 접근하고 활용할 수 있도록 해주세요.”

고객, 프로젝트 착수 시점

이 요청은 SQL 문법이 핵심 장애물이라는 가정에서 출발했습니다. 하지만 쿼리를 작성하려면 먼저 어떤 데이터가 존재하고, 어떻게 구성되어 있으며, 무엇을 확인해야 하는지 알아야 합니다.

실제 문제는 쿼리를 작성하는 단계보다 앞에 있었습니다. 현업 담당자에게는 데이터를 조회하기 전에 필요한 데이터를 찾고 이해할 수 있는 방법이 필요했습니다.

첫 번째 버전은 200명 대상 베타테스트까지 배포됐습니다. 그리고 검색 결과 화면이 충분한 맥락을 전달하지 못한다는 직접적인 피드백을 받았습니다.

“데이터를 많이 제공하려는 것은 알겠지만, 어떤 정보가 있고 무엇을 보여주려는지 모르겠다.”

베타 사용자 피드백 요약

화면은 데이터를 반환했지만, 사용자는 자신이 무엇을 보고 있는지, 그 데이터가 전체 구조에서 어디에 속하는지 이해하기 어려웠습니다. 표면적인 화면 수정에 그치지 않고 원인을 파악하기 위해 다른 데이터 검색 서비스들을 직접 사용하고 비교했습니다. 그 과정에서 계층 구조와 필터, 결과 맥락이 사용자의 해석 부담을 어떻게 줄이는지 확인했고, 이를 바탕으로 개선 방향을 정의한 뒤 탐색 경험을 다시 설계했습니다.

• 결과 중심 화면에서 단계적인 탐색 방식으로 전환
• 평면적인 검색 결과를 계층 구조와 필터 중심으로 변경
• 사용자가 데이터 카탈로그를 알고 있다고 가정하지 않고, 각 결과의 위치와 맥락을 함께 제공

새로운 환경에서 처음부터 만드는 작업이 아니었습니다. 기존 엔터프라이즈 시스템과 협업 구조 안에서 작동해야 했습니다.

• Databricks 데이터 플랫폼이 이미 구축되어 있었고 파트너사가 운영하고 있었습니다.
• 포털이 기존 데이터 거버넌스와 접근 권한을 우회해서는 안 됐습니다.
• 주요 사용자는 분석가나 개발자가 아닌 현업 담당자였습니다.
• 여러 회사가 각기 다른 시스템 계층을 담당했기 때문에 기술과 업무의 책임 범위를 명확히 해야 했습니다.
• 베타테스트 2주 전에 투입되어, 기존 코드와 고객 상황을 빠르게 이해하면서 즉시 납기까지 맞춰야 했습니다.
• 첫 번째 버전은 200명을 지원하면서 향후 전사 확대와도 호환되어야 했습니다.

저희 팀은 포털 계층과 Power BI 제공을 담당했고, Databricks 플랫폼을 대체하지는 않았습니다. 저는 포털의 기술 방향과 직접 구현을 책임지면서, 보고서 업무에서는 고객사와 모델러를 연결하고 전체 진행을 총괄했습니다. 이 경계가 제품의 초점과 참여자별 책임을 명확하게 유지했습니다.

Query Builder는 쿼리 생성과 실행, 결과 확인, Excel 내보내기까지 전체 흐름을 지원합니다. 남은 핵심 과제는 실행이 아니라 쿼리 검증 계층입니다. 거버넌스 기능은 Databricks의 데이터 품질과 오염 정도를 측정해 관리자에게 보여주고, 포털에서 표준화 상태를 검토·수정할 수 있게 합니다.

최초 요청은 업무 문제의 원인보다 가장 눈에 잘 보이는 장애물을 설명하는 경우가 많습니다. 이 프로젝트에서는 SQL이 눈에 보였지만, 데이터 탐색이 먼저였습니다.

다시 진행한다면 첫 주에 최소 기능으로 만든 검색 결과 화면을 현업 담당자 5명에게 먼저 보여줄 것입니다. 넓은 배포에 투자하기 전에 사용자가 정보 구조를 이해하는지 검증할 수 있습니다. 또한 쿼리 생성과 검증 계층을 처음부터 함께 설계할 것입니다.