LLMOps 05

AI 개발에서 설계 없는 구현이 기술 부채가 되는 순간

AI가 코드를 빨리 만들어주면 기술 부채가 줄어든다고 생각하기 쉽다.

근거 · 교안 p16-p18

1장: 루나: AI가 기술 부채를 줄여줄까? 그 전에 ‘빚’의 본질부터

1. 루나: AI가 기술 부채를 줄여줄까? 그 전에 ‘빚’의 본질부터

솔라는 의자 등받이에 몸을 깊게 묻으며 만족스러운 한숨과 함께 노트북 화면을 바라봤다. 방금 AI 어시스턴트의 도움을 받아 복잡해 보이던 기능 하나를 순식간에 구현해 낸 참이었다. 코드 몇 줄을 추천받아 붙여 넣고, 약간만 수정하니 의도대로 완벽하게 작동했다. 이 놀라운 속도감에 취해 있을 때, 문득 며칠 전 스터디에서 스쳐 지나갔던 문장이 머릿속을 맴돌았다. ‘AI 개발에서 설계 없는 구현이 기술 부채가 되는 순간.’

“언니.”

솔라는 거실에서 조용히 책을 읽고 있던 루나를 불렀다.

“요즘 AI로 코딩하니까 개발 속도가 정말 말도 안 되게 빨라졌거든. 이러면 ‘기술 부채’도 자연스럽게 줄어드는 거 아닐까? 빨리 만들고, 문제가 생겨도 빨리 고칠 수 있으니까.”

루나는 책에서 눈을 떼고 솔라를 바라봤다. 솔라의 얼굴에는 ‘나는 정답을 알고 있다’는 확신이 반쯤, ‘하지만 무언가 찜찜하다’는 의문이 반쯤 섞여 있었다.

“그 말을 들으니 기술 부채라는 개념을 처음 만든 워드 커닝햄이 떠오르네.”

루나가 말했다.

“그는 처음 코드를 배포하는 건 빚을 지는 것과 같다고 했지.”

“알아. 당장은 아니더라도 나중에 수정하거나 개선해야 할 코드를 남겨두는 거잖아. 말하자면 ‘언젠가 갚아야 할 빚’ 같은 거. 그런데 내 말은, AI 덕분에 개발 속도가 빨라졌으니 그 빚을 갚을 시간도 더 빨리, 더 많이 버는 셈 아니냐는 거지.”

솔라의 반문에 루나는 고개를 끄덕이며 펜과 노트를 조용히 솔라 쪽으로 밀었다.

“재미있는 관점이네. 그럼 작은 상상 실험을 하나 해볼까? 아주 간단한 앱을 만든다고 생각해 봐. ‘스마트홈 제어 앱’이고, 첫 기능은 ‘외출 모드’야. 현관문이 닫히면 집 안의 모든 조명을 끈다.”

“쉽네.”

솔라는 자신 있게 대답했다.

“AI한테 ‘현관문 센서가 ‘닫힘’ 상태가 되면, 연결된 모든 조명 기기의 전원을 꺼줘’라고 요청하면 코드가 바로 나올 거야. 그걸로 첫 기능 배포. 깔끔하네.”

“좋아. 첫 번째 빚을 졌어. 며칠 뒤에 새로운 요구사항이 들어왔어. ‘청소 로봇이 작동 중일 때는 외출 모드여도 거실 조명은 켜져 있어야 한다’는 거야. 어떻게 할래?”

“음… ‘외출 모드’를 실행하는 코드에 조건문을 하나 추가하면 되겠지. ‘만약 청소 로봇이 작동 중이라면 거실 조명은 끄지 않는다’라고.”

솔라는 망설임 없이 답했다. 가장 빠르고 직관적인 해결책이었다. AI에게 물어봐도 아마 비슷한 답을 줬을 것이다.

“완벽해. 그리고 또 며칠 뒤. ‘밤 10시 이후에 외출할 때는, 보안을 위해 현관 앞 작은 등 하나는 계속 켜둬야 한다’는 요구사항이 추가됐어.”

“그럼… 또 조건문을 추가해야지. ‘만약 현재 시간이 밤 10시 이후라면, 모든 조명을 끄는 동작에서 현관 등은 제외한다’… 잠깐만.”

솔라의 미간이 살짝 찌푸려졌다. 루나는 아무 말 없이 솔라가 자신의 생각을 따라가도록 기다렸다.

