읽은 책

저자: 박성철, 강대명, 공용준, 김정, 박미정 저 외 3명

출판사: 골든래빗

총 페이지: 252p

링크: https://product.kyobobook.co.kr/detail/S000200381165

읽게 된 계기

처음 이 책을 접하고 목차들을 쭉 훑었는데 그동안 시니어들에게 궁금했던 내용들이 담겨 있어서 읽게 되었다. 목차마다 다른 개발자들이 내용을 작성했기 때문에 각자 가장 중요하게 생각하는 내용 혹은 전달하고 싶은 내용을 담은 것 같아서 궁금했다. 업무를 하다보면 이런 저런 고민이 생겨서 머리가 복잡할 때가 있는데, 주로 퇴근길 지하철에서 책을 읽다보니 그런 고민을 풀어주는 느낌을 받아서 좋았다.

기억에 남는 문장

1. 덕업일치를 넘어서

어떤 일을 시작할 때면 그 일을 해야 할 개인적인 의미를 찾아 가능한 강한 내적 동기를 가지고 일하려고 의식적으로 노력했습니다. 정 동기가 찾아지지 않으면 일부러 제가 하고 싶은 일을 그 과제에 섞어넣기도 했습니다.

내게 맡겨진 업무가 불만족스러울 때면 내가 하고 싶은 걸 할 수 있도록 환경을 바꾸고 싶다라는 생각을 우선 하게 되는 것 같다. 그러나 현실적으로 내가 하고 싶은 것만 할 수 있는 환경이란 존재하지 않기 때문에 불만족스러운 환경에서도 나의 동기를 끌어올릴 수 있는 방법을 찾아야 한다.

이 문장이 그걸 일깨워준 것 같았다. 그런 사실을 이성적으로는 알고 있으나 늘 의식적으로 그렇게 생각하기란 어렵기 때문이다. 그래서 이 문장을 한번 더 되새김으로써 주체적으로 일을 하고 내 동기를 관리하자라는 마음에서 기록하고 싶었다.

동기를 관리하는 사람은 자신의 에너지도 관리하고 지나치게 에너지를 소진하지 않으려고 노력합니다. 동기는 단순히 있고 없고 하는 것이 아닌 크기가 있는 양입니다. 에너지 관리는 단순히 에너지를 소진하지 않으려고 걱정하며 조심하는 소극적인 방식이 아닌 회복 탄력성을 키우고 에너지 그릇을 키우는 적극적 방식이 좋습니다.

그동안은 동기를 양의 관점에서 바라보기 보다는 유무를 따졌기 때문에 이 문장이 새롭게 다가왔다. 또 에너지 관리는 단순히 에너지를 소진하지 않으려고 걱정하며 조심하는 소극적인 방식이 아닌 이라는 구절도 좋았다.

나는 번아웃과 같은 상태에 한번 빠지고 나서는 다시는 그 상태로 돌아가지 않도록 에너지를 과소비 하지 않도록 주의했었다. 그러나 그것도 하나의 방법이지만, 회복탄력성과 에너지 그릇이 근본적으로 가장 중요한 문제인 것 같다. 멘탈이 강한 사람은 회복 탄력성이 좋은 사람이다라는 말이 있듯 언제 지치더라도 금방 회복해서 다시 달릴 수 있도록 내 회복 탄력성을 관리해두어야 할 것 같다.

제 머릿속에는 처음 이 직업을 선택할 때 마음을 움직인 ‘쓸모 있는 일을 하자’는 결심이 자리잡고 있습니다. 오늘도 저는 제가 쓸모 있는 일을 하는지, 다시 말해서 이 사회에 가치 있는 결과를 만들어내고 있는지 묻습니다.

사회에 미치는 영향력에 준하는 사명감과 전문 역량과 윤리의식을 겸비한, 그래서 스스로 자랑스럽고 사람들에게 존중받는 개발자의 모습을 저는 여전히 찾고 있습니다.

