문서를 영문으로 보려면 영문 확인란을 선택하세요. 마우스 포인터를 텍스트 위로 이동시켜 팝업 창에서 영문 텍스트를 표시할 수도 있습니다.
번역
영문

우선 순위 지정

작성: Mitch Lacey. 소유: Mitch Lacey & Associates, Inc(Agile 및 스크럼 도입과 개선 전문 컨설팅 업체)

2012년 1월

이 문서에서 Mitch Lacey는 여러 Agile 팀을 통해 그 유익함이 입증된 세 가지 방법, 즉 Kano의 고객 만족 모델, Luke Hohmann이 제시한 일련의 혁신 게임, Karl Weigers의 의 상대적 가중치 모델을 설명합니다. 이러한 모델을 통해 백로그의 대략적인 우선 순위를 정한 후 위험, 중요성, 고객 만족을 충분히 따져 정확한 순서를 지정할 수 있습니다.

Application Lifecycle Management, Team Foundation Server

이 문서의 내용

Agile 팀의 작업 효율성을 유지하려면 제품 백로그의 항목을 우선 순위별로 정렬한 다음, 프로젝트 진행에 따라 해당 우선 순위를 업데이트해야 합니다. 모든 제품 백로그는 비즈니스 가치와 위험에 따라 우선 순위를 지정해야 합니다. 이 우선 순위 순서를 파악하면 팀은 성공적인 제품 개발에 영향을 줄 가능성이 높은 기능을 중심으로 더욱 효율적인 작업을 수행할 수 있습니다. 이처럼 적합한 순서와 우선 순위가 지정된 백로그는 팀의 효율성과 고객 만족도를 높일 뿐 아니라 사업 성장에도 도움이 됩니다. 백로그에 대한 자세한 내용은 제품 백로그 작성 및 관리, 백로그 만들기, 백로그 정리 및 예상을 참조하세요.

제품 백로그의 순서와 우선 순위를 지정할 때는 여러 요인을 고려해야 할 뿐 아니라 결정 사항이 타당함을 증명할 수 있어야 합니다. 원시 제품 백로그를 시작할 때는 프로세스를 진행하기가 매우 어려워 보일 수도 있지만 백로그의 모든 항목 순서를 즉시 정확하게 지정하지 않아도 됩니다. 즉, 예측에서 설명하는 효율적인 "The Big Wall" 기술을 사용하면 원시 제품 백로그를 신속하게 예상하고 관련자들과 협력하여 대략적인 우선 순위를 지정할 수 있습니다.

이처럼 일단 대략적인 우선 순위만 지정하면 상황에 맞게 프로세스를 시작할 수 있습니다. 그러나 이러한 우선 순위를 세분화하거나 더 과학적인 방식으로 우선 순위가 지정된 백로그를 만들어야 하는 경우도 있습니다. 이 경우에는 여러 가지 기술을 사용할 수 있습니다. 다음 문서에서는 여러 Agile 팀을 통해 그 유익함이 입증된 세 가지 방법, 즉 Kano의 고객 만족 모델, Luke Hohmann이 제시한 일련의 혁신 게임, Karl Weigers의 상대적 가중치 모델을 설명합니다. 이러한 모델을 통해 백로그의 대략적인 우선 순위를 정한 후 위험, 중요성, 고객 만족을 충분히 따져 정확한 순서를 지정할 수 있습니다.

Kano의 고객 만족 모델은 1980년대에 도쿄 Rika 대학의 Noriaki Kano 교수가 개발한 것으로, 필수 특성과 차별화되는 특성 간을 구분하는 간단한 순위 체계를 제공합니다. 설문지 기반 접근 방식인 이 모델을 활용하면 효율적으로 제품 특성을 시각화하고 디자인 팀 내의 활발한 토론을 유도할 수 있습니다.

예제 제품 기능 그래프

Kano 모델에서는 기능과 역기능 형식으로 일련의 질문을 합니다. 고객에게 차량용 GPS 내비게이션 시스템 관련 질문을 하는 경우를 예로 들어 보겠습니다. 먼저 다음과 같은 기능 분야의 질문을 합니다.

  • 이 차량에 GPS 내비게이션 시스템이 있다면 어떨까요?

