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

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

예전에도 기술은 계속 바뀌었습니다. 새로운 프레임워크가 나오고, 더 좋은 라이브러리가 나오고, 더 편한 도구가 등장했습니다. 하지만 이번 변화는 조금 다르게 느껴졌습니다. 단순히 도구가 바뀌는 수준이 아니라, “개발자가 하는 일”의 경계가 직접 흔들리는 느낌이었기 때문입니다.

특히 저처럼 아직 커리어가 길지 않은 주니어 개발자에게는 더 그랬습니다. AI는 생산성을 높여주는 도구이기도 했지만, 동시에 제 기준을 흔드는 존재이기도 했습니다.

• 이제 서비스 개발의 진입장벽은 어디까지 낮아질까?
• 백엔드 개발자의 전문성은 앞으로도 분명한 형태로 남을까?
• 지금의 나는 CS, DB, Java, Spring 같은 기본기를 계속 붙잡아야 할까, 아니면 AI를 잘 쓰는 능력을 더 앞세워야 할까?

한동안 저는 이 질문들을 거의 같은 뜻으로 받아들였습니다. 결국 “AI가 개발자를 대체할까?“라는 불안의 변주라고 생각했던 겁니다.

그런데 세 글을 읽고 나서야 제가 붙잡고 있던 질문이 조금 잘못되어 있었다는 걸 깨달았습니다.

버블일 수는 있습니다. 실제로 지금의 AI 열풍에는 과열도 많고 과장도 많습니다. 하지만 버블이라는 말이 곧 안심해도 된다는 뜻은 아닙니다. 닷컴 버블이 꺼졌다고 인터넷이 사라지지 않았던 것처럼, 과열과 재편은 동시에 올 수 있기 때문입니다.

그래서 이제 제 질문은 조금 달라졌습니다.

“AI가 개발자를 대체할까?”보다 더 중요한 질문은, 내가 무엇을 AI에게 넘기고 무엇을 끝까지 붙잡아야 하는가이다.

이 글은 그 질문에 대해 AI 시대를 살아가는 주니어 백엔드 개발자로서 지금의 제 생각을 처음부터 다시 정리해 본 기록입니다.

질문을 바꿔야 했다

세 글이 공통으로 건드린 지점은 하나였습니다. 개발자의 미래를 단순히 “사라지느냐, 살아남느냐”의 이분법으로 보면 중요한 것을 놓치게 된다는 점입니다.

토스의 글은 질문을 이렇게 바꿉니다. 정말 중요한 것은 AI가 개발자를 통째로 대체하느냐가 아니라, 개발자라는 직업이 어떤 일의 묶음으로 다시 나뉘고 재정의되느냐는 것입니다. teo님의 글도 비슷한 방향에서 AI 시대에 더 선명해지는 개발자의 본질이 무엇인지를 묻습니다.

이 관점이 특히 크게 와닿았던 이유는 “개발자”라는 말이 원래부터 하나의 기술만 뜻하는 말이 아니었기 때문입니다. 코드 작성, 리뷰, 설계, 디버깅, 장애 대응, 문서화, 도메인 이해, 팀과의 조율, 요구사항 해석, 우선순위 판단까지 모두 섞여 있습니다. 그런데 우리는 종종 이 많은 일들을 그냥 “코딩”이라고 뭉뚱그려 부르곤 합니다.

AI는 이 묶음 전체를 한 번에 대체하지는 못합니다. 대신 그 안에 있던 일부 일을 빠르게 가져갑니다. 반복적인 구현, 초안 작성, 보일러플레이트, 테스트의 첫 번째 버전, 문서 초안 같은 것들입니다.

문제는 여기서부터입니다. 어떤 일은 생각보다 빨리 AI에게 넘어가는데, 어떤 일은 오히려 더 또렷하게 사람의 몫으로 남습니다. 그렇다면 이제 중요한 건 “AI를 쓰느냐 마느냐”가 아니라, 어떤 일을 내려놓고 어떤 일을 더 강하게 붙잡아야 하느냐가 됩니다.

