Software Construction & Code Physics

1. Overview

소프트웨어 구축 및 코드 물리학(Software Construction & Code Physics, SCC)은 추상적 설계도를 하드웨어가 실행 가능한 수천, 수만 줄의 문장으로 정밀 조각하고, 그 문장들이 시간이 지나도 썩지 않게 물리적 탄성을 부여하는 '상세 설계 및 구현 공학'입니다.

학습자는 변수 이름 하나에서부터 대규모 클래스 구조까지 관통하는 **클린 코드(Clean Code)**의 수리적 수순과, 변경의 여파를 최소화하는 SOLID 원칙의 물리적 작용을 배웁니다. 특히, 코드의 복잡성을 수치화(Cyclomatic Complexity)하여 관리하고, 나쁜 냄새(Code Smell)를 제거하는 **리팩터링(Refactoring)**의 물리적 수순을 익힙니다. 이를 통해 단순히 "돌아가는 코드"가 아닌, 사람이 읽기 쉽고 하드웨어가 효율적으로 소화하는 하이엔드 소프트웨어 구축 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Coding Standard & Style: 명명 규칙(Naming), 레이아웃, 주석의 물리적 가독성 수순
• Design Principles: SOLID, DRY, KISS, YAGNI의 수리적 정합성 증명
• Construction Mechanics: 예외 처리(Exception), 방어적 프로그래밍의 물리적 방벽 설계
• Refactoring Techniques: 메서드 추출, 클래스 이동 등 물리적 구조 개선 수순
• Code Optimization Basics: 알고리즘 성능이 아닌 '코드 표현'의 하드웨어 친화성

Out-of-Scope

• 특정 프로그래밍 언어(Java, Python 등)의 고유한 문법 상세 (05-01-XX 영역에서 분담)
• 분산 시스템 간의 결합 아키텍처 상세 (09-01-03 Architecture 영역에서 분담)

Boundaries

• SCC vs. AL: 알고리즘(04-03-XX)이 '수학적 효율'에 집중한다면, SCC는 그 알고리즘을 감싸는 '코드의 구조적 가독성과 변화에 견디는 복원력(Maintainability)'이라는 물리적 품질에 집중하여 구분합니다.

3. Counterexample

• 단순히 "들여쓰기 잘하기"라 설명하는 것은 SCC 학습이 아닙니다. 왜 개방-폐쇄 원칙(OCP) 위반이 신규 기능을 추가할 때마다 기존 하드웨어 로직을 건드리게 만들어 전체 시스템의 '물리적 회귀 장애'를 유발하는지 증명할 수 있어야 하며, 순환 복잡도(Complexity) 수치가 10을 넘는 함수가 왜 인간의 단기 기억 용량($Short-term Memory$)을 초과하여 물리적 버그의 온상이 되는지 논증하지 못한다면 SCC의 정수를 이해하지 못한 것입니다.

4. Prerequisites

• Programming Languages Foundations (Basic): 05-01-XX의 기초 프로그래밍 문법 이해가 필수입니다.
• Data Structures & Algorithms (Recommended): 자료구조의 수리적 시간 복잡도 이해가 권장됩니다. (04-01-XX)

5. Learning Map

1. Microscopic Order: 변수와 함수라는 가장 작은 물리 단위에 명확한 의미와 질서를 부여합니다.
2. The Logic of Change: 코드가 바뀔 때 다른 곳이 무너지지 않게 만드는 물리적 완충(SOLID)을 배웁니다.
3. Smell Identification: 코드 속에 숨어 시스템을 좀먹는 '나쁜 냄새'를 수리적으로 감지합니다.
4. Permanent Polish: 매일 조금씩 코드를 닦고 조이는 리팩터링을 통해 영원히 썩지 않는 하이엔드 소프트웨어를 완성합니다.

6. Learning Topics

Basic

Core: 코드 가독성과 명명 규칙 (Coding Foundations)

• Why to Learn: 코드는 작성하는 시간보다 읽히는 시간이 수십 배 길기 때문에, 물리적인 해독 비용을 낮추기 위해서입니다.
• What to Learn:
  • Semantic Naming: 변수 역할이 2진수 덩어리가 아닌 수리적 의미로 읽히게 하는 법
  • Scope Minimization: 변수의 물리적 생존 범위를 최소화하여 두뇌 부하 감소
  • Function Sizing: '한 가지 일만 하는' 함수의 물리적 적정 길이($Lines$)
• How to Learn:
  • a, b, c로 이름 지어진 코드를 userBalance, orderCount 등으로 이름을 바꿔보며, 읽는 시간($Sec$)이 얼마나 단축되는지 측정 실습
  • 100줄이 넘는 가상의 함수를 10줄 이내의 함수 10개로 쪼개는 물리적 분할 수순 훈련
• Implement: 코드 텍스트를 분석하여 평균 단어 길이와 함수 길이를 수치화하는 CodeSanitizer

Recommended

