자동화의 90%는 왜 Index에서 죽나요? | 노티크 김시현 대표 인터뷰 전문

제가 말하는 Index는 단순히 데이터를 정리하거나 목록화하는 단계라기보다, 그 업무를 내가 어느 정도까지 이해하고 있는가에 가깝습니다. 자동화하려는 업무의 구조와 핵심 지표, 판단 기준을 사람이 제대로 이해하지 못하면 AI가 아무리 그럴듯한 결과를 만들어도 그것이 맞는지 검증할 수 없습니다. 그래서 지금은 이해하지 못하는 업무를 바로 자동화하려고 하지 않으려 노력합니다.

이 원칙이 처음부터 있었던 것은 아니에요. 이전에는 제가 잘 모르는 영역도 AI가 어느 정도 알아서 해줄 것이라고 생각하고 자동화를 시작한 적이 많았습니다. 실제로 AI는 결과물을 빠르게 만들어줬고, 겉으로 보기에는 잘 작동하는 것처럼 보였습니다. 하지만 시간이 지나 성과가 나오지 않거나 예외 상황이 발생했을 때, 제가 내부 구조를 이해하지 못하고 있으니 무엇이 잘못됐는지 판단할 수 없었어요. 결국 부분적으로 수정하는 것이 아니라 처음부터 다시 공부하고 시스템을 재설계해야 했습니다.

SEO와 GEO 관련 자동화가 대표적인 사례입니다. AI는 키워드를 뽑고, 콘텐츠를 작성하고, 기존 페이지를 분석하거나 개선안을 제안하는 일을 상당히 잘합니다. 하지만 어떤 키워드가 실제로 가치가 있는지, 검색 의도가 무엇인지, 노출과 유입 이후 어떤 지표를 봐야 하는지, 결과가 나오지 않았을 때 콘텐츠와 기술적 문제 중 어디를 의심해야 하는지는 사람이 알아야 합니다. 이런 이해 없이 AI가 제안한 대로 콘텐츠만 대량으로 만들면 자동화 자체는 돌아가더라도 사업적으로는 아무 의미가 없는 결과가 나올 수 있다고 생각합니다.

이런 실패를 여러 번 겪으면서, 자동화를 시작하기 전에 먼저 해당 업무에서 중요한 Index가 무엇인지 공부하게 됐습니다. 어떤 데이터가 필요하고, 어떤 지표를 기준으로 성과를 판단하며, 정상적인 결과와 비정상적인 결과를 어떻게 구분하는지를 먼저 이해합니다. 그다음에 반복되는 수집과 분석, 실행을 AI에 맡깁니다.

그래서 ‘자동화의 90%가 Index에서 죽는다’는 말은 대부분의 자동화가 업무에 대한 충분한 이해 없이 실행부터 시작하기 때문에 실패한다는 의미입니다.

지금의 제 원칙은 사람이 먼저 업무의 핵심을 이해하고 판단 기준을 세운 뒤, 그 실행을 AI에 맡겨야 한다는 것입니다.

API를 통해 가져오는 데이터 자체가 틀린 경우는 거의 없습니다. 오히려 실제로 문제가 됐던 부분은 원본 데이터의 규칙이 생각보다 명확하게 정해져 있지 않았다는 점이었습니다.

사람이 직접 운영할 때는 같은 상품명이 조금 다르게 입력돼 있거나, 주문 상태가 예외적으로 처리돼 있거나, 특정 채널의 데이터 형식이 달라도 담당자가 맥락을 보고 융통성 있게 처리할 수 있습니다. 하지만 자동화는 그런 맥락을 알아서 보완하지 못합니다. 사람에게는 사소한 차이처럼 보이는 것이 시스템에서는 전혀 다른 데이터로 인식되기 때문에, 물류 수량과 매출이 맞지 않거나 광고 성과가 잘못 연결되는 문제가 생겼습니다.

이런 문제는 자동화 로직만 수정해서 해결되지는 않았습니다. 결국 원본 데이터부터 다시 보면서 데이터 정합성을 하나씩 맞춰나가야 했습니다. 상품명, SKU, 주문 상태, 취소와 반품 처리 기준처럼 기존에는 사람이 암묵적으로 판단하던 부분을 전부 명시적인 규칙으로 바꾸는 작업이 필요합니다.

그래서 그 이후에는 문제가 생길 때마다 사람이 예외를 직접 처리하는 방식보다는, 해당 예외가 왜 발생했는지 확인하고 새로운 기준을 세우는 방향으로 시스템을 고쳤습니다. 예를 들어 특정 데이터가 비어 있거나 서로 맞지 않으면 임의로 처리하지 않고 별도의 예외 상태로 분류하고, 사람이 한 번 판단한 결과를 다음부터는 동일한 규칙으로 처리하도록 반영했습니다.

결국 “사람은 결정만 한다”는 말은 사람이 모든 예외를 계속 수작업으로 처리한다는 뜻은 아닙니다. 사람이 해야 할 일은 개별 건을 매번 해결하는 것이 아니라, 예외가 발생했을 때 어떤 기준으로 처리할지를 결정하고 그 기준을 시스템에 다시 넣는 것입니다. 그렇게 하나씩 기준을 만들어가면서 자동화의 범위를 넓혀가는 방식으로 운영했습니다.