이 질문은 주니어에게 더 무겁습니다. 시니어는 이미 여러 실패와 운영 경험, 도메인 이해를 몸에 쌓아둔 상태에서 AI를 맞이합니다. 하지만 주니어는 아직 그 사다리를 오르는 중입니다. 배워야 할 것도 많고 증명해야 할 것도 많은데, 그 사이에서 AI가 먼저 많은 입문 작업을 흡수해버리고 있으니 불안이 커질 수밖에 없습니다.

그래서 저는 이제 “AI 시대에도 백엔드 개발자가 필요할까?”보다 먼저 이렇게 묻고 싶습니다.

AI 시대의 주니어 백엔드 개발자는 무엇을 더 잘해야 하는가.

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

teo님의 글을 읽고 가장 크게 붙잡게 된 문장은 개발자의 역할을 “인간의 모호한 요구를 시스템이 풀 수 있는 문제로 바꾸고, 그 결과를 판단하고 책임지는 사람“으로 보는 관점이었습니다.

AI는 문서를 요약할 수 있고 구조를 제안할 수도 있으며 코드를 작성해줄 수 있습니다. 하지만 무엇을 만들어야 하는지, 어떤 조건이 성공인지, 무엇이 위험한 선택인지, 어디까지가 허용 가능한 예외인지는 여전히 사람이 정해야 합니다.

백엔드는 단순히 API를 만드는 일이 아닙니다. 데이터가 어떻게 흐르는지, 상태를 어디서 보장할지, 트랜잭션을 어떻게 끊을지, 인증과 인가를 어떻게 둘지, 동시성 문제를 어떻게 다룰지, 장애가 났을 때 어디서 복구할지, 어떤 로그와 메트릭으로 시스템을 관찰할지를 설계하는 일입니다. 겉으로는 “엔드포인트 하나 추가”처럼 보여도 실제로는 그 뒤에 더 무거운 질문이 따라붙습니다.

AI는 이 영역에서도 많은 제안을 해줄 수 있습니다. 하지만 제안을 한다는 것과 책임을 진다는 것은 다릅니다. 예를 들어 나중에 데이터 정합성을 깨뜨릴 위험은 없는지, 이 예외 처리가 실제 운영 환경에서도 감당 가능한지, 장애 상황에서 어떤 순서로 실패할지를 판단하는 일은 아직 개발자의 몫입니다.

그래서 저는 AI 시대를 지나며 개발자의 본질이 완전히 바뀌고 있다고 보지 않게 됐습니다. 오히려 반대에 가깝습니다.

반복적인 구현이 AI에게 많이 흡수될수록 원래 중요했지만 구현 노동에 가려져 있던 역할이 더 또렷하게 드러납니다.

• 문제를 정의하는 일
• 모호한 요구를 구체적인 명세로 바꾸는 일
• 필요한 맥락과 제약을 설명하는 일
• 결과를 검증하는 일
• 최종적으로 책임지는 일

결국 AI가 바꾸는 것은 개발자의 존재 자체라기보다 개발자가 시간을 쓰는 위치에 더 가깝습니다.

AI에게만 맡긴 프로젝트가 알려준 것

이 관점이 더 크게 와닿았던 건, 비슷한 문제를 이미 직접 겪어봤기 때문입니다.

최근에 개인 프로젝트를 하면서, 코드를 직접 작성하지 않고 AI에게만 요청해서 어디까지 만들 수 있는지 실험해본 적이 있습니다. 단순히 AI가 도움이 되는지 보는 정도가 아니라, 제가 거의 개입하지 않아도 프로젝트가 굴러갈 수 있는지 확인해보고 싶었습니다.

처음에는 꽤 잘 되는 것처럼 보였습니다. 환경 세팅도 빠르게 진행됐고, 간단한 API도 만족스럽게 나왔습니다. 막히면 AI가 다른 대안을 제시했고, 에러가 나면 수정 방향도 계속 내놓았습니다.

문제는 제가 그 속도를 따라가지 못했다는 점이었습니다.

