[구태완 테크 칼럼] GORE: What보다는 Why에 집중한 요구사항 분석

 



1. 무엇(What)보다 왜(Why)

소프트웨어 개발에서 요구사항 분석은 가장 기본적이면서도 가장 복잡한 과정 중 하나로 자리매김하고 있다. 이는 시스템이 수행해야 할 역할을 명확히 규정하고, 다양한 이해관계자의 기대와 요구를 종합적으로 정리하며, 전체 개발 프로젝트의 방향성을 설정하는 데 필수적인 단계이기 때문이다. 그러나 실제 프로젝트 현장에서는 “무엇을 만들 것인가(What)”라는 기능적 측면에 지나치게 집중한 나머지, “왜 그것을 만들어야 하는가(Why)”라는 근본적인 목적과 동기 부여에 대한 충분한 논의가 이루어지지 않는 경우가 빈번하다.
 

초기 요구사항 명세서를 분석해 보면, “시스템은 ~해야 한다(shall)”, “사용자는 ~할 수 있어야 한다(should be able to)”와 같은 서술적 표현으로 채워져 있는 경우가 많다. 이러한 기술적 접근 방식은 기능 목록을 작성하고, 체계적으로 정리하는 데에는 효율적일 수 있으나, 각각의 기능이 어떤 목적을 위해 존재하는지, 조직의 전반적인 비즈니스 목표나 사용자 가치와 어떻게 유기적으로 연결되는지에 대한 설명은 부족하다. 물론 부가적인 설명을 추가하여 부족한 부분을 보완할 수도 있겠지만, 기능 서술이 주요 목표이다 보니, 부가적인 설명이 누락되거나 충분하지 못한 결과를 초래할 확률이 높다. 

결과적으로 구현된 기능이 ‘올바르게 작동하는가’는 검증할 수 있지만, 그 기능이 ‘왜 필요한가’에 대한 판단은 주관적이고 모호해질 수 있다.

이러한 문제는 행위 중심 요구공학(Behavior-driven Requirements Engineering) 접근 방식의 구조적 한계에서 기인한다. 행위 중심 요구공학은 시스템이 수행해야 할 구체적이고 명확한 행위를 기술하는 데 강점을 지니고 있지만, 그 행위가 ‘왜 필요한지(Why)’를 논리적이고 체계적으로 연결하는 틀을 제공하지 못한다. 그 결과 프로젝트 후반부로 진행될수록 기능의 중복, 누락, 우선순위 갈등, 변경 관리의 비효율성 등 다양한 문제가 빈번하게 발생하게 된다. 

이러한 한계를 극복하고 요구사항 분석의 효율성을 높이기 위해 등장한 접근 방식이 바로 목표 지향 요구공학(Goal-Oriented Requirements Engineering, GORE)이다. GORE는 요구사항을 단순한 기능 명세로만 한정하지 않고, 시스템이 달성해야 할 ‘목표(Goal)’로 정의한다. 다시 말해, ‘기능(Function)’은 목표를 실현하기 위한 수단으로서의 역할을 수행하며, ‘목표(Goal)’는 기능이 존재하는 이유와 그 존재 가치를 명확하게 설명하는 근거가 된다. 

결과적으로 GORE는 요구사항을 단순히 “어떻게 표현할 것인가”의 문제로 접근하는 것이 아니라, 요구의 존재 이유(reason)를 중심으로 사고를 구조화하는 방법론이다. 정의된 모든 기능이 “왜 필요한가”를 명확히 설명하지 못하는 경우, 해당 요구사항은 완전한 요구사항으로 간주될 수 없다. 따라서 GORE의 출발점은 명세나 기술이 아닌 질문이며, 분석의 초점은 “무엇을 구현할 것인가(What)”가 아닌 “왜 그것이 필요하고, 왜 그렇게 동작해야 하는가(Why)”에 있다.
 
2. GORE란 무엇인가?

