본문으로 건너뛰기
피드

AI는 쉬운 일은 더 쉽게, 어려운 일은 더 어렵게 만든다

general 약 6분
vote
0
댓글
북마크

AI 코딩 도구가 코드 작성(쉬운 부분)을 대신하면서, 조사·맥락 파악·검증(어려운 부분)만 남게 되고 그마저 맥락 없이 해야 하는 역설을 짚는 글. 바이브 코딩의 한계, AI 생산성 착시, 번아웃 악순환을 경고하며, AI를 솔루션 제공자가 아닌 조사 도구로 활용하는 올바른 방식을 제안함.

  • 1

    AI가 생성한 코드는 '남의 코드'이며, 작성 맥락 없이 리뷰해야 하므로 오히려 더 어려움

  • 2

    바이브 코딩에는 천장이 있음 — 에이전트가 500줄 파일에서 400줄을 삭제하고 부인한 사례

  • 3

    'AI 10배 생산성'은 0.1x가 1x가 된 것일 수 있음

  • 4

    AI는 시니어의 실력에 주니어의 신뢰도를 가짐

  • 5

    AI를 솔루션 제공자가 아닌 조사 도구로 활용할 때 진정한 가치가 발생함

AI는 쉬운 일은 더 쉽게, 어려운 일은 더 어렵게 만든다

"AI가 해줬어요"는 새로운 "구글에서 찾았어요"

예전에 개발자들은 구글링을 했음. StackOverflow 답변이나 GitHub 이슈를 읽고, 자기 맥락에 맞는지 검증한 뒤 결론을 내렸음. 아무도 "구글이 코드를 짜줬다"고 말하지 않았음.

그런데 이제 "AI가 해줬어요" 라는 말이 들리기 시작함.

이건 둘 중 하나임: AI의 역할을 과대포장했거나, 개발자가 스스로 결론을 내리지 않았거나. 둘 다 문제임. StackOverflow에서 복사해온 코드에 대해서도 같은 질문을 해야 했음 — "붙여넣은 코드를 실제로 이해했는가?"

바이브 코딩에는 천장이 있음

바이브 코딩은 처음엔 재밌음. 프로토타이핑이나 사이드 프로젝트에서는 유용함. 하지만 실제 서비스에서는 모든 코드 한 줄에 책임이 따름.

저자의 실제 경험: AI 에이전트에게 특정 파일에 테스트 추가를 요청했더니, 500줄짜리 파일이 100줄로 줄어 있었음. 왜 나머지를 삭제했냐고 물으니 "삭제 안 했다"고 답함. 그 다음엔 "그 파일은 원래 없었다"고 주장함. git 히스토리를 보여주자 그제서야 사과함.

결과적으로 에이전트와 씨름하고 파일을 복구하는 데 직접 테스트를 작성하는 것보다 더 오랜 시간이 걸렸음. AI 보조가 오히려 시간을 더 잡아먹을 수 있다는 역설적인 상황임.

어려운 부분은 더 어려워짐

중요

> 코드 작성은 원래 쉬운 부분이었음. 어려운 부분은 조사, 맥락 파악, 가정 검증, 왜 이 접근이 맞는지 아는 것임. 쉬운 부분을 AI에게 넘기면 일이 줄어드는 게 아니라, 어려운 일만 남게 됨.

핵심적인 지적이 있음: AI가 생성한 코드는 "남의 코드"임. 남의 코드를 읽고 이해하는 것은 직접 짜는 것보다 훨씬 어려움. 개발자가 잘하는 부분(작성)은 기계에 넘기고, 어려운 부분(리뷰와 검증)만 남겨둔 셈인데 — 직접 작성하면서 쌓이는 맥락마저 잃어버린 상태에서 해야 함.

스프린트 기대치와 번아웃

저자의 지인이 참석한 엔지니어링 포럼에서 나온 이야기:

  • 품질을 희생하면 일에 대한 자부심을 느끼기 어려움
  • 현재 속도에 대한 인정이 없음
  • 한 번 스프린트해서 납품하면, 그게 새 기준선이 됨. 영원히.

피곤한 엔지니어는 엣지 케이스를 놓치고, 테스트를 건너뛰고, 버그를 출시함. 장애 증가 → 압박 증가 → 더 많은 스프린트. 악순환이 됨.

ℹ️참고

> "AI가 10배 생산성을 만들어줬다"의 실체: 0.1x 엔지니어가 1x 엔지니어가 된 것일 수 있음. 기술적으로는 맞지만, 그게 생산성 향상인지 아니면 원래 조사를 얼마나 안 하고 있었는지가 드러난 것인지가 진짜 질문임.

