11월입니다. 2023년 한 해의 결과를 정리해보는 때이기도 하지요.
작년 이맘때 데이터 처리를 자동화시키기 위한 Library/API를 설계했었습니다. 올해 1월에 Prototype을 만들고 포스팅 한 후 1년 가까이 이런저런 일에 치이다 올해의 결과를 나누어볼까 합니다.
Library를 개발하게된데는 몇 가지 배경이 있었습니다.
- 엔지니어들의 코드스타일이 달라 재사용성이 떨어졌습니다.
- 이로 인해 반복업무의 재작업으로 인한 비효율이 발생했고요.
- 코드에 로그를 남기지 않아 작업 결과와 클라우드 비용을 연계할 수 없었습니다.
처음에 만든 프로토타입은 챗봇형 데이터 자동화 솔루션이었습니다.
이 챗봇은 사용자에게 데이터를 탐색하기 위한 최소조건을 계속해서 물었습니다. 질의를 하는 모듈과 결과를 수행하는 모듈로 나뉘어 만들어졌었는데요, 기존에 반나절 정도 걸리던 작업을 10분 이내에 처리할 수 있을 정도로 작업 속도에 많은 개선을 가져왔습니다.
그런데, 챗봇을 서비스화하기 위해선 몇 가지 결정이 필요했습니다.
- 챗봇 서비스를 위한 별도의 서버를 구축할 것인가?
- Web, UI/UX를 개발할것인가?
- 유지보수 관련된 리소스를 투여할것인가?
팀은 이 프로토타입의 배포에 앞서 다시 한 번 고민했습니다.
"누구를 위한 솔루션인가?"
팀이 받고있던 데이터 요청을 극단적인 두 가지 유형으로 나누어보면 다음과 같습니다.
A : 이미 잘 정리되어있는 데이터를 요청하면서 요청에 필요한 파라미터값을 요청자가 명확히 아는 경우
B : 데이터가 어떻게 생겼는지도 모르고, 요청 받는 엔지니어도 그 데이터가 어디에있는지 잘 모르는 경우
B 케이스는 어차피 자동화할 수 없는 일입니다. 이 일을 어차피 누군가는 고생을 하면서 데이터를 찾아야 하는 일로 정리한다면, 굳이 A 케이스의 유저를 위해 챗봇형 서비스를 오픈할 이유는 없었습니다.
그렇게 데이터 자동화 솔루션은 챗봇을 탑재한 웹서비스가 아닌, API형태로 방향을 틀었습니다.
프로토타입 챗봇의 질의부는 떼어놓고, 수행부를 API로 연계할 수 있는 형태로 정리했습니다. 요청자가 이미 알고있는 파라미터값으로 API를 호출하면 AWS Lambda가 Library를 호출하고, 정해진 시나리오대로 데이터를 처리합니다. 중간에 좀 헤맨 과정이 있었지만, 결국은 프로토타입에서 구현했던 작업속도 개선의 효과를 데이터 요청자가 직접 누릴 수 있는 상황에 도달한셈입니다.
여러번의 재개발을 거치면서 엔지니어들의 코드를 비용과 연계하여 볼 수 있는 방안도 마련했습니다. Outlier query 탐지를 위해 매주 모니터링 툴이 돌며 trouble shooting이 필요한 query를 리포팅합니다. 보통 매주 10 개 정도의 쿼리를 튜닝하고 팀에 작업 가이드를 공유하고있습니다.
데이터 처리를 위한 Cost가 데이터로 남는다는것은 몇 가지 프로세스상의 변화를 가져옵니다. 먼저 요청받은 데이터에 대한 처리 비용이 예상 가능해졌고, 이에 따라 과도한 데이터를 요청하는 부서에 sampling 또는 조건 협의를 끌어내기가 용이해졌습니다. 데이터가 쌓이기 전에는 불가능했던 의사소통방식이었습니다.
데이터 자동화를 위한 앞으로의 여정은 어떻게 될까요?
요청자에게 비용에 대한 예상치를 보여주면서 데이터 처리중 발생하는 Outlier를 관리하기 위한 방안이 추가가 될 것 같습니다. 동시에 API가 대응할 수 있는 데이터 시나리오를 늘려나갈 예정입니다.
상황마다 데이터가 쓰이는 용도와 환경이 다를것이고 데이터를 찾는 이도 다를것입니다. 회사가 DX를 추진하고, 데이터 Life cycle을 구현하는데 있어 정답은 없는것 같습니다. 어떤 유료 솔루션을 도입해서 편하게 해결할 수 있는 일은 아닙니다. 아웃소싱으로도 뾰족한 수가 없는것은 마찬가지고요. 하지만 분명한것은, 진짜 문제를 파헤치기 시작하다보면 해결방안이 보일 것입니다. 보이는 것들을 끊임없이 시도하다보면 어느새 다음 문제를 고민하고 있는 상황을 마주할것입니다.
3
