AI를 통한 새로운 협업 경험

AI를 업무에 본격적으로 활용하기 시작한 건 사실 오래되지 않았다. 처음에는 솔직히 "내가 AI보다 낫다" 는 생각을 버리지 못했다.

AI가 만들어주는 코드를 보면 허술한 부분이 보였고, 결국 내가 다시 고쳐야 하는 경우가 많았다. 그래서 마음속에서는 늘 "결국은 내가 더 잘하지"라는 자만심이 자리 잡고 있었다.

초기 AI 활용의 한계와 좌절

돌이켜보면 그때의 나는 AI를 단순한 코드 생성기 정도로만 인식하고 있었다. ChatGPT에게 "React 컴포넌트 만들어줘", "이 버그 고쳐줘"라고 던지고는 결과물에 실망하기 일쑤였다.

하지만 지금 생각해보면, 문제는 AI의 능력이 아니라 내가 AI와 소통하는 방식 에 있었다. 나는 AI를 마치 주니어 개발자에게 대충 업무를 던져주는 것처럼 대했다. 맥락도, 제약사항도, 비즈니스 요구사항도 제대로 설명하지 않은 채 말이다.

나의 아집을 꺾게 된 순간

그런데 이 아집이 완전히 꺾인 순간이 있었다. 바로 팀장님의 애티튜드 를 보면서였다.

팀장님은 AI를 단순히 코드를 대신 작성해주는 도구로 보지 않았다. 오히려 AI를 통해 협업 방식 자체를 바꿀 수 있는 패러다임 으로 접근하고 계셨다.

사내 발표에서 공유해주신 "AI Native 조직" 이야기는 내 생각을 송두리째 흔들어 놓았다.

팀장님 발표에서 받은 충격

그 발표는 단순히 AI 활용 팁을 공유하는 세션이 아니었다. 조직 문화와 업무 방식의 근본적 변화 에 대한 이야기였다.

팀장님이 강조한 핵심은 이것이었다 "AI 시대에는 개인의 생산성이 폭발적으로 증가하지만, 정작 팀 차원에서는 여전히 병목이 발생한다. 왜일까?"

답은 정보의 파편화 와 맥락의 소실 에 있었다. 각자가 AI로 빠르게 작업하지만, 그 결과물들이 하나로 통합될 때는 여전히 많은 커뮤니케이션 비용이 발생한다는 것이다.

그 발표에서 처음 접한 개념이 바로 컨텍스트 엔지니어링(Context Engineering) 이었다. 단순히 AI에게 "코드를 짜줘"라고 요청하는 것이 아니라, 비즈니스 배경부터 기술 요구사항까지 구조적으로 정리해 전달하는 방식 이었다.

맥락이 살아 있는 상태로 문서화되고, 그 문서를 바탕으로 사람이든 AI든 같은 언어로 협업할 수 있게 된다. 이걸 보고 나서야 깨달았다. 중요한 건 내가 더 똑똑하다는 걸 증명하는 게 아니라, 좋은 도구를 어떻게 더 잘 활용할 수 있을지를 고민하는 것 이었다.

Context Engineering의 실체

팀장님이 보여준 Context Engineering의 구체적인 모습은 놀라웠다. 단순히 요구사항을 나열하는 것이 아니라, 비즈니스 맥락부터 기술적 제약사항, 의사결정 히스토리까지 구조화된 정보를 포함하고 있었다.

이런 맥락이 포함된 문서를 기반으로 AI와 협업하면, 결과물의 품질이 완전히 달라진다는 것을 보여주셨다. AI는 더 이상 단순한 코드 생성기가 아니라, 맥락을 이해하는 협업자 가 되었다.

👉 팀장님 발표 자료는 여기서 볼 수 있다.

AI 시대, 우리는 협업을 어떻게 해야 할까?

발표에서 인상 깊었던 부분을 옮기자면

"요즘 AI는 점점 똑똑해지고 개인 생산성은 비약적으로 올라가고 있습니다. 그런데 회사 팀 프로젝트는 왜 예전보다 빠르다고 느껴지지 않을까요? 저는 그 이유를 모호한 요구사항 → 맥락 소실 → 정보 파편화에서 찾았습니다. (…) 최근 주목받는 개념이 있습니다. 바로 Context Engineering."