GORE (Goal-Oriented Requirements Engineering)는 말 그대로 목표(Goal)를 중심에 두고 요구사항을 정의하고 분석하는 접근 방법이다. 이는 단순히 “무엇을 해야 하는가(What)”를 명세하는 것을 넘어, “왜 그렇게 해야 하는가(Why)”까지 명확하게 명세하는 것에서부터 출발한다.
전통적인 요구공학은 시스템의 기능과 동작을 중심으로 요구사항을 기술한다(기능 요구사항). 예를 들어 “시스템은 데이터를 암호화해야 한다”는 문장은 구현 측면에서는 무엇을 어떻게 해야 한다를 명확하게 기술하고 있지만, 그 암호화의 목적이 무엇인지, 즉 “고객 개인정보를 보호하기 위해” 또는 “표준/법규 준수를 위해”와 같은 근본적 목적(이유)를 표현하지 않았다. 그런데 GORE는 “이유(reason)”를 요구사항의 구조 속에 포함함으로써 단순 기능 명세를 넘어서 의도(intention)와 맥락(context)을 분석 가능한 형태로 표현하려는 접근이다. 

2.1 GORE의 등장 배경
1990년대 이후 소프트웨어 시스템이 대형화되고, 여러 이해관계자와 복잡한 비기능 요구사항이 얽히면서 기존의 기능 중심 요구공학으로는 시스템의 전체 목적을 설명하기 어려워졌다. 악셀 판 람스위어드(Axel van Lamsweerde)는 이러한 현실적 한계를 극복하기 위해 GORE를 체계화하였으며, “요구사항 도출, 상세화, 분석, 협상, 문서화, 변경의 전 과정에서 목표 개념을 활용하는 접근”으로 GORE를 정의했다(van Lamsweerde, 2001). 

 
2.2 GORE의 핵심 개념
GORE는 시스템을 구성하는 다양한 요구사항을 목표 간의 관계로 표현한다. 이때 각 목표는 상위 목표로부터 유도되어 계층 구조를 형성하며, 구체화 수준에 따라 다음과 같이 구분된다. 

• High-level Goal: 시스템이 달성해야 할 최상위 목적(예: “안전한 운행을 보장해야 한다”) 
• Refined Goal: 상위 목표를 실현하는 데 필요한 세부 목적(예: “충돌을 방지해야 한다”, “제동 시스템이 즉시 반응해야 한다”)
• Operational Requirement: 가장 하위 수준의 구체적 요구사항으로, 검증 가능하고 구현 가능한 형태(예: “제동 명령은 0.5초 이내에 제어기로 전달되어야 한다”) 

이러한 계층 구조를 통해 GORE는 각 요구사항이 어떤 목표를 실현하기 위한 것인지 명확히 하고, 요구 간의 논리적 정당성과 추적성(traceability)을 확보한다.

2.3 GORE 방법론의 주요 구성요소
GORE는 단일 이론이 아닌, 여러 연구자에 의해 발전된 방법론들의 집합체로, 대표적으로 다음과 같은 네 가지 모델이 자주 언급된다. 

• KAOS (Knowledge-based Automated Specification of Systems): 수학적 논리 표현을 사용하는 가장 대표적인 GORE 모델로, 목표 간 정형 분석과 장애물(Obstacle) 분석을 중시한다.
• i*: 이해관계자 간의 의존 관계를 강조하며, 조직적 목표와 행위자 간의 상호작용을 모델링한다.
• Tropos: i*를 확장하여 시스템 개발의 초기 요구부터 설계, 구현 단계까지 목표 기반 추적을 지원한다.
• GRL (Goal-oriented Requirement Language): UML 환경에 통합된 그래픽 모델로, 품질 속성(Softgoal)을 표현하기에 적합하다.

이 네 가지 접근 모두 “목표를 중심으로 요구사항을 구조화한다”는 공통된 철학을 공유하지만, 적용 범위와 강조점은 서로 다르다. 예를 들어 KAOS는 형식 검증(Formal Verification)에 강점이 있는 반면, i*는 조직적 관계와 사회적 의도(Stakeholder Intent) 분석에 유리하다.

