Part 2. 고객이 원하는 것은 무엇인가? — User Requirement(URS) 정의

“무알콜 맥주 공장을 만들어 주세요.”

 

지난 글에서 가상의 고객사로부터 하나의 요청을 받았습니다.

“무알콜 맥주를 생산할 수 있는 공장을 만들어 주세요.”

 

프로젝트는 이렇게 시작됐습니다.

 

그런데 엔지니어 입장에서 이 말을 듣고 바로 P&ID를 그릴 수 있을까요? 당연히 어렵습니다.

 

어떤 제품을 만들 것인지, 하루에 얼마나 생산할 것인지, 원료는 무엇인지, 제품의 품질은 어느 수준이어야 하는지, 공장은 어디에 지을 것인지, 어떤 유틸리티를 사용할 것인지조차 결정되지 않았기 때문입니다.

 

결국 첫 번째로 해야 할 일은 설계를 시작하는 것이 아니라 질문하는 것입니다.

 

“고객께서 말씀하신 무알콜 맥주란 정확히 무엇입니까?”

 

이 질문에서 이번 프로젝트의 두 번째 단계인 User Requirement 정의가 시작됩니다.

 

 

1. 고객의 요구와 엔지니어의 설계조건은 다르다

 

엔지니어링 프로젝트에서 고객은 대개 자신이 원하는 결과를 이야기합니다.

 

예를 들어 다음과 같습니다.

 

• 무알콜 맥주를 생산하고 싶다.
• 제품의 맛은 기존 맥주와 유사해야 한다.
• 하루에 많은 양을 생산하고 싶다.
• 생산공장은 안전해야 한다.
• 향후 생산량을 늘릴 수 있었으면 좋겠다.
• 자동화된 공장을 만들고 싶다.

문제는 이런 요구사항만 가지고는 설비를 설계할 수 없다는 것입니다.

 

예를 들어 고객이

“하루 100톤의 무알콜 맥주를 생산하고 싶습니다.”

 

라고 말했다고 가정해 보겠습니다.

 

엔지니어 입장에서는 바로 다음과 같은 질문이 나옵니다.

 

• 100톤은 완제품 기준인가?
• 하루 24시간 운전 기준인가?
• 연간 300일 운전인가, 330일 운전인가?
• 생산량은 평균 생산량인가, 최대 생산량인가?
• 제품 생산량에는 포장 손실이 포함되는가?

 

같은 “100톤”이라는 숫자라도 기준이 달라지면 공장 규모가 달라질 수 있습니다.

 

따라서 프로젝트 초기에는 고객의 말을 그대로 설계조건으로 사용하는 것이 아니라, 고객의 요구를 하나씩 분해하여 엔지니어링 요구사항으로 구체화하는 과정이 필요합니다.

 

이것이 User Requirement를 정의하는 이유입니다.

 

 

2. URS(User Requirement Specification)란 무엇인가?

 

URS는 User Requirement Specification, 즉 사용자 요구사항을 정리한 문서입니다.

 

쉽게 말하면 다음과 같습니다.

“고객이 최종적으로 어떤 시스템과 결과를 원하는지를 설계팀이 이해할 수 있는 형태로 정리한 문서”

 

여기서 중요한 것은 URS가 곧바로 P&ID나 Equipment Specification이 아니라는 점입니다.

 

URS에서는 먼저 무엇을 원하는지를 정의합니다.

 

그다음 엔지니어가 그 요구사항을 바탕으로 URS → Design Basis → Process Design → Equipment Design → P&ID 와 같은 방식으로 구체화해 나갑니다.

 

요구사항을 명확하게 정의하고 이후 설계 및 검증 단계에서 이를 확인하는 구조는 다양한 산업의 시스템 설계·검증 체계에서 중요하게 다뤄집니다. FDA 역시 설계 초기 단계에서 사용자 요구, intended use, 성능, 안전, 환경, 규제 요구사항 등을 design input으로 식별하는 접근을 설명하고 있습니다.

 

즉, URS는 설계의 출발점입니다.

 

 

3. 그렇다면 고객에게 무엇을 물어봐야 할까?

 

이제 실제 프로젝트로 돌아가 보겠습니다.

 

고객이 “무알콜 맥주 공장을 만들어 달라”라고 요청했습니다. 그렇다면 엔지니어는 어떤 질문부터 해야 할까요?

 

가장 먼저 크게 여섯 가지 영역으로 나누어 볼 수 있습니다.

 

① Product — 어떤 제품인가?

가장 먼저 제품을 정의해야 합니다.

 

예를 들어:

 

