2025년에 읽는 소프트웨어 엔지니어링 책

인공지능 시대의 소프트웨어 공학

Jun 4. 2025

책만 출판사에서 보내 주셔서 <모던 소프트웨어 엔지니어링>을 읽던 중에 독후감을 쓰면서, 책을 둘러싼 지식과 관련 경험을 연재로 이어가고 싶었습니다. 연재를 시작하는 글로 먼저 저자 서문과 옮긴이의 말 중에서 밑줄 친 내용을 토대로 생각을 담습니다.

기술 이전에 사업 관리 역량 축적되던 시기를 돌아보다

저자의 서문(들어가며)에서 밑줄 친 내용입니다.

'소프트웨어 공학'을 정의하려는 과거의 시도는 특정 도구나 기술을 지나치게 규범적으로 정의하는 실수를 저질러 왔다. 소프트웨어 공학은 우리가 작성하는 코드와 우리가 사용하는 도구 그 이상이다. 소프트웨어 공학은 어떤 형태로든 생산 공학이 아니며, 생산 공학은 우리의 문제가 아니다. 내가 '공학'이라고 말할 때 관료주의가 떠오른다면 이 책을 읽고 다시 한번 생각해 보기 바란다.

경험에 의해 깊이 공감하는 내용입니다. 연상[1]되는 에피소드가 있습니다. '규범적으로'와 '관료주의'라는 표현이 찾아낸 경험에 대한 이야기입니다. 대기업 SI 회사들이 차세대 프로젝트를 주도하던 시절의 에피소드인데요. 첫 사건은 2004년 당시 3대 대기업 SI 회사 중 한 곳에서 제안서를 쓸 당시, 문서 이름에 복잡한 기호를 붙이고 커다란 엑셀 파일에서 주기적으로 전체 프로젝트 멤버가 진도를 기록하게 하는 방식을 두고 벌어진 다툼이었죠.

혈기왕성하고 배려심이 부족했던 저는 컨설팅 회사 소속이었는데, 컴소시움을 이끄는 대기업의 QA(품질 보증) 담당자의 '표준화 방안'을 PM 앞에서 공개적으로 비판했습니다. 결과적으로 사업 참여를 하지 않았던 기억이 있습니다. 지나고 보면 사업 책임자가 까다로운 일을 맡은 참모를 고집 있는 엔지니어가 강조하는 무언가보다 중요하게 여긴 것이죠.

대규모 프로젝트에서는 관리자가 '사업 관리'와 '위험 관리' 관점으로 일을 판단합니다. 쉽게 말해, 회사가 정해 준 마진(최소 이익)을 지켜야 하고, 불확실성을 최소화하려고 합니다. 당시 저는 경험 부족으로 그러한 역학을 이해하지 못했습니다. 다행스럽게 20년 넘게 업계를 떠나지 않고 애정을 갖고 보니 산업 발전을 역사적 시각으로 볼 수 있게 되었습니다.

비슷한 일이 2009년에도 있었습니다. 하지만, 이번에는 결과가 달랐죠. 어려운 문제를 푸는 와중에 또 QA 담당자가 시간을 잡아먹는 형식적 통일로 팀원들의 시간을 빼앗자 공개적으로 그를 비판했습니다. 그런데 이번에는 사업 책임자가 제 손을 들어주었습니다. 불필요한 형식적 통일로 시간 낭비하는 일이 사라졌습니다. 시간이 많이 흐른 일이라 기억도 부정확하고 두 사례만으로 비교하여 어떤 결론을 내리기는 어렵습니다. 다만, 5년의 시간 속에서 업계에서도 무엇이 중요하고, 무엇이 덜 중요한지에 대한 노하우가 쌓였다고 믿습니다.

생산 공학 혹은 제조 공학

한편, '생산 공학'이라는 말은 생소해서, 퍼플렉시티에 물었습니다.

Production Engineering은 전통적으로 제조업(공장 등)에서 제품 생산의 효율화, 자동화, 품질 관리 등을 다루는 공식 용어입니다.

『모던 소프트웨어 엔지니어링』에서는 아마도 소프트웨어 개발을 단순한 코딩이 아니라, 공학적 원칙과 프로세스를 적용해 '생산'하는 일련의 과정으로 바라보자는 의미에서 이 용어를 쓴 것으로 보입니다.

위키피디아에서는 Production Engineering 페이지는 없고 (포워딩을 통해) Manufacturing engineering 페이지로 갑니다.

제조 공학 또는 생산 공학은 기계, 화학, 전기, 산업 공학 등 다른 공학 분야와 많은 공통 개념과 아이디어를 공유하는 전문 공학 분야입니다. 제조 공학은 제조 과정을 계획하고, 도구, 공정, 기계 및 장비를 연구 및 개발하며, 최적의 자본 지출로 고품질 제품을 생산하기 위한 시설과 시스템을 통합할 수 있는 능력을 요구합니다.

생소한 개념이라 인용했지만, 저자는 소프트웨어 공학은 생산 공학은 아니라고 말하죠. 요즘은 소프트웨어도 제품Production이라고 부르는 일이 흔하지만, 물리적인 재료를 다루는 생산과 말과 생각을 재료로 다루는 생산은 너무나도 다르다 할 수 있습니다. 그래서, 저자는 이렇게 말하죠.

소프트웨어 공학 Software engineering은 소프트웨어의 현실적인 문제를 풀기 위한 효율적이고 경제적인 해법을 찾아 나서는 경험적이고 과학적인 접근 방식의 응용이다.

소프트웨어 공학을 경험적이고 과학적인 접근 방식의 응용이라고 말이죠. 다시 보니 마음에 쏙 드는 정의네요. 이어서 이렇게 말합니다.

이 책은 더 나은 소프트웨어를 안정적이고 반복적으로 만들기 위해 적용해야 하는 규율, 프로세스, 아이디어에 관한 책이다.

세 가지 핵심 아이디어를 말하는데, 그중 두 가지 역량을 굵은 폰트로 강조합니다.

학습의 전문가

복잡성을 관리하는 전문가

이어서 옮긴이의 말에서 밑줄 친 내용입니다.

이 책은 … 정적인 소프트웨어 공학 이론을 동적인 소프트웨어 공학 실천 방 안으로 뒤바꿔 놓는다. 테스트 가능성과 배포 관점에서 모듈성을 정리하며, DDD(설계 주도 개발)와 TDD (테스트 주도 개발) 관점에서 응집성과 관심사 분리에 의미를 부여하며, 조직적이고 문화적인 문제와 기술이나 설계 문제 사이의 트레이드오프를 고려해 정보 은닉과 추상화 수준을 선택하는 방안을 제시하고, 마이크로서비스 관점에서 결합도의 어려움을 관심사 분리와 연계해 생각할 거리를 제공한다.

옮긴이가 택한 '정적인'이라는 표현은 저자가 썼던 '규범적으로'와 '관료주의'라는 개념을 대하는 느낌을 표현한 것이 아닌가 싶습니다. 그리고, 저자가 소프트웨어 공학적인 관점에서 글을 쓴 반면 옮긴이는 실무 현장 개발자가 익숙한 단어들을 뽑습니다. 옮긴이의 경험이나 사고의 바탕이 느껴지는 듯합니다.