クイズ: 請求書類の完全性

접수함의 파일이 진짜 PDF 인지 확인하려고 head -c 5 파일 | grep -q '%PDF-' 를 썼는데 진짜 PDF 에서도 자꾸 실패한다. 가장 알맞은 진단은?

• PDF 판이 1.7 이면 머리글이 달라 그 문자열로는 잡히지 않는다
• head 가 5바이트만 읽어 grep 이 줄을 완성하지 못했기 때문이다
• 파일에 NUL 이 섞여 있어 grep 이 이진 입력으로 다루기 때문이며 od 나 바이트 읽기로 봐야 한다
• 파일 권한이 모자라 head 가 앞부분을 읽지 못했기 때문이다

같은 영수증 이미지가 파일 이름만 바꿔 두 청구에 제출되었다. 이것을 찾아내는 근거로 가장 알맞은 것은?

• 두 파일 내용의 sha256 이 같은지 본다
• 두 파일의 이름에서 청구번호를 떼고 나머지가 같은지 본다
• 두 파일의 크기와 수정 시각이 같은지 본다
• 두 청구의 금액과 병원명이 같은지 본다

청구 유형마다 필요한 서류 목록이 다르고 상품이 바뀔 때마다 그 목록이 움직인다. 점검기 설계로 가장 알맞은 것은?

• 유형마다 함수를 하나씩 만들어 필요한 서류를 코드로 적는다
• 가장 서류가 많은 유형을 기준으로 삼고 예외를 조건문으로 적는다
• 모든 유형에 공통인 서류만 점검하고 나머지는 심사자에게 맡긴다
• 유형과 서류 종류를 두 컬럼으로 가진 규칙표에 두고 점검기는 표를 읽게 한다

제출 기한 점검을 만들면서 기산일을 접수일로 잡았다. 이 선택이 만드는 문제는?

• 사고일이 비어 있는 청구를 처리하지 못한다
• 늦게 접수한 건일수록 기한이 함께 밀려 사실상 기한이 없어진다
• 같은 사고의 여러 청구가 서로 다른 기한을 갖게 된다
• 기한이 지난 건을 세는 기준일이 매일 달라진다

접수 기록에는 있는데 접수함에 파일이 없는 건과, 접수함에는 있는데 기록이 없는 건을 발견했다. 두 가지의 성격을 옳게 짝지은 것은?

• 둘 다 기록 오류이므로 기록을 파일 기준으로 맞추면 된다
• 앞은 개인정보가 남아 있는 것이고 뒤는 지급 근거가 빈 것이다
• 둘 다 같은 사고이므로 한 목록으로 묶어 보완 요청을 보낸다
• 앞은 지급 근거가 빈 것이고 뒤는 누구의 것인지 모르는 개인정보가 남은 것이다

증빙 점검 보고서를 쓰면서 파일 이름에 실려 온 개인정보를 다루려 한다. 가장 알맞은 방식은?

• 건수와 판정 규칙만 적고 값은 싣지 않는다
• 문제가 된 파일 이름을 전부 나열해 담당자가 바로 고치게 한다
• 이름의 가운데 글자만 별표로 가려 목록에 담는다
• 별도 첨부 파일에 이름 목록을 담아 보고서와 함께 보낸다