개봉 시기에 맞춰 영화 『Michael/마이클』을 보러 갔습니다. 팝의 황제(King of Pop)의 반생은 정말 대단하다고 생각하면서, 영화를 본 후에 곡들도 더욱 찾아 듣게 되었습니다. 그러던 차에 Michael Jackson에 대해 조사하다 보니 소프트웨어 공학계에 Michael Anthony Jackson이라는 분이 계셔서, IT 업계에도 Michael Jackson이 있다는 사실을 알게 되었습니다. 이번에는 그분에 대해 쓴 기사입니다.

얼마 전, Michael Jackson의 전기 영화 『Michael/마이클』을 보고 왔습니다.

서두에도 조금 썼지만, 킹 오브 팝(King of Pop)은 역시 대단합니다. Michael Jackson의 곡은 원래부터 듣고 있었지만, 이번 영화를 통해 더욱 좋아하게 되었습니다 (웃음).

그리고 여운에 잠겨 Michael Jackson에 대해 조사하다가, 어떤 인물에 대해 알게 되었습니다.

소프트웨어 업계에도 Michael Jackson이 있잖아.

Michael Jackson (not the singer) — Consultancy & Research in Software Development

심지어 "가수가 아닌 쪽의 Michael Jackson입니다"라고 직접 써두셨더군요. 몇 번이나 "Thriller의 그 사람인가요?"라는 질문을 받았을지... 라고 생각하며 조사해 보니, 이분은 **소프트웨어 공학계의 킹(King)**이라고 부르고 싶을 정도로 대단한 분이었습니다.

• Michael A. Jackson이 어떤 인물인가

• "3가지 기적" = JSP·JSD·문제 프레임(Problem Frames)의 대략적인 개요

