90DaysOfDevOps (Day 88)

고태규·2026년 2월 7일
devops

DevOps

목록 보기
83/87
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 88 - What Developers Want from Internal Developer Portals

1. IDP의 배경

지난 5년 동안 마이크로서비스, 쿠버네티스, 클라우드 등의 기술은 조직의 효율성을 높여주었지만, 동시에 그만큼의 부작용인 복잡성을 초래했다.

  • 마이크로서비스와 쿠버네티스: 병렬 작업을 가능하게 하여 배포 속도를 높였지만, 너무 많은 서비스가 파편화되면서 소유권을 파악하고 전체 생태계를 이해하는 것이 불가능에 가까워졌다.

  • 클라우드 호스팅: 리소스 생성이 쉬워지고 비용이 저렴해졌지만, 이로 인해 정체를 알 수 없는 리소스가 방치되는 Sprawl 현상이 발생했다.

  • 도구의 홍수: 더 빠른 개발을 위해 수많은 도구를 도입했지만, 잦은 컨텍스트 스위칭과 알림 공해로 인해 오히려 개발자의 집중력을 저해하고 있다.


기존 도구들의 한계: Context의 실종

현재 시장의 도구들은 각자의 영역에서는 훌륭하지만, 전체를 꿰뚫는 통찰력을 제공하지 못한다.

  • APM/모니터링 (Datadog 등): Quality를 측정하지만, 해당 서비스가 무엇이며 왜 존재하는지에 대한 맥락은 없다.

  • 엔지니어링 메트릭 (DORA 등): 병목 현상은 알려주지만, 데이터가 정적이라 실제 Action으로 이어지기 어렵다.

  • 워크플로우 도구 (Git, Jira): 프로세스를 관리하지만, 우리가 올바른 방식으로 구축하고 있는지에 대한 가시성은 부족하다.

결국 가장 큰 문제는 이 모든 파편화된 정보를 하나로 연결하여 "이 서비스는 누가 만들었고, 어떤 리소스와 연결되며, 현재 상태는 어떠한가?"를 보여주는 Entity Graph의 부재다.

IDP는 바로 이 끊어진 연결고리를 잇는 역할을 해야 한다.

2. 개발자가 IDP에서 진정으로 원하는 3가지

Cortex가 50명의 엔지니어를 대상으로 "IDP에서 무엇을 원하는가?"를 설문한 결과, 개발자들의 고통과 니즈는 다음 세 가지로 명확히 요약된다.

  1. 정보 탐색의 고통

    • 개발자들은 서비스, 리소스, 인프라 정보가 수십 개의 도구에 흩어져 있어 필요한 정보를 찾는 데 엄청난 시간을 낭비한다.

    • 온보딩의 어려움: 신규 입사자가 전체 시스템 구조를 파악하는 데 오랜 시간이 걸린다.

    • 장애 대응 지연: 한밤중에 모르는 서비스의 알림을 받았을 때, 소유자가 누구인지, Runbook은 어디에 있는지 찾을 수 없다.

    • 협업의 장벽: 내 기능이 다른 팀의 서비스와 상호작용할 때, 누구와 소통해야 하는지 파악하기 어렵다.

  2. 우선순위의 불명확성

    • 보안(Snyk), 모니터링(Datadog), 기획(Jira), 코드 품질(SonarQube) 등 사방에서 알림과 요구사항이 쏟아진다.

    • 이 소음 속에서 개발자는 "지금 당장 내가 무엇을 먼저 처리해야 하는가?"를 판단하기 어렵다.

    • 개발자는 주관적인 판단이 아닌, 조직 차원의 명확한 우선순위 가이드를 원한다.

  3. 템플릿과 셀프 서비스

    • 개발자가 꼽은 IDP의 가장 필요한 기능 1위는 템플릿(Templates)이다.

    • 개발자는 새로운 프로젝트를 시작할 때마다 복잡한 초기 설정을 반복하고 싶어 하지 않는다.

    • 조직의 Best Practice가 이미 적용된 골든 패스(Golden Path)를 통해, 버튼 클릭 몇 번으로 즉시 개발 가능한 환경을 구축하기를 원한다.

3. Cortex의 해법: 실행 가능성 중심의 기능

