brunch

브런치북 조은 온 소프트웨어 11화

라이킷 17 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 하조은 Aug 01. 2022

내가 지키지 못한 조언들

매니저일 때 했던 조언을 개발자가 돼서 지키지 못하는 이유

이전 직장에서 마지막 1년은 매니저 역할을 맡았었다. 개발자 동료와 만나면 문제 해결을 위해 도움을 주곤 했다. 컨디션 조절을 위한 조언도 자주 했다.

현재는 개발에만 몰입하고 있다. 다시 개발자의 역할을 맡아 일하며 몇 가지 흥미로운 상황을 마주했다. 내가 매니저로서 조언했던 대로 행동하지 못하는 자신을 발견한 것.

오늘은 내가 지키지 못한 조언에 관해 이야기해볼까 한다.

1. PR은 작은 단위로 나눠서 올리세요

업무를 작게 나누면 예상 소요 시간을 파악하기 쉽다. 때문에 Jira 티켓도 작게 여러 개를 만드는 편이다. 커밋도 티켓과 마찬가지로 나눠야 한다고 조언하곤 했다. PR도 잘게 쪼개 달라고 했다. 리뷰할 때도 편하고 문제가 생겼을 때 원인 파악 및 롤백에도 도움이 되기 때문이다.

그런데 막상 나도 PR을 나누지 않는 경우가 많았다.

보통은 이런 상황이다. 새로운 기능을 추가하던 중에 다른 로직에 있는 이상한 함수명이 보인다. 혹은 구조적으로 아쉬운 부분을 발견한다. 기능상의 문제없지만, 눈에 거슬리는 컨벤션 오류를 발견한 것. 그 오류를 수정하다 보면 원래 만들려는 기능과는 무관한 내용의 커밋이 함께 딸려간다. 결국 PR에 설명을 구구절절 적게 된다. 그러다 보면 "아차, PR을 나눴어야 했는데..." 하는 생각이 든다.

요즘은 다시 브랜치를 생성하고 방금 작업한 로직만 cherry-pick 해서 새로운 PR을 만드는 수고로움과 이미 만들어둔 PR에서 구구절절 설명하는 수고로움, 둘 중 무엇이 더 귀찮은지 고민하고 조금 더 편한 방식을 선택하고 있다.

2. '완벽'보다 '완성'이 중요한 경우도 있어요

같이 일하던 동료는 본인이 완벽주의 성향이 강하다고 했다. 그래서 늘 코드를 완벽하게 만드느라 시간을 쓰곤 했다. 일정에 지연이 생길 정도로 시간을 할애한 건 아니었다. 다만 야근, 주말 근무 등으로 개인 시간을 과도하게 할애했다. 건강을 해칠까 걱정돼서 당장의 완벽함을 포기하고 넘어가길 자주 권했었다. 일단 어지르면서 만들고 나중에 다시 고치자는 의견이었다. 잘 정돈하면서 개발하면 좋지만, 항상 그렇게 할 수 있는 건 아니라고 말했었다.

그런데 나 역시 완벽함을 포기 못해서 밤을 지새우는 일이 잦았다. 서비스의 요구 사항과 무관하게 개발자로서 채우고 싶은 완벽함을 추구하다 보니 밤낮없이 일하게 됐다. 요구사항만 충족하는 건 제한 시간 내에 끝내고 일찍 잘 수 있는 정도였다. 하지만 만족할 수가 없었다. 그저 그런 코드를 방치하는 건 내 자존심이 허락하지 않았달까. 막상 다음날 보면 그다지 훌륭한 코드가 아니었다는 생각이 들지만, 욕심을 버리기 힘들었다.

3. 매몰되지 말고 큰 그림을 보세요

동료가 완벽에 대한 욕심을 버리지 못할 때 종종 했던 조언이다. 개발자로서 좋은 코드, 양질의 코드를 작성하는 것도 중요하지만 더 중요한 건 서비스가 살아남는 것이다. 그리고 그걸 지속할 수 있는 개발자의 건강이 중요하다. 우리는 장거리 마라톤을 달리고 있으니 너무 단거리 스프린트처럼 혹사하진 말라는 의미였다.

예상했겠지만 나는 나를 누구보다 혹사하고 있었다. 자려고 누워서도 코드 생각을 했고 좋은 방법이 생각나면 잠깐 일어나 노트북 앞에 앉았다. 지속 가능한 생활 패턴이 아닌 것을 알면서도 당장 눈앞에 있는 문제를 해결하는 재미에 푹 빠져버렸다. 단거리 스프린트처럼 질주했다.

조언을 지키지 못하는 이유

PR을 나누지 않는 건 게으른 탓이라고 볼 수 있다. 하지만 완벽을 추구하면서 매몰되어 자신을 무리하게 혹사하는 데는 다른 이유가 있다. 개발에 중독성이 있다는 점이 조언을 무시하게 만드는 가장 큰 이유다. 엔도르핀이 돈다고 해야 할까. 개발의 중독성을 배가시키는 몇 가지 요인이 있다.

1. 코드를 짜는 즐거움

개인적으론 초안을 쓰고 퇴고하는 과정을 즐기는 편이다. 그래서인지 코드를 붙잡고 이리저리 좋은 방식으로 바꿔보는 게 참 즐겁다. 더 간결한 코드로 복잡한 로직을 처리할 수 있도록 만들거나 더 명시적인 이름을 지어가는 과정이 즐겁다. 정돈된 코드를 보면서 잘 읽힌다는 생각이 들 때의 뿌듯함과 즐거움이 있다.

2. 서비스에 대한 책임감

서비스의 디테일을 가장 잘 이해하고 있는 건 개발자다. 매니저, 기획자가 인지하고 있는 서비스에 대한 이해와는 결이 다른 부분이 있다. 사소한 성능의 차이나 결함을 누구보다 잘 알고 있다. 가끔은 코드 한 줄까지 기억해 버그의 이유까지 짐작할 수도 있다. 그래서 책임감도 크게 느낀다. 내 실수로 서비스가 망가질까 노심초사하게 된다.

3. 메이커 간의 연대감

함께 제품을 만드는 메이커들과 연대감도 중요하다. 백엔드 엔지니어와 API를 정의하고 약속한 데이터가 오가며 새로운 기능이 구현된다. 디자이너가 제안한 디자인을 구현하고 디테일을 수정하면 처음 상상했던 서비스가 완성된다. 이 모든 개발의 과정에서 느껴지는 특별한 연대감이 더 서비스 개발에 몰입하게 만든다.

내로남불

"내가 하면 로맨스 남이 하면 불륜"

이중잣대를 들이미는 상황을 절묘하게 설명한 이 표현을 매니저일 때와 개발자일 때 다르게 행동하는 내게도 적용해볼 수 있을 것 같다. 어쩌면 이중잣대의 간극을 좁혀나가는 게 성장하는 좋은 방법이 아닐까. 내가 뱉은 말만 잘 지키면서 일해도 대단한 사람이라 생각하는 요즘이다.

keyword

Brunch Book

조은 온 소프트웨어