UI TERM 자동 매칭툴, 그 쉽지 않았던 개발 에피소드 2

최근 미국 야구 독립리그에서 기계장치를 이용하여 스트라이크 판정을 하는 시스템을 도입했다고 한다. 메이저리그 사무국도 이 리그에서 사용되는 모습을 참고하여 빠르면 2022년 시즌부터 도입가능성을 얘기하고 있다고 한다. 야구경기에서 끊임없이 나오는 스트라이크 판정 문제로 생긴 심판과 선수들간의 오래된 앙금이 이 시스템의 도입으로 해결될 수 있을지 귀추가 주목된다.


위의 소식 같은 내용을 접하면 흔히 개발자들은 이런 걸 만들려면 어떤 로직이 필요하고 어떤 시스템이 접목되어야 할지에 대해 자못 심각(?)하게 얘기를 나누곤 한다.

카메라는 몇 대가 필요할지, 선수들의 신장차이는 어떻게 판별해야 할지, 스트라이크 존의 좌표 문제로 고등학교 시절 수학시간 얘기까지 나오고 나서야 이내 제풀에 꺾이고 말지만 말이다.

이런 남의 나라 이야기들 같은 문제는 그냥 웃어넘기면 되지만 실제 우리가 일하고 있는 현장에서는 그것이 쉽게 용납되지 않는다.

필요에 의해서 만들어진 프로그램은 그 자체만으로는 존재할 수 없고 수 없이 많은 주변환경의 변수와 끊임없이 대화하고 맞춰나가지 않으면 사장되어 버리거나 중대한 오류를 범할 수 있다.

아래의 이야기는 그런 연장 선상에서 한샘EUG가 개발한 UI TERM 자동 매칭툴 Weaver가 현장에서 본격 운용되기까지 거쳐야만 했던 과도기 때의 이야기이다.


“우리가 정하는 숫자를 믿고 일선의 누군가는 거기에 목숨을 건다”
-드라마 “미생”에서-


UI TERM 자동 매칭툴(이하 Weaver)이 본격적으로 개발이 시작되어 현장 피드백이 오고 가던 시점에서 문제의 발단은 이랬다.

고객에게서 받은 UI TERM Table의 내용 중에서 소문자와 대문자가 구별되어야 하는 부분이 있는데 실제로 이 부분이 제대로 지켜지지 않은 채 우리 작업파트 쪽으로 넘어오게 된 것이다.

이를 사람이 일일이 보고 고치려면 5개 언어를 1사람이 대략 8시간이 걸려 수정해야 한다는 예측이 나왔고 우리는 이를 하루속히 해결할 수 있는 프로그램을 개발해야만 했다.

이는 지난번 개발에피소드에서 언급한 것 같이 “’UI TERM 테이블’은 과연 얼마나 신용할 수 있는 데이터인가 하는 문제에서부터 그렇다면 어떤 공정을 통해서 만들어져야만 하는 것인가 등에 대한 이야기”와 일맥 상통한다.


개발 프로그램의 주요기능은 다음과 같다.

1. 엑셀의 모든 시트를 대상으로 한다.
2. 언더바(_) 전체 삭제
3. 첫 단어의 첫 글자 대문자 적용, 이 후 단어의 첫 단어 첫 글자 소문자 적용

intercom entre ocho personas Intercom entre ocho personas
Encender_Compartir_Música Encender compartir música

4. 독일어는 3번의 조건 제외

Unterstützung Navigations-App 수정안함
Audio Boost 수정안함

5. 대문자로 표기된 문장중의 UI TERM은 대문자 유지

Configuración RDS AF Impostazione RDS AF
FM activado FM acceso

이처럼 다양한 조건들을 하나씩 해결한 결과 우리는 또 하나의 작은 프로그램을 완성시켰고, 대문자 소문자를 판별하는 주요기능을 가졌다 하여 “UMPIRE CAPS”라고 이름 지었다.

서두에 언급한 스트라이크 판정 시스템을 만드는 사람들도 실제로는 엄청난 중압감에 시달릴 수 있으리라는 생각이 든다.

결국 자기들이 만든 시스템을 믿고 전미의 야구시합들이 좌지우지 될 수 있으니 말이다.

비록 거기까지는 아니지만 개발자들이 만든 프로그램을 믿고 현장에서 일을 진행시키며 고객과 소통하고 있는 것을 잘 알고 있기에 우리는 프로그램을 하나를 만들 때도 되도록이면 신중하게 접근하려고 노력한다.

프로그래밍 해 놓은 버튼 하나가 누군가의 앞에서 장시간의 고된 노동과 바꿀 수 있을 만큼의 신뢰가 만들어질 때까지 끊임없이 주변환경과 소통하고 해결방법을 모색해야 한다.

그러다 보면 어느새 주변에서 스트라이크로 판정된 프로그램이 우리를 퍼펙트 게임으로 인도할 수 있으리라 기대해 본다.