-
대형 테크 시스템의 불투명성
- 대형 테크 회사들은 자사 시스템조차 "전쟁터의 안개(fog of war)" 속에서 운영된다.
- "Y 타입 유저가 기능 X를 쓸 수 있나?", "액션 Z 시 정확히 무슨 일이?", "현재 요금제는 몇 가지?" 같은 기본 질문에조차 조직 내 소수만 답할 수 있다.
- 심하면 조사 전담자를 지정해야 하며, 공개 문서만 봐도 답이 나와야 할 텐데 그렇지 않다.
-
복잡성의 근원: Wicked Features
- 큰 소프트웨어는 self-hosting, 무료 체험, 조직/정책 제어, 다국어 로컬라이징, 규제 준수 기능 등으로 극도로 복잡하다. 이러한 기능은 모든 새 기능에 영향을 미침
- 예: 정책 제어 추가 시 매번 새 기능에도 적용해야 하고, 로컬라이징 시 번역도 따라가야 한다.
- "EU 리전 self-hosting 엔터프라이즈 고객의 특정 기능 접근 여부"는 코드 직접 탐사나 실험으로만 확인. 이런 기능 생략 시 엄청난 수익 포기, 큰 회사와 작은 회사의 차이점.
-
문서화의 한계
- 새 기능 시 상호작용 문서화는 이론적 가능하나, 시스템 변화 속도가 문서보다 빠름.
- 정적 시스템이 아닌 동적 환경에서 문서 작성자는 변화보다 앞서야 하며, 이는 불가능 수준.
- 더 큰 문제: 많은 동작이 명시적 의도 아닌 디폴트 설정 상호작용으로 생김 – 문서화는 실제 시스템 탐사와 같다.
-
답변의 핵심: 코드베이스와 엔지니어
- 정확한 답은 코드베이스 직접 들여다보기로만 나오며, 이는 엔지니어의 권력 기반.
- 엔지니어링 팀의 핵심 기능은 소프트웨어 질문에 답하는 능력
- 특정 코드 머릿속에 사는 암묵적 지식(tacit knowledge) 활용.
- 팀 재편 시 지식 소실로 "탐색적 수술"(코드 수정/체크 강제 등) 필요.
- 코드 작성은 쉽지만, 신뢰성 답변은 자신감 문제로 어렵다(틀릴 위험, 요약 압축 필요).
-
결론: 귀중한 능력
- 비기술직은 소프트웨어가 엔지니어에게 완벽히 이해된다고 믿으나, 대형 시스템은 누구도 완벽히 모름.
- 기본 질문조차 반복 조사 필요, 변화 시 뉘앙스/예외 발생. 정확한 답변 능력은 극히 가치 있음.