ekyu 님의 블로그

《한국사 이상현상 연구원》 리뷰 — 귀신보다 무서운 건 기록에서 사라진 사람들이었다

ekyu — Fri, 2 Oct 2026 13:52:58 +0900

《한국사 이상현상 연구원》 리뷰 — 귀신보다 무서운 건 기록에서 사라진 사람들이었다

처음 제목을 봤을 때는 조금 가볍게 생각했다.

한국사 + 이상현상 + 비밀 연구기관.

궁궐에서 귀신이 나오고, 고분에 들어갔다가 사람이 사라지고, 오래된 사찰에서 설명할 수 없는 일이 생기면 정체불명의 기관 사람들이 출동해서 해결하는 이야기.

대충 그런 책일 거라고 예상했다.

실제로 그런 재미가 있다.

그런데 500쪽 가까운 이야기를 따라가다 보면 생각보다 다른 곳에 마음이 걸린다.

처음에는 이상현상이 궁금해서 읽는데 나중에는 이런 생각을 하게 된다.

왜 하필 이곳에서 이런 일이 생겼을까.

그리고 조금 더 읽으면 질문이 다시 바뀐다.

여기에서 예전에 무슨 일이 있었던 걸까.

그때부터 《한국사 이상현상 연구원》은 괴담집하고는 조금 다른 책이 된다.

무서운 건 귀신인데, 결국 기억에 남는 건 사람이다.

소설인데 정말 연구소 자료를 훔쳐보는 것 같다

이 책에서 가장 먼저 재미있는 건 형식이다.

일반적인 소설처럼

주인공이 어디로 갔다.
누군가를 만났다.
사건이 벌어졌다.

이런 방식으로만 진행되지 않는다.

탐사 지침서가 나오고,

사건 보고서가 나오고,

녹취록이 나오고,

면담 기록이 나오고,

연구원 직원들이 주고받은 채팅까지 들어간다.

처음 몇 장은 소설을 읽는다기보다 어디선가 유출된 내부 문서를 보고 있는 기분이 든다.

이 방식이 생각보다 잘 먹힌다.

귀신이 정말 존재한다고 아무리 설명해도 결국 소설이라는 걸 알고 읽는다.

그런데

사건번호, 탐사 절차, 주의사항, 기록 시간

같은 것들이 붙기 시작하면 이상하게 진짜 같아진다.

특히 사건을 설명하는 문체가 차가울수록 오히려 무섭다.

누군가는 그 장소에서 분명 끔찍한 일을 겪었는데 보고서에는 몇 줄로 정리된다.

사람의 공포가 행정 문서가 되는 순간이 있다.

나는 이게 꽤 좋았다.

처음에는 괴담이었는데 어느 순간 한국사가 들어온다

배경도 한국 사람에게 익숙하다.

궁궐,

고분,

사찰,

종갓집,

오래된 건물.

해외 호러물에서 보던 낡은 저택이나 정신병원이 아니다.

학교 다닐 때 수학여행으로 갔을 것 같은 곳이고, 주말에 관광객들이 사진을 찍고 있을 것 같은 곳이다.

그 익숙함 때문에 오히려 묘하게 기분이 나쁘다.

낮에는 아무렇지 않게 지나갔던 장소인데,

“밤이 되면 저 안에서 이런 일이 생긴다면?”

하고 생각하기 시작한다.

그런데 작가는 역사적 장소를 그냥 괴담의 배경으로만 쓰지 않는다.

이게 이 책에서 가장 마음에 들었던 부분이다.

처음에는 장소가 무서운데,

조금 지나면 그 장소에 남아 있는 시간이 무서워진다.

역사는 대부분 아주 건조하게 기록된다

학교에서 역사를 배울 때 흔히 이런 식이다.

몇 년에 전쟁이 일어났다.

왕이 바뀌었다.

반란이 일어났다.

몇 명이 처형됐다.

정책이 바뀌었다.

시험을 볼 때는 이것만 알면 된다.

그런데 조금 생각해 보면 그 문장 하나 안에 실제 사람들이 있다.

‘수백 명이 죽었다.’

라고 적혀 있으면 역사책에서는 한 줄이다.

하지만 그 수백 명에게는 각자 가족도 있었고 이름도 있었고, 죽기 직전까지 살던 하루가 있었다.

《한국사 이상현상 연구원》은 계속 그 사이를 파고든다.

역사책에 남은 큰 사건보다 그 사건 밑에서 사라진 사람들을 본다.

그래서 책을 읽으면서 자꾸 ‘행간’이라는 단어가 떠올랐다.

기록에는 있는데 사람이 없는 역사.

혹은 사람이 분명 있었는데 기록에는 없는 역사.

이 책의 괴이현상은 그 사이에서 나오는 것처럼 느껴진다.

그래서 여기서 귀신은 조금 다른 의미가 된다

보통 괴담에서 귀신은 해결해야 할 문제다.

정체를 밝혀내고,

원한을 풀어주거나,

봉인하거나,

도망치면 끝난다.

그런데 이 책을 읽으면서는 자꾸 반대로 생각하게 됐다.

왜 이 존재가 여기까지 남아 있어야 했을까.

기록된 사람은 역사 속에서 이름을 가진다.

왕도 있고,

장군도 있고,

학자도 있다.

그런데 역사적인 사건에는 항상 이름이 남지 않은 사람이 훨씬 많다.

궁녀,

하인,

백성,

여성,

패배한 쪽 사람,

죄인의 가족.

기록을 남길 권한도 없었고 누군가 기록해주지도 않았던 사람들이다.

그러다 보니 이 책에서 나타나는 이상현상은 단순한 초자연 현상이라기보다

“나도 여기 있었다.”

라는 흔적처럼 보이기 시작한다.

그렇게 생각하고 나면 귀신 이야기가 조금 슬퍼진다.

한국 괴담이 유독 무서울 때가 있다

서양의 괴물 이야기와 한국 괴담은 무서운 지점이 조금 다르다고 생각한다.

한국 괴담에는 유독 장소와 과거가 많이 붙는다.

이 집에서 옛날에 사람이 죽었다.

이 산에서 전쟁 때 무슨 일이 있었다.

이 연못에 누군가 빠져 죽었다.

저 건물은 일제강점기에 이런 곳이었다.

사건이 끝나도 장소가 남아 있다.

그리고 사람이 그 위에서 다시 살아간다.

몇십 년, 몇백 년이 지나면 원래 무슨 일이 있었는지도 잊는다.

그런데 장소는 그대로다.

《한국사 이상현상 연구원》이 영리한 건 그 익숙한 한국식 공포를 역사 기록과 연결한 것이라고 생각한다.

뭔가 갑자기 튀어나오는 것보다

“이곳에서 실제로 이런 일이 있었을 수도 있겠다.”

라는 생각이 들 때 훨씬 기분이 이상하다.

가장 재미있는 건 독자가 직접 조사하는 느낌이다

문서 형식으로 쓰였다는 게 단순한 디자인은 아니다.

정보가 한 번에 정리돼서 나오지 않는다.

보고서에는 이렇게 적혀 있는데,

녹취록에서는 조금 다르고,

다른 기록을 보면 앞에서 읽었던 내용이 다시 이상해진다.

그러면 자연스럽게 앞장을 다시 보게 된다.

“잠깐, 아까 이 사람이 뭐라고 했지?”

이런 일이 생긴다.

독자가 구경하는 위치에서 조금 벗어난다.

마치 연구원에 막 들어온 신입 직원처럼 문서들을 조합해서 사건을 이해하게 된다.

그래서 분량이 상당한데도 의외로 잘 넘어간다.

짧은 자료 하나 읽고,

다음 기록을 보고,

또 다른 사건을 확인하다 보면 계속 다음 페이지를 보게 된다.

이런 형식의 소설을 좋아한다면 상당히 재미있을 것이다.

반대로 감정에 바로 들어가기는 조금 어렵다

장점이 분명하면 단점도 거기에서 나온다.

일반적인 소설은 특정 인물을 오래 따라가기 때문에 그 사람에게 감정이 붙는다.

그런데 기록과 보고서가 중심이 되면 조금 거리가 생긴다.

누군가 죽었어도

“이 인물이 죽었다.”

보다는

“이 사건에서 사망자가 발생했다.”

같은 감각으로 먼저 들어오는 순간이 있다.

처음에는 조금 차갑게 느껴졌다.

그런데 계속 읽다 보니 이것도 의도처럼 느껴졌다.

역사가 사람을 기록하는 방식과 비슷하기 때문이다.

한 사람에게는 인생 전체였던 일이 기록에서는 한 문장이 된다.

그래서 책의 차가운 형식과 그 안의 슬픈 이야기가 묘하게 부딪친다.

오히려 뒤로 갈수록 그 차이가 더 마음에 남았다.

기록은 정말 사실일까

책을 읽으면서 또 하나 생각하게 된 게 있다.

우리는 역사책에 적힌 것을 사실이라고 받아들인다.

물론 역사 연구는 기록과 사료를 바탕으로 이루어진다.

그런데 기록은 누가 남긴 걸까.

누가 쓸 수 있었고,

누구의 이야기는 중요하다고 판단됐으며,

누구의 이야기는 기록할 가치가 없다고 생각했을까.

기록에 없다는 건 존재하지 않았다는 뜻이 아니다.

이 책은 그 단순한 사실을 괴담이라는 장르로 꽤 재미있게 건드린다.

역사에서 사라진 사람이 귀신이 되어 돌아온다는 설정은 생각해보면 아주 직관적이다.

살아 있을 때 목소리를 남기지 못했으니 죽어서라도 흔적을 남긴다.

나는 이 지점부터 이 책의 제목도 조금 다르게 보였다.

‘이상현상’을 연구하는 곳인데 사실은 사람을 연구하는 곳 같다

처음에는 당연히 초자연 현상을 연구하는 기관이라고 생각한다.

그런데 사건을 하나씩 따라갈수록 이상현상의 원인을 찾는 과정은 결국 과거의 사람을 찾는 일이 된다.

누가 여기에서 살았는가.

누가 죽었는가.

왜 죽었는가.

왜 기록되지 않았는가.

그러니까 연구원이 하는 일은 괴물을 찾아내는 일이면서 동시에 기억에서 지워진 사람을 다시 찾아내는 일이 된다.

이게 참 재미있는 설정이었다.

괴담을 해결하려면 역사를 알아야 한다.

역사를 알려면 기록을 봐야 한다.

그런데 기록만 믿으면 다시 중요한 걸 놓친다.

결국 기록 밖까지 봐야 한다.

이 구조가 꽤 잘 만들어져 있다.

무서웠다가 어느 순간 조금 슬퍼진다

괴담집을 읽다 보면 보통 가장 무서웠던 에피소드가 무엇인지 이야기하게 된다.

그런데 《한국사 이상현상 연구원》은 조금 달랐다.

무서웠던 장면보다

왜 그런 일이 생겼는지를 알게 되는 순간

이 더 오래 남았다.

공포의 정체가 밝혀지면 덜 무서워져야 정상이다.

그런데 이 책에서는 정체를 알고 나면 오히려 마음이 무거워지는 이야기가 있다.

귀신에게 사연을 하나 붙여서 억지로 울리려는 방식하고도 조금 다르다.

그냥 과거의 삶을 따라가다 보면

“아, 그래서 이게 남아 있었구나.”

싶어진다.

그 순간 공포가 애도로 조금 바뀐다.

책 소개에서 이 작품을 ‘잊힌 존재들을 위한 애도’라고 표현하는 이유도 읽다 보면 이해된다.

역사에 이름을 남긴 사람보다 이름이 없던 사람들이 더 많다

생각해 보면 당연한 이야기다.

우리가 아는 역사 인물은 극히 일부다.

왕 몇 명,

장군 몇 명,

정치가 몇 명,

유명한 학자 몇 명.

하지만 그 시대를 실제로 살았던 사람은 수백만 명이었다.

대부분은 이름조차 남아 있지 않다.

그 사람들이라고 사랑하지 않았을 리 없고,

억울하지 않았을 리 없고,

살고 싶지 않았을 리 없다.

《한국사 이상현상 연구원》은 그 당연한 사실을 계속 떠올리게 한다.

그래서 역사 이야기를 읽고 있는데 역사 속 유명 인물보다 기록되지 않은 사람들 쪽으로 자꾸 눈이 간다.

괴담을 읽으면서 이런 생각을 하게 될 거라고는 예상하지 못했다.

결국 가장 무서운 건 잊히는 것인지도 모른다

책을 다 읽고 나서 제목을 다시 봤다.

《한국사 이상현상 연구원》.

처음에는 제목 그대로였다.

한국사 속 이상현상을 연구하는 곳.

그런데 다 읽고 나면 이상현상보다 ‘한국사’ 쪽이 훨씬 크게 보인다.

역사는 지나간 일을 기록한다.

하지만 모든 것을 기록하지는 못한다.

그리고 기록되지 않은 사람은 시간이 지나면 정말 없었던 사람처럼 된다.

이 소설에서는 그 사람들이 이상현상이 되어 다시 나타난다.

그걸 무섭다고 해야 할지, 슬프다고 해야 할지 조금 애매했다.

처음에는 귀신을 찾으려고 책을 펼쳤는데 마지막에는 사람을 찾고 있었다.

나는 그 변화가 이 책에서 가장 좋았다.

한국사를 아주 잘 알아야 읽을 수 있는 책도 아니다.

오히려 읽다가 궁금해져서 실제 사건이나 시대를 찾아보게 되는 쪽에 가깝다.

그래서 한국사에 관심이 있는 사람뿐 아니라 괴담이나 SCP, 아카이브 형식의 미스터리를 좋아하는 사람에게도 재미있을 것 같다.

다만 진짜 장점은 설정 자체보다 그 설정을 어디까지 끌고 갔느냐에 있다.

왜 과거의 사람들은 아직도 현재에 남아 있는가.

소설은 그 질문에 귀신이라는 답을 내놓은 것처럼 보인다.

그런데 조금 더 생각하면 다른 답도 가능하다.

기억하는 사람이 있는 동안 과거는 완전히 끝나지 않는다.

반대로 아무도 기억하지 않는 순간 한 사람의 삶은 정말 사라진다.

그래서 이 책에서 가장 무서웠던 건 괴물이 아니었다.

분명 살았는데 아무 기록에도 남지 않는 것.

그게 이상하게 가장 오래 남았다.

책 정보

제목: 《한국사 이상현상 연구원》
저자: 최인서
출판사: 다이브
출간: 2026년 8월 31일
분량: 500쪽
장르: 한국형 아카이브 미스터리·괴담
탐사 지침서, 사건 보고서, 음성 녹취록, 면담 기록, 채팅 등 여러 기록 형식을 이용해 이야기가 진행된다.

한 줄 감상

귀신을 조사하는 이야기인 줄 알았는데, 결국 역사에서 이름을 잃어버린 사람들을 찾아가는 이야기였다.

※ 서지 정보와 작품의 공식 설정은 출판·서점 공개 자료를 확인해 작성했다.

《오디세이》 리뷰 — 전쟁은 끝났는데, 왜 그는 집에 돌아갈 수 없었을까

ekyu — Fri, 2 Oct 2026 13:47:24 +0900

《오디세이》 리뷰 — 전쟁은 끝났는데, 왜 그는 집에 돌아갈 수 없었을까

※ 영화의 주요 설정과 장면에 대한 이야기가 있습니다. 결말을 직접 풀어놓지는 않지만, 영화가 무엇을 말하려 하는지는 꽤 깊게 다룹니다.

《오디세이》를 보기 전에는 당연히 거대한 모험 영화를 예상했다.

트로이 전쟁이 있고, 바다가 있고, 괴물이 나오고, 신들이 인간을 가지고 논다. 무엇보다 크리스토퍼 놀란이 IMAX로 찍은 그리스 신화라니. 이것만으로도 볼 이유는 충분했다.

실제로 볼거리도 엄청나다.

그런데 영화를 다 보고 나서 이상하게 가장 먼저 생각난 건 키클롭스도, 바다도, 전쟁 장면도 아니었다.

오디세우스의 얼굴이었다.

집에 돌아가겠다는 사람의 얼굴인데, 시간이 갈수록 정말 저 사람이 집에 돌아갈 수 있을까 싶어진다.

길을 몰라서가 아니다.

그가 지나온 길에 너무 많은 사람이 죽었고, 자신도 그 죽음에서 자유롭지 않기 때문이다.

그래서 내가 본 놀란의 《오디세이》는 모험담보다는 훨씬 더 전쟁과 업보, 그리고 상처 입은 사람이 다시 집으로 돌아가는 이야기에 가까웠다.

전쟁에서 이겼다고 끝난 게 아니었다

트로이 전쟁은 그리스군의 승리로 끝난다.

오디세우스는 그 승리에 결정적인 역할을 한 사람이다.

트로이 목마.

역사상 가장 유명한 계략 중 하나이고, 보통 이야기에서는 오디세우스의 지혜를 보여주는 장면이다.

그런데 놀란은 그 승리를 꽤 이상하게 바라본다.

분명 이겼는데 전혀 통쾌하지 않다.

도시는 무너지고,

사람들은 죽고,

승리한 병사들의 얼굴에서도 승리자의 기쁨이 잘 느껴지지 않는다.

특히 오디세우스에게 트로이 목마는 자신의 위대한 업적이라기보다 이후 평생 따라다니는 어떤 시작점처럼 보인다.

전쟁에서 살아남았지만, 그 전쟁에서 자신이 한 일까지 살아남아 버린 것이다.

이게 중요했다.

놀란은 전쟁의 승패보다 전쟁이 끝난 다음에 무엇이 남는지를 더 오래 본다.

어쩌면 오디세우스의 긴 여행은 벌이었을지도 모른다

원래 《오디세이》에는 신들의 분노가 있다.

인간이 신에게 잘못하고,

오만해지고,

그 대가를 치른다.

그런데 놀란의 영화에서는 그걸 조금 다르게 볼 수도 있었다.

괴물이 나타나고,

배가 부서지고,

동료들이 죽고,

집으로 가려 할수록 계속 다른 곳으로 밀려난다.

겉으로 보면 신이 내리는 벌이다.

그런데 영화를 보고 있으면 어느 순간 이런 생각이 든다.

정말 신들이 오디세우스를 집에 보내주지 않는 걸까.

아니면 오디세우스 자신이 아직 돌아갈 수 없는 사람인 걸까.

전쟁에서 저지른 일,

자신의 판단 때문에 죽은 사람,

살아남기 위해 버렸던 사람,

자기가 내린 명령.

그런 것이 하나씩 따라붙는다.

그래서 영화의 괴물들도 단순한 퀘스트처럼 보이지 않았다.

오디세우스가 하나를 쓰러뜨리면 레벨이 올라가고 다음 스테이지로 넘어가는 모험이 아니다.

계속 무언가를 잃는다.

사람을 잃고,

자신감을 잃고,

전쟁 영웅이라는 자기 이미지도 조금씩 무너진다.

집에 가까워지는 대신, 오디세우스라는 사람이 하나씩 벗겨진다.

놀란이 보고 싶었던 건 ‘영웅의 업보’였던 것 같다

이 영화의 오디세우스는 전형적인 영웅과 조금 다르다.

용감하고 머리가 좋고 위기에서 빠져나오는 능력도 있다.

그런데 그 능력이 항상 좋은 결과만 만드는 것은 아니다.

어떤 순간에는 그의 지혜가 사람들을 살린다.

다른 순간에는 바로 그 자신감 때문에 누군가가 죽는다.

이게 상당히 놀란다운 부분이었다.

놀란 영화의 주인공들은 능력이 뛰어난 경우가 많다.

그런데 능력이 뛰어나다는 이유로 행복해지는 사람은 별로 없다.

오히려 자기가 한 선택의 결과를 짊어지고 산다.

《오펜하이머》가 가장 직접적이었다.

자신의 능력으로 불가능했던 일을 해낸 사람이 나중에는 그 성공 자체에서 벗어나지 못한다.

《오디세이》의 오디세우스도 비슷하게 보였다.

트로이를 무너뜨린 천재적인 전략가.

그런데 그 전략의 결과까지 자신에게서 떼어낼 수는 없다.

그래서 이 영화에서 업보는 신비한 힘이라기보다 훨씬 현실적인 의미로 느껴졌다.

자기가 한 일이 결국 자기 삶으로 돌아오는 것.

피할 수는 있어도 없었던 일로 만들 수는 없는 것.

가장 무서운 건 괴물이 아니라 살아남았다는 사실이다

오디세우스는 계속 살아남는다.

모험 영화라면 당연한 일이다.

주인공이니까.

그런데 영화가 진행될수록 그 생존이 축복인지 알 수 없어진다.

옆에 있던 사람들이 계속 사라진다.

처음에는 함께 집으로 돌아가자던 사람들이 하나씩 줄어든다.

그리고 결국 살아남은 사람에게는 이상한 문제가 생긴다.

왜 나는 살아남았지?

전쟁을 경험한 사람들에게서 이야기되는 생존자의 죄책감과도 닿아 있다.

전쟁터에서 살아남았다는 사실이 항상 기쁜 일만은 아니다.

친구가 죽고 내가 살아남았다면,

내 명령 때문에 누군가 죽었다면,

내가 조금 다르게 판단했다면 그 사람이 살 수도 있었다고 생각한다면,

전쟁은 끝났어도 머릿속에서는 계속된다.

그래서 오디세우스에게 바다는 단순히 집으로 가는 길처럼 보이지 않았다.

전쟁과 고향 사이에 놓인 굉장히 긴 완충지대처럼 보였다.

몸은 전쟁터를 떠났는데 전쟁은 아직 몸 안에 있다

나는 이게 놀란이 《오디세이》를 지금 다시 만든 가장 흥미로운 이유라고 느꼈다.

트로이 전쟁이 끝났다.

그런데 오디세우스에게 전쟁은 끝나지 않았다.

전쟁터에서 살아남는 방법과 집에서 살아가는 방법은 완전히 다르다.

전쟁에서는 의심해야 한다.

먼저 공격해야 할 수도 있고,

사람을 속여야 할 수도 있고,

때로는 누군가를 희생시켜야 전체가 산다.

그런 방식으로 10년을 산 사람이 어느 날 집에 도착했다고 해서 갑자기 남편과 아버지로 돌아갈 수 있을까.

나는 오히려 불가능에 가까울 것 같다.

그래서 영화 속 긴 방황이 단순히 물리적인 여행만으로 보이지 않았다.

오디세우스에게는 전쟁에서 평범한 삶으로 돌아오기 위해 필요한 시간이었던 것 같다.

그런데 그 시간이 무려 10년이다.

전쟁도 10년.

귀환도 10년.

전쟁을 치르는 것만큼이나 전쟁에서 빠져나오는 데 오래 걸린 셈이다.

그래서 칼립소의 시간이 다르게 보였다

오디세우스의 여정 중에는 앞으로 나아가는 것 같지 않은 시간이 있다.

특히 칼립소와 함께 보내는 긴 시간은 일반적인 모험 영화의 속도로 보면 이상하다.

집에 간다면서 왜 여기에서 이렇게 오래 머물지?

그런데 이 영화를 전쟁의 상처라는 쪽에서 보면 다르게 보인다.

어쩌면 오디세우스에게는 그 시간이 필요했을지도 모른다.

아직 집으로 돌아갈 준비가 되어 있지 않았기 때문이다.

집에 가고 싶다는 것과

집으로 돌아갈 수 있는 상태라는 것은 다르다.

몸은 이타카를 원한다.

마음은 페넬로페를 원한다.

그런데 그 사람은 아직 전쟁터에 있다.

나는 영화가 그 차이를 꽤 중요하게 보고 있다고 느꼈다.

귀환이라는 말이 이렇게 어려운 말이었나 싶었다

《오디세이》를 흔히 집으로 돌아가는 이야기라고 한다.

그런데 영화를 보고 나니 ‘돌아간다’는 말이 생각보다 어렵다.

집이라는 장소에 도착하면 귀환이 끝나는 걸까.

10년 전에 떠났던 사람과 지금 돌아온 사람이 완전히 다른데도?

집도 그대로 있지 않다.

페넬로페는 기다리는 동안 자기 시간을 살았다.

텔레마코스는 아버지가 없는 상태에서 자랐다.

오디세우스가 기억하는 가족과 지금 존재하는 가족은 다르다.

여기서 놀란이 오래 이야기해 온 주제가 다시 나온다.

시간이다.

떠났던 사람에게도 시간이 흘렀지만,

기다리는 사람에게도 똑같이 시간이 흘렀다.

그래서 귀환은 시간을 되돌리는 일이 아니다.

떠나기 전으로 돌아갈 수는 없다.

그냥 변한 사람들이 다시 만나는 것이다.

페넬로페는 단순히 기다리는 사람이 아니었다

오디세우스의 여정을 이야기하면 대부분 오디세우스만 본다.

괴물을 만나고,

신들과 싸우고,

바다를 건너기 때문이다.

그런데 집에서 기다리는 사람에게도 20년은 똑같은 20년이다.

페넬로페에게 오디세우스는 남편이지만, 어느 순간부터는 기억에 가까운 사람이었을 수도 있다.

살아 있는지 죽었는지도 모른다.

언젠가 돌아올 거라고 믿으며 살아야 하지만 자기 삶 역시 계속된다.

그래서 두 사람이 다시 만나는 일은 우리가 흔히 생각하는 낭만적인 재회보다 훨씬 복잡하다.

