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

요즘은 개발 언어로 기능을 구현하는 시간보다 markdown 파일로 정리된 스킬을 읽어보고, 자연어로 AI에게 요청하고, 규칙 파일을 작성하는 시간이 더 많아졌습니다.

그러다 보니 문득 이런 생각이 들었습니다.

이게 내가 생각하던 개발자의 모습이 맞을까?

예전에는 개발을 한다고 하면 자연스럽게 에디터를 열고 코드를 직접 작성하는 장면이 먼저 떠올랐습니다. 그런데 지금은 프롬프트를 쓰고, 규칙을 정리하고, AI가 따를 맥락을 문서로 설명하는 시간이 점점 더 많아졌습니다.

AI를 최대한 잘 활용해보려고 노력하면서도, 한편으로는 묘한 회의감이 있었습니다.
내가 개발을 하고 있는 건지, 아니면 문서를 정리하고 있는 건지 헷갈릴 때가 있었기 때문입니다.

그 시점에 보게 된 글이 teo님의 우리, 프로그래머들 - .md로 코딩하는 시대였습니다. 제목부터 지금 제 상황을 정확하게 건드리는 느낌이었습니다.

이전 글에서는 AI 시대의 주니어 백엔드 개발자가 무엇을 붙잡아야 하는지에 대해 고민했다면, 이번 글을 읽고 나서는 질문이 조금 달라졌습니다.

이제 제 고민은 단순히 “무엇을 더 공부해야 할까“가 아니라,
“무엇을 AI에게 맡기고 무엇을 내가 끝까지 붙잡아야 할까“로 옮겨갔습니다.

코드를 덜 친다고 개발을 덜 하는 것은 아니었다

이 글에서 가장 크게 와닿았던 표현은 역시 “.md로 코딩하는 시대”였습니다.

처음에는 이 표현이 낯설었습니다.
솔직히 말하면, 저에게 개발의 낭만은 코드를 직접 고민하고, 한 줄씩 작성하고, 구조를 잡아가며 구현하는 데 있었습니다.

그런데 AI를 쓰기 시작한 뒤로는 프롬프트를 쓰고, 규칙 파일을 만들고, 스킬을 정의하고, 체크리스트를 정리하는 시간이 늘어났습니다. 한동안 저는 이 변화를 개발의 본질에서 조금 멀어진 것으로 받아들였습니다.

하지만 글을 읽고 나니 생각이 달라졌습니다.

문서를 쓰고, 규칙을 정의하고, 프롬프트를 설계하고, AI가 지켜야 할 가드레일을 만드는 일 역시 결국은 시스템의 동작 방식을 설계하는 일이었기 때문입니다. 표현 방식이 자연어로 바뀌었을 뿐, 여전히 기능을 분리하고 책임을 나누고 흐름을 제어한다는 점에서는 개발과 크게 다르지 않았습니다.

오히려 이 과정은 코드를 작성하기 전에 내가 무엇을 만들고 싶은지, 어떤 제약이 필요한지, 어디까지를 자동화하고 어디부터는 통제해야 하는지를 더 명확하게 드러내는 작업에 가깝다고 느꼈습니다.

코드를 직접 타이핑하는 손맛은 줄어들 수 있습니다.
하지만 설계가 사라지는 것은 아니었습니다.

오히려 무엇을 문서로 정의해야 하고, 무엇을 규칙으로 고정해야 하고, 무엇을 검증 단계로 막아야 하는지를 고민하는 새로운 형태의 코딩이 시작된 것에 더 가까웠습니다.

AI에게 일을 맡긴다는 것은 결국 추상화를 다시 설계하는 일이다

이전에는 AI 시대의 개발자를 떠올릴 때, 주로 “AI를 잘 쓰는 사람”을 생각했습니다.

프롬프트를 잘 쓰는 사람, 최신 도구를 빨리 익히는 사람, 더 빠르게 결과물을 만드는 사람이 앞으로 유리하지 않을까 생각했습니다. 물론 이런 능력들이 중요하지 않다는 뜻은 아닙니다.

