아세아제지 스마트 생태공장 모니터링 프로젝트 회고
아세아제지 스마트생태공장 모니터링 프로젝트는 태양광 (인버터), LED (전력량계), 스크러버 (복합악취), 보일러 (열량계) 데이터를 수집해 저장하고 대시보드로 표출하는 프로젝트입니다.
버스 팩터
초기에 제가 담당하던 역할은 일종의 미들웨어에 가까웠습니다. 각 설비와 시스템에서 발생하는 데이터를 수집하고, 이를 상위 시스템으로 전달하는 역할이었습니다.
그런데 프로젝트 진행 중 상위 시스템의 개발자가 퇴사하면서 상황이 달라졌습니다. 추가로 수집 서버와 모니터링 UI 까지 맡게 되었고 시간이 얼마 남지 않은터라 조금 급하게 개발을 하였습니다.
기술 선택
이번 프로젝트는 고객의 특별히 요구하는 기술 스택이나 제약사항이 없었습니다. 덕분에 제가 좋아하는 Kotlin 을 사용해 작업을 할 수 있었습니다.
설비 통신은 Modbus TCP 로 통일!
설비 업체들과의 통신 방식은 가능한 한 Modbus TCP로 통일했습니다. 가장 큰 이유는 유지보수의 편의성이었습니다.
프로젝트에는 여러 대의 PLC가 사용되었고 각 PLC마다 서로 다른 통신 프로토콜을 사용한다면 개발뿐만 아니라 이후 테스트와 장애 대응에서도 복잡도가 높아질 것이라 생각했습니다. 반면 Modbus TCP를 사용하면 통신 방식과 데이터 접근 방법을 어느 정도 일관되게 가져갈 수 있었습니다.
물론 설비마다 필요한 데이터의 양도 고려했습니다. 이번 프로젝트에서는 PLC에서 읽어야 할 메모리 영역이 크지 않았기 때문에 대량의 데이터를 한 번에 읽을 수 있는 제조사 전용 프로토콜까지 사용할 필요는 없다고 판단했습니다.
이번 프로젝트의 데이터 규모와 유지보수성을 고려했을 때 Modbus TCP만으로도 충분하다고 판단했고 가능한 설비들은 하나의 통신 방식으로 통일했습니다.
JPA
이번 프로젝트에선 JPA (Java Persistence API) 를 도입해봤습니다.
사실 저는 평소 Native Query를 선호합니다. JPA가 과도한 추상화라고 생각했기 때문입니다.
물론 JPA가 제공하는 장점은 엄청납니다. 반복적인 쿼리 작성을 줄여주고 엔티티의 필드가 변경되었을 때 관련된 조회 쿼리를 일일이 찾아 수정해야 하는 부담도 줄어듭니다. 그리고 데이터베이스를 객체를 중심으로 바라볼 수 있다는 점도 장점이라고 생각합니다.
하지만 그렇다고 해서 JPA를 사용하면 복잡함이 마법처럼 사라지는 것은 아닙니다. 오히려 내부적으로 어떤 SQL이 실행되는지, 영속성 컨텍스트가 어떻게 동작하는지, 지연 로딩이나 N+1 문제는 무엇인지 등을 이해해야 제대로 사용할 수 있습니다. 추상화의 내부가 완전히 숨겨지지 않는 Leaky Abstraction의 대표적인 사례기도 합니다.
특히 제가 기존에 주로 경험했던 물류자동화 시스템에서는 장애가 곧 공장의 정지로 이어질 수 있습니다. 프로그램에 발생한 작은 문제가 실제 현장의 정지로 이어지고 그 몇 분이 큰 손실로 이어질 수도 있습니다. 그런 환경에서 충분히 이해하지 못한 기술을 단순히 유행한다는 이유로 도입하고 싶지는 않았습니다.
다행히 이번 프로젝트는 설비에서 데이터를 수집하고 대시보드에 표출하는 것이 주된 목적이었습니다. 시스템에 문제가 발생하더라도 공장 운영 자체를 중단시키는 성격은 아니었기 때문에 새로운 기술을 실전에서 경험해보기에 상대적으로 적합한 프로젝트라고 판단했습니다.
그래서 이번에는 이론으로만 알고 있던 JPA를 직접 사용해보기로 했습니다. 프로젝트를 장난감처럼 생각해서 내린 결정은 아닙니다. 프로젝트의 기간과 난이도, 장애 영향 범위를 고려했을 때 충분히 감당할 수 있는 수준이라고 판단했기 때문에 내린 선택이었습니다.
마치며
이번 프로젝트는 규모가 크거나 기술적으로 복잡한 프로젝트는 아니었습니다. 하지만 개인적으로는 도입해보고싶은 기술을 실무에 시도해볼 수 있는 의미있는 프로젝트였습니다.
특히 기존에는 안정성을 이유로 새로운 기술을 도입하는 것에 조심스러운 편이었습니다. 물류자동화 현장에서 작은 장애가 실제 공장 운영에 영향을 줄 수 있기 때문입니다.
개인적으론 좋은 기술과 나쁜 기술이 있다고 생각하지 않습니다. 현재의 상황에 따라 어올리는 기술이 있다고 생각합니다.