개발자는 기술로도 문제를 해결할 수 있는 사람이다
개발만 잘하면.. 그것도 좋긴 하다.
회사라는 조직에서 구성원들은 하나의 공동목표를 공유합니다. 바로 비즈니스에 기여하라는 것. 아무리 좋게 포장해도 회사는 돈을 벌지 못하면 존속할 수 없기 때문에 모든 구성원들은 비즈니스에 기여해야합니다. 각자의 자리에서 맡은 일을 해야하는 이유에요.
서비스를 만드는 메이커 집단도 마찬가지에요. 보통 기획, 디자인, 개발로 이루어져요. 그 중 구성원 중 하나로서 개발자 또한 같은 목표를 공유받고 그 목표를 달성하기 위해 전속력으로 달려요.
그럼 이 상황 속에서 일 잘하는 개발자는 어떤 개발자일까요? 개발 경험이 많이 누적되신 분일 수도 있고, 개발쪽으로는 박학다식한 분이 될 수도 있죠. 손이 빠른 개발자를 선호하시는 경향도 있어요. 하지만 이런 피상적인 것 보다 좀 더 낮은 레벨에서 보면, 제가 생각할 때 일 잘하는 개발자는 최소한의 코드로 문제를 해결하는 사람이에요.
개발자가 코드 작성 안하면 뭘로 문제를 해결하느냐, 물론 코드 짜야죠. 근데 덜 작성할 수 있는 요소가 충분 하다면 그러자는겁니다. 그래서 개발자여도 비즈니스와 사용자 경험에 대한 이해가 매우 중요합니다.
문제가 맞나?
내가 요구받아 해결해야 할 문제가 진짜 문제가 맞나? 이 고민 해보신 적 있나요? 가령 A라는 문제 해소를 위해 B라는 기능을 추가해주세요 라는 식의 요구가 들어왔다면 무작정 OK하고 B를 개발하진 않으셨냐는 거에요.
개발자는 메이커 조직의 종장에 위치한 직군이므로 꼭 고려해봐야 할 사항입니다. 회사의 리소스와 프로덕트와 같이 비즈니스에 치명적인 사항에 직접적으로 영향을 주기 때문입니다. 가령 다음과 같은 상황을 가정해볼게요.
“게시글의 공유량이 너무 낮아요. 공유하기 이벤트를 위해 캠페인 페이지를 하나 만들어주세요”
만약 위와 같은 요구가 들어왔을 때 순종적인 개발자가 되기 위해 “네”하고 만들기에 들어갔다면 메이커 몇명의 리소스가 며칠 소모되었겠죠?
문제의 재정의
하지만 잘 생각해보면, 해결해야 하는 문제는 캠페인 페이지 만들기가 아니라 게시글 공유량을 높히는 것이니까 간단하게 게시글 공유하기 버튼을 잘보이게 색칠을 한다던가 애니메이션을 준다던가 플로팅으로 고정을 해주면 해결되지 않을까? 하고 생각할 수 있습니다.
문제라고 생각해 상정한 과제가 사실 문제가 아닐 확률이 꽤 높고, 문제가 맞더라도 해결책이 기획/디자인 단에서 생각한 문제와 다를 가능성도 있습니다. 혹은 개발자들만 알고 있는 방법들을 모르고 계실 수도 있고요. 이러한 소통은 결과적으로 회사와 각 구성원, 고객 모두에게 이득이 되는 방향입니다.
문제가 맞다!
문제임이 판명되어 해결해야하는 과제가 주어졌다면, 해결해야합니다. 하지만 해결하기 전에도 해야 할 고민이 있는데, 바로 이게 해결책이 맞나? 입니다. 사실 그걸 알 수 있는 사람은 없습니다. 그럴 것이다 하고 추측하는 것이죠.
저는 이럴 때 문제의 크기를 가장 작게 만들고 고객의 반응을 보는걸 선호합니다. 데이터는 거짓말하지 않으니까요. 흔히 A/B 테스팅이라고 하는 도구를 쓰거나 데이터 로깅을 통해 수치를 분석하고 다음 스텝을 정하는 과정을 말합니다.
뭐 대단히 말하면 진짜 문제 해결을 위해서는 설계가 필요하다는 것입니다. 무지성 개발이 빠르게 만들어서 빠르게 고객에게 전달한다는 장점이 있고 어쩌다 효과가 있을수도 있지만, 더 대단한 효과도 기대할 수 있는거잖아요?
여기까지 개발하면 되겠다
개발자의 자율성은 스스로 얼마나 개발할지를 정할 수 있다는 점에서 나옵니다. 나에게 주어진 문제가 기획서와 디자인 협업툴에 나온대로 개발하기라면 자율성이랄게 없어지지만, 지표 A 개선하기나 페이지 B 사용성 개선 같은 추상화 레벨이 높고 조직 공동의 목표에 가깝다면 할 수 있는 일이 꽤 많아집니다.
키보드보다는 펜을 우선 잡고, 어떻게 이 문제를 풀 수 있을까 고민합니다. 그 과정에서 기획과 디자인측 인사이트를 받고 제 인사이트를 드립니다. 공유된 개념들을 모아 최적의 설계를 하고, 비로소 키보드를 잡습니다.
마치며
두 눈과 귀를 닫고 주어진 개발만 하는 것은 편합니다. 코딩 재밌잖아요. 근데 그건 회사 입장에서는 이기적일 수 있습니다. 문제해결을 위해 더 좋은 해결방법이 있을 수 있는데 방관한 것이니까요. 저는 문제에 달려든다라는 표현을 좋아하는데, 궁극적으로는 개발자 뿐만 아니라 메이커 집단이 어떤 추상화된 문제에 달려드는 자세가 필요하다 생각해요. 그래서 뜻과 결이 맞는 사람과 일하는걸 중요하게 생각하는 것 같습니다.
