주니어 백엔드 개발자의 2주년 회고: 일잘러가 되고 싶었던

😮 개발자 2주년이 되었다

취업 준비 기간 동안은 합격 소식을 기다리는 1~2일 조차도 시간이 굉장히 느리게 흘러갔던 것 같은데, 입사 후의 시간은 속절없이 빠르게 지나갔다.

 

그리고 2024년 8월 8일, 어느새 개발자로서의 2주년을 맞이했다.

내가 벌써 2주년이라니!

나는 회고를 좋아하기 때문에 8월 8일이 되자마자 회고 포스팅을 작성하고 싶었지만, 1주년 때처럼 가볍게 시작할 수가 없었다. 2주년 회고는 생각보다 더 많은 고민과 생각이 필요했다.

 

실무 경험이 쌓이면서 더 큰 규모의 중요한 이슈들이 다가왔고, 이제는 업무를 예전처럼 마냥 간단하게 처리할 수는 없었다. 뿐만 아니라 사회초년생인 만큼 다양한 사람과의 협업 속에서 처음 마주하게 된 이슈들이 많았고, 그 속에서 어떻게 대응하고 올바른 나만의 가치관을 형성해 나갈지 끊임없이 고민해야하는 순간들이 있었다. 어떤 개발 공부를 할 것인가를 넘어서, 어떤 개발자 그리고 사회구성원으로서 성장할 것인가도 함께 고민하다보니 2주년 회고에 담을 내용들에 대한 고민이 더 커져서, 시간이 꽤나 걸렸던 것 같다.

 

📝 2주년 회고에서 다룰 것들

2주년 회고는 아래의 내용을 담아 작성해보려고 한다.

• ⚒️ 서비스 안정화를 위한 유지보수 경험과 성과
• 🌠 일잘러가 되기 위한 작고 소중한 노력들
• 🔥 내부 운영 효율화를 위한 개선: "원래 그래요" 없애기

그럼 회고를 시작해볼까? 🚀

---

⚒️ 서비스 안정화를 위한 유지보수 경험과 성과

2023년을 마무리하며 다짐했던 것이 있었다.

"2024년에는 솔루션 유지보수에 더 집중해보자"

 

1주년을 맞이하기까지의 나는, 회사에서 갖춰야 할 마인드나 태도 등 준비 자세를 갖추는 것에 집중하였다. (🔗 1주년 회고 보러가기) 업무적으로는 유지보수를 병행하긴 했지만, phpunit 도입, E2E 환경 구축 등 직접적인 유지보수 보다는 서비스 품질 향상을 위한 외적 준비에 상대적으로 더 많은 시간을 할애했다.

 

혼자서 다양한 개발 문화를 공부하고 개선점을 모색해보는 등의 열정적인 자세를 유지했지만, 서비스에 대한 깊은 이해가 부족한 상태였기에 효율적이고 효과적인 개선 방안을 제안하고 즉각적으로 도입하기는 어려웠다. 그리고 고민의 시간이 길어질수록, 주어진 기간 안에 내가 서비스 유지보수에 기여할 수 있는 범위는 점점 좁아졌다. 이런 상황 속에서, 나는 '일을 잘하는 개발자' 즉 조직에서 필요로 하는 기여도가 높은 개발자가 되는 경험이 먼저 필요하다고 느꼈다. 그리고 이러한 경험이 쌓여야 실제 운영 환경에서 벌어지는 크고 작은 이슈들을 해결하며, 자연스럽게 더 많은 고민과 효과적인 해결책을 모색할 기회를 마주할 수 있을 것이라는 생각도 들었다.

 

개발자에게 가장 좋은 성장 재료는, 회사 프로젝트

(출처: 실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고 - 좋았던 선택 vs 후회되는 선택 | 인프콘 2022)

 

따라서, 2024년을 맞이한 나는 유지보수에 온전히 몰입해보기로 다짐하였다.

 

서비스개발팀의 직접적인 유지보수에 가까운 업무는 말그대로 유지보수 업무, 그리고 1:1문의 대응 2가지가 있다.

🗂️ 1:1 문의 대응

고객 대응 팀에서 간단히 해결하기 어려운 1:1문의가 있을 때, 개발팀에 지원 요청이 들어오곤 한다. 이러한 경우는 비즈니스 로직을 세밀하게 분석하거나 DB 데이터와 여러 로그를 바탕으로 이슈 원인을 분석해야 하므로 상당한 시간이 소요된다. 하지만 고객에게는 신속한 답변을 제공해야 하기 때문에, 정확성과 속도를 동시에 요구하는 작업이라 나에게는 꽤나 까다로운 업무였다.

Help me...

