대부분의 빌딩은 사람들이 쾌적하게 생활할 수 있도록 건물 내부 생활공간의 온습도를 제어해주는 공기조화기가 각 층 또는 지하의 기계실에 위치합니다. 이 공기조화기를 구동시키기 위해서는 인버터가 필요합니다. 여기서 말하는 인버터는 모터를 제어하는 장비를 의미합니다. 기존에는 인버터를 제어하기 위해서는 공기조화기 패널을 통해 간접적으로 제어해야 했기에 시공 단계에서 공기조화기 운용 테스트를 하기가 힘든 상황이 자주 발생했습니다. 테스트 단계에서 인버터를 직접 제어하기 위해 SMAT-mi Ver.1이 등장했습니다. 이 프로그램은 공기조화기 테스트 운용 뿐만 아니라 삼양감속기에서 출시 전 인버터 안정성 검증을 위한 테스트에도 사용됩니다.

개발에 활용한 언어는 C#, 프레임워크는 .NET, UI 제작 도구는 WinForm입니다. 데이터를 게이지 및 차트로 표시하기 위해 유료 UI 도구인 Infragistics, 통신 라이브러리로는 C#과 호환되는 NModbus4를 활용했습니다.

SMAT-mi Ver.1은 첫 회사에 들어가 맡게 된 첫 프로젝트입니다. 당시 뛰어난 PC 프로그램 개발자로 성장하는 것을 목표로 입사하였기에 WinForm은 어느 정도 활용할 수 있었으나 막상 실무에 뛰어들고 보니 생각과는 다른 많은 시행착오와 어려움이 기억이 있습니다.

첫 번째로 어려웠던 점은 멀티 스레드 기반 개발이었습니다. 멀티 스레드 기반 UI 프로그램을 제작하면서 공유 자원 동시 점유 이슈, 레이스 컨디션, Cross Thread 이슈 등 예상치 못한 버그에 직면해 경험이 한참 부족한 신입 개발자로서 매일매일이 고난과 역경이였습니다. 시간이 지남에 따라 UI 스레드와 워커 스레드가 작업을 수행해야 하는 영역은 어디인지, 언제 스레드 풀의 스레드를 사용해야 하고, 백그라운드 워커 스레드는 어떤 부류의 작업 수행에 필요한지 등 스레드를 중심으로 많은 시행착오를 겪으며 어느정도 개발 노하우가 생겨 점점 빠르게 문제점을 파악하며 고쳐 나아갈 수 있었습니다. 이처럼 멀티 스레드 기반 프로그래밍을 지속해서 접하며 논리력 성장에 많은 도움을 받았습니다.

두 번째로 어려웠던 점은 통신 기기 스펙의 불확실성에 있습니다. 모드버스 통신부를 개발해야 하는데 하드웨어 비용의 문제로 Physical Layer의 통신 라인과 DataLink Layer의 Swtiching Hub 종류가 정해지지 않아 네트워크 통신 방식을 시리얼 통신으로 할지, TCP 병렬 통신으로 할지 또한 정할 수 없게 돼 모드버스 통신 클래스를 작성하는데 어려움을 겪었습니다. 물론 모드버스 통신 스펙을 지키며 통신하는 라이브러리가 있어서 통신 관련 세부 구현은 할 필요가 없었지만, TCP와 시리얼 통신 방식은 통신 라인부터 근본적으로 다르기 때문에 직렬 처리 방식으로 구현해야 할지, 동시 처리 방식으로 구현해야 할지 두 범주로 크게 나뉘어 개발에 앞서 어려움을 겪었습니다. 당시 확장에 용이한 설계 능력이 전무했기에 비교적 비용이 저렴한 시리얼 통신 방식으로 진행될 것으로 상정하고 직렬 처리 방식으로 구현했습니다. 한쪽으로만 강한 결합을 갖도록 소스를 구현했기 때문에 추후 요구사항이 바뀌어 병렬 처리 방식으로 구현해야 하는 경우 통신 클래스의 많은 부분을 수정해야 하므로 이 부분에 대해서 반성하고 있습니다. 만약 지금 다시 구현한다면 네트워크 통신이라는 동일한 전략을 취하는 인터페이스를 만들고 이를 상속받아 TCP/IP, 시리얼 통신 클래스를 작성한 후 외부 호출부에서 필요에 따라 전략을 변경하는 방식인 Strategy Pattern을 활용했을 것입니다.

마지막으로 어려웠던 점은 통신에 노이즈가 자주 발생한다는 것입니다. RS-485 라인 특성상 외부 노이즈에 너무나도 쉽게 간섭을 받기 때문에 CRC 체크 부분에서 잦은 통신 에러가 있었습니다. 빌딩 기계실 현장에는 블루투스 통신 트래픽이 많기 때문에 정확한 메시지 송수신을 위해 통신 클래스의 기능을 조금 더 다듬을 필요가 있었습니다. 예를 들어 송신을 보냈을 때 에러가 발생하면 에러가 발생한 메시지를 최대 3회까지 다시 보내고 계속 에러가 발생하면 토스트 메시지로 사용자에게 이를 알리고 에러 발생일시를 기준으로 로깅합니다. 이를 통해 언제 어디서 에러가 발생했는지 알 수 있기에 시리얼 라인이 있는 곳에 노이즈를 일으킬만한 장치가 있다면 간섭 방지 장치를 추가하는 등의 조치를 취할 수 있게 됐습니다.