2.4 GORE의 핵심 원리: 목적에서 행동으로
GORE의 핵심 원리는 “왜(Why)에서 출발하여 무엇(What)으로 구체화한다”는 점이다. 이는 일반적으로 “Why → What → How”로 표현된다. 상위 목표를 명확히 설정한 후, 이를 실현하기 위한 하위 목표를 정제하고, 최종 단계에서 실행 가능한 요구사항으로 변환하는 프로세스를 의미한다. 이러한 계층적 정제 과정은 시스템이 제공해야 할 각 기능이 상위 목적과 논리적으로 연결되어 있는지 검증할 수 있도록 지원한다. 
예를 들어, “데이터 유출을 방지한다(Why)”라는 목표는 “데이터 접근을 제어한다(What)”로, 다시 “사용자 인증 절차를 강화한다(How)”로 세분화할 수 있다. 이처럼 구성된 목표-요구사항 체계는 변경 관리 및 위험 분석 시 강력한 추적성을 제공한다.
GORE는 요구공학의 하위 기법이 아닌, 요구공학을 ‘이해하는 방식’ 자체를 재정의하는 틀로 인식해야 하며, 시스템이 수행해야 할 기능만을 나열하는 접근 방식과 달리, 각 요구사항의 존재 이유를 모델링함으로써 시스템의 목적성과 일관성을 보장한다. 
 
3. GORE 기반 요구사항 분석이 필요한 이유 

그렇다면, 왜 GORE가 필요할까?

3.1 품질(Quality) 요구사항이 점점 중요해지고 있기 때문이다
성능, 안정성, 보안, 사용성, 공정성, 설명가능성 등과 같은 비기능적 요구사항(Non-Functional Requirements, NFR)은 정량화된 수치로 표현하기 어렵고, 때로는 기능 요구사항과도 충돌한다. GORE에서는 이러한 비기능 요구사항, 즉 품질 요구사항을 단순한 부가조건이 아닌, ‘Softgoal’이라는 독립적인 분석 단위로 세분화한다. 예를 들어 “사용자 신뢰를 높인다”는 목표에 대해 하위 목표로 분해하여 “에러 발생 시 명확한 피드백 제공”, “데이터 처리의 투명성 보장”과 같은 구체적 수단으로 연결할 수 있다. 이처럼 GORE는 정량화가 어려운 품질 요구사항을 목표 간 트레이드오프 구조 속에서 분석할 수 있도록 도와준다.

 

---

사례 #1  자동 로그인 기능

■ 기능 요구사항(Functional Requirement)

• FR1: 사용자는 일정 기간 자동 로그인 기능을 이용할 수 있어야 한다. 

이 기능의 목적은 사용자 편의성을 높이고, 로그인 과정을 단축시켜 사용 경험(UX)을 향상시키는 것이다. 하지만 이 기능은 동시에 여러 비기능적 품질 요구(Softgoal)들과 충돌할 가능성이 있다.

1. 상위 목표(High-level Goal)

• G0: 사용자 편의성과 시스템 보안을 모두 만족하는 인증 체계 구축

이 상위 목표 아래에서 두 개의 주요 하위 목표가 도출된다. 

• G1: 사용자 편의성(Usability) 향상
• G2: 시스템 보안(Security) 강화

2. 하위 목표 정제(Goal Refinement)

• G1. 사용자 편의성 향상

        - G1.1: 로그인 절차 단축 → 사용자가 반복적으로 로그인하지 않아도 되도록 자동 로그인 기능을 제공한다.
        - G1.2: 인증 실패율 감소 → 로그인 오류나 세션 만료로 인한 불편을 줄인다. 
        - G1.3: 신속한 사용자 접근성 확보 → 로그인 이후 즉시 개인화된 화면으로 이동한다. 

