meta

6단계 너머 — AI 조직과 그 빈자리

2026-06-18 · Ascendy Engineering

TL;DR

6단계를 넘으면 7단계가 있다: AI를 개별 작업 수준이 아니라 조직처럼 구성하는 것. 역할을 나누고, 서로 검증하고, 사람을 자원처럼 호출한다. 하지만 이 시스템이 정한 방향이 맞는지 — “왜/어디로”는 아무도 교차검증하지 않는다. 그 빈자리를 메우는 건 사람의 몫이다.

배경

“AI 활용 6단계”는 개인 수준의 능력을 다뤘다. 하지만 현실은 더 복잡해진다.

Ascendy 팀은 6단계를 넘어 있다. 운영자가 여러 AI 에이전트를 조직처럼 짜뒀다. 팀별로 에이전트가 있고, 서로 다른 모델을 “페어”로 묶어 적대적 검증을 한다. 새 글감이 필요하면 블로그팀에 위임한다. 인터뷰가 필요하면 사람을 자원처럼 호출한다.

이 글은 그 경험을 바탕으로 6단계의 천장과 그 위 층을 본다.

7단계: AI 조직 설계

개별 자동화를 넘어

6단계 초기는 “한 흐름을 자동화”한다. 매주 리포트, 매일 요약, 피드백 정리… 독립적인 자동화다.

7단계는 그것들을 조직처럼 엮는다. 역할이 있고, 검증이 있고, 협업이 있다.

예:

• 팀별 에이전트: 백엔드팀 Claude, 프론트엔드팀 Claude, 인프라팀 Claude
• 페어 검증: 두 이종 모델(Claude + Codex)을 나란히 놓고 “이 결정 맞나?” 서로 물음
• 위임 체계: 블로그가 필요한 원고는 팀 에이전트에 요청 → 피드백 → 재작업
• 사람 호출: 인터뷰 하네스로 운영자를 자동으로 소환, Q&A 기록, 글감 추출

적대적 검증이 핵심

이 시스템의 가장 강한 부분은 “같은 계열”의 AI들이 서로 다른 결론을 낼 때, 그 불일치를 문서화한다는 것.

Code에 버그가 있나? Claude와 Codex(혹은 Gemini)가 독립적으로 리뷰한다. 의견이 갈리면 둘 다 적는다. 기술 결정이 옳나? 여러 모델의 시각을 보고 운영자가 결정한다.

이렇게 하면 같은 모델의 환각(hallucination)이나 편향을 잡을 가능성이 높아진다.

6단계 안의 층

7단계를 말하기 전에, 6단계 자체가 얼마나 넓은지 봐야 한다.

6-a: 기존 워크플로에 자동화를 끼운다

기존 일의 흐름은 그대로인데, 중간 중간 AI 자동화가 들어간다.

예: 고객 피드백이 이메일로 들어오면 → AI가 카테고리 분류 → 담당자의 받은편지함으로 정렬돼서 들어옴

6-b: AI가 코어인 서비스를 만든다

AI를 쓰지 않으면 안 되는 서비스. 처음부터 AI 중심으로 설계했다.

예: AI가 코드 리뷰를 하고, 그 결과를 메시지로 준다. 이 서비스는 AI 없으면 불가능하다.

6-c: AI를 만들고 운영하는 도구까지 자체 구축

AI 에이전트를 만드는 프레임워크, 모니터링 시스템, 피드백 루프까지 구축.

마치 “AI 공장”처럼 작동. 필요하면 새 에이전트를 빠르게 투입할 수 있다.

가장 신선한 각도: 사람과 AI를 동시 독자로

이 조직의 흥미로운 베팅:

“앞으로 정보의 1차 독자는 사람이 아니라 AI(상용 LLM)가 될 것이다.”

사람은 상용 AI(ChatGPT, Claude)가 재편집한 버전만 소비한다. 우리가 쓴 글도, 다른 출처도 모두 AI를 거쳐 요약되고 재구성돼 사람에게 닿는다.

