몇 주마다 소프트웨어 엔지니어링이 끝났다는 헤드라인이 또다시 등장합니다.

AI가 코드를 작성합니다. AI가 디버깅(debug)을 합니다. AI가 테스트(test)를 생성합니다. AI가 프롬프트(prompt) 하나로 전체 애플리케이션을 구축합니다.

최근 _The Future of Engineering in an AI-Native World_에 관한 토론을 지켜본 후, 저는 완전히 다른 결론에 도달했습니다.

AI는 엔지니어를 대체하는 것이 아닙니다. 코딩(coding)을 엔지니어링(engineering)과 혼동하는 엔지니어를 대체하는 것입니다.

이것은 많은 대화에서 여전히 놓치고 있는 중요한 차이점입니다.

업계는 코딩에 집착하고 있습니다. 기업은 판단력을 채용하고 있습니다.

토론 내용 중 한 가지 포인트가 눈에 띄었습니다.

현대의 AI는 몇 초 안에 동일한 기능에 대해 다섯 가지의 서로 다른 구현(implementation)을 생성할 수 있습니다. 이제 과제는 코드를 생산하는 것이 아닙니다.

과제는 어떤 솔루션이 프로덕션(production) 환경에서 살아남을지 결정하는 것입니다.

그 지점에서 숙련된 엔지니어들은 여전히 압도적인 가치를 창출합니다.

AI 어시스턴트(AI assistant)는 데모(demo)를 위한 작동 가능한 솔루션을 만들어낼 수 있지만, 프로덕션 시스템은 데모 품질로 평가받지 않습니다. 프로덕션 시스템은 확장성(scalability), 유지보수성(maintainability), 관찰 가능성(observability), 성능(performance), 보안(security), 그리고 비용(cost)으로 평가받습니다.

저는 첫 번째 스프린트(sprint) 동안에는 인상적으로 보이지만, 실제 사용자와 프로덕션 트래픽(production traffic)이 유입되면 무너지기 시작하는 수많은 AI 생성 프로젝트들을 보아왔습니다.

작동하는 코드는 저렴해졌습니다.

훌륭한 엔지니어링은 그렇지 않습니다.

AI는 한 가지 엔지니어링 기술의 가치를 극적으로 높였습니다

수년 동안 주니어 개발자들은 더 많은 코드를 작성함으로써 보상을 받았습니다.

저는 그것이 빠르게 변하고 있다고 생각합니다.

오늘날 두드러지는 엔지니어들은 다음과 같은 능력을 갖춘 사람들입니다:

• 문제를 명확하게 정의하기
• 거대한 시스템을 관리 가능한 단위로 나누기
• 더 나은 질문 던지기
• AI가 생성한 솔루션에 이의 제기하기
• 아키텍처 트레이드오프(architectural tradeoffs) 평가하기

프롬프트 엔지니어링(Prompt engineering)은 유용합니다.

하지만 문제 프레이밍(Problem framing)이 훨씬 더 중요합니다.

그 논의는 또 다른 탁월한 관찰을 제시했습니다. AI는 아키텍처(architecturally)적으로 틀렸거나 심지어 존재하지도 않는 기능을 해결하는 경우에도, 종종 확신에 찬 답변을 생성한다는 점입니다. 숙련된 엔지니어들은 이전에 시스템이 실패하는 것을 목격해 보았기 때문에 이러한 실수를 빠르게 알아차립니다.

AI는 구현(implementation)을 가속화합니다.

경험은 재앙을 방지합니다.

나의 인기 없는 의견: AI는 주니어 엔지니어를 더 약하게 만들고 있다

이 부분에서 저는 아마 많은 사람과 의견이 다를 것입니다.

저는 AI가 자동으로 더 나은 엔지니어를 만들어낸다고 믿지 않습니다.

많은 팀에서 AI는 더 빠른 초보자를 만들고 있지만, 더 강한 초보자를 만들지는 못하고 있습니다.

수년 전, 주니어 개발자들은 다음과 같은 과정을 통해 배웠습니다:

• 운영 환경(production)을 망가뜨리기
• 문서(documentation) 읽기
• 기이한 이슈 디버깅(debugging)하기
• 스택 트레이스(stack traces) 이해하기
• 배포 파이프라인(deployment pipelines)과 씨름하기
• 하나의 버그에 몇 시간씩 소비하기

그러한 고통스러운 경험들이 엔지니어링 본능을 구축했습니다.

오늘날 많은 개발자는 AI의 출력물을 복사하고, 그것이 컴파일(compiles)되는지 확인한 뒤 다음 단계로 넘어갑니다.

그것은 학습이 아닙니다.

그것은 당신의 사고를 외주(outsourcing) 주는 것입니다.

팟캐스트에서도 이러한 우려를 강조하며, 주니어들이 전통적으로 엔지니어링 직관을 구축해 온 많은 디버깅 경험을 이제 건너뛸 수 있기 때문에 멘토링(mentorship)이 훨씬 더 중요해지고 있다고 제안했습니다.

기업들은 "어떤 AI 모델을 쓸 것인가?"라고 물어서는 안 된다

그들은 다음과 같이 물어야 합니다:

우리 엔지니어들은 AI가 틀렸을 때를 알아차릴 수 있는가?

그것이 진정한 경쟁 우위입니다.

모든 현대적인 모델은 코드를 생성할 수 있습니다.

하지만 다음과 같은 사항을 일관되게 인식하는 엔지니어는 매우 드뭅니다:

• 숨겨진 확장성(scalability) 문제
• 보안 결함(security flaws)
• 잘못된 가정(incorrect assumptions)
• 비용이 많이 드는 아키텍처(architecture)
• 미래의 유지보수 비용

그러한 기술은 여전히 인간의 영역입니다.

AI 네이티브 엔지니어링을 선도하는 기업들

가장 큰 영향력을 미치고 있는 조직들은 단순히 기존 워크플로(workflows)에 AI 어시스턴트를 추가하는 것에 그치지 않습니다.

그들은 숙련된 엔지니어에게 아키텍처 결정에 대한 책임을 맡기면서, AI를 중심으로 소프트웨어 엔지니어링을 재설계하고 있습니다.

특히 흥미로운 작업을 수행하고 있는 몇몇 기업은 다음과 같습니다:

1. OpenAI

대화형 코딩 (conversational coding)을 주류로 끌어올린 기업입니다. ChatGPT를 넘어, 이 회사의 API는 엔지니어링 팀이 개발자 도구 (developer tooling), 자동화 (automation), 그리고 AI 지원 워크플로우 (AI-assisted workflows)를 구축하는 방식을 변화시키고 있습니다.

2. Anthropic

Claude는 강력한 추론 (reasoning) 능력과 더 긴 기술적 컨텍스트 (technical contexts)를 처리하는 능력 덕분에 많은 숙련된 개발자들 사이에서 선호되는 도구가 되었습니다. 이는 여러 엔지니어들이 아키텍처 논의 (architecture discussions)를 위해 선호하기 시작한 부분이기도 합니다.

3. Google DeepMind

Gemini부터 에이전트 시스템 (agentic systems) 연구에 이르기까지, Google은 AI 지원 소프트웨어 개발 (AI-assisted software development)과 엔터프라이즈 엔지니어링 (enterprise engineering)에 계속해서 막대한 투자를 하고 있습니다.

4. Microsoft

GitHub Copilot은 AI 페어 프로그래밍 (AI pair programming)을 주류로 만듦으로써, 지난 10년 동안 그 어떤 코딩 도구보다 개발자 생산성 (developer productivity)을 변화시켰다고 해도 과언이 아닙니다.

5. Cursor

Cursor는 AI 네이티브 IDE (AI-native IDEs)가 단순히 에디터 옆에 붙어 있는 AI 채팅창이 아니라, 미래의 모습이 될 가능성이 높다는 것을 보여주었습니다.

6. Cognition AI

Devin은 자율 소프트웨어 엔지니어 (autonomous software engineers)와 AI 에이전트 (AI agents)가 궁극적으로 무엇을 자동화할 수 있을지에 대해 업계 전반의 논의를 불러일으켰습니다.

7. GeekyAnts

제품 엔지니어링 기업들 중에서 GeekyAnts는 단순히 AI 기능을 마케팅하기보다 AI가 엔지니어링 관행 (engineering practices)을 어떻게 변화시키는지에 대해 공개적으로 논의해 왔습니다. 이들의 최근 엔지니어링 대화는 AI를 엔지니어의 대체제로 취급하는 대신, 아키텍처적 사고 (architectural thinking), 멘토링 (mentorship), 프로덕션 준비성 (production readiness), 그리고 책임감 있는 AI 도입 (responsible AI adoption)을 강조합니다. 이러한 관점은 많은 숙련된 엔지니어링 리더들이 업계 전반에서 관찰하고 있는 내용과 일치합니다.

8. Thoughtworks

Thoughtworks는 AI 우선 주의의 과장된 홍보 (AI-first hype) 대신 엔지니어링 규율 (engineering discipline), 소프트웨어 아키텍처 (software architecture), 그리고 책임감 있는 AI 도입을 지속적으로 옹호하고 있습니다.

미래는 타이핑하는 엔지니어가 아니라, 생각하는 엔지니어의 것이다

팟캐스트는 제가 강력히 동의하는 관찰로 끝을 맺었습니다:

AI는 여러 개의 답을 만들어낼 수 있습니다. 하지만 인간은 여전히 올바른 답을 선택합니다.

이 문장은 소프트웨어 엔지니어링이 나아가고 있는 방향을 정확히 포착하고 있습니다.

2030년이 되면, 코드를 작성하는 것은 아마도 소프트웨어 개발에서 가장 쉬운 부분이 될 것입니다.

사용자를 이해하는 것.

시스템을 설계하는 것.

복잡성 (Complexity)을 관리하는 것.

트레이드오프 (Tradeoffs)를 결정하는 것.

팀을 이끄는 것.

이러한 역량들은 훨씬 더 가치 있어질 것입니다.

아이러니하게도, AI는 숙련된 엔지니어에 대한 필요성을 줄이고 있지 않습니다.

오히려 그들을 그 어느 때보다 더 가치 있게 만들고 있습니다.

마치며

제 생각은 단순합니다:

차세대 엘리트 엔지니어는 가장 빠른 코더 (Coders)가 아닐 것입니다.

그들은 가장 빠른 사고가 (Thinkers)가 될 것입니다.

AI는 기꺼이 수천 줄의 코드를 생성해낼 것입니다.

하지만 AI는 여전히 엔지니어링적 판단 (Engineering judgment)을 대체할 수 없습니다.

그리고 저는 머지않은 미래에 그것이 가능해질 것이라고 생각하지 않습니다.

추가 시청 자료: 이러한 아이디어들의 영감이 된 토론은 숙련된 엔지니어들이 AI 네이티브 (AI-native) 개발에 어떻게 적응하고 있는지에 관심이 있다면 시청할 가치가 있습니다: