이펙티브 엔지니어를 읽고...

교보문고 돌아다니다가 눈에 띄여서 구입했고 ... 생각보다 책이 아주 얇다 .. 그것이 선택이 이유다 ! 솔직하게 얇아서 샀다!! 

99% 진심이였고 막상 펼쳐놓고보니 결론부터 말하면 다 알고있는 내용이고 다 너무 당연한 내용들이였다. 그럼에도 불구하고 이책을 소장하기로 마음 먹은것은 아는것과 그것을 실천하는것은 엄연히 다르다는 사실이라는 것과 내가 무심코 지나치고 잊는 것과 잊지 않는것은 아주 많은 차이의 결과를 도출시키는것이란것을 알기에 소장하기로했다. 

 원래는 책을 어렸을때부터 닥치는 대로 많이 읽었지만 ... 언젠가 부터는 남들과 비슷한 핑계로 1년에 1~2권도 간신히 읽는 편이다. 그 흔한 만화책 조차도 안본지 몇년은 된거 같다. 디지털화된 생활에 유튜브나 숏폼 을 통해 지식을 손가락으로 취득하는 게 익숙해졌지만 아직 나는 침뭍혀서 종이를 넘기는게 좋고 뱡항제와 종이 그리고 잉크냄새가 묘하게 섞여서 나는 서점의 냄새가 너무 좋다. 

 나는 개발자 다 

 개발자라는 종족(?)이 어떤지는 나 스스로도 잘안다. 처음부터 끝까지 나는 비효율적인것을 본능적으로 거부하는 편이다. 아마 나에게 눈알붙이기 알바나 편지봉투 붙이기를 시킨다면 최소 1시간동안은 이걸 어떻게하면 빠르고 쉽게 할수있을까 하는 생각을 하다가 일을 못할것이다.  개발자라는 직업은 효율적인 것을 지향하고 그것을 세상에 구현하기 위한 노력이 필요 하다고 생각한다. 그래서 난 이책에 나오는 나와 다른 나보다 나은사람들은 어떤 생각을 하는지가 궁금했고 첫장을 펴자 마자 이게 뭐지란 생각을 했다. 

레버리지가 높은 활동에 집중 하라 

 모든 행동은 레버리지가 높이는 방향으로 행동하라고 한다. 결코 어려운 것이 아니다. 쉽게 말하면 쉬운일을 오래 하지말고 그 시간을 좀더 높은 코스트를 취할 수 있는 일 위주로 하란 이야기다. 

 흔히 영양가 없는 일 말고 좀 영양가 있는 일을해라 ! 라고 하는 그 의미다. 쉽지만 어려운 단어다 사람은 본능적으로 어려움을 피한다. 쉬운게 당연히 좋고 쉬운일을 오래(?) 한다면 그만큼 일한티 내기 좋지 않을까 ? 처음부터 고민스러운 단어다  저자는 어려운일에 좀더 시간을 투자해서 본인의 레버리지를 높여 자신의 활동의 가치를 높이기를 권장한다. 그리고 레버리지르를 늘릴수 있는 세가지 방법에 대해 가이드를 한다. 투자시간 줄이기 , 생산량 늘리기 , 레버리지 높은 활동으로 전환하기 .. 

   "레버리지 = 생산량 / 투자시간"

학습을 위해 최적화 하라

  너무 중요한 이야기만 마인드셋이 필요하다 배고자하는 의지 발전하겠다는 의지 ... 그리고 항상 배우겠다는 마음가짐과 행동으로 옴길수 있는 행동력. 아직은 다행이 나에게는 이런부분들이 남아 있고 항상 이런 부분들을 내가 업무에 입할때 그리고 누군가에게 도움을 줄때 강조하는 부분이다. 이게 최적화라는 키워드와 무슨 관계에 있냐고 한다면 , 최적화를 하기위해서 아주 기본적으로 갖춰야할 요소이다. 내가 성장해야만 최적화를 할수있고 아는만큼 최적화가 가능 하다. 책에서 말하는 중요한 중요 포인트는 성장하는 마인드셋 과 그것을 바탕으로 자신의 학습률을 좀더 투자 하는 노력을 하라는것이다. 그런 내용들이 서술 되있고 흥미로웠던 것은 학습에 도움이 되는 근무환경을 찾아 보라는 부분이다. 결국 마인드셋을 가져야하는 것에 대한 동기부여중 본인 스스로 자각하여 가지는것이 좋겠지만 근무환경이 강제하는 동기부여만큼 확실한건 없긴한거 같다. 받았으면 그만큼 해야하니까 말이다. 키워드 만큼은 최적화라고 했지만 결국 내가 본 결론은 개발자 라면 항상 배워야 한다는것 같다. 

