Day14. 4년 차 개발자 회고록
나의 전문성은 어디쯤에?
나는 안드로이드 개발자이다. 작년에 내가 작성했던 '2018 주니어 개발자 회고록'을 읽고 왔다. 그때의 설렘, 불안함이 느껴졌다. 사실 내가 얼마나 성장했는지, 개발자로서 어느 위치에 있는지 항상 불안하고 걱정됐다. 그런데 이 글을 쓰다 보니 그때보다는 한 뼘 더 큰 내가 보였다.
안되면 되게 하라 (1년 차)
처음 개발자가 되고 나서는 요청한 건 모두 되게 하고, 빨리 해내는 것이 능력이라고 생각했다. 그래서 못한다는 말이 실력이 없다는 말 같았다. 하지만 당시 경력이나 실력으로는 요청받은 일의 가능 여부를 판단하기 어려웠고, 된다고 생각했던 일이 예상보다 시간이 오래 걸리거나 불가능한 일들도 있었다. 그리고 전체 구조를 생각하지 못하고 무조건 되게 하려는 생각에 일관성을 해치거나, 나조차도 이해할 수 없는 코드들을 만들어 갔다.
더불어 아쉬웠던 점은, 혼자 모든 것을 하려고 했던 것이다. 개발을 하다 보면 개인의 역량이나 성향에 따라 더 잘하는 일이 있고, 업무에 따라 서버/클라이언트의 효율성이 다르다. 이런 부분을 판단하기 어려웠던 나는 일단 업무 요청을 받으면 어떻게든 현재 상황에서 혼자 할 수 있는 방법을 찾아서 했다. 경험이 쌓이면서 이런 부분들을 판단하는 능력이 생겼다. 지금도 이런 경험을 쌓기 위해 고민이 되거나, 잘 모르겠는 부분이 있으면 빠르게 공유하고 의견을 들어 더 좋은 방법을 찾기 위해 노력하고 있다.
예외처리 (2년 차)
빨리 하면, 놓치기 마련이다. 주니어 개발자에게 시간보다 빨리 만들었다는 것은 이 코드에서 발생할 예외사항을 더 생각해보지 못했기 때문일 수 있다. 그리고 이런 부분을 생각하지 못하기 때문에 과도하게 짧은 스케줄을 잡기도 한다. 경력 있는 개발자 분들이 나에게 첫 번째로 지적했던 부분이 바로 이 부분이었다. 나의 경력에서 예상 스케줄을 산정하기 어려운 게 당연하지만 구현에 치중해서 스케줄을 잡다 보니, 너무 일정을 타이트하게 잡았다. 이 때문에 오류를 찾아 수정하는 시간이 구현의 배가 걸리기도 했고, 스케줄을 지키기 위해 시간을 단축시키는 꼼수들이 늘어났다. 다른 부분을 포기해야 하는 악순환이 계속됐다. 결국 나도 돌다리를 두들겼고 넘어졌다. 이렇게 쌓인 예외처리들이 메서드가 되기도 하고, 나의 스케줄링의 정확성을 높여주고 있다.
우선순위와 제한시간 설정 (2년 차)
경력이 1년도 되지 않은 2018년, 새로운 프로젝트를 시작했을 때 사수가 없었다. 그렇다 보니 나의 업무를 모니터링해주거나 도와줄 사람이 없었다. 이 때문에 무언가 문제가 발생했을 때 하염없이 문제를 붙잡고 있거나, 갑자기 코드 품질에 꽂혀서 이미 구현된 코드를 고치고 또 고치며 시간이 흘러갔다. 이렇게 지나가는 시간들의 가장 큰 문제는 내가 이렇게 샛길로 샌다는 것을 인지하지 못하고 있다는 것이었다. 어느새 정신을 차려 보면 이미 그날 하루가 다 지나가 있었다. 이렇게 클라이언트 개발이 자꾸 밀리고 있었다. 클라이언트 개발이라면, 연극과 같다. 연극을 올리기 위해, 대본을 만들고, 무대를 꾸미고, 조명을 설치하고, 사운드를 준비하고, 배우들은 리허설을 한 뒤에, 사람들 앞에서 연극을 선보인다. 이전의 모든 과정이 준비되어 있어도 무대가 준비되어있지 않다면, 사람들에게 연극을 보여줄 수 없다. 우리의 서비스를 사람들에게 보여줄 수 없다는 것과 같았다. 나는 방법을 찾아야 했다.
바로 우선순위와 제한시간 설정이었다. 일을 하다 보면 프로젝트 일정, 제약 사항, 코드 품질 등 다양한 내용들이 고려사항이 되어야 한다. 먼저 고려하기 위해 업무를 최소 단위로 쪼갰다. 그러고 나서 해당 업무의 우선순위를 아래 그림에 따라 정해 나갔다. 이 과정에서는 반드시 운영진과 서버 개발자들과 충분한 협의를 거쳤다. 그와 동시에 나만의 시간을 정했다. 특히 중요하지만 긴급하지 않은 일들을 처리할 때 도움이 되었다. 한 일에 매몰되어 다른 것을 보지 못하는 나를 모니터링하기 위한 장치였다.
https://blessingyear.tistory.com/entry/%EC%9A%B0%EC%84%A0%EC%88%9C%EC%9C%84%EB%A5%BC-%EC%A0%95%ED%95위임하기 (3년 차)
프로젝트가 점점 커짐에 따라 새로운 개발자가 필요했고 여러 사람이 스쳐 지나갔다. 아이러니하게도 나의 일을 덜기 위해 새로운 사람이 올 수록 나는 더 힘들어져갔다. 여러 이유로 신입금의 개발자를 뽑게 되었는데, 이 상황은 나를 개발 실무뿐만 아니라 관리의 업무까지 해야 하는 상황을 만들었다. 말도 안 되는 코드들 때문에 한 줄 한 줄 코드 리뷰를 해야 했고, 업무 공유가 되지 않아 하루에도 몇 번씩 진행 사항을 물어야 했다. 지금의 상황에서 내가 계속 개발을 해야 한다면, 내 일을 위임하고 맡길 수 있는 사람이 필요했다. 이전의 일련의 과정들 때문에 지금의 동료에게 일을 온전히 맡기기 까지도 꽤 오랜 시간이 걸렸다. 하지만 이 과정을 통해서 정말 많은 것을 배웠다. 나는 물리적으로 한 사람이고 주어진 시간 안에 내가 할 수 있는 일의 총량은 정해져 있다는 것이다. 그래서 모든 할 수 있다고 말하고, 하는 게 능사가 아닌 내가 할 수 있는 한계를 알고, 또 누군가에게 일을 믿고 맡기는 일이 향후 내가 관리자가 되었을 때 꼭 필요한 덕목이라는 것을 배웠다.
내 코드의 고객은 나와 다른 개발자 (4년 차)
클라이언트 개발자로서 가장 중요하게 생각해야 하는 것은 앱을 사용하는 유저라 생각한다. 이는 외부적 요소이고 내부적인 나의 고객을 생각해보면 두 부류가 있다. 첫 번째는 업무를 요청하는 사람이고, 두 번째는 다른 개발자와 미래의 나이다. 어차피 내가 작성한 코드도 한 달만 지나면 새롭다. 그래서 요새 나의 화두는 유지보수이다. 서비스를 지속하는 한, 프로젝트는 계속 커질 것이고 새로운 코드들은 쌓여갈 것이다. 규칙 없이 쌓여 가는 코드, 설명이 필요한 코드, 여기저기 이름만 다르고 똑같은 역할을 하는 메서드 들은 매번 우리의 발목을 잡을 것이다. 적어도 내가 이전에 했던 실수를 반복하지 않기 위해, 어떤 개발자가 와도 빨리 적응할 수 있는 시스템을 만들고 싶은 것이 나의 소망이다.
앞으로의 나
오히려 전체를 보게 되니, 기본에 다시 회귀하게 된다. 불안하고 걱정되는 시기에 나는 트렌드를 쫓아 이것저것 기웃거렸다. 머신러닝이 뭔지, 파이썬이 뭔지, 요새는 플러터가 유행이라던데 어느 흐름에 자꾸 휩쓸렸다. 물론 이를 아는 건 중요하지만, 내가 업무에서 실제 맞딱들이는 것은 더욱 기본을 요구하고 있다. 최근에 있었던 일인데, 숫자를 비교하기 위해 BigDecimal로 변경 후, equal로 값을 비교했다. double에서 발생할 수 있는 문제점들을 알고 있었기 때문이다. 그런데 테스트 코드와 일반 기기 모두 성공하는 코드가, 특정 기기에서는 실패였다. 문제 발생 원인은 equals/compareTo의 차이를 알고 있는가, 안드로이드 기기별로 다른 CPU를 사용할 때 어떤 차이가 있을 수 있는가 하는 것이었다. 결국 기본이다.
이제 점점 더 구글링이나 스택오버플로우의 도움을 받기 어려울 것이다. 그리고 그럼에도 불구하고 문제를 해결할 수 있을 때 나의 성장을 느낄 수 있을 것이다. 존경하는 개발자 분이 버그를 찾느라 고생하는 나를 보면서 해주신 말이 있다. 문제의 발생 원인을 모를 때는 아닌 것을 제거해 나가면 된다고. 이를 위해 얼기설기 산재되어 있는 지식들을 한데 엮어 촘촘한 나만의 그물을 만들어 나가야겠다.
https://brunch.co.kr/@ethanchae/
출처
https://brunch.co.kr/@jin-lab/23
https://d2.naver.com/news/3435170
https://www.youtube.com/watch?v=U8Y3wZEtR98
https://okky.kr/article/370719
