실용주의 개발자 01

1장. 실용주의 철학

서문

• 실용주의 프로그래머는

  • 문제와 해법에 접근하는 태도와 방식, 철학에 차이가 있는 프로그래머를 말한다.

• 변화와 관성사이에서 어떻게 균형을 잡을 것인가?

토픽1. 당신의 인생이다.

• 개발자라면 주도적으로 행동이라

• 불평, 불만만으로 끝날 것이 아니라 스스로 쟁취해야한다.

토픽2. 고양이가 내 소스 코드를 삼켰어요

• 책임을 질 수 있어야 한다. 회피하지마라 핑계도 대지마라.

• 어설픈 변명 말고 대안을 제시해라.

개인적으로 아직 주니어지만 프로젝트를 하다보면 핑계를 대는 경우가 종종있다

내 실수에 대해, 내가 무능하게 보일까봐, 난 스스로 내가 괜찮은 개발자라고 스스로 생각하게 한다.

하지만, 진정한 미들급이나 시니어 개발자가 되기 위하여는 내 행동에 책임을 질 수 있어야 한다.

실천

• 잘 모르겠어요 에서 끝나는게 아니라, 알아보겠습니다 로 이어서 말해봐야 한다.

토픽3. 소프트웨어 엔트로피

• 깨진 창문을 내버려 두지 말라

  깨진 창문

  • 작은 무질서를 방치하면 더 큰 범죄로 이어진다.

  • 경미한 깨진 창문 하나를 즉시 수리하고 관리해 공동체 즉, 코드 질서를 유지하는 것이 중요함.

시간이 급해서.. 코드가 엉망이 되는 일은 없어야한다.

시간이 정말 급하다면, 사실 야근을 해서라도 품질을 위해 힘써야한다고 생각한다.

품질과 속도사이에서 조절하는 것도 참 매번 일인 것 같다.

고민

• 창문이 처음 깨진 경우, 목소리를 낼 수 있을까?

  • 상급자의 명령에 따른 결과라면.. 나는 어떻게 할 것인가

솔직히.. 별말 하지 못할 것 같다.. 기본적으로 미움받을 용기가 난 참 없는 것 같다.

누구에게나 무난하고 미움받고 싶지않다는 생각을 전제로 가지고 있기에, 참.. 매번 힘들다.

토픽4. 돌멩이 수프와 삶은 개구리

• 큰 목표를 위해서 작은것에서부터 점진적인 성공을 보여줄 수 있다면, 모두가 힘을 모아 더 큰 결과를 이끌어낼 수 있다.

• 삶은 개구리 예시처럼

  • 서서로 데워지는 물속에서 변화를 감지하지 못하고 .. 삶아진다.

  • 작은 문제가 서서로 쌓여서 프로젝트를 파국으로 몰고가는데.. 이러한 엔트로피 에 무감각해지면 안된다.

  • 늘 주변 상황과 큰 그림 에 주의를 기울여야 한다.

개발하다보면 자꾸 코드에 매몰된다.

내 스타일대로 코드를 짜고, 남들과 소통하기보단 스스로 갇혀있기도하고 지금도 고쳐야하는 습관이지만

저연차때는 더더욱이 그랬다.

개발자는 개발이 전부가 아니다, 내가 정답도 아니고, 개발자는 내 의견을 어떠한 감정도 담지않고 더 좋은 결과를 위해 개진하는 사람이자,

좋은 개발자가 되기 위해서는 주변의 변화에서 기민해져야 한다.

토픽5. 적당히 괜찮은 소프트웨어

• worse is better

  • 단순성과 구현의 용이성은

    • 완벽함과 일관성보다 우선시 되어야 한다.

    • 완벽하지 않아도 단순하고 누구나 이해할 수 있고, 빠르게 배포될 수 있는 시스템이 더 빠르게 채택되고 확산되어 결국 시장을 지배하게 된다.

• 다만, 완벽하지 않아도 된다는 것이지, 불완전한 소프트웨어를 팔아먹으라는 말은 아니다

• 어디까지 완벽하게 할 것인가는 다 우리의 몫이다

  • 적어도 어느정도의 선은 본인이 정하기 나름이다

기능 블로트를 조심해야한다.

• 대표적인 예시로는 MS Office 가 있다

  • 대부분의 사용자들은 기본적인 10% ~ 20% 의 기능만 사용하지만, MS Office 에는 출판기능, 매크로 자동화 등의 복잡한 기능을 가지고 있다.

  • 그래서 시작 속도와 반응속도 가 느려지는 문제가 있다..

유별나게 우리나라 웹사이트도 그런거같음