이 질문에 대한 응답은 다음 항목으로 제한합니다.

  • 좋을 것 같음

  • 반드시 그래야 함

  • 잘 모르겠음

  • 상관없음

  • 좋지 않을 것 같음

이 예제에서는 가상의 고객이 "좋을 것 같음"으로 응답했다고 가정합니다.

다음으로는 역기능 형식의 질문을 합니다.

  • 이 차량에 GPS 내비게이션 시스템이 없다면 어떨까요?

가상의 고객 목록의 대답 중에서 선택할 수 있습니다. 그러나 이 질문의 대답은 기능 형식 질문과 다른 경우가 많으며 일반적으로는 다릅니다. 이 예제에서는 가상의 고객이 역기능 형식 질문에 "반드시 그래야 함"이라고 응답했다고 가정하겠습니다.

실제 프로젝트에서 이 질문을 할 때는 이 목록에 나와 있는 것처럼 서로 반대되는 질문을 여러 고객 그룹, 즉 고객 조직에서 각기 다른 기능을 수행하는 여러 개별 사용자 집합에 대해 제시할 수 있습니다. 마케팅 그룹, 회계 그룹, 제조 그룹 등을 예로 들 수 있습니다. 여기서는 이 모델을 더 쉽게 이해할 수 있도록 고객 그룹 하나에 질문을 하나만 한다고 가정하겠습니다. 기능 및 역기능 형식의 대답 쌍을 컴파일한 후 표 1에 나와 있는 것처럼 표에 매핑합니다.

예제 Kano 매핑

표 1 – Kano 매핑

앞에서 설명한 것처럼 이 예제에서 가상의 고객은 기능 형식 질문에는 좋음으로, 역기능 형식 질문에는 필요함으로 대답했습니다. 이 쌍을 표에 매핑하면 두 특성이 교차하는 위치는 아래 표에서 강조 표시된 노란색 사각형과 같이 E가 됩니다. 그러면 우선 순위가 지정된 백로그에서 이 결과의 의미에 대해 알아보겠습니다.

  • E = 자극 요인. 고객이 예상치 않았지만 실제로 제품을 경쟁업체와 차별화하는 기능입니다. 이러한 기능은 특히 초기에는 식별하기가 어렵습니다. 유용한 기능을 소개하는 질문을 만들기가 어려울 수 있기 때문입니다. 따라서 자극 요인은 대개 프로젝트가 진행되고 고객 피드백이 발생하기 시작하면 생성되어 우선 순위가 높아지는 경우가 많습니다.

    • 고객은 이러한 기능에 크게 만족하며 더 높은 가격을 지불하더라도 해당 기능을 사용하고자 할 가능성이 높습니다. 예를 들어 Apple iPod은 화면 방향에 따라 콘텐츠를 회전하는 직관적 기능을 통해 고객 만족도를 크게 높였습니다. 그러나 고객은 해당 기능을 예상하지 못했으므로 이 기능이 없었어도 고객 만족도가 낮아지지는 않았을 것입니다.

    • 위의 예제에서 GPS 내비게이션은 자극 요인 기능이 됩니다. 최소한 고객 피드백을 받는 시점까지는 이 기능을 개발하는 과정에 비교적 높은 우선 순위를 지정해야 합니다.

  • B = 기본. 제품에 반드시 포함해야 하는 우선 순위가 높은 필수 기능입니다.

    • 이러한 기본적인 특성은 아무리 잘 실행되더라도 고객의 인식이 바뀌지 않습니다. 예를 들어 워드 프로세서에는 "문서 만들기"와 "문서 저장" 기능이 반드시 필요합니다. 고객은 해당 기능을 사용하기 위해 제품을 구입하기 때문입니다.

    • 고객에게 안전벨트 관련 질문을 하는 경우 대부분의 고객은 신차에는 안전벨트가 반드시 필요함으로, 그리고 안전벨트가 없으면 좋지 않음으로 대답할 것입니다. 표에서 이 두 대답을 매핑하면 안전벨트는 필수 기능인 기준(B)임을 확인할 수 있습니다.

  • L = 직접 연관. 성능 요구 사항이라고도 하는 직접 연관 기능은 고객 만족도와 직접 연관됩니다. 이러한 기능은 우선 순위 면에서는 기본 기능보다 낮지만 비용에 따라 적절하게 조정해야 합니다.

    • 실행 품질이 향상되거나 기능이 증가하면 고객 만족도도 높아집니다. 반면 기능이 감소하면 만족도도 낮아집니다.

    • 제품 가격은 이러한 특성과 관련되는 경우가 많습니다.

  • I = 부수. 이러한 기능은 고객 대상 중요도가 가장 낮으므로 제품에 대한 중요도도 가장 낮아야 하며, 비즈니스 가치를 거의 또는 전혀 제공하지 않습니다.