"일하면서 배우는거지 가장 좋은 동기부여는 돈이다."
"이정도면 됬다고 공부 하지 않는 순간부터 개발자가 아니다"

우선순위를 정기적으로 점검 하라

 이부분 만큼은 내가 그동안 간과 한 부분인것 같다. 점검을 한다.. 여기선 점검이라 이야기했지만 이 챕터에서 말하고자 하는건 나의 해석으로는 결국 집중과 관심인것 같다. 앞서 나온 내용들과 종합적으로 고민해보면 높은 레버리지의 활동에 집중하고 항상 배워나가는것이 중요하다는것인다. 결국은 내가 그일에 대해 집중을 해서 레버리지를 높이고 있는지 시간을 헛되이 쓰고 있진 않은지 그리고 효율적으로 해나가는지를 관심을 지속적으로 가져가는지가 중요한게 아닌가라는 느낌을 받았다. 아무리 레버리지를 높이고 배운다고 하더라도 그 방향이 옳지만 과정이 효율적이지 못하고 지속적이지 못하다면 그것 만큼 안하니만 못한 것 없는것 같다. 보통 앞에 두단계만 시도하고 다한거 마냥 겉멋이 들지 않도록 조심해야할거 같다. 

반복 속도에 투자하라 

 이부분은 정말 개발자 스러운 부분인것 같다. 반복은 개발자에게는 숙명적 단어인것같다. 반복은 개발자에게는 비효율의 상징성을 가진 단어이고 그 비효율을 제거하는게 개발자의 숙명이라고 생각한다. 이 챕터는 결국엔 시간이란 키워드로 정리가 될거 같다. 빠르게 대응하고 배우고 움직이며 시간을 최대한 효율적으로 쓰는것이 중요하다는 이야기를 저자는 하고 싶었던거 같다. 

 디버깅과 검증과정을 최대한 효율적으로 만들고 내가 프로그래밍을 하는 환경 조차도 최적화하여 시간을 단축시키고 내가 시간을 절약할수있다면 모든것들을 폭넓게 고민해보는것. 여태까지 당연하게 했던것들 그리고 내가 당연하게 했던것들이 내가 본능적으로 인지하고 있던것도 있었지만 반대로 내가 그런것 조차 목적을 모르고 실행하고 있었던것들이 있었다. 

 개발자면 당연히 이래야지! 라는 말은 하면 내가 정말로 엔지니어로서 제대로된 시간을 사용하고 있는지 놓치고있는게 있는지 확인하게 됬다. 

"만약 수동으로 두 번 이상으로 해야 하는 일이 생기면 세 번째에는 도구를 작성하라"

개선하려는 사항을 측정 하라

 지표라는 말을 썩 좋아하진 않는다. 수치화 하고 도식화 하는것들이 항상 정확할수 없다고 생각하고 이것은 인간이 만들었지만 가장 인간에게 안맞는 도구라고 생각한다. 하지만 개발자들은 0 과 1의 세상속에서 사는 존재들이다 보니 이런생각을 할수도 있겠다는 생각이 들긴 했지만 내가 이 책에서 저자에 생각중 고개를 갸웃하게 만든 챕터이다. 지표의 함정은 모든것을 수치화 하려다가 숫자의 저주에 빠진가는것이다. 실제로 수치화 할수 없는것들이 있고 그런것들은 결국엔 내가 낸 수치의 치명적인 객관성 상실을 초래하는 경우를 많이 봤다. 여기서 말하는 지표는 성과라기 보단 내가 지금 하는 행동과 현재 상황을 파악하기 위한 지표 라고 생각했다. 이렇게 수치화가 가능하고 불측정한 요소가 없는 수준으로 측정을 잘해낼수 있다면 그것또한 좋은 요소로 작용할거 같다. 책에서는 이것을 핵심지표라고 칭하고 있다. 나만의 핵심지표를 찾아 낼수있다면 나에대해서 객관적 측정이 가능하지 않을까 ?  

