프로세스와 안전의 비가시성: 보이지 않는 것은 존재하지 않는 것인가?

 

 

우리가 매일 사용하는 기술 시스템 속에는 수많은 ‘프로세스’가 작동하고 있습니다. 또한 이러한 시스템들이 우리의 생명과 재산을 위협하지 않도록 ‘안전’이 설계되어 있습니다. 하지만 이 모든 것들은 대부분 눈에 보이지 않습니다. 그리고 이 ‘보이지 않음’—즉, 비가시성(Invisibility)은 곧 신뢰의 부재와 문제 발생 시 무력함으로 이어집니다.

 

기술이 고도화될수록, 시스템은 복잡해지고, 그 안에서 작동하는 절차와 보호장치는 점점 더 추상적이고 불투명해집니다. 이는 특히 자동차, 철도, 항공, 제조 산업 등 사람의 생명과 직결되는 영역에서 매우 중요한 이슈가 됩니다.

 

이번 포스팅에서는 ‘프로세스’와 ‘안전’이 왜 비가시적인 존재가 되었는지, 그로 인해 발생하는 문제는 무엇인지, 그리고 어떻게 하면 다시 그것들을 ‘보이게’ 만들 수 있는지를 살펴 보겠습니다.

 

1. “보이지 않는 프로세스”: 시스템 신뢰의 사각지대

현대의 기술 시스템은 복잡하고 정교합니다. 버튼 하나로 수십 개의 연산이 일어나고, 센서 하나가 차량 전체의 움직임을 바꾸는 시대입니다. 겉으로 보기에는 단순한 동작처럼 보이지만, 그 내부에서는 수많은 연산과 판단이 진행되고 있습니다. 이 모든 과정은 하나의 목적을 위해 움직이는 ‘프로세스’라는 이름의 절차적 흐름입니다. 그러나 이 프로세스는 사용자에게도, 때로는 개발자에게도 ‘보이지 않는 것’으로 작동합니다. 그리고 바로 이 지점이 시스템 신뢰의 사각지대를 만들어냅니다.

 

시스템이 복잡해질수록, 그 내부 동작은 외부에서 관찰하거나 이해하기 어려워집니다. 특히 자동차와 같은 제어 시스템에서는 수십 개의 전자제어장치(ECU)가 독립적으로, 혹은 상호작용하면서 동작하게 됩니다. 각각의 기능은 정상적으로 수행되고 있는 것처럼 보일 수 있지만, 실제로는 ‘왜’, ‘언제’, ‘무엇을 기준으로’ 그런 판단을 내렸는지 명확히 설명되지 않는 경우가 많습니다. 이러한 현상을 우리는 프로세스의 비가시성이라고 말할 수 있습니다.

 

프로세스가 보이지 않는 상태에서 문제가 발생하면, 원인을 찾는 일은 매우 어려워집니다. 예를 들어 자동차에서 브레이크가 평소보다 늦게 작동했다고 가정해 보겠습니다. 이는 페달 센서의 지연일 수도 있고, 제어 알고리즘의 조건문 충돌일 수도 있으며, 혹은 상황 판단 로직에서 비정상적인 입력이 들어갔기 때문일 수도 있습니다. 문제는 그 모든 흐름이 시스템 내부에서 이루어지며, 외부에서는 그 흐름을 따라갈 수 없다는 데 있습니다.

 

개발자들은 종종 각 모듈별로 개발을 담당합니다. 기능별 사일로 구조 속에서 자신이 맡은 기능은 잘 작동하는 것으로 확인되었고, 테스트도 통과했습니다. 그러나 시스템이 통합된 이후에는 각 모듈 사이의 상호작용, 판단 우선순위, 예외 처리 로직이 얽히며 복잡한 상황이 만들어집니다. 이때 프로세스의 흐름이 눈에 보이지 않는다면, 문제가 생겨도 “우리 영역은 아니다”, “다른 팀에서 구현했다”는 식의 책임 회피성 대응이 나타나기 쉽습니다. 이는 곧 조직 신뢰의 붕괴로 이어집니다.

 

이러한 프로세스 비가시성은 시스템 개선도 어렵게 만듭니다. 프로세스를 개선하려면 먼저 현재 프로세스가 어떻게 동작하는지 파악해야 합니다. 하지만 많은 조직에서는 시스템이 잘못 동작했을 때조차 “재현되지 않는다”, “테스트에서는 이상 없었다”는 이유로 문제를 덮고 넘어가는 경우가 많습니다. 이는 보이지 않는 프로세스가 기술적 개선의 출발점조차 제공하지 못한다는 것을 의미합니다.

 