하지만 이번 글과 토스의 글을 함께 읽고 나서는 더 중요한 지점이 보였습니다.

AI에게 일을 맡긴다는 것은 결국 추상화를 다시 설계하는 일이라는 점입니다.

추상화는 단순히 구현을 감추는 기술적인 기법만은 아니었습니다.
내가 더 이상 직접 신경 쓰지 않아도 되는 것과, 끝까지 직접 이해하고 책임져야 하는 것을 나누는 일이기도 했습니다.

이 관점에서 보니 AI를 쓴다는 것도 조금 다르게 보였습니다.

단순히 “편하게 시킨다”가 아니라,
“어디까지는 내려놓아도 되고 어디부터는 내가 붙잡아야 하는가”를 판단하는 일에 더 가까웠습니다.

간단한 CRUD나 문서화처럼 잘 정의된 문제는 AI에게 꽤 많이 맡길 수 있습니다. 실제로 이런 작업은 지금의 AI도 정말 빠르고 능숙하게 도와줍니다.

하지만 레거시 리팩토링, 도메인 규칙이 얽힌 비즈니스 로직 수정, 운영 장애의 원인 분석처럼 맥락과 책임이 무거운 영역은 전혀 다른 문제였습니다.

이 지점에서 저는 개발자의 역할을 조금 다르게 보게 되었습니다.

AI 시대의 개발자는 더 많이 구현하는 사람이 아니라,
무엇을 AI에게 맡길 수 있는지와 무엇은 맡기면 안 되는지를 구분하고, 그 경계를 설계하는 사람에 가깝다고 느꼈습니다.

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

이 관점은 특히 제가 백엔드 개발자로 일하면서 더 크게 와닿았습니다.

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

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

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

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

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

결국 이 맥락을 풀어 설명하고, 도메인 단위로 문서화하고, 무엇이 핵심 규칙인지 정리해주는 일은 개발자의 몫입니다.

그래서 저는 지금 모든 프로시저와 메서드를 도메인 단위로 끊어서 풀어 정리하고, 그 문서를 기반으로 비즈니스 로직을 애플리케이션 코드로 옮기려 하고 있습니다.

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

AI 시대라고 해서 도메인 이해의 중요성이 줄어드는 것이 아니라, 오히려 더 중요해진다는 점입니다.

AI가 이해할 수 있도록 맥락을 구조화하는 사람이 필요하기 때문입니다.

AI는 생각을 대신하기보다 생각의 층위를 올려줄 때 가장 유용했다

그렇다고 해서 AI를 불신의 대상으로만 보고 싶지는 않습니다.

오히려 AI 덕분에 제가 더 높은 층위에서 생각해보게 된 경험도 있었습니다.

개인 프로젝트를 하면서 로깅 시스템을 설계해야 했던 적이 있습니다. 당시 저는 로그를 서버 상태 확인, 예외 처리, 에러 트레이스를 남기는 정도로만 좁게 이해하고 있었습니다. 회사에서도 뚜렷한 로깅 시스템을 경험해본 적이 없었기 때문에, 운영 환경에서 로그를 어떻게 설계하고 활용해야 하는지 감이 부족했습니다.

이때 제가 리서치한 내용과 고민을 정리해서 AI에게 맥락과 함께 질문했더니, 단순히 라이브러리 하나를 추천하는 수준이 아니라 운영 지표를 어떻게 볼 것인지, 에러 원인을 파악하기 위해 어떤 로그가 더 필요한지, 성능을 고려해 어떤 방식으로 기록하는 것이 나은지 같은 방향까지 같이 제안해주었습니다.

물론 AI의 제안이 항상 정답이라고 말할 수는 없습니다.
하지만 적어도 그 과정을 통해 제 사고의 층위가 한 단계 올라갔던 것은 분명했습니다.

저는 그때 처음으로 단순히 “로그를 남겨야 한다”가 아니라,

