구글의 소프트웨어 엔지니어링 (1/5)

1. 소프트웨어 엔지니어링이란 무엇인가?

편의상 엔지니어링과 공학을 혼용해서 사용하였습니다.

• 혹시 컴퓨터 과학과 컴퓨터 공학의 차이를 설명하실 수 있나요?
• 프로그래머와 소프트웨어 엔지니어의 차이를 구분하실 수 있나요?

 

잠깐 책 이야기에 앞서, 경험담을 먼저 이야기 드리고 싶습니다. 뜬금없지만 한 번은 아버지와 TV를 보며, 논쟁을 벌인 적이 있습니다. 왜인지는 모르겠지만 그 때 엔지니어링에 관해 이야기를 하고 있었습니다. 그리고 이야기를 하던 도중 저는 "개발자도 엔지니어다"라는 말을 했습니다. 그러자 전자공학과 출신이신 아버지는 제가 엔지니어라는 말을 듣고 고개를 갸웃거리셨습니다.

 

사실 논쟁이라고 하기도 민망할정도로 가벼운 의견 교류였지만 어쨌거나 살짝 자존심이 상했었습니다. 컴퓨터 공학을 전공했고, 소프트웨어 엔지니어라고 부르고, 소프트웨어 공학이라는 수업도 들었습니다. 평상시에 엔지니어라는 자부심도 가지고 있었습니다. 그치만 객관적으로 봤을 때 저는 소프트웨어 엔지니어도 엔지니어다 라는 말을 논리적이고 설득력있게 주장하지 못했습니다.

 

생각해 보면, 엔지니어라는 말을 들었을 때, 엔지니어는 뭔가 하드웨어를 만들고 있을 것만 같습니다. 기계 공학은 기계를 만듭니다. 원자력 공학은 원자력 발전 설비를 개발합니다. 전자 전기 공학은 회로를 만집니다. 그렇지만 컴퓨터 공학은요?

 

물론 컴퓨터 공학은 소프트웨어를 만듭니다. 혹은 진로에 따라 회로 업무를 일부 만지기도 하는 것으로 압니다. 하지만 그럼에도 소프트웨어는 실체가 다소 애매모호합니다. 소프트웨어를 개발하는 것을 공학이라고 볼 수 있을까요? 애초에 공학이란 뭘까요? 위키피디아에서 정의 내린 공학에 대해서 읽어보면... 그런가 싶으면서도 확신이 들지 않았습니다. 좀 더 명확한 답을 얻고 싶어서 여기저기 찾아봤지만, 어딘가에서 명확한 해답을 얻기 어려웠습니다.

 

그래서인지 이 책의 도입부에서 구글은 소프트웨어 엔지니어링이란 무엇인지를 정의를 내리고 시작합니다. 그리고 프로그래밍과 엔지니어링을 구분합니다.

소프트웨어 엔지니어링은 프로그래밍에 시간이라는 개념이 추가된 것이다.

구글이 말하는 소프트웨어 엔지니어링이란 프로그래밍에 시간, 확장, 트레이드오프를 고려한 것이라 합니다. 책을 다 읽고 나서야 이게 얼마나 많은 의미를 담고있는지 깨달았습니다. 그리고 소프트웨어 엔지니어링을 가장 정확하게 서술한 정의라고 생각합니다. 이게 뭔 소린가 할 수 있으니 몇가지 단편적인 사례로 풀어서 이야기해봅시다.

 

모든 코드에는 기대수명이란 것이 있습니다. 간단하게는 더미 데이터를 만들기 위해 사용되는 일회성 스크립트 코드부터, 한 달 정도 임시로 사용할 셸 스크립트, 졸업 프로젝트를 위해 1~2년 정도 운영하기 위해 만들어지는 스프링 백엔드, 혹은 수십, 수백 년 유지되고자 하는 프로그램 등... 어떤 목적을 갖고 태어난 코드는 기대 수명이라는 게 존재합니다.

 

그리고 당연하게도 기대 수명에 따라 프로그램에 요구되는 깊이와 투자해야 하는 시간이 다를 겁니다. 한 달 정도 사용할 코드를 작성하면서 스크립트 버전이 올라가 호환이 안될 걱정을 할 일은 없을 겁니다. 또한 1~2년 동안 사용할 스프링 백엔드를 개발하면서 스프링 메이저 버전 업데이트를 걱정할 필요도 없을 겁니다. 하지만 수십수백 년을 목표로 하는 프로그램은 어떨까요?

 

