저는 회사의 조직, 기능 또는 제품 구조를 대화 도중에 즉석에서 구축해야 하는 전략 세션에 자주 참여합니다.

첫 번째 다이어그램(diagram)이 화면에 나타납니다. 누군가가 "아니요, 이 기능은 여기에 있으면 안 됩니다"라고 말합니다. 다른 사람이 새로운 역할을 추가합니다. 세 번째 사람은 CEO에게 아이디어를 설명할 수 있도록 브랜치(branch)의 절반을 일시적으로 숨겨달라고 요청합니다. 20분 후, 구조는 우리가 처음에 시작했던 모습과는 더 이상 같지 않게 됩니다.

그리고 바로 그 지점에서 거의 모든 일반적인 다이어그램(diagram)이 방해가 되기 시작합니다.

이러한 세션에 참여하는 사람들은 대개 분석가, 프로세스 아키텍트(process architect) 또는 기술 전문가가 아닙니다. 그들은 상업적, 운영적 또는 행정적 리더들입니다. 그들이 박스를 올바르게 그리는 법을 배우거나, 화살표로 연결하거나, 적절한 관계 유형(relationship type)을 선택하는 법을 익혀야 해서는 안 됩니다. 그들은 비즈니스 자체를 논의해야 합니다.

마치 아이들처럼 말이죠. 그리고 이것은 비판이 아닙니다. 성인들이 함께 어려운 문제를 해결할 때, 인터페이스(interface) 또한 그들의 주의력에서 사라져야 합니다.

그 경험은 저에게 도구에 대한 요구 사항 목록을 제공했습니다.

실시간 세션 중에 일어나야 하는 일

• 도구는 무거운 제3자 소프트웨어나 라이선스가 필요한 소프트웨어를 설치하지 않고도, 거의 모든 곳에서 거의 모든 장치에서 실행될 수 있어야 합니다.
• 모델은 전문적인 표기법(notation)으로 과부하되지 않으면서도, 대형 화면이나 경영진, 또는 의사결정 검토를 위해 충분히 보기 좋게 보여야 합니다.
• 구조는 상자와 화살표로 수동으로 그리는 것이 아니라, 하나의 모델로서 구축되어야 합니다.
• 참가자들은 토론 중에 모델을 변경할 수 있어야 합니다: 블록을 드래그하고, 보고 라인(reporting lines)을 변경하고, 그룹화하고, 불필요한 부분을 숨기고, 서식을 조정하며, 관련 브랜치(branch)로 주의를 빠르게 다시 돌릴 수 있어야 합니다.
• 동일한 모델이 다양한 방식으로 읽힐 수 있어야 합니다: 클래식한 수직 계층 구조(vertical hierarchy)뿐만 아니라, 책임 체인(responsibility chain), 기능적 흐름(functional flow), 또는 마인드 맵(mind map)에 더 가까운 수평적 흐름(horizontal flow)으로도 읽힐 수 있어야 합니다.
• 모델은 단일 수치 차원(numeric dimension)을 가져야 합니다: 예산, 타임라인, 인원수(headcount), 노력(effort), 작업량(workload) 또는 기타 측정값입니다. 해당 값은 각 블록에 별도의 라벨로 존재하는 대신, 전체 브랜치에 걸쳐 집계(aggregate)되어야 합니다.
• 결과물이 하나의 애플리케이션 안에 갇혀 있어서는 안 됩니다. 그래픽, 표, 대화형 HTML, 그리고 기계가 읽을 수 있는 코드(machine-readable code)로 전송할 수 있어야 합니다.
• 모델의 콘텐츠는 내장된 기업용 API로 전송할 필요 없이, 사용자의 자체 AI 도구를 사용하여 쉽게 분석하고 개선할 수 있어야 합니다.
• 마지막으로, 이러한 모델에는 이름, 급여 범위, 예산, 상업적 가정과 같은 민감한 데이터가 거의 항상 포함됩니다. 꼭 필요한 경우가 아니라면 또 다른 클라우드 서비스에 업로드할 필요가 없어야 합니다.

이 모든 것을 하나로 통합한 기성 도구를 찾을 수 없었기에, 저는 직접 만들기로 결심했습니다.

하지만 저는 하나의 애플리케이션만으로는 충분하지 않다는 것을 빠르게 깨달았습니다.

저는 두 가지를 만들어야 했습니다

첫 번째는 계층 구조 모델을 위한 오픈 포맷인 **ORGF**입니다.

두 번째는 이러한 모델을 시각적으로 열고, 표시하고, 편집할 수 있는 무료 브라우저 애플리케이션인 **ORGFORMAT Studio**입니다.