• G2. 시스템 보안 강화

        - G2.1: 세션 하이재킹 방지 → 장기 세션이 탈취되지 않도록 토큰 만료와 재인증 절차를 강화한다. 
        - G2.2: 개인정보 보호 → 기기에 저장된 인증 정보가 암호화되어야 한다.
        - G2.3: 사용자 인증 주기 유지 → 일정 기간 이후에는 반드시 재로그인을 요구해야 한다.

3. Softgoal간 Trade-Off 구조  

G1.1 ↔ G2.3 (Trade-off)	자동 로그인 유지 기간을 길게 설정하면 편의성은 높아지지만, 보안은 약화된다.
G1.2 ↔ G2.1 (Trade-off)	인증 실패율을 줄이기 위해 세션 만료를 완화하면, 세션 하이재킹 위험이 증가한다.
G1.3 → G1 (Support)	즉시 접근성은 사용 편의성 향상에 직접적으로 기여한다.
G2.2 → G1 (Support)	개인정보 보호 강화는 간접적으로 사용자 신뢰를 높여, 편의성에 긍정적으로 작용할 수 있다.

4. 결론
GORE는 기능 요구사항인 “자동 로그인 제공”을 단순한 편의 기능으로 보지 않고, 그 기능이 만들어내는 보안, 신뢰, 편의성 간의 상충 관계를 모델링한다. 즉, GORE는 개발자가 “무엇을 만들 것인가(자동 로그인)”뿐만 아니라 “왜 그렇게 만들어야 하는가(보안과 편의의 균형)”를 논리적 근거로 설명할 수 있는 구조를 제공한다.

---

3.2 불확실성과 위험 요인을 체계적으로 다뤄야 하기 때문이다 
자율주행 차량의 도로 상황, 클라우드 서비스의 부하 변화, AI 모델의 데이터 편향 등은 예측하기 어렵고 지속적으로 변한다. 이런 상황에서 “모든 요구사항이 항상 만족된다”는 가정은 비현실적이다. GORE에서는 이러한 불확실성을 장애물(Obstacle)이라는 개념으로 표현한다. 장애물은 목표 달성을 방해할 수 있는 요인으로, 이를 제거(Eliminate), 완화(Reduce), 허용(Tolerate)하는 전략이 목표 모델 안에 함께 포함된다. 따라서 GORE는 시스템이 달성해야 할 목표뿐 아니라, 실패할 수 있는 조건까지 동시에 모델링할 수 있다.

 

---

사례 #2  비상 제동 시스템(Emergency Braking System, EBS)

■ 상위 목표 (High-level Goal)

• G0: 차량이 전방 충돌 위험을 감지했을 때, 안전하게 정지한다.

이 목표는 자율주행 및 운전자 지원 시스템에서 매우 핵심적인 안전 목표(Safety Goal)이다. 그러나 실제 환경에서는 이 목표를 방해할 수 있는 여러 불확실성이 존재한다. GORE에서는 이러한 불확실성을 “장애물(Obstacle)”로 정의한다. 
 
1. 목표 구조(Goal Refinement)

• G1: 전방 장애물을 정확하게 감지한다. → 센서 정확도와 데이터 처리의 신뢰성에 의존함
• G2: 감지 후 즉시 제동 명령을 발행한다. → 신호 전달 지연과 제동 알고리즘의 반응 속도에 의존함
• G3: 차량이 안전하게 정지한다. → 도로 마찰력, 제동력, 차량 하중 등 물리적 제약에 영향을 받음

이 세 가지 하위 목표는 “충돌 방지”라는 상위 목표를 만족시키는 논리적 구조이다. 하지만 목표마다 실패할 수 있는 조건(Obstacle)이 존재한다. 
 
2. 장애물(Obstacles) 모델링
(1) G1에 대한 장애물

• O1: 센서 오작동으로 장애물을 감지하지 못함(Sensor Fault)
• O2: 악천후로 센서 감도가 저하됨(Adverse Weather)
• O3: 장애물의 형태가 비정형이어서 인식 모델이 분류 실패(Model Misclassification)

(2) G2에 대한 장애물

• O4: ECU 간 통신 지연(Network Latency)
• O5: 제동 명령 신호 손실(Message Loss)

(3) G3에 대한 장애물

• O6: 도로 마찰력 부족(Low Friction)
• O7: 브레이크 시스템 고장(Brake Fault)

3. 장애물 대응 전략
 

전략	설명	예시
Eliminate	장애물을 완전히 제거하는 설계	센서 이중화(Redundancy), 고정밀 센서 교체
Reduce	장애물의 발생 가능성이나 영향도를 줄이는 방안	딥러닝 모델 재학습, 센서 융합(Fusion)
Tolerate	장애물이 발생하더라도 시스템이 안전 상태로 전이하도록 허용	Fail-safe 제동 모드, fallback 알고리즘 적용

· O1(센서 오작동)은 Eliminate 전략을 통해 센서 이중화를 적용할 수 있다.
· O2(악천후 감도 저하)는 Reduce 전략으로 레이다·카메라 센서 융합(Fusion)을 통해 완화한다.
· O4(통신 지연)는 Tolerate 전략으로 신호 유실 시 fallback 제동 로직을 활성화할 수 있다.

---

3.3 복잡한 시스템 간 상호작용을 설명할 수 있기 때문이다
현대 시스템은 하나의 독립된 구성요소로 존재하지 않고 여러 서비스, 모듈, 외부 API, 데이터 소스가 서로 연결되어 상호작용한다. 이때 개별 기능의 기술만으로는 시스템 전체의 의도적 연계(intentional linkage)를 설명하기 어렵다. GORE는 목표를 통해 행위자(Agent)와 책임(Responsibility)을 명확히 정의하고, 목표 간의 의존 관계를 표현할 수 있으며, 단순히 기능 간의 호출 관계를 넘어서, 행위자 간의 의도적 상호작용(intentional interaction)을 분석하게 해 준다. 

 

---

사례 #3  자율주행 차량의 위험 감지 및 제동 협력 시나리오

1. 상위 목표(High-level Goal)

• G0: 차량은 전방의 위험 상황을 감지하고 안전하게 정지해야 한다.

이 상위 목표는 하나의 시스템 단위로 표현되지만, 실제로는 여러 행위자(agent)의 협력에 의해 달성된다. GORE에서는 이를 행위자 기반 목표 할당(Goal Assignment to Agents)으로 표현한다.
  
2. 행위자(Agents) 정의
 

행위자	역할 및 책임
Sensor Module	도로 및 주변 객체를 감지하는 책임을 가짐
Perception ECU	센서 데이터를 통합하여 위험 상황을 인식함
Braking Controller	위험 판단 후 즉각적인 제동 명령을 수행함
Driver Monitoring System (DMS)	운전자의 상태(주의 분산, 졸음 등)를 모니터링하여 판단에 반영함

3. 목표 구조(Goal Decomposition)

• G1 (Sensor Module): 전방 객체를 실시간으로 탐지한다. → 하위 목표: “거리, 속도, 이동 방향을 50ms 이내 주기로 업데이트”
• G2 (Perception ECU): 센서 데이터를 통합하여 위험도를 산출한다.→ 하위 목표: “객체의 TTC (Time-to-Collision)가 2초 미만일 경우 위험 경보 발생”
• G3 (Braking Controller): 위험 판단 시 안전하게 감속 또는 정지한다.→ 하위 목표: “ABS 제어 및 감속 곡선을 동적으로 계산하여 제동 명령 수행”
• G4 (DMS): 운전자의 주의 상태를 판단하여 자동 제동 개입 조건을 조정한다.→ 하위 목표: “운전자가 반응하지 않으면 자동 개입 임계값을 낮춤”

4. 목표 간 의존 관계(Goal Dependency)
 