• 무알콜 맥주인가?
• 논알코올 맥주인가?
• 알코올 함량 기준은 무엇인가?
• 제품의 원료는 무엇인가?
• 목표 맛과 향은 어느 수준인가?
• 최종 제품의 품질 기준은 무엇인가?

특히 이번 프로젝트에서 중요한 질문이 있습니다.

“무알콜”의 기준을 어디까지 볼 것인가?

 

알코올이 완전히 0인 제품을 의미하는지, 아니면 일정 기준 이하의 알코올을 허용하는 제품인지에 따라 공정의 방향이 달라집니다.

 

이 질문은 이후 Product Specification을 결정하는 Part 3에서 본격적으로 다뤄보겠습니다.

 

② 얼마나 만들 것인가?

제품을 정의했다면 다음은 생산량입니다.

 

예를 들어 고객이 다음과 같이 이야기했다고 가정해 보겠습니다.

“하루에 무알콜 맥주 100톤 정도 생산하고 싶습니다.”

 

여기서 엔지니어는 바로 “100 TPD”라고 적으면 안 됩니다. 다시 질문해야 합니다.

 

하루 100톤이 정확히 무엇을 의미하는가?

 

예를 들어 다음과 같이 구체화할 수 있습니다.

 

항목	고객 요구
제품	무알콜 맥주
목표 생산량	100 ton/day
운전시간	추후 결정
연간 운전일수	추후 결정
생산 Batch	추후 결정
제품 저장량	추후 결정
포장 여부	추후 결정

 

이렇게 하나의 문장을 여러 개의 설계변수로 분해합니다.

 

이 과정이 중요한 이유는 생산량이 결정되면 이후의 Tank Size, Pump Capacity, Heat Exchanger Duty, Utility Consumption, Pipe Size 등 수많은 설계조건에 영향을 주기 때문입니다.

 

결국 “100톤을 만들고 싶다”는 고객의 요구가 나중에는 실제 설비의 크기와 용량으로 변환됩니다.

 

③ 공장은 얼마나 오래 사용할 것인가?

고객의 요구사항에는 의외로 이런 질문도 포함되어야 합니다.

“이 공장은 지금 필요한 만큼만 만들 것인가, 아니면 향후 증설까지 고려할 것인가?”

 

예를 들어 현재 목표 생산량이 100 ton/day라고 하더라도 고객이

“5년 후에는 200 ton/day까지 생산량을 늘리고 싶습니다.”

 

라고 한다면 이야기가 달라집니다.

 

처음부터 모든 설비를 200 ton/day 기준으로 설치할 필요는 없을 수도 있습니다.

 

하지만 최소한 다음과 같은 사항은 검토해야 합니다.

 

• 부지에 증설 공간이 있는가?
• 배관 Rack에 여유 공간을 확보할 것인가?
• Utility Header에 Capacity Margin을 둘 것인가?
• 전기 및 계장 시스템은 증설을 고려할 것인가?
• 저장 Tank를 추가할 공간이 있는가?

즉, 고객이 말하지 않은 미래의 요구사항까지 질문하는 것이 프로젝트 초기 엔지니어의 역할이기도 합니다.

 

④ 공장은 어떤 환경에서 운전되는가?

같은 공정이라도 어디에 설치하느냐에 따라 설계조건은 달라집니다.

 

예를 들어 공장이 대한민국에 설치되는 것과 동남아시아에 설치되는 것은 상당히 다른 조건을 가질 수 있습니다.

 

엔지니어는 다음과 같은 사항을 확인해야 합니다.

 

• Ambient Temperature
• Design Temperature
• Humidity
• Rainfall
• Seismic Condition
• Wind Load
• Utility Availability
• Electrical Supply
• Cooling Water Availability
• Steam Availability
• Instrument Air
• Nitrogen
• Raw Water
• Wastewater Treatment 조건

특히 Utility는 프로젝트 초기부터 확인해야 합니다. 예를 들어 고객이

“Steam은 공장에서 공급됩니다.”

 

라고 말했다고 해도 이것만으로는 부족합니다.

 

• Steam Pressure는 얼마인가?
• Steam Temperature은 얼마인가?
• 공급량은 충분한가?
• 공급이 항상 가능한가?

이런 질문까지 들어가야 실제 설계조건으로 사용할 수 있습니다.

 

⑤ 안전과 규제는 어디까지 고려해야 하는가?

공장을 설계하면서 생산량과 제품만 생각할 수는 없습니다.

 

화학공정이나 식품·음료 플랜트에서는 안전과 법규 역시 중요한 User Requirement입니다.

 