20년 전 사랑했던 사람과 지금 눈앞에 있는 사람이 정말 같은 사람인가.

오디세우스도 변했고,

페넬로페도 변했다.

그런데 그래도 다시 서로를 알아볼 수 있는가.

나는 이 질문이 영화 후반부의 거대한 액션보다 더 좋았다.

결국 귀환은 집으로 돌아오는 게 아니라 인간으로 돌아오는 과정이었다

영화 초반의 오디세우스는 전쟁 영웅이다.

전략가이고,

왕이고,

사람들을 지휘하는 사람이다.

하지만 여행이 길어질수록 그런 것들이 하나씩 사라진다.

배도 잃고,

병사도 잃고,

권위도 잃는다.

결국 남는 건 집에 돌아가고 싶은 한 사람이다.

그래서 나는 《오디세이》의 진짜 목적지가 이타카만은 아니라고 생각했다.

오디세우스가 전쟁 영웅에서 다시 사람으로 돌아가는 것.

그게 이 여행의 진짜 끝 아닐까.

전쟁은 사람에게 굉장히 단순한 기준을 준다.

적과 아군.

승리와 패배.

생존과 죽음.

하지만 평범한 삶은 그렇게 단순하지 않다.

남편이 되고,

아버지가 되고,

사랑했던 사람 앞에 다시 서야 한다.

어쩌면 괴물을 상대하는 것보다 이쪽이 더 어려웠을 수도 있다.

그런데 돌아왔다고 모든 것이 없던 일이 되는 건 아니다

여기서 영화가 마음에 들었던 부분이 있다.

귀환을 구원처럼 쉽게 사용하지 않는다.

집에 돌아왔다.

가족을 만났다.

그러면 모든 상처가 치료된다.

이렇게 끝내버리면 편했을 것이다.

그런데 사람은 그렇게 쉽게 리셋되지 않는다.

트로이에서 죽은 사람들이 살아 돌아오는 것도 아니다.

오디세우스의 동료들도 마찬가지다.

그가 가족과 다시 살아갈 수 있다고 해도 자신이 지나온 일을 지울 수는 없다.

그래서 귀환과 속죄는 같은 말이 아니다.

집에 돌아갈 자격을 얻었다고 해서 죄가 사라지는 것도 아니다.

나는 놀란이 이 부분에서 꽤 냉정했다고 느꼈다.

사람은 자기 삶을 다시 시작할 수 있다.

하지만 과거를 삭제한 상태로 다시 시작할 수는 없다.

결국 가지고 가야 한다.

‘업보’라는 말을 계속 떠올리게 된 이유

영화를 보고 나오면서 자꾸 업보라는 단어가 생각났다.

종교적인 의미의 벌만 이야기하는 건 아니다.

좀 더 단순하다.

내가 한 행동에는 결과가 있다.

그리고 그 결과는 내가 원한다고 끝나는 것이 아니다.

트로이 전쟁은 끝났다.

승자도 결정됐다.

그러면 이제 끝이라고 생각할 수 있다.

그런데 《오디세이》는 오히려 거기서 시작한다.

전쟁이 끝난 다음 사람들이 어떻게 살아가는지.

승리한 사람이 무엇을 가지고 집으로 돌아오는지.

죽은 사람은 어떻게 살아남은 사람 안에서 계속 존재하는지.

그걸 보여준다.

그래서 이 영화에서 신들의 저주는 어쩌면 업보를 이해하기 쉽게 만든 신화적인 표현인지도 모르겠다.

현대적으로 말하면 기억이고,

죄책감이고,

트라우마다.

괴물보다 훨씬 오래 따라오는 것들이다.

《오펜하이머》 다음이 《오디세이》라는 것도 재미있었다

두 영화를 직접 이어진 작품처럼 볼 필요는 없다.

그런데 나는 자연스럽게 연결됐다.

《오펜하이머》는 엄청난 일을 해낸 사람의 이야기였다.

전쟁을 끝내기 위한 무기를 만들었고,

그 성공 이후부터 오히려 진짜 문제가 시작된다.

《오디세이》도 비슷하다.

오디세우스는 트로이를 무너뜨렸다.

역사에 남을 승리를 만들었다.

그런데 승리 뒤에 남는 질문은 같다.

그래서 당신은 자신이 한 일과 어떻게 살아갈 것인가.

놀란은 영웅의 성공 자체보다 성공하고 난 뒤 그 사람이 어떻게 되는지에 더 관심이 있는 감독처럼 보인다.

오펜하이머에게 원자폭탄이 있었다면,

오디세우스에게는 트로이 목마가 있다.

둘 다 뛰어난 두뇌가 만든 승리이고,

둘 다 그 승리를 만든 사람에게서 쉽게 떨어지지 않는다.

이렇게 놓고 보면 놀란이 왜 《오펜하이머》 다음 영화로 3천 년 전의 이야기를 선택했는지도 조금 이해되는 것 같았다.

놀란이 결국 계속 찍고 있는 건 ‘집에 돌아가려는 사람’인지도 모른다

생각해보면 놀란 영화에는 집으로 돌아가려는 사람이 많다.

《인셉션》의 코브도 그랬고,

《인터스텔라》의 쿠퍼도 그렇다.

《덩케르크》는 말 그대로 살아서 고향으로 돌아가는 이야기다.

그런데 《오디세이》에서는 그 주제가 가장 원형에 가까운 모습으로 나온다.

가족이 있고,

떠난 남자가 있고,

아들이 기다리고,

시간이 흐르고,

남자는 어떻게든 집에 돌아가려고 한다.

놀란은 이 영화를 두고 가족, 사랑, 전쟁, 죽음과 귀환이 모두 들어 있는 이야기라고 설명했다. 특히 자신 역시 일 때문에 가족과 떨어져 있는 시간이 생기면서 ‘돌아가고 싶은 마음’과 떨어져 있는 동안 잃어버리는 시간에 대해 생각한다고 이야기한 적이 있다. :chatgpt-content-reference{index="0"}

그래서 《오디세이》가 놀란에게 단순히 유명한 고전을 영화화한 작품만은 아니었다는 생각이 든다.

어쩌면 지금까지 자신이 계속 변주해서 만들던 이야기를 원형까지 거슬러 올라가 다시 찍은 영화에 가깝다.

볼거리는 엄청났지만, 내가 더 좋았던 건 그 뒤에 있는 이야기였다

물론 영화적인 스케일만 놓고 봐도 대단하다.

바다가 정말 바다처럼 무섭고,

사람이 자연 앞에서 작게 보이는 순간들이 많다.

전쟁도 멋있게 찍었다기보다 육체적으로 힘든 일처럼 느껴진다.

신화 속 괴물들 역시 너무 깨끗한 판타지 생물처럼 보이지 않는 게 좋았다.

그런데 나에게는 그런 장면들이 영화의 핵심은 아니었다.

괴물 하나하나가 오디세우스에게 남은 전쟁의 흔적처럼 보이기 시작하면서 영화가 훨씬 재미있어졌다.

그래서 《오디세이》를 단순한 신화 어드벤처로 보면 꽤 다른 영화가 된다.

전쟁은 끝났는데 전쟁에서 돌아오지 못한 사람.

자기가 만든 승리의 대가를 치르는 사람.

동료들을 잃고 혼자 살아남은 사람.

그리고 그 모든 것을 가지고도 다시 가족에게 돌아가려고 하는 사람.

나는 그 이야기가 더 좋았다.

집에 돌아온다고 예전 사람이 되는 건 아니다

영화를 보고 가장 오래 남은 생각은 이거였다.

우리는 흔히 힘든 일을 겪은 사람에게

“이제 다 끝났어.”

라고 말한다.

전쟁이 끝났고,

수술이 끝났고,

사건이 끝났고,

집으로 돌아왔다.

그런데 실제 사람에게는 그때부터 시작되는 시간이 있을 수도 있다.

오디세우스의 10년 귀환도 그런 시간처럼 보였다.

전쟁터에서 집까지 가는 데 10년이 걸린 게 아니라,

전쟁을 자기 안에서 빠져나오는 데 10년이 걸린 것.

그래서 이 영화의 마지막에 중요한 건 오디세우스가 정말 이타카에 도착했느냐만은 아니었다.

그 사람이 어떤 모습으로 돌아왔느냐였다.

전쟁 전의 오디세우스는 다시 돌아오지 않는다.

그럴 수도 없다.

대신 모든 걸 겪은 사람이 돌아온다.

상처도 가지고,

죄책감도 가지고,

자기가 잃어버린 사람들의 기억도 가지고.

그래도 돌아온다.

나는 그게 《오디세이》에서 말하는 귀환이라고 생각했다.

과거를 없애고 집에 들어가는 게 아니라,

과거를 짊어진 상태로 다시 살아보기로 하는 것.

놀란이 이 거대한 신화를 가지고 결국 하고 싶었던 이야기도 거기에 있지 않았을까.

엄청난 전쟁도,

신들의 저주도,

괴물도 결국 지나간다.

마지막에 남는 건 아주 오래된 질문 하나다.

상처 입고 잘못도 저지른 사람이 다시 집으로 돌아가 살아갈 수 있는가.

《오디세이》는 그 질문에 쉽게 용서도, 쉽게 구원도 주지 않는다.

그래서 좋았다.

조금만 더 감정을 밀어붙였으면 내게는 완벽한 작품이 됐을 것 같다는 아쉬움은 남는다. 그래도 거대한 신화와 액션을 보여주면서 그 안에 전쟁 이후의 인간을 끝까지 놓치지 않았다는 점에서 충분히 오래 기억에 남을 영화였다.

내 기준으로는 ★★★★☆ 4.5점 / 5점.

《더 드라마》 리뷰 — 사랑한 건 그 사람일까, 내가 알고 있다고 믿었던 사람일까

ekyu — Fri, 2 Oct 2026 13:40:20 +0900

《더 드라마》 리뷰 — 사랑한 건 그 사람일까, 내가 알고 있다고 믿었던 사람일까

※ 영화의 핵심 설정을 다룹니다. 이 작품은 중간에 드러나는 사실 자체가 중요한 영화라, 아직 보지 않았다면 먼저 영화를 보는 편을 권합니다.

처음에는 꽤 익숙한 영화처럼 시작한다.

결혼을 앞둔 커플이 있고, 둘은 잘 어울린다. 만나게 된 과정도 영화 같고, 결혼식 준비도 순조롭다. 찰리와 엠마를 보고 있으면 특별히 큰 문제가 생길 것 같지 않다.

물론 이런 영화에서 아무 일도 일어나지 않을 리는 없다.

친구들과 술을 마시면서 시작한 별것 아닌 대화 하나가 모든 걸 바꾼다.

“살면서 가장 끔찍했던 일이 뭐야?”

처음에는 웃으면서 이야기할 수 있는 정도다. 누군가는 어릴 때 다른 사람에게 못된 짓을 했고, 누군가는 비겁했던 순간을 이야기한다.

그러다 엠마의 차례가 온다.

그리고 분위기가 완전히 바뀐다.

여기부터 《더 드라마》는 로맨틱 코미디처럼 보였던 외피를 벗어버린다.

말하지 않은 것과 거짓말한 것은 같은 걸까

엠마가 과거에 했던 생각과 행동은 절대로 가볍게 넘길 수 있는 일이 아니다.

십대 시절 총기를 가지고 학교에서 사람들을 죽이려는 계획을 세웠고, 실제 행동으로 옮기기 직전까지 갔다.

사람이 죽지 않았다는 결과만 놓고

“아무 일도 없었잖아.”

라고 말할 수 있는 종류의 이야기는 아니다.

나는 이 부분에서는 찰리의 충격이 충분히 이해됐다.

결혼하려는 사람이 이런 과거를 평생 한 번도 이야기하지 않았다면 당황하는 게 이상하지 않다.

사랑의 문제가 아니라 안전과 신뢰의 문제로 느껴질 수도 있다.

그런데 영화가 재미있는 건 여기서 엠마를 쉽게 악인으로 만들지 않는다는 데 있다.

엠마는 지금의 삶에서 그런 행동을 하는 사람이 아니다.

오랜 시간이 흘렀다.

그렇다면 자연스럽게 다음 질문이 따라온다.

사람은 과거에 생각했던 가장 끔찍한 순간으로 평생 정의되어야 할까.

나는 여기서 쉽게 답을 내릴 수 없었다.

그런데 총기 사건만큼은 가볍게 생각하기 어려웠다

《더 드라마》에서 가장 불편했던 부분이기도 하다.

미국의 총기 사건과 학교 총격은 영화적인 충격을 만들기 위한 편리한 소재로 소비하기에는 너무 현실적인 문제다.

실제로 수많은 사람이 목숨을 잃었고, 살아남은 사람과 가족에게는 지금도 끝나지 않은 일이다.

그래서 엠마의 과거가 처음 공개됐을 때 나 역시 찰리와 비슷한 쪽으로 마음이 움직였다.

“이걸 정말 아무 일도 없었던 것으로 봐도 되는 건가?”

그런데 영화가 조금 더 어려운 질문을 던진다.

엠마는 실제로 사람을 죽이지 않았다.

그렇다면 우리는 행동하지 않은 생각까지 어느 정도 처벌해야 하는가.

반대로 실제 행동으로 이어지지 않았다는 이유만으로 그 위험성을 모두 지워도 되는가.

둘 다 쉽게 선택하기 어렵다.

그래서 나는 이 영화의 총기 설정이 단순한 반전 장치라고만 생각하지 않았다.

오히려 불편할 정도로 큰 사건을 가운데 던져놓고, 관객에게 어느 선까지 용서할 수 있는지를 묻는 것에 가깝게 느껴졌다.

다만 이런 소재를 선택한 이상 더 조심스럽게 다뤘어야 하는 부분도 있다고 생각한다.

실제 총기 폭력의 무게가 너무 크기 때문이다.

영화가 던지는 질문은 흥미롭지만 그 질문을 가능하게 하기 위해 학교 총격이라는 현실적인 비극을 가져왔다는 점은 영화를 다 보고 난 뒤에도 조금 마음에 걸렸다.

로버트 패틴슨이 찰리를 너무 잘 만든다

처음의 찰리는 꽤 괜찮은 남자처럼 보인다.

조금 어색한 구석도 있지만 엠마를 좋아하고, 결혼을 기다리고 있다.

그러다 과거를 알게 된 이후 점점 무너진다.

여기서 로버트 패틴슨의 연기가 정말 좋다.

처음에는 충격이다.

그다음에는 두려움이 생기고,

조금 지나면 의심으로 바뀐다.

그리고 결국에는 엠마의 과거뿐 아니라 지금 눈앞에 있는 엠마까지 전부 다시 해석하기 시작한다.

그 과정이 굉장히 불편하다.

사람이 한번 의심하기 시작하면 상대가 하는 행동 하나하나에 의미를 붙이게 된다.

예전에 웃었던 장면도 다르게 보이고,

평범했던 말도 수상하게 들린다.

패틴슨은 그 불안이 점점 사람을 잠식하는 과정을 꽤 웃기면서도 무섭게 연기한다.

가끔 너무 우스워서 웃음이 나오는데, 웃고 나면 상황 자체는 전혀 웃기지 않다.

이런 이상한 온도가 영화와 잘 맞는다.

젠데이아는 오히려 많이 하지 않아서 좋았다

젠데이아의 엠마는 반대다.

찰리가 점점 크게 흔들리는 동안 엠마는 상대적으로 눌려 있다.

그래서 더 답답하게 느껴지는 순간도 있다.

“도대체 무슨 생각이지?”

싶다.

그런데 이 역할에서는 그게 맞는 것 같다.

엠마가 계속 울면서 자신의 과거를 설명하고 용서를 구했다면 영화가 너무 쉽게 흘렀을 것이다.

젠데이아는 표정을 크게 쓰지 않는다.

그 대신 찰리가 자신을 바라보는 방식이 달라졌다는 걸 알아차린 사람의 표정이 있다.

어제까지는 사랑하는 사람이었던 사람이 오늘부터 나를 두려워하기 시작했다.

그걸 보는 얼굴이다.

특히 영화가 진행될수록 중요한 건 과거의 엠마보다 현재의 엠마를 우리가 어떻게 바라보고 있는가라는 생각이 들었다.

젠데이아의 연기가 그 질문을 잘 버텨준다.

어쩌면 찰리가 사랑했던 건 엠마가 아니었을지도 모른다

영화를 보다 보면 어느 순간 이런 생각이 든다.

찰리는 엠마를 사랑했던 걸까.

당연히 사랑했다.

그런데 조금 더 정확하게 말하면 찰리가 알고 있는 엠마를 사랑했던 것은 아닐까.

친절하고,

매력적이고,

자신과 잘 맞고,

결혼해서 행복하게 살아갈 사람.

찰리 머릿속에는 엠마라는 사람이 이미 완성되어 있었다.

그런데 과거의 이야기가 하나 추가되는 순간 그 사람이 완전히 무너진다.

사실 현재의 엠마는 어제와 똑같다.

달라진 건 찰리가 알고 있는 정보 하나다.

그런데 사람 전체가 다르게 보인다.

이게 영화에서 가장 재미있었던 부분이다.

우리가 사랑하는 사람을 정말 있는 그대로 보고 있는지 생각하게 한다.

사실 대부분은 상대를 조금씩 자기 방식으로 정리한다.

이런 사람.

이런 성격.

이런 과거를 가진 사람.

그리고 그 설명에 맞지 않는 무언가가 나타나는 순간 당황한다.

“모든 것을 알아야 한다”는 생각도 한번 의심해볼 필요가 있다

연인 사이에는 비밀이 없어야 한다는 말을 많이 한다.

결혼한다면 더 그렇다.

나도 기본적으로는 동의한다.

그런데 《더 드라마》를 보고 있으면 조금 이상한 질문이 생긴다.

사랑하는 사람의 모든 것을 알아야 할 권리가 정말 나에게 있을까.

아주 위험한 과거라면 이야기가 달라질 수 있다.

그렇다고 해서 사람이 살아온 모든 생각과 모든 잘못을 연인에게 제출해야 하는 것도 이상하다.

누구에게나 말하고 싶지 않은 시절이 있다.

지금의 나와는 너무 달라서 다시 들여다보고 싶지 않은 모습도 있다.

어디까지 알려야 하고 어디부터 개인의 과거로 남겨둘 수 있는지.

영화는 그 경계를 아주 극단적인 사건으로 시험한다.

그래서 생각할 거리가 많아진다.

친구들이 보이는 반응도 꽤 중요하다

엠마의 고백 이후 친구들의 분위기도 순식간에 달라진다.

조금 전까지 같이 웃고 있던 사람이 갑자기 완전히 다른 사람이 된다.

이 부분이 꽤 현실적이었다.

우리는 사람을 판단할 때 현재의 모습만 보는 것 같지만 실제로는 그렇지 않다.

새로운 정보를 하나 알게 되면 이전 행동까지 전부 다시 해석한다.

“그러고 보니 그때도 좀 이상했어.”

“원래 그런 사람이었나 봐.”

이런 식이다.

사람 한 명에 대한 이야기가 순식간에 다시 작성된다.

그리고 그때부터 사실보다 이야기가 더 강해질 때가 있다.

크리스토퍼 보글리 감독은 역시 사람의 불편한 부분을 잘 건드린다

《드림 시나리오》에서도 그랬지만 크리스토퍼 보글리는 사람들이 남을 바라보고 판단하는 순간을 꽤 짓궂게 건드리는 감독이다.

이번에도 누구에게 감정을 맡겨야 하는지 쉽게 정해주지 않는다.

찰리에게 공감하고 있으면 어느 순간 찰리가 불편해지고,

엠마를 이해하려고 하면 과거의 행동이 다시 걸린다.

그렇다고 둘 다 잘못했다고 가운데 서 있으면 되는 영화도 아니다.

보글리는 계속 관객을 한쪽으로 밀었다가 다시 당긴다.

무엇보다 로맨틱 코미디의 모양으로 시작한 것도 꽤 영리했다.

영화 초반의 둘은 정말 영화 속 커플처럼 보인다.

만나는 과정부터 결혼 준비까지 너무 잘 만들어진 이야기 같다.

그래서 과거가 공개되는 순간 단순히 두 사람의 관계만 무너지는 게 아니라 우리가 보고 있던 영화 장르 자체가 무너진다.

처음에는 로맨틱 코미디였는데 어느 순간 심리 스릴러를 보고 있는 기분이 든다.

그 변화가 상당히 좋았다.

A24의 공식 소개 역시 이 작품을 결혼을 앞둔 행복한 커플에게 예상하지 못한 사건이 생기면서 관계가 시험받는 이야기로 소개한다. 크리스토퍼 보글리가 각본과 연출을 맡았고 젠데이아와 로버트 패틴슨이 두 주인공을 연기했다. :chatgpt-content-reference{index="0"}

영화가 숨겨놓은 건 결국 ‘이야기를 만드는 사람’에 대한 얘기 아닐까

나는 이 영화를 보고 나서 이 부분이 가장 재미있었다.

찰리는 엠마의 과거를 알게 된 뒤 자신의 머릿속에서 새로운 엠마를 만들어낸다.

좋은 여자였던 엠마가 어느 순간 위험한 사람이 된다.

그런데 둘 다 완전한 엠마는 아니다.

그냥 찰리가 알고 있는 정보로 만든 이야기다.

우리도 똑같다.

누군가에 대한 몇 가지 사실을 알고 나서

“아, 이 사람은 이런 사람이구나.”

라고 결론을 내린다.

영화도 그렇게 사람을 보여준다.

초반에 우리에게 완벽한 연인이라는 정보를 준다.

그러고 나서 중간에 완전히 다른 정보를 하나 던진다.

그러자 관객 역시 엠마를 다시 보기 시작한다.

결국 감독은 찰리만 시험하는 게 아니라 관객도 똑같이 시험하고 있는 셈이다.

당신은 새로운 사실 하나를 알았을 때 사람 전체를 얼마나 쉽게 다시 판단하는가.

나는 이게 《더 드라마》가 총기 사건 뒤에 숨겨놓은 더 흥미로운 이야기라고 생각했다.

그렇다고 과거를 그냥 지우자는 이야기는 아니다

여기서 조심해야 할 부분도 있다.

“사람은 변할 수 있으니 과거는 중요하지 않다.”

영화가 이런 말을 하는 것은 아니라고 생각한다.

특히 엠마의 과거는 그렇게 쉽게 정리할 수 있는 수준이 아니다.

누군가를 죽이려는 의도를 가지고 실제 준비까지 했다면, 그 위험성과 책임에 대해 गंभीर하게 생각해야 한다.

다만 영화가 묻는 건 그 다음이다.

그런 사람이 십수 년 동안 전혀 다른 삶을 살았다면 우리는 지금 그 사람을 어떻게 봐야 하는가.

사람에게 과거에서 벗어날 가능성은 존재하는가.

없다면 인간은 가장 나빴던 순간으로 평생 살아야 한다.

있다면 어디까지 허용해야 하는가.

영화가 여기에서 명확한 답을 내리지 않는 게 좋았다.

이건 간단하게 답할 수 있는 문제가 아니니까.

제목이 왜 《더 드라마》인지도 나중에는 재미있어진다

처음에는 단순히 결혼을 앞두고 엄청난 ‘드라마’가 벌어진다는 의미처럼 보였다.

그런데 다 보고 나면 조금 다르게 들린다.

사람은 자기 인생을 이야기로 만들어 살아간다.

우리가 어떻게 만났고,

왜 사랑했고,

어떤 사람이었고,

앞으로 어떤 삶을 살 것인지.

찰리와 엠마 역시 자신들의 관계를 하나의 완성된 이야기처럼 가지고 있었다.

그런데 과거의 사실 하나가 들어오자 이야기가 완전히 바뀐다.

어쩌면 관계가 무너지는 것보다 더 견디기 힘든 건 자기가 믿고 있던 이야기가 무너지는 것이었을지도 모른다.

그래서 찰리는 끊임없이 과거를 다시 해석하려고 한다.

그걸 이해해야 자신이 지금까지 살아온 이야기도 다시 정리할 수 있으니까.

배우 둘을 보는 것만으로도 충분히 재미있었다

영화의 주제에 동의하느냐와 별개로 배우들은 정말 좋았다.

로버트 패틴슨은 불안, 비겁함, 사랑, 분노가 뒤엉킨 사람을 우스꽝스럽게 만들면서도 완전히 희화화하지 않는다.

젠데이아는 훨씬 어려운 역할을 맡았다.

관객이 쉽게 이해해서도 안 되고, 그렇다고 완전히 멀어져서도 안 되는 인물이다.

조금만 감정을 과하게 밀어붙였으면 영화가 엠마의 편을 들거나 반대로 비난하는 것처럼 보였을 텐데 그 사이를 잘 버틴다.

두 사람이 같이 있을 때 생기는 불편한 긴장도 좋다.

초반에는 정말 잘 어울리는 커플이라서 후반이 더 이상해진다.

감독의 선택 역시 마음에 들었다.

이런 주제를 처음부터 무겁고 진지한 영화로 만들었다면 오히려 너무 예상 가능한 이야기가 됐을 것 같다.

보글리는 웃기게 시작해서 사람이 웃기 어려운 곳까지 데려간다.

그 방식 때문에 영화의 호불호가 크게 갈릴 수밖에 없겠지만, 적어도 안전하게 만든 영화는 아니다.

