2025년 10월 22~23일에 열린 Enterprise Engineering Summit 2025에 참석했으며, Gibbs의 성찰 주기(Gibbs' Reflective Cycle)를 활용해 이번 경험을 돌아보기로 했습니다.

상황 설명

10월 말, 동료 몇 명과 함께 대기업 환경에서의 플랫폼 엔지니어링 프랙티스를 주제로 한 2일간의 컨퍼런스에 참석했습니다. 다른 조직에서는 플랫폼 엔지니어링을 어떻게 도입하고 있는지 더 알아보고, 우리 플랫폼 팀의 운영 방식을 개선하는 데 도움이 될 인사이트를 얻을 수 있기를 기대했습니다.

행사는 업계 전문가들이 이끄는 다양한 강연과 패널 토론으로 구성되었으며, 세 가지 트랙으로 진행되었습니다:

• 플랫폼 엔지니어링
• 개발자 경험
• 옵저버빌리티 & SRE

저는 주로 플랫폼 엔지니어링 트랙에 참여했으며, 다음과 같은 세션들을 들었습니다:

느낌

호기심과 기대를 안고 서밋에 참석했습니다. 플랫폼 팀으로서 유용한 공통 솔루션을 몇 가지 구축해 왔지만, 다른 조직이 플랫폼 엔지니어링을 어떻게 구성하고 운영하는지 배울 점이 많다고 느꼈기 때문입니다.

강연을 들으며 공감을 느끼는 동시에 답답함도 느꼈습니다. 많은 발표에서 잘 정의된 프랙티스를 갖춘 성숙한 플랫폼 팀과, 플랫폼 엔지니어링을 프로덕트처럼 관리하는 전담 역할을 보유한 대규모 엔지니어링 조직의 사례가 소개되었습니다. 우리가 겪는 어려움이 다른 조직에서도 공통적으로 나타난다는 점에서는 공감을 얻었지만, 다른 팀들이 우리보다 얼마나 앞서 있는지를 확인하는 것은 한편으로 답답하게 느껴졌습니다. 동시에 다른 팀들이 구현한 해결책에서 영감을 얻었고, 그 아이디어 중 일부를 우리 팀에 가져와 적용하고 싶다는 동기부여도 받았습니다.

서밋을 떠나며 앞으로 나아갈 길에 대해 겸허함과 설렘이 교차하는 기분을 느꼈고, 우리 플랫폼 팀을 발전시키기 위해 실질적으로 어떤 단계를 밟아 나갈 수 있을지 고민하게 되었습니다.

평가

일부 강연은 우리의 상황과는 다소 거리가 멀게 느껴졌습니다. 특히 규제가 엄격한 산업이나 자원이 풍부한 초대형 엔터프라이즈 사례가 그러했습니다.

하지만 다양한 접근 방식을 접하고, 조직의 규모나 산업에 관계없이 성공적인 플랫폼 팀을 뒷받침하는 공통의 핵심 원칙을 발견하는 과정은 매우 흥미로웠습니다.

특히 여러 조직이 플랫폼 팀의 성과를 측정하기 위해 지표를 어떻게 활용하는지, 그리고 제한된 자원으로 레거시 시스템을 관리하는 기업들의 이야기는 더욱 흥미로웠습니다.

분석

저는 2023년에 작성한 블로그 글에서 우리 플랫폼 팀이 겪었던 여러 과제를 다룬 적이 있는데, 당시 짚었던 내용들이 이번 서밋의 주제들과 어떻게 맞닿아 있는지 되돌아보는 것도 흥미로운 일이었습니다.

우선순위 지정

당시 글에서는 서로 다른 프로덕트 팀들의 상충하는 요구 사이에서 균형을 잡고, 플랫폼 업무가 더 넓은 비즈니스 목표와 부합하도록 만드는 등 우선순위 결정 과정에서 겪은 어려움에 대해 썼습니다.

서밋에서는 플랫폼을 프로덕트처럼 다루는 것의 중요성을 강조한 발표가 여러 차례 있었습니다. 사용자 니즈를 파악하고 그에 따라 업무 우선순위를 정하는 전담 역할이 필요하다는 내용이었습니다. 예를 들어 Bruno Suárez Laffargue는 Tesco에서 Head of Product for Engineering Effectiveness로서의 역할을 소개하며, 개발자 피드백과 비즈니스 임팩트를 기반으로 플랫폼 이니셔티브의 우선순위를 어떻게 정하는지 설명했습니다.

엔지니어링 팀 내에 product mindset을 장려해야 한다는 점도 반복적으로 등장한 주제였습니다. 플랫폼 팀이 단순히 기능을 만드는 것을 넘어 사용자에게 가치를 제공하는 데 집중해야 한다는 점을 강조한 것입니다.

일부 조직은 전담 프로덕트 엔지니어링 역할을 둘 여유가 있지만, 우리의 상황에서는 기존 역할 안에서 이러한 마인드셋을 어떻게 내재화할 수 있을지 모색해야 할 것 같습니다.

개발자로부터 피드백을 수집하고 플랫폼 이니셔티브의 효과를 측정하기 위해 설문과 지표를 활용하는 것도 효과적인 우선순위 결정을 위한 핵심 프랙티스로 소개되었습니다. 이 영역에서는 DX가 자주 언급되는 도구였고, 저희도 Mintel에서 도입을 검토한 바 있습니다. 그 외에도 DORA 지표와 디자인 시스템 도입 지표를 수집하기 위해 자체 도구를 만들어 활용하기도 했습니다.

일정 관리와 이른 공유

일정과 타이밍에 대한 과제도 다룬 바 있습니다. 명확한 니즈가 생기기 전에 너무 일찍 무언가를 만드는 위험과, 반대로 너무 오래 기다리다가 프로덕트 팀의 발목을 잡게 되는 위험 사이의 문제였습니다.

여러 발표에서는 거절하는 것의 중요성을 강조하며, 그것이 플랫폼 생태계에서 건강한 프랙티스라고 말했습니다. 플랫폼 팀은 병목이 되지 않도록 해야 하며, 때로는 더 넓은 목표에 부합하지 않거나 플랫폼에 적합하지 않은 요청에 대해 선을 긋는 것이 필요하다는 것입니다.

팀의 자율성을 장려하고, 프로덕트 팀이 플랫폼 가이드라인 안에서 스스로 결정하고 솔루션을 만들 수 있도록 역량을 부여해야 한다는 점도 공통된 주제였습니다. 이는 플랫폼 팀에 대한 의존성을 줄이고 개발 속도를 높이는 데 도움이 될 수 있습니다.

흥미로운 패널 토론에서는 Saxo Bank, SOK, Cycloid의 연사들이 각 조직에서 자율성과 거버넌스 사이의 균형을 어떻게 관리하는지에 대해 논의했습니다. 이때 나온 한 가지 지적은 모든 것을 지원하려다 보면 플랫폼 추상화가 오히려 기반 도구보다 더 복잡해져, 개발자의 인지 부하를 줄이려는 본래 목적을 무색하게 만들 수 있다는 것이었습니다.

사람들이 실제로 사용하는 것 만들기

사람들이 결국 사용하지 않는 것을 만들게 될 위험에 대해서도 썼습니다. 사용자 니즈를 충족하지 못해서이거나, 팀들이 자체 솔루션을 직접 만드는 것을 선호하기 때문인 경우가 많습니다.

이는 앞서 우선순위 부분에서 언급한 내용과도 연결되지만, 도입 곡선에 대한 흥미로운 관점도 있었습니다. 여러 발표에서는 플랫폼 솔루션이 실제 니즈를 충족하도록 개발자를 설계와 개발 과정에 참여시키는 공동 창조(co-creation)의 중요성을 강조했습니다.

Ionut Craciunescu는 Utility Warehouse에서 관리형 Kafka 서비스로 전환하는 과정에서 프로세스 초기에 RFC를 활용해 개발자들의 피드백을 모으고 합의를 이끌어낸 사례를 소개했습니다. 이러한 접근은 솔루션이 사용자 니즈를 충족하도록 하고 도입률을 높이는 데 도움이 되었습니다.

레거시 시스템

레거시 시스템을 개선하고 유지하는 대신 이를 대체할 새로운 솔루션을 만들고 싶은 유혹과 그 위험성에 대해서도 언급한 바 있습니다.

이 주제를 다룬 흥미로운 발표가 몇 개 있었습니다. Donovan Thomson은 Utility Warehouse에서 우편 청구서를 디지털 인보이스로 전환하는 효과를 검증하기 위해 A/B 테스트를 도입한 사례를 소개했습니다. 이를 통해 전환의 이점을 수치로 측정하고 이해관계자를 설득할 수 있었다고 합니다.

Nick Simmonds는 GroupOn에서 레거시를 대하는 실용적인 접근법에 대해 이야기하며, 점진적인 유지보수와 비용 절감에 초점을 맞춘다고 설명했습니다. 그는 안정성이 economic decision이라는 점과, 가장 가치 있는 시스템 기능에 영향을 주지 않으면서 장애를 용인할 수 있는 레거시 시스템 내의 crumple zones을 식별한다는 아이디어를 소개했습니다.

지식 사일로화

마지막으로, 플랫폼 팀이 사일로가 되어 플랫폼을 사용하는 다른 팀들이 일상적으로 겪는 문제와 동떨어질 위험에 대해서도 짚었습니다.

여러 발표에서는 커뮤니티를 구축하고 팀 간 협업을 촉진하는 것의 중요성을 언급했으며, 정기적인 교차 팀 커뮤니티와 밋업을 운영한다고 소개했습니다. 일부 조직은 사내 개발자 컨퍼런스를 직접 개최해 비즈니스 전반의 엔지니어들을 한데 모아 지식과 베스트 프랙티스를 공유하기도 합니다.

팀 이동과 엔지니어 교류 역시 플랫폼 팀과 프로덕트 팀 간의 공감과 이해를 높이는 효과적인 방법으로 언급되었습니다. Daniel Gittins는 Ford에서 매년 개발자가 다음 해에 함께 일하고 싶은 팀을 직접 선택할 수 있는 행사를 운영하며, 이를 통해 비즈니스의 다양한 영역을 경험하고 팀 간 관계를 형성한다고 소개했습니다. Stephane Di Cesare는 DKB에서 개발자의 니즈와 페인 포인트를 파악하기 위한 디스커버리 기법으로 섀도잉을 활용한다고 설명했습니다.

AI와 LLM

이전 글에서는 다루지 않았지만 이번 서밋에서 자주 등장한 주제 중 하나는 AI와 대규모 언어 모델이 플랫폼 엔지니어링에 미치는 영향이었습니다.

우리의 플랫폼 솔루션이 개발자 생산성 향상을 위한 AI 도구 활용을 어떻게 지원할 수 있을지 고민해 보는 것도 흥미로운 지점입니다. Niko Kivelä와 Jacob Lärfors는 SOK에서 Backstage와 같은 기성 솔루션을 사용하는 대신, AI 코딩 도구와의 통합을 더 잘 지원하기 위해 자체 Internal Developer Portal 솔루션을 구축할 계획이라고 밝혔습니다.

AI 코딩 도구는 생산성 향상에 대해 대담한 주장을 내세우지만, 이러한 주장을 어떻게 측정하고 검증할 수 있을까요? David Graça는 AXA에서 개발자 생산성 지표를 활용해 AI 도구의 효과를 측정하는 방법에 대해 발표했습니다.

결론

다른 조직들이 플랫폼 엔지니어링에 어떻게 접근하고 있는지 들을 수 있었던 것은 저에게 정말 값진 경험이었습니다. 제가 얻은 핵심 교훈은 다음과 같습니다:

• 플랫폼을 프로덕트처럼 다루는 것은 효과적인 우선순위 설정과 개발자에게 가치를 전달하는 데 매우 중요합니다. 전담 프로덕트 엔지니어링 역할이 없더라도 기존 역할 안에 프로덕트 마인드셋을 내재화할 방법을 찾아야 합니다.
• 개발자 피드백을 수집하고 지표를 활용해 플랫폼의 임팩트를 측정하는 것이 필수적입니다. 플랫폼 개발 자체뿐만 아니라 AI 코딩 도구에 대한 투자의 효과를 측정하기 위해서도, 이를 더 효과적으로 수행할 수 있는 도구와 프로세스를 모색해야 합니다.

실행 계획

제가 앞으로 취할 다음 단계는 다음과 같습니다:

• 팀원들과 이번에 정리한 생각들을 공유하기
• 개발자 피드백을 어떻게 수집하고 플랫폼 임팩트를 어떻게 측정하고 있는지 다시 점검하고, 이를 우선순위 결정 과정에 더 잘 반영할 방법 찾기
• 더 많은 교차 팀 커뮤니티와 협업을 만들 수 있는 기회 모색하기