더 나아가 사용자 관점에서도 프로세스 비가시성은 신뢰를 위협합니다. 자율주행 차량이 갑작스레 멈췄을 때, 운전자는 그 이유를 알고 싶어합니다. 금융 시스템이 대출을 거절했을 때, 고객은 판단의 기준이 무엇이었는지 궁금해합니다. 하지만 “시스템이 그렇게 판단했습니다”라는 답변만이 돌아온다면, 사용자는 그 시스템을 신뢰하지 않게 됩니다. 시스템이 스스로의 행동을 설명하지 못한다면, 사용자는 그 결과를 받아들이지 않기 때문입니다.

 

정리 해 보면 프로세스의 비가시성은 결국 다음과 같은 문제를 일으킵니다:

• 문제가 발생해도 원인을 파악하기 어렵다.
• 사용자와 고객은 시스템이 ‘왜 그렇게 작동했는지’ 이해하지 못한다.
• 프로세스 개선의 기회가 사라진다.
• 표면적으로는 잘 작동하지만, 내부에서는 오류가 쌓이는 “잠복 결함”이 발생한다.

 

2. “보이지 않는 안전”: 안심의 환상

우리는 종종 “이 시스템은 안전합니다”라는 말을 듣습니다.

제품 광고나 기술 문서, 심지어는 실무 회의에서도 이런 표현은 매우 익숙하게 사용됩니다. 하지만 정작 그 시스템이 어떻게 안전한지, 어떤 위험을 고려했고 어떻게 대응하고 있는지는 설명되지 않는 경우가 많습니다. 결국 우리는 ‘안전하다’는 말만 듣고 스스로 안심하게 됩니다.

그렇지만 그 안심은 정말 타당한 것일까요? 혹시 우리는 보이지 않는 안전 속에서 안심이라는 환상에 빠져 있는 것은 아닐까요?

 

현대의 기술 시스템은 갈수록 복잡해지고 있습니다. 특히 자동차, 항공, 철도, 의료기기와 같은 고신뢰성이 요구되는 분야에서는 기능, 인터페이스, 통신, 사용 시나리오가 모두 유기적으로 연결되어 있습니다. 이러한 시스템에서는 단순히 “이 부품은 안전하다”, “이 기능은 인증받았다”는 말만으로 전체 시스템의 안전을 보장할 수 없습니다. 그럼에도 불구하고 우리는 종종 시스템을 ‘전체적으로 안전하다’고 판단합니다. 그 판단의 근거는 대부분 눈에 보이지 않으며, 때로는 단편적인 인증서나 테스트 결과일 뿐입니다.

 

안전은 보이는 것이 아닙니다.

불이 켜지듯 작동하는 것도 아니고, 소리로 알리는 것도 아닙니다. 시스템이 평상시에는 잘 작동하는 것처럼 보여도, 특정 조건에서 예상치 못한 상황이 발생할 때 그 시스템이 얼마나 안전한지를 알 수 있습니다. 하지만 그때는 이미 늦은 경우가 많습니다.

그래서 우리는 사전에 안전을 설계하고, 이를 보이는 방식으로 구조화해 두어야 합니다.

 

보이지 않는 안전은 다음과 같은 문제들을 동반합니다.

 

첫째, 사용자가 시스템의 위험 요소를 인식하지 못합니다.

“자동차가 자동으로 멈추겠지”, “센서가 알아서 판단하겠지”와 같은 막연한 기대는 실제로는 아무런 근거가 없는 낙관입니다. 사용자는 시스템이 어떤 한계를 가지고 있는지, 어떤 상황에서 오작동할 수 있는지 알지 못한 채 그저 기술을 믿게 됩니다.

 

둘째, 개발자조차도 시스템의 안전 메커니즘이 어떻게 구현되었는지 명확히 설명하지 못합니다.

많은 시스템은 여러 팀에 의해 개발되며, 각 팀은 자신의 역할에 집중하기 때문에 전체적인 안전 구조를 파악하지 못하는 경우가 많습니다. 그 결과, 기능은 구현되었지만 위험 시나리오에 대응하는 안전 기능은 누락되거나 비일관적인 방식으로 분산되어 있습니다.

 

셋째, 인증을 위한 문서와 실제 구현 사이에 괴리가 발생합니다.

