2025 회고: 풀스택과 AI 사이드킥을 지나 다시 JVM으로

돌고 돌아 다시 자바 개발자로 돌아간 나

 

25년 한해동안 저는 사이드 프로젝트로 Python을 기반으로 챗봇을 만드는 것도 경험해보고 Typescript로 풀스택으로 실무 개발을 해보는 경험까지 다양하게 경험을 해보았습니다. AI와 함께라면 해결하지 못하는 문제는 없을 거라고 생각했었고 실제로 막힐 때마다 AI의 도움을 받아 쉽게 해결했기 때문에 이제 개발자는 시스템 디자인 역량이 더더욱 중요해질 거라 생각했습니다. 하지만 이는 저의 착오였습니다.

 

작동하는 코드와 어울리는 코드의 차이

자바의 빌더 패턴과 타입스크립트에서의 인터페이스 활용

자바에서 전달해야되는 파라미터가 많은 경우에는 빌더 패턴을 자주 활용합니다. 이는 가독성을 높일 뿐만 아니라 코드를 작성할 때의 실수또한 줄여주는 좋은 예시죠. 하지만 타입스크립트에서는 빌더패턴보다는 인터페이스를 활용하여 파라미터를 전달하는 구조로 많이 활용합니다.

 

여기서 서로 다른 패턴을 사용한다고 동작하는데에는 큰 문제를 주지 않을 것입니다. 하지만 이를 유지보수하는 개발자에게는 이전과 다른 패턴으로 인해 코드를 다소 이해하는데 시간이 걸릴 것입니다. AI는 깃헙에 있는 수많은 코드를 익혔지만 정확히 그 코드가 왜 작성되었는지 그 상황에서 작성되어야만 했는지는 알 수 없습니다.

 

AI는 개발한 코드에 대해서 책임을 지지 않습니다. 결국 작성한 코드의 책임은 개발자에 있기에 AI가 작성한 코드가 잘 동작하는지뿐만 아니라 의도한 맥락에 맞춰 잘 작성했는지와 과도한 오버엔지니어링이 되지 않았는지 검토를 해야합니다. 아니러니하게도 우리는 언어의 생태계를 이전보다 더욱 더 깊이를 이해해야지만 AI를 잘 쓸 수 있는 상황이 온 것입니다.

 

코드 바깥의 컨텍스트와 보이지 않는 요구사항

빙산의 일각뿐인 명시적 요구사항

 

클로드 코드, 커서 등 AI 도구가 많이 발전하여 요구사황과 관련된 코드를 직접 찾아서 활용하는 수준까지 왔지만 아직은 사람만큼의 컨텍스트를 이해하지 못합니다.  예를들어 사람은 보안 수준이 낮은 곳에서는 검증을 생략하거나, 가독성을 위해 성능을 양보하기도 합니다. 하지만 AI는 이런 유연한 결정을 '오류'로 인식해 불필요한 지적을 쏟아냅니다. AI에게 이 모든 상황을 학습시키는 공수보다 사람의 검수가 훨씬 경제적이기에, 결국 최종 리뷰는 다시 사람의 몫이 됩니다.

 

책임의 주체는 어디에?

만약 AI로 생성한 코드가 프로덕션에 문제가 생겼다면 사람이 결국 대응을 해야합니다. 그렇기 때문에 우리는 AI가 작성한 코드의 내용 조차 머릿속에 저장을 해둬야 하는데 남이 작성한 코드는 내가 직접 작성한 코드보다는 깊게 남지 않기 때문에 매순간 디버깅하는데에 어려움을 겪습니다. 

 

이뿐만 아니라 AI의 결과물을 검토하기 위해서는 아이러니하게도 우리는 AI보다 더 높은 수준의 언어와 아키텍처의 이해도를 가지고 있어야할 것입니다. 그래야지만 AI가 작성한 코드가 성능적 이슈를 일으키지 않는지와 엣지 케이스에도 정상적으로 동작할 수 있을지 보장할 수 있기 때문입니다.

 

자바 개발자로 다시 돌아가기

 

사이드 프로젝트를 오가며 참 많은 언어를 거쳐왔습니다. 덕분에 백엔드는 물론 프론트엔드, AI, DevOps까지 넓은 영역을 경험할 수 있었죠.

 

하지만 지금까지의 커리어를 되돌아보며 "나는 이 중 단 하나의 영역이라도 AI보다 더 '깊게' 이해하고 있는가?"라는 질문을 스스로 던지게 되었습니다. 안타깝게도 저는 이 질문에 "그렇다"라고 자신 있게 답하기엔 아직 부족함이 많다는 것을 깨달았습니다.

 

언젠가부터 제가 AI를 도구로 주도하는 것이 아니라, AI가 내놓는 답을 맹목적으로 따라가고 있다는 위기감이 들었고 AI가 수많은 코드를 양산해내는 지금, 저만의 뚜렷한 '깊이 있는 무기'가 없다면 살아남기 어렵다고 생각했습니다. 그래서 저는 다시 처음으로 돌아가, 자바와 백엔드 기술을 다시 딥다이브 해보는 시간을 가져가보려고 합니다.

 

왜 자바인가?

첫째, 안정성과 견고함 때문입니다. 루비, 타입스크립트, 파이썬 등 다양한 언어로 백엔드를 구축해 보았지만, JVM만큼 컴퓨터 리소스를 효율적으로 관리하고 언어 레벨에서 휴먼 에러를 방지해 주는 안정적인 환경을 찾기 어려웠습니다.

 

둘째, 개방된 생태계입니다. C# 또한 훌륭한 언어지만, 특정 벤더(MS) 중심의 생태계보다는 오픈소스 진영이 주도하여 전 세계 수많은 엔지니어링의 정수가 담긴 자바 생태계가 제 성장에 더 적합하다고 생각했습니다.

 

마지막으로, 제 학습의 뿌리이기 때문입니다. OOP, DDD, MSA 등 제가 추구하는 아키텍처 방법론들은 대부분 자바를 기반으로 정립되었습니다. 방법론과 구현하는 기술이 일치할 때 오는 학습의 효율성, 그리고 제게 가장 익숙한 도구라는 점이 자바를 다시 선택한 결정적 이유입니다.

 

앞으로의 계획

얼어붙은 현재의 IT 시장을 체감하며, 저 또한 생존과 성장에 대해 더 유연한 태도를 가지게 되었습니다. 앞으로는 정규직뿐만 아니라 프리랜서 활동까지 열어두고, 회사를 선택할 때도 막연한 커리어 성장보다는 '회사의 비즈니스 지속 가능성(재무적 건전성)'과 '내가 실질적으로 기여할 수 있는 비즈니스 가치'를 최우선으로 고민하려 합니다.

 

또한, 이번 딥다이브 과정은 혼자만의 학습으로 끝내지 않고 오픈소스 생태계 기여로 연결할 계획입니다. 과거에는 영어라는 언어의 장벽이라는 핑계로 미루곤 했지만, 이제는 AI라는 훌륭한 도구가 있으니 제미나이, 클로드, 지피티 등의 힘을 빌려 언어의 장벽을 넘고, 한국이라는 더 나아가 다양한 국가의 엔지니어들과 소통해 보려 합니다.