리더는 "AI 왜 안 쓰냐" VS 실무자는 "사고 나면요?"

라이브 서비스는 멈출 수 없다. 신규 개발은 실패하면 접으면 되지만, 이미 서비스 중인 제품은 그럴 수 없다. 사고가 나면 지금 접속해 있는 사용자에게 바로 영향을 미친다. 그래서 라이브 조직에서는 어떤 판단을 하든 “지금 돌아가는 걸 망가뜨리지 않는가”를 먼저 확인하게 된다.

AI 도입도 마찬가지다. 지금 대부분의 회사가 AI를 쓰라고 한다. 흐름 자체는 거스를 수 없고, 언젠가는 해야 할 일이라는 데도 대체로 동의한다. 그런데 유독 라이브 조직에서는 이 흐름이 더디다. 몰라서도 아니고, 하기 싫어서도 아니다. 라이브라는 환경이 가진 조건 때문이다.

이 글에서는 그 조건이 무엇인지, 필자가 게임 조직에서 경험한 점을 토대로 그것이 왜 조직 안에서 경영진과 실무자의 갈등으로 번지는지, 그리고 그 상황에서도 실제로 시도해 볼 수 있는 것이 무엇인지를 정리해 보려 한다.

라이브 서비스가 원래 안고 있는 것들

AI 이야기를 하기 전에, 라이브 서비스의 유지보수가 왜 그렇게 무거운지부터 짚어야 한다. 이 조건들이 뒤에서 AI 도입을 막는 이유가 되기 때문이다.

기능은 더해지기만 하고 빠지지 않는다

라이브 서비스는 한 번 만든 기능을 좀처럼 지우지 못한다. 이미 그 기능을 쓰고 있는 사용자가 있고, 없애면 항의가 들어온다. 쓰는 사람이 적어도 마찬가지다. 그래서 업데이트마다 새 기능은 더해지는데, 기존 기능은 그대로 남는다.

문제는 늘어나는 것이 기능의 개수만이 아니라는 점이다. 기능이 늘면 기능끼리 서로 영향을 주는 경우의 수가 같이 늘어난다. 하나를 수정할 때 확인해야 할 범위도 같이 커진다. 그래서 유지보수 부담은 기능이 늘어나는 속도보다 빠르게 커진다.

얽혀 있는 구조를 AI가 정확히 파악하지 못한다

라이브 서비스는 데이터 테이블과 오래된 코드가 스파게티처럼 복잡하게 연결되어 있다. 파트끼리 공유하는 문서 형식도 마찬가지다. 그래서 특정 파트만 떼어 AI로 처리할 수가 없다.

AI가 대충 해석은 할 수 있을지 몰라도, 사용자가 정확히 짚어 주지 않으면 완벽히 파악하지 못한다. 관련 코드 파일과 로직 구조, 돌아가는 흐름과 세팅된 데이터 값을 모두 던져 주고 시간을 주고 진행 도중 포인트를 짚어 주면서 진행해도 한계가 있다. 어느 정도 파악한 것 같아 테스트 케이스를 돌려 보면, 꼭 20% 정도는 엉뚱한 값이 들어가거나 값을 비워 놓는 경우가 생긴다.

이런 부분이 자칫 큰 사고로 이어진다. 예를 들어, 게임 조직에서 어떤 아이템을 추가하는 기능을 바이브코딩으로 만들거나, AI를 통한 자동화 도구로 구축했다고 가정해 보자.

아이템을 데이터 테이블에 몇 개 추가하고, 데이터 연결성을 모두 통과하여 QA까지 검수 완료된 아이템이 라이브에 패치되었다. 그런데 패치 몇 시간 뒤 갑자기 메신저가 울린다. 아이템을 얻을 수 있는 획득처가 잘못 설정된 것이다. 그럴 리가. 분명 데이터 연결성 검증도 통과하고 QA도 확인한 부분이다. 다시 살펴본다. “A던전 보스를 클리어”해야 얻을 수 있는 아이템인데, “A던전 전체에서 획득 가능한” 아이템으로 설정되어 있다.

유저들은 난리가 났다. 돈을 써서 던전을 열심히 돌았는데 하나도 안 나온다, 유저 기만이다, 환불해라. 큰일 났다. 다시 확인해 본다. 아이템을 설정하는 시트 내부, 해당 아이템의 획득처 설정에서 onlyBoss 컬럼의 값이 FALSE인 것이다. 데이터 연결성 체크에서는 저 값이 TRUE이든 FALSE이든 상관없이 값이 있으면 PASS 처리되고, QA 과정에서는 A던전의 보스를 잡았더니 나왔다고 판단되어 OK 사인이 떨어진 것이다. 물론 이런 상황은 어느 정도 QA와 작업자의 미스이지만, 항상 모든 이슈는 이런 실수로부터 시작된다라는 가정을 하고 넘어가자.

