대학원 시절, 연구를 하거나 논문을 읽을 때 가장 중요한 기준은 제안하는 시스템의 안전성(soundness)과 완전성(completeness)이었습니다. 그리고 이 두 가지를 이야기하려면 반드시 필요한 개념이 두 가지 있었습니다. 바로 오탐(false positive)과 미탐(false negative)입니다.
처음 두 개념을 배울 때는 시스템을 평가하는 지표로만 이해했습니다. 그런데 회사에 취업하고, 다양한 연구를 접하게 되면서 이 개념은 단순히 지표가 아니라 생각의 틀로 확장되었습니다. 외부 기술을 이해할 때, 보고 자료를 검토할 때, 그리고 현재는 AI와 협업할 때까지, 오탐과 미탐은 제가 다른 기술이나 주장을 판단하는 기준이 되었습니다.
이 글에서는 그 기준이 무엇이고, 어떻게 쓰임이 넓어졌는지를 정리했습니다. 개념에서 출발해 실체와 뷰, 외부 기술의 이해, 리더의 검토 도구, 그리고 AX 시대의 비판적 시각까지 순서대로 기술했습니다.
목 차
오탐과 미탐
두 개념의 정의는 아주 간단합니다. 오탐은 아닌 것을 맞다고 판정하는 것이고, 미탐은 맞는 것을 놓치는 것입니다.
처음 이해할 때 예로 들었던 것이 대학의 입학 시스템이었습니다. 똑똑한 학생을 뽑는 것이 목적인 입학 시스템이 있다고 가정해 보겠습니다. 그런데 현실에서는 똑똑하지 않은 학생이 입학에 성공하기도 하고, 똑똑한 학생이 입학 시스템을 통과하지 못하기도 합니다. 전자가 오탐에 해당하고, 후자가 미탐입니다. 어떤 시스템이든 오탐과 미탐은 늘 존재합니다.
위조지폐 분류기도 마찬가지입니다. 진짜 지폐를 위조로 걸러내기도 하고, 위조지폐를 통과시키기도 합니다. 기술이 발달하면서 두 확률 모두 줄어들지만, 아직 0%라고 말하기는 어렵습니다.
그리고 보통은 두 오류는 서로 맞물려 있습니다. 분류 기준을 엄격하게 강화하면 오탐이 줄어드는 대신 미탐이 늘어나고, 느슨하게 풀면 그 반대가 됩니다. 두 오류를 동시에 0으로 만드는 건 어렵기 때문에, 시스템을 설계한다는 것은 결국 어느 오류를 더 허용하는 게 나은지 결정하는 일이 되기도 합니다. 가령, 의학적 검진 시스템은 의도적으로 오탐을 좀 더 허용하는 쪽으로 기울어 있는 것이 그 예입니다. 놓치는 것보다 한 번 더 의심하는 편이 낫기 때문입니다.
실체와 뷰
연구 및 실무 경험이 쌓이면서 자연스럽게 확장하게 된 개념이 바로 실체와 뷰(view)에 대한 구분입니다.
어떤 눈에 보이지 않는 대상이 있을 때 정확히 이해하기도 어렵고, 남에게 설명하는 것은 더 어렵습니다. 그래서 우리는 뷰를 통해 그 대상을 가시화합니다. 시스템의 성능을 지표로 표현하고, 조직의 상태를 보고서로 요약하는 것이 모두 뷰입니다. 뷰는 필요한 정보를 추상화하여 이해할 수 있는 형태로 만들어 줍니다. 그런데 뷰는 실체와 동일한 대상이 아니기 때문에, 뷰에는 앞서 언급한 두 종류의 오류가 따라붙습니다.
먼저 왜곡, 즉 오탐입니다. “평균 응답시간 200ms”라는 지표는 대부분의 요청이 빠르다는 인상을 주지만, 실제로는 일부 요청이 수 초씩 걸리는 상황을 감출 수 있습니다. 유리한 측정 구간만 골라 보여주는 벤치마크, 절대량(2건에서 1건)을 숨기는 “에러 50% 감소” 같은 비율 표현도 같은 부류입니다. 측정한 값 자체는 사실이지만, 구성된 뷰가 왜곡을 만듭니다.
다음은 누락, 즉 미탐입니다. 2차 세계대전 당시 통계학자 Abraham Wald의 연구에 따르면, 귀환한 폭격기의 피탄 데이터만 분석하면 격추된 기체의 정보가 통째로 빠집니다. 뷰에 담기지 않은 데이터가 판단에서 제외되는 경우입니다. 측정하지 않는 지표는 뷰에 존재하지 않습니다. 또, 트리구조로 추상화된 공식 조직도에는 실제 협업과 의사소통의 경로가 담기지 않습니다.
소프트웨어 아키텍처 설계에서 다양한 뷰를 혼합해 사용하는 이유가 여기에 있습니다. 대표적으로, Kruchten이 제안한 4+1 뷰 모델이 있습니다. 하나의 시스템을 논리 뷰, 프로세스 뷰, 개발 뷰, 물리 뷰의 네 관점으로 나누어 기술하고, 시나리오가 이들을 묶습니다. 각 뷰는 하나의 관심사를 정확히 담기 위해 나머지를 의도적으로 생략합니다. 클래스 구조를 담는 논리 뷰에는 배포 구성이 없고, 배포를 담는 물리 뷰에는 코드의 의존 관계가 없습니다. 그래서 단일 뷰로 시스템을 판단하면 반드시 놓치는 것이 생기고, 하나의 뷰를 실체로 착각하면 왜곡이 생깁니다. 여러 뷰를 겹쳐서 보는 것이 뷰의 오탐과 미탐을 보완하는 방법입니다.
외부 기술을 이해하는 관점
국내외 연구소에서 근무하던 시절, 제 업무 중 중요한 부분을 차지했던 일이 다양한 아이디어와 외부 기술을 이해하고 판단하는 것이었습니다. 내부 팀원들로부터 올라오는 여러 제안을 리뷰하는 일도 있었습니다. 새로운 기술 설명을 접할 때마다 판단할 기준이 필요했는데, 그때 이러한 관점들을 활용했습니다. 우선 시스템의 기능을 이해하고 나면, 이후에는 복잡한 설명을 걷어내고 “이 시스템은 어디서 어떻게 틀리는가”를 물으면 구조를 확인할 수 있었습니다.
추천 시스템이 좋은 예입니다. 복잡한 용어로 설명되지만, 결국 오류는 두 가지로 정리됩니다. 관심 없는 것을 추천하는 오탐, 그리고 원했을 것을 보여주지 못하는 미탐입니다. 시스템의 오류를 이 두 개념으로 이해하고 나면, 그 시스템이 어느 쪽을 포기하도록 설계되었는지를 짐작할 수 있습니다.
AI의 할루시네이션도 마찬가지입니다. 기술적 디테일은 다르지만, 이해하는 관점에서는 오탐의 전형적인 예입니다. 진짜라고 판정해 자신 있게 내놓았지만 실제로는 사실이 아닌 답변을 출력했기 때문입니다.
기술마다 용어는 바뀝니다. 그러나 오류를 이해하는 기준은 바뀌지 않습니다.
리더의 검토 도구
리더의 자리에 있을 때도 이 관점을 자주 활용했습니다. 보고를 받을 때 내용을 검토하는 도구입니다.
“A라는 기술을 적용해서 기존보다 성능이 XX% 좋아졌습니다”라는 보고를 받으면, 저는 자연스럽게 두 방향의 질문을 하게 됩니다. 먼저 놓치는 것이 없는지, 어떤 부작용이 있는지를 물어봅니다. 미탐의 개념이 작동하는 것입니다. 그리고 성능 측정을 어떻게 했는지, 정보에 왜곡은 없는지를 물어봅니다. 이번에는 오탐이 작동합니다.
두 질문은 보고자를 의심하는 것이 아니라 일종의 검산 과정입니다. 주장에 반대하거나 요청을 반려하기 위한 것이 아니라, 그 주장의 근거를 확인하는 저만의 절차입니다.
오탐과 미탐에 대한 감각은 이렇게 기술을 이해하는 것을 넘어, 주장을 판단하는 큰 도구가 됩니다.
AX 시대, 여전히 유효한 시각
경험있는 엔지니어라면 누구나 각자 세상을 바라보는 관점이 있을 것입니다. 저에게는 오탐과 미탐이 그 관점 중 하나였고, AX 시대가 되면서 이런 비판적인 시각은 더 필요해졌다고 생각합니다.
AI에게 업무를 위임해야 하는 시대입니다. 그렇다면 어떤 시선으로 AI와 소통해야 할까요. AI의 결과물에도 오탐은 언제든 있을 수 있습니다. 그럴듯한 형식과 자신 있는 어조가 사실을 보장하지 않기 때문입니다. 또한 AI가 내놓지 않은 것, 즉 미탐도 있습니다. 결과물에 담기지 않은 선택지와 부작용은 묻지 않으면 보이지 않습니다.
특히 AI와 작업을 할 때는 편향에 주의해야 합니다. 가령, AI에는 학습 데이터의 편향이 있을 수 있습니다. 데이터에 적게 등장한 집단과 사례에서 미탐이 집중됩니다. 무작위 누락이 아니라 특정 방향으로 쏠린 미탐이 발생합니다. 또 사용자 입장에서 AI가 자기 생각과 일치하는 답을 내놓으면 검토 없이 통과시키는 확증 편향도 있습니다. 보고 싶은 것을 사실로 판정하는 오탐입니다.
두 편향이 같은 방향으로 겹칠 때 오류는 증폭됩니다. AI의 미탐과 사용자의 오탐이 서로를 가려주기 때문입니다. AX 시대에 비판적 시각이 필요한 이유가 여기에 있습니다.
결국 필요한 것은 리더로서 가졌던 비판적 사고, 엔지니어 관점에서 가졌던 비판적 사고입니다. 주장에 대한 오탐과 미탐을 찾아내려던 그 관점이 AI와의 협업에서도 여전히 유효합니다.
맺음말
기술은 바뀌고, 도구도 바뀌고, 판단의 대상도 바뀝니다. 그러나 판단의 기준은 오래 갑니다. 무엇을 근거로 옳다고 하는지, 어디서 틀릴 수 있는지 아는 것이 중요합니다. 그리고 이를 관통하는 원칙을 세우는 것이 중요합니다. 저에게 오탐과 미탐은 그 원칙을 세우는 하나의 방법이었습니다. 하지만 더 중요한 것은 자신의 판단 기준을 가지고 그것을 계속 점검하는 태도입니다. AX 시대에 엔지니어와 리더에게 필요한 것입니다.
AX 시대에 엔지니어와 리더에게 함께 필요한 것은 변하지 않는 판단 기준입니다.
ChulJoo Kim (김철주)
※ 참고문헌
- Abraham Wald, 「A Method of Estimating Plane Vulnerability Based on Damage of Survivors」, Center for Naval Analyses(CRC 432), 1980(원저 1943). https://apps.dtic.mil/sti/citations/ADA091073
- Philippe Kruchten, 「The 4+1 View Model of Architecture」, IEEE Software, 1995.11. https://ieeexplore.ieee.org/document/469759
ckarch.kr
© 2026
is licensed under
CC BY-NC-SA 4.0