세금계산서는 오히려 자동화하기에 적합한 영역이라고 생각합니다. 규칙이 명확하고 입력값만 정확하다면 사람이 직접 처리하는 것보다 실수가 적은 경우도 많았습니다. 실제로 운영하면서 세금계산서 발행 자체에서 큰 오류가 발생한 적은 없었고, 설령 문제가 생기더라도 수정 발행이라는 절차가 있기 때문에 리스크를 충분히 관리할 수 있습니다.

제가 말하는 ‘자동화는 맨 끝’이라는 원칙은 자동화를 가장 마지막에 만든다는 의미는 아니고 처음부터 AI나 시스템이 모든 것을 자동으로 실행하게 두지 않는다는 뜻입니다. 초기에는 사람이 단계별로 결과를 모두 확인하고 승인합니다. 예를 들어 발행 대상이 맞는지, 금액이 맞는지, 거래처가 맞는지를 사람이 직접 검토한 뒤 실행합니다.

이 과정이 반복되면서 “이 조건에서는 항상 문제가 없다”는 확신이 생기면, 그 승인 단계를 하나씩 시스템에 위임합니다. 결국 사람이 하던 판단을 규칙으로 만들고, 충분히 검증된 규칙만 자동으로 실행하도록 하는 것입니다.

안전장치도 같은 방식입니다. 새로운 로직을 바로 운영에 적용하지 않고, 사람이 먼저 모든 케이스를 검증한 뒤 그 검증된 로직 그대로만 시스템이 실행하도록 합니다. 즉, AI가 그때그때 새로운 판단을 하는 구조가 아니라, 이미 사람이 확인한 규칙 안에서만 자동으로 움직이게 만드는 것입니다.

그래서 저는 자동화에서 가장 중요한 것은 AI의 성능보다 사람이 검증한 기준을 얼마나 잘 시스템에 녹여냈는가라고 생각합니다.

자동화는 사람을 없애는 것이 아니라, 사람이 반복해서 하던 검증을 충분한 신뢰가 쌓였을 때 조금씩 시스템으로 이전하는 과정입니다.

저라면 지금은 노코드를 먼저 배우라고 추천하지는 않을 것 같습니다. 예전에는 Zapier나 Make, n8n 같은 노코드 툴이 가장 쉬운 시작점이었지만, 지금은 Claude Code나 Claude Code의 Cowork 기능을 활용하는 편이 오히려 더 빠르고 진입장벽도 낮다고 생각합니다. 자연어로 원하는 자동화를 설명하면 AI가 필요한 코드를 작성하고 수정까지 함께 해주기 때문에, 개발 경험이 없어도 생각보다 쉽게 시작할 수 있습니다.

Capture 단계에서 가장 중요한 것은 거창한 자동화를 만드는 것이 아니라 내가 반복해서 하는 일을 하나 기록하고 수집하는 것입니다. 예를 들어 이메일을 많이 처리하는 마케터라면 “특정 고객에게서 메일이 오면 내용을 요약하고, 해야 할 일을 추출해서 Notion에 등록하고, Slack으로 알림을 보내준다” 정도의 자동화부터 시작해볼 수 있습니다. 이런 정도의 자동화는 Claude Code에게 “Gmail API를 연결해서 특정 조건의 메일을 가져오고, Claude로 요약한 뒤 Notion과 Slack에 전달하는 프로그램을 만들어줘”라고 요청하면 AI와 대화하면서 충분히 구현할 수 있는 수준입니다.

이 과정을 통해 자연스럽게 어떤 데이터가 들어오고, 어떤 판단이 필요한지, 어떤 결과를 저장해야 하는지를 이해하게 됩니다. 저는 이것이 CIA 프레임워크의 Capture 단계라고 생각합니다. 처음부터 복잡한 에이전트를 만드는 것이 아니라, 내가 반복하는 업무 하나를 AI가 대신 수집하고 정리하도록 만드는 것부터 시작하면 됩니다. 그렇게 하나씩 자동화를 경험하다 보면 Capture에서 Index, 그리고 Automation 단계로 확장하는 것이 훨씬 쉬워집니다.

지금까지는 사람이 도구를 조합해서 자동화를 만드는 시대였다면, 앞으로는 에이전트가 필요한 도구를 직접 만들고 수정하는 시대가 올 것 같습니다. 이미 Claude Code나 여러 AI 코딩 도구를 보면, 필요한 기능이 없으면 직접 코드를 작성해서 해결하고, API를 연결하고, 문제가 생기면 스스로 수정하는 수준까지 발전하고 있습니다. 즉, Automation 단계의 구현 비용이 급격히 낮아지고 있습니다.

반면 Capture와 Insight는 생각보다 더 중요해질 것이라고 봅니다. 아무리 에이전트가 똑똑해져도 잘못된 데이터를 가져오거나, 비즈니스의 핵심 지표를 이해하지 못하면 좋은 결과를 만들 수 없습니다. 결국 어떤 데이터를 수집해야 하는지(Capture), 그 데이터에서 무엇을 의사결정해야 하는지(Insight)는 여전히 사람이 설계해야 하는 영역입니다.

