⏰ 읽는 시간: 15분

들어가기 전

2022년 8월 8일, 백엔드 개발자로서의 첫 커리어가 시작되었다.

처음 3년이 중요하다라는 주변의 조언을 들으며 긴장 반, 설렘 반을 안고 입사하였는데 정신차려보니 벌써 1년차 개발자가 되어가고 있었다.

중요하다는 3년의 1/3을 보내며 '나는 입사 초와 많이 달라졌는가?'를 고민했을 때 정말 많이 달라졌다고 느낀다.

Before

• Task를 정리할 때 나만 이해할 수 있는 글로 작성했다
• 나에게 주어진 업무를 제대로 이해하지 못해 하루 가까이 고민을 했다
• 개발 계획을 사전에 공유하지 않고 진행했다가, 결국 처음부터 다시 시작했다
• 다른 사람의 코드를 이해하기 어려워 코드리뷰에 적극적으로 참여할 수 없었다
• 혼자 처리해야하는 업무라고 생각해서 다른 파트에 필요한 협업 요청을 하는 것을 어려워했다

Now

• Task를 정리할 때 적절한 카테고리 분류를 통해 누구나 쉽게 읽을 수 있는 글로 작성한다
• 주어진 업무에 대해 파악하는 시간이 빨라졌다 (시간이 너무 오래 걸린다 싶으면 바로 질문한다)
• 개발 계획을 Flow로 미리 정리해보고, 1회 이상 피드백을 받은 다음 개발을 시작한다
• 다른 사람의 코드를 충분히 이해하고, 코드리뷰에 적극적으로 참여하며 다양하게 고민해본다
• 파트별로 담당하는 업무의 카테고리에 대해 이해하고, 필요에 따라 적절하게 협업 요청을 한다

현재와 같이 변화하기까지 혼자 나름대로의 많은 시간과 노력이 필요했다. 퇴근하고도 이슈를 해결하기 위해 어떻게 개발해야할지 고민하거나 회사에서 작성해둔 업무 Task를 다시 읽어보며 효과적으로 글을 작성하는 방법에 대해서도 고민했다.

스스로 고군분투하며 많은 산을 넘은 것도 있지만, 1년차가 되는 시점에서 다시 돌아보니 내가 성장할 수 있게 뒤에서 잘 받쳐준 우리 팀 덕분도 크다고 생각이 들었다.

그래서 1년 간의 회사 생활을 돌아보며 이번 포스팅을 작성하게 되었다. 주니어가 잘 성장할 수 있는 근무 환경의 조건에는 무엇이 있을까?

물론 개인마다 생각하는 기준은 다르겠지만, 내 의견을 한 스푼 담아 작성해보려고 한다.

고민을 모두에게 알리자 🔊

입사 초, 일하면서 '지금 이 질문을 해도 되는걸까?' 라는 고민이 나를 가장 힘들게 했다. 만약 누군가에게 물어봤다면 빠르게 해결할 수 있었을 문제인데,

_"제대로 알아보지도 않고, 혹은 제대로 고민해보지도 않고 일단 물어보는 것처럼 보일 수 있지 않을까?" _ 하는 생각 때문에 선뜻 질문하지 못했다.

알고보니 나 뿐만 아니라 파트 전반적으로 혼자서 최대한 해결해봐야하지 않을까 하며 오랜 시간 고민하는 분위기였다. 보다못한 팀장님께서(🤣) 파트 채팅방에 "고민 3시간 이상 금지!" 라는 공지를 올리셨다.

물론 혼자서 생각하는 시간도 필요하지만 그게 너무 길어지면 다같이 고민해보는 것이 더 좋은 방향으로 나아갈 수 있다는 입장이셨다

팀장님께서 먼저 이렇게 고민은 적극적으로 공유하자고 언급해주시니 모두가 SOS를 좀더 적극적으로 요청하는 분위기로 변화하게 되었다👍

사수의 중요성 🧚‍♂️

우리 파트는 보통 1 Task에 대하여 1명의 개발 담당자가 지정된다

우리 파트 모두가 같은 서비스를 담당하고 있지만, 각자 진행하는 테스크는 다르기 때문에 아무래도 본인의 개발 건에 대해 다른 사람에게 물어보는 것이 쉽지는 않다. 테스크에 대해 처음부터 설명을 하고 질문을 해야하다보니 상대방의 시간을 많이 뺏는다고 생각이 들면 한없이 미안해지기 때문에..

특히 주니어에게는 딜레마가 자주 발생한다 🥺

혼자서는 도저히 답이 안 나올 것 같은데
그렇다고 질문하기는 어렵고
그렇다고 혼자서 해결하려니 막연하게 시간만 흐르고...

이와 같은 무한 굴레에 빠져버리게 된다. 내가 이러한 딜레마에서 빠르게 벗어날 수 있었던 가장 큰 이유는 '사수'의 존재였다.

우리 파트는 사수-부사수로 매칭되어있다. 매칭의 기준은 파트장님의 판단이며 현재는 사수(대리, 과장)-부사수(사원)으로 구성되어 있다. (아마 사수-부사수 문화가 생긴 것이 혼자서 끙끙거리는 시간이 길어지는 것을 방지하기 위한 하나의 해결책이 아니었을까?)

파트 전반적으로 '잘 도와주는 것'에 대해 긍정적으로 바라보고 있기에 사수님들은 질문을 받을 때마다 적극적으로 도움의 손길을 내밀어주신다. 그리고 부사수의 입장에서는 언제든지 편하게 고민을 물어볼 수 있는 사람이 있다는 점에서 심적 부담감이 많이 줄어든다.

현재 사수님은 스스로 한번 고민해볼만한 내용에 대해서는 과제 느낌으로 던져주시기도 한다📝 좋은 방향으로 성장할 수 있도록 잘 이끌어주셔서 항상 감사하다 그래도 너-무 시간을 뺏는 상황은 생기지 않도록 항상 주의하고 있다🧐

아는 만큼 도와주기 👌

입사 초 나는 정말 많은 사람들에게 도움을 받았고, 덕분에 회사에 잘 적응할 수 있었다 그래서인지 나도 누군가에게 잘 베풀고 좋은 방향으로 이끌어줄 수 있는 사람이 되어야겠다는 생각을 항상 가지고 있다

