데이터를 통한 개발력 측정

코딩시간 측정을 통한 나의 개발력 분석

요즘 정말 유라임 (필자의 스타트업 프로덕트) 개발이 재밌다. 분명 3개월 전만 해도 개발력이 너무 떨어져서 걱정했었는데, 워낙 유라임 개발이 재미있는 나머지, 하루의 대부분의 시간을 유라임 개발에 할애하고 있다. 몇몇 서비스 개발이 끝났다. 게다가 많은 컴포넌트에 대한 재활용이 가능하고, 나름대로의. Redux 패턴을 잡아놓으니 되려 내 유라임 서비스에 이렇게 잘 맞는 것이 있나 싶을 정도.

남은 작업은 설정과, 몇몇 UI적인 부분, 그리고 모바일이다. 사실 리엑트를 통해 모바일 컨버팅을 쉽게 하자고 했는데, 막 생각만큼은 잘 되지 않았다. 뭐 CSS도 새로 만들어야 하고 그런 부분은 당장 하기에는 너무 작업이 크다. 대신, 유라임 자체가 반응형 웹이기 때문에 당장은 웹뷰를 써서 앱을 개발하자 라는 취지. 사실 앱도 막 필요한 것은 아니지만, 유저에게 Apple Health를 제공해 주기 위한 선택이긴 하다.

그리고 페이스북과 Wakatime이라는 코딩시간 측정 앱의 데이터 연동. 아마 이 부분은 가장 나중에 해도 될 것 같다. 당장 중요한 것은 Planning을 더 쉽게 하는 planner에 대한 개발인데, 시안은 어느정도 나와있는데 기능적 구현이 정확히 돌아갈지는 미지수이다. 뭐 이것도 어느정도는 완성해 둬서 금방 끝날지도.

중요한 것은 차트이다. 너무 많은 종류의 차트를 고민하다 보니 개인적으로도 어떤게 답인지 모르겠다. 그냥 한두 종류의 차트만 정해두고 이를 위젯 식으로 하는 것이 가장 좋을 것 같은 느낌이다. 차트도 최근에 우버에서 개발한 React-vis를 사용하게 되었는데, 아주 생각보다는 이쁘지는 않아서, 게다가 인터렉션도 크게 없는 듯 해서 살짝 고민이긴 하다.

여하튼 10월 초에는 베타 서비스를 하려고 노력하고 있는데, 남은 시간이 별로 없다. 3주 정도? 이 시간동안 얼마나 더 작업을 할 수 있을까. 요즘 하루에 코딩을 약 6시간 정도 하는 것 같은데, 그 이상을 더 하기는 조금 힘들기도 하다. 때문에 체력관리에 대한 관심이 급증하고 있는데, 체력을 저하시키는 많은 것들을 억제하려고 노력하고 있다.

최근 30일간의 코딩시간

결국 주말을 제하면 주중 30시간, 유라임 개발에 박찰을 가하기 시작한게 7월과 9월 지금까지의 4주 정도인데 (8월에는 한국 방문을 해서 약 2주정도 못했다.) 토탈 약 2개월 정도를 총 8개의 모듈 중에 5개를 끝냈다.

최근 유라임 git commit 캘린더 차트

그런데 또 생각해 보면 초기에는 Redux 패턴을 잘 잡지 못해서 보낸것과, props, state에 대한 이해 부족 등이 있어서 개발을 무조건 모듈 단위로 해야한다는 생각에 좀 더 삽질을 했던 것 같다. 그래서 처음에는 모듈 하나 개발하는데 2-3주 정도를 보냈는데, 최근 개발을 완료한 체크리스트의 경우에는 유라임 모듈 중 가장 단위가 큼에도 불구하고 2주 정도 걸려서 마무리를 했던 것 같다.

2017.06.01 ~ 현재까지 코딩시간 측정

그런데 이 뭔가 리엑트를 배우면서 생겼던 진입장벽에 대한 체크는 힘들까, 아마 코딩 시간으로 측정되지 않을까. Wakatime의 코딩시간을 측정해 본다면, 본격적인 개발이 시작된 6월에는 유라임 작업 (파란색) 이 거의 없다. 이 때에는 Udemy등의 강의를 들으면서 리엑트에 대한 이해를 높혀갔다.

6월의 코딩/디버깅 시간