“또 다른 요구사항. ‘실내 공기질이 나쁠 때 자동 환기 시스템이 작동하면, 안전을 위해 베란다 조명은 켜 둔다’면?”

“…….”

솔라는 더 이상 즉답하지 못했다. 대신 노트 위에 뒤죽박죽 얽힌 화살표와 상자들을 그리기 시작했다. 현관문 센서, 조명, 청소 로봇, 시간, 환기 시스템…

“코드가 어떻게 변하고 있는 것 같아?”

루나가 조용히 물었다.

“걷잡을 수 없이 복잡해지고 있어. 처음엔 간단했는데, 예외에 예외가 꼬리를 물고 있어. 지금 당장이야 어떻게든 코드를 덧붙이겠지만, 몇 달 뒤에 ‘수면 모드’ 기능을 새로 만들어야 한다면? 그때는 이 ‘외출 모드’ 코드를 어디부터 어디까지 건드려야 할지 한눈에 파악하기조차 힘들 것 같아.”

솔라는 자신이 그린 복잡한 그림을 보며 말했다. 처음의 명쾌함은 온데간데없었다.

“바로 그게 ‘이자’야.”

루나의 한마디에 솔라는 고개를 들었다.

“이자?”

“응. 처음 ‘모든 조명을 끈다’는 간단한 코드는 ‘원금’이었어. 빨리 기능을 출시했으니 이득을 봤지. 하지만 ‘청소 로봇 예외’를 처리하기 위해 조건문을 추가했을 때, 너는 처음으로 ‘이자’를 내기 시작한 거야. 코드를 이해하고 수정하는 데 드는 추가적인 시간과 노력 말이야. 밤 10시 예외, 환기 시스템 예외가 더해질수록 이자는 복리로 불어나지. 결국엔 새로운 기능을 하나 추가하는 시간보다 기존 코드를 분석하고 부작용이 없는지 확인하는 데 드는 시간이 더 커지는 순간이 와. 배보다 배꼽이 더 커지는 거지.”

그제야 솔라의 얼굴에서 어렴풋한 찜찜함이 걷히고 명확한 깨달음이 번졌다.

“아… 기술 부채는 그냥 ‘나중에 할 일 목록’ 같은 게 아니었구나. 지금 편하자고 선택한 잘못된 구조가 미래에 치러야 할 비용을 눈덩이처럼 불리는 것. 그게 부채의 진짜 의미였네.”

솔라는 자신의 처음 생각으로 돌아갔다.

“그러고 보니 AI는 내가 시키는 대로 가장 빠른 길을 찾아줄 뿐이야. ‘외출 모드에 청소 로봇 예외 처리해줘’라고 하면, 전체 구조를 바꾸기보다 기존 코드에 조건문 하나 덧붙이는 가장 ‘효율적인’ 방법을 알려주겠지. 설계에 대한 고민 없이 말이야.”

“맞아. AI는 구조적인 개선보다 눈앞의 문제를 해결하는 지름길을 제안할 가능성이 높아. 그 지름길들이 모여 감당 못 할 이자를 만들어내는 거고.”

루나의 말은 솔라의 머리를 명쾌하게 정리해주었다. AI의 속도가 부채 상환 능력을 키워주는 게 아니라, 오히려 설계 없는 부채를 더 빠른 속도로 쌓게 만들 수도 있다는 것. 솔라는 비로소 ‘기술 부채 렌즈’를 통해 자신이 작성하던 코드를 다시 보게 되었다.

생각이 여기까지 미치자 솔라의 마음속에 새로운 질문이 떠올랐다. 방금 전의 상상 실험은 설득력이 있었다. 하지만 어디까지나 상상이었다.

“언니, 그럼… 실제로 AI 코딩 도구를 썼을 때 기술 부채가 늘어난다는 걸 보여주는 구체적인 증거나 데이터 같은 게 있어? 방금 우리가 상상한 일이 현실에서도 정말 벌어지고 있는지 궁금해.”

2장: 루나: AI의 속도가 진짜 ‘빚’을 키우는 순간

솔라의 질문이 채 공기 중에 흩어지기도 전에, 루나는 이미 노트북을 돌려 화면을 보여주고 있었다. 화면에는 복잡한 그래프 대신, 간결하지만 충격적인 몇 개의 숫자가 떠 있었다. 솔라가 며칠 전 스터디 자료에서 스쳐 지나갔던, 바로 그 통계였다. 루나는 웹 브라우저의 특정 부분을 가리켰다.

