코딩의 고뇌가 사라진 시대: 나는 개발자가 맞는가?

AI에이전트를 신나게 쓰면서도 참… 찝찝하다.

요즘 컴퓨터를 켜서 제일 먼저 실행하는 게 Intellij나 VSCode가 아니게 된 지가 꽤 됐다. 그 자리를 Cursor가 채웠다.

예전엔 빈 index.tsx 화면에 깜빡이는 커서를 보면 일단 커피 두 모금, 한 숨 한 번, 대충 내가 짰던 예시 코드 긁고 지우기 이걸 무한 반복했다. (시작이 제일 빡셌다. 항상)

“하… 이 껍데기를 언제 다 짜냐. 컴포넌트 구조는 또 어떻게 잡지?”

근데 지금은? 고민할 시간이 없다. 그냥 Cursor Agent 대화창 누르고 건방지게 명령만 내리면 된다.

“로그인 페이지 만들어줘. Next.js랑 Tailwind 쓰고, 모바일 반응형까지 싹 다.”

엔터 치면? 1초 뒤에 코드가 미친 듯이 쏟아진다.

내가 3일 동안 끙끙대며 짤 레이아웃이 30초 만에 튀어나온다.

에러? 터미널에 붉은 글씨 뜨면 바로 “Fix it” 딸깍. 그럼 지가 알아서 고친다.

솔직히 처음엔 지렸다. “와 씨, 나 이제 생산성 미쳤네 ㅋㅋ 걍 하루 30분만 일해도 되는 거 아님?”

밀키트 뜯어서 냄비에 붓기만 했는데, 내가 미슐랭 셰프가 된 기분이었다.

근데 이게 계속되니까… 기분이 좀 묘하다.

요즘 내가 블로그에 주구장창 이런 관련된 이야기를 올리는게 그 이유다.

너무 편리한데… 자꾸만 불안해져서 이렇게 글이라도 써야 조금 덜 불안해진다.

‘고뇌의 공백’이 가져온 불안함

개발자라면 다들 알 거다.

변수명 하나 짓는 데 10분 쓰고, useEffect 의존성 배열 때문에 머리 쥐어뜯는 그 지루한 시간들.

우리는 그걸 삽질이라 부르지만, 사실 그게 근육을 만드는 과정이었다.

근데 Cursor가 들어오면서 그 ‘정적’의 시간이 증발했다.

로직을 씹고 뜯고 맛보고 즐길 새도 없이 결과물이 내 눈앞에 떡하니 놓인다.

편하긴 엄청나게 편하다. 야근도 안하고, 오히려 업무 시간에 멍 때리는 시간이 많아졌다.

근데 문득 이런 생각이 든다.

“이 코드, 내가 알고는 있는게 맞나?”

마치 내비게이션 없으면 동네 마트도 못 찾아가는 길치 운전자가 된 기분이다.

이제 프롬프트 없이는 reduce 함수 하나 짜는 것도 귀찮아하는, ‘생각의 근육’이 다 빠져버린 물살 개발자가 되어가는 건 아닐까?

가트너의 살벌한 예언

주말 아침에 커서를 돌려놓고, 가트너(Gartner)가 최근에 낸 Software Engineering 2030: Impact of AI 보고서를 읽었다.

결론부터 말하면, 단순 코더(Coder)는 멸종한다는 소리다.

1. 코딩은 이제 ‘개나 소나’ 다 한다

가트너 보고서의 핵심이 뭐냐면,

AI가 개발자의 역할을 ‘작성자(Author)‘에서 ‘감독관(Supervisor)‘으로 강제로 이동시키고 있다.

2027년까지 개발자의 80%가 업무 방식을 뜯어고쳐야 한단다. 왜? AI가 코드를 쏟아내기 시작하면서 코드 작성 자체의 가치는 떡락했으니까.

이제 “나 리액트 잘 써요”, “C#으로 게임 몇 개 만들어봤어요.”는 자랑이 아니다.

그건 AI가 더 잘하니까.

2. 80%의 개발자가 ‘재교육’ 없으면 도태된다

보고서에서 아주 뼈를 때리더라.

AI가 엔지니어링 라이프사이클 전반에 침투하면서, AI-Native Software Engineering 역량이 필수가 된단다.

단순히 “프롬프트 잘 쓰는 법” 수준이 아니다.

AI가 짠 코드 검증 능력
RAG(검색 증강 생성) 아키텍처 설계 능력
AI 에이전트 오케스트레이션 능력

이거 못 하면?

그냥 Legacy 인간 취급받는 거다.

3. 보안은 더 지옥이다 (Snyk & Lasso Security)

가트너만 겁주는 게 아니다. 보안 쪽은 더 심각하다.

Snyk 2024 리포트: 개발자의 80%가 AI를 쓰지만, 59%는 AI가 만든 보안 구멍을 무서워한다. (머리랑 손이 따로 노는 중)
Lasso Security: AI가 존재하지도 않는 패키지를 import 하라고 구라를 치는 ‘패키지 환각’ 비율이 21%나 된다. 이거 그대로 썼다간 해커한테 문 열어주는 꼴이다. (실제로 이거 노리고 AI가 환각에 빠져 불러올 없는 패키지를 만들어서 그걸 다운 받는 순간 악성 코드가 설치되도록 하는 공격이 있다고 한다.)

4. 나는 무엇을 해야 하는가?

그렇다고 다시 예전처럼 한 땀 한 땀 코딩하는게 정답인가?

절대 아니다. 그건 멍청한 짓이다. 안 쓰면 도태되는 건 팩트니까.

