복잡한 문제를 함께 푸는 팀: 통합기술센터 리더가 말하는 솔루션 조직의 조건

1. 17년 여정, 세 가지 역할이 만든 리더십

1-1. 인터뷰이 소개

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

안녕하세요, 통합기술센터장을 맡고 있는 정동기입니다. 2008년에 엑셈에 입사했으니 올해로 17년차네요. 처음에는 맥스게이지 개발자로 시작했고, 중간에 DB 성능 컨설턴트로 직무를 바꿨다가, 지금은 맥스게이지, 인터맥스, 엑셈원까지 전체 모니터링 솔루션을 총괄하는 센터를 이끌고 있습니다. 돌이켜보면 세 가지 역할을 다 경험한 게 지금 팀을 이끄는 데 정말 큰 자산이 된 것 같아요. 개발자 시절에는 '어떻게 만들 것인가'를 고민했고, 컨설턴트 시절에는 '왜 이게 필요한가'를 배웠죠. 지금은 '누가 어떻게 성장할 것인가'를 생각하고 있습니다.

1-2. 공통 키워드

개발자, 컨설턴트, 센터장까지 세 가지 역할을 모두 경험하셨는데요. 각 경험을 관통하는 공통 키워드가 있다면 무엇일까요?

'번역'이라는 단어가 떠오르네요. 개발자 시절엔 사용자의 불편함을 코드로 번역했고, 컨설턴트 시절엔 DB 성능 이슈를 고객이 이해할 수 있는 언어로 번역했어요. 지금은 조금 다른 번역을 하고 있습니다. 엔지니어들의 기술적 고민을 조직의 방향으로, 고객의 요구사항을 팀의 목표로 번역하는 역할이죠. 2024년에 엑셈원 첫 대규모 구축 프로젝트를 할 때가 생각나네요. 팀원들이 가장 힘들어했던 순간이 '왜 우리가 이걸 해야 하는지' 명확하지 않았을 때였거든요. 그때 제가 했던 일이 고객사 현장에 팀원들을 직접 데려간 거예요. 담당자분이 장애 대응하면서 얼마나 힘들어하시는지, 우리 솔루션이 그분한테 어떤 의미인지 직접 보게 했죠. 그 이후로 팀원들 눈빛이 완전히 달라지더라고요. 기술은 결국 누군가의 문제를 해결하기 위한 거잖아요.

1-3. 핵심 가치

엑셈 통합기술센터 핵심 가치_인터뷰 — 사진 촬영 : 전현지 TA Manager

통합기술센터가 정의하는 핵심 가치를 한 문장으로 설명해주신다면요?

통합기술센터의 핵심 가치는 ‘복잡한 문제를 함께 풀어가는 팀’입니다. 여기서 가장 중요한 단어는 ‘함께’입니다. 엑셈원은 인프라, 쿠버네티스, 애플리케이션, 데이터베이스까지 전 영역을 아우르는 만큼, 한 사람이 모든 영역을 완벽하게 잘하기는 현실적으로 어렵습니다. 인프라 전문가는 DB를 깊게 모를 수 있고, DB 전문가는 컨테이너 오케스트레이션이 낯설 수 있습니다. 그래서 우리 센터는 모든 걸 혼자 완벽하게 해내는 개인을 기대하기보다, 각자의 강점을 모으고 서로 함께 돕고 치열하게 고민하며 배우는 문화를 더 중요하게 생각합니다.

2. 대규모 멀티클라우드, 하나의 모니터링

2-1. 기술보다 사람이 어려웠던 순간

엑셈원의 첫 대규모 모니터링 구축 사례(AWS·Azure·On-premise 멀티클라우드 환경)를 진행하시면서, 기술적 도전도 있겠지만 팀원들과 관련된 어려움도 컸을 것 같습니다. 어떤 순간이 가장 힘들었나요?