AI 코파일럿 사용 후 코드 품질 변화 (A/B 테스트 그룹 분석)

복사/붙여넣기 코드 (Copy/pasted Code) 40% 증가
중복 코드 (Duplicated Code) 10배 증가
재작업률 (Churn) 유의미한 증가

솔라는 눈살을 찌푸렸다. 상상 속의 시나리오가 데이터로 증명된 것 같아 찜찜했지만, 한편으로는 반론도 떠올랐다.

“언니, 이 숫자들만 보면 확실히 문제가 있는 것 같긴 한데… 개발 속도 자체가 50% 이상 빨라졌다는 데이터도 있잖아. 중복 코드가 좀 늘어나도, 그만큼 빨리 만들고 빨리 고칠 수 있다면 결국엔 더 이득 아닐까? 10명이 할 일을 5명이 하게 해주는 셈이니까, 나머지 5명이 이런 코드들을 정리하는 데 투입될 수도 있고.”

솔라의 목소리에는 여전히 AI의 생산성에 대한 강한 믿음이 묻어났다. 빠른 개발 속도가 모든 단점을 상쇄하고도 남을 거라는 직관적인 생각이었다.

루나는 솔라의 말을 잠자코 듣더니, 솔라가 작업하던 프로젝트 코드를 화면에 띄웠다.

“좋은 지적이야. ‘나중에 고치는 비용’이 정말 ‘속도로 번 이득’보다 적을지 한번 확인해 보자. 마침 네가 며칠 전에 AI로 만들었다는 기능이 있네. ‘사용자 등급별 쿠폰 발급 기능’이랑 ‘신규 가입자 대상 이벤트 쿠폰 발급 기능’.”

루나가 가리킨 두 개의 함수는 놀라울 정도로 비슷했다. 둘 다 사용자를 조회하고, 쿠폰 발급 조건을 확인한 뒤, 쿠폰을 생성해서 데이터베이스에 저장하는 로직이었다. 전체 코드의 80%가 거의 동일했고, 다른 부분은 쿠폰의 종류와 발급 조건을 확인하는 단 몇 줄뿐이었다.

“AI한테 각각 다른 기능이라고 설명하고 만들었더니, 이렇게 비슷한 코드를 두 벌 만들어줬어. 하지만 괜찮아. 각자 잘 작동하니까. 이걸 합치는 것보다 그냥 두는 게 빨랐거든.”

솔라는 약간 변명하듯 말했다.

“바로 지금이 ‘나중’이야.”

루나가 말했다.

“새로운 요구사항이 들어왔어. ‘쿠폰을 발급할 때, 해당 사용자의 마케팅 수신 동의 여부를 확인해서, 동의하지 않은 사용자에게는 발송하지 않는다’는 정책이 추가됐어. 지금부터 시간을 재 볼게. 이 두 함수에 새 정책을 반영해 봐. 아주 간단한 조건문 하나 추가하는 거니까, 1분이면 충분하겠지?”

솔라는 자신 있게 키보드에 손을 올렸다. 타이머가 시작되었다. 먼저 ‘사용자 등급별 쿠폰 발급 기능’ 함수를 열었다. 사용자 정보를 조회하는 부분 바로 다음에, 마케팅 수신 동의 여부를 체크하는 if 문을 추가했다. 완벽했다. 이제 똑같은 코드를 ‘신규 가입자 대상 이벤트 쿠폰 발급 기능’에도 추가하면 된다.

그런데 코드를 복사해서 붙여넣으려는 순간, 솔라의 손가락이 멈칫했다.

‘잠깐, 이 프로젝트에 쿠폰 발급 기능이 정말 이 두 개뿐이었나?’

솔라의 머릿속에 불안감이 스쳤다. 프로젝트 전체 검색창을 열어 ‘coupon’이라는 키워드로 검색했다. 결과 창에 스크롤이 생겼다. 예상보다 훨씬 많은 파일이 나타났다. 대부분은 관련 없는 파일이었지만, 솔라의 눈에 익숙한 코드 조각이 보였다.

‘…아. 맞다. 추천인 이벤트 쿠폰 발급 기능도 있었지.’

솔라는 완전히 잊고 있던 세 번째 쿠폰 발급 함수를 발견했다. 심지어 그 함수는 앞의 두 함수와 미묘하게 달랐다. 추천인 정보를 추가로 조회하는 로직 때문에 구조가 살짝 변형되어 있었다. 솔라는 방금 작성한 마케팅 수신 동의 확인 코드를 그대로 붙여넣을 수 없다는 사실을 깨달았다. 세 번째 함수에 맞게 코드를 다시 수정해야 했다.

