[크리스의 SW아키텍처] 코드가 싸진 시대, AI가 SW공학을 대체하는가? SW아키텍처는?
AI가 코드를 써주는 시대가 되자 소프트웨어 공학을 둘러싼 극단적인 주장이 동시에 나온다. 한쪽에서는 "이제 코드를 사람이 짜지 않으니 기존 공학은 끝났다"고 하고, 다른 쪽에서는 "AI 시대에 맞는 완전히 새로운…
AI가 코드를 써주는 시대가 되자 소프트웨어 공학을 둘러싼 극단적인 주장이 동시에 나온다. 한쪽에서는 "이제 코드를 사람이 짜지 않으니 기존 공학은 끝났다"고 하고, 다른 쪽에서는 "AI 시대에 맞는 완전히 새로운 공학을 처음부터 세워야 한다"고 한다. 필자는 두 주장 모두 한 걸음씩 앞서 나간 것이라고 본다. 새 공학을 밑바닥부터 만들 필요는 없다. 다만 기존 소프트웨어 공학의 무게중심이 이동하고 있다고 보는 것이 정확하다.
싸진 것은 코드이고, 어려움은 그대로다
바뀐 것은 코드를 작성하는 비용이 0에 가까워졌다는 사실 하나다. 소프트웨어가 풀어야 하는 본질적인 어려움은 그대로 남아 있다. 요구가 불확실하다는 것, 시스템이 복잡하다는 것, 끊임없이 변경해야 한다는 것, 그리고 품질속성 사이의 트레이드오프를 선택해야 한다는 것이다.
이 구분은 새롭지 않다. 프레더릭 브룩스는 1986년 에세이 「은 탄환은 없다(No Silver Bullet)」에서 소프트웨어의 어려움을 본질적인 것과 부수적인 것으로 나눴다. 부수적인 어려움은 도구와 언어가 좋아지면 줄어들지만, 본질적인 어려움은 어떤 도구도 걷어내지 못한다는 논지였다. 코드 생성 AI는 구현이라는 부수적 어려움의 상당 부분을 걷어냈다. 그러나 무엇을 만들어야 하는지 모르는 문제는 그대로이고, 오히려 구현이 쉬워진 만큼 그 문제가 병목으로 드러난다.
덜 중요해지는 것들
무게중심이 이동한다는 말은 어떤 것은 가벼워진다는 뜻이기도 하다. 가장 먼저 가벼워지는 것은 사람이 코드를 읽고 쓰기 편하도록 만든 관행들이다. 세밀한 코딩 규약, 사람 중심의 코드 리뷰, 공수(맨먼스) 산정에 기대는 일정 관리가 여기에 속한다. 이 관행들은 사람의 인지 한계와 구현 인력의 시간을 아끼기 위해 발전했는데, 구현의 주체가 바뀌면 전제가 흔들린다.
같은 이유로 구현 인력을 어떻게 나눌 것인가에 맞춰 짜던 조직과 프로세스 설계도 힘이 약해진다. 코드를 몇 명이 몇 주에 걸쳐 짜는가를 기준으로 팀을 나누던 방식은 그 기준 자체가 흔들리고 있다.
더 중요해지는 것들
명세가 새로운 소스코드가 된다
코드가 싸지면 병목은 "어떻게 만들 것인가"에서 "무엇을 만들 것인가"로 올라간다. 요구사항과 의도를 정확하게 적은 명세가 에이전트가 만들어내는 코드의 품질을 사실상 결정한다. 명세가 곧 새로운 소스코드가 된다고 해도 과장이 아니다. 필자가 이 지면에서 '의도부채'라고 불러온 문제, 즉 왜 이렇게 설계했는가라는 배경이 사라지는 문제가 AI 시대에 더 치명적인 이유다. 의도를 적어두지 않으면 기계가 아무리 빨리 코드를 만들어도 올바른 방향을 잡을 수 없다.
읽어서 믿는 방식에서 검증해서 믿는 방식으로
생성 속도가 사람의 검토 속도를 압도하면 품질을 지키는 방식도 달라져야 한다. 사람이 모든 코드를 읽을 수 없으니 "읽어서 믿는" 방식은 한계에 닿는다. 그 자리를 테스트, 계약(contract), 정형 검증, 관측성이 대신한다. 검증이 사람의 눈이 아니라 시스템에 내장되어야 한다는 뜻이다.
이 문제는 이미 수치로 드러나고 있다. 코드 분석업체 깃클리어(GitClear)의 조사에서는 AI 도구를 적극 활용하는 개발 환경에서 코드 변경량이 39% 늘었지만, 기술 리더의 75%는 앞으로 1년 안에 AI 지원 개발이 기술부채를 중간 이상 심각한 수준으로 키울 것이라고 답했다. 앤트로픽이 낸 개발 트렌드 보고서에서도 개발자들은 업무의 약 60%에서 AI를 활용하지만 완전히 위임할 수 있다고 느끼는 작업은 020%에 그쳤다. 생성은 빨라졌는데 검증과 책임은 여전히 사람 몫으로 남아 있다는 신호다.
아키텍처는 가드레일이 된다
AI는 국소 최적에 강하다. 함수 하나, 모듈 하나를 잘 만드는 일에는 능숙하다. 그러나 시스템 전체의 성능, 보안, 변경용이성, 비용 같은 품질속성과 경계 설계는 약하다. 이 빈틈을 메우는 것이 아키텍처다.
모듈 경계, 의존성 규칙, 의사결정 기록(ADR)은 이제 사람 팀원이 따르는 약속에 그치지 않고 AI가 일관되게 코드를 생성하도록 잡아주는 가드레일 역할을 하게 된다. 아키텍처가 가치를 잃는 것이 아니라 오히려 가장 가치가 커지는 쪽이다.
만들지 않을 것을 결정하는 능력
코드를 너무 쉽게 만들 수 있다는 것은 위험이기도 하다. 중복, 불일치, 기술부채가 폭발적으로 쌓일 수 있기 때문이다. 만들 수 있는 것이 무한대에 가까워지면, 값어치는 무엇을 만들지 않을지 결정하는 능력으로 이동한다. 복잡성을 통제하는 일, 곧 절제는 AI 시대에 가장 희소한 아키텍트의 역량이다.
새로 연구해야 할 영역
기존 공학을 재정의하는 데서 그치지 않고, 새로 연구할 영역도 분명히 있다. 필자는 네 가지를 꼽는다.
첫째, AI 에이전트에 친화적인 아키텍처다. 컨텍스트가 작아도 이해되는 모듈 크기, 명시적인 계약, 스스로를 설명하는 구조가 어떤 모습이어야 하는지 정리해야 한다.
둘째, 생성 코드의 신뢰성을 보증하는 체계다. 평가 하네스, 회귀 검증, 출처와 변경 추적이 여기에 속한다. 누가(어떤 에이전트가) 언제 왜 이 코드를 만들었는지 따라갈 수 있어야 한다.
셋째, 인간과 에이전트의 협업 프로세스다. 명세에서 생성, 검증, 폐기 또는 재생성으로 이어지는 순환을 어떻게 설계할 것인가, 일회용 코드를 전제로 한 설계는 어떤 모습인가를 정립해야 한다.
넷째, 비결정적 구성요소를 포함한 시스템의 설계 패턴과 품질 평가다. LLM 자체가 시스템의 부품이 되면 같은 입력에 같은 출력이 나온다는 오래된 전제가 깨진다. 이를 다루는 패턴과 평가 방법은 아직 충분히 쌓이지 않았다.
독자가 바뀐다
정리하면 이것은 폐기가 아니라 재정의다. 구현 중심이던 공학이 명세, 검증, 구조 통제 중심으로 한 층 올라가는 것이고, 아키텍처는 그중에서도 가치가 커지는 쪽에 있다.
한 가지 덧붙일 것이 있다. 지금까지 아키텍처 문서와 원칙은 사람 독자를 전제로 쓰였다. 앞으로는 기계, 곧 에이전트도 독자로 삼도록 바꿔야 한다. 사람이 읽고 이해하던 설계 문서가 에이전트가 읽고 따르는 설계 문서가 되어야 한다는 뜻이다. 그렇다면 아키텍트의 일은 사람과 사람 사이의 소통을 설계하던 것에서, 사람과 기계 사이의 관계를 설계하는 것으로 넓어진다. 기술은 바뀌어도 소프트웨어를 만드는 일이 결국 관계를 설계하는 일이라는 점은 변하지 않는다.
지금까지 한국은 적당히 작은 시장규모에 정부와 소수 대기업이 리드하는 SW산업 특성으로 특이하게 한국만의 독자적인 시장프로세스에서 SW산업이 갇혀 있을 수 있었다. AI로 코드가 싸진 상황에서 중소 SW회사들이 SI 서비스 산업을 중심으로 경쟁적으로 가격이 낮아질 수 있고, AI 생성 코드로 품질 사고, 보안 사고, 유지보수 비용 폭증이 먼저 나타날 수 있다. 이 과정에서 AI코드 품질관리, AI로 발생한 기술부채의 진단과 자동 청산, 에이전트 거버넌스, 플랫폼 엔지니어링 등과 같은 방식으로 기존의 SW아키텍처와 SW공학이 새로운 차원에서 발전할 가능성이 높다.
본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)