비교표에서는 C가 88점으로 가장 높아요. 그런데 필요한 형식으로 데이터를 내보낼 수 없다면 C를 선택할 수 있을까요? 점수를 더하기 전에 반드시 충족할 조건을 따로 확인해야 해요. 이번에는 가상의 업무 도구 세 개를 비교해 필수 조건 판정, 점수 계산, 순위가 바뀌는 가중치 경계까지 있는 비교표를 만들어요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
상황은 매주 자료를 처리하고 다른 팀에 넘기는 담당자의 도구 선택이에요. 필수 조건은 ‘기존 팀이 읽는 지정 형식으로 결과를 내보낼 수 있을 것’이에요. 처리시간·지원 업무 수·운영시간은 모두 합성 값이며 특정 제품의 실측 성능이 아니에요. 이 숫자를 그대로 구매 판단에 사용할 수는 없어요.
필수 조건을 점수 한 칸으로 넣지 않아요
대안 입력 CSV (ZIP: alternatives.csv)의 내용은 다음과 같아요. 지원 범위는 미리 정한 열 가지 업무 중 가능한 업무의 수이고, 운영 부담은 매주 유지에 드는 시간이에요.
| 대안 | 1회 처리시간 | 지원 업무 | 주당 운영시간 | 지정 형식 내보내기 |
|---|---|---|---|---|
| A | 12분 | 10/10개 | 8시간 | 가능 |
| B | 8분 | 8/10개 | 4시간 | 가능 |
| C | 6분 | 10/10개 | 2시간 | 불가 |
C는 필수 조건을 충족하지 않아 선택 대상에서 제외해요. ‘내보내기 기능 0점, 속도 100점’처럼 더하면 다른 장점이 필수 조건 위반을 상쇄할 수 있어요. 정말 필수라면 점수 계산 앞에서 통과 여부를 결정해야 해요. 기능이 가능한지 아직 확인하지 못했다면 ‘통과’도 ‘탈락’도 아닌 확인 대기로 두고 최종 순위에 포함하지 않아요.
A와 B의 지원 차이도 살펴봐야 해요. 빠진 두 업무가 사실상 필수라면 B도 탈락해야 해요. 이 예제에서는 그 두 업무를 수동으로 보완할 수 있고, 보완 부담이 주당 운영시간에 포함됐다고 가정해요. 무엇을 필수로 정했는지가 계산 결과보다 먼저예요.
단위가 다른 값을 같은 척도로 바꿔요
분, 업무 개수, 시간을 그대로 더할 수는 없어요. 여기서는 아래와 같은 0~100점 척도를 비교 전에 정해요.
- 속도 점수:
(20−처리분)/20×100. 20분이면 0점, 0분이면 100점이에요. - 지원 점수:
지원 업무 수/10×100. 열 업무의 중요도가 같다는 가정이에요. - 운영 점수:
(10−주당 운영시간)/10×100. 10시간이면 0점, 0시간이면 100점이에요.
기준 시간 20분·10시간은 이번 담당자의 평가 범위예요. 검증된 보편 척도가 아니에요. 범위 밖의 값을 넣어 음수 점수를 만들기보다 범위가 왜 벗어났는지 확인하고 척도를 다시 정해야 해요. NASA의 의사결정 분석 안내도 서로 다른 측정 기준을 정규화할 때 척도가 어떤 뜻인지 분명히 정의하고 순위의 견고함을 살피도록 설명해요. 아래 척도와 가중치는 그 문서의 공식 배점이 아니라 이번 예제의 선택이에요.
| 대안 | 속도 | 지원 | 운영 |
|---|---|---|---|
| A | 40 | 100 | 20 |
| B | 60 | 80 | 60 |
| C | 70 | 100 | 80 |
두 가지 선호를 계산하면 순위가 달라져요
기본 가중치는 속도 20%, 지원 50%, 운영 30%로 정해요. 합계는 100%이고, 각 점수에 가중치를 곱해 더해요. A는 40×0.2+100×0.5+20×0.3=64, B는 60×0.2+80×0.5+60×0.3=70이에요.
지원 범위를 더 중시해 20%·70%·10%로 바꾸면 A는 80점, B는 74점이 돼요. 자료가 바뀐 것이 아니라 ‘지원 두 업무를 더 확보하기 위해 운영 부담을 얼마나 감수할까’라는 선호가 바뀐 거예요.
| 가중치: 속도·지원·운영 | A | B | 필수 조건 통과 대안 중 1위 |
|---|---|---|---|
| 기본: 20%·50%·30% | 64 | 70 | B |
| 지원 우선: 20%·70%·10% | 80 | 74 | A |
점수 차이 6점을 통계적으로 유의한 차이나 성공 확률 차이라고 해석하지 않아요. 이 점수는 입력값과 정의한 척도·가중치의 계산 결과예요. 가중치에 동의하지 않는 사람은 계산을 틀렸다고 하기보다 어느 교환 관계에 동의하지 않는지 설명할 수 있어야 해요.
순위가 바뀌는 지점을 식으로 남겨요
속도 가중치를 20%로 고정하고 지원 가중치를 w로 두면 운영 가중치는 0.8−w예요. 음수가 되지 않도록 0≤w≤0.8에서 비교해요.
A = 40×0.2 + 100w + 20(0.8−w) = 24+80w
B = 60×0.2 + 80w + 60(0.8−w) = 60+20w
두 값이 같은 지점은 24+80w=60+20w, 즉 w=0.6이에요. 지원 가중치가 60%보다 작으면 B가, 60%보다 크면 A가 앞서요. 정확히 60%면 72점으로 같아요.
최종 메모는 ‘기본 가중치에서는 B를 권고하되, 지원 범위의 중요도를 60% 초과로 정하면 A로 바뀐다. C는 필수 형식 미지원으로 제외한다’가 돼요. 둘 중 하나를 계산이 자동으로 확정한 것처럼 쓰지 않고, 가중치를 결정할 담당자가 무엇을 판단해야 하는지 남겨요.
검증 코드 (ZIP: verify.py)를 python3 assets/verify.py로 실행하면 점수 결과 (ZIP: scores.csv), 민감도 표 (ZIP: sensitivity.csv), 실행 기록 (ZIP: results.json)을 다시 만들어요. Python 3.12.3 표준 라이브러리에서 실행했고 가중치 합계와 동점 경계를 검사했어요. 실제 자료에 적용할 때는 업무 목록과 측정 단위를 먼저 정하고, 입력값의 출처·확인일·판정 담당을 추가하세요. 입력값 자체가 불확실하다면 가중치만 바꾸는 이번 표로 충분하지 않으므로 가정별 시나리오도 함께 계산해요. 합성 비교표와 원고는 2026년 10월 13일 Codex가 작성했어요.
예제 파일을 한 번에 받아 다시 확인해요
이 글의 입력·코드·완성 자료 ZIP을 새 폴더에 풀면 R20/README.txt, replay.py, assets 폴더가 함께 생겨요. 개별 코드 파일만 저장하면 보조 모듈이나 입력이 빠질 수 있으므로 처음에는 이 묶음을 사용하세요. R20 폴더에서 다음 명령을 실행하면 본문에 사용한 검사를 순서대로 수행해요.
python3 replay.py
확인할 결과는 기본64/70/88점, 지원우선80/74/92점, C 필수조건 탈락예요. 명령이 성공해도 이 값과 본문의 적용 범위를 함께 대조하세요. 실행 안내 (ZIP: README.txt)에 필요한 파일과 개별 명령을 적었어요. 실행 코드는 verify.py (ZIP: verify.py)에서 직접 볼 수 있어요. Python3.12의 표준 라이브러리를 사용하며, 명령이 실패하면 ZIP의 폴더 구조와 오류에 나온 파일부터 확인해요. 실제 앱 실행에 필요한 프로그램은 원래 설명을 따르세요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.