• 웹사이트도 하나의 기능에 덕지덕지 다른 기능 떄려박고

• 토스나 카톡도 보면 기능이 덕지덕지 나중에는 안쓰는 기능이 검나 많은데 또 그대로 피곤함.

  • 근데 또 이해가 안되는건 아님.. 여러 앱으로 분산시켜놓으면 그런대로 사람들이 더 접근율이 낮아지는 단점이 있긴함.

  • 어차피 백엔드 서버는 다 분리되어 있으니까 뭐 상관은 없겠지

  • 앱 프론트도 결국은 분리되어 있을거고

과도한 미래 대비, 삭제의 부재, Yes-Man 문화 를 조심해야한다.

토픽6. 지식 포트폴리오.

일찍 일어나는 새가 먹이를 잡는다

• 일찍 일어나는 새

  • 원래 의미는 부지런하고 먼저 움직이는 사람이 기회나 이익을 선점하는 것이다.

  • 지식 포트폴리오 에서는

    • 새로운 기술과 지식을 재빨리 습득하고 현장에 적용하는 전문가를 의미

• 일찍 일어나는 벌레

  • 급변하는 기술환경에 대한 냉정한 현실을 알려주는 말이다.

  • 벌레 는 일찍 일어났음에도 불구하고 결국에 일찍 일어난 새 에게 잡히는 희생적 존재

  • 부지런하고 지식을 쌓았음에도 불구하고, 지식 자체가 기한이 다하는 지식 이 되어버린 전문가를 의미

열심히 일하고 노력하는 것은 중요하지만, 무엇을 배워야 할지, 어떻게 배워야 할지 전략 없이 노력만 한다면, 곧 진부화되어 가치를 잃고 새에게 잡힐 위험이 있음.

어떻게 지식 포트폴리오를 현명하게 관리할 수 있을까?

• 단순한 기술 습득 이상으로, 끊임없이 변화하는 세계 속에서 나의 존재 가치를 유지하고 발전시키는 실존적인 노력이 필요하다.

1. 주기적인 투자

• 소량이라고 주기적으로 투자해야한다

  • 학습 을 숙제 가 아니라 미래가치를 위한 휴식/재충전 이라고 생각하자.

복리의 힘 이라고 아시는가?

• 실패는 나침반이다 - 한기용 지음 을 읽다가 나온 단어인데 꽤나 재밌는 표현이라 차용했다.

• 매일 1% 만큼 내가 발전한다는 전제하에서는

  • 1년 37배 발전한 나를 발견할 수 있다.

2. 다각화하라

• 현재 작업 외에도 여러 분야에 대해 학습해야한다.

• 결국 아래에서 리스크 관리와 똑같은 말인 것 같습니다.

3. 리스크 관리

• 중용(The Golden Mean)

  • 보수적인 투자와 고위험 투자사이에 균형이 필요함.

    • 공부를 하더라도 시간투자를

      1. 현재 업무

      2. 새로운 기술

      와 균형을 두도록해라.

4. 싸게 사서 비싸게 팔기

• 새로운 기술이 시장을 점령하기 전에 미리 그 기술을 학습해놓고 이익을 보라는 말인데

• 한국 시장에서 내가 보기엔 golang이 그렇지 않았나 싶다

  • 한국 시장 자체가 워낙에 자바 외의 다른 언어에 배척하는 편이라

• 그래도 주식이나 코인 같은 실시간 서비스에는 golang 이 많이 채용된다고 들었던 것 같다.

5. 검토 및 재조정

• 포트폴리오를 주기적으로 재검토하고 재조정하라.

• 나의 지식을 재검토하라는 말임

  • 뭐 분기나 반기정도로 내가 아는 지식이 진부화된건지..

  • 어떤 지식을 필요로하는지

  • 스스로 반추 하라는 의미이지 않나 싶다.

실천해보기

언어와 환경을 확장해보자.

• 개발자로서 고착화된 사고방식

  • 도그마 에 갇히는 것을 경계라고, 끊임없이 새로운 관점을 수용해 문제 해결 능력을 근본적으로 향상

→ 매년 새로운 언어를 최소 하나는 배우기

• 언어는 단순히 코드를 작성하는 도구가 아니라.

• OOP, 함수형 프로그래밍 등 서로 다른 패러다임을 가진 언어를 배워야 사고 간의 교접 → 새로운 사고의 확장이 가능해짐.

→ 고립되지 마라

• 지식은 사회적 구성물 .. 내가 아는 것이 전부가 아니다.

