AI와 함께 다시 코딩하기: 중단했던 사람들이 돌아오는 이유
한때 개발자였지만, 지금은 관리자가 되었거나, 육아와 일상에 치여 키보드는 먼지만 쌓여 있는 분들이 많습니다. 재미있게도, 이들이 하나둘 다시 에디터를 켜고 있습니다. 이유는 단순합니다. 챗GPT, Claude, Codex 같은 AI 코딩 도우미가 생겼기 때문입니다.
이 글에서는 “사람들이 어떻게 AI 덕분에 다시 코딩을 시작하는지”, “예전의 관리 경험과 업무 스킬이 왜 오히려 코딩 에이전트를 다루는 데 강력한 무기가 되는지”를 이야기합니다. 마지막에는 지금 바로 써먹을 수 있는, AI와 함께 다시 코딩을 시작하는 실전 루틴도 정리합니다.
코딩을 그만둔 사람들, 왜 다시 키보드를 잡나
AI 코딩 도구는 이제 개발자들만의 비밀 병기가 아닙니다. MIT Technology Review가 여러 개발자와 리서치를 종합한 결과를 보면, 요즘 AI 코딩 도구는 “코드를 다 대신 짜준다”기보다 “번거롭고 반복적인 부분을 덜어주는 도우미”에 가깝습니다.1
이게 왜 중요할까요?
개발을 그만둔 가장 흔한 이유는 보통 이런 것들입니다.
풀타임 코딩을 하기엔 시간이 너무 부족해졌고
최신 기술 스택을 따라잡는 것도 부담스럽고
몇 년만 쉬어도 감각이 떨어진 느낌이 들기 때문입니다.
그런데 LLM(대형 언어 모델)은 이 세 가지 벽을 동시에 낮춥니다.
과거에 몇 년이라도 코딩을 해본 경험이 있다면, AI에게 다음과 같이만 지시해도 꽤 쓸 만한 결과를 돌려받습니다.
“React로 간단한 사이드 프로젝트 대시보드 만들고 싶은데, 로그인 페이지와 간단한 통계 차트가 나오는 화면까지 뼈대를 만들어줘.”
이전 같으면 반나절은 들었을 기초 세팅을, 이제는 10~20분 안에 “돌아가는 첫 버전”까지 뽑을 수 있습니다. MIT의 한 조사에서, AI 코딩 도구는 특히 보일러플레이트 코드, 테스트 코드, 버그 수정, 기존 코드 설명에서 강점을 보인다고 합니다.1 즉, 다시 코딩을 시작할 때 가장 귀찮고 지루한 부분을 AI가 떠안아 주는 셈입니다.
그래서 요즘엔 이런 패턴이 많습니다.
낮에는 팀이나 프로젝트를 관리하는 관리자
밤이나 주말엔 AI 도우미랑 함께 사이드 프로젝트를 만드는 “하이브리드 개발자”
다시 “풀타임 개발자”가 되는 게 아니라, AI와 함께 “필요한 만큼만 코딩하는 사람”이 되는 것이죠.
LLM 덕분에 가능한 새로운 코딩 방식, ‘바이브 코딩’
최근 연구자들은 이런 스타일을 “바이브 코딩(vibe coding)”이라는 이름으로 부르기 시작했습니다.23 핵심은 간단합니다.
“코드를 한 줄 한 줄 이해하며 짜는 게 아니라,
결과를 확인하고, 안 맞는 부분만 수정하면서
AI와 함께 점점 완성도를 높여가는 방식”
예전의 코딩은 “처음부터 끝까지 내가 짜고, AI는 없으니 모든 책임도 나에게”였다면, 바이브 코딩은 “AI가 초안을 만들고, 나는 요구사항 정의와 검수·조율을 맡는 구조”에 가깝습니다.
이 방식은 특히 다시 코딩을 시작하는 사람에게 매력적입니다.
첫째, 빈 화면 공포가 줄어듭니다.
시작부터 완벽한 구조를 짜려고 애쓰지 않고, AI에게 “대략 이런 기능이 필요하다”고 설명하면 거친 초안이 나오고, 그걸 보면서 감각을 되살릴 수 있습니다.
둘째, 과거의 경험을 “감독 능력”으로 재활용할 수 있습니다.
몇 년간 코드를 안 썼더라도, “좋은 설계가 무엇인지”, “유지보수하기 좋은 구조가 무엇인지”에 대한 감은 남아 있습니다. AI가 제안한 코드를 코드 리뷰하듯 검수하면서 프로젝트를 이끌면 됩니다.
셋째, 학습과 실행이 동시에 일어납니다.
“이 코드 왜 이렇게 짰어? 다른 방법으로 리팩터링해줘.”라고 AI에게 물어보면, 설명과 코드 수정이 한 번에 이뤄집니다. 예전에는 검색 → 블로그 글 → 공식 문서 → 실험까지 거쳐야 했던 과정을, 대화 몇 번으로 해결하는 셈입니다.4
다만 연구에 따르면, AI를 쓴다고 해서 언제나 생산성이 올라가는 것은 아닙니다. 어떤 실험에서는 개발자들이 “AI 덕분에 20% 빨라졌다”고 느꼈지만, 실제 측정 결과는 오히려 19% 느려진 경우도 있었습니다.1
결국 “AI를 어떻게 쓰느냐”가 성패를 가른다는 이야기입니다.
관리 경험이 코딩 에이전트에게 통하는 이유
여기서 흥미로운 포인트가 나옵니다.
AI 코딩 에이전트를 잘 다루는 사람의 특징을 살펴보면, 꼭 뛰어난 알고리즘 실력자만이 아닙니다. 의외로, 이런 사람들도 강합니다.
팀 리더, PM, 매니저
여러 사람의 작업을 조율해 본 관리자
요구사항 정리, 일정 쪼개기, 피드백 주고받기에 익숙한 사람
이유는 간단합니다. “코딩 에이전트를 다루는 일”이 “사람을 관리하는 일”과 매우 비슷하기 때문입니다.2
AI 에이전트를 잘 쓰려면 네 가지가 중요합니다.
첫째, 목표 설정 능력
“로그인 기능 추가해줘”가 아니라
“이메일·비밀번호 로그인, 최소 길이 검증, 실패 시 오류 메시지, JWT 기반 세션 유지”처럼 구체적인 목표를 제시해야 합니다.
사람에게 일을 시킬 때도 마찬가지죠. “대충 잘 알아서 해줘”라고 하면 망합니다.
둘째, 맥락 제공 능력
좋은 관리자는 일을 시킬 때 필요한 배경을 함께 설명합니다.
AI에게도 마찬가지입니다.
지금 사용하는 프레임워크,
배포 환경,
기존에 지켜오던 코드 스타일,
성능이나 보안에 대한 민감도
이런 맥락을 잘 넘겨줄수록 AI 결과물의 품질이 올라갑니다. Tabnine 같은 기업용 AI 코딩 플랫폼은 아예 “회사 고유의 아키텍처와 코딩 규칙을 학습해 그에 맞춰 코드를 제안한다”고까지 강조합니다.5 결국 “맥락 관리”가 성능에 직결된다는 뜻입니다.
셋째, 작업 분할 능력
큰 기능을 한 번에 “다 만들어줘”라고 하면, LLM의 한계 때문에 작업 중간에 맥락을 잃거나 엉뚱한 구조를 만들기 쉽습니다.16
반대로, 관리자가 하듯이 이렇게 쪼개보면 훨씬 수월합니다.
1단계: 기존 코드 베이스 분석
2단계: 변경이 필요한 파일 목록 정리
3단계: 새 기능의 설계안 초안 작성
4단계: 실제 코드 작성
5단계: 테스트 코드 및 리팩터링
Hacker News의 어느 개발자는 실제로 “연구 → 계획 작성 → 컨텍스트 초기화 → 계획 실행 → 테스트 및 리뷰”라는 루프를 반복하면서 복잡한 수정도 20~30분 안에 끝낸다고 말합니다.6 프로젝트 관리하듯 에이전트를 운용하는 전형적인 예입니다.
넷째, 피드백 제공 능력
사람과 일할 때 “이 부분은 좋았고, 이 부분은 수정하자”라고 구체적으로 말해줘야 다음에 더 잘합니다. AI도 거의 같습니다.
“성능은 괜찮은데, 이 부분은 팀 컨벤션이랑 다르다.”
“테스트는 통과하지만, 변수명과 함수명이 지나치게 길다.”
“이번엔 예외 케이스 처리가 빠졌다. 엣지 케이스를 중심으로 다시 짜 달라.”
이렇게 구체적인 피드백과 예시를 주면, 다음 출력에서는 그 피드백이 반영됩니다. LLM 연구에서도 이런 “사람의 피드백(Prefernce/Feedback)”이 성능 향상에 핵심이라는 사실이 반복해서 확인됩니다.42
즉, 그동안 사람을 관리하며 쌓아온 스킬이, 이제는 “AI 에이전트 관리”에도 거의 그대로 적용됩니다. 과거 코딩 실력 + 관리 경험이 합쳐진 사람은 새로운 시대의 “에이전트 리더”가 될 수 있습니다.
다시 코딩을 시작하는 사람을 위한 AI 활용 루틴
이제 “그렇다면 나는 어떻게 시작해야 하지?”가 궁금해질 차례입니다. 완전히 처음부터 공부하듯 접근하면 금방 지칩니다. 대신, 아래와 같은 루틴을 추천합니다.
1단계: 아주 작은 목표부터 정하기
“앱 하나 만들어야지” 같은 거창한 계획보다, 1~2시간 안에 끝낼 수 있는 작은 목표를 잡아보세요.
예를 들어:
“나만 쓰는 가계부 웹 페이지 만들기”
“아이 학원 스케줄을 관리하는 캘린더 만들기”
“팀 주간 회의 안건을 자동으로 정리하는 슬랙 봇 만들기”
작을수록 좋습니다. 중요한 것은 “실제로 돌아가는 무언가를 완성해본 경험”입니다.
이 목표를 AI에게 그대로 설명해 주세요.
“React로, 나만 쓰는 간단한 가계부를 만들고 싶은데, 수입/지출 내역을 입력하고 월별 합계를 볼 수 있는 페이지까지만 우선 만들고 싶어.”
이 정도만 던져도, AI는 기본 구조, 컴포넌트 분리, 상태 관리 방식까지 어느 정도 제안해 줍니다.
2단계: AI에게 ‘설계부터 같이 하자’고 제안하기
바로 코드를 달라고 하기보다, 설계부터 함께 하는 것이 좋습니다. 앞으로 유지보수할 사람은 결국 나니까요.
예를 들어 이런 식입니다.
“바로 코드부터 짜지 말고,
필요한 기능 목록,
어떤 컴포넌트로 나누면 좋을지,
데이터 구조 예시,
를 먼저 정리해줘.”
이렇게 하면 AI는 설계 문서를 먼저 써줍니다. 마음에 안 드는 부분은 이 단계에서 수정 요청을 합니다.
“모바일에서도 쓸 거라서, 반응형 디자인 고려해줘.”
“로컬에만 저장하고, 서버는 없이 시작하고 싶어.”
설계 합의를 마치고 나면, “이제 이 설계대로 코드를 작성해줘.”라고 이어가면 됩니다.
바이브 코딩 연구에서도, 이렇게 “계획 중심(Planning-Driven) 모델”이 실전에서 자주 쓰이는 패턴이라고 정리합니다.2
3단계: 코드 품질은 ‘테스트와 결과’로 판단하기
다시 코딩을 시작한 사람에게 가장 큰 불안은 “이 코드가 맞는 건가?”라는 의심입니다. 이때 AI의 장점을 최대한 활용하세요.
“지금까지 작성한 코드 기준으로, 최소한의 유닛 테스트를 만들어줘.”
“엣지 케이스를 중심으로 테스트 목록을 만들어줘.”
테스트 코드는 AI가 특히 잘하는 영역입니다.15 테스트를 통과하는지, 실제 UI가 의도대로 작동하는지를 기준으로 판단하면, 코드 한 줄 한 줄을 완전히 이해하지 못해도 안심할 수 있습니다.
물론 장기적으로는 코드 이해도 중요하지만, “다시 코딩을 시작하는 초기”에는 결과 기준으로 자신감을 회복하는 것이 훨씬 중요합니다.
4단계: 모르는 부분은 “검색 대신 대화”로
옛날에는 모르는 게 나오면 검색창부터 열었지만, 이제는 바로 AI에게 묻는 편이 훨씬 빠릅니다.4
“이 부분에서 useEffect를 이렇게 쓴 이유를 설명해줘.”
“이 코드를 리팩터링해서 더 읽기 쉽게 만들어줘.”
“이 함수의 시간 복잡도를 분석해줘.”
AI에게 설명을 요구하고, 필요하면 “초보 개발자에게 설명하듯이” 같은 조건을 붙입니다. 관리 경험이 있는 분이라면, “신입에게 설명하듯이, 단계별로, 예시를 곁들여”라고 요구해보는 것도 좋습니다.
이 과정에서, 과거에 갖고 있던 개념이 빠르게 되살아납니다.
5단계: 주기적으로 ‘리팩터링 스프린트’를 잡기
AI가 만들어 준 코드는 종종 “돌아는 가지만 아름답지 않은” 경우가 많습니다.16 함수가 쓸데없이 길거나, 중복 코드가 많거나, 프로젝트 컨벤션과 어긋나는 식이죠.
한 번에 완벽을 바라지 말고, 일정 간격으로 리팩터링 스프린트를 잡으세요.
“이 파일 전체를 팀 컨벤션에 맞춰 정리해줘.”
“중복 코드를 제거하고, 함수 분리를 통해 가독성을 높여줘.”
“객체지향 스타일로 바꿔줘 / 함수형 스타일로 정리해줘” 등
Hacker News의 한 개발자는 아예 “Clean Code 스타일로 코드 정리해줘”라는 프롬프트를 저장해두고, AI가 만든 코드를 나중에 한 번에 다듬는다고 합니다.6 리팩터링은 예전 개발 경험이 빛을 발하는 부분이기도 합니다. AI가 제안한 리팩터링을 보고, 괜찮은 부분만 채택하면 됩니다.
앞으로의 코딩: “코드를 짜던 사람”이 아니라 “에이전트를 이끄는 사람”
AI 코딩 도구는 이미 기업 현장 깊숙이 들어와 있습니다. 어떤 기업은 자체 코드 기준과 아키텍처를 반영한 기업용 에이전트를 쓰고 있고,5 어떤 조직은 아예 AI 코딩 도구로 자기 도구를 개선하는 “자기 강화 루프”를 만들기도 합니다.7
연구자들은 이런 흐름을 분석하며, 개발자의 역할이 “코드를 직접 짜는 사람”에서 “에이전트와 시스템을 설계하고 관리하는 사람”으로 변화하고 있다고 봅니다.23
이 변화 속에서, 과거에 코드를 짜봤고, 사람도 관리해봤던 여러분은 의외로 큰 강점을 갖고 있습니다.
요구사항을 정리하고
전체 그림을 그리며
일을 나누고
결과물을 검수하고
피드백을 주는 능력
이건 이미 여러 프로젝트에서 해오던 일입니다. 단지, 이제는 그 대상에 “AI 코딩 에이전트”가 추가될 뿐입니다.
지금 중요한 건 “내가 예전처럼 풀타임 개발자로 돌아갈 수 있을까?”가 아닙니다.
대신 이렇게 물어보면 어떨까요?
“내가 가진 도메인 지식과 관리 경험, 그리고 AI 코딩 도구를 합치면,
어떤 새로운 것들을 만들어 볼 수 있을까?”
에디터를 켜고, 작은 목표 하나를 AI에게 설명해보세요.
돌아가는 첫 화면이 뜨는 순간, 예전에 느꼈던 그 짜릿함이 다시 돌아올지 모릅니다.
참고
1AI coding is now everywhere. But not everyone is convinced. | MIT Technology Review
4Scaling LLMs to Larger Codebases | Hacker News
5OpenAI built an AI coding agent and uses it to improve the agent itself | Ars Technica