최근 많은 조직과 기업에서 AX를 강조하고 있습니다. 다만 AX가 정확히 무엇인지, 실체가 있는 것인지, 조직마다 공통된 지침이 있는 것인지에 대해서는 아직 다양한 의견과 방법론이 혼재되어 있다고 느낍니다. “DX도 아직 충분히 안 되었는데 AX를 말하는 것이 맞는가?” 라는 질문도 자연스럽게 나옵니다. 저도 이 혼란이 실제 현업에서 매우 크게 느껴진다고 생각합니다. 최근 하네스 엔지니어링으로 강의 제안이 많이 있습니다. 저는 이런 강의 자리에서 하고 싶었던 역할은, “당장 모든 조직이 하네스 엔지니어링을 적용해야 합니다”라고 말하는 것이 아니라, 현재 AI 도구와 에이전트 활용이 현실적으로 어디까지 와 있는지 보여드리는 것이었습니다. 지금 당장 도입하기 어렵더라도, 가능한 수준을 먼저 이해하면 방향성이 생깁니다. “아, AI 활용이 단순히 프롬프트를 잘 쓰는 수준에서 끝나는 것이 아니라, 결국 AI 에이전트를 기반으로 도구 연결, 역할 분리, 검증 구조, 업무 프로세스 재설계까지 가는구나”라는 그림을 보는 것만으로도 의미가 있다고 생각했습니다. 즉, 하네스 엔지니어링은 모든 구성원이 오늘 바로 실무에 적용해야 하는 출발점이라기보다는, AX가 향할 수 있는 상위 단계의 모습에 가깝습니다. 저는 AX를 단순히 “AI 도구를 잘 쓰는 것”으로 보지 않습니다. AX는 AI가 업무의 일부를 읽고, 정리하고, 판단을 보조하고, 때로는 승인된 범위 안에서 실행할 수 있도록 업무 방식 자체를 다시 설계하는 전환에 가깝습니다. 그래서 AX는 도구의 문제가 아니라 업무, 데이터, 권한, 검증, 책임의 문제입니다. AX 전환을 대략 다음 단계로 보고 있습니다. - AI 도구를 개인 업무에 사용해보는 단계 - 프롬프트를 통해 문서 작성, 요약, 정리, 아이디어 발산을 돕는 단계 - 반복 업무를 템플릿화하고, 개인 업무 루틴을 자동화하는 단계 - 사내 도구나 데이터와 AI를 안전하게 연결하는 단계 - 업무 절차를 AI가 이해하고 수행할 수 있도록 구조화하는 단계 - 에이전트, 스킬, MCP, 검증 루프를 포함한 AI 환경을 구축하는 단계 - 사람과 AI가 함께 일하는 방식으로 조직 프로세스를 재설계하는 단계 이렇게 보면, 프롬프트 엔지니어링은 AX의 끝이 아니라 초입에 가깝습니다. 반대로 하네스 엔지니어링은 초심자에게 바로 적용하기에는 어려울 수 있지만, 조직이 앞으로 가야 할 방향을 보여주는 데에는 의미가 있습니다. 또한 직군별 AX 로드맵은 같을 수 없습니다. 비테크 직군은 “내 업무를 더 빨리 정리하고, 문서화하고, 의사결정을 돕는 방향”에서 시작하는 것이 좋습니다. 개발 직군은 “코드 생산과 검증, 리뷰, 테스트 자동화”에서 빠르게 효과를 볼 수 있습니다. 인프라와 보안 직군은 “자동 실행”보다 “조회, 요약, 검증, 승인 기반 실행”부터 접근해야 합니다. 리더나 매니저 직군은 “업무 프로세스를 AI가 일하기 좋은 형태로 재설계하는 것”이 더 중요해질 수 있습니다. 하네스 엔지니어링은 프롬프트 엔지니어링 단계에 있는 분들에게는 다소 앞선 주제일 수 있습니다. 하지만 동시에, AX가 단순히 “ChatGPT를 잘 쓰는 법”에서 끝나지 않는다는 점을 보여주는 주제이기도 합니다. AX는 각자의 업무에서 가장 반복적이고, 가장 시간이 많이 들고, 가장 위험도가 낮으며, AI가 실수해도 사람이 쉽게 검토할 수 있는 영역부터 시작하는 것이 현실적입니다. 캘린더, 메일, Jira, Git issue, 모니터링, 온콜 스케줄, 결재함 등을 한 번에 요약해 “오늘 내가 먼저 봐야 할 것”을 정리하는 것은 거창한 자율 에이전트는 아니지만, 실제 업무 시간을 줄여주는 현실적인 AX입니다. 저는 이런 작은 자동화가 쌓이면서 조직의 업무 방식이 바뀐다고 봅니다. 인프라 담당자의 예를 들면, AX는 처음부터 AI가 장애를 고치고, 운영 서버를 제어하고, 모든 결정을 대신하는 것이 아닙니다. 오히려 처음에는 사람이 더 빨리 파악하고, 더 적게 놓치고, 더 안정적으로 판단할 수 있게 돕는 것이 중요합니다. 이렇게 각자의 업무 맥락에 맞게 연결될 때, AX가 추상적인 구호가 아니라 실제 생산성 변화로 이어질 수 있다고 생각합니다. 이를 위해서 기업은 이런한 시도를 누구나 할 수 있도록 하는 환경을 제공할 의무가 있다고 생각합니다. AI 활용을 개인의 관심과 개인 결제에 맡겨서는 조직 전환이 일어나기 어렵습니다. 필요한 AI 도구를 적시에 제공하고, AI 크레딧을 제공하며, GPU 사용이 가능하도록 해야 합니다. AI 활용 교육과 사내 가이드라인을 만들고, 개인의 판단에 맡기기 보다는 허용과 비허용 기준을 수립해 혼란스럽지 않도록 해야 합니다. AI 활용 모범 사례를 적극 발굴하고, 공유를 해야 합니다. 고리타분한 단기 성과 측정 프레임워크보다는 어떤 일이 가치가 있었는지, 어떤 혁신이 있었는지 모니터링하고, 혁신을 발휘한 개인 또는 조직에는 즉각 보상을 합니다. AI 잘 쓰고 계신가요? 이 질문에 많은 분들이 “AI를 해보고 싶은데 일이 바빠서 못합니다"고 답합니다. 우리는 AI 를 왜 써야 하는지 다시 한번 새겨보면 좋을 것 같습니다. 어쩌면 그 자체가 AX가 필요한 가장 분명한 이유입니다.