내가 어떠한 직업을 선택할 때 중요시했던 가치와 일치해서 기록해두고 싶었던 문장들이다. 나는 내가 일을 함으로써 세상을 보다 더 살기 좋게 만들고 싶었고, 그런 도구 중에 하나로 매력적이게 보였던 게 개발이었다. 이러한 생각을 되새김하면 좋을 것 같아 남긴다.

2. 오류를 만날 때가 가장 성장하기 좋을 때다

툴의 소스 코드를 확인하는 것으로 관련 에러가 왜 발생하는지 해결하려면 어떻게 해야 하는지 같은 깊은 지식을 얻을 수가 있습니다. 파생되거나 비슷한 문제를 예방할 수도 있게 됩니다. 이것이 바로 제가 소스 레벨에서 오류를 확인하라 주장하는 이유입니다.

사용하는 툴의 에러를 파악하기 위해서는 소스 코드를 보는 것만큼 좋은 게 없는 것 같다. 예전엔 항상 문서를 확인하거나 검색을 통해 해결을 했었는데 사용자가 많지 않은 툴은 트러블 슈팅도 많지 않아서 소스코드를 직접 찾아봐야 했다. 그 때 에러가 발생하는 원인이 뭔지 직접 코드를 통해 명확히 알 수 있던 게 너무 명쾌하고 좋았었다.

이후로는 어떤 에러가 발생했는데 검색을 해도 명확히 풀리지가 않거나 이건 코드를 직접 보면 더 좋을 것 같다 생각되는 경우에는 소스코드를 찾아가게 되었다. 무엇보다 가장 신뢰 있고 가장 명쾌한 답을 주는 것인 것 같다.

3. 소프트웨어 디자인 원칙

많은 사람이 망각의 축복을 만끽하는 바람에 하나의 기능이나 완결된 버전의 소프트웨어를 만들고 나면 그 이후에 발생하는 많은 요구사항과 복잡한 기능을 더 적은 리소스를 투입해 해결하려고 합니다. 왜냐면 이미 적은 리소스를 가지고 만든 효율적인 경험이 있기 때문에 그다음은 더 쉬울거라고 상상하는 겁니다. 한 번 릴리즈된 소프트웨어는 시간이 지날수록(릴리즈가 되면 될수록) 커집니다. 물리적으로 느껴지는 소프트웨어 파일 크기도 커지고 개수는 늘어나며 구성과 의존성은 더욱 복잡해집니다. 그래서 굉장히 당연하게도 그다음 버전이나 기능의 완성은 느려질 수밖에 없는데도 다음 버전을 만들 땐 더 빨리 더 효과적으로 만들 수 있다고 생각합니다.

이 문장은 요즘 깊이 공감이 되고 있다. 얼마 전에 있었던 기능 개발 건에 대해 예상보다 더 긴시간을 소요하게 되었는데, 새로 접하는 아키텍처와 디자인 패턴을 도입했다는 다른 요인도 결합되어 있었지만 기존의 코드가 생각 외로 발목을 잡은 것도 원인이었다.

필요로 했던 로직이 이미 비슷하게 작성되어 있기에 재사용하려고 했는데, 이 로직은 여러 군데에 의존성이 있어서 기존 코드를 시간을 들여 분석해야 했다. 또 요구 사항에 맞게 수정한 뒤 의존성이 있던 부분들이 문제 없이 잘 동작하는지도 체크해야 했다.

이를 어느정도 방지하기 위해서는 저자가 말한대로 설계나 디자인에 대한 공부가 필요한 것 같다. 시간이 지날 수록 더욱 복잡해질 수 밖에 없는 것이 소프트웨어지만, 유지보수성을 최대한 끌어올릴 수 있는 방법에 대해 고민해야겠다.

4. 나의 메이저 버전을 업그레이드하는 마이너 원칙들

