서비스 제작자로서의 개발자
지식 노동자는 제품을 찍어내는 사람이 아니다.
배틀그라운드의 제작사 크레프톤의 일대기를 다룬 책 크레프톤 웨이엔 프로에 대한 언급이 끊임없이 나옵니다. 넷플릭스의 기업문화를 다룬 책 규칙없음에서는 인재 밀도를 높이기 위한 노력으로 터무니없는 급여를 지급하죠. 그렇다면 프로 개발자, 인재로서의 개발자는 어떤 사람이어야 할까요?
멀지않은 과거에 개발자들은 노동자로서 서비스를 찍어내는 입장에 있었습니다. 그래서 프로나 인재가 되는 사람은 그리 많지 않았고(CTO나 리드급정도?) 나머지 사람들은 볼트와 나사못같이 회사의 귀퉁이를 차지하는 노동자였습니다.
그리고 세월이 흘러 오늘날엔 개발자 품귀현상이라는 흐름을 타, 지식 노동자라는 새로운 계급을 달고 같은 일을 합니다. 하지만 우리가 하는 일은 예전과 같아선 안됩니다. 개발자는 최종 프로덕트를 점검하는 관문이자 진정한 올라운더로서 서비스 전반을 바라보는 눈을 가지고 업무에 임해야 합니다.
단순 노동자로서의 개발자가 하는 일은 언젠가, 컴퓨터가 대체할 수 있다는 사실을 명심해야합니다.
AI 기반 코드 자동 작성기 Copilot개발자는 개발만 잘 하면 되지 않나요?
개발자는 기획자와 디자이너가 만들어낸 문서를 바탕으로 실물을 만들어내는 제작자입니다. 마치 본사에서 판매할 물건의 프로토타입을 기획하고, 틀을 만드는 공장에서 제품을 찍어내기만 하면 되도록 보일러플레이트를 만든 뒤에 공장 노동자가 하는 일과 같죠. 생산자들은 무엇을 하면 되나요? 그들이 만들어준 스펙과 틀을 가지고 제품을 찍어내기만 하면 됩니다.
붕어빵 틀에선 항상 같은 붕어빵이 나온다그 일은 명확한 스펙, 명확한 디자인 틀에 맞춰 실제 판매될 제품을 생산해내는 일입니다. 여기서 조금이라도 다른 외형을 가진 물건을 생산하거나, 오작동하도록 만들어진 물건은 상품가치를 잃습니다. 그렇기 때문에 철저한 분업시스템 내에서 생산자의 역할은 요구조건에 맞는 물건을 만들어내는 것 이상의 권한을 갖지 못합니다.
하지만 기획이 틀렸을 수도 있고, 디자인이 이상할 수도 있으며, 기획이나 디자인을 수정해서 쉽게 해결할 개발 이슈들도 있습니다. 만들라는대로 만들고 나면 결과물이 나온 뒤 이상함을 알아채고 수정을 요구할 수 있고, 조금만 바꿔보자고 우릴 구슬릴 수도 있습니다. 아래 예시를 보겠습니다.
왼쪽 두 사진은 앱에서 Screen으로 구현되어 있습니다. 하지만 성격을 따져봅시다.
왼쪽은 단순한 채팅방 생성 페이지입니다. 만들어진 채팅방에서 뒤로가기를 눌렀을 때 다시 생성 페이지로 이동할 여지를 주는 잘못된 UI입니다.
오른쪽은 이벤트용 Static 페이지로서 더이상의 인터렉션이 발생하지 않고 오직 뒤로가기 정도만 필요한 상황입니다.
그래서 두 스크린은 PopUp 형태로 구현되어야 하는게 맞습니다.
세번째 페이지는 어떨까요? 저 많은 내용은 전부 스크린에 들어가 있는데, 가독성도 떨어질 뿐만 아니라 사용자가 정말 필요할 때 검색도 불가능하고, 중요한 약관 변경 같은 이벤트에 빠르게 대응도 되지 않죠. 그러면서 관리도 불편한 각자 스크린으로 존재합니다. 이런 경우엔 Notion같은 회사 문서관리도구에 내용을 넣고, WebView로 뿌리면 간단히 해결됩니다. 간단한 넛징을 통해 역제안하여 작업량과 효율성을 모두 끌어올린 사례입니다.
이러한 요구가 들어왔을 때, 곧이 곧대로 만드는 개발자보다는 UI/UX의 관점에서, 오작동의 가능성 측면에서 다른 기획이나 디자인을 요구하는 것이 일을 2번하지 않고 모두가 만족하는 명확한 결과물에 도달할 줄 아는 개발자라고 생각합니다.
개발자가 OwnerShip을 가지는 방법
어떤 대표든 직원들이 OwnerShip을 가지고 회사 업무에 임해주길 바랍니다. 하지만 어떤 직원이 지분도 없는 회사에, 상장할 가능성도 없는 회사에 OwnerShip을 가지고 일하겠습니까. 하지만 개발자는 조금 다른 관점에서 그럴 수도 있다고 봅니다. 마치 칼을 만드는 장인이 이미 날카로운 칼날을 더욱 날카롭게 갈아내듯, 디테일을 더해줄 수 있고, 새롭게 나오고 있는 기법이나 장인만 알고있는 비기를 활용해서 더 완성도 높은 칼을 만들 수 있죠.
내가 프론트 엔드 개발자라고 생각해봅시다. 사용자가 직접 마주하는 앞단을 담당하는 개발자로서 어떤 부분엔 애니메이션이 들어가면 더 부드러운 느낌을 줄 수 있고, 온보딩 폼엔 자동 포커스 기능을 넣어 사용자 입장에서 귀찮은 키보드 오르내림이나 커서 이동을 최소화할 수 있죠. 우리는 이렇게 특정한 분야에서 서비스의 만족도를 높힐 수 있는 방법을 알고 제안할 수 있습니다.
개발자들이 기획자들로부터 꽤나 자주 듣는 말이, “이렇게 구현하실 수 있나요?”입니다. 왜냐하면 기획자는 이런 기능을 모를 수 있습니다. 개발자들은 이러한 기능들이 가능한지 불가능한지 직감적으로, 혹은 구글링 몇번으로 알 수 있습니다. 우리는 이런 요구를 안된다, 시간이 걸린다라고 둘러댈 수 있지만 양심의 영역에서 그리고 개발자의 자존심의 영역에서 진실된 말을 할 줄 알아야하며, 이는 다른 의미에서는 회사에 대한 OwnerShip보다 더 강력한 Service OwnerShip이라고 생각합니다.
기획자의 관점에서 바라보는 코드는 어떤거죠?
어떤 사람도 가까운 미래에 어떻게 될지 모릅니다. 플랫폼 비즈니스에 대입해보면 어떤 기능이 추가될지, 변경될지, 사용자 요구에 맞춰 대규모 업데이트를 할 수도 있고, 2.0 리뉴얼 같은 작업을 할 수도 있습니다. 이러한 내용들은 기획단계나 전략회의 단계에서 고려되어 축적되어야 할 것이며 청사진(blueprint) 도한 그 범주 안에 존재할 것입니다.
이런 사실을 모르고 기획서를 받아든 개발자는 당장 눈앞의 문제를 해결하기 위한 설계를 하기 마련입니다. 추가적인 질문을 해보면 내가 지금 설계해야 할 산출물이 몇번째 마일스톤인지 알 수 있을텐데, 보통 그런 질문을 하지 않습니다. 너무 주제넘는다고 생각할 수도 있고, 그럴만한 레벨이 아니라고 생각할 수도 있습니다. 물론 그런 질문에 그냥 개발이나 하라고 꾸짖는 기획자나 대표님도 많습니다. 이건 회사 문제니 넘어가도록 하죠.
그래서 만약 기획자가 코드를 짠다면 어떤 모습일까 생각했을 때, 아래 사진과 같을 것이라고 추측했습니다.
전화 교환기이 사진은 전화 교환기인데요, 저 수많은 구멍들 중 하나에 선을 연결하면 두 포인트 간 전화연결이 성사됩니다. 선과 구멍은 각자의 역할만을 합니다.
확장성을 고려해 여러 기능을 추가할 수 있도록 전체 판을 설계하고, 당장 사용하지 않을 구멍들은 잠시 막아 둡니다. 자주 쓰거나 강한 연결이 필요한 기능이라고 생각되면 응집도를 높힐 수 있도록 납땜하여 하나의 모듈로 만들고, 다른 가벼운 기능들은 언제든 추가/제거 가능할 수 있도록 간단히 선정리를 진행할 것입니다.
이 모든 작업이 끝난 다음 손이 빠르고 유능한 전화 교환원을 앉히면, 비로소 서비스가 시작될 수 있는 시점으로 보고 상주 유지보수 엔지니어를 소수 둔 다음 다음 선이나 기판을 개발하는 팀을 꾸리는 겁니다.
하지만 기획자는 개발을 할 수 없습니다. 그럴거면 아마 직책이 달라졌을겁니다. 기획개발팀 PM이나 CTO가 되었겠죠? 그래서 최종 단계에서의 점검을 개발자가 할 수밖에 없습니다. 우리는 그들의 의도를 얻기 위해 끊임없이 소통하고, 얻은 청사진을 바탕으로 제품을 설계해야합니다.
Outtro
서두에도 언급했듯이 개발자는 더이상 생산 노동자가 아닙니다. 만들라는대로 잘 만드는게 최고의 개발자라 고 생각하는 사람들이 많은데, 역사를 둘러보면, 그런 직종들은 전부 기계와 컴퓨터에 의해 대체되었습니다. 우리는 지식 노동자로서의 지위를 확보할 수 있는 방법을 찾는 노력을 지속해야 할 것입니다.