기능안전 문서는 프로젝트 초기에 정리되어 제출되지만, 시스템은 계속 변화하고 발전합니다. 이 과정에서 문서와 구현의 일치성이 점점 떨어지게 되고, 검증되지 않은 상태에서 ‘인증받은 시스템’으로 오해되기 쉬운 구조가 만들어집니다. 

 

즉, 안전은 문서와 숫자로만 존재할 뿐, 시스템의 어느 부분에 어떤 안전 메커니즘이 존재하는지는 보이지 않습니다. 그리고 이러한 안전의 비가시성은 실무에서 다음과 같은 문제로 연결됩니다:

•  안전 분석 결과가 설계에 반영되지 않는 문제
•  안전 요구사항과 기능 구현 사이의 추적 불가능성
•  인증 심사 대응은 되지만, 실제로는 안전하지 않은 시스템
•  사용자 관점에서는 시스템의 안전을 체감할 수 없는 구조

 

3. 비가시성이 초래하는 조직적 문제

비가시성은 단순히 시스템의 동작이 외부에서 보이지 않는다는 기술적인 문제로만 이해되기 쉽습니다. 그러나 실제로는 이보다 훨씬 광범위한 영향을 미칩니다. 비가시성은 곧 소통 단절, 책임 회피, 개선 무력화, 신뢰 붕괴라는 형태로 조직 전반에 문제를 일으킵니다. 이러한 영향은 특히 협업이 필수적인 소프트웨어 조직, 자동차 제어 시스템 개발 조직, 대규모 프로젝트 환경에서 뚜렷하게 나타납니다.

 

먼저, 비가시성은 협업의 단절을 초래합니다.

대부분의 시스템은 여러 팀이 나눠서 개발합니다. 한 팀은 입력을 다루고, 다른 팀은 판단 로직을 구성하며, 또 다른 팀은 출력과 제어기를 담당합니다. 이런 구조에서 프로세스 흐름이 눈에 보이지 않는다면, 각 팀은 자신이 맡은 기능만 구현하고 끝나게 됩니다. 서로가 서로의 입력과 출력을 이해하지 못한 채, 단절된 기능들만 시스템에 존재하게 되는 것입니다.

 

결국 문제가 생겼을 때, “이건 우리 쪽 기능이 아니다”, “그건 다른 팀이 처리하는 로직이다”라는 말이 반복됩니다. 문제는 전체 시스템의 상호작용에서 발생했지만, 각 팀은 자신의 책임이 아니라고 말하게 됩니다. 이처럼 비가시성은 협업을 단절시키고, 시스템을 기능 단위의 고립된 섬들로 만들어 버립니다.

 

두 번째로, 비가시성은 책임의 부재를 초래합니다.

문제가 발생했을 때, 우리가 가장 먼저 해야 할 일은 ‘무엇이 잘못되었는가’를 파악하는 것입니다. 하지만 시스템의 내부 동작이 보이지 않는다면, 원인을 파악하기가 어렵습니다. 원인이 명확하지 않으면, 책임도 명확히 할 수 없습니다.

이는 결국 모든 문제에 대해 “누가 책임져야 하는가”가 아니라 “책임질 수 있는 사람이 없다”는 결론으로 이어집니다. 그 결과, 시스템은 반복적으로 같은 문제를 겪고도 제대로 고쳐지지 않으며, 개인은 방어적인 태도로 일하게 됩니다. 이러한 조직 문화에서는 창의적인 개선이나 혁신은 일어나기 어렵습니다. 대신 위험 회피와 보신주의가 팽배해지고, “지시 받은 것만 하자”는 분위기가 형성됩니다.

 

세 번째로, 비가시성은 지속적인 개선을 어렵게 만듭니다.

조직은 끊임없이 시스템을 개선해야 합니다. 하지만 개선이 이루어지려면, 현재 시스템이 어떻게 작동하고 있고, 그 작동 방식에 어떤 문제가 있는지를 먼저 정확히 이해해야 합니다. 그러나 시스템 내부가 보이지 않는다면, 개선은 표면적인 수정이나 우회 처리에 그치게 됩니다.

이는 마치 병의 근본 원인은 모른 채 증상만 억제하는 것과 같습니다.

또한 시스템이 어떻게 작동하는지 모르는 상태에서는 새로운 기능을 추가하거나 기존 기능을 변경하는 것 자체가 큰 리스크가 됩니다.

작은 변경이 예기치 않은 부작용을 일으킬 수 있고, 그 영향 범위를 사전에 예측하지 못하게 됩니다.

