소프트웨어 엔지니어링은 결코 코딩만이 아니었다

“이제 AI가 코드를 쓰니까 개발자는 곧 필요 없어질 것이다.”

이 주장은 이제 놀랄 만큼 다양한 형태로 등장한다. 어떤 때는 예측처럼 들리고, 어떤 때는 위협처럼 들리며, 놀랍도록 자주 마케팅처럼 들린다.

출발점 자체가 완전히 터무니없는 것은 아니다. AI는 코드를 쓴다. 그리고 이제는 소프트웨어 개발을 체감할 만큼 바꿀 정도로 충분히 잘하고, 충분히 빠르며, 충분한 규모로 코드를 작성한다. Coding Agent는 Feature를 구현하고, 테스트를 생성하고, Refactoring을 수행하고, 오류를 찾고, 기존 시스템을 분석하며, 수많은 파일을 오가면서 작업한다. 예전에는 몇 시간이 걸렸던 일도 이제는 때때로 훨씬 짧은 시간 안에 끝낼 수 있다.

나는 이런 방식으로 일하는 것을 좋아한다. 아주 많이 좋아한다.

하지만 코드 생산이 빨라졌다고 해서 소프트웨어 개발 자체가 해결된 것은 아니다.

사고의 오류는 훨씬 앞에서 시작된다.

Coding은 Software Engineering이 아니다.

눈에 보이는 것이 전부였던 적은 없다

코드는 우리가 하는 일 가운데 가장 눈에 잘 보이는 부분이다. Repository 안에 있고, 셀 수 있으며, Diff를 보고 Review할 수 있고, 실행할 수도 있다. 그래서 소프트웨어 개발을 코드 작성과 동일시하는 것은 이해할 만하다.

하지만 그 등식은 처음부터 틀려 있었다.

의미 있는 코드가 나오기 전에 누군가는 먼저 실제로 어떤 문제를 해결해야 하는지 이해해야 한다. Requirements를 해석하고, 모순을 발견하고, 도메인 관계를 이해해야 한다. 시스템에는 경계가 필요하다. 데이터는 어딘가에서 생겨나고, 처리되고, 저장되어야 한다. 컴포넌트들은 서로 통신하고, 외부 시스템은 장애를 일으키며, 권한은 올바르게 동작해야 하고, 기존 데이터는 언젠가 마이그레이션해야 한다. 유지보수성, 성능, 운영, 장애 상황은 함수 하나를 더 빨리 구현할 수 있다고 해서 사라지지 않는다.

그리고 언젠가는 누군가가 가능한 여러 해법 가운데 현재 조건에서 어떤 해법이 실제로 합리적인지 결정해야 한다.

그 모든 것이 Software Engineering이다.

AI가 갑자기 이런 것들을 중요하게 만든 것이 아니다. 원래부터 중요했다.

달라지는 것은 다른 부분이다. 코드 생산이 점점 더 빠르고 저렴해질수록, 그것을 Engineering과 혼동하기가 점점 어려워진다.

AI 때문에 Software Engineering이 갑자기 더 중요해진 것은 아니다. 원래 중요했다. 다만 코드 생산 자체가 점점 더 저렴해지면서 Software Engineering을 코드 생산과 혼동하기가 더 어려워질 뿐이다.

어쩌면 이것이 현재 변화에서 가장 흥미로운 부수 효과 중 하나일지도 모른다.

우리는 수십 년 동안 Lines of Code가 의미 있는 생산성 지표가 아니라고 설명해 왔다. 이제는 과거 며칠 동안 만들던 양의 코드를 한 시간 만에 생성할 수 있게 되었는데도, 가끔 놀랄 만큼 쉽게 그 양 자체를 다시 생산성으로 해석하려 한다.

하지만 더 많은 코드는 우선 그냥 더 많은 코드일 뿐이다. 더 많은 Agent Run은 더 많은 Agent Run일 뿐이다. 오전보다 오후에 Repository가 세 배 커졌다고 해서 Business Value가 세 배 늘었다는 증거가 되지는 않는다.

Agentic Work는 시간을 압축한다

그럼에도 Agentic Work의 생산성 효과는 분명히 현실적이다.

잘 작성된 Task에 유용한 Context, 명확한 Constraints, 적절한 Architecture가 주어지면 놀라울 정도로 빠르게 구현할 수 있다. Agent는 알려진 Pattern을 일관되게 적용하고, 여러 파일에 걸친 변경을 조율하며, 인간 개발자가 어느 순간 커피를 Build System 의존성으로 문서화해야 하는지 진지하게 고민하게 되는 단조로운 작업을 대신할 수 있다.

