AI 시대의 주니어 백엔드 개발자는 무엇을 붙잡아야 할까

teo님의 AI 시대의 개발자: 현업 개발자의 솔직한 이야기를 읽고 느낀점을 정리한 글입니다.

AI가 등장한 뒤로 개발자라는 직업을 바라보는 시선 자체가 많이 달라졌습니다.

예전에도 기술은 빠르게 변했습니다. 새로운 프레임워크가 나오고, 더 좋은 라이브러리가 나오고, 더 편한 개발 도구가 나왔습니다. 하지만 최근의 변화는 조금 결이 다르게 느껴졌습니다. 어제 어렵게 느껴졌던 일이 오늘은 AI 덕분에 훨씬 쉽게 보이고 오늘 막 익숙해진 도구가 내일이면 또 다른 방식으로 대체될 것처럼 보였기 때문입니다.

특히 ChatGPT가 등장한 이후에는 그 변화의 속도가 더 직접적으로 느껴졌습니다. 단순히 검색을 더 잘해주는 도구가 아니라, 설명을 해주고, 코드를 짜주고, 구조를 제안하고, 문서를 요약하고, 심지어 어느 정도는 서비스의 형태까지 빠르게 만들어 주는 존재가 생긴 것입니다. 여기에 Cursor 같은 AI 코딩 도구의 확장, 작업 일부를 스스로 수행하는 AI Agent의 등장, 자연어만으로 빠르게 구현해보는 바이브 코딩까지 등장하면서 개발자로서의 불안은 더 커졌습니다.

정말 이제 개발자는 덜 필요해지는 걸까 ?

특히 백엔드 개발자는 앞으로도 전문성이 있는 직업일까 ?

그리고 지금의 나는 무엇을 준비해야 할까.

저는 주니어 백엔드 개발자입니다. 아직 커리어가 길지 않기 때문에 시장의 변화가 더 크게 다가왔습니다. 어느 정도 연차가 쌓인 개발자라면 지금까지의 경험과 도메인 이해를 바탕으로 변화에 대응할 여지가 많아 보이지만 주니어는 아직 증명해야 할 것도 많고 배워야 할 것도 많은데, 그 와중에 AI까지 등장하니 기준이 흔들리는 느낌을 받았습니다.

저를 가장 크게 흔든 불안은 두 가지였습니다.

첫 번째는 존재 불안이었습니다.

AI가 없던 시절에는 서비스를 만든다는 것 자체가 꽤 높은 진입장벽이었습니다. 코드를 작성할 줄 알아야 했고 프레임워크를 이해해야 하며 서버를 띄우고 데이터를 다루고 배포하는 방법도 알아야 했습니다. 그런데 지금은 비전공자나 다른 직군의 사람들도 AI를 활용해서 원하는 기능을 빠르게 만들고 실제로 서비스 형태로 운영하는 사례가 점점 늘어나고 있습니다.

물론 이 변화가 나쁘다는 뜻은 아닙니다. 오히려 다양한 서비스들이 많이 출시되는 반가운 일입니다. 다만 개발자의 입장에서는 허들이 이렇게 낮아진다면, ‘개발자라는 직군의 전문성은 어떻게 되는 걸까?’, ‘백엔드 개발자라는 포지션은 앞으로도 분명한 전문성을 인정받을 수 있을까?’ 저 역시 이 질문 앞에서 꽤 오래 불안했습니다.

두 번째는 방향성에 대한 불안이었습니다.

AI 시대의 개발자로서 대체 무엇을 준비해야 하는가… 지금까지 공부해오던 CS, DB, Java, Spring 같은 기본기를 계속 붙잡아야 하는지 아니면 이제는 AI를 잘 쓰는 능력을 더 우선해야 하는지 방향이 잡히지 않았습니다.

그러던 중에 teo님의 글인 AI 시대의 개발자: 현업 개발자의 솔직한 이야기를 읽게 되었습니다. 이 글이 저의 불안을 단번에 없애주지는 않았지만, 제가 무엇을 불안해하고 있었는지 더 정확하게 보게 해준 글에 가까웠습니다. 막연하던 감정을 구체적인 질문으로 바꿔 주었고, 그 질문 앞에서 제가 무엇을 붙잡아야 할지 조금 더 선명하게 만들어 주었습니다.