이로 인해 개선은 점점 더 어려워지고, 시스템은 점점 더 유지보수가 힘든 구조로 고착화됩니다.

 

마지막으로, 비가시성은 조직 내 신뢰를 무너뜨립니다.

신뢰란 단지 사람이 사람을 믿는다는 의미를 넘어, 시스템이 예측 가능하게 동작할 것이라는 믿음, 내가 의존하고 있는 구성 요소가 안정적으로 기능할 것이라는 믿음, 문제가 발생했을 때 조직이 투명하고 공정하게 대응할 것이라는 믿음을 포함합니다.

하지만 시스템이 어떤 기준으로 판단했는지 설명되지 않고, 문제 발생 시 명확한 대응이 없다면, 신뢰는 빠르게 무너지게 됩니다. 팀원들은 시스템을 믿지 않게 되고, 서로를 신뢰하지 않게 되며, 결정권자에 대한 신뢰도 약화됩니다. 결국 조직은 서로를 의심하고, 책임을 전가하며, 공동의 목표보다는 개인의 방어에 집중하게 됩니다.

이러한 상태에서는 협업도 개선도 불가능합니다.

 

비가시성은 기술적 한계에서 시작되지만, 궁극적으로는 조직문화의 병리현상으로 발전합니다. 이러한 문제를 해결하기 위해서는 단순히 기술 문서를 보강하거나 개발 가이드를 늘리는 것으로는 부족합니다. 무엇보다 중요한 것은 시스템의 내부 동작을 가시화하고, 그 흐름을 모든 구성원이 이해할 수 있도록 구조화하는 것입니다.

 

 

4. 어떻게 ‘보이게’ 만들 것인가?

그렇다면 우리는 어떻게 이 시스템의 ‘보이지 않음’을 ‘보이게’ 만들 수 있을까요? 

 

첫째, 동작을 구조화하여 보여줘야 합니다

기능이 구현되어 있다고 해서 그 기능이 이해되는 것은 아닙니다. 어떤 기능이, 언제, 어떤 조건에서, 어떤 흐름에 따라 실행되는지를 구조화된 형태로 보여주는 것이 그 시작입니다. 이는 단순한 플로우차트나 다이어그램이 아니라, 실제 실행 경로와 판단 기준이 담긴 시나리오 기반 흐름 표현이어야 합니다. 예를 들어, 자율주행 시스템에서 갑작스러운 정지 상황이 발생했을 때, “어떤 센서 입력이 판단 로직에 어떤 영향을 주었고, 그 결과 어떤 제어 명령이 실행되었는가”를 시나리오 흐름으로 보여줘야 합니다.

 

이를 위해 시스템 개발 과정에서 입력 → 판단 → 출력의 경로를 기능 단위로 추적 가능한 구조로 문서화하고, 각 경로별로 조건 분기와 예외처리 흐름을 명확히 해 두는 것이 필요합니다. 이런 구조화 없이는 시스템은 여전히 블랙박스 상태로 남게 됩니다.

 

둘째, 시스템의 ‘판단’을 설명할 수 있어야 합니다

오늘날 많은 시스템이 AI나 복잡한 로직 기반 판단을 수행합니다. 그러나 판단은 결과만으로는 설명될 수 없습니다. 우리가 신뢰를 갖기 위해서는 “왜 그렇게 판단했는가”라는 질문에 답할 수 있어야 합니다. 이런 설명 가능성을 확보하기 위한 방법 중 하나가 GSN(Goal Structuring Notation)입니다. GSN은 시스템이 특정 행동을 하게 된 이유를 주장(Goal) - 전략(Strategy) - 근거(Solution)의 구조로 표현합니다. 예를 들어, “이 시스템은 교차로에서 멈추는 것이 안전하다”는 주장을 구조화하여,

• 어떤 판단 로직이 사용되었고
• 어떤 상황 데이터를 근거로 삼았으며
• 그 판단이 어떤 조건에서 타당한지를
• 한눈에 파악할 수 있도록 합니다.

이처럼 판단 로직을 설명 가능하게 만드는 것은 단순한 기술이 아니라 사용자와 시스템, 개발자 간의 신뢰를 회복하는 과정입니다.

 

GSN(Goal Structuring Notation) 해석 - 안전케이스(Safety Case) 작성 규칙

 

GSN(Goal Structuring Notation) 표기법 - 안전케이스(Safety Case)/보안케이스(Security Case) 작성

 