표 1에는 Q와 R도 나와 있습니다.

  • Q: 의심 – 질문이 잘못되었거나 대답이 명확하지 않습니다.

  • R: 모순 – 대답 조합이 적합한 항목으로 계산되지 않습니다. 위의 GPS 내비게이션 시스템 예제에서 고객이 내비게이션이 필요하다고 대답하는 동시에 좋지 않다고 대답하면 해당 대답에는 R이 지정됩니다.

대답 쌍의 등급이 Q나 R로 지정된 경우에는 질문 또는 대답 쌍을 더 면밀하게 확인해야 합니다.

혁신 게임은 기본적인 시장 조사를 개발하는 데 사용할 수 있는 도구입니다. 고객은 이러한 도구를 통해 "게임"을 하여 제품이나 서비스에 대한 피드백과 의견을 입력합니다. Luke Hohmann의 저서인 Innovation Games에는 이와 같은 12가지 게임에 대한 자세한 설명이 나와 있습니다. 개인적으로 백로그 우선 순위를 지정하는 데 즐겨 사용하는 두 가지 게임은 제품 트리 정리기능 구입입니다. Luke의 허가를 받아 그의 저서에서 발췌한 이 두 게임에 대한 설명은 다음과 같습니다.

정원사는 나무를 정리하여 수확량을 제어합니다. 때로는 동물이나 재미있는 추상적 형태를 만들기 위해 예술적으로 나무를 정리할 수도 있습니다. 정리를 할 때에는 대부분 최고 품질의 '결과물'을 수확하기 위해 나무를 균형 있게 가꿉니다. 즉, 이 프로세스에서는 '제거'가 아닌 '형성'을 수행합니다. 고객이 원하는 제품을 만들 때도 이러한 개념을 활용할 수 있습니다.

게임

먼저 화이트보드나 두꺼운 종이에 큰 나무를 그리거나 대형 포스터로 트리의 그래픽 이미지를 인쇄합니다. 굵은 가지는 시스템 내의 주요 기능 영역을 나타내고 나무의 가장자리, 즉 맨 바깥쪽 가지는 현재 릴리스에서 제공되는 기능을 나타냅니다. 여러 색인 카드(나뭇잎 모양이면 좋음)에 새로 포함될 수 있는 기능을 적습니다. 그리고 나무에 원하는 기능을 붙여 다음 제품 확장 단계를 정의하도록 고객에게 요청합니다. 이 과정에서 고객이 균형 잡힌 방식으로 성장하는 나무를 만드는지, 특정 가지(제품의 핵심 기능)가 집중적으로 커지는지, 나무에서 활용도가 낮은 부분이 더 많이 자라는지 등을 확인합니다. 아래 그림에 나와 있는 것처럼 뿌리(지원 및 고객 관리 인프라) 부분이 나무의 윗부분만큼 크게 확장되는지도 확인합니다.

제품 트리 정리에 대한 예제 레이아웃

제품 트리 – Hohmann

유용성

개발자와 고객 모두 기능의 중요도가 각기 다름을 알고 있습니다. 따라서 가장 중요한 기능, 즉 고객에게 가장 큰 가치를 제공하는 기능에 작업을 중점적으로 수행하는 경향이 높습니다. 반면 제품을 완성하는 데 필요한 기능에는 작업을 거의 수행하지 않는 경우도 있습니다. 제품 트리 정리 게임을 통해 고객은 제품을 구성하는 기능 집합을 전반적으로 확인하여 의사 결정 프로세스에 의견을 제공할 수 있습니다.

이 모델에서는 고객이 제품을 구입하도록 하는 기능, 제품을 업그레이드하도록 하는 기능, 고객 만족도가 매우 높아 수정하거나 제거하려는 기능이 있더라도 무시하거나 용인하게 되는 기능 등을 확인할 수 있습니다.

