이것으로 불을 껐다!! AI 개발 도구의 '유행'에 휘둘리지 않는 Gemini 활용술【팀 운영·최신판】

지난 기사에서는 Cursor나 Windsurf와 같은 유행하는 AI 에디터에 의존하지 않고, 자체 제작한 「파일 문자열 결합 도구」를 사용하여 Gemini의 능력을 최대한으로 끌어내는 수법을 소개해 드렸습니다.

이번에는 그 「최신판·팀 운영편」입니다.

"99% 불타오른다(炎上)"라고 불린 가혹한 프로젝트를 잔업 제로에 가까운 상태로 헤쳐 나갈 수 있었던 최대 요인은, 프로젝트 멤버 전원이 「단시간에, 균일한 정밀도로」 AI를 사용할 수 있는 구조를 구축한 것에 있습니다.

특정 도구에 얽매이지 않고, 회사에서 주어진 Gemini를 궁리하여 이용하며 어떻게 개인의 역량에 의존하는 현상(属人化)을 배제했는지. 그 아키텍처(Architecture)와 운용 절차를 공개합니다.

이 장에서는 AI를 팀에 도입했을 때 반드시 부딪히는 「전제 지식의 공유」라는 벽에 대해 해설합니다.

AI의 파일 읽기 상한이나, 멤버별로 「AI에 전달하는 정보의 편차」가 팀 개발에서의 최대 병목 현상(Bottleneck)이 됩니다.

버그 조사나 기능 추가를 수행할 때, Gemini에는 「파일 전송 수 상한」이나 「컨텍스트 윈도우(Context Window, 한 번에 처리할 수 있는 텍스트 양)」의 제한이 있습니다.

더욱 심각한 것은, 「어떤 소스 코드를 AI에게 읽혀야 하는가」라는 판단이 개인의 역량에 의존(属人化)하게 되는 것입니다. 숙련자는 적절하게 필요한 파일을 AI에게 전달할 수 있지만, 경험이 적은 멤버는 관계없는 파일을 전달하여 AI가 혼란을 느끼고 잘못된 답변을 출력하는 케이스가 다발하고 있었습니다.

AI에게 전달할 소스 코드의 「선정」과 「결합」을 자동화·템플릿화하는 것입니다.

지난번에 작성한 「파일 결합 도구」를 응용하여, 프로젝트의 「설정 파일(전제)」과 「기능별 소스 코드」를 미리 정의하여 결합할 수 있는 구조를 구축했습니다.

왜 우리는 「고기능 AI 에디터의 도입」이 아니라, 「소스 코드를 텍스트로 결합하여 Gemini에 전달하는」 투박한 설계(Architecture)를 선택했을까요?

