패스트캠퍼스 오프라인 강좌에서 S-P-O 분해 연습문제로 출제했던 시나리오의 풀이 노트를 공유합니다.

이 문제의 핵심은 두 가지입니다.

1. 자연어 문장을 주어(Subject) - 술어(Predicate) - 목적어(Object) 트리플로 분해하기
2. 관측 사실(Observation)과 가설(Hypothesis)을 명확히 분리하기

문제 페이지

아래는 당시 문제로 제시했던 페이지를 인라인 SVG로 재현한 것입니다.

문제 요약

• 자율주행 로봇이 장애물이 없는 곳에서 급정거하는 유령 멈춤(Phantom Stop) 현상이 발생했습니다.
• AP 로그 분석 결과 LiDAR 센서가 장애물 감지 신호를 보냈지만, LiDAR 단품 테스트는 정상이었습니다.
• 앨리스는 DC-DC 컨버터의 리플 노이즈가 센서 민감도를 초과해 오탐을 유발했을 가능성을 제기했습니다.

풀이 접근법

S-P-O 분해는 다음 세 단계로 진행합니다.

Step 1. 개체(Entity) 식별

시나리오에서 고유한 이름을 가질 수 있는 것을 먼저 찾습니다. 사람, 장비, 이벤트, 문서 등이 모두 개체 후보입니다.

개체	유형	근거
Scenario_ONT_SCN_2024_002	시나리오 문서	문서 번호 ONT-SCN-2024-002
Alice	인물	전자 회로 설계자
Bob	인물	시스템 통합 담당자
Meeting_2024_10_15_1000	회의 이벤트	2024-10-15 10:00, 101호
Robot_Autonomous	시스템	자율주행 로봇
PhantomStopEvent	장애 이벤트	유령 멈춤 현상
AP_Log	데이터 소스	메인 프로세서 로그
LiDAR_Sensor	부품	라이더 센서
DCDC_Converter	부품	전원 공급 모듈
RippleNoise	물리 현상	리플 노이즈

Step 2. 관측 사실 vs. 가설 분류

문장을 읽으면서 측정/확인된 사실인지, 아직 검증되지 않은 추정인지 분류합니다. 이 구분이 S-P-O 분해의 핵심입니다.

관측 사실의 판별 기준:

• 로그에 기록된 데이터 → 사실
• 테스트 결과 → 사실
• 문서에 명시된 메타데이터 → 사실

가설의 판별 기준:

• “의심합니다”, “가능성을 제기” 등 불확실성 표현 → 가설
• 아직 측정하지 않은 인과 관계 → 가설

Step 3. 트리플 작성

각 문장에서 “무엇이(S) 어떠하다(P) 무엇과(O)” 구조를 추출합니다. 한 문장에서 여러 개의 트리플이 나올 수 있습니다.

“앨리스는 전원 공급 모듈(DC-DC Converter)과 라이더 센서 사이의 연결 관계를 의심합니다.”

이 문장 하나에서 다음 트리플들이 추출됩니다:

• Alice — suspects → NoiseInterferenceHypothesis
• NoiseInterferenceHypothesis — involves → DCDC_Converter
• NoiseInterferenceHypothesis — involves → LiDAR_Sensor

“의심합니다”라는 표현이 있으므로, 이 트리플들은 모두 가설 그룹에 속합니다.

S-P-O 분해 결과: 관측 사실

#	S	P	O
1	Scenario_ONT_SCN_2024_002	hasTitle	“전력 모듈과 센서 간의 노이즈 간섭에 따른 시스템 오작동 분석”
2	Scenario_ONT_SCN_2024_002	hasDocumentNumber	“ONT-SCN-2024-002”
3	Scenario_ONT_SCN_2024_002	hasDate	“2024-10-15”
4	Scenario_ONT_SCN_2024_002	hasObjective	“부품 간의 연결 관계를 추적하여 장애의 근본 원인과 파급 효과를 규명”
5	Scenario_ONT_SCN_2024_002	hasParticipant	Alice
6	Alice	hasRole	“Electronics Engineer”
7	Scenario_ONT_SCN_2024_002	hasParticipant	Bob
8	Bob	hasRole	“Integrator”
9	Meeting_2024_10_15_1000	scheduledAt	“2024-10-15T10:00”
10	Meeting_2024_10_15_1000	locatedIn	“101호 회의실”
11	Robot_Autonomous	experienced	PhantomStopEvent
12	AP_Log	reported	LiDAR_ObstacleSignal
13	LiDAR_UnitTest	hasResult	“normal”

S-P-O 분해 결과: 가설

#	S	P	O
H1	Alice	suspects	NoiseInterferenceHypothesis
H2	NoiseInterferenceHypothesis	involves	DCDC_Converter
H3	NoiseInterferenceHypothesis	involves	LiDAR_Sensor
H4	DCDC_Converter	produces	RippleNoise
H5	RippleNoise	exceedsToleranceOf	LiDAR_Sensor
H6	RippleNoise	causes	FalseObstacleSignal
H7	FalseObstacleSignal	leadsTo	PhantomStopEvent

지식 그래프 시각화

