INFCON 2023 - 불확실한 미래에는 어설픈 추상화/공통화 보다는 삭제하기 쉬운 중복이 낫다 (feat. 이동욱 개발자님)
현재 Splab에 재직하면서 가장 큰 고민은 조직 구조이다.
거창한 용어라 그렇지, 작고 귀여운 개발팀의 구조를 효과적으로 구성하고 싶은 것뿐이다.
(우리 팀과 상대적으로) 규모 있는 인프런은 Part별 포지션을 Cell 조직에 골고루 분배했다.
Cell 단위도 포지션별 인원도 충족되지 않은 우리 개발팀을 효과적으로 구조화할 수는 없을까?
사실 우리 팀(회사)의 현실은 모든 조직의 전문가들이 기획 - 개발 - 디자인을 의논한다.
개발자들은 항상 디자인 미팅에 참여하고, 백엔드 개발자인 나는 항상 user flow를 그리며 서비스를 명세한다.
솔직히 말해서 인프런의 조직구조를 보고 부러웠다.
각자의 Part 목표와 조직 목표를 나누어서 고민할 수 있다는 것.
누구나 개인적인 커리어 관점 욕심으로는 당연히 Part 목표를 성장시키고 싶을 것이다.
그런데 과연 Part 목표가 조직 목표 없이 가능할 것이냐?
당연히 안 된다.
우리 개발팀은 항상 클로징 된 딜에 맞춰 타임라인을 수정한다.
고객의 입에서 나온 의견은 highest VoC로 등록한다.
성장 로켓에 탑승한 서비스는 운명처럼 비즈니스 속도를 높여야 한다.
그래서 개발자가 뭘 어떻게 해야 하는데?
효과적인 구조화는 우리 팀에서 채택한 효과적인 커뮤니케이션 구조를 따르면 된다.
개발팀뿐만 아니라 어느 Part에서든, 우리가 소통하는 방식을 따라 설계한다.
어려운 말처럼 썼지만 간단하다.
어설프게 불확실한 미래를 위한 추상적인 가설을 구상하기보다는,
현재의 상황과 리소스에 맞춰 우리 팀만의 법칙을 만드는 것이다.
인프런에 좋은 DevOps 4분이 join 하여, pulumi로 각 Cell의 집중도를 높인 것처럼.
설계에 경험 있는 백엔드 개발자인 내가 user flow와 서버 아키텍처를 검토하고,
UX에 경험 있는 프론트 개발자 Leo가 디자인과 사용성을 검토하면 된다.
결론은 누군가 제시하는 Best Practice를 따라 할 필요 없다는 것이다.
우리가 try 하는 것을 Best가 되도록 Easy and Fast 하게 해 보면 된다.