2025년 상반기 회고

2025년이 벌써 반이나 지났다. 6개월이라는 짧은 시간동안 크고 작은 변화들이 있었다. 최근 회사에서 굵직한 일 하나가 끝났다. 보통 프로젝트가 끝나면 프로젝트 회고록을 작성하지만, 이번엔 특정 프로젝트에 참여한 것은 아니기 때문에 지난 6개월 간 나의 삶이 어땠는지 돌이켜보는 회고를 작성해볼까 한다.

스타트업으로 다시 시작

24년 회고에서 가볍게 언급했지만, VMWare에서 브로드컴으로 인수된 것이 나에게 마냥 좋은 소식은 아니었다. 회사 규모가 커지면서 금전적인 보상들은 좋아졌지만, 인수 이후에 일어나는 브로드컴의 악명 높은 정리 해고가 1년 내내 스트레스로 다가왔다. 아무래도 둘째가 조만간 태어날 예정이었기 때문에 걱정이 되었다. 결국 1년 만에 팀 전체가 해체되었다. 당시 나의 매니저님은 우리 팀은 수입, 비전 등이 확실하기 때문에 걱정 말라는 이야기를 하셨다. 만약 안 좋은 일이 발생하면 다같이 나가서 회사를 차리자는 이야기도 종종 하셨다.

당시에는 단순히 나를 안심시키려는 농담이라고 생각했지만, 그 말은 현실이 되었다. 나의 매니저님은 이제 나의 사장님이다. 상당히 놀랐고, 매니저님에겐 큰 고마움을 느꼈다. 요즘처럼 취업 시장이 얼어 붙은 상황에 홀벌이를 하는 내 입장에선 하고 있는 일을 그대로 이어서 할 수 있다는 사실에 안도감과 좋은 동료들과 함께 계속 일할 수 있다는 사실에도 감사함을 느꼈다.

스타트업은 조직이 작다. 나는 이 사실을 그만큼 나의 비중이 커졌다는 의미로 받아들였다. 브로드컴은 직원 수가 3만 7천명이라는데, 우리는 지금 28명이다. 단순 계산으로 1/37,000 에서 1/28 이라는 비중을 갖는다는 사실에 부담감을 느꼈다. 아니나 다를까 이번 상반기를 지내고 뒤돌아보니 내 한 몫을 하기 위해선 보완할 부분이 많다고 생각했다. 어떤 점에 이런 감정을 느끼게 되었는지 자세한 이야기는 다음 주제에서 이어가볼까 한다.

토요타 DIG 7기

이번 토요타 DIG 7기는 기존과 다른 방식으로 진행했다. 덕분에 여러 팀들을 돌아다니면서 많은 코드들을 볼 수 있었다. 프로젝트의 컨텍스트가 상당히 자주 바뀌는 편이라 피곤했지만, 좋은 점들도 있었다. 사용해보지 못했던 기술 스택을 경험해본다거나 다양한 비즈니스 도메인을 경험할 수 있었다.

각 팀들을 보면 서로 다른 서비스들을 만들고 있는데, 대부분 공통적인 문제들이 있었던 것 같다.

• 과도한 테스트 더블(test double)로 인해 부족한 리팩토링 내성과 거짓 양성
• JPA 기술 스택을 사용하는 팀의 경우 N+1 문제로 인한 퍼포먼스 이슈
• 매우 무겁고 복잡한 리액트 프로젝트
• E2E 테스트의 부재

과도하게 테스트 더블을 사용하면 리팩토링 내성에 취약하다. 좋은 테스트란 리팩토링 내성을 갖고 있어야 한다. 리팩토링 내성이란 효율성, 가독성, 성능을 위해 내부 구현을 리팩토링 했을 때 테스트가 실패하지 않아야 함을 의미한다. 헌데 테스트에 너무 과도한 스파이(spy) 객체들로 인해 코드의 사소한 변경도 테스트 실패를 야기했다. 구현 코드에는 전혀 문제가 없었으나 테스트가 너무 과민하게 반응하여 거짓 양성(false positive)을 발생시켰다. 작업이 크지 않다면 좋지 않은 테스트 코드 패턴도 함께 정리했다. 리팩토링 과정이 상당히 피곤했다.