프로젝트 초반 3개월이 가장 힘들었습니다. 온프레미스와 AWS·Azure 같은 퍼블릭 클라우드가 뒤섞인 멀티 클라우드·하이브리드 환경을 마치 하나의 환경처럼 인프라–쿠버네티스–WAS–애플리케이션–데이터베이스까지 한 흐름으로 묶어 보여주는 풀스택 모니터링을 만들어야 했거든요. 시스템이 올라가 있는 위치도, 담당하는 조직도 제각각이라, 이 복잡한 환경을 기준과 관점 하나로 정리하는 일이 가장 큰 어려움이었습니다.

기술적으로 어려웠던 건 오히려 명확했습니다. 이미 아키텍처와 스키마는 잘 설계되어 있었고, 각 환경에 맞게 어떤 데이터를 어떤 방식으로 수집해서 한 흐름으로 연결할지만 정하면 됐으니까요. 진짜 어려운 건 사람마다 ‘엔드투엔드’와 ‘중요한 지표’의 정의가 모두 달랐다는 점이었습니다. 인프라 팀은 서버와 네트워크 리소스를 가장 중요한 기준으로 보고, 애플리케이션 팀은 트랜잭션과 API 응답 시간에 집중하고, DB 팀은 쿼리와 락, 대기 이벤트를 우선순위에 두었습니다. 각자 “우리 구간은 잘 보인다”라고 말하는데, 정작 고객이 원하는 건 “한 거래가 어디에서 막히는지 한눈에 보고 싶다”는 것이었죠. 이 관점을 맞추는 데 시간이 많이 걸렸습니다.

그래서 어느 시점부터 접근을 바꿨습니다. 팀을 한 회의실에 모아놓고, 실제 멀티 클라우드·하이브리드 환경에서 발생했던 장애 시나리오를 그대로 펼쳐놓고 물었습니다. “이 거래가 고객 입장에서 느려졌다고 할 때, 지금 우리가 설계한 구조로 5분 안에 병목 지점을 찾을 수 있을까요?” 그 질문을 던지고 나니, 자연스럽게 이야기가 바뀌었습니다. “우리 지표”가 아니라 “장애를 가장 빨리 찾기 위해 꼭 필요한 지표와 흐름이 무엇인가”를 기준으로 논의가 되기 시작한 거죠. 그때부터 공통 태깅 체계, 트랜잭션 추적 방식, 화면에서 무엇을 먼저 보여줘야 하는지에 대해 합의가 생겼습니다.

그 경험을 통해 느낀 건, 풀스택 모니터링이든 멀티 클라우드든 기술 선택은 결국 ‘왜 이걸 보려는가’라는 질문에서 출발해야 하고, 그 ‘왜’를 사람끼리 맞추는 일이 기술 자체보다 더 어렵다는 사실이었습니다.

2-2. 의사결정 원칙

그 과정에서 센터장님이 가장 중요하게 생각했던 의사결정 원칙이 있다면 무엇인가요?

"회의실에서 오래 논쟁하지 말고, 짧게라도 직접 만들어서 검증하고 결정하자"는 원칙입니다. 저는 웬만한 기술 이슈는 말이 아니라 PoC로 풀어야 한다고 생각합니다. 풀스택 모니터링을 만들다 보면 기술적인 장벽이 꼭 생깁니다. 수집 방식이나 저장 구조, 아키텍처 선택처럼 지원과 개발의 의견이 갈리는 지점들이 있죠. 그럴 때 저는 한쪽 의견을 택하는 방식이 아니라, 지원과 개발이 함께 작은 테스트 환경을 만들고 실제와 비슷한 데이터를 넣어 성능과 안정성, 운영 편의성을 같이 검증한 뒤에 결정하도록 했습니다. 어떤 선택이 이론적으로 옳은지보다, 실제 운영 환경에서 더 잘 버티고 엔지니어와 고객에게 도움이 되는지를 기준으로 보는 겁니다. 그렇게 같이 검증을 해보면 처음에 입장이 달랐던 사람들도 결과를 납득하고, 한 번 결정된 방향을 서로 신뢰하면서 밀고 나갈 수 있었습니다

2-3. 팀의 변화

프로젝트를 성공적으로 마무리하고 나서, 팀에서 가장 크게 달라진 점은 무엇인가요?