AI에게 현재 상황을 말하고 왜 저 셀 값을 TRUE가 아니라 FALSE로 했는지 추궁하니, 자신의 판단에 있어 그 부분이 세팅 시 명확히 제공되지 않아 폴백 과정에서 FALSE로 처리했다고 답한다. 죄송하다는 말과 함께.

세팅과 폴리싱은 다른 일이다

라이브 작업 중에는 사람이 창의성을 발휘해야 하는 종류가 섞여 있다. 게임이라면 신규 스킬이나 패턴을 만드는 일이 그렇다. 그런데 이 작업은 아이디어를 내는 것으로 끝나지 않는다.

5년 전에 시작한 어떤 게임의 라이브 서비스가 있다고 가정해 보자. 스킬 하나를 만들기 위해서는 엑셀 파일 세 개를 동시에 열어 작업해야 하고, 만들어진 스킬을 다시 캐릭터에 연결하는 작업까지 하면 대략 열 개 정도의 엑셀 시트에 데이터가 올바르게 입력되어야 한다.

보통 게임에서 사용되는 데이터 테이블 값이 단순히 수치만 입력된 것이 아니다. 업데이트에서 클라이언트 코드를 수정하면 바이너리 업데이트가 필요해지기 때문에, 통상적인 게임에서 데이터 테이블은 스크립트를 적당히 엑셀에 구겨 넣은 형태다. A1 셀에 30, 이런 식으로 들어가는 것이 아니라 skill(스킬ENUM, 밸류, val1, val2, 스킬타입) 같은 식이다. 게임 장르나 리드 프로그래머의 성향에 따라 다를 수 있지만, 대개는 이런 식의 복잡한 문자열 기반이 많을 것이다. 게다가 라이브 업데이트에서 스킬 파라미터가 바뀌면 이 부분도 같이 바뀐다. 간단한 스킬 데이터도 저런 문자열 기반, 혹은 스크립팅 데이터가 복잡하게 얽혀 동작한다.

게다가 이 부분은 제작자의 창의성이 필요하다. 게임을 해 본 사람이라면 알겠지만 스킬 하나에는 많은 리소스가 포함된다. 어떤 이펙트를 쓸 것인지, 이펙트의 범위는 어떻게 되는지, 사운드는 어느 타이밍에 시작되는지, 시전 속도, 소모 자원, 아이콘, 쿨타임 등. 이런 부분은 단순히 값을 채워 넣는 게 아니라, 최초 세팅 후 수 시간 혹은 몇 달 동안 계속 폴리싱하여 깎아 나가야 유저들에게 제공할 수 있는 프로덕트 레벨의 아웃풋이 나온다.

AI는 값을 세팅할 수는 있어도, 세팅된 값이 유저 입장에서 어떻게 느껴지는지 알 수 없다.

그 사이 담당자는 계속 바뀐다

이런 복잡도를 가진 작업이 수개월, 수년간 누적되며 서비스는 피로해지고 사람은 떠나거나 교체된다. 코드와 데이터, 리소스들은 계속 남게 되지만 정작 그걸 만든 사람은 조직에 남아 있지 않다. 문서가 남아 있어도 왜 그렇게 만들었는지까지 정확히 적혀 있는 경우는 드물고, 코드 주석도 마찬가지다. 심지어 이 부분이 중간중간 유지보수가 누락되면서 서로 안 맞는 경우도 생긴다. 서비스는 돌아가지만, 왜 이렇게 만들어졌고 구현되었는지를 아는 히스토리를 아는 사람이 없어진다. 결국 시스템이 아니라 몇몇 사람에 의해 겨우겨우 연명해 가는 형태가 된다.

남은 사람들이나 충원된 인력은 각자 자기가 맡은 부분만 겨우 이해한 상태로 아슬아슬한 유지보수를 이어가게 된다. 자기 담당이 아닌 부분은 아예 건드리지 않는 것이 서비스 관점이나 자기 관리 관점에서 유리하기 때문에, 제발 무너지지 않아라 기도하며 아슬아슬한 줄타기를 하고 있는 현실이 생기게 된다.

너무나 쓰고 싶고, 해야 하지만, 어디서부터 써야 할지 모르겠다