의존 관계	설명
G2 → G1 (Information Dependency)	인식 ECU는 센서 모듈이 제공하는 데이터에 의존
G3 → G2 (Control Dependency)	제동 제어는 위험 판단 결과에 의존
G3 ↔ G4 (Intentional Interaction)	제동 여부 결정은 운전자 상태(주의 수준)에 따라 조정됨
G4 → G2 (Feedback Dependency)	운전자의 상태는 위험 판단 알고리즘에 피드백으로 작용

5. 의도적 상호작용(Intentional Interaction) 분석
이 시나리오에서 가장 중요한 상호작용은 Braking Controller와 DMS 사이의 관계이다. 이 관계는 단순한 “신호 전달”이 아니라, 의도 기반 상호작용(Intentional Interaction)으로 표현된다.

예시:

• Braking Controller의 목표는 “위험 감지 시 제동을 수행한다”이다.
• DMS의 목표는 “운전자가 제동 반응을 보이면 시스템 개입을 최소화한다”이다.

즉, DMS는 Braking Controller의 제동 의도를 수정하는 영향력을 가진다. 이 상호작용은 단순한 호출 관계가 아니라 의사결정 수준에서의 목표 조정(intentional modification)으로 해석된다. 이때 GORE 모델에서는 이를 “Delegation(위임)” 또는 “Softgoal Interference(간접 간섭)” 관계로 표현한다.
 
결국 “행위자 간 의도적 상호작용(Intentional Interaction)”을 모델링함으로써 누가 왜 무엇을 해야 하는가에 관한 협력적 시스템 구조를 명시화할 수 있다.
즉,

• Sensor → Perception → Braking은 기능적 호출 관계이지만,
• DMS ↔ Braking Controller는 의도 기반 협력(intent-based cooperation) 관계이다.

 

---

4. 마치며:
“왜(Why)”를 묻는 습관이 공학을 바꾼다

요구공학의 본질은 완벽한 명세서를 작성하는 것이 아니라, 요구사항의 이유를 이해하는 것이라고 생각한다. 그 이유가 명확해야만 무엇을 할지, 어떻게 할지에 대한 기능의 의미가 명확해지고, 요구사항 자체도 가치를 가질 수 있다고 믿는다. 
이를 위해 이번 글에서는 GORE (Goal-Oriented Requirements Engineering)에 대한 개념적 내용을 살펴보았다. GORE를 사용하면 기능 하나하나를 단순히 나열하는 게 아니라, 그 기능이 무엇을 위해 존재하는지, 어떤 목표를 실현하려는지, 그리고 그 이유가 사람과 조직의 가치에 어떻게 연결되는지를 생각하게 해 준다. 
물론, GORE를 직접 적용하는 것은 쉽지 않을 것이다. 때로는 논의가 길어지고, 결정이 늦어지며, 모호한 답 앞에서 더 이상 분석을 진행하지 못할 수도 있다. 그럼에도, 이런 고민의 저변에는 아무런 체계적 분석 없이 요구공학 프로세스가 수행되는 현실을 조금이나마 개선하는 데 도움이 되었으면 하는 마음이 있었다. 그리고, “왜?”를 묻지 않은 채 만들어진 요구사항은 불명확성으로 쉽게 흔들리고, 지속성을 가지기 어렵게 될 것이 자명할 것이다. 따라서 이번 글을 통해 요구사항을 작성함에 있어 늘 “왜”를 묻는 습관을 잃지 않으려 한다.  - END -
원문 출처



 필자 소개 
구태완 박사는 복잡한 기술 개념을 더 많은 이들과 나누기 위해 블로그에 꾸준히 글을 올리고 있다. 시스템공학과 소프트웨어, 자동차 기술 분야에서 축적한 경험을 쉽게 풀어 전달하며, 현장의 사고방식과 실용적 관점을 공유하는 것이 그의 글쓰기 목적이다.





 

---

이전글 보기 >>
OWL 온톨로지란 무엇인가?
 

AEM(오토모티브일렉트로닉스매거진)

---