목표가 명확할수록 특히 잘 작동한다.

문제는 반대 방향에서도 똑같이 잘 작동한다는 것이다.

Agent는 잘못된 도메인 가정도 똑같이 일관되게 구현할 수 있다. 나쁜 추상화를 여러 Layer에 깔끔하게 퍼뜨릴 수 있고, 시작부터 잘못된 Architecture 결정에 테스트, Interface, Mapper, 그리고 놀라울 만큼 정돈된 네이밍까지 붙여 줄 수 있다.

그렇게 되면 오류는 단순히 잘못된 상태를 넘어선다.

아주 훌륭하게 구조화된 오류가 된다.

Agent는 나쁜 결정으로부터 우리를 보호해 주지 않는다. 최악의 경우, 그저 그 결정의 구현만 더 전문적으로 만들어 줄 뿐이다.

이 문제 자체도 새롭지 않다. 개발자는 예전에도 잘못된 Requirements를 구현했고, 나쁜 추상화를 만들었으며, 자신이 완전히 이해하지 못한 문제에 국소적인 해결책을 만들었다.

무엇보다 새로워진 것은 속도다.

Agentic Work는 시간을 압축한다. 좋은 결정은 더 빨리 효과를 내고, 나쁜 결정도 그렇다.

그래서 오늘날에는 눈앞의 코드 그 이상을 이해하는 사람이 이러한 도구를 사용할 때 분명한 이점을 갖는다. 흐름, 시스템 경계, Pattern, 데이터 흐름, 도메인 관계, Trade-off를 이해하는 사람은 Agent에게 무엇을 해야 하는지 더 정확하게 설명할 수 있을 뿐 아니라, Agent의 해석이 잘못된 방향으로 가고 있다는 것도 더 일찍 알아챌 수 있다.

그 차이는 Task를 정의하는 순간부터 시작된다.

잘못된 질문을 하면, 잘못된 문제에 대한 훌륭한 답을 받을 수 있다.

그리고 이것은 대놓고 틀린 답보다 더 불편할 때가 많다. 명백한 오류는 눈에 띈다. 하지만 잘못된 문제를 해결하면서도 그럴듯하고, 깔끔하게 구현되어 있으며, 테스트까지 잘 갖춰진 해법은 놀랄 만큼 멀리 갈 수 있다.

“10×”와 “어차피 아무것도 못 해” 사이

공개 담론은 이 기술을 합리적으로 다루는 일을 딱히 더 쉽게 만들어 주지 않는다.

한쪽에는 이제 익숙해진 “10× Developer”, 1인 팀, 그리고 오후 한 번 만에 만들었다는 SaaS 제품의 세계가 있다. 인상적인 Demo 하나가 종종 새로운 소프트웨어 생산성 단위처럼 취급된다.

소셜 미디어에는 이런 멋진 이야기도 돌아다닌다. 어떤 CTO가 AI로 방금 만든 애플리케이션 링크를 자랑스럽게 공유했는데, 그 링크가 localhost:4200이었다는 이야기다.

그 일이 실제로 있었는지는 모른다. 아마 이제는 신뢰할 만한 사실 기록이라기보다 Urban Myth에 가까울 것이다. 하지만 현재의 AI Hype를 풍자하는 이야기로는 훌륭하게 작동한다.

브라우저에서 실행된다. 그러니 제품도 완성된 모양이다.

하지만 불행히도 Software Engineering의 상당 부분은 Demo가 끝나는 바로 그 지점에서 시작된다.

시스템은 어떻게 운영할 것인가? 부하가 걸리면 어떻게 되는가? 누가 어떤 데이터를 볼 수 있는가? 그 데이터는 애초에 올바른가? 부분 장애가 발생하면 어떻게 되는가? 기존 정보는 어떻게 마이그레이션할 것인가? 다음 Requirement가 들어오면 어떻게 되는가? 생성된 해법 안에는 어떤 가정이 숨어 있는가? 여섯 달 뒤에도 누군가 그 구조를 이해할 수 있을까? 어떤 외부 시스템이 장애를 일으킬 수 있는가? 그리고 이 애플리케이션은 애초에 해결해야 했던 도메인 문제를 정말 해결하고 있는가?

동작하는 Happy Path 하나는 이 질문들에 놀랄 만큼 적게 답한다.

반대편 극단도 그다지 더 설득력 있지는 않다.

“AI는 어차피 아무것도 못 해. 그냥 내가 직접 코딩할래.”

물론 그렇게 해도 된다.