작년에는 1:1문의 대응이 익숙하지 않아, 평균적으로는 3~4일, 길게는 일주일 넘게 답변이 지연되기도 했다. 답변이 늦어질수록 고객대응팀에서도 난감해질 뿐더러, 나에게 할당된 다른 유지보수 작업까지 덩달아 지연되는 상황이었다. 그래서 문의 건이 할당될 때마다 일정 관리에 대한 압박이 굉장히 커졌고 정신적인 피로도 또한 높아졌던 기억이 있다. 

 

2024년 인프콘 강연 중에 인상 깊었던 내용이 있었는데, 실무 능력이 뛰어난 사람은 불이 났을 때 그 불을 빠르게 끌 수 있는 사람이라는 이야기였다. 당장 눈앞에서 불이 나고 있을 때는, 불이 나지 않게 하기 위해 어떻게 개선할지 고민하는 것이 아니라 일단 발화점을 찾아 빠르게 불부터 끄는 것이 중요하다는 것이었다.

 

위 이야기처럼, 문의 대응을 하면서 나는 '실무 능력'도 중요하다는 사실을 절실히 느끼게 되었다. 솔직히 말하면 '문의 대응 최대한 안 하고 싶다'가 가장 컸다. 하지만 결국 해야 하는 업무였기에 '내가 어떻게 하면 문의 대응에 대한 스트레스를 줄일 수 있을까?'에 대해서 고민을 하기 시작했다.

 

먼저, 파트 내에서 대응 속도가 빠른 편이었던 팀원들이 담당한 문의 대응 Task들을 빠짐없이 읽어보았다. Task를 읽으며 그 사람들의 원인 접근 방식이나 문제를 분석하는 방법을 엿볼 수 있었고, 자연스레 문제를 바라보는 관점 및 따로 공부해야 할 개발적인 지식들을 습득할 수 있었다. 더불어 로직을 빠르게 해석하고, 로그와 데이터를 통해 문제를 신속하게 추적할 수 있는 역량을 기르기 위한 노력도 했다. 집에서는 도메인별 비즈니스 로직을 틈틈이 읽었고, 로컬 환경에서 디버그 모드를 켠 채로 다양한 기능들을 사용하며 상황별로 어떤 로그가 남는지 눈으로 익혀두었다. 그리고 DB 테이블을 모두 열어보며 컬럼별로 데이터가 어떻게 관리되는지 확인하기도 했다.

 

물론 현재도 깊이 있는 확인이 필요한 건은 시간이 필요하지만, 조금씩 노력한 덕분에 현재는 문의 대응 속도가 1~2일로 짧아졌다. 그 결과, 자연스레 문의 대응에 대한 스트레스도 많이 감소했다. 더불어, 문의 대응을 통해 개발 시 꼭 고려해야 할 몇 가지 중요한 점들도 자연스럽게 습득할 수 있었다. 예를 들면 아래와 같은 4가지?

1. 적재적소에 로그 남기기
2. 트랜잭션 잘 활용하기
3. 동시 요청에 대비하기
4. OOM 발생 주의하기

 

1:1 문의 대응을 통해 미리 파악한 이 중요한 요소들 덕분에, 지금은 개발할 때 발생할 수 있는 이슈들을 사전에 고려하여 안정적으로 개발하는 습관을 갖추게 되었다.

 

🗂️ 유지보수

2024년 5월에는 PHP 최신 버전 업그레이드이라는 중요한 이슈가 있었다.

서비스의 PHP 메이저 버전이 업그레이드 되면서, 5월까지는 유지보수보다는 버전업 대응에 집중해야 했다.

 

5월 이후, 내가 담당한 유지보수 배포 건수가 궁금해서 확인해보니

• 6월: 17건
• 7월: 10건
• 8월~9월 초: 12건

6월부터는 매 정기 배포마다 최소 10건 이상의 배포를 진행했다.

지난해 내가 월 평균 2~3건 정도를 배포했던 것과 비교하면, 업무량이 크게 증가한 것을 알 수 있었다.

좌: 2024년 유지보수 프로젝트 / 우: 개발팀 프로젝트

 

또한, 가장 많이 사용하는 프로젝트의 대시보드를 통해 멤버별 업무 현황을 살펴봤을 때, 기획과 개발이 함께 사용하는 유지보수 프로젝트와 내가 속한 개발팀의 프로젝트(주로 유지보수 외의 추가 개선 업무를 다루는 프로젝트) 모두에서 내 업무 완료 수가 1위였다.

 

내 노력의 흔적은 깃헙 잔디밭에서도 확인할 수 있다 ㅎㅎ (최근 1년 간 약 2,000 건의 기여)

 