개발자 포털이 실패하는 가장 큰 이유는 정보의 무덤이 되기 때문이다.

Cortex는 정보 제공을 넘어 그래서 지금 무엇을 해야 하는가?에 대한 답을 주고, 개발자가 즉시 행동할 수 있도록 돕는 5가지 핵심 기능을 제공한다.

  1. 기록 시스템 (System of Record)과 자동 발견

    • 많은 조직이 엑셀이나 Wiki에 서비스 목록을 수동으로 정리하지만, 이는 금방 낡은 데이터가 된다. Cortex는 이를 자동화한다.

    • 진실의 원천 (Source of Truth): Cortex는 기존 도구(Jira, GitHub, Snyk 등)를 대체하지 않는다. 대신 50개 이상의 도구와 연동하여 현재 상태가 가장 정확한 데이터를 실시간으로 가져온다. 팀 정보는 HR 시스템(Workday)에서, 보안 정보는 보안 도구(Snyk)에서 가져와 하나로 합친다.

    • 자동 발견: 개발자가 일일이 "이 서비스는 제가 만들었어요"라고 입력할 필요가 없다. Cortex가 도구 간의 관계를 분석하여 "이 GitHub 레포지토리는 저 쿠버네티스 클러스터에 배포되어 있고, 소유권은 A팀에게 있다"는 의존성 그래프를 자동으로 생성하고 최신 상태로 유지한다.

  2. 강력한 쿼리 빌더

    • 수집된 데이터가 단순히 쌓여만 있으면 의미가 없다. Cortex는 흩어진 데이터를 조합하여 복잡한 질문에 즉시 답할 수 있는 능력을 제공한다.

    • 복합 질문 해결: 과거에는 보안팀, 인프라팀, 개발팀에게 각각 물어봐야 했던 질문을 한 번에 해결한다.

    • 실전 예시:

      • "Log4j 취약점 버전이 포함된 라이브러리를 쓰면서(보안), 최근 24시간 동안 배포되지 않은(인프라) 서비스 목록을 줘."

      • "개인정보(PII)가 포함된 DB를 사용하는데(데이터), 백업 설정이 없는(인프라) 위험한 서비스는 어디인가?"

  3. 스코어카드(Scorecards)와 게임화

    • 조직의 표준을 지키라고 강요하는 대신, 게임처럼 레벨을 올리도록 유도하는 기능이다. 리더십에게는 현황판이 되고, 개발자에게는 명확한 가이드가 된다.

    • 표준의 자동화: 배포 전 체크리스트 같은 문서를 자동화된 규칙으로 만든다. 사람이 검사하는 것이 아니라, 시스템이 데이터(테스트 커버리지, 보안 점수 등)를 보고 자동으로 점수를 매긴다.

    • 단계별 성숙도: 등급을 나누어 동기를 부여한다.

      • 🥉 브론즈 (기본): 서비스 소유자가 등록되어 있고, Readme 파일이 있는가?

      • 🥈 실버 (중간): 유닛 테스트가 자동화되어 있고, 당번(On-call) 로테이션이 설정되어 있는가?

      • 🥇 골드 (최상): SLO(서비스 수준 목표)를 추적하고 있으며, 치명적인 취약점이 0개인가?

    • 리더십 리포팅: 경영진은 "우리 조직의 서비스 건전성이 지난달 대비 얼마나 좋아졌는가?", "어떤 팀이 리스크가 가장 높은가?"를 데이터로 한눈에 파악할 수 있다.

  4. Self-Service와 스캐폴더(Scaffolder)

    • 개발자가 가장 원하는 기능 1위

    • 새로운 프로젝트를 시작할 때, 고민하지 않고 버튼 하나로 완벽한 환경을 만드는 것

    • 스캐폴더 (Scaffolder): 발판이라는 뜻처럼, 프로젝트의 뼈대를 자동으로 만들어준다. 오픈 소스인 쿠키커터(Cookiecutter)를 기반으로 하여 보일러플레이트(기본 코드) 생성을 자동화한다.

    • 피드백 루프와 골든 패스: 단순히 코드만 생성하는 게 아니다. Cortex의 템플릿을 사용하면 Git 저장소 생성 + 기본 코드 작성 + 카탈로그 등록이 한 번에 끝난다.

    • 동기 부여: 개발자에게 "이 템플릿을 쓰면, 스코어카드에서 자동으로 실버등급을 달성합니다"라고 안내한다. 개발자는 편해서 좋고, 조직은 자연스럽게 표준을 준수시킬 수 있다.

  5. 개발자 홈페이지와 플러그인

    • 개발자에게 불필요한 알림을 줄이고, 나에게 중요한 정보만 보여주는 개인화된 공간이다.

    • 개인화된 대시보드: 로그인하자마자 "내가 당번인가?", "내가 리뷰해야 할 코드는 무엇인가?", "내 서비스 점수는 몇 점인가?"를 보여준다. 또한 Slack 등으로 "지금 이것부터 처리하세요"라고 넛지(Nudge, 부드러운 개입)를 보내 행동을 유도한다.

    • 플러그인 아키텍처: Cortex가 기본으로 제공하지 않는 기능도 문제없다. React/TypeScript를 사용해 조직 고유의 도구를 포털 안에 심을 수 있다. (예: 사내 전용 배포 UI나 K8s 제어판을 포털 메뉴로 통합).

