시스템의 경계를 묻는 사람들
“시스템은 EMS와 연동되어야 한다.”
...끝?
이게 URS 문장이면,
감사인은 반드시 다음과 같이 되묻는다.
“EMS랑 어떻게 연동되죠?”
“알람 정보는 어디서 발생해서 어디로 가는 거죠?”
“기록은 각 시스템에서 독립적으로 남는 구조인가요?”
“연동 실패 시 어떻게 알 수 있나요?”
이 질문에 대답 못 하면?
시스템 경계가 불명확하다는 뜻이다.
그리고 경계가 불명확한 시스템은 책임 소재도 불명확하다.
그 말은 곧, 실사에서 “누가 뭘 책임지는지 모른다”는 평가로 직결된다.
경계를 설명하는 문장은 이렇게 써야 한다.
“본 시스템은 EMS 시스템으로부터 온도 알람 정보를 OPC 통신을 통해 실시간으로 수신하고,
수신된 알람은 1초 이내 화면에 표시되며,
알람 발생/해제 내역은 각각의 시스템에서 독립적으로 Audit Trail에 기록되어야 한다.”
이 문장 하나로 다음과 같은 사실이 명확하게 구분된다.
– 알람의 출처는 EMS
– 수신 방법은 OPC 통신
– 표시 조건: 1초 이내
– 기록 주체: 양쪽 시스템 모두
– 기록 방식: 독립적 Audit Trail
이걸 URS에서 못 짚으면,
나중에 “EMS는 했는데 본 시스템은 왜 기록이 없죠?”라는 질문이 돌아온다.
그건 당신이 지는 싸움이다.
실무자들이 흔히 놓치는 포인트
1. 연동 시스템을 너무 당연하게 여김
“어차피 EMS에서 주는 거니까”
→ No. 당신 시스템이 수신하고 처리하는 ‘기능’도 명확히 정의해야 한다.
2. 통신 방식이나 트리거 조건을 안 씀
→ OPC, Modbus, HTTP, MQTT… 어떤 방식인지에 따라 검증 전략이 완전히 달라진다.
3. 기록 책임이 누구에게 있는지 모름
→ 실사장은 이 질문 하나로 실무자 레벨을 가늠한다.
GAMP5는 뭐라 하냐고?
“Design with Validation in Mind.”
“Define system boundaries explicitly.”
검증을 염두에 두고 설계하라.
경계를 명확히 정의하라.
이게 GAMP5의 공식 메시지다.
이 문장은 검증이 되는가?
이 문장은 기록으로 남는가?
이 문장은 책임 소재를 명확히 하는가?
그게 기능 정의의 끝이다.