1년 간 다양한 업무를 처리하면서 여러 이슈를 해결하고, 그 과정에서 분산 처리, 캐싱, 성능 테스트, CI/CD 개선, 로그 관리, 동시성 이슈 대응 등 다양한 공부들도 병행해왔다. 하지만 이번 회고에서는 공부한 내용을 직접 언급하기보다는 지난 1년간 내 업무 능력을 향상시키기 위해 어떤 노력을 해왔는지를 적어보려고 한다.

업무를 통해 공부한 상세 내용들은 추후 별도의 포스팅으로 나눠 다룰 예정이다 😉

---

🌠 일잘러가 되기 위한 작고 소중한 노력들

🗂️ 1. 주변 이슈에도 지속적인 관심 갖기

PHP 버전업 전에는 Emergency 레벨 이상의 로그가 발생할 경우에만 웹훅을 받아 모니터링 했었다.

이때 Error 레벨로 설정하지 않은 이유는, 20년이 넘은 서비스인 만큼 레거시가 많다보니 웹훅 최초 도입 당시 Error 레벨 이상으로 받기에는 부담이 컸기 때문이다. 그러나 버전업이 완료된 서비스 만큼은 안정적인 운영과 레거시 최소화를 목표로, Error 이상 레벨부터 웹훅을 받고 있다. 버전업이 된 서비스 오픈 직후부터 지금까지 가장 많이 발생하는 웹훅 알림은 최신 버전의 타입 검사 강화로 인해 발생하는 런타임 에러다.

 

이전 버전에서 정상적으로 동작하던 기능들이 최신 버전에서 작동하지 않는다는 것은 나에겐 큰 이슈라고 느껴졌다. 그래서 서비스 품질 유지를 위해, 버전업 이후 자발적으로 에러 웹훅을 모두 살펴보고 로직과 상세 로그를 분석했다. 이를 바탕으로 에러를 잡기 위해 직접 Task를 등록하고 개선 작업을 진행하는 등 적극적으로 대응했다. 이 경험 덕분에, 나는 PHP 최신 버전의 특징에 대해 깊이 이해할 수 있었고 로직 작성 시 타입에 대해서도 더욱 꼼꼼하게 고민하는 습관을 기를 수 있었다.

 

 

또한, 인젝션 공격이 발생했을 때는 웹훅을 통해 먼저 인지하여 웹 로그를 분석해 데브옵스에 IP 차단을 요청한 경험도 있었다. 이 과정에서 다양한 인젝션 공격 패턴을 경험할 수 있었고, 생소한 표현식은 직접 검색해보며 관련 지식도 함께 쌓을 수 있었다.

 

이처럼 나에게 직접적으로 할당된 업무는 아니더라도, 팀 내에서 에러 웹훅을 지속적으로 모니터링하고 문제를 해결해 나가는 과정에서 여러 실무 경험과 지식을 습득할 수 있었다.

 

🗂️ 2. 모호함을 외면하지 않기

나는 본인이 담당한 작업에 대해서는 누구보다 잘 알고 설명할 수 있어야 한다고 생각한다.

그래서 작업 방향을 구성할 때는 디테일한 요소까지도 스스로에게 "왜 이렇게 해야 할까?"라는 질문을 던지는 편이다. 만약 스스로 설득이 되는 답변이 나오지 않는다면, 여러 레퍼런스를 찾거나 구글링을 통해 방향성에 대한 분명한 이유와 확신을 갖기 위해 노력해왔다.

지금은 잘 모르겠는데요.. 어떻게든 알아올게요...

 

또한 상대방이 질문했을 때도, 내가 말하다가 막히는 상황이 생기면 "일단 이렇게 했다고 알고 계시면 돼요."라는 회피형 대답은 절대로 하지 않았다. 조금 부끄럽더라도 "제가 지금은 헷갈리는 부분이 있어서, 더 확인해보고 언제까지 정리해서 공유드릴게요." 라고 솔직하게 말했고, 이후에 더 공부하고 확실하게 내용을 정리하는 시간을 가졌다.

 

그리고 내가 고민한 모든 흔적은 Task에 정리하여 남겨두었다. 이 기록들은 나중에 내 결정에 잘못된 점이 있더라도, 그 당시 내가 어떤 개념을 몰라서 잘못된 선택을 하였는지, 이 문제를 해결하기 위해 추가로 고려해야 할 점이 무엇인지 명확하게 확인하고 성장할 수 있는 좋은 밑거름이 되었다.

 

이러한 경험들을 통해, 나는 '단지 지금 일을 빠르게 끝내고 싶어서 애매하게 일을 마무리하는' 개발자가 아닌, '가능하면 확실하고 분명하게, 그리고 책임감 있게 일을 마무리하는' 개발자로 성장하기 위한 마인드셋을 갖출 수 있었다.

 

