brunch

You can make anything
by writing

C.S.Lewis

by 밍풀 Jul 03. 2024

미국 개발자 이야기: 한 달간의 프로젝트가 끝났다

그에 대한 회고


드디어 6월부터 시작된 한 달간의 프로젝트가 끝났다.



정확히는, 모든 코드 변경과 테스팅은 끝났고 나머지는 운영 환경(production)에 배포해서 개발(dev), 통합(integ) 환경에 테스팅한 것과 같은 결과가 나오는지 지켜보는 것만 남았다. 덕분에 새로운 팀으로의 온보딩에도 여유가 생겼다.





 불과 1년 전만 해도,  ‘믿고 맡길 만한 사람’이 되고 ‘일을 더 잘할 수 있는지’에 대해 많은 고민을 했다. 그래서 당시 한참 베스트셀러로 유명했던 ‘세이노의 가르침’이라는 책을 읽고 많은 도움을 받았다. 특히 책에 나온 다음의 내용들은 일 머리가 부족한 나에게 하나하나 피와 살이 되는 말들이었다.


1) 반복적인 일의 개선점을 찾아내기
2) 행동하기 전에 일에 필요한 지식을 반드시 흡수하기
3) 실수하지 말기
4) 효율적으로 일하기
5) 경험자들의 의견을 반드시 듣기


이번 프로젝트를 하면서도 그때 책에서 배운 내용을 조금이라도 접목시키려 했다.






막 프로젝트를 시작했을 때


최대한 많은 시간을 들여 프로젝트에 필요한 모든 배경지식을 긁어모았다. 특히 다음과 같은 항목에 집중했다:




프로젝트의 필요성 (현재 팀의 문제점 설명 및 타임라인 포함)

프로젝트의 목적과 기대 성과

프로젝트를 완수하기 위해 쪼갠 세부 업무(task)들

각 단계별 코드 변경 내용 설명

세부 업무(task) 테스트 및 확인 방법

개발(dev)/통합(integ) 환경의 적합성 평가

비기술직을 위한 데이터 결괏값 제공 (예: Metrics, Grafana Dashboard)

필요에 따른 스크립트(script) 작성

코드 변경이 다른 종속(dependency) 팀과 연관되어 있는지 확인






코드 변경 시 주의사항


이전 경험을 통해, 너무 많은 코드 변경을 하나의 PR(Pull Request)에 포함하지 않기로 했다. 큰 덩어리의 코드 변경은 디버깅과 테스트 시 예상치 못한 많은 에러를 발생시킬 수 있기 때문이다. 따라서 단계별로 코드를 나누어 테스트하고, 문제가 생기면 쉽게 원인을 찾을 수 있도록 했다. 이렇게 할 경우, 다음 스텝으로 넘어갔을 때도 에러가 발생하면 어디에서 문제가 생겼는지 찾기 쉬워진다.




프로젝트 진행 중, 중요 요소: 소통과 적절한 도움 요청


여느 프로젝트들이 그렇지만, 직장인 4년 차가 되면서 절실히 느낀 것은 “소통”이었다.


이번 프로젝트는 처음부터 끝까지 자율적으로 진행했지만, Principal Engineer와 매니저에게 지속적으로 보고했다. 무엇보다 내 선에서 맞다고 생각하는 코드 변경과 테스팅 과정이 다른 사람들 눈에는 모호하게 들릴 수 있다는 걸 알게 된 후, 매니저가 물어보지 않아도 자발적으로 프로젝트 진행 상황을 투명하게 업데이트했다.

 




Principal engineer와의 소통


디자인 다큐먼트 작성 과정:   

Metrics가 테스트 증명에 적합한지 확인

Phase 1, 2 계획의 타당성 및 코드 변경이 프로젝트 목적에 부합하는지 확인

디자인 다큐먼트의 기술적 검토 요청


코드 변경:   

Phase 1: 코드 변경과 테스트 순조롭게 마무리

Phase 2: 코드 변경과 디버깅을 위해 Principal Engineer의 도움 요청



매니저와의 소통


디자인 다큐먼트가 비기술직 매니저와 VP에게 이해되도록 작성:   

1주 차: 디자인 다큐먼트 작성 및 3주 계획 설명

2주 차: Phase 1 완료 및 결과 보고

3주 차: Phase 2 진행 및 종속 팀의 영향 검토

4주 차: Phase 2 완료 및 결과 보고, production 배포 준비







프로젝트 진행 중 어려움


내가 나눈 옵션 1, 2, 3이 각각의 코드 변경으로 인한 버그 대문에 개발 환경(dev environment) 테스트를 통과하지 못했다. 개발 환경에 나온 로그 메시지로는 원인을 알 수 없어 DevOps에서 로그 메시지를 더 확인했지만 그럼에도 정확한 이슈를 잘 찾지 못했다. 결국 3주 차가 되었을 때 Principal Engineer의 도움을 요청해 디버깅을 했다.





함께 디버깅하면서 알게 된 것은, 내가 변경한 코드로 인한 문제는 아니었다.


1. 다른 개발자의 테스팅 버전으로 인한 오류
당시 나 말고 다른 레포지토리(repository)에서 개발 환경(dev environment)에 테스팅하고 있던 다른 엔지니어의 PR 버전이 그대로 사용되고 있어서 그걸로 인한 문제 발생이었다. 그래서 마스터 버전(master version)을 배포한 다음 내 것을 다시 배포하니 그전에 발견한 에러 메세시는 사라졌다.