좋았지만 마음 편하게 높은 점수를 주기는 어려웠다

《더 드라마》는 영화를 보는 동안보다 다 보고 난 뒤 이야기할 게 더 많아지는 작품이었다.

사랑하는 사람의 과거를 어디까지 알아야 하는지,

사람은 정말 변할 수 있는지,

과거의 생각과 현재의 사람을 분리할 수 있는지,

그리고 우리는 새로운 사실 하나로 타인을 얼마나 쉽게 다시 만들어버리는지.

이런 질문들이 계속 남는다.

젠데이아와 로버트 패틴슨의 연기도 좋았고, 크리스토퍼 보글리가 로맨틱 코미디를 완전히 다른 방향으로 뒤집는 방식도 마음에 들었다.

다만 학교 총격과 미국의 총기 폭력을 영화의 핵심 장치로 사용하는 선택에는 끝까지 조심스러운 마음이 남았다. 실제 비극의 크기에 비해 영화가 그 문제 자체를 충분히 깊게 바라보지 않는다고 느껴지는 순간도 있었다. 이 작품을 두고 일부 평론에서도 총기 폭력을 다루는 방식과 엠마의 심리를 얼마나 충분히 다뤘는지를 두고 평가가 갈렸다. :chatgpt-content-reference{index="1"}

그 아쉬움 때문에 완벽하다고 하기는 어렵다.

그래도 불편한 주제를 피하지 않고 던져놓은 뒤 관객이 어느 쪽에도 쉽게 서지 못하게 만드는 영화는 꽤 오랜만이었다.

특히 마지막까지 남은 건 엠마의 과거 자체보다 다른 질문이었다.

사랑하는 사람에 대해 몰랐던 사실 하나를 알게 됐을 때, 그 사람이 변한 걸까.
아니면 내가 그 사람을 바라보는 방식이 변한 걸까.

그 질문 하나만으로도 꽤 볼 만한 영화였다.

내 기준으로는 ★★★★☆ 4.5점 / 5점.

《가능한 사랑》 리뷰 — 사랑을 말하는데, 자꾸 계급이 보였다

ekyu — Mon, 28 Sep 2026 18:10:27 +0900

《가능한 사랑》 리뷰 — 사랑을 말하는데, 자꾸 계급이 보였다

※ 영화의 주요 설정과 인물에 대한 이야기가 있습니다. 결말을 직접적으로 풀지는 않지만, 영화를 보지 않았다면 일부 내용은 스포일러가 될 수 있습니다.

이창동 영화는 보고 있을 때보다 보고 난 뒤에 더 많은 이야기가 시작되는 경우가 있다.

처음에는 눈앞에 보이는 이야기를 따라간다.
그런데 며칠 지나면 그때는 별것 아닌 것 같았던 장면이 다시 생각난다.

《가능한 사랑》도 그랬다.

처음에는 두 부부 이야기라고 생각했다.

오래 함께 살아온 부부가 있고, 전혀 다른 환경에서 살아온 또 다른 부부가 있다. 서로를 만나고, 가까워지고, 상대의 삶을 들여다보면서 조금씩 균열이 생긴다.

여기까지만 보면 사랑과 부부 관계에 관한 영화다.

그런데 영화를 보고 있을수록 이상하게 사랑보다 먼저 보이는 것이 있었다.

돈이었다.

조금 더 정확하게 말하면 돈 그 자체보다는 사람이 서 있는 자리였다.

그리고 그 자리에서 무엇을 욕망할 수 있는지, 무엇을 당연하다고 생각하는지였다.

처음에는 전도연의 미옥이 답답하게 보였다

미옥을 처음 봤을 때는 자기 욕망이 별로 없는 사람처럼 보였다.

무엇을 하고 싶냐고 물어도 딱히 떠오르는 게 없다.

뭘 좋아하는지, 앞으로 무엇을 해보고 싶은지, 어떤 삶을 원하는지도 잘 드러나지 않는다.

처음에는 그게 그냥 성격이라고 생각했다.

자기주장이 강하지 않은 사람.

남편과 가정을 중심으로 오래 살아온 사람.

그런데 영화를 따라가다 보면 생각이 조금 달라진다.

미옥에게 정말 하고 싶은 것이 없었던 걸까.

아니면 오랫동안 하고 싶은 걸 생각할 필요가 없는 삶을 살았던 걸까.

이 차이가 꽤 크다.

영화 중반 이후 미옥은 조금씩 변한다.

갑자기 인생을 뒤집겠다고 선언하는 것도 아니고, 어느 날 완전히 다른 사람이 되는 것도 아니다.

그냥 하고 싶은 게 생긴다.

가보고 싶은 곳이 생기고,

해보고 싶은 게 생기고,

자기가 무엇을 원하는지 조금씩 입 밖으로 내기 시작한다.

나는 이 변화가 영화에서 상당히 중요하다고 느꼈다.

원하는 게 없던 사람이 아니라, 원할 여유가 없던 사람

흔히 사람에게 이렇게 묻는다.

“넌 뭘 하고 싶어?”

굉장히 공평한 질문처럼 들린다.

그런데 정말 공평한 질문일까.

무엇을 하고 싶은지 생각하려면 그 전에 필요한 게 꽤 많다.

시간이 있어야 하고,

돈도 어느 정도 있어야 하고,

실패해도 다시 돌아갈 곳이 있어야 하고,

무엇보다 내가 다른 삶을 선택할 수도 있다는 경험이 있어야 한다.

미옥을 보면서 이 생각이 들었다.

원하는 게 없었던 게 아니라 원하는 것을 상상할 조건이 없었던 건 아닐까.

그래서 다른 삶을 만나면서 미옥이 조금씩 변하는 과정이 단순한 자아 찾기처럼 느껴지지 않았다.

선택지가 있다는 걸 알게 된 사람이 처음으로 선택을 생각해보는 과정에 가까웠다.

이 영화에서 욕망은 굉장히 개인적인 것 같지만, 사실 계속 계급과 붙어 있다.

무엇을 원하는지도 내가 처한 환경과 무관하지 않다.

반대로 조인성의 상우에게는 많은 것이 너무 자연스럽다

상우를 보고 있으면 다른 느낌이 든다.

이 사람에게는 여유가 있다.

생활도 그렇고, 공간도 그렇고, 행동도 그렇다.

돈을 자랑하고 다니는 인물도 아니다.

오히려 자신의 부를 크게 의식하지 않는 것처럼 보인다.

그런데 그래서 더 흥미롭다.

상우에게는 자신이 가진 것이 특별한 것이 아니라 그냥 삶이다.

이게 굉장히 현실적이다.

부를 가진 사람이 매일 아침 일어나 자신의 부를 생각하며 살지는 않는다.

좋은 집에 사는 것도,

좋은 환경을 누리는 것도,

여유롭게 선택할 수 있는 것도,

어느 순간부터는 그냥 정상적인 삶이 된다.

그리고 영화는 나중에 그 부의 뿌리를 슬쩍 흔든다.

상우가 친일파의 후손이라는 사실이 드러나는 순간이다.

이걸 영화가 거대한 폭로처럼 사용하는 것도 아니다.

갑자기 상우를 악당으로 바꾸지도 않는다.

나는 그래서 더 좋았다.

친일파 후손이라는 설정이 재미있는 이유

상우가 친일파의 후손이라고 해서 상우 자신이 친일을 한 것은 아니다.

태어나기 전에 벌어진 일을 본인이 선택한 것도 아니다.

그렇다면 상우에게 책임이 있는가?

이렇게 질문하면 이야기가 금방 단순해진다.

그런데 영화가 보고 있는 건 개인의 죄책감만은 아닌 것 같다.

오히려 이런 질문에 가깝다.

그 사람이 지금 누리고 있는 삶은 어디에서 왔는가.

우리는 현재의 부를 이야기할 때 쉽게 개인의 능력을 생각한다.

성공한 사람이 노력했고,

가난한 사람은 운이 나빴거나 기회를 잡지 못했다고 생각한다.

하지만 현실의 출발선은 그렇게 깔끔하지 않다.

누군가는 자기가 만들지 않은 부를 물려받는다.

반대로 누군가는 자기가 만들지 않은 가난을 물려받는다.

그리고 몇 세대가 지나고 나면 그 과정은 사라지고 결과만 남는다.

좋은 집.

교육.

인맥.

안전한 환경.

실패해도 다시 시작할 수 있는 여유.

그때부터 그 사람에게 그 모든 것은 상속받은 특권이 아니라 그냥 일상처럼 느껴진다.

상우가 흥미로운 건 바로 이 지점이다.

악한 사람이 아니기 때문이다.

이창동은 부자를 악인으로 만들지 않는다

만약 상우가 아주 못된 인간이었다면 영화는 훨씬 쉬워졌을 것이다.

가난한 사람과 부유한 사람을 세워놓고,

한쪽은 선하고 다른 한쪽은 위선적이라고 하면 관객도 금방 편을 고를 수 있다.

그런데 《가능한 사랑》은 그런 편안함을 주지 않는다.

돈이 많은 사람도 사랑하고,

가난한 사람도 누군가를 상처 입힌다.

상처받은 사람이라고 해서 언제나 옳지 않고,

좋은 의도를 가진 사람이라고 해서 언제나 좋은 결과를 만드는 것도 아니다.

이창동 영화에서 사람을 보는 방식이 늘 그랬던 것 같다.

사회 구조는 분명히 존재한다.

그렇다고 사람을 그 구조 하나로 전부 설명하지 않는다.

그러니까 더 불편하다.

두 부부가 같은 공간에 있어도 같은 위치에 있는 것은 아니다

영화에서는 네 사람이 꽤 가까워진다.

같이 이야기하고,

같이 먹고,

서로의 삶을 들여다본다.

겉으로만 보면 관계가 평평해진 것처럼 보인다.

그런데 실제로는 그렇지 않다.

어떤 사람에게는 선택 하나가 삶 전체를 흔드는 일이고,

다른 사람에게는 그냥 여러 선택 중 하나다.

이 차이가 계속 있다.

나는 이 영화에서 계급을 가장 잘 보여주는 방식이 바로 이거라고 느꼈다.

누군가가 “우리는 계급이 다르다”고 말하지 않는다.

카메라가 부자를 보여줄 때 돈다발을 강조하지도 않는다.

그냥 어떻게 사는지를 보여준다.

그리고 옆에 다른 삶을 붙여놓는다.

그러면 차이가 알아서 보인다.

사랑이라는 말도 그래서 조금 달라진다

처음에는 《가능한 사랑》이라는 제목을 부부 관계에 관한 것으로 생각했다.

서로를 이해할 수 있는가.

오래 함께 살아온 사람을 여전히 사랑할 수 있는가.

여기에 대한 이야기라고.

물론 그것도 맞다.

그런데 영화를 보고 나면 ‘사랑’이라는 말이 조금 더 넓어지는 것 같다.

삶의 조건이 전혀 다른 사람끼리 정말 상대를 이해할 수 있을까.

이 질문이 끼어든다.

내가 평생 가져본 적 없는 고통을 가진 사람을 이해할 수 있는가.

반대로 내가 한 번도 누려보지 못한 여유 속에서 살아온 사람을 이해할 수 있는가.

여기에는 감정만으로 해결되지 않는 문제가 있다.

좋은 마음을 가지고 있다고 해서 사회적 위치까지 사라지는 것은 아니니까.

타인을 이해한다는 것도 어쩌면 특권일 수 있다

이 영화에서 계속 불편했던 것 중 하나가 이것이었다.

누군가는 다른 사람의 삶을 바라본다.

듣고,

기록하고,

이해하려고 한다.

그 행위 자체는 나쁘지 않다.

하지만 여기에는 미묘한 차이가 있다.

한쪽은 그 고통을 살아야 하는 사람이고,

한쪽은 그 고통을 바라볼 수 있는 사람이다.

이 둘은 같지 않다.

상대의 삶을 이해하고 싶어 하는 마음도 진심일 수 있다.

그런데 그 사람에게는 이해하다가 힘들면 자기 삶으로 돌아갈 수 있는 선택지가 있다.

당사자에게는 그런 선택지가 없다.

이창동은 이 차이를 꽤 집요하게 보여준다.

누군가를 이해하려는 마음조차 내가 가진 위치와 완전히 무관하지 않다는 것.

여기까지 오면 영화는 이미 단순한 부부 이야기를 한참 벗어나 있다.

미옥의 욕망과 상우의 부가 같은 이야기처럼 보였다

처음에는 전혀 다른 이야기처럼 보였다.

미옥은 하고 싶은 것을 찾아간다.

상우는 이미 많은 것을 가지고 있다.

그런데 영화를 보고 난 뒤에는 두 이야기가 붙어 보였다.

누군가는 선택하는 법을 배우고, 누군가는 선택할 수 있다는 사실 자체를 생각해본 적이 없다.

상우에게 선택은 너무 자연스럽다.

미옥에게 선택은 뒤늦게 발견한 가능성이다.

여기에서 계급이라는 것이 아주 구체적으로 느껴졌다.

단순히 통장 잔고의 차이가 아니다.

내가 무엇을 할 수 있다고 생각하는 범위 자체가 다르다.

어떤 사람은 실패해도 다시 시작할 수 있다고 생각한다.

어떤 사람은 시작해보는 것 자체를 생각하지 않는다.

그 차이가 아주 오래 쌓이면 성격처럼 보이기까지 한다.

“저 사람은 원래 욕심이 없어.”

“저 사람은 원래 도전적인 사람이야.”

하지만 정말 그 사람의 성격만으로 설명할 수 있을까.

영화는 그런 질문을 자꾸 남긴다.

보이는 이야기는 사랑인데, 밑에서는 계급이 움직인다

내가 《가능한 사랑》을 좋게 본 가장 큰 이유가 이 부분이다.

겉으로는 상당히 쉽게 따라갈 수 있다.

두 부부가 있고,

사람들이 만나고,

관계가 바뀐다.

그게 영화의 표면이다.

그런데 조금만 내려가면 욕망에 대한 이야기가 있다.

나는 무엇을 원하는가.

그 욕망은 정말 나의 것인가.

그리고 그보다 더 밑으로 내려가면 계급이 있다.

누가 선택할 수 있는가.

누가 선택할 기회를 가지고 있는가.

그리고 더 내려가면 역사까지 나온다.

지금 우리가 가진 것이 정말 지금 만들어진 것인가.

과거에 만들어진 부와 가난은 어디로 갔는가.

사라진 게 아니라 사람을 통해 계속 이어지고 있는 건 아닌가.

이렇게 한 층씩 열리는 게 이창동 영화의 재미였다.

친일의 역사를 넣은 것도 그래서 과하지 않았다

영화에서 친일파 후손이라는 이야기가 나왔을 때 처음에는 상당히 센 설정이라고 생각했다.

자칫하면 영화가 갑자기 정치적인 메시지를 설명하기 시작할 수도 있으니까.

그런데 생각해보면 이 설정이 계급 이야기의 끝에 자연스럽게 붙는다.

지금의 자산은 어디에서 왔는가.

그 질문을 따라가다 보면 한 세대 전으로 가고,

또 한 세대 전으로 간다.

그러면 결국 역사와 만난다.

현재의 사회적 위치를 현재만 보고 설명할 수 없다는 것.

나는 이 설정을 그렇게 받아들였다.

상우 개인을 심판하기 위한 장치라기보다 현재의 계급 뒤에도 역사가 있다는 표시에 가깝다.

그래서 더 찜찜하다.

개인의 잘못만 찾아내면 해결하기 쉬운데, 구조와 역사까지 가면 누구 하나를 욕하는 것으로 끝낼 수 없으니까.

영화는 결국 관객한테도 질문을 돌린다

영화를 보는 동안 나도 계속 사람들을 판단했다.

이 사람은 이렇고,

저 사람은 저렇다고.

그러다가 어느 순간 그게 조금 불편해진다.

나는 왜 미옥을 욕망 없는 사람이라고 생각했을까.

왜 상우가 누리는 생활을 처음에는 별 생각 없이 봤을까.

왜 누군가의 좋은 의도를 좋은 행동이라고 바로 연결했을까.

영화 속 사람들이 서로를 오해하는 동안 관객도 똑같은 일을 하고 있었다.

이창동은 이런 식으로 관객을 슬쩍 영화 안으로 끌어들이는 것 같다.

처음에는 남을 구경하고 있었는데,

어느 순간 내 시선이 같이 드러난다.

사랑이 가능하다는 말은 생각보다 어렵다

영화를 다 보고 나면 제목의 ‘가능한’이라는 단어가 계속 걸린다.

《사랑》이라고 하지 않았다.

《불가능한 사랑》도 아니다.

《가능한 사랑》이다.

가능하다고 단정한 것도 아니고,

불가능하다고 포기한 것도 아니다.

그래서 나는 이 제목이 좋았다.

사람 사이에는 이해할 수 없는 부분이 있다.

거기에 계급까지 다르고,

살아온 역사까지 다르다면 그 거리는 더 커진다.

그런데도 우리는 같이 살아간다.

사랑하고,

결혼하고,

친구가 되고,

남의 이야기를 듣는다.

그렇다면 정말 가능한 사랑이라는 게 있을까.

영화가 내놓은 답을 찾기보다는, 영화가 그 질문을 얼마나 복잡하게 만들어놓았는지가 더 흥미로웠다.

이 영화에서 가장 기억에 남은 건 ‘변할 수 있다는 것’이었다

영화가 끝난 뒤 이상하게 미옥이 가장 많이 생각났다.

처음의 미옥과 마지막의 미옥이 완전히 다른 사람은 아니다.

여전히 같은 사람이다.

그런데 조금 달라졌다.

자기가 원하는 것에 대해 전보다 더 많이 생각한다.

내가 하고 싶은 게 무엇인지 물어본다.

나는 그 정도의 변화가 오히려 현실적으로 느껴졌다.

사람이 어느 날 갑자기 새로운 사람이 되는 건 흔하지 않다.

대부분은

이것도 한번 해볼까.

여기도 가보고 싶다.

나는 이건 싫다.

이 정도부터 시작하니까.

그리고 어쩌면 사랑도 비슷할지 모르겠다.

누군가를 완전히 이해하게 되는 일이 아니라,

내가 그 사람을 다 알고 있다고 생각했던 마음에서 조금 벗어나는 것.

그 정도라면 가능할 수도 있겠다.

결국 이창동이 하고 싶었던 이야기는 한 가지가 아니었던 것 같다

《가능한 사랑》을 그냥 부부 영화라고 해도 틀린 말은 아니다.

계급 영화라고 해도 맞다.

욕망에 관한 영화라고 해도 맞고,

한국 사회가 무엇을 물려받았는지 이야기하는 영화라고 해도 맞을 것이다.

그게 좋았다.

하나를 설명하기 위해 다른 이야기를 희생하지 않는다.

사랑을 이야기하다가 계급이 보이고,

계급을 보고 있으면 역사가 나오고,

그 역사를 따라가다 다시 한 사람의 작은 욕망으로 돌아온다.

그리고 결국 다시 사람이다.

이창동 감독의 영화가 계속 기억에 남는 이유도 아마 이 때문일 것이다.

화면에 있는 이야기를 다 봤다고 생각했는데,

영화가 끝난 다음부터 화면에 없던 이야기가 시작된다.

《가능한 사랑》도 그랬다.

영화를 보고 나온 직후보다 시간이 조금 지난 뒤 더 좋아졌다.

처음에는 두 부부를 보고 있었고,

조금 지나서는 그들의 돈과 환경을 생각했고,

그다음에는 그 돈이 어디에서 왔는지를 생각했다.

그리고 마지막에는 다시 미옥이 떠올랐다.

하고 싶은 것이 없던 사람에게 하고 싶은 것이 생기는 것.

별것 아닌 변화처럼 보이지만 어쩌면 이 영화에서 가장 큰 사건은 그게 아니었을까.

내 기준으로는 ★★★★★ 5점 만점에 5점.

《암살자(들)》 리뷰 — 다 보고 나니 제목의 괄호가 무섭게 남았다

ekyu — Mon, 28 Sep 2026 17:57:33 +0900

영화 <암살자(들)> 리뷰 — 다 보고 나니 제목의 괄호가 무섭게 남았다

※ 영화의 주요 설정과 일부 장면에 대한 이야기가 있습니다. 결말을 직접적으로 설명하지는 않습니다.

영화 제목을 처음 봤을 때 가장 먼저 눈에 들어온 건 ‘(들)’이었다.

왜 그냥 <암살자들>이 아니라 <암살자(들)>일까.

영화를 보기 전에는 꽤 작위적인 제목이라고 생각했다. 그런데 다 보고 나서는 오히려 이 영화에서 가장 잘 만든 것 중 하나가 제목이라는 생각이 들었다.

누가 암살자인가.

총을 쏜 사람인가.
그 사람을 움직인 사람인가.
사건을 덮은 사람인가.
진실을 알고도 침묵한 사람까지 포함해야 하는가.

영화가 끝날 때쯤이면 괄호 안에 들어간 한 글자가 처음보다 훨씬 무겁게 보인다.

내 기준에서는 5점 만점에 5점.

최근 본 한국 영화 가운데 이렇게 처음부터 끝까지 집중해서 본 작품은 오랜만이었다.

이미 결과를 알고 있는데도 긴장된다

<암살자(들)>은 1974년 8월 15일 발생한 영부인 저격 사건을 모티브로 한다. 허진호 감독이 연출했고 유해진, 박해일, 이민호가 각각 경찰 철구, 사회부장 재환, 신입 기자 영일을 연기한다. 세 사람은 실존 사건을 그대로 재연하는 인물이라기보다 영화가 만들어낸 가상의 인물들로, 각자의 위치에서 사건의 의문을 따라간다. 영화는 2026년 9월 23일 개봉했다.

이런 영화를 만들 때 가장 어려운 점은 아마 관객 대부분이 사건의 큰 틀을 이미 알고 있다는 것 아닐까.

무슨 일이 벌어지는지도 알고 있고, 누가 체포됐는지도 안다.

그런데도 긴장된다.

이게 좋았다.

영화는 억지 반전을 숨겨뒀다가 마지막에 터뜨리는 식으로 끌고 가지 않는다.

오히려 이미 알려진 사건 주변을 천천히 들여다본다.

처음에는 별것 아닌 것처럼 보였던 작은 모순 하나가 생기고, 그걸 따라가면 또 다른 이상한 부분이 나온다.

“어?”

하고 한 번 걸린다.

조금 지나면 또 하나 걸린다.

그러다 어느 순간부터 공식적으로 알려진 이야기를 그대로 받아들이기가 어려워진다.

영화가 관객에게 계속 답을 주는 게 아니라 의심하는 방법을 만들어주는 느낌이었다.

그래서 더 재미있었다.

유해진이 이렇게 조용한데도 무서울 수 있구나

유해진을 보면서 가장 먼저 든 생각이었다.

이 영화에서 유해진은 굳이 큰 연기를 하지 않는다.

평소 그의 영화에서 볼 수 있었던 능청스러움도 거의 없다. 말도 많지 않고 표정도 크지 않다.

그런데 이상하게 계속 보게 된다.

철구는 사건 현장 가까이에 있었던 경찰이다.

경찰이라는 신분 때문에 일반 사람보다 많은 것을 볼 수 있지만, 그렇다고 모든 것을 말하거나 움직일 수 있는 사람은 아니다.

그 애매한 위치가 유해진과 정말 잘 맞았다.

무엇인가를 봤는데 확신하지 못하는 얼굴.

확신했지만 입 밖으로 꺼낼 수 없는 얼굴.

그리고 어느 순간부터는 알고 싶지 않은데도 계속 알아버리는 얼굴.

대사가 아니라 표정으로 넘어가는 장면이 꽤 많았다.

유해진을 수많은 영화에서 봤는데도 이번에는 조금 다르게 보였다.

박해일은 그냥 그 시대의 기자처럼 보였다

박해일의 재환도 좋았다.

신념에 불타는 기자라고 해서 처음부터 정의를 외치거나 책상을 치지 않는다.

오히려 현실을 너무 잘 알고 있는 사람이다.

무엇을 기사로 쓸 수 있는지 알고 있고,

무엇을 쓰면 안 되는지도 안다.

그래서 더 답답하다.

영화를 보는 사람 입장에서는 어느 순간 이런 생각이 든다.

“아니, 알았으면 그냥 쓰면 되잖아.”

그런데 영화는 그게 그렇게 간단하지 않았던 시대를 보여준다.

허진호 감독은 작품을 준비하며 당시 사건에 관한 다큐멘터리, 책, 논문과 해외 자료 등을 조사했고, 사건의 범인을 새롭게 단정하기보다는 폭력이 지배했던 시대 속에서 진실을 좇는 사람들의 이야기를 그리고자 했다고 설명했다.

그래서인지 재환이라는 인물이 더 현실적으로 보였다.

용감한 기자와 비겁한 기자를 딱 나눠놓지 않는다.

사람은 대부분 그 사이 어딘가에 있다.

겁도 나고, 가족도 생각나고, 직장도 생각나는데,

그래도 이것만큼은 그냥 넘어갈 수 없다고 생각하는 순간이 온다.

박해일이 그 미묘한 지점을 정말 잘 잡는다.

그리고 이민호가 생각보다 훨씬 좋았다

솔직히 이 영화에서 가장 궁금했던 배우는 이민호였다.

유해진과 박해일 사이에서 어떤 느낌일지가 궁금했다.

