speed.md

Speed

• 생각의 속도 > 구현의 속도 > 문화의 속도
  • 생각
    • e.g. 비지니스, 아이디어, 기능 구현, bug 오류 인지
  • 구현
    • e.g. 영업망 연락/확충, 실제 구현(코드 뿐만 아니라)
  • 문화
    • e.g. 실패를 보는 시선, 문서화 등 개발문화뿐만 아니라 사내 전반적인 문화
    • 회사에는 개발 조직만 있는 게 아니므로 개발 조직의 특성을 인정하더라도 다른 조직과의 갭이 너무 크면 좋을 건 없음
  • 이 반복의 속도를 높여야 빠른 비지니스 구현 테스트가 가능해지는 듯
  • 당연하게도 생각의 속도를 구현의 속도가 앞설 수 없고, 구현의 속도를 문화의 속도가 앞설 수 없음
  • 하지만 구현의 속도가 빨라지면 생각을 실현하는 속도가 빨라지고, 문화의 속도가 빨라지면 구현을 실현하는 속도도 빨라짐
    • MVP를 구현하는 이유가 바로 이것. 스타트업은 빨리 실행해보고 실패하면 pivot을 해야 하니까 MVP로 최소의 핵심 아이디어만 실행
  • 생각의 폭이 넓으면 그 아래쪽으로는 해야 할 일이 훨씬 더 넓어짐
    • e.g. 생각: 오류 발생 > 구현: bug fix > 문화: test, postmortem등을 통해 어떻게 유사한 오류를 방지할 것인가
    • e.g. 생각: 신사업 > 구현: 작게는 새로운 component추가 크게는 완전히 새로운 전체 시스템 구현 > 문화: history project 관리부터...
  • 즉 생각, 구현, 문화는 순서대로 폭이 넓어지며, 위에 있는 단계를 뒷받침하는 토대가 됨
• project 방법론
  • agile: 생각 -> 코드 반복의 속도 향상. 그래서 fail fast
  • waterfall: 생각 -> 코드 -> 문화의 구현에 집중
• 어느 정도는 생각 -> 코드 구간의 반복만으로 비지니스를 실현 가능하지만 일정 정도가 넘어서면 문화가 뒷받침 되지 않으면 무너지는 듯
  • 물론 최고의 회사들도 문화쪽은 앞의 두 가지에 비해 중요도가 떨어지는 듯 하지만(예를 들어 문서화 부족)
  • 그렇다고 해도 다른 회사들 보다는 더 많이 신경을 씀(예를 들어 engineering blog를 운영하고 최소한 여기 나가는 문서들은 매우 좋음)
  • 실패를 용인하는 문화가 있어야 도전이 쉬워짐
  • 개발문화가 뒷받침 되어야 실패를 할 여지가 생김
    • 현재 동작하는 product와 연관이 있는 코드를 변경하더라도 현재 business에 피해를 주지 않고 테스트 가능
  • 좋은 개발 문화가 있어야 개발자들이 흥미를 가짐
    • 개발자들은 business 자체에 대해 흥미를 갖는 경우는 기술관련이 아니면 드묾
    • 구현은 open source가 아니면 어떻게 된 건지 알기 어려움. 기술 stack 정도나 흥미를 갖게 할 수 있음
    • 좋은 개발 문화는 개발자 성장을 위한 뒷받침이 된다는 점에서 흥미 요소가 될 수 있음