지동한 팀장 · 이현성 책임 - GS칼텍스 DAX센터 DAX Lab
"우리 회사에서도 AI 도입해야 하는데, 뭐부터 해야 할지 모르겠어요."
아마 한 번쯤은 들어봤거나, 직접 해본 말일 겁니다. 컨퍼런스나 언론에서 "AI가 바꿀 미래"를 백 번 들어도, 막상 내 책상 앞으로 돌아오면 감이 안 잡히는 거죠.
그런데 이 회사에서는 조금 다른 일이 벌어지고 있었어요. 직원들이 먼저 물어보기 시작한 겁니다. "GPT는 이렇게 되는데, 우리 회사는 왜 이게 안 돼요?"
GS칼텍스 DAX Lab*. 지난 1년간 해온 일을 한 줄로 요약하면 이렇습니다. 사내 AI 플랫폼 'AiU'**를 오픈했고, 임직원 3천 명 중 2천 명 이상이 매달 쓰고 있으며, 현업이 직접 만든 AI 에이전트가 563개 생겼습니다.
*DAX Lab: GS칼텍스 DX센터 산하 조직. 디지털 전환(DX)에 AI 전환(AX)을 더한 'DAX(Digital & AI Transformation)' 전략을 실행한다. 데이터 기반 현장 개선부터 생성형 AI 플랫폼 구축까지 폭넓게 담당한다.
**AiU(에이아이유): GS칼텍스가 2025년 6월 오픈한 사내 생성형 AI 플랫폼. 'AI + You(당신을 위한 AI)' 'AI + 油(기름, 에너지 기업)'의 중의적 의미를 담은 브랜드다. GPT·클로드·제미나이 같은 모델을 사내 보안 환경에서 쓸 수 있게 해주고, 사용자가 직접 AI 에이전트를 만들 수 있는 빌더도 갖췄다.
숫자 뒤에는 두 사람이 있었습니다. 요구의 방향이 뒤집혔다는 걸 가장 먼저 알아챈 전략가, 그리고 매일 밀려드는 VoC를 받아 2주마다 배포를 돌리고 있는 PO. 그들의 이야기를 들어보았습니다.
Chapter 1. 일상에서 먼저 써본 AI, 회사 안으로 들어오다
처음 던진 질문은 이거였어요. "DX는 왜 현업에게 와닿지 않는다고 느끼셨어요?"
지동한 팀장의 답은 비유로 시작했습니다.
"사람들이 원하는 건 내 업무가 편해지는 거지, 백조가 호수 아래에서 어떻게 발을 젓고 있는지는 관심이 없어요." - 지동한 팀장
DX의 핵심은 사일로를 없애고 데이터를 연결하는 거였습니다. 그런데 그 일의 대부분이 수면 아래에서 일어나요. 사용자 눈에는 잘 안 보입니다. 분석 모델을 만들어 드려도 "이게 어떤 알고리즘인가요? 데이터는 뭘 쓰나요?"라는 질문이 먼저 돌아왔습니다. 호기심이 아니라 '이거 믿어도 되나?'를 검증하기 위한 질문이었습니다.
지동한 팀장이 칼텍스에 와서 처음 만든 분석 모델은 세 번째 시도만에 자리를 잡았습니다. 처음 만들었을 때는 잘 안 쓰여서 잊혔고, 회사에서 DX 과제를 다시 발굴할 때마다 같은 모델이 올라왔다가 또 안 쓰였습니다. 세 번째가 되어서야 "이거 믿을 만하네"라는 반응이 나왔다고 합니다. 기술의 장벽이 아니라 인식의 장벽. 그걸 넘는 데 시간이 걸렸습니다.
그런데 생성형 AI가 나오고 나서는 풍경이 완전히 달라졌습니다.
그런데 생성형 AI가 나오고 나서는 풍경이 완전히 달라졌습니다. 지동한 팀장은 아이언맨을 떠올렸습니다. 손짓하면 도면 펼쳐지고 3D 홀로그램이 나오는 바로 그 장면이 회사에서는 디지털 트윈*으로 구현돼야 하는데, 현실에서는 잘 안 보였다고요. 그런데 생성형 AI는 달랐습니다. 자비스처럼 말을 걸면 바로 답하니까, 사람들이 신기해하고 일단 써봤다는 겁니다.
*디지털 트윈(Digital Twin): 현실의 공장·설비를 가상 공간에 똑같이 복제해 실시간 데이터로 상태를 모니터링하거나 시뮬레이션하는 기술.
요즘 생성형 AI는 일상 속에 완전히 녹아들어있습니다. 사주를 보고, 날씨를 묻고, 아이들이 발표 자료를 만들 때 AI 툴을 씁니다. 직원들은 일상에서 생성형AI를 활용한 경험을 가지고, 회사에 들어오면 다른 질문을 합니다. "왜 이건 안 되지?" 기대하는 변화의 방향이 완전히 뒤집힌 겁니다.
"예전에는 우리가 DX의 당위성을 설득해야 했어요. 지금은 반대예요. 사용자가 이렇게 쓰고 싶다, 저렇게 쓰고 싶다, 이건 왜 안 되냐고 들고 오십니다." - 지동한 팀장
이 인식이 DAX Lab의 전략을 바꿔 놓았습니다. "DX의 당위성을 설명하는 조직"에서 "쏟아지는 요구의 우선순위를 정하는 조직"으로. 전자는 밀어 올리는 일이고, 후자는 받아서 걸러내는 일입니다. 일의 근육이 다릅니다.
그래서 결정했다고 합니다. "일상에서의 경험을 회사 안으로 가져오자." 이 문장이 지난 1년 DAX Lab의 모든 판단을 관통합니다.
Chapter 2. 이번엔 사용자가 먼저 말을 걸어왔다
이현성 책임은 2025년에 생성형 AI 업무를 이어받았습니다. 그전까지는 클라우드 쪽 일을 하고 있었어요. 넘겨받고 보니, 이전 팀에서 해둔 일이 있었습니다. 2024년 6월에 'GS Gen AI Lab'이라는 시범 서비스를 한 번 열어봤던 것.
한 300명이 썼고, 그중 180명이 설문에 응답했습니다. 이벤트 상품도 안 걸고, 그냥 "개선하겠다"고 했는데 180명이 답했습니다. 이현성 책임은 그 숫자에서 신호를 읽었어요.
"상품도 안 걸었는데 180명이 응답해 주셨다는 건, 이게 잘 쓰이고 있다는 얘기거든요. 요구 사항이 있다는 얘기예요." - 이현성 책임
VoC의 결이 DX 시절과 완전히 달랐습니다. 예전에는 "이 기능 왜 이렇게 불편하냐"는 불만이 대부분이었는데, 이번에는 현업들이 제일 먼저 기능을 써보고 왔습니다. AiU로 이렇게도 해보고 저렇게도 해봤는데 퍼포먼스가 안 나온다, 그래서 요청드린다는 식이었다고 합니다.
즉, 사용자가 이미 프로토타이핑을 하고 있었다는 겁니다. 회사가 제공하기 전에 개인의 삶에서 써보고, 조합해서 쓰고, 비교해서 쓴 결과를 들고 오는 것. 이건 "해주세요"가 아니라 "이 방향이 맞는지 봐주세요"에 가깝습니다.
그래서 AiU의 메인 페이지는 GPT와 같은 '대화하기' 화면이 됐습니다. 소개 페이지가 아니라 대화 화면이 첫 화면인 거죠. MISO가 에이전트를 만들고 관리하는 빌더 중심의 플랫폼이라면, AiU는 그 위에서 직원들이 가장 자주 쓰는 기능을 전면에 내세운 것입니다. 내부VoC에 기반하여 "사람들이 들어와서 가장 먼저 보는 건 대화하기여야 한다"고 판단했기 때문이죠.
*미소(MISO): GS그룹 오픈 이노베이션 조직 52g가 개발한 그룹 공통 AX 플랫폼. 코드 없이 AI 에이전트를 만들 수 있게 해주는 도구다. AiU는 그 위에 GS칼텍스가 자체 UI와 사내 데이터 연계를 얹어 만든 사내 서비스다.
시범 서비스 당시 피드백이 근거였습니다. 빌더 쪽은 "생각보다 똑똑하게 답하네" 같은 긍정 반응이 많았는데, 대화하기 쪽은 "이 기능 더 만들어달라"는 요구가 훨씬 컸다고 합니다. 사람들이 대화하기를 더 잘 쓰고 싶어 한다는 신호였죠.
그다음 질문은 자연스럽게 이거였습니다. 쏟아지는 VoC 중에 뭘 먼저 반영할 건가?
이현성 책임의 답은 스타트업의 언어였습니다. 대기업 회의실에서 듣기 어려운 단어들 — ICE 스코어, 그로스 해킹 — 이 자연스럽게 흘러나왔습니다.
"세 가지 축으로 봤어요. Impact(MAU와 사용량 증가 효과), Confidence(실제로 쓸 거라는 확신), Cost(개발에 드는 시간·비용). ICE 스코어로 정리한 거예요."* - 이현성 책임
*ICE 스코어: Impact(효과) · Confidence(확신) · Ease(실행 용이성) 세 축으로 점수를 매겨 업무 우선순위를 정하는 프레임워크. 스타트업 그로스 팀에서 주로 쓴다. 실무에서는 Ease를 Cost(비용)로 바꿔 쓰기도 한다.
대기업 IT 조직에서는 흔히 팀장이나 임원이 "이건 해야지"라고 결정하는 방식이 일반적입니다. 그런데 AiU 팀은 달랐습니다. 스타트업이 앱 런칭하듯 그로스 해킹 방식으로 움직였습니다. VoC를 모으고, 이탈 사용자를 인터뷰하고, 지속적으로 피드백을 줄 수 있는 현업 10명을 뽑아 주기적으로 설문을 돌렸습니다. 사용성 KPI 대시보드를 만들어서 일주일 단위로 질문 패턴도 분석했습니다. 팀에서 이렇게 많은 사용자가 쓰는 서비스를 애자일* 방식으로 개발하고 운영해본 게 이번이 처음이라, 많은 시도를 해볼 수 있었다고 합니다.
*애자일(Agile): 한 번에 완성해서 내놓는 대신, 작게 만들고 사용자 반응을 보면서 계속 고쳐나가는 일하는 방식. 원래 소프트웨어 개발에서 시작됐지만 지금은 제품 기획·조직 운영 전반에 쓰인다.
대기업 안의 스타트업 팀. 그 운영 방식이 숫자로 돌아왔습니다. 오픈 70일 만에 누적 사용자 2,986명(임직원의 94%), 월 사용자 2,170명(68%). 대화량은 월 56,640건, 인당 월평균 26번. 현업이 만든 에이전트 563개, 그중 100회 이상 대화 기록이 있는 '활성 에이전트'가 55개.
그런데 이 숫자 뒤에는 2주마다 돌아오는 배포 일정이 있었습니다. 이 새로운 속도를 어떻게 버텼을까요
애자일은 회의 포맷이 아니라 실행 습관입니다. 2주마다 배포를 내보낸다는 것. 그 습관이 자리 잡기까지는 시간이 걸렸습니다.
Chapter 3. 일의 원동력, 그리고 실패의 궤적
인터뷰 중반, 힘들지 않냐고 물었습니다. 이현성 책임은 웃으면서도 숨기지 않았습니다. 2주마다 배포한다는 게 쉬운 일은 아니라고요. 그런 그에게 원동력은 무엇일까요? 한참 뜸을 들였습니다.
"원동력이요? 그러게요. 구체적으로는 저도 잘 모르겠는데, 아마 파일럿 때처럼 2~300명이 썼으면 이렇게 못했을 거예요. 지금은 많은 사람들이 업무에 잘 쓰고 있는 걸 아니까, 최대한 도와드리고 싶더라고요." - 이현성 책임
현업이 프로토타이핑을 먼저 하고 오는 만큼, PO도 프로토타이핑을 늦추면 안 된다는 것. 요구는 계속 바뀌고, 외부에서 새 모델이 매달 나오고, 누군가는 "왜 우리는 클로드 코드처럼 안 되냐"고 묻습니다. 이 속도를 따라가지 못하면 조직이 금방 뒤처집니다.
그런데 이 속도는 하루아침에 만들어진 게 아니었습니다. 그 전에 실패가 있었습니다.
① MS Copilot PoC — 너무 이른 오픈
2024년 초, MS가 코파일럿을 대대적으로 광고하던 때였습니다. 칼텍스 역시 도입해서 써봤고, 결과는 간단했습니다. 한국어를 잘 못 알아들었고, 너무 성급하게 오픈한 탓에 사용자가 다 떨어져 나갔습니다.
② 스타트업 업무 챗봇 — 확장성의 벽
다음은 국내 스타트업 솔루션 업체와 함께 업무용 챗봇을 만들어봤습니다. 정확도가 80~90%까지 올라왔는데, 그 위로는 안 올라갔습니다. 업체가 쓰던 기술이 LLM이 아니라 머신러닝 기반이었고, 원천적인 한계가 있었습니다.
두 번의 실패가 의미하는 건 이겁니다. 기술이 부족해서도 있지만, "누가 사용할 것인가?"의 답이 없었다는 것입니다. 전문가가 만들어서 현업에게 건네주는 구조는 아무리 완성도가 높아도 확산이 안 됐습니다.
그래서 질문을 바꿨습니다. 현업이 필요한 것을 직접 만들게 하면 어떨까?
이 질문에 답이 나온 계기가 있었습니다. 사실 칼텍스는 2021~2022년부터 이미 현업 개발자 육성을 해오고 있었습니다. 디지털 아카데미에서 60여 명을 12주 풀타임 교육으로 키웠고, 생성형 AI 교육 이수자만 지난 1년간 1,392명. 이미 어려운 개발로부터 맷집이 생긴 현업들이 있었습니다. 그러던 중 생성형 AI가 터지면서 관심이 증가하고, 개발 난이도가 갑자기 낮아졌습니다. 지동한 팀장은 그 전에 단련돼 있던 분들이었기 때문에 현업이 직접 만든다는 개념을 받아들일 수 있었다고 했습니다. 타이밍이 안 맞았다면 퍼지지 않았을 거라고요.
그 타이밍 위에서 AiU가 만들어졌습니다. 이현성 책임은 가장 힘들었던 순간이 AiU 오픈이었다고 말했습니다. MISO팀과 커뮤니케이션하면서 내부 개발과 테스트를 동시에 돌려야 했고, 오픈 직전이 제일 빠듯했다고요. 오픈하고 나서는 돌아가는 사이클 안에서 내달리는 느낌이었습니다.
그 사이클이 2주짜리였습니다. 사용자 VoC 받고, ICE 스코어로 정리하고, 배포하고, 다시 VoC 받고.
그러자 이 타이트한 속도가 현장을 진짜 바꾸는지 궁금해졌습니다.
Chapter 4. 현업이 만드니, 현장이 바뀌었다
가장 분명한 변화는 여수 공장에서 나왔습니다. 현장에는 TBM*이라는 안전 미팅이 있습니다.
*TBM(Tool Box Meeting): 작업 시작 전 10분 내외로 진행하는 안전 점검 회의. 그날의 작업 내용, 위험 요소, 비상 대응법을 작업책임자가 작업자들에게 전달한다. 법적으로 요구되는 필수 절차.
여수 공장에서는 하루 평균 400건 이상의 작업이 일어납니다. 즉, 하루에 TBM이 400번 열린다는 얘기입니다. 그런데 이 미팅이 쉽지 않았습니다. 필수 전달 항목이 8가지, 연관 데이터는 2개 시스템에 100개 이상 흩어져 있습니다. 여기에 협력사가 60곳 이상 들어오는데, 이분들은 안전 전문가가 아닙니다. 진행자마다 스킬이 다르고, 정보가 누락되고, 어떤 날은 비상대피장소 안내 자체가 빠지기도 했습니다.
안전팀이 문제를 들고 왔습니다. "이 스크립트 작성을 AI가 도와주게 할 수 없을까?"
2025년, 52g 크루가 AiU 플랫폼 위에서 직접 만들기 시작했습니다. 개발자 없이, 현업 출신의 크루가 2주 동안 직접 만들었죠.
비교하면 이렇습니다. 그 전해 2024년에는 같은 안전 영역에서 '안Gen봇'*을 만들었는데, 개발 환경도 개발자도 완전히 달랐습니다.
*안Gen봇: 2024년 52g 스튜디오의 전문 개발자가 만든 여수 공장 안전 챗봇. 현장에서 사진을 찍어 올리면 잠재 위험 요소를 찾아주고, 안전 규정을 물어보면 답해준다. 별도 인프라 위에서 3개월에 걸쳐 개발됐다.
안Gen봇 (2024) | TBM AI 비서 (2025) | |
개발 기간 | 3개월 | 2주 |
개발자 | 전문 개발자 (52g 스튜디오) | 현업 (52g 크루) |
개발 환경 | 별도 인프라 구성 | AiU 플랫폼 |
유지보수 | 개발자 의존적 (코드 수정) | 현업 직접 대응 (GUI) |
단순히 개발 속도만 빨라진 건지 궁금해졌습니다.
두 사람의 답은 같았습니다. 꼭 현업이 직접 개발해야 하는 건 아니지만, 현장의 문제를 아는 사람이 개발 과정에 제대로 참여하는 게 중요하다는 것. 개발의 문턱이 낮아지면서 그 루프가 빨라진 거라고요.
TBM AI비서가 성공한 또 하나의 결정적 요소는 협력사 직원이 별도 앱 설치나 교육 없이 바로 쓸 수 있어야 한다는 기준이 있었기 때문입니다. 따로 앱을 설치하게 했으면 사람들이 안 썼을 거라고 해요.
협력사 직원들은 '전자작업허가서'라는 시스템을 기존에 사용하고 있었습니다. 공사 들어가기 전에 반드시 열어야 했죠. 팀은 그 위에 버튼 하나를 달았습니다. 버튼을 누르면 TBM 스크립트가 자동으로 생성되도록. 원래 보던 화면이고, UI도 거의 안 바뀌었습니다. 새로운 앱을 설치하지도, 따로 로그인할 필요도 없었습니다.
"이게 DX와 AX를 같이 해야 되는 확실한 증거예요. 원래도 협력사분들이 쓸 수 있는 IT 서비스가 있었어요. 전자작업허가서에 들어가서 업무를 하셔야 하는 거였거든요. 그 기반이 있었으니까 스크립트 생성 버튼 하나만 얹으면 됐던 거죠." - 지동한 팀장
결과는 숫자로 돌아왔습니다. 오픈 첫 주 활용률 8%, 한 달 반 만에 33%. (*활용률 기준: 당일 전체 작업 건수 대비 TBM AI 비서를 호출해 스크립트를 생성한 작업의 비율) 이현성 책임은 이 숫자를 처음 봤을 때 감사한 마음이었다고 합니다. 원래 잘 안 바뀌는 분들이고, 나이도 많으신데 그분들이 적극적으로 쓰신다는 게 신기했다고요. 정말 필요한 문제를 잘 해결하면 변화 관리는 알아서 따라온다는 걸 확실히 느낀 사례였다고 했습니다.
TBM AI 비서도 물론 하나의 에이전트이지만, 도구 이상의 인사이트를 보여줬습니다. 현업이 자기 문제를 직접 풀 수 있는 환경이 만들어지면, 조직에서 원래 안 바뀌던 영역도 바뀐다는 것을 증명해냈죠.
Chapter 5. 벌써 1년이 됐고, 이제 시작이다
인터뷰 끝자락에 이 1년을 한 문장으로 정리해달라고 물었습니다. 지동한 팀장의 대답은 담백했습니다.
"제품의 라이프 사이클을 빠르게 모두 경험했어요."
오픈, 사용자 급증, 이탈까지도 다 겪었는데 정신없이 지나가 있더라는 겁니다. 반면 이현성 책임은 의외였죠. 아직은 갈 길이 멀고, 현업 한 분 한 분이 고객이라 감상에 잠길 틈이 없다고 했습니다.
지동한 팀장이 웃으며 덧붙였습니다. 이 친구가 가끔 '내 KPI를 임직원들이 달성해줘서 고마웠던 한 해'라고 농담을 한다고요. 하지만 기업용 서비스 기획자 입에서 '써주셔서 감사하다'는 말이 나온다는 건, 이 팀이 사내 서비스를 B2C처럼 고객을 직접 바라보며 운영하고 있다는 방증이기도 합니다.
실제로 숫자가 이를 증명합니다. 첫 해 MAU 목표는 1,000명. 지동한 팀장은 당시 너무 높다고 반대했다고 합니다. 그런데 오픈 후 집계된 수치는 무려 2,000명이었죠.
마지막으로, AI 도입을 고민하는 다른 기업 담당자에게 한마디씩을 부탁했습니다. 이현성 책임은 속도를, 지동한 팀장은 조직을 이야기했습니다.
"ROI 같은 얘기는 이제 안 나와요. 이건 그냥 인간 기술의 표준이 됐거든요. 모바일처럼요. 너무 복잡하게 걱정하지 말고, 하루라도 빨리 도입해서 빨리 써보면서 개선하세요. 비용, 권한 체계, 이런 걸 너무 앞세우지 말고 일단 많은 사람들이 경험하게 하는 게 먼저예요." - 이현성 책임
"기술부터 변화 관리까지 다 애착을 가지고 챙기는 오너십 부서가 꼭 있어야 해요. CoE* 예요. '이건 우리 조직의 역할이야'를 넘어서, 약간의 오지랖이 있는 조직이요. 내 조직이 아니어도 가서 도와주고, 안 해달라고 해도 가서 챙겨보는. 그런 애착이 있어야 합니다." - 지동한 팀장
*CoE(Center of Excellence): 특정 전문 영역의 기술과 방법론을 중앙에서 책임지고 확산시키는 조직 형태. 전사 AI 도입에서 자주 언급된다.
인터뷰가 끝난 뒤 돌이켜보면, 두 사람의 역할이 업무 전체의 구조였습니다. 지동한 팀장은 요구의 방향이 뒤집혔다는 걸 전략 언어로 읽어낸 사람. 이현성 책임은 그 요구를 매일 받아 2주마다 배포로 증명한 사람. 한쪽은 왜 해야 하는지를, 다른 한쪽은 어떻게 지속하는지를 말합니다.
AI를 도입해야 하는데 뭐부터 해야 할지 모르겠다는 분들께, 이 두 사람이 한 말을 다시 옮깁니다.
먼저, 사용자가 먼저 말을 걸고 있는지 들어보세요. 생성형 AI를 쓰는 개인의 경험이 이미 회사의 요구로 들어오고 있습니다.
그 다음, 그 요구를 받을 팀이 있는지 확인해보세요. 애자일 배포를 버틸 근육, 그리고 내 조직이 아니어도 가서 챙길 오지랖이 있는 팀.
마지막으로, 현업이 자기 문제를 직접 풀 수 있는 도구를 쥐여주세요.
🖊️ Editor's Note
이 두 분의 이야기를 들으면서 계속 맴돌았던 건, 지동한 팀장이 DX 시절과 지금을 비교하며 쓴 백조 비유였어요. 아무도 수면 아래에서 발을 젓는 건 보고 싶어 하지 않는다는 것. 그래서 DX는 오래 걸렸다고.
그런데 AI는 수면 위로 올라왔어요. 사용자가 먼저 GPT를 쓰고 와서 "왜 우리 회사는 이게 안 돼요?"라고 묻기 시작하면서요. 질문의 방향이 뒤집힌 거죠. 그 뒤집힘 위에서 AiU가 열렸고, 2주마다 배포가 돌았고, 공장의 협력사 분들이 쓰기 시작했어요.
이현성 책임이 웃으며 "너무 힘들어요"라고 말한 뒤, 빛나는 눈으로 "그럼에도 불구하고 많은 사람들이 잘 쓰고 있는 걸 아니까 최대한 도와드리고 싶더라고요"라고 이은 부분이 오래 남았어요. 솔직히 말하면 대기업 환경에서 나온 말이라는 게 신기했어요. 임직원이 고객이라고 생각하는 PO가 있는 것. 그리고 그 PO가 소진되지 않게 지지해주는 팀장이 있는 것. 기술보다 이 조합이 더 귀해 보였습니다.
— Hanna
'52g' 구독하기
사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 '52g'을 구독하세요!
Slashpage에 가입하고 '52g'을 구독하세요!
구독
