😎 오늘의 메이커 : 인프랩 CTO 이동욱(향로)

오늘 함께할 메이커는 누적 가입자 165만 명의 AI·IT 교육 플랫폼 인프런을 운영하는 인프랩의 CTO, 이동욱(향로) 님입니다. 56명의 구성원과 함께 일하며, 사내 인프라와 AI 플랫폼을 지원하는 DevOps 조직을 이끌고 제품 스쿼드의 PM들과 협업하고 계세요.

인프런의 AX는 구성원이 직접 할 수 있는 일의 범위를 넓히는 데서 출발했습니다. 마케터가 프로모션 페이지를 만들고 개발자는 비용과 보안을 검토하는 식으로, 도구의 도입과 함께 업무를 나누는 방식도 달라졌죠. 이렇게 쌓은 도구와 기록은 실제 사용자를 위한 AI 모의면접을 만드는 데도 쓰였습니다.

오늘 인터뷰에서는 AI를 조직에 적용하며 바꾼 업무 기준과 협업 방식, 모의면접의 질문과 피드백을 검증하는 과정, 그리고 빠른 실행을 사업 성과로 연결하기 위해 남아 있는 과제에 대해 이야기 나눴습니다.

레시피 하나, AI를 도입한 뒤 일하는 방식부터 재정의

Q. 안녕하세요, 먼저 팁스터 구독자분들께 인사 부탁드립니다.

안녕하세요. 누적 가입자 165만 명의 AI, IT 교육 플랫폼 인프런을 운영하는 인프랩에서 CTO를 맡고 있는 이동욱입니다. 사내에서는 향로라고 불립니다. 올해 기준으로 전체 조직원은 56명이고, 그중 제품 조직은 26명입니다. 사내 인프라와 AI 플랫폼을 지원하는 DevOps 조직은 제 직속이고, 나머지 제품 스쿼드의 PM 분들과 직접 일하고 있습니다.

에디터 : 제품 조직을 맡으시며, 최근 화두가 되고 있는 AX(AI Transformation)’는 기존의 디지털 전환이나 단순한 AI 도구 도입과는 조금 다른 변화도 겪고 계실 것 같아요.

네, 아무래도 몇 년 전 스타트업 업계에서는 데이터가 흐르는 조직이라는 말을 많이 했습니다. 데이터를 모으고 분석하기 위해 BI 도구도 많이 도입했고요. 요즘 회사마다 AI 도구를 도입하는 모습을 보면 그때가 떠오릅니다. 디지털 전환도 조직이 일하는 방식을 크게 바꾸는 일이었는데, 저는 AX에서는 구성원 각자가 직접 할 수 있는 일의 범위까지 달라진다는 점을 크게 보고 있습니다.

저희 팀에서도 마케터가 직접 프로모션 페이지를 만들고, 개발자에게 비용과 보안 검토를 요청한 일이 있었습니다. 데이터를 보고 무엇을 할지 정하더라도 실제로 구현하려면 다른 직군의 도움을 받아야 하는 일이 많았는데, 이제는 그중 일부를 담당자가 AI와 함께 직접 만들어볼 수 있게 된 것이죠. 그러면 누가 먼저 만들고, 누구에게 무엇을 확인받을지까지 달라집니다.

이렇게 일하려면 담당자만 알고 있던 업무 기준을 AI도 참고할 수 있도록 문서로 남겨야 하고, 만든 결과를 확인하는 절차도 있어야 합니다. 같은 요청에도 결과가 달라질 수 있으니 어디까지 맡길지 정하고, 잘못 바꾼 것을 되돌릴 준비도 해야 하고요. 저는 AI를 쓴다는 전제에서 업무를 나누고 협업하는 방식을 다시 정하는 것까지가 AX라고 생각합니다.

Q. 업무를 나누고 협업하는 방식까지 바꿔야 한다고 말씀해 주셨어요. 인프런에서 이 변화를 시작하게 된 계기와 가장 먼저 재정비한 업무는 무엇이었나요?

2025년 하반기에 조직이 작아지면서 같은 서비스를 더 적은 인원으로 운영해야 했습니다. 그런데 AI 시대가 오면서 서비스의 특정 기능 자체는 해자가 되기 어렵겠다는 생각도 들었습니다. 보이는 기능은 이제 누구나 쉽게 따라 할 수 있으니, 저희는 더 자주 실험하고 더 빨리 움직여야 한다고 봤습니다. 인원은 줄었는데 실험은 더 많이 해야 하는 상황이었던 것이죠.

그래서 독립적으로 서비스를 운영하고 배포하는 각 조직의 크기를 줄이되, 조직의 수는 늘리는 쪽으로 판단했습니다. 10월에 기존 6인 체제의 조직을 1~3인 체제의 작은 셀로 개편했고, 그중에는 사내의 모든 운영 업무를 효율화하는 목표를 맡은 셀도 있었습니다. 11월부터는 전사에서 클로드를 팀 플랜으로 사용하도록 지원하면서, 데브옵스 팀과 운영 효율화 조직이 함께 사내 업무를 AI로 개선하는 작업을 진행했습니다.

가장 먼저 바꾸려고 한 건 운영과 사업 쪽의 반복 업무였습니다. 개발 쪽은 이미 2024년부터 AI 코드 리뷰를 쓰고 있었지만, 저희가 원한 건 전사의 생산성이 좋아지는 것이었으니까요. 지식공유자분과 소통한 기록을 템플릿에 맞게 정리하거나, 여러 문서에 흩어진 소통 내용을 한곳에 모으거나, 강의 기획안 초안을 만들고 챌린지 미션을 채점하는 일들부터 시작했습니다. 이후에는 마케팅 자동화와 소재 생성 등으로 넓혀갔습니다.

그 일을 하는 방법도 계속 바뀌었습니다. n8n을 사내 자동화 도구로 적극적으로 사용하다가 코드로 된 에이전트 서버로 옮겼고, 지금은 상용 도구를 쓰면서 저희가 업무 지식과 스킬을 관리하는 방식으로 바뀌었습니다.

Q. 다른 조직의 AX 사례를 참고할 때, 그대로 가져올 부분과 인프런에 맞게 바꿀 부분을 어떻게 구분하시나요?

다른 조직의 사례를 볼 때는 그 조직이 어떤 환경에서 일하는지부터 봅니다. 규모와 예산, 보안 기준, 문서가 쌓여 있는 정도가 저희와 다르면 같은 방식을 써도 결과가 다를 수 있으니까요. 제가 회고를 쓸 때 저희 조직의 맥락부터 설명하는 것도 그 차이를 감안해서 읽어주셨으면 해서입니다.

조직의 형태도 봅니다. 기획팀, 디자인팀, 개발팀으로 나뉜 기능 조직인지, 여러 직군이 같은 목표를 두고 일하는 목적 조직인지에 따라 참고할 수 있는 부분이 다르다고 생각합니다. 목적 조직이라면 저희와 비슷한 구조이니 적용할 수 있는 부분이 더 많을 것이라고 보고요.