그런데 꽤 잘 어울린다.

영일은 아직 기자 생활에 완전히 길들여지지 않은 사람이다.

그래서 선배들이 한 번 멈출 때 혼자 한 발 더 들어간다.

위험한지도 모르고 들어가는 순간도 있고, 알고도 들어가는 순간도 있다.

이 캐릭터가 없었다면 영화 전체가 너무 무거웠을 것 같다.

철구와 재환이 이미 세상이 어떻게 돌아가는지 아는 사람들이라면 영일은 아직 “왜 안 되는데?”라고 묻는 사람이다.

그 차이가 영화에 속도를 만든다.

세 배우가 한 팀처럼 붙어 다니면서 사건을 해결하는 영화가 아니라는 것도 좋았다.

경찰은 경찰의 자리에서 보고,

사회부장은 사회부장의 자리에서 보고,

막내 기자는 또 자기 자리에서 본다.

그러다가 각자가 발견한 조각들이 조금씩 연결된다.

이 방식 때문에 같은 사건을 여러 각도에서 들여다보게 된다.

이 영화는 총격보다 침묵이 더 무섭다

영화에는 총이 등장한다.

당연히 사건의 중심에도 총성이 있다.

그런데 보고 나서 가장 기억에 남는 건 총소리가 아니었다.

사람들이 입을 다무는 순간이었다.

누군가는 봤는데 못 봤다고 한다.

누군가는 알고 있는데 모른다고 한다.

어떤 사람은 질문을 듣자마자 표정부터 변한다.

그리고 가장 무서운 건 그 사람들이 특별히 악해서 그러는 게 아니라는 점이다.

말하면 안 되는 시대였고,

잘못 말했다가는 실제로 무슨 일이 생길지 알 수 없는 시대였다.

처음에는 외부에서 입을 막는다.

그런데 시간이 지나면 굳이 누가 막지 않아도 스스로 멈추게 된다.

여기까지만 알아보자.

이건 묻지 말자.

이 사람에게는 전화하지 말자.

기사에는 이 정도만 쓰자.

그렇게 한 사람씩 선을 긋기 시작한다.

이 영화가 좋았던 이유 중 하나가 바로 이 부분이었다.

거대한 음모를 거창하게 보여주는 것보다 사람들이 조금씩 말을 하지 않게 되는 과정을 보여준다.

그게 훨씬 현실적으로 무서웠다.

허진호 감독 영화라는 게 중간중간 느껴진다

소재만 보면 굉장히 거칠고 강한 정치 스릴러가 될 수도 있다.

그런데 <암살자(들)>은 생각보다 차분하다.

사건이 계속 벌어지는데도 영화가 흥분하지 않는다.

카메라도 그렇고 배우들도 그렇다.

누가 악인인지 크게 표시해주지도 않는다.

그리고 사람을 보는 시간이 길다.

누군가가 사건을 설명하는 장면보다 그 설명을 듣고 있는 사람의 얼굴이 더 기억나는 순간도 있었다.

이런 부분에서는 확실히 허진호 감독 영화라는 느낌이 난다.

큰 사건을 다루면서도 결국 사람을 보고 있다.

특히 철구와 재환이 조금씩 변해가는 과정이 그렇다.

처음부터 목숨을 걸고 진실을 밝히겠다는 사람들이 아니다.

우연히 이상한 걸 봤고,

조금 더 알아봤고,

그러다 돌아가기 어려운 곳까지 간다.

그 과정이 자연스럽다.

영화가 역사적 사실과 허구 사이에서 꽤 영리하게 움직인다

이런 영화는 조금만 잘못 만들면 위험하다.

실제 사건을 다루면서 영화적 상상력을 너무 강하게 밀어붙이면 관객이 그것을 사실로 받아들일 수도 있기 때문이다.

<암살자(들)> 역시 실제 영부인 저격 사건에서 출발하지만, 철구·재환·영일 등 주요 추적 인물들은 가상 인물이다. 감독 역시 자료 조사 뒤 사건에 새로운 역사적 결론을 내리는 방식이 아니라, 당시 사건을 바라보고 의문을 품었던 사람들을 중심으로 이야기를 구성했다고 밝혔다.

그래서 영화를 보고 나서 오히려 실제 기록이 궁금해졌다.

영화가 정답을 알려줘서가 아니다.

반대다.

영화가 정답을 주지 않았기 때문에 찾아보고 싶어졌다.

이 차이가 꽤 크다.

역사 영화가 할 수 있는 가장 재미있는 역할 중 하나가 이런 것 아닐까 싶다.

영화를 보고,

“진짜는 어땠지?”

하고 검색해보게 만드는 것.

130분이 길게 느껴지지 않았다

요즘 두 시간이 넘어가면 보기 전부터 조금 부담스럽다.

특히 대사가 많고 정치적인 배경까지 있는 영화라면 더 그렇다.

그런데 <암살자(들)>은 이상하게 길다는 생각을 거의 하지 않았다.

사건 하나를 해결하고 다음 사건으로 넘어가는 식으로 억지로 속도를 내지 않는다.

그런데 계속 궁금하다.

이 사람은 뭘 알고 있는지.

왜 저 이야기를 하지 않는지.

아까 나온 장면은 무슨 의미였는지.

큰 사건보다 작은 의문을 계속 이어붙인다.

그래서 집중력이 잘 끊기지 않는다.

영화가 끝난 다음 시간을 확인하고 나서야

“생각보다 꽤 길었네.”

싶었다.

내게는 좋은 영화에서 자주 생기는 일이기도 하다.

무엇보다 결말까지 보고 제목을 다시 생각하게 된다

그리고 결국 다시 제목이다.

암살자(들).

영화 보기 전과 보고 난 뒤에 제목이 완전히 다르게 읽힌다.

암살자는 한 명인가.

정말 방아쇠를 당긴 사람만 암살자인가.

명령한 사람이 있다면?

그 사실을 알고 숨긴 사람이 있다면?

진실을 없애버린 사람이 있다면?

어디까지 괄호 안에 넣어야 할까.

영화가 이 질문에 답을 써주지는 않는다.

그래서 마음에 들었다.

만약 마지막에 모든 것을 친절하게 설명하고

“진실은 이것입니다”

라고 끝냈다면 오히려 평범한 영화가 됐을 것 같다.

대신 괄호 하나를 남긴다.

그리고 극장을 나온 뒤에도 그 괄호가 계속 생각난다.

5점을 준 이유

별 다섯 개를 주는 영화라고 해서 모든 장면이 완벽해야 한다고 생각하지는 않는다.

내가 5점을 주는 영화는 조금 다르다.

보는 동안 몰입했고,

배우들이 좋았고,

끝까지 궁금했고,

영화가 끝난 뒤에도 계속 생각났고,

결국 실제 사건까지 다시 찾아보게 됐다.

<암살자(들)>은 그게 전부 있었다.

특히 좋았던 건 이 영화가 역사적 사건을 빌려와 단순히 “숨겨진 진실을 폭로한다”는 방향으로만 가지 않았다는 점이다.

그보다 더 오래 남는 건 사람들이다.

봤던 사람.

알게 된 사람.

말하지 못했던 사람.

그래도 끝까지 확인하려 했던 사람.

그래서 사건보다 사람들의 얼굴이 더 오래 기억난다.

그리고 마지막에는 아주 단순한 질문 하나만 남는다.

내가 저 시대에 있었다면 어디까지 갈 수 있었을까.

영화를 다 보고 나서도 그 질문에 쉽게 답하지 못했다.

그래서 5점이다.

★★★★★ 5/5

최근 한국 영화 중에서 누군가에게 “극장에서 볼 만한 영화 뭐 있어?”라고 물으면 망설이지 않고 이야기하고 싶은 작품이다.

그리고 가능하면 영화에 대한 정보를 너무 많이 찾아보지 않고 먼저 보는 쪽을 권하고 싶다.

이 영화는 무엇을 알고 보는 것보다,

보면서 하나씩 의심하기 시작할 때 훨씬 재미있다.

<암살자(들)>이라는 제목의 괄호가 왜 필요한지 직접 확인하는 것.

그게 이 영화를 보는 가장 재미있는 방법이었다.

《빵과 우유》 리뷰 — 사람 마음이 그렇게 깔끔하게 나뉠 리가 없지

ekyu — Mon, 28 Sep 2026 17:53:56 +0900

《빵과 우유》 리뷰 — 사람 마음이 그렇게 깔끔하게 나뉠 리가 없지

책 제목만 보면 꽤 순하다.

빵과 우유.

아침 식탁 같은 제목이고, 어쩐지 따뜻한 이야기가 들어 있을 것 같다. 그런데 몇 편 읽다 보면 제목에서 생각했던 분위기와는 꽤 멀어진다.

사람들이 계속 불편해한다.

자기가 선택한 삶이 정말 원하는 삶인지 모르겠고, 좋은 일을 한다는 사람을 보면서도 어딘가 미심쩍고, 싫다고 말하면서 정작 완전히 떠나지도 못한다.

그런 사람들이 이 책에 계속 나온다.

그리고 그게 생각보다 재미있었다.

한은형의 《빵과 우유》는 2015년 《어느 긴 여름의 너구리》 이후 11년 만에 나온 두 번째 소설집이다. 총 일곱 편이 실려 있고, 비거니즘과 종교, 가족과 모성, 재한 동포의 삶처럼 서로 꽤 다른 이야기를 다룬다. 2026년 9월 문학동네에서 출간됐다.

그런데 막상 읽고 나면 각각의 소재보다 더 기억에 남는 건 그 안에 있는 사람들이다.

좋은 사람과 나쁜 사람으로 나누기가 애매하다

첫 번째 작품인 〈식물성 관상〉부터 그렇다.

비건 식당이 등장한다.

말만 들으면 가치관이 분명한 공간처럼 보이는데, 실제로 그 안을 들여다보면 그렇게 단순하지 않다. 식당은 비건이라는 이미지를 내세우면서 사람을 외모로 판단하고, 그걸 또 그럴듯한 말로 포장한다.

사장은 이런 말을 한다.

“진정성 없는 게 이 시대의 진정성이라고 해도 되겠다.”

웃기면서도 묘하게 기분 나쁜 말이다.

말 자체만 떼어놓고 보면 요즘 어디선가 한 번쯤 들어봤을 법한 이야기이기도 하다.

중요한 건 가치인가, 이미지인가.

정말 비건이어서 비건 식당을 운영하는 건지, 아니면 비건이라는 이미지를 파는 건지.

그런데 소설이 여기서 친절하게 답을 내려주지는 않는다.

이 사람이 위선적이라고 딱 표시해놓고 끝내는 식이 아니다. 오히려 읽는 사람 쪽에서 계속 판단을 바꾸게 만든다. 출판사 역시 이 작품을 비건을 표방하는 식당 안에서 벌어지는 이미지 소비와 차별을 다룬 이야기로 소개하고 있다.

나는 이 애매함이 좋았다.

현실에서 만나는 사람들도 대부분 그렇기 때문이다.

완전히 좋은 사람도 드물고, 작정하고 나쁜 사람도 생각보다 많지 않다.

그 사이가 훨씬 넓다.

이상한 스님을 보면서 드는 이상한 감정

〈절담〉도 기억에 남았다.

소설 속 화자는 유명한 사찰 음식의 대가가 된 승려를 만난다.

그런데 예전에 그 절을 방문했던 기억과 지금의 모습이 좀처럼 연결되지 않는다. 예전에는 먹기 힘든 밥을 내놓던 곳이 유명한 사찰 음식의 공간이 되었고, 스님 역시 어느새 마케팅에 능한 유명인이 되어 있다.

여기서 재미있는 건 돈 많은 스님을 비판하는 이야기로 간단히 끝내지 않는다는 점이다.

사람은 성공하면 안 되는가.

승려는 좋은 차를 타면 안 되는가.

마케팅을 잘하면 수행자의 진정성이 사라지는가.

머리로는 쉽게 답할 수 있을 것 같은데 실제 사람을 앞에 놓으면 생각이 복잡해진다.

나도 읽으면서 몇 번 마음이 바뀌었다.

“이건 좀 이상한데.”

싶다가도,

“그렇다고 이 사람이 잘못했다고 할 수 있나?”

싶어진다.

딱 그런 순간을 잘 잡는다.

표제작 《빵과 우유》는 오히려 가장 거칠다

제목이 된 〈빵과 우유〉에는 미구라는 인물이 등장한다.

미구는 훌륭한 가정주부가 되는 삶을 끔찍하게 여기면서도 가족을 완전히 버리고 떠나지는 못한다. 그리고 작품 안에서 그 답답함은 식탁과 음식, 집 안에 쌓여 있는 물건들과 묘하게 겹친다.

이 작품에서 유독 기억에 남는 부분이 있다.

미구가 정말 망가뜨리고 싶은 건 음식이 아니라 가정 자체였다는 대목이다.

남편과 아이가 싫다는 단순한 이야기는 아니다.

가정을 사랑하면서도 가정이라는 형태에서 도망가고 싶은 마음.

아이를 사랑한다고 해서 엄마라는 역할까지 사랑해야 하는 건 아니고,

결혼을 했다고 해서 가정주부의 삶이 자연스럽게 자기 것이 되는 것도 아니다.

이런 감정은 설명하려고 하면 오히려 이상해진다.

“가족은 사랑하지만 가족에게서 도망가고 싶다.”

앞뒤가 안 맞는 말처럼 보인다.

그런데 사람이 원래 그렇다.

그래서 이 소설집의 제목으로 〈빵과 우유〉를 고른 게 꽤 잘 어울린다고 생각했다.

겉으로 보기에는 아무 문제 없어 보이는 식탁이 있는데, 그 식탁 앞에 앉아 있는 사람 마음속에서는 전혀 다른 일이 벌어지고 있다.

나는 이 책에서 ‘모순’이라는 말이 제일 많이 떠올랐다

책에는 일곱 편이 실려 있다.

〈식물성 관상〉
〈절담〉
〈빵과 우유〉
〈피서〉
〈N서울타워〉
〈스위스식 농담〉
〈동백 정원〉

서로 소재도 다르고 등장인물도 다르다.

그런데 읽다 보면 계속 비슷한 순간을 만나게 된다.

싫은데 떠나지 못한다.

이상하다고 생각하면서도 끌린다.

혼자 있고 싶은데 외로운 건 싫다.

옳다고 생각하지만 그렇게 살지는 못한다.

누군가를 이해하면서도 좋아하지는 않는다.

보통 사람을 설명할 때는 하나를 고르게 된다.

좋은 엄마.

위선적인 사람.

외로운 사람.

이기적인 사람.

그런데 실제 사람은 그런 식으로 한 줄로 정리되지 않는다.

이 책은 그 정리되지 않는 부분을 계속 건드린다.

출판사 소개에서 이 소설집을 설명하면서 ‘양가적이고 모순적인 감정’이라는 표현을 사용하는데, 책을 가장 짧게 설명한다면 나도 결국 그 말을 고를 것 같다.

다만 책을 읽으면서는 그렇게 거창한 단어보다 이런 생각이 더 많이 들었다.

사람 마음이 원래 이렇지.

그래서 누군가를 쉽게 미워하기가 조금 어려워진다

소설을 읽을 때 꼭 교훈을 찾아야 한다고 생각하지 않는다.

오히려 이 책은 뭔가를 가르치려 들지 않아서 좋았다.

누가 옳은지도 명확하지 않고,

누가 나쁜지도 쉽게 정해지지 않는다.

어떤 인물에게는 꽤 짜증이 나다가도 조금 지나면 그 사람이 왜 그렇게 행동했는지 이해하게 된다.

그렇다고 갑자기 좋아지는 것도 아니다.

그냥 조금 알게 된다.

나는 그 정도면 충분하다고 생각한다.

현실에서도 누군가를 제대로 알고 나면 이상하게 욕하기가 조금 어려워질 때가 있다.

잘못한 건 잘못한 건데,

그 사람이 그렇게 된 과정까지 알고 나면 이야기가 약간 달라진다.

한은형이 작가의 말에서 이 책의 인물들을 두고 미숙하고 결점이 있지만 자신이 편애하는 사람들이라고 밝힌 것도 그래서 이해됐다. 작가는 그들을 ‘알고 싶어하는 사람’이라고 표현한다.

그 표현이 꽤 마음에 들었다.

《빵과 우유》라는 평범한 제목이 나중에는 다르게 보였다

처음에는 제목이 왜 《빵과 우유》인지 크게 생각하지 않았다.

그냥 표제작 제목을 소설집 이름으로 사용한 거라고 생각했다.

그런데 책을 덮고 나니 조금 다르게 보인다.

빵과 우유는 너무 평범하다.

같이 놓여 있어도 이상하지 않고, 설명도 필요 없다.

가정도 비슷하다.

부부가 있고 아이가 있고 식탁이 있으면 우리는 그것을 자연스럽게 하나의 모습으로 받아들인다.

그런데 가까이 들여다보면 사람 마음은 그렇게 가지런하지 않다.

사랑하면서 벗어나고 싶고,

믿으면서 의심하고,

원하면서 동시에 싫어한다.

그걸 굳이 하나로 정리하지 않아도 되는 소설들이었다.

그래서 나는 이 책을 읽고 나서 인물보다 이상하게 마음의 앞뒤가 맞지 않는 순간들이 더 많이 기억에 남았다.

아마 한동안은 누군가를 보고

“저 사람은 왜 저래?”

라는 생각이 들 때,

한 번 정도 더 생각하게 될 것 같다.

정말 저 사람 마음이 하나뿐일까.

《빵과 우유》는 그런 책이었다.

사람을 이해하게 해주는 책이라기보다는,

사람을 너무 빨리 이해했다고 생각하지 않게 만드는 책.

그 정도 거리를 남겨놓는 게 마음에 들었다.

책 정보

제목: 《빵과 우유》
저자: 한은형
출판사: 문학동네
출간: 2026년 9월 28일
분량: 296쪽
수록작: 7편

한 줄 감상

사람 마음이 앞뒤가 맞지 않는다고 해서, 그 마음까지 가짜인 건 아니다.

GPT-6와 Claude 5.5, 이제 토큰보다 캐시가 중요하다

ekyu — Thu, 24 Sep 2026 14:51:09 +0900

GPT-6와 Claude 5.5, 이제 토큰보다 캐시가 중요하다

Agent를 오래 돌릴수록 모델 가격보다 Context를 얼마나 다시 쓰느냐가 중요해지는 이유

AI 모델 가격을 비교할 때 보통 가장 먼저 보는 숫자는 이겁니다.

Input Token 가격
Output Token 가격

짧은 질문을 한두 번 하는 정도라면 이것만 봐도 충분합니다.

하지만 Codex나 Claude Code처럼 Agent가 한 작업을 오래 이어가면 이야기가 달라집니다.

Agent는 매번 새 질문 하나만 보내는 게 아닙니다.

프로젝트 규칙, Tool 정의, 이전 대화, 코드, Build 결과처럼 이미 한 번 읽었던 내용을 계속 가지고 다음 작업을 이어갑니다.

AGENTS.md / CLAUDE.md

Tool Definitions

Repository Context

Conversation History

Build / Test Result

현재 작업 내용

Context가 10만, 20만 Token까지 커진 상태에서 매 요청마다 이 내용을 처음부터 다시 계산한다면 비용도 커지고 응답도 느려집니다.

그래서 최근 GPT-6와 Claude Opus 5.5를 보면 공통적으로 눈에 들어오는 것이 Prompt Cache입니다.

GPT-6는 Cache Hit를 높이고 어디서 Cache가 깨졌는지 확인하는 기능까지 크게 늘렸고, Claude는 긴 Session에서 Effort를 바꾸면서도 Cache를 유지하는 방법을 제공하고 있습니다.

1. Prompt Cache가 뭐길래 중요해졌을까

쉽게 생각하면 됩니다.

Agent가 이미 읽은 내용 중 변하지 않은 부분을 매번 처음부터 다시 처리하지 않는 것입니다.

첫 요청이:

System Instructions

AGENTS.md

20개의 Tool 정의

Repository 설명

사용자 질문 A

였다면,

다음 요청은 보통:

System Instructions        ← 그대로

AGENTS.md                  ← 그대로

20개의 Tool 정의          ← 그대로

Repository 설명           ← 그대로

사용자 질문 A             ← 그대로

Agent 답변                 ← 추가

사용자 질문 B             ← 추가

가 됩니다.

앞부분 대부분은 이미 처리한 내용입니다.

Cache가 잘 유지되고 있다면 모델은 이 긴 앞부분을 그대로 재사용하고 새롭게 추가된 부분만 처리하면 됩니다.

그래서 긴 Agent Session에서는:

전체 Context 크기

만큼이나

그중 얼마나 Cache로 다시 읽었는가

가 중요해집니다.

2. Agent에서는 같은 Context를 계속 반복해서 쓴다

일반 Chat에서는 질문 하나 하고 끝날 수 있습니다.

하지만 Coding Agent는 그렇지 않습니다.

예를 들어 버그 하나를 고친다고 해보겠습니다.

Repository 분석

→ 관련 파일 검색

→ 코드 읽기

→ 수정

→ Build

→ Test 실패

→ Log 확인

→ 다시 코드 수정

→ Test

→ Review

10번의 Model Call이 발생해도 프로젝트 설명이나 Tool 정의 대부분은 그대로입니다.

그래서 매번:

100K Context × 10번

을 전부 새로 처리하는 것과,

처음 한 번 처리한 100K를 이후 요청에서 대부분 Cache로 재사용하는 것은 비용 차이가 큽니다.

이 때문에 Agent가 길게 일할수록 Prompt Cache의 가치가 커집니다.

GPT-6에서 Cache가 꽤 많이 바뀌었다

3. GPT-6는 Cached Input을 최대 90% 할인한다

OpenAI는 GPT-6와 함께 Prompt Caching을 크게 손봤습니다.

공식 설명 기준으로 동일한 Prompt Prefix를 다시 사용하는 경우 Cached Input Token은 최대 90% 할인을 받을 수 있습니다.

또 GPT-6 계열에서는 재사용 가능한 Prefix가 30분 동안 유지될 수 있도록 Cache 동작도 개선됐습니다.

Agent 입장에서는 꽤 큰 차이입니다.

예를 들어:

공통 Instructions
Tool Schema
프로젝트 규칙
긴 대화 Context

같은 부분이 계속 Cache에 걸린다면 매 Turn마다 Fresh Input 가격을 전부 지불하지 않아도 됩니다.

4. GPT-6에서는 Cache가 왜 깨졌는지도 볼 수 있다

예전 Prompt Cache의 불편한 점 중 하나는:

왜 이번에는 Cache Hit가 안 됐지?

를 알아내기 어렵다는 것이었습니다.

GPT-6에서는 이 부분에 관리 기능이 추가됐습니다.

Prompt Caching Dashboard

전체 요청 중:

Cached Input

Uncached Input

비율을 볼 수 있습니다.

Cache Diagnostics

Cache가 깨졌다면:

Tool이 변경됨

Model이 변경됨

설정이 변경됨

Prompt Prefix가 달라짐

같은 이유를 확인할 수 있습니다.

즉 이제 Prompt Cache가 단순한 내부 최적화가 아니라 개발자가 직접 관리하는 성능 지표에 가까워졌습니다.

5. 원하는 지점까지 직접 Cache할 수도 있다

GPT-6에서는 Explicit Cache Breakpoint도 사용할 수 있습니다.

예를 들어 Agent Prompt가:

공통 Agent 규칙

프로젝트 Architecture

Tool Definitions

현재 사용자 정보

현재 시간

이번 요청

순서라면,

앞의 안정적인 부분까지만 Cache 대상으로 잡을 수 있습니다.

공통 Agent 규칙

프로젝트 Architecture

Tool Definitions

──────── Cache Breakpoint ────────

현재 사용자 정보

현재 시간

이번 요청

자주 바뀌는 정보를 Cache 뒤쪽에 두는 방식입니다.

이렇게 하면 매 요청마다 바뀌는 정보 때문에 앞의 긴 Context까지 다시 처리하는 문제를 줄일 수 있습니다.

6. Cache를 미리 데워두는 것도 가능하다

GPT-6에는 Cache Prewarming도 있습니다.

사용자가 질문하기 전에:

공통 Instructions

Tool Definitions

Reference Document

처럼 미리 알고 있는 Context를 먼저 Cache에 올려두는 방식입니다.

그러면 실제 사용자 요청이 들어왔을 때 긴 공통 Context를 처리하는 시간이 사용자 대기시간에 포함되지 않을 수 있습니다.

예를 들어 사내 Agent라면:

서비스 시작

↓

회사 공통 규칙
Tool Schema
제품 문서

Cache Prewarm

↓

사용자 첫 질문

처럼 구성할 수 있습니다.

특히 첫 응답 속도가 중요한 서비스에서는 꽤 실용적인 기능입니다.

이번 GPT-6 변화에서 특히 재미있는 부분

7. Reasoning Effort를 바꿔도 Cache를 유지할 수 있다

Agent를 쓰다 보면 모든 작업의 난이도가 같지 않습니다.

예를 들어:

파일 이름 변경
→ 낮은 Effort

일반 Feature 구현
→ Medium

복잡한 Concurrency Bug
→ High

처럼 쓰고 싶습니다.

문제는 Reasoning 설정을 바꾸면서 Prompt 자체가 달라지면 Cache가 깨질 수 있다는 점입니다.

