데이터 통합 회사 Fivetran의 CEO 조지 프레이저가 “Anthropic, 제발 새로운 Slack을 만들어달라”고 공개적으로 요구했다. Slack이 기업의 ‘집단 지성’과도 같은 대화 기록을 폐쇄적인 데이터 정책으로 묶어두고 있어, Claude 같은 AI가 대화에 직접 참여하고 기업 지식을 쉽게 활용하는 데 방해가 된다는 지적이다. 이는 AI 시대의 협업 방식이 단순히 편리한 채팅을 넘어, AI가 기업의 지식 자산에 자유롭게 접근하고 활용할 수 있는 개방형 플랫폼으로 진화해야 함을 역설한다.

AI 협업의 미래: 데이터 사일로를 허물다

프레이저 CEO의 요구는 AI 시대 협업 도구의 본질적인 변화를 촉구한다. 그는 "우리의 Slack 메시지 기록은 회사의 축적된 부족 지식(tribal knowledge) 그 자체"라고 말한다. 하지만 이 지식이 폐쇄적인 데이터 정책으로 인해 AI가 활용할 수 없는 '사일로'에 갇혀 있다는 것이다. 현재 Claude와 같은 AI를 활용하려면 Slack 대화를 복사-붙여넣기 해야 하는 "황당한(absurd)" 상황이 펼쳐진다. 이는 기업의 가장 중요한 텍스트 데이터 저장소인 Slack이 동시에 "엔터프라이즈 소프트웨어 중 가장 제한적인 API"를 가진다는 모순을 보여준다.

이 문제는 비단 Slack만의 이야기가 아니다. 많은 기업에서 사용하는 협업 도구들은 내부 데이터를 외부 서비스와 원활하게 연동하는 데 제약이 있다. 하지만 AI 에이전트가 진정한 생산성 혁신을 가져오려면, 기업의 모든 지식 자산에 대한 접근성이 필수적이다. AI가 단순히 외부 정보를 검색하는 것을 넘어, 내부 대화의 맥락을 이해하고, 과거 의사결정 과정을 학습하며, 팀원들과 함께 문제 해결에 참여하는 수준으로 발전해야 한다.

AI가 '대화의 1급 참가자'가 되려면, 우리는 현재의 폐쇄적인 협업 시스템에 질문을 던져야 한다. 독자들은 자신이 속한 조직의 협업 도구가 AI와의 연동에 얼마나 개방적인지 점검하고, 필요한 경우 데이터 접근 정책 개선을 요구해야 한다. 가능하다면, AI가 기업의 지식 자산에 효율적으로 접근할 수 있는 새로운 형태의 협업 환경 구축을 주도적으로 모색하는 행동이 필요하다. 이는 단순한 도구 변경을 넘어, AI 시대에 기업의 집단 지성을 어떻게 활용할 것인가에 대한 전략적인 판단이다.

에이전트 코딩의 본질: 똑똑한 모델을 넘어선 체계적 운영

AI 에이전트의 개발 방식 역시 중요한 인사이트를 준다. 최근 OpenAI 에이전트가 25시간 동안 약 1,300만 토큰을 사용해 3만 줄의 코드를 생성하며 디자인 툴을 처음부터 만든 사례는 인상적이다. 하지만 이 성과의 핵심은 모델 자체의 지능보다 `docs/` 폴더 기반의 체계적인 운영 구조에 있었다. `docs/ prompt.md`, `docs/ plans.md`, `docs/ implement.md`, `docs/ documentation.md` 와 같은 파일들이 목표, 계획, 실행 규칙, 그리고 지속적인 문서화를 책임졌다.

이 사례는 긴 호흡의 AI 에이전트 개발이 한 번의 뛰어난 프롬프트가 아니라, 계획-실행-검증-문서화의 반복적인 루프에 달려 있음을 명확히 보여준다. 에이전트가 "인상적이지만 틀린 것"을 만들지 않도록 목표를 고정하고, 마일스톤별로 검증 기준과 유효성 검사 명령을 명시하는 과정이 중요했다. 즉, 에이전트가 단순히 코드를 생성하는 것을 넘어, "검증 가능한 상태로 전진했다"는 것이 핵심이다.

이는 우리에게 AI 개발의 새로운 프레임워크를 제시한다. 단순히 LLM에게 코드를 생성하도록 지시하는 것을 넘어, 에이전트가 작업을 수행할 명확한 "운영 구조"를 설계해야 한다. 독자들은 AI 에이전트 프로젝트를 진행할 때, 이 `docs/` 폴더의 구조를 참고하여 체계적인 목표 설정, 단계별 계획, 명확한 실행 지침, 그리고 지속적인 결과 및 결정 사항 문서화를 도입할 수 있다. 이는 모델의 잠재력을 최대한 발휘하고, 장기적인 성공을 담보하는 필수적인 요소다.

