AI가 몇 년 만에 바꿔 놓은 개발자의 성장 방식에 대한 생각 (상)

직접 구현하며 배우던 시간

개발자로서 성장하는 방법을 크게 의심하지 않던 때가 있었다. 좋은 코드를 읽고, 설계를 공부하고, 배운 내용을 실제 프로젝트에 적용하면 조금씩 더 나은 개발자가 될 수 있다고 생각했다. 당장 이해되지 않는 개념도 코드를 작성하다 보면 필요해지는 순간이 있었고, 그때 다시 공부하면 이전보다 깊이 이해할 수 있었다. 성장의 속도는 느릴지 몰라도 방향만큼은 분명해 보였다.

내가 공부하던 것들은 대부분 유지보수하기 좋은 소프트웨어를 만드는 일과 연결되어 있었다. 요구사항이 바뀌었을 때 어디까지 수정해야 하는지, 새로운 기능을 추가하면서 기존 기능에 영향을 주지 않으려면 어떻게 설계해야 하는지, 함께 일하는 사람이 내 코드를 쉽게 이해하려면 무엇을 고려해야 하는지 같은 문제들이었다. 새로운 기술을 배우는 이유도 결국 비슷했다. 지금보다 유연하고 확장하기 좋은 소프트웨어를 만들고 싶었다.

퇴근 후나 주말에도 그 고민은 이어졌다. 인프런과 패스트캠퍼스에서 강의를 구매하고, 사이드 프로젝트를 만들어 배운 내용을 적용했다. 강의를 들을 때는 이해한 것 같다가도 직접 구현하면 막히는 부분이 생겼다. 그러면 다시 자료를 찾고, 코드를 고치고, 왜 처음 생각한 방식으로는 잘되지 않는지 돌아봤다. 시간이 걸리는 과정이었지만, 그렇게 고민한 내용은 다음 작업에서 조금 더 익숙하게 다룰 수 있었다.

최근 AI Agent가 발전하는 모습을 보면서 자주 떠올리는 것은 그때의 학습 과정이다. 개발하는 방식이 빠르게 달라지고 있고, 내가 직접 맡아야 하는 일의 범위도 바뀌고 있다. 예전에는 직접 구현하며 자연스럽게 마주쳤던 고민을 이제는 건너뛸 수 있게 됐다. 그 변화를 경험하면서, 내가 익숙하게 생각해 왔던 성장 방식도 다시 돌아보게 됐다.

신입 개발자가 해결하기 어려운 문제를 직면하다

처음부터 이런 고민을 했던 것은 아니다. GPT-3를 접했을 때는 그저 신기했다. 질문을 이해하고 답변을 만들어 내는 모습이 흥미로웠지만, 실제 업무에서 막힌 문제를 함께 풀어 갈 수 있을 것이라고 기대하지는 않았다. AI를 바라보는 내 생각이 달라진 것은 GPT-4를 사용하면서부터였고, 그 계기에는 지금도 선명하게 기억하는 일이 있다.

입사한 지 1년 정도 지나고, 고객사에 납품된 특정 버전의 소스 코드가 유실된 사실을 알게 됐다. 처음에는 어딘가에 남아 있을 것이라고 생각했다. 정확한 위치를 찾지 못했을 뿐이라고 믿으며 GitLab을 계속 뒤졌다. 그러나 저장소와 이전 기록을 아무리 살펴봐도 납품된 버전과 일치하는 소스는 나오지 않았다.

해당 고객사는 일반 버전에 별도의 기능을 많이 추가한 대형 고객사였다. 이전 버전의 소스를 찾더라도 그대로 가져다 쓸 수 있는 상황이 아니었다. 더구나 당시에는 고객사에서 발생한 보안 문제를 조치하기 위한 추가 개발이 필요했다. 소스가 없다는 이유로 작업을 미룰 수도 없었고, 해결하지 못하면 수년간 이어지는 유지보수 계약에도 영향을 줄 수 있었다. 어디서부터 풀어야 할지조차 분명하지 않은 문제를 앞에 두고, 입사한 지 1년 정도 된 나는 부담이 상당히 컸다.

며칠 동안 인터넷을 찾아보고 동료와 선배에게도 조언을 구했다. 가능한 방법을 하나씩 검토했지만 뚜렷한 해결 방향은 보이지 않았다. 야근이 이어지던 어느 날, GPT-4의 성능이 좋다는 유튜브 영상을 봤던 기억이 났다. 무엇이라도 더 시도해 봐야겠다는 생각으로 GPT를 켜고, 내가 처한 상황을 설명하기 시작했다.