시간은 이미 3분을 넘기고 있었다. 이마에 땀이 배어 나왔다. 간신히 세 번째 함수까지 수정을 마쳤다고 생각한 순간, 루나가 조용히 말했다.

“하나 더 있어. 테스트 코드.”

“아…!”

솔라는 짧은 탄식을 내뱉었다. 각 기능별로 작성된 테스트 코드에도 쿠폰 발급 성공/실패 케이스가 들어 있었다. 새로운 정책을 반영하려면 최소 3개의 테스트 코드를 더 수정해야 했다. 기능 코드 수정보다 더 손이 많이 가는 작업이었다. 결국 모든 수정을 마치고 나서야 솔라는 타이머를 멈췄다.

“몇 분 걸렸어?”

“…8분. 8분이나 걸렸어. 고작 조건문 하나 추가하는데.”

솔라는 허탈하게 대답했다. 애초에 하나의 함수로 잘 만들어뒀다면, 함수 하나와 테스트 코드 하나만 고쳐 1분 안에 끝났을 일이었다. 하지만 중복된 코드를 찾아내고, 각각의 미묘한 차이를 파악해 수정하고, 잊고 있던 테스트 코드까지 고치느라 8배의 시간을 쓴 셈이었다.

솔라는 다시 루나의 노트북 화면에 떠 있는 통계 숫자를 바라봤다.

중복 코드 (Duplicated Code) 10배 증가

아까와 똑같은 숫자였지만, 이제는 전혀 다른 의미로 다가왔다. 저 ‘10배 증가’라는 숫자는 단순히 코드 라인 수가 늘어났다는 의미가 아니었다. 미래에 발생할 수정 비용이 10배로 늘어날 수 있다는 경고였다. 방금 자신이 겪은 8분의 고통이 프로젝트 곳곳에 10배의 확률로 숨어있다는 뜻이었다.

“알겠어… 이제 알겠다. AI가 주는 속도는 ‘원금’을 빨리 얻게 해주지만, 생각 없이 받아쓰면 ‘이자율’이 훨씬 높은 빚을 지게 되는 거구나. 내가 방금 쓴 8분은 그 이자를 처음으로 내본 거였어.”

속도가 품질 저하를 상쇄할 거라는 생각은 완전히 부서졌다. 오히려 속도가 품질 문제를 더 빠른 속도로, 더 넓은 범위에 퍼뜨리고 있었다. 솔라는 자신이 ‘AI 부채 지표’를 읽는 법을 막 깨달았음을 느꼈다. 저 숫자들은 단순한 통계가 아니라, 미래의 유지보수 비용을 예측하는 명백한 신호였다.

생각이 정리되자, 새로운 의문이 고개를 들었다.

“그런데 언니, 생각해보면 좀 이상해. AI가 일부러 중복 코드를 만들려고 한 건 아니잖아. 나는 그냥 ‘A 기능 만들어줘’, ‘B 기능 만들어줘’라고 따로 시켰을 뿐인데. AI는 그저 내 요청에 충실했을 뿐이야. 그렇다면… 진짜 문제는 AI 자체가 아닐 수도 있겠다는 생각이 들어. 혹시 AI를 쓰는 ‘내 방식’이 잘못된 건 아닐까?”

3장: 루나: AI 시대, ‘설계 부재’가 쌓아 올리는 부채 탑

솔라는 자신의 지난 질문을 곱씹으며 빈 코드 에디터 창을 열었다. ‘AI를 쓰는 내 방식이 잘못된 걸까?’ 이전의 쿠폰 발급 기능은 AI에게 각각의 기능을 따로따로, 생각나는 대로 요청한 결과물이었다. 마치 숙련된 목수에게 ‘여기에 선반 하나 달아줘’, 잠시 후 ‘저쪽에도 비슷한 선반 달아줘’ 라고 말하는 것과 같았다. 목수는 요청에 충실했을 뿐, 집 전체의 가구 배치나 동선을 고려해주진 않는다.

“좋아, 이번엔 다를 거야.”

솔라는 다짐하며 새로운 프로젝트를 시작했다. 이름은 ‘회의록 요약 AI 에이전트’. 이번에는 처음부터 더 큰 그림을 그리며 AI에게 요청하기로 했다.

