jbyoo 싸인 한 번 잘못하면 감사에서 털린다 https://brunch.co.kr/@@hZw8 2025-06-21T06:40:26Z https://brunch.co.kr/@@hZw8/43 2025-09-10T11:00:08Z 2025-09-10T11:00:08Z

1. OQ는 ‘시험’이 아니라 ‘입증’이다 많은 사람들이 Operational Qualification(OQ)을 단순히 “시스템이 작동하는지 확인하는 단계”라고 생각한다. 틀린 말은 아니지만, 이 정의만으로는 절반밖에 이해 못 한 것이다. OQ의 진짜 목적은 이 시스템이 왜 이렇게 설계되었는지, 그 설계 논리를 시험으로 입증하는 것이다. 즉, OQ는

https://brunch.co.kr/@@hZw8/42 2025-09-05T11:00:09Z 2025-09-05T11:00:09Z

1. “기능이 있다”는 말로는 부족합니다 실제 CSV 문서에서 흔히 보게 되는 문장들: 시스템은 알람 기능을 제공해야 한다. 트렌드는 30일 데이터를 표시할 수 있어야 한다. 사용자 계정은 권한에 따라 관리된다. 이 문장들이 틀렸다고 말하긴 어렵습니다. 그런데 문제는, 테스트가 불가능하다는 것입니다. 시험 항목은 ‘있는지 없는지’를 보는 것이 아니

https://brunch.co.kr/@@hZw8/41 2025-09-03T12:01:06Z 2025-09-03T12:01:06Z

실제 실무에서는 이런 상황, 자주 마주칩니다. “기능 확인했어요. 버튼 눌러봤습니다.” “잘 작동하던데요?” “사진도 찍어뒀어요.” 정말요? 그게 시험(Test)인가요, 그냥 확인(Verification)인가요? 시험(Test)은 기능을 ‘보는 것’이 아니라 ‘입증하는 것’ 많은 실무자들이 ‘시험’을 그냥 동작 확인 수준으로 이해합니다. 예를 들어,

https://brunch.co.kr/@@hZw8/40 2025-08-28T11:00:07Z 2025-08-28T11:00:07Z

IOQ 서류 다 완벽합니다. 서명도 다 있어요. 사진도 첨부했어요. 근데 실사관 표정이 안 풀립니다. “설계 문서는 어디 있나요?” “FDS는 작성하셨나요?” 아차. “밸리데이션은 다 했는데, 설계 문서가 없어요…” 검증은 ‘설계 대비’라는 걸 잊지 마라 IOQ 문서에 시험 결과가 아무리 정확하게 기록되어 있어도 그게 무엇을 기준으로 작성되었는가를

https://brunch.co.kr/@@hZw8/39 2025-08-21T12:25:57Z 2025-08-21T12:25:57Z

– 공사도 변경관리입니다. 실무에서 자주 놓치는 CSV 항목들 이런 건, 누가 봐도 변경 같지 않죠. 센서 하나 이설했다? 기계 고정대만 살짝 옮겼다? 알람 설정을 살짝 바꿨는데 그게 뭐? 근데요, 실사관 눈엔 다 보입니다. 그리고 이런 “작은 변경” 하나가 감사보고서에 그대로 적힙니다. “No change control applied for syste

https://brunch.co.kr/@@hZw8/38 2025-08-20T10:00:04Z 2025-08-20T10:00:04Z

시작 – 이런 질문, 받아보셨습니까? “측정값은 바꿀 수 없나요?” “기록은 누가, 언제 남긴 거죠?” “원본은 어디 있습니까?” 이런 질문은 사람이 아닌 시스템의 신뢰성을 묻는 것입니다. 그리고 그 대답은 결국 Audit Trail과 무결성 구조에서 나옵니다. 데이터 무결성이란 무엇인가? ALCOA++ 핵심 5요소 요약    → Attributab

https://brunch.co.kr/@@hZw8/37 2025-08-19T10:00:08Z 2025-08-19T10:00:08Z

요즘은 프로젝트 초기에 벤더가 미리 URS 초안을 작성해주는 경우가 많습니다. 겉보기엔 깔끔하게 포맷도 갖춰져 있고, 마치 바로 검토 후 서명만 하면 될 것처럼 보이죠. 그런데… 이게 진짜 사용자 요구사항일까요? 사실 대부분의 벤더 URS 초안은 ‘기술사양 목록’에 가깝습니다. “이 기능은 있어요, 저 기능도 됩니다” – 마치 쇼핑몰 설명처럼 말이죠.