한 번의 질문으로 답을 찾을 수는 없었다. 현재 상황을 설명하면 방법이 제시됐고, 그 방법을 적용하기 어려운 이유를 설명하면 다른 선택지가 나왔다. 나는 답변을 읽으면서 실제 시스템에 적용했을 때 어떤 문제가 생길지 생각했고, 예상되는 문제를 다시 질문했다. 하나의 가능성을 따라가다가 막히면 앞선 지점으로 돌아와 다른 가능성을 살펴봤다. 그렇게 대화가 여러 갈래로 뻗어 나가면서, 막연했던 문제에 조금씩 접근할 수 있게 됐다.

그 과정에서 찾은 방향은 리플렉션을 활용하는 것이었다. 실행 중인 프로그램에서 클래스 정보를 찾아 활용하는 기능을 통해 기존 코드의 Redis 연결 클래스를 가져오고, 그 연결을 사용해 필요한 데이터에 접근하는 방식이었다. 당시에는 서버 개발을 담당하던 동료와 수정 범위를 최대한 작게 유지하기로 협의한 상태였기 때문에, 기존 구조를 활용할 수 있는지가 중요했다.

해결 방향을 찾은 뒤에도 작업은 쉽게 끝나지 않았다. 해당 버전의 구조가 내가 알고 있던 방식과 달랐고, 실제로 적용하려고 하면 예상하지 못한 문제가 생겼다. 그때마다 코드와 답변을 대조하고, 내가 이해한 내용이 맞는지 확인했다. 다음 단계에서 막힐 수 있는 부분을 생각하며 질문을 이어 갔고, 가능한 경우의 수를 정리하면서 작업 흐름을 하나씩 그려 나갔다. 결국 일주일 넘게 이어진 야근 끝에 문제를 해결할 수 있었다.

답변을 이해해야 다음 단계로 갈 수 있었다

그때는 지금처럼 Agent가 프로젝트를 살펴보고 직접 코드를 수정하는 방식이 널리 쓰이던 시기가 아니었다. 답변을 받더라도 그 의미를 이해하고, 우리 시스템에 적용할 수 있는지 판단하고, 실제 구현으로 옮기는 과정은 직접 해야 했다. 필요한 개념을 공부하다가 다시 코드로 돌아오기를 반복했고, 잘못 이해한 부분은 작업 중에 드러났다. 문제를 해결하는 동안 내가 무엇을 모르고 있었는지도 조금씩 알게 됐다.

당시에는 집에 돌아가서도 그 문제를 놓지 못했다. 잠들기 전까지 해결 방법을 생각했고, 다음 날에는 무엇을 확인해 봐야 할지 머릿속으로 정리했다. 분명 고생스러운 시간이었지만, 지금 돌아보면 그 과정에서 많이 성장했다는 느낌이 남아 있다. 공부한 내용을 실제 제약 속에서 적용하고, 실패한 이유를 살펴보고, 다른 방법을 찾는 경험을 짧은 기간에 반복했기 때문일 것이다.

그 시간의 끝에서 가장 선명하게 남은 장면은 함께 고생한 동료 엔지니어와 담배 한 대를 피우러 나갔던 순간이다. 계속 짓누르던 부담이 풀리고, 드디어 해결했다는 안도감이 들었다. 그동안 얼마나 마음을 졸였는지 문제를 해결하고 나서야 실감할 수 있었다. 지금도 개발하면서 가장 행복했던 기억 중 하나로 남아 있다.

이 일을 겪은 뒤 AI는 내 공부와 업무에 자연스럽게 들어왔다. 혼자 자료를 찾다가 막히면 질문했고, 답변을 이해하기 위해 다시 공부했다. 질문이 구체적일수록 답변을 활용하기 쉬웠고, 내 지식이 부족한 부분에서는 답변을 받아도 다음 단계로 나아가기 어려웠다. 당시에는 AI와 함께 문제를 해결하는 과정이 곧 배우는 과정으로 느껴졌다.

Cursor를 위한 팀 규칙도 개발 역량이었다

그러다 Cursor가 널리 쓰이기 시작하면서 회사 밖에서 만나는 개발자들의 관심도 조금씩 달라졌다. 지인이나 다른 회사의 개발자들과 이야기하다 보면 새로운 기술을 공부하는 것보다 프로젝트의 팀 규칙을 정리하는 데 더 많은 시간을 쓰고 있다는 말을 들었다. AI가 프로젝트의 구조와 개발 방식을 이해하도록 기준을 마련하는 일이 중요해진 것이다.

