AI가 코드를 짜도 남는 것: 기본기와 설계
AI 코딩 도구가 코드를 거의 다 써 주는데 백엔드 개발자로 계속 가도 되는지 고민 중이라면 같이 읽어 볼 만한 글이 있습니다. 2026년 10월 27일 네이버 D2에 올라온 정상혁 님의 「AI 시대의 개발자를 꿈꾸는 학생 개발자에게」입니다. 학생에게 쓴 글이지만 연차가 쌓인 개발자에게도 「AI 시대에 개발자가 실제로 하는 일」과 「무엇을 공부해야 하는지」를 구체적으로 짚어 줍니다. 이 글에는 5년차 백엔드 개발자인 제가 그 글을 읽으며 공감한 부분과, 읽고 나서 정한 공부 계획을 적었습니다.
결론부터 말하면 AI가 실행을 맡을수록 개발자에게 남는 일은 기본기와 설계 판단이었고, 저는 오픈소스 기여로 기본기를, 작은 시스템 설계 연습으로 아키텍처를 다지기로 했습니다.
5년차에 진로를 다시 고민하게 된 이유
5년차가 되면서 AI 도입 때문에 진로 고민이 많아졌습니다. 요즘은 AI 코딩 에이전트에게 맡기면 기능 하나가 금방 나옵니다. 그동안 쌓은 구현 경험이 앞으로도 경쟁력이 될지, 백엔드라는 직군이 그대로 남을지 확신이 서지 않았습니다.
원문 저자도 같은 질문 앞에서 답을 단정하지 않습니다. 이 글을 「목적지가 명확한 안내서보다는 격변기의 스냅샷」으로 봐 달라고 하고, 지금의 취업 한파를 어떻게 봐야 할지 모르겠다고도 적었습니다. 2018년에 쓴 전편 제목은 「백엔드 개발자를 꿈꾸는 학생개발자에게」였는데, 이번에는 제목에서 「백엔드」를 뺐다고 합니다. 진로를 특정 레이어나 기술 스택으로 좁히지 말라는 뜻입니다.
답을 주는 글은 아니지만 고민할 방향을 정리하는 데는 도움이 됐습니다. 특정 기술 스택을 다룬다는 사실만으로는 차별화가 어려워진다면, 연차가 쌓여도 남는 것은 무엇인지를 따져 보게 됐습니다.
다시 확인한 것: 기본을 모르면 AI에게 질문도 못 한다
글을 읽으면서 가장 많이 든 생각은 역시 기본이 가장 중요하다는 것이었습니다. 원문에는 기본기가 왜 필요한지 보여 주는 예가 두 개 나옵니다.
첫째는 N+1 쿼리입니다. 목록을 가져온 뒤 한 건마다 DB를 다시 조회하는 패턴인데, AI는 이 코드가 운영 환경에서 문제없는 수준이라고 주장했습니다. 저자는 배포될 환경을 고려하면 그 기준을 받아들일 수 없었다고 씁니다. AI가 내놓은 기준보다 높은 기준을 세우려면, 그 기준이 왜 필요한지 설명할 지식이 사람에게 있어야 합니다.
둘째는 0.1 같은 소수를 2진수로 표현할 때 생기는 오차입니다. 1991년 패트리어트 미사일 요격 실패와 2011년 교육행정정보시스템(NEIS) 석차 오류가 모두 이 오차를 보정하지 못해 일어났다고 합니다. 원문은 이 지식을 모르면 AI에게 「이 금액 계산에 부동소수점 오차가 문제를 일으킬 여지는 없는가」라고 물어볼 수조차 없다고 지적합니다.
저도 실무에서 AI가 만든 코드를 리뷰할 때 같은 경험을 합니다. 문제를 알아야 질문을 하고, 질문을 해야 AI가 고칩니다.
여기서 말하는 기본에는 기술 지식만 들어가지 않습니다. 도메인 지식도 들어간다는 것을 저는 실무에서 낸 이슈로 배웠습니다. 회사 업무를 하다가 공통 로직을 고쳐야 했던 적이 있습니다. 제가 맡은 기능만 놓고 보면 고치는 것이 맞아 보였고 코드만 읽어서는 문제가 될 곳이 보이지 않았습니다. 그런데 그 로직은 도메인 전반에서 공통으로 쓰이고 있었고 다른 기능들은 기존 동작을 전제로 돌아가고 있었습니다. 그 전제를 모른 채 수정했고 배포 뒤 이슈가 올라왔습니다.
다시 고칠 때는 제가 손댄 공통 로직을 롤백해 기존 동작으로 되돌렸습니다. 그리고 제 기능도 새로 고친 로직 대신 그 기존 공통 로직을 그대로 재활용하는 방식으로 다시 만들었습니다.
원문은 어디서 어떤 방식으로 호출될지 모르는 공통 모듈에 가까울수록 개발자가 코드를 세세하게 이해해야 한다고 말합니다. 조직의 암묵적인 전제는 AI가 초안에 담기 어려운 정보라고도 합니다. 제가 놓친 것이 바로 그런 전제였습니다. 코드 어디에도 「이 로직은 여러 기능이 이 동작을 믿고 쓴다」고 적혀 있지 않았습니다. 같은 수정을 AI에게 맡겼더라도 그 전제를 알려 주지 않았다면 같은 방향으로 고쳤을 가능성이 큽니다. 이 일 이후로는 공통 로직을 건드리기 전에 호출하는 곳부터 찾아봅니다. AI에게 일을 맡길 때도 같은 확인을 먼저 하라고 적어 둡니다.
AI가 실행되는 코드는 만들어 주지만 문제없는 코드인지 판단하는 일은 기본기와 도메인 지식을 갖춘 사람의 몫으로 남아 있습니다.
「작업자」를 「AI 에이전트」로 바꿔 읽은 일곱 줄
원문에서 가장 오래 붙들고 있던 부분은 아래 목록입니다. 저자는 이제 조직의 말단 작업자는 AI이고 모든 개발자는 AI 팀의 관리자가 됐다고 하면서, 전통적인 관리자의 일을 이렇게 나열합니다. 그리고 「작업자」를 「AI 에이전트」로 바꿔 읽으면 이제는 모든 개발자가 하는 일이라고 말합니다.
- 다수의 작업자에게 목표와 배경, 추구하는 가치, 평가 기준을 제시한다.
- 작업자의 정보 탐색 비용을 줄여 준다.
- 참조할 정보가 어디에 있는지 알려 준다.
- 작업자별 역할을 명확히 정의하여 할 일을 분배한다.
- 작업자별 장점과 투자액(과금액) 수준을 고려하여
- 각자의 작업에 집중할 수 있도록, 컨텍스트가 과도하게 넓어지지 않고 컨텍스트 전환이 최소화되도록
- 의사결정자와 작업자 간의 효율적인 피드백 사이클을 구축한다.
— 정상혁, 「AI 시대의 개발자를 꿈꾸는 학생 개발자에게」, 네이버 D2, 2026-10-27
실무에서 AI를 쓰면서 이 일곱 줄을 뼈저리게 느끼고 있습니다. 돌아보면 제가 AI 코딩 도구 설정 파일에 적어 둔 규칙이 거의 그대로 이 목록에 대응합니다.
| 원문의 관리자 일 | AI 에이전트에게 실제로 적어 둔 규칙 |
|---|---|
| 목표·배경·평가 기준 제시 | 작업을 시작할 때 「완료 조건」을 한 문장으로 먼저 쓰게 한다. 한 문장으로 못 쓰면 작업을 쪼갠다 |
| 정보 탐색 비용 줄이기 | 빌드 결과물이나 의존성 폴더처럼 읽을 필요가 없는 디렉터리는 열지 말라고 적어 둔다 |
| 참조할 정보의 위치 | 폴더마다 무엇이 들어 있는지, 원본은 어디이고 결과물은 어디에 두는지를 문서 맨 앞에 둔다 |
| 역할 정의와 분배 | 코드 위치 찾기, 한두 파일 수정, 변경 리뷰를 서로 다른 에이전트에게 나눠 맡긴다 |
| 장점과 과금액 고려 | 단순한 일을 맡는 에이전트는 더 저렴한 모델로 고정하고 한 작업에 띄우는 에이전트 수에 상한을 둔다 |
| 컨텍스트를 좁히고 전환을 줄이기 | 같은 파일을 반복해서 읽는 신호가 보이면 실패한 명령과 관련 파일 몇 개만 들고 새 세션을 시작한다 |
| 효율적인 피드백 사이클 | 멈추고 사람에게 물어야 하는 경우를 두 가지로 정해 두고, 같은 방법이 두 번 실패하면 세 번째 시도 전에 보고하게 한다 |
처음부터 이렇게 설계한 것은 아닙니다. 에이전트가 엉뚱한 파일을 뒤지느라 시간을 쓰거나, 범위를 넘어 고치거나, 같은 실패를 반복할 때마다 한 줄씩 늘어난 규칙입니다. 원문을 읽고 나서야 이 규칙들이 결국 관리자가 팀원에게 해 주던 일이라는 것을 알았습니다.
이 목록은 이 사이트에서 연재 중인 「에이전트 하네스를 직접 만들어 본다」 시리즈와도 이어집니다. 하네스(harness)는 모델 바깥에서 모델을 호출하고 대화를 들고 있고 도구를 실행해 주는 코드입니다. 원문도 AI 에이전트의 불확정성을 줄이는 하네스 기법들이 대부분 리뷰와 테스트 지시를 포함한다고 언급합니다. 모델이 도구 실행을 요청만 하고 실제 실행은 하네스가 맡는 과정은 시리즈의 도구 호출 편에서 실행 로그로 따라가 볼 수 있습니다.
기본기와 관리자 역할을 더 잘하려면: 오픈소스 기여
읽고 나서 남은 질문은 「기본기와 위의 일곱 줄을 어떻게 하면 더 잘하게 될까」였습니다. 저는 오픈소스 프로젝트에 기여하면서 기본을 공부하기로 마음먹었습니다.
오픈소스를 고른 이유는 원문에서 찾았습니다. 첫째, 원문은 직접 짜지 않은 대량의 코드를 빠르고 정밀하게 이해하기 어렵다고 말합니다. AI가 쓴 코드를 리뷰하는 일도 결국 남이 짠 코드를 읽는 일입니다. 잘 관리되는 오픈소스 코드베이스를 읽고 고쳐 보는 것은 그 능력을 기르는 가장 직접적인 연습이라고 봤습니다.
둘째, 원문은 혼자 공부하면 자신이 무엇을 잘못 알고 있는지조차 알기 어렵다며, 피드백을 줄 수 있는 동료를 강조합니다. 그 방법으로 스터디 그룹, 작은 사이드 프로젝트와 함께 오픈소스 기여를 꼽습니다. 메인테이너의 리뷰는 AI의 리뷰와 달리 그 프로젝트가 지켜 온 기준을 담고 있습니다.
셋째, 원문은 검색해서 읽는 데서 멈추지 말고 자신의 언어로 다시 설명하고 써 봐야 응용할 수 있는 지식이 된다고 말합니다. 기여 과정에서 이해한 내용은 이 블로그에 글로 다시 정리할 생각입니다.
아키텍처 설계가 실력을 가르는 기준이라는 말에 공감한 이유
원문에서 가장 공감한 부분은 아키텍처 설계 공부입니다. 저는 아키텍처 설계 능력이 실력 있는 개발자와 그렇지 않은 개발자를 가르는 기준이 된다고 느낍니다.
현장에서 많은 시니어 개발자를 만나 본 것은 아닙니다. 그래도 업무를 하면서 아키텍처를 잘 설계하는 개발자가 회사가 좋아하는 결과, 예를 들어 비용 최적화를 만들어 내고, 그런 개발자가 더 대우받는다는 것을 느꼈습니다.
원문을 읽고 나니 이 차이가 AI 시대에 더 벌어질 것 같습니다. 원문은 모듈 경계가 분명하면 에이전트가 고칠 범위를 좁게 잡지만, 경계가 흐리면 비슷한 코드를 여기저기 복제한다고 설명합니다. 같은 AI를 써도 설계가 좋은 코드베이스에서는 결과가 좋아지고 설계가 나쁜 코드베이스에서는 기술부채가 빨리 쌓인다는 뜻입니다. 비용도 마찬가지입니다. 원문은 회사가 AI에 쓰는 지출이 늘면서 투자 대비 효과를 더 엄격하게 평가하게 되고, 모든 코드를 높은 트래픽 기준에 맞춰 만들면 오버엔지니어링이자 토큰 낭비라고 지적합니다. 어디에 높은 기준을 적용하고 어디는 단순하게 둘지 정하는 판단이 곧 설계이고, 그 판단이 회사의 인프라 비용과 AI 사용료를 함께 좌우합니다.
공부 방법도 원문의 제안을 따르려고 합니다. 이미 다루는 작은 시스템에서 「왜 이렇게 구성했는가」를 스스로 설명해 보고, 가정을 하나씩 얹어 구조가 어떻게 바뀌어야 하는지 그려 보는 것입니다. 예를 들면 이렇습니다.
- 지금 서버가 한 대인데 이 서버가 죽으면 무엇이 멈추는가. 이 단일 장애점을 없애려면 무엇을 바꿔야 하는가
- 사용자가 지금의 백 배로 늘어나면 어디가 먼저 막히는가
- 데이터가 DB 한 대에 담기지 않으면 어떻게 나눌 것인가
원문은 실무자도 모든 경우를 경험해 보고 설계하지는 않는다면서, 지금 필요한 만큼만 단순하게 설계하고 필요가 생기면 다음 단계를 그려 가는 태도가 좋은 아키텍트의 자질이라고 말합니다. 완벽한 설계를 미리 알아야 한다는 부담을 덜어 준 문장이었습니다.
읽고 나서 정한 것
- 기본기: 오픈소스 프로젝트 하나를 정해 코드를 읽고 작은 이슈부터 기여한다. 이해한 내용은 이 블로그에 다시 쓴다
- 관리자 역할: AI 에이전트에게 적어 둔 규칙을 위의 일곱 줄 기준으로 다시 점검하고 빠진 칸을 채운다
- 아키텍처: 지금 다루는 시스템 하나를 골라 「서버가 죽으면」, 「사용자가 백 배가 되면」 같은 가정을 하나씩 얹어 구조를 그려 본다
원문: 정상혁, 「AI 시대의 개발자를 꿈꾸는 학생 개발자에게」, 네이버 D2, 2026-10-27. 인용한 목록 외의 내용은 요약해서 옮겼습니다. 원문에는 여기서 다루지 않은 취업·진로·추천 도서 이야기가 더 있습니다.