경쟁력 있는 커리어를 쌓고 있다고 생각되는 이유는 성장하고 변화하는 조직에 있기 때문이라고 생각한다. 그리고 특히나 이런 조직에 있으면서 좋은 경험을 쌓고 있다고 생각하는게, 링크드인에서 아래 글을 보았는데 나는 5번 빼고 모든 경험을 쌓고 있다고 생각하기 때문이다.

경쟁력있는 커리어를 위해 경험해보길 추천하는 업무 포트폴리오

첫번째는 아주 성장이 빠른 기업이나 조직경험. 아주 성장이 빠른 기업이라는 건 증가하는 인원에서 느껴진다. 내가 들어올 때가 딱 증가하는 순간이였던 것 같다. 그러다보니 조직을 리빌딩하기도 하고, 기존 방식으로는 잘 안 굴러가는 문제가 있었던 것 같다. 그러다 보니 만 2년차가 조금 넘은 나에게는 신선한 경험이었다. 조직이 커짐에 따라 기존의 방식이 잘 적용이 안되고, 새로운 규칙 또는 방식을 찾아야 했나보다. "그 때는 맞고, 지금을 틀리다" 같은 느낌. 솔직히 팀이 리빌딩되면서 (기존 맴버가 이탈하기도 하고, 외부에서 인재를 영입하기도 하고, 신입을 많이 뽑기도 하고... 등) 분위기가 어수선한 느낌은 있었지만 그래도 조금 진정되가고 있는 것 같다.
 또, 이번에 들어오신 경험이 많으신 리더 분이 인원이 늘고 성장하는 시기에 팀을 만들어가는지도 옆에서 볼 수 있는 기회인 것 같다.

두번째로는 방법론을 배울 수 있는 조직인 것도 맞는 것 같다. 스타트업이기 때문에 가능한 부분인 것 같은데, 여러 툴들을 적극 활용하려는 분위기 뿐만 아니라 새로운 방법론을 도입해보려는 시도들이 많이 보인다. 기존에서는 노션에서 문서를 정리하면서 프로젝트를 관리하다가 linear라는 툴을 적극 도입해보기도 하고, 서드파티의 데이터 파이프라인, 리포팅 툴을 도입해 여러가지 것들을 자동화하기도 하였다. 무엇보다 동료분들이 대단하다고 느낀 부분은 바뀌는 것에 대한 두려움이 별로 없고, 생각보다 적응하는데 시간이 많이 걸리지도 않았던 부분이다.

세번째 데이터 분석과 AI를 활용하여 업무의 효과, 효율을 높힌 경험은 chatGPT를 써본 경험을 들 수 있을 것 같다. 어떻게 만들지는 아는데 어떤 라이브러리를 써야하나 이런 걸 고민할 때 chatGPT를 쓰면 도움이 된다. 전 직장에서 db에서 데이터를 추출 후 엑셀 파일을 이메일에 첨부하는 코드를 짤 때 chatGPT에게 도움을 받은 적 있다. 이런 식이다. "데이터를 가지고 엑셀 파일을 만드는 python 코드를 짜줘" -> "이메일에 엑셀을 첨부해서 smtp 서버를 통해 보내고 싶은데 코드를 짜줘" 이런 식으로 하면 몇 초만에 짜준다. 근데 중요한 건 돌려보면 안 돌아갈 수도 있다. 저번에 chatGPT가 줬던 코드는 외부 라이브러리에서 method를 하나 잘 못 썼었던 같은데 그런건 에러 보고 바꿔주면 된다. (chatGPT에게 틀렸다고 말해주면 고치는 방법을 알려줄 수도 있다.)

번외로, chatGPT를 쓰면 공부하는데 도움도 많이 된다. 아래 글에서 썼다시피 큰 덩어리를 배울 때 어떤 것부터 배워야하는지 어려울 때가 있는데 선생님에게 질문하듯이 chatGPT에게 질문을 하면 큰 도움을 받을 수 있다.  

2023.01.23 - [Programming] - AWS EC2 instance, AMI, EBS 이해하기

마지막으로 네번째, 자신의 업무가 고객에게 직접 가치를 부여하는 것을 확인할 수 있는 업무 경험도 감사하게도 있었다. 우리팀 PM님이 고객사를 만나고 오면 product에 대한 피드백이나 이런저런 기능이 있으면 좋겠다는 이야기를 공유해주신다. 그럼 이런 부분이 더 보완되어야하구나, 이런저런 기능은 다음에 만들어야겠구나 하는 생각을 한다. 그리고 이런 이야기를 듣다보면 어떤 기능을 개발할 때 작게 쪼개서 보완해나가는 방법을 배워볼 수도 있다. 채팅 기능을 예로 들자면 처음에는 두 사람이 대화하는 것만을 개발하고, 후에 그룹채팅 방을 만든다던지. 처음에는 텍스트만 보낼 수 있는데 이모티콘까지 지원하는 채팅방을 만든다던지... 이런 경험은 좋은 PM님을 만나서 있을 수 있었던 경험 같다.

