- 소프트웨어만의 특성으로 여겨지는 요구사항 변경과 불확실성, 반복 작업과 임시방편은 전통 공학에서도 흔하며 두 영역은 차이보다 공통점이 많음
- 전통 공학은 Waterfall, 소프트웨어는 Agile이라는 구분은 지나치게 단순함. 물리적 제작은 반복 비용이 커 사전 설계가 많지만 터널·토목·전자 분야도 점진적 개발과 현장 적응을 활용함
- 공급업체 폐업, 제조 장비 변화, 예상 밖의 토양 특성처럼 전통 공학 역시 계획을 뒤엎는 문제를 겪으므로 소프트웨어만 특별히 예측 불가능하다고 보기 어려움
- 실제 차이는 소프트웨어의 높은 일관성과 빠른 변경, 상대적으로 유연한 제약에 있음. 물리적 제품은 재료 편차와 마모, 강도·크기 같은 하드 제약, 되돌리기 어려운 변경을 감수해야 함
- 빠른 수정은 실험과 검증을 쉽게 만들지만 물리적 결함을 코드로 우회하도록 압박할 수도 있음. 각 공학 분야는 서로의 설계·검증·자동화 방식을 배울 수 있음
소프트웨어가 특별하다는 방어 논리
- 석유 저장층은 기름으로 가득 찬 풍선이 아니라 다공성 암석 구조이므로, 갑작스러운 압력 손실이 국소적인 빈 공간 때문인지 바다로 뚫린 것인지 판단하기 어려움
- 작은 빈 공간에 헤이즐넛 껍질을 주입해 서서히 메우고 압력을 평형화하며 구조 안에 있는지 시험함
- 노르웨이에서 석유 회사들이 헤이즐넛 껍질의 최대 구매자라는 사례는 전통 공학도 예상 밖의 재료와 현장 대응에 의존한다는 점을 보여줌
- 소프트웨어와 전통 공학을 비교할 때 면허나 엄격성의 차이로 소프트웨어를 공학보다 낮게 평가하는 한편, 소프트웨어를 일반적인 공학의 틀로 이해할 수 없는 특별한 분야로 만들기도 함
- 요구사항이 유난히 빠르게 변하므로 사전 계획과 공학적 방법을 적용하지 않아도 된다는 논리는 방어 기제로 작동함
- NoEstimates 운동은 전통 공학과 달리 소프트웨어 추정이 어렵다는 이유로 추정 자체를 없애려 함
- 하지만 소프트웨어에서 고통스럽다고 여기는 문제 대부분은 다른 공학 분야에도 있으며, 양쪽을 경험한 엔지니어들은 두 업무의 본질이 가깝다고 봄
흔히 거론되는 다섯 가지 차이
- 전통 공학 전체를 하나의 영역처럼 다루거나 토목공학과 동일시하면 각 하위 분야의 차이가 사라짐
- 소프트웨어와 전통 공학의 보편적인 차이로 흔히 꼽히는 항목은 다음과 같음
- 전통 공학은 Waterfall, 소프트웨어는 Agile에 적합함
- 전통 공학은 예측 가능하지만 소프트웨어는 예측하기 어려움
- 공학은 주로 제조이고 코드는 설계이므로 “코드가 곧 설계”임
- 전통 공학이 소프트웨어 공학보다 엄격함
- 소프트웨어가 전통 공학보다 훨씬 빠르게 움직임
- 일부에는 실제 차이가 있지만 대부분은 틀렸거나 판단에 필요한 핵심 맥락이 빠져 있음
Waterfall과 Agile이라는 단순 구분
- 널리 알려진 서사에 따르면 Winston Royce가 1970년 건축 공정을 본떠 Waterfall을 만들었고, 요구사항 변경에 취약한 이 방식은 2001년 Agile Manifesto로 대체됨
- 실제 Waterfall은 오늘날 인식만큼 엄격하거나 보편적이지 않았음
- 1970~1980년대 개발자들은 임시 계획이나 Spiral Model, V Model 같은 여러 점진적 모델을 사용함
- Agile은 단절적인 혁명보다 당시 흐름의 자연스러운 결과에 가까움
- 전통 공학이 더 많은 사전 설계와 별도의 시험 시간을 쓰는 것은 사실이지만, 이는 Waterfall의 경직성보다 반복 비용의 경제성에서 비롯됨
- 반복에 시간과 비용이 많이 들수록 한 번의 작업을 더 오래 계획하는 편이 합리적임
- 회로 기판이 처음부터 작동하지 않으면 공장에 다시 보내야 하며, 수천 파운드와 2주의 일정이 추가될 수 있음
- 설계와 구현의 경계도 명확하지 않음
- 토목 엔지니어의 축소 모형이나 자동차 엔지니어가 미학과 공기역학을 시험하려고 만드는 점토 실물 모형은 설계이면서 구현으로도 볼 수 있음
- 다른 산업에도 Agile과 유사한 방식이 존재함
- 오스트리아식 터널 공법은 반복 개발과 현장 즉흥 대응에 의존함
- Handbook of Industrial Engineering은 부서 간 협업과 빠른 고객 피드백을 강조함
- 토목공학도 시공이 시작되면 현장 문제를 처리하기 위해 개방적인 소통과 적응 중심으로 이동함
전통 공학도 예측하기 어렵다
- 완성된 교량이나 제품만 보면 그 과정에서 발생한 마찰과 비용 초과, 지연을 놓치기 쉬움
- 벽을 1인치 잘못 세우거나 핵심 공급업체가 폐업하는 사건만으로도 계획이 흔들릴 수 있음
- 소프트웨어는 1~2년마다 지배적인 프레임워크나 언어가 바뀌는 것처럼 보이지만, 전통 공학도 도구와 생산 환경의 변화를 겪음
- 반도체 파운드리가 새 제조 장비를 도입하면 칩 설계 계획도 바뀜
- 라이브러리만큼 빠르지는 않아도 변화가 없다는 뜻은 아님
- 공사 중 영유권이 바뀌거나, 검증된 절차가 갑자기 영구적으로 실패하거나, 개발 후반에 새로운 사실이 발견되는 일도 있음
- 교량 기초 공사를 시작한 뒤 특정 토양이 예상과 다르게 얼고 지진 때 과도하게 액상화한다는 사실을 발견하면 설계부터 다시 시작해야 함
- 소프트웨어만 특별히 예측 불가능하다는 생각은 다른 공학 분야의 실제 작업 과정을 보지 못한 데서 나옴
“코드가 곧 설계”라는 주장
- “코드가 곧 설계”는 UML로 완벽한 모델을 만든 뒤 코드를 자동 생성하면 된다는 생각에 대한 반작용이었음
- CPython 핵심 개발자이자 과거 Boeing 시스템 통합 엔지니어였던 Nick Coghlan은 이를 소프트웨어와 이전 업무의 근본적인 차이로 봄
- 항공기, 항공 교통 관제, 안테나 배열처럼 독립된 여러 시스템 팀이 호환 가능한 인터페이스를 만들도록 조율했음
- 반도체 엔지니어에게는 CPU의 첫 회로도부터 파운드리에서 나온 최종 칩까지 전 과정이 설계이며, 제조는 설계를 넘기고 칩을 받는 비교적 쉬운 단계일 수 있음
- 완성된 칩이나 기계 제품에 결함이 있으면 설계를 바꿔야 하므로 설계와 제작은 분리되지 않음
- 기계공학의 “fettling”은 제작 과정의 작은 불완전성에 맞춰 설계를 조정하는 작업임
- 제작이 설계를 바꾸고, 바뀐 설계가 다시 제작을 바꾸는 순환이 생김
- 설계의 범위 자체도 불명확함
- 아키텍처 개요, 정형 명세, 상세 도면은 모두 서로 다른 수준의 설계임
- 교량 설계도처럼 복잡한 프로젝트에는 여러 층위로 반복되는 세부 사항이 존재함
- 시공에 가장 많은 시간과 비용을 쓰는 특성은 교량·건물 중심의 일부 토목공학에 해당하며, 이를 모든 전통 공학의 대표 모습으로 일반화할 수 없음
- 토목공학도 도시 건설에 필요한 다양한 영역을 포함하므로 교량과 건물만으로 한정되지 않음
엄격성에 대한 오해
- 전통 공학은 제1원리부터 신중하게 추론하지만 소프트웨어는 복사·붙여넣기에 의존한다는 구분은 실제 작업을 반영하지 못함
- 소프트웨어의 상대적으로 낮아 보이는 엄격성은 문화만의 문제가 아니라, 구현과 시험이 쉬운 재료적 특성에 따른 합리적인 절충일 수 있음
- 가정을 확인하는 가장 쉬운 방법이 직접 구현해 실행하는 것인 경우가 많음
- 경험적 정보를 빠르게 수집하는 행위 자체도 엄격한 검증 방식임
- 전통 공학 제품이 소프트웨어보다 일관되고 체계적이라는 전제도 맞지 않음
- 소프트웨어는 기록 보존과 포괄적인 검증에서 오히려 앞선 경우가 있음
- 전통 공학의 핵심 정보가 Excel 파일이나 오래된 서류함에 저장돼 낡거나 손상되는 사례도 많음
- 소프트웨어에서 당연하게 여기는 자동화 테스트를 도입하고 싶어 하는 전통 공학 엔지니어도 많음
- 물리적 구조물에서도 필요하면 브래킷을 추가하는 식의 임시방편이 계속 사용됨
실제 차이 1: 일관성
- 소프트웨어는 논리로 완전히 합성되며 스프링처럼 마모되지 않기 때문에 다른 공학 결과물보다 훨씬 일관적임
- 정렬 함수가 비정상 입력이 아닌 숫자 목록을 95%만 정렬한다면 정상적인 동작으로 받아들이기 어려움
- 물리적 재료와 부품에는 이론값에서 벗어나는 편차가 기본적으로 존재함
- 저항기는 1Ω부터 수억 Ω까지 제공되며 색상 띠로 이론적인 저항값을 나타냄
- 녹색·파란색·빨간색 띠는 5,600Ω을 뜻하지만 금색 허용오차 띠가 있으면 실제 값은 최대 5% 달라질 수 있음
- 같은 저항기 100개 중 일부는 5,320Ω, 일부는 5,880Ω일 수 있어 각각 측정해야 함
- 마모와 온도 변화까지 고려하면 편차는 더 복잡해짐
- 모든 물리적 재료에는 비슷한 문제가 있으며, 나사 제조사 Fastenal도 스테인리스강 나사를 알루미늄 판에 사용하지 말라고 경고함
실제 차이 2: 변경 속도
- 소프트웨어는 다른 공학 시스템보다 훨씬 빠르게 변경할 수 있음
- 전통 공학에서는 명세를 공유한 뒤 공장이나 기계 작업장의 제작과 설치, 수주간의 시험을 기다려야 함
- 일부 엔지니어링 변경은 한 번마다 예산에서 5,000달러가 빠지는 식으로 비용이 명확함
- 코드는 변경한 뒤 전체 테스트를 수초 안에 실행할 수 있음
- 비소프트웨어 분야 가운데 화학공학이 가장 가까운 속도를 보였지만, 1분 단위의 전환도 상상하기 어려운 수준임
- 다른 공학 분야가 설계 도구와 시뮬레이션에 소프트웨어를 더 많이 사용하는 이유도 구현 전에 아이디어를 빠르게 시제품화할 수 있기 때문임
- 빠른 변경 능력에는 부정적인 측면도 있음
- 전자·기계 장치의 문제가 완전히 해결되지 않으면 소프트웨어 엔지니어에게 코드 우회책으로 보완하라는 압박이 집중됨
- 이러한 의존은 치명적인 결과로 이어질 수 있음
- 2019년 두 차례의 Boeing 737 MAX 추락 사고로 300명 넘게 사망함
- 조사에서는 자동 비행 제어 시스템인 MCAS의 버그를 원인으로 지목함
- Boeing은 뒤늦게 발견한 항공기의 공기역학적 특성 문제를 물리적 설계로 수정하는 대신 MCAS를 추가했음
실제 차이 3: 제약과 되돌릴 수 없는 변경
- 전통 공학 제품은 무게, 강도, 저항성, 온도처럼 반드시 지켜야 하는 물리적 한계를 가짐
- 칩 설계에서는 몇 분의 1나노초에 해당하는 시간 여유까지 다른 팀과 협상할 수 있음
- 소프트웨어에도 메모리 용량, 센서의 10사이클 응답, API 호출 제한 같은 제약이 있음
- 다만 소프트웨어 제약은 넘을수록 상태가 나빠지는 소프트 제약인 경우가 많아 개발 속도나 단순한 알고리듬을 위해 경계를 조금 조정할 수 있음
- 전통 공학의 제약은 넘으면 제품이 작동하지 않는 하드 제약인 경우가 많음
- 상자의 폭이 조금만 넓어도 문을 통과할 수 없음
- 석유 시추 시설에 설치할 스크루 컨베이어가 방보다 몇 인치 높았던 사례에서는 장비를 줄이거나 위의 네 층 때문에 천장을 높일 수 없었음
- 천장에 구멍을 내 장비를 넣고, 위층 사람이 걸려 넘어지지 않도록 구멍 주변에 상자를 설치함
- 이 변경은 시설 구조에 영구적으로 남아 이후 모든 변경에서 계속 고려해야 함
- 소프트웨어 엔지니어는 임시방편을 되돌릴 수 있지만 전통 공학의 물리적 임시방편은 영구적인 구조물이 되기 쉬움
다르지만 특별하지는 않다
- 소프트웨어에는 고유한 보안 문제가 있지만 토목공학에는 날씨, 화학공학에는 화학적 특성처럼 분야마다 별개의 난제가 있음
- 모든 공학 분야는 사전의 추상적 사고, 정돈된 작업, 적절한 임시방편을 중시하며 변화하는 요구사항과 알 수 없는 미지수를 마주함
- 각 분야는 서로 고립돼 있어 소프트웨어 엔지니어가 기계공학을 모르는 만큼 화학공학 엔지니어도 다른 공학의 실제 업무를 알기 어려움
- 소프트웨어가 특별하지 않기 때문에 다른 공학 분야에서 개선 방법을 배울 수 있고, 기록·검증·자동화처럼 전통 공학이 소프트웨어에서 배울 부분도 있음
- 후속 글 공학이 우리에게 가르칠 수 있는 것과 우리에게서 배울 수 있는 것은 양쪽이 교환할 수 있는 구체적인 교훈을 다룸