Build Systems & Artifact Engineering

1. Overview

빌드 시스템 및 아티팩트 공학(Build Systems & Artifact Engineering, BAE)은 사람이 쓴 텍스트 파일을 하드웨어가 즉각 실행할 수 있는 고밀도 물리 덩어리(Binary, Docker Image 등)로 구워내고, 이 결과물이 '누가, 언제, 어떤 재료로' 만들었는지 완벽히 증명하는 '디지털 제조 공학'입니다.

학습자는 컴파일과 링크의 수리적 결합 수순과, 변경된 부분만 골라 굽는 **증분 빌드(Incremental Build)**의 물리적 가속 원리를 배웁니다. 특히, 한번 구워진 결과물을 절대 수정하지 않는 불변 아티팩트(Immutable Artifact) 원칙과, 이를 안전하게 보관하는 **아티팩트 저장소(Repository)**의 수리적 수순을 익힙니다. 이를 통해 어떤 환경에서도 "내가 구운 바로 그 파일"이 동일하게 동작함을 보장하는 하이엔드 소프트웨어 공급망 관리 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Build Automation: Makefile, Gradle, Webpack 등 빌드 도구의 물리적 작업 연결(Task DAG)
• Dependency Resolution: 하위 라이브러리들의 수리적 의도 파악과 버전 충돌 물리 해결
• Artifact Management: 저장소(Nexus, Artifactory)를 통한 바이너리의 물리적 버저닝
• Reproducible Builds: 동일 소스로부터 비트 단위까지 일치하는 결과물을 내는 수리적 통제
• Build Performance: 캐싱, 병렬화, 분산 빌드를 통한 하드웨어 빌드 시간($T$) 단축

Out-of-Scope

• 소스 코드 내부의 알고리즘 수리 설계 (04-03-XX 영역으로 위임)
• 빌드된 아티팩트를 서버에 배치하는 배포(CD) 물리 상세 (09-03-03 IaC 영역에서 분담)

Boundaries

• BAE vs. GPA: GPA(09-03-01)가 '변화의 기록(Source)'에 집중한다면, BAE는 그 기록의 '결과물(Binary)'과 그 결과물을 만드는 '기계(Build System)'에 집중하여 경계를 구분합니다.

3. Counterexample

• 단순히 "커맨드 입력해서 빌드하기"라 설명하는 것은 BAE 학습이 아닙니다. 왜 빌드 아티팩트가 저장될 때 'Hash값' 기반의 식별자를 가져야 하드웨어 노드 간의 불일치를 물리적으로 방지할 수 있는지 수리적으로 증명할 수 있어야 하며, 증분 빌드의 캐시 무효화($Invalidation$) 로직 오류가 왜 '낡은 코드 조각'이 남은 변종 하드웨어를 탄생시키는지 논증하지 못한다면 BAE의 정수를 이해하지 못한 것입니다.

4. Prerequisites

• Git Physics & Advanced Workflows (Basic): 09-03-01의 소스 이력 및 태깅 이해가 필수입니다.
• Programming Languages Compilers (Recommended): 05-02-XX의 컴파일러 최적화 및 링크 이해가 권장됩니다.

5. Learning Map

1. Recipe to Product: 소스라는 재료를 빌드 스크립트라는 레시피에 태워 실제 물건(Artifact)으로 뽑아냅니다.
2. The Graph of Tasks: 컴파일, 테스트, 패키징이 꼬이지 않도록 수리적 실행 그래프(DAG)를 설계합니다.
3. Vault of Binary: 만들어진 소중한 결과물을 안전한 보관소에 넣고 고유한 이름표를 붙입니다.
4. Guaranteed Sameness: 언제 어디서 누가 빌드해도 1비트의 오차도 없는 하이엔드 제조 라인을 완성합니다.

6. Learning Topics

Basic

Core: 빌드 도구의 유형과 실행 그래프 (Build Automation)

• Why to Learn: 복잡한 빌드 단계를 순서에 맞춰 하드웨어가 자동으로 실행하게 만들기 위해서입니다.
• What to Learn:
  • Declarative vs Imperative: 빌드 단계를 선언하는 가, 명령하는 가의 수리적 차이
  • Task Dependency: 선행 작업이 끝나야 후속 작업이 시작되는 물리적 인과 관계
  • Build Lifecycle: 초기화, 컴파일, 검증, 패키징의 표준 수순
• How to Learn:
  • Makefile이나 package.json을 작성하여, 파일 하나가 수정되었을 때 의존된 다른 타겟들이 함께 물리적으로 갱신되는지 확인 실습
  • 빌드 전후의 파일 용량($Size$) 변화를 보고 압축 및 최적화 효과 수치 분석
• Implement: 빌드 단계들의 성공/실패 여부를 트래킹하고 시간을 기록하는 기초 BuildRunner

Recommended

Core: 종속성 관리와 버전의 물리학 (Dependency Engineering)

• Why to Learn: 내 코드가 사용하는 수천 개의 외부 부품들이 서로 물리적으로 충돌하지 않게 조율하기 위함입니다.
• What to Learn:
  • Semantic Versioning (SemVer): Major.Minor.Patch가 의미하는 물리적 하위 호환성 규칙
  • Lock Files: 모든 환경에서 동일한 라이브러리 조각을 쓰기 위한 수리적 고정(Locking)
  • Transitive Dependencies: 내가 부른 라이브러리가 몰래 데려온 '친구의 친구' 관리 수순
• How to Learn:
  • 버전 충돌 상황(예: A 라이브러리는 JSON v1을 원하고 B는 v2를 원함)을 재현하고, 수리적으로 'Override' 하는 해결 실습
  • lock 파일 유무에 따라 서로 다른 하드웨어에서 빌드된 바이너리의 해시값이 어떻게 달라지는지 관찰
• Implement: 현재 프로젝트의 전체 종속성 트리를 출력하고 보안 위험도를 체크하는 DepsAudit 도구

Practical

Core: 아티팩트 저장소와 불변성 (Artifact Governance)

• Why to Learn: 빌드된 파일을 이메일로 보내지 않고, 중앙에서 수리적으로 제어되는 정품 인증소를 운영하기 위해서입니다.
• What to Learn:
  • Central Registry: Docker Hub, Nexus 등 바이너리 전용 하드웨어 보관소
  • Immutability Rule: 배포된 버전의 명칭은 절대 바뀌지 않는다는 물리적 약속
  • Provenance: 아티팩트의 '출처'와 '제조 이력'을 담은 수치적 메타데이터
• How to Learn:
  • 사설 아티팩트 저장소를 구축하고, 빌드된 이미지를 푸시/풀($Push/Pull$) 하며 물리적 전송 속도 측정 실습
  • 동일한 버전 번호로 다른 파일이 업로드되는 상황을 서버 설정으로 차단하는 물리 방벽 구축 훈련
• Implement: 아티팩트의 해시값과 메타데이터를 검증하여 정품 여부를 가리는 ArtifactValidator

Advanced

Core: 빌드 가속 기술과 재현 가능성 (High-speed Engineering)

• Why to Learn: 빌드 시간이 1시간에서 5분으로 줄어들 때 개발팀의 물리적 창의성이 기하급수적으로 늘어나기 때문입니다.
• What to Learn:
  • Distributed Caching: 로컬이 아닌 공용 메모리에서 빌드 조각을 빌려오는 수리 전략
  • Remote Execution: 고성능 하드웨어팜에 빌드 연산을 물리적으로 위임하는 법
  • Deterministic Builds: 타임스탬프 등 환경 노이즈를 제거해 수리적 재현성 확보
• How to Learn:
  • 대규모 소스 코드를 대상으로 'Clean Build'와 'Cached Build'의 하드웨어 리소스 점유율 및 시간 데이터 산출 실습
  • 빌드 결과물에서 환경 변수(사용자 이름 등)를 물리적으로 소거하여 이진 파일의 동일성을 확보하는 기술 연구
• Implement: 빌드 성능 지표를 분석하여 가장 시간이 오래 걸리는 '병목 태스크'를 찾는 BuildProfiler

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Configuration Management / Software Building — Fabrication standards.
• [P5] SFIA v9 - Software Engineering / Methods and tools (Release and deployment management) — Logistics skills.

Secondary

• [Building and Testing with Bazel] — High-scale build physics.
• [The Art of Build Automation] — Tooling overview and best practices.

Industry

• [Google SRE: The Build System] — Reliability at scale.
• [OWASP: Software Component Analysis (SCA)] — Security within build systems.

9. Final Checklist

Primary

• '빌드 시스템'에서 '의존성 그래프'의 순환 참조가 물리적으로 빌드를 왜 불가능하게 만드는지 설명 가능한가? (P2)
• '아티팩트 버저닝'의 부재가 운영 환경의 하드웨어 형상 관리에 미치는 수리적 파괴를 기술할 수 있는 가? (P2)

Secondary

• '메이븐(Maven)'과 '그레이들(Gradle)'의 빌드 모델이 '선언(XML)'과 '실행(Groovy)' 측면에서 어떤 물리적 유연성 차이를 주는지 소통 가능한가?
• 불변 아티팩트 원칙을 깨고 배포된 서버에서 파일을 직접 수정했을 때, 동일성($Consistency$)이 무너지는 과정을 논증할 수 있는 가?

Industry

• 실무 파이프라인에서 '빌드 캐시'의 잔류 데이터로 인해 발생하는 '오염된 빌드'를 물리적으로 완벽히 세척하는 절차를 제안할 수 있는 가? (SFIA)
• Docker 멀티스테이지 빌드를 통해 아티팩트에서 '제조 도구'를 제거하고 최종 용량을 수치적으로 낮추는 수순을 분석할 수 있는 가?