Git 고고학 #8 — 공학 상대성: 왜 같은 엔지니어가 다른 점수를 받는가

Source: Dev.to

Source: …

엔지니어링 상대성

같은 물체가 달에서는 가볍고 목성에서는 무겁습니다. 같은 현상이 코드베이스에서도 일어납니다.

7장에서는 코드베이스의 우주와 같은 구조—중력, 네 가지 힘, 그리고 “숙련된 좋은 중력”에 대해 이야기했습니다. 이번 장에서는 그 중력의 또 다른 근본적인 속성에 대해 다룹니다.

중력은 그 우주에 따라 달라진다

다양한 코드베이스에서 EIS 결과를 살펴보니 다음과 같은 점을 발견했습니다:

중력은 우주에 따라 변한다.

EIS는 코드베이스에서 얼마나 많은 중력을 만들었는지를 측정하지만, 중력에는 한 가지 중요한 특성이 있습니다: 그 존재하는 공간에 의존한다는 점입니다.

• 물리학에서 지구, 달, 목성은 각각 다른 중력장을 가지고 있습니다. 같은 물체가 어디에 있느냐에 따라 가볍거나 무거워집니다.
• 코드베이스에서도 같은 엔지니어가 서로 다른 코드베이스에서 서로 다른 EIS 점수를 받습니다.

성숙한 코드베이스 vs. 약한 코드베이스

• 성숙한 환경에서는 새로운 중력을 만들기가 어렵습니다. 기존 구조가 강할수록 중심을 이동시키는 데 더 많은 에너지가 필요하므로 EIS 점수를 올리기가 힘듭니다.
• 약한 환경에서는 첫 번째로 괜찮은 설계를 도입한 사람이 하룻밤 사이에 아키텍트가 되고, EIS 점수를 올리기가 쉬워집니다.

결과: EIS는 절대값이 아닙니다. 엔지니어 와 코드베이스의 중력장 사이의 상호작용에 의해 결정됩니다.
이것은 일종의 엔지니어링 상대성—다른 우주에 있는 같은 엔지니어가 다른 중력을 만든다는 의미입니다.

엔지니어링 평가에 대한 시사점

다음과 같은 점수를 가진 엔지니어를 상상해 보세요:

당연히 60이 “더 좋게” 보입니다.
하지만 레포 A가 극도로 강한 중력장—다수의 아키텍트, 고도로 정제된 구조, 전투 테스트를 거친 추상화—을 가지고 있다면, 그 맥락에서 35는 실제로 눈에 띄는 성과일 수 있습니다.

정규화 함정: EIS의 상대적 정규화는 각 팀의 최고 기여자가 100점을 받게 하므로, 한 레포에서의 최고 점수가 다른 레포에서는 평범할 수 있습니다.
정규화는 계산 문제이고, 엔지니어링 상대성은 구조 문제입니다. 코드베이스 자체가 점수의 의미를 바꿉니다.

상대성을 고려하는 방법

1. eis analyze --team 확인하기

Structure: Architectural Engine → Strong gravitational field (scores are hard‑earned)
Structure: Unstructured          → Weak gravitational field (scores come easily)

Total: 40 inside an Architectural Engine
Total: 40 inside an Unstructured team

동일한 총점이라도 의미가 완전히 다릅니다.

• 팀에 아키텍트가 많을수록 Design 축을 올리기가 더 어렵습니다.
• Design: 60을 세 명의 아키텍트가 있는 팀에서 얻는 것은 아키텍트가 전혀 없는 팀에서 Design: 100을 얻는 것보다 더 어려울 가능성이 높습니다.

2. 재귀적 크로스‑레포 분석

eis analyze --recursive ~/workspace

여러 레포지토리를 가로질러 분석하면 엔지니어의 “단일 우주를 넘어선 중력”을 파악할 수 있습니다.

• 한 레포에서는 Producer, 다른 레포에서는 Architect — 이런 패턴은 적응력과 잠재 역량을 보여줍니다.

eis timeline --span 6m --periods 0 --recursive ~/workspace

코드베이스 구조는 정적이지 않습니다. 멤버 이탈, 리팩터링, 신규 기능—all이 중력장을 이동시킵니다. 타임라인을 통해 다음을 구분할 수 있습니다:

• 구조가 약해질 때 점수가 상승하는 엔지니어
• 구조 강도와 관계없이 점수를 안정적으로 유지하는 엔지니어

아키텍트 재현성

진정으로 뛰어난 엔지니어는 어떤 우주에서도 중력을 만든다—다양한 코드베이스, 팀, te

Source: …

ch 스택. 이것을 Architect Reproducibility 라고 부를 수 있습니다.

