요즘 개발자 커뮤니티에서 자주 들리는 이야기입니다.
“요즘은 코드를 직접 안 짜게 돼.”
“AI가 더 잘 짜더라. 그냥 프롬프트만 잘 쓰면 끝나.”
과장이 아닙니다.
최근 등장한 AI 코딩 툴들(ChatGPT, GitHub Copilot, Cursor, Windsurf 등)은 CRUD 중심의 단순한 기능 구현 정도는 몇 문장만으로도 손쉽게 처리해냅니다. 몇 년 경력으로 축적된 코딩 노하우가 이제는 자연어 몇 줄로 대체되는 상황입니다.
하지만, 그렇게 만들어진 코드들… 실제 제품에 써도 괜찮을까요?
“바이브코딩”? 농담 같던 말이 현실이 됐다
2025년 초, 안드레이 카파시(Andrej Karpathy)가 처음 ‘Vibe Coding’이라는 용어를 썼을 때만 해도 반응은 반신반의였습니다.
“AI가 짜주는 코드의 흐름을 사람은 감으로 따라가기만 하면 된다”는 식의 개념은 그저 과장된 말처럼 보였죠.
하지만 지금, 그 말은 더 이상 과장이 아닙니다.
AI는 실제로 많은 개발자들의 손을 거치지 않고 코드를 생성하고 있으며, “AI를 얼마나 잘 다루느냐”가 생산성과 직결되는 시대가 왔습니다. 개발자는 이제 도구를 능숙하게 ‘타이핑’하는 사람에서, 도구를 ‘디렉팅’하는 사람으로 진화하고 있습니다.
AI 시대, 개발자는 정말 필요 없을까?
AI가 코드를 대체하고 있는 것은 사실입니다. 그러나 개발자가 불필요해졌다고 보기는 어렵습니다. 단지 역할의 중심축이 달라지고 있을 뿐입니다. 예전에는 직접 코드를 작성하는 것이 개발자의 핵심 역량이었다면, 이제는 AI가 생성한 코드를 읽고, 판단하고, 방향을 설정하는 능력이 더 중요해졌습니다.
개발자는 더 이상 ‘손으로 벽돌을 쌓는 사람’이 아닙니다.
이제는 전체 건물을 설계하고 공정을 조율하는, 일종의 ‘현장 총감독’에 가까운 역할로 바뀌고 있습니다.
개발자의 새로운 두 얼굴: 건축가와 에디터
AI가 코드를 대체하고 있는 것은 사실입니다. 그러나 개발자가 불필요해졌다고 보기는 어렵습니다. 단지 역할의 중심축이 달라지고 있을 뿐입니다. 예전에는 직접 코드를 작성하는 것이 개발자의 핵심 역량이었다면, 이제는 AI가 생성한 코드를 읽고, 판단하고, 방향을 설정하는 능력이 더 중요해졌습니다.
개발자는 더 이상 ‘손으로 벽돌을 쌓는 사람’이 아닙니다.
이제는 전체 건물을 설계하고 공정을 조율하는, 일종의 ‘현장 총감독’에 가까운 역할로 바뀌고 있습니다.
1. 건축가(Architect)형 개발자: 구조를 설계하는 사람
AI는 모듈 하나, 함수 하나 등 작은 단위의 코드 생성에는 강하지만, 전체 그림을 그리진 못합니다. 어떤 모듈이 어떤 책임을 질지, 비즈니스 플로우는 어떤 식으로 흐를지, 장애 상황에서는 어떻게 복구할지에 대해서는, 사람이 직접 생각하고 설계해야 합니다.
AI는 “어떻게 짤지”는 알려줘도, “무엇을 짜야 할지”는 모릅니다. 게다가 항상 ‘정상 작동’만 가정합니다. 실제 운영 환경처럼 예외가 튀고, 요청이 몰리고, 버전이 꼬이는 상황에서는 누군가 설계를 잘해두어야 합니다. 그게 바로 건축가형 개발자의 몫입니다.
2. 에디터(Editor)형 개발자: AI가 만든 코드를 다듬는 사람
이제 개발자의 업무는 ‘직접 짜는 것’보다 ‘제대로 돌아가게 만드는 것’에 더 가깝습니다.
실제로 AI가 짜주는 코드를 보면 돌아는 가는데 구조가 엉망이거나 보안 구멍이 있거나, 팀 컨벤션을 무시한 경우가 많습니다. 쓸데없이 반복되는 로직, 하드코딩된 API 키, 테스트 커버리지 0%… 이런 코드들을 리뷰하고 정제하며 실제 운영 수준까지 끌어올리는 작업은 여전히 사람의 몫입니다. 앞으로는 “무엇을 만들 것인가”보다 “무엇을 고쳐야 하는가”를 판단하는 눈이 더 중요해질 것입니다.
단순 코딩은 AI가, 책임은 사람이 진다
AI 코딩 도구는 정말 빠릅니다. 단 몇 줄로 전체 서비스의 뼈대를 뽑아주고, UI도 만들어주고, API도 붙여줍니다. 그 하지만 그 코드가 서비스에 바로 투입될 수준인가? 대부분의 경우, 그 대답은 ‘아니다’에 가깝습니다. 그 안에는 종종 다음과 같은 이슈가 숨어 있습니다:
- 보안 취약점 (SQL 인젝션, 하드코딩된 크리덴셜)
- 성능 문제 (불필요한 반복 로직, 메모리 낭비)
- 저작권 침해 (라이선스 위반 코드 재현)
- 내부 소스코드 유출 위험 (클라우드 LLM 사용 시)
때문에 큰 기업일수록 GitHub Copilot 같은 툴을 막거나, 자체 LLM을 개발해서 내부망에서만 쓰는 식으로 대응하고 있습니다. (대표적으로 삼성전자의 ‘Gauss’가 있습니다.)
물론 이런 접근은 상당한 비용과 인프라, 전문 인력을 필요로 하기 때문에 모든 기업이 선택하기는 어렵습니다. 특히 보안이 중요한 산업군에서는 외부 AI 도구 사용에 제약이 많기 때문에, 로컬 환경에서 자체적으로 LLM을 운영할 수 있는 대안들이 필요해지고 있습니다.
최근에는 GPU 인프라만 있다면 인터넷 없이도 사내 LLM을 배포해 운영할 수 있는 솔루션이 등장하여 크게 주목받고 있는데, CodeCenter와 같은 에어갭 환경에서도 완전히 독립적으로 실행 가능한 플랫폼은 보안 요구사항이 높은 조직이나 민감 데이터를 다루는 팀에서 검토되고 있습니다.
앞으로 개발자가 준비해야 할 것
구조 설계 능력:
시스템의 큰 그림을 보고, 각 부분이 어떻게 연결돼야 하는지를 설계할 수 있어야 합니다.
코드 감수 능력:
AI가 짜준 코드를 보고, 잘못된 부분을 발견하고 개선하는 눈을 길러야 합니다.
보안 · 윤리적 판단:
AI가 제안한 코드의 출처와 법적·보안적 문제 가능성을 사전에 점검할 수 있어야 합니다.
마치며 – 우리는 어디로 가고 있는가
MS Excel이 처음 나왔을 때, 사람들은 사무직이 사라질 거라고 했습니다. 실제로 단순 계산 업무는 줄었지만, 엑셀을 잘 다루는 데이터 분석가와 전략가는 더 각광받게 됐습니다.
개발도 마찬가지입니다.
반복적인 코딩 자체는 점점 자동화되겠지만, 무엇을 만들고, 어떻게 연결하고, 어디까지 책임질지를 아는 사람은 여전히 필요하고, 오히려 더 중요해질 것입니다.
“코드는 AI가 짜지만, 그 코드에 책임지는 건 결국 사람입니다.”
바로 우리가 해야 할 일은, 그 책임을 질 수 있는 개발자로 성장하는 것입니다.
Referenced from
