구르는 동그라미

이전 회사에서 SSD FW를 개발할 때에는 sprint에 작업하기로 한 task가 변경되는 일이 거의 없었습니다.
제품의 완성 기한이 정해져있고, 필요한 기능들이 추가되면 수시로 backlog에 넣지만, 이 sprint에 작업 순서를 바꿔서 완료해야 하는 일은 거의 없었어요.

일정을 크게 나누어서
- SSD의 일반 동작부터 개발/검증 하고
- 특수 상황의 동작을 개발/검증 하므로
큰 일정 내에서는 급하게 순서를 변경할 필요가 없었어요.
간혹 특정 모듈이나 기능에서 예상 보다 버그가 많이 나오거나, 해결에 시간이 오래 소요되면, 하던 작업을 멈추고 투입되기도 했지만요.

현재 회사에서는 서비스를 제공하기 때문에, 주기/비주기적으로 개선 버전을 배포합니다.
이 때, 배포 주기와 개발 sprint 기간이 일치하지 않다보니 기획적으로 기능의 배포 순서가 바뀌면 backlog task의 우선순위가 바뀌거나, 예정에 없던 task가 생기기도 합니다.

작업량이 많아서 두 sprint로 나눠서 작업하려다가, 중간에 우선순위가 바뀌면 참 찝찝하기도 하고,
우선순위가 바뀔정도로 급한 일이 들어왔다는 얘기라서 task 크기에 따라 정신없이 바빠지기도 합니다.

네,  계속 바쁘네요

석사를 마치고 입사했던 첫 회사에서 저는 예상보다 스트레스를 많이 받았습니다.

주변에서 주는 스트레스 외에 업무를 하면서도 스스로 받는 스트레스가 많았어요.

새 프로젝트에 들어가면서, 서로 코드 리뷰를 진행하며 한참 개발에 열을 올리던 시기였습니다.

기존의 코드를 기반으로 개선하는 것이 아니라, 각 모듈별 기능을 정의한 후 새롭게 작성하는 프로젝트였어요

이 프로젝트의 코드가 이후 후속 프로젝트의 기반 코드가 되는 것이었지요.

몇몇 책임/수석급 선배분들께서 제가 코드 리뷰/분석을 할 때 스트레스를 많이 받는 것 같다는 얘기를 해주셨습니다.

이후에 코드 리뷰/분석을 하다가 돌아보니, 확실히 스트레스를 받고 있었어요.

특히, 기존의 안좋았던 코드를 답습하면서 가독성이 굉장히 나쁜 코드를 볼 때 스트레스가 심했습니다.

 - 의미를 명확히 알 수 없는 변수 (e.g. bool request - request를 해야하는 것인지, request를 했다는 것인지)

 - state(enum)를 가지면서 boolean 값에 따라 두 가지 상태를 내포하는 복잡한 상태 천이

 - 등등

모처럼 새롭게 만드는 프로젝트인데, 저는 몇몇 동료분이 대체 왜 그러는지 이해할 수 없었습니다.

당시의 저는, 이렇게 작성된 코드들은 전부 '하기 싫어서 대충 작성한' 결과라고 생각했거든요.

이런저런 조언을 해주시던 선배분들은 그것이 '하기 싫은 결과'가 아니라 그 사람의 '한계'라는 얘기를 해주셨던 기억이 납니다.

단지 실력 부족에 의한 '한계'이거나, 과거 프로젝트가 너무 익숙해져서 그 스타일이 몸에 밴 것일 수도 있을 것 같네요.

저는 최근에 서버 API 변경에 맞춰서 일부 모듈의 리팩토링을 같이 진행하고 있습니다.

API와 직접 연관된 부분만 간단히 수정하려 했는데, 줄줄이 연결된 레거시가 너무 많네요.

깔끔해져 가는 코드를 보면 너무 기분이 좋은데, 예상하지 못한 레거시를 추가로 분석하고, 믿었던 코드에 배신을 당하면서 스트레스가 심해지는 것 같아요.

다시 한 번 생각해 봅니다. 이게 그 사람의 한계였을 것이다.

