제목으로 어그로를 끌려고 했는데 실패한것 같네요. 하지만 오해하지 마시기 바랍니다. 빈둥 대자는게 아니고, ‘이건 내 일 아님!’이라고 말하는것도 아닙니다!
개인적으로 일을 잘하는 방법중 하나가 일을 나누는 것이라고 생각합니다. 프로젝트 초반은 물론, 중후반에도 일의 경계가 무너지는 경우가 많습니다. 초반에 투입되어 혼자 여러가지 일을 할 수밖에 없는 상황에서는 흐지부지 과업들이 완수되지 못한채 터지기도 합니다. 가끔은 개발자가 기획자가 되고 기획자가 디자이너가 됩니다. 사람이 없으면 어쩔 수 없죠. 하지만 이때 일에 대한 분배를 생각하며 작업하는게 필요합니다.
결국 나눠주게 될 일이거든요. (혹시 혼자 다 하실 수 있다면 능력자이신 거에요! 어서 자랑스러워하십시오.)
이번 글에서는 많은 프로젝트를 진행하며 경험 했던 일을 나누는 방식에 대해 개발자의 입장에서 풀어보고자 합니다.
몰려드는 일
직방에서 3D단지투어 기능에 대한 기술 검증이 끝나고, 제품을 본격적으로 만들기 위해 백엔드가 필요해졌습니다. 2020년 말에 저를 포함해 두 개발자가 합류하게 되었습니다. 프로젝트 중간쯤 한 분이 다른 프로젝트로 인해 빠지게 되었고 저 혼자가 되었습니다. 외로워지기 시작했습니다.
3D단지투어를 위한 데이터는 매우 많습니다. 제가 모르는 원본 데이터를 포함해서, 타입별 평면도 데이터, 유니티에서 사용하는 에셋번들, 주변 환경 데이터 등 지금도 계속 종류가 늘어나는 중입니다.
데이터의 종류가 다양한 만큼 데이터를 데이터 생성의 주체도 많습니다. 여러 사람이 동시에 여러 데이터를 가공 및 조합해서 하나의 단지를 그려내야 합니다. 으레 그렇듯 데이터 틀어지는 일이 많았습니다. 일부 팀은 툴을 쓰기도 했지만 DB와 S3를 직접 건드리는 일이 잦았습니다.
문제는 틀어진 데이터 확인 요청이 저에게 먼저 왔었다는 것이었습니다. 데이터 확인의 게이트 웨이였습니다. 나중에는 관리가 힘들 정도로 쌓여서 업무 이해관계자들이 모두 기다리는 문제가 발생합니다. 이러한 병목현상을 방지하기 위해 (그리고 살기 위해!) 결단을 내려야 합니다.
개발자가 코드를 짜는 것만이 일은 아닙니다. 여러가지가 있죠. 동료도 설득하고, 문서도 써야 합니다. 그래도 수동으로 데이터를 확인하고, 운영 보조 역할도 하고, 불필요한 반복적인 일을 계속하는건 개발자가 가만히 하고있을 종류의 일이 아닙니다.
저는 이렇게 포지션을 바꾸면서 집중력을 흐트러뜨리고 싶지 않았습니다.그래서 저는 관리자 페이지를 좀 일찍 만들기로 했습니다. 이러면 제가 하던 일을 다른 사람에게 전달하기 쉬워집니다. 기획도 없고, 디자인도 없지만 착수 해보기로 합니다.
관리자 페이지를 만듭시다
최우선으로 수행한 작업은 데이터 상태 노출이었습니다. 기능 고도화는 미루고 일단 제가 AWS console, SQL client를 사용하지 않고 관리자 페이지로 데이터를 다룰 수 있도록 하는 게 먼저입니다. 틈틈히 작업해 직방 내 관리자 페이지에서 보이도록 했습니다. 엑셀을 많이 사용하는 동료들이 편할 수 있도록 엑셀 내용으로 바로 검색할 수 있는 검색창도 넣어봅니다.
자체 QA 후 관리자에게 넘기면 ‘데이터 확인해주세요’와 같은 반복 작업이 사라질 줄 알았는데 어드민 페이지의 편리함을 알아버린 관리자에게 더 다양하고 고도화된 기능 추가 요청이 들어왔습니다.
관리자 페이지를 더 잘만듭시다
어떤 기능이든지 대충 만들면 안 된다는 교훈은 왜 자꾸 잊어버리는지 모르겠습니다. 그렇게 제 업무는 자연스럽게 관리자 페이지 고도화로 변경되었습니다. 그만큼 지금까지 관리자가 손으로 하고 계셨을 것이란 생각에 살짝 눈물도 흐르는데… 괜찮습니다. 저도 힘들거든요. 흠흠. 제 업무는 이제 관리자 페이지를 고도화 하는 것으로 바뀌었습니다.
JSON 포맷의 뷰는 테이블로 바뀌었고, 3D단지의 복잡한 상태 들은 ‘에러’, ‘검증 중’, ‘오픈 가능’ 과같이 운영에 필요하도록 추상화되었습니다. 바꾸고 나니 당연하다고 생각됩니다. 관리자 툴이라고 복잡해야 할 이유가 없죠. 오히려 버튼 하나로 모든게 다 되도록 동작 해야 했습니다.
맞습니다. 결과적으로 모든 요구사항은 운영상 필요한 명령을 버튼 몇 개로 해결하도록 바뀌고 있었습니다. 빌드, 검증, 검색, 배포. 비지니스 요구가 복잡해지고 많아질수록 버튼은 많아지겠지만, 그땐 그때의 관리 페이지가 있겠죠.
결과적으론 좋았다
관리자 페이지를 만드는 동안 초반 한두 달은 이전보다 더 바빴습니다. 이전에는 귀찮지만 AWS 콘솔에 들어가서 클릭 몇 번이면 가능했던 작업을 위해 어드민 개발을 해야 했으니까요.
시간이 지날수록 상황은 더 나아졌습니다. 일단 요청의 형태가 데이터 확인과 책임자 찾기에서 코드 짜기로 변했습니다. 그리고 유지보수를 할수록 요청빈도는 줄었고 관리자 페이지를 통해 관리자가 직접 처리할 수 있는 부분이 들었습니다. 커뮤니케이션의 질은 높아졌습니다. 이는 관리자 페이지를 만들면서 상태에 대한 논의가 활발히 이루어지고 ‘관리’에 대한 모델이 가시화되었기 때문이라고 생각합니다.
이제 시작입니다.
지금은 프로세스가 정립되어서, 모든 변경을 관리자 페이지를 통해서 하도록 되어있습니다. 프로세스가 코드로 문서화 된 셈이죠. (여전히 복잡하긴 합니다)
아직도 자동화 해야 하는 부분이 많습니다. 레이어를 나눠서 불필요한 파이프라인을 타지 않게 하는 것도 필요합니다. 지금도 데이터 종류는 늘어나고 있고, 검증기를 피해가는 데이터가 나오니 당연한 이야기입니다. 하지만 관리자 페이지라는 매개체를 통해 나의 일을 위임한다면 즉, 자동화 한다면 많은 부분이 좋아질 것임을 의심치 않습니다.
마치며
이 글은 사실 일을 남에게 넘기는 것에 대한 내용이 아닙니다. 자동화/추상화 작업으로 업무에 대한 효율과 성과가 좋아지게 된 점을 강조하는 것입니다. 여기서 말하는 관리자 기능은 기획자, 디자이너, 동료 개발자 심지어 자기 자신에게도 도움이 될 것입니다.
매번 DB를 접근하고 AWS 콘솔을 만지면서 운영할 수는 없습니다. 도구를 통해 프로세스를 잡는 과정은 고통스럽지만 그에 상응하는 보상을 줄 것입니다.
이상 저의 좌충우돌 경험담 이야기를 마칩니다. 삽질은 부끄럽지만 누군가에게는 도움이 될 것이라 생각하며 작성했습니다. 읽어주셔서 감사합니다.