이 한 문단만으로도 내가 왜 시각을 바꾸게 되었는지 설명이 된다.

실전 적용: BMAD Method 경험

항해플러스 8주차 과제를 하면서 이 개념은 더 분명하게 다가왔다. BMAD Method라는 AI Native Workflow Framework를 활용해 과제를 진행했는데, 결과적으로 직접 코드 한 줄도 치지 않고 PR을 올리는 경험을 하게 되었다.

BMAD의 4단계 프로세스

BMAD Method는 다음과 같은 4단계로 구성되어 있다

• Business Requirements (비즈니스 요구사항 정의)
• Master Document (마스터 문서 작성)
• Architecture Design (아키텍처 설계)
• Development & Delivery (개발 및 전달)

각 단계마다 명확한 산출물과 검증 기준이 있어서, AI와의 협업이 체계적으로 이루어진다.

개발자로서 가장 와닿았던 부분

개발자인 나에게 가장 충격적이었던 것은 문서 작성이 선택이 아닌 필수가 되는 구조 였다. 평소에는 "일단 코드부터 짜고 나중에 문서 정리하지"라는 마음가짐이었는데, BMAD에서는 문서 없이는 다음 단계로 넘어갈 수가 없었다.

그런데 이게 오히려 나중에 큰 도움이 되었다. AI에게 요청할 때도 "이런 느낌으로 해줘"가 아니라, 구체적인 기술 스펙과 제약사항을 명시해서 전달할 수 있게 된 것이다.

Master Document의 힘

두 번째 단계에서 정말 깨달은 것은 개발자도 문서를 잘 써야 한다 는 점이었다. 그동안은 "코드가 곧 문서다"라고 생각했는데, AI와 협업하려니 코드만으로는 부족했다.

Master Document에는 기술적 결정의 배경, API 설계 의도, 데이터 구조 선택 이유 등이 모두 들어가야 했다. 처음에는 번거로웠지만, 나중에 AI가 이 문서를 바탕으로 생성한 코드는 내가 직접 짠 것과 거의 차이가 없을 정도로 정확했다.

특히 기술적 의사결정 히스토리 를 기록하는 부분이 인상 깊었다. "왜 이런 라이브러리를 선택했는가?", "왜 이런 아키텍처 패턴을 적용했는가?" 같은 내용들이 문서에 명시되어 있으니, AI도 일관된 기준으로 코드를 생성할 수 있었다.

코드 한 줄 없이 완성한 PR

BMAD Method를 철저히 따르다 보니, 정말로 직접 코드를 작성하지 않고도 완전한 기능을 구현할 수 있었다. 개발자로서는 처음 겪는 경험이었다.

평소 내가 코드를 작성할 때와 AI가 Master Document를 보고 생성한 코드 사이에는 몇 가지 차이점이 있었다

• 더 꼼꼼한 에러 핸들링: 나라면 대충 넘어갔을 예외 상황들까지 모두 처리
• 더 체계적인 테스트 코드: 내가 보통 미루는 테스트 코드도 함께 작성
• 더 일관된 네이밍: 문서에 명시된 컨벤션을 정확히 준수

이 경험을 통해 깨달은 것은, 좋은 설계 문서가 있으면 AI도 시니어 개발자처럼 동작한다 는 점이었다. 오히려 나보다 더 꼼꼼하게 코드를 작성하는 경우도 있었다.

개발자로서 느낀 프레임워크의 가치

BMAD Method를 경험하면서 흥미로운 토론이 벌어졌다. 항해플러스를 함께하고 있는 영서님께서 했던 질문이다.

"굳이 이런 프레임워크가 필요할까? AI에게 잘 물어보기만 해도 충분하지 않냐?"

자유 vs 일관성의 딜레마

이 질문은 개발자라면 누구나 한 번쯤 고민해봤을 것이다. React 같은 프레임워크를 쓸 때도, ESLint나 Prettier 같은 도구를 도입할 때도 비슷한 논의가 벌어진다.

"굳이 이런 제약을 둬야 해? 그냥 자유롭게 개발하면 안 돼?"

