목차


히어로를 채용하고 잡부를 만드는 스타트업

포스트 링크

사람을 기반으로하는 스타트업에서 능력 있는 인재를 뽑은 다음에 팀으로 만드는 것에 실패하는 경우들에 대해 이야기한다. 문제를 해결할 수 있는 능력이 있는 사람은 누구나 히어로이고 그 사람을 뽑는 것은 일반적으로 다른 히어로가 나가는 것과 맞물리게 된다. 그러나 이 히어로가 나간 자리를 다시 채우는 경우는 없고, 그러면 이전의 사람이 했던 일들 중에서 다른 사람이 할 수 있는 일들이 떠넘겨지게 된다. 즉 히어로가 잡부가 되는 것이다.

이를 방지하기 위해서 해당 포스트에서 제시하는 것은, 히어로가 퇴사 카드를 꺼내들기 전에 먼저 팀을 만들고 그가 불만이 있을 법한 사항들을 개선해주자는 것이다. 퇴사 카드를 꺼내든 이후에 연봉 협상과 같은 협상책을 제시하는 것은 이미 늦은 것이다. 이를 위해 할 수 있을 법한 일 들로는 다음과 같은 것을 제시한다.

  1. 정기적인 개인면담
  2. 개인이 처한 상황에 대해 회사가 해줄 수 있는 창구마련
  3. 선심성 발행이 아닌 진심을 담은 회사 히어로서의 성과급 제도 발행 및 적용
  4. 외부 리뷰서비스나 커뮤니티의 지속적인 상황파악을 통한 개선점 도출 및 지속적인 피드백
  5. 히어로를 관리하는 관리자의 역량을 점검

그리고 최종적으로 남은 사람들에 대해서도 배려해달라는 이야기로, 요 근래 스타트업에 지원하면서 가져야 할 마음가짐에 대해 생각해보는 글이 됐다.


루브 골드버그 장치와 같은 지나친 자동화를 경계하자

포스트 링크

루브 골드버그 장치라는 보이기는 거창하나 하는 일은 아주 단순한 재미만을 추구하는 연쇄 반응 기계 만화의 비유를 통해 소프트웨어 산업에서 자동화를 할 때 주의해야 할 점들에 대해 이야기한다. 루브 골드버그 장치는 매우 복잡한 구조를 가지고 있지만, 그 구조를 이해하면 그것이 하는 일은 매우 단순하고 사람이 직접 하는 것보다 더 복잡하고 비효율적일 수 있다. 이처럼 소프트웨어 산업에서도 자동화를 할 때 자동화를 이룰 때 하는 이유와 그것이 하는 일이 실제로 가져다 주는 이득이 무엇인지를 잘 생각해야한다는 내용을 담고 있다.

최근 오픈소스 프로젝트를 참가해보면서 소규모 프로젝트들에서조차 pre-commit과 같은 자동화 도구에 지나치게 많은 hook을 사용하고 있다고 느껴지는 지점들이 있었다. 처음에는 이것들이 굉장히 멋있고 개발에 도움이 된다고 생각했지만, 해당 장치들을 세팅할 시간에 실제로 코드를 작성하는 것이 낫겠다는 생각도 들었고 동시에 이들에 맞추어 코드를 수정하는 시간들이 코드의 품질에 도움이 되는 것인지에 대해 의문이 생기는 시점이었다. 이러한 부분들에 대한 경계 및 정도를 잘 판단하는 것이 중요하다는 것을 다시 한 번 느끼게 되었다.


Golang: Improving Your Go Project with Pre-Commit Hooks

포스트 링크

그럼에도 불구하고 실제로 이들을 사용해보는 경험은 어느 정도 규모가 이미 자리잡은 시스템이 필요한 프로젝트에서는 도입이 필요하다고 생각 한다. 내 채팅 어플리케이션용 api 서버 역시 개발이 약 3개월차가 되면서 작성한 line의 수가 12000줄을 넘어가고 지운 것이 6000줄이 될 정도 로 양이 많아지고 있다. 이러한 상황에서 코드의 품질을 유지해야 개발 속도를 높일 수 있을 것이라 생각해서 pre-commit을 도입하게 됐다.

다만 이를 동시에 containerization하는 IaC 역시도 도입하려는 생각을 원래는 하고 있었는데, 그럴 시간에 그냥 개발을 하는 것이 더 나을 것이라는 생각이 들었다. 어차피 내가 다른 개발 환경에서 작업할 일도 없고, 다른 사람과 협업할 일도 없을 가능성이 높은 상황인 프로젝트 이니까.


2024-05-05
다음 글: 5월 2주차 포스트 → 카테고리로 돌아가기 ↩