성장을 목표로 한다면 먼저 방향과 나만의 속력을 알아야 합니다. 낯선 목적지를 찾아갈 때 방향을 정확하게 인지하지 못하면 방황하거나 더 먼길로 돌아갈 수 있으므로 이동할 방향을 반드시 알아둬야 합니다. 그런데 현실에서는 목표가 있는 방향으로 일직선으로 나아가는 일이 불가능합니다. 인생에는 언제 내리고, 언제 방향을 바꾸고, 어디로 돌아가야 할지 알려주는 지도 앱 같은 안내자가 없습니다.

방향성이란 항상 늘 고민하게 되는 것이고, 중요한 만큼 결론짓기가 어려워 언제나 명쾌한 답으로 존재하기가 어려운 것 같다. 따라서 이 책에서 말한 것처럼 계속해서 두리번거리면서 내가 어느 방향으로 가고 있는지 어디로 가야할지 항상 결정을 내려가며 고민하는 게 필요한 것 같다.

익숙한 것을 반복하면 더 오래 기억할 수 있게 되지만 성장하지는 못합니다. 성장을 위한 더 효과적인 방법은 의도적으로 낯선 환경을 만들고 제약사항을 추가해서, 도전적이면서 살짝 어렵지만 재밌는 요소를 찾아서 학습하는 겁니다.

반복하게 되면 익숙해지는데 그 익숙한 걸 잘하는 것이라 착각할 수 있게 되는 것 같다. 그것도 스킬이지만 실력이 좋은지 판가름하는 척도는 아닐 것 같다. 저자가 말한대로 실력을 키우기 위해서는 익숙한 것에서 벗어나 도전적으로 학습해보는 게 필요할 것 같다. 그런 도전적인 환경에 놓였을 때 더 근본적인 문제에 다가가 문제 해결 능력을 키울 수 있을 것 같다.

시야를 넓게 해서 다양한 기준에서 과정을 자주 되돌아볼 줄 알아야 합니다. 그러려면 목표가 어디로 움직였는지, 스스로 어디를 향하는지 방향을 빠르게 인지하는 게 중요합니다. 그리고 방향이 바뀔 때마다 과정을 기록해보세요. 결과만 있는 기록과 다르게 과정을 기록하면 메타 인지 관점에서 자신을 돌아보는 데 매우 도움이 됩니다.

소프트웨어 개발자는 코드로 보여줍니다만, 자신의 코드가 의도한 자신의 생각은 꼭 설명할 수 있어야 합니다.

5. 이직, 분명한 이유가 필요해

쉽게 흔들리지 않는 체계가 존재한다는 것은 어떤 종류의 일이 팀에 찾아와도 일을 해낼 수 있는 조직/개발 문화가 기반이 된다는 것이고, 달리 표현하자면 안정적인 프로세스 안에서 내가 시야를 넓힐 시도를 할 수 있는 여유가 하락된다는 뜻이기도 합니다. 스타트업에서 스스로 기회를 찾아내기에는 이미 해내야 하는 일들이 가득했습니다.

나는 현재로서는 회사 내부에서도 체계가 불안정한 조직에서 일을 하고 있기 때문에 언제나 명확한 체계가 있는 곳에서 일을 하고 싶다는 욕구가 있는 것 같다. 체계가 갖추어지지 않음으로 인해 불필요한 의사소통이 반복적으로 일어나고, 일을 여러번 반복하게 되는 것 같았기 때문이다. 내가 체계가 있다고 말하는 조직 안에서 일해 본 경험이 없기 때문에 그곳에서도 얼마만큼의 비효율적인 프로세스가 일어나는지는 잘 알 수 없지만 말이다.

그럼에도 이직하고 싶다라는 분명한 결정을 내리기가 어려운 것은 지금 환경에서만 겪을 수 있는 경험들이 존재하기 때문인 것 같다. 프로덕트의 설계부터 출시까지 전반적인 경험을 할 수 있기 때문에 다른 곳에서는 주니어로서 쉽게 접할 수 없는 일들을 할 수 있다.

