AI가 숙련된 소프트웨어 엔지니어의 필요성을 크게 줄일 것이라는 인식이 확산되고 있다. 하지만 현실은 그렇지 않다.
시연은 설득력이 있다. AI를 피그마, 지라, 소스 제어 시스템, CI/CD 파이프라인에 연결하는 모습이 제시된다. 기능 요청이 입력되면 코드가 생성되고, 풀 리퀘스트가 자동으로 생성된다. 워크플로는 점점 자동화되는 것처럼 보인다.
표면적으로 이런 자동화는 소프트웨어 개발의 자연스러운 진화처럼 보인다. 그러나 실제 환경에서는 훨씬 많은 제약이 따른다.
이런 시연의 전제는 입력 정보가 완전하다는 가정이다. 지라 티켓에는 모든 비즈니스 규칙이 담겨 있다. 인수 기준은 모든 예외 상황을 예상한다. 디자인 시스템은 완전히 일관된다. 모든 의존성은 문서화돼 있다. 미해결 질문은 존재하지 않는다. 모호성도 없다.
20년 넘게 엔터프라이즈 시스템 전반에서 소프트웨어를 개발해 왔지만, 그런 수준의 티켓을 본 적은 없다.
실제 티켓은 근사치에 가깝다. 전체 현실이 아니라 의도를 담는다. 대화, 과거 의사결정, 슬랙 스레드, 공식 문서로 남지 않은 아키텍처 관례에 의존한다. 비공식적으로 조율된 절충안을 반영한다. 숙련 엔지니어가 암묵적으로 보유한 맥락을 전제로 한다.
자동화는 명확성을 전제로 하지만, 현실의 소프트웨어 개발은 모호성 속에서 이루어진다. 이런 특성은 기업 전반에 여러 함의를 갖는다. 그중 가장 중요한 점은 숙련된 엔지니어가 여전히 필요하다는 사실이다. 오히려 그 가치는 더 높아졌다.
정밀도를 얻으려고 치러야 하는 비용
소프트웨어 개발 작업에 내재한 모호성이 AI 기반 자동화의 실패를 의미하지는 않는다. 다만 문제 정의의 정밀도에 따라 성과가 직접적으로 달라진다는 뜻이다. AI가 자율적으로 기능을 구현하길 원한다면, 지시는 완전한 기술 명세에 가까운 수준이어야 한다. 모든 예외 상황을 사전에 식별해야 하며, 모든 가정을 명시해야 하고, 구현 전에 모든 열린 질문을 해결해야 한다.
출력의 지능은 입력의 정밀도를 넘지 못한다.
이 원칙은 일반적으로도 적용된다. 다만 AI의 경우 결과물이 매끄럽고 권위 있어 보이기 때문에, 불완전한 입력과 자신감 있는 출력 사이의 간극을 감지하기가 더 어렵다.
AI를 활용해 전체 기능을 구현해 본 경험이 있다. 문제를 충분히 명확히 설명하면, 컴파일되고 실행되며 예상보다 더 많은 시나리오를 처리하는 코드를 생성한다. 효율적으로 느껴지고 현대적으로 보이며 비용도 낮아 보인다.
그러나 결과물은 필자가 직접 작성했을 코드보다 더 복잡한 경우가 많다.
개발자에 대해 공개적으로 잘 언급되지 않는 사실이 있다. 게으르다는 점이다. 최소한 필자는 그렇다. 필요 이상으로 많은 코드를 작성하고 싶지 않다. 문제를 깔끔하게 해결하는 가장 작은 해법을 원한다. 이런 태도는 지름길이 아니라 규율에 가깝다. 구조를 충분히 고민한 뒤 코드를 작성하면 구현은 더 작아진다. 명확한 경계는 중복을 제거한다. 정확한 모델링은 방어적 분기를 줄인다. 신중한 제약 설정은 추가 계층의 필요성을 낮춘다.
좋은 아키텍처는 더 적은 코드로 이어진다.
AI는 다른 방식으로 최적화한다. 적용 범위와 견고성을 우선한다. 다양한 변형을 예상한다. 더 넓은 사례를 포괄하기 위해 추상화를 도입한다. 생성된 결과는 대체로 틀리지 않지만, 당장 필요한 범위를 넘어서는 경우가 많다. 그만큼 비용이 따른다.
요구사항이 변경되면 의도적으로 설계하지 않은 로직을 수정해야 한다. 버그가 발생하면 충분히 추론하지 않았던 제어 흐름을 디버깅해야 한다. 특정 추상화가 왜 존재하는지 다른 엔지니어가 질문할 경우, 의도적 설계가 아니라 생성된 결과의 일부였다는 설명이 될 수 있다.
AI는 코드 작성 비용을 낮춘다. 그러나 코드 소유 비용을 낮추지는 않는다.
소유에는 이해가 포함된다. 변경이 시스템 전반에 어떻게 전파되는지 추론할 수 있어야 한다. 로직을 단순화해도 의도치 않은 부작용이 발생하지 않을 것이라는 확신이 필요하다. 이런 이해와 확신은 AI가 아니라 엔지니어에게 존재한다.
가속은 아키텍처를 증폭한다
시스템 경계가 명확하고 도메인 모델이 일관돼 있다면 AI는 영향력을 확대한다. 기존 구조를 더 빠르게 확장할 수 있다. 반대로 아키텍처가 느슨하게 정의돼 있다면, AI는 복잡성 축적을 가속한다. 도구는 방향을 바꾸지 않는다. 속도만 높인다.
이런 증폭 효과는 대규모 기업에서 특히 두드러진다. 이들 기업에서 아키텍처는 단순한 다이어그램이 아니라 누적된 역사다.
엔터프라이즈 시스템은 처음부터 새로 설계된 경우가 드물다. 수년에 걸쳐 진화한다. 과거 제약 아래에서 내려진 결정을 안고 있다. 쉽게 재작성할 수 없는 통합 구조를 포함한다. 안정성을 유지하는 많은 요소는 문서가 아니라 기억에 남아 있다. 특정 경계를 도입한 이유, 의존성을 제한한 배경, 과거 리팩터링이 실패한 맥락이 그 예다.
이런 축적된 아키텍처 기억이 체계적으로 기록돼 있지 않다면, AI는 접근할 수 없다. 기록돼 있더라도 통계적 패턴으로 해석할 뿐 맥락을 이해하지는 못한다. 과도하게 결합된 서비스가 초래한 장애를 기억하지 못한다. 가격 엔진을 분리하기까지의 내부 논쟁을 기억하지 못한다. 특정 모듈에서 확장성 대신 단순성을 선택한 이유를 기억하지 못한다.
숙련 엔지니어는 기억한다
이런 기억은 미묘한 방식으로 의사결정에 영향을 미친다. 새로운 추상화를 도입할 가치가 있는지 판단하는 기준이 된다. 지름길을 허용해도 되는지 가늠하게 한다. 제안된 단순화가 다른 영역을 불안정하게 만들 가능성을 평가한다. 이런 고려는 지라 티켓에 거의 드러나지 않지만, 구현 품질에는 직접적 영향을 준다.
워크플로가 AI 중심으로 전환될수록 이런 아키텍처 기억의 가치는 더 커진다. 맥락 없이 구현 속도만 높아지면 과거 실수를 더 빠르게 반복할 위험이 있다. 구현은 가속되지만 맥락 인식이 따라오지 않으면 취약성도 함께 확산된다.
기업 차원의 변화도 수반된다. AI가 기능을 자율적으로 구현하길 원한다면 요구사항 작성 방식은 크게 개선돼야 한다. 티켓은 형식적 명세에 가까워져야 한다. 과거에는 구현 단계에서 해소되던 모호성이 이제는 프롬프트 이전 단계에서 해결돼야 한다.
시스템이 무엇을 해야 하는지 결정할 사람은 여전히 필요하다. 경계를 정의할 사람도 필요하다. 새로운 기능이 기존 제약과 어떻게 통합될지 판단할 사람도 필요하다. AI는 그 책임을 제거하지 않는다. 마찰이 발생하는 위치를 바꿀 뿐이다.
새롭지만 오래된 형태의 전문성
오랜 기간 기술적 깊이는 복잡해 보이는 코드를 작성하는 능력, 프레임워크 내부 구조를 숙지하는 역량, 정교한 반응형 흐름을 조합하는 능력으로 평가돼 왔다. 이런 기술은 여전히 중요하다. 그러나 더 이상 차별화 요소로 작용하지는 않는다. AI가 상당 부분을 보조할 수 있기 때문이다.
희소한 자원은 판단력이다.
판단력은 문제보다 과도한 해법을 구분하는 능력이다. 추상화를 도입하기 전에 도메인을 정확히 모델링하는 역량이다. 기교보다 절제를 선택하는 규율이다. 추가 계층이 미래의 유지보수 비용으로 전환된다는 사실을 인식하는 태도다.
필자는 20년 이상 소프트웨어 엔지니어로 일하며 도구의 급격한 변화를 목격했다. 수동 인프라 관리에서 클라우드 컴퓨팅 플랫폼으로, 장황한 프레임워크에서 선언형 프레임워크로, 수작업 설정에서 자동 생성 구조로 이동해 왔다. 각 물결은 생산성 향상을 약속했고, 실제로 향상을 이끌었다.
그럼에도 변하지 않은 요소가 있다. 규모 확장이 결함을 증폭시키기 전에 구조를 신중히 설계해야 한다는 사실이다.
AI는 또 하나의 생산성 가속 장치다. 기본 역량의 기준을 끌어올리고, 실험에 따르는 부담을 크게 낮춘다. 기본 구조를 잡거나 반복 코드를 작성하는 일은 이제 큰 노력이 들지 않는다. 그러나 견고한 시스템의 가치는 얼마나 빨리 만들었는지가 아니라 얼마나 치밀하게 설계했는지에서 갈린다. 단순히 동작하는 소프트웨어와 시간이 지나도 안정적으로 유지되는 소프트웨어는 분명히 다르다.
AI는 소프트웨어를 저렴하게 만들 수 있다. 그러나 사고를 저렴하게 만들지는 못한다. 사고는 오늘만 작동하는 시스템과 내일도 안정적으로 작동하는 시스템을 가르는 핵심 요소다
dl-itworldkorea@foundryco.com
Sonu Kapoor editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