최근 IT 업계에서 AX를 외치는 목소리가 높습니다. 하지만 현업에서는 DX도 제대로 끝나지 않아 피로감이 큽니다. 이 혼란의 실체를 분석해보면 거창한 구호 대신 현실적인 단계부터 짚어야 합니다.

프롬프트를 넘어 워크플로우 재설계로

AX의 최종 목적지는 단순히 프롬프트를 잘 작성하는 수준을 넘어 업무 프로세스를 재설계하는 일입니다. AI가 문서를 읽고 판단을 보조하며 승인된 범위 안에서 실행하는 구조를 구축하는 작업이 핵심입니다. AX는 단순한 도구 도입이 아니라 권한과 검증의 문제입니다. 방향이 중요합니다.

AX 전환은 단계적으로 일어납니다. 초기에는 개인 업무에 AI 도구를 활용하다가 프롬프트 템플릿으로 자동화를 시도합니다. 이후 사내 데이터와 AI를 안전하게 연결하고 최종적으로 MCP 나 검증 루프를 포함한 에이전트 환경을 구축합니다. 하네스 엔지니어링 은 이 여정의 상위 단계를 보여주는 대표적인 사례입니다. 단계가 높습니다.

직군별 로드맵과 작고 확실한 시작

조직 구성원 모두가 똑같은 방식으로 AX 에 진입할 필요는 없습니다. 비테크 직군은 문서 요약에서 출발하고 개발자는 코드 생성과 테스트 자동화에서 빠르게 효율을 높입니다. 인프라 직군은 자동 실행보다 검증 기반의 승인 프로세스로 접근해야 안전합니다. 역할이 다릅니다.

거창한 에이전트보다 메일과 Jira 의 이슈를 요약해 오늘 할 일을 정리해주는 시스템이 유용합니다. 인프라 담당자에게 필요한 AI도 서버 제어보다는 장애 상황을 빠르게 파악하도록 지원하는 수준이 적당합니다. 작은 자동화가 쌓여야 조직의 업무 방식이 변합니다. 부담이 없습니다.

현업에서 흔히 마주치는 캘린더 정리나 결재함 요약 같은 일들이 좋은 출발점입니다. 위험도가 낮고 실수가 나와도 사람이 쉽게 검토하는 영역부터 시작해야 현실적입니다. 이런 맥락 있는 연결이 실제 생산성 향상으로 이어집니다. 속도가 붙습니다.

기업이 닦아야 할 인프라와 보상 체계

개인이 사비로 결제해 사용하도록 방치하는 조직에서는 진정한 전환이 일어나지 않습니다. 기업은 필요한 AI 도구와 크레딧을 적시에 제공하고 명확한 보안 가이드라인을 수립해 혼란을 줄여야 합니다. 인프라와 비용을 개인이 책임지게 해서는 안 됩니다. 지원이 먼저입니다.

구태의연한 단기 성과 측정 방식을 버리고 실질적인 업무 개선을 보여준 팀에 즉각 보상하는 문화를 구축해야 합니다. 성공 사례를 적극적으로 발굴하고 사내에 공유하여 동기를 불어넣어야 합니다. 보상이 답입니다.

AI를 해보고 싶은데 일이 바빠서 못한다는 푸념을 자주 듣습니다. 역설적으로 바쁜 업무를 덜어내기 위해 지금 AX 를 도입해야 합니다.

요약

  • AX는 단순한 AI 도구 사용을 넘어 권한, 검증, 책임을 포함한 업무 프로세스 자체의 재설계입니다.
  • 모든 직군이 동일한 AX 로드맵을 따를 필요는 없으며 직무 특성에 맞춰 위험도가 낮은 영역부터 단계적으로 접근해야 합니다.
  • 성공적인 AX를 위해서 기업은 인프라와 크레딧을 전폭 지원하고 단기 성과 측정 대신 실질적 업무 개선에 즉각 보상해야 합니다.