GPT-6에서는 configuration_update를 Conversation 뒤에 추가하는 방식으로 기존 Context는 그대로 유지하면서 이후 작업의 Reasoning Effort만 변경할 수 있습니다.

구조는 대략 이렇습니다.

긴 기존 Context
───────────────

Medium으로 작업

↓

어려운 문제 등장

↓

configuration_update
effort = high

↓

기존 Cache 유지

↓

작업 계속

이게 긴 Agent Session에서는 꽤 중요합니다.

Claude 5.5도 비슷한 방향으로 움직이고 있다

8. Claude도 Top-level Effort를 바꾸면 Cache가 깨진다

Claude Opus 5.5에서도 Effort는 중요한 비용 조절 수단입니다.

기본값은:

medium

입니다.

그런데 API 요청의 Top-level Effort를:

medium
→
high

로 바꾸면 Prompt Cache가 다시 시작됩니다.

긴 Context를 사용하고 있었다면 앞의 Context를 다시 Cache Write해야 할 수 있습니다.

그래서 긴 Agent Conversation에서 Effort를 계속 바꾸는 것은 생각보다 비용이 들 수 있습니다.

9. Claude에는 Per-message Effort가 있다

이 문제를 해결하기 위한 기능이 Per-message Effort입니다.

예를 들어:

일반 Coding
Medium

↓

이번 Turn만 어려움
High

↓

다음 Turn
다시 Medium

처럼 특정 Turn의 Effort만 바꿀 수 있습니다.

이 방식을 사용하면 앞의 Prompt Cache를 그대로 유지할 수 있습니다.

현재 Beta 기능이며 Claude Opus 5.5도 지원합니다.

즉 GPT-6과 Claude 5.5 모두 결국 비슷한 문제를 해결하고 있습니다.

Context는 그대로 두고

↓

이번 작업의 Reasoning 깊이만 바꾸기

입니다.

10. Claude 5.5에서는 Cache Read 가격도 상당히 낮다

Opus 5.5 API 가격은:

Fresh Input
$4 / MTok

5분 Cache Write
$5 / MTok

Cache Read
$0.20 / MTok

입니다.

Cache Read는 Fresh Input의 5% 수준입니다.

그래서 긴 Context를 반복해서 사용하는 Agent라면:

모델 Input 가격

만 보는 것보다

실제로 Fresh Input으로 처리된 양

vs

Cache에서 읽은 양

을 같이 봐야 합니다.

Tool이 많아질수록 Cache 관리도 어려워진다

11. Tool Schema 하나 바꿔도 Cache가 영향을 받을 수 있다

Coding Agent에는 Tool이 많습니다.

GitHub

Search

Terminal

Browser

Database

Xcode

Simulator

등이 있습니다.

그리고 Tool마다 긴 Schema와 설명이 들어갑니다.

이 Tool 정의 역시 Prompt의 일부입니다.

따라서 매 요청마다:

Tool 1
Tool 2
Tool 3

순서를 바꾸거나,

Tool 설명을 수정하거나,

Schema를 조금씩 다르게 만들면 기존 Prefix와 달라질 수 있습니다.

결국 Cache Hit가 떨어집니다.

12. GPT-6는 Tool을 지우지 말고 사용 가능 여부만 바꾸는 방식을 권장한다

예를 들어 이번 Turn에서는 GitHub Tool이 필요 없다고 해보겠습니다.

매번 Tool 목록에서 GitHub를 제거하면:

이전 Prompt

Tool A
Tool B
Tool C

↓

새 Prompt

Tool A
Tool C

가 되면서 앞의 Context가 달라질 수 있습니다.

GPT-6에서는 Tool 정의 자체는 그대로 유지하고:

allowed_tools

로 이번 요청에서 사용할 Tool만 제한하거나,

필요 없다면:

tool_choice = none

으로 두는 방법을 권장합니다.

핵심은:

안 쓰는 Tool을 삭제하지 말고 Tool 목록 자체는 가능한 한 안정적으로 유지하는 것입니다.

그래서 Agent Prompt 구조도 달라져야 한다

13. 변하지 않는 것은 앞에, 자주 바뀌는 것은 뒤에 둔다

Prompt Cache는 앞에서부터 동일한 Prefix를 찾습니다.

그래서 Agent Prompt가 이런 식이라면:

현재 시간

사용자별 설정

AGENTS.md

Tool Schema

Architecture

이번 질문

좋지 않을 수 있습니다.

맨 앞의 시간이 매번 바뀌기 때문입니다.

오히려:

AGENTS.md

Architecture

Tool Schema

공통 Reference

──────── 안정적인 Context ────────

사용자별 정보

현재 시간

이번 질문

처럼 배치하는 것이 유리합니다.

원칙은 간단합니다.

잘 안 바뀌는 정보는 앞쪽. 자주 바뀌는 정보는 뒤쪽.

14. AGENTS.md와 CLAUDE.md도 Cache 관점에서 볼 필요가 있다

예전에는 AGENTS.md나 CLAUDE.md를:

Agent에게 프로젝트 규칙을 알려주는 문서

정도로 생각했습니다.

Cache까지 생각하면 한 가지 이유가 더 생깁니다.

프로젝트 규칙을 안정적인 한 곳에 두면:

매 요청마다 달라지는 Prompt

보다 훨씬 재사용하기 쉽습니다.

예를 들어:

Architecture Rule

Build 명령

Test 명령

파일 구조

금지된 Dependency

같은 내용은 자주 바뀌지 않습니다.

이런 Context는 Prompt 앞쪽에서 안정적으로 유지하는 것이 좋습니다.

Cache를 깨는 흔한 패턴

15. Agent를 만들 때 이런 부분을 주의할 만하다

System Prompt를 매번 새로 생성

현재 날짜를 System Prompt 첫 줄에 넣기

처럼 Dynamic 값이 앞부분에 들어가면 재사용하기 어렵습니다.

Tool 순서를 계속 변경

같은 Tool이라도 정의 순서가 달라지면 Prompt가 달라질 수 있습니다.

Tool Schema를 매 Turn 수정

사용하지 않는 Tool을 삭제했다 다시 추가하는 식도 좋지 않습니다.

Conversation History를 다시 작성

이전 대화를 그대로 이어붙이는 대신 매번 요약해서 새 Prompt로 만들면 Prefix가 달라질 수 있습니다.

Reasoning Effort를 Top-level에서 계속 변경

GPT-6과 지원되는 Claude 모델 모두 Cache를 보존하는 별도 방식을 사용하는 편이 좋습니다.

너무 잦은 Compaction

Compaction은 Context를 줄여주지만 이전 Prefix가 달라지기 때문에 Cache Hit가 줄 수 있습니다.

즉 Context를 줄이는 것과 Cache를 유지하는 것 사이에도 균형이 필요합니다.

Cache가 얼마나 중요하냐면

16. OpenAI가 공개한 실제 사례도 꽤 크다

OpenAI가 공개한 한 고객 사례에서는 Explicit Cache Breakpoint를 적용한 뒤 평가 환경의 Cache Hit Rate가:

83%
→
91%

로 올라갔습니다.

그 결과 Cache Write는 약 3분의 2 줄었고, 같은 작업량에서 Inference 비용은 36% 감소했다고 합니다.

물론 특정 서비스 사례라 모든 Agent가 36% 절감된다는 뜻은 아닙니다.

중요한 부분은:

모델을 바꾸지 않았는데도 Cache 관리만으로 비용이 크게 달라질 수 있다.

는 점입니다.

GPT-6과 Claude 5.5를 비교하면

17. 둘 다 Cache가 중요하지만 접근법은 조금 다르다

항목	GPT-6	Claude Opus 5.5
자동 Prompt Cache	지원	지원
Effort 변경 + Cache 유지	`configuration_update`	Per-message Effort
Cache 관리 Dashboard	지원	상대적으로 제한적
Cache Miss 진단	지원	별도 관리 필요
Explicit Breakpoint	지원	Prompt Cache 지점 지정 방식 지원
Prewarming	지원	일반적인 Cache Write 방식 활용
Cached Input 절감	최대 90%	Cache Read $0.20 / MTok
긴 Agent Session	매우 중요	매우 중요

둘 중 누가 Cache 자체를 더 잘한다고 단순하게 말하기보다는 차이가 있습니다.

GPT-6는 이번 업데이트에서 Cache를 눈으로 보고 직접 튜닝하는 운영 도구가 많이 추가됐습니다.

Claude 5.5는 저렴한 Cache Read와 Effort 조절을 긴 Agent Session에 활용하는 방식이 눈에 띕니다.

Codex나 Claude Code를 실제로 쓴다면

18. 일반 개발자는 Cache를 직접 코딩하지 않아도 된다

API를 직접 만드는 개발자가 아니라면:

prompt_cache_breakpoint

configuration_update

output_config

같은 API를 매일 만질 필요는 없습니다.

그래도 Cache가 어떻게 동작하는지 알고 있으면 Agent를 훨씬 효율적으로 사용할 수 있습니다.

예를 들어 긴 Claude Code Session에서 별 이유 없이:

Medium

High

Medium

High

를 계속 오가는 것은 좋지 않을 수 있습니다.

작업 경계에 맞춰 Effort를 바꾸는 편이 낫습니다.

Codex 역시 Agent Context나 Tool 구성을 필요 없이 계속 바꾸는 것보다 안정적으로 유지하는 편이 Cache에 유리합니다.

19. 새 Session을 계속 만드는 것도 비용 측면에서는 생각해볼 문제다

예를 들어 같은 Feature를 작업하면서:

Session A
→ 조사

Session B
→ 구현

Session C
→ 테스트

Session D
→ 수정

처럼 계속 새 Session을 만들면 각 Session에서 프로젝트 Context를 다시 읽어야 할 수 있습니다.

반대로 하나의 Session에서 너무 오래 작업하면 Context 자체가 너무 커집니다.

그래서 실제로는:

하나의 관련 작업
→ 같은 Session

업무 주제가 완전히 달라짐
→ 새 Session

정도가 자연스럽습니다.

Cache 때문에 모든 작업을 한 Session에 몰아넣을 필요도 없습니다.

결국 Agent 비용은 이렇게 보는 게 더 맞다

20. 이제는 Token 단가 하나로 비교하기 어렵다

Agent의 실제 비용은 대략 이런 요소가 합쳐집니다.

Fresh Input

+

Cache Write

+

Cache Read

+

Thinking

+

Output

+

Tool Call

+

Retry

그리고 가장 비싼 Agent가 항상 가장 비싼 것도 아닙니다.

비싼 모델이 한 번에 끝내고,

싼 모델이 다섯 번 실패한다면 결과가 달라질 수 있습니다.

반대로 높은 Effort가 필요 없는 작업에 계속 가장 깊은 Reasoning을 사용해도 낭비입니다.

그래서 앞으로 Agent 비용을 볼 때는:

가격표

뿐 아니라:

Cache Hit Rate

Task당 Turn 수

Thinking 사용량

Retry 횟수

까지 같이 봐야 합니다.

21. 실무에서는 이렇게 시작하면 된다

Agent API를 직접 만든다면 우선 네 가지부터 보면 됩니다.

1. Stable Context를 앞에 둔다

System Rule
Architecture
Tool Schema
공통 Reference

2. Dynamic Context는 뒤에 둔다

현재 시간
사용자 정보
이번 요청

3. Tool 정의를 자주 바꾸지 않는다

필요한 Tool만 활성화하는 방식을 사용합니다.

4. Cache Hit Rate를 실제로 측정한다

추측보다 실제 데이터가 중요합니다.

GPT-6를 사용한다면 새 Cache Dashboard와 Diagnostics가 이 부분에 특히 유용합니다.

마치며

GPT-6와 Claude Opus 5.5를 보면 모델 경쟁의 기준이 조금씩 바뀌는 것이 보입니다.

예전에는:

누가 더 똑똑한가?

누가 Token 가격이 싼가?

가 중요했습니다.

Agent가 길게 일하기 시작하면서 이제는 질문이 하나 더 생겼습니다.

이미 읽은 Context를
얼마나 다시 활용할 수 있는가?

입니다.

특히 Coding Agent는 같은 프로젝트 규칙과 Tool, Repository Context를 여러 Turn에 걸쳐 계속 사용합니다.

그런 환경에서는:

비싼 Context를 매번 다시 읽는 Agent

와

한 번 읽은 Context를 계속 Cache로 재사용하는 Agent

의 실제 운영비가 크게 달라질 수 있습니다.

GPT-6는 이번에 Cache Dashboard, Miss Diagnostics, Explicit Breakpoint, Prewarming까지 추가하면서 Prompt Cache를 개발자가 직접 관리하는 영역으로 끌어올렸습니다.

Claude Opus 5.5도 Per-message Effort를 이용하면 긴 Context를 그대로 유지하면서 특정 Turn에서만 더 깊게 생각하게 할 수 있습니다.

그래서 앞으로 Agent를 만들 때는 모델 선택만큼:

Context를 어떻게 배치하고, 어디까지 Cache하고, 무엇 때문에 Cache가 깨지는지를 설계하는 것도 중요해질 가능성이 큽니다.

한 줄로 줄이면 이렇습니다.

Agent 시대에는 Token을 얼마나 쓰느냐보다, 이미 쓴 Token을 얼마나 다시 쓰느냐가 점점 중요해지고 있습니다.

참고자료

OpenAI — Better prompt caching for GPT-6

GPT-6에서 새롭게 추가된 Prompt Caching Dashboard, Cache Miss Diagnostics, Explicit Cache Breakpoint, Prewarming과 Reasoning Effort 변경 시 Cache를 유지하는 방법을 설명한 공식 발표입니다.

GPT-6 Prompt Caching 공식 발표

OpenAI API — Prompt Caching

Prompt Prefix가 어떻게 Cache되는지, Cache Breakpoint와 configuration_update, allowed_tools, Prewarming을 실제 API에서 어떻게 사용하는지 자세히 설명합니다.

OpenAI Prompt Caching 공식 문서

OpenAI — Introducing GPT-6 Sol and Luna

GPT-6 계열의 새로운 Prompt Caching과 Cached Input 최대 90% 할인, Reasoning Effort와 Tool 설정을 바꾸면서 Cache를 유지하는 방향을 확인할 수 있습니다.

GPT-6 Sol·Luna 공식 발표

Anthropic — Claude Opus 5.5 Model Overview

Opus 5.5의 Input·Output 가격, Cache Write·Read 가격, 1M Context와 기본 Medium Effort 등 기본 사양을 확인할 수 있습니다.

Claude Opus 5.5 모델 사양

Anthropic — Effort

Claude에서 Top-level Effort를 변경하면 Cache가 다시 시작되는 이유와, Per-message Effort를 이용해 Cache를 유지하면서 특정 Turn의 Reasoning 깊이만 바꾸는 방법을 설명합니다.

Claude Effort 공식 문서

Anthropic — Prompting Claude Opus 5.5

Opus 5.5에서 Medium Effort를 기본으로 사용하는 이유, High·XHigh·Max 사용 시 Thinking·Latency·Token이 늘어나는 특징과 Prompt Cache 관련 주의사항을 설명합니다.

Claude Opus 5.5 Prompting Guide

Claude Opus 5.5, 40% 싸지고 더 빨라졌다

ekyu — Thu, 24 Sep 2026 14:50:27 +0900

Claude Opus 5.5, 40% 싸지고 더 빨라졌다

Medium Effort·Token·Cache·Agent 비용까지 달라진 이유

2026년 9월 22일 Anthropic이 Claude Opus 5.5를 공개했습니다.

새 모델이 나오면 보통 Benchmark 점수부터 확인하게 됩니다.

그런데 이번 Opus 5.5는 성능 숫자보다 다른 변화가 더 눈에 들어옵니다.

같은 일을 처리하는 데 드는 비용과 시간이 크게 줄었습니다.

성능 ↑

Input / Output 가격 ↓

Cache 가격 ↓↓↓

기본 Effort
High → Medium

불필요한 Thinking ↓

작업에 필요한 Turn ↓

출력 속도 ↑

Anthropic이 공식 발표에서 강조한 숫자도 강합니다.

Opus 5와 비교해 일반적인 작업 비용을 약 40% 낮췄습니다.

단순히 토큰 가격만 낮춘 결과는 아닙니다.

모델이 일을 처리하는 방식 자체가 더 효율적으로 바뀌었습니다.

1. 먼저 숫자부터 보면 변화가 꽤 크다

Opus 5.5의 주요 사양은 다음과 같습니다.

항목	Claude Opus 5.5
Context	1M tokens
일반 최대 Output	128K
Batch 최대 Output	300K Beta
Input	$4 / MTok
Output	$20 / MTok
5분 Cache Write	$5 / MTok
Cache Read	$0.20 / MTok
기본 Effort	Medium
Thinking	Adaptive Thinking
출력 속도	Opus 5 대비 30% 이상 향상
Fast Mode	최대 2.5x OTPS

Opus 5의 Input과 Output 가격은 각각:

Input
$5 / MTok

Output
$25 / MTok

이었습니다.

Opus 5.5에서는:

Input
$4 / MTok

Output
$20 / MTok

으로 내려갔습니다.

기본 토큰 가격부터 20% 인하된 셈입니다.

2. Cache Read 가격은 더 크게 내려갔다

Prompt Cache 쪽 변화는 더 큽니다.

Opus 5:

Cache Read
$0.50 / MTok

Opus 5.5:

Cache Read
$0.20 / MTok

입니다.

60% 인하입니다.

그리고 Fresh Input 가격과 비교하면 Cache Read는 5% 수준입니다.

Fresh Input
$4

Cache Read
$0.20

Claude Code처럼 같은 프로젝트 Context를 계속 읽는 환경에서는 꽤 중요한 차이입니다.

3. 그래서 20% 가격 인하가 40% 작업비용 절감으로 커진다

가격표만 보면 이렇게 생각하기 쉽습니다.

토큰 가격이 20% 싸졌네.

그런데 Anthropic은 Opus 5.5가 일반적인 작업을 Opus 5보다 약 40% 낮은 비용으로 처리한다고 설명합니다.

이유는 Agent의 비용이 단순히 토큰 단가만으로 결정되지 않기 때문입니다.

예를 들어 기존 Agent가:

코드 읽기
 ↓
수정
 ↓
Test 실패
 ↓
다시 읽기
 ↓
다시 수정
 ↓
다른 문제 발견
 ↓
또 수정

했다면,

더 효율적인 Agent는:

관련 코드 확인
 ↓
영향 범위 파악
 ↓
수정
 ↓
Test
 ↓
완료

로 끝낼 수 있습니다.

실제 작업비용은 결국:

토큰 가격
×
사용한 Token
×
Turn 수
×
Retry 수

에 가깝습니다.

Opus 5.5는 이 여러 요소를 동시에 줄였습니다.

4. 이번 변화에서 가장 중요한 건 기본 Effort가 Medium이라는 점이다

Opus 5의 기본 Effort는:

High

였습니다.

Opus 5.5는:

Medium

입니다.

이 변화가 꽤 중요합니다.

Effort가 높아지면 모델은 더 많이 생각합니다.

그만큼:

Thinking Token ↑

처리시간 ↑

비용 ↑

도 따라옵니다.

예전에는 높은 품질을 얻으려면 High를 기본처럼 사용하는 경우가 많았습니다.

Opus 5.5는 상당수 Coding 작업을 Medium에서도 높은 품질로 처리하는 것을 목표로 합니다.

5. Effort가 높다고 무조건 좋은 것은 아니다

Effort는 성능 등급이라기보다:

이 작업에 얼마나 많은 계산을 쓸 것인가

에 가깝습니다.

Low

이름 변경

반복적인 코드 수정

정해진 Pattern 적용

간단한 파일 정리

Medium

Feature 구현

일반 Bug Fix

Refactoring

일반적인 Code Review

High

복잡한 Debugging

Concurrency 문제

여러 Module에 걸친 수정

Architecture 영향 분석

XHigh / Max

대규모 분석

정말 어려운 문제

장시간 자율 작업

정도로 생각하면 쉽습니다.

평소 개발까지 무조건 High나 Max를 사용하는 것은 필요 없는 Thinking 비용을 추가하는 것일 수 있습니다.

6. Medium으로 충분한 작업이라면 High는 그냥 더 비싸다

Medium에서도 한 번에 끝나는 기능을 High로 실행했다고 해보겠습니다.

결과가 같다면 High에서는:

Thinking이 더 길고

Token을 더 사용하고

응답이 늦고

사용 한도도 더 빨리 소모

됩니다.

아무런 이득이 없습니다.

그래서 Opus 5.5에서는:

일단 Medium

으로 시작하는 전략이 훨씬 자연스러워졌습니다.

7. 반대로 어려운 문제에서는 High가 더 싸게 끝날 수도 있다

High가 항상 낭비라는 뜻은 아닙니다.

Medium이 어려운 문제에서:

수정
 ↓
실패

다시 분석
 ↓
수정

또 실패
 ↓
다시 수정

한다면 Turn이 계속 늘어납니다.

반대로 High가 처음부터:

문제 분석
 ↓
관련 호출부 확인
 ↓
영향 범위 파악
 ↓
수정
 ↓
Test 통과

로 끝낸다면 Thinking Token을 조금 더 써도 전체 비용은 더 낮아질 수 있습니다.

그래서 Effort를 고를 때 중요한 건:

얼마나 오래 생각했나?

보다

몇 번 만에 일을 끝냈나?

입니다.

8. Opus 5.5는 같은 일을 더 적은 Token으로 끝내는 방향도 개선됐다

Opus 5.5의 장점은 단순 가격 인하가 아닙니다.

Agent가 작업을 끝내기 위해 사용하는:

Thinking

Tool Call

Output

Retry

Turn

자체도 줄이는 방향으로 개선됐습니다.

Coding Agent는 한 번 답하고 끝나지 않습니다.

코드 검색
 ↓
파일 읽기
 ↓
수정
 ↓
Build
 ↓
Test
 ↓
Log 확인
 ↓
재수정

을 반복합니다.

각 단계에서 조금씩 효율이 좋아지면 긴 작업에서는 차이가 꽤 크게 벌어집니다.

9. 출력 속도도 빨라졌다

Opus 5.5는 Opus 5보다 Output Token 생성 속도가 30% 이상 빨라졌습니다.

Agent에서는 단순 답변 한 번의 속도보다 의미가 큽니다.

Reasoning
 ↓
Tool Call
 ↓
Result
 ↓
Reasoning
 ↓
Tool Call

을 여러 번 반복하기 때문입니다.

각 단계가 조금씩 빨라지면 전체 작업시간에서는 체감 차이가 더 커집니다.

10. Opus 5.5 비용에서 정말 중요한 건 Prompt Cache다

Claude Code를 오래 사용하면 Session 안에 이런 내용이 계속 쌓입니다.

System Prompt

CLAUDE.md

Skills

Tool Definitions

읽었던 Source Code

Conversation

Build Log

Test Result

Context가 100K 이상 커지는 것도 어렵지 않습니다.

다음 요청에서도 이 내용을 계속 사용합니다.

매번 전부 Fresh Input으로 다시 처리하면 비쌉니다.

그래서 Prompt Cache가 중요합니다.

11. 이미 읽은 Context는 훨씬 싸게 다시 읽는다

Opus 5.5 기준으로:

Fresh Input
$4 / MTok

Cache Read
$0.20 / MTok

입니다.

같은 Context를 다시 읽을 때 비용 차이가 20배입니다.

예를 들어 120K 정도의 Context가 이미 Cache에 있다면 다음 Turn에서는 대부분을 매우 저렴하게 다시 활용할 수 있습니다.

긴 Agent 작업에서는:

Token을 조금 줄이는 것

만큼이나

이미 만든 Cache를 유지하는 것

이 중요합니다.

12. 그래서 긴 Claude Code Session에서는 Cache를 깨지 않는 게 중요하다

이미 150K Context가 쌓여 있다고 해보겠습니다.

이 상태에서:

구현

Build

Test

Review

를 이어가면 앞의 Context 대부분은 계속 재사용됩니다.

그런데 설정을 바꿔 Cache가 깨지면:

150K Context
→ 다시 Cache Write

가 필요합니다.

Session이 길수록 이 비용은 커집니다.

13. Claude Code에서 Effort를 바꾸면 Cache가 다시 만들어질 수 있다

Claude Code에서:

/effort high

처럼 Effort를 바꿀 수 있습니다.

문제는 Effort나 Thinking 설정이 Prompt Cache 조건에 영향을 준다는 점입니다.

그래서:

Medium
 ↓
High
 ↓
Medium
 ↓
High

처럼 계속 변경하면 긴 Session에서는 Cache 효율이 떨어질 수 있습니다.

Effort는 필요할 때만 바꾸는 게 좋습니다.

14. Effort 변경은 작업 경계에서 하는 게 낫다

예를 들어:

Feature 구현
Medium

──── 구현 완료 ────

복잡한 Architecture Review
High

──── Review 완료 ────

다음 일반 작업
Medium

처럼 쓰는 편이 낫습니다.

작업 중간에 계속 Low, Medium, High를 오가는 것보다 자연스럽습니다.

15. API에서는 Cache를 유지하면서 Effort를 바꿀 수도 있다

Claude API에는 Per-message Effort라는 Beta 기능이 있습니다.

예를 들어:

Turn 1
Medium

Turn 2
Medium

Turn 3
이번 문제만 High

