brunch

You can make anything
by writing

C.S.Lewis

by 개발자 꿀 Jul 30. 2021

시니어 개발자 다음 단계

시니어 개발자는 어떻게 일해야 하는가

개발자 업무는 여러 차원의 일로 구성되며 ‘writing code’는 그중에 일부일 뿐이다. 그래서 잘하고 좋아하는 일이 개발자들마다 다르다. 나는 주로 하루 중에 상당한 시간 동안 남의 코드를 읽고 리뷰하는 편이었다. Git diff만 보고 네이밍이나 지적하는게 아니라 IDE에서 프로젝트를 열어서 앞뒤 문맥을 전부 읽으면서 리뷰하는데, 엄청나게 많은 시간이 들지만 이렇게 열심히 생각하면서 읽으면 프로젝트 사이의 의존성이나 테스트의 사각지대에 있는 이슈들이 보인다. 그게 재밌어서 우리 팀 PR의 거의 대부분을 읽었다고 감히 자부하고 암묵적으로 팀에서 중요한 수정에 마지막으로 approve 하는 사람이 되었다.

사실 거의 모든 개발자들이 직접 코딩하기를 선호할 것이다. 손 끝에서 시작한 int a = 1; 한 줄이 100라인, 1000라인으로 모양을 갖춰가는 모습 보기를 싫어하는 사람이 어디 있을까. 하지만 80/20 법칙대로 신나게 코딩을 할 수 있는 업무는 현업에서 생각보다 찾아보기 힘들어서 사람들은 일부러 이런 일을 만들기도 한다.

절대적인 프로그래밍 시간이 필요하다고 느꼈던 어떤 핵데이에서 우리 팀에서 작게 만들어서 쓰던 서비스를 스프링 부트로 새로 작성했던 적이 있다. 우리 회사에서는 백엔드용 사내 플랫폼이 따로 있어서 스프링 부트가 제1 선택지가 아니기 때문에 사람들의 호기심을 샀고, 시의적절하게 그 서비스를 확장해야 하는 흐름을 타고 수정의 용이함이나 좋은 만듦새에 대해 생각보다 훨씬 더 큰 칭찬을 받았다.

이 서비스는 우리 팀 DB 노드 개수를 동적으로 바꾸는 용도였는데 적은 양의 코드였지만 선뜻 손대기가 까다로웠고 정해진 답이 없었다. 그래서 팀에서 함께 서비스에 살을 붙이는 동안 하나를 더할 때마다 자잘한 의논이 많았던 것 같다.

나는 프로젝트를 다시 만들면서 약간의 맛을 더했다는 이유로 크고 작은 코드를 봐달라는 부탁도 받고 얼떨결에 검증단 같은 사람이 돼버렸다. 의견을 물어봐주는 것은 너무 고마웠지만, 결정이 내게 몰리는게 부담되고 업무량이 많아지는 악순환에 어느순간 갇혀있더라. 이건 일을 덜 하는 수밖에 답이 없었다. 절대적인 업무 시간과 에너지가 정해져 있고, 프로젝트는 더 이상 혼자만의 책임이 아니었기 때문이다. 나의 역할은 오히려 다른 멤버들이 그 프로젝트의 일을 할 때 병목이 되지 않고 도와주는 역할이 맞았다. 자잘한 수정을 전부 확인하고 말을 한 마디씩 보태면 팀은 scale 할 수 없다. 이 시기를 기점으로 일을 어떻게 손아귀에서 놔야 하는지 생각하기 시작했다.

말은 적절하게 하는 것도 중요하고 적절하게 하지 않는 것도 중요하다고 생각한다. 내 의견이 다른 의견보다 조금 더 중요하게 받아들여지는 것을 느꼈고, 내가 의견을 내면 결론이 너무 빨리 나고 의도치 않게 다른 사람들, 심지어 일을 주도하는 사람조차 참여할 시간이 없어진다는 것을 알았다. 때때로 책임감과 소유권을 누르지 못하고 필요 이상으로 큰 목소리가 터져 나오기도 했지만.

사실 프로젝트는 팀 업무로 승격(?)되어 더 이상 혼자서 모든 걸 책임질 필요가 없었고 내게 책임을 전가하는 분위기도 전혀 아니었다. 하지만 무언가 잘못되면 원인이 근본적으로 내가 한 작업에 있을 수도 있다는 생각을 무의식 중에 항상 가지고 있었다. 다 큰 성인 자식의 실수를 자신의 실수처럼 느끼는 부모의 마음이 마치 이런 걸까... DB 퍼포먼스에 영향을 주기 때문에 한동안 배포할 때마다 담당자가 밀착 모니터링을 하던 시기에는 직접 커밋을 하지도 않았고 온콜이 아닌데도 온콜 알람 채널을 밤낮으로 확인했다.