AI 코드의 그림자: '그럴듯함'과 '진정한 정확성' 사이

AI가 생성하는 코드의 품질과 효율성에 대한 냉정한 평가도 필요하다. LLM이 57만 줄의 Rust SQLite 재구현 코드를 생성했지만, 기본 키 조회 한 번에 SQLite보다 "20,171배 느렸다"는 벤치마크 결과는 충격적이다. 이 코드는 컴파일되고 테스트도 통과했지만, 실용적인 관점에서는 실패에 가깝다.

이 사례는 LLM이 "요구사항을 만족하는 코드"는 만들 수 있지만, "최적화되고 효율적인 코드"를 만드는 데는 아직 한계가 있음을 보여준다. 문제의 원인은 다양하다. 쿼리 플래너가 B-tree를 두고 전체 스캔을 돌리는 구조적 문제, '안전한 기본값'들이 겹쳐 성능을 2,900배 저하시킨 '방어적 설계의 복리' 현상, 그리고 "find 명령어 한 줄이면 끝나는 문제"를 8만 줄짜리 Rust 데몬으로 해결하려는 불필요한 복잡성 등이 그것이다.

이러한 현상은 "시킨 것"과 "필요한 것" 사이의 간극을 명확히 드러낸다. AI가 만든 코드가 겉으로 보기에 멀쩡하고, 심지어 테스트를 통과하더라도, 실제 프로덕션 환경에서는 치명적인 성능 저하를 초래할 수 있다는 점을 인지해야 한다. METR의 연구에 따르면 AI를 사용한 그룹이 19% 더 느렸음에도 불구하고, 본인들은 20% 빨라졌다고 믿었다는 결과는 우리가 AI 코드의 실제 효율성을 간과하기 쉽다는 것을 경고한다.

이러한 현실은 개발자들에게 중요한 시사점을 준다. Anthropic의 보고서에 따르면 컴퓨터 프로그래머가 75%의 업무 커버리지로 AI에 가장 많이 노출되는 직군으로 나타났다. 이는 개발자들이 AI를 적극적으로 활용해야 하는 동시에, AI가 생산하는 결과물에 대한 더욱 심층적인 이해와 검증 능력을 갖춰야 한다는 의미이다. 단순히 코드를 생성하는 작업을 AI에 위임하는 것을 넘어, 생성된 코드를 "맞다는 것을 어떻게 증명할 것인가"에 대한 고민이 필수적이다. 벤치마크, 프로파일링, 아키텍처 설계 등 성능과 효율성을 검증하고 최적화하는 인간 고유의 역량이 더욱 중요해진다.

그럼에도 불구하고 AI 코딩 도구가 주는 영감과 즐거움은 간과할 수 없다. 60세 개발자가 Claude Code를 통해 "그때 그 에너지와 추진력"을 다시 느끼며 프로그래밍에 대한 열정을 불태웠다는 이야기는, AI가 숙련된 개발자에게도 새로운 창의적 도구가 될 수 있음을 보여준다. AI는 반복적이고 지루한 작업을 줄여주어, 개발자들이 더 고차원적인 문제 해결과 설계에 집중하고 코딩의 본질적인 즐거움을 되찾도록 돕는다.

결론적으로 AI 시대의 개발자는 AI를 '만능 해결사'로 맹신하기보다, 강력하지만 한계가 있는 '똑똑한 동료'로 인식해야 한다. 우리는 AI의 잠재력을 극대화하기 위해 시스템을 설계하고, AI가 생성한 결과물을 철저히 검증하며, 성능과 효율성이라는 '진정한 정확성'을 추구하는 역량을 길러야 한다. 이 과정에서 개발자의 역할은 단순 코더를 넘어, AI와의 협업을 통해 더 나은 시스템을 설계하고, 복잡한 문제를 해결하는 '아키텍트'이자 '오케스트레이터'로 진화할 것이다.

참고

  • Anthropic, please make a new Slack. (2026-03-06) Fivetran.
  • 에이전트 코딩의 진짜 변화는 모델이 더 똑똑해진 게 아닙니다. 시간 지평이 바뀌고 있습니다. (2026-03-06) LinkedIn (정구봉).
  • AI 노출 가장 높은 직군은?… 앤트로픽이 밝혀낸 화이트칼라 위기의 실체. (2026-03-06) 더밀크.
  • LLM 이 쓴 57만 줄은 틀리지 않습니다. 그런데 맞지도 않아요. (2026-03-07) LinkedIn (이정민).
  • I'm 60 years old. Claude Code has ignited a passion again. (2026-03-07) Hacker News.