콘웨이의 법칙(Conway's law)

• 개요
• 멜빈 콘웨이(Melvin E. Conway)
• 인용과 해석
  • 콘웨이의 논문에 소개된 콘웨이의 법칙
    • 결론
    • stages of design
  • 데브옵스 핸드북에서 말하는 콘웨이의 법칙
  • The Jargon File에 수록된 콘웨이의 법칙
  • Tom Cheatham의 추가 해석
  • Ruth Malan의 해석
  • 실용주의 프로그래머에서 말하는 콘웨이의 법칙
  • 스티브 맥코넬이 설명한 콘웨이의 법칙
  • 프레드 브룩스가 설명한 콘웨이의 법칙
  • 마이크로소프트의 Windows Vista 사례 연구
  • 콘웨이의 법칙에 대한 엉클 밥의 코멘트
  • 샘 뉴먼이 말하는 응용 방법
  • 콘웨이의 법칙과 3계층 아키텍처
• 역콘웨이의 법칙
  • 크리스 리처드슨
  • 수잔 파울러
  • 주의할 점: 팀의 구조에 따라 Functional Sharding을 하지 말 것
• 애플리케이션 개발 단순화를 위한 교훈들
• Links
• 참고문헌
• 각주

개요

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.¹

• 소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게 된다.
• 콘웨이가 논문을 Havard Business Review에 제출했을 때에는 가설을 입증할 수 없다는 이유로 거절당했다고 한다.²
  • 그러나 개발자들 사이에서는 상식의 반열에 오른 법칙이다.

멜빈 콘웨이(Melvin E. Conway)

• 멜빈 콘웨이는 컴퓨터 과학자이자, 해커이다.
• SAVE라 불리는 Burroughs 220을 위한 어셈블러를 작성한 바 있다.

인용과 해석

콘웨이의 논문에 소개된 콘웨이의 법칙

• 1968년4월, Datamation 지에 실린 콘웨이의 논문 "HOW DO COMMITTEES INVENT?".

결론

다음은 콘웨이 논문의 결론 부분을 인용하고 간단하게 번역한 것이다.

Conclusion

The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.
This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.
Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.

결론

이 논문의 기본 논제는(넓은 의미에서) 시스템을 설계하는 조직은 조직의 의사소통 구조를 본딴 설계를 생산하도록 제약된다는 것이다. 우리는 이 사실이 시스템 설계 관리에 중요한 영향을 미친다는 것을 보았다. 기본적으로, 우리는 설계 조직의 구조에 대한 기준을 발견했다: 설계 활동은 의사소통 필요에 따라 조직되어야 한다.

이 기준은 유효한 시스템의 개념이 시기에 따라 바뀌고 그에 따라 의사소통의 필요성이 달라질 수 있기 때문에 문제를 일으킨다. 최초의 설계가 최선의 설계일 가능성이 없으므로, 일반적인 시스템 개념의 변경이 필요할 수 있기 때문이다. 따라서 효율적인 설계에는 조직의 유연성이 중요하다.

조직을 기민하고 유연하게 유지한 설계 관리자에게 보상을 할 수 있는 방법을 찾아야 한다. 단순하게 인력을 추가하는 것이 생산성을 증가시킨다는 가정에 근거하지 않는 시스템 설계 관리상의 철학이 필요하다. 이러한 철학의 발전은 자원의 가치와 의사소통의 기술에 대한 근본적인 문제들, 즉 우리의 시스템 구축 기술이 확신 위에서 진행되기 위한 과제들을 밝혀내게 될 것이다.

stages of design

Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist.

어떤 설계 팀 조직이라도 필요한 커뮤니케이션 경로가 전혀 존재하지 않기 때문에 추구할 수 없는 대안적인 설계 유형이 존재한다.

데브옵스 핸드북에서 말하는 콘웨이의 법칙

결국, 팀을 구성하는 방법은 업무 수행 방식에 영향을 미친다. 1968년, 멜빈 콘웨이 박사는 코볼과 ALGOL 컴파일러를 제작하는 연구팀 여덟 명과 함께 유명한 실험을 수행했다. 콘웨이 박사는 다음과 같이 말했다.

"처음에 난이도와 시간을 추정한 후, 다섯 명이 코볼 작업에 그리고 세 명이 ALGOL 작업에 배정됐다. 그 결과, 코볼 컴파일러는 5단계, ALGOL 컴파일러는 3단계로 실행됐다." ³

The Jargon File에 수록된 콘웨이의 법칙

에릭 레이몬드는 [[/book/the-jargon-file]]의 콘웨이의 법칙 항목에서 다음과 같이 말했다.

If you have four groups working on a compiler, you'll get a 4-pass compiler.

하나의 컴파일러를 만들기 위해 4개의 팀이 조직된다면, 4단계로 빌드하는 컴파일러가 나오게 된다.

명쾌한 설명이라 생각한다.

Tom Cheatham의 추가 해석

If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager.

N 명의 그룹이 코볼 컴파일러를 구현한다면, N-1 단계가 될 것이다. 왜냐하면 한 사람은 관리자가 되어야 할 테니까.

• 관료제를 중시한 코볼 업계를 돌려 비판한 말이라고 할 수 있겠다.

Ruth Malan의 해석

If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.

시스템 구조와 조직 구조가 대립하면 언제나 조직 구조가 승리한다. ⁴

실용주의 프로그래머에서 말하는 콘웨이의 법칙

1967년 멜빈 콘웨이_{Melvin Conway}는 <How do Committees Invent?(위원회는 어떻게 발명을 하는가?)>라는 논문에서 훗날 콘웨이의 법칙_{Conway's law}으 알려지게 되는 발상을 소개했다.

시스템을 설계하는 조직은 조직의 의사소통 구조를 그대로 본뜬 설계를 만들기 마련이다.

즉, 팀이나 조직의 사회적 구조 및 의사소통 경로가 그들이 만드는 애플리케이션, 웹 사이트, 제품에 반영된다는 것이다. 많은 연구가 이것이 사실임을 잘 보여 주었고, 우리도 셀 수 없을 만큼 많이 목격했다. 예를 들어, 아무도 서로 이야기하지 않는 팀에서는 사일로_silo나 연통_stove-pipe처럼 칸칸이 쪼개 시스템을 만들었다. 사람들이 두 무리로 쪼개진 팀에서는 클라이언트/서버나 프론트엔드/백엔드로 나뉘었다.

연구에 따르면 이 원칙을 역으로 이용할 수도 있다. 여러분이 만들고 싶은 코드 구조에 맞추어 팀을 조직하는 것이다. 예를 들어 팀이 여러 지역으로 나뉘어 있으면 더 모듈화, 분산화된 소프트웨어를 만드는 경향이 있다.

어쨌든 가장 중요한 것은 이것이다. 고객이 개발팀의 일원일 때 만들어지는 소프트웨어는 고객의 존재가 잘 드러날 것이고, 고객이 개발팀에 속해 있지 않다면 그것 역시 잘 드러날 것이다. ⁵

스티브 맥코넬이 설명한 콘웨이의 법칙

[[/PROFESSIONAL-SOFTWARE-DEVELOPMENT]]{Professional 소프트웨어 개발}에서 스티브 맥코넬은 다음과 같이 설명한다.

콘웨이 법칙은 "프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다"는 것이다. 혼란스러운 회사는 혼란스러운 소프트웨어만 만들어낸다. 영웅 개발자를 고용하고, 그들에게 전권을 주며, 기적을 만들어 내기 위해 영웅들을 자유롭게 놔두는 회사는 결국 기발할지는 모르지만 에러도 무지하게 많은 제품을 만들어 낸다. 비효율적인 프로세스를 실행하는 회사의 제품은 유치하고 둔한 반면, 효과적이고 최적화된 조직은 조화롭고 아주 만족스러운 소프트웨어를 만들어 낸다.⁶

프레드 브룩스가 설명한 콘웨이의 법칙

[[/book/mythical-man-month]]의 "10장 기록물 가설"을 읽어보면 프레드 브룩스가 콘웨이의 법칙을 설명한다.

조직도는 콘웨이의 법칙이 말하는 것처럼 인터페이스 명세와 서로 얽혀 있다. "시스템을 설계하는 조직은, 그 조직의 의사소통 구조를 본뜬 시스템을 만들어내게 되어 있다." 이어서 콘웨이는 최초의 조직도에는 첫 설계 내용이 반영될 것이라고 지적한다. 이 설계가 제대로일 가능성은 물론 아주 낮다. 시스템 설계가 자유롭게 변경될 수 있어야 한다면 조직 역시 변화에 대비하고 있어야 한다.

마이크로소프트의 Windows Vista 사례 연구

• The Influence of Organizational Structure On Software Quality: An Empirical Case Study
  • PDF

Windows Vista 개발 조직과 소프트웨어 품질과의 상관관계를 연구한 경험적 사례 연구이다.

다음은 결론 부분의 일부를 인용한 것이다. 번역은 파파고가 했다.

Our study also compares the prediction models built using organizational metrics against traditional code churn, code complexity, code coverage, code dependencies and pre-release defect measures to show that organizational metrics are better predictors of failure-proneness than the traditional metrics used so far.

또한 본 연구는 조직 지표를 사용하여 구축된 예측 모델을 전통적인 코드 전환, 코드 복잡성, 코드 의존성 및 발표 전 결함 조치와 비교하여 조직 지표가 지금까지 사용한 기존 지표보다 더 나은 오류 발생 예측 변수임을 보여준다.

콘웨이의 법칙에 대한 엉클 밥의 코멘트

밥 아저씨(로버트 C. 마틴)는 클린 아키텍처에서 콘웨이의 법칙을 언급하고 다음과 같이 말한다.⁷

많은 팀으로 구성되며 관심사가 다양한 조직에서 어떤 시스템을 개발해야 한다면, 각 팀이 독립적으로 행동하기 편한 아키텍처를 반드시 확보하여 개발하는 동안 팀들이 서로를 방해하지 않도록 해야 한다. 이러한 아키텍처를 만들려면 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다. 그래야만 이들 컴포넌트를 독립적으로 작업할 수 있는 팀에 할당할 수 있다.

샘 뉴먼이 말하는 응용 방법

그렇다면 우리가 소유한 서비스의 설계를 진화시키려 할 때 어떻게 해야 할까? 필자는 서비스가 분해되어야 할 때 시스템 개발에 연관된 사람들의 지리적인 경계가 이를 추진할 훌륭한 방법이 될 수 있다고 제안한다. 그리고 일반적으로 서비스의 소유권을 변경 비용을 적게 유지할 수 있는 동일 위치의 한 팀에 부여할 것을 검토해야 한다.⁸

• 매우 단순한 예
  • 서비스를 분리해야 한다면 => 지리적으로 분리된 여러 팀이 한 서비스를 유지보수하게 한다.
  • 서비스를 합쳐야 한다면 => 동일 위치의 한 팀이 서비스를 유지보수하게 한다.

콘웨이의 법칙과 3계층 아키텍처

바로 3계층 아키텍처가 이런 콘웨이 법칙이 적용되는 좋은 예다. 과거 IT 조직은 핵심 역량 측 면에서 사람들을 그룹으로 묶었다. 데이터베이스 관리자는 데이터베이스 관리자들끼리, 자바 개발자는 자바 개발자들끼리 팀을 구성했다. 프론트엔드 개발자들은 요즘엔 자바스크립트와 네이 티브 모바일 앱 개발 같은 신종 기술을 아는 자기들끼리 팀을 꾸렸다. 핵심 역량을 기준으로 인력 을 그룹짓고, 각 팀에 연관된 IT 자산을 만든다.

이는 3계층 아키텍처가 왜 그토록 흔한지에 대한 이유를 설명한다. 3계층 아키텍처 자체만 놓고 보면 나쁘지 않다. 3계층 아키텍처는 그저 우리가 전통적으로 어떻게 사람들을 그룹으로 묶었 는지를 보여주며, 친밀도를 중심으로 한 조직의 집합에 최적화되어 있을 뿐이다. 그러나 상황이 바뀌었다. 소프트웨어에 대한 우리의 열망도 바뀌었다. 이제 우리는 사람들을 다재다능한 팀으로 묶어서, 업무 이관과 사일로 현상을 줄인다. 우리는 그 어느 때보다도 훨씬 더 빠르게 소프트 웨어를 출시하길 원한다. 이런 변화를 통해 우리는 어떻게 팀을 조직하고, 그 결과로 어떻게 시 스템을 분해하는지에 대해 새로운 선택을 하고 있다.

기능 변경은 주로 비즈니스 기능의 변경에 초점을 맞춘다. 그러나 그림 1-1을 보면, 우리의 비즈니스 기능은 사실상 모두 3개 계층에 분산되어 있으며, 기능 변경은 여러 계층에 걸쳐 있을 가능성이 높다. 3계층 아키텍처는 기술 관점에서 응집력이 높지만, 비즈니스 기능 관점에서는 응집력이 낮다. 쉽게 변경할 수 있게 만들려면 코드를 그룹화하는 방식을 바꿔야 한다. 즉 기술 보다는 비즈니스 기능의 응집력을 선택할 필요가 있다. 각 서비스는 이런 세 계층의 혼합을 포함하는 상황으로 끝날 수도 그렇지 않을 수도 있지만 이런 서비스는 로컬 서비스 구현 문제일 뿐이다.

– 마이크로서비스 도입 이렇게 한다. 1장.

역콘웨이의 법칙

크리스 리처드슨

크리스 리처드슨(Chris Richardson)은 마이크로서비스 패턴(Microservices Patterns)에 다음과 같은 노트를 삽입했다.⁹

역 콘웨이 전략(reverse Conway maneuver)

(중략)

즉, 애플리케이션 아키텍처는 그것을 개발하는 조직의 구조를 그대로 반영한다는 뜻입니다. 따라서 이 법칙을 역으로 이용해서 조직의 구조가 마이크로서비스 아키텍처에 고스란히 반영되도록 설계해야 합니다. 이렇게 하면 개발 팀과 서비스를 느슨하게 결합시킬 수 있습니다.

수잔 파울러

Inverse Conway's Law

수잔 파울러(Susan Fowler)는 마이크로서비스 구축과 운영(Production-Ready Microservices)에서 마이크로서비스 관점에서 역콘웨이의 법칙에 대해 이야기한다.¹⁰

역콘웨이의 법칙이라 불리는 콘웨이 법칙의 역('회사 제품의 아키텍처가 회사의 조직 구조를 결정한다')도 유효한데 이는 특히 마이크로서비스 생태계에 의의가 있다. 콘웨이의 법칙이 처음 소개된 지 40년이 지난 지금, 콘웨이의 법칙과 역콘웨이의 법칙 둘 다 여전히 유효하다. 마이크로소프트 사의 조직 구조를 시스템 아키텍처처럼 스케치하면 마이크로소프트 사의 제품 아키텍처와 매우 비슷하다. 구글, 아마존 등 다른 대형 기술 회사도 마찬가지다. 마이크로서비스 아키텍처를 도입한 회사도 이러한 규칙을 예외 없이 적용할 수 있다.

마이크로서비스 아키텍처는 독립적으로 격리된 작은 마이크로서비스로 구성된다. 역콘웨이의 법칙에서 마이크로서비스 아키텍처를 사용한 회사는 조직 구조를 매우 작고 격리된 독립적인 팀으로 구성할 것을 요구한다. 이로부터 발생하는 팀 구조는 필연적으로 사일로 현상과 스프롤 현상을 야기한다. 마이크로서비스 생태계가 좀 더 정교하고 복잡해지고 동시적이고 효율적일 때마다 문제는 악화된다.

역콘웨이의 법칙은 어떤 점에서는 개발자도 마이크로서비스와 같을 것이라는 것을 의미한다. 개발자는 한 가지 업무를 하며 그 한 가지 업무를 매우 잘 수행할 것이다. 개발자는 특정 분야의 지식과 경험, 책임 면에서 마이크로서비스 생태계의 나머지 부분과 격리된다. 총체적으로 보면 마이크로서비스 생태계의 모든 개발자는 업무에서 경험하는 마이크로서비스 생태계의 모든 것을 안다. 반면, 개개의 개발자는 매우 전문화됐기 때문에 담당하고 있는 마이크로서비스 생태계의 업무에 대해서만 안다.

이로부터 야기되는 조직적인 문제는 피할 수 없다. 팀이 격리되고 단절된 채로 마이크로서비스를 개발해야 하더라도 마이크로서비스는 서로 고립되지 않으며 이왕 제품이 전체적으로 작동하려면 마이크로서비스 간 소통이 원활해야 한다. 따라서 팀은 격리되고 독립적으로 기능하면서도 서로 긴밀히 협력해야 한다. 팀의 목적과 핵심 결과 지표를 성문화한 대부분의 팀 목표와 계획이 해당 팀이 담당하는 마이크로서비스에만 특정한다는 점을 고려해보면 마이크로서비스 간의 원활한 소통은 다소 힘들 수 있다.

(중략)

역콘웨이의 법칙 때문에 발생하는 관련 문제는 더 있다. 모놀리식 아키텍처를 사용하는 회사에서 거의 발견되지 않는 운영 조직에 대한 운영의 어려움이다. 모놀리스에서는 애플리케이션을 위해 운영 인력의 배치와 비상 대기 업무 지원이 용이하지만 마이크로서비스 아키텍처에서는 잘 해내기가 매우 어렵다. 왜냐하면 마이크로서비스마다 개발 팀과 운영 팀 둘 다 배치해야 하기 때문이다. 결과적으로 마이크로서비스 개발 팀은 운영 업무와 마이크로서비스에 연관된 작업을 담당해야 한다. 비상 대기 업무와 모니터링 업무를 맡을 별도의 운영 조직이 없다. 즉, 개발자는 자신의 서비스에 대해 비상 대기해야 한다.

주의할 점: 팀의 구조에 따라 Functional Sharding을 하지 말 것

• 팀의 구조에 따라 각각의 데이터 table을 다른 database에 두고 싶다면 매우 신중하게 결정해야 한다.
• 팀보다 데이터가 더 오래 살아남기 때문이다.

비즈니스에서 '기능'을 기반으로 데이터를 분할하려면 데이터가 무엇인지 깊은 이해가 필요합니다. 이는 서비스 지향 아키텍처(SOA) 및 마이크로 서비스와 같은 일반적인 소프트웨어 아키텍처 패러다임과 맞물려 있습니다. 모든 기능적 접근 방식이 동일한 것은 아니며, 위의 극단적인 비즈니스 사레에서 각 테이블을 자체 '기능적' 데이터베이스에 넣는다면 너무 많은 단편화로 인해 모든 것을 악화시킬 수 있습니다.

우려되는 대규모 단일/혼합 데이터베이스를 비즈니스 확장에 도움이 되는 합리적인 소규모 클러스터 세트로 분할하려면 어떻게 해야 할까요? 다음 몇 가지 지침을 기억해두세요.

• 엔지니어링 팀의 구조에 따라 나누지 마십시오. 그 구조는 어느 순간 바뀔 것입니다.
• 비즈니스 기능에 따라 테이블을 분할합니다. 계정 등록을 지원하는 테이블은 기존 고객 설정을 호스팅하는 테이블과 분리될 수 있으며 새로운 기능을 지원하는 테이블은 자체 데이터베이스에서 시작해야 합니다.
• 데이터에 별도의 비즈니스 문제가 뒤섞이는 것을 너무 두려워하지 마십시오. 데이터 분리뿐만 아니라 애플리케이션 리팩터링이나 API 액세스 도입 문제가 있을 수도 있습니다. 흔한 예로 고객 ID와 고객 청구서를 혼합하는 것을 들 수 있습니다. ¹¹

애플리케이션 개발 단순화를 위한 교훈들

Toward Simplifying Application Development, in a Dozen Lessons Mel Conway

So how do you use it? The importance of the principle as a guide to action is not that your design organization determines the things you can design; as a guide to action, that’s not particularly useful. The importance of the principle as a guide to action is that you need to know that your design organization is keeping you from designing some things that perhaps you should be building. The principle creates an imperative (1)to keep asking: “Is there a better design that is not available to us because of our organization?” and (2)to be open to changing the organization if a better design is found. ¹²

그래서 우리는 이것을 어떻게 이용해야 할까요? 행동 지침으로서 이 원칙의 중요성은 설계 조직이 당신이 설계할 수 있는 것을 결정짓는다는 지점에 있지 않습니다. 그런 측면은 행동 지침으로서는 유용하지 않죠.

행동 지침으로서 이 원칙의 중요성은, 만들어야 하는 어떤 것들이 조직 구조 때문에 설계를 할 수 없도록 막혀 있다는 사실을 알아야 한다는 것입니다.

이 원칙은 다음 질문을 계속해서 던지라고 합니다. "조직 구조 때문에 우리가 만들 수 없다고 여겼던, 더 나은 설계가 존재하는가?" 그리고 더 나은 설계가 발견되었을 때 변화할 수 있는 열린 조직이 되어야 한다고 합니다.

Links

• CONWAY'S LAW: Conway 홈페이지에 소개된 Conway's law.
• How Do Committees Invent? - Melvin E. Conway: 1968년 Conway's law가 소개된 콘웨이의 페이퍼.
• Toward Simplifying Application Development, in a Dozen Lessons - Mel Conway (pdf): 콘웨이의 2018년 페이퍼.
  • 백업
  • 이 글을 소개하는 콘웨이의 트윗
• Conway's law(the jargon file)
• Conway's law(wikipedia)
• Melvin Conway(wikipedia)

참고문헌

• MySQL 성능 최적화 / 실비아 보트로스, 제레미 틴리 저/류수미, 송희정 역 / 위키북스 / 초판발행 2022년 09월 22일 / 원제 : High Performance MySQL 4E
• Professional 소프트웨어 개발 / 스티브 맥코넬 저 / 윤준호, 한지윤 공역 / 인사이트(insight) / 초판 4쇄 2006년 10월 13일 / 원제 : Professional Software Development (Addison-Wesley)
• 데브옵스 핸드북 / 진 킴, 제즈 험블, 패트릭 드부아, 존 윌리스 저/김영기 역 외 1명 정보 더 보기/감추기 / 에이콘출판사 / 2018년 07월 06일 / 원제: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
• 마이크로서비스 구축과 운영 / 수잔 파울러 저/서영일 역 / 에이콘출판사 / 발행 2019년 05월 31일 / 원서 : Production-Ready Microservices: Building Standardized Systems Across an Engineering Organization
• 마이크로서비스 도입 이렇게 한다 / 샘 뉴먼 저/박재호 역 / 책만 / 2021년 01월 20일 / 원서 : Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith
• 마이크로서비스 아키텍처 구축 / 샘 뉴먼 저 / 정성권 역 / 한빛미디어 / 초판 2쇄 2017년 05월 01일 / 원서 : Building Microservices: Designing Fine-Grained Systems
• 마이크로서비스 패턴 / 크리스 리처드슨 저/이일웅 역 / 길벗 / 초판발행 2020년 01월 30일
• 실용주의 프로그래머 (20주년 기념판) / 데이비드 토머스, 앤드류 헌트 저/정지용 역/김창준 감수 / 인사이트(insight) / 2판 1쇄 발행 2022년 02월 24일
• 클린 아키텍처 / 로버트 C. 마틴 저/송준이 역 / 인사이트(insight) / 초판 1쇄 2019년 08월 20일 / 원제 : Clean Architecture: A Craftsman's Guide to Software Structure and Design
• 팀 토폴로지 / 매튜 스켈톤, 마누엘 페이스 저/김연수 역 / 에이콘출판사 / 2020년 12월 30일 / 원서 : Team Topologies: Organizing Business and Technology Teams for Fast Flow
• 해커 영어사전 제3판 / Guy L. Steel Jr. Eric S.RayMond 편저, 한경훈 역 / 기전연구사 / 1판 1쇄 1998년 12월 25일 / 원제 : The New Hacker's Dictionary(3rd)

각주