<🚩 뭣이 중헌디 : 개발자의 목표 설정>

1. 목표가 일치해야 조직 앉아만 있어도 속이 답답해지는 회의가 있습니다. 으레 그렇듯 이야기는 겉돌고, 서로의 입장차만 확인하는 그런 회의들이죠. 대게 이런 의견차의 뿌리를 따라가 보면 목표의 불일치가 원인인 경우가 많습니다. 서로의 입장이 다르니, 각자 입장에서야 합리적인 주장들이 펼치고 있지만 회의는 좀처럼 결론이 나질 않습니다. 이상한 일입니다. 영리를 목적으로 모인 회사라는 조직인데 왜 서로의 목표가 다른 걸까요? 여러 관점이 있겠지만, 오늘은 개발자의 목표와 그 목표를 바라보는 관점에 관해 이야기해보고자 합니다. --- 2. 우리의 목표는 사업이 잘되는 것입니다. 우리는 돈을 벌기 위해 회사에 모였습니다. (다른 이유도 있을 수 있지만… 우리는 명목상 돈을 받고 사업체에서 일하는 프로니까요) 우리는 사업을 잘하기 위해서, 기획을, 개발을, 마케팅을 이야기합니다. 결국, 회사에 속한 우리는 사업에 집중해야 합니다. (그것이 상도이니까, 끄덕..) --- 3. 수단은, 언제나 목표를 가려서는 안 됩니다. 특히나 개발자는 문제의 '해결'에 집중하다 보니 문제 자체에 매몰되어버리는 경우가 종종 있는 것 같습니다. '되게 하는 방법'을 치열하게 고민하다 보면 '왜 되어야 했었는지'가 옅어질 수 있습니다. 현업에서의 문제는 수능과는 조금 다르지요. 지문 속에 모든 것이 있지 않습니다. 실전에서의 백그라운드는 매우 복잡하고, 우리가 현재 손에 들고 전전긍긍하던 그 문제는 사실은 그럴만한 가치가 있는 일이 아닐 수도 있습니다. --- 4. 문제를 정의하는 능력 또한, 문제를 '잘' 해결하기 위해서도 먼저 무엇이 문제인지를 명확히 하는 것이 중요합니다. 문제를 명확히 하기 위해서는 문제를 왜 풀어야 하는지부터 알아야겠지요. (사업을 잘하기 위해서!) 좋은 개발자를 판단하는 가장 중요한 포인트 중 하나는 문제를 합리적으로 정의하는 능력이라고 생각합니다. 심지어, 문제 해결 능력보다도 문제를 정의할 수 있는 능력이 더 중요할 때가 많습니다. 우리의 리소스는 한정적이며, 정말 풀어야 할 가치가 있는 문제에 집중할 수 있어야 합니다. --- 5. 균형 감각 개발자의 모습과 성향은 다양하지만, 우리들이 언제나 수많은 고민들 속에 있다는 것에는 동의하실 겁니다. 우리는 대용량 트래픽을 수용할 수 있는 확장성 있고 튼튼한 서비스를 만들어야 하지요. 우리 시스템의 사용자는 눈이 침침한 100살의 노인이거나, 펜타곤을 해킹할 수 있는 중학생 천재 해커 둘 뿐이라는 생각으로 준비해야 합니다. 이 과정은 험난하고, 매번 다양한 기술적 도전을 받습니다. 하지만, 이제 관점을 조금만 바꾸어 균형 감각 한 스푼 정도 추가된 개발자가 되어보면 어떨까요? 기술적 이슈들을 무시하자는 게 아니라, 사업의 측면에서도 문제를 바라볼 수 있다면 좋겠습니다. 때로는 작업의 퀄리티보다는 속도가 중요할 때가 있는 법이며, 최신 기술의 혁신보다는 안정성이 보장된 레거시가 필요할 때도 있습니다. 좋은 개발자가 되기 위해서는 시기와 상황에 맞는 효율적인 수단을 선택할 수 있는 안목이 필요합니다. --- 6. 슬기로운 개발자 생활 '해줘' 라고 기획자가 말하진 않지만... 협업하다 보면 그렇게 들릴 때가 많은데요. 정말 말 그대로 그냥 해줄 수도 있지만, 이제는 기획의 목표를 이해하고 개발적인 관점에서 더 디벨롭된 피드백을 제시해볼 수 있다면 좋을 것 같습니다. ("아 이 체크셔츠 개발자분 좀 치시네?" 할 수 있도록요) 아래 예시 느낌 정도면 어떨까요? "제안하신 A기능이 도입되면 XX의 맥락에서 사용자 경험이 더 좋아질 수 있다는 방향으로 이해했습니다. 현재 우리 서비스의 트래픽 정도라면 당장은 기능 구성에 무리가 없겠지만, 추후에 사용자가 늘어난다면 기능 확장에는 어려움이 있을 것 같은데요. 이번에는 XX맥락에서 당장 필요한 B정도로 구현 스펙을 축소화해서 제공하고, 조금 더 시간을 들여 전용 시스템을 구축해서 더 고도화된 기능 구성으로 준비해 보면 어떨까요?" --- 7. 맺음 사업을 항해에 비유한다면, 개발자는 풍랑을 이겨내고 악천후를 대비하며 안전하고 빠르게 배를 운행해야 하는 항해사가 아닐까 싶습니다. 우리가 선장이나 승객이라면 목적지를 제시했을 때, 무작정 출발하는 개발자보다는 왜 그곳에 가는지를 묻고, 어떻게 목적지에 도달할지에 대해 논의할 수 있는 개발자에게 더 신뢰가 가지 않을까요? --- 개인적으로는 개발자에게 목표가 제대로 록온되는지에 대한 여부는.. 사실 조직 운영의 비중이 더 크다고 생각합니다. 다만, 이번에는 개발자 개인의 태도 관점에서 말해보고 싶었습니다. 조직 운영 관점에서는 기회가된다면 다시 이야기해보도록 하겠습니다.