제품 기획자는 이러한 질문과 다른 종류의 질문에 대해 많은 논의를 합니다. 릴리스에 추가할 기능 집합을 제대로 선택하느냐에 따라 제품 릴리스 결과(단기적인 실패 또는 장기적인 실패)가 결정될 수 있습니다. 그러나 제품 기획자는 제품에 가장 큰 영향을 주는 고객을 배제하고 이 결정을 내리는 경우가 많습니다. 기능 구입 게임에서는 고객이 제품을 제작해 보도록 함으로써 이 결정의 효율성을 높일 수 있습니다.

게임에 대한 예제 레이아웃

기능 구입 – Sterne

게임

포함 가능성이 있는 기능과 각 기능의 가격 목록을 작성합니다. 실제 제품에서와 마찬가지로 가격은 개발 비용, 고객 가치 또는 기타 요인을 기준으로 할 수 있습니다. 기능에 대해 부과할 실제 비용을 가격으로 책정할 수도 있지만 반드시 이렇게 해야 하는 것은 아닙니다. 고객은 제공받은 게임 머니를 사용하여 다음 제품 릴리스에 포함하고자 하는 기능을 구입합니다. 가격이 너무 비싸서 어떤 고객도 구입할 수 없는 기능도 반드시 포함해야 합니다. 고객이 비용을 공동 부담하여 반드시 필요한 기능 및/또는 고가의 기능을 구입하도록 합니다. 이렇게 하면 고객들이 가장 중요한 기능에 대해 서로 협상하게 됩니다.

이 게임은 그룹 내 고객 수가 4~7명일 때 가장 효율적입니다. 고객이 협상을 통해 비용을 공동 부담할 기회가 늘어나기 때문입니다. 제품 상자 게임과는 달리 기능 구입 게임은 실제로 개발 로드맵에 포함될 가능성이 높은 기능 목록을 기준으로 합니다.

유용성

대부분의 제품 기획자는 고객이 제품 우선 순위를 명확하게 정의했다고 생각합니다. 실제로 우선 순위를 정의하는 고객도 있지만 대부분의 고객은 그렇지 않습니다. 즉, 옵션 집합을 제시하면 대부분의 고객은 모든 기능을 원한다고 대답하고 요청 우선 순위 지정은 개발자에게 맡기게 됩니다. 제품 관리자가 고객과 일대일로 작업을 진행하여 기능 우선 순위를 수집하고, 해당 과정에서 본인도 모르는 사이에 기능 우선 순위 지정을 지정하게 되는 경우도 많습니다. 고객을 그룹으로 구성하여 제한적인 리소스를 제공하면 고객이 그룹 단위로 원하는 기능의 우선 순위를 지정할 수 있습니다. 그러나 이 게임의 핵심적인 기능은 이러한 그룹 지정이 아니라, 고객이 특정 기능에 대해 서로 협상을 하도록 논의 과정을 구성하는 것입니다. 협상을 통해 고객이 실제로 원하는 기능을 더욱 명확하게 파악할 수 있습니다.

우선 순위 지정을 위한 또 다른 효율적인 방법은 1999년에 Karl Weigers가 도입한 상대적 가중치입니다. 이 방법에서는 사용자의 입력 내용과 피드백을 기준으로 요구 사항 우선 순위를 지정하는 메커니즘을 사용할 수 있을 뿐 아니라, 팀 전문가의 판단 사항도 포함할 수 있습니다. Kano의 모델 및 혁신 게임과 마찬가지로 상대적 가중치 모델에서도 제품 소유자가 구현할 기능 및 해당 우선 순위 순서를 더욱 효율적으로 측정할 수 있습니다.

