한창 개발을 할때 기획자나 관리자들이 어쩌다 보면 "ㅉㅉ 개발자 마인드 하고는..." 하는 경우가 종종 있었다.
이 개발자 마인드라는게 뭘까?
주로 어떠한 개발/이슈에 대해 부정적으로 반응하거나 방어적인 스케쥴 제시 때 들었던걸로 기억을 하는데, 개발자들이 처음부터 그렇게 반응하지는 않는다.
개발 건 을 들고 와서 "얼마나 걸려?" 라고 물어보고는 개발자가 제시하는 일자에 해당 기능 개발이 완료되지 않을경우 "네가 스케쥴 잡았잖아" 라는 무한 책임을 몇번 겪고 나면, 일정 자체를 1.5~2배 정도로 잡기도 하고, 최대한 부정적으로 대답을 하게 된다.
개발 시작전 예상하지 못했던 상황도 오롯이 개발자에게 책임을 묻기 때문인데 해가 가고 경력이 쌓이면서 그러한 상황을 "예측" 해서 일정을 잡게 된다. 그렇게 경력자가 된 개발자는 일정을 잘 지키게 될지는 모르겠으나, 그것은 기업 특히 스타트업같은 작은 기업에게 긍정적인 효과로 작용하지는 않는다.
개발자의 일정이 지켜지지 않는것에서 만일 개발자가 노력했음에도 문제가 생겼을때는 개발자의 변명을 되도록 수용해주고 인정해주어야 그 다음에도 일정을 최대한 회사측 입장에서 잡을 수 있게 된다. 그리고 또한 우리 사업에 더욱 긍정적인 반응을 보이게 되어 "그거 안되요, 오래 걸려요"같은 반응보다는 "힘들거 같은데 한번 해볼게요" 같은 반응을 가져올 수 있게 된다.
개발자 마인드에 대한 이해와 효과적인 일정 관리
개발을 진행하다 보면 기획자나 관리자들이 종종 "개발자 마인드하고는..."이라는 말을 하곤 한다. 특히, 일정 산정 과정에서 부정적인 반응을 보이거나 보수적으로 일정을 제시할 때 이러한 표현을 듣는 경우가 많다. 하지만 개발자들이 처음부터 이런 태도를 취하는 것은 아니다.
개발자의 일정 산정 방식과 방어적 태도의 형성
일반적으로 새로운 기능 개발을 요청받으면 기획자나 관리자는 "이 기능을 개발하는 데 얼마나 걸릴까?"라는 질문을 던진다. 이에 대해 개발자가 신중하게 일정 예측을 하고 답변을 하지만, 실제 개발이 진행되면서 예상치 못한 문제들이 발생하기 마련이다. 그러나 개발 일정이 지연될 경우, 개발자에게 "네가 스케줄을 잡았으니 책임도 네가 져야 한다"는 부담이 돌아오는 경우가 많다.
이러한 경험이 반복되다 보면, 개발자들은 일정 산정을 할 때 점점 더 보수적으로 접근하게 된다. 예를 들어, 예상 소요 시간을 1.5배에서 2배 정도로 늘려 잡거나, 최대한 부정적인 시나리오를 가정하고 대답하는 방식을 택한다. 이는 단순한 방어 기제가 아니라, 경험을 통해 형성된 합리적인 대응 방식이다. 실제 개발 과정에서는 예상치 못한 변수들이 많기 때문에, 이를 감안한 일정 조정이 필요하다는 것을 학습한 결과이다.
경력자의 일정 예측과 스타트업 환경
경력이 쌓인 개발자들은 이러한 변수를 고려하여 일정을 보다 현실적으로 산정한다. 하지만 일정 준수율이 높아지는 것이 반드시 스타트업 같은 작은 기업에게 긍정적인 효과로 작용하는 것은 아니다. 개발자가 지나치게 보수적으로 일정을 잡게 되면, 기업의 기민한 대응 능력이 저하될 수 있기 때문이다.
스타트업에서는 빠른 실행과 적절한 리스크 감수가 중요하다. 따라서 개발 일정이 지연될 경우, 개발자가 충분히 노력했음에도 불가피한 문제가 발생했다면, 이를 인정하고 유연하게 대응하는 것이 중요하다. 개발자의 입장에서 "왜 일정이 늦어졌는가?"라는 질책보다는 "어떤 문제가 있었고, 어떻게 해결할 수 있을까?"라는 접근이 필요하다.
개발자와의 협업을 위한 긍정적인 문화 조성
개발자들이 지나치게 방어적인 태도를 취하지 않도록 하려면, 일정이 지연되었을 때 개발자의 변명을 무조건 배척하기보다는 이를 수용하고 인정해 주는 문화가 필요하다. 그렇게 해야 개발자들도 일정 산정 시 회사의 입장을 더욱 고려하게 되고, 보다 적극적인 태도로 업무에 임할 수 있다.
예를 들어, 개발자가 "그거 안 돼요, 오래 걸려요"라고 말하는 대신 "힘들 것 같지만 한번 해볼게요"라고 반응할 수 있도록 유도하는 것이 중요하다. 이를 위해서는 신뢰를 바탕으로 한 협업 환경을 조성하고, 실패를 지나치게 비난하는 문화를 지양해야 한다. 개발자가 새로운 도전에 긍정적인 태도를 가질 수 있도록 지원하는 것이 결국 기업의 성장에도 도움이 될 것이다.
결론
'개발자 마인드'라는 말이 종종 부정적인 의미로 사용되곤 하지만, 사실 이는 경험을 통해 형성된 현실적인 대응 방식이다. 효과적인 협업을 위해서는 개발자의 일정 산정 방식을 이해하고, 일정 지연에 대한 책임을 지나치게 가중시키지 않는 것이 중요하다. 이를 통해 개발자와 회사 모두가 긍정적인 방향으로 나아갈 수 있을 것이다.