• 어떤 운영 지표를 보고 싶은가
• 장애가 발생했을 때 무엇을 근거로 원인을 좁혀갈 것인가
• 어떤 로그는 꼭 남겨야 하고, 어떤 로그는 오히려 노이즈가 되는가

같은 질문을 하게 되었습니다.

이 경험은 저에게 중요한 기준 하나를 남겼습니다.

AI는 내 생각을 대신해주는 존재라기보다,
내가 고민해야 할 층위를 더 위로 끌어올리는 도구로 쓸 때 가장 유용하다는 점입니다.

중요한 것은 더 많은 지시가 아니라 더 정확한 맥락과 더 명확한 검증 기준이다

예전의 저는 AI에게 원하는 결과를 얻으려면 세세하게 지시해야 한다고 생각했습니다. 실제로 지금도 꼭 전달해야 하는 배경지식과 맥락은 구체적으로 제공해야 한다고 생각합니다.

다만 이번 글을 읽고 나서는 생각이 조금 바뀌었습니다.

중요한 것은 무조건 더 세세하게 간섭하는 것이 아니라,
내가 반드시 전달해야 하는 맥락과 AI가 스스로 풀어도 되는 영역을 구분하는 일이라는 점입니다.

제가 앞으로 AI에게 꼭 전달해야 한다고 생각하는 것은 이런 것들입니다.

• 문제의 배경과 목적
• 도메인 규칙과 금지 조건
• 수정하면 안 되는 핵심 제약
• 무엇을 성공으로 볼 것인지에 대한 기준

반대로 AI가 비교적 스스로 풀어도 되는 영역은 이런 것들입니다.

• 초안 코드 생성
• 반복적인 구조 정리
• 문서 초안 작성
• 테스트 케이스의 1차 제안

그리고 이 둘 사이를 연결하는 것이 결국 가드레일과 하네스라고 생각합니다.

앞으로 저는 AI를 단순히 채팅처럼 사용하는 것이 아니라, 정의를 먼저 내리고, 검증 기준을 세우고, 가드레일을 만든 뒤에 위임하는 방식으로 프로젝트를 진행해보고 싶습니다.

이 방향은 단순히 AI를 더 많이 쓰겠다는 말과는 조금 다릅니다.

중요한 것은 AI 사용량이 아니라,
AI가 엉뚱한 방향으로 가지 않도록 내가 어떤 경계와 검증 체계를 설계했는가라고 생각하기 때문입니다.

그래서 앞으로는 이렇게 해보려고 한다

이 글을 읽고 나서 제 머릿속에 남은 방향은 비교적 분명합니다.

첫째, AI를 계속 사용해보되 단순한 생산성 도구로만 쓰지 않으려고 합니다.
작은 작업이라도 “이건 어디까지 맡길 수 있는가”, “어디서부터는 내가 붙잡아야 하는가”를 의식적으로 구분하면서 사용해보려고 합니다.

둘째, 도메인과 기본기를 더 단단하게 붙잡으려고 합니다.
AI가 점점 더 많은 구현을 도와줄수록, 결국 차이를 만드는 것은 도메인 이해와 판단이라고 느꼈기 때문입니다. 백엔드 개발자로서 데이터 흐름, 트랜잭션, 정합성, 운영, 장애 대응 같은 영역은 계속 직접 이해하고 설명할 수 있어야 한다고 생각합니다.

셋째, 문서화 능력을 더 중요하게 보려고 합니다.
예전에는 문서를 보조적인 산출물처럼 생각한 적도 있었지만, 지금은 다르게 봅니다. 내가 아는 맥락을 구조화해서 AI와 다른 사람 모두가 이해할 수 있는 형태로 풀어내는 일은 앞으로 더 중요한 실력이 될 것 같습니다.

넷째, 하네스와 가드레일을 두는 방식으로 AI를 써보려고 합니다.
프롬프트를 한 번 잘 쓰는 것보다, 어떤 기준으로 검증하고 어떤 흐름으로 실패를 막을지 설계하는 쪽이 더 중요하다고 느꼈기 때문입니다.