JPA는 정말 편리하다. 도메인 모델링만으로 데이터베이스와 연결된다니 정말 마법 같지 않은가? 나는 JPA를 만났을 때 감동을 잊을 수 없다. JPA를 정말 많은 프로젝트에서 사용해보면서 경험이 쌓이다보니 과도한 연관 관계는 독이라는 사실을 알게 되었다. 단순한 조회임에도 불구하고, 지나치게 많은 쿼리가 실행되기 때문이다. 좋은 도메인 설계라고 생각한 부분이 퍼포먼스을 좀먹는다. 개발자는 도메인 설계와 퍼포먼스 사이의 트레이드 오프를 보고 적절한 설계를 할 줄 알아야 한다. 마지막에 도움을 준 팀도 너무 많은 @OneToOne 연관 관계와 도메인 객체 사이의 사이클 의존성(cycle depedency)으로 인해 조회가 상당히 느렸다. 13개의 데이터를 조회하기 위해 250번의 쿼리가 실행되는 것을 보았다. 간단한 조인 쿼리로 처리하기 어려울 정도로 복잡해져, 이를 해결하는 데 상당한 시간이 소요되었다.

리액트 프로젝트가 매우 무겁고 복잡했다. 도메인 특성 때문에 데이터의 속성(property)가 많은 것도 있었지만, 비효율적으로 상태를 관리하는 케이스나 사용자 인터뷰 결과만을 고려한 UI/UX 설계로 인해 프론트엔드 애플리케이션 구조가 무너지는 경우가 많았다. 우리 서비스만의 도메인 모델을 고려하지 않고 서드 파티(3rd-party) 애플리케이션에서 내려주는 응답을 그대로 사용하면서 코드를 복잡하게 만들거나 네트워크 호출의 비용이 얼마나 큰지 고려하지 않은채 API 호출을 반복적으로 수행하는 케이스도 있었다. 이런 문제들을 개선하고 싶었지만, 과도한 테스트 더블을 사용한 테스드 코드들과 맞물려 리팩토링이 굉장히 어려웠던 경험을 했다.

예전에 난 E2E 테스트가 개발자 선호도에 따른 옵션이라고 생각했었다. E2E 테스트는 비용이 크기 때문에 여러모로 피곤하기 때문이다. 최근 들어 의견이 조금 바뀌었는데, E2E 테스트가 가져다주는 이점은 E2E 테스트를 작성할 때 겪는 어려움이나 피곤함에 비해 크다. 특히 프론트엔드 테스트를 더 깨끗하게 유지할 수 있게 도와준다. 프론트엔드 단위 테스트를 작성할 때 여러번 API 호출이 필요한 경우엔 응답에 대한 과도한 스텁(stub)들로 인해 스텁 지옥(stub hell)을 만들어지는 경향이 있다. 프론트엔드 테스트 코드에서 테스트 더블을 복잡하게 조합해 컨텍스트를 준비하기보다는, E2E 테스트의 사용자 여정(user journey)에 해당 케이스를 포함시키는 편이 코드를 더 깔끔하게 유지할 수 있을 것 같다.

6개월 동안 여러 문제들을 해결하면서 많이 배웠다. 위 경험들은 모두 블로그에 글로 정리할 예정이다. 내 개인적인 생각으로 7기에서 우리가 준 임패트는 그리 크지 않았던 것 같다. 클라이언트들의 적절한 피드백이 없어서 정말로 큰 도움이 됐는지 알 수가 없다. 짧은 시간동안 돌아다니면서 팀에 줄 수 있는 영향은 당연히 크지 않았다고 생각한다.

이번엔 처음으로 같이 일해본 피봇(pivot)들이 많았다. 특히 유스케-상, 유카-상에게 도움을 많이 받았다. 일본어로 일하기 때문에 나에겐 아직까지 언어 장벽이 있다. 아무래도 일본어 실력이 부족한 나로썬 적극적인 의사 표현을 하는 것이 껄끄럽다. 작년에 학원을 다닌 이후로 1년 넘게 일본어로 일하다보니 말하거나 듣는 실력이 꽤 늘었지만, 아직까진 대화의 큰 흐름만 파악할 수 있을 뿐 구체적인 내용을 정확히 이해하기엔 무리가 있다. 이런 부분을 유스케-상과 유카-상이 많이 보완해줬다. 둘 모두 클라이언트들에게 린 XP(lean XP) 컨설턴트로써 클라이언트에게 좋은 조언들을 해줬다. 내가 만약 일본어를 잘했더라도 둘만큼 좋은 조언들이나 제안들을 할 수 있었을까? 둘을 보면서 내가 아직 린 XP 컨설턴트로써의 실력이 부족하다고 느꼈다. 여태껏 랩스에서 꽤 많은 프로젝트를 경험했다. 이 경험들을 바탕으로 다시 한번 린 스타티업(lean startup), 익스트림 프로그래밍(XP), 애자일에 관련된 책들을 읽어보면 컨설턴트로써 성장할 힌트를 얻을 수 있을까? 프로젝트 경험이 없을 때 읽었던 감상과 많은 프로젝트 경험 후 읽었을 때 감상이 많이 다를 것이라고 기대를 갖고 다시 읽어봐야겠다.

