인수 기준은 프로젝트 종료 직전에 만들면 늦다
인수 조건은 최종 검수 회의에서 새로 쓰는 요구사항 목록이 아닙니다. 무엇이 완료 상태인지 작업 전에 정하고 그 잣대로 테스트와 종료 여부를 판단해야 합니다. 고객 인수 조건을 작업 시작 전에 최대한 분명히 정의하고 이를 인수 테스트의 근거로 쓰라는 것이 이슈 관리 도구 지침의 공통된 안내이기도 합니다.[6]
인수 기준에는 최소한 여섯 요소가 있어야 합니다. 어떤 기능과 시스템, 환경, 데이터가 범위에 들어가는지 확인합니다. 어떤 결과가 나오면 완료인지 확인합니다. 테스트 결과와 로그, 저장소, 문서, 설정 내역 가운데 무엇을 제출하는지 확인합니다. 누가 어느 환경에서 다시 확인하는지 확인합니다. 누가 READY와 READY WITH CONDITIONS, HOLD를 정하는지 확인합니다. 미완료 항목을 어떤 조건으로 남길 수 있는지입니다.
이 구조가 없으면 검수 회의는 대체로 되는 것 같다는 말과 우리는 개발을 완료했다는 말이 부딪히는 자리가 됩니다.
기능 검수와 운영 인수를 왜 나눠야 하나
두 게이트는 서로 이어져 있지만 같은 질문에 답하지 않습니다.
영국 정부의 서비스 준비성 검토 지침도 사용자 인수 테스트와 통합 테스트, 비기능 테스트를 운영 인수 테스트와 구분합니다. 또한 시험된 복구 계획과 미해결 결함, 보안 이슈, 데이터 이전, 인수 후 운영 책임자까지 확인 대상으로 둡니다.[7]
기능 검수가 끝났다고 운영 인수까지 자동으로 끝나지는 않습니다. 반대로 운영 문서를 모두 받았어도 핵심 기능이 합의 조건을 채우지 못하면 기능 검수는 통과하지 못합니다.
- 기능 검수 게이트
- 기능 검수 게이트는 합의한 요구사항이 구현됐는지 확인하는 관문이며, 핵심 흐름과 권한별 허용·차단, 계산과 데이터 변경, 외부 연동, 비기능 기준, 미해결 결함과 제외 범위를 봅니다.
- 운영 인수 게이트
- 운영 인수 게이트는 인수 조직이 공급자에게 기대지 않고 시스템을 통제하는지 확인하는 관문이며, 소스와 빌드, 배포, 계정, 데이터, 복구, 보안, 모니터링, 유지보수 경계를 봅니다.
출시 판단까지 이어지는 검증 — 핵심 흐름을 검증하고 실행 결과와 남은 조건을 출시 판단의 근거로 연결합니다.
인수 매트릭스는 무엇을 묻나
아래 표에서 F는 기능 검수, O는 운영 인수, B는 두 게이트 모두에 영향을 주는 항목을 뜻합니다. 영역마다 합의할 기준과 필수 증거, 인수자가 직접 확인할 것, 대표적인 HOLD 조건을 함께 적습니다.
READY WITH CONDITIONS는 위험의 범위와 임시 대응책, 책임자, 완료 기한이 모두 정해졌을 때만 씁니다. HOLD는 현재 상태로는 기술·운영 인수를 완료하지 않는다는 뜻입니다. 이 판정이 대금 지급이나 법적 소유권에 미치는 효과는 계약과 법률 검토의 영역이며 여기서 다루지 않습니다.
영역 | 게이트 | 합의할 기준 | 필수 증거 | 인수자가 직접 확인할 것 | 대표적인 HOLD 조건 |
|---|---|---|---|---|---|
| 요구사항·인수 조건 | F·B | 요구사항 식별자와 적용 버전, 완료 조건, 제외 범위가 고정돼 있다 | 요구사항 목록, 인수 테스트 결과, 미완료·예외 목록 | 핵심 요구와 테스트 결과를 표본 추적하고 예외 승인자를 확인 | 기준이 사후에 바뀌었거나 핵심 요구의 결과가 없음 |
| 소스코드 | O | 합의 범위의 애플리케이션 코드와 DB 마이그레이션, 빌드·배포 스크립트, 설정 템플릿, 필요한 IaC가 들어 있다 | 최종 커밋과 태그, 저장소 목록, 소스 아카이브 해시, LFS·서브모듈 목록 | 최종 배포 버전이 어느 커밋에서 만들어졌는지 추적 | 운영 버전과 전달 소스가 다르거나 핵심 코드가 빠져 있음 |
| 저장소 소유권 | O | 개인 계정이 아니라 인수 조직이 저장소와 조직 설정을 통제한다 | 소유 조직, 관리자 목록, 팀·권한, 브랜치 규칙, 웹훅·배포 키 목록 | 인수 조직 소유자가 설정과 권한, 보호 규칙을 변경 | 수행사 개인이나 조직만 소유자이고 발주자는 협업자에 그침 |
| 빌드 재현성 | O | 지정한 소스 리비전과 문서화된 환경에서 산출물을 다시 만든다 | 런타임·컴파일러 버전, 잠금 파일, 베이스 이미지, 빌드 명령, 로그, 산출물 해시 또는 출처 증명 | 깨끗한 러너나 새 장비에서 직접 빌드 | 특정 개발자 PC나 접근 불가능한 사설 레지스트리에서만 빌드됨 |
| 배포 절차 | O | 인수 조직 계정으로 테스트·운영 환경에 배포한다 | 파이프라인 정의, 배포 런북, 환경 목록, 설정·비밀정보 참조 방식, 상태 점검 | 인수팀이 비운영 환경에 직접 배포하고 결과를 확인 | 문서화되지 않은 수동 작업이나 수행사 계정이 반드시 필요함 |
| 자격증명·계정 소유권 | O | 계정은 조직 명의이며 개인 공용 계정을 쓰지 않는다. 권한과 복구 수단, 다중 인증, 비밀정보 수명주기가 정해져 있다 | 계정·역할 인벤토리, 복구 연락처, 다중 인증 상태, 비밀정보 교체·폐기 기록 | 자체 계정으로 로그인하고 수행사 접근을 교체·폐기 | 최고 관리자나 복구 이메일을 수행사만 통제하거나 자격증명 출처를 모름 |
| 도메인·DNS·클라우드 계정 | O | 등록자와 결제 주체, 복구 연락처, 최고 관리자, 갱신 책임을 인수 조직이 통제한다 | 등록기관·DNS 존·클라우드 계정·청구·지원 인벤토리 | DNS 변경, 도메인 갱신, 클라우드 지원 요청 권한을 확인 | 도메인이나 루트 계정, 결제 계정이 수행사 명의로만 존재 |
| 데이터 내보내기·이전 | B | 인수 대상 데이터의 범위와 형식, 보존, 정합성 검증 방식이 합의돼 있다 | 데이터 사전, 스키마, 내보내기·이전 스크립트, 건수·합계·해시 검증 결과 | 표본 또는 격리 환경에서 내보내기와 적재를 수행 | 완전한 내보내기 경로가 없거나 이전 후 건수·금액·관계 정합성을 확인하지 못함 |
| 백업·복구 | O | 백업 생성뿐 아니라 합의된 데이터 시점으로 복구한다 | 정책, 저장 위치, 최근 성공 기록, 복구 시험 보고서, 측정 소요 시간 | 격리 환경에서 최근 백업을 복구하고 애플리케이션을 확인 | 백업 성공 로그만 있고 복구 시험이 없거나 인수팀이 백업에 접근하지 못함 |
| 보안 발견 사항 | B | 검증 범위와 방법, 버전, 모든 미해결 발견 사항이 공개돼 있다 | 보안 시험 보고서, 비밀정보 스캔, 미해결 항목, 재시험 결과, 위험 수용자·기한 | 공개된 발견 사항이 현재 배포 버전과 맞는지 표본 확인 | 중대한 미해결 이슈의 영향과 완화책, 책임자가 없거나 비밀정보가 코드에 남아 있음 |
| 의존성·라이선스 | O | 실행에 필요한 내부·외부 구성요소와 접근 경로, 지원 종료 상태를 파악한다 | 잠금 파일, SBOM, 사설 패키지 목록, 구성요소 버전·해시·라이선스·지원 종료 정보 | 새 환경에서 모든 의존성을 내려받아 설치하고 빌드 | 필수 사설 패키지에 접근하지 못하거나 누가 유지하는지 모름 |
| 모니터링 | O | 운영 상태를 볼 수 있고 경보가 행동 가능한 담당자에게 전달된다 | 대시보드, 경보 규칙, 로그 접근권한·보존, 알림 경로, 런북 | 시험 경보를 발생시키고 수신·확인·조치 경로를 검증 | 운영 가시성이 수행사 계정에만 있거나 경보 수신자가 없음 |
| 문서 | O | 문서가 최종 버전과 맞고 실제 작업을 재현할 만큼 구체적이다 | 아키텍처, 데이터 흐름, API, 배치·크론, 배포, 백업, 장애 대응, 계정 인벤토리 | 문서만 보고 빌드·배포·복구 중 하나를 수행 | 핵심 단계가 구두 지식으로만 남거나 문서가 과거 버전을 설명 |
| 알려진 문제 | F·B | 모든 알려진 결함과 제약, 기술부채를 영향과 함께 공개한다 | 이슈 식별자, 영향 버전, 재현 절차, 영향도, 우회책, 책임자, 목표일 | 표본 이슈를 재현하고 현재 상태와 우회책을 확인 | 핵심 업무·보안·데이터에 영향을 주는 이슈가 숨겨져 있거나 소유자가 없음 |
| 하자·유지보수 경계 | O | 결함과 변경 요청, 운영 작업, 외부 장애를 기술적으로 분류하고 접수·판정 절차를 정한다 | 분류표, 지원 채널, 운영 시간, 증거 요건, 상위 이관, 외부 공급사 경계 | 같은 예시 티켓을 양측이 같은 유형으로 분류하는지 확인 | 장애가 나도 어느 조직도 접수·판정·조치를 책임지지 않는 구조 |
| 운영 책임자 | O | 시스템과 소스, 클라우드, 데이터, 보안, 장애 대응의 책임 역할과 대체자가 지정돼 있다 | RACI 또는 소유자 등록부, 담당자·대체자, 접근권한 확인 기록 | 실제 소유자가 첫 배포와 복구, 경보 훈련에 참여 | IT팀처럼 추상적 조직명만 있고 실제 권한이 있는 담당자가 없음 |
소스코드를 받았다는 말만으로는 부족하다
소스코드 압축 파일을 전달받는 것과 소프트웨어를 통제하는 것은 다릅니다. 최종 운영 버전이 어떤 커밋과 태그에서 만들어졌는지 알 수 있어야 하고, 이슈와 풀 리퀘스트, 릴리스 기록과 설정이 남은 저장소를 인수해야 합니다. GitHub를 쓰는 경우 저장소를 이전하면 새 소유자가 내용뿐 아니라 이슈와 풀 리퀘스트, 릴리스, 프로젝트와 설정까지 관리합니다.[1] 다만 웹훅과 비밀정보, 배포 키도 연결된 채 남을 수 있으므로 이전 뒤에 권한과 비밀정보를 따로 감사해야 합니다.
저장소가 특정 담당자 한 명에게만 매여서도 안 됩니다. GitHub는 소유자 한 명이 연락되지 않으면 프로젝트 접근이 끊길 수 있어 조직마다 복수 소유자를 권합니다.[8] 이는 특정 제품의 기능이 아니라 소스 관리 권한을 개인에게 몰지 말라는 운영 원칙으로 읽으면 됩니다.
GitHub를 쓰지 않는 프로젝트도 잣대는 같습니다. 플랫폼이 무엇이든 인수 조직이 저장소와 접근권한, 변경 이력, 보호 정책, 패키지 저장소를 직접 통제해야 합니다.
모든 프로젝트에 비트 단위 재현 빌드가 필요한 것은 아니다
재현 가능한 빌드의 엄격한 정의는 같은 소스와 빌드 환경, 지침으로 누구나 비트 단위까지 같은 산출물을 만드는 것입니다. 이를 확인하려면 소스 리비전과 의존성 버전, 빌드 플래그, 환경 변수, 산출물 해시가 필요합니다.[9]
하지만 모든 SI 프로젝트의 최소 인수 조건을 곧바로 비트 단위 동일성으로 정할 필요는 없습니다. 위험에 따라 두 단계로 나누는 편이 현실적입니다. 기본은 다시 빌드되는 빌드입니다. 깨끗한 환경에서 전달받은 소스 리비전을 받아 고정된 런타임과 의존성으로 실행 가능한 산출물을 만들 수 있어야 합니다.
보안과 규제, 공급망 위험이 큰 시스템은 여기에 산출물 해시와 빌드 출처 증명을 더합니다. SLSA는 소프트웨어가 변조되지 않았고 어떤 소스에서 생성됐는지 추적하는 빌드 트랙과 출처 증명 검증 구조를 제공합니다.[2] 어느 수준을 택하든 수행사 개발자의 노트북에서 빌드가 됐다는 설명은 인수 증거가 아닙니다. 인수팀이 자체 환경에서 다시 빌드해야 합니다.
계정은 비밀번호 목록이 아니라 통제권으로 인수한다
인수 문서에 비밀번호를 평문으로 모아 놓는 것은 좋은 인계가 아닙니다. 먼저 계정과 권한의 인벤토리를 만들고 조직 명의 계정과 개인 계정을 구분해야 합니다. 비밀정보는 승인된 비밀 관리 도구나 안전한 전달 수단으로 옮기고, 수행사가 알고 있던 키와 비밀번호는 인수 완료 후 교체하거나 폐기합니다.
OWASP는 비밀정보를 생성과 회전, 폐기, 만료라는 수명주기로 관리하고 더 이상 필요하지 않거나 노출 가능성이 있는 비밀정보는 폐기하도록 권고합니다.[3] 사용 기록과 관리자 작업도 감사할 수 있어야 합니다.
특히 다음 계정을 빠뜨리기 쉽습니다. 도메인 등록기관과 DNS, 클라우드와 호스팅, 데이터베이스, CI/CD와 패키지 레지스트리, 이메일·SMS·결제·지도 같은 외부 API, 앱스토어와 모바일 서명, 모니터링과 로그, 보안 도구, 백업 저장소와 암호화 키, SaaS의 청구·지원 계정입니다. 각 계정에는 소유자와 관리자, 결제 주체, 복구 이메일, 다중 인증, 갱신일, 수행사 접근 종료일이 있어야 합니다.
백업 파일보다 복구 결과를 받아야 한다
백업 목록이나 최근 백업 성공 화면만으로는 복구 가능성을 알 수 없습니다. 인수 시점에 필요한 것은 실제 복구 시험의 결과입니다.
최소한 일곱 가지를 확인합니다. 어떤 시점의 데이터를 복구했는가. 어느 환경에 복구했는가. 복구에 얼마나 걸렸는가. 애플리케이션이 복구된 데이터로 정상 기동했는가. 사용자와 권한, 첨부파일, 외부 저장소까지 포함됐는가. 복구 후 데이터 정합성을 무엇으로 확인했는가. 복구에 필요한 암호화 키와 계정은 누가 소유하는가입니다.
운영 인수에서 복구 시험을 요구하는 이유는 별도의 복구 아키텍처를 설계하려는 것이 아닙니다. 이미 납품 대상에 들어 있는 백업이 인수 조직의 권한과 절차로 실제 동작하는지 확인하기 위해서입니다. 영국 정부의 서비스 준비성 검토 역시 실행 가능하고 시험된 비상·연속성·복귀 계획을 확인 대상으로 둡니다.[7]
의존성 목록은 빌드 파일만으로 끝나지 않는다
package.json과 pom.xml, requirements.txt 같은 파일은 출발점입니다. 실제 인수에는 여덟 가지 정보가 더 필요합니다. 정확한 구성요소와 버전, 직접·간접 의존 관계, 사설 패키지와 접근권한, 구성요소의 해시, 적용 라이선스, 지원 종료 또는 폐기 상태, 운영에 필요한 외부 SaaS와 API, 의존성 교체·업데이트 책임자입니다.
다국가 공동 SBOM 지침은 소프트웨어를 개발하는 조직뿐 아니라 구매하거나 운영하는 조직도 대상에 넣습니다. 최소 요소에는 구성요소 버전과 의존 관계, 해시, 라이선스, SBOM 생성 도구와 버전 등이 들어갑니다.[10]
SBOM이 있다고 모든 보안 위험이 사라지지는 않습니다. 그러나 어떤 구성요소를 운영하는지 모르는 상태보다는 취약점과 지원 종료, 라이선스 영향을 판단할 출발점을 줍니다.
보안 검수의 목표는 취약점 0개 증명서가 아니다
보안 결과물에는 최소한 시험 대상 버전과 범위, 방법, 판정 잣대, 수행일, 발견 사항, 재시험 결과가 있어야 합니다. 미해결 발견 사항은 영향과 완화책, 위험 수용자, 책임자, 처리 기한을 남깁니다.
OWASP ASVS는 웹 애플리케이션과 실행 환경의 기술 보안 통제를 검증하고 조달 요구사항을 정의하는 바탕으로 쓸 수 있습니다.[11] NIST도 공급자가 검증 활동을 수행했다는 주장뿐 아니라 검증 결과와 설정·구현 정보, 미해결 취약점, 보완 조치를 조달과 인수 과정에서 확인하도록 안내합니다.[4][12]
중요한 것은 보안 검사를 했다는 한 줄이 아니라 다섯 질문에 답하는가입니다. 무엇을 검사했고 무엇은 검사하지 않았는가, 어느 버전과 환경을 검사했는가, 미해결 이슈는 무엇인가, 지금 운영을 멈춰야 하는 이슈는 무엇인가, 누가 언제 수정하거나 위험을 수용했는가입니다.
관측에서 복구와 개선까지 이어지는 운영 — 서비스 지표와 경보를 기준으로 대응하고 변경 이력과 사후 보고를 다음 개선에 연결합니다.
모니터링도 계정과 사람까지 연결돼야 한다
대시보드 주소를 전달받았다고 모니터링을 인수한 것은 아닙니다. 인수 조직이 로그와 지표에 접근해야 하고 경보가 실제로 대응할 사람에게 전달돼야 합니다. Google SRE는 경보가 사용자의 문제를 나타내고 긴급하며 수신자가 행동할 수 있어야 한다고 강조합니다.[5] 호출로 이어지는 모든 경보는 조치 가능해야 합니다.
그래서 인수 과정에서 시험 경보를 한 번 발생시키는 편이 좋습니다. 경보가 올바른 채널에 도착하는지, 담당자가 런북을 찾는지, 필요한 운영 계정으로 접속하는지 확인합니다. 경보는 울렸지만 받을 사람이 없거나 수행사 계정에서만 대시보드가 보인다면 운영 인수는 끝나지 않았습니다.
알려진 문제를 남기는 것과 숨기는 것은 다르다
모든 알려진 문제를 고친 뒤에만 인수할 수 있는 것은 아닙니다. 영향이 제한적이고 우회책이 있으며 담당자와 완료 기한이 정해진 문제는 조건부로 남길 수 있습니다.
다만 알려진 문제에는 최소한 일곱 가지 정보가 있어야 합니다. 영향을 받는 버전과 기능, 재현 절차, 사용자·데이터·보안·운영 영향, 임시 우회책, 수정 책임자, 목표일, 인수 판정에 미치는 영향입니다.
추후 개선 예정은 처리 계획이 아닙니다. 특히 핵심 업무 중단과 권한 우회, 데이터 손상, 복구 실패 가능성이 있는 문제는 단순한 잔여 작업으로 낮춰서는 안 됩니다.
하자와 유지보수의 법률적 의미보다 먼저 기술 분류를 맞춘다
다음 구분은 법적 책임을 정하기 위한 것이 아닙니다. 장애나 요청이 들어왔을 때 티켓이 어느 창구로 가야 하는지를 정하는 기술·운영 분류입니다. 실제 비용과 책임, 기간, 법적 효과는 계약과 별도 법률 검토를 따릅니다.
양측이 같은 사건을 다르게 분류하면 대응이 시작되지 않습니다. 수행사는 추가 개발이라고 하고 발주사는 기존 결함이라고 주장하는 동안 운영 장애는 그대로 남습니다. 그래서 분류 잣대와 필요한 증거, 최초 판정자, 이견 조정 경로를 인수 전에 정해야 합니다.
발생 상황 | 기술·운영상 분류 후보 | 인수 전에 정할 내용 |
|---|---|---|
| 합의한 인수 조건과 실제 동작이 다름 | 결함 후보 | 재현 증거, 심각도, 수정·재시험 절차 |
| 새로운 기능이나 바뀐 업무 규칙을 요구 | 변경 요청 후보 | 영향 분석, 승인, 별도 일정·비용 산정 절차 |
| 잘못된 운영 데이터·설정 때문에 장애 발생 | 운영·데이터 지원 후보 | 설정·데이터 소유자와 복구 책임 |
| 외부 API·SaaS 장애 또는 사양 변경 | 외부 의존성 장애 | 1차 확인자, 공급사 문의, 우회·대체 범위 |
| 런타임·라이브러리의 보안 패치나 지원 종료 | 유지보수·업그레이드 작업 후보 | 모니터링, 업데이트 결정권자, 회귀 검증 책임 |
인수 회의에서는 시연보다 재실행이 중요하다
실무에서는 여섯 단계 순서가 잘 맞습니다. 먼저 인수 후보를 고정합니다. 소스 태그와 산출물 버전, 데이터베이스 스키마, 배포 환경, 인수 매트릭스 버전을 함께 묶습니다. 다음으로 수행사가 먼저 증거를 제시합니다. 기능 결과와 빌드·배포 로그, 계정 목록, 데이터 검증, 복구 시험, 보안 보고서와 알려진 문제를 설명합니다.
셋째, 인수팀이 같은 작업을 다시 수행합니다. 자체 계정으로 저장소를 내려받고 빌드하고 비운영 환경에 배포합니다. 데이터 내보내기와 적재, 백업 복구, 시험 경보도 표본으로 실행합니다. 넷째, 예외를 별도 원장에 남깁니다. 누락 항목마다 영향과 우회책, 책임자, 완료일, 재검수 방법과 현재 판정을 기록합니다. 다섯째, 계정 소유권을 전환합니다. 인수 조직의 소유자와 복구 수단을 확인한 뒤 수행사 접근을 필요한 범위로 낮추고 비밀정보를 교체하거나 폐기합니다. 여섯째, 기능 검수와 운영 인수에 각각 서명합니다. 기능은 통과했지만 운영 인수가 HOLD인지, 어느 항목이 조건부인지 구분합니다.
시연은 수행사가 할 수 있다는 사실을 보여 줍니다. 인수팀의 재실행은 수행사가 없어도 조직이 계속 운영한다는 사실을 보여 줍니다. 둘은 다른 증거입니다.
조건부 인수가 가능한 경우와 멈춰야 하는 경우
조건부 인수는 미완료 항목이 있다는 사실만으로 허용되지 않습니다. 네 가지가 모두 있어야 합니다. 영향 범위가 제한돼 있고, 현재 운영을 유지할 우회책이 있고, 수정 책임자와 완료 기한이 정해져 있고, 미완료 항목이 인수 조직의 독립적인 수정·배포·복구 능력을 없애지 않아야 합니다.
반면 여덟 상태는 운영 인수를 멈출 이유가 됩니다. 최종 운영 소스와 저장소를 통제하지 못한다. 인수팀이 깨끗한 환경에서 빌드하지 못한다. 수행사 계정 없이는 배포하거나 운영 환경에 접근하지 못한다. 도메인과 DNS, 클라우드 최고 관리자와 복구 수단을 인수하지 못했다. 데이터를 완전하게 내보낼 수 있는지 알 수 없다. 백업은 있지만 복구 시험이 없다. 중대한 보안 이슈나 코드에 박힌 비밀정보의 처리 책임자가 없다. 운영 경보를 받을 사람과 장애 대응 소유자가 없다입니다.
문서의 개수보다 중요한 것은 인수 조직이 시스템의 다음 변경과 다음 장애를 스스로 책임지는가입니다.
소프트웨어 인수의 완료 조건
소프트웨어 인수는 기능 목록에 체크 표시를 모두 넣는 행위가 아닙니다. 인수 조직이 다음 질문에 그렇다고 답할 수 있어야 합니다. 수행사가 내일부터 참여하지 않더라도 우리는 이 소프트웨어의 현재 상태를 설명하고 소스를 수정하고 다시 빌드하고 배포하고 데이터를 옮기고 복구하고 보안 문제와 장애에 대응하는가입니다.
이 질문에 답하려면 더 많은 문서가 아니라 소유권과 실행 가능한 절차, 검증 증거, 분명한 운영 책임자가 있어야 합니다. 기능 검수와 운영 인수를 나누면 무엇이 끝났고 무엇이 아직 위험으로 남았는지 비로소 정확하게 판단합니다.