Turn 4
다시 Medium

처럼 특정 Turn만 Effort를 높일 수 있습니다.

이 방식은 기존 Prompt Cache를 유지하면서 사용할 수 있습니다.

그래서 구분하면:

Claude Code 일반 Effort 변경
→ Cache 재작성 가능

API Per-message Effort
→ Cache 유지 가능

입니다.

16. Per-message Effort 자체가 Opus 5.5에서 처음 나온 기능은 아니다

이 기능은 Opus 5.5만의 전용 기능은 아닙니다.

일부 이전 Claude 모델에서도 지원됩니다.

다만 Opus 5.5에서는:

기본 Medium

+

낮아진 Cache Read 가격

+

향상된 Token 효율

이 같이 들어오면서 훨씬 활용하기 좋아졌습니다.

17. Adaptive Thinking은 항상 켜져 있다

Opus 5.5에서는 Thinking을 단순히:

ON
OFF

하는 방식보다 Effort로 조절하는 방식이 중심입니다.

즉:

Thinking을 할까?

보다

얼마나 깊게 생각할까?

를 정하는 방식입니다.

다만 Adaptive Thinking이 켜져 있다고 모든 요청에서 길게 생각하는 것은 아닙니다.

간단한 문제라면 낮은 Effort에서 거의 바로 처리할 수 있습니다.

18. Context는 1M, 일반 Output은 128K다

Opus 5.5는:

Context
1,000,000 tokens

일반 Output
128K tokens

을 지원합니다.

Batch API Beta에서는 최대 300K Output도 지원합니다.

대규모 Repository 분석이나 Migration에는 꽤 넉넉합니다.

하지만 1M Context가 있다고 무조건 다 채우는 건 좋은 전략이 아닙니다.

19. Context가 크다고 다 넣으면 오히려 비싸다

예를 들어:

Repository 전체

오래된 Build Log

이미 끝난 Debugging 내용

필요 없는 Test 결과

까지 계속 Session에 들고 다닐 필요는 없습니다.

Cache Read가 싸다고 해도 무료는 아닙니다.

Context가 커지면 모델이 중요한 정보를 찾기도 어려워집니다.

그래서:

필요한 Context는 오래 유지하고

끝난 Context는 정리한다

가 중요합니다.

20. 그래서 /compact와 /clear가 중요하다

같은 업무를 계속하지만 Session이 너무 커졌다면:

/compact

를 사용할 수 있습니다.

완전히 다른 업무로 넘어간다면:

/clear

가 더 적합합니다.

예를 들어:

/compact
실패한 테스트와 API schema 변경 내용은 유지해줘

처럼 중요한 내용을 남길 수도 있습니다.

중요한 건 아무 때나 Compact하지 않는 것입니다.

Debugging 한가운데서 Context를 줄였다가 필요한 Log까지 사라지면 오히려 다시 읽어야 합니다.

21. Prompt도 Opus 5.5에 맞게 다시 볼 필요가 있다

이전 모델을 움직이기 위해 이런 규칙을 만들어둔 경우가 있습니다.

항상 6단계로 작업해라.

모든 변경 전에 긴 Plan을 작성해라.

항상 두 번 검증해라.

모든 내용을 자세하게 설명해라.

예전에는 도움이 됐을 수 있습니다.

하지만 Opus 5.5에서는 이런 규칙이:

불필요한 Output

추가 Tool Call

Turn 증가

를 만들 수도 있습니다.

모델이 바뀌었다면:

CLAUDE.md

Skills

Agent Rules

Prompt

도 한 번 정리하는 게 좋습니다.

22. 테스트가 잘 되어 있으면 High Effort를 쓸 일도 줄어든다

Medium에서 코드 하나를 놓쳤다고 바로:

Medium
→ High

로 올릴 필요는 없습니다.

Agent가 스스로 결과를 확인할 수 있다면 상황이 달라집니다.

Build

Unit Test

Integration Test

Lint

Static Analysis

를 실행할 수 있으면 Medium에서도 실수를 발견하고 다시 고칠 수 있습니다.

Agent 개발에서는:

더 많이 생각하게 하기

보다

틀렸는지 바로 확인할 수 있게 하기

가 더 중요한 경우가 많습니다.

23. Task Budget도 Agent 개발에서는 재미있는 기능이다

API 기반 Agent를 직접 만든다면 Task Budget도 사용할 수 있습니다.

Effort와 역할이 다릅니다.

Effort
→ 한 단계에서 얼마나 깊게 생각할까

Task Budget
→ 전체 작업에 얼마를 쓸까

입니다.

예를 들어:

Search

파일 읽기

Tool Call

수정

Test

전체에 일정한 Token Budget을 주는 식입니다.

현재 Beta 기능이며 일반 Claude Code 기능과는 구분해서 봐야 합니다.

24. Fast Mode는 비용 절감 기능이 아니다

Opus 5.5에는 Fast Mode도 있습니다.

같은 Opus 5.5를 더 빠른 Inference 환경에서 실행합니다.

일반 가격:

Input
$4

Output
$20

Fast Mode:

Input
$8

Output
$40

수준입니다.

즉 Fast Mode는:

비용을 줄이는 기능

이 아니라

돈을 더 내고 응답시간을 줄이는 기능

입니다.

실시간 Agent나 긴 Streaming Output에서 속도가 중요한 경우에 맞습니다.

25. Tool Calling도 확인해야 한다

API Agent를 직접 만들고 있다면 Model ID만 바꿔서는 안 됩니다.

Opus 5.5에서는 기존 Tool 강제 선택 방식 일부가 달라졌고:

Strict Tool Use

Structured Output

쪽을 다시 확인해야 합니다.

Computer Use도 새로운 Toolset 구조를 사용합니다.

기존 Agent Framework를 운영한다면 Migration 전에:

Tool Choice

Thinking

Effort

Computer Use

max_tokens

를 같이 점검하는 게 좋습니다.

26. Opus 5.5가 일상용 Opus가 된 이유

기존 Opus는 성격이 명확했습니다.

정말 어려운 문제
→ Opus

였습니다.

성능은 좋았지만 모든 Coding Task에 쓰기에는 부담이 있었습니다.

Opus 5.5에서는:

Input / Output 20% 인하

Cache Read 60% 인하

기본 Medium

적은 Turn

적은 Retry

빠른 Output

이 같이 들어왔습니다.

그래서 최고급 모델인데도 일상적인 Coding에 쓰기 훨씬 쉬워졌습니다.

27. Claude Code에서는 이렇게 시작하면 된다

복잡하게 생각할 필요 없습니다.

단순 반복 작업

Low

일반 개발

Medium

복잡한 Debugging

High

정말 어려운 문제

XHigh / Max

그리고 Medium이 한 번 틀렸다고 바로 High로 올리지 않습니다.

먼저:

Test가 있나?

Build를 돌릴 수 있나?

Agent가 자기 결과를 검증할 수 있나?

를 확인하는 편이 좋습니다.

28. 같은 작업에서 사용 한도 소모도 줄었다

Opus 5.5의 낮아진 가격은 Claude 구독 사용 한도에도 반영됩니다.

Anthropic 설명에 따르면 가격 차이만 놓고도 Opus 5보다 사용 한도가 약 25% 더 오래 갑니다.

여기에:

적은 Turn

적은 Retry

적은 Output

저렴한 Cache

가 같이 적용됩니다.

그래서 실제 사용자는 같은 시간 동안 더 많은 작업을 처리할 수 있습니다.

표현도:

사용량이 덜 줄어든다

보다는:

같은 작업에서 사용 한도 소모가 줄었다

가 정확합니다.

29. 그런데 이번에 더 중요한 숫자는 40%다

Opus 5.5에서 가장 눈에 들어오는 공식 수치는:

약 40% 낮아진 작업비용

입니다.

이건:

토큰을 40% 적게 쓴다

는 뜻이 아닙니다.

더 정확한 의미는:

가격 인하

+

Cache 비용 감소

+

필요한 Token 감소

+

Turn 감소

+

Retry 감소

를 합쳤을 때 같은 일을 완료하는 총비용이 약 40% 낮아졌다는 것입니다.

이쪽이 훨씬 중요한 변화입니다.

30. Opus 5에서 넘어간다면 High부터 다시 볼 필요가 있다

기존 설정이:

Opus 5
High

였다고 해서 5.5에서도 그대로 High를 유지할 필요는 없습니다.

먼저:

Opus 5.5
Medium

으로 같은 작업을 돌려보는 게 좋습니다.

충분하면 그대로 씁니다.

부족한 작업만 High로 올립니다.

이것만으로도:

Thinking

Latency

Token

사용 한도

를 꽤 줄일 수 있습니다.

31. Opus 5 → 5.5 Migration Checklist

API를 직접 쓰고 있다면 이 정도는 확인하는 게 좋습니다.

1. Model ID 변경

2. Thinking 설정 확인

3. 기본 Effort 다시 측정
   High부터 쓰지 말고
   Medium부터 시작

4. Tool Choice 변경사항 확인

5. Structured Output / Strict Tool Use 확인

6. Computer Use Toolset 확인

7. max_tokens 확인

8. Prompt Cache 동작 확인

9. CLAUDE.md / Skill 정리

10. 실제 Repository Task로
    Opus 5와 비용 비교

Benchmark보다 자기 프로젝트에서 Feature 하나, Bug 하나를 실제로 해결해보는 게 훨씬 정확합니다.

마치며

Claude Opus 5.5를 단순히:

Opus 5보다 더 좋은 모델

이라고 설명하면 이번 변화의 핵심을 놓치게 됩니다.

이번에는:

성능 ↑

가격 ↓

Cache 가격 ↓↓↓

기본 Effort
High → Medium

Thinking 효율 ↑

Turn ↓

Retry ↓

출력 속도 ↑

가 같이 움직였습니다.

그래서 가장 눈에 들어오는 숫자가:

Opus 5 대비 약 40% 낮아진 작업비용

입니다.

최고급 Opus를 쓰면서도 이전보다 부담이 크게 줄었습니다.

그리고 개발자에게는 숫자보다 더 중요한 변화가 있습니다.

예전에는:

좋은 품질이 필요하다
→ High

더 어려운 문제다
→ 더 오래 Thinking

에 가까웠다면,

이제는:

평소 개발
→ Medium

단순 작업
→ Low

정말 어려운 문제
→ High

정도로 시작할 수 있습니다.

더 오래 생각하게 만드는 것보다 필요한 만큼만 생각하게 하는 게 중요해졌습니다.

긴 Claude Code 세션에서는 여기에 Prompt Cache까지 잘 유지하면 비용 차이는 더 커집니다.

Opus 5.5를 한 문장으로 정리하면 이렇습니다.

성능 좋은 Opus가 하나 더 나온 게 아니라, 매일 써도 될 만큼 효율 좋은 Opus가 나왔습니다.

참고자료

Anthropic — Introducing Claude Opus 5.5
Opus 5.5의 성능 향상, Agentic Coding, Early Tester 사례와 비용 효율에 대한 공식 발표입니다.
Claude Opus 5.5 공식 발표

Claude — What a task costs on Opus 5.5
Token 단가만이 아니라 Turn, Retry, Thinking, Prompt Cache를 포함해 실제 Claude Code Task 하나의 비용이 어떻게 결정되는지 설명합니다. Claude Code에서 Effort 변경 시 Cache가 다시 작성될 수 있다는 부분도 확인할 수 있습니다.
Opus 5.5 작업 비용 분석

Claude Platform — Opus 5.5 Model Overview
1M Context, 128K Output, 300K Batch Output, 가격과 Prompt Cache 사양을 확인할 수 있습니다.
Opus 5.5 모델 사양

Claude Platform — Effort
Low·Medium·High·XHigh·Max의 역할과 Effort가 Thinking·Latency·비용에 미치는 영향, API의 Per-message Effort와 Cache 유지 방식을 설명합니다.
Claude Effort 공식 문서

Claude Platform — Prompting Claude Opus 5.5
Opus 5보다 30% 이상 빨라진 Output 생성과 Effort Calibration, Opus 5.5에 맞는 Prompt/Harness 작성 방법을 설명합니다.
Opus 5.5 Prompting Guide

Claude Platform — What's new in Opus 5.5
Inline Tool Addition, Compaction, Prompt Cache, Task Budget 등 Opus 5.5에서 지원하는 최신 Agent 기능을 정리한 공식 문서입니다.
Opus 5.5 새로운 기능

Claude Platform — Migration Guide
Opus 5에서 5.5로 변경할 때 Thinking 설정, Tool Choice, Computer Use Toolset 등 실제 코드에서 수정해야 하는 Breaking Change를 정리합니다.
Opus 5.5 Migration Guide

Claude Platform — Task Budgets
Effort가 각 단계의 추론 깊이를 조절한다면 Task Budget은 전체 Agent Loop가 소비할 작업량을 조절한다는 차이를 확인할 수 있습니다.
Task Budgets 공식 문서

Claude Platform — Fast Mode
동일 Opus 모델에서 최대 2.5배 높은 Output Token 속도를 제공하는 Research Preview 기능과 별도의 Premium 가격을 설명합니다.
Fast Mode 공식 문서

Codex와 Claude 플러그인 생태계

ekyu — Thu, 24 Sep 2026 14:49:38 +0900

Codex와 Claude 플러그인 생태계

Jira·Confluence·Figma부터 GitHub·Worktree·공유드라이브까지 개발 업무는 어디까지 연결될까

처음 Codex나 Claude Code를 사용할 때는 역할이 단순했습니다.

Repository
    ↓
AI Agent
    ↓
코드 수정
    ↓
Build / Test

하지만 2026년의 AI 개발환경은 여기서 상당히 멀리 왔습니다.

이제 Agent가 연결되는 범위는:

Jira
Confluence
Figma
GitHub
Slack
Teams
Google Drive
SharePoint
OneDrive
Notion
Linear
Database
사내 MCP

까지 넓어졌습니다.

여기에:

Plugin
Connector
Skill
MCP
Subagent
Worktree
Hook
Cloud Agent

가 결합합니다.

그래서 이제 단순히:

Codex가 코드를 더 잘 짜나, Claude가 더 잘 짜나?

만 비교해서는 부족합니다.

개발자가 실제로 봐야 할 것은:

어떤 Agent가 요구사항부터 디자인, 코드, QA, 문서까지 우리 개발 Workflow 전체를 얼마나 자연스럽게 연결하는가

입니다.

1. Plugin, Connector, Skill, MCP부터 구분하자

이름이 많지만 개발자 관점에서는 네 가지 정도로 나누면 이해하기 쉽습니다.

Plugin

여러 기능을 하나의 업무 Workflow로 묶은 Package입니다.

예를 들어:

Atlassian Plugin

├─ Jira 연결
├─ Confluence 연결
├─ 관련 Skill
└─ 업무 Workflow

처럼 구성할 수 있습니다.

현재 OpenAI Plugin은 Skill, Connected App, App Template 등을 하나의 재사용 가능한 Workflow 단위로 묶을 수 있고 Codex의 지원되는 Task View에서도 직접 사용할 수 있습니다.

Claude Plugin 역시 MCP, Skill, Tool 등을 한 번에 설치하는 형태로 확장되고 있습니다.

2. Connector와 App은 외부 서비스를 연결한다

Connector는:

GitHub

Jira

Confluence

Figma

Google Drive

Slack

SharePoint

같은 외부 서비스에 Agent가 접근할 수 있도록 연결합니다.

중요한 것은 기존 서비스 권한을 그대로 사용한다는 것입니다.

내가 접근 가능한 Jira Issue
→ Agent도 접근 가능

권한 없는 Confluence Space
→ Agent도 접근 불가

입니다.

Plugin을 설치했다고 회사 시스템의 권한이 자동으로 확장되는 것은 아닙니다.

3. Skill은 ‘어떻게 일할지’를 알려준다

Tool이 무엇을 할 수 있는지 알려준다면 Skill은:

이 작업을 어떤 순서로 처리할 것인가?

를 정의합니다.

예를 들어:

iOS Release Skill

1. Build
2. Unit Test
3. Simulator Smoke Test
4. Version 확인
5. Release Note 작성
6. Jira Release Issue 업데이트
7. Confluence 변경사항 정리

같은 방식입니다.

Agent가 바뀌더라도 팀의 작업 절차는 Skill로 유지할 수 있습니다.

4. MCP는 AI와 Tool을 연결하는 공통 규격이다

MCP는 Plugin이 아니라 Protocol입니다.

예를 들면:

Codex
 ↓
Figma MCP
 ↓
Figma

또는:

Claude
 ↓
Atlassian Rovo MCP
 ↓
Jira / Confluence

또는 iOS 개발에서:

Codex
 ↓
XcodeBuildMCP
 ↓
Xcode / Simulator

처럼 사용합니다.

정리하면:

Plugin
→ 업무 Package

Connector / App
→ 외부 서비스 연결

Skill
→ 반복 작업 방법

MCP
→ Tool 통신 규격

입니다.

이제 실제 개발업무에 넣어보자

5. 개발업무의 시작은 GitHub보다 Jira인 경우가 많다

회사 개발은 대부분 코드부터 시작하지 않습니다.

먼저:

신규 기능
Bug
고객 요청
운영 이슈
개선사항

이 생기고 Jira Task가 만들어집니다.

예를 들어:

MOB-210

iOS 결제 화면에서
중복 결제 가능성 수정

이라고 해보겠습니다.

기존에는 개발자가 직접:

Jira 확인

↓
Confluence 검색

↓
Slack 검색

↓
Figma 확인

↓
Repository 확인

↓
Agent에게 Context 전달

해야 했습니다.

이제 이 단계 자체를 Agent에 연결할 수 있습니다.

6. Codex에서도 Atlassian Rovo Plugin을 사용할 수 있다

OpenAI Plugin Directory에는 Atlassian이 만든 Atlassian Rovo Plugin이 있습니다.

이 Plugin은:

Jira

Confluence

Compass

Context를 가져오고 Action까지 연결할 수 있습니다.

예를 들어:

MOB-210의

Description
Acceptance Criteria
Subtask
Owner

를 정리해줘.

또는:

이번 Incident 관련
Confluence 문서를 찾아서

Root Cause와
Mitigation을 정리해줘.

같은 요청이 가능합니다.

OpenAI의 Plugin 구조는 ChatGPT뿐 아니라 지원되는 Codex Task View에서도 설치된 Plugin을 Source로 선택할 수 있습니다.

7. 대화를 Jira Task로 바로 만들 수도 있다

예를 들어 회의 중:

로그인 실패가 5회 이상이면
계정을 30분 동안 잠그자.

관리자가 수동으로
해제할 수도 있어야 한다.

라는 결정이 나왔다고 해보겠습니다.

Agent에게:

이 내용을 Jira Task로 정리해.

Title
Description
Acceptance Criteria
Subtasks
Owner 후보

까지 만들어줘.

라고 요청할 수 있습니다.

즉:

회의 / 아이디어

      ↓

AI 정리

      ↓

Jira Work Item

로 바로 이어집니다.

Confluence는 ‘왜’를 담당한다

8. Jira와 Confluence의 역할은 다르다

개발자가 둘을 이렇게 생각하면 편합니다.

Jira

무엇을 할 것인가

누가 할 것인가

언제 할 것인가

현재 상태는 무엇인가

Confluence

왜 이렇게 설계했는가

Architecture

Decision

Requirement

Meeting Note

Runbook

Migration Guide

입니다.

즉:

Jira
→ What

Confluence
→ Why

라고 볼 수 있습니다.

9. Jira만 보는 Agent와 Confluence까지 보는 Agent는 결과가 다르다

Jira에:

Payment API v3 적용

이라고만 적혀 있다고 해보겠습니다.

반면 Confluence에는:

Payment Architecture v3

- 인증 방식 변경
- Retry 정책
- Error Code
- Migration 순서
- 기존 API 종료 일정

가 있습니다.

Jira만 보면 Agent가:

Task
→ 바로 코딩

할 수 있습니다.

하지만 Confluence까지 확인하면:

Task
+
Architecture
+
Decision History

      ↓

Impact Analysis

      ↓

Implementation Plan

부터 만들 수 있습니다.

AI Agent 시대에는 이 Context 차이가 생각보다 큽니다.

이제 Figma가 들어온다

10. Jira가 ‘무엇’, Confluence가 ‘왜’라면 Figma는 ‘어떻게 보여야 하는가’다

UI 개발에서는 요구사항과 설계 문서만으로 부족합니다.

실제 구현해야 하는 모습은 Figma에 있습니다.

Jira
→ 무엇을 만들지

Confluence
→ 왜 그렇게 설계했는지

Figma
→ 실제 UI가 어떻게 보여야 하는지

GitHub
→ 실제로 무엇을 만들었는지

입니다.

이 네 가지가 연결되면 Agent가 보는 Context가 훨씬 완성됩니다.

11. Codex와 Figma는 양방향 연결이 꽤 강하다

2026년 OpenAI와 Figma는 Codex–Figma 직접 연동을 발표했습니다.

Figma MCP Server를 Codex와 연결하면:

Figma Design
     ↓
Codex
     ↓
Implementation

뿐 아니라:

현재 Code
   ↓
Codex
   ↓
Figma / FigJam

방향도 사용할 수 있습니다.

즉 단순한 Design-to-Code가 아닙니다.

Code
↔
Design Canvas

사이를 오가는 Workflow를 목표로 합니다.

OpenAI와 Figma의 공식 연동은 Figma Make, FigJam까지 연결합니다.

12. Codex에서 Figma Plugin 자체도 활용할 수 있다

Figma Plugin은 단순 디자인 파일 읽기보다 범위가 넓습니다.

예를 들어:

Wireframe

Storyboard

Flow Diagram

Gantt Chart

Slide Deck

Design Asset

을 생성할 수 있습니다.

예를 들어 PRD가 있다면:

Google Drive
    ↓
PRD
    ↓
Codex + Figma
    ↓
User Flow
    ↓
Figma Wireframe

처럼 연결할 수 있습니다.

또 기존 서비스 Flow를 코드에서 분석한 다음 FigJam Diagram으로 만들 수도 있습니다.

13. Claude Code에도 Figma Plugin이 있다

Claude도 Figma가 약한 것은 아닙니다.

Figma가 직접 만든 Claude Code Plugin이 있습니다.

이 Plugin은:

Figma Frame

↓
Layout

Typography

Color

Design Token

Component

↓
Claude Code

↓
Production Code

흐름에 상당히 잘 맞습니다.

특히:

/implement-design

/create-design-system-rules

/code-connect-components

같은 Skill이 제공됩니다.

Figma Component와 실제 Code Component를 매핑하고 Design Token을 읽어 기존 Design System에 맞춰 구현하는 Workflow가 꽤 구체적입니다.

14. Figma만 놓고 보면 둘의 성격이 조금 다르다

Codex

Code
↔
Figma

Design 생성
Diagram 생성
Slide 생성
FigJam
Implementation

까지 넓게 연결되는 느낌이 강합니다.

Claude Code

Figma
 ↓
Design Context
 ↓
Existing Codebase
 ↓
Implementation

즉 정확한 Design-to-Code와 Design System 준수에 강점이 있습니다.

그래서 단순히:

누가 Figma를 지원하나?

가 아니라,

어떤 방향으로 Figma를 쓰고 싶은가?

를 봐야 합니다.

여기서 Worktree가 등장한다

15. Git Worktree는 Plugin이 아니다

GitHub Plugin과 Worktree는 완전히 다른 개념입니다.

GitHub
→ 원격 Repository / Issue / PR

Worktree
→ 로컬 작업공간 분리

입니다.

예를 들어:

Repository

├─ Worktree A
│   → MOB-210

├─ Worktree B
│   → MOB-211

└─ Worktree C
    → MOB-212

처럼 만들 수 있습니다.

Multi-Agent 개발에서 상당히 중요한 기능입니다.

16. Codex는 Local / Worktree / Cloud를 하나의 실행 선택지로 제공한다

Codex에서는 작업을:

Local

Worktree

Cloud

형태로 나눌 수 있습니다.

예를 들어:

Codex A
→ Login Refactoring

Codex B
→ Swift 6 Migration

Codex C
→ Unit Test

를 각각 다른 Worktree에서 돌릴 수 있습니다.

Main Working Directory를 직접 건드리지 않고 작업을 분리할 수 있다는 것이 장점입니다.

Codex에서는 이 Worktree Workflow가 Desktop 개발 경험 안에 상당히 자연스럽게 들어와 있습니다.

17. Claude Code도 Worktree를 지원한다

Claude Code에서도:

claude --worktree

를 이용할 수 있고 Subagent를 Worktree에 격리하는 것도 가능합니다.

예를 들면:

Main Claude

├─ Agent A
│   → Worktree A

├─ Agent B
│   → Worktree B

└─ Agent C
    → Worktree C

입니다.

Claude는 특히 Subagent + Worktree 조합이 강점입니다.

GitHub까지 연결하면 코드 Workflow가 완성된다

18. GitHub Plugin은 Issue부터 PR·CI까지 이어진다

GitHub 연결을 하면 Agent가:

Repository

Issue

PR

Review Comment

CI Check

Context를 가져올 수 있습니다.

예를 들어:

현재 PR의 Review Comment를 처리해.

실패한 CI Check 원인을 조사하고

필요한 수정을 한 뒤
관련 Test를 다시 실행해.

같은 Workflow를 만들 수 있습니다.

전체는:

Jira
 ↓
Requirement