6. 목표를 달성하는 나만의 기준, GPAM

주기적으로 평가를 해서 목표와 계획과 실천을 계속 점검해야 합니다. 평가를 하면 ‘목표 대비 조금만 더 하면 되겠어. 드디어 목표를 달성했어’처럼 도전의식과 성취감을 얻을 수 있습니다.

사람에게 감정은 무언가를 달성하는 힘이 되기도 포기하게 되는 짐이 되기도 합니다. 의욕을 가지고 지속적으로 실천하려면 꼭 평가를 수행해야 합니다.

그동안 나는 평가의 중요성을 간과한 적이 많았기 때문에 이 문장들을 기록해두고 싶었다. 가장 큰 목표만 머릿 속에 채우고 과정에 대해서는 많이 되돌아보지 않았기 때문에 내가 얼마만큼의 기량을 낼 수 있는 사람인지 명확히 정의내리기 어렵기도 했다. 또 중간중간 평가를 함으로써 최종 목표를 달성하는 과정 중에서도 성취감을 얻을 수 있다는 점이 좋은 것 같아 개인적인 기록 같은 걸 더 자세하게 써보는 게 좋을 것 같다.

항상 상황은 변하기 때문에 목표와 계획을 세워 두고 실천까지 오래 끌다 보면 의미가 없는 목표가 되어 버리거나, 계획 실천이 불가능해지거나, 각오가 사그러들거나, 잊힙니다.

7. 프로덕트 중심주의

흔히 디테일을 너무 강조해서는 안 되고, 빠르게 진행하고 실패하라고 말합니다 빠르게 실패하는 원칙에 전적으로 동의합니다. 하지만 프로젝트 후반부의 진행에서도 핵심 목표 없이 빠르게, 점진적으로만 진행해서는 프로덕트의 완성도를 좌우할 디테일을 발휘할 기회가 사라지게 됩니다.

디테일한 완성도는 제품을 차별화를 결정하는 데 중요하기 때문에 빠른 실패가 더 중요한 시점이 어느 때인지를 판단하는 게 필요한 것 같다. 지금 내가 만들고 있는 프로덕트도 여태까지는 속도가 가장 중요했지만, 필수적인 기능적인 것들은 어느정도 갖춰두었으니 조금씩 완성도를 챙겨나가는 것이 이제부터 필요하겠다란 생각이 들었다.

보잘것없거나, 심지어 본인이 보기에 완전한 실패라 해도 시도를 망설일 필요는 전혀 없습니다. 더 나은 프로덕트를 목표로 삼고 무언가를 계속 반복적으로 시도하면 점점 프로덕트를 잘 이해하게 됩니다. 프로젝트 실패 경험은 오히려 큰 성장을 이루게 하며, 앞으로 더 잘할 수 있는 역량을 보장하기 때문입니다.

아직 프로덕트가 정식적으로 출시되지는 않았지만 만드는 과정에서도 실패를 느낄 때가 많은 것 같다. 그러나 실패란 당연하게 있을 수 밖에 없는 것이기에 이 경험을 기반으로 프로덕트의 성장 방향을 더 고민하는 게 가장 중요한 것 같다.

8. 제어할 수 없는 것에 의존하지 않기

일정과 퀄리티는 어느 한쪽 포기해야 한다와 같은 시소 관계가 아니라, 어떻게 하면 아무리 급해도 항상 80~90점짜리 소프트웨어를 개발할 수 있는지가 중요하다

일반적으로 A 코드가 더 나을지, B코드가 더 나을지 고민하면서 적지 않은 시간을 보내게 되는데, 그분들은 A 코드와 B 코드 중 현재 상황에 더 적합한 코드를 판별하는 기준과 원칙이 있어 고민 없이 곧바로 선택합니다. 기준과 원칙에 따라 빠르게 결정을 내리면, 정말 중요한 설계와 선택이 필요할 때 더 깊게 사고할 수 있는 시간을 확보하고 사용하게 됩니다.