데이터와 환경을 버전 관리하고, 업무 지식을 문서로 남기고, 사람이 결과를 확인하는 절차는 저희도 적용합니다. 다만 그걸 위해 승인 단계를 얼마나 둘지, 전담 조직을 만들지, 어떤 플랜을 쓸지는 저희 상황에 맞게 판단해야 합니다. 큰 조직에서 임원부터 단계적으로 도입했다고 해서 56명인 저희가 그 순서까지 따라갈 필요는 없었습니다.

반대로 작은 조직이나 개인이 쓰는 방식도 그대로 가져오기는 어려웠습니다. 개인 플랜이 비용 면에서 유리할 수는 있지만, 회사 데이터가 개인 계정에 쌓이면 퇴사할 때 권한과 데이터를 회수하기 어렵습니다. 개인에게 잘 맞는 사용 방식이어도 회사에서 함께 쓰려면 계정과 데이터를 어떻게 관리할지까지 봐야 하는 것이죠. 그래서 저희는 팀 플랜을 쓰고 있고, 각자 PC에서 사용하는 AI 도구도 DevOps 조직의 중앙 관리 아래에서 쓰도록 지원하고 있습니다.

Q. ‘효율이 좋아진 것’과 ‘효과가 좋아진 것’을 구분하셨어요. AX가 더 큰 사업 성과를 냈다고 판단하려면 어떤 변화가 필요할까요?

효율이 좋아졌다는 건 기존에 내던 성과를 더 적은 시간과 비용으로 낼 수 있다는 뜻으로 쓰고 있습니다. 효과가 좋아졌다는 건 그동안 내지 못했던 사업 성과를 내는 것이고요. 저는 이 둘을 구분해서 보려고 합니다.

예를 들어 저희 팀에서는 PM 한 분이 사내 AI 봇과 15번 정도 대화하면서 PRD와 프로토타입을 만들었습니다. 마케터가 직접 이벤트 페이지를 만들고 개발자는 비용과 보안을 검토한 사례도 있고, 8,700행이 넘는 광고 데이터를 손으로 정리하던 일을 대시보드로 바꾸기도 했습니다. 이렇게 효율이 좋아진 사례는 많이 확인했지만, 그래서 AI 덕분에 더 큰 사업 성과를 냈다고 말하기는 아직 어렵습니다.

사업 성과를 보려면 매출이나 MAU 같은 숫자를 봐야 하는데, 인당 지표만으로 평가하기에는 부족하다고 생각합니다. 인원이 줄면 인당 매출은 올라갈 수 있으니까요. 예전에는 도달하지 못했던 매출이나 MAU에 도달하게 만들었다면 그때는 사업적 성과를 냈다고 볼 수 있을 것 같습니다.

예전에는 하고 싶어도 할 수 없었던 일을 할 수 있게 된 것도 사업 성과로 볼 수 있다고 생각합니다. 당장의 매출로 이어지지 않더라도, 장기적인 로드맵에서 필요한 일을 이제 시도할 수 있게 됐다면 의미가 있으니까요. 머신러닝 시스템을 구축해야 가능했던 예측 시스템들이 그런 사례라고 봅니다. 최근 기업들이 내는 AI 해커톤 과제에도 트렌드를 감지하거나, 투수의 제구 성공 확률을 예측하거나, 신규 콘텐츠의 성공 여부를 예측하는 시스템들이 나옵니다. (기업들의 AI 해커톤 과제) 그동안은 이런 일을 하려면 필요한 인재와 리소스를 확보하기 어려웠는데, AI가 그 문제를 풀어주고 있다고 생각합니다.

레시피 둘, 회사 성과에 따른 AI 활용 목표

Q. 업무 기준과 프로세스를 먼저 정리한 뒤 AI를 적용해 달라진 사례가 있을까요?

경영지원 파트의 결산 업무가 그런 사례입니다. 사람이 줄면서 같은 일을 더 적은 인원이 맡아야 했는데, 내부에서 쓰는 기준이 회계법인의 기준과 달라 부가세나 법인세를 신고할 때마다 숫자를 한 번 더 맞춰봐야 했습니다.

이 일을 바꾸면서 가장 어려웠던 건 기준을 맞추는 일이었습니다. 매출을 인식하는 기준을 회계법인과 똑같이 맞추고, 입출금과 매입 내역도 어떤 체계로 분류할지 정리했습니다. 그 기준을 적용한 시트와 결산 매뉴얼을 만들었는데, 시트를 만드는 데는 AI의 도움을 많이 받았습니다. 담당자는 큰 그림을 그리는 게 어려웠지 구현은 그리 어렵지 않았다고 하더라고요. 시트 함수를 잘 몰라도 원하는 구조를 설명하면 AI가 방법을 알려줬다고 합니다.

지금은 신고할 때 숫자를 다시 맞춰볼 필요가 없어졌고, 원본 데이터만 정확히 넣으면 현금 흐름과 손익, 부가세 예상 세액까지 바로 확인할 수 있습니다. 손으로 옮겨 적다 생기던 실수도 줄었고, 매뉴얼을 함께 남겼기 때문에 담당자가 아니어도 결산을 할 수 있습니다. 선급금을 관리하기 시작하면서 방치돼 있던 광고비 미사용분을 찾아 환불받기도 했습니다.

에디터 : 기준을 정리하니 자동화의 효과도 분명해졌네요. 반대로 자동화를 시도했다가 사람의 판단을 다시 넣기로 한 일도 있었나요?

반대로 에이전트가 버그를 고치고 PR을 쓰고 리뷰까지 하는 과정을 사람 없이 끝까지 자동화해보려다가 되돌린 일도 있습니다. 여러 방식으로 검증해봤지만 결국 적용하지 않았습니다. 웹에서 생기는 에러 로그를 노린 악성 요청이 너무 많아졌고, AI를 이용한 해킹 사례도 계속 나오고 있기 때문입니다. 올해 6월에는 누구나 에러를 보낼 수 있는 수집 경로로 가짜 버그 알림을 심어서, 그걸 읽은 AI 에이전트가 해커가 만든 패키지를 실행하도록 유도한 공격 시도도 보고됐습니다. (관련 분석)

사람이 한 번도 확인하지 않은 코드가 그대로 나가는 건 이제 위험하다고 봅니다. 검수를 사람이 하느냐 AI가 하느냐로 보면 비슷해 보일 수 있지만, 지금은 사람과 AI가 함께 보는 것과 AI 혼자 보는 것을 비교해야 한다고 생각합니다.

서비스 코드에서 AI 리뷰를 머지의 필수 조건으로 두는 것도 보류했습니다. 같은 코드를 다시 리뷰해도 결과가 달라질 수 있으니, 반복해서 나오는 문제는 린트나 테스트로 옮기려고 합니다.