Confluence
 ↓
Architecture

Figma
 ↓
UI

Codex / Claude
 ↓
Worktree

GitHub
 ↓
PR / CI

가 됩니다.

Slack과 Teams도 빼기 어렵다

19. 실제 최신 정보가 Slack에만 있는 경우가 많다

Jira와 Confluence가 항상 최신 상태인 것은 아닙니다.

실제 회사에서는:

"Backend API Response가
오늘 오전에 다시 바뀌었습니다."

같은 중요한 정보가 Slack Thread에만 있을 수 있습니다.

그래서 Agent에게:

MOB-210 Jira와
관련 Confluence 문서를 확인하고

최근 Slack 논의에서
변경된 요구사항이 있는지도 찾아줘.

라고 요청할 수 있습니다.

20. Microsoft 환경이라면 Teams + SharePoint다

회사에서 Microsoft 365를 사용한다면:

Slack
→ Teams

Google Drive
→ SharePoint / OneDrive

로 바뀝니다.

OpenAI Plugin 생태계에서도:

Outlook

Teams

SharePoint

OneDrive

를 연결할 수 있습니다.

Claude 역시 Microsoft 365 Connector를 통해 SharePoint, OneDrive, Outlook, Teams를 연결합니다.

공유드라이브도 개발 Context다

21. 개발 문서는 Repository 밖에도 많다

실제 프로젝트에서 이런 자료는 Drive에 있는 경우가 많습니다.

API Specification.pdf

Architecture.pptx

QA Checklist.xlsx

Security Policy.pdf

Release Plan.xlsx

Agent에게:

Google Drive의
Payment API v3 문서를 찾아.

현재 Repository 구현과 비교해서
Spec과 다른 부분을 정리해.

라고 할 수 있습니다.

이제:

Code
+
Document

를 동시에 보는 것이 가능합니다.

22. Google Drive는 Docs·Sheets·Slides까지 개발 업무에 들어온다

예를 들면:

Docs
→ Requirement / Architecture

Sheets
→ QA Matrix / 일정

Slides
→ Architecture / 발표자료

입니다.

그래서:

Drive
 ↓
Agent
 ↓
Repository
 ↓
Migration Plan

형태로 사용할 수 있습니다.

Claude 역시 Google Drive Connector를 제공하고 있습니다.

Confluence는 개발 완료 후 다시 등장한다

23. 코드를 바꿨다면 문서도 같이 바뀌어야 한다

개발팀에서 흔한 문제는:

Code
→ 최신

Confluence
→ 6개월 전

입니다.

Agent에게:

이번 PR에서 Architecture가 변경된 부분을 찾아.

기존 Confluence 문서와 비교해서
수정해야 할 Section을 정리해.

라고 할 수 있습니다.

지원되는 Write Action을 사용한다면 실제 Page 업데이트까지 연결할 수도 있습니다.

Atlassian Rovo MCP는 Jira와 Confluence를 검색하는 것뿐 아니라 지원되는 범위에서 생성·수정까지 제공합니다.

24. Incident 대응에도 이 조합이 잘 맞는다

Production 장애가 생기면 Context는 보통 여러 곳에 흩어져 있습니다.

Jira
→ Incident

Slack
→ 대응 내용

GitHub
→ Commit

Logs
→ Error

Confluence
→ Postmortem

Agent가 이를 모아서:

Timeline

Root Cause

Mitigation

Action Items

을 만들 수 있습니다.

그리고 Action Item을 Jira Task로 다시 만들고 Postmortem은 Confluence에 남기는 Workflow도 가능합니다.

이제 전체 개발 Workflow를 연결해보자

25. 기능 하나를 개발한다고 하면

새 기능:

Jira

MOB-310
새 결제 인증 방식 적용

이 들어왔다고 해보겠습니다.

1단계 — 요구사항 확인

Jira
+
Confluence
+
Slack

을 Agent가 확인합니다.

2단계 — UI 확인

Figma

에서 새로운 화면과 Component를 확인합니다.

3단계 — 구현 계획

Agent가:

Repository

Jira

Confluence

Figma

Slack

을 함께 보고 Impact Analysis를 만듭니다.

4단계 — Worktree 생성

MOB-310
 ↓
Worktree

로 격리합니다.

5단계 — 구현

Codex / Claude Code
      ↓
Implementation

6단계 — Build / Test

Build

Unit Test

Integration Test

iOS라면:

XcodeBuildMCP
      ↓
Simulator QA

까지 연결할 수 있습니다.

7단계 — GitHub PR

Diff

Test Result

Risk

Screenshot

을 정리해서 PR을 준비합니다.

8단계 — CI / Review

실패한 CI가 있으면 다시 Agent가 원인을 분석합니다.

9단계 — Jira 업데이트

Status

PR Link

Implementation Summary

QA Result

를 업데이트합니다.

10단계 — Confluence 갱신

Architecture가 바뀌었다면 관련 문서를 업데이트합니다.

11단계 — 공유

Slack / Teams

Drive / SharePoint

에 Release Note나 변경 내용을 공유합니다.

전체를 한 번에 보면:

                   Jira
              무엇을 만들까
                     ↓
                Confluence
                왜 만들까
                     ↓
                  Figma
             어떻게 보여야 할까
                     ↓
        ┌────────────┼────────────┐
        ↓            ↓            ↓
      Slack        Drive        GitHub
     팀 논의        자료          코드
        └────────────┼────────────┘
                     ↓
              Codex / Claude
                     ↓
                 Worktree
                     ↓
                   Code
                     ↓
              Build / Test
                     ↓
             Simulator / QA
                     ↓
                 GitHub PR
                     ↓
                Jira 완료
                     ↓
             Confluence 갱신
                     ↓
           Slack / Drive 공유

이게 현재 AI Coding Plugin 생태계가 만들어가고 있는 개발 Workflow입니다.

Codex를 쓴다면 어떻게 구성할까

26. Codex 개발자 기본 구성

처음에는 이 정도면 충분합니다.

Atlassian Rovo
→ Jira / Confluence

Figma
→ UI / Diagram / Design

GitHub
→ Code / PR / CI

Slack 또는 Teams
→ 팀 Context

Google Drive 또는 SharePoint
→ 문서

그리고 Local에는:

AGENTS.md

Skills

Worktree

MCP

를 둡니다.

iOS라면:

XcodeBuildMCP

를 추가합니다.

이렇게 하면:

Requirement
Design
Code
Test
QA
Documentation

이 한 Agent Workspace에 거의 다 들어옵니다.

Claude를 쓴다면

27. Claude 개발자 구성도 상당히 강력하다

Claude는:

Atlassian MCP
→ Jira / Confluence

Figma Plugin
→ Design-to-Code

GitHub Plugin
→ Repository / PR

Slack Connector

Google Drive

Microsoft 365

등을 사용할 수 있습니다.

Local 개발에서는:

Claude Code

CLAUDE.md

Skills

Subagents

Worktree

Hooks

MCP

를 조합합니다.

Claude의 Plugin Directory도 현재 상당히 커졌고 GitHub, Figma, Playwright, Linear, Supabase, Vercel, Database Tool 같은 개발 Plugin이 빠르게 늘고 있습니다.

그러면 지금은 Codex와 Claude 중 어느 쪽이 더 강할까

28. Plugin 숫자만 보면 둘 다 이미 상당히 크다

단순히:

Plugin이 더 많은 쪽이 좋다.

라고 보기는 어렵습니다.

Claude도 현재 수백 개의 Connector를 제공하고 있고 Claude Code Plugin 생태계도 굉장히 빠르게 커지고 있습니다.

특히:

Subagent

Hooks

Worktree Isolation

Design-to-Code

Plugin 기반 개발 자동화

는 Claude Code의 강점입니다.

29. 그래도 전체 개발 Workflow를 묶는 관점에서는 Codex 쪽이 조금 더 강하게 느껴진다

현재 Codex가 특히 재미있는 이유는:

Local

Worktree

Cloud

Plugin

Connected App

Skill

Computer Use

Browser

GitHub

Figma

Atlassian

Drive

문서 제작

이 하나의 제품 환경 안으로 계속 들어오고 있기 때문입니다.

특히 Codex Desktop에서:

Repository
→ Worktree
→ Plugin
→ Tool
→ Cloud Context

를 하나의 Task 흐름으로 연결하는 방향이 상당히 명확합니다.

OpenAI Plugin도 ChatGPT에서만 쓰는 부가기능이 아니라 지원되는 Codex Task 자체에서 Source로 선택할 수 있습니다.

이 부분이 현재 큰 장점입니다.

30. Figma에서도 Codex의 범위가 조금 더 넓다

Claude Code의 Figma Plugin은 상당히 좋습니다.

특히:

Figma
→ Design Token
→ Component Mapping
→ Production Code

에서는 오히려 Claude가 굉장히 구체적입니다.

하지만 Codex–Figma 공식 연동은:

Figma
→ Code

뿐 아니라:

Code
→ Figma

까지 양방향 Workflow를 강조합니다.

그리고 별도 Figma Plugin에서:

Diagram

Slide

Asset

Storyboard

Wireframe

까지 생성할 수 있습니다.

개발 + 디자인 + 문서화 전체로 보면 Codex 쪽 범위가 더 넓게 느껴지는 이유입니다.

31. 업무 Context 연결도 Codex가 상당히 넓다

Codex 쪽 Plugin 생태계에서는:

Jira / Confluence

GitHub

Slack

Teams

Google Drive

SharePoint

OneDrive

Figma

Outlook

을 하나의 OpenAI Workspace에서 사용할 수 있습니다.

즉 개발 외에도:

문서 작성

PPT

Spreadsheet

메일

회사 Knowledge

까지 같은 제품 생태계 안으로 연결됩니다.

최근 ChatGPT Work와 Codex의 통합 방향까지 생각하면 개발자 업무와 일반 지식 업무 사이의 경계가 상당히 얇습니다.

반대로 Claude가 더 좋은 부분도 분명하다

32. Claude Code의 Subagent와 Hook 구조는 여전히 매력적이다

Claude에서는:

Main Agent
   ↓
Subagent
   ↓
Worktree

를 상당히 자연스럽게 만들 수 있습니다.

특히:

Architecture Agent

Research Agent

Review Agent

Implementation Agent

처럼 역할을 명시적으로 나누는 데 좋습니다.

Hook도:

Agent가 특정 명령을 실행하기 전

특정 파일 수정 후

작업 완료 시

같은 자동 제어를 넣는 데 유용합니다.

이쪽은 Claude Code의 특징이 강하게 남아 있습니다.

33. Claude의 Figma Design-to-Code는 여전히 상당히 좋다

특히 기존 Design System이 잘 만들어진 회사라면:

Figma Component

↓ Code Connect

실제 Component

↓ Design Token

Production Code

Workflow가 중요합니다.

Claude Figma Plugin은 이 부분이 상당히 구체적으로 설계되어 있습니다.

그래서:

Figma 디자인을 기존 Frontend Design System에 최대한 정확하게 구현한다.

가 핵심이라면 Claude Code가 여전히 좋은 선택입니다.

하지만 Claude가 상대적으로 아쉬운 부분도 있다

34. 기능이 여러 Surface에 조금 더 분산돼 있다

Claude는 기능이:

Claude

Claude Code

Cowork

Connector

Desktop Extension

Plugin

MCP

로 나뉩니다.

기능적으로는 강력하지만 처음 사용하는 개발자 입장에서는:

이 Plugin은 어디서 실행되지?

이 Connector는 Claude Code에서도 되나?

이건 Desktop Extension인가?

이 Subagent는 Cowork인가?

를 구분해야 하는 경우가 있습니다.

Codex도 제품 Surface가 여러 개 있지만 최근에는 Desktop의 Codex와 Work, Plugin 체계가 비교적 한 방향으로 통합되고 있습니다.

사용하면서 느끼는 구조적 단순함에서는 현재 Codex 쪽이 조금 유리한 편입니다.

35. 개발 외 업무까지 넘어가면 Codex 생태계가 더 자연스럽다

개발자가 실제 하는 일에는:

Architecture PPT

기술 보고서

Spreadsheet

Executive Summary

Release Mail

회의자료

도 포함됩니다.

OpenAI 쪽은:

Codex
+
ChatGPT Work
+
Plugin
+
Document
+
Presentation
+
Spreadsheet

를 같은 계정과 Workspace에서 연결합니다.

그래서:

코드 작성
↓
QA
↓
보고서
↓
PPT
↓
메일

까지 이어가기가 자연스럽습니다.

Claude도 문서와 파일 생성을 지원하지만 현재 전체 Workflow의 연결 범위와 시각·문서 제작까지 합치면 OpenAI 쪽이 조금 더 한 덩어리로 느껴집니다.

36. 한 번에 비교하면

영역	Codex / OpenAI	Claude / Claude Code
코드 작성	매우 강함	매우 강함
Repository 분석	매우 강함	매우 강함
Worktree	제품 Workflow에 깊게 통합	강함
Cloud Coding	강함	강함
Subagent	강함	특히 강함
Hooks	가능/Workflow 중심	강점
GitHub	강함	강함
Jira / Confluence	Atlassian Rovo Plugin + MCP	Atlassian MCP
Figma	Code↔Design + Plugin	Design→Code 강점
Slack / Teams	둘 다 연결	Slack + Microsoft 365
Google Drive	강함	강함
SharePoint / OneDrive	강함	강함
문서/PDF	Work 통합 강점	강함
Spreadsheet	Work 통합 강점	강함
PPT/Presentation	Work + Figma 등 강점	가능
이미지 생성	직접 연결 강점	상대적으로 외부 의존
Computer Use	Codex/Work 통합	Desktop/Cowork 계열
개발→업무 전체 연결	현재 특히 강점	강하지만 다소 분산

37. 현재 기준으로는 이렇게 정리할 수 있다

순수 Coding Agent 성능만 놓고:

Codex > Claude

라고 단순하게 말하기는 어렵습니다.

둘 다 충분히 강하고 작업 종류에 따라 결과가 달라집니다.

하지만 이번 글에서 본 것처럼:

Jira
+
Confluence
+
Figma
+
GitHub
+
Worktree
+
Slack / Teams
+
Drive / SharePoint
+
MCP
+
문서
+
PPT

까지 개발자의 전체 업무환경을 기준으로 보면 현재는 Codex/OpenAI 쪽이 한 단계 더 넓게 연결되어 있다는 느낌이 강합니다.

특히:

Code

Design

Business Context

Documents

Presentation

Computer Use

가 하나의 Workspace 안에서 연결되는 것이 큰 차이입니다.

마치며

예전에는 개발환경을 이렇게 생각했습니다.

IDE

Git

Terminal

CI

지금은 여기에:

Agent

Plugin

Connector

Skill

MCP

Worktree

Company Knowledge

가 추가되고 있습니다.

그리고 실제 업무를 놓고 보면:

Jira
→ 무엇을 해야 하는가

Confluence
→ 왜 그렇게 해야 하는가

Figma
→ 어떻게 보여야 하는가

Slack / Teams
→ 지금 무엇을 논의하고 있는가

Drive / SharePoint
→ 어떤 자료를 참고해야 하는가

GitHub
→ 실제로 무엇이 변경됐는가

Worktree
→ 어디에서 안전하게 수정할 것인가

가 연결됩니다.

이 모든 정보를 Agent가 이해하고 실제 작업까지 할 수 있게 되면서 AI Coding Tool의 경쟁 기준도 달라지고 있습니다.

Claude Code는 여전히:

Codebase 이해

Subagent

Hooks

독립 Agent Workflow

정확한 Design-to-Code

에서 상당히 강력합니다.

반면 현재 Codex는:

Local / Worktree / Cloud

Plugins

Figma 양방향 Workflow

Atlassian

GitHub

회사 문서

Computer Use

ChatGPT Work

까지 범위를 빠르게 넓히고 있습니다.

그래서 개발만 놓고 둘 중 하나를 고르는 문제라면 여전히 취향과 프로젝트에 따라 달라질 수 있지만, 개발부터 디자인·업무·문서·발표까지 하나의 AI Workspace로 묶는 관점에서는 현재 Codex 쪽이 조금 더 앞서 있다고 볼 만합니다.

Claude가 부족하다기보다 차이가 있습니다.

Claude는 여전히 강력한 Coding Agent를 여러 Tool과 조합하는 느낌이 강하고,

Codex는 점점 개발자의 전체 Workspace 자체를 AI가 운영하는 방향으로 가고 있습니다.

앞으로의 경쟁은 모델 하나의 코딩 점수보다:

어느 Agent가 회사의 실제 개발 Workflow 전체를 더 적은 Context Switching으로 연결해주는가

에서 더 크게 벌어질 가능성이 있습니다.

참고자료

OpenAI — ChatGPT 및 Codex의 Plugins
Codex와 ChatGPT에서 Plugin이 어떻게 구성되는지, Skill·Connected App·App Template이 어떤 역할을 하는지 확인할 수 있습니다. 지원되는 Codex Task View에서는 Sources → Use plugins를 통해 설치된 Plugin을 직접 사용할 수 있다는 점도 공식 문서에 명시되어 있습니다.
OpenAI Plugin 공식 문서
OpenAI — Atlassian Rovo Plugin
Jira, Confluence, Compass의 정보를 ChatGPT/OpenAI 환경에서 검색하고, Jira Task 생성이나 Confluence 기반 Incident 정리처럼 실제 Action까지 연결하는 공식 Plugin입니다. Jira를 업무의 시작점으로, Confluence를 설계·결정 Context로 사용하는 개발 Workflow를 확인하기 좋습니다.
Atlassian Rovo Plugin
Atlassian — Rovo MCP Server
Jira와 Confluence뿐 아니라 Jira Service Management, Bitbucket, Loom 등 Atlassian 제품을 MCP Client와 연결하는 공식 MCP Server입니다. 검색·요약뿐 아니라 Work Item이나 Confluence Page 생성·수정 같은 Action도 지원하며 OAuth 2.1과 기존 Atlassian 권한을 그대로 사용합니다.
Atlassian Rovo MCP 공식 문서
Atlassian — Rovo MCP v2
2026년 9월 GA된 Rovo MCP v2의 최신 변경사항을 확인할 수 있습니다. Jira·Confluence Tool이 개선됐고 Bitbucket, Loom, Sprint, Attachment, Whiteboard 등 지원 범위가 확대됐습니다. Atlassian 연동을 새로 구성한다면 v2 기준으로 확인하는 것이 좋습니다.
Rovo MCP 최신 변경사항
OpenAI — Figma Plugin
Figma와 FigJam을 이용해 Wireframe, Flow Diagram, Gantt Chart, Storyboard, Presentation 등을 생성하는 공식 Plugin입니다. 코드 구현뿐 아니라 PRD나 문서를 디자인 결과물과 연결하는 Workflow를 확인할 수 있습니다.
OpenAI Figma Plugin
OpenAI & Figma — Codex × Figma Integration
Codex와 Figma의 공식 양방향 연동 발표입니다. Figma MCP Server를 이용해 Figma 디자인을 Codex에서 구현하는 Design → Code뿐 아니라 현재 코드에서 Figma Design이나 FigJam 쪽으로 이동하는 Code → Design Workflow도 지원하는 것이 핵심입니다.
Codex × Figma 공식 발표
Claude — Figma Plugin
Claude Code에서 Figma Frame의 Layout·Typography·Color·Design Token을 읽고 실제 코드로 구현하는 공식 Plugin입니다. /implement-design, /create-design-system-rules, /code-connect-components 같은 Skill을 제공해 기존 Design System에 맞춘 구현에 특히 유용합니다.
Claude Code Figma Plugin
Claude — Atlassian Plugin
Claude Code와 Cowork에서 Jira와 Confluence를 연결하는 공식 Atlassian Plugin입니다. Jira Issue 검색·생성, Confluence 문서 조회·작성, Sprint 관리, Spec을 Backlog로 변환하는 작업 등을 지원합니다.
Claude Atlassian Plugin
Claude — Atlassian Rovo Connector
Claude, Claude Desktop, Claude Code 및 API에서 Jira와 Confluence를 읽고 쓰는 공식 Connector입니다. Jira Issue 생성, 프로젝트 상태 업데이트, Confluence Page 작성 등 실제 업무 Action을 지원합니다.
Claude Atlassian Rovo Connector
Claude — Connectors
Claude에서 GitHub, Slack, Google Drive, Linear 같은 외부 서비스를 연결하는 기본 구조를 설명합니다. Connector가 각 사용자의 원래 서비스 권한을 그대로 따르며, Claude·Desktop·Claude Code 등 여러 Surface에서 사용할 수 있다는 점을 확인할 수 있습니다.
Claude Connector 공식 안내
Claude — Remote Connector와 Desktop Extension 비교
GitHub·Slack·Notion 같은 Cloud SaaS는 Remote Connector, 로컬 파일·localhost DB·Desktop App처럼 컴퓨터 내부 접근이 필요한 기능은 Desktop Extension을 사용하는 기준을 설명합니다. Claude 개발환경을 구성할 때 Cloud Context와 Local Tool을 구분하는 데 유용합니다.
Claude Connector 선택 가이드
Atlassian — Claude Agent for Jira
Jira Work Item을 Claude Managed Agent에게 직접 할당하고, Claude가 코드를 작성한 뒤 Branch를 Push하고 GitHub Pull Request까지 만드는 Beta Workflow입니다. Jira가 단순 Issue Tracker를 넘어 AI Coding Agent의 업무 할당 지점으로 확장되는 사례입니다.
Claude Agent for Jira 공식 안내

참고해서 볼 포인트

이번 글에서 중요한 것은 Plugin 개수 자체가 아닙니다.

Jira
→ 무엇을 해야 하는가

Confluence
→ 왜 그렇게 해야 하는가

Figma
→ 어떻게 보여야 하는가

GitHub
→ 실제로 무엇이 바뀌었는가

Worktree
→ 어디에서 안전하게 수정할 것인가

Drive / SharePoint
→ 어떤 자료를 참고하고 공유할 것인가

이 Context들이 하나의 Agent Workflow로 연결된다는 점입니다.

현재 공식 자료를 기준으로 보면 Codex/OpenAI 쪽은 Atlassian Rovo, Figma, GitHub, Drive 등 업무·개발·디자인 도구를 하나의 Plugin 체계로 묶는 방향이 강하고, Claude 쪽은 Atlassian/Figma Plugin과 Connector, Subagent, Worktree, Desktop Extension을 조합해 개발 Workflow를 세밀하게 구성하는 방향이 강합니다.

Paseo로 여러 AI 코딩 에이전트를 한 팀처럼 쓰는 방법

ekyu — Thu, 24 Sep 2026 14:48:24 +0900

Paseo로 여러 AI 코딩 에이전트를 한 팀처럼 쓰는 방법

Claude는 설계하고, Codex는 구현하고, 다른 Agent는 리뷰하게 만들기

Codex를 쓰다가 Claude Code도 같이 쓰고 싶을 때가 있습니다.

단순히 두 터미널을 띄워 놓는 것은 어렵지 않습니다.

문제는 역할을 나누기 시작할 때입니다.

Claude
→ 설계

Codex
→ 구현

Claude
→ 코드 리뷰

Codex
→ 테스트

Gemini
→ 자료 조사

각 Agent에게 Context를 다시 전달하고, 어느 Agent가 무엇을 하고 있는지 확인하고, 결과를 다시 모아서 다음 Agent에게 넘겨줘야 합니다.

Agent가 두세 개를 넘어가면 사람이 AI 사이에서 메시지를 전달하는 역할을 하게 됩니다.

Paseo는 이 부분을 관리하기 위한 Multi-Agent Orchestration 도구입니다.

Paseo 자체가 새로운 AI 모델을 제공하는 것은 아닙니다.

이미 사용하고 있는:

Claude Code

Codex

OpenCode

Gemini CLI

GitHub Copilot

그 외 ACP Agent

를 하나의 Workspace에서 실행하고 관리합니다.

기존 CLI의 로그인 정보, 설정, Skill, MCP Server도 그대로 사용할 수 있습니다.

1. Paseo가 필요한 상황부터 보자

Agent를 하나만 쓴다면 Paseo가 꼭 필요한 것은 아닙니다.

예를 들어:

Codex

"이 프로젝트의 로그인 기능을 구현해줘."

정도로 충분하다면 Codex 자체가 더 간단합니다.

Paseo가 재미있어지는 것은 역할이 나뉘기 시작할 때입니다.

Main Agent
     │
     ├─ Architecture Agent
     │
     ├─ Implementation Agent
     │
     ├─ QA Agent
     │
     └─ Review Agent

그리고 이 Agent들이 꼭 같은 모델일 필요도 없습니다.

Architecture
→ Claude

Implementation
→ Codex

Research
→ Gemini

QA
→ Codex

처럼 Provider까지 나눌 수 있습니다.

Paseo 공식 Orchestration 기능도 서로 다른 Provider와 Model을 사용하는 Agent에게 작업을 위임하고, Agent끼리 메시지를 보내고, 진행상태를 확인하고, 결과를 다시 받아오는 구조를 지원합니다.

2. 먼저 이해해야 할 것 — Paseo는 AI 모델이 아니다

Paseo를 처음 보면 또 하나의 Coding Agent처럼 느껴질 수 있습니다.

하지만 구조는 이렇습니다.

             Paseo
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
  Claude     Codex     Gemini
   Code                 CLI

Paseo가 직접 코드를 생각해서 만드는 것이 아니라,

