아직도 챗GPT에 질문만 하십니까? : '설계'하지 못하는 99%는 도태된다
질문하는 능력도 옛말, 이제는 '설계'하는 능력이다
머슴닷컴을 만들고 두 달쯤 됐 을 무렵, 나는 비용 내역을 들여다보다 멈칫했다. 페이지 하나를 열 때마다 API가 20개씩 동시에 호출되고 있었다. 정상적인 설계라면 1~2개로 충분한 일이었다. 사이트는 멀쩡히 돌아갔다. 느려지지도 않았다. 그런데 뒤에서 불필요한 비용이 조용히 쌓이고 있었다. 에이전트가 "일단 작동하게" 만들었지, "효율적으로" 만들지는 않았던 것이다. 며칠 동안 그 사실을 몰랐다. 겉으로 잘 돌아가면 잘 만든 줄 알았다. 이 경험이 하나를 분명하게 알려줬다. 에이전트를 쓰는 것과 에이전트를 설계하는 것은 전혀 다른 일이라는 것.
AI가 처음 대중에게 퍼졌을 때, 사람들은 질문을 잘하는 법부터 배웠다. "같은 내용도 어떻게 물어보느냐에 따라 답이 달라진다." 프롬프트 엔지니어링이라는 말이 각광을 받았고, 그 기술이 새로운 경쟁력처럼 소비됐다. 그런데 AI가 점점 똑똑해지면서 역설이 생겼다. 어설프게 물어도 AI가 맥락을 맞추기 시작한 것이다. 질문 기술의 격차가 점점 좁혀졌다.
이제 진짜 격차는 다른 곳에서 벌어진다. 무엇을 어떤 구조로 굴릴 것인가. 어떤 일을 자동화하고, 어떤 단계에서 멈추게 하고, 어느 기준으로 결과를 검토할 것인가. 질문이 아니라 설계의 문제다.
설계라는 단어가 어렵게 느껴지면 레고를 떠올리면 된다. 누구나 조각을 쌓을 수 있다. 하지만 같은 조각으로도 결과는 완전히 달라진다. 차이는 손재주만이 아니다. 머릿속에 완성 그림이 있는지, 단계가 있는지, 순서가 있는지가 결과를 만든다.
나는 이 변화를 이렇게 부르고 싶다. 호모 프롬프트에서 호모 아키텍트로. 질문하는 인간은 AI에게 일을 시키고 결과를 받는다. 설계하는 인간은 AI가 일하는 방식 자체를 만든다. 어떤 일을 어느 에이전트에게 맡길지. 어떤 기준으로 검증할지. 어디서 멈추게 할지. 어떤 형식으로 결과를 모을지. 전체 흐름을 짠다.
질문은 매번 새로 해야 하지만, 설계는 한 번 만들어두면 반복해서 쓸 수 있다. 프롬프트 엔지니어링이 유행하던 시대는 ‘한 번의 대화’에 집중했다. 에이전트 AI가 확산되면서 기본 단위가 바뀌었다. 이제는 ‘하루를 굴리는 자동 흐름’이 기본 단위다. 밤새 주문을 모아 정리하고, 아침에 요약을 만들고, 낮에는 가격을 감시하고, 저녁에는 정산을 준비하는 흐름. 이런 구조를 만들려면 질문만 잘해서는 부족하다. 언제 무엇을 돌릴지, 어떤 단계에서 확인을 받을지 같은 설계가 필요하다.
질문은 점점 작업 지시서가 되고, 설계는 운영체계가 된다. 운영체계를 가진 사람은 매일 비슷한 일을 반복하지 않는다. 운영체계가 일을 반복한다.
머슴닷컴을 만들기까지 두 달도 안 되는 시간 동안, 나는 30개가 넘는 프로그램을 만들었다. 그러면서 깨달은 것이 있다. 그 많은 프로그램 중 상당수는 ‘한 번 물어보면 되는 일’이었다는 것. 그런데도 프로그램을 만든 이유는 두 가지였다. 자동으로 돌아가게 하려고, 그리고 결과를 '고정'하려고. AI에게 매번 물어보면 답이 조금씩 달라진다. 프로그램은 고정된 형식으로 결과를 만든다.
이 반복 가능성이 설계의 핵심이다. API 20개 사건 이후, 나는 구조를 바꿨다. 코딩 에이전트가 만든 결과물을 점검하는 에이전트를 따로 뒀다. 계획을 세우는 에이전트를 따로 두고, 실행하는 에이전트에게 넘기는 구조. 이중 구조가 필수라는 걸 몸으로 배웠다.
그리고 또 한 번의 예상 못 한 문제가 터졌다. 스팸이었다. 봇들이 광고성 글을 쏟아붓기 시작했다. 손으로 지울 수는 있었다. 하지만 10분마다 올라오는 스팸을 사람이 감시하는 건 불가능했다. 그래서 스팸을 잡는 에이전트를 만들었고, 처음 결과는 처참했다.
첫 번째 실패는 주기 설정이었다. 에이전트가 돌아가는 간격을 제대로 잡지 못해 스팸이 한참 쌓인 뒤에야 감지했다. 두 번째 실패는 규칙이었다. "광고 링크가 있으면 스팸"처럼 단순하게 잡았더니, 정상 글까지 걸러버리는 오탐이 쏟아졌다.
네다섯 번을 고쳤다. 주기를 10분 단위로 바꾸고, 링크 패턴·글자 수·반복 단어·계정 나이를 조합해 판단하게 만들었다. 결국 90퍼센트 이상을 자동으로 걸러내는 시스템이 완성됐다. 흥미로운 건 그다음이다. 잘 돌아가는데 멈춰야 했다. 에이전트가 글을 읽고 판단할 때마다 토큰 비용이 발생했다. 스팸이 줄어들자 커뮤니티의 자정 작용이 작동하기 시작했고, 비용 대비 효과가 떨어졌다. 지금은 에이전트를 꺼두고, 필요할 때만 다시 켠다.
이 경험에서 배운 것은 두 가지다. 에이전트 설계는 한 번에 끝나지 않는다. 그리고 잘 돌아가는 에이전트도 '유지 비용'이 있다. 설계는 만드는 기술이면서 동시에 끄는 판단이기도 하다.
바이브 코딩 이야기를 잠깐 해야 한다. ‘분위기’로 목표를 말하면 AI가 코드를 만들어주는 방식. 예전에는 코딩을 하려면 문법을 배워야 했다. 지금은 대화로 프로그램을 만든다. 아이디어를 빠르게 실제 형태로 바꿀 수 있다는 점에서 강력하다.
그런데 바이브 코딩을 하다 보면 재미있는 역설을 만난다. 프로그램을 만들고 나면 이런 생각이 든다. "이걸 굳이 만들 필요가 있었나?" 날씨 프로그램을 만든다고 하자. 기상청 API를 붙이고, 지역을 선택하고, 화면을 만든다. 좋은 연습이다. 하지만 목적만 놓고 보면, AI에게 "오늘 날씨 어때"라고 물어보면 끝난다.
프로그램의 가치는 정보 자체가 아니라 운영에 있다. 반복 가능하게, 자동으로, 고정된 형식으로. 바이브 코딩은 코드가 아니라 운영을 만드는 도구였다. 이 감각이 정착할 무렵, 나는 한 단계 더 올라갔다.
코드를 바로 만들지 않고, 먼저 '계획을 세우는 에이전트'를 따로 만들었다. 이 에이전트는 코드를 짜지 않는다. "어떤 구조로 만들지, 어떤 순서로 진행할지, 어떤 기술을 쓸지"를 정리해준다. 그 설계도를 코딩 에이전트에게 넘기자, 결과물의 품질이 눈에 띄게 올라갔다.
에이전트가 에이전트를 설계한다. 이 순간이 호모 아키텍트의 감각에 가장 가까웠다. 나는 코드를 한 줄도 읽지 못하지만 어떤 순서로 무엇을 만들지는 정할 수 있었다. 설계는 코딩 실력이 아니라, 목적과 순서를 정하는 능력이었다.
설계하는 인간은 무엇을 하는가
첫째, 목표를 명확히 한다. "좋은 답"이 아니라 "어떤 결과"가 필요한지 정의한다. 둘째, 흐름을 나눈다. 수집, 분류, 검증, 요약, 실행으로 단계를 쪼갠다. 셋째, 역할을 나눈다. 한 에이전트는 자료를 모으고, 다른 에이전트는 반론을 만들고, 또 다른 에이전트는 숫자를 검증한다. 넷째, 안전선을 만든다. 어디서 멈추게 할지, 어떤 데이터는 밖으로 보내지 말지 정한다. 다섯째, 기록을 만든다. 무엇을 했는지 남기고, 다음 번에 더 잘하도록 만든다. 이 다섯 가지가 설계의 뼈대다.
질문을 잘하는 사람은 매번 대화로 해결한다. 설계하는 사람은 시스템으로 해결한다. 시간이 갈수록 격차는 커진다. 바이브 코딩이 중요한 게 아니라, 무엇을 자동화할지 정하는 게 중요하다. 다시 설계로 돌아온다. 기준이 있으면 AI는 더 유용해진다. 기준이 없으면 AI는 편리하지만 불안한 도구로 남는다. 설계는 신뢰를 만드는 기술이기도 하다.
프롬프트는 '명령 문장'이 아니라 '정책'이 된다. "이런 기준으로만 추천해", "이런 데이터는 밖으로 보내지 마", "이런 행동은 항상 멈추고 물어봐." 정책이 모이면 룰북이 되고, 룰북이 모이면 운영체계가 된다. 호모 아키텍트는 질문을 잘하는 사람이 아니라, 기준을 잘 세우는 사람이다.
설계의 경쟁력은 '완성품'을 만드는 데 있지 않다. 변화에 대응하는 데 있다. AI와 도구는 계속 바뀐다. 오늘의 최적 도구가 내일은 구식이 된다. 설계가 있으면 바꿀 수 있다. 어떤 단계는 다른 도구로 교체하고, 어떤 에이전트는 새 것으로 갈고, 어떤 기준은 업데이트하면 된다. 질문이 중요했던 시대는 끝나지 않았다. 다만 질문만으로는 부족해진 시대가 왔다. 사람은 답을 받는 존재에서, 지능의 흐름을 디자인하는 존재로 이동하고 있다. 호모 프롬프트에서 호모 아키텍트로. 그 전환이 이미 시작됐다.
호모 아키텍트의 설계 체크리스트
설계가 실패하는 순간 : 호모 아키텍트가 배우는 방식
설계를 강조하다 보면 오해가 생긴다. "설계를 잘하면 실패하지 않는다." 이 말은 틀렸다. 설계는 실패의 횟수를 줄이는 게 아니라, 실패에서 배우는 속도를 빠르게 만드는 도구다.
머슴닷컴을 운영하면서 가장 어리석었던 순간을 꼽으라면, 성공한 설계를 그냥 복사해서 다른 곳에 붙인 때다. A라는 문제를 해결한 흐름이 있었다. 그 흐름이 잘 돌아가자, B라는 전혀 다른 문제에도 비슷한 구조를 그대로 붙였다. 처음에는 돌아갔다. 두 달 뒤 조용히 망가졌다. 원인을 추적하는 데 일주일이 걸렸다.
문제는 설계 자체가 나빴던 것이 아니었다. A의 조건과 B의 조건이 달랐는데, 그 차이를 무시하고 복사했다는 것이었다. 설계는 재활용할 수 있지만, 맥락은 재활용되지 않는다.
이 경험이 호모 아키텍트에게 주는 교훈은 두 가지다. 첫째, 설계에는 전제 조건이 붙어 있다. 어떤 상황을 가정하고 만들었는지를 적어두지 않으면, 나중에 그 설계를 쓰는 사람이 (미래의 나 자신이라도) 잘못 쓸 수 있다. 둘째, 설계 수명을 알아야 한다. 어떤 설계는 6개월짜리이고, 어떤 설계는 2주짜리다. 수명을 모르면 폐기해야 할 시점을 놓친다. 낡은 설계가 새 문제를 낡은 방식으로 처리한다.
이와 연결된 또 하나의 함정이 있다. 나는 자동화 중독이라고 부른다. 자동화를 맛보면 모든 것을 자동화하고 싶어진다. 자동화할 수 있는 것과 자동화하면 안 되는 것의 경계가 흐려진다. 대표적인 실수는 판단을 자동화하는 것이다. 데이터를 수집하고 분류하는 건 자동화가 맞다. 하지만 그 데이터를 보고 어떤 방향으로 갈지 결정하는 것은, 자동화를 얹을수록 위험해진다. 에이전트는 기준을 따른다. 기준이 틀려도 기준을 따른다. 기준이 상황에 맞지 않아도, 상황이 아니라 기준을 본다.
한 번은 이런 일이 있었다. 특정 단어가 포함된 게시물을 자동으로 분류하는 에이전트를 만들었다. 처음엔 잘 됐다. 그런데 사람들이 새로운 단어를 쓰기 시작하면서, 같은 주제의 글이 전혀 다른 방식으로 분류됐다. 에이전트는 몰랐다. 기준이 바뀌지 않았으니까. 사람만이 "분류가 이상하다"는 감각을 가졌다. 그 감각이 설계를 수정하는 시작이 됐다.
여기서 호모 아키텍트의 핵심 능력 중 하나가 드러난다. 잘 작동하는 자동화를 관찰하는 능력이다. 자동화를 만드는 것은 시작이다. 자동화가 돌아가는 동안 무언가 어긋나고 있지 않은지 주기적으로 보는 것이 더 중요하다. 에이전트는 스스로 "내가 틀렸다"고 말하지 않는다. 사람만이 그 신호를 읽을 수 있다.
설계하는 인간에게 실패는 사고가 아니라 정보다. 왜 실패했는가? 어떤 전제가 틀렸는가? 무엇을 다음엔 다르게 할 것인가? 이 세 질문을 루틴으로 만든 사람이, 한 번에 완벽한 설계를 만들려는 사람보다 결국 더 빠르게 좋은 시스템을 갖는다.
설계는 완성이 아니라 개선이다. 그것이 호모 아키텍트가 호모 프롬프트와 근본적으로 다른 지점이다.
설계의 윤리 : 나의 기준이 다른 사람에게 영향을 미칠 때
설계하는 인간에게 마지막으로 필요한 것은 윤리적 감각이다. 이것이 없으면 설계는 강력한 만큼 위험해진다.
나만을 위한 비서를 만들 때는 내 기준이 전부다. 하지만 그 설계가 다른 사람과 맞닿는 순간, 기준은 사적인 것이 아니게 된다.
가장 가까운 예시가 자동 답변 에이전트다. 고객 문의에 자동으로 답변을 보내는 에이전트를 만들었다고 하자. 그 에이전트의 기준은 내가 정했다. 하지만 답변을 받는 사람은 사람이다. 그 사람은 자신이 에이전트와 대화하고 있다는 사실을 모를 수도 있다.
이때 설계자는 질문해야 한다. 이 에이전트가 보내는 말은 얼마나 정확한가? 틀린 정보를 믿고 결정을 내리는 사람이 생기면 어떻게 할 것인가? 에이전트임을 밝히는 것이 맞는가?
정답은 상황마다 다르다. 단순한 배송 조회 안내라면 에이전트 여부를 굳이 밝히지 않아도 될 수 있다. 의료 상담이나 법률 자문에 가까운 내용이라면 다르다. 기준을 어디에 두는지는 설계자가 결정한다. 하지만 그 결정이 다른 사람의 삶에 닿는다는 사실은, 설계를 단순한 기술 문제로만 볼 수 없게 만든다.
조금 더 넓게 보면 이런 상황도 있다. 추천 에이전트를 만들었다. 특정 조건에 맞는 상품이나 정보를 필터링해서 보여준다. 그 필터 기준 안에 나도 모르는 편향이 들어 있을 수 있다. 가격을 우선으로 하면 품질이 낮은 것이 위로 올라올 수 있다. 평점을 우선으로 하면 리뷰가 많은 유명 브랜드가 새로운 소규모 생산자를 밀어낼 수 있다. 에이전트는 기준 대로 추천했을 뿐이다. 하지만 그 추천이 누군가의 생계에 영향을 미친다.
호모 아키텍트가 호모 프롬프트보다 훨씬 더 큰 영향력을 갖는 이유가 여기 있다. 설계는 한 번의 대화가 아니라 반복되는 규칙이다. 반복되는 규칙은 구조가 된다. 구조는 특정 방향으로 세상을 밀어낸다. 그 밀어냄이 원하던 것인지, 원하지 않던 것인지를 주기적으로 확인하는 일이 설계의 마지막 책임이다.
이것이 거창한 이야기처럼 들릴 수도 있다. 하지만 실제로는 매우 구체적인 습관이다. 에이전트를 처음 만들 때 한 가지를 더 적어두는 것이다. "이 에이전트가 누구와 어떻게 맞닿는가? 그 맞닿음이 잘못됐 을 때 어떻게 고칠 것인가?"
이 두 줄이 있는 설계와 없는 설계는, 문제가 생겼을 때 완전히 다른 속도로 반응한다.