정식 출시 전 단계인 지금 프로덕트를 개발하면서 속도를 중요시하다 보니 계속해서 퀄리티의 중요성을 잃어가고 있는데, 내 역량이 어느 정도의 퀄리티를 끌어올릴 수 있는지를 결정하는 것 같다. 종종 코드를 작성하면서 깊은 고민에 빠질 때가 있는데 그런 경우는 내가 해당 케이스에 대한 판단을 내릴 수 있는 지식이 없었기 때문인 것 같다. 따라서 그 결단력을 기르기 위해 이를 판단할 수 있는 역량을 계속해서 다져 나가야 할 것 같다.

코드와 마찬가지로 현실에서도 역시 제어할 수 없는 것에 대한 의존성을 낮추고 제어할 수 있는 것을 선택하면 쉽게 흔들리지 않는 견고한 생활을 지킬 수 있습니다.

아무리 고민을 해도 해답이 나오지 않고 고민이 한층 더 깊어지는 것은 이런 제어할 수 없는 부분조차 고민의 영역으로 두기 때문인 것 같다. 저자 말대로 제어할 수 없는 것은 고민을 해도 바꿀 방법이 없으니 제쳐 두고 내가 할 수 있는 일에 집중하는 것이 앞으로 지속해서 나아갈 수 있는 원동력도 만들어주고, 현명한 결정을 할 수 있게 해주는 것 같다.

9. 달리는 기차의 바퀴를 갈아 끼우기

첫째, 많이 읽어야 잘 쓸 수 있다. 책을 많이 읽어도 글을 잘 쓰지 못할 수는 있다. 그러나 많이 읽지 않고도 잘 쓰는 것은 불가능하다. 둘째, 많이 쓸수록 더 잘 쓰게 된다. 축구나 수영이 그런 것처럼 글도 근육이 있어야 쓴다. 글쓰기 근육을 만드는 유일한 방법은 쓰는 것이다. 여기에 예외는 없다. 그래서 ‘철칙’이다.

다른 사람이 작성한 코드는 그 사람이 작성해낸 해답지와 같다는 생각이 든다. 그래서 좋은 코드를 작성하고 싶을 때면 실력이 좋은 개발자들의 소스코드를 가장 먼저 찾게 되는 것 같다. 코드의 퀄리티는 아무리 많이 작성한다해서 나아지는 것이 없기 때문에 의식적으로 잘 작성된 남의 코드를 자주 읽어야겠다.

바퀴를 다시 발명하는 일은 결과보다는 과정에 더 큰 가치가 있습니다. 현실 세게에서는 과정보다 결과가 중요하고, 바퀴를 다시 발명할 기회는 좀처럼 없습니다. 기회가 오면 놓치지 말고, 기회가 없으면 만들어야 합니다. 혹시라도 기회가 주어지면 먼저 굴러가는 바퀴를 만들어야 합니다. 더 잘 굴러가는 바퀴를 만드는 것은 그 다음입니다. 굴러가는 바퀴를 만드는 일이 (지금의) 밥값을 하는 일이라면, 더 잘 굴러가는 바퀴를 다시 발명하는 과정은 (미래의) 몸값을 만드는 일입니다.

리팩토링은 언제나 큰 숙제인 것 같다. 당장은 잘 굴러가는 코드지만 프로젝트의 유지보수성을 해쳐 생산성을 낮추고 있는 코드가 존재하지만 다시 만든다해도 이전보다 나으리란 보장도 없다. 리팩토링을 해서 버그가 생기는 경우도 적지 않기 때문이다. 그만큼 어렵게 다가온다. 그러나 리팩토링을 함으로써 저자의 말대로 바퀴를 더 잘 알게 되었으니, 기회가 생겼을 때면 다시 잘 굴러가는 바퀴를 만들고 더 잘 굴러갈 수 있도록 하는 과정은 필요한 것 같다.