개발자는 쉽게 쓰는데, 처음 쓰는 사람도 그럴까요?

익숙한 조작에도 설명되지 않은 전제가 있습니다

개발자는 전원을 켜고, 준비 상태를 확인하고, 필요한 조작을 자연스럽게 이어갑니다.
오랫동안 같은 시제품을 다루었다면 화면에 적혀 있지 않은 의미까지 알고 있을 수 있습니다.
처음 기기를 만나는 사용자는 어떨까요?

개발자가 시연에 성공했다는 사실은 기기의 동작을 설명하는 데 도움이 됩니다.
하지만 그것만으로 의도한 사용자가 같은 조건에서 안전하게 사용할 수 있다는 결론까지 내리기는 어렵습니다.
개발자의 경험이 대신 메워 주는 부분이 무엇인지 찾아보는 것이 이번 글의 출발점입니다.

이 글은 의료기기 개발팀을 위한 자체 검토 질문입니다.
특정 기기의 조작법이나 진료 지침이 아니며, 제품별 사용적합성 평가 계획을 대신하지 않습니다.
사례에 등장하는 기기는 실제 제품이 아닌 설명용 가상 시제품입니다.

사용자, 환경, 인터페이스를 함께 봅니다

FDA의 Human Factors Considerations는 사용자, 사용환경, 사용자 인터페이스의 상호작용을 설명합니다.
사용자의 경험이나 감각·조작 능력, 주변의 빛과 소음, 기기의 표시와 조작부 등을 함께 살펴보는 관점입니다.
인터페이스는 화면에 한정되지 않고 사용자가 제품과 상호작용하는 부분을 포함합니다.

FDA의 Applying Human Factors and Usability Engineering to Medical Devices는 2026년 8월 3일 발행본이 공개되어 있습니다.
이 글에서는 범위와 정의를 참고했습니다.
가이던스의 권고와 법적 의무는 구분해야 하며, 미국 자료를 국내 인허가 요건으로 그대로 적용하지 않습니다.

이하의 질문과 표는 원문 표의 번역이 아닌 MedQraft 자체 작성입니다.
가이던스 전체 절차나 시험 인원, 합격 기준을 요약한 것으로 사용하지 마십시오.

“누가 쓴다”를 실제 역할로 풀어 봅니다

“의료인이 사용하는 제품”이라는 한 줄만으로 구체적인 사용 장면이 충분히 설명될까요? 팀에서 생각하는 사용자가 누구인지, 제품에 익숙한지, 어느 단계의 조작을 맡는지 조금 더 나누어 볼 수 있습니다.

예를 들어 한 사람이 기기를 준비하고 다른 사람이 결과를 확인한다면, 준비 단계의 정보가 다음 사람에게 어떻게 전달되는지 질문할 수 있습니다.
같은 직무라도 해당 제품을 매일 쓰는 사람과 처음 쓰는 사람은 기대하는 안내가 다를 수 있습니다.
직무 이름만으로 경험을 가정하지 않는 이유입니다.

검토에서는 확인된 사용자 정보와 개발팀의 가정을 구분해 보십시오.
실제 사용자 관찰이나 인터뷰가 필요한 부분은 확인 과제로 남깁니다.
아직 확인하지 않은 사용자 행동을 확정된 요구사항처럼 적기보다 무엇을 알아야 하는지 드러내는 편이 유용합니다.

가상 사례: 불빛 하나로 두 상태를 보여준다면

휴대형 측정기의 가상 시제품을 생각해 보겠습니다.
전원이 켜져도, 측정 준비가 완료되어도 같은 표시등이 켜집니다.
개발팀은 내부 준비 시간이 필요하다는 사실을 알고 있어서 기다린 후 조작합니다.
처음 쓰는 사람은 불빛을 보고 바로 준비가 끝났다고 이해할 수 있을까요?

여기서 검토할 것은 단순히 불빛의 색이 예쁜지가 아닙니다.
사용자가 그 표시를 어떤 상태로 해석하고, 그 해석이 다음 행동에 어떻게 영향을 주는지가 핵심 질문입니다.
이 사례는 특정 제품에서 문제가 발생했다는 보고가 아닙니다.

팀은 먼저 표시가 전달하려는 의미를 문장으로 적어 볼 수 있습니다.
그다음 사용자가 어떤 정보를 보고 시작 여부를 판단하는지 살펴봅니다.
표시를 더 구분하는 안, 문구를 바꾸는 안 등은 설계 후보가 될 수 있지만, 어떤 안이 충분한지는 제품의 맥락과 확인 결과를 바탕으로 판단해야 합니다.
임의의 색상 변경만으로 문제가 해결되었다고 단정하지 않습니다.