이런 문제들이 겹겹이 쌓이면서 모순이 생긴다. 회사가 줄이고 싶어 하는 비용의 1순위는 라이브 유지보수다. 인원이 계속 붙어 있어야 하고, 컴퓨터 전원 끄듯 내일 당장 서비스를 종료할 수도 없다.

더군다나 유지보수 인력이 계속 있을 거라는 보장도 없다. 라이브가 겨우 유지되는 조직은 보통 성과나 달성, 이로 인한 리워드가 박한 편이라 인력 이탈이 빈번하고, 심지어 이탈된 인원을 충원하기도 힘들다. 더 좋은 비전과 미래를 가진 신규 조직, 혹은 같은 라이브여도 굉장히 고밸류의 서비스를 제공하는 조직이 아니라면, 구직자 입장에서도 이 조직을 선택할 메리트가 극히 적기 때문이다.

따라서 회사나 내부 조직도 AI를 활용하여 이 부분을 어떻게든 극복해 보고 싶어 한다. 하지만 역설적으로 이런 라이브 서비스는 AI를 도입하기 어려운 구조적인 문제가 있다.

일정도, 검증할 여력도 없다

빡빡한 라이브 일정에서 위험을 감수하기는 어렵고, 도입하더라도 별도 QA를 붙이기 어렵다. AI로 기능 한두 개를 고쳐서 써 보다가 결국 이슈가 생기거나 생각만큼 효율이 나오지 않고, 당면한 일감에 치여 문제들을 모두 해결할 수 없어 결국 다시 원래 방식으로 회귀한다.

앞에서 말한 데이터 구조를 직접 겪고 나면, 작업자 입장에선 공포가 생긴다. AI가 저 셀 하나를 인식하게 하는 것도 몇 시간이 걸리는데, 각 데이터 시트의 연결도를 정리하고 오차 없이 도구를 만들 수 있을까. 지금은 개발 단계가 아니라 5년차 라이브 서비스 중인데 말이다. 다음 주 업데이트를 준비해야 하고, 다음 달 메이저 업데이트도 준비해야 한다.

몇 번 시도해서 겨우 도구를 만들어 내고 돌려 보면 오류투성이다. 게다가 검증은 당사자가 직접 해야 한다. 앞에서 본 것처럼, 시키지도 않은 부분을 AI가 추론해서 처리해 놓은 경우까지 직접 찾아내야 한다. 이런 위험을 안고 과연 어떤 실무자가 공격적으로 AI를 도입할 수 있을까.

문제가 났을 때 누가 책임지는지가 정해져 있지 않다

앞의 문제들은 조직 안에서 결국 이런 모습으로 드러난다. 위에서는 왜 안 쓰냐고 묻고, 아래에서는 사고 나면 누가 책임지냐고 답한다. 어느 쪽도 틀린 말을 하고 있지 않다.

경영진 입장에서는 경쟁사도 다 쓰는 도구를 우리만 안 쓰는 상황을 방치할 수 없다. 실무자 입장에서는 문제가 생겼을 때 결국 자기가 밤을 새우고, 자기 이름이 사고 보고서에 올라간다. 실무자가 소극적인 이유는 능력이 없어서가 아니라, 결정 권한은 없는 상태에서 위험과 책임만 혼자 지기 때문이다. 도입 여부를 정하는 사람과 문제가 났을 때 수습하는 사람이 다르면, 소극적인 태도일 수밖에 없다.

이 상태를 그냥 두면 조직은 이상해진다. 공식적으로는 AI를 도입한 회사인데, 실제로는 각자 알아서 개인 도구를 쓰는 상태로 굳는다. 무엇을 어디까지 썼는지 아무도 정리하지 않으니, 나중에 문제가 생겨도 원인을 찾기 어렵다.

그럼에도 해야 하고, 할 수 있는 부분은 있다

도구 성능을 아무리 비교해도 이 상황은 풀리지 않는다. 더 좋은 모델이 나와도 데이터 구조가 복잡한 것은 그대로고, 일정이 빠듯한 것도 그대로다.

그렇다고 책임 소재를 정하는 것으로 끝날 문제도 아니다. 누가 책임질지를 문서로 정해 둔다고 해서 데이터 구조가 단순해지지도, 검증할 시간이 생기지도 않는다. 책임이 명확해지면 시도할 여지가 조금 생기는 정도이고, 그 다음이 없으면 결국 아무것도 달라지지 않는다. 그렇다고 안 할 수도 없다. 그러니 필요한 것은 지금 조건에서 실제로 굴러갈 수 있는 방법을 찾는 일이다.