예를 들어 다음과 같은 요구사항이 있을 수 있습니다.

 

• 화재 및 폭발 위험 관리
• 압력용기 관련 법규
• 산업안전 관련 법규
• 소방 관련 법규
• 식품위생 관련 규정
• 배출 및 폐수 기준
• 작업자 안전
• Emergency Shutdown
• Relief System
• Hazardous Area Classification

특히 프로젝트 초기부터 위험요인을 고려하면 이후 설계 변경을 줄이는 데 도움이 됩니다.

 

설계 초기 단계에서 요구사항과 위험요인을 함께 검토하는 접근은 설계 과정에서 잠재적인 위험을 조기에 식별하고 저감 하기 위한 일반적인 설계관리 원칙과도 연결됩니다.

 

⑥ 고객은 무엇을 중요하게 생각하는가?

사실 이 질문이 가장 중요할 수도 있습니다. 고객에게 다음과 같이 물어볼 수 있습니다.

“이번 프로젝트에서 가장 중요한 것이 무엇입니까?”

 

고객의 답은 서로 다를 수 있습니다.

 

어떤 고객은 CAPEX 최소화를 가장 중요하게 생각할 수 있습니다. 또 다른 고객은 OPEX 절감을 중요하게 생각할 수 있습니다.

 

어떤 고객은 생산량을 최우선으로 할 수 있고, 또 다른 고객은 제품 품질을 가장 중요하게 생각할 수 있습니다.

 

예를 들어 다음과 같은 요구가 있다고 가정해 보겠습니다.

“CAPEX는 최대한 낮추되, 향후 생산량 증설은 가능해야 합니다.”

 

이 한 문장만으로도 엔지니어에게는 상당한 의미가 있습니다.

 

저렴한 설비를 무조건 선택하는 것이 아니라, 현재 투자비와 미래 증설성을 동시에 고려해야 하기 때문입니다.

 

결국 URS는 단순히 숫자를 적어놓은 문서가 아닙니다.

 

고객이 무엇을 중요하게 생각하는지를 설계팀에 전달하는 문서이기도 합니다.

 

 

4. Beer to Zero Project의 User Requirement를 정의해 보자

 

그렇다면 지금까지의 질문을 실제 프로젝트에 적용해 보겠습니다.

 

가상의 고객사와 협의를 거쳐 다음과 같은 초기 User Requirement가 정의되었다고 가정하겠습니다.

 

Beer to Zero Project — Initial User Requirement

 

Category	User Requirement
Product	Non-Alcoholic Beer
Product Alcohol	별도 Specification 정의 필요
Production Capacity	100 ton/day
Operation	연속/Batch 운전방식 검토
Annual Operation	추후 결정
Future Expansion	증설 가능성 고려
Product Quality	기존 맥주와 유사한 품질 목표
Utilities	Steam, Cooling Water, Electricity 등 사용
Safety	관련 안전기준 및 법규 준수
Environment	폐수 및 배출물 처리 고려
Automation	자동화 운전 시스템 적용
Maintenance	유지보수가 용이한 설비 구성
Site	고객 지정 부지 기준
CAPEX	경제성 확보
OPEX	장기 운전비용 고려

 

아직 완벽한 설계조건은 아닙니다. 오히려 “추후 결정”이라는 항목이 상당히 많습니다.

 

그런데 이것이 잘못된 것이 아닙니다. 프로젝트 초기의 목적은 모든 숫자를 억지로 결정하는 것이 아니라,

무엇이 결정되었고, 무엇이 결정되지 않았으며, 무엇을 추가로 확인해야 하는지를 명확하게 만드는 것

 

이기 때문입니다.

 

 

5. URS에서 Design Basis로 넘어가는 순간

 

이제 중요한 변화가 일어납니다. 처음 고객이 이야기했던 것은 단순했습니다.

“무알콜 맥주 공장을 만들어 주세요.”

 

하지만 URS를 거치면서 요구사항이 다음과 같이 변했습니다.

 

1. 고객의 요구
2. 무알콜 맥주 생산
3. 목표 제품 정의
4. 100 ton/day 생산
5. 향후 증설 고려
6. 특정 Utility 조건
7. 안전·환경 요구사항
8. CAPEX/OPEX 목표

이제야 엔지니어가 다음 단계로 넘어갈 수 있습니다.

 

바로 "Design Basis"입니다.

 

URS가

“무엇을 원하는가?”

 

를 정의하는 단계라면, Design Basis는

“그 요구사항을 만족시키기 위해 어떤 설계조건을 적용할 것인가?”

 