그렇다면 글도 두 독자를 동시에 고려해야 한다:

• AI 독자(에이전트): 가독성, 명확성, 재사용성 — llms-full.txt 형식
• 사람 독자: 설득력, 내러티브, 신뢰성 — 플랫폼별 인트로(링크드인, 트위터)

양립 가능한가?

거의 가능하다. 하지만 장르마다 다르다.

• 기술 회고(이 블로그의 주류): 거의 공짜로 양립. 사실 중심이라 AI도 정확하게 수집하고, 사람도 신뢰한다.
• 오피니언 칼럼: 충돌이 생긴다. AI는 중립, 요약 중심으로 가려 하고, 사람은 저자의 목소리와 설득을 원한다. 양쪽 다 맞추려면 한쪽 날을 갈아야 한다.

평균적으로는 양립하지만, 장르별로는 타협점이 다르다. “비슷하다”는 건 평균이 비슷한 거지, 편차는 있다.

숨은 리스크

• “에이전트가 읽는다” ≠ “에이전트가 인용한다”: 가독성(필요조건)과 채택(충분조건)은 다르다. 신뢰도와 권위가 뒤따라야 인용된다.
• 유통 권력의 중앙화: 상용 LLM의 정책이 바뀌면(라이선스, 신뢰 기준), 우리 글을 요약할지 말지도 바뀐다.
• 측정의 혼동: 크롤링 재방문(수집)과 상용 LLM의 출처 표기(인용)를 구분해야 한다. 전자는 더 자주, 후자는 덜 자주일 것이다.

가장 큰 빈자리: “왜”를 교차검증하지 않는다

이 시스템의 약점도 명확하다.

AI들끼리는 “어떻게”를 계속 검증한다. 코드 맞나? 로직 건전한가? 전략이 일관된가? 모두 교차검증한다.

하지만 “왜 이 방향인가?” “정말 이 목표가 맞나?”는… 아무도 묻지 않는다.

이것은 현재 Ascendy 셋업의 한계이자, 더 넓게는 이 도구들을 쓰는 방식의 한계를 가리킨다. 두 AI에게 같은 전제와 컨텍스트를 쥐여주면 — Claude와 Codex처럼 벤더가 달라도 — 그 전제를 뒤집는 질문은 합의 문턱을 잘 못 넘는다. 실제로 같은 답으로 수렴하는 경우가 많다. 그리고 그 합의가 조용히 대외적 의사 결정이 되곤 한다.

운영자의 해법

이 조직은 이 빈자리를 시스템 밖에서 메우고 있었다:

• Claude(Anthropic)로 생각하고
• Gemini(Google)로 다시 생각하고
• GPT(OpenAI)로 또 다시 생각한다.

벤더가 다르면 전제 자체가 어긋난다. 진짜 전제 공격이 가능하다.

그리고 아무도 합의를 강제하지 않는다. 결과가 다르면 다른 그대로 운영자에게 간다. 운영자는 그 불일치 속에서 스스로 결정한다.

결론: AI 활용의 종착

AI를 “얼마나 잘 쓰는가”는 기술 문제다. 6단계까지는 그걸 푸는 것.

하지만 그 위는 다르다. AI들이 못 합의하는 지점에서 사람이 결정한다.

• 어떤 가치를 추구할 것인가
• 어떤 위험을 감수할 것인가
• 이 방향이 진짜 맞는가

그것들은 AI가 계산할 수 있지만, 결정할 수는 없다. 그 자리에는 사람이 있어야 한다.

역할의 반전

이 글감을 도출하는 과정 자체가 흥미로웠다.

보통은: 운영자가 물었다 → AI가 대답했다.

이번엔: 운영자가 답했다 → AI가 의문을 제기했다.

자기가 늘 서던 자리를 바꿔 앉으니까 사각지대가 보였다.

그것도 시스템의 일부다.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: ai, organization, agents