역할이 규칙이 아닌 이유 (새 탭에서 열림)

제품 개발이 협업 중심으로 바뀌면서 엔지니어의 역할은 정해진 요구사항을 구현하는 데서 벗어나, 무엇을 만들지까지 함께 결정하는 방향으로 확장되고 있다. 하지만 협업과 피드백을 항상 늘리는 것이 정답은 아니며, 다양한 의견을 탐색하는 단계와 결정을 내리고 추진하는 단계 사이의 균형이 중요하다. Figma는 역할을 고정된 규칙으로 보지 않고, 초기부터 폭넓게 협업하되 마일스톤을 통해 적절한 시점에 수렴하는 방식을 택한다.

엔지니어 역할의 확장

• 웹 기술의 발전과 Google Docs 같은 협업 도구의 확산, 원격·하이브리드 근무의 증가로 제품은 점점 “멀티플레이어 기본값”이 되었다.
• 제품 개발은 더 이상 디자인에서 시작해 엔지니어링으로 끝나는 선형적인 과정이 아니다.
• 엔지니어는 단순히 구현 방법(how)을 결정하는 사람이 아니라, 고객 피드백과 제품·디자인 동료의 의견을 바탕으로 만들 대상(what)도 함께 정의한다.
• 따라서 직무의 경계를 엄격한 규칙으로 보기보다, 필요한 순간 서로의 영역을 넘나드는 협업 방식이 요구된다.

협업과 독립성 사이의 균형

• 다른 사람의 지식을 활용하는 것과, 방향 없이 계속 논의만 반복하는 것은 다르다.
• 모든 작업에서 항상 최대한 많은 사람의 피드백을 받으면 품질이 높아질 것 같지만, 오히려 결정이 늦어지고 프로젝트가 제자리걸음할 수 있다.
• 독립적으로 집중해야 하는 시기와 적극적으로 다른 팀을 끌어들여야 하는 시기는 작업마다 다르다.
• 적절한 균형은 조직 문화, 제품의 특성, 팀이 최적화하려는 목표에 따라 달라진다.

초기 아이디어를 공개하는 방식

• 새로운 업무를 시작할 때는 가능한 한 이른 시점부터 다양한 관점을 반영한다.
• 엔지니어는 완성된 설계가 아니라 초기의 생각과 가설을 문서로 작성해야 한다.
• 문서는 “완성 후 검토”를 위한 산출물이 아니라, 작업 중인 상태에서 피드백을 받기 위한 협업 도구다.
• 대부분의 프로젝트에 초기 생각을 기록하는 문서가 존재하지만, 각 팀이 바쁜 상황에서도 빠르게 피드백을 주고받을 수 있는 구조가 필요하다.

엔지니어링 크리트: 승인보다 피드백

• Figma는 디자인·엔지니어링 조직 간 정기적인 엔지니어링 크리트(crit)를 운영한다.
• 크리트의 목적은 다음과 같다.
  • 기술 설계를 초기에 공유한다.
  • 다른 팀으로부터 자주 피드백을 받는다.
  • 전문적인 기술 지원과 문제 제기를 얻는다.
• 크리트는 승인 회의가 아니다.
  • 회의에서 최종 결정을 내리거나 작업을 확정하지 않는다.
  • 작업 중인 상태(WIP)를 전제로 문제를 지적한다.
  • 설계 자체가 충분히 발전해 별도의 승인을 필요로 하지 않도록 돕는다.
• Figma는 FigJam을 사용해 실시간으로 참여하고 의견을 시각적으로 공유한다.

너무 많은 의견이 만드는 정체

• 다양한 의견은 유용하지만, 입력이 지나치게 많거나 서로 충돌하면 프로젝트가 방향을 잃을 수 있다.
• 특히 가격 정책처럼 불확실성과 중요한 트레이드오프가 많은 문제에서는 아이디어가 계속 추가되면서 결정을 내리지 못할 위험이 크다.
• 탐색적이고 생성적인 논의만 계속하면 프로젝트가 앞으로 나아가지 못한다.
• 협업의 목표는 모든 의견을 반영하는 것이 아니라, 더 나은 결정을 내릴 수 있을 만큼 설계를 발전시키는 데 있다.

마일스톤을 통한 수렴

• Figma는 프로젝트를 여러 마일스톤으로 나누어 탐색과 실행의 시점을 구분한다.
• 마일스톤을 명확히 정의하고 공유하면 다음과 같은 효과가 있다.
  • 이해관계자의 기대치를 관리할 수 있다.
  • 현재 단계에서 무엇을 결정해야 하는지 분명해진다.
  • 계속 확장하기보다 수렴해야 할 시점을 알 수 있다.
• 프로젝트가 진전되려면 다양한 가능성을 열어두는 단계와, 하나의 방향을 선택해 추진하는 단계가 모두 필요하다.
• 추진력(momentum)이 유지되면 목표에 가까워지고 있다는 감각을 얻지만, 추진력을 잃으면 프로젝트의 방향과 목적 자체를 다시 의심하게 된다.

실용적인 적용

• 초기 설계와 가설을 완성되기 전에 문서로 공유한다.
• 피드백 회의는 승인 절차가 아니라 문제를 조기에 발견하는 자리로 운영한다.
• 모든 의견을 반영하려 하지 말고, 마일스톤마다 탐색을 멈추고 결정을 내릴 시점을 명확히 한다.
• 역할과 책임을 고정된 경계로 보지 않되, 최종적으로는 누가 어떤 결정을 내리고 실행할지 분명히 해야 한다.