그러다가 7월이 되고나서 본격적으로 유라임의 리엑트 마이그레이션을 시작했다. 특히 말일이 갈 수록 코딩 시간이 늘어나는 모습을 볼 수 있었다.

7월의 코딩/디버깅 시간

8월에는 한국에 2주나 다녀왔음에도 불구하고 7월보다 10시간이나 더 작업을 했다. 지금도 그렇지만 거의 이때쯤에는 “중독” 수준이었다. 머릿속에는 온통 리엑트를 통해 접한 버그를 어떻게 해결할지에 대한 생각 뿐이었으니 말이다.

8월의 코딩/디버깅 시간

그리고 9월이 된 지금, 아직 말일이 되지 않았는데도 오늘까지 개발하면 곧 100시간을 채울 것 같다. 뭐사실 하루에 코딩 8시간씩 1주 40시간, 1개월 160시간 에 비하면 아무것도 아니지만, 순수한 코딩과 디버깅(크롬) 활동만 가지고 툴로 측정한 시간이기 때문에 웹서핑 미팅 등의 시간은 순전히 제외하고 측정된 결과라서 개인적으로 더 보람차다고 생각한다. 참고로 크롬은 오로지 디버깅만 쓰고 주력 브라우저는 사파리를 사용한다.

9월 현재까지의 코딩시간

확실히, 코딩시간이 늘어나니 제품의 완성도도 늘어나고 있고, 꾸준히 개발을 하다보니 코드에 대한 가독성, 모듈화 등 많은 부분이 안정이 되어가고 있다. 

나는 개인적으로 모든 코딩이 이와 비슷하다 생각한다. 진입장벽이란 것은 어느 언어이던 존재한다. 나는 백엔드 개발자이기 때문에 사실 6월에 처음으로 ES6를 접했고, 내 주력인 스칼라/자바 가 아닌 자바스크립트/크롬 의 입지가 훨씬 높아졌다. 음, 이건 좋아해야 하는지는 모르겠지만 말이다.

6월부터 현재까지의 개발언어 비중

그래서 최근에는 조금 더 정체성에 혼란이 오긴 한다. 내가 프론트 개발자인지 프론트에 관심이 있는건지 등등등. 하지만 나의 관심사는 언제나 백엔드이고, 프론트는 개인적 관심사로 두기로 했다. 아무래도 프론트를 전문적으로 다루기에는 아직은 좀 무리가 있지 않나. 거의 전반적인 커리어를 바꾸는 수준이 될수도 있다는 생각이 드니 말이다. :)

여하튼, 결론은 내가 생각한 베타 기간정도에는 유라임이 어느정도 나오지 않을까 라는 생각이다. 그간 총 코딩한 시간인 268시간 동안 모듈 8개 중 5개를 끝냈으니, 단순 계산으로는 모듈 한개당 약 53시간이 소요된다. 그런데 보통 디버깅:개발 이 약 6:4 이기 때문에 디버깅 시간이 1/2 정도 줄어들게 되면 (가능할지는 모르겠지만) 약 30%의 시간을 줄일 수 있으므로 37시간으로 줄일 수 있다. 게다가 갈수록 모듈들이 재활용이 되기 때문에 어느정도 알파값을 고려하게 되면 35시간 내로 개발이 가능하지 않을까. 

그럼 1주 조금 더 노력해서 개발한다 하면 3개의 모듈까지는 3주가 남았다는 말이니 정말 저 데이터만 따지면 불가능한 일은 절대 아니다. 다만 중간에 별 탈이 없이 하루에 온전히 6시간 이상 개발이 가능해야겠고, 조금 더 노력한다면 8시간 내지는 10시간까지는 코딩시간을 늘려봐야 하는 것이 더 정답인 것 같다.

데이터는 거짓말을 하지 않지만, 인간은 다양한 변수가 존재하는 것 같다. 3주 뒤에는 그때 또 수집된 데이터를 가지고 이 글과 비교하면서 어떻게 되었을지를 한번 작성해 보려고 한다. 예정 시간보다 늦춰지거나 빨라졌다면 어떤 요인이 존재했는지 등에 대해서 말이다. 재밌는 데이터의 세계인 것 같다:) 

글쓴이: 메튜장 | matthew@urhy.me | http://www.matthewlab.com