하다못해 지난 10년 사이에만 해도 자바 버전은 7(2011)에서 17(2021)으로 업데이트되었습니다. 그리고 한 번은 중간에 자바라는 프로그래밍언어가 유료화 된다는 괴담이 돌면서 난리가 나기도 했습니다. 수십 년을 목표로 하는 프로그램이라면 언어의 버전 업데이트를 신경 쓰지 않을 수가 없습니다. 2005년에 개발되어 자바 5버전을 사용하고 있는 프로젝트가 있다고 가정합시다. 그리고 고집이 센 백엔드 엔지니어들 때문에 2018년까지 자바의 버전 업데이트가 없었다고 합시다. 시간이 흘러 어느날 자바 5에 보안적 결함이 발견되었습니다. 그리고 오라클에서는 자바 9 버전 이전에 대한 업데이트를 더 이상 지원하지 않는다 합니다. 이제는 진짜로 업데이트해야 할 때입니다. 그런데 눈을 떠보니 자바는 어느새 11버전까지 나왔습니다. 게다가 자바 9버전부터는 모듈 시스템이라는 새로운 시스템이 도입되면서 큰 변화가 있었다고 합니다. 프로젝트는 자바 11로 업데이트하고 싶은 상황입니다. 과연 무사히 버전 업데이트를 할 수 있을까요?

수명이 길어질수록 업데이트의 중요성은 늘어납니다.

 

결국 수십 년을 바라보는 프로그램은 큰 변화가 있을 때마다 주기적으로 업데이트를 따라가줄 필요가 있습니다. 단순히 언어 버전만의 문제가 아닙니다. 아무리 유려한 코드일지라도 시간이 지나면 노후화되는 것도 문제입니다. 리팩토링을 고려하지 않을 수가 없습니다. 규모 면에서의 확장도 고민이 됩니다. 시스템이 커지면서 채용을 자꾸 늘리는데, 확장 가능하도록 시스템이 설계되어 있지 않다면 이것만큼 낭패가 아닐 수 없습니다.

 

어떤 라이브러리나 DB를 선택할 때도 시간을 고려해야합니다. 그리고 이에 따른 트레이드오프를 고려해야합니다. 지금은 활발히 사용되고 있는 라이브러리지만 갑자기 메인테이너가 업데이트 지원 중단을 하면 어떡하죠? 

 

결국 시간이라는 개념이 도입되면서 고려해야 할 대상이 전반적으로 바뀝니다. 이런 배경 설명을 듣고 아래 설명을 다시 읽어보면 뭔가 다르게 받아들여집니다.

소프트웨어 엔지니어링은 프로그래밍에 시간이라는 개념이 추가된 것이다.

이렇게 정의를 내리고 보니, 개발에 대해서 바라보는 시야가 달라지기 시작합니다. 그리고 이 책의 내용들도 대부분 이런 새로운 시각으로 프로그래밍을 대하는 방식에 대해 다루고 있습니다.

 

마무리

누군가에게는 당연한 지식일 수도 있을 것 같습니다. 하지만 적어도 저는 모르던 지식들이었고, 가장 인상 깊었던 도입부라서 글이 길어졌습니다.

 

도입부를 쓰신 Titus winters 님이 프레젠테이션한 강의도 있으니 참고하면 좋을 것 같습니다. https://youtu.be/SqU8TZDnFFA

 

* 일부 내용은 예시를 들으려다 보니 약간씩 다른 부분이 있습니다. 예를 들어, 사견이지만, 자바 8과 자바 9는 거의 다른 언어라고 생각합니다. 메이븐 호환도 안되는 게 많고 모듈 시스템 도입같이 이해하기 어려운 새로운 시스템이 들어오는 등 환경 자체가 너무 크게 바뀌었습니다. 그래서 보통 자바 8에서 자바 9로 업데이트하지 않는 경우가 많은 것 같습니다. 만약 조직에서 자바 5에서 자바 8로 업데이트하자는 결정을 내린다면 생각보다 쉽게 업데이트를 마칠 수 있다고 생각합니다. 하지만 좀 더 긴 시간이 지나면 다른 방법을 고려하지않을 수 없습니다. 그리고 대부분은 자바 9를 선택하는 것보다는 코틀린으로 갈아타는 경우가 많은 듯 보입니다.