// 【에비던스】 프로젝트 내에서 공유되는 결합 도구의 설정 파일 예시 (발주 기능)
{
"project_context": [
...

이 설계를 선택한 이유는 「환경에 대한 비의존성」과 「전제의 완전 통제」입니다.

유행하는 AI 에디터는 각 개인의 로컬 환경이나 라이선스에 의존하지만, 텍스트 기반의 결합이라면 .NET이든 레거시 시스템(Legacy System)이든 환경을 가리지 않습니다. 게다가 위와 같은 설정 파일을 Git으로 관리함으로써, 「발주 처리에는 이 파일군이 필요하다」는 프로젝트의 정답을 팀 전체가 강제적으로 공유할 수 있습니다.

AI도 인간과 같습니다. 새로운 팀 멤버에게 「이 발주 기능의 버그를 고쳐줘」라고 부탁할 때, 관련 설계서나 소스 코드 일체를 파일로 묶어서 전달하죠?

AI에게도 마찬가지로 「필요한 자료만을 깔끔하게 정리한 바인더」를 전달해 줄 필요가 있습니다. 이 장의 구조는 그 바인더 만들기를 완전 자동화하는 것입니다.

이 장에서는 팀 전원이 망설임 없이 AI에게 필요한 정보를 전달할 수 있도록 구축한, 구체적인 디렉토리 아키텍처(Directory Architecture)를 해설합니다.

「공통 폴더」와 「기능별 폴더」를 나누어 Git으로 관리함으로써, 누구라도 원클릭으로 AI용 완벽한 인수인계 자료(결합 파일)를 생성할 수 있습니다.

시스템의 기능 개수를 수행할 때, 대상이 되는 기능의 소스 코드만 AI에게 전달해도 「데이터베이스의 접속 설정은 어떻게 되어 있는가?」, 「공통 함수의 사양은?」과 같은 시스템 전체의 전제가 결여되어 있으면 AI는 정확한 코드를 제안할 수 없습니다. 그렇다고 매번 수작업으로 공통 파일을 모으는 것은 매우 비효율적입니다.

결합 도구의 설정 파일과 출력처를 미리 「기능별 폴더」로 나누어 Git 리포지토리(Repository)로 관리하는 아키텍처를 채택했습니다.

우리는 다음과 같은 디렉토리 구조를 설계하여 Git으로 팀에 공유했습니다.

📁 AI_Context_Builder/ (Git 관리)
├── 📁 공통 폴더/
│ ├── build_context.py (결합 도구 실행 스크립트)
...

이 설계의 핵심은 「AI 전제 지식의 버전 관리」입니다.

예를 들어, 「발주 처리 기능에 버그가 있어서 원인을 특정해 주길 바란다」는 태스크(Task)가 발생했다고 가정해 봅시다. 담당자는 「발주 폴더」 안에 있는 스크립트를 실행하는 것만으로, 현시점의 최신 발주 관련 소스와 필수적인 공통 기반 소스(.csproj나 appsettings 등)가 모두 하나의 텍스트로 결합되어 출력됩니다.

이것을 Gemini에 복사해서 붙여넣기만 하면, AI는 프로젝트의 전체상을 완벽하게 파악한 상태에서 디버깅을 시작할 수 있습니다. 누가 실행하더라도 동일한 파일군이 AI에게 전달되기 때문에, 답변의 정밀도가 균일화됩니다.

요리 레시피 세트를 상상해 보세요.

'공통 폴더'는 소금이나 간장 같은 '기본 양념 세트'입니다. '발주 폴더'는 그날의 '메인 식재료(고기나 채소)'입니다.

요리사(AI)에게 메인 식재료만 전달하면 간을 맞출 수 없습니다. 항상 '기본 양념'과 '메인 식재료'를 세트로 묶어서 전달하는 구조를 만듦으로써, AI는 언제든 최고의 퍼포먼스를 발휘할 수 있게 됩니다.

마지막으로, 이 구조를 어떻게 팀의 일상 업무에 적용하고 정착시켰는지에 대해 해설하겠습니다.

'처음 한 번만 설정하고, 나머지는 실행하기만 하면 된다'는 극한까지 심플한 운용 방식을 채택함으로써, 귀찮음이 많은 멤버라도 자연스럽게 AI를 능숙하게 다룰 수 있게 됩니다.

아무리 뛰어난 구조를 만들어도 운용 절차가 복잡하면 현장의 엔지니어는 사용하지 않습니다. 특히 압박감이 심한 불타는 프로젝트(炎上プロジェクト)에서는 '새로운 툴을 익힐 시간조차 아깝다'며 기피하기 일쑤입니다.

나무늘보 전략(철저하게 하지 않을 것을 결정함)에 기반하여, '일일 작업에서는 스크립트를 더블 클릭하기만 하면 된다'는 운용 플로우를 확립했습니다. 설정 작업은 기능 개발의 '처음 한 번'으로만 한정합니다.

실제 개발 현장에서의 운용 절차(아키텍처의 라이프사이클)는 다음과 같습니다.

신기능(예: 재고 관리) 개발이 시작되면

'공통 폴더'를 복사하여 '재고 폴더'를 생성합니다. -
초기 설정 (이 부분만 수작업)

생성한 '재고 폴더' 내의 설정 파일에 재고 기능과 관련된 파일 경로를 한 번만 등록하고 Git에 커밋합니다. -
일일 운용 (버그 조사·기능 추가)

개발 중이거나 버그 발생 시에는 해당 폴더의 Python 스크립트를 실행하기만 하면 됩니다.

# 【에비던스】 build_context.py의 간략화된 로직
import json, os
def build_ai_context():
...

이러한 운용 설계를 선택한 이유는 '인지 부하의 최소화'입니다.

버그가 발생하여 초조해하고 있을 때, '어떤 파일을 AI에게 읽혀야 하는가'를 고민하는 것은 뇌의 메모리 낭비입니다. Git에서 최신 정보를 Pull하고, 스크립트를 실행하여, 나온 텍스트를 Gemini에 던진다. 이 일련의 동작을 루틴화함으로써, 미경험 신입이라 할지라도 베테랑과 완전히 동일한 '질 높은 전제 정보'를 AI에게 제공하여 고품질의 답변을 끌어낼 수 있었습니다.

스마트폰의 '단축어' 앱과 같습니다. 매일 정해진 사람에게 정해진 정형 문구의 메일을 보낼 때, 매번 수신인과 본문을 입력하는 것은 번거롭지요.

'재고 기능의 버그를 AI에게 물어보기 위한 준비'라는 작업을 원클릭 단축어로 등록하여 팀 전원이 공유함으로써, 압도적인 시간 단축을 실현하고 있습니다.

AI 개발 툴의 진화는 무시무시하며, Cursor 등의 편리한 툴은 매일 업데이트되고 있습니다.

하지만 '자사에서는 특정 AI만 허용된다', '레거시 환경이라 최신 툴을 사용할 수 없다'는 현장도 여전히 많은 것이 현실입니다.

그렇기에 '텍스트를 결합하여 AI에게 전달한다'는 보편적이고 검증된(枯れた) 기술과, '필요한 문맥을 폴더로 관리·공유한다'는 운용의 조합이 빛을 발합니다. 툴에 휘둘리는 것이 아니라, 엔지니어 스스로가 'AI에게 무엇을 인풋(Input)해야 하는가'라는 아키텍처를 컨트롤하는 것.

이것이야말로 어떤 환경에서도 통용되는 진정한 AI 활용술이라고 믿습니다.

Gemini (제미나이)

Google이 개발한 생성 AI 모델. 장문의 문맥을 한 번에 읽어들이는 능력(컨텍스트 윈도우)이 뛰어나며, 대규모 소스 코드 해석에 매우 적합하다. -
컨텍스트 윈도우 (Context Window)

AI가 한 번의 상호작용에서 기억·처리할 수 있는 '글자 수의 상한(작업 메모리)'. 이를 초과하면 AI는 정보를 잊어버리고 답변의 정밀도가 현저히 저하된다. -
Git (깃)

프로그램의 소스 코드 등의 변경 이력을 기록·추적하기 위한 분산형 버전 관리 시스템. 본 기사에서는 AI에게 읽히기 위한 '설정 파일'을 팀 전원이 공유·통일하기 위해 활용하고 있다. -
아키텍처 (Architecture)

시스템이나 소프트웨어의 기본 구조, 혹은 설계 사상(Design Philosophy)을 의미한다. 본 기사에서는 "기능별로 폴더를 나누고, 공통 설정과 개별 소스 코드를 자동으로 결합하는 메커니즘" 그 자체를 가리킨다. -
.csproj / appsettings.json

C# (.NET) 개발에 있어, 프로젝트 전체의 구성이나 설정(데이터베이스 접속 정보 등)이 기술된 필수 파일군. AI에게 시스템 전체를 이해시키기 위한 "전제 지식"으로서 매우 중요하다. -
속인화 (Zokujinka, 属人化)

특정 업무의 진행 방식이나 노하우가 특정 담당자만이 알 수 있는 상태가 되는 것. 팀 개발에 있어 가장 큰 리스크 중 하나이다.