최근에는 우리 파트에 신규 입사자로 4명 정도 들어왔는데 신규 입사자 가이드 작성을 내가 맡기도 했고, 편하게 질문하실 수 있도록 말씀을 드렸는데 그 효과가 있었던 것 같다

(캡쳐 모음을 보니 왜 넴넴봇처럼 보이지.. 그렇지만 그때그때 진심으로 답변을 한건 사실이에여..)

서로 적극적으로 도와주는 분위기를 만들기 위해 나부터 실천해야 한다는 생각도 있어서 아는 만큼 열심히 도와드렸고, 신규로 오신 분들도 자연스럽게 이런 분위기에 적응하신 것 같아 나중에 팀 내 협업 시 더 좋은 시너지가 나지 않을까 생각한다🥳

사실 도와주는게 상대방에게만 실력+1이 되는 것은 아니다 나도 한번더 찾아보고 고민해보며 공부하는 시간을 갖게 되는 경우도 있어서 질문자도, 답변자도 모두 배워가는 순간들이 쌓여나가는 것 같다 ✏️

주기적인 기술 공유 시간 👏

우리 회사 개발실의 전체 인원은 약 100명 정도이며 여러 파트로 구성되어 있다. (프론트, 백엔드, 모바일, 데봅스, 데이터운영, 보안 등) 파트에 상관없이 기술 공유로 다룰만한 좋은 주제들은 수요일 오후 2시마다 온라인 상으로 발표를 한다.

Kafka, Vault, MySQL 버전업 등 다양한 주제가 있었는데 실제로 내가 작업한 적은 없지만 이런 것들도 있구나~하고 미리 배경지식으로 쌓아두기 좋은 것 같다 더불어 개발실에서 요즘 어떤 포인트를 트렌드로 잡고 작업을 하는 지도 알기 쉽다 나는 Kafka에 대한 강의를 조만간 들어볼까 생각 중이다 !

이런 기술 공유 시간은 발표를 하는 사람도, 발표를 듣는 사람에게도 모두 도움이 되는 좋은 시간이 아닐까 싶다

좋은 건 다같이 알고 넘어가자 😲

카카오, 네이버, NHN, 인프런 등 개발자 컨퍼런스 참가신청을 받는 기간에는 팀장님께서 항상 개발자 단체 메신저 방에 관련 링크를 공유해주신다

다양한 컨퍼런스에 참여하여 시야를 넓히는 것이 중요하다고 생각하시는 것 같아 개발실 사람들은 가고 싶은 컨퍼런스가 있으면 부담없이 다녀오는 편이다

실제로 나와 우리 파트 중 일부는 작년에 NHN컨퍼런스, 올해에 네이버 데뷰에 다녀왔다. 가서 리프레시도 하고, 다녀와서 좋았던 점은 서로 공유도 하곤 했다

행사 뿐만 아니라, 한번씩 보면 좋을 개발 관련 영상들도 단체방에 올라온다 (영상 보고 후기 남겨야하는 그런 분위기 아니고 그냥 툭툭-올라오곤 합니다 ㅎㅎ)

가끔 업무가 붕 떠서 여유롭거나 출퇴근길에 하나씩 봐도 시간이 잘 가서 나는 이렇게 공유해주시는 영상이나 기술블로그 포스팅들이 넘넘 좋다🤗

말로 어렵게 설명하는 것보다, 잘 정리된 영상으로 공유하고 싶은 내용을 알리는 것도 좋은 방법인 것 같다

피드백은 구체적으로 🧐

입사 초, Task 작성에 대해서 정말 많은 피드백을 받았다.

나는 나름대로 내가 고민했던 내용들을 자세히 녹여내는 것이 좋겠다고 생각했는데 추후에 그 테스크를 봐야하는 사람들에게는 너무 구구절절하게 작성된 글이었을 뿐이었다. 아니면 오히려 너무 내용을 덜어내서 필요한 내용이 제대로 적혀있지 않은 경우도 있었다.

'너무 읽기 힘들어요'
'좀 더 쉽게 써주세요'
'업무 글은 이렇게 쓰면 안돼요. 다시 써주세요.'

글 작성은 개인의 주관이 많이 반영되는 작업인 만큼 글에 대한 평가도 위와 같이 추상적으로 될 수 있는데

파트장님께서는 항상 피드백을 구체적으로 주셨고 덕분에 내 글쓰기의 문제점을 좀더 빠르게 파악할 수 있었다. 만약 주변에서 조언을 주지 않았다면, 나는 아직까지도 불친절한 글쓰기를 반복하고 있었을 것 같다.

요즘은 Task 작성 시 항상 카테고리를 활용한다.

위 카테고리에 맞춰 작성하니 나도 좀더 글을 깔끔하게 쓸 수 있게 되었고 테스크를 공유할 때도, 읽는 사람이 부담없이 보는 것 같았다.

요즘은 피드백을 요청할 때마다 긍정적인 답변을 자주 받고 있어서 이전에 비해 많이 성장했구나를 느끼고 있다🥰

적극적인 코드 리뷰 📝

코드 리뷰는 특히 주니어 개발자에게 정말 도움이 많이 된다. 리뷰를 받는 것도, 리뷰에 참여하는 것도!

1년 간 코드 리뷰를 통해 얻을 수 있는 장점은 크게 5가지였다

• commit에 작업 내역을 적절하게 반영시키기
• branch 관리하는 방법 배우기
• 내 코드에 불편한 점은 없을까?에 대해 계속 되짚어보기
• 더 나은 네이밍, 더 나은 구조에 대해 생각하고 찾아보기 (더 나아가 디자인패턴까지 찾아볼 수 있다)
• 코드에 대한 의견을 교환하는 커뮤니케이션 능력 키우기

우리 파트는 매일 오전에는 전날에 올라온 PR을 보며 코드리뷰를 적극적으로 하기로 약속했다 갑자기 이슈가 터지거나 장애가 발생하는 등 다들 바쁠 때는 코드 리뷰를 하지 못하는 경우도 있지만 ㅠㅠ 그래도 사수-부사수의 PR은 서로 꼭 확인해주고자 하는 분위기라 최소 1명 이상의 approve는 받고 있어서 괜찮다 ㅎㅎ 그리고 나는 PR 올라오면 꼭 확인하는 편이라, 다른 사람의 코드를 이해하는 실력이 많이 좋아졌다👍

