AX란 무엇인가 (4)
AX 여정기 (4) : 바이브 코딩을 멈추고, 조직을 코딩하다
불과 얼마 전까지만 해도, 나의 퇴근 후와 주말은 오롯이 '만드는 즐거움'으로 채워져 있었다.
새로운 기술이 나오면 일주일에 한 번씩 내가 가진 클라우드 기반 지식에 자연어와 프롬프트로 소통하며 이른바 ‘바이브 코딩(Vibe Coding)’에 심취해 플루터(Flutter) 기반의 하이브리드앱을 만들어보기도 하고, 쏟아지는 글로벌 빅테크의 API들을 조합해 새로운 UX를 얹은 나만의 AI 사이트들을 테스트하는 것이 일상이었다.
당시 나는 사내에서 압도적인 격차로 'AI 툴 토큰 사용량 1위'를 기록하던 열성적인 유저였다. 최신 기술을 가장 먼저 뜯어보고 코드로 세상과 직관적으로 소통하며 개인의 커리어와 역량에 날을 세우는 것. 그것이 내가 생각하던 IT 전문가의 삶이자 가장 확실한 성장의 방식이었다.
하지만 사내에 최초로 AI 관련 팀이 신설되고 팀장이라는 직책을 맡게 되면서, 나의 일상은 완전히 다른 궤도로 진입했다. 개인의 토큰 사용량은 급격히 줄어들었고, CLI나 IDE를 띄워놓고 몰입하는 날보다 타 부서와 회의를 하고 정책 문서를 다듬는 시간이 압도적으로 많아졌다.
기술의 최전선에서 직접 프로그램하는 것을 즐기던 실무자가, 왜 갑자기 코딩 창을 닫고 전사의 프로세스를 설계하는 일에 몰두하게 되었을까?
1. 융합의 교차로
AI 앞에서는 기존의 경계가 무너진다
사람들은 흔히 신설된 'AI 전담 팀'이라고 하면, 최신 GPU 서버를 세팅하고 고도화된 모델을 튜닝하는 기술 중심의 조직을 상상한다. 하지만 엔터프라이즈 환경에서 AI 조직이 마주하는 현실은 기술 그 너머에 있다. 'AI'라는 단어가 비즈니스에 붙는 순간, 기존에 명확히 나뉘어 있던 부서 간의 R&R에 대한 경계가 급격히 허물어지며 거대한 융합의 장이 열리기 때문이다.
예를 들어 '전사 AI 활용 사규 및 윤리 지침'을 제정하는 일은 본래 전략이나 기획 부서의 고유 영역이다. 보안 정책은 정보보안팀의 몫이고, 임직원 교육은 HR이나 인재개발원의 주된 업무다.
하지만 생성형 AI는 기존의 방식대로 다루기엔 너무나 이질적인 기술이다. 프롬프트 작성 시의 데이터 입력 범위, RAG(검색 증강 생성) 환경에서의 데이터 인덱싱에 따른 보안 취약점, 환각(Hallucination) 현상에 대한 면책 조항 등은 기술적 메커니즘을 깊이 이해하지 못하면 실효성 있는 룰을 만들 수 없다.
따라서 AI라는 전례 없는 패러다임 앞에서는 전통적인 부서별 매뉴얼만으로는 완벽한 밑그림을 그리기 어려웠다. 그렇기에 기술의 최전선에 있는 AI 팀이 선제적으로 나서서 기획, 보안, HR 부서와 긴밀하게 협력하며 새로운 '표준'을 밑바닥부터 함께 설계해야만 했다.
화려한 AI 모델링 이면에는, 이렇듯 전사의 제도를 다듬고 보안 룰을 세팅하며 교육 커리큘럼까지 챙겨야 하는 보이지 않는 기반 공사가 필수적으로 동반된다.
2. 선도 조직의 무게
밀려드는 회의와 문서 작업 앞에서 가끔은 "기술 개발에만 집중하고, 정책이나 보안은 유관 부서의 판단에 온전히 맡기자"라고 타협하고 싶은 순간도 있었다. 하지만 우리 회사의 위치가 그것을 허락하지 않았다. 우리 회사는 단순히 외부의 가이드라인을 적당히 가져와 적용할 수 있는 조직이 아니다. 우리는 거대한 전 그룹사 내에서 언제나 가장 먼저 기술을 테스트하고 레퍼런스를 만들어내야 하는 모범의 위치에 있다. 여기서 체감하는 책임의 무게는 남다르다.
만약 우리 AI 팀이 리소스를 핑계로 AI 보안 정책이나 전사 지침 수립 과정에서 기술적 개입을 느슨하게 하거나 대충 타협해 버린다면? 그것은 단지 우리 부서만의 리스크로 끝나지 않는다. 우리가 세운 헐거운 기준 하나, 미처 파악하지 못한 보안 취약점 하나가 그대로 전 계열사와 그룹사 전체의 'AI 표준'으로 굳어져 확산될 수 있다.
우리가 제안하는 원칙과 데이터 통제 규칙이 곧 거대 그룹 전체가 참고할 척도가 된다는 사실. 이 파급력을 인지하고 나면, 기술 외적인 융합 영역이라고 해서 결코 소홀히 넘길 수가 없었다.
3. 관점의 이동
프로그래머에서 아키텍트로
이 과정에서 나는 내가 쥐고 있던 가장 익숙한 무기, 즉 '직접 코딩하고 개발하는 실무자'로서의 관점을 의식적으로 확장해야 했다.
팀장으로서 내가 내는 성과는 과거와 질적으로 달라졌다. 실무자 시절에는 쏟아지는 새로운 API를 얼마나 빠르게 익히고 데이터를 표준화하여 얼마나 효율적인 좋은 코드를 짜느냐가 성장의 척도였다면, 지금은 하루가 다르게 변하는 기술의 흐름 속에서 '도입할 가치가 있는 기술'과 '거품인 기술'을 냉정하게 판별하는 안목이 훨씬 중요해졌다. 무엇보다 각기 다른 강점과 전문성을 가진 팀원들을 파악하고, 그들에게 가장 잘 맞는 업무와 무대를 세팅해 주는 '조율자(Orchestrator)'로서의 역할에 집중해야 했다.
개인의 지적 호기심과 기술적 성취에 집중하는 프로그래머의 뇌 근육과, 조직 전체의 방향성을 읽고 구조를 설계하는 관리자의 뇌 근육은 사용하는 방식 자체가 다르다. 통제 가능한 프로그래밍 코드 대신, 예측 불가능한 비즈니스의 요구사항을 조율하고 시스템과 제도를 엮어내는 일. 그것이 기술 중심의 조직을 이끄는 리더십의 본질임을 현장에서 뼈저리게 체감하고 있다.
4. "다 네 성격 탓이야"
피곤하지만 타협할 수 없는 꼼꼼함
산더미 같은 보고서 초안을 리뷰하고 타 부서와의 AI 회의를 준비하는 나를 보며, 동료들은 종종 웃으며 농담을 던진다.
"솔직히 말해봐. 네가 하나부터 열까지 다 챙기려다 보니 일이 끝이 없는 거잖아. 그렇게 피곤하게 일하는 거, 다 네 꼼꼼한 성격 탓도 있어."
부정하지 않는다. 사실 어느 정도는 맞는 말이다. 나는 매사를 지독하게 계획적으로 접근하고, 구조의 밑바닥이 단단하게 다져지지 않으면 다음 스텝으로 넘어가는 것을 극도로 경계하는 편이다. 하지만 역설적으로 이 깐깐한 성향이, 폭발적인 속도로 질주하는 AI 시대에 기업을 이끄는 데 필요한 '최소한의 방어기제'라고 굳게 믿는다.
속도만을 강조하며 규정과 보안의 나사를 헐겁게 조인 수많은 프로젝트들이 결국 무분별한 섀도우 IT의 난립이나 파편화된 기술 부채로 이어지는 것을 보아왔다. 전략, 보안, 시스템, 그리고 변화관리라는 4개의 톱니바퀴가 하나의 일관된 거버넌스 아래 치밀하게 맞물려 돌아가지 않으면, 기업은 AI라는 거대한 파도 위에서 표류하게 된다. 누군가는 전체를 관망하며 이 기반 요소들을 정렬시키는 피곤함을 감수해야만 한다.
5. 무대 뒤에서 조직의 운영 체제를 코딩하다
과거의 나를 아는 사람들은 회의실과 문서 작업에 파묻혀 있는 내 모습을 보며 개발자로서의 즐거움을 잃었다고 아쉬워할지도 모른다. 확실히 나만의 앱을 만들며 느끼던 즉각적인 성취감이나 토큰 사용량 1위의 타이틀은 이제 과거의 일이 되었다.
하지만 나는 단 한 번도 내가 '개발'을 멈췄다고 생각하지 않는다. 과거의 내가 컴퓨터의 언어를 타이핑해 모바일 앱 하나를 만들었다면, 지금의 나는 '전사 사규와 지침'이라는 코드로 조직의 행동 양식을 설계하고, '보안 정책'이라는 방화벽을 세우며, '변화관리 교육'이라는 인터페이스를 통해 수많은 임직원이 움직이는 거대한 시스템 그 자체를 프로그래밍하고 있을 뿐이다.
개인적인 코딩의 즐거움은 이제 새로운 기술을 무기로 필드를 뛸 현업 직원들에게 기꺼이 넘겨주었다. 대신 나는 우리 회사가, 나아가 우리 그룹사 전체가 아무런 두려움 없이 마음껏 혁신할 수 있는 '가장 단단하고 안전한 인프라'를 설계하는 일에 몰두하고 있다.
개인의 코드 생산성을 넘어 조직 전체의 운영 체제(OS)를 고민하는 것. 눈에 띄지 않는 곳에서 조직의 뼈대를 묵묵히 다지는 이 과정이야말로, 폭풍 같은 AI 시대를 맞이한 기업 환경에서 한 명의 리더가 수행할 수 있는 진짜 '엔터프라이즈 프로그래밍'일 것이다.