Claude Blue에서 Bloom으로

"지금 우리 인프라 다 박살났어."

원준님이 화상통화에서 들은 첫마디였습니다. 메타에서 시니어 AI 엔지니어로 일하는 선배가 꺼낸 말입니다. AI가 뽑아내는 코드의 양이 사람이 읽고 검토할 수 있는 속도를 이미 넘어섰고, 코드를 제대로 보지도 않고 그냥 올려버리는 사람이 회사 곳곳에 생겼다는 것입니다. 안정적이어야 할 인프라가 그 여파로 흔들리고 있었습니다.

이 대화는 원래 원준님의 개인 기록이었습니다. 실리콘밸리에서 일하는 빅테크 엔지니어, 그리고 스타트업 창업자와 같은 날 나눈 이야기를 정리한 글이 생각보다 멀리 퍼졌고, 그 반향이 서울에서 Claude 커뮤니티가 처음 모이는 자리로 이어졌습니다. 우울을 뜻하는 'Claude Blue'에서 피어남을 뜻하는 'Bloom'으로.

Seoul Bloom은 그렇게 시작됐습니다. 팀에서는 그 출발점이 된 대화를, 한국에서 일하는 기업 실무자의 눈높이로 다시 옮겨 정리했습니다.

Claude Blue란 무엇인가?

Claude Blue는 실리콘밸리에서 AI 최전선에 선 사람들이 겪는 일종의 직업적 우울감을 가리키는 표현입니다.

특정 제품 이름이 아니라, 자신이 수십 년 쌓은 전문성이 몇 주 단위로 대체되는 것을 지켜보는 데서 오는 감정에 가깝습니다.

원준님이 인상적으로 본 지점은, 이 감정을 느끼는 사람이 뒤처진 사람이 아니라는 것이었습니다. 물리학과 엔지니어링으로 박사 학위를 받고 대기업과 메타를 거친, 가장 앞단에 선 선배가 이렇게 말했다고 합니다. "글을 쓸 때 나만의 구조나 시각화 방법론이 있었습니다. 그게 내 엣지였습니다. 그런데 AI한테 정리해 달라고 하면 명문이 탁 나온다." 새 모델을 써보고 "나 얼마 안 남았네"라는 생각이 드는 데 걸린 시간은, 예전처럼 몇 달이 아니라 하루였다고 했습니다.

AI 네이티브 조직은 실제로 어떻게 일하는가?

원준님 선배의 하루를 들여다보면 'AI 네이티브'라는 말이 구체적으로 잡힙니다. 그는 회사에서 클로드 코드를, 집에서는 코덱스를 씁니다. 새 업무를 받으면 에이전트를 두 개 동시에 띄웁니다. 하나는 목표만 던져놓고 먼저 달리게 하는 실행용, 다른 하나는 그 업무가 무엇인지 자신에게 설명해 주는 학습용입니다. 실행 에이전트가 하루 이틀 돌면 코드가 만 줄 가까이 쌓이고, 그사이 본인은 업무를 파악하며 결과물을 또 다른 에이전트와 함께 검토합니다.

원준님이 더 눈여겨본 건 도구가 연결된 방식이었습니다. 메타 내부에서는 구글 드라이브, 문서, 스프레드시트, 이메일, 지라, 컨플루언스, 위키가 전부 에이전트로 접근 가능하게 묶여 있습니다. 선배의 표현을 그대로 옮기면 이렇습니다. "나는 에이전트랑만 일하고, 내가 원하는 결과물의 형태로 각 도구에 데이터가 알아서 쌓인다." 스프레드시트를 직접 열 필요도, 지라 티켓을 손으로 정리할 필요도 없습니다. 터미널 안에서 지시하면 데이터베이스가 채워집니다.

성숙도를 보여주는 장면이 하나 더 있었습니다. 선배는 올해 첫 연말 평가 때, 사내 AI 도구에 "입사하고 나서 한 일 다 정리해 줘"라고 했더니 그동안 작성한 보고서와 문서를 모아 방대한 목록으로 요약해 줬다고 합니다. 본인은 소감만 덧붙이면 셀프 평가가 끝났습니다. 여기서 기업이 가져갈 첫 번째 신호가 나옵니다. AI 네이티브 전환의 출발점은 더 똑똑한 모델을 고르는 일이 아니라, 흩어진 업무 도구를 에이전트가 오갈 수 있게 연결해 두는 일입니다.

편리함의 이면, 코드 크라이시스

같은 환경이 문제도 만듭니다. 앞서 나온 "인프라가 다 박살났다"는 말이 그 지점입니다. AI가 만든 코드를 충분히 검토하지 않고 커밋하는 사람이 늘면서, 시스템 안정성에 균열이 생기고 있습니다.

