유지보수를 어렵게 만드는 건

Development Language+

오늘날의 소프트웨어 엔지니어는 다양한 개발 언어를 다룰 줄 알아야함에도 그런 역량을 가진 인력은 많이 찾아볼 수 없다. 심지어 나 조차도 그러한 개발자가 되어버릴 수 밖에 없는 환경에 오랫동안 있었던 것 같다. 현재 회사에서 자바로 작성된 클라이언트 애플리케이션이 무겁다며 Go 언어를 사용해서 다시 작성하고자 한다는데 개인적으로는 동의하지 않는다. 해당 발언을 한 CTO 조차 Go 언어에 대한 경험이 없는 상태로 AI 의 도움을 받아서 진행하려는 생각으로 보인다. 갑작스러운 이 선택 과연 옳은 결정일까?

Ops Infrastructure

운영 규모가 작은 조직에서는 인프라 변경도 유지보수를 어렵게 만들 수 있는 계기가 되는 것 같다. 현재 회사는 AWS Elastic Beanstalk 을 활용하다가 비용적인 문제로 AWS Elastic Container Serivce 를 사용하는 것으로 변경했다. 하지만, DevOps 엔지니어가 없는 조직 입장에서는 ECS (또는 EKS)에 대한 역량이 있는 개발자가 없었던 것은 유지보수를 어렵게 만들게 된 원인 중 하나이지 않을까 생각된다. ECS 에 대한 운영 경험이 있는 것이 아니기 때문에 인프라 설정 관련해서 운영 이슈가 발생할 수 있다는 것도 큰 문제이다.

Commercial Skills

일반적으로 선택되는 기술이 아닌 상용 기술은 사용중인 회사 또는 공개적으로 공유된 레퍼런스가 부족하여 참고하기 어렵다. 현재 회사에서 개발중인 시스템은 KX에서 개발한 KDB 라는 시계열 데이터베이스에 대한 의존성이 강하다. 조직에서 선택한 기술이 아무리 좋다고 해도 이를 다룰 수 있는 소프트웨어 엔지니어가 부족하고 그 기술을 배우고자 하는 인력이 없다는 것도 큰 문제라고 볼 수 있다. 시계열 데이터베이스로 유명한 InfluxDB 대신에 사용하고 있는 건데 개인적인 관점에서는 TimesaleDB 또는 QuestDB 로도 충분한 규모의 환경이라고 생각한다.

Documents

소프트웨어 엔지니어로써 유지보수에 대한 작업을 진행하고자 할 때 가장 큰 걸림돌은 바로 문서화에 대한 부재 또는 부족함이다. 개인적으로는 최대한 히스토리를 남도록 작업하는 편이지만 조직에서 개발해왔던 인력들은 요구사항에 대한 결정없이 일단 진행해서 반영한다거나 이슈 또는 변경 사항에 대한 숨겨진 히스토리를 어디에도 남기지 않는 편이다. 이러한 요구사항 명세와 변경사항에 대한 히스토리가 없는 부분으로 인해 통합 테스트를 수행하는 QA 엔지니어 뿐만 아니라 개발했던 인력조차 버그인지 스펙인지 알기 어렵다.

---

시스템 오류는 과거에 제대로 결정하지 못하거나 일단 무시하고 진행했던 부분들로 인해 발생한다. 우리는 늘 해당 요구사항에 대해 다시 고민할 것이라 생각하지만 그렇게 진행되었던 적이 없다. 결국, 유지보수를 어렵게 만드는 건 조직의 업무 방식이며 인재라고 볼 수 있다.