AX는 누구 일일까요? 허브와 스포크 사이 회색지대
원고 제공 | 백상현 이노핏파트너스 파트너 강사 · AI 풀스택 엔지니어
편집 | 이노핏파트너스 사업기획팀
📜Contents
배경 충분히 설명하기
작게 만들어 먼저 써보기
실패를 기록으로 남기기
사람이 계속 판단하기
'AI 툴 활용법' 시리즈 2편입니다. 1편 구글 워크스페이스에 이어, 이번 호는 클로드 활용법을 다룹니다. 다음 3편은 코덱스 활용법입니다.
→
기업이 AI 전환(AX)을 조직할 때는 흔히 허브(hub, 표준·플랫폼·거버넌스를 담당하는 중앙 전담조직)와 스포크(spoke, 실제 업무를 아는 현업 부서)로 역할을 나눕니다. 문제는 둘 중 누구 몫인지 애매한 회색지대인데, '아이디어를 작게 만들어보고 판단하는 일'이 여기에 속합니다.
최근엔 스포크, 즉 현업의 참여가 눈에 띄게 커졌습니다. 허브가 인프라·정책·거버넌스에 집중하는 사이, 속도가 필요한 현업이 AI 도입 과제를 직접 풀기 시작했습니다. 동시에 AI 덕분에 코드 제작 비용까지 낮아지면서, 직접 풀 수 있는 환경이 가능해졌습니다. 이렇게 작게 만들어보는 순간 최종 사용자가 개발 과정에 합류한 것과 다름없어지기 때문에, 현장 적용률도 드라마틱하게 오릅니다.
이번 2편은 반복되는 뉴스 확인 업무를 클로드(Claude Code)로 풀어낸 이야기입니다. 다만 이 글이 정말 다루는 것은 도구 사용법이 아니라 순서입니다. 큰 예산을 들여 전사 도입을 결정하기 전에, 현업이 먼저 작게 만들어보고 판단하는 순서입니다. 다만 그 작은 성공이 우연으로 끝나지 않으려면, 실패까지도 그냥 넘기지 않고 기록으로 남기는 습관이 필요합니다. 이번 111호에서는 필자가 AI 뉴스 서비스를 만들고 운영하며 반복한 이 네 가지 습관을 살펴봅니다.
🗣️1) 배경 충분히 설명하기
AI 소식을 따라가려면 여러 사이트를 돌아다녀야 했습니다. 겨우 찾은 소식도 영어 원문이면 읽는 데 또 힘이 들었습니다. 새로운 기술을 아는 것은 좋았지만, 같은 수고를 매일 반복하는 일은 번거로웠습니다. 필자가 지금 운영하는 AI 뉴스 서비스는 이 불편에서 출발했습니다.
AI에게 이 문제를 맡길 때도 특별한 명령어나 형식을 먼저 찾지는 않았습니다. 친구에게 상황을 설명하듯 이야기했습니다. 다만 상대가 모를 배경은 최대한 알려주려 했습니다. 여러 사이트를 찾아다니고 있다는 점, 영어 원문을 읽기 어렵다는 점, 우선 본인이 볼 뉴스가 필요하다는 점이 그 배경이었습니다. 원하는 기능만 나열하는 것보다 왜 필요한지를 함께 말해야, 결과를 보고 무엇을 고칠지도 분명해집니다.
클로드 코드를 사용한 범위도 코드 작성에만 머물지 않았습니다. 생각을 구체화하고, 구현 가능성을 검토하고, 실제 결과로 옮기는 과정 전체에 함께 썼습니다. 다만 출발점을 정하고 필요한 맥락을 채워 넣는 일, 그리고 AI가 만들어 온 결과에 설명을 더하며 작은 단위로 다시 확인하는 일은 필자의 몫이었습니다. 원하는 바를 AI가 처음부터 다 알고 있다고 전제하지 않는 것이 중요했습니다.
🧩2) 작게 만들어 먼저 써보기
AI 없이 개발하던 때, 코드는 비싼 것이었습니다. 아이디어가 있어도 실제로 만들어 확인하기까지 시간과 품이 많이 들었습니다. AI와 함께 구현하면서 그 비용은 낮아졌습니다. 코드가 싸진 만큼, 작은 아이디어를 실제로 만들어보고 판단할 수 있는 여지도 커졌습니다.
그래서 필자는 PoC(아이디어의 핵심이 실제로 가능한지 작은 결과물로 먼저 확인하는 실험)가 더 중요해졌다고 말합니다. 구현할 수 있다는 사실만이 아니라, 직접 써봤을 때 불편이 실제로 줄어드는지를 함께 봐야 합니다. 다음 기능을 붙일지, 여기서 멈출지는 그 결과를 보고 정합니다.
이 서비스에서도 먼저 확인하고 싶었던 것은 뉴스를 모아 정리한 결과가 필자 본인이 읽기에 쓸 만한가였습니다. 이렇게 시작한 프로젝트 대부분이 만들어 보니 쓸 이유가 없어 접은 경우였습니다. 처음부터 크게 벌이지 않으니, 실험을 접을 때의 비용도 작았습니다.
기능이 있다는 설명만으로는 알 수 없었던 읽는 경험을, 결과가 생긴 다음에야 판단할 수 있었습니다. 처음에는 본인이 편해진 것만으로도 의미가 있었지만, 공유하고 나니 매일 찾아 읽는 사람이 생겼고 감사하다는 메일도 왔습니다. 혼자 겪던 작은 불편이 다른 사람에게도 있었던 셈입니다.
📝3) 실패를 기록으로 남기기
만들고 나서 자주 부딪힌 문제는 수집 실패였습니다. 정해진 시간에 자동으로 돌아가도록 했다고 해서, 늘 원하는 결과가 나오는 것은 아니었습니다. 그래서 수집 로그를 남기기 시작했습니다. 문제가 생겼을 때 막연히 다시 시도하는 대신, 어디에서 어떤 일이 있었는지 볼 수 있는 기록이 필요했습니다. 처음 기획할 때는 절실하지 않았던 이 기능은, 실제로 운영해보고 나서야 다음 개발 과제가 됐습니다.
지금의 서비스는 여러 출처에서 뉴스를 가져와 중복을 걸러내고, 분류하고 편집한 뒤 발행하는 흐름으로 운영됩니다. 운영 화면에서는 소스별 실행 횟수와 성공률, 새 기사와 중복 기사 수 등을 확인할 수 있습니다. 다만 수집에 성공했다는 기록만으로 글의 내용까지 좋다고 판단할 수는 없어서, 결과를 직접 읽는 일은 여전히 필요합니다.
여기서 클로드 코드로 자동화를 개발하는 일과, 완성된 프로그램이 정해진 시간에 뉴스를 처리하는 일은 구분할 필요가 있습니다. 필자가 말하는 작업 환경, 또는 하네스(아이디어를 실제 작업으로 이어주고, 실행 결과와 실패 기록을 다시 확인할 수 있게 해둔 작업 체계)도 이런 맥락입니다. 일단 써보면 어디가 자주 실패하는지, 무엇을 더 확인해야 하는지가 드러납니다. 그 경험을 다음 작업의 재료로 삼는 것입니다.
💡4) 사람이 계속 판단하기
필자가 결과를 볼 때 중요하게 여기는 기준은 직접 읽었을 때 괴리감이 없는가입니다. AI가 작업을 많이 수행하더라도, 그 결과가 의도에 맞는지 판단하는 역할까지 사라지지는 않습니다. 자동으로 발행되는 과정이 있는 만큼, 사람이 어떤 기준으로 결과를 점검하고 개선할지도 계속 고민해야 합니다.
지금 서비스에는 기사에서 원문으로 이동하는 링크도 있습니다. 요약을 읽는 편리함과, 내용이 의도에 맞는지 살펴보는 일은 함께 가야 한다는 생각 때문입니다.
이런 습관은 새로운 아이디어를 대할 때도 이어집니다. 필자는 휴대폰과 컴퓨터에서 늘 켜져 있는 에이전트에게 그때그때 떠오른 아이디어를 전합니다. 그렇다고 떠오르는 모든 생각을 큰 프로젝트로 만들지는 않습니다. 지금 확인하고 싶은 한 가지가 무엇인지부터 정하고, 작게 만들어본 뒤 실제로 쓸 만하면 살을 붙입니다.
코드를 만드는 비용이 낮아진 지금, 오히려 중요해진 것은 직접 확인하는 횟수와 판단입니다. 업무에서 시작한다면 매번 찾아보는 정보나 반복해서 정리하는 자료 하나면 충분합니다. 왜 번거로운지 배경을 설명하고, 가장 작은 결과를 만들어 직접 써보는 것부터 시작하면 됩니다.
이 순서를 조직 단위로 옮기면, 회색지대의 상당 부분이 스포크(현업) 쪽으로 채워지는 흐름과 만납니다. 처음부터 전사 도입을 전제로 기획하면, 검증되지 않은 가정 위에 예산과 일정부터 쌓입니다. 반대로 현업이 먼저 작게 만들어보고 그 결과를 기록해두면, 허브는 어디까지 표준화하고 어디부터 현업에 맡길지를 실제 근거로 판단할 수 있습니다. 다만 이 작은 성공을 시작한 사람 한 명에게서 끝나지 않고 조직의 습관으로 자리 잡으려면, 곁에서 판단 기준을 함께 세워줄 파트너가 필요합니다.
혼자 겪던 작은 불편에서 시작한 실험이, 매일 찾아 읽는 서비스로 이어졌습니다. 그 사이 계속 반복된 것은 배경을 충분히 설명하고, 작게 만들어보고, 실패를 기록하고, 결과를 직접 확인하는 네 가지 습관이었습니다. 다음 호에도 'AI 툴 활용법' 시리즈가 이어집니다. 3편에서는 코덱스를 실무 개발에 활용한 사례를 다룹니다.
🤝 이노핏파트너스는 이렇게 함께합니다
이 습관을 현업 한 사람의 재능에 맡겨두지 않습니다.
현업이 직접 과제를 들고 와 작게 만들어보는 PoC부터,
그 결과를 기록하고 계속 판단하는 마인드셋까지 함께 교육합니다.