CPN 한국어 자습서 · Claude Certified Developer — Foundations Prep
5-4 · 요구사항과 생애주기
Requirements & Lifecycle
이어지는 레슨의 배포 결정은 요구사항이 이미 정리돼 있다고 전제합니다 — 데이터를 어디서 처리할지, 응답이 얼마나 빨라야 할지, 누가 어떤 자격으로 접근할지. 이 레슨에서는 그 요구사항이 어디에서 오는지부터 살펴봅니다. 비즈니스 문제를 확인할 수 있는 기능·인프라 요구사항으로 옮기고, 이렇게 정리한 요구사항을 시스템 생애주기 안에 배치하는 두 단계를 차례로 다룹니다.
이 장에서 배우는 것What you'll learn
약 20분비즈니스 문제와 요구사항의 차이, 그리고 요구사항을 끌어내는 순서
기능 요구사항 — 시스템이 무엇을 해야 하는지 확인할 수 있게 적기
인프라 요구사항 네 갈래 — 응답 속도·처리량·데이터 처리 위치·접근 주체
결정을 뒷받침하도록 요구사항을 기록하는 이유
요구사항부터 개선까지 이어지는 시스템 생애주기 일곱 단계
단계 사이의 게이트 — 시험과 배포를 나눠서 보기
이후 레슨에서 다루는 배포 플랫폼 결정은, 요구사항이 이미 손에 있다고 전제하고 출발합니다. 그렇다면 그 요구사항 자체는 어디에서 올까요. 시작점은 비즈니스 문제입니다. 이 문제를, 나중에 배포 결정을 설명할 근거가 될 기능 요구사항과 인프라 요구사항으로 옮기는 것이 이 절의 주제입니다.
기능 요구사항은 시스템이 무엇을 해야 하는지를, 확인할 수 있을 만큼 구체적으로 적은 문장입니다. "상담원이 더 빨리 답하도록 돕고 싶다" 같은 비즈니스 문제는 아직 요구사항이 아닙니다. 기능 요구사항은 여기에서 끌어냅니다 — 예를 들어 "티켓을 네 개의 처리 흐름 중 하나로 분류한다", "관련 정책을 인용해 답변 초안을 만든다", "사람의 승인 없이는 자동 발송하지 않는다"처럼요. 요령은 각 항목을 확인할 수 있는 행동 문장으로 적는 것입니다. 두루뭉술한 목표는 설계의 기준으로도, 검증의 기준으로도 삼기 어렵습니다. 반면 구체적인 문장은 그대로 이밸(자동 평가)의 한 항목이 되고, 리뷰 때 판단 기준이 됩니다.
인프라 요구사항은 배포가 만족해야 하는 제약 가운데 기능이 아닌 쪽입니다. 대부분은 비즈니스 문제에 직접 적혀 있지 않습니다. 대신 비즈니스 문제에 담겨 있는 질문을 던져서 끌어냅니다.
응답 속도·처리량·데이터 처리 위치·접근 주체, 이 네 가지가 배포 플랫폼을 결정짓는 가장 흔한 인프라 요구사항입니다. 그리고 이런 제약은 다른 이유로 플랫폼이 정해지기 전, 맨 처음에 정리해 두기가 가장 쉽습니다.
요구사항을 적어 두는 이유는, 배포 결정을 나중에 검토하는 사람들이 요구사항을 직접 모은 사람이 아니기 때문입니다. 기능 동작, 인프라 제약, 그리고 각 제약이 어떤 규제에서 나왔는지를 짧게 정리한 요구사항 기록이 있으면, 플랫폼 선택을 "익숙해서 골랐다"가 아니라 "요구사항에서 따라 나온 결정"으로 설명할 수 있습니다. 이 기록이 다음 단계인 배포 결정이 읽어 들이는 입력이 됩니다.
FIT · 요구사항을 먼저 뽑는 접근이 언제 맞는가
| 잘 맞는 경우 | 플랫폼을 고르기 전에, 비즈니스 문제를 확인 가능한 기능·인프라 요구사항으로 옮겨 둘 때. |
|---|---|
| 비용·복잡도 | 인프라 제약을 미리 끌어내려면, 팀이 건너뛰고 싶어 하는 범위 정리 대화가 한 번 필요합니다. |
| 다른 방법이 나은 경우 | 리뷰도 규제 대상 데이터도 없는 일회용 시제품이라면, 가벼운 메모만으로 충분합니다. |
비즈니스 문제는 "이걸 하고 싶다"는 바람이고, 요구사항은 "그러려면 시스템이 이걸 이렇게 한다"로 옮겨 적은 것입니다. 확인할 수 있게 적어 두면, 나중에 왜 이 플랫폼을 골랐는지 설명할 근거가 남습니다.
규제를 받는 유럽연합(EU)의 한 은행이, 고객 통화 녹취를 상담팀을 위해 요약해 주는 에이전트를 만들려고 합니다. 요약은 사람이 검토한 뒤 EU 안에서 저장됩니다. 이 상황에서 어떤 문장이 기능 요구사항이고 어떤 문장이 인프라 요구사항인지 골라 봅니다. 정답을 먼저 떠올려 본 뒤 골라 보세요. 맞히면 설명이 나옵니다.
Q1위 상황에서 올바른 기능 요구사항은 무엇일까요?
정답은 두 번째 보기입니다. "사람이 승인한 뒤 저장된다"는 확인할 수 있는 행동이고, 특정 업무 절차 제약(사람이 검토하는 단계)에 묶여 있습니다. "빠르고 정확하게"는 확인 기준으로 삼기 어렵습니다. 나머지 둘 — 클라우드 제공사와 데이터의 EU 이탈 금지 — 은 인프라 요구사항이지 기능 요구사항이 아닙니다.
Q2같은 상황에서 올바른 인프라 요구사항은 무엇일까요?
정답은 세 번째 보기입니다. "데이터를 EU 안에서 처리한다"는 확인할 수 있고, 특정 규제상 제약(데이터 처리 위치 규정)에 묶여 있습니다. "곧바로 활용할 만큼 빠르게"는 확인 기준으로 삼기 어렵습니다. 프롬프트 틀은 인프라 제약이 아니라 설계 선택이고, 사람이 검토한다는 문장은 인프라가 아니라 기능 요구사항입니다.
방금 정리한 요구사항은 더 긴 흐름의 첫 단계입니다. 이 절에서는 그 흐름을 시스템 생애주기라는 이름으로 짚어 봅니다. 이렇게 이름을 붙여 두면, 이 모듈의 나머지에서 다루는 배포·버전 관리·경계 설정 작업이 서로 무관한 일처럼 흩어지지 않고 저마다 맞는 단계에 자리를 잡습니다.
Claude 애플리케이션도 다른 엔지니어링 시스템과 같은 생애주기를 지나갑니다. 각 단계에 모델 관련 작업을 얹으면 이렇게 됩니다.
LIFECYCLE · 일곱 단계
| Requirements | 요구사항 — 기능·인프라 요구를 정리한다. |
|---|---|
| Design | 설계 — 플랫폼·모델·신뢰 경계(어디까지 믿고 맡길지의 선)를 고른다. |
| Build | 구축 — 에이전트·도구·프롬프트를 작성한다. |
| Test | 시험 — 이밸과 단위·통합·전 구간 점검을 실행한다. |
| Deploy | 배포 — 버전을 고정하고, 이밸 통과를 조건으로 승격을 연다. |
| Operate | 운영 — 비용·지연 시간·오류를 측정하고, 정해 둔 안전 한계를 지킨다. |
| Iterate | 개선 — 운영에서 나온 결과를 다시 요구사항으로 돌려보낸다. |
이 단계들은 앞선 모듈들이 하나씩 따로 가르쳐 온 바로 그 작업들입니다. 이걸 하나의 생애주기로 묶어서 보면, 단계들이 서로 어떻게 이어지는지가 드러납니다.
게이트는 한 단계에서 다음 단계로 넘어가도 되는지 판단하는 결정 지점입니다. 규제가 걸린 프로젝트에서 통제력을 유지하는 자리이기도 합니다. 플랫폼이 데이터 처리 위치 규정을 만족하기 전에는 설계에서 구축으로 넘어가지 않습니다. 새 버전이 고정해 둔 기준선(baseline) 대비 이밸을 통과하기 전에는 배포에서 실제 프로덕션으로 넘어가지 않습니다. 각 작업을 맞는 단계에 두고 게이트를 건너뛰지 않는 것 — 이것이 Claude 애플리케이션을 언제든 다시 살펴볼 수 있는 상태로 유지하는 방법입니다.
FIT · 단계마다 게이트를 두는 접근이 언제 맞는가
| 잘 맞는 경우 | 엔지니어링 작업 하나하나를, 정해진 산출물과 게이트를 갖춘 생애주기 단계에 배치할 때. |
|---|---|
| 비용·복잡도 | 단계 사이에 게이트를 두면, 마감에 쫓기는 팀이 건너뛰고 싶어 하는 점검 지점이 늘어납니다. |
| 다른 방법이 나은 경우 | 일회성 실험이라면 여러 단계를 하나로 합쳐도 되지만, 규제가 걸린 배포에서는 그러기 어렵습니다. |
생애주기는 "어느 작업을 언제 하는지"를 정리한 지도라고 보면 됩니다. 같은 일이라도 어느 단계에 두는지에 따라, 그 앞뒤에 어떤 게이트가 필요한지가 달라집니다.
이번에는 각 작업이 생애주기의 어느 단계에 속하는지 골라 봅니다. 단계는 요구사항 · 설계 · 시험 · 배포 · 운영 다섯 가지입니다. 정답을 먼저 떠올린 뒤 골라 보세요.
Q1전체 모델 ID를 고정하고, 이전 버전을 남겨 두기.
배포 단계입니다. 어떤 모델 버전을 프로덕션에 올릴지 고정하고, 문제가 생겼을 때 되돌아갈 이전 버전을 남겨 두는 일은 배포에서 내리는 결정입니다.
Q2버전이 프로덕션으로 가기 전에, 이밸 통과를 조건으로 승격을 여는 것.
배포 단계입니다. 이밸 묶음과 채점 기준을 만드는 일은 시험이지만, 그 결과를 조건으로 걸어 승격을 여는 것은 배포의 결정입니다. 시험과 헷갈리기 쉬운 지점이라, 둘을 나눠서 보면 좋습니다.
Q3데이터를 특정 지역에서 처리해야 한다고 정하는 것.
요구사항 단계입니다. 데이터 처리 위치 규정은 규제에서 나오는 제약이라, 플랫폼을 고르기 전에 요구사항으로 정리해 둡니다. 그 규정을 만족하는 플랫폼을 고르는 일은 다음 단계인 설계입니다.
Q4프로덕션에서 호출마다 토큰 비용과 지연 시간을 측정하기.
운영 단계입니다. 실제로 작동 중인 시스템에서 비용·지연 시간·오류를 측정하고 지켜보는 일은 운영에 속합니다.
Q5고객이 규정 준수 체계를 Amazon Bedrock에 두고 있어서 Bedrock을 고르는 것.
설계 단계입니다. 요구사항을 만족하는 플랫폼을 고르는 것은 설계 결정입니다. 여기서는 고객의 규정 준수 체계가 이미 Bedrock에 있다는 점이 그 선택의 근거가 됩니다.
모듈 5의 다음 절은 배포와 버전 관리(Deployment & Versioning)를 다룹니다. → 5-5 · 배포와 버전 관리
전 코스는 계속 무료입니다. 등록하면 이 코스의 남은 38개 레슨을 끝까지 읽을 수 있습니다.
이미 등록하셨다면 그때 쓰신 이메일을 넣어 주세요.