선배의 예측은 여기서 한 발 더 나갔습니다. 비개발 회사도 같은 길을 걷는다는 것입니다. 100명이 하던 일을 세 명이 에이전트로 처리하는 회사가 나타나 가격을 후려치면 기존 회사가 먼저 무너집니다. 그다음에는 그 세 명 안에서도, 에이전트가 쏟아내는 결과물의 맥락을 놓쳐서 생기는 위기가 옵니다. 결국 세 명으로 에이전트를 제대로 지휘할 수 있는 조직만 살아남습니다.

원준님은 이 대목을 속도를 늦추라는 경고로 읽지 않았습니다. 어느 단계는 AI가 검증해도 괜찮은지, 어느 단계는 반드시 사람이 봐야 하는지, 그 경계를 미리 설계해 두라는 뜻에 가깝습니다. 검토 없이 흘러가는 자동화는 생산성이 아니라 부채가 됩니다.

승부처는 '에이전트 오케스트레이션'으로 옮겨갔다

실리콘밸리에서는 이제 '바이브 코딩'이라는 말을 잘 쓰지 않는다고 합니다. "게임 하나 만들어 줘" 식의 두루뭉술한 요청은 이미 한 세대 전 방식입니다. 지금은 장르, 캐릭터 성장 범위, 적 난이도 상승 방식까지 상세한 스펙 문서로 정의하고, 반복되는 요청의 공통점을 스킬이나 도구 형태로 묶어 에이전트에게 어떻게 잘 먹이느냐로 실력이 갈립니다. 그래서 요즘 더 많이 쓰이는 표현이 '에이전트 오케스트레이션'이라고 설명했습니다.

원준님이 정리한 핵심은 이렇습니다. 앞으로 사람이 맡는 일은 시작과 끝입니다. 무엇을 만들어야 하는지 감각으로 아는 것, 그리고 나온 결과가 마음에 드는지 판단하는 것.

여기에 하나가 더 붙습니다.

결과가 성에 안 찰 때 어느 부분이 왜 부족한지 정확히 짚어내는 능력입니다. 기업 단위에서는 여기에 리소스 최적화가 얹힙니다. 에이전트도 토큰 비용을 쓰기 때문에, 사람과 에이전트의 손을 어디에 배분할지 설계하는 것 자체가 경쟁력이 됩니다.

개발 직군만의 이야기가 아니다

메타에서 AI를 돌리는 건 엔지니어만이 아니었습니다. 원준님이 전한 바로는, 프로그램 매니저, HR, 영업까지 사실상 전 직군이 붙어 있습니다.

애플에서 영업 데이터를 다루는 한 매니저는 팀 전체를 에이전트 기반으로 바꿨다고 합니다. 데이터를 정리해 경영 판단용 인사이트를 뽑는 일을 통째로 에이전트화하자, 팀에 여력이 생겨 업무 범위를 넓혔습니다.

메타 사내에서는 HR 담당자가 "나는 엔지니어가 아닌데 이런 걸 만들어 봤다"며 직접 만든 도구를 공유하는 글이 종종 올라옵니다. 영업처럼 대면이 많은 직군도 엑셀에 핵심 메시지를 넣어 던지면 슬라이드가 만들어집니다. 선배 본인도 이제 슬라이드를 한 장 한 장 그리지 않습니다. 문단과 그래프를 주고 "만들어" 한 다음, "이 표 더 크게"처럼 몇 번 돌리면 끝입니다.

선배의 결론은 짧았습니다. "지금 메타에서 AI 안 하는 사람이 없는 것 같다." 문서 작업과 데이터 분석이 중심인 사무직이야말로 이 변화의 다음 순번이라는 얘기입니다.

변하지 않는 조직은 잡아먹힌다

선배는 국내 대기업 본사에서 일한 경험이 있습니다. 같은 AI 엔지니어 업무인데 삶이 완전히 달랐다고 했습니다. 가장 큰 차이는 "무언가를 하려 할 때 허락을 받는 깊이"였습니다. 대기업에서는 상사의 허락을 받고, 그 상사가 또 윗선의 허락을 받고, 계약서를 쓰고, 준비 과정을 보고합니다. 메타에서는 일단 만들어 올린 뒤 관련자를 태그하고 "이렇게 했는데 괜찮죠?"라고 물으면, 한 명만 승인해도 반영됩니다. 대기업에서 3개월에 하던 일을 지금은 일주일에 한다고 했습니다.

AI를 쓰지 않는 조직에 대한 진단도 솔직했습니다. "지금 안 쓰고 있으면 안 쓰는 이유가 있고, 그런 곳은 계속 안 쓴다." 보안이라는 표면적 이유 뒤에는 대개 이해관계가 있습니다. 사내 AI 도구를 납품하는 계열사가 있고 그 관계가 이미 짜여 있으면, 외부 도구를 도입하자는 제안이 그 구조를 흔듭니다. 성공 공식이 조직을 여기까지 데려왔기 때문에, 새로운 것이 나와도 방식을 바꾸지 않습니다. 그리고 그 틈을 더 작고 빠른 조직이 파고듭니다.

