“장인은 도구를 탓하지 않는다”라는 말이 있다. 그러나 이 말은 역설적으로, 장인이 아닌 대부분의 사람들에게는 도구의 품질이 결과의 품질을 좌우한다는 사실을 전제하고 있다. 시스템을 만드는 엔지니어 역시 예외가 아니다. 특히 시스템 안전의 영역에서는 개인의 숙련도나 노력보다, 어떤 도구를 선택하고 그 도구에 얼마나 의존하는가가 결과의 신뢰성을 결정짓는다.
대부분의 시스템은 한 명의 장인이 아니라, 수많은 엔지니어와 조직, 그리고 긴 시간 위에서 만들어진다. 이 과정에서 결과의 완성도와 안전성은 개인의 역량보다 “무엇을 믿고 작업했는가”에 더 크게 좌우된다. 시스템 안전의 관점에서 그 ‘믿음’의 대상은 점점 사람에서 도구로 이동하고 있다.
우리는 이미 COTS를 통해, 이야기 밖에서 가져온 구성품이 시스템에 어떤 영향을 미치는지 경험해 왔다. 이제 질문은 한 단계 더 안쪽으로 들어온다. 시스템을 구성하는 제품이 아니라, 시스템을 만들어내는 과정에서 사용하는 도구는 과연 얼마나 신뢰할 수 있는가다. 대부분의 사람들은 장인이 아니기에, 도구라도 좋아야 믿을 만한 결과를 만들어낼 수 있다.
좋은 도구를 고르고, 그 도구를 사용해 시스템을 만드는 것. 이것이 ROTS다. Reliance on Tools라는 이름이 말해주듯, ROTS는 단순한 툴 선택의 문제가 아니라, 우리가 시스템 안전을 어디까지 도구에 맡기고 있는지를 묻는 개념이다. 이 글은 그 질문에서 출발한다.
ROTS는 Reliance on Tools, 즉 도구에 대한 의존성을 분석하는 개념이다. 여기서 말하는 도구는 단순한 편의 수단이 아니다. 요구사항을 정의하고, 설계를 고정하며, 분석 결과를 정당화하고, 때로는 안전성을 “증명해 주는 것처럼 보이는” 모든 엔지니어링 툴을 의미한다. 좋은 도구를 고르고, 그 도구가 만들어내는 전제와 한계를 이해한 채 시스템을 만드는 것. 이것이 ROTS의 본질이다.
ROTS는 “이 도구가 좋은가?”를 묻지 않는다.
대신
“우리는 이 도구에 무엇을 맡기고 있는가?”
를 묻는다.
ROTS는 종종 COTS와 혼동되지만, 두 개념은 분석 대상과 방향이 다르다. COTS는 외부에서 완성된 구성품을 시스템에 통합하여 사용하는 것을 전제로 한다. 운영체계, 하드웨어 모듈, 상용 소프트웨어처럼 시스템 내부로 들어오는 ‘제품’이 대상이다. 핵심 질문은 이것이다. “이 블랙박스를 시스템 안에 넣어도 되는가?”
반면 ROTS는 시스템을 만드는 과정에 사용되는 도구를 다룬다. 요구사항 관리 툴, 모델 기반 설계 툴, 시뮬레이션 소프트웨어, 안전 분석 자동화 도구 등—이들은 시스템의 일부로 남지 않지만, 시스템의 형태와 논리를 결정한다.
즉,
COTS가 시스템이 무엇으로 구성되는가의 문제라면,
ROTS는 시스템이 어떻게 사고되었는가의 문제다.
ROTS 분석의 핵심은 도구의 기능이 아니라, 도구가 만들어내는 의존성에 있다. 한 번 선택된 도구는 단순히 일을 편하게 해주는 수준을 넘어, 설계 방법을 고정시키고 데이터 구조를 제한하며 팀의 작업 방식과 의사결정 흐름까지 규정한다. 이 의존성은 초기에 눈에 띄지 않지만, 시간이 지날수록 기술적 부채가 아니라 안전 부채(safety debt)로 조용히 쌓인다.
현대 시스템 엔지니어링에서 도구는 더 이상 중립적이지 않다. 도구는 특정 모델링 철학과 분석 가정을 전제로 하며, 어떤 위험은 강조하고 어떤 위험은 자연스럽게 가려버린다. 다시 말해, 도구는 우리가 무엇을 “중요하다고 보게 되는지”를 결정한다. 이 지점에서 문제가 발생한다. 우리가 종종 다음을 혼동한다.
“도구가 계산했다”는 사실을 “위험이 충분히 분석되었다”는 의미로 착각하고,
“리포트가 생성되었다”는 결과를 “안전이 입증되었다”는 결론으로 오인한다.
ROTS 분석이 없는 환경에서는 시스템 결함의 원인이 대부분 사람의 실수나 절차 미준수로 기록된다. 그러나 그 원인을 더 깊이 추적해 보면, 잘못 선택된 도구, 과도한 자동화에 대한 신뢰, 검증되지 않은 분석 결과가 숨어 있는 경우가 많다. 잘못된 도구는 잘못된 질문을 하게 만들고, 보이지 않는 위험을 마치 분석이 끝난 것처럼 포장한다. ROTS는 바로 이 보이지 않는 전제를 수면 위로 끌어올리기 위해 필요하다.
그렇기 때문에 ROTS는 단순한 기능 비교나 벤더 데모로 끝날 수 없다. 시스템 엔지니어는 해당 도구가 장기간 사용 가능한지, 즉 안정성(stability)을 제공하는지 질문해야 한다. 업데이트 주기와 호환성 정책은 예측 가능한가, 특정 버전에 묶여 분석 기준이 흔들리는 구조는 아닌가를 점검해야 한다. 동시에 도구가 동일한 조건에서 신뢰 가능한 결과를 반복적으로 제공하는지, 신뢰성(reliability) 역시 핵심 검증 대상이 된다.
여기서 끝이 아니다. 시스템은 반드시 변화한다. 요구사항은 바뀌고, 규제는 강화되며, 운영 환경은 예측 불가능하게 진화한다. 이 변화 속에서 도구가 지속적으로 따라올 수 있는지, 내부적으로 관리되고 계승될 수 있는지—즉 유지성(maintainability)—이 확보되어야 한다. 더 나아가, 벤더 정책 변경이나 시장 철수로 인해 도구 자체가 더 이상 사용 불가능해지는 상황을 대비해야 하는데, 이는 곧 가용성(availability)의 문제다.
좋은 도구를 고르고, 그 도구가 만들어내는 한계와 전제를 이해한 채 시스템을 만드는 것. 이것이 ROTS다.
Reliance on Tools라는 이름이 말해주듯, ROTS는 도구를 맹목적으로 믿으라는 이야기가 아니다. 오히려, 우리가 무엇을 믿고 있는지를 자각하라는 경고에 가깝다.
시스템 안전은 언제나 기술의 문제가 아니라 선택의 문제였다. 그리고 그 선택의 출발점에는, 눈에 잘 띄지 않지만 가장 오래 함께하게 될 도구가 있다.
1. 도구의 역할 정의 - 무엇을 이 도구에 맡기고 있는가
첫 단계는 단순하지만 가장 중요하다. 해당 도구가 시스템 개발 생애주기에서 단순 보조 수단인지, 아니면 판단과 결론을 대신하는지 명확히 해야 한다. 안전 인증 자료로 사용되는 결과를 생성한다면, 이미 핵심 ROTS 대상이다.
단순 기록용인가, 의사결정 근거를 생성하는가
분석 결과가 안전 인증 자료로 사용되는가
사람의 검토 없이 자동으로 결과를 생성하는가
도구가 단순한 작업 보조를 넘어, “결과의 정당성”을 제공하는 순간부터 ROTS 대상이 된다. 이 정의가 불분명하면 이후 모든 평가는 의미를 잃는다.
2. 도구 의존성 식별 - 사람이 아니라 도구가 결정하는 지점
다음은 도구에 대한 의존성 지도를 그리는 단계다. 이 도구 없이는 과거 결과를 재현하거나 이해할 수 없는 지점을 식별한다. 도구가 사고 과정의 일부가 되는 순간, 의존성은 위험이 된다.
특정 포맷으로만 데이터가 저장되는가
해당 도구 없이는 과거 산출물을 해석할 수 없는가
다른 도구로의 전환 시 의미 손실이 발생하는가
이 단계에서 중요한 질문은 하나다.
“이 도구가 사라지면, 우리는 시스템을 이해할 수 있는가?”
ROTS 분석은 도구 사용 자체가 아니라, 도구 없이는 사고가 불가능해지는 구조를 위험으로 본다.
3. 안정성(Stability) 평가 - 시간이 지나도 같은 기준을 유지하는가
시스템은 수년, 때로는 수십 년간 유지된다. 시간이 지나도 동일한 입력에 대해 동일한 기준의 결과를 제공하는지, 버전 변화가 분석의 일관성을 깨지 않는지 확인해야 하며, 도구는 그 시간을 견딜 수 있어야 한다.
주요 기능이 잦은 업데이트로 바뀌지는 않는가
동일한 입력에 대해 버전별 결과 차이가 발생하는가
장기 프로젝트에서 기준선(baseline)을 유지할 수 있는가
안정성이 낮은 도구는 분석 품질을 흔들고, 결과의 추적성을 붕괴시킨다.
4. 신뢰성(Reliability) 검증 - 결과를 믿어도 되는가
ROTS에서 말하는 신뢰성은 “버그가 적다”는 의미가 아니다. 도구의 알고리즘 가정, 한계, 예외 처리가 명확한지 확인해야 한다. 가장 위험한 도구는 틀린 결과를 조용히 출력하는 도구다.
알고리즘의 가정이 문서화되어 있는가
경계 조건이나 예외 상황이 명확히 정의되어 있는가
잘못된 입력에 대해 경고를 제공하는가, 아니면 조용히 계산하는가
신뢰할 수 없는 도구의 가장 큰 위험은,
틀린 결과를 그럴듯하게 보여준다는 점이다.
5. 유지성(Maintainability) 평가 - 사람이 바뀌어도 살아남는가
도구는 조직보다 오래 남기도 한다. 특정 개인의 경험에 의존하지 않아도 사용할 수 있는지, 문서와 교육 체계가 유지되는지 살핀다.
특정 개인만 알고 있는 설정이나 운용 방식은 없는가
내부 로직을 이해하지 못하면 사용이 불가능한가
교육, 문서, 사용자 커뮤니티가 지속적으로 유지되는가
ROTS 관점에서 유지성이 낮은 도구는 “현재 팀에게만 안전한 도구”일뿐이다.
6. 가용성(Availability) 및 벤더 리스크 - 내일도 쓸 수 있는가
마지막으로, 현실적인 질문을 던져야 한다. 여기서는 라이선스 변경, 지원 종료, 정책 변화가 시스템 안전 활동에 미치는 영향을 분석한다. 도구 역시 공급망의 일부다.
벤더가 정책을 바꾸면 우리는 대응할 수 있는가
라이선스 변경, 클라우드 종료, 지역 규제로 인한 영향은 없는가
오프라인 접근이나 백업 경로가 존재하는가
도구는 기술 자산이 아니라 공급망 요소다. ROTS는 이를 안전 분석의 범위 안으로 끌어온다.
ROTS 분석은 별도의 문서 한 장으로 끝나지 않는다. 도구 선정 시점, 프로젝트 초기 아키텍처 결정 단계, 안전 계획 수립 과정에 자연스럽게 통합되어야 한다.
신규 툴 도입 전: ROTS 사전 평가
장기 프로젝트 중간: 도구 의존성 재점검
인증 또는 사고 분석 이후: 도구 역할에 대한 사후 검증
중요한 것은, 도구를 선택한 사실보다 선택의 근거가 기록되는 것이다.
좋은 도구를 고르고, 그 도구가 만들어내는 한계와 전제를 이해한 채 시스템을 만드는 것. 이것이 ROTS다. Reliance on Tools라는 이름이 말해주듯, ROTS는 도구를 무조건 믿으라는 이야기가 아니다. 오히려 우리가 무엇을 믿고 있는지를 자각하라는 경고에 가깝다.
시스템은 사람의 손으로 만들어지지만, 그 손이 무엇을 보고 어떻게 생각했는지는 결국 도구가 결정한다. 어떤 위험을 보았고, 어떤 위험을 놓쳤는지, 무엇을 당연하게 여겼는지는 모두 선택된 도구의 프레임 안에서 정의된다. 그렇기에 ROTS 분석은 도구를 의심하기 위한 절차가 아니라, 도구를 충분히 이해한 뒤에만 믿기 위한 최소한의 책임이다.
시스템 안전은 언제나 기술의 문제가 아니라 선택의 문제였다. 그리고 그 선택의 출발점에는 눈에 잘 띄지 않지만, 가장 오래 함께하게 될 도구가 있다. ROTS는 그 출발점에 질문을 던지는 분석이며, 시스템 안전을 향한 가장 조용하지만 가장 근본적인 개입이다.