주변의 이야기를 들으며 나 역시 Cursor에 팀 규칙과 프로젝트의 맥락을 반영해, 팀이 함께 활용하는 방법을 배우고 적용해 보고 싶어졌다. 하지만 당시 다니던 회사에서는 다들 AI로 개발 방식이 달라지는 일에 별다른 관심이 없었다. 회사 밖에서는 이미 새로운 방식으로 일하고 있다는 이야기가 들려오는데, 나는 익숙한 개발 방식에 머물러 있다는 느낌이 들었다. 이런 환경에 계속 있다 보면 변화를 충분히 경험하지 못한 채 점점 도태되는 것은 아닌지 불안했다. 그래서 AI를 실제 개발 과정에 적극적으로 활용하는 팀에서 Cursor의 팀 세팅과 활용 방법을 배우고 싶었고, 그 마음이 이직을 진지하게 고민하는 계기가 됐다.

그렇게 운 좋게 AI 소프트웨어 개발사로 옮기게 됐고, 그곳에서는 내가 배우고 싶었던 방식이 실제 업무에 자리 잡아 있었다. 새 회사는 Cursor를 적극적으로 사용하고 있었고, 팀이 도구를 활용하는 기준도 구체적이었다. Cursor의 설정 파일에 팀 규칙을 반영하고, 반복 작업이나 코드 스타일이 그 기준에서 벗어나지 않도록 관리하고 있었다. 원하는 결과가 나오지 않으면 함께 원인을 살펴보고 규칙을 수정했다. 설정은 한 번 작성하고 끝나는 문서가 아니라, 실제 작업을 통해 계속 다듬어 가는 기준이었다.

이야기로만 듣던 방식이 실제로 자리 잡은 모습을 보니 그 역할을 더 구체적으로 이해할 수 있었다. 팀이 매번 설명해야 했던 내용을 Agent가 참고할 수 있도록 정리하자 반복되는 작업이 수월해졌고, 결과물도 팀의 개발 방식에 가까워졌다. 그때부터는 규칙과 컨텍스트, 즉 작업에 필요한 배경 정보를 잘 정리하는 일 역시 개발 역량의 일부라는 생각이 들었다. 팀의 개발 기준을 정리하고 실제 작업에 맞춰 다듬는 과정에도 배울 것이 있었다.

빠른 구현 뒤에 남은 질문들

그렇게 새로운 방식에 익숙해지고 있던 중, 다시 마음이 복잡해지는 일이 두 번 있었다.

JWT의 내용을 읽는 것과 검증하는 것

한 번은 옆자리에서 선배 두 명이 JWT에 관해 대화하던 때였다. 7년 차 선배가 5년 차 선배에게 시크릿 키가 없는데 토큰의 payload 값을 어떻게 볼 수 있는지 물었다. 그런데 질문을 받은 선배도 바로 답하지 못했고, 두 사람 모두 그 이유를 명확하게 설명하지 못하고 있었다.

JWT 개념 설명

• Payload: 토큰 안에 담긴 정보를 뜻한다. JWT에서는 이 정보를 JSON 형태로 표현한다.
• 내용 읽기: 일반적으로 사용하는 서명된 JWT에서는 payload가 Base64url로 인코딩되어 있을 뿐 암호화되어 있지 않다. 따라서 서명용 키 없이도 디코딩해 내용을 읽을 수 있다. JWS 표준(RFC 7515)
• 서명 검증: 검증에 필요한 키로 서명을 확인해 토큰의 내용이 서명 이후 변조되지 않았는지 검사하는 과정이다. 내용을 읽을 수 있다는 것만으로 서명이 검증된 것은 아니다.
• 암호화된 JWT(JWE): 내용을 읽으려면 복호화가 필요하다. 서명된 JWT의 내용을 디코딩하는 경우와 구분해야 한다. JWT 표준(RFC 7519)

내가 놀란 지점은 그 기본적인 구분에 대한 대화가 이어지지 않았다는 것이었다.

당시 나는 경력이 많은 선배라면 이런 원리는 익숙하게 알고 있을 것이라고 생각했다. 그래서 그 장면이 더 크게 다가왔던 것 같다. 평소 구현은 빠르게 진행되고 있었는데, 실제로 사용하는 기술의 동작 원리를 설명하는 순간에는 대화가 멈추고 있었다.

로컬에서 확인할 수 있었던 연동 테스트

또 한 번은 프론트엔드와 백엔드를 맡은 선배들이 연동 테스트를 진행하던 때였다. 두 사람은 같은 내부망에서 작업하고 있었고, 코드를 수정할 때마다 결과를 확인해야 했다. 그런데 로컬에서 실행한 서버에 서로 접근하는 방법 대신, 수정한 내용을 배포한 뒤 확인하는 방식으로 테스트를 진행하려고 했다. 작은 변경을 확인할 때도 배포 과정이 필요해지면서 작업이 길어졌다.

