
불 꺼진 집이 양산되는 시대에, 우리는 무엇을 측정하는가
요약
AI 에이전트의 발전으로 소프트웨어 구현 속도가 비약적으로 상승함에 따라, 코드의 품질을 검증하고 관리하는 소프트웨어 공학적 관점의 중요성을 다룹니다. 단순 구현을 넘어 설계와 리뷰, 검증의 주체가 변화하는 흐름을 분석합니다.
핵심 포인트
- AI 에이전트 도입으로 인한 '위탁 모드' 코딩 시대의 도래
- 생산성 폭발에 따른 테스트 및 리뷰(검사)의 중요성 증대
- 단순 구현을 넘어 설계와 운용 전반으로 확장되는 AI의 역할
- 도구 사용 자체에 매몰되지 않는 본질적인 엔지니어링 역량 필요
심야의 분양 단지를 드론으로 항공 촬영한 영상을 본 적이 있을 것이다. 골조가 세워지고, 외벽이 붙여지며, 다음 날 아침에는 명패까지 붙어 있다. 그런데 어느 창문에도 불이 켜져 있지 않다. 안에 누군가 살고 있는지, 전기가 통하고 있는지 밖에서는 알 수 없다. 건축 자재의 질을 의심하는 것이 아니다. 기초도 배관도 검사는 통과했을 것이다. 다만, 그 정적이 묘하게 마음을 불안하게 한다. 아무도 그 집의 평면도를 설명할 수 없는 것이 아닐까. 그런 기운만이 감돌고 있다.
얼마 전, 사내 엔지니어 대상 컨퍼런스에서 t_wada님의 강연을 들었다. 주제는 「AI 시대의 소프트웨어 엔지니어링 (Software Engineering)」이었다. 강연을 듣고 가장 먼저 떠오른 것이 바로 그 불 꺼진 분양 단지였다. 지금 우리는 집을 짓는 속도 면에서 사상 최속의 시대에 살고 있다. 다만, 아무도 방을 돌아다니며 불을 켜고 다니지 않는다. 이 기사는 그 하룻밤의 기록이다.
솔직히 쓰겠다. 작년의 나는 코딩 에이전트 (Coding Agent)의 이용 한도를 다 쓰지 않으면 손해를 보는 것 같은 시기가 있었다. 오늘 안에 소비하지 않으면 다음 달까지 이월되지 않는다는 식의 묘한 초조함. t_wada님은 이를 행동 중독, 도박 중독에 가까운 구조라고 불렀는데, 뼈아픈 지적이었다. FOMO (Fear Of Missing Out)가 만드는 변화는 대개 제대로 된 것이 아니다. 다 쓰는 것이 목적이 되는 순간, 도구는 도구가 아니게 된다.
하지만 지난 1년 동안 논의의 축은 바뀌었다. 「인간이 코드를 작성해야 하는가」라는 질문은 이미 끝났다. 10월에서 11월에 걸친 모델 성능의 향상이 전환점이 되었고, 바이브 코딩 (Vibe Coding)이라는 용어는 더 넓은 의미를 가진 에이전틱 코딩 (Agentic Coding)이라는 이름으로 세대교체 중이다. 작은 집을 하룻밤에 3채 짓던 시대에서, 30채를 지을 수 있는 시대로의 이행이다. 프로토타이핑 (Prototyping)에 있어서 이것은 분명 무기가 된다. 다만, 대규모의 복잡한 건물에는 적합하지 않다. 커밋 제로 (Commit Zero), 테스트 제로 (Test Zero), 2만 행―― 그런 “죽은 집”이 양산되는 현장을 나 자신도 보았다.
집을 짓는 방식에는 두 가지가 있다. 하나는 동행 모드. AI와 대화하며 이인삼각으로 못을 박는다. 상황은 파악할 수 있지만, 인간의 인지 (Cognition)가 병목 (Bottleneck)이 된다. 다른 하나는 위탁 모드. 자율적으로 움직이는 AI에게 여러 현장을 동시에 맡긴다. 생산 속도는 압도적이지만, 어느 방에 무엇이 놓여 있는지 현장 감독인 우리의 눈이 닿지 않는다.
지난 여름쯤, 동행 모드에는 드디어 승리 패턴이 보이기 시작했다. 사양 주도 개발 (Specification-Driven Development) 툴군이 그것을 범용화 (Commodity)하고 있다. 하지만 올해의 테마는 명확하게 위탁 모드의 확대다. 그리고 그것은 동시에, 리뷰 (Review)라는 이름의 “검사”를 누가 어떻게 할 것인가라는 문제를 정면으로 마주하게 한다.
명칭의 변천도 흥미롭다. 프롬프트 엔지니어링 (Prompt Engineering), 컨텍스트 엔지니어링 (Context Engineering), 하네스 엔지니어링 (Harness Engineering), 루프 엔지니어링 (Loop Engineering). 버즈워드 (Buzzword)는 차례차례 생겨나고 옅어진다. 하지만 본질은 매번 같은 곳으로 돌아온다. 이것은 새로운 마법이 아니다. 과거의 소프트웨어 공학 (Software Engineering)이 나선형을 그리며 한 단계 위로 올라가고 있을 뿐이다.
집을 짓는 분업에도 역사가 있다. 2024년까지의 AI는 구현 공정―― 즉 목수 일――에 손을 빌려주는 조력자에 불과했다. 그런데 2025년, 구현 페이즈 (Phase)는 거의 통째로 AI의 일이 되었고, 요구사항 정의부터 설계, 운용에 이르기까지 모든 공정에 AI가 얼굴을 내밀게 되었다. 2026년인 지금, 논의는 이미 한 걸음 더 나아가 있다. AI를 중심으로 개발의 전 공정을 재편한다는 발상이 진지하게 논의되기 시작했다.
이것은 단순한 효율화의 이야기가 아니다. 지금까지 목수에게 지시해 온 건축주가, 어느샌가 목수가 그린 도면에 따라 발주서만 쓰는 존재가 될 수도 있다. 그런 주객전도가 구현 공정뿐만 아니라 개발 전체로 퍼지고 있다는 이야기다. 동행 모드에 머무를 것인가, 위탁 모드로 한 발짝 더 나아갈 것인가. 그 선택은 이제 현장 수준의 취향 문제가 아니라, 누가 누구를 섬길 것인가의 문제가 되었다.
집을 다 지었으면 검사가 필요하다. 지금까지 그 검사의 대부분을 코드 리뷰 (Code Review)라는 하나의 스티커가 담당해 왔다. 하지만 그 스티커를 앞으로는 다섯 가지 검사 공정으로 나누어 다시 배분하자는 논의가 진행 중이다.
먼저, 도면 단계에서의 모순 검출. 형식 기법 (Formal Methods)이라는, 한때 쇠퇴해가던 도구가 AI의 도움을 받아 재도전의 기회를 얻고 있다. 다음은 테스트 스위트 (Test Suite). 이것은 이제 조연인 서류가 아니라, 집 그 자체와 동격인 결과물이다. 테스트 선행 (Test-First)이 아니라면, 스스로 짓고 스스로 검사한 셈이 되어버린다. 자작극 방지를 위한, 말하자면 건축주 자신에 의한 체크다.
세 번째는 분전반 (Distribution Board) 검사, 즉 타입 시스템 (Type System)과 정적 분석 (Static Analysis)이다. 인간의 눈이 닿지 않는 곳의 배선 실수를 기계적으로 감지하는 가드레일 역할을 한다. 네 번째는 비즈니스 영향도에 따른 리스크 매핑 (Risk Mapping)이다. 동작이 변하는 공사인지, 구조만 정돈하는 공사인지 나누어 생각하는 발상은, 오래전부터 이야기되어 온 "우선 정리부터"라는 사상과 맞닿아 있다. 그리고 다섯 번째는 페어 프로그래밍 (Pair Programming)과 모브 프로그래밍 (Mob Programming)의 재발견이다. 과거 리뷰 (Review)가 담당했던 교육적 역할을 실시간 협업으로 되돌린다. 미미해 보일지 모르지만, 이는 AI 피로에 대한 처방전으로서도 효과가 있다.
검사 완료 스티커를 한 장에서 다섯 장으로 늘린다. 번거로워 보이지만, 스티커 한 장에 모든 것을 짊어지게 해왔던 것이 애초에 무리수였을지도 모른다. 리뷰 (Review)라는 한 단어에 사양의 정합성도, 동작의 정확성도, 위험한 배선의 감지도, 교육도 전부 때려 넣고 있었다. 그러니 바쁠 수밖에 없다. 나누어 다시 배분하는 것은 퇴보가 아니라 정리라고 생각한다.
DORA 리포트가 2024년부터 "AI 지원 소프트웨어 개발의 현황"이라는 이름으로 바뀐 것은 상징적이다. 결론은 아주 명확하다. AI는 조직의 능력을 증폭시키는 기계일 뿐이며, 강한 조직은 더 강해지고, 기능 부전 상태인 조직은 더 악화한다. 즉, AI 도입의 성패는 도구의 성능이 아니라 받아들이는 측, 즉 우리 조직 자체의 구조에 달려 있다. 분전반이 낡은 집에 아무리 고성능 가전제품을 들여놓아도 차단기가 내려갈 뿐이다.
이는 위로가 되지 않는 결론이기도 하다. 잘 풀리지 않는 팀이 AI를 도입해도, 잘 풀리지 않는 상태가 증폭될 뿐이다. 도구의 도입 그 자체를 목표로 삼아버리는 현장일수록 이 함정에 빠지기 쉽다. 분전반의 용량을 확인하지 않은 채 고성능 가전제품만 계속 사들이는 것과 같다.
여기서부터가 나에게 가장 뼈아프게 다가온 이야기다. 기술적 부채 (Technical Debt) — 유지보수성이 낮은 코드라는 의미에서의 부채는, 아이러니하게도 AI에 의해 개선되는 추세라고 한다. 그렇다면 다행인 것일까? 아니다. 대신 대두된 것이 인지 부채 (Cognitive Debt)다. 인간의 이해가 코드로부터 뒤처지기 시작하고 있다.
과거에는 코드를 작성하는 행위 자체가 머릿속에 그 집의 평면도를 새기는 작업이기도 했다. 기둥을 하나 세울 때마다 왜 여기에 기둥이 필요한지를 자신의 손으로 확인했다. AI가 그 공정을 대신하는 순간, 평면도를 기억할 기회 자체가 사라져 버린다. 기술적 부채라는 말을 처음 만든 인물이 말한 "인간의 이해가 코드보다 앞서 있는 상태"라는 정의는 30년의 시간을 거쳐 뒤집혔다. 지금은 코드가 이해보다 앞서 달려가고 있다.
또 하나 소개된 생각이 가슴에 와닿았다. 프로그래밍이란 이론 구축의 활동이라는 관점이다. 그렇다면 AI가 고속으로 만들어내고 있는 것은 움직이는 집이 아니라, 누구의 머릿속에도 도면이 존재하지 않는 "죽은 집"의 양산에 불과하다. 게다가 골치 아픈 점은, 이 인지 부채를 측정할 메트릭 (Metric)이 아직 세상에 존재하지 않는다는 것이다. 이해하지 못한 채 진척도만 쌓이고, 평가까지 올라가 버린다 — 그 공범 관계를 멈출 신호가 없다. 브레이크 역할은 결국 엔지니어링 매니저 (Engineering Manager)나 프로덕트 매니저 (Product Manager)가 인력으로 떠맡을 수밖에 없다.
1983년에 지적된 자동화의 아이러니도 소개되었다. 자동화가 진행될수록, 막상 인간이 개입해야 할 장면에서의 난이도는 올라가고, 그 개입에 필요한 기술은 먼저 사라져 간다. 분전반을 본 적도 없는 인간에게 정전된 밤에 배선을 고치라고 말하는 것과 같다.
바이브 코딩 (Vibe Coding)이라는 말을 만든 본인의 발언으로 소개된 한 마디가 이 밤 가장 기억에 남는다. 사고 (Thinking)는 외주를 줄 수 있다. 하지만 이해 (Understanding)만은 외주를 줄 수 없다.
질의응답 시간의 답변 중에도 가져가야 할 파편들이 많았다. 엔지니어로서의 성장 축은 이해를 뒤처지게 하지 않는 것, 설계 판단을 내리는 횟수를 늘리는 것에 있다는 이야기. 설계 판단이란 요컨대 "이 벽은 남기고, 이 기둥은 옮긴다"를 자신의 언어로 결정하는 횟수를 말한다. AI를 언제 쓰고 언제 쓰지 않을지를 교육 설계에 명시적으로 포함해야 한다는 이야기도 나왔다. 쓸지 말지를 그때그때 기분에 따라 결정하는 것이 아니라, 미리 정해두는 것이다. 이해와 속도는 반드시 트레이드오프 (Trade-off) 관계가 아니며, 양립하고 있는 층이 실제 조사에서도 확인되었다고 한다. 반대로 AI에 모든 것을 맡기는 것은 도박에 가까워 결과가 안정적이지 않다는 지적도 뼈아픈 이야기로 남았다.
테스트의 미래에 대해서도 이야기가 나왔다. 정해진 절차를 확인하는 체킹 (Checking)은 AI에게 맡겨도 상관없다. 하지만 아직 아무도 발을 들이지 않은 영역을 탐색하는 탐색적 테스팅 (Exploratory Testing)은 당분간 인간의 업무로 남을 것이다. 도면에 실려 있지 않은 방을 찾아 나서는 일은 여전히 인간의 역할이라는 뜻이다. 주니어 육성에 대해서는 팀에 매몰시키지 않고, 가설을 세우는 것부터 배포 (Deploy)까지 혼자서 끝까지 해내는 경험을 반복하게 한다는 이야기가 인상 깊었다. AI를 어디까지 관여시킬지는 가르치는 쪽에서 의도적으로 컨트롤하는 변수로 취급한다. 하나하나 세세하게 가르치는 것이 아니라, 불을 켜는 스위치를 어디까지 숨겨둘지를 가르치는 쪽이 결정한다는 발상이다.
조직의 마인드셋 (Mindset)을 바꾸려면, 메트릭스 (Metrics)를 조직의 목표 (Goal) 및 아웃컴 (Outcome)과 피라미드 형태로 연결하고, AI 도입 후에 그 구조가 무너지지 않았는지 항상 계속 지켜보는 것. 숫자는 심판하기 위한 것이 아니라, 올바른 방향으로 성장하고 있는지를 함께 확인하기 위한 도구라는 말은, 이날 가장 다정한 말이었을지도 모른다.
강연을 듣고 돌아오는 길, 나는 우리 팀에 대해 생각했다. 위탁 모드로 생성된 기능이 테스트도 통과하고 정적 분석 (Static Analysis)에도 걸리지 않았지만, 그럼에도 누구의 머릿속에도 “왜 이런 형태인가”라는 도면이 존재하지 않는다. 그런 집이 우리 분양 단지에도 몇 채는 세워져 있는 것 같다는 생각이 들었다. 동수를 자랑하는 것은 이제 그만두자. 몇 동을 지었느냐보다, 몇 동의 구조를 자신의 언어로 설명할 수 있는지를 세어야 한다.
그 주말, 4살 아들과 근처 공원에 갔다. 미끄럼틀 차례를 두고 다투던 다른 아이와 우리 아이가 손가락 걸고 약속을 하고 있었다. “이제 안 밀 거야”라는, 단지 그뿐인 약속. 딸은 아직 2살 전이라 말보다 먼저 손가락을 내미는 흉내만 배웠다. 아들이 “왜 손가락 걸고 약속해?”라고 물었을 때, 나는 잠시 생각하다가 “약속한 걸 제대로 기억하기 위해서야”라고만 대답했다. 이해는 누군가 대신해 줄 수 없다. 손가락 걸고 약속하는 본인이 자신의 손가락으로 기억해 둘 수밖에 없다.
분양지의 불을 한 채씩 켜고 다니는 것은 확실히 고된 일이다. 그럼에도 나는 오늘 밤, 내 구역만큼은 불을 끄지 않으려 한다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기