첫 단계에서는 기능의 상대적 이점에 가중치를 할당합니다. 이점이란 최종 제품의 해당 기능을 사용함으로써 사용자에게 제공되는 장점입니다. 그런 다음 상대적 페널티를 할당합니다. 페널티는 사용자가 최종 제품의 해당 기능을 사용하지 않는 경우의 결과입니다. 이점과 페널티를 평가하면 기능 및 역기능 형식 질문을 사용하는 Kano의 방식과 동일한 결과를 얻을 수 있습니다. 가중치는 회사에서 기능의 이점과 위험을 평가하는 방식을 나타내는 임의의 수치입니다. 이 방식은 총점을 산출하기 위해 교사가 과제, 출석, 퀴즈, 시험 등에 대해 적용할 가중치를 결정하는 방식(교사마다 다른 방식을 사용함)과 매우 비슷합니다. 이점이 페널티보다 큰 경우 적절한 비율로 해당 가중치를 페널티보다 높게 설정합니다. 반대로 페널티가 이점보다 큰 경우에도 그에 따라 가중치를 조정합니다. 위의 표 2에 나와 있는 예제에서는 이점에 상대적 가중치 2를, 페널티에는 상대적 가중치 1을 적용했습니다. 즉, 최종 우선 순위를 결정하는 데는 이점이 더 중요한 요인이 됩니다.

같은 방식으로 비용 백분율 및 위험 백분율의 가중치도 결정합니다. 아래 예제에서는 프로젝트에서 위험이 크게 중요하지 않으므로 비용 백분율의 가중치는 1이고 위험 백분율의 가중치는 0.5입니다. 가치 백분율을 계산하기 전에 이점과 페널티 가중치를 지정하지만 비용과 위험의 가중치는 백분율로 지정됩니다. 위험성이 높은 프로젝트에서는 비용보다 위험의 가중치를 더 높게 지정합니다.

예제 기능 테이블 - 시작

가중치를 설정하고 나면 사용자에게 각 기능의 상대적 이점과 상대적 페널티 점수를 매기도록 합니다. 각 이점과 페널티에 설정된 단위로 등급이 지정됩니다. Weigers의 권장 단위는 1~9이지만 일관성만 유지한다면 다른 단위를 선택해도 됩니다. 상대적 이점은 기능이 제공하는 가치이고 상대적 페널티는 기능이 없는 경우에 발생 가능한 부정적 영향입니다.

"Sarbanes-Oxley 규정을 준수하는 위젯 만들기" 기능의 경우를 예로 들어 보겠습니다. 이 기능의 경우 사용자에 대한 상대적 이점은 사실상 없지만 업무상의 상대적 페널티는 매우 큽니다. 해당 규정을 준수하지 않으면 회사의 업무가 중단될 수도 있기 때문입니다. 따라서 상대적 이점의 점수는 1이나 2인 반면 상대적 페널티의 점수는 8이나 9일 수 있습니다.

다음 예제에서 사용자는 "공급 업체 주문 상태 쿼리" 기능의 상대적 이점 등급을 5로 지정하고 상대적 페널티는 3으로 지정했습니다. 해당 기능의 총점을 산출하려면 두 값에 상대적 가중치를 곱한 후에 결과를 더합니다.

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

여기서 해당 기능의 총점은 13점입니다.

예제 기능 테이블 - 진행 중

기능의 상대적 총점 및 점수 백분율을 계산할 때는 사용자가 아닌 에서 정보를 파악합니다. 즉, 팀이 같은 점수를 사용하여 각 기능을 구현하기 위해 예상되는 상대적 비용을 계산하도록 합니다. Karl Weigers의 설명에 따르면 개발자는 요구 사항의 복잡성, 필요한 사용자 인터페이스 작업의 범위, 기존 디자인이나 코드를 다시 사용할 수 있는 가능성, 필요한 테스트 및 설명서의 수준과 같은 요인을 기준으로 예상 비용 등급을 결정합니다.

예상되는 상대적 비용을 계산한 후에는 예상되는 상대적 위험을 계산합니다. Weigers의 설명에 따르면 개발자는 각 기능과 연관된 기술적 또는 기타 위험의 상대적 등급에 1~9 사이의 예상 단위를 지정합니다. 예상 점수가 1인 경우 위험이 매우 경미한 것이며 9인 경우에는 기능의 적합성, 필요한 전문 지식을 보유한 직원의 유무, 성능이 입증되지 않았거나 익숙하지 않은 도구와 기술 사용 등의 중요한 문제인 것입니다. 스프레드시트에서 각 기능으로 인해 발생하는 전체 위험 백분율이 계산됩니다.