당시 환경에서는 서버의 접근 설정과 방화벽 등을 확인해 사설 IP로 연결하는 방법을 살펴볼 수 있었다. 하지만 두 사람은 배포를 전제로 문제를 풀다가 몇 시간 동안 어려움을 겪고 있었다. 옆에서 상황을 보고 함께 설정을 확인한 뒤에는 서로의 로컬 환경에 접근해 테스트할 수 있게 됐다.

내가 충격을 받은 이유는 모르는 내용이 있었다는 사실 자체보다, 익숙한 작업 방식을 잠시 멈추고 다른 방법을 찾아보는 과정이 잘 보이지 않았기 때문이다. JWT를 읽는 방법이나 로컬 서버에 접근하는 방법은 찾아보면서 이해할 수 있는 문제였다. 그런데 작업을 진행하는 데 집중하다 보니, 그 과정에서 생긴 질문을 충분히 살펴보지 않고 넘어가는 것처럼 느껴졌다.

물론 두 장면만으로 선배들의 역량을 판단할 수는 없고, AI 때문에 그렇게 됐다고 단정할 수도 없다. 다만 당시의 나에게는 AI가 일을 대신해 주는 만큼, 사람이 스스로 생각할 기회도 쉽게 놓칠 수 있다는 걱정이 남았다. 결과를 빠르게 얻을 수 있게 된 뒤에는 그 결과에 도달하는 과정을 이해하지 못해도 다음 작업으로 넘어갈 수 있었다.

이해의 과정을 스스로 선택해야 하는 때

이 걱정은 자연스럽게 나 자신에게도 향했다. Agent가 만들어 준 코드가 원하는 대로 동작하면, 나 역시 충분히 이해하지 않은 채 넘어갈 수 있다. 일정이 급하고 다음 작업이 기다리고 있다면 더욱 그렇다. 다른 사람의 모습을 보며 느꼈던 불편함은 결국 나도 같은 방식으로 일하고 있지는 않은지 돌아보게 만들었다.

GPT-4와 함께 문제를 해결하던 때에는 답변을 이해하지 못하면 구현을 이어 갈 수 없었다. 그래서 질문을 거듭하고, 자료를 찾아보고, 실제 코드와 비교해야 했다. 반면 Agent와 작업할 때는 내가 충분히 이해하지 못한 부분도 구현된 상태로 받을 수 있었다. 작업을 끝내기 위해 반드시 거쳐야 했던 이해의 과정이, 이제는 내가 선택해서 거쳐야 하는 과정이 된 것처럼 느껴졌다.

새 회사에서 경험한 생산성의 변화는 분명했다. 팀 규칙을 정리하고 Agent가 필요한 정보를 참고하도록 만드는 일은 실제로 업무를 수월하게 했다. 나 역시 그 효과를 경험하면서 이런 방식으로 개발하는 법을 배우고 싶어졌다. 그러면서도 한편으로는, 편리해진 작업 과정 안에서 내가 무엇을 배우고 있는지 확신하기 어려웠다.

처음에는 AI를 활용하는 새로운 개발 방식을 충분히 경험하지 못하고 있다는 불안이 컸다. 하지만 직접 Agent를 적극적으로 활용하고 나니 고민은 더 복잡해졌다. 이전의 공부 방식만 고집하기에는 개발 환경이 이미 달라지고 있었고, 그렇다고 빠르게 결과를 만드는 것만으로 성장하고 있다고 생각하기도 어려웠다.

돌아보면 GPT-4를 처음 사용했을 때의 놀라움과 Cursor를 활용하면서 느낀 놀라움은 조금 달랐다. 전자는 혼자 풀지 못하던 문제에 접근할 수 있게 됐다는 기쁨이었다. 후자는 내가 직접 하던 일의 상당 부분을 도구가 수행할 수 있다는 놀라움이었고, 그 뒤에는 내가 앞으로 무엇을 익혀야 할지에 대한 막막함이 따라왔다.

이 글에서 돌아본 경험들은 그 질문이 생겨난 과정이다. AI를 통해 문제를 해결하며 성장했다고 느꼈던 내가, 더 강력한 AI를 사용하면서 오히려 성장에 대해 고민하게 된 과정이기도 하다. 이어지는 하편에서는 이 고민을 안고 개발하는 방식을 어떻게 바라보게 됐는지, 그리고 달라진 환경에서 무엇을 배우고 익혀야 할지에 대한 생각을 이어 가려 한다.