바위 위에 지어지는 것은 없습니다. 모든 것은 모래 위에 지어지죠. 하지만 우리는 모래가 바위라고 생각하고 지어야 합니다. - 호르헤 루이스 보르헤스 (아르헨티나 소설가, 시인, 평론가)
최근에 예~~~전부터 눈독들여왔던 도서 '구글 엔지니어는 이렇게 일한다'를 읽기 시작했습니다.
모든 챕터를 정리하지는 못해도 시간이 허락하는 대로 읽은 내용을 정리해보려 합니다.
책 선정 이유
저는 경력이 이제 갓 1년 6개월을 넘어가기 시작한 초급 개발자 입니다.
그래서 '코딩을 하는 것 그 자체'보다 더 거시적인 시각에서 '개발 문화' 그리고 '장기 프로젝트를 유지 보수가 가능하게 운용하는 방법'에 대한 담론을 얘기하는 이 책이 저한테는 과분한 혹은 저에게는 시기상조인 책일 수 있겠습니다.
그럼에도 불구하고 이 책을 지금 읽기로 마음먹게 된 계기는 아래와 같습니다.
- 첫 직장에서 기술 부채를 제 때 해결하지 않고, 협업과 개발에 대한 정책이나 가이드라인 없이, 즉 건전한 개발 문화 없이 단순히 '코딩'을 반복해 나가는 것이 '건강에 해롭다'는 것을 깨달았습니다.
- 두 번째 직장은 초기 단계의 스타트업 입니다. 가서 최대한 업무와 문화를 최대한 열심히 배우고 적응하고 나서, 회사의 규모가 더 커질 시기가 되면 선배 개발자님들과 좋은 개발과 문화에 대한 담론을 나누고 정착 시키고 싶다는 생각을 했습니다.
그럼 정리를 시작해 보겠습니다.
도서 "구글 엔지니어는 이렇게 일한다"의 첫 번째 장에서는 소프트웨어 엔지니어링에 대한 정의를 제시합니다.
소프트웨어 엔지니어링은 흐르는 시간위에서 순간순간의 프로그래밍을 모두 합산한 것이다.
이 한 줄의 문장은 소프트웨어 개발과 소프트웨어 엔지니어링의 차이를 명확하게 보여줍니다.
저는 이 문장을 '엔지니어링 = 시간 + 프로그래밍' 이라고 더 간단하게 표현해 보았습니다.
엔지니어링 = 시간 + 프로그래밍
프로그래밍: 기본 요소
프로그래밍은 단순히 코드를 작성하는 행위입니다.
특정 문제를 해결하기 위해 컴퓨터에게 지시를 내리는 과정이죠.
프로그래밍은 소프트웨어 개발의 기본 요소이며, 모든 소프트웨어 시스템의 출발점입니다.
시간: 엔지니어링의 핵심 차별점
시간은 소프트웨어에 대해 생각할 때 엔지니어링이라는 관점에서 다양한 생각을 하도록 만드는 요소입니다.
책에서는 이를 다음과 같이 표현합니다.
정육면체는 정사각형이 아니고 거리는 속도가 아니듯, 소프트웨어 엔지니어링은 프로그래밍이 아니다.
소프트웨어가 단기간에 사용되고 버려지는 것이 아니라 수개월, 수년 또는 수십 년 동안 존속한다면, 시간의 영향을 고려해야 합니다. 시간이 지남에 따라 아래화 같은 변화를 맞이해야 하기 때문입니다.
- 요구사항이 변경됩니다
- 기술 환경이 진화합니다
- 팀 구성원이 바뀝니다
- 비즈니스 우선순위가 변화합니다
이러한 변화에 대응할 수 있게 관리하는 것이 소프트웨어 엔지니어링의 본질입니다.
때문에 정육면체를 극단적으로 납작하게 만들면 정사각형이 되듯이, 소프트웨어의 예상 존속 기간(시간)을 극단적으로 짧게 잡으면 '엔지니어링 = 프로그래밍'의 공식도 성립하게 됩니다.
시간축을 고려하면 '다른 것 들'도 보인다
시간이라는 요소를 고려하기 시작하면, 다른 중요한 요소들도 자연스럽게 고려해야 합니다.
1. 확장성의 필요성
소프트웨어가 오래 존속하면서 사용자가 증가하고, 기능이 추가되고, 데이터가 늘어납니다. 따라서 확장가능성이 중요해집니다.
- 기술적 확장성: 더 많은 트래픽, 더 많은 데이터, 더 복잡한 요구사항을 처리할 수 있는 능력
- 코드 확장성: 코드베이스가 커져도 관리 가능하도록 설계
- 팀 확장성: 더 많은 개발자가 동시에 작업할 수 있는 구조
시간이 지남에 따라 다양한 변화에 대응해야 할 때, 시간 - 비용 그래프가 선형 이상으로 증가한다면 이는 '확장 가능하지 않다'라고 판단할 수 있습니다.
소프트웨어의 확장성에 영향을 주는 요인은 아래와 같습니다.
- 전문성(expertise): 요구사항에 대한, 혹은 요구사항을 구현하기 위한 기술에 대한 전문성이 높을 수록 코드 베이스를 확장하기 쉬워집니다.
- 안정성(stability): 릴리즈의 규모를 줄이고 빈도를 늘려 더 짧은 간격으로 더 적은 변경 사항이 릴리즈 되도록 합니다.
- 순응(conformity): 모든 코드베이스에 주기적으로 업그레이드를 적용합니다.
- 익숙함(familiarity): 업그레이드르 정기적으로 실행하고 릴리즈를 자주 하게 되는 과정에서 중복되는 작업, 휴먼 에러의 소지가 다분한 작업을 찾고 자동화 하려고 노력합니다.
- 정책(policy): 소프트웨어 확장성을 높이기 위해선, 코드 바깥의 것들을 볼 수 있어야 합니다. 조직 문화나 좋은 정책을 설립하여, 확장성을 가지는 작업들을 이행하는데에 대한 부담을 줄이고 유인을 제공해야 합니다.
확장성을 높이기 위한 작업들(예를 들어 잦은 릴리즈)을 가능하게 하려면, 가능한한 많은 버그가 개발 타임라인의 왼쪽에서 발견 되도록 해야합니다. 이를 '원점 회귀'라고 합니다.
이 원점 회귀를 위한 완벽한 방법, 완벽한 툴은 없기 때문에, 다층 방어 전략을 구사해야 합니다.
2. 다양한 선택(트레이드 오프)의 필요성
소프트웨어를 오랜 기간 유지하다 보면 다양한 '선택(트레이드 오프)'이 필요해집니다.
이러한 트레이드 오프는 항상 명확한 답이 있는 것이 아니며, 상황과 맥락에 따라 달라집니다.
중요한 것은 이러한 선택을 의식적으로, 데이터에 기반하여 내리는 것입니다.
어떤 한 선택이 '내가 그렇게 정했으니까'가 되서는 안됩니다.
모든 선택은 최대한 데이터와 선례에 의해 결정되어야 합니다.
또한 결정권자는 결정이 잘못됐을경우 잘못을 인정하고 결정을 재고할 수 있어야 합니다.
3. 조직과 정책의 중요성
소프트웨어가 장기간 존속하려면 코드 자체만이 아니라 조직과 정책도 중요해집니다.
- 코드 소유권: 누가 코드의 어떤 부분에 책임을 지는지
- 개발 프로세스: 코드 리뷰, 테스트, 배포에 대한 규칙과 가이드라인
- 지식 공유: 팀원이 바뀌어도 지식이 유지되는 메커니즘
- 기술 문화: 품질, 협업, 혁신을 장려하는 가치와 관행, 구성원들이 스스로의 가치를 느끼고 생산적인 일을 하고 있다고 느끼게 하는 것을 모두 포함합니다.
Google에서는 이러한 조직적 측면이 기술적 측면만큼이나 중요하다고 강조합니다.
아무리 뛰어난 코드라도 그것을 관리하고 발전시키는 조직 체계가 없다면 시간이 지나면서 가치를 잃게 됩니다.
결론: 소프트웨어 엔지니어링의 본질
"엔지니어링 = 시간 + 프로그래밍"이라는 공식은 단순하지만 강력합니다.
이는 소프트웨어 개발의 본질이 단순히 기능적인 코드를 작성하는 것이 아니라, 시간이 지남에 따라 유지보수 가능하고 진화할 수 있는 시스템을 구축하는 것임을 상기시켜 줍니다.
시간이라는 요소를 고려하면, 자연스럽게 확장성, 트레이드 오프, 조직적 측면에 대한 고려로 이어집니다.
이러한 요소들을 균형 있게 관리하는 것이 성공적인 소프트웨어 엔지니어링의 핵심입니다.
Google의 경험에서 배울 수 있는 가장 중요한 교훈은 소프트웨어 엔지니어링을 단순한 기술적 활동이 아닌 총체적인 접근으로 바라봐야 한다는 것입니다.
코드뿐만 아니라 시간, 사람, 프로세스를 함께 고려할 때 진정으로 지속 가능한 소프트웨어를 만들 수 있습니다.
가장 중요한 점은 이러한 구글의 방법들 역시 '은 탄환'은 될 수 없다는 점 이라고 생각합니다.
제가 자주 시청하는 유튜브 '제미니의 개발실무'채널의 채널 소개 처럼 모든 곳엔 '진리의 케바케'가 존재하기 때문입니다.
내가 속한 곳의 규모와, 프로젝트의 예상 존속 시간, 규모, 처한 환경에 따라 앞으로 이 책에서 소개될 다양한 방법론을 스케일링(비례축소)하여 적용하는 것이 중요하다고 생각됩니다.
다만, 저는 한 가지 확실한 점은 있다고 생각합니다.
바로 '우리는 구글이 아니니까'라는 핑계로 더 좋은 문화에 대한 '고민과 생각을 덮어두는 것'만은 명백히 '다름이 아닌 틀린 행위이다'라는 점입니다.
비록 저는 아직 하잘것 없는 초급 개발자 이지만, 이런 확신을 바탕으로 '여러 거인들의 어깨위에 올라타 멀리 보는 연습을 하는 것'과 '그곳에서 본 경치에 대해 생각하는 것'을 멈추지 않을 계획입니다.
이 글은 "구글 엔지니어는 이렇게 일한다"(Titus Winters, Tom Manshreck, Hyrum Wright 저)의 첫 번째 장을 기반으로 작성되었습니다.