아이디어는 일찍 그리고 자주 검증하라 

 이 챕터가 의외로 내 사고에 잘 편입되지 않는 부분이였다. 내가 정말 잘한건지 맞는건지 검증하기 위해 A/B 테스트를 이야기하고 독선에 빠지는것을 경우하는데 좀 여러가지로 나한테는 이해가 잘 되지 않는 부분이였다. 그래서 내가 생각하게 맞는지를 쉬지않고 의심하고 피드백 받고 그 피드백이 좀더 좋은 방향으로 흘러갈수 있도록 기준을 세우고 움직이라는 이야기라고 이해하고 넘어 가기로 했다. A/B 테스트에 않좋은 기억이 너무 많았나 보다 .

 

프로젝트 추정 기술을 향상 시켜라

 이랬으면 .. 참 좋겠다.. 라는 혼잣말이 나왔다. 정확한 추정치와 미지의 변수까지 고려하여 프로젝트를 진행하면 얼마나 좋을까 ? 그리고 구체적이고 측정하기도 좋고 이슈도 잘컨트롤 되고 ... 이 얼마나 이상적인 이야기인가. 단 한번도 정확한 추정치를 낸경우를 보지 못했고 미지의 변수를 고려 해서 한다해도 지나가다 떨어지는 야자수에 맞는 확률 보다 더 많은 미스테리한 일들이 벌어 지는게 프로젝트였다. 저자는 이런것들을 잘 고려하라고 한다. 

 학교에서 소프트웨어공학을 배울때 들었던 말중 아직도 기억하는건 "고객은 무지하다" 였다. 고객을 비하하는것이 아니라 고객은 자신이 원하는것을 잘 모르거나 잘 정리 하지 못한다는 말을 빗댄 말이였다. 고객도 모르는것을 제 3자가 구체적으로 목표를 잡을수 있나 ? 라는 .. 생각을 항상했고 측정가능한 마일스톤이라는것은 아무짝에 쓸모 없는.. 조만간 다른 무수히 많은 v1.2..1.3..1.4.. 에 밀려 휴지통에 들어갈 엑셀파일중에 하나 일뿐이였다.  이때 알았다. 저자가 한국사람이 아니란걸 저자가 이 나라에서 프로젝트를 해보고 이 챕터를 다시써보라고 하면 어떻게 쓸지가 좀 궁금해 졌다. 내용은 당연하고 최대한 저런것들을 준수하려고 노력해야하지만 될까... ? 이 곳에서 ? 

장기적인 가치를 구축하라

 

  나름 많은 회사들을 다니면서 이부분들이 결여된 곳들을 아주 많이 보았다. 코드를 리뷰하고 문제를 추상화 하여 해결하고 자동 테스트스를 수행하여 코드의 커버리지를 유지하고 가장 중요한건 기술부채를 관리하는 일련의 행위들... 

 참 많은 곳들에 비슷한 형태의 부정적 피드백을 많이 받았다. 도입도 힘들고 막상 도입한다고해서 단기적으로 성과가 나오지 않는다. 책에서 괜히 장기적인 가치라고 칭하는것이 아니다. 장기적  투자와 관심이 필요하고 한사람이 아닌 여러사람들의 동의와 참여가 지속되지 않는한 쉽게 되지 않는 부분이다. 하더라도 형식적이나 관행처럼 할경우가 대다수였고 결국엔 가치를 쌓기위한 행동이 업무의 방해요소가 되고 가치는 쌓이지 않고 참여자도 지치는 상황이 빈번하게 일어났던거 같다. 

 아마 비개발자들 눈에는 일도 바빠죽겠는데 뭐하는것인지 싶을수도 있고 이해도 안가고 굳이 저렇게 해야하는지 그리고 비효율적이라고 느낄수 밖에 없는 개발자들만의 세계관중 하나인것 같다. 결국 빅테크라는 기업들도 오래전부터 저런 것들을 꾸준히하려고 노력했고 결국엔 그렇게 쌓인 가치가 오랬동안 누적되어 빅테크 라는 결과를 그리고 남들입에 저긴 빅테크니까! 라는 말이 나오는 결과를 냈다고 생각한다. 돈이 많아서 투자해야만 하거나 정말 엄청난 능력을 개발자들이 주도해야만 되는게 아닌것 같다. 

 결국은, 장기적 가치를 언젠가는 우리도 모르게 쌓여 빛이 날수 있는 가치를 쌓을수 있는 행위를 하려는 의지 유무에 따라 빅테크라는 거창한 닉네임을 가질수 있는게 아닌가 라는 생각을 했다. 개발자라고 저런 코드리뷰나 테스트자동화를 당연시 여기는분들만 있는게 아니다 여러명의 개발자분들을 봤을 때 개발자도 저런것은 싫어하시는분들도 상당수 있으시다. 하지만 우리가 장기적 가치를 쌓기 위해서 가장 무서운 가치를 자동으로 하락 시키는 요소는 결국 기술부채라고 생각한다. 기술부채를 상환할수있다면 이런부분들을 좀더 오픈된 입장에서 싫어할것만 아니라 다시한번 생각해보는것도 좋지 않을까 싶다.  당장 눈앞에 안보이는것이 다는 아닌거 같다. 

