Ward Cunningham

Keynote: Observation of Emergent Schema in Organized Development

• 원본: www.youtube.com/watch?v=oPJIXPC_vn8&t=483s ↗
• DDD 컨퍼런스 기조연설

에릭 에반스의 도입부

에릭 에반스(Eric Evans)가 워드를 소개하며 DDD 책의 뒷이야기를 들려준다.

워드는 DDD 책의 리뷰어였다. 그는 "전술적 패턴(tactical patterns)들은 부록으로 옮겨야 할 것 같다"고 조언했다. 핵심이 아니라고 봤기 때문이다.

에릭은 그 조언을 따르지 않았다. 두 가지 휴리스틱(heuristics)이 충돌했기 때문이다.

1. 핵심 메시지를 정제해서 명확히 전달하고 싶다 → 전술적 패턴을 빼야 한다
2. 당시 업계에는 "모델러는 코딩을 하지 않는다"는 상아탑 식 문화가 팽배했다 → 모델과 코드의 연결 고리를 반드시 보여줘야 한다

에릭은 2번을 택했다. 누군가가 "이런 엔티티(entity)와 밸류 오브젝트(value object)가 있다"고 말할 때, 그것이 어떻게 구현될지 알 수 있어야 했다. 유비쿼터스 언어(ubiquitous language)로 실제로 돌아가는 소프트웨어를 만들 수 있다는 걸 보여줘야 했다.

에릭은 워드를 "원조(proto) DDD 전문가"라고 불렀다. 워드는 DDD 책이 나오기 전부터 이미 DDD를 하고 있었다.

워드의 발표: 관찰하기

워드는 제목을 설명한다.

• 관찰(Observation): 무언가를 직접 보기 전까지는 뭘 얻게 될지 모른다. 이론을 증명하는 게 아니라 호기심이다.
• 스키마(Schema): 데이터베이스가 아니라 "사물들이 어떻게 연결되어 있는가"를 의미한다.
• 조직화된 개발(Organized Development): 사람뿐 아니라 코드와 코딩 방식까지 포함하는 넓은 범위다.

타임랩스 비유: 호텔 창밖을 그냥 보면 "괜찮은 풍경"이지만, 타임랩스로 보면 주차장에서 벌어지는 미묘한 활동들이 보인다. 변화를 볼 수 있게 되면 풍경이 달라진다.

컴퓨팅의 변화

워드는 키펀치(keypunch) 시대와 앨런 케이(Alan Kay)의 비전을 대비시킨다. 앨런 케이는 "컴퓨터는 저렇게 작동해서는 안 된다"고 말했다. 앞을 내다보는 능력으로부터 많은 것을 배웠다.

지금 또 다른 극적인 변화의 시점에 와 있다. 패킷 스위칭(packet switching), 컨테이너 운송 등 소중한 것들을 조각내어 전 세계로 보내는 기술이 근간이다.

뉴렐릭(New Relic)에서의 경험

워드가 뉴렐릭에서 겪은 조직 변화:

• 자율 선택(self-selection): 거대한 홀에서 모든 테이블이 하나의 팀을 상징. 사람들이 원하는 팀을 직접 찾아다닌다. 누구도 강요받지 않는다.
• 자율적인 팀(autonomous teams): 각 팀은 성공에 필요한 인력을 갖추고 스스로 해결한다.
• 팀 단위 책임: "개인에게 책임을 묻지 않고 팀에게 책임을 부여한다." 사람은 팀 사이를 옮겨 다닐 수 있지만, 책임을 소유하는 건 팀이다.

브레인스토밍 방법론

1. 고객이 가진 문제는 무엇인가?
2. 어떤 제품이나 기술이 그 문제를 해결할 수 있는가? (시간 여행이라도 좋다)
3. 우리가 무엇을 알게 되기를 바라는가?
4. 알고 싶은 것을 어떻게 하면 가장 빨리 배울 수 있을까?

핵심: 적자마자 답하지 말고, 잊어버리고 다음 질문으로 넘어간다. 결국 화이트보드는 고객에게 가치 있는 '할 수 있는 일들'로 가득 찬다.

엘도라도(El Dorado) 프로젝트

탄생 배경