나는 이렇게 생각했다.

개발에서 일관성은 자유보다 중요하다. React를 쓰는 것도, TypeScript를 쓰는 것도 마찬가지다. 개인의 코딩 자유도는 줄어들지만, 팀 전체의 생산성과 유지보수성을 확보할 수 있다

BMAD 역시 이런 철학을 문서 작성과 AI 협업에 적용한 것이었다. 조금 번거롭더라도 일관된 방식을 따르는 편이 훨씬 낫다는 걸 이번에 깨달았다.

프레임워크가 만드는 개발 문화

더 중요한 깨달음은 프레임워크가 팀의 개발 문화를 만든다 는 점이었다. BMAD를 사용하면 팀원 A가 작성한 기술 문서를 팀원 B가 쉽게 이해할 수 있고, AI도 동일한 구조로 코드를 생성한다.

이는 단순히 문서 템플릿의 문제가 아니다. 개발자의 사고 방식을 표준화 하는 것이다. 문제를 어떻게 분석하고, 어떤 순서로 설계해나갈 것인지에 대한 공통된 접근법을 제공한다.

실제로 BMAD를 적용한 후 우리 팀에서 다음과 같은 변화가 나타났다

• 코드 리뷰 시간 단축: 설계 의도가 문서에 명확히 나와있어 빠른 이해 가능
• 온보딩 속도 향상: 신규 팀원도 문서만 보면 프로젝트 구조를 쉽게 파악
• 기술 부채 감소: 임시방편성 코드 대신 설계 기반의 구현이 늘어남

다른 개발자들의 반응

영서님 외에도 다른 개발자들의 반응은 다양했다. 처음에는 "문서 쓰는 시간에 코드 더 짜겠다"는 반응이 많았지만, 써보고 나면 "디버깅 시간이 확 줄었다"거나 "나중에 유지보수할 때 편하더라"는 평가로 바뀌었다.

특히 인상 깊었던 것은 한 동료의 말이었다. "AI랑 일하려니까 오히려 더 체계적으로 생각하게 되네요. 사람한테는 '대충 이런 느낌으로'라고 해도 알아듣는데, AI는 정확히 말해야 하니까 내 생각도 더 명확해지는 것 같아요."

이 말이 핵심을 찔렀다. AI와의 협업이 오히려 개발자의 설계 역량도 개선시킨다 는 것이다.

시행착오와 배움

물론 시행착오도 많았다. AI에게 한 번에 너무 큰 태스크를 맡기면 쉽게 무너졌다. 그럴 때마다 작업을 더 작은 단위로 쪼개어 다시 요청해야 했다.

실패에서 얻은 교훈

이런 실패들을 통해 몇 가지 중요한 원칙을 깨달았다

1. 작업 분할의 중요성

큰 작업을 작은 단위로 쪼개는 것은 단순히 AI의 한계 때문만이 아니었다. 각 단계별로 검증하고 피드백을 받을 수 있는 구조 를 만드는 것이 핵심이었다.

2. 맥락 유지의 어려움

AI는 대화의 맥락을 유지하는 데 한계가 있다. 따라서 문서를 통한 맥락 보존 이 필수적이었다. Master Document가 바로 이런 역할을 해주었다.

3. 반복적 개선의 필요성

한 번에 완벽한 결과를 기대하지 말고, 점진적으로 개선해나가는 접근법 이 효과적이었다. 마치 애자일 개발 방법론과 비슷한 맥락이었다.

코치님이 해주신 피드백이 기억에 남는다.

1. 일을 잘게 나눌 것
2. AI에게 계획을 먼저 세우게 할 것
3. 그리고 그 계획대로 시키는 것

개발과 협업의 유사점 발견

이 세 가지 원칙을 실천하다 보니, 흥미로운 깨달음이 있었다. AI와 일하는 방식이 시니어 개발자가 주니어를 가이드하는 방식과 놀랍도록 유사하다 는 것이다.

시니어 개발자가 주니어에게 일을 맡길 때 하는 일과 AI와 협업할 때 필요한 것들 사이에는 많은 공통점이 있었다. 큰 기능을 구체적이고 실행 가능한 태스크로 분할하고, 명확한 기술적 맥락과 목표를 제공하며, 정기적인 코드 리뷰와 피드백을 통해 방향을 조정하는 것 등이 그것이었다.