각 Coding Agent를 실행하고 연결하고 관리하는 Control Layer입니다.

공식 문서에서도 Paseo는 기존 Agent CLI를 subprocess로 실행하며, 자체 Coding Agent를 제공하지 않는다고 설명합니다.

그래서 먼저 사용할 Agent가 설치되어 있어야 합니다.

3. 가장 쉬운 설치 방법은 Desktop App이다

처음 사용한다면 CLI보다 Desktop App부터 시작하는 것이 편합니다.

Paseo 공식 문서에서도 Desktop App을 권장 방식으로 안내하고 있습니다.

Desktop App에는 Paseo daemon이 포함되어 있어서 별도의 서버를 먼저 구성할 필요가 없습니다.

설치는 공식 다운로드 페이지에서 하면 됩니다.

Paseo를 실행하면 기본 구조는:

Paseo Desktop
      ↓
Local Daemon
      ↓
Claude / Codex / 기타 Agent

가 됩니다.

즉 Agent들은 자신의 Mac에서 실행됩니다.

4. CLI로 설치하고 싶다면

터미널 중심으로 사용한다면 Paseo CLI도 사용할 수 있습니다.

npm install -g @getpaseo/cli

설치 후:

paseo

를 실행합니다.

Paseo daemon이 로컬에서 시작됩니다.

Desktop App을 사용한다면 이 작업을 직접 할 필요가 없습니다.

5. Claude Code와 Codex를 먼저 설치한다

중요합니다.

Paseo를 설치했다고 Claude나 Codex가 설치되는 것은 아닙니다.

각 CLI를 별도로 설치하고 인증해야 합니다.

구조는:

Mac

├─ Claude Code
├─ Codex
└─ Paseo

입니다.

Paseo는 설치되어 있는 Native Provider를 찾아서 사용할 수 있습니다.

현재 Native 지원 Provider에는 Claude Code, Codex, OpenCode, Pi 등이 있으며 Gemini CLI나 GitHub Copilot 등은 ACP Catalog를 통해 추가할 수 있습니다.

6. 먼저 각 Agent가 독립적으로 동작하는지 확인한다

Paseo부터 설정하기 전에 각각의 CLI가 정상적으로 동작하는지 확인하는 게 좋습니다.

예를 들어:

claude

그리고:

codex

를 직접 실행합니다.

둘 다 프로젝트를 읽고 정상적으로 대답한다면 Paseo 쪽으로 넘어갑니다.

문제가 생겼을 때:

Paseo 문제인가?

Claude 인증 문제인가?

Codex 설정 문제인가?

를 구분하기 쉬워집니다.

7. 프로젝트를 Paseo Workspace로 연다

Paseo의 중요한 개념 중 하나가 Workspace입니다.

쉽게 말하면:

Agent들이 함께 작업할 프로젝트 공간

입니다.

예를 들어:

MyApp/
├─ Sources
├─ Tests
├─ Package.swift
└─ MyApp.xcodeproj

가 있다면 이 프로젝트 폴더를 하나의 Workspace로 엽니다.

CLI에서는 이런 식으로 만들 수 있습니다.

paseo workspace create \
  --isolation local \
  --path ~/Projects/MyApp \
  --title MyApp

이제 이 Workspace 안에 여러 Agent를 띄울 수 있습니다.

8. 처음에는 Worktree 없이 시작해도 된다

Paseo에는 Git Worktree 기능도 있습니다.

각 Agent가 독립적으로 코드를 수정해야 한다면:

Main Project

├─ Agent A Worktree
├─ Agent B Worktree
└─ Agent C Worktree

처럼 분리할 수 있습니다.

Paseo가 별도의 Branch와 Directory를 만들어 Agent끼리 같은 파일을 동시에 수정하면서 충돌하는 것을 줄여줍니다.

하지만 처음부터 사용할 필요는 없습니다.

처음에는:

하나의 Workspace
+
여러 Agent

정도로 시작하는 것이 이해하기 쉽습니다.

병렬 구현이 필요해졌을 때 Worktree를 추가하면 됩니다.

9. Paseo에서 가장 먼저 해야 할 것은 Agent Profile 만들기다

Paseo에서 개인적으로 가장 중요한 기능 중 하나가 Agent Profile입니다.

매번:

Claude 선택

모델 선택

Thinking 설정

Permission 설정

을 반복하는 대신 역할별 설정을 저장합니다.

예를 들어:

Planning

Provider
Claude

Reasoning
High

When to use
Architecture 설계, 문제 원인 분석,
구현 전에 방향을 정할 때 사용

Implementation

Provider
Codex

Reasoning
High

When to use
확정된 설계에 따라 실제 코드 수정,
Build와 Test까지 수행

Review

Provider
Claude

Reasoning
Medium

When to use
Diff Review,
Bug 가능성,
불필요한 복잡성,
누락된 테스트 확인

Paseo의 Agent Profile에는 Provider, Model, Mode, Thinking Level과 Feature 설정을 저장할 수 있으며 When to use 메모를 Orchestrator가 읽고 작업에 맞는 Profile을 선택할 수 있습니다.

10. 여기서 말하는 ‘토큰 분배’는 조금 다르다

Paseo가:

Claude 30%

Codex 40%

Gemini 30%

처럼 하나의 Token Pool을 비율로 잘라주는 것은 아닙니다.

대신 비싼 모델을 꼭 필요한 작업에만 사용하도록 역할을 분리하는 방식입니다.

예를 들면:

Architecture
→ Claude / High

Implementation
→ Codex / High

간단한 탐색
→ 저렴한 모델 / Low

Review
→ Claude / Medium

Test
→ Codex / Medium

입니다.

즉:

모든 작업
→ 가장 비싼 모델

이 아니라:

업무 난이도
       ↓
적절한 Agent
       ↓
적절한 Model
       ↓
적절한 Thinking

으로 나누는 겁니다.

실제로 이게 여러 AI 서비스를 같이 사용하는 팀에서 더 현실적인 비용 관리 방식입니다.

11. 이제 Paseo Tools를 켠다

Profile까지 만들었다면 Agent가 다른 Agent를 직접 실행할 수 있게 만듭니다.

Paseo에서:

Settings
→ Host
→ Agents
→ Enable Paseo tools

를 활성화합니다.

기본값은 Off입니다.

활성화한 뒤 새 Agent를 시작하거나 기존 Agent를 Reload하면 Paseo Tool을 사용할 수 있습니다.

이제 Main Agent에게 이렇게 요청할 수 있습니다.

Paseo Profile을 확인해.

이 기능의 Architecture는 Planning Agent에게 분석시키고,

설계가 끝나면 Implementation Agent에게
구현을 맡겨.

마지막으로 Review Agent에게
독립적인 코드 리뷰를 요청해.

모든 결과를 마지막에 하나로 정리해줘.

여기서부터 진짜 Multi-Agent Workflow가 시작됩니다.

12. Agent끼리 실제로 역할을 나눌 수 있다

예를 들어 Main Agent에게:

회원가입 기능을 추가해야 한다.

먼저 Architecture Agent에게
현재 인증 구조와 변경 범위를 분석하게 해.

파일은 수정하지 않는다.

분석이 끝나면 결과를 가져와서 나에게 보여줘.

라고 합니다.

그러면:

Main Agent
      ↓
Planning Agent
      ↓
Repository 분석
      ↓
Architecture 제안
      ↓
Main Agent로 결과 전달

이 됩니다.

그 다음:

승인된 설계를 Implementation Profile을 사용하는
Codex Agent에게 넘겨.

구현하고 관련 Unit Test를 실행해.

로 이어갑니다.

Paseo는 Agent 생성뿐 아니라 Agent에게 추가 Prompt를 보내거나 상태를 조회하고, 완료 결과를 확인하는 Tool을 제공합니다.

13. 병렬 작업은 독립적인 문제에만 사용한다

Multi-Agent라고 무조건 많이 띄우는 것은 좋지 않습니다.

좋은 병렬화:

Agent A
→ 현재 Network 구조 조사

Agent B
→ Test 구조 조사

Agent C
→ 관련 Regression 조사

세 작업은 서로 파일을 수정하지 않습니다.

동시에 실행해도 안전합니다.

Paseo 공식 예제에서도 하나는 Request Path를 추적하고, 하나는 Test를 조사하고, 하나는 Regression을 확인한 뒤 결과를 종합하는 Fan-out Workflow를 예로 들고 있습니다.

반대로:

Agent A
→ LoginViewModel 수정

Agent B
→ LoginViewModel 수정

을 같은 Directory에서 동시에 돌리면 좋지 않습니다.

이럴 때 Worktree를 씁니다.

14. 코드 수정이 병렬이라면 Worktree를 사용한다

예를 들어:

Agent A
→ Network Layer Migration

Agent B
→ SwiftUI 화면 Migration

Agent C
→ Unit Test 추가

를 동시에 진행하고 싶다면 각각 독립 Worktree를 만드는 편이 안전합니다.

구조는:

origin/main
     │
     ├─ feature/network
     │      └─ Codex
     │
     ├─ feature/ui
     │      └─ Codex
     │
     └─ feature/tests
            └─ Claude

처럼 됩니다.

Paseo가 Workspace를 생성할 때 Worktree Isolation을 지정하면 독립 Branch와 Directory를 만들어줍니다.

Git에 익숙하지 않다면 처음부터 이 기능을 사용할 필요는 없습니다.

여러 Agent가 실제 코드를 동시에 수정해야 할 시점에 추가하면 됩니다.

15. Paseo Skill도 있다

Agent에게 매번:

다른 Agent 띄워.

라고 설명할 필요도 없습니다.

Paseo에는 Orchestration Skill이 있습니다.

대표적으로:

/paseo

/paseo-handoff

/paseo-committee

/paseo-advisor

가 있습니다.

/paseo-handoff

현재 작업을
다른 Agent에게 넘기기

/paseo-committee

어려운 문제를
두 Agent에게 독립적으로 분석시키기

/paseo-advisor

현재 구현에 대한
Second Opinion 받기

정도로 이해하면 쉽습니다.

Paseo Settings의 Orchestration Skills에서 설치하거나 CLI에서 설치할 수도 있습니다.

여기까지가 Paseo의 기본 세팅이다

정리하면:

1. Claude / Codex 설치

2. Paseo 설치

3. Project Workspace 생성

4. Agent Profile 생성

5. Paseo Tools 활성화

6. Main Agent 실행

7. 역할별 Subagent 위임

이 정도만 해도 상당히 쓸 만합니다.

이제 실제 개발 Workflow를 만들어보겠습니다.

16. 일반적인 개발팀이라면 이렇게 구성해볼 수 있다

개인적으로 처음 구성한다면 Agent를 너무 많이 만들지 않고 세 개 정도로 시작하는 것이 좋습니다.

                 Main
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
     Planning   Coding    Review
      Claude    Codex      Claude

Planning Agent

역할:

Architecture 분석

영향 범위 조사

작업 계획

대안 비교

파일 수정은 하지 않습니다.

Coding Agent

역할:

실제 구현

Refactoring

Build

Unit Test

Review Agent

역할:

Diff Review

Bug 가능성

Regression

Test 누락

Architecture 위반

중요한 점은 Review Agent가 Implementation Agent와 다른 Context에서 독립적으로 보는 것입니다.

17. Main Agent는 코딩보다 지휘를 담당하게 한다

Main Agent까지 직접 코딩하면 Context가 빠르게 커집니다.

그래서 Main Agent는 가능하면:

요구사항 이해

Agent 선택

Task 분리

결과 수집

충돌 판단

최종 요약

역할에 집중하게 할 수 있습니다.

구조가 이런 형태가 됩니다.

                 Main Agent
                     │
              Task Breakdown
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
 Architecture    Implementation   Test
       │             │             │
       └─────────────┼─────────────┘
                     ↓
                   Review
                     ↓
                Main Agent
                     ↓
                 최종 결과

이렇게 하면 하나의 Agent Context가 모든 로그와 코드를 다 먹는 것도 어느 정도 줄일 수 있습니다.

18. iOS 개발에서는 Paseo가 특히 재미있다

iOS 개발 환경에 적용하면 역할을 더 분명하게 나눌 수 있습니다.

예를 들어:

                  Paseo
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    Claude        Codex       Codex
 Architecture   Implementation   QA
       │            │            │
       │            │      XcodeBuildMCP
       │            │            │
       └────────────┼────────────┘
                    ↓
                 Claude
                  Review

여기서 역할은 이렇게 나눌 수 있습니다.

19. Claude = Architecture와 Review

Claude Agent에는:

현재 Feature 구조를 분석해.

변경이 필요한 Module과 Dependency를 정리해.

바로 코드를 수정하지 말고
구현 계획과 위험요소만 작성해.

를 맡깁니다.

구현이 끝난 뒤에는 별도의 Claude Review Agent를 띄웁니다.

현재 Diff를 독립적으로 Review해.

확인할 것:

- Architecture 위반
- Swift Concurrency 문제
- MainActor 사용
- Retain Cycle
- Error Handling
- 불필요한 복잡성
- Test 누락

파일은 수정하지 말고
문제와 수정 우선순위만 알려줘.

처럼 사용할 수 있습니다.

20. Codex = 실제 구현

Architecture가 확정되면 Codex로 넘깁니다.

Planning Agent의 설계를 기준으로 구현해.

요청한 범위를 벗어난 Refactoring은 하지 마.

기존 Architecture를 유지하고,

완료 후 Build와 관련 Unit Test를 실행해.

변경 파일과 Test 결과를 요약해.

구조는:

Claude
Architecture
    ↓
   Plan
    ↓
Codex
Implementation

입니다.

설계와 구현 Context를 일부러 나눈다는 것이 핵심입니다.

21. Codex + XcodeBuildMCP = Simulator / QA

여기서 iOS에서는 한 단계 더 갈 수 있습니다.

Codex Agent에 XcodeBuildMCP를 연결합니다.

XcodeBuildMCP는 Xcode Project Discovery, Build/Test, Simulator Boot, 앱 설치·실행, Log Capture, Screenshot, UI hierarchy와 UI Automation 같은 기능을 Agent에게 제공합니다. 최근 구현에서는 tap, swipe, type_text 같은 Simulator Interaction도 지원합니다.

그러면 QA Agent 역할을 따로 만들 수 있습니다.

QA Agent
  │
  └─ Codex
       │
       └─ XcodeBuildMCP
              │
              ├─ Build
              ├─ Simulator
              ├─ Launch
              ├─ UI Tree
              ├─ Tap
              ├─ Type
              ├─ Swipe
              ├─ Screenshot
              └─ Logs

이게 iOS 프로젝트에서는 상당히 재미있는 조합입니다.

22. QA Agent Profile을 별도로 만든다

Paseo에 다음 Profile을 추가합니다.

iOS QA

Provider
Codex

Thinking
Medium

When to use

iOS Simulator 실행,
Build/Test,
UI Interaction,
Screenshot,
Regression 확인이 필요한 작업.
XcodeBuildMCP를 우선 활용한다.

이제 Main Agent는:

구현이 끝났으면
iOS QA Profile을 사용해서
Simulator 검증을 실행해.

라고 위임할 수 있습니다.

23. 실제 iOS Workflow는 이렇게 된다

예를 들어 상품 상세 화면을 수정한다고 해보겠습니다.

1단계

Claude:

현재 ProductDetail 구조를 분석하고
변경 계획만 작성.

2단계

Codex:

승인된 Plan을 구현하고
Unit Test 실행.

3단계

QA Codex:

Simulator에서 앱을 실행.

상품 목록 진입.

첫 번째 상품 선택.

상세 화면 확인.

스크롤.

구매 버튼 확인.

Screenshot 저장.

Console Warning과 Crash 확인.

4단계

Claude:

Diff와 QA 결과를 같이 보고
최종 Review.

전체로 보면:

Requirement
    ↓
Claude
Architecture
    ↓
Codex
Implementation
    ↓
Codex + XcodeBuildMCP
Simulator QA
    ↓
Claude
Review
    ↓
Developer

입니다.

24. iPhone Duo QA에도 그대로 확장할 수 있다

최근 이야기했던 iPhone Duo처럼 화면 상태가 많아지는 환경에서는 더 유용합니다.

Closed

Open

Folded

Rotated

상태에서:

Layout

Navigation

Safe Area

ReservedRegion

Scroll

Button Interaction

을 반복해서 확인해야 하기 때문입니다.

Paseo 구조에서는:

Claude
→ Duo Migration 설계

Codex
→ UI Migration 구현

Codex + XcodeBuildMCP
→ Simulator QA

Claude
→ Diff + QA 결과 Review

처럼 역할을 분리할 수 있습니다.

즉 Paseo가 Simulator를 직접 제어하는 것이 아닙니다.

Paseo가 QA 담당 Codex를 관리하고, Codex가 XcodeBuildMCP를 이용해서 Simulator를 제어하는 구조입니다.

이 구분은 중요합니다.

25. QA 결과는 Agent에게 반드시 구조화해서 받는 게 좋다

QA Agent가:

테스트했습니다. 이상 없습니다.

라고 끝내면 의미가 없습니다.

처음부터 Output 형식을 지정합니다.

Scenario

Home → Product → Detail

Simulator

iPhone Duo / iOS 27.1

Result

PASS / FAIL

Checks

Layout
Navigation
Interaction
Warnings
Crash

Evidence

Screenshot Path

Finding

발견된 문제

Recommendation

수정 제안

이렇게 받으면 Main Agent가 결과를 다시 Review Agent에게 전달하기도 쉬워집니다.

26. Agent를 너무 많이 만들면 오히려 손해다

Multi-Agent 이야기를 하면:

Planning Agent

Research Agent

UI Agent

Network Agent

DB Agent

Test Agent

QA Agent

Review Agent

Security Agent

처럼 만들고 싶어집니다.

하지만 이렇게 시작하면 Agent 관리가 새로운 일이 됩니다.

처음에는:

Planning

Implementation

Review

세 개 정도면 충분합니다.

iOS라면:

Planning

Implementation

Simulator QA

Review

정도가 현실적입니다.

독립적인 Reasoning이 필요한 경우에만 Agent를 나누는 편이 좋습니다.

27. Agent보다 Skill이 더 적합한 작업도 있다

반복되는 절차라고 모두 Agent를 만들 필요는 없습니다.

예를 들어:

Release Checklist

Swift 6 Migration Rule

PR 작성 규칙

Lint 실행

Build 명령

같은 작업은 독립적인 Agent보다 Skill이나 Project Instruction이 더 적합할 수 있습니다.

반면:

Architecture 분석

독립 Code Review

Root Cause 조사

Simulator QA

처럼 별도의 Context에서 판단해야 하는 작업은 Agent로 분리할 가치가 있습니다.

기준은:

정해진 절차
→ Skill

독립적인 판단
→ Agent

정도로 시작하면 이해하기 쉽습니다.

28. 보안과 Permission도 Profile별로 나누는 게 좋다

모든 Agent에게 동일한 권한을 줄 필요도 없습니다.

예를 들어 Review Agent는:

Read
→ 허용

Code Write
→ 제한

할 수 있습니다.

Implementation Agent는:

Workspace Write
→ 허용

QA Agent는:

Build
Simulator
Test

정도만 필요할 수 있습니다.

Paseo는 Provider의 Native Sandbox나 Permission Option을 전달할 수 있지만, 공식 문서에서도 이 설정 자체가 Host Security Boundary를 대신하는 것은 아니라고 설명합니다. 민감한 작업이나 신뢰하지 않는 코드라면 Container나 별도 Machine을 사용하는 편이 안전합니다.

29. Paseo를 쓰면 Agent를 휴대폰에서도 확인할 수 있다

Paseo는 Desktop뿐 아니라 Mobile, Web, CLI Client를 제공합니다.

Desktop Agent가 긴 작업을 하고 있다면 휴대폰에서:

Agent 상태 확인

결과 확인

추가 Prompt

작업 중단

같은 작업을 할 수 있습니다.

Paseo는 Local Machine에서 Agent를 실행하고 Client가 daemon에 연결하는 구조이며 Mobile Device도 Pairing할 수 있습니다.

긴 Build나 Test를 많이 하는 개발자에게는 의외로 편한 부분입니다.

30. 처음 Paseo를 도입한다면 이 구성부터 추천한다

처음부터 복잡하게 만들 필요는 없습니다.

Profile 1 — Architect

Claude

High Reasoning

Architecture / Planning

Profile 2 — Developer

Codex

High Reasoning

Implementation

Profile 3 — Reviewer

Claude

Medium Reasoning

Independent Review

iOS라면 하나 더 추가합니다.

Profile 4 — iOS QA

Codex

Medium Reasoning

XcodeBuildMCP
Simulator
Test
Screenshot
Logs

그리고 Main Agent에게 이렇게 말합니다.

Paseo Agent Profile을 확인해.

먼저 Architect에게 이 작업을 분석시켜.

설계가 끝나면 Developer에게 구현을 맡겨.

구현 후 iOS QA Agent가
Build와 Simulator 검증을 수행하게 해.

마지막으로 Reviewer가
Diff와 QA 결과를 독립적으로 검토하게 해.

각 단계 결과를 마지막에 하나로 정리해.

이 정도면 Paseo를 쓰는 이유가 꽤 명확하게 느껴집니다.

31. 가장 중요한 건 Agent 숫자가 아니다

Paseo를 사용한다고 Agent를 많이 띄우는 것이 목적은 아닙니다.

중요한 것은:

누가 계획하는가

누가 구현하는가

누가 검증하는가

누가 최종적으로 책임지는가

를 분리할 수 있다는 점입니다.

특히 모델마다 장점이 조금씩 다르다면:

Claude의 장점
→ Architecture / Review

Codex의 장점
→ Implementation / Tool Execution

XcodeBuildMCP
→ Build / Simulator / QA

처럼 역할을 배치할 수 있습니다.

결국 Paseo의 가치는 새로운 AI 모델을 하나 더 쓰는 데 있는 것이 아니라,

이미 사용하는 여러 Coding Agent를 하나의 개발팀처럼 구성할 수 있다는 데 있습니다.

마치며

지금까지 Coding Agent를 사용하는 방식은 대부분:

Developer
    ↓
Agent

였습니다.

하지만 Agent가 여러 개가 되기 시작하면 구조가 달라집니다.

                    Developer
                        ↓
                      Paseo
                        ↓
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
       Claude         Codex         Codex
     Architecture  Implementation     QA
          │             │             │
          └─────────────┼─────────────┘
                        ↓
                     Claude
                      Review

특히 iOS 개발이라면:

Claude = 설계와 Review

Codex = 실제 구현

Codex + XcodeBuildMCP = Simulator와 QA

정도로 역할을 나누는 구성이 상당히 실용적입니다.

그리고 모든 작업에 가장 큰 모델을 사용하는 대신:

어려운 설계
→ 비싼 Reasoning

구현
→ Coding Agent

반복 QA
→ 적절한 Agent + Tool

간단한 조사
→ 저렴한 Model

처럼 분산하면 Agent를 여러 개 쓰는 이유가 훨씬 분명해집니다.

Multi-Agent의 핵심은 Agent를 많이 만드는 것이 아닙니다.

각 Agent에게 독립적으로 판단할 가치가 있는 일을 나누고, 그 결과를 다시 하나의 Workflow로 연결하는 것.

Paseo는 바로 그 연결부에 있는 도구입니다.

참고자료

Paseo — Getting Started
Desktop App, CLI, daemon, Mobile Pairing과 기본 설치 방법을 설명합니다.
Paseo 시작하기
Paseo — Providers
Claude Code, Codex 등 기존 Agent CLI를 Paseo가 어떻게 실행하고 관리하는지 설명합니다.
Paseo Providers
Paseo — Supported Providers
Claude Code, Codex 등의 Native Provider와 Gemini CLI, GitHub Copilot 등 ACP Catalog를 확인할 수 있습니다.
지원 Agent 목록
Paseo — Agent Profiles
Provider, Model, Mode, Thinking Level과 역할 설명을 Profile로 저장하는 방법입니다.
Agent Profiles
Paseo — Orchestration
한 Agent가 다른 Agent를 생성하고 작업을 위임하고 결과를 모으는 핵심 기능입니다.
Paseo Orchestration
Paseo — Common Orchestration Workflows
구현 위임, 독립 Review, Parallel Research 같은 실전 예제가 있습니다.
Orchestration Workflow
Paseo — Git Worktrees
여러 Agent가 병렬로 코드를 수정할 때 독립적인 Workspace를 구성하는 방법입니다.
Paseo Worktrees
Paseo — Orchestration Skills
Handoff, Committee, Advisor 등 반복 가능한 Multi-Agent Workflow를 제공합니다.
Paseo Skills
XcodeBuildMCP
Build, Test, Simulator, UI Automation, Screenshot, Log 등 iOS 개발을 AI Agent와 연결하기 위한 MCP Server입니다.
XcodeBuildMCP

공식 자료 기준으로 보면 Paseo의 핵심은 자체 모델이 아니라 Provider·Workspace·Agent Profile·Orchestration을 이용해 여러 Coding Agent를 하나의 작업 흐름으로 묶는 것입니다. 처음에는 Claude/Codex 두 Provider와 Planning·Implementation·Review 정도의 Profile만 만들어도 충분하고, iOS 프로젝트라면 그다음 단계로 XcodeBuildMCP 기반 Simulator QA Agent를 붙이는 방식이 가장 이해하기 쉽습니다.