저는 새로 접하는 소스 코드를 살펴볼 때 여행을 떠난다고 표현하곤 합니다.
 💬 ☆☆모듈의 코드 여행을 다녀왔습니다

이전 회사에 입사해서 배정된 팀은 구조가 조금 이상했는데 리더를 제외하면 다음의 형태였습니다.

• 수석급 2 명 / 책임급 1 명
• 선임급 2 명 / 사원급 2 명
• 신입사원 3명

사원/선임/책임급은 학/석/박사 입사 2년차 이하였기에, 2년차 이하의 집단이었습니다.

허리층이 없는 구조인데, 원해서 만들어진 구조는 아니었고 인력을 막 모으던 팀이었죠.

팀분들께 프로젝트에 대해서 질문을 하기 좋은 상황은 아니었지만,

저는 도움을 받는 것 보다는 직접 파악하는 것을 선호하였기 때문에 큰 문제는 없었습니다.

오히려 코드 여행을 떠나기에 최적의 팀이었죠.

여행을 다녀오면, 본 것들을 공유 하기도 했고, 자연스레 세미나 준비도 잘 했던 것 같습니다.

그 때는 참 의욕적으로 코드 여행을 떠났는데, 다음과 같은 이유가 있던 것 같습니다.

• 처음 접한 모듈(FTL)이 신기하고 재미있어서
• 빨리 한 사람 몫을 하고 싶어서
• 맡은 업무(버그) 처리를 위해서

이렇게 코드 여행을 떠나면서 스스로 코드를 살펴보던 것이 많은 도움이 되었는데요,

지금은 구조가 다소 어색한 프로젝트를 보는 것에 거부감이 없고, 동작이 잘 정리되지 않은 코드도 조금 더 빠르게 파악할 수 있게 된 것 같습니다.

(덧)

개인적으로는 입사 초기에 프로젝트 구조를 깊게 잘 파악했던 덕분에,

• 이후에 TF팀에서 새롭게 모듈을 설계할 때도 활발히 참여할 수 있었고,
• 중요 모듈을 메인으로 개발할 수 있었고,
• 다양한 버그 이슈 대응에도 투입되었고,

꽤나 중요한 팀원이 될 수 있었던 것 같습니다.

HR과 퇴사 면담 때, 팀 리더로 부터 잡아야하는 인재라는 얘기를 들었다며, 리텐션 옵션을 제안 받기도 했습니다.

참 감사하고, 보람있는 순간이었죠.

다만, 쓰레기같던 옆 팀 리더 때문에 퇴사하는 것이었기에, 제안은 거절하고 나왔습니다.

2년차 주니어를 지원하고 있습니다.

팀을 옮겨온 분이어서, 프로토타입 기능을 개발하면서 적응을 유도하고 있는데요,
필요한 부분에선 소극적이고, 수용해야 할때는 고집을 부려서 스트레스가 심합니다.

어떻게 하면 좋을지 고민을 해야겠어요.

이전에 3년 정도의 개발 경력이 있는데 중고신입으로 입사했다고 들었는데,

신입사원과 별로 차이가 없어서 실망스러운 것도 있습니다.

설계를 고민을 좀 해야하는데 고민의 흔적이 전혀 없어요.

한 번은 이상한 구조를 "어색하니 수정합시다" 라고 코멘트를 남겼더니, "저는 어색하지 않습니다" 라는 답이 왔어요.

이곳 저곳을 살펴야 하는 큰 구조 변경을 요구하면, 일단 반항적인 자세를 취합니다.

코드와 본인을 일체화해서 방어적인 것인지, 일이 커지니 짜증을 내는 것인지 알 수가 없어요.

상대가 스트레스받지 않게 최대한 좋게 말하고 돌려 말하니 무작정 거절해도 된다고 생각하는가 봅니다.

이제는 "이상한 것"과 "불쾌한 것"을 직설적으로 얘기하고 있습니다.

상대의 스트레스 보다 나의 스트레스가 더 중요하니까요.

남을 배려하지 않는 사람까지 배려하고 싶지가 않네요.