이 유사점을 발견한 후, 평소 존경하던 시니어들의 코드 리뷰 스타일이나 멘토링 방식을 AI와의 협업에 적용해보기 시작했다.

이런 식으로 접근하니 결과물의 품질이 확연히 달라졌다.

AI와 함께하는 개발 환경

BMAD Method 경험과 여러 시행착오를 통해, 앞으로의 개발 방식에 대한 새로운 시각을 갖게 되었다.

AI Native 개발팀의 모습

팀장님이 말씀하신 "AI Native 조직"을 개발팀 관점에서 상상해보게 되었다. 모든 기능 개발이 체계적인 설계 문서에서 시작되고, 이 문서는 단순한 기록이 아니라 실행 가능한 기술 명세서 역할을 한다. 개발자가 읽어도, AI가 읽어도 같은 구조로 코드를 구현할 수 있는 형태로 작성된다.

팀원이 바뀌거나 기능이 인수인계될 때, 별도의 코드 설명 없이도 문서만으로 완전한 기술적 맥락 이해가 가능하다. AI는 이런 문서를 기반으로 즉시 개발에 참여할 수 있다.

개발자 역할의 변화

앞으로는 "AI와 페어 프로그래밍하는 능력" 이 개발자 스킬의 핵심이 될 것 같다. 단순한 코딩 작업은 AI가 담당하고, 개발자는 더 고수준의 설계와 아키텍처, 코드 품질 관리에 집중하게 될 것이다.

• 기존 개발자 업무: 요구사항 분석 → 설계 → 코딩 → 테스트 → 배포
• AI 시대 개발자 업무: 요구사항 분석 → 상세 설계 문서화 → AI와 협업하여 구현 → 품질 검증 → 배포

코딩보다는 설계와 검증에 더 많은 시간을 투자하게 되는 셈이다. 오히려 더 본질적인 개발자 역량 에 집중할 수 있게 된 것 같다.

마무리

돌이켜보면 이번 경험은 내 사고방식에 큰 전환점을 주었다. 나는 더 이상 "내가 AI보다 낫다"는 생각을 하지 않는다.

대신 "어떻게 하면 더 잘 활용할 수 있을까?" 를 고민하게 됐다. 그리고 이 고민은 단순히 AI 활용에 그치지 않고, 앞으로 팀을 어떻게 이끌고 협업을 만들어갈 것인지에 대한 새로운 시각을 열어주었다.

가장 큰 변화: 설계 우선 사고

이번 경험을 통해 얻은 가장 큰 변화는 설계를 먼저 생각하는 습관 이 생긴 것이다. 문제를 마주했을 때 무작정 코드를 짜기보다는, 다음과 같은 질문들을 먼저 던져보게 되었다

• 이 기능의 핵심 요구사항은 무엇인가?
• 어떤 기술적 제약조건들이 있는가?
• 확장성과 유지보수성은 어떻게 고려할 것인가?
• API 설계는 어떻게 할 것인가?
• 테스트는 어떻게 작성할 것인가?

이런 사고 과정은 AI와의 협업뿐만 아니라, 동료 개발자들과의 코드 리뷰에서도 큰 도움이 되고 있다.

앞으로의 생각

결국 내 회고는 이렇게 정리할 수 있다.

"AI를 단순한 코딩 도구로 쓰는 수준을 넘어, 개발 방식과 팀 협업을 다시 고민하게 된 시간이었다."

앞으로 나는 AI와 개발자가 조화롭게 협업하는 방식을 계속 탐구해보고 싶다. 단순히 개인의 생산성 향상이 아니라, 팀 전체의 개발 역량을 높이는 방향 으로 말이다.

AI는 분명 강력한 개발 도구다. 하지만 도구는 그것을 사용하는 개발자에 따라 그 가치가 결정된다. 나는 이 도구를 통해 더 나은 코드를 작성하고, 더 의미 있는 문제들을 해결하는 데 기여하고 싶다.

그 첫 걸음이 바로 이번 경험이었다고 생각한다.