내가 가장 크게 붙잡게 된 관점

이 글을 읽으면서 가장 크게 와닿았던 것은, AI 시대의 개발자를 단순히 AI를 잘 쓰는 사람으로 정의하지 않는다는 점이었습니다.

개발자는 인간의 모호한 요구를 더 구체적인 문제로 바꾸고 그것을 시스템이 처리할 수 있는 형태로 만들어서 결과가 맞는지 판단하고 책임지는 사람이다.

그전까지 저도 AI 시대의 개발자에 대해 이것저것 생각해 보았습니다. 예를 들어 AI의 컨텍스트를 더 잘 관리하는 능력이 핵심인가, 프롬프트를 더 정교하게 만드는 능력이 중요한가, 아니면 모델별 특성과 비용을 이해하고 더 효율적으로 활용하는 능력이 중요해지는가 같은 질문들입니다. 이런 것들이 모두 중요하지 않다는 뜻은 아닙니다. 다만 그것들이 중심은 아니라는 생각이 들었습니다.

중심은 여전히 문제를 이해하는 능력이었습니다.

사람의 요구는 대부분 모호합니다. 컴퓨터는 “좀 더 편하게”, “더 빠르게”, “이상 없이”, “자동으로”, “좋은 경험으로” 같은 표현을 그대로 구현할 수는 없습니다. 누군가는 이 모호한 표현을 구체적인 시나리오와 조건으로 바꿔야 합니다. 어떤 데이터가 필요한지, 어떤 예외가 생길 수 있는지, 어디까지를 자동화하고 어디부터는 사람이 개입해야 하는지, 무엇이 성공이고 무엇이 실패인지 정해야 합니다.

AI가 코드를 대신 써줄 수는 있어도 무엇을 만들어야 하는지와 어떤 기준으로 맞고 틀림을 판단하는지는 여전히 사람의 몫입니다. 그리고 그 책임은 결국 개발자에게 돌아옵니다.

이 지점이 저에게 크게 와닿았던 이유는 AI 시대의 개발자가 무엇을 해야 하는지에 대한 제 머릿속 정의가 모호했기 때문입니다. 저는 막연히 “예전과는 다른 능력이 필요할 것이다”라고만 생각하고 있었습니다. 그런데 이 글을 읽고 나니 예전과 다른 능력만이 중요한 것이 아니라 오히려 예전부터 중요했던 능력이 더 선명해지는 시대일 수 있겠다는 생각이 들었습니다.

• 추상적인 요구를 구체적인 명세로 바꾸는 능력
• 맥락과 의도를 명확하게 설명하는 능력
• 내가 다루는 업과 도메인을 이해한 상태에서 무엇을 AI에게 맡기고 무엇은 직접 판단해야 하는지 구분하는 능력
• 결과를 검증하고 책임지는 능력

이런 능력들은 AI 이전에도 좋은 개발자에게 필요했던 역량입니다. 다만 AI가 등장하면서 그 중요성이 줄어든 것이 아니라 오히려 더 직접적으로 드러나고 있다고 느꼈습니다.

이 생각을 더 현실적으로 만든 경험

사실 이 관점이 더 크게 들어왔던 이유는 비슷한 문제를 이미 직접 겪어본 적이 있었기 때문입니다.

최근에 개인 프로젝트를 하나 진행한 적이 있습니다. 그때 저는 코드를 직접 작성하지 않고 AI에게만 요청해서 프로젝트를 완성해보자는 극단적인 목표를 잡았습니다. 단순히 “AI가 어느 정도 도움을 주는지”를 보는 것이 아니라 제가 개입하지 않아도 프로젝트가 어디까지 굴러갈 수 있는지를 직접 확인해보고 싶었습니다.

처음에는 환경 세팅이나 간단한 API 구현 같은 작업은 AI가 꽤 자연스럽게 처리했습니다. 네이밍도 좋았고 클래스나 메서드 구조도 괜찮았습니다. 저도 같이 결과물을 따라가면서 “생각보다 방향을 잘 잡아주는데?”라는 느낌을 받았습니다.

문제는 그 다음부터였습니다.