"자율적인 팀들이라... 뭐가 잘못될 수 있을까?" — 자율 팀 체제에서는 서비스가 폭발적으로 늘어난다. 서비스들을 어떻게 정리할 것인가?

동료 앤드류(Andrew)가 데이터 센터의 서비스를 스프레드시트로 정리하려다 한계에 부딪혔다. 워드가 Neo4j를 제안했고, 앤드류가 하룻밤 만에 만들어왔다. 여러 소스의 정보를 그래프에 넣고 합치니 질문이 무궁무진해졌다.

구조 창고(Structure Warehouse)

데이터 웨어하우스가 아닌 '구조 창고'. 약 20개의 소스에서 데이터를 읽어와 ETL로 Neo4j에 쌓고, 루비(Ruby) UI로 탐색한다.

• 사이퍼(Cypher) 쿼리로 질문
• 결과를 Graphviz 다이어그램으로 시각화
• 노드나 화살표를 클릭해서 드릴다운
• 쿼리는 수정 가능한 폐쇄 루프(closed loop) 구조

핵심 통찰

워드가 에릭에게 보여줬을 때:

• 에릭: "그게 바로 컨텍스트 맵(context map)이고 바운디드 컨텍스트(bounded context)군요"
• 워드: "바운디드 컨텍스트가 뭐죠?"
• 에릭: "당신이 내 책 리뷰도 해줬으면서!"

워드는 리팩토링(refactoring)의 신봉자라서 "기술 부채를 잘 관리하면 어디에나 통용되는 하나의 유비쿼터스 언어를 갖게 될 것"이라 믿었다. 그래서 DDD 책 4장(바운디드 컨텍스트)을 무시했다. 하지만 에릭이 맞았고 워드가 틀렸다. 누구도 그 정도로 리팩토링을 하지는 않는다. 에릭이 30년 전에 예측한 것을 워드는 이제야 발견하고 있었다.

실제 작동 방식

• 노드 타입: 팀, 서비스, 프로그램, 프로세스, 시스템 등
• 관계: 소유(OWNS), 의존(DEPENDS), 부분(PART-OF) 등
• 다양한 소스에서 팀 이름조차 일관되게 표기하는 곳이 없다 → 대여섯 가지 휴리스틱 매처 적용
• '부분(part-of)' 관계만 기술하고, 연결 방식은 내부(카프카 프로듀서/컨슈머 등)를 들여다보며 유추

누가 쓰는가

• 아키텍트: 시스템 전체를 이해하기 위해
• 자율적인 개발자: "내 에이전트에서 UI 차트까지 어떻게 연결되는가?"를 알기 위해
• 보안 팀: 포트 스캔 결과에서 해당 팀/매니저/슬랙 채널을 찾기 위해
• 궁극적으로: 모든 사람

ETL의 어려움

• 본질적으로 사무적인(clerical) 작업. 데이터 정제.
• 새 데이터 소스 추가에 하루 정도 소요
• 각 소스마다 언어와 네이밍이 다름 → 휴리스틱 매칭 필요
• 하기 싫은 사무적인 일은 프로그래밍 과제로 바꿔서 즐겁게 만든다

페더레이티드 위키(Federated Wiki)

워드가 6년간 만들어온 시스템. 오리지널 위키처럼 탐구를 위한 것이지만 데이터를 포함한다.

자전거 공유 서비스 예시: 포틀랜드의 힙한 동네를 지도에 표시하고, 실시간 자전거 스테이션 데이터를 연결해서 "힙한 장소 근처에 자전거 스테이션이 몇 개나 있나?" 같은 질문에 답한다. 페이지는 정적이지만 브라우저 내 동일한 객체 공간에서 데이터가 동적으로 흐른다.

두 가지 시사점

1. 구조 창고(Structure Warehouse): 단순히 데이터가 아니라 모든 것이 구조(연결)에 관한 것
2. 베이지안(Bayesian) 스타일 인터페이스: 자신의 가정을 가지고 탐색하다가 반대되는 증거를 발견하면 믿음을 수정하고, 그것이 결과물에 반영되도록 하는 발견 유도 인터페이스

"숫자보다 풍부하고 복잡한 데이터를 다루는 도구의 작동 방식이 우리 산업이 나아갈 방향이다. 우리에겐 컴퓨터, 그래픽, 언어가 다 있다. 오직 '의지'만 있으면 된다."