그래서 앞으로 CIA 프레임워크의 역할도 조금 바뀔 것 같습니다. Automation은 AI가 대부분 구현해주는 영역이 되고, 사람은 무엇을 수집할 것인지와 무엇을 판단할 것인지를 정의하는 역할에 더 집중하게 될 것입니다. 저는 앞으로 경쟁력은 자동화를 만드는 기술보다, 올바른 문제를 정의하고 올바른 데이터를 선택하는 능력에서 더 크게 결정될 것이라고 생각합니다.

저는 자동화 후보를 고를 때 세 가지를 봅니다.

첫 번째는 반복성입니다. 하루에 여러 번 하거나, 매주 같은 방식으로 반복하는 일이라면 가장 먼저 자동화 대상이 됩니다. 반대로 한 번만 하는 일이나 매번 방식이 바뀌는 일은 자동화해도 투자 대비 효과가 크지 않은 경우가 많습니다.

두 번째는 규칙이 명확한가입니다. 사람이 “이럴 땐 이렇게 처리한다”는 기준을 말로 설명할 수 있는 업무라면 자동화하기 좋습니다. 반대로 사람도 경험과 직관으로 판단하는 일이 많다면 아직은 자동화보다 사람이 하는 편이 더 효율적입니다.

세 번째는 실패 비용입니다. 자동화가 잘못됐을 때 손해가 얼마나 큰지를 항상 생각합니다. 비용이 크다면 처음부터 완전 자동으로 가지 않고, 사람이 승인하는 단계를 반드시 넣습니다. 충분히 신뢰가 쌓인 이후에야 그 승인 과정을 점진적으로 시스템에 넘깁니다.

오히려 짜증난다고 무조건 자동화하는 것은 추천하지 않습니다. 실제로는 자동화보다 업무 프로세스를 먼저 정리하는 것이 더 중요한 경우가 많습니다. 사람이 할 때도 기준이 매번 다르고, 담당자마다 처리 방식이 다르면 AI도 똑같이 혼란스러워집니다. 그런 업무는 자동화보다 먼저 기준을 통일하는 것이 우선입니다.

결국 저는 반복되고, 규칙이 명확하며, 실패 비용을 관리할 수 있는 일부터 자동화합니다. 그리고 예외가 생길 때마다 사람이 그 예외를 처리하는 것이 아니라, 왜 그런 예외가 생겼는지 분석해서 새로운 규칙으로 만드는 과정을 반복합니다. 그 과정을 거치면서 자동화의 범위가 점점 넓어지는 것이 가장 현실적인 접근이라고 생각합니다.

예전에는 자동화를 하면 더 많은 일을 처리하는 데 시간을 썼습니다. 그런데 지금은 생각이 조금 달라졌습니다. 반복 업무를 줄여서 생긴 시간은 결국 사람만 할 수 있는 일에 쓰는 것이 가장 가치가 크다고 생각합니다.

저는 그 시간을 새로운 사업 아이디어를 검증하거나, 고객 인터뷰를 하고, 새로운 기술을 공부하거나, 직접 서비스를 만드는 데 가장 많이 투자하고 있습니다.

AI는 실행 속도를 높여주는 도구이지 무엇을 만들지까지 결정해주지는 못합니다.

결국 사업의 방향을 정하고 문제를 정의하는 일은 여전히 사람이 해야 하는 영역입니다.

그래서 자동화의 목적은 단순히 시간을 아끼는 것이 아니라, 더 중요한 일에 집중할 시간을 만드는 것이라고 생각합니다.

예전에는 규모가 큰 프로젝트를 이해하는 것 자체가 큰 일이었습니다. 새로운 기능 하나를 수정하려고 해도 관련 파일을 찾고, 의존성을 따라가고, 영향을 받을 부분을 파악하는 데 많은 시간을 사용했습니다.

지금은 AI 코딩 도구가 그 과정을 상당 부분 대신해주고 있습니다. 필요한 기능을 설명하면 관련 파일을 찾아주고, 코드의 흐름을 요약해주며, 수정이 필요한 위치와 영향 범위까지 함께 분석해줍니다. 덕분에 개발자는 코드를 찾는 시간보다 문제를 정의하고 결과를 검토하는 시간에 더 집중할 수 있게 되었습니다.

특히 Claude Code 같은 도구는 단순히 코드 자동완성 수준이 아니라 프로젝트 전체를 이해하면서 작업하기 때문에, 대규모 코드베이스일수록 생산성 향상을 더 크게 체감하고 있습니다.

그래서 저는 앞으로 개발자의 역할도 조금씩 바뀐다고 생각합니다. 예전에는 코드를 얼마나 빨리 작성하느냐가 중요했다면, 지금은 AI에게 문제를 얼마나 명확하게 설명하고, 나온 결과를 얼마나 정확하게 판단할 수 있느냐가 더 중요한 역량이 되어가고 있다고 생각합니다.