essayedit button

메이커의 역할

11 min read|24. 1. 9.

코딩만 하다 보면 조금 더 잘해볼 수 있지 않을까 고민을 하게 된다. 동료들로부터 인정을 받고 싶을 수도 있고 자신의 역량을 높이고 싶다는 이유일 수도 있다. 이번 글에서는 'Frontend Engineer는 엔지니어이기 전에 메이커(Maker)'라는 관점을 공유해보려고 한다.

TL;DR

  • 본인 제품에 관심을 갖고 개발하는 사람
  • 본인 리소스를 소중히 할 수 있는 사람

Table of Contents

  1. Challenge
  2. Output
  3. Sharing
  4. Managing

1. Challenge

함께 제품을 만드는 동료(Product Owner, 기획자, Product Designer, PM, Backend Engieer, Data analytics 등)에게 챌린지 할 수 있어야 하는 메이커다. 크게 3가지 부분에 있어서 판단하고 스스로가 납득할 수 없거나 팀 구성원들이 같은 입장이 아니라면(on the same page) 이야기하여 맞춰갈 수 있어야 한다.

  1. 하려고 하는 작업이 ROI(Return On Investment) 가 타당한 작업인지
    1. 들어가는 비용(cost) 대비 결과물(output)이 명확한지
    2. 유의미한 변화를 만들 것이라 기대되는 작업인지
    3. 스스로 판단하기 어렵다면 전달받은 내용에 설득이 되는지
  2. 해결하고자 하는 문제를 제대로 해결하는 방법인지
    1. 문제가 가진 근본적인 원인을 해결하는 방법인지
    2. 임시 방편으로 해결하고 있진 않은지 → 다시 1번에 대한 이야기
  3. 해결하고자 하는 문제 또는 달성하고자 하는 지표를 싸게 해결하는 방법인지
    1. 문제 해결을 위한 다른 방법은 없는지
    2. 여러 방법 중 가장 싸게 해결하는 방법인지 (기술적인 비용에 대해 알고 있는 전문가는 본인뿐)

2. Output

결국 최종적인 결과물을 만드는 메이커다. 정적인 디자인에 동적인 데이터를 연동하여 제품을 만든다. 잘 만들어진 재료들로 최종 요리를 내놓는 행위와 유사하다고 생각한다. 보기 좋은 요리가 먹기에도 좋듯이.

앞서 이야기 한 1번에 기반하여 제품 개발하되 제품 ‘특성’에 따라 알맞은 방향으로 개발해야 한다. 여러 가지 특성이 있겠지만 대표적인 예로 제품 수명이 있을 수 있다. 수명 주기가 짧은 제품은 변경에 유연하게 만들기 보단 빠르게 개발하는 것이 오히려 이득이라는 것을 알고 확장이 고려되어야 하는 제품은 변경에 유연하도록 만든다. (변경에 유연한 컴포넌트)

요구사항에 따라 상황에 맞는 기술을 선택하고 이를 책임진다. 요구사항을 구현하는 방법은 여러 가지이다. 그 중 '효율적인' 해결 방법을 고민하고 적용하는 책임이 주어진다. 여러 방법 중 가장 싸게 해결하는 방법인지 기술적인 비용에 대해 알고 있는 전문가는 본인뿐이다.

한 가지 더 언급하자면 사용자 경험(UX)을 수호하며 개발해야 한다. 퍼널 전환율을 조금이라도 높이기 위해 클릭률을 조금이라도 더 높이기 위해 안티 패턴을 적용하는 비도덕적인 행동을 지양해야 한다. (프론트엔드의 본질은 UX가 아닐까)

3. Sharing

내 리소스가 소중한 만큼 다른 사람의 리소스도 소중하다. 삽질로 시간을 낭비했다면, 동료가 같은 이유로 시간을 낭비하지 않도록 삽질기를 공유한다. 공유는 여러 형태가 될 수 있다. 코드 리뷰를 통해 지식을 알려줄 수도 있고 간단히 메신저를 통해 경험을 공유해도 된다. 다룰 내용이 많다면 간단한 세션을 준비하. 잘 정리된 내용도 기술자산이 된다. 이렇게 공유하기 위해 정리하면 분명 본인에게 더 도움이 된다. (개발자의 학과 습 참고)