🗂️ 3. 시퀀스 다이어그램 꾸준히 그리기

나는 업무를 할 때, 전체적인 그림을 알고 있어야 마음이 편해지는 스타일이다.

 

문법 에러 같은 경우는 에러 메시지가 명확하기 때문에 즉시 수정하지만, 기능 개선이나 신규 개발을 할 때는 항상 흐름 파악을 위한 시퀀스 다이어그램을 그린다. 처음 시퀀스 다이어그램을 그리기 시작한 이유는 '설명하기 어려워서'였다. 내가 담당한 작업에 대해서 상대방에게 언제든지 명확하게 설명할 수 있어야 한다는 생각 때문에, 복잡한 내용을 어떻게 쉽게 전달할까 고민하면서 자연스럽게 시퀀스 다이어그램을 그리는 일이 많아졌다.

 

실제로 업무를 위해 그렸던 시퀀스 다이어그램들

 

나는 주로 draw.io를 사용하고, 급할 때는 PlantUML 를 활용해 빠르게 그리는 편이다.

 

그리고 1차 결과물이 완성되면, 주변 동료들에게 피드백을 요청해 시퀀스 다이어그램만 보았을 때 이해하기 어려운 부분이 있을지 확인한다. 그리고 누구나 쉽게 이해할 수 있는 시퀀스 다이어그램이 될 때까지 피드백을 반영해 반복적으로 다듬는 과정을 거친다.

 

시퀀스 다이어그램을 미리 그리는 습관 덕분에 실 개발에 들어가기 전 논리적 오류를 빠르게 발견한 수 있었고, 시각적인 자료가 준비되어 있으니 타팀과 협업할 때도 R&R를 명확하게 정리할 수 있어 커뮤니케이션이 원활했다. 또한 시간이 지나 다시 확인해야 할 때도, 복잡한 로직을 일일이 파악할 필요 없이, 이미 그려둔 Flow를 통해 쉽게 이해할 수 있어 업무 효율성에도 큰 도움이 되었다.

 

꾸준히 시퀀스 다이어그램을 그린 경험 덕분에, 이제는 개발에 앞서 전체적인 그림을 구상하고 시각적으로 표현하는 것이 훨씬 수월해졌다!

 

🗂️ 4. 업무 "잘" 하기

업무를 잘한다는 말은 많은 의미를 내포하고 있다.

- 일정 관리를 잘한다.
- 완성도 높은 결과물을 낸다. (= 버그가 없고, 퀄리티 높은 소스코드 품질을 유지한다.)
- 작업한 내용에 대하여 꼼꼼하게 정리 및 공유를 잘한다.

 

그리고 모든 주니어 개발자들은 업무를 잘하기 위해 끊임없이 노력하지만, 그만큼 많이 실패하기도 할 것이다. 나 또한 그랬다. 신입 시절에는 호기롭게 개발 기간을 3일로 공유했다가 3주가 지나서야 완성한 적도 있었고, 배포 후 에러가 발생하여 롤백을 진행한 것은 물론, 작업한 내용을 공유할 때 빠진 내용들이 많아서 조직장으로부터 '이 내용도 추가해주세요'라는 피드백도 자주 받았다.

 

1주년이 되기까지는 업무를 하는 방법을 익히기 위해 노력했고, 2주년이 되기까지는 업무를 "잘" 하기 위해 많은 노력을 해왔다.

노력하는 과정에서 나는 아래 3가지에 특히 힘쓰게 되었다.

- 📝 업무 템플릿 만들기
- 🔖 근거 있는 말하기 & 좋은 언어 습관 만들기
- ✏️ 메신저 소통 그만, 공유 및 기록의 중요성

 

📝 업무 템플릿 만들기

연차가 쌓이면서 내가 담당해야 하는 업무량이 점차 많아졌고, 동시에 여러 작업의 진행 상황과 세부 내역을 체크해야 했다. 그러다 보니, 과거에 내가 남긴 코멘트가 있음에도 불구하고, 통일성이 없어서 그 당시에 왜 그렇게 작성했는지 기억을 되살리는 데 시간이 걸리곤 했다.

 

내가 남긴 코멘트를 나조차도 다시 해석해야 하는 상황이니, 업무 내용을 공유 받는 다른 팀원들은 더 큰 혼란을 겪었을 수도 있겠다는 생각을 했다. 그 당시 자유롭게 남겼던 코멘트는 결국 '재해석이 필요한 암호'가 되었고, 암호를 풀기 위해 메신저로 추가 질문을 받는 등의 불필요한 커뮤니케이션이 발생했다. 처음부터 제대로 정리해두었다면 이런 핑퐁은 없었을 텐데..

 

그래서 어느 순간부터 작업 내역과 진행 상황을 보기 쉽게 정리할 수 있는 업무 템플릿을 만들어야겠다고 결심했다.

고정된 템플릿을 통해 정보를 기록하면, 나중에 다시 확인하기도 훨씬 수월할 것이라는 기대감이 있었다.

 

그렇게 탄생한.. 나의 작고 소중한 업무용 템플릿! 😊

누군가는 이걸 보고 정리 변태라고 하였다..ㅋㅋ🙃

 

완성하고 나니, 장점이 정말 많았다.

 

1. 그때그때 생각해서 코멘트를 작성할 필요 없이, 템플릿을 복붙하고 필요한 내용만 채워 넣으면 된다.

2. 고정된 템플릿 덕분에, 나중에 Task를 확인할 때도 진행 상황을 한눈에 파악할 수 있어 히스토리 확인이 수월했다.

3. 업무마다 기록해야 할 내용들이 이미 종류별로 정리되어 있어서, 작업 일정이나 필요한 코멘트 등이 누락되지 않는다.

나는 실제 업무에서 위와 같이 활용 중이다.

 

꺄아~~

실제 업무에 템플릿을 적용한 후 비개발팀으로부터 내용을 이해하기 편하다는 피드백을 받았고, 협업에 도움이 되었다는 생각에 혼자 소소한 만족감도 느꼈다 ㅎㅎ

 

🔖 근거 있는 말하기 & 좋은 언어 습관 만들기

나는 일할 때만큼은 '뇌피셜', 즉 추측성 발언을 좋아하지 않는다. 그래서 업무 관련 대화를 나눌 때, 항상 '내가 말하려는 것이 충분히 설득력 있는 말인가?'라는 질문을 스스로에게 던지고, '그렇다'라고 답을 할 수 있을 때 말을 꺼내곤 한다.

 

이런 성향은 대학 시절 영상 촬영, 발표, 논문 작성 등의 활동에서 먼저 길러졌다. 예를 들어, 영상 촬영을 위한 스토리보드를 그릴 때도 매 컷마다 사용할 샷, 앵글, 카메라 워킹에 대해 세세한 이유를 고민해야했고, UX/UI 관련 발표를 할 때도 모든 내용에 대해 설득력 있는 사례를 준비해야 했다. 특히 메타버스 게임 관련 UI 논문을 작성할 때는 한 문단을 완성하기 위해 팀원들과 참고문헌을 5~6개씩 찾아보고, 한 문장을 쓰기 위해 1~2시간씩 토론하는 것이 일상이었다. 이런 경험 덕분에, 개발을 할 때도 '이 기능이 왜 필요할까?', '이 방법이 왜 좋을까?'를 계속해서 고민하고 스스로 답을 찾아보게 되었다.

 

요즘은 AI 기술의 발달로 ChatGPT나 SonarLint 같은 도구의 도움을 받기도 한다. 나 역시 효율적인 방향성을 제시받기 위해 사용하곤 하지만, AI가 추천한 내용을 그대로 적용하지는 않는다. ChatGPT도 결국 방대한 인터넷 데이터를 기반으로 답변을 제공하기 때문에, 추천 내용이 신뢰할 만한 포스팅이나 공식 문서에 나와있는지를 내 눈으로 직접 확인하고 나서야 적용한다. 아마.. 누구도 'ChatGPT가 추천해줘서 사용해봤습니다.'라는 말만 업무 히스토리에 남기는 사람과 함께 협업하고 싶어 하지는 않을 것이다.

 

이처럼 '모든 작업에 충분한 근거가 있어야 한다'는 내 가치관은, 내 언어 습관 형성에도 많은 영향을 미쳤다. 나는 업무 중에는 정말 필요한 경우가 아닌 이상 '~것 같아요/같습니다'라는 불확실한 표현은 사용하지 않는다.

(물론 협업 상황에서 부드럽게 의견을 제안할 때는 사용하기도 하지만, 그 전에 충분한 이유를 설명하는 걸 우선시 한다.)

 

내가 지양(❌)하는, 그리고 지향(✅)하는 대화 방식은 아래와 같다.

[기획자와의 대화]
기획자: "현재 로그인 불가 이슈가 A 기능 배포 때문일까요?"
개발자
: "네, A 기능 때문일 것 같습니다. 핫픽스가 필요할 것 같습니다." (❌)
: "네, A 기능 개선 과정에서 로그인 세션에 수정이 이루어졌고, 그 영향으로 예상되어 검토 중입니다. 추가 확인 후 핫픽스 진행 여부 공유드리겠습니다." (✅)