• 내 지식 을 공동체의 지식 으로 확장..

  • 고립은 도그마 ( 확고한 신념 )를 강화함.

  • 교류는 사고의 유연성을 키움.

전 회사 같은 경우 시니어 개발자분들은 고립되어 계셨음

• 학습된 무기력

  • 반복적으로 통제 불가능한 부정적인 상황 에 노출되는 경우 동물들은 결국에 노력 자체를 포기 하고 수동적인 상태에 머무르게 된다.

• 현 회사에서 항상 이렇게 했기에, 이게 유일한 정답인 듯이..

  • 새로운 환경이나 기술 스택의 장점을 무시하고 과거 방식을 고수하려는 경향이 강했음.

→ 경계를 허물려고 노력

• IDE OS 도구 등을 변경시킴으로

  • 도구에 사고가 지배되지 않도록 하는 훈련을 해야한다.

  • 도구의 기능을 넘어 근본 원리 를 이해해서

    • 변화에 대한 적응력을 키워야 한다고함

요즘은 AI 때문에 코드를 쓸때도 그 코드가 내부적으로 어떻게 동작하는지 모르고 사용하는 경우가 있음.

• AI 라는 도구를 사용할 때 스스로 경계하면서 사용해야한다고 개인적으로 생각

• 코드 작성에 대해 도움을 받더라도 해당 코드가 내부적으로 어떻게 동작하는지 스스로 반추해야한다고 생각함.

균형 있는 지식의 습득

→ 기술 서적 한달에 한권

→ 기술 서적이 아닌 것도 읽기

• 개발자는 코드가 전부가 아니라, 소프트 스킬 이 정말 중요함.

• 논리적인 오류가 아니라 감정적 맥락 이 가장 중요

개발자들이 T 라고 하지만, 정말 찐 T 였으면 개발회사는 다 터져버렸을 것

• 개인적으로 개발 능력도 능력인데 소프트스킬 이 부족한 사람들은 압도적인 능력을 가진 것이 아니라면 평가절하될 가능성도 있다고 봄.

→ 강좌나 세미나 참여

• 시장과 기술 최전선에서 어떤 일이 일어나고 있는지 알아야함.

• 다른 사람이 어떤 경험을 했는지 를 아는 것이 중요함.

  • 해당 커뮤니티의 언어와 문화 를 습득하는 과정을 익혀야함.

비판적인 분석

→ 무지의 인정과 탐구

• 소크라테스

  • 나는 내가 아무것도 모른다는 것을 안다

• 자신의 무지를 인정해야함.

  • 무지를 인정함으로 새로운 지식을 얻을 수 있는 되려 좋은 기회를 가질 수 있음

→ 도그마(맹목적 신념) 와 상업주의 경계

• 정보에 대해 비판적으로 분석해야함

→ Five Whys

• 모든 해결책은 맥락 이 있음.

  • 해결책도 결국 각각의 경우 장, 단점이 존재하는데

  • 해당 해결책에 대해 다음에 어떤 일이 일어날 것인지? , 그 이후에는 어떤 일이 일어날 수 있는지 스스로 생각해야함

• 사고 방안

  1. 왜 배포시에 치명적인 시스템 오류가 발생했나?

     • 원인

       • 결제 시스템의 업데이트로 데드락 발생

  2. 왜 데드락이 발생했나?

     • 원인

       • 결제 시스템 관련 SP 주간 업데이트로 결제 진행중이던 사람들의 트랜잭션이 정상적으로 종료되지 않아 데드락 발생

  3. 왜 결제 시스템관련 SP 를 주간에 업데이트했나?

     • 원인

       • 리더의 판단 오류

  4. 리더는 왜 주간 업데이트로 판단하였나?

     • 원인

       • 실무에 대한 감각 부족 및 새벽근무를 해야했기 때문

       • 배포가 최근에 너무 잦아서 배포에 대한 경각심이 줄어들었기 때문

  5. 왜 배포가 그렇게 잦았나?

     • 원인

       • 매출액의 감소 및 회사 경영진의 압박

토픽7. 소통하라

청중이 이해해야 소통이다.

• 소통의 책임은 청중에게 있는 것이 아니라 나에게 있다.

• 청중을 소통에 참여시켜야 한다.

• 개발적으로는

  • 문서화를 개발 프로세스릐 필수 불가별한 부분을 받아들어야 한다

• 주석을 다는 건 다는건데

  • HOW 가 아니라 Why 를 설명해야한다.

    • 코드가 이미 어떻게 동작하는지 를 보여주기에, 코드의 동작 방식에 대한 주석을 불필요한 중복이다. (DRY, Don`t Repeat Yourself) 에 위반