[역자 직강?] 구글 엔지니어는 이렇게 일한다
프로그래머여, 소프트웨어 엔지니어가 되자!
★ 제가 번역한 《구글 엔지니어는 이렇게 일한다》를 주제로 발표한 내용의 도입부를 정리한 글입니다.
★ [2023-09-11] 최근 발표 영상이 공유되어 있습니다. 글도 업데이트 버전을 새로 썼으니 새 글을 참고해주세요.
'람다256'에서.. (2022-10-07)시간 위를 걷는 프로그래밍
책 번역이 끝나갈 즈음 많은 분께 리뷰를 부탁드리고 추천사를 받았습니다. 그중 ‘우아한테크코스’를 총괄하시는 박재성 님의 다음 추천사가 가장 마음에 와닿았습니다.
아마 대부분의 프로그래머가 박재성 님과 마찬가지로 소프트웨어 엔지니어링을 그다지 반겨하지 않고 살아왔을 것입니다. 하지만 박재성 님은 이 책을 접하고 추천사에서와 같은 이유로 거부감이 사라지셨다고 하시네요. 대학생 때부터 소프트웨어 엔지니어링을 좋아했던 제게는 아주 반가운 작은 변화였습니다.
참고로 저는 소프트웨어 엔지니어링을 전공하지 않았고, 대학 수업조차 듣지 않았습니다. 군대에서 우연한 기회에 관련 원서를 읽고 푹 빠져버렸죠. 제게 소프트웨어 엔지니어링은 소프트웨어를 올바르고 제대로 개발하기 위한 종합 예술이었고, 그 중심에는 사람이 있었습니다.
하지만 제가 만난 대부분의 프로그래머는 소프트웨어 엔지니어링을 고리타분하고 너무 학술적인, 현실과 동떨어진 분야로 치부했습니다. 왜 그렇게 생각하는지 짐작되지 않는 바는 아니었지만.. 어쨌든 우리가 하는 일을, 우리의 워너비 개발 문화를 가장 잘 대변하는 게 소프트웨어 엔지니어링이라 생각한 저는 이런 인식이 몹시 아쉬웠습니다.
앞에서 박재성 님의 인식을 바꿔준 표현인 ‘시간 위를 걷는 프로그래밍’은 영어로는 ‘Programming over Time’입니다. 우리말로 어떻게 옮길까 많이 고민한 기억이 나는데, 결과적으로 잘 번역한 것 같습니다. 이 말을 풀어보면 다음과 같습니다.
소프트웨어 엔지니어링: 코드를 작성하는 행위에 더하여, 시간의 흐름에 발맞춰 한 조직이 코드를 구축하고 유지보수하는 데 이용하는 모든 도구와 프로세스를 포괄
시간이 흐르면 소프트웨어에는 변경이 생기고, 규모가 커지고, 조직은 성장합니다. 이 모든 변화 요인을 고려했을 때 아키텍처는 어떻게 잡아야 하고, 설계는 어떻게 해야 하고, 코딩은 어떻게 해야 잘하는 것인지를 연구하고 실천하는 것이 바로 소프트웨어 엔지니어링입니다.
소프트웨어 엔지니어라면..
우리의 직업을 부르는 용어는 다양합니다. 프로그래머, 개발자/디벨로퍼, 소프트웨어 엔지니어. 그리고 드물게 코더라로 불리길 원하는 분도 계십니다. 다음 그림은 용어만 놓고 봤을 때 제가 느끼는 일의 범위입니다. 공감되지 않으시면 그냥 무시하시면 됩니다. �
여러분의 명함에는 직업이 무어라 적혀 있나요? 혹시 ‘프로그래머’라고 적혀 있더라도 “아! 소프트웨어 엔지니어시군요?”라고 되물었을 때 “아니요, 전 프로그래머예요”라고 답하는 사람은 거의 없을 겁니다.
이렇듯 소프트웨어 엔지니어로 불리는 직업에 종사하는 우리입니다. 그렇다면 소프트웨어 엔지니어링이 무엇인지는 이해하고, 적어도 이 용어에 거부감은 갖지 않아야 하지 않을까요?
나아가 소프트웨어 엔지니어임을 자각하고, 스스로 소프트웨어 엔지니어임을 남들에게 어필해야 ‘우리의 권익’을 찾을 수 있다고 저는 생각합니다.
업계 비밀 한 가지..
“개발자(프로그래머)들은 매번 안 된다고 징징대면서도, 쪼으면 결국 해낸다”라는 우스갯소리가 있습니다. 왜 이런 말이 나왔고, 우리는 씁쓸해하면서도 부정하기 어려울까요?
이유는 간단합니다. 쪼을수록 프로그래밍에 집중하고, 소프트웨어 엔지니어링에서 이야기하는 일들을 제대로 하지 않고 넘기기 때문입니다.
프로그래밍만 한다면 마감일까지 요구 기능 대부분을 어떻게든 돌아가게 할 수 있습니다. 하지만 우리는 뒷날까지 생각하며 제대로 된 소프트웨어를 만들고 싶어 합니다. 그러려면 제대로 된 개발 문화를 일구고, 프로세스를 정립해 따르고, 도구와 인프라를 갖추고 효율도 발맞춰 개선해야 합니다. 우리가 실제로 매일매일 수행하고 있거나 하고 싶어 하는 일들이죠.
‘프로그래밍’이라는 용어는 이 모두를 담기에는 너무 작습니다. 기획자나 디자이너 등 외부 협력자에게 프로그래머가 하는 일을 제대로 대변하지 못합니다. 우리가 스스로를 프로그래머라고 소개한다면, 매일같이 수행하는 수많은 일 중 오직 프로그래밍(≒ 코딩)만을 그들은 상상할 것입니다. 그래서 이제부터라도 다음처럼 이야기해야 하지 않을까요?
“저는 소프트웨어 엔지니어이고, 프로그래밍은 제 일 중 작은 일부일 뿐이에요.”
실제로 현실이 그렇고, 이렇게 말해야 우리를 바라보는 일반의 인식이 조금씩이나마 올바른 방향으로 변하지 않을까 생각해봅니다.
이 책의 구성
《구글 엔지니어는 이렇게 일한다》는 크게 4부로 구성됩니다.
1부에서는 앞서 잠시 이야기한 ‘소프트웨어 엔지니어링’을 깊게 알아보며, 앞으로 이야기할 내용의 토대를 닦습니다.
2~4부는 문화, 프로세스, 도구를 다루는데..
‘문화’는 개발 조직이 아니더라도 대부분의 조직 관리에 공통된 내용으로 채워져 있습니다. 실제로 다른 조직 관리나 리더십 책들과 교집합이 많습니다. 사람이 모여 일하는 곳은 어디든 비슷하니까요. 엔지니어의 용어가 가끔 등장하지만, 다른 부서 사람이 읽는 데 딱히 어려운 건 없어 보입니다. 그러니 다들 한 번씩 읽어보시면 개발 조직의 사람들을 이해하고 앞으로 소통하는 데 많은 도움이 되리라 생각합니다.
‘프로세스’부터는 개발 조직에 특화된 이야기가 시작되고, ‘도구’에 가면 구글에만 해당하는 내용도 다소 포함됩니다.
‘문화 → 프로세스 → 도구’ 순서로, 범용적인 내용에서 점차 구체적으로 들어가는 구조입니다. 그래서 처음에는 범용성을 기준으로 구성했나 싶었는데, 생각해보니 ‘중요도’가 기준이 아닌가 싶습니다. 훌륭한 문화 없이 멋진 프로세스와 도구를 도입하거나 개선하는 건 어불성설입니다. 먼저 문화를 갖춘 후, 프로세스를 올바르게 정립하고, 적절한 지원 도구들을 찾아 도입하거나 직접 개발/개선해야 할 것입니다.
그래서 제 발표 자료와 발표 분량 역시 ‘문화’에 집중되어 있고, 프로세스가 중간, 도구는 단순 요약 수준입니다. 특히 도구의 경우엔, 제가 구글러 출신이 아니라서 더 말씀드릴 게 거의 없기도 하고요.
들어가기 전에
책 내용으로 본격적으로 들어가기 전에 마지막으로 드릴 말씀이 있습니다.
이 책을 읽으실 때, 결론만 보지 마시고 원인과 과정을 함께 보세요. 구글도 처음부터 이 책이 말하는 수준이 아니었습니다. 그러니 자신의 현 위치와 처한 상황을 냉철히 파악한 다음, 거기서 한 걸음 내딛으려면 무엇 무엇이 필요하고, 무엇이 우선순위인지를 고민해주세요. 그러면 이 책이 저 멀리 서있는 딴 나라 회사의 피상적인 이야기가 아닌, 실용적인 지침서가 되어줄 것입니다.