리뷰를 남겨주고 나서, 이렇게 메신저를 받을 때면 너무 뿌듯하구 ㅜ 코드 리뷰만큼은 단점 없는 좋은 문화인 것 같다 😎

달달한 커피타임 ☕️

파트장님, 팀장님께서 2-3달에 1번씩 커피타임을 하자고 메신저를 보내주신다 첫 커피타임을 가질 때는 긴장했는데, 이제는 마음 편하게 수다를 떨고 오는 시간이라고 생각해서 좋아졌다

진짜 스몰토크를 하는 경우도 있고, 중간중간 힘든 점이나 구성원으로써 개선점에 대해 내고 싶은 의견이 있는지 물어봐주시는데 항상 파트의 이야기에 귀기울여주고 신경써준다는 느낌이 들어서 좋았다👂

신기했던 점은, 분명 리더로서 힘든 점들도 있으실텐데 항상 조직원들 앞에서 그런 내색 없이 오히려 잘 업무를 해낼 수 있도록 서포트를 하는 모습을 보여주셔서 리더로서 어떻게 행동해야 파트원들에게 긍정적인 영향을 줄 수 있는지 속으로 많이 배웠다

고민 많은 주니어 개발자들에게 달달한 커피타임은 생각 정리에 큰 도움이 되는 좋은 시간인 것 같다

마무리하며

1년 동안 느낀 점들을 쭉 작성해보았는데, 나는 정말 운이 좋게도 좋은 조직에서 잘 배우고 성장하고 있는 사람인 것 같다

앞으로도 기운 내서 더 잘해봐야지! ❤️

⏰ 읽는 시간: 10분

들어가기 전

회사에 들어오기 전, 나는 Git을 거의 몰랐다 git commit, git push 등 간단한 작업만 알고 있었고 이마저도 IDE에서 지원하는 GUI를 활용해왔다. 내가 들어온 파트에서는 적극적으로 Git Flow 전략을 사용하고 있었고 회사 서비스 소스코드에 적응하는 것과 동시에 Git에 대해 파악하느라 꽤 고생했던 기억이 있다.

지금은 기본적으로 필요한 Git 작업들은 충분히 숙지되어있고 커밋 충돌이나 rebase 작업 등이 필요한 상황에서 어려워하는 파트원들에게 먼저 다가가 도움을 주곤 한다

😎😎😎 1년 간 열심히 공부하고 배운 만큼, 이번 기회에 필수적인 내용에 대해 정리해보고자 한다

(+ 본 포스팅은 하이라이팅이 많이 첨부되어 있습니다. 다크모드 대신 라이트모드로 읽는 것을 권장드립니다.)

파트에서 사용하는 Git Flow

출처: https://blog.jetbrains.com/space/2023/04/18/space-git-flow/

Branch별 역할 (사내 기준)

• main 실제 운영에 반영되어 있는 소스 코드들이 있는 브랜치
• release 베타 배포 및 베타 QA를 위한 브랜치 main 배포 예정인 feature 브랜치들을 release에 취합한 후, Real 배포 전에 release->main으로 merge 한다
• develop 알파 배포 및 알파 QA를 위한 브랜치 feature 브랜치 개발이 완료되어 알파QA를 원할 경우, 배포 일정과 관계 없이 바로 develop 브랜치에 적용하여 알파 환경에서 테스트를 진행한다
• feature 기능 개발을 진행하는 브랜치 우리 파트에서는 main 브랜치를 기준으로 feature 브랜치를 생성했다 (feature 브랜치의 시작 브랜치는 상황에 따라 전략을 다르게 가져갈 수 있을 것 같다)
• hotfix main 배포 후 급하게 수정해야할 경우 생성되는 브랜치

Git Flow를 따라 작업해보자

Github에 이슈업하기

먼저 개발하고자 하는 테스크에 대한 이슈를 github에서 등록한다

