AI Didn't Make Software Engineering Easier. It Made the Hard Parts Harder.
When I started using AI tools seriously across my side projects, I expected the work to get easier....
사이드 프로젝트 전반에 AI 도구를 진지하게 쓰기 시작했을 때, 작업이 쉬워질 거라 기대했다. AI가 보일러플레이트(반복적인 틀 코드)를 처리하고, 나는 흥미로운 부분에 집중한다. 그게 약속이었다.
그런데 더 쉬워지지 않았다. 흥미로운 부분이 오히려 더 어려워졌고, 더 자주 찾아왔으며, 더 많은 에너지를 소모하게 됐다.
이 경험이 특별한 건 아니다. Google의 한 Staff Engineer가 최근 회사를 떠난다는 글로 화제가 됐는데, 급여나 복지 때문이 아니었다. 업무가 너무 조급해졌고 의미가 줄었기 때문이었다. AI가 어울리지 않는 자리에 억지로 밀려 들어오고 있었고, 그는 새벽 2시에 페이저를 받고 있었다. 그의 말: "나는 다른 누군가의 실행 팔이 되고 싶지 않다(I don't want to be just another execution arm for someone else)."
세계에서 기술적으로 가장 유능한 조직 중 하나인 Google에서 이런 일이 벌어지고 있다면, AI가 소프트웨어 엔지니어링에 실제로 어떤 영향을 미치는지 따져볼 필요가 있다. 보도자료 말고, 실무에서.
기존 업무 구조: 실행 80%, 사고 20% #
소프트웨어 엔지니어링의 역사 대부분에서 업무는 대략 이렇게 나뉘었다.
80% — 실행(Execution)
- 보일러플레이트 코드 작성
- 반복적인 버그 수정
- 티켓 처리 및 문서 업데이트
- 설정(config) 및 환경 구성
- 알려진 동작에 대한 테스트 작성
20% — 깊은 사고(Deep Thinking)
- 실제 문제 파악
- 제약 조건 하에서의 시스템 설계
- 예상치 못한 엣지 케이스 디버깅
- 불완전한 정보로 트레이드오프 결정
- 만들지 말아야 할 것 파악
80%는 궂은 작업이었다. 필요하지만 익힐 수 있었다. 20%는 경험이 정말 중요한 영역이었다. 시니어 엔지니어가 빠르게 타이핑해서가 아니라 더 명확하게 사고함으로써 자기 값어치를 증명하는 곳이었다.
AI가 80%를 가져갔다. 이제 20%가 전부다. #
Claude Code, Cursor, GitHub Copilot 같은 도구들은 실행 계층에서 탁월하다. 보일러플레이트? 사라졌다. 표준 CRUD 엔드포인트? 몇 초 만에 완성된다. 반복적인 테스트? 커피를 다 마시기 전에 생성된다.
그런데 아무도 소리 내어 말하지 않는 게 있다.
20%는 지속적이고 깊은 집중을 요구했기에 어려웠다. 이제 엔지니어들은 그 영역에 상시로 머물 것을 요구받는다. 그런데 인간의 뇌는 그렇게 설계되어 있지 않다.
20%가 새로운 80%가 되었다. 과거의 80%와는 전혀 다른 종류의 피로를 안겨준다.
3시간 동안 보일러플레이트를 작성하는 건 지루하지만, 뇌는 회복된다. 3시간 동안 분산 시스템의 장애 모드를 설계하고, 아키텍처 트레이드오프를 결정하며, 특정 부하 조건에서만 나타나는 레이스 컨디션(race condition, 여러 프로세스가 동시에 자원에 접근할 때 생기는 경쟁 상태)을 디버깅하는 것은 차원이 다른 피로다. AI는 이런 작업의 빈도를 줄이고 있지 않다. 오히려 늘리고 있다.
아무도 인간의 컨텍스트 윈도우를 이야기하지 않는다 #
AI 세계에서는 컨텍스트 윈도우(context window, 모델이 한 번에 처리할 수 있는 텍스트 범위)에 대한 논의가 끊이질 않는다. 모델이 얼마나 많은 토큰을 유지할 수 있는가? 검색을 어떻게 최적화할 것인가? 모델이 적시에 올바른 정보를 갖게 하려면 어떻게 해야 하는가?
완전히 타당한 엔지니어링 문제다. 그런데 아무도 이야기하지 않는 또 다른 컨텍스트 윈도우가 있다.
인간 엔지니어의 컨텍스트 윈도우는 커지지 않고 있다. 항상 그랬던 것과 같은 뇌다. 이제 그 뇌는 더 많은 아키텍처 복잡성을 유지하고, 불확실성 속에서 더 빠른 결정을 내리며, 이전 어느 때보다 자주 시스템 간 컨텍스트를 전환하도록 요구받는다. 모델과 달리, 더 긴 컨텍스트로 업그레이드할 수 없다. 전전두엽에 RAM을 추가할 수도 없다.
Google의 엔지니어는 새벽 2시에 페이저를 받고 오전 5~6시까지 잠을 잘 수 없었다고 했다. 이건 생산성 문제가 아니다. 인지 부하(cognitive load) 문제다. 그리고 이게 예외가 아니라 표준이 되어가고 있다.
실무에서 매일 느끼는 것 #
이론적인 이야기가 아니다. 다섯 개의 사이드 프로젝트에서 이 도구들을 매일 쓴다.
생산성 향상은 실재한다. 이전보다 빠르게 뭔가를 출시한다. 하지만 인지 부하 역시 이전보다 높다. 실행에서 아낀 매 시간은 곧장 더 어려운 사고로 채워진다. 지난주에는 모노레포의 다섯 개 제품에 걸친 공유 상태(shared state)를 어떻게 처리할지, 단 하나의 아키텍처 결정에 오후를 통째로 썼다. 예전에는 며칠이 걸렸을 결정이다. 주변의 실행 작업들이 자연스러운 사고 시간을 제공했기 때문이다. 이제 실행은 즉각적이고, 사고 시간은 의도적으로 확보하지 않으면 그냥 사라진다.
코드를 덜 작성하는 게 아니다. 더 많은 결정을 내리고 있다. 그리고 결정이 비싼 부분이다.
실용적인 조언 #
깊은 작업 시간을 그 어느 때보다 지켜라. AI가 얕은 작업을 처리할수록, 사소한 방해가 비례적으로 더 큰 손해를 낳는다. 예전에는 10분을 낭비했던 Slack 알림이 이제는 아키텍처 결정 하나를 앗아간다. AI 도구를 열기 전 매일 아침 두 시간을 먼저 블록하는 게 좋다.
"좀 더 생각해볼게요"라고 말하는 데 익숙해져라. AI가 만들어내는 속도는 더 빠른 결정을 하라는 압박으로 이어진다. 이에 저항해야 한다. "제대로 생각해보겠습니다"를 느리다는 고백이 아니라 전문적인 응답으로 대하는 것, 이게 지금 가장 과소평가된 기술 중 하나다.
인지적 회복(cognitive recovery)을 업무의 일부로 다뤄라. 과거의 80%는 뇌에 자연스러운 휴식을 주었다. 깊은 사고에서 단순 실행으로의 전환이 위장된 회복이었다. 그 휴식이 사라졌다. 깊은 작업 세션을 의도적으로 부담이 적은 것으로 마무리하면 실질적인 차이가 생긴다.
AI를 언제 쓰지 말아야 할지 알아라. 때로는 코드를 직접 천천히 작성하는 것이 시스템을 이해하는 데 도움이 된다. 한번은 AI가 제품의 데이터 페칭 레이어 전체를 생성하게 했다. 깔끔해 보였고, 빠른 리뷰를 통과했으며, 배포했다. 3주 후 캐싱 버그가 터졌는데, 그 레이어가 실제로 어떻게 동작하는지 이해한 적이 없었기 때문에 디버깅을 할 수가 없었다. 직접 작성했다면 두 시간이면 됐을 것을 이틀을 썼다. 이해 부채(comprehension debt)는 실재하며, 최악의 순간에 나타난다.
결론 #
Google의 엔지니어는 업무가 너무 조급해졌고 의미가 줄었다고 했다. AI가 그것을 덜 의미 있게 만든 게 아니라, AI가 만들어내는 속도가 조심하지 않으면 그렇게 느껴지게 만든다.
남겨진 20%, 즉 시스템 설계, 트레이드오프, 불확실성 속의 디버깅, 만들지 말아야 할 것 파악은 예전에는 개발하는 데 수년이 걸렸다. 주니어 엔지니어들은 80%의 실행 작업이 제공한 기반 위에서 이것을 점진적으로 쌓아왔다. 그 기반이 이제 빠르게 사라지고 있다.
AI는 엔지니어를 대체하는 것이 아니다. 엔지니어가 해야 할 모든 것의 타임라인을 압축하고 있다. 그것이 선물이냐 짐이냐는 전적으로 남겨진 것을 얼마나 의도적으로 관리하느냐에 달려 있다.
이 글은 위 출처의 내용을 바탕으로 작성된 초안입니다. 원문의 의견과 정보를 그대로 전달하며, 별도의 견해를 포함하지 않습니다.