CCAR-P · CHAPTER 06 · D6 STAKEHOLDER COMMUNICATION & LIFECYCLE MANAGEMENT · 14%
설계보다 어려운 합의: 이해관계자와 생애주기를 다루는 법
아무리 정교한 아키텍처도 이해관계자가 이해하지 못하면 승인받지 못하고, 승인받아도 운영으로 이어지지 않으면 가치를 내지 못합니다. 도메인 6은 전체의 14%로, 발견 단계의 요구사항 정리부터 의사결정 전달, 기대 정렬, 문서화, 그리고 운영 이후의 반복까지 — 설계를 조직 안에서 살아 움직이게 만드는 역량을 다룹니다. 상위 아키텍트의 실력은 다이어그램의 완성도가 아니라 이 흐름을 얼마나 끝까지 책임지느냐에서 갈립니다.
6.1 발견 단계 — 답을 모으기 전에 질문을 설계합니다
발견(discovery, 프로젝트 초기에 요구사항과 제약을 끌어내는 단계)은 자유로운 대화가 아니라 설계된 인터뷰입니다. 상위 아키텍트는 현업이 말하는 표면적 요구 뒤의 실제 업무 목표, 데이터 민감도, 응답 지연·비용의 허용선, 성공을 판정할 기준을 구분해 끌어냅니다. 특히 Claude 기반 설계에서는 '무엇을 자동화하고 싶은가'만큼 '틀리면 어떤 비용이 발생하는가'를 초기에 확정해야, 뒤에서 평가(evaluation, 모델 출력이 기준을 만족하는지 판정하는 설계) 범위와 거버넌스 범위가 흔들리지 않습니다. 질문의 순서와 범위를 미리 짜 두면, 빠진 요구사항이 이관 직전에 드러나는 상황을 막습니다.
실무 예시
국내 손해보험사의 보험금 심사 자동화를 맡은 솔루션 아키텍트라면, '심사를 빠르게'라는 요청을 곧바로 설계로 옮기지 않습니다. 오심사 한 건의 재작업·민원 비용, 규제상 심사역이 최종 승인해야 하는 구간, 과거 심사 자료의 편향 가능성을 먼저 인터뷰로 확정한 뒤에야, 어디까지 Claude가 초안을 잡고 어디부터 심사역이 판단할지 경계를 그립니다.
6.2 결정과 절충을 설명합니다 — 선택하지 않은 길까지
아키텍트의 결정에는 반드시 포기한 대안이 따라옵니다. RAG(retrieval-augmented generation, 외부 지식을 검색해 답변에 붙이는 방식)를 택했다면 파인튜닝을 왜 접었는지, 응답 품질을 위해 지연과 비용을 얼마나 감수했는지를 함께 말해야 결정이 신뢰를 얻습니다. 이때 청중에 따라 언어를 바꿉니다 — 경영진에게는 비용·리스크·일정으로, 엔지니어에게는 구조와 실패 모드로 같은 결정을 번역합니다. ADR(architecture decision record, 결정의 배경·대안·근거를 한 장으로 남기는 기록)처럼 결정을 남겨 두면, 몇 달 뒤 '왜 이렇게 했나'라는 질문에 담당자의 기억이 아니라 문서가 답합니다.
실무 예시
유통 대기업의 사내 문서 검색 도우미를 설계하며 컨텍스트 윈도우(context window, 모델이 한 번에 참고하는 정보의 범위)에 전체 문서를 넣는 대신 검색 기반 구조를 택했다면, 테크리드에게는 토큰 비용과 정확도 곡선으로 설명하고, 임원 보고에서는 '문서가 늘어도 월 비용이 선형으로 폭증하지 않는 구조'라는 한 문장으로 같은 결정을 전합니다.
6.3 기대를 맞추고 피드백을 순환시킵니다 — SLA는 약속을 숫자로 바꾼 것
생성 모델은 같은 질문에도 다른 문장을 내놓을 수 있어, '100% 정확'이라는 기대는 처음부터 관리해야 합니다. 상위 아키텍트는 막연한 만족도 대신 측정 가능한 약속으로 기대를 고정합니다. SLA(service level agreement, 서비스 수준을 수치로 합의한 문서)에는 응답 지연의 상한, 가용성, 정확도 판정 기준, 그리고 기준을 벗어났을 때의 대응 경로를 담습니다. 피드백은 한 번의 시연으로 끝나지 않고, 짧은 주기로 결과를 함께 검토하며 프롬프트와 평가 기준을 조정하는 순환으로 설계합니다. 무리한 약속을 피하는 것 자체가 신뢰를 지키는 설계입니다.
실무 예시
공공기관 민원 응대 초안 생성 시스템을 납품하는 아키텍트라면, '틀린 답을 절대 안 한다'가 아니라 '초안은 항상 담당 주무관이 검토 후 발송하며, 정해진 위험 범주의 질문은 자동으로 담당 주무관에게 넘긴다'를 SLA로 합의합니다. 2주 주기로 실제 민원 표본을 함께 검토해 자동 처리 범위를 조금씩 넓히는 것도 같은 합의에 담습니다.
6.4 구현으로 이어지는 문서를 남깁니다
문서의 목표는 아름다움이 아니라 '다른 팀이 이 문서만으로 구현을 이어갈 수 있는가'입니다. 상위 아키텍트는 구성도와 함께, 프롬프트 설계 원칙, 도구(tool, 모델이 외부 기능을 호출하는 연결) 정의, 실패했을 때의 대체 동작, 평가 항목과 합격선을 구현 지침으로 남깁니다. 추상적 원칙만 있는 문서는 곧 해석 차이로 갈라지므로, 대표 입력과 기대 출력 예시를 함께 실어 모호함을 줄입니다. 좋은 문서는 회의 없이도 질문에 답하고, 담당자가 바뀌어도 설계 의도가 살아남게 합니다.
실무 예시
제조 대기업 품질팀에 이상 리포트 요약 기능을 이관하는 엔지니어라면, 시스템 프롬프트 전문과 함께 '요약에 수치가 없으면 원문 링크를 붙인다' 같은 규칙, 모델이 애매할 때의 처리 순서, 그리고 합격으로 볼 요약 예시 다섯 건을 문서에 실어, 받는 팀이 곧바로 자체 검증을 돌릴 수 있게 합니다.
6.5 발견에서 반복까지, 생애주기를 끝까지 함께합니다
설계는 배포로 끝나지 않습니다. 발견·설계·이관·관찰·반복은 한 방향의 직선이 아니라, 운영에서 나온 신호가 다시 설계로 돌아오는 순환입니다. 이관(handoff)은 문서를 넘기고 손을 떼는 순간이 아니라, 받는 팀이 스스로 운영할 수 있을 때까지 함께 서는 구간입니다. 배포 후에는 응답 품질의 변화, 비용 추세, 새로운 질문 유형을 관찰하고, 모델이 바뀌거나 업무가 늘면 프롬프트와 평가 기준을 다시 손봅니다. 상위 아키텍트는 이 순환을 처음부터 전제로 설계해, 첫 버전이 완벽하지 않아도 조직이 스스로 개선해 나갈 구조를 남깁니다.
실무 예시
금융 지주사의 내부 규정 질의응답 시스템을 6개월간 운영 이관하는 아키텍트라면, 초기 3개월은 자사 엔지니어가 관찰 지표를 함께 읽고, 이후 3개월은 고객사 담당자가 주도하며 아키텍트는 확인만 합니다. 새 규정이 추가될 때 어떤 절차로 지식과 평가를 갱신하는지까지 이관 계획에 담아, 담당자가 바뀌어도 시스템이 낡지 않게 합니다.
! 흔한 함정
- 발견을 건너뛰고 기술부터 정하는 것 — 현업의 첫 요청을 요구사항으로 착각하면, '왜, 틀리면 무엇을 잃는가'를 확인하지 않은 채 잘 만든 시스템이 엉뚱한 문제를 풉니다.
- SLA를 정성적 약속으로 두는 것 — '정확하게', '빠르게' 같은 형용사로 합의하면, 측정 기준과 이탈 시 대응이 빠져 나중에 분쟁의 씨앗이 됩니다.
- 청중을 하나로 가정하는 것 — 경영진 보고와 엔지니어 설명에 같은 자료를 쓰면, 결정은 하나여도 전달 언어가 청중과 어긋나 설득에 실패합니다.
- 이관을 문서 전달로 오해하는 것 — 문서만 넘기면 끝났다고 보지만, 받는 팀이 스스로 운영·개선할 수 있을 때 비로소 이관이 완료됩니다.
HANDS-ON 이해관계자의 기대를 현실에 맞추는 일은 Claude의 실제 능력과 한계를 함께 이해하는 데서 시작합니다 — byteforce learn의 claude-101로 그 공통 언어를 먼저 세우면, 발견 인터뷰와 SLA 합의가 훨씬 단단해집니다. learn으로 →
Q 확인 퀴즈
한 시중은행의 여신 심사 지원 시스템을 맡은 솔루션 아키텍트입니다. 현업 부서는 "심사 속도를 높여 달라"는 한 문장으로 요구를 전달했고, 일정도 넉넉하지 않습니다.
발견(discovery, 프로젝트 초기에 요구사항과 제약을 끌어내는 단계)에서 이 아키텍트가 가장 먼저 해야 할 일로 적절한 것은?