# 우리는 특별하지 않다 (2021) > Clean Markdown view of GeekNews topic #31843. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31843](https://news.hada.io/topic?id=31843) - GeekNews Markdown: [https://news.hada.io/topic/31843.md](https://news.hada.io/topic/31843.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-27T08:03:03+09:00 - Updated: 2026-07-27T08:03:03+09:00 - Original source: [hillelwayne.com](https://www.hillelwayne.com/post/we-are-not-special/) - Points: 1 - Comments: 1 ## Topic Body - 소프트웨어만의 특성으로 여겨지는 **요구사항 변경과 불확실성**, 반복 작업과 임시방편은 전통 공학에서도 흔하며 두 영역은 차이보다 공통점이 많음 - 전통 공학은 Waterfall, 소프트웨어는 Agile이라는 구분은 지나치게 단순함. 물리적 제작은 반복 비용이 커 사전 설계가 많지만 터널·토목·전자 분야도 **점진적 개발과 현장 적응**을 활용함 - 공급업체 폐업, 제조 장비 변화, 예상 밖의 토양 특성처럼 전통 공학 역시 계획을 뒤엎는 문제를 겪으므로 소프트웨어만 특별히 **예측 불가능하다**고 보기 어려움 - 실제 차이는 소프트웨어의 **높은 일관성과 빠른 변경**, 상대적으로 유연한 제약에 있음. 물리적 제품은 재료 편차와 마모, 강도·크기 같은 하드 제약, 되돌리기 어려운 변경을 감수해야 함 - 빠른 수정은 실험과 검증을 쉽게 만들지만 물리적 결함을 **코드로 우회**하도록 압박할 수도 있음. 각 공학 분야는 서로의 설계·검증·자동화 방식을 배울 수 있음 --- ### 소프트웨어가 특별하다는 방어 논리 - 석유 저장층은 기름으로 가득 찬 풍선이 아니라 **다공성 암석 구조**이므로, 갑작스러운 압력 손실이 국소적인 빈 공간 때문인지 바다로 뚫린 것인지 판단하기 어려움 - 작은 빈 공간에 헤이즐넛 껍질을 주입해 서서히 메우고 압력을 평형화하며 구조 안에 있는지 시험함 - 노르웨이에서 석유 회사들이 헤이즐넛 껍질의 최대 구매자라는 사례는 전통 공학도 예상 밖의 재료와 현장 대응에 의존한다는 점을 보여줌 - 소프트웨어와 전통 공학을 비교할 때 면허나 엄격성의 차이로 소프트웨어를 공학보다 낮게 평가하는 한편, 소프트웨어를 일반적인 공학의 틀로 이해할 수 없는 **특별한 분야**로 만들기도 함 - 요구사항이 유난히 빠르게 변하므로 사전 계획과 공학적 방법을 적용하지 않아도 된다는 논리는 방어 기제로 작동함 - [NoEstimates 운동](https://techbeacon.com/app-dev-testing/noestimates-debate-unbiased-look-origins-arguments-thought-leaders-behind-movement)은 전통 공학과 달리 소프트웨어 추정이 어렵다는 이유로 추정 자체를 없애려 함 - 하지만 소프트웨어에서 고통스럽다고 여기는 문제 대부분은 다른 공학 분야에도 있으며, 양쪽을 경험한 엔지니어들은 두 업무의 본질이 가깝다고 봄 ### 흔히 거론되는 다섯 가지 차이 - 전통 공학 전체를 하나의 영역처럼 다루거나 **토목공학과 동일시**하면 각 하위 분야의 차이가 사라짐 - 소프트웨어와 전통 공학의 보편적인 차이로 흔히 꼽히는 항목은 다음과 같음 - 전통 공학은 Waterfall, 소프트웨어는 Agile에 적합함 - 전통 공학은 예측 가능하지만 소프트웨어는 예측하기 어려움 - 공학은 주로 제조이고 코드는 설계이므로 “코드가 곧 설계”임 - 전통 공학이 소프트웨어 공학보다 엄격함 - 소프트웨어가 전통 공학보다 훨씬 빠르게 움직임 - 일부에는 실제 차이가 있지만 대부분은 틀렸거나 판단에 필요한 **핵심 맥락이 빠져 있음** ### Waterfall과 Agile이라는 단순 구분 - 널리 알려진 서사에 따르면 Winston Royce가 1970년 건축 공정을 본떠 Waterfall을 만들었고, 요구사항 변경에 취약한 이 방식은 2001년 [Agile Manifesto](https://agilemanifesto.org/)로 대체됨 - 실제 Waterfall은 오늘날 인식만큼 엄격하거나 보편적이지 않았음 - 1970~1980년대 개발자들은 임시 계획이나 [Spiral Model](https://en.wikipedia.org/wiki/Spiral_model), [V Model](https://en.wikipedia.org/wiki/V-Model) 같은 여러 **점진적 모델**을 사용함 - Agile은 단절적인 혁명보다 당시 흐름의 자연스러운 결과에 가까움 - 전통 공학이 더 많은 사전 설계와 별도의 시험 시간을 쓰는 것은 사실이지만, 이는 Waterfall의 경직성보다 **반복 비용의 경제성**에서 비롯됨 - 반복에 시간과 비용이 많이 들수록 한 번의 작업을 더 오래 계획하는 편이 합리적임 - 회로 기판이 처음부터 작동하지 않으면 공장에 다시 보내야 하며, 수천 파운드와 2주의 일정이 추가될 수 있음 - 설계와 구현의 경계도 명확하지 않음 - 토목 엔지니어의 축소 모형이나 자동차 엔지니어가 미학과 공기역학을 시험하려고 만드는 [점토 실물 모형](http://www.bbc.com/autos/story/20161111-why-car-designers-stick-with-clay)은 설계이면서 구현으로도 볼 수 있음 - 다른 산업에도 Agile과 유사한 방식이 존재함 - [오스트리아식 터널 공법](https://tunnelingonline.com/understanding-the-new-austrian-tunnel-method-natm/)은 반복 개발과 현장 즉흥 대응에 의존함 - *Handbook of Industrial Engineering*은 부서 간 협업과 빠른 고객 피드백을 강조함 - 토목공학도 시공이 시작되면 현장 문제를 처리하기 위해 개방적인 소통과 적응 중심으로 이동함 ### 전통 공학도 예측하기 어렵다 - 완성된 교량이나 제품만 보면 그 과정에서 발생한 마찰과 비용 초과, 지연을 놓치기 쉬움 - 벽을 1인치 잘못 세우거나 핵심 공급업체가 폐업하는 사건만으로도 계획이 흔들릴 수 있음 - 소프트웨어는 1~2년마다 지배적인 프레임워크나 언어가 바뀌는 것처럼 보이지만, 전통 공학도 **도구와 생산 환경의 변화**를 겪음 - 반도체 파운드리가 새 제조 장비를 도입하면 칩 설계 계획도 바뀜 - 라이브러리만큼 빠르지는 않아도 변화가 없다는 뜻은 아님 - 공사 중 영유권이 바뀌거나, 검증된 절차가 갑자기 영구적으로 실패하거나, 개발 후반에 새로운 사실이 발견되는 일도 있음 - 교량 기초 공사를 시작한 뒤 특정 토양이 예상과 다르게 얼고 지진 때 과도하게 액상화한다는 사실을 발견하면 **설계부터 다시 시작**해야 함 - 소프트웨어만 특별히 예측 불가능하다는 생각은 다른 공학 분야의 실제 작업 과정을 보지 못한 데서 나옴 ### “코드가 곧 설계”라는 주장 - “코드가 곧 설계”는 UML로 완벽한 모델을 만든 뒤 코드를 자동 생성하면 된다는 생각에 대한 반작용이었음 - CPython 핵심 개발자이자 과거 Boeing 시스템 통합 엔지니어였던 Nick Coghlan은 이를 소프트웨어와 이전 업무의 근본적인 차이로 봄 - 항공기, 항공 교통 관제, 안테나 배열처럼 독립된 여러 시스템 팀이 **호환 가능한 인터페이스**를 만들도록 조율했음 - 반도체 엔지니어에게는 CPU의 첫 회로도부터 파운드리에서 나온 최종 칩까지 전 과정이 설계이며, 제조는 설계를 넘기고 칩을 받는 비교적 쉬운 단계일 수 있음 - 완성된 칩이나 기계 제품에 결함이 있으면 설계를 바꿔야 하므로 설계와 제작은 분리되지 않음 - 기계공학의 “fettling”은 제작 과정의 작은 불완전성에 맞춰 설계를 조정하는 작업임 - 제작이 설계를 바꾸고, 바뀐 설계가 다시 제작을 바꾸는 순환이 생김 - **설계의 범위** 자체도 불명확함 - 아키텍처 개요, 정형 명세, 상세 도면은 모두 서로 다른 수준의 설계임 - [교량 설계도](https://www.dot.state.mn.us/bridge/pdf/abc/br-62646-plan.pdf)처럼 복잡한 프로젝트에는 여러 층위로 반복되는 세부 사항이 존재함 - 시공에 가장 많은 시간과 비용을 쓰는 특성은 교량·건물 중심의 일부 토목공학에 해당하며, 이를 모든 전통 공학의 대표 모습으로 일반화할 수 없음 - 토목공학도 도시 건설에 필요한 다양한 영역을 포함하므로 교량과 건물만으로 한정되지 않음 ### 엄격성에 대한 오해 - 전통 공학은 제1원리부터 신중하게 추론하지만 소프트웨어는 복사·붙여넣기에 의존한다는 구분은 실제 작업을 반영하지 못함 - 소프트웨어의 상대적으로 낮아 보이는 엄격성은 문화만의 문제가 아니라, 구현과 시험이 쉬운 재료적 특성에 따른 **합리적인 절충**일 수 있음 - 가정을 확인하는 가장 쉬운 방법이 직접 구현해 실행하는 것인 경우가 많음 - 경험적 정보를 빠르게 수집하는 행위 자체도 엄격한 검증 방식임 - 전통 공학 제품이 소프트웨어보다 일관되고 체계적이라는 전제도 맞지 않음 - 소프트웨어는 기록 보존과 포괄적인 검증에서 오히려 앞선 경우가 있음 - 전통 공학의 핵심 정보가 Excel 파일이나 오래된 서류함에 저장돼 낡거나 손상되는 사례도 많음 - 소프트웨어에서 당연하게 여기는 **자동화 테스트**를 도입하고 싶어 하는 전통 공학 엔지니어도 많음 - 물리적 구조물에서도 필요하면 브래킷을 추가하는 식의 임시방편이 계속 사용됨 ### 실제 차이 1: 일관성 - 소프트웨어는 논리로 완전히 합성되며 스프링처럼 마모되지 않기 때문에 다른 공학 결과물보다 훨씬 **일관적**임 - 정렬 함수가 비정상 입력이 아닌 숫자 목록을 95%만 정렬한다면 정상적인 동작으로 받아들이기 어려움 - 물리적 재료와 부품에는 이론값에서 벗어나는 편차가 기본적으로 존재함 - 저항기는 1Ω부터 수억 Ω까지 제공되며 색상 띠로 이론적인 저항값을 나타냄 - 녹색·파란색·빨간색 띠는 5,600Ω을 뜻하지만 금색 허용오차 띠가 있으면 실제 값은 최대 5% 달라질 수 있음 - 같은 저항기 100개 중 일부는 5,320Ω, 일부는 5,880Ω일 수 있어 각각 측정해야 함 - 마모와 온도 변화까지 고려하면 편차는 더 복잡해짐 - 모든 물리적 재료에는 비슷한 문제가 있으며, 나사 제조사 Fastenal도 [스테인리스강 나사를 알루미늄 판에 사용하지 말라](https://www.fastenal.com/en/70/corrosion)고 경고함 ### 실제 차이 2: 변경 속도 - 소프트웨어는 다른 공학 시스템보다 훨씬 빠르게 변경할 수 있음 - 전통 공학에서는 명세를 공유한 뒤 공장이나 기계 작업장의 제작과 설치, 수주간의 시험을 기다려야 함 - 일부 엔지니어링 변경은 한 번마다 예산에서 **5,000달러**가 빠지는 식으로 비용이 명확함 - 코드는 변경한 뒤 전체 테스트를 수초 안에 실행할 수 있음 - 비소프트웨어 분야 가운데 화학공학이 가장 가까운 속도를 보였지만, 1분 단위의 전환도 상상하기 어려운 수준임 - 다른 공학 분야가 설계 도구와 시뮬레이션에 소프트웨어를 더 많이 사용하는 이유도 구현 전에 아이디어를 빠르게 시제품화할 수 있기 때문임 - 빠른 변경 능력에는 부정적인 측면도 있음 - 전자·기계 장치의 문제가 완전히 해결되지 않으면 소프트웨어 엔지니어에게 **코드 우회책**으로 보완하라는 압박이 집중됨 - 이러한 의존은 치명적인 결과로 이어질 수 있음 - 2019년 두 차례의 Boeing 737 MAX 추락 사고로 300명 넘게 사망함 - 조사에서는 자동 비행 제어 시스템인 **MCAS**의 버그를 원인으로 지목함 - Boeing은 뒤늦게 발견한 항공기의 [공기역학적 특성 문제](https://leehamnews.com/2018/11/14/boeings-automatic-trim-for-the-737-max-was-not-disclosed-to-the-pilots/)를 물리적 설계로 수정하는 대신 MCAS를 추가했음 ### 실제 차이 3: 제약과 되돌릴 수 없는 변경 - 전통 공학 제품은 무게, 강도, 저항성, 온도처럼 반드시 지켜야 하는 **물리적 한계**를 가짐 - 칩 설계에서는 몇 분의 1나노초에 해당하는 시간 여유까지 다른 팀과 협상할 수 있음 - 소프트웨어에도 메모리 용량, 센서의 10사이클 응답, API 호출 제한 같은 제약이 있음 - 다만 소프트웨어 제약은 넘을수록 상태가 나빠지는 소프트 제약인 경우가 많아 개발 속도나 단순한 알고리듬을 위해 경계를 조금 조정할 수 있음 - 전통 공학의 제약은 넘으면 제품이 작동하지 않는 **하드 제약**인 경우가 많음 - 상자의 폭이 조금만 넓어도 문을 통과할 수 없음 - 석유 시추 시설에 설치할 스크루 컨베이어가 방보다 몇 인치 높았던 사례에서는 장비를 줄이거나 위의 네 층 때문에 천장을 높일 수 없었음 - 천장에 구멍을 내 장비를 넣고, 위층 사람이 걸려 넘어지지 않도록 구멍 주변에 상자를 설치함 - 이 변경은 시설 구조에 영구적으로 남아 이후 모든 변경에서 계속 고려해야 함 - 소프트웨어 엔지니어는 임시방편을 되돌릴 수 있지만 전통 공학의 물리적 임시방편은 **영구적인 구조물**이 되기 쉬움 ### 다르지만 특별하지는 않다 - 소프트웨어에는 고유한 보안 문제가 있지만 토목공학에는 날씨, 화학공학에는 화학적 특성처럼 분야마다 별개의 난제가 있음 - 모든 공학 분야는 사전의 추상적 사고, 정돈된 작업, 적절한 임시방편을 중시하며 **변화하는 요구사항과 알 수 없는 미지수**를 마주함 - 각 분야는 서로 고립돼 있어 소프트웨어 엔지니어가 기계공학을 모르는 만큼 화학공학 엔지니어도 다른 공학의 실제 업무를 알기 어려움 - 소프트웨어가 특별하지 않기 때문에 다른 공학 분야에서 개선 방법을 배울 수 있고, 기록·검증·자동화처럼 전통 공학이 소프트웨어에서 배울 부분도 있음 - 후속 글 [공학이 우리에게 가르칠 수 있는 것과 우리에게서 배울 수 있는 것](https://www.hillelwayne.com/post/what-we-can-learn/)은 양쪽이 교환할 수 있는 구체적인 교훈을 다룸 ## Comments ### Comment 62431 - Author: neo - Created: 2026-07-27T08:03:04+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/zfvln5/we_are_not_special_2021) - 글의 많은 부분에는 동의하지만, 소프트웨어 공학의 **엄밀성**을 지나치게 낙관하고 있음. 지금도 자동화 테스트, 특히 여러 계층의 견고한 테스트가 개발 절차에 포함되는 것은 당연하지 않으며, 개발자 자신만을 유일한 검문소로 여기거나 조직이 절차를 장애물로 취급해 없애기도 함 업계는 검증된 모범 사례를 체계화하지 않은 채 몇 년마다 바퀴를 재발명함. 표준화된 것도 대개 회사마다 의미가 크게 다른 느슨한 공통 어휘에 불과하며, ‘애자일’이나 ‘테스트’가 대표적임. 많은 개발자는 테스트를 단위 테스트 정도로만 생각하고, 일부는 컴포넌트·통합 테스트까지 포함하지만 어떤 회사에서는 그것만 거친 채 운영 환경에 배포함 이전에 쓴 [댓글](https://lobste.rs/s/hb1s2k/reviewing_code_requires_reading#c_1bafex)처럼, 건강한 조직에서 코드 리뷰는 품질을 책임지는 여러 절차 중 하나여야 하며 운영 배포를 결정하는 단일 관문이어서는 안 됨. 코드 병합 이후의 품질 보증 절차가 사실상 사라진 팀과 회사가 많음 책임을 희석하자는 게 아니라 코드 작성 전부터 **품질을 절차에 내재화**해야 함. 여러 직군이 명세와 요구사항을 논의하는 Three Amigos 세션, 테스트 주도 개발, IDE와 각 검문 단계에 통합된 정적 분석, 개발자와 별개의 품질 보증·테스트 자동화 전문가 등이 필요함 토목 공학에서는 한 사람이 교량의 설계자이자 시공자이자 유일한 책임자가 되지 않음. 계산과 문서 작성, 재검산, 정부 승인, 시공 중 감사와 검사 등 여러 단계가 있고 단독주택도 도면·승인·허가·검사를 거침. 공학적 재난 역시 여러 단계에서 막지 못한 전체 절차의 실패인 경우가 많음 소프트웨어 개발을 토목 공학과 비교하려면 절차 수준이 전혀 같지 않다는 사실도 인정해야 함. 기껏해야 법적 요구사항을 우회하며 가장 싼 집을 짓는 주택 개발업자에 가까운 경우가 많음 - 실제 공학 분야에서도 테스트가 생각보다 훨씬 적게 이뤄지며, **통합 지옥**도 몹시 고통스러움 - 소프트웨어 업계가 품질을 더 중시하면 좋겠지만, 두 분야는 **실패 비용**부터 다름. 교량 계산을 잘못하면 사람이 죽을 수 있고 새 교량을 짓지 않고는 고치기 어려운 반면, 소프트웨어 결함은 예외적으로 인명 피해를 낼 수 있어도 대체로 수정 가능함 따라서 MRI 제어 소프트웨어 같은 분야가 아닌 일반 소프트웨어에서는 테스트·검증 비용과 그 효과 사이의 절충점이 토목 공학과 달라질 수밖에 없음 - 세 편 모두 훌륭하니 읽어보길 권함. 과거 토론도 함께 볼 수 있음 https://lobste.rs/s/fv8swh/crossover_project (프로젝트 발표) https://lobste.rs/s/lmvroa/are_we_really_engineers (재토론) https://lobste.rs/s/8j8sdc/are_we_really_engineers (또 다른 재토론) Glenn Vanderburg의 [이 강연](https://lobste.rs/s/xt6z3h/real_software_engineering)도 매우 관련 깊음 - 소프트웨어 개발과 전통 공학의 가장 큰 차이는 **변경에 따르는 마찰**임. 소프트웨어는 상대적으로 저렴하게 변경할 수 있고 유연해서 완전히 새로운 가능성이 열림 전통 공학도 시뮬레이션을 더 많이 만들수록 물리·화학적 한계 안에서 소프트웨어와 비슷하게 변경 가능성을 넓힐 수 있음 “정렬 함수라면 비병리적인 숫자 목록을 95% 확률로만 정렬하리라고 예상하지 않는다”는 말도 이제 **LLM 생성 코드**에는 실제로 들어맞음. 대부분 작동하지만 항상 작동하지는 않음 - ~hwayne은 왜 계정을 비활성화했는지 궁금함 - Bluesky의 [게시물](https://bsky.app/profile/hillelwayne.com/post/3mojo5wf22c2g)과 [며칠 전 재확인](https://bsky.app/profile/hillelwayne.com/post/3mr63j4rink2g)에 따르면 **소셜 미디어로 인한 정신 건강 휴식** 때문임