복잡한 기술 환경일수록 중요한 건 더 뛰어난 개인이 아니라, 서로 다른 전문성을 가진 사람들이 한 방향을 향해 움직이도록 만드는 조직의 힘입니다.
17년 동안 개발자, 컨설턴트, 그리고 센터장까지 다양한 역할을 경험해온 정동기 센터장은 통합기술센터가 한 사람의 완벽함보다 서로의 강점을 모으고 함께 고민하며 배우는 문화를 더 중요하게 여겨 왔다고 말합니다. 멀티클라우드와 풀스택 모니터링이라는 큰 도전 속에서도 그는 고객의 문제를 가장 빠르게 해결할 기준을 세우고, 각자의 전문성이 자연스럽게 연결되는 협업 방식을 만들어 왔습니다.
통합기술센터를 이끌고 있는 정동기 센터장을 만나, 엑셈에서 솔루션 조직이 어떻게 성장하고 협업하는지 들어보았습니다.
1. 세 가지 역할의 경험으로 정의한 통합기술센터의 가치
Q. 안녕하세요, 간단한 자기소개 부탁드립니다.
안녕하세요, 통합기술센터장을 맡고 있는 정동기입니다. 2008년에 엑셈에 입사했으니 올해로 17년차네요. 처음에는 맥스게이지 개발자로 시작했고, 중간에 DB 성능 컨설턴트로 직무를 바꿨다가, 지금은 맥스게이지, 인터맥스, 엑셈원까지 전체 모니터링 솔루션을 총괄하는 센터를 이끌고 있습니다.
돌이켜보면 세 가지 역할을 다 경험한 게 지금 팀을 이끄는 데 정말 큰 자산이 된 것 같아요. 개발자 시절에는 '어떻게 만들 것인가'를 고민했고, 컨설턴트 시절에는 '왜 이게 필요한가'를 배웠죠. 지금은 '누가 어떻게 성장할 것인가'를 생각하고 있습니다.
Q. 개발자, 컨설턴트, 센터장까지 세 가지 역할을 모두 경험하셨는데요. 각 경험을 관통하는 공통 키워드가 있다면 무엇일까요?
'번역'이라는 단어가 떠오르네요. 개발자 시절엔 사용자의 불편함을 코드로 번역했고, 컨설턴트 시절엔 DB 성능 이슈를 고객이 이해할 수 있는 언어로 번역했어요. 지금은 조금 다른 번역을 하고 있습니다. 엔지니어들의 기술적 고민을 조직의 방향으로, 고객의 요구사항을 팀의 목표로 번역하는 역할이죠.
2024년에 엑셈원 첫 대규모 구축 프로젝트를 할 때가 생각나네요. 팀원들이 가장 힘들어했던 순간이 '왜 우리가 이걸 해야 하는지' 명확하지 않았을 때였거든요. 그때 제가 했던 일이 고객사 현장에 팀원들을 직접 데려간 거예요. 담당자분이 장애 대응하면서 얼마나 힘들어하시는지, 우리 솔루션이 그분한테 어떤 의미인지 직접 보게 했죠. 그 이후로 팀원들 눈빛이 완전히 달라지더라고요. 기술은 결국 누군가의 문제를 해결하기 위한 거잖아요.
Q. 통합기술센터가 정의하는 핵심 가치를 한 문장으로 설명해주신다면요?
‘복잡한 문제를 함께 풀어가는 팀’이요. 여기서 가장 중요한 단어는 ‘함께’예요.
엑셈원은 인프라, 쿠버네티스, 애플리케이션, 데이터베이스 까지 전 영역을 아우르는 만큼, 한 사람이 모든 영역을 완벽하게 잘하기는 현실적으로 어렵습니다. 인프라 전문가는 DB를 깊게 모를 수 있고, DB 전문가는 컨테이너 오케스트레이션이 낯설 수 있습니다. 그래서 우리 센터는 모든 걸 혼자 완벽하게 해내는 개인을 기대하기보다, 각자의 강점을 모으고 서로 함께 돕고 치열하게 고민하며 배우는 문화를 더 중요하게 생각합니다.
2. 대규모 멀티클라우드 구축 경험이 만든 팀과 의사결정
Q. 엑셈원의 첫 대규모 모니터링 구축 사례(AWS·Azure·On-premise 멀티클라우드 환경)를 진행하시면서, 기술적 도전도 있겠지만 팀원들과 관련된 어려움도 컸을 것 같습니다. 어떤 순간이 가장 힘들었나요?
프로젝트 초반 3개월이 제일 힘들었습니다. AWS, Azure, 온프레미스 다 섞인 환경을 하나로 보여주는 풀스택 모니터링. 말은 쉬운데, 막상 시작하니까 인프라팀, 애플리케이션팀, DB팀 각자가 보는 '중요한 지표'가 다 달랐던 점이 가장 큰 어려움이었습니다.
기술은 사실 명확했어요. 아키텍처도 스키마도 이미 잘 설계되어 있었고, 각 환경에서 어떤 데이터를 어떻게 수집해서 연결할지만 정하면 됐으니까요. 진짜 어려웠던 건 사람이었어요.
인프라팀은 서버 리소스를 가장 중요하게 보고, 애플리케이션팀은 트랜잭션 흐름에 집중하고, DB팀은 쿼리 실행을 우선순위에 두죠. 모두 "우리 구간은 잘 보인다"고 하는데, 고객이 원하는 건 그게 아니었어요. "한 거래가 어디서 막히는지 한눈에 보고 싶다"였죠. 그래서 어느 날 팀 전체를 한 회의실에 모았어요. 실제로 고객사에서 있었던 장애 시나리오를 펼쳐놓고 물었습니다.
"이 거래가 느려졌다고 할 때, 지금 우리가 설계한 구조로 5분 안에 병목 지점 찾을 수 있어요?"
그 질문 하나로 분위기가 확 바뀌었어요. "우리 영역에서는 이게 중요해"가 아니라 "장애를 가장 빨리 찾으려면 뭘 봐야 하지?"로요. 그때부터 공통 태깅을 어떻게 할지, 트랜잭션을 어떻게 추적할지, 화면에 뭘 먼저 보여줄지에 대해 합의가 생겼습니다.
결국 기술보다 사람끼리 '왜'를 맞추는 게 더 어려웠던 거죠.
Q. 그 과정에서 센터장님이 가장 중요하게 생각했던 의사결정 원칙이 있다면 무엇인가요?
"회의실에서 오래 논쟁하지 말고, 짧게라도 만들어서 검증하자"는 원칙입니다.
저는 기술 이슈는 말이 아니라 PoC로 풀어야 한다고 생각해요. 수집 방식이나 저장 구조 같은 부분은 지원팀이랑 개발팀 의견 갈릴 때 있죠. 그럴 때 한쪽 의견을 택하는 게 아니라, 둘 다 작은 테스트 환경을 만들어서 실제 비슷한 데이터 넣어봤습니다.
성능이랑 안정성, 운영 편의성을 같이 검증하고 나면, 처음에 입장 달랐던 사람들도 결과를 납득하고, 한번 결정된 방향을 서로 신뢰하면서 밀고 나갈 수 있어요. 이론적으로 뭐가 옳은지보다, 실제 운영 환경에서 뭐가 더 잘 버티고 엔지니어랑 고객한테 도움이 되는지가 중요하니까요.
Q. 프로젝트를 성공적으로 마무리하고 나서, 팀에서 가장 크게 달라진 점은 무엇인가요?
'우리는 할 수 있다'는 자신감을 얻은것 같아요. 처음에 목표 얘기했을 때 반응이 "정말 가능할까요?"였습니다. 근데 실제로 시스템이 안정적으로 돌아가는 거 보니까, 다들 표정이 완전히 달라졌어요.
특히 한 주니어 엔지니어가 장애 대응 후에 저한테 찾아와서 한 말이 기억나요. "센터장님, 저 이번 프로젝트 전에는 제가 작성한 쿼리나 설계한 화면이 현장에서 어떻게 쓰이는지 실감이 안 났거든요. 근데 이제는 고객사가 알림 확인하고 우리 화면 보는 그 몇 초가 얼마나 중요한지 몸으로 느낀 것 같아요."
이게 바로 제가 원했던 변화예요. 기술은 배우면 늘어요. 근데 내가 만든 게 어디서 어떻게 쓰이는지 아는 그 감각은, 실제 프로젝트 경험이 만들어주는 거거든요.
3. 서로 다른 전문성을 잇는 협업과 구조적 이해의 관점
-%E1%84%83%E1%85%A1%E1%84%8B%E1%85%B3%E1%86%B7%E1%84%8B%E1%85%A6%E1%84%89%E1%85%A5-%E1%84%87%E1%85%A7%E1%86%AB%E1%84%92%E1%85%AA%E1%86%AB-png.jpg?table=block&id=2d8ddf18-253e-804a-b188-c4e3063e965f&cache=v2)
Q. 인프라, 쿠버네티스, DB, WAS 등 서로 다른 영역의 전문가들이 협업할 때, 기술 차이보다 더 큰 장벽은 무엇이었나요?
'내 영역이 제일 중요하다'는 생각이요.
인프라팀은 "서버 죽으면 끝이다", DB팀은 "쿼리 느리면 끝이다", WAS팀은 "로직 오류가 제일 많다" 이렇게 말하거든요. 말 자체는 다 맞아요. 근데 각자 자기 관점에만 머물러 있으면 전체 흐름을 보기 어렵습니다.
그래서 '장애 재현 워크숍'을 했어요. 실제 고객사 장애 시나리오 가지고, 인프라→쿠버네티스→WAS→DB 순서로 같이 로그랑 메트릭 따라가 보는 거죠. 한번은 특정 API가 10초까지 느려진 이슈가 있었는데요, 각 팀이 자기 구간만 볼 때는 원인이 뚜렷하지 않았어요. 근데 타임라인 맞춰서 함께 보니까, 여러 계층에서 동시에 영향 주고받는 복합 이슈라는 것이 드러났습니다.
이 경험 이후로 팀원들이 '문제는 한 레이어에서만 생기지 않는다'는 걸 체감했어요. 그래서 자연스럽게 옆 팀 메트릭도 같이 보는 문화가 생겼죠. 결국 기술 장벽보다 관점의 장벽이 더 컸고, 이걸 깨는 가장 좋은 방법은 같은 장애를 끝까지 함께 추적해 보는 경험이었어요.
Q. 팀 간 의사결정은 어떤 프로세스로 진행되나요? 특히 의견이 충돌할 때는 어떻게 조율하시나요?
저는 ‘데이터로 말하는 것’ 과 ‘고객 중심 사고’ 두 가지 원칙을 강조해요.
엑셈원 대시보드 UI 설계할 때였어요. '영역별 기본 뷰'랑 '커스텀 대시보드(사용자가 직접 설계)' 중에 뭘 먼저 만들지로 의견이 갈렸거든요. 개발팀은 "기본이 되는 영역별 뷰부터 구축해야 한다"고 했고, 컨설팅팀은 "현장마다 보고 싶은 게 다 다르니까 커스텀이 먼저"라고 했어요.
그래서 제가 실제 고객사 3곳에 두 방식 다 제공하고 사용 로그를 3개월간 추적했어요. 결과가 명확하더라고요. 초기엔 기본 뷰를 90% 썼는데, 3개월 후엔 커스텀 대시보드 사용률이 60%까지 올라갔어요. 고객이 시스템에 익숙해질수록 자기만의 뷰를 원한다는 거죠.
이 데이터 보고 나니까 개발팀도 자연스럽게 "그럼 둘 다 고도화하되, 커스텀의 학습 곡선을 낮추는 데 집중하자"로 방향이 잡혔어요. 감정 싸움이 아니라 고객 행동으로 결정하니까 훨씬 건강한 논의가 된것같습니다.
Q. 센터장님이 생각하시기에, 전 영역을 아우르는 '시스템 사고'를 가진 엔지니어의 공통점은 무엇인가요?
그들의 공통점은 "한 단계 더 파보는 습관"이 있는 사람들인것 같아요. 예를 들어 슬로우 쿼리 발견되면, 보통은 실행 계획 보고 인덱스 추가하고 끝내잖아요. 근데 시스템 사고 가진 엔지니어는 거기서 한 번 더 물어요.
"왜 지금 이 시점부터 느려졌지?"
"이 쿼리 사용하는 서비스에 어떤 변화가 있었지?"
그래서 단순히 쿼리랑 인덱스만 보지 않고, 최근 배포된 애플리케이션 변경사항, 트래픽 패턴 변화, 배치 작업이나 다른 서비스와의 경합, 인프라 레벨의 리소스 할당까지 같이 훑어보며 원인을 찾습니다. 겉으로는 "DB 슬로우 쿼리" 처럼 보이지만, 실제 원인이 애플리케이션 호출 패턴 변경이거나 특정 배치 작업, 리소스 할당 정책 변경인 경우가 많거든요.
이런 엔지니어들이 특별한 천재여서가 아니라, 내가 보고 있는 것 뒤에 다른 원인이 있을 수 있다는 걸 인정하고, "이 부분은 네가 더 잘 아니까 같이 보자"라고 동료한테 묻는 걸 자연스럽게 받아들이는 사람들이에요.
저희는 그런 태도와 습관을 시스템 사고의 핵심으로 봐고 있습니다.
Q. 마지막으로, 엑셈 통합기술센터에 합류하면 '이것만큼은 배울 수 있다'고 자신하는 부분이 있을까요?
첫째, 전체를 보는 시야.
맥스게이지(DB), 인터맥스(WAS), 엑셈원(풀스택)까지 20년간 쌓아온 모니터링 노하우를 한 곳에서 배울 수 있어요. '내가 설계한 시스템이 전체에서 어떤 의미를 갖는지' 이해하게 되죠.
둘째, 고객과 가까운 개발 문화.
우리 엔지니어들은 정기적으로 컨설팅팀이랑 고객 현장에 동행해요. '이 기능이 왜 필요한지'를 회의실이 아니라 현장에서 직접 배우는 거죠. 이 경험은 저한테도 개발자에서 컨설턴트로 전환할 때 가장 큰 자산이 됐어요.
셋째, 실패를 공유하는 문화.
저희는 분기마다 실패한 기술, 놓친 버그, 잘못된 의사결정을 공개적으로 발표하고 학습하는 시간을 가져요. 처음엔 좀 어색했는데, 지금은 팀원들이 서로 실패 사례 공유하면서 같은 실수를 반복 안 하게 됐죠.
4. 미래의 엑셈 엔지니어들에게 전하는 한마디
Q. 지금 엑셈 통합기술센터가 가장 필요로 하는 사람은 어떤 분일까요?
완벽한 기술보다 '함께 성장하고 싶은 마음'을 가진 분이요.
처음부터 인프라, 쿠버네티스, DB, WAS 다 잘하는 사람은 없어요. 저도 개발자로 시작해서 DB 컨설턴트 되기까지 5년 걸렸고, 전체 시스템 보는 눈 갖기까지 또 5년 걸렸거든요. 중요한 건 배우려는 의지랑 옆 사람한테 물어보는 용기예요.
그래서 우리는 이런 분을 찾고있습니다.
- '왜 이 문제가 발생했을까?'를 끝까지 추적하고 싶은 사람
- '내가 설계한 시스템이 고객에게 어떤 의미인지' 궁금한 사람
- '다른 영역 엔지니어랑 대화하면서 함께 문제 풀고 싶은' 사람
기술 스택이 얼마나 많은지보다, 문제를 대하는 이런 태도가 우리한테는 더 중요해요.
함께하신다면, 상상하신 것보다 훨씬 빠르게 성장할 수 있을 거예요.
📢 엑셈 통합기술센터에서 함께 성장할 네트워크/인프라 엔지니어를 찾습니다.
동료가 된다면 이런 경험을 함께 할 수 있어요.
- 한 영역만이 아닌, 전체 시스템을 이해하는 엔지니어로 성장
- 고객 현장과 가까운 개발 문화
- 실패를 공유하고 함께 배우는 경험
함께 보면 좋은 아티클