--recursive 옵션으로 전체 워크스페이스를 분석하면, 여러 저장소에서 지속적으로 Architect 역할을 수행하는 엔지니어는 특정 코드베이스에 의존하지 않는 범용 설계 능력을 가지고 있음을 알 수 있습니다.

Gravitational Lensing in Codebases

천체물리학에서, 거대한 물체는 뒤에 있는 물체들의 빛을 휘게 만드는 방식—중력 렌즈 효과—으로 탐지됩니다.

코드베이스에서는 Architect의 중력이 자신의 점수가 아니라 다른 사람들의 점수에 어떻게 영향을 미치는가에서 가장 뚜렷하게 드러납니다.

• 강력한 Architect가 존재할 때:

  • 다른 엔지니어들의 Survival 점수가 낮아질 수 있습니다(Architect의 코드가 블레임을 많이 차지함).
  • 팀의 Design 축 분포가 한쪽으로 치우칩니다(한 사람이 대부분의 아키텍처 변화를 흡수).
  • 새로 합류한 사람들은 특유의 “런업 곡선”을 보이며, 초기 점수가 낮았다가 점차 기존 구조에 기여하게 됩니다.

• 그 Architect가 떠날 때:

  • 여러 엔지니어들의 점수가 동시에 변동합니다.
  • Design Vacuum 위험이 나타납니다.
  • 점수 분포의 “평탄화”는 중력 중심이 사라졌음을 알리는 신호입니다.

eis timeline --team 명령으로 이를 관찰할 수 있습니다. 중력 중심이 사라지는 순간, 팀 전체의 메트릭이 파동처럼 움직입니다. 중력은 실제로 존재했으며, 그 전체 형태를 보려면 다른 사람들의 메트릭에 미친 영향을 살펴봐야 합니다.

Bottom Line

Engineering Relativity는 EIS의 한계가 아니라, 엔지니어와 그들이 작업하는 코드베이스 사이의 실제적이고 동적인 관계를 반영하는 특징입니다. 이 상대성을 이해하고 고려하면 다음을 할 수 있습니다:

1. 점수를 고립된 값이 아니라 맥락 속에서 해석한다.
2. 다양한 환경에서 중력을 생성할 수 있는 진정한 적응형 Architect를 식별한다.
3. 강력한 Architect의 숨은 영향을 동료들의 메트릭을 통해 포착한다.

상대성을 수용함으로써, 원시 숫자를 사람, 구조, 그리고 끊임없이 변하는 중력에 대한 풍부한 이야기로 전환할 수 있습니다.

Engineering Relativity

엔지니어링 영향을 측정할 때, 어떻게 하면 공정한 비교를 할 수 있을까요?
하지만 저는 이것을 제한이 아니라 특징이라고 봅니다.

물리학에서 상대성이론이 발견되었을 때, *“절대적인 시간이나 공간은 존재하지 않는다”*는 사실은 직관에 반했습니다. 이를 받아들이면 우주에 대한 이해가 기하급수적으로 깊어졌습니다.

EIS도 마찬가지입니다.

점수가 환경에 따라 변한다는 사실은 엔지니어를 그들의 환경을 무시하고 비교하는 것이 본질적으로 의미가 없다는 것을 가르쳐 줍니다. 엔지니어의 실제 역량은 진공 상태에서 측정될 수 없으며, 항상 코드베이스—그들이 활동하는 우주와의 관계 속에 존재합니다.

진정으로 위대한 엔지니어는 어떤 우주에서도 중력을 만들어냅니다.
하지만 그 중력은 우주에 따라 다르게 보입니다.

이것이 Engineering Relativity입니다.

Chapters

1. Git 히스토리만으로 엔지니어링 영향 측정
2. 개별 점수를 넘어: Git 히스토리로 팀 건강도 측정
3. 아키텍트로 가는 두 길: 엔지니어가 다르게 성장하는 방식
4. 백엔드 아키텍트의 수렴: 영혼을 쉬게 하는 신성한 작업
5. 타임라인: 점수는 거짓말을 하지 않으며, 주저함도 포착한다
6. 팀의 진화: 타임라인이 밝혀낸 조직 법칙
7. 코드 우주 관찰하기
8. Engineering Relativity: 왜 같은 엔지니어가 다른 점수를 받는가 (이 포스트)

Tools

• GitHub: engineering-impact-score – CLI 도구, 공식, 방법론 모두 오픈 소스입니다.
• Homebrew로 설치:

brew tap machuz/tap && brew install eis

If this was useful…

레포지토리에 ⭐️를 달거나, 개념을 팀과 공유하거나, 개선 사항을 기여해 주세요!