AI Native, JX라는 말

주변에서 ‘AI Native’라는 말을 많이 듣고 접하게 되는 요즘이다.

세간에서 말하는 AI Native의 정의를 보면, ‘디지털 네이티브’에서 파생된 말로 단순히 AI를 도구로 쓰는 수준을 넘어 AI를 사고방식의 중심에 두는 상태를 뜻한다고 한다. 어떤 문제를 마주했을 때 ‘내가 어떻게 할까’가 아니라 ‘이걸 AI로 어떻게 가장 효율적으로 풀까’를 본능적으로 떠올리는 것이라고 한다.

우리 회사에서도 AI Native를 이야기하면서, AX를 넘어 JX로 직무 전환을 해야 한다고 말하곤 한다.

• AX (AI Transformation): AI를 이용해 기술 인프라와 생산성을 높이는 것
• JX (Job Transformation): 직무와 고용 환경이 근본적으로 변화하는 현상

개인적으로, 너무나 빠르게 급변하는 사회에서 구시대의 업무 체계가 더 이상 효율적이지 않다는 말에는 어느 정도 공감하는 입장이다. 그래서 이 변화 자체를 그렇게 나쁘다고만 생각하지는 않는다.

다만, 목적이 없는 변화만큼 실무자에게 스트레스가 되는 것도 없다고 생각한다. 실제로 이 용어를 듣고 ‘내가 이 전환을 해내야 한다’고 생각했을 때, 최종 그림이 잘 그려지지 않아 막막함을 느끼는 요즘이기도 하다.

AI Native가 뭐길래 다들 이 문화를 찬양하고, 그렇게 따라가야 한다고 생각하는 걸까? 이 안에 숨어있는 것들은 무엇이고, 명확하게 정의를 한다면 어떤 로드맵을 그리는 것이 ‘건강한 AI Native’가 되는 것일까.

그래서, 만약 내가 회사를 운영하는 대표라면 어떤 그림을 원하고 있을지 한번 고민해보기로 했다.

내가 대표라면 어떤 그림을 원할까

내가 대표라면, 직원들이 더 가치 있는 업무에 집중할 수 있는 환경을 만들고, 고부가가치 업무 위주의 핵심 인력만 남기고 싶지 않을까 싶다.

가령 먼 옛날, 주판으로 계산하던 시절을 떠올려보자. 계산기와 컴퓨터가 등장하면서, 주판 전문가 3명을 쓸 비용으로 컴퓨터 전문가 1명을 쓰는 게 더 효율적이게 되는 시점이 분명 있었을 것이다.

그때의 주판이, 지금의 단순 코딩이나 반복 작업으로 비춰지는 것 같기도 하다.

근데 실무자 입장이라면

단순히 생각하면 이렇겠지만, 실무자의 입장과 대조해서 생각해보면 전환 과정에서 이런 점들이 제일 고민이 될 것 같다.

만약 내가 주판 업무를 컴퓨터로 이관해야 하는 담당자가 되었다고 생각해보자.

• 주판으로 계산하던 로직과 기존의 업무 체계를 안전하게 마이그레이션해야 한다.
• 기존 방식에만 존재하던 암묵지를 밝혀, 최종 결과물이 나오는 과정에서 불필요한 과정을 컴퓨터에게 위임할 수 있어야 한다.
• 그것을 위임하는 사람은 기존에 주판을 다루던 방식을 모두 다 알 필요는 없지만, 그들의 습관과 행동양식으로부터 파생되어 생략되는 것을 지속적으로 주의해야 한다.
• 주판을 다루던 인원들이 컴퓨터를 잘 사용할 수 있도록 해야 한다. (고용노동법상 막 자를 수는 없으니…?)

대략 이런 고민이 든다.

결국 중요한 건, 기존 업무 방식뿐만 아니라 내가 지금 하고 있는 행동과 습관 하나하나에 숨겨져 있는 암묵지가 무엇인지 인지하고, 그것들 중 불필요한 것을 위임하는 것이 중요해지는 시대라는 점이다.

그래서, AI Native가 뭐냐고 물으면

말이 AI Native지, 사실 마케팅용 용어처럼 보이기도 한다. 업무 자동화를 있어 보이는 말로 포장한 게 아닐까 싶기도 하다.

AI 도구 활용 사례를 공유하자는 취지 자체는 좋다. 다만 그 외에 토큰 사용량 대시보드를 만든다거나, 개발자 생산성 향상을 발표할 때 커밋 수 같은 지표를 들고 나오는 걸 보면 ‘뭐가 중요한 거지?’ 싶어진다.

지표가 하나 생기면, 그 지표를 달성하기 위한 어뷰징도 따라 생기기 마련이다. 게다가 그 지표를 왜·어떻게 달성해야 하는지에 대한 여정이 명시되지 않으면, 누구나 자연스럽게 어뷰징을 시도하게 될 것 같다. 일할 때 정작 중요한 게 아니었던 것들이 중요한 지표로 잡히는 게 불필요하게 느껴지는 이유다.