대신 태세를 전환해야 한다.

가트너 형들이 말한 대로 감독관이 되어야 한다.

구현(Implementation)의 고뇌는 AI한테 던져라.

그리고 검증을 하자.

근데 말이 쉽지… 어떻게?

5. AI 코드, 어떻게 “검증”할 것인가?

감독관이 되려면 검수 기준이 있어야 한다.

제1방어선: TDD (Test-Driven Development)의 부활

순서를 바꿔야 한다.

AI한테 코드를 짜라고 하기 전에, 테스트 코드부터 짜게 하자.

How: “기능 짜줘” 하지 말고, 이 기능 테스트 케이스(Unit Test)부터 짜줘라고 해라. 네가 그 테스트만 쓱 훑어보고(본 코드보다 훨씬 읽기 쉬우니까), 이거 통과하는 코드 짜라고 명령해라.
Why: 테스트 코드가 AI에게 가장 명확한 작업 지시서가 된다.

제2방어선: 정적 분석(Static Analysis) 도구로 ‘기계적 검증’

AI가 짠 코드를 하나하나 리뷰하겠다고? 그냥 “불가능”하다.

How: ESLint, Prettier는 무조건 Strict Mode로 돌리고 SonarQube나 Snyk 같은 도구를 CI/CD에 박아둬서 최소한의 기계적 검증을 하자.
Why: AI의 ‘패키지 환각’이나 ‘보안 취약점’은 눈으로 못 잡는다.(적어도 나는 그렇다.) 기계로 조져야 한다.

제3방어선: ‘설명 요구(Reverse Explanation)‘를 통한 취조

코드가 100줄 넘어가서 눈에 안 들어온다? 억지로 읽지 마라. AI를 취조해라.

How: Cursor 채팅창에 코드 드래그하고 물어보자. “이거 한 문장으로 요약해봐.” 혹은 “여기서 발생할 수 있는 엣지 케이스(Edge Case) 3가지만 대봐.”
Why: 만약 AI가 설명을 버벅거리거나 헛소리를 한다? 그 코드는 논리적으로 꼬여있을 확률이 99%다.

제4방어선: ‘분할 정복’ - 한 번에 100줄 이상 금지

How: 명렬을 마치 레고 블록 조립하듯이 내리자. (유효성 검사 -> API 호출 -> UI). 이게 CDD(Component-Driven Development)의 핵심이다.
Why: “로그인 페이지 전체 다 만들어줘”라고 하면 검증 불가능한 500줄짜리 예쁜 쓰레기가 나온다.

결론: 왜 ‘감독관’이 되어야 하는가?

앞서 말한 4가지 방어선으로 AI를 검증하고 하는 깐깐한 ‘감독관’이 되어야 하는 이유는 명확하다.

지식, 기술의 평준화 앞에서 남들보다 더 잘하기 위해.

‘구현(Development)‘에 들어가는 시간을 최소화하고, 확보된 그 시간을 ‘제품(Product)‘의 가치에 쏟아붓기 위해서다.

가트너 보고서의 마지막 장을 덮으며 든 확신은 하나다.

이제 진짜… ‘Development’가 아닌 ‘Product’의 시대가 왔다.

과거의 우리는 코드를 어떻게 짤지, 어떤 라이브러리를 쓸지가 나의 정체성이었다.

하지만 이제 기술을 그저 코드를 짜는 도구가 아니라, 사용자에게 가치를 주는 ‘제품’을 완성하는 무기로 바라보는 사람만이 살아남는다.

왜냐고? 곧 생존을 위한 ‘개발 유목민(Dev Nomad)‘들이 쏟아져 나올 테니까.

예전의 “디지털 유목민”이 낭만이었다면, 앞으로 닥칠 “개발 유목민”의 시대는 생존 경쟁이다. 기업들이 AI 도입으로 채용 문을 좁히는 순간(이미 엄청나게 좁다.), 갈 곳 잃은 개발자들, 혹은 “이럴 바엔 내 걸 만들겠다”고 각성한 이들이 광야로 나오게 된다.

그들은 맨손이 아니다.

AI라는, 혼자서도 10인분의 몫을 해내는 강력한 무기를 들고 있다.

그들은 이제 회사 간판 뒤에 숨지 않고, 자신만의 Product로 시장에서 직접 가치를 증명하려 들 것이다.

수천 명의 1인 개발자가 쏟아내는 수만 개의 서비스가 앱스토어와 웹을 뒤덮는 대항해시대가 열리는 거다.

그러니 저 거대한 파도가 덮치기 전에, 먼저 깃발을 꽂아야 한다. (이미 많이 늦었을지 모른다. 지금 이 순간에도 누군가는 Cursor를 켜놓고 서비스를 런칭하고 있으니까.)

AI라는 미친 성능의 F1 자동차가 우리 앞에 놓였다.

이 차는 공평하다. 대기업 팀장이든, 방구석 취준생이든 똑같은 엔진(LLM)을 쓴다.

하지만 결국 그 핸들을 잡고, 결승선까지 질주하는 건 누구인가? 바로 개발자 본인이다.

그러니 Cursor 쓴다고 죄책감 갖지 말고, 남들보다 더 잘 쓰려는 고민을 하자.

손으로 짜는 ‘노동’은 줄었어도, 가치를 만드는 ‘고민’은 더 치열해져야 한다.

그 고민마저 놓아버린다면? 개발자가 아니라, 그냥 AI가 짠 코드 복사 붙여넣기 하는 ‘21세기형 디지털 인형 눈 붙이기 알바로 전락할 테니까.

마침