「AI 주도 개발을 시작합시다!」라는 말을 들은 현장 엔지니어가 가장 먼저 직면한 현실은, AI 이야기가 아니었다

작년쯤부터 「AI 활용으로 생산성 2배!」 「AI로 내재화 추진!」이라는 구호가 각 기업에서 난무하고 있다.

우리 현장에도 왔다.

처음에는 순수하게 기대하고 있었다.

하고 싶었던 것:
- 코드를 작성하면 자동으로 보완·제안해줌
- 테스트 코드(Test Code)를 AI가 생성하게 함
...

모두 꿈같은 이야기는 아니다. 실제로 그런 사례는 있다.

하지만, 막상 자신의 현장에서 움직이려 했을 때, AI 이전에 정리해야 할 것들이 산더미였다는 이야기를 하려 한다.

「공식 사례」에서 자주 보이는 「AI로 개발이 극적으로 개선되었습니다!」 같은 이야기가 아니다.

더 엉망진창이고, 더 리얼한 이야기다.

AI를 도입하려고 가장 먼저 확인한 것이 「현상태의 개발 환경」이었다.

거기서 밝혀진 것이 이것.

변경 관리: 없음
브랜치(Branch) 운용: 없음
리뷰(Review) 문화: 없음
...

폴더명이 버전 관리(Version Control)가 되어 있었다.

src_20240301/
src_20240301_최종/
src_20240301_최종_수정판/
...

'너도냐' 하는 표정을 지었다.

AI는 Git과 매우 궁합이 좋다. PR(Pull Request)・Issue・Commit・ADR・README 등 모든 것이 「문맥이 있는 구조화된 텍스트(Structured Text)」로서 기능한다.

하지만 Git이 없는 현장에 AI를 넣어도, 문맥 없는 파편을 계속 먹이게 될 뿐이다.

결론: AI 도입 전에 Git 도입을 하기로 했다.

AI에게 설계서를 건네면 그것을 바탕으로 코드를 생성하거나, 사양(Specification) 질문에 답해준다. 이론적으로는 그렇다.

하지만 그 설계서를 열었을 때, 말을 잃었다.

• 셀 병합이 종횡무진으로 실행된 Excel
• SmartArt로 그려진 시스템 구성도
• Word에 붙여넣어진 스크린샷 플로우 차트(Flowchart)
• 「최신판(구버전)」이라는 파일명의 PDF

AI는 똑똑하지만, Excel의 SmartArt나 붙여넣은 이미지의 「도형」을 인간처럼 읽지 못한다.

인간: 「이 화살표의 의미는... 음, 전후 문맥과 담당자에게 물어보면 알 수 있어」
AI: 「......」

텍스트로서 읽을 수 없는 것은 AI에게 그저 노이즈(Noise)일 뿐이다.

더욱 문제였던 것은 이것.

사양이 구두로 존재하고 있었다.

「그건 A 씨에게 물어보면 알아」 「이 부분은 예전 경위가 있어서...」 같은 개인의 지식(Tacit Knowledge)이 어디에도 문서화되어 있지 않다.

AI에게 먹이기는커녕, 인간조차 정보를 찾기가 어려운 상태였다.

사내 정보가 어디에 있는지 조사했더니 다음과 같았다.

장소	내용
SharePoint	3년 전 설계서 (최신인지 불명)
...

이것은 AI 이전에, 인간조차 정보 수집이 곤란한 상태다.

RAG(Retrieval-Augmented Generation)를 구축하여 「사내 지식을 AI에게 먹이자」는 구상이 있었지만, 먹이기 전에 정보의 재고 조사(Inventory)가 필요했다.

오래된 사양, 잘못된 사양, 권한상 문제가 되는 정보, 개인정보…… 그것들을 정리하지 않고 RAG에 투입하면, AI가 자신만만하게 오래된 사양이나 잘못된 정보를 답변하는 최악의 케이스가 된다.

AI 도입 노력을 횡단적으로 보면 크게 3가지 패턴으로 나뉘어 있었다.

1. 폐쇄형 (금융·관공서·인프라 계열에 많음)

• 외부 AI 원칙적 금지
• Azure OpenAI만 한정 허가
• 설계서 반입에 엄격한 심사

이것 자체는 이유가 있다. 감사 대응·정보 유출 리스크 저감 등 정당한 이유다.

하지만 부작용으로:
「인간이 복사·붙여넣기 담당자가 되는」 현상이 발생한다.

AI와 연결되지 않은 환경에서 일하는 개발자가 수동으로 프롬프트(Prompt)를 구성하고, 수동으로 복사·붙여넣기하고, 수동으로 확인한다.

생산성 향상은커녕, 새로운 형태의 작업이 늘어났을 뿐이라는 현장도 있었다.

2. 통합형 (GitHub Enterprise + Copilot Enterprise + Azure OpenAI + 사내 RAG를 정비한 폐쇄 환경을 구축하는 패턴)

생각하는 방식이 바뀌어 있는 점이 여기다.

「개발 환경에 설계서를 두어도 되는가」가 아니라

「AI 이용 기반으로서 어떻게 통제할 것인가」라는 발상으로의 전환

이것이 진행되고 있는 기업은 명확하게 AI 활용의 성숙도가 다르다.

3. 방치형 (현장 개발자가 개인 판단으로 사용)

• 개인 계약한 ChatGPT
• 무료 AI 서비스
• VSCode의 수상한 확장 기능(Extension)
• 로컬 LLM(Large Language Model)

을 사용하고 있는 상태. 이른바 **섀도 AI (Shadow AI)**다.

그리고 AI 금지를 강화하면 할수록, 섀도 AI가 늘어나는 역설적인 현상이 일어나고 있었다.

