Chapter 1

소프트웨어 공학의 정의와 철학

  • 1.1 공학이란 과학의 실용적인 응용 분야
  • 1.2 소프트웨어 공학 정의의 재구성
  • 1.3 다시 '소프트웨어 공학'
  • 1.4 소프트웨어 공학의 탄생
  • 1.5 패러다임의 전환
  • 1.6 프로덕션은 우리의 문제가 아니다
  • 1.7 프로덕션이 아닌 설계를 위한 공학
  • 1.8 실무자를 위한 공학의 정의
  • 1.9 수공예 vs 공학
  • 1.10 '수공예'의 한계
  • 1.11 정밀도와 확장성
  • 1.12 복잡성을 관리하자
  • 1.13 측정은 반복적이며 정확해야 한다
  • 1.14 공학 창의성 장인정신
  • 1.15 우리가 하는 일이 소프트웨어 공학이 아닌 이유
  • 1.16 소프트웨어 제작의 트레이드오프: 결합도가 핵심이다
  • 1.17 기술 발전의 진보라는 환상
  • 1.18 수공예에서 공학으로 가는 여정
  • 1.19 수공예만으로 충분하지 않다
  • 1.20 지금 우리가 고민해야 할 것들은 무엇일까

우리가 하는 일은 정말 공학일까? Farley는 소프트웨어 공학의 정의부터 다시 세우고, 장인정신만으로는 부족한 이유를 파고들어.

1968년 NATO 컨퍼런스에서 소프트웨어 공학이라는 말이 처음 나왔을 때, 사람들이 떠올린 건 제조업이었어. 미리 설계하고, 계획하고, 순서대로 만드는 것. 워터폴의 탄생 배경이지. 근데 소프트웨어는 제조가 아니잖아. 다리는 물리 법칙이 확실하고 요구사항이 명확한데, 우리는 요구사항이 매주 바뀌고 "완성"이라는 개념 자체가 없어.

그래서 Farley가 제안하는 정의는 이거야 — "탐색과 발견을 통해 학습하는 과정에 과학적 사고를 적용하는 것". 핵심은 학습이라는 단어야. 우리는 문제를 완전히 이해하지 못한 채 시작해서, 만들면서 배워나가잖아. 이 과정을 체계적으로 만들려면 가설을 세우고, 실험하고, 측정하고, 배우는 과학적 방법이 필요해.

실제로 Continuous Delivery, Lean, XP 같은 실천법이 효과적이라는 건 DORA 연구에서 데이터로 증명됐어. 반면 "빅 뱅 릴리스 + 상세 설계 문서 + 승인 프로세스"가 효과적이라는 증거는 없고, 오히려 반대 증거만 쌓여있지.

"예측하고 계획하는" 방식에서 "탐색하고 적응하는" 방식으로의 전환. 이건 단순히 "애자일 하자"는 얘기가 아니야. 어떤 방법론이든 "왜 이게 효과적인가"를 증거로 설명할 수 있어야 해. 그게 진짜 공학이야.

그렇다면 "깨끗한 코드를 짜는 장인"이 되면 충분할까? 장인정신은 필요 조건이지, 충분 조건이 아니야. 소프트웨어 업계에 소프트웨어 장인정신(Software Craftsmanship) 운동이 있었어. 깨끗한 코드, 테스트, 지속적인 학습. 좋은 의도였지. 근데 수공예의 근본적인 문제가 있어 — 확장이 안 된다는 거야. 팀의 "수석 장인"이 모든 코드 리뷰를 하고 아키텍처를 결정하는 구조는 결국 병목이 돼. 도제식 전수로 "우리 팀은 원래 이렇게 해"를 물려주지만, "왜 이렇게 하는지"는 전달이 안 되면 그건 전통이지 공학이 아니야.

여기서 핵심적인 통찰이 하나 있어. 소프트웨어의 본질은 **프로덕션(생산)**이 아니라 **설계(Design)**라는 거야. 제조업에서는 자동차를 수만 대 찍어내는 데 비용이 들지만, 소프트웨어에서 코드를 복사하는 비용은 거의 0이잖아. git clone 하면 끝이야. 그런데도 많은 방법론이 제조업의 프로덕션 최적화 모델을 그대로 가져다 쓰고 있어. 이게 근본적인 착오야. 소프트웨어 공학은 설계를 더 잘하기 위한 공학이어야 해.

수공예에서 공학으로 넘어가려면 개인의 역량에만 의존하지 않는 시스템과 프로세스가 필요해. 누가 하더라도 일정 수준 이상의 결과를 보장할 수 있는 체계를 만드는 거야. 자동화된 테스트, CI/CD 파이프라인, 명확한 추상화, 잘 정의된 인터페이스 — 이런 것들이 소프트웨어 공학의 "정밀한 도구"에 해당해. 모차르트가 소나타 형식이라는 엄격한 구조 안에서 걸작을 만든 것처럼, 이런 구조가 오히려 창의성을 촉진하지. "아무렇게나 해도 돼"는 자유가 아니라 혼돈이거든.

그리고 이 모든 것의 중심에 있는 트레이드오프가 하나 있어 — **결합도(Coupling)**야. 모듈 간 결합도가 높으면 변경의 파급 효과가 커지고, 시스템을 이해하기 어려워져. 좋은 추상화, 깨끗한 인터페이스, 정보 은닉 — 이 기법들의 목적은 결국 결합도를 낮추는 거야. 소프트웨어에서 생산성과 품질의 저하는 대부분 복잡성 관리 실패, 그리고 그 뿌리에 있는 결합도 관리 실패에서 와.

냉정하게 말하면, 지금 대부분의 소프트웨어 개발은 공학이 아니야. 증거 없이 결정하고, 실험하지 않고, 측정하지 않잖아. 새 프레임워크가 나오면 "이번엔 다르다"고 하지만, 도구가 바뀐다고 복잡성 관리, 결합도 관리, 피드백 루프 최적화라는 본질적 문제가 사라지는 건 아니야. 이건 희망적 사고에 가까운 거지, 공학이 아니야. Farley가 이 책의 나머지에서 풀어갈 답은 — 반복, 피드백, 점진주의, 경험주의, 실험주의라는 다섯 가지 원칙이야.

정리

1장 읽고 기억할 거 세 가지:

  1. 소프트웨어 공학은 학습 과정이야. 제조가 아니라 설계에 가까운 일을 하면서, "탐색과 발견을 통해 배우는 과정에 과학적 사고를 적용하는 것"이 진짜 공학이야.
  2. 수공예(장인정신)만으로는 부족하다. 개인의 역량에 의존하는 방식은 확장이 안 돼. 자동화된 테스트, CI/CD, 명확한 추상화 같은 시스템적 접근이 있어야 공학이야.
  3. 복잡성 관리의 핵심은 결합도다. 프레임워크는 바뀌어도 결합도 관리, 피드백 루프 최적화라는 본질적 문제는 변하지 않아.