“언니, 나 새로운 에이전트 만들어보려고. 이번에는 처음부터 설계를 좀 더 생각하면서 AI한테 시켜볼게.”

루나는 솔라의 결심에 말없이 고개를 끄덕여 보였다. 솔라는 키보드를 잡고 AI 어시스턴트 창에 첫 프롬프트를 입력했다.

# 역할: 회의록 텍스트를 입력받아 핵심 내용을 요약하는 파이썬 함수를 만들어줘.

AI는 순식간에 깔끔한 코드를 생성했다. 솔라는 만족스럽게 웃으며 다음 요청을 이었다.

# 추가 기능: 방금 만든 함수에 회의에서 결정된 '액션 아이템'을 별도로 추출하는 기능을 더해줘.

AI는 기존 요약 로직에 정규 표현식이나 키워드 분석을 통해 액션 아이템을 찾아내는 코드를 덧붙였다. 여기까지는 순조로웠다. ‘그래, 이렇게 점진적으로 기능을 구체화하면 되는구나.’ 솔라는 AI 개발도 결국 전통적인 개발과 크게 다르지 않다고 생각했다. 복잡하니까, 일단 작게 시작해서 하나씩 붙여나가는 방식이 최선이라고.

하지만 문제는 다음 단계에서 터져 나왔다.

# 추가 기능: 추출된 액션 아이템 옆에, 해당 업무를 담당할 담당자를 함께 명시해줘. 회의록 앞부분에 참석자 명단이 있으니 참고하면 돼.

AI가 생성한 코드는 이전과 달랐다. 갑자기 코드가 복잡해지며 제대로 작동하지 않는 부분이 생기기 시작했다. 어떤 때는 있지도 않은 사람을 담당자로 할당했고(환각), 어떤 때는 담당자 이름 대신 엉뚱한 단어를 가져왔다. 액션 아이템과 담당자를 연결하는 논리가 뒤죽박죽 엉켜버린 것이다.

“아, 왜 이러지? 참석자 명단 참고하라고 분명히 말했는데… 이걸 기억 못 하나?”

솔라는 미간을 찌푸리며 AI가 뱉어낸 코드를 수정하기 시작했다. 한참을 매달려 코드를 뜯어고치던 솔라의 옆으로, 루나가 다가와 빈 노트를 펼쳤다. 그리고는 아무 말 없이 노트 위에 네 개의 제목을 썼다.

에이전트의 진짜 역할:
작업 순서 (Workflow):
기억해야 할 정보 (State):
역할과 책임의 경계:

“이 에이전트의 진짜 역할이 뭐야?”

루나의 질문에 솔라는 당연하다는 듯 대답했다. “회의록 요약 에이전트.”

“정말? ‘액션 아이템 추출’과 ‘담당자 지정’은 요약의 일부인가, 아니면 별개의 책임인가?”

“어… 그건…” 솔라는 말문이 막혔다. 처음에는 ‘요약’이라는 간단한 역할로 시작했지만, 기능이 추가되면서 에이전트의 정체성이 모호해진 것이다. ‘요약가’에게 ‘업무 분담’까지 시키고 있었다.

“그럼 작업 순서는?”

솔라는 자신의 머릿속에 있던 흐름을 더듬으며 말했다. “텍스트를 받아서… 요약하고, 액션 아이템을 찾고, 담당자를 붙인다?”

루나는 솔라의 말을 들으며 노트에 화살표를 그었다. 입력 → [요약 + 액션 아이템 찾기 + 담당자 지정]

“이 상자 안에서 모든 일이 한꺼번에 일어나는 구조네. 그러니 AI가 혼란스러워하는 거야. 담당자를 지정하려면 ‘참석자 명단’과 ‘추출된 액션 아이템 목록’이라는 두 가지 정보가 명확히 준비되어 있어야 하는데, 지금 네 프롬프트는 그 모든 걸 한 번에 처리하라고 요구하고 있어. 마치 요리사에게 ‘재료 줄 테니 전채, 메인, 디저트를 동시에 만들어봐’라고 하는 것과 같아.”

루나는 계속해서 질문했다.

“이 에이전트가 작업하는 동안 계속 기억하고 있어야 할 정보는 뭐야?”

“회의록 원문, 그리고… 아, 참석자 명단. 그리고 요약된 내용, 추출된 액션 아이템 목록…”

