엔지니어링 AX는 AI 도입이 아니라 업무 방식의 재설계다

건설·엔지니어링 업계에 AX(AI Transformation)라는 말이 빠르게 번지고 있다. 현대건설은 사내 전용 AI 비서를 도입한 지 두 달 만에 임직원 약 3,000명이 12만 건 넘는 업무에 활용했다고 밝혔고, GS건설은 ChatGPT 엔터프라이즈를 전사 도입한 뒤 사내 AI 경진대회까지 상시화했다. GS건설의 AI 하자 예방 플랫폼은 국토부 하자심사분쟁조정위원회 조사에서 하자 판정 0건이라는 성적표를 받았다. 국토부는 전북에 'AI 건설·로봇 혁신센터'를 세우며 건설 AX를 국가 어젠다로 끌어올렸다.

숫자만 보면 전환은 이미 끝난 것처럼 보인다. 그런데 현장에서 체감하는 속도는 다르다. 대형사 몇 곳을 제외하면 업계 전반의 AI 활용은 여전히 초기 단계라는 진단이 나오고, 실무자 설문에서는 "AI가 본격 활성화되는 시점은 2030년 이후"라는 전망이 다수다. 시공사 R&D 투자 비중이 1%를 겨우 넘는 산업 구조에서, 설계·엔지니어링 회사의 사정은 더 말할 것도 없다.

왜 이런 간극이 생기는가. 나는 엔지니어링 조직 안에서 AI 전환 실무를 직접 굴려보면서, 이 간극의 원인이 기술이 아니라는 결론에 도달했다. 엔지니어링 AX가 더딘 이유는 AI가 부족해서가 아니라, AI가 일할 수 있는 업무 환경이 없어서다.

1. DX는 시스템을 바꿨지만, AX는 판단을 건드린다

많은 조직이 AX를 DX의 연장선으로 이해한다. 전자결재를 깔고 도면을 PDF로 바꾸던 그 흐름의 다음 단계쯤으로. 그러나 둘은 성격이 다르다.

DX는 정보가 흐르는 경로를 바꾸는 일이었다. 종이가 파일이 되고, 결재판이 시스템이 됐다. 업무의 본질, 즉 "누가 무엇을 판단하는가"는 건드리지 않았다.

AX는 판단 그 자체에 개입한다. 설계 검토, 규격 적합성 확인, 견적 산출, 설계 변경 영향 분석. 전부 시니어 엔지니어의 경험값이 깊게 들어간 영역이다. 여기에 AI를 붙인다는 것은 "이 판단의 어느 부분을, 어떤 조건에서, 누구의 책임 하에 기계에 위임할 것인가"라는 질문에 답하는 일이다. 챗봇 하나 깔아준다고 답이 나오는 질문이 아니다.

제조업의 AX가 상대적으로 빨랐던 이유가 여기에 있다. 제조는 공정이 표준화돼 있고 데이터가 센서에서 자동으로 쌓인다. 엔지니어링은 프로젝트마다 발주처가 다르고, 조건이 다르고, 산출물 형식이 다르다. 같은 회사 안에서도 팀마다, 심지어 사람마다 도면 레이어 체계와 보고서 목차가 다르다. AI 이전에 일하는 방식 자체가 표준화되어 있지 않다.

2. "자동 설계"는 멀고, "자동 검토"는 가깝다

AX 논의에서 가장 흔한 착각은 AI가 설계를 대신할 것이라는 상상이다. 현실의 순서는 반대다. AI의 첫 일자리는 창조자가 아니라 검토자다.

이유는 책임 구조에 있다. 설계는 인허가와 법적 책임이 걸린 최종 산출물이다. AI가 그린 도면에 도장을 찍을 기술사는 없다. 반면 검토는 다르다. 도면 오류 탐지, 상위계획 정합성 확인, 법정 기준 누락 체크, 계산서 검산, 설계 변경의 파급 범위 추적. 이 영역에서 AI가 틀려도 최악의 결과는 "사람이 한 번 더 본다"이고, AI가 맞으면 사람이 놓칠 뻔한 오류 하나가 잡힌다. 비대칭적으로 유리한 게임이다.

실제로 성과가 나오는 지점도 여기다. 배관 용접부 비파괴 검사의 AI 판독, 외벽 균열 점검 로봇, 하자 예방 플랫폼. 전부 "만드는 AI"가 아니라 "잡아내는 AI"다. 설계 엔지니어링으로 넘어와도 마찬가지다. 내가 실무에서 검증해 본 원칙은 단순하다. AI는 제안하고, 판단은 사람이 하며, 확정은 검증 가능한 절차를 거친다. AI 산출물에는 반드시 "확인 필요" 표식이 붙고, 사람이 승인하기 전까지는 공식 산출물이 아니다. 이 구조를 포기하는 순간 AX는 리스크 폭탄이 된다.

3. 병목은 GPU가 아니라 데이터 소유권과 파일 서버다

"우리 회사엔 30년치 프로젝트 데이터가 있다"는 말은 절반만 사실이다. 파일은 많다. 그러나 학습 가능하고 검색 가능한 데이터는 놀랄 만큼 적다.

엔지니어링 프로젝트 데이터는 발주처, 설계사, 시공사, 협력사에 흩어져 있고, 저작권과 보안 조건이 계약마다 다르다. "이 과업의 성과품을 사내 지식베이스에 넣어도 되는가"라는 질문에 즉답할 수 있는 조직은 거의 없다. AI 도입 이전에 계약서와 보안 정책부터 손봐야 하는 이유다.

