기성 모듈을 붙이기 전에 물어볼 것들

무인 환전 키오스크를 만들었습니다. 지폐 입금기, 출금기, 카드 투출기, 동전 지급기, 제어보드, CCTV가 한 몸에 들어가고, 아무도 쓰지 않는 동안에는 광고가 돌아갑니다. 이 장치들은 전부 기성 제품입니다. 직접 만들 이유가 없고, 만들 수도 없습니다.

기성 모듈을 쓰면 빨리 갑니다. 다만 대가가 있습니다. 그 모듈 공급사의 사정이 곧 내 일정이 됩니다. 이 프로젝트에서 그것을 세 가지 모양으로 겪었습니다.

첫째, 비트 수.

프로그램은 처음에 C# .NET x86, 그러니까 32비트로 만들었습니다. 일반 키오스크였다면 문제가 없었을 것입니다. 그런데 붙는 장치가 많고 광고 재생까지 돌다 보니 32비트의 메모리 한계에 걸렸습니다.

64비트로 옮기려면 조건이 하나 있습니다. 붙어 있는 모든 장치의 64비트 라이브러리가 있어야 합니다. 하나라도 없으면 그 장치 때문에 전체가 32비트에 묶입니다. 실제로 주는 곳도 있었고 없는 곳도 있었습니다.

없는 것은 공급사가 낸 Java 샘플을 뜯어 RS232 통신을 직접 구현했습니다. 몇 가지는 그렇게 넘겼지만 끝내 풀리지 않는 것이 남았습니다. 결국 공급사에 다시 요청해 64비트 라이브러리를 받고서야 풀렸습니다.

둘째, 버전.

원인을 알 수 없는 오작동이 이어진 적이 있습니다. 코드를 몇 번이나 다시 봤습니다. 알고 보니 받아 둔 라이브러리가 구버전이었습니다. 최신으로 바꾸자 그대로 정상이 되었습니다.

이런 종류의 문제는 찾기가 유난히 어렵습니다. 내 코드는 어제와 똑같은데 기계만 이상하게 구니, 자연히 내 쪽만 들여다보게 됩니다. 원인 모를 오작동을 만나면 내 코드보다 받은 것의 버전을 먼저 보는 편이 빠를 때가 있습니다.

셋째, 받는 시점.

라이브러리는 공급사에서 받아야 합니다. 언제 어떤 형태로 받느냐가 이쪽 일정과 구조를 정합니다. 이건 개발로 줄일 수 있는 시간이 아닙니다.

그래서 부품을 고를 때 함께 물어보시길 권합니다. 값과 성능만 보고 정하면 나중에 이 항목들이 일정으로 돌아옵니다.

어떤 언어와 환경의 라이브러리를 주는가. 샘플만 주고 라이브러리는 없는 경우도 있습니다.

64비트를 지원하는가. 지금 32비트로 충분해 보여도, 붙일 것이 늘면 한계는 옵니다.

최신 버전은 무엇이고 어떻게 받는가. 받아 둔 것이 언제 것인지 알 수 있어야 합니다.

통신 규격 문서를 주는가. 라이브러리가 막히면 결국 이것으로 직접 구현하게 됩니다.

네 가지 다 메일 한 통이면 물어볼 수 있습니다.