클라이언트들과 일할 때는 일본어로 대화한다. 동료들과 대화할 떄는 영어로 대화한다. 언어 컨텍스트가 갑자기 바뀌면 말하는 것이 정말 어렵다. 매번 회의 때마다 하고 싶은 이야기를 제대로 상대방에게 전달하지 못했을 떄 큰 좌절감과 자괴감을 느꼈다. 영어랑 일본어 모두 실력이 꽤 나아졌다고 느꼈지만, 이번 7기에서 아직도 많이 부족하다고 느꼈다. 언제까지고 언어 장벽이라는 방어막 뒤에 숨어 있을 순 없다고 생각했다. 25년 하반기에는 일본어나 영어 실력을 늘리는 것에 시간을 많이 투자해야겠다.

AI 시대

정말 지금은 AI 시대라는 것이 실감된다. 많은 동료들은 MCP 서버나 바이브 코딩에 토론하기 시작했다. 이를 어떻게 우리 프랙티스에 녹여낼 수 있을지 고민하고 있다. 고객들은 구현하기 어려운 코드를 AI에게 물어보기 시작했다. 정확히 이해하지 못한 코드이지만, 그대로 적용하고 있었다. CI/CD 파이프라인에서 MCP 서버를 연동하고 개발 자동화를 시도해보고 있다. 주변 지인들은 테스트 코드를 자신이 작성하고 구현 코드를 AI에게 맡기고 있다고 했다.

내 블로그 방문자 수만 봐도 실감할 수 있다. 22년부터 25년까지 기록을 살펴보면, ChatGPT가 등장한 22년 11월까진 방문자 수가 계속 상승한다. 이후 보합을 1년정도 유지하다 23년 말부터 꾸준히 하락세다. 그동안 내가 블로그에 글을 작성하는 것을 멈추거나 글의 품질이 낮아진 것도 아닌데, 방문자 수의 감소는 블로그를 유지하는 동기를 잃게 만들었다.

나는 AI를 적극 활용하지 못한다. 블로그 글을 다듬거나 공부할 때, 혹은 개발 중 모르는 것들을 물어보는 정도로만 사용하고 있다. 앞으로 AI가 적극적으로 개발자의 업무를 대체하고 있는 추세는 더 강해질 것으로 보인다. 이 흐름을 거스를 수는 없다고 생각한다. AI를 많이 사용해보지 않고 이 생태계를 모른다면 조만간 뒤쳐질 것이라는 FOMO(Fear Of Missing Out)가 올 것 같다. 아직 실제 업무에서 어떻게 활용할지 아이디어는 없지만, 기술적인 부분들을 잘 이해할 필요는 있을 것 같다는 생각에 최근엔 LLM 관련 강의들을 보고 책들을 읽고 있다.

개인 활동

스프링 시큐리티에 관련된 원고 집필은 24년 말에 모두 마무리했다. 원고가 마무리 됐지만, 바로 출판 과정으로 이어지진 않았다. 알 수 없는 출판사의 사정으로 인해 7월이 다 되도록 출판 시작에 관련된 소식은 듣지 못하고 있다. 스프링 시큐리티는 아무래도 인기가 없는 주제라 출판의 우선 순위가 뒤로 밀리고 있다는 느낌을 지울 수가 없다. 프레임워크 버전은 계속 올라가고 있기 때문에 빠르게 출판하는 것이 좋을 것 같지만, 나만 초조한 것 같다.

책 내용을 기반으로 인프런에 강의를 올릴려고 준비 중이다. 우연히 인프런 지식 공유 챌린지에 참여하게 되서 강의 자료를 만들고 촬영 시작은 했지만, 강의를 몇 개 촬영해보니 정말 쉽지 않은 작업이라는 것을 느꼈다. 비디오에서 흘러나오는 내 목소리는 정말 어색하다. 일단 시작은 했으니 끝을 내보자.

좋은 책을 읽는 것은 항상 많은 도움이 된다. 최근 추천 받은 레버리지(롭 무어)라는 책을 읽고 있다. 책을 읽다 보니 내가 소중히 여기는 삶의 가치와 방향을 지키기 위한 비전이 다소 모호하다는 생각이 들었다. 조용한 새벽에 나에게 소중한 것들과 내가 가고 싶은 삶의 방향이 무엇일지 브레인스토밍하며 나의 내면을 들여다보는 시간을 가졌다. 그리고 나의 시간을 이것들을 위해 투자하고 있는지 돌이켜봤다. 중구난방으로 벌린 일들이 많지만, 방향은 틀리지 않은 것 같다. 다만, 내가 잘하고 가장 크고 지속적인 가치를 창조하는데 시간을 투자하고 있다는 생각은 들지 않았다. 극적인 효율을 위해 내 시간을 잘 활용할 수 있는 방법들에 대해 고민해봐야겠다.

남은 25년 길을 잃지 말고 성장하길