Q. 같은 도구를 줘도 활용 수준에는 차이가 생길 것 같아요. 구성원이 스스로 일하는 방식을 바꾸도록 리더는 무엇을 해야 할까요?

같은 도구와 환경이라 하더라도 활용 수준에는 차이가 나는 것 같긴 합니다. 다만 우리가 조심해야 할 것은 AI 도구를 잘 활용하는 것 자체가 구성원 개개인의 목표로 할당되어서는 안 된다는 것입니다. AI로 줄일 수 있는 반복 업무를 계속 같은 방식으로 하고 있다면 피드백할 필요가 있지만, AI를 적극적으로 쓰고 있다는 이유만으로 고성과로 평가할 필요도 없다고 생각합니다. 각 구성원이 회사의 목표를 얼마나 잘 달성하고 있느냐를 봐야 하는 것이죠.

제 개인적인 생각으로는, 기존에 하던 방식으로는 도저히 달성할 수 없는 목표를 받았느냐가 도구 사용에 큰 영향을 주는 것 같습니다. 지금보다 조금 더 열심히 하면 되는 정도의 목표라면 굳이 일하는 방식을 바꿀 필요를 느끼지 못할 수 있습니다. 그런데 지금 방식으로는 시간이 다섯 배, 열 배는 더 있어야 달성할 수 있는 목표라면 아예 새로운 방법을 찾아야 하는데, 그때 본인이 일하는 방식에도 큰 변화가 생기는 것 같습니다.

다만 그런 목표를 잡는 이유도 AI를 더 적극적으로 쓰게 하려는 게 아니라 회사가 더 크게 성장하기 위해서여야 합니다. 그 목표를 달성할 수 있다면 AI로 더 많은 양의 일을 처리하는 것도 방법이고, 자잘한 일은 AI로 처리하면서 본인은 더 큰 성과를 낼 수 있는 일에 집중하는 것도 방법이라고 생각합니다.

요즘은 AI를 활용해서 일의 양을 늘리거나 복제하는 데 관심이 많이 쏠리는 것 같습니다. 그런데 본인이 일정 수준의 결과물을 많이 만드는 쪽에서 성과를 내기 좋은지, 더 큰 성과를 낼 수 있는 일에 집중하는 쪽이 좋은지는 사람마다 다를 수 있습니다. 본인의 업무와 강점에 어떤 방식이 더 맞는지 판단하고, 거기에 맞게 도구를 쓰는 게 중요하다고 생각합니다.

저희는 각자 필요한 방법을 시도할 수 있도록 사용 한도 때문에 작업을 못 하는 분들의 플랜을 올려드렸고, 활용 사례도 모아 공유하고 있습니다. 평가할 때는 그렇게 일해서 회사의 목표에 맞춰 얼마나 더 큰 가치를 만들었는지를 봐야겠죠.

에디터 : AI를 얼마나 많이 썼는지보다 회사에 어떤 가치를 만들었는지를 보신다는 말씀이네요. 비슷한 도구를 쓰는 조직들 사이에서, 인프런이 쌓고 있는 쉽게 복제되지 않을 자산은 무엇인가요?

얼마 전 X에서 사모펀드 쪽 기술 실사를 하는 엔지니어가 쓴 글을 봤습니다. "독자 AI 플랫폼"이라던 회사의 코드를 열어 보니 외부 모델 호출과 지시문, 600줄짜리 연결 코드가 전부였고 투자사는 그날 철회했다고 합니다. 글쓴이가 실사 서비스를 판다는 점은 감안해야 하지만, 남들이 못 만드는 데이터가 있는지, 핵심 지식이 몇 사람에게만 몰려 있는지, 쉽게 다시 만들 수 있는 기능인지는 저희에게도 필요한 질문이었습니다.

앞으로 무엇이 경쟁사가 따라오기 어려운 자산이 될지는 예측하기 어렵습니다. 그래도 요즘은 저희 팀의 경쟁력이 데이터와 사람에 있다고 생각합니다. 저희가 일해온 기록은 회의 녹음과 정책 문서, 코드로 남긴 인프라에도 있고, 한곳에 모은 서비스와 마케팅 데이터에도 있습니다. 다른 회사가 같은 모델을 쓴다고 해서 저희가 왜 이런 결정을 했는지까지 알 수 있는 건 아니니까요.

사람에 대해서는 제가 CTO라 엔지니어링 조직에 한정해서 말씀드릴 수 있을 것 같습니다. 저희 팀은 전문성과 개방성을 함께 갖고 있고, 필요하면 더 배워서 팀 전체가 쉽게 일할 수 있는 방법을 고릅니다.

자동차에 비유하면, 면허가 없는 사람도 어디든 갈 수 있게 하려면 모든 도로와 날씨에 대비한 완전 자율주행차를 만들어야 합니다. 반면 모두가 면허를 땄다고 전제하면 차는 훨씬 단순해지고, 처음 가는 길도 내비게이션의 도움을 받아 갈 수 있습니다.

저희 인프라도 안에 든 기술을 몰라도 누구나 쓸 수 있는 플랫폼을 만들려면 모든 경우의 수를 미리 대비해야 합니다. 그래서 저희는 개발자가 Pulumi(인프라를 코드로 적는 도구)를 깊이 몰라도 AI의 도움을 받아 직접 변경을 요청하는 쪽으로 가고 있습니다. 인프라는 전부 코드로 두고, 개발자가 수정 요청을 올리면 AI 코드 리뷰와 테스트를 거친 뒤 DevOps가 검수하고 반영하는 흐름을 만들고 있습니다.

이렇게 필요하면 배우고 일하는 방식을 바꿀 수 있는 전문성과 개방성은 모델이 좋아진다고 복제되는 것은 아니라고 봅니다. 개발자를 채용할 때도 말보다 결과물로 보여주고 맡은 일을 끝까지 마무리하는 분을 찾고, 시키지 않아도 자기 일하는 방식을 바꿔보는지를 보게 됐습니다.

레시피 셋, 도구와 기록을 모아 팀이 함께 쓰는 지식으로 연결

Q. 각자 선호하는 AI 도구를 쓰는 대신 전사 도구를 통일한 이유는 무엇인가요? 실제로 쓰면서 생긴 불편도 궁금합니다.

예전에는 각자 손에 맞는 개발 도구를 쓰게 두는 편이 좋다고 생각했습니다. 그런데 AI 도구는 한 분이 익힌 사용 방법을 다른 분들도 바로 가져다 쓸 수 있다는 점이 다릅니다. 스킬이나 플러그인, MCP(AI를 사내 문서나 업무 도구에 연결하는 방식) 연결, 프롬프트를 공유하면 다른 분들도 활용할 수 있으니까요. 각자 다른 도구를 쓰면 이런 경험도 따로 쌓이기 때문에, 주로 쓸 도구를 정하고 노하우를 모으기로 했습니다.

개인 플랜과 팀 플랜을 고를 때는 회사에서 어디까지 관리할 수 있는지를 봤습니다. 개인 계정의 사용 내역은 회사가 확인하기 어려워서, 계정이 탈취돼 결제가 발생해도 늦게 알 수 있습니다. 어떤 MCP와 스킬에 회사 데이터를 연결하는지 사전에 검토하기도 어렵고요. 팀 플랜에서는 회사가 계정과 권한을 관리하고 퇴사할 때 회수할 수 있으니, 비용보다 관리를 생각해서 팀 플랜을 선택했습니다. 어떤 MCP를 연결할지 정하고 결제와 데이터 학습 거부 설정, 사용량도 조직에서 관리할 수 있습니다.

쓰면서 실제로 불편했던 건 사용 한도였습니다. 많이 쓰는 분들은 주간 한도에 금방 도달해서, 자체 게이트웨이를 두고 팀 플랜 한도에 걸리면 그쪽을 통해 계속 쓸 수 있게 했습니다.

한 업체의 도구에 경험이 쌓이다 보니 그 업체가 품질이나 가격 정책을 바꾸면 영향을 받는다는 점도 있습니다. 제품 안에서 쓰는 모델은 바꿀 수 있게 해뒀지만, 사내에서 익힌 사용 방식까지 쉽게 옮길 수 있는 것은 아닙니다. 그럼에도 하나를 충분히 잘 다뤄본 팀원들이라면 다른 도구도 빨리 익힐 수 있지 않을까 생각하며 노하우를 모으고 있습니다.

에디터 : 하나의 도구에 사용 경험을 모으는 것만큼, AI가 참고할 조직의 지식도 중요하겠어요. 특히 ‘왜 그런 결정을 했는지’가 담긴 기록은 어떻게 남기고 활용하시나요?

개발팀은 예전부터 장애보고서를 작성해왔는데, 이 보고서에는 왜 그때 코드를 그렇게 작성했는지, 인프라는 왜 그렇게 수정했는지까지 남게 됩니다. 5Why 기법(5Whys)으로 표면적인 증상부터 근본 원인(Root Cause)까지 찾아가다 보면 당시 결정의 맥락도 함께 정리하게 되기 때문입니다. 이렇게 남긴 기록은 나중에 AI가 코드 리뷰를 하거나 코드를 작성할 때도 참고할 수 있습니다.

이런 사례들을 토대로 전사적으로는 회의를 녹음하기 시작했습니다. 회의록에는 결론과 할 일이 주로 남는데, 녹취에는 왜 그렇게 결정했는지도 남습니다. 예전에는 녹음본을 텍스트로만 바꿔 회의록에 첨부했지만, 지금은 AI로 정리하기가 편해져서 녹음 파일에 담긴 중요한 맥락을 정리해 회의록에 함께 넣고 있습니다.

팀 단위로 주고받는 이메일도 항상 전사 지식 베이스(Knowledge Base)에 저장하도록 하고 있습니다. 회의록과 녹음본뿐 아니라 이메일, 구글 캘린더까지 연결해두니, 직접 참여하지 않은 일도 어떤 맥락에서 진행됐는지 확인할 수 있습니다. 사내 슬랙 봇과 AI 도구들도 이 지식 베이스를 참고하면서 업무를 진행하고 있습니다.

에디터 : 기록으로 남지 않고 담당자만 알고 있는 기준도 있을 것 같아요. 엔지니어가 마케팅팀 안으로 직접 들어가 함께 일하는 FDE 방식은 이런 지식을 발견하고 활용하는 데 어떤 차이를 만들었나요?

중앙 조직에서 만드는 도구는 모두를 위한 도구가 되기 쉬운데, 이럴 경우 자칫 잘못하면 그 누구에게도 도움이 되지 않는 경우도 많습니다. 마치 전투기 좌석의 크기를 모든 군인들의 평균으로 만들었더니 그 누구에게도 맞지 않는 것처럼 말이죠.

사내 FDE라고 한다면, 결국 도구를 만드는 것에 그치는 것이 아니라 해당 도메인을 가진 분들이 직접 도구를 만드는 것까지 넘어갈 수 있도록 해야 한다고 생각했습니다. 그러려면 FDE가 해당 도메인 팀에 들어가서 함께 식사하고 회의에 참여하면서, 그들의 도메인에 대한 이해도를 높이고 어떻게 일하는지 관찰해야 합니다. 그렇게 함께 일하면서 자동화할 수 있는 부분은 자동화하는 것이죠.

실제로 개발자가 현업과 함께 일하니 요청으로 올라오지 않던 일들을 발견했습니다. 8,700행이 넘는 광고 데이터를 손으로 정리하던 일이 그런 사례입니다. 일을 처리하는 기준과 예외는 담당자만 알고 있는 경우가 많아서, 개발자가 옆에서 일하는 것을 보고 규칙을 글로 정리해야 했습니다.

더 나아가서는 그분들에게 FDE 본인의 AI 환경을 이식해주고, 직접 필요한 도구를 만들도록 해주는 것까지 하는 것이죠. 올해 6월에는 마케터 한 분이 메인 페이지의 LLM 강의 추천 코드를 가져와 디자인을 바꾸고 프로모션 페이지를 직접 만들었습니다. 개발자에게는 트래픽이 늘 때 비용이 얼마나 들지, 코드에 보안 문제가 없는지 검토를 요청했습니다. 개발자들은 사용자별 호출 한도와 사용자 입력을 처리하는 부분을 확인했습니다.

레시피 넷, 사용량과 권한까지 살펴 AI를 지속해서 쓸 환경 구축

Q. AI 사용 비용은 어떤 기준으로 관리하시나요? 모델 성능과 사용량, 구성원의 업무를 함께 고려하는 방식이 궁금합니다.

어떤 업무든 기한 안에 원하는 수준으로 끝내는 게 목표이기 때문에, "이 업무에는 이 정도 비용이 적정하다"고 정해두지는 않았습니다. 물론 Fable 5.1이나 6.1 Sol의 Ultra 모드 같은 최고급 모델을 모든 일에 쓸 수 있으면 좋겠지만, 사내에서 쓰는 팀 플랜의 프리미엄 시트로는 그렇게 할 수 없습니다. 그래서 어떤 업무에 어떤 모델을 쓸지는 권장하고 있습니다. 기획과 설계처럼 판단이 중요한 단계에는 최근 성능이 좋아진 Opus 5.5를 쓰고, 실제 실행은 Sonnet 5.5와 Haiku 5.5를 주력으로 쓰도록 안내합니다.

시트도 사용 패턴을 보면서 다르게 드립니다. 가성비만 따지면 프리미엄 시트가 가장 좋지만, 이건 쓰든 못 쓰든 인당 월 125달러가 고정으로 나갑니다. 그런데 요즘은 주간 한도를 꽉 채워 쓰는 분이 많지 않아서, 어떤 분께는 스탠다드 시트 25달러에 종량제 100달러를 붙여 드리기도 합니다. 이렇게 쓰는 분들은 사내에서 보조로 제공하는 제미나이 엔터프라이즈와 조합해서 월 100달러 이하로 쓰는 경우가 많았습니다. 실제로 쓰는 양을 보니 그분들께는 비용 면에서 이쪽이 더 맞았던 것이죠.

각자 토큰이 많이 든 작업을 돌아보고 다음에는 어떻게 더 잘 활용할지 개선할 수 있도록, TACO라는 사내 AI 사용량 측정 도구도 전사적으로 사용하고 있습니다. 어떤 세션에서 얼마나 많은 토큰을 썼는지, 어떤 저장소와 작업에 토큰을 얼마나 썼는지를 본인이 확인할 수 있습니다.

다만 비용을 줄이려고 보안 기준을 낮추지는 않습니다. 어떤 시트를 쓰든 회사 팀 플랜 안에서만 쓰고, 한도를 넘는 사용은 앞서 말씀드린 게이트웨이를 거칩니다.

에디터 : 사용 패턴에 맞춰 비용을 조정하되 보안 기준은 낮추지 않는다고 하셨어요. 그 원칙을 실제 업무에서 지키면서도 필요한 도구를 쓸 수 있게 하는 장치는 무엇인가요?

개인 계정에 회사 데이터를 연결하지 않는 것은 분명하게 정했습니다. 회사가 권한을 관리하고 퇴사할 때 회수할 수 있어야 하는데, 개인 계정에 연결하면 그걸 하기 어렵기 때문입니다. 외부 AI 서비스나 MCP에 구글, 깃허브 같은 회사 계정 권한을 줄 때도 DevOps에서 먼저 검토합니다.

계정은 구글 워크스페이스를 중심으로 관리하고, AI 도구는 SSO와 초대 방식으로 접근을 제한합니다. 모델 호출은 게이트웨이에서 허용된 요청인지 확인하고 사용량을 기록하며, 외부 아티팩트 공유도 제한했습니다. DB 접속은 임시 자격 증명으로 바꿔가고 있고, 개인정보와 정산 데이터는 그룹별 권한으로 접근을 제한합니다. 메일 발송이나 티켓 생성 같은 작업은 사람이 승인하도록 하고요.

클로드 팀 플랜에는 조직 전체에 적용할 지시사항을 설정하는 기능도 있습니다. 공통 업무 규칙이나 데이터 취급 기준을 등록하면 모든 구성원의 대화에 적용되고, 개인이 설정한 지시사항보다 우선합니다. 다만 이것도 AI에게 전달하는 프롬프트인 만큼, 반드시 막아야 할 동작은 계정 권한과 관리 설정으로도 제한하는 쪽으로 가고 있습니다.

AI 도입과 보안 검토는 DevOps가 함께 맡고 있습니다. 쓰지 못하게 하는 것만으로는 구성원들이 다른 경로를 찾을 수 있으니, 필요한 도구를 검토하고 안전하게 쓸 방법까지 마련하려고 합니다.

법령 검색 MCP를 쓰고 싶다는 요청이 들어왔을 때도 검토 후에 쓸 수 있게 바꿨습니다. 외부 서버 운영자가 AI에 보내는 지시를 바꿀 수 있고 대화 내용이 외부로 전송될 수 있는 기능도 있어서, 바로 연결하는 대신 원본 법령 데이터를 가져와 사내에서 운영하는 방식으로 만들었습니다. 요청을 받은 뒤 한 달 정도 지나 사용할 수 있게 열었습니다.

레시피 다섯, 새로운 AI 모의면접 서비스의 문제 정의와 제품 판단

Q. 최근 공개한 인프런의 AI 모의면접은 어떤 문제에서 출발했나요? 이 문제를 직접 제품으로 풀어야겠다고 판단한 계기도 궁금합니다.

출처 : 인프랩 제공

혼자 면접을 준비하면 어떤 질문이 나올지 모르고, 실제로 말해볼 기회도 없고, 내 답이 괜찮았는지 알려주는 사람도 없습니다. 멘토링이나 코칭을 받는 방법도 있지만 사람의 시간을 쓰는 일이라 비용이 많이 들고 여러 번 반복하기도 어렵습니다. 저희 팀은 올해 7월 방향을 다시 정하면서, 사람을 따로 구하지 않아도 몇 번이든 반복할 수 있는 연습 상대를 만들기로 했습니다. 회사에서도 지식공유자의 콘텐츠에 기대지 않고 인프런이 직접 만들어 운영하는 제품이 필요한 상황이었습니다.

그 연습은 말로 해야 한다고 생각했습니다. AI 시대에 생산성을 유지하려면 회의 중에도 옆 사람과 바로 결정을 내릴 수 있어야 하는데, 그러려면 업무 내용을 충분히 알고 상대가 결정하는 데 필요한 내용을 바로 설명할 수 있어야 합니다. 함께 일할 사람을 정할 때도 이런 대화는 필요하니 대면 면접은 없어지지 않을 거라고 봅니다. 면접관 앞에서 자기 생각을 직접 말로 꺼내는 일만큼은 AI가 대신해 줄 수 없습니다. 저희 팀이 모의면접을 자기 목소리로 답하는 경험으로 만든 이유입니다.

출시 뒤에는 실제 지원하는 회사의 공고를 넣고 면접을 보는 분들이 있었고, 초기 기록에서 평균 면접 시간은 40분을 넘겼습니다.

저희 팀이 특히 주목한 건 수요가 빠르게 늘어나는 직무였습니다. FDE(Forward Deployed Engineer)처럼 채용이 늘어나는 직무는 준비하는 사람이 먼저 생겨도 모의면접을 해줄 멘토가 충분해지기까지 시간이 걸립니다. AI로 새로 생기는 직무에서도 이런 시간차가 생긴다고 봤습니다.

일본의 개발자 채용 플랫폼 파인디(Findy)는 올해 4월 FDE와 함께 SET(Software Engineer in Test), CRE(Customer Reliability Engineer)라는 직군 분류를 새로 만들었다고 발표했습니다. FDE 공고는 반년 전 거의 없다가 약 50건이 됐고, SET와 CRE도 각각 40-50건씩 올라와 있다고 합니다. (Findy 발표) 채용 수요가 이렇게 늘어나면 그 직무의 면접을 준비할 곳도 필요합니다. 저희 팀은 AI 면접관으로 이런 직무를 준비하는 분들에게도 연습할 상대를 제공할 수 있겠다고 봤습니다.

에디터 : 누구나 필요할 때 연습할 상대를 만드는 일이었네요. 그 상대가 단순히 지식을 묻는 데 그치지 않고 지원자의 경험과 판단을 드러내려면, 질문은 어떻게 달라져야 할까요?

처음에는 이력서에서 기술 키워드를 뽑아 질문을 찾았는데, PM이 본인 포트폴리오로 테스트해보니 단편적인 지식만 묻는 문제가 있었습니다. 그래서 저희 팀은 8월 초에 지원자의 경험과 판단을 더 구체적으로 묻는 쪽으로 바꿨습니다. 사내에서 면접관을 맡아온 개발자, 디자이너분들에게 실제로 어떻게 질문하는지 듣고 원칙을 정리했습니다.

개발자라면 어떤 기술을 썼는지는 이력서에 이미 적혀 있습니다. 면접에서는 왜 그 기술을 골랐는지, 다른 방법은 왜 쓰지 않았는지, 문제가 생겼을 때 어떻게 바꿨는지를 확인해야 한다고 생각했습니다. 프로젝트가 실패했더라도 그 과정에서 합리적으로 판단했는지를 보고, 팀이 한 일과 본인이 한 일도 구분해서 확인하고요. 이런 내용을 알려면 여러 주제를 얕게 훑기보다 두세 가지를 깊게 파는 편이 변별력이 높다는 것도 면접관분들과 이야기를 나누면서 배웠습니다.

이 원칙에 맞춰 이력서를 경험 단위로 나누고, 각 경험에서 그 일을 설명하는 질문과 돌아보는 질문을 만듭니다. 답변을 듣고 더 확인할 것이 있으면 꼬리질문을 합니다. 기술 지식을 확인할 때는 정리해둔 질문 데이터셋도 찾아보는데, 거기 있는 질문을 그대로 내는 건 아닙니다. 얼마나 깊게 물어볼지 참고하는 데만 쓰고, 꼬리질문은 항상 지원자의 답변을 바탕으로 만듭니다. 데이터셋에 없는 기술이면 경험에서 질문을 만듭니다.

그런데 답변을 계속 따라가다 보니 원래 확인하려던 것과 멀어지는 문제도 있었습니다. 내부 개발자들이 지원자 입장에서 테스트할 때 저도 참여했는데, 백엔드 면접에서 일부러 인프라 이야기를 몇 번 했더니 꼬리질문이 계속 인프라 쪽으로 따라왔습니다. 그래서 답변을 따라가면서도 지원 직무와 원래 질문의 목적을 확인해야 한다고 피드백했습니다.

이력서에 비해 공고를 충분히 반영하지 못하는 점도 있었고, 저희 팀이 회사 정보에 따라 질문이 달라지도록 손보고 있습니다. 출시 뒤에는 이용 기록과 질문 생성 실험에서 어떤 답변에 꼬리질문이 나왔는지, 어떤 종류의 질문은 거의 나오지 않는지를 확인했습니다. 그중 가장 기억에 남는 작업이나 가장 몰입했던 부분을 묻는 질문은 잘 선택되지 않아서, 경험 전체를 설명하게 하는 질문으로 바꾸기로 했습니다. 질문 품질은 아직 고칠 부분이 많아서, 프롬프트를 고치고 직접 테스트하는 일을 계속하고 있습니다.

Q. 실제 면접처럼 자기 목소리로 답하는 경험을 중요하게 보셨어요. 이용자가 연습을 시작하고 이어가도록 어떤 설계를 했고, 연습 효과는 어떻게 확인하려고 하시나요?

채팅으로 답하면 보내기 전에 몇 번이고 고칠 수 있지만, 말에는 초고가 없습니다. 말하고 나서야 표현이 이상했다는 걸 알아도 그때는 이미 면접관이 들은 뒤입니다. 실제 면접은 그렇게 진행되니 저희 팀은 연습도 그래야 한다고 봤습니다.

그래서 음성을 기본으로 하고 카메라는 선택으로 뒀습니다. 자기 생각을 말한 뒤에 꼬리질문을 받았을 때도 설명을 이어가는 연습을 하도록 했습니다. 면접 중에는 정답이나 힌트, 피드백을 보여주지 않고 끝난 뒤 리포트에서만 줍니다.

출시 뒤 이용 기록에서 먼저 확인한 건 면접을 끝까지 진행하는지와 어디서 그만두는지였습니다. 면접장에 들어온 분들은 대부분 끝까지 진행했는데, 시작 전에 이력서를 올리는 단계에서 이탈이 많았습니다. 그래서 이력서 첨부를 선택으로 바꾸고 캐릭터를 먼저 고르게 했습니다.

연습 효과는 면접을 마친 분들이 다시 이용하는지, 실제 면접 준비에 도움이 됐다고 하는지를 보면서 확인하려고 합니다. 출시 뒤 한동안은 계정당 한 번만 면접을 진행할 수 있도록 제한을 두었습니다. 그래서 다시 이용하는지는 아직 보지 못했습니다.

여러 번 볼 수 있게 바뀐 뒤에는 일정 기간 안에 다시 응시하는 비율을 보려고 합니다. 리포트 아래에 다음 면접 준비에 도움이 됐는지 묻는 한 문항 설문을 넣고, 이전 회차와 비교할 수 있는 리포트도 만들어보려고 합니다.

출처 : 인프랩 제공

에디터 : 다음 연습과 비교할 수 있는 리포트도 준비하고 계시네요. 사용자가 평가를 납득하고 실제로 답변을 개선하는 데 도움이 되도록, 피드백에는 어떤 기준을 두셨나요?

출시 초기 리포트에는 질문마다 잘한 점과 아쉬운 점은 있는데, 이 정도면 잘 답한 것인지 알기 어려웠습니다. 다음에 다시 면접을 봐도 이전보다 나아졌는지 비교하기도 어려웠고요. 사용자가 평가를 납득하고 다음 연습에 쓸 수 있도록, 저희 팀이 리포트를 다시 만들고 있습니다.

리포트에서 잘했다고 할 때는 답변에서 실제로 드러난 것만 근거를 들어 쓰게 했습니다. 아쉽다고 할 때도 무엇이 왜 아쉬웠는지 설명해야 하고, 다음에 적용할 점은 다음 답변에서 바로 해볼 수 있는 행동이어야 합니다. 리포트에는 질문마다 잘한 점, 아쉬운 점, 다음에 적용할 점을 이렇게 나눠서 보여줍니다. 답하지 않은 질문에는 잘한 점과 아쉬운 점을 만들지 않고, 다음에 어떻게 준비하면 좋을지만 안내합니다.

지금 고치는 리포트에서 어떤 역량을 볼지, 등급을 어떻게 나눌지, 답하지 않았거나 중간에 끝난 문항을 어떻게 다룰지는 저희 팀이 정합니다. 문항별 평가 기준은 AI가 질문을 만들 때 함께 생성해 저장해두고 채점할 때 참고합니다. AI는 문항마다 점수와 이유 한 줄을 내고, 그 점수를 등급으로 바꾸는 규칙은 사람이 정한 대로 시스템이 적용합니다.

등급을 보여주더라도 사람을 낮춰 보는 표현은 쓰지 않기로 하고 문구를 다듬고 있습니다. 같은 답변을 여러 번 평가해도 결과가 비슷한지 테스트한 뒤 공개하고, 현직자 검수는 그다음 단계로 하려고 합니다.

Q. 직원분들의 목소리와 여러 면접관 캐릭터도 눈에 띄어요. 캐릭터마다 경험은 달라지면서 질문과 평가의 품질은 유지되도록 어떻게 설계했나요?

저희 팀은 면접 연습을 조금 더 가볍게 시작할 수 있도록 면접관을 캐릭터로 만들었습니다. 면접관마다 묻는 방식은 온화한지 압박하는지로 나누고, 성격은 다정한지 꼼꼼한지 직설적인지로 나눴습니다. 지원자가 어떤 면접관과 연습하고 싶은지에 따라 고를 수 있게 했습니다.

캐릭터를 만들 때는 그 면접관이 왜 그렇게 묻는지 납득할 수 있도록 실제로 있을 법한 배경을 잡았습니다. 보고서의 숫자 하나를 놓쳐 프로젝트가 뒤집힌 뒤로 왜 그 값이 나왔는지를 꼭 되짚는 분석가, 돌려 말하는 걸 못 견디고 근거부터 묻는 실무자 같은 식입니다. 압박하는 캐릭터도 진지하고 깐깐한 선배에 가깝게 만들었습니다. 제 목소리를 쓰는 캐릭터도 있는데 꽤 깐깐하게 만들었더라고요(웃음).

목소리는 캐릭터에 어울리는 직원분들이 샘플을 녹음했습니다. 모든 질문을 미리 녹음할 수는 없으니, AI가 만든 질문을 그 목소리로 읽어주게 했습니다. 질문할 때와 답변을 들을 때, 검토할 때의 짧은 영상도 따로 만들었습니다.

캐릭터에 따라 달라지는 건 질문의 말투와 목소리입니다. 이력서에서 경험을 뽑고 질문을 만들고 채점하는 과정은 캐릭터와 상관없이 같고, 그렇게 만들어진 질문을 그 면접관답게 바꿔 말하게 했습니다. 그 과정에서 원래 묻고 싶은 내용까지 바뀌지 않는지는 계속 확인하고 있습니다.

에디터 : 캐릭터가 달라도 원래 확인하려던 내용은 같아야 한다는 말씀이네요. 내부 테스트에서 실제로 고친 부분은 무엇이었나요? 백엔드로 시작한 이유와 다른 직무로 넓히기 위한 조건도 궁금합니다.

내부 개발자와 CX 파트가 지원자 입장에서 써보니 말하는 중간에 음성 인식이 멈춰 답변이 빠지거나, 음성 합성이 기호를 그대로 읽는 일이 있었습니다. 음성 인식이 틀렸을 때 답변을 고칠 수 없어 아쉽다는 의견도 있었고요. 저희 팀은 이런 기본적인 진행 문제부터 고치고, 텍스트로 답변을 입력하고 편집하는 기능을 넣었습니다.

잘 모르겠다고 답했는데도 꼬리질문이 계속 나오는 것도 막았습니다. 앞 답변만 따라가다 지원 직무를 벗어나지 않도록 검토하는 단계를 넣었고, 꼬리질문 앞에 붙던 확인했다는 식의 군더더기 말도 뺐습니다. 출시 뒤에는 이용 기록을 보고 이력서를 선택으로 바꿨고, 질문이 만들어지는 동안 제출한 자료를 다시 볼 수 있게 했습니다.

이런 질문과 답변을 검토할 자료와 사람이 있다는 점 때문에 백엔드로 시작했습니다. 사내에서 면접관을 맡아온 백엔드 개발자분들에게 질문 원칙을 들을 수 있었고, 인프런에 백엔드 면접 강의와 질문 자료가 있었고, 직접 지원자 입장에서 테스트해 줄 개발자도 있었습니다. 저희 팀은 답변 데이터를 먼저 쌓으려면 한 직무에 집중하는 게 낫다고 봤습니다.

다른 직무로 넓힐 때도 그 직무의 면접을 아는 사람과 참고할 질문 자료가 있어야 하고, 현직자가 직접 써보면서 지원자의 경험을 제대로 묻는지 확인해야 한다고 봅니다. 그 기준을 수치로 정해 두지는 않았습니다.

IT가 아닌 직무는 실제 면접에서 어떤 질문을 받는지부터 살펴봐야 합니다. FDE처럼 면접 자료가 부족한 직무는 공고와 지원자의 경험에서 질문을 만드는 쪽으로 이야기하고 있습니다. 그보다 먼저 지금 백엔드 면접을 돈을 내도 아깝지 않은 품질로 만드는 게 저희 팀의 우선순위입니다.

레시피 여섯, 빠르게 만든 후 고객이 선택할 이유를 확인

Q. 사내 AX 경험은 AI 모의면접을 만드는 데 어떤 도움이 됐나요? 반대로 제품을 출시하면서 새롭게 확인한 과제도 있을까요?

모의면접은 7월 중순에 방향을 정하고 8월 말에 출시했습니다. 저희 팀이 그 속도로 제품을 만들 수 있었던 데에는 사내에서 AI를 쓰며 마련해둔 도구와 기록이 도움이 됐습니다. 기존 게이트웨이로 모델 호출 비용을 확인하고, DevOps가 지원한 음성 합성 도구를 면접관 목소리에 썼습니다. PRD와 회의록, 리서치도 마크다운으로 남겨서 AI가 다음 작업을 할 때 참고하게 했고요.

제품에서는 이용할 때마다 모델 비용이 발생하니 사내 구독료를 볼 때보다 비용을 더 구체적으로 봐야 했습니다. 가격을 논의할 때도 모델 비용뿐 아니라 인건비와 인프라까지 포함해서 사업을 지속할 수 있는지 계산했습니다. 리포트에서 같은 답변인데 평가가 매번 달라지면 납득하기 어려울 테니, 리포트를 개선하면서 같은 답변을 여러 번 평가하는 테스트를 검토하고 있습니다.

다만 개발 속도가 좋아졌다는 것만으로 사업 성과까지 좋아졌다고 보기는 어렵습니다. 기능을 빨리 만들 수 있어도 사용자가 찾아와 돈을 낼지는 따로 확인해야 하니까요. 저희 팀 회고에서도 개발 방식보다 매출에 더 집중해야 한다는 이야기가 나왔습니다. 사내 AX에서 효율이 좋아진 것과 사업 성과를 구분해서 봤는데, 제품에서도 같은 기준으로 보고 있습니다.

에디터 : 출시 속도뿐 아니라 평가를 납득할 수 있는지도 확인해야 하네요. 질문을 만들고 답변을 평가하는 과정에서 AI에게 맡길 부분과 사람이 정할 부분은 어떻게 나눴나요?

지원자가 잘 모르겠다고 답했는데도 AI가 꼬리질문을 계속하는 문제가 있었습니다. 더 물어볼지, 무엇을 물어볼지는 AI가 판단하게 했지만, 답하지 못하는 사람에게 같은 내용을 계속 묻도록 둘 수는 없다고 봤습니다. 그래서 저희 팀은 모르겠다는 답변에는 꼬리질문을 하지 않도록 바꿨습니다. 질문이 끝없이 이어지지 않도록 꼬리질문의 횟수와 깊이에도 상한을 뒀습니다.

질문 방향의 후보와 예시도 사람이 정해두고, AI가 그중에서 선택하게 했습니다. 후보로 넣어둔 질문이 실제로 얼마나 선택되는지도 실험해봤습니다. 잘 쓰이지 않는 질문 방향은 그 결과를 보고 바꾸기로 했고요.

평가에서도 AI가 답변을 읽고 피드백을 만들게 하지만, 무엇을 평가할지와 답하지 않은 문항을 어떻게 다룰지는 앞서 말씀드린 대로 사람이 정합니다.

Q. 이력서와 과제 코드까지 AI가 도와주는 시대에, 실제 채용 면접에서는 지원자의 무엇을 확인해야 한다고 보시나요?

저희 팀은 지금도 면접 전에 기술 과제를 냅니다. 다만 지원자가 코드 대부분을 AI로 작성할 것이라고 전제하고, 면접에서는 그 과제를 놓고 이야기합니다. 이력서와 예상 질문부터 과제 코드까지 AI가 대신해줄 수 있으니, 제출된 결과물만 보고 지원자에 대해 알 수 있는 것은 줄었다고 봅니다.

그래서 과제를 볼 때는 본인이 그 내용을 얼마나 이해하고 있는지부터 확인합니다. AI가 작성한 코드 중 본인도 잘 모르는 부분의 문제를 지적받았을 때 어떻게 대처하는지, 모르는 것을 모른다고 말하고 필요한 내용을 다시 확인하는지도 봅니다. AI가 없으면 최소한의 업무 이야기도 못 하는 분인지는 이때 알 수 있습니다. AI가 답을 만들어줄 수 있어도 그 답이 지금 상황에 맞는지 확인하는 건 그 사람이 할 일이니까요.

이렇게 과제를 두고 대화하다 보면 함께 일하는 방식도 보입니다. 질문을 끝까지 듣는지, 서로 다르게 이해한 부분이 있을 때 확인하고 생각을 맞춰가는지는 직접 대화해봐야 알 수 있습니다. AI에 어떤 지시를 했고, 해서는 안 되는 일을 어떻게 막았는지도 같은 과제를 보면서 확인합니다.

제가 면접에서 확인하고 싶은 건 이 사람이 저희 회사에 와서 잘 적응하고, 팀과 함께 성과를 낼 수 있는 사람인지입니다. 그걸 확인하는 데는 실제로 함께 일할 사람들과 한두 시간 동안 업무와 전문성을 놓고 나누는 대화가 가장 효율적이라고 생각합니다.

Q. 마지막으로 AX를 시작하고 싶은 작은 팀의 리더에게, 가장 먼저 해보라고 권하고 싶은 일이 있을까요?

작은 팀의 리더분께는 회의를 녹음하고, 그 자리에서 내린 결정은 따로 짧게 적어두는 것부터 권하고 싶습니다. 저희도 담당자만 알고 있던 업무를 AI에게 설명하려고 하니 기록이 부족한 경우가 많았습니다. 회의를 녹음하면 왜 그렇게 결정했는지까지 남길 수 있지만, 나중에 그 내용을 확인하려고 녹음을 전부 다시 듣기는 어렵습니다. 그래서 결정마다 배경과 결과를 적어두는 ADR도 함께 필요하다고 봅니다. 이렇게 문서로 남겨두면 새로 온 분도, AI도 그때 어떤 결정을 했고 왜 그렇게 했는지 확인할 수 있습니다.

저희도 작년 말에야 시작했습니다. Spotify 엔지니어링 블로그의 "When Should I Write an Architecture Decision Record"에서도 문제가 있고 팀이 정한 답도 있는데 적어둔 문서가 없으면 쓰라고 합니다. 그 글의 결론은 "거의 항상"인데, 대신 가볍게 써도 된다고 합니다. 그러니 너무 어렵게 생각하지 마시고, 일단 기록을 시작해보시길 추천드립니다.

에디터 : 결정을 가볍게라도 기록하는 것부터 시작하면 되겠네요. 그렇다면 AI로 사용자의 문제를 풀고 싶은 메이커에게는 어떤 이야기를 전하고 싶으신가요?

저희도 아직 AI 제품으로 성공하는 것에 대해 확실하게 성공 방정식을 찾았다고 할 수는 없어서 메이커분들께 드리는 조언은 참 어렵다고 느낍니다. 다만, 요즘 저는 좋은 사업, 좋은 서비스는 ‘AI’를 떼고도 그걸 선택할 이유가 있는 것이어야 한다는 생각을 하고 있습니다.

AI가 추천한다고 더 신뢰해야 하거나 AI가 만들어줬으니 그걸 더 좋아해야 할 이유는 없다고 생각합니다. 제작 자체는 AI로 하더라도, 그 서비스가 해결하고자 하는 문제가 정말 고객이 비용을 지불할 만큼의 가치를 전달하는 것이 맞는지에 대한 고민을 많이 해야할 때인 것 같습니다.

예전에는 실행에 대한 비용이 비싸서 실행력이 해자였다면, 지금은 실행의 비용이 너무 낮아져서 역설적으로 모든 것을 다 해보려고 합니다. 그러다 보면 이것도 저것도 아닌 형태로, 무엇을 해결하고자 했는지 알 수 없는 제품이 되기도 합니다.

AI로 실행에 대한 비용이 극단적으로 낮아진 지금, 우리가 진짜 해결하고자 하는 문제가 무엇이었는지를 더 많이 고민하고 그 문제를 해결할 수 있는 도구에 초점을 잡아보신다면 어떨까 싶습니다. AI 자체를 그 제품의 본질과 핵심으로 삼지는 않으셨으면 합니다.

이렇게 이야기하는 게 저 역시도 부끄러운데요. 아직 인프런도 그러한 성과를 내지 못했기에 이 글을 작성하면서 스스로 더 초심을 잡고 있습니다. 다 같이 멋진 제품으로 더 멋진 세상을 함께 만들어가길 바라겠습니다.

오픈채팅방을 통해 뉴스레터로 다 소개하지 못한 정보를 확인해보세요!

팁스터가 인스타그램을 시작했어요!