프로젝트가 진행될수록 처음 보는 라이브러리와 구조가 점점 붙기 시작했는데, 저는 그 코드가 왜 그렇게 작성되었고 왜 그 기술을 선택했는지, 지금 구조가 괜찮은지, 어디가 위험한지를 설명할 수 없었습니다. 겉으로는 프로젝트가 앞으로 나아가는 것처럼 보였지만, 실제로는 제가 프로젝트의 맥락을 점점 잃어가고 있었던 겁니다.

결국 어느 순간부터는 프로젝트가 실행조차 제대로 되지 않는 상태가 됐습니다. 어디에서부터 문제가 시작됐는지 추적할 수 없었고, 무엇을 되돌려야 하는지도 알 수 없었습니다. AI는 계속 다음 답을 제시했지만, 그 답이 맞는지 판단할 수 있는 사람이 없었습니다.

돌이켜보면 그때 저는 코드를 안 쓴 것이 아니라, 생각을 안 하고 있었습니다.

AI를 사용하는 것과 AI에게 의존하는 것은 다릅니다.
AI를 사용하는 것은 생산성을 높이는 일일 수 있지만, AI에게 의존하는 것은 생각과 판단까지 넘겨버리는 일이 될 수 있습니다.

AI는 제가 이해하지 못하는 프로젝트를 대신 책임져주지 않습니다. 오히려 제가 이해하지 못하는 속도로 프로젝트를 더 멀리 끌고 갈 뿐입니다. 그 결과 마지막에 남는 것은 “빠르게 생성된 코드”가 아니라, 아무도 자신 있게 설명하지 못하는 시스템일 수 있습니다.

그래서 그 뒤로는 AI를 얼마나 많이 쓰느냐보다 어디까지를 맡기고 어디서부터는 내가 직접 이해해야 하는가를 더 중요하게 보게 됐습니다.

위임은 결국 추상화의 경계를 설계하는 일이다

요즘은 에디터보다 .md 문서를 더 오래 켜두는 날이 많습니다. 구현을 시작하기 전에 AI에게 어떤 맥락을 줘야 하는지, 어떤 규칙을 지켜야 하는지, 무엇을 건드리면 안 되는지 정리하는 시간이 늘어났기 때문입니다.

처음에는 이게 낯설었습니다. 개발자의 일이라면 코드를 직접 치는 시간이 중심이어야 한다고 생각했기 때문입니다. 그런데 teo님의 “.md로 코딩하는 시대”라는 표현을 읽다보니 생각이 달라졌습니다.

문서를 쓰고, 규칙을 정의하고, 검증 기준을 세우고, AI가 따라야 할 가드레일을 만드는 일도 결국은 시스템의 동작 방식을 설계하는 일입니다. 표현 매체가 코드에서 자연어로 일부 옮겨왔을 뿐, 핵심은 여전히 같습니다. 책임을 나누고, 흐름을 제어하고, 예외를 줄이는 일입니다.

이 지점에서 토스의 글이 말하는 “AI 위임은 곧 업무 추상화”라는 관점도 자연스럽게 연결됐습니다.

추상화는 단순히 복잡한 구현을 감추는 기술이 아닙니다.
무엇을 더 이상 직접 신경 쓰지 않아도 되는지 결정하는 일입니다.

그렇다면 AI에게 일을 맡긴다는 것도 결국 같은 뜻이 됩니다.

AI에게 맡긴다는 것은 그 일의 일부 디테일을 더 이상 직접 다루지 않겠다고 결정하는 일이다.

문제는 아무 디테일이나 내려놓을 수는 없다는 데 있습니다. 잘못된 추상화가 나쁜 결과를 만들듯, 잘못된 위임도 똑같이 문제를 키웁니다. 경계가 모호한 작업, 예외가 많은 작업, 컨텍스트 의존도가 높은 작업, 실패했을 때 되돌리기 어려운 작업은 “알아서 잘 해줘”라고 던지는 순간 위험해집니다.

반대로 AI에게 위임하기 좋은 일은 비교적 공통된 특징이 있습니다.