기저에 깔린 책임감은 생각보다 일이 너무 커진 데서 오는 당황스러움과 성취감의 부작용일지도 모르겠다. 코딩하고 싶어서 시작한 hack 프로젝트가 어쩌다 보니 생각보다 유용하고 잘 만들어졌다고 밝혀졌을 때, 초기의 훌륭함을 끝까지 끌고 가고 싶은 욕심이 되고, 욕심은 자연스럽게 심리적 부담감과 스트레스로 발전한다. 하지만 나는 상황을 쿨하게 받아들였어야 했다. 나의 소임을 다 했다, 장애가 발생하더라도 같이 해결할 사람들이 있다, 그러니까 혼자 일하는 사람처럼 오버하지 말자고.

마냥 한없이 쿨할 수 없었던 이유는 책임감을 놓고 싶어 하는 동시에 끊임없이 프로젝트의 상태를 알고 싶어 했기 때문이다. 그래서 더욱 사소한 리뷰나 작은 회의 하나하나를 포기하지 못했다. 혼자서 코딩을 하면서 가능한 상황을 상상하고, 초기 설계 안에서 이렇게 하면 된다 저렇게 고치면 된다는 마음속 답이 어느 정도 있었다. 하지만 이런 걸 전부 다른 사람들이 알리가 없을뿐더러 그 사이 프로젝트가 커져서 앞서 상상하던 문제에 부딪혔다 해도 내 처음 생각대로 문제가 해결되지는 않았을지도 모른다. 그러나 해결 방안이 개인적 초안과 달라질 때, 나의 아름답게 완성된 디자인을 망친다는 불안감이 들면서 그러한 선택을 할 수밖에 없는지 논리적으로 납득되길 원했다. 앞서 말했듯 결정 과정에서 내 의견이 중요하게 받아들여질 수 있다는 점을 언제나 염두에 두고 있었으므로 나는 보통 입을 다물고 있는 편이었지만, 과정에 끊임없이 동참했던 뒤편에는 이런 이유가 있었다.

작년부터 다른 사람들을 내 아이디어에 일찍 자주 참여시키라는 피드백을 받았다. 이 피드백은 다른 말로 하면 내가 문제 제기를 하고 일을 시작할 때 처음부터 끝까지 혼자 승부를 보지 말고 팀 사람들을 이 일에 참여시켜서 마치 팀 안에 더 작은 팀처럼 일을 하라는 뜻이다.

처음에 이 피드백을 받았을 때는 무슨 뜻인지 잘 이해를 못 했는데, 여태껏 구구절절 설명한 사건을 경험하는 동시에 시니어로 승진하면서 이 피드백을 두 가지 방법으로 적용할 수 있다는 생각을 했다. 우선 생각을 구체화하는 단계에서, 아이디어를 미완성의 상태로 사람들과 의논하고 좀 더 발전시켜서 다시 사람들과 이야기하는 방법으로 짧은 주기로 피드백을 받아서 팀과 함께 아이디어부터 솔루션 구상까지 차근차근 밟아 올라가기.

두 번째는 구현에서, 책을 쓸 때 챕터를 나눠서 사람들과 챕터를 각자 맡아서 책을 완성하는 것처럼 일하기. 이때 토씨 하나하나를 트집 잡듯 피드백을 주지 않도록 조심하고 해당 챕터의 소유권을 작업하는 사람이 온전히 느낄 수 있게 한다.

처음 디자인 단계부터 사람들의 머릿속 싱크가 잘 맞고 계획이 잘 공유되어야, 구현 단계에서 모두가 서로 맡은 부분에 집중하면서도 개개인의 작업물이 한차례 다 같이 동의한 방향으로 자연스럽게 흐를 수 있다.

지금 내 단계에 팀 안에서 요구받는 역할은 바로 이런 것이다. 그림을 제시해주고, 독립적인 contribution을 할 수 있게 뒤에서 받쳐주면서 개인의 성장을 도와 결국 팀이 성장하게 하는 것. 이걸 깨닫고 실천해서 나의 성과로 만드는 과정은 혼자 코딩하고 문제를 해결하면 되는 단계와는 다른 험난함이 있는 것 같다. 그걸 처음으로 가르쳐준 게 여태 말했던 프로젝트였고. 이게 어마어마한 프러덕트도 아니고 엄청난 아이디어의 구현도 아니었지만, 개인적 시작에서 팀의 일로 바꾸는 과정에서 전에는 몰랐던 고민이 있었기 때문에. 동시에 다시 한번 개발자의 업무에는 다양한 스펙트럼이 있고 나는 아직 그 전부를 보지 못했다는 생각을 한다.

June 22 2021

#개발자 #해외취업 #해외이직 #개발자승진

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari