심 혁주 베이글코드의 ‘AI First’는 AI와 함께 성장의 영역을 넓혀가는 여정입니다.
<AI First, with Bagels>는 그 길 위에 선 동료들의 생생한 목소리를 담습니다.
[Vol. 7 – AI Lab팀 전임송님]
: AI 전도사의 다음 질문
예방주사. 기미상궁. 전도사.
임송님에게 본인이 하는 일을 설명해달라고 했더니 세 가지로 표현했습니다.
먼저 써보고 시행착오를 줄일 수 있는 방향을 잡아주는 ‘예방주사’.
새로운 AI 기술을 현업에 올리기 전에 먼저 맛보고, 우리 일에 맞는지 판단하고, 위험하거나 불필요한 부분을 걸러내는 ‘기미상궁’.
AI를 어렵고 먼 기술이 아니라, 실제 업무에 도움이 되는 도구로 확산시킨다는 점에서 ‘전도사’.
세 단어가 가리키는 방향은 하나입니다. 먼저 해보고, 구분해서, 퍼뜨린다.
1. AI Lab 합류, 곳곳에 닿은 손길
AI Lab은 AI 트렌드를 지속적으로 연구하고 이를 실제 업무에 적용해 전사 생산성 향상에 기여하는 팀입니다. 직접 툴을 개발하고 다른 팀으로 찾아가 함께 문제를 해결하기도 합니다.
임송님은 공채 4기로 입사해 데이터&AI팀에서 1년을 보낸 뒤 AI Lab 초기 멤버로 합류했습니다.
합류 이후 임송님이 만든 프로덕트들은 사내 곳곳에서 쓰이고 있습니다.
코드베이스, 씬스틸러, AI 뉴스 슬랙봇 .
그리고 TODOS까지.
그런데 이 중에 눈에 띄는 점이 있습니다.
이 중 절반은 AI Jam(해커톤)에서 시작돼 실제 업무 도구로 발전했습니다.
프로덕트를 만들 때 임송님이 항상 자신에게 던지는 질문이 있습니다.
‘어떻게 해야지 사용자가 편하고 보기 좋을까.’
처음 코드 베이스를 만들 때부터 그 질문을 놓치지 않았습니다. 기능이 아무리 좋아도, 쓰기 불편하거나 보기에 불편하면 결국 쓰지 않게 됩니다. 임송님이 디자인 디테일을 특히 신경 쓰는 이유입니다.
“프로덕트를 기획할 때 누가 쓰는 지를 가장 먼저 고민해요.
이렇게 말하고 보니 프론트엔드 개발자 같기도 하네요(웃음)”
2. TODOS: 불편함을 가만히 두지 않는다
그 중에서도 가장 많이 이야기하게 되는 건 TODOs입니다.
TODOs는 팀 내 업무를 함께 볼 수 있는 태스크 관리 툴입니다. AI Lab은 Jira를 쓰지 않았습니다. 팀이 작았고, 필요하지 않았습니다. 그런데 팀의 개발 속도가 빠르게 올라가면서 달라졌습니다. 누가 무엇을 하고 있는지 함께 볼 수 있는 것이 필요해졌습니다.
Slack Canvas로 옮겨봤지만 하루도 못 갔습니다. Jira는 입력해야 할 정보가 너무 많았습니다. 빠르게 발전하는 AI 기술, 수많은 업무를 동시에 처리하는 AI Lab의 업무 방식과는 맞지 않았습니다.
그래서 직접 만들기로 했습니다.
핵심 아이디어는 단순했습니다. 복잡한 로그인 없이. 제목·내용·담당자, 꼭 필요한 정보만.
TODO → Claim → Processing → Done의 단순한 흐름.
“3일 만에 팀에 공유할 수 있는 결과물이 나왔어요.
계획하고 디자인하는 부분이 제일 오래 걸렸죠. 구현 자체는 금방 했고요.”
3. TODOS, 사내로 퍼지다
AI First Fair. TODOS 부스에 많은 분들이 찾아왔습니다.
먼저 나온 말은 “예쁘다”였고, 그 다음이 “지라 대체해서 쓰면 좋겠는데요”였습니다.
지라에 불만을 가진 사람이 그렇게 많다는 게 임송님은 놀라웠습니다.
이 고민, 본인만 한 게 아니었던 것입니다.
TODOs 화면
이후 팀별 도입 문의가 들어오기 시작했습니다. P&C팀, GS팀. 팀마다 일하는 방식이 달랐습니다. 임송님은 TODOS의 방향을 틀지 않았습니다. 대신 각 팀에 격리된 환경을 따로 세팅해줬습니다. 그 다음은 각 팀이 직접 커스터마이징하는 것.
“제가 세팅만 해드리면 돼요. 클로드 코드나 코덱스 쓰시면 무조건 커스터마이징 할 수 있어요.
본인 업무에 맞게 직접 하시는 게 최고죠.”
임송님이 원한 그림이 바로 이것이었습니다. 세팅은 내가, 나머지는 각 팀이.
4. AI 에이전트와 같이 일하는 방법
임송님이 AI 에이전트와 협업하는 방식입니다.
- 명령이 아니라 소통
AI는 우리 팀의 맥락을 모릅니다. 배경과 이유까지 함께 설명하는 것이 훨씬 낫습니다. - 여러 에이전트를 동시에
하나에 작업을 걸어두고 바로 다음으로 넘어갑니다. 구현보다 판단과 컨텍스트 스위칭이 더 중요해졌습니다. - 문서화는 AI를 위해
나중에 다시 쓸 것 같으면 바로 파일로 저장합니다. 사람이 아니라 AI가 다시 읽을 기록입니다. - 반복되면 구조화
같은 설명을 두 번 이상 하게 된다면, 스킬이나 룰로 만들어야 할 신호입니다. - 무조건 직접 만들지 않는다
이미 좋은 도구들이 많습니다. 개인화가 필요한 부분에서만 직접 만드는 게 낫습니다.
공통점이 있습니다. 모두 AI를 ‘도구’가 아니라 ‘같이 일하는 상대’로 대하는 방식입니다.
맥락을 공유하고, 역할을 나누고, 반복을 줄이는 것. 사람과 협업하는 방식과 크게 다르지 않습니다.
그리고 하나 더.
AI 덕분에 뭐든 빠르게 만들 수 있게 됐다고 해서 무조건 다 만드는 게 맞지는 않습니다.
임송님은 이 균형을 찾는 것 자체가 지금 시대에 가장 중요한 판단력이라고 말합니다.
5. AI 에이전트 드리븐 문화의 안착
사내에서 AI를 가장 적극적으로 알리고 확산시키는 역할을 해온 사람으로서,
지금 회사 분위기가 어떤 것 같냐고 물었습니다.
슬랙 ‘AI help for Beginner’ 채널에서 임송님은 변화를 체감하고 있습니다.
“꽤 오래된 채널인데, 거기에 글이 올라오는 속도가 달라졌어요. 진짜 단기간 안에 진짜 많이 바뀌었어요. AI Fair하고 게임잼 이후로 그냥 회사 전체 분위기가 그렇게 바뀐 게 확실히 체감이 돼요.”
AI를 잘 모르는 분들도 이제는 자유롭게 물어보고, 알게 된 것을 흔쾌히 나누는 분위기가 자리를 잡았습니다. 직접 툴을 만들어보는 모습들, 채널에 공유되는 이야기들. 임송님은 그 변화를 현장에서 매일 보고 있습니다.
처음 챗GPT를 전사 보급했을 때, AI를 어떻게 활용해야 할지 감을 잡지 못하는 분들도 계셨습니다.
수많은 사내 행사들을 거치고 서로의 경험과 방법을 나누는 문화가 쌓이면서 자연스럽게 자리를 잡았습니다.
강요가 아니라 스며든 변화입니다.
6. 에이전트의 눈으로
“웹이 과연 필요했을까?”
임송님은 모든 프로덕트를 만들 때 당연하게 웹으로 만들었습니다.
사용자는 당연히 사람이라고 생각했으니까요.
그런데 에이전트와 일하면서 달라졌습니다.
에이전트는 웹 화면을 보지 않습니다.
“사람이 볼 거라는 걸 이미 머릿속으로 정해두고 만드니까 웹으로 만들게 되는 거죠.
AI 친화적으로 할 거면 CLI든 MCP든, 굳이 예쁘게 만드는 데 시간을 많이 들일 필요가 없었던 거예요.”
누구를 위해 만드는지가 달라지면, 무엇을 만드는지도 달라집니다.
임송님의 설계 기준에는 이제 사람만이 아니라 에이전트가 함께 들어와 있습니다.
[에디터 한 마디]
먼저 불편을 찾고, 직접 만들고, 기꺼이 퍼뜨리는 사람.
그런 임송님이 요즘 가장 많이 하는 질문은 이것입니다.
'이 툴, 사람만 쓸 건가요?'