10월 22~23일에 열린 Enterprise Engineering Summit 2025에 참석했으며, 이번 경험을 되돌아보기 위해 Gibbs 성찰 주기를 활용하기로 했다.

설명

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 코딩 도구와의 통합을 더 잘 지원하기 위해 자체 내부 개발자 포털 솔루션을 구축할 계획이라고 밝혔다.

AI 코딩 도구는 생산성 향상에 대한 장밋빛 전망을 내세우기도 하지만, 이러한 주장을 어떻게 측정하고 검증할 것인가? David Graça는 AXA에서 AI 도구의 임팩트를 측정하기 위해 개발자 생산성 지표를 어떻게 활용하고 있는지 설명했다.

결론

다른 조직들이 플랫폼 엔지니어링에 어떻게 접근하고 있는지 들을 수 있어 정말 값진 경험이었다. 나에게 핵심적으로 남은 교훈은 다음과 같다:

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

실행 계획

나의 다음 단계는 다음과 같다:

• 이 생각들을 팀의 다른 구성원들과 공유하기
• 개발자 피드백을 수집하고 플랫폼 임팩트를 측정하는 방식을 재점검하고, 이를 우선순위 결정 과정에 더 잘 반영할 방법을 찾기
• 더 많은 팀 간 커뮤니티와 협업을 만들 기회를 모색하기