'우리는 할 수 있다'는 자신감이 생긴 거죠. 처음 대규모 멀티클라우드 환경 모니터링 목표를 얘기했을 때 팀원들 반응이 "정말 가능할까요?"였거든요. 그런데 실제로 시스템이 안정적으로 돌아가는 걸 보니까, 다들 표정이 완전히 달라지더라고요.

특히 인상 깊었던 건, 한 주니어 엔지니어가 장애 대응 후에 저한테 찾아와서 한 얘기예요."이번 프로젝트 전에는 제가 작성한 쿼리나 기획에 참여한 화면들이 현장에서 어떻게 쓰이는지, 그리고 장애 상황에서 얼마나 중요한 역할을 하는지 실감이 잘 안 났는데요. 이제는 고객사가 알림을 확인하고 우리 화면을 보는 그 몇 초 동안, 어떤 정보가 어떻게 보여야 하는지가 얼마나 중요한지 몸으로 느낀 것 같습니다."

이게 바로 제가 원했던 변화예요. 기술은 배우면 늘어요. 그런데 내가 만든 것의 의미가 어디서, 어떻게 쓰이는지 아는 감각은 실제 프로젝트 경험이 만들어주는 거거든요.

3. 서로 다른 영역의 전문가들, 하나의 목표를 만드는 법

3-1. 협업의 장벽

인프라, 쿠버네티스, DB, WAS 등 서로 다른 영역의 전문가들이 협업할 때, 기술 차이보다 더 큰 장벽은 무엇이었나요?

저는 가장 큰 장벽이 '내 영역이 제일 중요하다'는 생각이라고 봅니다. 인프라팀은 "서버가 죽으면 끝", DB팀은 "쿼리가 느리면 끝", WAS팀은 "로직 오류가 제일 많다"고 말하죠. 말 자체는 다 맞지만, 각자 자기 관점에만 머물러 있으면 전체 흐름을 보기가 어렵습니다. 그래서 실제 고객사 장애 시나리오를 가지고 인프라 → 쿠버네티스 → WAS → DB 순서로 같이 로그와 메트릭을 따라가 보는 '장애 재현 워크숍'을 진행했습니다. 한번은 특정 API 응답이 10초까지 느려진 이슈가 있었는데, 각 팀이 자기 구간만 볼 때는 원인이 뚜렷하지 않았지만, 타임라인을 맞춰서 함께 보니 여러 계층에서 동시에 영향을 주고받는 복합적인 이슈라는 것이 드러났습니다. 이 경험 이후로 팀원들이 '문제는 한 레이어에서만 생기지 않는다'는 것을 체감했고, 자연스럽게 옆 팀의 메트릭과 로그도 함께 보는 문화가 생겼습니다. 결국 기술 장벽보다 더 컸던 것은 관점의 장벽이었고, 이를 깨는 가장 좋은 방법은 같은 장애를 놓고 끝까지 함께 추적해 보는 경험이라고 느꼈습니다.

3-2. 의견 충돌 조율

팀 간 의사결정은 어떤 프로세스로 진행되나요? 특히 의견이 충돌할 때는 어떻게 조율하시나요?

저는 데이터로 말하는 것과 고객 중심 사고 두 가지 원칙을 강조해요. 예를 들어, 엑셈원 대시보드 UI를 설계할 때 '영역별 모니터링 뷰'랑 '커스텀 대시보드(사용자가 직접 설계하는 것)' 중에 뭘 우선할지 의견이 갈렸어요. 개발팀은 "기본이 되는 '영역별 모니터링 뷰'부터 먼저 구축해야 한다"고 했고, 컨설팅팀은 "현장마다 보고 싶은 게 다 다르니까 커스텀이 먼저 되어야 한다"라고 하더라고요. 그때 제가 한 게 뭐냐면, 실제 고객사 3곳에 두 방식을 다 제공하고 사용 로그를 분석한 거예요. 결과가 되게 명확했어요. 초기엔 영역별 모니터링 뷰를 90% 썼는데, 3개월 후엔 커스텀 대시보드 사용률이 60%까지 올라갔거든요. 고객이 시스템에 익숙해질수록 자기만의 뷰를 원한다는 거죠. 이 데이터를 보고 나니까 개발팀도 "그럼 두 기능 모두 고도화하되, 커스텀 대시보드의 학습 난이도를 낮추는 데 집중하자"로 방향이 자연스럽게 정리됐어요. 감정 싸움이 아니라 고객 행동 데이터로 결정하니까 훨씬 건강한 논의가 되더라고요.