• 입력과 출력이 명확할 것
• 범위가 좁고 책임이 분리되어 있을 것
• 성공 조건을 미리 검증할 수 있을 것
• 실패해도 되돌리기 쉬울 것

예를 들면 보일러플레이트 코드 작성, 반복적인 DTO나 테스트 초안 생성, 문서의 첫 번째 버전, 비교적 잘 정의된 CRUD 구현 같은 것들입니다.

반대로 쉽게 맡기면 안 되는 일도 분명합니다.
아키텍처 결정, 보안 정책, 도메인 핵심 규칙, 장애 상황의 우선순위 판단, 운영 중인 시스템의 위험한 리팩토링 같은 것들입니다.

결국 AI 시대의 개발자는 더 많이 구현하는 사람이라기보다 위임의 경계를 설계하는 사람에 가까워지는 것 같습니다.

코드는 읽을 수 있어도 맥락은 읽히지 않는다

이 생각은 제가 지금 마주하고 있는 백엔드 작업에서 더 분명해졌습니다.

최근 저는 교육 플랫폼의 레거시 구조를 고도화하는 작업을 하고 있습니다. 이 서비스에는 학습자가 진단을 수행하고 그 결과를 분석한 뒤, 우리 회사의 교육 철학이 녹아 있는 커리큘럼을 제공하는 흐름이 있습니다.

겉으로만 보면 “진단 결과에 따라 추천을 제공하는 기능”처럼 보일 수 있습니다.
하지만 실제 로직 안에는 단순한 조건문 이상이 들어 있습니다.

이런 로직은 코드의 실행 흐름만 따라가서는 온전히 이해할 수 없습니다.
단순히 어떻게 동작하는지는 읽을 수 있어도 왜 그렇게 해야 하는지는 읽히지 않습니다.

저에게 특히 크게 다가왔던 건, “우리 회사의 교육 철학”이라는 표현 자체가 이미 AI가 스스로 알 수 없는 도메인 지식이라는 점이었습니다. 어떤 오답 패턴을 단순한 실수로 볼지, 어떤 결과를 학습 결손으로 해석할지, 어느 수준에서 어떤 커리큘럼을 제공해야 한다고 판단할지는 보편적인 정답이 있는 규칙이 아니었습니다. 그건 우리 서비스가 지금까지 쌓아온 해석이고 판단이었습니다.

바로 이 지점에서 AI의 한계도 같이 보였습니다.

AI는 코드 구조를 읽고 흐름을 요약하는 데는 도움을 줄 수 있습니다. 하지만 우리 회사 안에서만 통하는 맥락, 오랜 기간 쌓인 교육 도메인 의미, 그리고 그 로직이 왜 존재하는지에 대한 배경까지는 스스로 알 수 없습니다. 조건문은 읽을 수 있어도 그 조건 뒤에 있는 교육적 의도까지 복원할 수는 없는 셈입니다.

저는 이 지점에서 AI의 한계가 단순히 성능의 문제가 아니라 맥락의 소유권 문제라는 생각이 들었습니다. 결국 이 맥락을 풀어 설명하고, 도메인 단위로 문서화하고, 무엇이 핵심 규칙인지 정리해주는 일은 개발자의 몫입니다.

그래서 저는 지금 모든 프로시저와 메서드를 도메인 단위로 끊어서 풀어 정리하고, 그 문서를 기반으로 비즈니스 로직을 애플리케이션 코드로 옮기려 하고 있습니다. 지금 제게 먼저 필요한 것은 멋진 리팩토링 기술이 아니라, 왜 이 로직이 존재하는지를 문장으로 복원하는 일이었습니다. 결국 먼저 해야 했던 건 리팩토링이라기보다 번역에 가까웠습니다.

이 경험을 통해 더 분명하게 느낀 것이 있습니다.

AI가 이해할 수 있도록 맥락을 구조화하는 사람이 필요하기 때문에 AI 시대라고 해서 도메인 이해의 중요성이 줄어드는 것이 아니라, 오히려 더 중요해진다는 점입니다.

그래서 AI 시대일수록 기본기와 글쓰기가 더 중요해진다

