14. 소프트웨어 공학의 특성
소프트웨어 개발의 3가지 메타포 중 하나인 공학에 대해서
소프트웨어 개발을 얘기할 때 언급되는 메타포들이 있다.
장인정신(craftmanship), 정원 가꾸기(gardening), 그리고 오늘 이야기할 공학(engineerin g)이 있다.
장인정신
내가 이해하고 있는 장인정신 메타포는 지식과 학습 외에 경험을 통한 배움과 숙련(연습)이 필요하다는 것이다. 즉, 실무에서 가치로 기여하며 동료들과 서로 배움을 주고받아야 하는 측면에 대한 것이라고 생각한다.
Emily Bache가 "How SOLID & TDD Paved the Way to Success at Ferrari"에서 언급한 내용 중에 어려운 기술을 도입한 것에 대한 내용이 있다. 팀이 Scala를 도입하기 위해 팀 전체가 Scala 교육을 받고, 돌아와서 이미 Scala를 할 줄 아는 동료들의 도움을 받아 업무에 성공적으로 적용한 것에 반해 OOP, SOLID 등은 교육을 받고 업무에 적용하는데 어려움이 있었다고 한다. 하지만 개발 코치들과 함께 업무에 적용하다 보니 익숙해졌다는 것이다. 즉 지식만으로 안되고 함께 일하면서만 경험하고, 배울 수 있는 것들이 있다는 것이다. 이런 것들이 장인정신이라고 생각한다.
정원 가꾸기
소프트웨어를 지속적으로 성장하고 변화하는 유기체로 보는 관점이다. 소프트웨어는 정원의 식물들처럼 지속적으로 관심으로 가지고 가꿔줘야 한다는 것이다. 구현하여 동작하도록 만든 후에도 지속적으로 개선해야 한다는 의견이다.
공학의 속성
공학 메타포는 건축에서 영향을 많이 받았다고 생각한다. 개발자들이 많이 사용하는 용어들 - 설계, 아키텍처, 아키텍트 등 - 은 건축에서 왔다.
공학의 일반적 특성
공학은 설계(Design)와 빌드(Build)로 이뤄진다.
공학에서 설계는 일반적으로 예측하고 어렵고, 급여가 비싸고 창의적인 인력들을 필요로 한다.
이에 반해 빌드는 조금 더 예측하기 쉽고, 상대적으로 비용이 적게 드는 인력들을 필요로 한다.
건축 등의 물리적인 산출물을 목표로 하는 공학에서는
설계와 빌드가 분리된다.
설계를 하는 인력은 설계만 하고, 빌드를 하는 인력은 설계를 하지 않는다. 건축가는 벽돌을 쌓거나 못을 박지 않는 것처럼 말이다.
물리적 산출물을 목표로 하는 공학에서는
빌드 비용이 비싸다.
조사에 의하면 공학의 경우 설계 비용은 전체 비용에 10%에 불가하고 빌드 비용이 전체 비용의 90%를 차지한다고 한다. 대규모 아파트를 건설하는 것을 생각해 보면 설계 비용보다는 빌드 비용이 엄청 많이 들 것 같다.
마지막으로 살펴볼 공학의 특성은 산출물에 대한 것이다.
공학의 산출물은 빌드할 수 있는 재생산 가능한(Reproducible) 문서화이다.
공학자들은 재생산 가능한 문서인 설계도를 만든다. 설계도만 동일하다면 누구 빌드를 하든지 거의 유사한 결과물이 만들어진다.
소프트웨어 공학의 특성
위에서 물리적 산출물(건물 등)을 목표로 하는 공학의 일반적인 특성을 살펴봤다.
그럼 위에서 살펴본 속성들이 소프트웨어 공학에서는 어떻게 다른지 알아보겠다.
소프트웨어의 공학의 설계와 빌드 비용
빌드 비용은 거의 공짜이다.
"What is Software Design?" , C++ Journal, 1992에서 Jack W. Reeves는
SW 설계가 비교적 쉽게 만들어지고 SW 빌드 비용이 무료라는 점을 감안할 때 SW 설계는 엄청나게 크고 복잡해지는 경향이 있다(Given that software designs are relatively easy to turn out and essentially free to build, an unsurprising revelation is that software designs tend to be incredibly large and complex)
SW 빌드는 저렴하지만 설계는 믿을 수 없게 비싸다(Software may be cheap to build, but it is incredibly expensive to design)
라고 했다.
조금 이상하게 들릴 수 있겠지만 소프트웨어에서 '빌드'란 그저 컴퓨터가 컴파일, 링크 등의 과정을 거쳐서 개발자가 작성한 코드를 실행 가능한 프로그램으로 바꾸는 과정일 뿐이다. 자동화된 빌드 시스템을 구축하면 거의 순식간에 이뤄진다. 그럼 설계가 소프트웨어 공학에서는 훨씬 더 중요해진다.
모든 공학의 산출물인 재생산 가능한 설계도에 대해서 소프트웨어 측면에서 알아보자.
소프트웨어 공학에서 설계도가 무엇일까? 각종 다이어그램(UML, C4 등) 등이 설계도가 될 수 있을까? 설계도는 재생산 가능한 문서화여서 설계도가 동일하다면 결과물도 동일해야 한다고 했다. 같은 다이어그램을 서로 다른 개발자들에게 전달하면 동일한 산출물이 나올까? 그렇지 않을 것이다.
아주 오랜 전에 팀장님이 클래스 다이어그램, 시퀀스 다이어그램 등을 그리면 내가 그것을 구현한 적이 있다. 처음엔 몰랐는데 나중에 이상한 것을 발견했다. 아무리 노력을 해도 팀장님이 그린 다이어그램대로 구현할 수가 없는 것이었다.
그때 팀장님에게
"팀장님 이상해요. 팀장님이 설계한 대로 구현해서는 원하는 결과가 나오지 않아요?"
라도 질문을 했다. 그랬더니 팀장님이
"다 그런 거죠. 어떻게 설계한 대로 구현이 되겠어요."
그때 팀장님의 의견은 설계를 참조해서 구현하는 사람이 결정을 해야 한다는 것이었다. 이때 다이어그램은 절대 재생산 가능한 설계도가 아니었다.
이보다 전에는 분석가, 설계가, 프로그래머(라고 부르고 사실은 코더였다), QA가 완전히 분리된 환경도 경험을 했었다. 이때 재생산 가능한 설계도는 찾아보기 어려웠다.
Rober C. Matin은 소프트웨어 공학의 설계도는 코드라고 했다. 코드만 동일하다면 어떻게 빌드하든 동일한 산출물이 나오기 때문이다. 그렇다면 설계를 잘해야 하는 소프트웨어 엔지니어는 소스 코드를 잘 작성해야 한다. 그래야만 지속적으로 생산성을 유지할 수 있다. 다시 말해 구축 이후 발생하는 기능 추가, 변경 등의 요구사항을 안전하고 빠르게 적용할 수 있게 된다.
공학의 목표 ~= 재생산 가능한 설계
소프트웨어 공학의 설계 ~= 소스코드
여기서 주의할 점은 얼마나 잘 설계해야 하는가? 다시 말해 코드를 잘 작성해야 하는가?이다.
우리 팀에서 가장 훌륭한 개발자는 OOP, SOLID 등의 원칙을 준수하면서 경우에 따라 Tranasction Script 방식으로, 어떤 때는 Domain Model 방식으로 비즈니스 로직을 구현하며 TDD, Refactoring 등을 구사하여 멋진 코드를 만들어 낸다.
코드 리뷰를 통해 이를 목격한 우리 팀 막내가 한 번에 이 수준으로 코드를 작성하겠다고 할 수 있다. 그러지 말아야 한다. 그러면 언제 커밋, 푸시하고 배포를 하겠는가? 자신의 수준에 맞게 관련된 코드 덩어리들을 잘 묶고 필요하다면 코멘트를 활용해서 우리 팀의 다른 동료들과 코드로 의사소통하여 자신의 의도를 전달하고 주요한 결함이 없는 수준에서 배포하며 팀에 기여해야 한다.
구축 비용보다 유지보수 비용이 훨씬 비싸다
건축과 같은 물리적 산출물을 목표로 하는 공학 영역에서는 구축 비용에 비해 유지보수 비용이 크지 않다. 아파트 구축 비용 대비 거주민이 살면서 발생하는 유지보수 비용은 매우 낮을 것이다.
하지만 소프트웨어는 그렇지 않다. 보통 소프트웨어의 유지보수 비용은 전체 비용의 80% 이상을 차지한다고 한다.
왜 그럴까? 왜 소프트웨어는 유지보수 비용이 비싸고 건축 등의 유지보수 비용이 낮을까? 내 생각은 다음과 같다.
물리적 산출물의 영역은 Hard 하다
즉 변경 요구사항을 수용할 수 없다. 30층짜리 아파트를 빌드하다가 28층 즈음에서 문제를 발견했다면 어떨까? 지금까지 빌드한 것을 다 부수고 문제 해결책이 적용된 설계를 반영해서 빌드할 수 있을까? 아마 그렇지 않을 것이다. 치명적인 것이 아니라면 조금 불편하더라도 수긍하고 사용할 것이다. 그래서 건축은 빌드 비용이 비싸고, 유지보수 비용은 저렴하다.
하지만 소프트웨어는 어떤가? 배포, 오픈이 얼마 남지 않았더라도 변경 요구사항을 수용해야 하는 경우가 대부분이다. Soft 해서 고칠 수 있기 때문이다. 고칠 수 없다면 변경으로 인한 유지보수 비용이 높지 않겠지만 고칠 수 있어서 변경으로 인한 유지보수 비용이 높다.
기획자는 자신이 만든 요구사항이 구현되어 그 소프트웨어를 사용해 봐야만 진정으로 자기가 원하는 것인지를 알 수 있다
이 문구의 출처는 기억이 안 나지만 매우 공감하는 문구이다. 인간은 예측에 취약하다고 한다. 아무리 예측을 잘해도 우리에게는 무엇을 모르는지도 모르는 경우가 있다(Unknown unkowns, 도널드 럼스펠드). 그러니 변경이 많이 발생할 수밖에 없다.
이 그림은 구축된 코드의 사용율을 보여준다. 항상(always), 가끔(often) 사용되는 것이 20% 밖에 안된다. 이처럼 인간은 정말 예측에 취약하다. 그러니 변경(유지보수) 비용이 높아진다.
그래서 변경은 소프트웨어의 본질이라는 이야기가 통용되는 것 같다.
이 글에서는 소프트웨어 개발을 공학적 메타포로 봤을 때 일반적인 공학과의 차이점을 살펴봤다.
다음 글에서는 이렇게 설계, 유지보수 비용이 많이 드는 소프트웨어 영역에서 높은 품질을 제공하는 것이 어떤 가치가 있는지를 살펴보도록 하겠습니다.
