경로 06강의 1 / 6

제품보다 책임을 먼저 비교하기

어시스턴트, 내부 소프트웨어 제공 플랫폼, 소프트웨어 팩터리를 비교하세요. 각 선택지가 수행하는 작업과 남는 책임을 파악하세요.

기초10 min검토일

발행 콘텐츠 작성 방식

이해도 확인공급업체가 구현과 테스트 실행을 자동화합니다. 비즈니스 요구사항은 누가 책임질까요?실습하기
공급업체가 구현과 테스트 실행을 자동화합니다. 비즈니스 요구사항은 누가 책임질까요?

학습할 내용

  • 같은 목표 결과를 기준으로 선택지를 비교합니다.
  • 작업 수행과 그 결과에 대한 책임 수락을 구분합니다.
  • 제안된 운영 모델에서 책임의 공백과 중복을 찾습니다.

같은 결과를 비교하세요

프로토타입 도구의 선택이 프로덕션 운영 모델까지 결정할 필요는 없습니다. 사람들은 자기 업무에 맞는 도구로 아이디어를 탐색할 수 있습니다. 그래도 조직에는 유용한 결과물을 안전하게 배포하고 유지보수하고 운영할 수 있는 지원 체계가 필요합니다.

코딩 어시스턴트, 내부 플랫폼, 소프트웨어 팩터리는 문제의 서로 다른 부분을 해결할 수 있습니다. 범위를 정하지 않고 구독료만 비교하면 잘못된 결정을 내릴 수 있습니다.

목표 결과부터 정하세요. 회사의 데이터, 보안, 신뢰성 요구사항에 따라 내부 서비스를 제공하고 운영하는 것입니다. 그런 다음 수명주기 전반에 필요한 작업을 파악하세요. 첫 시연이 성공한 뒤의 작업도 포함하세요.

가상의 계약 관리 서비스에는 승인된 요구사항, 직원 접근, 비공개 기록, 검증된 릴리스, 사고 대응, 지속적인 업데이트가 필요합니다. 엔드포인트를 생성하는 도구는 이 목록의 일부를 해결합니다.

가능한 운영 모델 세 가지를 설명하세요

코딩 어시스턴트를 사용하는 경우 개발자는 기존 엔지니어링 시스템 안에서 AI를 사용합니다. 조직이 주변 프로세스, 연동, 플랫폼 기능, 증거 수집을 제공합니다. 성숙한 공통 서비스를 갖춘 조직에 적합할 수 있습니다.

내부에서 소프트웨어 제공 시스템을 조합하는 경우 조직은 에이전트, 맥락, 검사, 배포, 운영 피드백을 통합합니다. 설계를 통제할 수 있지만 통합 제품 자체와 지원, 업그레이드도 책임져야 합니다.

소프트웨어 팩터리를 구매하는 경우 공급업체가 더 넓은 범위를 연결하는 작업 흐름을 제공합니다. 실제 범위와 지원하는 연동을 검증하세요. 조직은 여전히 제품 결정을 내려야 하며 책임 분담을 명확히 해야 합니다.

이는 비교를 위한 모델이지 모든 제품에 적용되는 보편적인 분류가 아닙니다. 개별 공급업체나 내부 플랫폼은 기능을 다르게 조합할 수 있습니다.

프로토타입에서 운영 서비스까지의 경로를 검증하세요

각 선택지에 같은 구체적 시나리오를 사용하세요. 은행 업무 프로토타입에서는 합성 거래 데이터로 시작하고 실제 서비스 권한은 부여하지 마세요. 접근 범위를 넓히기 전에 팀이나 공급업체에 다음 역량을 보여 달라고 요청하세요.

  1. 프로토타입을 평가하고 변경하거나 교체해야 할 코드를 찾습니다.
  2. 정책이 요구하는 경우 조직의 자체 클라우드 계정을 포함해 필요한 인프라에 배포합니다.
  3. 애플리케이션 권한, 비밀 정보 처리, 개발 및 실행 시점의 데이터 흐름을 검증합니다.
  4. 적용되는 요구사항에 대한 증거를 만들고 릴리스 결정을 기록합니다.
  5. 서비스를 모니터링하고 취약점을 수정하며 복구를 테스트하고 사고에 대응합니다.

