요즘과 같이 코드가 저렴한 때도 없는 듯 하다. 이제는 프로그래머가 아니더라도 누구나 자신이 원하는 아이디어를 앱으로 표현할 수 있다. 그렇다면 당연히 제품의 개발 속도가 빨라져야 하지 않는가? 그러나 실무에 임하다 보면 기대와 현실 사이에 느껴지는 간극이 있다.
회사의 파운더로 임할 때에는 개발 속도가 답답하게 느껴질 때가 많았다. 시도해 보고 싶은 것들은 많았고, 시장은 빠르게 움직이고 있었기 때문이다. 그런데 다른 회사의 직원으로서 업무에 참여하게 되면서 예전에는 보이지 않았던 부분들이 눈에 들어오기 시작했다.
결론부터 말하자면, 개발 속도는 단순히 개발자의 역량이나 의지의 문제가 아니라 그 사람이 감당해야 하는 책임과 리스크의 크기에 영향을 받는 것 같다.
최소한의 책임 의식을 가진 개발자라면, 어떤 업무가 주어졌을 때 결과가 잘못될 경우 발생할 시간적 금전적 손실을 고려하게 된다. 그리고 그 손실을 자신이 어디까지 감당할 수 있는지도 함께 계산한다.
대표가 직접 개발하는 상황에서는 상대적으로 감당 가능한 실패의 범위를 크게 잡을 수 있다. 일정이 조금 밀리거나 방향이 틀어지더라도 스스로 판단하고 책임질 수 있기 때문이다. 그래서 더 과감한 시도와 빠른 실행이 가능하다. 반면 직원 입장에선 그렇지 않다.
손실 허용 가능 범위에 대한 정보가 부족하거나, 조직이 실제로 어디까지 실패를 받아들일 수 있는지가 모호하게 느껴진다면, 사람은 본능적으로 보수적으로 움직이게 된다. 한 번 리뷰하고 넘어갈 것을 두 번 리뷰하고, 최대한 많은 이해당사자의 동의를 확보하려 한다. 실패했을 때 “왜 그렇게 했는가”를 설명해야 하기 때문이다.
그래서 개발 속도가 느려지는 것은 단순히 비효율적인 프로세스나 게으름의 결과가 아니라, 오히려 책임과 리스크 사이에서 이루어진 타협의 결과물에 가깝다.
일부 조직은 이런 부담감을 줄이기 위해 ‘실패해도 좋다 (Fail Fast)’는 문화를 이야기한다. 물론 초기 스타트업처럼 아직 잃을 것이 많지 않은 단계에서는 꽤 효과적인 접근일 수 있다. 하지만 실제 매출과 고객 경험에 직접 연결되는 미션 크리티컬한 영역에서는 ‘실패’가 민감하게 받아들여질수도 있다.
그래서 개발 속도를 높이고 싶다면 단순히 “실패해도 된다”라고 말하는 것만으로는 부족하고, 오히려 더 중요한 것은 어디까지 실패해도 되는지, 어떤 범위 안에서는 과감히 움직여도 되는지를 조직이 명확하게 정의해 주는 것이 필요하다.
결국 최종 책임은 대표가 진다. 그렇다면 대표가 해야 할 일은 단순히 속도를 요구하는 것이 아니라, 조직이 감당 가능한 리스크의 범위를 명확히 공유하고 심리적인 안전감을 제공하는 것이어야 한다. 물론 쉬운 일은 아니며, 특히 실패에 민감한 문화에서는 더욱 그렇다. 다만 개발 속도의 저하를 단순히 개발 프로세스의 문제로 바라볼 일은 아니라는 것이다.