양쪽 모두에 조정이 필요하다.

책임자 쪽에서는 지금 수준의 AI가 모든 것을 자동화할 수 없다는 점과, 실무자가 소극적일 수밖에 없는 것임을 이해해야 한다. 그리고 단순히 “하라면 해라” 혹은 책임 소재 같은 주관적 요소가 아니라, 실무자에게 구체적인 현재 상황을 요청하고 그로 인해 발생할 수 있는 문제점과 실 이득을 명확히 해야 한다.

지원이 필요하다면, 세미나 참석이나 강의 수강같이 실무자 입장에선 뜬구름 잡는 것들이 아니라, AI를 도입하기 위해 필요한 시간과 KPI를 명확히 지정해 주는 것이다. AI를 도입한다고 당장 내일부터 나아지는 것이 아니다. AI를 사용하여 결과물이 나올 때까지는 시간이 걸리고, 그것이 실제 눈에 보이는 코스트 절감으로 이어지기까지는 생각보다 오랜 시간이 소요될 수 있다. 

도입 후 개발 사이드에서의 시행착오, 그 시행착오를 거쳐 새로운 파이프라인을 만들었을 때 파이프라인의 안정성을 검증해야 하는 시간, 프로덕트로 배포되었을 때 사용자 사이드에서 이전과 같은 수준으로 느끼는지에 대한 반응까지. 단순히 AI로 무언가 만들어 낸 것과 달리, 라이브 서비스에서는 이 모든 것이 완료될 때까지를 KPI에 편입해야 서로의 이해관계가 맞는다.

실무자 쪽에서는 모든 AI 활용을 라이브 사고 위험과 같은 것으로 놓고 전면 거부하는 태도를 다시 봐야 한다. 위험한 부분도 있지만, 그렇지 않은 부분도 분명히 있다. 그 구분을 가장 정확히 할 수 있는 사람은 실무자다. 안전하게 시도할 수 있는 업무를 골라내는 것 자체가 실무자만 할 수 있는 일이다.

그리고 현재 구조를 구체적으로 정리하고 명시해서 상급자와 소통해야 한다. 단순히 “위험해서 안 된다”는 건 상위자 입장에서 받아들일 수 없는 변명처럼 들리기 때문에, 이를 정확히 왜 어떻게 안 되는지, 혹은 어떤 부분이 가능한지, 앞에서 말한 것처럼 도입은 가능하나 발생할 수 있는 개발적 리스크와 품질적 리스크는 무엇이고 파이프라인 적용 후 사후 플랜은 어떻게 되는지로 정리하는 것도 실무자가 해야만 하는 일이다.

반복되는 작은 작업부터 시작한다

내 생각은 이렇다. 아주 작은 것부터 하나씩 해 보는 것이다. 라이브 서비스를 해 본 사람이라면 이해하겠지만, 라이브 서비스는 정말 자잘자잘한 것들이 모이고 모여 서비스의 부채를 만드는 경우가 많다. 추가하거나 변경할 때는 코드 몇 줄, 혹은 데이터 셀 몇 개, 스프라이트 리소스 몇 개였을지라도, 이것들이 시간이 지남에 따라 계속 누적되어 코스트를 만든다.

그러니 엄두가 안 나는 것이다. 개발자 입장에서는 가장 큰 것부터 줄이고 싶지만, 오히려 그렇게 큰 부분은 파이프라인 자체를 통째로 변경하거나 대규모 리팩토링을 해야 하는 경우, 혹은 연관된 부분이 너무 많아 사이드 이펙트를 만들 수 있는 경우일 가능성이 높다.

따라서 가장 작은 것부터, 가장 귀찮은 것부터, 그리고 가장 중요한 건 조직 구성원 개개인이 가볍게 시도할 수 있는 것부터 해야 한다. 그래야 AI를 다루는 스킬이 늘어나고, 처음엔 막막했더라도 어디서부터 어디까지 가능한지에 대한 개념이 생길 것이다.

예를 들어, 데이터 시트를 변경하거나 자동화 툴을 만들어야 하는 비프로그래머 조직에서는 데이터 입력, 파이프라인 문서 포맷, 데이터 연결성 검증 등이 늘 문제가 된다. 특히 데이터 연결성 검증이나, 특정 기능 혹은 엔진상에서 클라이언트 온리로 동작하던 시뮬레이션 기능 등이 필요할 경우, 이슈 발제부터 컨펌, 구현 명세서 작성, 구현 요청, 테스트를 거치는 일반적인 개발 파이프라인을 여러 파트에 걸쳐 확인받고 핑퐁하여 만들어야 했다. 상상만 해도 머리 아픈 일이다.