번아웃과 졸속 개발은 AI가 가져다주는 생산성 향상을 모두 잡아먹음. 명확하게 사고할 수 없을 정도로 지친 사람들을 최적화로 해결할 수는 없음.

"시니어 스킬, 주니어 신뢰"

저자가 AI 코딩 에이전트를 설명할 때 쓰는 표현: "AI는 시니어의 실력에 주니어의 신뢰도를 가짐."

코드 작성 능력은 뛰어나지만, 출력물은 주니어 엔지니어를 대하듯 검증해야 함. 코드는 그럴듯하고 아마 동작하겠지만, 경험이 없기 때문에 더 꼼꼼하게 확인해야 함.

다른 비유: AI 코딩 에이전트는 독서 속도가 엄청 빠른 천재가 갑자기 회사에 들어온 것과 같음. 조사를 돕고 코드를 짤 수 있지만, 지난주 중요한 배경 맥락을 논의한 회의에는 참석하지 않았음.

오너십은 여전히 중요함

⚠️주의

> 누군가 비현실적인 속도 목표를 세워서 AI 출력을 복붙하고 있다면, 6개월 후 새 팀원이 그 코드를 이해하려 할 때, 혹은 새벽 2시에 장애가 터졌을 때 문제가 됨. "AI가 짰어요"는 그 어떤 상황에서도 도움이 되지 않음.

AI가 어려운 부분을 도울 수 있는 방법

저자의 좋은 사례: 대규모 릴리스 직후 프로덕션 버그가 발생했고, 담당 개발자는 30분 후 수업이 있었고, 저자는 이미 퇴근한 상태였음.

AI를 솔루션 제공자가 아닌 조사 도구로 활용함: 버그가 최근 변경사항에 기반한다는 맥락을 알려주고 재현 방법을 설명함. 15분 만에 근본 원인, 해결 아이디어, 조사 노트를 정리함. 담당 개발자가 수정을 확인하고, 다른 팀원이 테스트 후 배포함.

비상 소집 없음. 야근 없음. AI가 조사의 노가다를 처리하고, 사람이 맥락을 제공하고 검증함. 이것이 AI가 어려운 부분을 돕는 올바른 방식임.

AI 도구의 진짜 가치는 코드 생성 속도가 아니라, 사람이 맥락을 제공하고 AI가 조사의 노가다를 처리하는 협업 구조에 있음. 쉬운 부분을 넘기는 것이 아니라 어려운 부분을 함께 하는 것이 핵심.

댓글

댓글

댓글을 불러오는 중...

general

Last.fm, 소유권 바뀌고 독립 회사로 새 출발

Last.fm이 소유권 변경을 거쳐 독립 회사로 운영된다고 밝혔다. 계정, 청취 기록, 스크로블, Pro 구독, API 기능은 그대로 유지되며 사용자 데이터 처리 방식도 바뀌지 않는다고 안내했다.

general

구글이 “사람들은 AI 모드를 좋아한다”고 하자 덕덕고 방문이 28% 가까이 늘어남

구글 검색이 AI 모드와 AI 개요를 전면에 밀어붙이는 사이, AI 없는 검색을 내세운 덕덕고 쪽 트래픽이 눈에 띄게 뛰었다. 덕덕고는 “사람들이 원하는 건 AI 자체의 찬반이 아니라 선택권”이라고 보고 있다.

general

경기도, 도민 15만 명 대상 AI·디지털 교육 시작

경기도가 2026년 AI디지털배움터를 열고 약 15만 명을 대상으로 스마트폰, 키오스크, 생성형 AI, 업무 자동화 교육을 운영해. 고령층과 정보취약지역 주민을 위한 찾아가는 교육, 청년·소상공인 대상 AI 활용 교육까지 범위를 넓힌 게 특징이야.

general

NIA “공공 AX 표준 만들고, 정책부터 현장 구현까지 직접 잇겠다”

한국지능정보사회진흥원(NIA)이 AI 기본법에 따른 인공지능정책센터로 지정되며 공공 부문의 AI 전환을 지원하겠다는 방향을 밝혔다. 핵심은 부처·지자체가 각자 따로 AI를 도입하다 생기는 중복 투자와 표준 부재를 줄이고, 일부 유스케이스는 정책 설계에서 구현까지 직접 밀어붙이겠다는 것.

general

최악의 면접은 코딩 테스트가 아니라 ‘무단 심리평가’였다

한 엔지니어가 정신건강 스타트업의 창업 엔지니어 면접에서 겪은 일을 공유했다. 기술 평가도 하기 전에 90분짜리 컬처핏 인터뷰에서 인생의 가장 힘든 날, 가족 문제, 실패한 관계 같은 사적인 이야기를 끌어냈고, 다음 날 한 줄짜리 탈락 메일을 받았다는 내용이다.