사내 데이터 사정도 다르지 않다. 최종본_진짜최종_수정2.hwp가 굴러다니는 파일 서버, 담당자 PC에만 있는 계산 시트, 퇴직자와 함께 사라진 프로젝트 히스토리. RAG니 벡터 검색이니 하는 기술은 그다음 문제다. 문서명 규칙, 폴더 체계, 산출물 템플릿, 버전 관리. 이 지루한 것들이 정리되지 않은 조직에서 AI는 쓰레기 더미 위의 검색엔진일 뿐이다. AX 성패의 8할은 표준화이고, 표준화는 기술 프로젝트가 아니라 총무·품질·계약 부서까지 걸린 조직 프로젝트다.

4. 진짜 자산은 시니어의 머릿속에 있다 — 그리고 지금 은퇴 중이다

업계가 인력 고령화와 숙련 인력 이탈을 구조적 위기로 꼽은 지 오래다. 엔지니어링 회사의 경쟁력은 장비도 소프트웨어도 아닌 시니어의 판단력인데, 그 판단은 대부분 문서화돼 있지 않다. "이 지역 발주처는 이런 걸 싫어한다", "이 조건이면 심의에서 반드시 걸린다" 같은 지식은 회식 자리와 어깨너머로만 전수돼 왔다.

AX는 이 암묵지를 조직 자산으로 바꿀 수 있는 사실상 마지막 기회다. 방법론 자체는 거창하지 않다. 검토 의견서를 구조화해서 쌓고, 프로젝트별 이슈와 해결 과정을 로그로 남기고, 그것을 검색 가능한 지식베이스로 연결하는 것. 다만 여기서 반드시 마주치는 벽이 있다. "내 노하우를 왜 시스템에 넣어야 하는가"라는 저항이다.

이건 감정 문제가 아니라 보상 설계 문제다. 개인의 경험이 조직 자산이 되는 순간 그 개인의 협상력은 떨어진다. 지식 기여를 평가와 보상에 반영하는 장치 없이 "협조 부탁드립니다"만 반복하는 조직의 지식베이스는 반드시 빈 껍데기가 된다. 사내 지식관리 프로젝트가 그토록 자주 실패해 온 이유가 기술이 아니었다는 점을, AX 시대에도 똑같이 반복할 가능성이 크다.

5. PoC는 성공하는데 왜 아무도 안 쓰는가

지난 1~2년간 업계에 AI PoC가 넘쳤다. 데모는 대부분 성공한다. 그리고 대부분 거기서 멈춘다.

이유는 간단하다. 데모가 증명하는 것과 현장이 요구하는 것이 다르기 때문이다. 데모는 "된다"를 보여주면 끝나지만, 현장은 "매번 되는가", "틀리면 누가 책임지는가", "기존 결재 라인 어디에 끼워 넣는가", "보안 심사는 통과하는가"를 묻는다. 경영진에게 보여주는 AI와 실무자가 매일 쓰는 AI 사이에는 이 네 가지 질문만큼의 거리가 있다.

그래서 PoC의 성공 기준을 바꿔야 한다. "정확도 90%"가 아니라 "실무자 N명이 자기 업무에서 주 몇 회 이상 자발적으로 사용하는가"가 기준이 되어야 한다. 전자는 데모의 지표이고, 후자가 전환의 지표다.

6. 그래서, 어디서부터 시작해야 하나

거창한 AI 플랫폼 구축부터 시작하는 조직은 높은 확률로 실패한다. 현실적인 로드맵은 반대 방향이다.

첫째, 검토·검색·정리부터. 문서 검색, 규격 비교, 회의록 정리, 보고서 초안, 설계 변경 추적처럼 3개월 안에 실무자가 체감할 수 있는 과제로 시작한다. 작은 성공이 없으면 현업의 신뢰도 예산도 따라오지 않는다.

둘째, 표준화를 AI 도입의 조건이 아니라 결과물로. "표준화가 끝나면 AI를 도입하자"는 영원히 시작하지 못한다. 특정 업무 하나를 AI 워크플로우에 태우는 과정에서 그 업무의 템플릿과 규칙을 함께 정리하는 방식이 현실적이다. AI가 표준화의 강제 장치가 되는 셈이다.

셋째, 책임 구조를 먼저 그린다. AI 산출물의 검증 절차, 승인 권한, 감사 로그를 워크플로우에 처음부터 박아 넣는다. 이게 없으면 잘 되던 파일럿도 첫 사고 한 번에 전사가 AI 알레르기에 걸린다.

넷째, 역량 기준을 다시 쓴다. AI가 계산과 초안을 맡기 시작하면 엔지니어의 승부처는 문제 정의와 검증으로 이동한다. 정답을 빨리 내는 엔지니어보다 AI의 답을 의심하고 조건을 따지는 엔지니어가 귀해진다. 프롬프트 작성법 교육보다 "AI 결과물을 어떻게 검증할 것인가"에 대한 훈련이 먼저다.

맺으며

대형사와 나머지의 기술 격차는 이미 벌어지기 시작했다. 하지만 이 격차의 본질은 GPU 예산이나 전담 조직 규모가 아니다. AI가 일할 수 있도록 데이터를 정리하고, 절차를 표준화하고, 책임 구조를 설계한 조직과 그렇지 않은 조직의 격차다. 그리고 이 작업은 돈보다 의지와 시간이 드는 일이라서, 중견 엔지니어링사에게도 아직 기회가 닫히지 않았다.

엔지니어링 AX의 승부는 "AI를 얼마나 빨리 샀는가"가 아니라 "AI가 일할 수 있는 업무 환경을 만들었는가"에서 갈린다. 결국 AX는 기술 프로젝트이기 전에, 엔지니어링 조직이 30년간 미뤄온 일하는 방식의 재설계다. AI는 그 재설계를 더 이상 미룰 수 없게 만든 계기일 뿐이다.