주니어 입장에서 실무자는 뭘 해야 성과로 인정받을까. 이런 것들을 고민하게 되는데, 지금 회사에서 성과 지표로 설정해둔 것들도 사실 방향성을 잘 모르겠는 것들이 있기도 하다.

그래서, 주니어인 나는

그렇다면 주니어인 나는 무엇을 해야 할까.

성과를 보는 기준부터 다시 잡아야겠다고 생각했다. ‘진짜 일을 잘한다’는 건 지금 시점에서 토큰 사용량도, 커밋 수도 아니라고 본다. 어떤 문제가 발생했을 때 근원적인 원인을 빠르게 파악하고, 해결 방식의 트레이드오프를 빠르게 재서 풀어내는 능력이 아닐까.

실제로 사내에서 정말 잘한다고 느낀 분들이 있다. 한 시니어 엔지니어는 문서화를 굉장히 꼼꼼하게 해뒀다. 덕분에 사내 공통 플랫폼이나 라이브러리를 쓸 때 별도로 질문할 필요 없이 업무를 진행할 수 있었다. 또 다른 시니어 엔지니어는 이슈나 레이턴시 같은 에러가 발생했을 때, 어떤 지표를 봐야 할지 확실히 알고 순차적으로 분석하며 근본 원인을 빠르게 파악했다. Datadog을 보고, 로그를 보고, 특정 코드의 최근 작업 내용과 데이터 파이프라인을 점검하는 등 하나하나 확인할 게 많은데도 차분하게 짚어가는 모습이 본받고 싶었다.

이런 능력은 토큰 사용량이나 커밋 수 같은 숫자로는 잡히지 않는다.

그 기준을 북극성 삼아, 앞으로 이런 것들을 시도해보려 한다.

1. 내가 일하는 방식을 불필요한 것까지 빠짐없이 설명하며, 암묵지를 걷어낸다.

내가 어떻게 일하고 있는지, 불필요하다고 생각하는 것까지 명확히 설명하면서 그 안에 숨은 암묵지를 드러내는 작업이 필요하다고 생각한다. 오히려 주니어라서 인지할 수 있는, 일에서 생략된 것들을 발굴해내는 게 내 강점이 되지 않을까. (물론 메타인지가 잘 되어 있는 시니어라면, 이런 건 주니어가 발굴할 필요도 없는 일일지도 모르겠다.)

2. 반복 업무를 자동화에서 멈추지 않고, 근본 원인까지 파고든다.

요즘 내 업무에서 가장 불필요하게 느껴지는 건 알림톡 개발이다. 장부팀에서 제공하는 데이터를 Spring Batch로 조합해 알림톡을 발송하는데, 알림톡이 신규로 추가되거나 수정될 때마다 배포를 해야 한다. 특히 A/B 테스트를 할 때가 제일 번거로웠다. ‘이게 정말 개발자인 내가 해야 할 일인가?’ 하는 물음표가 계속 생긴다.

근본 원인을 따져보면, 마케팅에서 쓰는 Braze에 어트리뷰트를 추가하고 관리할 수 있는 구조를 만들면 이 반복을 상당 부분 걷어낼 수 있을 것 같았다. 그래서 어트리뷰트를 확장 가능한 형태로 같이 고민하고 개선하자고 담당 팀에 요청했지만, 협조가 잘 되지 않았다. 해결할 수 있어 보이는 문제가 풀리지 않는 데서 답답함을 느꼈다.

그렇다고 자동화 플랫폼을 직접 만들어보려니 또 다른 벽이 있었다. 요구사항이 너무 광범위한 데다, 이미 실무자들이 주로 쓰는 도구는 Braze인데 그걸 두고 비슷한 걸 또 만드는 건 관리 포인트를 두 배로 늘리는 일이었다. 아무리 AI로 빠르게 만들 수 있어도, 그건 근본 해결이 아니었다. 그래서 지금은 병목인 채로 남아 있어 아쉬움이 있다.

그래도 이 과정에서 배운 게 있다. ‘플랫폼을 만든다’는 답으로 곧장 가지 않고, 진짜 병목이 무엇인지, 회사에서 이미 쓰는 도구로 풀 수는 없는지, 여러 트레이드오프와 비용을 먼저 따져보는 일. 그 어려운 부분에 집중하는 게 내가 해야 할 일이라는 점이다.

3. 사내 데이터와 도메인 지식을 AI가 쓰기 좋은 형태로 정제한다.

데이터를 정제하는 것도 그 일환이다. 구체적으로 말하기는 어렵지만, 사내에서 활용 중인 데이터와 도메인 지식·규칙을 어떻게 하면 최신화하기 쉽고 AI가 쓰기 좋은 방향으로 만들 수 있을지 계속 고민하고 있다.

마치며

물론 짧은 식견이라, 내가 아직 이해하지 못한 모르는 무언가가 있는 것 같기도 하다.

이 시대에 어떻게 학습해야 하는지도 사실 잘 모르겠다. 그래도 더 많이 시도하며 더 많은 기록을 남기고, 경험을 단단하게 다지며, 꾸준히 메타인지를 갈고닦으면서 누구보다 내가 나를 잘 알아가는 것. 그게 이 시대의 좋은 학습이자 무기가 되지 않을까 생각한다.