지금은 작업 당사자가 직접 도구를 만들어 볼 수 있다. 이 방식은 서비스 자체를 건드리지 않으니 승인하는 쪽에서 결정하기 쉽고, 요청 명세서처럼 다른 파트에 설명하기 위해 해야 하는 기반 작업 없이 필요한 사람이 즉시 만들 수 있기 때문에 명확한 결과물이 나온다. 이것이 즉시 라이브 서비스에 도움이 되진 않더라도, 라이브 서비스를 진행하면서 작은 것들이 누적되어 큰 라이브 코스트를 만들듯이, 이런 시도들이 하나하나 모여 어느샌가 정말 눈에 띌 정도로 코스트나 프로세스 절감, 혹은 라이브 서비스의 효율성 상승, 프로덕트 완성도 상승 등의 긍정적인 효과로 이어질 수 있는 것이다.

내 경험도 여기서 출발한다. 엑셀 입력 시 휴먼에러를 줄이는 일, 다량의 시트를 한 번에 바꾸는 일, 전투 공식 문서를 최신화하기 위해 전투 관련 코드를 직접 분석해서 프로그래머와 함께 유지보수용 문서를 최신화하는 일, 혹은 콘텐츠마다 설정된 확률값이 현재 데이터와 안내된 값이 맞는지 크로스 체크하는 일들이었다. 당시 전투 담당 클라이언트 프로그래머도 초기 멤버가 아니어서 모든 히스토리를 알고 있지 못했고, 부분부분 모르는 부분이 서로 존재하는 상황이었다.

우선 기획 파트 및 CS 파트에서 매번 궁금하거나 필요한 위키 형태의 정리가 필요했고, 각 파트에서는 리스트를 정리해 담당 프로그래머에게 넘겼다. 또한 전투를 담당하던 기획자는 알려진 버그 및 전투 시 발생하는 기능들의 우선순위를 알기 위해 해당 부분이 어떤 코드 파일을 참조하는지 프로그래머와 핑퐁했다. 프로그래머는 기존 히스토리 점검 및 위키를 정리하며 자신이 알고 있는 내용을 최신화했고, 다른 파트에서는 최신화된 데이터를 갱신할 수 있게 되어 매번 프로그램 파트에 문의하던 비효율적인 프로세스를 끊어낼 수 있었다.

핵심은, 일반적인 업무 과정처럼 보이는 이 과정이 실제 라이브 조직에서는 AI를 사용한 코드 분석 및 정리 없이는 쉽지 않다는 점이었다. 이걸 그냥 하려면 최소한 2주짜리 작업이었는데, 불과 이틀 만에 모두 마무리할 수 있었다. 그때 당시에는 조직 구성원 모두가 AI에 익숙하지 않아 회의적이었는데, 결과물이 일목요연하게 이틀 만에 정리된 것을 보고 모두 여론이 바뀌는 계기가 되었다.

데이터 시트를 최신화하는 경험은 구체적으로 이런 사례였다. 엑셀 파일 하나가 50메가가 넘는다. 겨우 엑셀 파일 하나 여는데 이렇게 무겁다고? 하는 상황이다. 게다가 파일을 열어 보면 각종 서식, 중복 체크, 데이터 무결성 검사 등, 정말 엑셀을 열어 수정할 때마다 짜증과 한숨이 나올 수밖에 없다. 그런 상황에서 순간적으로 잘못된 셀에 데이터가 입력되는 경우가 잦고, 그게 라이브에 나가면 주말에 메신저가 울린다.

깃(Git)이나 SVN에서 데이터 변경 사항을 diff로 확인하면 되는 거 아니냐고 할 수 있다. 5년차 라이브 서비스 게임의 데이터 양은 diff로 확인할 수 있는 수준이 아니다. 그래서 필자는 이런 방식을 시도해 봤다. 앞서 말한 서식과 중복 체크, 데이터 무결성 검사 같은 엑셀 자체의 기능은 모두 끄고, 그 역할을 대신할 기능을 따로 만드는 것이다. 엑셀을 닫을 때 이번 작업에서 수정한 부분이 어느 시트의 어느 셀인지 추가 확인창을 띄우는 식이다. 엑셀의 주요 기능, 특히 데이터 유효성 검사 등은 여러 사람이 사용할 경우 문제를 일으킬 가능성이 높기 때문이다. 