복잡한 문제를 시간을 들여 해결했다면 공통화를 해보자. 동료가 동일한 시간이 소요되지 않도록. 다만 공통화는 다음과 같은 이유로 난이도가 꽤 높은 작업이다.

  1. 공통화 한 코드가 있는지 잘 알 수 있어야 하며
  2. 공통화 한 코드를 다른 사람도 쉽게 가져다 사용할 수 있어야 하며
  3. 실제로 사용할 수 있어야 하기도 한다.

특히 3번은 해결 방법을 확장 가능하게(Scalable) 적용해야 하기 때문에 어렵다. 이렇게 하기 어렵다 보니 공통화를 하기 쉬운 개발 환경도 중요하다. 최근 들어 모노레포로 개발 환경을 구성하는 경우가 많아졌는데 위와 같은 이유 때문이라고 생각한다. 모노레포로 구성된 개발 환경, 개발 문화는 이런 의미에서 유의미하다. 그럼에도 공통 모듈은 기술 자산이 되어 장기적인 생산성에 분명 도움이 된다.

눈에 보이지 않지만 리소스를 갉아먹고 있는 문제를 발견하고 정의하여 해결해야 한다. 방금 소개한 모노레포를 예로 들자면 저장소 크기가 커질수록 CI 속도가 느려진다던가 알게 모르게 비효율이 발생하곤 한다. 이런 공통 부분을 비판적으로 의식하고 문제를 정의하여 해결한다면 팀 생산성과 비용에 많은 도움이 될 수 있다.

4. Self Managing

위에서 언급한 1, 2, 3에 대해 적절한 비율로 나누어 스케쥴링 해야 한다. 아무도 대신 해주지 않는다. 기획자나 PO는 제품이 개발되기만 하면 그만이고 이번 스프린트에 주어진 태스크를 어느 정도 끝낼 수 있다면 더이상 관심사가 아니다. 메이커 스스로 고민해야 하는 영역이다. 그렇다면 이상적인 비율은 어느정도 일까? 경험적으로는 8:2 정도라고 생각한다.

  • 8: 제품 개발에 집중하는 비율 (1+2)
  • 2: 기술적인 고민을 하고 개발 환경에 기여하는 비율(3번) 장기적인 관점에서 봤을 때, 제품을 개발하면서 해결한 문제들을 공유하고 더 복잡한 문제는 함께 해결해 나가는 2번이 10 중 2 비율로 지속적으로 투자되어야 하지 않을까 생각한다.

다만 1년 내내 이상적인 비율이 유지할 수 있다고는 생각하지 않는다. 아무리 기술적으로 뛰어나도 만든 제품이 의미가 없으면 시장 타이밍을 놓치게 되면 팀이 와해될 수도 있기 때문이다. 상황에 맞춰 비율을 조정할 수 있어야 한다. 팀 인원이 늘어날수록 10 중 2 만으로 해결되지 않을 수 있는데, 이 때는 이 일만 담당하는 인원이 필요해지기도 한다.

마무리

엔지니어이기 이전에 제품을 만드는 메이커에게 요구하는 역량에 대한 생각을 정리해봤다. 제품에서 팀으로 팀에서 조직으로 시야가 넓어지는 경험을 하면서 느꼈다. 엔지니어이기 전에 팀원으로써, 제품을 만드는 일원으로써 역량도 중요하다는 것을.

결국 투입되는 리소스 대비 최대 결과물을 만들어 내야 하는데, 경제학에서 의사결정하는 흐름과 비슷하다고 생각했다. 컴퓨터 공학, 소프트웨어 엔지니어링, 경제학이라고 구분지어 놨을 뿐 일을 잘하기 무언가는 경계가 없지 않을까.