" 그런건 빅테크 기업이나 하는거야 "
" 우린 그런거 할시간 없어 그럴 시간에 코드나 짜 " 
" 좋은건 알지 근데 그거 할 여력이 되 ?"
" 타부서에서 일처리 늦는다고 빨리해달라고 하는데 이번엔 그냥 넘어가자 "

 

운영부담을 최소화 하라

 내가 가장 잘하고 싶고 잘 지키고 싶고 잘 해보고 싶은 내용들이 많은 부분이였다. 운영은 단순하게 하라는 이야기는 내가 종종 입에 담는 이야기다 언젠가 부터 거대하고 복잡하고 모든 비지니스를 다 포함한 완벽한 시스템들을 만들고자 했는데 그게 과연 답인가라는 생각을 몇년전 부터 하기 시작했다 MSA 라는 아키텍처를 공부하면서 점점 단순화에 대해서 관심을 가지게 됬고 그러다보니 오히려 객체지향에 유레카를 외치는 순간이 종종 오곤 한다. 내용은 내입장에선 평이했다. 일괄처리에 대한 멱등성을 위지하고 반족적인것들은 전부 자동화하고 신속하게 대응가능하며 복구도 쉽게 만들어야 한다! 이건 그냥 모든 개발자들이 인지 하고있는 부분들이라고 생각한다. 

 하지만 단순하게 운영은 과연 다들 그렇게 생각할까 ? 단편적으로 비교적 최근이지만 아무 비효율적으로 아주 복잡한 프로세스로 시스템을 운영하시는 분을 만났고 대화를 나누면서 "이런게 운영의 묘라고하죠 " 라는 말에 충격아닌 충격을 적잖히 받았다. 비지니스가 복잡하니까 당연히 시스템도 복잡하죠 라는 근거에서 나온 이야기였는데 순간 초심으로 돌아간 기분이였다. 책에서도 말한다 단순하게 운영하라고 하지만 현실은 시스템이 복잡 할 수 밖에 없다. 거기서 약간의 충격을 받았다. 여태껏 당연하게 비지니스를 받아서 그걸 그대로 100% 녹여서 시스템화 하는것을 당연하게 생각했는데 결국엔 그렇게 할경우 어쩔수없이 로직을 복잡하게 짤수 밖에 없고 구조도 복잡하게 구성하고 데이터베이스 테이블 조차 수십 수백개를 만들수 밖에 없다. 근데 그걸 왜 당연하게 생각했고 그대로 할생각을 했을까 ? 

 DDD , 객체지향 , EDA , MSA ... 이런애들이 말하는것은 결국에 저런 비지니스를 구현할때 그대로 구현은 해주되 개발자들이 운영하기 좋은 형태를 가져가기 위한 방법들이고 그렇게 많이 공부하고 보았지만 복잡한것을 단순화하는 방법들이였구나라는 생각이 들었다. 물론 저방법들을 사용하는게 쉽지 않고 막상 해보면 단순하진 않다 하지만 해왔던 방법보다야 아직까진 나은 방향을 보여주기 때문에 사용하지 않을까 라는 생각이 들었다. 그저 읽으면서 생각한거다 보니 내 생각에는 무수한 허점들이 있을것이고 나는 이책을 덮고 난뒤에 한동안 많은 고민을 하고 정리를 해야할 필요가 있어 보였다. 

Simple is Best ?!

 