프로젝트가 진행되면서 제가 잘 모르는 기술이나 개념들이 등장하기 시작했습니다. AI는 기능을 구현하기 위해 새로운 라이브러리나 구조를 자연스럽게 가져왔고 처음 보는 코드도 거리낌 없이 붙여 넣었습니다. 겉으로만 보면 프로젝트는 점점 풍성해지고 있었지만 저는 점점 프로젝트를 따라가지 못하고 있었습니다.

이 코드가 왜 이렇게 작성되었는지 설명할 수 없었고, 왜 이 기술을 선택했는지 판단할 수도 없었으며 지금 구조가 괜찮은지, 어디가 위험한 부분인지도 전혀 파악하지 못했습니다.

그래도 일단 프로젝트 완성이 목표였기 때문에 계속 진행했습니다. 그 과정에서 가장 위험했던 점은 제가 이해하지 못하는 코드가 쌓이는데도 겉보기엔 프로젝트가 앞으로 나아가는 것처럼 보였다는 것입니다. AI는 항상 다음 단계의 답을 제시해 주었습니다. 막히는 것처럼 보이면 다른 대안을 가져왔고, 에러가 나면 그 에러를 해결하는 새로운 코드나 설정을 제안했습니다.

그런데 어느 순간부터는 프로젝트가 실행조차 제대로 되지 않는 상태가 되어버렸습니다. 어디에서 문제가 시작되었는지 추적할 수 없었고 무엇을 되돌려야 하는지도 알 수 없었습니다. 프로젝트의 맥락을 전체적으로 이해하지 못하는 상태에서 AI가 계속 덧붙인 코드들만 남아 있었고, 최종 검토자인 저는 그 결과물이 맞는지 판단할 능력이 없었습니다.

그제서야 AI만 사용한다고 프로젝트가 굴러가는 것은 아니라는 것을 알게 됐습니다.

내가 만들고 있는 것이 무엇인지, 이 프로젝트가 어떤 흐름으로 돌아가고 사용하는 기술이 어떤 역할을 하는지 제가 먼저 이해하고 있어야 했습니다. 그래야 AI에게도 명확하게 설명할 수 있고 결과가 어긋났을 때 어디서부터 다시 봐야 하는지도 판단할 수 있습니다.

반대로 제가 기술을 모르고, 도메인을 이해하지 못하고, 구조를 모르면 AI가 제대로 만들고 있는지조차 알 수 없습니다. 이 상황에서 AI는 저를 도와준 것이 아니라 제가 이해하지 못한 속도로 프로젝트를 더 멀리 끌고 갔을 뿐이었습니다.

이 경험 이후로는 “AI를 사용하는 것”과 “AI에게 의존하는 것”이 완전히 다르다는 점을 체감하게 됐습니다.

AI를 사용하는 것이 잘못된 것은 아닙니다. 더 빠르게 실험하고, 더 빠르게 비교하고, 더 빠르게 초안을 만들 수 있습니다. 하지만 AI에게 의존하는 순간 제가 생각해야 할 역할까지 넘기게 됩니다. 프로젝트의 방향을 잡는 일, 무엇이 중요한지 정하는 일, 결과를 검증하는 일까지 AI에 기대기 시작하면 결국 마지막에 아무도 책임질 수 없는 결과물만 남을 수 있습니다.

돌아보면 저는 그 프로젝트에서 코드를 안 쓴 것이 아니라 생각을 안 하고 있었습니다. 이 사실이 저에게는 꽤 크게 남았습니다.

개발자의 본질은 사라진 것이 아니라 더 선명해졌다

이 경험과 teo님의 글이 겹치면서 AI 시대를 바라보는 방식도 달라졌습니다.

예전에는 AI가 코딩을 도와주기 시작하면 개발자의 핵심 역량도 함께 바뀔 것이라고 생각했습니다. 물론 일부는 바뀔 것입니다. 개발 방식은 이미 달라지고 있고, 앞으로도 더 달라질 가능성이 큽니다. 하지만 그렇다고 해서 개발자의 본질이 완전히 새로운 것으로 교체되는 것은 아닌 것 같습니다.

오히려 반대일 수 있습니다. 개발자의 본질은 그대로인데, 그 본질을 감추고 있던 반복적인 구현 작업이 AI에 의해 많이 흡수되면서 원래 중요했던 역할이 더 또렷하게 드러나고 있는 것일 수 있습니다.