코드를 조직 계정으로 옮기는 것은 이 작업의 한 부분입니다. 누가 환경을 관리할 수 있고 외부 서비스가 어디에서 데이터를 받는지 검증하세요. 통제를 조직의 의무에 맞추세요. 배포 위치만으로 규정 준수가 입증되지는 않습니다.

한 공급업체가 명시한 경계의 예로 Taiga의 공동 책임 설명을 조직의 책임 분담과 비교하세요. 이 자료는 이 사이트의 발행자가 소유합니다. Taiga를 활성화하기 전에 적용되는 계약과 구성을 검증하세요.

수행, 확인, 결정을 구분하세요

각 활동을 누가 수행하고 결과를 검증하며 그 결과를 수락하는지 기록하세요. 한 주체가 여러 역할을 맡을 수는 있지만, 빈 역할은 책임의 공백입니다.

활동책임 분담에서 확인할 질문
요구사항모호한 비즈니스 규칙을 누가 해결하는가?
데이터 처리수신자와 처리 조건을 누가 승인하는가?
구현수락 후 생성된 코드를 누가 유지보수하는가?
검증증거가 실제 릴리스를 다루는지 누가 확인하는가?
배포누구의 ID가 어느 환경을 변경하는가?
운영서비스가 실패하면 누가 대응하는가?
플랫폼 업데이트의존성이 바뀌면 누가 연동을 조정하는가?

클라우드 서비스도 제공자와 고객 사이에 책임을 나눕니다. 정확한 분담은 서비스에 따라 달라집니다. 이를 근거로 구체적인 책임 분담을 요청하세요. 모든 관리형 제품의 경계가 같다고 가정하지 마세요. AWS 공동 책임.

공백과 중복 작업을 찾으세요

플랫폼 팀이 승인된 배포 경로를 이미 유지하는데 공급업체가 파이프라인을 생성한다고 가정해 보세요. 공급업체가 기존 경로를 사용해야 하는지 결정하세요. 독립적으로 유지하는 두 파이프라인은 통제 충돌과 불필요한 비용을 만들 수 있습니다.

반대로 공급업체는 고객에게 사고 대응팀이 있다고 가정하고, 고객은 운영이 서비스에 포함된다고 생각할 수 있습니다. 사용자가 서비스에 의존하기 전에 이 공백을 해결하세요.

CNCF의 플랫폼 지침은 내부 역량과 관리형 역량을 조합할 수 있도록 합니다. 중요한 질문은 조합한 결과가 명확한 책임 아래 사용자 요구를 충족하는지입니다. CNCF 지침.

구매 결정에 책임 분담을 활용하세요

평가 기록에 책임 분담을 첨부하고 적용되는 계약에서 이를 명확히 하세요. 조직에 남는 작업의 비용을 산정하세요. 구성 요소 사이의 연결을 유지하는 비용도 포함하세요.

더 넓은 범위를 제공하는 공급업체가 통합 작업을 줄이고 수명주기 전반의 증거를 유지한다면 가치가 있을 수 있습니다. 고유한 요구사항 때문에 지속적으로 직접 책임질 이유가 있다면 내부 방식이 가치 있을 수 있습니다. 목표 결과와 검증된 범위를 바탕으로 결정하세요.

실습하기

코딩 어시스턴트, 내부에서 조합한 소프트웨어 제공 시스템, 구매한 소프트웨어 팩터리라는 세 열을 만드세요. 요구사항, 정책, 구현, 검증, 릴리스, 운영, 업데이트를 행으로 추가하세요. 각 활동을 누가 수행하고 검증하고 수락하는지 기록하세요. 알 수 없는 항목을 모두 표시하세요.

워크시트 다운로드(Markdown)
이해도 확인 ↑

계속 학습하기

출처 및 더 읽을 자료

Taiga의 관련 읽을거리