24시간, 고객 서버 위에서 동작하는 코드를 만드는 일

고객사 IT 인프라부터 네트워크, APM과 TP 모니터링까지. 어떤 환경에서도 안정적으로 동작하는 모니터링 에이전트를 만들어온 개발자를 만났습니다.

12년 차 개발자이지만, 여전히 “배울 게 많다”고 말하는 이유는 무엇일까요. 엑셈에서의 경험이 개발을 바라보는 기준을 어떻게 바꿔놓았는지 이야기를 들어보았습니다.

1. 모니터링의 기반을 만드는 시스템 개발자

Q. 차장님 안녕하세요, 간단한 자기소개 부탁드립니다.

안녕하세요. 통합개발본부 데몬3팀에서 근무하고 있는 개발자 이다솜입니다. 통합 모니터링 솔루션 엑셈원(exemONE)과 애플리케이션 성능 분석 솔루션 인터맥스(InterMax)에서 사용하는 데이터 수집 에이전트를 개발하고 있습니다. 복잡한 운영 환경에서도 고객이 빠르게 장애를 해결할 수 있도록 돕는 것이 제 업무의 핵심이며, 24시간 고객 서버에서 동작하는 만큼 '죽지 않는 에이전트'를 만드는 것을 가장 중요한 원칙으로 생각하고 있습니다.

Q. 데몬3팀이 하는 일이 정말 다양할 것 같은데요. 구체적으로 어떤 영역을 맡고 계신지 궁금합니다.

다양한 성능 데이터를 안정적으로 수집해 실시간 분석이 가능하도록 전달하는 C 기반 에이전트를 개발하고 있습니다. 배포 전에는 장시간 실행 테스트를 통해 성능 오버헤드와 메모리 사용량을 점검하고, 새로운 기능을 추가할 때도 기존 수집 구조와의 하위 호환성을 함께 고려합니다. 인프라 영역에서는 CPU, 메모리, 네트워크, 디스크 등 시스템 자원 데이터를 각 OS 환경에 맞게 수집하는 호스트 에이전트를 담당하고 있고, 네트워크 영역에서는 여러 제조사 장비의 성능 지표를 통합 모니터링하는 NDM 에이전트를 개발하고 있습니다. 또 APM/TP 영역에서는 TMAX, TUXEDO 기반 서비스의 트랜잭션 데이터를 수집해, 고객이 복잡한 애플리케이션 구조에서도 병목 구간을 빠르게 분석할 수 있도록 지원하고 있습니다.

Q. 고객 환경이 다양하다 보니 에이전트가 예상과 다르게 동작했던 사례도 있었을 것 같은데요.

실제로 그런 경험이 많았습니다. Linux만 해도 배포판과 버전이 다양하다 보니, 특정 환경에서는 성능 지표가 수집되지 않거나 예상보다 많은 데이터가 수집돼 내부 버퍼를 초과하는 문제가 발생하기도 했습니다. 이런 이슈를 겪으면서 특정 환경에 맞춘 예외 처리 방식에는 한계가 있다는 점을 깨달았습니다. 이후에는 문제를 임시로 해결하기보다, 어떤 환경에서도 안정적으로 동작할 수 있는 구조인지부터 고민하게 되었습니다. 이 과정에서 혼자 판단하기보다는 팀 안에서 설계 방향을 공유하고 기준을 함께 정리하는 것이 중요하다고 느꼈습니다. 데몬그룹에서는 특정 환경의 이슈를 개인의 문제가 아닌 팀의 설계 과제로 가져가 논의하는 문화가 자연스럽게 자리 잡혀 있어, 더 보편적인 설계 기준을 만들어가는 데 큰 도움이 되고 있습니다.

2. 인프라부터 TP·Kubernetes까지 넓어진 시야

Q. 인프라부터 APM과 TP 모니터링까지 폭넓은 영역을 다루시는데요. 개발자로서 달라졌다고 느끼신 부분이 있으신가요?

이전에는 주로 Linux 환경에서 C 언어 기반 개발을 해왔습니다. 엑셈에 합류한 이후에는 전혀 경험하지 못했던 기술 영역을 많이 접하게 됐습니다. 입사 초기에는 TP 모니터링을 담당하며 TMAX, TUXEDO 기반 미들웨어 구조와 트랜잭션 흐름을 이해해야 했고, 실무에서 직접 부하 트랜잭션을 다뤄볼 수 있었던 경험이 인상 깊었습니다. 인프라 영역에서는 AIX, HP-UX, SunOS 등 다양한 운영체제를 다루며 OS마다 커널 인터페이스와 시스템 API가 크게 다르다는 점을 몸으로 익히게 됐고, 네트워크 영역에서는 SNMP 기반 MIB 구조와 OID 체계를 이해하게 되었습니다. 최근에는 Python 기반 에이전트를 통해 Kubernetes 환경까지 경험하고 있습니다. 여러 영역을 넘나들며 개발하다 보니, 개별 기능 구현을 넘어 시스템 전체를 함께 고려하는 시각이 생긴 것이 가장 큰 변화라고 생각합니다

