[나는 악동일까] - 소프트웨어 엔지니어의 역할에 대하여 IT회사는 솔루션을 통해 돈을 번다. 그렇다면 솔루션을 만드는 개발자의 역할은 무엇이고, 알아야할 범위는 어디까지 일까? 이러한 팀 안

[나는 악동일까] - 소프트웨어 엔지니어의 역할에 대하여 IT회사는 솔루션을 통해 돈을 번다. 그렇다면 솔루션을 만드는 개발자의 역할은 무엇이고, 알아야할 범위는 어디까지 일까? 이러한 팀 안에서 나는 무엇을 해야할까? 먼저 내가 생각하는 이상적인 팀 구성은 이렇다. 외부로부터 팀원을 지켜주는 탱커, 팀원의 정신적 지주인 서포터, 퍼포먼스 터지는 딜러. 탱커는 팀의 리더로 외부와의 소통을 담당하며 팀의 문화 ( 에자일이든 무엇이든 )를 지키고, 각 팀원의 업무를 조율해주는 역할을 한다. 리더에게 부여된 임무는 팀원이 각자의 역할을 충분히 할 수 있는 환경을 만드는 것이라고 생각한다. 서포터는 주로 팀의 시니어 급으로 기술 관점에서 솔루션의 안정을 책임진다. 각 팀원의 아이디어, 설계물, 결과물 등을 리뷰하며 안정적인 측면에서 보완해야할 점을 제시해줄 수 있어야 한다고 생각한다. 딜러는 사실 팀원 모두가 해당한다. 이들에게 주어진 임무는 퍼포먼스를 내면서 눈에 보이는 결과를 만드는 것이다. 그리고 나의 고민은 역할 범위가 어디까지냐에 있다. 누군가는 딜러 개발자의 역할로 주어진 '해결법'을 구현하는 것이라고 생각한다. 혹자는 '문제를 해결하는 방법에 대한 고민' 부터가 딜러의 역할이라 생각한다. 그리고 또 누군가는(나를 포함) '문제 정의' 부터가 딜러의 역할이라 생각한다. 조직의 형태가 목적 조직이냐 기능 조직이냐에 따라 (혹은 조직 문화에 따라) 개발자의 역할 범위가 한정되어 있을 수는 있다. 그러나, '요구사항의 출현부터 해결방법 도출까지' 전 과정에 대해서는 모든 개발자가 이해해야 한다고 생각한다. 내가 이 일을 왜 하는지를 알아야 내가 지금 이 일을 잘 하고 있는지 정성적으로든 정량적으로든 평가가 가능하다. 그리고 평가를 바탕으로 회고하고 개선 하며 더 나은 소프트웨어를 개발할 수 있다. ( 평가할 수 없는 일은 하지 않은 것과 같다는 생각에 동의한다. ) 조금 더 나아가서는 실제 현장에서 어떤 불편함이 발생하는 지에 대해 알아야하고, 비즈니스 상황에서는 어떤 요구사항이 나오는지 알아야 한다. 전체 맥락을 이해해야만 올바른 솔루션을 생각해내고, 설계하고, 개발할 수 있다고 생각한다. 이러한 맥락에서 나는 동료들에게 우리 솔루션과 관련한 비즈니스 상황과 요구사항 등에 관심을 가졌으면 한다. 그리고 기존보다 더 나은 해결법을 제시했으면 하고, 더 나아가 새로운 문제를 발굴 했으면 한다. 회의를 하면 가끔 이런 질문을 한다. - 이 기능의 장점은 무엇이고 단점은 무엇일까요? - 해당 기능이 정말 이용자의 고통을 덜어 줄 수 있을까요? - 평가 지표로 무엇을 가져가면 좋을까요? - 더 나은 해결방법은 없을까요? 이러한 고민은 조직 리더의 역할이고 각 팀원은 부분만 알고 있으면 된다고 주장할 수도 있다. 혹은 위와 같은 질문을 하는 것이 조직 리더의 역할이라고 할 수도 있다. 나의 질문으로 괜히 그들의 퍼포먼스에 브레이크를 걸어 전체 일정에 영향을 줄 수도 있고, 올바른 방향으로 나아가던 사람에게 괜한 자극을 주어 이상한 방향으로 가게 만들 수도 있다. 물론 나는 브레이크하고 생각하는 시간을 갖는 것도, 본인이 생각한 방향으로 갔다가 돌아오는 것도 필요하다고 생각한다. 아직 경험이 짧아 무엇이 정답인지, 무엇이 더 좋은 조직인지 모르겠다. 나는 이 악동 짓을 계속해도 되는 걸까?