• 명논문 「The World and the Machine」(ICSE '95)의 핵심

• Michael A. Jackson은,
  **JSP(Jackson Structured Programming, 잭슨 구조화 프로그래밍)・JSD(Jackson System Development, 잭슨 시스템 개발법)・문제 프레임(Problem Frames)**을 만들어낸 영국의 소프트웨어 공학자 - 그의 작업은 "프로그램 → 시스템 → 문제"로,
  컴퓨터의 바깥쪽으로, 바깥쪽으로 그 범위를 넓혀갔다 - 대표 논문의 메시지는 "
  문제는 세계에 있고, 기계는 해결책이다"

항목	내용
출생	1936년, 영국 버밍엄
...
대학 전공이 컴퓨터 사이언스(Computer Science)가 아니냐고 따지고 싶어지지만, 당시 Oxford의 고전학에는 논리학이 포함되어 있었으며, 그것이 그에게 있어 관심사였다고 합니다.

일본에서의 평가도 소개하겠습니다. 소프트웨어 심포지엄 2009의 모델링 WG 자료에서는 다음과 같이 소개되어 있습니다.

의심할 여지 없이 소프트웨어 엔지니어링(Software Engineering) 영역의 기재, 혹은 거장. 철학적인 깊이, 본질에 다가가는 예지, 다만 범인에게는 상당히 이해하기 어렵다.

"다만 범인에게는 상당히 이해하기 어렵다"고 했지만, 실제로 저작이 난해하기로 유명하다고 하니, 이 기사에서는 분위기라도 파악하고 돌아가시기 바랍니다.

앞서 언급한 자료에서는 선생님의 업적이 **"3가지 기적"**이라고 소개되어 있습니다. 흥미로운 점은, 각각 다루는 범위가 점점 컴퓨터의 바깥쪽으로 넓어진다는 점입니다.

기적	출판 연도	다루는 범위	한 줄 요약
기적 1: JSP(Jackson Structured Programming)	1975	프로그램 1개	제어 흐름(Control Flow)이 아니라 데이터 구조(Data Structure)로부터 프로그램을 도출하는 설계법
...
3가지 기적의 사정거리. 프로그램→시스템→문제로, 점점 컴퓨터의 바깥쪽으로 넓어짐 (AI 작성)

1970년대, "플로우차트(Flowchart)를 구조화하여 프로그램으로 번역하는 것"이 주류였던 시대에, Jackson 선생님은 "플로우차트는 제어 흐름의 기술일 뿐이지, 설계가 아니다"라고 정면으로 이의를 제기합니다.

대신 제안한 것이, 입력과 출력의 데이터 구조를 "순차·선택·반복"의 3가지 기본 구조로 도식화(Jackson Structure Diagram)하여, 그 대응 관계로부터 프로그램 구조를 도출하는 접근 방식입니다. "프로그램의 형태는 데이터의 형태를 따른다"는 발상입니다.

참고로 선생님 자신도 어셈블러(Assembler) 시대에 정성껏 플로우차트를 작성한 뒤 코딩을 했었는데, "이렇게 주의 깊게 해도 틀린다"는 것을 통감한 것이 방법론 탐구의 원점이었다고 합니다. 선생님도 처음에는 "설계라는 것은 어렵다"라고 생각했다고 합니다.

JSD는 한 걸음 더 물러나, 시스템 개발 전체의 방법론입니다. 전제가 되는 사상이 벌써 전율이 돋습니다.

사용자는 요구사항을 알지 못한다. 기능보다 실세계 모델...

기능 목록을 히어링(hearing)하여 쌓아 올리는 것이 아니라, 우선 실세계의 실체(서적이나 이용자 등)와 그 거동을 기술하여, 시스템 내에 실세계를 시뮬레이션하는 모델 프로세스(model process)를 만든다. 기능은 그 모델에 나중에 접속하는 것이라는 순서입니다.

예를 들어 도서관 시스템으로 설명하겠습니다. 실세계에서 「서적」이 대출되면, 시스템 내의 프로세스가 동일한 동작을 한다. 이를 위해 실세계와 시스템을 「어떻게 접속할 것인가」를 결정한다——라는 사고방식입니다. 도메인 주도 설계 (DDD)가 현재 존재하지만, "어라, 이거 1983년 이야기인가...?"라며 놀랐습니다.

또 하나, JSD에서 흥미로운 점은 공유 사건 (common action) 이라는 개념입니다.

「사람이 시계 버튼을 누른다」와 「시계가 사람에게 버튼을 눌린다」는, 사람의 생애와 시계의 생애가 교차하는 동일한 이벤트 (event) 를 양측에서 바라본 것입니다. 이 공유 사건을 추출하는 것이야말로 시스템 설계의 첫걸음이라고 여겨집니다. 이 「양측에서 바라보는」 감각이 다음 문제 프레임(problem frame)과 대표 논문으로 이어집니다.

그리고 집대성이 문제 프레임입니다. 이제는 시스템을 만드는 방법조차 아니라, 애초에 풀어야 할 문제를 어떻게 분석·구조화할 것인가 에 대한 이야기입니다.

실세계의 문제를 「기계·도메인(적용 영역)·요구」의 관계로 파악하고, 몇 가지 기본 패턴(문제 프레임)에 대입하여 분석합니다.

요구란, 기계가 미치는 효과에 의해 적용 영역에서 달성되어야 하는 조건입니다.

요구는 기계의 기능 목록이 아니라, 세계 측에서 달성되어야 하는 조건 이라는 정의입니다.

여기까지 오면, 이제 완전히 「컴퓨터의 바깥쪽」 이야기를 하고 있는 것입니다.

「요구」와 「요건」에 대하여

이 기사에서는 원문의 requirement를 「요구」로 번역하고 있습니다. 일본에서는 「사용자의 요구를 히어링하여, 시스템의 요건으로 정의한다(요건 정의)」와 같이 구분하여 사용하는 경우가 많지요. 잭슨(Jackson) 선생이 말하는 requirement는 「고객이 세계 측에서 실현하기를 바라는 조건」을 의미하므로, 시스템 측의 조건으로서 확정한 「요건」보다 앞단에 있는 「요구」가 뉘앙스상 더 가깝습니다.

세 가지 기적을 관통하는 사상이 가장 응축되어 있는 것이 ICSE '95의 논문 「The World and the Machine」입니다. 서두부터 곧바로 핵심을 찌릅니다.

요구 — 즉 문제는 세계 측에 있다. 기계는 우리가 구축하는 해결책이다.

워드 프로세서의 가치는 코드의 아름다움이 아니라, 완성된 문서의 질로 결정된다.

항공 관제 시스템의 요구는 비행기와 공역과 활주로와 관제탑 안에 있다.

소프트웨어의 가치는 항상 컴퓨터의 바깥쪽(=세계)에서 결정된다는 이야기입니다.

항공 관제 시스템이란

비행기끼리 충돌하지 않도록 관제사가 하늘의 교통 정리를 하기 위한 시스템입니다. 레이더 등으로 비행기의 위치·고도·속도를 파악하여, 이착륙 순서나 비행 경로 지시를 내리는 것을 지원합니다. 즉, 이 시스템의 「요구」는 코드 속이 아니라, 실제 비행기·공역·활주로·관제탑과 같은 현실 세계 측에 존재한다는 것이 잭슨 선생의 지적입니다.

세계와 기계의 관계. 요구(문제)는 세계 측에, 프로그램(해결)은 기계 측에 있으며, 사양은 두 가지가 겹치는 경계에 작성한다 (AI로 작성)

논문 중의 예시가 강렬하여 소개합니다. 어떤 항공기 시스템에는 다음과 같은 요구가 있었습니다.

「비행기가 활주로에 접지하고 있을 때만, 역추력을 사용할 수 있게 하고 싶다」

역추력이란

착륙한 비행기가 엔진의 분사 방향을 전환하여 강력한 브레이크로 사용하는 메커니즘입니다. 아직 하늘을 날고 있는 상태에서 작동하면 대형 사고이므로, 「접지하고 있을 때 만」이라는 조건이 무엇보다 중요해집니다.

「비행기가 접지하고 있다」는 것은 세계 측의 사실이며, 제어 소프트웨어(기계)는 그것을 직접 알 수 없습니다. 기계가 알 수 있는 것은 어디까지나 센서로부터 전달되는 신호뿐입니다.

그래서 개발자는 세계와 기계를 연결하기 위해, 세계에 대한 두 가지 가정을 세웠습니다.

가정 1: 바퀴가 회전하고 있다면, 바퀴의 센서에서 펄스(pulse) 신호가 나온다 (역도 마찬가지)
가정 2: 바퀴가 회전하고 있다면, 비행기는 활주로 위에 있다 (역도 마찬가지)

이 두 가지 가정을 인정하면, 「접지하고 있을 때」를 기계도 이해할 수 있는 언어로 번역할 수 있습니다.

요구: 접지하고 있을 때만, 역추력을 허용하고 싶다 (세계의 언어)
↓ 가정 2: 바퀴가 돌고 있다 = 활주로 위에 있다
↓ 가정 1: 바퀴가 돌고 있다 = 펄스가 나온다
...

개발자는 "가정 1과 가정 2가 옳다면, 이 사양은 요구사항을 충족한다"는 것을 증명했습니다. 로직상으로는 완벽합니다.

그런데 어느 폭우가 내리던 날. 활주로에 형성된 수막으로 인해 타이어가 떠오르는 하이드로플래닝 현상 (Hydroplaning) (비 오는 날 자동차가 미끄러지는 현상입니다)이 발생했고, 비행기는 접지하고 있음에도 바퀴가 회전하지 않는 상태가 되었습니다. 가정 2의 붕괴입니다.

맑은 날과 폭우가 내리는 날, 기계의 판단은 이렇게 달라진다 (AI로 생성)

바퀴가 회전하지 않음 → 펄스(Pulse)가 나오지 않음 → 기계는 "아직 착륙하지 않았다"라고 판단 → 조종사는 역추진(Reverse thrust)을 사용할 수 없음. 결과적으로 비행기는 멈추지 못하고 활주로를 오버런(Overrun)했습니다.

여기서 중요한 점은, 기계는 사양대로 완벽하게 작동하고 있었다는 것입니다. 버그가 있었던 것은 코드가 아니라, 세상에 대한 가정 쪽이었습니다. 요구사항 정의(Requirement definition)로 머리를 싸매본 적이 있는 분들이라면 가슴에 와닿을 것입니다.

지금까지의 이야기로 "세상을 이해하는 것이 중요하구나"라는 결론에 도달하게 되는데, 이 논문의 흥미로운 점은 그럼에도 불구하고 우리 엔지니어들은 세상으로부터 눈을 돌려 기계 속에 갇혀버린다고 지적한다는 부분입니다. 그 변명의 패턴이 '4가지 부정(4 Denials)'으로 나열되어 있습니다. 이 네 가지의 내용은 AI 시대의 이야기와 엮어서 후편에서 자세히 소개하겠습니다.

• 소프트웨어 업계의 마이클 잭슨(Michael Jackson)은 스스로 "not the singer"라고 자처하는 영국의 거장
• JSP → JSD → 문제 프레임(Problem Frames)으로, 커리어를 통해 계속해서 "컴퓨터의 바깥쪽"을 향해 나아감
• 대표 논문의 메시지는 "문제는 세상에 있고, 기계는 해결책이다"

여기까지 썼습니다만,

"문제는 세상에 있고, 기계는 해결책이다"——이 30년 전의 말, AI가 코드를 작성하는 2026년인 지금이야말로 가장 가슴에 와닿는 것 아닌가...?

AI가 저렴하게 만든 것은 "기계"를 만드는 비용이지, "세상"을 이해하는 비용은 단 1원도 저렴해지지 않았을 것입니다. 역추진의 비극 같은 일은 프롬프트(Prompt)의 문제로서 지금도 매일 재생산되고 있습니다. 그리고 바이브 코딩(Vibe coding)이라는 AI의 유혹은, 사실 30년 전에 "부정"으로서 예언된 것이 아닐까...

그런 이야기를 후편에서 자세히 쓰겠습니다.

후편 링크 예정 ＞＞

• Michael Jackson, "The World and the Machine", Proceedings of ICSE '95
• 飯泉純子 「문제는 『문제』에 있다 — An Overview of Problem Frames」 소프트웨어 심포지엄 2009 모델링 WG
• Michael A. Jackson (computer scientist) - Wikipedia
• 잭슨의 구조적 프로그래밍 - Wikipedia
• 영화 『Michael/마이클』 공식 사이트
• 일본어 번역서: 『구조적 프로그램 설계의 원리』 (1980), 『시스템 개발 —JSD법—』 (1989), 『소프트웨어 박물지 —세상과 기계의 기술—』 (1997)