GSN(Goal Structuring Notation) - 안전 케이스(Safety Case, ISO 26262), 보안 케이스(Security Case, ISO 21434)

 

셋째, 동작 기록을 추적할 수 있어야 합니다

시스템이 “왜 그렇게 행동했는가”를 설명하려면, 그 동작이 기록되어 있어야 합니다. 이것이 바로 로깅(logging)과 트레이싱(tracing)의 중요성입니다. 많은 시스템이 로그는 남기지만, 그 로그가 문제 해결이나 설명에 실질적으로 도움이 되지 않는 경우가 많습니다. 이는 로그가 단편적이고, 흐름이 연결되지 않으며, 의미가 명확하지 않기 때문입니다.

가시성 있는 로그란,

• 어떤 조건에서 어떤 판단이 내려졌고,
• 어떤 결과가 발생했으며,
• 그 판단에 영향을 준 변수는 무엇인지가
• 시간 순서와 흐름 단위로 표현된 로그입니다.

이러한 로그는 단지 디버깅 용도가 아니라, 시스템이 사용자를 향해 “나는 이렇게 판단했어요”라고 설명하는 언어가 됩니다.

 

넷째, 시스템의 의도와 실제 구현을 일치시켜야 합니다

많은 경우 시스템은 설계 당시 의도한 바와 다르게 동작합니다. 그 이유는 요구사항이 변경되었거나, 구현 과정에서 단순화되었거나, 검토가 누락되었기 때문입니다. 이런 설계와 실행 간의 불일치는 시스템의 가시성을 크게 떨어뜨립니다. 이를 해소하려면, 요구사항 → 설계 → 구현 → 테스트 → 릴리스까지의 모든 단계가 추적 가능(traceable) 해야 합니다. 즉, 어떤 요구가 어떤 설계를 낳았고, 그 설계가 어디에 구현되었으며, 어떤 테스트로 검증되었는지를 연결할 수 있어야 합니다. 

이러한 추적 구조는 단순한 도구 사용만으로는 어렵습니다. 명확한 명세 작성, 코드 주석화, 요구사항 기반 테스트 케이스 설계, 변경관리 절차의 엄격한 적용 등이 함께 수행되어야 합니다. 이것이 바로 시스템의 ‘의도’와 ‘현실’을 보이게 만드는 과정입니다.

 

다섯째, 가시성을 조직 문화로 만들어야 합니다

마지막으로, 아무리 기술적으로 시스템을 보이게 만들어도, 그 정보가 공유되지 않고, 이해되지 않으며, 협업에 반영되지 않는다면, 그 가시성은 아무 의미가 없습니다. 진정한 가시성은 조직 내 커뮤니케이션과 태도, 문화의 변화와 함께할 때 비로소 실현됩니다. 팀원들은 자신이 만든 기능이 전체 시스템에서 어떤 역할을 하는지 알고 있어야 하며, 문제가 발생했을 때 “내 책임이 아니다”가 아니라 “어디에서 연결이 끊겼는가”를 함께 찾을 수 있는 문화가 필요합니다. 이는 리더의 역할이기도 합니다. 가시성을 위한 문서화를 강조하고, 리뷰를 제도화하며, 설명 가능한 개발을 독려하고, “왜 이렇게 설계했는가?“라는 질문을 당연하게 여기는 분위기를 만드는 것이 중요합니다.

 

---

결론: 보이게 만든다는 것은 설명 가능하게 만드는 일입니다

기술이 고도화될수록 시스템은 더 잘 작동하는 듯 보이지만, 실제로는 더 깊은 어둠 속으로 숨게 됩니다.

그 어둠을 걷어내고, 시스템을 보이게 만드는 일은 단지 도구나 기술의 문제가 아닙니다.

그것은 설계자의 태도이며, 조직의 책임이고, 사용자에 대한 예의입니다.

 

“보이게 만든다”는 것은 곧

• 시스템이 왜 그렇게 동작했는지 설명할 수 있어야 하며,
• 문제가 발생했을 때 원인을 추적할 수 있어야 하며,
• 모든 구성원이 동일한 이해 위에 설 수 있어야 한다는 의미입니다.

보이지 않는 시스템은 결국 신뢰를 잃습니다. 그리고 보이지 않는 안전은 존재하지 않는 것과 같습니다.

 

이제 우리는 기술을 만드는 사람으로서, 시스템을 ‘잘 만드는 것’만큼 ‘잘 보이게 만드는 일’도 함께 고민해야 합니다.