팀의 성장에 투자하라  

 왜 이부분이 마지막 챕터에 나왔을까 그리고 저자는 어떤생각이 들어서 앞선 모든 내용은 개인에 대한 이야기였는데 갑자기 팀에 대한 이야기를 할까 한참을 고민했다. 인상 깊었던건 채용은 리더만의 책임이 아니라 모두가 같이 책임져야하는 주장이였다. 나와 친분이 있으신 CTO 님께서 나에게 해주신 충고중 아직도 기억하는건 아래와 같은 이야기다.

 "너가 소속되고 싶은 조직을 고를땐 그 조직의 리더를 잘 보고 선택해"

처음엔 몰랐지만 지금은 안다. 결국 그 조직원을 구성하는 권하는 그 조직의 리더가 가지고있고 리더의 능력이 좋을수록 그 리더의 눈높이 맞는 조직원 과 팀원들이 뽑힌다는것을 나도 리더라는것을 하면서 느꼈다. 그래서 내가 처음 팀리더를 맡았을땐 정말 그 누구보다 더 공부를 많이 하고 더 많이 노력했었던거 같다. 그리고 그 리더의 능력중 하나는 저자의견에 절대 공감하는 부분이 바로 온보딩이다. 

 온보딩이란 결국엔 새로운 팀원이 제대로된 능력을 발휘하기 위한 적응과 환경을 만들어주는게 목적인데 이게 리더의 능력이라고 생각한다. 생각보다 우리나라의 회사에 개발팀장들은 온보딩에 대해서 잘 생각하지 못하거나 인사팀이 하는거지뭐라는 식의 가벼운 생각으로 접근하는경우가 많은것 같다. 그저 멘토 하나를 정해주고 그사람한테 맡기면 된다고 생각하는데 난 그것만큼 최악의 온보딩은 없는것 같다. 누가봐도 훌륭하다는 온보딩 절차를 만들고 그것을 모든 팀원들에게 공유하고 결국 팀원들이 모두 책임을 나눠 들고 온보딩에 참여하는것 만큼 좋은 구조는 없는것 같다. 

 그리고 이런 것들이 시작으로 좋은 엔지니어링, 개발문화가 생길수있다고 본다. 책임을 나누고 서로 온보딩을 통해서 조직문화를 만들어가고 개발문화를 만들어가는 환경의 회사들은 경험적으로 아주 긍정적인 집단지성들이 많이 생기는 걸 보았고 경험도 했다. 올바른 집단지성이 얼마나 회사에 많은 도움이 되는지는 꼭 경험 해보면 좋은것 같다. 

 

저자는 구글에서 검색품질 개발자로 일했던 사람이라고한다. 그리고 그다음행적을 보면 엔지니어링 조직문화를 만드는것에 대해 굉장한 관심을 가지고 이런 글들을 다수 타임즈나 포브스 같은곳에 기고 했던거 같다. 그래서 그런지 일단 우리나라랑 안맞는 것들도 좀 있다. 하지만 우리나라에도 이런 문화를 만들고자하는 분들이 있고  그중 많진 않지만 유명하신 몇분들과 이야기를 해보았고 그분들도 결국엔 책에 나온 이야기의 대부분을 비슷하게 이야기해 주시곤 했다.

 현실적으로 이런것들을 하려면 내가 적어도 한조직의 리더가 되야 해볼수있는 만들수 있는 문화고 결국 대부분은 나스스로 해야 하는 부분들 같다.  내가 본 개발중 50:50 정도로 굳이 이런걸 해야되 ? 라는 분들과 과하다 할정도로 테스크코드에 집착할 정도로 잘 해보고 싶은 분들이 있던거 같다. 개취는 인정하자 ! 적어도 나는 저런것들을 최대한 지키고 싶고 옳다고 믿는 사람이기에 딴사람은 모르겠고 본인이나 잘해볼 생각이 들었다. 

 습관은 사람이 가진 장점중 하나라고 생각한다. 습관는 들이기 쉽지 않지만 막상 습관이 생긴다면 그것보다 행동으로 옴기기 쉬운 것이 없다.간만에 나 스스로를 돌아보는 책을 만났고 내가 지금까지 잘해온것들 그리고 잠시 내려놓은 것들을 확인할수 있었다. 아직 습관을 만들 힘이 있기에 다시 한번 좋은 습관을 만들어 보려고 한다. 습관이 지배하는 내가 좀더 나은 사람이 되기를 ....