서론

개발자로 근무하면서 첫 3년 9개월 정도의 정직원으로 근무했었는데 이때는 수동적인 개발자였던걸, 프리랜서 개발자로 근무한 5개월 정도에 많이 느끼게 되었다. 이걸 공유해 보려고 한다.

첫 프리랜서로 근무하며 느낀점

난 수동적인 개발자였다.

서빙로봇 도메인을 가지고 있는 회사에서 관리자 페이지를 개발하게 되는 기회를 갖게 됐다.
기존 정직원으로 일할 때는 내가 기획자, 프론트 분들과 직접적인 얘기를 하고 회의를 하며 기능을 개발한 적이 없고, 파트장님을 통해 업무지시만 받았고 문제가 있을 때도 리더에게 공유를 하면 파트장님이 타 부서 사람들과 이야기를 하는 방식으로 진행했었다. 이게 핑계가 되진 않겠지만 파트장님이 시키신 일만하게 됐고, 버그 픽스 정도가 아니면 내가 서비스를 개선하고자 더 생각해보진 않았었다.

더 나은 서비스를 위해 끊임 없는 생각과 의견 공유

프리랜서로 근무하는 곳은 PL이 있고 기획자, 프론트, 백엔드가 한팀이 되어 직접적으로 이야기하고 진행하는 방식의 환경이었다.

이런 상황이다 보니 기능에 대한 의문점, 개선점이 있는 경우 내가 먼저 얘기를 꺼내고 이야기를 통해 좀 더 나은 방향으로 진행했다. 이런 환경을 접하다 보니 PL에게 지시받은 기능구현을 넘어서 어떻게 해야 좀 더 나은 방향이 있을지 생각하게 됐고 의견이 받아지기도 때로는 기각 되기도 하면서 서비스를 어떻게 더 좋아지게 할 지 생각 하게 됐다.

물론 내 모든 생각이 받아들여 지진 않았고, 바꾸지 못한 것에 대한 아쉬움도 있는 부분이 있다.(링크)

내가 나가고 난 그 후는? -> 남들이 보기 좋은 코드는 무엇이지?

프리랜서로 1~2주 근무 하면서 새로운 기능을 계속 개발하는 도중 내가 나간 후 이 코드는 남으신 분들이 개선작업 또는 버그가 있을 경우 쉽게 건들 수 있는 코드인가? 라는 고민을 하게 됐다.

이 때부터 단일 책임 원칙을 최대한 지키면서 클래스에 기능을 최소한으로 하고 한 클래스에서 여러가지 작업을 하지 않도록 클래스별 기능을 많이 나눴다. 이제 정답인지는 잘 모르겠지만 코드 분석을 할 때, 해당 클래스가 어떤 역할을 하는지 클래스부터 인지하고 볼 수 있도록 하기 위해서 였다.

또한 메서드에 코드를 나열하기 보단 메서드도 잘게 쪼개서 메서드명으로 어떤 기능을 가지고 있는지 메서드명의 흐름으로 기능을 읽기 편하도록 코드를 짜기 시작했다. 이게 클린코드에서 함수를 최대한 간결하게 였던것 같다.

결론

3년 9개월의 정직원으로 개발한 시간보다 5개월이지만 잠깐의 프리랜서로 근무하면서 내 코드의 품질을 생각하게 됐고, 더 나은 서비스를 위해 어떤 방향성으로 코드를 작성해야하는지 생각하게 됐었다.