아임웹은 약 2년 전부터 AI를 각자 활용하고 있었고, 2025년 초에 공식적으로 AI 비용을 지원하기 시작했습니다. 모든 직군이 각자의 업무에 맞는 툴을 자유롭게 쓸 수 있어요. 엔지니어들에게는 Claude Code Max가 일찍 도입됐고, 개발 직군에서는 이미 AI가 함께 일하는 동료처럼 자리를 잡아가고 있었습니다.
그런데 비개발 직군은 이야기가 조금 달랐습니다. 적극적으로 활용하는 분들도 있었지만, "써보고 싶긴 한데 어디서부터 손대야 할지 모르겠다"는 분들도 꽤 있었어요. 툴을 결제하더라도, 업무에 어떻게 활용해야 할지가 막막한 거죠.
"AI, 좋은 건 알겠는데 제 업무에 어떻게 적용해야 할까요?"
CTO 형섭님이 이런 간격을 좁혀보고자 직접 나섰는데요. 모든 비개발 구성원을 대상으로, 팀별로 1시간씩 AI AMA(Ask Me Anything)를 진행하면서 각 팀이 실제로 부딪히는 어려움을 하나하나 풀어주셨어요. AI가 뭘 할 수 있는지를 설명하기보다, "이렇게 써보면 어때요?"를 직접 보여주고 설명해주셨죠.
AMA를 여러 팀에 걸쳐 진행하면서 형섭님이 발견한 게 있었다고 해요. 질문의 내용은 팀마다 달랐지만, 결국 하고 싶은 건 하나로 모였던 건데요. "내가 반복하는 이 업무를 자동화하고 싶다."
이 공통된 니즈가 모여, 비개발 구성원을 대상으로 한 AX 워크숍이 만들어졌어요. AI를 그저 설명만 하는 게 아니라, 각자 자신의 반복 업무를 하나 들고 와서 실제로 자동화해보는 게 목표였어요. 비개발 구성원들이 자유롭게 시도해볼 수 있도록 하되, 막히는 순간에는 엔지니어 도우미가 옆에서 함께 풀어주는 시간이었어요.
어느 금요일 저녁 7시, 약 40명이 라운지에 모였습니다. 도우미 엔지니어 10명이 테이블마다 배치됐고, 참가자들은 각자 노트북을 열고 Claude Cowork를 켰어요. Cowork는 AI가 직접 브라우저를 제어하면서 웹 기반 업무를 함께 처리할 수 있는 도구라서, 비개발 코딩 없이 업무를 자동화해보고자 하는 취지에 딱 맞았거든요.
AX 워크숍 타임테이블
보는 자리가 아니라, 해보는 자리
Claude Cowork의 기본 사용법과 브라우저 제어를 함께 익힌 뒤, 곧바로 각자의 업무를 떠올리면서 해보고 싶은 시도를 정했습니다.
워크숍 가이드에는 클로드를 잘 쓰기 위해 어떤 환경을 세팅하면 좋은지, 자동화를 만들 때 어떤 순서로 접근하면 좋은지, 완성된 자동화 작업을 동료에게 어떻게 공유할 수 있는지까지 안내가 돼 있어서, 처음 해보는 사람도 시작이 두렵지 않은 자리였어요. 거기에 도우미 엔지니어가 테이블마다 앉아 있으니, 막히더라도 혼자 끙끙댈 일은 없었죠.
옆자리에 앉은 도우미 엔지니어들
이번 워크숍에는 10명의 엔지니어가 도우미로 참여했어요. 테이블마다 앉아서 참가자들이 막힐 때 AI 사용에 대해 조언을 주는 역할이었어요.
도우미를 맡은 Back-end Engineer 창민님에게 어떤 도움을 가장 많이 주셨는지 물어봤어요. 대부분은 크롬 브라우저 확장 프로그램 연결 같은 초기 설정이나, 프롬프트를 어떻게 입력해야 하는지에서 막히셨다고 해요. "이런 것까지 입력해도 되나요?", "한 번에 넣어야 하나요, 끊어서 넣어야 하나요?" 같은 질문이 많았는데, 한두 번 겪고 나면 이후부터는 스스로 해결하시는 모습이 반복됐다고 합니다.
창민님이 도와주는 방식은 ‘일단 스스로 해볼 수 있게 하는 것’이었다고 해요. 에러가 나면 그 메시지를 그대로 클로드에게 다시 물어보게 하고, 프롬프트에 뭘 써야 할지 모르겠다면 일단 생각나는 대로 넣어보게 하는 거였죠. 프롬프트를 한 번에 다 넣어도 되고, 나눠서 넣어도 된다는 걸 직접 확인하고 나면, ‘아, 어떻게 해도 되는구나!’를 깨닫게 된다는 거였어요.
또다른 도우미 SRE 승민님은 참가자들이 AI 자체에 대해 낯설어하기보다, AI에게 말을 거는 방식에서 어려움을 느끼고 있는 것 같다고 말씀 주셨어요. 원하는 건 명확한데 "이거 이렇게 해줘" 정도로 추상적으로 입력하다 보니 AI가 의도를 제대로 못 잡는 거죠. 승민님은 참가자가 원하는 바를 함께 정리한 뒤, 어떻게 구체적으로 전달하면 되는지를 같이 잡아줬어요.
승민님은 그런 상황에서 참가자가 원하는 바를 함께 정리한 뒤, 클로드에게 어떻게 구체적으로 전달하면 되는지를 같이 잡아줬어요. 그 과정에서 기억에 남는 에피소드가 하나 있었습니다.
CX팀에서 슬랙 메시지에 볼드체가 안 먹힌다고 하시길래 봤더니, 슬랙이랑 클로드의 마크다운 규칙이 달라서 생긴 문제였어요. 클로드에게 왜 볼드체로 가지 않는다고 추상적인 프롬프트를 하니 해결이 잘 안 되고 있었더라고요. '신입 직원에게 업무를 인계하듯이 구체적으로 디렉션을 주시면 더 좋은 결과가 나와요'라고 안내했더니, CX팀이 이걸 정말 좋아하셨어요.
여러 도우미분들이 언급하는 공통적인 현상은, 참가자들이 아직 AI를 과소평가하고 있다는 것이었어요. "AI가 이런 것까지 해준다고?"라는 반응이 정말 많았고, 스킬이나 정책 같은 클로드의 커스텀 기능을 최대한 알려드리려고 신경 썼다고 합니다.
하지만 AI의 기능이 무궁무진하듯, 비개발 구성원분들의 가능성도 무한한 것 같다는 이야기도 있었어요. 개발자들은 정형화된 방식에 익숙한데, 참가자들은 완전히 다른 접근으로 창의적인 아이디어를 자유롭게 내셨다고요. 창민님은 참가자와 함께 본인도 처음 해보는 복잡한 자동화를 실험했는데, 결국 해결한 순간이 너무 뿌듯했다고 해요.
도우미와 참가자가 함께 미지의 문제를 풀어나가는 장면이 곳곳에서 많이 보였습니다.
AI에게 맡기지 않을 것을 미리 정합니다
참가자들에게는 처음부터 정해둔 원칙이 있었어요. 저장, 게시, 삭제, 발송, 결제, 권한 변경처럼 중요한 작업은 자동으로 끝까지 진행하지 않고, 반드시 사람이 확인하게끔 한다. 고객 개인정보, 인사, 평가, 급여 같은 민감 정보는 실습에 넣지 않는다.
이 원칙은 비개발자도 안심하고 시도할 수 있게 만드는 가드레일 역할을 해주었어요. ‘뭘 잘못 건드리면 어쩌지’라는 걱정이 있으면 첫 시도 자체가 어렵지만, 경계가 명확하면 그 안에서는 마음껏 실험할 수 있으니까요.
실제로 이 원칙이 작동한 순간이 있었어요. 슬랙 메시지로 자동 발송을 설정하면서 굳이 노출되지 않아도 될 정보가 슬랙에 노출될 수 있다는 걸 발견했습니다. 클로드에게 마스킹을 추가로 요청했고, 마스킹이 적용된 형태로 결과물이 수정됐어요. 미리 설정된 가드레일이 있었기 때문에 이런 순간을 의식적으로 방지할 수 있었습니다.
이런 변화를 만들었어요
워크숍에서 참가자들이 자기 업무로 만든 결과물 중 세 가지를 소개할게요.
Business Development Team 주현님 — 이제 제휴 문의 정리보다 대응에 집중할 수 있어요
BD팀에 제휴 문의가 꾸준히 들어옵니다. 문제는 이 문의의 원문을 확인하려면 매번 CS 채널에 다시 접속해서 내용을 처음부터 읽어야 했다는 거예요. 게다가 문의 내용이 텍스트로 장황한 경우가 많아서, 유효한 문의인지 아닌지를 빠르게 판단하기가 어려웠습니다.
주현님은 이 흐름 전체를 자동화했어요. 제휴 문의가 들어오면 AI가 내용을 분석해서 문의자 정보와 핵심 내용을 요약하고, 슬랙 스레드에 자동으로 정리해주는 구조를 만든 거예요.
만드는 과정에서 한 가지 문제가 발견됐어요. AI가 요약하면서 문의자의 휴대폰 번호와 이메일 주소까지 그대로 슬랙에 노출되는 리스크가 있는 거죠. 주현님은 앞서 언급한 가이드를 참고해서 개인정보 마스킹을 추가로 요청했고, AI가 이름은 **, 이메일 앞부분은 ***, 연락처 가운데 자리는 ****로 처리하는 형태로 결과물이 수정됐습니다.
완성된 다음 날, BD팀 슬랙 채널에 문의 요약 메시지가 올라왔어요. 팀 동료들이 "오 주현님 워크숍 결과군요!!"라고 열렬히 반응했고, 주현님은 이렇게 답했어요.
"실습해보니 너무 신기하고 이제야 어떻게 써야 할지 감이 잡혀요!"
주현님은 이날 두 가지를 시도해 둘 다 성공하셨는데요. 또 다른 하나는 매주 월요일 OKR 지표를 태블로에서 구글시트로 옮기는 반복 작업이었는데, 이것도 깔끔하게 자동화됐습니다. 한 번 감이 잡히니까 바로 두 번째 시도까지 해낸 거죠.
People Team 혜원님 — 매일 오후 1시 30분, 클로드가 허락을 맡으러 와요
백엔드 개발자 채용에는 7개 스쿼드별 공고가 있고, 수많은 지원자가 각기 다른 공고에 지원합니다. 지원자가 발생하면 리뷰어를 배정해야 하는데, A,B,C 세 개의 리뷰어 그룹 중 하나로 배정을 하고 있어요.
어떤 그룹으로 배정할지를 결정하는 데는 매번 나름의 판단이 필요했다고 해요. 후보자가 지원한 스쿼드에 속한 리뷰어를 우선 배정하는데, 이게 필수인 스쿼드도 있고 아닌 곳도 있죠. 또, 인터뷰가 많이 잡혀 있거나 리뷰가 이미 몰려 있는 리뷰어에게는 추가 배정을 최대한 지양하려고 신경써야 하고요. 이런 사소한 요소들을 매번 캘린더와 슬랙 히스토리를 보면서 혜원님이 직접 판단하고 있었다고 해요.
‘판단을 자동화하겠다’는 비장한 목표로, 혜원님은 하고 싶은 일을 클로드에게 줄줄 늘어놓았어요. 그런데 한참을 입력했더니 클로드가 되물었습니다. "그래서 정확히 어떤 과정을 자동화하고 싶은 거야?" 혜원님은 추상적인 요청사항을 무작정 넣기보다는 원하는 결과물을 명확히 정해야 한다는 걸 깨달았다고 해요.
그리고 처음에 Sonnet으로 시도했을 때는 복잡한 판단이 많아서인지 계속 멈추고 진행이 안 됐어요. 모델을 Opus로 바꾸니까 클로드가 필요한 질문을 알아서 던져주면서 하나씩 풀려나가기 시작했고요. 모델 선택도 효율과 결과에 큰 차이를 만든다는 걸 느꼈다고 해요.
결과적으로 만들어진 건 노션 기반 배정 시스템이에요. '입력용' 시트에 지원자 이름, 지원자의 프로필 링크, 리뷰 마감 기한을 넣으면 클로드가 조건에 맞는 리뷰어 그룹을 알아서 배정하고, 슬랙 메시지 초안까지 깔끔하게 정리해줍니다.
자동으로 배정된 결과를 나타내는 클로드 화면
지금은 매일 오후 1시 30분에 클로드가 "이렇게 배정해서 이렇게 메시지 보내면 될까요?"라고 물어봐요. ‘승인’ 두 글자만 치면 백엔드 채용 슬랙 채널에 리뷰 요청이 올라갑니다. 며칠 동안 잘 사용하고 있는데 제가 평소에 배정하던 패턴과 차이가 전혀 없어요. 이게 없었다면 여전히 후보자에게 어떤 리뷰어를 배정할지를 일일이 고민하면서, 매일 소중한 시간을 쓰고 있었을 거예요.
CX Team 윤선님 — 고객의 목소리가 제품팀에 도달하는 속도를 바꿨어요
아임웹에서 CX는 단순히 고객 문의에 답변을 드리는 데서 끝나지 않아요. 고객이 어디에서 어려움을 느끼는지, 그 온도가 어떤지를 파악하고 분석해서 제품팀에 전달하는 허브 역할입니다. 그래서 고객 이슈가 들어오면 답변만 하는 게 아니라, 제품 개선으로 이어질 수 있도록 지라(Jira) 티켓을 만들어 개발팀에 연결하는 작업이 중요해요.
문제는 이 과정이 전부 수동이었다는 거예요. 문의가 들어오면 내용을 읽고, 핵심을 정리하고, 지라에 들어가서 티켓을 만들고, 필요한 필드를 하나하나 채워 넣는 작업을 매번 담당자가 직접 했습니다. 고객의 목소리를 제품팀까지 연결하는 일이 중요한 만큼, 이 과정이 빨라지면 CX팀 전체의 일하는 방식이 달라질 수 있는 부분이었어요.
클로드가 자동으로 만든 지라 티켓 내용
윤선님은 상담 화면에 '지라 작성'이라고 입력하면 클로드가 대화 내용을 분석해서 지라 티켓을 자동으로 생성해주는 자동화를 시도했습니다. 도우미 승민님이 옆에 있었기 때문에, 윤선님이 원하는 걸 클로드에게 어떻게 구체적으로 전달할 수 있는지를 배우면서 완성됐어요.
윤선님은 팀에서 바로 쓸 수 있도록 프롬프트를 요약해서 전달했어요. 이게 이번 워크숍의 가장 큰 목적이기도 했습니다. 자신이 만든 자동화를 혼자 쓰는 데서 끝내지 않고, 팀 전체가 반복 업무를 줄이는 방식으로 확장하는 것이죠.
AX 워크숍, 좋았던 점과 아쉬웠던 점
열기는 밤 11시가 넘는 시간까지 이어졌어요. 상상만 했던 방식이 자동화로 구현되는 순간 박수와 환호가 터지기도 했고, 옆 테이블에서 "오 된다!"하는 소리가 들리면 우루루 몰려가서 같이 구경을 하기도 했습니다.
기대보다 잘 된 건 도우미들의 활약였어요. 대신 해주는 게 아니라, 스스로 해볼 수 있게 옆에서 유도하는 방식이 근본적인 진입 장벽을 허무는 데 큰 도움이 됐습니다. 어려운 첫 시도만 함께 넘기면, 그다음부터는 비개발자도 문제를 혼자 풀어나가는 모습이 반복됐어요.
반면 아쉬운 점도 있었는데요. 함께 만든 자동화가 다 일상적으로 쓰이는 건 아닙니다. 어떤 건 연결 이슈를 더 풀어야 하고, 어떤 건 업무 환경에 맞게 조정이 필요하고요. 그래도 이걸 실패라고 부르진 않아요. 내가 직접 무언갈 만들 수 있다는 자신감, 그게 이번 워크숍이 남긴 가장 큰 결과라고 생각합니다.
AX는 누가 쓰느냐가 아니라, 누구나 쓸 수 있느냐의 문제예요
전사에 AI 도구를 지원하기 시작했을 때, "시작 비용을 줄이면 실행이 빨라진다"고 말씀드렸죠. 이번 콘텐츠는 그 다음 단계의 이야기입니다.
툴을 제공하는 것만으로는 충분하지 않았어요. AI AMA에서 가장 많이 나온 말이 "내 반복 업무를 자동화하고 싶다"였다는 건, 각자의 업무에 적용하는 방법을 모르면 변화가 일어나지 않는다는 뜻이었습니다.
그래서 워크숍을 설계했어요. AI를 업무에 편하게 적용할 수 있는 환경을 마련하는 걸 도와주고, 도우미가 옆에서 첫 시도를 함께 해주고, 한 번 된 걸 반복 가능하게 바꾸고, 동료에게 공유할 수 있게 정리하는 것까지. 이 전체 과정이 가능할 때, AI는 진정한 ‘일하는 방식’이 되기 때문입니다.
아임웹이 말하는 AI native는 개발자에게 한정되는 게 아니에요. CX도, BD도, 리크루터도 AI를 능숙하게 다룰 수 있는 환경까지 함께 만드는 것. 그게 아임웹이 추구하는 AX입니다.
imweb Corp.
아임웹은 약 2년 전부터 AI를 각자 활용하고 있었고, 2025년 초에 공식적으로 AI 비용을 지원하기 시작했습니다. 모든 직군이 각자의 업무에 맞는 툴을 자유롭게 쓸 수 있어요. 엔지니어들에게는 Claude Code Max가 일찍 도입됐고, 개발 직군에서는 이미 AI가 함께 일하는 동료처럼 자리를 잡아가고 있었습니다.
그런데 비개발 직군은 이야기가 조금 달랐습니다. 적극적으로 활용하는 분들도 있었지만, "써보고 싶긴 한데 어디서부터 손대야 할지 모르겠다"는 분들도 꽤 있었어요. 툴을 결제하더라도, 업무에 어떻게 활용해야 할지가 막막한 거죠.
"AI, 좋은 건 알겠는데 제 업무에 어떻게 적용해야 할까요?"
CTO 형섭님이 이런 간격을 좁혀보고자 직접 나섰는데요. 모든 비개발 구성원을 대상으로, 팀별로 1시간씩 AI AMA(Ask Me Anything)를 진행하면서 각 팀이 실제로 부딪히는 어려움을 하나하나 풀어주셨어요. AI가 뭘 할 수 있는지를 설명하기보다, "이렇게 써보면 어때요?"를 직접 보여주고 설명해주셨죠.
AMA를 여러 팀에 걸쳐 진행하면서 형섭님이 발견한 게 있었다고 해요. 질문의 내용은 팀마다 달랐지만, 결국 하고 싶은 건 하나로 모였던 건데요. "내가 반복하는 이 업무를 자동화하고 싶다."
이 공통된 니즈가 모여, 비개발 구성원을 대상으로 한 AX 워크숍이 만들어졌어요. AI를 그저 설명만 하는 게 아니라, 각자 자신의 반복 업무를 하나 들고 와서 실제로 자동화해보는 게 목표였어요. 비개발 구성원들이 자유롭게 시도해볼 수 있도록 하되, 막히는 순간에는 엔지니어 도우미가 옆에서 함께 풀어주는 시간이었어요.
어느 금요일 저녁 7시, 약 40명이 라운지에 모였습니다. 도우미 엔지니어 10명이 테이블마다 배치됐고, 참가자들은 각자 노트북을 열고 Claude Cowork를 켰어요. Cowork는 AI가 직접 브라우저를 제어하면서 웹 기반 업무를 함께 처리할 수 있는 도구라서, 비개발 코딩 없이 업무를 자동화해보고자 하는 취지에 딱 맞았거든요.
AX 워크숍 타임테이블
보는 자리가 아니라, 해보는 자리
Claude Cowork의 기본 사용법과 브라우저 제어를 함께 익힌 뒤, 곧바로 각자의 업무를 떠올리면서 해보고 싶은 시도를 정했습니다.
워크숍 가이드에는 클로드를 잘 쓰기 위해 어떤 환경을 세팅하면 좋은지, 자동화를 만들 때 어떤 순서로 접근하면 좋은지, 완성된 자동화 작업을 동료에게 어떻게 공유할 수 있는지까지 안내가 돼 있어서, 처음 해보는 사람도 시작이 두렵지 않은 자리였어요. 거기에 도우미 엔지니어가 테이블마다 앉아 있으니, 막히더라도 혼자 끙끙댈 일은 없었죠.
옆자리에 앉은 도우미 엔지니어들
이번 워크숍에는 10명의 엔지니어가 도우미로 참여했어요. 테이블마다 앉아서 참가자들이 막힐 때 AI 사용에 대해 조언을 주는 역할이었어요.
도우미를 맡은 Back-end Engineer 창민님에게 어떤 도움을 가장 많이 주셨는지 물어봤어요. 대부분은 크롬 브라우저 확장 프로그램 연결 같은 초기 설정이나, 프롬프트를 어떻게 입력해야 하는지에서 막히셨다고 해요. "이런 것까지 입력해도 되나요?", "한 번에 넣어야 하나요, 끊어서 넣어야 하나요?" 같은 질문이 많았는데, 한두 번 겪고 나면 이후부터는 스스로 해결하시는 모습이 반복됐다고 합니다.
창민님이 도와주는 방식은 ‘일단 스스로 해볼 수 있게 하는 것’이었다고 해요. 에러가 나면 그 메시지를 그대로 클로드에게 다시 물어보게 하고, 프롬프트에 뭘 써야 할지 모르겠다면 일단 생각나는 대로 넣어보게 하는 거였죠. 프롬프트를 한 번에 다 넣어도 되고, 나눠서 넣어도 된다는 걸 직접 확인하고 나면, ‘아, 어떻게 해도 되는구나!’를 깨닫게 된다는 거였어요.
또다른 도우미 SRE 승민님은 참가자들이 AI 자체에 대해 낯설어하기보다, AI에게 말을 거는 방식에서 어려움을 느끼고 있는 것 같다고 말씀 주셨어요. 원하는 건 명확한데 "이거 이렇게 해줘" 정도로 추상적으로 입력하다 보니 AI가 의도를 제대로 못 잡는 거죠. 승민님은 참가자가 원하는 바를 함께 정리한 뒤, 어떻게 구체적으로 전달하면 되는지를 같이 잡아줬어요.
승민님은 그런 상황에서 참가자가 원하는 바를 함께 정리한 뒤, 클로드에게 어떻게 구체적으로 전달하면 되는지를 같이 잡아줬어요. 그 과정에서 기억에 남는 에피소드가 하나 있었습니다.
여러 도우미분들이 언급하는 공통적인 현상은, 참가자들이 아직 AI를 과소평가하고 있다는 것이었어요. "AI가 이런 것까지 해준다고?"라는 반응이 정말 많았고, 스킬이나 정책 같은 클로드의 커스텀 기능을 최대한 알려드리려고 신경 썼다고 합니다.
하지만 AI의 기능이 무궁무진하듯, 비개발 구성원분들의 가능성도 무한한 것 같다는 이야기도 있었어요. 개발자들은 정형화된 방식에 익숙한데, 참가자들은 완전히 다른 접근으로 창의적인 아이디어를 자유롭게 내셨다고요. 창민님은 참가자와 함께 본인도 처음 해보는 복잡한 자동화를 실험했는데, 결국 해결한 순간이 너무 뿌듯했다고 해요.
도우미와 참가자가 함께 미지의 문제를 풀어나가는 장면이 곳곳에서 많이 보였습니다.
AI에게 맡기지 않을 것을 미리 정합니다
참가자들에게는 처음부터 정해둔 원칙이 있었어요. 저장, 게시, 삭제, 발송, 결제, 권한 변경처럼 중요한 작업은 자동으로 끝까지 진행하지 않고, 반드시 사람이 확인하게끔 한다. 고객 개인정보, 인사, 평가, 급여 같은 민감 정보는 실습에 넣지 않는다.
이 원칙은 비개발자도 안심하고 시도할 수 있게 만드는 가드레일 역할을 해주었어요. ‘뭘 잘못 건드리면 어쩌지’라는 걱정이 있으면 첫 시도 자체가 어렵지만, 경계가 명확하면 그 안에서는 마음껏 실험할 수 있으니까요.
실제로 이 원칙이 작동한 순간이 있었어요. 슬랙 메시지로 자동 발송을 설정하면서 굳이 노출되지 않아도 될 정보가 슬랙에 노출될 수 있다는 걸 발견했습니다. 클로드에게 마스킹을 추가로 요청했고, 마스킹이 적용된 형태로 결과물이 수정됐어요. 미리 설정된 가드레일이 있었기 때문에 이런 순간을 의식적으로 방지할 수 있었습니다.
이런 변화를 만들었어요
워크숍에서 참가자들이 자기 업무로 만든 결과물 중 세 가지를 소개할게요.
Business Development Team 주현님 — 이제 제휴 문의 정리보다 대응에 집중할 수 있어요
BD팀에 제휴 문의가 꾸준히 들어옵니다. 문제는 이 문의의 원문을 확인하려면 매번 CS 채널에 다시 접속해서 내용을 처음부터 읽어야 했다는 거예요. 게다가 문의 내용이 텍스트로 장황한 경우가 많아서, 유효한 문의인지 아닌지를 빠르게 판단하기가 어려웠습니다.
주현님은 이 흐름 전체를 자동화했어요. 제휴 문의가 들어오면 AI가 내용을 분석해서 문의자 정보와 핵심 내용을 요약하고, 슬랙 스레드에 자동으로 정리해주는 구조를 만든 거예요.
만드는 과정에서 한 가지 문제가 발견됐어요. AI가 요약하면서 문의자의 휴대폰 번호와 이메일 주소까지 그대로 슬랙에 노출되는 리스크가 있는 거죠. 주현님은 앞서 언급한 가이드를 참고해서 개인정보 마스킹을 추가로 요청했고, AI가 이름은 **, 이메일 앞부분은 ***, 연락처 가운데 자리는 ****로 처리하는 형태로 결과물이 수정됐습니다.
완성된 다음 날, BD팀 슬랙 채널에 문의 요약 메시지가 올라왔어요. 팀 동료들이 "오 주현님 워크숍 결과군요!!"라고 열렬히 반응했고, 주현님은 이렇게 답했어요.
주현님은 이날 두 가지를 시도해 둘 다 성공하셨는데요. 또 다른 하나는 매주 월요일 OKR 지표를 태블로에서 구글시트로 옮기는 반복 작업이었는데, 이것도 깔끔하게 자동화됐습니다. 한 번 감이 잡히니까 바로 두 번째 시도까지 해낸 거죠.
People Team 혜원님 — 매일 오후 1시 30분, 클로드가 허락을 맡으러 와요
백엔드 개발자 채용에는 7개 스쿼드별 공고가 있고, 수많은 지원자가 각기 다른 공고에 지원합니다. 지원자가 발생하면 리뷰어를 배정해야 하는데, A,B,C 세 개의 리뷰어 그룹 중 하나로 배정을 하고 있어요.
어떤 그룹으로 배정할지를 결정하는 데는 매번 나름의 판단이 필요했다고 해요. 후보자가 지원한 스쿼드에 속한 리뷰어를 우선 배정하는데, 이게 필수인 스쿼드도 있고 아닌 곳도 있죠. 또, 인터뷰가 많이 잡혀 있거나 리뷰가 이미 몰려 있는 리뷰어에게는 추가 배정을 최대한 지양하려고 신경써야 하고요. 이런 사소한 요소들을 매번 캘린더와 슬랙 히스토리를 보면서 혜원님이 직접 판단하고 있었다고 해요.
‘판단을 자동화하겠다’는 비장한 목표로, 혜원님은 하고 싶은 일을 클로드에게 줄줄 늘어놓았어요. 그런데 한참을 입력했더니 클로드가 되물었습니다. "그래서 정확히 어떤 과정을 자동화하고 싶은 거야?" 혜원님은 추상적인 요청사항을 무작정 넣기보다는 원하는 결과물을 명확히 정해야 한다는 걸 깨달았다고 해요.
그리고 처음에 Sonnet으로 시도했을 때는 복잡한 판단이 많아서인지 계속 멈추고 진행이 안 됐어요. 모델을 Opus로 바꾸니까 클로드가 필요한 질문을 알아서 던져주면서 하나씩 풀려나가기 시작했고요. 모델 선택도 효율과 결과에 큰 차이를 만든다는 걸 느꼈다고 해요.
결과적으로 만들어진 건 노션 기반 배정 시스템이에요. '입력용' 시트에 지원자 이름, 지원자의 프로필 링크, 리뷰 마감 기한을 넣으면 클로드가 조건에 맞는 리뷰어 그룹을 알아서 배정하고, 슬랙 메시지 초안까지 깔끔하게 정리해줍니다.
자동으로 배정된 결과를 나타내는 클로드 화면
CX Team 윤선님 — 고객의 목소리가 제품팀에 도달하는 속도를 바꿨어요
아임웹에서 CX는 단순히 고객 문의에 답변을 드리는 데서 끝나지 않아요. 고객이 어디에서 어려움을 느끼는지, 그 온도가 어떤지를 파악하고 분석해서 제품팀에 전달하는 허브 역할입니다. 그래서 고객 이슈가 들어오면 답변만 하는 게 아니라, 제품 개선으로 이어질 수 있도록 지라(Jira) 티켓을 만들어 개발팀에 연결하는 작업이 중요해요.
문제는 이 과정이 전부 수동이었다는 거예요. 문의가 들어오면 내용을 읽고, 핵심을 정리하고, 지라에 들어가서 티켓을 만들고, 필요한 필드를 하나하나 채워 넣는 작업을 매번 담당자가 직접 했습니다. 고객의 목소리를 제품팀까지 연결하는 일이 중요한 만큼, 이 과정이 빨라지면 CX팀 전체의 일하는 방식이 달라질 수 있는 부분이었어요.
클로드가 자동으로 만든 지라 티켓 내용
윤선님은 상담 화면에 '지라 작성'이라고 입력하면 클로드가 대화 내용을 분석해서 지라 티켓을 자동으로 생성해주는 자동화를 시도했습니다. 도우미 승민님이 옆에 있었기 때문에, 윤선님이 원하는 걸 클로드에게 어떻게 구체적으로 전달할 수 있는지를 배우면서 완성됐어요.
윤선님은 팀에서 바로 쓸 수 있도록 프롬프트를 요약해서 전달했어요. 이게 이번 워크숍의 가장 큰 목적이기도 했습니다. 자신이 만든 자동화를 혼자 쓰는 데서 끝내지 않고, 팀 전체가 반복 업무를 줄이는 방식으로 확장하는 것이죠.
AX 워크숍, 좋았던 점과 아쉬웠던 점
열기는 밤 11시가 넘는 시간까지 이어졌어요. 상상만 했던 방식이 자동화로 구현되는 순간 박수와 환호가 터지기도 했고, 옆 테이블에서 "오 된다!"하는 소리가 들리면 우루루 몰려가서 같이 구경을 하기도 했습니다.
기대보다 잘 된 건 도우미들의 활약였어요. 대신 해주는 게 아니라, 스스로 해볼 수 있게 옆에서 유도하는 방식이 근본적인 진입 장벽을 허무는 데 큰 도움이 됐습니다. 어려운 첫 시도만 함께 넘기면, 그다음부터는 비개발자도 문제를 혼자 풀어나가는 모습이 반복됐어요.
반면 아쉬운 점도 있었는데요. 함께 만든 자동화가 다 일상적으로 쓰이는 건 아닙니다. 어떤 건 연결 이슈를 더 풀어야 하고, 어떤 건 업무 환경에 맞게 조정이 필요하고요. 그래도 이걸 실패라고 부르진 않아요. 내가 직접 무언갈 만들 수 있다는 자신감, 그게 이번 워크숍이 남긴 가장 큰 결과라고 생각합니다.
AX는 누가 쓰느냐가 아니라, 누구나 쓸 수 있느냐의 문제예요
전사에 AI 도구를 지원하기 시작했을 때, "시작 비용을 줄이면 실행이 빨라진다"고 말씀드렸죠. 이번 콘텐츠는 그 다음 단계의 이야기입니다.
툴을 제공하는 것만으로는 충분하지 않았어요. AI AMA에서 가장 많이 나온 말이 "내 반복 업무를 자동화하고 싶다"였다는 건, 각자의 업무에 적용하는 방법을 모르면 변화가 일어나지 않는다는 뜻이었습니다.
그래서 워크숍을 설계했어요. AI를 업무에 편하게 적용할 수 있는 환경을 마련하는 걸 도와주고, 도우미가 옆에서 첫 시도를 함께 해주고, 한 번 된 걸 반복 가능하게 바꾸고, 동료에게 공유할 수 있게 정리하는 것까지. 이 전체 과정이 가능할 때, AI는 진정한 ‘일하는 방식’이 되기 때문입니다.
아임웹이 말하는 AI native는 개발자에게 한정되는 게 아니에요. CX도, BD도, 리크루터도 AI를 능숙하게 다룰 수 있는 환경까지 함께 만드는 것. 그게 아임웹이 추구하는 AX입니다.
아임웹 팀과 함께 끊임없이 도전하고 성장할 동료를 찾습니다.
아임웹 대규모 채용