단 한 가지, E-to-E로 문제를 정의하고 설계하고 해결해본 경험은 없는 것 같다. 사실 db 모델을 설계하고, 개발 완료하고, 모니터링까지 하는 게 E2E 라면 E2E 겠지만은 그걸 안 해본 백엔드 개발자는 거의 없을 것 같아서 제외하고, 비즈니스적인 관점에서 기획~실행까지는 아직 못해본 것 같다. 특히나 개발팀에 있으면 기획 같은건 거의 PM님이 해주셔서 그런 것 같기도 한데 좋은 PM님과 일하면서 나중에는 기획도 어느정도 할 수 있는 개발자가 될 수 있으면 좋겠다.

최근에 사수님께서 "이제 00도 테스트코드를 짜면서 코드를 짜보세요." 라고 하셨다.

그래서 당연히 넵 :) 이라고 답했다.

근데 "테스트코드를 먼저 짜면서 코드를 작성해보세요" 라고 하셨다.

나 : ???

입사 전에도 테스트코드를 짜보긴 했고, TDD(Test-Driven-Developement)라는 걸 들어보긴 했었다. 근데 이제 사수님이 TDD는 테스트코드를 먼저 짜보면서 코드를 작성하는 거라고 하시면서 한 번 해보라니까 감이 안 잡혔다. 그래서 한 번 TDD를 왜하는 거고, 어떻게 하는지 찾아보기로 했다.

그래서 TDD 왜 해야하는 거야?

전에 혼자 DRF를 이용해서 asset-dashboard라는 프로젝트를 혼자 진행했던 후기 글에서도 언급했듯이 점점 기획의 중요성을 느꼈다. 그래서 어떤 기획이 좋은 기획인가?를 찾아보면서 여러 글을 보았는데 그 중 이런 글귀가 있었다. "가설 베이스 사고를 하는 것이 논리적 사고를 하는데 있어서 중요하다. 늘 결론을 갖고 그에 대한 가설을 검증하는 방식으로 사고해야 한다" 이 글귀가 정확히 TDD가 가고자 하는 방향을 설명하는 것 같았다.

테스트코드를 먼저 짜므로서 가설을 설정하고, 내가 짠 코드로 그 가설을 검증하는 것이다.

그리고 이런 방향으로 개발하기 위해서는 "검증하고자 하는 가설은 무엇인가?" 이게 핵심 질문이였다. 즉, "테스트하고자 하는 것이 무엇인가"이다. 생각해보면 이전에 간단하게 테스트코드를 짤 때는 request를 날리고 requests.code.ok가 떴는지 이런걸 체크하기 위해 테스트코드를 짰었는데 이런게 무의식 중에 생각하게 되는 아주 작은 가설 ('내가 이렇게 request를 날리면 200이 올 것이다!") 중 하나였던 것 같다. "

이렇게 하면 테스트코드를 먼저 짜야하니까 미래에 일어날 버그들을 생각하게 되고, 코드부터 짜고 테스트를 하는 것보다 나중에 생길 버그나 개선해야 할 것들을 더 생각하게 되는 것 같았다. 그리고 결과적으로 모두가 원했던 버그는 줄고 코드는 간결해지는 clean code라는 목표에 다다르게 되는 것 같았다.

마지막으로 이런 이유로 TDD를 하는 것이고, TDD를 하면 미래에 유지보수하는 시간이 매우 줄 것이라고 생각한다. 그래서 기능이 많은 큰 프로젝트에서는 TDD가 중요할 것 같다. 근데 해보니까 TDD를 하면 개발하는 시간이 엄청나게 늘어 날 것 같다. 기획자와 의사소통이 많이 필요하니까... 그래서 프로토타입을 만들어서 기능을 실험해보거나 휘발성이 높은 코드를 짤 때는 엄청 필요할 것 같진 않아보였다.

그래서 TDD를 어떻게 해야하나...

위의 사진처럼 설계/기획하고, 테스트코드를 먼저 작성한 다음에 코드 개발을 하는 것이다. 그리고 더 나아가서 TDD 방식이란 테스트코드를 짜면서 발생하는 예외사항들을 계속 테스트케이스에 추가하면서 설계를 개선하고 마지막에 테스트를 통과한 코드만 실제 코드로 작성하는 방식이라고 한다. 이론적으론 그렇다... :)

사실 이런 부분은 ' 아 그렇구나... 일단 이렇게 해야하는 거 같다...' 이렇게 감을 잡고 하다보면 아 '왜 이런 방식으로 하라고 가르쳐주셨구나...' 라는 걸 더 느끼게 되는 것 같다. 그래서 회사 내부에서 누군가 unittest로 짜놓은 test코드를 보면서 공부하고, 이전에 써보았던 pytest도 생각하면서 일단 어떻게든 해보고 있다. 꼭 알아두면 좋은 setup, setupclass나 teardown, teardownclass와 더불어서 @patch 이런 것도 다음에 글 쓰면서 정리해봐야겠다.

00pen.tistory.com/92

참고문헌

구글에서 개발한 5일 완성 기획 프로세스:  brunch.co.kr/@thinkaboutlove/87

TDD(Test-Driven-Development) 방법론에 대해서: https://wooaoe.tistory.com/33