Provider를 비판적으로 볼 수도 있고, 개인정보 보호를 문제로 생각할 수도 있고, 비용을 의심할 수도 있고, 나쁜 결과를 거부할 수도 있으며, 특정 작업은 의도적으로 직접 수행할 수도 있다. AI를 합리적으로 사용한다는 것이 곧 가능한 모든 일을 Agent에게 넘긴다는 뜻은 아니다.

하지만 이 기술을 진지하게 사용해 보지도 않고, 가능성과 한계를 제대로 조사하지도 않은 채 근본적으로 가치 없다고 선언하는 사람 역시 특별히 중립적인 입장을 취하는 것은 아니다.

그는 단지 실험을 건너뛰고 곧바로 결론으로 갔을 뿐이다.

Hallucination이 AI가 무의미하다는 증거는 아니다. 마찬가지로 성공적인 Greenfield Demo Run이 Software Engineering이 해결되었다는 증거도 아니다.

양쪽 모두 특정 지점에서는 타당한 주장을 할 수 있다. 문제가 되는 것은 도구를 제대로 검토하기도 전에 결론이 이미 정해져 있을 때다.

“소프트웨어 개발은 해결되었다”와 “이건 아무것도 못 한다” 사이에는 훨씬 더 흥미로운 공간이 있다.

그리고 그 공간에서는 실제로 일해야 한다.

믿기보다 검증하기

그 일의 중요한 부분이 Verification이다.

AI 시스템은 진실 기계가 아니다. Output이 설득력 있게 표현되고 자신감 있게 들린다고 해서 자동으로 옳아지는 것은 아니다. 강력한 Agent도 가정을 잘못 해석하거나, Context를 놓치거나, 그럴듯한 API를 만들어 내거나, 처음에는 합리적으로 보였던 Decision Path의 어느 지점에서 잘못된 방향으로 갈 수 있다.

좋은 모델일수록 그럴 때 더 설득력 있어 보이기도 한다.

이것은 사용하지 말아야 한다는 주장이 아니다. 오히려 사용할 때 더 전문적이어야 한다는 주장이다.

가볍게 믿지 마라. 검증하라.

Requirements와 그로부터 파생된 가정을 검증하고, 코드와 테스트, Security, 데이터 흐름, 시스템의 인접 영역에 미치는 영향도 검증해야 한다. 무엇보다도 만들어진 해법이 원래 문제를 정말 해결하고 있는지 확인해야 한다.

Generation과 Verification은 서로 다른 작업이다. 첫 번째를 점점 더 자동화할 수 있다고 해서 두 번째까지 자동으로 끝나는 것은 아니다.

테스트 역시 어느 정도 건강한 의심을 받을 만하다. 잘못된 해석을 구현한 Agent는 그 잘못된 해석에 정확히 맞는 테스트도 얼마든지 작성할 수 있다. 그러면 초록색 Test Run은 코드와 테스트가 같은 잘못된 생각을 공유하고 있다는 사실을 아주 안정적으로 증명한다.

적어도 일관성은 있다.

안타깝게도 아직 도메인 정합성은 아니다.

그래서 Architecture Rule, 명시적인 Constraints, 분명한 시스템 경계, 좋은 테스트가 Agentic Work에서 매우 중요하다. 이것들이 Agent를 마법처럼 무오류로 만들어 주기 때문이 아니라, 이탈을 더 잘 보이게 하고 일부는 기계적으로 검증할 수 있게 하기 때문이다.

따라서 결정적인 질문은 AI를 믿어야 하는지, 아니면 원칙적으로 의심해야 하는지가 아니다.

더 나은 질문은 이것이다. 무엇을 검증할 수 있는가?

호기심은 취미가 아니다

이 질문에 좋은 답을 찾으려면 가끔 제품 발표를 읽는 것만으로는 부족하다.

도구를 실제로 써 봐야 한다.

그래서 나는 호기심을 진지한 Engineering 역량으로 본다. 새 모델 이름이 나올 때마다 따라가라는 뜻도 아니고, 하루 종일 Benchmark만 하라는 뜻도 아니다. 실제 판단력을 쌓으라는 뜻이다.

서로 다른 모델을 써 보고, Context를 너무 적게 주거나 너무 많이 줬을 때 어떤 일이 일어나는지 관찰해 보라. Agent에게 더 큰 Task를 맡기고 언제 Drift가 시작되는지 보라. 작은 모델과 큰 모델을 비교하고, Token 사용량과 비용을 관찰하면서, 어떤 작업은 놀랄 만큼 안정적인데 어떤 작업은 여러 번 시도해도 계속 불안정한지 알아보라.

어렵거나 불완전한 Requirements도 줘 보라. 실패하게 두라. 가능하다면 가끔은 처음에는 꽤 설득력 있어 보여서 자세히 들여다봐야 오류를 찾을 수 있을 정도로 실패하게 두는 것도 좋다.

그 과정에서는 어떤 Feature List도 전달해 줄 수 없는 지식이 생긴다. 언제 추가 질문이 필요한지, 언제 Constraints를 명시적으로 만들어야 하는지, 언제 Task가 너무 커지는지, 언제 Context가 사라지는지, 어떤 종류의 Verification이 어떤 작업에 어울리는지에 대한 감각이 생긴다.

모든 한계가 문서에 적혀 있는 것은 아니다.

어떤 것은 직접 겪어야 한다.

기술 변화가 빠른 시기의 호기심은 놀이가 아니다. 그것은 일종의 리스크 관리다.

실험하는 사람은 도구가 무엇을 할 수 있는지만 배우는 것이 아니다. 언제 그 도구를 맹신하면 안 되는지도 배운다.

나는 거의 30년 동안 프로그래밍을 해 왔다. 그렇다고 이 모든 관계를 거의 30년 동안 이해했다는 뜻은 아니다. 오히려 반대다. 나에게 경험의 일부란, 눈에 보이는 코드 뒤에 어떤 문제가 숨어 있는지 조금씩 알아가는 과정이다.

오늘날 AI라는 맥락에서 다시 중요해진 많은 통찰은 Software Engineering에서 전혀 새로운 것이 아니다. 이 분야는 내가 개발자로서 이해하기 훨씬 전부터 어떤 것들을 이미 알고 있었다.

경험은 단순히 지나간 경력 연수의 합이 아니다. 잘 쌓인 경험은 우리가 시스템을 바라보는 모델을 바꾼다. 어떤 관계를 볼 수 있는지, 어떤 질문을 던지는지, 어떤 결정이 어떤 결과를 만들지 얼마나 잘 인식하는지를 바꾼다.

Agent가 갑자기 기계적인 구현의 상당 부분을 빠르게 만들어 주는 지금, 바로 이런 시스템 이해가 큰 도움이 된다.

Tooling만 만들지 말고 Capability를 만들어라

그렇기 때문에 누군가 언젠가 “AI 시대의 전문적인 소프트웨어 개발은 이렇게 하는 것”이라고 완성된 정답을 설명해 주기를 기다리는 것도 좋은 전략이라고 생각하지 않는다.

그런 사용 설명서는 없다.

고용주가 완전히 제공해 주지도 않을 것이다. 대학은 이렇게 빠른 발전을 필연적으로 제한적으로만 따라갈 수 있다. 자격증은 실무 경험을 대신하지 못한다. Framework Vendor는 여러분의 시스템 Context를 모른다. 그리고 LinkedIn Timeline은 아마 앞으로도 Peer Review가 아닐 것이다.

그래서 개발자는 스스로 판단력을 만들어야 한다. 내일 당장 실직할까 봐 두려워서가 아니다. 그것은 같은 종류의 값싼 미래 예측에 단지 마이너스 기호를 붙인 것뿐이다. 오히려 불확실성에 대한 합리적인 대응이 적응력이기 때문이다.

이는 배우고, 실험하고, 주장을 직접 확인하고, 더 나은 방식이 나오면 일하는 방식을 바꾸는 것을 의미한다. 또한 자동화가 실제로 도움이 되는 곳과 현재는 그저 추가 복잡성만 만드는 곳을 구분해 가는 것도 포함한다.

기업에도 같은 책임이 있다.

현재 AI에 투자하려는 움직임은 이해할 만하다. License를 구매하고, Coding Agent를 도입하고, 모델을 평가하고, Compute를 제공하고, Agent Platform을 만든다. 많은 경우 충분히 합리적일 수 있다.

하지만 Tooling만으로 Capability를 설명하기에는 놀랄 만큼 부족하다.

Tooling만으로는 왜 Engineering Capability가 생기지 않는지, 그리고 학습 공간이 왜 투자인지는 13편 – Agentic Work의 경제학에서 자세히 다뤘다.

사람들에게는 여전히 도메인 지식, 시스템 이해, 기술적 폭, 경험을 쌓을 기회가 필요하다.

이것은 Junior에게만 해당하는 이야기가 아니다.

10년이나 20년의 경력이 깊은 시스템 이해를 보장하지 않는다. 20년 동안 좁은 영역에서만 일해 온 사람이 자동으로 20년의 Architecture 역량을 갖게 되는 것은 아니다.

Engineering Capability는 근속 연수만으로 생기지 않는다.

사람들이 지식을 쌓고, 책임을 맡고, 관계를 이해하고, 결정으로부터 배울 수 있을 때 생긴다.

그래서 기업이 미래 투자를 주로 자동화 투자와 동일시하면서 동시에 교육, Junior 육성, 기술적 폭, 학습 공간에 비용 압박을 가한다면 나는 그 안에 분명한 위험이 있다고 본다. 단기적으로는 일부 효율 지표가 좋아질 수 있다. 그러나 그것이 장기적으로 조직이 자기 시스템을 이해하고 진화시키는 능력까지 높이는지는 전혀 다른 질문이다.

AI License 하나가 곧 Engineering Capability는 아니다.

소프트웨어의 미래에 투자하려는 조직이라면 모델과 자동화에만 투자해서는 안 된다. 그 도구를 의미 있게 사용하고, 결과를 판단하며, 그 뒤의 시스템을 계속 이해할 수 있는 조직의 능력에도 투자해야 한다.

도구도 투자 대상이다.

사람도 그렇다.

미지의 땅

그리고 이 모든 논의 위에는 한 가지 질문이 남아 있다. 장기적으로 이것이 우리의 일에 무엇을 의미할까?

나는 모른다.

AI는 빠르게 발전하고 있고, Robotik과 다른 형태의 자동화도 그렇다. 이것이 일자리, 기업, 사회에 어떤 영향을 미칠지 생각하는 것은 당연히 정당하다. 하지만 오늘날 Coding Agent의 상태만 보고 2036년의 노동시장을 진지하게 도출하는 것은 거의 불가능하다.

새로운 직업이나 완전히 다른 업무 모델이 생길 수도 있다. 어떤 활동은 사라지고, 다른 활동은 근본적으로 바뀌며, 새로운 일이 생겨날 수도 있다. 오늘날에는 유토피아처럼 보이는 사회 모델이 언젠가 당연해질 수도 있다. 반대로 많은 변화가 훨씬 덜 극적으로 진행될 수도 있다.

미래는 미지의 땅이다.

그래서 나는 우리가 오늘 영향을 줄 수 있는 것에 더 관심이 있다. AI는 이미 코드 생산을 크게 가속할 수 있고, 시스템 이해가 있는 사람은 현재 그 레버리지를 특히 잘 활용할 수 있다. 신뢰할 수 있는 Agentic Workflow에는 여전히 Context, 좋은 문제 정의, Constraints, Verification이 필요하다. 동시에 모델이 바로 그 영역에서 오늘 수준에 계속 머물 것이라고 가정할 합리적인 이유도 없다.

이 모든 것은 동시에 참일 수 있다.

미래를 진지하게 예측할 수 없다면, 적응력은 오늘 우리가 할 수 있는 가장 합리적인 투자 중 하나일지도 모른다.

그래서 나는 이 시리즈를 예측으로 끝내고 싶지 않다. 오히려 초대로 끝내고 싶다. 도구를 써 보고, 준비된 Demo만이 아니라 실제 문제를 맡겨 보라. 한계를 관찰하고, 비용을 이해하고, 결과를 검증하라. 더 나은 질문을 던지는 법을 배우고, 자신의 시스템에 대한 지식을 쌓아라. 언젠가 누군가 완성된 방법론을 들고 와서 설명해 주기를 기다리지 마라.

우리는 실제 소프트웨어 시스템에서 Agentic Work가 어떻게 작동하는지 이제 막 배우기 시작했다. 오늘의 방법 중 일부는 아마 다시 버리게 될 것이고, 다른 일부는 너무 당연한 것이 될 것이다. 새로운 모델은 새로운 가능성을 열어 줄 것이고, 거의 확실하게 설득력 있게 잘못된 방향으로 가는 새로운 방식도 만들어 낼 것이다.

그러니 이 주제는 전혀 끝나지 않았다.

다만 지금까지의 모든 실험을 돌아보면 한 가지 생각만큼은 놀라울 정도로 안정적이다.

Software Engineering은 결코 Coding만이 아니었다. AI가 이 사실을 만들어 낸 것이 아니다. 단지 이제는 그 사실을 무시하기가 훨씬 어려워졌을 뿐이다.

어쩌면 AI가 Software Engineering을 더 중요하게 만든 것은 아닐지도 모른다.

어쩌면 그저 원래 중요했던 것을 더 의식적으로 수행하도록 우리를 밀어붙이고 있는 것인지도 모른다.

그리고 그 과정에서 우리는 새로운 모델과 일하는 법만 배우는 것이 아니다.

우리는 그 모델들과 함께 Software Engineering이 어떻게 작동하는지를 다시 배우고 있다.