Core: 객체 지향 설계의 5대 원칙 (SOLID Principles)

• Why to Learn: 요구사항이 바뀔 때마다 코드를 통째로 갈아엎는 물리적 재앙을 피하기 위함입니다.
• What to Learn:
  • Single Responsibility: 하나의 클래스가 하나의 '변경 이유'만 갖게 하는 수리 격리
  • Liskov Substitution: 하위 클래스가 상위의 물리적 명세를 깨뜨리지 않는 정합성
  • Dependency Inversion: 구체적인 하드웨어 구현이 아닌 추상적 약속(Interface)에 의존
• How to Learn:
  • SOLID 원칙이 무시된 '거대 클래스($God Object$)'의 데이터 흐름도를 그려보고, 변경 시 터져나오는 물리적 부작용 예측 실습
  • 인터페이스 주입($DI$)을 통해 모조 객체(Mock)를 끼워 넣으며 컴포넌트 간 물리적 절연 상태 검증
• Implement: 특정 코드가 SOLID 원칙을 얼마나 준수하는지 자가진단 항목 점수를 매기는 SOLIDScoreboard

Practical

Core: 방어적 프로그래밍과 오류 관리 (Defensive Construction)

• Why to Learn: 사용자의 잘못된 입력이나 하드웨어 장애 상황에서도 소프트웨어가 물리적으로 폭발(Crash)하지 않게 하기 위해서입니다.
• What to Learn:
  • Assertions: 실행 시점의 수리적 전제 조건(Pre-condition)을 명시적으로 체크
  • Exception Scoping: 오류를 가둘 수 있는 가장 작은 물리적 범위 설정 수순
  • Null Control: '존재하지 않는 값'이 시스템을 무너뜨리지 않게 하는 물리 방벽(Option, Null-safety)
• How to Learn:
  • 일부러 에러를 주입하고, 시스템이 '우아한 종료($Graceful Exit$)'를 하는지 파괴 실험 실습
  • 로그 메시지에 수리적 진단이 가능한 컨텍스트를 포함시키는 '추적성($Traceability$)' 강화 훈련
• Implement: 외부 API 호출 시 타임아웃과 재시도 횟수를 수리적으로 조절하는 ResilienceLogic

Advanced

Core: 리팩터링과 코드 복잡도 거버넌스 (Governance & Refactoring)

• Why to Learn: 쌓여가는 기술 부채를 정기적으로 상환하여 시스템의 물리적 임계치 도달을 늦추기 위함입니다.
• What to Learn:
  • Code Smells: 중복 코드, 긴 매개변수 목록 등 수리적 열화 신호의 식별
  • Refactoring Patterns: 결과의 물리적 변화 없이 구조만 개선하는 표준 수순
  • Complexity Metrics: 순환 복잡도, 유지보수성 지수 등 소프트웨어의 '건강 수치' 산출
• How to Learn:
  • 복잡한 중첩 Loop와 If문을 수리적으로 단순화하고, 단위 테스트가 여전히 'Pass'를 뱉는지 물리적 무결성 확인 실습
  • 정적 분석 도구(SonarQube 등)를 돌려 시스템 전체의 '기술 부채($Technical Debt$)' 환산 금액 산출 연구
• Implement: 특정 파일의 복잡도 변화량을 추적하여 리팩터링 시점을 알리는 ComplexGuard

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Construction — Construction standards.
• [P5] SFIA v9 - Software Engineering / Programming/software development — Implementation skills.

Secondary

• [Code Complete] Steve McConnell — The construction bible.
• [Clean Code] Robert C. Martin — The standard for readability.
• [Refactoring] Martin Fowler — Catalog of structural improvements.

Industry

• [Google Java/Python Style Guide] — Large scale consistency rules.
• [SonarQube: Code Quality and Security Guidelines] — Tooling standards.

9. Final Checklist

Primary

• '함수 한 가지 일 원칙'이 하드웨어 컨텍스트 스위칭 부하가 아닌 '인간의 인지 부하'를 어떻게 줄이는지 설명 가능한가? (P2)
• '의존성 역전 원칙(DIP)'을 통해 상위 정책의 물리적 로직이 하위 구현의 변화로부터 보호받는 과정을 기술할 수 있는 가? (P2)

Secondary

• '리팩터링' 과정에서 단위 테스트가 없는 상태로 구조를 건드렸을 때 나타나는 물리적 붕괴 리스크를 소통 가능한가?
• 방어적 프로그래밍이 과도해졌을 때 코드 본연의 논리적 흐름이 수리적으로 어떻게 오염되는지 논증할 수 있는 가?

Industry

• 사내 엔지니어링 표준 수립 시, '순환 복잡도' 임계치를 몇으로 설정해야 코드 리뷰 효율이 최적화되는지 제안할 수 있는 가? (SFIA)
• 'NullPointerException'을 근본적으로 차단하기 위한 현대적 언어의 물리적 안전 장치(예: Optional)의 활용 수순을 분석할 수 있는 가?