• 무엇을 만들 것인지 정의하는 일
• 어떤 문제를 풀고 있는지 명확히 하는 일
• 모호한 요구를 구체적인 설계와 명세로 바꾸는 일
• 맥락을 설명하고 선택의 이유를 정리하는 일
• 결과를 검증하고 책임지는 일

이런 역할은 AI가 등장했다고 해서 갑자기 생긴 것이 아닙니다. 원래 좋은 개발자에게 필요하던 역량입니다. 다만 이제는 구현 자체보다 “무엇을 시키고 무엇을 검토하며 어떤 기준으로 판단할지”가 더 중요해진 만큼, 이 역량들이 더 눈에 띄게 됐습니다.

이 점에서 백엔드 개발자의 역할을 생각해봤습니다.

백엔드는 단순히 API를 만드는 일이 아닙니다. 데이터의 흐름을 설계하고, 상태를 관리하고, 예외를 다루고, 시스템이 일관되게 동작하게 만드는 일입니다. 요청 하나가 들어왔을 때 어떤 검증을 거쳐야 하는지, 어느 시점에 트랜잭션이 보장되어야 하는지, 중복 요청이나 동시성 문제는 어떻게 다뤄야 하는지, 장애 상황에서 어떻게 복구할지, 로그와 모니터링은 어떻게 남겨야 하는지 같은 질문들이 자연스럽게 따라옵니다.

AI는 이런 문제에 대해서도 제안을 할 수 있습니다. 하지만 어떤 제안이 지금 상황에 맞는지, 어떤 방식이 실제 서비스 운영에서 감당 가능한지, 어떤 선택이 나중에 더 큰 부채가 될지는 여전히 개발자가 판단해야 합니다.

그래서 저는 “AI 시대에는 백엔드 개발자가 덜 필요해질까?”라는 질문을 조금 다르게 바꾸게 되었습니다.

이제 더 중요한 질문은 “AI 시대에 백엔드 개발자는 무엇을 더 잘해야 하는가?”입니다.

AI 시대일수록 기본기가 더 중요해진다고 느낀 이유

한동안은 저도 반대로 생각했습니다. AI가 코드를 더 빨리 써주기 시작하면 기본기의 중요성은 상대적으로 조금 줄어드는 것 아닐까, 구현 속도가 핵심이 아니게 된다면 전통적인 공부 방식의 비중도 줄어들지 않을까 하는 생각이 들었습니다.

그런데 지금은 오히려 AI가 구현 속도를 끌어올릴수록 기본기는 더 중요하다고 느낍니다.

이유는 단순합니다. 코드가 더 빨리 만들어질수록 그 코드를 읽고 구조를 이해하고 위험을 판단할 수 있는 능력의 가치가 더 커지기 때문입니다. 예전에는 한 줄 한 줄 직접 작성하면서 생각했을 문제를 이제는 훨씬 많은 양의 코드와 구조를 짧은 시간 안에 검토해야 합니다. 기반 지식이 없으면 결과물을 감당하기 어렵습니다.

AI가 API 하나를 만들어주는 것은 상대적으로 쉬워 보일 수 있지만 그 API가 실제로 안전한지, 인증과 인가가 올바른지, 요청과 응답 모델이 적절한지, 데이터 정합성에 문제가 없는지, 트랜잭션 범위가 맞는지, 동시성 상황에서 안전한지, 장애가 났을 때 어떤 로그를 남기고 어떻게 복구할 수 있는지까지는 다른 차원의 문제입니다.

예를 들어 DB 설계가 어색하면 나중에 쿼리 성능과 정합성 문제가 따라올 수 있습니다. 또한, Spring의 동작 방식을 제대로 이해하지 못하면 프록시, 예외 전파, 빈 생명주기 같은 지점에서 이상한 버그를 만나도 이유를 설명하지 못할 수 있습니다. 보안에 대한 이해가 부족하면 당장은 동작하는 API를 만들 수 있어도 실제 운영 환경에서는 위험한 시스템이 될 수 있습니다.

AI는 이런 부분에 대한 예시와 제안을 줄 수 있지만, 무엇이 지금 서비스에 적절하고 무엇이 위험한 선택인지는 결국 기본기가 있는 사람이 판단할 수 있습니다.

그래서 저는 AI 시대일수록 기본기가 더 중요해졌다고 느끼게 됐습니다.