선호도와 실제 행동을 구분해 기록합니다

“사용하기 편했다”는 의견은 참고할 수 있지만, 그 말만으로 어느 단계가 어려웠는지 알기는 어렵습니다.
자체 탐색에서 관찰하려는 행동을 미리 정리하면 질문이 더 구체적이 됩니다.

예를 들어 다음 조작을 찾느라 멈춘 지점, 표시를 다른 의미로 설명한 장면, 설명자의 도움을 받은 단계를 구분해 기록할 수 있습니다.
사용자가 망설였다는 사실과 그 이유에 대한 개발자의 추측도 분리합니다.
원인을 단정하기 전에 사용자에게 무엇을 이해했는지 확인할 필요가 있습니다.

위 표는 기록을 돕기 위한 예시이며 시험 판정표가 아닙니다.
성공·실패를 판단할 기준이나 평가의 조건은 실제 목적에 맞춰 별도로 정해야 합니다.

수정한 내용과 다시 확인할 질문을 연결합니다

관찰을 마친 뒤에는 발견한 장면을 설계 수정안과 연결해 보십시오.
단순히 “사용성 개선”이라고 적기보다 무엇이 불명확했고, 어떤 정보를 어떻게 바꾸려는지 설명하는 방식입니다.

가상의 표시등 사례라면 전원 켜짐과 준비 완료를 구분하는 것이 수정의 목적일 수 있습니다.
이 목적을 기록해 두면 이후에 수정 결과를 무엇으로 확인할지도 분명해집니다.
확인 과정에서 다른 상태를 혼동하게 되지는 않았는지처럼, 변경으로 새롭게 생길 질문도 함께 살펴볼 수 있습니다.

관찰 조건, 사용한 시제품의 버전, 제공한 안내를 남기는 것도 유용합니다.
서로 다른 버전이나 다른 설명 조건의 결과를 한데 묶으면 무엇 때문에 결과가 달라졌는지 설명하기 어려워집니다.
관련해서 성능시험 결과의 비교 조건을 다룬 글도 함께 참고할 수 있습니다.
시험의 목적은 다르지만, 비교할 조건을 명확히 해야 한다는 실무 질문은 연결됩니다.

내부 탐색과 최종 검증을 같은 것으로 부르지 않습니다

FDA 가이던스는 설계의 강점·약점과 예상하지 못한 사용 오류를 탐색하는 형성평가와, 개발 후반에 사용자 상호작용 및 위험 통제의 효과를 평가하는 인간공학 검증 시험을 구분합니다.
개발자가 시연했거나 일부 의견을 들었다는 사실만으로 최종 검증을 마쳤다고 표현해서는 안 됩니다.

팀 내부에서 질문을 정리하고 시제품을 살펴보는 작업은 다음 조사와 평가를 준비하는 데 사용할 수 있습니다.
다만 그 결과를 어느 범위까지 해석할 수 있는지 명확히 남겨야 합니다.
“이번 관찰에서 확인한 것”과 “아직 확인하지 않은 것”을 구분하는 방식입니다.

실제 평가의 대상 사용자, 과업, 사용 조건과 방법은 제품의 사용목적 및 관련 위험에 맞춰 계획해야 합니다.
이 글에는 제품별 시험 계획을 정할 정보가 없으므로 특정 인원이나 평가 방식이 충분하다고 제시하지 않습니다.

다음 설계 회의에 가져갈 다섯 질문

• 개발팀의 설명이 없어도 다음 행동을 알 수 있나요?
• 의도한 사용자의 역할과 경험을 실제로 확인했나요?
• 제품이 사용될 환경 중 아직 관찰하지 못한 조건은 무엇인가요?
• 관찰 사실과 원인에 대한 추측을 구분해 기록했나요?
• 수정 목적, 확인 결과와 남은 질문이 연결되어 있나요?

회의에서는 모든 질문에 즉시 답하려 하기보다, 가정으로 남아 있는 한 가지를 선택해 다음 확인 과제로 정해 볼 수 있습니다.
이 과정에서 제품의 위험 분석과 연결할 문제가 발견되면 관련 검토로 이어갑니다.
의료기기 위험관리의 근거 연결을 다룬 글에서 그 관점을 더 살펴볼 수 있습니다.

출처는 위에 링크한 FDA 공개 설명과 가이던스의 범위·정의 부분입니다.
가이던스 발행일은 2026년 8월 3일, 자료 확인일은 2026년 9월 21일입니다.
신규 규제 의무 발표를 다루는 글이 아니며, 가상 시제품과 표·질문은 MedQraft 자체 작성입니다.
특정 제품의 적합성 판정이나 임상 서비스 제공을 의미하지 않습니다.