✨ 개발자의 미덕... 알잘딱...!
"어어 영기야~ 다름이 아니라..."
사실... 큰 사건이란게, 지나고 보면 컸구나... 싶은거지 당장에 그 상황에서는 아무 생각도 안들 수 있는 사소한 것에서 시작되는 것 같다.
평화로운 대학생의 느슨해진 인생에 긴장을 불어넣은 외주 사건의 발단 또한 그랬다.
누군가 그랬다... 인생은 선택의 연속이라고...
영기(본인 부캐)에게 다가온 외주 또한, 그저 아는 형의 같이 해보자는 가벼운 제안에서 시작되었다.
나에게 같이 하자고 제안한 형 또한 그닥 큰 프로젝트가 아니니, 금방 끝내자고 말하였고 실제로 서비스의 크기가 그리 크지 않아 금방 끝낼 수 있을 것이라고 생각했다...
하지만 그때 우리는 알지 못했다... 2주면 끝날 외주가 1달 반을 넘어갈 것이라는 사실을...
갭 모애의 끝판왕이신, 짱구의 모 쌍둥이께서는 말씀하셨다.
원래 인생을 뜻대로 되지 않는 법이라고.
하지만 적어도, 일적인 측면에 있어서는 계획한 대로 되어야 한다고 생각한다.
프로젝트를 해본 경험이 있는 자라면 한번쯤은 계획대로 흘러가지 않는 상황에 마주해본 적이 있을 것이다.
프로젝트가 로드맵대로 흘러가지 않는것은 도대체 뭐가 문제일까?
정말 수도 없이 많은 이유가 있을 것 같다.
하지만 우리가 처한 문제는 정말 근본적이면서 어이가 없는 문제였다.
듣고 나면 조금 웃길수도 있는데
만들고자 하는 서비스는 있는데, 기획자가 없다.
??? : 그게 가능한거야...? 아니 적어도 뭐를 만들지가 있으면 누군가를 기획한거 아닐꺼야...
허허... 외주를 받고 보니 정말정말 러프하게 어떤 것들을 만들지를 pdf로 대충 만들어 놓은 것이 있었다...
??? : 그럼 외주를 안받으면 되는거잖아...
물론 그것도 해결책일 수 있겠지만, 정말 금방 끝날 프로덕트로 생각되어서 빨리 끝내고 돈 받을 생각에 신나 있었다...
그래서 우리는 디자인조차 없는 정말정말 러프한 pdf 파일 하나와 일을 시작하게 되었다.
이것이 프런트 한명, 백엔드 한명, 그리고 pdf 한마리와 함께하는 우당탕탕 외주의 시작이었다.
오케이 그러면 일단 기획자가 없으니 뭐 부터 해야할지 정리를 해보자
한번 상상을 해봐라.
일은 시작되었는데 내가 가진 것은, 초라한 pdf 하나와 아직 받지 못한 돈에 대한 기대감 뿐이다. (그리고 사랑하는 프런트 형님 추가...ㅎ)
기획자가 있는 것도 아니라서 PRD, IA, FlowChart를 요청할 수 있는 상황조차 아니다.
그러면 뭐를 먼저 해야할까...?
너무나도 당연히 가진 것부터 점검해봐야 하지 않겠는가?
근데 돈은 아직 가지지 못했으니... 내가 가진거라곤 pdf 뿐이었다.
그래서 pdf를 보고 각 페이지에서 생길만한 flow상 오류와 기획의 의도 등을 파악하고, 기능에서 모호하거나 질문이 될만한 것들을 정리해서 외주사 측에 전달했다!
A4 용지 2장 정도 분량으로...ㅎ
그리고 답변을 받았다!!
질문한 시점으로 부터 1주일 정도 뒤에... ㅎ
저엉말 답변이 늦게 오긴 했지만, 그래도 답변이 안온거슨 아니기에...
럭키비키~⭐️ 라는 생각으로 나는 일단 필요한 데이터와, 기능을 정리했다.
그 다음에 DB구조를 설계하고 이를 ERD로 작성했고,
서버 구성도와, API 명세서를 노션으로 작성하여 외주사 측에 전달했다.
기본적으로 외주사 측에서 바란 것은, 추후에 유지 보수하기 쉬운 코드와, 문서화였다.
이번 외주에서는 이 요청사항을 최대한 반영하기 위해서 정말 노력했던 것 같다.
먼저 코드에 최대한 주석을 달아가며 적으려고 노력했고 각각의 controller 단에 있는 코드들이 어떤 역할을 하는지 직관적으로 보여질 수 있도록 노력했다.
또한, 커밋 컨벤션을 설정하여, 버전 관리에 용이하도록 도우려고 노력했다.
참고로 커밋 시 사용하는 아이콘은 아래 링크만한 게 없는 것 같다.
또한 직관적인 api 명세서를 제공하려고 노력했는데,
기본적으로 swagger를 제공하긴 했지만, api를 그렇게 설정한 의도를 충분히 전달하기에는 어려움이 있다고 느껴서 문서화를 시켜주기 위해 무단히 노력했다.
"코드를 깔끔하게 짜는 것은 당연한거고... 흐음... 또 해줄 수 있는게 뭐가 있지?"
외주사측의 경우에는, 정말 개발에 대해서 모르는 분들이셨고 그에 비해서 개발 시 제한되는 제약 사항은 많이 있었다.
(자세한 것은 아래 기술 회고에서 확인...)
어느 자기개발 도서에서, 개발자가 실력을 키우는 방법은, 본인의 개발 환경에 제한을 두고 개발을 하거나, 주변의 실력을 높여서 본인이 성장하는 방법이라고 하였다.
저자의 정확한 의도를 파악하기는 힘들지만, 당시에 나는 이 문구가 그저 성장할 수 있는 환경에 나를 두어서 부딛혀보라는 의미로만 파악했다.
근데, 상황의 제약에서도 정말 성장이 있더라...
평소에 개발할 때 그냥 AWS로 배포하고, route53을 쓰고, mysql을 사용해서 개발하는게 너무 당연했는데, 외주사에서 바라는 요구사항들을 들어줘야 하다 보니, 원래 쓰던 방법이 아닌 새로운 방법을 계속 찾아 나서야 했고, 그 과정에서 지식이 늘어날 수밖에 없었다.
아무튼...
개발은 잘 끝났고, 외주사 측의 QA 단계도 별 탈 없이 끝났다.
원하는 것을 유추해내서 개발하는 과정이 조금 오래 걸리긴 했지만... 그래도 시간과 별개로 정말 최선을 다해서 했던 것 같다.
첫 외주였던 만큼, 나의 역량을 최대한 짜내며 했던 것 같은데, 그럼에도 너무 부족함을 느껴서 아쉬웠다.
혼자 개발했던 만큼 코드적으로 어땠는지는 나 이후에 유지보수 하실 개발자 분의 의견을 들어보고 싶고, 문서화의 경우에는 주변에 계신 현업자 분들에게 여쭤가면서 만들었던 만큼 정답은 없지만, 그래도 알아보기 쉬울 정도의 문서화를 했다고 생각한다.
전에 모 대기업에서 인사를 담당하신 분과 이야기할 기회가 있었다.
그때 기업에서 뽑고 싶은 개발자는 어떤 개발자인지 여쭤보았다.
고민을 조금 하시더니 이런 얘기를 해주셨었다.
"아무래도 회사의 성장에 기여할 수 있는 개발자를 뽑고 싶겠죠?"
그래서 회사의 성장에 이바지 할 수 있는 개발자가 어떤 개발자인지 여쭤보았고, 웃으며 이런 질문을 던지셨다.
"그럼 영기는 두명의 개발자가 있는데, 둘 다 년차와 실력이 비슷하고, 인품도 보장이 되어 있다고 하면 어떤 개발자를 뽑을 것 같아요?"
"글쎄요... 저는 아무래도 말씀하신 능력치 이외에 그 사람이 어떤 특출난 특징을 가지고 있는지를 보려고 노력할 것 같아요"
"특출난 특징의 예시를 들어볼래요?"
"흠... 뭐 저를 예시로 들면 회복탄력성이나 능동적인 태도, 그리고 집요함인 것 같아요"
"그럼 그 세 개의 능력치가 지원하려는 회사에 어떻게 도움이 될까요?"
그래서 하고 싶은 말이 뭔데...?
보통 이 글을 읽으시는 분들은 스타트업 종사자 분들과, 대학생 분들이리라 생각한다.
보통 인사측에서 사람을 뽑으면, 후보군이 세 명 정도로 추려진다고 한다.
그 때 과연 어떤 경쟁력으로 뽑힐 수 있을까?
이 때 남들이 가지지 않은 킥이 하나쯤 있어야 한다고 생각한다.
그리고 이런 킥은 이렇게 개발 외적인 능력이 될 것이라고 생각한다.
개인의 능력치가 아니더라도 인맥 또한 여기에 포함될 수도 있다고 본다.
하지만, 나처럼 인맥이 없는 감쟈는... 뭐라도 개발해야 하지 않을까...?
아직 대학생이신 분들은 외주가 되었건, 협업이 되었건 같이 무언가를 만들어 보는 경험을 가져 보기를 추천한다.
제대로 문서화 되어 있지 않은 무언가를 소통이 되지 않는 누군가의 의도를 스스로 파악해서 실체화 하고 이를 개발하는 경험을 어디서 해볼 수 있겠는가?
과연 기획자가 던져주는 태스크의 의도를 파악하고 알잘딱으로 개발할 수 있는 능력치를 어디서 기를 수 있을까?
정말 체계가 잘 잡혀있어서 개발자가 문서나, 구두로 설명을 듣고 해당 서비스를 잘 개발할 수 있으면 좋겠지만, 애자일한 개발을 위해서는 이 알잘딱 능력치를 키워야 한다고 생각한다.
빠르게 서비스에 얼라인 하고, 여기서 기획자의 의도를 찾고, 능동적으로 디벨롭 할 수 있는 능력치.
아직 현업에서 일해보진 않았지만, 내가 처음부터 개발한 서비스가 아닌 무언가를 맡아서 디벨롭 해야 하는 상황이 생길 것이라고 생각한다.
그때마다 코드와 기획 의도를 기가 막히게 파내고, 능동적으로 디벨롭 할 수 있는 것이 회사를 성장시키는 개발자의 미덕이 아닐까?
이 빠르게 분석하고 능동적으로 무언가를 할 수 있는 능력치... 줄여서 알잘딱은 적어도 책으로는 배울 수 없다고 생각한다.
아무래도 회사도 알잘딱으로 최고의 프로덕트를 만들어 내는 개발자를 뽑고 싶지 않을까?
과연 이런 능력치가 서비스 개발에서 큰 비중을 차지하는지, 그리고 실제로 같이 일할 때 이렇게 개발 외적인 부분이 중요하다고 생각하시는지 여러분의 의견이 궁금합니다...!