3-3. 시스템 사고를 가진 엔지니어

센터장님이 생각하시기에, 전 영역을 아우르는 '시스템 사고'를 가진 엔지니어의 공통점은 무엇인가요?

글쎄요, 거창한 건 아니고요. 그냥 “한 단계 더 파보는 습관”이 있는 사람들입니다. 예를 들어 슬로우 쿼리가 발견되면, 보통은 실행 계획을 보고 인덱스를 추가하거나 통계를 갱신하고 끝내는 경우가 많죠. 그런데 시스템 사고를 가진 엔지니어는 거기서 한 번 더 묻습니다. “왜 지금 이 시점부터 느려졌지?” “이 쿼리가 사용되는 서비스나 트랜잭션에 어떤 변화가 있었지?” 그래서 단순히 쿼리와 인덱스만 보지 않고, - 최근 배포된 애플리케이션 변경 사항 - 트래픽 패턴 변화 - 배치 작업이나 다른 서비스와의 경합 - 인프라·쿠버네티스 레벨의 리소스/스케줄링 변화 까지 같이 훑어보면서 원인을 찾습니다. 겉으로는 “DB 슬로우 쿼리”처럼 보이지만, 실제 원인이 애플리케이션 호출 패턴 변경이나 특정 배치 작업, 혹은 리소스 할당 정책 변경인 경우가 많거든요.

이런 엔지니어들이 특별한 천재라서가 아니라, 내가 보고 있는 것 뒤에 다른 원인이 있을 수 있다는 걸 인정하고, “이 부분은 네가 더 잘 아니까 같이 보자”라며 동료에게 묻는 걸 자연스럽게 받아들이는 사람들입니다. 저희는 그런 태도와 습관을 시스템 사고의 핵심으로 보고 있습니다.

3-4. 배울 수 있는 것

마지막으로, 엑셈 통합기술센터에 합류하면 '이것만큼은 배울 수 있다'고 자신하는 부분이 있을까요?

세 가지를 꼽을 수 있을 것 같아요. 첫째, 전체를 보는 시야. 맥스게이지(DB), 인터맥스(WAS), 엑셈원(풀스택)까지 20년간 쌓아온 모니터링 노하우를 한 곳에서 배울 수 있어요. '내가 설계한 시스템이 시스템 전체에서 어떤 의미를 갖는지' 이해하게 되죠. 둘째, 고객과 가까운 개발 문화. 우리 엔지니어들은 정기적으로 컨설팅팀과 함께 고객 현장에 동행해요. '이 기능이 왜 필요한지'를 회의실이 아니라 현장에서 직접 배웁니다. 이 경험은 저한테도 개발자에서 컨설턴트로 전환할 때 가장 큰 자산이 됐어요. 셋째, 실패를 공유하는 문화. 저희는 분기마다 실패한 기술, 놓친 버그, 잘못된 의사결정을 공개적으로 발표하고 학습하는 시간을 가져요. 처음엔 좀 어색했는데, 지금은 팀원들이 서로 실패 사례를 공유하면서 같은 실수를 반복하지 않게 됐죠.

4. 우리가 찾는 사람

엑셈_우리가 찾는 사람_인터뷰 — 사진 촬영 : 전현지 TA Manager

지금 엑셈 통합기술센터가 가장 필요로 하는 사람은 어떤 분일까요?

완벽한 기술보다 '함께 성장하고 싶은 마음'을 가진 분이요. 솔직히 처음부터 인프라, 쿠버네티스, DB, WAS를 다 잘하는 사람은 없어요. 저도 개발자로 시작해서 DB 컨설턴트가 되기까지 5년 걸렸고, 전체 시스템을 보는 눈을 갖기까지 또 5년 걸렸거든요. 중요한 건 배우려는 의지와 옆 사람에게 물어보는 용기예요. 그래서 우리는 이런 분을 찾고 있어요.