ORGF의 이면에는 단순한 아이디어가 있습니다. 모델은 단지 이미지, 스크린샷, 또는 특정 벤더(vendor)가 소유한 파일로만 존재해서는 안 된다는 것입니다. 모델은 다른 사람과 공유할 수 있고, 다른 도구에서 열 수 있으며, 검증(validation) 가능하고, AI의 입력값으로 사용되거나 다른 표현 방식(representation)으로 변환될 수 있는 일반적인 읽기 가능한 텍스트여야 합니다.

저는 YAML을 선택했습니다. YAML은 사람이 눈으로 읽기에 충분히 간단하면서도, 소프트웨어와 AI가 이해할 수 있기 때문입니다.

reference:
  format: "ORGF 1.0.0"
  syntax: "YAML|UTF-8 without BOM"
...

ORGF 포맷 자체, 레퍼런스(reference), 그리고 검증기(validator)는 MIT 라이선스(MIT licence) 하에 공개되어 있습니다. 이는 단순히 Studio를 위한 파일이 아닙니다. Studio와 독립적으로도 사용할 수 있습니다.

이것이 단순한 다이어그램 그 이상인 이유

ORGF에는 계층 구조를 단순한 그림에서 작동하는 모델로 바꿔주는 세 가지 간단한 메커니즘이 있습니다.

가치(Value): 경제적 차원을 가진 구조

각 블록(block)은 숫자 값을 가질 수 있으며, 모델은 전체 브랜치(branch)에 걸쳐 이를 집계합니다.

해당 값은 예산, 인원수, 노력(effort), 타임라인, 업무량(workload) 또는 기타 다른 단일 측정 지표를 나타낼 수 있습니다. 따라서 새로운 구조를 논의할 때, 보고 체계(reporting lines)나 기능적 분해(functional decomposition)가 어떻게 변하는지뿐만 아니라, 수치적 규모가 어떻게 변하는지도 확인할 수 있습니다.

ORGF가 스스로 기업의 효율성을 자동으로 측정할 수 있다고 주장하는 것은 아닙니다. 하지만 구조적 결정과 그에 따른 경제적 평가 사이의 간단한 가교를 만들어 줍니다.

태그(Tags): 무거운 데이터베이스 없는 체계화

블록에는 sales, critical, remote, contractor, region-eu, planned 또는 기타 사용자 정의 속성과 같은 태그를 표시할 수 있습니다.

이를 통해 계층 구조에 가벼운 시스템 계층(systemic layer)을 부여할 수 있습니다. 별도의 데이터베이스를 구축하거나 모델에 기술적 스키마(schema)를 부담시키지 않고도 기능 유형, 상태, 역할, 지역, 기술 또는 기타 특성을 설명할 수 있습니다.

실제로 이는 작은 도메인 데이터베이스 (domain database)가 되지만, 일반적인 업무 회의 중에 여전히 열어보고, 이해하고, 논의할 수 있는 형태를 유지합니다.

AI-ready: 임베디드 에이전트가 아닌, 당신의 AI와 함께 작업하기

저는 API를 통해 Studio 내부에 침투적인 AI 에이전트 (AI agent)를 구축하지 않기로 의도적으로 결정했습니다.

첫째, 이는 보통 추가 비용, 키 (keys), 제한 사항, 그리고 특정 제공업체에 대한 의존성을 의미하기 때문입니다. 더 중요한 점은, 사용자들이 이미 작업을 논의하고, 소스 정보를 수집하며, 컨텍스트 (context)를 구축해 온 자신만의 AI 도구를 이미 가지고 있는 경우가 많다는 것입니다.

기계가 읽을 수 있는 ORGF 모델을 해당 AI로 보내는 것이 더 논리적입니다. 이미 논의된 입력값을 바탕으로 브랜치 (branches)를 추가하거나, 역할을 재구성하거나, 태그 (tags)를 확장하거나, 값을 재계산하거나, 구조의 새로운 버전을 생성하도록 AI에게 요청하는 것입니다.

업데이트된 파일은 이후 Studio에서 열어 시각적으로 확인할 수 있습니다. AI가 인간의 결정을 대체하는 것은 아니지만, 콘텐츠를 모델로 옮기는 수동 작업을 제거해 줍니다.

"또 하나의 클라우드 서비스" 대신 로컬 우선 (local-first)을 선택한 이유

Studio는 브라우저에서 실행되지만, 모델을 다루는 일반적인 작업은 로컬 (local)에 머뭅니다. 즉, 데이터는 브라우저의 로컬 스토리지 (local storage)에 저장됩니다.