2. 사소한 포맷 이슈

그전까지는 자원(resource)을 따로 쓰면서 이런 작은 오류가 무시되고 예외(exception)에 안 잡혔다가 내가 만든 코드 변경으로 잡히게 됐다. 이 포맷 이슈를 해결한 뒤로, 내 코드 변경 테스팅은 순조롭게 통과됐다.

 



당시 모든 코드 변경에 생긴 문제로, 당장 어디부터 손봐야 될지 감이 안 잡혔다. 그러나 그마저도 문서로 정리하니 나중에 principal engineer한테 어떤 것에서 막혔는지 간결하게 설명하기 훨씬 수월했다.


즉, 모든지 뭘 하던 그때 그때 기록으로 남기는 것의 중요성을 다시금 절실히 느꼈다.





프로젝트를 하면서 감사했던 순간들


3주 차까지 별다른 큰 변화가 없다가 막판에 이 프로젝트의 본래 목적을 달성시킬 수 있게 됐다. 나는 옵션 A, B를 생각하고 있었는데 전혀 생각도 못한 옵션 D로 문제가 해결됐다. 사실 옵션 D로 바로 갈 수도 있었지만, 옵션 A랑 B를 다 시도해 봤기에 옵션 D라는 방법이 나오지 않았나 싶다.



이전에 내가 생각해 낸 옵션 A랑 B가 코드 변경과 테스팅 후에도 기댓값대로 안 나왔는데, 그 이유를 결국 우리 팀 서비스의 원초적인 아키텍처 이슈에서 찾을 수 있었다. 그래서 슬랙에 다른 principal engineer들에게 옵션 C를 제안하는 내용을 컨펌받기 위해 올렸다. 이후, 다른 엔지니어들이 차라리 옵션 D로 하자는 제안을 통해 이 프로젝트를 무사히 마무리 지을 수 있게 됐다.


디버깅에서 막힌 순간에도, Principal engineer 분 덕분에 며칠은 지체될 수 있는 일의 진행상황을 단축시킬 수 있었다.





프로젝트 소회


무엇보다 일을 제대로 완수한 성취감이 크다. 어떤 분들은 큰 프로젝트가 완수돼도 그건 회사에게 있지, 나에게 있지 않기에 살짝의 공허함이 뒤따라 온다는데 나는 그냥 행복했다.



현재 일하고 있는 회사는 초과근무 수당이 없지만 이 프로젝트를 끝내기 위해 절대적인 시간들이 필요했다. 그래서 지난 3주간 주말에도 운동과 기타 일정을 제외하고는 계속해서 일을 했다. 머릿속에는 프로젝트를 어떻게 하면 완수해야 될지에 대한 생각들로 가득했다.



결국 그로 인해 중간에 피부발진도 생기고 몇 주간 간지러움을 찾아가며 일을 하는 고생을 했지만 시간 안에 무사히 완수해서 스스로에게 한 약속을 지켰다는 것에 뿌듯하다. 또한 Principal Engineer의 도움 덕분에 몇 주간의 시간을 단축할 수 있어서 감사했다. 특히 매니저와의 지속적인 소통 덕분에 프로젝트를 성공적으로 마칠 수 있었다.







물론 그 이후에도 매니저와 결괏값에 대한 정확한 이해를 위해 수많은 대화가 오고 갔지만, 이렇게 정확하게 봐주는 매니저와 일하는 것도 감사하다. 무엇보다 이번 프로젝트를 통해 다시 한번 기록의 중요성을 절실히 느꼈다. 모든 과정을 문서로 남기는 것이 나중에 문제를 해결하는 데 큰 도움이 됐다. 일을 완수한 성취감과 더불어, 앞으로도 꾸준히 배운 내용을 실천하며 성장해 나가기를.




번외: 이후 매니저와 1:1 미팅을 했다. 매니저가 나한테 말한 2가지 피드백은,


1. 최소한으로 확실하게 개선할 수 있는 수치 제시


예를 들어, 이번에 초기 프로젝트 진행상황에서는 25%의 개선을 보일 수 있다고 보고했다. 이후, 옵션 D를 선택하면서 50%의 개선율을 달성했다. 매니저는 이 부분에 대해 잘하고 있다고 칭찬해 줬다.



2. 구체적이고 명확한 완료 시간 제시

프로젝트 3주 차에 나는 원래 예정된 한 달 안에 프로젝트가 마무리될 것이라고 설명했지만, 다른 엔지니어의 종속된 태스크로 인해 일주일간의 추가 배포 기간(deployment period)이 필요할 것 같다고 말했다. 매니저는 이 부분에 대해 '내가 더 개선할 수 있는 점'이라고 말하면서 자신은 그보다 더 빨리 일을 완수할 것이라고 기대했기 때문이라고 덧붙였다.


사실 나는 처음 예상한 시간 안에 프로젝트를 끝냈다고 생각했지만, 매니저의 기대에는 미치지 못한 셈이다.


그래도 이렇게 개선될 부분을 확실하고 정확하게 알려주는 매니저가 있다는 것도 감사하고, 여전히 내가 고칠 부분이 있다는 것도 좋다. 1년 전과 비교했을 때 많이 성장한 것처럼, 앞으로 더 많이 성장할 나를 기대해 본다.


















매거진의 이전글 매니저가 경기 침체로 승진이 연기됐다고 합니다
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari