🌱 서론
11월을 끝으로 저는 현재 다니던 회사를 떠나게 되었습니다. 정확히 말하자면 자진퇴사가 아닌 권고사직을 받게 되었습니다. 두 번째 직장은 길게 다니겠다는 마음을 먹고 입사했지만, 제 의지와는 다르게 회사 사정이 좋지 않아 이렇게 권고사직을 받게 되었습니다.
25년 2월부터 약 9개월 조금 넘게 근무한 짧은 시간이었지만, 좋은 동료분들을 만나며 개발자로서 성장할 수 있었던 너무나도 소중한 시간이었습니다. 이번 직장을 통해 배운 것들을 잊지 않기 위해, 그리고 다시 한 번 머릿속에 정리하고자 회고를 작성하게 되었습니다.
🔍 로그는 개발자에게 이정표
로그는 내가 올바른 방향으로 개발하고 있는지, 혹은 반대로 잘못된 방향으로 가고 있는지를 확인할 수 있는 이정표다.
입사 초기의 저는 로그를 제대로 활용하지 못했습니다. 개발한 기능이 의도대로 작동하지 않으면 무작정 코드를 다시 살펴보며 감으로 문제를 찾으려 했습니다. 그러다 보니 작업 능률도 좋지 않았고, 실수도 종종 발생했습니다.
코드 리뷰를 하던 중 한 팀원분께서 “코드 사이에 로그를 작성하는 습관을 들여보면 좋겠다”는 피드백을 주셨습니다. 평소 그분이 로그를 적극적으로 활용해 문제를 해결하는 모습을 많이 봤기에, 저는 그 조언을 받아들여 로그를 본격적으로 작성하기 시작했습니다.
로그를 넣어가며 코드를 확인하는 방식으로 바꾸고 나니, 문제 해결 방식 자체가 완전히 달라졌습니다. 예전에는 “왜 안 되지?” 라는 막연한 상태에서 전체 코드를 뒤집어보는 정도였지만, 로그를 활용하면서부터는 의심해야 할 포인트를 단계적으로 좁혀가는 방식을 자연스럽게 익힐 수 있었습니다.
특히
- 어떤 흐름이 정상적으로 이어지는지
- 어디에서 흐름이 끊기는지
- 특정 값이 어떤 시점에서 비정상적으로 바뀌는지
이런 지점들을 로그로 하나씩 확인하다 보니 문제를 구조적으로 바라보는 습관이 생겼습니다.
또한, 로그는 협업에서도 큰 장점이 되었습니다. 문제가 발생했을 때 단순히 “에러가 났습니다”가 아니라 “어떤 API 호출 이후 응답 값이 null이며, 해당 시점에 ~~ 로그가 발생했습니다” 와 같이 상황을 명확히 공유할 수 있었기 때문입니다. 그 덕분에 문제 해결 속도도 빨라졌고, 원인 공유 과정도 훨씬 명확해졌습니다.
이번 직장 생활을 통해 가장 크게 배우고 느낀 점은, 로그는 단순한 출력이 아니라 개발의 방향을 잡아주는 진짜 이정표라는 것입니다. 앞으로 어떤 프로젝트를 하더라도, 어떤 환경에 있더라도“기능을 믿지 말고, 로그를 믿어라.”이 마음가짐을 잃지 않으려고 합니다.
💬 커뮤니케이션은 짧고 굵게
길고 장황한 커뮤니케이션보다는 핵심적인 내용을 함축하고 있는 커뮤니케이션이 좋은 커뮤니케이션이다.
입사 초기에 유지보수 업무를 맡으면서 팀원 두 분에게 코드 히스토리를 듣게 되었습니다. 한 분께서는 히스토리를 매우 상세하고 깊게 설명해주셨고, 다른 한 분께서는 핵심 흐름만 간단히 짚어주신 뒤 모르는 점이 생기면 언제든 질문하라고 말씀해주셨습니다.
두 방식 모두 장점이 있었지만, 실제로 업무를 진행하며 더 도움이 되었던 것은 후자의 방식이었습니다. 짧고 굵게 핵심만 전달받으니 전체 구조를 빠르게 이해할 수 있었고, 이후 필요한 부분만 골라 질문하며 세부 내용을 채워 넣을 수 있었습니다. 오히려 처음부터 지나치게 많은 정보를 들었을 때보다 더 능동적으로 코드를 탐색하고, 스스로 의문점을 만들어가는 데에 큰 도움이 되었습니다.
이 경험을 통해 커뮤니케이션은 정보의 양보다 맥락과 방향성이 중요하다는 것을 깨달았습니다. 상대가 바로 실행하거나 판단할 수 있도록 본질만 전달하고, 필요한 설명은 그때그때 보충하는 방식이 훨씬 효율적이라는 점을 실무에서 체감했습니다. 그래서 저도 이제 슬랙 메시지를 보내기 전이나 직접 대화를 하기 전에, 꼭 전달해야 할 핵심 내용을 먼저 추리고 그 내용을 바탕으로 질의응답을 이어가려 노력하고 있습니다.
그리고 이 과정을 겪으며 한 가지를 더 확실히 느꼈습니다. 좋은 개발자는 짧고 명확한 코드로 동료들을 설득하고 기능을 구현하는 것도 중요하지만, 그만큼 커뮤니케이션 능력 역시 개발 실력 못지않게 중요하다는 점입니다. 서로의 이해를 맞추고, 방향성을 공유하고, 협업의 속도를 높이는 것은 결국 사람 사이의 대화에서 시작되기 때문입니다. 기술적 역량과 커뮤니케이션 역량은 따로 존재하는 능력이 아니라, 함께 성장해야 팀 전체의 효율이 올라간다는 사실을 이번 경험을 통해 배울 수 있었습니다.
📝 기록은 항상 꼼꼼히
아무리 기억력이 좋다 한들, 매번 기록을 통해 남겨둔 문서들을 이기지는 못한다.
개발자로서 근무하며 크게 체감한 것 중 하나는 기억은 생각보다 빨리 희미해지고, 기록은 생각보다 큰 힘을 발휘한다는 것이었습니다. 입사 초반에는 '이 정도는 기억해두면 되겠지'라는 마음으로 간단한 이슈나 흐름 정도는 머릿속에만 저장해두곤 했습니다. 하지만 며칠만 지나도 정확한 변수명, API 흐름, 문제가 발생했던 시점과 원인이 흐릿해지면서 같은 내용을 다시 확인하는 일이 반복되었습니다.
- 어떤 기능을 왜 그렇게 구현했는지
- 어떤 버그가 있었고, 왜 그렇게 해결했는지
- 전체적인 기능 흐름이 어떻게 흘러가는지
이런 내용들은 시간이 지나면 반드시 다시 마주하게 되는 부분들이었습니다. 그리고 그 때마다 기록이 되어있지 않으면 그 때의 상황을 다시 떠올리기 위해 노력하거나, 처음부터 다시 파악하는데 시간이 들었습니다.
그래서 저는 점점 작은 것이라도 기록하는 습관의 가치를 깨닫게 되었습니다. 공용 노션 문서에 단순한 이슈 해결이든, 특정 기능의 히름이든 상관없이 "나중에 다시 봐도 이해할 수 있을 만큼"정리해두기 시작했고, 정리해둔 기록은 큰 자산이 되었습니다.
- 같은 실수를 반복하지 않게 되었다.
- 문제를 해결한 과정이 정리돼 있어 다른 팀원에게 공유하기도 훨씬 쉬워졌다.
- 과거의 나와 대화하듯 참고할 수 있어, 작업 속도도 빨라졌다.
- 배운 것이 기록으로 축적되면서 ‘성장하고 있다’는 감각을 스스로 느낄 수 있었다.
기억은 일회성이고, 기록은 자산이다. 아무리 작은 내용이라도 기록해두면 미래의 저에게 가장 친절한 가이드가 되어준다는 것을 몸소 느낄 수 있었습니다. 앞으로 새로운 직장에서 어떤 업무를 맡게 되든, 저는 "기록은 꼼꼼하게, 그리고 꾸준하게"라는 원칙을 잊지 않고 실천하려고 합니다.
🚀 결론
갑작스러운 권고사직으로 인해 예상치 못하게 직장을 떠나게 되었지만, 이 상황을 단순한 좌절로 남기고 싶지는 않았습니다. 흔들릴 수 있는 순간이었지만, 오히려 이 시점에서 제 자신을 돌아보고 앞으로의 방향을 다시 정비하는 기회가 필요하다는 생각이 들었습니다. 그래서 이렇게 회고를 통해 지난 시간들을 차분히 정리해보았습니다.
돌이켜보니, 그 동안 직장에서 경험한 일들, 배운 기술들, 협업 과정에서 느낀 점들, 부족함을 발견했던 순간들 등 모두가 저를 만들어준 소중한 경험이었습니다. 이번 회고는 그 자산을 다시 정리하고 제 안에 단단히 쌓아 올리는 과정이었고, 덕분에 다음 단계로 나아가기 위한 자신감과 추진력을 마련할 수 있었습니다.
현재 개발자 시장이 쉽지 않다는 이야기를 많이 듣지만, 저는 준비된 사람에게는 언제든 새로운 기회가 열릴 것이라 믿습니다. 단지 새로운 직장을 찾는 것이 아니라, 지금보다 더 성장하고, 더 의미있게 기여하며, 더 좋은 개발자로 발전할 수 있는 환경을 목표로 차근차근 준비할 예정입니다.
읖으로의 시간들은 저에게 또 하나의 도약이 될 것이라 생각합니다. 흔들림 없이 꾸준히 배우고, 경험을 쌓고, 준비하며 더 나은 내일을 만들어가겠습니다.