https://brunch.co.kr/@@hZw8/36 2025-08-18T11:09:20Z 2025-08-18T11:04:49Z

BMS, EMS 프로젝트에서 자주 등장하는 기능 중 하나가 바로 알람 기능입니다. 너무 흔하다 보니, 간단히 URS 한 줄 넣고 넘어가는 경우가 많습니다. “시스템은 이상 발생 시 알람을 발생시켜야 한다.” 하지만 그 한 줄이, OQ 때 누락되면 실사에서 매뉴얼이 아닌 실전질문이 날아옵니다. “이 알람, 정확히 언제 울립니까?” 예상치 못한 질문이 아

https://brunch.co.kr/@@hZw8/35 2025-08-12T12:39:15Z 2025-08-12T12:39:15Z

먼저, URS 문장 3요소 공식을 기억해 주세요 모든 요구사항(URS) 문장에는 반드시 아래 세 가지가 담겨야 합니다. 조건: 언제/어떤 상황에서 동작합니까? 통제: 누가/어떤 절차로 설정·해제·변경합니까? 기록: 무엇을/어디에/얼마 동안 변경 불가로 남깁니까? (Audit Trail/보존) 한 줄 공식: [조건]에서 [동작]하고, 설정·해제는 [권

https://brunch.co.kr/@@hZw8/34 2025-08-07T12:56:19Z 2025-08-07T12:56:19Z

“시스템은 알람 기능을 제공해야 한다.” 문장 자체는 이상 없어 보인다. 하지만 이 한 줄이, 프로젝트 전체를 망가뜨릴 수도 있다. 왜냐고? 이건 기능이 아니라 ‘선언’이기 때문이다. 실제 현장에서 쓰이는 많은 URS는 ‘요구사항’이 아닌 사양 나열 혹은 기술 설명 수준에 머문다. “시스템은 HTML5 기반이어야 한다.” “시스템은 백업 기능을 지원한다

https://brunch.co.kr/@@hZw8/33 2025-08-06T12:06:32Z 2025-08-06T12:06:32Z

“로그인, 백업, 알람? 다들 하잖아요.” 그래서 그냥 넘어간다. 그러다 실사에서 털린다. 실제로는 거의 모든 시스템 URS에서 계정 관리, 백업, 알람, 트렌드, 설정 변경 항목이 등장한다. 그런데 그게 문제다. 너무 익숙해서 아무도 안 본다. 그냥 넘어간다. 대충 쓴다. 벤더가 준 거 그냥 붙인다. 그러다 실사에서 “이건 왜 이렇게 썼죠?”라는 질문

https://brunch.co.kr/@@hZw8/32 2025-08-05T12:41:11Z 2025-08-05T12:41:11Z

‘ALCOA++는 나중에 고민하죠. 지금은 기능만 뽑아야 하니까요.’ 이 말을 듣는 순간, 난 바로 URS 초안을 열어봤다. 아니나 다를까. 기능들은 줄줄이 써 있었지만, 그 기능이 어떻게 통제되고, 어떻게 기록되며, 무결성을 어떻게 보장하는지는 어디에도 없었다. 그냥 “로그인이 가능해야 한다”, “알람이 있어야 한다”, “백업 기능이 있어야 한다”… 기

https://brunch.co.kr/@@hZw8/31 2025-08-02T11:58:24Z 2025-08-02T11:58:24Z

“시스템은 EMS와 연동되어야 한다.” ...끝?이게 URS 문장이면,감사인은 반드시 다음과 같이 되묻는다. “EMS랑 어떻게 연동되죠?”“알람 정보는 어디서 발생해서 어디로 가는 거죠?”“기록은 각 시스템에서 독립적으로 남는 구조인가요?”“연동 실패 시 어떻게 알 수 있나요?” 이 질문에 대답 못 하면?시스템 경계가 불명확하다는 뜻이다.그리고 경계가

https://brunch.co.kr/@@hZw8/30 2025-08-01T12:40:42Z 2025-08-01T12:40:42Z

“시스템은 백업 기능을 제공해야 한다.” 이 문장, URS에서 수도 없이 본다.그리고 실사장에서 이렇게 물어본다. “백업은 주기적으로 자동 저장되나요?”“누가 백업 주기를 설정하나요?”“백업 로그는 Audit Trail로 남나요?”“백업 데이터는 변경이 불가능한 저장소에 있나요?” ...당신의 URS 문장이 이 질문에 대답할 수 없다면,그 문장은 기능 정의

https://brunch.co.kr/@@hZw8/29 2025-07-31T12:28:31Z 2025-07-31T12:28:31Z

“시스템은 HTML5 기반의 웹 인터페이스를 제공한다.” 이 문장, 많이 봤을 거다.이런 문장들은 흔히 URS에 붙어 있고, 보통은 무난하게 넘긴다.하지만 실사장에서 이 문장이 문제 되면?다음 질문이 날아온다. “그래서 이 HTML5 인터페이스에서 사용자 권한 설정은 어떻게 작동하죠?”“그 화면에서 변경된 로그는 어떻게 관리되나요?”“해당 기능은 어떤 업무

https://brunch.co.kr/@@hZw8/28 2025-07-29T20:57:54Z 2025-07-29T13:49:19Z

“사용자는 백업 기능을 사용할 수 있어야 한다.” 이 문장을 보면 어떤 생각이 드는가?잘 쓴 것처럼 보인다. 기술적이고, 말도 맞고.하지만 실사장이면 얘기가 달라진다. “사용자는 사용할 수 있어야 한다.”이게 기능 정의인가?기능이 존재할 수도 있다는 가능성을 말하고 있을 뿐,시스템이 실제로 어떻게 동작해야 하는지는 아무것도 말하지 않는다. 이 문장이

https://brunch.co.kr/@@hZw8/27 2025-07-28T12:38:17Z 2025-07-28T12:38:17Z

“시스템은 알람 기능을 제공해야 한다.”이 문장 하나로 밸리데이션을 말아먹은 QA들이 몇이나 될까? 문제는 이 문장이 너무 익숙해서 아무도 이상하다고 생각하지 않는다는 거다.하지만 실사를 나온 감사인은, 이 한 줄에서 수십 개의 질문을 뽑아낸다. “어떤 조건에서 알람이 발생하나요?”“알람은 어디에 표시되며, 누가 해제할 수 있죠?”“발생·해제 로그는 자동

https://brunch.co.kr/@@hZw8/26 2025-07-24T14:29:18Z 2025-07-24T11:56:05Z

현장에서 문서를 검토하다 보면어떤 문장에서는 손이 멈춘다. 반면, 어떤 문장은 아무 생각 없이 넘긴다.그리고 몇 달 뒤 실사 때, 그 '넘겼던 문장'이 문제를 일으킨다. 이게 바로 URS의 무서운 점이다.처음엔 기능 나열처럼 보여도,그 문장이 이후 FDS, DQ, IQ, OQ, 실사까지 전부를 따라가기 때문이다.처음에 놓친 문장은, 끝까지 흔들린다. 실무

https://brunch.co.kr/@@hZw8/25 2025-07-23T13:18:54Z 2025-07-23T12:14:05Z

검토자 입장에서 URS를 보다 보면,“기능은 맞는데 왜 이렇게 불안하지?” 싶은 문장들이 있다. 이유는 간단하다.문장이 기능은 설명하는데, 구조는 말하지 않기 때문이다. “연동 가능해야 한다.”이 문장은 아무것도 의미하지 않는다. 누가 시작하고,어떤 데이터를 주고받으며,그 결과는 어디에 기록되는가 이게 설명되지 않으면그 기능은 검증도 안 되고, 설계서도

https://brunch.co.kr/@@hZw8/24 2025-07-22T13:27:41Z 2025-07-22T12:35:04Z

문장이 있다는 건 아무 의미 없다.문장이 ‘설득력이 있느냐’가 전부다. URS를 보다 보면기능은 다 써 있는 것 같은데어딘가 불안한 문장들이 있다. “시스템은 백업 기능을 제공해야 한다.”검토자 입장에서 보면이건 아무것도 말하지 않는 말이다. 백업이 뭘 백업하는 건지주기는 누가 정하는지백업본은 어디 저장되는지로그는 남는지설정은 통제 가능한지아무것도 안 보