4년차 백엔드 개발자 회고
글썼던 개발자
2022년, NHN에 신입 개발자로 입사한지도 벌써 3년이란 시간이 지났다. 2019년 팬데믹을 기점으로 불어온 개발자 열풍 탓에 혼자서 가졌던 개발자에 대한 환상과는 다르게, 어찌보면 현업 개발자로서의 3년은 참 무난하고 평범하게 지나간 것 같다. (어쩌면 대부분이 그렇겠지만?)
여느 직장인처럼 월요일이 시작되면 피곤한 몸을 일으켜 출근하고, 금요일이 끝나면 피곤한 몸을 이끌고 퇴근하는 삶의 반복. 하지만 다행히 그 틈에서도 무언가를 배울 기회는 있었던건지, 연차가 쌓일수록 생각과 가치관이 바뀌는 나의 모습과, 과거의 나를 지금의 내가 반성하는 모습을 통해 '무언가 바뀌긴 했겠구나'하는 생각이 든다.
글을 작성하고 있는 '글쓰는 개발자' 블로그도 내 과거의 생각들이 고스란히 담긴 곳이다. 취업 후 조금씩 잊혀졌던 이 블로그가 최근에 다시금 생각나, 그때 쓴 글을 살펴보니 "무슨 이런 생각을 했을까?"하며 웃기도 했지만, 분명한 것은 그렇게라도 기록을 남겨두지 않았다면 지금의 회고를 남길 생각도 못했을테니 흑역사 같은 과거라도 남기면 좋겠다는 생각이 들었다.
그러한 관계로, 2025년의 스냅샷도 몇 장 정도는 이 곳에 남겨두어야겠다. 언젠가의 미래에 다시 또 이 글을 보며 "무슨 이런 생각을 했을까?"하며 웃을 수 있길 바라면서 말이다.
우매함의 봉우리, 추락
초심자의 오만함을 지적하기 위해 흔히 사용하는 더닝 크루거 효과. (연구 결과가 오남용 된다고 하지만, 아래처럼 재밌어서 계속 퍼나른다)
개발자들의 생애 주기에는 꼭 저 우매함의 봉우리에 오르는 때가 있는 것 같다. 보통 무언갈 많이 배웠다고 자평하는 시점에 그렇게 되는 것 같은데, 그런 사람들의 특징은 "나는 아니야"라고 생각한다는 것이다. 물론 이런 말을 하는건 당연히 내가 그랬기 때문이고, 어쩌면 지금도 "나는 아니야"라고 봉우리에서 바보같이 소리치며 돌아오는 메아리를 듣고 있는지도 모르겠다.
아무튼 지금 생각해보면 지난 3년의 시간은, 저 봉우리에 서있다가 거의 떠밀리다시피 추락해 와장창 깨지면서 겸손함이란걸 좀 아는 시간이 되었던 것 같다.
어느 정도 프로그래밍이 손에 익고 나서부터는, 단순한 프로그래밍 언어 구사보다 고차원의 이론에 손이 가기 마련이다. 나는 이런 단계에서 소프트웨어 공학이 근간이 되는 이론들, 예를 들어 객체 지향 설계 원칙이나 더 나아가 요즘도 많이들 얘기하는 DDD, 클린/헥사고날 아키텍쳐 같은 쪽에 관심을 가졌던 부류에 속한다.
어느정도 경험이 있는 사람이라면 내가 어떤 실수를 범했을지 이미 예상할 대목일 것이다. 나는 처음 이런 이론들을 접했을 때 마치 구원받은 신자라도 된 것 마냥 거대한 해답을 찾은듯한 느낌이 들었다. 이것만 있으면 완벽한 소프트웨어를 만들 수 있을 것 같은 허상에 빠졌고, 그것은 시기별로 주제를 바꿔가며 "Spring만 알면 완벽할거야" "DDD만 적용하면 완벽할거야" "헥사고날 아키텍처만 적용하면..." 과 같은 소프트웨어 이상론을 추구하는 방향으로 흘러갔다. 심지어 이런 것을 알아주지 못하는 사람들을 이상하다고 생각하기도 했다.
이런 잘못된 믿음을 적용하려 하니, 때론 누군가 함께하는 프로젝트의 시간을 지연시키기도 하고, 불완전한 지식에 근거해 이상한 구조를 만들어내기도 하는 등 여러 형태의 망작(?)을 양산해냈다.
이런 맹신을 사이드 프로젝트처럼 상대적으로 중요도가 높지 않은 작업들에 적용하긴 쉽지만, 철저히 팀원들의 검증이 따라붙는 실서비스에서는 당연히 적용할 수도 없었고, 혹여나 그런 요소 때문에 혼자 고민하느라 일정이 지체되면 피드백을 통해 두들겨 맞으면서 현실적인 부분을 제일 먼저 고려하는 습관이 생기게 되었다.
종합해보면 직장에서는 현실 가능성과 실력 부족으로, 또 대외 활동과 사이드 프로젝트에서는 흑역사에 대한 반성으로 겸손이 주입된 케이스이다.
이렇게 말하면 마치 이론을 말하는 개발자는 잘못된 것처럼 느낄 것 같은데, 이론에는 죄가 없다. 단지 그것을 맹신하고 추앙하는 태도가 문제가 될 뿐. 무엇이든 현실과 이론은 적절한 균형점을 찾아 적용해야 할 요소인 것이지, 어느 하나를 이분법적으로 선택할 문제는 아니라고 생각한다. 나는 이론에 쏠린 사람이었던거고.
아무튼 지난 겸손 주입 시기를 통해, 더 이상 내가 획기적인 이상을 알고 있고 적용할 수 있다는 오만한 생각은 집어치우고 현실적인 요소를 더 많이 고려하려 한다.
커뮤니케이션
겸손이 주입되는 과정과 병행하여 또 다른 배운점이 많은데, 대표적으로 커뮤니케이션이 있다. 수많은 Job Description에서 커뮤니케이션을 강조하고, 신입 채용 시장에서도 많이 봤던 문구였는데 그 당시에는 "개발자가 개발만 잘하면 되지 무슨 커뮤니케이션?" 식으로 생각했던 것 같다.
입사하고 얼마 지나지 않아서 이게 왜 중요한지 알게 되었다. 개발자 혼자서는 큰 규모의 서비스를 만들수도 없을 뿐더러, 운영 업무까지 더해지니 이건 절대로 혼자 할 수 없는 일이었다.
업무들은 자연스럽게 여러 부서를 나누어 분배했으며, 우리 조직은 큰 서비스를 개발하고 운영하는 일부 부서에 불과했다. 당연히 그 조직에 속한 나라는 개발자는 (슬프지만) 그보다도 더 작은 모듈같은 존재였다. 스프링으로 치면 한... DTO쯤 되려나?
그러니 각 부서 사람들의 R&R도 세부적으로 나뉘었고, 이걸 통합하는 공통의 언어는 존재하지 않았다. 그래서 운영 부서와 소통할 때는 운영의 언어로, 개발 부서와 소통할 때는 개발의 언어로, 또 기획 부서와 소통할 때는 기획의 언어로 소통해야 했다. 이러한 능력은 그냥 생기지 않고, 어떻게 해야 상대방이 더 잘 이해할까?라는 상대방 중심적인 고민을 해보아야 향상되는 능력인 것 같다.
처음엔 이게 참 힘이 들었다. 당최 저 사람이 어디까지 뭘 알고 있는지도 모르겠고, 애초에 나도 내가 뭘 모르는지 모르는 상태에서 뭘 잘 설명할 수 있으랴. 그래도 지금은 도메인 지식도 많이 쌓이고, R&R에 대한 이해도 높아지면서 이런 부분들은 점차 해소되고 있는 것 같다. 그렇지만 아직도 다른 사람들을 보면서 내가 부족하구나 많이 느끼고, 퇴사하기(?) 전까지는 부단히 상대방 입장에서 생각하도록 노력하는 것이 최선의 방법일 듯 하다.
문제 해결력
커뮤니케이션 다음 따라오는건 문제 해결력이다. 이 단어도 JD에서 많이 보았고, 똑같이 "문제 해결력? 피상적이군"하고 지나갔던 것 같다. 커뮤니케이션과 같은 클리셰로, 이것도 입사하고 나니 중요성을 느낀 부분이 많다.
문제에 따라 문제를 해결할 방법은 수십 개도 있을 수 있겠지만, 최선의 방법은 한 개 밖에 없을 것이다. 이 문장은 예전부터 알고 있었고 동의하는 내용이었다. 문제는, 내가 스스로 최선의 방법을 적용하고 있을거라는 착각에 있었다. 입사를 하고 나서 문제를 최선으로 해결했는지, 또 정말 문제가 해결된 것이 맞는지를 엄밀하게 검증하는 과정을 거치면서, "내가 생각보다 휴리스틱한 방식으로 일하고 있었구나"라는 점을 느끼게 되었다.
어떤 일에 대한 문제 해결 전략을 제시할 때는, 항상 다른 개발자가 '이 문제가 정말 해결된 것이 맞는지?' '정말 이렇게 밖에 해결할 수 없는 문제인지?'를 검증하는 과정이 수반되었다. 그것은 코드 리뷰를 통해서일 수도 있고, 기능 개발 전 스펙 리뷰를 통해서일 수도 있다. 문제는 여기서 내가 논리를 잘 세우고 설명을 해야 전략에 대한 설득이 될텐데, 논리가 빈약하니 설득 과정에서 애를 먹었던 경험이 참 많다.
왜냐하면 알고보니 나는 그전에는 문제 해결을 잘 한것인지 검증할 줄 몰랐고, 일단 잘 돌아가는 것처럼 보이고 해결되는 것처럼 보이니 대충 마무리하는 방식으로 일을 해왔기 때문이다. 이런 부분들도 지속적으로 업무를 해결하는 과정에서 많이 나아진 모습을 보이는 것 같다.
문제가 일어났을 때는, 일어난 문제에 대한 '문제 정의'가 필요하고, 그 문제가 해결된 것이 무엇인지 정의하는 '문제 해결 상태 정의', 그리고 그 상태에 최선의 방식으로 도달할 '문제 해결 전략'을 엄밀하게 세우는 습관이 중요하다는 것을 배우게 되었다.
기본의 중요성
앞서 말한 부분들은 사실 3년차까지 많이 느꼈던 부분인데, 4년차에 접어든 요즘은 '기본의 중요성'이라는 재미 없는 단어를 다시금 떠올려보고 있다. 여기서 말하는 기본은 개발자로서의 기본만을 의미하는 것이 아니다. 꾸준함, 꼼꼼함, 약속, 열정, 노력과 같은 개발자가 아닌 직장인, 직장인이 아닌 인간으로서의 기본에 좀 더 가까운 의미이다.
개발자 채용 시장을 보면 화려한 단어들이 많이 보인다. MSA(Micro Service Architecture), EDA(Event Driven Architecture), DDD(Domain Driven Design), 대용량 트래픽 등 기술적 도전이 많아 보이고 왠지 해두면 개발자 채용 시장에서도 나를 잘 팔 수 있을 것 같은 단어들이다. 그래서 흔한 개발자 교육 서비스에서도 이런 단어들이 더 많이 쓰고 있는 것 같다.
물론 이런 것들은 당연히 개발자로서 알아두면 좋은 것이고, 일정 규모 이상으로 서비스가 성장하면서 문제의 해결책이 되어줄 수도 있다. 앞서 말했듯 이론에는 죄가 없는거니까. 그런데 이러한 기술적 도전 요소들이 수단이 아니라 목적이 되는 경우를 종종 보게 된다. 물론, 그것을 목적이라고 대놓고 말하는 사람은 당연히 없다. 보통 필요하지 않은데 필요하다고 자신과 팀을 속이는 상황으로 나타난다.
신기술을 잘 모르고 도입했다가 거기서 일어나는 문제를 해결할 방법이 없어 예전 방식으로 롤백하는 일들을 본 적이 있는데, 이런 상황들이 위 명제의 근거가 되는 사례이다. 개인적인 생각으로는... 필요 이상으로 과열된 느낌이 있는듯?
그럼에도 이런 도전들을 부정적으로 생각하지는 않는다. 실패와 성공을 반복하면서 성장하는 것이 사람이니까. 다만, 나는 좀 더 문제가 되는 것들은 이런 화려한 언어들 뒤에 우리가 개발자로서 기본적으로 지켜야 할 소양들이 가려지고 있는 부분이라고 생각한다.
개발자의 삶은 생각보다 그렇게 화려한 기술적 요소들을 이용해 우아한 문제 해결을 해야할 일만 생기지 않는다. 때로는 레거시를 운영하며 지저분한 코드를 만지기도 하고, 복잡한 요구 사항을 머리 아프게 문서화하는 일도 있으며, 피곤한 새벽 출근을 하며 반복적인 배포 업무를 해야하는 일도 있다. 그보다 더 사사로운 일들을 하게 될 수도 있다.
이런 업무들은 단조로운 일이라 하기 싫고 심지어 중요하지 않다고 느낄 수도 있지만, 우리가 운영하는 서비스를 운영하고 서비스가 성장하는데 필수적인 요소들이다. 이런 것들은 위의 화려한 기술들만 가지고는 할 수 없는 일이다. 배포에서 빠진 부분이 없는지 한번 더 확인하는 꼼꼼함, 주어진 일감을 정해진 일정 내에 어떻게든 해내려는 책임감, 맞닥뜨린 문제를 몇 시간이고 투입해서 해결하는 끈기. 나는 이런 것들이 개발자의 기본이라고 생각하고, 요즘따라 그런 것들을 더 잘 챙겨야 하겠다는 생각을 한다.
마무리
호기롭게 4년차 회고를 시작했다가, 중간에 너무 길어져서 쓰지 말까? 고민하다가 결국 어찌저찌 내 생각들을 휘갈겨 담았다. 이 중에는 내가 느낀 점이라고 이야기 했지만 여전히 남이 보기엔 내가 실천하지 않는 부분들이 있을거고, 그런건 앞으로의 내가 더 채워야 할 부분일 것 같다.
미래의 내가 이 글을 보고 "재밌네" 하고 웃을 수 있으면 좋겠다. 이 글 외에도 몇가지 개발자로서의 경험을 풀고싶은 것들이 있는데, 시간이 날 때 또 글을 써보아야겠다.