솔라는 하나씩 읊으며 깨달았다. 자신이 AI에게 이런 정보(State)를 체계적으로 관리하고 넘겨주도록 설계한 적이 없다는 사실을. 그저 ‘네가 알아서 맥락을 파악해’라는 식으로 프롬프트를 이어 붙였을 뿐이다. ‘혼재된 State’와 ‘이어 붙인 프롬프트’가 만들어낸 필연적인 실패였다.

마지막으로 루나는 ‘역할과 책임의 경계’ 항목을 가리켰다.

“이 에이전트는 어디까지 책임져야 할까? 만약 회의록에 오타가 있다면? 담당자가 명확히 지정되지 않은 액션 아이템은 어떻게 처리해야 할까? 이런 예외 상황에 대한 규칙, 즉 ‘통제된 워크플로’를 정해준 적이 있어?”

솔라는 고개를 저었다. 그저 AI가 ‘알아서 잘’ 해주기만을 바랐다.

그제야 솔라의 눈에 스터디 자료의 한 문장이 새로운 의미로 박혀 들어왔다.

[AI에 대한 과도한 의존]이 문제가 아니라, [설계 없는 개발]이 문제다.

AI의 지능을 믿고 의존하는 것이 문제가 아니었다. AI가 자신의 역할을 제대로 수행할 수 있도록 명확한 ‘설계도’를 주지 않은 것이 진짜 문제였다. 내가 만들고 있는 것이 단순한 코드 조각이 아니라, 명확한 역할과 작업 순서, 기억 체계를 가진 하나의 ‘에이전트’라는 사실을 망각했던 것이다.

“알겠다….”

솔라는 루나가 정리해준 노트를 보며 말했다.

“나는 AI에게 ‘코드를 짜달라’고 한 게 아니라, 사실상 ‘설계까지 해달라’고 떠넘기고 있었어. 그것도 아주 불명확하고 모순된 요구사항을 던지면서.”

AI 개발이 복잡해서 전통적 설계를 적용하기 어렵다는 생각은 틀렸다. 오히려 복잡하기 때문에, 역할, 워크플로, 데이터(State), 책임 범위 같은 핵심 원칙을 더 명확히 세우는 ‘가벼운 설계’가 반드시 먼저 필요했다.

솔라는 자신의 노트북으로 돌아갔다. 그리고 엉망이 된 ‘회의록 요약 에이전트’ 코드를 지우는 대신, 새로운 파일을 하나 열었다. 파일명은 smart_home_agent_design.md. 1장에서 상상했던, 예외 처리가 꼬여 엉망이 되었던 바로 그 스마트홈 앱이었다.

솔라는 키보드를 두드리기 시작했다. 이것은 코드가 아니었다. 루나가 보여준 네 가지 항목을 바탕으로, 자신이 만들었어야 할 에이전트의 설계도를 그리는 작업이었다.

에이전트 설계 점검표: 스마트홈 매니저

역할: 집의 상태(State) 변화를 감지하고, 설정된 규칙에 따라 기기를 제어하는 ‘자동화 매니저’.
워크플로:
- 트리거 발생 (예: 현관문 닫힘)
- 현재 상태 수집 (현재 시간, 청소 로봇 작동 여부, 공기질 센서 값 등)
- 규칙 기반 판단 (수집된 상태에 따라 어떤 조명을 켜거나 끌지 결정)
- 기기 제어 실행
기억해야 할 정보 (State): 각 기기의 현재 상태, 시간, 외부 센서 데이터. 이 정보는 뒤섞이지 않고 명확히 구분되어야 한다.
책임 경계: 새로운 규칙(예: ‘수면 모드’)이 추가될 때, 기존 규칙을 수정하는 것이 아니라 새로운 ‘규칙’ 블록으로 추가한다. 각 규칙은 독립적으로 작동해야 한다.

이 간단한 점검표를 작성하고 나자, 솔라는 확신할 수 있었다. 만약 처음부터 이 설계도를 가지고 AI에게 요청했다면, ‘외출 모드에 조건문 하나 추가해줘’가 아니라 ‘현재 상태를 확인해서 조명을 제어하는 시스템을 만들어줘’ 라고 말했을 것이다. 빚을 지는 대신, 확장이 용이한 자산을 쌓아 올렸을 것이다. 속도에 취해 설계를 건너뛰는 것이야말로 가장 비싼 이자를 내는 지름길임을, 솔라는 마침내 온몸으로 이해했다.