를 결정하는 단계라고 볼 수 있습니다.

 

그리고 이 과정에서 고객이 말한 “무알콜 맥주”는 점점 엔지니어가 계산할 수 있는 숫자로 변하게 됩니다.

 

예를 들어, 100 ton/day라는 하나의 요구사항이

 

• 시간당 생산량
• 유량
• Tank Capacity
• Pump Flow
• Heat Exchanger Duty
• Pipe Size
• Utility Consumption

등으로 확장됩니다. 이렇게 고객의 언어가 엔지니어의 언어로 바뀌기 시작합니다.

이 부분에서 재밌는 얘기를 하나 해보겠습니다.
몇몇 제조업에서 이런 식으로 업무가 일사천리로 진행되는 Case도 있지만 또 몇몇 제조업은 다릅니다.
User Requirement Specification까지는 프로젝트로 고려 안 하는 경우도 많습니다.
또, 예산을 책정하기 위한 P&ID, Equipment List, Design Basis를 우선적으로 문서 작성 후 투자심의를 거친 이후에야 프로젝트가 시작되는 경우도 있습니다.
제조업이 업계에 따라 다른 경우를 염두에 두고 글을 정주 행하시다 보면 더욱 재밌게 느껴지실 겁니다.
연재 내용 중 추가적인 필자의 실무 경험을 통해 독자 분들께서 읽는 재미와 상상하는 재미를 동시에 느껴보시기 바랍니다.

 

 

6. 좋은 URS는 “구체적인 문서”가 아니라 “검증 가능한 문서”다

 

URS를 작성할 때 흔히 하는 실수가 있습니다.

“높은 품질의 제품을 생산한다.”

“안전한 공장을 구축한다.”

“효율적인 공정을 적용한다.”

 

문장 자체는 틀리지 않았습니다.

 

하지만 엔지니어링 관점에서는 좋은 요구사항이라고 보기 어렵습니다.

 

왜냐하면 무엇을 기준으로 만족 여부를 판단할지 알 수 없기 때문입니다.

 

좋은 요구사항은 가능하면 객관적으로 확인할 수 있어야 합니다.

 

예를 들어,

“제품의 알코올 함량을 고객이 정의한 허용범위 이내로 유지한다.”

 

처럼 측정 또는 검증 가능한 기준으로 바꾸어야 합니다.

 

요구사항을 객관적인 acceptance criteria와 연결하는 것은 이후 설계 검증과 성능검증을 수행할 때도 중요합니다. FDA의 관련 가이드 역시 요구사항을 성능, 안전, 운전조건 등으로 구체화하고 객관적인 성능 판단 기준을 정의하는 접근을 설명합니다.

 

결국 좋은 URS의 핵심은 “그럴듯하게 작성하는 것”이 아니라 “나중에 확인할 수 있도록 작성하는 것”입니다.

 

 

7. 이번 프로젝트에서 우리가 얻은 것

 

Part 1에서는 고객에게서 하나의 요청을 받았습니다.

“무알콜 맥주 공장을 만들어 주세요.”

 

하지만 아직까지 공장은 없습니다.

 

P&ID도 없습니다.

 

Tank Size도 없습니다.

 

Pump Capacity도 없습니다.

 

Heat Exchanger Size도 없습니다.

 

그런데 프로젝트는 분명히 한 단계 앞으로 나아갔습니다.

 

왜일까요? 무엇을 만들어야 하는지가 조금씩 명확해졌기 때문입니다.

 

엔지니어링 프로젝트에서 설계는 도면을 그리는 것부터 시작하지 않습니다.

 

때로는 고객에게 질문하는 것에서 시작합니다.

 

“정확히 무엇을 원하십니까?”

 

그리고 그 질문에 대한 답을 하나씩 정리해 나가는 과정이 바로 User Requirement 정의입니다.

 

 

Beer to Zero Project 연재 순서

 

PART 1. 프로젝트의 시작 — 고객의 요구를 정의하다

 

• Part 1. 고객사 요청 접수 - 프로젝트의 시작
• Part 2. 고객이 원하는 것은 무엇인가 - User Requirement 정의
• Part 3. 무알콜 맥주를 어디까지 만들 것인가 - Product Specification
• Part 4. 하루에 얼마나 생산할 것인가 - 생산능력 결정
• Part 5. 공장을 어디에 지을 것인가 - Site & Utility 검토
• Part 6. 어떤 공정으로 알코올을 제거할 것인가 - Process Selection
• Part 7. 맥주에서 알코올을 어떻게 제거하는가 - Dealcoholization 공정