[코드 리뷰]
개발자A: "이 부분에서 특정 입력값에 따라 이슈가 발생할 수 있을 것 같은데, 괜찮을까요?"
개발자B
: "네, 다시 검토해보니 이슈가 있을 것 같습니다. 수정하겠습니다." (❌)
: "네, 말씀하신 특정 입력값이 들어올 경우 {@} 에러가 발생하는 것을 확인했습니다. 예외 처리가 가능하도록 수정했습니다." (✅)

[업무 보고]
리더: "개선 방향은 어떻게 잡았나요?"
개발자
: "Redis Lock을 쓰면 좋을 것 같아서, 이 방향으로 가려고 합니다." (❌)
: "해당 문서 검토 시, 동시성 이슈를 Redis Lock으로 해결할 수 있는 것으로 확인했습니다. Redis Lock을 활용한 구체적인 개선 방안 작성 후 추가 피드백 요청드리겠습니다." (✅)

[회의]
팀원A: "그러면 이번 배포 대상에서 서버1은 제외하면 될까요?"
팀원B
: "네, 서버1은 제외하면 될 것 같습니다." (❌)
: "네, 이번 배포 대상에서 서버1은 제외 부탁드립니다." (✅)

 

커뮤니케이션 과정에서 불확실한 표현을 사용하면 신뢰도가 자연스럽게 떨어진다. 이로 인해 업무 진행 중에 불필요한 재확인 요청이 이어져 업무 효율성까지 저하될 수 있다. 그래서 나는 항상 명확한 답변을 제공하려고 노력하고 있다. 이를 위해서는 누구보다도 내가 문제 상황을 정확히 파악하고 있어야 하기 때문에, 자연스럽게 나에게 할당된 모든 일을 꼼꼼히 검토하고 내용을 충분히 숙지하며 기록하는 습관을 갖게 되었다. 이러한 습관은 업무에 대한 책임감과 처리 정확도를 높이는데 큰 도움이 되었다 👍

 

✏️  메신저 소통 그만, 공유 및 기록의 중요성

나는 업무 중에 메신저로만 소통하고 끝내는 것을 선호하지 않는다. 특히 상대방이 Task 진행 상황이나 세부 내용에 대해 질문했을 때, 메신저로만 답변하고 마무리하는 상황은 피하려고 한다. 누락된 내용을 Task에 보충하지 않고, 메신저로만 소통을 마치면, 나중에 다른 팀원이 그 내용을 파악하려 할 때 불필요한 커뮤니케이션이 반복될 수 있기 때문이다.

그래서 나는 보충이 필요한 부분에 대해서는 Task에 즉각적으로 피드백을 반영한 후, 메신저는 보조적인 소통 수단으로 활용하고 있다. 즉, Task에 작성된 내용을 중심으로 논의가 이루어질 수 있도록 노력하고 있다.

 

과거 Task 히스토리를 살펴보면, 아무런 코멘트 없이 '완료'로만 표시된 경우가 종종 있었다. 이런 경우 나중에 히스토리를 다시 확인하려 할 때 어려움이 많았다. 그래서 나는 업무를 관리할 때 실시간으로 업무 상태 태그(ex. 개발 진행, QA 진행 등)를 업데이트하고, 이벤트 소싱처럼 모든 중요한 진행 상황을 코멘트로 기록하는 습관을 들였다.

업무 기록 남겼던 예시

사실 이 습관은 나 뿐만 아니라, 팀 전체를 위한 기본적인 배려라고 생각한다.

꼼꼼하게 기록을 남기는 습관 덕분에 Task 링크만 공유해도 업무 진행 상황을 쉽게 전달할 수 있어 불필요한 소통을 줄일 수 있었고, 이후 내가 진행했던 업무의 히스토리를 확인할 때도 과거 이슈, 논의 내용, 개선 방향성, 일정 지연 사유 등을 명확하게 확인할 수 있어 업무 대응이 훨씬 편해졌다 😊

 

🗂️ 5. 적극적인 코드리뷰

코드리뷰의 중요성은 아무리 강조해도 지나치지 않다. 내가 왜 코드리뷰를 열심히 했는지에 대해서 길게 설명하기보다는, 더 나은 코드리뷰를 위해 참고했던 유용한 포스팅들을 첨부하는 것이 더 좋겠다 :)

 

🔗 코드 리뷰를 왜 해야하는가?

🔗 코드 리뷰는 스포츠다

 