이슈 생성 후 확인 가능한 이슈번호가 feature 브랜치 번호의 기준이 된다. (ex. feature/#26)

local의 main 브랜치 최신화하기

$ git switch main
$ (main) git fetch
$ (main) git pull origin main

git log로 local main의 최신 커밋이 origin main의 최신 커밋과 동일한지 체크해주자

부모 feature 브랜치 생성하기

이슈 번호는 10으로 가정하고 진행하겠다

$ (main) git switch -c feature/10
$ (feature/10) git push origin feature/10

자식 feature 브랜치 생성하기

$ (feature/10) git switch -c feature/10-1
$ (feature/10-1)

우리 파트의 경우 자식 feature -> 부모 feature로 merge하는 pr을 올리는 시점에 코드리뷰를 진행했다 즉, 부모 feature 브랜치는 해당 기능 개발건이 완벽하게 되어있다는 보장이 되도록 방향을 잡았다

개발 진행

이제 자식 feature 브랜치에서 자유롭게 개발을 진행한다 파트에서 commit 명에 대한 세세한 규칙은 아직 정하지 않았지만 최근 유지보수를 하다보니 커밋만으로 이슈와 PR을 찾기가 어려워 히스토리 추적이 오래 걸렸던 적이 있었다. 그래서 방법을 고민하다가 커밋명 앞에 이슈번호를 붙여주는 방법을 선택했다. (혼자서만 도입한 방법이라 슬금슬금 파트에 커밋 네이밍 룰을 전파해볼 생각이다)

AS-IS

TO-BE

TO-TO-BE (07.28.업데이트)

최근에 새로 알게 된 사실.. rebase 작업 후 터미널에서 커밋 메시지 정리하고 마치려는데

커밋 맨 앞에 붙은 #으로 인해 해당 라인이 전체 주석 처리가 되어버린 이슈가 있었다

그래서 현재는 [#이슈번호] 커밋메시지 패턴으로 작업하고 있다.

개발을 진행하다 main 브랜치가 최신화되는 경우가 있을 수 있다 추후 conflict을 방지하기 위해 상시로 feature 브랜치를 최신화해주어야 한다

$ (feature/10-1) git switch feature/10
$ (feature/10) git pull (origin) main --rebase
$ (feature/10) git push origin +feature/10

부모 feature 브랜치를 무시하고 자식 feature 브랜치에서만 main을 pull rebase 받아오면 안된다 왜냐하면 main -> feature/10 -> feature/10-1 순서로 브랜치를 따왔기 때문에 이 순서를 지켜주어야 한다 !

이때 rebase 옵션을 주는 이유는 feature 브랜치에서 추가된 커밋이 항상 HEAD에 올 수 있도록 하기 위해서다. 작업 시간대별로 commit 순서가 정렬되면 추후 커밋 리스트 보기가 힘들어진다.

최신화가 완료된 부모 feature 브랜치를 origin에 push할 때는 경우에 따라 force push가 필요할 수 있다(+) 사실 나는 귀찮아서 항상 붙여주긴 한다..

$ (feature/10) git switch feature/10-1
$ (feature/10-1) git pull (origin) feature/10

이제 자식 feature 브랜치까지 최신화 완료! 이어서 개발을 진행하자

Origin에 리뷰 받을 PR 생성하기

$ (feature/10-1) git push origin feature/10-1

이제 개발이 완료되었다면 origin에 올려주자

우리 파트의 경우, 개발 PR과 연관된 테스크를 dooray에서 따로 작성하고 있어서 두레이 링크를 함께 첨부해두고, PR 작업 내역에 대해 간단히 소개한다

그리고 이어지는 활발한 코드리뷰! 🥳 PR에서 코멘트로 티키타카를 주고 받기 부족하면 메신저로도 열띤 토론을 펼치곤 한다

우리 파트는 누군가의 코드에 대해 다같이 열심히 고민해주는 분위기라 다같이 성장하기 좋은 것 같다 👍

리뷰어의 피드백을 반영하여 소스코드가 수정될 경우, 수정했는데 의도하신 피드백 방향에 맞을까요? 한번 확인해주세요!라는 의미를 담아 한번더 리뷰어를 멘션걸어 커밋 번호와 함께 답글을 남긴다.

만약 리뷰어가 수정한 커밋에 대해 만족한다면, 👍을 남겨주고 해당 대화는 resolve 처리를 한다.

feature 브랜치에서는 force push도 괜찮다

$ (feature/10-1) git rebase -i abcdef^
-> 터미널에 보여지는 commit 목록 중 수정하고자 하는 커밋의 pick을 edit로 변경
-> 소스코드 수정 후, 수정한 파일을 git add 하고
-> git rebase --continue로 작업 마무리

만일 이미 origin에 올라간 커밋이라고 해도 feature 브랜치, 즉 개인 브랜치의 영역에서는 force push를 허용하기로 했기 때문에 rebase를 자유롭게 활용하고 있다.

물론 코드리뷰에 대한 피드백을 rebase로 처리하게 되면 리뷰어가 수정 내역만 보기 어렵다는 단점이 존재하긴 하지만.. 이건 파트에서 룰을 세부적으로 정해나가야할 것 같다

Merge Pull Request

코드 리뷰에 참여한 사람들의 approve가 확인되면 이제 부모 feature 브랜치로의 Merge를 진행한다 우리 파트는 merge branch가 생기는걸 방지하기 위해 Rebase and merge 옵션을 선택하고 있다

merge 옵션별 설명은 https://im-developer.tistory.com/182 포스팅에서 너무 설명이 잘 되어 있다

feature -> develop

feature 개발이 완료되었다면 alpha QA를 위해 develop에 feature 브랜치를 merge 한다. 알파 QA 과정에서 결함 건이 발견되었다면 다시 자식 feature 브랜치를 생성하여 작업을 반복한다.

feature -> release

알파 QA가 끝나고 배포 일정이 정해졌다면, 배포 전 베타 QA 기간에 맞춰 release에 feature 브랜치를 merge 한다. 베타 QA 과정에서 결함 건이 발견되었다면 다시 자식 feature 브랜치를 생성하여 작업을 반복한다.

우리 파트에서는 정해진 배포 일에 여러 feature 개발건이 배포가 나갈 경우, release에 배포나갈 feature 브랜치들을 취합한다고 표현하고 있다.

release -> main

release->main으로 merge 하기 전, release 브랜치는 베타 QA 후 결함건 수정까지 완료되어있는 상태다. 실제 배포일에 release 브랜치를 main으로 merge하고 main 브랜치를 기준으로 운영 환경에 배포를 진행한다.

hotfix

$ (main) git switch -c hotfix/10

만일 main 배포 후, 급한 수정건이 발생할 경우 main 브랜치를 기준으로 hotfix 브랜치를 생성하여 빠르게 수정 작업을 진행한다. hotfix를 만드는 사람이 내가 아니길 항상 빌고 있다.

hotfix 브랜치 작업이 완료되면 다시 hotfix->main으로 merge 하여 main 브랜치를 기준으로 배포한다

main 배포 후에는 꼭 브랜치 최신화를!

main 배포 후에는 develop과 release 브랜치가 main에 있는 커밋을 모두 가질 수 있도록 최신화를 진행해야한다. 종종 배포 담당자가 이를 놓치게 되는 경우가 있는데, 최신화가 적절한 시점에 되어 있지 않으면 추후 conflict이 발생할 가능성이 높고 공용 브랜치다보니 빠르게 원인을 찾아 바로 해결하기 어려운 경우가 발생한다.

develop 브랜치가 복구가 어려울 정도로 꼬여있으면 브랜치 삭제 후, main 기준으로 다시 develop 브랜치를 생성해야 한다. 이럴 경우 develop 브랜치에만 알파QA 할 feature 브랜치를 merge 해둔 개발 담당자들은 이 작업을 1번더 해야 하기 때문에 번거로운 상황이 온다 🥺 꼭 브랜치 최신화는 바로바로 챙겨주자!

정리하며

여기까지 파트에서 사용하고 있는 Git Flow 전략을 좀더 상세하게 정리해보았다 git 백지 상태에서 1년 동안 열심히 공부해서 여기까지 성장할 수 있어서 다행이라는 생각이 든다 이제 정말 Git이 왜 편한지 알게 되었다! 그리고.. rebase가 무섭지 않게 될 때, 정말 열심히 공부했구나를 느꼈다😎

머릿속에만 그려두고 있다가 처음으로 글로 정리해보았는데 우리 파트의 git flow 전략에 많이 적응되어 있어서 refresh를 위해 다른 git 전략도 찾아보며 다양하게 알아두어야겠다는 생각이 문득 들었다 :)

오늘의 포스팅은 여기까지!

E2E 테스트 프로젝트를 처음 맡고 나서 생각했던 플로우는 단지 이것 뿐이었다.

단순히 생각할 프로세스가 아니였다

결과적으로 현재 구성된 프로세스는 위와 같다. 혼자서 저 결과를 이끌어내기까지 정말 많은 고민과 갈아엎음이 필요했다..🫠 위 프로세스는 알파 배포를 기준으로 작성한 플로우다.

글로 아무리 친절하게 설명하는 것보다, 깔끔한 플로우 그림 하나가 더 완벽한 설명이 될 것 같아 구구절절한 설명은 생략하려고 한다.

DEPLOY

E2E 테스트 실행 전에 가장 먼저 필요했던 것은 알파 서버 젠킨스 배포 환경 구축이었다. 베타, 리얼의 경우에는 젠킨스 배포가 가능하도록 되어있었지만 알파는 특이하게 직접 터미널에서 알파 서버에 접속하여 git pull origin develop하는 과정이 필요했다. 변경되지 않은 이유는 크게 2개 같았다.

• 기존에는 젠킨스 파이프라인 소스코드 관리를 데봅스에서 맡았다.
  • 파이프라인 개선을 위해서는 수정이 필요한 이유와 방향을 설명하는 커뮤니케이션이 필요했다.
  • 아무래도 우선순위가 높지 않아서 현상 유지가 되었던 것 같다.
• 젠킨스 관리 권한이 데봅스에서 솔루션으로 넘어온지 얼마 되지 않았다.
  • 대부분의 솔루션 개발자들은 groovy에 익숙하지 않았다. (쓸 일도 없었다.)
  • 기존 소스코드에 대한 러닝 타임이 필요했다.
  • 결국 우선순위 높은 테스크를 먼저 처리하느라 신경 쓸 시간이 없었다.

그래서 E2E 테스트 실행 프로세스 추가와 함께, 전반적인 Jenkins 파이프라인 개선까지 함께 맡아 처리하였다.

기존에는 git에서 tag를 add&push하고 해당 태그명을 젠킨스 빌드 시 파라미터값으로 직접 입력해줘야 하는 과정이 있었다면, 이번에는 원클릭으로 앞선 프로세스가 자동으로 되도록 구현하였다.

1. origin develop 최신 커밋에 (날짜)_(시간)_devleop 으로 태그 생성 및 origin push
2. server /www/ 하위 경로로 소스코드 배포

다들 은근한 불편함은 느끼고 계셨던 것 같다..ㅎㅎ 개선 후 긍정 리액션을 받을 때마다 기분이 너무 좋았달까 !

다시 본론으로 돌아와서, DEPLOY를 개선하니 Jenkins 빌드 시 생성된 태그로 바로 Test를 돌릴 수 있고 롤백 관리를 할 수 있어서 더욱 깔끔해졌다. 이제 Deploy가 완료되면 배포된 서버를 대상으로 본격적인 Test가 실행까지 진행된다.

TEST

Test 실행을 서비스 배포 파이프라인에서 직접 하지는 않는다. 명확한 역할 구분을 위해 E2E 파이프라인을 따로 만들었고, TEST 단계에서는 E2E 파이프라인을 cURL로 실행하도록 하였다.

자세한 플로우는 위 그림으로 그렸고, 큼지막하게만 정리하면 위의 표와 같다.

Playwright 자체에서 특정 조건일 경우 전체 테스트를 다시 수행하도록 로직을 작성하는 것이 쉽지 않아 고민이 많았는데, 젠킨스 재빌드를 하면 깔끔하게 해결되는 문제였다.

이제 실제로 사용할 차례

프로세스 구축은 끝났지만, 아직은 환경 개발에 집중하느라 테스트 케이스를 많이 추가해두지 못했다. 그렇지만 반대로 말하면 테스트 케이스만 추가하면 돼인 상황이기도 하다. 사실 환경을 구현해두니 다른 우선순위 테스크가 많아지면서 단순 작업인 테스트 케이스 개발이 점차 밀려나고 있다.. 그래서 근무 시간이 아니더라도 퇴근 후나 여유가 있을 때마다 조금씩이라도 해둬야겠다는 생각을 했다.

아마 실제로 사용하게 되는 순간이 오면 다시 여러 시행착오가 발생하지 않을까 싶다. 그때는 다시 포스팅으로 어떤 난관이 있었고 어떻게 극복해나갔는지 작성해봐야했다. 기업에서 실제로 E2E 프로세스 도입을 성공시킨 사례가 많지 않아 걱정이 컸는데, 그럼에도 구축을 완료해두어서 참 다행이라는 생각이다.

내가 주도적으로 맡아 진행한 프로젝트인 만큼, 묻히지 않고 사내 개발 문화 중 하나로 자리 잡을 수 있도록 꾸준히 관심을 갖고 개선해나가야겠다. 그럼 이번 포스팅은 여기까지!

E2E 테스트를 위해 고려되었던 것들은 위의 표 내용 정도로 간단하게 정리가 된다.

VSCode

나는 IntelliJ를 좋아하지만, VSCode의 Extension에서 Playwright 확장 프로그램이 설치가 가능한 것을 보고 바로 VSCode로 넘어왔다. 테스트 실행은 GUI로 하는 것이 굉-장히 편리하기 때문에..!!

나중에 찾아보니 Jetbrains에서 테스트를 위한 IDE인 Aqua 베타 버전을 무료로 제공해주고 있다는 것을 알고 한번 써볼까 했는데.. 아쉽게도 현재는 셀레니움까지만 지원을 해주며 Playwright는 준비 중이라고 해서 VSCode로 시작을 했다.

TypeScript

이번 프로젝트 덕분에 TypeScript를 처음 접해보았다. TypeScript 언어 자체의 장점도 많아서 한번쯤 도전해보고 싶어서 다른 언어와 크게 비교하면서 깊게 고민하지는 않았던 것 같다.

그리고.. 솔직하게 말하면, 아직 Playwright에 대한 커뮤니티가 크게 활성화되어 있지 않다. 그나마 활성화된 커뮤니티에서 TypeScript로 Playwright를 사용하여 개발한 사례가 비중이 높았기 때문에 좀더 편리한 개발을 위해 선택하였다. 주니어인 나에게는 같은 언어로 고민하는 사람들의 이야기를 보는 것이 훨씬 이해도 빠르고 효율도 좋을 것이라고 생각했다.

Jenkins

이번 E2E 프로젝트의 최종 목표는 QA 서버 배포 직후 자동으로 E2E 테스트까지 실행되는 것. 그래서 빌드 프로세스에 E2E 실행까지 포함되어야 했기 때문에 Jenkins 파이프라인 설계까지 작업이 필요했다.

테스트 로그 관리

젠킨스에서 테스트 실행을 목적으로 하는 빌드가 진행될 때, 미리 빌드된 도커 이미지를 실행함으로써 테스트가 돌아가게 된다. 테스트가 끝난 직후, 테스트 로그를 확인하기 위해 직접 도커 컨테이너에 접근하여 로그 파일을 찾아 들어가는 과정은 매우 불편하고 비효율적이라 테스트가 종료되면 로그를 한 곳으로 자동으로 업로드하여 관리를 해줄 필요가 있었다. 결론적으로 NHN Cloud에서 제공하는 Object Storage에 로그를 올려서 확인 가능하도록 하였다.

테스트 결과 알람

테스트 시작, 테스트 종료, 테스트 성공 및 실패 여부에 대해 알람을 실시간으로 받을 필요가 있었다. 알람을 받을 창구로 사내 메신저로 사용 중인 NHN Dooray의 Hook API를 사용하기로 하였다.

어떻게?

Page Object Model (POM)

MVC, Singleton 등의 패턴은 알고 있었지만 막상 "E2E 테스트를 위한 디자인 패턴..?" 을 생각하니 어떤 것을 참고해야 하나 고민이 컸다.

https://playwright.dev/docs/pom Playwright 공식 문서에서는 POM 모델을 추천했고, Celenium 등 E2E 테스트를 위해 다른 라이브러리를 사용하는 경우에도 일반적으로 POM 모델을 따르고 있었다.

간단하게는 테스트가 진행되는 Page와, Page를 구성하는 Object로 나뉘어 설계를 한다고 생각하면 된다.

디렉토리 구조 잡기

POM 모델을 바탕으로 테스트 케이스를 추가하며 디렉토리 구조를 설계하기 시작했다. 그리고.. 정말 많이 고민하고 많이 갈아엎었다.

대략적인 구조는 아래와 같다.

SRC

src
├── admin
└── front
    ├── page-locators
    │   ├── mobile
    │   └── pc
    │       ├── login
    │       │   ├── ILoginLocators.ts
    │       │   ├── LoginPage.ts
    │       │   ├── skinA
    │       │   │   └── LoginLocators.ts
    │       │   └── skinB
    │       │       └── LoginLocators.ts
    │       └── ...
    └── paths
        └── PagePaths.ts

COMMON

Page, Object 세팅과 관련된 요소들을 src 하위로 위치시켰다면, 테스트 실행 전후, 테스트에서 전반적으로 활용되는 요소들은 common 하위로 위치시켰다.

☑️ common/data

common
├── data
│   └── ...

static 변수로 값을 저장하여 프로젝트 전반에서 활용되어야 하는 data 정보를 관리하는 곳이다.

테스트 실행 시, 테스트 정보에 대한 파라미터는 env 값으로 전달 받는데, env 값을 static 변수로 저장하여 프로젝트 전반에서 활용할 수 있도록 해야했다. 지금은 이 역할을 common/data/** 에서 담당하고 있다.

// common/data/env/Domain
export class Domain {
    static hasDomain: boolean = process.env.DOMAIN !== undefined

    static DOMAIN: string = Domain.hasDomain ? process.env.DOMAIN! : ""
    static SUBDOMAIN: string = Domain.hasDomain ? (new URL(process.env.DOMAIN!).hostname!).split('.')[0] : ""
    // ... 생략
}

☑️ common/external

외부 서비스와의 연동이 필요한 경우가 많았다. Dooray Hook 알람, Jenkins 빌드, OBS 업로드 등등.. 외부 서비스와 api로 통신하는 곳은 external 폴더 하위로 분류하였다.

├── external
│   ├── dooray
│   ├── jenkins
│   └── obs

☑️ common/fixture

├── fixture
│   ├── Fixture.ts
│   └── (domain)
│       ├── Member.json
│       └── ...

테스트에 필요한 실제 데이터 값을 보관하고, 읽는 곳이다. Fixture 클래스는 json 파일을 읽어 원하는 데이터를 array로 반환해주는 역할을 담당한다.

import { Domain } from '@common/data/env/Domain'
import * as fs from 'fs'

export class Fixture {
    static get(fileNm: string, key: string) {
        const jsonFile = fs.readFileSync(`common/fixture/${Domain.SUBDOMAIN}/${fileNm}.json`, 'utf8')
        const fixture = JSON.parse(jsonFile)[key]
        return fixture
    }
}

예를 들어 Memeber.json 파일 내에는 아래와 같이 데이터가 저장되어 있고,

{
    "testUser": {
        "id": "(id)",
        "name": "(name)",
        "pw": "(password)"
    },
    ...
}

실제로 값을 읽을 때는 아래와 같이 호출한다.

const fixture = Fixture.get("Member", "testUser")

☑️ common/hook

├── hook
│   ├── CustomReporter.ts
│   ├── afterEach
│   │   └── ...
│   └── beforeEach
│       └── ...

Playwright에서 기본적으로 제공해주는 Reporter 인터페이스를 implements하면 본인이 원하는 커스텀 레포트를 만들 수 있다.

export default class CustomReporter implements Reporter {
    // 전체 테스트 시작 전
      onBegin(config: FullConfig, suite: Suite): Promise<void> { }

      // 전체 테스트 종료 후
      onEnd(result: FullResult): Promise<void> { }

      // 개별 테스트 시작 전
      onTestBegin(test: TestCase, result: TestResult): void { }

      // 개별 테스트 종료 후
      onTestEnd(test: TestCase, result: TestResult): void { }
}

각 케이스에 따라 적절하게 로그나 외부 api 호출 등을 추가하여 테스트 실행 결과 관리를 하였다.

☑️ common/log

├── log
│   └── Logging.ts

이번 프로젝트에서는 winston로 로그 관리를 하였다. 로그 작성에 대한 소스코드는 위 클래스로 관리하였다.

☑️ common/page

├── page
│   ├── Admin
│   │   └── AdminPageCommon.ts
│   ├── Front
│   │   ├── MobilePageCommon.ts
│   │   └── PcPageCommon.ts
│   └── PageCommon.ts

Page 관리에 대해 Common한 요소들만 모아놓은 곳이다. Page 공통적으로 필요한, 특정 페이지를 여는 것을 Page.open()이라는 하나의 메서드로 통일시키기 위해 고민한 결과이다. 이건 별도의 포스팅으로 정리하는 것이 좋을 듯 싶다.

➡️ (포스팅 완성 후, 여기에 링크가 생성될 예정입니다.)

tests

tests
├── admin
│   └── Login.spec.ts
└── front
    ├── mobile
    │   └── Login.spec.ts
    └── pc
        └── Login.spec.ts

tests 내부도 src와 같이 depth를 환경 - 서비스 - 스킨으로 잡았다. 테스트 코드 작성은 보통 아래와 같은 구조를 따른다.

/**
 * @Title ( 테스트 제목 )
 * @Level ( 테스트 우선순위 )
 * @Given
 * ( 테스트 사전 조건)
 * @When
 * ( 테스트 수행 절차 )
 * @Then
 * ( 테스트 기대 결과 )
 */
test("[FRONT][PC] Login_0001: 로그인_성공", async ({ page }) => {
    // given
    let mainPage = new MainPage(page)
    let header = new Header(page)
    let loginPage = new LoginPage(page)
    const fixture = Fixture.get("Member", "commonUser")

    // when
    await mainPage.open()
    await page.click(header.locators.aLogin)
    await page.fill(loginPage.locators.inputId, fixture.id)
    await page.fill(loginPage.locators.inputPw, fixture.pw)
    await page.click(loginPage.locators.buttonLogin)
    await page.waitForNavigation({ waitUntil: "load", timeout: 10000 })

    // then
    const expected = Skin.SKIN == "(skinA)" ? "LOGOUT" : "로그아웃"
    expect(await page.textContent(header.locators.aLogout)).toBe(expected)
})

테스트 코드를 보면 아마 아래와 같이 구분한 이유가 더 명확하게 보이지 않을까 싶다.

├── login
   ├── ILoginLocators.ts
   ├── LoginPage.ts
   ├── skinA
   │   └── LoginLocators.ts
   └── skinB
       └── LoginLocators.ts

스킨별 Locators 클래스는 같은 Locators 인터페이스를 바라본다.

const { LoginLocators } = require ("./" + Skin.SKIN + "/LoginLocators")

export class LoginPage extends PcPageCommon {
    readonly locators: ILoginLocators

    constructor(page: Page) {
        super(page, PagePath.LOGIN_PAGE)
        this.locators = new LoginLocators()
    }
}

구체적인 Locators 값은 각 스킨별로 구분되어있기 때문에 테스트가 돌아가는 skin env 값에 따라 자동으로 적절한 skin의 Locators를 가져오게 된다.

테스트 개발 완료

위 구조를 바탕으로 전반적인 테스트 케이스 개발이 가능해졌다. 내가 고민해서 만든 구조가 정답인지는 모르겠지만.. 여러번 갈아엎는 과정에서 비효율적인 구조를 정말 많이 버렸기 때문에 평균 이상의 역할은 하고 있다고 생각한다.

테스트 코드 작성이 완료되었다면, 이제는 실제 배포 프로세스에 E2E 테스트를 녹일 차례다. 이건 다음 포스팅에서 이어서 진행해야겠다 !

작년 말, E2E 도입이 처음 이슈업 되었고 2023년이 시작되면서 본격적으로 E2E 테스트 프로세스 도입을 내가 맡게 되었다.

처음에는 _'테스트 케이스만 추가하면 되는건가'_라고 생각하는 등 일의 난이도나 깊이에 대해 정확하게 파악을 하지 못했다.

그리고 수많은 시행착오를 겪어오면서 현재는 E2E 도입이 가능한 프로세스 구축까지 구현해두었다. 지금부터 풀어볼 이야기는 시작부터 지금까지의 도전 이야기, 그리고 실제 E2E 테스트를 하며 앞으로 겪게 될 또 다른 시행착오들도 함께 풀어나가지 않을까 싶다.

E2E 테스트가 뭔데요?

End-to-End 테스트의 약자로, 실제 사용자 시나리오를 시뮬레이션하여 프로그램의 전체 흐름을 테스트하는 유형을 의미한다. 단위, 구성테스트에서 발견하기 어려운 통합 단위의 문제를 파악하기 위한 테스트이기도 하다.

우리팀에서는 Playwright 라이브러리를 활용하기로 했다.

이유는 크게 3가지였다.

• 빠른 테스트 속도: 테스트 병렬 실행 가능
• Microsoft 사 라이브러리: 오랜 기간 관리될 가능성 높음
• codegen 기능: 빠른 테스트코드 작성에 도움을 줌

E2E 테스트가 왜 필요했나요?

사실 테스트 문화를 만들기에는 다들 너무 바빴다

테스트 코드, 꼼꼼하게 잘 작성되고 모두가 테스트 문화를 지켜나간다면 너무 좋지만 여러 개발팀에서는 시간에 쫓기다보니 일이 바쁜 경우에는 테스트코드가 우선순위에서 계속 밀려나게 된다.

현재 내가 속한 서비스 개발팀도 일이 많이 쌓여있다보니 다들 테스트 코드에 대한 문화를 고민할 여유가 없는 상황이 지속되고 있었다.

이런 상황에서 내가 어떻게 E2E 테스트 프로세스 구축을 맡게 되었을까, 사실 E2E 테스트 문화만큼은 우선순위를 조금 더 높여 도입해야했던 이유가 있었다.

배포 때마다 반복되는 수동 QA, 비효율적인 과정은 제거하자

우리 팀이 웹서비스를 개발하고 배포하는 과정은 아래와 같다.

로컬 개발 -> 알파 배포 -> 베타 배포 -> 리얼 배포

• 1달에 1번 진행하는 정기배포 (+ 베타 배포)
• 그외 필요할 때마다 진행되는 수시배포 (+ 베타 배포)

베타 배포, 리얼 배포 직후 필수로 진행해야 하는 E2E QA 리스트가 있었는데 우선순위 1번째 QA 리스트라는 의미에서 팀에서는 P1 테스트라고 명명한다.

그리고 기획팀에서 1달에 최소 2회 이상의 정해진 P1 테스트를 직접 진행해왔다. (그리고 P1 리스트에 속해있는 테스트 케이스들의 수는 거의 200~300개)

고정된 테스트를 매번 사람이 직접 반복적으로 확인하는 상황 자체가 굉장히 비효율적이었고, 이 문제를 개선하기 위해 P1 테스트만큼은 배포 직후 자동으로 테스트가 수행되도록 하는 프로세스가 필요했다.

그리고 난 정말 용감하게도 "제가 해봐도 되나요?"라고 말해버렸다. 그 당시 생각했던 테스크의 규모와, 지금 내가 되돌아보는 이 테스크의 규모 차이는 극과 극이랄까.. 그래도 많이 배울 수 있었던 너무 좋은 기회였다 (기회였다...? 사실 아직 -ing 중이다 🫠)

근데 E2E 레퍼런스가 너무 없다

사실 이번 테스크를 시작하면서 E2E 테스트라는 것에 대해 처음 찾아보게 되었고, 생각보다 너무 자료가 없어서.. 당황스러웠다.

여기서 쓴 자료가 없다는 말은 아래와 같다.

• 타 기업에서 Playwright를 활용한 성공 사례가 없다.
• 사실 타 라이브러리로도 E2E를 성공적으로 도입한 기업 사례가 거의 없다.
• 그래서인지 E2E 관련 컨퍼런스 영상이.. 1-2개 뿐이랄까..? 사실 이마저도 현재 우리팀 상황과 많이 달라서 아쉬웠다.

누군가가 잠깐 공부하려고 올린 포스팅은 사실 필요한 정보들에 가깝지 않았기 때문에 결국 맨땅에 헤딩을 하듯이 공식 문서를 미친듯이 찾아보고, 혼자 구조를 설계하며 새롭게 꾸며가게 되었다.

1년차도 안된 내가 회사에서 무언가를 처음부터 이끌고 문화를 만들어 나간다는게 조금 부담스럽기도 했고, 그만큼 잘 해내고 싶은 욕심이 컸는데 내 실력이 따라와주지 않아 속상했던 적도 많았다.

그래도 지금 포스팅으로 회고록을 작성하기 시작할 정도로 진도가 많이 나갔기 때문에 중간에 포기하지 않고 잘 이끌고 왔다고 스스로에게 칭찬 한 마디 건네주고 싶다 💪

다음 포스팅에서

다음 포스팅부터는 내가 구현한 E2E 테스트 프로세스에 대해 조금더 deep하게 소개할 예정이다. 이번 글은 약간의 빌드업과 지금까지 느낀 내 생각 정리랄까 ㅎㅎ

그렇다면 이제 2편에서 마저 작성해보는걸로!🔔

최근 들어 개인 공부의 흔적을 다시 github에 남기기 시작해야겠다는 다짐을 했다. 오랜만에 들어간 github에는 취준생 시절 맨땅에 헤딩을 하며 공부했던 흔적들이 가득했다.

첫 입사를 한 날짜는 2022-08-08, 이제 겨우 9개월 차 주니어 백엔드 개발자이지만 그럼에도 입사 전과 현재의 내 모습은 한참 비교가 되었다.

즉, 그 당시에는 멋모르고 올렸던 다양한 공부 기록들이 지금은 조금 부끄러운 병아리 수준의 기록이 되었달까..

심지어 간단히 맛보기 수준으로 코드를 작성한 것까지 레포로 모두 올려두었던 것을 보며 한시라도 빨리 정리를 해야겠다는 생각이 들었다.

github 레포들을 정리하고, 리드미 파일을 수정하다가 내 velog에 오랜만에 들어가보게 되었다. 지금 내 상황에서 참고할 만한 의미 있는 포스팅이 전혀 없었고, 약간의 검색을 통해 쉽게 찾을 수 있던 것들까지 모두 포스팅으로 올려서 개수는 매우 많았다. 내 벨로그를 다시 구경하며 '양은 많고 질은 떨어지는 블로그가 되어있었구나'라는 생각 뿐이었다.

그래서 게시글을 전부 삭제하려고 보니 벨로그에는 게시글 전체 삭제 기능이 따로 제공되지 않는 것 같았다. 그래서 큰맘 먹고 회원 탈퇴를 했다.

미련이 남는다기보다는 진짜 개발자스러운 블로그를 가꿔나갈 수 있겠다는 설렘에 기분이 좋았다.

어떤걸 올려볼까

올리고 싶은 내용은 많다. 신입 개발자로서 회사에서 배우는 다양한 것들, 그리고 느낀 점들도 대외비를 지키는 선에서 정리해볼까 한다.

지금 책들도 계속 읽고 있는데 사실 작년까지만해도 처음에는 교과서를 그대로 필기노트화 시키는 것처럼 정리를 했고, 지금 돌아보니 온전히 내꺼로 만든 듯한 정리는 아니였다. 책을 내껄로 습득해 다시 내 색을 담은 포스팅을 올리고 싶다.

👍 할 수 있다! 화이팅!