한동안은 저도 반대로 생각했습니다. AI가 구현 속도를 이렇게 높여준다면, 전통적인 기본기의 중요성은 조금 줄어드는 것 아닐까 하고 말입니다.

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

이유는 단순합니다. 생성 속도가 빨라질수록 검토해야 할 코드의 양과 구조적 복잡성이 더 빠르게 늘어나기 때문입니다. 예전에는 한 줄씩 직접 작성하면서 자연스럽게 고민하던 문제를 이제는 훨씬 많은 양의 결과물을 짧은 시간 안에 읽고 판단해야 합니다.

기본기가 약하면 여기서 바로 한계가 옵니다.

예를 들어, AI가 API를 하나 만들어주더라도 그 API가 정말 안전한지 판단하려면 결국 아래 같은 질문을 직접 던질 수 있어야 합니다.

• 인증과 인가는 올바르게 분리되어 있는가
• 요청과 응답 모델은 장기적으로 유지 가능한가
• 트랜잭션 범위는 적절한가
• 동시성 상황에서 데이터 정합성이 깨지지 않는가
• 장애가 났을 때 로그와 메트릭으로 원인을 추적할 수 있는가
• 지금의 선택이 나중에 더 큰 운영 부채가 되지 않는가

DB 설계가 어색하면 성능과 정합성 문제가 뒤따르고, Spring의 동작 원리를 모르면 프록시나 예외 전파 같은 지점에서 이상한 버그를 설명하지 못할 수 있습니다. 보안에 대한 이해가 부족하면 당장은 동작하는 API를 만들 수 있어도 운영 환경에서는 위험한 시스템이 될 수 있습니다.

결국 AI는 제안을 할 수는 있어도 어떤 제안이 지금 상황에 맞는지 판단하는 능력은 기본기 위에서만 생깁니다.

토스의 글이 말하듯 좋은 엔지니어는 추상화를 신뢰하면서도, 그 아래에서 어떤 실패가 일어날 수 있는지에 대한 작동 모델을 머릿속에 갖고 있습니다. 저는 이 태도가 AI 시대에 더 중요해졌다고 느낍니다. 추상화를 쓸 줄 아는 것만으로는 부족하고 그 추상화가 어디서 깨질 수 있는지 아는 사람이 되어야 하기 때문입니다.

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

예전에는 글쓰기와 회고를 개발의 본질에서 한 발 떨어진 일처럼 느낀 적도 있었습니다. 지금은 아닙니다. 내가 무엇을 왜 선택했는지, 어떤 제약이 있었는지, 어디서 실패했고 무엇을 배웠는지를 구조적으로 설명하는 능력은 AI 시대에 더 중요해졌습니다.

잘 정리된 글은 잘 정리된 생각이고, 잘 정리된 생각은 더 좋은 위임과 더 좋은 검증으로 이어집니다. 무엇보다 글쓰기는 암묵지를 명시지로 바꾸는 훈련입니다. AI와 협업하는 시대에 이 능력은 선택이 아니라 거의 핵심 역량에 가까워지고 있다고 느낍니다.

그래서 나는 무엇을 붙잡고 무엇을 내려놓으려 하는가

여기까지 생각을 정리하고 나니, 적어도 지금의 저는 어떤 것을 붙잡고 어떤 것을 내려놓아야 할지 조금은 선명해졌습니다.

먼저 저는 내려놓을 것을 분명히 하려고 합니다.

이런 것들은 계속 AI에게 맡겨보려고 합니다. 다만 중요한 전제가 있습니다. 되돌릴 수 있고, 검증할 수 있고, 경계가 비교적 분명한 작업부터 맡긴다는 점입니다.

반대로 저는 끝까지 붙잡을 것도 분명히 하려고 합니다.

결국 저는 AI를 많이 쓰는 개발자가 되고 싶은 것이 아니라, AI를 어디에 써야 하는지 아는 개발자가 되고 싶습니다.

그래서 앞으로는 아래 다섯 가지를 꾸준히 실천해보려고 합니다.