그럼에도 AI가 대체 못 하는 것

같은 날 원준님이 만난 실리콘밸리 창업자는 전혀 다른 위치에 있으면서도 비슷한 온도의 이야기를 했습니다. 그리고 한 가지를 분명히 했습니다. 비즈니스는 여전히 관계로 돌아간다는 것입니다. 아무리 소프트웨어가 글로벌하고 원격이 가능해도, 얼굴을 보고 밥을 먹어야 채워지는 신뢰가 있습니다. 그가 초기 고객을 확보한 통로도 학교 동문 네트워크였습니다.

원준님은 이 대목의 함의를 분명하게 봤습니다. AI로 자동화할수록, 사람만 만들 수 있는 판단과 관계의 가치는 오히려 올라갑니다.

• 무엇을 만들지 정하는 감각
• 결과를 받아들일지 가르는 판단
• 사람과 사람 사이의 신뢰

AI 네이티브 전환의 목적지는 사람을 빼는 게 아니라, 사람을 이 세 가지에 집중시키는 데 있습니다.

기업이 해야할 것

원준님이 정리한 대화들을 실무 언어로 옮기면 네 가지 과제가 남습니다.

1. 도구부터 연결합니다. 문서, 스프레드시트, 이슈 트래커, 이메일을 에이전트가 오갈 수 있게 묶는 것이 전환의 첫 단추입니다. 모델 선택은 그다음 문제입니다.
2. 검토 경계를 설계합니다. 어느 작업은 AI가 검증해도 되고, 어느 작업은 사람이 반드시 봐야 하는지 미리 정합니다. 검토 없는 자동화는 부채가 됩니다.
3. 오케스트레이션 역량을 키웁니다. 스펙을 정확히 쓰고, 부족한 부분을 짚어내고, 사람과 에이전트의 리소스를 배분하는 능력이 새로운 실력입니다.
4. 직군을 가리지 않습니다. 개발뿐 아니라 기획, HR, 영업까지 각 팀이 자기 업무를 에이전트로 다시 설계하도록 판을 깝니다.

From Claude Blue to Bloom

원준님은 처음엔 주변 15명에게 물어봐도 AI로 인한 병목을 느끼는 사람이 없어서 '아직 이른가' 싶었다고 합니다. 하루 동안 두 사람과 이야기한 뒤 생각이 바뀌었습니다. 우리가 병목을 못 느끼는 건 일을 잘해서가 아니라, 아직 AI를 충분히 안 써봤기 때문일 수 있다는 것입니다.

Claude Blue가 위기감의 이름이라면, Bloom은 그 위기감을 함께 마주하고 각자의 자리에서 답을 찾아보자는 이름입니다. Seoul Bloom은 원준님이 남긴 그 대화를 오프라인으로 옮겨온 자리입니다. 이 블로그에는 앞으로 행사를 만들고 운영하며 나온 이야기들이 하나씩 쌓입니다. 오늘의 이 기록은 그 첫 장입니다.

지금 화면에 에이전트 하나가 돌고 있다면, 그 옆에 하나를 더 띄워보는 것부터 시작해도 좋겠습니다.

자주 묻는 질문 (FAQ)

Q. Claude Blue가 정확히 무슨 뜻인가요?

• 실리콘밸리에서 AI 최전선에 있는 사람들이 겪는 직업적 우울감을 가리키는 표현입니다. 자신의 전문성이 빠르게 대체되는 것을 지켜보며 느끼는 위기감에 가깝습니다.

Q. 바이브 코딩과 에이전트 오케스트레이션은 어떻게 다른가요?

• 바이브 코딩은 "게임 하나 만들어 줘" 같은 대략적 요청입니다. 에이전트 오케스트레이션은 상세한 스펙 문서를 만들고, 반복 작업을 스킬·도구로 묶어 여러 에이전트를 구조적으로 지휘하는 방식입니다.

Q. 비개발 직군도 AI 네이티브 전환이 필요한가요?

• 네. 메타에서는 프로그램 매니저, HR, 영업까지 전 직군이 에이전트를 활용하고 있습니다. 문서 작업과 데이터 분석이 중심인 사무직이 이 변화의 다음 순번입니다.

Q. 기업이 가장 먼저 해야 할 일은 무엇인가요?

• 더 좋은 모델을 고르는 것보다, 흩어진 업무 도구를 에이전트가 접근할 수 있게 연결하는 것이 먼저입니다. 그다음 사람과 AI의 검토 경계를 설계해야 합니다.

다시 보기

Bloom과 함께하기

Bloom은 사람과 기술이 만나는 오프라인 자리를 만듭니다. 다음 행사에서 뵙겠습니다.

• 💬 디스코드 커뮤니티, 행사 공지가 가장 먼저 올라옵니다
• ▶️ 유튜브, 지난 행사 강연 다시 보기
• 📸 인스타그램, 현장 스케치
• 🎟️ 다가오는 행사 보기