SKILL.md: 복잡한 설계를 위한 인지 시스템 공학
license: Apache-2.0
metadata:
name: 인지 시스템 공학 (CSE)
source: "The Role of Cognitive Systems Engineering in the Systems Engineering Design Process"
authors: Militello, Dominguez, Lintern, Klein
version: 1.0
activation_triggers:
- 에이전트 시스템 또는 오케스트레이션 아키텍처 설계
- 시스템이 실패했거나 사용자에게 실패하고 있는 이유 분석
- AI 또는 인간 실행을 위한 복잡한 작업 분해
- 도메인 전문가로부터 요구사항 도출
- 인지 작업에서 오류 또는 예상치 못한 동작 발생
- 올바른 문제를 해결하고 있는지 의문
- 전문가 판단, 의사 결정 지원 또는 자동화 설계
- 해결책이 명시된 문제 대신 실제 문제를 해결하고 있는지 평가
이 스킬을 사용해야 할 때
다음과 같은 경우 이 스킬을 사용하세요:
- 인간의 인지를 지원하기 위한 시스템 설계 — 의사 결정 지원, 에이전트 오케스트레이션, 정보 시스템, 전문성 자동화
- 요구사항이 모호하거나, 논쟁 중이거나, 계속 변경되는 경우 — 이는 이해관계자가 혼란스러운 것이 아니라 인지적 요구사항이 보이지 않는다는 신호입니다.
- 오류나 실패가 발생하는 경우 — 이를 패치해야 할 결함이 아닌 설계 가정에 대한 진단 도구로 취급하세요.
- 명시된 문제가 잘못된 것처럼 느껴지는 경우 — 해결 공간에 실제 정답이 포함되지 않은 것 같을 때
- 전문성을 캡처, 복제 또는 지원해야 하는 경우 — 그리고 전문가가 "자신이 어떻게 하는지 잘 설명하지 못하는" 경우
- 분산된 팀이나 시스템이 복잡한 인지 작업을 조정해야 하는 경우 — 여러 에이전트, 인간, 도구 또는 조직이 인지 부하를 공유하는 경우
- 분석 작업의 가치가 의심받는 경우 — 인지적 기여가 엔지니어링 산출물에 비해 보이지 않을 때
핵심 정신 모델
1. 인지적 요구사항은 보이지 않는다
설계자가 작업자에게 필요하다고 가정하는 것과 작업자가 실제로 필요로 하는 것은 체계적으로 다르며, 그 격차는 엄청납니다. 숙련된 실무자는 자신이 쉽게 말로 표현할 수 없고 관찰만으로는 드러나지 않는 암묵적 지식, 지각적 단서, 패턴 인식, 제약 조건 인식을 바탕으로 작업합니다. 이러한 요구사항을 적극적으로 발굴하지 않는 모든 설계 과정은 가상의 작업자를 위해 구축될 것입니다.
시사점: 요구사항 도출은 인터뷰나 설문조사가 아닌 전문적인 방법(인지 작업 분석, 중요 결정 방법, 생각 말하기 프로토콜)을 사용해야 합니다. 이 작업의 산출물은 기능 목록이 아닌 실제 작업의 인지 모델입니다.
2. 오류는 진단 도구이지 결함이 아니다
인지 시스템의 오류는 오작동이 아닙니다. 이는 시스템의 작업 모델이 작업의 실제 구조와 어디에서 다른지를 정확하게 나타내는 지표입니다. 예상된 동작과 관찰된 동작 간의 불일치는 설계자가 얻을 수 있는 가장 정보 밀도가 높은 신호입니다.
시사점: 에이전트, 사용자 또는 결합 시스템이 예상치 못한 출력을 생성할 때, 첫 번째 질문은 "이 오류가 우리의 설계 가정에 대해 무엇을 드러내는가?"이지 "이 오류를 어떻게 제거할 것인가?"가 아닙니다.
3. 설계는 대화이지, 파이프라인이 아니다
순차적 설계 모델(요구사항 → 명세 → 구축 → 테스트)은 교육적으로는 편리하지만 실제로는 거짓입니다. 복잡한 문제는 참여할수록 새로운 정보를 드러냅니다. 시작할 때의 문제 설명은 끝날 때의 문제 설명과 결코 같아서는 안 됩니다. 요구사항을 조기에 고정하려는 시도는 복잡한 문제가 요구하는 발견을 억제합니다.
시사점: 반복은 계획의 실패가 아닙니다. 프로젝트 중간에 문제 프레임을 재검토하는 것은 범위 확장이 아니라 프로세스가 올바르게 작동하고 있다는 신호입니다. 명시적인 재평가 게이트를 구축하세요.
4. 문제 프레이밍이 가장 영향력이 큰 개입이다
인지 분석이 생성할 수 있는 가장 가치 있는 것은 종종 문제의 재진술입니다. 명시된 문제에 대한 더 나은 해결책이 아니라, 명시된 문제가 잘못되었다는 증거입니다. 원자력 발전소 사례: 직원 80명 이상에서 35명으로 감축, 새로운 기술 없이, 단지 작업의 실제 인지 구조를 이해함으로써 가능했습니다.
시사점: 어떤 해결책을 최적화하기 전에 문제 설명을 검증하는 데 투자하세요. 잘못된 문제를 높은 품질로 해결하는 비용은 다른 거의 모든 설계 오류를 능가합니다.
5. 도구-사용자 쌍이 아닌 결합 인지 시스템
인지적 복잡성은 분산 시스템 — 인지 작업을 집합적으로 수행하는 인간, 기술, 프로세스 및 조직 구조 — 에 있습니다. 단일 에이전트나 도구를 고립적으로 설계할 수 없습니다. 시스템 전반에 걸친 조정 메커니즘, 정보 흐름 및 공유 상황 인식이 인지적 성공 또는 실패를 결정합니다.
시사점: 노드뿐만 아니라 핸드오프를 설계하세요. 구성 요소 간의 공유 정신 모델 요구사항을 명시하세요. 자동화가 결합 시스템 전반의 인지 부하 분배를 어떻게 변화시키는지 분석하세요(단순히 자동화가 작동하는지 여부만이 아닙니다).
의사 결정 프레임워크
문제 진단
IF 시스템이 오류 또는 예상치 못한 동작을 생성하는 경우
THEN load: failure-modes-in-complex-cognitive-systems.md
→ 수정을 제안하기 전에 실패 모드를 분류하세요
→ 질문: 이것이 자동화 서프라이즈, 잘못된 문제, 사일로 현상, 과잉 명세, 또는 병목 현상인가?
IF 이해관계자가 요구사항에 동의하지 않거나 요구사항이 계속 변경되는 경우
THEN load: cognitive-requirements-are-invisible.md
→ 변경은 정보입니다: 인지적 요구사항이 아직 명시되지 않았습니다
→ 더 많은 요구사항 수집 전에 구조화된 도출을 수행하세요
IF 제안된 해결책이 잘못된 것을 해결하는 것처럼 느껴지는 경우
THEN load: problem-reframing-as-highest-leverage-intervention.md
→ 해결 작업을 중단하고 먼저 문제 프레이밍에 투자하세요
→ 현재 해결책 유형을 불필요하게 만드는 재진술을 찾으세요
설계 프로세스
IF 에이전트 시스템 또는 오케스트레이션 아키텍처를 설계하는 경우
THEN load: joint-cognitive-systems-distributed-cognition.md AND cse-concept-map-for-agent-architecture.md
→ 구성 요소를 설계하기 전에 전체 결합 시스템을 매핑하세요
→ 조정 메커니즘과 정보 흐름을 먼저 설계하세요
IF 충분한 이해 없이 요구사항을 최종 확정하라는 압력을 받는 경우
THEN load: design-as-dialog-not-pipeline.md
→ "요구사항 잠금"과 "현재 최상의 모델 보유"를 구분하세요
→ 순차적 잠금 대신 명시적인 재평가 게이트를 제안하세요
IF 전문가 판단을 위해 또는 전문가 판단을 중심으로 설계하는 경우
THEN load: expertise-recognition-and-tacit-knowledge.md
→ 전문성이 실제로 어떻게 작동하는지 이해하기 위해 인식 기반 의사 결정 모델을 적용하세요
→ 요구사항 작업에서 전문가 표현 격차를 계획하세요
평가와 가치
IF 인지 분석 작업의 가치가 의문시되는 경우
THEN load: value-case-and-invisible-contributions.md
→ 역설: 좋은 CSE 작업은 스스로를 보이지 않게 만듭니다(실패 감소, 원활한 운영)
→ 사고 건수뿐만 아니라 선행 지표를 사용하세요
IF 제안된 해결책에 기술 또는 인력 추가가 포함된 경우
THEN load: problem-reframing-as-highest-leverage-intervention.md
→ 확인: 작업의 정확한 인지 모델이 이 해결책을 검증하는 데 사용되었습니까?
→ 원자력 발전소 벤치마크: 문제 재구성이 제안된 리소스의 필요성을 없앨 수 있습니까?
참조 파일
| 파일 | 로드 시기 |
|---|---|
references/cognitive-requirements-are-invisible.md | 요구사항이 모호하거나 논쟁 중일 때, 전문 사용자를 위해 설계할 때, 요구사항 도출 프로세스를 시작할 때, 사용자 연구 방법이 의문시될 때 |
references/design-as-dialog-not-pipeline.md | 요구사항을 조기에 확정하라는 압력을 받을 때, 반복 프로세스가 비효율적이라고 도전받을 때, 프로젝트가 중간에 있고 문제 설명을 재검토해야 할 때 |
references/problem-reframing-as-highest-leverage-intervention.md | 해결 공간에 올바른 답이 포함되지 않은 것 같을 때, 제안된 해결책이 비싸거나 잘못된 것처럼 느껴질 때, 실행을 중단하고 재구성하는 것을 정당화해야 할 때 |
references/joint-cognitive-systems-distributed-cognition.md | 다중 에이전트 또는 인간-기계 시스템을 설계할 때, 조정 실패를 분석할 때, 자동화가 인지 부하 분배를 어떻게 변화시키는지 평가할 때 |
references/expertise-recognition-and-tacit-knowledge.md | 전문가 지식을 캡처할 때, 의사 결정 지원을 설계할 때, 전문가 판단을 복제하거나 지원하는 시스템을 구축할 때, 전문가가 작업 수행 방법을 설명할 수 없을 때 |
references/failure-modes-in-complex-cognitive-systems.md | 시스템 오류 또는 예상치 못한 동작을 진단할 때, 제안된 설계에 대한 사전 분석(pre-mortem)을 수행할 때, 관찰된 실패에 대응하기 전에 분류할 때 |
references/cse-concept-map-for-agent-architecture.md | 에이전트 시스템의 기능을 매핑할 때, 구성 요소 간 인지 기능을 구성할 때, 프레임워크 간 용어 혼동을 해결할 때 |
references/value-case-and-invisible-contributions.md | 인지 분석 투자를 정당화할 때, CSE 작업의 가치가 의문시될 때, 주로 실패를 방지하는 시스템의 결과를 측정할 때 |
안티 패턴
다음은 CSE가 특별히 경고하는 실패 모드입니다. 조기에 인식하세요.
1. 상상된 작업자를 위한 설계 전문가가 실제로 어떻게 작업하는지가 아니라 설계자가 전문가가 작업한다고 생각하는 방식에 기반한 시스템 구축. 상상된 작업자는 합리적이고, 완전한 정보를 가지고 있으며, 절차를 따르고, 교과서가 말하는 대로 결정을 내립니다. 실제 작업자는 이 중 어느 것도 하지 않습니다.
2. 오류를 진단 도구가 아닌 결함으로 취급 오류가 무엇을 드러내는지 묻지 않고 패치하는 것. 이해되지 않은 채 수정된 오류는 근본적인 설계 가정을 바로잡을 기회를 놓치는 것이며, 문제가 다른 형태로 재발할 것임을 보장합니다.
3. 인지 작업이 완료되기 전에 요구사항 고정 순차적 프로세스 모델은 요구사항을 조기에 고정하라는 압력을 만듭니다. 인지적으로 복잡한 영역에서는 잘못된 시스템이 효율적으로 구축되도록 보장합니다. 조기 요구사항 고정은 규율이 아니라 조기 종결입니다.
4. 사일로 현상: 결합 시스템 관점 없이 구성 요소 최적화 주변의 인간 또는 에이전트의 워크플로를 망가뜨리는 훌륭한 도구 구축. 시스템 성능을 저하시키는 국소 최적화. 전형적인 예: 인간을 작업에서 해방시키지만 자동화가 실패할 때 상황 인식을 상실하게 만드는 자동화.
5. 실패 분석의 사후 편향 사고 이후 특정 실패에 대해서만 설계하는 것. 사후 재구성의 유혹적인 명확성은 실패가 실제보다 더 예측 가능해 보이게 만들고 — 설계 에너지를 다음 실패가 아닌 마지막 실패에 집중시킵니다.
6. 적응 능력을 제거하는 과잉 명세 현실이 모델에서 벗어날 때 실무자가 즉흥적으로 대응할 수 없을 정도로 빡빡하게 시스템을 설계하는 것. 실제 복잡한 작업에는 적응이 필요합니다. 과잉 명세는 유연성이 가장 중요한 상황에서 시스템을 취약하게 만듭니다.
7. 설계에 의한 전문가 병목 현상 단일 전문가(인간 또는 AI)가 모든 중요한 결정의 필수 게이트웨이가 되는 시스템 구축. 그 전문가가 훌륭하더라도 이는 치명적인 취약성을 만듭니다. CSE는 전문성을 집중시키는 것이 아니라 분산할 것을 요구합니다.
식별 지표
누군가가 CSE를 진정으로 내면화했는지, 아니면 요약본만 읽었는지 알아내는 방법:
그들은 "오류는 흥미롭다"고 말합니다 — "오류는 문제다"가 아닙니다. CSE를 흡수한 사람은 실패 보고서를 마감해야 할 티켓이 아니라 연구 기회로 취급합니다.
그들은 "해결책은 무엇인가?"보다 먼저 "이것이 올바른 문제인가?"라고 묻습니다 — 그리고 그 질문에 가시적인 진행이 지연되더라도 실제 시간을 기꺼이 투자합니다. 그들은 원자력 발전소 사례를 보았고 그 답이 얼마나 가치 있을 수 있는지 알고 있습니다.
그들은 인지 분석 없이 요구사항 고정에 저항합니다 — 방해 행위가 아니라 작업의 인지 구조를 이해하기 전에 요구사항을 고정하는 것이 잘못된 것을 구축하는 구체적이고 명명된 예측 가능한 방법임을 이해하기 때문입니다.
그들은 결합 시스템으로 생각합니다 — 실패를 분석하거나 해결책을 설계할 때 본능적으로 "이것이 전체 인지 시스템에서 어디에 위치하는가?"를 묻지 "이 구성 요소는 무엇을 해야 하는가?"를 묻지 않습니다.
그들은 암묵적 지식이 얼마나 많은 비용이 드는지 알고 있습니다 — 전문가가 자신이 알아야 할 것을 말해줄 수 있을 것이라고 기대하지 않습니다. 그들은 전문성이 대부분 내성적으로 접근할 수 없다는 것을 내면화하고 그에 따라 도출 방법을 계획합니다.
그들은 설계의 반복적 특성을 노이즈가 아닌 신호로 취급합니다 — 프로젝트 중간에 문제 설명이 변경될 때 이를 관리해야 할 계획 실패가 아니라 프로세스가 실제 무언가를 드러내고 있다는 신호로 읽습니다.
그들은 다섯 가지 실패 모드를 말할 수 있습니다 — 자동화 서프라이즈, 잘못된 문제 설명, 사일로 현상, 과잉 명세, 전문가 병목 현상 — 그리고 이를 체크리스트가 아니라 새로운 상황에 진단적으로 적용합니다.
그들이 말하지 않는 것: "더 나은 요구사항만 있으면 됩니다." "프로세스를 문서화하면 시스템이 따라올 것입니다." "사용자 교육만 필요합니다." "운영자가 어떻게 사용하는지와 무관하게 AI 도구를 평가할 수 있습니다."
특정 상황이 발생하면 필요에 따라 참조 파일을 로드하세요. 이 파일로 SKILL이 활성화됩니다; 더 깊은 분석에는 참조 파일이 필요합니다.