위 트리플들을 그래프로 그려 보면 전체 인과 관계가 한눈에 보입니다. 파란 실선은 관측 사실, 빨간 점선은 가설입니다.

가설 체인(DCDC_Converter → RippleNoise → FalseObstacleSignal → PhantomStopEvent)이 검증 대상 경로가 됩니다. 이 경로의 각 링크를 실측으로 확인하면 가설이 사실로 전환됩니다.

RDF 스케치 (Turtle)

@prefix ex:  <http://example.org/ontology/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# ── 시나리오 메타데이터 (관측 사실) ──
ex:Scenario_ONT_SCN_2024_002 a ex:Scenario ;
    ex:hasDocumentNumber "ONT-SCN-2024-002" ;
    ex:hasDate "2024-10-15"^^xsd:date ;
    ex:hasTitle "전력 모듈과 센서 간의 노이즈 간섭에 따른 시스템 오작동 분석" ;
    ex:hasObjective "부품 간의 연결 관계를 추적하여 장애의 근본 원인과 파급 효과를 규명" ;
    ex:hasParticipant ex:Alice, ex:Bob ;
    ex:hasContext ex:PhantomStopEvent ;
    ex:hasIncident ex:LiDARObstacleSignalIncident ;
    ex:hasHypothesis ex:NoiseInterferenceHypothesis .

ex:Alice a ex:Person ;
    ex:hasRole "Electronics Engineer" .

ex:Bob a ex:Person ;
    ex:hasRole "Integrator" .

ex:Meeting_2024_10_15_1000 a ex:Meeting ;
    ex:partOf ex:Scenario_ONT_SCN_2024_002 ;
    ex:scheduledAt "2024-10-15T10:00:00"^^xsd:dateTime ;
    ex:locatedIn "101호 회의실" .

# ── 관측된 사건 ──
ex:Robot_Autonomous a ex:System ;
    ex:experienced ex:PhantomStopEvent .

ex:PhantomStopEvent a ex:IncidentEvent ;
    ex:description "장애물이 없는 곳에서 급정거" .

ex:AP_Log a ex:DataSource ;
    ex:reported ex:LiDAR_ObstacleSignal .

ex:LiDAR_UnitTest a ex:TestResult ;
    ex:hasResult "normal" .

# ── 가설 (검증 대상) ──
ex:NoiseInterferenceHypothesis a ex:Hypothesis ;
    ex:suspectedBy ex:Alice ;
    ex:involves ex:DCDC_Converter, ex:LiDAR_Sensor .

ex:DCDC_Converter a ex:Component ;
    ex:produces ex:RippleNoise .        # 가설

ex:RippleNoise a ex:PhysicalPhenomenon ;
    ex:exceedsToleranceOf ex:LiDAR_Sensor ; # 가설
    ex:causes ex:FalseObstacleSignal .      # 가설

ex:FalseObstacleSignal a ex:Signal ;
    ex:leadsTo ex:PhantomStopEvent .        # 가설

흔한 실수

강좌에서 수강생분들이 자주 빠지는 함정 세 가지를 정리합니다.

1. 관측 사실과 가설을 섞는다

“DC-DC 컨버터가 리플 노이즈를 발생시켰다.”

아직 측정하지 않았으므로 사실이 아니라 가설입니다. 시나리오에서 “의심합니다”, “가능성을 제기” 같은 표현이 보이면, 그 뒤에 나오는 인과 관계는 전부 가설 그룹으로 분류해야 합니다.

2. 주어를 문자열로 쓴다

S: “앨리스” / P: suspects / O: “노이즈 간섭”

주어와 목적어가 고유한 개체라면 URI(리소스 식별자)로 표현해야 합니다. 문자열 리터럴("앨리스")은 이름이지, 개체 자체가 아닙니다. Alice라는 리소스로 지정해야 다른 트리플과 연결됩니다.

3. 한 문장에서 트리플 하나만 뽑는다

“앨리스는 전원 공급 모듈과 라이더 센서 사이의 연결 관계를 의심합니다.”

이 문장에는 최소 3개의 트리플(suspects, involves × 2)이 담겨 있습니다. 자연어 한 문장이 반드시 트리플 하나에 대응하지 않습니다. 명사구와 동사구를 꼼꼼히 분해해야 합니다.

다음 단계: 가설에서 검증으로

S-P-O 분해가 끝나면, 가설 체인의 각 링크가 자연스럽게 검증 과제가 됩니다.

가설 트리플	검증 방법
DCDC_Converter → produces → RippleNoise	오실로스코프로 DC-DC 출력단 리플 측정
RippleNoise → exceedsToleranceOf → LiDAR_Sensor	센서 데이터시트의 전원 허용 리플 스펙과 비교
RippleNoise → causes → FalseObstacleSignal	리플 주입 테스트 후 센서 출력 관찰
FalseObstacleSignal → leadsTo → PhantomStopEvent	로그 타임스탬프 교차 확인

관측 사실은 검증된 데이터로 묶고, 가설은 검증 대상으로 명확히 분리합니다. 이렇게 분해해 두면 “다음에 뭘 확인해야 하지?”라는 질문에 그래프가 바로 답해줍니다.