분기별 리스트업
1분기
이직 준비 시작, 커리어 멘토링, 서류-과제-면접 불합격2분기
이력서 및 경력기술서 재정비, SI 프로젝트 수행3분기
항해 플러스 수료, 인프콘, 팁스 과제 수행4분기
계속되는 서류-면접 탈락, SI 프로젝트 수행
올해 목표는 '이직'이었고, 올해 안에는 이직할 수 있을 거라고 막연히 생각했었다.
지금 생각해보면 무슨 자신감이었는지 모르겠지만.. 계속되는 서류-면접 탈락을 끝으로 결국 2024년이 지나갔다.
첫 이직 준비라 어떻게 준비하고 시작해야 할지 잘 몰랐다. 나름 계획도 짜고 "이런 곳에 가고 싶다!"라는 목표도 세웠다.
✅ 향후 10년뒤 개발자로써의 목표
- 개발 경력 10년차 이상 꾸준한 커리어
- 성과 달성을 통해 흑자 전환
- 시리즈 B~C부터 IPO 경험
- C-레벨급 실력
✅ 이직 목표
- 5년 이상 꾸준히 재직할 수 있는 회사
- 커머스(클레임/물류/전시), 핀테크, 에듀테크 도메인 경험
- 문제를 피하지 않고 피드백 수용력이 좋은 동료와 문화를 가진 회사
- 업무 프로세스가 정해지진 않았어도, 프로세스를 발전시킬 수 있는 회사
- 흑자 전환한 회사
업무 프로세스가 애매하거나 매출이 적자라 할지라도 조직에 기여하여 발전을 이루고 싶다. 그러기 위해서는 문제 인지와 수용력이 좋은 문화가 필수라고 생각한다.
무작정 내 스타일대로 이력서를 작성하기 시작했다. 이 타이밍에 당근 부동산 팀에 공고가 올라와 이력서를 제출하였고, 결과는 서류에서 떨어졌다.
탈락 안내를 받던 당일 내심 큰 기대를 했는지 멘탈이 많이 나갔었다. "문제점이 뭘까?" 혼자서는 답이 나오질 않아 바로 멘토링을 신청했다.
멘토분께서는 정말 날카롭게 문제점을 잡아주셨는데, 요약하자면 이력서가 정형화되어있지 않고 지원자의 장점을 알기 어렵다는 것이었다. 그럴것이 너무 긴 내용과 제대로 정리되어 있지도 않아 읽기 불편하여 지원자(나)를 파악하기 어려웠다.
멘토링을 받고 나서, 사실 기분이 별로 좋지 않았다. 나 자신이 피드백을 냉장하게 받아들이는 사람인 줄 알았는데, 현실은 냉정했고 나는 아직 어렸나보다.
지금 돌이켜보면 "좌절할 시간에 나의 문제점을 개선하자!"라는 생각뒤에 누군가에게 인정과 위로를 받고 싶어했던거 같다.
이후, 이력서를 재정비하고 주변 지인들에게 나와 이력서에 대해 의견을 여줘보았다. 적절한 피드백은 수용하고, 나와 다른 생각에 의견은 그런가 보구나하고 생각했다.
이 때 후회되는 것은, 나와 다른 의견에 대해서 다시 한 번 생각보지 못 한 것인데, 내가 정답이라고 생각했던 방식이 틀릴 수 있다는 것을 받아들이는 데 시간이 필요했다. "이 사람은 왜 이렇게 생각했을까?"를 고민하고 내 생각과 비교하여 개선할 점을 찾는 것이 바람직하지 않았을까 한다.
정리된 이력서 덕분에, 다행히 몇몇 기업에서 서류합격 의사를 받을 수 있었다. 과제와 코테는 통과했지만 아쉽게도 1차 면접에서는 합격 의사를 받을 수 없었다. 빨리 이직하면 좋겠지만, 실패하지 않은 만큼 내가 성장할 수 없었을 것이다. 많이 실패해보고 개선하며, 도전하는 것이 나를 더욱 성장시킬 수 있다고 믿고 앞으로도 계속해서 도전해볼 생각이다.
면접에서 탈락한 회사에 다시 도전하고 싶었다.
그러기 위해서는 지금 내가 뭘 할 수 있을지 고민해봤는데, 멘토링 때 깨달은 '다른 시각을 통해 많은 것을 얻을 수 있다'는 점이 생각났다. 그렇다면 다른 개발자들과 함께 할 수 있는 것이 무엇일지 고민하다가 항해플러스를 알게되었다. 가격적인 측면에서 많이 고민되었지만, 미래에 대한 투자에 돈을 아끼지 말자는 생각에 지원하게 되었고 무사히 수료하였다.
이 기간에서 얻은 것은 '인사이트'였다. 개발 능력 뿐만이 아닌, 좋은 개발자라면 어떻게 사고하고 행동해야 하는지를 알고 배울 수 있다는게 가장 큰 배움이었다.
내 시야에서 코드를 짜는 것보다, 다른 개발자 분은 결과를 도출하기 까지 어떤 고민을 했고, 그 과정과 문제 해결 방법에 대해서 다양한 관점에서 학습할 수 있었다.
일례로, 쿼리 옵타마이징이 필요한 과제에서 MySQL의 동작 방식을 깊이 있게 테스트를 진행하신 분이 계셨다. 해당 발표 내용은 부하테스트가 끝났음에도 MySQL이 높은 CPU 사용률을 유지하는 것을 발견했고, 그 이유는 CUD 작업으로 인한 버퍼풀의 페이지 인덱싱 과정이었다는 것이었다. 여기서 그치지 않고 Kafka 환경을 따로 구축하여 추가적인 테스트를 진행하여 여러가지 테스트 결과를 도출하셨다.
발표 내용을 정말 감명깊게 들어서 "어떻게 이런 깊이있는 사고를 할 수 있을까?"라는 생각이 들었다. 깊이있는 사고를 하기 위한 방법에 대해서 아래와 같이 정의해 보았다.
나의 경우 '이상 징후 감지' 이후 '결과 도출' 순서로 문제를 해결했다. 이렇게 한다면 빠르게 문제를 해결할 수 있겠지만 깊이있는 사고라고 할 수 없을 것이다. 그래서 필요한 것이 '예상 시나리오 정의'와 '여러 환경을 고려한 테스트'이다. 예상 시나리오를 정의함으로써 내가 알고 있는 지식의 범주를 정하고, 추가적인 테스트를 통해 다양한 측면에서 문제 바라볼 수 있을 것이다.
2분기가 시작될 무렵, 팁스 지원사업에 우리 회사가 선정되어 분산투자 서비스를 준비하게 되어 백엔드 파트를 관리하기 시작했다.
조직 규모는 작았지만 중간 관리자의 역할이 필요하다고 생각했다. 때문에 중간관리자의 역할을 수행하며 팀의 체계적인 관리 방안을 제안했다.
당시 내가 제시했던 방안은 다음과 같았다.
팀 임팩트를 만들기 위한 의견
# 데일리 스크럼:
- 매일 팀 회의를 통해 서로의 업무를 공유합니다.
# 스프린트 회고
- 1~3주 단위로 결과물을 점검하고 잘하거나 부족한 부분을 회고합니다.
- 이를 통해 문제점을 인식하고 다음에는 어떻게 해결할 지 점검할 수 있습니다.
# PR 단위 코드 리뷰:
- 코드 리뷰는 시간 낭비라고 생각하지 않습니다.
- 코드 품질 향상, 지식 공유, 팀 협업 및 소통 향상, 유지보수 용이 등등..
- 올바른 코드 리뷰 문화는 개발 속도를 향상시킬 수 있습니다.
누구 한 사람을 위한 조직이 아닌, 모두가 주도적으로 일을하고 서로가 대체할 수 있는 것이 가능한 건강한 조직이라고 생각했다. 그렇게 하기 위해서는 체계적인 프로세스와 주도적으로 일을 할 수 있는 환경과 문화가 필요하기 때문에 이와 같은 방안들을 제시했다.
결론부터 말하자면 그렇지 않았다.
이유는 팀원들을 잘 설득하지 못했고 권위적인 태도와 감정적인 대화로 인해 서로에 대한 신뢰도가 떨어진게 아닌가 생각한다. 지금까지 프로젝트를 돌아보면서 공유되지 않은 지식을 담보로 일방적인 권위를 내세우는 자신을 발견하기도 했다.
이렇게 돌이켜보니 인성이 크게 잘못된 사람처럼 보일 수 있겠다..
(굳이 변명을 하자면) 나는 상대방의 감정에 예민한 편이라 "아, 내가 말실수를 했구나"라고 생각하면 진솔한 대화를 많이 한다.
물론, 잘못한 점에 대해서 빠르게 사과하고 개인적으로 왜 그렇게 행동했는지 내 생각을 말하기도 했다. 이러한 노력 덕분에 피드백 수용력이 좋다는 이야기를 들을 수 있었고, 내가 어떤 상황에서 조심해야 할지 알 수 있는 메타인지 능력도 생겼다.
그렇다면, 우리 팀이 만든 문화는 무엇이 있을까? 팀원분들의 의견과 개인적으로 겪었던 장단점을 정리해보았다.
# 데일리 스크럼
- 좋았던 점:
업무 공유로 생산성 향상
- 아쉬운 점:
스크럼에 의미가 희석되어 비용 발생
팀원 간 의견 공유가 활발했으면 좋겠음
# 스프린트 회고
- 좋았던 점:
스프린트를 평가하고 발전할 수 있는 계기를 만듬
- 아쉬운 점:
보고 형식에 가까운 상황이 발생
# 코드 리뷰:
- 좋았던 점:
코드 공유로 서로가 대체 가능
생각치 못한 버그를 미연에 방지
개발 경험 향상
- 아쉬운 점:
맥락에 벗어난 리뷰로 혼란 발생
직접 관리자로서 역할을 경험해보니 진심으로 쉽지 않은 일이라는 걸 뼈저리게 느꼈다. 나의 부족한 점과 더불어 본격적으로 관리자로서 역할을 수행해야 한다면 뭔가 잘못될 거 같다는 생각까지 들 정도이다.
누군가를 설득하고 이해시키는 것이 어려운 일이라는 걸 몰랐다. 일례로, 회의 중 스크럼이 과연 필요한지 의문을 제시한 팀원 분이 계셨는데, 그 이유는 아침마다 진행하는 회의가 시간적 비용을 발생시킨다고 생각해서였다. 나 또한 왜 그렇게 생각하셨는지 어느정도 이해가 됐었기에 팀 회의가 끝난 후 "스크럼은 서로 겹치는 일에 의견도 이야기할 수 있어서 좋을 거 같아요"라고 말씀드렸다. 이후에도, 이 분과 일하는 방향이 맞지 않아 크고 작은 다툼이 있었고, 효율적인 생산성을 만들어내지 못했었다.
지금 생각해보면, 이분은 당시 스크럼에 문제점을 알고 있었고, 나는 팀원분의 이야기를 귀기울이지 않았다. 단지 나의 의견만을 일방적으로 전달했을 뿐이었다.
나를 누구보다 잘 아는 사람은 동료들이라는 생각이 들었고, 동료 역량평가 설문지를 만들어 감사 인사와 함께 주변 동료분들에게 부탁하여 개인적으로 설문을 진행해보았다.
악감정 없으신 거 맞나요..? 😅
다행히 솔직한 피드백을 받을 수 있었고, 나름 정리해 보자면 다음과 같은 피드백을 받을 수 있었다.
역량 | 평가 항목 | 평균점수 | |
---|---|---|---|
1 | 문제 해결 능력 | 업무에서 문제 상황이 발생했을 때 적절한 해결책을 제시하는 능력에 대하여 | 3.6 |
2 | 업무 효율성 | 주어진 업무를 효율적으로 처리하고 있는지 | 4.0 |
3 | 팀워크 및 커뮤니케이션 | 팀원과의 소통 능력 | 2.8 |
4 | 주도성 | 새로운 아이디어나 개선 사항을 제안하고 주도적으로 실행하는 모습 | 4.0 |
5 | 피드백 수용 능력 | 피드백을 긍정적으로 받아들이고 개선하였는지 | 4.0 |
'쪽팔릴 용기'라는 말이 개인적으로 정말 가슴에 와닿았다.
예전부터 자존감이 낮은 편이라 자기 방어적인 기질이 있었고, 때문에 무언가 나서는 하는 걸 굉장히 무서워했다. 그 이유가 부정적인 반응에 스스로 위축되곤 했다. 이런 상황을 마주하고 나면 나 자신이 초라해지고 한심하게 여겨지곤 했다.
딱히 계기랄 건 없었지만, 어느 순간부터 이게 잘못되었다고 느꼈고 이러다간 내 세상에 갇혀 후회만 쌓일 것 같다는 걸 무의식중에 알았던 건 아닐까 생각한다. 2023년부터 사내 스터디를 시작으로 대외적인 활동을 나갔었고, 하고 싶은 이야기가 있다면 부끄럽더라도 시도하고 넘어지고를 반복했다. 항해플러스 수료식 때는 코치/동료분들 앞에서 나의 생각을 공유하는 자리도 가질 수 있었다.
누군가와 생각을 나누는게 설레는 일이라는 걸 깨달았던 계기가 되었다.
기차안에서 발표자료를 준비했던 기억은 평생 잊지 못할 것이다.
개인적으로 존경하는 인프랩 CTO님께서 말씀하신 것처럼, 내 생각을 누군가에게 전달하고 피드백을 수용하며, 많이 배우고 싶다. 2024년이 나를 정립해 나가는 한 해였다면, 2025년은 내가 정립한 나 자신을 기반으로 도전하며, 함께 성장하는 한 해로 만들어가고자 한다.
마지막으로, 사내 동료분과 이 글을 읽어주신 여러분께 감사의 마음을 전하며 글을 마무리하고자 합니다.
지난해는 힘든 일이 많았던 것 같습니다.
그렇다고 좌절하기보다는 스스로에게 부끄럽지 않게, 앞으로 후회할 일을 만들지 않겠다는 마음으로 나아가고자 합니다.
그래서 요즘은 회고도 하고, 운동도 꾸준히 하며, 많은 사람들을 만나 긍정적인 마인드셋을 가지기 위해 노력하고 있어요.
이 글을 읽는 모든 분들이 앞으로 더 성장하고, 좋은 영향을 주고받으며 함께 발전할 수 있기를 진심으로 바랍니다.
코딩업을 하면서 문제 해결 능력 중 가장 필요한 자질이 결국 사람을 얼마만큼 이해하는가로 결론이 나더군요. 문제를 생성하는 것도, 문제를 해결해야 하는 이유도, 문제를 해결 해야하는 목적도 결국은 사람에게 있다고 봅니다. 기술적인 역량 강화나 자신의 업무 역량도 중요하지만 사람을 놓치지 않으셨으면 좋겠습니다.
배려와 친절, 타인에 대한 이해가 밑바탕으로 깔려있는 사람이 더욱 더 성장하고 발전하는 시대라고 봅니다. 피드백 받은 설문을 잘 곱씹어 보시고 단점들을 잘 고쳐나가신다면 큰 성장을 이루실거라 믿어 의심치 않습니다.
또한 회고를 통해 2024년에 있었던 여러 추억들을 돌아 보시고 같은 갈등이나 실수를 반복하지 않는 것도 중요하다고 생각합니다. 2024년의 회고를 기반으로 2025년에는 하시는 모든 일이 잘되시길 기원합니다.
글 항상 잘 읽고 있습니다. 화이팅 입니다.