아웃오브박스 AI가 팀을 왜곡하는가 – 그리고 무엇을 해야 하는가

대부분의 기술은 사용할수록 더 편안하게 사용할 수 있습니다. 그러나 AI 도구의 경우 반대가 사실입니다. Stack Overflow는 49,000명 이상의 개발자를 대상으로 한 연례 설문조사에서 AI 도구의 사용률은 84%로 증가했지만, 이러한 도구의 정확성에 대한 신뢰는 1년 만에 40%에서 29%로 떨어졌습니다.

이 효과는 저에게 익숙합니다. 저희 팀이 처음으로 AI 도구를 사용했을 때, 기술 언론이 빠른 작업과 덜 힘든 작업에 대한 감동적인 효과를 계속해서 썼음에도 불구하고, 개발자들은 실망했습니다. AI는 중간 수준의 코드를 생성했으며, 코드를 검토하는 데 오랜 시간이 걸렸으며, 결국에는 다시 작성해야 했습니다. 팀은 AI가 시간을 절약할 것으로 기대했지만, 실제로는 추가 작업을 해야 했습니다. 따라서 첫 번째 시도 후에 팀은 다시 원래대로 작업했습니다.

오늘날, 동일한 도구는 개발자들이 코드를 작성하고 검토하는 것을 가속화합니다. 더 나은 모델을 찾은 것이 아니라, 우리는 그와 함께 작업하는 방식을 변경했습니다. 우리에게 도움이 된 것은 다음과 같습니다.

개발자들이 왜 AI 작성 코드에 실망하는가

AI는 인터넷 전체에서 대규모 공개 코드에 의존하며, 이러한 코드는 드물게 탁월합니다. 코드의 품질은 평균이며, 모델은 이러한 평균을 재현합니다.

그러나 “평균”은 가능한 최고 수준이 아닙니다. 모델이 프로젝트를 알게 되면, 그것은 단지 평균을 생성합니다. 600명 이상의 개발자를 대상으로 한 Qodo 조사에 따르면, AI 코드의 품질에 불만을 가진 개발자 중 44%는 이것을 바로 컨텍스트 부족에 기인합니다. 이것이 코드의 출력을 중간 수준으로 유지합니다.

好的 소식은 AI가 받는 컨텍스트가 팀이 완전히 제어할 수 있는 유일한 변수라는 것입니다. 도구가 프로젝트를 얼마나 잘 이해하는지는 모델에 달려 있지 않습니다. 무엇을 입력하느냐에 달려 있습니다.

두 번째 이유는 정신적인 것입니다. 작업의 본질이 변경됩니다. AI가 대부분의 코드를 작성하면, 개발자의 주요 작업은 더 이상 코드를 작성하는 것이 아니라 생성된 코드를 검토하는 것입니다. 즉, 누군가의 솔루션을 읽고, 대안을 평가하고, 무엇이 배포 준비가 되었는지 결정하는 것입니다. 이것은 코드를 직접 작성하는 것과는 다른 기술이며, 코드 작성 부분을 좋아하는 사람들에게 쉽게 오지 않습니다.

GitHub는 2025년 Octoverse 보고서에서 정확히 이러한 변화를 설명합니다. AI와 가장 멀리 간 개발자는 더 이상 “코드의 저자”라고 부르지 않고, 코드의 “창의적인 디렉터”가 됩니다. 여기서 핵심 기술은 코드를 지시하고 검증하는 것입니다. 그러나 이 역할로 가는 길은 실수와 좌절을 거치며, 결국에는 자신의 작업에서 보상을 볼 때까지입니다.

AI가 좌절의 원천에서 도구로 변하는 것

저희 팀이 처음으로 AI를 사용했을 때, 일부 개발자는 Claude Code, OpenAI Codex, GitHub Copilot, Gemini CLI와 같은 도구를 사용했습니다. 각 도구는 서로 다른 결과를 냈습니다. 따라서 팀이 AI와 함께 작업하는 방식을 정리하기 위해, 첫 번째로 한 일은 단일 도구를 선택하는 것이었습니다.

이것은 저희의 관행뿐만 아니라 다른 팀의 관행이기도 합니다. 예를 들어, Linear 팀은 2026년 초까지 “모두가 원하는 대로 작업할 수 있다”는 원칙을 따랐습니다. 그러나 리더십은 이 접근 방식을 포기하고 모든 개발자를 단일 작업 방식으로 옮겼습니다. 개발자는 두 개의 AI 도구 중 하나를 사용하여 코드를 작성해야 했으며, 수동으로 작성하지 말아야 했습니다. 이 회사는 평균 생산성이 다음 달에 병합된 PR이 30%, 엔지니어당 종료된 작업이 33% 증가했다고 보고했습니다.

