저희 고객사에서 최근 IDP(내부 개발 플랫폼)을 기획하는데 도움을 달라고 해서… 국내 기업의 사례가 궁금합니다. 특히, 플랫폼 엔지니어링 시점에서 국내의 골든패스 전략은 어떻게하는지…
저도 내용을 찾아보니… 글로벌하게 특정 벤더가 주장하는 내용이나, 백스테이지 같은 해외 사례의 내용만 일부 간헐적으로만 있어서요. 아시다시피, 국내는 다른 나라에 비해서 SI 용역이나 하도 형태이기도 하고, SI 개발 문화 정책 등이 다른 나라에 비해서 많은 차이가 있기에 …
국내 기업에서 개발자들이 만족하는 IDP가 성공적으로 구축한 사례가 있는지 궁금해서 문의드립니다.
요즘 국내 기업들 사이에서도 개발자 경험(DevEx)을 전면에 내세우며 IDP를 고민하는 경우가 확실히 늘고 있는 것 같습니다. 다만 실제 논의를 따라가다 보면, 말씀 주신 것처럼 해외의 Backstage 사례나 특정 벤더가 제시하는 프레임을 그대로 가져오기에는 국내 현실과의 간극이 꽤 크게 느껴지는 것도 사실입니다.
국내는 여전히 SI 중심 구조, 다단계 협력사 체계, 망 분리·보안 심의·운영 승인 같은 요소들이 강하게 작동하는 환경이고, 이런 조건 속에서의 IDP는 자연스럽게 해외 사례와는 다른 모습으로 진화해 온 것 같습니다.
대외적으로 “이 회사의 IDP는 성공했다”라고 정리된 사례는 많지 않지만, 제가 파악하고 있는 범위에서 보면 국내 선도 기업들(빅테크, 금융권, 일부 제조 대기업)은 나름의 **‘한국형 골든패스’**를 이미 실무적으로 만들어 쓰고 있다고 보는 편이 더 정확해 보입니다.
흥미로운 점은, 국내에서 개발자 만족도가 비교적 높다고 평가받는 IDP들이 공통적으로 **‘포털’이라기보다는 ‘복잡한 내부 절차를 잘 감춘 서비스’**에 가깝다는 점입니다.
예를 들면 토스나 카카오뱅크의 경우, 강한 보안 규제와 금융권 통제 환경 속에서도 인프라 할당부터 배포까지의 과정을 최대한 단순화하는 데 집중해 왔습니다. 토스가 여러 발표를 통해 강조해 온 것처럼, 개발자가 반드시 쿠버네티스 명세나 인프라 구조를 깊이 알지 않아도 서비스를 배포할 수 있도록 추상화 수준을 높인 것이 핵심이었습니다. 기술적으로 보면 대단히 새로운 것이 아닐 수 있지만, 내부 절차를 엔지니어링으로 정리했다는 점에서 의미가 컸다고 봅니다.
제조업 쪽에서는 현대자동차 사례가 자주 언급됩니다. 이 경우는 개발자 경험이라는 표현보다는, 파편화된 도구와 환경을 통합해 SI 협력사 인력까지 포함한 전체 개발·운영 흐름을 표준화하려는 목적이 더 강했습니다. 즉, “누가 오더라도 최소한 이 경로로는 바로 개발에 투입될 수 있게 하자”는 관점에서 플랫폼이 설계된 셈입니다.
당근마켓처럼 비교적 조직이 유연한 회사들은 조금 다른 접근을 보여줍니다. 플랫폼 팀이 내부 개발자를 명확한 ‘고객’으로 두고, 반복적으로 나오는 불만과 요구를 흡수해 배포 환경과 운영 방식을 정리해 나가는 전형적인 플랫폼 엔지니어링 흐름에 가깝습니다. 다만 이 역시도 자유로운 선택지를 무한히 열어두기보다는, 잘 닦인 표준 경로를 제공하는 쪽에 가깝습니다.
이런 사례들을 종합해 보면, 국내에서 말하는 골든패스는 해외에서 이야기하는 “가장 이상적인 선택지”라기보다는, 오히려 **“이 길로 가면 보안 심의, 운영 승인, 감사 대응까지 자동으로 해결된다”**는 의미에 더 가깝습니다. 자율과 선택을 강조하기보다는, 조직 현실 속에서 사고를 줄이고 마찰을 최소화하는 경로를 명확히 제시하는 방식입니다.
특히 SI 구조상 인력 교체가 잦고 역할 경계가 흐릿한 환경에서는, 사람의 판단이나 승인에 의존하는 프로세스를 줄이고 이를 자동화된 워크플로우로 바꾸는 것이 IDP의 핵심 가치가 되는 경우가 많습니다. 국내형 IDP에서 Human-in-the-loop을 최소화하려는 경향이 강한 이유도 여기에 있다고 봅니다.
또 하나의 특징은 레거시와의 공존입니다. 신규 클라우드 환경만을 전제로 한 IDP는 현실에서 곧바로 한계를 드러내는 경우가 많고, 실제로는 온프레미스나 기존 시스템과 연결되는 하이브리드 형태의 프로비저닝과 운영 경로를 함께 품고 가는 경우가 대부분입니다.
그래서 IDP 기획을 놓고 보면, 기술 스택이나 Backstage 도입 여부 자체는 생각보다 본질적인 문제가 아닌 경우가 많습니다. 오히려 플랫폼 팀이 내부 개발자들이 실제로 어디에서 시간을 낭비하고 있는지, 어떤 절차에서 가장 큰 피로를 느끼는지를 얼마나 집요하게 파고드는지가 성패를 가르는 경우가 많았습니다.
“우리는 IDP를 도입할 것이다”보다는
“왜 신규 프로젝트 하나 띄우는 데 이렇게 오래 걸리는가”
“왜 로그 한 번 보려면 이렇게 많은 사람을 거쳐야 하는가”
같은 질문에서 출발하는 쪽이 국내 환경에서는 훨씬 설득력이 있어 보입니다.
처음부터 거대한 플랫폼을 만들기보다는, 가장 반복적이고 귀찮은 업무 하나를 자동화해 개발자들이 체감할 수 있는 변화를 만드는 것이 신뢰를 얻는 데 훨씬 효과적이기도 합니다. 그리고 이런 플랫폼은 만들고 끝나는 것이 아니라, 내부에서 계속 설명하고 설득하고 개선해 나가야 하는 성격의 ‘제품’에 가깝습니다.
결국 국내 환경에 최적화된 IDP는 하나의 소프트웨어라기보다는, 조직이 일하는 방식을 기술로 정리하고 고정해 가는 과정에 가깝다고 생각합니다. 고객사에도 기술적인 완결성보다는, 개발 시간 단축이나 운영 리소스 감소처럼 바로 체감 가능한 가치를 중심으로 이야기하시는 쪽이 현실적으로 도움이 될 것 같습니다.
@jhkwon91 국내 기업 사례를 잘 설명해주셔서 감사합니다. 저도 SI만 오래하다보니 재환님의 의견에 동의합니다. 답변주신 국내 사례와 함께 해외에서 또는 표준으로 얘기되고 있는 backstage 등의 장점을 최대한 접목할 수 있다면 좋을거 같다는 생각은 합니다. 사례 소개에 너무 감사합니다. 재환님은 아콘에 계시는군요. ^^
@jhkwon91 @cvnrainland Bro님의 질문/답변에 감사합니다.
안녕하세요.
저는 삼성전자 반도체에서 devsecops 구축을 하고 있는데요.
저희는 2022년부터 idp를 만들고 있습니다.
올해 저희 파트분들이 kubernetes community days 2025에서 관련 내용을 발표하였는데요.
설명보다는 직접 보시면 참고 많이 되실것 같습니다~
기업 내 idp가 많이 만들어 졌으면 좋겠네요~
혹시 궁금하신것은 연락주시면 아는한 도와드리겠습다~