금지되어 있으니까 보고하지 않는다 → 회사는 실태를 파악할 수 없다 → 리스크가 가시화되지 않는다 → 규칙이 더욱 강화된다 → ……

이 악순환(Negative Loop)을 누군가는 끊어내야 한다.

Word나 Excel을 직접 AI에게 전달하는 것이 아니라, 한번 Markdown으로 변환한 중간 파일을 만드는 운용 방식을 시작했다.

Word 설계서 → Markdown (수동 또는 변환 스크립트)
Excel 사양서 → CSV / YAML
PowerPoint 구성도 → 텍스트 요약 + Mermaid 도표

수고는 따른다. 하지만 이를 통해 다음과 같은 부수적인 효과가 있었다.

• AI가 설계서를 정확하게 읽을 수 있게 되었다
• Git으로 차이(Diff) 관리를 할 수 있게 되었다
• 리뷰가 텍스트 기반으로 이루어지게 되었다

"도표는 Mermaid로 작성한다"라는 규칙을 도입했다.

장점은 많다.

• Git으로 차이 비교가 가능하다
• AI가 "도표의 의미"를 이해할 수 있다
• AI가 자동 생성 및 수정할 수 있다
• 리뷰를 코드 리뷰와 같은 감각으로 할 수 있다

이미지나 SmartArt로 그려진 도표는 변경이 있을 때마다 전체를 다시 작성해야 했다. Mermaid라면 한 줄만 바꾸면 끝난다.

여기에는 은근히 큰 패러다임 시프트 (Paradigm Shift)가 있다.

AI에게 이미지 도표는 그저 "보는" 대상일 뿐이다.

하지만 Mermaid는 "이해·생성·수정"할 수 있는 대상이 된다.

"도표를 이미지로 보유하는 것"에서 "도표를 텍스트로 보유하는 것"으로의 전환.

이는 단순한 표기법의 문제가 아니라, 문서(Document)를 AI와 공동 편집할 수 있는 자산으로 만드느냐 아니냐의 분기점이다.

"규칙이 정비될 때까지 AI 사용 금지"가 아니라, 최소한의 가이드라인을 먼저 만들고 실행하면서 개선하는 방식을 취했다.

첫 번째 가이드라인은 이것뿐이었다.

1. 고객 정보·개인 정보 입력 금지
2. 인증 정보(비밀번호·API Key) 입력 금지
3. AI 생성 코드는 반드시 인간이 리뷰
...

이것만으로도 "사용해도 되는지/안 되는지"의 기준이 생겼고, 섀도 AI (Shadow AI) 보고가 늘어났다.

AI 주도 개발 (AI-Driven Development)을 진행하며 얻은 가장 큰 깨달음은 이것이다.

AI 도입은 "개발 프로세스 정상화 프로젝트"였다.

AI에게 전달할 수 있는 형태로 정보를 정리한다 → 문서가 구조화된다

Git으로 관리한다 → 변경 이력이 가시화된다

리뷰 문화가 생긴다 → 개인의 종속성(Silo)이 해소된다

AI를 도입하려 했을 뿐인데, 오랫동안 방치되었던 부채를 단번에 해소하는 압력이 생겨났다.

"AI가 모든 코드를 작성한다"는 꿈을 꾸었지만, 실제 첫걸음은 이랬다.

꿈	현실의 첫걸음
AI가 설계서를 읽고 전체 구현	설계서를 Markdown화하기
...

"개발자를 없애는 것"이 아니라, **"개발자의 마찰을 줄이는 것"**이 현실적인 첫걸음이었다.

AI 주도 개발을 진행하던 중, 팀 내에서 화제가 된 적이 있다.

"AI를 쓸 줄 아는 사람"보다 "AI에게 전달할 수 있는 형태로 정보를 정리할 수 있는 사람"이 사실은 더 희귀할지도 모른다.

• 사양을 Markdown으로 구조화할 수 있다
• 도표를 Mermaid로 표현할 수 있다
• 문서를 기계 판독 가능한 (Machine-readable) 형태로 관리할 수 있다
• 정보의 "분류", "권한", "신선도"를 정리할 수 있다

이것들은 전부 업무 이해도·구조화 능력·표준화 능력이다. 프롬프트 엔지니어링 (Prompt Engineering)보다 먼저 요구되는 능력일지도 모른다.

AI 도입 이야기를 하고 있었을 뿐인데, 조직의 정보 문화를 근본적으로 재검토하게 되었다.

하지만 그것으로 잘되었다고 생각한다.

AI는 만능이 아니었다.

다만, 오랫동안 "언젠가 하겠지"라며 미뤄왔던 문제들을, "AI를 도입하기 위해 지금 반드시 해결해야 하는 문제"로 바꾸는 압력으로서는 매우 강력했다.

Git 미도입·문서 혼돈·정보 분산——이것들은 어제오늘의 문제가 아니다. 하지만 "AI를 도입하고 싶다"라는 탑다운 (Top-down) 식의 명령이, 현장의 "어차피 말해도 변하지 않는다"라는 체념을 마침내 움직였다.

AI 도입에 난항을 겪고 있는 당신의 현장도 아마 마찬가지일 것이다.

• Mermaid: 텍스트로 시퀀스 다이어그램·플로우 차트를 작성
• GitHub Copilot: 코드 완성·테스트 생성
• ADR (Architecture Decision Records): 설계 판단을 Git으로 관리
• OpenAPI: API 사양을 텍스트로 관리

이 글이 "우리 현장도 저런데……"라고 생각하는 분들에게 작은 용기가 되었기를 바랍니다.

#AI #AI주도개발 #GitHubCopilot #문서 #엔지니어 #현장이야기 #Mermaid #Qiita