1. AI를 계속 써보되, 단순히 빨라지는 경험으로 끝내지 않고 어떤 작업이 좋은 위임 대상인지 기록해보기
2. 작은 기능이라도 배포와 운영까지 연결해보며 시스템을 한 바퀴 완주해보기
3. CS, DB, Java, Spring, 보안, 테스트, 운영 같은 기본기를 계속 붙잡기
4. 도메인 로직을 코드만이 아니라 문장으로도 설명할 수 있도록 문서화와 회고를 습관으로 만들기
5. AI가 만든 결과를 무조건 검증하고, 왜 이 선택이 나왔는지 끝까지 설명해보기

이 다섯 가지는 거창한 전략이라기보다 AI 시대의 주니어 백엔드 개발자인 제가 당장 할 수 있는 현실적인 방향에 가깝습니다.

주니어에게 더 무겁게 다가오는 문제

여전히 불안은 남아 있습니다.

특히 주니어 사다리에 대한 불안은 쉽게 사라지지 않습니다. AI는 주니어가 주로 맡아왔던 반복적인 작업을 먼저 흡수하고 시니어의 일은 보조하는 방식으로 들어오는 것처럼 보입니다. 그러다 보니 주니어에게는 “예전보다 더 빠르게 시니어처럼 생각하라”는 요구만 남고, 천천히 시행착오를 겪으며 배울 수 있는 자리는 줄어드는 느낌이 들 때가 있습니다.

이건 개인의 노력만으로 모두 해결할 수 있는 문제는 아닙니다. 시장의 방향, 채용 구조, 팀이 주니어를 어떻게 키우는지 같은 더 큰 변수들이 분명히 있습니다.

다만 그렇다고 해서 제가 할 수 있는 일이 완전히 없는 것은 아닙니다.

지금의 저는 주니어라는 이유로 AI를 피하는 것보다 오히려 더 의식적으로 AI를 사용해보면서 그 안에서 제가 끝까지 붙잡아야 할 것을 훈련해야 한다고 생각합니다. 문제 정의, 맥락 설명, 검증, 문서화, 회고, 도메인 이해 같은 일은 누가 대신 주지 않기 때문입니다.

어쩌면 앞으로의 주니어는 예전보다 더 빨리 “생각하는 역할”에 올라타야 할지도 모릅니다. 저는 이 변화가 반갑지만은 않습니다. 그래도 피할 수 없다면, 적어도 그 방향을 똑바로 보고 준비하는 편이 낫다고 생각합니다.

맺으며

예전의 저는 AI 시대를 주로 불안의 언어로 바라봤습니다. 개발자가 덜 필요해지는 시대가 오는 것은 아닐까, 지금 공부하는 것들이 금방 낡아버리는 것은 아닐까, 주니어에게는 더 불리한 시장이 되는 것은 아닐까 하는 생각이 머릿속을 많이 차지했습니다.

지금도 그 불안이 완전히 사라진 것은 아닙니다. 다만 적어도 예전보다 질문은 더 선명해졌습니다.

이제 제게 중요한 것은 AI를 두려워하느냐, 아니면 무조건 낙관하느냐가 아닙니다.
더 중요한 것은 무엇을 AI에게 맡기고 무엇을 끝까지 책임질 것인가입니다.

저는 앞으로도 AI를 적극적으로 사용할 생각입니다. 더 많이 실험해보고, 더 많이 맡겨보고, 더 많이 실패해보려고 합니다. 하지만 그 과정에서 생각과 판단까지 같이 넘기지는 않으려고 합니다.

AI 시대의 주니어 백엔드 개발자에게 필요한 것은 더 빨리 타이핑하는 손이 아니라,
문제를 구조화하는 머리, 맥락을 설명하는 언어, 결과를 검증하는 눈, 그리고 끝까지 책임지는 태도라고 생각합니다.

불안을 완전히 없애지는 못했습니다.
하지만 적어도 이제는 어디에 시간을 써야 하는지는 조금 더 분명해졌습니다.

AI를 피하지 않되, 생각과 책임까지 위임하지 않는 개발자.

지금의 저는 그런 주니어 백엔드 개발자가 되고 싶습니다.