4. 성공적인 IDP 도입을 위한 4단계 로드맵

IDP 도입에 실패하는 가장 큰 이유는 데이터 없이 셀프 서비스부터 구축하려 하기 때문이다.

Cortex는 다음의 순서로 도입할 것을 강력히 권장한다.

1단계: 정보 수집 및 집계 (Inventory & Aggregation)

  • 가장 먼저 무엇이 존재하는지를 파악해야 한다.

  • 서비스, 인프라, 리소스, 소유권 정보를 긁어모아 카탈로그를 구축하라.

  • 현재 상태를 모르면 개선할 수 없다.

2단계: 평가 및 목표 설정 (Assess & North Star)

  • 데이터가 모였다면 우리는 어디에 있는가?를 평가해야 한다.

  • 조직이 중요하게 생각하는 가치(신뢰성, 보안, 생산성 등)에 대한 Baseline을 설정하고, 목표를 정하라.

3단계: 조치 처방 (Prescribe Action)

  • 목표 대비 현재의 격차를 파악했다면, 개발자에게 무엇을 해야 하는지 알려주어야 한다.

  • 스코어카드나 우선순위 알림을 통해 개발자가 집중해야 할 작업을 명확히 제시하라.

4단계: 경험 최적화 (Optimize Experiences)

  • 마찰이 발생하는 지점이 명확해졌을 때 비로소 셀프 서비스를 도입하라.

  • 예를 들어, "SLO 설정이 어렵다"는 데이터가 나오면 그때 SLO 설정 자동화 템플릿을 제공하는 식이다.

결론: 플라이휠(Flywheel) 효과

  • 이 과정을 거치면 측정 -> 평가 -> 조치 -> 최적화라는 피드백 루프가 형성된다.

  • 이 루프가 반복될수록 IDP는 단순한 도구를 넘어 조직의 생산성을 지속적으로 가속화하는 플라이휠이 된다. 이것이 바로 성공적인 조직들이 IDP를 통해 가치를 창출하는 방식이다.

5. 정리 및 결론

성공적인 내부 개발자 포털(IDP)은 플랫폼 팀의 관점이 아닌, 실제 사용자인 개발자의 핵심 니즈(정보 탐색, 우선순위 명확화, 템플릿)에서 출발해야 한다.

Cortex는 단순한 정보 통합을 넘어, 스코어카드와 스캐폴딩을 통해 개발자가 데이터를 보고 즉시 행동(Action)할 수 있는 실행 가능한 환경을 제공하는 데 초점을 맞춘다.

조직은 무작정 기능을 도입하기보다 정보 수집 → 평가 → 조치 처방 → 경험 최적화의 단계적 접근을 통해 선순환 피드백 루프를 형성해야 한다.

결국 IDP는 단순한 관리 도구가 아니라, 조직의 엔지니어링 문화를 성숙시키고 생산성을 지속적으로 가속화하는 강력한 플라이휠(Flywheel)이 되어야 한다.


profile
고태규
이전 포스트

90DaysOfDevOps (Day 87)

다음 포스트

90DaysOfDevOps (Day 89)

0개의 댓글