코드 리뷰를 꾸준히 진행하면서 느낀 점 중 하나는, 몇 달 전 까지만 해도 "A라는 이슈에 대해 다시 검토하고 수정 부탁드립니다"라는 피드백이 여러 PR에서 올라왔다면, 이제는 코드 리뷰에 활발히 참여했던 팀원들이 개발 시 A라는 이슈를 사전에 고려하여 PR을 올리게 되었다는 것이다. 덕분에 시간이 지날수록 더 수준 높은 코드 리뷰가 이루어지고 있음을 실감했다. 서로의 기술적 지식을 보완하며, 코드 리뷰가 더욱 활발하게 이루어질 수 있다는 점에서, 나도 꾸준히 코드리뷰에 적극적으로 참여하고 효과를 증폭시키기 위해 노력해야겠다는 다짐을 하고 있다.

---

🔥 내부 운영 효율화를 위한 개선: "원래 그래요" 없애기

입사 초기 1년은 모든 것이 새롭고 정신없이 지나갔지만, 이제 2년이 지나고 나니 서비스에 적응하면서 시야가 조금 더 넓어졌다. 현재는 서비스의 유지보수뿐만 아니라, 팀의 성장에 병목이 되는 부분이 발생하지 않도록, 개선이 필요한 점이 있을지 꾸준히 고민하는 팀원으로서의 역할도 수행하기 위해 노력 중이다.

 

협업에서 가장 중요한 포인트 중 하나는 문제에 대한 공감이라고 생각한다. 팀이 긍정적인 방향으로 나아가기 위해서는 모두가 불편한 점을 공감하고, 그에 대한 개선 방안에 대해 적극적으로 고민할 수 있어야 한다.

원래 그래요

 

내가 개인적으로 정말 싫어하는 문장이다. 모든 회사가 그렇겠지만, 업무 진행 중 불편함이 있어 '왜 이렇게 했을까?' 하고 히스토리를 찾아봤을 때, '원래 이랬다'라는 이유로 개선되지 않은 부분들이 있었다. '문제가 있어서 개선했다'가 아닌, '원래 그랬으니 작업자가 이 히스토리를 알고 스스로 챙겨야 한다'는 수동적인 접근 방식이었다. 서비스에 어느 정도 적응하기 시작하면서, 점차 눈에 들어오는 방치된 레거시들을 없애기 위한 노력을 시작했다.

🗂️ 1. Git Flow 도입

처음 팀에 합류했을 때는 뚜렷한 Git Flow가 없었다. 신입이었던 나는 처음엔 서비스에 적응하느라 다른 것을 돌아볼 여유가 없었기에 처음에는 문제 상황을 인지하지 못했다. 그렇게 1년이란 시간이 흘러 23년 9월이 되었고, 배포 담당이라는 새로운 역할을 맡게 되면서 main 브랜치 상태를 다시 보게 되었다.

그 당시 파트의 Git Flow

당시 파트의 Git Flow는 모든 병합 방식이 "Create a merge commit"이었다. 그리고 main 브랜치로 리얼 배포가 나간 다음, QA 공용 브랜치(release, develop)를 최신화하기 위해 다시 역방향으로 "Create a merge commit"을 해주었다.

이로 인해 merge commit으로 인한 main 브랜치의 타임라인은 지저분해졌으며 특정 이슈에 대한 커밋이 push 된 시점으로 섞여있기에 한눈에 개선 건의 diff를 확인하기 어려웠다. 😢

 

또한, 파트 내 Commit Message Convention이 존재하지 않아 해당 커밋이 어떤 이슈로 인해 수정되었는지를 연결지어 확인하기가 어려웠다. 이러한 상황을 돌아보며, '개선된 소스코드만 올라가 있으면 된다'에 만족하고 있다는 느낌을 강하게 받았다. Git Flow가 존재하지 않았기에 PR을 올리고 머지하는 과정에서 충돌이 더 잦았고, 개개인의 편의에 따라 충돌을 해결하다보니 불필요한 소스코드가 반영되는 경우도 발생했다. 한번은 개선되었던 소스코드가 잘못된 충돌 해결과정에서 원복된 경우도 봤었다. 결국 추후 히스토리 확인 시에는 추적하는데 많은 시간이 소요되었고, 장기적으로는 기술적 부채가 쌓이는 상황이 되었다.

내가 새롭게 제안한 Git Flow

이 문제를 해결하기 위해, 파트에서 활용 가능한 Git Flow에 대해 고민하고 새롭게 제안했다. 위 Flow는 우리 서비스 QA 환경의 특수성과 기획-개발 간 협업을 위해, 통용되는 Git Flow를 파트 특성에 맞게 약간 변형한 결과이다.

그 결과, 훨씬 깔끔해진 Timeline