3. 고객 장애 경험에서 만들어진 설계 기준

Q. 고객 환경에서 발생하는 장애를 겪으면서, 에이전트를 설계하고 개발하는 방식에도 변화가 있었나요?

고객 환경에서만 발생하는 이슈는 사내에서 재현하기 어려운 경우가 많습니다. 이런 상황에서는 고객 환경과 최대한 유사한 구조를 구성해 재현 테스트를 진행하며 원인을 추적합니다. 로그, 수집 데이터, core dump, 로직 흐름 등을 기반으로 분석하고, 필요할 때는 팀원들과 함께 코드를 검토하며 문제의 범위를 좁혀갑니다. 이런 경험을 통해 단순히 빠르게 수정하는 것보다, 같은 문제가 반복되지 않도록 구조적으로 개선하는 것까지를 장애 대응의 일부로 보게 되었습니다. 특정 환경에 맞춘 예외 처리보다는 어떤 환경에서도 안정적으로 동작할 수 있는 구조인지부터 고민하게 된 계기이기도 합니다. 그 과정에서 가장 중요하게 생각하게 된 원칙은 '죽지 않는 에이전트'를 만드는 것입니다. 에이전트는 고객 서버에서 24시간 직접 실행되기 때문에 패치가 쉽지 않고, 일부 환경에서는 에이전트 장애가 곧 서비스 장애로 이어질 수 있습니다. 그래서 메모리 사용량, CPU 부하, 리소스 누수 여부를 꼼꼼히 점검하고, 장시간 실행 테스트를 통해 안정성을 검증하려고 노력합니다. 하위 호환성 역시 중요한 기준입니다. 최신 에이전트와 구버전 수집 서버가 함께 운영되는 환경도 많기 때문에, 기능 확장보다 항상 안정성과 호환성을 우선에 두고 설계와 개발을 진행하고 있습니다.

Q. 장애 경험을 통해 설계에 대한 관점이 달라졌다면, 이후 기술을 학습하는 태도에도 변화가 있었을 것 같습니다. 지금은 어떤 방향성을 가지고 학습을 이어가고 계신가요?

최근에는 Python 기반 모니터링 에이전트를 개발하며 Kubernetes 환경을 많이 접하고 있습니다. 온프레미스 환경과는 구조가 다르기 때문에 직접 샘플 환경을 구성해 테스트하며 학습하고 있습니다. 이론을 충분히 공부한 뒤 시작하기보다는, 필요한 부분을 익히고 바로 실습해보는 방식으로 접근하고 있으며, 생성형 AI도 개념 확인이나 실습 가이드 용도로 활용하고 있습니다.

4. AI 시대, 시스템을 함께 고민할 개발자에게

Q. 앞으로 개발자로서 어떤 방향으로 나아가고 싶으신가요?

엑셈에서 다양한 기술을 접하며 시야를 넓힐 수 있었던 만큼, 앞으로는 변화하는 IT 환경에 맞춰 더 깊이 있는 기술 이해를 갖추고 동료들의 성장에도 도움이 되는 개발자가 되고 싶습니다. 쿠버네티스에 대한 이해도를 더 높이고, AI를 코드 분석이나 테스트 자동화, 장애 원인 추적 등 실질적인 영역에 적용해 에이전트 품질과 개발 생산성을 함께 높여보고 싶습니다.

Q. 마지막으로, 엑셈에 합류를 고민하시는 분들에게 한 말씀 부탁드립니다.

엑셈에서는 실제 고객 서버에서 동작하는 시스템 에이전트를 직접 설계하고 개발할 수 있습니다. 최근에는 Go로 구현되어 있던 로그 모니터링 기능을 C 환경에 맞게 재설계한 경험도 있습니다. 제한된 환경에 맞춰 thread pool과 작업 큐 기반으로 아키텍처를 다시 설계하며, 스레드 비용과 락 경합까지 고려해 안정적으로 구현했습니다. 이 경험을 통해 시스템을 더 깊이 이해하게 됐습니다. C 기반 시스템 개발은 쉽지 않지만, 메모리와 성능, 구조를 직접 고민하며 설계하는 경험은 개발자로서 단단한 기반이 됩니다. Kubernetes, 네트워크, APM 등 다양한 기술 영역을 함께 경험할 수 있다는 점도 큰 장점입니다. 환경은 달라져도 흔들리지 않는 설계를 고민하고 싶은 개발자라면, 엑셈은 충분히 매력적인 선택이 될 것 같습니다.

📢 엑셈 데몬3팀에서 함께 성장할 C 기반 에이전트 개발자를 찾습니다

동료가 된다면 이런 경험을 함께 할 수 있어요