지금 기준으로 앞으로 6개월 동안 제가 실천해보고 싶은 것은 이 정도입니다.

1. 작은 기능이나 문서 작업부터 먼저 AI에게 위임해보고, 어디서 결과가 좋아지고 어디서 맥락이 부족해지는지 기록해보기
2. 프로젝트를 할 때마다 내가 직접 판단해야 하는 영역과 AI에게 맡겨도 되는 영역을 나눠보는 기준 만들기
3. 도메인 문서, 규칙 파일, 체크리스트를 정리하면서 AI가 이해할 수 있는 맥락을 구조화하는 연습하기

여전히 남아 있는 불안도 있다

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

여전히 가장 크게 남아 있는 불안은 주니어 사다리의 붕괴입니다.

결국 주니어도 시니어로 성장하려면 많은 설계와 실패와 맥락을 경험해야 합니다. 그런데 시장은 점점 더 빠른 생산성을 요구하고, 주니어가 천천히 경험을 쌓을 수 있는 자리는 줄어드는 것처럼 느껴집니다.

이런 상황에서 AI가 더 좋아질수록 기업은 더 적은 인원으로 더 많은 일을 하려고 할 수도 있습니다. 그럴수록 주니어가 시행착오를 통해 배우는 기회는 더 줄어들 수 있습니다.

그래서 저도 여전히 불안합니다.

하지만 이번 글을 읽고 적어도 한 가지는 조금 더 선명해졌습니다.

지금 제게 필요한 것은 막연히 뒤처지지 않기 위해 더 조급해지는 것이 아니라,
AI를 실제로 써보면서도 그 안에서 제가 끝까지 붙잡아야 할 것을 더 정확히 구분하는 일이라는 점입니다.

마무리

teo님의 글을 읽기 전까지 저는 AI 시대를 주로 속도의 문제로 바라봤던 것 같습니다.

누가 더 빨리 만들 수 있는지,
누가 더 많은 도구를 먼저 익히는지,
누가 더 생산성을 높일 수 있는지 같은 질문들이 먼저 떠올랐습니다.

그런데 이번 글을 읽고 나서는 관점이 조금 달라졌습니다.

AI 시대의 개발자는 단순히 더 빨리 만드는 사람이 아니라,
무엇을 추상화해서 내려놓고 무엇을 끝까지 붙잡아야 하는지 판단하는 사람이라는 생각이 들었습니다.

특히 주니어 백엔드 개발자인 저에게는 이 관점이 더 중요하게 느껴졌습니다. 도메인 지식이 녹아 있는 비즈니스 로직, 운영에서의 책임, 맥락이 중요한 설계는 여전히 누군가가 직접 이해하고 설명하고 검증해야 하기 때문입니다.

이제는 저도 조금 다르게 개발을 바라보려고 합니다.

코드를 직접 많이 치는가만으로 개발을 정의하지 않고, 문서와 규칙과 검증 기준까지 포함해 AI가 일할 수 있는 환경을 설계하는 것도 개발의 일부로 보려고 합니다.

그리고 그 과정에서 저는 여전히 개발자가 해야 할 일이 많다고 생각합니다.
오히려 더 어려워졌다고 느낍니다.

다만 그 어려움의 종류가 달라졌을 뿐입니다.

앞으로도 AI는 더 좋아질 것입니다.
그래서 제가 붙잡아야 할 경계도 계속 바뀔 것입니다.

그렇다면 지금 제가 해야 할 일은 AI를 두려워하거나 무작정 신뢰하는 것이 아니라, 직접 써보면서 무엇을 위임하고 무엇을 끝까지 책임져야 하는지 판단할 수 있는 개발자가 되는 일이라고 생각합니다.

어쩌면 AI 시대의 개발자에게 더 중요한 질문은
“무엇을 더 빨리 만들 수 있는가”가 아니라
“무엇을 내려놓고, 무엇을 끝까지 붙잡을 것인가”인지도 모르겠습니다.