서비스 품질 관리를 위해 꼭 필요한 기본적인 과정인 만큼, Git Flow 도입의 필요성을 공감받기 위해 정말 열심히 설명했고, Git에 대한 이해도 향상이 필요한 경우에는 먼저 도와주는 등 꾸준히 노력한 결과 내가 제안한 Git Flow를 현재 우리 파트의 개발 문화로 정착시키는 데 성공할 수 있었다. 그 결과, 현재 팀의 Git 이해도도 전반적으로 향상되었고, 코드 버전 관리가 더욱 용이해져 코드의 안정성이 높아졌다. 덕분에 롤백 및 핫픽스에 대한 신속한 대응도 가능해졌다.

 

🗂️ 2. 배포 프로세스 개선

배포를 담당하게 되면서, Git Flow에 이어 배포 프로세스도 함께 개선하게 되었다.

 

소스 배포 방법을 인수인계 받는 과정에서, 처음에는 혼란스러운 점이 많았다. 젠킨스 파이프라인 내에 사용하지 않는 옵션들이 그대로 남아있거나, 실제 동작 과정이 옵션명과 일치하지 않는 경우도 있었다. 예를 들어 CHECKOUT 옵션을 선택했을 때, 브랜치 변경이 아닌 특정 커밋이 추가되는 작업이 수행되는 식이었다.

 

이처럼 직관적이지 않은 UI 속에서 배포 실수를 하지 않으려면, 구두로 인수인계된 내용을 정확히 기억하고 있어야 했다. 대학 시절 4년간 UX/UI를 공부했던 나에게는 이 상황을 공감하기가 어려웠다.

일반적으로 UI는 UX를 고려하여 만들어지는데, 반대로 사람이 UI에 맞춰야 하는 환경이 과연 올바른걸까?

 

결국 나는 이 문제를 직접 개선하기로 결심했다.

(어떻게 보면, 미디어커뮤니케이션학부에서 공부한 것들이 실무에서 여러 방면으로 꽤 도움이 된 것 같다.)

 

젠킨스 파이프라인 UI 개선을 시작으로, 배포 프로세스 내 UX적으로 불편한 부분들을 하나둘씩 고쳐나가기 시작했다. 세부적인 개선 사항들을 모두 언급할 수는 없으나 많은 부분들을 자동화하고, 배포 과정에서의 휴먼 에러를 방지할 수 있도록 여러 유효성 검사를 추가해 서비스의 안정성을 높였다.

 

이렇게 문제 해결에 자발적으로 나서면서, 현재까지 약 1년간 꾸준히 배포 프로세스 개선을 담당하고 있다. 

꾸준한 개선을 통해, 배포 실수가 발생했을 때 단순히 '다음부터 주의해주세요'로 끝나는 것이 아닌, '휴먼 에러를 방지하기 위해 UX/UI를 어떻게 더 개선할 수 있을까'를 고민하는 분위기로 자연스럽게 변하는 것을 보며 큰 만족감을 느꼈다.

---

🤔 앞으로의 계획은?

2주년을 맞이하기까지, 나는 좋은 실무자로서 맡은 일을 책임감 있게 잘 수행하기 위해 꾸준히 노력해왔다. 실무 능력을 키우기 위해 집에서도 계속 고민했고, 업무 중 모르는 개념이 생기면 열심히 찾아보고 공부하는 등 개발 지식을 쌓기 위한 노력도 멈추지 않았다. 그 결과, 지금까지는 내가 맡은 Task에 대하여 충분한 이해를 갖춘 상태에서 올바른 방향으로 업무를 수행할 수 있었다.

 

그동안 수많은 새로운 이슈들을 해결하며 성장했지만, 동시에 스스로에게 느끼는 아쉬움도 커져갔다.

탄탄한 기본기가 필요하다.

 

2주년을 맞이하면서, 가장 많이 떠올렸던 문장이다.

 

점차 복잡한 이슈를 맡게 되면서 집에서는 개념 공부를, 회사에서는 공부한 개념을 바탕으로 개발에 집중하는 시간이 많아졌다. 하지만 업무 해결을 위한 학습에 치중하다 보니, 내 기준에서는 깊이 있는 학습이 부족하다는 아쉬움이 생겼다. 앞으로는 새로운 개념을 배울 때 별도의 시간을 충분히 마련해, 지식을 더 체계적으로 확장하고자 한다. 흩어져 있는 지식을 단편적으로 익히는 것이 아니라, 하나의 큰 그림으로 정리해 머릿 속에 담아두는 것이 목표다.

 

이를 위해.. 기술 블로그도 더 열심히 운영해야겠지? :)

 

2년이라는 짧고도 긴 시간 동안, 열심히 달려온 나 자신에게 고생했다고 말해주고 싶다.

앞으로도 잘해보자! 화이팅!