상대적 이점, 페널티, 비용 및 위험에 해당하는 값을 기록한 후 각 열의 값을 더합니다. 이러한 총점을 사용하여 백분율을 계산합니다.

  • 총계 백분율: 상대적 이점과 페널티의 합계 값을 맨 아래의 총합으로 나눕니다. 다음 예제에서 이 결과는 13/154 = 8%입니다.

  • 상대적 비용 백분율: 상대적 비용 값을 맨 아래의 상대적 비용 총합으로 나눕니다. 다음 예제에서 이 결과는 2/42 = 4.8%입니다.

  • 상대적 위험 백분율: 상대적 위험 값을 맨 아래의 상대적 위험 총합으로 나눕니다. 다음 예제에서 이 결과는 1/33 = 3%입니다.

  • 우선 순위: 값 백분율을 (비용 백분율 * 비용 가중치)+(위험 백분율 * 위험 가중치)로 나눕니다. 다음 예제에서 이 결과는 8.4%/((4.8% * 1)+(3% * 0.5)입니다. 따라서 우선 순위 값은 (1.345)가 됩니다.

우선 순위 값을 구한 후에는 우선 순위가 가장 높은 항목이 맨 위에 오도록 우선 순위 열을 내림차순으로 정렬합니다. 제품 백로그에 항목을 추가하거나 스토리에 대한 추가 정보가 발생하면 우선 순위를 다시 평가해야 합니다.

최종 시트는 아래 표와 같습니다.

예제 기능 테이블 - 완료

이 방식을 사용하면 팀과 관련자에게 모두 적용되는 범위를 더 효율적으로 파악할 수 있습니다. 또한 각 기능의 이점, 페널티, 비용, 위험과 같은 요소는 객관적으로 설정하기 어려울 수 있으므로 논의의 기준을 더욱 명확하게 지정할 수 있습니다.

Weigers는 실제 상황에 더 적합하도록 모델을 조정하는 방법에 대해 다음과 같이 설명했습니다.

"이전 제품에서 완성된 요구 사항 또는 기능 집합을 사용하여 상황에 맞게 이 모델을 조정합니다. 계산된 우선 순위 순서가 테스트 집합 내 요구 사항의 실제 중요도를 확인하는 사후 평가 결과와 일치할 때까지 가중치 요인을 조정합니다. 이 모델을 사용하면 제안된 새 요구 사항을 평가할 때 결정 사항을 적절하게 변경할 수도 있습니다. 이 모델을 통해 우선 순위를 예상하면 예상 우선 순위가 기존 요구 사항과 일치하는 정도를 파악하여 적합한 구현 순서를 선택할 수 있습니다. 외부 환경의 영향을 줄이면서 객관적이고 분석적인 방식으로 요구 사항 우선 순위를 지정하기 위해 수행하는 모든 작업은 최적의 순서로 가장 중요한 기능을 제공하는 프로젝트 기능을 개선할 수 있습니다."

Karl Weigers의 두 저서인 소프트웨어 요구 사항(2판)실용적인 소프트웨어 요구 사항: 까다로운 문제와 핵심적인 조언에서 상대적 가중치 설정에 대한 상세 정보를 확인할 수 있습니다.

이러한 방법 중 하나를 사용하든 다른 기술을 사용하든 관계없이, 제품 백로그는 지속적으로 변화한다는 점에 유의해야 합니다. 즉, 유용한 백로그를 유지 관리하려면 우선 순위를 한 번 지정한 후 계속 사용하는 것이 아니라 시간이 지남에 따라 다시 지정해야 합니다. 프로젝트를 계획대로 진행하려면 프로젝트 스토리, 프로젝트에 대한 스토리의 중요도 및 새로운 정보가 백로그에 영향을 주는 방식을 지속적으로 다시 평가해야 합니다. 그리고 프로젝트 전체 과정에 관련자와 고객이 참여하도록 해야 하며, 항목의 우선 순위를 결정하려면 예상 우선 순위를 반드시 설정해야 합니다. 그렇지 않으면 백로그가 오래된 상태가 되어 유용성이 없어집니다. 시간과 노력을 투자하여 백로그를 관리하고 정리하면 최종 제품뿐 아니라 사업 자체에도 도움이 됩니다.

  1. Agile 소프트웨어 요구 사항(Dean Leffingwell, Addison Wesley)

    "유용한 품질과 필수 품질"(Noriaki Kano, 품질 JSQC, 14권 2번 - 1984년 10월) 원문 작성자 - Kano

  2. 요구 사항 우선 순위 지정 순서(Karl E. Wiegers)

표시: