Metlivi 블로그

요구가 강한 이해관계자에게 대응하는 방법: 관계 유지와 프로젝트 경계의 균형

영향력 있는 이해관계자가 새로운 요구를 하면 원하는 결과부터 확인합니다. 승인된 계획과 비교해 추가 작업이 무엇을 바꾸는지 설명하고, 실제 결정 권한을 가진 사람에게 선택지를 전달하세요. 충분히 듣는 것과 납품을 약속하는 것은 별개의 행동입니다. 제때 답하고 정확히 이해하며 후속 상황을 알리는 것도 협업 관계를 유지하는 방식입니다.

2026년 9월 07일5분관계와 삶의 단계작성: Metlivi Editorial Team
섹션 1

강한 표현을 구체적인 요청으로 바꾸세요

“반드시 넣어야 합니다”만으로는 작업 내용을 정하기 어렵습니다. 누가 어떤 상황에서 사용할지, 없으면 이미 합의한 어떤 결과에 영향이 있는지 물어보세요. 기존 요구의 설명인지, 원래 약속에 미달한 결과의 수정인지, 새로운 범위의 추가인지 구분합니다. 약속했지만 완료하지 않은 작업을 새 요청으로 바꾸면 안 됩니다.

여기서 강하다는 표현은 현재의 영향력이나 말하는 방식을 뜻하며 인격을 평가하지 않습니다. 요청과 이유, 결정을 원하는 시점을 기록하세요. 한 가지 구현 방법만 제시되었다면 다른 방식으로도 같은 목적을 달성할 수 있는지 확인합니다.

섹션 2

현재 합의를 기준으로 영향을 설명하세요

확인된 범위와 일정, 인수 기준을 열고 추가되거나 달라지는 작업과 영향을 받는 약속을 적습니다. 시간이나 자원을 아직 평가하지 않았다면 미평가 상태라고 명확히 표시합니다. 대화를 이어 가기 위해 정확해 보이는 숫자를 만들어 내지 마세요. 단순히 바쁘다고 말하면 무엇을 선택해야 하는지 드러나지 않습니다.

APM은 승인된 계획의 변경을 기록하고 평가한 뒤 승인, 거절 또는 연기를 결정하는 절차를 설명합니다. 범위와 품질, 시간, 자원, 비용, 위험 등이 평가 대상입니다. 현재 프로젝트의 절차를 사용하면 되며 작은 프로젝트에 새 위원회를 만들 필요는 없습니다.

섹션 3

비교할 수 있는 선택지를 제시하세요

금요일 공개 예정인 행사 페이지에 신청 통계를 추가해 달라는 상황을 예로 들어 봅시다. 사실을 확인한 뒤 기존 공개 범위를 유지하거나, 이미 승인된 도구로 당장의 정보를 확인하거나, 범위와 날짜를 바꿔 통계를 추가하는 안을 비교할 수 있습니다. 예시가 새 도구나 정보 처리 방식의 사용을 허용하는 것은 아닙니다.

“신청 현황이 필요하다는 점은 이해했습니다. 금요일 버전에는 통계가 없습니다. 추가 작업과 기존 대안을 확인해 내일 오후에 선택지를 알려 드리겠습니다. 지금 말씀드린 것은 검토 회신 시점이지 새 기능의 납품일은 아닙니다”라고 설명할 수 있습니다.

섹션 4

결정자와 의견 제공자를 구분하세요

높은 직급, 강한 주장, 변경 승인 권한은 같은 것이 아닙니다. 현재 책임 분담을 확인하고 불명확하면 프로젝트 책임자에게 권한을 확인해 달라고 요청합니다. Atlassian의 DACI는 결정을 추진하는 사람, 승인자, 전문 의견을 제공하는 사람을 구분합니다. 이 구분을 참고하되 팀을 새로 구성할 필요는 없습니다.

APM의 지속적 협의 원칙은 관계와 경계, 성공 기준, 인계 조건을 명확히 하도록 안내합니다. 상위 담당자와 이야기해야 한다면 기존 프로젝트 후원자의 참여를 요청할 수 있습니다. 적절한 사람에게 정보를 전달하는 것이 목적이지 요청자를 난처하게 하는 절차가 아닙니다.

섹션 5

결정 후 같은 버전을 공유하세요

승인되면 범위, 날짜, 담당자와 인수 기준을 업데이트하고 변경에 의존하는 사람에게 알립니다. 거절하면 현재 이유를, 연기하면 다시 검토할 조건이나 날짜를 남깁니다. 대화의 동의와 작업 시스템의 옛 일정이 동시에 남지 않도록 합니다.

재촉이 이어지면 어떤 검토가 빠졌는지, 누가 결정하지 않았는지, 언제 업데이트할지로 돌아갑니다. 요청의 처리 방향이 분명하고 관계자들이 현재 버전을 알고 있으면 한 단계가 끝난 것입니다. 모두가 선택에 만족해야만 완료되는 것은 아닙니다.

관련 글

이 주제 더 살펴보기