본문으로 건너뛰기
피드

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

폐쇄된 클라이밋닷거브, 공공 데이터 덕분에 클라이밋닷어스로 되살아나다

미국 정부의 기후 정보 사이트 Climate.gov가 예산 삭감으로 내려간 뒤, 전직 NOAA 관련자들이 Climate.us로 핵심 자료를 복원했어. 15년 넘게 쌓인 기후 지도, 교육 자료, 기후 지표 보고서, 삭제된 제5차 국가기후평가까지 되살린 배경에는 미국 정부 데이터가 법적으로 퍼블릭 도메인이라는 점이 있었어. 다만 운영은 기부에 의존하고 있어, 공공 인프라를 민간이 임시로 떠받치는 불안정한 구조도 같이 드러나.

general

AI 시대에도 인간 관리자가 남는 이유는 결국 ‘책임’ 때문임

생성형 AI가 기업 경영의 많은 판단을 도와도, 인간 관리자의 역할이 사라지지는 않는다는 주장이다. 글은 공감, 검증, 실행, 책임이라는 네 가지 영역에서 AI가 아직 인간 관리자를 대체하기 어렵다고 설명한다.

general

서로 1만 달러 주고받으면 매출 1만 달러? 스타트업 매출 놀이를 비꼰 풍자 사이트

LARP는 창업자끼리 같은 금액을 서로 주고받은 것처럼 장부에 기록해 매출을 만든다는 설정의 풍자 사이트다. 실제 제품, 고객, 현금 이동 없이도 연간 반복 매출(ARR)을 부풀릴 수 있다는 식으로, 스타트업의 매출 인정과 상호 거래 관행을 날카롭게 비꼰다.

general

뱅크오브아메리카, 소버린 클라우드 수요 보고 아이오노스에 매수 의견

뱅크오브아메리카가 유럽 웹 호스팅·도메인 기업 아이오노스에 매수 의견과 목표주가 37유로를 제시했다. 핵심 논리는 중소기업 대상 웹 서비스, AI 업셀링, 소버린 클라우드 수요가 맞물리며 2025년부터 2028년까지 매출과 이익이 성장할 수 있다는 것이다.

general

SDT·KT·스패로우까지, 국내 보안·클라우드·양자 업계 단신 모음

SDT는 양자 클라우드 플랫폼 큐레카에 양자내성암호를 적용하고 CUDA-Q 교육 모듈을 3개 국어로 제공하기로 했다. KT, 스패로우, 매스웍스, 아이씨티케이, 오케스트로 클라우드도 각각 메일보안, 앱 보안, 디지털 트윈, 양자보안, 공공 클라우드 전환 관련 소식을 냈다.