그리고 더 나아가, 해당 엑셀을 직접 수정하는 게 아니라 마치 포인터처럼 파일을 열지 않고 수정할 수 있는 툴을 만들어 보기도 했다.

처음엔 성공적이었다. 엑셀 파일을 매번 직접 열 필요가 없어지니 엑셀이 무거워짐으로 인해 발생하는 버벅거림이 사라졌고, 작업자들의 스트레스가 줄어드는 간접적인 효과도 있었다. 다만 이 역시 필자가 해당 게임의 라이브 서비스에서 손을 떼고 툴 유지보수가 끊기면서, 이후에는 다시 레거시 방식으로 돌아갔다고 전해진다. (단, 이 부분은 AI를 통한 자동화 이슈라기보다는 조직 사이드에서 발생한 인수인계 프로세스 문제라, AI의 문제는 아니라고 생각되긴 한다.)

정리할 대상이 반복 입력만은 아니다. 하나의 기획서를 각 파트가 쓸 수 있는 형태로 옮기는 작업도 매번 반복된다. 같은 내용을 파트마다 다른 형식으로 다시 쓰는 일이다. 이 변환 규칙을 도구로 만들어 두면 반복 작업이 줄어든다. 그리고 어떤 형식으로 주고받기로 했는지가 사람의 기억이 아니라 도구에 남으니, 담당자가 바뀔 때 히스토리가 사라지는 문제도 조금은 덜해진다.

모두 드라마틱하게 라이브 코스트를 줄여 주는 부분은 아니었지만, 분명히 필요한 부분이었다. 특히 전투 관련 코드, 문서 최신화와 콘텐츠 확률값 점검은 계속 해야지, 해야지 하면서 미루고 미루던 일이었다. 당장 생산성에 도움이 되지 않더라도 해야 하는데, 일정상 계속 뒤로 밀려 부채가 쌓이던 상황이었기 때문이다.

넘지 말아야 할 부분

반대로 지금 수준에서 하지 말아야 할 것도 있다. 실사용자와 서비스 데이터베이스에 AI가 직접 쓰기 작업을 하도록 자동화하는 것이다. 읽어서 정리하는 것까지는 괜찮지만, 사람 확인 없이 바꾸게 두면 앞에서 말한 문제들이 그대로 재현된다.

마치며

정리하면 이렇다. 라이브 조직이 AI를 쓰지 못하는 이유는 몰라서도 게을러서도 아니다. 데이터와 코드가 오래 얽혀 있어 부분만 떼어 낼 수 없고, 사람이 감각으로 깎아야 하는 작업이 섞여 있고, 일정에 검증할 여유가 없기 때문이다. 당장 바꾸기 어려운 조건들이다. 그렇다고 손을 놓을 수도 없으니, 그 안에서 지금 할 수 있는 것을 찾아야 한다.

그리고 처음부터 크게 시작할 필요는 없다고 본다. 가능한 부분부터 명확히 한다. 그리고 너무 보수적으로 접근할 필요도 없다. 단순한 반복 작업부터 시작해서, 조직 전체가 AI에 익숙해지는 속도에 맞춰 범위를 넓혀 가는 편이 현실적이다. 작게 보이지만 이런 시도가 쌓여야 다음 단계를 설득할 근거가 생긴다. 근거 없이 위에서 밀어붙이거나 아래에서 버티기만 하면, 조직이나 프로덕트, 혹은 작업자 개인 모두 아무것도 얻을 수 없다.

AI를 거부할 수 있는 흐름은 이제 그 어디에도 존재하지 않는다. 그러나 아직 각자의 위치에서 AI 사용에 대한 인지 상태가 크게 다르기에, 우리는 단순히 AI를 써야 한다가 아니라, AI를 쓰기 위해서 필요한 것부터 접근하는 방식을 써야 한다.

AI는 한 사람이 직접 할 수 있는 일의 범위를 넓혀 준다. 다만 무엇을 맡기고 무엇을 사람이 할지는 여전히 사람이 정할 수밖에 없다. 라이브 서비스는 수많은 이해관계가 정말 상상할 수 없을 만큼 어지럽게 묶여 있다. 그래서 AI 도입이 기술적인 문제가 아니라, 사람과 사람 간의 이해관계 구조에 있다. 답답하고 막막하지만, 그 구조 안에서도 시작할 수 있는 부분은 있다는 것을 모두에게 전하고 싶다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.