여기에 저는 한 가지를 더 붙잡고 싶습니다. 글쓰기와 회고입니다.

예전에는 글쓰기나 회고를 개발의 본질에서 조금 떨어진 일처럼 느낀 적도 있었습니다. 지금은 아닙니다. 내가 무엇을 왜 선택했는지 설명하고, 내가 겪은 문제를 정리하고, 맥락을 구조화해서 남기는 능력은 AI 시대에 더 중요해졌습니다. 잘 정리된 글은 곧 잘 정리된 생각이고, 잘 정리된 생각은 결국 더 좋은 지시와 더 나은 판단으로 이어질 가능성이 높기 때문입니다.

그래서 앞으로 나는 무엇을 붙잡으려고 하는가

이 글과 제 경험을 통해 지금의 저는 두 가지 방향을 함께 가져가야겠다고 생각하게 됐습니다.

첫 번째는 AI를 적극적으로 활용하는 사람 되기입니다.

AI는 이미 일시적인 유행이라기보다 개발 문화가 되어버렸습니다. AI 없이 개발하는 능력을 자랑하는 시대라기보다, AI를 도구로서 제대로 사용할 줄 아는 사람이 더 유리한 시대가 되었다고 생각합니다. 그래서 저는 AI를 피하지 않으려고 합니다. 더 많이 써보고, 작은 프로젝트라도 직접 적용해보고, Agent나 Harness 같은 개념도 경험해보면서 제 작업 흐름 안에서 익숙한 도구로 만들고자 합니다.

단순히 질문을 잘 던지는 수준에 머무르지 않고, 어떤 작업을 AI에게 맡기면 좋은지, 무엇은 반드시 제가 직접 판단해야 하는지, AI의 답을 어떻게 검증해야 하는지까지 포함한 기준을 만들 것입니다.

두 번째는 본질에 더 충실한 개발자 되기입니다.

AI를 적극적으로 활용할수록 제가 다루는 기술과 도메인에 대해서는 AI보다 더 명확하게 알고 있어야 한다는 사실을 실감했습니다.

그래서 앞으로도 CS, DB, Java/Spring, 설계 같은 기본기를 계속 붙잡으려고 합니다. 공식 문서를 읽고, 원리를 다루는 책을 읽고, 작은 프로젝트라도 끝까지 완성해보면서 내 지식이 실제 문제 해결로 이어지도록 만드는 방향으로 가고자 합니다.

지금 기준으로 제가 붙잡고 싶은 실행 방향을 정리하면 이렇습니다.

1. AI를 계속 써본다.
   새로운 도구가 나오면 겁먹기보다 직접 만져보고, 작은 개인 프로젝트에도 적용해보면서 익숙해진다.

2. AI가 만든 결과를 무조건 검증한다.
   그럴듯해 보여도 그대로 믿지 않고, 왜 이런 구조가 나왔는지, 지금 상황에 맞는지 계속 따져본다.

3. 기본기를 더 단단하게 쌓는다.
   CS, DB, Java/Spring, 설계, 보안, 테스트, 운영 관점까지 포함해서 실제 서비스에 필요한 이해를 깊게 만든다.

4. 작게라도 끝까지 만들어본다.
   초안이나 데모 수준이 아니라, 배포와 운영까지 연결되는 경험을 통해 시스템을 한 바퀴 완주해본다.

5. 글을 쓰고 회고한다.
   무엇을 배웠고, 어디서 막혔고, 왜 이런 판단을 했는지 기록하면서 생각을 구조화하는 연습을 한다.

저는 이 다섯 가지가 AI 시대의 주니어 백엔드 개발자인 제가 당장 붙잡을 수 있는 현실적인 방향이라고 생각하고 있습니다.

아직 남아 있는 불안과 지금의 태도

물론 불안이 완전히 사라진 것은 아닙니다.

여전히 채용 시장에 대한 불안은 남아 있습니다. 주니어 포지션은 줄어드는 것 같고, 기대 수준은 더 높아지는 듯합니다. AI가 더 발전하면 기업이 더 적은 인원으로 더 많은 일을 하려는 방향을 갈 수도 있습니다.