그러나 공유 도구만으로 코드를 개선할 수 없습니다. 도구를 설정해야 합니다. 즉, 규칙을 정의해야 합니다. 예를 들어, 규칙.md 파일을 작성하여 코드를 작성하는 방법을 설명해야 합니다. 또한 프로젝트의 일반적인 작업을 위해 사용자 지정 기술을 개발해야 합니다. 따라서 개발자가 같은 것을 설명하지 않아도 됩니다. 마지막으로, 기존 코드베이스를 도구에 제공하는 것이 좋습니다. 도구는 프로젝트가 작성된 방식을 분석하여 새로운 코드를 동일한 스타일로 생성합니다. 도구가 받는 컨텍스트가 많을수록, 수동으로 다시 작성해야 하는 코드가 줄어듭니다.

그러나 가장 어려운 부분은 기술적인 것이 아닙니다. 코드의 저자에서 코드의 평가자로의 전환은 tự發적으로 발생하지 않습니다. 이 전환에는 도움이 필요합니다. 가장 직접적인 방법은 훈련과 인증입니다. 예를 들어, 10명의 개발자가 도구 제공업체와의 파트너 프로그램을 진행하고 있습니다. 또한, 도구의 채택을 담당하는 사람이 함께 작업하며, 도구가 특정 결과를 생성한 이유와 이를 수정하는 방법을 설명합니다.

팀이 협조적으로 작업할 때, 하나의 병목 현상이 남아 있습니다. 즉, 검토입니다. 이 병목 현상을 AI로 강화하는 것이 좋습니다. 에이전트는 모든 풀 요청을 먼저 검토하고, 명백한 문제를 해결합니다. 즉, 루틴 실수, 스타일, 반복, 보안 구멍 등을 해결합니다. 인간 검토자는 더 이상 모든 것을 무분별하게 검토하지 않습니다. 오직 건축물과 중요한 결정만 검토합니다. 이 효과는 이러한 도구를 구축하는 회사 내에서도 명백합니다. Anthropic에서 이러한 에이전트를 도입한 후, 실질적인 검토를 받은 풀 요청의 비율은 16%에서 54%로 증가했으며, 엔지니어는 에이전트의 댓글에 대해 1% 미만으로 동의하지 않았습니다.

저희에게 이것은 2~3일 동안 여러 번에 걸쳐 진행되던 검토 주기를 단축했으며, 또한 선임 엔지니어의 일상 업무를 줄였습니다. 그들은 이제真正로 어려운 부분에만 집중할 수 있습니다. 도구가终于 결과를 생성했을 때, 도구에 대한 신뢰도 나타났습니다.

AI 도구에 대한 신뢰가 효과를 나타내는 곳

첫째, 코드 작성에서 효과가 나타납니다. 도구가 프로젝트를 알고, 에이전트가 첫 번째 검토를 처리하면, 팀은 동일한 시간에 더 많이, 더 잘 코드를 작성합니다. 저희의 경우, AI 도구는 작업을 약 30~40% 가속화했습니다.

또한, AI는 온보딩을 더 쉽게 만들었습니다. 새로운人が 프로젝트에 합류할 때, 경험 있는 사람이 프로젝트의 코드 구조에 대한 수십 개의 질문에 답변해야 했습니다. 이제 에이전트가 이 역할을 수행합니다. 프로젝트가 잘 문서화되어 있다면, 새로운人は 동료에게 질문하는 대신 에이전트에게 95%의 질문을 합니다.

문서화도 비슷한 이야기입니다. 대략적인 건축 설계 초안은 이제 대부분 에이전트가 작성합니다. 저희의 추정에 따르면, 에이전트가 충분한 컨텍스트를 받으면, 약 80%의 초안을 작성할 수 있습니다. 인간이 해야 할 일은 저장소에 없는 결정, 트레이드오프, 전문 지식입니다.

同じく 중요하게는, AI가 할 수 있는 일의 한계를 명확하게 하는 것입니다. 왜냐하면, 부풀린 기대가 처음부터 실망을 불러일으키기 때문입니다. AI는 컴플라이언스를 담당하지 않습니다. 인간이 의료 또는 금융 데이터에 대한 책임을 지며, 회사가 모델이 아닌 책임을 지습니다. 또한, AI는 파트너와의 통합을 가속화하지 않습니다. 여기서 수십 개의 시간이 통화와 조정에 소요됩니다.

아웃오브박스 AI는 정말로 짜증나지만, 완성된 솔루션으로 사용할 때만 così입니다. 좌절과 보상의 차이는 도구 주변에 무엇을 구축하느냐에 달려 있습니다. 즉, 공유 표준, 프로젝트의 컨텍스트, 개발자의 새로운 역할입니다.