이것은 클라우드에 반대하는 종교적 전쟁이 아닙니다. 클라우드 솔루션은 협업과 더 복잡한 시나리오에 유용할 수 있습니다. 하지만 첫 번째 버전에서는, 단순히 구조를 빠르게 구축하거나 논의하기 위해 민감한 기업 모델을 다른 서버에 업로드하도록 누군가에게 강요하지 않는 것이 저에게 중요했습니다.

브라우저를 열고, 모델을 구축하고, 파일을 저장하고, 고객이나 동료에게 보내세요. 필수 계정, 구독, 또는 "귀하의 데이터는 ...에 따라 처리됩니다"와 같은 절차 없이 말입니다.

[

]

하나의 모델, 여러 가지 읽기 방식

저는 또 다른 ARIS, Visio, HRIS 또는 범용 BPM 플랫폼을 만들려는 것이 아닙니다.

ORGF는 교차 링크 (cross-links)가 없는 엄격한 계층 구조 (hierarchies)로 의도적으로 제한되어 있습니다. 이는 "긴급히 수정해야 할 누락된 기능"이 아닙니다. 이는 객체의 계층 구조와 데이터에 대한 직접적인 책임에 기반한 의도적인 경계입니다.

책임, 기능, 역할, WBS (Work Breakdown Structure), 분류 (classifications) 또는 카탈로그 (catalogues)의 구조에 대해 빠르게 합의하는 것이 주요 작업일 때, 트리는 종종 범용 그래프 (universal graph)보다 더 유용합니다. 트리는 명확성을 유지합니다. 즉, 모든 블록은 자신의 위치와 부모, 그리고 이해 가능한 책임 분기 (responsibility branch)를 가집니다.

하지만 동일한 모델을 반드시 위에서 아래로만 읽어야 하는 것은 아닙니다.

최근 저는 Studio에 수평 흐름 보기 (horizontal flow view)를 추가했습니다. 데이터는 변하지 않습니다. 여전히 동일한 계층 구조이지만, 기능적 분해 (functional decomposition), 책임 체인 (responsibility chain) 또는 레벨의 시퀀스 (sequence of levels)로서 왼쪽에서 오른쪽으로 읽기가 더 쉬워집니다.

두 가지 보기 모두에서 카드 상세 정보, 검색, 강조 (Highlight), 다크 모드 (dark mode), 드래그 앤 드롭 (Drag-and-Drop), 그리고 SVG 또는 독립형 대화형 HTML (standalone interactive HTML)로의 내보내기 기능을 사용할 수 있습니다.

계층 구조는 조직도만이 아닙니다

첫 번째 비즈니스 모델을 구축한 후, 저는 이 포맷이 HR이나 컨설팅에만 국한될 필요가 없다는 것을 빠르게 깨달았습니다.

계층 구조는 역사, 교육, 프로젝트 관리 (project management), 카탈로그, 분류, 심지어 어린이용 자료에서도 나타납니다. 이것이 데모에 왕조 (ruling dynasties), 동물 도감 (animal atlas) 및 기타 사례들이 포함된 이유입니다.

한 사례에서 value는 예산을 의미할 수 있습니다. 다른 사례에서는 인시 (person-hours)를 의미할 수 있습니다. 세 번째 사례에서는 왕조의 통치 기간을 의미할 수 있습니다. 형식적으로는 동일한 메커니즘입니다. 모델은 한 분기(branch)에 걸쳐 하나의 지표 (indicator)를 집계하며, 사용자는 그 지표가 무엇을 나타낼지 결정합니다.

이 프로젝트는 매우 집중적인 한 달 동안 진행되었습니다. 아직은 "모두를 위한 이상적인 플랫폼"은 아닙니다. 모델을 더 쉽게 만들고, 더 명확하게 논의하며, 사람과 도구 사이에서 더 자유롭게 전송할 수 있도록 만들기 위한 실행 가능한 시도입니다.

저는 특히 다음 세 가지 질문에 대한 비판에 관심이 있습니다:

• 조직 구조(organisational structures) 이외의 영역에서 이와 같은 포맷이나 도구가 가장 유용하게 쓰일 곳은 어디일까요?
• 무엇을 가장 먼저 바꾸고 싶으신가요, 혹은 무엇을 먼저 망가뜨려 보고 싶으신가요?
• 개방형 계층 구조 포맷(open hierarchy format)은 좁고 단순하게 유지되어야 할까요, 아니면 필연적으로 그래프(graphs), 프로세스(processes), 그리고 더 복잡한 의미론(semantics)을 향해 확장되어야 할까요?