이 불안은 쉽게 해소되지 않습니다. 왜냐하면 이 문제는 개인의 노력만으로 통제할 수 있는 영역이 아니기 때문입니다. 산업 전체의 변화와 채용 시장의 흐름, 기업의 투자 방향 같은 요소들은 개인이 좌우할 수 없습니다.

하지만 이제는 불안을 붙잡고 있는 시간이 문제를 해결해주지 않는다는 걸 압니다. 시장이 어떻게 바뀔지에 대해 계속 상상하는 것보다, 지금 내가 통제할 수 있는 부분을 더 단단히 만드는 것이 결국 더 현실적인 대응이라는 생각을 하게 됐습니다.

채용 시장이 줄어드는 것 자체는 당장 바꿀 수 없습니다.
하지만 그 안에서 더 설득력 있는 개발자가 되는 일은 제가 할 수 있습니다.

AI가 앞으로 얼마나 더 좋아질지는 예측하기 어렵습니다.
그렇다고 준비를 미룰 이유는 없습니다. AI를 도구로 익숙하게 사용하면서도, 그 위에 설 수 있는 기본기와 판단력을 쌓는 일은 지금 바로 시작할 수 있습니다.

개발자의 역할이 변하는 것은 피할 수 없을지 누구도 모릅니다.
하지만 그 변화 속에서 내가 어떤 개발자가 되고 싶은지 정하고, 거기에 맞는 준비를 하는 일은 저의 몫입니다.

그래서 지금의 저는 불안을 없애려고 하기보다, 불안을 방향으로 바꾸려고 합니다.

막연하게 뒤처질까 봐 두려워하기보다 AI를 직접 써보면서도 생각하는 역할까지 넘기지 않는 개발자,
속도에만 집착하지 않고 문제를 구조화하고 맥락을 설명하며 결과를 검증할 수 있는 개발자,
그리고 무엇보다 AI가 발전하는 시대일수록 본질에 더 가까이 가는 개발자가 되려고 합니다.

마무리

teo님의 글을 읽기 전까지 저는 AI 시대를 주로 불안의 언어로 바라봤습니다. 개발자가 줄어드는 시대가 오는 것 아닐까, 주니어에게 더 불리한 시장이 되는 것 아닐까, 내가 지금 공부하는 것들이 금방 낡아버리는 것 아닐까 하는 생각들이 머릿속을 많이 채우고 있었습니다.

이제는 적어도 무엇을 해야 할지 분명해진 것 같습니다.

AI를 피하는 것이 답은 아니고 그렇다고 AI만 믿는 것도 답이 아닙니다.

중요한 것은 AI를 적극적으로 활용하되, 문제를 정의하고 맥락을 설명하고 결과를 검증하는 역할까지 넘기지 않는 것이라고 생각합니다. 결국 개발자의 역할은 코드를 입력하는 손 자체에만 있지 않습니다. 무엇을 만들어야 하는지 판단하고, 그것을 시스템이 해결할 수 있는 문제로 바꾸고, 최종적으로 책임지는 사람이라는 점에서 여전히 의미가 있습니다.

그리고 저는 앞으로 AI를 잘 활용하는 사람과 그렇지 않은 사람의 격차는 더 커질 것이라고 생각합니다. 다만 여기서 말하는 “잘 활용한다”는 것은 단순히 프롬프트를 잘 쓰는 능력이 아닙니다.

차이를 만드는 것은 결국 더 근본적인 부분일 것입니다. 문제를 더 잘게 나눌 수 있는 사람, 필요한 맥락을 더 정확하게 설명할 수 있는 사람, AI가 만든 결과를 그대로 받아들이지 않고 직접 검증할 수 있는 사람, 그리고 그 과정에서 공식 문서와 원리를 확인하며 자기 실력으로 다시 흡수하는 사람이 결국 더 멀리 갈 것이라고 생각합니다.

반대로 AI를 그럴듯한 답을 주는 도구로만 소비하면 속도는 잠깐 빨라질 수 있어도 실력은 쉽게 남지 않을 수 있습니다. 그래서 저는 결국 AI를 쓰느냐 마느냐보다, AI를 어떤 위치에 두고 쓰느냐에서 격차가 벌어질 것이라고 믿고 있습니다.

이 글은 어쩌면 그 방향을 잊지 않기 위해 스스로에게 남기는 기록일지도 모르겠습니다.