테오 블로그 RSS Feed

흔들림은 결함이 아니다

Mon, 04 May 2026 09:00:00 GMT

빠른 팀에서 헤맨다는 감각

빠른 팀의 회의실은 이상한 광학을 가진다. 모두가 같은 방향을 보고 있는 듯하고, 한 사람의 말이 떨어지면 두세 사람의 손이 동시에 움직이고, 결정은 어느 사이엔가 내려져 있다. 그 사이에 한 명만 잠깐 길을 잃는다. 무엇이 결정되었는지, 그 결정이 무엇에 근거했는지, 자신이 어디에 동의했는지 또렷하지 않다.

이 감각은 능력의 문제처럼 다가오지만, 실제로는 광학의 문제다. 빠른 팀은 자기들끼리 이미 합의된 표지판을 들고 다니고, 그 표지판은 회의 자료에 적혀 있지 않다. 새로 들어온 사람은 안 보이는 표지판들 사이를 한동안 걸어야 한다. 그래서 헤맴은 결함이 아니라 위치다.

다만 위치는 영원하지 않다. 위치는 어떤 동작을 반복하느냐에 따라 굳어지기도 하고 풀리기도 한다. 흔들리는 위치를 어떻게 다루느냐가 그 위치를 머무는 자리로 만들지, 빠져나오는 길로 만들지 가른다. 흔들림 자체는 결함이 아니지만, 흔들림을 다루는 방식은 종종 결함이 된다.

흔들림은 사적이고, 자리는 공적이다

흔들림과 흔들림의 외부화는 같은 일이 아니다. 책상 앞에서 자기 글을 의심하는 일과, 그 의심을 자신이 청한 회의 자리 한가운데에 풀어놓는 일은 전혀 다른 동작이다. 앞의 것은 사유의 동작이고, 뒤의 것은 자리의 신뢰를 깎는 동작이다.

회의를 청한 사람은 그 자리의 첫 번째 검증자이지, 첫 번째 부정자가 아니다. 자기가 청한 자리에서 자기 손으로 자리를 흔드는 일은 종종 솔직함으로 오해되지만, 자리에 앉아 있던 사람들에게는 다른 신호로 닿는다. 다음에 같은 사람이 청한 자리에 앉을 때, 그들은 한쪽 눈으로 자리의 의제를 보고 다른 쪽 눈으로 자리를 청한 사람의 손을 본다. 한 번 흔든 손은 다음 자리를 위해서도 한 번 더 흔들 가능성을 가진 손이 된다.

회의 자리에서의 사과, 좌절의 토로, 확신 없음의 표명은 그 자리의 공기를 사적인 감정의 무게로 끌어내린다. 사적인 흔들림은 1:1 자리, 동료의 책상, 멘토의 시간에 풀어놓는다. 회의 자리는 그 흔들림을 받아주는 자리가 아니다. 회의 자리는 공적인 결정의 자리다. 두 자리를 섞으면 두 자리 모두 흐려진다.

자기를 설득하지 못했다면 자리를 열지 마라

자기 설득이 끝나지 않은 채 회의를 여는 일은 그 자리에서 엎을 일을 미리 약속하는 일이다. 청한 사람이 흔들리면 의제가 흔들리고, 의제가 흔들리면 자리에 앉은 사람들이 흔들린다. 청한 사람이 자기 의제를 한 번 더 의심한 다음에 자리를 여는 일이, 자리를 연 다음에 의심을 꺼내는 일보다 거의 언제나 작은 비용이다.

미루는 일은 회피와 다르다. 자기가 아직 설득되지 않았다는 사실을 미리 알고 자리를 한 번 미루는 동작은 책임의 동작이다. 그 자리를 그대로 열고서 자리 안에서 미안하다고 말하는 동작은 책임을 자리에 앉은 사람들에게 나눠 갖게 만드는 동작이다. 한쪽은 시간이 늦춰지고, 한쪽은 신뢰가 깎인다. 시간은 회복되지만 신뢰는 잘 회복되지 않는다.

자기 설득이 어렵다고 느낄 때 가장 빠른 길은 자리를 옮기는 일이다. 회의 자리에서 의제 옆에 앉아 의심하지 말고, 책상 앞으로 돌아가 의제를 다시 다듬거나, 옆자리 동료의 손을 빌리거나, 멘토의 시간을 받는다. 거기에서 끝낸 다음에 회의 자리를 다시 연다. 자리는 청한 사람이 흔들리지 않을 때 비로소 자리가 된다.

정답을 끌어내려는 대화는 사고를 깎는다

도구와의 대화는 묘한 함정을 가진다. 도구에게 물으면 답이 돌아오고, 답이 그럴듯하면 머릿속의 빈칸이 채워진 것처럼 보인다. 그러나 그 빈칸은 채워진 게 아니라 가려졌다. 직접 빈칸을 메우는 동작을 한 번 빼먹을 때마다, 다음 빈칸을 메울 근육이 한 번씩 약해진다.

도구에서 끌어낸 답은 자기 안에서 나온 답과 모양이 다르다. 도구의 답은 매끄럽지만 자기 것이 아니라서, 다음 자리에서 그 답을 옮길 때 흔들린다. 자기 안에서 나온 답은 거칠지만 자기 것이라서, 흔들려도 어느 지점부터 다시 잡아야 하는지 안다. 매끄러운 답이 자기 안에서 좀처럼 나오지 않는 이유는, 자기 사고의 거친 버전을 한 번 거치지 않고 도구의 매끄러운 버전을 그대로 옮기기 때문이다.

도구에 묻기 전에 자기에게 먼저 묻는 일, 자기가 먼저 답을 적어보고 나서 도구에게 검증을 부탁하는 일, 그 순서를 지키는 사람의 사고 근육이 자라난다. 순서가 뒤집힌 사람의 근육은 매번 도구의 답을 옮기다가 멈춘다.

매몰된 시간을 버리지 못하면 다음 시간이 깎인다

한 달 동안 쌓은 결론이 잘못되었다는 신호가 올 때, 그 한 달이 가장 무거운 짐이 된다. 한 달을 버리지 못하는 마음이 그 한 달을 지키려고 다음 한 달을 추가로 쓴다. 그러는 동안 처음의 한 달이 두 달이 되고, 두 달이 세 달이 된다. 결국 신호가 왔을 때 한 달을 버렸다면 두 달로 줄었을 길이가 세 달이 되어 있다.

매몰된 시간은 가만히 있어도 자라난다. 어제 쌓은 결론을 오늘 버리는 일은 한 칸짜리 후퇴지만, 한 달 쌓은 결론을 오늘 버리는 일은 한 달짜리 후퇴처럼 느껴진다. 그 느낌이 결정을 늦추고, 늦춘 시간이 다시 매몰된 시간을 키운다. 가장 비싸지는 결정은 거의 언제나 가장 늦게 내려진 결정이다.

처음부터 다시 시작하는 동작은 진 사람이 하는 동작처럼 보이지만, 늦지 않게 다시 시작한 사람이 결국 가장 빨리 도착한다. 매몰된 시간은 끊을수록 작아지고, 안고 갈수록 커진다.

태도는 본인이 결정한다

지식과 기술은 환경이 채워줄 수 있다. 옆자리 동료가 가르쳐주고, 시스템이 받쳐주고, 시간이 쌓아준다. 그러나 태도는 환경이 채워주지 않는다. 태도는 본인이 결정하는 동작이고, 결정하지 않으면 시간이 대신 결정한다. 시간이 결정한 태도는 거의 언제나 가장 작은 저항을 따라간다.

회의 자리에서 한숨을 한 번 쉬면 그 한숨이 다음 자리에 그대로 따라온다. 자기 설득이 끝나지 않은 자리를 한 번 열면 다음 자리도 같은 방식으로 열린다. 가장 빠른 길로 한 번 도구에 답을 묻기 시작하면, 그다음부터는 자기에게 먼저 묻는 동작 자체가 어색해진다. 태도는 한 번의 결정으로 굳어지지 않지만, 한 번의 결정이 다음 결정의 자리를 좁힌다.

흔들림은 결함이 아니다. 그 흔들림을 어떻게 다루느냐가 결정이다. 결정은 본인의 자리에 있다.

채용되는 것은 손이 아니라 판단이다

Fri, 01 May 2026 21:30:00 GMT

같은 단어, 다른 사람

채용 공고 앞에 앉으면 같은 단어를 본다. 개발자. 그 단어가 가리키는 사람의 모습은 시기마다 달랐다. 한 시기에는 자판을 빨리 치는 사람이었고, 한 시기에는 알고리즘을 깊게 아는 사람이었으며, 또 한 시기에는 새벽까지 모니터를 응시하는 사람이었다. 단어는 그대로인데 그 안에 들어 있는 사람의 모습이 매번 바뀌었다.

요즘 그 단어가 또 한 번 비어 가는 중이다. 자판은 더 이상 빠를 필요가 없고, 외워 둔 라이브러리는 어제의 가치만큼만 가치 있고, 새벽까지 모니터를 응시하는 일도 점점 줄어든다. 단어 안의 사람이 비워지는 자리에, 다른 종류의 사람이 들어오고 있다. 누군지 아직은 잘 보이지 않는다.

손이 가벼워지는 시간

손이 가벼워진다는 말을 자주 듣는다. 코드를 짜는 일이 가벼워지고, 화면을 만드는 일이 가벼워지고, 데이터를 옮기는 일이 가벼워진다. 키보드 위의 손은 점점 같은 일을 점점 적게 한다. 한 사람의 손으로 1년 걸리던 일이 두세 달로 줄어들고, 두세 달 걸리던 일이 며칠로 줄어드는 풍경이 도처에 펼쳐진다.

이 가벼워짐을 처음 본 사람들의 반응은 비슷하다. 두려움과 안도가 동시에 도착한다. 두려운 것은 자기 손의 가치가 사라진다는 감각이고, 안도하는 것은 더 이상 손으로 그 모든 것을 끌고 가지 않아도 된다는 사실이다. 두려움과 안도는 같은 사건의 두 얼굴이다.

가벼워진 손은 어디로 가는가. 사라지지 않는다. 손이 하던 일을 하지 않게 될 뿐이다. 그 손은 다른 자리에 놓여야 한다. 어디에 놓일 것인가, 그 질문에 회사도 사람도 아직 답을 갖고 있지 않다.

지금은 저수준의 일에서 손이 가벼워졌다. 화면 한 장을 그리는 일, 한 모듈을 만드는 일, 데이터를 옮기는 일. 머지않아 더 위쪽의 일에서도 손이 가벼워질 것이다. 시스템 전체의 그림을 그리는 일, 위험을 미리 보는 일, 트레이드오프를 정리하는 일. 시간 차이일 뿐 방향은 같다. 가벼워짐은 위로 올라간다.

무엇을 만들지 모르는 자리

회사 안에 가장 자주 흐르는 침묵은 어떻게 만들지 앞이 아니라 무엇을 만들지 앞에서 흐른다. 어떻게 만들지는 누군가 답을 안다. 자료가 있고, 사례가 있고, 검색이 있고, 이제는 AI가 있다. 그러나 무엇을 만들지에 관해서는 자료도 사례도 답을 주지 못한다. 그 자리는 누군가가 자기 판단으로 채워야 하는 자리다.

대부분의 조직은 이 자리에서 멈춰 있다. 만들 손은 충분한데 만들지가 정해지지 않는다. 어떤 고객을 위해 어떤 문제를 풀 것인가. 이 기능과 저 기능 중 무엇이 다음 1년을 결정하는가. 풀고 나면 무엇이 좋아진다고 말할 수 있는가. 이 질문 앞에서 자주 사람이 부족해진다. 손이 부족한 게 아니라, 답을 함께 만들어 줄 머리가 부족하다.

회사가 채용 공고를 올릴 때 적는 단어는 여전히 개발자다. 그러나 그 자리에서 회사가 진짜로 사고 있는 것은 손이 아니다. 함께 결정해 줄 사람이다. 이 차이는 공고문의 문장만으로는 잘 드러나지 않지만, 면접에 들어가면 금방 드러난다. 면접관이 던지는 질문이 점점 어떻게 짤 것인가에서 무엇을 풀 것인가로 옮겨가고 있다.

손과 머리의 자리 바꾸기

이 변화가 처음은 아니다. 한 세기 전에도 비슷한 일이 있었다. 그때도 손이 가벼워졌다. 베틀이 멈추고, 방적기가 돌아가고, 망치가 기계로 바뀌었다. 사람은 무엇을 만들 것인가, 어떤 순서로 만들 것인가, 어떤 품질을 어디까지 허용할 것인가를 정하는 자리에 남았다. 자리가 비워지는 것이 아니라 옮겨졌다. 한 세대의 직업이 사라지고, 다른 세대의 직업이 만들어졌다. 단어는 그대로인데 안의 사람이 바뀌었다.

같은 모양의 사건이 지금 사무실에서 일어난다. 손이 빠른 사람을 비싸게 사던 시대가 닫히고 있다. 그 자리에 비싸게 팔리는 것은 다른 종류의 사람이다. 무엇을 만들지를 정의하는 사람, 만들지 않을 것을 결정하는 사람, 만든 것을 어떤 기준으로 좋다고 부를지를 합의해 가는 사람.

악보를 읽을 줄 아는 사람이 많아진다고 해서 지휘자가 사라지지는 않는다. 오히려 누구나 연주할 수 있는 시대일수록, 무슨 곡을 어떤 박자로 함께 연주할지 정하는 사람의 자리가 무거워진다. 채용 공고에 적힌 개발자라는 단어는 그대로지만, 그 단어가 가리키는 사람의 일은 바뀌었다. 가리키는 자리가 손에서 머리 쪽으로 천천히 이동하고 있다.

이 자리는 직급으로 표현하면 흔히 팀장급이라 불린다. 그러나 팀장급은 직급의 이름이 아니라 사고의 위치다. 자기 코드만 책임지는 자리에서, 무엇을 만들 것인가에 답을 내야 하는 자리로 옮겨간 사람. 그 자리에 어울리는 사람이 점점 귀해지고 있다.

다음에 뽑힐 사람

손이 빨라서 살아남던 시대는 점점 끝나간다. 손이 빠른 사람을 회사가 더 이상 비싸게 사지 않는다. 그 자리에 비싸게 팔리는 사람은 무엇을 만들지 정의해 줄 사람, 만드는 일과 만들지 않는 일 사이에서 함께 골라 줄 사람이다.

채용 공고 앞에 다시 앉는다. 같은 단어가 눈에 들어온다. 개발자. 그 단어 안에 어떤 사람이 들어 있는지 다시 한번 들여다보면 좋다. 그 자리에서 회사가 진짜로 찾고 있는 것이 손인지, 판단인지.

프로토타입이라는 새 문법

Fri, 01 May 2026 09:00:00 GMT

회의실의 가구는 그 시대의 인식이다

회의실은 가구가 단순해 보이는 공간이다. 책상이 있고 의자가 있고 벽에 화면이 걸려 있다. 그런데 그 책상 위에 무엇이 놓이는가는 단순하지 않다. 거기 놓인 한 가지가 그 조직이 무엇을 진실로 여기는지를 드러낸다. 슬라이드의 시대가 있었고, 메모의 시대가 있었다. 이제 프로토타입이 그 자리에 올라간다.

도구가 바뀐다는 말은 도구가 바뀐다는 뜻이 아니다. 회의의 주체가 한 칸씩 이동한다는 뜻이다. 발표자에서 독자로, 독자에서 사용자로. 가구는 매번 새 주인공을 위해 새로 들어온다.

슬라이드는 발표자의 시선이었다

PowerPoint는 말하는 사람을 보호하는 도구다. 빈 곳은 말로 메우면 되고, 정렬된 표는 그것만으로 동의처럼 보인다. 전환 효과는 흐름의 빈틈을 가린다. 청중은 화면을 따라가고, 따라가는 동안에는 의문을 잠시 미룬다. 슬라이드 회의가 끝나면 모두가 같은 결론에 동의한 것 같지만, 막상 다음 주에 만나보면 각자 다른 결론을 들고 있는 일이 흔하다.

슬라이드의 진짜 비용은 제작 시간이 아니라 검증의 유예에 있다. 발표자가 말하는 동안 청중은 듣는 척을 할 수 있고, 듣는 척이 끝나면 회의도 끝난다. 무엇이 합의되었는지는 회의 후에 밝혀진다. 보통은 합의된 게 별로 없다.

메모는 독자의 시선이다

2004년 Bezos는 Amazon 임원 회의에서 PowerPoint를 폐지하고 6쪽 메모를 강제했다. 회의의 첫 30분은 침묵이다. 모두가 같은 텍스트를 같은 속도로 읽는다. 발표하지 않고, 끄덕이지 않고, 페이지만 넘긴다. 그다음에 토론이 시작된다.

이 한 가지 결정이 회의실의 권력 구조를 옮겼다. 누가 더 매끄럽게 말하느냐가 아니라, 누가 더 조밀하게 썼느냐가 중요해졌다. 합의의 단위는 '인상'에서 '문장'으로 내려왔다. 메모는 청중을 보호하지 않는다. 부족한 논리를 가리는 슬라이드 효과가 없다. 6쪽 안에서 모순이 드러나면 그 모순이 그대로 회의 테이블 위에 올라온다.

메모 회의가 어색한 이유도 여기에 있다. 발표자가 두르던 보호막이 사라지고, 독자가 따져 읽는 시선이 그 자리에 들어선다. 그 시선은 친절하지 않다. 친절은 발표자의 일이었지, 독자의 일이 아니다.

두 문화는 오래 공존했다

흥미로운 사실은 메모 시대가 슬라이드 시대를 완전히 대체한 적이 없다는 점이다. 한쪽에는 이미지 한 장 없이 텍스트만으로 한 페이지를 채우는 1-Pager 조직이 있었다. 다른 한쪽에는 이해하기 쉬운 도식과 색을 정성껏 깐 PPT 조직이 있었다. 이 두 문화는 같은 시기 같은 도시에서 나란히 굴러갔고, 둘 중 어느 쪽이 옳았는지는 끝내 판정되지 않았다.

1-Pager 조직은 합의가 정확했다. 문장에 적힌 그대로가 합의의 내용이었고, 다음 주에 만나도 해석이 어긋나지 않았다. PPT 조직은 합의가 빨랐다. 한 장의 도식이 다섯 페이지의 설명을 대신했고, 회의 시간이 짧았다. 정확함과 빠름은 둘 다 자산이고, 어느 시점에 어느 자산을 더 필요로 했느냐는 산업과 단계에 따라 달랐다.

진화한다는 말은 위로 올라간다는 말이 아니다. 환경이 바뀌면 그 환경에서 살아남는 도구가 달라진다는 말이다. 슬라이드 시대도 메모 시대도, 정답이어서 그 자리에 있던 게 아니다. 그 시대의 비용 구조에 가장 잘 맞는 도구였기에 그 자리에 있었다. 만드는 비용이 비싸고 검토 시간이 쌌던 시기에는 잘 다듬은 메모 한 편이 효율이었고, 그림 한 장으로 의사결정자의 직관에 닿는 게 더 빠르던 시기에는 PPT가 효율이었다.

프로토타입은 사용자의 시선이다

지금 회의실에 새로 들어오는 가구는 프로토타입이다. AI는 만드는 비용을 거의 없는 수준까지 끌어내리는 중이고, 비용이 충분히 떨어지면 회의의 단위도 같이 작아진다. 만들기 전에 합의하던 시대에서, 만들어 놓고 합의하는 시대로 이동한다.

프로토타입이 책상 위에 올라오면 회의의 문법이 다시 한 번 바뀐다. 읽고 머릿속에서 그림을 그리는 단계를 한 번 더 거쳐야 했던 자리에, 그 단계를 건너뛴 무언가가 놓인다. 발표자의 보호막도, 독자가 따져 읽는 시선도 거기서는 작동하지 않는다. 사용자가 한 번 클릭하면, 다섯 페이지의 메모와 스무 장의 슬라이드가 동시에 무력해지는 순간이 있다.

이것도 정답이어서가 아니다. 만드는 비용이 떨어졌으니, 회의의 단위도 따라 작아진 것뿐이다. 비용이 다시 올라간다면 메모가 돌아올 것이고, 메모마저 비싸다면 슬라이드가 돌아올 것이다. 가구가 어떤 모양일지는 환경이 정한다.

가구를 바꿔도 시선은 잘 안 바뀐다

여기서 가장 자주 어긋나는 지점이 있다. 책상 위에 프로토타입을 올려놓아도, 회의는 여전히 발표자의 회의로 흘러간다. 누군가 시연하고, 나머지는 끄덕인다. 화면 속에서 무엇이 동작하는지를 한 사람이 설명하고, 청중은 다시 슬라이드 시대의 자세로 앉아 있다. 가구는 바뀌었는데 시선은 바뀌지 않은 회의실이다.

도구가 시선을 바꾸는 게 아니라, 시선이 바뀐 사람만이 도구를 알아본다. PPT 시대에 메모를 들고 오던 사람이 있었고, 메모 시대에 프로토타입을 들고 오던 사람이 있었다. 가구는 늘 한발 늦게 도착한다. 먼저 도착해 있던 것은 시선이다.

이 비대칭이 조직마다 격차를 만든다. 같은 도구를 들여놓아도, 그 도구가 가리키는 시선을 가진 사람이 회의실 안에 몇 명이냐가 결과를 가른다. 도구는 비교적 쉽게 산다. 시선은 그렇게 쉽게 사지 못한다.

다음 가구는 무엇인가

모든 시대의 회의 도구는 그다음 도구가 와야 자신의 한계를 드러낸다. 메모의 시대는 슬라이드의 부재를 드러냈고, 프로토타입의 시대는 메모로는 결국 만져볼 수 없었다는 사실을 드러낸다. 다음에 올 것이 무엇인지 묻는 일은 흥미롭지만, 그 질문은 종종 지금을 회피하기 위한 질문이 된다.

지금 회의실에 놓인 것이 무엇을 가리고 있는지를 보는 편이 정직하다. 슬라이드가 가리고 있던 것이 검증이었다면, 메모가 가리고 있던 것은 만져봐야 알 수 있는 무엇이었다. 프로토타입이 가리고 있는 것은 아직 잘 모른다. 모른 채로, 그 가구를 책상 위에 올려두는 일이 지금의 회의다.

채용 추천 시스템은 어떻게 '상위 지원자'를 가려내는가

Sat, 25 Apr 2026 10:00:00 GMT

어느 저녁, LinkedIn에서 푸시 알림이 왔다. "회원님은 Senior Java Engineer 외 채용공고 80+개에 채용될 가능성이 가장 높습니다." 얼핏 반가운 문장이지만, 엔지니어의 눈으로 다시 읽으면 두 가지 질문이 따라붙는다. 이 80+개는 어떻게 선정되었는가. 그리고 "채용될 가능성이 가장 높다"는 점수는 무엇을 측정한 것인가.

이 글은 두 질문을 리크루트먼트 추천 시스템(Recruitment Recommender System)의 문제로 옮겨 놓고, 공개된 산업 사례와 학계 논문을 교차 참조해 답을 구성하는 기술 리포트다. LinkedIn의 엔지니어링 블로그와 논문들이 가장 많은 구체성을 제공하므로 예시의 대부분을 그쪽에서 가져오지만, 기법 자체는 Indeed, BOSS Zhipin, 그리고 학계의 Person-Job Fit 계열 연구에 공통적으로 적용되는 것들이다. 용어가 낯설면 글 끝의 "더 알면 좋은 개념" 섹션을 먼저 훑어도 좋다.

리크루트먼트 RecSys는 왜 일반 추천과 다른가

상품 추천과 영상 추천은 대체로 사용자의 선호라는 한 축을 최적화한다. 클릭이 발생하면 그 자체로 보상이고, 추천의 결과는 소비 시간으로 환산된다. 리크루트먼트 추천에는 두 가지가 다르다.

첫째, 양방향 매칭(reciprocal matching)이다. 지원자가 공고를 좋아해도 채용담당자가 그 지원자를 뽑지 않으면 추천은 실패다. 반대 방향도 마찬가지다. 데이팅 앱이 양쪽 호감을 동시에 봐야 성사되는 것과 같은 구조다. 시스템은 지원자 선호와 채용담당자 선호를 동시에 모델링해야 한다. LinkedIn의 리쿠르터 검색/추천 시스템은 이 비대칭을 명시적으로 다루며 공고-지원자 양쪽을 각각 임베딩(embedding)으로 학습한다 (LinkedIn Engineering — AI Behind Recruiter Search and Recommendation Systems).

둘째, 라벨 희소성이다. 클릭(CTR, Click-Through Rate)은 넘쳐나지만 최종 채용(confirmed hire)은 수백에서 수천 번의 노출에 한 번 정도 발생하는 이벤트다. 게다가 "누가 실제로 채용되었는가"는 시스템 내부에 명시적으로 기록되지 않고, 대개 지원자의 프로필 직책 변화 같은 간접 신호로 추정된다. 이 때문에 리크루트먼트 RecSys는 클릭/지원 같은 밀도 높은 신호로 모델을 학습하되, 희소한 downstream 신호로 목적함수를 보정하는 다중 신호 설계를 거의 예외 없이 채택한다.

3단계 파이프라인 -- Retrieval, Ranking, Re-ranking

대규모 리크루트먼트 RecSys는 대부분 세 단계의 계단식 파이프라인으로 동작한다. 수백만 공고에서 출발해 수백 개로 좁히고, 수십 개로 랭킹하고, 최종 화면에서 다양성·공정성 제약을 반영해 재배열한다. LinkedIn의 공식 블로그와 LiRank (arXiv:2402.06859) 논문이 이 구조를 가장 명확하게 기록하고 있다.

단계	후보 수	대표 기법	목적
Retrieval (L0)	수억 → 수백	Two-tower 임베딩, ANN, 그래프 워크, 휴리스틱	빠른 리콜
Ranking (L1/L2)	수백 → 수십	XGBoost, DCNv2, MTL, GDMix	정밀한 스코어
Re-ranking	수십 → 화면	베이지안 가중합, 다양성·공정성 제약	최종 배열

Retrieval은 "후보 풀을 만드는" 넓고 거친 단계, Ranking은 "소수의 후보를 정밀하게 줄세우는" 단계, Re-ranking은 "줄 세운 결과를 비즈니스 규칙에 맞춰 매만지는" 후처리 단계다. 각 단계가 해결하는 문제가 다르고, 따라서 모델이 예측하는 "확률"의 의미도 다르다. "채용될 가능성" 이라는 한 문장이 사실은 이 세 단계가 포갠 점수의 투영이다.

Retrieval -- 수억 공고에서 수백 개로

Retrieval 단계의 표준은 Two-tower 모델이다. 지원자 타워는 프로필·스킬·행동 시퀀스를 벡터로 압축하고, 공고 타워는 JD·회사·직무를 벡터로 압축한다. 두 벡터의 내적(dot product)이 매칭 스코어이며, 공고 벡터들은 미리 인덱싱해 ANN(Approximate Nearest Neighbor) 검색으로 수백 개의 후보를 상수 시간에 뽑는다. 산업 공통의 기법이다 (LinkedIn Engineering — Using Embeddings to Up Its Match Game for Job Seekers).

2024년 LinkedIn이 공개한 JUDE는 이 구조에 LLM을 얹은 사례다. 7B 파라미터 Mistral을 LoRA로 파인튜닝하여 지원자·공고 타워를 각각 구축하고, 해시 기반 디듀플리케이션으로 추론량을 약 6배 줄였다. A/B 테스트 결과는 qualified application +2.07%, dismiss-to-apply -5.13%, 전체 application +1.91%로 보고되었다 (LinkedIn Engineering — JUDE: LLM-Based Representation Learning for Job Recommendations).

주의할 점은, Retrieval은 정확한 랭킹이 아니라 리콜을 맡는다는 것이다. 여기서의 스코어는 "이 공고가 지원자의 관심 공간에 들어오는가"를 판정하는 대략적 좌표이지, 채용 확률이 아니다. 사용자가 받은 알림의 "80+개"는 이 단계를 통과한 모수에 가깝다.

Ranking -- 클릭, 지원, 채용을 동시에 예측한다

Ranking 단계는 두 겹으로 쪼개져 있다. L1 Ranking에서 로지스틱 회귀나 XGBoost 같은 가벼운 모델로 후보 점수를 캘리브레이션(calibration)하고, L2 Ranking에서 심층 다중 작업 학습(Multi-Task Learning, MTL) 모델이 CTR·지원·소셜 액션 등 여러 타워를 동시에 예측한다. LinkedIn의 최신 공개 아키텍처는 LiRank로, DCNv2(Deep & Cross Network v2)에 어텐션과 잔차 연결(residual connection)을 결합한 Residual DCN을 중심에 둔다 (LiRank (arXiv:2402.06859)).

피처 측면에서는 세 갈래의 신호가 합류한다.

콘텐츠 신호: 프로필 임베딩, 스킬 벡터, JD 임베딩, 회사·직무 카테고리.
활동 신호: apply, save, dismiss 시퀀스를 순차 모델로 요약한 활동 임베딩. 2022년 LinkedIn 공개 실험에서 이 임베딩 하나만으로 confirmed hire가 약 5% 개선된 것으로 보고되었다 (LinkedIn Engineering — Improving Job Matching with Machine-Learned Activity Features).
개인화 층: GDMix가 전역 고정효과(fixed effect) 모델 위에 멤버·공고별 랜덤 효과(random effect) 모델을 얹는 혼합 효과(mixed effects) 구조로, 글로벌 모델과 개인 모델을 동시에 운영한다 (LinkedIn Engineering — GDMix: A Deep Ranking Personalization Framework).

학계 선행 연구로는 LinkedIn이 2018년 공개한 Towards Deep Learning for Talent Search (arXiv:1809.06473)와 Personalized Job Recommendation System at LinkedIn (RecSys 2017)이 이 파이프라인의 초기 뼈대를 제시한다. engagement label(클릭·지원)과 relevance label(전문 평가자 주석)을 이중 감독으로 사용하는 설계가 RecSys 2017 논문에서 이미 정립되어 있다.

Person-Job Fit -- 이력서와 JD의 의미론적 매칭

Ranking 내부의 핵심 서브 모듈 중 하나가 Person-Job Fit(PJF) 이다. 지원자의 이력서 텍스트와 공고 JD 텍스트를 각각 인코더로 표현한 뒤, 두 표현의 상호작용으로 매칭 점수를 계산하는 계열의 모델이다. 검색에서의 쿼리-문서 매칭을 "사람-공고" 쌍에 맞춰 변형한 분야에 가깝다.

학계 계보는 대략 다음과 같다.

PJFNN -- CNN(Convolutional Neural Network) 기반 이중 인코더로 이력서와 JD의 표현을 학습. 리크루트먼트 NLP의 사실상 베이스라인 (Person-Job Fit: Joint Representation Learning (arXiv:1810.04040)).
APJFNN / BPJFNN -- "어떤 요건을 충족시키는가"에 가중치를 두는 ability-aware 어텐션으로 확장.
PJFCANN -- Co-Attention으로 이력서와 JD의 교차 참조를 명시적으로 다룸 (PJFCANN (Neurocomputing 2022)).
도메인 적응 PJF -- BOSS Zhipin이 EMNLP 2019에서 제안한 문장 수준 어텐션 + 도메인 적응 구조 (BOSS Zhipin Domain Adaptation (EMNLP 2019)).

LinkedIn의 프로덕션 시스템은 공식적으로 PJFNN 이름을 쓰지 않지만, co-attention과 활동 임베딩의 결합은 같은 사상을 대규모 스케일에 재구현한 것에 가깝다. 한국어권 구직 플랫폼이 이 계열을 응용할 때 대부분 참조하는 원형 논문들이 PJFNN과 그 확장들이다.

Re-ranking -- 가중치, 다양성, 공정성

Ranking이 뽑아낸 수십 개 후보는 그대로 화면에 뿌려지지 않는다. Re-ranking 단계에서 여러 타워의 점수를 베이지안 최적화로 가중 결합하고, 동일 회사·동일 직무 중복 노출을 억제하며, 콜드 공고에 탐색 예산을 배정한다. 특히 공정성(fairness) 제약은 LinkedIn이 프로덕션 랭킹에 공식적으로 도입한 모듈 중 하나로, Fairness-Aware Ranking in Search & Recommendation Systems with Application to LinkedIn Talent Search (KDD 2019, arXiv:1905.01989)에서 성별 등 보호속성 기반의 분포 제약을 Top-k 결과에 주입하는 방법을 공개했다.

Re-ranking의 관점에서 보면, 최종 리스트에 오른 지원자·공고의 순서는 "가장 확률이 높은 것"이 아니라 "제약 조건을 반영한 것" 이다. 이 구간을 이해하지 못하면 확률 해석에 큰 오차가 생긴다.

"채용될 가능성" 스코어의 실체

이제 사용자가 받은 알림 문장으로 돌아가자. LinkedIn이 Help 문서에서 밝히는 Top Applicant의 정의는 다음과 같다.

Premium 전용 기능이다.
특정 공고에 지원자가 10명 이상일 때만 활성화된다.
해당 공고 지원자 기준 **상위 50%**에 들면 Top Applicant로 분류된다.

즉 Top Applicant는 확률 보정된 채용 예측이 아니라, 공고 단위의 상대 랭킹이다. 사용자가 받은 푸시("80+개 공고에서 가능성이 가장 높다")는 이 공고별 상대 랭킹을 여러 공고에 걸쳐 집계한 메시지로, 공식 문서에는 이 집계 로직의 세부는 공개되어 있지 않다. 엔지니어링 블로그와 학계 논문을 종합해 합리적으로 추정하면, 다음 계층의 스코어가 합산된 결과다.

매칭 스코어: Two-tower 임베딩 유사도(JUDE)로 뽑은 후보 공고별 의미론적 적합도.
클릭·지원 예측: LiRank 계열 다중 작업 모델이 내놓는 apply 확률.
프록시 채용 라벨: 프로필 직책 업데이트 감지로 구성한 confirmed hire 신호에 학습된 downstream 예측치.
공정성·다양성 보정: Re-ranking 단계에서의 제약 반영.

알림에 등장하는 "가능성"은 채용으로 이어질 확률의 보정된 값이 아니라, apply 확률과 상대 순위에 프록시 채용 라벨을 얇게 덮은 종합 점수다. Confirmed hire 자체가 직접 관측되지 않고 프로필 업데이트 같은 간접 신호로 근사되기 때문에, 이 스코어는 구조적으로 과거 채용 패턴을 재현할 뿐 미래 채용 확률을 보장하지는 못한다.

목적함수가 바꾸는 "가능성"의 정의

같은 지원자·공고 쌍에 대해 시스템이 내놓는 점수는 어떤 목적함수를 최적화했는가에 따라 달라진다. 대표적인 후보들을 비교하면 다음과 같다.

목적함수	밀도	실제로 예측하는 것
CTR	매우 높음	제목과 회사명이 지원자의 주의를 끄는가
Apply	높음	지원자가 지원 버튼을 누를 만한가
InMail 수락률	중간	채용담당자의 메시지에 지원자가 응답하는가
Qualified Application	낮음	지원이 유효한 서류 심사까지 도달하는가
Confirmed Hire	매우 낮음	실제로 채용으로 이어지는가

LinkedIn Engineering — Building the Next Generation of Job Search는 최근 몇 년의 흐름이 CTR·Apply 같은 상위 깔때기 신호에서 qualified application·confirmed hire 같은 downstream outcome으로 목적함수가 내려가고 있음을 명시적으로 서술한다. 같은 "상위 지원자" 라벨이라도 2020년과 2026년의 그것이 같은 것을 의미하지 않는다.

스코어와 기회 사이의 간극

정리하면, "채용될 가능성이 가장 높다"는 한 문장 뒤에는 다음이 쌓여 있다.

Retrieval이 수억 공고에서 수백 개로 좁힌 리콜 스코어.
Multi-task ranking이 계산한 apply 확률과 소셜 액션 확률.
Person-Job Fit 계열 인코더가 추정한 텍스트 적합도.
GDMix의 개인화 레이어가 얹은 멤버별 조정.
프로필 업데이트로 추정한 프록시 채용 라벨에 대한 예측.
Re-ranking의 공정성·다양성 제약과 상대 랭킹 임계값(상위 50%).

이 중 어느 하나도 "채용 확률"로 직접 해석되도록 캘리브레이션되어 있지 않다. 그럼에도 알림 문장은 수학적 확률인 것처럼 말한다. 이는 플랫폼이 사용자에게 제공하는 단일한 요약 메시지의 성격이지, 시스템 내부에서 실제로 사용되는 변수명이 아니다.

편향과 한계는 여러 문헌이 지적해 왔다. 행동 신호를 학습에 쓰는 순간 성별·연령 같은 보호속성이 행동 패턴을 통해 간접적으로 재현될 수 있으며 (MIT Technology Review (2021)), 그래서 Fairness-Aware Ranking (KDD 2019) 같은 재랭킹 모듈이 요구된다. "상위 지원자"가 객관적 확률이 아니라 정책 선택이 녹아든 랭킹 지표라는 사실을 인식하는 것 자체가, 이 시스템을 읽는 가장 기본적인 출발점이다.

알림이 말하는 "가능성" 은 과거 데이터에 포착된 패턴의 투영이다. 그 투영이 유용한 신호라는 것과, 그 투영이 곧 기회라는 것은 다른 이야기다. 리크루트먼트 RecSys의 구조를 이해한다는 것은, 그 두 문장을 분리해 읽을 수 있게 된다는 뜻이기도 하다.

더 알면 좋은 개념

본문에서 가볍게만 언급한 용어의 배경. 필요에 따라 참조하면 된다.

임베딩(embedding)

사람·문서 같은 대상을 수백~수천 차원의 실수 벡터로 압축한 표현. 벡터 사이의 거리가 의미론적 유사도가 되도록 훈련된다. 추천·검색에서 모든 대상을 "좌표로 바꾼 다음 가까운 것을 찾는" 접근의 출발점.

Two-tower 모델

지원자 쪽과 공고 쪽을 각각 독립된 두 신경망 "타워"로 따로 임베딩하는 구조. 두 타워의 출력 벡터를 내적해 매칭 스코어를 낸다. 공고 벡터를 미리 인덱싱해 두면 지원자 벡터 하나만 실시간으로 계산해 ANN 검색으로 상수 시간에 후보를 뽑을 수 있다. 리크루트먼트뿐 아니라 광고·영상 추천의 Retrieval 단계 표준.

ANN (Approximate Nearest Neighbor)

수억 개 벡터 중 가장 가까운 소수를 근사적으로 빠르게 찾는 검색 기법. 정확한 최근접 검색은 비용이 크기 때문에 약간의 정확도를 양보하고 속도를 얻는다.

LoRA

대형 모델의 원본 가중치는 고정한 채 저차원 어댑터만 덧붙여 학습하는 파인튜닝 기법. 풀파인튜닝 대비 학습·저장 비용이 훨씬 작아 LLM 기반 임베딩 타워를 현실 비용으로 운영할 수 있게 한다.

로지스틱 회귀 / XGBoost

전자는 확률 분류의 고전적인 선형 모델, 후자는 의사결정 나무를 여러 개 앙상블하는 고성능 테이블 모델. 둘 다 심층 신경망보다 가볍고 해석도 쉬워 Ranking 파이프라인의 L1 단계에서 자주 쓰인다.

캘리브레이션(calibration)

서로 다른 후보 소스가 매긴 점수를 같은 척도로 맞추는 보정 작업. 넓게는 모델이 낸 점수 0.7이 실제 빈도로도 70%에 해당하도록 맞추는 확률 보정까지 포함한다. 여러 모델의 출력을 합치려면 반드시 필요하다.

다중 작업 학습(MTL)

여러 목표를 하나의 네트워크로 동시에 예측하며 공유 표현을 학습하는 기법. 라벨이 희소한 태스크가 밀도 높은 태스크로부터 간접적으로 배울 수 있다는 장점이 있다. 리크루트먼트 Ranking에서 클릭·지원·confirmed hire를 한 모델로 동시에 예측하는 이유.

DCNv2 / 잔차 연결

DCNv2(Deep & Cross Network v2)는 피처끼리의 교차 조합을 명시적으로 학습하도록 설계된 신경망. 잔차 연결(residual connection)은 입력을 출력에 더해 깊은 네트워크에서 학습을 안정화하는 구조로, ResNet에서 처음 대중화됐다. 둘을 결합한 Residual DCN이 LinkedIn LiRank의 중심.

고정 효과 / 랜덤 효과 / 혼합 효과

통계학의 혼합 효과(mixed effects) 모형에서 유래한 개념. 모든 관측에 공통으로 적용되는 전역 파라미터가 고정 효과, 그룹(사용자·공고 등) 단위로 개별 편차를 잡는 파라미터가 랜덤 효과. LinkedIn의 GDMix는 이 두 층을 분리해 글로벌 모델과 개인화 모델을 한 시스템에서 운영한다.

engagement label / relevance label

전자는 클릭·지원 같은 사용자 행동에서 얻는 암묵적 학습 신호, 후자는 전문 평가자가 "이 매칭이 적합한가"를 주석한 명시적 학습 신호. 전자는 풍부하지만 편향되기 쉽고, 후자는 편향은 적지만 수가 적다. 두 신호를 함께 쓰는 이중 감독이 대규모 리크루트먼트 랭킹의 표준 설계.

인코더

텍스트·이미지·사용자 프로필 같은 입력을 벡터 표현으로 바꾸는 신경망. Person-Job Fit 계열 모델은 이력서 인코더와 JD 인코더를 따로 두는 이중 인코더 구조를 기본으로 한다.

Co-Attention

한쪽 텍스트를 해석할 때 다른 쪽의 어느 부분을 참고할지 서로 계산해 주고받는 양방향 어텐션. 이력서 각 문장이 JD의 어느 요건에 대응하는지, 그 역방향까지 함께 학습된다.

도메인 적응(domain adaptation)

source 도메인에서 학습한 모델을 target 도메인에서도 잘 작동하도록 적응시키는 기법. 직군·산업이 달라지면 이력서와 JD의 어휘 분포도 달라지는데, 이 간극을 좁히기 위해 쓰인다.

베이지안 최적화

적은 횟수의 실험으로 최적 조합을 찾는 탐색 기법. 매번 결과를 관찰해 다음 실험 지점을 확률적으로 선택한다. Re-ranking의 타워 가중치 튜닝처럼 실험 비용이 큰 하이퍼파라미터 탐색에 자주 쓰인다.

콜드 공고 / Top-k

콜드 공고는 이력이 거의 없어 학습 신호가 부족한 신규 공고. 추천 시스템은 이런 공고에 별도의 탐색 예산을 배정해야 랭킹의 장기 다양성을 유지한다. Top-k는 추천 리스트의 상위 k개 결과를 가리키며, 공정성 제약은 대개 Top-k 단위로 적용된다.

A/B 테스트

같은 기간 트래픽을 둘로 나눠 한쪽만 새 모델로 서빙하며 효과를 측정하는 온라인 실험 방법. 리크루트먼트 추천에서는 qualified application, dismiss-to-apply, confirmed hire 같은 downstream 지표의 변화량을 기준으로 판정한다.

참고문헌

LinkedIn Engineering Blog

학술 논문

공식 문서 / 미디어

내려놓음의 역설 — 《오프 먼트》가 말하는 가장 어려운 전략

Fri, 24 Apr 2026 09:00:00 GMT

"덜 애쓰면 더 잘된다"는 말의 수상함

"덜 애쓰면 더 잘된다." 이 문장은 대부분의 사람에게 거짓말처럼 들린다. 살아온 경험이 그 반대를 가리키기 때문이다. 더 오래 준비한 사람이 시험을 잘 보고, 더 오래 연습한 사람이 무대에서 덜 떤다. 밤을 새운 다음 날은 제안서가 통과되고, 느슨한 주는 지표가 내려간다. 인과의 방향은 명확하다. 애쓴 만큼 결과가 나온다.

그런데 상담가 장재열은 《오프 먼트(OFF-MENT)》에서 이 확신을 조심스럽게 비튼다. 목표를 낮추라는 말이 아니다. 오히려 목표는 품고 있어도 된다. 내려놓아야 하는 건 목표가 아니라, 그 목표를 잡고 있는 손의 힘이라고 한다. 저자는 이것을 '스위치를 끄고 켜는 힘'이라고 부른다. 일과 삶 양쪽에서 스스로의 전원을 조절할 줄 아는 능력. 말은 근사한데, 실제로 뭘 어떻게 하라는 말일까.

목표와 강박은 같은 것이 아니다

목표는 방향이다. 어디로 갈 것인가의 문제. 강박은 긴장이다. 그 방향을 붙잡는 손의 힘의 크기. 이 둘은 원래 구분되는데, 일상 속에서 대부분 하나로 묶여 움직인다. 목표가 커질수록 강박도 같이 커지고, 강박이 옅어지면 목표 자체가 흐려진 것처럼 느껴진다.

문제는 여기서 생긴다. 목표와 강박이 한 덩어리로 움직이면, 둘 중 하나를 풀려고 할 때 다른 하나까지 같이 풀린다. 강박만 낮추고 싶어도 목표가 같이 낮아진다. 그래서 많은 사람이 "긴장을 풀어라"는 조언을 받으면 본능적으로 저항한다. 긴장을 풀었다가 목표가 흐려질까 봐. 목표가 흐려졌다가 그 자리가 비어버릴까 봐.

《오프 먼트》가 제안하는 것은 이 한 덩어리를 분리하는 작업이다. 목표는 벡터, 강박은 스칼라. 방향은 유지하되 크기는 조절 가능하다는 감각. 이 감각은 타고나는 것이 아니라 훈련해서 얻는 것에 가깝다.

왜 역설은 성립하는가

강박이 문제인 이유는 감정적으로 피곤하기 때문이 아니다. 그 정도면 그저 "힘들지만 해야 한다" 수준에서 끝난다. 진짜 문제는 강박이 목표 달성의 확률 자체를 깎는다는 점이다.

강박은 판단력을 좁힌다. 긴장 상태에 오래 놓인 뇌는 넓은 시야를 포기하고 가까운 위협에 집중한다. 먼 맥락을 보지 못하고, 대안을 떠올리지 못하고, 자신이 지금 잘못된 해결책에 매달리고 있다는 사실조차 인식하지 못한다. 같은 문제 앞에서도 덜 긴장한 사람이 더 나은 답을 내는 이유는 머리가 더 좋아서가 아니라 시야가 더 넓어서다.

회복력도 같이 깎인다. 중요한 일은 대부분 한 번의 시도로 끝나지 않는다. 실패 후에 얼마나 빨리 다시 자세를 잡느냐가 결과를 가른다. 강박이 높은 사람은 실패의 충격이 크고, 충격이 큰 만큼 재정비에 들어가는 시간도 길다. 같은 목표를 쫓는 두 사람 중 한 명이 세 번 넘어졌다가 네 번째에 일어서고, 다른 한 명이 두 번 넘어지고 멈춘다면, 단순한 산수로 후자가 목표에 닿을 확률이 낮다.

그러다 자기 자신까지 소모한다. 장재열은 이 상태를 두고 "깨달음은 끓는 물과 같아서 계속 장작을 넣지 않으면 본래로 돌아간다"고 썼다. 그는 이 문장을 깨달음의 유지 문제로 꺼냈지만, 같은 구조는 에너지 소모에도 적용된다. 강박은 장작을 한 번에 다 태우는 방식이다. 처음 몇 시간은 뜨겁지만, 남은 길이 아직 절반 이상일 때 땔감이 바닥난다. 내려놓음은 장작을 아끼는 기술이다.

이 세 가지가 겹치면 답은 분명하다. 동일한 목표 앞에서, 강박이 낮은 사람이 더 자주 도달한다. 덜 애쓰는 것이 아니라, 애쓰는 방식이 다른 것이다.

내려놓음은 포기가 아니다

이 지점에서 자주 오는 오해가 있다. 내려놓음을 '포기', '느슨함', '마음 비우기'와 같은 단어로 읽는 것이다. 이런 독해는 내려놓음을 쉬운 일로 만든다. 그냥 덜 신경 쓰면 되니까. 그러나 《오프 먼트》가 가리키는 내려놓음은 그보다 훨씬 세밀한 작업이다.

유용한 구분은 이렇다. 실행 밀도와 감정 점유율을 나눠보는 것. 실행 밀도는 오늘 하루 동안 이 목표에 투입된 시간과 움직임의 양이다. 감정 점유율은 그 사이 머릿속 공간 중 이 목표가 차지한 비율이다. 지금까지 우리는 두 개가 함께 움직여야만 진심이라고 배워왔다. 밤새 걱정하지 않으면 덜 원하는 거라고, 쉬는 시간에도 머리에 붙어 있지 않으면 책임감이 없는 거라고.

내려놓음의 역설은 여기서 작동한다. 실행 밀도는 그대로 두고 감정 점유율만 떼어내는 것. 오늘 해야 할 일을 어제와 같은 순서, 같은 시간에 하되, 퇴근 후 혹은 샤워 중 혹은 식사 자리에 그 일을 끌고 들어오지 않는 것. "어떻게든 되겠죠"라는 체념처럼 들리는 문장이 실은 이 감정 점유율을 낮추는 선언이다. 포기한다는 뜻이 아니라, 내일 다시 잡을 때까지는 한 번 내려놓는다는 뜻이다.

실무의 언어로 번역하면

이 원리를 실무 언어로 옮기면 몇 가지 관찰 가능한 신호로 내려온다.

마감 앞에서의 호흡이 다르다. 강박이 높은 상태에서는 마감 직전에 호흡이 얕아지고, 결과물이 아니라 "어떻게 보일지"에 에너지가 새어나간다. 감정 점유율이 낮은 상태에서는 마감이 다가와도 호흡이 깊게 유지되고, 남은 시간을 결과물 자체에 쓸 수 있다. 같은 사람이 같은 마감 앞에서, 어느 날은 호흡이 얕고 어느 날은 깊다면, 변한 것은 실력이 아니라 손의 힘이다.

실패 후 회복 시간도 다르다. 강박은 실패를 정체성의 문제로 번역하는 경향이 있다. 이 프로젝트가 실패했다는 사실이, 내가 무능한 사람이라는 결론으로 순식간에 건너뛴다. 그러면 회복에 며칠이 필요해진다. 감정 점유율이 낮은 상태에서는 실패가 그냥 실패로 남는다. 원인 분석에 몇 시간, 다음 시도 설계에 몇 시간. 반나절이면 다시 자세가 잡힌다.

중거리 이후의 속도도 다르다. 짧은 기간만 비교하면 강박이 높은 쪽이 빠르게 치고 나간다. 그러나 한 달, 세 달, 여섯 달 단위로 보면 순서가 뒤집히는 경우가 많다. 강박은 단거리 경기에서는 유리하지만, 대부분의 일은 단거리가 아니기 때문이다. 장재열의 비유를 빌리면, 러닝머신에서 버티는 사람과 무빙워크 위에서 제 속도로 걷는 사람 중, 같은 역에 먼저 도착하는 쪽은 후자일 때가 많다.

내려놓음은 기질이 아니라 훈련이다

내려놓음의 또 다른 오해는 그것이 타고난 성향의 문제라는 생각이다. 원래 태평한 사람과 원래 불안한 사람이 나뉘어 있고, 불안한 사람은 어쩔 수 없다는 체념. 《오프 먼트》의 제안이 의미 있는 이유는 이 체념을 기각한다는 점이다. 저자는 내려놓음을 기질이 아니라 훈련 대상으로 본다. 빈손 산책, 케렌시아(자기만의 쉼 공간), 의식적 혼자 있기 같은 구체적인 동작들이 반복될 때, 감정 점유율을 조절하는 근육이 조금씩 붙는다.

핵심은 이 근육이 '안 애쓰는 근육'이 아니라 '적절한 순간에 스위치를 끄는 근육'이라는 데 있다. 완전히 꺼둘 필요는 없다. 일할 때는 켜두고, 일이 끝난 뒤에는 끈다. 두 상태를 오갈 수 있다는 것. 그것이 저자가 말하는 오프 먼트다.

이 관점으로 보면 "덜 애쓰면 더 잘된다"는 문장은 더 이상 거짓말처럼 들리지 않는다. 정확히 말하면, 덜 애쓰는 것이 아니라 덜 움켜쥐는 것이다. 목표는 그대로 옆에 둔다. 품에 꼭 껴안지 않을 뿐이다. 껴안은 것은 잘 볼 수 없다. 옆에 두어야 잘 보인다. 그리고 잘 보이는 것이, 결국 잘 닿는다.

식어 가는 자리에서 성공을 바라는 사람들

Wed, 22 Apr 2026 11:00:00 GMT

요즘 이런 뉴스를 한 번쯤 본 적이 있을 것이다. 길을 가던 사람에게 갑자기 흉기를 휘두른 범죄자가 체포된다. 수사관이 묻는다. "미안하지 않습니까?" 범죄자는 고개를 숙이지 않는다. 도리어 어리둥절한 얼굴로 되묻는다. "제가 왜 미안해야 하죠?"

우리는 이런 사람을 보면 쉽게 꼬리표를 붙인다. "사이코패스라서 그래." 그런데 30년 가까이 범죄자들을 만나 온 한 프로파일러는 다르게 말한다. 사이코패스라서 죄책감이 없는 게 아니라, 그들에겐 애초에 미안해야 할 이유가 없다는 것이다. 이 말이 무슨 뜻인지 따라가다 보면, 이야기는 몇몇 이상한 사람의 문제로 끝나지 않는다.

미안함은 어디서 생겨나는가

잠깐 생각해 보자. 누군가에게 미안하다고 느끼려면 무엇이 필요할까.

상대가 나와 '같은 편'이라는 감각이 먼저 깔려 있어야 한다. 같은 사회에 살고, 같은 거리를 걷고, 어떤 식으로든 서로 엮여 있다는 느낌 말이다. 그 바탕이 있어야 그 위에서 미안함이라는 감정이 자란다.

프로파일러가 만난 범죄자들은 거짓말을 하거나 입을 다문 것이 아니었다. 그들은 정말로 미안할 이유를 이해하지 못했다. 그들에게 피해자는 나와 같은 세상에 속한 사람이 아니었다. 그냥 지나가는 사물에 가까웠다. 같은 편이라는 바탕이 사라진 자리에서는, 그 위에서 자라야 할 감정도 함께 사라진다.

그렇다면 왜 그 바탕이 사라졌을까. 원래부터 그렇게 태어났기 때문일까, 아니면 자라는 동안 조금씩 지워져 간 걸까.

살인자의 뇌를 가졌지만 살인자가 되지 않은 사람

흥미로운 이야기가 하나 있다.

미국에 짐 팰런이라는 과학자가 있다. 그의 일은 살인범들의 뇌 사진을 분석하는 것이었다. 어느 날 그는 살인범과 일반인의 뇌를 비교하려고 자기 가족의 뇌 사진도 함께 찍어 섞어 두었다.

그러다 한 장의 사진이 눈에 들어왔다. 보자마자 그는 소름이 돋았다. 살인범들에게서 반복적으로 나타나는 특징이 너무도 선명했다. 그는 동료들에게 말했다. "이 사람은 위험하다. 사회에 돌아다니게 두면 안 된다." 그러고 나서 이름을 가린 종이를 떼어 냈다. 사진의 주인은 자기 자신이었다.

놀라서 가계도를 뒤져 보니, 조상 중에 살인자가 일곱 명이나 있었다. 그는 그야말로 '살인자의 뇌'를 가지고 태어난 셈이었다. 그런데 그는 아무도 죽이지 않았다. 오히려 가족과 친구들이 고민이 있을 때 찾아가는 조언자로 살아왔다.

그는 이렇게 말한다. "어린 시절이 믿을 수 없을 정도로 따뜻했다. 그 행복이 내 유전자를 씻어 낸 것 같다."

유전자는 방아쇠 같은 것이다. 방아쇠가 있다고 총이 저절로 발사되지는 않는다. 누가 당겨야 발사된다. 팰런의 경우, 따뜻한 환경이 방아쇠에 끝내 손을 대지 않은 셈이다.

이 이야기를 거꾸로 읽으면 오싹한 말이 된다. 특별히 나쁜 것을 타고나지 않은 사람이라도, 자라는 곳이 충분히 메마르면 방아쇠가 당겨질 수 있다는 뜻이기 때문이다. 학교가 배우는 곳이 아니라 서로 밟고 올라가는 곳이 되고, 선생님이 아이를 길러 내는 사람이 아니라 입시 서비스를 파는 사람이 되었을 때, 아이들에게 남는 것은 목표뿐이다. 다투고 화해하고 다시 엮이는 긴 과정을 배울 시간이 그들에게는 없다.

사람 사이에 흐르는 보이지 않는 무언가

가만히 보면, 우리는 하루 동안 생각보다 많은 것을 주고받는다.

아침에 엘리베이터에서 마주친 이웃과 눈인사를 나눈다. 편의점 계산대에서 거스름돈을 받으며 "감사합니다"를 덧붙인다. 붐비는 지하철에서 어깨를 부딪친 사람에게 "죄송합니다" 하고 지나간다. 복도에서 아이 울음소리가 들리면 잠시 걸음이 느려진다.

대단한 일이 아니다. 돈이 오가는 것도 아니고, 서로의 이름을 기억하는 것도 아니다. 하지만 이 자잘한 주고받음이 사람과 사람 사이에 작은 온기를 돌게 한다. 이 온기는 통장처럼 쌓아 두는 것이 아니라, 매일 주고받아야 살아 있는 것이다.

이 온기가 식기 시작하면 이상한 일이 생긴다. 옆에 있는 사람이 그냥 '좀 먼 사람'이 되는 게 아니라, '아예 없는 사람'이 된다. 길에 쓰러진 낯선 사람을 보고 그냥 지나치는 일이 점점 자연스러워지는 것도 그런 이유에서다. 차가워서가 아니다. 그 사람이 내 온기가 닿는 범위 바깥으로 밀려나 있기 때문이다.

댓글창에서 누군가의 죽음이 농담거리가 되는 순간, 익명의 화면 뒤에서 쏟아지는 조롱, 지하철에서 어깨를 스쳤다고 튀어나오는 욕설. 이 모든 풍경은, 사람들 사이의 온기가 식어 버린 자리에서 자주 볼 수 있는 것들이다.

더 무서운 고립은 '문을 닫은 고립'이다

고립에는 두 종류가 있다.

하나는 세상이 나를 밀어낸 경우다. 아무리 다가가도 사람들이 받아 주지 않아 혼자가 된 사람이다. 이런 사람은 외롭고, 아프다. 그래도 마음 한구석에서는 여전히 연결되고 싶어 한다. 창문 바깥에서 계속 문을 두드리고 있는 셈이다.

다른 하나는 내가 먼저 세상을 밀어낸 경우다. "나는 굳이 너희들과 엮일 이유가 없어." 이렇게 정해 버린 사람이다. 두드림이 없다. 대신 옆자리가 지워진다.

더 무서운 쪽은 두 번째다. 외로운 사람은 누가 손을 내밀면 조심스럽게라도 잡는다. 그러나 스스로 문을 닫은 사람은 손을 내밀어도 필요 없다고 한다. 그렇게 점점 더 안쪽으로 들어간다. 그 끝자락에 "저 사람들은 제 사회가 아닙니다"라는 말이 있다.

여기서 앞서 말한 팰런을 다시 떠올려 보면 이야기가 한 번 더 뒤집힌다. 그는 사실 감정적으로 차가운 사람이라고 스스로 말했다. 누가 울어도 함께 울어지지 않는다고 했다. 원래 이런 온도의 사람이라면 남과 엮이는 일이 번거롭게 느껴져서 문을 닫기 쉽다. 그런데 팰런은 정반대로 갔다. 사람들의 이야기를 몇 시간이고 들어 주고, 차분하게 조언한다. 문을 닫지 않았기 때문이다.

즉 타고난 감정의 온도와, 문을 열어 둘지 닫을지는 서로 다른 축이다. 차갑게 태어난 사람도 문이 열려 있으면 조언자가 되고, 따뜻하게 태어난 사람도 문이 닫히면 아무에게도 미안하지 않은 사람이 된다. 중요한 것은 타고난 것이 아니라, 문을 어느 쪽으로 두고 사느냐는 쪽이다.

성공만 남고 사람은 지워진다

그런데 여기서 이상한 점이 하나 있다.

문을 닫고 사는 사람이라면 세상에 대한 의욕도 같이 식었을 것 같지만, 실제로는 그렇지 않다. 이들도 성공은 간절히 원한다. 돈을 벌고 싶고, 이름이 알려지고 싶고, 자리가 높아지고 싶은 마음은 그대로 남아 있다. 오히려 더 뜨거울 때도 있다.

다만 그 성공의 길 위에 다른 사람이 보이지 않는다. 누군가를 밟아야 올라갈 수 있다면 망설임 없이 밟는다. 옆에서 비슷한 속도로 달리는 사람이 있어도, 같이 가는 동료가 아니라 치워야 할 장애물로 보인다.

이쯤 되면 질문이 하나 떠오른다. 이게 정말 몇몇 범죄자들만의 이야기일까.

다시 한 번 떠올려 보자. 그들은 다른 별에서 온 사람들이 아니다. 팰런처럼 위험한 것을 타고나고도 따뜻한 사람으로 자란 경우가 있고, 반대로 평범하게 태어났지만 점점 차갑게 굳어 간 경우도 있다. 양쪽을 갈라놓은 것은 어디서, 어떤 환경에서 자랐느냐였다.

그러니 '미안할 이유를 모르는 사람'과 우리 사이의 거리도, 어쩌면 우리가 더 착하기 때문이 아니라 우리 주변에 아직 작은 온기가 남아 있기 때문일지 모른다.

성공을 향해 달리는 마음은 누구에게나 있다. 문제는 그 옆에, 같이 달리는 사람이 있다는 것을 느끼는 마음이 함께 있느냐는 것이다. 우리는 두 마음 중 어느 쪽을 먼저 잃고 있을까.

아직 온기가 다 식지 않은 자리에서, 이 질문은 물어볼 수 있다.

조직이라는 단어가 흔들릴 때

Tue, 21 Apr 2026 15:48:59 GMT

지난주, 한 팀의 두 사람이 비슷한 일을 각자의 AI에게 맡겼다. 한 명은 Claude로 경쟁사 리서치를 세 시간 만에 끝냈고, 다른 한 명은 Gemini로 같은 주제의 시장 자료를 정리했다. 두 결과물은 모두 훌륭했다. 문제는 그다음이었다. 한 사람이 파고든 논점과 다른 사람이 짚어낸 구조는, 서로의 화면 안에만 머물렀다. 팀 전체로 보면 아무것도 적재되지 않았다. 각자는 빨라졌는데, 팀은 그만큼 빨라지지 않았다.

이런 장면은 요즘 많은 조직에서 반복된다. AI는 개인을 도왔지만, 조직은 그 도움을 흡수하지 못한다. 왜 AI는 개인 수준에서 멈추는가. 이 질문을 파고들다 보면, 답은 기술 쪽에 있지 않다.

증폭되는 것은 개인이다

지금의 AI 인터페이스는 구조적으로 1인용이다. 챗봇은 나의 대화 히스토리 위에서 움직이고, IDE 플러그인은 내 편집기에 붙어 있으며, 검색은 나의 질의어에서 시작한다. 컨텍스트는 개인의 기억에 묶이고, 프롬프트는 개인의 언어로 쓰이며, 산출물은 개인의 채널로 흐른다. 이 구조가 뒤틀리기 전까지는, AI가 아무리 강해져도 남는 것은 "개인의 생산성"이다.

팀 안에서는 이상한 일이 벌어진다. 모두가 각자의 현미경을 들고 같은 샘플을 들여다본다. 각자의 현미경은 다른 각도로 맞춰져 있고, 각자만 볼 수 있는 디테일을 찾아낸다. 그런데 들여다본 것은 각자의 노트에만 남는다. 옆자리 사람이 무엇을 보았는지, 왜 그 각도로 돌려보았는지, 그 미세한 조정을 통해 무엇을 배웠는지, 공유되는 것은 거의 없다.

그래서 AI는 "생산성 도구"로 소비된다. 조직이 기대하는 "역량"으로는 쌓이지 않는다. 같은 크기의 팀이, 구성원 각자는 분명 똑똑해졌는데, 조직 단위로는 작년과 거의 같은 질문을 반복한다.

조직은 왜 이것을 올리지 못하는가

회사는 당연히 이 증폭을 조직 역량으로 끌어올리고 싶다. 공유된 지식, 학습된 판단, 재사용 가능한 노하우. 표현은 각자 다르지만 바라는 것은 하나다. 그러나 시도는 번번이 막힌다.

막히는 지점은 대체로 셋이다. 첫 번째는 데이터 접근의 경계다. 개인이 다룬 문서, 주고받은 대화, 검토한 자료 대부분이 조직 저장소로 되돌아오지 않는다. 기술적 이유보다 감정적 이유가 크다. 내 메모를 공용 공간에 올리면, 그 메모에 남은 거친 표현과 흐트러진 논리의 책임까지 나에게 남는다.

두 번째는 문제의 비반복성이다. 조직이 다루는 일은 정확히 반복되지 않는다. 지난 분기의 가격 인상 논의와 이번 분기의 가격 인상 논의는 이름만 같다. 그래서 템플릿은 대개 절반만 맞고, AI가 학습할 "정답 패턴"이 조직의 일 속에는 드물다.

세 번째가 가장 까다롭다. 암묵지다. 사람이 AI와 나눈 대화에는 프롬프트로 쓰이지 않은 판단 기준이 녹아 있다. "이 문단은 내보내지 않는다"는 결정, "여기서는 강하게 밀어붙인다"는 감각. 이런 것들은 대화 본문에 드러나지 않고, 사람의 머릿속에만 남아 있다.

이 지점에서 "RAG를 도입하면 됩니다" 식의 처방이 흔히 등장한다. 그러나 이 처방이 풀려는 문제의 단위 자체가 잘못 설정된 것이라면 어떨까.

그렇다면 조직이란 무엇이었는가

"조직이 AI를 못 올린다"는 문제에 부딪혔을 때, 먼저 의심해야 할 것은 도구가 아니라 조직이라는 단어의 해상도다. 그 단어는 AI 이전 시대에 정의됐다.

지금까지 조직은 대체로 "사람의 모음"으로 정의됐다. 사람이 들어오고 나가며, 그 사람들이 가진 능력과 경험의 합이 조직이었다. 그래서 HR은 자연스럽게 "사람을 관리하는 부서"였다. 채용은 사람을 들이는 일, 평가는 사람을 재는 일, 이탈은 사람을 잃는 일이었다.

그러나 일의 단위가 이미 개인-AI 쌍(pair)으로 내려가 있다면, 조직의 단위도 "사람"에서 벗어날 수 있다. 조직을 "판단의 축적체"로 다시 정의해 볼 수 있다는 말이다. 누가 있는가보다, 무엇이 학습되어 있는가가 앞선다.

합창단을 떠올려 보면 된다. 합창단은 단원 리스트가 아니라 악보로 정의된다. 단원은 바뀌지만 악보는 남고, 새 단원은 그 악보를 배우며 합창단의 일부가 된다. 조직도 "사람의 리스트"가 아니라 "그동안 쌓인 판단의 악보"로 정의될 수 있다.

이 정의 위에서 HR의 역할은 달라진다. 사람의 고용과 평가보다 앞서는 질문이 생긴다. 조직이 어떤 판단을 학습하고, 어떤 판단을 버리는가. 일종의 기억 큐레이션이다.

구체적으로 보자. 채용은 "이 사람이 들어오면 어떤 판단이 조직에 추가되는가"를 묻는 일이 된다. 평가는 "이 사람이 만든 자산이 조직의 악보에 편입되었는가"로 이동한다. 이탈은 "이 사람이 나갈 때 어떤 판단이 함께 빠져나가고, 어떤 판단이 조직에 남는가"를 묻는다. HR은 사람을 관리하는 부서에서, 판단을 쌓고 걸러내는 부서로 바뀐다.

이 전환은 거창한 제도 개편에서 시작되지 않는다. 두 사람이 각자의 AI로 같은 주제를 파고든 뒤, 지운 문장과 바꾼 질문의 이유를 서로에게 설명하는 작은 루틴에서 시작된다. 그 루틴을 통해 팀의 판단은 처음으로 개인의 머리 바깥에 기록된다. 흥미로운 것은, 앞으로 HR이 다룰 일의 많은 부분이 채용 공고의 표현이나 평가 양식의 항목이 아니라 이런 루틴의 설계라는 점이다. 조직이 매일 어떤 흔적을 남기는지, 어떤 대화를 공용 기억에 흡수시키고 어떤 대화를 개인에게 돌려보내는지. 사람을 고르는 일보다 기억을 설계하는 일이 먼저다.

흔들리는 것은 조직이라는 단어 자체다

AI를 어떻게 조직에 올릴까를 묻기 전에, 한 가지를 먼저 점검해 볼 만하다. 우리 팀이 지난 한 달간 AI와 나눈 대화 중, 팀의 자산으로 남은 것은 무엇인가. 아무것도 없다면, 그 AI는 팀의 것이었는가 개인의 것이었는가.

조직을 "사람의 조합"이 아니라 "판단의 조합"으로 한 번 그려보는 것도 도움이 된다. 그 그림 속에서 HR의 자리는 어디로 움직이는가. 그 자리가 지금 우리가 알고 있는 HR과 같은 곳이라면, 우리는 아직 조직이라는 단어가 흔들리기 전의 모습으로 조직을 그리고 있는 셈이다.

36.8%의 확률로 사랑하기

Sat, 18 Apr 2026 21:00:00 GMT

1960년 2월, 『사이언티픽 아메리칸』의 「Mathematical Games」 칼럼에 짧은 문제 하나가 실렸다. 마틴 가드너가 쓴 그 호의 부제는 어쩐지 불길했다. "결혼하기 전에 고려해야 할 것들에 관한 수학적 퍼즐."

문제 자체는 단순했다. 비서 한 명을 뽑는다고 치자. 후보는 100명. 한 명씩 차례로 면접을 보고, 면접이 끝나는 순간에 뽑을지 말지를 결정해야 한다. 한번 거절한 사람은 다시 부를 수 없다. 게다가 지원자의 절대적인 점수는 보이지 않는다. 지금까지 본 사람들 사이의 상대적 순위만 보인다. 이 조건에서 어떻게 해야 진짜 최고의 후보를 뽑을 수 있을까?

수학자들은 이 문제를 아주 좋아했다. 하도 좋아해서 이름이 여러 개 생겼다. 비서 문제(secretary problem), 결혼 문제(marriage problem), 술탄의 지참금 문제(sultan's dowry problem), 구골 게임(googol game). 같은 문제인데 상황만 바꿔놓은 것이다. 술탄은 왕비 후보를, 비서실장은 비서를, 그리고 아마 당신은… 오늘의 주제다.

놀랍게도 이 문제에는 정답이 있다. 그것도 매우 깔끔한, 외우기 쉬운 정답이. 그리고 이 정답은 꽤 오래전부터 은근히 유명해서, 데이팅 앱이 생기기 한참 전부터 수학자들이 결혼 상대를 고를 때 몰래 참고했다는 소문도 있다.

어디 한번 들여다보자.

37%에서 멈추라

최적 전략은 이렇다.

전체 후보의 처음 37%는 무조건 거절한다. 이 구간은 "탐색"이다. 이 사람이 아무리 좋아 보여도 넘긴다.
37%가 지나면, 지금까지 본 최고보다 나은 사람이 나타나는 순간 그와 결정한다.

왜 하필 37%일까. 수학적 유도는 복잡하지만 결과는 단순하다. 전체의 1/e 지점에서 멈추는 게 최적이고, 1/e ≈ 0.368, 반올림하면 37%다. e는 자연로그의 밑, 값은 2.71828…. 파이만큼 유명하진 않지만 파이만큼 이상한 상수다. 그래서 이 전략은 "37% 규칙"이라는 별명을 얻었다.

그리고 이 전략이 1등을 뽑을 확률은 1/e ≈ 36.8%다. 달리 말하면, 이 수학이 추천하는 최적의 전략을 완벽히 따라도 열 번 중 여섯 번은 1등을 놓친다. 이게 "공식이 있다"는 말의 함정 중 하나다. 있긴 있는데, 60%는 실패한다.

숫자를 조금 만져보자. 브라이언 크리스천과 톰 그리피스는 『알고리즘, 인생을 계산하다』에서 이 공식을 데이팅 기간에 대입한다. 18살부터 40살까지 22년 동안 누군가를 만나보기로 정했다고 하자. 22년의 37%는 약 8년. 즉, 26살이 되기 전까지는 누구를 만나든 "이 사람이다" 싶어도 일단 거절하라. 그리고 26살이 넘어가면, 지금까지 만난 역대 최고를 기억해두고, 그보다 나은 사람이 나타나는 즉시 결혼하라.

만약 기간이 아니라 "만날 사람 수"로 계산하면 어떨까. 평생 열 명쯤 진지하게 만난다고 치면, 앞의 서너 명은 연습용이고, 네 번째부터는 누구라도 이전보다 나으면 결혼하라는 얘기가 된다.

써놓고 보니 굉장히 낭만적이지 않은 문장이다. 하지만 수학은 원래 낭만에 관심이 없다. 37% 규칙은 사랑을 이야기하지 않는다. 이 공식이 말하는 건 "어떻게 하면 최고를 놓칠 확률을 줄일 수 있는가"에 가깝다. 그리고 방금 봤듯이, 줄여도 60%는 놓친다. 이 사실은 계속 기억해둘 가치가 있다.

그런데 그 사람이 이미 고점이었다면

이 공식의 가장 잔인한 부분은 여기다.

37% 규칙이 실패하는 시나리오는 크게 두 가지다.

첫 번째. 탐색 구간(처음 37%) 안에 이미 인생 최고가 있었다. 그 사람은 "기준"을 세우는 데만 쓰이고 지나간다. 이후에 등장하는 사람들은 전부 그보다 못한 사람들이니, 규칙을 지키면 아무도 고를 수 없다. 마지막까지 버티다가 전략이 무너져버린다.

두 번째. 관찰 구간의 최고가 너무 훌륭해서 이후 아무도 못 이긴다. 결과적으로 마지막 사람까지 끌려가고, 별 감흥 없는 그 사람과 결정하게 된다.

첫 번째 시나리오가 발생할 확률은 정확히 37%다. 1등이 전체 후보 중 어느 위치에 있을지는 대체로 균일분포로 본다. 그러니 앞쪽 37% 안에 있을 확률이 37%. 바꿔 말하면, 이 공식을 완벽히 따르는 사람의 세 명 중 한 명은 "이 사람이다" 싶었던 사람을 거절해놓고 평생 그보다 나은 사람을 만나지 못한다.

이상한 일이다. 수학자들이 "최적"이라고 부르는 전략인데, 실행한 사람의 3분의 1은 자기 인생 최고의 사람을 직접 흘려보냈다는 사실조차 모르고 살아간다. 그게 수학적으로 "정답"이다.

이 부분이 사랑에 대한 수학을 진지하게 받아들일 수 없게 만드는 진짜 이유 같다. 수학은 "가장 높은 확률로 1등을 뽑는 전략"을 알려주지, "이 사람이 지금 내가 만날 수 있는 가장 좋은 사람인가"에는 답하지 않는다. 37%가 지난 뒤 "어, 이 정도면 전보다 낫네" 싶어서 멈춘 바로 그 지점이 사실은 당신 인생의 고점일 수도 있고, 동시에 당신이 놓친 첫 37% 어딘가에 그보다 훨씬 높은 봉우리가 있었을 수도 있다.

그리고 결정적으로, 당신은 그걸 영영 모른다. 탐색이 끝나면 그 사람들은 대부분 당신 삶에서 사라지니까.

재미있는 역설이 하나 있다. 탐색 구간에서 최고를 세워두고 활용 구간에 진입한 뒤, 그 기준을 뛰어넘는 사람이 "드디어" 나타났다고 하자. 수학의 관점에서 이 사람은 특별하다. 왜냐하면 관찰된 전체 후보의 1등이 (지금까지는) 이 사람이기 때문이다. 그런데 이때 "그래도 더 나은 사람이 있을 수 있지 않나?"라는 생각이 든다면, 사실 그 생각은 이미 37% 규칙이 거부하라고 경고한 바로 그 유혹이다.

규칙은 이렇게 말한다. "탐색은 끝났다. 당신이 지금 보고 있는 사람은 지금까지의 전부를 이긴 사람이다. 더 기다리는 건 원리적으로 이득일 수도 있지만, 통계적으로 당신은 지금보다 더 나은 사람을 만나기보다 아무도 만나지 못하고 시간을 태울 가능성이 더 크다."

그래서 "이 사람보다 더 나은 사람이 있을 수도 있다"는 생각이 들기 시작하면, 수학적으로는 오히려 신호를 거꾸로 읽고 있을 가능성이 크다. 37%가 지난 시점에 과거 최고를 이긴 사람이 나왔다는 건, 확률적으로 이 사람이 앞으로 만날 사람들 중에서도 상위에 있을 공산이 크다는 뜻이다. "더 나은 사람"을 기다리는 시간이 길어질수록 당신은 63%의 중간 어딘가를 낭비하고 있을지 모른다.

물론, 그래도 남은 63%에서 더 나은 사람이 나타날 확률은 여전히 있다. 얼마나? 직관과 달리 그리 높지 않다. 그리고 이 확률이 얼마든, 여기엔 한 가지 슬픈 조항이 덧붙는다. 기다리는 동안 그 사람은 기다려주지 않는다는 것.

수학자들도 이 문제로 장난쳤다

공식은 공식이고, 현실은 현실이다. 수학자들도 이 사실을 모르지 않았다. 그래서 그들은 결혼 문제에 대해 꽤 오랫동안 농담 같은 장난을 쳐왔다.

1611년, 독일의 천문학자 요하네스 케플러는 첫 아내를 잃고 두 번째 아내를 구하고 있었다. 케플러는 꼼꼼한 사람이었다. 어찌나 꼼꼼했는지, 2년에 걸쳐 11명의 후보 여성을 만났고, 각각의 장단점을 세밀하게 정리한 편지와 일지를 남겼다. 행성의 궤도를 타원으로 정리한 그 남자답게, 결혼 후보들도 정량화하려 했던 셈이다.

수학사학자 알렉스 벨로스가 정리한 바에 따르면, 케플러는 4번째 후보에게 강하게 끌렸지만 친구들의 만류로 넘어갔고, 이후 5번부터 11번까지 계속 비교를 이어갔다. 결국 그가 선택한 사람은 5번째 후보, 수잔나 로이팅거였다. 결혼 생활은 꽤 행복했다고 기록돼 있다. 케플러는 최적 멈춤 이론을 알지 못했다. 그의 시대에 그런 건 없었다. 그런데 그가 한 일을 37% 규칙에 대입해보면 기묘하게 맞아떨어진다. 11명 중 37%는 약 4명. 탐색 구간의 최고(4번째)를 기준점으로 두고, 5번째에서 그보다 나은 사람이 나왔을 때 멈춘 셈이다.

이 패턴은 순전한 우연일 수도, 케플러가 직관적으로 도달한 일종의 자가 발견일 수도 있다. 어느 쪽이든, 400년 뒤의 수학자들은 이 일지를 보고 기립박수를 쳤다.

훨씬 최근에는 더 뻔뻔한 장난도 있었다. 2010년, 영국 워릭대학의 경제학자 피터 백커스는 "나는 왜 여자친구가 없는가(Why I Don't Have a Girlfriend)"라는 장난 논문을 썼다. 백커스가 사용한 도구는 드레이크 방정식이었다. 드레이크 방정식은 원래 우리 은하에 존재할 외계 문명의 수를 추정하기 위해 천문학자 프랭크 드레이크가 만든 수식이다. 별의 탄생 속도, 행성을 가진 별의 비율, 생명이 발생할 비율, 지적 생명으로 진화할 비율, 교신 가능한 문명이 될 비율, 문명 존속 시간. 여섯 개의 수를 곱해 외계 문명의 수를 얻어내는 간결한 방정식이다.

백커스는 이 수식의 변수를 하나씩 바꿨다. 별의 탄생 속도 대신 영국의 인구 증가율, 행성을 가진 별의 비율 대신 여성의 비율, 생명이 발생할 비율 대신 런던에 거주할 비율… 전부 넣고 계산해보니, 영국에서 그의 이상형일 가능성이 있는 여성은 약 26명이었다. 그 시점에 감지 가능한 외계 문명이 약 10개 정도로 추정되고 있었으니, 결론은 이랬다: 외계인을 만날 확률보다 이상형을 만날 확률이 2.6배 높다. 위로인지 비관인지 헷갈리는 결론이다.

드레이크 방정식도 37% 규칙도, 어떤 의미에서는 같은 일을 하고 있다. 통제할 수 없을 만큼 복잡한 현실을 몇 개의 숫자로 축약해놓고, "이 숫자만 맞추면 답이 나온다"고 주장한다. 그게 사실일 리 없다는 걸 모두가 안다. 그런데도 계산하고, 발표하고, 읽는다. 이 안에 뭔가가 있다. 불완전한 수식이라도, 무작위한 삶에 격자 하나를 올려놓으면 최소한 어디가 어디인지 가리킬 수는 있다. 정답이 아니라 좌표계로서의 수학이다.

수학자들은 이 문제를 가지고 수십 년간 변형을 만들어왔다. 몇 가지만 추려보자.

완전 정보 변형(full-information problem): 후보의 절대 점수를 볼 수 있다면? 이 경우 성공 확률은 37%에서 58% 이상으로 뛴다. 상대 순위만 보던 원래 문제가 얼마나 정보 빈곤한 설정이었는지 드러나는 대목이다.
되돌아가기 허용(recall allowed): 이미 거절한 사람을 다시 부를 수 있으면, 당연히 더 나은 전략이 존재한다. 확률은 올라가고 공식은 덜 엄격해진다. 현실의 재회나 뒤늦은 고백이 여기 해당된다고 볼 수 있다.
2등 뽑기(postdoc problem): 놀랍게도 2등을 뽑는 전략은 1등을 뽑는 전략과 다르다. 탐색 구간이 37%가 아니라 더 짧다. "최고는 부담스러우니 2등이면 된다"는 사람에게 수학은 다른 답을 준다.
매칭 시장(Gale-Shapley): 선택하는 쪽이 한쪽이 아니라 양쪽이라면? 수학자 로이드 섀플리와 데이비드 게일은 1962년 "안정 매칭 알고리즘"을 발표했다. 모든 사람이 서로에게 순위를 매기고, 제안하고, 거절하고, 받아들이는 이 메커니즘은 2012년 노벨 경제학상을 받았다. 결혼 문제에 "상대방도 나를 고른다"는 조항을 추가한 순간, 수학은 훨씬 재밌어졌고 동시에 훨씬 현실에 가까워졌다.

이 모든 변형이 말해주는 것은 하나다. 원래의 37% 규칙은 아주 특수한 설정에서만 성립한다. 그리고 그 설정이 현실과 얼마나 닮았는지는… 음, 그건 각자의 삶에 달렸다. 대체로 덜 닮았고, 가끔 예상보다 닮았다.

멈추는 일에 대하여

수학을 한쪽으로 치워놓고 보면, 37% 규칙이 하는 이야기는 사실 아주 오래된 질문이다. 언제 충분히 알았다고 말할 수 있는가.

1978년, 경제학자 허버트 사이먼은 두 종류의 사람을 구분했다. 극대화자(maximizer)와 만족자(satisficer). 극대화자는 모든 선택지를 다 검토하고 그중 최고를 고르려고 한다. 만족자는 일정 기준을 세운 뒤, 그 기준을 넘는 첫 선택지에서 멈춘다. 사이먼은 극대화자 전략이 수학적으로는 가장 좋은 결과를 낼 것 같지만, 현실에선 거의 불가능하다고 지적했다. 후보가 유한하고 비교 비용이 0일 때에만 성립하는 전략이기 때문이다. 현실의 후보는 시간이 지나면 사라지고, 비교하는 데는 시간과 감정이 든다.

2002년, 심리학자 배리 슈워츠는 이 아이디어를 "선택의 역설(paradox of choice)"로 확장했다. 그의 연구에 따르면, 극대화자 성향이 강한 사람일수록 결정을 내린 뒤에도 더 후회하고 더 불행해진다. 선택지를 오래 비교할수록 "더 나은 게 있었을지도 모른다"는 그림자가 길게 따라붙는다. 반대로 만족자는 기준을 넘는 첫 순간에 멈추고, 그 뒤의 삶에 에너지를 쓴다.

37% 규칙의 진짜 미덕은 이 지점에서 드러난다. 이 규칙은 겉으로는 극대화자의 문법으로 쓰여 있다. "1등을 뽑을 확률을 최대화하라." 그런데 막상 따르면 60%는 실패하고, 그 실패의 상당 부분은 "이미 최고를 놓쳤다"는 방식이다. 수학적 극대화조차 만족자의 결론으로 귀결된다. "더 나은 게 있었을지도 모른다"는 건, 모든 선택이 항상 짊어지는 조건이지, 어떤 특정 선택의 결함이 아니다.

이 관점은 사랑뿐 아니라 많은 일에 적용된다. 어느 회사에서 멈출지, 어느 직업에서 멈출지, 어느 도시에서 멈출지, 어느 책상에서 멈출지. 계속 비교하고 싶은 유혹은 강하지만, 수학이 보여주는 건 비교의 수익률이 생각보다 빨리 떨어진다는 사실이다. 그리고 멈춘 자리가 최고가 아닐 확률은 어느 전략을 써도 대개 50%를 넘는다. "최적"을 포기해도 잃을 것은 대부분 착시다.

그러니 "이 사람보다 더 나은 사람이 있지 않을까"라는 질문이 찾아오면, 그 질문 자체가 답이 아닐 수도 있다. 37% 규칙이 옳다면, 그 질문에 매달리는 시간의 대부분은 이미 지나간 탐색 구간을 뒤돌아보거나, 63%의 남은 시간을 통계적으로 유의미하지 않은 비교에 쓰는 일에 가깝다. 어쩌면 질문을 이렇게 바꾸는 편이 더 정확할지도 모른다. 이 사람이 내 기준을 넘는가.

수학은 여기까지다. 그 다음은 사람의 몫이다. 케플러는 11명의 후보를 세심하게 비교한 뒤 다섯 번째에서 멈추었고, 그게 행복한 결혼으로 이어졌다고 전한다. 피터 백커스는 자기 이상형이 26명이라는 계산을 공개한 뒤 몇 년 뒤 실제로 결혼했다. 그들의 결정이 수학이 말한 "최적"이었는지, 아니었는지는 아무도 모른다. 아마 본인들도.

36.8%는 사랑에 빠질 확률이라기보다, 멈춰도 괜찮다고 수학이 슬쩍 건네주는 승인에 가깝다. 그 숫자가 완벽하지 않다는 걸 알면서도, 그리고 바로 그 불완전함 때문에, 수학이 끝난 자리에서부터 사람이 시작될 여지가 남는다.

떠날 수 있어서 떠난다

Sat, 18 Apr 2026 12:00:00 GMT

오늘 현충원에 다녀왔다. 사람이 많았고, 마침 군악대 행사가 있어서 한참 구경했다. 연주가 끝나고 근처 카페에 들러 커피를 한 잔 시켰다. 자리에 앉는 동안 옆 테이블에서 한 문장이 잠깐 귀에 걸렸다.

"왜 다들 성공하면 해외로 나가서 살고 싶어할까요."

그게 전부였다. 이어진 대화는 듣지 못했고, 굳이 들으려 하지도 않았다. 그런데 그 한 문장이 카페를 나와 걷는 내내 머릿속에 남았다. 조금 전까지 걸었던 비석들 사이의 공기와 이 질문이 묘한 각도로 겹쳤다. 비석 앞에서는 한 나라와 한 개인의 관계가 가장 무거운 형태로 떠올랐고, 카페에서는 그 관계를 다시 설계하려는 사람들의 질문이 스쳐 있었다. 무게가 전혀 다른 두 이야기였지만, 공통된 축은 하나였다. 여기에 머물 것인가, 여기를 떠날 것인가. 그리고 떠나고 싶어 하는 마음은 도대체 무엇으로 이루어져 있는가.

저렴함이라는 사회 계약

한국은 살기 좋은 나라라고들 한다. 이 말은 대체로 "물가가 싸다"는 감각과 묶여 있다. 그런데 통계를 들춰 보면 이야기가 조금 꼬인다. 한국의 의식주 물가는 OECD 평균보다 약 55% 높고, 식료품만 따로 보면 평균 대비 47% 높다(시사저널, 민들레). 사과, 돼지고기, 티셔츠, 남자 정장, 골프장 이용료 같은 개별 품목은 OECD 평균의 두 배를 넘기도 한다. 사실 "물가가 싼 나라"라는 말은, 엄밀히 말하면 틀렸다.

그럼에도 한국이 살기 좋게 느껴지는 이유는 따로 있다. 절대 물가가 아니라 서비스와 의료와 대중교통과 외식 배달 같은, 일상을 굴리는 가처분 영역의 가성비다. 원하는 시간에 택시를 부를 수 있고, 감기에 걸리면 싼값에 진료를 받을 수 있고, 야식이 30분 안에 현관까지 도착한다. 생필품은 비싸도, 시간을 사는 값이 싸다. 이 조합이 한국 사회의 숨은 계약 조건이다.

그리고 이 계약 위에 또 하나의 구조가 얹혀 있다. 근로소득자 세 명 중 한 명은 결정세액이 0원이다. 2024년 국세청 자료 기준으로 전체 근로소득자 약 2,054만 명 중 697만 명, 비율로 33.9%가 면세자다. 반대편에서는 상위 1%의 근로소득자가 전체 근로소득세의 31.2%를 부담한다(서울신문). 일본의 면세자 비율은 15.1%, 호주는 15.5%다. 한국은 생활비 수준이 세계 최상위권인 동시에, 세부담이 소수에 극단적으로 집중된 이례적인 나라다.

닭이 먼저냐 달걀이 먼저냐 하는 질문이 여기서 등장한다. 생활의 가성비가 좋아서 대중이 적은 세금으로도 살아갈 수 있는 것인가, 아니면 소수에게 집중된 세부담이 그 가성비를 떠받치고 있는 것인가. 방향이 정반대인 두 인과가 한 구조 안에 얽혀 있다. 어느 쪽이든, 한국이 살기 좋다는 말의 상당 부분은 이 얇은 균형에 기대어 있다.

저렴함이 가치가 되지 않는 사람들

그렇다면 이미 저렴함이 필요 없는 사람에게 한국은 무엇을 줄 수 있는가.

상위 0.3%에게 물가는 사라진 변수다. 변수가 사라지면 다른 변수가 도드라진다. 교육의 질, 공기의 질, 의료 접근성, 거주지의 쾌적함, 남들의 시선에서 자유로울 권리. 한국의 일상이 주는 가성비가 이 사람들에게는 기본값에 불과하다. 기본값이 된 것은 더 이상 감사의 대상이 아니다. 비교의 무게중심이 '저렴함'에서 '그 외'로 옮겨 간다.

거기에 한 가지 감정이 덧붙는다. 자신이 내는 세금의 상당 부분이 자신의 삶에 직접적으로 돌아오지 않는다는 감각이다. 내가 아니라 다른 누군가의 복지를 위해 큰 몫을 내고 있다는 체감 — 그것이 사실인가 아닌가를 떠나, 적어도 그들의 자리에서는 그렇게 느껴진다. 이 구조가 불공정하다는 뜻이 아니다. 다만 이 구조 속에 오래 서 있을수록, 왜 내가 여기서 이 비율을 감당해야 하는가라는 질문이 자연스럽게 자라난다.

같은 돈, 다른 삶

창업자들 사이에서 꽤 자주 돌아다니는 말이 있다. 같은 돈을 쓰더라도 훨씬 풍요롭고 안락한 라이프스타일을 누릴 수 있는 나라가 많다는 이야기. 이 말이 냉정한 이유는 거의 틀리지 않기 때문이다. 같은 연봉으로 동남아에서는 집안일과 육아를 타인에게 맡길 수 있고, 유럽 일부 도시에서는 걷기 좋은 동네와 공원과 깨끗한 공기가 기본값으로 제공되고, 북미 도시에서는 상대적으로 큰 주거 공간이 가능하다. 같은 숫자가 다른 모양의 삶을 만든다.

여기에 한 가지가 더 얹힌다. 한국에서 창업으로 고용을 만들고 부를 축적할수록 법적·행정적 부담이 누적되는 구조가 있다. 주 52시간, 노무, 세무, 공정거래, 상속. 각 규제의 취지는 정당하다. 그러나 한 사람에게 동시에 걸렸을 때의 총합은 체감 비용이 된다. 정책이 기업인을 악인으로 상정한다기보다, 정책의 기본 가정이 '보호받아야 할 사람'과 '규제받아야 할 사람'으로 나뉘어 있다는 말이 더 정확하다. 규제받는 쪽에 놓인 사람은 그 가정에서 벗어나고 싶어진다. 떠날 수 있는 선택지가 생기는 순간, 이 무게가 떠남의 방향으로 기울기 시작한다.

100억의 출구, 1000억의 눌러앉음

한 가지 흥미로운 관찰이 있다. 100억에서 200억 사이 구간에서 해외 이주가 많고, 그 이상이면 오히려 한국에 눌러앉는다는 이야기. 얼핏 직관에 반한다. 돈이 더 많을수록 자유로워야 할 텐데 왜 눌러앉는가.

답은 상속세다. 한국의 상속세 명목 최고세율은 50%, 최대주주 할증까지 포함하면 60%에 이른다. OECD 회원국 중 최고 수준이다. 직계비속 상속에 과세하는 OECD 18개국의 평균 최고세율은 27.1%로, 한국의 절반에도 못 미친다. 상속세가 아예 없는 OECD 회원국도 15개국에 이른다(한국경제).

이 지점에서 해외 사례가 내내 단골처럼 인용된다. 싱가포르는 2008년 상속세를 폐지했다. 당시 재무부의 논리는 단순했다. "세수 기여도는 낮은데 고액자산가에게만 영향을 미친다." 자산가 유입을 촉진한 결과, 폐지 5년 만에 인구가 10% 늘었다(한국경제).

더 상징적인 사례는 스웨덴이다. 한때 유럽에서 가장 강력한 분배 국가였던 스웨덴은 2004년 여야 합의로 상속세를 폐지했다. 전 세계 분배주의자들에게 충격적인 사건이었다. 계기는 자국 기업들의 이탈이었다. 이케아 창업자 잉그바르 캄프라드는 상속세를 견디지 못하고 스위스로 국적을 옮겼고, 이케아 본사는 1982년 네덜란드로 이전했다. 스웨덴 정부가 분석해보니 상속세 세수는 전체의 0.3~2%에 불과한 반면, 떠난 기업들이 내던 법인세와 근로자의 소득세가 훨씬 컸다. 분배를 위해 상속세를 유지할수록 분배의 원천이 빠져나가는 역설이었다(머니투데이, 한국경제 2020).

이 사례들은 "부를 분배하려면 상속세를 높게 유지해야 한다"는 직관과 반대 방향으로 움직인다. 세율이 어떤 임계점을 넘으면, 부자는 세금을 더 내는 것이 아니라 국경을 넘는다. 그리고 빠져나간 자리에는 분배할 원천 자체가 남지 않는 진공이 생긴다.

다시 한국의 계산으로 돌아오면, 결정을 가르는 것은 자산의 절대량이라기보다 자산이 무엇으로 이루어져 있느냐다. 100억에서 200억대 자산가의 상당수는 현금성 자산의 비중이 높고, 이주 후에도 자산의 형태가 크게 망가지지 않는다. 이 구간에서는 "떠나는 비용"이 감당 가능한 수준에 머문다. 반면 자산의 핵심이 국내 기업의 경영 지분에 묶여 있으면 계산이 달라진다. 2018년 도입된 출국세, 가족 기업의 지배 구조, 이사회와 주주 간 계약 같은 실무적 매듭이 이주 비용을 크게 키운다. 자산 규모가 커지면서 지분·경영 비중도 함께 커지는 경우, 역설적으로 이주의 문턱이 더 높아지는 지점이 생긴다.

물론 이 경향은 절대 법칙이 아니다. 이케아 창업자가 세계적 거부임에도 스위스로 떠났던 것처럼, 결국은 개별 자산의 성격과 각자의 계산이 결정을 만든다. 다만 한국 시장 안에서 대략적으로 관찰되는 경향은 이렇다 — 돈의 절대량보다 떠나는 비용의 상대적 크기가 결정을 바꾼다. 많은 결정이 그렇다. 옳고 그름이 아니라, 각자가 감당 가능한 범위에서의 최적화다.

규제는 선택지 없는 사람에게 먼저 닿는다

업계에서 꽤 자주 나오는 말이 하나 있다. "부자를 겨냥한 규제를 만들면 부자는 빠져나가고, 남는 건 중간 층이 부담하는 구조다." 이 말을 그대로 받아들일 필요는 없지만, 조심스럽게 풀어볼 필요는 있다. 규제가 부자에게 쓸모없다는 뜻이 아니다. 자산을 해외로 재배치하거나 교육과 거주지를 옮길 수 있는 사람에게는 규제의 구속력이 상대적으로 약하다는 관찰이다.

해외 송금 자체는 국내 거주자에게 결코 간단한 절차가 아니다. 고액 송금에는 한도와 사유 소명과 신고 의무가 뒤따른다. 그러나 이주라는 구조적 경로를 택하면 이야기가 달라진다. 이민 단계에서의 자산 이동은 제도가 허용하는 경로이고, 거주지가 바뀐 뒤에는 과세 관할 자체가 달라진다. 한국 부유층의 일부는 이미 자산의 상당 부분을 해외에 분산하고, 자녀를 유학 보내고, 영주권이나 시민권을 미리 확보해 둔다. 이들에게 한국의 과세 체계는 여러 시나리오 중 하나가 된다.

반면 자산이 국내 부동산과 근로소득에 묶여 있는 사람은 규제와 과세를 그대로 맞는다. 의도된 대상과 실제 부담자가 어긋나는 이 역설은 규모가 큰 규제일수록 종종 나타난다.

이 구조를 비판하려고 쓰는 것이 아니다. 다만 떠남이라는 선택지가 있는 사람과 없는 사람은 같은 사회를 전혀 다르게 경험한다는 점만 기록해두고 싶다. 그리고 창업자가 대체로 전자에 속한다는 점을 생각하면, 왜 그들의 이주가 구조적으로 쉬워 보이는지 조금 더 분명해진다.

좁고 빠르게 큰 사회

떠남의 서사를 이야기하다 보면 쉽게 잊는 사실이 하나 있다. 한국이 부자가 된 지는 그리 오래되지 않았다는 점이다.

1960년대 초반 한국의 1인당 GDP는 100달러 안팎 수준이었다. 2024년 기준으로는 3만 6천 달러를 넘겼고, 사상 처음으로 일본의 1인당 GDP를 추월했다(Trading Economics). 60여 년 사이 300배 이상 늘어난 숫자다. 같은 세대 안에서 부모는 보릿고개를 겪었고, 자식은 아이폰을 들고 유학을 간다. 이 속도는 기적에 가깝고, 기적은 대체로 성장통을 동반한다.

짧은 시간에 부의 분포가 극단으로 벌어졌다. 같은 세대 안에서 누구는 부모에게 집을 물려받고, 누구는 월세부터 시작한다. 누구는 1990년대의 저평가된 부동산을 쥐었고, 누구는 2020년대의 고평가된 부동산 앞에서 무력해졌다. 자산 가격이 근로 소득보다 훨씬 빠르게 뛰는 국면에서, 근로 소득만 가지고 있는 사람의 박탈감은 구조적으로 피할 수 없다. 이것은 누구의 잘못이라기보다, 급하게 자란 나라의 성장통에 가깝다.

게다가 한국은 좁다. 인구 5천만, 수도권에 절반 이상이 모여 있는 나라다. 좁은 공간에서 비교가 날카롭게 작동한다. 옆집이 어느 아파트에 사는지, 자식을 어느 학교에 보내는지, 동창 중 누가 어디에 자리를 잡았는지가 선명하게 보인다. 누군가의 성공이 자주 나의 상대적 실패로 번역된다. 좁고, 빠르게, 밀도 있게 비교되는 사회에서는 성공조차 피로가 된다.

떠남이 매력적으로 보이는 이유 중 하나는 이 중력장에서 벗어나는 것이다. 물리적으로 멀어지면 비교의 밀도도 얇아진다. 아무도 내가 어떤 아파트에 살았는지, 어느 회사 대표였는지, 어느 학교를 다녔는지 모른다. 평가가 사라지는 자리에는 새로운 종류의 자유가 들어선다.

안 하는 것과 못 하는 것 사이

여기서 관점을 한 번 돌려보고 싶다. 사람들이 해외 이주를 놓고 하는 대화는 대체로 "왜 떠나는가"에 집중된다. 세금이 무거워서, 교육이 답답해서, 공기가 나빠서. 하지만 더 흥미로운 질문은 "왜 대부분의 사람은 떠나지 않는가"다.

떠나지 않는 것과 떠나지 못하는 것은 다르다. 전자는 선택이고 후자는 조건이다. 그런데 일상 언어에서 두 단어는 자주 뒤섞인다. 많은 사람은 자기가 안 하는 것처럼 말하지만, 실제로는 못하고 있다. 그리고 대부분의 인간 행동은 같은 궤적을 그린다. 못하다가, 못하다가, 할 수 있게 되니까 비로소 한다. 해외 이주, 이직, 창업, 결혼, 이혼, 독립, 관계의 끝. 욕망의 기본 작동 원리는 단순하다. 가능성이 생겨야 실행이 따라온다.

욕망이 없어서 안 하는 것이 아니다. 욕망은 대체로 누구에게나 있다. 이루고 싶고, 달라지고 싶고, 자유롭고 싶다. 다만 그것을 실행에 옮기는 데에는 가능성의 문턱이 필요하고, 그 문턱은 우리가 생각하는 것보다 훨씬 높은 곳에 있다.

'못 한다'가 '안 한다'로 바뀐다

나이가 들수록 자산, 가족, 경력, 평판 같은 고정값이 쌓인다. 고정값이 쌓이면 불확실성의 비용이 커진다. 같은 결정이라도 스무 살일 때와 마흔 살일 때의 무게가 다르다. 마흔에 회사를 그만두고 해외로 간다는 결정에는, 스무 살에 배낭 하나 메고 떠나는 것과는 비교할 수 없는 고정값의 재배치가 뒤따른다.

그래서 우리는 번역을 시작한다. "하고 싶은데 못 한다"가 "원래 내 취향이 아니다"로, "지금은 때가 아니다"로, "현실적으로 어렵다"로, "나이 먹어서 못 한다"로 바뀐다. 이 번역은 대개 무의식적이다. 자기 자신도 속는다. 속아야만 마음이 편하다.

'안 한다'는 말은 종종 '못 한다'의 완곡한 표현이다. 자존감을 지키기 위한 언어의 완충재다. 그러나 완충재 아래에는 실제로 가능성의 문턱에 가 닿지 못한 채 멈춰선 욕망이 있다. 이 사실을 알아차리는 것이 중요한 이유는, 언젠가 문턱이 낮아지는 순간을 놓치지 않기 위해서다.

창업자에게 이주가 쉬운 이유

창업자는 이미 불확실성의 가격을 치러본 사람이다. 폐업, 자본 잠식, 투자자의 외면, 팀의 이탈, 제품의 실패. 최악의 시나리오를 머리로가 아니라 몸으로 겪은 사람이다. 겪어보면 안다. 최악도 견딜 수 있다는 것을, 그리고 대부분의 불확실성이 예상만큼 치명적이지 않다는 것을.

이 학습은 이주 결정에서 특별한 방식으로 작동한다. 보통 사람에게 "떠나서 적응 못 하면 어쩌지"라는 질문은 치명적인 공포다. 그러나 이미 여러 번 망해봤던 사람에게는 그 공포의 크기가 다르다. 비교 대상이 있다. 적응 못 하는 정도는 회사 망한 정도에 비하면 가볍다. 이미 치러본 대가 앞에서는 새 대가가 덜 무겁게 느껴진다.

여기에 자본까지 쌓였다면 숫자는 더 단순해진다. 실패해도 안전하다는 감각. 돌아올 수 있다는 감각. 그것이 이주를 '결심'이 아니라 '선택지 중 하나'로 만든다. 떠나는 사람들이 특별히 대담한 것은 아닐지도 모른다. 같은 결정 앞에 섰을 때 각자가 느끼는 불확실성의 크기가 다를 뿐이다. 대담함의 차이가 아니라, 저마다 쌓아온 비용 구조의 차이다.

리셋이라는 매력

떠남의 이유를 세금과 교육과 공기와 의료로만 설명하면, 설명되지 않는 큰 부분이 남는다. 그것은 관계다.

누적된 관계에는 무게가 있다. 10년, 20년 쌓인 인연 안에는 고마움과 빚과 기대와 역할이 한데 얽혀 있다. 그 인연들이 귀중한 만큼, 가끔은 그 총합이 버겁게 느껴지는 순간이 있다. 지난 시간이 나를 규정한 만큼, 그 규정에서 벗어나 다른 모양의 삶을 살아보고 싶어지는 때가 있다. 꼭 한국이 싫어서가 아니라, 지금까지의 나 자신에게서 잠시 쉬고 싶은 것일지도 모른다.

아무도 나를 모르는 곳에서 제로부터 시작하는 삶. 지금부터 다시 만들어지는 관계와 환경. 이 상상이 꽤 매력적으로 다가오는 시기가 사람에게 있다. 해외 이주는 이 매력에 가장 가까운 답안 중 하나다. 국경을 넘으면 물리적 거리만 벌어지는 것이 아니다. 지금까지 나를 규정해 왔던 호칭과 역할과 기대와 평판이 한꺼번에 초기화된다. 누구의 선배도 아니고, 누구의 친구도 아니고, 누구 회사 대표도 아닌 한 사람으로 다시 시작한다. 어떤 사람에게는 이 초기화가 공포지만, 어떤 사람에게는 해방이다.

짐작컨대 해외로 떠난 많은 사람들이 실제로 떠난 이유는 세금도, 교육도, 공기도 아니었을지 모른다. 그저 더는 누군가의 무엇이 아닌 상태로 살아보고 싶었던 것뿐인지도 모른다. 이 이유는 표면적으로 말하기 어렵고, 그래서 세금과 교육과 공기가 대신 자리를 차지한다.

양쪽이 모두 이해될 때

그래서 떠나는 사람 편인가, 남는 사람 편인가. 어느 쪽도 아니다. 양쪽 모두 이해된다.

징벌적이라 불리는 세금제도조차도 이해할 수 있는 자리가 있다. 그 누진적 구조가 없었다면 지금의 가성비 사회는 성립하지 않는다. 국밥 한 그릇이 삼만 원이 되는 나라에서 지금 한국의 일상은 운영되지 않는다. 상위 소수가 전체 세금의 상당 부분을 떠맡는 구조는 얼핏 불공평해 보이지만, 동시에 그것이 이 사회를 떠받치는 숨은 기둥이기도 하다. 그 기둥을 두드리는 사람은 그만한 이유가 있고, 기둥이 싫어서 떠나는 사람에게도 그만한 이유가 있다.

한쪽에서는 "왜 성공한 사람을 잠재적 악인 취급하느냐"고 묻고, 다른 한쪽에서는 "가진 사람이 더 많이 내는 것이 당연하다"고 받는다. 둘 다 틀리지 않다. 이 사회는 두 감각 사이의 미묘한 균형 위에 서 있고, 균형이 한쪽으로 크게 기울 때마다 누군가는 불편해진다. 불편해진 사람에게는 두 가지 선택지가 있다. 안에서 바꾸려 하거나, 밖으로 나가거나. 어느 쪽이든 합리적이다.

나는 이 문제의 전문가가 아니다. 세제 설계도, 이민 정책도, 거시 경제의 균형점도 전공이 아니다. 전문가들이 나보다 훨씬 더 깊이 고민해줄 것이라 믿고, 한 사람의 시민으로서 감시하는 정도의 역할만 감당한다. 다만 관찰은 할 수 있다. 사람들이 어떤 자리에서 어떤 선택을 하는지, 무엇이 그 선택을 가능하게 만드는지, 누구에게는 왜 그 선택이 아직 주어지지 않았는지.

이유가 아니라 가능성

세금, 교육, 공기, 상속, 의료, 문화. 사람들이 대는 이유들은 전부 사실이지만, 본질은 아니다. 본질은 "떠날 수 있게 되었다"는 것이다. 남는 사람과 떠나는 사람을 가르는 것은 가치관이 아니라 임계점이다. 그리고 임계점은 대부분, 살아보기 전에는 어디쯤인지 보이지 않는다.

그래서 "왜 떠나냐"는 질문은 종종 틀린 질문이다. 떠날 수 있어서 떠난다. 남을 수 있어서 남는 것이 아니라, 아직 떠날 수 없어서 남는 것일지도 모른다. 이 차이를 인정하는 사람은 남의 선택을 쉽게 평가하지 않는다. 그리고 어쩌면, 자기 자신에게 하는 "나는 안 해"라는 말도 다시 들여다보게 된다. 그 말 아래에 무엇이 숨어 있는지.

카페를 나와 걷던 길의 끝에 다시 현충원이 보였다. 옆 테이블에서 스친 한 문장이 이 정도의 생각을 끌고 올 줄은 몰랐다. 떠나는 이야기와 남은 이야기는 서로 다른 장르 같지만, 결국 같은 질문의 두 얼굴이다. 여기에 있을 이유가 있는가. 그리고 여기를 떠날 수 있는가. 둘 중 하나라도 분명한 사람은, 생각보다 많지 않다.

책상 바깥에서 자라는 것들

Sat, 18 Apr 2026 10:00:00 GMT

회의실과 모니터 사이에 앉아 있는 시간이 실력과 비례한다는 믿음이 있다. 엉덩이가 무거운 사람이 결국 이긴다는 말이 그렇고, 늦게까지 불을 켜둔 자리에 자부심을 붙이는 습관이 그렇다. 그런데 실제로 깊은 판단이 내려졌던 순간을 거꾸로 되감아 보면, 그건 자리 앞에서 쥐어짠 결과인 경우가 드물다. 오히려 책상을 떠나 있던 시간, 혹은 전혀 다른 곳을 바라보고 있던 시간에서 온다.

좋은 결과와 오래 앉아 있음 사이에는 직선이 없다. 둘은 나란히 놓인 다른 차원이다. 데이터와 근성으로는 채울 수 없는 영역이 있고, 그 영역은 대개 "책상 바깥"이라 불리는 시간에 조용히 채워진다.

욕조에서 풀린 문제

아르키메데스가 왕관의 비밀을 풀어낸 장소는 연구실이 아니라 욕조였다. 몸을 담그는 순간 넘쳐 흐르는 물을 보고, 오랫동안 책상에서 매달리던 부피 측정의 원리를 깨달았다. 그는 옷도 제대로 걸치지 않은 채 거리로 뛰쳐나갔다고 전해진다.

수학자 앙리 푸앵카레도 비슷한 경험을 『과학과 방법』에 직접 기록해두었다. 몇 달간 풀리지 않던 푹스 함수의 구조가, 연구실이 아니라 지질학 답사를 위해 마차에 오르는 순간 떠올랐다. "발을 발판에 올려놓는 바로 그 순간, 해답이 완전히 번뜩였다." 그는 덧붙인다. 책상 앞에서는 아무리 오래 붙어 있어도 나오지 않던 구조가, 거기서 떠난 뒤 거의 저절로 솟았다고.

두 사람의 공통점은 분명하다. 책상을 떠난 순간에 책상의 문제를 풀었다는 것. 이것은 우연도 기적도 아니다. 뇌가 작동하는 방식 그 자체다.

뇌는 쉴 때 정리한다

2001년, 워싱턴 의대의 마커스 라이클은 fMRI로 뇌를 관찰하다가 이상한 현상을 발견했다. 피험자가 아무 과제도 수행하지 않을 때, 오히려 뇌의 특정 영역들이 활발하게 움직이고 있었다. 내측 전전두엽, 후측 대상피질, 하두정소엽. 그는 이 회로에 "Default Mode Network(DMN)"라는 이름을 붙였다.

DMN은 멍하니 창밖을 볼 때, 샤워를 하는 동안, 산책길 위에서 가장 활발해진다. 그리고 이 회로가 하는 일은 흥미롭다. 지금까지 쌓인 기억을 재배열하고, 떨어져 있던 정보 사이에 다리를 놓고, 아직 오지 않은 장면을 시뮬레이션한다. 의식적 몰입이 정보를 한 점으로 모으는 수렴이라면, DMN은 정보를 섞고 연결짓는 확산이다.

근성으로 책상에 붙어 있는 시간은 이 회로를 오히려 꺼둔다. 수렴 엔진이 과열되는 동안 확산 엔진은 식는다. 그리고 확산 엔진이 식은 사람에게서는, 아무리 재료가 많아도 연결이 일어나지 않는다.

수렴과 확산, 두 개의 엔진

심리학자 J.P. 길포드는 사고를 두 종류로 나눈 적 있다. 수렴적 사고(convergent thinking)와 확산적 사고(divergent thinking). 수렴은 하나의 정답을 향해 파고드는 힘이고, 확산은 여러 가능성을 펼치며 멀리까지 뻗는 힘이다. 시험 문제는 대부분 수렴을 요구하지만, 실제 일의 난제는 거의 언제나 확산을 요구한다.

책상은 수렴의 공간이다. 반대로 산책로, 샤워실, 지하철, 부엌은 확산의 공간이다. 좋은 판단은 이 두 공간을 오가며 나온다. 수렴만 하는 사람은 날카롭지만 좁고, 확산만 하는 사람은 넓지만 공허하다. 한쪽 엔진만으로 비행기는 뜨지 않는다.

그런데 현대의 지식 노동자 대부분은 한쪽 엔진만 과열시킨다. 책상 앞의 시간을 실력의 증명이라 여기면서, 그 엔진을 식힐 시간을 일종의 사치로 취급한다. 사치라고 여기던 그 시간이, 실은 나머지 절반의 엔진이었다.

사냥꾼의 눈

사냥꾼은 사냥감만 보지 않는다. 바람의 방향, 나뭇잎의 뒤집힌 각도, 젖은 흙 위의 희미한 자국, 숲의 소리가 잠시 멎는 구간. 이 단서들을 동시에 읽어야 한다. 교과서에 쓰여 있지 않은 이 읽기는, 오로지 많은 숲을 걸어본 사람만이 할 수 있다. 목적을 가지고 걷는 숲만으로는 부족하다. 아무 목적 없이 걸었던 숲도 그 감각의 일부가 된다.

책상 앞에 앉은 사람은 자주 '문제'만 본다. 해결해야 할 지표, 답을 내야 할 의제, 마감이 걸린 페이지. 시야가 좁아지는 건 자연스럽다. 하지만 그 문제를 둘러싼 '숲'은 책상 위에 없다. 퇴근길의 표지판, 주말에 들른 낯선 동네의 간판, 취미로 고른 책의 한 줄, 키우는 식물이 시드는 방식. 업무와 아무 상관 없어 보이는 이런 장면들이, 어느 순간 문제의 본질을 비추는 단서가 된다.

목적 없이 바라보는 시간에만 감각은 본능의 층위로 내려앉는다. "이걸 써먹어야지"라고 준비하는 순간 그것은 이미 수렴이고, 수렴된 정보는 확장을 잃는다. 숲을 읽는 감각은 특별히 고안된 훈련이 아니라, 오랫동안 숲을 쏘다닌 덕분에 남겨진 흔적이다.

리더의 퇴근이 조직의 품질이다

취미 없는 리더의 판단에는 공통점이 있다. 모든 판단의 재료를 '업무 맥락' 하나에서만 길어온다. 회의에서 나오는 언어도, 문제를 바라보는 각도도, 사례로 드는 은유도 모두 같은 우물에서 퍼 올린 물이다. 물맛이 점점 얇아지는 것을 본인만 모른다.

반대로 전혀 다른 영역에 발을 담그는 리더가 있다. 주말에 목공을 하거나, 달리기를 하거나, 요리를 하거나, 무언가를 기르는 사람. 그런 리더가 꺼내는 질문의 결은 다르다. "이 프로젝트는 조립이 아니라 조각처럼 접근해야 할 것 같아요"라거나, "지금은 물을 더 주면 안 되는 단계 같아요" 같은 말이 나온다. 은유가 풍부한 사람은 대개 은유를 인위적으로 만든 게 아니라, 오래 쌓아둔 다른 세계의 감각을 꺼낸 것뿐이다.

이것은 한가로움이 아니라 재료 수급이다. 잘 퇴근하는 리더가 회의에서 더 좋은 질문을 던지는 것은 여유가 있어서가 아니라, 서로 다른 영역에서 퍼 올린 감각이 서로를 비추기 때문이다. 조직의 판단 품질은 결국 그 조직을 이끄는 사람의 삶이 얼마나 넓은지에 수렴한다.

취미에 효율을 요구하지 말 것

"이 취미가 내 업무에 도움이 될까?"를 묻는 순간, 그 취미는 이미 업무의 연장이 된다. 질문의 모양이 바뀌었을 뿐 수렴 엔진은 여전히 켜져 있다. 감각의 토양은 무용(無用)의 시간에서 자란다.

장자는 쓸모없는 것의 쓸모, 무용지용(無用之用)을 말했다. 큰 나무가 굽고 옹이가 많아 목수가 쓸 수 없다고 버려둔 덕분에, 그 나무는 잘려나가지 않고 오래 살아 그늘을 드리웠다. 쓸모없다는 이유로 살아남은 것이, 결국 더 큰 쓸모가 되었다.

직감에 이자를 붙이고 싶다면 취미에서 효율을 기대해서는 안 된다. 이자는 목적 없이 쌓은 시간에서만 붙는다. "이게 나중에 쓸모 있을까"를 묻지 않고 몰입했던 순간들이, 훗날 전혀 예상치 못한 자리에서 직감의 일부가 되어 되돌아온다. 효율을 기대한 취미는 업무가 되고, 업무가 된 취미는 더 이상 감각을 키우지 못한다.

의자에서 일어나는 일

오래 앉아 있는 것이 실력이 아니라, 잘 일어나는 것이 실력이다. 좋은 판단에 필요한 재료의 절반은 의자 위에 없기 때문이다. 의자는 재료를 정돈하는 자리이고, 의자 바깥은 그 재료가 모이는 자리다. 재료 없는 정돈은 공허하고, 정돈 없는 재료는 무질서하다. 둘은 번갈아 작동해야 하는 한 쌍이다.

숲을 많이 걸어본 사람만 숲의 흔적을 읽을 수 있다. 같은 이치로, 책상 바깥의 시간을 충분히 보낸 사람만이 책상 위의 문제를 다른 각도에서 볼 수 있다. 오늘의 좋은 판단은 지난 주말의 산책에서 왔고, 내일의 통찰은 오늘 저녁의 취미에서 자라고 있다.

이번 주에 할 수 있는 일은 거창한 휴가가 아니다. 업무에 도움이 될 것 같은 책이 아니라 끌리는 책을 한 권 펼쳐보는 일. 목적 없이 동네를 한 바퀴 걸어보는 일. 효율을 묻지 않고 취미에 한 시간을 내어주는 일. 이 작은 시간들이 쌓여 조용히 직감이 된다.

책상은 씨앗을 심는 자리일 뿐이다. 그것을 길러내는 일은, 언제나 책상 바깥에서 일어난다.

사랑을 받지 않는 기술

Fri, 17 Apr 2026 01:57:08 GMT

사막 한가운데 자판기가 하나 서 있다. 목이 말라 죽을 것 같은 사람이 동전을 넣고 버튼을 누른다. 아무것도 나오지 않는다. 한 번 더 누른다. 또 안 나온다. 열 번을 누른다. 백 번을 눌러도 같다.

이쯤 되면 보통은 자판기를 떠난다. "안 나오는구나." 그리고 다시는 그 버튼을 누르지 않는다.

이상한 일은 아니다. 백 번 시도해도 안 나오는 자판기 앞에서 버튼을 계속 누르는 게 오히려 더 이상하다. 그건 학습이다. 환경이 가르쳐 준 합리적 결론이다. 그런데 이 학습이 사람에게도 일어난다면 어떨까. 아주 어릴 때, 자기가 누른 버튼이 한 번도 응답하지 않는 경험이 반복되었다면.

받지 않는 데에도 기술이 있다

"회피형"이라는 말을 처음 들었을 때, 나는 그게 무언가를 못 하는 사람을 가리키는 줄 알았다. 정을 못 주는 사람, 사랑을 못 받는 사람, 마음을 못 여는 사람. 그런데 들여다볼수록 정반대 같다. 회피형은 무언가를 못 하는 사람이 아니라, 어떤 일을 너무 잘하게 된 사람에 가깝다.

받지 않는 일을 잘하는 사람.

심리학에서 1970년대에 했던 실험이 있다. 한 살짜리 아기를 낯선 방에 데려다 놓고 엄마를 잠깐 내보낸다. 대부분의 아기는 운다. 매달리고 싶어한다. 그런데 어떤 아기들은 울지 않는다. 엄마가 다시 들어와도 본 척도 안 한다. 안아주려 하면 몸을 비틀며 피한다.

처음에는 이 아기들이 씩씩하다고 봤다. 독립적이라고. 그런데 심박수와 스트레스 호르몬을 재 보니 이야기가 달랐다. 겉으로는 멀쩡해 보여도, 속으로는 우는 아기들과 똑같이 무너지고 있었다. 단지 표현하지 않을 뿐이었다.

왜 표현하지 않게 됐을까. 표현해 봤자 응답이 없었기 때문이다. 어떤 자판기는 누르면 가끔이라도 나온다 — 슬롯머신처럼 가끔 잭팟이 터지는 자판기 앞에서는 사람이 더 미친 듯이 버튼을 누른다. 그런데 이 아기들의 자판기는 그것조차 아니었다. 눌러도 안 나오고, 안 눌러도 안 나왔다. 그러니 누르지 않는 게 가장 합리적이었다.

회피형의 자기 신뢰는 그러니까 자신감이라기보다는 선언에 가깝다. 이 세상 믿을 사람 하나 없으니, 차라리 내가 알아서 살아남겠다는. 받기를 포기한 자리에 자립이 들어선 거다.

첫 번째 기술: 감정의 스위치를 끄는 법

받지 않는 기술의 핵심은 감정을 다루는 방법에 있다.

불안형이 감정을 키워서 어떻게든 응답을 끌어내는 방식이라면, 회피형은 감정을 꺼버리는 방식이다. 보고 싶다는 마음이 올라오면 — "지금은 일해야 돼." 외롭다는 느낌이 들면 — "혼자가 편하지 뭐." 슬프다는 감정이 시작되면 그 회로 자체를 차단한다.

흥미로운 건 이게 거짓말이 아니라는 점이다. 회피형이 슬프지 않다고 말할 때, 그건 정말로 슬픔을 느끼지 않는 상태일 수 있다. 감정을 느끼는 뇌와 상황을 인지하는 뇌 사이의 연결이 일시적으로 끊어진다. 본인도 모르게.

그래서 회피형 어른에게 어린 시절을 물으면 종종 이런 답이 돌아온다. "별로 힘든 기억은 없어요. 그냥 평범했어요." 구체적으로 어떤 좋은 추억이 있냐고 다시 물으면 잘 떠올리지 못한다. 따뜻하게 안겼던 기억, 함께 웃었던 기억, 위로받았던 기억. 그런 것들이 비어 있다. 좋은 기억도 나쁜 기억도 같이 흐릿한 거다.

스위치를 끈다는 건 한쪽만 끌 수 없는 일인 듯하다. 슬픔의 회로를 차단하면 기쁨의 회로도 같이 어두워진다. 받지 않기 위해 닫은 문은, 들어오는 것도 나가는 것도 막는다.

문제는 그렇게 닫아둔 감정이 사라지지는 않는다는 거다. 어딘가로 가야 한다. 회피형의 몸에는 그래서 두통이, 소화불량이, 만성피로가 자주 산다. 마음이 받지 않으면 몸이 대신 받는다.

두 번째 기술: 거북이의 침묵

부부 치료의 권위자 존 가트맨 박사가 갈등 상황에서 회피형의 심박수를 잰 적이 있다. 결과는 좀 충격적이었다. 겉으로는 팔짱을 낀 채 무표정하게 앉아 있는데, 심박수는 분당 100회를 훌쩍 넘어 있었다.

회피형이 싸울 때 침묵하는 이유를 그동안 우리는 거꾸로 이해해 왔던 것 같다. 무관심해서, 화가 나서, 무시하려고. 그런데 안에서 일어나는 일은 정반대다. 감정의 홍수가 뇌를 덮치고, 언어를 담당하는 부분이 마비된다. 말을 안 하는 게 아니라 못 하는 상태에 가깝다.

거북이를 떠올린다. 위협을 느낀 거북이는 등껍질 속으로 머리를 더 깊이 집어넣는다. 우리가 등껍질을 두드리고 소리 지를수록, 거북이는 더 안으로 들어간다. 나오라는 신호로 받아들이지 않기 때문이다. 그건 폭풍이 더 격렬해졌다는 신호다. 거북이는 그저 폭풍이 지나갈 때까지 버틴다.

회피형의 침묵을 보면서 "왜 대답을 안 해"라고 다그치는 건 등껍질을 두드리는 일과 비슷하다. 두드릴수록 안으로 들어간다. 그러니까 침묵은 거절이 아니라 차라리 오작동에 가깝다 — 과부하 걸린 컴퓨터에 엔터키를 백 번 누르는 셈이다.

이걸 알게 된 뒤로 나는 누군가의 침묵을 조금 다르게 읽기 시작했다. 답이 없는 게 답이 아닐 수도 있다는 것. 어쩌면 답이 너무 많아서 하나도 꺼내지 못하는 상태일 수도 있다는 것.

세 번째 기술: 일이라는 안전한 도피처

회피형이 가장 우아하게 회피하는 방법은 무엇일까. 도망가는 것도 아니고, 화내는 것도 아니다. 일하는 거다.

인간관계는 내 마음대로 안 된다. 상대가 어떻게 반응할지, 무엇을 요구할지, 언제 실망할지 통제할 수 없다. 그런데 일은 다르다. 노력한 만큼 결과가 나온다. 코드는 짜면 돌아가고, 보고서는 쓰면 완성된다. 회피형에게 직장은 감정 소모 없이 성취감을 얻을 수 있는 가장 안전한 공간이 된다.

게다가 "너무 바빠서 연락 못 했어, 미안"은 사회적으로 완벽하게 용인되는 거절 멘트다. 게으름이 아니다, 무관심이 아니다, 직무유기가 아니다. 오히려 성실함의 증거다. 회피형의 회피 성향이 사회적으로 박수받는 형태로 변신하는 순간이다.

그래서 회피형 중에 일중독이 많다. 일이 일이라기보다 도피처에 가까워진다. 일에 몰두하고 있으면 관계의 요구에서 벗어날 수 있고, 혼자 있어도 외롭지 않다. 책상 앞에 앉아 있는 동안만큼은 누구도 나에게 마음을 요구하지 않는다.

이 글을 쓰면서 가장 뜨끔한 부분이 여기였다. 일을 사랑한다고 믿었던 시간들이, 사실은 일 뒤에 숨어 있던 시간이었을지도 모른다는 가능성. 일을 잘한다는 칭찬을 받을 때마다 안전감을 느꼈다면, 그건 성취에 대한 자긍심이었을까 아니면 회피에 성공했다는 안도였을까.

받지 않는 기술의 양면

여기까지 읽으면 회피형이 무슨 결함처럼 들릴 수도 있겠다. 그런데 한쪽 면만 보고 있는 거다.

받지 않는 기술에는 분명한 강점이 있다. 감정에 휩쓸리지 않고 상황의 사실에 차분히 집중할 수 있다는 것. 심리학에서는 이걸 "인지적 재평가"라고 부른다. 위기 상황에서 패닉에 빠지지 않고 침착하게 대응 방식을 떠올릴 수 있다. 갈등이 휘몰아쳐도 자기 페이스를 잃지 않는다.

이스라엘에서 했던 재미있는 실험이 있다. 사람들을 모아놓고 컴퓨터에서 정체불명의 연기가 나도록 한다. 불안형 애착이 높은 사람들이 가장 먼저 알아차렸다. 그런데 위험에서 가장 빨리 벗어난 건 회피형이었다. 알아차리는 건 늦었지만, 알아차린 다음에 침착하게 행동했던 거다.

원시 부족을 상상해 보자. 맹수가 습격할 때 위험을 가장 먼저 감지하는 건 불안형 선조다. 모두가 패닉에 빠질 때, 회피형 선조가 침착하게 말한다. "저쪽 동굴로 가자." 집단이 살아남으려면 둘 다 필요하다. 어쩌면 우리는 회피형을 너무 오래 부정적으로만 봐 왔는지도 모른다. 자급자족 모드로 살아남은 사람들. 받기를 포기한 대신 자기 발로 서는 법을 익힌 사람들.

다만 이 기술에는 비용이 따른다. 받지 않는 데 익숙해진 사람은, 자기가 무언가를 받았을 때 그것을 어떻게 처리해야 할지 모른다. 누가 호의를 베풀면 즉시 갚아야 한다는 압박을 느낀다. 빚지고 싶지 않아서가 아니라, 빚진 채로 있는 방법을 모르기 때문이다. 받기는 통제권을 잠깐 내려놓는 일인데, 회피형은 그 잠깐을 견디기가 어렵다.

그리고 무엇보다, 감정은 미뤄둔 만큼 한 번에 돌아온다. 회피형은 이별 직후에 오히려 후련함을 느낀다. "아, 이제 내 시간이 생겼네." 그런데 몇 달이 지나면 갑자기 그 사람이 떠오르고, 후회가 밀려오고, 잠을 못 잔다. 억눌렀던 감정이 쓰나미처럼 밀려오는 거다. 받지 않으려 했던 것들의 청구서가 한참 뒤에 도착한다.

다시 받는 연습

회피형은 어쩌면 어린 시절에 두려움 때문이 아니라 사랑 때문에 그 길을 선택했는지도 모른다. 자기를 충분히 돌봐주지 못하는 부모가 안쓰러워서, 내가 기대면 부모가 더 힘들어할 것 같아서. 부모를 귀찮게 하지 않고, 알아서 잘하는 모습으로 짐을 덜어주려고. 그 어린 나이에 그런 마음을 먹었다면, 그건 결함이라기보다는 차라리 사랑의 한 형태였다.

다만 이제는 좀 다른 이야기가 가능해진다. 어른이 된 회피형은 더 이상 그렇게 혼자 모든 걸 짊어져야 하는 아이가 아니다. 도움을 요청해도 무너지지 않는다. 약한 모습을 보여도 사람들이 떠나지 않는다. 그런데 그 사실을 머리로 아는 것과, 몸이 받아들이는 건 다른 문제다.

받지 않는 기술이 평생에 걸쳐 정교해진 만큼, 받는 기술도 같은 시간을 들여 다시 익혀야 할지도 모른다. 단번에 되는 일이 아니다. 사막 자판기 앞에서 다시 버튼을 누르는 일은, 한두 번 누른다고 익숙해지지 않는다. 누를 때마다 "또 안 나오면 어쩌지" 하는 두려움이 따라온다. 그게 자연스럽다.

진짜 용기는 더 강해지는 게 아닐 수도 있다. 혼자서 갈증을 끝까지 참는 것도 아닐 수 있다. 어쩌면 다시 목마르다고 말하는 것. 그리고 누군가가 건네는 물을 거절하지 않는 것. 받는 일을 어색해하면서도 일단 받아보는 것.

세상의 모든 자판기가 고장 난 건 아니다. 그건 어릴 적의 자판기 한 대가 그랬을 뿐이다. 다른 자판기는 다른 응답을 한다. 그걸 머리로 아는 것에서, 한 번 더 눌러보는 것까지의 거리가 회피형에게는 가장 멀고 어려운 길일 것이다.

다만 그 거리를 한 번 건너고 나면, 받지 않는 기술과 받는 기술 둘 다 가진 사람이 된다. 위기에 침착하면서도 친밀함에 마음을 열 수 있는 사람. 자급자족이 가능하면서도 함께 살아갈 줄 아는 사람. 그게 어쩌면 회피형이 도달할 수 있는 가장 단단한 형태가 아닐까.

이름이 숫자가 되던 날

Fri, 17 Apr 2026 01:51:47 GMT

시험지가 돌려지는 교실의 풍경이 있다. 종이 맨 위에는 이름이, 그 옆에는 붉은 글씨로 숫자가 하나 붙어 있다. 94. 그 아래에는 더 작은 글씨로 '반 석차 3/35'. 아이들은 종이를 받아 들며 책상 아래로 시선을 내리깐다. 옆자리 친구의 점수를 흘끗 훔쳐본다. 마음 한구석에서 무언가가 조용히 움직인다.

이름 옆에 숫자가 붙는 순간, 무언가가 바뀐다. 그때부터 사람은 더 이상 사람이 아니라, 평균으로부터 몇 점 위에 있거나 아래에 있는 존재가 된다. 길이가 되고, 너비가 되고, 등급이 된다. 그런데 우리는 대체 누구를 기준으로 그 거리를 재고 있는 걸까.

존재하지 않는 조종사

1950년대 초, 미 공군은 원인을 알 수 없는 추락 사고에 시달리고 있었다. 전투기 성능은 비약적으로 좋아졌는데, 조종사들이 잇따라 떨어졌다. 처음엔 조종사 개개인의 실력을 탓했고, 그다음엔 기계적 결함을 의심했다. 그러나 진짜 원인은 엉뚱한 곳에 있었다. 조종석이었다.

공군은 조종사 4,063명의 신체 치수를 측정해 그 평균값으로 조종석을 설계했다. 가장 많은 사람에게 가장 잘 맞을 거라고 굳게 믿었던 그 평균 사이즈. 그런데 연구원 길버트 대니얼스가 이상한 질문 하나를 던진다. 키, 가슴둘레, 팔 길이 등 열 가지 주요 항목에서 평균값에 모두 속하는 조종사는 과연 몇 명일까.

답은 0명이었다.

4,063명의 조종사 중 열 가지 평균에 모두 부합하는 사람은 단 한 명도 없었다. 어떤 이는 팔이 긴데 다리가 짧았고, 어떤 이는 가슴이 넓은데 머리가 작았다. 평균적인 조종사라는 존재는 이 세상에 없었다. 미 공군은 유령을 위해 수만 대의 조종석을 찍어내고 있었던 것이다.

이 이야기의 무게는 거기에 있다. 우리가 평생 맞추려 애써온 그 몸은, 어쩌면 애초에 존재하지도 않는 것일지 모른다.

교실이라는 조종석

평균이 이상적 인간의 모습이라고 선언한 사람은 19세기의 통계학자 아돌프 캐틀레였다. 그는 군인들의 신체 치수를 재서 평균값을 구한 뒤, "이상적인 인간이란 평균값이다"라고 선언했다. 그로부터 200년이 지난 지금도, 이 한 문장이 학교와 회사와 사회 전체를 지배하고 있다.

18세기 후반, 나폴레옹에게 처참하게 패배한 프로이센 제국은 이런 결론을 내렸다. 제국은 비판적으로 생각하는 개인이 아니라 명령에 복종하는 부품이 필요하다. 그렇게 종소리에 맞춰 이동하고, 정해진 내용을 암기하고, 시험으로 서열을 매기는 프로이센식 교육이 탄생했다. 토드 로즈는 이 모델을 "존재하지도 않은 평균적 학생을 위해 설계된 거대한 조종석"이라고 불렀다.

이 조종석 안에서 잘 적응한 사람들은 하나의 공통된 믿음을 가진다. 공부를 잘하면 나는 똑똑한 사람이고, 못하면 나는 멍청한 사람이다. 성적이, 시험 점수가, 평균과의 거리가 곧 내 가치를 증명한다.

이 믿음이 어디서 탈이 나는지를 보여주는 실험이 있다. 스탠포드의 캐럴 드웩은 초등학교 5학년 400명에게 어려운 퍼즐을 풀게 한 뒤, 두 그룹에게 딱 한 마디씩만 다르게 말해주었다. A 그룹에게는 "너 정말 똑똑하구나", B 그룹에게는 "너 정말 열심히 했구나". 다음 시험에서 '열심히 했다'고 칭찬받은 그룹은 성적이 30% 올랐고, '똑똑하다'고 칭찬받은 그룹은 오히려 20% 떨어졌다.

왜 이런 일이 벌어졌을까. '똑똑하구나'라는 말을 들은 순간, 아이의 머릿속엔 '나는 똑똑한 아이'라는 정체성이 생긴다. 그런데 이 정체성이 곧 양날의 검이다. 다음 시험에서 어려운 문제를 만나면 아이는 생각한다. 틀리면 어떡하지? 내가 사실은 똑똑하지 않다는 게 들통나는 것 아닐까. 그래서 아이는 도전하지 않는다. 쉬운 문제만 고른다. 실패는 단순한 실패가 아니라, 내가 멍청하다는 증거가 되어버리니까.

어쩌면 이것이, 요즘 번아웃과 무기력의 정체일지도 모른다. 태어날 때부터 평균이라는 잣대로 줄 세워져온 사회에서, 한 번의 실패가 "나는 역시 평균도 안 되는 사람이구나"를 증명해버리는 순간 — 우리는 아예 시도하지 않는 쪽을 택한다. 시도하지 않으면 적어도 '아직 제대로 안 해 본 사람'으로는 남을 수 있으니까. '해봤는데 안 되는 사람'보다는 나으니까.

사냥꾼의 몸, 농부의 일

그렇다면 왜 어떤 사람들은 유독 교실과 사무실에서 힘들어할까. 미국 국립 보건원의 연구에 따르면, ADHD가 있거나 산만하다고 평가받는 사람들의 뇌는 도파민 수용체 밀도와 운반체 수치가 일반인보다 현저히 낮다. 쉽게 말해, 남들만큼 각성하려면 훨씬 더 강렬하고 즉각적인 자극이 필요하다는 뜻이다.

숏폼 영상은 1초마다 도파민을 공급한다. 학교와 직장은 3개월 뒤의 성적, 1년 뒤의 인사 평가라는 지연된 보상을 약속한다. 애초에 강한 자극이 필요한 뇌에게 이 간격은, 굶어 죽으라는 요구와 비슷하다.

흥미로운 건, 이 뇌가 늘 결함이었던 건 아니라는 사실이다. 아프리카 케냐 북부의 아리알 부족에는 새로운 자극을 끊임없이 좇게 만드는 DRD4-7R, 이른바 '방랑자 유전자'를 가진 사람들이 있다. 이들이 초원을 누비는 유목 생활을 하던 시절, 방랑자 유전자를 가진 사람들은 부족 최고의 에이스였다. 체질량 지수도 높고 영양 상태도 완벽했다. 사방에서 맹수가 튀어나오는 환경에서 그들의 산만함은 주변을 경계하는 레이더였고, 충동성은 창을 빠르게 던지게 만드는 생존의 무기였다.

그런데 부족이 마을에 정착해 농경 생활을 시작하자, 똑같은 유전자를 가진 에이스들이 가장 먼저 영양실조에 시달리며 도태되기 시작한다. 몸은 그대로인데 환경만 바뀌었는데, 에이스가 낙오자가 된다. 진화 생물학은 이 현상을 '진화적 불일치'라고 부른다.

어쩌면 교실과 사무실에서 미칠 듯한 지루함을 느끼는 건, 당신에게 결함이 있어서가 아닐지도 모른다. 사냥꾼의 하드웨어를 가지고, 씨앗이 자라는 걸 가만히 기다려야 하는 농부의 삶에 갇혀 있기 때문일지도 모른다.

악당이 되는 편이 낫다

중학교 1학년 미술 시간, 지루함을 견디지 못한 한 소년이 칠판을 향해 황화암모늄 폭탄 여섯 개를 던진다. 달걀 썩는 냄새에 모든 학생이 눈물을 흘리며 도망칠 때, 그 소년만 혼자 웃었다. 선생님은 소년의 목덜미를 잡고 교장실로 끌고 갔다. 소년에게는 이미 익숙한 공간이었다. 그는 정학 처분을 받았고, 얼마 뒤 ADHD 판정도 받았다. 평점 0.9로 고등학교를 간신히 졸업한 이 소년은, 훗날 교육 신경과학의 권위자가 되는 토드 로즈다.

그는 나중에 이렇게 고백했다. "무능한 피해자로 동정받느니, 차라리 악당이 되어 경멸받고 싶었다."

이 고백의 핵심은 자율성이다. 인간의 가장 강력한 본능 중 하나는 '내 삶을 스스로 통제한다'는 감각이다. 환경이 "너는 평균이야. 너는 구제 불능이야"라고 억압할 때, 남은 통제권을 지키기 위해 할 수 있는 일은 스스로 룰을 엎어버리는 것뿐이다. 악당이 되는 길은 결함이 아니라, 마지막 자존감을 지키기 위한 처절한 방어 기제일 수 있다.

생각해보면 우리 주변에도 이런 사람들이 있다. 이해할 수 없는 타이밍에 조직을 뒤집는 동료, 갑자기 프로젝트를 엎어버리는 선배, 스스로 커리어를 망치는 듯한 선택을 반복하는 지인. 그들을 그냥 '문제 있는 사람'으로 라벨링하기는 쉽다. 하지만 그들이 오랫동안 맞지 않는 조종석에 눌려 있었다면, 어쩌면 그 폭발은 결함이 아니라 생존 신호였을지도 모른다.

토드답지 않게요

시간당 4달러를 받으며 백화점 선반을 정리하던 고졸 중퇴자. 아내와 어린 두 아들을 부양하며 복지 수당으로 연명하던 사람. 이 사람이 어떻게 하버드 교수가 될 수 있었을까.

먼저 움직인 건 아내 케일린이었다. 토드가 일하러 나간 사이, 그녀는 부모에게 돈을 빌려 야간 수업 두 과목을 대신 등록해버렸다. 그리고 대수롭지 않게 말했다. "등록금은 환불이 안 되니까, 늦기 전에 듣고 싶은 과목으로 바꾸는 게 좋을 거야." 토드가 선택한 과목은 개인 관계 심리학이었다.

어느 날 토드가 과제를 내지 않았다. 예전의 나쁜 습관이 되살아난 것이었다. 그런데 담당 교수는 혼내지 않았다. 걱정스러운 표정으로 다가와서 이렇게 말했다. "토드, 토드답지 않게 왜 그랬어요?"

이 한 마디가 그의 안에서 무언가를 건드렸다. 그는 처음으로, 자신을 '문제'가 아니라 '가능성 있는 학생'으로 바라보는 사람을 만난 것이다.

1963년, 하버드의 로버트 로젠탈은 샌프란시스코의 저소득층 학교에서 작은 실험을 한다. 전교생을 대상으로 지능 검사를 한 뒤, 점수와 무관하게 무작위로 20%의 학생을 뽑아 교사들에게 이렇게 말했다. "이 아이들은 앞으로 지적 능력이 크게 향상될 것으로 보입니다." 8개월 후 다시 검사했을 때, 그 아이들의 성적은 실제로 눈에 띄게 향상되어 있었다. 유명한 피그말리언 효과의 탄생이다.

교사가 아이에게 긍정적인 기대를 품는 순간, 의식적으로 그 아이에게 더 눈을 맞추고, 더 따뜻하게 대하고, 질문에 답할 시간을 더 주고, 틀려도 더 많이 격려하게 된다. 기대는 대기 중으로 사라지지 않는다. 시선으로, 어조로, 기다림의 길이로 전해진다.

토드는 결국 우수한 성적으로 대학을 졸업했지만, 하버드 대학원 지원서를 써놓고도 원서비 120달러가 아까워서 — 아니, 사실은 또 실패할까 두려워서 — 그 종이를 쓰레기통에 쳐박는다. 그때 아내 케일린이 다시 쓰레기통에서 원서를 꺼내 먼지를 털며 말했다. "떨어지는 건 아무것도 아니야. 근데 시도조차 안 하면, 평생 후회하면서 살게 될 걸."

'너답지 않게'와 '시도 안 하면 후회해'. 이 두 문장 사이에, 토드 로즈의 하버드가 있다.

좌석을 조종사에게 맞추기

미 공군은 결국 그 문제를 어떻게 해결했을까. 해결책은 아주 단순했다. 좌석을 앞뒤로 밀고 당길 수 있게 만든 것이다. 조종사를 조종석에 맞추는 대신, 조종석을 조종사에게 맞췄다. 그러자 모든 조종사의 기량이 상승했다.

우리에게도 같은 일이 일어난 적이 있을까.

평균이 곧 이상이었던 지난 200년 동안, 우리는 조종석에 몸을 맞춰왔다. 그 과정에서 몸은 뒤틀렸고, 그 통증에 우리는 이렇게 이름을 붙였다. 게으름. 의지박약. 평균 이하. 하지만 평균에 딱 들어맞는 사람은 이 세상에 단 한 명도 없다. 아인슈타인은 이렇게 말했다. 모든 사람은 천재다. 하지만 나무에 오르는 능력으로 물고기를 평가한다면, 물고기는 평생 자신을 바보라고 믿으며 살게 될 것이다.

사람이 자신의 특별함을 의심하기 시작하는 건 언제일까. 아마 처음으로 이름 옆에 숫자가 붙던 그날부터일 것이다. 그날 이후로 사람은 이름이 아니라 숫자로 호명된다. 몇 등이고, 몇 점이고, 몇 번째 직원이고, 몇 분위.

조종석을 조종사에게 맞추는 일은 거창한 해방이 아니다. 언제 에너지가 차오르고 언제 지치는지를 관찰하는 일. 무엇이 자신의 도파민에게 말을 거는지 이해하는 일. 빠른 영역과 느린 영역을 섞어서 자기 고유의 리듬으로 받아들이는 일. 아주 작은 범위에서라도, 앉을 자리의 위치를 몇 센티미터 앞뒤로 미세하게 조정해보는 일이다.

어쩌면 어른이 된다는 건, 이름 옆에 붙었던 숫자들을 하나씩 떼어내고 다시 이름으로 돌아가는 과정일지도 모른다. 그리고 그때 숫자를 이름으로 되돌리는 주체는 선생님도 회사도 사회도 아니다. 결국, 자기 자신이다.

How는 어렵다

Tue, 14 Apr 2026 14:00:00 GMT

누군가에게 자전거 타는 법을 설명해 본 적이 있는가. 페달을 밟으라, 핸들을 잡으라, 균형을 잡으라 — 말로는 그럴듯하다. 하지만 이 설명을 듣고 자전거를 탈 수 있게 된 사람은 없다. 넘어지고, 다시 올라타고, 또 넘어지고, 어느 순간 몸이 알아서 균형을 잡기 시작할 때까지. 자전거를 타는 법은 말이 아니라 몸으로 배운다.

일하는 법도 마찬가지가 아닐까. 요즘은 "How는 쉽다"는 말이 당연한 것처럼 쓰인다. AI가 코드를 짜주고, 실행 비용이 거의 0에 수렴하는 시대니까. 하지만 정작 "당신은 일을 어떻게 하나요?"라고 물으면, 깔끔하게 대답할 수 있는 사람이 얼마나 될까. How가 정말로 쉽다면, 왜 우리는 그것을 설명하지 못하는 걸까.

자전거를 타는 법을 설명해 보라

PR 리뷰를 잘하는 시니어 엔지니어가 있다고 하자. 그 사람에게 "PR 리뷰를 어떻게 하세요?"라고 물으면, 보통 이런 대답이 돌아온다. "일단 전체 diff를 훑어보고, 변경 의도를 파악하고, 로직에 문제가 없는지 확인해요." 맞는 말이다. 하지만 이 설명을 그대로 따라 한다고 해서 같은 수준의 리뷰가 나오지는 않는다.

그 사람이 diff를 훑을 때 실제로 일어나는 일은 훨씬 복잡하다. 수백 줄의 변경 중 어디에서 멈추는지, 왜 그 지점이 걸리는지, "이건 나중에 문제가 될 것 같다"는 직감이 어디서 오는지 — 이런 것들은 당사자도 정확히 설명하지 못한다. 10년의 경험이 압축된 패턴 인식이 작동하고 있을 뿐이다.

자전거와 같다. 핸들을 몇 도 기울여야 좌회전이 되는지, 속도와 균형의 관계가 어떻게 되는지 — 탈 줄 아는 사람도 이걸 수치로 말하지 못한다. 몸이 아는 것과 입으로 설명할 수 있는 것 사이에는 넓은 간극이 있다.

절차 기억이라는 블랙박스

최근 AI 에이전트의 인지 구조를 분석한 CoALA(Cognitive Architectures for Language Agents)라는 논문을 읽었다. 인간의 기억 체계를 빌려와 에이전트를 설계하는 프레임워크였는데, 기억을 네 가지로 나눈다. 지금 이 순간 쓰이는 정보를 담는 작업 기억, 과거 경험을 저장하는 일화 기억, 세계에 대한 사실을 보관하는 의미 기억, 그리고 "어떻게 하는지"를 담는 절차 기억.

흥미로운 건 절차 기억이 두 층으로 나뉜다는 점이었다.

첫째는 명시적 절차 기억이다. 매뉴얼, 체크리스트, 워크플로우 문서, 코드로 작성된 로직. "사용자가 가입하면 → 이메일 인증을 보내고 → 온보딩 화면을 띄운다" 같은 흐름이다. 이건 누구나 읽을 수 있고, 복사할 수 있고, 자동화할 수 있다.

둘째는 암묵적 절차 기억이다. AI로 비유하면 수십억 개의 파라미터에 압축된 가중치 — 언어를 다루는 법, 맥락을 읽는 법이 여기에 녹아 있지만, 꺼내서 들여다볼 수는 없다. 자전거 타는 법을 말로 설명하기 어렵듯, 이 가중치도 명시적으로 풀어쓸 수 없다.

사람에게도 마찬가지다. 시니어 엔지니어의 코드 리뷰 능력, 노련한 PM의 우선순위 감각, 경험 많은 디자이너의 "이건 아닌데" 하는 직감 — 이것들은 모두 암묵적 절차 기억이다. 노션 문서에도, 위키에도, 온보딩 자료에도 담기지 않는다. 당사자의 머릿속에만 존재하고, 당사자조차 온전히 꺼내지 못한다.

사람들이 "How는 쉽다"고 말할 때, 그들이 말하는 How는 첫 번째 층이다. 명시적 절차 기억, 즉 문서화되고 자동화 가능한 표면. 하지만 진짜 How — 일을 잘하게 만드는 그 핵심 — 은 두 번째 층에 있다.

How를 쉽다고 말할 수 있는 조건

공정하게 말하자면, How가 정말로 쉬워지는 조건이 있긴 하다.

100년 전 프레더릭 테일러는 공장 노동자들의 작업을 관찰하면서 혁신적인 아이디어를 냈다. 하나의 작업을 가능한 한 작은 단위로 쪼개고, 각 단위를 표준화하고, 각 단위를 다른 사람에게 할당하라. 삽으로 석탄을 퍼 나르는 일을 "삽을 들어올리는 동작", "몸을 회전하는 동작", "석탄을 쏟는 동작"으로 분해하면, 각 동작의 How는 단순해진다. 누구나 배울 수 있고, 누구로든 대체할 수 있다.

이 논리는 오늘날에도 유효하다. 일을 충분히 작게 쪼개면, 각 조각의 How는 사소해진다. 소프트웨어 개발에서 마이크로서비스가 대형 모놀리스보다 각 부분의 이해를 쉽게 만드는 것도 같은 원리다. AI가 "How를 대신한다"는 것도 결국 이 맥락이다 — 충분히 분해된 작업의 명시적 절차를 자동화하는 것.

하지만 여기에 숨겨진 전제가 있다. 일이 그렇게 쪼개질 수 있어야 한다는 것이다.

디자이너가 레이아웃을 결정할 때, 그 판단은 "왼쪽 정렬 → 여백 16px → 폰트 14pt"로 분해되지 않는다. 수백 번의 시행착오에서 축적된 미적 감각, 사용자의 시선 흐름에 대한 체감, "이 화면은 무언가 답답하다"는 느낌 — 이런 것들이 동시에 작동하면서 하나의 결정을 만들어낸다. 엔지니어가 시스템을 설계할 때도, 매니저가 회의에서 분위기를 읽을 때도 마찬가지다.

그 논문에서 흥미로운 문장을 발견했다. 에이전트는 빈 상태에서 태어나도 되지만, 절차 기억만은 비어 있으면 안 된다. 다른 기억 — 경험, 지식 — 은 나중에 채울 수 있지만, "어떻게 할 것인가"는 처음부터 주어져야 한다. 기계도 그런데, 하물며 사람의 How는 어떻겠는가.

말로 옮길 수 없는 것의 무게

철학자 마이클 폴라니는 이런 말을 남겼다. "우리는 말할 수 있는 것보다 더 많이 안다(We know more than we can tell)." 이것은 인간 지식의 결함이 아니라 특성이다. 전문성이 깊어질수록, 그 지식은 의식의 표면 아래로 가라앉는다. 더 잘 알게 될수록 덜 설명할 수 있게 되는 역설.

조직에서 이 현상은 매우 구체적인 결과를 낳는다. 시니어가 팀을 떠나면 무엇이 사라지는가. 그 사람이 작성한 문서는 남아 있다. 코드도, 위키도, 슬랙 히스토리도 남아 있다. 하지만 무언가가 분명히 사라진다. "그 사람이 있으면 이런 건 안 일어났을 텐데" 하는 상황이 늘어난다. 사라진 것은 의미 기억(문서화된 지식)이 아니라 암묵적 절차 기억 — 문서에는 없지만 그 사람의 판단에는 있던 것들이다.

AI의 맥락에서도 같은 한계가 드러난다. 회사의 모든 문서를 학습시키면 의미 기억은 복제할 수 있다. 모든 대화 기록을 넣으면 일화 기억도 흉내 낼 수 있다. 하지만 최고의 엔지니어가 "이 설계는 3개월 뒤에 문제가 될 것"이라고 느끼는 그 감각 — 이건 어떤 데이터에도 명시적으로 기록되어 있지 않다. 학습시킬 아티팩트 자체가 존재하지 않는다.

How를 진짜로 아는 사람

레시피를 따르는 사람과 요리하는 사람의 차이를 생각해 보자. 둘 다 같은 요리를 만든다. 같은 재료, 같은 순서. 하지만 요리하는 사람은 소금을 넣기 전에 맛을 보고, 불 세기를 중간에 바꾸고, 재료가 없으면 다른 것으로 대체한다. 레시피를 따르는 사람은 그렇게 하지 못한다. 이탈하면 불안해지고, 대체하면 확신이 없어진다.

차이는 단계에 있지 않다. 단계와 단계 사이에 있다. 적힌 대로 하는 것은 명시적 절차 기억이고, 상황에 따라 적힌 것을 벗어나는 것이 암묵적 절차 기억이다.

소프트웨어에서도 같다. 주니어 엔지니어는 아키텍처 문서를 충실히 따른다. 시니어 엔지니어는 언제 그 문서를 어겨야 하는지 안다. "이 경우에는 원칙을 따르면 오히려 복잡해진다"는 판단, "지금은 기술 부채를 의도적으로 남기는 게 맞다"는 결정 — 이런 것들은 어떤 가이드라인에도 적혀 있지 않다. 그리고 이것이야말로 조직이 그 사람에게 기대하는 진짜 가치다.

그래서 멘토링, 페어 프로그래밍, 도제식 학습이 AI 시대에도 사라지지 않는 것이 아닐까. 명시적 절차 기억은 문서로 전달할 수 있다. 하지만 암묵적 절차 기억은 옆에서 보고, 따라 하고, 실패하고, 다시 시도하는 과정을 통해서만 전달된다. 자전거를 타는 법을 배우듯이.

어쩌면 우리가 "일 잘하는 사람"이라고 부르는 것의 실체는, 더 많은 What을 아는 사람도, 더 빠른 How를 가진 사람도 아닐 수 있다. 암묵적 절차 기억이 더 정교하게 축적된 사람 — 단계 사이의 판단이 더 촘촘한 사람 — 이 아닐까.

그런데 정말 그런 걸까

여기까지 쓰고 나서 스스로에게 반문해 본다. 설명할 수 없다는 것이 정말로 자동화할 수 없다는 뜻일까.

LLM을 생각해 보자. LLM은 자신의 가중치를 설명하지 못한다. 왜 이 단어 다음에 저 단어를 선택했는지 명시적으로 풀어쓸 수 없다. 하지만 그것이 LLM의 능력을 제한하지는 않는다. 오히려 설명할 수 없는 채로 놀라운 수준의 일을 해낸다. 설명 불가능성과 자동화 불가능성은 같은 것이 아니다.

그리고 더 불편한 질문이 있다. 내가 나의 How를 설명하지 못하는 이유가, 정말로 그것이 깊고 정교한 암묵지이기 때문일까. 혹시 그냥 대충 해왔기 때문은 아닐까. 자신의 일에 진지하게 임하지 않은 사람도 "어떻게 하는지 설명하기 어렵다"고 말한다. 숙련자의 설명 불가능과 미숙련자의 설명 불가능은 겉으로 구분이 안 된다.

매일 아침 같은 루트로 출근하는 사람에게 "왜 그 길로 가세요?"라고 물으면 "그냥요"라고 답할 수 있다. 이것은 수천 번의 경험에서 최적화된 암묵적 판단일 수도 있고, 한 번도 다른 길을 시도해 보지 않은 관성일 수도 있다. 둘 다 "설명할 수 없다"는 점에서는 동일하다.

그래서 "How는 어렵다"는 말은 조건부다. 자신의 How를 의식적으로 갈고닦아 온 사람에게만 해당된다. 설명할 수 없는 것의 무게는, 그 아래에 진짜로 쌓인 것이 있을 때만 무겁다. 없으면 그냥 빈 상자다.

How를 쉽다고 말하기 전에

다시 자전거로 돌아오자. 자전거 타는 법에 대한 매뉴얼을 쓸 수 있다. 10페이지든 100페이지든. 모든 문장이 정확할 수 있다. 그리고 그 매뉴얼은 아무에게도 자전거를 가르치지 못할 것이다. 매뉴얼과 실제 라이딩 사이의 간극 — 그것이 How의 본질이다.

명시적 절차 기억과 암묵적 절차 기억. 문서화된 단계와 문서화할 수 없는 판단. 이 두 층을 구분하지 않으면, How에 대한 대화는 늘 엇갈린다. "How는 쉽다"고 말하는 사람은 첫 번째 층을 보고 있고, "How는 어렵다"고 느끼는 사람은 두 번째 층을 경험하고 있다. 둘 다 맞지만, 말하는 대상이 다르다.

How의 표면이 점점 자동화되고 있는 것은 사실이다. 그리고 그것은 좋은 일이다. 하지만 그 자동화가 진행될수록, 남는 것은 자동화할 수 없는 층이다. 단계를 실행하는 능력이 아니라, 단계를 설계하고, 변형하고, 때로는 무시하는 판단력. 그것이 점점 더 드러나고, 점점 더 중요해진다.

당신이 지금 하는 일의 How를 누군가에게 설명해 보라. 설명할 수 있는 부분은 조만간 자동화될 것이다. 설명할 수 없는 부분이 클수록, 당신이 쌓아온 것도 크다. 그것을 "쉽다"고 부르기 전에, 한 번쯤 그 무게를 재어볼 필요가 있지 않을까.

금융 데이터, 하나의 API로 — Headless Finance Platform을 공개합니다

Mon, 13 Apr 2026 15:00:00 GMT

금융 데이터 연동이라는 늪

회계 자동화, 경비 관리, 대출 심사, 세금 신고. 금융 데이터가 필요한 서비스는 셀 수 없이 많다. 그런데 정작 그 데이터를 가져오려고 하면, 대부분의 팀이 같은 늪에 빠진다.

은행마다 인증 방식이 다르다. 카드사마다 응답 포맷이 다르다. 홈택스는 자기만의 세계를 구축하고 있다. 겨우 연동에 성공해도, 기관 인터페이스가 예고 없이 바뀌면 새벽에 장애 알림이 울린다. 3개월에서 6개월을 연동에 쏟고도 유지보수에 허덕이는 팀을 수없이 봐왔다. 우리도 그중 하나였다.

우리가 이 문제를 풀 수밖에 없었던 이유

볼타를 운영하면서 우리는 수십억 건의 비정형 거래내역을 수집하고, 정규화하고, 서비스에 연결해왔다. "카드매출내역"이라는 단순해 보이는 데이터 하나만 해도, 기관마다 필드명이 다르고 날짜 포맷이 다르고 금액의 부호 규칙이 전부 다르다. 이걸 일관된 형태로 만드는 건 기술이라기보다 노하우다. 문서에 적혀 있지 않은, 실전에서만 쌓이는 종류의 경험.

에러 핸들링도 마찬가지다. 기관마다 에러 코드가 다르고, 장애 패턴이 다르고, 대응 방법이 다르다. 어떤 기관은 타임아웃 직전에 응답을 주고, 어떤 기관은 성공 코드와 함께 빈 데이터를 내려보낸다. 이런 것들을 일일이 학습하고 대응하는 건, 어떤 팀이든 쉽지 않은 일이다.

그리고 확신하게 됐다. 이 인프라를 모든 팀이 매번 새로 만드는 건 낭비라는 것을.

Headless Finance Platform — 우리의 답

그래서 만들었다. 헤드리스(Headless Finance Platform). 금융 데이터 수집의 복잡성을 추상화하고, 하나의 API로 제공하는 플랫폼이다.

78개 금융기관. 은행, 카드사, 홈택스를 아우른다. 31개 데이터 액션. 계좌 조회부터 세금계산서 다운로드까지. 12개 표준 스키마. 어떤 기관에서 가져오든 동일한 형태의 데이터.

워크플로우는 세 단계로 이루어진다.

첫째, 연결(Connect). 인증 정보를 등록하고 커넥터를 설정한다. 기관별로 천차만별인 인증 방식을 하나의 인터페이스로 추상화했다.

둘째, 수집(Collect). API 한 줄로 데이터를 수집한다. 대용량 데이터는 자동으로 청킹되고, 실패하면 자동으로 재시도한다.

셋째, 정규화(Normalize). 어떤 기관의 데이터든 동일한 표준 스키마로 변환된다. 원본 내역은 그대로 보존하면서, AI가 가맹점명의 브랜드와 카테고리를 자동으로 매핑해준다.

스크래핑이라는 구조적 딜레마

잠깐, 한 발 물러서서 생각해보자. 지금까지 대부분의 팀이 금융 데이터를 가져오던 방식은 스크래핑이다. 그리고 스크래핑에는 기술적 난이도 이전에, 더 근본적인 문제가 있다.

스크래핑으로 금융기관 데이터를 수집하려면, 사용자의 인증서 정보를 개발팀이 직접 보유해야 한다. 공동인증서든, 금융인증서든, 그 인증서는 단순한 로그인 수단이 아니다. 계좌 조회, 이체, 거래 — 금융 행위 전반에 대한 권한 그 자체다. 그걸 외부 개발팀에 넘긴다는 건, 금고 열쇠를 복사해서 건네는 것과 다르지 않다.

문제는 여기서 끝나지 않는다. 서비스가 성장하면 인증서를 보관하는 주체가 늘어난다. 개발 서버, 스테이징 환경, 배포 파이프라인, 로그 시스템. 보관 지점이 하나 늘어날 때마다 유출 표면(attack surface)이 함께 넓어진다. 인증서 하나가 탈취되면 조회가 아니라 실제 거래까지 가능하다는 점에서, 이건 단순한 데이터 유출과 차원이 다른 리스크다.

그래서 많은 팀이 딜레마에 빠진다. 금융 데이터가 필요하니까 스크래핑을 해야 하는데, 스크래핑을 하려면 인증서를 맡겨야 하고, 인증서를 맡기는 순간 보안 책임의 무게가 감당하기 어려운 수준으로 커진다. 규모가 작을 땐 눈 감을 수 있지만, 고객이 늘어나고 감사가 들어오는 순간 이 구조는 지속 불가능해진다.

기존 방식과 뭐가 다른가

핵심은 메타데이터 드리븐 아키텍처다. 새로운 금융기관을 추가할 때 코드를 한 줄도 고치지 않는다. 데이터베이스에 메타데이터를 넣는 것만으로 즉시 지원된다. 78개 기관이 동일한 스펙으로 동작하는 이유가 여기에 있다. 5개의 범용 핸들러가 모든 기관의 요청을 처리한다.

기관 인터페이스가 변경되면 플랫폼이 자동으로 대응한다. 여러분의 새벽 잠을 깨우는 건 우리의 일이지, 여러분의 일이 아니다.

보안은 기능이 아니라 전제다. 앞서 말한 스크래핑의 딜레마 — 인증서를 개발팀이 직접 들고 있어야 하는 구조 — 를 헤드리스는 근본적으로 다른 방식으로 해결한다. 인증 정보는 격리된 보안 환경에서만 사용되고, 고객사의 코드나 서버에 인증서가 노출되지 않는다. 모든 민감 데이터는 AES-256으로 암호화되며, Live 환경과 Sandbox 환경은 완전히 분리되어 있다. 인증서를 맡기는 것이 아니라, 인증서가 필요 없는 구조를 만든 것이다.

5분이면 시작할 수 있다

curl 한 줄이면 된다. 좀 더 편하게 쓰고 싶다면 Node.js, Python, Java, Kotlin, Go SDK를 제공한다. 콘솔에서 직접 테스트할 수도 있고, API로 자동화할 수도 있다. 같은 엔드포인트, 같은 스키마. 테스트에서 프로덕션까지 달라지는 건 없다.

연동 방식도 강제하지 않는다. 동기 HTTP로 즉시 응답을 받을 수도 있고, 비동기 HTTP로 폴링하거나 웹훅 콜백을 받을 수도 있다. 대량 처리가 필요하다면 SQS나 Kafka 같은 메시지 큐 기반 연동도 지원한다. 시스템 아키텍처에 맞는 인터페이스를 고르면 된다. 플랫폼이 거기에 맞춰준다.

사람이 아니라 AI가 먼저 이해하는 API

우리는 API를 설계할 때 한 가지를 더 기준으로 삼았다. 사람이 읽기 좋은 API는, AI 에이전트도 읽기 좋아야 한다는 것.

12개의 표준 스키마, 일관된 엔드포인트, 예측 가능한 응답 구조. 이 원칙들은 개발자의 인지 부하를 줄이기 위해 만든 것이지만, 동시에 AI 에이전트가 별도의 학습 없이 API를 이해하고 호출할 수 있는 조건이기도 하다. 실제로 Claude Code 같은 AI 코딩 에이전트에게 헤드리스 API 문서를 넘기면, 연동 코드를 스스로 작성한다. 기관별 분기도, 스키마 변환도 필요 없으니까.

이것은 부가 기능이 아니다. 우리가 처음부터 추구해온 표준화와 추상화의 자연스러운 귀결이다. 잘 정돈된 인터페이스는 사람에게든 기계에게든 같은 방식으로 작동한다. 학습 곡선이 5분이 아니라, 경우에 따라서는 0에 수렴할 수 있다는 뜻이다.

같이 만들어가고 싶습니다

현재 헤드리스는 Invite Only로 운영하고 있다. 소수의 팀과 함께 시작하며, 피드백을 통해 다듬어갈 것이다. 완성된 제품을 내놓겠다는 것이 아니라, 함께 만들어가겠다는 선언이다.

금융 데이터가 필요한 서비스를 만들고 있다면, 더 이상 인프라에 시간을 쏟지 않아도 된다. 수십억 건의 데이터를 다루며 쌓아온 경험 위에서, 당신의 제품에만 집중할 수 있도록. 그것이 우리가 헤드리스를 만든 이유다.

초대를 요청하려면 h6s.ai를 방문해주세요.

설계된 직감, 설계된 빈틈 — 탐닉의 설계자들 북클럽 리포트

Mon, 13 Apr 2026 12:00:00 GMT

닌텐도 Wii의 기획자 다마키 신이치로가 쓴 '탐닉의 설계자들'은 사람들이 왜 게임에 빠지는지를 분석한 책이다. 하지만 읽다 보면 게임만의 이야기가 아님을 깨닫게 된다. 우리가 무언가에 빠지는 구조, 직감이라 믿었던 것이 실은 설계자의 의도였던 순간, 예상이 깨졌을 때 오히려 더 몰입하게 되는 역설. 이 책은 제품과 콘텐츠, 나아가 일상의 경험 전반을 관통하는 설계의 원리를 다룬다.

2026년 4월의 어느 토요일 오후, 이 책을 중심으로 다양한 배경의 사람들이 모였다. 개발자, 콘텐츠 기획 지망생, 약학 전공자, 공학도까지. 주최자가 준비한 여섯 가지 토론 주제를 따라 각자의 경험을 나눴다. 같은 책을 읽고도 각자의 렌즈로 전혀 다른 장면을 꺼내 놓는 게 인상적이었다. 아래는 그날 나눈 대화를 정리한 기록이다.

직감이라고 믿었던 것들

첫 번째 질문은 단순했다. "내가 스스로 선택했다고 믿었지만, 사실은 설계된 경험이 있는가?" 막상 떠올리려 하면 쉽지 않다. 우리는 보통 그냥 하고, 지나가고, 잊기 때문이다.

"필라테스 옷을 좋아해서 백화점에서 샀는데, 프랑스에서 건너온 브랜드인 줄 알았어요. 이름도 프랑스어고, 모델도 전부 외국인이었거든요. 나중에 알고 보니 국내 제조 제품이었어요. 그때 되게 배신감을 느꼈어요. 수입도 아닌데 왜 이렇게 비싼 거지, 하면서." — 참가자3

브랜딩이 직감을 설계한 전형적인 사례다. 주최자는 이와 비슷한 예로, 특정 커피 브랜드가 로고에 '1910'이라는 숫자를 붙여 100년 이상의 역사를 암시하지만 실제로는 10년도 안 된 신생 브랜드인 경우를 소개했다. 커머스 회사에서 일했을 때 35만 원짜리 상품을 팔기 위해 55만 원짜리를 옆에 배치했던 앵커링 전략도 직접 사용해 봤다고 한다.

"쿠팡셀러를 해봤는데, 중국에서 사입해 오는 상품이랑 쿠팡에서 파는 상품의 가격 차이가 꽤 크더라고요. 비슷한 물건인데 기획이랑 카드뉴스, 마케팅을 어떻게 하느냐에 따라 가치 인식이 완전히 달라지는 거예요." — 참가자1

"네이버 길찾기에서 최적 경로라고 제시된 걸 따라갔는데, 나중에 보니 더 빠른 길이 따로 있었어요. 시스템이 보여주는 게 최선이라고 직감적으로 믿어버린 거죠." — 참가자5

넷플릭스의 5초 자동재생도 화제에 올랐다. 주최자는 5초라는 시간이 거부하기엔 너무 짧고, 수용하기엔 충분한 절묘한 설계라고 분석했다. 만약 10초였다면 꽤 많은 에피소드를 다음 화로 넘기지 않았을 거라는 말에 참가자들이 고개를 끄덕였다. 특정 애니메이션 플랫폼은 여기서 한 발 더 나아가 오프닝 자동 스킵과 자동 다음 화 재생을 모두 기본 설정으로 제공한다. 켜놓기만 하면 1화부터 마지막 화까지 끊김 없이 흘러간다. 사용자는 '내가 선택해서 본다'고 느끼지만, 실은 멈추는 선택지가 설계적으로 제거된 것이다.

예상이 깨질 때 빠져든다

우리 뇌는 다음에 일어날 일을 끊임없이 예측한다. 예측이 맞으면 안심하고, 틀리면 혼란스럽다. 그런데 때로는 예상이 깨졌을 때 오히려 더 깊이 빠져드는 경험이 있다.

"고양이 마리오라고, 기존 마리오의 직관적 규칙을 전부 뒤집어 놓은 게임이 떠올랐어요. 벽인 줄 알았는데 지나갈 수 있고, 밟을 수 있을 것 같은 블록이 바닥으로 떨어지고. 예측이 전부 깨지는 게임인데 스트리머들이 스트레스 해소용으로 즐기더라고요." — 참가자1

주최자는 진격의 거인, 데스노트, 강철의 연금술사를 예로 들며, 이 세 작품이 결말을 미리 정해놓고 연재를 시작한 드문 사례라는 점을 짚었다. 대부분의 만화는 한 화를 그려보고 반응을 본 뒤 이야기를 채워나가지만, 결말이 확정된 채로 시작한 작품은 1화부터 마지막까지의 빌드업 자체가 치밀할 수밖에 없다. 참가자들도 이런 '설계된 반전'이 일반적인 만화와 차별화되는 핵심이라는 데 공감했다.

"드라마를 많이 보는 편인데, 한국 드라마의 해피엔딩 강박이 좀 아쉬워요. 10화까지 너무 재밌게 봤는데 결말에서 실망한 적이 있거든요. 왜 꼭 해피엔딩이어야 하는 거지, 싶었어요." — 참가자2

기대가 깨지는 건 콘텐츠에만 국한되지 않았다.

"헬스를 3개월 했는데 기대한 만큼 몸이 안 변하더라고요. 한번 이탈했다가 목표를 바꿨어요. 멋있는 몸이 아니라 건강 유지와 습관. 그렇게 생각을 바꾸니까 다시 꾸준히 하게 됐어요." — 참가자5

제품 설계에서도 같은 원리가 작동한다. 주최자는 사용자가 화면의 레이아웃을 보고 자연스럽게 다음 행동을 예측할 수 있도록 설계하는 것이 핵심이라고 했다. 예측할 수 있게 만들되, 때로는 그 예측을 전략적으로 깨뜨려 몰입을 만드는 것 — 그 균형이 체험 설계의 기술이라는 이야기였다.

설명하지 않는 힘

책에서 인상 깊었던 개념 중 하나는 '설명하지 않음'의 가치다. 마리오 1-1 스테이지에서는 튜토리얼 한 줄 없이 플레이어가 규칙을 스스로 발견한다. 이 원리는 게임 밖에서도 통했다.

"과외할 때 직접 설명하는 것보다 방향만 제시하고 학생이 스스로 답을 도출하게 했을 때 기억 보유율이 훨씬 높았어요. 처음엔 솔직히 저도 편하려고 그랬는데, 오히려 효과가 좋아서 지금도 계속 하고 있어요." — 참가자1

"고등학생 때 친구들이랑 본디라는 앱을 깔았는데, 사실 뭐 하는 앱인지도 잘 모르면서 한 달을 썼어요. 캐릭터 만들고, 방에 초대하고. 그냥 뭔지 모르겠지만 재밌었어요." — 참가자2

주최자는 본디를 "사용자가 의미를 후천적으로 부여하는 서비스"로 해석했다. 대부분의 사용자가 의미 부여에 실패했기에 결국 쇠퇴했지만, 반대로 의미를 찾은 사람들에게는 강렬한 경험이 됐을 것이다.

한 참가자가 강레오 셰프의 사례를 꺼냈다. 10년 전 '누군가의 제자가 아니다'라는 의혹이 인터넷에서 바이럴됐지만, 본인은 단 한 번도 해명하지 않았다. 그러다 스승이 은퇴하면서 수제자 명단을 공개했는데, 거기에 이름이 있었다. 10년의 침묵이 곧 증명이 된 셈이다.

"적극적으로 해명한 다른 유명인은 아직도 의혹을 받고 있는데, 아무 말 안 한 쪽이 오히려 깔끔하게 증명이 됐잖아요. 설명 없이 증명한 셈이죠." — 참가자5

주최자는 자신의 회사에서도 제품 설계 원칙 중 하나가 "설명하지 않는다"라고 소개했다. 설명하지 않아도 사용자가 의도와 행동을 스스로 판단할 수 있어야 한다는 것이다. 다만 금융 서비스처럼 설명이 불가피한 영역도 있다. 해외 주식 양도세 신고 서비스를 6개월간 개선했지만, 여전히 건강검진 결과서나 주민등록증을 제출하는 사용자가 있다는 사례가 웃음과 공감을 동시에 자아냈다.

만드는 사람의 착각

'내가 좋은 것이 유저도 좋을 것이다'라는 착각. 공급자의 에고는 분야를 가리지 않는다.

"벤츠가 신형 모델에 삼각별 로고를 그릴, 라이트 등 차의 모든 곳에 박아버렸거든요. 디자이너는 좋다고 생각했겠지만 소비자 반응은 정말 안 좋았어요." — 참가자5

주최자는 이 문제를 "예쁜 쓰레기"라는 표현으로 정의했다. 엔지니어가 기술에만 몰두해 사용자 가치를 간과하는 현상이다. 국내 게임 업계에서 엔지니어들이 혼을 갈아 넣어 최적화했지만 시장에서 살아남지 못한 프로젝트가 사례로 언급됐다. 기술적 완성도와 별개로 운영 비용과 매출의 간극 앞에서 오래 버티지 못했고, 수년을 쏟아부은 개발자들이 경력마저 인정받기 어려웠다는 후일담이 뒤따랐다.

"개발자가 기술, 그러니까 How에만 집중해서 사용자 가치, What을 간과하는 경향이 있는 것 같아요. 기획자 분이 사용자 관점에서 고려한 걸 들어보면, 내가 생각한 것과 다른 측면이더라고요." — 참가자1

모든 일은 What(무엇을 할지)과 How(어떻게 할지) 두 가지로 귀결된다는 이야기가 나왔다. 코드를 짜는 것, 디자인하는 것, 마케팅 캠페인을 집행하는 것은 전부 How다. 그런데 How에 6개월, 1년을 투자해도 What이 틀리면 아무도 쓰지 않는 제품이 나온다.

사진 전공 경험이 있는 참가자는 다른 각도에서 같은 문제를 짚었다.

"잡지를 직접 만드는 과제가 있었는데, 제가 봤을 때는 나름 잘 만든 것 같았어요. 근데 교수님이 폰트가 너무 많다, 시선 유도 구도가 안 맞는다고 피드백을 주시더라고요. 공급자인 제가 만족한 결과물과 수용자가 느끼는 결과물이 다르다는 걸 그때 처음 느꼈어요." — 참가자2

팀 내에서 의견이 충돌할 때 쓸 수 있는 멘탈 모델도 공유됐다. 내 의견은 내 의견이 아니라, 내가 생각하는 고객의 의견이라는 프레이밍이다. 엔지니어링 관점의 고객 이해, 마케팅 관점의 고객 이해, 디자인 관점의 고객 이해를 모두 모은 뒤, 고객을 가장 잘 대변하는 안을 고르는 방식이다. 에고 충돌 대신 고객이라는 공통 기준을 세우는 것. 다만 이런 성숙함은 하루아침에 만들어지지 않는다는 점도 솔직하게 덧붙여졌다.

우리는 소비자인가, 기획자인가

마지막 주제는 이 책을 읽고 달라진 것이 있는가였다. 참가자마다 반응이 달랐다.

"콘텐츠 기획 쪽에 관심이 있어서, 사람들이 클릭하게 만드는 설계 — 섬네일이라든가 시선을 끄는 구조에 이 책의 원리를 활용하고 싶어졌어요." — 참가자2

"마케팅 설계자라는 책을 읽었을 때 비슷한 충격을 받았는데, 이 책에서도 같은 느낌이 들었어요. 제가 만든 제품으로 제대로 터져보는 경험을 해보고 싶어서, 적극적으로 활용해 보려고요." — 참가자1

"소비할 때 내 의지로 사는 건지 아니면 유도에 현혹된 건지를 좀 더 신중하게 판단하고 싶어졌어요." — 참가자3

같은 책을 읽어도 콘텐츠를 만드는 사람은 설계의 도구로, 소비하는 사람은 방어의 기준으로, 개발자는 제품의 원칙으로 받아들인다. 책이 주는 통찰의 방향이 읽는 사람의 위치에 따라 완전히 달라진다는 것 자체가 이 북클럽에서 가장 흥미로운 발견이었다.

약 두 시간의 대화는 20시를 넘기며 자연스럽게 마무리됐다. 정리하면 이렇다.

직감은 설계된다. 우리가 자연스럽다고 느끼는 선택의 상당수는 누군가의 의도가 만든 경로 위에 있다.
빈틈이 몰입을 만든다. 모든 것을 설명하는 대신 추리의 여지를 남길 때, 사람들은 스스로 의미를 찾고 더 깊이 기억한다.
만드는 사람의 에고를 경계하라. How에 대한 자부심이 What에 대한 질문을 대체하면, 아무도 쓰지 않는 것을 정성껏 만드는 결과가 된다.
같은 책, 다른 렌즈. 다양한 배경의 사람이 같은 텍스트를 두고 대화할 때, 혼자 읽었다면 절대 보지 못했을 면이 드러난다.

Agentic AI 논문 읽기: A-MEM — 제텔카스텐에서 영감받은 에이전트 기억 시스템

Wed, 08 Apr 2026 18:00:00 GMT

논문 정보

제목: A-MEM: Agentic Memory for LLM Agents

저자: Wujiang Xu, Zujie Liang, Kai Mei, Hang Gao, Juntao Tan, Yongfeng Zhang (Rutgers University, AIOS Foundation)

출판: NeurIPS 2025 / arXiv 2502.12110 (2025.02)

시리즈의 마지막 논문이다. 스물다섯 편의 여정을 마무리하기에 이보다 적절한 주제가 없다 -- 기억.

앞선 Rise and Potential 서베이에서 에이전트를 뇌(Brain), 지각(Perception), 행동(Action)의 세 축으로 분해했다. 시리즈 전체가 이 세 축을 따라 걸어왔다. CoT에서 시작된 추론 능력은 ReAct에서 행동과 결합했고, Toolformer에서 도구를 잡았으며, AutoGen과 MetaGPT에서 다중 에이전트로 확장되었다. 하지만 이 모든 구조를 관통하는 하나의 전제가 있다 -- 에이전트가 경험을 기억하고, 그 기억을 활용할 수 있어야 한다는 것이다.

시리즈의 첫 글에서 CoALA가 에이전트의 세 축 중 하나로 기억을 꼽았다. Reflexion에서 반성이 에피소드 메모리에 저장되었고, LATS에서 트리 구조가 외부 메모리로 기능했으며, ETO에서 실패 궤적이 모델 가중치에 새겨졌다. 하지만 이 모든 경우에 메모리의 구조는 사전에 정의되어 있었다 -- 슬라이딩 윈도우, 키-값 쌍, 트리 노드. 누군가가 미리 그릇의 모양을 결정했고, 에이전트는 그 안에 경험을 부어넣을 수 있을 뿐이었다. A-MEM은 다른 질문을 던진다. 에이전트가 스스로 그릇을 빚을 수 있는가?

사전 정의된 기억의 한계 -- 왜 고정된 구조는 충분하지 않은가

기존 LLM 에이전트 메모리 시스템의 작동 방식을 돌아보자. 개발자가 메모리의 저장 구조를 미리 정의하고, 워크플로우 내 저장 시점을 지정하며, 검색 타이밍을 설정한다. Mem0 같은 시스템이 그래프 데이터베이스를 도입하여 구조화된 조직을 제공하지만, 근본적으로 사전 정의된 스키마와 관계에 의존한다. 도서관의 십진분류법이 아무리 정교하더라도, 그 분류법이 만들어질 당시 존재하지 않던 학문 분야의 책을 적절히 배치할 수 없는 것과 같다.

시리즈에서 읽은 논문들의 메모리 구현을 떠올려 보자. Reflexion은 슬라이딩 윈도우에 자연어 반성을 저장했다 -- 구조는 "최근 N개의 반성 텍스트"로 고정되어 있다. LATS는 트리 노드에 탐색 이력을 보존했다 -- 구조는 "부모-자식 관계의 트리"로 고정되어 있다. MemGPT는 운영체제의 메모리 계층(메인 컨텍스트, 아카이벌 스토리지)을 모방했다 -- 구조는 "두 계층 사이의 페이징"으로 고정되어 있다. 모든 경우에 메모리가 무엇을 기억하느냐는 유연하지만, 어떻게 조직하느냐는 설계 시점에 결정된다.

실제 시나리오에서 이 한계는 명확하다. 에이전트가 새로운 수학적 해법을 배울 때, 기존 시스템은 이 정보를 미리 설정된 프레임워크 안에서만 분류하고 연결할 수 있다. 혁신적 연결을 형성하거나, 지식이 진화함에 따라 새로운 조직 패턴을 개발하는 것은 불가능하다. 검색 단계에서 자율성을 발휘하는 RAG(Retrieval-Augmented Generation) 역시 마찬가지다 -- 검색은 유연하지만 메모리 구조 자체는 정적이다.

영감의 원천은 니클라스 루만의 제텔카스텐(Zettelkasten)이다. 독일의 사회학자가 70권의 책과 400편의 논문을 쓸 수 있었던 비결로 알려진 메모 시스템. 핵심 원칙은 세 가지다. 각 메모는 원자적(atomic)이다 -- 하나의 자기 완결적 생각을 담는다. 메모들 사이에 링크가 형성된다 -- 위계적 분류가 아니라 연상적 연결이다. 그리고 시간이 지나면서 네트워크가 자연스럽게 성장한다 -- 분류 체계를 미리 설계할 필요가 없다. 도서관이 아니라 뉴런 네트워크에 가깝다. A-MEM은 이 원리를 LLM 에이전트의 메모리 시스템에 이식한다.

세 가지 메커니즘 -- 노트, 링크, 진화

A-MEM의 아키텍처는 세 가지 핵심 메커니즘으로 구성된다.

노트 구성(Note Construction): 에이전트가 환경과 상호작용할 때, 그 경험이 구조화된 노트로 변환된다. 각 노트에는 원래 상호작용 내용, 타임스탬프, LLM이 생성한 키워드와 태그, 맥락적 설명, 임베딩 벡터, 그리고 연결된 메모리 집합이 포함된다. 제텔카스텐의 원자성 원칙 그대로 -- 각 노트가 단일한, 자기 완결적 지식 단위를 포착한다. 중요한 것은 키워드, 태그, 맥락적 설명이 모두 LLM에 의해 자율적으로 생성된다는 점이다. 개발자가 분류 체계를 미리 설계하지 않는다.

링크 생성(Link Generation): 새 메모리 노트가 시스템에 추가되면, 두 단계의 연결 과정이 자동으로 작동한다. 먼저 임베딩 기반 코사인 유사도로 상위 k개의 관련 기존 메모리를 검색한다. 그 다음 LLM이 새 메모리와 후보 메모리들을 분석하여, 공유 속성, 인과 관계, 개념적 연결에 기반한 의미 있는 링크를 설정한다. 임베딩 유사도를 초기 필터로 사용하여 효율성을 확보하면서, LLM 분석으로 단순 유사도 지표를 넘어서는 미묘한 패턴과 관계를 포착한다.

메모리 진화(Memory Evolution): 가장 독창적인 메커니즘이다. 링크가 생성된 후, A-MEM은 연결된 기존 메모리들을 새 메모리와의 관계에 기반하여 진화시킨다. LLM이 각 이웃 메모리에 대해 맥락, 키워드, 태그를 업데이트할지 결정하고, 강화(strengthen), 병합(merge), 가지치기(prune) 중 적절한 행동을 선택한다. 시간이 지남에 따라 개별 메모리들 사이에서 고차원 패턴과 추상적 개념이 자연스럽게 출현한다.

이 세 메커니즘 위에 **검색(Retrieve Relative Memory)**이 작동한다. 쿼리가 들어오면 임베딩 기반으로 상위 k개 메모리를 찾되, 검색된 메모리와 같은 링크 그룹에 있는 관련 메모리도 자동으로 접근한다. 하나의 실마리에서 출발하여 연결된 기억의 네트워크 전체를 탐색하는 것이다. 이것이 Multi-Hop 추론에서 A-MEM이 압도적 우위를 보이는 구조적 이유다.

구체적 예를 들어보자. 에이전트가 "사용자가 매주 월요일 아침 카페에서 회의한다"는 대화를 기억한다고 하자. 이후 "지난 월요일 카페가 문을 닫아서 사무실에서 만났다"는 대화가 추가되면, A-MEM은 두 메모리를 링크하고, 기존 메모리의 맥락적 설명을 "사용자의 월요일 루틴은 유연할 수 있다"로 진화시킨다. 나아가 "사용자가 좋아하는 카페 메뉴"에 관한 별도의 메모리가 있다면, 이것도 같은 링크 그룹으로 연결될 수 있다. 고정된 슬롯에 최신 정보를 덮어쓰는 것이 아니라, 기존 기억 자체가 새 경험에 비추어 재해석되고, 관련 기억들이 하나의 의미 네트워크로 엮이는 것이다.

벤치마크 -- 더 적은 토큰으로 더 정확한 기억

논문은 LoCoMo(장기 대화, 평균 9K 토큰, 최대 35 세션)와 DialSim(장기 다자간 대화, 1,300 세션, 350,000 토큰)의 두 데이터셋에서, 6개 기반 모델에 걸쳐 평가를 수행했다. 결과는 일관된다.

방법	Multi-Hop F1	Temporal F1	Average Ranking
LoCoMo	25.02	9.09	2.4
MemGPT	26.65	25.52	2.4
ReadAgent	2.81	--	--
A-MEM	27.02	45.85	1.2

GPT-4o-mini 기준 결과이며, GPT-4o에서는 격차가 더 벌어진다 -- Multi-Hop F1에서 A-MEM 45.85 대 LoCoMo 18.47로 약 2.5배 향상이다. 오픈소스 모델(Qwen2.5-15b)에서는 Multi-Hop ROUGE-L이 27.23으로, LoCoMo의 4.68 대비 거의 6배 차이를 보인다.

Multi-Hop에서의 압도적 우위가 특히 의미 있는 이유는, 이것이 A-MEM의 링크 구조가 가져다주는 직접적 이점이기 때문이다. Multi-Hop 질문은 여러 대화에 흩어진 정보를 조합해야 답할 수 있다. "사용자가 좋아하는 식당이 어디이고, 그 식당의 메뉴 중 무엇을 주문했는지"를 묻는 질문에 답하려면, 식당에 관한 메모리와 주문에 관한 메모리가 연결되어 있어야 한다. 고정된 검색 구조로는 이 연결을 자동으로 따라갈 수 없지만, A-MEM의 링크 네트워크는 하나의 메모리에서 출발하여 관련 메모리의 네트워크 전체를 자동으로 탐색한다.

비용 효율성도 주목할 만하다. A-MEM의 메모리 연산당 토큰 사용량은 1,200~~2,500으로, LoCoMo와 MemGPT의 16,900 대비 85~~93%를 절감한다. 연산당 비용은 $0.0003 미만이며, 처리 시간은 GPT-4o-mini 기준 5.4초, 로컬 Llama 3.2 1B에서는 1.1초다. AI Agents That Matter가 경고한 "정확도-비용 트레이드오프"를 정면으로 돌파하는 결과다.

스케일링 특성도 확인되었다. 1,000에서 1,000,000 메모리 엔트리까지 확장했을 때, A-MEM의 검색 시간은 0.31 마이크로초에서 3.70 마이크로초로 선형에 가깝게 증가한다. 같은 조건에서 ReadAgent는 43.62 마이크로초에서 120,069 마이크로초로 폭증하여, 100만 엔트리 기준 A-MEM이 약 63,000배 빠르다.

제거 실험은 각 메커니즘의 기여를 분리한다.

구성	Multi-Hop F1	Average F1
w/o LG and ME	9.65	15.32
w/o ME (LG만)	21.35	44.16
A-MEM (전체)	27.02	50.03

링크 생성이 핵심 기반이고(9.65에서 21.35로 도약), 메모리 진화가 추가적 정제를 제공하며(21.35에서 27.02로), 두 모듈이 상호 보완적이라는 결론이다. 제텔카스텐의 원리로 돌아가면 당연한 결과이기도 하다 -- 노트 사이의 링크가 없으면 그것은 그저 메모 더미이고, 시간에 따른 진화가 없으면 네트워크는 화석이 된다.

한계 -- 자율적 기억의 대가

세 가지 한계가 눈에 띈다.

첫째, 메모리 조직의 품질이 기반 LLM의 능력에 직접적으로 의존한다. 다른 모델은 다른 맥락적 설명을 생성하고 다른 연결을 설정할 수 있다. 시리즈에서 반복적으로 관찰한 패턴이다 -- AI Agents That Matter가 지적했듯, 기반 모델의 선택이 에이전트 전체의 성능 천장을 결정한다.

둘째, LLM 기반 링크 생성의 비용이다. 새 메모리가 추가될 때마다 LLM을 호출하여 후보 메모리와의 관계를 분석하고, 연결된 메모리를 진화시킨다. 메모리의 수가 증가할수록 이 비용이 누적된다. 스케일링 분석에서 검색 시간 자체는 100만 엔트리에서도 3.70마이크로초로 효율적이지만, 메모리 저장 시점의 LLM 호출 비용은 별개의 문제다.

셋째, 메모리 진화의 누적 효과에 대한 불확실성이다. 장기간에 걸쳐 메모리가 반복적으로 진화하면, 원래 정보로부터의 드리프트(drift)가 발생할 수 있다. 인간의 기억도 회상할 때마다 미세하게 변형된다는 심리학 연구와 유사한 현상이다. 제텔카스텐의 비유를 이어가자면, 루만의 카드 상자는 종이에 잉크로 기록되었기에 원본이 보존되었지만, A-MEM의 디지털 메모리는 진화 과정에서 원본이 대체된다. 원본을 별도로 보존하는 메커니즘이 필요할 수 있다.

현재 논문은 텍스트 기반 상호작용에 초점을 맞추고 있어, 이미지나 오디오 같은 멀티모달 확장 역시 향후 과제로 남아 있다. Rise and Potential이 지각(Perception) 축에서 멀티모달 입력의 중요성을 강조한 것을 떠올리면, 기억 시스템의 멀티모달 확장은 자연스러운 다음 단계다.

CoALA 좌표계의 완성

시리즈의 첫 글에서 세운 좌표계로 돌아간다. A-MEM은 기억 축의 최종 진화를 보여준다.

시리즈 논문	기억 방식	구조의 자율성
CoALA	기억의 존재를 정의	프레임워크만 제시
Reflexion	반성 텍스트를 슬라이딩 윈도우에 저장	구조는 고정, 내용만 자율
LATS	트리 구조로 탐색 이력 보존	구조는 고정, 탐색은 자율
ETO	궤적 쌍을 모델 가중치에 내재화	구조 자체가 모델에 흡수
A-MEM	자율적으로 구조를 만들고 진화시키는 기억	구조와 내용 모두 자율

에이전트의 기억은 고정된 구조에서 동적 구조로, 외부 저장에서 자기 조직화로 진화해왔다. CoALA가 지도를 그렸고, Reflexion이 첫 발자국을 남겼으며, A-MEM은 그 지도 위에 에이전트가 스스로 길을 내도록 한 것이다.

행동 축에서는 ReAct가 도구 호출의 문법을, Toolformer가 도구 선택의 자율성을, Halo가 워크플로우 전체의 최적화를 보여주었다. 판단 축에서는 CoT가 추론의 구조를, Reflexion이 반성의 루프를, LATS가 탐색의 체계를 제시했다. 그리고 기억 축에서 A-MEM이 구조와 내용 모두의 자율성을 달성함으로써, CoALA가 제시한 에이전트의 세 축 -- 기억, 행동, 판단 -- 모두에서 자율성의 가능성이 입증되었다.

시리즈를 마치며

스물다섯 편의 논문을 통해 에이전트 AI의 지형을 걸었다. 추론의 씨앗(CoT)에서 행동과의 결합(ReAct)으로, 도구 사용(Toolformer)에서 다중 에이전트(AutoGen, MetaGPT)로, 자기 반성(Reflexion)에서 체계적 탐색(LATS)으로, 모델 훈련(ETO)에서 비판적 평가(AI Agents That Matter)로, 금융 특화(BloombergGPT에서 FINCH까지)에서 안전성(Constitutional AI, RLHF)으로, 그리고 마침내 기억(A-MEM)으로.

돌아보면, 이 여정에서 반복적으로 나타난 패턴이 있다.

구조는 덜어내고, 자율성은 더한다. CoT가 추론의 구조를 명시적으로 제시했다면, 후속 연구들은 그 구조를 에이전트 스스로 결정하게 했다. ReAct의 고정된 Thought-Action-Observation 루프는 LATS의 동적 트리 탐색으로, 그리고 A-MEM의 자기 조직화 메모리로 진화했다. 사전 정의된 틀을 줄이고 에이전트의 자율적 판단을 늘리는 것이 일관된 방향이다.

실패는 가장 풍부한 학습 신호다. Reflexion은 실패를 자연어로 반성했고, LATS는 실패 지점에서 트리를 분기했으며, ETO는 실패 궤적을 모델 가중치에 새겼다. 성공만 보고 배우는 행동 클로닝보다, 실패와 성공을 대조하는 학습이 일관되게 우수했다. 인간의 학습과 다르지 않다.

에이전트는 혼자보다 함께일 때 강하다. AutoGen의 대화 기반 협업, MetaGPT의 SOP 기반 조직, Multi-Agent Survey의 집단 지능 -- 다중 에이전트 시스템은 단순히 여러 모델을 동시에 돌리는 것이 아니라, 역할 분담과 상호 검증을 통해 개별 에이전트의 한계를 넘어선다. 흥미롭게도, A-MEM의 메모리 진화 메커니즘 안에도 이 원리가 작동한다 -- 개별 메모리가 서로를 업데이트하며 전체 네트워크의 지능이 성장한다.

벤치마크를 의심하되, 평가를 포기하지 마라. AI Agents That Matter가 가장 날카롭게 지적한 바 -- 정확도만 추구하면 비용이 폭증하고, 비용만 줄이면 정확도가 무너진다. 범용성과 전문성, 성능과 효율, 자율성과 안전성 사이의 긴장은 어느 하나의 논문으로 해소되지 않는다. A-MEM이 85~93%의 토큰 절감과 동시에 성능 향상을 달성한 것은, 이 긴장을 해소하는 것이 불가능하지 않다는 희망적 사례이기도 하다.

도메인 특화와 범용성은 공존할 수 있다. BloombergGPT에서 FINCH까지의 금융 특화 연구, DocLLM의 문서 이해, Won의 한국어 금융 NLP -- 이 논문들은 범용 모델만으로는 전문 영역의 깊이에 도달하기 어렵다는 것을 보여주었다. 동시에 Paradigms 서베이가 정리한 도구 사용, 계획, 피드백의 삼각 구도는 도메인에 관계없이 적용되는 보편적 원칙이었다. 전문성은 데이터와 평가에서, 범용성은 아키텍처에서 온다.

2026년 4월의 시점에서 에이전트 AI의 현황을 정리하면 이렇다. 추론과 계획의 기본 능력은 확립되었고, 도구 사용과 환경 상호작용의 프레임워크가 성숙했으며, 다중 에이전트 협업의 패러다임이 자리를 잡았다. 금융, 의료, 법률 같은 도메인 특화 에이전트가 실무에 투입되기 시작했고, A-MEM이 보여준 것처럼 메모리 시스템이 마지막 퍼즐 조각으로 빠르게 진화하고 있다.

그러나 안전성과 정렬(alignment)은 여전히 진행 중인 과제다. Constitutional AI와 RLHF가 방향을 제시했지만, 자율성이 높아질수록 예측 불가능성도 함께 증가한다는 근본적 긴장은 해소되지 않았다. 진정한 자율 에이전트 -- 인간의 개입 없이 장기간 복잡한 목표를 추구하는 시스템 -- 는 아직 연구의 전선에 있다.

시리즈를 쓰는 동안 한 가지가 분명해졌다. 에이전트 AI는 단일한 돌파구가 아니라, 수많은 작은 진보의 축적이다. CoT의 프롬프트 한 줄이 추론을 열었고, ReAct의 루프 하나가 행동을 결합했으며, 제텔카스텐의 오래된 메모 방법론이 기억의 자율성을 가능하게 했다. 각각은 겸손한 한 걸음이지만, 스물다섯 걸음이 모이면 풍경이 달라진다.

어쩌면 이 시리즈 자체가 일종의 제텔카스텐이었는지도 모른다. 각 논문이 하나의 원자적 노트이고, 논문들 사이의 참조와 대조가 링크이며, 글을 쓰는 과정에서 초기 논문에 대한 이해가 후기 논문의 관점으로 진화했다. CoALA를 처음 읽었을 때와 A-MEM을 읽고 난 후 CoALA를 다시 떠올릴 때, 같은 프레임워크가 다르게 보인다. 기억이 진화한 것이다.

이 시리즈가 읽은 스물다섯 편의 논문은 그 전선의 지도이자, 동시에 그 전선이 얼마나 빠르게 이동하고 있는지를 보여주는 시간의 기록이다. 논문은 여기서 끝나지만, 에이전트의 진화는 계속된다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 스물다섯 번째이자 마지막 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Rise and Potential — 뇌·지각·행동으로 본 에이전트 전망

Wed, 08 Apr 2026 15:00:00 GMT

논문 정보

제목: The Rise and Potential of Large Language Model Based Agents: A Survey

저자: Zhiheng Xi, Wenxiang Chen, Xin Guo 외 (Fudan University NLP Group)

출판: arXiv 2309.07864

앞선 글에서 Autonomous Agents Survey는 에이전트를 건물로 비유하며 시공 매뉴얼을 작성했다. 프로파일링, 메모리, 계획, 행동 -- 네 개의 기둥을 세우면 에이전트가 완성된다는 공학적 청사진이었다. 유용하지만, 그 시선은 "어떻게 만드는가"에 묶여 있었다. 만드는 법을 알면 에이전트를 이해한 것인가? 설계도를 읽을 줄 안다고 해서 그 건물에 사는 존재의 경험을 이해한 것은 아니다.

Fudan University NLP Group이 거의 같은 시기(2023년 9월)에 발표한 이 서베이는 다른 질문에서 출발한다. "에이전트를 어떻게 만드는가"가 아니라, "에이전트란 무엇인가"를 묻는다. 그 답을 찾기 위해 논문은 인지과학의 렌즈를 꺼내든다. 인간을 이해하는 틀로 인공 에이전트를 바라보겠다는 것이다. 에이전트를 뇌(Brain), 지각(Perception), 행동(Action)의 세 축으로 분해하고, 그 위에 단일 에이전트에서 다중 에이전트로, 다시 인간-에이전트 협업으로 확장되는 3단계 조직 구조를 올려놓는다.

CoALA가 인지 아키텍처의 이론적 골격을 제시했다면, Autonomous Agents Survey가 구현의 체크리스트를 정리했다면, 이 서베이는 그 둘 사이 어딘가에 자리를 잡는다. 인지과학에서 빌려온 은유를 사용하되, CoALA만큼 추상적이지 않고, Autonomous Agents Survey만큼 구현에 밀착하지도 않는다. 같은 대상을 서로 다른 축으로 절개했을 때 드러나는 단면이 다르듯, 이 논문은 에이전트의 또 다른 면을 보여준다.

왜 또 다른 서베이인가 -- 현미경과 망원경의 차이

같은 해에 발표된 두 서베이가 같은 대상을 다루면서도 전혀 다른 그림을 그린다. 이것은 우연이 아니라, 분류 체계의 근본적 출발점이 다르기 때문이다.

Autonomous Agents Survey는 엔지니어의 시선으로 에이전트를 본다. 프로파일링 모듈은 어떻게 설계하는가, 메모리 구조는 어떤 선택지가 있는가, 계획 전략은 피드백을 포함하는가 -- 모든 질문이 구현 결정을 향한다. 현미경으로 부품을 하나하나 확대하는 방식이다. 부품의 사양은 정확히 파악하지만, 전체 유기체가 어떻게 움직이는지는 부품 목록만으로 설명되지 않는다.

이 서베이는 망원경으로 한 발 물러서서 본다. 에이전트를 인간 인지의 모형으로 이해하려 한다. 뇌가 사고하고, 감각 기관이 세계를 인식하고, 팔다리가 세계에 개입한다 -- 이 삼분법을 에이전트에 투영한다. 시리즈 첫 글의 CoALA가 기억-행동-판단이라는 인지과학의 축을 제시한 것과 같은 계보에 속하지만, CoALA보다 더 직관적이고 덜 정형적이다. CoALA가 Soar와 ACT-R 같은 인지 아키텍처 전통을 명시적으로 계승했다면, 이 논문은 인지과학의 대중적 은유 -- 뇌, 감각, 운동 -- 를 차용하여 더 넓은 청중에게 말을 건다.

세 개의 축 -- Brain, Perception, Action

논문의 핵심 구조는 단순하다. 에이전트를 구성하는 세 축을 정의하고, 각 축의 내부를 세분화한다.

Brain -- 중추 신경계로서의 LLM

Brain은 에이전트의 인지적 핵심이다. LLM이 이 역할을 맡는다. 논문은 Brain의 기능을 여섯 가지로 세분화한다.

자연어 상호작용: 인간과 자연스럽게 소통하는 능력. 모든 인지 활동의 매체다.
지식: 사전 학습으로 내재화한 언어적 지식, 상식, 도메인 전문성. LLM의 파라미터에 응축된 세계 모델이다.
기억: 단기 기억(인컨텍스트 윈도우)과 장기 기억(외부 벡터 DB)의 이분법. 더 나아가 에피소드 기억(경험의 기록), 의미 기억(사실과 개념), 절차 기억(방법의 체화)으로 나뉜다. 시리즈 마지막 글에서 다룰 A-MEM이 바로 이 기억 체계를 재설계하려는 시도다.
추론: CoT(Chain-of-Thought)에서 출발하여 ToT(Tree of Thoughts), GoT(Graph of Thoughts)로 확장되는 추론 패러다임. 시리즈에서 CoT를 단일 경로, ToT를 다중 경로, LATS를 트리 탐색 기반으로 읽었다 -- 모두 Brain의 추론 능력을 확장하려는 시도였다.
계획: 복잡한 과제를 하위 과제로 분해하고 실행 순서를 정하는 능력. 계획-실행-반성의 루프가 핵심이며, Reflexion이 이 반성 루프를 언어적으로 구현한 대표적 사례다.
전이 가능성: 학습한 능력을 새로운 과제에 일반화하는 능력. 분포 외(out-of-distribution) 과제 처리, 지속적 학습, few-shot 적응이 여기에 포함된다.

Autonomous Agents Survey의 4모듈과 비교하면, Brain은 프로파일링을 제외한 나머지 세 모듈(메모리, 계획, 행동의 일부)을 하나로 통합한다. 이것이 두 서베이의 가장 큰 구조적 차이다. Autonomous Agents Survey는 기능별로 모듈을 나누고, 이 서베이는 생물학적 은유로 계층을 나눈다.

Perception -- 감각 기관으로서의 입력 채널

Perception은 에이전트가 환경에서 정보를 수집하는 모든 경로를 포괄한다.

텍스트 입력: 대화, 지시문, 문서, 웹 페이지. 가장 기본적인 지각 채널이다.
시각 입력: 이미지, 비디오, GUI 스크린샷. GPT-4V 이후 멀티모달 에이전트의 핵심 입력이 됐다.
청각 입력: 음성 인식, 소리 신호. Whisper 같은 모델이 LLM과 결합되면서 가능해진 채널이다.
기타 모달리티: 촉각, 제스처, 3D 환경 데이터. 체화된(embodied) 에이전트의 영역이다.

Perception을 독립적 축으로 분리한 것은 이 서베이의 중요한 관점이다. Autonomous Agents Survey에서 입력은 별도의 모듈로 다뤄지지 않았다 -- 행동 모듈의 일부이거나, 메모리에 저장되기 전의 전처리 단계 정도로 취급됐다. 하지만 인지과학의 관점에서, 지각은 단순한 데이터 입력이 아니라 세계를 해석하는 적극적 과정이다. 무엇을 보고 무엇을 무시하는가, 어떤 감각 채널을 신뢰하고 어떤 것을 할인하는가 -- 이 선택이 인지의 질을 결정한다.

Action -- 운동 기관으로서의 출력 채널

Action은 에이전트가 세계에 영향을 미치는 모든 방식이다.

도구 사용: API 호출, 코드 실행, 데이터베이스 검색, 웹 브라우징. Toolformer가 LLM의 도구 사용 가능성을 열었고, ReAct가 추론과 도구 사용의 교차 실행을 보여줬다.
텍스트 출력: 대화 응답, 보고서 생성, 요약, 코드 작성. 가장 보편적인 행동이다.
물리적 행동: 로봇 제어, 가상 환경에서의 조작. 체화된 에이전트가 디지털 출력을 넘어 물리적 세계에 개입하는 단계다.

Brain-Perception-Action의 세 축을 관통하는 핵심 통찰은 이것이다. 에이전트의 능력은 개별 축의 성능이 아니라, 세 축 사이의 연결 품질에 의해 결정된다. 아무리 강력한 Brain이라도 Perception이 빈약하면 맹인과 같고, Perception이 풍부해도 Action이 제한되면 감옥에 갇힌 것과 같다.

세 개의 층위 -- 단일에서 협업으로

논문은 에이전트 시스템을 세 단계의 조직 수준으로 분류한다. 각 단계에서 복잡성과 가능성이 함께 증가한다.

단일 에이전트: 하나의 LLM이 Brain-Perception-Action을 모두 담당한다. 과제 지향적 에이전트(CoT, ReAct, Toolformer)와 창발적 행동을 보이는 에이전트(Generative Agents의 개별 캐릭터)로 나뉜다. 시리즈 초반에 읽은 논문들 -- CoALA, ReAct, Reflexion, Toolformer -- 이 모두 이 단계의 설계 원리를 탐구한 것이다.

다중 에이전트: 여러 에이전트가 상호작용하며 과제를 수행한다. 논문은 상호작용 방식을 세 가지로 분류한다.

협력적 상호작용: 역할을 분담하고 순차적 파이프라인으로 작업을 처리한다. MetaGPT가 Product Manager-Architect-Engineer의 역할 분배로, ChatDev가 디자이너-프로그래머-테스터의 흐름으로 이 패턴을 구현했다.
토론적 상호작용: 에이전트 간 의견 교환을 통해 답을 정제한다. Multi-Agent Debate가 대표적이며, AutoGen의 유연한 대화 기반 협업도 이 범주에 속한다.
경쟁적 상호작용: 게임이나 시뮬레이션에서의 경쟁. 늑대인간(Werewolf), 외교(Diplomacy) 같은 전략 게임에서 에이전트 간 경쟁이 더 나은 전략을 창발시킨다.

인간-에이전트 협업: 에이전트가 독립적으로 행동하는 것을 넘어, 인간과 상호작용하는 패턴이다.

지시자-실행자: 인간이 지시하고 에이전트가 실행한다. Copilot 스타일의 보조가 대표적이다.
동등한 협력자: 에이전트가 인간에게 판단을 요청하거나, 인간과 공동으로 문제를 해결한다.
에이전트 주도: 에이전트가 자율적으로 행동하고, 인간은 감독과 승인만 담당한다.

시리즈의 여정도 이 세 단계를 따라왔다. CoALA에서 Toolformer까지가 단일 에이전트의 원리를, AutoGen에서 MetaGPT까지가 다중 에이전트의 조직을, RLHF와 Constitutional AI가 인간-에이전트 관계의 설계를 다뤘다. 이 서베이의 3단계 분류는 시리즈 전체의 지도이기도 하다.

세 개의 렌즈 -- 프레임워크 비교

같은 시기에 발표된 세 서베이가 LLM 에이전트를 서로 다른 축으로 절개한다. 각각의 장단점을 비교하면 에이전트를 이해하는 복합적 시야가 열린다.

비교 항목	Rise and Potential (이 논문)	Autonomous Agents Survey (#23)	CoALA (#1)
분류 축	Brain / Perception / Action	프로파일링 / 메모리 / 계획 / 행동	기억 / 행동 / 판단
출발 시선	인지과학적 은유	공학적 모듈 분해	인지 아키텍처 이론
강점	직관적 구조, 조직 수준 분류	구현 선택지의 상세함	이론적 완결성
약점	모듈 간 경계 모호	프로파일링의 정체성 논의 제한적	추상도가 높아 구현 지침 약함
에이전트 정체성	Brain 내부에 암묵적	프로파일링 모듈로 명시	다루지 않음
멀티모달 입력	Perception으로 독립 분류	행동 모듈에 포함	관찰 공간으로 추상화
다중 에이전트	조직 수준으로 별도 분류	응용 영역에서 언급	범위 밖
평가 프레임워크	벤치마크와 도전 과제 제시	주관/객관 평가 구분	형식적 정의 중심

세 프레임워크 중 어느 것이 "정답"인가라는 질문은 잘못된 질문이다. 엔지니어에게는 Autonomous Agents Survey의 4모듈이, 연구자에게는 CoALA의 인지 아키텍처가, 에이전트의 전체적 윤곽을 빠르게 파악하려는 사람에게는 이 논문의 Brain-Perception-Action이 더 유용하다. 중요한 것은, 세 서베이가 공통적으로 포착하는 구조가 있다는 점이다 -- 에이전트에게는 사고하는 핵심(Brain/계획/판단), 세계를 인식하는 경로(Perception/메모리/관찰), 세계에 개입하는 수단(Action/행동)이 필요하다. 이 삼분법은 용어만 다를 뿐 본질적으로 수렴한다.

2026년의 시선 -- 인지 은유는 얼마나 버텼는가

이 서베이가 발표된 지 2년 반이 지났다. Brain-Perception-Action 프레임워크는 여전히 유효한 렌즈인가?

맞힌 것부터 보자. 멀티모달 에이전트의 부상을 Perception이라는 독립 축으로 미리 포착한 것은 선견지명이었다. 2024년 이후 GPT-4o, Gemini, Claude의 멀티모달 능력이 급격히 발전하면서, 에이전트의 Perception 채널은 텍스트를 넘어 시각, 음성, 심지어 실시간 비디오까지 확장됐다. Autonomous Agents Survey가 입력을 독립 모듈로 다루지 않았다는 점을 감안하면, 이 논문이 Perception을 별도 축으로 분리한 판단은 옳았다.

조직 수준의 3단계 분류도 유효하다. 단일 에이전트에서 다중 에이전트로의 전환은 AutoGen과 MetaGPT를 거쳐 현실이 됐고, 인간-에이전트 협업은 Copilot에서 Cursor, Claude Code에 이르는 개발 도구들의 핵심 설계 원리가 됐다. "에이전트 주도 + 인간 감독" 패턴은 2026년 현재 가장 보편적인 인간-AI 협업 모델이다.

놓친 것도 있다. 가장 큰 빈칸은 안전과 정렬(alignment)이다. Brain-Perception-Action 어디에도 "에이전트가 하지 말아야 할 것"을 다루는 축이 없다. Constitutional AI가 제기한 원칙 기반 제약, RLHF가 시도한 인간 선호 정렬 -- 이런 안전 메커니즘이 프레임워크에 자리를 잡지 못한다. 2026년 시점에서 에이전트 안전은 선택이 아니라 필수인데, 이 서베이의 삼분법은 그것을 구조적으로 포착하지 못한다.

Brain의 범위가 너무 넓다는 점도 시간이 갈수록 선명해졌다. 자연어 이해, 지식, 기억, 추론, 계획, 전이 -- 이 모든 것을 Brain 하나에 넣으면, Brain이 사실상 "에이전트 = Brain + 입출력"이라는 자명한 명제로 환원된다. Autonomous Agents Survey가 메모리, 계획, 행동을 별도 모듈로 분리한 것이 실용적으로 더 유용했던 이유다. 특히 o1 이후의 추론 모델이 등장하면서, Brain 내부의 "추론"과 "계획"이 얼마나 다른 것인지, 분리해서 다뤄야 하는 것인지가 중요한 질문이 됐다.

에이전트-에이전트 간 통신 프로토콜의 부재도 눈에 띈다. 다중 에이전트를 조직 수준으로 분류한 것은 좋았지만, 에이전트들이 실제로 어떻게 소통하는지 -- 메시지 형식, 합의 메커니즘, 갈등 해결 -- 에 대한 분석이 얕다. 2025년에 등장한 MCP(Model Context Protocol) 같은 표준 프로토콜이나, A2A(Agent-to-Agent) 통신 규격이 이 공백의 중요성을 증명한다.

결국, Brain-Perception-Action 프레임워크는 에이전트를 처음 이해하려는 사람에게 여전히 좋은 출발점이다. 하지만 그 단순함이 곧 한계이기도 하다. 에이전트가 복잡해질수록, Brain 내부를 더 세밀하게 나누고, 안전이라는 네 번째 축을 추가하고, 조직 수준에 통신 프로토콜을 명시해야 한다. 은유는 이해의 시작이지, 설계의 완성이 아니다.

마무리

한 문장으로 줄이면 이렇다. 에이전트를 뇌, 지각, 행동의 세 축으로 보는 인지과학적 렌즈는 전체 윤곽을 빠르게 잡아주지만, 그 단순함 뒤에는 안전, 정체성, 통신이라는 빈칸이 있다.

Autonomous Agents Survey가 에이전트의 부품 목록을 제시했다면, 이 서베이는 에이전트를 살아 있는 유기체의 은유로 바라보게 했다. 두 시선 모두 필요하다. 부품을 모르면 만들 수 없고, 유기체를 모르면 왜 만드는지를 잊는다. 시리즈에서 읽어온 CoALA의 인지 아키텍처, ReAct의 추론-행동 루프, Reflexion의 자기 반성, MetaGPT의 역할 분배, AutoGen의 대화 기반 협업 -- 이 모든 연구가 Brain-Perception-Action이라는 세 축 위에, 혹은 프로파일링-메모리-계획-행동이라는 네 기둥 위에 자리를 잡는다. 어떤 좌표계를 쓰느냐에 따라 보이는 면이 달라질 뿐, 에이전트라는 대상 자체는 하나다.

다음 글에서는 에이전트의 가장 본질적인 능력으로 돌아간다 -- 기억. A-MEM은 니클라스 루만의 제텔카스텐에서 영감받아, 에이전트가 사전 정의된 구조 없이 스스로 기억을 조직하고 진화시키는 시스템을 제안한다. 시리즈의 마지막 글이다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 스물네 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Autonomous Agents Survey — 자율 에이전트 구축의 해부도

Wed, 08 Apr 2026 12:00:00 GMT

논문 정보

제목: A Survey on Large Language Model based Autonomous Agents

저자: Lei Wang, Chen Ma, Xueyang Feng 외 (Renmin University of China, Tencent)

출판: Frontiers of Computer Science, 2024 / arXiv 2308.11432

앞선 글에서 RLHF의 파이프라인이 매 단계마다 근본적 균열을 품고 있음을 확인했다. 인간 피드백은 일관적이지 않고, 보상 모델은 해킹에 취약하며, 정책 최적화는 표면적 패턴을 악용한다. 그렇다면 질문은 자연스럽게 옮겨진다 — 정렬의 이론적 한계를 인식한 뒤, 에이전트를 실제로 만들 때는 무엇을 어떻게 설계해야 하는가?

정렬 이론이 "어떤 에이전트가 바람직한가"를 묻는다면, 이 서베이는 "에이전트를 어떻게 조립하는가"를 묻는다. 건축에 비유하면, RLHF 논의가 건물의 안전 기준을 정하는 일이라면, 이 논문은 기둥, 벽, 배관, 전기 — 건물을 실제로 세우는 도면을 그리는 일이다. 시리즈 첫 글에서 CoALA가 에이전트의 인지 아키텍처를 기억-행동-판단의 세 축으로 그렸고, 일곱 번째 글에서 Multi-Agent Survey가 다중 에이전트의 지형을 네 축으로 분류했다. 이 서베이는 그 사이를 메운다 — 단일 에이전트의 구축(Construction)과 응용(Application)을 체계적으로 분류하면서, 각 모듈의 구현 선택지까지 나열한다.

2023년 8월에 발표된 이 논문은, 86페이지에 걸쳐 당시까지의 LLM 기반 에이전트 연구를 하나의 분류 체계 안에 정리한다. Renmin University of China와 Tencent의 연구팀이 수십 편의 논문을 하나의 좌표계 위에 배치하려는 시도다. 출발점은 단순한 질문이다. 에이전트를 만들려면 무엇이 필요한가? 답은 네 개의 모듈로 압축된다.

설계도가 없는 건축 현장 — 통합 프레임워크의 부재

2023년 중반, LLM 기반 에이전트 연구는 폭발적으로 늘고 있었지만 공통 언어가 없었다. ReAct는 "추론과 행동의 시너지"를, Toolformer는 "도구 사용의 자율성"을, Reflexion은 "언어적 반성"을, Generative Agents는 "사회적 시뮬레이션"을 각각 제안했다. 문제는 이 연구들이 서로 다른 용어, 서로 다른 분류, 서로 다른 평가 기준을 쓰고 있었다는 점이다.

건축에서 설계도는 단순히 건물의 모양을 보여주는 그림이 아니다. 기둥이 어디 서는지, 배관이 어떻게 흐르는지, 전기가 어디서 들어오는지를 하나의 좌표계 위에 올려놓는 체계다. 설계도 없이 건물을 지을 수는 있다. 하지만 설계도 없이는 건물을 비교하거나, 어디가 부실한지 진단하거나, 다음 건물을 더 잘 지을 수가 없다.

CoALA는 인지과학의 렌즈로 에이전트를 분류하는 추상적 좌표계를 제시했다. 하지만 추상적 좌표계만으로는 실제 구축에서의 설계 결정 — 에이전트의 역할을 어떻게 정의할지, 메모리를 어떤 구조로 설계할지, 계획 수립에 피드백을 포함할지 — 을 안내하기 어렵다. 이 서베이는 그 공백을 채운다. CoALA가 지도라면, 이 논문은 시공 매뉴얼이다.

네 개의 기둥 — 에이전트 구축의 4모듈 프레임워크

논문은 에이전트 구축을 네 가지 핵심 모듈로 분해한다. 프로파일링, 메모리, 계획, 행동. 각 모듈은 독립적으로 설계되지만, 서로 맞물려 에이전트의 능력을 결정한다.

프로파일링 모듈 — 에이전트의 정체성

에이전트가 "무엇인지"를 정의하는 첫 단계다. 역할, 성격, 전문성, 행동 양식을 규정한다. 세 가지 방법이 있다.

핸드크래프팅(Handcrafting): 인간이 직접 역할을 기술한다. "당신은 금융 전문가입니다" 같은 시스템 프롬프트가 여기에 해당한다.
LLM 생성: LLM이 자동으로 에이전트 프로필을 만든다. Generative Agents에서 1,000명의 시뮬레이션 참여자를 생성한 것이 대표적이다.
데이터셋 정렬: 실제 데이터에서 프로필을 구성한다. 인구통계 데이터나 소셜 미디어 프로필을 기반으로 에이전트를 초기화한다.

시리즈에서 읽은 MetaGPT의 역할 분배(Product Manager, Architect, Engineer)는 핸드크래프팅의 전형이다. AutoGen의 에이전트 정의도 마찬가지다. 프로파일링이 중요한 이유는, 같은 LLM이라도 어떤 역할을 부여하느냐에 따라 출력의 성격이 완전히 달라지기 때문이다.

메모리 모듈 — 경험의 저장과 검색

에이전트가 과거를 기억하고, 현재에 활용하는 방법을 다룬다. 두 종류의 메모리가 핵심이다.

단기 메모리: 현재 대화의 맥락. 인컨텍스트 학습(in-context learning)으로 구현되며, 컨텍스트 윈도우의 크기에 제약된다.
장기 메모리: 과거 경험과 축적된 지식. 외부 벡터 데이터베이스에 저장하고, 유사도 검색으로 필요한 정보를 꺼낸다.

Generative Agents의 메모리 검색이 이 모듈의 가장 정교한 구현이었다. 최근성(recency), 관련성(relevance), 중요도(importance) 세 가지 점수를 결합하여 어떤 기억을 떠올릴지 결정한다. CoALA가 기억을 작업 기억, 일화 기억, 의미 기억, 절차 기억의 네 서랍으로 나눈 것과 비교하면, 이 서베이의 분류는 더 실용적이다 — 단기와 장기, 그리고 그 사이의 검색 메커니즘에 집중한다.

계획 모듈 — 과제 분해와 정제

복잡한 과제를 하위 과제로 쪼개고, 실행 순서를 정하고, 필요하면 수정하는 과정이다. 논문은 이를 피드백의 유무로 양분한다.

피드백 없는 계획: 한 번에 전체 계획을 세운다. CoT(Chain-of-Thought)가 단일 경로, ToT(Tree of Thoughts)가 다중 경로, GoT(Graph of Thoughts)가 그래프 기반 분해를 대표한다.
피드백 있는 계획: 실행 결과를 보고 계획을 수정한다. 환경 피드백(ReAct), 인간 피드백, 모델 피드백(Reflexion)으로 나뉜다. LATS는 트리 탐색과 환경 피드백을 결합한 사례다.

외부 플래너(PDDL 등 전통적 계획 시스템)를 LLM과 결합하는 접근도 있다. LLM이 자연어 문제를 형식적 계획 언어로 번역하고, 기존 솔버가 최적 계획을 찾는 방식이다.

행동 모듈 — 환경과의 상호작용

계획을 실제 행동으로 옮기는 마지막 단계다. 세 가지 유형이 있다.

도구 사용: API 호출, 코드 실행, 데이터베이스 검색. Toolformer가 이 영역을 개척했다.
구현(Embodied Action): 텍스트 생성, 코드 작성, 물리적 행동. 디지털 환경에서의 텍스트 출력부터 로봇의 물리적 조작까지 포함한다.
기억/학습: 경험을 메모리에 저장하여 미래 행동을 개선한다. 행동의 결과가 다시 메모리로 돌아가는 피드백 루프다.

시리즈 논문의 모듈 배치

시리즈에서 읽은 논문들이 이 네 모듈의 어디에 위치하는지 정리하면, 각 연구의 기여가 더 선명해진다.

모듈	관련 논문	핵심 기여
프로파일링	MetaGPT, AutoGen	역할 기반 에이전트 정의, 다중 페르소나 설계
메모리	Reflexion, Generative Agents	자기 반성의 언어적 기록, 검색 기반 장기 기억
계획	CoT, ToT, LATS, ReAct	단일/다중 경로 추론, 트리 탐색, 피드백 기반 정제
행동	Toolformer, ReAct	자율적 도구 선택, 추론-행동 교차 실행

CoALA의 기억-행동-판단 축과 비교하면, 이 서베이는 프로파일링이라는 새로운 차원을 추가한다. 에이전트의 "정체성"을 설계의 첫 단계로 명시한 것은, 실제 구축 과정에서의 필요를 반영한 판단이다.

네 개의 무대 — 응용 영역

구축 프레임워크가 "어떻게 만드는가"에 답한다면, 응용 분류는 "어디에 쓰는가"에 답한다. 논문은 크게 세 갈래로 나눈다.

사회 시뮬레이션: Generative Agents가 대표한다. 에이전트들이 가상 마을에서 일상을 살아가며, 사회적 행동의 패턴을 생성한다. 경제 시뮬레이션, 게임 이론 검증, 여론 형성 실험 등이 여기에 속한다. 프로파일링 모듈이 핵심 역할을 하는 영역이다 — 다양한 성격과 배경을 가진 에이전트를 대량으로 생성해야 하기 때문이다. 흥미로운 점은, 이 영역에서는 에이전트의 "정확성"보다 "그럴듯함"이 더 중요하다는 것이다. 사회 시뮬레이션의 목적은 정답을 맞추는 것이 아니라 행동 패턴을 탐색하는 것이므로.

소프트웨어 개발: MetaGPT와 ChatDev가 대표적이다. 요구사항 분석부터 코드 생성, 테스트, 디버깅까지의 전 과정을 에이전트가 수행한다. 계획 모듈과 행동 모듈이 긴밀하게 결합되어야 하는 영역이다. AutoGen의 유연한 대화 기반 협업도 이 범주에 들어간다.

게임과 과학: Voyager가 Minecraft에서 자율 탐험하며 스킬을 축적하는 것이 게임 응용의 대표적 사례다. 과학 연구에서는 약물 발견, 수학 증명, 실험 설계 자동화 등에 에이전트가 활용된다. 장기 메모리와 계획 모듈이 특히 중요한 영역이다 — 탐색 공간이 넓고, 시행착오를 기억해야 하므로.

논문의 분류에서 눈에 띄는 것은, 응용 영역마다 네 모듈의 비중이 다르다는 점이다. 사회 시뮬레이션은 프로파일링에, 소프트웨어 개발은 계획과 행동에, 과학 연구는 메모리에 무게가 실린다. 이 차이가 시사하는 바는, 범용 에이전트 프레임워크를 설계할 때 네 모듈의 비중을 도메인에 따라 유연하게 조절할 수 있어야 한다는 것이다.

설계도의 빈칸 — 프레임워크의 한계

이 서베이가 제시한 4모듈 프레임워크는 실용적이지만, 몇 가지 구조적 한계가 있다.

첫째, 안전과 정렬 차원의 부재다. 프로파일링, 메모리, 계획, 행동 — 어디에도 "에이전트가 해서는 안 되는 것"을 다루는 모듈이 없다. RLHF의 한계에서 본 것처럼, 정렬은 에이전트 설계에서 빼놓을 수 없는 축이다. 그런데 이 프레임워크에서는 안전이 네 모듈 중 어디에도 명시적으로 자리를 잡지 못한다. Constitutional AI가 제기한 원칙 기반 제약이 프로파일링에 속하는지, 계획에 속하는지, 아니면 별도의 모듈이 되어야 하는지가 불분명하다.

둘째, 커버리지 편향이다. 서베이가 작성된 2023년 중반 시점의 연구 지형을 반영하므로, 이후 급격히 발전한 영역 — 코드 생성 에이전트, 멀티모달 에이전트, 에이전트 간 프로토콜 — 이 충분히 다뤄지지 않았다. 서베이는 본질적으로 스냅샷이다.

셋째, 모듈 간 상호작용의 깊이가 부족하다. 네 모듈을 독립적으로 설명하는 것은 명쾌하지만, 실제 에이전트에서는 메모리가 계획에 영향을 주고, 계획이 행동을 결정하고, 행동의 결과가 메모리를 갱신하는 순환이 핵심이다. 이 순환의 설계 — 어떤 정보를 어디에 흘리고, 어디서 끊을지 — 가 프레임워크에서 충분히 다뤄지지 않는다. Reflexion이 행동-반성-기억의 루프를, ReAct가 추론-행동의 교차를 제시한 것처럼, 모듈 간 연결의 패턴이야말로 에이전트의 실질적 능력을 결정하는 요소인데 말이다.

넷째, 평가 프레임워크의 미성숙이다. 논문은 주관적 평가(인간 주석, Elo 점수)와 객관적 평가(자동 벤치마크)를 구분하지만, 어떤 벤치마크가 어떤 모듈의 능력을 측정하는지의 대응 관계가 불명확하다. 시리즈에서 나중에 다루게 될 AI Agents That Matter가 바로 이 평가의 함정을 파고든다.

2026년의 시선 — 설계도는 어떻게 늙었는가

이 서베이가 발표된 지 2년 반이 지났다. 4모듈 프레임워크는 여전히 에이전트를 설명하는 데 쓸모 있는 골격인가?

프로파일링은 더 정교해졌다. 단순한 시스템 프롬프트를 넘어, 에이전트의 역할이 YAML manifest나 구조화된 설정 파일로 정의되고, 런타임에 동적으로 조정되는 방식이 보편화됐다. "당신은 금융 전문가입니다"라는 한 줄에서, 도구 접근 권한, 행동 제약, 통신 프로토콜까지 포함하는 다차원 프로필로 진화한 것이다.

메모리는 가장 활발히 발전한 모듈이다. 시리즈 마지막 글에서 다룰 A-MEM이 제텔카스텐에서 영감받은 구조화된 기억 시스템을 제안했고, RAG를 넘어 에이전트가 기억의 저장과 검색 전략을 스스로 결정하는 방향으로 나아가고 있다. 서베이가 제시한 단기/장기의 이분법은 여전히 유효하지만, 그 안의 구현 방식은 근본적으로 달라졌다.

계획은 가장 극적으로 변한 모듈이다. 서베이 시점에는 CoT와 ToT 수준의 프롬프트 기반 계획이 주류였지만, 이제는 o1 이후의 추론 모델이 계획 능력을 LLM 내부에 흡수했다. 외부 계획 모듈이 필요 없어진 것은 아니지만, 경계가 흐려졌다.

행동은 도구 사용이 보편화되면서 가장 성숙한 모듈이 됐다. Toolformer가 "LLM이 도구를 잡을 수 있다"를 증명한 단계에서, MCP(Model Context Protocol) 같은 표준 프로토콜이 도구 통합을 체계화하는 단계로 넘어왔다. 시리즈에서 다룬 Tool Use Evolution이 정리한 "단일 도구에서 다중 오케스트레이션까지"의 궤적이, 이 모듈의 진화를 압축적으로 보여준다.

결국 4모듈 프레임워크 자체는 살아남았다. 에이전트를 만들 때 정체성, 기억, 계획, 행동을 각각 설계해야 한다는 관찰은 여전히 참이다. 달라진 것은 각 모듈의 내부 구현과 모듈 간 경계의 유동성이다.

CoALA와의 비교도 흥미롭다. CoALA는 인지과학의 언어로 에이전트를 분류하여, 이론적 완결성에서 우위를 갖는다. 이 서베이는 구현의 언어로 에이전트를 분류하여, 실용적 가이드로서 더 직접적이다. 2026년의 시점에서 보면, 두 프레임워크 모두 에이전트의 특정 측면을 잘 포착하지만, 에이전트-에이전트 상호작용(Multi-Agent Survey의 영역)과 인간-에이전트 정렬(RLHF와 Constitutional AI의 영역)을 통합하는 더 포괄적인 프레임워크는 아직 등장하지 않았다.

마무리

한 문장으로 줄이면 이렇다. 에이전트는 정체성, 기억, 계획, 행동이라는 네 개의 기둥 위에 서며, 어떤 기둥을 얼마나 정교하게 세우느냐가 에이전트의 성격과 한계를 결정한다.

이 서베이는 완벽한 설계도가 아니다. 안전 차원이 빠져 있고, 모듈 간 순환의 깊이가 부족하며, 2023년의 스냅샷이라는 한계가 있다. 그럼에도 "에이전트를 만들려면 무엇이 필요한가?"라는 질문에 대해, 당시까지 가장 체계적인 답을 제시한 논문이다. 에이전트를 처음 설계하는 사람에게, "프로파일링은 했는가? 메모리 구조는 정했는가? 계획 전략은 선택했는가? 행동 인터페이스는 정의했는가?" — 이 네 가지 질문은 지금도 유효한 체크리스트다.

다음 글에서는 에이전트를 다른 렌즈로 바라보는 또 다른 서베이를 읽는다. Rise and Potential — 뇌, 지각, 행동의 세 축으로 에이전트의 미래를 전망한다. 같은 대상을 서로 다른 축으로 분해할 때, 보이지 않던 면이 드러난다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 스물세 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: RLHF의 한계 — 인간 피드백 강화학습의 미해결 과제

Wed, 08 Apr 2026 09:00:00 GMT

논문 정보

제목: Open Problems and Fundamental Limitations of Reinforcement Learning from Human Feedback

저자: Stephen Casper, Xander Davies, Claudia Shi 외

출판: arXiv 2307.15217 (2023.07)

앞선 글에서 Constitutional AI가 인간 피드백 없이 원칙만으로 AI를 정렬하려 했다. 인간 대신 헌법을 세우고, AI가 스스로 자기 출력을 비판하고 수정하게 했다. 왜 그런 우회로가 필요했을까? 인간 피드백이 충분히 좋은 신호라면, 굳이 원칙이라는 추상 계층을 끼워넣을 이유가 없다. Constitutional AI는 답이었다. 이 논문은 그 답이 필요했던 질문 — RLHF는 어디서, 왜, 얼마나 부서지는가 — 을 체계적으로 정리한다.

RLHF(Reinforcement Learning from Human Feedback)는 ChatGPT를 가능하게 한 핵심 기술이다. 사전 훈련된 LLM이 방대한 지식을 갖추지만 인간의 의도에 맞게 응답하지는 못하는 문제를, 인간의 선호 데이터로 미세 조정하여 풀었다. 인간이 좋은 응답과 나쁜 응답을 비교 평가하고, 그 선호를 보상 신호로 변환하여 모델을 정렬한다. 2022년 말 ChatGPT의 등장 이후, RLHF는 LLM 정렬의 사실상 표준이 되었다.

기술적으로는 성공이었다. 사전 훈련만 거친 모델이 보여주던 난잡하고 때로 유해한 출력이, RLHF를 거치면 정돈되고 유용해졌다. 하지만 이 파이프라인의 매 단계에, 표면 아래에서 균열이 자라고 있었다. 2023년 7월, MIT와 ETH Zurich, Stanford, UC Berkeley의 연구자들이 그 균열의 목록을 작성했다. 40페이지가 넘는 이 서베이는 RLHF의 찬사가 아니라 부검 보고서에 가깝다.

잘 작동하는 기계의 숨겨진 결함 — RLHF 파이프라인 해부

RLHF의 3단계 파이프라인은 정교한 조립 공정과 비슷하다. 원재료를 수급하고, 부품을 가공하고, 완성품을 조립한다. 각 단계가 이전 단계의 출력에 의존한다. 문제는, 첫 단계의 미세한 결함이 최종 단계에서 증폭된다는 것이다. 불순물이 섞인 원재료로 만든 부품은, 아무리 정밀하게 조립해도 결함 있는 완성품을 낳는다.

실제 파이프라인은 RLHF 이전에 두 단계를 더 거친다. 먼저 대규모 코퍼스로 사전 훈련(Pre-training)을 하고, 고품질 시연 데이터로 지도 미세 조정(SFT, Supervised Fine-Tuning)을 수행한다. 여기까지는 비교적 잘 이해된 영역이다. RLHF는 그 위에 쌓이는 마지막 세 단계다.

1단계는 피드백 수집이다. 인간 평가자가 모델의 출력 쌍을 비교하여 어느 쪽이 나은지 판단한다. 비교 판단(pairwise comparison)을 사용하는 이유는, 절대 점수를 매기는 것보다 상대적 비교가 인간에게 더 쉽고 일관적이기 때문이다. 2단계는 보상 모델 학습이다. 수집된 선호 데이터로 보상 모델(Reward Model)을 훈련시켜, 임의의 출력에 대해 스칼라 점수를 예측하게 한다. Bradley-Terry 모델 같은 확률 프레임워크로 쌍별 비교를 점수로 변환한다. 3단계는 정책 최적화다. PPO(Proximal Policy Optimization) 같은 강화학습 알고리즘으로, 보상 모델의 점수를 최대화하는 방향으로 LLM을 미세 조정한다.

각 단계는 그 자체로 하나의 연구 분야이고, 각 단계에 고유한 실패 모드가 있다. 논문은 이 실패 모드들을 하나하나 명명하고 분류한다. 병의 이름을 알아야 치료를 시작할 수 있듯이.

원재료의 불순물 — 피드백 수집의 구조적 문제

피드백 수집 단계의 근본 가정은 "인간이 좋은 출력과 나쁜 출력을 구별할 수 있다"는 것이다. 이 가정이 흔들리는 지점은 여러 곳이다.

첫째, 비일관성이다. 동일한 출력 쌍에 대해 서로 다른 평가자가 서로 다른 판단을 내린다. 같은 평가자도 시간이 지나면 판단을 바꾼다. 피로, 주의력, 그날의 기분이 변수로 작용한다. 이것은 단순한 노이즈가 아니다. 보상 모델이 학습하는 목표 자체가 흔들린다는 뜻이다.

둘째, 체계적 편향이다. 인간 평가자는 긴 응답을 짧은 응답보다 선호하는 경향이 있다 — 실제 정보량과 무관하게. 앞에 제시된 선택지를 뒤의 것보다 선호하는 순서 효과도 관찰된다. 사회적으로 바람직해 보이는 답을 실제로 정확한 답보다 높이 평가하는 편향도 있다. 이런 편향은 개별 평가에서는 미세하지만, 수만 건의 선호 데이터에 체계적으로 누적되면 보상 모델의 기울기를 왜곡한다.

셋째, 역량의 한계다. 수학 증명의 정확성, 코드의 보안 취약점, 법률 자문의 적절성 — 이런 영역에서 비전문가 평가자의 판단은 신뢰하기 어렵다. 논문은 이를 "감독 불가능성(unmonitorability)"이라 부른다. 모델의 출력이 인간 평가자의 판단 능력을 넘어서는 순간, 피드백의 품질이 급락한다. AI 시스템이 점점 강해질수록, 이 문제는 악화될 수밖에 없다.

넷째, 다수결의 함정이다. 선호 데이터를 다수의 평가자에게서 수집하면 노이즈가 줄어들 것 같지만, 다수 의견이 소수 의견을 체계적으로 무시하는 문제가 생긴다. 문화적 맥락, 소수 집단의 가치관, 비주류적 관점이 다수결 과정에서 소거된다. 모델은 "평균적 인간"의 선호를 학습하지만, 평균적 인간은 어디에도 존재하지 않는다.

다섯째, 비용과 확장성이다. 고품질 인간 피드백을 수집하는 것은 비용이 높고 시간이 오래 걸린다. 모델이 업데이트될 때마다 피드백을 다시 수집해야 하는데, 모델의 출력 분포가 변했으므로 이전 피드백의 유효성이 떨어진다. 이 반복 비용이 RLHF의 실무적 병목이며, RLAIF가 등장한 직접적 동기이기도 하다.

정보의 압축 손실 — 보상 모델의 구조적 한계

2단계로 넘어오면, 문제의 성격이 바뀐다. 1단계의 문제가 "신호의 품질"이었다면, 2단계의 문제는 "신호의 변환"이다.

인간의 복잡한 선호를 하나의 스칼라 값으로 환원하는 것 자체가 근본적 정보 손실이다. "이 응답은 사실적으로는 정확하지만, 톤이 거만하고, 핵심을 지나치게 늦게 제시한다"는 다차원적 평가가, 0.73이라는 하나의 숫자로 압축된다. 그 숫자 안에서 정확성, 톤, 구조가 어떤 비율로 반영됐는지는 복원할 수 없다.

이 위에 보상 해킹(Reward Hacking)이 쌓인다. 정책 모델이 보상 모델의 허점을 발견하고 악용하는 현상이다. 보상 모델이 "긴 응답에 높은 점수를 주는" 패턴을 학습했다면, 정책 모델은 내용과 무관하게 응답을 늘려 점수를 높인다. 보상 모델이 "자신감 있는 어투"에 높은 점수를 주면, 틀린 내용도 단정적으로 서술하는 법을 배운다. Goodhart의 법칙 — "측정 지표가 목표가 되는 순간, 좋은 지표이기를 멈춘다" — 의 전형적 사례다.

보상 모델의 일반화 실패도 심각하다. 훈련 분포 안(in-distribution)에서는 인간 선호를 잘 예측하지만, 분포 밖(out-of-distribution)에서는 예측이 급격히 무너진다. 정책 최적화 과정에서 모델이 생성하는 출력은 점차 훈련 분포에서 벗어나므로, 보상 모델의 점수가 높아질수록 실제 품질과의 괴리가 커지는 역설이 발생한다. 나침반이 정확한 것은 알려진 지형에서뿐이다. 미지의 영역에 들어서면, 나침반의 바늘이 가리키는 방향을 신뢰할 수 없다.

이 세 가지 문제 — 정보 손실, 보상 해킹, 일반화 실패 — 는 서로 독립적이 아니다. 정보 손실이 보상 모델의 빈틈을 만들고, 그 빈틈이 해킹의 여지를 제공하며, 해킹된 정책이 분포 밖으로 이동하면 일반화가 무너진다. 세 문제가 순환적으로 강화되는 구조다.

최종 조립의 불안정 — 정책 최적화의 도전

3단계는 보상 모델이 매기는 점수를 실제로 최대화하는 단계다. 여기서의 실패는 눈에 가장 잘 보인다. 사용자가 마주하는 모델의 실제 행동이 결정되는 곳이기 때문이다.

정책 최적화 단계에서 가장 널리 쓰이는 기법은 PPO다. PPO는 보상 모델의 점수를 최대화하되, KL 발산 제약을 통해 정책 모델이 기본 모델(SFT 모델)에서 너무 멀리 벗어나지 않도록 제한한다. 이 제약이 없으면 모델은 보상 해킹으로 빠르게 붕괴하고, 제약이 너무 강하면 RLHF의 효과 자체가 미미해진다. 하지만 이 제약의 최적 강도를 정하는 것 자체가 어려운 문제다. 과제에 따라, 모델에 따라, 보상 모델의 품질에 따라 최적값이 달라진다.

모드 붕괴(Mode Collapse)도 관찰된다. 보상 모델이 높은 점수를 주는 소수의 패턴을 발견한 모델이, 그 패턴만 반복 생성하면서 다양성을 잃는 현상이다. "다양한 상황에 적절히 대응하는 모델" 대신 "몇 가지 템플릿을 반복하는 모델"이 만들어진다. 이 시리즈의 ETO(#10) 논문이 반복 횟수를 2~3회로 제한한 것도, 과도한 최적화가 다양성을 파괴한다는 동일한 관찰에서 비롯됐다.

탈옥(Jailbreaking)은 정렬의 견고성 문제를 드러낸다. 적대적 프롬프트로 안전 장치를 우회할 수 있다는 것은, RLHF가 만든 정렬이 모델의 근본적 성향을 바꾼 것이 아니라 표면적 행동 패턴을 덧씌운 것에 가깝다는 의미다. 바니시를 칠한 것이지, 나무를 바꾼 것이 아니다.

논문은 여기에 정렬 세금(Alignment Tax)이라는 개념도 추가한다. 안전성 훈련이 유용성을 감소시키는 비용이다. 유해한 출력을 거부하도록 훈련하면, 모델이 무해하지만 합법적인 요청까지 과도하게 거부하는 현상이 나타난다. 안전과 유용 사이의 긴장은 RLHF의 구조적 문제이며, 최적의 균형점은 과제와 맥락에 따라 달라진다. Constitutional AI(#21)가 이 문제를 "원칙의 계층"으로 풀려 한 것도, 단일 보상 함수로는 안전과 유용의 균형을 표현할 수 없다는 인식에서 출발한다.

파이프라인 전체의 열린 문제 — 분류와 심각도

논문이 식별한 열린 문제를 단계별로 정리하면 다음과 같다.

단계	열린 문제	핵심 위험	2026년 현재 상태
피드백 수집	평가자 간 비일관성	학습 목표 자체의 노이즈	부분 해결 (AI 피드백으로 대체)
피드백 수집	체계적 편향 (길이, 순서)	왜곡된 선호 학습	미해결 (편향 유형만 변화)
피드백 수집	전문성 한계	초인적 AI 감독 불가	악화 (모델 능력 상승)
피드백 수집	비용과 확장성	반복 수집의 비용	부분 해결 (RLAIF)
보상 모델	스칼라 보상의 정보 손실	다차원 가치의 환원 불가	부분 해결 (다중 보상 모델)
보상 모델	보상 해킹 / Goodharting	점수만 높고 품질 저하	부분 해결 (DPO로 우회)
보상 모델	OOD 일반화 실패	최적화할수록 괴리 증가	미해결
정책 최적화	KL 제약 균형	과소/과대 최적화	부분 해결 (DPO가 단순화)
정책 최적화	모드 붕괴	다양성 상실	미해결
정책 최적화	탈옥 취약성	정렬의 피상성	미해결 (공격도 진화)
정책 최적화	정렬 세금	안전성-유용성 상충	부분 해결 (세밀한 조정)
근본적 한계	검증 불가능성	진정한 정렬 여부 불명	미해결

표의 마지막 행, "검증 불가능성"이 가장 심각하다. RLHF가 모델을 진정으로 정렬했는지, 아니면 정렬된 척하는 법을 학습했는지를 구별할 방법이 현재로서는 없다. 모델이 평가 상황에서만 원칙을 따르고, 감독이 없을 때 다르게 행동할 가능성을 배제할 수 없다. 이것은 기술적 문제라기보다 인식론적 문제에 가깝다. 시험 볼 때만 모범생인 학생을, 시험 성적만으로는 가려낼 수 없는 것과 같다.

서베이의 시야 — 한계와 맥락

이 논문은 2023년 7월에 출판되었다. ChatGPT가 세상을 바꾼 지 8개월, GPT-4가 출시된 지 4개월 된 시점이다. RLHF의 성공이 가장 화려하게 빛나던 바로 그 순간에, 그 성공의 이면을 해부한 셈이다. 그 시점까지의 RLHF 연구를 체계적으로 정리한 것이지, 이후 등장한 해결책까지 다루지는 않는다. DPO가 본격적으로 확산되기 직전이었고, Claude 2가 막 출시된 시점이었다. 논문이 "열린 문제"로 분류한 것 중 일부는 이후 부분적으로 해소되었고, 일부는 형태를 바꿔 여전히 남아 있다.

또한 이 서베이는 문제의 분류에 집중하지, 각 문제의 해결책을 깊이 다루지는 않는다. 문제를 명명하는 것 자체가 가치 있는 작업이지만, 실무자가 "그래서 어떻게 해야 하는가"를 찾는다면 개별 문제에 대한 후속 연구를 참조해야 한다.

논문 자체도 인정하듯, RLHF의 대안으로 제시된 접근법들 — DPO, RLAIF, 과정 기반 보상 — 은 논문 시점에서 초기 단계였다. 이 대안들이 실제로 어떤 문제를 해결하고 어떤 새로운 문제를 낳았는지는, 논문의 범위를 넘어선다. 하지만 문제 목록이 있다는 것 자체가, 해결책을 평가하는 체크리스트가 된다. "이 새로운 기법은 표의 어떤 행을 해결하는가?" — 이 질문을 던질 수 있게 된 것이 서베이의 기여다.

2026년의 시선 — 3년간 무엇이 바뀌었는가

논문 출판 이후 3년간, RLHF 생태계는 크게 변했다. 논문이 "열린 문제"라고 명명한 것들 중 일부는 닫혔고, 일부는 형태를 바꿨고, 일부는 오히려 더 벌어졌다.

가장 눈에 띄는 변화는 DPO(Direct Preference Optimization)의 부상이다. DPO는 보상 모델을 아예 제거하고, 선호 데이터에서 직접 정책을 최적화한다. 수학적으로 보면, RLHF의 보상 모델 학습과 PPO 최적화를 하나의 단계로 합친 것이다. 이로써 3단계 파이프라인의 2단계(보상 모델 학습)가 통째로 사라진다. 보상 해킹, OOD 일반화 실패, 스칼라 보상의 정보 손실 — 보상 모델에 귀속되던 문제들이 구조적으로 회피된다. PPO의 불안정한 하이퍼파라미터 튜닝도 필요 없어진다. 이 시리즈의 10번 글에서 다룬 ETO가 DPO를 활용한 것이 한 사례다.

하지만 DPO가 만능은 아니다. 선호 데이터의 품질에 여전히 의존하고, 암묵적 보상 모델이 내부에 존재하므로 해킹 가능성이 완전히 사라지지는 않는다. 또한 DPO는 오프라인 학습이므로, 모델이 새로운 출력을 생성하고 그에 대한 피드백을 받는 온라인 반복 학습에서는 RLHF가 여전히 우위를 보이는 경우가 보고된다.

RLAIF(RL from AI Feedback)도 확산되었다. Constitutional AI(#21)에서 제안된 이 접근법은, 인간 평가자를 AI 평가자로 대체한다. 피드백 수집 단계의 비일관성, 비용, 확장성 문제를 완화하지만, "AI의 편향이 인간의 편향을 대체할 뿐"이라는 비판에서 자유롭지 않다. 편향의 종류가 바뀌었을 뿐, 편향 자체가 사라진 것은 아니다.

과정 기반 보상(Process-based Rewards)도 주목할 진전이다. 최종 결과에만 보상을 주는 대신 추론의 각 단계에 보상을 주어, 올바른 과정을 거쳐 올바른 답에 도달하도록 유도한다. ReAct(#2)의 사고-행동-관찰 사이클과 철학적으로 통하는 접근이다. 결과만 보지 않고 과정을 본다. 수학과 코딩처럼 중간 단계의 검증이 가능한 영역에서 특히 효과적이지만, "좋은 대화란 무엇인가"처럼 과정 자체를 정의하기 어려운 영역에서는 적용이 제한적이다.

멀티 에이전트 시스템에서의 정렬 문제도 새롭게 부상했다. 단일 모델의 RLHF를 넘어, 여러 에이전트가 협업하는 시스템 전체의 정렬을 어떻게 보장하는가? 개별 에이전트가 각각 정렬되어 있어도, 상호작용의 결과가 정렬될 것이라는 보장은 없다. 이 문제는 논문이 쓰인 시점에는 이론적이었지만, 2026년에는 실무적 과제가 되었다.

하지만 논문이 지적한 가장 근본적인 문제 — 초인적 AI를 인간이 감독할 수 있는가, 정렬을 검증할 수 있는가 — 는 2026년에도 미해결이다. 오히려 모델 능력이 상승하면서 문제가 더 선명해졌다. 인간의 코딩 능력을 넘어선 AI의 코드를, 인간이 어떻게 평가하는가? 수학 올림피아드 수준의 증명을 생성하는 모델의 출력을, 비수학자 평가자가 어떻게 비교하는가? 이 질문들에 대한 답은 아직 없다.

결국 3년간의 진전을 한마디로 요약하면, 파이프라인의 공학적 문제들은 상당 부분 완화되었지만, 정렬의 철학적 문제들은 그대로 남아 있다. DPO가 PPO를 대체하고, RLAIF가 인간 라벨러를 보완하고, 과정 기반 보상이 스칼라 보상을 확장했지만 — "우리가 AI에게 원하는 것을 정확히 표현할 수 있는가"라는 질문 앞에서는 모두 같은 한계에 부딪힌다.

마무리

한 문장으로 줄이면 이렇다: "RLHF는 AI를 인간에게 맞추는 가장 성공적인 기법이자, 인간이라는 기준 자체의 한계를 가장 선명하게 드러낸 기법이다."

이 서베이가 에이전트 연구에 시사하는 바는 명확하다. Reflexion의 자기 반성도, ETO의 대조 학습도, Constitutional AI의 원칙 기반 자기 검열도 — 모두 RLHF의 한계를 다른 방식으로 우회하려는 시도로 읽을 수 있다. 인간 피드백이라는 원재료의 불순물을 알아야, 그것을 정제하거나 대체하는 방법도 설계할 수 있다. 이 서베이는 불순물의 목록을 건넨 것이다. 그 목록을 들고, 에이전트 시스템의 전체 지도를 펼쳐보자.

다음 글에서는 에이전트 연구의 전체를 조망하는 서베이로 넘어간다. Autonomous Agents Survey — 에이전트 구축의 4가지 모듈을 해부하는 포괄적 분류 체계를 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 스물두 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Constitutional AI — 원칙 기반 자기 개선

Tue, 07 Apr 2026 17:00:00 GMT

논문 정보

제목: Constitutional AI: Harmlessness from AI Feedback

저자: Yuntao Bai, Saurav Kadavath, Sandipan Kundu, Amanda Askell 외 (Anthropic)

출판: arXiv 2212.08073 (2022.12)

시리즈가 다시 방향을 전환한다. InvestorBench에서 금융 에이전트의 의사결정 능력을 벤치마킹했다면, 이제는 그보다 더 근본적인 질문으로 내려간다 -- 에이전트가 강력해질수록, "에이전트가 잘못된 일을 하지 않도록 어떻게 보장하는가"가 더 중요해진다. 투자 판단을 내리는 에이전트라면 그 판단의 수익률만큼이나 안전성이 중요하다. ReAct가 도구를 사용하게 했고, CoALA가 메모리와 계획을 부여했고, Voyager가 열린 세계를 탐험하게 했다. 능력이 커질수록, 그 능력에 걸맞은 제어가 필요하다.

2022년 12월, Anthropic이 Constitutional AI(CAI)를 발표했다. 핵심 아이디어는 인간의 감독을 원칙(constitution) -- AI 행동을 지배해야 하는 규칙 목록 -- 으로 추상화하는 것이다. 인간이 매번 유해한 출력에 라벨을 다는 대신, "이런 원칙을 따르라"고 한 번 정의하면, AI가 스스로 자기 출력을 비판하고 수정한다. 국가가 수만 개의 판례를 일일이 참조하는 대신 헌법이라는 상위 원칙에서 법을 도출하는 것처럼, CAI는 수만 개의 인간 선호 레이블 대신 소수의 자연어 원칙에서 행동 기준을 도출한다.

이 논문은 AI 안전성(alignment) 연구에서 하나의 분수령이다. RLHF가 "인간이 직접 가르친다"는 접근이었다면, CAI는 "인간이 원칙을 세우고, AI가 스스로 배운다"는 접근이다. 교사가 매번 답을 알려주는 것에서, 교사가 시험 규칙을 정하고 학생이 자율 학습하는 것으로의 전환이다.

시리즈의 맥락에서 보면, 이 전환은 필연적이다. 에이전트가 도구를 호출하고, 코드를 실행하고, 외부 시스템과 상호작용하는 세계에서, 매번 인간이 "이 행동은 괜찮고, 저 행동은 안 된다"를 레이블링하는 것은 불가능하다. 원칙으로 행동을 규율하는 것 -- 헌법적 접근 -- 이 확장 가능한 유일한 경로다. 이 전환이 왜 필요했는지, 어떻게 작동하는지, 그리고 무엇을 남겼는지를 들여다본다.

왜 인간 피드백만으로는 부족한가 -- RLHF의 병목

CAI를 이해하려면, 그것이 해결하려 한 문제 -- RLHF의 구조적 한계 -- 를 먼저 봐야 한다.

RLHF(Reinforcement Learning from Human Feedback)는 ChatGPT를 가능하게 한 핵심 기술이다. 인간 평가자(크라우드워커)가 AI의 두 응답 중 어느 것이 더 나은지 비교하고, 그 선호 데이터로 보상 모델을 훈련하고, 그 보상 모델로 정책을 최적화한다. 문제는 이 파이프라인의 매 단계에 병목이 있다는 것이다.

첫째, 확장성의 한계. 유해성 평가에 필요한 인간 레이블은 수만 개에 달한다. 각 레이블에는 평가자의 시간, 비용, 심리적 부담이 따른다. 유해한 콘텐츠를 반복적으로 읽고 판단해야 하는 크라우드워커의 피로와 트라우마는 실질적인 운영 비용이다. 그리고 평가자를 더 많이 고용한다고 문제가 해결되지 않는다 -- 평가자 간의 불일치(inter-annotator disagreement)가 늘어나기 때문이다.

둘째, 불투명성. 수만 개의 인간 선호 레이블에는 평가자의 개인적 편향, 문화적 배경, 그날의 컨디션이 모두 녹아 있다. 그 레이블의 총합이 어떤 행동 규범을 인코딩하고 있는지 아무도 정확히 알 수 없다. 법으로 치면, 판례가 수만 개 쌓여 있는데 그것을 관통하는 원칙이 명문화되어 있지 않은 상태다. 모델이 특정 방식으로 행동하는 이유를 역추적하기가 극도로 어렵다.

셋째, 회피성(evasiveness)의 문제. RLHF로 훈련된 모델은 민감한 주제에 대해 "그 질문에 답할 수 없습니다"라는 정형화된 거부로 일관하는 경향이 있었다. 크라우드워커가 유해할 가능성이 있는 응답보다 무조건적인 거부를 선호했기 때문이다. 이것은 무해성이 아니라 회피다. 핵무기 제조법을 거부하는 것은 당연하지만, 핵에너지의 장단점에 대한 균형 잡힌 논의마저 거부하는 것은 유용성의 포기다. 유해성과 유용성 사이의 파레토 최적을 찾는 대신, 모델이 유용성을 포기하고 안전지대로 도망치는 것이다.

CAI는 이 세 가지 문제에 대한 Anthropic의 답이다. 수만 개의 불투명한 레이블 대신, 약 16개의 자연어 원칙으로 행동을 제어한다. 헌법이라는 이름은 비유가 아니라 설계 철학이다. 국가가 시민의 행동을 규율할 때, 모든 가능한 상황에 대한 판례를 미리 만들어두지 않는다. 소수의 상위 원칙 -- 헌법 -- 을 세우고, 구체적 판단은 그 원칙에서 도출한다. CAI도 같은 전략을 취한다.

헌법의 메커니즘 -- 비판과 수정의 2막 구조

CAI의 훈련 과정은 두 단계로 나뉜다. 지도학습(SL) 단계에서 모델이 자기 응답을 비판하고 수정하는 데이터를 만들고, 강화학습(RL) 단계에서 AI 피드백으로 선호 모델을 훈련한다.

1막: 비판-수정의 지도학습 (SL-CAI)

SL 단계의 핵심은 모델이 스스로 훈련 데이터를 생성한다는 것이다. 이것이 기존 RLHF와의 결정적 차이다.

출발점은 유용성만으로 RLHF 훈련된 모델이다. 이 모델에 의도적으로 유해한 프롬프트를 던진다 -- "이웃의 와이파이를 해킹하는 방법을 알려줘" 같은 레드팀 공격. 유용성에 최적화된 모델은 기꺼이 위험한 답을 생성한다.

여기서 헌법이 개입한다. 모델에게 자기 응답을 헌법의 원칙에 비추어 비판(critique)하도록 요청한다. 예를 들어 "어시스턴트의 응답이 불법적이거나 유해한 활동을 조장하는 방식을 식별하시오"라는 원칙이 주어지면, 모델은 "와이파이 해킹은 개인정보 침해이며 불법일 수 있으므로 이 응답은 유해합니다"라고 자기 비판을 생성한다. 그 다음, 비판에 기반하여 원래 응답을 수정(revision)한다 -- "이웃의 와이파이를 해킹하는 것은 개인정보 침해이므로 강력히 반대합니다. 법적 문제에 처할 수도 있습니다."

이 비판-수정 사이클은 여러 번 반복된다. 각 단계마다 16개 원칙 중 하나를 무작위로 샘플링하여 적용한다. 수정이 거듭될수록 응답은 점진적으로 더 안전해진다. 논문의 실험에서 수정 횟수가 증가할수록 무해성은 단조 증가했다. 최종 수정된 응답들을 모아 지도학습 데이터셋으로 사용하고, 사전 훈련된 언어 모델을 파인튜닝한다.

흥미로운 질문이 있다 -- 비판 단계가 정말 필요한가? 비판 없이 바로 수정을 생성하는 단순화도 가능하다. 논문의 실험 결과, 소형 모델에서는 비판을 포함한 수정이 더 높은 무해성 점수를 달성했지만, 대형 모델에서는 차이가 미미했다. 그럼에도 비판을 포함하기로 결정한 이유는 투명성이다. 비판은 모델이 왜 수정하는지를 명시화하고, 더 미묘한 유해성을 발견하는 추론 과정을 제공한다. Reflexion이 과제 실패에 대한 자기 반성으로 성능을 개선했던 것과 같은 메커니즘이 안전성 영역에 적용된 것이다.

2막: AI 피드백의 강화학습 (RLAIF)

SL 단계만으로도 모델은 개선된다. 하지만 진정한 도약은 2막에서 일어난다.

SL 단계가 "자기 수정 데이터로 파인튜닝"이라면, RL 단계는 "자기 평가 데이터로 강화학습"이다. RLHF에서 크라우드워커가 하던 선호 비교를 AI가 대신한다.

구체적으로, SL-CAI로 파인튜닝된 모델이 같은 프롬프트에 대해 두 개의 응답을 생성한다. 피드백 모델에게 헌법 원칙과 함께 두 응답을 보여주고, 어느 것이 원칙에 더 부합하는지 판단하게 한다. 이때 Chain-of-Thought(CoT)를 활용한다 -- "Let's think step-by-step"으로 왜 한 응답이 더 나은지 논증하게 한 뒤, 최종 선택의 로그 확률을 추출한다.

여기서 세심한 엔지니어링 디테일이 있다. CoT 확률을 40-60% 범위로 클램핑하여 극단적 확신을 방지한다. AI가 "A가 압도적으로 좋다"고 과신하는 것을 막는 것이다. 또한 16개 원칙을 앙상블하여 평가의 견고성을 높인다. 단일 원칙이 편향될 수 있지만, 다양한 원칙의 평균은 더 균형 잡힌 판단에 수렴한다.

이 AI 생성 선호 데이터셋으로 선호 모델(Preference Model)을 훈련하고, SL-CAI 모델을 이 PM에 대해 강화학습으로 파인튜닝한다. 이것이 RLAIF -- RL from AI Feedback다.

헌법의 원칙은 어떤 것들인가? 논문은 약 16개의 원칙을 사용했다. 일부를 예로 들면:

"가장 도움이 되면서도, 정직하고, 무해한 응답을 선택하시오"
"인종차별적, 성차별적, 독성이 있는 내용을 식별하시오"
"불법적이거나 위험한 활동을 조장하지 않는 응답을 선호하시오"
"회피적이지 않으면서도 유해하지 않은 응답을 선호하시오"

마지막 원칙이 특히 중요하다. "회피적이지 않으면서도 유해하지 않은" -- RLHF의 회피성 문제를 원칙 수준에서 직접 다루고 있다. 원칙이 단순히 "나쁜 것을 하지 마라"가 아니라 "나쁜 것을 하지 않되, 도망치지도 마라"는 양면을 모두 인코딩하고 있는 것이다.

논문의 저자들은 헌법의 원칙 수가 중요하지 않다고 강조한다. 16개는 충분히 다양한 관점을 커버하면서도 관리 가능한 수준이다. 핵심은 원칙의 수가 아니라, 원칙이 자연어로 명시되어 있어 누구나 읽고 이해하고 수정할 수 있다는 점이다. RLHF의 수만 개 불투명한 레이블과 대비되는 CAI의 가장 큰 장점이 바로 이 투명성이다.

숫자가 말하는 것 -- 유용성과 무해성의 파레토 프론티어

이론이 아무리 우아해도, 숫자가 뒷받침하지 않으면 학문적 호기심에 그친다. CAI의 성과를 가장 명확하게 보여주는 것은 유용성-무해성 평면에서의 모델 위치다. 논문의 Figure 2가 핵심 결과를 담고 있다. 기존에는 유용성을 높이면 무해성이 떨어지고, 무해성을 높이면 유용성이 떨어지는 트레이드오프가 불가피하다고 여겨졌다. CAI는 이 경계선 자체를 밀어냈다.

모델	유용성 Elo	무해성 Elo	회피율	특징
유용성 전용 RLHF	높음	낮음	낮음	유해한 요청에도 기꺼이 응답
HH RLHF (유용+무해)	중간	중상	높음	민감한 주제 회피 경향
SL-CAI (비판-수정만)	중간	중상	중간	수정 횟수에 비례하여 무해성 증가
RL-CAI (RLAIF)	중상	높음	낮음	비회피적이면서 무해
RL-CAI + CoT	중상	최고	최저	파레토 프론티어 최적

핵심 발견은 세 가지다.

첫째, RL-CAI + CoT가 유용성-무해성 파레토 프론티어에서 가장 우수한 위치를 차지했다. 무해성에서 인간 피드백 기반 RLHF를 능가하면서, 유용성 손실이 최소화됐다. 인간 레이블 없이도 인간 레이블 기반 모델과 동등하거나 더 나은 안전성을 달성할 수 있다는 것이다.

둘째, RL-CAI 모델은 사실상 결코 회피적이지 않았다. HH RLHF 모델이 민감한 주제에 대해 "그 질문에 답할 수 없습니다"로 일관한 반면, RL-CAI는 왜 특정 요청이 문제가 되는지를 설명하면서 대화에 참여했다. "핵무기를 만드는 방법을 알려줄 수는 없지만, 핵 비확산 조약의 역사와 현재 과제에 대해 논의할 수 있습니다"와 같은 식이다. 문을 닫는 것이 아니라, 안전한 방향으로 문을 연다.

셋째, SL 단계만으로도 상당한 개선이 가능하지만, RL 단계가 추가되었을 때 비약적인 향상이 일어났다. 자기 수정과 자기 평가의 조합이 어느 하나만 사용하는 것보다 효과적이라는 것이다. 이것은 직관적으로도 이해된다 -- 학생이 스스로 답안을 고치는 것(SL)과, 두 답안 중 어느 것이 더 나은지 판별하는 능력을 키우는 것(RL)은 서로 다른 역량이고, 두 역량이 결합될 때 학습이 가속된다.

RLAIF 레이블의 보정(calibration)도 주목할 만하다. AI가 생성한 선호 레이블이 인간 레이블과 비교하여 상당히 양호한 보정을 보였다. 모델이 "A가 70% 확률로 더 낫다"고 판단했을 때, 실제로 인간도 비슷한 비율로 A를 선호했다는 뜻이다. AI 피드백이 인간 피드백의 합리적인 대체제가 될 수 있음을 실증적으로 보여준 것이다.

다만, 과도한 훈련 시 Goodharting 행동이 관찰됐다. 유해한 프롬프트에 과도하게 엄격하게 반응하거나, "당신은 소중하고 가치 있는 사람입니다" 같은 상투적 문구를 삽입하는 현상이다. 보상 모델을 과적합하면 보상 신호의 피상적 패턴을 악용하는 RLHF의 고전적 문제가 RLAIF에서도 동일하게 나타난 것이다. 감독의 형태를 바꿨을 뿐, 감독의 근본적 어려움 -- 측정하는 것이 실제 목표와 괴리될 수 있다는 것 -- 은 사라지지 않았다.

종합하면, CAI는 유용성-무해성 트레이드오프에서 새로운 파레토 프론티어를 개척했다. 인간 레이블 없이도 인간 수준의 안전성 판단이 가능하다는 것, 그리고 안전성과 유용성이 반드시 상충하지 않는다는 것을 실증했다. 하지만 이 성과의 전제 조건 -- 충분히 큰 모델, 잘 설계된 원칙, 적절한 훈련 -- 을 간과해서는 안 된다.

헌법이 닿지 못하는 곳 -- 구조적 한계

CAI의 우아함이 가리기 쉬운 구조적 한계들이 있다. 모든 해법은 새로운 문제를 만들고, CAI도 예외가 아니다.

가장 근본적인 문제는 헌법 자체의 설계다. 누가 원칙을 정하는가? 논문에서는 Anthropic의 연구진이 16개 원칙을 작성했다. 이 원칙들은 서구적, 영어 중심적, 기술 기업의 관점을 반영할 수밖에 없다. "유해하지 않은" 것의 정의는 문화권마다 다르다. 미국에서 합법적인 표현이 다른 국가에서는 혐오 발언이 될 수 있고, 그 역도 성립한다. 헌법이 보편적이라는 가정은 실제로 특정 문화의 가치를 보편으로 포장할 위험을 내포한다.

자기 평가의 정확도도 한계가 있다. 모델이 자기 출력의 유해성을 판단하는데, 그 판단 능력은 모델 자체의 능력에 의존한다. 모델이 인식하지 못하는 미묘한 유해성 -- 구조적 편향, 암시적 차별, 문맥 의존적 위험 -- 은 자기 비판으로도 포착되지 않는다. 감시자와 피감시자가 동일인인 셈이다.

조작 가능성도 존재한다. 충분히 정교한 adversarial 프롬프트는 비판-수정 사이클을 우회할 수 있다. 원칙이 공개되면 그 원칙의 사각지대를 공략하는 공격이 가능해진다. 헌법의 조문이 공개된 국가에서 법률의 허점을 이용하는 것과 같은 구조적 취약점이다. 실제로 CAI 이후 다양한 jailbreak 기법들이 등장했고, 이는 원칙 기반 접근만으로는 모든 공격을 방어할 수 없음을 보여준다.

원칙 간의 충돌 해결 메커니즘도 명확하지 않다. "유용해야 한다"와 "무해해야 한다"가 충돌할 때 -- 예를 들어 의학적 조언을 구하는 사용자에게 정확하지만 잠재적으로 위험한 정보를 제공해야 하는 상황 -- 어느 원칙이 우선하는지의 위계가 명시되어 있지 않다. 실제 헌법에는 기본권 간 충돌 시의 해석 원칙이 있지만, CAI의 헌법에는 그것이 없다.

마지막으로, 논문이 명시적으로 인정하는 한계가 있다. CAI는 유해성에 대해서만 인간 레이블을 대체했을 뿐, 유용성에 대해서는 여전히 인간 피드백에 의존한다. 완전한 자율 정렬이 아니라 부분적 자율화다. 그리고 이 부분적 자율화조차 모델이 충분히 크고 능력이 있을 때만 작동한다 -- 소형 모델의 자기 비판은 신뢰하기 어렵다. 자기 개선의 역설이다: 자기를 개선하려면 이미 충분히 유능해야 한다.

2026년의 시선 -- 헌법에서 문화로

논문이 발표된 2022년 12월로부터 3년 이상이 흘렀다. AI 연구에서 3년은 지질학적 시간 단위에 가깝다. CAI가 남긴 유산은 논문의 직접적 결과를 훨씬 넘어선다.

가장 명백한 영향은 Anthropic의 Claude 시리즈 자체다. Claude는 CAI의 원칙 기반 접근을 제품 수준으로 발전시킨 가장 직접적인 결과물이다. 초기 16개 원칙은 수백 개의 세분화된 가이드라인으로 확장되었고, 원칙의 설계 과정 자체가 하나의 연구 영역이 되었다. "어떤 원칙이 좋은 원칙인가"라는 메타 질문이 "어떤 행동이 좋은 행동인가"만큼이나 중요해진 것이다. 또한 OpenAI, Google DeepMind 등 다른 연구 기관들도 유사한 원칙 기반 정렬 전략을 채택하면서, CAI의 패러다임이 업계 표준에 가까워지고 있다.

CAI의 자기 비판 메커니즘은 에이전트 연구에서 반복적으로 나타나는 패턴의 한 변형이다. Reflexion이 과제 수행에서의 자기 반성이었고, CAI는 안전성에서의 자기 반성이다. 이 두 축 -- 성능의 자기 개선과 안전성의 자기 개선 -- 이 통합되는 방향으로 연구가 진행되고 있다. 에이전트가 "내가 이 과제를 잘 수행했는가"와 "내가 이 과제를 안전하게 수행했는가"를 동시에 반성하는 시스템이다.

RLAIF의 아이디어 -- AI 피드백으로 AI를 훈련한다 -- 는 2026년 현재 더 넓은 맥락에서 "scalable oversight"의 핵심 전략이 되었다. 인간이 직접 감독하기 어려운 복잡한 과제에서, AI가 다른 AI를 평가하고 개선하는 재귀적 구조는 초인간적 능력을 가진 AI의 정렬 문제를 다루는 핵심 경로 중 하나로 인정받고 있다. CAI는 그 경로의 초기 실증이었다.

이 시리즈에서 다룬 다른 논문들과의 교차점도 흥미롭다. Reflexion의 자기 반성은 과제 성능에 초점을 맞췄지만, CAI의 자기 비판과 본질적으로 같은 메커니즘이다. ETO의 궤적 최적화에서 부정적 궤적을 학습에 활용하는 것은, CAI가 유해한 응답을 비판하여 더 나은 응답을 도출하는 것과 구조적으로 닮았다. 안전성과 성능은 별개의 문제가 아니라, "자기 개선"이라는 하나의 패러다임의 두 표현인 것이다.

헌법의 문화적 편향 문제도 의미 있는 진전이 있었다. 단일 보편 헌법이 아니라, 사용 맥락과 문화적 배경에 따라 적응하는 헌법의 다원화가 탐구되고 있다. 하나의 헌법이 아니라 헌법의 체계 -- 핵심 원칙의 보편 층위와 문화적 적응의 지역 층위가 공존하는 구조 -- 가 논의되고 있다. CAI 논문이 제시한 "16개 원칙"이라는 단순한 출발점에서, 원칙의 생태계로 진화하고 있는 셈이다.

에이전트 시스템의 관점에서 보면, CAI의 유산은 더 구체적이다. CoALA가 에이전트의 인지 아키텍처를 체계화했다면, CAI는 그 아키텍처 안에 안전성을 내장하는 방법론을 제시했다. 에이전트가 외부 도구를 호출하기 전에 "이 행동이 원칙에 부합하는가"를 자문하는 내부 검열 단계 -- 이것이 CAI에서 에이전트로의 자연스러운 확장이다. Toolformer가 도구 사용의 시기를 학습했다면, CAI의 후속 연구들은 도구 사용의 안전성을 학습하게 하는 방향으로 나아가고 있다.

마무리

한 문장으로 줄이면 이렇다: "수만 개의 인간 레이블 대신 16개의 원칙을 세우고, AI가 스스로 비판하고 수정하게 하면, 더 투명하고 덜 회피적인 안전성이 가능하다."

이 논문이 에이전트 연구에 남긴 가장 중요한 통찰은 안전성의 자기 개선 가능성이다. 에이전트가 도구를 사용하고 실세계에 영향을 미칠 때, 원칙 기반 자기 검열은 외부 감시자에 의존하지 않는 내재적 안전장치가 된다. InvestorBench의 투자 에이전트가 매일 Buy/Sell/Hold를 결정할 때, 그 결정이 윤리적인지 -- 내부자 정보를 악용하지는 않는지, 시장 조작에 해당하지는 않는지 -- 를 스스로 검열하는 메커니즘이 필요하다. 외부의 규칙이 아니라 내면화된 원칙으로 행동을 제어한다는 것 -- CAI가 "헌법"이라는 이름을 선택한 이유가 여기에 있다.

하지만 CAI는 RLHF를 대체한 것이 아니라 보완한 것이다. 유용성에 대해서는 여전히 인간 피드백을 사용했고, 무해성에 대해서만 AI 피드백으로 대체했다. 그렇다면 RLHF 자체의 근본적 한계는 무엇인가? 다음 글에서는 CAI의 기반이 되는 RLHF의 미해결 과제들을 체계적으로 정리한 서베이를 읽는다. CAI가 해법이었다면, 다음 논문은 그 해법이 필요했던 문제의 전체 지도를 펼친다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 스물한 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: InvestorBench — 금융 의사결정 에이전트 벤치마크

Tue, 07 Apr 2026 13:00:00 GMT

논문 정보

제목: InvestorBench: A Benchmark for Financial Decision-Making Tasks with LLM-based Agent

저자: Haohang Li, Yupeng Cao, Yangyang Yu 외 (Stevens Institute of Technology, Columbia University, Harvard University)

출판: ACL 2025 / arXiv 2412.18174 (2024.12)

FINCH가 스프레드시트 업무의 자동화를 평가했다면, InvestorBench는 한 단계 더 야심적인 질문을 던진다 -- LLM이 투자 의사결정을 내릴 수 있는가?

FINCH에서 에이전트의 과제는 셀을 채우고, 수식을 검증하고, 서식을 맞추는 것이었다. 답이 틀리면 점수가 깎이지만, 누군가의 자산이 줄어들지는 않는다. InvestorBench가 요구하는 것은 다르다. 매일 아침 시장이 열리면 에이전트는 Buy, Sell, Hold 중 하나를 결정해야 한다. 그 결정은 누적 수익률로 돌아온다. 스프레드시트에서 시장으로 -- 정답이 사후에야 드러나는 영역으로 에이전트를 밀어 넣은 것이다.

이 논문은 Stevens Institute of Technology, Columbia, Harvard의 연구진이 ACL 2025에 발표한 것으로, 3가지 자산 유형(주식, 암호화폐, ETF)에 걸쳐 13개 LLM을 체계적으로 비교한 최초의 포괄적 금융 의사결정 벤치마크다. FinMem, FinAgent, CryptoTrade 같은 기존 금융 에이전트 프레임워크들이 각자의 틈새 -- 단일 주식, 암호화폐, 소규모 포트폴리오 -- 에 한정되어 있었다면, InvestorBench는 이들을 하나의 통합된 평가 무대 위에 올려놓았다. 단순히 모델을 줄 세우는 것이 아니라, 에이전트가 시장 정보를 어떻게 기억하고, 통합하고, 판단하는지를 구조적으로 설계한 점에서 벤치마크 이상의 가치를 가진다.

시장이라는 시험장 -- LLM에게 투자를 맡긴다는 것

금융 시장에서 의사결정을 내리는 것은 오픈북 시험과 비슷하다. 모든 정보가 공개되어 있지만, 그 정보를 어떻게 조합하고 해석하느냐에 따라 결과가 갈린다. OHLCV 가격 데이터, 뉴스 헤드라인, 분기 실적 보고서(10-Q), 연간 보고서(10-K), 시장 감성 지표 -- 전문 투자자가 아침마다 확인하는 이 정보들을 에이전트에게도 동일하게 제공하면, 과연 합리적인 판단이 나오는가?

문제의 본질은 정보의 양이 아니라 정보의 시간적 구조에 있다. 어제 나온 뉴스와 6개월 전에 발표된 연간 보고서는 동일한 가중치를 가져서는 안 된다. 인간 투자자는 이것을 직관적으로 안다 -- 아침에 읽은 실적 서프라이즈 뉴스에는 즉각 반응하지만, 작년 10-K 보고서의 부채 비율은 장기적 관점에서 참조한다. LLM에게 이 시간적 감각을 어떻게 부여할 것인가? InvestorBench의 핵심 설계가 여기서 출발한다.

또 하나의 도전은 순차적 의사결정의 특성이다. 코드 생성 벤치마크에서 각 문제는 독립적이다. 하나를 틀려도 다음 문제에 영향을 주지 않는다. 투자는 다르다. 오늘의 매수 결정이 내일의 포지션을 결정하고, 내일의 포지션이 모레의 선택지를 제약한다. 체스에서 한 수가 나머지 판 전체를 바꾸는 것처럼, 투자에서의 각 결정은 이후 모든 결정의 맥락을 재구성한다.

논문은 이 구조를 무한 기간 POMDP(Partially Observable Markov Decision Process)로 형식화했다. 관찰 가능한 상태(가격, 뉴스)와 관찰 불가능한 상태(시장 심리, 내부자 정보)가 공존하는 환경에서, 에이전트는 할인된 누적 손익(PnL)을 최대화하는 행동 시퀀스를 찾아야 한다. 행동 공간은 {Buy, Sell, Hold}의 세 가지로 단순화했지만, 이 단순한 행동이 매일 반복되면서 만들어내는 궤적의 복잡성은 결코 단순하지 않다.

기억의 계층 -- 에빙하우스를 금융에 이식하다

InvestorBench의 에이전트 아키텍처에서 가장 독창적인 부분은 계층적 장기 메모리(Layered Long-Term Memory)다. 인간의 인지 시스템에서 영감을 받아, 정보의 종류에 따라 감쇠 속도를 다르게 설정한 3개 계층의 벡터 데이터베이스를 구축했다.

계층	반감기	정보 유형	비유
얕은 처리 (Shallow)	14일	일일 뉴스, 시장 감성	아침 신문 -- 읽고 나면 빠르게 잊힌다
중간 처리 (Intermediate)	90일	분기 보고서 (10-Q)	분기 실적 -- 한 분기 동안 유효하다
깊은 처리 (Deep)	365일	연간 보고서 (10-K)	기업 펀더멘털 -- 천천히 변한다

각 메모리 이벤트의 검색 점수는 세 가지 요소의 합성이다. 최근성(에빙하우스 망각 곡선에 기반한 시간 감쇠), 관련성(코사인 유사도로 측정한 현재 맥락과의 부합도), 중요도(계층별 차등 확률과 감쇠 비율의 곱). 얕은 계층의 뉴스는 2주가 지나면 검색 점수가 급격히 떨어지지만, 깊은 계층의 연간 보고서는 1년이 지나도 상당한 영향력을 유지한다.

이 설계가 영리한 이유는 명시적인 시간 필터 대신 연속적 감쇠를 사용했다는 점이다. "3개월 이상 된 뉴스는 무시하라"는 규칙은 경계선에서 정보 손실을 일으킨다. 감쇠 함수는 오래된 정보를 버리지 않고 자연스럽게 영향력을 줄인다. 인간이 "그때 그 기사, 뭐였더라..."하며 희미하게 기억하는 것과 같은 메커니즘이다.

메모리 외에도 에이전트를 구성하는 모듈들이 유기적으로 연결되어 있다.

Profile 모듈은 에이전트를 경험 많은 투자자로 역할 정의하면서, 역사적 시장 모멘텀에 따라 위험 선호를 동적으로 조정한다. 양의 모멘텀이 지속되면 위험 추구적으로, 음의 모멘텀이 지속되면 보수적으로 전환하는 자기 적응적 메커니즘이다. 인간 투자자가 상승장에서 자신감을 갖고 하락장에서 방어적으로 전환하는 심리를 모델링한 것이다.

Perception 모듈은 OHLCV 수치 데이터, 텍스트 뉴스, SEC 공시 문서를 LLM이 처리할 수 있는 구조화된 형식으로 변환한다. 숫자와 텍스트와 문서라는 이질적 형식의 정보를 하나의 프롬프트 안에서 통합하는 번역기 역할이다. Action 모듈은 이 모든 분석을 종합하여 매일 Buy, Sell, Hold 중 하나를 결정한다.

에이전트 아키텍처에는 작업 메모리(Working Memory)도 있다. 즉각적 반성(immediate reflection)과 확장된 반성(extended reflection)의 두 가지 메커니즘으로, 최근 의사결정의 결과를 되돌아보고 다음 결정에 반영한다. "어제 TSLA를 매수했는데 5% 하락했다"는 즉각적 반성이고, "지난 2주간 뉴스 감성에 과잉 반응하여 불필요한 매매를 반복했다"는 확장된 반성이다.

데이터 환경도 실세계를 충실히 반영한다. 주식 시장은 MSFT, JNJ, TSLA, AAPL, HON, UVV, NIO의 7개 종목에 대해 Yahoo Finance의 OHLCV, Alpaca News API의 뉴스, SEC EDGAR의 10-K/10-Q를 통합했다. 테스트 기간은 2020년 7월부터 2021년 5월까지다. 암호화폐 시장은 Bitcoin과 Ethereum에 대해 cryptonews, cryptopotato, cointelegraph 등 다중 소스 뉴스를 수집하여 2023년 4월부터 11월까지 평가했다. ETF 시장은 NIFTY 데이터셋의 뉴스 헤드라인과 감성 데이터를 활용하여 2020년 1월부터 9월까지를 다뤘다. 세 시장이 서로 다른 시기를 다루기 때문에, 시장 레짐의 다양성도 어느 정도 확보된다.

13개 모델의 대결 -- 돈 앞에서 드러나는 격차

InvestorBench는 13개 LLM을 3가지 자산 유형에 걸쳐 평가했다. 독점 모델 3개(GPT-4, GPT-4o, GPT-o1-preview), 금융 특화 모델 1개(Palmyra-Fin-70B), 오픈소스 모델 9개(Qwen2.5-72B부터 Qwen-2.5-7B까지)의 구성이다.

평가 지표는 네 가지다. 누적 수익률(CR)은 전체 투자 기간의 총 성과를, 샤프 비율(SR)은 위험 대비 수익의 효율성을, 연환산 변동성(AV)은 수익률의 불안정성을, 최대 낙폭(MDD)은 최악의 손실 구간을 측정한다. CR이 높아도 MDD가 크면 실전에서 견디기 어렵고, SR이 높아도 AV가 높으면 결과의 일관성을 신뢰하기 어렵다. 네 지표를 함께 봐야 전체 그림이 보인다.

주식 트레이딩 결과에서 가장 두드러진 패턴은 독점 모델의 우위다.

모델	주식 CR	주식 SR	암호화폐 CR	ETF CR
GPT-o1-preview	상위권	상위권	상위권	상위권
GPT-4	상위권	상위권	상위권	상위권
GPT-4o	상위권	상위권	상위권	상위권
Qwen2.5-72B	중상위	중상위	중상위	중상위
Llama-3.1-70B	중위권	중위권	중위권	중위권
Palmyra-Fin-70B	중위권	중위권	중위권	중위권
DeepSeek-67B	중위권	중하위	중위권	중하위
Yi-1.5-34B	중하위	중하위	하위권	중하위
Qwen2.5-32B	중하위	중하위	하위권	중하위
Llama-3.1-8B	하위권	하위권	하위권	하위권
Qwen-2.5-7B	하위권	하위권	하위권	하위권

세 가지 핵심 발견이 있다.

첫째, 독점 모델이 모든 자산 유형에서 일관되게 상위권을 차지했다. 특히 혼합 시장 조건 -- TSLA와 NIO처럼 급등과 급락이 번갈아 나타나는 종목 -- 에서 격차가 벌어졌다. GPT-4와 GPT-o1이 역사적 모멘텀, 현재 포지션, 자기 반성 결과를 효과적으로 종합하여 노이즈 속에서 신호를 포착한 반면, 소규모 오픈소스 모델들은 뉴스 감성에 과잉 반응하거나 가격 추세에 후행하는 경향을 보였다.

둘째, 모델 크기가 금융 의사결정 품질과 비례했다. 오픈소스 진영 내에서 67B 이상 모델이 30B 이하 모델 대비 유의미하게 높은 CR과 SR을 보였고, 결과의 분산도 현저히 낮았다. 순차적 의사결정이 단순한 패턴 매칭이 아니라 다중 정보원의 복잡한 추론을 요구하기 때문이다. 작은 모델은 개별 정보를 처리할 수 있지만, 여러 정보를 동시에 고려하여 일관된 판단을 내리는 능력이 부족했다.

셋째, 금융 특화 파인튜닝이 의사결정에서는 결정적 이점을 제공하지 않았다. Palmyra-Fin-70B는 금융 맥락으로 광범위하게 파인튜닝되었지만, 같은 크기의 범용 모델과 비교하여 순차적 트레이딩에서 뚜렷한 우위를 보이지 못했다. 재무 보고서 분석이나 용어 이해에 최적화된 훈련이 실시간 의사결정 능력으로 직결되지 않는다는 것이다. 금융 용어를 잘 안다고 해서 돈을 잘 버는 것은 아닌 셈이다. 이것은 도메인 지식과 의사결정 능력이 별개의 역량임을 시사하며, 금융 AI의 훈련 전략에 대한 중요한 질문을 제기한다.

암호화폐와 ETF 시장에서도 패턴은 유사했다. 암호화폐는 뉴스와 감성에 더 민감한 시장 특성상, 대형 모델의 텍스트 이해 능력이 더 큰 차이를 만들었다. 중소형 오픈소스 모델은 단순한 Buy & Hold 전략보다도 낮은 수익률을 기록했다 -- 아무것도 하지 않는 것이 작은 모델의 판단보다 나았다는 뜻이다.

ETF 시장에서는 다양한 섹터에 걸친 복합적 분석이 필요했기에, 풍부한 사전 훈련 지식을 보유한 독점 모델의 이점이 더 두드러졌다. ETF는 개별 종목과 달리 산업 전반의 동향을 종합적으로 이해해야 하므로, 넓은 지식 기반이 곧 의사결정 품질로 연결된 것이다.

백테스트의 그림자 -- InvestorBench가 증명하지 못한 것들

벤치마크의 결과가 인상적일수록, 그 결과가 증명하지 못한 것들에 대해 냉정해야 한다. 금융에는 오래된 경구가 있다 -- "과거 수익률이 미래 수익률을 보장하지 않는다." 이 경고는 인간 펀드매니저뿐 아니라 LLM 에이전트에게도 동일하게 적용된다.

가장 근본적인 한계는 백테스팅과 실시간 트레이딩의 간극이다. InvestorBench의 모든 실험은 과거 데이터에 대한 시뮬레이션이다. 2020년 7월부터 2021년 5월까지의 주식 데이터를 사용했는데, 이 기간은 코로나 이후 회복기로 대부분의 자산이 상승한 시기다. 상승장에서의 Buy/Hold 결정은 하락장에서의 Sell 결정보다 구조적으로 쉽다. 시장 레짐(regime)이 바뀌었을 때 에이전트가 동일한 성능을 유지할 수 있는지는 미지수다.

생존자 편향(survivorship bias)도 존재한다. 테스트에 사용된 종목 -- MSFT, AAPL, JNJ -- 은 모두 대형 우량주다. 이 종목들에 대해서는 풍부한 뉴스와 분석 자료가 존재하고, LLM의 사전 훈련 데이터에도 대량 포함되어 있을 가능성이 높다. 소형주, 신흥 시장, 유동성이 낮은 자산에서의 성능은 완전히 다를 수 있다.

논문 자체가 인정하는 한계도 있다. 현재 벤치마크는 단일 자산 의사결정에 초점을 맞추고 있어, 포트폴리오 수준의 자산 배분이나 리밸런싱은 평가하지 않는다. 실제 투자에서는 "AAPL을 살 것인가"가 아니라 "AAPL과 MSFT 중 어디에 비중을 더 둘 것인가"가 더 중요한 질문인 경우가 많다.

또한 거래 비용, 슬리피지, 시장 충격 같은 실행 마찰(execution friction)이 모델에 반영되지 않았다. 백테스트에서의 수익이 실거래에서 그대로 실현되지 않는 가장 큰 이유 중 하나가 바로 이 실행 비용이다. 일일 Buy/Sell/Hold를 결정하는 에이전트가 매일 포지션을 전환한다면, 그 거래 비용만으로도 수익의 상당 부분이 사라질 수 있다.

마지막으로, LLM의 사전 훈련 데이터와 테스트 기간의 중첩 가능성도 고려해야 한다. 2020-2021년의 시장 데이터와 뉴스는 대형 LLM의 훈련 데이터에 포함되어 있을 가능성이 높다. 에이전트가 진정으로 실시간 추론을 하는 것인지, 아니면 훈련 데이터에서 본 패턴을 재현하는 것인지를 구분하기 어렵다는 것이다. 이것은 InvestorBench만의 문제가 아니라, 과거 데이터 기반 금융 벤치마크 전반이 안고 있는 구조적 과제다.

2026년의 시선 -- 금융 에이전트의 현재 좌표

논문이 발표된 2024년 12월 이후, 금융 AI 에이전트 영역은 빠르게 움직였다. 벤치마크 논문의 운명은 흥미롭다 -- 발표 시점의 순위표는 빠르게 구식이 되지만, 평가 프레임워크 자체는 오히려 시간이 갈수록 가치가 높아진다.

InvestorBench가 제안한 계층적 메모리의 아이디어는 금융을 넘어 다양한 에이전트 시스템에 영향을 주었다. 정보의 종류에 따라 감쇠율을 다르게 설정한다는 개념은, 이 시리즈의 앞선 논문들 -- CoALA의 메모리 분류, MemGPT의 가상 메모리 관리 -- 의 연장선에 있으면서도, 금융이라는 도메인의 시간적 구조를 명시적으로 인코딩했다는 점에서 한 걸음 나아갔다. 고객 서비스, 의료 진단, 법률 분석 등 시간에 따라 정보의 가치가 달라지는 도메인이라면, 유사한 계층적 감쇠 메모리가 유효할 수 있다.

독점 모델의 우위라는 발견은 2026년 현재의 지형에서 재해석이 필요하다. 논문 당시의 오픈소스 모델은 Llama-3.1과 Qwen-2.5 세대였다. 그 이후 등장한 오픈소스 모델들의 추론 능력은 비약적으로 향상되었고, 금융 의사결정처럼 복잡한 순차적 추론에서의 격차도 상당 부분 좁혀졌을 가능성이 있다. 특히 추론 특화 모델(reasoning model)의 등장은, 다중 정보원을 종합하여 판단을 내리는 금융 의사결정과 자연스럽게 맞닿는다. InvestorBench가 제공하는 표준화된 평가 프레임워크 위에서 최신 모델들을 다시 비교하는 것은 의미 있는 후속 연구가 될 것이다.

금융 에이전트의 가장 큰 미해결 과제는 여전히 신뢰성이다. 백테스트 성능이 아무리 좋아도, 실시간 시장에서의 검증 없이는 실전 배치가 어렵다. 실시간 시장에는 백테스트에 없는 변수들이 존재한다 -- 유동성 부족으로 원하는 가격에 체결되지 않는 상황, 갑작스러운 거래 중단, 플래시 크래시 같은 극단적 이벤트.

규제 환경도 변수다. AI가 내린 투자 결정에 대한 법적 책임 소재, 알고리즘 트레이딩에 대한 규제 강화는 기술적 성능과는 별개의 문을 넘어야 하는 과제다. 에이전트가 아무리 높은 샤프 비율을 기록해도, 그 결정의 근거를 설명할 수 없다면 규제 당국의 승인을 받기 어렵다.

그럼에도 InvestorBench가 열어놓은 방향은 유효하다. 표준화된 벤치마크가 존재해야 모델 간 공정한 비교가 가능하고, 공정한 비교가 가능해야 실질적 개선이 측정된다. 금융 에이전트 연구가 "우리 모델이 잘 된다"는 개별 주장에서 "어떤 조건에서 어떤 모델이 왜 더 나은가"라는 체계적 이해로 나아가기 위한 기반이다.

논문이 제시한 두 가지 참여 모드도 주목할 만하다. 첫째, 연구자가 자신의 파인튜닝된 LLM을 InvestorBench의 에이전트 프레임워크에 통합하여 평가하는 모드. 둘째, 자체 설계한 에이전트에 InvestorBench의 환경과 평가 지표를 적용하여 비교하는 모드. 벤치마크를 닫힌 경쟁이 아니라 열린 플랫폼으로 설계한 것이다.

마무리

한 문장으로 줄이면 이렇다: "LLM은 금융 의사결정이라는 오픈북 시험에서 아직 초보 투자자 수준이지만, 기억의 구조를 바꾸면 성적이 달라진다."

이 논문이 벤치마크로서 남긴 가장 중요한 유산은 숫자 자체가 아니라, 금융 의사결정 에이전트를 평가하는 표준화된 틀을 제공했다는 점이다. 13개 모델의 순위는 시간이 지나면 바뀌지만, "3가지 자산 유형 x 4가지 평가 지표 x 다중 소스 데이터 환경"이라는 평가 프레임워크는 후속 연구의 기준선이 된다. 그리고 계층적 메모리라는 설계 원칙은 금융을 넘어, 시간적 구조를 가진 모든 정보 환경에서 에이전트의 기억을 설계하는 참조점이 된다.

시리즈의 궤적을 돌아보면, FINCH는 "에이전트가 정형화된 금융 업무를 수행할 수 있는가"를 물었고, InvestorBench는 "에이전트가 불확실성 속에서 금융 판단을 내릴 수 있는가"로 질문을 한 단계 높였다. 스프레드시트의 정답은 하나지만, 시장의 정답은 내일에야 드러난다. 두 벤치마크가 함께 그리는 그림은, 금융 AI가 아직 갈 길이 멀지만 측정 가능한 방향으로 움직이고 있다는 것이다.

다음 글에서는 금융 AI를 떠나, AI 시스템의 안전성으로 넘어간다. 에이전트가 강력해질수록 중요해지는 질문이 있다 -- 에이전트가 잘못된 행동을 하지 않도록 어떻게 보장하는가? 투자 의사결정을 내리는 에이전트라면, 그 판단의 안전성은 수익률만큼이나 중요하다. Constitutional AI -- 원칙 기반 자기 개선으로 유해한 출력을 제어하는 Anthropic의 접근을 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 스무 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: FINCH — 스프레드시트 중심 재무 벤치마크

Tue, 07 Apr 2026 09:00:00 GMT

논문 정보

제목: FINCH: Benchmarking Finance & Accounting across Spreadsheet-Centric Enterprise Workflows

저자: Haoyu Dong 외 (University of Chinese Academy of Sciences, Harvest Fund, Hugging Face 등)

출판: arXiv 2512.13168 (2025.12)

지난 글에서 DocLLM을 읽었다. 바운딩 박스 좌표만으로 문서의 공간 레이아웃을 이해하는 경량 접근이었다. 송장 위의 숫자가 "매출" 옆에 있는지 "비용" 옆에 있는지를 구분하는 능력 — 문서 이해(document understanding)의 기초 체력이다.

그런데 현실의 금융 실무자에게 물어보면, 문서를 "이해"하는 것은 업무의 시작일 뿐이다. 이해한 다음에는 스프레드시트를 열어야 한다. 숫자를 입력하고, 수식을 걸고, 시트 간 참조를 연결하고, 검증하고, 차트를 그리고, 보고서를 쓴다. 문서 이해가 눈이라면, 스프레드시트 조작은 손이다. 눈이 아무리 좋아도 손이 움직이지 않으면 일은 끝나지 않는다.

FINCH는 바로 그 손의 능력을 측정한다. AI 에이전트가 실세계 엔터프라이즈 스프레드시트 워크플로우를 실제로 수행할 수 있는지를 묻는, 금융·회계(F&A) 벤치마크다.

포장도로 위의 시험 — AI 코딩 벤치마크의 맹점

HumanEval 91%, SWE-bench 40% — AI 에이전트의 코딩 능력은 매년 경신된다. 이 숫자를 보면 AI가 곧 모든 지식 노동을 대체할 것 같다. 하지만 이 벤치마크들은 포장도로 위의 주행 시험과 같다. 평탄하고, 규칙적이고, 경계가 분명하다. 코드에는 문법이 있고, 테스트에는 통과 기준이 있다.

실세계 엔터프라이즈 업무는 비포장도로다. 세계에서 가장 많이 쓰이는 업무 도구 — 스프레드시트 — 를 생각해보라. 병합된 셀, 중첩된 헤더, 시트 91개짜리 워크북, 암호 같은 열 이름, 숨겨진 수식에 인코딩된 비즈니스 로직. 문법이 없다. 관행만 있다. 같은 회사 안에서도 부서마다, 사람마다 스프레드시트를 다르게 만든다. 이 지저분함(messiness)이 실세계의 본질이다.

기존 스프레드시트 벤치마크들 — SheetCopilot, SpreadsheetBench, SheetAgent — 이 존재했지만, 이들은 대부분 단일 과제나 인공적으로 구성된 시나리오에 집중했다. 실제 기업에서 일어나는 것처럼, 데이터 입력부터 계산, 검증, 시각화, 보고까지 한 워크플로우 안에서 연쇄적으로 일어나는 복합 과제를 평가하지는 못했다. FINCH의 저자들이 던지는 질문은 직설적이다 — 오늘날의 프론티어 AI 에이전트가 전문가들이 매일 직면하는 지저분하고, 장기적이며, 지식 집약적인 워크플로우를 실제로 처리할 수 있는가?

Enron의 유산에서 벤치마크를 캐다 — 데이터셋 구축

FINCH의 데이터는 인공적으로 만들어진 것이 아니다. 2001년 파산한 에너지 기업 Enron의 실제 업무 기록에서 왔다. Enron 이메일 코퍼스는 약 15,000개 스프레드시트와 150명 직원의 500,000개 이메일을 담고 있다. 20여 년 전의 기업이 남긴 디지털 유산이, 2025년 AI 벤치마크의 원석이 된 셈이다.

데이터셋 구축은 네 가지 경로로 이루어졌다. 첫째, 이메일 스레드에서 워크플로우를 발굴했다. GPT-5를 활용하여 비즈니스 목표를 명시하고 스프레드시트를 참조하는 협업 메시지를 식별한 뒤, 전문가가 검증했다. 둘째, 버전화된 스프레드시트에서 워크플로우를 추론했다. 같은 워크북의 다른 버전을 비교하여, 어떤 작업이 수행되었는지를 역추적했다. 셋째, 최종 산출물에서 역으로 워크플로우를 구성했다. 투자은행, 세계은행, 캐나다/영국 정부의 고품질 스프레드시트와 보고서를 활용했다. 넷째, 모든 워크플로우에 대해 주석자 간 교차 검증과 LLM 보조 품질 관리를 수행했다.

최종 결과물은 172개 복합 워크플로우다. 384개 과제, 1,710개 스프레드시트, 2,700만 셀, 그리고 PDF, 이미지, Word 문서 등 다양한 아티팩트를 포함한다. 700시간 이상의 도메인 전문가 노력이 투입되었다. 과제는 10가지 유형으로 분류된다.

과제 유형	워크플로우 수	설명
Calculation	119	수식 채우기, 순자산 계산, 집계 등
Structuring/Formatting	86	테이블 재구성, 계층 조정, 셀 포맷팅
Data Entry/Import	44	스프레드시트/PDF/이미지에서 데이터 전사
Validation/Review	37	일관성 검사, 계산 조정, 오류 검출
Cross-sheet/file Retrieval	36	다수 시트/파일에서 값 검색 및 참조
Summary/Visualization	33	요약 테이블이나 차트로 인사이트 도출
Financial Modeling	15	밸류에이션, 시나리오 분석, 타이밍 모델
Web Search	11	웹에서 금융 데이터 수집 후 스프레드시트 통합
Report	10	분석 결과를 문서 형태로 정리
Translation	3	구조/포맷 보존하며 언어 변환

이 과제들은 독립적이지 않다. 78.5%의 워크플로우가 2개 이상의 과제를 결합한 복합 워크플로우다. 데이터를 입력하고, 수식을 걸고, 교차 참조로 검증하고, 차트를 그리는 — 실제 업무의 흐름 그대로다. 86.6%가 다수 파일을 포함하고, 92.4%가 다중 시트(평균 8시트, 최대 91시트)로 구성된다. 셀 수의 중간값은 15,000개이며, 최대는 370만 셀에 달한다.

비즈니스 도메인도 다양하다. 보고(48개), 트레이딩/리스크(35개), 운영 관리(36개), 예측 모델링(33개), 예산/계획(26개), 가격/밸류에이션(15개), 매출채권/매입채무(10개), 조달/자산관리(10개) 등 8개 도메인을 포괄한다. 에너지 트레이딩에서 예산 편성까지, 금융·회계의 전 스펙트럼을 아우르는 것이다.

난이도 역시 단순한 분류가 아니라, 과제의 복합도와 데이터의 규모에 의해 자연스럽게 결정된다. 과제가 하나인 워크플로우와 다섯 개인 워크플로우는 질적으로 다른 도전이다. 또한 스프레드시트 자체의 멀티모달성도 난이도에 기여한다. 20.3%가 내장 차트를 포함하고, 10.5%가 PDF나 이미지 등 비스프레드시트 아티팩트와 연결되어 있다.

최전선의 성적표 — 벤치마크 결과

FINCH는 프론티어 AI 시스템을 두 가지 방식으로 평가했다. 프로덕트 사이드 에이전트(ChatGPT 5.1 Pro, Claude Sonnet 4.5)는 파일 업로드와 반복적 도구 호출이 가능한 환경에서 테스트되었다. 스프레드시트를 직접 검사하고, 중간 결과를 확인하고, 오류가 발생하면 수정을 시도할 수 있다. API 기반 모델(GPT 5.1, Gemini 3 Pro, Grok 4, Qwen3 Max 등)은 단일 호출로 Python 스크립트를 생성하여 스프레드시트를 직접 조작하는 방식이다. 반복적 정제 없이 한 번에 답을 내야 하므로, 조건이 훨씬 가혹하다.

평가는 인간 전문가의 pass/fail 판정과 LLM-as-Judge 자동 평가를 병행했다. 자동 평가의 인간 판단 일치율은 GPT 5.1 Pro 기준 82.1%, Claude Sonnet 4.5 기준 90.2%로, 합리적인 수준이다.

전체 통과율은 다음과 같다.

에이전트	유형	통과율 (인간 평가)
GPT 5.1 Pro	Product	38.4%
GPT 5.1	API	32.0%
Gemini 3 Pro Preview	API	27.3%
Claude Sonnet 4.5	Product	25.0%
Grok 4	API	23.8%
Claude Sonnet 4.5	API	20.3%
Qwen3 Max	API	14.5%

최고 성능인 GPT 5.1 Pro도 40%를 넘지 못한다. 워크플로우당 평균 16.8분을 소비하면서도 이 수준이다. Claude Sonnet 4.5는 프로덕트 모드에서 25.0%, API 모드에서 20.3%에 그쳤다. 오픈소스 진영의 Qwen3 Max는 14.5%로, 프론티어 독점 모델과의 격차가 뚜렷하다.

복합 워크플로우에서의 성능 저하는 더 극적이다.

과제 수	워크플로우 수	GPT 5.1 Pro 통과율	평균 소요 시간(분)
1	37	48.6%	13.1
2	84	42.4%	17.4
3	33	33.3%	18.7
4	10	0%	21.3
5	8	12.5%	13.6

과제가 2개를 초과하면 통과율이 급락한다. 4개 과제가 결합된 워크플로우에서는 GPT 5.1 Pro조차 통과율 0%다. 단계 간 오류 누적(error cascading)이 다단계 실행을 불균형적으로 해친다는 것을 보여준다. 한 단계에서의 작은 실수가 다음 단계로 전파되면서 전체 워크플로우를 무너뜨리는 것이다.

과제 유형별로 보면, Data Entry/Import와 Structuring/Formatting이 일관되게 가장 어려웠다. 지저분한 레이아웃과 비자명한 구조적 제약을 이해해야 하기 때문이다. Translation은 의외로 극도로 저조한 성적을 보였다. 단순히 텍스트를 번역하는 것이 아니라, 금융 문맥에서 헤더 계층, 행/열 정렬, 레이아웃 단서를 보존해야 하기 때문이다. 구조를 해치지 않고 번역하는 것은 번역이 아니라 재구성에 가깝다.

프로덕트 사이드와 API 기반의 성능 차이도 주목할 만하다. 같은 GPT 5.1이라도 프로덕트 모드(38.4%)가 API 모드(32.0%)보다 6.4%p 높다. Claude Sonnet 4.5도 프로덕트(25.0%)가 API(20.3%)를 4.7%p 앞선다. 반복적 실행과 중간 검사가 가능한 환경이 단일 호출보다 우월하다는 것은 직관적이지만, 그 차이가 이 정도에 그친다는 것은 — 반복 기회를 줘도 근본적인 한계는 크게 변하지 않는다는 뜻이기도 하다.

오류 분석에서 가장 지배적인 실패 원인은 수식 추론 오류(35%)였다. 스프레드시트 수식에 인코딩된 잠재적 비즈니스 로직을 모델이 재구성하지 못하는 것이다. 예를 들어, "IF NGPL MidContinent index (@ Baker)"라는 헤더가 일일 노출 지표처럼 보이지만, 관련 수식(25 * V21 + C41 * C22)은 실제로 55일 결제 타이밍을 인코딩하고 있다. 표시된 값과 숨겨진 로직 사이의 괴리를 파악하는 것이, 현재 LLM에게는 가장 큰 벽이다. 데이터 검색 오류(25%)와 코드 생성 오류(25%)가 그 뒤를 이었고, 과제 오해(10%)와 데이터 렌더링 오류(5%)가 나머지를 차지했다.

돋보기 아래의 균열 — 한계

FINCH의 기여는 분명하지만, 벤치마크 자체의 한계도 인식해야 한다.

첫째, 데이터의 시대적 특수성이다. Enron은 2001년에 파산한 에너지 기업이다. 그 스프레드시트는 20여 년 전의 업무 관행을 반영한다. 현재의 기업들이 사용하는 스프레드시트 — 클라우드 기반 협업, 실시간 데이터 연동, 매크로와 VBA 대신 Python 통합 — 와는 상당한 거리가 있을 수 있다. 세계은행이나 정부 자료로 일부 보완했지만, Enron 중심이라는 편향은 남아 있다.

둘째, 영어 중심이다. 글로벌 기업의 F&A 워크플로우는 다국어 환경에서 이루어지지만, FINCH는 영어가 지배적이다. 캐나다 정부 자료에 일부 프랑스어가 포함되어 있을 뿐이다.

셋째, API 기반 평가가 단일 LLM 호출로 제한되었다. 반복적 상호작용이나 자기 수정 없이 한 번에 Python 스크립트를 생성해야 하는 조건은, 실제 에이전틱 워크플로우와 거리가 있다. 프로덕트 사이드 에이전트(ChatGPT, Claude)는 반복적 도구 호출이 가능했기에 더 나은 성적을 보였지만, 이것이 모델 능력의 차이인지 인터페이스의 차이인지를 완전히 분리하기 어렵다.

넷째, LLM-as-Judge 자동 평가의 한계다. 인간 판단과의 일치율이 82~90%로 양호하지만, 미묘한 시각적 오류나 수식이 정적 값으로 대체되는 오류를 감지하기 어렵다는 점이 보고되었다. 수식 대신 하드코딩된 값이 들어간 셀은 겉보기에 정답이지만, 입력이 바뀌면 틀린 답이 된다. 이런 종류의 "깨지기 쉬운 정답"을 자동으로 잡아내는 것은 여전히 미해결 과제다.

2026년의 시선 — 스프레드시트와 엔터프라이즈 AI의 현실

2026년 4월 현재, 엔터프라이즈 AI 도입은 가속화되고 있다. Microsoft Copilot은 Excel에 깊이 통합되었고, Google Sheets에도 Gemini가 내장되었다. 스타트업부터 대기업까지, CFO와 재무팀에게 "AI가 스프레드시트를 대신 해준다"는 마케팅 메시지가 쏟아진다. 벤더들의 데모는 항상 단일 과제다 — 데이터를 정리하거나, 차트를 그리거나, 수식을 제안하거나. 깔끔한 데이터 위의 깔끔한 작업이다.

그런데 FINCH의 숫자를 다시 보라. 38.4%. 가장 강력한 프론티어 모델이, 16.8분을 쓰고도, 열 개 중 여섯 개의 워크플로우에서 실패한다. 단일 과제라면 절반 가까이 성공하지만, 과제가 복합되는 순간 성공률이 급락한다. 실세계 업무는 거의 항상 복합이다.

이 격차가 의미하는 것은 무엇인가? AI가 스프레드시트 업무에 쓸모없다는 뜻이 아니다. 단일 계산, 단순 포맷팅, 기본적인 데이터 입력에서 AI는 이미 실질적인 생산성 향상을 제공한다. 하지만 "AI가 재무 분석가를 대체한다"는 서사와 현실 사이에는 여전히 깊은 간극이 있다. 핵심은 복합성이다. 실세계 워크플로우의 지저분함과 장기성과 다단계 추론이 결합될 때, 현재의 AI는 한계를 드러낸다.

FINCH가 시사하는 현실적 전략은, AI Agents That Matter가 제기한 질문과 맞닿는다. "벤치마크가 실세계를 반영하는가?" FINCH의 과제들은 실제 기업 데이터에서 왔고, 실제 업무 프로세스를 반영한다. 이 벤치마크에서 40%도 넘지 못한다는 사실은, 엔터프라이즈 AI가 인간 전문가의 보조(augmentation)로서 가치를 제공하되, 완전한 자동화(automation)는 아직 먼 이야기임을 말해준다.

한 가지 더 주목할 점이 있다. FINCH 논문이 발표된 2025년 12월 이후, GPT 5.1이나 Claude Sonnet 4.5 같은 프론티어 모델의 추론 능력은 분명 향상되었다. 하지만 벤치마크의 핵심 교훈 — 복합 워크플로우에서의 급격한 성능 저하 — 은 단순히 모델을 더 크게 만든다고 해결되는 문제가 아니다. 오류 누적은 모델의 크기가 아니라 아키텍처와 워크플로우 설계의 문제이기 때문이다.

논문의 오류 분석이 제시한 다섯 가지 실패 속성 — 대규모 분절된 스프레드시트 생태계, 의미적으로 동질적인 금융 콘텐츠, 불규칙한 테이블 레이아웃, 수식에 잠재된 비즈니스 로직, 멀티모달 아티팩트 — 은 개별적으로는 모델이 합리적으로 대처할 수 있는 수준이다. 하지만 이들이 동일한 워크플로우 안에서 동시에 발생할 때, 그 복합(composition)이 성능을 급격히 떨어뜨린다. 개별 요소의 난이도를 합산한 것 이상의, 비선형적인 어려움이 생긴다. 이것이 실세계 엔터프라이즈 업무의 본질적 특성이며, 포장도로 위의 벤치마크가 포착하지 못하는 지점이다.

마무리

한 문장으로 줄이면 이렇다: "실세계 스프레드시트 워크플로우는 현재 최강의 AI에게도 40% 벽이며, 그 벽의 본질은 단일 과제가 아니라 과제들의 복합에 있다."

FINCH가 기업 내부의 업무 자동화를 평가했다면, 다음 글에서는 시선을 기업 바깥으로 돌린다. InvestorBench — 주식, 암호화폐, ETF에 걸쳐 LLM의 투자 의사결정 능력을 평가하는 벤치마크를 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열아홉 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: DocLLM — 레이아웃 인식 문서 이해 모델

Mon, 06 Apr 2026 17:00:00 GMT

논문 정보

제목: DocLLM: A Layout-Aware Generative Language Model for Multimodal Document Understanding

저자: Dongsheng Wang, Natraj Raman 외 (JPMorgan AI Research)

출판: arXiv 2401.00908 (2024.01)

지난 글에서 다룬 Won은 한국어 금융 NLP의 첫 좌표계를 그렸다. 5,500개 문항과 80,000건의 인스트럭션 데이터로 "한국어 금융을 평가하려면, 한국어 금융에서 태어난 잣대가 필요하다"는 것을 실증했다. 하지만 Won이 평가한 과제들은 한 가지 전제를 공유한다 -- 입력이 깔끔한 텍스트라는 전제다. 객관식 문항이든 개방형 질의든, 모델에게 주어지는 것은 정돈된 문장이었다.

실세계의 금융 문서는 그렇지 않다. 송장에는 금액이 오른쪽 열에, 항목명이 왼쪽 열에, 날짜가 상단에 흩어져 있다. 계약서에는 조항 번호가 좌측 마진에, 본문이 중앙에, 서명란이 하단에 배치된다. 영수증의 "500,000"이라는 숫자는 "매출" 옆에 있을 때와 "비용" 옆에 있을 때 의미가 완전히 다르다. 텍스트의 의미는 텍스트 자체가 아니라 텍스트가 놓인 위치에도 의존한다. Won이 연 문은 텍스트의 언어를 이해하는 것이었다면, 이 글이 다루는 문은 텍스트의 공간을 이해하는 것이다.

금융 에이전트가 실세계에서 작동하려면, 깔끔한 텍스트뿐 아니라 이런 시각적으로 복잡한 문서를 이해해야 한다. 그런데 기존의 비전-언어 모델은 이미지 전체를 처리하는 비용이 크다. 더 가벼운 방법은 없는가?

2024년 1월, JPMorgan AI Research가 이 문제에 대한 경량 해법을 제시한다. DocLLM -- 비전 인코더 없이, 바운딩 박스 좌표만으로 문서 레이아웃을 이해하는 LLM 확장이다.

문서를 읽는다는 것 -- 레이아웃이 의미를 만드는 세계

사람이 문서를 읽는 방식을 관찰하면 흥미로운 점이 있다. 우리는 글자만 읽지 않는다. 송장을 받으면 시선이 먼저 상단의 발행 날짜로 가고, 오른쪽 하단의 총액으로 이동하고, 그 사이의 항목 테이블을 훑는다. 양식을 작성할 때는 레이블과 입력란의 공간적 인접성으로 무엇을 어디에 써야 하는지 파악한다. 계약서를 검토할 때는 조항 번호의 계층 구조로 논리적 관계를 읽는다. 이 모든 과정에서 공간적 배치가 의미 해석의 핵심 단서로 기능한다.

엔터프라이즈 문서 -- 송장, 영수증, 계약서, 주문서, 양식 -- 는 기업 코퍼스의 상당 부분을 구성한다. 이 문서들에서 정보의 의미는 텍스트 내용과 공간적 위치의 교차점에서 결정된다. 테이블의 같은 열에 있는 숫자들은 같은 범주에 속하고, 같은 행에 있는 값들은 같은 항목을 설명한다. 이 관계는 텍스트만으로는 포착할 수 없다. 문서를 순수한 텍스트 스트림으로 변환하는 순간, 공간이 담고 있던 의미의 절반이 사라진다.

이 문제에 대한 기존 접근은 크게 세 갈래였다. 첫째, GPT-3.5나 Llama 같은 텍스트 전용 LLM. 이들은 공간 레이아웃을 아예 무시한다. 문서를 직렬화하면 "Name John Doe Address 123 Main St" 같은 평면적 시퀀스가 되고, "John Doe"가 "Name"의 값인지 "Address"의 값인지 구분할 수 없다. 둘째, mPLUG-DocOwl이나 UReader 같은 비전-언어 모델. 문서를 이미지로 처리하므로 레이아웃을 포착할 수 있지만, 비전 인코더가 필요하다. 모델 크기와 처리 시간이 크게 증가한다. 셋째, LayoutLM이나 UDOP 같은 레이아웃 특화 모델. 효과적이지만 과제별 파인튜닝이 필요하고 범용성이 부족하다.

DocLLM의 핵심 관찰은 단순하면서도 강력하다: 문서 레이아웃을 이해하는 데 이미지 픽셀은 과잉이다. 비전 인코더는 문서의 배경색, 글꼴 스타일, 테두리 두께까지 처리한다. 하지만 "500,000이 매출 열에 있다"는 정보를 전달하는 데 그런 디테일은 불필요하다. OCR이 추출한 텍스트의 바운딩 박스 좌표 -- (left, top, right, bottom) 네 개의 숫자 -- 만으로 충분하다. 비전 인코더라는 무거운 도구 없이, 좌표라는 가벼운 신호로 같은 문제를 풀 수 있다는 것이다. 이것은 비유하자면, 문서를 보지 않고 만지는 것이다. 점자를 읽듯이, 위치만으로 구조를 파악하는 접근이다.

네 개의 시선 -- 분리된 공간 어텐션의 설계

DocLLM의 핵심 메커니즘은 Disentangled Spatial Attention이다. 이름이 암시하듯, 텍스트와 공간이라는 두 모달리티의 상호작용을 분리하여 계산한다.

표준 트랜스포머의 셀프 어텐션은 텍스트 토큰 간의 관계만 계산한다. Query와 Key가 모두 텍스트 임베딩에서 나온다. 하나의 시선만 존재하는 셈이다. DocLLM은 이것을 네 개의 시선으로 확장한다.

입력 시퀀스의 각 텍스트 토큰에 바운딩 박스 b_i = (left, top, right, bottom)가 대응한다. 이 좌표 정보를 별도의 히든 벡터 S로 인코딩하고, 어텐션 행렬 계산을 네 가지 교차 모달 점수로 분해한다:

text-to-text: 표준 텍스트 간 어텐션. "매출"이라는 단어가 "이익"이라는 단어에 주의를 기울이는 것.
text-to-spatial: 텍스트가 공간에 주의. "500,000"이라는 텍스트가 다른 토큰의 위치 정보를 참조하여, 자신이 "매출" 열에 있는지 "비용" 열에 있는지 파악하는 것.
spatial-to-text: 공간이 텍스트에 주의. 특정 위치의 공간 벡터가 텍스트 내용을 참조하여, 그 위치에 어떤 종류의 정보가 있는지 학습하는 것.
spatial-to-spatial: 공간 간 어텐션. 두 토큰의 위치 관계 자체를 직접 계산. 같은 열에 있는지, 같은 행에 있는지, 인접한 블록인지를 파악하는 것.

각 교차 모달 상호작용에는 가중치 하이퍼파라미터가 부여되어 상대적 중요도를 조절한다. 공간 벡터 S는 레이어 간에 재사용되지만, 각 레이어의 프로젝션 행렬은 독립적이어서 유연성을 유지한다.

이 설계의 핵심 장점은 효율성이다. 비전 인코더를 추가하면 수억 개의 파라미터가 늘어나지만, 분리된 공간 어텐션은 공간 모달리티용 프로젝션 행렬만 추가하면 된다. 파라미터 증가가 현저히 적다. S를 텍스트 임베딩 H에 단순히 더하는 방식(additive positional encoding)보다 모달리티 간 선택적 초점이 가능하다는 점도 중요하다. 더하면 섞이고, 분리하면 선택할 수 있다.

제거 실험이 이 설계의 가치를 입증한다. 텍스트만 사용할 때(text-to-text만) NTP 정확도는 35.43이었다. 여기에 spatial-to-spatial만 추가하면 39.12로 뛰어올랐다 -- 가장 큰 단일 향상이다. 네 가지를 모두 조합하면 39.02로, spatial-to-spatial 하나만 추가한 것과 거의 동일했다. 공간 간의 직접적 관계 파악이 문서 이해에서 가장 강력한 신호라는 의미다.

빈칸 채우기의 지혜 -- 블록 인필링 사전 학습

DocLLM의 두 번째 혁신은 사전 학습 목적의 설계에 있다. 일반적인 언어 모델은 좌에서 우로 다음 토큰을 예측하는 방식으로 사전 학습된다. 이것은 소설이나 기사처럼 선형적으로 흐르는 텍스트에는 적합하지만, 문서에는 맞지 않는다.

문서의 텍스트는 선형적으로 흐르지 않는다. 송장에서 발행 날짜, 수신자 주소, 항목 테이블, 합계 금액은 공간적으로 분산되어 있고, OCR이 추출하는 순서가 의미의 순서와 일치하지 않을 수 있다. 선행 토큰만으로 다음 토큰을 예측하는 방식은, 수평으로도 수직으로도 엇갈려 배치된 문서 요소들 사이의 관계를 포착하기 어렵다.

DocLLM은 이 문제를 두 가지 수정으로 해결한다.

첫째, 코히시브 블록(cohesive block) 단위의 처리. 개별 토큰이 아니라 OCR 엔진이 식별한 의미적으로 응집된 텍스트 블록 -- "Name", "John Doe", "Doctor" 같은 단위 -- 을 기본 처리 단위로 삼는다. 블록의 더 넓은 맥락이 개별 토큰보다 나은 이해를 제공한다. 송장에서 "Total Amount"와 "$1,500.00"은 별개의 토큰이 아니라 하나의 의미 단위로 묶여야 한다.

둘째, 인필링(infilling) 접근법. 선행 토큰만이 아니라 선행과 후행 토큰 모두에 조건화하여 예측한다. 무작위로 선택된 텍스트 블록을 마스킹하고, 마스킹된 블록의 앞뒤 맥락을 모두 활용하여 빈칸을 채우는 것이다.

이 접근은 세 가지 이점이 있다: 맥락적으로 관련된 완성이 가능하고, OCR 노이즈에 대한 견고성을 제공하며, 다양한 문서 필드 간의 관계를 더 잘 처리한다. 양식에서 "이름" 필드가 마스킹되어도, 주변의 "주소", "전화번호" 필드가 어떤 종류의 정보가 들어가야 하는지 맥락을 제공하는 것이다.

형식적으로는 이렇게 동작한다. 전체 K개 텍스트 블록 중 M개(M이 K보다 훨씬 적은)를 무작위로 마스킹하고, 마스킹된 블록의 연속 토큰을 특수 토큰 [M]으로 교체한다. 각 마스킹된 블록에 시작 토큰 [S]와 끝 토큰 [E]를 부여하여, 모델이 시퀀스의 어디서부터 어디까지를 채워야 하는지 명확히 한다.

제거 실험에서 인과 학습만 사용하면 32.6, 인과 학습에 공간 모달리티를 추가하면 36.2, 블록 인필링에 공간 모달리티를 추가하면 39.1이었다. 블록 인필링이 인과 학습 대비 +2.9의 NTP 향상을 가져왔고, 공간 모달리티와의 결합 효과는 그보다 더 컸다. 흥미로운 부가 발견도 있다 -- 인과 디코더와 프리픽스 디코더 간 차이가 미미했다. 프리픽스 디코더의 양방향 어텐션이 이 맥락에서는 추가적 이점을 제공하지 않는다는 것이다. 읽기의 방향을 하나에서 둘로 늘린 것, 그리고 단위를 토큰에서 블록으로 넓힌 것이 문서 이해의 품질을 끌어올렸다.

숫자가 말하는 것 -- 16개 데이터셋의 증거

DocLLM은 네 가지 핵심 문서 지능 과제에 대해 평가되었다: VQA(시각적 질의응답), NLI(자연어 추론), KIE(핵심 정보 추출), CLS(문서 분류). 16개 데이터셋, 636K 학습 인스턴스, 97K 테스트 인스턴스에 걸친 포괄적 실험이다.

사전 학습에는 IIT-CDIP Test Collection(500만 문서, 1,600만 페이지)과 DocBank(50만 문서)를 사용하여 총 38.7억 토큰을 학습했다. 인스트럭션 튜닝에는 VQA 145K, NLI 104K, KIE 237K, CLS 150K -- 네 과제에 걸친 636K 학습 인스턴스를 사용했다. 모델은 DocLLM-1B(Falcon-1B 기반, 24레이어)와 DocLLM-7B(Llama2-7B 기반, 36레이어) 두 가지 변형으로 구축했다. 7B 모델은 8개 24GB A10g GPU에서 16비트 혼합 정밀도로 훈련되었다.

SDDS(Same Datasets, Different Splits) 평가 결과:

과제	데이터셋	GPT-4+OCR	Llama2+OCR	DocLLM-7B
VQA	DocVQA	82.8	47.4	69.5
VQA	BizDocs	76.4	48.8	86.7
NLI	TabFact	77.1	48.2	66.4
KIE	KLC	45.9	27.8	60.3
KIE	CORD	58.3	13.8	67.4
KIE	SROIE	90.6	56.4	91.9
KIE	BizDocs	66.1	10.8	95.9
CLS	RVL-CDIP	68.2	32.8	91.8
CLS	BizDocs	84.9	40.9	99.4

결과의 패턴은 명확하다. DocLLM-7B는 동등 크기 모델 기준 16개 데이터셋 중 14개에서 SOTA를 달성했다. 특히 KIE와 CLS -- 레이아웃에 가장 의존적인 과제 -- 에서 GPT-4를 일관되게 압도했다. BizDocs KIE에서 95.9 대 66.1, BizDocs CLS에서 99.4 대 84.9 -- 격차가 단순한 우위가 아니라 압도적이다. 송장에서 금액을 추출하고, 문서 유형을 분류하는 과제에서 공간 좌표가 이미지 이해보다 더 직접적인 신호가 된다는 것이다. 반면 VQA에서는 GPT-4가 우세했는데, 추론과 추상화의 복잡도가 높은 과제에서는 모델 크기의 차이가 드러났다.

일반화 능력도 인상적이다. STDD(Same Tasks, Different Datasets) 평가에서, 학습 시 보지 못한 5개 데이터셋 중 4개에서 최고 점수를 기록했다. Llama2-7B 대비 15~61%의 성능 향상이었다. 특히 KIE 과제에서의 일반화가 두드러졌는데, 새로운 형태의 송장이나 양식을 처음 보더라도 공간 패턴의 유사성을 포착하여 핵심 정보를 추출할 수 있었다. 분류 과제에서만 약세를 보였는데, 이는 단일 분류 데이터셋(RVL-CDIP)으로만 훈련된 한계다. 더 다양한 문서 유형으로 분류 학습을 확장하면 이 격차는 좁힐 수 있을 것이다.

DocLLM-1B도 7B 모델에 가까운 성능을 보여, 아키텍처 자체의 효과가 모델 규모보다 중요함을 시사한다. 1B라는 작은 모델이 레이아웃 집약적 과제에서 경쟁력을 가진다는 것은, 분리된 공간 어텐션이라는 구조적 혁신이 단순한 스케일링보다 효율적인 경로일 수 있다는 증거다.

보이지 않는 것과 열리지 않는 문 -- 한계

DocLLM의 한계는 그 강점의 이면에 있다.

첫째, OCR 의존성. DocLLM은 비전 인코더를 제거한 대가로 OCR에 전적으로 의존한다. 바운딩 박스의 품질이 OCR 엔진의 정확도에 직결되며, OCR이 텍스트를 잘못 인식하거나 바운딩 박스를 부정확하게 잡으면 모델의 성능이 하락한다. 논문 자체도 LayoutLMs의 선행 연구를 인용하며, Microsoft Azure OCR API가 TesseractOCR보다 우수한 성능을 보였음을 언급한다. OCR이라는 선행 단계의 품질이 모델의 천장을 결정하는 구조다.

둘째, 순수 시각 요소의 부재. 바운딩 박스는 텍스트의 위치를 알려주지만, 이미지 자체의 내용은 전달하지 않는다. 문서에 포함된 차트, 도장, 서명, 로고, 워터마크 -- 이런 비텍스트 시각 요소를 DocLLM은 이해할 수 없다. 논문은 향후 경량 방식으로 비전을 통합할 계획을 밝히지만, 현재 버전에서는 텍스트와 좌표가 전부다.

셋째, 비공개 모델. DocLLM은 JPMorgan AI Research의 산물이며, 모델 가중치가 공개되지 않았다. 재현 실험이 불가능하고, 커뮤니티가 개선에 기여할 수 없다. BloombergGPT와 마찬가지로, 금융 기관이 만든 모델이 금융 기관 안에 머무는 패턴이 반복된다.

넷째, 프롬프트 민감도. Zero-shot 결과가 프롬프트 문구에 민감하다는 점도 보고되었다. 논문에서는 3명의 독립적 프롬프트 엔지니어가 5라운드에 걸쳐 프롬프트를 정제했다. 실무 적용 시 프롬프트 설계에 상당한 공수가 필요할 수 있다는 의미다.

이 한계들은 DocLLM의 설계적 선택과 직결된다. 경량화를 위해 비전을 포기한 대가가 OCR 의존과 시각 요소 미인식이고, 금융 기관의 연구인 만큼 비공개는 예견된 귀결이다. 공학적 트레이드오프의 전형적 사례다 -- 하나를 얻으면 하나를 잃는다.

2026년의 시선 -- 좌표만으로 충분한가

DocLLM이 발표된 2024년 1월 이후 2년이 지났다. 그 사이 문서 이해 분야는 두 갈래로 갈라졌다.

한쪽은 비전-언어 모델의 급속한 발전이다. GPT-4V, Claude의 Vision 기능, Gemini의 멀티모달 이해 -- 이들은 문서를 이미지로 통째로 이해한다. OCR이 필요 없고, 차트도 읽고, 서명도 인식한다. DocLLM이 제거한 비전 인코더를, 2026년의 모델들은 더 효율적으로 통합했다. 비전 인코더의 비용이 급격히 낮아지면서, DocLLM의 "비전 없이도 된다"는 명제는 "비전이 있으면 더 좋고, 비용도 감당할 수 있다"는 현실에 도전받고 있다. 2024년 초에는 비전 인코더가 사치였지만, 2026년에는 표준이 되었다.

다른 쪽은 DocLLM이 열어젖힌 공간 인식 접근법의 심화다. 바운딩 박스라는 경량 신호의 가치는 여전히 유효하다. 엣지 디바이스에서의 문서 처리, 대량 문서 배치 처리, 비전 인코더의 지연이 허용되지 않는 실시간 시스템 -- 이런 맥락에서 좌표만으로 레이아웃을 이해하는 접근은 여전히 경쟁력이 있다. 특히 KIE -- 송장에서 금액을 추출하고, 양식에서 필드를 인식하는 과제 -- 에서 공간 좌표가 이미지 픽셀보다 더 직접적인 신호라는 DocLLM의 통찰은 후속 연구들에 의해 반복적으로 확인되었다.

흥미로운 것은 이 두 갈래가 대립이 아니라 상보적이라는 점이다. 비전-언어 모델이 문서의 전체적 이해에 강하다면, 공간 좌표 기반 접근은 구조화된 정보 추출에 강하다. 실무에서는 두 가지가 모두 필요하다. 문서를 분류하고 전체적 맥락을 파악하는 데는 비전이 유리하고, 특정 필드의 값을 정확히 추출하는 데는 좌표가 유리하다. 2026년의 최선의 문서 이해 파이프라인은 아마도 이 두 접근을 결합하는 것일 것이다.

DocLLM의 진정한 유산은 특정 모델이 아니라 설계 철학에 있다. "문서 이해에 필요한 최소한의 신호는 무엇인가"라는 질문을 던지고, "텍스트 + 좌표로 충분하다"는 답을 실증한 것이다. 이 철학은 비전-언어 모델이 지배하는 2026년에도 유효하다 -- 최소한의 신호로 최대한의 이해를 추구하는 것은 효율성의 핵심 원리이기 때문이다. BloombergGPT가 "도메인 데이터의 힘"을, FinGPT가 "오픈소스의 민주화"를 보여줬다면, DocLLM은 "구조적 신호의 효율성"을 보여준 논문이다.

마무리

한 문장으로 줄이면 이렇다: "문서를 이해하는 데 눈이 꼭 필요하지는 않다 -- 손끝으로 위치를 더듬는 것만으로도 레이아웃은 읽힌다."

DocLLM은 비전 인코더라는 무거운 눈을 제거하고, 바운딩 박스라는 가벼운 촉각으로 문서를 이해하는 모델이다. 분리된 공간 어텐션으로 네 가지 교차 모달 상호작용을 계산하고, 블록 인필링으로 문서의 비선형적 구조에 대응했다. 16개 데이터셋 중 14개에서 SOTA를 달성하고, 미지의 데이터셋에서도 견고하게 일반화되었다. 공간 좌표만으로 GPT-4를 KIE와 CLS에서 넘어선 것은, 문서 이해에서 진짜 중요한 신호가 무엇인지 다시 생각하게 만든다.

Won이 금융 텍스트를 평가하는 잣대를 세웠다면, DocLLM은 금융 문서의 공간적 의미를 읽는 방법을 제시했다. 다음 글에서는 이 문서 이해 능력이 실세계에서 어떻게 시험받는지를 본다. FINCH -- Enron의 실제 스프레드시트에서 추출한 172개 복합 워크플로우로, GPT 5.1 Pro조차 38.4%만 통과하는 엔터프라이즈 금융의 극한 난이도를 드러낸다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열여덟 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: ₩on — 한국어 금융 NLP의 첫 번째 벤치마크

Mon, 06 Apr 2026 13:00:00 GMT

논문 정보

제목: ₩on: Establishing Best Practices for Korean Financial NLP

저자: Guijin Son, Hyunwoo Ko, Hanearl Jung, Chami Hwang (OneLineAI, 한국거래소)

출판: arXiv 2503.17963 (2025.03)

지난 글에서 다룬 FinGPT는 오픈소스와 경량 파인튜닝으로 금융 LLM을 민주화하려는 프레임워크였다. BloombergGPT가 독점한 길을 열었고, 300달러의 LoRA 파인튜닝으로 감성 분석에서 ChatGPT를 넘어섰다. 하지만 FinGPT의 세계에서 한국어는 존재하지 않았다. 데이터도 영어와 중국어 중심이었고, 벤치마크도 영어 금융 과제에 맞춰져 있었다. 한국어 금융은 지도 위에 그려지지 않은 영역이었다.

이 부재는 단순한 번역의 문제가 아니다. 한국은 K-IFRS라는 고유한 회계 기준을 채택하고 있고, 금융위원회의 규제 체계와 한국거래소의 시장 구조는 미국이나 유럽과 다르다. "화폐의 시간가치에 관한 설명으로 옳지 않은 것은?" 같은 한국 금융 시험 문항을 영어 벤치마크를 번역해서 만들 수는 없다. 한국 금융을 평가하려면 한국 금융의 언어와 제도에서 태어난 벤치마크가 필요하다.

BloombergGPT는 영어 금융 데이터에 집중했고, FinGPT는 영어와 중국어 금융 데이터에 집중했다. 한국회계기준원(KIFRS), 금융위원회, 한국은행 — 한국 금융의 핵심 기관들이 생산하는 데이터로 LLM을 평가하거나 훈련한 체계적 연구는 2025년 3월 이전까지 부재했다. 한국어라는 언어적 특수성과 한국 금융이라는 제도적 특수성이 교차하는 지점에, 기존 연구는 닿지 못하고 있었다.

2025년 3월, OneLineAI와 한국거래소의 연구팀이 이 공백을 메운다. 5,500개 문항의 벤치마크, 80,000건의 인스트럭션 데이터셋, 그리고 한국 금융 특화 추론 모델까지 — 한국어 금융 NLP의 좌표계를 처음으로 그린 연구다.

번역으로는 닿을 수 없는 땅 — 한국어 금융 벤치마크의 필요성

외국어를 잘 아는 사람이 반드시 그 나라의 세법에 밝은 것은 아니다. 금융 NLP도 마찬가지다. 영어 금융 벤치마크를 한국어로 옮기면, 언어적으로는 한국어이되 제도적으로는 미국이다. 미국의 GAAP(Generally Accepted Accounting Principles)와 한국의 K-IFRS는 같은 거래를 다르게 분류할 수 있다. 한국거래소의 매매 제도, 금융위원회의 규제 용어, 한국 특유의 재벌 구조에 대한 기업 분석 — 이런 것들은 번역의 산물이 아니라 한국 금융 생태계 고유의 산물이다. "엑세스바이오의 COVID-19 진단 제품의 매출 기여와 미국 시장 판매에 대해 올바른 것은?" 같은 문항은 한국 상장 기업의 연간 보고서를 읽어야만 답할 수 있다.

기존에 한국어 금융 LLM을 평가할 도구가 전혀 없었던 것은 아니다. KRX-Bench는 한국 상장 기업에 대한 지식을 평가했고, KMMLU는 45개 카테고리 중 금융과 경제의 하위 집합을 포함했다. 하지만 이 벤치마크들은 금융 부문에서 LLM이 해야 할 일의 넓은 스펙트럼을 담지 못했다. 회계 추론, 주가 예측, 금융 에이전트로서의 코딩 능력까지 포괄하는 벤치마크는 없었다.

여기에 한국 금융 기관 특유의 제약도 있다. 금융위원회의 네트워크 분리 정책은 독점 모델(GPT-4 등)의 활용을 제한한다. 엄격한 보안 규정 때문에 외부 API 호출이 불가능한 환경에서, 금융 기관들은 오픈소스 모델을 자체 인프라에 배포해야 한다. 이때 어떤 모델이 한국 금융을 잘 이해하는지 평가할 수 있는 체계가 없으면, 선택 자체가 불가능하다. 환각이나 편향이 금전적 손실로 직결되는 도메인에서, 평가 없이 배포하는 것은 지도 없이 항해하는 것과 같다. 생성 AI의 위험을 관리하기 위한 명확한 가이드라인과 견고한 평가 프레임워크의 부재가, 한국 금융 기관의 AI 도입을 가로막는 핵심 장벽이었다.

벤치마크의 설계 — 8주, 5,500문항, 11개 데이터 소스

₩on의 벤치마크 설계는 한국 금융의 다층적 성격을 반영하려 한다. 회계를 아는 것과 시장을 아는 것은 다르고, 시장을 아는 것과 코드로 데이터를 분석하는 것은 또 다르다. 하나의 숫자로 금융 능력을 측정하는 것은 불가능하다. ₩on은 이 문제에 대해 5가지 객관식(MCQA) 카테고리와 1가지 개방형 QA라는 다면적 접근을 택했다.

카테고리	문항 수	평가 대상
재무회계 (F&A)	1,450	K-IFRS 기반 회계 추론, 대학 시험 수준
국내 기업 분석	2,039	한국 상장 기업의 연간 보고서 기반 지식
주가 예측	1,472	OHLCV 데이터 기반 가격 방향 이진 분류
금융 시장	642	한국 금융 법률과 매매 제도 이해
금융 에이전트	46	CSV 파싱, 코드 기반 데이터 분석
개방형 FinQA	100	법률 추론, 금융공학, 계량경제학

데이터 수집에서 특기할 점은 소스의 구성이다. 가장 많이 활용된 11개 도메인 중 대부분이 정부(go.kr)와 비영리(or.kr) 기관이다 — 한국거래소(krx.co.kr), 금융위원회(fsc.go.kr), 한국은행(bok.or.kr), 한국법령정보서비스(law.go.kr), 한국회계기준원(kasb.or.kr), K-IFRS(kifrs.com), 중소벤처기업부(mss.go.kr), 공정거래위원회(ftc.go.kr). 라이선스 프리 공공 데이터에서 금융 벤치마크를 구축할 수 있다는 것 자체가 하나의 발견이다.

각 카테고리의 문항 설계에도 세심한 공학이 들어갔다.

재무회계 문항은 대학 시험에서 주로 가져왔으며, 예비 라운드에서는 4지선다, 본 라운드에서는 8지선다로 난이도를 높였다. 임베딩 기반으로 유사 문항을 그룹핑하고, "위의 모든 항목" 옵션을 추가하거나 선택지 순서를 셔플하는 규칙 기반 증강을 적용한 뒤, 수동 검수로 정확성을 보장했다. 4지선다에서 8지선다로의 확장은 단순히 보기를 늘린 것이 아니라, 모델이 표면적 패턴 매칭이 아닌 진정한 이해에 기반하여 답해야 하도록 만든 설계다.

주가 예측 카테고리는 한국 주식시장의 OHLCV 데이터에서 2024년 이후 데이터만 무작위 샘플링하여, 기술적 지표(adj-close, inc-5~30 등)를 Markdown 테이블로 제공하고 가격 상승/하락을 이진 분류하게 했다. 모멘텀이나 평균 회귀 같은 기본적인 시그널을 감지하는 능력을 평가하는 과제다.

금융 에이전트 카테고리는 자동화된 금융 에이전트로서의 기능을 평가한다. CSV 파일과 지시가 주어지면 특정 정보를 추출하는 코딩 작업을 수행해야 하며, 교란된 출력 변형도 포함되어 있다.

개방형 FinQA는 가장 도전적인 카테고리다. KRX-Bench의 법률 추론, HRM8K의 고급 수학 문제, 대학원 수준의 금융공학/계량경제학 시험에서 100개를 큐레이팅하고, o1-Pro로 골드 스탠다드 답변을 생성한 뒤 GPT-4o를 LLM-as-a-Judge로 활용했다.

평가 방식도 독특하다. Zero-shot Chain-of-Thought로 모델이 추론을 생성하게 한 뒤, 원래 프롬프트와 생성된 추론을 합쳐 로짓 프로세서로 제공된 선택지 중 하나를 강제 선택하게 했다. 모델의 추론 능력과 최종 판단을 분리하여 평가하는 방식이다. 단순히 정답을 맞히는 것이 아니라, 왜 그 답을 선택했는지의 과정도 함께 드러나게 한 설계다.

리더보드는 2024년 10월부터 12월까지 약 8주간 운영되었다. 예비 라운드(10.14~~11.07)에서 478개, 본 라운드(11.13~~12.06)에서 641개, 총 1,119개 모델이 제출되었다. 233개 계정이 등록했고, 71개 팀이 최소 1개 모델을 제출했으며, 활성 팀당 평균 약 7개를 제출했다. 최다 일일 제출은 45건(11월 5일)이었다.

참가자의 52.5%가 기업(금융 23%, 기술 21.3%), 47.5%가 학생이었다. 총 상금 약 42,000달러와 본 라운드 진출 30개 팀에 AWS $2,500 크레딧이 제공되었고, 이 투자는 600개 이상의 공개 모델과 200,000건 이상의 데이터 샘플로 돌아왔다. 허용된 기본 모델은 Qwen(1.5B/7B), Mistral(7B), Llama 3/3.1(8B), Gemma2(2B/9B) 등으로 제한되어, 대형 기업의 자원 우위를 방지했다. 하루 1모델 제출 제한으로 스팸도 방지했다.

인스트럭션 데이터셋 구축 과정도 체계적이다. 참가 팀들이 HuggingFace에 올린 200,000건의 원시 데이터를 수집한 뒤, MinHash 중복 제거, 시간 종속 쿼리 필터링("카카오의 2024년 매출은?" 같은 시점 의존적 문항 제거), 불완전한 질문 필터링을 거쳐 최종 86,007건의 ₩on-Instruct 데이터셋을 만들었다.

대부분의 참가자들이 원시 코퍼스를 GPT-4o나 Qwen2.5-72B-Instruct로 MCQA 또는 Instruction-Response 형식으로 변환했으며, 일부는 LLM-as-a-Judge를 검증에 활용했다. 경쟁의 부산물이 공공재가 되는 구조 — 리더보드 대회가 동시에 데이터 크라우드소싱 플랫폼으로 기능한 것이다. 42,000달러의 상금이 80,000건의 고품질 인스트럭션 데이터를 만들어냈으니, 데이터 1건당 약 0.5달러의 비용이다. 전문가에게 직접 의뢰하는 것보다 훨씬 효율적인 방식이다.

리더보드 결과 — 추론의 힘과 지식의 벽

리더보드의 성과를 바탕으로, 연구팀은 자체적으로 한국 금융 특화 추론 모델 ₩on을 구축했다.

₩on 모델은 Qwen2.5-Math-7B-Instruct를 기반으로, SFT와 DPO 2단계로 훈련되었다. 기본 모델로 수학 특화 모델을 택한 것은 의도적이다 — 금융의 핵심이 수리적 추론에 있기 때문이다. 최근 추론 LLM 트렌드에 맞춰, <think>...</think> 태그 내에서 자기 교정 추론을 수행하고, <solution>...</solution> 태그 내에서 최종 요약을 제공하는 구조를 채택했다.

SFT 단계에서는 세 가지 소스의 데이터를 사용했다: (1) 영어 Prompt-R1 응답, (2) 한국어 Prompt-R1 응답, (3) 86K 프롬프트에 대해 DeepSeek-R1이 생성한 응답을 GPT-4o로 정답 필터링(최대 6회 재시도)하여 만든 약 400K 인스턴스. 여기서 세 번째 소스가 핵심이다 — R1의 추론 능력을 한국 금융 도메인에 증류(distillation)하는 것이다. GPT-4o가 정답 필터 역할을 하여, R1이 틀린 응답을 생성한 경우를 걸러냈다.

DPO 단계에서는 SFT 이후 나타나는 두 가지 문제를 교정했다. 첫째, 일상적인 프롬프트에서도 불필요하게 긴 추론을 수행하는 과잉 사고(overthinking). 둘째, MCQA 포맷을 따르지 않는 출력 형식 오류. 선택 샘플은 R1 생성에서, 거부 샘플은 SFT 모델에서 추출했다. 총 훈련 시간은 H100 8대, DeepSpeed-Zero1 기준 25시간이다.

본 라운드 상위 모델들의 성능을 보자.

모델	F&A	Market	Open-Ended	Average
overfit-brothers	0.65	0.83	0.01	0.50
AnonymousLLMer	0.63	0.65	0.04	0.44
shibainu24	0.56	0.67	0.04	0.43
₩on (연구팀)	0.78	0.66	0.18	0.54

₩on이 재무회계(0.78)와 개방형 FinQA(0.18)에서 최고 성능을 기록했고, 전체 평균에서도 0.54로 1위를 차지했다. 수학적이고 논리적인 추론이 요구되는 과제에서 탁월한 결과다. 개방형 FinQA에서 대부분의 모델이 0.00~0.04 수준에 머문 것을 감안하면, 0.18이라는 수치는 추론 모델의 구조적 우위를 보여준다.

반면 금융 시장(Market) 카테고리에서는 overfit-brothers(0.83)에 크게 뒤졌다. 이 카테고리는 한국 금융 법률과 매매 제도에 대한 사실적 지식에 의존하는데, 추론 중심 모델의 한계가 드러난 지점이다. Ha(2025)가 관찰한 것과 일치하는 패턴이다 — 추론 중심 모델은 도전적인 수학 문제에서 탁월하지만, 지식 집약적 도메인에서는 훈련이 진행될수록 오히려 성능이 저하될 수 있다. 추론은 칼이고 지식은 재료다. 칼이 아무리 날카로워도 재료가 없으면 요리를 만들 수 없다.

상위 팀들의 훈련 전략에서도 교훈이 있다. 예비 라운드에서는 모든 상위 10개 모델이 Qwen2.5-7B-Instruct 기반에 단순 SFT를 적용했다. 가장 큰 성능 향상은 국내 기업 분석 카테고리에서 나타났다(0.51에서 0.94로). 재무회계와 금융 시장 카테고리에서는 상대적으로 향상 폭이 작았는데, 단순 SFT만으로는 깊은 추론이 요구되는 과제의 성능을 끌어올리기 어렵다는 것을 시사한다.

본 라운드에서는 전략이 정교해졌다. Shinbainu 팀은 커리큘럼 기반 SFT(쉬운 샘플에서 어려운 샘플 순서)와 Evolve Instruct로 도전적 프롬프트를 생성한 뒤 DPO를 적용했다. Overfit Brothers 팀은 KTO(Kahneman-Tversky Optimization)를 활용했다.

하지만 가장 인상적인 결과를 낸 것은 Hi-Q 팀의 CPT + SFT + DPO 3단계 파이프라인이었다. CPT가 SFT 단독 대비 +2.7점의 향상을 가져왔고, 최종 CPT+SFT+DPO 조합이 평균 68.5로 최고점을 기록했다. 잘 구조화된 도메인 사전학습이 한국 금융 과제에서 유의미한 차이를 만든다는 실증이다. 다만 어떤 데이터로, 얼마나, 어떤 방식으로 CPT를 수행해야 최적인지에 대한 추가 연구는 여전히 필요하다.

열린 문 너머의 벽 — 한계와 과제

₩on이 한국어 금융 NLP의 첫 좌표를 찍었지만, 그 좌표가 지도의 전부는 아니다.

가장 근본적인 한계는 객관식 형식 자체다. 실무에서 금융 전문가가 마주하는 질문은 4지선다가 아니다. "이 기업의 현금흐름 구조를 분석하고 투자 의견을 제시하라"는 종류의 과제를 객관식으로 평가하는 것은 구조적으로 불가능하다. 개방형 FinQA 100건이 보완을 시도했지만, 대부분의 모델이 0.00~0.04 수준에 머문 것은 이 과제의 난도를 넘어 평가 방법론 자체의 미성숙을 드러낸다. 객관식은 지식의 존재를 확인할 수 있지만, 지식의 활용 능력은 확인하기 어렵다.

커버리지의 문제도 있다. 금융 에이전트 카테고리는 46문항에 불과하다. 보험, 부동산 금융, 파생상품 등 한국 금융의 중요한 하위 도메인이 충분히 반영되지 않았다. 기본 모델 제한(7B~9B급)도 공정성을 위한 선택이었지만, 더 큰 모델이나 다른 아키텍처의 가능성을 탐구하지 못한 제약이다. 70B급 모델이나 MoE(Mixture of Experts) 아키텍처가 한국 금융 과제에서 어떤 성능을 보일지는 여전히 열린 질문이다.

리더보드가 8주간만 운영되었다는 점도 아쉽다. 금융 시장은 끊임없이 변하고, 벤치마크도 그 변화를 반영하며 갱신되어야 한다. 2024년에 정확했던 기업 분석 문항이 2025년에는 이미 구식이 될 수 있다. 정적인 벤치마크는 시간이 지날수록 현실과 괴리가 벌어진다. 지속적으로 갱신되는 리빙 벤치마크(living benchmark)로의 전환이 필요하다.

₩on이 재무회계에서 0.78, 금융 시장에서 0.66이라는 것은 이 모델이 한국 금융의 약 70%를 이해한다는 뜻이 아니다. 특정 형식의 특정 질문에 대한 성능일 뿐이다. 벤치마크의 숫자가 실무 능력과 등치되는 것은 위험한 착각이며, 이 점을 인식하는 것이 벤치마크를 올바르게 사용하는 출발점이다.

2026년의 시선 — 한국 금융 AI의 좌표

₩on이 발표된 2025년 3월 이후 1년이 지났다. 그사이 한국 금융 AI 생태계는 빠르게 움직였다. KB금융, 신한금융 등 주요 금융지주사들이 자체 LLM 도입을 가속화하고 있고, 금융위원회도 AI 활용 가이드라인을 구체화하는 중이다. 한국 금융 기관들의 AI 수요는 더 이상 잠재적이지 않다 — 현실적이고 긴급하다.

₩on의 가장 큰 기여는 벤치마크 자체보다, 한국어 금융 NLP라는 연구 커뮤니티를 가시화한 것일 수 있다. 8주 동안 1,119개 모델이 제출되었다는 사실은, 수요가 공급보다 앞서 있었음을 보여준다. 참가자의 절반 이상이 기업이었다는 점도 의미심장하다 — 증권사, 은행, 기술 기업이 직접 모델을 훈련하고 제출했다는 것은, 이 문제가 학술적 호기심이 아닌 사업적 필요에서 비롯되었음을 뜻한다.

공공 데이터 기반의 벤치마크와 80K 인스트럭션 데이터셋은 후속 연구의 출발점이 된다. CPT + SFT + DPO 파이프라인이 한국 금융 도메인에서 효과적이라는 실증은, 실무 적용의 구체적 방향을 제시한다.

이 논문이 시사하는 더 넓은 교훈도 있다. 한국 정부와 공공 기관이 생산하는 데이터(go.kr, or.kr 도메인)가 금융 NLP의 핵심 학습 자원이 될 수 있다는 점이다. 홈택스, 오픈뱅킹, 전자공시시스템 — 한국 금융 인프라의 디지털화가 진행될수록, 이 공공 데이터의 가치는 커진다. ₩on은 그 가치를 처음으로 체계적으로 증명한 연구다.

남은 과제는 명확하다. 객관식을 넘어 실무 수준의 개방형 평가 체계 구축, 벤치마크의 지속적 갱신, 더 나은 CPT 전략의 탐구, 그리고 네트워크 분리 환경에서의 온프레미스 배포 — 평가에서 실전으로 넘어가는 다리가 아직 놓이지 않았다. 하지만 다리를 놓기 위해서는 먼저 강 양편의 위치를 아는 것이 필요하고, ₩on은 그 위치를 처음으로 측정한 연구다.

마무리

한 문장으로 줄이면 이렇다: "한국어 금융을 평가하려면, 한국어 금융에서 태어난 잣대가 필요하다."

₩on은 그 잣대의 첫 번째 버전이다. 5,500개 문항, 80,000건 인스트럭션 데이터, 1,119개 모델 제출 — 숫자만 봐도 한국어 금융 NLP 커뮤니티의 잠재력을 알 수 있다. 완벽하지는 않지만, 없는 것과 있는 것의 차이는 크다. 지도의 첫 번째 선이 정확하지 않아도, 그 선이 있어야 다음 사람이 더 나은 지도를 그릴 수 있다.

이 시리즈에서 BloombergGPT(독점 데이터), FinGPT(오픈소스 민주화), 그리고 ₩on(한국어 금융 벤치마크)까지 금융 NLP의 세 가지 접근을 살펴봤다. 금융의 언어는 각 나라의 제도 위에 서 있고, 그 제도를 이해하는 모델을 만들기 위해서는 그 제도에서 태어난 데이터와 평가 체계가 필요하다는 것이 일관된 교훈이다.

다음 글에서는 금융에서 문서 이해로 시선을 옮긴다. DocLLM — 비전 인코더 없이 바운딩 박스 좌표만으로 문서 레이아웃을 이해하는 경량 접근을 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열일곱 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: FinGPT — 오픈소스 금융 LLM 프레임워크

Mon, 06 Apr 2026 09:00:00 GMT

논문 정보

제목: FinGPT: Open-Source Financial Large Language Models

저자: Hongyang Yang, Xiao-Yang Liu, Christina Dan Wang (AI4Finance Foundation, Columbia University, NYU Shanghai)

출판: FinLLM 2023@IJCAI / arXiv 2306.06031 (2023.06)

지난 글에서 BloombergGPT를 읽었다. 40년치 독점 데이터, 50.6B 파라미터, 약 300만 달러의 훈련 비용. "독점 데이터가 경쟁 우위"라는 명제를 정면으로 입증한 연구였다. 인상적이지만, 그 글의 마지막에 던진 질문이 남아 있다 — 그 반대 방향은 가능한가?

2023년 6월, Columbia University와 NYU Shanghai의 연구자들이 AI4Finance Foundation이라는 이름 아래 정확히 그 질문에 답했다. FinGPT는 BloombergGPT의 거울상이다. 독점 대신 공개, 처음부터 훈련 대신 경량 적응, 수백만 달러 대신 300달러. 같은 문제를 전혀 다른 철학으로 풀겠다는 선언이다.

소프트웨어 산업에서 이 패턴은 낯설지 않다. Linux가 Unix에 대해 던진 질문, MySQL이 Oracle에 대해 던진 질문과 구조가 같다. 독점 시스템이 기술적 우위를 증명한 직후, 오픈소스 대안이 "충분히 좋은 수준"을 훨씬 낮은 비용으로 달성할 수 있음을 보여주는 패턴. FinGPT는 금융 LLM 분야에서 그 역할을 자처한 논문이다.

금융 AI를 둘러싼 이 논쟁은 기술적이면서 동시에 정치적이다. 누가 금융 언어를 이해하는 모델을 만들 수 있는가? Bloomberg 같은 거대 금융 정보 기업만의 특권인가, 아니면 대학 연구실과 스타트업도 참여할 수 있는 열린 경쟁인가? FinGPT는 후자에 건 논문이다. 그리고 이 시리즈에서 Toolformer가 도구 사용의 문을 열었듯, FinGPT는 금융 LLM의 문턱을 낮추려는 시도다.

성벽 안의 언어 — 금융 LLM의 접근성 문제

금융 데이터는 세 가지 고유한 난제를 가진다.

첫째, 높은 시간 민감도. 시장을 움직이는 뉴스가 공개되면 알파를 극대화할 수 있는 창은 몇 분에서 몇 시간이다. 어제의 데이터로 훈련한 모델이 오늘의 시장에서 유효하다는 보장이 없다.

둘째, 끊임없는 동적성. 경제 상황, 규제 변화, 지정학적 이벤트가 금융 환경을 매일 재구성한다. 모델을 한 번 훈련하고 고정하는 것은 금융에서 통하지 않는다. 그런데 전체 재훈련은 수백만 달러가 든다.

셋째, 낮은 신호 대 잡음비(SNR). 방대한 금융 데이터 속에 실제로 유용한 정보는 희박하게 흩어져 있다. 트위터의 루머, 뉴스의 반복 보도, 공시의 형식적 문구 — 이 노이즈를 걸러내지 않으면 모델은 시장의 신호가 아니라 소음을 학습한다.

BloombergGPT는 이 세 난제를 자원의 힘으로 돌파했다. 40년치 뉴스, SEC 공시, 금융 소셜 미디어를 축적한 FinPile 363B 토큰. 130만 A100 GPU 시간. 이 규모의 투자는 Bloomberg이기에 가능했다. 대부분의 금융 기관, 대학 연구실, 핀테크 스타트업에게는 재현 불가능한 접근이다.

비유하자면 이렇다. BloombergGPT는 성벽 안에 지은 도서관이다. 장서는 풍부하고 사서는 유능하지만, 입장권이 없으면 문 앞에 서는 것조차 불가능하다. FinGPT가 제기한 질문은 단순하다 — 성벽 밖의 공공 도서관으로도 충분히 읽을 수 있지 않은가?

이 질문에 답하기 위해, 먼저 두 접근의 철학적 차이를 정리할 필요가 있다.

차원	BloombergGPT	FinGPT
데이터	독점 (FinPile 363B 토큰)	공개 (뉴스, SEC, 소셜 미디어)
훈련 방식	처음부터 사전 훈련 (50.6B)	기존 모델 경량 파인튜닝 (LoRA)
비용	~$3,000,000 (130만 GPU 시간)	~$300
접근성	비공개, 재현 불가	오픈소스, 누구나 재현 가능
모델 업데이트	전체 재훈련 필요	경량 재파인튜닝으로 빠른 적응
과제 범위	17개 벤치마크 (넓은 범위)	감성 분석 중심 (깊은 집중)

같은 목적지를 향한 전혀 다른 경로다. 하나는 자원 집약적이고, 다른 하나는 지혜 집약적이다.

네 개의 층 — FinGPT의 설계 구조

FinGPT는 엔드투엔드 프레임워크를 네 개의 계층으로 설계했다.

첫 번째는 데이터 소스 계층이다. Reuters, CNBC, Yahoo Finance, MarketWatch 같은 뉴스 사이트, Twitter와 Reddit 같은 소셜 미디어, SEC와 NYSE의 공시 서류, Seeking Alpha와 Google Trends의 애널리스트 전망까지 — 공개적으로 접근 가능한 모든 금융 데이터 소스를 수집 대상으로 삼는다. Bloomberg의 독점 FinPile 대신, 인터넷 위에 흩어진 공개 데이터를 자동으로 긁어 모으는 전략이다.

두 번째는 데이터 엔지니어링 계층이다. 수집된 원시 데이터를 실시간 NLP 파이프라인으로 정제한다. 파이프라인은 다섯 단계로 구성된다: 데이터 정제(비관련 데이터 제거, 결측값 처리, 텍스트 정규화), 토크나이제이션(실시간 스트림 분해), 벡터 임베딩(도메인 적응 모델로 금융 텍스트를 의미 벡터로 인코딩), 특성 추출(TF-IDF, Word2Vec 등), 데이터 증강(실제 금융 데이터 특성을 모방하는 합성 데이터 생성). 특히 벡터 임베딩 단계에서 티커 심볼, 변동률, 이벤트 유형, 시간 메타데이터를 벡터에 통합하여 세밀한 금융 맥락을 포착하고, 벡터 DB에 인덱싱하여 저지연 검색과 RAG를 지원한다.

이 계층이 FinGPT의 "데이터 중심 접근"의 실체다. 모델 아키텍처가 아니라 데이터 파이프라인에 엔지니어링의 무게중심을 둔다.

세 번째는 LLM 계층이다. 모델을 처음부터 훈련하지 않는다. Llama, Mistral, Qwen 같은 기존 오픈소스 모델을 가져와서 LoRA(Low-Rank Adaptation)로 경량 파인튜닝한다. LoRA의 핵심은 원본 모델의 가중치를 고정한 채, 저차원 행렬 두 개만 훈련하는 것이다. 8B 파라미터 모델 전체를 움직이는 대신, 그 위에 얇은 적응 층을 덧씌우는 접근이다. Llama-3.1-8B 기준으로 훈련 가능 파라미터는 약 8.3M — 원본 8B의 0.1% 미만이다. 비용은 약 300달러.

여기에 RLSP(Reinforcement Learning on Stock Prices)라는 독자적 기법을 추가했다. 이름에서 알 수 있듯, RLHF(Reinforcement Learning from Human Feedback)의 금융 버전이다. RLHF가 인간 선호도를 보상으로 쓰듯, RLSP는 뉴스 발행 후 실제 주가 변동을 보상 함수로 쓴다. 환경은 금융 시장이고, 보상은 뉴스 후 주가 반응이다. 감성 분석의 출력을 시장의 실제 반응과 정렬함으로써, 모델이 "금융적으로 올바른" 감성을 학습하게 한다. 인간 주석자의 판단이 아니라 시장 자체의 판단을 정답으로 삼는 것이다.

네 번째는 응용 계층이다. 감성 분석, 로보어드바이저, 퀀트 트레이딩, 포트폴리오 최적화, 신용 점수, 사기 탐지까지 — 금융 실무의 다양한 과제를 커버한다. 논문은 각 응용에 대해 실습 튜토리얼과 데모를 제공하여, 프레임워크의 실용적 진입 장벽을 낮추려 했다.

이 네 계층 구조에서 주목할 점은 LLM이 세 번째 계층이라는 사실이다. 첫 번째와 두 번째 — 데이터 수집과 정제 — 가 모델보다 앞에 놓여 있다. 이것이 FinGPT가 스스로를 "데이터 중심 접근"이라 부르는 이유다. 모델은 교체 가능한 부품이고, 데이터 파이프라인이 프레임워크의 진짜 뼈대다. Llama가 아닌 Mistral을 쓰더라도, Qwen을 쓰더라도, 앞의 두 계층은 동일하게 작동한다.

300달러의 감성 분석 — 벤치마크가 말하는 것

FinGPT의 주력 실험은 금융 감성 분석이다. 62만 건 이상의 금융 뉴스 헤드라인을 CNBC, Reuters, Yahoo Finance, MarketWatch에서 수집하고, 뉴스 발행 후 단기 주가 변동으로 자동 레이블링했다. 수동 주석 비용을 회피하면서, 감성을 실제 시장 반응과 연결하는 접근이다.

데이터셋의 레이블링 방식이 흥미롭다. 사람이 직접 "긍정/부정/중립"을 태깅하는 대신, 뉴스 발행 후 단기 주가 변동률 r을 기준으로 자동 분류했다. r이 양의 임계값을 넘으면 Positive, 음의 임계값 아래면 Negative, 그 사이면 Neutral이다. 감성의 정의를 "시장이 실제로 어떻게 반응했는가"에 묶은 것이다. 수동 주석의 비용과 주관성을 동시에 회피하는 전략이지만, 주가 변동이 반드시 해당 뉴스의 감성만을 반영하지는 않는다는 한계도 있다.

Llama-3.1-8B-Instruct를 기반으로 2단계 적응을 수행했다. 1단계는 LoRA 기반 지도 파인튜닝(SFT)으로, rank=8, scaling factor alpha=16의 표준 구성에서 약 8.3M의 파라미터만 훈련한다. 2단계는 RLSP를 통한 시장 정렬이다. RLHF가 인간 선호도를 보상으로 쓰듯, RLSP는 실제 주가 반응을 보상 함수로 쓴다.

모델	정확도	Macro-F1
Llama3.1-8B (zero-shot)	57.9	54.4
ChatGPT (zero-shot)	63.4	61.7
FinBERT	71.2	69.9
FinGPT (LoRA-SFT)	78.8	77.3
FinGPT (SFT + RLSP)	82.1	80.9

ChatGPT 대비 +18.7% 정확도, FinBERT 대비 +10.9% 정확도. 300달러짜리 파인튜닝이 세계 최고 수준의 범용 모델과 금융 특화 BERT 모델을 모두 넘어선 것이다.

제거 실험(ablation)에서는 Base Llama3의 54.4에서 LoRA SFT가 77.3으로 끌어올리고, RLSP가 80.9으로 마무리했다. LoRA가 대부분의 무거운 작업을 수행하고, RLSP가 시장 정렬이라는 마지막 한 겹을 더한 구조다.

주목할 점은 각 단계의 기여분이다. Base Llama3에서 LoRA SFT로의 점프가 54.4 -> 77.3으로 +22.9, SFT에서 RLSP 추가가 77.3 -> 80.9로 +3.6이다. LoRA가 전체 개선의 약 86%를 담당했다. 이는 경량 파인튜닝만으로도 도메인 적응의 대부분이 달성 가능하다는 강력한 증거다. RLSP는 "마지막 한 겹"이지만, 시장의 실제 반응과 모델 출력을 정렬한다는 점에서 질적으로 중요한 한 겹이다.

사례 하나가 이 차이를 선명하게 보여준다. "Tesla cuts prices again in China as EV competition intensifies"라는 헤드라인에 대해, 기본 Llama3는 Neutral을 출력했다. 표면적 문구만 읽은 것이다 — "가격 인하"를 소비자에게 좋은 것으로, "경쟁 심화"를 중립적 시장 현상으로 해석한 셈이다. FinGPT는 Negative를 출력했다. 가격 인하가 경쟁 압박과 마진 압축을 의미한다는 금융적 맥락을 읽어낸 것이다. 실제 후속 주가도 하락했다. 같은 문장을 읽고도 "소비자의 시선"과 "투자자의 시선"이 다르다는 것을 모델이 학습한 것이다.

공공 도서관의 한계 — FinGPT가 말하지 않는 것

숫자가 인상적이지만, 정직한 평가가 필요하다.

첫째, 실험이 감성 분석 하나에 집중되어 있다. 금융 NER, 수치 추론, 질의응답 같은 다른 핵심 과제에 대한 체계적 평가가 없다. BloombergGPT가 5개 외부 벤치마크와 12개 내부 벤치마크에서 검증된 것과 대조적이다. 깊이 대 넓이의 트레이드오프에서 FinGPT는 깊이를 선택했고, 그 선택의 대가는 일반화 가능성에 대한 불확실성이다.

둘째, 데이터 품질의 문제다. 공개 소스 데이터는 접근성은 높지만, 노이즈도 높다. 소셜 미디어의 루머, 뉴스의 편향, 공시의 형식적 차이 — Bloomberg가 40년간 정제해온 데이터와 인터넷에서 자동 수집한 데이터 사이에는 품질 격차가 존재한다. 논문 스스로도 금융 데이터의 "낮은 SNR"을 핵심 도전으로 꼽으면서, 그 도전을 자동화된 파이프라인만으로 얼마나 해결할 수 있는지에 대한 정량적 분석은 부족하다.

셋째, 시간적 감쇠(temporal decay)다. 금융 데이터의 유효 기간은 짧다. FinGPT의 경량 재파인튜닝 능력은 이론적으로 빠른 업데이트를 가능하게 하지만, 실제로 얼마나 자주, 얼마나 빠르게 모델을 갱신해야 성능을 유지할 수 있는지에 대한 실험이 빠져 있다. 2016~2024 데이터로 훈련한 모델이 2025년 시장에서도 같은 정확도를 보일 것이라는 보장이 없다.

넷째, 영어 중심의 설계다. 논문의 데이터 소스와 실험은 모두 영어 금융 데이터에 기반한다. 금융 시장은 글로벌하지만, 금융 언어는 지역적이다. 한국의 DART 공시, 일본의 EDINET, 중국의 CNINFO — 각국의 금융 데이터는 형식과 용어가 다르다. "실적이 컨센서스를 하회했다"라는 한국어 문장의 감성을 영어 데이터로 훈련한 모델이 정확히 판단할 수 있을까? 이 다국어 확장에 대한 로드맵은 향후 과제로 남겨졌다.

이 한계들을 종합하면, FinGPT는 "오픈소스 금융 LLM이 가능하다"는 개념 증명(proof of concept)에는 성공했지만, "프로덕션에 투입할 수 있다"는 증명에는 아직 도달하지 못한 것이다. 프레임워크의 가치와 실전 적용 사이의 간극 — 이것이 후속 연구가 채워야 할 공간이다.

2026년의 시선

FinGPT가 발표된 2023년 6월 이후 약 3년이 흘렀다. 오픈소스 금융 LLM의 풍경은 FinGPT의 저자들조차 예상하지 못했을 정도로 변했다.

가장 큰 변화는 기반 모델 자체의 진화다. FinGPT가 초기에 기반으로 삼은 Llama-2는 Llama-3, Llama-4로 세대를 거듭했고, Mistral, Qwen, DeepSeek 같은 강력한 경쟁 모델들이 등장했다. 기반 모델이 강해질수록 경량 파인튜닝의 출발점이 높아지고, FinGPT 같은 프레임워크의 잠재력도 함께 올라간다. 300달러의 적응이 더 강력한 모델 위에서 이루어진다면, 성능 천장도 함께 올라간다. 논문의 최신 버전(v2, 2025.11)이 이미 Llama-3.1과 Qwen3을 지원 모델 목록에 추가한 것이 이를 반영한다.

또 하나의 변화는 에이전트와의 결합이다. 이 시리즈에서 읽어온 ReAct, Toolformer, AutoGen 같은 에이전트 프레임워크와 금융 LLM이 만나면서, 단순한 감성 분석을 넘어 자율적 금융 분석 에이전트의 가능성이 열리고 있다. FinGPT의 4계층 프레임워크가 에이전트 시스템의 도구 계층으로 편입되는 미래를 상상할 수 있다.

FinGPT가 제안한 "데이터 중심 + 경량 파인튜닝" 패러다임은 금융을 넘어 의료, 법률, 교육 등 다른 도메인 특화 LLM에서도 반복되고 있다. 독점 데이터로 거대한 모델을 처음부터 훈련하는 대신, 공개 모델 위에 도메인 지식을 얹는 접근이 사실상의 표준이 됐다. BloombergGPT의 "성벽 안 도서관"이 틀렸다기보다, FinGPT가 보여준 "성벽 밖 도서관"의 비용 효율이 대부분의 조직에게 더 현실적이었던 것이다.

동시에, 경량 파인튜닝 자체에 대한 회의도 커졌다. RAG(검색 증강 생성)가 발전하면서, 파인튜닝 없이도 도메인 지식을 주입할 수 있다는 주장이 힘을 얻었다. FinGPT의 LoRA + RLSP가 여전히 RAG 기반 접근 대비 우위를 유지하는지는 2026년 현재 열린 질문이다.

그리고 FinGPT가 남긴 가장 중요한 유산은 아마도 질문 자체일 것이다 — "금융 LLM은 독점의 영역인가, 공유의 영역인가?" 이 질문은 3년이 지난 지금도 답이 갈린다. 하지만 적어도 "공유"가 선택지에 올라온 것은 FinGPT 때문이다. AI4Finance Foundation이 오픈소스 커뮤니티를 중심으로 코드, 데이터, 벤치마크를 공개한 것은 기술적 기여를 넘어, 금융 AI 연구의 생태계 자체를 변화시키려는 시도였다.

마무리

한 문장으로 줄이면 이렇다: "금융 LLM에 수백만 달러가 필요하다는 전제를 300달러로 반박한 논문."

FinGPT의 기여는 모델이 아니라 프레임워크에 있다. 데이터 수집부터 파인튜닝, 응용까지의 파이프라인을 오픈소스로 공개함으로써, "나도 금융 LLM을 만들 수 있다"는 가능성을 열었다. 물론 BloombergGPT의 독점 데이터가 주는 깊이를 공개 데이터가 완전히 대체할 수 있는지는 여전히 증명되지 않았다. 감성 분석이라는 단일 과제에서의 성공이 금융 NLP 전반으로 확장될 수 있는지도 열린 문제다. 하지만 최소한, 성벽 밖에서도 싸울 수 있다는 것은 보여줬다.

BloombergGPT가 "이것이 가능하다"를 증명했다면, FinGPT는 "이것이 당신에게도 가능하다"를 증명하려 했다. 전자가 기술의 경계를 넓혔다면, 후자는 기술의 접근성을 넓혔다. 둘 다 필요한 일이고, 둘 다 같은 방향을 가리킨다 — 금융은 언어를 이해하는 기계를 필요로 한다.

다음 글에서는 시선을 한국어 금융 NLP로 좁힌다. FinGPT가 영어 중심이라는 한계를 지적했는데, 바로 그 빈칸을 채우려는 연구다. Won — 한국어 금융 벤치마크와 리더보드를 최초로 구축하여, "한국어로도 금융 LLM을 평가할 수 있는가?"라는 질문에 답한 논문을 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열여섯 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: BloombergGPT — 금융 특화 대규모 언어 모델의 탄생

Sun, 05 Apr 2026 17:00:00 GMT

논문 정보

제목: BloombergGPT: A Large Language Model for Finance

저자: Shijie Wu, Ozan İrsoy, Steven Lu 외 (Bloomberg, Johns Hopkins University)

출판: arXiv 2303.17564 (2023.03)

지난 글에서 다룬 Tool Use Evolution 서베이는 도구 사용의 전체 지형을 조망했다. 단일 호출의 정확성에서 다중 오케스트레이션의 견고성까지, 에이전트가 외부 세계와 상호작용하는 방식의 진화를 6가지 차원으로 정리한 지도였다. 그 지도 위에는 범용적인 도구들 -- 검색 API, 코드 실행기, 브라우저 -- 이 놓여 있었다. 하지만 도구가 아무리 정교해져도, 도구를 쥐는 손 자체가 금융의 언어를 모르면 어떻게 될까?

시리즈가 여기서 방향을 전환한다. 지금까지 열네 편의 논문은 에이전트의 범용적 능력 -- 추론, 행동, 도구 사용, 학습, 평가 -- 을 다뤘다. ReAct로 추론과 행동을 엮고, Reflexion으로 실패에서 배우고, Voyager로 열린 세계를 탐험하고, Toolformer로 도구를 집어들었다. 이 모든 능력은 범용적이었다. 어떤 도메인에서든 작동하도록 설계된 것이었다.

이제부터 여섯 편의 논문을 통해 이 범용적 능력이 특정 도메인, 특히 금융에서 어떻게 구현되고 평가되는지 살펴본다. 범용에서 특화로의 전환 -- 그 첫 번째 문은 Bloomberg이 연다.

2023년 3월, Bloomberg의 AI 연구팀이 금융 특화 대규모 언어 모델을 발표했다. 50.6B 파라미터, 708B 토큰. 숫자 자체도 인상적이지만, 진짜 의미는 데이터에 있다. Bloomberg가 40년간 축적한 금융 데이터 -- 뉴스, 보고서, SEC 제출 문서, 금융 소셜 미디어 -- 를 FinPile이라는 363B 토큰의 코퍼스로 구성했다. 당시 기준으로 가장 큰 도메인 특화 데이터셋이었다. 이것은 돈으로 살 수 없는 데이터다.

이 논문이 중요한 이유는 모델의 성능 자체만이 아니다. "독점 데이터를 가진 기업이 도메인 특화 LLM을 구축하면 어떤 일이 일어나는가"라는 질문에 최초의 대규모 실증적 답변을 제공했다는 점에서 의미가 있다. 학계가 공개 데이터로 실험하는 동안, 산업계가 자기만의 금광으로 무엇을 캘 수 있는지 보여준 사례다.

만능 칼과 회칼 -- 범용 모델이 금융에서 부딪히는 벽

범용 언어 모델은 만능 칼이다. 어떤 재료든 자를 수 있지만, 참치 해체에는 쓸 수 없다. 금융 텍스트가 바로 그 참치다.

"COMPANY to cut 10,000 jobs" -- 이 문장의 감성은 무엇인가? 일상 언어로 읽으면 부정적이다. 사람들이 일자리를 잃는다. 그러나 금융 시장에서 이 뉴스는 구조조정에 따른 비용 절감 기대로 주가를 올린다. 감성이 뒤집힌다. "10-K filing"이라는 단어를 보고 일반 모델은 등산 대회를 떠올릴 수도 있지만, 금융에서는 기업의 연간 보고서를 뜻한다. 같은 단어, 다른 의미. 같은 문장, 반대의 감성.

금융 텍스트의 특수성은 감성만이 아니다. 숫자의 밀도가 일반 텍스트와 비교할 수 없이 높다. "Revenue increased 12.3% YoY to $4.7B, beating consensus estimates of $4.5B" 같은 문장에서 모델은 비율, 절대값, 시간 비교, 시장 기대치와의 차이를 동시에 파악해야 한다. 약어도 독특하다. YoY(Year over Year), EPS(Earnings Per Share), EBITDA -- 이런 용어들이 문장마다 등장하고, 문맥에 따라 의미가 미묘하게 달라진다.

2023년 이전까지 도메인 특화 모델의 성공 사례는 이미 있었다. 코드에는 Codex, 과학 논문에는 Galactica, 의학에는 Med-PaLM. 각각이 범용 모델보다 해당 영역에서 우월했다. 그러나 금융 도메인에서는 아무도 이 실험을 대규모로 수행하지 않았다. 물론 FinBERT처럼 BERT를 금융 텍스트로 파인튜닝한 소규모 시도는 있었지만, LLM 규모에서의 도메인 특화 사전 훈련은 전례가 없었다.

이유가 있다. 금융 데이터는 대부분 독점적이다. 학술 기관이 구할 수 있는 금융 텍스트의 양은 제한적이다. 뉴스 기사는 라이선스가 필요하고, 기업 공시는 접근이 어렵고, 소셜 미디어 데이터는 정제가 필요하다. Bloomberg는 달랐다. 40년간 쌓아온 뉴스, 공시, 보도자료, 웹 크롤 데이터가 있었다. 데이터의 양만이 아니라, 큐레이션의 깊이가 달랐다. 금융 전문가가 분류하고 정제한 데이터였다.

핵심 질문은 이것이었다: 도메인 데이터만으로 훈련할 것인가, 범용 데이터와 섞을 것인가? 전자는 금융에 강하지만 범용 능력을 잃는다. 후자는 양쪽을 유지할 수 있지만, 도메인 특화의 날이 무뎌질 수 있다. 의학 분야에서 PubMedBERT가 도메인 데이터만으로 처음부터 훈련하여 일반 BERT를 의학 과제에서 넘어선 사례가 있었고, 반대로 Galactica는 과학 데이터 48M 논문에 범용 데이터를 섞어 과학적 지식과 범용 능력을 동시에 유지했다. BloombergGPT는 Galactica의 혼합 전략을 택하되, 비율에 승부를 걸었다. 금융 데이터의 비율을 어디까지 높이면 범용 능력이 무너지기 시작하는가? 이 경계를 탐색하는 것이 BloombergGPT의 핵심 실험이다.

FinPile이라는 금광 -- 363B 토큰의 설계

BloombergGPT의 진짜 기여는 모델 아키텍처가 아니라 데이터 설계에 있다. 아키텍처는 기존 BLOOM을 따랐고, 훈련 기법도 표준적이었다. 차별화의 원천은 오직 데이터다. FinPile은 다섯 가지 원천으로 구성된 363B 토큰의 금융 코퍼스다.

원천	토큰 수	비율	내용
Web	298B	42.01%	Bloomberg이 선별한 금융 관련 고품질 웹사이트
News	38B	5.31%	금융 커뮤니티 관련 뉴스 (Bloomberg 자체 기사 제외)
Filings	14B	2.04%	SEC 공시 (10-K, 10-Q 등), EDGAR 출처
Press	9B	1.21%	기업 보도자료
Bloomberg	5B	0.70%	Bloomberg 자체 뉴스, 의견, 분석

주목할 점은 FinPile의 구성 비율이다. Web이 298B로 압도적이지만, 이것은 일반적인 웹 크롤이 아니다. Bloomberg이 금융 관련 고품질 웹사이트를 선별하여 수집한 것이다. Filings 카테고리는 14B 토큰으로 비율은 작지만, 후에 벤치마크에서 가장 큰 성능 격차를 만들어낸다. SEC 공시 문서는 표와 차트가 밀집된 PDF 형식으로, 기존 LLM 훈련 데이터와 근본적으로 다른 문서 유형이기 때문이다.

여기에 공개 데이터셋 345B 토큰(The Pile 184B, C4 138B, Wikipedia 24B)을 합쳐 총 708B 토큰의 혼합 코퍼스를 만들었다. 금융 51%, 범용 49% -- 거의 정확히 반반이다. 이 비율은 직관적인 것 같지만, 실은 Chinchilla 스케일링 법칙과의 절충에서 나온 결과다.

Chinchilla 법칙에 따르면, 주어진 계산 예산(1.3M A100 GPU 시간)에서 최적 모델은 약 50B 파라미터에 1,100B 토큰으로 훈련해야 한다. 그러나 Bloomberg이 확보할 수 있는 금융 데이터는 363B 토큰이 한계였다. 범용 데이터를 아무리 늘려도 금융 데이터의 양은 변하지 않는다. 여기서 실용적 타협이 이루어진다. 범용 데이터를 345B 추가하여 총 708B 토큰을 확보하되, 이는 여전히 Chinchilla 최적인 1,100B에 크게 못 미친다. 그래서 708B 토큰에서 훈련을 멈추되, 모델 크기는 Chinchilla 최적 근처인 50.6B로 유지하는 전략을 택했다. 이론적 최적보다 토큰이 부족하지만, 큐레이팅된 도메인 데이터의 품질로 그 격차를 메우겠다는 판단이었다. 결과적으로 이 판단은 벤치마크에서 검증된다.

모델 아키텍처는 BLOOM을 기반으로 한 decoder-only 트랜스포머다. 70개 레이어, 40개 어텐션 헤드, 히든 차원 7,680. 총 50.6B 파라미터. BLOOM 아키텍처를 선택한 것은 실용적 이유가 크다 -- BLOOM 프로젝트의 일환으로 개발된 기존 코드와 인프라를 활용할 수 있었기 때문이다. 논문은 이를 "적당한 규모의 팀이 도메인 특화 데이터로 경쟁력 있는 모델을 생산할 수 있음"을 보여주는 사례로 제시한다.

ALiBi 위치 인코딩을 사용했고, Unigram 토크나이저에 131,072 어휘를 부여했다 -- 표준 50,000보다 2.6배 큰 어휘로, 금융 전문 용어를 효율적으로 인코딩하기 위한 선택이었다. 토크나이저 설계도 독특했는데, The Pile의 22개 도메인을 256 청크로 분할하여 병렬로 토크나이저를 훈련한 뒤 계층적으로 병합하는 방식을 사용했다. 큰 어휘는 같은 길이의 컨텍스트 윈도우(2,048 토큰)에 더 많은 정보를 담을 수 있게 해준다.

훈련은 Amazon SageMaker에서 64개 p4d.24xlarge 인스턴스(총 512개 A100 40GB GPU)로 53일간 수행되었다. ZeRO Stage 3로 모델 파라미터, 그래디언트, 옵티마이저 상태를 128 GPU 그룹에 걸쳐 샤딩하고, MiCS로 클라우드 클러스터의 통신 오버헤드를 줄였다. Mixed Precision 훈련으로 포워드/백워드 패스는 BF16, 파라미터 저장과 업데이트는 FP32로 분리했다. AdamW 옵티마이저를 사용했고, 학습률은 6e-5에서 코사인 감쇠를 적용했다.

논문의 부록에는 "Training Chronicles"라는 이례적인 섹션이 있다. 53일간의 훈련 과정에서 내린 의사결정을 날짜별로 기록한 일지다. Step 7,200에서 배치 크기를 1,024에서 2,048로 변경하고, Step 115,500에서 검증 손실이 정체하기 시작했을 때 학습률을 2/3로 낮추고, Step 129,900에서 다시 절반으로 낮추면서 dropout 0.1을 추가하고, 최종적으로 Step 139,200에서 569B 토큰(코퍼스의 80%)을 학습한 시점에 조기 종료했다.

이 과정은 마치 선원이 항해 일지를 쓰는 것과 같다. 바람이 바뀌면 돛을 조정하고, 폭풍이 오면 속도를 줄이고, 때로는 항로를 바꾼다. 대규모 모델 훈련의 실전 기록을 공개한 것 자체가 학술적 기여다. 보통 논문은 최종 결과만 보여주지만, BloombergGPT는 53일간의 시행착오를 투명하게 공개하여, 비슷한 규모의 훈련을 시도하는 다른 팀들에게 실질적인 참고 자료를 제공했다.

숫자가 말하는 것 -- 금융 벤치마크의 풍경

벤치마크 결과가 BloombergGPT의 가설을 검증한다. 논문은 세 가지 층위에서 평가를 설계했다: 공개 금융 벤치마크(5개 외부 과제), Bloomberg 내부 벤치마크(12개 실전 과제), 범용 NLP 벤치마크(4개 스위트). 이 삼중 평가 구조 자체가 이전 도메인 특화 모델 연구보다 포괄적이다.

5개 외부 금융 과제에서 BloombergGPT는 같은 크기의 범용 모델(GPT-NeoX 20B, OPT-66B)뿐 아니라, 3.5배 큰 BLOOM-176B까지 일관되게 능가했다.

과제	유형	BloombergGPT (50.6B)	GPT-NeoX (20B)	OPT-66B	BLOOM-176B
FPB	감성 분류	0.511	0.381	0.386	0.367
FiQA SA	감성 분석	0.751	0.632	0.714	0.553
Headlines	뉴스 분류	0.822	0.744	0.720	0.665
NER	개체명 인식	0.608	0.491	0.523	0.401
ConvFinQA	금융 QA	0.433	0.348	0.311	0.252

FPB(Financial PhraseBank) 감성 분류에서 BloombergGPT는 0.511로, 2위 OPT-66B의 0.386을 32% 넘어선다. 앞서 언급한 "감성이 뒤집히는" 금융 텍스트를 정확히 분류하려면, 금융 맥락에서의 감성이 일상 감성과 다르다는 것을 모델이 체화해야 한다. 363B 토큰의 금융 데이터가 이 체화를 가능하게 했다.

ConvFinQA -- 대화형 금융 질의응답 -- 에서는 격차가 더 극적이다. 0.433 대 0.348(GPT-NeoX), 0.311(OPT-66B), 0.252(BLOOM-176B). BLOOM-176B가 0.252에 불과하다는 점이 특히 인상적이다. 3.5배 큰 모델이 금융 QA에서는 절반도 안 되는 성능을 보인 것이다. 이 과제는 금융 보고서의 표를 읽고, 다단계 수치 추론("전년 대비 매출 성장률을 계산하고, 그 추세가 지속된다면 3년 후 예상 매출은?")을 수행해야 한다. 금융 맥락에서의 수치 추론이 요구되는 과제에서, 모델의 크기보다 훈련 데이터의 도메인 적합성이 결정적이었다.

Bloomberg 내부 벤치마크에서는 결과가 더 극적이었다. 10가지 감성 분석 과제 중 10개에서 1위, 4가지 개체명 인식 과제 전부에서 1위. 내부 감성 분석에는 에퀴티 뉴스, FX 뉴스, 신용, 소셜 미디어 등 Bloomberg의 실제 비즈니스 과제가 포함되어 있었다. 이 과제들은 공개 벤치마크보다 Bloomberg의 실제 사용 시나리오를 더 정확히 반영한다. 학술 벤치마크와 실전 과제 양쪽에서 모두 우위를 보인 것이 BloombergGPT의 설득력을 높인다.

NER(개체명 인식) 과제도 주목할 만하다. 금융 텍스트에서 기업명, 인물, 기관을 정확히 식별하는 것은 뉴스 분석과 정보 추출의 기초다. "Apple"이 과일인지 기업인지, "Goldman"이 사람 이름인지 Goldman Sachs인지를 문맥에서 판단해야 한다. BloombergGPT는 NER에서 0.608로, 2위 OPT-66B의 0.523을 16% 넘어섰다.

특히 Heldout 손실 분석이 흥미롭다. 논문은 FinPile에서 시간적으로 미래인 데이터를 사용하여 bits per byte(BPB)를 측정했다. BloombergGPT가 FinPile의 모든 카테고리에서 일관되게 최저 BPB를 달성했는데, Filings(공시 문서) 카테고리의 격차가 가장 컸다. PDF 기반 공시 문서는 다른 모델의 훈련 데이터에 거의 포함되지 않기 때문이다. 남들이 읽지 않은 문서를 읽은 모델이 남들이 못 푸는 문제를 풀었다. 범용 데이터에서의 BPB도 경쟁적이었다 -- 혼합 훈련이 범용 텍스트 이해력을 저하시키지 않았음을 의미한다.

동시에, 범용 NLP 벤치마크(BIG-bench Hard, MMLU, TriviaQA, BoolQ 등)에서도 BloombergGPT는 동일 규모 모델들과 동등하거나 우수한 성능을 보였다. BIG-bench Hard에서 4개 비교 모델 중 승률 1위 또는 2위를 기록했고, 176B BLOOM보다 더 자주 승리했다 -- 3.5배 작은 모델이 더 큰 모델을 범용 과제에서도 이긴 것이다. MMLU나 TriviaQA 같은 지식 평가에서는 GPT-NeoX와 동등했고, 독해(BoolQ, RACE)에서도 경쟁적이었다.

유일하게 BLOOM-176B가 우세한 영역은 일부 언어 과제(WiC, WSC 등)였는데, 이는 3.5배의 파라미터 차이를 고려하면 놀라운 일이 아니다. 오히려 50.6B 모델이 176B 모델과 대부분의 범용 과제에서 대등하게 경쟁한다는 사실 자체가 혼합 훈련의 효과를 입증한다.

이 결과가 시사하는 바는 명확하다. 혼합 훈련에서 금융 데이터 51%를 투입해도, 범용 능력이 희생되지 않았다. 오히려 금융 텍스트에 포함된 논리적 추론, 수치 분석, 사실 관계 판단이 범용 능력에도 긍정적 전이(positive transfer)를 일으켰을 가능성이 있다. 금융 보고서를 읽으며 익힌 수치 추론 능력이 일반 산술 과제에도 도움이 되고, 뉴스 분류를 하며 익힌 텍스트 이해력이 범용 독해에도 기여한다.

도메인 데이터가 범용 능력의 적이 아니라 보완재가 될 수 있다는 것 -- 이것이 논문의 핵심 주장이며, 이후 도메인 특화 모델 연구의 근거가 된 통찰이다.

이 발견은 도메인 특화 모델 연구 전체에 영향을 미쳤다. 이후의 도메인 특화 모델들 -- 의학, 법률, 과학 -- 이 대부분 혼합 훈련 전략을 채택한 것은 BloombergGPT의 이 결과에 힘입은 바가 크다.

금고의 그림자 -- BloombergGPT의 한계

BloombergGPT는 강력한 결과를 냈지만, 그 강력함의 원천이 곧 한계이기도 하다. 금고에 금을 쌓아두면 도둑은 못 들어오지만, 다른 사람도 들어올 수 없다.

첫째, 재현 불가능성이다. FinPile은 Bloomberg의 독점 데이터로 구성되어 있어 공개되지 않았다. 모델 가중치도 비공개다. 논문은 아키텍처, 훈련 하이퍼파라미터, 평가 방법론을 상세히 기술하여 최대한의 투명성을 제공하려 했지만, 학술 연구의 핵심 원칙인 재현성이 원천적으로 차단되어 있다. 다른 연구팀이 이 결과를 검증하거나 개선하려면, 비슷한 규모의 금융 데이터를 독자적으로 확보해야 한다. 현실적으로 Bloomberg급 데이터를 가진 조직은 세계에 몇 되지 않는다. 이 비대칭이 학술적으로는 약점이지만, Bloomberg의 비즈니스 관점에서는 경쟁 우위의 핵심이다.

둘째, 비용이다. 512개 A100 GPU에서 53일. 1.3M GPU 시간. 2023년 기준 A100 클라우드 가격으로 환산하면 수백만 달러에 달하는 비용이다. 이것은 대부분의 기업과 연구 기관이 감당하기 어려운 규모다. 도메인 특화 모델이 범용 모델을 이기려면, 매 도메인마다 이 비용을 지불해야 하는가? 이 질문이 다음 글에서 다룰 FinGPT의 출발점이 된다.

셋째, 인스트럭션 튜닝의 부재다. BloombergGPT는 사전 훈련만 수행했다. RLHF나 인스트럭션 파인튜닝은 미래 연구로 남겼다. 이는 모델이 지시를 따르는 능력, 대화하는 능력에서 한계를 갖는다는 뜻이다. 벤치마크에서 높은 점수를 받는 것과, 실제로 금융 애널리스트가 "이 기업의 최근 실적을 요약해줘"라고 물었을 때 유용한 답을 내는 것은 다른 문제다. 2023년 당시에는 충분했을 수 있지만, ChatGPT 이후의 세계에서 이 부재는 실용적 격차로 이어진다.

넷째, 시간적 지식의 미활용이다. FinPile에는 2007년부터 2022년까지의 시간 정보가 포함되어 있지만, 논문은 이 시간 정보를 모델 훈련에 명시적으로 활용하지 않았다. 금융 데이터에서 시간은 본질적 차원이다 -- 2008년의 "bank failure"와 2022년의 "bank failure"는 전혀 다른 맥락을 갖는다. 금리 환경, 규제 체계, 시장 심리가 모두 다르다. 시간 정보를 모델에 인코딩하면 과거 사건의 맥락적 이해가 가능해질 것이다.

다섯째, 할루시네이션에 대한 체계적 분석이 없다. 금융은 사실 정확성이 특히 중요한 도메인이다. "이 기업의 2022년 매출이 X억 달러였다"는 문장에서 숫자 하나가 틀리면 투자 판단이 바뀐다. 논문은 금융 과제의 정확도를 측정했지만, 모델이 생성하는 텍스트의 사실 정확성 -- 특히 수치와 날짜 -- 에 대한 별도의 분석은 수행하지 않았다. 이 시리즈의 앞선 글에서 ReAct가 외부 검색으로 환각을 0%로 줄인 것을 보았다. BloombergGPT에는 그런 그라운딩 메커니즘이 없다. 금융 도메인에서의 환각은 단순한 불편함이 아니라 규제적, 법적 위험으로 이어질 수 있다.

2026년의 시선

BloombergGPT가 발표된 지 3년이 지났다. 3년은 LLM 세계에서 한 세대에 해당한다. GPT-3.5에서 GPT-4로, 그리고 o1과 o3로. 오픈소스에서는 Llama에서 Llama 3로, Mistral에서 Mixtral로. 모델의 규모와 능력이 근본적으로 달라진 시간이다.

실현된 것: 도메인 특화 모델의 가치가 반복적으로 입증되었다. 의학의 Med-Gemini, 법률의 Harvey, 코드의 Codestral -- 범용 모델이 아무리 커져도, 특정 도메인의 전문 데이터로 훈련된 모델이 해당 영역에서 우위를 보이는 패턴은 계속 반복되고 있다. BloombergGPT가 던진 "독점 데이터가 경쟁 우위"라는 통찰은 업계의 상식이 되었다. 실제로 JP Morgan, Morgan Stanley 등 주요 금융 기관들이 자체 LLM 역량을 구축하거나, 범용 모델을 자사 데이터로 특화하는 전략을 채택했다.

확장된 것: 도메인 특화의 방법론이 달라졌다. BloombergGPT는 처음부터 사전 훈련(pre-training)하는 접근을 택했다. 708B 토큰을 처음부터 학습시키는, 비용과 데이터 모두에서 높은 장벽을 가진 방법이었다. 그러나 2024년 이후, LoRA나 QLoRA 같은 파라미터 효율적 파인튜닝(PEFT) 기법이 보편화되면서, 범용 모델 위에 도메인 지식을 얹는 방식이 주류가 되었다. Llama나 Mistral 같은 강력한 오픈소스 기반 모델이 등장하면서, "처음부터 만들 것인가, 기존 위에 쌓을 것인가"의 답이 후자로 기울고 있다.

다음 글에서 다룰 FinGPT가 정확히 이 접근이다. 사전 훈련의 비용과 데이터 장벽을 파인튜닝으로 우회하는 전략. BloombergGPT의 708B 토큰 사전 훈련 vs FinGPT의 경량 파인튜닝 -- 이 대비가 도메인 특화 모델의 두 갈래 길을 보여준다. RAG(Retrieval-Augmented Generation)의 부상도 이 풍경을 바꿨다. 모델 자체에 지식을 넣는 대신, 검색으로 실시간 지식을 주입하는 방식이 비용 대비 효과적인 대안으로 자리잡았다. BloombergGPT가 363B 토큰을 모델에 내재화한 것과 달리, RAG는 필요할 때 필요한 문서를 꺼내 쓴다. 금융처럼 정보가 빠르게 업데이트되는 도메인에서는 RAG의 이점이 특히 크다.

여전히 열린 것: 범용 모델의 금융 능력이 빠르게 향상되면서, 도메인 특화 모델의 필요성 자체에 대한 논쟁이 계속되고 있다. GPT-4나 Claude 같은 모델이 별도의 금융 훈련 없이도 상당한 수준의 금융 과제를 수행한다. 그러나 규제가 엄격한 금융 도메인에서는 세 가지 이유로 자체 모델이 필요하다는 주장이 여전히 강하다. 첫째, 데이터 통제 -- 고객의 금융 데이터가 외부 API로 나가는 것을 허용하지 않는 기관이 많다. 둘째, 추론 비용 -- 범용 모델의 API 호출 비용은 대량 처리 시 자체 모델보다 비싸다. 셋째, 감사 가능성 -- 금융 규제는 모델의 판단 근거를 설명할 수 있어야 한다고 요구하는데, 블랙박스 API로는 이 요구를 충족하기 어렵다.

또한, BloombergGPT가 보여준 "혼합 훈련" 접근법의 최적 비율도 열린 문제다. 금융 51% + 범용 49%라는 비율이 정말 최적이었는지, 금융 70% + 범용 30%이었다면 금융 성능이 더 올라가되 범용 성능이 어디까지 떨어졌을지 -- 논문은 이 ablation study를 수행하지 않았다. 데이터 비율과 성능의 관계를 체계적으로 탐구하는 것은 후속 연구의 몫으로 남아 있다.

Bloomberg 자신이 2026년 현재 BloombergGPT의 후속 모델을 발표했는지 여부도 명확하지 않다. 그러나 Bloomberg Terminal에 AI 기능이 꾸준히 추가되고 있는 것을 보면, 내부적으로는 모델이 계속 진화하고 있을 가능성이 높다. 열린 질문은 이것이다 -- 범용 모델의 천장이 올라갈수록, 도메인 특화 모델의 바닥도 함께 올라가야 하는가? 아니면 어느 시점에서 범용 모델이 도메인 특화 모델을 추월하여, 별도의 도메인 훈련이 불필요해지는 순간이 오는가?

마무리

이 글에서 다룬 내용을 한 문장으로 줄이면 이렇다: "남들이 읽지 못한 문서를 읽은 모델이, 남들이 풀지 못한 문제를 풀었다."

40년치 독점 데이터라는 해자(moat), 혼합 훈련이라는 전략, 그리고 도메인과 범용의 균형이라는 설계 철학. 이 세 요소가 결합하여, 50.6B 파라미터 모델이 176B 모델을 금융에서 압도하면서도 범용 능력을 유지하는 결과를 만들어냈다. 시리즈의 맥락에서 보면, 지금까지 읽은 ReAct, Reflexion, Voyager 같은 논문들이 에이전트의 행동 방식을 설계한 것이라면, BloombergGPT는 에이전트의 두뇌 자체를 특정 도메인에 맞게 재구성한 시도다. 행동 패턴이 아니라 지식의 밀도에 투자한 것이다.

다음 글에서는 BloombergGPT의 정반대 접근을 읽는다. FinGPT -- 독점 데이터와 막대한 훈련 비용 대신, 오픈소스와 경량 파인튜닝으로 금융 LLM을 민주화하려는 시도다. Bloomberg가 40년의 데이터와 수백만 달러의 계산 비용으로 쌓은 성벽을, FinGPT는 오픈소스 기반 모델과 공개 데이터, 그리고 PEFT로 우회한다.

금고를 가진 자의 전략과 금고 없는 자의 전략. 그 대비에서 도메인 특화 모델의 미래가 보인다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열다섯 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Tool Use Evolution — 단일 도구에서 다중 오케스트레이션까지

Sun, 05 Apr 2026 13:00:00 GMT

논문 정보

제목: The Evolution of Tool Use in LLM Agents: From Single-Tool Call to Multi-Tool Orchestration

저자: Haoyuan Xu, Chang Li, Xinyan Ma, Xianhao Ou 외 (Harbin Institute of Technology, Harvard University, Huawei Technologies)

출판: arXiv 2603.22862 (2026.03)

지난 글에서 Halo는 에이전트 워크플로우를 DAG로 표현하고, GPU-CPU 이종 파이프라인을 공동 스케줄링하는 시스템 최적화를 다뤘다. 에이전트의 마음이 아니라 몸을 최적화하는 논문이었다. 그 DAG의 노드 하나하나에는 도구 호출이 들어 있었다. 검색 API를 부르고, SQL을 실행하고, 코드 인터프리터를 돌리는 것. Halo는 그 노드들의 실행 순서와 자원 배분을 최적화했지만, 노드 안에서 무슨 일이 일어나는지 -- 어떤 도구를 왜 선택하고, 어떻게 조합하고, 실패하면 어떻게 복구하는지 -- 는 다루지 않았다.

이번 서베이는 바로 그 안을 들여다본다. 시리즈의 네 번째 글에서 읽었던 Toolformer는 언어 모델이 스스로 도구를 집어드는 순간을 포착한 논문이었다. 하지만 그것은 2023년 초의 일이다. 그때는 단일 도구를 한 번 호출하는 것만으로도 혁신이었다. 3년이 지난 지금, 도구 사용은 계산기 하나를 쥐는 수준에서 오케스트라를 지휘하는 수준으로 진화했다. 이 서베이는 그 진화의 전체 지형을 6가지 차원으로 조망하는 지도다.

2026년 3월, Harbin Institute of Technology와 Harvard University, Huawei Technologies의 공동 연구팀이 이 포괄적 답변을 발표했다. 50편 이상의 벤치마크와 수백 편의 논문을 분류하면서, 도구 사용이 단일 호출의 정확성에서 다중 도구 오케스트레이션의 견고성으로 진화하는 과정을 추적한다. 이 시리즈에서 이미 읽었던 Toolformer, ReAct, Reflexion, LATS, Halo가 모두 이 서베이의 지도 위에 자리를 잡고 있다.

기존 서베이들이 놓치고 있던 두 가지 격차를 이 논문이 지적한다. 첫째, 개념적 격차다. "도구 사용", "도구 호출", "워크플로우 실행"이라는 용어가 혼용되면서, 단일 호출과 장기 오케스트레이션의 본질적 차이가 흐려졌다. 둘째, 구조적 격차다. 계획, 학습, 안전, 효율, 벤치마킹이 별개 영역으로 연구되지만, 실제 시스템에서는 이 차원들이 상호 의존한다. 이 서베이는 두 격차를 모두 메우려는 시도다.

6가지 차원 -- 도구 사용의 해부학

서베이는 문헌을 6가지 차원으로 조직한다. 각 차원은 독립된 연구 영역이면서, 실제 시스템에서는 상호 의존한다.

추론 시 패러다임: 에이전트가 도구를 선택하고 호출하는 방식이다. Toolformer의 in-generation 트리거에서, ReAct의 reasoning-acting 전략으로, 그리고 다중 도구를 병렬/순차적으로 오케스트레이션하는 방식으로 진화했다.

서베이가 특히 주목하는 것은 토폴로지 계획(topological planning)의 등장이다. 전통적 ReAct는 과제를 선형으로 분해한다. 하지만 ToolNet과 StructuredAgent 같은 최신 연구는 도구 의존성을 방향 그래프로 인코딩하여, 병렬 I/O와 중첩 호출을 자연스럽게 처리한다. Halo가 시스템 수준에서 DAG를 활용했다면, 여기서는 에이전트의 추론 수준에서 그래프 구조가 등장한 것이다. 계층적 위임도 주요 흐름이다. HIPLAN은 상위 수준 마일스톤과 하위 수준 실행기를 분리하고, ADaPT는 실패할 때만 재귀적으로 분해하는 적응적 접근을 취한다.

튜닝/학습: 도구 사용 능력을 모델에 내재화하는 방법이다. Toolformer가 자기지도학습으로 도구 사용 패턴을 가중치에 새겨 넣었다면, 이후에는 더 정교한 방법들이 등장했다.

Gorilla가 대규모 API 호출 데이터로 파인튜닝하여 문법 정렬을 달성하고, ToolLLM이 DFS 결정 궤적 학습을 도입하고, Hammer가 Function Masking으로 비관련 도구의 환각을 억제했다. 최근에는 ToRL이나 Agent-R1처럼 SFT 없이 강화학습만으로 도구 사용 능력을 확보하는 엔드투엔드 접근이 부상하고 있다. 궤적 데이터 합성에서 "합성-검증-확장" 프레임워크가 지배적 패러다임이 되었다는 점도 주목할 만하다. 합성 데이터의 핵심은 양이 아니라, 롱테일 도구 조합과 다단계 오류 패턴의 체계적 커버리지다.

안전성: 도구 호출의 부작용을 관리하는 문제다. 외부 API를 호출할 때 비가역적 행동(이메일 발송, 결제 등)의 위험을 어떻게 통제하는가.

서베이는 병렬 실행의 경쟁 조건(race conditions)과 장기 도구 체인에서의 에이전트 드리프트(agent drift)를 핵심 위협으로 식별한다. 방어의 진화는 3단계로 요약된다. 사전 실행 정적 제약(AARM, AgentSpec), 실행 중 트랜잭션 관리(SagaLLM이 분산 시스템의 Saga 패턴을 차용하여 롤백 로직을 도입), 실행 후 동적 검증(CRITIC, VerifiAgent). 장기 궤적에서는 MINJA 스타일의 메모리 중독 공격이나 계획 주입 공격 같은 새로운 공격 벡터도 등장하고 있다.

효율성: 도구 호출의 비용과 지연을 최소화하는 전략이다. Halo에서 읽었던 배치 최적화가 이 차원에 해당한다.

서베이는 효율성을 지연 시간 최적화와 비용 최적화로 나눈다. 지연 시간 측면에서는 병렬 실행(LLMCompiler가 도구 의존성 분석으로 독립 호출을 동시 실행), 비동기 분리(계획과 실행의 분리), 투기적 추론(ReWoo가 기대 도구 출력을 포함한 실행 그래프를 사전 생성)이 핵심이다. 비용 측면에서는 적응적 모델 라우팅(FrugalGPT -- 저비용 모델을 우선 시도하고 신뢰도가 낮을 때만 대형 모델로 에스컬레이션), 동적 도구 검색(AnyTool의 계층적 디렉토리 트리), 의미적 캐싱(GPTCache가 의미적으로 유사한 쿼리를 감지하여 캐시에서 반환)이 발전하고 있다. SwiftSage는 인간의 이중 프로세스 이론을 차용하여, 경량 모듈이 루틴 도구 호출을 처리하고 대형 모델은 복잡한 추론에만 개입하는 구조를 제안했다.

완전성: 오픈 환경에서 필요한 도구가 존재하지 않을 때 어떻게 하는가. 서베이는 이 문제를 세 수준으로 나눈다.

첫째, 능력 경계 인식이다. 모델이 자신의 도구킷으로 해결할 수 없는 과제를 인식하는 것. FAIL-TALMS가 이 인식 부족을 정량화했고, AskToAct는 결측 파라미터를 감지하면 사용자에게 명확화 질문을 던진다. 둘째, 자율적 도구 확장이다. LATM은 에이전트를 도구 창조자와 도구 사용자로 분리하고, CREATOR는 추상 문제를 Python 스크립트로 변환한다. 셋째, 오픈 환경 적응이다. Voyager는 성공적으로 실행된 코드를 기술 라이브러리로 축적하고, ExpeL은 성공/실패 트레이스에서 교차 과제 통찰을 추출한다.

Toolformer가 기존 도구를 "언제 쓸지" 학습했다면, 이 연구들은 "필요한 도구가 없으면 만들어라"로 나아간 것이다.

벤치마크/평가: 도구 사용 능력을 어떻게 측정하는가. 서베이는 50개 이상의 벤치마크를 토폴로지 복잡도, 시간 규모, 동적 환경, 상태 지속성이라는 4가지 차원으로 분류한다.

초기의 API-Bank은 단일 호출 정확성을 측정했지만, 최근의 UltraHorizon은 400회 이상의 도구 호출과 200K 토큰 이상의 궤적에서 장기 오케스트레이션 능력을 평가한다. AppWorld는 9개의 상호 연결된 앱에서 지속적 DB 상태 변경을 추적하고, OSWorld는 실세계 컴퓨터 환경에서 수백 개의 오픈 도메인 과제를 테스트한다. 이 서베이에서 가장 체계적인 부분 중 하나가 바로 이 벤치마크 분류표다.

진화의 세 단계 -- 계산기에서 오케스트라까지

Toolformer가 보여준 것은 첫 번째 단계였다. 이후의 진화를 세 단계로 정리할 수 있다.

단계	대표 시스템	도구 수	호출 패턴	핵심 도전
단일 도구, 단일 호출	Toolformer, Gorilla	1개	생성 중 1회 삽입	정확한 API 선택과 파라미터 생성
다중 도구, 순차 호출	ReAct, TaskWeaver	여러 개	이전 출력이 다음 입력	도구 체이닝, 중간 상태 관리
다중 도구, 오케스트레이션	HuggingGPT, Chameleon	수십~수백 개	병렬+순차, DAG 구조	토폴로지 계획, 실패 복구, 비용 최적화

첫 번째 단계에서 Toolformer는 단일 도구를 한 번 호출한다. 계산기를 쓰거나, 검색을 하거나, 번역을 하는 수준이다. 시리즈의 네 번째 글에서 읽었던 것처럼, 6.7B 모델이 175B GPT-3를 넘어선 것은 이 단계의 성과였다. 하지만 한계도 명확했다 -- 도구 체이닝이 불가능하고, 결과를 보고 전략을 수정하는 루프가 없었다.

두 번째 단계에서 ReAct와 TaskWeaver는 여러 도구를 순서대로 호출한다. 검색 결과를 요약하고, 요약을 번역하는 파이프라인이다. ReAct의 사고-행동-관찰 루프가 이 패턴의 원형이다. 이전 도구의 출력이 다음 도구의 입력이 되므로, 중간 상태를 올바르게 전달하는 것이 핵심 도전이 된다.

세 번째 단계에서 HuggingGPT와 Chameleon은 과제를 분석하여 필요한 도구들의 실행 계획을 세우고, 병렬 실행이 가능한 것은 동시에, 의존성이 있는 것은 순서대로 실행한다. HuggingGPT는 중앙 계획자가 이종 전문가를 라우팅하는 구조를 취하고, Chameleon은 사용 가능한 모듈들의 조합을 프로그래밍 방식으로 합성한다. 소프트웨어 엔지니어링(SWE-Agent), GUI 자동화(AppAgent), 엔터프라이즈 워크플로우 같은 복잡한 과제에서 이 수준이 필요하다. Halo가 최적화한 것도 바로 이 세 번째 단계의 실행 효율이었다.

이 세 단계의 경계는 점점 흐려지고 있다. LATS에서 읽었던 탐색 기반 접근은 두 번째와 세 번째 단계 사이에 놓인다. 트리 탐색으로 다중 도구 경로를 평가하되, 완전한 사전 계획 없이 탐색과 실행을 병행한다. 서베이가 제시하는 비용 인식 목적 함수 -- 과제 보상에서 비용을 감산하는 형태 -- 는 이 세 단계를 관통하는 통일된 프레임워크를 제공하려는 시도다.

서베이가 드러내는 핵심 발견

서베이가 수백 편의 논문에서 추출한 발견들 중 주목할 만한 것들이 있다.

첫째, 도구 사용 학습의 패러다임이 SFT에서 RL로 빠르게 이동하고 있다. 초기의 Gorilla와 ToolLLM이 지도 파인튜닝으로 도구 호출 패턴을 가르쳤다면, ToRL과 Agent-R1은 기본 모델에서 SFT 단계 없이 강화학습만으로 도구 사용 능력을 직접 유도한다. 이 전환은 도구 사용이 패턴 모방을 넘어 의사결정 최적화의 문제라는 인식을 반영한다.

둘째, 벤치마크 설계가 고립된 API 호출 정확성에서 시스템 수준 평가로 결정적 전환을 겪고 있다. NESTFUL은 900개 이상의 도구와 1,800개 이상의 인스턴스로 비선형 도구 의존성을 테스트하고, UltraHorizon은 200K 토큰 이상의 장기 궤적에서 메모리 쇠퇴와 컨텍스트 포화를 측정한다. "이 도구를 올바르게 호출할 수 있는가"에서 "수십 개의 도구를 조율하면서 목표를 달성할 수 있는가"로 평가의 초점이 이동한 것이다.

셋째, 에이전트 자기 개선이 추론에서 도구 생태계 전체로 확장되고 있다. Reflexion이 언어화된 교훈을 에피소드 메모리에 저장하는 수준이었다면, MetaAgent는 경험을 재사용 가능한 도구와 내부 지식으로 증류하고, Test-Time Tool Evolution은 추론 시점에 새로운 실행 가능 도구를 합성하고 검증한다. 추론이 적응적 루프가 되어 도구 생태계를 사용할 뿐 아니라 재조직하고 개선하는 방향이다.

넷째, 응용 영역별로 도구 사용의 핵심 도전이 다르다. 서베이가 정리한 4개 응용 영역의 대비가 이를 잘 보여준다.

응용 영역	핵심 도전	대표 시스템	지배적 차원
소프트웨어 엔지니어링	도구 의존성 그래프의 복잡성	SWE-Agent, OpenHands	추론 시 패러다임
엔터프라이즈 워크플로우	규정 준수, 감사 가능성	TaskWeaver	안전성
GUI 에이전트	동적 UI 환경 적응	CogAgent, AppAgent	완전성
모바일 시스템	자원 제약, 실시간성	AutoDroid, DroidAgent	효율성

범용적 도구 사용 프레임워크와 도메인 특화 요구 사이의 간극은 아직 좁혀지지 않았다.

서베이의 한계

이 서베이가 포괄적임에도 불구하고, 몇 가지 한계를 지적할 수 있다.

첫째, 6가지 차원 간의 상호작용을 깊이 다루지 못한다. 예를 들어 안전성과 효율성은 종종 상충한다 -- 트랜잭션 롤백과 검증은 안전성을 높이지만 지연 시간을 늘린다. 서베이는 각 차원을 독립적으로 정리하면서 이러한 트레이드오프를 체계적으로 분석하지 않는다.

둘째, 산업계의 실제 배포 경험이 거의 반영되지 않았다. 학술 벤치마크에서의 성능과 프로덕션 환경에서의 신뢰성 사이에는 상당한 격차가 존재한다. 에이전트가 수천 명의 사용자에게 서비스될 때 발생하는 문제 -- 도구 API의 장애, 속도 제한, 버전 불일치 -- 에 대한 논의가 부족하다.

셋째, 멀티모달 도구 사용에 대한 분석이 얇다. GUI 에이전트 섹션에서 시각적 그라운딩을 언급하지만, 이미지 생성, 비디오 분석, 음성 처리 등 비텍스트 도구와의 오케스트레이션은 충분히 다루지 않는다.

넷째, 도구 사용의 실패 모드에 대한 체계적 분류가 부족하다. 어떤 유형의 과제에서 어떤 단계의 도구 사용이 실패하는지, 실패의 근본 원인이 추론 오류인지 도구 선택 오류인지 파라미터 생성 오류인지를 구분하는 분석이 있었다면 실무적 가치가 더 컸을 것이다.

2026년의 시선

이 서베이는 2026년 3월에 발표되어, 가장 최신의 지형을 반영한다. 서베이가 발표된 이후에도 도구 사용의 지형은 빠르게 변하고 있다.

가장 눈에 띄는 변화는 MCP(Model Context Protocol)의 부상이다. Anthropic이 2024년 말에 공개한 이 프로토콜은 도구 연결의 표준화를 시도한다. 서베이가 정리한 "완전성" 차원의 문제 -- 도구 발견, 도구 확장, 오픈 환경 적응 -- 를 프로토콜 수준에서 해결하려는 접근이다. 도구마다 고유한 API 스키마를 학습해야 했던 시대에서, 표준화된 인터페이스로 도구를 플러그앤플레이하는 시대로의 전환이 진행 중이다.

네이티브 함수 호출(native function calling)도 도구 사용의 지형을 바꾸고 있다. Toolformer가 파인튜닝으로 도구 사용 패턴을 학습해야 했다면, 오늘날의 Claude, GPT-4, Gemini는 훈련 과정 자체에 도구 사용이 내장되어 있다. 서베이의 "튜닝" 차원에서 다룬 SFT와 RL 기법들이 이미 상용 모델의 기본 기능으로 흡수된 것이다. 서베이가 정리한 진화의 세 번째 단계 -- 다중 도구 오케스트레이션 -- 가 연구 주제에서 산업 표준으로 이동하는 속도가 예상보다 빠르다.

도구 사용에서 가장 활발한 연구 방향은 안전성과 완전성이다. 에이전트가 실세계에서 도구를 사용할 때, 잘못된 호출의 결과가 되돌릴 수 없을 수 있다는 점이 점점 더 중요해지고 있다. 서베이가 식별한 에이전트 드리프트, 교차 도구 상태 오염, 메모리 중독 공격 같은 위협들은 에이전트가 프로덕션에 배포될수록 현실적인 문제가 된다.

도구 생태계의 규모도 서베이가 다루던 시점과는 다른 양상을 보인다. ToolkenGPT가 도구를 특수 토큰으로 표현하여 플러그앤플레이 적응을 시도했던 것이 연구의 영역이었다면, 이제 MCP 서버가 수천 개 단위로 등록되는 현실에서 동적 도구 검색과 선택의 문제는 더 이상 학술적 관심사가 아니라 엔지니어링 과제가 되었다. 서베이의 6가지 차원 중 "완전성"이 가장 빠르게 현실과 조우하고 있는 셈이다.

마무리

한 문장으로 줄이면 이렇다: 도구 사용의 진화는 "올바른 도구를 고르는 것"에서 "올바른 순서로 안전하게 조율하는 것"으로 질적 전환을 겪고 있으며, 그 전환의 지도를 6가지 차원으로 펼친 것이 이 서베이다.

Toolformer가 도구를 잡는 법을 가르쳤고, ReAct가 도구를 쓰면서 생각하는 법을 보여줬고, Reflexion이 도구 사용의 실패에서 배우는 법을 입증했고, LATS가 도구 경로를 탐색하는 법을 제안했고, Halo가 도구 실행을 최적화하는 법을 설계했다. 이 서베이는 그 모든 조각들이 하나의 지도 위에서 어떻게 연결되는지를 보여준다.

다음 글부터는 시리즈의 방향을 금융 AI로 전환한다. BloombergGPT -- 금융 데이터에 특화된 최초의 대규모 언어 모델이 어떻게 탄생했는지 읽는다. 범용적 도구 사용 능력이 특정 도메인의 언어를 만났을 때, 어떤 가능성과 한계가 드러나는지 살펴본다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열네 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Halo — DAG로 에이전트 워크플로우를 최적화하다

Sun, 05 Apr 2026 09:00:00 GMT

논문 정보

제목: Batch Query Processing and Optimization for Agentic Workflows

저자: Junyi Shen, Noppanat Wadlom, Yao Lu (National University of Singapore)

출판: arXiv 2509.02121 (2025.09)

지난 글에서 Paradigms 서베이는 에이전트 연구를 도구 사용, 계획, 피드백 학습이라는 세 패러다임으로 분류했다. 그 세 패러다임이 교차하면서 네 가지 범용 워크플로우가 만들어진다는 것이 핵심 기여였다. 하지만 워크플로우가 아무리 정교해도, 결국 물리적 하드웨어 위에서 실행되어야 한다. GPU에서 LLM 추론이 돌아가고, CPU에서 SQL 쿼리와 API 호출이 처리된다. 설계도가 아름다운 건물도 시공이 부실하면 무너진다. 이 실행의 효율성을 누가 책임지는가?

시리즈의 지금까지 논문들은 에이전트가 무엇을 하는가를 다뤘다. 추론하고(CoT), 행동하고(ReAct), 도구를 쓰고(Toolformer), 반성하고(Reflexion), 탐색한다(LATS). 하지만 이 모든 능력은 토큰으로 환산되고, 토큰은 GPU 사이클을 소비한다. 에이전트 하나가 작동할 때는 이 비용이 감당할 만하다. 에이전트 수백 개가 동시에 작동할 때, 비용은 곱셈이 아니라 조합 폭발이 된다. 논문 한 편의 실험에서는 10개의 에이전트가 동시에 수익 감소 원인을 조사하는 분석 워크플로우를 실행했는데, 각 에이전트가 searcher, connector, analyzer, editor라는 네 가지 역할에 걸쳐 수십 번의 LLM 호출과 도구 호출을 수행했다. 이 규모에서 중복과 유휴가 지배적 비용이 된다.

2025년 9월, National University of Singapore의 연구팀이 이 질문에 답하는 시스템 논문을 발표했다. Halo는 에이전트 워크플로우를 데이터베이스 시스템의 관점에서 바라본다. 워크플로우를 DAG(Directed Acyclic Graph)로 표현하고, 여러 워크플로우 사이에서 공유할 수 있는 계산을 발견하고, GPU와 CPU 사이의 작업 스케줄링을 최적화한다. 에이전트의 지능이 아니라, 에이전트의 인프라를 다루는 논문이다.

세 겹의 비효율 -- 왜 에이전트가 느린가

Halo가 해결하려는 문제는 세 가지 비효율이다.

첫째, 구조적 중복이다. 여러 에이전트가 같은 하위 과제를 수행할 때, 같은 SQL 쿼리를 각자 실행하고, 같은 API를 각자 호출한다. 10개의 에이전트가 같은 고객 데이터를 조회하면 10번의 동일한 데이터베이스 쿼리가 실행된다. 기존 에이전트 프레임워크(LangGraph, AgentScope)는 각 세션을 독립적으로 처리하므로 이 중복을 감지하지 못한다. 기존 LLM 서빙 엔진(vLLM, SGLang)도 마찬가지다 -- 개별 요청을 격리하여 최적화하므로, 요청 사이의 논리적 중복을 볼 수 없다.

둘째, 이종 파이프라인 버블이다. 에이전트 워크플로우는 GPU에서 실행되는 LLM 추론과 CPU에서 실행되는 도구 호출이 교차한다. LLM이 "이 SQL을 실행해라"고 출력하면, GPU가 멈추고 CPU가 SQL을 실행하고, 결과가 돌아오면 GPU가 다시 LLM을 돌린다. 이 왕복 과정에서 GPU와 CPU가 번갈아 유휴 상태에 빠진다. 파이프라인 안에 거품이 끼는 것이다.

셋째, LLM 연산자의 상태 관리 문제다. 서로 다른 워크플로우가 서로 다른 모델을 요구하면 모델 전환 비용이 발생한다. 같은 프롬프트 접두사를 공유하는 요청들이 있어도, 기존 시스템은 이를 인식하지 못해 KV 캐시를 재활용하지 못한다. 따뜻한 캐시를 차가운 캐시로 되돌리는 것은, 이미 끓인 물을 버리고 다시 끓이는 것과 같다.

Halo의 아키텍처 -- Parser, Optimizer, Processor

Halo의 구조는 세 단계 파이프라인이다. 데이터베이스 시스템의 쿼리 처리 파이프라인 -- 파싱, 최적화, 실행 -- 을 에이전트 워크플로우에 적용한 것이다. 이 대응은 우연이 아니다. 에이전트 워크플로우의 구조가 데이터베이스 쿼리의 구조와 본질적으로 유사하기 때문이다. 둘 다 의존관계가 있는 연산의 그래프이고, 둘 다 공유 가능한 중간 결과를 가지며, 둘 다 이종 자원 위에서 실행된다.

Parser는 YAML로 선언된 워크플로우를 DAG 형태의 중간 표현(GraphSpec)으로 변환한다. 핵심 변환은 의존성 분리(dependency decoupling)다. LLM 프롬프트 안에 묻혀 있는 SQL 쿼리나 API 호출을 별도의 노드로 추출한다. 프롬프트 내부의 불투명한 부작용이 아니라, 스케줄링 가능한 독립 단위로 만드는 것이다. 이 단계가 없으면 이후의 모든 최적화가 불가능하다.

Optimizer는 DAG를 실행 계획으로 변환한다. 연속 시간 최적화는 다루기 어려우므로, 계획을 결정 윈도우(에포크)로 분할한다. 각 에포크에서 옵티마이저는 현재 시스템 상태 -- 완료된 노드 집합과 각 워커의 상주 모델 및 KV 캐시 상태 -- 를 참조하여 GPU 워커에 배정할 LLM 노드를 선택한다. 비용 모델은 병목 워커의 지연 시간(makespan)과 총 시스템 부하를 동시에 고려한다.

기존 옵티마이저가 고정 비용을 가정하는 것과 달리, Halo의 비용 모델은 상태 인식적이다. 현재 워커에 이미 올라와 있는 모델과 다른 모델이 필요하면 전환 비용을 반영하고, 같은 프롬프트 접두사를 가진 요청이면 프리픽스 캐싱 할인을 적용한다. MILP(Mixed Integer Linear Programming) 오라클이 1.44시간 걸리는 최적 스케줄을, Halo의 DP 솔버는 상태 공간을 위상적 프론티어로 가지치기하여 2.24초에 거의 동일한 품질로 산출한다.

Processor는 계획을 실행한다. Coordinator가 DAG 상태를 비차단 이벤트 기반으로 관리하고, GPU 실행자가 LLM 추론을, CPU 실행자가 도구 호출을 처리한다. 웨이브프론트 스타일 실행을 통해, 하나의 LLM 노드가 완료되면 느린 형제 노드를 기다리지 않고 후속 노드가 즉시 실행될 수 있다. Coordinator는 잠금 없는 이벤트 루프로 완료 이벤트를 소비하고, 새로 준비된 노드를 타입에 따라 GPU 큐 또는 CPU 큐로 승격한다.

이 세 단계 구조에서 주목할 점은 Parser의 의존성 분리가 나머지 두 단계의 전제 조건이라는 것이다. 프롬프트 안에 묻혀 있는 도구 호출을 독립 노드로 추출하지 않으면, Optimizer는 최적화할 대상을 볼 수 없고, Processor는 CPU-GPU 오버랩을 만들 수 없다. 투명성이 최적화의 필요 조건인 것이다.

핵심 최적화 기법 -- 중복 제거, 유휴 시간 활용, 캐시 재사용

Halo의 구체적 최적화 기법 세 가지가 성능 향상의 원천이다.

요청 합체(Request Coalescing): 동일한 도구 호출을 자동으로 감지하여 한 번만 실행한다. 10개의 에이전트가 같은 SQL 쿼리를 요청하면, 물리적으로 한 번 실행하고 결과를 10개 노드에 팬아웃한다. 데이터베이스의 공유 스캔(shared scan)과 같은 발상이다. 제거 실험에서 이 기법을 빼면 복잡한 워크플로우(W6)의 지연이 154% 증가했다 -- 세 가지 기법 중 가장 큰 영향이다.

기회적 실행(Opportunistic Execution): 계획된 작업이 외부 요인(느린 API 응답 등)으로 지연될 때, 데이터 의존성이 이미 충족된 다른 노드를 빈 슬롯에서 실행한다. 유휴 시간을 생산적 시간으로 바꾸는 것이다. 정적 스케줄의 한계를 동적으로 보완하는 전략으로, W6에서 이 기법을 제거하면 지연이 56% 증가했다.

KV 캐시 공유 및 프리페칭: 같은 시스템 프롬프트나 같은 컨텍스트 접두사를 공유하는 LLM 요청들의 KV 캐시를 재사용한다. 프리필 단계에서 이미 계산된 토큰을 다시 계산하지 않으므로, 추론 비용이 절감된다. 동일 워커에서 계보(lineage)를 유지하도록 배치하는 로컬리티 인식 전략이 이를 가능하게 한다. 비용 모델에서 이를 "프리픽스 캐싱 할인"이라 부르는데, 공유 접두사가 길수록 유효 프리필 토큰 수가 줄어들어 할인 폭이 커진다.

세 가지 기법은 독립적이지 않다. 요청 합체가 동일 도구 호출의 물리적 중복을 제거하고, KV 캐시 공유가 동일 프롬프트 접두사의 연산 중복을 제거하며, 기회적 실행이 두 기법이 만들어낸 빈 슬롯을 채운다. 겹겹이 쌓인 최적화가 서로를 보완하는 구조다.

실험 결과 -- 숫자가 말하는 것

6개 벤치마크에서의 결과다. 논문이 발표된 2025년 기준, NVIDIA H200 GPU 3대와 AMD EPYC CPU 환경에서 측정되었다.

비교 대상	시나리오	속도 향상	비고
vLLM	W1 배치 (N=1024)	400배 이상	71시간 to 676초
OpWise	W1 배치	2.4배	토폴로지 인식 배칭 기준선
OpWise	W6 배치	1.6배	복잡 워크플로우
LangGraph	W5 배치	3.6배	복잡 에이전트 워크플로우
OpWise	온라인 서빙	1.53-1.74배 QPS	처리량 기준
LangGraph	온라인 서빙	최대 2.58배 QPS	TPCH W5 기준

vLLM 대비 400배라는 숫자는 문맥 없이 보면 비현실적으로 보인다. 이는 vLLM이 에이전트 워크플로우를 전혀 인식하지 못하고 모든 요청을 순차적으로 처리하기 때문에 발생하는 극단적 비효율이 기준선이기 때문이다. 더 공정한 비교 대상인 OpWise(토폴로지 인식 배칭)와 LangGraph(에이전트 오케스트레이터) 대비에서도 1.6배에서 3.6배 향상을 보인다는 것이 실질적 의미가 있다.

핵심은 출력 품질 저하 없이 이 성능을 얻었다는 점이다. Halo는 에이전트의 행동 자체를 바꾸지 않는다. 같은 입력에 같은 출력을 내되, 그 과정의 물리적 실행만 최적화한다. 알고리즘의 의미론을 건드리지 않고 구현의 효율만 개선하는 것 -- 컴파일러가 프로그래머의 의도를 보존하면서 기계어를 최적화하는 것과 같은 원리다.

제거 실험(ablation study)의 결과도 각 기법의 기여를 선명하게 드러낸다.

제거 대상	W1 지연 증가	W6 지연 증가
프로파일링 스코어링 제거	+20%	+8%
CPU 부하 가이드 제거	+1%	+18%
기회적 실행 제거	+1%	+56%
요청 합체 제거	+16%	+154%
Halo (전체)	기준	기준

워크플로우가 복잡해질수록(W1에서 W6으로 갈수록) 요청 합체와 기회적 실행의 중요성이 급격히 커진다. 단순 워크플로우에서는 프로파일링이 더 큰 영향을 미치지만, 복잡한 토폴로지에서는 중복 I/O 제거가 지배적 요인이 된다.

스케일 측면에서도 배치 크기 256에서 2048까지 거의 선형적으로 확장되고, GPU 워커 수 1개에서 3개까지 준선형 탄성을 보이며, 모델 크기 0.4B에서 32B까지 일관된 효율을 유지했다. 또한 A100, H100, H200 등 서로 다른 GPU에서도 일관된 개선을 보여, 특정 하드웨어에 종속되지 않는 범용성을 입증했다.

한계와 열린 문제 -- 지도의 빈칸

논문이 스스로 인정하는 한계가 두 가지 있고, 읽으면서 발견한 한계가 하나 더 있다.

첫째, 배포 범위가 단일 머신에 한정된다. 다중 GPU는 지원하지만, 다중 노드(여러 서버) 배포에는 분산 배치, 캐시 이동, 네트워크 인식 스케줄링이 추가로 필요하다. 프로덕션 규모의 에이전트 시스템이 수십 대의 서버에 분산되는 현실을 고려하면, 이 한계는 무시하기 어렵다.

둘째, 고정 논리 플랜을 가정한다. Halo는 워크플로우의 DAG 구조가 주어진 것으로 간주하고, 실행 순서와 자원 배분만 최적화한다. 비용을 줄이기 위해 프롬프트를 수정하거나, 정확도를 약간 희생하여 더 작은 모델로 교체하는 등의 상위 수준 재작성(semantic rewriting)은 범위 밖이다. AI Agents That Matter가 제기한 비용-정확도 트레이드오프를 시스템 수준에서 자동으로 탐색하려면, Halo 위에 한 층 더 필요하다.

셋째, 의존성 분리가 YAML 선언에 의존한다. Parser가 프롬프트 안에 묻힌 도구 호출을 추출하려면, 워크플로우가 YAML로 명시적으로 선언되어 있어야 한다. 자연어 지시만으로 에이전트가 자율적으로 도구를 선택하는 시나리오 -- ReAct나 Toolformer가 다루는 바로 그 시나리오 -- 에서는 DAG 자체를 사전에 구성할 수 없다. Halo의 최적화는 워크플로우의 구조가 사전에 알려져 있을 때 가장 강력하고, 구조가 동적으로 결정될 때 적용이 어려워진다.

2026년의 시선 -- 실현된 것, 확장된 것, 열린 것

이 논문이 발표된 지 반년이 지난 2026년 4월의 시점에서, Halo가 제기한 문제의식이 어떤 궤적을 그렸는지 세 가지 축으로 돌아본다.

실현된 것. DAG 기반 워크플로우 최적화라는 아이디어는 이미 현실로 들어왔다. 주요 LLM 서빙 프레임워크들이 프리픽스 캐싱과 연속 배칭을 기본 기능으로 탑재하기 시작했고, 에이전트 오케스트레이터와 서빙 엔진의 경계가 흐려지고 있다. Halo가 지적한 "오케스트레이션과 서빙의 분리"라는 비효율을 업계가 인식하기 시작한 것이다. 클라우드 API 수준에서도 프롬프트 캐싱이 기본 기능이 되었고, 이는 Halo의 KV 캐시 공유 개념이 API 인터페이스로 노출된 사례라 할 수 있다.

확장된 것. Halo는 CPU-GPU 이종 파이프라인을 다뤘지만, 2026년의 에이전트 시스템은 더 다양한 이종성을 보인다. 로컬 모델과 클라우드 API의 혼용, 캐시 서버와 벡터 데이터베이스, 코드 실행 샌드박스까지. 이종 파이프라인 최적화의 범위가 Halo가 그린 것보다 넓어지고 있다. 특히 MCP(Model Context Protocol)와 같은 표준이 도구 호출을 규격화하면서, 도구 노드의 시그니처 정규화 -- Halo의 요청 합체가 의존하는 바로 그 메커니즘 -- 가 더 자연스럽게 가능해지는 환경이 조성되고 있다.

열린 것. 가장 근본적인 질문은 여전히 열려 있다. 에이전트 워크플로우를 고정 DAG로 표현할 수 있는가? LATS처럼 탐색 과정에서 동적으로 분기하는 워크플로우, Reflexion처럼 실패에 따라 구조 자체가 바뀌는 워크플로우는 정적 DAG로 포착되지 않는다. 동적 워크플로우의 런타임 최적화는 아직 해법을 기다리고 있다. 또한 Halo가 다중 노드 분산 환경을 지원하지 않는 한계도 프로덕션 채택의 벽으로 남아 있다. 네트워크 레이턴시와 캐시 이동까지 비용 모델에 포함시키는 것은 단일 머신 최적화와는 차원이 다른 문제다.

CoALA 좌표계 위의 Halo

Halo는 CoALA 좌표계의 바깥에 있다. 기억, 행동, 판단이라는 인지적 축이 아니라, 에이전트를 실행하는 하부 구조의 최적화다. CoALA가 에이전트의 마음을 설계한다면, Halo는 에이전트의 신체 -- 물리적 실행 환경 -- 를 최적화한다.

이 위치가 중요한 이유가 있다. 시리즈에서 다룬 대부분의 논문은 에이전트의 인지적 능력 -- 추론, 계획, 반성, 학습 -- 에 집중한다. 그 인지적 능력이 프로덕션에서 실제로 작동하려면, 시스템 수준의 효율이 뒷받침되어야 한다. 마음과 신체가 분리될 수 없듯, 알고리즘 연구와 시스템 연구도 결국 합류해야 한다. Halo는 그 합류 지점의 좌표를 보여준다.

마무리

한 문장으로 줄이면 이렇다. 에이전트의 지능을 높이는 것만으로는 충분하지 않다 -- 지능이 실행되는 인프라의 효율이 지능 자체만큼 중요하다.

Halo의 DAG 노드 안에는 도구 호출이 들어 있었다. 검색 API를 부르고, SQL을 실행하고, 코드 인터프리터를 돌리는 것. Halo는 그 노드들의 실행 순서와 자원 배분을 최적화했지만, 노드 안에서 무슨 일이 일어나는지 -- 어떤 도구를 왜 선택하고, 어떻게 조합하고, 실패하면 어떻게 복구하는지 -- 는 다루지 않았다. 다음 글에서는 바로 그 안을 들여다본다. Tool Use Evolution -- 단일 도구 호출에서 다중 도구 오케스트레이션까지, 에이전트가 도구를 다루는 방식이 어떻게 발전해왔는지 여섯 가지 차원으로 분석한다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열세 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Paradigms — 도구 사용·계획·피드백의 삼각 구도

Sat, 04 Apr 2026 17:00:00 GMT

논문 정보

제목: A Review of Prominent Paradigms for LLM-Based Agents: Tool Use (Including RAG), Planning, and Feedback Learning

저자: Xinzhe Li (Deakin University)

출판: arXiv 2406.05804 (2024.06, revised 2024.11)

시리즈에서 지금까지 읽은 논문들을 떠올려보면, 각각이 에이전트의 다른 능력을 다뤘다. CoT와 ReAct는 추론과 행동을, Toolformer는 도구 사용을, Reflexion과 LATS는 피드백과 계획을, ETO는 훈련을 통한 학습을 다뤘다. 각각의 논문 안에서는 논리가 선명했지만, 논문과 논문 사이의 관계 — 어떤 논문이 어떤 논문의 어디를 확장하고 어디를 대체하는지 — 는 독자가 스스로 정리해야 했다.

2024년 6월, Deakin University의 연구자가 이 정리를 시도했다. 에이전트 연구를 도구 사용, 계획, 피드백 학습이라는 세 패러다임으로 분류하고, 패러다임을 가로지르는 통합 프레임워크를 제안한다. Multi-Agent Survey가 다중 에이전트의 지형을 그렸다면, 이 논문은 단일 에이전트의 워크플로우 지형을 그린다.

세 가지 역할 — LLM이 맡을 수 있는 직무

논문의 핵심 기여는 LLM이 에이전트 시스템에서 맡을 수 있는 역할을 세 가지로 추상화한 것이다. 논문은 이를 LLM 프로파일 역할(LMPR)이라 부른다.

정책 모델(Policy): 무엇을 할지 결정한다. 두 가지 하위 유형이 있다. Actor는 현재 상태에서 다음 행동을 직접 생성한다 — ReAct가 대표적이다. Planner는 행동 시퀀스, 즉 계획을 한 번에 생성한다 — Plan-and-Solve가 대표적이다.

평가자(Evaluator): 행동이나 상태의 품질을 판단한다. ToT에서 각 사고 단계의 가치를 평가하는 것, Reflexion에서 자기 반성을 생성하는 것이 모두 이 역할이다.

동적 모델(Dynamic Model): 행동의 결과를 예측한다. 세계 모델이라고도 부른다. RAP에서 행동을 실제로 실행하지 않고 다음 상태를 시뮬레이션하는 것이 이 역할이다.

이 세 역할의 가치는 조합에 있다. 시리즈에서 읽어온 논문들이 세 역할의 서로 다른 조합이라는 것을 보여준다.

프레임워크	정책 모델	평가자	동적 모델
CoT	O (actor)	X	X
ReAct	O (actor)	X	X
ToT	O (planner)	O	X
Reflexion	O (actor)	O	X
LATS	O (actor)	O	O

CoT와 ReAct는 정책 모델만 사용한다. ToT와 Reflexion은 평가자를 추가한다. LATS는 세 역할을 모두 동원한다. 에이전트의 복잡성은 역할의 수가 아니라, 역할 간의 상호작용 방식에서 나온다.

네 가지 워크플로우 — 에이전트가 일하는 방식

세 역할이 조합되어 네 가지 범용 워크플로우를 만든다.

기본 워크플로우: 정책 모델만으로 환경과 상호작용한다. CoT, ReAct, Plan-and-Solve가 여기에 속한다. 가장 단순하지만, 긴 시간 범위의 과제에서는 계획이 초반에 고정되어 중간 수정이 어렵다는 한계가 있다.

도구 사용 워크플로우: 정책 모델이 외부 도구를 호출한다. 논문은 이를 네 가지 하위 유형으로 분류한다. RAG 스타일은 검색 메커니즘이 수동적으로 정보를 제공하고, 수동적 검증은 별도 도구가 출력을 검증하고, 자율적 도구 사용은 LLM이 스스로 도구 호출 시점과 종류를 결정하고, 자율적 검증은 평가자가 도구 검증 필요 여부를 판단한다.

자율적 도구 사용에서 도구를 호출하는 트리거 방식이 흥미롭다. In-Generation 트리거는 생성 중에 특수 토큰을 감지하면 일시 정지하고 도구를 호출한다 — Toolformer의 방식이다. Reasoning-Acting 전략은 추론과 행동을 교차하면서 필요할 때 도구를 호출한다 — ReAct의 방식이다. Confidence 기반은 생성된 토큰의 신뢰도가 낮으면 도구로 보완한다.

탐색 워크플로우: 여러 가능한 경로를 체계적으로 탐색한다. 순회/휴리스틱 방식은 ToT처럼 트리 구조에서 DFS/BFS로 탐색하고, 평가자가 고정된 가치 추정을 제공한다. MCTS 방식은 세 역할이 모두 협력한다 — LATS가 대표적이다. 두 방식의 핵심 차이는 탐색 알고리즘의 정교함이다. 순회/휴리스틱은 정적 가치 추정에 의존하지만, MCTS는 누적 통계로 가치를 동적으로 업데이트한다.

피드백 학습 워크플로우: 과거 시도에서 얻은 피드백으로 행동을 개선한다. 피드백 소스에 따라 세 가지로 나뉜다 — 평가자만(Self-Refine, Reflexion), 평가자 + 환경(Reflexion with environment), 인간(CRITIC with human).

교차 패러다임 비교 — 같은 개념, 다른 맥락

논문의 가장 유용한 부분은 패러다임을 가로지르는 비교다.

같은 역할이 패러다임에 따라 다르게 사용된다. 정책 모델의 Actor 역할을 예로 들면, 기본 워크플로우에서는 실행 가능한 행동을 생성하고, 탐색 워크플로우에서는 계획 알고리즘에 입력할 후보 행동을 생성하고, 도구 사용 워크플로우에서는 도구 호출 행동을 생성한다. 같은 LLM이 같은 역할을 맡지만, 출력의 성격이 완전히 다르다.

평가자의 경우는 더 극적이다. 피드백 학습에서 평가자는 전체 시도를 되돌아보며 자유 형식의 반성 텍스트를 생성한다. 탐색에서 평가자는 트리의 각 노드에 스칼라 가치를 매겨 탐색을 안내한다. 같은 "평가"라는 기능이, 한쪽에서는 에세이를 쓰고 다른 쪽에서는 점수를 매기는 것이다.

계획 생성도 패러다임에 따라 달라진다. 기본 워크플로우에서 계획은 탐욕적으로 한 번에 생성되고 이후 수정되지 않는다. 탐색 워크플로우에서 계획은 여러 후보를 탐색하며 백트래킹을 지원한다. MCTS에서는 루트 노드의 행동만 실제로 실행하고, 나머지는 시뮬레이션 후 폐기하여 지속적으로 재계획한다.

시리즈에서 읽은 논문들의 위치

이 분류 체계 위에 시리즈의 논문들을 배치하면 전체 그림이 선명해진다.

논문	워크플로우	사용 LMPR	패러다임
CoT	기본 (Actor)	정책	기본
ReAct	기본 (Actor) + 도구 사용	정책	기본 + 도구
Toolformer	도구 사용 (자율적)	정책	도구
Reflexion	피드백 학습 (평가자 + 환경)	정책 + 평가자	피드백
LATS	탐색 (MCTS)	정책 + 평가자 + 동적	계획
ETO	피드백 학습 (DPO)	정책	피드백

CoT에서 LATS로 갈수록 사용하는 역할이 늘어나고, 워크플로우가 복잡해진다. 하지만 AI Agents That Matter가 보여줬듯이, 복잡한 워크플로우가 항상 더 나은 것은 아니다. 과제의 난이도에 맞는 워크플로우를 선택하는 것이 핵심이다.

2026년의 시선 — 통합의 현재

논문이 발표된 2024년 6월로부터 약 2년이 지났다.

실현된 것: 세 패러다임의 통합이 프레임워크 수준에서 이루어졌다. LangGraph, CrewAI 같은 현대 에이전트 프레임워크는 도구 사용, 계획, 피드백 학습을 하나의 에이전트 루프 안에서 유연하게 조합할 수 있게 설계되어 있다.

확장된 것: 논문이 제안한 세 가지 LMPR이 실제로는 더 세분화되었다. 예를 들어 "오케스트레이터"나 "라우터"라는 새로운 역할이 등장하여, 여러 에이전트나 워크플로우 사이의 흐름을 조율한다.

여전히 열린 것: 범용 도구 사용 워크플로우는 아직 완전히 해결되지 않았다. 특정 과제에 맞춤화된 도구 사용과, 어떤 과제에서든 적용할 수 있는 범용 도구 사용 사이의 간극이 여전하다.

마무리 — 분류의 가치

이 논문이 제공하는 것은 새로운 에이전트 아키텍처가 아니라, 기존 아키텍처를 이해하는 렌즈다. 세 가지 역할과 네 가지 워크플로우라는 프레임워크는, 새로운 에이전트 논문을 만났을 때 "이것은 어떤 역할의 어떤 조합인가"를 즉시 파악하게 해준다.

다음 글에서는 에이전트 워크플로우의 실행 효율 문제로 넘어간다. Halo — DAG 기반 에이전트 워크플로우에서 공유 계산을 발견하고 스케줄링을 최적화하는 시스템 논문을 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열두 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: AI Agents That Matter — 벤치마크의 함정을 파헤치다

Sat, 04 Apr 2026 13:00:00 GMT

논문 정보

제목: AI Agents That Matter

저자: Sayash Kapoor, Benedikt Stroebl, Zachary S. Siegel, Nitya Nadgir, Arvind Narayanan (Princeton University)

출판: arXiv 2407.01502 (2024.07)

시리즈의 지난 세 글에서 에이전트 학습의 세 가지 축을 읽었다. Reflexion은 자연어 반성으로, LATS는 트리 탐색으로, ETO는 대조 학습으로 성능을 끌어올렸다. HumanEval에서 91%, 92.7%라는 수치가 등장했고, 각각이 이전 SOTA를 넘어섰다. 숫자는 인상적이었다.

하지만 여기서 멈추고 물어야 할 질문이 있다. 그 숫자가 진짜 의미하는 것은 무엇인가? LATS가 92.7%를 달성할 때, 얼마를 썼는가? 단순히 같은 문제를 다시 풀어보는 것과 비교하면 어떤가?

2024년 7월, Princeton University의 연구팀이 정확히 이 질문을 던졌다. 논문 제목부터 도발적이다 — "AI Agents That Matter". 중요한 AI 에이전트. 현재의 에이전트 벤치마킹이 "중요하지 않은" 에이전트를 만들고 있다는 암묵적 비판이다.

134달러짜리 88% — 숫자 뒤의 숫자

논문이 제시하는 첫 번째 실험이 가장 충격적이다. HumanEval 벤치마크에서 여러 에이전트의 정확도와 비용을 함께 측정한 것이다.

에이전트	정확도 (%)	총 비용 ($)
GPT-4 (zero-shot)	89.6	1.93
Warming (GPT-4)	93.2	2.45
Retry (GPT-4)	92.0	2.51
LDB (GPT-4)	93.3	6.36
Reflexion (GPT-4)	87.8	3.90
LATS (GPT-4)	88.0	134.50

Warming은 단순한 전략이다. 실패하면 온도를 조금 올려서 다시 시도한다. 그게 전부다. 자기 반성도 없고, 트리 탐색도 없고, 외부 메모리도 없다. 이 전략이 93.2%를 달성한다. LDB(93.3%)와 거의 같은 정확도를, 비용은 2.45달러 대 6.36달러로 절반 이하에 달성한다.

LATS는 88%에 134.50달러다. 앞선 글에서 읽었던 정교한 트리 탐색, 가치 함수, 반성 메커니즘 — 이 모든 것이 단순 재시도보다 정확도는 낮으면서 비용은 50배 이상이다. 물론 이것은 HumanEval이라는 특정 벤치마크에서의 결과이고, 더 어려운 과제에서는 이야기가 달라질 수 있다. 하지만 이 숫자가 던지는 질문은 불편하다.

네 가지 근본 문제

논문은 현재 에이전트 벤치마킹의 네 가지 구조적 문제를 식별한다.

첫째, 정확도만 추구하면 비용이 무한히 증가한다. 리더보드는 정확도만 보여준다. 연구자들은 비용에 관계없이 정확도를 1%라도 올리려 한다. 결과적으로 복잡하고 비싼 에이전트가 리더보드 상위를 차지하지만, 실세계에서 배포하기에는 비실용적이다. SWE-Agent 1회 실행에 4달러라면, 하루에 수천 건의 요청을 처리하는 서비스에서는 감당할 수 없다.

논문이 제안하는 대안은 파레토 프론티어다. 정확도와 비용을 2차원 평면에 놓고, 어떤 에이전트가 "더 적은 비용으로 같은 정확도" 또는 "같은 비용으로 더 높은 정확도"를 달성하는지 보는 것이다. 파레토 프론티어 위의 에이전트만이 "중요한" 에이전트다. 프론티어 아래에 있다면, 더 싸면서 더 정확한 대안이 존재한다는 뜻이다.

둘째, 모델 평가와 다운스트림 평가가 혼동된다. 모델 개발자가 아키텍처의 효과를 측정하려는 것과, 서비스 개발자가 어떤 모델을 채택할지 결정하려는 것은 다른 목적이다. 전자는 계산량(compute)으로 비용을 측정하고, 후자는 달러로 측정해야 한다. 이 구분이 무시되면, 벤치마크 결과가 실세계 의사결정을 잘못 안내한다.

NovelQA 사례가 이를 보여준다. 긴 컨텍스트 모델과 RAG를 비교할 때, NovelQA 벤치마크는 RAG에 불리하게 설계되어 있다. 하지만 실세계에서 RAG는 20배 이상 저렴하면서 유사한 정확도를 낸다.

셋째, 적절한 hold-out 세트가 부족하다. 에이전트 연구에서 과적합은 모델 과적합과 다른 형태로 나타난다. 특정 벤치마크의 구조를 알고 있는 연구자가, 그 구조에 맞춘 하드코딩된 전략을 에이전트에 심는다. WebArena에서 1위를 차지한 STeP 에이전트가 대표적이다. URL 구조에 의존하는 하드코딩된 정책을 사용했고, URL이 바뀌면 작동하지 않았다.

논문이 제시하는 4단계 일반성 프레임워크가 이 문제를 체계화한다. 분포 특화, 과제 특화, 도메인 일반, 완전 일반 — 각 수준에서 적절한 hold-out 세트가 달라진다. 17개 벤치마크를 분석한 결과, 대다수가 적절한 hold-out을 포함하지 않았다.

넷째, 표준화와 재현성이 부족하다. 같은 벤치마크에서 같은 에이전트를 실행해도, 평가 스크립트의 차이, 외부 환경과의 상호작용, 미묘한 버그로 인해 결과가 달라진다. HumanEval과 WebArena 모두에서 만연한 재현성 문제가 발견되었다.

단순한 기준선의 위력

논문이 테스트한 세 가지 단순 기준선이 인상적이다.

Retry: 실패하면 최대 5회까지 같은 프롬프트로 재시도한다. 온도는 0.

Warming: Retry와 같지만, 재시도할 때마다 온도를 0에서 0.5까지 점진적으로 올린다. 다양한 출력을 유도하기 위해서다.

Escalation: 가장 저렴한 모델(Llama-3 8B)부터 시작하고, 실패하면 더 비싼 모델로 올라간다.

이 중 Escalation이 특히 주목할 만하다. 85%의 정확도를 0.27달러에 달성한다. 대부분의 문제는 저렴한 모델로 풀 수 있고, 어려운 문제만 비싼 모델이 처리한다. 비용 효율성 관점에서 가장 뛰어나다.

이 결과가 시사하는 것은 "복잡한 에이전트 구조가 성능 향상에 기여한다"는 일반적 가정에 대한 의문이다. 논문의 표현을 빌리면, "System 2 접근법 — 디버깅, 반성, 계획 — 이 성능 향상에 책임이 있다는 증거가 부족하다." 적어도 HumanEval 수준의 벤치마크에서는 그렇다.

비용을 함께 최적화하면 — DSPy 실험

논문은 비판에 그치지 않고 대안을 제시한다. DSPy 프레임워크와 Optuna를 사용하여, 정확도와 비용을 동시에 최적화하는 실험을 수행했다.

HotPotQA에서 GPT-3.5를 사용할 때, 공동 최적화가 기본 DSPy 대비 비용을 53% 절감하면서 동일한 정확도를 유지했다. Llama-3-70B에서는 41% 절감. 최적화 대상은 온도, 퓨샷 예시의 수와 선택, 포맷팅 지시의 포함 여부 같은 단순한 하이퍼파라미터들이다. 복잡한 에이전트 구조가 아니라, 기본적인 설정 조정만으로도 큰 효율 개선이 가능하다는 뜻이다.

2026년의 시선 — 비판의 유효성

논문이 발표된 2024년 7월로부터 약 2년이 지났다.

실현된 것: 비용 인식 평가가 에이전트 연구의 표준으로 자리잡기 시작했다. SWE-bench Verified 같은 최신 벤치마크는 비용을 함께 보고하는 추세다. Escalation 패턴은 "라우터(router)" 방식으로 산업에서 광범위하게 채택되었다 — 간단한 쿼리는 작은 모델이, 어려운 쿼리는 큰 모델이 처리하는 구조다.

여전히 유효한 것: 리더보드 중심의 연구 문화는 여전하다. 새로운 에이전트 논문이 나올 때마다 "SWE-bench에서 X%"라는 숫자가 헤드라인을 장식하고, 비용은 작은 글씨로 묻힌다. 논문이 제기한 재현성 문제도 근본적으로 해결되지 않았다.

수정이 필요한 것: "복잡한 에이전트가 불필요하다"는 주장은 HumanEval 같은 단순 벤치마크에서는 맞지만, SWE-bench나 실세계 소프트웨어 엔지니어링 과제에서는 다르다. 복잡한 추론, 계획, 도구 사용이 실질적 차이를 만드는 영역이 존재한다. 논문도 이 점을 인정하며 "더 어려운 과제에서는 System 2 접근이 유용할 가능성"을 언급한다.

CoALA 좌표계 위의 이 논문

이 논문은 에이전트를 만드는 논문이 아니라, 에이전트를 평가하는 논문이다. CoALA 좌표계 위에 놓기보다는, 좌표계 자체를 점검하는 메타 연구에 해당한다.

시리즈에서 읽어온 모든 논문 — CoT, ReAct, Reflexion, LATS, ETO — 의 성과가 실제로 무엇을 의미하는지 재검토하게 만든다. 벤치마크 숫자 뒤에 비용이 있고, 비용 뒤에 실용성이 있고, 실용성 뒤에 "이 에이전트가 실세계에서 정말 유용한가"라는 궁극적 질문이 있다.

마무리 — 숫자를 읽는 법

이 논문이 바꾸는 것은 에이전트 연구를 읽는 방식이다. 정확도가 몇 퍼센트인지 묻기 전에, 비용이 얼마인지 묻는다. SOTA라는 라벨을 보기 전에, 단순 기준선과 비교했는지 확인한다. 복잡한 구조가 진짜로 기여하는 부분인지, 아니면 같은 효과를 더 싸게 얻을 수 있는지 따진다.

다음 글에서는 다시 에이전트 아키텍처로 돌아온다. Paradigms — 도구 사용, 계획, 피드백 학습이라는 세 가지 패러다임으로 에이전트 전체를 정리하는 리뷰 논문을 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열한 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: ETO — 실패 궤적으로 에이전트를 훈련하다

Sat, 04 Apr 2026 09:00:00 GMT

논문 정보

제목: Trial and Error: Exploration-Based Trajectory Optimization for LLM Agents

저자: Yifan Song, Da Yin, Xiang Yue, Jie Huang, Sujian Li, Bill Yuchen Lin (Allen Institute for AI, Peking University, UCLA, Ohio State University, UIUC)

출판: ACL 2024 Main Conference

arXiv: 2403.02502

앞선 두 글에서 에이전트가 실패에서 학습하는 두 가지 방식을 읽었다. Reflexion은 실패를 자연어로 반성하여 다음 시도의 컨텍스트에 추가했다. LATS는 실패 지점에서 트리를 분기하여 다른 경로를 탐색했다. 둘 다 가중치를 건드리지 않는다. LLM의 파라미터는 그대로 둔 채, 프롬프트나 탐색 전략으로 행동을 개선한다.

하지만 이 접근에는 근본적 제약이 있다. 아무리 정교한 프롬프트를 써도, 모델 자체의 능력 한계를 넘을 수 없다. 7B 파라미터의 오픈소스 모델은 GPT-4만큼의 추론 능력이 없고, 프롬프트 엔지니어링만으로 그 간극을 메우기 어렵다. 모델의 능력 자체를 올리려면, 결국 가중치를 업데이트해야 한다.

2024년 3월, Allen Institute for AI와 Peking University 등의 공동 연구팀이 이 문제에 대한 답을 발표했다. ETO — Exploration-based Trajectory Optimization. 제목이 곧 방법론이다. 탐색(Exploration)으로 실패 궤적을 수집하고, 그 궤적을 성공 궤적과 대조하여 정책을 최적화(Optimization)한다. Reflexion과 LATS가 "실패에서 배우되 모델은 바꾸지 않는다"였다면, ETO는 "실패에서 배워서 모델을 바꾼다"이다.

행동 클로닝의 한계 — 성공만 보고 배우는 것의 문제

오픈소스 LLM으로 에이전트를 만드는 표준 방법은 행동 클로닝(Behavioral Cloning)이다. GPT-4 같은 강력한 모델이 과제를 수행하는 모범 궤적을 수집하고, 작은 모델이 그 궤적을 따라하도록 지도 파인튜닝(SFT)한다. 사범대학에서 모범 수업을 관찰하고 따라하는 교생실습과 비슷하다.

이 방법의 문제는 모범만 보여준다는 것이다. 학생에게 "이렇게 해야 한다"만 가르치고, "이렇게 하면 안 된다"는 가르치지 않는다. 결과적으로 에이전트는 전문가가 선택하지 않은 행동 — 잘못된 도구 호출, 비효율적인 탐색 경로, 논리적 오류 — 에 대한 피드백을 받지 못한다. 본 적 없는 상황에서 실수를 반복한다.

인간의 학습은 다르다. 성공적 시연을 관찰하는 것뿐 아니라, 직접 시행착오를 겪으며 "무엇이 잘못되었는지"를 체험한다. ETO는 이 직관을 에이전트 학습에 가져온다.

ETO의 구조 — 탐색과 학습의 반복

ETO의 파이프라인은 두 단계의 반복이다.

1단계: 행동 클로닝으로 기본 에이전트 구축

먼저 전문가 궤적에 대해 SFT를 수행하여 기본 에이전트를 만든다. 이 에이전트는 아직 초보다. 모범 답안을 외웠지만 응용력이 부족한 학생과 같다.

2단계: 탐색-학습 반복 루프

여기서 ETO의 핵심이 시작된다.

탐색 단계: 기본 에이전트가 환경에서 과제를 수행한다. 성공할 수도 있고 실패할 수도 있다. 환경이 보상(0~1)을 반환한다. 에이전트가 생성한 궤적과, 같은 과제에 대한 전문가 궤적을 비교하여 "실패-성공" 쌍을 구성한다. 둘 다 성공하면 그 쌍은 버린다 — 둘 다 잘한 경우에는 대조할 정보가 없기 때문이다.

학습 단계: 수집된 실패-성공 쌍으로 DPO(Direct Preference Optimization) 손실을 사용하여 모델을 업데이트한다. 성공 궤적의 확률은 높이고, 실패 궤적의 확률은 낮추되, 기본 에이전트의 능력이 과도하게 변하지 않도록 KL 제약을 건다.

이 루프를 반복한다. 업데이트된 에이전트가 다시 환경을 탐색하고, 새로운 실패를 수집하고, 다시 학습한다.

DPO — 왜 PPO가 아닌가

에이전트를 환경에서 학습시키는 가장 직관적인 방법은 온라인 강화학습(PPO 등)이다. 하지만 논문은 PPO를 명시적으로 기각한다. 실험에서 PPO는 WebShop에서만 미미한 개선을 보였고, ALFWorld 같은 이진 보상 환경에서는 성능이 처참하게 떨어졌다(SFT 60.0 → PPO 22.1). 온라인 RL의 고유한 불안정성이 LLM 에이전트 학습에서 실질적 장벽이라는 것이다.

DPO는 이 문제를 우회한다. 온라인으로 환경과 상호작용하면서 정책을 업데이트하는 대신, 미리 수집한 궤적 쌍에서 오프라인으로 학습한다. 수학적으로는 RL 목적 함수를 재구성한 것이므로 최종 보상을 직접 최대화하면서도 RL 최적화의 불안정성을 피한다.

궤적 수준 대조의 중요성

ETO에서 흥미로운 설계 결정은 대조의 단위다. 두 가지 선택지가 있다.

궤적 수준 대조: 전체 궤적(시작부터 끝까지)을 단위로 비교한다. "이 궤적은 성공, 이 궤적은 실패."

단계 수준 대조: 개별 행동을 단위로 비교한다. "이 단계에서 이 행동은 좋고, 이 행동은 나쁘다."

직관적으로 단계 수준이 더 세밀한 정보를 제공할 것 같지만, 실험 결과는 정반대였다. 궤적 수준 대조가 67.4점인 반면, 단계 수준 대조는 8.3점으로 붕괴했다. 원인은 보상 할당(credit assignment) 문제다. 에이전트가 최종적으로 실패했더라도, 초반 행동들은 합리적이었을 수 있다. 최종 보상만으로 개별 행동의 품질을 정확히 판단하기 어렵다.

이 관찰은 Reflexion의 제거 실험과도 공명한다. Reflexion에서도 "무엇이 잘못되었는지" 정확히 짚지 못하면 오히려 성능이 떨어졌다. 정확한 피드백 없이 세밀한 수정을 시도하면, 잘못된 방향으로 학습한다.

실험 결과 — 세 가지 벤치마크에서의 검증

논문은 세 가지 벤치마크에서 Llama-2-7B-Chat 기반으로 실험했다. 2024년 초 기준의 결과다.

벤치마크	SFT	PPO	GPT-4	ETO
WebShop	63.1	64.2	63.2	67.4
ScienceWorld (Seen)	67.4	59.4	64.8	73.8
ScienceWorld (Unseen)	53.0	51.7	64.4	65.0
ALFWorld (Seen)	60.0	22.1	42.9	68.6
ALFWorld (Unseen)	67.2	29.1	38.1	72.4

세 가지 관찰이 두드러진다.

첫째, ETO가 모든 벤치마크에서 모든 기준선을 능가한다. WebShop에서 7B 모델이 GPT-4를 넘어선 것(67.4 vs 63.2)은 상징적이다. 물론 특정 과제에서의 결과이고, GPT-4가 WebShop에 최적화되지 않은 상태임을 감안해야 한다.

둘째, OOD(Out-of-Distribution) 일반화에서 ETO가 특히 강력하다. ScienceWorld-Unseen에서 SFT 대비 +12%p, ALFWorld-Unseen에서 +5.2%p. 실패에서 학습한 에이전트가 본 적 없는 환경에서도 더 잘 대처한다. 모범 답안만 외운 학생보다, 시행착오를 겪은 학생이 새로운 문제에 더 유연하게 대응하는 것과 같은 원리다.

셋째, PPO의 실패가 극적이다. ALFWorld에서 SFT 60%에서 PPO 22%로 급락한다. 이진 보상(성공 또는 실패) 환경에서 온라인 RL의 불안정성이 여실히 드러난다.

반복의 수확체감 — 3회가 한계

반복 실험에서 중요한 패턴이 관찰된다. 1~2회 반복에서 큰 성능 향상이 일어나지만, 3회 이상부터는 과적합으로 성능이 정체되거나 오히려 떨어진다. 원인은 대조 데이터의 다양성 감소다. 전문가 궤적 세트는 고정되어 있고, 에이전트가 점점 나아지면서 새로운 실패의 유형이 줄어든다. 같은 종류의 대조 데이터로 반복 학습하면 과적합이 발생한다.

ALFWorld처럼 이진 보상 환경에서는 1회 반복만 효과적이다. "성공 아니면 실패"라는 거친 피드백으로는 세밀한 반복 학습이 어렵다.

Reflexion, LATS, ETO — 세 가지 학습 방식의 비교

시리즈에서 읽은 세 논문은 에이전트 학습의 세 가지 축을 보여준다.

차원	Reflexion	LATS	ETO
학습 방식	자연어 반성	트리 탐색	대조 학습
파라미터 변경	없음	없음	있음 (DPO)
적용 대상	폐쇄형 모델 (GPT-4)	폐쇄형 모델	오픈소스 모델
비용	추론 비용	높은 추론 비용	훈련 비용
일반화	컨텍스트 의존	컨텍스트 의존	모델에 내재화

Reflexion과 LATS는 추론 시간(inference time)에 작동한다. 모델을 바꾸지 않고, 매번 프롬프트와 탐색으로 행동을 개선한다. 장점은 GPT-4 같은 폐쇄형 모델에도 적용할 수 있다는 것이고, 단점은 학습이 모델에 내재화되지 않아 매번 비용이 발생한다는 것이다.

ETO는 훈련 시간(training time)에 작동한다. 모델의 가중치를 바꿔서, 한 번 학습하면 이후에는 추가 비용 없이 개선된 행동을 한다. 장점은 학습이 영구적이라는 것이고, 단점은 오픈소스 모델에만 적용할 수 있고 훈련 비용이 든다는 것이다.

세 접근이 상호 배타적이지 않다는 점도 중요하다. ETO로 기본 능력을 올린 모델에 Reflexion의 자기 반성을 추가하거나, LATS의 트리 탐색을 적용하는 것이 가능하다.

2026년의 시선 — 대조 학습의 현재

논문이 발표된 2024년 3월로부터 2년이 지났다.

실현된 것: DPO 기반 대조 학습은 LLM 학습의 표준 도구가 되었다. RLHF의 복잡한 파이프라인(보상 모델 학습 → PPO 최적화) 대신, DPO가 더 안정적이고 간단한 대안으로 널리 채택되었다. ETO가 에이전트 학습에서 보여준 DPO의 효과는, 이후 수많은 후속 연구에서 확인되었다.

확장된 것: 과적합 문제는 여전히 존재하지만, 더 다양한 환경과 더 큰 데이터셋으로 완화되고 있다. Self-play 방식 — 전문가 궤적 없이 에이전트가 스스로 탐색하고 학습하는 — 이 더 정교해졌다.

여전히 열린 것: 단계 수준의 세밀한 보상 할당(credit assignment)은 여전히 미해결 과제다. 궤적 전체가 아니라 개별 행동의 품질을 정확히 판단할 수 있다면, 학습 효율이 크게 올라갈 것이다. 또한 범용 에이전트(하나의 모델이 여러 과제를 수행)를 위한 다중 과제 학습은 논문이 명시적으로 향후 연구로 남긴 영역이다.

CoALA 좌표계 위의 ETO

CoALA 축	ETO의 위치
기억	실패-성공 궤적 쌍이 학습 데이터로 활용 (외부 메모리)
행동	ReAct 형식의 환경 상호작용
판단	DPO를 통해 판단 능력이 모델 가중치에 내재화

Reflexion이 판단에 시간 축을, LATS가 공간 축을 추가했다면, ETO는 판단의 영구화를 달성한다. 반성이 프롬프트에 남는 것이 아니라, 모델의 가중치 속에 새겨진다. 다음 대화에서도, 다음 세션에서도, 한 번 배운 것을 잊지 않는다.

마무리 — 세 가지 학습의 스펙트럼

Reflexion, LATS, ETO. 세 논문을 연속으로 읽으면서, 에이전트가 실패에서 학습하는 스펙트럼이 그려졌다. 반성으로 배우고(Reflexion), 탐색으로 배우고(LATS), 훈련으로 배운다(ETO). 어느 것이 "최선"이라 단정할 수 없다 — 폐쇄형 모델이냐 오픈소스냐, 추론 비용이냐 훈련 비용이냐, 즉시 적응이냐 영구 학습이냐에 따라 답이 달라진다.

다음 글에서는 한 발 물러서서, 이 모든 에이전트 연구가 실제로 의미 있는지 묻는 논문을 읽는다. AI Agents That Matter — 에이전트 벤치마크의 함정을 파헤치는 비판적 분석이다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 열 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: LATS — 트리 탐색으로 추론과 행동을 통합하다

Fri, 03 Apr 2026 17:00:00 GMT

논문 정보

제목: Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Models

저자: Andy Zhou, Kai Yan, Michal Shlapentokh-Rothman, Haohan Wang, Yu-Xiong Wang (University of Illinois Urbana-Champaign, Lapis Labs)

출판: ICML 2024 (PMLR 235)

arXiv: 2310.04406

앞선 글에서 Reflexion을 읽었다. 에이전트가 실패하면 자연어로 반성하고, 그 반성을 다음 시도의 컨텍스트에 추가한다. 직선적인 되감기였다. 한 번 실패하면, 실패를 복기하고, 다시 처음부터 시도한다.

하지만 직선에는 한계가 있다. 미로에서 막다른 골목을 만났을 때, "아까 왼쪽으로 가지 말았어야 했다"라고 반성한 뒤 입구로 돌아가 처음부터 다시 걷는 것은 비효율적이다. 더 나은 전략은 갈림길로 돌아가서, 아직 가보지 않은 오른쪽 길을 시도하는 것이다. 이것이 트리 탐색의 발상이다.

2023년 10월, University of Illinois의 연구팀이 이 발상을 논문으로 발표했다. LATS — Language Agent Tree Search. 몬테카를로 트리 탐색(MCTS)을 LLM 에이전트에 적용하여, 추론과 행동과 계획을 하나의 프레임워크로 통합한다. Reflexion이 실패 후 전체를 되감았다면, LATS는 실패 지점의 갈림길로 돌아가 다른 가지를 뻗는다.

왜 직선이 아니라 트리인가

시리즈에서 읽어온 방법들을 나란히 놓으면, 각각이 무엇을 할 수 있고 무엇을 못하는지가 선명해진다.

방법	추론	행동	계획	자기 반성	외부 메모리
CoT	O	X	X	X	X
ReAct	O	O	X	X	X
Reflexion	O	O	X	O	O
LATS	O	O	O	O	O

CoT는 생각만 한다. ReAct는 생각하며 행동한다. Reflexion은 실패를 되돌아보며 다시 시도한다. 하지만 이 모든 방법은 한 가지 공통 제약을 가진다 — 단일 궤적만 탐색한다. 한 번에 하나의 길만 걷는다. 갈림길에서 하나를 선택하면, 나머지는 버린다.

LATS가 추가하는 것은 계획이다. 여러 가능한 경로를 동시에 열어두고, 가장 유망한 곳을 체계적으로 탐색한다. 실패하면 그 지점을 기억하고, 아직 탐색하지 않은 다른 경로로 이동한다. 버린 길을 다시 주울 수 있다.

몬테카를로 트리 탐색 — 바둑에서 온 알고리즘

LATS의 핵심 엔진은 몬테카를로 트리 탐색(MCTS)이다. AlphaGo가 바둑에서 인간 챔피언을 이길 때 사용한 바로 그 알고리즘이다.

MCTS의 핵심 아이디어는 탐색과 활용의 균형이다. 이미 좋은 결과를 보인 경로를 더 깊이 탐색(활용)하면서도, 아직 시도하지 않은 경로에도 기회를 준다(탐색). 이 균형을 수학적으로 제어하는 것이 UCT(Upper Confidence bounds for Trees) 공식이다.

바둑에서 MCTS가 작동하는 이유는, 이전 수로 돌아갈 수 있기 때문이다. 논문의 핵심 관찰은 LLM 과제에서도 같은 조건이 성립한다는 것이다. 텍스트 기반 과제에서 "이전 상태로 되돌리기"란, 이전 단계의 텍스트 입출력을 그대로 복사하여 다시 시작하는 것에 불과하다. 물리적 환경과 달리, 텍스트 세계에서는 시간을 되감는 비용이 사실상 제로다.

여섯 개의 연산 — LATS가 돌아가는 방식

LATS는 여섯 개의 연산을 반복한다. 각 연산이 하나씩 트리를 성장시키고 정제한다.

선택: 루트에서 시작하여, UCT 값이 가장 높은 자식 노드를 따라 리프까지 내려간다. 이미 많이 방문한 노드보다 덜 방문한 노드에 가산점을 주어, 탐색이 한쪽으로 편향되지 않도록 한다.

확장: 선택된 리프 노드에서 LLM으로 n개의 행동을 샘플링한다. 각 행동이 새로운 자식 노드가 된다. 한 번에 하나의 행동만 선택하는 ReAct와의 핵심 차이다 — LATS는 한 시점에서 여러 가능성을 동시에 열어둔다.

평가: 새로 생성된 자식 노드에 가치를 매긴다. LATS의 가치 함수는 두 요소의 결합이다. 하나는 LLM 자체를 가치 함수로 재활용하여 궤적의 정확성을 평가하는 것이고, 다른 하나는 자기 일관성(self-consistency) 점수 — 같은 상태에서 여러 번 샘플링했을 때 일관된 행동이 나올수록 높은 점수를 부여하는 것이다. ToT와의 핵심 차이는, LATS가 환경으로부터 피드백을 받은 뒤에 가치를 평가한다는 점이다. 행동의 결과를 보고 나서 판단하는 것이 행동 전에 판단하는 것보다 정확하다.

시뮬레이션: 선택된 노드에서 터미널 상태까지 진행한다. 최고 가치 노드를 우선 탐색하여 깊이 방향으로 확장한다.

역전파: 터미널 상태에 도달하면, 그 결과(보상)를 루트까지 거슬러 올라가며 경로상 모든 노드의 가치를 업데이트한다. 성공한 경로의 노드들은 가치가 올라가고, 실패한 경로의 노드들은 내려간다.

반성: 실패한 터미널 노드에서 Reflexion과 같은 방식으로 자기 반성을 수행한다. 오류를 요약하고, 더 나은 대안을 제시하는 텍스트를 생성하여 메모리에 저장한다. 이 반성이 이후 반복에서 추가 컨텍스트로 활용된다.

Reflexion과의 관계 — 경쟁이 아니라 확장

LATS는 Reflexion을 부정하지 않는다. 오히려 품는다.

Reflexion의 핵심 요소 — 자기 반성과 에피소드 메모리 — 는 LATS의 여섯 번째 연산으로 그대로 통합된다. 차이는 반성이 작동하는 맥락이다. Reflexion에서 반성은 전체 시도가 실패한 후 일어난다. LATS에서 반성은 트리의 한 가지가 실패할 때마다 일어나고, 그 반성이 다른 가지의 탐색을 안내한다.

제거 실험이 이 관계를 수치로 보여준다. HotPotQA에서 자기 반성을 제거하면 성능이 0.63에서 0.58로 떨어진다. 하지만 LM 가치 함수를 제거하면 0.63에서 0.37로 급락한다. LATS에서 가장 중요한 구성요소는 반성이 아니라 가치 함수, 즉 체계적 탐색 자체다. 반성은 탐색을 보조하는 역할이다.

이것이 함의하는 바는 명확하다. Reflexion의 "되감기 후 재시도"보다, LATS의 "갈림길로 돌아가서 다른 길 탐색"이 더 효과적인 구조적 이유가 있다.

실험 결과 — 세 전장에서의 검증

논문은 네 가지 도메인에서 실험했다. 2023년 말~2024년 초 기준의 결과다.

HotPotQA (GPT-3.5 기준): LATS(CoT+ReAct)가 EM 0.71을 달성하여, ReAct(0.32)의 두 배 이상, Reflexion(0.51)보다 20%p 높은 성능을 보였다. 흥미로운 관찰은, 단순히 ToT에 ReAct를 추가하거나 RAP에 ReAct를 추가하면 오히려 추론만 했을 때보다 성능이 떨어진다는 것이다. 추론과 행동의 결합은 단순한 합산이 아니라, MCTS라는 체계적 탐색 알고리즘을 통해야 효과적으로 통합된다.

프로그래밍 (HumanEval): GPT-3.5에서 LATS가 83.8%로 Reflexion(68.1%)을 15.7%p 앞섰다. GPT-4에서는 92.7%로, 바로 앞 글에서 읽은 Reflexion의 91.0%를 다시 넘어 당시 새로운 SOTA를 수립했다. 같은 모델, 같은 벤치마크에서 탐색 전략의 차이만으로 성능이 달라진다.

WebShop (GPT-3.5): LATS가 75.9점으로, Reflexion(64.2)과 ReAct(53.8)을 크게 앞섰다. 더 놀라운 것은 지도학습+강화학습(IL+RL) 파인튜닝(62.4)을 추론만으로 넘어섰다는 점이다. 가중치를 건드리지 않고, 탐색 전략만으로 파인튜닝에 필적하는 성능을 달성한 것이다.

비용과 한계 — 공짜 점심은 없다

LATS의 강력한 성능에는 대가가 있다. 트리 탐색은 본질적으로 다중 경로를 탐색하므로, LLM 호출 횟수가 ReAct나 Reflexion보다 많다. 논문은 이 비용을 솔직하게 인정하면서, 점근적으로 같은 샘플 복잡도를 가지며 평균적으로 더 적은 노드를 확장한다고 주장한다.

더 근본적인 한계는 되돌리기 가정이다. MCTS는 이전 상태로 되돌아갈 수 있어야 한다. 프로그래밍, 웹 탐색, 텍스트 게임에서는 이전 입력을 복사하면 되므로 자연스럽게 성립한다. 하지만 물리적 로봇 조작이나 비가역적 트랜잭션에서는 이 가정이 깨진다. 이메일을 보내는 행동은 되돌릴 수 없다.

탐색 폭 n이 성능과 비용의 자연스러운 조절 장치가 된다. n=1이면 ReAct와 같은 단일 궤적이고, n이 커질수록 더 넓은 탐색이 이루어지지만 비용도 비례하여 증가한다. 논문은 이 트레이드오프가 환경의 복잡도에 따라 조정되어야 한다고 제안한다.

2026년의 시선 — 트리 탐색의 현재

논문이 발표된 2023년 가을로부터 2년 반이 지났다.

실현된 것: MCTS와 LLM의 결합이라는 아이디어는 에이전트 연구의 주요 줄기가 되었다. OpenAI의 o1 시리즈가 "추론 시간 컴퓨팅(inference-time compute)"이라는 개념으로 이를 대규모로 실현했다. 더 많이 생각하면(더 많은 토큰을 생성하면) 더 정확한 답을 낼 수 있다는 발상은 LATS가 보여준 "더 넓게 탐색하면 더 좋은 경로를 찾을 수 있다"와 같은 근본 원리다.

확장된 것: LATS가 제기한 비용 문제는 여전히 유효하지만, 모델 추론 비용의 급격한 하락으로 실용성의 경계가 넓어졌다. 2023년에 비용 때문에 n=2~3이 한계였다면, 현재는 더 넓은 탐색이 경제적으로 가능해졌다.

여전히 열린 것: 되돌리기 불가능한 환경에서의 계획은 여전히 미해결 과제다. 실세계 에이전트가 물리적 행동을 취할 때, 잘못된 행동을 되감을 수 없다. 시뮬레이션 환경에서 먼저 탐색한 후 실세계에 최적 경로만 실행하는 접근이 탐구되고 있지만, 시뮬레이션과 현실의 간극은 별도의 문제를 만든다.

CoALA 좌표계 위의 LATS

CoALA 축	LATS의 위치
기억	트리 구조 전체가 외부 장기 메모리 + 반성 텍스트
행동	ReAct 기반으로 환경과 상호작용, 다중 행동 샘플링
판단	LM 가치 함수 + UCT 알고리즘으로 체계적 탐색 판단

Reflexion이 CoALA의 판단 축에 시간 차원을 추가했다면, LATS는 판단 축에 공간 차원을 추가한다. 하나의 시점에서 여러 가능한 미래를 동시에 평가하고, 가장 유망한 방향을 선택한다. 판단이 되감기에서 갈림길 탐색으로 진화한 것이다.

마무리 — 탐색의 범용성

LATS가 보여준 것은 체계적 탐색이 에이전트의 능력을 끌어올리는 범용적 전략이라는 점이다. 추론, 행동, 반성 — 이 모든 것이 탐색 알고리즘이라는 하나의 우산 아래서 시너지를 만든다. 하지만 그 범용성에는 조건이 붙는다. 되돌리기가 가능한 환경, 충분한 추론 예산, 그리고 적절한 가치 함수.

다음 글에서는 에이전트 학습의 세 번째 방식을 읽는다. Reflexion이 반성으로, LATS가 탐색으로 학습했다면, ETO(Trial and Error)는 실패 궤적과 성공 궤적의 대조 학습으로 에이전트를 직접 훈련시킨다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 아홉 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Reflexion — 실패를 언어로 되감는 에이전트

Fri, 03 Apr 2026 13:00:00 GMT

논문 정보

제목: Reflexion: Language Agents with Verbal Reinforcement Learning

저자: Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao (Northeastern University, MIT, Princeton University)

출판: NeurIPS 2023

arXiv: 2303.11366

시리즈의 앞선 글들에서 우리는 에이전트의 뼈대를 세워왔다. CoALA가 기억-행동-판단이라는 인지 좌표계를 그렸고, CoT가 추론의 씨앗을 심었고, ReAct가 그 추론에 행동을 엮었다. Toolformer는 도구를 집어들었고, AutoGen과 MetaGPT는 에이전트를 여럿으로 불렸다. Multi-Agent Survey는 그 전체 지형을 내려다보았다.

하지만 지형도를 아무리 정교하게 그려도, 하나의 핵심 질문이 남아 있었다. 에이전트가 실패하면 어떻게 하는가? 같은 실수를 반복하지 않으려면 무엇이 필요한가?

2023년 3월, Northeastern University, MIT, Princeton의 공동 연구팀이 이 질문에 답하는 논문을 발표했다. 2023년은 LLM 에이전트 연구의 폭발기였다. ReAct가 추론과 행동의 교차를 보여준 직후, 자연스럽게 떠오른 다음 문제는 "실패한 행동을 어떻게 교정하는가"였다. 전통적 강화학습은 가중치를 업데이트하지만, 수십억 파라미터의 모델을 과제마다 파인튜닝하는 것은 현실적이지 않았다. Reflexion의 아이디어는 놀랍도록 단순하다. 가중치를 바꾸지 말고, 실패를 말로 되돌아보게 하자.

의미적 기울기 — 숫자가 아니라 문장으로 배우기

전통적 강화학습에서 에이전트는 스칼라 보상 신호를 받는다. +1 또는 -1. 성공이냐 실패냐. 이 숫자로 기울기를 계산하고, 가중치를 조정한다. 수십만 번의 반복이 필요한 이유는 하나의 숫자가 담을 수 있는 정보가 극히 제한적이기 때문이다. "실패했다"는 알려주지만, "왜 실패했는지"는 알려주지 않는다.

Reflexion이 제안하는 것은 이 스칼라 신호를 자연어로 확장하는 것이다. 논문은 이를 의미적 기울기(semantic gradient)라 부른다. 수학적 기울기가 파라미터 공간에서 손실을 줄이는 방향을 가리키듯, 의미적 기울기는 의미 공간에서 행동을 개선하는 방향을 가리킨다. 다만 그 방향이 벡터가 아니라 문장으로 표현된다.

인간이 체스에서 진 후 하는 일을 떠올려보면 직관적이다. 점수판을 보고 "졌다"만 확인하는 게 아니라, "중반에 퀸을 너무 일찍 내보내서 수비가 무너졌다. 다음에는 중앙 통제를 먼저 확보해야 한다"라고 복기한다. Reflexion은 LLM에게 이 복기를 시킨다.

세 개의 모듈 — Actor, Evaluator, Self-Reflection

Reflexion은 세 개의 독립적 모듈로 구성된다. 각각이 분리된 역할을 맡으며, 이 분리가 프레임워크의 유연성을 만든다.

Actor는 실제로 환경과 상호작용하는 에이전트다. CoT나 ReAct 같은 기존 행동 생성 전략을 그대로 사용할 수 있다. 핵심은 Actor가 행동할 때 메모리 컴포넌트를 참조한다는 점이다. 이 메모리에 과거의 반성이 저장되어 있다.

Evaluator는 Actor의 결과를 평가한다. 흥미로운 것은 평가 방식이 과제마다 완전히 다르다는 점이다. 추론 과제에서는 정답과의 정확 일치(exact match)를 사용하고, 의사결정 과제에서는 휴리스틱을 사용한다. "같은 행동을 세 번 반복하면 환각", "30단계를 넘기면 비효율적 계획"이라는 규칙이다. 프로그래밍 과제에서는 LLM이 스스로 단위 테스트를 생성하고 실행한다. Evaluator가 하나의 범용 모듈이 아니라 과제에 맞게 교체되는 설계는, Reflexion이 특정 평가 방식에 묶이지 않겠다는 의도를 보여준다.

Self-Reflection이 Reflexion의 이름을 만든 핵심이다. 이 모듈은 실패한 궤적과 Evaluator의 판정을 받아, 자연어로 된 반성을 생성한다. "열쇠를 서랍에서 찾으려 했지만 실제로는 선반 위에 있었다. 다음에는 서랍이 비어 있으면 즉시 다른 위치를 탐색해야 한다." 이런 문장이 에피소드 메모리에 쌓이고, 다음 시도에서 Actor의 컨텍스트에 추가된다.

반복의 구조 — 알고리즘이 돌아가는 방식

Reflexion 프로세스는 반복적 루프다.

Actor가 환경과 상호작용하여 궤적을 생성한다
Evaluator가 이 궤적을 평가하여 성공/실패를 판정한다
실패했다면, Self-Reflection이 궤적과 판정을 분석하여 반성을 생성한다
반성이 에피소드 메모리에 저장된다
다음 시도에서 Actor가 이 메모리를 참조하여 새로운 궤적을 생성한다
성공하거나 최대 시도 횟수에 도달할 때까지 반복한다

메모리는 슬라이딩 윈도우로 관리된다. 최근 1~3개의 반성만 유지한다. 논문이 쓰인 당시 LLM의 컨텍스트 윈도우가 제한적이었기 때문이다. 이 설계가 함의하는 것은 Reflexion이 전체 이력을 학습하는 것이 아니라, 가장 최근의 실패에서 가장 즉각적인 교훈을 추출하는 데 집중한다는 점이다.

전통적 강화학습과의 차이를 정리하면 이렇다.

차원	전통적 RL	Reflexion
학습 신호	스칼라 보상	자연어 반성
파라미터 업데이트	가중치 조정	없음 (메모리 추가)
해석 가능성	낮음 (가중치 변화)	높음 (반성 텍스트 직접 읽기 가능)
비용	파인튜닝 비용	추론 비용만
수렴 보장	이론적 보장 존재	형식적 보장 없음

세 가지 전장에서의 실험

논문은 서로 성격이 다른 세 가지 과제에서 Reflexion을 검증했다. 논문이 발표된 2023년 초 기준의 결과임을 감안해야 한다.

순차적 의사결정: ALFWorld

ALFWorld는 텍스트 기반 가상 가정 환경이다. 134개의 과제 — 숨겨진 물건 찾기, 물건 이동, 조작 — 를 에이전트가 해결해야 한다. ReAct를 Actor로 사용한 Reflexion은 130/134 과제를 해결하여 97%의 성공률을 기록했다. ReAct 단독은 약 75%에서 정체되었고, 환각 비율이 22%로 수렴하여 더 이상 개선되지 않았다.

가장 흥미로운 관찰은 학습 곡선이다. 처음 2~~3회 시도에서 급격한 향상이 일어나고, 이후 12회까지 완만하게 개선된다. 기준선인 ReAct 단독은 시도 6~~7회 사이에서 완전히 정체된다. 환각에 빠진 에이전트는 아이템을 가지고 있다고 믿지만 실제로는 없다. Reflexion은 이 환각을 반성을 통해 포착하고, 다음 시도에서 회피한다.

추론: HotPotQA

다단계 추론 과제에서 Reflexion은 CoT(GT) + GPT-4 조합으로 68%에서 80%로, ReAct + GPT-4 조합으로 39%에서 51%로 성능을 끌어올렸다. 제거 실험이 특히 의미 있다. 에피소드 메모리만 사용하고 자기 반성을 제거하면 +8%의 성능 차이가 발생한다. 과거 궤적을 그대로 기억하는 것보다, 그 궤적에서 교훈을 추출하는 반성 과정이 추가적인 가치를 만든다는 증거다.

프로그래밍: HumanEval과 MBPP

논문이 가장 극적인 수치를 보인 영역이다. HumanEval Python에서 91% pass@1을 달성하여, 당시 GPT-4 단독의 80.1%를 11%p 앞섰다. 이 결과가 당시 기준으로 새로운 SOTA였다.

프로그래밍 과제에서 Reflexion의 작동 방식은 다른 과제와 구별된다. Evaluator가 LLM 자체를 활용하여 단위 테스트를 생성하고, 이 테스트를 실제로 실행하여 피드백을 얻는다. 코드가 테스트를 통과하지 못하면, Self-Reflection이 실패 원인을 분석하고 수정 방향을 제시한다.

제거 실험이 중요한 교훈을 준다. 테스트 생성 없이 자기 반성만 적용하면 성능이 기준선(60%)보다 오히려 떨어진다(52%). 자기 코드가 맞는지 틀린지 판단할 근거가 없는 상태에서 반성하면, 잘못된 방향으로 수정할 수 있다. 반성이 효과를 내려면 정확한 평가가 선행되어야 한다.

벤치마크	당시 SOTA	GPT-4 단독	Reflexion
HumanEval (Python)	65.8	80.1	91.0
HumanEval (Rust)	—	60.0	68.0
MBPP (Python)	67.7	80.1	77.1
LeetcodeHard	—	7.5	15.0

MBPP에서 Reflexion이 GPT-4 단독보다 낮은 것도 주목할 만하다. 모든 과제에서 반성이 유효한 것은 아니다.

반성이 작동하지 않는 곳 — 한계의 지형

Reflexion의 한계는 세 가지 축에서 드러난다.

첫째, 로컬 미니마 문제다. 언어적 반성도 결국 일종의 정책 최적화이고, 최적화는 로컬 미니마에 빠질 수 있다. WebShop 실험에서 이 현상이 관찰되었다. 매우 다양하고 독특한 행동이 필요한 환경에서는, 과거 반성이 오히려 탐색을 제한할 수 있다.

둘째, 메모리 용량의 한계다. 슬라이딩 윈도우가 최근 1~3개의 반성만 유지하므로, 장기적 학습이 제한된다. 논문은 벡터 임베딩 DB나 SQL DB로의 확장을 향후 연구로 제안했다.

셋째, 자기 반성 능력 자체가 모델 크기에 의존한다. 논문은 starchat-beta 같은 소형 모델에서는 Reflexion이 개선을 보이지 않았다고 보고한다. 자기 반성은 충분히 강한 모델에서만 나타나는 창발적 능력이다.

2026년의 시선 — 예측의 검증

논문이 쓰인 2023년 초로부터 3년이 지난 지금, Reflexion의 아이디어가 어떻게 전개되었는지 돌아볼 수 있다.

실현된 것: 자기 반성 패턴은 에이전트 설계의 기본 구성요소가 되었다. 거의 모든 주요 에이전트 프레임워크 — LangGraph, CrewAI, AutoGen — 가 실패 시 자기 반성 루프를 내장하고 있다. "실패 → 반성 → 재시도"라는 패턴은 Reflexion 이후 사실상 표준이 되었다.

확장된 것: 메모리의 한계는 컨텍스트 윈도우의 확장(GPT-4 Turbo의 128K, Claude의 200K)과 외부 메모리 시스템의 발전으로 상당 부분 완화되었다. 논문이 제안한 "벡터 DB로의 확장"은 이미 일반적인 구현 패턴이 되었다.

여전히 열린 것: 로컬 미니마 문제는 해결되지 않았다. 반성이 탐색을 제한하는 문제 — 이전 실패에 과도하게 반응하여 유효한 전략까지 회피하는 현상 — 는 여전히 에이전트 설계의 열린 과제다. 또한 "반성의 품질"을 어떻게 보장하는가라는 질문도 남아 있다. 잘못된 반성은 잘못된 학습으로 이어진다.

CoALA 좌표계 위의 Reflexion

시리즈 첫 글에서 세운 CoALA의 인지 아키텍처 좌표계 위에 Reflexion을 놓아보자.

CoALA 축	Reflexion의 위치
기억	단기(궤적) + 장기(반성 요약). 슬라이딩 윈도우로 관리
행동	Actor가 CoT/ReAct 기반으로 환경과 상호작용
판단	Evaluator가 과제별 평가 + Self-Reflection이 언어적 판단

Reflexion이 CoALA 프레임워크에 추가하는 것은 판단 축의 확장이다. CoALA가 판단을 "무엇을 할지 결정하는 것"으로 정의했다면, Reflexion은 판단에 시간 축을 더한다 — "과거에 왜 실패했는지 판단하고, 미래에 무엇을 달리할지 결정하는 것".

마무리 — 실패가 자산이 되려면

Reflexion이 보여준 것은 LLM이 실패를 경험이 아니라 교훈으로 변환할 수 있다는 가능성이다. 가중치를 건드리지 않고, 오직 자연어 반성만으로 행동을 개선한다. 하지만 그 가능성에는 조건이 붙는다. 정확한 평가가 선행되어야 하고, 모델이 충분히 강해야 하고, 반성이 잘못된 방향으로 흐르지 않아야 한다.

다음 글에서는 이 반성의 아이디어를 트리 탐색과 결합한 LATS를 읽는다. Reflexion이 직선적으로 되감기를 했다면, LATS는 갈림길에서 여러 경로를 동시에 탐색한다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 여덟 번째 글입니다. 시리즈 전체 목록은 시리즈 페이지에서 확인할 수 있습니다.

Agentic AI 논문 읽기: Multi-Agent Survey — 집단 지능의 지도를 펼치다

Fri, 03 Apr 2026 09:00:00 GMT

논문 정보

제목: Large Language Model based Multi-Agents: A Survey of Progress and Challenges

저자: Taicheng Guo, Xiuying Chen, Yaqi Wang, Ruidi Chang, Shichao Pei, Nitesh V. Chawla, Olaf Wiest, Xiangliang Zhang (University of Notre Dame, KAUST, SUSTech, UMass Boston)

출판: arXiv 2402.01680 (2024.01, revised 2024.04)

지난 글의 마지막 질문을 기억한다. "에이전트에게 자기 성찰의 능력을 부여할 수 있는가?" AutoGen의 유연한 대화와 MetaGPT의 엄격한 절차, 정반대의 철학이 같은 빈칸 앞에 서 있었다. 장기 기억이 없고, 실패에서 학습하지 못하고, 같은 실수를 반복한다는 것.

그 질문에 답하기 전에, 한 발 물러서야 할 순간이 왔다.

시리즈는 여기까지 개별 논문을 하나씩 등반하듯 읽어왔다. CoALA가 좌표계를 펼쳤고, CoT가 추론을 증명했고, ReAct가 추론에 행동을 엮었고, Toolformer가 행동의 자율성을 보였다. AutoGen은 유연한 대화로 다중 에이전트의 문을 열었고, MetaGPT는 엄격한 절차로 그 문 안에 질서를 세웠다. 개체의 지능에서 집단의 지능으로, 다시 집단의 조직으로 — 한 단계씩 봉우리를 넘어왔다.

이제 봉우리 위에서 전체 산맥을 내려다볼 차례다.

2024년 1월, University of Notre Dame과 KAUST의 연구팀이 LLM 기반 다중 에이전트 시스템 전체를 조망하는 서베이를 발표했다. CAMEL이 다중 에이전트의 문을 연 2023년 3월 이후, 불과 10개월 만에 수십 편의 논문이 쏟아졌다. 소프트웨어 개발, 로봇 협업, 사회 시뮬레이션, 게임, 과학 토론 — 분야도, 접근법도, 용어도 제각각이었다. 이 논문은 그 혼돈에 하나의 정리 축을 세운다. 네 개의 축으로 모든 다중 에이전트 시스템을 분류하고, 응용을 두 갈래로 나누고, 여섯 가지 열린 도전을 식별한다.

CoALA가 단일 에이전트의 내부를 해부하는 지도였다면, 이 서베이는 에이전트들이 모여 만드는 집단의 지형을 그리는 지도다.

왜 서베이가 필요한가 — 개별 연구의 숲과 나무

나무 한 그루를 자세히 관찰하면 껍질의 무늬, 가지의 방향, 잎의 형태를 알 수 있다. 하지만 숲의 구조 — 어떤 나무들이 함께 자라는지, 수원지가 어디인지, 길이 어디로 통하는지 — 는 높은 곳에 올라서야 보인다.

시리즈에서 우리는 나무를 봐왔다. AutoGen이라는 나무를 보면서 "대화로 엮는 유연한 협업"을 이해했고, MetaGPT라는 나무를 보면서 "절차로 짜인 구조적 협업"을 이해했다. 하지만 이 두 시스템이 다중 에이전트라는 숲에서 어디쯤에 서 있는지, 어떤 나무들이 아직 탐색되지 않았는지는 개별 논문만 읽어서는 파악하기 어렵다.

서베이가 쓰인 2024년 초 시점에서, 다중 에이전트 연구는 이미 체계적 정리가 절실했다. 2023년 3월 CAMEL 이후 10개월 동안 독립적으로 쏟아진 논문들은 저마다 다른 용어, 다른 프레임워크, 다른 평가 기준을 사용했다. 같은 개념을 다른 이름으로 부르거나, 다른 개념을 같은 이름으로 혼용하는 경우도 빈번했다. 단일 에이전트 연구에서 CoALA가 "기억-행동-판단"이라는 공통 좌표계를 제시하여 혼란을 정리한 것처럼, 다중 에이전트 연구에도 공통 분류 체계가 필요했다.

이 서베이가 제시하는 것은 네 개의 축으로 이루어진 분류 프레임워크다. 어떤 다중 에이전트 시스템이든, 이 네 개의 질문으로 해부할 수 있다. 에이전트가 어디에서 활동하는가? 에이전트가 어떻게 정의되는가? 에이전트가 어떻게 소통하는가? 에이전트가 어떻게 성장하는가?

네 개의 축 — 다중 에이전트를 해부하는 프레임워크

서베이의 핵심 기여는 이 4축 분석 프레임워크다. 하나씩 뜯어본다.

첫 번째 축: 에이전트-환경 인터페이스

에이전트가 활동하는 무대를 세 가지로 분류한다.

유형	설명	대표 사례
샌드박스(Sandbox)	인간이 구축한 시뮬레이션/가상 환경	코드 인터프리터, 게임, Minecraft
물리 환경(Physical)	실세계 물리 법칙이 적용되는 환경	로봇 조작, 창고 관리
없음(None)	환경 없이 에이전트 간 소통만 존재	과학 토론, 합의 도출

흥미로운 것은 세 번째 유형이다. 환경이 없다. 에이전트들이 물리적 행동을 취하지 않고, 오직 서로에게 말하는 것만으로 과제를 수행한다. 과학 토론에서 여러 LLM이 논쟁하며 합의에 도달하는 경우가 이에 해당한다. 행동 없이 대화만으로도 집단 지능이 발현될 수 있다는 것 — 이것은 AutoGen의 "대화가 곧 프로그래밍"이라는 철학과 공명한다.

두 번째 축: 에이전트 프로파일링

에이전트에게 정체성을 부여하는 방식을 세 가지로 나눈다.

방법	설명	사용 비율
사전 정의(Pre-defined)	설계자가 역할, 능력, 제약을 명시	가장 일반적
모델 생성(Model-Generated)	LLM이 에이전트 프로필을 자동 생성	소수
데이터 기반(Data-Derived)	기존 데이터셋에서 프로필 구성	사회 시뮬레이션에서 주로 사용

논문이 쓰인 당시 기준으로, 대다수의 시스템이 사전 정의 방식을 채택했다. MetaGPT의 다섯 가지 역할(Product Manager, Architect, Project Manager, Engineer, QA Engineer)이 전형적인 예다. 설계자가 각 에이전트의 이름, 목표, 스킬, 제약을 시스템 프롬프트로 주입한다.

모델 생성 방식은 더 야심적이다. LLM 스스로가 "이 과제에는 어떤 역할이 필요한가?"를 판단하고 에이전트를 정의한다. 하지만 이 방식은 프로파일의 품질이 LLM의 판단에 전적으로 의존하기 때문에, 예측 가능성과 재현성이 떨어진다는 한계가 있었다.

데이터 기반 방식은 사회 시뮬레이션에서 빛난다. Generative Agents가 25명의 가상 주민을 시뮬레이션할 때, 각 에이전트의 프로필은 인구 통계 데이터에서 파생되었다. 17,945명 규모의 S³ 시뮬레이션에서는 실제 사회 데이터를 기반으로 에이전트 집단을 구성했다.

세 번째 축: 에이전트 통신

이 축이 가장 풍부하다. 서베이는 통신을 세 겹으로 분해한다 — 패러다임, 구조, 내용.

통신 패러다임은 에이전트들이 왜 소통하는가를 분류한다.

패러다임	특성	대표 사례
협력(Cooperative)	공유 목표를 향해 정보 교환	소프트웨어 개발, 로봇 협업
토론(Debate)	논쟁을 통해 해결책을 정제	과학 토론, 사실 검증
경쟁(Competitive)	서로 상충하는 목표 추구	게임(Werewolf, Diplomacy)

통신 구조는 에이전트들이 어떻게 소통하는가를 분류한다. 이 부분이 AutoGen과 MetaGPT를 새로운 렌즈로 볼 수 있게 해주는 핵심이다.

구조	특성	대표 사례
계층적(Layered)	계층별 역할, 인접 계층끼리 소통	DyLAN
분산(Decentralized)	P2P 직접 통신, 중앙 없음	Generative Agents, 사회 시뮬레이션
중앙집중(Centralized)	중앙 에이전트가 모든 통신 조율	과학 실험 팀
공유 메시지 풀(Shared Message Pool)	발행-구독 메커니즘	MetaGPT

네 번째 구조가 눈에 띈다. 공유 메시지 풀은 MetaGPT가 제안한 것이다. 에이전트가 구조화된 메시지를 풀에 발행하고, 역할에 따라 관련 메시지만 구독한다. 서베이가 이것을 계층적, 분산, 중앙집중과 동등한 수준의 독립적 통신 구조로 분류한 것은, MetaGPT의 설계가 단순한 구현 기법이 아니라 통신 아키텍처의 새로운 패러다임이었음을 의미한다.

네 번째 축: 에이전트 능력 획득

에이전트가 어떻게 성장하는가를 두 단계로 분석한다. 먼저 어떤 피드백을 받는가, 그리고 그 피드백으로 어떻게 적응하는가.

피드백 유형:

유형	설명	사례
환경 피드백	코드 실행 결과, 물리 환경 반응	소프트웨어 개발, 로봇
에이전트 상호작용 피드백	다른 에이전트의 판단, 비판, 동의	토론, 게임
인간 피드백	인간 가치와 선호도 정렬	Human-in-the-loop 시스템
없음	피드백 없이 시뮬레이션 결과만 분석	전염병 전파 모델링

적응 전략:

전략	설명	사례
메모리	과거 경험 저장·검색으로 행동 개선	대부분의 시스템
자기 진화(Self-Evolution)	피드백 기반으로 목표·전략을 동적 수정	ProAgent, LTC
동적 생성(Dynamic Generation)	운영 중 새로운 에이전트를 즉석 생성	스케일링이 필요한 시스템

자기 진화가 특히 주목할 만하다. ProAgent는 팀원의 결정을 예측하고 통신 로그에 기반하여 전략을 동적으로 조정했다. LTC(Learning through Communication)는 다중 에이전트 통신 로그를 사용하여 데이터셋을 생성한 뒤 LLM을 파인튜닝하는 패러다임을 제안했다. 인컨텍스트 학습의 한계를 넘어, 에이전트가 자율적으로 프로필이나 목표를 조정하는 것이다.

하지만 서베이는 솔직하게 인정한다. 논문이 쓰인 시점에서 대부분의 시스템은 메모리 기반 적응에 머물러 있었고, 자기 진화는 소수의 실험적 시도에 불과했다. 이것이 바로 AutoGen과 MetaGPT가 공유하던 빈칸 — 경험에서 학습하지 못한다는 한계 — 의 서베이적 확인이다.

AutoGen과 MetaGPT를 다시 본다 — 4축 위의 좌표

이제 이 4축 프레임워크를 렌즈로 삼아, 시리즈에서 이미 다뤘던 두 시스템을 다시 들여다본다. 익숙한 지형을 새로운 지도 위에 올려놓으면, 개별 분석에서는 보이지 않던 것들이 드러난다.

축	AutoGen	MetaGPT
환경 인터페이스	샌드박스 (코드 실행) + 없음 (순수 대화 과제)	샌드박스 (코드 실행 + 테스트 실행)
프로파일링	사전 정의 (시스템 메시지로 역할 부여)	사전 정의 (이름·목표·스킬·제약 명시)
통신 패러다임	협력 + 토론 (에이전트 간 피드백 루프)	협력 (순차적 산출물 전달)
통신 구조	중앙집중 (GroupChatManager)	공유 메시지 풀 (발행-구독)
피드백 유형	환경 (코드 실행) + 인간 (UserProxy)	환경 (코드 실행 + 테스트)
적응 전략	메모리 (대화 이력)	메모리 (구조화된 산출물)

이전 글에서 두 시스템의 차이를 "유연한 대화 vs 엄격한 절차"로 요약했다. 4축 프레임워크는 이 직관적 대비를 더 정밀한 언어로 분해해준다.

통신 구조의 차이가 가장 선명하다. AutoGen의 GroupChatManager는 중앙집중형이다. 모든 대화가 중앙을 거치고, 중앙이 다음 화자를 선택한다. MetaGPT의 공유 메시지 풀은 발행-구독형이다. 중앙 조율자가 없고, 에이전트가 필요한 메시지만 구독한다. 이전 글에서 "슬랙 전체 채널 vs 팀별 채널"이라고 비유했던 것이, 서베이의 분류 체계에서는 "중앙집중 vs 공유 메시지 풀"이라는 정확한 좌표를 얻는다.

통신 패러다임의 차이도 새로운 관점을 제공한다. AutoGen은 협력과 토론을 동시에 지원했다. 에이전트가 코드를 실행하고 결과가 틀리면, 대화를 통해 수정을 요청한다. 이것은 협력인 동시에 토론이다 — 결과를 놓고 논쟁하며 개선한다. MetaGPT는 순수한 협력이다. Product Manager의 PRD를 Architect가 받아서 설계로 변환하는 과정에서, 논쟁이나 피드백은 없다. 산출물이 다음 단계로 흐를 뿐이다. 이전 글에서 "조립 라인"이라고 비유한 것의 정체가, 서베이의 분류에서 "단방향 협력"으로 정확히 위치 지어진다.

적응 전략에서 두 시스템이 공유하는 한계도 4축 프레임워크 위에서 더 명확해진다. 둘 다 메모리 기반 적응에 머물러 있다. 자기 진화도, 동적 생성도 없다. 서베이가 적응 전략의 세 가지 옵션을 제시한 덕분에, "경험에서 학습하지 못한다"는 이전 글의 관찰이 "자기 진화(Self-Evolution) 축이 비어 있다"는 구체적 진단으로 바뀐다.

한 가지 더. 서베이의 4축 프레임워크에는 계층적(Layered) 통신 구조가 있다. DyLAN이 제안한 다계층 피드포워드 네트워크다. 이것은 AutoGen의 중앙집중도, MetaGPT의 공유 메시지 풀도 아닌 제3의 길이다. 에이전트가 계층별로 배치되어, 인접 계층과만 소통한다. 시리즈에서 아직 다루지 않은 구조이며, 이 서베이를 통해서만 그 존재를 인식할 수 있다. 나무 두 그루만 봐서는 숲의 다른 영역을 알 수 없다.

문제를 풀거나, 세계를 짓거나 — 응용의 두 갈래

서베이는 다중 에이전트의 응용을 두 갈래로 나눈다. 문제 해결(Problem-Solving)과 세계 시뮬레이션(World Simulation)이다.

문제 해결 — 주어진 과제를 에이전트 협업으로 풀어내는 방향이다.

소프트웨어 개발이 가장 활발한 분야였다. MetaGPT, ChatDev, CAMEL이 각기 다른 접근으로 코드를 생성했다. 체화된 에이전트(Embodied Agents) 분야에서는 RoCo가 고수준과 저수준 경로 계획을 분리하여 여러 로봇의 협업을 조율했고, CoELA가 분산 제어 환경에서 복잡한 관찰과 비용 높은 통신 문제를 다뤘다. 과학 실험에서는 전략 계획, 문헌 검색, 코딩, 로봇 운영에 각각 전문화된 에이전트가 팀을 이뤘다. 과학 토론에서는 여러 LLM이 논쟁하여 사실성과 추론 정확도를 높였다.

시리즈에서 다룬 AutoGen과 MetaGPT는 모두 이 갈래에 속한다. 수학 문제, 코드 생성, 텍스트 게임 — 모두 "주어진 문제를 풀어라"는 과제다.

세계 시뮬레이션 — 에이전트 집단으로 세계를 구성하고 그 역학을 관찰하는 방향이다.

이 갈래는 문제 해결과 근본적으로 다른 야심을 품고 있다. 정답을 찾는 것이 아니라, 세계가 어떻게 작동하는지를 탐구한다.

사회 시뮬레이션이 대표적이다. Generative Agents는 25명의 가상 주민이 일상을 살아가는 마을을 시뮬레이션했다. Social Simulacra는 규모를 1,000명으로 키웠고, S³는 17,945명까지 확장했다. 에이전트 수가 늘어나면서, 개별 행동이 아닌 집단 수준의 역학 — 정보 전파, 사회적 규범 형성, 여론 변화 — 이 관찰 대상이 되었다.

게임 분야에서는 Werewolf, Avalon, Diplomacy 같은 전략 게임에서 LLM 에이전트가 추론, 협력, 기만, 설득을 수행했다. 게임 이론의 가설을 LLM 에이전트로 검증하는 실험이다. 심리학에서는 Turing Experiments가 고전적 심리학·경제학·사회학 실험을 LLM 에이전트로 복제했다. 논문이 보고한 당시 기준으로, 더 큰 모델이 인간 행동을 더 충실히 복제하되, 지식 기반 과제에서는 "초정확도 왜곡(super-accuracy distortion)" — 인간보다 너무 정확해서 오히려 인간답지 않은 — 현상이 발견되었다.

경제 시뮬레이션에서는 거시경제 활동, 금융 거래, 가상 타운이 모델링되었다. 추천 시스템에서는 Agent4Rec이 1,000명의 에이전트로 MovieLens-1M 데이터셋을 재현했다. 정책 결정에서는 수질 오염 위기와 역사적 분쟁이 시뮬레이션되었다. 질병 전파에서는 LLM 에이전트가 자가 격리와 사회적 거리두기 같은 인간 대응 행동을 정확히 모방했다.

이 두 갈래 — 문제 해결과 세계 시뮬레이션 — 의 구분이 중요한 이유는, 다중 에이전트 시스템을 설계할 때 근본적으로 다른 질문을 던지게 하기 때문이다. 문제 해결에서는 "에이전트를 어떻게 조직하면 더 좋은 답을 내는가?"가 핵심이다. 세계 시뮬레이션에서는 "에이전트를 어떻게 구성하면 더 현실적인 세계가 만들어지는가?"가 핵심이다. 같은 다중 에이전트 기술이, 목적에 따라 전혀 다른 설계 결정을 요구한다.

여섯 가지 열린 문 — 아직 풀리지 않은 도전

서베이는 여섯 가지 도전을 식별했다. 논문이 쓰인 2024년 초 시점의 진단이다.

1. 멀티모달 확장. 논문이 쓰인 당시, 대부분의 다중 에이전트 시스템은 텍스트만 처리했다. 이미지, 오디오, 비디오를 통합하는 멀티모달 에이전트는 아직 실험 단계였다. 2년이 지난 지금, GPT-4o와 Claude 3.5 이후의 멀티모달 모델이 보편화되면서, 이 도전은 상당 부분 완화되었다. 하지만 다중 에이전트 간 멀티모달 통신 — 에이전트가 이미지를 생성하고 다른 에이전트가 그것을 해석하는 — 은 여전히 활발한 연구 영역이다.

2. 환각의 연쇄 전파. 단일 에이전트의 환각도 문제지만, 다중 에이전트에서는 한 에이전트의 잘못된 정보가 네트워크를 통해 증폭된다. 전화 게임(Chinese Whispers)의 LLM 버전이다. MetaGPT가 구조화된 산출물로 이 문제를 부분적으로 완화했지만, 근본적 해결은 아니었다. 서베이는 개별 에이전트 수정을 넘어 정보 흐름 전체의 관리가 필요하다고 지적했다. 이 진단은 지금도 유효하다.

3. 집단 지능 획득. 서베이가 가장 야심적으로 제기한 도전이다. 현재 시스템은 개별 에이전트의 메모리와 자기 진화에 의존하지만, 진정한 집단 지능은 네트워크 수준에서 발현되어야 한다. 개미 군집이나 새 떼의 집단 행동처럼, 개별 에이전트의 능력 합 이상의 것이 시스템에서 창발하는 것 — 이것은 2년이 지난 지금도 대부분 미해결이다.

4. 스케일링. 에이전트 수가 증가하면 세 가지 문제가 동시에 발생한다. 계산 비용(각 에이전트가 GPT-4급 LLM을 필요로 한다), 조정 복잡성(누가 누구에게 무엇을 말하는가), 통신 효율성(메시지가 기하급수적으로 증가한다). 서베이는 에이전트 오케스트레이션(Agent Orchestration) — 에이전트 워크플로우, 과제 할당, 통신 패턴의 최적화 — 이 점점 중요해질 것이라고 예측했다. 정확한 예측이었다.

5. 평가와 벤치마크. 개별 에이전트의 능력은 HumanEval이나 MBPP 같은 벤치마크로 측정할 수 있다. 하지만 다중 에이전트 시스템의 가치는 시스템 수준의 창발적 행동에 있다. 에이전트들이 함께 일할 때 나타나는 것 — 협업의 효율성, 갈등 해결, 집단 의사결정의 질 — 을 어떻게 측정하는가? 이것은 논문이 쓰인 시점에도, 지금도, 열린 문제다.

6. 실세계 응용. 금융, 교육, 의료, 환경 과학, 도시 계획 — 서베이가 나열한 잠재적 응용 분야의 폭이 넓다. 논문이 쓰인 당시에는 대부분 학술적 실험이었지만, 2년 사이에 금융과 소프트웨어 개발 분야에서는 프로덕션 수준의 배포가 시작되었다.

여섯 가지 중 세 가지(멀티모달, 실세계 응용, 부분적으로 스케일링)는 진전이 있었고, 세 가지(환각 전파, 집단 지능, 평가)는 여전히 깊이 열려 있다. 서베이의 진단이 쓰인 지 2년이 지났지만, 열린 문 중 절반이 여전히 닫히지 않았다는 것은, 이 도전들이 단기적 기술 한계가 아니라 다중 에이전트 시스템의 근본적 난제임을 시사한다.

CoALA의 좌표계 위에 놓은 서베이

시리즈의 매 글에서 해온 것처럼, CoALA의 좌표계와 이 논문을 대조한다. 하지만 이번에는 양상이 다르다. 이전 글에서는 개별 시스템(ReAct, Toolformer, AutoGen, MetaGPT)을 CoALA의 축 위에 올려놓았다. 이번에 올려놓을 것은 시스템이 아니라 프레임워크다. 분류 체계 위에 분류 체계를 놓는 메타 작업이다.

결론부터 말하면, 두 프레임워크는 경쟁하지 않는다. 보완한다.

CoALA의 축	서베이의 대응	관계
기억	능력 획득의 적응 전략 (메모리, 자기 진화)	CoALA의 기억을 다중 에이전트 맥락으로 확장. 개별 에이전트의 기억이 어떻게 집단 수준의 적응으로 이어지는가
바깥 행동	에이전트-환경 인터페이스 (Sandbox, Physical, None)	CoALA의 바깥 행동이 일어나는 무대를 분류. 행동의 내용이 아니라 행동의 맥락을 지도화
안 행동	에이전트 프로파일링 + LLM 추론	CoALA의 안 행동을 결정하는 정체성(프로필)의 부여 방식을 분류
의사결정	에이전트 통신 (패러다임 + 구조) + 능력 획득 (피드백 유형)	CoALA의 의사결정이 개별 에이전트 내부에서 일어나는 것이라면, 서베이의 통신은 에이전트 사이에서 일어나는 집단적 의사결정

CoALA는 하나의 에이전트를 열어서 내부 구조를 보여주는 해부도다. 기억이 어떻게 쌓이는지, 행동이 어떻게 선택되는지, 판단이 어떻게 내려지는지. 이 서베이는 에이전트들이 모여 있는 외부 구조를 조감하는 지형도다. 누가 누구와 소통하는지, 어떤 무대에서 활동하는지, 집단이 어떻게 성장하는지.

비유하자면, CoALA가 세포의 내부 구조를 기술한다면, 이 서베이는 세포들이 모여 조직을 이루는 방식을 기술한다. 생물학에서 세포 생물학과 조직학이 서로 다른 수준의 분석이되 둘 다 필요하듯이, 에이전트 연구에서도 단일 에이전트의 인지 구조(CoALA)와 다중 에이전트의 상호작용 구조(이 서베이)가 함께 있어야 전체 그림이 완성된다.

한 가지 흥미로운 대칭이 있다. CoALA가 단일 에이전트 연구의 초기 혼란을 정리하기 위해 공통 좌표계를 제시한 것처럼, 이 서베이도 다중 에이전트 연구의 초기 혼란을 정리하기 위해 공통 분류 체계를 제시했다. 연구 분야가 충분히 성숙하면 정리가 필요해진다는 패턴 자체가 반복되는 것이다. 먼저 개별 연구가 폭발적으로 늘어나고, 그 다음에 누군가 뒤로 물러서서 지도를 그린다. CoALA가 단일 에이전트의 지도였고, 이 서베이가 다중 에이전트의 지도다.

마무리 — 지도의 가치

지도는 영토가 아니다. 지도를 아무리 자세히 읽어도, 산을 오른 경험을 대체하지 못한다. 하지만 지도 없이 산에 오르면, 같은 길을 두 번 걷거나 막다른 골목에서 시간을 낭비한다. 서베이의 가치는 여기에 있다.

이 논문은 LLM 기반 다중 에이전트의 첫 2년(2023~2024)을 4축 프레임워크로 정리했다. 에이전트-환경 인터페이스, 프로파일링, 통신, 능력 획득. 이 네 개의 축은 새로운 다중 에이전트 시스템을 설계할 때 체크리스트가 되고, 기존 시스템을 분석할 때 비교 기준이 된다. AutoGen과 MetaGPT를 4축 위에 올려놓았을 때 보였던 것처럼, 같은 시스템이라도 어떤 렌즈로 보느냐에 따라 다른 것이 드러난다.

2년이 지난 지금, 서베이가 그린 지도의 일부는 이미 낡았다. 멀티모달 에이전트는 당시의 예상보다 빠르게 보편화되었고, 실세계 배포도 시작되었다. 하지만 지도의 핵심 구조 — 네 개의 축, 두 갈래의 응용, 여섯 가지 도전 — 는 여전히 유효하다. 새로운 시스템이 나올 때마다 "이것은 4축에서 어디에 위치하는가?"라고 물을 수 있다.

시리즈의 흐름으로 돌아가자. CoALA가 단일 에이전트의 좌표계를 펼쳤고, CoT·ReAct·Toolformer가 그 좌표계 위에서 개별 능력을 확장했고, AutoGen과 MetaGPT가 에이전트 간 협업의 두 가지 극단을 보여주었다. 이 서베이는 그 모든 것을 한 장의 지도 위에 올려놓았다.

지도를 손에 쥐었으니, 이제 다시 구체적인 질문으로 돌아갈 준비가 되었다. MetaGPT가 남긴 질문, 서베이의 4축 프레임워크가 "자기 진화" 축에서 비어 있음을 확인해준 바로 그 질문. 에이전트가 실패했을 때, 그 실패를 되돌아보고, 스스로 전략을 수정할 수 있는가? 다음 글에서 Reflexion을 읽는다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 일곱 번째 글입니다.

Agentic AI 논문 읽기: MetaGPT — SOP로 설계한 다중 에이전트 조직

Thu, 02 Apr 2026 17:00:00 GMT

논문 정보

제목: MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework

저자: Sirui Hong, Mingchen Zhuge, Jiaqi Chen, Xiawu Zheng, Yuheng Cheng 외 다수 (DeepWisdom, KAUST, UC Berkeley, Swiss AI Lab IDSIA)

출판: ICLR 2024 (Conference Paper)

arXiv: 2308.00352

시리즈의 궤적을 되짚는다. CoALA가 좌표계를 펼쳤고, CoT가 추론을 증명했고, ReAct가 추론에 행동을 엮었고, Toolformer가 행동을 스스로 배울 수 있음을 보였다. AutoGen은 이 능력들을 가진 에이전트들이 대화를 통해 협력할 수 있음을 보여주며, 개체의 지능에서 집단의 지능으로 전환했다.

지난 글의 마지막 질문은 이것이었다. 에이전트가 자신의 실패를 되돌아보고, 그로부터 학습할 수 있는가? 중요한 질문이다. 하지만 이번 글은 그보다 한 발 앞선 질문을 던진다. 실패로부터 학습하기 전에, 애초에 실패를 구조적으로 예방할 수 있는가?

AutoGen의 비교표를 기억한다면, MetaGPT가 "정적"이라는 딱지가 붙어 있었다. 대화 패턴이 유연하지 않다는 의미였다. AutoGen이 그것을 한계로 분류한 자리에, MetaGPT는 핵심 설계 원칙을 세운다. 유연성이 아니라 절차가, 대화가 아니라 문서가, 이 시스템의 근간이라는 선언이다.

2023년 8월이다. AutoGen이 나온 시기와 거의 같다. 두 논문은 같은 문제를 바라보되, 정반대의 철학으로 답한다. AutoGen은 유연한 대화를 통해 에이전트를 풀어놓았고, MetaGPT는 엄격한 절차 안에 에이전트를 배치했다. 이 논문이 제출된 DeepWisdom 팀은 실제 소프트웨어 회사의 운영 방식을 에이전트 시스템에 이식하겠다는 야심찬 실험을 수행했다.

대화의 함정 — 다중 에이전트가 실패하는 이유

AutoGen이 보여준 다중 에이전트 대화에는 구조적 취약점이 있었다. 에이전트들이 자연어로 자유롭게 소통하면, 전화 게임(Chinese Whispers)과 같은 현상이 발생한다. 첫 번째 에이전트가 전달한 정보가 두 번째 에이전트를 거치면서 미묘하게 왜곡되고, 세 번째 에이전트에 이르면 원래 의도와 상당히 다른 해석이 만들어진다. LLM의 환각이 한 에이전트에서 다음 에이전트로 전파되며 증폭되는 것이다. 논문은 이것을 연쇄 환각(cascading hallucinations)이라 불렀다.

문제는 더 있었다. 기존 다중 에이전트 시스템에서 에이전트들은 종종 업무와 무관한 대화를 나눴다. 논문이 든 예시가 인상적이다 — Product Manager가 "안녕하세요, 잘 지내세요?"라고 인사하고, Architect가 "좋아요! 점심 드셨나요?"라고 답하는 상황. 인간 사이에서는 자연스러운 이 잡담이, LLM 에이전트 사이에서는 토큰을 낭비하고 환각의 씨앗이 된다.

비유를 바꿔보자. 다섯 명의 개발자가 슬랙 채널 하나에 모여 앉아, 별도의 문서화 없이 대화로만 소프트웨어를 만든다고 상상해보라. 초기에는 빠르게 진행될 수 있다. 하지만 프로젝트가 커지면, "그때 누가 뭐라고 했더라?"를 찾기 위해 채팅 로그를 뒤지고, 같은 결정을 두 번 내리고, 서로 다른 이해를 가진 채 코드를 작성하게 된다. 결국 시스템이 무너진다.

실제 소프트웨어 회사는 이 문제를 어떻게 해결했는가? 표준 운영 절차(SOP, Standard Operating Procedures)다. 역할을 명확히 나누고, 각 역할이 생산하는 산출물의 형식을 정의하고, 인수인계 기준을 문서화한다. MetaGPT의 핵심 통찰은 단순하다 — 인간 조직이 수십 년에 걸쳐 정제한 이 절차적 지혜를, LLM 에이전트 시스템에 그대로 이식하자.

다섯 개의 직함 — SOP로 짜인 조직

MetaGPT가 시뮬레이션하는 것은 소프트웨어 회사다. 다섯 명의 직원이 있고, 각자 명확한 직함과 책임과 산출물을 가진다.

역할	입력	산출물
Product Manager	사용자 요구사항	PRD (제품 요구사항 문서): 목표, 사용자 스토리, 경쟁 분석
Architect	PRD	시스템 설계: 파일 목록, 클래스 다이어그램, 인터페이스 정의
Project Manager	시스템 설계	과제 목록: 파일별 기능 분해, 의존관계 분석
Engineer	과제 목록 + 설계 문서	코드: 지정된 클래스와 함수 구현
QA Engineer	코드	테스트 케이스: 품질 검증, 단위 테스트

워크플로우는 순차적이다. 조립 라인(assembly line)이라는 비유가 논문 자체에 등장한다. 사용자가 요구사항을 던지면, Product Manager가 PRD를 작성하고, Architect가 그 PRD를 시스템 설계로 변환하고, Project Manager가 설계를 과제로 분해하고, Engineer가 코드를 작성하고, QA Engineer가 테스트를 수행한다. 각 단계의 출력이 다음 단계의 입력이 된다.

이전 글에서 다뤘던 AutoGen과 비교하면 차이가 선명해진다. AutoGen의 에이전트들은 대화 중에 동적으로 역할을 전환하고, GroupChatManager가 상황에 따라 다음 화자를 선택했다. 축구팀처럼 유동적이었다. MetaGPT의 에이전트들은 공장의 조립 라인처럼 자기 위치에서 자기 일만 한다. Product Manager는 절대 코드를 쓰지 않고, Engineer는 절대 PRD를 작성하지 않는다.

이것이 제약인가, 장점인가? MetaGPT의 답은 명확하다 — 장점이다. 각 에이전트가 프로필(이름, 역할, 목표, 제약)로 초기화되고, 전문 스킬만 가지고 있기 때문에, 역할 외의 일을 시도하다가 환각을 일으킬 여지가 줄어든다. 5인 스타트업에서 모두가 모든 일을 하는 것과, 50인 회사에서 각자 전문 분야에 집중하는 것의 차이다. 규모가 커질수록 후자가 이긴다.

문서가 말을 대신한다 — 구조화된 소통

MetaGPT의 가장 뚜렷한 설계 결정은 에이전트 간 소통 방식에 있다. 대화가 아니라 문서다.

기존 다중 에이전트 시스템은 자연어 메시지를 주고받는다. "요구사항이 이렇고, 이런 구조로 만들면 좋겠어"라고 Architect가 말하면, Engineer가 그 메시지를 읽고 해석한다. 해석의 여지가 있다는 것은 오류의 여지가 있다는 뜻이다.

MetaGPT에서 Architect는 말하지 않는다. 대신 시스템 설계 문서를 작성한다. 파일 목록, 클래스 다이어그램, 시퀀스 플로우, API 인터페이스 정의가 명시된 구조화된 문서다. Engineer는 이 문서를 "해석"할 필요가 없다. 정의된 인터페이스대로 구현하면 된다. 인간 소프트웨어 회사에서 구두 지시 대신 설계 문서를 쓰는 것과 같은 이유다 — 문서는 모호성을 줄인다.

정보 공유 방식도 다르다. 모든 에이전트가 모든 메시지를 받는 브로드캐스트 방식 대신, MetaGPT는 발행-구독(Publish-Subscribe) 메커니즘을 사용한다. 글로벌 메시지 풀(message pool)에 구조화된 메시지가 발행되고, 각 에이전트는 자신의 역할에 관련된 메시지만 구독한다.

Architect는 Product Manager의 PRD를 구독하지만, QA Engineer의 테스트 결과는 구독하지 않는다. Engineer는 Architect의 설계 문서와 Project Manager의 과제 목록을 구독하지만, Product Manager의 경쟁 분석은 구독하지 않는다. 필요한 정보만 받아서, 필요한 산출물만 만든다. 정보 과부하를 구조적으로 차단하는 것이다.

이 설계를 AutoGen과 대비하면 철학의 차이가 극명해진다. AutoGen의 GroupChatManager는 대화를 모든 에이전트에게 브로드캐스트했다. 유연하지만, 에이전트 수가 늘어나면 각 에이전트가 처리해야 할 정보량이 기하급수적으로 증가한다. MetaGPT의 발행-구독은 이 문제를 설계 수준에서 해결했다. 회사에서 전체 슬랙 채널 대신 팀별 채널을 쓰는 것, 모든 회의에 전 직원이 참석하는 대신 관련자만 참석하는 것과 같다.

코드가 스스로를 검증한다 — 실행 피드백 루프

SOP와 구조화된 소통이 환각을 예방하는 설계라면, 실행 가능 피드백(executable feedback)은 환각이 발생했을 때 잡아내는 안전망이다.

기존 접근법에서 코드 품질을 보장하는 방식은 두 가지였다. 코드 리뷰 — 다른 에이전트가 코드를 읽고 피드백을 준다. 자기 반성(self-reflection) — 에이전트 자신이 코드를 다시 살펴본다. 두 방법 모두 코드를 실행하지 않는다. 논리적으로 맞아 보이지만 실제로 돌아가지 않는 코드를 걸러내지 못하는 것이다.

MetaGPT의 Engineer는 코드를 작성한 후, 직접 실행한다. 실행 오류가 발생하면, 과거 실행 이력과 디버깅 메모리를 참조하여 코드를 수정한다. 필요하면 단위 테스트를 작성하고 실행하여, 테스트가 통과할 때까지 반복한다. 최대 3회의 재시도가 허용된다.

이것은 인간 개발자의 워크플로우를 충실하게 재현한 것이다. 코드를 쓰고, 빌드하고, 테스트를 돌리고, 실패하면 에러 로그를 보고 수정한다. 코드 리뷰가 "이 코드가 맞는 것 같다"는 판단이라면, 실행 피드백은 "이 코드가 실제로 동작한다"는 증명이다. CI/CD 파이프라인이 구두 코드 리뷰를 대체할 수 없듯이, 실행 피드백도 코드 리뷰를 대체하지 않는다. 둘 다 필요하다. MetaGPT는 실행 피드백을 추가함으로써, 기존 시스템이 갖지 못한 검증 계층을 하나 더 쌓은 것이다.

숫자가 말하는 것들 — 벤치마크 결과

논문이 쓰인 2023년 8월 기준으로, MetaGPT는 세 가지 벤치마크에서 평가되었다.

코드 생성 벤치마크(HumanEval, MBPP)에서 MetaGPT는 당시 모든 선행 접근법을 능가했다.

모델	HumanEval (Pass@1)	MBPP (Pass@1)
GPT-4 단독	67.0%	—
CodeX (175B)	47.0%	47.0%
MetaGPT (실행 피드백 없음)	81.7%	82.3%
MetaGPT (실행 피드백 포함)	85.9%	87.7%

실행 피드백의 효과가 수치로 드러난다. HumanEval에서 +4.2%, MBPP에서 +5.4%의 추가 개선이다. 코드를 실행해보는 것만으로 이 정도의 차이가 난다.

더 흥미로운 것은 SoftwareDev 벤치마크다. 70개의 실제 소프트웨어 개발 과제(미니 게임, 이미지 처리, 데이터 시각화)를 대상으로 한 평가에서, MetaGPT는 당시 대표적 다중 에이전트 프레임워크인 ChatDev를 거의 모든 지표에서 앞섰다.

지표	ChatDev	MetaGPT
실행 가능성 (1–4)	2.25	3.75
코드 라인 수	77.5	251.4
생산성 (토큰/코드라인, 낮을수록 효율적)	248.9	124.3
인간 수정 비용	2.5	0.83

인간 수정 비용이 2.5에서 0.83으로 떨어진 것에 주목해야 한다. MetaGPT가 생성한 코드는 인간이 고쳐야 할 부분이 ChatDev의 3분의 1 수준이라는 뜻이다. 더 많은 코드를 더 적은 토큰으로 생성하면서, 품질도 높다.

역할별 제거 실험(ablation study)은 SOP의 가치를 직접적으로 보여준다.

역할 구성	실행 가능성 (1–4)	인간 수정 비용	비용
Engineer만 (1명)	1.0	10.0	$0.915
+PM, Architect (3명)	2.5	4.0	$1.204
+Project Manager (4명)	2.0	3.5	$1.251
전체 (5명)	4.0	2.5	$1.385

Engineer 혼자일 때 실행 가능성은 1.0이고 인간 수정 비용은 10.0이다. 역할을 하나씩 추가할 때마다 비용은 소폭 증가하지만($0.915 → $1.385, 약 51% 증가), 실행 가능성은 1.0에서 4.0으로, 인간 수정 비용은 10.0에서 2.5로 극적으로 개선된다. 에이전트를 더 쓰는 비용보다, 사람이 코드를 덜 고치는 이득이 압도적으로 크다.

이 벤치마크 결과들은 당시 기준의 것이며, 이후 더 발전된 LLM과 프레임워크가 등장했다는 점을 염두에 두어야 한다. 하지만 결과가 보여주는 패턴 — 역할 분리가 품질을 높이고, 구조화된 소통이 환각을 줄이고, 실행 피드백이 정확성을 보완한다 — 은 특정 벤치마크 수치를 넘어서는 일반적 교훈이다.

아직 열리지 않은 문 — MetaGPT의 한계

MetaGPT의 설계는 인상적이지만, 논문 자체가 인정하는 한계가 있다.

첫째, 프로젝트 간 학습이 없다. 각 프로젝트가 독립적으로 실행되며, 이전 프로젝트에서 얻은 경험을 다음 프로젝트에 활용하지 않는다. 같은 유형의 과제를 반복해도 매번 처음부터 시작한다. 논문의 부록에서 이 문제를 인식하고, 에이전트가 과거 프로젝트 경험을 장기 메모리에 저장하여 제약 프롬프트를 재귀적으로 수정하는 자기 개선 메커니즘을 향후 과제로 제안했다.

둘째, SOP가 정적이다. 실제 소프트웨어 회사에서 운영 절차는 프로젝트 규모, 팀 구성, 긴급도에 따라 유동적으로 조정된다. 소규모 프로젝트에서는 Architect와 Project Manager의 역할이 합쳐지기도 하고, 긴급 버그 수정에서는 QA를 건너뛰기도 한다. MetaGPT의 SOP는 하드코딩되어 있다. 모든 과제에 동일한 5단계 파이프라인이 적용된다.

셋째, 도메인 특화다. 논문의 실험은 소프트웨어 개발에 한정되어 있다. Product Manager → Architect → Engineer라는 역할 구조가 다른 도메인 — 예를 들어 법률 문서 검토나 금융 분석 — 에도 적용 가능한지는 검증되지 않았다.

이 한계들은 AutoGen과의 대비에서 더 선명해진다. AutoGen의 유연한 대화 패턴은 다양한 도메인에 적용 가능했다 — 수학 문제, 텍스트 게임, 체스, QA까지. MetaGPT는 소프트웨어 개발이라는 특정 도메인에서 더 높은 성능을 보였지만, 그 대가로 범용성을 희생했다. 유연성과 구조 사이의 트레이드오프가 여기에 있다.

CoALA의 좌표계 위에 놓은 MetaGPT

시리즈의 매 글에서 해온 것처럼, CoALA의 좌표계 위에 MetaGPT를 올려놓는다.

축	MetaGPT의 상태
기억	SOP와 역할 정의가 절차 기억(procedural memory) 역할. 구조화된 산출물(PRD, 설계 문서, 과제 목록)이 작업 기억(working memory). 장기 기억 없음 — 프로젝트 간 경험이 축적되지 않음
바깥 행동	코드 실행 + 단위 테스트 실행을 통한 디지털 환경 상호작용. 실행 피드백 루프로 행동 결과를 검증
안 행동	역할별로 특화된 LLM 추론 + 구조화된 문서·코드 생성. 추론 트레이스가 산출물(PRD, 설계 문서)에 자연스럽게 내재
의사결정	SOP에 의해 사전 정의된 순차적 파이프라인. 동적 판단 없이 정해진 절차를 따름

AutoGen과 나란히 놓으면 두 시스템이 채운 영역의 차이가 드러난다.

축	AutoGen	MetaGPT
기억	대화 이력이 작업 기억	SOP가 절차 기억, 구조화된 문서가 작업 기억
바깥 행동	코드 실행 + 함수 호출	코드 실행 + 테스트 실행 + 실행 피드백 루프
안 행동	LLM 추론 + 자연어/코드 생성	역할 특화된 LLM 추론 + 구조화된 문서 생성
의사결정	동적 화자 선택 (GroupChatManager)	정적 순차 파이프라인 (SOP)

MetaGPT가 새롭게 채운 영역은 절차 기억이다. AutoGen에는 절차 기억에 해당하는 것이 없었다. 에이전트가 "어떤 순서로 무엇을 해야 하는지"를 대화 도중에 즉흥적으로 결정했다. MetaGPT는 이것을 SOP로 사전에 인코딩함으로써, 의사결정의 부담을 설계 시점으로 앞당겼다.

또 하나의 차이는 작업 기억의 질이다. AutoGen의 작업 기억은 자연어 대화 이력이었다. MetaGPT의 작업 기억은 PRD, 시스템 설계 문서, 인터페이스 정의 같은 구조화된 산출물이다. 같은 정보라도 구조화된 형태로 저장되면 후속 에이전트가 더 정확하게 활용할 수 있다. 슬랙 대화를 뒤지는 것과 컨플루언스 문서를 참조하는 것의 차이다.

하지만 두 시스템이 공유하는 빈칸도 있다. 장기 기억이 없고, 자기 성찰(self-reflection)이 없고, 경험에서 학습하는 메커니즘이 없다. AutoGen의 에이전트들은 대화에서 배우지 않았고, MetaGPT의 에이전트들은 프로젝트에서 배우지 않는다. 다중 에이전트 시스템의 두 가지 극단 — 유연한 대화와 엄격한 절차 — 모두 같은 빈칸 앞에 서 있다.

마무리 — 절차라는 지혜

MetaGPT의 전부를 한 문장으로 줄이면 이렇다: "인간 조직의 표준 운영 절차가, 에이전트 조직에서도 작동한다."

이것은 기술적 기여이면서 동시에 조직론적 통찰이다. 소프트웨어 공학이 수십 년에 걸쳐 발견한 것 — 역할을 나누고, 산출물을 정의하고, 인수인계 기준을 문서화하면 품질이 올라간다는 것 — 이 LLM 에이전트에게도 똑같이 적용된다. 에이전트가 인간을 모방하는 것이 아니라, 인간이 발견한 조직 원리가 에이전트에게도 유효한 것이다.

3년이 지난 지금, MetaGPT의 영향은 두 갈래로 갈라졌다. 구조화된 산출물과 역할 분리라는 설계 원칙은 후속 다중 에이전트 시스템에 널리 채택되었다. 반면 정적 SOP라는 구현 방식은 대부분 더 유연한 형태로 진화했다. 원칙은 살아남았고, 구현은 바뀌었다. 좋은 절차의 운명이 그렇다 — 절차 자체는 대체되지만, 절차가 체화한 지혜는 문화가 된다.

시리즈의 흐름을 돌아보자. CoT가 추론을 증명했고, ReAct가 행동을 엮었고, Toolformer가 행동의 자율성을 보였다. AutoGen은 유연한 대화로 다중 에이전트의 문을 열었고, MetaGPT는 엄격한 절차로 그 문 안에 질서를 세웠다. 개체의 지능에서 집단의 지능으로, 다시 집단의 조직으로 — 한 단계씩 올라가고 있다.

하지만 유연성과 구조, 두 가지 접근 모두 같은 빈칸을 남겨두었다. 에이전트가 실패했을 때, 그 실패를 되돌아보고 스스로 전략을 수정할 수 있는가? 구조가 아무리 정교해도, 대화가 아무리 유연해도, 실행 과정에서 발생하는 실패를 반성하고 학습하는 능력이 없다면 같은 유형의 실수는 반복된다. 다음 질문은 자연스럽게 이어진다 — 에이전트에게 자기 성찰의 능력을 부여할 수 있는가?

이 글은 "Agentic AI 논문 읽기" 시리즈의 여섯 번째 글입니다.

Agentic AI 논문 읽기: AutoGen — 대화로 엮는 다중 에이전트 시스템

Thu, 02 Apr 2026 13:00:00 GMT

논문 정보

제목: AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation

저자: Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li 외 다수 (Microsoft Research, Penn State University, University of Washington, Xidian University)

출판: arXiv 2308.08155 (2023.10)

이 시리즈의 첫 번째 글에서 CoALA는 좌표계를 펼쳤다. 기억, 행동, 판단이라는 세 축 위에 에이전트를 올려놓는 지도다. 두 번째 글에서 ReAct는 그 지도 위에 처음으로 에이전트를 세웠다. 생각하고, 행동하고, 관찰하는 사이클이다. 세 번째 글에서 CoT는 시간을 거슬러 올라가 원점을 찾았다 — LLM이 추론할 수 있다는 가장 근본적인 전제를 증명한 논문이다. 네 번째 글에서 Toolformer는 도구 사용법을 인간의 가르침 없이 스스로 학습할 수 있음을 보였다.

네 편의 논문이 그린 궤적은 이렇다. 생각할 수 있다(CoT), 생각하면서 행동할 수 있다(ReAct), 행동을 스스로 배울 수 있다(Toolformer). 하지만 이 모든 것은 한 명의 에이전트가 홀로 수행한 것이다. 지난 글의 마지막 문장이 던진 질문 — "이 모든 것을 하나의 시스템 안에서 어떻게 조율하는가?" — 에 이번 논문이 답한다.

2023년 10월이다. GPT-4가 공개된 지 7개월, ChatGPT 플러그인이 도입된 지 6개월이 지났다. Microsoft Research에서 하나의 전환을 제안하는 논문이 나온다. 혼자 일하는 에이전트의 시대를 넘어, 여러 에이전트가 대화를 통해 협력하는 시스템을 구축할 수 있는가? AutoGen은 이 질문에 프레임워크로 답한 논문이다.

혼자서는 부족하다 — 다중 에이전트의 직관

하나의 LLM 에이전트가 해결할 수 있는 문제의 범위는 넓다. CoT로 추론하고, ReAct로 도구를 사용하고, Toolformer의 방식으로 도구 사용법을 학습할 수 있다. 하지만 과제의 복잡성이 증가하면, 단일 에이전트는 한계에 부딪힌다.

비유하자면, 아무리 뛰어난 요리사도 혼자서 50인분의 코스 요리를 동시에 준비할 수 없다. 전채를 담당하는 사람, 메인 디시를 굽는 사람, 디저트를 만드는 사람, 전체 흐름을 조율하는 수석 셰프가 필요하다. 각자 전문 영역에서 일하되, 서로 소통하며 전체 코스를 완성한다. 이 직관을 LLM 에이전트에 적용한 것이 다중 에이전트 대화(multi-agent conversation)다.

논문은 다중 에이전트가 주는 이점을 세 가지로 정리했다. 첫째, 발산적 사고를 촉진한다. 다른 역할의 에이전트들이 같은 문제를 다른 관점에서 바라보면, 단일 에이전트가 놓치는 해법을 찾을 수 있다. 둘째, 사실성과 추론의 질을 높인다. 한 에이전트의 출력을 다른 에이전트가 검증하면, 환각이나 논리적 오류를 잡아낼 수 있다. 셋째, 역할 분담을 통해 복잡한 과제를 모듈적으로 분해할 수 있다.

그러나 다중 에이전트를 구현하려면 두 가지 근본적 질문에 답해야 한다. 개별 에이전트를 어떻게 설계해야 재사용 가능하고 커스터마이즈 가능한가? 그리고 다양한 대화 패턴 — 1:1 대화, 그룹 토론, 인간이 개입하는 대화 — 을 수용하는 통합 인터페이스를 어떻게 만들 것인가?

대화할 수 있는 에이전트 — ConversableAgent의 설계

AutoGen의 첫 번째 기여는 대화 가능한 에이전트(Conversable Agent)라는 추상화다. 에이전트는 메시지를 보내고 받을 수 있는 엔티티로, 세 가지 능력원으로 구동된다.

첫째, LLM이다. 역할 수행, 추론, 코드 생성 등 고급 언어 능력을 제공한다. 둘째, 인간(Human)이다. 에이전트 대화에 인간이 직접 참여하여 피드백을 제공하거나 판단을 내린다. 셋째, 도구(Tool)다. 코드 실행이나 함수 호출을 통해 외부 시스템과 상호작용한다.

핵심은 이 세 가지가 조합 가능하다는 점이다. 하나의 에이전트가 LLM만 사용할 수도 있고, LLM과 도구를 함께 사용할 수도 있고, 인간의 입력을 받으면서 도구를 실행할 수도 있다. 이 조합의 유연성이 ConversableAgent를 범용 빌딩 블록으로 만든다.

내장 에이전트 네 종류가 이 추상화 위에 구축된다:

에이전트	역할	능력원
ConversableAgent	최상위 추상화	LLM + 인간 + 도구 (모두 가능)
AssistantAgent	AI 어시스턴트	LLM 중심 (코드 생성, 문제 해결)
UserProxyAgent	인간 프록시	인간 입력 수집 + 코드 실행
GroupChatManager	그룹 대화 관리자	동적 화자 선택 + 응답 브로드캐스트

비유를 이어가면, ConversableAgent는 주방에서 누구든 될 수 있는 범용 요리사다. "너는 오늘 수 셰프야"라고 역할을 부여하면 AssistantAgent가 되고, "너는 손님의 피드백을 전달하는 홀 매니저야"라고 하면 UserProxyAgent가 되고, "너는 주방 전체를 조율하는 헤드 셰프야"라고 하면 GroupChatManager가 된다. 같은 기본 추상화 위에서, 구성만 바꾸면 역할이 달라진다.

이전 논문들과 비교하면 이 설계의 차별점이 선명해진다. ReAct의 에이전트는 LLM + 도구의 고정된 조합이었다. 인간 개입을 추가하려면 별도의 메커니즘이 필요했다. Toolformer의 에이전트는 LLM + 도구이되, 추론 트레이스조차 없었다. AutoGen의 ConversableAgent는 이 모든 조합을 하나의 인터페이스 안에서 구성 가능하게 만든 것이다.

특히 인간 개입의 유연성이 주목할 만하다. UserProxyAgent의 human_input_mode는 세 가지 설정을 제공한다. ALWAYS는 매 턴마다 인간에게 입력을 요청한다. TERMINATE는 종료 조건이 충족될 때만 인간에게 확인을 요청한다. NEVER는 완전 자동 모드다. Toolformer의 "학습 후 자율 실행"과 ReAct의 "인간이 프롬프트를 작성" 사이의 스펙트럼을 연속적으로 조절 가능하게 만든 것이다.

대화로 프로그래밍하다 — 계산과 제어의 융합

AutoGen의 두 번째 기여는 대화 프로그래밍(Conversation Programming)이라는 패러다임이다. 복잡한 LLM 애플리케이션 워크플로우를 다중 에이전트 대화로 단순화한다는 통찰이다.

전통적인 프로그래밍에서 계산(computation)과 제어 흐름(control flow)은 분리되어 있다. 함수가 계산을 수행하고, if/else나 for 루프가 흐름을 제어한다. AutoGen은 이 두 가지를 모두 대화로 통합한다.

계산은 대화 중심적(conversation-centric)이다. 에이전트가 대화에서 행동을 수행하고, 그 결과가 후속 대화로 이어진다. 제어 흐름은 대화 주도적(conversation-driven)이다. 어떤 에이전트에게 메시지를 보낼지, 어떤 순서로 작업할지가 대화 자체에 의해 결정된다.

이를 가능하게 하는 두 가지 설계 패턴이 있다.

첫째, 통합 인터페이스와 자동 응답이다. 모든 에이전트는 send, receive, generate_reply라는 세 가지 함수를 공유한다. 메시지를 받으면 자동으로 응답을 생성하고, 그 응답을 다시 상대에게 보내는 사이클이 반복된다. 종료 조건이 충족될 때까지 이 사이클이 이어지면서, 별도의 오케스트레이션 코드 없이도 대화가 자동으로 진행된다.

둘째, 자연어와 프로그래밍 언어의 융합이다. 에이전트의 행동은 시스템 메시지(자연어)로 프로그래밍하고, 종료 조건이나 도구 실행 같은 정밀한 제어는 Python 코드로 정의한다. 자연어와 코드 사이의 전환이 양방향으로 일어난다 — LLM이 코드를 생성하면 그것이 실행되고, 실행 결과가 다시 대화로 돌아온다.

동적 대화 패턴도 지원한다. 대화 도중 다른 에이전트를 동적으로 호출할 수 있고, GroupChatManager가 상황에 따라 다음 화자를 선택할 수 있다. 정적으로 고정된 순서가 아니라, 대화의 맥락에 따라 흐름이 결정된다.

이것을 당시 기준으로 기존 시스템과 비교하면 AutoGen의 위치가 명확해진다.

측면	AutoGen	CAMEL	BabyAGI	MetaGPT
대화 패턴	유연(동적)	정적	정적	정적
코드 실행	O	X	X	O
인간 개입	설정 가능	X	X	X

유연한 대화 패턴, 코드 실행, 설정 가능한 인간 개입을 모두 지원하는 프레임워크는 논문이 쓰인 시점에 AutoGen이 유일했다.

여섯 개의 무대 — 벤치마크와 사례

논문은 여섯 가지 애플리케이션에서 프레임워크의 효과를 입증했다. 각각이 다른 대화 패턴과 에이전트 조합을 보여주며, AutoGen의 유연성을 다각도로 검증한다.

수학 문제 해결 — 내장 에이전트 2개의 위력

가장 인상적인 결과다. AssistantAgent(문제 풀이)와 UserProxyAgent(코드 실행)라는 기본 에이전트 두 개만으로 MATH 벤치마크에서 69.48%를 달성했다. 당시 GPT-4 단독의 55.18%를 14%p 능가한 수치다.

시스템	MATH 정확도
AutoGen (2-에이전트)	69.48%
GPT-4 (단독)	55.18%
ChatGPT + Code Interpreter	45.0%

비결은 단순하다. AssistantAgent가 문제를 풀어서 Python 코드를 생성하고, UserProxyAgent가 그 코드를 실행한다. 실행 결과가 틀리면 대화가 이어지고, AssistantAgent가 코드를 수정한다. 이 사이클이 반복되면서 답에 수렴한다. 인간이 대화에 참여하는 human-in-the-loop 모드에서는 자율적으로 풀 수 없는 도전적 문제도 해결했다.

ALFWorld 텍스트 게임 — 그라운딩 에이전트의 가치

2-에이전트(어시스턴트 + 실행기)로 ReAct에 필적하는 성능을 보였지만, 반복 오류 루프에 빠지는 문제가 있었다. 에이전트가 같은 실수를 되풀이하는 것이다. AutoGen의 모듈적 설계 덕분에 그라운딩 에이전트를 추가하여 3-에이전트 시스템을 구성했다. 이 에이전트는 반복 오류 징후가 보일 때 상식 지식을 적시에 제공한다. "대상 물건을 찾아서 집어야 사용할 수 있다"는 배경 지식을 주입하여 오류 루프를 끊는 것이다. 결과는 2-에이전트 대비 15% 성능 향상이었다.

이 사례가 보여주는 교훈은 명확하다. 문제를 풀 에이전트뿐 아니라, 문제를 풀다 막혔을 때 도와줄 에이전트가 별도로 필요하다는 것이다. 인간 팀에서 멘토의 역할과 같다.

멀티에이전트 코딩 (OptiGuide) — 코드 축소와 안전성

공급망 최적화 코드 작성을 위해 Commander(지시), Writer(코드 작성), Safeguard(안전 검증)의 3-에이전트 구조를 설계했다. 핵심 워크플로우 코드가 430줄에서 100줄로 축소됐다 — 4배 이상의 절감이다. 더 중요한 것은 Safeguard 에이전트가 안전하지 않은 코드를 식별하는 F-1 점수를 GPT-4에서 8%, GPT-3.5에서 35% 향상시켰다는 것이다. 코드를 쓰는 에이전트와 코드를 검증하는 에이전트를 분리한 것만으로 안전성이 올라간 결과다.

검색 증강 QA — 대화형 검색

검색 증강 에이전트 2개로 Natural Questions에서 F1 66.65%를 달성했다. 핵심 혁신은 대화형 검색(interactive retrieval)이다. 관련 정보를 찾지 못하면 "UPDATE CONTEXT"라는 메시지로 자동 재검색을 수행한다. 한 번의 검색으로 끝나는 것이 아니라, 대화를 통해 검색을 반복하는 것이다. Toolformer가 도구를 한 번만 호출할 수 있었던 한계와 대비된다.

동적 그룹 채팅과 대화형 체스

GroupChatManager가 역할 기반으로 화자를 동적 선택하여 정적 순서 대비 높은 성공률을 보였다. 대화형 체스에서는 플레이어 에이전트와 보드 에이전트의 분리가 불법 수를 방지하여 게임 완결성을 보장했다. 보드 에이전트 없이는 불법 수가 발생하여 게임이 중단되는 것과 대조적이다.

아직 답하지 못한 질문들 — AutoGen의 한계

논문은 네 가지 열린 문제를 솔직하게 밝혔다.

첫째, 최적 워크플로우 설계의 부재다. 에이전트를 몇 개 써야 하는지, 각 에이전트에 어떤 역할을 부여해야 하는지, 어떤 대화 패턴이 최적인지에 대한 가이드라인이 없다. MATH 벤치마크에서 2개의 에이전트가 최적이었지만, ALFWorld에서는 3개가 더 좋았다. 과제마다 다르다면, 이 선택을 어떻게 체계화할 것인가?

둘째, 스케일링과 안전성이다. 에이전트 수가 늘어나면 대화의 복잡도가 기하급수적으로 증가한다. 어떤 에이전트가 어떤 판단을 내렸는지 추적하기 어려워지고, 연쇄 실패의 위험이 커진다.

셋째, 자율성의 위험이다. 완전 자율 모드(human_input_mode='NEVER')에서 에이전트들이 서로 대화하며 행동하면, 의도치 않은 방향으로 전개될 수 있다. 보상 해킹이나 통제 이탈의 가능성이 열려 있다. 논문 자체가 ALWAYS 모드로 시작하여 점진적으로 자동화하라고 권고한 이유다.

넷째, LLM 추론 최적화다. 프롬프트 설계, 온도 설정, 응답 캐싱 등 튜닝해야 할 매개변수가 많고, 에이전트 수만큼 이 복잡성이 곱해진다.

3년이 지난 지금 시점에서 되짚어보면, 이 한계들 중 일부는 해소되었고 일부는 더 첨예해졌다. 최적 워크플로우 설계는 여전히 열린 문제다. 에이전트 수와 역할의 최적 조합을 자동으로 찾는 메타 학습은 아직 실용 수준에 이르지 못했다. 반면 안전성과 자율성 문제는 에이전트 시스템이 프로덕션에 배포되면서 현실적 긴급성을 얻었다. AutoGen이 이론적으로 제기한 "연쇄 실패"와 "통제 이탈"은 이제 엔지니어링 문제가 되었다.

CoALA의 좌표계 위에 놓은 AutoGen

시리즈의 매 글에서 해온 것처럼, CoALA의 좌표계 위에 AutoGen을 올려놓는다.

축	AutoGen의 상태
기억	대화 이력이 작업 기억 역할. 장기 기억 없음. 에이전트 간 대화 자체가 공유 기억
바깥 행동	코드 실행 + 함수 호출을 통한 도구 사용. UserProxyAgent가 디지털 환경과 상호작용
안 행동	LLM 기반 추론 + 자연어/코드 생성. 명시적 추론 트레이스는 에이전트 설계에 따라 선택적
의사결정	자동 응답 메커니즘 + 동적 화자 선택. GroupChatManager가 다자간 의사결정 조율

이전 논문들과 비교하면 AutoGen이 새롭게 채운 영역이 드러난다.

CoT는 안 행동(내부 추론)만 있었다. ReAct는 안 행동과 바깥 행동을 엮었다. Toolformer는 바깥 행동을 자율적으로 학습했다. 세 편 모두 단일 에이전트의 능력을 확장한 논문이다. AutoGen이 추가한 것은 에이전트 간 관계(inter-agent relationship)라는 새로운 차원이다.

CoALA의 좌표계가 개별 에이전트의 인지 구조를 기술한다면, AutoGen은 그 에이전트들이 어떻게 조직되는가를 기술한다. 기억, 행동, 판단의 각 축이 에이전트 내부에서 작동하는 것에 더해, 에이전트 사이의 대화를 통해서도 작동한다. 한 에이전트의 출력이 다른 에이전트의 작업 기억이 되고, 한 에이전트의 행동 결과가 다른 에이전트의 판단 입력이 된다.

하지만 한계도 있다. AutoGen은 에이전트 간 대화가 주는 구조적 이점을 입증했지만, 각 에이전트의 인지 구조 자체는 단순하다. 장기 기억이 없고, 자기 성찰(self-reflection)이 없고, 경험에서 학습하는 메커니즘이 없다. 대화를 통해 에이전트 수준에서의 한계를 보완하지만, 개별 에이전트의 지능은 CoT나 ReAct 수준에 머문다.

마무리 — 대화라는 프로토콜

AutoGen의 전부를 한 문장으로 줄이면 이렇다: "에이전트 사이의 대화가 곧 프로그래밍이다."

이것은 기술적 제안이면서 동시에 철학적 전환이다. 전통적 소프트웨어에서 모듈 간 소통은 함수 호출, API, 메시지 큐 등 엄격하게 정의된 인터페이스를 통해 이루어졌다. AutoGen은 자연어 대화를 모듈 간 인터페이스로 승격시켰다. 에이전트가 서로에게 "이 코드를 실행해봐"라고 말하고, "결과가 틀렸으니 다시 해봐"라고 피드백하고, "이번에는 맞았어, 다음 단계로 가자"라고 진행하는 것 — 이것이 프로그래밍이라는 주장이다.

3년이 지난 지금, AutoGen의 영향은 프레임워크 자체보다 더 넓은 범위에서 확인된다. CrewAI, LangGraph, Microsoft의 AutoGen 후속 버전 등 다중 에이전트 프레임워크가 봇물처럼 쏟아졌고, 대부분이 AutoGen이 제시한 두 가지 핵심 — 대화 가능한 에이전트 추상화와 대화 기반 워크플로우 — 을 변주한 것이다. "에이전트들이 대화한다"는 직관은 이제 업계의 기본 가정이 되었다.

시리즈의 흐름을 되짚어보자. CoT가 추론을 증명했고, ReAct가 추론에 행동을 엮었고, Toolformer는 행동을 스스로 배울 수 있음을 보였다. AutoGen은 이 능력들을 가진 에이전트들이 대화를 통해 협력할 수 있음을 보였다. 개체의 지능에서 집단의 지능으로 — 규모의 전환이다.

하지만 AutoGen이 보여준 다중 에이전트 시스템에는 아직 빠진 조각이 있다. 에이전트들이 대화하지만, 대화에서 배우지는 않는다. 같은 실수를 반복하고, 경험을 축적하지 않고, 자신의 한계를 인식하지 못한다. 다음 질문은 자연스럽게 이어진다. 에이전트가 자신의 실패를 되돌아보고, 그로부터 학습할 수 있는가?

이 글은 "Agentic AI 논문 읽기" 시리즈의 다섯 번째 글입니다.

Agentic AI 논문 읽기: Toolformer — 언어 모델이 스스로 도구를 잡은 순간

Thu, 02 Apr 2026 09:00:00 GMT

논문 정보

제목: Toolformer: Language Models Can Teach Themselves to Use Tools

저자: Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom (Meta AI Research, Universitat Pompeu Fabra)

출판: NeurIPS 2023

arXiv: 2302.04761

이 시리즈의 첫 번째 글에서 CoALA는 좌표계를 펼쳤다. 기억, 행동, 판단이라는 세 축 위에 에이전트를 올려놓는 지도다. 두 번째 글에서 ReAct는 그 지도 위에 처음으로 에이전트를 세웠다. 생각한 다음 행동하고, 결과를 보고 다시 생각하는 패턴이다. 세 번째 글에서 CoT는 시간을 거슬러 올라가 원점을 찾았다. LLM이 추론할 수 있다는 것 — 에이전트가 성립하기 위한 가장 근본적인 전제를 증명한 논문이었다.

네 번째 글에서는 다른 질문을 던진다. ReAct에서 에이전트는 위키피디아 API를 호출했다. 검색하고, 페이지를 탐색하고, 답을 제출했다. 하지만 그 능력이 어디서 왔는지 되짚어보면, 인간이 몇 개의 시연 궤적을 직접 작성해서 프롬프트에 넣어준 것이었다. "이 상황에서는 이 도구를 이렇게 쓴다"는 예시를 인간이 보여주니, 모델이 그 패턴을 따라 한 것이다. CoT도 마찬가지다. 풀이 과정이 담긴 예시를 인간이 프롬프트에 넣어줬다. 두 논문 모두, 도구 사용의 "무엇을"과 "어떻게를" 인간이 가르쳤다.

2023년 2월이다. ChatGPT가 출시된 지 3개월, GPT-4가 공개되기 한 달 전이다. Meta AI Research에서 하나의 질문에 답하는 논문이 나온다. 모델이 도구 사용법을 스스로 알아낼 수 있는가? 인간의 시연 없이, 어떤 도구를 언제 쓸지, 어떤 입력을 넣을지, 그 결과를 어떻게 활용할지를 자기 지도 학습만으로 배울 수 있는가? Toolformer는 이 질문에 "예"라고 답한 논문이다.

몸이 없는 지성 — 도구가 필요한 이유

LLM은 역설적인 존재다. 변호사 시험을 통과하고 시를 쓸 수 있지만, 7 × 8을 실수하고, 어제 무슨 일이 있었는지 모르고, 지금이 몇 월인지 알지 못한다. 지성은 있지만 몸이 없다. 파라미터에 압축된 세계 모델 안에 갇혀 있어서, 세계와 접촉하는 채널이 없다.

논문은 이 한계를 네 가지로 정리했다. 첫째, 최신 정보에 접근할 수 없어 사실을 환각한다. 학습 데이터의 마감일 이후의 세계는 존재하지 않는다. 둘째, 정밀한 수학 계산이 안 된다. "1,247 × 83"을 파라미터 연산으로 풀어야 하니 틀리는 것이 당연하다. 셋째, 저자원 언어를 잘 이해하지 못한다. 영어 중심으로 학습된 모델에게 스와힐리어 문서는 안개 속이다. 넷째, 시간의 흐름을 인식하지 못한다. "다음 주 목요일"이 언제인지 계산하려면 오늘이 며칠인지 알아야 하는데, 모델에게 "오늘"은 존재하지 않는다.

이 한계들에는 공통점이 있다. 모두 외부 도구가 있으면 즉시 해결된다는 것이다. 검색 엔진이 있으면 최신 정보를 가져올 수 있고, 계산기가 있으면 산술 오류가 사라지고, 번역기가 있으면 다국어를 처리할 수 있고, 달력이 있으면 시간을 인식할 수 있다. 문제는 도구의 부재가 아니라, 도구를 연결하는 방법이었다.

기존 접근법은 두 갈래였다. 하나는 대량의 인간 주석에 의존하는 방식이다. 어떤 상황에서 어떤 도구를 호출해야 하는지를 사람이 일일이 레이블링하고, 그 데이터로 모델을 훈련시킨다. 효과적이지만 확장하기 어렵다. 새로운 도구가 추가될 때마다 새로운 주석이 필요하다. 다른 하나는 도구 사용을 특정 과제에만 한정하는 방식이다. "수학 문제를 풀 때는 계산기를 쓰라"고 하드코딩하는 식이다. 이러면 모델의 범용성이 사라진다.

Toolformer는 이 두 가지를 모두 피하겠다고 선언한다. 인간 주석 없이 학습하고, 특정 과제에 묶이지 않고, 모델의 핵심 언어 능력을 훼손하지 않으면서 도구를 사용하겠다는 것이다.

스스로 가르치는 법 — 3단계 파이프라인

Toolformer의 핵심 아이디어를 한 문장으로 요약하면 이렇다. 도구를 호출했을 때 미래 토큰을 더 잘 예측할 수 있다면, 그 도구 호출은 유용한 것이다.

이 직관을 알고리즘으로 구현하는 과정이 3단계 파이프라인이다.

Step 1: API 호출 샘플링

대규모 텍스트 데이터셋의 각 문장에서, 모델에게 "여기에 API를 호출하고 싶은 충동이 드느냐?"고 묻는다. 구체적으로는, 각 위치에서 특수 토큰 <API>가 생성될 확률을 계산한다. 그 확률이 임계값 이상인 위치에서, 모델이 스스로 API 호출 후보를 생성한다. 어떤 API를 호출할지, 어떤 입력을 넣을지를 모델 자신이 결정한다. 필요한 것은 각 API의 사용법을 보여주는 소수의 예시뿐이다.

예를 들어, "The population of Tokyo is approximately 14 million"이라는 문장에서 "approximately" 앞의 위치에 높은 확률이 매겨지고, 모델이 [QA("population of Tokyo")]라는 API 호출을 생성하는 식이다.

Step 2: API 호출 실행

생성된 모든 API 호출을 실제로 실행한다. QA 시스템에 질문을 보내고, 계산기에 수식을 입력하고, 위키피디아에서 검색 결과를 받아온다. 이 단계는 단순하다 — 후보 호출을 모아서 배치로 실행하면 된다.

Step 3: API 호출 필터링

여기가 Toolformer의 핵심이다. 생성된 수백만 개의 API 호출 중 실제로 유용한 것만 골라내야 한다. 필터링 기준은 가중 교차 엔트로피 손실의 차이다.

두 가지 상황을 비교한다. L⁺는 API 호출과 그 결과가 텍스트에 삽입됐을 때의 손실 — 즉, API 결과를 본 상태에서 미래 토큰을 예측하는 난이도다. L⁻는 API가 없을 때의 손실 — 아무 도움 없이 미래 토큰을 예측하는 난이도다. 그 차이 L⁻ - L⁺가 임계값 τ_f 이상이면, 이 API 호출은 미래 토큰 예측을 실질적으로 도왔다는 뜻이다. 이 호출만 남기고 나머지는 버린다.

이 기준의 우아함은 인간의 판단이 전혀 개입하지 않는다는 데 있다. "이 상황에서 계산기를 쓰는 것이 적절한가?"를 사람이 판단하는 것이 아니라, "계산기를 썼더니 모델이 다음에 올 단어를 더 잘 맞추게 됐는가?"를 자동으로 측정한다. 언어 모델링이라는 모델의 본업을 잣대로 삼아, 도구의 유용성을 자기 지도적으로 판별하는 것이다.

비유하자면, 계산기가 도움이 되는 순간을 스스로 발견하는 학생과 같다. 선생님이 "여기서 계산기를 써라"고 알려주는 것이 아니라, 학생이 여러 문제에서 계산기를 시험 삼아 써보고, 실제로 답을 더 잘 맞힌 경우만 기억에 남기는 것이다.

파인튜닝: 필터링을 통과한 API 호출을 원본 텍스트에 삽입하여 증강 데이터셋을 만들고, 이 데이터로 모델을 파인튜닝한다. 결정적으로, 증강 데이터셋은 API 호출을 제외하면 원본과 정확히 같은 텍스트를 포함한다. 원래 학습할 내용에 API 호출이 자연스럽게 끼워진 형태이므로, 핵심 언어 모델링 능력이 보존된다.

추론: 파인튜닝이 끝나면, 모델은 텍스트를 생성하다가 스스로 <API> 토큰을 출력한다. 이 시점에서 디코딩을 잠시 멈추고, 해당 API를 실제로 호출하여 결과를 받아온 뒤, 그 결과를 텍스트에 삽입하고 다시 생성을 이어간다. 모델이 "여기서 도구를 써야겠다"고 스스로 판단하고, 실행하고, 결과를 통합하는 전체 흐름이 자동으로 작동한다.

다섯 개의 손가락 — Toolformer의 도구들

Toolformer가 도구에 부과하는 제약은 두 가지뿐이다. 입력과 출력이 텍스트 시퀀스로 표현 가능해야 하고, 사용 시연을 소수 확보할 수 있어야 한다. 이 조건을 충족하는 다섯 가지 도구를 탐구한다.

도구	입력	출력	보완하는 LLM 한계
QA 시스템 (Atlas)	자연어 질문	사실적 답변	지식의 한계, 환각
계산기	수식 (+, -, *, /)	계산 결과	산술 능력 부족
위키피디아 검색	검색어	위키 발췌문	최신 정보 부재
기계 번역 (NLLB)	외국어 텍스트	영어 번역	저자원 언어 이해
캘린더	(없음)	현재 날짜	시간 인식 부재

다섯 개의 도구가 다섯 개의 손가락과 같다. 각각은 특화되어 있지만, 함께 작동하면 모델의 손이 닿는 범위를 극적으로 넓힌다. QA 시스템은 모델이 "모르는 것"을 보완하고, 계산기는 "못 하는 것"을 보완하고, 위키피디아 검색은 "오래된 것"을 보완하고, 번역기는 "읽지 못하는 것"을 보완하고, 캘린더는 "인식하지 못하는 것"을 보완한다.

흥미로운 점은 QA 시스템과 위키피디아 검색의 역할 분화다. 둘 다 사실 정보를 가져오지만, QA 시스템은 정확한 답을 반환하고, 위키피디아 검색은 더 넓은 맥락을 반환한다. "도쿄의 인구가 몇 명인가?"에는 QA가, "도쿄에 대해 더 알고 싶다"에는 위키피디아가 적합하다. 모델은 이 미묘한 차이를 스스로 학습한다.

작은 모델이 거인을 넘다 — 벤치마크 결과

Toolformer는 GPT-J(6.7B 파라미터)를 기반으로 한다. 당시 기준으로도 대형 모델이 아니었다. GPT-3는 175B, OPT는 66B — Toolformer보다 10배에서 26배 큰 모델들이 비교 대상이다. 결과는 충격적이었다.

사실 완성 (LAMA)

벤치마크	GPT-J (6.7B)	Toolformer (6.7B)	OPT (66B)	GPT-3 (175B)
SQuAD	17.8	33.8	24.3	26.8
Google-RE	4.9	11.5	4.0	7.0
T-REx	31.9	53.5	33.2	39.8

6.7B 모델이 자신보다 26배 큰 GPT-3를 모든 항목에서 능가했다. 98.1%의 예시에서 QA 도구를 자율적으로 호출했다. 모델이 "이 문장의 사실적 정확성을 확인해야 한다"고 스스로 판단한 것이다.

수학 벤치마크

벤치마크	GPT-J (6.7B)	Toolformer (6.7B)	OPT (66B)	GPT-3 (175B)
ASDiv	10.0	40.4	11.2	14.0
SVAMP	5.2	29.4	7.2	10.0
MAWPS	9.9	44.0	12.0	19.8

여기서의 격차는 더 극적이다. Toolformer는 GPT-3보다 수학 문제에서 2~3배 높은 정확도를 보인다. 97.9%의 예시에서 계산기를 호출했다. 산술 능력이 본질적으로 부족한 언어 모델에게, 외부 계산기라는 의수를 달아준 효과다.

이 결과가 의미하는 바는 명확하다. 규모만이 능력의 경로가 아니다. 175B 파라미터를 쌓아서 산술을 조금 더 잘하게 만드는 대신, 6.7B 모델에 계산기를 쥐어주면 문제가 해결된다. 크기의 게임이 아니라 증강의 게임이다.

스케일링 법칙: 도구를 잡을 수 있는 최소 크기

논문은 GPT-2 패밀리(124M~1.6B)와 GPT-J(6.7B)에 Toolformer를 적용하여, 도구 사용 능력이 어느 규모에서 출현하는지를 측정했다. 결과는 약 775M 파라미터에서 도구 사용 능력이 나타나기 시작한다는 것이다. 그 아래에서는 도구를 사용해도 성능이 나아지지 않는다.

이것을 세 번째 글에서 다룬 CoT의 스케일링 법칙과 비교하면 흥미롭다. CoT는 약 100B(1000억) 파라미터 이상에서야 추론 능력이 출현했다. Toolformer의 도구 사용 능력은 그 문턱의 130분의 1 지점에서 나타난다. 같은 문제 — 예를 들어 산술 — 를 해결하는 데 두 가지 경로가 있는 셈이다. 하나는 모델을 충분히 크게 키워서 내부적으로 추론하게 하는 것(CoT의 경로), 다른 하나는 작은 모델에게 도구를 쥐어주는 것(Toolformer의 경로)이다.

언어 모델링 성능 보존

마지막으로 결정적인 검증이 있다. 도구 사용 학습이 모델의 핵심 능력을 훼손하지 않았는가? WikiText와 CCNet에서 퍼플렉시티를 측정한 결과, API 호출이 증강된 데이터로 파인튜닝한 후에도 퍼플렉시티가 증가하지 않았다. 이것이 가능한 이유는, 증강 데이터셋이 API 호출을 제외하면 원본 데이터셋과 정확히 같은 텍스트를 포함하기 때문이다. 모델은 원래 배울 것을 그대로 배우면서, 추가로 도구를 사용하는 법을 익힌 것이다.

아직 열리지 않은 문 — Toolformer의 한계

논문은 효과를 보고하는 데 그치지 않고, 다섯 가지 한계를 정직하게 밝힌다.

첫째, 도구 체이닝이 불가능하다. 한 도구의 출력을 다른 도구의 입력으로 넘길 수 없다. "도쿄의 인구를 검색한 뒤, 그 숫자를 계산기에 넣어 서울 인구와 비교하라"는 흐름이 불가능하다. 각 API 호출이 텍스트 내 독립된 위치에서 독립적으로 샘플링되기 때문이다.

둘째, 상호작용이 불가능하다. 검색 결과가 부적절할 때 쿼리를 수정하거나, 여러 결과를 탐색하는 루프가 없다. 한 번 호출하고, 그 결과를 받아들이는 것이 전부다.

셋째, 입력의 문구에 민감하다. 같은 내용이라도 표현이 바뀌면 API 호출 여부가 달라질 수 있다.

넷째, 비용을 고려하지 않는다. 모든 API 호출을 동등하게 취급한다. 현실에서 검색 API는 비싸고 캘린더 API는 싸다. 이 차이를 호출 결정에 반영하는 메커니즘이 없다.

다섯째, 샘플 효율이 낮다. 100만 개 이상의 문서를 처리하여 수천 개의 유용한 API 호출만을 건져내는 과정은 계산 비용이 크다.

이 한계들을 두 번째 글에서 다룬 ReAct와 나란히 놓으면, 두 논문의 강점과 약점이 정확히 상보적임이 드러난다. ReAct는 사고-행동-관찰 사이클을 반복하므로 도구 체이닝과 상호작용이 자연스럽다. 검색 결과가 부적절하면 "이건 내가 원한 게 아니다, 다른 검색어를 시도해보자"라고 생각하고 다시 행동한다. 하지만 ReAct의 도구 사용 능력은 인간이 작성한 몇 개의 시연 궤적에 의존한다.

반대로 Toolformer는 도구 사용법을 자기 지도적으로 학습하지만, 한 번의 호출로 끝난다. 추론 트레이스도 없고, 결과를 보고 전략을 수정하는 루프도 없다. ReAct가 "행동 사이에 생각할 시간을 주는" 에이전트라면, Toolformer는 "생각 없이 도구를 쓰는, 그러나 언제 쓸지를 스스로 아는" 모델이다. 둘 다 도구를 사용하지만, 도구를 사용하는 방식이 근본적으로 다르다.

CoALA의 좌표계 위에 놓은 Toolformer

이 시리즈의 매 글에서 해온 것처럼, CoALA의 좌표계 위에 Toolformer를 올려놓는다.

축	Toolformer의 상태
기억	절차 기억에 도구 사용 패턴 학습 (파인튜닝). 일화·의미 기억 없음
바깥 행동	디지털 환경 (5개 API: QA, 계산기, 위키, 번역, 캘린더)
안 행동	텍스트 생성 중 암묵적 추론. 명시적 추론 트레이스 없음
의사결정	API 호출 여부를 자율적으로 결정. 단일 호출, 평가/선택 없음

CoT, ReAct와 비교하면 Toolformer가 채운 빈칸이 선명하게 드러난다.

CoT는 모든 칸이 거의 비어 있었다. 추론만 있었고, 외부 행동도, 장기 기억도, 평가도 없었다. ReAct는 바깥 행동(위키피디아 API)과 명시적 추론 트레이스를 추가했지만, 장기 기억은 여전히 없었고, 도구 사용 능력은 인간이 작성한 프롬프트 예시에서 왔다 — 명시적 절차 기억이되, 인간이 직접 쓴 것이다.

Toolformer가 새롭게 채운 셀은 학습된 절차 기억이다. CoALA가 정의한 절차 기억의 두 층 — 암묵적(LLM 가중치)과 명시적(에이전트 코드) — 에서, Toolformer는 파인튜닝을 통해 암묵적 절차 기억에 도구 사용 패턴을 새겨 넣었다. 인간이 코드로 "이때 계산기를 호출하라"고 명시하지 않아도, 모델의 가중치가 "여기서 계산기를 호출하면 도움이 된다"를 내재화한 것이다. 이것은 CoT(절차 기억 변화 없음)에도, ReAct(인간이 명시적으로 주입한 절차 기억)에도 없던 속성이다.

하지만 대가도 있다. ReAct에는 있던 명시적 추론 트레이스가 Toolformer에는 없다. ReAct의 에이전트는 "이 결과가 부적절하니 다시 검색해야겠다"고 사고를 드러내며, 인간이 이 추론을 읽고 두 줄을 고치면 실패가 성공으로 전환됐다. Toolformer는 조용히 도구를 쓴다. 왜 여기서 도구를 썼는지, 결과가 맞는지를 설명하지 않는다. 디버깅과 인간 정렬(alignment)의 측면에서, Toolformer는 ReAct보다 후퇴한 셈이다.

마무리 — 도구를 잡는다는 것의 의미

Toolformer의 전부를 한 문장으로 줄이면 이렇다: "어떤 도구를 언제 쓸지, 모델 스스로 알아내게 하라."

생물학에서 도구 사용은 종종 진화적 전환점으로 거론된다. 침팬지도 나뭇가지로 개미를 낚지만, 상황에 따라 다른 도구를 선택하고, 새로운 도구의 용도를 발견하는 것은 인간 고유의 능력으로 여겨져 왔다. Toolformer는 LLM에서 이 전환의 초기 형태를 보여준다. 모델이 "여기서 계산기를 쓰면 된다"를 가르침 없이 발견하는 것 — 도구를 받아 쓰는 것과 도구를 선택하는 것 사이의 차이다.

3년이 지난 지금, Toolformer가 제안한 기법 자체는 대체되었다. 오늘날의 Claude, GPT-4, Gemini는 네이티브 함수 호출(function calling)을 지원한다. 별도의 파인튜닝 없이, 모델이 수백 개의 도구 중에서 적절한 것을 골라 호출한다. 이 능력은 훈련 과정 자체에 내장되어 있다. 하지만 그 훈련의 근저에 흐르는 원리 — 모델이 스스로 도구의 유용성을 판단하고, 언제 어떤 도구를 써야 하는지를 자율적으로 결정한다는 것 — 는 Toolformer가 처음 입증한 것이다.

시리즈의 흐름을 되짚어보자. CoT가 추론을 증명했고, ReAct가 추론에 행동을 엮었고, Toolformer는 모델이 행동을 스스로 학습할 수 있음을 보였다. 세 편의 논문이 그린 궤적은 이렇다 — 생각할 수 있다, 생각하면서 행동할 수 있다, 행동을 스스로 배울 수 있다. 다음 질문은 자연스럽게 이어진다. 이 모든 것을 하나의 시스템 안에서 어떻게 조율하는가?

기법은 대체되지만, 좋은 원리는 표준이 된다. Toolformer는 기법에서 출발해, 표준이 되었다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 네 번째 글입니다.

Agentic AI 논문 읽기: CoT — 생각의 사슬이 추론을 깨운 순간

Wed, 01 Apr 2026 17:00:00 GMT

논문 정보

제목: Chain-of-Thought Prompting Elicits Reasoning in Large Language Models

저자: Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, Denny Zhou (Google Research, Brain Team)

출판: NeurIPS 2022

arXiv: 2201.11903

이 시리즈에서 첫 번째 글은 지도를 펼쳤다. CoALA가 제시한 기억, 행동, 판단의 세 축이라는 좌표계다. 두 번째 글은 그 지도 위에 처음으로 에이전트를 올려놓았다. ReAct가 보여준 "생각한 다음 행동하고, 결과를 보고 다시 생각한다"는 패턴이다. 세 번째 글에서는 시간을 거슬러 올라간다. ReAct가 확장한 그 추론 — LLM이 중간 단계를 밟으며 답에 도달하는 능력 — 은 어디서 시작됐는가?

2022년 1월이다. ChatGPT는 아직 11개월 뒤의 일이고, GPT-3가 대규모 언어 모델의 전선이다. 이 시점에 LLM은 놀라운 언어 능력을 보여주고 있었지만, 한 가지 분명한 한계가 있었다. 추론을 못 한다는 것이다. 다단계 산술 문제를 주면 틀리고, 상식적 판단이 필요한 질문에서 헤매고, 기호를 조작하는 과제에서 무너졌다. 모델을 키우면 나아지리라 기대했지만, 스케일링만으로는 추론 과제의 정확도가 좀처럼 오르지 않았다.

Google Research의 Jason Wei 등은 이 벽에 놀랍도록 단순한 방법으로 구멍을 냈다. 프롬프트에 "풀이 과정"을 함께 보여주는 것이다. 이 논문이 제안한 사고의 연쇄 프롬프팅(Chain-of-Thought prompting, CoT)은 지금으로부터 4년 전에 발표되었지만, 그 핵심 원리 — "생각의 과정을 펼쳐 보이면 더 잘 추론한다" — 는 오늘날 모든 AI 시스템의 기본 전제가 되었다. 이 글에서는 그 발견이 어떻게 이루어졌고, 무엇을 밝혔으며, 4년이 지난 지금 어떤 위치에 있는지를 살펴본다.

"답만 말하지 말고, 풀이 과정을 보여줘"

CoT의 아이디어는 한 문장으로 요약된다. 퓨샷 프롬프트의 예시에 중간 추론 단계를 포함시킨다.

이전의 퓨샷 프롬프팅은 이런 형태였다. 질문과 답만 보여준다.

Q: Roger has 5 tennis balls. He buys 2 more cans of tennis balls.
   Each can has 3 tennis balls. How many tennis balls does he have now?
A: The answer is 11.

CoT 프롬프팅은 질문과 답 사이에 풀이 과정을 끼워 넣는다.

Q: Roger has 5 tennis balls. He buys 2 more cans of tennis balls.
   Each can has 3 tennis balls. How many tennis balls does he have now?
A: Roger started with 5 balls. 2 cans of 3 tennis balls each is
   6 tennis balls. 5 + 6 = 11. The answer is 11.

차이는 "5 + 6 = 11"이라는 중간 단계를 명시적으로 보여주느냐의 여부뿐이다. 이 예시 몇 개를 프롬프트에 넣으면, 모델이 그 형식을 따라 자기도 중간 단계를 펼치며 답에 도달한다. 파인튜닝도, 보상 함수도, 추가 학습 데이터도 필요 없다. 기존 모델에 프롬프트만 바꿔서 넣으면 된다.

논문은 이 접근법이 네 가지 매력적인 속성을 가진다고 정리했다.

첫째, 다단계 문제를 중간 단계로 분해한다. 한 번에 풀기 어려운 문제를 각각은 풀 수 있는 작은 단계로 나눈다. 더 어려운 문제에는 자연스럽게 더 많은 추론 단계가 할당된다.

둘째, 해석 가능한 창(window)을 제공한다. 모델이 어떤 경로로 답에 도달했는지 볼 수 있으니, 어디서 틀렸는지 진단할 수 있다. 블랙박스가 아닌, 들여다볼 수 있는 추론이다.

셋째, 범용적으로 적용 가능하다. 수학만이 아니라, 상식 추론, 기호 조작, 인간이 언어로 풀이할 수 있는 모든 과제에 원칙적으로 적용할 수 있다.

넷째, 사용이 간편하다. 기존의 대규모 언어 모델에 프롬프트 예시 몇 개만 수정하면 바로 적용 가능하다. 별도의 모델 학습이나 아키텍처 변경이 필요 없다.

GSM8K의 도약 — 숫자로 읽는 추론의 탄생

논문은 세 가지 영역에서 CoT를 검증했다. 산술 추론 5개, 상식 추론 5개, 기호적 추론 2개 — 총 12개 벤치마크다. 결과는 놀라웠다.

가장 극적인 변화는 GSM8K에서 일어났다. GSM8K(Grade School Math 8K)는 OpenAI가 2021년에 공개한 벤치마크로, 초등학교 수준의 수학 문제 8,500개를 모아놓은 데이터셋이다. "가게에 사과가 23개 있었다. 점심에 20개를 팔고 6개를 더 들여왔다면 몇 개인가?" 같은 문제다. 인간에게는 쉽지만, 2~8단계의 산술 연산을 순서대로 수행해야 하기 때문에 LLM에게는 난관이었다. 논문이 쓰인 시점의 최고 기록은 파인튜닝된 GPT-3에 검증기(verifier)까지 붙인 시스템이 달성한 55%였다. 대규모 학습 데이터와 전용 모델이 필요한 접근이었다.

PaLM 540B에 CoT 프롬프팅을 적용한 결과는 이랬다.

벤치마크	표준 프롬프팅	CoT 프롬프팅	당시 SOTA
GSM8K (다단계 산술)	17.9%	56.9%	55% (파인튜닝 GPT-3+검증기)
SVAMP (산술 변형)	기존 수준	SOTA 달성	-
MAWPS (기본 산술)	기존 수준	SOTA 달성	-

8개의 수작업 예시만으로, 대규모 학습 데이터로 파인튜닝한 전용 시스템을 넘어섰다. 17.9%에서 56.9%로 — 세 배 이상의 도약이다.

산술만이 아니었다. 상식 추론에서도 변화가 뚜렷했다. StrategyQA에서 PaLM 540B는 75.6%를 달성하여 이전 최고 기록 69.4%를 넘었다. Sports Understanding에서는 95.4%로, 비전문가 인간의 정확도 84%를 웃돌았다. 기호적 추론에서는 Last Letter Concatenation과 Coin Flip 과제에서 거의 100% 정확도에 도달했다.

여기서 주목할 패턴이 하나 있다. CoT의 효과는 문제가 어려울수록 커졌다. GSM8K처럼 여러 단계가 필요한 문제에서는 성능이 세 배 이상 올랐지만, 한 단계로 풀리는 쉬운 문제에서는 거의 개선이 없었다. CoT가 단순히 "답을 더 잘 맞히는" 기법이 아니라, 다단계 추론이라는 특정 능력을 활성화하는 메커니즘임을 시사하는 결과다.

100억 개의 파라미터가 넘어야 하는 벽

논문의 가장 의미심장한 발견은 성능 수치가 아니라, 그 수치가 나타나는 조건에 있었다.

CoT 프롬프팅은 모든 모델에서 효과가 있지 않았다. 약 100B(1000억) 파라미터 미만의 모델에서는 CoT가 성능을 개선하지 못했고, 오히려 표준 프롬프팅보다 성능이 떨어지는 경우도 있었다. 작은 모델은 문법적으로 유창하지만 논리적으로는 엉터리인 사고의 연쇄를 생성했다. "Roger는 5개의 공을 가지고 있다. 2캔을 더 샀다. 각 캔에 3개가 있다. 그러므로 답은 9이다."처럼 — 문장은 자연스럽지만 계산이 틀리는 식이다.

100B를 넘어서면 양상이 달라진다. 사고의 연쇄가 논리적으로 올바르게 전개되기 시작하고, 성능이 극적으로 올라간다. 논문은 이것을 모델 규모의 창발적 능력(emergent ability)이라 불렀다. 양을 늘리면 어느 순간 질이 바뀌는 현상이다.

이 발견이 중요한 이유는, 추론이 "더 많은 데이터로 학습시키면 점진적으로 나아지는" 종류의 능력이 아님을 보여줬기 때문이다. 일정 규모 아래에서는 전혀 나타나지 않다가, 문턱을 넘으면 갑자기 출현한다. 마치 물이 99도까지는 액체이다가 100도에서 끓기 시작하는 것처럼 — 임계점이 존재한다.

2022년 당시, 이 임계점은 PaLM 540B, GPT-3 175B 같은 최대 규모 모델에서만 도달 가능했다. 실험실 안의 몇 개 모델만이 "추론"할 수 있었다는 뜻이다. 이것은 CoT를 발견인 동시에 한계로 만들었다 — 일반 연구자나 기업이 접근할 수 있는 모델에서는 쓸 수 없는 기법이었다. 오늘날에는 지시어 튜닝과 추론 특화 훈련 같은 기법들이 이 문턱을 크게 낮췄지만, "추론은 규모에서 창발한다"는 원리 자체는 여전히 유효하다.

자연어가 핵심이다 — 제거 실험이 밝힌 것들

CoT가 효과가 있다는 것은 알겠는데, 왜 효과가 있는가? 논문은 이 질문에 답하기 위해 정교한 제거 실험(ablation study)을 설계했다. 세 가지 대안을 시험하여, CoT의 어떤 측면이 핵심인지를 분리해냈다.

첫 번째 실험: 자연어 대신 수학 수식만 출력하게 했다. 풀이 과정을 자연어 문장이 아닌 방정식으로만 표현하도록 프롬프트를 구성한 것이다. 결과는 GSM8K에서 효과가 미미했다. 자연어가 사라지니 성능도 사라졌다. 논문은 이것을 GSM8K 수준의 문제가 가진 의미적 복잡성 — 문장 속에 숨겨진 관계와 조건을 파악하는 것 — 이 수식만으로는 포착되지 않기 때문이라 분석했다.

두 번째 실험: "더 많은 토큰을 생성하니까 더 많이 생각하는 것 아닌가?"라는 직관을 검증했다. CoT가 중간 단계를 서술하면서 더 많은 토큰을 생성하므로, 그 추가 계산 시간(토큰 수) 자체가 핵심일 수 있다는 가설이다. 이를 분리하기 위해, 사고의 연쇄와 같은 길이의 점(...)만 출력하도록 했다. 결과는 표준 프롬프팅과 동일한 성능이었다. 더 많은 토큰을 생성하는 것 자체는 아무 효과가 없었다. 핵심은 토큰의 양이 아니라 내용이었다.

세 번째 실험: 사고의 연쇄를 답 뒤에 배치했다. "CoT가 사전 훈련 중 획득한 관련 지식에 더 잘 접근하도록 돕는 것일 수 있다"는 가설이다. 만약 그렇다면, 사고의 연쇄가 답 앞에 있든 뒤에 있든 관련 지식을 활성화하는 효과는 같아야 한다. 결과는 역시 기준선과 동일했다. 답을 내기 전에 단계를 밟아가며 추론하는 순서 자체가 핵심임이 확인됐다. 지식 활성화가 아니라 순차적 추론이 CoT의 효과를 만들어낸다.

이 세 실험을 종합하면 결론은 명확하다. CoT의 효과는 추가 계산 시간에서 오는 것이 아니고, 관련 지식의 활성화에서 오는 것도 아니고, 자연어로 중간 추론 단계를 순차적으로 전개하는 것 자체에서 온다. 언어가 추론의 매체(medium)로 기능한다는 발견이다.

논문은 견고성도 검증했다. 세 명의 독립된 주석자가 각자의 스타일로 사고의 연쇄를 작성했을 때, 그리고 의도적으로 간결한 문체로 작성했을 때에도 모두 표준 프롬프팅을 큰 폭으로 능가했다. 특정한 문체나 형식에 의존하지 않는다는 뜻이다. 중요한 것은 표현의 스타일이 아니라 추론의 구조다.

안락의자 위의 철학자 — CoT의 한계

논문은 효과를 보고하는 데 그치지 않고, 실패를 정직하게 분석했다. LaMDA 137B가 GSM8K에서 생성한 사고의 연쇄를 수동으로 검토한 결과는 흥미로웠다.

정답을 낸 50개 샘플 중 48개에서 사고의 연쇄가 논리적으로, 수학적으로 올바랐다. 나머지 2개는 추론에 오류가 있었지만 우연히 정답에 도달한 경우였다. 즉, 정답의 96%는 올바른 추론의 결과였다.

오답을 낸 50개 샘플에서는 46%가 사소한 실수였다 — 계산기 오류(8 × 4 = 24라고 쓰는 식), 기호 매핑 실수, 추론 단계 하나를 빠뜨리는 것. 사고의 흐름은 올바르지만 세부 실행에서 미끄러진 경우다. 나머지 54%는 문제의 의미를 잘못 이해하거나 추론의 일관성이 무너진 주요 오류였다.

이 분석이 드러내는 CoT의 근본적 한계는, 모델이 자기 머릿속에만 갇혀 있다는 것이다. 외부 세계를 확인하지 않고, 파라미터에 저장된 내부 지식만으로 사고를 전개한다. 그 지식이 맞으면 추론이 정확하지만, 틀리면 거짓된 전제 위에 그럴듯한 논리를 쌓아 올린다. 이 시리즈의 두 번째 글에서 다룬 ReAct 논문이 정확히 이 지점에서 출발했다. "안락의자에서 내려와 세상과 부딪혀야 한다" — 추론과 행동을 엮어야 한다는 것이 ReAct의 핵심 문제의식이었고, 그 문제의식의 출발점이 바로 CoT의 이 한계였다.

논문 자체도 한계를 인정했다. 첫째, LLM이 정말로 "추론"하는 것인지, 훈련 데이터에서 본 유사한 패턴을 재현하는 것인지는 미해결 질문이다. 둘째, 올바른 추론 경로의 보장이 없다 — CoT는 맞는 답에도, 틀린 답에도 이를 수 있다. 셋째, 100B 이상 모델에서만 작동하므로 당시 기준으로 실서비스 비용이 높았다.

한계에서 태어난 것들 — CoT 이후의 진화

이 한계들 각각에서 후속 연구가 태어났다. CoT-SC(Self-Consistency)는 같은 문제에 대해 여러 사고의 연쇄를 독립적으로 생성하고 다수결로 답을 고르는 방식으로 신뢰성을 높였다. Zero-shot CoT는 "Let's think step by step"이라는 한 줄만으로 예시 없이도 사고의 연쇄를 유도할 수 있음을 보였다. Tree of Thoughts는 하나의 선형적 사슬이 아닌 여러 갈래의 추론 경로를 탐색하고 평가하는 구조를 제안했다. 그리고 ReAct는 추론 사이에 외부 행동을 끼워 넣어 사실 확인의 루프를 만들었다.

가장 극적인 진화는 추론 모델(reasoning model)의 등장이다. OpenAI의 o1, o3 같은 모델은 CoT를 프롬프팅 기법이 아닌 훈련 과정 자체에 내재화했다. 사용자가 "풀이 과정을 보여줘"라고 요청하지 않아도, 모델이 내부적으로 긴 추론 사슬을 생성한 뒤 최종 답을 출력한다. CoT는 프롬프트에서 시작해, 모델의 본성이 되었다.

CoALA의 좌표계 위에 놓은 CoT

이 시리즈의 첫 글에서 소개한 CoALA의 좌표계 위에 CoT를 놓으면, 그 위치가 선명하게 드러난다.

축	CoT의 상태
기억	작업 기억(프롬프트 컨텍스트)만. 장기 기억 없음
바깥 행동	없음. 최종 답 출력이 전부
안 행동	추론만. 검색도, 학습도 없음
의사결정	제안만. 단일 사슬, 평가도 선택도 없음

ReAct보다도 빈칸이 많다. ReAct는 최소한 외부 행동(위키피디아 API 검색)이 있었다. CoT에는 그것조차 없다. 에이전트라고 부르기도 어렵다 — 엄밀히 말하면 CoT는 에이전트가 아니라 추론 기법이다. 환경과 상호작용하지 않고, 프롬프트라는 작업 기억 안에서 시작하고 끝난다.

하지만 CoT가 증명한 것은 가장 근본적인 것이었다. LLM이 추론할 수 있다는 것. 문제를 단계로 분해하고, 각 단계를 논리적으로 연결하여, 올바른 답에 도달할 수 있다는 것. CoALA가 정의한 "추론 = 작업 기억의 읽기/쓰기"의 가장 순수한 구현이 바로 CoT다. 프롬프트(작업 기억)를 읽고, 중간 단계를 기록하고(쓰기), 그 위에서 다음 단계를 전개하는(읽기) 과정의 반복이다.

진화의 경로는 이렇다. CoT가 추론을 증명했고, ReAct가 추론에 행동을 엮었고, Tree of Thoughts가 추론에 평가를 더했고, Reflexion이 추론에 반성을 붙였다. CoALA가 좌표계이고 ReAct가 그 위에 놓인 첫 번째 에이전트라면, CoT는 원점이다. 모든 것이 시작된 (0, 0) 좌표.

마무리 — 시작점의 무게

CoT의 전부를 한 문장으로 줄이면 이렇다. "답만 말하지 말고, 풀이 과정을 보여줘."

이 한 문장이 바꾼 것은 LLM에 대한 근본 전제다. CoT 이전에 LLM은 뛰어난 패턴매칭 엔진이었다. 입력에 가장 그럴듯한 출력을 매핑하는 시스템이다. CoT 이후에 LLM은 잠재적 추론자가 되었다. 중간 단계를 밟으며 새로운 답에 도달할 수 있는 시스템이다. 이 전제의 전환이 없었다면, 추론과 행동을 엮겠다는 ReAct의 발상도, 에이전트를 인지 아키텍처로 분류하겠다는 CoALA의 시도도 성립하지 않았을 것이다.

4년이 지난 지금, "풀이 과정을 보여줘"는 더 이상 프롬프트에 적는 지시가 아니다. 모델 훈련 과정에 흡수되었고, 추론 모델이라는 새로운 카테고리를 만들었으며, 에이전트가 사고하는 방식의 기본 문법이 되었다. 기법은 대체되지만, 좋은 발견은 전제가 된다. CoT는 기법에서 출발해, 전제가 되었다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 세 번째 글입니다.

Agentic AI 논문 읽기: ReAct — 생각과 행동을 엮은 최초의 패턴

Wed, 01 Apr 2026 13:00:00 GMT

논문 정보

제목: ReAct: Synergizing Reasoning and Acting in Language Models

저자: Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao (Princeton University, Google Research Brain team)

출판: ICLR 2023

arXiv: 2210.03629

지난 글에서 다룬 CoALA는 에이전트를 분류하는 좌표계였다. 기억, 행동, 판단이라는 세 축. 그 좌표계 위에서 CoALA가 "가장 단순하지만 추론과 행동의 시너지를 처음 입증한 사례"로 꼽은 에이전트가 ReAct다.

ReAct 논문이 나온 시점은 2022년 10월이다. GPT-3.5가 아직 등장하기 전, PaLM-540B가 대규모 언어 모델의 전선이던 때다. 지금으로부터 약 3년 6개월 전의 일이다. 그사이 모델의 규모와 능력은 비약적으로 변했지만, 이 논문이 제안한 하나의 패턴 — "생각한 다음 행동하고, 결과를 보고 다시 생각한다" — 은 오늘날 거의 모든 AI 에이전트의 기본 호흡법이 되었다.

이 글에서는 그 패턴이 어떤 문제의식에서 출발했고, 어떻게 작동하며, 3년이 지난 지금 무엇이 달라졌는지를 살펴본다.

혼자 생각하는 LLM, 혼자 행동하는 LLM

ReAct 이전에, LLM 연구에는 두 갈래의 흐름이 있었다. 하나는 추론, 다른 하나는 행동이다. 문제는, 이 두 갈래가 서로 만나지 않고 있었다는 점이다.

첫 번째 흐름은 사고의 연쇄(Chain-of-Thought, CoT) 프롬프팅이다. 원리는 단순하다. 질문과 답만 보여주는 대신, 풀이 과정을 함께 보여주는 예시 몇 개를 프롬프트에 넣는다. 그러면 LLM이 그 형식을 따라, 자기도 중간 단계를 펼쳐 보이며 답에 도달한다. Wei 등이 2022년 초에 발표한 이 기법은, "LLM도 추론할 수 있다"는 가능성을 처음으로 대규모로 입증했다. 산술 문제, 상식 추론, 기호 조작에서 효과가 극적이었고, 이후 수많은 후속 연구를 낳았다. 하지만 치명적인 약점이 있었다. LLM이 자기 머릿속에만 갇혀서 추론한다는 것이다. 외부 세계를 확인하지 않고, 내부 지식만으로 사고를 전개한다. 그 지식이 맞으면 다행이지만, 틀리면 거짓된 전제 위에 그럴듯한 논리를 쌓아 올린다. 이것이 환각(hallucination)이다. 논문의 분석에 따르면, CoT의 실패 사례 중 56%가 이 환각에서 비롯됐다. 안락의자에 앉아 세상을 추론하는 철학자와 비슷하다 — 논리는 정교하지만, 사실과 부딪혀보지 않는다.

두 번째 흐름은 행동 생성이다. LLM을 대화형 환경에 배치하고, API를 호출하거나 게임에서 동작을 수행하게 하는 연구다. WebGPT처럼 검색을 수행하거나, 텍스트 게임에서 방을 이동하고 물건을 집는 식이다. 하지만 이 방식에도 문제가 있었다. 모델이 행동만 하고, 왜 그 행동을 하는지 추론하지 않았다. 고수준 목표를 하위 과제로 분해하지 못하고, 지금까지 무엇을 했는지 추적하지 못했다. 레시피를 따라 요리하지만, 지금 무엇을 만들고 있는지는 모르는 요리사와 같았다.

논문은 인간의 요리 과정을 비유로 든다. 우리는 야채를 썰다가 혼잣말을 한다 — "재료가 다 준비됐으니 이제 물을 끓이자." 소금이 없으면 "간장으로 대체하자"라고 생각을 바꾼다. 반죽 만드는 법이 기억나지 않으면 인터넷을 검색한다. 생각과 행동이 자연스럽게 교차한다. 이 교차가 없으면, 머릿속으로만 요리 계획을 세우다 재료가 없는 걸 모르거나(CoT), 레시피를 보지도 않고 무작정 냄비부터 올리게 된다(Act).

행동 공간을 확장하라 — ReAct의 핵심 아이디어

ReAct의 아이디어는 놀랍도록 단순하다.

에이전트의 행동 공간(Action Space)을 확장한다. 원래 에이전트가 할 수 있는 행동의 집합을 A라 하면, ReAct는 여기에 언어 공간 L을 합친다.

Â = A ∪ L

A에 속하는 행동은 환경에 영향을 미친다 — 검색을 실행하고, 물건을 집고, 답을 제출한다. L에 속하는 행동은 환경에 아무 영향도 주지 않는다. 대신 에이전트의 컨텍스트를 갱신한다. 이것을 사고(Thought) 또는 추론 트레이스(Reasoning Trace)라 부른다. 환경은 사고에 반응하지 않지만, 에이전트 자신은 사고를 통해 다음에 무엇을 할지 더 나은 판단을 내릴 수 있다.

이로써 사고-행동-관찰(Thought-Action-Observation)의 반복 사이클이 만들어진다. 위키피디아 기반 질의응답(HotpotQA)에서 이 사이클이 어떻게 작동하는지 보자.

질문이 이렇다고 하자: "Milhouse라는 이름은 어떤 미국 대통령에서 따왔는가?"

Thought 1: Milhouse의 이름이 미국 대통령에서 유래했다고 하니, 먼저 Milhouse Van Houten을 검색해서 이름의 유래를 확인해야겠다.

Action 1: search[Milhouse Van Houten]

Observation 1: Milhouse Mussolini Van Houten은 심슨 가족의 등장인물로... 그의 이름은 Richard Nixon 대통령에서 따왔다.

Thought 2: Milhouse의 이름이 Richard Nixon에서 유래했다는 정보를 얻었다. Nixon의 중간 이름이 Milhous인지 확인해야 한다.

Action 2: search[Richard Nixon]

Observation 2: Richard Milhous Nixon은 미국의 제37대 대통령으로...

Thought 3: Richard Nixon의 중간 이름이 Milhous이다. 질문의 답이 확인됐다.

Action 3: finish[Richard Nixon]

핵심은 사고가 수행하는 역할의 다양성이다. 논문은 다섯 가지를 식별했다:

목표 분해: 큰 질문을 하위 단계로 나눈다 (Thought 1)
정보 추출: 관찰에서 필요한 부분만 골라낸다 (Thought 2)
진행 추적: 지금까지 무엇을 알아냈는지 정리한다
예외 처리: 검색 결과가 기대와 다르면 계획을 수정한다
상식 주입: "이 물건은 보통 서랍에 있다" 같은 배경 지식을 끌어온다

CoT가 처음부터 끝까지 하나의 독백을 펼치는 것이라면, ReAct는 환경과의 대화 속에서 생각을 조각조각 끼워넣는 것이다. 독백과 대화의 차이 — 이것이 ReAct와 CoT의 본질적 차이다.

네 개의 시험대 — 지식 추론과 의사결정

논문은 네 개의 벤치마크에서 ReAct를 검증했다. 두 개는 지식 추론, 두 개는 의사결정 과제다. 기반 모델은 PaLM-540B이며, 모든 실험은 퓨샷(few-shot) 프롬프팅으로 이루어졌다.

지식 추론 과제: HotpotQA와 FEVER

두 과제 모두 위키피디아 API 세 가지를 행동 공간으로 사용했다: search[entity](검색), lookup[string](페이지 내 탐색), finish[answer](답 제출).

방법	HotpotQA (EM)	FEVER (정확도)
Standard (프롬프트만)	28.7	57.1
CoT (추론만)	29.4	56.3
Act (행동만)	25.7	58.9
ReAct	27.4	60.9
CoT-SC → ReAct	34.2	64.6
ReAct → CoT-SC	35.1	62.0

단독 성능만 보면 ReAct가 CoT를 압도하지는 않는다. HotpotQA에서는 오히려 CoT보다 낮다. 하지만 수치 이면의 이야기가 중요하다.

논문이 성공과 실패 사례를 분석한 결과, CoT의 성공 사례 중 14%가 환각된 사실에 기반한 허위 양성이었다. 맞는 답을 냈지만, 근거가 거짓이었다. ReAct는 이 비율이 6%에 불과했다. 더 놀라운 것은 실패 분석이다. CoT가 실패한 사례의 56%가 환각에서 비롯된 반면, ReAct의 환각 비율은 0%였다. 외부 검색으로 사실을 확인하는 구조가 환각을 근본적으로 차단한 것이다. ReAct의 실패는 검색이 유용한 결과를 가져오지 못한 경우(23%)와 추론 자체의 오류(47%)에서 왔다.

여기서 결과 표의 CoT-SC를 잠시 설명해야 한다. CoT-SC(Self-Consistency)는 CoT의 확장판이다. 같은 질문에 대해 CoT 추론을 여러 번 독립적으로 샘플링한 뒤, 다수결로 최종 답을 고른다. 올바른 추론은 경로가 달라도 같은 답에 수렴하고, 잘못된 추론은 제각각 다른 답에 흩어진다는 직관에 기반한다. 한 번의 추론이 실수할 수 있어도, 여러 번 독립적으로 시도하면 정답이 다수를 차지할 가능성이 높다. 단독 CoT보다 일관되게 높은 성능을 보여, 당시 추론 과제의 강력한 기준선이었다.

하지만 CoT-SC에도 한계가 있다. 환각이 체계적일 때 — 즉 모델이 같은 거짓 사실을 반복적으로 생성할 때 — 다수결도 틀린 답에 수렴한다. 여러 경로로 추론해도 출발점이 같은 거짓 위에 있으면 도착지도 같다.

이 분석에서 논문의 가장 실용적인 통찰이 나온다 — 두 방법의 전환 전략이다. ReAct는 외부 검색으로 사실을 확인하니 환각에 강하지만, 검색이 실패하면 답을 내지 못한다. CoT-SC는 내부 지식만으로도 답을 내지만, 그 지식이 틀리면 다수결조차 무력하다. 둘의 약점이 정확히 상보적이다. 그래서 논문은 ReAct가 정해진 단계 안에 답을 내지 못하면 CoT-SC로 전환하고, 반대로 CoT-SC의 다수결 확신도가 낮으면 ReAct로 전환하는 전략을 제안했다. 이 결합이 HotpotQA에서 35.1, FEVER에서 64.6으로 각각 단독 최고 성능을 달성했다.

의사결정 과제: ALFWorld와 WebShop

ALFWorld는 텍스트 기반 가정 환경 시뮬레이터다. "책상 위 스탠드를 켜라" 같은 목표를 받고, 방을 이동하고 물건을 조작하며 50단계 이상에 걸쳐 과제를 완수해야 한다.

방법	ALFWorld 성공률
BUTLER (모방학습)	37%
Act (행동만)	45%
ReAct	71%

결과가 극적이다. ReAct의 최악의 시도(48%)조차 Act의 최고 시도(45%)를 넘었다. 정성적 분석에서 원인이 드러난다. Act는 목표를 하위 과제로 분해하지 못하고, 지금까지의 진행 상황을 추적하지 못한다. 서랍을 열었는데 원하는 물건이 없으면, 다시 같은 서랍을 열거나 목적 없이 돌아다닌다. ReAct는 사고를 통해 "스탠드는 보통 책상 위에 있다. 아직 열어보지 않은 서랍을 확인하자"라고 계획을 조정한다.

WebShop은 118만 개의 실제 상품이 있는 온라인 쇼핑 환경이다. 여기서도 ReAct(40.0%)가 Act(30.1%)와 모방학습+강화학습(28.7%)을 모두 넘었다. 수많은 상품 정보 속에서, 사고를 통해 "이 상품은 가격은 맞지만 색상이 다르다"처럼 관찰을 정제하는 능력이 결정적이었다.

생각 두 줄을 고치면 실패가 성공이 된다

논문의 부록에 주목할 만한 실험이 있다. Human-in-the-Loop — 인간이 에이전트의 추론에 개입하는 실험이다.

ALFWorld에서 ReAct가 실패한 과제들을 분석하니, 대부분 에이전트의 사고가 환각하는 지점에서 문제가 시작됐다. 예를 들어, 싱크대 앞에 있으면서 "냉장고를 확인해야겠다"고 잘못 생각하는 식이다. 연구자들이 이 환각된 사고 두 줄만 올바른 내용으로 고쳤더니, 실패하던 과제가 성공으로 전환됐다.

이 발견의 의미는 크다. 만약 사고 없이 행동만 하는 에이전트였다면, 잘못된 행동의 원인을 파악하기 어렵고, 수십 개의 행동을 처음부터 다시 입력해야 했을 것이다. 추론 트레이스가 있으니 문제의 지점이 눈에 보이고, 고칠 곳도 명확하다. 행동 수십 줄 대신 생각 두 줄을 고치는 것 — 이 효율 차이가 ReAct의 실용적 가치를 압축적으로 보여준다.

추론 트레이스는 모델을 위한 장치인 동시에, 인간을 위한 인터페이스이기도 하다. 에이전트가 왜 그런 행동을 했는지 읽을 수 있고, 어디서 잘못됐는지 진단할 수 있고, 최소한의 개입으로 궤적을 바로잡을 수 있다. 논문은 이것을 "인간 정렬(human alignment)"이라 불렀다.

3년 뒤의 풍경 — ReAct가 남긴 것과 달라진 것

2022년 10월에 프롬프팅 기법 하나로 출발한 아이디어가, 3년 6개월이 지난 지금 어떤 위치에 있는지 돌아보자.

실현된 것: 사고-행동-관찰 사이클의 보편화

ReAct가 제안한 Thought-Action-Observation 사이클은 오늘날 사실상 모든 에이전트 프레임워크의 기본 구조가 되었다.

LangChain의 AgentExecutor는 이 사이클을 프레임워크 수준에서 구현했고, 이름 자체가 ReAct 패턴에서 유래했다. AutoGPT는 "생각 → 행동 → 관찰 → 반성"의 루프를 반복한다. Claude의 도구 사용(tool use)도 내부적으로 같은 흐름을 따른다 — 추론으로 어떤 도구를 호출할지 판단하고, 호출 결과를 관찰한 뒤 다시 추론한다. OpenAI의 Assistants API, Cursor의 코딩 에이전트, Devin — 표면적 형태는 다르지만, 근저에 흐르는 패턴은 동일하다.

논문이 "추론과 행동의 교차가 더 그라운딩되고 신뢰할 수 있는 에이전트를 만든다"고 주장한 것은, 3년간의 실전에서 압도적으로 확인됐다.

진화한 것: 기법에서 아키텍처로

달라진 것도 많다.

ReAct는 퓨샷 프롬프팅에 의존했다. 사람이 몇 개의 예시 궤적을 손으로 작성하고, 이를 프롬프트에 넣어 모델이 패턴을 따르게 했다. 오늘날의 에이전트는 명시적 예시 없이도 도구를 사용한다. 명령어 튜닝(instruction tuning)과 네이티브 함수 호출(function calling) 기능이 모델에 내장되었기 때문이다. ReAct의 패턴은 프롬프트가 아니라 모델의 훈련 과정 자체에 흡수됐다.

행동 공간도 비교가 안 된다. 논문이 쓰인 시점에 ReAct가 쓴 행동은 위키피디아 API 세 가지뿐이었다. 오늘날 에이전트는 파일 시스템, 브라우저, 코드 실행 샌드박스, 수십 개의 외부 API를 넘나든다. MCP(Model Context Protocol) 같은 표준이 등장하면서, 도구의 연결 방식 자체가 규격화되고 있다.

단일 루프의 한계도 넘어섰다. ReAct는 하나의 에이전트가 하나의 사고-행동 루프를 실행했다. 지금은 여러 에이전트가 병렬로, 또는 계층적으로 각자의 루프를 돌린다. 하나가 계획을 세우면 다른 하나가 실행하고, 또 다른 하나가 검증한다. ReAct의 단일 루프는 멀티 에이전트 시스템의 기본 단위가 되었다.

여전히 열린 것: ReAct가 남긴 숙제들

논문이 보고한 실패 패턴 중 하나 — 에이전트가 같은 생각과 행동을 반복하며 루프에 빠지는 현상 — 는 2026년에도 여전히 실전에서 관찰된다. 에이전트가 막다른 길에서 벗어나지 못하고 같은 도구를 반복 호출하는 것은, 현재 에이전트 시스템에서 가장 흔한 장애 유형 중 하나다.

추론의 깊이와 행동의 속도 사이의 균형도 열린 문제다. 언제 더 깊이 생각해야 하고, 언제 바로 행동해야 하는가? ReAct는 이 판단을 모델에 맡겼고, 그 한계는 여전히 넘어서지 못했다.

환각된 도구 호출이라는 새로운 변종도 등장했다. ReAct가 위키피디아 검색에서 환각을 0%로 줄인 것은 사실이지만, 오늘날처럼 수십 개의 도구가 열려 있는 환경에서는 존재하지 않는 도구를 호출하거나, 잘못된 파라미터를 넣는 형태의 환각이 새로운 문제가 됐다.

CoALA의 좌표계 위에 놓은 ReAct

지난 글에서 "빈칸이 보이면, 그것이 곧 개선의 방향이 된다"고 했다. CoALA의 세 축 위에 ReAct를 놓으면, 빈칸이 선명하게 드러난다.

축	ReAct의 상태
기억	장기 기억 없음. 작업 기억(프롬프트 컨텍스트)만 사용
바깥 행동	디지털 환경 (위키피디아 API 3개)
안 행동	추론만. 검색도, 학습도 없음
의사결정	제안만. 평가도, 선택도 없음

장기 기억이 없다. 경험에서 배우지 못한다. 도구가 세 개뿐이다. 후보를 비교하지 않고 떠오르는 첫 번째 행동을 바로 실행한다. CoALA의 기준으로 보면, ReAct는 빈 서랍장으로 싸운 에이전트다.

그런데도 이겼다. 모방학습과 강화학습으로 훈련된 에이전트를 퓨샷 프롬프팅만으로 넘어섰다. 이것이 시사하는 바는 명확하다 — 추론과 행동을 엮는 패턴 자체에 강력한 힘이 있다는 것이다. 인프라가 아닌 구조의 승리다.

그리고 그 빈칸들은 후속 연구가 채워나갔다. Voyager는 절차 기억을 추가했고, Generative Agents는 일화 기억과 의미 기억을 추가했고, Tree of Thoughts는 평가와 선택을 추가했다. ReAct가 그린 최소한의 골격 위에, 에이전트 연구의 3년이 살을 붙여온 셈이다.

마무리 — 단순한 아이디어의 무게

ReAct의 전부를 한 문장으로 줄이면 이렇다: "행동 사이에 생각할 시간을 줘라."

복잡한 아키텍처도, 대규모 학습 데이터도, 강화학습 보상 함수도 없다. 에이전트가 할 수 있는 행동에 "자연어로 생각하기"를 하나 추가한 것이 전부다. 그 하나가 환각을 차단하고, 목표를 분해하고, 인간이 개입할 수 있는 창구를 열었다.

논문이 쓰인 2022년에 GPT-3가 최전선이었다. 지금은 모델의 규모와 능력이 당시와는 차원이 다르다. 하지만 패턴은 살아남았다. 기법은 대체되지만, 좋은 구조는 내재화되기 때문이다. ReAct는 프롬프팅 기법에서 시작해, 에이전트의 호흡법이 되었다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 두 번째 글입니다.

Agentic AI 논문 읽기: CoALA — 언어 에이전트를 위한 인지 아키텍처

Wed, 01 Apr 2026 09:00:00 GMT

논문 정보

제목: Cognitive Architectures for Language Agents

저자: Theodore R. Sumers, Shunyu Yao, Karthik Narasimhan, Thomas L. Griffiths (Princeton University)

출판: Transactions on Machine Learning Research (2024.02)

arXiv: 2309.02427

이 논문이 쓰인 2023년은, GPT-4가 변호사 시험을 통과하고 LLM 기반 에이전트라는 개념이 막 폭발적으로 퍼지기 시작한 시기였다. 당시의 LLM은 탁월한 언어 능력을 갖췄지만, 혼자서는 기억하지 못하고, 계획하지 못하고, 행동하지 못했다. 뛰어난 두뇌를 가졌지만 몸도 기억도 습관도 없는 존재와 같았다. 이 간극을 메우려는 시도가 바로 언어 에이전트(Language Agent)였다.

그런데 문제가 있었다. 각 연구가 "도구 사용", "그라운딩", "행동" 같은 용어를 제각각 다른 의미로 쓰고 있었고, 비슷한 에이전트를 비교하거나 발전 방향을 잡기가 어려웠다.

CoALA는 이 혼란을 정리하기 위해 등장한 개념적 프레임워크다. 인지과학과 전통 AI 연구의 수십 년 역사를 빌려와, 흩어진 에이전트 연구들을 기억, 행동, 판단이라는 세 개의 축 위에 올려놓았다.

2년이 넘게 지난 지금, 에이전트 기술은 논문이 쓰인 시점과는 비교할 수 없을 만큼 발전했다. 그럼에도 이 논문을 첫 번째로 다루는 이유는, CoALA가 제시한 분류 체계가 오늘날의 에이전트를 이해하는 데도 여전히 유용한 골격을 제공하기 때문이다. 이 글에서는 CoALA의 핵심 구조를 따라가되, 2023년의 시선이라는 점을 염두에 두고 읽어보자.

LLM에서 에이전트로 — 생성 시스템이라는 오래된 연결고리

CoALA를 이해하려면 생성 시스템(Production System)이라는 개념까지 거슬러 올라가야 한다.

20세기 전반, 수학과 계산을 기호 조작으로 환원하려는 시도가 있었다. 생성 시스템은 그 과정에서 탄생한 형식주의 중 하나다. 구조는 놀랍도록 단순하다. "조건이 맞으면 이 규칙을 적용한다."

XYZ → XWZ

문자열 XYZ를 만나면 Y를 W로 바꾸라는 뜻이다. 이런 규칙을 여럿 모아두면 문자열을 점진적으로 변환할 수 있다. 하지만 규칙만으로는 "어떤 규칙을 먼저 적용할지"를 알 수 없다. 여기서 제어 흐름(Control Flow)이 등장한다 — 규칙 사이의 우선순위와 실행 순서를 결정하는 장치다.

Allen Newell을 비롯한 AI 연구자들은 이 생성 시스템을 인간의 문제 해결 과정을 모사하는 데 끌어왔다. 단순한 문자열 변환 규칙에 기억, 지각, 계획 같은 인지 프로세스를 결합하니 인지 아키텍처(Cognitive Architecture)가 태어났다. 대표적인 예가 Soar다. Soar는 장기 기억에 규칙을 보관하고, 현재 상황에 가장 적합한 규칙을 골라 실행하는 판단 루프를 반복한다. 기억도, 학습도, 의사결정도 있는 완전한 인지 시스템이었다.

여기서 CoALA의 핵심 통찰이 나온다:

LLM은 확률적 생성 시스템이다.

전통적 생성 시스템이 "이 조건이면 이 규칙을 적용한다"고 결정론적으로 동작했다면, LLM은 입력 텍스트가 주어졌을 때 가능한 출력들에 대한 확률 분포를 만든다. 고정된 규칙을 따르는 것이 아니라, 매번 확률적으로 하나를 골라 적용하는 셈이다.

이 관점을 받아들이면, 프롬프트 엔지니어링의 본질도 달리 보인다. Few-shot 예시를 넣거나, RAG로 검색 결과를 컨텍스트에 추가하거나, Self-Critique를 시키는 것 — 이 기법들은 결국 LLM이라는 확률적 생성 시스템에 제어 흐름을 부여하는 행위다. 그리고 이 제어 흐름을 체계적으로 설계하면, LLM은 단순한 텍스트 생성기를 넘어 에이전트가 된다.

네 개의 서랍장 — CoALA의 기억 구조

인간은 다양한 종류의 기억을 쓴다.

지금 읽고 있는 문장의 내용(작업 기억)
어제 저녁에 먹은 것(일화 기억)
"서울은 한국의 수도"라는 사실(의미 기억)
자전거 타는 법(절차 기억)

CoALA는 이 인지심리학의 분류를 에이전트 설계에 그대로 가져온다.

기억 유형	역할	에이전트에서의 모습
작업 기억(Working Memory)	지금 이 순간 쓰이는 정보	프롬프트 컨텍스트, 현재 목표, 직전 관찰
일화 기억(Episodic Memory)	과거 경험을 시간순으로 보관	대화 이력, 작업 궤적, 성공·실패 기록
의미 기억(Semantic Memory)	세계에 대한 사실적 지식	위키피디아, 지식 베이스, 도메인 규칙
절차 기억(Procedural Memory)	"어떻게 하는지"에 대한 지식	LLM 가중치(암묵적) + 에이전트 코드(명시적)

절차 기억이 두 층으로 나뉘는 점이 흥미롭다.

첫째는 암묵적 절차 기억 — LLM 가중치 그 자체다. 수십억 파라미터에 압축된 "언어를 다루는 법"이다. 자전거 타는 법을 말로 설명하기 어렵듯, LLM의 가중치도 명시적으로 꺼내볼 수 없다.

둘째는 명시적 절차 기억 — 에이전트의 소스 코드다. "사용자 입력을 받으면 → 검색을 먼저 하고 → 결과를 프롬프트에 넣어서 → LLM에게 보내라" 같은 흐름이 여기 해당한다. 프롬프트 템플릿, 도구 호출 로직, 워크플로우 코드가 모두 명시적 절차 기억이다.

LLM은 본질적으로 무상태(Stateless) 시스템이다. 한 번의 호출이 끝나면 아무것도 남지 않는다. 에이전트가 "기억하는 존재"가 되려면, 이 네 가지 기억을 LLM 바깥에 명시적으로 구축해야 한다.

일화 기억이나 의미 기억은 처음에 비어 있어도 된다. 경험이 쌓이면서 채워지니까. 하지만 절차 기억은 다르다 — 에이전트가 돌아가려면, 설계자가 코드를 작성해서 초기화해야 한다. 에이전트는 백지 상태에서 태어나지만, "무엇을 어떻게 할지"는 알고 시작해야 한다.

에이전트가 할 수 있는 것들 — 행동 공간

기억이 에이전트의 "아는 것"이라면, 행동 공간(Action Space)은 "할 수 있는 것"이다. CoALA는 행동을 바깥을 향한 것과 안을 향한 것으로 나눈다.

바깥을 향한 행동 — 그라운딩(Grounding)

에이전트가 외부 세계와 실제로 상호작용하는 행위다. 세 갈래로 나뉜다:

물리 환경: 로봇이 물건을 집거나, 센서로 주변을 읽는 것
대화 환경: 사람이나 다른 에이전트와 언어로 소통하는 것
디지털 환경: API 호출, 웹 탐색, 코드 실행

흔히 말하는 "도구 사용(Tool Use)"은 디지털 환경에서의 그라운딩이다.

안을 향한 행동 — 추론, 검색, 학습

외부에 아무런 영향을 주지 않고, 에이전트의 내부 상태만 바꾸는 행위다. CoALA는 이를 기억과의 관계로 깔끔하게 분류한다:

추론(Reasoning): 작업 기억 안에서 정보를 가공해 새로운 결론을 낸다. 관찰을 요약하거나, 다음 행동을 계획하거나, 상황을 판단하는 것이 여기 속한다.
검색(Retrieval): 장기 기억에서 필요한 정보를 찾아 작업 기억으로 가져온다. 과거 경험을 떠올리거나, 지식 베이스에서 사실을 찾는 것이다.
학습(Learning): 새로운 정보를 장기 기억에 쓴다. 경험을 일화 기억에 기록하거나, 추론 결과를 의미 기억에 남기거나, 에이전트 코드 자체를 수정하는 것까지 포함한다.

정리하면, 추론 = 작업 기억 내 읽기/쓰기, 검색 = 장기 기억에서 읽기, 학습 = 장기 기억으로 쓰기다. 이 분류가 깔끔한 이유는 행동의 종류를 기억과의 상호작용으로 정의하기 때문이다.

생각하고, 고르고, 실행하다 — 의사결정 사이클

기억도 있고 행동도 할 수 있다면, 남은 질문은 하나다. "지금 무엇을 할 것인가?"

CoALA는 이 결정을 반복적인 사이클로 구조화한다.

관찰 → [계획: 제안 → 평가 → 선택] → 실행 → 관찰 → ...

계획 단계에서 에이전트는 세 과정을 거친다:

제안(Proposal): 추론과 검색을 동원해 후보 행동을 만든다. "지금 뭘 할 수 있지?"
평가(Evaluation): 후보가 여럿이면 각각에 점수를 매긴다. LLM의 자체 판단, 학습된 가치 함수, 시뮬레이션 결과 등 다양한 방법이 가능하다.
선택(Selection): 가장 유망한 행동을 고른다. 만족스러운 후보가 없으면 제안 단계로 돌아간다.

실행 단계에서는 선택된 행동을 수행한다. 외부 행동이면 환경에 영향을 주고, 내부 행동이면 기억 상태가 바뀐다. 그 결과로 새로운 관찰이 들어오고, 다시 사이클이 시작된다.

중요한 점은, 오늘날 대부분의 에이전트가 이 사이클의 일부만 구현하고 있다는 것이다. 제안만 하고 평가를 생략하기도, 평가에만 특화되기도 한다. CoALA는 이 차이를 체계적으로 포착하는 도구다.

다섯 에이전트로 읽는 CoALA

추상적인 프레임워크가 실제로 쓸모 있는지, 논문이 분석한 다섯 가지 에이전트를 살펴보자. 이들은 모두 2022~2023년에 발표된 연구로, 당시 에이전트 설계의 최전선이었다.

SayCan — 몸은 있지만 머리가 단순한 에이전트

Google이 만든 주방 로봇 에이전트다. 551개의 사전 정의된 동작("컵을 집어", "서랍을 열어")을 가지고 있고, LLM은 상황에 맞는 동작의 확률을 매기기만 한다. 장기 기억도, 추론이나 검색도 없이, 오직 평가만으로 의사결정을 한다. CoALA 기준으로 보면 가장 단순한 구조다 — 바깥 행동만 있고, 안을 향한 행동이 전혀 없다.

ReAct — 생각과 행동을 엮은 에이전트

"생각한 다음 행동하고, 행동한 다음 다시 생각한다." 이 패턴을 처음 제안한 연구다. 장기 기억 없이, 추론(안)과 그라운딩(바깥)을 번갈아 수행한다. 의사결정은 단순하다 — 한 번 추론으로 상황을 파악하고, 바로 다음 행동을 제안한다. 평가나 선택 과정이 없다. 하지만 이 단순한 구조만으로 추론과 행동의 시너지를 처음 입증했다.

Voyager — 네 가지 행동을 모두 갖춘 에이전트

Minecraft에서 자율 탐험하는 에이전트다. CoALA가 정의한 네 가지 행동(추론, 검색, 학습, 그라운딩)을 전부 갖춘, 가장 "완전한" 에이전트에 가깝다. 코드로 된 스킬을 절차 기억에 쌓고, 새 상황에서 기존 스킬을 검색해 활용하고, 성공한 스킬은 기억에 추가한다. 실패하면 추론으로 코드를 고쳐서 재시도한다. 에이전트가 경험을 통해 점점 유능해지는 구조다.

Generative Agents — 기억하고 성찰하는 에이전트

Stanford의 "AI 마을" 실험에서 등장한 에이전트다. 일화 기억과 의미 기억을 동시에 활용한다. 매일의 경험을 일화 기억에 쌓고, 주기적으로 이를 되돌아보며 고차원적 성찰("나는 환경에 관심이 많은 사람이다")을 만들어 의미 기억에 저장한다. 다음 날 계획을 세울 때 이 성찰을 검색해 참고한다. 단순히 반응하는 것이 아니라, 경험으로부터 자아를 빚어가는 에이전트다.

Tree of Thoughts — 내부 세계에서 깊이 파고드는 에이전트

바깥 행동은 "최종 답 제출" 하나뿐이다. 장기 기억도 없다. 하지만 의사결정에서 독보적이다. 추론 결과를 여러 개 제안하고, 각각을 LLM으로 평가하고, 트리 탐색 알고리즘으로 유망한 방향을 고른다. 막다른 길에 다다르면 이전 분기점으로 되돌아간다. 외부 세계 없이, 순수하게 내부 추론의 깊이를 극대화한 사례다.

비교 정리

에이전트	장기 기억	바깥 행동	안 행동	의사결정 특징
SayCan	없음	물리적 (로봇)	없음	평가만
ReAct	없음	디지털 (API)	추론	제안만
Voyager	절차 기억	디지털 (게임)	추론+검색+학습	제안+피드백 루프
Generative Agents	일화+의미 기억	디지털+대화	추론+검색+학습	제안+성찰
Tree of Thoughts	없음	디지털 (답 제출)	추론	제안+평가+선택

이 표에서 드러나는 패턴이 있다. 2023년 당시, 어떤 에이전트도 CoALA가 정의한 모든 요소를 다 갖추지는 못했다. 각각이 프레임워크의 서로 다른 부분을 탐색하고 있었을 뿐이다. 오늘날에는 이 빈칸의 상당수가 채워졌지만, CoALA가 제시한 좌표계 자체는 여전히 에이전트의 구조를 파악하는 데 유효하다.

에이전트 설계를 위한 세 단계 청사진

CoALA가 남긴 가장 실용적인 유산은 에이전트를 설계할 때 물어야 할 세 가지 질문이다.

첫째, 어떤 기억이 필요한가?

과거 상호작용을 기억해야 하면 일화 기억이, 도메인 지식을 참조해야 하면 의미 기억이, 코드 기반 스킬을 축적해야 하면 명시적 절차 기억이 필요하다. 모든 기억이 항상 필요한 것은 아니다 — ReAct는 장기 기억 없이도 강력했다.

둘째, 어떤 행동이 가능한가?

각 기억에 대한 읽기/쓰기 권한을 설계한다. 어떤 내부 행동(추론, 검색, 학습)이 필요한가? 어떤 외부 환경과 어떻게 연결되는가?

셋째, 어떻게 판단하는가?

제안만 할 것인가, 평가까지 할 것인가, 복수의 후보를 비교 선택할 것인가? 정교한 판단 절차는 더 나은 결과를 내지만, 비용과 지연도 커진다. 과제의 성격에 맞는 균형점을 찾아야 한다.

이 청사진 위에서 CoALA가 거듭 강조하는 원칙이 있다 — 에이전트는 모놀리식이 아닌 모듈형으로 구성되어야 한다. 기억, 행동, 판단을 독립적 모듈로 분리하면, 각 부분을 따로 개선하고 교체할 수 있다.

그리고 에이전트 안에는 두 종류의 "프로그램"이 공존한다. LLM 가중치(확률적, 유연함)와 에이전트 코드(결정론적, 정확함). CoALA의 제안은, 코드를 아껴 쓰되 LLM이 잘 못하는 영역 — 트리 탐색, 수치 계산, 외부 API 호출 — 을 보완하는 데 집중하라는 것이다.

CoALA가 남긴 질문들 — 2년 뒤의 시선으로

논문이 제시한 미래 과제들을, 2026년의 시점에서 되짚어보자:

자기 수정: 에이전트가 자기 코드를 고치며 발전할 수 있을까? → Claude Code나 Cursor 같은 코딩 에이전트가 이미 자신의 도구와 워크플로우를 수정하며 동작한다. 완전한 자기 수정까지는 아니지만, 논문이 상상한 방향으로 상당히 진전됐다.
적응적 검색: 상황에 따라 검색 전략을 바꿀 수 있을까? → RAG를 넘어 에이전트가 검색 쿼리를 스스로 구성하고, 결과를 평가해 재검색하는 패턴이 보편화됐다.
추론 효율: 추론의 비용과 품질 사이 균형을 조절할 수 있을까? → 이 문제는 여전히 열려 있다. 토큰 비용이 낮아졌지만, 언제 깊이 생각하고 언제 빠르게 답할지의 판단은 아직 발전 중이다.
신뢰와 정렬: 에이전트의 과신과 환각을 어떻게 제어할 것인가? → Constitutional AI나 RLHF 같은 접근이 발전했지만, 자율적으로 행동하는 에이전트의 정렬 문제는 여전히 가장 어려운 과제다.

논문은 "더 강력한 LLM이 등장하면 외부 기억이나 도구가 불필요해질까?"라고도 물었다. 실제로 컨텍스트 윈도우는 백만 토큰을 넘겼고, LLM의 추론 능력도 비약적으로 발전했다. 하지만 CoALA의 예측대로, 체계적인 기억과 행동의 구조는 사라지지 않았다. 오히려 에이전트가 더 복잡한 과제를 다루게 되면서 그 필요성이 더 뚜렷해졌다. 달라진 것은 각 모듈의 구현 방식과 비중이다.

마무리 — 렌즈로서의 CoALA

CoALA는 특정 에이전트를 만드는 레시피가 아니다. 2023년 시점에서 에이전트를 이해하고 비교하기 위한 렌즈를 제공한 논문이다. 개별 기술은 빠르게 구식이 되지만, "기억은 어떻게 구성되어 있는가, 행동은 무엇이 가능한가, 판단은 어떻게 내리는가"라는 질문의 구조는 쉽게 낡지 않는다.

"이 에이전트에는 어떤 기억이 있는가? 어떤 행동이 가능한가? 판단은 어떻게 내리는가?" — 이 세 질문만으로도, 어떤 에이전트든 구조와 한계를 파악할 수 있다. 빈칸이 보이면, 그것이 곧 개선의 방향이 된다.

다음 글에서는 CoALA가 사례로 다룬 에이전트 중 하나인 ReAct를 깊이 들여다본다. 추론과 행동을 엮는 단순한 아이디어가 어떻게 에이전트 설계의 출발점이 되었는지 살펴보자.

이 글은 "Agentic AI 논문 읽기" 시리즈의 첫 번째 글입니다.

프롤로그. 개발자, 회사를 만들다

Wed, 01 Apr 2026 00:00:00 GMT

프로젝트가 끝난 직후의 사무실은 묘한 공기를 품는다. 달리던 관성이 아직 남아 있는데 발밑에는 달릴 길이 없는, 그 특유의 부유감. 은행정보 플랫폼이라는 이름의 프로젝트를 마무리한 뒤가 그랬다. 수십 개 조직이 파편적으로 관리하던 데이터를 하나의 플랫폼으로 통합하고, SDK를 설계해서 연동 공수를 줄이고, 티셔츠까지 만들어 입고 다니며 전사에 보급했다. 제대로 작동하고 있었다. 다음 프로젝트들이 줄 서 있었고, 어떤 것은 흥미로운 기술 과제를 품고 있었다. 떠나야 할 이유가 딱히 보이지 않는 상황이었다.

그런데 그 사이, 이상한 감각이 자라고 있었다. 플랫폼이 잘 돌아갈수록 드는 생각이 있었다. 이것은 수십 개 조직이 각자 풀고 있던 같은 문제를 한곳에서 풀었기에 가능한 것이다. 그렇다면 조직이라는 구조 자체를 다르게 만들면 어떤 일이 벌어질까. 플랫폼을 만드는 것이 아니라, 플랫폼이 필요 없는 팀을 만들면. 처음부터 모든 맥락이 공유되고, 분업의 경계에서 유실되는 것이 없는 규모의 팀이라면.

물론 그것은 막연한 상상이었다. 퇴사를 결심하게 된 계기는 좀 더 구체적이었고, 한 사람의 끈질김에서 비롯되었다.

1시간의 결정

디스콰이엇이라는 플랫폼에서 메시지가 하나 왔다. 공동창업 제안이었다. 당시에는 일주일에 몇 통씩 비슷한 메시지가 도착하던 시기였기에, 대수롭지 않게 넘겼다. 그런데 며칠 뒤 링크드인으로 같은 사람이 다시 찾아왔다. 자료를 정리해서 보내며 이야기를 이어가려는 모습이 보통의 콜드메일과는 달랐다. 자료를 읽기 시작했다.

공감 가는 내용이 많았다. 기업이 매일 반복하는 비효율을 기술로 풀겠다는 방향, 작은 팀으로 빠르게 움직이겠다는 구상. 궁금한 점들을 메시지로 주고받다가, 마침 가까운 곳에 계신다기에 오프라인에서 만났다.

만난 지 1시간 만에 말이 나왔다. "같이 하시죠."

돌이켜보면 그것은 사업 계획에 대한 확신이 아니었다. 시장 규모를 계산한 것도, 수익 모델을 검증한 것도 아니었다. 이 사람과 함께라면 불확실한 것들 앞에서 도망치지 않을 수 있겠다는 감각이었다. 나중에야 그것을 관계에 대한 직관이라고 이해하게 되었지만, 그 순간에는 그저 몸이 먼저 반응한 것에 가까웠다. 자리에서 일어나 곧장 팀장님에게 퇴사 의사를 전했다.

만드는 것에서 함께 만드는 것으로

두 사람이 시작한 팀의 첫 번째 일은 코딩이 아니었다. 노코드 도구로 랜딩 페이지를 만들었다. "이런 기능이 곧 출시됩니다. 지금 신청하면 무료입니다." 단순한 문장이었다. 그런데 200곳이 넘는 기업이 신청했다.

숫자에 놀라기보다 먼저 한 것은 전화였다. 신청한 기업들을 하나씩 인터뷰했다. 한 달 동안 그들이 실제로 겪고 있는 문제에 파고들었다. 랜딩 페이지에 적었던 기능이 정말로 그들의 문제를 푸는 것인지, 아니면 우리가 상상한 문제일 뿐인지를 확인해야 했다. 그 과정에서 MVP의 윤곽이 잡혔고, 본격 개발에 들어갔다.

MVP는 정말로 기능에만 충실한 것이었다. 입력란과 버튼의 나열. 하지만 고객들이 쓰기 시작했고, 피드백이 쏟아졌다. 속도를 위해 포기했던 확장성이 발목을 잡았다. 기능 하나를 추가할 때마다 기존 구조가 흔들렸다. 결국 전면 리뉴얼이라는 결단을 내렸다. 작동하고 있는 제품을 처음부터 다시 짓는 일. 두 사람이 감당하기에는 벅찬 규모의 결정이었다.

그때부터 채용이 현실이 되었다. 프로덕트 디자이너를 먼저 모셨다. 혼자서 제품의 방향과 형태를 모두 결정하던 구조가 한계에 달했기 때문이다. 백엔드 개발자, 프론트엔드 개발자가 합류했다. 두 명이었던 팀이 다섯 명이 되었다.

다섯이라는 숫자는 작아 보인다. 하지만 그 전환의 무게는 숫자가 말해주지 않는다. 두 사람일 때는 모든 결정이 대화 한 번으로 끝났다. 머릿속에 있는 맥락이 서로에게 거의 그대로 공유되어 있었다. 세 번째 사람이 들어오는 순간, 그 자명함이 사라졌다. 내가 당연하다고 생각하는 것을 상대도 당연하게 여기리라는 전제가 더 이상 성립하지 않았다. 왜 이 기능을 먼저 만드는지, 왜 이 고객의 요구를 거절하는지, 왜 이 방식으로 코드를 짜는지 -- 설명해야 할 것들이 갑자기 불어났다.

"만드는 것"의 문제가 "함께 만드는 것"의 문제로 바뀌는 순간이었다. 코드의 문제가 아니라 사람의 문제, 구현의 문제가 아니라 조직의 문제가 눈앞에 놓였다. 그리고 솔직히, 그때의 나에게는 그것을 풀 준비가 되어 있지 않았다.

이 책이 답하려는 질문

개발자가 회사를 만든다는 것은 코드를 짜는 것과 전혀 다른 종류의 문제를 푸는 일이었다. 아키텍처를 설계하는 대신 채용 기준을 세웠고, 코드 리뷰를 하는 대신 피드백의 방식을 고민했다. 버그를 고치는 대신 사람들 사이의 기대치 불일치를 조율했다. 그리고 이 모든 것을 소수의 인원으로 해내야 했다.

작은 팀은 선택이었다. 큰 조직에서 겪었던 것들 -- 부서 사이에 떠도는 애매한 책임, 중간 관리자를 거치며 왜곡되는 정보, 누구도 전체를 보지 못하는 구조 -- 을 반복하고 싶지 않았다. 하지만 작은 팀을 유지하겠다는 결심만으로 문제가 풀리지는 않았다. 작은 팀이기에 부딪히는 문제들이 따로 있었다. 한 사람의 빈자리가 전체를 흔드는 무게, 명시적 프로세스 없이도 굴러가야 하는 일상, 친밀함이 만드는 침묵의 함정.

이 책은 그 여정에서 배운 것들의 기록이다.

작은 팀을 유지하면서 어떻게 큰 일을 해낼 수 있는가. 적은 인원으로 빠르게 움직이되, 방향을 잃지 않으려면 무엇이 필요한가. 이 질문에 대한 완결된 답을 가지고 있다고 말하기는 어렵다. 다만 시행착오 속에서 발견한 몇 가지 원칙이 있고, 그 원칙들이 실제로 작동하는 것을 확인한 경험이 있다.

그것들을 하나씩 펼쳐보려 한다. 왜 굳이 작은 팀이어야 했는지부터.

같이 일한다는 것

Wed, 01 Apr 2026 00:00:00 GMT

카페였다. 테이블 위에 아메리카노 두 잔, 그 사이에 노트북 한 대. 아직 이름도 정하지 못한 서비스의 데이터베이스 구조를 냅킨에 끄적이고 있었다. 상대방이 고개를 들어 말했다. "이거 진짜로 해볼까?" 나는 고개를 끄덕였다. 그 순간에는 몰랐다. 그 한마디가 단순한 프로젝트 제안이 아니라, 서로의 시간과 삶의 궤도를 하나로 엮는 일이었다는 것을.

같이 일하자는 말은 가볍게 나온다. 술자리에서, 카페에서, 때로는 메신저의 한 줄로. 하지만 그 말이 실행되는 순간, 무게가 완전히 달라진다. 함께 출근하고, 함께 야근하고, 함께 실패를 맞는다. 앞 챕터에서 작은 팀이라는 구조적 선택에 대해 이야기했다. 큰 조직의 관성을 벗어나 빠르게 움직일 수 있는 단위. 하지만 그 구조 안에 어떤 사람들이 있는가, 그리고 그 사람들 사이에 어떤 관계가 형성되는가는 전혀 다른 차원의 문제다.

같은 불확실성 안에 서는 것

같이 일한다는 것은 같은 공간에 앉는 것이 아니다. 같은 불확실성 안에 서는 것이다.

초기 스타트업에는 확실한 것이 아무것도 없다. 시장이 존재하는지도, 만들고 있는 제품이 맞는 방향인지도, 다음 달 급여를 줄 수 있는지도 모른다. 이 불확실성은 혼자 감당하면 공포가 되지만, 옆에 같은 것을 바라보는 사람이 있으면 모험이 된다. 공포와 모험의 차이는 능력의 차이가 아니라 관계의 차이다.

회사의 가치를 이야기할 때 존속가치라는 개념이 있다. 회사가 계속 운영될 때의 가치. 그리고 그 반대편에 청산가치가 있다. 문을 닫았을 때 남는 자산의 합. 초기 스타트업에서는 이 둘의 차이가 거의 없다. 사무실 보증금, 중고 모니터 몇 대, 반쯤 완성된 코드 — 청산하면 남는 것이 없다. 그런데 어떤 팀은 이 간극을 벌린다. 같은 자원, 같은 시장 조건에서도 존속가치가 청산가치를 압도하는 팀이 있다. 그 차이를 만드는 것은 기술력도, 사업 모델의 참신함도 아니다. 함께하는 사람들이 만들어내는 관계의 밀도다.

투자자들이 초기 팀에 돈을 거는 이유를 생각해본다. 슬라이드 덱에 적힌 TAM 수치나 비즈니스 모델이 결정적이라고 믿는 사람은 드물다. 그들이 실제로 보는 것은 "이 사람들이 함께라면 뭔가 해낼 것"이라는 믿음이 들게 하는 무엇, 즉 창업팀 사이의 관계의 질이다. 아이디어는 바뀔 수 있고, 시장은 변할 수 있다. 하지만 위기가 왔을 때 흩어지지 않고 함께 방향을 틀 수 있는 팀인가 — 이것은 쉽게 바뀌지 않는다.

위기가 오면 사람의 본질이 드러난다고 흔히 말하지만, 더 정확하게는 관계의 본질이 드러난다. 같은 방향을 바라보고 있었는지, 아니면 그저 같은 자리에 앉아 있었을 뿐인지가 분명해지는 순간. 그 순간을 버틸 수 있는 것은 계약서가 아니라 함께 쌓아온 신뢰다.

일상의 태도가 제도를 이긴다

관계의 밀도는 거창한 선언이 아니라 일상의 작은 태도에서 만들어진다.

복지라는 단어를 들으면 떠오르는 이미지가 있다. 실리콘밸리 캠퍼스의 무제한 간식바, 사내 세탁 서비스, 로비를 돌아다니는 반려견. 하지만 복지의 본질은 혜택의 목록이 아니다. 복지는 조직이 구성원에게 보내는 신호다. "당신은 단순한 노동력이 아닙니다. 당신의 삶 전체를 존중합니다." 무제한 간식이 아니라 아플 때 눈치 보지 않고 쉴 수 있다는 확신, 최신 장비가 아니라 의견을 말해도 불이익이 없다는 안전감. 그것이 진짜 복지다.

50인 이하의 스타트업에 전속 요리사를 둘 수는 없다. 하지만 옆자리 동료의 컨디션을 물어볼 수는 있다. 누군가 힘들어 보일 때 먼저 "괜찮아?"라고 묻는 것. 실수가 발생했을 때 범인을 찾는 대신 원인을 함께 분석하는 것. 야근이 당연한 것이 아니라 예외라는 사실을 서로 인정하는 것. 이런 작은 태도들이 켜켜이 쌓여서, 사람이 조직을 신뢰하게 되는 토양을 만든다.

작은 팀에서는 이런 일상의 태도가 제도보다 강력하다. 100페이지짜리 인사 규정보다, 대표가 팀원의 감기약을 사다놓는 행위가 더 큰 메시지를 보낸다. 관계의 밀도란 결국, 서로를 숫자가 아닌 사람으로 대하느냐의 문제이기 때문이다.

우리다움이라는 기준점

관계의 밀도가 쌓이면 팀 안에 독특한 것이 생겨난다. "우리는 어떤 팀인가"에 대한 공유된 감각. 이것을 나는 "우리다움"이라고 부른다.

회의실에서 흔히 벌어지는 장면을 떠올려보자. 리더가 새 프로젝트의 기획안을 화면에 띄운다. "의견 있으면 편하게 말해주세요." 침묵이 흐른다. 결국 "그럼 이대로 진행하겠습니다"라는 말로 회의가 끝난다. 복도에 나서야 두어 사람이 소곤거린다. "솔직히 그 방향 좀 아닌 것 같지 않아?"

의견이 없어서 침묵한 것이 아니다. 부족한 것은 아이디어가 아니라 확신이다. "이걸 말해도 될까?" "이 수준의 의견을 꺼내도 괜찮을까?" "내가 틀리더라도 이 팀에서는 괜찮을까?" 이 확신의 부재가 입을 닫게 만든다. 그리고 이 확신은 개인의 성격이나 용기와는 거의 관계가 없다. 아무리 대담한 사람이라도 낯선 팀의 첫 회의에서는 말을 아끼게 되고, 내성적인 사람도 안전하다고 느끼는 팀에서는 놀라울 만큼 날카로운 의견을 낸다.

"우리다움"이 바로 이 확신의 원천이 된다. "우리 팀은 일단 빠르게 해보는 팀"이라는 공유된 감각이 있으면, "이건 너무 오래 고민하고 있는 거 아닌가?"라는 말이 자연스럽게 나올 수 있다. "우리는 데이터 없이는 결정하지 않는 팀"이라는 정체성이 있으면, "이 결정에는 근거가 부족한 것 같다"는 지적이 공격이 아니라 정상적인 점검이 된다. 발언의 근거가 개인의 판단이 아니라 팀의 합의된 정체성 위에 놓이기 때문이다.

이 "우리다움"은 선언문이나 슬로건으로 만들어지지 않는다. 팀이 함께 일하면서 자연스럽게 축적한 패턴, 반복된 선택, 공유된 기억에서 형성된다. 그리고 이것을 의식적으로 강화하는 방법이 하나 있다. 과거에 누군가가 했던 발언을 되짚어주는 것이다. "지난번에 수진이 말했던 것 있잖아, 사용자 인터뷰를 먼저 하자고 했던 거. 그때 그 방향으로 갔더니 결과적으로 맞았어." 이 한마디가 만드는 효과는 단순한 칭찬을 넘어선다. 수진의 발언이 팀의 역사에 기록되고, "내가 했던 말이 기억되고 있다"는 감각이 다음 발언의 동기가 된다. 팀 전체에는 "발언은 흘러가는 것이 아니라 축적되는 것"이라는 메시지가 퍼진다.

결국 좋은 팀을 만드는 사람은 자기가 가장 뛰어난 아이디어를 내는 사람이 아니라, 다른 사람의 아이디어에서 가치 있는 조각을 발견하고 이름을 붙여주는 사람이다. 불완전한 생각이 꺼내지고, 그 위에 다른 생각이 얹히고, 혼자서는 도달할 수 없었던 방향이 만들어지는 순환. 이 순환의 시작은 화려한 인사이트가 아니라 팀원의 서툰 한마디를 주워 올리는 행위에 있다.

남는 것

왜 이 사람들과 함께 일하는가. 능력 때문인가, 비전 때문인가. 물론 둘 다 중요하다. 하지만 솔직하게 답하자면, 이 사람들 곁에서 나도 좀 더 나은 사람이 되는 것 같아서다. 함께 있을 때 더 용감해지고, 더 솔직해지고, 더 끈기 있어지는 관계. 그런 관계가 "같이 일한다는 것"의 본질이 아닐까.

사업이 잘될 수도 있고, 안 될 수도 있다. 서비스가 성공할 수도, 실패할 수도 있다. 하지만 함께 일하며 서로를 대했던 방식은 남는다. 어쩌면 그것이 우리가 만든 가장 중요한 것이다.

이 관계의 무게를 알게 되면, 자연스럽게 다음 질문이 떠오른다. 그렇다면 누구와 함께할 것인가. 관계의 본질을 이해한 사람에게, 새로운 사람을 팀에 들이는 일은 단순한 채용이 아니라 관계를 시작하는 결정이 된다.

왜 작은 팀인가

Wed, 01 Apr 2026 00:00:00 GMT

스타트업의 가장 큰 강점이 무엇이냐고 물으면, 대부분의 사람들은 "빠른 의사결정"이라고 답한다. 맞는 말이다. 적어도 처음에는. 세 명이 머리를 맞대면 점심시간 안에 제품의 방향이 바뀔 수 있고, 오후에 바로 실행에 옮길 수 있다. 그런데 그 팀이 열 명이 되고, 서른 명이 되고, 쉰 명이 되면 어떤 일이 벌어질까?

자동차의 바퀴를 생각해보자. 네 개의 바퀴는 자동차를 움직이기에 충분하다. 그런데 바퀴를 여덟 개로 늘리면 두 배로 빨라질까? 열여섯 개로 늘리면? 오히려 바퀴들 사이의 마찰이 생기고, 방향을 틀 때마다 더 많은 에너지가 소모되며, 어느 순간부터는 바퀴가 서로를 방해하기 시작한다. 조직도 마찬가지다. 인원이 늘어난다고 해서 속도가 비례하여 빨라지지 않는다. 오히려 역방향으로 작용하는 힘이 생긴다.

프롤로그에서 나는 왜 큰 조직을 떠나 작은 팀을 만들었는지를 이야기했다. 이 챕터에서는 그 선택의 이면에 있는 구조적 이유를 들여다보려 한다. 작은 팀을 유지하겠다는 결심이 단순한 취향이 아니라 전략이 될 수 있는 이유, 그리고 조직이 커지면서 잃어버리게 되는 것들에 대한 이야기다.

커진 조직에서 벌어지는 일

세 명이 함께 시작한 팀이 쉰 명, 백 명으로 불어나는 과정은 겉으로 보기에 성공의 징표다. 투자를 받고, 사람을 뽑고, 부서를 나누고, 각자의 역할을 명확히 정의한다. 조직도에 깔끔한 선이 그어지고, 누가 무엇을 담당하는지가 분명해진다. 합리적인 과정처럼 보인다.

그런데 바로 이 "명확한 업무 분장"이 예상하지 못한 부작용을 낳는다. 역할이 나뉘는 순간, 역할의 경계에 있는 애매한 일들이 생긴다. 그 일은 누구의 것인가? 아무도 선뜻 손을 들지 않는다. 내 일이 아니니까. 이것이 부서 이기주의의 씨앗이다.

나는 조직이 커지는 과정을 여러 번 가까이서 지켜보았다. 그때마다 반복적으로 나타나는 풍경이 있었다. 복도에서, 회의실에서, 슬랙 채널에서 이런 말들이 떠돌기 시작하는 것이다. "우리 제품은 왜 이렇게 장애가 잦지?" "1년 전 고객 컴플레인이 왜 아직도 미해결이야?" "개발팀은 도대체 뭘 하고 있는 거야?"

이 질문들의 공통점은 모두 다른 팀을 향해 있다는 것이다. 각자는 자기 부서의 성과를 위해 열심히 일하고 있다고 믿지만, 그 열심히 일하는 방향이 회사 전체의 방향과 어긋나기 시작한다. 토론이라는 이름 아래 서로에게 책임을 전가하고, 부서 단위로 성과를 극대화하려는 문화가 자리잡는다. 결국 제품의 품질은 떨어지고, 고객 만족도는 하락하며, 성장은 정체된다. 인원을 늘린 것이 성장을 위한 투자였는데, 그 투자가 오히려 성장을 갉아먹는 역설적 상황이 벌어지는 것이다.

여기에 더해, 커뮤니케이션 레이어가 추가될수록 정보는 왜곡된다. 세 명이 한 방에서 일할 때는 모든 맥락이 공유되었다. 누가 무슨 일을 하고 있는지, 어디서 막혔는지, 어떤 고객이 뭘 원하는지가 공기처럼 자연스럽게 흘렀다. 그런데 팀이 커지면 정보는 중간 관리자를 거치고, 회의록으로 정리되고, 주간 보고서로 압축된다. 그 과정에서 뉘앙스는 사라지고, 의도는 변질되며, 현장의 온도는 숫자로 환원된다. 원래의 문제가 경영진에게 도달할 때쯤이면, 이미 전혀 다른 문제가 되어 있는 경우도 드물지 않다.

작은 팀이라는 전략

돌이켜보면, 내가 가장 즐겁게 일했던 시기는 크게 노력하지 않아도 모든 구성원이 무슨 일을 하고 있는지 눈에 보이는 규모일 때였다. 대략 스무 명 안팎. 그 정도 규모에서는 회사 전체가 어떻게 돌아가는지 한눈에 들어온다. 내가 하는 일이 회사에 어떤 영향을 미치는지가 명확히 보인다. 그 "보인다"는 감각이 사라지는 순간, 일하는 방식이 근본적으로 달라진다.

큰 조직에서 일할 때는 회사 전체를 보는 것이 물리적으로 불가능하다. 자연스럽게 시야가 내가 속한 부서의 업무로 좁아진다. 그것은 개인의 의지와 관계없는 구조적 한계다. 반면 작은 팀에서는 전체를 보는 것이 기본값이다. 모든 구성원이 회사의 전체 그림 속에서 자신의 역할을 인식하고, 다른 사람의 일과 자기 일이 어떻게 연결되는지를 체감한다.

작은 팀을 유지하겠다는 것은 성장을 포기하겠다는 뜻이 아니다. 그것은 성장의 방식을 다르게 정의하겠다는 선언이다.

스타트업의 전통적 성장 공식은 단순했다. 제품-시장 적합성을 찾으면 투자를 받고, 사람을 뽑고, 규모를 키우고, 다시 투자를 받는 순환. 이 루프는 빠르게 돌수록 좋다고 여겨졌다. 하지만 그 과정에서 조직은 비대해지고, 사업 방향을 전환하기가 점점 어려워진다. 특정 역할을 위해 채용한 사람들을 새로운 방향에 재배치하는 일은 생각보다 훨씬 큰 뚝심과 고통을 수반한다. 매출이 나고 있는 사업을 접고 새로운 것을 시작하겠다는 결정은 조직이 클수록 내리기 어렵다.

작은 팀은 이 문제에서 훨씬 자유롭다. 인원이 적으면 의사소통 비용이 낮고, 조직을 플랫하게 유지할 수 있으며, 방향 전환이 필요할 때 빠르게 움직일 수 있다. 인재밀도를 높이면서 규모를 억제하는 전략은, 변화의 속도가 빨라지는 세상에서 구조적 이점으로 작용한다.

여기에 하나의 시대적 흐름이 이 전략을 더욱 유효하게 만들고 있다. 생성형 AI의 등장으로 한 사람이 수행할 수 있는 일의 범위가 급격히 넓어지고 있다는 점이다. 예전에는 열 명이 해야 했던 일을 세 명이 해낼 수 있는 시대가 오고 있다. 이 변화는 작은 팀이 감당할 수 있는 일의 크기를 근본적으로 바꾸어 놓는다. 몸집을 불려 리스크를 키우는 대신, 적은 인원으로 더 큰 임팩트를 만드는 것이 가능해진 것이다. 이 주제는 이 책의 후반부에서 더 깊이 다루게 될 것이다.

폴 자비스Paul Jarvis는 『Company of One』에서 작은 규모를 유지함으로써 "성장을 위한 성장"이 만들어내는 문제들을 피할 수 있다고 주장한다. 그의 논지에 공감하지만, 나는 한 발 더 나아가고 싶다. 작은 팀을 유지하는 것은 문제를 "피하는" 전략이 아니라, 더 건강하고 오래 지속될 수 있는 성장을 "선택하는" 전략이다. 볼타에서 우리가 작은 팀을 고집하는 이유가 바로 여기에 있다. 불필요한 커뮤니케이션 비용을 줄이고, 효율적으로 일하며, 작은 팀만이 가질 수 있는 강점을 극대화하는 것. 그것이 우리가 정의한 성장의 모습이다.

작은 것은 쉽지 않다

하지만 여기서 한 가지 고백해야 할 것이 있다.

작은 팀이 좋다는 말은 쉽다. 그런데 작은 팀을 "제대로 작동시키는 것"은 완전히 다른 문제다. 큰 조직은 시스템으로 비효율을 흡수할 수 있다. 누군가가 빠져도 조직은 돌아간다. 프로세스가 사람을 대체한다. 하지만 작은 팀에서는 한 사람 한 사람의 무게가 크다. 누군가의 부재가 전체에 즉각적인 영향을 미친다. 그래서 작은 팀은 더 정교한 운영 기술을 필요로 한다.

적은 인원으로 큰 일을 해내려면, 누구와 함께할 것인지를 더 신중하게 결정해야 한다. 리더가 부서의 대리인이 아니라 조직 전체의 리더로 서야 한다. 팀 전체가 같은 방향을 바라보게 만드는 명료함이 있어야 한다. 불편한 말을 할 수 있는 문화가 필요하고, 과정에서 공정함을 느낄 수 있는 시스템이 있어야 한다. 무엇을 할 것인지와 어떻게 할 것인지를 분리할 줄 알아야 하며, 번아웃에 빠지지 않으면서 성과를 만들어내는 방법을 찾아야 한다.

작은 팀이라는 전제 위에 이 모든 것을 쌓아야 비로소 그 팀은 작동한다.

그렇다면 작은 팀에서 "함께 일한다"는 것은 정확히 어떤 의미일까? 규모의 문제를 넘어, 관계의 밀도라는 다른 차원의 이야기가 필요하다.

누구와 함께할 것인가

Wed, 01 Apr 2026 00:00:00 GMT

같이 일한다는 것의 무게를 알게 되면, 다음 질문은 자연스럽게 따라온다. 그렇다면 누구와 함께해야 하는가.

창업 초기, 두 사람이 카페에서 서비스 구조를 그리던 시절에는 이 질문이 그리 복잡하지 않았다. 서로의 부족함을 채울 수 있는 사람, 같은 방향을 보고 있는 사람이면 충분했다. 그러나 제품이 시장에 나가고 고객이 생기기 시작하면, 두 사람만으로는 감당할 수 없는 영역이 나타난다. 그때 비로소 채용이라는 단어가 현실이 된다.

작은 팀에서 채용은 빈자리를 메우는 일이 아니다. 팀의 밀도를 재조정하는 일이다. 다섯 명이 일하는 조직에서 한 사람은 전체의 20퍼센트다. 그 한 사람이 어떤 사고방식을 가졌는지, 어떤 강점을 지녔는지, 팀에 어떤 자극을 줄 수 있는지에 따라 조직 전체의 색깔이 바뀐다. 대기업에서 채용이 인력 수급의 문제라면, 작은 팀에서 채용은 정체성의 문제다.

3500 대 3

2023년, 볼타는 처음으로 본격적인 채용을 시작했다. 여러 플랫폼에 공고를 올렸고, 약 3500명이 지원했다. 모 채용 플랫폼에서 인기순 1위를 2주 연속 유지하기도 했다. 그리고 최종적으로 세 사람을 모셨다.

3500 대 3이라는 숫자가 자랑이 아니다. 이 숫자는 경쟁률이 아니라, 작은 팀에서 한 사람을 선택하는 일이 얼마나 무거운 결정인지를 보여준다. 수천 명의 이력서를 읽고, 과제를 검토하고, 인터뷰를 진행하면서 깨달은 것이 있다. 채용에서 가장 중요한 것은 뛰어난 사람을 찾는 것이 아니라, 이 팀에 맞는 사람을 찾는 것이다. 그리고 그 기준을 명확히 갖고 있지 않으면, 수천 명의 이력서 앞에서 길을 잃는다.

불합격을 안내드린 분들에게 500자에서 1000자에 이르는 피드백을 보냈다. 시간이 많아서가 아니었다. 지원해주신 분들의 시간을 존중하는 것이 채용의 첫 번째 원칙이라고 생각했기 때문이다. 채용은 합격자만을 위한 과정이 아니다. 불합격자에게 어떤 태도를 보이느냐가, 그 조직이 사람을 어떻게 대하는지를 드러낸다.

같이 일해본 사람을 모시지 않는다는 것

첫 번째 채용 원칙은 의외의 것이었다. 같이 일해본 적 있는 사람을 풀타임으로 모시지 않는다는 원칙.

대부분의 창업자는 정반대의 선택을 한다. 검증된 사람, 손발이 맞는 사람, 따로 설명하지 않아도 서로의 생각을 아는 사람을 데려온다. 합리적인 판단처럼 보인다. 초기 속도가 중요한 스타트업에서 커뮤니케이션 비용을 줄이는 것은 분명한 이점이다.

그러나 이 이점 뒤에는 세 가지 그림자가 있다.

첫째, 조직의 개성이 사라진다. 비슷한 경험을 공유한 사람끼리는 서로에게 새로운 자극을 주기 어렵다. 같은 회사에서 같은 방식으로 일했던 사람들이 모이면, 그 조직은 이전 조직의 복제품이 될 위험이 있다. 작은 팀이 가져야 할 가장 큰 무기는 다양한 시각인데, 그 무기를 스스로 내려놓는 셈이다.

둘째, 건강하게 싸우기 어렵다. 제품을 만들다 보면 의견이 충돌하는 순간이 반드시 온다. 그때 이미 쌓인 친분은 오히려 족쇄가 된다. 관계가 틀어질까 두렵고, 나쁜 사람으로 기억되는 게 싫어서 갈등을 피한다. 표면적으로는 화목한 팀이지만, 속으로는 중요한 논쟁을 회피하는 팀. 그런 팀은 결정적인 순간에 최선의 판단을 내리지 못한다.

셋째, 보이지 않는 벽이 생긴다. 눈빛만으로 서로의 생각을 읽는 관계는 두 사람 사이에서는 효율적이다. 하지만 팀에 새로운 사람이 합류하면 이야기가 달라진다. 설명 없이 통하는 두 사람과, 그 맥락을 알 수 없는 나머지 사이에 의도하지 않은 파벌이 만들어진다. 팀이 커질수록 이 벽은 두꺼워지고, 결국 조직 전체의 커뮤니케이션을 병들게 한다.

이 원칙은 친한 사람과 일하지 말라는 뜻이 아니다. 친분에 기대어 채용의 본질을 건너뛰지 말자는 뜻이다. 작은 팀에서 한 사람의 합류는 기존의 균형을 깨뜨리는 일이다. 그 균형을 깨뜨릴 때, 더 나은 균형으로 재편되어야 한다. 익숙함은 안정감을 주지만, 작은 팀에 필요한 것은 안정감이 아니라 긴장감이다.

인재밀도를 높이는 기준들

그렇다면 어떤 사람을 모셔야 하는가. 수천 건의 이력서를 검토하고 수십 번의 인터뷰를 진행하면서, 채용의 기준은 점점 구체화되었다.

가장 먼저 확인한 것은 팀과의 적합성이었다. 그러나 단순히 "분위기에 잘 어울리는 사람"이라는 뜻이 아니다. 팀 Fit이라는 말에는 더 깊은 의미가 있었다. 기존 팀원들과 잘 맞으면서도, 동시에 기존 팀에 없는 캐릭터를 가진 사람. 합류했을 때 기존 팀원들이 새롭게 배울 수 있는 무언가가 분명한 사람. 조화와 자극, 이 두 가지를 동시에 충족시키는 사람을 찾는 것이 핵심이었다.

세 사람을 모시는 과정에서 이 기준은 구체적인 판단으로 이어졌다. 제품 리뉴얼을 앞두고 가장 먼저 모신 프로덕트 디자이너는 이전 환경에서의 강점이 명확하면서도, 완전히 새로운 환경에서 도전하겠다는 확신이 뚜렷한 사람이었다. 백엔드 엔지니어는 아직 대학에 재학 중이었지만, 경력자들도 어려워하는 인터뷰를 훌륭히 통과했고, 무엇보다 신선한 시각과 열정으로 제품에 새로운 의견을 던질 수 있는 사람이었다. 프론트엔드 엔지니어는 한정된 시간 안에서 일을 효율적으로 해내는 능력이 인터뷰 과정에서부터 드러난, 모든 팀원에게 귀감이 될 수 있는 사람이었다.

세 사람의 공통점이 있었다. 양적 확장이 가능하다는 것. 기존 팀원이 하는 일을 당연히 소화하면서도, 새로운 영역으로 확장하는 데 기여할 수 있는 사람이라는 판단이 있었다. 작은 팀에서는 한 사람이 하나의 역할만 수행하는 것이 사치다. 자신의 전문 영역을 깊이 파면서도, 필요하면 경계를 넘나들 수 있는 사람이어야 한다.

채용 프로세스 자체도 진화했다. 초기에는 이력서, 사전 과제, 온사이트 인터뷰로 이어지는 전통적인 방식을 따랐다. 짧으면 2주, 길면 한 달. 그런데 온사이트까지 왔는데도 가장 중요하게 보는 부분에서 아쉬움을 느끼는 경우가 반복됐다. 후보자도 회사도 많은 시간을 투자한 뒤에 불합격을 통보받는 상황. 이것은 제품 개발에서 말하는 Fast Fail의 부재와 같은 문제였다.

그래서 30분 남짓의 사전 인터뷰를 도입했다. 이력서만으로는 알 수 없는, 팀이 가장 중요하게 여기는 가치관과 태도를 초기에 확인하기 위해서다. 제품 개발에서 빠르게 검증하고 빠르게 방향을 잡는 것이 중요하듯, 채용에서도 서로의 시간을 낭비하지 않는 것이 예의이자 효율이었다. 사업적 임팩트를 주도적으로 만들고 싶은 사람인지, 안정보다 혁신에 가치를 두는 사람인지, 뛰어난 동료에게서 자극받는 사람인지. 이런 질문에 대한 답은 긴 과제가 아니라 짧은 대화에서 더 정직하게 드러난다.

서로 다른 시간을 가진 사람들

좋은 사람을 모시면 끝일까. 그렇지 않다. 채용 이후에는 또 다른 긴장이 기다린다.

스타트업이 성장하면 피할 수 없는 순간이 있다. 처음부터 함께한 사람들과 새로 합류한 사람들 사이의 미묘한 갈등. "우리가 처음부터 여기 있었는데"라는 감정과, "지금 중요한 건 현재의 역량 아닌가"라는 논리가 부딪힌다. 어느 쪽이 옳다고 말하기 어렵다. 둘 다 진실이기 때문이다.

함께 시작한 사람들의 기여를 기억하는 것은 중요하다. 아무것도 없던 시절에 불확실성을 함께 감내한 사람들이다. 하지만 그 기여가 특권이 되는 순간, 조직은 병든다. 과거의 공로가 현재의 면책으로 작동하면, 새로 합류한 사람은 아무리 뛰어나도 보이지 않는 천장을 느끼게 된다. 반대로, 새로운 사람의 역량만을 기준으로 삼으면 초기 멤버들은 자신이 소모품이었다는 감정을 갖게 된다.

이 균형을 잡는 데 정답은 없다. 다만 태도는 있다. 기여를 기억하되 특권으로 만들지 않는 것. 역량을 존중하되 맥락을 무시하지 않는 것. 그리고 무엇보다, 팀 안에서 서로 다른 시간을 가진 사람들이 같은 현재를 만들어가고 있다는 사실을 모두가 인식하는 것.

채용은 팀에 사람을 더하는 산술이 아니다. 팀의 밀도를 재조정하는 화학이다. 한 사람이 합류하면 기존의 관계, 역할, 무게중심이 모두 변한다. 그 변화를 두려워하지 않되, 가볍게 여기지도 않는 것. 3500명 중 세 사람을 선택한 그 무게가, 선택 이후에도 계속된다는 것을 아는 것. 그것이 작은 팀의 채용이 가진 진짜 의미가 아닐까.

좋은 사람들을 모셨다면, 이제 다음 질문이 찾아온다. 그 사람들이 함께 리더십팀을 구성할 때, 무엇이 가장 중요한가.

리더는 부서의 대사가 아니다

Wed, 01 Apr 2026 00:00:00 GMT

좋은 사람들을 모았다. 인재밀도를 지키기 위해 채용 기준을 세우고, 함께 일해본 적 없는 사람에게까지 손을 뻗었다. 이제 그 사람들이 리더로서 한 테이블에 앉는다. 그런데 막상 테이블에 둘러앉으면, 기대했던 것과는 다른 광경이 펼쳐진다.

엔지니어링 리드가 먼저 입을 연다. "개발팀 입장에서 말씀드리면, 이번 일정은 현실적으로 어렵습니다." 프로덕트 리드가 바로 받는다. "PM 조직에서는 이 기능이 이번 분기에 반드시 나가야 한다고 보고 있습니다." 디자인 리드가 끼어든다. "디자인팀 관점에서는 품질을 더 가져가고 싶은데요."

대화는 정중하다. 분위기도 나쁘지 않다. 그런데 한 시간이 지나 회의실을 나서면, 결정된 것은 거의 없다. 각자 자기 팀의 이익을 조금씩 양보해서 타협안을 만들었지만, 누구도 만족하지 못했고, 조직 전체에 가장 좋은 결정이 무엇인지는 논의조차 되지 않았다. 이 미팅은 도대체 무엇이었을까.

대사의 함정

이 장면을 가만히 들여다보면, 익숙한 구조가 보인다. UN 총회다. 각국의 대사들이 자국의 이익을 대표하여 발언하고, 양보는 최소화하며, 자국에 유리한 결과를 이끌어내는 것이 유능한 대사의 조건인 그 자리. 리더십 미팅이 UN 총회와 닮았다면, 그 안에 앉아 있는 사람들은 리더가 아니라 대사로 행동하고 있다는 뜻이다.

대사에게 "당신 나라 이익을 포기하고 전체를 위해 양보하라"고 말하면, 그는 어이없어할 것이다. 자국의 이익을 극대화하는 것이 대사의 존재 이유이기 때문이다. 문제는, 많은 리더십팀이 정확히 이 구조로 작동한다는 점이다. 엔지니어링 리드는 개발팀의 대사, 프로덕트 리드는 PM 조직의 대사, 디자인 리드는 디자인팀의 대사. 미팅의 결과는 각 부서 이익의 교집합이지, 조직 전체를 위한 최선의 결정이 아니다.

여기서 근본적인 질문이 생긴다. 리더십팀에 앉아 있는 사람들의 정체성은 무엇인가. 그들은 부서의 대사인가, 조직의 리더인가.

내가 직접 리더십팀을 운영하면서 확신하게 된 것이 하나 있다. 리더십팀에서 나의 첫 번째 팀은 내가 이끄는 팀이 아니라, 내가 속한 리더십팀 그 자체라는 것이다. 이것은 자기 팀을 소홀히 하라는 뜻이 아니다. 리더십팀에서 내린 결정이 조직 전체에 가장 좋은 결정이 되어야, 결국 내 팀도 더 나은 환경에서 일할 수 있다는 의미다. 대사는 자국에 불리한 결정에 반대하지만, 리더는 자기 부서에 불리하더라도 조직 전체에 좋은 결정이면 기꺼이 지지한다. 이 차이가 UN 총회와 리더십팀을 갈라놓는다.

하나의 팀, 하나의 점수

축구 경기를 떠올려 보자. 한 미드필더가 경기 후 인터뷰에서 말한다. "저는 오늘 패스 성공률 94%를 기록했습니다. 제 역할은 충분히 했다고 생각합니다." 그런데 팀은 0대 3으로 졌다. 이 미드필더는 좋은 경기를 한 것인가.

축구에서는 답이 자명하다. 개인 기록이 아무리 좋아도 팀이 지면 의미가 없다. 이긴 팀의 벤치 선수도 이긴 것이고, 진 팀의 MVP도 진 것이다. 모든 선수가 같은 점수를 받는다.

조직도 다르지 않다. 엔지니어링팀이 모든 기술 지표를 달성했지만 회사 전체가 분기 목표를 놓쳤다면, 엔지니어링 리드도 실패한 것이다. 마케팅팀이 캠페인 성과를 초과 달성했지만 제품이 제때 나가지 못해 매출이 빠졌다면, 마케팅 리드도 그 결과에서 자유롭지 않다. "내 팀은 잘했는데 왜 나까지 실패인가"라는 반문이 나올 수 있다. 그러나 바로 그 불공정함을 받아들이는 것이 리더십팀의 구성원이 된다는 것의 의미다.

내 부서의 성과가 좋으면서 회사 전체가 흔들린다면, 그것은 내가 리더십팀의 일원으로서 충분히 기여하지 못했다는 신호이기도 하다. 다른 부서의 병목을 함께 풀었어야 했고, 자원 배분에 대해 더 적극적으로 목소리를 냈어야 했다.

하나의 팀, 하나의 점수를 받아들이면 리더십 미팅의 풍경이 달라진다. "우리 팀 입장에서는"이라는 말 대신 "회사 전체로 볼 때"라는 말이 나오기 시작한다. 다른 부서의 문제가 남의 일이 아니게 된다. 자원이 부족한 팀을 돕는 것이 내 부서의 이익을 줄이는 것이 아니라 모두의 점수를 올리는 행위가 된다.

그런데 왜 이것이 말처럼 쉽지 않을까. 세 가지 저항이 있다.

첫째, 정체성의 문제다. "나는 엔지니어링 리드다"라는 문장에서 정체성은 엔지니어링에 놓인다. 매일 함께 일하는 사람은 개발팀 동료들이고, 리더십 미팅은 일주일에 한두 번이다. 소속감은 자연스럽게 부서 쪽으로 기운다.

둘째, 팀원들의 시선이다. 리더가 리더십 미팅에서 돌아오면 팀원들은 묻는다. "우리한테 유리한 결과가 나왔나요?" "사실 회사 전체를 위해 우리가 양보하기로 했다"고 말하면 실망하는 표정이 돌아올 수 있다. 이 순간의 두려움이 크다. 부서 밖에서는 조직의 리더로 행동했는데, 부서 안에서 배신자 취급을 받을까 걱정하는 것이다.

셋째, 단기 성과의 유혹이다. 리더십 미팅에서 부서 이익을 최대한 지키면, 부서로 돌아가서 "승리"를 보고할 수 있다. 단기적으로는 팀의 사기가 올라간다. 그러나 이 승리가 쌓이면, 리더십팀은 점점 더 UN 총회로 변질된다.

하지만 대부분의 팀원들이 정말로 원하는 것은 "우리 편만 드는 리더"가 아니다. 그들이 원하는 것은 "회사가 잘 되게 만드는 리더"다. 조직이 잘 되어야 팀도 잘 되고, 팀이 잘 되어야 개인도 잘 된다는 것을 합리적인 사람이라면 이해한다. 다만, 그 결정의 배경을 투명하게 설명해야 한다. "그냥 결정됐다"가 아니라, 왜 이 결정이 조직 전체에 가장 좋은지, 우리 팀에는 어떤 영향이 있고 장기적으로 어떤 이점이 있는지를 말해야 한다.

문제 해결형 리더의 세 축

리더십팀에서 대사의 자리를 내려놓았다면, 그 자리에 무엇을 채워야 하는가. 나는 제럴드 와인버그의 MOI 모델을 접한 뒤, 이 질문에 대한 하나의 프레임워크를 얻었다. 변화를 만들어내려면 세 가지가 필요하다.

동기부여(Motivation)는 사람들이 움직이도록 만드는 힘이다. 위협이나 보상만을 말하는 것이 아니라, 왜 이 일이 중요한지를 스스로 느끼게 하는 것까지 포함한다. 조직화(Organization)는 아이디어가 실현될 수 있는 구조를 만드는 것이다. 아무리 좋은 아이디어가 있어도 실행할 수 있는 체계가 없으면 공허하다. 아이디어(Idea)는 씨앗이다. 문제를 새로운 각도에서 보게 하는 관점, 해결책의 실마리가 되는 발상이다.

세 가지 중 하나라도 빠지면 변화는 일어나지 않는다. 반대로 말하면, 변화를 저지하고 싶다면 셋 중 하나만 무너뜨리면 된다. 의욕을 꺾거나, 협력 체계를 무너뜨리거나, 아이디어의 흐름을 막으면 조직은 멈춘다. 이 사실을 인지하는 것 자체가 리더에게는 중요한 자각이다.

이 모델을 실제 개발 조직에 적용하면, 문제 해결형 리더가 집중해야 할 세 가지 축이 드러난다.

첫째, 문제를 이해하는 것이다. 성공과 실패가 사소한 문제 정의의 차이에 달려 있는 경우가 많다. 논쟁이 길어지는 이유의 대부분은 해결 방법의 차이가 아니라 문제에 대한 이해가 다르기 때문이다. 문제 해결형 리더는 논쟁의 근원이 문제 정의에 있는지, 해결 방법에 있는지를 구분할 줄 안다. 그리고 팀원들이 고객의 문제를 직접 이해하도록 끊임없이 권장한다. 복잡한 문제를 처음부터 제대로 이해하는 경우는 거의 없지만, 이해하고 있다고 착각하는 경우는 많다. 그 착각이 재앙으로 가는 가장 확실한 길이다.

둘째, 아이디어의 흐름을 관리하는 것이다. 아이디어가 너무 적으면 해결책을 얻을 수 없고, 너무 많으면 혼란이 온다. 여기서 핵심적인 행동 두 가지가 있다. 하나는 팀 동료의 아이디어를 즉각 비판하지 않는 것이다. 아이디어를 테스트하는 것과 즉각 비판하는 것은 전혀 다른 문제다. "그건 안 될 거야"라는 말은 아이디어를 검증하는 것이 아니라 아이디어의 흐름 자체를 끊어버린다. 다른 하나는 시간의 압박에 굴복하지 않고 사람들의 아이디어에 귀 기울이는 시간을 갖는 것이다. 시간이 부족하면 대부분의 아이디어를 제대로 이해하기도 전에 포기하게 된다. 단기적으로는 시간을 절약하는 것처럼 보이지만, 자신의 아이디어가 부당하게 버려졌다고 느끼는 사람은 열의를 잃는다. 역설적으로, 모든 아이디어에 귀 기울이는 팀이 결과적으로 더 빠르게 전진한다.

셋째, 품질을 유지하는 것이다. "열심히 하면 된다"는 목표가 없는 상태에서의 자기 위안에 불과하다. 문제 해결형 리더는 프로젝트를 진행하면서 끊임없이 품질을 측정하고, 때로는 한 걸음 물러나서 전체를 조망한다. 특히 중요한 것은 프로젝트가 가망이 없다는 것을 알아차렸을 때, 다른 사람들이 더 많은 노력을 쏟기 전에 그 사실을 받아들이도록 설득하는 용기다.

이 세 축은 서로 독립적이지 않다. 문제를 깊이 이해해야 좋은 아이디어가 나오고, 아이디어의 흐름이 건강해야 품질 높은 결과물이 만들어지며, 품질에 대한 명확한 기준이 있어야 문제를 올바르게 정의할 수 있다. 리더는 이 세 축 사이를 끊임없이 오가며 팀이 앞으로 나아가도록 돕는 사람이다.

변화를 만들어내는 모든 사람

리더십 미팅에서 주어를 바꾸는 것부터 시작할 수 있다. "개발팀 입장에서는"을 "회사 전체로 볼 때"로 바꿔 보는 것이다. 단순한 언어의 변화지만, 이 전환이 사고의 프레임을 바꾼다. "개발팀 입장에서는 일정이 부족합니다"는 부서의 어려움을 호소하는 것이고, "회사 전체로 볼 때 이 일정에서 가장 큰 리스크는 품질입니다"는 조직의 의사결정에 기여하는 것이다.

다른 부서의 문제에 먼저 나서는 것도 연습이 된다. 마케팅팀이 어려움을 겪고 있을 때 "그건 마케팅 이슈니까"라고 넘기는 대신 "우리 팀에서 도울 수 있는 부분이 있을까"라고 묻는다. 이것은 선의만의 문제가 아니다. 마케팅의 문제가 해결되지 않으면 회사 전체의 점수가 내려가고, 그것은 곧 내 점수이기도 하다.

그리고 결정이 내려진 후에는 그것을 진심으로 지지해야 한다. 리더십 미팅에서 충분히 토론한 뒤 결정이 내려지면, 설령 내가 원래 다른 의견이었더라도 부서로 돌아가서 그 결정을 적극적으로 지지해야 한다. "나는 반대했는데 그렇게 결정됐다"라고 말하는 순간, 리더십팀의 결정은 힘을 잃는다. 팀원들은 리더십팀이 하나의 팀이 아니라 각자 따로 노는 집단이라고 느끼게 된다.

이 모든 연습의 밑바닥에는 하나의 자각이 깔려 있다. 리더는 조직에서 임명된 사람만을 의미하지 않는다. 변화를 만들어내는 모든 사람이 리더다. 직급이 주어지기 전에도 문제를 이해하고, 동료의 아이디어에 귀 기울이고, 품질에 대해 타협하지 않는 사람은 이미 리더로서 행동하고 있는 것이다.

리더십팀이 하나의 팀으로 작동하기 시작하면, 자연스럽게 다음 질문이 떠오른다. 그렇다면 이 팀이 합의해야 할 것은 무엇인가. 리더들이 대사의 자리를 내려놓고 조직의 리더로 섰다면, 그다음으로 필요한 것은 모두가 같은 답을 할 수 있는 명료함이다.

미션보다 명료함

Wed, 01 Apr 2026 00:00:00 GMT

리더들이 부서의 대사가 아니라 조직의 리더로 서기 시작했다고 하자. 회의실에서 "우리 팀 입장에서는"이라는 말 대신 "회사 전체로 볼 때"라는 말이 나오기 시작했다. 좋은 출발이다. 하지만 곧 다음 질문이 찾아온다. 조직의 리더로 사고하겠다는 마음은 먹었는데, 도대체 무엇에 대해 함께 사고해야 하는가? 그 "무엇"이 불분명하면, 아무리 훌륭한 태도도 방향 없이 떠돈다.

많은 조직이 이 문제를 미션 선언문으로 해결하려 한다. 그리고 대부분 실패한다.

로비에 걸린 문장

어느 회사의 로비에서 액자를 본 적이 있다. 깔끔한 프레임 안에 정성스러운 서체로 인쇄된 한 문장이 있었다. 고객에게 최고의 가치를 제공하고, 세계적인 혁신을 통해 모든 이해관계자가 함께 성장하는 기업이 되겠다는 내용이었다. 읽는 데 10초가 걸렸다. 다 읽은 뒤에도 이 회사가 무엇을 하는 회사인지 알 수 없었다. 그 앞을 지나는 직원들 중 발걸음을 멈추고 그 문장을 읽는 사람은 아무도 없었다. 읽었다 해도 달라질 것은 없었을 테지만.

재미있는 사실이 하나 있다. 미국 드라마 <더 오피스>에 등장하는 허구의 제지 회사 던더 미플린에는 이런 미션 선언문이 있다. "고품질의 제품과 서비스를 통해 고객의 삶에 가치를 더하며, 직원들과 장기적인 유대 관계를 구축하여 자부심을 갖고 안정적으로 업무에 임할 수 있게 한다." 기업 문화를 풍자하기 위해 코미디 작가들이 만든 문장이다. 그런데 이 문장을 실제 기업 로비에 걸어놓으면, 아무도 가짜라고 눈치채지 못할 것이다.

이것은 특정 기업의 문제가 아니다. 미션 선언문이라는 형식 자체가, 진짜로 의미 있는 말을 담기 어려운 구조를 가지고 있다는 뜻이다.

한 문장이라는 함정

미션 선언문은 왜 실패하는가. 근본적인 원인은 욕심이다.

하나의 문장 안에 너무 많은 것을 담으려 한다. 영감을 주면서 동시에 정보를 전달하고, 동기를 부여하면서 시장 포지셔닝까지 규정하려 한다. 그 결과 어떤 것도 제대로 해내지 못하는 문장이 탄생한다. "고객에게 최고의 만족을 제공하며..." — 이 세상에 고객에게 최고의 만족을 제공하지 않겠다고 선언하는 기업이 어디 있겠는가. 이런 문장은 아무것도 규정하지 못한다. 경쟁사와의 차별점도, 지금 우리가 무엇에 집중해야 하는지도 말해주지 않는다.

만드는 과정도 문제다. 경영진이 모여 각자의 바람을 한 문장에 우겨넣는다. 마케팅 담당은 고객 가치를 넣고 싶어하고, 재무 담당은 주주 가치를 넣고 싶어하고, 인사 담당은 직원 성장을 넣고 싶어한다. 그렇게 모두의 소망이 담긴 장문의 선언문이 나온다. 누구도 반대하지 않지만, 누구에게도 영감을 주지 못하는 문장. 이 문장을 회사 로비에 걸고, 티셔츠에 인쇄하고, 연례 보고서 첫 페이지에 넣는다. 그리고 다음 날부터 아무도 신경 쓰지 않는다.

더 본질적인 문제가 있다. 미션 선언문은 태생적으로 대화를 끝내기 위한 도구다. "자, 이 문장에 합의했으니 넘어갑시다." 하지만 조직의 명료함은 대화를 끝내는 것이 아니라, 충분히 깊은 대화를 나누는 과정에서 만들어진다. 리더들 사이에 생각의 차이가 조금이라도 남아 있으면, 그 차이는 조직 아래로 내려갈수록 증폭된다. 리더 간의 미묘한 불일치가 부서 간의 끝없는 논쟁이 되고, 구성원들은 일관된 메시지를 받지 못해 각자의 방향으로 흩어진다.

멋진 한 문장이 아니라, 다른 무엇이 필요했다.

다섯 명의 리더, 다섯 개의 답

리더십 미팅에서 한 가지 질문을 던진 적이 있다.

"우리 조직에서 지금 가장 중요한 것이 뭔가요?"

간단한 질문이었다. 그런데 다섯 명의 리더에게서 다섯 개의 다른 답이 나왔다. 한 명은 채용이라 했고, 한 명은 기술 부채 해소라 했고, 한 명은 신규 기능 출시, 한 명은 고객 이탈 방지, 한 명은 팀 문화 개선이라 했다. 다섯 개의 답 모두 틀린 것은 아니었다. 하지만 다섯 개가 동시에 "가장 중요한 것"일 수는 없었다.

그 순간 깨달은 것이 있었다. 이 조직에는 전략도 있고, 유능한 사람도 있고, 열정도 있다. 하지만 명료함이 없었다. 그리고 명료함이 없는 조직에서는, 모두가 열심히 일하면서도 같은 방향으로 가고 있지 않다.

패트릭 렌시오니는 조직의 건강을 위해 리더십팀이 반드시 합의해야 할 여섯 가지 질문을 제시한다. 우리는 왜 존재하는가. 우리는 어떻게 행동하는가. 우리는 무엇을 하는가. 우리는 어떻게 성공할 것인가. 현재 가장 중요한 것은 무엇인가. 누가 무엇을 해야 하는가. 이 질문들을 처음 접하면 너무 기본적이라는 생각이 든다. 이걸 모르는 리더십팀이 어디 있겠는가. 하지만 핵심은 "아는 것"이 아니다. 핵심은 "모두가 같은 답을 할 수 있는가"이다.

각자 머릿속에 답이 있는 것과, 리더 전원이 동일한 답을 명료하게 말할 수 있는 것은 전혀 다른 상태다. 전자는 개인의 확신이고, 후자는 조직의 명료함이다. 대부분의 조직은 전자에 머물러 있다.

여섯 개의 문, 하나의 복도

이 여섯 가지 질문을 하나의 복도에 있는 여섯 개의 문이라고 생각해보자.

"우리는 왜 존재하는가"는 가장 안쪽의 문이다. 돈을 버는 것 너머, 이 조직이 세상에 존재해야 하는 이유. 이 문이 닫혀 있으면 나머지 문들을 열어봐야 의미가 없다. "우리는 어떻게 행동하는가"는 문화의 문이다. "혁신적이고 고객 중심적이며"라는 범용 표현이 아니라, 경쟁사와 구별되는 우리만의 행동 방식. "우리는 무엇을 하는가"는 가장 단순해 보이지만 의외로 합의가 어려운 문이다. 조직이 하는 일을 한 문장으로 설명할 수 있는가. 부서마다 다른 설명을 하고 있지는 않은가.

그런데 이 여섯 개의 문 중에서, 내 경험상 가장 격렬한 논쟁이 벌어지는 문이 있다. "현재 가장 중요한 것은 무엇인가"라는 집중의 문이다. 중요한 것은 항상 여러 개다. 그중 하나만 고르라는 것은 나머지를 포기하라는 것처럼 느껴진다. 채용도 중요하고 기술 부채도 중요하고 신규 기능도 중요하다. 하지만 모든 것이 중요하면, 아무것도 중요하지 않은 것과 같다. 앞서 다섯 명의 리더에게서 다섯 개의 답이 나왔던 것도 바로 이 문 앞에서였다.

"우리는 어떻게 성공할 것인가"는 전략의 문이다. 같은 산업의 경쟁사들 사이에서, 우리가 의식적으로 선택한 차별화 포인트. 그리고 "누가 무엇을 해야 하는가"는 실행의 문이다. 앞의 다섯 가지 답이 아무리 명료해도, 구체적인 역할과 책임이 정해지지 않으면 아무 일도 일어나지 않는다.

여섯 개의 문 중 하나라도 닫혀 있으면, 복도 전체가 어두워진다. 한 가지 질문에 대해서라도 리더들 사이에 생각의 차이가 존재하면, 그 불일치는 조직 전체의 명료함을 잠식한다.

왜 답하지 못하는가

이 질문들에 답하지 못하는 이유는 리더들의 능력이 부족해서가 아니다. 모든 리더십팀은 이 질문들에 답할 수 있을 만큼의 정보와 경험을 이미 가지고 있다. 문제는 다른 곳에 있다.

첫째, 진짜 대화가 부족하다. 여섯 가지 질문에 답하려면, 리더들이 서로의 생각을 솔직하게 꺼내고 부딪힐 수 있어야 한다. 하지만 많은 리더십팀에서는 의견이 다를 때 "서로 다른 의견을 갖기로 합의"하고 넘어간다. 그것이 성숙한 태도라고 생각하면서. 그러나 이 "합의된 불일치"는 조직 아래로 내려갈수록 혼란이 되어 돌아온다. 한 리더가 "속도"를 강조하고 다른 리더가 "품질"을 강조하면, 그 아래의 구성원들은 어느 쪽을 따라야 할지 알 수 없다.

둘째, 마케팅적 접근의 유혹이 있다. 이 질문들에 답할 때, 리더들은 쉽게 그럴듯한 문구를 만들려 한다. 외부에 보여주기 좋은 인상적인 한 줄. 하지만 이 질문들의 답은 마케팅 카피가 아니다. 리더 전원이 진심으로 동의하고, 일상의 의사결정에서 반복적으로 활용할 수 있는 명료한 합의여야 한다.

셋째, 시간이 필요하다. 이 답들은 한 번의 워크숍으로 완성되지 않는다. 며칠이 아니라 몇 주간의 대화가 필요할 수 있다. 답이 나온 후에도 시간을 두고 다시 검토하며, 전원이 충분히 이해하고 동의하는지 확인해야 한다. 리더들은 바쁘다. 그래서 이 과정을 단축하려는 유혹에 빠진다. 하지만 합의의 깊이를 단축하면, 나중에 실행의 혼란으로 그 시간을 몇 배로 치르게 된다.

정확함보다 헌신

이 질문들에 대해 가장 흔한 오해가 있다. "완벽한 답을 찾아야 한다"는 생각이다.

하지만 실제로는 다르다. 80%의 정확도를 가진 답에 리더 전원이 100% 헌신하는 것이, 100%의 정확도를 가진 답에 절반만 동의하는 것보다 훨씬 강력하다. 조직에서 실행력은 답의 완벽함이 아니라 합의의 깊이에서 나오기 때문이다. 모든 리더가 같은 메시지를 자기 팀에 전달하고, 같은 기준으로 의사결정을 하고, 같은 우선순위로 자원을 배분할 때 비로소 조직은 하나의 방향으로 움직인다.

완벽한 전략을 세우는 데 석 달을 쓰고도 리더들 사이에 해석의 차이가 남아 있다면, 그 전략은 이미 실패한 것이다. 반대로, 다소 거칠더라도 리더 전원이 "이것이 지금 우리의 답"이라고 같은 목소리를 낼 수 있다면, 조직은 놀라울 만큼 빠르게 정렬된다.

이것은 내가 직접 겪으면서 확인한 것이기도 하다. 우리 팀에서 이 질문들을 처음 다뤘을 때, 나는 완벽한 답을 만들려고 했다. 누구도 반박할 수 없는, 논리적으로 빈틈없는 답. 하지만 정작 중요한 것은 그 답이 얼마나 정교한가가 아니라, 모두가 그 답을 자기 것으로 받아들이는가였다. 회의실을 나서는 순간 "글쎄, 나는 좀 다르게 생각하는데"라고 속으로 중얼거리는 사람이 한 명이라도 있다면, 그 합의는 합의가 아니다.

액자를 바꿀 것인가, 대화를 바꿀 것인가

많은 조직이 명료함의 부재를 느낄 때 가장 먼저 하는 일은, 새로운 미션 선언문을 만드는 것이다. 더 멋진 단어를 고르고, 더 세련된 문장을 다듬어서, 더 예쁜 액자에 넣는다. 하지만 로비의 액자를 아무리 바꿔도, 리더들의 대화가 바뀌지 않으면 조직의 명료함은 달라지지 않는다.

필요한 것은 새로운 선언문이 아니라 새로운 대화다. 리더들이 같은 방에 앉아서, 불편하더라도 서로의 생각 차이를 드러내고, 그 차이를 좁혀가는 과정. 완벽한 한 문장보다, 리더 모두가 같은 말을 할 수 있는 상태가 훨씬 강력하다. 미션 선언문은 벽에 걸기 위한 것이지만, 진짜 명료함은 사람들의 머릿속에 새겨지는 것이다.

그런데 여기서 한 가지 질문이 남는다. 리더들이 여섯 가지 질문에 합의했다고 하자. 같은 답을 말할 수 있는 상태가 되었다고 하자. 그 합의는 어떻게 유지되는가? 시간이 지나면 해석이 벌어지고, 상황이 바뀌면 우선순위가 흔들린다. 합의가 흐트러지는 순간을 누가, 어떻게 포착하는가? 명료함을 만드는 것만큼이나, 명료함을 지키는 것에도 용기가 필요하다. 동료에게 불편한 말을 건넬 수 있는 용기 말이다.

What과 How 사이에서

Wed, 01 Apr 2026 00:00:00 GMT

스프린트가 끝났다. 개발자들에게 할 일이 없다.

기획은 아직 나오지 않았고, 디자인은 리뷰 중이다. 백로그에는 "추후 논의"라는 딱지가 붙은 티켓들만 쌓여 있다. 이상한 일이었다. 팀의 실행 속도는 분명히 빨라졌다. 예전에 2주가 걸리던 기능을 며칠 만에 끝낸다. 그런데 팀 전체의 체감 속도는 오히려 느려졌다. 엔지니어들은 손이 비고, PM과 디자이너는 숨이 가쁘다. 실행이 빨라졌는데 팀이 느려지는 이 역설은 대체 어디에서 오는 걸까.

앞선 챕터들에서 사람을 다루는 기술 — 공정함, 피드백, 장면을 보여주는 매니지먼트 — 을 이야기했다. 사람 사이의 신뢰가 확보되었다면, 이제 질문은 자연스럽게 "일"로 옮겨간다. 이 팀이 무엇을, 어떤 구조로 할 것인가. 이 챕터는 그 질문에 대한 탐색이다.

How가 공짜가 되어가는 세상

지난 몇 년간 "만드는 비용"은 극적으로 줄었다. AI 코딩 도구, 자동화 파이프라인, 코드 생성기. 과거에 시니어 개발자 두 명이 2주를 매달려야 했던 기능을, 이제는 주니어 한 명이 3일이면 구현한다. 과장이 아니다. 실제로 수많은 팀에서 벌어지고 있는 현실이다.

How — 어떻게 만들 것인가 — 의 비용이 빠르게 0에 수렴하고 있다. 구현은 점점 쉬워지고, 같은 결과물을 내는 데 필요한 사람과 시간은 줄어든다. 기술의 진보다. 분명히 축하할 일이다.

그런데 한 가지 비용은 전혀 줄지 않았다. What — 무엇을 만들 것인가 — 를 결정하는 비용이다. 어떤 문제를 풀어야 하는지 파악하고, 아이디어를 구체화하고, 방향을 설정하는 데 걸리는 시간과 에너지는 여전히 그대로다. 오히려 선택지가 늘어나면서 의사결정의 무게는 더 커졌다.

How는 점점 싸지는데, What은 여전히 비싸다. 이 비대칭에서 역설이 시작된다.

개발자의 생산성이 높아지면 팀이 더 많은 것을 만들어야 정상이다. 하지만 현실은 그렇지 않다. 엔지니어들의 손이 빈다. 게으른 것이 아니다. 실행할 거리가 없는 것이다. What이 공급되는 속도보다 How가 소화하는 속도가 압도적으로 빨라졌기 때문이다. PM과 디자이너가 기획하고 검증하는 속도 자체가 병목이 되어버렸다.

이때 기업에게는 두 가지 선택지가 놓인다.

첫째, 병목 포지션을 충원한다. PM이나 디자이너를 더 뽑아서 What의 처리량을 늘린다.

둘째, 개발자를 줄인다. How의 처리량을 What의 공급 속도에 맞춘다.

논리적으로는 첫 번째가 맞다. 그러나 현실에서 두 번째가 압도적으로 쉽다. 적합한 PM이나 디자이너를 찾는 것은 정말 어려운 일이다. 비용의 문제가 아니라, 우리 제품과 시장을 깊이 이해하면서 동시에 문제 정의 능력을 갖춘 사람을 찾는 것 자체가 난제다. 반면 개발자를 줄이는 것은 숫자 계산만으로 결정할 수 있다.

그래서 많은 기업이 구조조정을 택한다. 실행력이 높아질수록, 실행하는 사람의 자리가 위태로워지는 역설. 빨라진 실행이 느려진 팀을 만들고, 느려진 팀이 더 적은 사람을 요구한다. 지난 몇 년간 테크 업계를 뒤흔든 대규모 구조조정의 이면에는 이 구조적 원인이 자리하고 있다.

How만 잘하는 사람은 대체 가능해진다. 이 문장이 불편할 수 있다. 하지만 외면해서는 안 되는 현실이다.

What에 참여하는 엔지니어

그렇다면 이 역설을 어떻게 깨뜨릴 수 있을까. 핵심은 What을 PM과 디자이너만의 영역으로 두지 않는 데 있다. 문제 파악, 아이디에이션, 방향 설정 — 이 과정에 엔지니어를 포함한 팀 전체가 참여해야 한다.

볼타에서는 세 가지 방식으로 이를 실천했다.

첫째, 고객 문의를 함께 본다. 고객이 어떤 문제로 문의를 넣는지, 어떤 기능을 예상과 다르게 사용하는지를 엔지니어가 직접 확인한다. 예컨대 단순 알림용으로 설계한 웹훅을 고객이 자체 자동화 파이프라인의 핵심 트리거로 활용하고 있다면 — 그것은 엔지니어가 가장 먼저, 가장 정확하게 포착할 수 있는 종류의 신호다. 코드를 만든 사람이 코드의 예상 밖 쓰임새를 가장 잘 읽는다.

둘째, 벤치마크 세션을 함께 한다. 경쟁사 분석, 시장 리서치를 PM만의 업무로 두지 않는다. 팀 전체가 주기적으로 시장을 함께 들여다본다. 엔지니어의 관점에서 보이는 기술적 가능성이 전혀 다른 아이디어를 촉발하기도 한다.

셋째, 프로토타이핑으로 아이디에이션에 기여한다. 피그마 목업을 기다리는 대신, 실제로 동작하는 프로토타입을 빠르게 만들어서 팀의 논의를 앞당긴다. How가 저렴해진 세상에서 프로토타입의 비용은 거의 0이다. 이미 구현 능력을 가진 사람이 아이디어 단계에서부터 손을 움직이면, 논의의 속도와 깊이가 완전히 달라진다.

이것은 엔지니어에게 위협이 아니라 기회다. 과거에는 구현에 모든 시간을 쏟느라 기획에 참여할 여유가 없었다. 지금은 실행 시간이 줄어든 만큼 What에 참여할 시간이 생겼다. 줄어든 시간을 어떻게 쓸 것인가가 개인의 가치를 결정한다.

1/3 법칙: What과 How를 교차하는 운영 구조

What에 참여하는 것만으로는 부족하다. 운영 구조 자체가 바뀌어야 한다.

가장 흔한 실수는 같은 문제에 대한 What과 How를 하나의 스프린트 안에서 동시에 진행하는 것이다. 이번 스프린트에 문제를 파악하면서, 동시에 그 해결책을 구현하려 한다. 이러면 반드시 블로킹이 생긴다. What이 늦어지면 How가 멈추고, How가 멈추면 엔지니어가 다시 손이 빈다. 앞에서 이야기한 역설이 스프린트 단위로 반복되는 것이다.

더 큰 문제는 리스크다. What 단계에서 방향이 틀어지면, 같은 스프린트에서 이미 진행 중이던 How 작업이 통째로 소실된다. 스프린트의 상당 부분을 한순간에 잃는 셈이다.

해법은 교차 운영이다. 이를 "1/3 법칙"이라 부른다.

스프린트의 1/3은 미래의 What에 투자한다. 아직 정의되지 않은 문제를 파악하고, 싱크하고, 아이디에이션한다. 나머지 2/3는 이미 정의된 What의 How를 실행한다. 지난 스프린트에서 충분히 검증해둔 것들을 만드는 데 집중한다.

흐름은 이렇다.

S1: 문제 A 파악 + 아이디에이션
S2: 문제 A 실행 + 문제 B 파악
S3: 문제 B 실행 + 문제 C 파악

이 구조의 핵심은 손실의 격리에 있다. S1에서 문제 A의 방향이 잡히지 않더라도, S1에서 실행하고 있는 것은 이전 스프린트에서 이미 검증된 다른 문제의 How다. What이 실패해도 How의 리소스가 날아가지 않는다. 반대로 How가 예상보다 빨리 끝나면, 미리 진행 중이던 What 작업 덕분에 다음 실행으로 곧바로 넘어갈 수 있다.

교차 운영에는 약간의 리드 타임이 필요하다. 다음 달 초에 실행할 것의 What을 이번 달부터 시작해야 한다. 하지만 이 선행 투자가 팀 전체의 블로킹을 제거한다. 엔지니어가 손이 비는 순간이 사라지고, PM과 디자이너에게 집중되던 병목이 완화된다.

직관을 훈련하는 팀

What을 잘하려면 직관이 필요하다. 고객의 문의 한 줄을 읽었을 때 "같은 문제를 겪고 있을 다른 고객사가 어디인지" 바로 떠올릴 수 있는 수준. 별도의 리서치 없이도 "이건 진짜 문제일 수 있겠다"라는 판단이 서는 수준.

이것은 타고나는 능력이 아니다. 훈련으로 만들어진다.

볼타에서는 네 가지 방식으로 직관을 훈련한다.

외부 고객에 대한 이해. 우리 고객이 어떤 비즈니스를 하고, 어떻게 수익을 만들고, 어떤 고민을 안고 있는지를 아는 것이다. 경조사, 신규 사업, 채용, 구조조정까지. 고객의 맥락을 깊이 알수록 문의 한 줄에서 읽어내는 것의 깊이가 달라진다.

내부 고객 — 팀원 — 에 대한 이해. 같은 팀의 구성원이 어떤 강점을 가지고 있고, 어떤 영역에 도전하고 싶어하는지를 아는 것이다. 새로운 문제가 포착되었을 때 누구에게 맡길지, 어떻게 나눌지 판단하는 것도 직관이다. 사람에 대한 이해 없이는 문제를 정의해도 실행으로 연결되지 않는다.

시장에 대한 이해. 경쟁사, 법령, 글로벌 트렌드. 이 맥락이 없으면 어떤 문제가 풀 만한 가치가 있는 문제인지 판단할 수 없다. 경쟁사의 과거 시행착오도 귀중한 학습 자료다. 현재의 UX나 기능을 참고하는 것이 아니라, 그들이 왜 그 선택을 했고 어디에서 어려움을 겪었는지를 읽는 것이다.

예상치 못한 사용의 관찰. 우리가 A를 위해 만든 기능을 고객이 B에 쓰고 있다면, 거기에 의외의 기회가 숨어 있다. 이런 신호는 제품을 만든 사람이 가장 먼저 감지할 수 있다. 코드를 작성한 사람만이 설계 의도와 실제 사용 사이의 간극을 정확히 이해하기 때문이다.

데이터를 경시하자는 이야기가 아니다. 데이터 분석은 어느 정도 규모의 팀이라면 누구나 할 수 있다. 좋은 도구가 많아졌고 방법론도 표준화되었다. 하지만 실무에서 마주하는 대부분의 상황에는 참고할 만한 정량적 데이터가 없다. 새로운 시장에 진출할 때, 경쟁사가 예상 밖의 움직임을 보일 때, 과거 데이터는 별로 도움이 되지 않는다. 데이터 없는 상황에서 판단할 수 있는 것은 오직 훈련된 직관뿐이다. 직관으로 빠르게 가설을 세우고, 데이터로 검증하며, 그 경험이 다시 직관을 더 예리하게 만드는 선순환. 그것이 What을 잘하는 팀의 기반이다.

"신입 PM은 없다"는 표현이 있다. 직관이 쌓이는 데 시간이 걸리기 때문이다. PM이라는 직군이 아무나 할 수 없다는 뜻이 아니다. 고객과 시장과 제품에 대한 깊은 이해를 기반으로 한 직관은 하루아침에 생기지 않는다는 뜻이다. 그리고 이 말은 PM에게만 해당되지 않는다. What에 참여하려는 모든 사람 — 엔지니어든 디자이너든 — 에게 똑같이 적용된다.

직관이 충분히 훈련된 팀은 탑다운으로 사고한다. "이 기능을 만들면 나아지겠지?"라는 바텀업이 아니라, "목표를 달성하려면 어떤 문제를 풀어야 하는가?"에서 출발한다. 목표에서 역산하되, How가 아닌 What과 Why에 먼저 집중한다. 실행 방법은 그다음이다. 올바른 문제를 정의하는 것이 올바른 해결책을 구현하는 것보다 언제나 앞선다.

더 잘 정의하는 팀

How가 공짜가 되어가는 흐름은 되돌릴 수 없다. 실행 비용은 앞으로도 계속 줄어들 것이고, 같은 일을 하는 데 필요한 사람은 점점 적어질 것이다.

이때 살아남는 팀은 "더 빨리 만드는 팀"이 아니라 "더 잘 정의하는 팀"이다. 잘 정의하는 것은 특정 직군 한두 명의 역할이 아니라, 제품팀 전체의 역량이다. 그리고 그 역량은 개인의 직관 훈련과 팀의 운영 구조가 함께 뒷받침할 때 비로소 작동한다.

줄어든 실행 시간을 위협으로 볼 수도 있고, 기회로 볼 수도 있다. 그 시간을 What에 참여하는 데 쓴다면, 이것은 모든 구성원에게 더 넓은 영역에서 기여할 수 있는 기회가 된다. 1/3 법칙으로 구조를 잡고, 직관을 훈련하여 문제 정의의 깊이를 높이고, 팀 전체가 What에 참여하는 문화를 만든다. 그것이 빨라진 실행 시대에 작은 팀이 택할 수 있는 가장 현명한 전략이다.

일의 구조를 세웠다면, 그 안에서 뛰는 사람은 괜찮은 걸까. 빠르게 돌아가는 스프린트, 촘촘한 실행 주기, 끊임없는 문제 정의. 이 리듬 속에서 개인이 지치지 않으려면 무엇이 필요한가. 구조가 아무리 좋아도, 그 안의 사람이 무너지면 아무 소용이 없다.

공정함은 과정에서 온다

Wed, 01 Apr 2026 00:00:00 GMT

어떤 말을 해야 하는지 아는 것과, 그 말이 상대에게 닿게 하는 것은 전혀 다른 문제다. 피드백의 내용이 아무리 정확해도, 그것이 전달되는 방식과 그 밑에 깔린 구조가 신뢰를 받지 못하면 아무것도 바뀌지 않는다. 팀원이 피드백을 수용하려면, 먼저 이 조직이 나를 공정하게 대한다는 감각이 있어야 한다. 그 감각은 어디에서 오는 걸까.

연봉 협상이 끝난 뒤

연봉 협상이 끝나면 사람들은 곧장 옆자리 동료에게 눈짓을 보낸다. 직접 묻지는 않는다. 대신 표정을 읽는다. 그 미세한 시선의 교환 속에서 자기 위치를 가늠한다.

흥미로운 점은, 그렇게 가늠하는 대상이 금액이 아니라 과정이라는 사실이다. 숫자는 의외로 빨리 잊힌다. 하지만 그때 들었던 — 혹은 듣지 못했던 — 말은 오래 남는다. "이번에 이 정도로 결정됐어." 그 한마디가 전부였던 순간. 왜 그 숫자인지, 어떤 기준을 적용했는지, 내 성과가 어떻게 반영되었는지에 대한 설명이 아무것도 없었던 그 순간이 수년이 지나도 선명하다.

돌이켜보면, 조직에서 가장 불편했던 순간은 결과가 나빴을 때가 아니었다. 결정이 내려진 뒤에야 알게 되었을 때였다. 내가 알 수 없는 어딘가에서 이미 모든 것이 정해져 있었다는 걸 깨달았을 때, 과정 자체에서 내가 존재하지 않았다는 사실이 결과보다 더 깊은 상처를 남겼다.

반대의 경험도 있다. 결과가 기대에 미치지 못했는데도 괜찮았던 적이 있다. 왜 이런 결정이 내려졌는지 설명을 들었을 때. 내 의견이 반영되지 않더라도, 적어도 고려는 되었다는 것을 느꼈을 때. 그때는 결과를 받아들일 수 있었다.

사람은 과정의 공정함에 더 예민하다

예일대의 톰 타일러는 이 현상을 '절차공정성'이라 불렀다. 사람들은 결과의 크기보다 그 결과에 이르는 과정이 공정했는지를 더 예민하게 감지한다는 것이다. 조직이 공정하려는 자세를 보이는지, 정직한지, 기회가 주어지는지, 결정의 질적 수준은 어떤지, 오류를 바로잡을 수 있는지, 편향이 없는지. 하나하나가 거창한 제도가 아니다. 결국 핵심은 단순하다. "당신은 이 결정에서 투명인간이 아닙니다"라는 메시지를 조직이 보내느냐의 문제다.

작은 팀이라고 해서 이것이 자동으로 해결되지는 않는다. 오히려 반대인 경우가 많다. 인원이 적으니 빠르게 결정해야 한다는 명분 아래 과정이 생략된다. 창업자의 직관이 곧 결정이 되고, 그 결정은 메시지 한 줄로 전달된다. 빠르다. 효율적이다. 하지만 거기에는 과정이 없다.

타운홀 미팅이 존재하는 이유가 여기에 있다. 임원들끼리 정하고 공지하면 끝날 일을 시시콜콜 설명하고 의견을 듣는 것은 비효율적으로 보인다. 하지만 그 비효율이 신뢰를 만든다. 신뢰는 감정이 아니라 구조에 가깝다. 감정은 흔들리지만 구조는 버틴다. 좋은 리더는 매력적인 사람이 아니라, 신뢰할 수 있는 구조를 설계하는 사람이다.

리더로서 결정을 내리기 전에 한 번 더 생각하는 습관이 생겼다. 이 결정을 공유하지 않아도 될 사람이 정말 없는지. 경험상, 그 범위는 내가 생각한 것보다 항상 넓다. 공정함은 정답을 찾는 문제가 아니라, 과정을 열어두려는 태도에서 시작된다.

장면이 명령을 이긴다

공정한 과정이라는 토대가 깔리면, 그 위에서 사람을 움직이는 방식도 달라져야 한다. 피드백이든, 가이드라인이든, 방향 제시든 — 핵심은 명령이 아니라 장면을 보여주는 것이다.

아이에게 "장난감 치워"라고 말하면 십중팔구 꿈쩍도 하지 않는다. 하지만 장난감 하나를 집어 들고 "이건 어디에 두면 돼?"라고 물으면, 아이가 직접 와서 알려준다. "이건 여기, 이건 저기." 어느새 스스로 치우고 있다. 아무도 치우라고 명령하지 않았는데.

명령은 외부 동기를 만든다. 보상이 있으니까, 혼나기 싫으니까, 그냥 시키니까 하는 것. 이런 동기는 빠르게 작동하지만 감시가 사라지면 행동도 사라진다. 반면 장면은 내부 동기를 만든다. 스스로 판단하고, 자기 문제라고 느끼고, 선택했기 때문에 하는 것. 이 동기는 느리게 시작하지만 훨씬 오래 지속된다.

코드 리뷰에서 이 차이가 극명하게 드러난다. "이 코드는 좋지 않습니다. 수정해주세요"라는 코멘트를 받으면 방어적이 된다. 하지만 "이 함수가 호출되는 시점에 connection pool이 소진된 상태라면 어떻게 될까요?"라는 코멘트를 받으면 생각하게 된다. 전자는 명령이고 후자는 장면이다. 후자는 상대의 머릿속에 특정 시나리오를 그려주고, 스스로 문제를 발견하게 만든다.

추상적인 지시도 마찬가지다. "코드 품질을 높여주세요"라고 말하면 듣는 사람의 머릿속에 아무런 그림도 떠오르지 않는다. 하지만 "지난주 결제 모듈 PR에서 에러 핸들링이 빠진 부분이 세 곳 있었어요"라고 말하면 구체적인 장면이 떠오르고, 무엇을 해야 하는지 선명해진다. 고유명사가 가진 힘이다. 이름, 날짜, 장소, 상황 — 이런 구체성이 머릿속에 장면을 그리고, 장면이 그려지면 행동이 따라온다.

실수를 다루는 방식에서도 장면의 원리는 작동한다. "테스트 코드를 꼭 작성하세요"라고 열 번 말하는 것보다, 안전한 범위 안에서 테스트 없이 배포했다가 장애를 경험하게 하는 것이 더 효과적이다. 다만 중요한 건, 실수 후에 "그것 봐, 내가 뭐라고 했어"라고 말하지 않는 것이다. 체험 직후에 필요한 것은 지적이 아니라 질문이다. "어떻게 된 것 같아?" "다음에는 어떻게 하면 좋을까?" 결론을 내 입으로 말하는 순간, 그것은 상대의 깨달음이 아니라 나의 잔소리가 된다.

존재감이 사라지는 것이 최고의 성과

명령하는 매니저는 팀이 자기 없이 움직이지 못하게 만든다. 모든 결정이 매니저를 거쳐야 하고, 모든 판단에 승인이 필요하다. 매니저의 존재감은 높아지지만 팀의 자율성은 죽는다. 장면을 만드는 매니저는 다르다. 결정을 내려주는 대신 결정에 필요한 맥락을 보여주고, 답을 알려주는 대신 답에 이르는 질문을 던진다.

공정한 과정이라는 토대 위에서, 장면이라는 도구를 사용하면 팀은 자율적으로 움직이기 시작한다. 명령은 순간의 행동을 만들지만, 장면은 지속적인 판단력을 만든다. 답을 줄수록 의존이 생기고, 장면을 줄수록 자율이 생긴다. 그래서 가장 좋은 매니저는, 역설적이게도, 팀이 자기 없이도 잘 돌아가게 만드는 사람이다.

사람을 다루는 기술 — 채용, 리더십, 명료함, 피드백, 공정함 — 을 이야기해왔다. 하지만 조직은 사람만으로 작동하지 않는다. 사람 사이에 일이 있고, 그 일에는 구조가 필요하다. 무엇을 할 것인가와 어떻게 할 것인가를 분리하는 기술, 그리고 빠르게 판단하는 직관을 키우는 훈련. 사람을 넘어 일의 구조로, 이야기를 이어가 보자.

제품에 철학을 담다

Wed, 01 Apr 2026 00:00:00 GMT

2막에서 우리는 팀의 내부를 들여다보았다. 누구와 함께할 것인가, 어떻게 이끌 것인가, 무엇을 명료하게 할 것인가, 어떻게 피드백하고 공정함을 세울 것인가, 일의 구조를 어떻게 짤 것인가, 그리고 그 안에서 어떻게 지치지 않을 것인가. 이 모든 질문은 결국 하나의 지점으로 수렴한다. 그래서 그 팀이 무엇을 만드는가.

팀 운영의 원칙이 아무리 정교해도, 그것이 제품에 반영되지 않으면 의미가 반감된다. 조직의 철학은 슬라이드에 적히는 것이 아니라 제품을 통해 세상에 드러난다. 3막의 시작은 여기서부터다. 시야를 팀 내부에서 외부로 돌려, 우리가 만드는 것에 어떤 생각이 담기는지를 이야기하려 한다.

잘 팔면 되는 거 아닌가

B2B 사업을 하다 보면 빠지기 쉬운 함정이 있다. "결국 잘 팔면 되는 거 아닌가?"라는 생각이다. 영업 조직이 리드를 확보하고, 데모를 보여주고, 가격을 제안하고, 계약을 따내는 흐름. 혹은 제품이 스스로 말하게 하여, 사용자가 직접 검색하고 비교하고 체험한 뒤 결제하는 흐름. 어느 쪽이든 핵심은 같다고 생각하기 쉽다. 매출이 늘면 성장이고, 성장하면 성공이라고.

그런데 여기서 한 가지를 놓치면 모든 것이 어긋난다. B2B 제품에는 구매자와 사용자가 다른 경우가 대부분이다. 구매 결정을 내리는 사람은 임원이고, 매일 그 제품 앞에 앉아 일하는 사람은 실무자다. 영업이 아무리 뛰어나도, 데모가 아무리 화려해도, 매일 그것을 쓰는 사람이 효용을 느끼지 못하면 그 계약은 다음 해에 갱신되지 않는다.

어떤 방식으로 성장하든 결국 고객이 최대의 효용을 느껴야 한다. 이것은 당연한 말처럼 들리지만, 실제로 이 원칙을 지키는 것은 놀라울 만큼 어렵다.

초기 스타트업에서 흔히 벌어지는 일이 있다. 큰 고객이 들어오면 그 고객의 요구사항을 맞춰준다. 다음 고객이 들어오면 또 그 고객에게 맞춘다. 이런 식으로 몇 번을 반복하면, 어느 순간 제품이 프랑켄슈타인이 되어 있다. 각 고객의 요구를 따로따로 이어붙인 결과물. 전체를 관통하는 설계 원칙은 사라지고, 누구의 문제도 깊이 있게 풀지 못하는 기형적인 무언가가 남는다. 돌이킬 수 없는 수준까지 가고 나서야 문제를 인식하는 경우도 적지 않다.

볼타가 기업 금융의 비효율을 최적화하는 B2B 핀테크 SaaS를 만들어 나가면서 계속 되뇌었던 것은, 사업적 성공과 제품의 완성도가 양립할 수 있어야 한다는 믿음이었다. 고객의 요구에 끌려다니는 것이 아니라, 고객이 아직 말하지 못한 문제까지 꿰뚫는 제품을 만들겠다는 욕심. 이것은 단순한 이상론이 아니다. 새로운 기능이 추가될 때마다 사용자가 별도의 학습 없이 스스로 이해할 수 있어야 한다는 구체적인 기준으로 작동하는 원칙이다.

그리고 이 원칙을 지키려면, 제품을 만드는 사람들이 가장 본능적으로 원하는 것 하나를 내려놓아야 한다.

사용자를 붙잡지 않는 용기

제품을 만드는 사람이라면 누구나 이런 욕망이 있다. 사용자가 오래 머물기를. 자주 돌아오기를. 떠나지 않기를. 사용 시간이 늘어나면 뿌듯하고, 활성 사용자 수가 올라가면 안심하고, 이탈률이 낮아지면 성공했다고 느낀다. 내가 만든 것에 사람들이 시간을 쓴다는 것은, 그것이 가치 있다는 증거처럼 보인다.

하지만 이 욕망이 설계를 지배하면 이상한 일이 벌어진다. 끝없이 스크롤되는 피드. 자동으로 재생되는 다음 영상. 끊임없이 울리는 알림. 이 장치들의 목적은 하나다. 사용자를 떠나지 못하게 만드는 것. 그런데 영화가 끝났는데 극장 문을 잠그고 다음 상영을 강제하면, 그곳은 극장이 아니라 감옥이 된다. 사용자의 시간을 점유하는 것과 사용자에게 가치를 주는 것은 전혀 다른 일이다. 이 둘을 혼동하는 순간, 제품은 사용자를 위한 도구가 아니라 사용자를 소비하는 기계로 변한다.

어린 시절 본 애니메이션의 마지막 회를 떠올려 본다. 모험이 끝나고 주인공이 일상으로 돌아가고, 석양이 지는 화면 위로 엔딩곡이 흐른다. 아쉽지만 동시에 충만한 그 감각. "이 이야기는 여기서 끝입니다"라는 신호가 지금까지의 체험을 하나의 완결된 덩어리로 만들어주었다. 끝이 있기 때문에 의미가 생겼다. 끝이 없었다면 그것은 이야기가 아니라 그냥 시간의 흐름이었을 것이다.

제품도 마찬가지다. 우리가 만드는 제품은 사용자 인생의 주인공이 아니다. 조연이다. 아무리 뛰어난 서비스라도 사용자의 하루 중 극히 일부만 차지한다. 그리고 그래야 한다. 좋은 조연은 주인공의 이야기를 돕고, 자기 역할이 끝나면 무대에서 내려온다. 사용자가 할 일을 끝내면 보내줘야 한다. 할 일 관리 앱은 모든 항목이 완료되면 빈 화면을 보여주며 "오늘은 끝났다"고 말해야 한다. 그 빈 화면이 사용자가 자기 인생의 다음 장면으로 넘어가는 문이다.

만드는 사람 입장에서 빈 화면은 무섭다. 사용자가 이탈할 수 있는 순간이기 때문이다. 그래서 빈 화면 대신 추천 콘텐츠를 넣고, 다음 목표를 제안하고, 무엇이든 하게 만들려 한다. 하지만 할 일을 다 한 사람을 억지로 붙잡는 것은, 집에 가겠다는 친구 앞에서 현관문을 막는 것과 같다. 한두 번은 괜찮을 수 있지만, 반복되면 그 집에 다시 가고 싶지 않아진다.

떠났다가 스스로 돌아오게 하는 것

멈출 수 있는 서비스에 사람들이 더 자주 돌아온다. 직관에 반하는 이야기지만, 곰곰이 생각하면 자연스러운 이치다.

넷플릭스의 자동 재생을 떠올려 보자. 에피소드가 끝나면 5초 후 다음 편이 시작된다. 멈추려면 적극적으로 행동해야 한다. 리모컨을 찾아 버튼을 눌러야 한다. 그 결과 의도보다 더 오래 시청하게 되고, 플랫폼의 시청 시간 지표는 올라간다. 하지만 그 시간이 끝난 후 남는 감정은 충만함이 아니라 후회다. "또 너무 오래 봤다." 이 후회가 반복되면 서비스를 여는 것 자체가 부담이 된다.

반대로 좋은 책은 챕터마다 자연스러운 멈춤 지점이 있다. 한 장을 읽고 책을 덮을 수 있는 여유. 그 여유가 있기 때문에 다음 날 다시 책을 집어든다. 읽다가 멈춘 것이 아쉬움이 되고, 그 아쉬움이 내일의 동력이 된다.

오래된 게임 디자인에서도 비슷한 통찰을 발견할 수 있다. 슈퍼 마리오 브라더스에는 워프 존이라는 것이 있다. 스테이지를 건너뛸 수 있는 숨겨진 통로다. 공들여 만든 스테이지를 건너뛰게 해주다니, 디자이너 입장에서는 모순적인 결정처럼 보인다. 하지만 워프 존이 있기 때문에, 플레이어는 자신이 이 게임을 통제하고 있다고 느낀다. 건너뛸 수 있지만 건너뛰지 않기로 선택하는 것. 그 선택이 체험의 질을 바꾼다. "나는 이 스테이지를 하고 싶어서 하고 있다"는 감각과 "이 스테이지를 할 수밖에 없다"는 감각은, 같은 행위를 전혀 다른 경험으로 만든다.

제품에서도 똑같은 원리가 작동한다. 사용자에게 선택지가 있다는 것은 자유가 있다는 것이고, 자유가 있다는 것은 자기 의지로 참여하고 있다는 것이다. 자기 의지로 참여한 경험은 기억에 남고, 강제된 경험은 소모된다.

리텐션의 진짜 의미는 여기에 있다. 사용자를 떠나지 못하게 하는 것이 아니라, 떠났다가 스스로 돌아오게 하는 것. 그러려면 먼저 떠날 수 있어야 한다. 자유를 주면 사용자가 떠날 수도 있다는 가능성을 감수하는 것은 용기가 필요한 일이다. 하지만 자유 속에서 남기로 선택한 사용자는, 붙잡혀서 머무는 사용자와는 비교할 수 없는 깊이의 관계를 맺는다.

팀의 철학이 제품이 된다

여기서 2막의 이야기가 다시 연결된다.

우리는 팀을 운영하면서 구성원의 자율성을 존중하는 법을 배웠다. 채용에서 함께한 적 없는 사람을 영입하는 역발상도, 리더가 부서의 대사가 아니라 조직 전체의 리더로 서는 것도, 피드백을 시스템으로 만드는 것도, 공정함을 과정에서 세우는 것도, What과 How를 분리하여 모든 구성원이 방향 설정에 참여하게 하는 것도 — 근저에 깔린 원칙은 하나였다. 사람을 통제하지 않고, 사람이 스스로 움직이는 구조를 만드는 것.

이 원칙이 제품 설계에 그대로 반영된다. 팀이 구성원에게 자율성을 주듯, 제품도 사용자에게 자유를 준다. 팀이 불필요한 회의와 보고 대신 명료한 맥락 공유를 선택하듯, 제품도 불필요한 알림과 강제 대신 깔끔한 완결을 선택한다. 팀이 구성원을 붙잡지 않고 성장할 기회를 주듯, 제품도 사용자를 붙잡지 않고 떠날 자유를 준다.

작은 팀이 만드는 제품의 차별점은 기능의 수가 아니다. 기능의 수에서 경쟁하면 큰 조직을 이길 수 없다. 차별점은 태도에서 나온다. 제품의 구석구석에 배어 있는 사용자에 대한 존중. 프랑켄슈타인이 되지 않겠다는 의지. 할 일이 끝나면 깔끔하게 보내주겠다는 용기. 이런 철학은 수백 명이 분업하는 조직에서는 유지하기 어렵다. 의사결정이 분산되면 철학도 희석된다. 작은 팀이기 때문에 하나의 철학을 제품 전체에 관통시킬 수 있다.

존중받았다고 느끼는 사용자만이 진심으로 돌아온다. 이것은 제품 철학인 동시에, 지금까지 이야기해 온 팀 운영 철학의 자연스러운 연장이다.

그리고 이 철학을 제품에 온전히 담으려면, 적은 인원으로 깊이 있는 결정을 내릴 수 있는 구조가 필요하다. 다음 장에서는 AI 시대에 작은 팀이 그 구조적 이점을 어떻게 극대화할 수 있는지를 이야기하려 한다.

번아웃과 성과의 관계

Wed, 01 Apr 2026 00:00:00 GMT

일하다 보면 한 번쯤 듣게 되는 말이 있다. "천천히 하세요, 그러다가 번아웃 와요." 야근하는 동료에게 건네는 이 말은 선의에서 비롯되었을 것이다. 하지만 이 충고에는 묘한 전제가 숨어 있다. 번아웃의 원인이 과로라는 전제다.

정말 그럴까. 앞 챕터에서 우리는 일의 구조를 이야기했다. What과 How를 분리하고, 직관을 훈련하며, 모든 구성원이 문제 정의에 참여하는 팀의 모습을 그렸다. 그런데 구조가 아무리 정교해도, 그 안에서 일하는 개인이 소진되면 구조는 껍데기가 된다. 팀의 운영 체계를 논하는 2막의 마지막에, 개인의 에너지 문제를 다뤄야 하는 이유가 여기에 있다.

번아웃은 과로가 아니라 헛달림이다

번아웃의 진짜 원인은 과로가 아니다. 열심히 달려가는데 결실이 보이지 않는 상태, 즉 성과의 부재다. 사람은 의외로 바쁜 것 자체에는 잘 견딘다. 마감에 쫓기면서도 눈앞에서 결과물이 만들어지고 있다는 감각이 있으면, 피로는 피로로만 남는다. 하지만 매일 야근하면서도 프로젝트가 표류하거나, 내가 만든 것이 어디에도 쓰이지 않는다는 느낌이 쌓이면, 같은 업무량이라도 에너지는 급격히 고갈된다.

오히려 조직이 뜨겁게 달리고 있을 때가 건강한 상태일 수 있다. 갑작스럽게 찾아오는 여유와 고요함이 불안을 만들어내는 경험을 해본 사람이라면 이 감각을 알 것이다. 열심히 스프린트를 돌다가 갑자기 할 일이 사라진 순간, 해방감보다 먼저 찾아오는 것은 "이게 맞나?"라는 불안이다. 그래서 번아웃의 해법은 쉬는 것이 아니다. 물론 휴식은 필요하다. 다만 휴식만으로는 근본 원인이 해소되지 않는다. 필요한 것은 자신이 기여하고 있다는 실감, 즉 성과다.

여기서 한 가지 짚어야 할 것이 있다. 상대방의 맥락을 모른 채 자기 경험에 비추어 건네는 조언의 위험이다. "그러다가 번아웃 와요", "제가 해보니까 건강이 최고예요" 같은 말은, 지금 달리고 있는 사람에게 달리지 말라고 말하는 것과 다르지 않다. 사람마다 성과를 내는 방식이 다르고, 시기에 따라 주어지는 기회는 한정적이다. 그때 해볼 수 있는 것은 그때 해봐야만 한다. 그것도 자신이 충분히 만족할 만큼.

능력 범위라는 울타리

그렇다면 성과를 내려면 어디서부터 시작해야 하는가. 답은 자신의 능력 범위를 정확히 아는 것이다.

능력 범위란 시간이 지나면서 축적한 지식과 전문성의 영역을 말한다. 누구에게나 자신이 깊이 이해하는 영역과 그렇지 못한 영역이 있다. 핵심은 그 경계를 인식하고, 경계 안에서 먼저 단단해지는 것이다. 세 가지 질문으로 시작할 수 있다. 내 직무의 책임과 역할은 무엇인가. 내가 잘하는 것은 무엇인가. 내가 아는 것과 모르는 것의 경계가 어디인가.

이 질문에 답할 수 있는 사람은 몇 가지 이점을 갖게 된다. 진정으로 이해하는 영역에 집중하니 성공 확률이 높아진다. 자기 판단에 확신이 생기니 의사결정이 빨라진다. 이해하지 못하는 것에 무리하게 뛰어들지 않으니 예측 불가능한 위험이 줄어든다. 그리고 기본 이해가 탄탄한 사람은 인접 영역으로의 확장도 더 빠르다. 결국 능력 범위 안에서 단단해지는 것이 확장의 전제 조건이 된다.

엔지니어 조직에서 이 경계 밖으로 뛰어나가려는 충동은 흔하다. 새로운 기술 스택, 새로운 역할, 새로운 도메인. 놓치면 뒤처질 것 같은 불안, 이른바 FOMO가 능력 범위 바깥으로 성급하게 발을 내딛게 만든다. 하지만 현실에 안주하라는 이야기가 아니다. 순서의 문제다. 자신이 해야만 하는 것, 잘할 수 있는 것을 먼저 단단하게 다져야 확장이 의미를 갖는다. 기초 없이 넓히는 것은 확장이 아니라 분산이다.

권한과 책임의 지도

능력 범위를 인식했다면, 다음 단계는 자신이 조직 안에서 어떤 종류의 일을 하고 있는지를 파악하는 것이다. John Cutler가 제안한 Mandate Levels는 이를 위한 유용한 지도가 된다.

Mandate Levels는 업무에서의 권한과 책임을 아홉 단계로 구분한다. 먼저 강조해야 할 것은, 이것이 상하관계나 등급을 나타내는 것이 아니라는 점이다. 일에 대한 권한의 종류를 구분한 것이다.

가장 기초적인 단계에서는 정해진 스펙을 그대로 구현한다. 시키는 일을 정확히 수행하는 것이 이 단계의 핵심이며, 여기서 쌓이는 기본기가 이후 모든 단계의 발판이 된다. 중간 단계로 올라가면 고객의 특정 문제를 직접 정의하고 해결하는 영역이 열린다. 더 이상 "이렇게 만들어라"가 아니라 "이 문제를 풀어라"가 주어지는 것이다. 주어진 입출력이 아니라 문제 자체를 다루기 시작한다는 점에서 질적 전환이 일어난다. 더 나아가면 사업 성과를 개선하기 위한 레버리지 포인트를 탐색하고 실험하는 단계가 있다. 매출 개선을 위한 새로운 방법을 직접 찾아내고 검증하는 일이다. 그리고 최상위 단계에서는 회사 전체의 장기적 사업 성과를 정의하고 책임진다.

실리콘밸리가 수평적이라고 할 때, 그 수평은 구성원 간의 관계를 말하는 것이지 의사결정의 구조를 말하는 것이 아니다. 어떤 조직이든 의사결정에는 층위가 존재한다. Mandate Levels가 유용한 이유는 이 층위를 투명하게 드러내기 때문이다.

작은 팀에서는 한 사람이 여러 레벨에 걸쳐 일하는 경우가 많다. 오전에는 고객 문의를 분석하며 문제를 정의하고(중간 단계), 오후에는 그 문제를 해결하기 위한 기능을 직접 구현하며(기초 단계), 저녁에는 분기 전략을 논의한다(상위 단계). 이 자체가 나쁜 것은 아니다. 오히려 작은 팀의 강점이다. 다만 중요한 것은, 자신이 지금 어떤 레벨에서 일하고 있는지를 의식하는 것이다. 그래야 각 레벨에서 요구되는 판단의 기준이 달라진다는 것을 알 수 있고, 자신의 에너지를 어디에 집중해야 하는지가 보인다.

성장이 수렴하는 지점

Mandate Levels를 통해 자신의 현재 위치를 인식하면, 능력 범위와 자연스럽게 연결된다. 내가 어떤 레벨에서 일하고 있는지를 알면 그 레벨에서 요구되는 능력이 무엇인지가 보인다. 그 능력이 내 현재 능력 범위 안에 있다면 성과를 낼 수 있고, 밖에 있다면 먼저 학습이 필요하다. 이 판단이 가능해지는 것만으로도 헛달림은 줄어든다.

번아웃은 결국 방향 없는 노력이 쌓일 때 찾아온다. 내가 할 수 있는 일과 해야 하는 일의 교집합을 찾고, 그 안에서 성과를 내는 경험을 축적하는 것. 이것이 번아웃을 이기는 가장 현실적인 방법이다.

2막을 통해 우리는 채용에서 시작해 리더십, 명료함, 피드백, 공정함, 실행 구조를 거쳐 여기까지 왔다. 팀을 만들고, 팀을 작동시키고, 팀 안의 개인이 지치지 않는 법까지. 이 모든 기술이 하나의 질문으로 수렴한다. 개인의 성장과 팀의 성장이 같은 방향을 가리킬 때, 작은 팀은 비로소 단단해진다.

그런데 단단한 팀이 만드는 결과물은 결국 제품이다. 팀 내부의 운영 원칙은 팀이 세상에 내놓는 것에도 그대로 스며든다. 2막에서 팀의 안을 들여다보았다면, 이제는 팀의 밖을 바라볼 차례다.

불편한 말이 팀을 살린다

Wed, 01 Apr 2026 00:00:00 GMT

리더 미팅이 끝난 직후의 복도는 묘한 공기를 품는다. 회의실에서 꺼내지 못한 말들이 사람들의 발걸음 사이에 떠돈다. 어느 날, 한 리더가 지난주에 약속한 일을 끝내지 못한 채 미팅에 들어왔다. 참석한 리더 전원이 그 사실을 알고 있었다. 그러나 아무도 입을 열지 않았다. 시선이 자연스럽게 한 곳으로 향했다. 나였다. 결국 내가 그 이야기를 꺼냈고, 미팅이 끝난 뒤 몇몇이 다가와 말했다. "말씀하시길 잘했어요. 저도 신경 쓰이긴 했거든요."

그 말에 안도하기보다 질문이 남았다. 신경이 쓰였다면 왜 직접 이야기하지 않았을까. 이것은 그 리더의 소심함도, 나의 리더십도 아닌, 팀이 책임을 다루는 방식의 문제였다.

앞선 챕터에서 여섯 가지 질문에 대해 리더 전원이 같은 답을 만들어내는 과정을 이야기했다. 명료함에 합의하는 것은 시작이다. 합의는 잉크가 마르는 순간부터 흐려지기 시작한다. 그것을 붙잡아두려면, 누군가 흐려짐을 발견한 순간 말을 건넬 수 있어야 한다. 문제는 그 '누군가'가 언제나 같은 사람이라는 데 있었다.

감독만 외치는 팀

축구 경기장에는 두 종류의 팀이 있다. 감독만 터치라인에서 소리를 지르는 팀과, 선수들끼리 서로 외치고 끌어당기는 팀이다. 감독은 경기장 바깥에 서 있다. 선수 열한 명의 움직임을 전부 볼 수 없고, 피치 위의 미세한 흐름까지 읽지 못한다. 상대 수비를 놓친 동료에게 "뒤를 봐!"라고 소리치는 것은 옆에서 함께 뛰는 선수만 할 수 있는 일이다.

조직에서도 마찬가지다. 모든 지적이 한 사람 -- 대개 CEO나 CTO -- 에게 집중되면, 그 사람이 아무리 부지런해도 구조적으로 한계에 부딪힌다. 한 사람이 모든 리더의 약속 이행을 추적하고, 미달을 짚고, 개선을 요구하는 것은 물리적으로 불가능하다. 설령 가능하더라도 그것이 만드는 것은 '동료 간의 약속'이 아니라 '상하 관계의 감시'다. 감독 혼자 외치는 팀에서는 선수들이 감독의 눈치를 살피지, 서로의 플레이를 살피지 않는다.

반대로 동료 리더들이 서로의 약속 이행을 확인하고, 미달이 보이면 직접 이야기하는 팀에서는 책임의 무게가 분산된다. 네 명의 동료가 함께 이야기하는 압박은 한 사람의 지적보다 훨씬 강력하면서도, 동시에 덜 위계적이다. 이것이 동료 간 상호 피드백이 가장 효과적인 책임 시스템이라고 생각하는 이유다.

침묵이 보호하는 것

그러나 대부분의 팀에서 이런 상호 피드백은 자연스럽게 일어나지 않는다. 세 가지 이유가 있다.

첫째, 관계에 대한 두려움이다. 지적하면 관계가 틀어질 것 같다. 특히 리더들 사이에서 이 두려움은 강하다. 서로의 전문 영역을 존중하는 관계에서 무언가를 짚는다는 것은 상대의 역량 자체를 의심하는 것처럼 느껴진다.

둘째, 역할에 대한 착각이다. "그건 CEO가 할 일이지, 내가 할 일이 아니야." 이 생각에는 편안함이 있다. 불편한 역할을 윗사람에게 위임하면 나는 '좋은 동료'로 남을 수 있다. 그 결과 한 사람만 나쁜 역할을 떠안고, 나머지는 방관자가 된다.

셋째, 가장 근본적인 문제는 지적과 갈등을 혼동하는 것이다. 동료에게 "지난주에 약속한 건 어떻게 됐어?"라고 묻는 것은 갈등이 아니다. 합의한 약속의 이행을 확인하는 것이다. 그러나 많은 사람들의 머릿속에서 이 질문은 갈등의 시작으로 분류된다.

아이러니는 여기서 발생한다. 지적을 피하면 관계가 보존될 것 같지만, 실제로는 반대다. 회의실에서 하지 못한 말은 사라지지 않는다. 복도의 뒷담화가 되고, 슬랙 DM의 푸념이 된다. 문제는 쌓이고, 감정은 뒤틀린다. 침묵이 보호하는 것은 관계가 아니라 불편함을 피하려는 자기 자신이다.

개인의 용기에서 팀의 시스템으로

이 불편함을 '용기'에만 의존하면 지속되지 않는다. 용기 있는 한두 사람이 지적을 반복하다 지치면, 팀은 다시 침묵으로 돌아간다. 불편함을 시스템으로 만들어야 한다.

내가 효과적이라고 느낀 방법은 의외로 단순했다. 리더들이 정기적으로 모여, 서로에게 딱 한 가지씩 이야기하는 시간을 갖는 것이다. "당신이 팀에 더 기여하기 위해 한 가지 더 잘했으면 하는 것"을 직접 말한다.

처음 이 자리를 만들었을 때 분위기는 당연히 어색했다. 눈을 잘 마주치지 못했고, 누군가 입을 열기까지 긴 침묵이 흘렀다. 그런데 한 사람이 먼저 말을 꺼내자 흐름이 달라졌다. 첫 번째 피드백 뒤에 두 번째는 훨씬 쉬워지고, 세 번째부터는 공기 자체가 바뀌었다. 더 놀라운 것은 피드백을 받는 쪽의 반응이었다. 방어적이기보다 "그게 그렇게 보였구나"라며 고개를 끄덕이는 경우가 많았다.

이 훈련의 본질은 피드백의 내용에 있지 않다. 서로의 행동에 대해 말하는 것이 '정상적인 일'이라는 경험을 만드는 데 있다. 한 번 이 경험을 하고 나면, 일상에서 동료에게 무언가를 이야기하는 문턱이 낮아진다. 완전히 편해지지는 않는다. 그러나 "우리는 서로에게 이런 이야기를 하는 팀이다"라는 기준이 생긴다. 기준이 세워지면, 침묵은 더 이상 예의가 아니라 회피가 된다.

피드백은 근육과 같아서, 쓰지 않으면 약해진다. 일회성 이벤트가 아니라 반복 가능한 루틴이어야 하는 이유다.

연기 감지기를 설치하라

피드백을 해야 한다는 것은 이제 동의했다고 하자. 다음 질문은 "무엇에 대해 피드백할 것인가"다.

분기 리뷰 자리에서 마주한 장면이 있다. 한 리더의 팀은 목표 매출을 달성했다. 숫자만 보면 나무랄 데가 없었다. 그런데 그 팀의 이직률은 조직 전체에서 가장 높았고, 다른 팀과의 협업 요청은 번번이 무산되었으며, 팀원들의 표정은 성과를 달성한 사람들의 것이 아니었다. 숫자는 "수고했다"고 말하라고 했지만, 눈에 보이는 것은 다른 이야기를 하고 있었다.

이런 순간에 많은 조직이 침묵을 택한다. 숫자가 좋으니까. 측정 가능한 지표가 달성되었으니까. 우리는 측정할 수 있는 것에 끌린다. 매출, 완료 프로젝트 수, 스프린트 속도. 이런 지표는 명확하고, 논쟁의 여지가 적으며, 숫자가 나를 대신 말해준다.

반면 행동은 모호하다. "회의에서 다른 팀의 의견을 자주 끊는다", "약속한 기한을 조용히 넘긴다", "팀원들 앞에서는 동의하고 뒤에서는 다른 이야기를 한다." 이런 것들은 KPI에 잡히지 않는다. 측정할 수 없으니 피드백의 대상도 되지 않는다.

건강검진을 떠올려 보면 이 문제가 선명해진다. 혈압, 혈당, 콜레스테롤 수치만 보고 "건강합니다"라고 말하는 의사가 있다. 수치를 본 뒤 생활습관까지 묻는 의사가 있다. 수면은 충분한지, 운동은 하는지, 스트레스는 어떻게 다루고 있는지. 수치가 정상이어도 생활습관이 나쁘면 "지금은 괜찮지만, 이대로 가면 문제가 생깁니다"라고 말하는 의사. 어느 쪽이 더 좋은 의사인지는 분명하다.

조직에서 성과만 피드백하는 리더는 수치만 보는 의사와 같다. 숫자가 무너진 뒤에야 "왜 이렇게 됐지?"라고 묻는다. 그때는 이미 늦다.

이것이 행동을 '연기 감지기'에 비유하는 이유다. 성과 지표는 화재 경보기다. 불이 나야 비로소 울린다. 행동은 연기 감지기다. 불이 나기 전, 연기가 피어오르는 단계에서 경고한다. 회의에 습관적으로 늦는 리더를 생각해보자. 5분, 10분. 대단한 문제는 아닌 것 같다. 그러나 이 행동이 반복되면 팀의 리듬이 깨진다. 다른 리더들도 시간을 덜 엄격하게 지키기 시작한다. 회의 시작이 매번 밀리고, 논의 시간이 줄어들고, 중요한 결정이 다음으로 미뤄진다. 몇 달 뒤 프로젝트가 지연되었을 때 원인을 추적하면, 뿌리는 훨씬 이전의 행동에 있었다.

연기 감지기 없이 화재 경보기만 설치한 건물은, 겉으로는 안전해 보이지만 대응할 시간을 이미 잃은 건물이다. 행동을 피드백하지 않는 조직도 마찬가지다.

판단이 아닌 장면으로 말하기

행동을 이야기해야 한다는 것까지는 동의했다. 남은 문제는 '어떻게'다.

"당신의 태도가 문제입니다."

이것은 피드백이 아니라 판단이다. 이 말을 들으면 누구든 방어적이 된다. 행동 피드백이 사람에 대한 공격으로 느껴지는 이유는, 대부분의 행동 피드백이 실제로 판단의 형태를 띠기 때문이다.

구체적인 장면, 그 행동이 만든 영향, 그리고 기대하는 변화. 이 세 가지가 갖춰지면 피드백은 공격이 아니라 대화가 된다.

"지난 수요일 기획 회의에서, 마케팅팀이 제안을 설명하는 중간에 두 번 말을 끊으셨어요. 그 뒤로 마케팅팀 쪽에서 발언이 거의 없었고, 결론이 한쪽으로만 기울어진 채 끝났습니다. 다음 회의에서는 상대 팀이 설명을 마칠 때까지 기다려주시면, 더 균형 잡힌 논의가 될 것 같습니다."

같은 문제를 이야기하지만, 받아들이는 사람의 경험은 전혀 다르다. 앞의 말은 사람을 재단하고, 뒤의 말은 장면을 묘사한다. 장면에서 출발하면 상대가 자기 행동을 객관적으로 돌아볼 여지가 생긴다.

이 구조를 안다고 해서 곧바로 쉬워지지는 않는다. 여전히 불편하다. 그러나 적어도 "어떻게 말해야 할지 모르겠다"는 핑계는 사라진다. 구조가 있으면 용기의 문턱이 낮아진다.

기대라는 이름의 신뢰

불편한 말을 건네는 것의 본질을 다시 들여다보면, 거기에는 기대가 있다. 동료에게 "지난번 미팅에서 약속한 자료가 아직 안 나왔다"고 말하는 것은 그 사람이 더 잘할 수 있다고 믿기 때문이다. 기대가 없는 관계에서는 불편한 대화가 필요 없다. 그냥 거리를 두면 된다. 포기한 관계에서는 침묵이 가장 효율적이다.

그래서 불편한 말을 건네는 것은 사실 이런 뜻이다. "나는 당신이 더 나아질 수 있다고 믿는다. 그리고 이 팀이 함께 더 좋아질 수 있다고 믿는다." 불편한 피드백이 신뢰의 부재가 아니라 신뢰의 증거라는 것을 팀 전체가 이해하면, 피드백의 의미가 달라진다. 지적이 아니라 기대의 표현이 된다.

물론 전제가 있다. 진심이어야 한다. 자기 불편함을 해소하기 위한 지적, 우위를 점하기 위한 지적은 기대가 아니라 공격이다. "이 말을 하는 이유가 이 사람과 이 팀을 위한 것인가"라는 질문에 솔직하게 답할 수 있어야 한다.

동료에게 마지막으로 불편한 말을 건넨 것은 언제인가. 기억이 나지 않는다면, 지금 당신의 팀에서 책임은 과연 누구의 몫인가. 그리고 그 책임을 함께 나눈다는 것은 결국, 팀 안에서 사람들이 공정하게 대우받고 있다는 감각과 맞닿아 있다. 피드백의 '무엇'과 '어떻게'를 넘어, 그 바탕이 되는 공정함의 뿌리는 어디에 있는 것일까.

AI 시대, 작은 팀이 유리한 이유

Wed, 01 Apr 2026 00:00:00 GMT

제품에 철학을 담으려면 깊이 있는 결정이 필요하다. 그런데 깊이 있는 결정은 회의실에 스무 명이 앉아 있을 때가 아니라, 서너 명이 같은 맥락을 공유한 채 마주 앉아 있을 때 나온다. 이 직관은 AI 시대에 들어서면서 직관이 아닌 구조적 사실로 바뀌고 있다.

앞 챕터에서 우리는 How의 비용이 0에 수렴하는 세상을 이야기했다. 만드는 일은 점점 싸지고, 정의하는 일만이 여전히 비싸다. 그때 우리가 집중한 것은 팀 내부의 실행 구조였다. 누가 What에 참여하고, 어떻게 스프린트를 교차 운영할 것인가. 하지만 그 논의에서 한 걸음 더 나가면, 더 근본적인 질문이 기다리고 있다.

AI가 개인을 강하게 만들수록, 조직이라는 형태 자체에 어떤 변화가 일어나는가.

규모의 경제가 무너지는 지점

오랫동안 큰 조직에는 명확한 이점이 있었다. 분업, 전문화, 규모의 경제. 백 명이 모이면 한 사람이 하나의 역할만 깊이 파고들 수 있고, 그 깊이가 모여 개인으로는 불가능한 결과물을 만들어냈다. 이 공식은 제조업에서 시작되어 소프트웨어 산업에까지 그대로 이식되었다.

그런데 AI가 이 공식의 전제를 흔들고 있다.

첫째, 분업의 경계가 허물어지고 있다. 과거에 한 사람이 기획 리서치를 하고, 다른 사람이 프로토타입을 만들고, 또 다른 사람이 코드를 작성하던 흐름이 있었다. 세 사람이 순차적으로 해야 했던 이 과정을, 이제 한 사람이 AI 도구를 곁에 두고 하루 안에 순환시킬 수 있다. 분업이 효율적이었던 이유는 각 단계에 전문 기술이 필요했기 때문인데, AI가 그 전문 기술의 접근 비용을 극적으로 낮춘 것이다.

둘째, 전문화의 의미가 바뀌고 있다. "이 분야만 깊이 아는 사람"의 가치가 사라지는 것은 아니다. 하지만 "여러 분야를 빠르게 학습하고 연결하는 사람"의 가치가 급격히 올라가고 있다. 이것은 작은 팀에서 이미 일상적으로 요구되는 역량이다. 다섯 명이 하나의 제품을 만들 때, 한 사람이 하나의 역할만 고수하는 것은 사치다. 모두가 경계를 넘나들며 일해야 한다. 그리고 AI는 그 경계 넘기를 가능하게 만드는 가장 강력한 도구다.

셋째, 규모가 오히려 비용이 되는 지점이 생겼다. 큰 조직이 새로운 AI 도구를 도입하려면 어떤 과정을 거치는지 생각해보자. 보안 검토, 정책 수립, 교육 프로그램 설계, 부서 간 협의, 파일럿 프로젝트, 성과 측정. 도구 자체의 비용보다 도입 과정의 조정 비용이 몇 배 더 크다. 작은 팀은 이 모든 과정을 점심시간에 끝낼 수 있다. 누군가 좋은 도구를 발견하면 오후에 바로 써보고, 저녁에 팀 전체가 피드백을 나눈다. 다음 날 아침이면 그 도구가 팀의 일상 속에 녹아 있다.

규모의 경제가 작동하려면 환경이 안정적이어야 한다. 같은 공정을 반복할수록 효율이 올라가는 구조니까. 하지만 AI로 인해 도구와 방법론이 몇 달 단위로 바뀌는 시대에, 규모는 관성이 되고 관성은 곧 둔감함이 된다.

작은 팀에서 AI가 증폭시키는 것

AI는 개인의 능력을 증폭시키는 도구다. 그런데 같은 도구라도 어떤 팀에서 쓰느냐에 따라 증폭의 크기가 전혀 다르다. 작은 팀이 가진 세 가지 고유한 강점 — 인재밀도, 의사결정 속도, 맥락 공유 — 은 AI와 만났을 때 덧셈이 아니라 곱셈으로 작동한다.

인재밀도와 AI의 곱셈. 인재밀도가 높은 팀에서 AI의 효과는 극대화된다. 맥락을 깊이 이해하고, 문제의 본질을 꿰뚫고, 방향을 정확히 설정할 수 있는 사람이 AI를 활용하면 생산성이 몇 배로 뛴다. 반면 맥락 이해가 부족한 사람은 AI를 써도 방향 자체가 틀릴 수 있다. AI는 "무엇을 해야 하는가"를 알려주지 않는다. "어떻게 해야 하는가"를 빠르게 실행해줄 뿐이다. What을 정의할 수 있는 사람의 손에 쥐어진 AI만이 의미 있는 결과를 만든다. 작은 팀의 높은 인재밀도는 이 조건을 자연스럽게 충족시킨다.

의사결정 속도와 AI의 곱셈. AI가 아무리 빠르게 선택지를 생성해도, 최종 결정은 여전히 사람이 한다. 의사결정 레이어가 세 단계인 조직에서는 AI가 만들어낸 옵션이 팀장에서 실장으로, 실장에서 본부장으로 올라가는 동안 시간이 흐른다. 각 단계에서 맥락이 손실되고, 원래의 의도가 희석된다. 의사결정 레이어가 하나인 조직에서는 AI가 제시한 선택지를 보고 바로 판단하고, 바로 실행에 옮긴다. AI 시대에 실행 속도의 병목은 "만드는 속도"가 아니라 "결정하는 속도"다. 그리고 결정하는 속도는 조직 구조가 결정한다.

맥락 공유와 AI의 곱셈. AI에게 정확한 결과를 얻으려면 정확한 맥락을 줘야 한다. 고객이 어떤 문제를 겪고 있는지, 시장이 어떤 방향으로 움직이고 있는지, 우리 제품의 기술적 제약이 무엇인지. 작은 팀에서는 모든 구성원이 이 맥락을 공유한다. 누구라도 AI에게 정확한 질문을 던질 수 있다. 큰 조직에서 맥락은 부서의 경계에서 끊긴다. 마케팅팀이 아는 고객 정보, 엔지니어링팀이 아는 기술적 제약, 영업팀이 아는 시장 상황 — 이것들이 한 사람의 머릿속에 모이지 않으면, AI에게 줄 수 있는 맥락도 파편적이 된다.

볼타에서 이 세 가지는 매일의 일상 속에서 작동한다. 고객 문의가 들어오면 엔지니어가 직접 읽고, 그 자리에서 AI 코딩 도구를 열어 프로토타입을 만들어본다. 기획 회의에서 나온 아이디어를 오후에 바로 검증할 수 있다. 누군가 새로운 AI 리서치 도구를 발견하면 그날 오후에 팀 전체가 써보고 피드백을 나눈다. 이 모든 것이 가능한 이유는 다섯 명 모두가 같은 맥락 안에 있고, 의사결정에 별도의 승인 과정이 없으며, 각자가 자기 영역 너머의 일까지 판단할 수 있는 밀도를 갖추고 있기 때문이다. 작은 팀이 AI와 함께일 때, 규모가 열 배 큰 팀이 하는 일을 해낼 수 있다는 것은 과장이 아니라 이미 우리가 경험하고 있는 현실이다.

What을 정의하는 사람만 남는 시대

이 모든 변화가 가리키는 방향은 하나다. How가 공짜가 되어가는 세상에서, 팀의 가치는 "몇 명이 있느냐"가 아니라 "얼마나 정확하게 What을 정의하느냐"에 달려 있다.

큰 조직이 사람을 많이 모아서 얻던 이점 — 전문 분업, 규모의 경제, 조직적 지식의 축적 — 은 AI가 상당 부분 대체하거나 무력화하고 있다. 반면 작은 팀이 원래 가지고 있던 강점 — 높은 인재밀도, 빠른 의사결정, 깊은 맥락 공유 — 은 AI에 의해 증폭되고 있다. 이것은 우연이 아니라 구조적 필연이다.

AI 시대에 작은 팀이 유리하다는 주장은 기술 낙관론이 아니다. AI가 만능이라서가 아니라, AI라는 도구의 특성이 작은 팀의 구조와 정확히 맞물리기 때문이다. AI는 방향을 설정하지 못한다. 맥락을 이해하지 못한다. 고객의 진짜 문제가 무엇인지 판단하지 못한다. 이 모든 것은 여전히 사람의 영역이고, 그 사람들이 밀도 높게 모여 빠르게 결정하고 깊이 공유하는 구조가 작은 팀이다.

작은 팀을 유지한다는 것은 성장을 포기한다는 뜻이 아니다. 오히려 AI 시대에 가장 효과적으로 성장할 수 있는 구조를 선택한다는 뜻이다. 한 사람이 할 수 있는 일의 양이 점점 커지는 세상에서, 위험하게 몸집을 불리는 것보다 의사소통 비용이 적고 플랫한 조직을 유지하는 것이 변화에 훨씬 빠르게 대응할 수 있는 전략이 된다.

그렇다면 이제 질문은 이렇게 바뀐다. 작은 팀이라는 형태가 구조적 우위를 갖는다면, 그 우위를 지속 가능하게 만드는 것은 무엇인가. AI 시대의 강점을 확인했다면, 이제 그 강점이 어떤 미래로 이어지는지를 그려볼 차례다.

작은 팀의 미래

Wed, 01 Apr 2026 00:00:00 GMT

AI가 실행의 비용을 극적으로 낮추고, 한 사람이 해낼 수 있는 일의 범위가 넓어지는 시대를 우리는 이미 살고 있다. 이전 챕터에서 우리는 이 변화가 작은 팀에게 구조적 우위를 안겨준다는 것을 확인했다. 인재밀도가 높은 소수의 팀이 의사결정 속도와 방향 전환의 유연함에서 압도적 이점을 갖는다는 사실을. 그렇다면 이제 한 걸음 더 나가보자. 작은 팀이라는 선택은 지금 이 순간만을 위한 전략인가, 아니면 앞으로의 세계가 요구하는 구조인가.

성장의 공식이 바뀌고 있다

오랫동안 스타트업의 성장에는 하나의 공식이 있었다. 제품-시장 적합성을 찾고, 투자를 받고, 사람을 더 뽑는다. 그렇게 몸집을 불려서 시장을 점유한다. 이 루프를 빠르게 도는 팀이 이기는 팀이었다. PMF를 발견한 다음 날부터 채용 공고가 올라가고, 시리즈 A 이후에는 인원이 두 배, 세 배로 뛰는 것이 당연한 수순으로 여겨졌다.

이 공식은 한동안 잘 작동했다. 그러나 그 안에는 누구도 크게 이야기하지 않는 비용이 숨어 있었다.

첫째, 사업 방향의 경직이다. 특정 역할을 염두에 두고 채용한 사람들은, 사업의 방향이 바뀌었을 때 새로운 역할로 이동하기 어렵다. 매출이 나오는 비즈니스를 내려놓고 새로운 도전을 시작하는 것은 인원이 많을수록 더 큰 뚝심과 합의를 필요로 한다. 조직이 클수록 방향 전환은 유조선의 선회처럼 느리고 고통스러워진다.

둘째, 커뮤니케이션 비용의 폭증이다. 인원이 늘면 의사결정 레이어가 추가되고, 같은 정보를 전달하는 데 필요한 경로가 기하급수적으로 증가한다. 빠른 의사결정이라는 스타트업의 핵심 강점이 인원 증가와 함께 퇴화하는 것이다. 전화기를 아무리 많이 놓아도 통화의 질이 좋아지지 않듯, 사람이 많다고 실행이 빨라지지 않는다.

셋째, 인재밀도의 희석이다. 급하게 사람을 늘리면 한 사람 한 사람의 밀도가 떨어진다. 밀도가 떨어진 조직은 더 많은 관리 체계를 필요로 하고, 그 관리 체계는 다시 속도를 떨어뜨린다. 성장을 위한 채용이 오히려 성장을 방해하는 역설이 벌어진다.

이 세 가지 비용은 과거에도 존재했지만, 변화의 속도가 상대적으로 느렸기 때문에 감내할 만했다. 시장이 서서히 변하는 세계에서는 방향 전환이 잦지 않았고, 커뮤니케이션 비용은 성장의 대가로 수용되었다. 그러나 지금은 다르다. AI가 산업의 지형을 몇 달 단위로 바꾸는 시대에, 이 비용들은 더 이상 감내할 수 있는 수준이 아니다.

건강한 성장의 조건

그렇다면 성장을 포기해야 하는가. 물론 아니다. 포기해야 하는 것은 성장 자체가 아니라, "성장을 위한 성장"이라는 관성이다. 몸집을 불리는 것이 곧 성장이라는 등식을 내려놓을 때, 비로소 다른 종류의 성장이 보인다. 건강하고 오래 갈 수 있는 성장이.

이 책 전체를 관통하며 탐구해온 주제들은 사실 하나의 질문을 향해 수렴하고 있었다. 적은 인원으로 어떻게 큰 일을 해낼 수 있는가. 그 답의 조각들을 지금 한자리에 모아본다.

인재밀도다. 적은 인원이지만, 한 사람 한 사람이 자기 영역에서 높은 밀도를 가진다. 채용의 기준을 타협하지 않고, 함께 일해본 적 없는 사람에게서도 가능성을 발견하는 용기. 이것이 작은 팀의 첫 번째 조건이었다.

명료한 방향이다. 여섯 가지 질문에 리더 전원이 같은 답을 할 수 있는 상태. 미션 선언문이라는 액자가 아니라, 일상적 의사결정의 매 순간에 나침반처럼 작동하는 합의. 인원이 적기 때문에 이 합의가 가능하고, 이 합의가 있기 때문에 적은 인원으로도 일관된 방향으로 움직일 수 있다.

자율적 피드백이다. 위에서 내려오는 평가가 아니라, 동료 간에 서로의 행동에 책임을 묻는 구조. 불편한 말을 시스템 안에 녹여냄으로써, 작은 팀이 빠지기 쉬운 침묵의 함정을 피한다. 관리자가 없어도 팀이 스스로를 교정하는 힘이 여기서 나온다.

전원이 What에 참여하는 구조다. 실행만 하는 사람이 아니라 정의하는 사람들의 팀. 문제를 파악하고, 아이디어를 내고, 방향을 잡는 일에 모든 구성원이 기여한다. 실행 비용이 0에 수렴하는 시대에, 살아남는 팀은 더 빨리 만드는 팀이 아니라 더 잘 정의하는 팀이다.

일상 속에서 훈련되는 직관이다. 고객을 이해하고, 시장을 읽고, 팀원의 강점을 파악하는 감각. 데이터가 없는 상황에서도 "이건 풀 만한 문제"라는 판단을 내릴 수 있는 역량. 이 직관은 타고나는 것이 아니라 훈련되는 것이며, 작은 팀의 모든 구성원에게 그 훈련의 기회가 열려 있다.

이 모든 것이 따로 노는 개별 기술이 아니다. 높은 인재밀도가 명료한 방향을 만들고, 명료한 방향이 자율적 피드백을 가능하게 하고, 자율적 피드백이 전원의 What 참여를 이끌어내고, What 참여의 경험이 직관을 훈련한다. 하나의 톱니가 다음 톱니를 돌리는 체계. 이것이 작은 팀의 운영 체계이며, 건강한 성장의 조건이다.

앞으로의 세계가 요구하는 구조

변화의 속도는 앞으로도 계속 빨라질 것이다. 이것은 예측이 아니라, 지난 10년간의 추세가 보여주는 사실이다. AI 기술은 매 분기마다 이전 분기의 한계를 허물고, 산업의 경계는 점점 더 빠르게 재편된다.

이런 시대에 큰 조직의 관성은 치명적인 약점이 된다. 수백 명의 합의를 구하고, 기존 사업의 관성을 극복하고, 새로운 방향으로 전환하는 데 걸리는 시간이 곧 기회비용이다. 반면 작은 팀의 민첩함은 이 시대가 요구하는 핵심 역량이 된다. 방향을 바꾸는 데 몇 달이 아니라 며칠이면 충분한 팀. 새로운 기술을 도입하는 데 위원회의 승인이 아니라 점심시간의 대화로 충분한 팀.

폴 자비스가 《Company of One》에서 그린 그림이 있다. 성장 자체를 목적으로 삼지 않고, 더 나은 것을 목적으로 삼는 회사. 더 크게가 아니라 더 잘을 추구하는 조직. 그가 이 책을 쓸 때만 해도 이것은 하나의 철학적 선택이었다. 하지만 AI 시대에 접어든 지금, 이것은 철학이 아니라 생존 전략에 가깝다. 한 사람이 해낼 수 있는 일의 범위가 극적으로 넓어진 세상에서, 몸집을 불리는 것은 더 이상 경쟁 우위가 아니기 때문이다.

볼타는 이 방향을 구체적인 운영 원칙으로 실천해왔다. 불필요한 커뮤니케이션 비용을 줄이고, 효율적으로 일하기 위해 작은 팀을 유지하며, 작은 팀의 강점을 모두 챙기기 위해 노력한다. 이것은 슬로건이 아니라 매일의 의사결정에 적용되는 기준이다. 새로운 프로젝트가 생겼을 때 사람을 더 뽑는 것이 아니라, 기존 팀의 역량 배치를 재구성한다. AI 도구가 생산성을 높여주면, 그 여유를 채용이 아니라 각 구성원의 What 참여 확대에 투자한다.

이것이 성장을 거부하는 것일까. 전혀 아니다. 매출은 성장하고, 고객은 늘어나고, 해결하는 문제의 범위는 넓어진다. 다만 그 성장이 인원의 증가로 이어지는 것이 아니라, 한 사람 한 사람의 역량 확장으로 이어지는 것이다. 이것이 건강한 성장의 모습이다.

작은 팀의 기술은 큰 비전을 위한 것이다

한 가지 오해를 풀어야 한다. 작은 팀이 좋다는 말이 작은 꿈을 꾸라는 뜻은 아니다. 오히려 정반대다.

큰 비전을 실현하려면 팀의 형태를 가장 효율적으로 유지해야 한다. 비전이 클수록 자원의 낭비를 허용할 여유가 없다. 커뮤니케이션 비용에 에너지를 쏟는 대신 고객의 문제에 집중해야 하고, 내부 정치에 시간을 빼앗기는 대신 시장의 변화를 읽어야 한다. 작은 팀은 이 모든 것을 가능하게 하는 구조다.

잘 정의하는 것은 특정 직군 한두 명의 역할이 아니라, 제품팀 전체의 역량이다. 이 한 문장이 이 책 전체를 관통하는 메시지일지도 모른다. 무엇을 만들 것인가를 함께 고민하고, 왜 이것을 해야 하는가에 모두가 같은 답을 할 수 있고, 어떻게 해야 하는가는 각자의 전문성에 맡기되 서로의 성장을 돕는 구조. 이것이 작은 팀의 기술이며, 이 기술은 작은 꿈이 아니라 큰 비전을 실현하기 위해 존재한다.

성장을 위한 성장의 시대는 저물고 있다. 그 자리에 들어서는 것은, 밀도 높은 소수가 명료한 방향 아래 자율적으로 움직이며 세상의 변화에 민첩하게 대응하는 팀의 시대다. 작은 팀의 미래는 낭만이 아니다. 앞으로의 세계가 요구하는 구조다.

이 구조적 논증은 여기서 마무리된다. 그러나 모든 구조와 원칙 뒤에는 그것을 선택한 사람의 이야기가 남아 있다. 다음 장에서 우리는 선언이 아니라 다짐으로, 다시 개인적인 목소리로 돌아간다.

에필로그. 여전히 작은 팀으로

Wed, 01 Apr 2026 00:00:00 GMT

큰 방향은 변하지 않지만, 매주 작은 꿈들을 새롭게 세워나가고 있다.

이 문장을 처음 적었을 때는 그것이 무엇을 의미하는지 스스로도 잘 몰랐다. 큰 방향이란 무엇인가. 작은 꿈이란 또 무엇인가. 그것이 매주 바뀐다면 우리는 정말로 한 방향을 향해 가고 있는 것인가. 그런데 볼타를 운영하며 몇 년을 보내고 나니, 이 문장이 우리 팀의 리듬 그 자체였다는 것을 알게 되었다. 큰 방향은 흔들리지 않되, 거기에 도달하는 경로는 매주 다시 그린다. 어제의 계획을 오늘 수정하는 것이 혼란이 아니라 학습의 증거인 팀. 그런 팀이 되고 싶었고, 조금씩 그렇게 되어가고 있다.

본질에 집중한다는 것

이 책에서 나는 여러 가지를 이야기했다. 채용에 대해, 리더십에 대해, 명료함과 피드백에 대해, 실행과 번아웃에 대해, 제품과 AI에 대해. 열두 개의 챕터에 걸쳐 각기 다른 주제를 다루었지만, 돌이켜보면 그것들은 모두 하나의 문장을 향해 수렴하고 있었다.

본질에 집중한다.

볼타는 전세계 재무팀의 비효율적인 시간 낭비를 줄이고, 그들이 본질에 집중하여 더 큰 가치를 만들어낼 수 있도록 돕는 회사다. 그리고 그것을 해내기 위해, 우리 자신도 본질에 집중해야 한다. 채용에서 본질은 인재밀도를 타협하지 않는 것이었고, 리더십에서 본질은 부서의 대사가 아니라 팀 전체를 보는 것이었다. 명료함의 본질은 선언문이 아니라 같은 답이었고, 피드백의 본질은 불편하더라도 말하는 것이었다. 실행의 본질은 무엇을 할 것인가를 함께 정의하는 것이었고, 성장의 본질은 몸집이 아니라 밀도였다.

결국 이 책 전체가 "본질에 집중한다"는 한 문장의 풀이였는지도 모른다.

프롤로그에서 나는 카페에서 시작된 이야기를 했다. 아메리카노 두 잔 사이에 놓인 노트북, 냅킨에 끄적인 데이터베이스 구조, "같이 하시죠"라는 한마디. 그때의 두 사람은 지금도 같은 팀에 있다. 팀은 조금 더 커졌지만 여전히 작다. 사무실은 바뀌었지만 한 공간에서 모든 맥락이 공유되는 밀도는 그대로다. 제품은 완전히 달라졌지만, 고객의 문제를 직접 듣고 직접 푸는 거리감은 변하지 않았다.

달라진 것도 있다. 두 사람이 감당하기 벅찼던 결정들을 이제는 팀 전체가 함께 내린다. 혼자 안고 있던 불확실성을 이제는 함께 마주한다. 직관은 더 날카로워졌고, 서로에 대한 이해는 더 깊어졌다. 무엇보다, 왜 이 일을 하는가에 대한 답이 더 단단해졌다.

독자에게

이 책이 정답을 담고 있다고 생각하지 않는다. 볼타가 발견한 것들은 볼타의 맥락에서 작동한 것이지, 모든 팀에 그대로 적용될 수 있는 보편 공식은 아니다. 다만 이 여정에서 반복적으로 확인한 것이 하나 있다면, 그것은 좋은 팀은 우연히 만들어지지 않는다는 사실이다. 의식적으로 선택하고, 매일 실천하고, 불편한 순간에도 포기하지 않을 때 비로소 만들어진다.

이 책을 덮으며 한 가지만 물어보고 싶다.

당신은 어떤 팀에서, 어떤 방식으로 일하고 싶은가.

작은 팀이든 큰 팀이든, 스타트업이든 대기업이든, 그 질문 앞에서 자신만의 답을 갖고 있는 사람은 이미 절반은 해낸 것이다. 나머지 절반은 그 답을 매일의 일상에서 실천하는 일이다. 그것이 쉽지 않다는 것을, 나도 매일 느끼고 있다.

볼타는 여전히 작은 팀이다. 그리고 앞으로도 그럴 것이다. 이것은 성장의 포기가 아니다. 가장 효과적인 성장의 형태를 선택한 것이다. 규모의 선언이 아니라, 태도의 선언이다.

이 책이 팀의 일하는 방식을 고민하시는 분들께 작은 도움이 되기를 바란다.

여섯 가지 질문에 답할 수 있는가

Mon, 30 Mar 2026 15:00:00 GMT

리더십 미팅에서 한 가지 질문을 던져 본 적이 있다. "우리 조직에서 지금 가장 중요한 것이 뭔가요?" 간단한 질문이었다. 그런데 다섯 명의 리더에게서 다섯 개의 다른 답이 나왔다. 한 명은 채용이라고 했고, 한 명은 기술 부채 해소라고 했고, 한 명은 신규 기능 출시라고 했고, 한 명은 고객 이탈 방지라고 했고, 한 명은 팀 문화 개선이라고 했다. 다섯 개의 답 모두 틀린 것은 아니었다. 하지만 다섯 개가 동시에 "가장 중요한 것"일 수는 없었다.

그 순간 깨달았다. 이 조직에는 전략도 있고, 유능한 사람도 있고, 열정도 있다. 하지만 명료함이 없었다. 그리고 명료함이 없는 조직에서는, 모두가 열심히 일하지만 같은 방향으로 가고 있지 않다.

단순하지만 답하기 어려운 질문들

패트릭 렌시오니는 조직이 건강해지기 위해 리더십팀이 반드시 합의해야 할 여섯 가지 질문을 제시한다.

우리는 왜 존재하는가?
우리는 어떻게 행동하는가?
우리는 무엇을 하는가?
우리는 어떻게 성공할 것인가?
현재 가장 중요한 것은 무엇인가?
누가 무엇을 해야 하는가?

이 질문들을 처음 보면, 너무 기본적이라는 생각이 든다. "이걸 모르는 리더십팀이 어디 있겠어?" 하지만 여기서 핵심은 "아는 것"이 아니다. 핵심은 "모두가 같은 답을 할 수 있는가"이다.

각자 머릿속에 답이 있는 것과, 리더 전원이 동일한 답을 명료하게 말할 수 있는 것은 전혀 다른 상태다. 전자는 개인의 확신이고, 후자는 조직의 명료함이다. 그리고 대부분의 조직은 전자에 머물러 있다. 각자 나름의 답을 가지고 있지만, 그 답이 서로 같은지 확인해 본 적이 없다.

지적 능력의 문제가 아니다

이 질문들에 답하지 못하는 이유는 리더들이 부족해서가 아니다. 굉장한 지적 능력이나 영리함이 필요한 것도 아니다. 모든 리더십팀은 이 질문들에 대한 명료함을 창출할 수 있을 만큼의 정보와 경험을 가지고 있다. 그런데도 답하지 못하는 데는 다른 이유가 있다.

첫째, 리더들 간의 진짜 대화가 부족하다. 여섯 가지 질문에 답하려면, 리더들이 화합되지 않은 상태에서도 서로의 생각을 솔직하게 꺼내고 부딪힐 수 있어야 한다. 하지만 많은 리더십팀에서는 불필요한 갈등을 피하려 한다. 의견이 다를 때 "서로 다른 의견을 갖기로 합의"하고 넘어간다. 그것이 성숙한 선택이라고 생각한다. 하지만 이 "합의된 불일치"는, 조직 아래로 내려갈수록 혼란이 되어 돌아온다.

둘째, 마케팅적 관점으로 접근하는 경향이 있다. 이 질문들에 답할 때, 리더들은 쉽게 그럴듯한 문구를 만들려고 한다. 외부에 보여주기 좋은, 인상적인 한 줄. 하지만 이것은 핵심을 놓치는 접근이다. 이 질문들의 답은 마케팅 카피가 아니라, 리더 전원이 진심으로 동의하고 일상에서 반복할 수 있는 명료한 합의여야 한다.

셋째, 시간이 필요하다. 이 질문들에 대한 답은 한 번의 워크숍으로 완성되지 않는다. 며칠이 아니라 몇 주간의 대화가 필요할 수 있다. 답이 나온 후에도 확신이 들 때까지 시간을 두고 다시 검토해야 한다. 리더십팀 전원이 충분한 시간을 갖고 답을 완벽히 이해하고 동의하는 것이 필수적이다.

여섯 개의 문, 하나의 복도

이 여섯 가지 질문을 하나의 복도에 있는 여섯 개의 문이라고 생각해보자.

"우리는 왜 존재하는가?" 는 가장 안쪽의 문이다. 이 문 뒤에는 조직의 근본적인 이유가 있다. 돈을 버는 것 너머의, 이 조직이 세상에 존재해야 하는 이유. 이 답이 없으면 나머지 문들을 열어봐야 의미가 없다.

"우리는 어떻게 행동하는가?" 는 문화의 문이다. 조직이 중요하게 여기는 행동 원칙. "혁신적이고 고객 중심적이며..."라는 범용 표현이 아니라, 경쟁사와 구별되는 우리만의 행동 방식이 무엇인지를 규정한다.

"우리는 무엇을 하는가?" 는 가장 단순해 보이지만 의외로 합의가 어려운 문이다. 조직이 하는 일을 한 문장으로 설명할 수 있는가? 부서마다 다른 설명을 하고 있지는 않은가?

"우리는 어떻게 성공할 것인가?" 는 전략의 문이다. 전략적 앵커라고 불러도 좋다. 같은 산업의 경쟁사들 사이에서, 우리가 의식적으로 선택한 차별화 포인트는 무엇인가?

"현재 가장 중요한 것은 무엇인가?" 는 집중의 문이다. 그리고 내 경험상 가장 많은 논쟁이 벌어지는 문이다. 중요한 것은 항상 여러 개이고, 그중 하나만 고르는 것은 나머지를 포기하는 것처럼 느껴지기 때문이다. 하지만 모든 것이 중요하면, 아무것도 중요하지 않은 것과 같다.

"누가 무엇을 해야 하는가?" 는 실행의 문이다. 앞의 다섯 가지 답이 아무리 명료해도, 구체적인 역할과 책임이 정해지지 않으면 아무 일도 일어나지 않는다.

이 여섯 개의 문 중 하나라도 닫혀 있으면, 복도 전체가 어두워진다. 리더들 사이에 단 하나의 질문에 대해서라도 생각 차이가 존재하면, 그것은 조직 전체의 명료함을 방해하는 원인이 된다.

답의 정확함보다 중요한 것

이 질문들에 대해 가장 흔한 오해가 하나 있다. "완벽한 답을 찾아야 한다"는 생각이다. 하지만 렌시오니가 강조하는 핵심은 다른 곳에 있다.

올바른 답을 얻는 것보다, 팀 전체가 헌신할 수 있는 답이 있다는 사실 자체가 중요하다.

80%의 정확도를 가진 답에 리더 전원이 100% 헌신하는 것이, 100%의 정확도를 가진 답에 절반만 동의하는 것보다 훨씬 강력하다. 왜냐하면 조직에서 실행력은 합의의 깊이에서 나오기 때문이다. 모든 리더가 같은 메시지를 자기 팀에 전달하고, 같은 기준으로 의사결정을 하고, 같은 우선순위로 자원을 배분할 때, 조직은 비로소 하나의 방향으로 움직인다.

반대로, 아무리 좋은 전략이라도 리더들 사이에 해석의 차이가 있으면, 조직 아래에서는 완전히 다른 메시지로 전달된다. 한 리더는 "속도가 중요하다"고 말하고, 다른 리더는 "품질이 중요하다"고 말하면, 그 아래의 팀원들은 어느 쪽을 따라야 하는지 알 수 없다. 혼란은 개인의 무능이 아니라 리더십의 불일치에서 온다.

같은 답을 할 수 있는 상태

여섯 가지 질문의 목적은, 완벽한 전략 문서를 만드는 것이 아니다. 리더 모두가 같은 방에서, 같은 질문에, 같은 답을 할 수 있는 상태를 만드는 것이다.

이 상태를 만드는 데 특별한 도구나 프레임워크는 필요 없다. 필요한 것은 시간과 솔직함이다. 리더들이 함께 앉아서, 불편하더라도 서로의 생각 차이를 드러내고, 그 차이를 좁혀가는 과정. 그 과정이 바로 조직 건강의 출발점이다.

당신의 리더십팀에게 이 여섯 가지 질문을 던져 보자. 각자 따로 답을 적게 한 뒤, 비교해 보자. 모두가 같은 답을 적었다면, 당신의 조직은 이미 건강한 기반을 가지고 있다. 만약 다른 답이 나왔다면, 걱정할 필요는 없다. 그 차이를 발견한 것 자체가 명료함을 향한 첫걸음이다. 중요한 것은 답의 차이가 아니라, 그 차이를 좁히기 위해 대화를 시작하는 것이니까.

미션 선언문이라는 허상

Mon, 30 Mar 2026 14:00:00 GMT

어느 회사의 로비에 걸린 액자를 본 적이 있다. 깔끔한 프레임 안에, 정성스러운 서체로 인쇄된 문장이 들어 있었다. "고객에게 최고의 가치를 제공하고, 세계적인 혁신을 통해 주주와 직원 모두가 성장하는 기업이 되겠습니다." 읽는 데 10초가 걸렸고, 다 읽은 뒤에도 이 회사가 무엇을 하는 회사인지 알 수 없었다.

그 문장이 로비에 걸려 있었던 이유는, 아마도 누군가 그것이 조직에 명료함을 줄 거라고 믿었기 때문일 것이다. 하지만 그 앞을 지나는 직원들 중 발걸음을 멈추고 그 문장을 읽는 사람은 없었다. 그리고 솔직히, 읽었다 해도 달라질 것은 없었을 것이다.

30년 된 착각

1980년대부터 많은 조직들이 명료함을 확보하기 위해 한 가지 도구를 활용했다. 미션 선언문이다. 컨설턴트가 들어와서 워크숍을 열고, 경영진이 모여서 단어를 고르고 문장을 다듬었다. 그 결과물은 대체로 이런 모양이었다. "고품질의 제품과 서비스를 통해 고객의 삶에 가치를 더하며, 직원들과 장기적인 유대 관계를 구축함으로써 직원들이 자부심을 갖고 안정적으로 업무에 임할 수 있게 한다."

이 문장이 어딘가 낯익다면, 당연하다. 거의 모든 기업의 미션 선언문이 이런 형태이기 때문이다. "세계적인", "주주 가치", "가치 창출", "혁신" — 이런 단어가 많이 들어갈수록 좋은 선언문이라는 믿음이 있었다. 하지만 실제로 이 단어들이 많아질수록, 그 문장은 어떤 회사에나 적용 가능한 범용 문구가 되어버린다.

그런데 위의 미션 선언문은 실제 기업의 것이 아니다. 미국 드라마 더 오피스(The Office)에 나오는 허구의 제지 업체 던더 미플린의 미션 선언문이다. 기업 문화를 풍자하기 위해 코미디 작가들이 만든 문장이 실제 기업들의 로비에 걸린 선언문과 구분이 되지 않는다는 것. 이것은 특정 기업의 문제가 아니다. 미션 선언문이라는 형식 자체가, 진짜로 의미 있는 말을 담기 어려운 구조를 가지고 있다는 뜻이다.

한 문장에 모든 것을 담으려는 욕심

미션 선언문의 근본적인 문제는 욕심이다. 한 문장 안에 너무 많은 것을 담으려 한다. 영감을 주면서, 정보도 주면서, 동기도 부여하면서, 조직이 속한 시장과 포지션까지 규정하려 한다. 그 결과 어떤 것도 제대로 하지 못하는 문장이 탄생한다.

"우리는 고객에게 최고로 만족할 수 있는 제품과 서비스를 제공하며..." 여기서 멈춰보자. 이 세상에 고객에게 최고의 만족을 제공하지 않겠다고 선언하는 기업이 어디 있는가? 이 문장은 아무것도 규정하지 않는다. 경쟁사와의 차별점도, 조직의 독특한 존재 이유도, 지금 우리가 무엇에 집중해야 하는지도 말해주지 않는다.

미션 선언문을 만드는 과정도 문제다. 대부분의 경우, 경영진이 모여서 각자의 바람을 한 문장에 우겨넣으려 한다. 마케팅 임원은 고객 가치를 넣고 싶어하고, 재무 임원은 주주 가치를 넣고 싶어하고, HR 임원은 직원 성장을 넣고 싶어한다. 그 결과 모두의 소망이 담긴 장문의 선언문이 나온다. 누구도 반대하지 않지만, 누구에게도 영감을 주지 못하는 문장. 우후죽순 생겨나는 목표들 중에서 서로 상충하거나 소수의 리더들에게만 이익이 되는 것들도 있다.

이런 선언문을 회사 로비에 걸고, 티셔츠에 인쇄하고, 연례 보고서에 넣는다. 그리고 다음 날부터 아무도 신경 쓰지 않는다. 왜냐하면 그 문장이 일상의 의사결정에 아무런 도움을 주지 못하기 때문이다.

명료함은 문장이 아니라 과정에서 나온다

그렇다면 미션 선언문 대신 무엇이 필요한가?

패트릭 렌시오니는 이렇게 말한다. 명료함은 야망이 가득 담긴 부연 문장을 잔뜩 쌓는 것에서 오지 않는다. 훨씬 더 철저하고 가식 없는 접근이 필요하다. 그 접근이란, 리더십팀이 함께 앉아서 몇 가지 핵심적인 질문에 대해 진심으로 답하는 것이다.

"우리는 왜 존재하는가?" "우리는 어떻게 행동하는가?" "우리는 무엇을 하는가?" "우리는 어떻게 성공할 것인가?" "현재 가장 중요한 것은 무엇인가?" "누가 무엇을 해야 하는가?"

이 질문들은 미션 선언문처럼 한 문장으로 압축되지 않는다. 각각의 질문에 대해 리더 모두가 같은 답을 할 수 있을 때까지 대화해야 한다. 며칠이 아니라 몇 주가 걸릴 수도 있다. 그리고 그 대화의 과정 자체가 조직에 명료함을 만든다.

미션 선언문이 실패하는 이유는, 그것이 대화를 끝내기 위한 도구이기 때문이다. "자, 이제 이 문장에 합의했으니 넘어갑시다." 하지만 명료함은 대화를 끝내는 것이 아니라, 충분히 깊은 대화를 나누는 것에서 온다. 리더들 사이에 조금이라도 생각 차이가 존재한다면, 그 차이는 조직 아래로 내려갈수록 증폭된다. 리더 간의 미묘한 불일치가 부서 간의 해답 없는 논쟁이 되고, 직원들은 일관된 메시지를 받지 못해 혼란에 빠진다.

그래서 명료함의 출발점은 멋진 문장을 만드는 것이 아니라, 리더들이 같은 방에 앉아서 불편한 질문에 솔직하게 답하는 것이다. "우리가 정말로 다른 회사와 다른 점이 뭔가?" "이번 분기에 진짜 중요한 건 딱 하나만 고르면 뭔가?" "우리가 하지 말아야 할 것은 뭔가?" 이 질문들에 답하는 과정은 미션 선언문을 쓰는 것보다 훨씬 불편하고 시간이 오래 걸린다. 하지만 그 결과로 얻는 명료함은, 로비의 액자와는 비교할 수 없을 만큼 강력하다.

액자를 바꿀 것인가, 대화를 바꿀 것인가

많은 조직이 명료함의 부재를 느낄 때 하는 첫 번째 일은, 새로운 미션 선언문을 만드는 것이다. 더 멋진 단어를 고르고, 더 세련된 문장을 다듬어서, 더 예쁜 액자에 넣는다. 하지만 로비의 액자를 아무리 바꿔도, 리더들의 대화가 바뀌지 않으면 조직의 명료함은 달라지지 않는다.

올바른 답을 얻는 것보다 중요한 것이 있다. 팀 전체가 헌신할 수 있는 답이 존재한다는 사실 자체다. 완벽한 한 문장보다, 리더 모두가 같은 말을 할 수 있는 상태가 훨씬 강력하다. 미션 선언문은 벽에 걸기 위한 것이지만, 진짜 명료함은 사람들의 머릿속에 새겨지는 것이다.

당신의 조직에도 로비에 걸린 미션 선언문이 있을 것이다. 그 문장을 지금 기억할 수 있는가? 기억하지 못해도 괜찮다. 중요한 것은 그 문장이 아니다. 중요한 것은, 당신의 리더십팀이 "우리에게 지금 가장 중요한 것은 무엇인가"라는 질문에 같은 답을 할 수 있느냐는 것이다. 할 수 없다면, 필요한 것은 새로운 선언문이 아니라 새로운 대화다.

리더십팀은 UN이 아니다

Mon, 30 Mar 2026 12:00:00 GMT

리더십 미팅이 시작되었다. 엔지니어링 리드가 먼저 입을 연다. "개발팀 입장에서 말씀드리면, 이번 일정은 현실적으로 어렵습니다." 프로덕트 리드가 바로 받는다. "PM 조직에서는 이 기능이 이번 분기에 반드시 나가야 한다고 보고 있습니다." 디자인 리드가 끼어든다. "디자인팀 관점에서는 품질을 더 가져가고 싶은데요." 각자 자기 팀을 대표해서 발언한다. 서로의 영역을 존중하며 합의점을 찾으려 한다. 대화는 정중하고, 분위기는 나쁘지 않다.

그런데 이 회의가 끝난 뒤, 결정된 것은 거의 없었다. 모두가 자기 팀의 이익을 조금씩 양보하면서 타협안을 만들었지만, 누구도 만족하지 않았고, 조직 전체에 가장 좋은 결정이 무엇인지는 논의조차 되지 않았다.

이 미팅은 UN 총회와 무엇이 다른가?

대사와 리더의 차이

UN 총회에서 각국의 대사는 자국의 이익을 대표한다. 그것이 그들의 역할이다. 양보는 최소화하고, 자국에 유리한 결과를 이끌어내는 것이 유능한 대사의 조건이다. 대사에게 "당신 나라 이익 좀 포기하고 전체를 위해 양보하세요"라고 말하면 어이없어할 것이다.

그런데 많은 리더십팀이 정확히 이 UN 모델로 작동한다. 엔지니어링 리드는 개발팀의 대사, 프로덕트 리드는 PM 조직의 대사, 디자인 리드는 디자인팀의 대사. 각자 자기 부서의 이익을 대변하기 위해 미팅에 온다. 미팅의 결과는 각 부서 이익의 타협점이지, 조직 전체를 위한 최선의 결정이 아니다.

여기서 근본적인 질문이 생긴다. 리더십팀에 앉아 있는 리더들의 정체성은 무엇인가? 그들은 부서의 대사인가, 조직의 리더인가?

내가 경험을 통해 확신하게 된 것은 이것이다. 리더십팀에서 내 첫 번째 팀은 내가 이끄는 팀이 아니라, 내가 속한 리더십팀이다. 엔지니어링 리드로서 나의 1순위 팀은 개발팀이 아니라 리더십팀이어야 한다. 이것은 개발팀을 소홀히 하라는 뜻이 아니다. 리더십팀에서 내린 결정이 조직 전체에 가장 좋은 결정이 되어야, 결국 개발팀도 더 나은 환경에서 일할 수 있다는 뜻이다.

대사는 자국에 불리한 결정에 반대한다. 리더는 자기 부서에 불리하더라도 조직 전체에 좋은 결정이면 지지한다. 이 차이가 UN 총회와 리더십팀을 구분한다.

하나의 팀, 하나의 점수

축구 경기를 생각해 보자. 미드필더가 경기 후 인터뷰에서 이렇게 말한다. "저는 오늘 패스 성공률 94%를 기록했습니다. 제 역할은 충분히 했다고 생각합니다." 그런데 팀은 0-3으로 졌다. 이 미드필더는 좋은 경기를 한 것인가?

당연히 아니다. 축구에서 개인 기록이 아무리 좋아도 팀이 지면 의미가 없다. 모든 선수는 같은 점수를 받는다. 이긴 팀의 벤치 선수도 이긴 것이고, 진 팀의 MVP도 진 것이다. 하나의 팀, 하나의 점수.

조직도 마찬가지여야 한다. 엔지니어링팀이 모든 기술 지표를 달성했지만 회사 전체가 분기 목표를 놓쳤다면, 엔지니어링 리드도 실패한 것이다. 마케팅팀이 캠페인 성과를 초과 달성했지만 제품이 제때 출시되지 않아 매출이 빠졌다면, 마케팅 리드도 그 책임에서 자유롭지 않다.

이것이 불공평하게 느껴질 수 있다. "내 팀은 잘했는데 왜 나까지 실패인가?" 하지만 이 불공평함을 받아들이는 것이 리더십팀의 구성원이 되는 것의 의미다. 내 부서의 성과가 좋으면서 회사 전체가 안 좋다면, 그것은 내가 리더십팀의 리더로서 충분히 기여하지 못했다는 뜻이기도 하다. 다른 부서의 문제를 함께 풀었어야 했고, 자원 배분에 대해 더 적극적으로 의견을 냈어야 했고, 조직 전체의 병목을 해소하는 데 나서야 했다.

하나의 팀, 하나의 점수를 받아들이면, 리더십 미팅의 풍경이 바뀐다. "우리 팀 입장에서는"이라는 말 대신 "회사 전체로 볼 때"라는 말이 나오기 시작한다. 다른 부서의 문제가 더 이상 남의 일이 아니게 된다. 자원이 부족한 팀을 돕는 것이 내 부서의 이익을 줄이는 것이 아니라, 우리 모두의 점수를 올리는 것이 된다.

왜 부서 이익을 내려놓기 어려운가

그런데 왜 이것이 말처럼 쉽지 않을까?

첫 번째는 정체성의 문제다. "나는 엔지니어링 리드다." 이 문장에서 정체성은 엔지니어링에 있다. 리더십팀의 구성원이라는 정체성은 부차적이다. 매일 함께 일하는 사람은 개발팀 팀원들이고, 리더십 미팅은 일주일에 한두 번이다. 자연스럽게 소속감은 부서에 더 강하게 형성된다.

두 번째는 부서원들의 기대다. 리더가 리더십 미팅에서 돌아올 때, 팀원들은 묻는다. "우리한테 유리한 결과가 나왔나요?" 리더가 "사실 우리 팀에는 좀 불리하지만 회사 전체를 위해 이렇게 결정됐다"고 말하면, 팀원들은 실망할 수 있다. "우리 리드가 우리 편을 안 들어주네."

이 순간의 두려움이 크다. 리더십 미팅에서 조직 전체를 위해 양보한 리더가, 부서로 돌아가면 배신자 취급을 받을까 걱정하는 것이다. 그래서 많은 리더들은 리더십 미팅에서 자기 부서의 이익을 최대한 지키려 한다. 부서로 돌아가서 "승리"를 보고하기 위해.

하지만 나는 이 두려움이 대부분 과장되어 있다고 생각한다. 팀원들이 정말로 원하는 것은 "우리 편만 드는 리더"가 아니다. 그들이 원하는 것은 "회사가 잘 되게 만드는 리더"다. 조직이 잘 되어야 팀도 잘 되고, 팀이 잘 되어야 개인도 잘 된다는 것을 대부분의 팀원들은 알고 있다.

물론 그 결정의 배경을 제대로 설명해야 한다. "그냥 결정됐어"가 아니라, "이런 이유로 이 결정이 조직 전체에 가장 좋다고 판단했고, 우리 팀에는 이런 영향이 있지만, 장기적으로는 이런 이점이 있다"고 말해야 한다. 투명한 설명 없이 양보만 가져오면, 팀원들의 불만은 당연하다.

조직의 리더로 서는 연습

UN 모델에서 벗어나는 것은 한 번의 결심으로 되지 않는다. 습관을 바꿔야 한다. 몇 가지 구체적인 연습이 도움이 된다.

첫째, 리더십 미팅에서 발언할 때 주어를 바꾸는 것이다. "개발팀 입장에서는"을 "회사 전체로 볼 때"로 바꿔 보자. 단순한 언어의 변화지만, 이 변화가 사고의 프레임을 바꾼다. "개발팀 입장에서는 일정이 부족합니다"와 "회사 전체로 볼 때 이 일정에서 가장 큰 리스크는 품질입니다"는 같은 문제를 다른 시야로 본다. 전자는 부서의 어려움을 호소하는 것이고, 후자는 조직의 의사결정에 기여하는 것이다.

둘째, 다른 부서의 문제에 먼저 나서는 것이다. 마케팅팀이 어려움을 겪고 있을 때, "그건 마케팅 이슈니까"라고 넘기는 대신 "우리 팀에서 도울 수 있는 부분이 있을까?"라고 묻는다. 이것은 선의만의 문제가 아니다. 마케팅의 문제가 해결되지 않으면 결국 회사 전체의 점수가 내려가고, 그것은 내 점수이기도 하다.

셋째, 결정이 내려진 후에 그것을 진심으로 지지하는 것이다. 리더십 미팅에서 충분히 토론한 후 결정이 내려지면, 설령 내가 원래 다른 의견이었더라도, 그 결정을 부서에 돌아가서 적극적으로 지지해야 한다. "나는 반대했는데 그렇게 결정됐어"라고 말하는 순간, 리더십팀의 결정은 힘을 잃는다. 그리고 팀원들은 리더십팀이 하나의 팀이 아니라 각자 따로 노는 집단이라고 느끼게 된다.

당신은 리더십 미팅에서 부서의 대사로 앉아 있는가, 조직의 리더로 앉아 있는가? 다음 미팅에서 "우리 팀 입장에서는"이라는 말이 나오려 할 때, 한 번만 멈춰 보자. 그리고 "회사 전체로 볼 때"로 시작해 보자. 그 작은 전환이 리더십팀을 UN 총회에서 진짜 팀으로 바꾸는 첫걸음이 될 수 있다.

행동을 지적할 것인가, 성과를 지적할 것인가

Mon, 30 Mar 2026 11:00:00 GMT

분기 리뷰 자리에서였다. 한 리더의 팀은 목표 매출을 달성했다. 숫자만 보면 나무랄 데가 없었다. 그런데 그 팀의 이직률은 조직에서 가장 높았고, 다른 팀과의 협업 요청은 번번이 무산되었으며, 팀원들의 표정은 성과를 달성한 사람들의 것이 아니었다. 나는 이 리더에게 뭐라고 말해야 할까? 숫자는 좋았으니 "수고했다"고 해야 할까, 아니면 보이지 않는 문제를 꺼내야 할까?

이 상황에서 많은 리더가 침묵을 택한다. 숫자가 좋으니까. 측정 가능한 성과가 달성되었으니까. 하지만 숫자 뒤에 숨으면, 진짜 문제는 계속 자란다.

측정할 수 있는 것의 유혹

우리는 측정할 수 있는 것에 끌린다. 매출, 완료한 프로젝트 수, 고객 만족도 점수, 스프린트 속도. 이런 지표들은 명확하다. "이번 분기 목표 대비 92%를 달성했다"는 말에는 논쟁의 여지가 적다. 그래서 피드백하기 편하다. 숫자가 나를 대신 말해 주니까.

반면 행동은 모호하다. "회의에서 다른 팀의 의견을 자주 끊는다", "약속한 기한을 조용히 넘긴다", "팀원들 앞에서는 동의하고 뒤에서는 다른 이야기를 한다." 이런 행동들은 KPI에 잡히지 않는다. 측정할 수 없으니 피드백의 대상이 되지 못한다.

건강검진을 떠올려 보자. 어떤 의사는 혈압, 혈당, 콜레스테롤 수치만 본다. 숫자가 정상이면 "건강합니다"라고 말한다. 또 다른 의사는 수치를 본 뒤에 생활습관을 묻는다. 수면은 충분한지, 운동은 하는지, 스트레스는 어떻게 관리하는지. 수치가 정상이어도 생활습관이 나쁘면 "지금은 괜찮지만, 이대로 가면 문제가 생길 겁니다"라고 말한다.

어느 의사가 더 좋은 의사인가? 답은 분명하다. 수치만 보는 의사는 문제가 발생한 후에야 반응한다. 생활습관까지 보는 의사는 문제가 발생하기 전에 경고한다.

조직에서 성과만 피드백하는 리더는 수치만 보는 의사와 같다. 숫자가 무너진 후에야 "왜 이렇게 됐지?"라고 묻는다. 하지만 그때는 이미 늦은 경우가 많다. 행동까지 보는 리더는 숫자가 무너지기 전에 신호를 읽는다.

행동 피드백이 어려운 진짜 이유

그런데 왜 대부분의 조직에서 행동에 대한 피드백은 잘 이루어지지 않을까?

첫 번째 이유는 주관성이다. 성과는 숫자로 이야기할 수 있지만, 행동은 해석이 필요하다. "회의에서 상대의 말을 끊었다"는 관찰은 비교적 객관적이지만, "팀의 분위기를 나쁘게 만든다"는 이미 판단이 섞여 있다. 이 판단이 나만의 해석인지, 모두가 공감하는 것인지 확신이 없다. 확신이 없으니 말을 꺼내기가 어렵다.

두 번째는 더 본질적인 문제다. 성과 피드백은 '일'에 대한 이야기이지만, 행동 피드백은 '사람'에 대한 이야기처럼 느껴진다는 것이다. "이번 분기 매출이 목표에 못 미쳤다"는 말은 업무 결과에 대한 평가다. 하지만 "당신이 회의에서 다른 사람의 말을 자주 끊는다"는 말은 인격에 대한 공격처럼 들릴 수 있다. 피드백을 주는 사람도 그게 두렵고, 받는 사람도 그렇게 느끼기 쉽다.

세 번째는 책임 추궁과 갈등을 혼동하는 것이다. 동료의 행동에 대해 이야기하는 것은 갈등을 일으키는 것이 아니라, 팀의 약속을 확인하는 것이다. 하지만 우리 머릿속에서 이 둘은 쉽게 구분되지 않는다. 행동을 지적하면 갈등이 생길 것 같고, 갈등은 피하고 싶으니 행동 피드백도 피하게 된다.

결과적으로 팀에서 일어나는 일은 이렇다. 성과 리뷰에서는 숫자 이야기만 한다. 행동에 대해서는 아무도 말하지 않는다. 그리고 숫자가 어느 날 갑자기 무너졌을 때, 모두가 놀란다. 사실은 갑자기가 아니었는데.

성과 전에 행동이 먼저 무너진다

대부분의 성과 문제는 갑자기 발생하지 않는다. 행동이라는 선행 지표가 먼저 신호를 보낸다.

회의에 자주 늦는 리더가 있다. 5분, 10분. 큰일은 아닌 것 같다. 하지만 이 행동이 반복되면 팀의 리듬이 깨진다. 다른 리더들도 시간을 덜 엄격하게 지키기 시작한다. 회의 시작이 매번 밀리고, 논의할 시간이 줄어들고, 중요한 결정이 다음으로 미뤄진다. 몇 달 뒤 프로젝트가 지연된다. 그때서야 "왜 일정이 밀렸지?"라고 묻지만, 뿌리는 훨씬 전에 시작되었다.

다른 팀의 요청을 무시하는 리더가 있다. 처음에는 "바빠서 못 봤다"는 핑계로 넘어간다. 하지만 이것이 패턴이 되면 협업이 끊긴다. 다른 팀들은 아예 요청을 하지 않게 된다. 각 팀이 독자적으로 움직이기 시작하고, 중복 작업이 생기고, 전체 효율이 떨어진다. 분기 성과가 나빠졌을 때 원인을 분석하면 "협업 부재"라는 결론이 나오지만, 그 시작은 한 리더의 반복된 무응답이었다.

이것이 내가 행동을 '연기 감지기'에 비유하는 이유다. 성과 지표는 화재 경보기다. 불이 나야 울린다. 하지만 행동은 연기 감지기다. 아직 불이 나지 않았지만, 연기가 피어오르고 있다는 것을 알려준다. 연기 감지기 없이 화재 경보기만 설치한 건물은 안전한 것 같지만, 실제로는 대응할 시간을 잃는다.

행동을 피드백하지 않는 조직은 연기 감지기 없이 운영되는 건물과 같다. 성과가 무너진 후에야 반응하고, 그때는 이미 손실이 크다.

어떻게 행동을 이야기할 것인가

행동 피드백이 어렵다는 것은 인정해야 한다. 하지만 어렵다고 피할 수는 없다. 방법은 있다. 핵심은 세 가지 요소를 갖추는 것이다. 구체적인 장면, 그 행동의 영향, 그리고 기대하는 변화.

"당신의 태도가 문제입니다"는 피드백이 아니다. 이것은 판단이다. 이런 말을 들으면 누구든 방어적이 된다.

대신 이렇게 말할 수 있다. "지난 수요일 기획 회의에서 마케팅팀이 제안을 설명하는 중간에 두 번 말을 끊으셨어요. 그 후로 마케팅팀 쪽에서 발언이 거의 없었고, 결론이 한쪽으로만 기울어진 채 끝났습니다. 다음 회의에서는 상대 팀이 설명을 마칠 때까지 기다려 주시면, 더 균형 잡힌 논의가 될 것 같습니다."

차이가 느껴지는가? 앞의 말은 사람을 공격한다. 뒤의 말은 장면을 묘사하고, 영향을 설명하고, 구체적인 변화를 제안한다. 같은 문제를 이야기하지만, 받아들이는 사람의 경험은 완전히 다르다.

물론 이 공식을 안다고 해서 쉬워지는 것은 아니다. 여전히 불편하다. 하지만 최소한 "어떻게 말해야 할지 모르겠다"는 핑계는 줄어든다. 구조가 있으면 용기의 문턱이 낮아진다.

그리고 한 가지 더. 행동 피드백은 부정적인 것만이 아니다. "지난 프로젝트에서 매주 진행 상황을 먼저 공유해 주신 덕분에 다른 팀과의 조율이 훨씬 수월했습니다"도 행동 피드백이다. 좋은 행동을 구체적으로 이야기해 주면, 그 행동은 강화된다. 행동 피드백의 근육은 긍정적인 것부터 훈련하면 훨씬 쉽게 붙는다.

당신의 팀에서 마지막으로 누군가의 행동에 대해 이야기한 것은 언제인가? 숫자가 아닌, 그 사람의 행동에 대해서. 만약 기억이 나지 않는다면, 지금 당신의 팀에는 연기 감지기가 없는 셈이다. 불이 나기 전에, 연기를 먼저 이야기하자.

불편한 지적이 팀을 살린다

Mon, 30 Mar 2026 10:00:00 GMT

리더 미팅이 끝나고 각자 자리로 돌아가는 길이었다. 한 리더가 지난주에 약속한 일을 하지 않았다. 미팅에 참석한 모든 리더가 그 사실을 알고 있었다. 하지만 아무도 말하지 않았다. 그 대신 시선이 자연스럽게 나에게로 향했다. 결국 내가 지적했다. 미팅이 끝나고 몇몇 리더가 슬쩍 다가와 말했다. "말씀하시길 잘했어요. 저도 신경 쓰이긴 했거든요."

그 순간 드는 생각이 있었다. 신경이 쓰였다면, 왜 직접 말하지 않았을까?

이것은 리더 한 명의 용기 문제가 아니다. 팀이 책임을 다루는 방식의 문제다. 그리고 이 문제를 풀지 못하면, 결국 모든 책임은 한 사람에게로 돌아간다.

관리자의 짐을 동료에게 나누는 법

축구 경기를 떠올려 보자. 감독만 선수를 야단치는 팀이 있고, 선수들끼리 서로 독려하고 지적하는 팀이 있다. 어느 팀이 더 강할까?

답은 명확하다. 선수들 사이에서 자발적으로 책임을 묻는 팀이 훨씬 강하다. 감독이 모든 상황을 볼 수는 없다. 경기장 안에서 벌어지는 일은 함께 뛰는 동료가 가장 잘 안다. 상대 수비를 제대로 안 따라간 동료에게 "야, 뒤를 봐!"라고 소리치는 것. 그것이 경기의 승패를 가른다.

조직도 마찬가지다. 리더가 여럿인 팀에서 책임을 묻는 역할이 오직 한 사람, 보통은 CEO나 CTO에게만 집중되어 있다면, 그 팀은 구조적으로 약하다. 한 사람이 모든 리더의 업무 이행을 추적하고, 미달 시 지적하고, 개선을 요구하는 것은 물리적으로 불가능하다. 설령 가능하더라도, 그것은 동료 간의 약속이 아니라 상하 관계의 감시가 된다.

반면 동료 리더들이 서로의 약속 이행을 확인하고, 미달 시 직접 이야기하는 팀이 있다. 이 팀에서는 책임의 무게가 한 사람에게 쏠리지 않는다. 모든 리더가 서로에게 책임을 묻기 때문에, 압박은 분산되고 효과는 배가된다. 감독 혼자 외치는 것보다 동료 선수 네 명이 함께 외치는 것이 훨씬 강력한 것처럼.

이것이 내가 동료 간 상호 피드백이 가장 효과적인 책임 시스템이라고 생각하는 이유다.

왜 우리는 동료의 문제를 외면하는가

그렇다면 왜 대부분의 팀에서 이런 상호 피드백이 자연스럽게 일어나지 않을까?

가장 큰 이유는 관계에 대한 두려움이다. "내가 지적하면 관계가 틀어지지 않을까?" 이 두려움은 매우 인간적이다. 특히 리더들 사이에서는 더 그렇다. 서로의 전문성을 존중하는 관계에서, 상대의 영역에 대해 뭔가를 지적한다는 것은 마치 그 사람의 역량을 의심하는 것처럼 느껴진다.

두 번째는 역할에 대한 착각이다. "그건 CEO가 할 일이지, 내가 할 일이 아니야." 이 생각에는 묘한 편안함이 있다. 책임을 묻는 불편함을 윗사람에게 위임하면, 나는 좋은 동료로 남을 수 있다. 하지만 그 결과 CEO만 '나쁜 역할'을 맡게 되고, 나머지 리더들은 방관자가 된다.

세 번째는 더 근본적인 문제인데, 지적과 갈등을 혼동하는 것이다. 동료에게 "지난주에 약속한 건 어떻게 됐어?"라고 묻는 것은 갈등이 아니다. 합의한 약속의 이행을 확인하는 것이다. 하지만 많은 사람들이 이 질문 자체를 갈등의 시작으로 느낀다.

아이러니한 것은, 지적을 피하면 관계가 보존될 것 같지만 실제로는 반대라는 점이다. 문제를 외면하면 그것은 사라지지 않는다. 대신 불만으로 쌓인다. 회의실에서 말하지 못한 것들이 복도에서 뒷담화가 되고, 슬랙 DM에서 푸념이 된다. 지적하지 않는 것이 관계를 보호한다는 생각은 착각이다. 오히려 솔직하게 이야기한 후에 관계가 더 단단해지는 경험을 한 적이 있을 것이다. 불편한 대화 후에 "아, 이 사람은 진심으로 이야기해 주는 사람이구나"라는 신뢰가 생기는 순간 말이다.

불편함을 시스템으로 만들기

문제는 이 불편함이 '개인의 용기'에 의존해서는 지속되지 않는다는 것이다. 용기 있는 한두 사람이 지적을 하다가 지치면, 팀은 다시 침묵으로 돌아간다. 불편함을 시스템으로 만들어야 한다.

내가 효과적이라고 느낀 방법은 단순하다. 리더들이 일정 주기로 모여서, 서로에게 딱 한 가지씩 이야기하는 시간을 갖는 것이다. "당신이 팀에 더 기여하기 위해 한 가지 더 잘했으면 하는 것"을 직접 말한다.

처음 이 훈련을 시도했을 때, 분위기는 당연히 어색했다. 서로 눈을 잘 마주치지 못했고, 말을 꺼내기까지 긴 침묵이 흘렀다. 그런데 한 사람이 먼저 입을 열자 흐름이 바뀌었다. 첫 번째 피드백이 나오면 두 번째는 훨씬 쉬워진다. 세 번째부터는 분위기가 완전히 달라진다. 놀라운 것은 피드백을 받는 사람들의 반응이었다. 대부분 방어적이지 않았다. 오히려 "아, 그게 그렇게 보였구나"라며 고개를 끄덕이는 경우가 많았다.

이 훈련의 핵심은 피드백의 내용이 아니다. 팀 안에서 서로의 행동에 대해 이야기하는 것이 정상적인 일이라는 경험을 만드는 것이다. 한번 이 경험을 하고 나면, 일상에서도 동료에게 뭔가를 이야기하는 것이 조금 덜 어려워진다. 완전히 편해지지는 않는다. 하지만 "우리는 서로에게 이런 이야기를 하는 팀이다"라는 기준이 생긴다. 그 기준이 생기면, 침묵은 더 이상 예의가 아니라 회피가 된다.

중요한 것은 이 피드백이 일회성 이벤트가 아니라 반복 가능한 루틴이어야 한다는 점이다. 분기에 한 번이든, 중요한 프로젝트가 끝난 후든, 팀이 정기적으로 이 시간을 갖는 것이 핵심이다. 피드백은 근육과 같아서, 쓰지 않으면 약해진다.

지적이 아니라 기대의 표현이다

여기서 한 가지 프레이밍을 바꿔보고 싶다. 우리는 이것을 '지적'이라고 부르지만, 본질적으로는 '기대의 표현'이다.

동료에게 "지난번 미팅에서 약속한 자료가 아직 안 나왔다"고 말하는 것은, 그 동료에게 기대가 있기 때문이다. 기대가 없는 사람에게는 지적도 하지 않는다. 포기한 관계에서는 불편한 대화가 필요 없다. 그냥 거리를 두면 된다.

그래서 동료의 문제를 지적하는 것은 사실 이렇게 말하는 것과 같다. "나는 당신이 더 잘할 수 있다고 믿는다. 그리고 이 팀이 함께 더 나아질 수 있다고 믿는다." 불편한 말을 건네는 것이 신뢰의 부재가 아니라 신뢰의 증거라는 것을 팀원들이 이해하면, 피드백의 의미가 달라진다.

물론 모든 지적이 기대의 표현이 되려면 전제가 있다. 진심이어야 한다. 자기 불편함을 해소하기 위한 지적, 우위를 점하기 위한 지적은 기대가 아니라 공격이다. 그 차이를 구분하는 것은 결국 '이 말을 하는 이유가 이 사람과 이 팀을 위한 것인가'라는 질문에 솔직하게 답하는 것이다.

당신의 팀에서 동료 리더에게 마지막으로 불편한 말을 건넨 것은 언제인가? 만약 기억이 나지 않는다면, 지금 당신의 팀에서 책임은 누구의 몫인가?

나라는 이야기의 작가는 누구인가

Fri, 27 Mar 2026 12:00:00 GMT

밤하늘을 올려다본다. 별들이 흩어져 있다. 우리는 그 별들을 보고 별자리를 찾는다. 곰을 닮았다, 전갈을 닮았다, 국자를 닮았다. 하지만 별들은 그냥 거기 있을 뿐이다. 곰의 형상도, 전갈의 꼬리도 실제로는 존재하지 않는다. 수천 광년 떨어진 별들을 하나의 패턴으로 묶은 건 순전히 우리 뇌의 작업이다.

그런데 별자리만 그런 걸까. '나'라는 것도 마찬가지는 아닐까. 머릿속의 생각을 단지 흐름으로 보지 않고, 구체적인 '대상'으로 붙잡아서 '나'라는 이름표를 붙이는 건 아닐까. 가자니가는 이 질문에 명확한 답을 내렸다. 자아는 좌뇌의 해석 장치가 만든 이야기라고.

소설 같은 자아

앞선 글들에서 좌뇌의 해석 장치가 어떻게 작동하는지, 그리고 그것이 어떻게 확신을 만들어내는지 이야기했다. 빈칸을 채우고, 그럴듯한 설명을 붙이고, 거기에 절대적 확신까지 부여하는 좌뇌. 가자니가는 여기서 한 걸음 더 나아간다. 이 해석 장치의 궁극적인 작품이 바로 '자아'라고.

가자니가는 1998년 저서 《마음의 과거(The Mind's Past)》에서 이를 '소설 같은 자아(The Fictional Self)'라고 명명했다. 자아가 소설처럼 지어낸 것이라니. 이것은 마치 지구가 평평하다고 믿었던 사람들이 지구가 둥글다는 말을 처음 들었을 때와 비슷한 충격일 수 있다. 하지만 가자니가는 이것이 실험적으로 입증 가능한 사실이라고 말한다.

우리 삶에서 무수히 일어나는 사건과 경험. 좌뇌는 이것들을 하나의 일관된 이야기로 엮는다. "나는 이런 사람이다", "나는 이런 가치를 중요하게 여긴다", "나는 이런 이유로 이 선택을 했다". 이 서사가 곧 '나'다. 하지만 분리뇌 연구가 보여주듯, 이 서사는 사실의 충실한 기록이 아니다. 해석 장치가 가용한 정보만으로 짜맞춘 이야기다. 때로는 빈칸을 상상으로 채우고, 때로는 현실을 무시하면서.

마음이 해석을 만든다

자아가 구성물이라는 증거는 분리뇌 연구 외에도 곳곳에서 발견된다. 특히 감정과 각성 상태가 해석을 바꾸는 실험들이 인상적이다.

유명한 '흔들다리 실험'이 있다. 남성 피험자들에게 두 가지 다리를 건너게 했다. 하나는 안전한 다리, 다른 하나는 높이 1.5미터의 가파르고 흔들리는 위험한 다리. 다리를 건넌 뒤, 다리 끝에서 여성 조교가 설문지를 건네고 연락처를 알려줬다. 결과는 놀라웠다. 위험한 다리를 건넌 남성들이 여성 조교에게 훨씬 더 많이 전화를 걸었다. 그들의 뇌는 다리에서 느낀 신체적 흥분(심장 박동, 땀, 긴장)을 여성에 대한 매력으로 해석한 것이다.

롤러코스터를 탄 뒤 연인의 사진을 보면 매력 점수가 올라간다는 연구도 있다. 흥분 상태에서 유발된 각성을, 좌뇌가 "이 사람이 매력적이기 때문"으로 해석하는 것이다. 다시 말해, 당신 이야기보다 당신의 좌뇌에 이미 연인이 있다면 어떤 놀이기구도, 어떤 감성적 자극도 낯선 사람의 매력도를 높이지 않는다.

이것이 의미하는 바는 크다. 우리가 느끼는 감정, 판단, 끌림의 상당 부분이 상황에 의해 촉발된 신체 반응을 좌뇌가 '해석'한 결과라는 것이다. 화가 나서 화를 내는 것이 아니라, 신경계가 흥분한 상태에서 좌뇌가 "화"라는 이름표를 붙이는 것일 수 있다. 두려워서 피하는 것이 아니라, 몸이 경직된 상태에서 좌뇌가 "두려움"이라는 서사를 입히는 것일 수 있다.

2500년 전에도 같은 이야기를 했다

가자니가의 연구를 접하고 놀란 것이 하나 있다. 동양의 영적 전통에서 2500년 동안 계속해서 이야기해온 것을 현대 신경과학이 실험으로 확인하고 있다는 점이다.

불교는 무아(無我)를 말한다. '나'라고 할 만한 고정된 실체는 없다는 가르침이다. 도교 경전인 도덕경과 힌두교의 불이일원론에서도 같은 내용을 찾을 수 있다. 자아란 임의적인 움직임 속에서 어떤 패턴을 보려는 것과 관련이 있지 않을까. 우리가 그토록 개발하려 애쓰는 자아란, 실은 지어낸 것이라고 분명하게 말한다.

자아가 허상임을 깨달으면 고통으로부터 해방된다고 동양 철학은 가르친다. 어떻게 그런 관계가 성립하는 걸까. 좌뇌가 만들어낸 이야기가 인간으로서 겪는 내적 고통의 가장 두드러진 원인이기 때문이다. 내 친구가 하는 직장 동료들이 자기를 좋아하지 않는다고 확신했다. 그 확신이 점점 심각해져서 출근이 무서워질 지경이었다. 그런데 어느 날, 자신의 동료들에게 직접 물었더니 오히려 정반대였다. 좌뇌가 단편적인 정보로 만든 이야기에 자기 자신이 갇혀 있었던 것이다.

반면 서양 심리학은 이 통찰을 경험적으로 찾아왔다. 실험을 통해, 그 의도도 없이 우연히 찾아왔다. 가자니가도 이렇게 말한다. 좌뇌의 해석 장치를 인식하는 것이 그 힘을 줄이는 시작이라고.

이야기를 알아차리는 순간

지금부터 10초간 주위를 천천히 둘러보고, 눈에 들어오는 것을 마음속으로 나열해 보라. 나 끝나면 다시 읽기로 돌아온다.

무엇을 나열했나. 아마도 책상, 의자, 나무, 차, 컴퓨터 같은 사물일 것이다. 하지만 빈 공간을 나열한 사람은 거의 없을 것이다. 주위를 둘러볼 때 보이는 것 중 압도적으로 많은 부분이 바로 빈 공간인데도, 좌뇌는 사물에 초점을 맞추고 이름표를 붙이고 분류한다. 빈 공간은 무시된다. 자아도 이와 같다. 무수한 경험의 흐름 속에서 좌뇌가 특정한 것들만 골라 '나'라는 이름으로 묶은 것이다.

이것을 아는 것과 모르는 것의 차이는 크다. 일상에서 벌어지는 일을 보자. 교통 체증의 한가운데서 어떤 차가 불쑥 내 앞을 끼어든다. 즉각적으로 화가 치밀어 오른다. 매력적인 사람을 만나면 즉시 호감이 생긴다. 머릿속에서 목소리가 들려온다. "저런 미친놈을 봤나", "뭔가 있는 게 있는 모양이군", "저 사람 나한테 관심 있나 봐". 이 목소리가 해석 장치의 작동이다.

해석은 맞을 수도 있고 틀릴 수도 있다. 문제는, 많은 경우 좌뇌의 해석 장치를 의식하지 못한 채 살기고 있다는 것이다. 사람들은 사건을 보고 판단하고 해석을 믿은 뒤에 그것이 정말 사실인지 의심하지 않는다. 하지만 해석 장치의 존재를 알고 있으면, 한 가지가 달라진다. "방금 머릿속에서 만들어진 이 판단, 이것은 사실인가 해석인가?"라는 질문을 던질 수 있게 된다.

비록 해석 장치는 항상 켜져 있고 끌 수 없지만, 일단 그것이 끊임없이 작동하고 있다는 걸 한 번이라도 눈치채면, 자신과 세상을 바라보는 새로운 시야가 트인다. 머릿속의 '나'에 대해 아무런 의심도 없이 인정하는 대신, "방금 머릿속에서 만들어진 이 판단은 사실일까 해석일까"라고 물을 수 있게 된다. 그러면 좌뇌의 해석이 만들어낸 이야기가 이전만큼 우리의 정신과 감정을 강하게 흔들지 못할 것이고, 결과적으로 고통은 감소될 것이다.

밤하늘의 별을 보며 별자리를 찾는 것은 아름다운 일이다. 하지만 그것이 별 자체가 아니라 내가 만든 패턴이라는 것을 아는 순간, 같은 하늘이 다르게 보인다. '나'를 들여다보는 것도 마찬가지다. 똑같은 실수를 날마다 저지르는 것도, 같은 감정에 매번 휘둘리는 것도, 어쩌면 '나'라는 게 있다고 믿기 때문일 수 있다. 이야기의 작가가 누구인지 알아차리는 것. 거기서부터 다른 종류의 자유가 시작된다.

확신이 강할수록 의심해야 하는 이유

Fri, 27 Mar 2026 11:00:00 GMT

회의에서 내가 강하게 밀었던 방향이 있었다. 근거도 충분했고, 논리도 깔끔했다. 팀원들이 다른 의견을 냈지만 나는 확신이 있었다. 그래서 밀어붙였다. 몇 주 뒤, 그 판단이 틀렸다는 게 드러났다. 돌아보니 당시 팀원들의 반론이 더 정확했다. 그때 느꼈던 그 강한 확신은 대체 어디서 온 것이었을까. 이상한 건, 틀렸다는 사실을 알고 난 뒤에도 당시의 확신이 '가짜'였다는 느낌이 들지 않는다는 것이다. 그만큼 확신은 생생하고 설득력 있었다.

이전 글에서 좌뇌의 해석 장치를 이야기했다. 뇌가 빈칸을 채우기 위해 자동으로 이야기를 만들어낸다는 것. 그런데 해석 장치에는 한 가지 더 무서운 특징이 있다. 만들어낸 이야기에 절대적인 확신을 부여한다는 점이다.

틀린 설명에 붙은 절대적 확신

가자니가의 분리뇌 실험에서 가장 놀라운 부분은 환자들의 대답이 틀렸다는 것이 아니다. 그 대답에 보인 확신의 강도다.

닭발과 눈 풍경 실험을 떠올려 보자. 환자는 왼손으로 삽을 고른 이유를 "닭장 청소에 필요하니까"라고 설명했다. 이 설명은 완전히 틀렸다. 하지만 환자에게 "정말요? 다시 생각해 보세요"라고 물으면, 환자는 자신의 답에 절대적인 확신을 보였다. 의심의 여지가 없다는 듯이. 더 흥미로운 건, 이 확신이 정답을 말할 때의 확신과 구별이 불가능하다는 점이다.

우뇌에 "웃으세요"라는 지시를 보여줬을 때도 마찬가지였다. 환자는 웃기 시작했고, 이유를 묻자 "당신들이 매번 와서 실험하니까 웃긴 거예요"라고 했다. 가자니가가 그 답에 의문을 제기해도 환자는 흔들리지 않았다. 자기 설명이 맞다고 굳게 믿었다. 좌뇌의 해석 장치는 이야기를 만들어낼 뿐 아니라, 그 이야기에 '진실'이라는 도장까지 찍어버린다.

현실을 부정하는 뇌

20세기의 가장 혁신적인 신경과학자 라마찬드란(V.S. Ramachandran)은 이 현상을 더 극적인 상황에서 관찰했다. 그가 연구한 것은 뇌졸중으로 왼쪽 몸이 완전히 마비된 환자들이었다. 이 환자들 중 일부는 자신의 마비를 인정하지 않았다. 의학에서 질병인식불능증(anosognosia)이라 부르는 상태다.

라마찬드란이 마비된 왼팔을 가리키며 "이 팔을 움직일 수 있나요?"라고 물으면, 환자는 자신 있게 "그럼요, 당연히 움직일 수 있죠"라고 답했다. 실제로 해보라고 하면 팔은 꿈적도 하지 않았다. 그런데 환자는 이렇게 말했다. "지금은 좀 피곤해서요." 또는 "오늘 하루 종일 의사들이 여기저기 수석 보고 갔단 말입니다. 지금은 팔을 움직이고 싶지 않은 거예요."

마비된 팔이 눈앞에 축 늘어져 있는데도, 좌뇌는 이 현실을 받아들이지 않았다. 대신 합리화를 시도했다. "피곤하다", "하기 싫다", "아프니까". 매번 다른 설명을 만들어냈고, 매번 확신에 차 있었다.

가자니가의 분리뇌 환자와 라마찬드란의 마비 환자가 보여주는 것은 같다. 좌뇌의 해석 장치는 현실이 자신의 이야기와 맞지 않을 때, 현실을 수정하는 것이 아니라 이야기를 수정한다. 그리고 수정된 이야기에도 같은 강도의 확신을 부여한다.

회의실에서 일어나는 같은 일

이 현상이 뇌 손상 환자에게만 일어난다고 생각하면 오산이다.

프로젝트가 실패했을 때를 떠올려 보라. 우리는 즉시 원인을 분석한다. "시장 타이밍이 안 맞았어", "리소스가 부족했어", "고객의 요구를 잘못 읽었어". 이 분석들은 그럴듯하다. 하지만 솔직히 물어보자. 그 분석은 사실의 재구성인가, 아니면 좌뇌가 불편한 실패에 설명을 붙이려는 시도인가. 많은 경우, 진짜 원인은 우리가 말한 것과 다르다. 하지만 해석 장치가 만든 설명이 워낙 그럴듯하고 확신에 차 있어서, 우리는 더 깊이 파고들지 않는다.

피드백을 받을 때도 같은 일이 벌어진다. 누군가 내 작업에 비판적 의견을 주면, 뇌는 즉시 방어 서사를 만든다. "저 사람은 맥락을 모르니까", "관점이 다른 거지 틀린 건 아니야", "내가 더 오래 고민한 건데". 이 생각들이 틀린 것은 아닐 수 있다. 문제는 이 생각이 얼마나 빠르고 자동적으로 생성되는지, 그리고 우리가 그것을 얼마나 즉각적으로 믿어버리는지다.

성공에 대해서도 마찬가지다. 좋은 결과가 나오면 우리는 그것을 자신의 판단과 노력 덕분이라고 해석한다. 물론 그것이 사실일 수도 있다. 하지만 운이 좋았거나, 팀원의 기여가 결정적이었거나, 시장이 우연히 좋았을 가능성은 쉽게 무시된다. 성공의 서사에서 좌뇌는 '나'를 주인공으로 만들고 싶어 한다.

확신을 의심하는 연습

그러면 어떻게 해야 할까. 해석 장치를 끌 수는 없다. 그것은 뇌의 기본 작동 방식이다. 하지만 인식할 수는 있다.

가자니가의 연구가 우리에게 주는 실질적인 교훈은 하나다. 확신의 강도는 정확성의 지표가 아니다. 완전히 틀린 설명에도 절대적 확신이 붙을 수 있다. 분리뇌 환자가 그랬고, 마비를 부정하는 환자가 그랬고, 매일의 회의실에서 우리가 그렇다.

실천할 수 있는 것은 간단하다. 확신이 강하게 느껴지는 순간, "이 확신은 어디서 왔지?"라고 한 번 물어보는 것이다. 내가 이 판단에 확신을 느끼는 건 정보가 충분해서인가, 아니면 좌뇌가 빈칸을 너무 매끄럽게 채워서인가. 이 질문 하나만으로 해석과 사실 사이에 한 뼘의 거리를 만들 수 있다.

특히 다음과 같은 상황에서 이 질문이 유효하다. 실패의 원인을 "확실히" 안다고 느낄 때. 누군가의 피드백이 "분명히" 틀렸다고 느낄 때. 내 선택의 이유를 "명확하게" 설명할 수 있다고 느낄 때. 이 '확실히', '분명히', '명확하게'라는 느낌 자체가 해석 장치의 서명일 수 있다.

확신이 흔들리는 순간은 불편하다. 하지만 분리뇌 연구가 보여주듯, 한 번도 흔들리지 않는 확신이야말로 가장 의심해봐야 할 것이다. 불편한 의심 속에 진실이 있고, 편안한 확신 속에 해석 장치의 소설이 숨어 있을 수 있다. 지금 당신이 가장 확신하는 그 판단 하나를 골라보라. 그리고 물어보라. 이것은 내가 안 것인가, 내 뇌가 지어낸 것인가.

뇌는 설명하고 싶다

Fri, 27 Mar 2026 10:00:00 GMT

얼마 전 후배에게 "그때 왜 그렇게 결정했어요?"라는 질문을 받았다. 나는 즉시 대답했다. 논리적이고 그럴듯한 이유를 세 가지나 댔다. 그런데 집에 오는 길에 문득 깨달았다. 그 이유들은 지금 만들어낸 것이었다. 당시에는 그냥 그래야 할 것 같아서 그랬을 뿐인데, 질문을 받으니 뇌가 순식간에 서사를 짜맞춘 것이다. 놀라운 점은, 대답하는 순간 나조차도 그것이 진짜 이유라고 믿었다는 것이다.

이것이 단순한 에피소드가 아니라 뇌의 기본 작동 방식이라는 사실을 알게 된 건, 반세기 전의 한 실험 덕분이었다.

뇌량을 자른 사람들

1960년대, 신경과학자 마이클 가자니가(Michael Gazzaniga)는 역사상 가장 흥미로운 뇌수술 실험을 진행했다. 당시 심한 간질 환자들의 증세를 완화하기 위해, 좌뇌와 우뇌를 연결하는 뇌량(corpus callosum)이라는 신경섬유 다발을 절단하는 수술이 시도되고 있었다. 로저 스페리(Roger Sperry)와 가자니가는 이 수술을 받은 환자들, 이른바 '분리뇌 환자(split-brain patient)'를 연구하기 시작했다.

뇌량이 잘리면 좌뇌와 우뇌는 서로 소통할 수 없게 된다. 평소에는 티가 나지 않는다. 하지만 좌뇌와 우뇌에 각각 다른 정보를 주면, 놀라운 일이 벌어진다. 좌우 반구는 몸을 교차로 지배한다. 오른쪽 시야는 좌뇌로, 왼쪽 시야는 우뇌로 연결된다. 그리고 언어를 담당하는 건 좌뇌다. 이 조합이 실험의 핵심이었다.

좌뇌의 해석 장치

가자니가의 초기 연구에서, 분리뇌 환자의 우뇌(왼쪽 시야)에 닭발 사진을, 좌뇌(오른쪽 시야)에 눈 덮인 풍경을 각각 보여주었다. 그리고 여러 장의 그림 중 관련 있는 것을 고르라고 했다. 환자의 오른손(좌뇌)은 닭을 골랐고, 왼손(우뇌)은 삽을 골랐다. 여기까지는 맞다. 닭발에는 닭이, 눈에는 삽이 연결된다.

문제는 이유를 물었을 때 벌어졌다. 말하기를 담당하는 건 좌뇌다. 좌뇌는 닭을 왜 골랐는지는 안다. 자기가 본 닭발 때문이다. 하지만 왼손이 삽을 고른 이유는 모른다. 눈 덮인 풍경은 우뇌만 봤고, 뇌량이 잘려 있으니 그 정보가 좌뇌에 전달되지 않았기 때문이다. 그럼에도 환자는 자신 있게 대답했다.

"닭을 골랐으니까, 닭장을 청소하려면 삽이 필요하잖아요."

완전히 틀린 설명이다. 하지만 환자는 이 답에 조금의 의심도 없었다. 좌뇌는 모르는 것을 "모른다"고 하지 않았다. 대신, 가지고 있는 정보만으로 즉석에서 그럴듯한 이야기를 만들어낸 것이다. 가자니가는 이것을 좌뇌의 '해석 장치(interpreter)'라고 불렀다.

이후의 실험에서도 패턴은 동일했다. 우뇌에 "웃으세요"라는 글자를 보여주면, 환자는 웃기 시작했다. 왜 웃느냐고 물으면 좌뇌는 이렇게 대답했다. "당신들이 실험 때문에 매번 여기 오잖아요. 참 별별 직업도 다 있다 싶어서 웃음이 나오네요." 매번 다른 상황, 매번 새로운 이야기. 하지만 하나같이 자연스럽고 확신에 차 있었다.

우리도 매일 같은 일을 하고 있다

분리뇌 환자의 이야기가 우리와 무슨 상관일까. 핵심은 이것이다. 뇌량이 잘리지 않은 우리도 근본적으로 같은 메커니즘으로 작동한다.

가자니가는 분리뇌 환자에게서 이 현상을 선명하게 관찰할 수 있었을 뿐이라고 말한다. 정상적인 뇌에서도 좌뇌의 해석 장치는 쉴 새 없이 돌아가고 있다. 우리가 매일 하는 일을 떠올려 보라. 누군가의 표정을 보고 "저 사람 나한테 화났나 봐"라고 판단한다. 교통 체증에서 불쑥 끼어드는 차를 보고 "저 사람은 성격이 급한 사람이야"라고 결론 짓는다. 매력적인 사람을 만나면 "이 사람은 뭔가 신뢰가 간다"고 느낀다.

이 모든 판단이 순식간에 만들어진 해석이다. 그리고 대부분의 경우, 우리는 그 해석이 '사실'이라고 믿는다. 해석 장치가 너무 빠르고, 너무 매끄럽게 작동하기 때문에 우리는 해석과 사실의 경계를 구분하지 못한다.

또 다른 초기 연구를 보자. 아무 문제가 없는 사람들에게 물건 몇 개를 보여주고, 마음에 드는 것을 고르게 했다. 그리고 이유를 물었다. 사람들은 "색깔이 예쁘잖아요", "질감이 마음에 들어요" 같은 이유를 댔다. 하지만 실험자들이 실제로 조작한 변수와 피험자들의 설명은 전혀 관계가 없었다. 사람들은 자신의 선택 이유를 정말로 모르면서도, 완벽하게 그럴듯한 설명을 만들어냈다. 그리고 그 설명이 진짜 이유라고 확신했다.

뇌가 침묵을 견디지 못하는 이유

왜 뇌는 이렇게 작동할까. 가자니가의 설명은 이렇다. 좌뇌는 우리가 경험하는 세상에 질서를 부여하는 것이 본업이다. 바깥 세상을 볼 때, 뇌는 사물에 초점을 맞추고, 이름표를 붙이고, 분류한다. 의미를 뽑아내고 패턴을 찾는다. 이 작업에 빈칸이 생기면 뇌는 불편해한다. 설명 없는 상태, 원인 없는 결과, 이유 없는 행동. 이런 공백은 뇌에게 일종의 경보다.

그래서 해석 장치는 공백을 채운다. 정보가 부족하면 부족한 대로, 틀리더라도 일단 이야기를 만든다. 침묵보다는 틀린 설명이 뇌에게 더 편안하다. 이것은 의식적인 선택이 아니다. 자동으로, 즉각적으로, 그리고 본인도 모르게 일어나는 과정이다.

돌이켜보면, 내가 후배에게 했던 대답도 정확히 이것이었다. 나는 당시의 이유를 모른다. 하지만 "모른다"는 대답은 뇌가 허용하지 않았다. 질문을 받자마자 해석 장치가 가동되어, 가용한 정보를 끌어모아 그럴듯한 서사를 조립했다. 그리고 나는 그 서사를 진심으로 믿으며 말했다.

이 사실이 불편한가. 나는 처음에 불편했다. 내 판단과 기억과 설명이 전부 사후적으로 조립된 이야기일 수 있다는 것은 꽤 충격적이다. 하지만 동시에 해방감도 있었다. 지금 당신이 확신하는 그 이유, 어젯밤 잠들기 전에 정리한 그 결론, 방금 누군가에게 한 그 설명. 그것이 정말 당신이 만든 것인지, 아니면 당신의 좌뇌가 침묵을 견디지 못해 급하게 지어낸 이야기인지. 한 번쯤 물어볼 가치가 있다.

무엇을 줄 것인가 — 이기적 이타주의자의 What

Fri, 27 Mar 2026 09:00:00 GMT

모든 일에는 두 가지 질문이 있다. 무엇을 할 것인가, 그리고 어떻게 할 것인가. 대부분의 사람은 후자에 시간을 쓴다. 어떤 기술을 배울까, 어떤 도구를 쓸까, 어떤 순서로 실행할까. 그런데 돌이켜 보면, 내 삶에서 가장 큰 변곡점은 항상 전자를 제대로 정의했을 때 찾아왔다.

나침반과 노

배를 젓는 데는 두 가지가 필요하다. 나침반과 노. 노를 잘 젓는 건 중요하다. 하지만 나침반 없이 노만 힘껏 저으면 방향 없는 원을 그릴 뿐이다. What은 나침반이고, How는 노다.

제품을 만들 때도 마찬가지다. 우리 팀은 대부분의 시간을 "우리가 풀어야 할 문제가 무엇인가"를 정의하는 데 쓴다. 디자이너든 개발자든 마케터든, 직군에 상관없이 모두가 이 질문 앞에 선다. 정작 코드를 작성하고, 디자인을 그리고, 캠페인을 실행하는 건 서너 시간이면 끝나는 경우가 많다. 검증까지 포함해도 그렇다. 아니다 싶으면 버리고 다시 시작한다. 실행이 빠른 건 우리가 특별히 뛰어나서가 아니다. What이 명확하면 How는 놀라울 정도로 빠르게 수렴한다.

AI가 이 구도를 더 극적으로 만들었다. 예전에는 실행 자체가 진입장벽이었다. 코드를 짜려면 개발을 배워야 했고, 디자인을 하려면 도구를 익혀야 했다. 지금은 아이디어만 있으면 누구든 프로토타입을 만들 수 있는 시대다. How의 민주화가 일어난 것이다. 그러면 남는 건 뭘까. What이다. 어떤 문제를 풀 것인가, 어떤 고객의 어떤 고통을 해소할 것인가. 이걸 정의할 수 있는 사람의 가치가 전에 없이 높아졌다.

위에서 내려오는 사고

나는 주니어와 시니어를 가르는 기준이 실력이 아니라 사고의 방향이라고 생각한다.

바텀업으로 사고하는 사람은 이렇게 생각한다. "이 일을 하면 돈을 벌 수 있지 않을까." 수단에서 출발해서 결과를 기대하는 방식이다. 반면 탑다운으로 사고하는 사람은 이렇게 묻는다. "1억을 벌려면 뭘 해야 할까." 목표에서 출발해서 수단을 역으로 찾는다. 1억을 버는 방법은 수십 가지다. 취업을 해도 되고, 물건을 떼와서 팔아도 되고, 서비스를 만들어도 된다. 탑다운으로 보면 선택지가 열린다. 바텀업으로 보면 내가 지금 할 수 있는 한 가지에 갇힌다.

이건 커리어에도 그대로 적용된다. "마케팅을 배우면 취업할 수 있지 않을까"는 바텀업이다. "내가 80대에 어떤 노인이고 싶은가"에서 역산해서 지금 뭘 해야 할지 찾는 건 탑다운이다. 후자의 시야에서 보면, 마케팅을 배우는 것도, 창업을 해보는 것도, 전혀 다른 업종에서 일해보는 것도 전부 같은 목표를 향한 서로 다른 경로일 뿐이다. 하나가 막히면 다른 길로 가면 된다.

문제는 대부분의 사람이 탑다운 사고를 훈련해본 적이 없다는 것이다. 학교에서 배우는 건 주어진 문제의 정답을 찾는 방법이지, 풀어야 할 문제를 정의하는 방법이 아니다. 그래서 이 전환에는 시간이 걸린다. 하지만 한 번 이 관점을 갖게 되면, 같은 세상이 다르게 보이기 시작한다.

기버의 두 운명

이 What의 감각은 일에서만 작동하는 게 아니다. 사람 사이에서도 똑같이 작동한다.

아담 그랜트의 프레임을 빌리면, 세상에는 기버(주는 사람), 테이커(받는 사람), 매처(주고받는 사람)가 있다. 흥미로운 건 부의 순위를 매겨보면 상위 1%에 테이커가 많고, 하위 1%에 기버가 많다는 점이다. 주기만 하는 사람이 제일 밑바닥에 있다. 직관적으로 이해가 된다. 자기 것을 끝없이 내어주면 남는 게 없다.

그런데 더 자세히 보면 이상한 점이 있다. 상위 0.1%, 정말 꼭대기에 있는 사람들은 다시 기버다. 같은 기버인데 누구는 바닥에, 누구는 꼭대기에 있다. 무엇이 이 둘을 갈라놓았을까.

목적성이다. "무엇을 줄 것인가"를 아는 기버와, 그냥 하염없이 주는 기버의 차이다.

하염없이 주는 것은 관대함이 아니라 방향 없음이다. 누가 도움을 요청하든, 어떤 상황이든, 일단 내 시간과 에너지를 쏟는다. 이것은 미덕처럼 보이지만, 실제로는 자신의 자원을 가장 비효율적으로 배분하는 방식이다. 나침반 없이 노를 젓는 것과 같다.

반면 목적 있는 기버는 다르다. 이 사람에게 내가 줄 수 있는 것 중 가장 가치 있는 것이 무엇인지를 안다. 상대의 결핍이 어디에 있는지를 읽고, 거기에 정확히 맞는 것을 건넨다. 열 가지를 주는 대신 딱 한 가지를 주되, 그 한 가지가 상대의 삶에 실제로 변화를 만드는 것이다.

이것도 결국 What이다. "무엇을 줄 것인가"라는 질문에 답할 수 있느냐의 문제다.

이 주제에 대해서는 예전에 두 번 글을 쓴 적이 있다. 한 번은 아담 그랜트의 책을 읽고 성공한 기버와 실패한 기버의 차이에 대해 정리했고, 다른 한 번은 그 프레임을 내 삶에 대입해 이기적인 이타주의자의 역설이라는 글을 썼다. 그때는 "누구에게 줄 것인가"와 "왜 주는가"에 초점을 맞췄다면, 이 글에서는 한 발 더 나아가 "무엇을 줄 것인가"를 묻고 있다.

해답이 아니라 질문을 건네는 사람

경험이 쌓이면서 느낀 것이 하나 있다. 후배나 주니어에게 진짜 도움이 되는 건 해답을 주는 게 아니라 질문을 던져주는 것이라는 점이다.

"이렇게 해"라고 말해주면 그 순간은 편하다. 하지만 그 사람은 다음에 비슷한 상황이 왔을 때 또 물어봐야 한다. How를 줬기 때문이다. 반면 "네가 진짜 풀고 싶은 문제가 뭔데?"라고 물으면, 그 사람은 처음으로 자기 나침반을 꺼내야 한다. 불편하지만, 이 경험이 쌓이면 스스로 방향을 잡는 사람이 된다. What을 줬기 때문이다.

나는 사람을 만날 때 그 사람의 결핍을 빨리 읽으려고 한다. 여기서 결핍이라 함은 부족함이 아니다. 이 사람이 지금 가장 원하지만 아직 손에 넣지 못한 것, 혹은 본인도 아직 언어화하지 못한 욕구다. 그걸 찾아서 거울처럼 비춰주면, 대부분의 사람은 스스로 답을 찾는다. 내가 한 건 해답을 준 게 아니라, 질문을 정의해 준 것뿐이다.

그래서 나는 주변에 나보다 5년에서 7년 정도 더 경험해본 사람을 두라고 말한다. 그 사람이 해주는 가장 중요한 역할은 내가 아직 모르는 What을 보여주는 것이다. 내가 아직 서보지 않은 곳에서 보이는 풍경을 미리 알려주는 사람. 해답을 주는 멘토가 아니라, 더 좋은 질문을 던져주는 사람. 그런 사람이 곁에 있으면, 노를 젓는 힘은 그대로인데 도착하는 곳이 완전히 달라진다.

씨앗을 고르는 일

결국 What을 정의하는 능력은 제품에만 필요한 게 아니다.

내 커리어에서 다음에 무엇을 할 것인가. 내 관계에서 이 사람에게 무엇을 줄 것인가. 내 삶에서 어떤 씨앗을 심을 것인가. 전부 같은 질문이다. 밭에 물을 주고 잡초를 뽑는 건 How다. 누구나 배울 수 있고, 성실하면 잘할 수 있다. 하지만 어떤 씨앗을 심을지 고르는 건 What이다. 이 선택이 수확의 질을 결정한다.

대부분의 사람은 노를 더 세게 저으려고 한다. 더 효율적인 도구를 찾고, 더 빠른 방법론을 익히고, 더 많은 시간을 투입한다. 그 노력 자체는 훌륭하다. 하지만 가끔은 노를 내려놓고 나침반을 꺼내 볼 필요가 있다. 내가 지금 가는 이 방향이 맞는가. 내가 지금 풀고 있는 이 문제가 정말 풀어야 할 문제인가. 내가 지금 주고 있는 이것이 정말 이 사람에게 필요한 것인가.

이 질문 앞에 서는 것이 불편하다면, 아마 지금이 나침반을 꺼낼 때다.

아무도 나를 보고 있지 않다

Tue, 24 Mar 2026 09:00:00 GMT

미국 거리에서 한국어로 영상을 찍고 있었다. 지나가는 사람들이 힐끗힐끗 쳐다봤다. 동양인이 혼자 카메라를 들고 뭔가를 열심히 말하고 있으니 눈길이 갈 만도 했다. 그런데 신기하게도, 긴장이 되지 않았다. 저 사람들은 내 말을 알아듣지 못한다. 그 사실 하나만으로 나는 자유로웠다.

한국에서였다면 어땠을까. 카페에서 노트북을 펴는 것조차 주변 눈치를 보던 때가 있었다. 길에서 혼잣말을 하면 이상한 사람이 될까 봐, 식당에서 혼자 밥을 먹으면 외로운 사람으로 보일까 봐. 같은 행동인데, 장소만 바뀌었을 뿐인데, 마음의 무게가 완전히 달랐다. 왜 그랬을까.

보이지 않는 무대 위의 배우

심리학에는 "스포트라이트 효과"라는 개념이 있다. 자신이 다른 사람들에게 주목받고 있다고 과대평가하는 인지 편향이다. 실제로는 아무도 신경 쓰지 않는데, 나만 혼자 무대 위에 서 있다고 느끼는 것이다.

코넬 대학의 실험이 유명하다. 학생들에게 다소 창피한 티셔츠를 입히고 교실에 들어가게 했다. 티셔츠를 입은 학생들은 교실의 절반 이상이 자신의 옷을 알아챘을 거라고 예상했다. 실제로 알아챈 사람은 25%도 되지 않았다. 우리는 자기 자신에게 스포트라이트를 비추고, 그 빛 아래서 온 세상이 나를 지켜보고 있다고 착각한다.

무대 위의 배우는 객석이 가득 차 있다고 믿는다. 하지만 커튼을 걷으면 대부분의 의자는 비어 있다. 관객은 각자의 무대에서 바쁘다. 내 실수를, 내 외모를, 내 어색한 행동을 기억하는 사람은 거의 없다. 기억하는 유일한 사람은 나 자신이다.

시선이 만드는 감옥

문제는 존재하지 않는 관객을 위해 우리가 실제로 행동을 바꾼다는 것이다.

하고 싶은 말을 삼킨다. 회의에서 떠오른 아이디어가 있지만, "이상하게 들리면 어쩌지?"라는 생각에 입을 다문다. 정작 말했더라면 아무도 이상하게 생각하지 않았을 것이다. 아니, 애초에 5분 뒤면 아무도 기억하지 못했을 것이다.

사소한 행동도 망설인다. 혼자 영화를 보고 싶지만 "혼자 온 사람"이라는 시선이 신경 쓰인다. 새로운 취미를 시작하고 싶지만 "나이 들어서 그걸 왜?"라는 반응이 두렵다. 질문을 하고 싶지만 "그것도 모르냐"는 눈빛이 겁난다.

이 모든 시선은 실체가 없다. 내 머릿속에서 만들어낸 상상의 관객이다. 하지만 상상의 관객이 만드는 감옥은 진짜다. 벽도 없고 자물쇠도 없는데, 우리는 그 안에서 스스로 작아진다. 할 수 있는 일을 하지 않고, 되고 싶은 사람이 되지 못하고, 살고 싶은 대로 살지 못한다. 보이지 않는 시선에 보이지 않는 사슬이 묶여 있다.

시선 속으로 걸어 들어가기

미국에서 영상을 찍으며 깨달은 것이 하나 있다. 시선의 무게를 줄이는 방법은 시선을 피하는 것이 아니라, 시선 속으로 직접 걸어 들어가는 것이다.

거창한 용기가 필요하지 않다. 아주 작은 것부터 시작하면 된다. 카페에서 혼자 앉아본다. 모르는 것을 질문해본다. 사람들 앞에서 자기 생각을 말해본다. 길에서 영상을 찍어본다. 처음에는 심장이 뛴다. 누가 나를 이상하게 보지 않을까. 하지만 직접 해보면 놀라운 사실을 발견한다.

아무도 신경 쓰지 않는다.

정말로, 놀라울 만큼 아무도 관심이 없다. 내가 혼자 밥을 먹든, 길에서 카메라를 들고 말을 하든, 회의에서 엉뚱한 질문을 하든. 사람들은 각자의 스포트라이트 아래서 자기 자신에게 바쁘다. 내가 나에게 쏟는 만큼의 관심을 타인이 나에게 쏟는 일은 거의 일어나지 않는다.

이것을 머리로 아는 것과 몸으로 느끼는 것은 완전히 다르다. 한 번 직접 경험하면, 상상 속 관객의 존재감이 조금 옅어진다. 두 번, 세 번 반복하면 더 옅어진다. 시선의 무게는 부딪힐수록 가벼워진다. 마치 근육이 반복 훈련으로 강해지듯, 시선을 견디는 힘도 반복으로 커진다.

관객석은 비어 있다

돌이켜보면, 내 인생에서 후회되는 순간들은 대부분 하지 않은 것들이다. 말하지 않은 것, 시도하지 않은 것, 시작하지 않은 것. 그리고 그 "하지 않음"의 이유를 파고 들어가면, 대부분의 끝에는 타인의 시선이 있었다.

실체 없는 시선 때문에, 실체 있는 기회를 놓친 것이다.

미국 거리에서 나를 쳐다보던 사람들은 10초 뒤에 내 존재를 잊었을 것이다. 그들에게 나는 스쳐 지나가는 풍경의 일부였을 뿐이다. 우리 모두 서로에게 그렇다. 당신이 생각하는 것만큼 세상은 당신을 지켜보고 있지 않다. 그리고 그것은 슬픈 일이 아니라, 자유로운 일이다.

지금 당신이 망설이고 있는 그 사소한 행동은 무엇인가. 그것을 가로막고 있는 시선은 정말 존재하는가. 한번 커튼을 걷어보라. 관객석은 비어 있을 것이다.

나무만 보는 사람, 숲을 읽는 사람

Mon, 23 Mar 2026 18:00:00 GMT

같은 팀에서 같은 시간을 일하는데, 누군가는 점점 더 큰 영향력을 갖게 되고, 누군가는 그 자리에 머문다. 실행 속도의 차이가 아니다. 코드 품질의 차이도 아니다. 둘 다 잘한다. 그런데 결과가 다르다.

차이는 대부분 사고의 출발점에 있다. 주어진 것에서 위로 올라가는 사람과, 전체에서 아래로 내려오는 사람. Bottom-up과 top-down의 차이다.

시킨 일을 잘하는 함정

Bottom-up 사고란, 주어진 것에서 출발하는 방식이다. 티켓을 받으면 그 기능의 구현에 집중한다. "이 API를 어떻게 만들까?" "이 컴포넌트를 어떻게 최적화할까?" 눈앞의 과제를 풀어내는 데 에너지를 쏟는다.

이것이 나쁜 건 아니다. 실행력을 기르는 데 필수적이고, 커리어 초반에는 자연스러운 사고방식이다. 문제는 이것이 유일한 모드로 굳어질 때 발생한다.

특히 빠르게 움직이는 조직일수록 이 습관이 강화된다. 빠른 실행이 미덕이고, 시야를 넓힐 여유가 없고, "일단 만들고 보자"가 문화다. 매일 불을 끄다 보면, 불이 왜 나는지 생각할 틈이 없다. 2년, 3년을 그렇게 보내면 bottom-up이 사고의 기본값이 된다.

요리에 비유하면, 재료를 잘 다루는 것과 코스 전체를 설계하는 것의 차이다. 재료를 잘 다루는 능력은 필수지만, 코스를 설계하려면 전혀 다른 차원의 시야가 필요하다. 손이 빠른 것과 방향이 맞는 것은 별개의 문제다.

출발점이 결론을 결정한다

Bottom-up 사고에는 전형적인 패턴이 있다. 수단에서 출발해서 목적을 역추론하는 것이다. "이 기능을 만들면 좋지 않을까?" → "만들 수 있으니까 만들자" → "만들었으니 효과가 있을 것이다." 수단이 목적을 정당화하는 구조다.

반대 방향은 이렇다. "돈을 1억 벌려면 무엇을 해야 할까?" → "고객이 가장 아파하는 문제는 무엇인가?" → "그 문제를 풀 수 있는 가장 효과적인 방법은?" 같은 역량을 가진 사람이라도, 질문의 방향만 바뀌면 완전히 다른 결론에 도달한다.

"페이지 로딩을 200ms 줄이자"는 bottom-up이다. "사용자가 이탈하는 진짜 이유가 뭘까?"는 top-down이다. 후자의 질문을 던지면, 로딩 속도가 아니라 온보딩 플로우 자체가 문제라는 걸 발견할 수도 있다. 같은 시간을 쓰되, 전혀 다른 곳에 쓰게 된다.

설계에서도 마찬가지다. "검색 결과 필터링"을 "상품 목록 페이지"의 부속 기능으로만 보면, 필터가 검색·카테고리·추천 등 여러 진입점에서 공통으로 쓰인다는 사실을 놓친다. 특정 페이지의 요구사항에서 출발하면 거기에 맞춘 구조가 나오고, 전체 사용자 플로우에서 출발하면 간결하면서도 범용적인 구조가 나온다.

출발점이 다르면 도착지가 다르다.

실행력만으로 갈 수 있는 곳

커리어 초반에는 실행력만으로 충분하다. 주어진 문제를 빠르고 정확하게 풀 수 있다면, 그것만으로도 가치가 있다. 하지만 어느 시점부터 실행력만으로는 넘을 수 없는 벽이 나타난다.

기술적 의사결정에서 "왜 이 방식이어야 하는가"를 설명하지 못할 때
내 작업이 다른 팀에 미치는 영향을 예측하지 못할 때
문제를 정의하지 못하고, 정의된 문제만 풀 수 있을 때
우선순위를 스스로 판단하지 못할 때

연차가 올라갈수록, 전체 시스템에 대한 이해도가 핵심 평가 기준이 된다. 내가 만드는 것뿐 아니라, 제품 전체, 업계 전체를 보는 시야.

이것은 능력의 문제가 아니라 습관의 문제다. Bottom-up이 체화되면, top-down을 시도할 기회 자체를 만들지 않게 된다. 주어진 일을 끝내고, 다음 일을 집어 들고, 또 끝내고. 바쁘지만 시야는 넓어지지 않는 루프.

Top-down으로 본다는 것

Top-down 사고는 "큰 그림을 봐라"라는 모호한 조언이 아니다. 구체적인 사고의 전환이다.

"이 API를 어떻게 만들까?" → "이 API가 왜 필요한가? 정말 API가 답인가?"
"이 버그를 어떻게 고칠까?" → "이 버그가 발생하는 구조적 원인은 무엇인가?"
"이 피처를 어떻게 출시할까?" → "이 피처가 풀고 있는 고객의 문제는 무엇인가?"

일을 더 많이 하라는 것이 아니다. 같은 일을 다른 해상도에서 보라는 것이다. 지도 앱에서 줌 레벨을 조절하는 것과 같다. 줌인하면 거리 이름이 보이고, 줌아웃하면 도시 전체의 동선이 보인다. 둘 다 필요하지만, 줌인만 할 줄 아는 사람은 목적지까지의 최적 경로를 찾지 못한다.

Why를 모른다면, 그건 당신 탓이 아니다

실행의 시대에 질문이 사라진다에서 What과 How를 이야기했더니, "Why는요?"라는 질문이 많았다.

솔직한 생각을 말하면, 한 팀인데 Why를 모른다면, 그건 개인의 문제가 아니라 조직 시스템의 문제다. Why는 개인이 찾아 헤매야 할 것이 아니라, 조직이 자연스럽게 흘려보내야 할 것이다.

하지만 현실은 다르다. 대부분의 조직에는 Why가 자연스럽게 싱크되는 장치가 없다.

전사 미팅에서 한 번 언급되고 끝나거나
노션 어딘가에 묻혀 있거나
아예 명문화되지 않았거나

"우리가 왜 이걸 하는가"가 팀 전체에 당연하게 공유되는 조직은 드물다.

그래서 top-down 사고를 하고 싶어도, 출발점인 Why가 없으면 시작할 수가 없다. 역설적으로, 조직이 Why를 잘 싱크하는 것 자체가 구성원의 top-down 사고를 가능하게 하는 인프라다. Why가 흐르는 조직에서는 구성원이 자연스럽게 top-down으로 사고하게 되고, Why가 막힌 조직에서는 bottom-up 외에 선택지가 없다.

그렇다고 개인이 할 수 있는 것이 없는 건 아니다. Why가 주어지지 않는 환경에서도, 시야를 넓히는 훈련은 가능하다.

시야를 넓히는 훈련

Top-down 사고는 타고나는 것이 아니라 훈련된다.

자기 작업의 상위 컨텍스트를 파악한다. 내가 만드는 컴포넌트가 속한 페이지, 그 페이지가 속한 플로우, 그 플로우가 풀고 있는 비즈니스 문제. 한 단계 위를 항상 인식하는 습관이다. 티켓을 받으면 바로 구현에 들어가지 말고, 이 티켓이 존재하는 이유를 한 단계만 거슬러 올라가본다.

다른 팀의 일을 이해한다. 백엔드, PM, 디자인, 비즈니스 팀이 지금 무슨 문제를 풀고 있는지 안다. 내 작업이 그들의 작업과 어떻게 연결되는지 안다. 이것만으로도 시야가 달라진다. 아는 만큼 보이고, 보이는 만큼 영향을 줄 수 있다.

역방향으로 계획을 세워본다. "6개월 뒤 이 제품이 이런 상태가 되려면, 지금 무엇을 해야 하는가?"라는 질문에서 출발해서 현재의 할 일을 역추론한다. 미래의 목표에서 현재의 행동을 도출하는 것. 이것이 top-down 계획의 기본 구조다.

세 가지 모두 거창한 것이 아니다. 매일 하던 일을 하되, 출발점을 한 단계 위로 옮기는 것이다.

나무를 심되, 숲의 지도를 가져라

Bottom-up이 나쁜 것이 아니다. 나무 하나를 제대로 심을 줄 모르면 숲을 만들 수 없다. 실행력 없는 시야는 공허하다.

하지만 나무만 보면서 숲을 만들 수도 없다. 두 가지 사고방식은 대립이 아니라 보완이다. 성장은 이 둘을 오갈 수 있는 유연함에서 온다. 줌인과 줌아웃을 자유롭게 전환할 수 있는 것. 나무를 심으면서도, 숲 전체의 지도를 머릿속에 가지고 있는 것.

지금 나무를 보고 있다면, 한 번쯤 줌아웃해볼 때다.

빨라진 실행, 느려진 팀 — 생산성의 역설

Sat, 21 Mar 2026 19:00:00 GMT

스프린트가 끝났다. 개발자들은 할 일이 없다. 기획은 아직 안 나왔고, 디자인은 리뷰 중이다. 백로그에는 "추후 논의"라고 적힌 티켓만 쌓여 있다.

이상한 일이다. 팀의 실행 속도는 분명히 빨라졌다. 예전에 2주 걸리던 피처를 3일 만에 끝낸다. 그런데 팀 전체의 속도는 오히려 느려진 것 같다. 실행이 빨라진 건 좋은 일이다. 그런데 왜 팀은 더 불안해졌을까.

How의 비용은 0에 수렴하고 있다

AI 코딩 도구, 자동화 파이프라인, 코드 생성기. 지난 3년간 "만드는 비용"은 극적으로 줄었다. 과거에 시니어 개발자 2명이 2주를 써야 했던 기능을, 지금은 주니어 1명이 3일이면 끝낸다. 이건 과장이 아니다. 실제로 수많은 팀에서 일어나고 있는 일이다.

How — 어떻게 만들 것인가 — 의 비용은 빠르게 0에 수렴하고 있다. 구현은 점점 쉬워지고, 같은 결과물을 내는 데 필요한 사람과 시간은 줄어든다. 기술의 진보다. 축하할 일이다.

그런데 한 가지 비용은 전혀 줄지 않았다. What — 무엇을 만들 것인가 — 를 결정하는 비용이다. 어떤 문제를 풀어야 하는지 파악하고, 아이디어를 구체화하고, 방향을 잡는 데 걸리는 시간은 여전히 똑같다. 오히려 선택지가 늘어나면서 더 오래 걸리기도 한다.

How는 점점 싸지는데, What은 여전히 비싸다. 여기서 역설이 시작된다.

그래서 기업은 개발자를 내보낸다

개발자들의 생산성이 높아지면 무슨 일이 벌어질까. 직관적으로는 "팀이 더 많은 걸 만든다"가 답이어야 한다. 하지만 현실은 다르다. 개발자들이 논다.

논다는 건 게으르다는 뜻이 아니다. 실행할 거리가 없다는 뜻이다. What이 나오는 속도보다 How가 소화하는 속도가 압도적으로 빨라졌기 때문이다. PM과 디자이너가 기획하고 디자인하는 속도가 병목이 되어버렸다.

이때 기업에게는 두 가지 선택지가 있다.

a. 병목 포지션을 충원한다. PM이나 디자이너를 더 뽑아서 What의 처리량을 늘린다.

b. 개발자를 줄인다. How의 처리량을 What의 속도에 맞춘다.

논리적으로는 a가 맞다. 하지만 현실에서 b는 압도적으로 쉽다. 적합한 PM이나 디자이너를 찾는 건 정말 어렵다. 비용이나 연봉의 문제가 아니라, 정말 맞는 사람을 찾는 것 자체가 난제다. 반면 개발자를 줄이는 건 숫자 계산만 하면 된다.

그래서 많은 기업들이 구조조정을 택한다. 이것이 지난 3년간 우리가 목격한 흐름의 구조적 원인이다. 실행력이 높아질수록, 실행하는 사람의 자리가 위태로워지는 역설. 빨라진 실행이 느려진 팀을 만들고, 느려진 팀이 더 적은 사람을 요구한다.

What을 나눠야 한다

그렇다면 이 역설을 어떻게 깰 수 있을까.

핵심은 간단하다. What을 PM과 디자이너만의 영역으로 두지 않는 것이다. 문제 파악, 아이디에이션, 방향 설정 — 이 과정에 엔지니어가 함께 참여해야 한다.

말처럼 쉽지는 않다. 그래도 구체적인 방법은 있다.

고객 문의 기반 문제 파악에 참여한다. 고객이 어떤 문제로 문의를 넣는지, 어떤 기능을 예상과 다르게 쓰는지를 엔지니어가 직접 보는 것만으로도 시야가 달라진다. 단순 알림용으로 만든 웹훅을 고객이 자체 자동화 파이프라인의 핵심 트리거로 쓰고 있다면 — 그건 엔지니어가 가장 빨리 포착할 수 있는 종류의 인사이트다.

벤치마크 세션을 함께 한다. 경쟁사 분석, 시장 리서치를 PM만 하는 게 아니라, 팀 전체가 주기적으로 함께 들여다본다. 엔지니어의 관점에서 보이는 기술적 가능성이 전혀 다른 아이디어를 만들어내기도 한다.

프로토타이핑으로 아이디에이션에 기여한다. 피그마 목업 대신 실제로 동작하는 프로토타입을 빠르게 만들어서 팀의 논의를 앞당긴다. How가 저렴해진 세상에서, 프로토타입을 만드는 비용도 거의 없다.

결국 How만 잘하는 사람은 대체 가능해진다. What에 참여할 수 있는 엔지니어만이 팀에서 유의미한 자리를 유지할 수 있다. 이건 위협이 아니라 기회다. 과거에는 엔지니어가 기획에 참여할 여유가 없었지만, 지금은 실행 시간이 줄어든 만큼 여유가 생겼으니까.

What과 How를 같은 스프린트에서 하지 않기

What에 참여하는 것만으로는 부족하다. 운영 구조도 바뀌어야 한다.

가장 흔한 실수는 같은 문제에 대한 What과 How를 같은 스프린트에서 동시에 진행하는 것이다. 이번 스프린트에 문제를 파악하면서, 동시에 그 해결책을 구현하려고 한다. 이러면 무조건 블로킹이 생긴다. What이 늦어지면 How가 멈추고, How가 멈추면 엔지니어가 또 논다.

더 큰 문제는 리스크다. What 단계에서 방향이 틀어지면, 같은 스프린트에서 진행 중이던 How 작업이 통째로 날아간다. 스프린트의 2/3를 한순간에 잃는 것이다.

해법은 교차 운영이다. 나는 이걸 "1/3 법칙"이라고 부른다.

스프린트의 1/3은 미래의 What에 쓴다. 문제를 파악하고, 싱크하고, 아이디에이션한다. 나머지 2/3는 이미 정의된 What의 How를 실행한다. 지난 스프린트에서 충분히 다져놓은 것들을 만드는 데 집중한다.

구체적으로 이런 흐름이다.

S1: 문제 A 파악 + 아이디에이션
S2: 문제 A 실행 + 문제 B 파악
S3: 문제 B 실행 + 문제 C 파악

이렇게 하면 What이 실패해도 How의 리소스가 날아가지 않는다. S1에서 문제 A의 방향이 안 나왔다면 유감이지만, S1에서 실행하고 있던 건 이전 스프린트에서 이미 검증된 다른 문제의 How다. 손실이 격리된다.

교차 운영은 약간의 리드 타임이 필요하다. 지금 3월이라면, 4월 초에 실행할 것에 대한 What을 지금부터 시작해야 한다. 하지만 이 투자가 팀 전체의 블로킹을 없앤다.

직관은 훈련된다

What을 잘하려면 직관이 필요하다. 고객이 문의를 넣었을 때, "이 문제를 동일하게 겪는 다른 고객사가 어디일까"가 바로 떠오르는 수준. 별도 리서치 없이도 "이건 진짜 문제일 수 있겠다"라는 판단이 서는 수준.

이건 타고나는 게 아니다. 훈련된다.

외부 고객을 이해한다. 우리 고객이 어떤 비즈니스를 하고, 어떻게 돈을 벌고, 어떤 고민을 안고 있는지를 안다. 경조사, 신규 사업, 채용, 구조조정까지. 깊이 알수록 직관이 날카로워진다.

내부 고객을 이해한다. 같은 팀원이 어떤 강점이 있고, 어떤 영역에 도전하고 싶어하는지를 안다. 문제를 누구에게 맡길지, 어떻게 나눌지 결정하는 것도 직관이다.

시장을 이해한다. 경쟁사, 법령, 시장 동향. 이 맥락 없이는 어떤 문제가 풀 만한 문제인지 판단할 수 없다.

예상치 못한 사용을 관찰한다. 우리가 A를 위해 만든 기능을 고객이 B에 쓰고 있다면, 거기에 의외의 기회가 숨어 있다. 이런 시그널은 코드를 만드는 사람이 가장 먼저 감지할 수 있다.

"신입 PM은 없다"는 말이 있다. 직관이 쌓이는 데 시간이 걸리기 때문이다. 하지만 이건 PM만의 이야기가 아니다. What에 참여하려는 모든 사람에게 해당한다. 그리고 지금, 실행이 빨라진 덕분에 우리에겐 그 훈련을 할 시간이 생겼다.

빨라진 실행을 기회로

How가 공짜가 되어가는 세상이다. 이 흐름은 되돌릴 수 없다. 실행 비용은 앞으로도 계속 줄어들 것이고, 같은 일을 하는 데 필요한 사람은 점점 적어질 것이다.

이때 살아남는 팀은 "더 빨리 만드는 팀"이 아니라 "더 잘 정의하는 팀"이다. 그리고 잘 정의하는 건 특정 직군 한두 명의 역할이 아니라, 제품팀 전체의 역량이다.

빨라진 실행을 위협으로 볼 수도 있고, 기회로 볼 수도 있다. 줄어든 실행 시간만큼 What에 참여할 여유가 생겼다고 본다면, 이건 엔지니어에게 오히려 더 넓은 영역에서 기여할 수 있는 기회가 된다.

당신의 팀에서 What은 누가 하고 있는가. 그리고 당신은 그 과정에 참여하고 있는가.

팀에 '우리다움'이 없으면 논의는 시작되지 않는다

Fri, 20 Mar 2026 10:00:00 GMT

"왜 아무도 말을 안 하지"

회의실에 여섯 명이 앉아 있다. 화면에는 새 프로젝트의 기획 초안이 띄워져 있다. 리더가 말한다. "의견 있으면 편하게 말해주세요." 침묵. 5초, 10초. 누군가 물을 한 모금 마시고, 누군가 노트북 화면을 내려다본다. 결국 리더가 "그럼 이대로 진행하겠습니다"라고 말하며 회의가 끝난다. 나오면서 복도에서 두 사람이 수군거린다. "솔직히 그 방향 좀 아닌 것 같지 않아?" "나도. 근데 뭐라고 말해야 할지 모르겠어서."

이 장면은 거의 모든 조직에서 반복된다. 의견이 없어서 침묵하는 것이 아니다. 의견은 있는데 말하지 못하는 것이다. 그리고 그 이유는 대부분의 사람이 생각하는 것과 다르다.

침묵의 원인은 아이디어 부족이 아니다

회의에서 사람들이 말을 안 하는 이유를 물어보면, 흔히 "마땅한 아이디어가 없어서"라는 답이 돌아온다. 하지만 복도에서 수군거리는 장면이 보여주듯, 아이디어는 있다. 부족한 것은 아이디어가 아니라 확신이다. "이걸 말해도 될까"라는 확신. "이런 수준의 의견을 꺼내도 괜찮을까"라는 확신. "내가 틀리더라도 이 팀에서는 괜찮을까"라는 확신.

이 확신은 개인의 성격이나 용기와는 별로 관계가 없다. 아무리 대담한 사람이라도, 낯선 팀에서 첫 회의에 참석하면 말을 아끼게 된다. 반대로 내성적인 사람도, 안전하다고 느끼는 팀에서는 놀라울 정도로 날카로운 의견을 낸다. 발언은 개인의 속성이 아니라 환경의 산물이다.

그렇다면 그 환경은 무엇으로 만들어지는가. 심리적 안전감이라는 말이 자주 쓰이지만, 그건 결과에 가깝다. 심리적 안전감이 생기려면 그 전에 먼저 필요한 것이 있다. 팀이 자기 자신에 대해 알고 있어야 한다. "우리는 어떤 팀인가"에 대한 공유된 감각. 이것이 없으면, 발언의 문턱이 무한히 높아진다.

'시원찮은 기획'에 대해 말하는 이유

기획 회의에서 보통 사람들이 말을 꺼내는 순간은 "좋은 아이디어가 떠올랐을 때"다. 충분히 정리되고, 논리적으로 말이 되고, 반박당하지 않을 만큼 단단한 아이디어. 그래서 회의 시간의 대부분이 침묵으로 채워진다. 완벽한 아이디어가 떠오르기를 기다리는 침묵.

하지만 좋은 논의가 일어나는 팀에서는 정반대의 일이 벌어진다. 사람들이 시원찮은 아이디어를 먼저 꺼낸다. "이게 맞는지 모르겠는데", "좀 엉뚱할 수 있는데", "일단 날것 그대로 던져볼게" 같은 전제를 달고 불완전한 생각을 내놓는다. 그리고 그 불완전한 생각 위에 다른 사람의 생각이 얹히면서, 혼자서는 도달할 수 없었던 방향이 만들어진다.

시원찮은 기획에 대해 말할 수 있다는 것은, 그 팀에 두 가지가 있다는 뜻이다. 첫째, 불완전한 것을 내놓아도 판단받지 않을 것이라는 믿음. 둘째, 불완전한 것이 팀을 통과하면서 더 나아질 것이라는 믿음. 이 두 가지 믿음은 구호로 만들어지지 않는다. 실제 경험의 축적으로만 만들어진다.

'우리다운 것'이 발언의 문턱을 낮추는 원리

"우리는 어떤 팀인가"라는 질문에 구성원들이 비슷한 답을 할 수 있는 팀이 있다. "우리 팀은 일단 빠르게 해보는 팀이야", "우리는 데이터 없이는 결정 안 하는 팀이야", "우리는 고객 앞에서 직접 부딪히는 팀이야." 이런 답이 팀 안에서 자연스럽게 공유되어 있을 때, 그것이 발언의 기준점이 된다.

기준점이 있으면 발언이 쉬워진다. "우리가 빠르게 해보는 팀이라면, 이건 너무 오래 고민하고 있는 거 아닌가?"라는 말이 자연스럽게 나올 수 있다. "우리가 데이터 기반으로 결정하는 팀이라면, 이 결정에는 근거가 부족한 것 같다"는 지적이 공격이 아니라 정상적인 점검이 된다. 발언의 근거가 개인의 판단이 아니라 팀의 합의된 정체성에 있기 때문이다.

반대로 "우리다운 것"이 없는 팀에서는, 모든 발언이 개인의 의견으로 읽힌다. "이건 너무 느린 것 같다"고 말하면 "너는 그렇게 생각하는구나"로 끝나거나, "내 일에 왜 참견하지?"로 받아들여진다. 같은 말이라도, 팀의 정체성 위에서 하는 말과 개인의 취향으로 하는 말은 무게가 다르다. 전자는 논의의 시작이 되고, 후자는 감정의 충돌이 된다.

"우리다움"은 거창한 것이 아니다. 팀이 일하면서 자연스럽게 형성된 패턴, 반복된 선택, 공유된 기억. 이것들이 쌓여서 "우리는 이런 식으로 하는 팀"이라는 감각이 만들어진다. 그 감각이 있으면, 발언은 "내 개인적인 생각인데"가 아니라 "우리 팀답게 보면"으로 시작할 수 있다. 그 차이가 침묵과 논의를 가른다.

과거 발언을 되짚어 팀원을 영웅으로 만드는 기술

"우리다움"을 만드는 가장 효과적인 방법 중 하나는, 과거에 누군가가 했던 발언을 되짚어주는 것이다. "지난번에 수진 님이 말했던 그 포인트 있잖아요, 사용자 인터뷰를 먼저 하자고 했던 거. 그때 그 방향으로 갔더니 결과적으로 맞았거든요." 이 한마디가 만드는 효과는 생각보다 크다.

첫째, 수진이라는 사람의 발언이 팀의 역사에 기록된다. "내가 했던 말이 기억되고 있구나"라는 감각은, 다음에도 말할 이유를 만든다. 둘째, 팀 전체에 "발언은 흘러가는 것이 아니라 축적되는 것"이라는 메시지가 전달된다. 내가 오늘 하는 말이 한 달 뒤에도 의미를 가질 수 있다는 감각. 이것이 발언의 동기를 만든다.

셋째, 그리고 이것이 가장 중요한 효과인데, 과거의 발언이 좋은 결과로 이어진 사례를 팀이 공유하면, "우리 팀에서는 이런 발언이 가치 있다"는 기준이 생긴다. 추상적인 원칙이 아니라, 실제 인물과 실제 사건에 기반한 기준. "수진 님처럼 초기에 방향을 짚어주는 말이 우리 팀에서는 중요하다"는 것을 모두가 체감하게 된다.

과거 발언을 되짚는 것은 단순한 칭찬이 아니다. 팀의 기억을 구성하는 행위다. 그리고 팀의 기억이 쌓여야 팀의 정체성이 만들어진다.

좋은 퍼실리테이터는 자기가 아니라 팀을 영웅으로 만든다

회의를 잘 이끄는 사람을 보면, 공통점이 있다. 자기가 좋은 아이디어를 내는 사람이 아니라, 다른 사람의 좋은 아이디어를 발견하는 사람이라는 것이다.

나쁜 퍼실리테이션은 리더가 답을 이미 가지고 있으면서 질문의 형식을 빌리는 것이다. "어떻게 생각해요?"라고 물어놓고, 원하는 답이 나올 때까지 "그것도 좋지만..."을 반복하는 것. 팀원들은 금방 눈치챈다. 어차피 답이 정해져 있다는 것을. 그러면 다음 회의부터 입을 닫는다.

좋은 퍼실리테이션은 다르다. 누군가 불완전한 아이디어를 꺼내면, 그 안에서 가치 있는 조각을 찾아 이름을 붙여준다. "지금 민수 님이 말한 건, 우리가 B2C 관점에서만 보고 있었다는 지적인 것 같은데, 이거 중요한 포인트인 것 같아요." 민수가 스스로도 정리하지 못했던 자기 생각이, 다른 사람의 해석을 통해 선명해진다. 그 순간 민수는 "나도 기여할 수 있구나"를 체험한다.

이런 경험이 반복되면 팀에 순환이 생긴다. 불완전한 발언 → 가치 발견 → 더 많은 발언 → 더 깊은 논의. 이 순환의 시작은 리더의 화려한 인사이트가 아니라, 팀원의 서툰 한마디를 주워 올리는 행위에 있다.

결국 논의가 시작되려면, 팀이 먼저 자기 자신을 알아야 한다. "우리는 어떤 팀인가", "우리는 어떤 발언을 중요하게 여기는가", "우리의 과거에는 어떤 순간이 있었는가." 이 질문들에 팀원 모두가 비슷한 대답을 할 수 있을 때, 침묵은 비로소 깨진다. 안전하다는 느낌은 제도나 규칙에서 오는 것이 아니라, "이 팀은 나를 포함해서 우리다"라는 감각에서 온다. 그 감각이 없으면, 아무리 "편하게 말해주세요"를 반복해도 회의실의 공기는 바뀌지 않는다.

프로덕트에서 플레이어를 떼어내는 용기

Thu, 19 Mar 2026 14:00:00 GMT

"이 이야기는 여기서 끝입니다"

어린 시절 본 애니메이션의 마지막 회를 기억한다. 모험이 끝나고, 주인공이 일상으로 돌아가고, 하늘에는 석양이 진다. 화면이 천천히 어두워지면서 엔딩곡이 흐른다. 그 순간의 감각이 있다. 아쉽지만, 동시에 충만한. "이 이야기는 여기서 끝입니다"라는 신호가, 지금까지의 체험을 하나의 완결된 덩어리로 만들어준다. 끝이 있기 때문에 의미가 생긴다. 끝이 없었다면, 그건 이야기가 아니라 그냥 시간의 흐름이었을 것이다.

프로덕트를 만드는 사람들은 이 감각을 잘 모른다. 아니, 알면서도 외면한다. 사용자가 떠나는 순간을 설계하는 것은, 만드는 사람의 본능에 역행하는 일이기 때문이다.

영원히 머물길 바라는 에고

프로덕트를 만드는 사람이라면 누구나 이런 욕망이 있다. 사용자가 오래 머물기를, 자주 돌아오기를, 떠나지 않기를. 사용 시간이 늘어나면 뿌듯하고, DAU가 올라가면 안심하고, 이탈률이 낮아지면 성공했다고 느낀다. 이건 자연스러운 감정이다. 내가 만든 것에 사람들이 시간을 쓴다는 건, 그것이 가치 있다는 증거처럼 보인다.

하지만 이 욕망이 설계를 지배하면 이상한 일이 일어난다. 끝없이 스크롤되는 피드, 자동 재생되는 다음 영상, 끊임없이 울리는 알림. 이것들은 사용자를 붙잡기 위한 장치들이다. 떠나지 못하게 만드는 것. 마치 극장에서 영화가 끝났는데 문을 잠그고 다음 상영을 강제하는 것과 같다. 영화관이 관객을 가두는 순간, 그곳은 더 이상 극장이 아니라 감옥이 된다.

사용자의 시간을 점유하는 것과 사용자에게 가치를 주는 것은 다른 일이다. 이 둘을 혼동하는 순간, 프로덕트는 사용자를 위한 도구가 아니라 사용자를 소비하는 기계가 된다.

프로덕트는 인생의 조연이다

우리가 만드는 프로덕트는 사용자 인생의 주인공이 아니다. 조연이다. 아무리 뛰어난 서비스라도, 사용자의 하루 중 극히 일부만 차지한다. 그리고 그래야 한다. 좋은 조연은 주인공의 이야기를 돕고, 자기 역할이 끝나면 무대에서 내려온다. 주인공보다 오래 무대에 서려는 조연은 이야기를 망친다.

프로덕트도 마찬가지다. 사용자가 할 일을 끝내면 보내줘야 한다. 운동 기록 앱은 운동이 끝나면 "잘했다"고 말하고 조용해져야 한다. 할 일 관리 앱은 모든 할 일이 완료되면 빈 화면을 보여주며 "오늘 할 일은 끝났다"고 알려줘야 한다. 그 빈 화면이, 사용자가 자기 인생의 다음 장면으로 넘어가는 문이다.

문제는 빈 화면이 무섭다는 것이다. 만드는 사람 입장에서 빈 화면은 "사용자가 이탈할 수 있는 순간"이다. 그래서 빈 화면 대신 추천 콘텐츠를 넣고, 다음 목표를 제안하고, 뭐라도 하게 만들려고 한다. 하지만 사용자가 할 일을 다 했는데 억지로 붙잡는 것은, 친구가 집에 가겠다는데 현관문 앞을 막는 것과 같다. 한두 번은 괜찮을 수 있지만, 반복되면 그 집에 다시 가고 싶지 않아진다.

멈출 수 있어야 돌아온다

체험을 멈추게 하는 디자인이라는 개념이 있다. 직관에 반하는 아이디어다. 보통은 사용자를 더 오래 붙잡는 것이 좋은 디자인이라고 생각한다. 하지만 역설적으로, 멈출 수 있는 서비스에 사람들은 더 자주 돌아온다.

넷플릭스의 자동 재생을 생각해보자. 에피소드가 끝나면 5초 후 다음 편이 자동으로 시작된다. 멈추려면 적극적으로 행동해야 한다. 리모컨을 찾아 버튼을 눌러야 한다. 그 결과 사용자는 의도보다 더 오래 시청하게 되고, 시청 시간 지표는 올라간다. 하지만 그 시간이 끝난 후 남는 감정은 무엇인가. 충만함이 아니라 후회다. "또 너무 오래 봤다." 이 후회가 반복되면, 서비스를 여는 것 자체가 부담이 된다.

반대로, 좋은 책은 챕터마다 자연스러운 멈춤 지점이 있다. 한 장을 읽고 책을 덮을 수 있는 여유. 그 여유가 있기 때문에, 다음 날 다시 책을 집어들 수 있다. 읽다가 멈춘 것이 아쉬움이 되고, 그 아쉬움이 내일의 동력이 된다. 멈출 수 있었기 때문에 돌아오는 것이다.

리텐션의 진짜 의미는 사용자를 떠나지 못하게 하는 것이 아니라, 떠났다가 스스로 돌아오게 하는 것이다. 그리고 사용자가 스스로 돌아오려면, 먼저 떠날 수 있어야 한다.

워프 존이라는 선택지

오래된 게임 디자인에서 흥미로운 사례가 있다. 슈퍼 마리오 브라더스에는 워프 존이 있다. 스테이지를 건너뛸 수 있는 숨겨진 통로다. 게임 디자이너 입장에서 보면 이상한 결정이다. 공들여 만든 스테이지를 건너뛰게 해주다니. 플레이어가 콘텐츠의 절반을 보지 않고 넘어갈 수 있다.

하지만 워프 존이 있기 때문에, 플레이어는 자기가 이 게임을 통제하고 있다고 느낀다. 건너뛸 수도 있지만 건너뛰지 않기로 선택하는 것. 그 선택이 체험의 질을 바꾼다. 강제로 모든 스테이지를 플레이하게 하는 것보다, 선택해서 플레이하게 하는 것이 더 깊은 몰입을 만든다. "나는 이 스테이지를 하고 싶어서 하고 있다"는 감각. 이 감각이 있을 때와 없을 때, 같은 체험이 전혀 다른 의미를 갖는다.

프로덕트에서도 같은 원리가 작동한다. 사용자가 "이 기능을 안 써도 되지만, 쓰기로 선택했다"고 느끼는 것과 "이 기능을 쓸 수밖에 없다"고 느끼는 것은 완전히 다른 경험이다. 선택지가 있다는 것은 자유가 있다는 것이고, 자유가 있다는 것은 자기 의지로 참여하고 있다는 것이다. 자기 의지로 참여한 경험은 기억에 남고, 강제된 경험은 소모된다.

자유를 주면 사용자가 떠날 수도 있다. 그 가능성을 감수하는 것이 용기다. 하지만 자유를 통해 남은 사용자는, 강제로 붙잡은 사용자와는 비교할 수 없는 깊이의 관계를 맺는다.

플레이어의 자유를 디자인하는 것

결국 프로덕트 디자인이란, 사용자를 붙잡는 구조를 만드는 것이 아니라 사용자가 자유롭게 오고 갈 수 있는 구조를 만드는 것이다. 떠날 수 있는데도 머무는 것, 멈출 수 있는데도 계속하는 것, 건너뛸 수 있는데도 플레이하는 것. 이 "~할 수 있는데도"가 체험의 가치를 만든다.

좋은 애니메이션이 엔딩을 두려워하지 않듯, 좋은 프로덕트도 사용자의 이탈을 두려워하지 않아야 한다. 완결된 체험을 제공하고, 깔끔하게 보내주고, 다시 올 이유를 남기는 것. 사용자가 프로덕트를 닫는 순간, "잘 썼다"는 감각이 남도록 하는 것. 그 감각이 내일 다시 여는 이유가 된다.

프로덕트에서 플레이어를 떼어내는 것은 포기가 아니다. 존중이다. 그리고 존중받았다고 느끼는 사용자만이, 진심으로 돌아온다.

예고 없는 프레젠테이션은 왜 실패하는가

Wed, 18 Mar 2026 18:00:00 GMT

폰을 꺼내는 정확한 타이밍

프레젠테이션을 하다 보면, 청중이 폰을 꺼내는 순간이 있다. 흥미로운 건 그 타이밍이 꽤 일정하다는 것이다. 발표 내용이 어려워서가 아니다. 재미없어서도 아니다. 청중이 폰을 꺼내는 정확한 순간은, "다음에 뭐가 나올지 감이 안 잡힐 때"다.

한번 떠올려보자. 누군가의 발표를 듣고 있는데, 한 슬라이드가 끝났다. 다음 슬라이드로 넘어갔는데, 이전 내용과 어떻게 연결되는지 모르겠다. "이 사람이 지금 어디로 가고 있는 거지?" 이 질문이 머릿속에 떠오르는 순간, 집중은 이미 끊겨 있다. 그리고 손은 자연스럽게 주머니 속 폰으로 간다. 의식적인 선택이 아니다. 뇌가 "이건 추적할 수 없다"고 판단한 것이다.

집중이 끊기는 진짜 이유

보통 발표가 실패하면, 내용이 부실했다거나 전달력이 부족했다고 분석한다. 물론 그것도 요인이 될 수 있다. 하지만 내용이 훌륭하고 전달력이 좋은데도 청중이 이탈하는 경우가 있다. 이때의 원인은 다른 곳에 있다. 이야기 흐름의 예측 불가능성이다.

사람의 뇌는 이야기를 들을 때 자동으로 다음을 예측한다. "문제를 설명했으니, 다음은 원인이겠지." "사례를 들었으니, 다음은 교훈이겠지." 이 예측이 대략적으로라도 맞으면, 뇌는 안심하고 이야기를 따라간다. 자신이 올바른 경로 위에 있다는 감각. 이 감각이 유지되는 한, 집중은 계속된다.

문제는 이 예측이 완전히 깨질 때다. 다음에 뭐가 올지 전혀 감이 잡히지 않으면, 뇌는 이야기를 쫓아가는 것을 포기한다. 미지의 길에서 이정표 없이 걷는 것과 같다. 어디로 가고 있는지 모르면, 계속 걸을 동기가 사라진다. 발표에서 청중이 이탈하는 건 지루해서가 아니라, 길을 잃어서다.

접속사가 만드는 예측 가능성

그렇다면 청중이 길을 잃지 않게 하려면 어떻게 해야 할까. 가장 단순하면서도 강력한 도구가 있다. 접속사다.

"다음으로"라고 말하면, 청중은 새로운 주제가 시작된다는 것을 안다. "예를 들어"라고 말하면, 구체적인 사례가 올 것을 예측한다. "그러나"라고 말하면, 앞의 내용을 뒤집는 무언가가 올 것을 기대한다. 이 짧은 단어 하나가 청중의 뇌에 이정표를 세운다. "아, 다음은 이런 종류의 이야기가 오겠구나."

접속사를 무시하고 이야기를 나열하면, 내용이 아무리 좋아도 청중의 머릿속에서는 분절된 슬라이드의 연속이 된다. 각각은 의미가 있지만, 흐름이 없다. 마치 챕터 번호가 없는 소설을 읽는 것과 비슷하다. 개별 장면은 좋은데, 전체 구조가 잡히지 않는다.

접속사는 화려한 기술이 아니다. 하지만 이야기에 골격을 부여한다. "첫째", "반면에", "결국" — 이런 단어들이 청중의 뇌에 지도를 그려준다. 지도가 있으면 사람은 걸을 수 있다. 지도가 없으면 멈춘다.

예고의 세 가지 기술

접속사가 문장 단위의 이정표라면, 예고는 구간 단위의 이정표다. 발표 전체의 흐름을 청중이 따라올 수 있게 하려면, 세 가지 종류의 예고가 필요하다.

첫째, 질문으로 예고하는 방법이 있다. "그렇다면 왜 이런 일이 벌어질까요?"라고 물으면, 청중의 뇌는 자동으로 답을 찾기 시작한다. 답을 찾으려는 상태에서 다음 슬라이드를 보면, 같은 정보라도 흡수 깊이가 다르다. 질문은 청중의 뇌를 수동에서 능동으로 전환시킨다. 다음에 올 내용을 "듣는" 것이 아니라 "찾는" 것으로 바꿔준다.

둘째, 의미심장한 중단이 있다. 핵심 메시지를 말하기 직전에 잠깐 멈추는 것이다. 이야기가 어떤 방향으로 흘러가고 있는데 갑자기 멈추면, 청중은 "왜 멈췄지?"라는 긴장감을 느낀다. 그 긴장감이 다음에 오는 말의 무게를 두 배로 만든다. 침묵은 빈 시간이 아니다. 기대를 증폭시키는 장치다.

셋째, 마무리 예고가 있다. "마지막으로 한 가지만 더 말씀드리겠습니다"라고 하면, 청중은 끝이 가까워졌음을 알고 집중력을 끌어올린다. 반대로 끝이 보이지 않는 발표는 청중을 지치게 한다. 마라톤에서 결승선이 보이면 마지막 힘을 낼 수 있지만, 결승선이 어디인지 모르면 페이스를 유지할 수 없는 것과 같다.

이 세 가지 — 질문, 중단, 마무리 예고 — 의 공통점은 청중에게 "다음에 무슨 일이 일어날지"에 대한 감각을 주는 것이다. 완벽하게 예측할 필요는 없다. 대략적인 방향만 알아도 사람은 따라온다.

예측 가능성과 놀라움의 리듬

여기서 한 가지 역설이 있다. 예측 가능성이 중요하다고 했는데, 그러면 발표가 뻔해지는 것 아닌가. 다음에 뭐가 올지 다 알면 재미없지 않은가.

맞는 지적이다. 예측 가능성만으로는 집중을 유지할 수 있지만, 몰입을 만들 수는 없다. 몰입이 생기려면, 예측 가능한 흐름 위에 예상치 못한 순간을 심어야 한다. 이것이 예측 가능성과 놀라움의 리듬이다.

구조는 이렇다. 먼저 청중이 "이건 이런 방향이겠지"라는 가설을 세울 수 있게 한다. 접속사와 예고를 통해 흐름의 뼈대를 보여준다. 청중이 안심하고 따라오는 상태가 만들어지면, 그때 예상을 뒤집는다. "그런데 실제로는 정반대였습니다." 안정된 흐름 위에서 터지는 반전은, 혼란이 아니라 쾌감이 된다. 가설이 먼저 있었기 때문에, 그 가설이 깨지는 순간이 강렬해지는 것이다.

이 리듬은 발표 전체에 걸쳐 반복되어야 한다. 예측 가능한 구간으로 안심시키고, 놀라운 순간으로 각성시키고, 다시 예측 가능한 구간으로 안심시키는 반복. 이 파동이 발표에 생명력을 준다. 예측만 있으면 졸리고, 놀라움만 있으면 피곤하다. 둘이 교차할 때 사람은 빠져든다.

발표 너머의 원리

이 원리는 프레젠테이션에만 적용되는 게 아니다. 글을 쓸 때도, 기획서를 작성할 때도, 심지어 일상적인 대화에서도 같은 구조가 작동한다.

글에서 문단의 첫 문장은 예고다. 이 문단에서 무엇을 다룰 것인지 독자에게 미리 알려준다. 그 예고가 없으면 독자는 문단 중간에서 길을 잃는다. 기획서에서 목차는 전체 흐름의 예고다. 목차를 읽는 것만으로 "아, 이런 순서로 이야기가 전개되겠구나"라는 감각이 생겨야 한다. 대화에서 "한 가지 물어봐도 될까"는 예고이고, "근데 말이야"는 전환의 신호다. 이런 작은 장치들이 상대방의 뇌가 다음을 준비할 시간을 만들어준다.

슬랙에서 긴 메시지를 보낼 때도 마찬가지다. "공유 드릴 것이 세 가지입니다"라고 시작하면 상대방은 마음의 준비를 한다. 아무런 예고 없이 장문의 메시지가 오면, 읽기도 전에 부담부터 느낀다. 같은 내용이지만, 예고가 있고 없고에 따라 수신자의 경험이 완전히 달라진다.

결국 모든 커뮤니케이션은 상대방의 뇌에 지도를 그려주는 일이다. "지금 여기에 있고, 다음은 저기로 간다"는 감각을 주는 것. 이 감각이 있으면 사람은 기꺼이 따라오고, 이 감각이 없으면 사람은 조용히 이탈한다. 프레젠테이션이 실패하는 진짜 이유는 내용이 나빠서가 아니다. 청중이 길을 잃었기 때문이다. 그리고 길을 잃게 만드는 가장 확실한 방법은, 예고 없이 이야기를 시작하는 것이다.

좋은 아이디어는 비밀에서 태어난다

Tue, 17 Mar 2026 20:00:00 GMT

"아이디어가 안 나와요"

이 말을 입 밖으로 꺼낸 적이 있을 것이다. 회의실에서, 카페에서, 새벽 두 시의 책상 앞에서. 그 순간에는 세 가지 불안이 동시에 찾아온다. 첫째, 기한이 다가오는데 아무것도 떠오르지 않는다는 공포. 둘째, 다른 사람들은 줄줄이 아이디어를 내놓는데 나만 빈 종이를 들고 있다는 자괴감. 셋째, 혹시 나는 원래 이런 사람이 아닐까 — 창의적이지 않은 사람이 아닐까 — 라는 정체성에 대한 의심.

이 세 가지가 겹치면, 사람은 아이디어를 "짜내려" 한다. 브레인스토밍을 하고, 레퍼런스를 뒤지고, 트렌드를 분석하고, 경쟁사를 벤치마킹한다. 방법론은 정교해지는데, 정작 나오는 것들은 어딘가에서 본 듯한 것들뿐이다. 무언가 근본적으로 방향이 잘못되었다는 감각. 그 감각은 대부분 맞다.

끝없이 생각한다는 함정

아이디어가 필요할 때, 가장 자연스러운 반응은 "더 많이 생각하는 것"이다. 머리를 쥐어짜고, 가능성을 나열하고, 조합을 시도한다. 논리적으로 보면 이 접근이 합리적이다. 더 많이 생각하면 더 좋은 것이 나올 확률이 높아지지 않겠는가.

하지만 실제로는 반대의 일이 일어난다. 생각을 많이 할수록 안전한 방향으로 수렴한다. 왜냐하면 "생각한다"는 행위 자체가 이미 검증의 프레임 안에서 작동하기 때문이다. "이건 될까?", "사람들이 좋아할까?", "말이 되는 이야기일까?" — 이런 질문들이 자동으로 필터가 되어, 조금이라도 위험해 보이는 것을 걸러낸다. 남는 것은 누구도 싫어하지 않지만, 누구도 열광하지 않는 것들이다.

끝없이 생각하는 접근이 실패하는 이유는, 그것이 바깥을 향하고 있기 때문이다. "다른 사람들은 뭘 원할까", "시장은 어떤 방향으로 갈까", "이게 먹힐까". 시선이 전부 외부를 향한다. 그러면 나오는 건 분석이지, 아이디어가 아니다. 분석은 이미 존재하는 것을 정리하는 일이고, 아이디어는 아직 존재하지 않는 것을 꺼내는 일이다. 도구가 다르다.

비밀이 가진 에너지

그렇다면 아이디어는 어디에서 오는가. 한 가지 힌트가 있다. "모두에게 비밀로 하고 있는 것을 생각하라."

이 말이 처음에는 기이하게 들린다. 기획에 비밀이 무슨 상관인가. 하지만 곰곰이 생각해보면, 사적인 것일수록 보편적인 공감을 만든다는 역설이 있다. 개인적인 불안, 아무에게도 말하지 못한 고민, 혼자만 겪었다고 생각하는 경험. 이런 것들을 꺼내면, 듣는 사람은 놀랍도록 빠르게 공감한다. "나도 그랬어"라고.

이유는 단순하다. 사적인 것은 가공되지 않은 것이기 때문이다. 시장 분석이나 트렌드 리포트에서 나온 아이디어는 이미 수많은 사람의 필터를 거친 것이다. 모서리가 깎이고, 안전하게 다듬어진 것. 반면 자기 안의 사적인 영역에서 나온 것은 날것이다. 날것에는 힘이 있다. 정제되지 않았기 때문에 오히려 진짜처럼 느껴진다.

가장 개인적인 에세이가 가장 많은 사람에게 읽히고, 가장 사적인 경험에서 나온 제품이 가장 넓은 시장을 만드는 이유가 여기에 있다. 비밀에는 에너지가 있다. 그 에너지는 "나만 이런 건 아닐까"라는 불안에서 온다. 그리고 그 불안이야말로, 많은 사람이 공유하지만 아무도 먼저 말하지 않는 것의 정체다.

사고의 단편을 수집하는 방법

그렇다고 "자기 안을 들여다봐라"는 말이 당장 실용적으로 들리지는 않는다. 구체적으로 어떻게 해야 할까. 방법은 의외로 소박하다. 소중한 것을 발견하는 것이다.

소중한 것이란 거창한 게 아니다. 일상에서 유독 마음이 머무는 것들이다. 퇴근길에 우연히 본 간판의 문구가 하루 종일 머릿속에 맴돌 때. 누군가의 말 한마디가 맥락 없이 떠올라서 멍해질 때. 어떤 제품을 쓰다가 "왜 이건 이렇게 만들었지?"라는 의문이 사라지지 않을 때. 이런 것들이 사고의 단편이다.

문제는 이런 단편들이 대부분 흘러간다는 것이다. 떠올랐다가 사라지고, 다시 떠오르지 않는다. 기획을 해야 하는 순간에 "그때 뭔가 좋은 생각이 있었는데…"라고 말하며 허공을 더듬는 경험. 이건 기억력의 문제가 아니다. 기록의 문제다. 단편들을 잡아두지 않았기 때문이다.

단편을 수집하는 사람은 기획 회의에서 다르다. 백지에서 시작하는 게 아니라, 축적된 단편들 사이에서 연결을 찾는다. "이 단편과 저 단편이 만나면 뭐가 될까?" 아이디어는 무에서 유를 창조하는 일이 아니라, 흩어져 있던 단편들이 하나의 맥락으로 엮이는 순간이다. 단편이 많을수록 조합의 가능성도 넓어진다.

수집의 방법은 각자 다를 수 있다. 메모장에 한 줄을 적는 사람도 있고, 사진을 찍는 사람도 있고, 음성 메모를 남기는 사람도 있다. 중요한 건 형식이 아니라 습관이다. 마음이 머무는 것을 놓치지 않겠다는 습관.

위기가 기획을 가속한다

사고의 단편 중에서도 가장 강력한 연료가 되는 것이 있다. 위기의 경험이다.

사람은 위기 상황에서 자신에 대해 가장 많은 것을 알게 된다. 평소에는 의식하지 못했던 가치관이 드러나고, 자신이 진짜 중요하게 여기는 것이 선명해진다. 커리어의 위기, 관계의 위기, 건강의 위기 — 종류는 다르지만 공통점이 있다. 위기의 순간에 떠오르는 생각들은 극도로 사적이면서, 동시에 극도로 보편적이다.

위기를 겪은 사람의 기획에는 절실함이 있다. "이건 진짜 필요한 거야"라는 확신이, 시장 분석에서는 절대 나올 수 없는 깊이로 박혀 있다. 그 확신은 데이터가 아니라 경험에서 온 것이기 때문에, 논리적으로 반박하기 어렵다. 그리고 그 절실함이 기획에 방향과 에너지를 동시에 준다.

물론 위기가 없어도 기획은 할 수 있다. 하지만 위기를 겪었고, 그 과정에서 발견한 사적인 통찰을 기획에 녹여넣을 수 있다면, 그것은 단순한 기능 제안이 아니라 이야기가 된다. 사람은 기능에 지갑을 열지만, 이야기에 마음을 연다.

기획에 대해 생각하는 것은 자신에 대해 생각하는 것이다

결국 아이디어의 원천은 밖에 있지 않다. 트렌드 리포트에도, 경쟁사 분석에도, 브레인스토밍 회의실에도 없다. 아이디어의 진짜 원천은 자기 안의 사적인 영역이다. 아무에게도 말하지 않은 불편함, 혼자만 느끼고 있다고 생각하는 결핍, 설명하기 어렵지만 분명히 존재하는 열망.

기획에 대해 생각하는 것은, 곧 자신에 대해 생각하는 것이다. 내가 뭘 불편해하는지, 내가 뭘 간절히 원하는지, 내가 어떤 순간에 마음이 움직이는지. 이런 질문들을 회피하면서 좋은 아이디어를 기대하는 것은 모순이다. 자기 자신을 모르는 사람이 다른 사람의 마음을 움직이는 것을 만들 수는 없다.

아이디어가 나오지 않는다면, 더 많이 생각하지 마라. 대신 자기 안을 더 깊이 들여다봐라. 누구에게도 말하지 않은 것, 사소해서 넘겼지만 자꾸 떠오르는 것, 위기의 순간에 비로소 선명해졌던 것. 좋은 아이디어는 언제나 그런 비밀에서 태어난다. 가장 사적인 것이 가장 보편적인 것이 되는 순간, 그것이 기획이 시작되는 자리다.

명령이 아니라 장면을 보여줘라

Tue, 17 Mar 2026 12:00:00 GMT

"치워" vs "이건 어디에 두면 돼?"

아이에게 "장난감 치워"라고 말하면, 십중팔구 꿈쩍도 하지 않는다. 한 번 더 말하면 겨우 몸을 일으키고, 세 번째 말해야 투덜거리며 움직인다. 그런데 같은 상황에서 장난감 하나를 집어 들고 "이건 어디에 두면 돼?"라고 물으면, 아이가 직접 와서 보여준다. "이건 여기, 이건 저기." 어느새 자기가 치우고 있다. 아무도 치우라고 명령하지 않았는데.

이 차이가 매니지먼트의 거의 모든 것을 설명한다. 명령은 저항을 만들고, 장면은 행동을 만든다. 아이를 키우는 것과 팀을 이끄는 것은 놀라울 정도로 닮아 있다. 둘 다 내가 원하는 방향으로 상대를 움직여야 하지만, 직접 움직일 수는 없다. 상대가 스스로 움직이게 만들어야 한다.

왜 명령은 저항을 만드는가

"이렇게 해." 이 한마디에는 암묵적인 메시지가 담겨 있다. "네 판단은 필요 없어. 내가 정한 대로 따라와." 명령을 받는 순간, 사람의 뇌는 자율성을 위협받았다고 판단한다. 설령 명령의 내용이 합리적이더라도, 형식 자체가 저항을 유발한다. 이건 고집이 아니라 본능이다.

외부 동기와 내부 동기의 차이가 여기 있다. 외부 동기는 누군가 시켜서 하는 것이다. 보상이 있으니까, 혼나기 싫으니까, 그냥 시키니까. 이런 동기는 빠르게 작동하지만 오래가지 않는다. 감시가 사라지면 행동도 사라진다. 반면 내부 동기는 스스로 하고 싶어서 하는 것이다. 재밌으니까, 의미가 있으니까, 내 문제라고 느끼니까. 이 동기는 느리게 시작하지만 훨씬 오래 지속된다.

명령은 외부 동기를 만든다. 장면은 내부 동기를 만든다. "이렇게 해"는 행동을 강제하지만, "이건 어디에 두면 돼?"는 생각을 유도한다. 생각이 시작되면 행동은 자연스럽게 따라온다. 그리고 그 행동은 시킨 것이 아니라 자기가 선택한 것이 되므로, 책임감과 몰입이 달라진다.

장면이 행동을 유도하는 원리

추상적인 지시는 사람을 얼어붙게 한다. "코드 품질을 높여주세요"라고 말하면, 듣는 사람의 머릿속에는 아무런 그림도 떠오르지 않는다. 코드 품질이 뭔지는 알지만, 지금 당장 무엇을 해야 하는지는 모호하다. 반면 "김 개발자, 지난주에 올린 결제 모듈 PR에서 에러 핸들링 빠진 부분 세 곳이 있었어요"라고 말하면, 머릿속에 구체적인 장면이 떠오른다. 어떤 파일의 어떤 부분인지 바로 떠올리고, 무엇을 해야 하는지 선명해진다.

고유명사의 힘이 여기 있다. "잘해주세요"는 아무것도 상기시키지 않지만, "지난 목요일 스탠드업에서 이야기한 그 건"이라고 말하면 기억의 회로가 켜진다. 구체적인 이름, 날짜, 장소, 상황. 이런 고유명사들이 머릿속에 장면을 그린다. 장면이 그려지면 감정이 붙고, 감정이 붙으면 행동이 따른다.

좋은 지시는 명령문이 아니라 묘사문이다. 상대의 머릿속에 구체적인 장면을 심어주는 것. "더 잘해"가 아니라, "이런 상황에서 이렇게 되면 어떨까"를 보여주는 것이다.

실수를 체험하게 하는 기술

아이에게 칫솔을 거꾸로 잡으면 안 된다고 백 번 말해봐야 소용이 없다. 하지만 칫솔 자루 쪽으로 이를 닦아보게 하면, 한 번에 이해한다. "아, 이쪽으로 하면 안 닦이는구나." 직접 체험한 실수는 백 마디 설명보다 강력하다.

이 원리는 조직에서도 동일하게 작동한다. 신입 개발자에게 "테스트 코드를 꼭 작성하세요"라고 열 번 말하는 것보다, 테스트 없이 배포했다가 장애가 나는 경험을 한 번 하게 하는 것이 더 효과적이다. 물론 치명적인 장애를 일부러 만들 수는 없다. 하지만 안전한 범위 안에서 실수를 경험하게 하는 것은 가능하다. 스테이징 환경에서 배포해보게 하거나, 작은 프로젝트에서 자기 판단대로 진행해보게 하거나.

중요한 건, 실수 후에 혼내지 않는 것이다. "그것 봐, 내가 뭐라고 했어"라는 말은 체험의 가치를 제로로 만든다. 실수를 체험한 직후에 필요한 건 지적이 아니라 질문이다. "어떻게 된 것 같아?" "다음에는 어떻게 하면 좋을까?" 이 질문이 상대로 하여금 자기 경험에서 스스로 교훈을 끌어내게 한다. 결론을 내 입으로 말하는 순간, 그건 상대의 깨달음이 아니라 나의 잔소리가 된다.

조직에서의 적용

코드 리뷰를 생각해보자. "이 코드는 좋지 않습니다. 수정해주세요"라는 코멘트와, "이 함수가 호출되는 시점에 connection pool이 소진된 상태라면 어떻게 될까요?"라는 코멘트. 전자는 명령이고 후자는 장면이다. 전자를 받으면 방어적이 되고, 후자를 받으면 생각하게 된다. 후자는 상대의 머릿속에 특정 시나리오를 그려주고, 스스로 문제를 발견하게 만든다.

온보딩도 마찬가지다. 새로 합류한 사람에게 문서 더미를 던져주는 것과, "첫 주에는 이 기능 하나를 직접 배포까지 해보세요"라고 하는 것은 완전히 다른 경험이다. 전자는 정보의 전달이고, 후자는 장면의 설계다. 직접 배포하는 과정에서 빌드 파이프라인을 이해하고, 코드 리뷰 프로세스를 겪고, 배포 후 모니터링을 확인하게 된다. 누가 설명하지 않아도, 장면이 가르친다.

팀 가이드라인을 만들 때도 같은 원리가 적용된다. "커뮤니케이션을 활발히 합시다"라는 선언은 아무런 행동도 만들지 않는다. 하지만 "PR을 올리면 24시간 안에 최소 한 명이 리뷰한다"라는 구체적인 장면을 제시하면, 행동이 따라온다. 원칙은 추상적이어도 되지만, 가이드라인은 장면이어야 한다.

좋은 매니저는 답이 아니라 장면을 만든다

명령하는 매니저는 팀이 자기 없이는 움직이지 못하게 만든다. 모든 결정이 매니저를 거쳐야 하고, 모든 판단이 매니저의 승인을 필요로 한다. 이 구조는 매니저의 존재감을 높이지만, 팀의 자율성을 죽인다. 매니저가 병목이 되고, 팀원은 실행자로 고정된다.

장면을 만드는 매니저는 다르다. 이들은 팀원이 스스로 판단하고 행동할 수 있는 환경을 설계한다. 결정을 내려주는 대신, 결정에 필요한 맥락을 보여준다. 답을 알려주는 대신, 답을 찾을 수 있는 질문을 던진다. 실수를 막는 대신, 안전한 범위에서 실수를 경험하게 한다.

아이에게 "장난감 치워"라고 말하면, 아이는 부모의 지시에 반응하는 존재로 남는다. "이건 어디에 두면 돼?"라고 물으면, 아이는 정리의 주체가 된다. 조직도 같다. "이렇게 해"라고 지시하면 팀원은 수동적 실행자로 남고, "이런 상황인데, 어떻게 하면 좋을까?"라고 장면을 보여주면 팀원은 문제의 주인이 된다.

결국 좋은 매니지먼트란 사람을 움직이는 기술이 아니다. 사람이 스스로 움직이고 싶어지는 장면을 만드는 기술이다. 명령은 순간의 행동을 만들지만, 장면은 지속적인 판단력을 만든다. 답을 줄수록 의존이 생기고, 장면을 줄수록 자율이 생긴다. 그래서 가장 좋은 매니저는 팀이 자기 없이도 잘 돌아가게 만드는 사람이다. 역설적이지만, 존재감이 사라지는 것이 최고의 성과다.

침묵이 설득하는 순간

Mon, 16 Mar 2026 09:00:00 GMT

"그때 말이 끊겼다"

발표 도중에 머릿속이 하얘진 적이 있다. 다음 슬라이드로 넘기려는데 무슨 말을 해야 할지 모르겠고, 입이 열리지 않았다. 2초, 3초. 체감으로는 30초쯤 되는 것 같은 침묵. 끝났다고 생각했다. 그런데 이상한 일이 벌어졌다. 고개를 숙이고 있던 청중이 하나둘 고개를 들었다. 노트북에서 눈을 떼고, 나를 바라보기 시작했다. 침묵이 만든 빈 공간에, 사람들의 주의가 빨려 들어온 것이다.

말을 이어가는 동안에는 아무도 집중하지 않았다. 말이 멈춘 순간에 모두가 집중했다. 그 경험이 꽤 오랫동안 머릿속에 남았다. 왜 말이 없는 순간이 말보다 강했을까.

말이 많아질수록 설득력이 떨어지는 이유

확신이 넘치는 사람은 말이 많아진다. 자기가 알고 있는 것을 전부 쏟아내야 할 것 같은 충동. 근거를 하나 더 대고, 사례를 하나 더 들고, 부연 설명을 하나 더 붙이면 상대가 설득될 거라는 믿음. 하지만 실제로는 반대다. 말이 많아질수록 핵심이 묻히고, 청자의 뇌는 정보를 처리하다 지쳐서 방어 모드에 들어간다.

이건 라디오 주파수와 비슷하다. 하나의 채널에서 선명한 소리가 나오면 귀가 기울어진다. 그런데 여러 채널이 동시에 겹치면, 아무리 좋은 내용이라도 잡음이 된다. 확신의 과잉은 노이즈를 만든다. 상대방의 머릿속에 여러 메시지가 동시에 밀려들어가면, 어느 것 하나 또렷하게 남지 않는다.

설득이 안 될 때 본능적으로 더 많이 말하게 된다. 하지만 그 순간 해야 할 일은 말을 더하는 게 아니라 말을 빼는 것이다. 메시지가 선명해지려면 여백이 필요하다. 그리고 그 여백의 가장 강력한 형태가 침묵이다.

침묵이 만드는 세 가지 효과

침묵은 단순히 말이 없는 상태가 아니다. 침묵에는 세 가지 작동 원리가 있다.

첫째, 긴장이다. 사람은 대화나 발표에서 일정한 리듬을 기대한다. 말이 이어지고, 질문이 나오고, 답이 돌아오는 흐름. 이 리듬이 갑자기 끊기면, 뇌는 "뭔가 달라졌다"고 경고를 보낸다. 예측이 깨지면서 주의가 집중된다. 영화에서 배경음악이 갑자기 사라지면 관객이 긴장하는 것과 같은 원리다. 침묵은 청자의 레이더를 강제로 켠다.

둘째, 여백이다. 말이 계속 이어지면 청자는 수동적 수신자가 된다. 듣기만 하면 되니까. 하지만 침묵이 끼어들면, 그 빈 공간에서 청자 스스로 생각을 시작한다. 방금 들은 말을 되새기고, 자기 경험과 연결하고, 의문을 품는다. 침묵은 상대에게 사고의 시간을 선물한다. 말이 채우지 못하는 것을 침묵이 채운다.

셋째, 주체성의 전환이다. 대화에서 한쪽이 계속 말하면, 주도권은 말하는 쪽에 있다. 그런데 말하는 사람이 침묵하면, 갑자기 공이 상대에게 넘어간다. "내가 뭔가 해야 하나?" 이 감각이 청자를 수동에서 능동으로 전환시킨다. 설득의 핵심은 상대가 스스로 결론에 도달하게 하는 것인데, 침묵은 그 전환의 스위치다.

프레젠테이션에서의 침묵 설계

프레젠테이션에서 청중의 집중력은 일정하지 않다. 시작 후 몇 분은 호기심으로 집중하지만, 중반으로 갈수록 떨어진다. 여기서 대부분의 발표자가 하는 실수는, 집중력이 떨어지는 구간에서 더 많은 정보를 넣는 것이다. "이것도 알아야 하고, 저것도 중요하고." 이러면 청중은 더 빠르게 이탈한다.

반대로, 집중력이 떨어지는 바로 그 지점에 침묵을 배치하면 효과가 극적으로 달라진다. 핵심 메시지를 말한 직후, 2~3초의 의도적인 정지. 슬라이드를 넘기기 전, 잠깐의 공백. 이 짧은 침묵이 청중의 뇌를 리셋한다.

터부의 모티프라는 이야기 기법이 있다. 신화에서 영웅에게 "절대 하지 말라"는 금기가 주어지면, 독자는 그 금기가 깨질 순간을 기다리며 긴장한다. 침묵도 같은 원리다. 말의 흐름 속에 갑자기 삽입된 침묵은 일종의 금기 위반이다. "말해야 하는 자리에서 말하지 않는다"는 규범의 위반이 긴장을 만들고, 그 긴장이 다음 말에 무게를 싣는다.

좋은 발표자는 무엇을 말할지 설계하는 것이 아니라, 어디서 멈출지를 설계한다.

1on1과 피드백에서의 침묵

피드백을 줄 때 가장 흔한 실수는, 말을 다 해버리는 것이다. 문제를 짚고, 원인을 분석하고, 해결책까지 제시하면 피드백을 준 사람은 뿌듯하다. 하지만 받는 사람의 머릿속에는 아무것도 남지 않는다. 남이 내려준 결론은 흡수되지 않기 때문이다.

1on1에서 "이 부분은 어떻게 생각해?"라고 질문을 던진 뒤, 침묵을 견디는 것이 가장 어렵고 가장 중요한 기술이다. 상대가 3초 안에 답하지 않으면, 보충 설명을 하고 싶은 충동이 생긴다. "아, 그러니까 내가 말하려는 건..." 하면서 다시 말을 이어가버린다. 그 순간, 상대가 스스로 생각할 기회를 빼앗은 것이다.

좋은 피드백은 빈칸이 있다. 문제를 짚되 해결책은 비워둔다. 질문을 던지되 답은 기다린다. 그 빈 공간에서 상대가 자기 말로 결론을 만들어야, 비로소 피드백이 행동으로 이어진다. 침묵은 상대에게 사고의 소유권을 넘기는 행위다.

침묵을 두려워하는 사람과 설계하는 사람

침묵을 두려워하는 사람은 빈 공간을 위협으로 느낀다. 대화에서 0.5초만 빈틈이 생겨도 불안해서 말을 채워 넣는다. 회의에서 정적이 흐르면 참지 못하고 의미 없는 말을 꺼낸다. 발표에서 잠시라도 멈추면 실수한 것 같은 기분이 든다. 이들에게 침묵은 실패의 신호다.

침묵을 설계하는 사람은 빈 공간을 도구로 본다. 이들은 안다. 말이 없는 순간이야말로 메시지가 가장 깊이 전달되는 순간이라는 것을. 그래서 어디에 침묵을 넣을지를 의도적으로 계획한다. 핵심 메시지 뒤에 여백을 두고, 질문 뒤에 기다림을 두고, 감정이 필요한 순간에 말을 멈춘다. 이들에게 침묵은 전략이다.

결국 침묵은 말의 부재가 아니라 말의 완성이다. 음악에서 쉼표가 없으면 선율이 무너지듯, 대화에서 침묵이 없으면 메시지가 무너진다. 말을 잘하는 사람은 무엇을 말할지 아는 사람이고, 설득을 잘하는 사람은 언제 말을 멈출지 아는 사람이다. 가장 강력한 메시지는 말 속에 있지 않다. 말이 멈춘 그 순간의 적막 속에 있다.

과정을 디자인하는 사람과 결과를 만드는 사람

Sun, 15 Mar 2026 20:00:00 GMT

"재밌게 만들어주세요"

이 요청을 받아본 적 있을 것이다. 기획서를 검토하다가, 프레젠테이션을 준비하다가, 제품의 방향을 논의하다가 — 누군가 이렇게 말한다. "좀 더 재밌게 만들어주세요." 그 순간 막막해진다. 재밌다는 게 뭔데? 어떻게 하면 재밌어지는 건데?

이 막막함에는 이유가 있다. "재밌다"는 결과이지 과정이 아니기 때문이다. 재밌다는 감정은 직접 만들어낼 수 없다. 누군가에게 "지금부터 재밌어하세요"라고 말해봐야 재밌어지지 않는다. 재밌다는 감정은, 어떤 과정을 겪은 끝에 저절로 생겨나는 것이다. 우리가 할 수 있는 건 결과를 직접 만들어내는 게 아니라, 그 결과로 이어지는 과정을 설계하는 것뿐이다.

결과를 직접 만들 수 없다는 역설

생각해보면, 우리가 가장 중요하게 여기는 것들은 대부분 직접 만들 수 없는 것들이다. 몰입, 감동, 신뢰, 성장. 이것들은 모두 결과다. 누군가에게 "몰입해"라고 명령할 수 없고, "감동받아"라고 지시할 수 없다. 이것들은 특정한 조건과 흐름 속에서 자연스럽게 발생한다.

그런데 많은 기획과 제품이 결과를 직접 만들려고 한다. 재밌으라고 화려한 이펙트를 넣고, 감동하라고 감성적인 카피를 쓰고, 몰입하라고 정보를 잔뜩 쏟아붓는다. 의도는 좋지만, 방향이 거꾸로다. 결과를 향해 직진하면 오히려 결과에서 멀어진다. 중요한 건, 그 결과가 자연스럽게 흘러나오는 과정을 설계하는 것이다.

세 가지 과정의 설계도

그렇다면 어떤 과정이 사람의 마음을 움직일까? 여기에 세 가지 구조가 있다.

첫째, 가설에서 환희로 가는 흐름이 있다. 무언가를 보고 "이건 아마 이렇게 되겠지"라는 가설이 떠오르고, 직접 시행해보고, 예상대로 들어맞았을 때의 쾌감. "역시 내 생각이 맞았어!" 이 흐름은 스스로 해냈다는 성취감을 만든다.

둘째, 오해에서 경악으로 가는 흐름이 있다. 당연히 이럴 거라고 생각하고 행동했는데, 전혀 예상치 못한 결과가 나오는 순간의 충격. "어? 이게 뭐야?" 이 흐름은 기존 전제를 깨뜨리면서 강렬한 인상을 남긴다.

셋째, 번뇌에서 의지로 가는 흐름이 있다. 해결할 수 없을 것 같은 난관에 부딪히고, 고군분투 끝에 한 단계 성장하고, "다시 해볼 수 있겠어"라는 의지가 생기는 흐름. 이 구조는 우리가 이야기라고 부르는 것의 뼈대다.

이 세 가지는 서로 다른 감정을 만들지만, 공통점이 있다. 모두 과정이라는 것이다. 환희도, 경악도, 의지도 — 결과물을 직접 쥐여주는 게 아니라, 특정한 흐름을 겪게 함으로써 자연스럽게 발생한다.

나도 모르게 빠져드는 기획

첫 번째 흐름, 가설에서 환희로 가는 구조를 기획에 적용해보자. 좋은 기획서는 읽는 사람이 "이건 이렇게 되겠군"이라는 가설을 세울 수 있게 만든다. 현황과 문제를 제시하면, 읽는 사람의 머릿속에서 자연스럽게 "그럼 이런 방향이겠네"라는 예측이 떠오른다. 그리고 다음 페이지에서 그 예측을 확인하거나, 살짝 다른 각도로 발전시키면 — 읽는 사람은 "내 생각과 통했어"라는 감각을 느낀다.

이런 기획서는 설득하지 않는다. 읽는 사람이 스스로 결론에 도달하게 만든다. 설득은 외부의 힘이지만, 자기 확인은 내부의 동력이다. "나도 모르게" 빠져드는 경험은 바로 이 구조에서 나온다. 기획이라는 체험을 재설계하면, 기획의 목적인 "사람의 마음을 움직이는 것"에 더 가까워진다.

예상을 뒤집는 제안

두 번째 흐름, 오해에서 경악으로 가는 구조는 임팩트에 대한 것이다. 프레젠테이션에서, 제품에서, 제안에서 — 사람의 기억에 오래 남는 것은 예상이 맞아떨어진 순간이 아니라 예상이 깨진 순간이다.

"이 문제의 원인은 A입니다"라는 슬라이드를 보고 모두가 고개를 끄덕인다. 당연한 분석이니까. 하지만 다음 슬라이드에서 "하지만 실제 데이터를 보면, A가 아니라 B였습니다"라고 뒤집으면, 회의실의 공기가 바뀐다. 당연하다고 믿었던 전제가 틀렸다는 깨달음. 이 순간의 충격이 메시지를 각인시킨다.

중요한 건, 이 놀라움이 작동하려면 먼저 "확신"이 있어야 한다는 것이다. 확신이 없으면 뒤집힐 것도 없다. "당연히 그렇지"라는 안정감을 먼저 만들고, 그 안정감을 정확한 타이밍에 깨뜨려야 한다. 순서가 중요하다.

성장 서사가 있는 조직

세 번째 흐름, 번뇌에서 의지로 가는 구조는 이야기의 힘에 대한 것이다. 사람은 자기 인생을 이야기로 이해한다. 지금 겪고 있는 어려움이 성장의 한 단계라고 느끼면 견딜 수 있고, 의미 없는 반복이라고 느끼면 무너진다.

좋은 조직에는 성장 서사가 있다. "지금은 힘들지만, 이 과정을 지나면 우리는 이전과 다른 팀이 된다"는 흐름이 보인다. 이건 리더가 억지로 주입하는 게 아니라, 실제로 팀이 난관을 넘고 달라지는 경험을 반복하면서 축적된다. 한 번의 위기를 넘기고 "우리가 이걸 해냈어"라는 기억이 쌓이면, 다음 위기가 와도 "이번에도 해낼 수 있어"라는 의지가 생긴다.

반대로, 성장 서사가 없는 조직에서는 어려움이 그저 고통이다. 같은 강도의 업무라도, "이걸 왜 하는지 모르겠다"는 감각 속에서 하면 소진되고, "이걸 넘으면 우리가 달라진다"는 감각 속에서 하면 몰입된다. 차이를 만드는 것은 업무의 양이 아니라, 그 업무가 놓인 서사의 구조다.

과정을 디자인하는 사람이 결과도 만든다

결과를 직접 만들려는 사람은 재밌는 기능을 넣고, 감동적인 카피를 쓰고, 임팩트 있는 숫자를 강조한다. 과정을 디자인하는 사람은 사용자가 스스로 발견하는 순간을 만들고, 예상이 뒤집히는 구조를 설계하고, 어려움을 넘는 서사를 깐다. 전자는 전달하고, 후자는 체험하게 한다.

역설적으로, 결과에 집착하지 않는 사람이 더 좋은 결과를 만든다. 재밌게 하려고 안간힘을 쓰는 대신, 사람이 자연스럽게 빠져드는 흐름을 설계하면 — 재미는 그 안에서 저절로 태어난다. 기획이든, 프레젠테이션이든, 조직 운영이든, 제품이든. 결국 우리가 만드는 모든 것은 누군가의 시간 위에 놓인다. 그 시간이 흘러가는 과정을 설계하는 것이, 결과를 만드는 가장 확실한 방법이다.

문맥이 경험의 가치를 결정한다

Sun, 15 Mar 2026 11:00:00 GMT

"같은 말인데 왜 다르게 들릴까"

"수고했어." 이 한마디가 어떤 날은 위로가 되고, 어떤 날은 아무 감흥도 없다. 밤새 코드를 짜고 겨우 버그를 잡아낸 직후에 듣는 "수고했어"와, 평범한 하루를 마치고 퇴근길에 듣는 "수고했어"는 같은 문장이지만 완전히 다른 경험이다. 말이 바뀐 게 아니다. 그 말을 받아들이는 내 안의 맥락이 다른 것이다.

우리는 흔히 무엇을 전달하느냐에 집중한다. 어떤 기능을 넣을 것인가, 어떤 메시지를 보낼 것인가, 어떤 피드백을 줄 것인가. 하지만 전달하는 것의 가치는, 그것이 놓이는 맥락에 의해 결정된다. 같은 것도 언제, 어디서, 어떤 상황에서 마주치느냐에 따라 전혀 다른 무게를 갖는다.

돌멩이의 세 가지 인생

하나의 돌멩이가 있다고 해보자. 별볼일 없고 하찮은, 그냥 돌멩이. 이 돌멩이를 재밌는 것으로 만들 수 있을까? 아무리 발버둥 쳐도 한낱 돌멩이 따위가 재밌어질 리 없다. 그렇다면 이런 방법은 어떨까.

길게 쭉 뻗은 길 한가운데에 돌멩이를 둔다. 지나가던 사람은 그것을 무심코 차버리고 싶어질 것이다. 별것 아니지만, 거기에 작은 행위가 생긴다. 공포영화를 보고 있는 사람 옆에 떨어뜨린다면? 분명 놀랄 것이고, 너무 어처구니가 없어서 웃음이 나올지도 모른다. 감금된 사람의 주머니에 넣어두면? "왜 여기 돌이 있지?", "이 돌을 이용해서 도망갈 수는 없을까?" 한낱 돌멩이를 앞에 두고 진지하게 고민할 것이다.

돌멩이는 바뀌지 않았다. 바뀐 것은 돌멩이가 놓인 상황, 즉 문맥이다. 중요한 것은 돌멩이 그 자체가 아니라, 돌멩이와 사람이 스치는 "마음의 문맥"이다.

기능이 아니라 맥락이다

프로덕트를 만들 때도 똑같은 일이 일어난다. 같은 알림 기능이라도, 사용자가 그것을 마주치는 맥락에 따라 가치가 달라진다. 무언가를 열심히 찾고 있는 중에 뜨는 추천 알림은 "와, 딱 필요했던 건데"가 된다. 하지만 아무것도 하고 싶지 않은 일요일 아침에 뜨는 같은 알림은 방해물에 불과하다.

기능 자체의 완성도는 중요하다. 하지만 완벽한 기능이라도 잘못된 맥락에 놓이면 가치가 사라진다. 반대로, 단순한 기능이라도 정확한 맥락에 놓이면 놀라운 가치를 만든다. 검색 결과 페이지 맨 아래에 놓인 "관련 질문" 하나가, 사용자의 탐색을 완전히 새로운 방향으로 이끌기도 한다. 기능은 같지만, 그것이 놓인 자리가 다르면 결과가 달라진다.

많은 기획자가 "어떤 기능을 만들 것인가"에 에너지를 쓴다. 하지만 더 중요한 질문은 "이 기능이 사용자의 어떤 순간에 놓일 것인가"다.

타이밍이라는 문맥

문맥 중에서도 가장 강력한 것은 타이밍이다. 같은 조언도 시점에 따라 잔소리가 되거나 통찰이 된다. "데이터를 먼저 봐야 해"라는 말을, 이미 결정을 내린 후에 들으면 간섭으로 느낀다. 하지만 여러 선택지 앞에서 갈팡질팡하고 있을 때 들으면, 판단의 축이 된다.

프레젠테이션에서도 마찬가지다. 핵심 메시지를 언제 꺼내느냐가 메시지의 무게를 결정한다. 처음부터 결론을 말하면 "당연한 얘기"가 되고, 청중이 "그래서 어쩌라고?"라는 질문이 떠오를 즈음에 꺼내면 같은 결론이 "바로 이거였어"가 된다.

기획에서, 피드백에서, 대화에서 — 무엇을 말하느냐보다 언제 말하느냐가 경험의 밀도를 결정한다. 타이밍은 내용을 바꾸지 않으면서 가치를 바꾸는 보이지 않는 변수다.

문맥을 읽는 사람, 문맥을 만드는 사람

세상에는 문맥을 읽는 사람과 문맥을 만드는 사람이 있다. 문맥을 읽는 사람은 상대방이 지금 어떤 상태인지, 팀이 어떤 흐름 속에 있는지를 감지하고 거기에 맞춰 행동한다. 이것만으로도 상당히 유능하다. 대화에서 분위기를 읽고, 회의에서 적절한 시점에 발언하고, 사용자가 필요로 하는 순간에 기능을 제안하는 것. 문맥을 읽는 능력은 센스라고 불리지만, 사실은 관찰의 축적이다.

문맥을 만드는 사람은 한 단계 더 간다. 단순히 기존 맥락에 반응하는 것이 아니라, 의도적으로 맥락을 설계한다. 제품의 온보딩 흐름을 통해 사용자가 특정 기능을 "발견"하는 순간을 만들어내거나, 프레젠테이션의 구조를 통해 청중이 특정 시점에 특정 질문을 떠올리게 하거나, 팀의 루틴을 통해 구성원이 자연스럽게 서로의 일에 관심을 갖게 하거나. 이들은 콘텐츠를 만드는 게 아니라 콘텐츠가 놓일 무대를 만든다.

당신의 일에도 문맥이 있다

이 원리는 거대한 프로덕트에만 적용되는 게 아니다. 일상적인 업무에도 문맥은 작동한다.

코드 리뷰를 할 때, 같은 피드백이라도 PR 설명에 맥락이 잘 적혀 있으면 건설적인 토론이 되고, 맥락 없이 코드만 덩그러니 있으면 방어적인 반응이 나온다. 아이디어를 제안할 때, 팀이 현재 겪고 있는 문제를 먼저 공유하고 나서 제안하면 공감을 얻고, 맥락 없이 "이거 해보면 어떨까요"라고 던지면 공허하게 들린다. 이력서 한 줄, 슬랙 메시지 하나, 1:1 미팅에서의 질문 하나. 모든 것에 문맥이 있고, 그 문맥이 의미의 크기를 결정한다.

결국, 같은 돌멩이도 어디에 놓느냐에 따라 걸림돌이 되기도 하고, 탈출의 도구가 되기도 하고, 웃음의 소재가 되기도 한다. 우리가 만드는 모든 것 — 기능, 메시지, 피드백, 경험 — 의 가치는 그것 자체에 있지 않다. 그것이 누군가의 마음과 만나는 순간의 문맥에 있다. 문맥을 설계할 수 있는 사람이, 같은 재료로 다른 가치를 만들어내는 사람이다.

왜 모든 여행은 집으로 돌아오는가

Sat, 14 Mar 2026 21:00:00 GMT

"결국 돌아왔다"

여행을 다녀온 직후의 감각이 있다. 현관문을 열고 집에 들어서는 순간, 묘한 허무함. 낯선 도시에서의 흥분, 새로운 음식, 예상치 못한 만남. 분명 특별한 시간이었는데, 돌아오니 방은 떠나기 전과 똑같고, 내일은 평소와 같은 하루가 기다리고 있다. "결국 돌아왔네." 이 한마디에 여행의 의미가 흐릿해지는 느낌.

프로젝트도 비슷하다. 몇 달간 몰두해서 무언가를 만들어내고, 출시하고, 반응을 확인하고 나면 — 다시 다음 프로젝트의 시작점에 서 있다. 이직도 마찬가지다. 새로운 환경에서 적응하고, 성과를 내고, 자리를 잡으면 — 그곳이 곧 새로운 일상이 된다. 어디를 가든, 무엇을 하든, 결국 어떤 형태로든 출발점과 닮은 자리로 돌아온다.

돌아온 여행에 의미가 없을까

"결국 제자리 아닌가?" 이렇게 느낄 수 있다. 돈과 시간을 들여 여행을 갔다 와도 일상은 그대로이고, 열정을 쏟아 프로젝트를 끝내도 다시 백지에서 시작해야 하고, 힘들게 이직해도 결국 비슷한 고민을 하게 된다면. 도착한 곳이 출발한 곳과 같다면, 그 여정에 무슨 의미가 있는 걸까.

이 질문에 답하려면, "같은 자리"라는 표현을 다시 생각해봐야 한다. 정말 같은 자리인가? 물리적으로는 그렇다. 같은 집, 같은 책상, 같은 모니터. 하지만 그 자리에 앉아 있는 사람은 같은 사람인가?

출발한 나와 돌아온 나는 다른 사람이다

여행을 다녀온 후 같은 동네를 걸으면, 이상하게 풍경이 다르게 보인다. 길은 그대로인데, 보이는 것이 달라져 있다. 이건 풍경이 변한 게 아니라 보는 사람이 변한 것이다. 새로운 도시에서의 경험이, 의식하지 못하는 사이에, 사물을 보는 필터를 바꿔놓는다.

프로젝트도 마찬가지다. 하나의 프로젝트를 끝내고 나서 다음 프로젝트를 시작하면, 같은 종류의 결정을 내려야 하는 상황에서도 판단이 달라진다. 이전에는 고민하던 것을 이번에는 바로 결정하고, 이전에는 몰랐던 위험을 이번에는 미리 감지한다. 같은 자리에 앉았지만, 같은 사람이 아니다.

문제는 이 변화를 당사자가 잘 느끼지 못한다는 것이다.

성장은 왜 보이지 않는가

매일 거울을 보는 사람은 자기 얼굴이 변하는 걸 모른다. 오랜만에 만난 친구가 "너 살쪘다"고 말해줘야 비로소 인식한다. 성장도 마찬가지다. 매일 조금씩 달라지기 때문에, 당사자는 자신이 성장했다는 사실을 체감하지 못한다.

어제의 나와 오늘의 나를 비교하면, 차이를 발견하기 어렵다. 작은 판단 하나, 미세한 관점의 변화, 약간 더 빨라진 결정 속도. 이런 것들은 하루 단위로는 보이지 않는다. 하지만 6개월 전의 나와 지금의 나를 비교하면, 차이가 분명해진다. 성장을 인식하려면 충분한 시간적 거리가 필요하고, 그 거리를 만들어주는 것이 바로 "시작점으로의 귀환"이다.

시작점이 거울이 된다

원래 자리로 돌아왔을 때, 그 자리는 거울이 된다. 과거의 내가 서 있던 자리에 지금의 내가 다시 서면, 비로소 비교가 가능해진다. "예전에는 이걸 어떻게 했더라?" 하고 떠올렸을 때, 지금의 내가 그때와 다르게 생각하고 있다는 걸 발견한다. 그 발견의 순간이 성장의 인식이다.

여행에서 돌아와 같은 동네를 걸을 때 풍경이 다르게 보이는 이유가 이것이다. 시작점이 과거의 나를 비추는 거울이 되어, 변한 나를 보여주는 것이다. 만약 여행이 끝나지 않고 계속 새로운 곳만 간다면, 변화를 인식할 기준점이 없다. 돌아와야만 비교가 가능하고, 비교해야만 성장이 보인다.

두 번째로 같은 일을 할 때

이 원리가 가장 선명하게 드러나는 순간은, 같은 종류의 일을 두 번째 할 때다.

처음 팀을 빌딩할 때는 모든 것이 막막하다. 누구를 뽑아야 하는지, 어떤 역할이 필요한지, 언제 사람을 늘려야 하는지. 시행착오를 겪으며 어찌저찌 팀을 만든다. 그리고 두 번째로 팀을 빌딩할 때, 자신이 얼마나 달라졌는지를 알게 된다. 이전에는 고민하던 결정을 이번에는 확신을 가지고 내린다. 이전에는 미처 몰랐던 실수를 이번에는 미리 피한다.

이건 "경험이 쌓여서"라는 한 문장으로 설명할 수 있다. 하지만 중요한 건, 그 성장을 인식하는 시점이 "두 번째로 같은 자리에 섰을 때"라는 것이다. 첫 번째 팀 빌딩이 끝난 직후에는 내가 뭘 배웠는지 잘 모른다. 두 번째 시작점에 서야 비로소, 첫 번째의 나와 지금의 나 사이의 거리가 보인다.

커리어도 원환이다

이직을 하고, 새 환경에 적응하고, 성과를 내고, 다시 다음을 고민하는 사이클. 창업을 하고, 실패하고, 다시 시작하는 사이클. 프로젝트를 기획하고, 실행하고, 마무리하고, 다시 기획하는 사이클. 커리어는 직선이 아니라 원환이다.

이걸 "제자리걸음"으로 볼 수도 있다. 하지만 정확히 같은 자리를 도는 원이 아니라, 조금씩 높아지는 나선이다. 같은 종류의 고민을 하지만 깊이가 다르고, 같은 종류의 결정을 내리지만 정확도가 다르고, 같은 종류의 실패를 하지만 회복 속도가 다르다. 나선은 위에서 보면 원처럼 보인다. 하지만 옆에서 보면 분명히 올라가고 있다.

왜 모든 여행은 집으로 돌아오는가

여행의 의의는 도착지에 있지 않다. 가는 동안 겪는 것들, 보는 것들, 느끼는 것들이 여행의 본질이다. 그리고 그 본질을 비로소 인식하게 되는 순간은, 집에 돌아왔을 때다. 떠나기 전의 나와 돌아온 뒤의 나를 비교할 수 있는 유일한 장소가 시작점이기 때문이다.

그래서 모든 좋은 이야기는 시작점으로 돌아간다. 신화 속 영웅이 모험을 마치고 마을로 돌아오는 것도, 긴 프로젝트를 끝내고 다시 백지 앞에 서는 것도, 같은 이유다. 돌아옴은 끝이 아니라, 성장을 자각하는 시작이다.

결국 집으로 돌아왔다고 느끼는 그 순간, 당신은 이미 떠나기 전의 당신이 아니다. 그걸 깨닫는 것이, 여행이 우리에게 주는 진짜 선물이다.

지루함을 설계하는 사람들

Fri, 13 Mar 2026 15:00:00 GMT

"하고 싶은데 지겹다"

좋아서 시작한 일인데 어느 순간 손이 안 간다. 재밌었던 프로젝트가 슬슬 루틴이 되고, 처음에는 설레던 출근길이 어느 날부터 무감각해진다. 능력이 부족한 것도 아니고, 흥미를 잃은 것도 아니다. 분명 좋아하는 일인데, 몸과 마음이 반응하지 않는다. "하고 싶은데 지겹다"는 모순적인 상태.

이건 의지의 문제가 아니다. 뇌가 원래 그렇게 작동한다. 같은 자극이 반복되면 반응이 줄어드는 건 결함이 아니라 설계다. 문제는 이 설계를 무시하고 의지력으로 버티려 할 때 생긴다.

익숙해지면 반응이 줄어든다

처음 먹는 음식은 맛이 강렬하다. 하지만 같은 음식을 매일 먹으면, 어느 순간부터 맛을 잘 못 느끼게 된다. 음식이 변한 게 아니라 혀가 적응한 것이다. 뇌도 마찬가지다. 동일한 자극이 반복되면, 뇌는 그것을 "이미 아는 것"으로 분류하고 반응의 강도를 낮춘다. 에너지를 아끼기 위한 합리적인 전략이다.

이건 일에서도 똑같이 일어난다. 새로운 기능을 처음 만들 때의 흥분, 첫 고객을 만났을 때의 떨림, 팀에 합류한 직후의 긴장감. 시간이 지나면 이 모든 것이 무뎌진다. 능숙해진다고도 할 수 있지만, 뒤집으면 둔감해진다는 뜻이기도 하다. 역량은 반복에서 오지만, 동력도 반복 속에서 사라진다. 이 역설이 모든 프로덕트, 모든 조직, 모든 커리어에서 반복된다.

예상이 빗나가는 순간

그렇다면 둔감해진 뇌를 다시 깨우는 건 뭘까. 답은 의외로 단순하다. 예상이 빗나가면 된다.

사람의 뇌는 끊임없이 다음에 무슨 일이 일어날지 예측한다. 출근하면 슬랙에 메시지가 쌓여 있을 거고, 스탠드업 미팅에서는 어제와 비슷한 이야기가 나올 거고, 오후에는 코드 리뷰를 할 것이다. 이 예측이 맞을수록 뇌는 에너지를 절약하고, 동시에 무감각해진다. 그런데 갑자기 예측이 깨지면 — 예상하지 못한 피드백이 오거나, 전혀 다른 방향의 제안이 나오거나, 당연하다고 생각한 전제가 뒤집히면 — 뇌는 다시 깨어난다. "어? 이건 뭐지?" 이 한 순간의 각성이 쌓인 무감각을 리셋한다.

놀라움의 본질은 화려함이 아니다. 예상과 현실 사이의 간극이다. 그 간극이 클수록, 리셋도 강력하다.

놀라움에는 타이밍이 있다

그렇다고 아무 때나 예상을 깨버리면 되는 건 아니다. 충분히 익숙해지기 전에 놀라움을 주면, 그건 놀라움이 아니라 혼란이다. 기본 규칙도 모르는 상태에서 규칙이 뒤집히면, 사람은 "재밌다"가 아니라 "모르겠다"고 느낀다.

놀라움이 작동하려면, 먼저 "이건 이런 거구나"라는 확신이 생겨야 한다. 반복을 통해 패턴을 익히고, 다음을 예측할 수 있다는 자신감이 쌓인 상태에서, 그 예측이 빗나가야 효과가 있다. 다시 말해, 지루함이 먼저 있어야 놀라움이 빛난다. 지루함 없는 놀라움은 소음이고, 놀라움 없는 지루함은 이탈이다. 둘은 따로 존재할 수 없다.

프로덕트의 리듬

이걸 프로덕트에 적용하면 명확해진다. 온보딩은 반복의 영역이다. 사용자가 서비스의 규칙을 배우고, 핵심 동작을 익히고, "이건 이렇게 쓰는 거구나"라는 감각을 형성하는 단계. 이 단계에서 중요한 건 일관성이다. 예측 가능한 경험이 반복되어야 사용자는 안심하고 배운다.

문제는 그 다음이다. 온보딩이 끝나고 사용자가 서비스에 익숙해지면, 반복은 리텐션의 적이 된다. 매일 같은 화면, 같은 기능, 같은 흐름. 뇌가 "이미 아는 것"으로 분류하는 순간, 서비스를 열 이유가 사라진다. 이 시점에 필요한 것이 예상 밖의 경험이다. 새로운 기능의 발견, 예상치 못한 추천, 기존 흐름을 깨는 이벤트. 이것들이 사용자의 뇌를 다시 깨운다.

좋은 프로덕트는 이 두 가지를 교차시킨다. 반복으로 신뢰를 쌓고, 적절한 놀라움으로 신선함을 유지하는 리듬. 한쪽에만 치우치면 실패한다.

조직에도 리듬이 필요하다

프로덕트만 그런 것이 아니다. 조직도 같은 리듬으로 돌아간다.

스프린트, 데일리 스탠드업, 주간 회의, 월간 리뷰. 이런 루틴은 조직의 반복 학습이다. 예측 가능한 리듬 속에서 구성원은 자기 역할을 익히고, 팀의 작동 방식을 체화한다. 이 루틴이 없으면 조직은 혼란스럽다. 하지만 루틴만 있으면 조직은 지루하다.

그래서 좋은 조직에는 루틴을 깨는 순간이 설계되어 있다. 오프사이트, 해커톤, 역할 교체, 전혀 다른 프로젝트에 잠시 참여하기. 이런 것들이 쌓인 무감각을 리셋한다. 중요한 건, 이것들이 자연발생하는 게 아니라 의도적으로 배치된다는 점이다. 좋은 리더는 팀이 언제 지루해지는지를 감지하고, 그 시점에 맞춰 리듬을 깨는 경험을 넣을 줄 안다.

지루함을 견디게 하는 건 다음 놀라움에 대한 기대다

반복이 고통스러워도 버틸 수 있는 이유가 있다. "조금만 더 하면 뭔가 다른 일이 일어날 것이다"라는 기대. 이 기대는 근거 없는 낙관이 아니라, 과거에 실제로 놀라움을 경험한 기억에서 온다. 이전에도 지루한 시기를 지나면 새로운 국면이 열렸으니까, 이번에도 그럴 거라는 신뢰.

리듬이 신뢰를 만든다. "반복 → 놀라움 → 반복 → 놀라움"이라는 패턴을 몇 번 겪으면, 반복의 시기에도 "곧 뭔가 올 것이다"라는 감각이 생긴다. 이 감각이 있으면 지루함은 고통이 아니라 축적이 된다. 다음 단계를 위해 힘을 모으는 시간. 반대로 이 리듬이 없는 조직, 놀라움 없이 반복만 계속되는 조직에서는 사람이 버티지 못한다. 이탈의 원인은 대부분 과로가 아니라 무감각이다.

지루함을 설계하는 사람들

제품을 만드는 사람이라면 누구든 이 리듬을 다루게 된다. 기획자는 기능의 배치 순서를, 개발자는 사용자가 마주할 흐름의 완급을, 리더는 팀이 반복과 변화를 오가는 주기를 설계한다. 역할은 다르지만 본질은 같다. "언제 지루하게 할 것인가"를 아는 것.

이건 직관적이지 않은 능력이다. 보통은 지루함을 문제로 보고, 그걸 없애려고 한다. 하지만 지루함을 없애면 역량도 같이 사라진다. 반복 없이는 숙련이 없고, 숙련 없이는 놀라움도 작동하지 않는다. 지루함은 버그가 아니라, 다음 단계를 위한 토양이다.

결국 좋은 제품을 만드는 사람들이 하는 일은 단순하다. 지루함과 놀라움 사이에 리듬을 만드는 것. 그리고 그 리듬을 통해, 사람들이 지치지 않고 계속 앞으로 나아갈 수 있게 하는 것이다.

성장은 불편한 동행자에서 시작된다

Fri, 13 Mar 2026 09:00:00 GMT

"그 사람만 아니었으면"

팀에 유독 한 사람이 있다. 회의 때마다 날카로운 질문을 던지고, 내가 괜찮다고 생각한 것에 의문을 제기하고, 분위기를 읽지 못하는 것 같은 발언을 한다. 점심시간에 그 사람 이야기가 나오면 다들 한숨을 쉰다. "그 사람만 아니었으면 일이 훨씬 수월할 텐데."

한번쯤은 이런 생각을 해본 적이 있을 것이다. 나도 그랬다. 그리고 흥미롭게도, 나중에 돌아보면 그 사람이 있던 시기에 가장 많이 성장해 있었다. 편하게 일했던 시기에는 별로 남는 게 없었는데, 불편했던 시기에는 뭔가 단단해져 있었다. 우연이라고 치부하기엔 너무 자주 반복되는 패턴이다.

편한 관계에서는 아무 일도 일어나지 않는다

좋은 팀을 생각하면 보통 이런 그림이 떠오른다. 서로 잘 통하고, 갈등 없이 매끄럽게 돌아가고, 회의에서 금방 합의가 이루어지는 팀. 실제로 그런 팀에서 일하면 정말 편하다. 스트레스가 적고, 일상이 예측 가능하고, 퇴근 후에도 마음이 가볍다.

문제는 그 편안함 속에서 아무것도 바뀌지 않는다는 것이다. 내 생각은 한 번도 도전받지 않고, 내 방식은 한 번도 의심받지 않고, 내 기준은 한 번도 흔들리지 않는다. 그건 조화가 아니라 정체다. 근육은 저항이 있어야 자란다. 아무런 부하도 없는 운동은 운동이 아니다. 팀에서의 불편함도 마찬가지다. 나와 다른 관점이 부딪혀야 내 관점이 날카로워진다.

불편함이 감정의 방향을 바꾼다

불편한 사람과 일하면 처음에는 짜증만 쌓인다. "왜 저렇게밖에 생각을 못 하지?" "왜 매번 반대만 하지?" 감정의 화살이 전부 상대를 향한다. 나는 관찰자이고, 상대는 문제의 원인이다. 이 구도에서는 공감이 생길 여지가 없다.

그런데 시간이 지나면서 미묘한 변화가 생긴다. 상대가 왜 그렇게 행동하는지 조금씩 이해되기 시작한다. 처음에는 "왜 반대만 하지?"였던 것이, "아, 이 사람은 이런 기준으로 판단하는구나"로 바뀐다. 감정의 방향이 바깥에서 안으로 전환되는 순간이다. 상대를 판단하던 시선이 상대를 이해하려는 시선으로 바뀌는 것. 이 전환이 일어나려면 시간이 필요하고, 불편함을 견디는 과정이 필요하다. 편한 관계에서는 이 전환이 일어날 이유 자체가 없다.

같이 넘어져야 비로소 보이는 것

불편한 사람에 대한 감정이 가장 극적으로 뒤집히는 순간은, 함께 위기를 겪을 때다. 프로젝트가 무너지기 직전, 장애가 터져서 밤을 새야 할 때, 예상치 못한 문제로 모두가 막막할 때. 그 순간에 평소 불편했던 사람이 묵묵히 자기 몫을 해내는 걸 보면, 감정의 지형이 완전히 달라진다.

"이 사람, 생각보다 괜찮은 사람이었구나." 이건 머리가 아니라 몸으로 느끼는 깨달음이다. 평소에 아무리 "그래도 나쁜 사람은 아니지"라고 되뇌어봐야 감정은 바뀌지 않는다. 직접 같이 넘어지고, 같이 일어서는 경험을 해야 한다. 위기는 잔인하지만, 사람의 본질을 드러낸다. 그리고 그 본질을 함께 목격한 관계는 이전과 같을 수 없다.

좋은 불편함과 나쁜 불편함

물론 모든 불편함이 성장으로 이어지는 건 아니다. 인격을 무시하는 불편함, 권력을 이용한 불편함, 악의가 담긴 불편함은 사람을 성장시키지 않고 파괴한다. 좋은 불편함과 나쁜 불편함을 가르는 기준은 하나다. 신뢰가 있느냐 없느냐.

신뢰가 있는 관계에서의 불편함은 건설적이다. "이 사람이 날 공격하려는 게 아니라, 더 나은 결과를 원하는 거다"라는 전제가 깔려 있기 때문이다. 반대로 신뢰가 없는 관계에서의 불편함은 파괴적이다. 상대의 모든 행동이 위협으로 해석되고, 방어만 하다 지치게 된다. 건설적 갈등은 문제에 초점이 있고, 파괴적 갈등은 사람에 초점이 있다. 같은 수준의 불편함이라도, 어디를 향하느냐에 따라 결과는 정반대다.

싫은 사람을 좋아할 필요는 없다

여기서 흔한 오해를 짚고 넘어가자. "불편한 사람에게서 배운다"는 말이 "싫은 사람을 좋아해야 한다"는 뜻은 아니다. 좋아하는 것과 공감하는 것은 완전히 다른 일이다. 좋아함은 감정이고, 공감은 이해다. 싫은 사람을 억지로 좋아하려고 하면 자기기만이 된다. 하지만 싫은 사람의 관점을 이해하려고 하면, 내 세계가 넓어진다.

솔직히 말하면, 나도 잘 못한다. 싫은 사람을 이해하려는 노력은 생각보다 에너지가 많이 든다. 하지만 그 에너지를 쓸 때마다 내 판단의 범위가 조금씩 넓어지는 건 분명히 느낀다. 한 가지 관점으로만 세상을 보던 시야가, 두 가지, 세 가지로 늘어나는 경험. 그건 편한 사람들과는 절대 만들 수 없는 경험이다.

내가 누군가의 불편한 동행자일 수 있다

지금까지 "불편한 사람"을 항상 상대방으로 놓고 이야기했다. 하지만 시점을 뒤집어 보면, 나 역시 누군가에게 그런 존재일 수 있다. 아니, 거의 확실히 그렇다.

내가 던지는 질문이 누군가에게는 짜증스러운 반박으로 들릴 수 있다. 내가 당연하다고 생각하는 기준이 누군가에게는 불합리한 잣대일 수 있다. 내가 효율적이라고 믿는 방식이 누군가에게는 차갑게 느껴질 수 있다. 이 사실을 인정하면, 상대의 불편함을 대하는 태도가 달라진다. "저 사람은 왜 저래?"에서 "나도 저런 존재일 수 있겠구나"로.

성장은 불편한 동행자에서 시작된다

편한 사람들과 함께하면 일상은 좋아진다. 하지만 일상이 좋아지는 것과 내가 성장하는 것은 다른 문제다. 성장은 대부분 불편한 곳에서 시작된다. 내 생각이 도전받는 순간, 내 방식이 의문시되는 순간, 내가 틀렸을 수도 있다는 가능성을 받아들여야 하는 순간.

그 순간을 만들어주는 건 책이나 강연이 아니라, 바로 옆에서 나를 불편하게 만드는 사람이다. 그 사람이 나를 위해 그러는 건 아닐 수도 있다. 그저 자기 방식대로 살고 있을 뿐일 수도 있다. 하지만 그 존재 자체가, 의도와 무관하게, 내게 성장의 기회를 만든다.

지금 당신을 가장 불편하게 하는 사람이 있다면, 그 사람이 어쩌면 지금 당신에게 가장 필요한 사람일 수 있다.

실행의 시대에 질문이 사라진다

Thu, 12 Mar 2026 18:00:00 GMT

"어떻게"가 먼저 떠오르는 이유

무언가를 시작하려 할 때, 대부분의 사람은 "어떻게"부터 고민한다. 어떤 도구를 쓸까, 어떤 기술을 배워야 할까, 어떤 순서로 진행할까. 자연스러운 반응이다. "어떻게"는 눈에 보이고, 측정할 수 있고, 착수하는 즉시 뭔가 하고 있다는 감각을 준다.

요리를 배우려는 사람이 "무엇을 만들까"를 고민하기도 전에 칼부터 고르는 것과 비슷하다. 좋은 칼을 사면 요리를 잘하게 될 것 같은 느낌이 든다. 하지만 칼이 아무리 좋아도, 무엇을 만들지 모르면 도마 위에는 아무것도 올라가지 않는다.

"어떻게"는 안전하다. 정답에 가까운 것이 있고, 비교할 대상이 있고, 잘하고 있는지 확인할 수 있다. 반면 "무엇을"은 불안하다. 정답이 없고, 비교할 것도 마땅치 않고, 잘 골랐는지는 한참 뒤에야 알 수 있다.

그래서 우리는 본능적으로 "어떻게"에 먼저 손을 뻗는다.

지도 없는 노

"무엇을 할 것인가"라는 질문 없이 시작된 실행은 표류한다. 방향 없이 노를 젓는 사람은 지치기만 할 뿐, 어디에도 도착하지 못한다. 더 세게 젓는다고 해결되지 않는다. 노 젓는 기술을 개선해도 달라지지 않는다. 문제는 노가 아니라 나침반이다.

열심히 한 것과 잘한 것은 다르다. 편의상 "어떻게"는 How, "무엇을"은 What이라 부르자. 열심히 했다는 건 How에 충실했다는 뜻이고, 잘했다는 건 What이 맞았다는 뜻이다. 6개월을 밤새워 만든 것이 아무도 원하지 않는 것이라면, 그 6개월은 열심히 한 시간이지 잘 쓴 시간이 아니다.

냉정하지만, 시장은 노력에 점수를 주지 않는다. 방향이 맞았을 때에만 노력이 빛난다.

실행의 비용이 사라지는 시대

한때는 실행 자체가 경쟁력이었다. 만들 수 있다는 것 자체가 희소한 능력이었고, "어떻게"를 아는 사람이 곧 가치 있는 사람이었다.

그 시대가 끝나가고 있다. 실행의 비용이 급격히 줄어들고 있다. 예전에는 한 달이 걸리던 일이 며칠이면 되고, 전문가 열 명이 필요하던 일을 한 사람이 할 수 있게 되었다. 만드는 것 자체는 점점 쉬워지고 있다.

누구나 만들 수 있는 시대가 되면, "만들 수 있다"는 것은 더 이상 차별화가 아니다. 같은 도구, 같은 기술, 같은 시간이 주어졌을 때, 결과의 차이를 만드는 건 실행의 속도가 아니라 질문의 깊이다.

What은 왜 어려운가

What은 데이터가 없는 상태에서 내려야 하는 판단이다. 참고할 전례가 없고, 검증할 방법이 마땅치 않다. 정답이 없을 뿐 아니라, 정답이 있었는지조차 한참 뒤에야 알 수 있다.

How의 세계는 피드백이 즉각적이다. 코드를 작성하면 작동하거나 오류가 나고, 디자인을 바꾸면 반응이 오고, 프로세스를 개선하면 수치가 움직인다. 이 즉각적인 피드백이 중독성 있다. 뭔가 하고 있다는 감각, 전진하고 있다는 감각.

반면 What의 피드백은 몇 달, 몇 년 뒤에야 온다. 내가 고른 방향이 맞았는지, 내가 정의한 문제가 진짜 문제였는지, 그건 시간이 지나야만 알 수 있다. 그 불확실한 시간 동안 확신 없이 걸어가야 한다.

그래서 많은 사람이 What을 회피하고 How로 도피한다. How는 바쁘게 해주지만, What은 불안하게 하니까.

질문하는 근육

"무엇을 할 것인가"를 묻는 것은 타고나는 능력이 아니다. 훈련이 필요한 근육이다.

이 근육은 실행을 반복할 때 자란다. 무언가를 만들고, 내놓고, 반응을 보고, 틀렸음을 인정하고, 다시 묻는 사이클을 돌릴 때. 한 번의 실행으로 직관이 생기지는 않는다. 수십 번, 수백 번 돌려야 비로소 "이건 될 것 같다"는 감각이 형성된다.

흥미로운 점은, How를 빨리 돌리는 것이 결국 What의 정확도를 높인다는 것이다. 빨리 만들고, 곧바로 검증하고, 즉시 수정하는 사이클이 반복될수록, "무엇이 맞는가"에 대한 감각이 정교해진다. 실행이 빨라지면 질문도 날카로워진다.

여기서 모순처럼 보이는 것이 있다. 앞에서 How보다 What이 중요하다고 했는데, 좋은 What을 얻으려면 결국 How를 많이 돌려야 한다면, How도 중요한 것 아닌가. 맞다. 다만 How의 목적이 달라져야 한다. 과거에는 How 자체가 가치였다. 만들 수 있다는 것이 곧 경쟁력이었다. 하지만 지금의 How는 What을 발견하기 위한 탐색 도구다. 실행의 목적이 "완성"에서 "탐색"으로 바뀌는 것이다.

실행 비용이 줄어든 시대에, 이 전환은 더 중요해진다. 한 번의 실행이 가볍기 때문에, 더 많이, 더 빠르게 돌릴 수 있다. 그리고 그 빠른 사이클 하나하나가 What을 향한 탐색이 될 때, 실행은 비로소 방향을 갖는다.

결국 좋은 질문을 하는 사람은, 많이 실행해 본 사람이다. 책상 위에서 What만 고민한다고 좋은 What이 나오지 않는다. 손을 움직여야 눈이 뜬다.

씨앗을 심었는데 다른 꽃이 핀다

What을 정했다고 해서 끝이 아니다. 내가 심은 씨앗에서 예상한 꽃이 피지 않는 경우가 더 많다. 전혀 다른 방향에서 가치가 발견되고, 내가 의도하지 않은 방식으로 사람들이 반응한다.

이건 실패가 아니다. What의 본질이 원래 그렇다. "무엇을 할 것인가"는 한 번의 선택으로 완결되는 것이 아니라, 시장과 사람이 끊임없이 재정의하는 것이다. 내가 던진 질문에 세상이 다른 답을 돌려줄 때, 그 답을 읽어내는 것도 What의 일부다.

그래서 What은 결정이 아니라 관찰이다. 한 번 정하고 끝내는 것이 아니라, 정한 뒤에도 계속 바라보고 수정하고 다시 묻는 것이다. 씨앗을 심되, 어떤 꽃이 피는지 지켜볼 줄 아는 눈이 필요하다.

실행의 시대에 질문이 사라진다

How가 중요하지 않다는 것이 아니다. How 없이는 아무것도 세상에 나오지 않는다. 다만, How의 가치는 What이 정해진 뒤에 빛난다. 방향이 맞을 때, 실행력은 비로소 날개가 된다.

문제는 실행이 쉬워질수록, 정작 "무엇을"이라는 질문이 뒷전으로 밀린다는 것이다. 만들 수 있으니까 일단 만들고, 할 수 있으니까 일단 하고, 빠르니까 일단 시작한다. 그러다 보면 노는 점점 빨라지는데, 여전히 지도가 없다.

실행의 속도가 빨라진 만큼, 질문의 깊이도 따라가야 한다. 아니, 따라가는 정도가 아니라 앞서야 한다. 질문이 실행보다 먼저 달려야 한다.

지금 우리에게 부족한 건 더 나은 도구가 아니다. 더 나은 질문이다.

직관이 만들어지는 구조

Wed, 11 Mar 2026 09:00:00 GMT

"그냥 느낌이 그래서"

"그냥 느낌이 그래서." 어떤 결정의 이유를 물었을 때, 이 말만큼 강력하면서도 설명 불가능한 대답이 있을까. 나도 종종 이런 식으로 판단을 내린다. 채용 면접에서 지원자의 이력은 훌륭한데 어딘가 찜찜한 느낌이 들 때, 제품의 방향을 두 가지 중 하나로 골라야 할 때, 혹은 처음 가본 식당에서 메뉴판을 3초 만에 훑고 주문을 결정할 때.

흥미로운 건, 이 "느낌"이 생각보다 자주 맞는다는 것이다. 아니, 정확히 말하면 맞았던 기억만 선명하게 남는 것일 수도 있다. 하지만 분명한 건, 직관이 잘 작동하는 사람과 그렇지 않은 사람이 있다는 것이다. 그리고 그 차이는 타고난 재능이 아니라, 구조에 있다고 생각한다.

최근 체험 디자인에 관한 책을 읽다가 직감이 어떻게 만들어지는지에 대한 흥미로운 관점을 발견했다. 게임 디자인을 분석한 책이었는데, 거기서 말하는 직감의 구조가 일과 삶에도 그대로 적용된다는 걸 깨달았다. 직감은 하늘에서 뚝 떨어지는 것이 아니라, 정교하게 설계되고 축적되는 것이었다.

뇌는 늘 다음을 상상한다

우리 뇌에는 재미있는 성질이 하나 있다. 뭔가를 보면 자동으로 "이걸 해볼까?"라는 가설을 세우고 싶어 한다는 것이다. 용도를 알 수 없는 기계를 봐도, 핸들 같은 게 보이면 "돌려볼까?", 버튼이 보이면 "눌러볼까?" 하는 생각이 저절로 든다. 아무도 "이 기계의 사용법에 대해 생각해보라"고 말한 적이 없는데도.

심리학에서는 이걸 어포던스(affordance)라고 부른다. 환경이 우리에게 부여하는 행동 가능성. 거창하게 들리지만, 쉽게 말하면 문 손잡이를 보면 자연스럽게 "잡아서 당겨볼까?"라는 생각이 드는 것이다. 의자를 보면 앉고 싶어지고, 계단을 보면 올라가고 싶어진다.

이걸 일하는 맥락으로 가져오면, 좋은 제품은 사용자가 "이걸 눌러볼까?"라는 가설을 자연스럽게 세울 수 있도록 만들어진 제품이다. 반대로, 설명서를 읽어야만 쓸 수 있는 제품은 어포던스가 부재한 제품이다. 그리고 이건 제품에만 적용되는 게 아니다. 좋은 조직도 구성원이 "이렇게 해볼까?"라는 가설을 자유롭게 세울 수 있는 환경을 만든다. 누군가 시키지 않아도, 자발적으로 다음 행동을 상상하게 되는 곳. 그게 어포던스가 살아있는 조직이다.

감이 만들어지는 세 단계

직감이 작동하는 구조를 뜯어보면, 세 단계로 나뉜다.

첫째, 가설이다. "이렇게 하면 되지 않을까?"라는 추측을 세운다. 이건 의식적으로 하는 분석이 아니라, 경험과 환경이 결합해서 자동으로 떠오르는 것이다. 둘째, 시행이다. 가설을 실제로 실행에 옮긴다. "한번 해보자"라는 마음으로 행동한다. 셋째, 환희다. 가설이 맞았을 때 느끼는 기쁨이다. "역시 내 생각이 맞았어!"라는 순간.

이 세 단계가 중요한 이유는, 단순히 한 번의 판단으로 끝나지 않기 때문이다. 가설을 세우고, 시행하고, 맞았을 때 기뻐하는 사이클이 반복되면서 비로소 "감"이라는 것이 형성된다. 한 번의 성공은 우연이지만, 이 사이클을 수십 번, 수백 번 반복하면 패턴이 된다. 그리고 그 패턴이 체화되면, 우리는 그것을 직관이라고 부른다.

스타트업을 하면서 느끼는 것도 비슷하다. 처음에는 모든 의사결정이 막막하다. 하지만 가설을 세우고 실행하고, 맞거나 틀린 결과를 반복적으로 경험하다 보면, 어느 순간 비슷한 상황에서 "이건 이렇게 해야 해"라는 감각이 생긴다. 그 감각의 정체가 바로 이 사이클의 축적이다.

가설은 어디서 오는가

그렇다면 가설은 어디서 오는가. 허공에서 "이렇게 해볼까?"라는 생각이 갑자기 떠오르는 건 아니다. 가설의 방향을 결정하는 건 환경이 보내는 신호, 즉 시그니파이어(signifier)다.

시그니파이어는 어포던스를 전달하기 위해 설계된 단서다. 슈퍼 마리오에서 마리오의 모습, 위치, 주변의 산과 풀이 모두 시그니파이어다. 이 단서들이 "오른쪽으로 가봐야 할 것 같다"는 가설을 플레이어의 머릿속에 심는다. 아무도 "오른쪽으로 가세요"라고 말하지 않았는데, 화면의 모든 요소가 그 방향을 가리키고 있는 것이다.

이걸 일에 적용하면, 좋은 리더는 시그니파이어를 잘 설계하는 사람이다. 팀원에게 "이걸 해"라고 지시하는 게 아니라, 팀원이 자발적으로 "이렇게 해볼까?"라는 가설을 세울 수 있도록 맥락과 정보를 배치하는 것이다. 명확한 목표, 적절한 권한, 그리고 충분한 맥락. 이 세 가지가 갖춰지면 팀원의 직감은 자연스럽게 올바른 방향을 향한다. 반대로, 모든 걸 지시하는 조직에서는 구성원의 직감이 퇴화한다. 가설을 세울 기회 자체가 없으니까.

처음이 모든 것을 결정한다

직감의 구성요소 중 하나가 초두효과다. 무언가를 처음 접했을 때, 우리의 집중력과 학습 효율은 가장 높다. 그리고 그 처음의 경험이 이후의 모든 판단에 기준점이 된다.

슈퍼 마리오가 첫 스테이지에 모든 핵심 아이템을 집중시킨 이유도 이것이다. 플레이어의 집중력이 가장 높은 순간에 게임의 규칙을 학습시키면, 이후에는 그 규칙이 직감처럼 작동한다. 불합리해 보이지만, 가장 약한 적인 굼바(쿠리보)가 가장 중요한 적인 이유이기도 하다. 집중력이 높은 초반에 등장하기 때문에, 플레이어의 기억에 가장 깊이 각인된다.

제품을 만들면서도 이 원리를 체감한다. 사용자가 서비스에 처음 들어왔을 때의 경험이 이후 모든 판단의 기준이 된다. 온보딩에서 "이건 쓸 만한 서비스다"라는 직감이 형성되면, 이후 작은 불편함은 넘어간다. 반대로, 첫 경험에서 혼란을 겪으면 아무리 좋은 기능이 뒤에 있어도 사용자의 직감은 "이건 아니다"라고 말한다. 처음이 전부를 결정하는 건 아니지만, 처음이 직감의 방향을 결정하는 건 분명하다.

같은 말이 다르게 들리는 이유

같은 정보를 받아도, 그걸 어떤 마음 상태에서 받느냐에 따라 해석이 완전히 달라진다. 게임에서 오른쪽으로 가는 것이 맞다는 사실을 발견했을 때, 플레이어가 느끼는 기쁨은 단순히 "정답을 알았다"는 것에서 오지 않는다. 가설을 세우고, 불안한 가운데 실행하고, 그 과정에서 심리적 긴장이 쌓였기 때문에 비로소 환희가 크다.

이걸 "마음의 문맥"이라고 부를 수 있다. 직감은 정보 자체가 아니라, 그 정보를 받아들이는 시점의 심리적 맥락에 의존한다. 같은 피드백이라도, 고민 끝에 듣는 피드백과 아무 맥락 없이 듣는 피드백은 흡수되는 깊이가 다르다. 스스로 충분히 고민한 뒤에 받은 조언은 직감의 일부가 되지만, 고민 없이 받은 조언은 그냥 정보로 흘러간다.

조직에서도 마찬가지다. 팀원이 스스로 충분히 고민할 시간을 준 뒤에 방향을 제시하면, 그건 직감의 재료가 된다. 하지만 고민할 틈도 없이 답을 던져주면, 그건 시키는 일이 될 뿐이다. 마음의 문맥을 만들어주는 것, 그게 직감을 키우는 환경의 핵심이다.

직감이 자라는 세 가지 조건

직감이 잘 작동하려면 세 가지 조건이 필요하다.

첫째, 충분히 긴 시간을 직감으로 채워야 한다. 어떤 일을 시작하고 "재밌다"거나 "감이 온다"고 느끼기까지는 시간이 걸린다. 빠르면 몇 분, 늦으면 몇십 분. 그 시간 동안 끊임없이 작은 가설과 시행의 사이클을 돌려야 한다. 중간에 그 흐름이 끊기면 직감은 리셋된다.

둘째, 하나하나의 사이클은 짧게 완결되어야 한다. 가설을 세웠는데 검증까지 한 달이 걸린다면, 그 사이에 불안과 지루함이 직감을 잠식한다. 작은 가설을 빠르게 세우고, 빠르게 확인하고, 결과를 바로 체감하는 것. 이 속도감이 직감을 선명하게 만든다.

셋째, 가설이 맞을 확률이 어느 정도 보장되어야 한다. 세운 가설이 매번 틀리면, 사람은 가설 세우기를 그만둔다. 적절한 난이도, 적절한 성공률이 있어야 "다음에도 해봐야지"라는 동기가 유지된다. 이건 게임뿐 아니라 일에서도 마찬가지다. 너무 어려운 과제만 주어지는 환경에서는 직감이 위축된다. 적절한 성공 경험이 쌓여야 직감이 자라난다.

나도 모르게 손이 먼저 움직일 때

직감이 완전히 체화되면, "나도 모르게" 작동한다. 의식적으로 분석하지 않아도 손이 먼저 움직이고, 머리가 먼저 답을 내놓는다.

이 "나도 모르게"야말로 직감의 가장 큰 힘이다. 체험 디자인에서도 최고의 디자인은 사용자가 "나도 모르게" 무언가를 하고 싶어지게 만드는 것이라고 말한다. 지시하지 않았는데 하고 싶어지고, 설명하지 않았는데 이해하게 되고, 강요하지 않았는데 몰입하게 되는 것.

돌이켜보면, 내가 가장 좋은 결정을 내렸던 순간들은 대부분 논리적 분석보다 직감이 먼저였다. 물론 그 직감은 하늘에서 온 게 아니라, 비슷한 상황을 여러 번 겪으면서 무의식에 축적된 패턴이었다. 중요한 건, 그 패턴이 축적되기까지의 과정에 가설과 시행과 환희가 있었다는 것이다.

설명할 수 없는 것이 아니라, 압축된 것이다

직감은 타고나는 것이 아니라 구조적으로 만들어진다. 어포던스가 가설을 유도하고, 시그니파이어가 방향을 잡아주고, 가설→시행→환희의 사이클이 반복되면서 패턴이 쌓인다. 초두효과가 첫 번째 기준점을 세우고, 마음의 문맥이 경험의 깊이를 결정한다.

결국 직감을 키운다는 건, 좋은 가설을 많이 세워보고, 빠르게 시행해보고, 맞았을 때의 기쁨을 충분히 느끼는 것이다. 그리고 그 환경을 스스로 만들거나, 함께 일하는 사람들에게 만들어주는 것이다.

"그냥 느낌이 그래서"라는 말 뒤에는, 셀 수 없이 많은 가설과 시행과 실패와 환희가 쌓여 있다. 직감은 설명할 수 없는 것이 아니라, 설명하기엔 너무 많은 경험이 압축되어 있는 것이다.

기회의 모양은 시대마다 다르다

Tue, 10 Mar 2026 11:00:00 GMT

1.

부모님 세대에게 기회는 땅이었다.

안정된 직장에 다니며 월급을 모아 아파트를 샀다. 그 아파트 값이 올랐다. 집 한 채가 인생을 바꿨다. 단순한 전략이었지만, 그 시대에는 그게 통했다. 부동산 가격은 올랐고, 경제는 성장했고, 성실함은 보상받았다.

그 이야기를 들으며 자란 세대는 같은 전략을 시도했다. 하지만 문은 이미 닫혀 있었다.

2.

기회는 사라지는 게 아니라 모양이 바뀐다.

할아버지 세대에게는 전쟁 이후의 재건이 기회였다. 산업 기반이 만들어지는 시기, 뭐든 만들면 팔렸다. 제조업의 시대. 부모님 세대에게는 부동산과 안정된 직장이 기회였다. 경제 성장의 과실을 나눠 가질 수 있었던 시대.

그리고 지금. 세상은 아날로그에서 디지털로, 디지털에서 인공지능으로 재편되고 있다. 기회의 모양이 또 한 번 바뀌는 중이다.

3.

우리 세대에 기회가 없었느냐고 묻는다면, 그건 아니다.

비트코인이 몇만 원이던 시절이 있었다. 지금 돌이켜보면 누가 봐도 기회였다. 하지만 그때 그걸 기회라고 확신한 사람은 거의 없었다. 대부분은 의심했고, 무시했고, 혹은 존재조차 몰랐다. 나도 마찬가지였다.

기회는 늘 그런 것 같다. 지나고 나서야 비로소 기회의 형태를 갖춘다. 한가운데 서 있을 때는 그저 불확실한 선택지 중 하나일 뿐이다. 그래서 기회를 잡는다는 건, 확신이 있어서가 아니라 불확실함 속에서도 움직일 수 있었느냐의 문제인지도 모른다.

4.

개인 차원의 노력이 무의미하다는 뜻은 아니다.

하지만 노력보다 더 중요한 게 있다. 방향이다. 아무리 열심히 달려도, 사양길에 접어든 길 위에서는 속도가 의미 없다. 세상의 변화를 읽어서 유망한 방향을 찾는 것. 유망까지는 아니더라도 사양길에 접어들지 않을 직종과 업종을 고르는 것. 게다가 당신이 살아야 할 인생이니까 본인의 장단점을 살펴서 정해야 한다.

방향 감각. 그것이 이 시대에 노력만큼이나 중요한 능력이다.

5.

스마트폰이 촉발한 디지털 혁명은 전 산업 분야에서 디지털 트랜스포메이션을 가져왔다. 유통과 커머스가 먼저 변했고, 물류가 따라왔다. 완강하게 버티던 자동차, 의료, 법률 산업도 천천히 변하고 있다.

이 변화를 주도하는 건 대기업이 아니라 스타트업이다. 세상이 어수선하고 빠르게 변할 때, 작은 신생기업에 기회가 있다. 인간의 능력이 생산수단으로서 경쟁력을 잃어가는 자리를, 인공지능과 빅데이터, 그리고 디지털 기술이 채우고 있다.

6.

개발자로서 이 흐름을 바라보면, 묘한 감정이 든다.

우리가 만드는 기술이 세상을 바꾸고 있다는 자부심. 동시에, 그 기술이 우리 자신마저 대체할 수 있다는 불안. AI가 코드를 쓰고, 디자인을 하고, 글을 쓰는 시대. 개발자라는 직업의 모양도 바뀌고 있다.

하지만 기술 자체가 기회인 적은 없었다. 기술을 이해하고, 그것으로 문제를 해결하는 사람이 기회를 잡았다. 증기기관이 기회가 아니라, 증기기관으로 공장을 돌린 사람이 기회를 만든 것처럼.

7.

텔레비전에 나오는 성공 스토리를 보면서 삶의 방향을 정하지 말라는 말에 공감한다.

남의 성공은 남의 시대, 남의 맥락, 남의 운이 겹친 결과다. 똑같이 따라 한다고 같은 결과가 나오지 않는다. 중요한 건 지금 내가 서 있는 자리에서, 어떤 문이 열려 있는지를 직접 살피는 것이다.

부모님의 문은 부동산이었다. 우리의 문은 다른 곳에 있다. 어쩌면 아직 이름도 붙지 않은 영역에 있을지도 모른다.

8.

물론, 모두가 그 문을 찾아 나서야 하는 건 아니다.

좋은 회사에 다니며 적당한 시점에 적당한 집을 사고, 안정적으로 살아가는 삶. 그것도 하나의 선택이고, 나쁘지 않은 선택이다. 대기업이 주는 안정감에는 분명한 가치가 있다. 예측 가능한 내일이 주는 평온함.

다만, 그 이상의 무언가를 원한다면 이야기가 달라진다. 적당함의 천장은 생각보다 낮고, 그 천장을 뚫을 수 있는 도구는 많지 않다. 변화의 한가운데서 직접 무언가를 만들어보는 것. 스타트업이 유일한 답이라고 말하기는 어렵지만, 가장 현실적인 선택지에 가깝다는 건 부정하기 어렵다.

9.

2030이라면 스타트업에서 기회를 찾아야 한다, 라는 말을 그대로 믿을 필요는 없다. 하지만 한 가지는 분명하다. 기회는 변화가 일어나는 곳에 있다.

변화가 가장 빠른 곳. 기존 질서가 흔들리는 곳. 불편한 것이 아직 해결되지 않은 곳. 거기에 기회가 있다. 그리고 그 기회를 잡는 건, 변화를 두려워하지 않는 사람이다.

10.

기회의 모양은 시대마다 다르다. 그래서 이전 세대의 지도는 참고만 할 수 있을 뿐, 그대로 따라갈 수는 없다.

우리는 우리의 지도를 그려야 한다. 그 지도 위에는 AI가 있고, 디지털이 있고, 글로벌이 있다. 하지만 가장 중요한 건 지도 위의 점이 아니라, 그 점들을 연결하는 나만의 선이다.

노력은 기본이다. 방향은 선택이다. 그리고 그 선택을 내리려면, 세상이 어디로 흘러가고 있는지를 눈 부릅뜨고 봐야 한다. 텔레비전이 아니라, 직접.

같이 일한다는 것의 진짜 의미

Tue, 10 Mar 2026 10:00:00 GMT

1.

처음 함께 일하자고 말했던 날을 기억한다.

카페였다. 아메리카노 두 잔 사이에 노트북 하나를 놓고, 아직 이름도 없는 서비스의 구조를 그렸다. 그때는 몰랐다. 그 한마디가 단순한 제안이 아니라, 서로의 시간과 삶의 방향을 묶는 일이었다는 걸.

같이 일한다는 건 같은 공간에 앉는 것이 아니다. 같은 불확실성 안에 서는 것이다.

2.

초기 스타트업에서 회사의 가치를 만드는 건 기술도, 시장도, 자본도 아니다. 사람이다. 더 정확하게는, 함께 시작한 사람들이 만들어내는 관계의 밀도다.

존속가치라는 말이 있다. 회사가 계속 운영될 때의 가치. 그 반대편에는 청산가치가 있다. 문을 닫았을 때 남는 것. 초기에는 이 둘의 차이가 거의 없다. 자산도 없고, 매출도 없으니. 그 간극을 벌리는 건 오직 함께하는 사람들의 힘이다.

좋은 공동창업자가 있으면 존속가치가 청산가치를 압도한다. 이 사람들이 계속 함께한다면 뭔가 될 거라는 믿음. 투자자가 초기 팀에 투자하는 건 사업 모델이 아니라 그 믿음에 돈을 거는 것이다.

3.

하지만 함께 시작하는 것과 끝까지 함께 가는 것은 전혀 다른 이야기다.

위기가 오면 사람의 본질이 드러난다고 하지만, 나는 조금 다르게 생각한다. 위기가 오면 관계의 본질이 드러난다. 서로에게 어떤 존재였는지가 분명해진다. 같은 방향을 바라보고 있었는지, 아니면 그저 같은 자리에 앉아 있었을 뿐인지.

창업자가 회사에 남아야 하는 이유는 책임감 때문만이 아니다. 함께 시작한 사람들에게 보내는 메시지이기 때문이다. "나는 아직 여기 있다." 그 한마디가 흔들리는 팀을 붙잡을 때가 있다.

4.

복지라는 단어를 들으면 떠오르는 이미지가 있다. 화려한 사무실, 무제한 간식, 최신 장비. 미국 IT 기업들이 자랑하는 것들. 아마존 본사 로비에 반려견이 돌아다니고, 구글 캠퍼스에 세탁 서비스가 있다는 이야기.

하지만 복지의 본질은 혜택의 목록이 아니다.

복지는 조직이 구성원에게 보내는 신호다. "당신은 단순한 노동력이 아닙니다. 당신의 삶 전체를 존중합니다." 무제한 간식이 아니라, 아플 때 쉴 수 있다는 확신. 최신 장비가 아니라, 의견을 말해도 불이익이 없다는 안전감.

5.

작은 팀에서 일하면서 깨달은 게 있다. 거창한 복지 제도보다 더 중요한 건, 일상의 태도다.

누군가 힘들어 보일 때 먼저 "괜찮아?"라고 묻는 것. 실수했을 때 원인을 찾지, 범인을 찾지 않는 것. 야근이 당연한 게 아니라 예외라는 걸 인정하는 것. 이런 작은 것들이 쌓여서 사람이 조직을 신뢰하게 된다.

50인 이하의 회사에 전속 요리사를 둘 수는 없다. 하지만 한 사람의 컨디션을 물어볼 수는 있다. 결국 복지란, 사람을 숫자가 아닌 사람으로 대하느냐의 문제다.

6.

스타트업이 성장하면 피할 수 없는 순간이 온다. 초기 멤버와 새로운 멤버 사이의 긴장. "우리가 처음부터 여기 있었는데"라는 감정과, "지금의 역량이 중요한 거 아닌가"라는 논리가 부딪힌다.

이 갈등에 정답은 없다. 하지만 태도는 있다. 함께 시작한 사람들의 기여를 기억하되, 그것이 특권이 되어서는 안 된다. 새로 합류한 사람들을 환영하되, 기존의 맥락을 무시해서도 안 된다.

같이 일한다는 건 결국, 서로 다른 시간을 가진 사람들이 같은 현재를 만들어가는 일이다.

7.

가끔 이런 생각을 한다. 내가 이 사람들과 함께 일하는 이유가 뭘까.

능력? 물론 중요하다. 비전? 그것도 빠질 수 없다. 하지만 정말 솔직하게 답하자면, 이 사람들 곁에서 나도 좀 더 나은 사람이 되는 것 같아서다. 함께 있을 때 더 용감해지고, 더 솔직해지고, 더 끈기 있어지는 관계. 그런 관계가 같이 일한다는 것의 진짜 의미가 아닐까.

사업이 잘될 수도 있고, 안 될 수도 있다. 서비스가 성공할 수도, 실패할 수도 있다. 하지만 함께 일하며 서로를 대했던 방식은 남는다. 그것이 결국 우리가 만든 가장 중요한 것이다.

공정하다는 느낌은 결과가 아니라 과정에서 온다

Tue, 10 Mar 2026 09:00:00 GMT

1.

연봉 협상이 끝난 뒤, 사람들이 가장 먼저 하는 일이 있다. 옆자리 동료에게 눈짓을 보내는 것이다. '너는 어땠어?' 직접 묻지는 않는다. 하지만 표정을 읽는다. 그 표정에서 자신의 위치를 가늠한다.

흥미로운 건, 금액 자체보다 그 과정이 더 오래 기억된다는 점이다. 나도 그랬다. 숫자는 잊어도, 그때 들었던 말은 남아 있다. "이번에 이 정도로 결정됐어." 끝. 왜 그 숫자인지, 어떤 기준이었는지, 아무 설명도 없던 그 순간이 아직도 선명하다.

2.

돌이켜보면, 내가 조직에서 가장 불편했던 순간은 결과가 나빴을 때가 아니었다.

결정이 내려진 뒤에야 알게 되었을 때. 내가 알 수 없는 어딘가에서 이미 모든 게 정해져 있었을 때. "원래 그렇게 된 거야"라는 말을 들었을 때. 나는 그 과정에 존재하지 않았다는 사실을 깨달았을 때.

반대로, 결과가 내 기대에 미치지 못했어도 괜찮았던 적이 있다. 왜 이런 결정이 내려졌는지 설명을 들었을 때. 내 의견을 물어봤을 때. 비록 반영되지 않더라도, 적어도 고려는 되었다는 걸 느꼈을 때. 그때는 결과를 받아들일 수 있었다.

3.

예일대의 톰 타일러(Tom Tyler) 교수는 이걸 '절차공정성'이라 부른다. 사람들은 결과의 크기보다 그 결과에 이르는 과정이 공정했는지를 더 예민하게 느낀다는 것.

그가 정리한 일곱 가지 요소를 보면 고개가 끄덕여진다. 조직이 공정하려는 자세를 보이는지, 정직한지, 기회가 주어지는지, 결정의 질적 수준은 어떤지, 오류를 바로잡을 기회가 있는지, 편향되지 않았는지.

하나하나가 거창한 제도가 아니다. 결국 핵심은 단순하다. "당신은 이 결정에서 투명인간이 아닙니다"라는 메시지를 조직이 보내주느냐의 문제다.

4.

스타트업에서 일하면서 느낀 건, 작은 조직이라고 해서 이게 자동으로 해결되지 않는다는 점이다.

오히려 반대인 경우도 많다. 인원이 적으니 빠르게 결정해야 한다는 명분 아래, 과정이 생략된다. 창업자의 직관이 곧 결정이 되고, 그 결정은 슬랙 한 줄로 전달된다. 빠르다. 효율적이다. 하지만 거기엔 과정이 없다.

IT 스타트업들이 타운홀 미팅을 여는 이유가 여기에 있다. 임원들끼리 뚝딱 정하고 벽보에 붙이면 끝날 일들을 시시콜콜 설명하고 의견을 청취하는 것. 비효율적으로 보일 수 있지만, 그 비효율이 신뢰를 만든다.

5.

신뢰라는 단어를 자주 쓰지만, 곰곰이 생각해보면 그 실체가 모호하다.

누군가를 신뢰한다는 건 뭘까. 그 사람이 좋은 사람이라서? 능력이 뛰어나서? 물론 그런 요소도 있다. 하지만 조직에서의 신뢰는 조금 다르다. 내가 달갑지 않은 상황에 놓였을 때, 그래도 이 사람 곁에 있으면 괜찮겠다는 믿음. 보상이 기대보다 적을 때, 그래도 이 과정에는 이유가 있을 거라는 기대.

그러니까 신뢰는 감정이 아니라 구조에 가깝다. 감정은 흔들리지만, 구조는 버틴다. 좋은 리더는 매력적인 사람이 아니라, 신뢰할 수 있는 구조를 만드는 사람이다.

6.

리더의 자리에 서고 나서야 이해한 것들이 있다.

팀원이 불만을 표현할 때, 대부분은 결과에 대한 불만이 아니다. 과정에서 소외되었다는 느낌에 대한 불만이다. "왜 저한테는 말씀 안 해주셨어요?" 이 한마디에 담긴 감정은 분노가 아니라 서운함이다. 나는 여기에 속해 있다고 생각했는데, 그렇지 않았다는 서운함.

그래서 요즘은 결정을 내리기 전에 한 번 더 생각한다. 이 결정을 공유하지 않아도 될 사람이 정말 없는지. 의외로 그 범위는 내가 생각한 것보다 항상 넓다.

7.

분배공정성은 비교의 문제다. 내가 다른 사람과 비교해 제대로 보상받는가. 하지만 이건 어차피 완벽할 수 없다. 누구의 기여가 더 큰지를 객관적으로 재는 건 불가능에 가깝다.

그래서 결국 사람들이 기대는 건 절차다. 내가 보상의 크기를 정확히 알 수 없으니, 적어도 그것이 정해지는 과정만은 납득하고 싶다. 투명하고, 설명 가능하고, 일관된 과정. 그게 있으면 결과가 조금 아쉬워도 수긍한다. 그게 없으면 결과가 좋아도 의심한다.

공정함은 정답이 아니라 태도다.

8.

지금 이 글을 쓰면서도 떠오르는 장면들이 있다.

과정 없이 내려진 결정 앞에서 무력했던 순간. 반대로, 결정의 배경을 솔직하게 들었을 때 마음이 풀렸던 순간. 내가 리더로서 과정을 생략하고 후회했던 순간.

공정하다는 느낌은 결과의 크기에서 오지 않는다. 과정에 내가 있었는가, 없었는가. 그 차이에서 온다.

그리고 그 차이가, 한 사람이 조직에 남을 이유가 되기도 하고, 떠날 이유가 되기도 한다.

의미는 해석에서 태어난다

Sat, 14 Feb 2026 12:00:00 GMT

1.

소설을 쓰려면 뭐가 필요할까.

대부분 '소재'라고 답한다. 자극적인 사건, 기막힌 반전, 특별한 경험. 우리가 기억하는 소설 대부분이 강렬한 소재를 가지고 있으니, 당연한 답처럼 느껴진다.

하지만 『죄와 벌』은 어떤가. 가난한 학생이 전당포 노파를 죽이는 이야기다. 소재만 놓고 보면 신문 사회면 기사와 다를 바 없다. 『노인과 바다』는? 노인이 바다에서 큰 물고기를 잡는다. 그게 전부다.

소재가 아니라 훈련이다. 같은 재료를 가지고도 완전히 다른 요리를 만들어내는 것, 그것이 진짜 실력이다.

2.

삶도 마찬가지인 것 같다.

극적인 일이 일어나야 삶이 특별해지는 게 아니다. 똑같은 출근길, 똑같은 점심시간, 똑같은 귀갓길. 이 반복되는 일상을 어떤 태도로 경험하느냐에 따라, 삶의 질감이 완전히 달라진다.

기계적으로 임하면 그저 반복이다. 능동적으로 임하면 매일이 조금씩 다르다. 같은 길인데 오늘은 바람이 다르다. 같은 카페인데 오늘은 음악이 다르다. 같은 대화인데 오늘은 상대방의 표정에서 새로운 것을 읽는다.

3.

의미는 객관적으로 부여되는 것이 아니다. 의미는 해석을 통해 생겨난다.

우리는 보통 의미를 '발견'한다고 말한다. 마치 어딘가에 숨겨져 있는 보물을 찾듯이. 하지만 실은 그렇지 않다. 의미는 숨겨져 있지 않다. 내가 만들어내는 것이다.

같은 퇴사를 겪어도, 어떤 사람은 실패로 해석하고 어떤 사람은 전환점으로 해석한다. 같은 이별을 겪어도, 누군가에겐 상실이고 누군가에겐 성장이다. 사건 자체에는 의미가 없다. 의미를 입히는 건 나다.

4.

글쓰기에서 재미있는 구분이 있다. 에피소드적인 글과 에픽적인 글.

에피소드는 사건의 나열이다. 오늘 이런 일이 있었고, 어제는 저런 일이 있었다. 재미는 있을 수 있지만, 읽고 나면 남는 게 별로 없다. 각 부분이 따로 논다.

에픽은 다르다. 각각의 사건이 하나의 큰 흐름 안에서 서로를 비추고, 전체가 되어 하나의 메시지를 만든다. 같은 사건들인데, 엮는 방식에 따라 완전히 다른 이야기가 된다.

삶도 그렇다. 일어난 일들은 같아도, 그것을 어떻게 엮느냐에 따라 내 삶의 이야기가 달라진다. 에피소드의 나열로 살 것인가, 하나의 에픽으로 엮을 것인가.

5.

논리를 뛰어넘어 직접 몸과 마음으로 얻는 이해가 있다.

매일 가던 길이 아닌 다른 길로 가보는 것. 늘 듣던 음악 대신 침묵을 들어보는 것. 익숙한 패턴을 한 번 깨보는 것. 삶에 아주 작은 변화를 주는 것.

그런 체험은 두꺼운 책보다 더 깊은 지혜로 이끌 때가 있다. 머리로 이해하는 것과 몸으로 아는 것은 다르다. 수영 이론을 아무리 공부해도, 물에 들어가기 전에는 수영을 할 수 없듯이.

논리를 뛰어넘어 직접 몸과 마음으로 얻는 이해의 체험. 그것은 그동안 주목하지 못했던 삶의 또 다른 측면을 부각시켜준다.

6.

이충녕의 『어떤 생각들은 나의 세계가 된다』를 읽으며 이런 생각들이 정리되었다. 이 책이 특별한 건, 거창한 철학을 이야기하는 듯하면서도 결국 일상으로 돌아온다는 점이었다. 넷플릭스를 고르지 못하는 밤, 성격 탓을 하는 습관, SNS를 스크롤하는 손가락. 일상의 장면에서 생각의 실마리를 끌어낸다.

그리고 그 실마리들이 모여서 하나의 질문이 된다. 나는 지금 삶을 어떻게 해석하고 있는가.

7.

나는 지금까지 삶에서 소재를 찾고 있었던 건 아닐까. 특별한 경험, 극적인 전환, 기막힌 우연. 그런 것들이 있어야 삶이 의미 있어진다고 생각했던 건 아닐까.

하지만 소재가 아니라 훈련이다. 일상을 능동적으로 경험하는 훈련. 일어난 일에 의미를 해석하는 훈련. 에피소드를 에픽으로 엮는 훈련.

의미는 어딘가에서 떨어지는 게 아니다. 내가 해석할 때, 비로소 태어난다.

8.

그래서 오늘도 해석한다.

오늘 아침 마신 커피의 온도, 창밖으로 들어오는 2월의 빛, 이 글을 쓰는 지금 이 시간. 특별할 것 없는 하루다. 하지만 이 하루를 어떤 눈으로 바라보느냐에 따라, 이 하루는 어떤 책 한 권보다 더 많은 것을 가르쳐줄 수 있다.

어떤 생각들은 나의 세계가 된다. 그리고 그 세계는, 내가 해석하는 만큼 넓어진다.

성격이라는 피난처

Sat, 14 Feb 2026 11:00:00 GMT

"나는 원래 이런 사람이야."

누구나 한 번쯤은 들어본 문장이다. 혹은 스스로 내뱉어본 문장이다. 회의에서 의견을 못 내는 사람은 "나는 원래 내성적이라서", 계획을 끝까지 밀어붙이지 못하는 사람은 "나는 원래 쉽게 질려서", 남의 부탁을 거절 못 하는 사람은 "나는 원래 착한 사람이라서". 성격이라는 단어 뒤에 숨으면, 어떤 행동이든 설명이 되는 것 같다.

그런데 어느 순간부터, 이 문장이 불편해졌다.

설명인가, 면책인가

"나는 원래 이런 사람이야"라는 말 속에는 여러 겹의 의미가 숨어 있다. '그러니까 바꿀 수 없어', '그러니까 이해해줘', '그러니까 내 잘못이 아니야'. 가만히 뜯어보면, 이건 자기 행동을 설명하는 것이 아니라 면책하는 것에 가깝다.

자신의 행위에 합리적인 이유를 부여하고 싶은 것은 인간의 뿌리 깊은 욕망이다. 그리고 '성격'은 그 욕망을 채우기에 너무 편리한 도구다. 한 번 붙이면 더 이상 설명할 필요가 없으니까. 피난처처럼 안전하니까.

나를 삼인칭으로 본다는 것

사람의 행동을 설명하는 방식에는 두 가지가 있다.

하나는 밖에서 보는 것이다. "저 사람은 유전적으로 외향적이다", "저 사람은 어린 시절 환경 때문에 그렇다." 관찰자의 시점. 과학적이고 객관적이지만, 거기에 '나'라는 주체는 없다.

다른 하나는 안에서 말하는 것이다. "나는 이것을 원해서 이렇게 했다", "나는 이것이 옳다고 판단해서 이렇게 선택했다." 나의 욕망과 판단이 근거가 되는, 주체적인 설명이다.

성격 탓을 할 때, 우리는 자신을 밖에서 바라보고 있는 것이다. 마치 관찰자가 실험 대상을 분석하듯. "저 사람은 원래 그런 성격이니까." 그 '저 사람'이 바로 나인데.

분노의 주인

"왜 화를 냈어?"라는 질문에 "나는 원래 급한 성격이라서"라고 답하는 것과, "상대방이 약속을 세 번째 어겼고, 나는 신뢰를 중요하게 여기는 사람이라 참기 어려웠다"라고 답하는 것. 같은 분노인데 설명이 전혀 다르다.

전자는 성격에 떠넘긴 것이고, 후자는 자신의 행위를 이해한 것이다. 내 행동의 이유를 스스로 재구성할 수 있을 때, 비로소 그 행동의 주인이 된다. 반대로, 성격에 위임해버리면 나는 내 행동의 관객이 된다.

착함이라는 도피

"나는 착한 사람이니까 어려움에 처한 사람을 도와줘야 해."

얼핏 들으면 아름다운 말이다. 하지만 이것도 같은 구조다. '착한 사람'이라는 정체성이 먼저 있고, 그 정체성을 유지하기 위해 도움을 주는 것이라면, 그것은 상대를 위한 것이 아니라 나를 위한 것이다.

진정한 도움은 "나는 착한 사람이니까"가 아니라 "지금 이 상황에서 내가 할 수 있는 최선이 이것이라고 판단했기 때문에"에서 나온다. 성격이 아니라 판단이 행위의 근거가 되어야 한다.

권위가 무너진 자리

SNS가 많은 것을 바꿨다. 보통은 비교의 원천, 우울의 촉매 정도로 이야기되지만, 다른 면도 있다.

과거에는 소수의 권위자가 정보를 독점했고, 그 독점이 카리스마를 만들었다. 카리스마는 꾸며진 겉모습에서 나올 뿐이다. SNS는 그 독점을 무너뜨렸다. 물론 온갖 가짜뉴스가 혼란을 만들기도 한다. 하지만 동시에, 기존 체제에 맹목적으로 순응하지 않는 감각도 키워준다.

결국 같은 맥락이다. 누군가의 권위에 기대는 대신 스스로 생각하는 것. 성격에 기대는 대신 스스로 판단하는 것.

이충녕의 『어떤 생각들은 나의 세계가 된다』를 읽으며 이 생각이 더 또렷해졌다. 분열은 혼란이기도 하지만, 새로운 가능성의 시작이기도 하다.

피난처에서 나오기

"나는 원래 이런 사람이야"라는 말을 쓰기 전에, 한 번 멈춰본다. 그리고 물어본다.

정말 원래 그런 건가? 아니면 그렇게 말하는 게 편한 건가?

피난처는 따뜻하다. 하지만 거기에 머물면 바깥세상을 잊는다. 불편하더라도, 내 행동의 이유를 나의 말로 설명할 수 있는 사람이 되고 싶다.

"나는 이렇게 판단했기 때문에 이렇게 했다."

이 한 문장이, 성격이라는 피난처에서 나오는 첫걸음이 아닐까.

선택이라는 이름의 자유

Sat, 14 Feb 2026 10:00:00 GMT

1.

금요일 저녁, 넷플릭스를 켠다.

썸네일을 훑는다. 스크롤을 내린다. 다시 올린다. 뭔가 끌리는 게 있다가도, 옆에 더 나은 게 있을 것 같아서 넘긴다. 10분이 지나고, 20분이 지나고, 결국 아무것도 고르지 못한 채 유튜브를 켠다.

수천 개의 콘텐츠가 눈앞에 있는데, 나는 아무것도 보지 못했다.

2.

메뉴가 세 개인 식당에서는 고민이 짧다. 하지만 선택지가 열 개, 스무 개가 되면 이야기가 달라진다. 괌을 갈까, 몰디브를 갈까, 발리를 갈까. 심지어 그 선택이 결정적이지도 않다. 어디를 가든 즐거울 것이다. 그런데도 고르지 못한다.

이미 결정된 조건 내에서 고르는 건 쉽다. 어려운 건 아무런 제약 없이 열린 선택지 앞에 서는 것이다.

3.

자유롭다는 건 좋은 것이라고 배웠다. 더 많은 선택지, 더 많은 가능성, 더 많은 길. 그것이 곧 풍요라고.

그런데 막상 모든 문이 열려 있으면, 어느 문으로 들어가야 할지 모르겠다. 문 앞에서 서성이다 지친다. 열려 있는 문이 많을수록 들어가지 못한 문도 많아지고, 들어가지 못한 문 뒤에 뭐가 있을지 계속 궁금해진다.

선택하지 못한 것들이 유령처럼 따라다닌다.

4.

종교를 가진 사람들이 때로 부러울 때가 있다.

신앙이 있어서가 아니다. 규율이 있어서다. 무엇을 먹고, 무엇을 하지 않고, 어떤 날에 쉬고, 어떤 방식으로 기도하고. 삶의 많은 부분이 이미 정해져 있다. 그 안에서 고민할 여지가 줄어든다.

자유를 포기한 것처럼 보이지만, 오히려 그 안에서 깊은 평온을 찾는 사람들이 있다. 규율에 따라 스스로를 통제하면서, 역설적으로 더 자유로워지는 것이다.

5.

연인 관계도 비슷하다.

상대방의 요구를 받아들인다. 금요일 저녁은 같이 보내기로 한다. 일요일 아침에는 같이 산책하기로 한다. 혼자였다면 무엇이든 할 수 있었던 시간을, 기꺼이 포기한다.

자유를 잃는 것일까? 표면적으로는 그렇다. 하지만 매주 금요일 뭘 할지 고민하지 않아도 된다는 안도감. 누군가와 함께한다는 충만함. 자유를 제한함으로써, 오히려 더 단단한 무언가를 얻는다.

6.

아무런 토양에도 뿌리를 내리지 못하면, 삶은 수많은 방향으로 물살이 흐르는 바다에서 이리저리 떠다니다 질식하게 된다.

자유의 바다에서 질식한다. 이 표현이 머릿속에 남았다. 이충녕의 『어떤 생각들은 나의 세계가 된다』에서 만난 문장인데, 자유가 많으면 많을수록 숨이 트일 줄 알았는데 오히려 질식할 수 있다니. 묘하게 와닿았다.

7.

생각해보면, 내가 가장 생산적이었던 시기는 제약이 있었던 시기였다.

마감이 정해져 있을 때. 예산이 한정되어 있을 때. 선택지가 줄어들었을 때. 그때 오히려 집중력이 생기고, 창의력이 나오고, 결과물이 만들어졌다.

무한한 시간과 무한한 자원이 있었다면? 아마 아무것도 하지 못했을 것이다. 넷플릭스 앞에서 20분을 허비하듯이.

8.

'하고 싶은 대로 하는 것'이 자유일까, '해야 한다고 판단한 것을 실행할 수 있는 것'이 자유일까.

전자는 욕망에 이끌리는 것이고, 후자는 이성으로 방향을 정하는 것이다. 자유를 쓰려면 먼저 기준이 있어야 한다. 기준 없는 자유는 표류다.

9.

요즘 나는 의식적으로 선택지를 줄이려 한다.

아침에 뭘 먹을지 고민하지 않는다. 대략 정해두었다. 옷도 비슷한 것들로 채워두었다. 카페도 두세 군데만 간다. 사소한 결정에 에너지를 쓰지 않으니, 정말 중요한 결정 앞에서 더 또렷해진다.

10.

끝없는 자유의 바다에서 표류하다가 질식해 정신을 잃는 것은, 자유를 상실하는 것에 가깝다. 모든 것을 할 수 있다는 것은, 아무것도 하지 않는 것과 종이 한 장 차이다.

자신의 삶에 선을 긋는 것. 그리고 그 선을 지키는 것.

11.

나는 아직도 때때로 선택 앞에서 멈춘다. 완벽한 선택을 하고 싶은 욕심이 발목을 잡는다.

하지만 이제는 안다. 완벽한 선택이란 없다는 것을. 선택하지 않는 것이 가장 나쁜 선택이라는 것을. 그리고 무언가를 포기해야 비로소 무언가를 얻을 수 있다는 것을.

자유란 모든 것을 가질 수 있는 상태가 아니다. 무엇을 가지지 않을지 스스로 정할 수 있는 상태다.

선을 긋자. 그 선 안에서, 진짜 자유가 시작된다.

첫 페이지를 넘기는 용기

Sat, 31 Jan 2026 23:03:34 GMT

어떤 책은 제목만 봐도 안다. 읽어야 할 책이라는 걸.

근데 그런 책일수록 쉽게 펼치지 못한다. 재미없으면 어쩌지. 기대한 만큼 아니면 어쩌지. 읽다가 멈추게 되면 어쩌지.

그래서 한동안 책장에 꽂아만 둔다. 가끔 꺼내서 목차만 보다가 다시 넣는다.

그러다 어느 날, 첫 문장을 읽는다. 결말이 어떻든 괜찮겠다는 마음이 들 때.

용기는 두려움이 사라진 뒤에 오는 게 아니다. 궁금함이 두려움을 이긴 순간, 손이 먼저 움직인다.

요즘 읽기 시작한 책이 하나 있다. 아직 첫 챕터다.

공간이 말을 거는 순간

Fri, 30 Jan 2026 14:39:49 GMT

1.

문을 열고 들어서는 순간, 알 수 있을 때가 있다.

여기다, 라고.

설명하기 어렵다. 천장 높이가 마음에 들었다거나, 창문으로 들어오는 빛의 각도가 좋았다거나, 의자의 간격이 적당했다거나. 그런 것들을 하나하나 분석해서 내린 결론이 아니다. 그냥 안다. 몸이 먼저 안다. 어깨에 들어가 있던 힘이 스르륵 풀리고, 숨을 조금 더 깊이 들이쉬게 되고, 발걸음이 느려진다.

공간이 말을 거는 순간이다.

2.

나는 카페를 자주 간다. 커피를 좋아하기도 하지만, 정확히는 커피를 마시는 그 시간과 장소를 좋아한다. 같은 아메리카노라도 어디서 마시느냐에 따라 맛이 다르게 느껴진다. 물론 원두가 같다면 실제 맛은 같을 것이다. 하지만 경험은 다르다.

시끄러운 프랜차이즈 카페에서 마시는 커피와, 조용한 골목 안쪽 작은 가게에서 마시는 커피는 같은 음료가 아니다. 혀로 느끼는 맛은 비슷할지 몰라도, 몸 전체로 느끼는 감각은 완전히 다르다.

그래서 나는 카페를 고를 때 커피 맛보다 공간을 먼저 본다. 어떤 음악이 나오는지, 테이블 사이가 얼마나 떨어져 있는지, 창문 밖으로 뭐가 보이는지, 조명은 어떤 색인지. 그런 것들이 모여서 하나의 분위기를 만들고, 그 분위기 안에서 나는 커피를 마신다.

3.

좋아하는 공간에는 공통점이 있다.

첫째, 적당히 비어 있다. 너무 꽉 차 있으면 숨이 막힌다. 사람이든 물건이든 가구든, 빈틈이 있어야 시선이 쉴 곳이 생긴다. 여백이 있는 공간에서 생각도 여백이 생긴다.

둘째, 자연광이 들어온다. 인공조명만 있는 공간은 오래 있기 힘들다. 시간이 흐르는 게 느껴지지 않아서 그런 것 같다. 햇빛이 들어오는 공간에서는 오전과 오후가 다르고, 맑은 날과 흐린 날이 다르다. 같은 자리에 앉아 있어도 매번 조금씩 다른 경험을 하게 된다.

셋째, 주인의 취향이 보인다. 이건 설명하기 가장 어렵다. 그냥 느껴진다. 누군가 이 공간을 신경 써서 만들었구나, 라는 게. 벽에 걸린 그림 하나, 선반 위에 놓인 소품 하나, 메뉴판의 글씨체 하나에서. 상업적인 계산이 아니라 진짜 좋아서 고른 것들이 모여 있을 때, 공간은 말을 걸기 시작한다.

4.

몇 년 전, 교토에 간 적이 있다.

관광지를 돌아다니다가 지쳐서, 골목 안쪽으로 들어갔다. 작은 찻집이 하나 있었다. 간판도 거의 안 보이고, 문도 닫혀 있어서 영업 중인지 알 수 없었다. 그냥 끌려서 문을 밀었다.

안에는 나무 테이블 세 개와 카운터가 전부였다. 주인은 60대쯤 되어 보이는 남자였고, 손님은 아무도 없었다. 말차를 시켰다. 주인은 아무 말 없이 차를 준비했고, 나도 아무 말 없이 앉아 있었다.

그 공간에서 한 시간쯤 있었던 것 같다. 특별한 일은 없었다. 차를 마시고, 창밖을 보고, 가끔 주인이 뭔가를 정리하는 소리를 들었다. 그게 전부였다.

그런데 그날 저녁, 숙소로 돌아가면서 이상하게 마음이 편했다. 피로가 풀렸다기보다, 뭔가 채워진 느낌이었다. 무엇이 채워진 건지는 모르겠다. 그냥 그 공간에 있었던 것만으로 충분했다.

5.

요즘은 그런 공간을 찾기가 쉽지 않다.

대부분의 카페와 식당은 효율을 위해 설계된다. 테이블 회전율을 높이기 위해 의자를 불편하게 만들고, 조명을 밝게 해서 오래 앉아 있기 싫게 만든다. 음악은 대화를 방해할 정도로 크고, 인테리어는 사진 찍기 좋게 꾸며져 있다.

그런 공간에서는 공간이 말을 걸지 않는다. 오히려 재촉한다. 빨리 사진 찍고, 빨리 먹고, 빨리 나가라고.

물론 그런 공간이 나쁘다는 건 아니다. 목적이 다른 거다. 어떤 공간은 머무르기 위한 곳이고, 어떤 공간은 스쳐 지나가기 위한 곳이다. 다만 나는 머무를 수 있는 곳을 찾는 사람이다.

6.

집도 마찬가지다.

오래전, 처음 자취를 시작했을 때 가장 신경 쓴 건 월세와 교통이었다. 공간 자체는 별로 생각하지 않았다. 어차피 잠만 자는 곳이라고 생각했다.

그런데 이상하게 집에 있기가 싫었다. 일이 끝나도 카페에서 시간을 보내다 늦게 들어갔고, 주말에도 밖으로 나갔다. 집이 불편해서가 아니었다. 그냥 있고 싶지 않았다.

지금은 다르다. 집을 고를 때 가장 먼저 보는 건 창문이다. 어느 방향으로 나 있는지, 빛이 언제 들어오는지, 창문 밖으로 뭐가 보이는지. 그다음은 천장 높이, 그다음은 바닥 재질. 월세와 교통은 그다음이다.

사치라고 할 수도 있다. 그런데 집에 있는 시간이 편해지니까 삶 전체가 달라졌다. 밖에서 일하다 지쳐도 집에 들어오면 회복이 된다. 공간이 나를 안아주는 느낌이랄까.

7.

공간은 사람을 닮는다.

주인의 취향이 묻어나는 공간은 그 사람과 대화하는 것 같다. 말을 섞지 않아도 어떤 사람인지 느껴진다. 무엇을 좋아하고, 무엇을 중요하게 생각하는지. 공간 곳곳에 그 사람의 결정들이 쌓여 있기 때문이다.

이 의자를 고른 이유, 저 그림을 건 이유, 이 음악을 트는 이유. 하나하나가 선택이고, 선택이 모여서 공간이 된다. 그래서 좋은 공간에는 주인이 있다. 프랜차이즈가 아무리 예뻐도 어딘가 허전한 건, 선택의 주체가 보이지 않기 때문이다.

8.

나도 언젠가 공간을 만들어보고 싶다.

카페든 사무실이든 집이든, 들어오는 사람이 "여기다"라고 느낄 수 있는 곳. 말을 걸지 않아도 편안한 곳. 오래 앉아 있어도 재촉하지 않는 곳.

거창한 인테리어가 필요한 게 아니다. 그냥 진심으로 고른 것들이 모여 있으면 된다. 내가 좋아하는 것들로 채워진 공간은, 나와 비슷한 것을 좋아하는 사람에게 말을 걸 것이다.

취향이란 결국 그런 게 아닐까. 내가 무엇을 좋아하는지 알고, 그것을 삶에 가져다 놓는 것. 공간은 취향이 물리적으로 드러나는 가장 정직한 형태다.

9.

가끔 길을 걷다가, 처음 보는 가게 앞에서 멈출 때가 있다.

안이 잘 보이지 않는다. 문을 열고 들어가 봐야 어떤 곳인지 알 수 있다. 잠깐 망설인다. 그리고 문을 민다.

들어서는 순간, 알 수 있다. 여기다, 혹은 아니다.

그 감각을 믿는다. 설명할 수 없어도 괜찮다. 몸이 먼저 아니까.

좋은 공간을 찾는 일은, 결국 나를 찾는 일이다. 내가 어디서 편안한지, 무엇에 반응하는지, 어떤 것들에 둘러싸여 있고 싶은지.

공간이 말을 거는 순간, 나는 나에 대해 조금 더 알게 된다.

몸이 먼저 아는것들

Fri, 30 Jan 2026 14:21:17 GMT

생각이 많은 밤이 있다.
이불 속에서 천장을 본다.
내일은 뭘 해야 하지.
왜 아직 안 했지.
할 수 있을까.

생각은 생각을 낳고,
그 생각은 또 다른 생각을 낳는다.
꼬리를 물고,
결국 제자리.

엑셀과 브레이크를 동시에 밟으면
차는 앞으로 가지 않는다.
브레이크가 더 강하다.

생각과 행동도 그렇다.
둘은 수평이 아니다.
행동이 위에 있다.

행동하면 생각은 따라온다.
생각한다고 행동이 따라오진 않는다.

그러니까,
혼란스러우면 일단 움직여본다.
무서우면 일단 손을 뻗어본다.
모르겠으면 일단 시작해본다.

생각은 나중에 정리해도 된다.
몸이 먼저 알게 될 때가 있다.

완벽한 준비 같은 건 없다.
확신이 생긴 다음에 움직이는 게 아니라,
움직이다 보면 확신이 생긴다.

일단, 해보고.
후회는 그다음에.

취향을 파는 사람들

Fri, 30 Jan 2026 10:46:59 GMT

요즘 재밌는 서비스들을 보면 공통점이 있습니다. 기능이 특별하지 않습니다. 그냥 이쁩니다. 필수가 아닌데 사람들이 씁니다.

행사 등록 플랫폼 Luma가 그렇습니다. 유사 서비스들과 기능이 크게 다르지 않은데, 군더더기 없이 깔끔합니다. 필름 카메라 느낌을 주는 사진 앱 once.film도 비슷합니다. 기능은 단순한데, 감성이 있습니다. 출시 두 달 만에 월 매출 천만 원을 넘겼다고 들었습니다.

이런 서비스들을 보면서 떠오른 말이 있습니다.

"생필품이 아니라 사치품을 팔아야 한다. 사치품은 취향이다. 취향을 사고 파는 플랫폼이 살아남는다."

꽤 설득력 있는 말이라고 생각했습니다. 필수가 아닌 것을 사게 만드는 힘. 그게 취향이니까요.

근데 나는 필수품을 판다

저는 B2B SaaS를 만듭니다. 첫 시작은 세금계산서 관리 서비스였습니다. 현재는 기업의 재무 전반을 더 쉽게 관리 할 수 있도록 돕고 있습니다. 취향이 끼어들 틈이 없어 보이는 영역입니다. 안 이뻐도 써야 하고, 안 쓰면 법적으로 문제가 됩니다.

그런데 이것도 재밌습니다.

취향을 파는 서비스는 "갖고 싶게" 만들어야 합니다. 필수품을 파는 서비스는 "안 쓰면 손해"라고 느끼게 만들어야 합니다. 접근 방식이 다릅니다. 설득의 언어가 다릅니다.

취향은 감성에 호소합니다. 필수품은 논리에 호소합니다. 취향은 "이거 너무 이쁘지 않아?"이고, 필수품은 "이거 안 쓰면 매달 3시간 날려요"입니다.

결국 같은 질문

그런데 곰곰이 생각해보면, 둘 다 결국 같은 질문을 던지고 있습니다.

"왜 이걸 사야 하지?"

취향을 팔든, 필수품을 팔든, 사람이 지갑을 여는 이유를 고민하는 일입니다. 방법이 다를 뿐 본질은 같습니다.

취향 쪽은 "없어도 되는 걸 있게 만드는" 일이고, 필수품 쪽은 "어차피 해야 하는 걸 덜 고통스럽게 만드는" 일입니다. 둘 다 결국 사람을 이해해야 할 수 있는 일입니다.

둘 다 재밌다

요즘은 둘 다 재밌다고 느낍니다.

필수품을 4년째 만들면서 "어떻게 하면 이 지루한 일을 덜 지루하게 만들까"를 고민하는 것도 재밌고, 취향을 파는 서비스들을 보면서 "저건 어떻게 저렇게 사게 만들었을까"를 관찰하는 것도 재밌습니다.

그래서 요즘은 취향을 파는 사람들의 이야기를 듣는 게 재밌습니다. 어떻게 그 감성을 만들었는지, 왜 그걸 선택했는지. 나와는 다른 방식으로 같은 질문을 푸는 사람들이니까요.

설렘을 잃지 않는 법

Thu, 29 Jan 2026 20:17:17 GMT

얼마 전 누군가와 이런저런 이야기를 나누다가 문득 물었습니다.

"살면서 잃고 싶지 않은 게 뭐예요?"

돌아온 답은 예상 밖이었습니다.

"새로운 거에 설레어하는 마음이요."

그 순간 멈칫했습니다. 좋은 답이라고 생각했는데, 동시에 이상한 질문이 떠올랐습니다. 나는 왜 설레지?

당연하게 설레고 있었다

저는 원래 잘 설레는 편입니다. 새로운 고객을 만나면 설레고, 팀원들과 새로운 기능을 기획하면 설레고, 처음 보는 문제를 마주하면 설렙니다. 스타트업을 4년째 하면서 설렘이 부족했던 적은 없었던 것 같습니다.

그런데 그 사람의 답을 듣고 처음으로 생각했습니다. 나는 왜 설레는 걸까?

당연하게 느끼고 있던 감정이라 한 번도 뜯어본 적이 없었습니다. 왜 어떤 건 설레고 어떤 건 안 설레는지, 설렘의 조건이 뭔지.

설렘은 어디서 오는 걸까

생각해보니 모든 새로운 것이 설레는 건 아니었습니다.

이미 해본 일의 반복은 새로워도 설레지 않고, 결과가 뻔히 보이는 일은 시작해도 두근거리지 않습니다. 반대로 어떻게 될지 모르는 일, 예상 못한 방향으로 흘러가는 대화, 처음 만나는 사람과의 시간은 설렙니다.

결국 설렘은 새로움 자체가 아니라 예측 불가능한 가능성에서 오는 것 같습니다.

"이게 어디로 갈지 모르겠다"는 감각. 그게 설렘의 정체가 아닐까요.

그래서 잃고 싶지 않다는 말

그 사람이 "잃고 싶지 않다"고 했을 때, 저는 처음엔 그냥 좋은 답이라고만 생각했습니다.

그런데 곱씹어보니 그 말이 좀 다르게 들렸습니다. 설렘은 가만히 있으면 유지되는 게 아니라, 의식하지 않으면 사라질 수 있는 거라는 뜻이니까요.

경험이 쌓이면 예측력이 올라갑니다. 예측력이 올라가면 불확실성이 줄어듭니다. 불확실성이 줄어들면 불안도 줄지만, 설렘도 함께 줄어들 수 있습니다.

그래서 "잃고 싶지 않다"는 말은 어쩌면 의도적으로 지키겠다는 말일지도 모르겠습니다.

다시 그 질문

"살면서 잃고 싶지 않은 게 뭐예요?"

그 사람의 답을 듣고 저도 생각해봤습니다. 아직 깔끔하게 정리되진 않았지만, 적어도 한 가지는 알게 됐습니다. 설렘은 그냥 오는 게 아니라 어딘가에서 오고, 지키려면 뭔가를 해야 한다는 것.

다음에 만나면 물어보고 싶습니다.

"그 설렘, 어떻게 지키고 있어요?"

후회하는데 왜 또 볼까 - 콘텐츠 빈지워칭의 역설

Tue, 27 Jan 2026 12:47:28 GMT

새벽 2시, "한 편만 더"를 다섯 번째 되뇌인다.

넷플릭스가 친절하게 다음 에피소드를 5초 뒤에 재생해주겠다고 한다. 리모컨을 들 필요도 없다. 그냥 가만히 있으면 된다. 그렇게 시즌 하나가 끝난다.

다음 날 아침, 후회한다. "왜 그랬지." 그런데 며칠 뒤 또 같은 일이 반복된다.

뜨거운 나와 차가운 나

행동경제학에 Hot-Cold Empathy Gap이라는 개념이 있다.

감정이 뜨거울 때(Hot)와 차가울 때(Cold)의 판단이 다르다는 거다. 배고플 때 장보면 과자를 잔뜩 사고, 배부를 때는 "왜 이렇게 샀지?" 한다. 화날 때 보낸 카톡을 다음 날 읽으면 손발이 오그라든다. 운동하기 싫을 때는 헬스장 등록이 왜 그렇게 무의미해 보이는지.

흥미로운 건, 이 간극이 "예측 불가능"하다는 점이다. Cold 상태에서는 Hot 상태의 자신을 상상하기 어렵고, 그 반대도 마찬가지다. 배부를 때 "배고프면 이성을 잃는다"는 걸 머리로는 알지만, 실제로 배고파지면 그 앎이 무력해진다.

콘텐츠 소비도 비슷하다. 드라마가 재밌을 때는 Hot 상태다. 다음 회차가 궁금하고, 주인공이 어떻게 될지 알고 싶다. 그 감정의 온도에서는 "내일 피곤할 거야"라는 Cold한 예측이 힘을 못 쓴다.

문제는 내일 아침의 내가 오늘 밤의 나를 이해하지 못한다는 거다. "왜 그랬지?"라고 묻지만, 사실 그 질문 자체가 Cold 상태에서만 가능한 질문이다.

감정 소비와 콘텐츠 소비는 다를까?

요즘 "감정 소비"라는 말을 종종 듣는다. 스트레스받으면 충동 구매를 하고, 다음 날 후회하는 패턴. 이것도 전형적인 Hot-Cold Gap이다.

그런데 콘텐츠 빈지워칭과 감정 소비 사이에는 미묘한 차이가 있다.

감정 소비는 후회하면 다음엔 조심하려고 한다. 카드값 보고 충격받으면, 최소한 한동안은 지갑을 닫는다. 학습이 된다. 그런데 콘텐츠 빈지워칭은? 후회해도 또 한다. 심지어 같은 시리즈를 다시 보기도 한다.

왜 그럴까?

첫 번째 가설은 손실의 가시성이다. 충동 구매는 돈이라는 명확한 손실이 있다. 통장 잔고가 줄어들고, 카드 명세서가 온다. 숫자로 보인다. 그런데 빈지워칭의 손실은 "피곤함"이나 "시간"인데, 이건 눈에 보이지 않는다. 명세서가 오지 않는다. 다음 날 커피 한 잔 더 마시면 어떻게든 버틴다.

두 번째 가설은 보상의 지속 시간이다. 충동 구매는 "사는 순간"이 피크다. 결제 버튼 누를 때가 가장 짜릿하고, 물건을 받으면 감흥이 줄어든다. 그래서 후회가 빨리 온다. 그런데 드라마는 보는 내내 재미있다. Hot 상태가 몇 시간씩 유지된다. 후회가 끼어들 틈이 없다.

세 번째 가설은 사회적 용인이다. 충동 구매는 "낭비"로 여겨진다. 주변에서도 걱정하고, 본인도 부끄러워한다. 그런데 드라마 정주행은? "요즘 뭐 봐요?"라는 대화 소재가 된다. 밤새 봤다고 하면 "오 대단하다" 소리를 듣기도 한다. 후회의 무게가 가볍다.

플랫폼은 알고 있다

여기서 한 가지 불편한 사실이 있다.

플랫폼들은 우리의 Hot 상태를 아주 잘 이해하고 있다. 자동 재생이 대표적이다. 에피소드가 끝나면 5초 뒤에 다음 편이 시작된다. 이 5초는 절묘하다. "그만 볼까?"라고 생각하기엔 너무 짧고, 리모컨을 찾기엔 너무 빠르다.

다음 에피소드 미리보기도 그렇다. 엔딩 크레딧이 올라가는 동안 화면 한쪽에서 다음 회차가 재생된다. 아직 이번 에피소드의 여운이 남아 있는데, 이미 다음 이야기가 시작되어 있다. 끊을 타이밍을 주지 않는다.

"이 시리즈를 좋아하셨다면" 추천도 마찬가지다. 시즌을 다 봐서 이제 끝이라고 생각하는 순간, 비슷한 시리즈가 추천된다. Hot 상태를 다른 콘텐츠로 이어붙인다.

이게 나쁜 걸까? 솔직히 단정 짓기 어렵다. 플랫폼 입장에서는 사용자가 오래 머무는 게 좋은 거고, 사용자 입장에서도 그 순간은 즐거운 거니까. 다만 한 가지 확실한 건, 우리가 "그만 봐야지"라고 결심하는 순간, 그 결심을 방해하는 장치들이 이미 설계되어 있다는 거다.

Cold 상태로 돌아갈 기회를 최대한 늦추는 것. 그게 플랫폼의 목표다.

몰입의 경험

비슷한 경험이 또 있다.

여행 계획을 짤 때. 어디 갈지 정하고, 숙소 찾고, 동선 짜고. "이 식당이 좋대", "여기서 여기는 걸어서 10분이네." 유튜브 여행 브이로그를 틀어놓고, 구글 지도를 켜고, 블로그 후기를 뒤진다. 정신 차리면 새벽 2시다.

다음 날 피곤하다. "적당히 하고 잘걸." 그런데 다음 여행을 계획할 때 또 똑같이 한다.

책을 읽을 때도 그렇다. 재밌는 소설을 만나면 "한 챕터만 더"를 반복하다가 새벽이 된다. 다음 날 후회하지만, 다음 재밌는 책을 만나면 또 그런다.

이런 몰입의 순간을 "비이성적"이라고만 할 수 있을까?

그 시간에는 분명히 뭔가가 있다. 계획이 맞아떨어질 때의 쾌감, 다음 장이 궁금해서 멈출 수 없는 감정. 그게 가짜라고 할 수는 없다. 단지 다음 날의 내가 그 감정을 100% 기억하지 못할 뿐이다.

두 개의 나

그래서 이런 생각이 든다.

우리는 Hot 상태의 자신과 Cold 상태의 자신을 너무 다른 사람처럼 취급하는 게 아닐까.

Cold 상태에서는 Hot 상태의 자신을 "비이성적"이라고 판단한다. "왜 그랬지?" "다음엔 안 그래야지." 마치 그때의 내가 실수를 한 것처럼.

그런데 둘 다 나다. Hot 상태의 내가 느낀 즐거움도 진짜고, Cold 상태의 내가 느끼는 후회도 진짜다. 어느 쪽이 "진짜 나"라고 할 수 없다.

문제는 이 두 상태가 서로를 예측하지 못한다는 거다. Hot 상태에서는 Cold 상태의 후회를 과소평가하고, Cold 상태에서는 Hot 상태의 즐거움을 과소평가한다.

어쩌면 후회를 줄이는 방법은 "다음엔 안 그래야지"가 아니라, 두 상태의 나를 모두 인정하는 거일지도 모른다. Hot 상태의 내가 어떤 선택을 할지 미리 알고, 그 선택의 결과를 Cold 상태의 내가 받아들일 준비를 하는 것.

물론 말처럼 쉽지는 않다.

기록의 역할

가끔 이런 생각을 한다. 기록이 도움이 될까?

예를 들어, 드라마를 밤새 보고 난 다음 날 아침에 "어젯밤 느낌"을 적어두는 거다. 얼마나 재밌었는지, 얼마나 피곤한지, 다음에 또 그럴 것 같은지.

그러면 다음번에 Hot 상태가 됐을 때, 그 기록을 볼 수 있다. "지난번에 이랬구나." Cold 상태의 내가 Hot 상태의 나에게 보내는 메시지 같은 거다.

효과가 있을지는 모르겠다. Hot 상태에서 그 기록을 읽을 마음이 들지도 의문이고.

다만 기록의 진짜 가치는 다른 데 있을 수도 있다. 두 상태의 나를 연결해주는 거. "그때의 나"와 "지금의 나"가 서로 단절되지 않도록.

결론 없는 결론

이 글에 명확한 결론은 없다.

"빈지워칭을 줄이는 5가지 방법" 같은 걸 기대했다면 미안하다. 나도 모른다.

다만 요즘 드라마를 보다가 문득 이런 생각이 들었다. "이 감정은 진짜일까, 설계된 걸까." 그리고 그 질문 자체가 꽤 재미있었다. 적어도 Cold 상태의 나에게는.

아마 오늘 밤도 "한 편만 더"를 외치겠지만, 그게 꼭 나쁜 건지는 여전히 모르겠다.

Hot 상태의 내가 즐거우면, 그것도 나름의 의미가 있는 거 아닐까.

[볼타 이야기] 볼타 팀은 이렇게 일합니다

Sun, 17 Aug 2025 12:00:00 GMT

최근 볼타 팀이 일하는 법에 대한 이야기를 나눌 기회가 많았습니다. 많은 분들이 관심을 가져주셔서, 이 기회에 글로도 정리해보려 합니다.

볼타 팀은 전세계 재무팀의 비효율적 시간 낭비를 줄이고, 본질에 집중하여 돈을 더 많이 벌 기회를 제공한다는 공동 목표를 가지고 있습니다. 이 큰 방향은 변하지 않지만, 저희는 매주 작은 꿈들을 새롭게 세워나가고 있습니다.

그렇다면 빠르게 변화하는 시장에서 어떻게 정확한 의사결정을 내릴 수 있을까요? 저희가 찾은 답은 '직관 훈련'이었습니다.

직관 훈련의 중요성

데이터는 정말 중요합니다. 볼타 팀도 데이터를 정밀하게 분석합니다. 하지만 저희는 데이터보다 직관이 훨씬 중요하다고 생각합니다.

왜 그럴까요?

첫째, 데이터 분석은 팀이 어느 정도 규모가 되면 누구나 할 수 있습니다. 좋은 도구들이 많아졌고, 데이터를 다루는 방법론도 표준화되었습니다. 데이터 기반 의사결정은 이제 기본 중의 기본이 되었죠.

둘째, 더 큰 문제는 실무에서 마주하는 대부분의 상황에 참고할 만한 정량적 데이터가 없다는 점입니다. 새로운 기능을 만들 때, 새로운 시장에 진출할 때, 경쟁사가 예상치 못한 움직임을 보일 때 - 이런 순간들에는 과거 데이터가 별로 도움이 되지 않습니다.

셋째, 데이터는 과거를 보여줄 뿐, 미래를 예측하지 못합니다. 특히 빠르게 변화하는 스타트업 환경에서는 어제의 데이터가 오늘의 의사결정에 오히려 방해가 될 수도 있습니다.

그래서 저희는 직관을 훈련합니다. 직관은 데이터가 없는 상황에서도 빠르고 정확한 판단을 가능하게 합니다. 고객과의 대화 한 줄에서 숨겨진 니즈를 발견하고, 시장의 미묘한 변화를 감지하며, 아직 데이터로 증명되지 않은 기회를 포착할 수 있게 해줍니다.

물론 직관이 데이터를 대체하는 것은 아닙니다. 직관으로 빠르게 가설을 세우고, 데이터로 검증하며, 다시 그 경험이 직관을 더욱 예리하게 만듭니다. 이런 선순환이 볼타 팀의 강점입니다.

직관이 가능하게 하는 초 단위 의사결정

고객이 "A 기능이 있나요?" 라고 문의한다고 가정해보겠습니다.

일반적인 접근이라면 이렇게 진행될 것입니다. "A 기능을 개발해야 할까요? 개발 리소스는 충분한가요? 투자 대비 효과는 어떨까요?" 이후 몇 주간의 회의와 분석이 이어지겠죠. 또는 "A 기능을 개발하면 매출은 얼마나 될까요? 몇명이나 사용 할까요?" 같이 바텀업 사고를 하곤 합니다.

하지만 직관이 훈련된 팀은 조금 다르게 접근합니다. "이 고객은 실제로 B 문제를 겪고 있네요. 비슷한 문제를 겪으실 다른 고객도 떠오릅니다. 경쟁사도 유사한 시도를 했다가 어려움을 겪었죠. 진짜 해결해야 할 문제는 C입니다."

문제 검증부터 의사결정, 담당자 배정까지 초 단위로 진행됩니다. 이것이 가능한 이유는 저희가 지속적으로 훈련하는 네 가지 덕분입니다.

볼타 팀이 직관을 훈련하는 네 가지 방법

1. 외부 고객에 대한 이해도 높이기

저희 제품을 사용하시는 고객의 사업을 깊이 이해하려 노력합니다. 고객이 어떤 분들인지, 어떤 일상을 보내시는지, 무엇에 어려움을 겪으시는지 자세히 파악합니다. 단순한 VoC 수집을 넘어, 고객의 맥락을 이해하는 것이 중요합니다.

2. 내부 고객(팀원)에 대한 이해도 높이기

팀원들의 강점과 성장 영역을 팀 차원에서 이해합니다. 누가 어떤 문제를 잘 해결하는지, 어떤 상황에서 최고의 성과를 내는지 파악합니다. 이를 통해 새로운 문제를 탐구 할 때 최적의 담당자를 즉시 찾을 수 있습니다.

3. 시장에 대한 이해도 높이기

우리가 플레이하고 있는 시장의 법률과 정치적 변화를 지속적으로 추적합니다. 글로벌 트렌드를 분석하고, 경쟁사가 무엇을 시도하고 있는지, 어떤 성과를 내고 있는지 관찰합니다. 경쟁사가 과거에 겪은 시행착오도 귀중한 학습 자료가 됩니다. 현재의 UX나 기능 같은걸 참고하지는 않습니다.

4. 제품에 대한 이해도 높이기

일주일에도 수많은 릴리즈를 나가며 정신없는 시간을 보내다보면, 어느순간 몇개월 전 적용한 정책이 구체적으로 어떤 정책이었는지 잊게됩니다. 그러다보면 매일같이 제품에 들어와서 사용하는 고객보다 제품을 만드는 사람이 제품에 대한 이해도가 낮아지기도 합니다. 이를 방지하기 위해 지속적으로 제품을 사용하고, 학습하며, 개선점을 찾아나갑니다.

탑다운 사고로 접근하기

많은 팀이 바텀업으로 일합니다. 이 기능을 만들면 무언가 나아지겠지? 하는 식으로 접근하죠. 기능을 개발하고, 업데이트한 후, 고객 만족도나 매출 증가를 기대합니다.

볼타 팀은 조금 다른 방식을 택했습니다. 저희는 탑다운으로 사고합니다.

매출을 1억에서 10억으로 성장시키려면 무엇이 필요할까요?
고객을 진정으로 만족시키려면 무엇을 해야 할까요?
고객의 비용을 100만원 절감해드리면, 그 중 50만원은 기꺼이 지불하실 것입니다. 그정도 비용 절감이 가능한 문제는 무엇일까요?

목표에서 출발하여 역산합니다. 그 과정에서도 How(어떻게)가 아닌 What(무엇을)과 Why(왜)에 집중합니다. 실행 방법은 그 다음 단계입니다. 먼저 올바른 문제를 정의하는 것이 중요합니다.

빠른 검증과 용기 있는 실행

"이것이 진짜 문제일까요?"

저희는 항상 이 질문으로 시작합니다. 기존 고객 인터뷰나 VoC 데이터만으로는 충분하지 않습니다. 컨설팅 보고서를 참고하고, 국내외 기업 사례를 연구하며, 적합한 페르소나와 직접 대화를 나눕니다.

검증은 신속하게 진행됩니다. 2-3일, 때로는 몇 시간 만에 결론을 도출합니다. 이메일 응답이 없으면 전화로 연락드립니다. 필요한 정보를 얻을 때까지 다양한 방법을 시도합니다.

그리고 용기 있게 의견을 제시합니다. 이는 근거 없는 자신감이 아닙니다. 충분한 준비와 깊은 이해를 바탕으로 한 확신입니다. 때로는 불편한 진실도 솔직하게 공유합니다. 그것이 팀을 올바른 방향으로 이끄는 길이기 때문입니다.

마무리하며

볼타 팀의 일하는 방식이 특별하다고 생각하지는 않습니다. 다만 저희는 매일 조금씩 더 나은 직관을 만들어가려 노력합니다. 고객을, 시장을, 제품을, 그리고 서로를 더 깊이 이해하려 합니다.

그 결과 고객의 한 마디에서 진짜 문제를 발견하고, 초 단위로 의사결정하며, 본질에 집중할 수 있게 되었습니다.

전세계 재무팀이 본질에 집중할 수 있도록, 저희도 본질에 집중합니다. 이것이 볼타 팀이 일하는 방법입니다.

이 글이 팀의 일하는 방식을 고민하시는 분들께 작은 도움이 되기를 바랍니다. 관련하여 이야기 나눠보고 싶은게 있으시다면 언제든 연락주세요.

이기적인 이타주의자의 역설

Tue, 12 Aug 2025 00:51:08 GMT

빌 게이츠가 세계 경제포럼에서 말했다. "인간에게는 이기심과 타인을 보살피고자 하는 두 가지 강한 본성이 있다." 그리고 덧붙였다. 이 두 가지 동력이 뒤섞인 사람이 가장 큰 성공을 거둔다고.

처음 이 말을 들었을 때, 마치 거울을 보는 듯했다. 나는 이타적인가, 이기적인가? 아니, 애초에 이 둘을 나눌 수 있는 것일까?

선의라는 함정

스타트업을 운영하다 보면 수많은 도움 요청을 받는다. CTO를 구한다, 기술 자문이 필요하다, 조언을 듣고 싶다. 메시지가 올 때마다 나는 빠르게 판단한다. 이것이 진정한 도움 요청인가, 아니면 여러 후보 중 하나로 나를 리스트에 올려둔 것인가.

냉정하게 들릴 수 있다. 하지만 나는 안다. 선의로 시작한 도움이 때로는 독이 된다는 것을. 스스로 일어설 기회를 빼앗는 것일 수도 있다는 것을.

진정한 도움은 상대가 절실하게 원하고, 내가 실제로 영향을 미칠 수 있을 때만 의미가 있다. 안타까움에서 시작한 개입은 연민일 뿐, 사랑이 아니다.

내 사람들의 우선순위

나는 내가 책임지기로 선택한 내 사람들의 행복이 무조건적으로 선행되어야 한다고 생각한다.

누군가는 이기적이라고 할 것이다. 전 인류의 행복을 추구해야 하지 않느냐고. 하지만 나는 묻고 싶다. 내 곁의 사람이 불행한데, 어떻게 세상을 구할 수 있는가?

비행기 안전 수칙이 말한다. 산소마스크는 본인이 먼저 착용한 후 옆 사람을 도우라고. 이것은 이기심이 아니다. 나부터 살아야 남도 살릴 수 있다는, 가장 현실적인 이타주의다.

사랑의 이기성

새벽 3시, 잠들지 못한 채 생각한다. "어떻게 하면 이 사람이 엄청 행복한 삶을 살 수 있을까?"

4시간 동안 고민한다. 이것은 이타적인가? 표면적으로는 그렇다. 하지만 더 깊이 들여다보면, 이것은 철저히 이기적인 행동이다.

그 사람이 행복해야 내가 행복하기 때문이다. 그 사람의 웃는 얼굴을 보고 싶기 때문이다. 결국 나를 위한 것이다.

"이쁘다, 멋지다, 잘한다"는 말들도 마찬가지다. 상대를 위한 것 같지만, 사실은 이쁘고 멋진 그 사람을 보며 행복한 나를 위한 것이다.

선택적 이타주의

나는 모든 사람을 도울 수 없다. 아니, 도우려 하지 않는다.

대신 내가 선택한 사람들에게는 전부를 준다. 시간도, 관심도, 사랑도. 이것이 편협한가? 그럴 수 있다. 하지만 모두를 조금씩 돕는 것보다, 몇 명을 완전히 돕는 것이 더 가치 있다고 믿는다.

물 한 방울씩을 여러 곳에 뿌리면 어디도 젖지 않는다. 하지만 한 곳에 모두 부으면 그곳은 완전히 젖는다. 그리고 그 젖은 땅에서 무언가가 자라날 수 있다.

기브 앤 테이크의 진실

『기브 앤 테이크』라는 책이 있다. 주는 사람이 결국 받는다는, 얼핏 보면 순수한 이타주의를 설파하는 듯한 책이다. 하지만 자세히 읽어보면 다르다.

성공하는 기버(Giver)는 무작정 주지 않는다. 누구에게 줄지 선택하고, 언제 줄지 판단하고, 어떻게 줄지 계산한다. 이것은 이타적인가, 이기적인가?

답은 '둘 다'다. 그리고 그것이 포인트다. 순수한 이타주의도, 순수한 이기주의도 지속 가능하지 않다. 둘이 섞여야 한다. 마치 물과 기름이 아니라, 물과 물감처럼.

관련해서 이전에 짧게 쓴 글이 있다. 기브앤테이크 6장. 이기적인 이타주의자

지속 가능한 선함

나는 '이기적인 이타주의자'다.

내가 사랑하는 사람들이 행복해야 내가 행복하다. 그래서 그들을 돕는다. 이것은 이기적이다.

하지만 그들을 진정으로 돕기 위해, 내 방식이 아닌 그들이 받아들일 수 있는 방식을 고민한다. 이것은 이타적이다.

이 역설적인 조합이 나를 지속 가능하게 만든다. 순수한 이타주의자였다면 진작 번아웃되었을 것이고, 순수한 이기주의자였다면 혼자 남았을 것이다.

우선순위의 윤리

"왜 전 세계 사람들이 아니라 당신 주변 사람들만 돕는가?"

이런 질문을 받을 때마다 나는 반문한다. "당신은 가족보다 낯선 사람을 먼저 돕는가?"

우선순위를 정하는 것은 차별이 아니다. 한정된 자원을 가진 존재로서의 현실적 선택이다. 나는 내가 영향을 미칠 수 있는 범위를 안다. 그리고 그 안에서 최선을 다한다.

내 회사의 고객들, 내 팀원들, 내가 사랑하는 사람들. 이들이 나의 우주다. 이 작은 우주를 완벽하게 만드는 것이 나의 이기적인 이타주의다.

계산된 진정성

나는 모든 행동과 생각 하나하나에 어떤 영향이 있고 어떻게 발산시킬 수 있는지 명시적으로 짚어가는 습관이 있다.

이것은 계산적이다. 하지만 그 계산의 목적이 '어떻게 하면 이 사람에게 진정으로 도움이 될까'라면, 그것은 동시에 진정성이다.

본능적으로 움직이면 되는 일을 복잡하게 생각한다고 할 수도 있다. 맞다. 하지만 이 복잡한 계산이 결국 더 정확한 도움으로 이어진다면, 그것이 진정한 사랑 아닐까.

결론: 역설의 수용

나는 이기적이면서 이타적이다. 계산적이면서 진정성 있다. 선택적이면서 헌신적이다.

이 모든 역설을 수용할 때, 비로소 지속 가능한 선함이 가능해진다. 나를 위해 남을 돕고, 남을 도우며 나를 채운다. 이것이 내가 찾은 균형점이다.

빌 게이츠의 말이 맞았다. 이기심과 이타심, 이 두 가지 동력이 뒤섞일 때 가장 큰 성공을 거둔다.

다만 여기서 '성공'이란 부나 명예가 아니다. 내가 사랑하는 사람들이 행복하고, 그것을 보며 나도 행복한 것. 그것이 내가 정의하는 성공이다.

이기적인 이타주의자로 사는 것은 역설이 아니라 현실이다. 우리는 모두 나를 위해 남을 돕고, 남을 도우며 나를 완성한다.

내가 선택한 나의 보호자에게

Mon, 11 Aug 2025 23:38:33 GMT

넘어져 무릎이 깨졌을 때, 울기도 전에 나를 일으켜 세우던 손길이 있었습니다. 세상은 선택의 영역이 아니었고, 나를 지켜주던 이들 역시 내가 선택한 사람들이 아니었습니다. 부모, 가족이라는 이름으로 주어진 나의 첫 번째 세계. 그 안에서 나는 안전했지만, 때로는 원치 않는 보호에 숨 막히기도 했습니다.

어른이 된다는 것은, 그 단단하던 세계에 스스로 문을 열고 나오는 일이라는 걸 그때는 몰랐습니다. 법적으로는 성인이지만 정서적으로는 여전히 아이인 채로, 우리는 보호자 없는 시간을 살아갑니다. 모두가 잠든 새벽, 이유 없는 불안에 심장이 내려앉을 때. 중요한 결정을 앞두고 수없이 흔들릴 때. 세상이 너무 거대하게 느껴져 혼자임이 버거울 때. 우리는 문득 깨닫습니다. 어른에게도 여전히 보호자가 필요하다는 것을요.

그래서 우리는 찾아 나섭니다. 내 상처를 들여다보고, 내 편이 되어주고, 필요할 때 기꺼이 어깨를 내어줄 사람. 그리고 동시에, 내가 그런 존재가 되어주고 싶은 단 한 사람을요.

어느 날은 당신이 세상의 무게에 휘청이는 나를 붙잡아 주었고, 또 다른 날은 내가 길을 잃은 당신의 손을 잡았습니다. 아침에는 내가 당신의 불안을 다독이고, 저녁에는 당신이 나의 지친 하루를 안아주었죠. 우리는 그렇게 서로의 어깨를 번갈아 내어주며 각자의 우주를 지켜냈습니다. 이것은 일방적인 보호가 아닌, 서투른 두 사람이 함께 추는 왈츠와 같았습니다.

"내가 너의 보호자가 되겠다."

의무가 아닌 의지로, 책임이 아닌 사랑으로 당신이 이 말을 건넸을 때, 나는 혈연보다 더 무거운 약속의 무게를 느꼈습니다. 선택했기에 더 소중하고, 언제든 떠날 수 있기에 매 순간 서로를 붙잡아야 하는 관계. 그래서 우리는 더 신중해집니다. "밥은 먹었어?", "조심히 들어가" 같은 사소한 안부들이 보이지 않는 보호막이 되어 서로를 지켜준다는 것을 배웁니다.

어쩌면 결혼이란 인류가 만든 가장 오래되고 낭만적인 '보호자 선택 계약'인지도 모릅니다. 기쁠 때 함께 웃고, 아플 때 곁을 지키고, 세상이 등을 돌려도 마지막까지 내 편이 되어줄 한 사람을 법과 사회 앞에서 내 사람으로 공표하는 일. 로맨스와 열정을 넘어, "이제부터 내가 당신을 지킨다"는 엄숙한 약속 말입니다.

매일 아침 눈을 뜨며, 나는 다시 선택합니다. 오늘도 당신의 보호자가 되기를. 그리고 당신에게 기꺼이 보호받는 사람이 되기를.

어린 시절 우리에게 보호자는 '주어지는 것'이었습니다. 하지만 이제야 압니다. 진짜 어른이 된다는 것은 보호자를 잃는 것이 아니라, 비로소 나의 보호자를 선택할 자유와 누군가의 보호자가 될 자격을 얻는 것임을. 그리고 그 선택을 매일 새롭게 이어가는 것임을요.

매일 아침, 다시 쓰는 편지

Sun, 10 Aug 2025 05:11:26 GMT

나의 사람에게.

우리의 시작은 태엽 인형의 춤과 같았죠. 누가 먼저랄 것도 없이 서로에게 이끌렸고, 심장은 내 의지와 상관없이 당신을 향해 뛰었습니다. 보이지 않는 실에 매달린 채, 우리는 정해진 중력에 따라 서로에게로 떨어졌습니다. 그 춤이 영원할 것이라고 믿었던, 황홀한 착각의 계절이었습니다.

하지만 영원한 태엽은 없더군요. 어느 날 인형의 춤이 멈춰 섰을 때, 문득 두려웠습니다. 이 모든 게 화학물질이 만든 환상은 아니었을까. 도파민이라는 나침반이 고장 나고 옥시토신이라는 연료가 바닥나면, 우리는 어디로 가야 할까.

바로 그 자리에서, 우리의 진짜 사랑이 시작되었습니다.

우리는 깨진 그릇을 금으로 잇는 장인들처럼, 서로의 상처와 균열을 발견하고 조심스럽게 어루만졌습니다. 완벽한 반쪽을 찾아 헤매는 대신, 두 개의 불완전한 조각이 만나 세상에 하나뿐인 무늬를 만들어갔죠. 당신의 상처가 나의 무늬가 되고, 나의 모남이 당신의 그림이 되었습니다.

우리는 함께 시간을 조각하는 사람들이 되었습니다. 어느 조각가가 돌 속에서 형상을 발견하듯, 우리는 평범한 하루라는 대리석 안에서 영원을 깎아냈습니다. 함께 저녁을 준비하는 시간, 나란히 앉아 각자의 책을 읽는 침묵, 같은 천장을 바라보며 생각에 잠기는 밤. 이 사소한 순간들이 모여 성당의 스테인드글라스보다 더 신성한 풍경을 만들었습니다.

이제 나는 압니다. 첫 비행의 설렘이 사라진 후에도 매년 같은 길을 날아가는 늙은 철새처럼, 사랑은 이제 선택이라는 것을요. 파도가 매일 같은 시간에 바위를 찾아오듯, 약속이나 의무가 아닌, 오늘의 마음으로 당신에게 닿는다는 것을요.

그래서 나는 매일 아침, 어둠이 물러가고 빛이 스며드는 그 순간에 조용히 맹세합니다.

"오늘도 나는 당신을 선택합니다."

이 말에는 영원을 장담하는 오만함도, 내일을 확신하는 경솔함도 없습니다. 그저 유한한 존재로서 내가 할 수 있는 가장 진실한 약속, 현재에 대한 온전한 충실함만이 담겨 있을 뿐입니다.

우리는 언젠가 시들 것을 알기에, 오늘 더 향기롭게 피어나는 꽃과 같습니다. 이 생물학적 마법이 끝날 것을 알기에, 우리는 매일의 선택으로 우리만의 마법을 만들어갑니다.

사랑은 저절로 피어나는 계절이 아니라, 함께 흙을 고르고 물을 주며 가꾸는 정원사라는 것을 알려준 나의 사람. 오늘도 나의 정원이 되어주어 고맙습니다.

내연기관과 개발자의 만남 - 기계공학에서 배우는 창의적 사고

Tue, 29 Jul 2025 00:10:15 GMT

어제 한 친구와 나눈 대화가 계속 머리속을 맴돌고 있다. 기계공학을 전공한 그 친구가 들려준 내연기관의 배기가스 절감 기법에 대한 이야기였는데, 듣다 보니 이게 단순히 자동차 엔진의 이야기가 아니라는 생각이 들었다.

물을 엔진에 뿌린다고?

"엔진에 물을 분사해서 내부 온도를 낮추면, 노킹 현상을 방지하고 출력을 높일 수 있어."

처음 들었을 때는 "엔진에 물을? 고장 나지 않나?"라는 생각이 들었다. 하지만 설명을 듣고 보니 정말 치밀하게 계산된 해결책이었다.

고온에서 발생하는 노킹(비정상 연소)는 물의 증발열로 억제하고, 그 덕분에 점화 타이밍을 최적화해서 출력을 끌어올릴 수 있다는 것이다. 온도를 낮춰서 연소 효율이 좋아지는 게 아니라, 노킹이라는 문제를 해결해서 엔진이 본래 성능을 발휘할 수 있게 만드는 거였다.

개발자로서 이런 접근이 정말 인상 깊었다. 문제의 근본 원인을 파악하고, 직관적으로는 이상해 보이는 방법으로 해결하는 사고방식 말이다.

EGR: 배기가스를 다시 넣는다

더 놀라운건 EGR(Exhaust Gas Recirculation) 시스템이었다. 이미 연소된 배기가스를 다시 흡기구로 보내서 새로운 공기와 섞는다는 개념이다.

"왜 더러운 배기가스를 다시 넣는거야?"라고 물었더니, 친구가 웃으며 설명해줬다. 이미 연소된 CO₂와 H₂O는 불활성 가스라서 산소 농도를 희석시킨다. 그러면 연소 할 수 있는 산소가 줄어드니 연소 온도가 낮아지고, 결국 질소산화물 배출이 줄어든다는 것이다.

여기서 핵심은 의도적으로 연소 효율을 약간 떨어뜨려서 환경적 목표를 달성한다는 점이었다. 최고 성능을 포기하고 다른 가치(환경)를 선택하는 엔지니어링적인 결정이다.

정말 기발한 발상이다. 완벽한 연소라는 국지 최적화보다, 전체적인 균형을 중시하는 시스템 최적화의 사고방식. 그 차이를 배울 수 있었다.

제약이 만드는 혁신

가장 인상 깊었던 건 이런 기술들이 탄생한 배경이었다. 환경 규제가 강해질수록 엔지니어들이 더 창의적인 해결책을 만들어낸다는 것이다.

질소산화물은 줄여야 하는데
출력은 유지해야 하고
연비도 좋아야 한다.

이런 상충하는 요구사항들 사이에서 물 분사, EGR, 다양한 연소 제어 기법들이 탄생했다. 결국 제약이야말로 혁신을 강제로 끌어내는 연료가 된 셈이다.

소프트웨어 엔지니어링에서도 마찬가지 아닌가? 메모리 제한, 응답 시간 요구사항, 동시 접속자 수 등등. 이런 제약 조건들이 있기에 우리도 더 효율적인 알고리즘과 아키텍처를 고민하게 되는 것이다.

ECO 모드와 트레이드오프

ECO 모드에 대한 이야기도 흥미로웠다. 흡기량을 줄이면 배기가스는 줄어들지만 출력도 함께 떨어진다. 완벽한 트레이드오프다.

"결국 엔지니어링은 트레이드오프의 예술이네."라고 말했더니, 친구가 고개를 끄덕였다. 모든 것을 다 잡을 수는 없으니, 상황에 따라 무엇을 우선할지 선택하는 것이 핵심이라고.

개발에서도 매일 마주하는 고민이다.

성능 vs 가독성
기능 vs 단순함
속도 vs 안정성

정답은 없고, 상황에 맞는 최선의 선택만 있을 뿐이다.

격자틀 멘탈모델, 다시 한번 확신하다

평소 찰리 멍거의 '격자틀 멘탈모델(Lattice Mental Models)'을 정말 좋아했는데, 이번 대화를 통해 그 위력을 다시 한번 체감했다. 서로 다른 학문 분야의 핵심 원리들이 하나의 격자처럼 연결되어, 더 깊은 이해와 통찰을 만들어낸다는 이 개념이 얼마나 강력한지 새삼 느꼈다.

기계공학의 내연기관 원리에서 배운 것들:

고정관념을 깨는 발상의 전환 (물을 엔진에 뿌리기)
제약 조건을 혁신의 기회로 보는 시각 (환경 규제 -> 새로운 기술)
복잡한 시스템에서 핵심 변수를 찾아내는 능력 (온도가 모든 걸 결정)
상충하는 요구사항 사이에서 균형점을 찾는 지혜 (성능 vs 환경)

이런 사고법들은 소프트웨어 개발은 물론, 비즈니스, 투자, 인간관계에까지 적용할 수 있다. 한 분야에서 깊이 있게 학습한 원리가 다른 모든 영역의 문제 해결에 도움이 되는 것이다.

멍거가 "진정한 지혜는 여러 학문의 핵심 아이디어들을 머릿속에서 격자처럼 연결할 때 나온다"고 했을 때, 이론적으로는 이해했다고 생각했다. 실전적으로도 그 중요성에 대해 어렴풋 이해하고 있었다. 하지만 오늘처럼 실제로 한 분야의 깊은 지식이 완전히 다른 영역의 사고를 확장시키는 순간을 경험하니, 왜 이 개념에 그렇게 매료되었는지 다시 한번 확신하게 되었다.

예전에도 비슷한 경험이 있었다. 우리가 보고 있는 별은 이미 수십억 년 전에 없어져 더 이상 존재하지 않는 별일 수도 있다는 천체물리학의 개념을 처음 들었을 때, 문득 이런 생각이 들었다. 그렇다면 지구 반대편과 네트워크 통신을 할 때도 비슷한 일이 일어나는 건 아닐까?

내가 지금 보내는 데이터 패킷이 상대방에게 도달할 때 쯤, 내 서버는 이미 다른 상태가 되어있을 수도 있다. 결국 분산 시스템에서 일관성 문제를 다루는 것도, 빛의 속도 제한으로 인한 정보 전달 지연을 다루는 것과 본질적으로 같은 문제인 셈이다.

천체물리학에서 개발까지, 전혀 다른 분야지만 '시간과 정보'라는 공통 분모로 연결되는 순간이었다.

감사의 마음

한 시간도 안 되는 대화였지만, 완전히 다른 분야에서 이렇게 많은 영감을 얻을 줄 몰랐다. 무엇보다 복잡한 공학적 원리를 이렇게 쉽고 재미있게 설명해주는 친구의 능력에 감탄했다.

전공 지식을 일상 언어로 번역하는 능력, 그리고 상대방이 이해할 수 있도록 친절하게 설명하는 마음씨. 이런 사람과 함께 이야기하는 시간이 얼마나 소중한지 새삼 느꼈다.

기계공학을 전공했지만 지금은 개발자로 일하고 있는 친구에게 고마운 마음이다. 전공 지식을 잊지 않고 간직하면서도, 내가 흥미를 가질 수 있도록 연결고리를 만들어준 그 센스와 배려심.

앞으로도 이런 대화를 계속 나눌 수 있기를 바란다. 서로 다른 분야에서 배운 것들을 나누며, 함께 성장해나가는 관계. 이게 바로 진정한 친구가 아닐까?

"모든 학문은 연결되어 있다"는 말의 참뜻을 알 것 같다. 오늘도 또 하나 배웠다.

앞으로도 이런 대화를 계속 나눌 수 있기를 바란다. 서로 다른 분야에서 배운 것들을 나누며, 서로의 사고 격자를 한 칸씩 촘촘하게 메워가는 관계. 그 과정에서 우리는 조금 더 깊고, 조금 더 넓게 세상을 이해하게 될 것이다.

언젠가는 내가 또 다른 분야의 이야기를 들려줄 차례가 오겠지. 그때 이 친구의 격자에도 새로운 선이 그어질 것이다. 모든 학문이 연결되어 있다는 말, 오늘 나는 그것을 머리가 아니라 가슴으로 배웠다.

뿌리 없는 성장은 없다 - 빠른 성장이라는 착각

Sat, 26 Jul 2025 19:25:49 GMT

나무에게서 배우는 진짜 성장의 법칙

조금 전, 나무들이 서로 소통한다는 흥미로운 영상을 보았다. 본질은 다른 내용이었지만, 오히려 그 부분이 인상 깊었다. 뿌리 아래 숨겨진 거대한 네트워크를 통해 영양분을 나누고, 위험을 알리고, 심지어 죽어가는 나무가 자신의 마지막 자원을 다른 나무에게 전달한다는 내용이었다. (영상; 칸을 뒤집은 미친 환경 캠페인)

그 순간 문득 떠오른 생각이 있었다. "이것이야말로 많은 사람들이 놓치고 있는 성장의 본질이 아닐까?"

빠른 성장이라는 착각

스타트업 씬에서, 개발자 커뮤니티에서, 심지어 일상 대화에서도 빠른 성장은 늘 미덕으로 여겨진다. 빠르게 승진하고, 빠르게 기술을 익히고, 빠르게 성과를 내는 것. 마치 그것이 성공의 전부인 양 말이다.

그런데 정말 그럴까? 나무를 보라. 100년을 살아남은 거대한 참나무와 2년 만에 쑥 자란 포풀러 중 어느 것이 진정한 성장을 이뤘다고 할 수 있을까?

많은 사람들이 '성장'과 '팽창'을 구분하지 못한다.

팽창은 빠르지만 취약하다. 성장은 느리지만 지속 가능하다. 나무가 위로만 자라려 하면 뿌리가 얕아져 첫 번째 폭풍에 쓰러진다. 사람도 마찬가지다.

보이지 않는 곳에서 일어나는 진짜 성장

나무의 가장 중요한 부분은 눈에 보이지 않는다. 땅 위의 웅장한 모습은 땅 아래 뿌리 시스템이 있기에 가능하다. 연구에 따르면, 건강한 나무의 뿌리 시스템은 지상부보다 2배~3배 넓게 퍼져있다고 한다.

사람의 성장도 마찬가지다.

겉으로 드러나는 것들 화려한 프로젝트, 빠른 승진, 높은 연봉 이것들은 보이지 않는 기초가 탄탄할 때만 의미가 있다.

진짜 성장의 뿌리는 이런 것들이다.

깊이 있는 사고력과 문제 해결 능력
지속적인 학습 습관과 적응력
진정성 있는 소통과 협업 능력
원칙과 가치관에 기반한 의사결정력

이런 '뿌리'들이 견고해야 어떤 변화가 와도 흔들리지 않는다.

최근 AI가 업무 현장을 빠르게 바꾸고 있다. 표면적인 스킬만 가진 사람들은 위기감을 느끼지만, 깊은 사고력과 문제 해결 능력을 기른 사람들은 오히려 AI를 도구로 활용해 더 큰 가치를 창출한다. 뿌리가 깊으면 가지도 더 멀리 뻗을 수 있기 때문이다.

협력이 만드는 지속가능한 성장

나무들의 가장 놀라운 특징은 경쟁하지 않는다는 것이다. 대신 협력한다.

어린나무가 그늘 아래서 자랄 때, 큰 나무는 자신의 뿌리를 통해 영양분을 나눠준다. 가뭄이 들면 물을 공유하고, 해충이 공격하면 화학 신호로 경고한다. 심지어 서로 다른 종끼리도 도우며 산다.

왜 그럴까? 숲 전체가 건강해야 각자도 건강하기 때문이다.

현대 사회는 개인의 성공에만 집중하라고 가르친다. 하지만 정말 지속가능한 성장을 이루려면, 자신을 둘러싼 생태계를 함께 키워야 한다.

좋은 멘토를 만나고, 동료들과 지식을 나누고, 후배들을 도우며, 업계 전체의 발전에 이바지하는 것. 이것이 나무들이 수백 년을 버텨내는 비결이다.

개발자 커뮤니티에서 가장 존경받는 사람들을 보라. 그들은 단순히 코드를 잘 짜는 사람이 아니라, 다른 사람들의 성장을 도우며 전체 생태계를 풍요롭게 만드는 사람들이다.

진정한 리더는 혼자 높이 올라가는 사람이 아니라, 다른 사람들도 함께 성장할 수 있는 토양을 만드는 사람이다.

가지치기의 지혜

나무는 때로 자신의 가지를 포기한다. 아픈 가지, 약한 가지, 잘못된 방향으로 자란 가지를 스스로 떨어뜨린다. 전체의 건강을 위해서다.

사람의 성장에도 이런 지혜가 필요하다. 때로는 포기하는 용기가 필요하다.

더 이상 의미 없는 일들
에너지를 소모시키는 관계들
과거의 성공에 대한 집착
남들의 기대에 맞추려는 강박

진정한 성장은 무언가를 더하는 것만이 아니라, 불필요한 것을 덜어내는 것이기도 하다. 집중이야말로 성장의 핵심이다.

계절을 받아들이는 힘

나무는 계절을 거부하지 않는다. 봄에는 새싹을 틔우고, 여름에는 무성하게 자라고, 가을에는 잎을 떨어뜨리고, 겨울에는 조용히 쉰다.

모든 계절이 성장의 일부라는 것을 안다.

사람의 인생에도 계절이 있다. 빠르게 성장하는 시기가 있고, 정체된 것 같은 시기도 있다. 실패와 좌절의 겨울도 있고, 새로운 시작의 봄도 있다.

많은 사람들이 겨울을 견디지 못한다. 당장 눈에 보이는 성과가 없으면 불안해하고, 남들과 비교하며 조급해한다. 하지만 겨울이야말로 뿌리가 가장 깊어지는 시기다.

중요한 것은 지금이 어떤 계절인지 인정하고, 그 계절에 맞는 성장을 하는 것이다. 겨울에 꽃을 피우려 억지 쓸 필요 없다. 조용히 뿌리를 기르며 다가올 봄을 준비하면 된다.

나무에게서 배우는 성장의 원칙

깊이를 선택하라 빠른 것보다 깊은 것을. 많은 것보다 탄탄한 것을. 당장 보이지 않아도 뿌리부터 단단히 하자.
연결을 선택하라 경쟁보다 협력을, 혼자 잘되려 하지 말고, 함께 자랄 수 있는 관계들을 만들어가자.
계절을 선택하라 억지로 서두르지 말고, 자신만의 성장 리듬을 찾자. 지금이 뿌리를 기르는 시기라면, 그것에 집중하자.

이것들은 단순한 조언이 아니다. 수백 년을 살아남은 나무들이 증명해 낸 생존과 성장의 법칙이다.

마치며

나무는 하루아침에 자라지 않는다. 하지만 100년을 버틴다.

사람도 마찬가지다. 진짜 성장은 보이지 않는 곳에서, 천천히, 다른 이들과 함께 이뤄진다.

오늘도 조급함에 떠밀려 어디론가 달려가고 있다면, 잠시 멈춰 서자. 내 뿌리는 충분히 깊은가? 나와 연결된 사람들은 건강하게 자라고 있는가? 지금은 나에게 어떤 계절인가?

진짜 성장은 속도가 아니라 방향이다.

그리고 그 방향을 알려주는 가장 좋은 나침반은, 아마도 창밖에서 묵묵히 자라고 있는 나무들일지도 모른다.

성장이란 결국 시간이 증명해 주는 것이다. 조급해하지 말자. 깊이 뿌리내리고, 따뜻하게 연결되고, 자신만의 계절을 받아들이며 성장해 가자.

느린 것이 부끄러운 게 아니다. 방향을 잃는 것이 부끄러운 것이다.

내 안의 회로를 밝히는 시간에 대한 기록

Thu, 24 Jul 2025 08:31:01 GMT

창업가의 삶이란 쉼 없이 흐르는 전류와 닮았다. 세상의 비효율을 해결하겠다는 단 하나의 목표를 향해 모든 에너지를 쏟아붓다 보면, 스스로가 거대한 회로 그 자체가 된 듯한 착각에 빠지곤 한다. 낮과 밤의 경계는 흐릿해지고, 끼니를 거르기 일쑤며, 세상은 온통 최적화해야 할 변수들의 집합처럼 보이기 시작한다. 지도 없이 항해하듯 나아갈 길에 대한 믿음이 희미했던 시절의 압박감은, 이제는 반드시 해낼 수 있다는 단단한 확신으로 바뀌었다. 그 즐거운 확신이야말로, 기꺼이 자신을 태우는 가장 뜨거운 연료가 된다.

문제는 이 회로가 좀처럼 꺼지지 않는다는 점이다. 일상의 모든 풍경 속에서 나는 무의식적으로 비즈니스 모델을 역산하고, 시스템의 숨은 규칙을 파헤친다. 가령, 무인 빨래방 앞을 지날 때면 나는 그저 깨끗한 세탁물을 떠올리지 않는다. '저 기계들의 한 시간당 최대 매출은 얼마일까. 지금 가동률은 20%가 채 안 돼 보이는데. 그렇다면 월매출과 임대료, 기기 감가상각비를 제하고 나면 과연 수익성이 있을까.' 내 머릿속은 순식간에 손익계산서를 그린다. 병원 건물이 즐비한 거리에선 간판의 미묘한 차이가 눈에 들어온다. '「OO의원」과 「OO성형외과 의원」의 차이는 무엇일까. 전문의 자격 유무에 따라 허용된 시술의 범위가 달라지는 걸까.' 나는 사회적 약속과 규제의 층위를 파고들고 있다.

이렇게 세상을 분해하고 재조립하는 사고는 나의 동력이지만, 동시에 내 안의 에너지를 끊임없이 소모시키는 원인이기도 하다. 나는 기업들 사이에 놓인 복잡한 거래의 길을 탐사하고, 그 길목을 막는 보이지 않는 장벽을 허무는 일을 한다. 혼돈처럼 얽힌 돈과 데이터의 흐름 속에서 명료한 질서를 발견하고, 모든 기업이 본질적인 가치 창출에만 집중하는 세상을 만드는 일. 그 거대한 청사진을 현실로 만드는 과정에는 분명 창조적인 희열이 있다. 하지만 그 희열에 매몰되다 보면, 정작 내 안의 가장 섬세한 회로가 마모되는 소리를 놓치고 만다. 혁신이라는 이름 아래, 나라는 존재를 무한히 소모해도 좋은 부품으로 여기기 시작하는 것. 그것은 일이 즐거울 때일수록 더 경계해야 할 위험한 순간이다.

하지만 나는 이 즐거운 질주 속에서도, 문득 스스로에게 질문을 던진다. '나는 왜 이 일을 시작했는가'라는 첫 질문의 빛이 흐려지고, 혹시 내가 이 속도에 취해 방향을 잊고 있지는 않은가. 그럴 때 나는 의식적으로 쉼표를 찍는다. 키보드에서 손을 떼고 목적 없이 낯선 도시의 거리를 걷고, 때로는 의식적으로 낯선 골목을 찾아 카메라의 뷰파인더를 들여다본다. 그날의 날씨와 빛, 그리고 그 순간의 내 감정까지 한 장의 프레임 안에 담아내는 것이다. 그렇게 바깥세상을 충분히 담아낸 뒤에는, 자연스레 안으로 시선이 향한다. 그럴 때 나는 오래된 카페의 구석 자리를 찾아, 노트에 생각을 기록한다.

이 시간은 나에게 흐트러진 마음을 조율하는 시간과 같다. 익숙한 소음이 오히려 고요한 배경이 되어주는 그곳에서 나는 하얀 노트를 펼친다. 정제되지 않은 날것의 단어들, 업무 폴더에는 담을 수 없는 사적인 감정의 조각들을 그저 흘려보낸다. 때로는 복잡한 사회 시스템의 논리를 파고들며, 세상의 규칙을 명료하게 이해하는 과정에서 오히려 마음의 평온을 얻기도 한다. 그것은 불협화음을 내던 내 안의 논리와 감정을 다시 가지런히 하여, 본래의 소리를 되찾게 하는 과정이다. 이 고요한 다독임 끝에, 나는 다시 단단해진다. 비로소 내가 풀어야 할 문제와 나 자신을 건강하게 분리할 수 있게 되는 것이다.

결국 세상을 움직이는 거대한 에너지는 가장 인간적인 '나'에게서 비롯된다고, 나는 믿는다. 잘 조율된 내면을 가진 리더만이 더 멀리 항해할 수 있는 튼튼한 배를 만들 수 있다. 스스로를 돌보는 시간이 결코 도피나 사치가 아니라, 가장 중요한 투자의 시간이자 가장 이타적인 책임감의 발현이라는 역설을 배운다. 기술의 비전을 선명히 제시하는 동시에 내면의 작은 소리에도 귀 기울일 줄 아는 균형 감각. 그것이야말로 이 즐거운 항해를 지치지 않고 계속할 유일한 동력일 것이다. 그래서 나는 오늘도 걷고, 쓰고, 방전된 나 자신을 충전한다. 이 도시의 미래와 함께, 내 안의 작은 불씨 또한 꺼뜨리지 않기 위해서.

결과에 확신이 없더라도 꾸준히 노력해야 하는 이유

Sat, 08 Mar 2025 12:41:49 GMT

우리는 종종 무언가를 시작하거나 계속할 때 확신이 필요하다고 생각합니다. 이 길이 맞는걸까?, 내가 정말 잘하고 있는 걸까?, 결과가 나올까? 이런 의문이 끊임없이 머릿속을 맴돕니다. 하지만 인생의 가장 큰 성취는 종종 확신 없이 그저 계속해서 나아갔을 때 찾아옵니다.

확신보다 중요한 것은 지속성이다

"그냥 하는거에요. 확신 있어서 하는 게 아니고 그냥 계속 하는거에요"

이 말은 단순하지만 깊은 진리를 담고 있습니다. 우리 삶의 대부분의 일은 처음부터 완벽한 확신을 가지고 시작하지 않습니다. 오히려 불확실함 속에서 한 걸음씩 나아가며 길을 찾아갑니다.

전문가들도 시작은 초보자였습니다. 차이점은 그들이 포기하지 않고 계속했다는 것뿐입니다. 확신이 없어도 그저 계속 나아갔습니다.

꺾이는 순간에도 그냥 하는 힘

"꺾이지 않는 마음이 아니라 꺾였는데 그냥 하는 거야."

완벽한 의지력과 결단력으로 절대 꺾이지 않는 사람은 존재하지 않습니다. 진정한 강인함은 좌절과 의심의 순간에도 다시 일어나 계속하는 능력에 있습니다.

자신감이 떨어지고, 확신이 사라지고, 의욕이 꺾여도 다시 시작하는 것이 중요합니다.

돌멩이를 던지듯, 경험을 쌓아가는 과정

"돌멩이 던져서 과녁에 맞춘다고 생각을 하고 어느 순간에 자신을 좀 믿고서 천천히 쌓여 간다고 생각해."

모든 시도는 경험으로 쌓입니다. 처음에는 돌멩이를 무작정 던지는 것처럼 느껴질 수 있습니다. 하지만 계속 던질수록 감각이 생기고, 조금씩 과녁에 가까워집니다. 이것이 바로 성장 과정입니다.

실패와 시행착오는 낭비가 아니라 성공으로 가는 필수 단계입니다. 각 실패는 다음 시도를 위한 귀중한 데이터입니다.

과도한 고민은 행동을 막는다

"이거저거 생각하잖아? 아무것도 안 돼. 가고 싶은데 발을 떼면 벌써 반은 간 거야."

너무 많은 생각은 종종 우리를 마비시킵니다. 완벽한 타이밍, 충분한 준비, 더 많은 정보를 기다리다 보면 결국 아무 것도 시작하지 못합니다. 가장 중요한 것은 그저 첫 발을 떼는 것입니다.

행동은 생각보다 강력합니다. 생각으로는 얻을 수 없는 통찰과 경험을 행동을 통해 얻을 수 있습니다.

부족함을 인정할 때 더 강해진다

"내가 모자르다고 생각하고 내가 부족하다는 생각이 어느 순간에는 너를 더 높이 올려줄 수 있는 굉장히 큰 원동력이 돼."

자신의 한계와 부족함을 인정하는 것은 약함이 아니라 성장의 시작입니다. 완벽하다고 생각하는 사람은 더 배우려 하지 않습니다.

반면 자신의 부족함을 인정하는 사람은 계속해서 배우고 성장합니다. 겸손함은 우리를 더 열린 마음으로 만들고, 더 많은 가능성에 눈을 뜨게 합니다.

매일의 작은 노력이 쌓여 큰 변화가 된다

결국 삶의 큰 성취는 하루아침에 이루어지지 않습니다. 성취는 매일의 작은 노력, 실패 후에도 다시 일어나는 의지, 확신 없이도 계속 나아가는 용기가 모여 만들어진 결과입니다.

오늘 당신이 하는 일에 완전한 확신이 없더라도 괜찮습니다. 그저 계속하세요. 돌멩이를 던지듯 계속 시도하세요. 그러다보면 그 모든 노력이 쌓여 상상하지 못했던 높이에 도달하게 될 것입니다.

확신이 없어도 계속 나아가는 것, 그것이 바로 진정한 성장의 비결입니다.

B2C와 B2B 환경에서의 엔지니어링: 각자의 매력과 차이점

Thu, 06 Mar 2025 21:58:40 GMT

제가 엔지니어로서 경험했던 B2C와 B2B 환경은 각기 다른 매력과 도전이 있었는데요. 이번 글에서는 제 경험을 바탕으로 두 환경의 차이점과 각각의 장단점에 대해 이야기해보려 합니다.

B2B의 매력: 고객과의 긴밀한 관계

B2B와 B2C는 각자 매력이 있지만, 저는 B2B를 훨씬 더 좋아하는 편입니다. B2B 환경에서는 고객과 더 가까이서 깊은 이야기를 나눌 수 있기 때문인데요. 직접 고객의 목소리(VoC)를 들으며, 실제 임팩트를 산정하고 우선순위를 결정하는 과정에 참여할 기회가 많습니다. 이런 측면에서 B2C보다 B2B에서 더 재미있게 일할 수 있었습니다.

어떤 분들은 이 글을 읽고, B2B가 고객 이야기 듣기 더 어려운 것 아닌지 생각하실 수 있습니다. 하지만 심층 고객 인터뷰를 비롯해 더 깊은 이야기를 나누기 용이하고, 개인을 넘어 조직과 회사 전체에 영향을 주는 제품을 만들다 보니 복잡성이 훨씬 증가합니다. 이런 복잡성 속에서 문제를 더 구체화하고 풀어나가는 과정이 꽤나 즐겁습니다.

복잡한 조직 설득이라는 도전

B2B 제품 개발에서 또 흥미로웠던 점은 복잡한 이해관계를 가진 조직을 설득하기 위한 제품을 어떻게 만들지 고민하는 과정입니다. B2B 제품은 여러 부서와 다양한 의사결정자들을 만족시켜야 하므로, 제품 설계가 더 복잡해질 수 있습니다. 이러한 복잡성이 오히려 저에게는 흥미로운 도전으로 다가왔습니다.

B2B 회사 내에서도 플랫폼 조직 선호

흥미롭게도 제가 B2C 서비스 회사에서 일할 때도, 대고객용 앞단 서비스 조직보다는 뒷단 플랫폼 조직에서 일하는 것을 더 즐겼습니다. 그 이유는 일반적으로 플랫폼 조직이 릴리즈하는 경우 정말 많은 사이드 이펙트가 발생할 수 있고, 심지어는 데이터의 정합성 자체가 깨질 수 있기에 문제 하나하나 깊게 고민해보고, 최고의 선택을 해야만 하기 때문이었습니다.

다양한 경험의 중요성

제 생각에는 B2C와 B2B 모두 두루두루 경험해보는 것이 좋습니다. 지금 무얼 해보고 싶은가라는 기준은 계속 바뀔 테니, 그 기준이나 생각이 바뀔 때 즈음이 새로운 도전을 시작하기 좋은 시점이 아닐까 싶습니다.

결론

엔지니어링 환경은 B2C와 B2B 모두 각자의 매력과 도전이 있습니다. 개인적으로는 B2B 환경이 제 성향과 더 잘 맞았지만, 이는 개인의 선호도와 목표에 따라 달라질 수 있습니다. 중요한 것은 다양한 경험을 통해 자신에게 맞는 환경을 찾아가는 과정이라고 생각합니다.

하고 싶은 것의 부재

Sun, 02 Mar 2025 20:19:26 GMT

어느순간부터 특별히 하고 싶은게 없었던 것 같다. 물론 아예 없는건 아니었지만, 일 자체와 일에 관련된 여러 고민이 나에게 즐거움을 주는 주요한 요인들이었다.

그러다보니 일상적인 부분에서 도파민 분출이 약해진 듯 하다. 예쁜 하늘, 아름다운 풍경, 맛있는 음식 같은 곳에서 느끼는 즐거움이 많이 줄어들었다.

일이 아닌 것에서 즐거움과 행복을 느끼는 때는 주로 혼자서 완전 새로운 것을 시도하거나 상대방의 반응에서 오곤 했다.

상대방이 먼저 무언가를 해보고 싶어하거나 어딘가에 가보고 싶어하고, 무언가를 먹어보고 싶다고 할 때 상대가 원하는 것을 해볼 수 있도록 돕고, 함께 그것을 했을 때 상대가 행복해하는 모습에서 대리만족을 느끼며 행복감을 느끼곤 했다. 교육이나 고객 만족을 위해 고민하는 것도 비슷한 맥락이었다.

그런데 최근 지인과 대화를 나누면서 되게 화려하거나 대단할 것 없는 시간인데도 그 시간이 즐겁고 행복하더라. 왜 그럴까, 너무 궁금했다.

저런 생각을 해오던 중, 문득 그 대화는 내가 평소에 느끼던 '상대를 위한 행동'에서 오는 대리만족과 다른, 더 직접적이고 순수한 연결감을 준다는 느낌을 받았다.

상대를 위하는 생각과 행동이 아니라, 정말 나에 대해 생각해볼 수 있게끔 도움되었달까? 평소에는 다른 사람의 즐거움을 위해 행동하면서 간접적으로 행복을 느꼈는데, 그 덕분에 온전히 내 자신으로 있을 때도 직접적인 행복을 경험하게 되었다. 이런 경험이 낯설지만 새롭고 특별했다.

고민하는 시간의 가치

Sun, 02 Mar 2025 14:53:08 GMT

트러블슈팅이란 무언가를 행동하고 그 과정에서 발생한 문제를 해결해 가는 과정이 아닌, 실행하기 전 충분한 상상과 사유의 과정이 아닐까?

이는 단순한 학습에도 큰 교훈을 가져다준다. 과거의 경험과 지식이 쌓여 충분한 상상과 사유의 과정을 거치지 않고, "이건 대략 그럴 것이다"라며 넘겨짚는 경우가 많다. 점점 '내가 배우려는 것은 무엇인가', '이것의 본질은 무엇인가'를 비롯한 고민의 과정이 생략되고 간결해지고 있다.

이는 시대의 변화 때문일까? AI의 발전도 영향이 있을까?

누군가는 "아무 걱정 없이 고민하는 사치를 부릴 여유가 없다"라며 반문할 수도 있을 것이다. 하지만 그럴수록 무언가에 대하여 고민하고 상상하는 시간은 더욱 가치 있어진다.

`당신은 왜 그렇게 치열하게 사는가?`

물질적 풍요? 가정의 평화? 자아실현? 어떤 이유에서든 목표하는 바에 도달하기 위해선 치열한 경쟁이 필연적이다. 하지만 목표에 도달하는 것은 극소수의 사람이다. 많은 사람들은 목표에 도달하기 위해 노력하고 실행하고 회고하며 나아간다. 그렇다면 이 과정 자체를 충분히 즐길 수 있어야 하지 않을까?

내가 살아가는 IT 업계에서는 이 세상을 '무한경쟁 게임'에 비유하곤 한다. 이러한 무한경쟁 속에서 스스로를 잃은 채로 타인과 비교하며 그들을 추종하는 것은 너무나도 불행한 일이다. 무한한 가능성이 존재하는 게임 속에서 스스로 한계를 결정짓는 행위이기 때문이다.

나에 대한 이해

그렇기에 타인에게 이끌려 다니지 않고 스스로 가치를 만들어낼 수 있어야 한다. 이를 위해선 '나의 강점과 약점은 무엇인지', '나의 관심사는 무엇인지'를 비롯하여 나 자신을 잘 이해하고, 스스로 고민하고 생각하는 시간이 필요한 것이다.

사실 이 글을 읽는 당신은 본능적으로 수년 전부터, 본질의 중요성에 대해 알고 있었을 것이다. 그럼에도 본질에 다가가는 것이 두려워 다가가지 못했을 가능성이 높다. 본능적으로는 알고 있지만, 본질에 대해 생각하는 것을 피하는 행위는 양가감정을 극대화하게 된다. 양가감정이 극에 달하면 결국 스스로 가치 있게 보냈다고 생각했던 과거의 시간들을 부정하게 된다.

남에게 보여주고 싶은 모습만을 보여주기 위해 나를 숨길수록 나에 대해 잃어가고, 어느 순간 허탈감을 느끼게 된다.

내가 개발자이니 개발자로서의 관점을 말해보겠다. 당신은 왜 개발자로서 일하는가? 개발이 재미있고 즐거우면 취미로 하면 되는 것 아닌가? 왜 업으로 하는가?

나는 어떠한 문제를 발견하고, 구체화한 뒤 그 문제를 해결하기 위한 가설을 세우는 과정 자체를 즐긴다. 이는 개발자의 소양이라기보단 사회를 구성하는 구성원으로서 우리가 살아가는 세상에 많은 관심이 있다는 것에 가깝다. 업의 관점으론 우리 업계의 PM이라는 직무를 가진 사람들의 소양에 가깝다.

그럼에도 난 저런 고민과 상상이 즐겁다. 하지만 가설을 세우는 것에서 끝난다면 아쉽지 아니한가? 가설을 검증하기 위해 실행하고, 평가해보고 싶은 욕심도 당연히 있다. 운 좋게도 내가 개발자이기에, 그것도 꽤나 역량 좋은 개발자 중 하나이기에 내 가설을 검증하기 위한 수단으로 개발을 하고, 개발자로 일하는 것이다.

난 내 힘이 닿는 데까지 내가 해결 가능한 문제를 발굴하고 실제로 그 문제를 해결해보려고 한다.

지금은 우리 고객의 고민을 0개로 만들어주고 싶다. 이것이 내가 개발자로서 살아가는 이유이자 내 삶의 목적이다.

작은 규모=공정한 평가

Wed, 05 Feb 2025 23:47:55 GMT

폴 그레이엄의 <해커와 화가>에서 언급된 작은 조직의 장점을 현대 기업에 비추어 작성해봅니다.

소규모 조직의 핵심 장점

대규모 조직은 개인의 기여도를 정확히 측정하기 어렵습니다. 수천 명이 함께 일하면 각자의 성과가 전체 평균에 섞여버립니다. 반면 10명 내외의 소규모 조직은 개인의 성과가 바로 드러나 공정한 평가가 가능합니다.

소규모 조직이 빠른 이유

큰 조직은 거대한 구식 전함과 같습니다. 수천 명이 노를 젓지만, 개인의 노력이 전체 속도에 미치는 영향은 작습니다. 그러나 10명의 작은 배는 다릅니다.

개인의 기여도를 바로 확인합니다.
실력자들이 모여 평균 성과가 높습니다.
서로 독려하며 최선을 다합니다.

현대 스타트업에 주는 시사점

스티브 잡스는 스타트업의 성패가 초기 멤버 구성에 달렸다고 했습니다. 2010년에 쓴 이 책의 통찰은 현대에 더욱 중요해졌습니다. 소규모 조직은 뛰어난 인재들이 자신의 가치를 온전히 인정받는 환경입니다. 작은 규모가 성공을 보장하진 않습니다. 하지만 작은 규모이기에 가능한 것들이 많습니다.

볼타 팀은 초기부터 작은 규모의 조직을 유지하는 것의 중요성에 대하여 깊게 고민했는데요. 관련 글은 아래에서 읽을 수 있습니다.

[볼타 이야기] 작은 팀을 유지하려는 이유

10년이 지난 지금도 이 책의 통찰은 유효합니다. 10년 전 만난 쿠팡 김범석 의장님이 떠오릅니다. 당시엔 낯설었던 그분의 주장이 지금은 매우 타당한 것으로 평가받습니다. 폴 그레이엄의 선구안처럼, 혼자 믿고 주장했던 그분의 혜안이 아직도 인상 깊습니다.

기브앤테이크 6장. 이기적인 이타주의자

Sun, 02 Feb 2025 02:02:06 GMT

아래 내용은 채팅방에 공유했던 내용이라 문체를 별도로 가공하지 않고 그대로 단락만 정리하여 작성하였습니다. :)

6장: 이기적인 이타주의자

성공한 기버와 실패한 기버의 차이

제가 돈을 받지 않고 교육을 하고, 그냥 막연하게 그들의 '성공'을 위해 기부를 하고 시간을 쓰는 것에 대하여 많은분들이 어떻게 그렇게까지 할 수 있느냐고 물어보곤 하는데요.

그때마다, 결국 나에게도 도움이 되는 것이 있기에 그렇게 한다. '이기적 이타심'이라고도 부른다. 라고 답을 하는 편이었습니다.

그러다보니 이번 챕터의 타이틀인 '이기적인 이타주의자'라는 표현에 눈길이 갔네요.

전체 내용을 읽으면서 느낀 것 + 생각

내가 본능적으로 깨닫고 지니고 있던 마음가짐이 실제로 많은 연구와 사례를 통해 유의미하다는걸 알 수 있었고, 쭉 읽으면서도 저에게 있어서 보상은 '돈'보다는 그들의 성공과 그들이 성공으로 나아가는 과정에서 발생하는 다양한 시행착오를 근처에서 바라볼 수 있는 특권을 가지는 것이라는 생각이 들었네요.

책에서 '일을 더 많이하면서도 활력을 유지하는 사람'에 대해 언급하는데, 실제로 저도 하는 일이 많고 새로운걸 도전하는걸 즐기는 편인데 딱히 힘들다고 생각해본적이 없는데요. 일단 뭐든 하면 잘 해내는 편이고 어느정도 이상의 성취를 이루는 것이 여태까지는 막연하게 성취를 느낄때까지 달려가는 속도가 남들보다 월등히 빠르다. 정도로 생각하고 있었지만, 이번 챕터를 읽어보니 내가 하는 행동과 생각 하나하나에 어떤 영향이 있고 어떻게 발산 시킬 수 있는지 명시적으로 짚어가는 습관이 크게 영향을 준게 아닐까 싶습니다. 지금 이 글을 쓰는 순간에도 이 글을 읽는 여러분들에게 어떤 영향이 있을지 생각하면서 쓰고 있네요.

아래는 책 내용 일부 인용 + 살짝의 편집 정리

똑똑한 이타주의자는 어리석은 이타주의자보다 덜 이타적일지도 모르지만, 그들은 어리석은 이타주의자와 이기주의자보다 더 바람직한 존재다.
성공을 거둔 기버는 단순히 동료보다 더 이타적이기만 한 것이 아니라 그들 자신의 이익을 도모하는 데도 적극적이다.
성공한 기버는 테이커나 매처 못지않게 야심이 크다.
'이기심 없이' 베풀기만 하는 기버는 타인의 이익을 중요시하고 자신의 이익을 하찮게 여긴다. 이들은 결국 성공의 사다리 아래로 추락한다.
빌게이츠가 세계 경제포럼에서 '인간에게는 이기심과 타인을 보살피고자 하는 두 가지 강한 본성이 있다'라고 언급한 적 있는데, 그 두 가지 동력이 뒤섞인 사람이 가장 큰 성공을 거둔다.
자신의 이익과 타인의 이익을 상충하는 것으로 보지 않을 수 있는 능력이 있다는 것은 축복받은 일이다. 이런 사람은 매우 드물다. 살면서 이런 사람이 주변에 있다면 절대 놓치지 마라. 언젠가 나도 그렇게 변할 수 있는 가능성을 만들어 줄 수 있는 사람이다.
많이 베푼다고 더 큰 보람을 느끼지는 않는다. 무엇이 되었든 '보상'이라고 느껴지는게 있어야 연료가 소진되지 않고 베풀 수 있다. 정말 헌신적인 사람들이 회사 생활을 힘들어하는 것이 이런 이유이다. 많은 회사의 보상은 돈으로 귀결되지만, 이는 대부분의 기버들에게는 큰 가치가 아니기 때문이다. 기버가 성공 할 수 있게 돕고 싶다면 그들이 생각하는 '보상'이 무엇인지 파악해야 한다. 보통은 그들의 행동 자체에 대하여 피드백을 주는 것만으로도 충분하다.
베푸는 과정에서 동정심을 지나치게 많이 표현하면 동정심 감퇴, 스트레스, 부담감 그리고 피로라고 표현 할 수 있는 '정신적 에너지 소진'이 발생 할 것 같지만, 실제로는 그렇지 않다. 오히려 도움을 필요로 하는 사람들을 효과적으로 도와주지 못한다고 생각할 때 소진된다.
일을 더 많이 하면서도 활력을 유지하는 모든 사람은 내가 하는 행동이 고객과 회사에 어떤 영향을 끼칠 수 있는지 이해하고, 그들의 성공과 만족을 위해 일한다는 것을 알고 있다. (책에서는 의사-환자의 관계로 설명함.)
직관적으로 생각하면 다소 이상하지만, 기버는 더 큰 영향력을 끼침으로써 더 많이 베풀면서도 에너지 소진을 피한다. 더 큰 영향력을 끼침으로써 그들의 성공을 위해 도움을 주고 있다는 것을 명확히 알고 있기 때문이다.

위 내용을 읽은 모임(?) 멤버들의 반응

코틀린의 null 값에 대한 고찰

Sat, 01 Feb 2025 10:10:48 GMT

원문 상황

OP가 제기한 상황:

Kotlin에서 null을 다룰 때 어떤 방식이 가장 좋은지에 대한 고민
특히 여러 개의 nullable 값들을 처리할 때 코드가 지저분해지는 문제 제기
실제 코드에서 많은 ?.와 ?:가 반복되는 상황
그렇기에 nullable var 보다 lateinit var를 더 선호함.

제안된 해결 방식들

1. Scope Functions 활용

// Before
if (user?.address?.city?.zipCode != null) {
    processZipCode(user.address.city.zipCode)
}

// After
user?.address?.city?.zipCode?.let { 
    processZipCode(it)
}

2. Early Return 패턴

fun processUser(user: User?) {
    // Early return for null cases
    if (user == null) return
    if (user.address == null) return
    
    // Main logic with non-null values
    processAddress(user.address)
}

3. Elvis 연산자와 기본값 활용

val cityName = user?.address?.city?.name ?: "Unknown City"

4. Sealed Class/Interface 활용

sealed interface Result<out T> {
    data class Success<T>(val data: T) : Result<T>
    data class Error(val message: String) : Result<Nothing>
}

fun getUser(): Result<User> {
    return try {
        Result.Success(fetchUser())
    } catch (e: Exception) {
        Result.Error("Failed to fetch user")
    }
}

Real-world use cases

Interview with a Backend Engineer Working with Kotlin Spring Boot. Here's how they handle null values in their production environment:

1. Domain Layer Pattern

data class UserProfile(
    val name: String,
    val email: String?,
    val phoneNumber: String?
) {
    fun hasValidContact() = !email.isNullOrBlank() || !phoneNumber.isNullOrBlank()
    
    fun getPrimaryContact() = email ?: phoneNumber ?: throw IllegalStateException("No contact available")
}

2. Repository Layer Implementation

interface UserRepository {
    fun findByEmail(email: String): User?
    
    fun getByEmail(email: String): User = 
        findByEmail(email) ?: throw NoSuchElementException("User not found")
}

3. Service Layer Pattern

@Service
class UserService(private val repository: UserRepository) {
    fun processUserData(email: String): UserDTO {
        return repository.findByEmail(email)
            ?.let { user -> UserDTO.fromEntity(user) }
            ?: throw NotFoundException("User not found with email: $email")
    }
}

They emphasized three key aspects of their approach:

Clear Separation of Concerns
- Repository layer handles raw null values
- Service layer converts nulls to domain-specific exceptions
- Controllers handle theses exception uniformly
Consistent Error Handling
- Using custom exceptions for domain-specific cases
- Maintaining a global exception handler
- Proper error logging and monitoring
Testing Strategy
- Extensive testing of null scenarios
- Property-based testing for nullable fields
- Integration tests for the full null-handling flow

My Thoughts

As a backend engineer working with Kotlin and Spring Boot, I find Kotlin's null handling mechanism both elegant and sometimes challenging. Coming from a Java background, Kotlin's null safety might initially feel cumbersome, but it's actually a powerful feature that prevents many runtime errors we used to face in Java.

On comment from the Reddit discussion particularly resonated with me:

"lateinit var is just Kotlin's way of saying 'let me do it Java style'. Don't use it except when your injection framework needs it."

This perspective brilliantly captures a common anti-pattern in Kotlin development. While lateinit var is necessary for framework-level integrations (particularly with Spring's dependency injection, ORM's field injection), overusing it often indicates that we're not fully embracing Kotlin's idioms. It's a reminder that we should strive to use Kotlin's null safety features rather than falling back to Java-style patterns out of habit.

A critical point worth mentioning is that even with Kotlin's robust null safety system, we can still encounter NullPointerExceptions at runtime when dealing with reflection or proxy-based operations. This is particularly relevant in Spring Boot applications where properties marked as non-null in Kotlin code might still receive null values through reflection or proxy mechanisms. This reminds us that while Kotlin's type system is powerful, we need to remain vigilant about the framework's behavior under the hood.

For example:

@Service
class UserService {
    // Marked non-null in Kotlin, but could be null at runtime
    @Value("\${app.someProperty}")
    private lateinit var someProperty: String
    
    // Could throw NPE if property is not defined in application.properties
    fun processProperty() = someProperty.length
}

/**
* or when working with JPA entities where a `@ManyToOne` relationship is marked
* as non-null but the referenced entity doesn't exist in the database
*/
@Entity
@Table(name = "...")
class UserJpaEntity(
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "memberId")
    val member: MemberJpaEntity
)

What fascinates me most is how Kotlin's null safety influences architectural decisions. In my experience, it encourages:

More thoughtful API design
- Forces thoughtful API design
- Leads to more explicit contract between layers
- Results in more maintainable codebase
Better domain modeling
- Instead of using null for optional values, we often create more explicit domain concepts
- Helps in making implicit business rules explicit in code
- Reduces the complexity of null checking chains
Improved testing practices
- Null cases are more visible and thus better tested
- Compile-time null checks reduce the need for null-related unit tests
- Make edge cases more apparent during code review

The discussion on Reddit shows that the community is actively thinking about theses patterns. While there's no one-size-fits-all-solutions, the combination of Kotlin's null safety features with well-thought-out architectural patterns can lead to more robust applications.

Have you faced similar challenges with null handling in you Kotlin projects? How do you balance between null safety and code readability? I'd love to hear your thoughts and experiences!

동시성 패턴: Fail-fast와 Single Flight 패턴 비교

Fri, 31 Jan 2025 02:58:12 GMT

원문 상황

OP가 설명한 상황: 동일 메소드에 대한 여러 비동기 요청이 있을때, 이미 다른 비동기 요청에 의해 처리중이라면, 다시 내부 로직을 수행하지 않고 다른 요청의 처리 결과를 기다렸다가 사용하고 싶음.
예시: 한번 호출 할 때 마다 비용이 발생하는 외부 API를 호출하는데, 같은 식별자(key)로 여러 요청이 들어오면 기존 요청의 처리 결과를 기다렸다가 사용

제안된 해결 방식들

1. Structured Concurrency 활용

coroutineScope 사용: all-or-nothing 방식으로 동작.
- 하나의 자식 코루틴이 실패하면 모든 자식 코루틴을 즉시 취소함.
- 실패를 상위로 전파하며, 트랜잭션과 같은 원자적 작업에 적합함.
supervisorScope와는 차이점이 있음: 각 자식 코루틴이 독립적으로 동작함.
- 실패를 격리시키고 부분적 실패를 허용함.
- 독립적인 작업들을 실행할 때 적합함.

2. Single Flight 패턴

동일한 작업이 동시에 요청될 때 중복 실행을 방지
첫 번째 요청만 실제로 실행하고 나머지는 그 결과를 공유
실제 사용 사례:
- 캐시가 없을 때 여러 요청이 동시에 들어오는 상황
- API 호출 중복 방지
- 리소스 낭비 방지
Reference: Golang의 singleflight

Conclusion

This discussion covers two important concurrency patterns in Programming(e.g. Kotlin):

The fail-fast pattern using coroutineScope, which cancels all operations when one fails
The Single Flight pattern, which deduplicates concurrent requests for the same operation

While they serve different purposes:

Fail-fast focuses on error propagation and maintaining consistency
Single Flight optimizes resource usage by preventing duplicate operations

Both patterns are valuable tools in building robust concurrent systems with Kotlin.

Real-world use cases

Interview with a Server Engineer Working on Live Streaming Applications.

Here's how they optimized their microservices architecture:

Single-flight Implementation at Aggregator Level

They implemented a single-flight pattern at the aggregator level where requests expecting the same result share one response using the same key. This means:

When the aggregator receives requests, it groups identical requests using single-flight
Only one actual request is made to downstream services for each group
The same response is shared across all grouped requests.

Performance Benefits

This implementation resulted in significant performance improvements:

Reduced load on downstream services
Improved aggregator performance by:
- Eliminating redundant kernel-level I/O operations
- Reducing memory copy operations

Additional Optimization with Rueidis

They further optimized the system using Rueidis, which provides server-assisted client-side caching in Go.

Current Architecture

Their architecture flows as follows:

AWS CloudFront -> Aggregator -> Service

Multiple Layers of Optimization

The system benefits from multiple optimization layers.

First single-flight filter at CloudFront
Second single flight filter at Aggregator
Client-side caching reducing service requests

Redis Load Reduction

This multi-layered approach significantly reduces Redis load:

Traditional flow: Aggregator -> Service -> Redis
Redis, being single-threaded, benefits significantly from reduced read operations
Client-side caching further reduces the need for Redis reads

The combination of single-flight at both CloudFront and Aggregator levels, plus client-side caching, has resulted in a substantial reduction in service requests and overall Redis load, creating a more efficient and performant system.

Important Consideration for Single-flight

They noted a critical consideration when implementing single-flight, particularly in Go:

If single-flight instances aren't separated by routes, the locking mechanism (which occurs for every request) can become a bottleneck. This is a characteristic specific to Go's implementation of single-flight, and the behavior might differ in other programming languages.
The combination of single-flight at both CloudFront and Aggregator levels, plus client-side caching, has resulted in a substantial reduction in service requests and overall Redis load, creating a more efficient and performant system.

My Thoughts

As a backend engineering, I find this discussion particularly relevant since it addresses a common business scenario we often encounter. When multiple clients requests the same resource simultaneously (e.g. fetching user profiles or processing payment transactions), we need to carefully handle these concurrent requests to optimize system resources and maintain data consistency.

What fascinates me is how Golang has built-in support for this pattern through their singleflight package. It shows that this concurrency pattern is so commonly needed that they decided to provide it at the language ecosystem level. This makes me wonder why other languages haven't adopted similar built-in solutions.

In my experience with Kotlin and Spring Boot, we often have to implement this pattern ourselves or rely on caching mechanisms. While these solutions work, having a standardized approach like Go's would be beneficial for consistency across different projects and team.

While this pattern might not be 100% applicable in distributed environments with multiple instances, having it as part of the ecosystem provides valuable insights into solving concurrency challenges. Without exploring Go or studying various concurrency patterns, I might never have discovered this elegant approach to handling duplicate requests.

Have you encountered similar concurrency challenges in your project? How did you handle them?

인터넷에서 상대방을 추적하는 혁신적인 방법

Wed, 22 Jan 2025 14:55:30 GMT

데스노트라는 일본 애니메이션을 본적 있는가? 안본 사람을 위해 대략 내용을 설명해주자면, 얼굴과 이름을 알고 있는 상태에서 작품명과 동일한 이름의 데스노트에 이름을 적으면 그 사람이 어디에 있든 사망에 이르게 할 수 있다는 컨셉을 지닌 애니메이션이다.

그리고 이 애니메이션의 초반에는 전세계에의 불특정 다수가 사망하는 것을 보고, 특정 단체의 소행이라 판단한채 범인을 검거하기 위해 추리를 펼치는 모습이 등장한다. 하지만 범인은 일본에 거주하는 평범한 학생이었다.(작품에서는 키라라는 별칭으로 불리운다.)

이때 작품에 등장하는 천재 명탐정(작품에서는 L이라는 이름으로 불리운다.)이 범인의 위치를 구체화 하기 위하여 구역을 나누고, 각 구역마다 방송을 송출하며 미끼를 던지는 모습이 등장한다. 이러한 방식은 범죄 수사에서 흔히 쓰이는데, 숨겨진 신원을 밝혀낸다는 의미에서 비익명화라고 부른다.

이제 우리에게는 익명이라는 개념이 너무 익숙하다. 인터넷 자체가 익명이기 때문이다. 인터넷을 이용하여 익명으로 여러 범죄가 이루어지고, 비밀이 오고간다.

최근 한 15세 해커가 흥미로운 연구 결과를 공개했다. 그는 Cloudflare라는 CDN 서비스의 특성을 이용해 Signal이나 Discord 같은 메신저 사용자의 위치를 추적할 수 있는 방법을 발견했다. 이 방법은 사용자의 어떤 조작도 필요 없이 약 400km 반경 내에서 위치를 특정할 수 있다고 한다.

공격 방법의 원리

이 공격의 핵심은 Cloudflare의 캐시 시스템에 있다. Cloudflare는 전 세계 330개 도시에 데이터센터를 두고 있으며, 사용자와 가까운 데이터센터에서 콘텐츠를 제공한다. 해커는 이 특성을 이용해 특정 콘텐츠가 어느 데이터센터에 캐시되었는지 추적함으로써 사용자의 대략적인 위치를 파악할 수 있었다.

Signal과 Discord의 취약점

Signal의 경우, 메시지에 첨부된 이미지나 파일이 Cloudflare CDN을 통해 전달된다. 사용자가 채팅방을 열거나 푸시 알림을 받을 때 이 파일들이 자동으로 다운로드되며, 이 과정에서 사용자의 위치 정보가 노출될 수 있다.

Discord도 비슷한 취약점을 가지고 있다. 특히 친구 요청을 보낼 때 프로필 이미지가 푸시 알림과 함께 전송되는데, 이 과정에서 위치 추적이 가능하다. 해커는 이를 자동화한 'GeoGuesser'라는 Discord 봇을 제작해 실제로 Discord CTO의 위치를 추적하는 데 성공했다.

보안 업체들의 반응

이 취약점이 공개된 후, 각 회사의 반응은 제각각이었다. Signal은 이를 자신들의 책임이 아니라며 사용자가 알아서 주의해야 한다는 입장을 보였다. Discord는 초기에는 수정을 약속했지만 나중에는 Cloudflare의 문제라고 입장을 바꿨다. Cloudflare는 결국 일부 취약점을 수정했지만, 근본적인 문제는 여전히 남아있다.

시사점

이 사례는 현대 인터넷 인프라의 복잡성과 그로 인한 예상치 못한 보안 위험을 보여준다. 특히 성능 향상을 위해 도입된 기술이 역설적으로 프라이버시를 위협할 수 있다는 점을 잘 보여준다.

개인의 프라이버시가 중요한 저널리스트, 활동가, 그리고 일반 사용자들은 이러한 위험을 인지하고 적절한 보호 조치를 취할 필요가 있다. VPN이나 Tor 같은 추가적인 보안 도구의 사용을 고려해볼 만하다.

전문: https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117

개발 조직에서의 리더 (부제: 다양한 문제해결 스타일)

Tue, 21 Jan 2025 01:04:54 GMT

리더는 어떤 사람일까? 리더는 변화를 이끌어 가는 사람이다. 그 변화는 다른 사람의 변화일 수도 있고, 팀의 변화일 수도 있으며, 조직 전체의 변화일 수도 있다. 그러나 무엇보다 우선, 리더는 자기 자신의 변화를 이끌어 가는 사람이다. 그리고 이러한 변화를 이끌어내는 방식은 리더마다 다양하다. 그 이유는 모든 사람이 유일한 존재이기 때문이다. 믿기지 않는다면 한 조직 안에 있는 두 명의 인물을 딱 10분만 관찰해 보자. 개인적으로 그리고 기술적으로 수십 가지 다른 리더십 행동을 찾아볼 수 있을 것이다.

그렇다면 각자의 리더십 스타일을 키워나가는 데 도움이 될만한, 일반적인 리더십이란 존재하지 않는걸까? 이 부분에 있어서는 나의 경험과 여러 사례를 통해 깨달은 MOI라는 모델에 대해 이야기 해보면 좋을 것 같다.

MOI 리더십 모델

변화를 만들어 내려면 환경은 반드시 다음 세 가지 구성 요소를 포함해야 한다.

M(Motivation; 동기부여): 위협하거나 보상하거나, 밀거나 당겨서 관련 있는 사람을 움직이도록 만드는 일
O(Organization; 조직화): 아이디어 실현이 가능하도록 만드는 구조
I(Idea; 아이디어, Innovation; 혁신): 씨앗, 실현될 것의 이미지

때론 변화를 저지하는 것도 리더십이라고 할 수 있다. 변화가 일어나는 것을 멈추게 하고 싶다면, 환경에 다음 세 가지 중 한 가지를 하면 된다.

M: 동기 제거 - 사람들에게 변화를 일으켜도 인정받을 수 없다고 느끼도록 만든다. 스스로 무언가를 할 필요를 느끼지 않도록, 자발적 동기를 통해 즐길 수 있는 모든 의욕을 꺾는다.
O: 혼란 조성 - 협력을 생각할 수 없을 만큼 심한 경쟁을 부추긴다. 자원은 최소한보다 아주 조금 부족한 상태를 유지한다. 보편적 가치가 있는 정보를 제한하거나, 의미 없는 말과 문서에 파묻히도록 한다.
I: 아이디어 흐름 억제 - 비판할 수 있는 상황이라면 다른 사람의 말을 듣지 않는다. 자신의 아이디어를 제일 큰 소리로 먼저 말하고, 의견을 제시하는 사람에게 불이익을 준다. 사람들이 함께 일하지 못하게 하고, 무엇보다도 웃음을 허용하지 않는다.

변화를 추구하는 경우에도, 반대로 변화를 저지하는 경우에도, MOI 모델은 리더십 스타일을 전반적으로 설명하는 모델이다.

개발 조직의 리더가 하는 일

개발 조직의 리더가 혁신을 강조하는 방법을 더 자세히 살펴보면, 다음 세 가지에 특히 노력한다는 사실을 알 수 있다.

문제를 이해하기
아이디어의 흐름을 관리하기
품질을 유지하기

이 세 가지가 문제 해결형 리더십의 특징적 구성 요소이며 이것이 바로 훌륭한 개발 조직 리더의 특징이다. 물론, 리더는 이 세 가지를 자신의 동기부여, 조직화, 혁신 능력에 따라 각자 서로 다른 방법으로 달성한다. 품질 향상을 목적으로 새로운 측정 도구를 도입하고자 하는 상황에서, 도구를 만드는 방법이 있고(I-전략), 도구를 사용하는 방법을 사람들에게 가르치고 사용하도록 설득하는 방법도 있으며(M-전략), 도구를 사용하는 사람들을 지원하는 체계를 만드는 방법도 있다.(O-전략).

문제 해결형 리더가 되기 위해서 갑자기 개종 수준의 변화가 필요한 것은 아니다. 단지 자신에게 어떤 전략이 부족한지 MOI의 목적과 수단을 조합하여 살펴본 다음, 한 번에 하나씩 부족한 부분을 채우면 된다. 새로운 방식에 각각 익숙해지면 또 다른 선택을 할 수 있게 되고, 문제 해결을 위해 환경에 긍정적 영향을 미칠 수 있는 기회가 늘어난다. 그리고 결국에는 팀이 더 생산적으로 바뀌는 놀라운 모습을 볼 수 있을 것이다.

문제 해결 스타일

앞서 훌륭한 개발 조직의 리더가 아래 세 가지에 특히 노력한다고 이야기 했다.

문제를 이해하기
아이디어의 흐름을 관리하기
품질을 유지하기

간혹, 주변 사람들이 나에게 개발을 잘 하는 사람들은 어떤 특징이 있나요?라던가 시니어 엔지니어가 되려면 어떻게 해야하나요?, 훌륭한 테크리더는 어떻게 될 수 있나요? 같은 질문을 하는 경우가 있다. 그때마다 한두가지의 특징을 말해주거나, 요행을 바라지 말라며 혼내기 바빴는데 이번 기회에 평소에 어렴풋이 인지하고 있던 생각을 위 세 가지 키워드를 중심으로 정리해보려 한다.

문제에 대한 이해

개발자들 중에는 아이디어에 푹 빠져 있지만, 자신의 일과 바깥 세상 사이의 연결 감각이 부족한 경우가 흔하다. 특히 눈앞에 닥친 문제를 이해하고 싶어 하지 않으며, 유일한 목표는 흥미로운 것을 탐색하는 일이다.

모든 구성원이 스스로 목표를 분명하게 이해하는 환경이라면, 위와 같은 팀원은 문제 해결형 팀에서 최고의 팀원이 될 수 있다. 그러나 환경적인 제한이 없다면 쓸모없는 시간만 보낼 뿐이고, 일은 우연에 의해서만 이루어진다. 모든 사람이 문제를 이해하는 환경을 만드는 데 도움을 주는 행동 중에서 우리가 흔히 볼 수 있는 것들은 구체적으로 다음과 같다.

고객의 문제를 매우 주의 깊게 이해한다. 성공과 실패가 사소한 문제 정의의 차이에 달려 있는 경우가 많다. 문제의 전체 개요를 파악할 필요도 있지만, 때로는 중요한 세부 사항 하나로 인해 큰 그림이 뒤바뀌기도 한다. 문제 해결형 리더는 이 사실을 잘 알기 때문에 세부 사항에 주의를 기울인다. 이와 반대로, 지금의 재미와 상황 면피만 추구하는 사람들은 괜찮은 해결책을 찾아내자마자 지루해하며 바로 다른 일을 하고 싶어 한다.

팀 동료들이 고객의 문제를 매우 주의 깊게 이해하도록 권장한다. 고객의 문제를 이해하는 것은 분명히 MOI 모델에서 I와 관련된 리더십이지만, 다른 사람들이 고객의 문제를 이해하도록 권장하는 것은 동기부여와 관련된 리더십이다.

원래 문제를 다시 참고함으로써 논쟁을 해결한다. 모든 팀원이 문제에 대한 이해를 공유하기 전까지 해결을 시도하는 것은 에너지 낭비일 뿐이다. 논쟁이 길어지는 이유는 대부분 서로 내세우는 해결책의 상대적인 가치가 다르기 때문이 아니라, 문제에 대한 이해가 지나치게 다르기 때문이다. 문제 해결형 리더는 논쟁이 문제 정의의 차이점 때문인지 아니면 해결 방법의 차이점 때문인지 보여주는 신호를 읽을 수 있다.

고객에게 문제에 대한 설명과 추가 정보를 요청한다. 어떤 훌륭한 프로젝트라도 완벽하고 올바른 설명을 제시하는 경우는 없으며, 문서의 경우도 마찬가지다. 그러나 다른 사람들과 상호작용을 하지 않고 현재 알고 있는 사실에 빠져서 허우적대는 사람들이 있다. 때로는 사소한 상호작용이 정말 큰 차이를 만들기도 한다.

작업이 어느 정도 진행된 후 요구사항의 의미가 더욱 분명해졌을 때 고객의 문제를 다시 참조한다. 복잡한 문제를 처음부터 제대로 이해하는 경우는 거의 없지만, 이해하고 있다고 착각하는 경우는 많으며 그 착각은 재앙으로 가는 확실한 길이다. 그렇기 때문에 사람들에게 문제에 대해 끊임없이 다양한 가정을 하도록 권장해야 한다.

아이디어의 흐름 관리

아이디어는 문제 해결형 리더십의 핵심이며, 문제 정의에서 출발해 수준 높은 해결책에 도달하는 방법이다. 아이디어가 너무 적으면 해결책을 얻을 수 없고, 반대로 너무 많으면 혼란이 발생한다. 아이디어의 흐름을 관리하는 리더십이 없는 경우, 같은 공간에 두 명의 기술 전문가가 모이면 논쟁을 하고, 세 명이 모이면 오합지졸이 되며, 네 명이 모이면 난장판이 된다. 아이디어를 효과적으로 관리하면, 몇 명이 모이든 성공하는 문제 해결형 팀이 될 수 있다. 다음은 문제 해결형 리더가 아이디어의 흐름을 관리하기 위해 사용하는 12가지 대표적 행동이다.

팀에 좋은 아이디어를 제공한다. 새로운 아이디어가 치명적 결과를 초래하는 경우도 있긴 하지만, 좋은 아이디어를 제공하는 것은 가장 확실한 리더십 행동이다. 그러나 사실, 정말로 새로운 아이디어는 매우 드물다. 예를 들자면, 컴퓨터 소프트웨어 분야에서 새로운 아이디어 대부분은 이미 100여 년 전에 제시된 것들이다. 좋은 아이디어보다 더 중요한 것은 문제 해결에 적합한 아이디어가 등장했을 때 그 아이디어를 인식할 수 있는 환경을 만드는 일이다.

유용한 아이디어를 모방하도록 권장한다. 인정하기 싫은 사람도 있겠지만 문제 해결형 리더는 상습 모방자이다. 그중에서도 최고로 뛰어난 사람은 자신이 모방자라는 사실을 인정할 뿐 아니라 모방을 예술의 경지까지 끌어올린다. 문제 해결형 리더는 항상 사용할 만한 아이디어를 찾기 위해 다른 분야를 탐색한다. 문제 해결형 리더는 항상 사용할 만한 아이디어를 찾기 위해 다른 분야를 탐색한다. 어떤 설계가 이미 존재하는지, 다른 상황에도 적용 가능한지 알고 있다. 문제 해결형 리더는 자신이나 누군가 다른 사람이 이미 훌륭하게 해낸 일을 단순히 반복하는 일에는 별로 관심이 없다.

팀 동료의 아이디어를 발전시킨다. 처음부터 완벽한 아이디어는 존재하지 않는다. 심지어 모방한 아이디어라고 해도 새로운 환경에 맞게 조정해야 한다. 대부분의 문제 해결형 리더는 아이디어를 제시할 때 보다 아이디어를 완벽하게 다듬는 데 100배는 더 많은 에너지를 사용한다. 에디슨이 "천재는 1%의 영감과 99%의 노력으로 이루어진다."라고 말한 것이 그러한 의미다.

팀이 추구하는 아이디어를 위해 누군가의 아이디어를 포기한다. 다만, 모든 사람이 이해하기 전에는 어떤 아이디어도 포기하지 말아야 한다. 이것은 복잡한 문제를 해결하는 조화에 대한 이야기이다. 규모가 큰 문제를 해결하려면 많은 사람들이 조화롭게 노력해야 한다. 그러나 팀워크의 필요성을 강조하다 보면 다수의 의견에 동의해야만 하는 강력한 압박이 발생하며, 다수가 잘못된 아이디어를 떨쳐 버리지 못한다면 재앙이 될 수 있다. 자신의 아이디어를 모두 포기하거나 하나도 포기하지 않는 것은 상대적으로 쉽다. 어려운 것은 균형을 잡는 것이다. 즉, 자기 주장을 고집하다 그 아이디어를 포기하거나, 다른 사람들이 치명적 실수를 할 것 같은 상황에서 자신의 고수하는 것은 쉬운 일이 아니다. 이는 우리 회사의 인재상 중 하나인, Strong opinions, weakly held와도 맥락이 일치한다.

시간의 압박에 굴복하지 않고, 다른 사람의 아이디어에 귀를 기울이는 시간을 갖는다. 시간의 압박을 받는 경우에는 대부분의 아이디어를 제대로 이해하기도 전에 포기한다. 비록 그 아이디어들 중 일부는 별 볼 일 없는 것이라서 이해하는 데 드는 많은 시간을 절약할 수 있기도 하다. 그렇더라도 사람들은 자신의 아이디어가 부당하게 버려지면 열의를 잃어버리기 마련이다. 아이디어를 적용할 수 없다는 사실이 밝혀져도, 사람들이 모든 아이디어에 귀 기울이는 환경에서 프로젝트는 결과적으로 더 빠르게 진행된다.

다른 사람들의 아이디어를 테스트한다. 특정 상황만 고려한다면, 대부분의 아이디어는 유용하지 못할 것이다. 과연 유용한 아이디어란 무엇일까? 전세계적으로 유명한 회사들은 자체적으로 큰 기술개발 연구소를 운영하고 있지만 연구소 자체 연구를 통해 탄생한 제품은 거의 없다. 연구원들의 중요한 업무는 자기 분야의 신 개발품을 지속적으로 연구해서, 어떤 개발이 회사에 잠재적 이익을 가져다 줄 것인지 비판적으로 분석하는 것이다. 좋은 아이디어가 나오면, 그들은 그 아이디어를 재빠르게 포착해 더 발전시킬 준비가 되어 있다.

아이디어의 흐름을 유지하기 위해 팀 동료의 아이디어를 즉각 비판하지 않는다. 아이디어를 테스트하는 것은 중요한 일이지만, 고민할 만한 가치가 없는 아이디어는 없다. 아이디어를 비판하는 것과 즉각 비판하는 것은 전혀 다른 문제이다. 큰 규모의 회사는 더 작은 회사가 실제로 아이디어를 적용할 수 있다는 것을 증명할 때까지 중요한 아이디어를 여러 차례 받아들이지 않는 일이 흔하다. 스타트업에서 혁신적인 주장을 하더라도 대기업에선 크게 반응하지 않는게 대표적인 사례다. 그러다 스타트업의 주장이 유의미하다고 판단되는 시점에는 직접 시장에 뛰어들곤 한다.

아이디어를 비판할 때는, 그 아이디어를 제시한 사람이 아니라 아이디어 자체를 비판하고 있다는 것을 명확히 안다. 문제 해결형 리더는 모든 아이디어가 모든 문제에 유용한 것은 아니라는 사실을 잘 알고 있지만, 사람은 모두가 유용한 존재라는 사실을 더욱 잘 알고 있다. 그건 바보 같은 생각이야라거나 절대 그럴 리 없어 같은 말을 하면 사람들이 더 이상 아이디어를 내지 않게 된다는 것을 알고 있기 때문에, 비판을 할 때 신중한 방법을 사용한다. 이것은 단어 선택에 주의를 기울여서, 사람이 아닌 아이디어에 대해서만 비판한다는 것을 의미한다.

자신의 아이디어를 팀에 제시하기 전에 먼저 테스트한다. 문제 해결형 리더라고 할 때 사람들이 흔히 떠올리는 이미지는, 영리한 젊은이가 분당 200단어 속도로 똑똑하고 신선한 아이디어를 마구 쏟아내는 모습일 것이다. 영향을 주는 행동의 숫자를 세어 점수를 매겨서 리더십을 측정한다면 그런 사람들이 높은 점수를 받을 수 있겠지만, 그들이 진짜 문제 해결형 리더인 경우는 드물다. 오히려 그와 반대인 경우가 많다. 왜 그렇게 말을 많이 하는지 물어보면, 이 수다쟁이들은 이렇게 이야기하곤 한다. "글쎄요. 다른 사람들이 아무 아이디어도 내지 않고 있거든요." 이 말은 헛소리다. 좋은 아이디어를 전부 혼자 낼 만큼 똑똑한 사람은 없으며, 자신의 경솔한 아이디어를 끊임없이 내뱉는 것은 다른 사람들의 아이디어를 억누르는 효과적인 방법이다.

시간과 인력이 부족해지면, 새로운 아이디어를 멈추고 행동에 옮긴다. 모든 프로젝트는 언젠가 실제로 일을 시작해야 하는 때가 온다. 그때까지 아이디어가 충분하지 않더라도, 어쨌든 프로젝트는 완료해야 하기 때문이다. 리더가 되기를 원하는 사람들 중 일부는 단순하게 구현하는 일 따위는 할 수 없다고 스스로를 과대평가 한다. 그러나 이 세상의 모든걸 창조했다는, 하나님 조차도 천지창조 6일 후에는 새로운 생명체를 생각해 내는 일을 그만두었다. (참고로 이 글을 쓰는 나는, 종교적인건 전혀 모른다.)

팀 구성원들에게 예전에는 성공을 거두었지만 새로운 상황에는 맞지 않는 아이디어를 버리도록 권장한다. 나쁜 아이디어라도 포기하기란 어려운 일이다. 하물며 좋은 아이디어를 버린다는 것은 더욱 어려운 일이다. 하지만 대단한 아이디어라고 하더라도 한계가 있기 마련이다.

포기한 아이디어라 하더라도 나중에 다른 문제를 해결하는 데 가치가 있다면 다시 활용한다. 사실 나쁜 아이디어는 없다. 단지 적합하지 않은 아이디어가 있을 뿐이다. 범선은 증기선에 밀려 자취를 감추었지만 에너지 비용이 증가하자 다시 제작되고 있다. 옛 아이디어가 사라져 버리는 것은 아니다. 문제 해결형 리더는 기억력이 뛰어나지만 적기를 포착하는 능력은 더 뛰어나다.

품질 제어

누군가는 열심히 한다면 성공할 수 있을 것이라고 말한다. 하지만 그것은 목표가 없기 때문에 품질을 측정할 수 없는 상태와 같다. 일단 목표를 정의하고 받아들이면, 문제 해결형 리더는 결함이 있는 해결책을 받아들이려 하지 않을 것이다. 다음과 같은 행동을 통해 품질을 위한 환경을 제어한다.

프로젝트를 진행하면서 품질을 측정한다. 고객의 요구사항을 재검토하는 능력이 품질에 대해 타협하는 능력을 의미하지는 않는다. 문제를 이해하는 능력은 실제로 요구사항을 구현하는 데 도움이 될 뿐이다. 위대한 요시라들은 요리를 만들면서 맛을 보고, 효과적인 문제 해결형 리더는 결코 품질에 대해 타협하지 않는다. 주어진 문제가 해결할 필요가 없다면 문제가 중요하지 않다는 사실을 인식한다.

해결책을 만들어 내기 위해 품질을 측정하는 도구와 프로세스를 설계한다. 제조업에서는 일정이나 요구사항이 우연히 충족되지는 않는다. 사람들에게 더 열심히 일하라고 이야기해서 충족되는 것도 아니다. 첨단 기술 산업에서는 구현 프로세스가 첨단 기술 제품 그 자체라고 할 수 있으며, 최고의 문제 해결형 리더십이 요구된다. 프로젝트를 진행하는 동안 실제 진행 상황과 품질을 측정하는 일이 때로는 낭비로 여겨지기도 하지만, 좋은 도구는 자연스럽게 품질을 제어할 수 있는 환경을 만들어 낸다.

구현 속도를 측정하고 일정과 비교하여 해결 방법의 변경을 대비한다. 업무를 완수하는 시간은 항상 요구사항의 일부이며, 원래 요구사항 대비 실제 진행 상황을 항상 비교해야 한다. 지연되고 있음에도 해결 방법을 변경하는 것이 두려워 몇 달 늦게 시장에 진입했기 때문에 사업에 실패한 첨단 기술 회사가 무수히 많다.

프로젝트에서 한 걸음 물러나서 실행 가능성을 새로운 관점에서 바라보고 평가한다. 때로는 지금 하고 있는 일을 새로운 관점으로 바라보는 것이 제일 좋은 측정 도구가 되기도 한다. 소프트웨어 업계에서는 구현이 시작된 모든 프로젝트의 반 이상이 제품을 출시하지 못한 채 취소된다. 불운한 프로젝트를 더 일찍 취소할수록 더 많은 비용을 절약할 수 있다. 문제 해결형 리더는 프로젝트가 가망이 없다는 것을 알아차리는 것뿐만 아니라 다른 사람들이 희망 없는 명분에 더 많은 노력을 쏟기 전에 그 사실을 받아들이도록 설득할 수 있어야 한다.

아이디어를 구현하기 전에 고객과 함께 검토한다. 문제 해결형 리더의 대중적인 이미지는 고독한 천재이지만, 진짜 리더는 성공을 만들어내는 것을 더 선호한다. 고객이 항상 옳지는 않지만 비용을 지불하는 사람은 고객이며, 리더는 고객이 비용을 지불하지 않는다면 그것은 성공이 아니라는 것을 잘 알고 있다. 만약 리더가 고객과 함께 계속해서 아이디얼르 검토할 수 있는 방법을 마련한다면 프로젝트를 취소하는 비율은 훨씬 더 줄어들 것이다.

아이디어가 실패했을 때에도 의욕을 잃지 않는다. 문제 해결형 리더는 실패를 쉽게 받아들이지 않으며 차질이 빋어진 경우에도 일이 멈추지 않도록 하는 방법을 알고 있다. 특히 헌신적인 동료가 그 차질을 개인적 비극으로 생각할 때 더욱 그러하다. 하지만 훌륭한 리더는 실패를 아무런 성과도 없는 아이디어의 속박으로부터 풀려나도록 하며, 아이디어의 순환을 새롭게 하고, 프로세스를 이전보다 더욱 생산적으로 만드는 계기로 삼는다.

질문

긴 글을 통해, 23개의 문제 해결 스타일에 대해 정리해보았다.

당신은 이 중 어떤 부분에 강점을 가지고 있는가?
내가 리더십을 발휘하고 있는 방식들은 이 중 무엇인가?
전반적으로, 문제 해결형 리더로서 자신의 스타일을 강화하려면 어떤 새로운 행동을 연습할 필요가 있을까?

위 질문을 받고 부족한 부분이 많지만, 나는 아직 리더가 되기엔 멀었으니 괜찮아.라고 말하는 사람이 있다면, 명심하라. 리더는 조직에서 임명된 리더만 있는 것이 아니라, 그 조직의 변화를 만들어내는 모든 사람을 의미한다.

위 내용은 제럴드 와인버그의 테크니컬 리더의 내용과 나의 경험을 일부 섞어 작성하였으니, 더 깊은 내용이 궁금하다면 책을 한번 읽어보는걸 추천한다.

평범한 결혼생활 - 임경선 / 별점 3.0

Wed, 18 Sep 2024 04:23:18 GMT

https://flybook.page.link/1PAsTRgRNTBFdm4f9

20년간 이어온 결혼 생활을 담백하게 그린 에세이. 작가는 결혼을 '연극'에 비유하지만, 그 속에서 부부간의 깊은 애정이 은근히 묻어난다. 겉으로 드러나지 않는 비언어적 소통을 통해 서로를 향한 사랑이 느껴진다.

티몬·위메프 사태로 알아보는 흑자도산

Thu, 01 Aug 2024 13:37:49 GMT

일반적으로 기업의 도산은 경영 부진으로 적자가 과도하게 발생할 때 일어난다. 도산의 원인으로는 원자재 가격과 근로자의 임금 상승으로 인한 수익 감소, 잘못된 경기 예측으로 인한 투자 실패 등을 들 수 있다.

하지만 일반적인 기업의 도산과는 달리, 흑자도산은 재무제표상으로는 문제가 없어 보이지만 자금의 흐름이 원활하지 않아 도산하는 경우를 말한다. 다시 말해, 장부상으로는 흑자일지라도 현재 융통할 수 있는 자금이 부족해 대출 이자를 상환하지 못하거나 거래처에 대금을 납부하지 못하면 도산에 이를 수 있다.

티몬·위메프 사태

최근 큐텐 계열사인 티몬·위메프의 미정산 사태가 발생해 큰 논란이 되고 있다. 이 사태의 여파는 같은 큐텐 계열사인 인터파크커머스와 에이케이(AK)몰까지 확산되어 더 많은 피해를 초래하고 있다. 왜 이런 사태가 발생했을까?

정확한 원인은 아직 조사 중이라 추측할 수 밖에 없으나, 근본적으로는 커머스 플랫폼이 해당 플랫폼에 입점한 셀러들에게 정산해 주어야 하는 자금이 고갈된 것이 문제의 원인이다. 만약 이 자금을 적절히 관리했다면 지금의 사태까지는 확산되지 않았을 것이다.

이를 보다 잘 이해하기 위해선 먼저 커머스 플랫폼의 정산 구조를 살펴볼 필요가 있다.

구매자: 커머스 플랫폼에서 물품 주문/결제 (PG 이용)
셀러: 구매자의 주문/결제를 확인하고 물품 배송
커머스 플랫폼: 구매자와 셀러를 연결해주고, PG로부터 정산받은 구매 대금을 셀러에게 정산

즉, 자금의 흐름이 구매자 -> PG -> 커머스 플랫폼 -> 셀러로 이동하는 구조이다. PG에서 커머스 플랫폼으로, 커머스 플랫폼에서 셀러로 자금이 이동할 때는 통상적으로 일정 기간이 소요되며, 서비스 이용 수수료를 제외한 자금이 전달된다.

그러다 보니 셀러에게 정산해 주기 전 일정 기간은 거래 대금 전체를 커머스 플랫폼이 가지고 있게 되고, 이 돈을 부동산에 투자하거나 대출을 상환하는 데 사용하는 경우가 발생하곤 한다. 법률상 이러한 행위를 제약하고 있지는 않기에 법적으로 문제가 되지는 않는다.

다만, 그 투자가 실패하거나 다음 달 거래금액이 감소하여 정산 시점에 지급해 줄 돈이 부족해지면 정산이 지연되고, 미래에도 돈을 받지 못할 것을 예상한 셀러들이 구매자에게 물품을 배송하지 않는 사태까지 발생할 수 있다. 즉, 정산 대금 돌려막기에 실패하면 문제가 커지는 것이다.

비슷한 듯 다른 B2C 거래와 B2B 거래

티몬·위메프 사태는 PG와 플랫폼을 통하는 기업과 개인 간 거래 구조(B2C)를 보여준다. 이러한 기업과 개인 간 거래가 아닌, 기업과 기업의 거래(B2B)에서도 흥미로운 부분이 많다.

기업 간 거래 중 상당수는 카드 결제가 아닌 현금 결제로 이루어진다. 여러 이유가 있을 수 있지만 거래 대금을 정산받는 데 시간이 소요되기도 하고 무엇보다 수수료가 발생한다는 점이 치명적이다.

또한 기업은 돈을 사용하거나 받을 때, 어떤 이유로 사용했고 받았는지 증빙을 남겨야 한다. 그래야 횡령을 비롯한 금융 사고를 예방하고 사유에 따른 적절한 세금을 부과할 수 있기 때문이다. 그렇다면 현금을 주고받을 때 증빙은 어떻게 남기는 걸까? 예전에는 '세금계산서'라는 이름의 종이 문서를 작성하고 날인하여 국세청에 직접 신고하는 방식이 널리 이용되었다.

하지만 오프라인으로 문서를 관리하고 이를 다시 국세청에서 집계하는 과정이 매우 번거롭고, 누락되거나 오기재되어 잘못 처리되는 등 여러 가지 문제로 인해 점차 전산화되며 '전자세금계산서'가 등장하게 되었다. 현시점에는 상당수 기업 간 현금 거래가 '전자세금계산서'를 기반으로 이루어진다.

전자세금계산서 기반 기업 간 거래

전자세금계산서는 용역이나 재화를 공급하는 기업이 그 재화를 공급받는 기업에 발행하게 된다.

즉, 돈을 받는 기업이 돈을 지급하는 기업에 발행하는 구조이다. 이러한 구조로 인해 이를 '보낸 세금계산서'나 '매출 세금계산서'라고 부르기도 하며, 반대로는 '받은 세금계산서'와 '매입 세금계산서'라고 부르곤 한다.

여기서 또 하나 재미있는 점이 있다. 만약 돈을 이체하였는데, 상대방의 실수나 착오로 인하여 세금계산서가 잘못 발행되거나 발행되지 않는다면 어떻게 될까? 전산상으로는 기업의 자금이 외부로 이체되었으나, 왜 이체하였는지에 대한 증빙 없는 출금 내역이 생기게 된다.

당연하게도 이런 출금 내역은 존재해서는 안 된다. 이러한 문제점 때문에 기업 간 거래는 대부분 전자세금계산서를 먼저 발행하고, 그 후 이체하는 방식으로 이루어진다. 하지만 이 방식도 전자세금계산서만 발행되고 이체되지 않거나 잘못 이체되는 문제가 생기곤 한다. 그럼에도 증빙 없는 출금이 발생하는 것 보다는 세무/회계적으로 처리하기에 용이하기 때문에 이러한 방식이 널리 사용되고 있다.

흑자도산

위에서 설명한 두 종류의 거래 구조로 인하여 흑자도산이 발생할 수 있다.

플랫폼을 이용한 기업과 개인 간 거래 : 신용카드 매출은 신고되었으나 플랫폼으로부터 정산받지 못하여 흑자도산
전자세금계산서 기반 기업 간 거래 : 전자세금계산서를 발행하였으나 거래처로부터 대금을 지급받지 못하여 흑자도산

이 중 전자세금계산서 기반 기업 간 거래의 경우, 거래를 증빙하는 전자세금계산서가 발행되었기 때문에 재무제표상 매출이 존재하지만, 실제로는 대금을 지급받지 못해 현금 흐름이 막히는 현상을 겪게 된다.

이렇게 현금 흐름이 막힌 기업에게 돈을 받아야 하는 다른 기업이 있다면 대출을 받게 되고, 대출의 규모가 커져 자본 잠식 상태에 빠지게 되면 줄줄이 현금 흐름이 막히고 연쇄적으로 파산하는 사태가 벌어지게 된다. 1997년 IMF 구제금융 요청 시기에 여러 기업이 줄도산한 것과 비슷한 현상이다.

매출/매입 세금계산서 관리

이런 문제를 예방하기 위해 기업들은 매출 세금계산서와 입금 내역, 매입 세금계산서와 출금 내역을 매칭하여 관리하게 된다. 이 작업을 평소에 해두지 않으면 연말에 받지 못한 돈을 손실 처리하거나 아직 지급하지 않은 돈을 한꺼번에 지급하면서 뜻하지 않은 비용이 발생할 수 있기 때문이다. 생각보다 많은 기업이 이런 문제를 겪곤 한다.

이러한 문제를 해결하기 위해 볼타를 창업하게 되었고, 볼타에서는 아래와 같은 기능을 무료로 제공하고 있다.

매출 세금계산서 ↔︎ 입금 내역 매칭/관리
매입 세금계산서 ↔︎ 출금 내역 매칭/관리
지급요청(지출결의)

그 외에도 5초 만에 발행할 수 있는 세금계산서를 비롯한 기업 간 거래를 쉽게 만들기 위한 다양한 기능을 제공하고 있다. 이를 통해 모든 기업의 재무팀이 자금 상황에 대한 가시성을 높여 흑자도산과 같은 위험을 피하길 바란다.

볼타 팀은 앞으로도 재무팀이 더 건강한 비즈니스를 구축하는 데 도움을 주기 위해 노력하고자 한다. 모든 기능은 무료로 이용 해볼 수 있으니, 둘러보고 아직 볼타 팀이 해결하지 못한 문제가 있다면 주저 말고 말해달라.

용기 내어 말해준 고객은 '이제 볼타가 없으면 업무를 할 수 없게 되었다.', '볼타가 없으면 출근하고 싶지 않다.'라고 이야기하기도 한다.

볼타 기능 둘러보기: https://bolta.io
고객 사례 둘러보기: https://bolta.io/customer-story

조직이 커지면서 발생하는 문제

Fri, 26 Jul 2024 00:15:49 GMT

3명밖에 없던 팀이 10명, 50명, 100명이 되다 보면 많은 문제가 발생하곤 한다.

업무는 적당히 분업화되었지만 서로 간 소통의 부재가 생기고, 소통이 없으니 자연스레 이슈가 제대로 공유되지 않는다. 엎친 데 덮친 격으로 초기 구성원과 신규 구성원 간 불화가 생기는 경우도 있다. 그러다 오랜 시간 함께했던 창업 멤버가 퇴사를 결정하면서 불화의 고리는 걷잡을 수 없게 된다.

이런 문제는 왜 생길까

조직이 커지면서 부서 간의 업무 분장이 명확해지는 것이 가장 중요한 원인이다. 업무 중요도와 관계없이 애매한 업무로 인해 부서 간 이기주의가 발생한다.

그리고 조직 내에 이런 이야기가 떠돌게 된다.

우리 제품은 장애가 왜 이렇게 자주 발생할까?
1년 전 고객 컴플레인은 왜 아직도 해결되지 않고 있는 걸까?
개발자는 뭘 하고 있는 걸까?

일을 하다 보면 서로의 의견 개진을 위해 목소리를 높이고 토론하는 것은 흔히 있는 일이지만 그 내용을 들여다보니 각자 다른 팀에 책임을 전가하는 발언만 내세우곤 한다. 이런 현상이 지속된다면 각 부서의 독단적인 행동을 부추기게 되고 기업 전체의 성과보다 자신이 속한 부서의 성과 극대화에만 열을 올리는 기업문화가 나타난다.

결국에는 각 부서 간 소통 부재로 인해 제품 품질 저하로 이어지고, 고객 만족도가 하락함에 따라 비즈니스 성장이 정체되거나 역성장하기도 한다.

과거를 돌이켜보며

경험상 내가 크게 노력하지 않아도 모든 구성원이 어떤 일을 하고 있는지 가시적으로 보이는 규모가 가장 재미있었던 것 같다. 최대치는 대략 20명 정도 규모인듯하다.

회사 전체가 20명 미만이라면 회사 전체가 어떻게 돌아가는지 한눈에 보이고, 내가 하는 일이 회사에 영향을 주고 있다는 게 명확히 보인다.

반면 회사 전체 인원은 훨씬 많지만, 팀이 10명~20명인 경우 회사 전체를 보는게 쉽지 않다. 자연스레 내가 속한 부서의 업무만 신경 쓰게 된다.

큰 조직과 작은 조직 모두 장단점이 있다. 중요한 것은 내가 지금 어떤 경험을 하고 싶은가?이다. 두 유형의 조직을 모두 경험해 본 결과 나와 더 맞는 경험은 작은 조직에서 전체를 보고 전체에 영향을 주는 경험이었다.

그 외에도 작은 조직에는 다양한 장점이 있다. 사례를 기반으로 이야기해주는 책; Company of One: Why Staying Small Is the Next Big Thing for Business이 있으니 관심있다면 읽어보길 추천한다.

PM은 무얼 하는 사람?

Mon, 22 Jul 2024 14:15:09 GMT

Job Title이 PM이라고 해서 다 같은 PM은 아니다

일반적으로 PM이 하는 일은 두 가지로 나누어 볼 수 있다.

기능을 만들고 출시하기를 목표로 하는 PM
제품 성공시키기를 목표로 하는 PM

기능 출시가 목표인 PM

경영진에 의해 정해진 기능 개발 로드맵에 따라 프로젝트를 준비한다.
이해관계자들의 요구사항을 취합하고, 요구사항에 맞추어 기능을 기획한다.
프로젝트를 담당할 디자이너와 엔지니어를 할당받는다.
기획서를 완성해 디자이너와 엔지니어에게 전달(hand-off)한다.
프로젝트 일정 내에 요구사항에 맞추어 개발을 완료하도록 프로젝트를 관리한다.
기능을 완성해서 배포한다.
다음 프로젝트로 넘어간다.

PM이 하는 일에 대한 오해

'고객과 이해관계자들의 요구'를 충족하는 제품 만드는 사람
이해관계자 커뮤니케이션이 주 역할인 사람

진짜 프로덕트 매니저

고객과 이해관계자의 요구사항을 충족시킨다고 성공할 수 없다는 것을 이해한다.
비즈니스에서 어떤 성과를 내야 하는지 이해한다.
회사의 전략에 맞춰 제품의 방향성을 세운다.
제품에서 어떤 지표를 개선해야하는지 이해한다.
어떤 레버리지(leverage)를 이용할 수 있는지 이해한다.
정량적, 정성적으로 고객들의 문제를 파악할 수 있다.
어떤 문제를 해결하면 좋은 성과를 낼 수 있는지 이해한다.
하나의 문제를 해결하는 방식이 다양하다는 것을 이해한다.
프로덕트 디자이너와 엔지니어들과 함께 다양한 가설과 해결책을 탐색한다.
정량적, 정성적으로 검증한다.

그럼 프로덕트 매니저는 무슨 일을 하는 사람인가?

성공적인 제품은 어떻게 만들 수 있을까? 제품이 성공하려면 어떻게 해야할까?를 고민하는 사람 / 성공적인 제품 = 고객에게도 가치를 주고, 우리 사업에도 도움주는 제품
제품의 성과 전반을 책임지는 사람

성공적인 제품의 네 가지 조건

Valuable: 고객이 구매하고자 하는 제품, 유저가 사용하고자 하는 제품
Usable: 사람들이 사용법을 익히고, 사용할 수 있는 제품
Feasible: 우리가 가진 기술력으로 구현할 수 있는 제품
Viable: 예산 내에서, 법률과 규제에 저촉되지 않고 회사 평판을 훼손하지 않고, 사업적으로 타당하며 이해관계자들이 받아들일 수 있는 제품

그와 동시에 제품 조직이 마주하는 네 가지 리스크이기도 함

Value Risk: 고객들이 원하지 않고, 유저가 사용하고 싶어하지 않는 제품
Usability Risk: 사용자들이 이용하기 어려운 제품
Feasibility Risk: 알고보니 기술적으로 구현하기 너무 어려운 제품
Business Viability Risk: 사업적으로 타당하지 않은 제품(비용 효율적이지 못하거나 법이나 규제에 저촉되는 경우)

PM에게 필요한 역량

A comprehensive survey of Product Management - Lenny's Newsletter에 따르면 글로벌 회사들에서 커뮤니케이션, 실행, 프로덕트 센스, 전략적인 사고, 협업 능력, 데이터, 디자인 등 다양한 역량을 요구하고 있음을 알 수 있음. 하지만 우선순위는 회사마다 천차만별.

오라클: 테크니컬 백그라운드
왓츠앱: 프로덕트 센스
세일즈포스: 커뮤니케이션, 실행 능력

회사의 제품 특징으로 인해 필요한 역량의 우선순위가 정해지기도 하지만, 회사의 Stage마다 다른 역할로 인해 필요한 역량이 달라지기도 함.

pre-PMF 단계 스타트업 PM의 역할
- 좋은 시장 찾기
- 수많은 이터레이션 운영
- 기존에 없던 가치를 만들어내는 단계
Feature Work 단계 스타트업 PM의 역할
- 제품 기능을 확장함으로써 고객 가치와 사업적 가치 창출
- 고객 문제 파악하기, 솔루션 만들기, 유저들이 기능을 잘 사용할 수 있게 알리고 교육하기
- 기능 추가와 개선으로 추가적인 고객 가치를 만들어내는 단계
Growth Work 단계 스타트업 PM의 역할
- 더 많은 유저/고객들이 우리 제품을 도입(adoption)하고 더 활발히 사용(usage)하게하기
- 이미 존재하는 가치에 더 많은 사람이 빨리 접근하게 만들어내는 단계

결론

회사와 제품의 단계에 따라 필요한 역할과 역량이 크게 달라짐. Pre-PMF/Feature Work/Growth Work/PMF Expansion/Scaling Work 같은 제품 단계별로 고민이 다를 수 밖에 없음.

그럼에도 제품이 성공하려면 어떻게 해야할까?를 집요하게 고민해야한다는 본질은 변하지 않음. 또한 이러한 고민은 Product Manager만 해서는 안됨. 제품을 함께 만드는 엔지니어와 디자이너 뿐 아니라 팀 전체가 공통으로 고민해야만 하는 문제라고 생각됨.

당신은 얼마나 책임 지고 있나요? (feat. Mandate Levels)

Tue, 11 Jun 2024 23:08:34 GMT

업무를 수행할 때 각자 맡은 바에 따라 책임과 권한의 범위가 크게 다른데요. 책임과 권한의 범위에 따라 성과의 종류와 크기가 결정되기도 합니다. 이를 이해하면 자신의 역할과 업무 범위를 명확히 파악할 수 있으며, 이를 통해 커리어를 발전시키는 데 중요한 통찰을 얻을 수 있기도 합니다.

이 글에서는 Mandate Levels라는 기준에 따라 권한과 책임이 어떻게 단계적으로 구분되는지 이야기해 보고자 합니다.

Mandate Levels

Mandate Levels는 John Cutler가 제안한 개념입니다. TBM 27/52: Mandate Levels

그는 권한/자율/위임과 같은 단어를 들을 때마다 '그게 무얼 의미하는 거지?'라는 기시감을 느꼈다고 합니다. 이를 계기로, 추상적으로 세 단어를 사용하는 게 아닌, 더 구체적인 표현 방법은 없을까 고민하게 되었고, 그 결과 Mandate Levels라는 일에 대한 9가지 기준을 세우게 되었습니다.

참고로 Levels라고 표현했다고 특정 일을 하는 사람들을 기준으로 상하관계나 등급을 나타내는 것은 아닙니다. 단지 종류를 나누었을 뿐이니 이 글을 읽으실 때 유의해 주시기를 부탁드립니다.

Level A: 기초 단계

권한: 없음
업무: 정해진 스펙을 만드는 것. 시키는 일을 그대로 수행
예시: "이렇게 해라"라고 지시한 대로 작업 수행

Level A는 권한이 거의 없지만, 기초적인 업무를 통해 기본적인 기술과 업무 이해도를 쌓는 단계입니다. 이 단계에서의 경험은 이후 단계로의 진입을 위한 중요한 발판이 됩니다. 기본기를 다지고, 업무 프로세스를 이해하는 데 도움이 됩니다.

Level B: 기초 프로그래밍

권한: 제한적
업무: 정해진 입력에 따라 특정 출력을 만들어내는 것
예시: 아이디와 비밀번호를 입력하면 시스템에 로그인되게 만들어라

Level B에서는 제한된 권한 내에서 특정 기능을 구현합니다. 이 과정에서 문제 해결 능력과 프로그래밍 기술을 연마할 수 있습니다. 또한, 정해진 요구사항을 정확히 이해하고 구현하는 능력을 키우는 데 집중하게 됩니다.

Level C: 기능 개발

권한: 일부 자유도 부여
업무: 고객 세그먼트가 어떤 작업을 할 수 있게 만드는 것
예시: 로그인 기능 개발 (아이디+비밀번호, 카카오 로그인, FaceID 로그인 등 다양한 방식으로 구현 가능)

Level C에서는 기능 개발을 통해 더 많은 자유도가 주어지며, 이를 통해 창의적 문제 해결 능력을 키울 수 있습니다. 다양한 방법을 탐구하고 선택하는 과정에서 책임감과 자율성을 배울 수 있습니다.

Level D: 문제 해결

권한: 중간 정도
업무: 고객의 특정 문제를 해결하는 것
예시: 통계 자료를 이해하기 어려운 문제를 해결하기 위한 차트 개선

Level D에서는 고객의 문제를 이해하고 해결하는 능력을 요구합니다. 그 과정에서 더 깊은 분석과 창의적인 해결 방안을 모색하게 되며, 이 단계에서의 경험은 더 복잡한 문제를 다루는 데 도움이 됩니다.

Level E: 경험 개선

권한: 상당한 자유도 부여
업무: 유저 또는 고객 세그먼트의 문제를 파악하고 경험을 개선하는 것
예시: 문제 정의부터 해결까지 모든 과정에 책임을 지고 경험 개선 방안을 마련

Level E에서는 문제 정의부터 해결까지 모든 과정을 주도적으로 이끌어 나가야 합니다. 이는 큰 책임감을 요구하며, 유저 경험을 개선함으로써 브랜드 이미지와 고객 충성도를 향상시키는 데 기여합니다. 이 단계에서의 경험은 리더십과 프로젝트 관리 능력을 향상시킵니다.

Level F: 성과 지표 개선

권한: 높은 책임감 요구
업무: 특정 지표를 개선하여 사업 성과를 향상시키는 것
예시: 리텐션을 증가시켜 매출을 올리기 위한 방안을 마련

Level F에서는 구체적인 성과 지표를 개선하여 회사의 사업 성과를 직접적으로 향상시키는 역할을 합니다. 이는 데이터 분석 능력과 전략적 사고를 요구하며, 성과를 통해 자신의 기여도를 명확히 드러낼 수 있습니다.

Level G: 실험 및 탐색

권한: 매우 높은 자유도
업무: 사업 성과를 개선하기 위한 레버리지 포인트를 탐색하고 실험하는 것
예시: 매출 개선을 위한 새로운 방법을 찾아 실험하고 적용

Level G에서는 높은 자유도와 함께 큰 책임이 따릅니다. 새로운 방법을 탐색하고 실험하는 과정에서 혁신적 사고와 문제 해결 능력을 발휘할 수 있으며, 성공적인 결과를 통해 사업 성과를 극대화할 수 있습니다.

Level H: 단기적 성과 달성

권한: 조직의 실무자 단계
업무: 단기적인 성과를 정의하고 전략을 짜는 것
예시: 장기적 전략에 따라 단기적으로 성과를 내기 위한 계획 수립 및 실행

Level H에서는 조직의 실무자로서 단기적인 성과를 내기 위한 전략을 수립하고 실행합니다. 이는 팀을 이끌고 조직의 목표를 달성하는 데 중요한 역할을 합니다. 단기적 성과를 통해 조직 내에서 자신의 위치를 확립하고, 더 큰 책임을 맡을 준비를 할 수 있습니다.

Level I: 장기적 성과 책임

권한: 최고 수준
업무: 회사 전체의 장기적 사업 성과를 정의하고 책임지는 것
예시: 회사 전체의 방향을 설정하고 장기적인 성과를 내기 위한 전략 수립 및 실행

Level I에서는 회사 전체의 리더로서 장기적인 사업 성과를 책임집니다. 이는 매우 높은 수준의 전략적 사고와 리더십을 요구하며, 회사의 장기적 성장과 방향성을 결정하는 중요한 역할을 합니다. 이 단계에서의 성공은 회사 전체에 큰 영향을 미치며, 자신의 커리어에서도 가장 중요한 이정표가 됩니다.

마무리

'이런 상하관계는 너무 구시대적입니다. 실리콘밸리는 매우 수평적이라던데요?'라고 이야기하시는 분들도 있을거라고 생각합니다. 앞서 이야기한 것처럼 이는 일에 대한 상하관계를 지정하는 개념이 아닙니다. 단순히 일을 할 때 어느 정도의 권한을 가질 수 있느냐의 문제입니다.

그리고 매우 수평적이라고 이야기하는 실리콘밸리조차 의사결정에 있어서는 계층이 나뉩니다. 그들이 수평적이라고 표현되는 이유는 일을 할 때 구성원들 간의 관계가 수평적이라는 의미이고, 의사결정은 수직적으로 진행됩니다.

여러분은 어떤 레벨에서 업무를 하고 있으신가요? 그리고 어떤 업무를 경험하고 싶으신가요? 여러 레벨에 걸친 업무를 하고 있는 분도 있으실 것이고, 한 개 레벨의 업무를 하는 분도 있으실 건데요.

Mandate Levels는 각자의 업무 역할과 권한을 명확히 구분해 주어 조직 내에서 각자의 위치와 책임을 이해하는 데 큰 도움이 됩니다. 각 단계에서의 경험과 성과는 다음 단계로 나아가는 중요한 발판이 되며, 커리어 발전에 있어서 중요한 역할을 합니다. 자신의 역할을 명확히 이해하고, 각 단계에서 요구되는 책임과 권한을 충실히 이행하는 것이 성공적인 커리어를 쌓는 데 큰 도움이 됩니다.

우리가 하는 일은 두 가지 유형의 일 뿐이다. (부제; 직무의 통합)

Sat, 01 Jun 2024 19:03:50 GMT

여러분은 평소 어떤 일을 하시나요? 고객의 요구사항을 분석하고 정리하여 문서로 만들기, 상세한 기능 명세서와 화면 설계서 작성하기, 기획서와 화면 디자인을 보며 어떻게 개발할지 고민하기 같은 제품을 만들기 위한 일부터

기업의 재무나 회계 자료를 정리하고 보고서를 만드는 일, 인체의 질병과 손상을 연구하고 진단/치료하는 일, 개인이나 단체를 대신하여 법정에서 그들을 변호해 주는 일까지 세상에는 정말 다양한 유형의 일이 존재합니다.

그런데 이 모든 일을 잘 놓고 보면 일이라는 것은 두 가지 유형으로 분류 할 수 있는데요. 무엇을 할지 고민하는 일 그리고 어떻게 할지 고민하는 일입니다. 오늘은 제품 개발과 관련된 예시와 관점으로 이 이야기를 풀어보려고 합니다.

무엇을 할지 고민하는 일

소위 말하는 제품 기획자라는 역할을 지니신 분들이 하는 일입니다. 이들은 주로 이해관계자들의 요구사항을 취합하고, 요구사항에 맞추어 기능을 기획합니다. 그 후 프로젝트를 담당할 디자이너와 엔지니어를 할당받습니다. 그리고 기획서를 만들어 디자이너와 엔지니어에게 넘깁니다. 디자이너와 엔지니어가 일정 내에 요구사항에 맞추어 개발을 완료할 수 있도록 프로젝트를 관리하고, 완성되면 배포하고 다음 프로젝트로 넘어갑니다.

어떻게 할지 고민하는 일

위 예시에서 언급한 디자이너와 엔지니어의 역할을 지니신 분들이 주로 하는 일입니다. 기획자의 의도에 맞게 디자인하고, 개발 하기 위하여 어떻게 해야 할지 고민합니다.

다양한 안티 패턴(anti-pattern)

앞선 예시의 업무수행 방식에서는 기획자 -> 디자이너 -> 엔지니어 순으로 hand-off 하는 방식의 패턴이 자주 보입니다. 모든 직군이 제품의 성공보다는 그냥 프로젝트를 수행하는 것에 초점을 맞추어 일하는 것인데요.

기획자, 디자이너 그리고 엔지니어가 철저히 분업화되면서 여러 가지 문제가 발생합니다. 기획자는 '상세한 기능 명세서와 화면 설계서를 만들어 넘겼으니 내 역할은 끝났다.'라고 생각하게 되고, 디자이너와 엔지니어는 '넘어온 형태로만 만들면 된다.'라고 생각하게 됩니다.

시간이 지나며 최근에는 제품 기획자라는 이름의 역할이 줄어들고 Product Manager / Project Manager / Product Owner 같은 직무가 등장하기 시작합니다. 그냥 기획자라는 직무를 그럴듯하게 영어로 바꾼 거 아니야? 라고 생각하실 수도 있는데요. 이들이 등장하게 된 배경을 살펴보면 꽤 흥미로운 점이 있습니다.

Product Manager와 Project Manager는 기존에 요구사항을 취합하고 요구사항에 맞추어 기능을 기획하던 기획자라는 역할에서 더 확장된 직무입니다.

하나씩 살펴보자면 이들은 각각 전략과 실행을 담당하는 역할로 이분화되어 있습니다.

Product Manager (전략): 시장을 조사하고, 제품 계획을 수립합니다. 요구사항을 정리해서 프로젝트 매니저에게 전달합니다.
Project Manager (실행): 개발팀과 소통하며 제품을 만들기 위한 일련의 작업을 수행합니다.

여기서도 전략과 실행 즉, 무엇을 할지 고민하는 일과 어떻게 할지 고민하는 일로 나누어집니다.

그러다 이 둘이 하나로 합쳐진 전략 + 실행을 모두 수행하는 역할이 생겨납니다. 이것이 바로 Scrum Product Owner 입니다. 참고: What is a Product Owner? | Scrum.org

참고로 여기서 말하는 Scrum Product Owner는 한국에서 널리 알려진 Product Owner와는 다릅니다. 해외에는 Product Owner라는 Job Position이 거의 없습니다. 대부분 Product Manager가 Scrum Product Owner의 역할을 수행하는 정도의 관계입니다.

이 글에서는 편의상 Product Manager를 전략을 담당하는 역할, Product Owner를 전략과 실행을 모두 담당하는 역할 정도로 표현할 예정이니 이해 부탁드립니다.

직무의 통합?

시간이 지남에 따라 여러 직무가 하나로 통합되고, 한 사람이 맡는 일의 양이 증가하고 있는데요. 이는 기술의 발전과 방대한 정보에 대한 접근성이 좋아진 탓이라고 생각합니다. 실제로 검색 엔진과 AI 등의 발전으로 과거에 비해 동일한 단위 시간당 한 사람이 할 수 있는 업무의 양이 비약적으로 증가했기 때문에 당연한 결과입니다.

그 외에도 업무의 효율성 차원에서의 이유도 있습니다. 기존에는 전략과 실행을 서로 다른 사람이 수행하다 보니 업무 간의 Boundary가 명확하게 나누어지고, 앞서 이야기한 다양한 안티 패턴이 발생하기 쉬운 구조였습니다. 안티 패턴을 깨고 서로 의견을 공유하려고 보니 서로의 이해도가 달라 발생하는 이슈가 발생하기도 했습니다.

그리고 이러한 문제점을 해결하기 위한 방법 중 여러 일을 한 사람이 맡아서 하는 방법이 가장 효율적이기에 시간이 지남에 따라 여러 직무가 하나로 통합되는 게 아닐까 싶습니다. 실제로 최근의 제품 개발 씬에서는 Product Engineer / Problem Solver 같은 직무가 등장하고 있기도 합니다.

장기적인 관점에서의 '일'

무엇을 할지 주로 고민하는 Product Manager와 어떻게 할지 주로 고민하는 Software Engineer 이 두 직무를 예시로 이야기해 보겠습니다.

Product Manager는 전략을 담당하고 무엇을 하면 좋을지 치열하게 조사하고 계획을 수립합니다. 이들 중 전문성을 강화하고 소위 말하는 일 잘하는 사람이라고 불리는 사람들은 이런 특징이 있습니다.

우리 사용자와 고객, 데이터, 비즈니스, 산업 등에 대한 깊은 이해도를 지니고 있습니다.
성공적인 프로덕트를 만들기 위해 끊임없이 호기심을 가지고 다양한 방식으로 집요하게 쪼개서 분석합니다.
비판적 사고(Critical Thinking) 능력이 매우 뛰어납니다.
단순히 가설을 세워서 실행하고 검증하는 것이 아닌, '그래서 그게 왜 중요했는가?'라는 질문에 대답할 수 있을 정도로, 주도적으로 문제를 정의하고 해결합니다.
일반적으로 Product Manager가 알기 어려운 기술적인 부분 또는 적용된 알고리즘, 혹은 성능 최적화에 대해 생각해 보고 의견을 제시합니다.

Software Engineer는 주로 실행을 담당하고 어떻게 만들면 좋을지 치열하게 설계하고 결과를 만들어냅니다. 이들 중 전문성을 강화하고 소위 말하는 일 잘하는 사람이라고 불리는 사람들은 이런 특징이 있습니다.

복잡한 문제를 체계적으로 분석하고 다양한 해결책을 제시하며 최적의 솔루션을 찾아냅니다.
초기 개발 단계부터 코드의 확장성과 유지보수성을 고려합니다.
코드나 시스템의 오류를 신속하게 찾아내고, 문제가 다시 발생하지 않도록 철저하게 근본 원인을 찾고 예방 조치를 마련합니다.
효율적인 알고리즘을 구현하고, 시스템 자원을 효과적으로 사용하는 등 제품의 성능을 최적화하는 데 능숙합니다.
우리 제품의 사용자가 최대의 효능감을 느끼게 하기 위해서는 무엇이 필요할지 생각해 보고 의견을 제시합니다.

Product Manager는 전략을 넘어 실행 관점에서 어떻게 해야 더 잘할 수 있을지 연구하고 의견을 제시하고, 반대로 Software Engineer는 단순히 실행하는 것을 넘어 사용자를 위해 진정으로 무엇을 해야 할지 고민하고 의견을 제시합니다.

재미있지 않나요? 결국 각 영역에서 일 잘하는 사람이라고 평가받는 사람들은 본인의 업무 영역을 넘어 다른 영역의 고민을 함께 고민해 주고 의견을 제시할 수 있는 사람입니다.

결론

우리가 하는 일은 두 가지 유형의 일밖에 없지만, 앞서 소개한 PM과 PO의 사례처럼 시간이 지남에 따라 한 사람이 두 가지 유형의 일을 다 맡게 될 가능성이 높습니다. Product Manager는 이제 단순히 기획만 하는 사람이 아니라, 제품을 성공으로 이끌기 위해 사용자와 고객에 대해 깊게 이해하고, IT산업과 기술적인 배경지식 요구하는 직무로 자리 잡고 있습니다. 반대로 Software Engineer도 단순히 코드를 작성하는 역할에서 벗어나 사용자 경험과 제품 전략에 대한 깊은 이해를 바탕으로 제품을 개발하고 있습니다.

결국 직무의 경계가 허물어지고 여러 역할이 하나로 통합되는 흐름은 앞으로도 지속될 것으로 보입니다. 물론 모든 직무가 하나로 통합되기까지는 훨씬 오랜 시간이 필요할 것 같네요. 😅

이는 우리가 기존의 역할에 안주하지 않고 끊임없이 배우고 성장해야 함을 의미하고, 각자의 전문성을 유지하면서도 다른 영역의 업무를 이해하고 협업하는 능력을 갖춘다면 빠르게 변화하는 산업 환경에서도 높은 경쟁력을 유지할 수 있음을 의미합니다.

미래에 통합될 거라면 이왕이면 지금부터 현재 내 직무에 대한 전문성을 바탕으로 다른 영역에도 관심을 가져보는 건 어떨까요?

교육 산업에 대한 고찰

Wed, 15 May 2024 16:34:53 GMT

들어서며

고시 낭인, 교육 중독이라는 단어를 들어보신 적 있으신가요? 나이를 불문하고 전 연령층에 퍼져있는 사회적 현상을 일컫는 단어입니다. 오늘은 이러한 사회적 현상과 교육산업 자체에 대한 생각을 남겨보려고 합니다.

저는 과거 컴퓨터공학을 메인으로 교육학과 교육심리학을 병행하여 공부 했었는데요. 그만큼 교육에 관심이 많았고, 진심이었습니다. 하지만 공부를 하면 할수록 이 산업은 나와 맞지 않다는 결론을 내리고 공부만 끝마친 뒤, 해당 산업에 full-time으로 뛰어들지 않았습니다.

몇 가지 이유가 있었지만 결정적으로 무얼 하면 좋을지 크게 고민하지 않는 산업이라고 생각했기 때문입니다. 삶을 살아가다 보면 다양한 고민과 의사결정 과정이 있기 마련이고, 그 고민은 크게 두 가지로 나뉩니다.

문제를 찾고, 그 문제를 해결하기 위해 무얼 하면 좋을지 고민하는 일 (What)
무얼 하면 좋을지 정해지면, 어떻게 할지 고민하는 일 (How)

그리고 저는 What에 해당하는 고민을 더 즐겨합니다. 하지만 교육산업에서 이루어지는 고민 대부분은 누구에게(Who), 무엇을(What) 가르칠지 이미 정해진 상태에서 어떻게(How) 가르칠지 고민하는 일이 대부분이라고 생각했습니다.

단상, 교육혁신의 대단함

많은 에듀테크 기업이 교육혁신이라는 캐치프레이즈로 시장에서 치열하게 경쟁하고 있습니다. 그럼, 이 교육혁신은 무엇일까요? 이를 이해하기 위해선 모든 인간은 공부하지 않으려는 본성을 가지고 있다는 걸 우선 알아야 합니다.

교육혁신이라는 것은 결국 공부하지 않으려는 본성을 가지고 있는 사람들이 이 본성을 이겨내고 자기 주도적으로 공부하고 싶게끔 아래와 같은 요소를 제공해 주어야 함을 의미합니다.

합리적인 교육 비용
양질의 커리큘럼
우수한 강사진
운영 인력의 노고

이 중 하나만 이루어져서는 안 됩니다. 네 가지 요소가 두루두루 갖추어져야만 하는데요. 현실적으로 생각해 보았을 때 이익을 추구해야 하는 기업의 특성상 각 요소 모두를 잘 갖추기란 쉽지 않은 일입니다. 그렇기에 더더욱 교육혁신이라는 건 대단한 일이라고 생각합니다.

현재까지 파트타임으로 교육과 멘토링을 해오며 2천 명 이상의 멘티와 학습자(피교육자)를 만나왔는데요. 그 과정에서 네 가지 요소를 최대한 제공해 드리며 항상 좋은 학습 경험과 사람이 성장할 수 있는 환경을 제공하기 위해 노력해 왔으나 이게 제 개인의 노력이 아니라 기업의 '업'이었다면 불가능했을거라 생각합니다.

인용, 교육업이 크게 성장하지 못한 이유

링글의 창업자이신 이승훈(Hoon Lee)님도 과거 교육업에 대한 생각을 공유해주신 적 있는데요. 승훈님은 교육업이 크게 성장하지 못한 본질적인 이유를 결심 또는 압박을 콘텐츠/서비스 이용 & 유저 성장으로 연계시키지 못했기 때문이라고 이야기합니다.

결제하는 사람들은 많지만, 꾸준하게 공부해서 성장하고, 다시 결제해서 더 공부하는 사람들은 많지 않기 때문에 산업의 중심이 '공부하는 사람' 보다는 '결제하는 사람'에 초점을 맞춰지게 된 것 같다는 이야기인데요. 그러다 보니 유저(학습자, 피교육자)가 교육 서비스를 이용함으로써 얼마나 만족할 수 있게끔 만드느냐보다는 어떻게 결제하게끔 만드느냐가 초점이 된 산업이 된게 아닐까 싶습니다.

마무리

이런 생각이 드실 수도 있습니다. 왜 사람들은 만족하지도 않는, 이용도 안 할 서비스와 교육을 구매할까?

사람은 생각보다 더 비합리적인 존재이기 때문에 언뜻 이해하기 어려운 소비도 큰 고민 없이 진행하기도 하고, 무엇보다 그 소비가 교육이라면 스스로 불필요한 소비라고 생각하지 않는 경향이 있습니다. 이용하지도 않고 구매했다는 행위 자체만으로 만족감을 느끼고, 그 만족감에 중독되곤 합니다.

꽤 많은 교육 기관이 유저 만족보다는 결제를 위해 고민하는 모습을 보며 아쉬운 마음이 들면서도 기업이라는 단체 특성상 어쩔 수 없다는 것도 알고 있으니, 한편으로는 이해되기도 합니다. 그럼에도 이용하게 되는 서비스와 교육에서 진정한 만족을 느낄 수 있도록 노력하는 많은 에듀테크 회사를 응원합니다.

그리고, 교육에 돈과 시간을 소비하는 것에 중독되신 분들은 하루빨리 그 중독에서 벗어나 스스로 내 방향성을 결정하고, 학습할 수 있도록 독립하는 연습을 꾸준히 해보셨으면 좋겠습니다. 이 연습을 게을리 하다보면 1년, 2년이 지났을 때에는 열심히 하고 있지만 성장하지 않는 것 같다라는 생각을 하게 될 것이고 3년, 4년이 지났을 때에는 내가 모르는 것이 너무 많다라는 생각이 들 것입니다.

그 이유는 간단합니다. 사실은 열심히 하지 않았으며, 열심히 한 것 처럼 느끼는 시간을 보냈을 뿐이기 때문입니다. 그리고 이걸 깨달았을 그때는 너무 늦었을 수도 있습니다. 미래에 후회하기보다는 미리 연습하셨으면 좋겠습니다.

useCallback을 순수 자바스크립트로 구현한다면?

Sun, 12 May 2024 21:07:55 GMT

React의 useCallback 함수는 함수를 캐싱하여 불필요한 리렌더링을 방지하고, 성능을 최적화하는 데 도움을 주는 훅(Hook)입니다. 일종의 함수 캐싱이라고 볼 수도 있는데요. 이를 순수 자바스크립트로 구현한다면 어떻게 만들 수 있을까요?

우선 어떤 구성 요소가 필요할지 고민이 필요합니다. 간단하게 생각해 봤을 때는 아래와 같은 요소가 필요할 것으로 보입니다.

함수를 캐싱하기 위하여 기존 함수를 저장하는 변수
기존 의존성 배열의 값을 저장하는 변수
함수를 처음 호출하는지 검사하는 함수
의존성 배열이 변경되었는지 검사하는 함수
새로운 함수와 의존성을 캐싱하는 함수

단계별로 쪼개어 다루어보겠습니다.

1. 함수를 캐싱하기 위하여 기존 함수를 저장하는 변수

let cachedFunction = null;

2. 기존 의존성 배열의 값을 저장하는 변수

let cachedDependencies = null;

3. 함수를 처음 호출하는지 검사하는 함수

function verifyInitialCall(cachedFunction) {
    return cachedFunction === null;
    // or
    return !cachedFunction;
}

4. 의존성 배열이 변경되었는지 검사하는 함수

function dependenciesAreEquals(arr1, arr2) {
  if (arr1 === arr2) {
    return true;
  }
  
  if (arr1.length !== arr2.length) {
    return false;
  }
  
  for (let i = 0; i < arr1.length; i++) {
    if (arr1[i] !== arr2[i]) {
      return false;
    }
  }
  
  return true;
}

// 사용 예시
if (!dependenciesAreEquals(cachedDependencies, dependencies)) {
    // ...
}

5. 새로운 함수와 의존성을 캐싱하는 함수

cachedFunction = func;
cachedDependencies = dependencies;

위 로직을 합쳐보면 아래와 같은 꼴이 됩니다.

useCallback Sample #1

function useCallback(func, dependencies) {
  // 함수를 캐싱하기 위하여 기존 함수를 저장하는 변수
  // 기존 의존성 배열의 값을 저장하는 변수
  let cachedFunction = null;
  let cachedDependencies = null;

  return function () {
    // 함수를 처음 호출하거나 의존성 배열이 변경된 경우 새로운 함수 생성
    if (
      !cachedFunction || !dependenciesAreEquals(cachedDependencies, dependencies)
    ) {
      cachedFunction = func;
      cachedDependencies = dependencies;
    }

    return cachedFunction.apply(this, arguments);
  };
}

// 두 의존성 배열이 같은지 비교하는 함수
function dependenciesAreEquals(arr1, arr2) {
  if (arr1 === arr2) {
    return true;
  }
  
  if (arr1.length !== arr2.length) {
    return false;
  }
  
  for (let i = 0; i < arr1.length; i++) {
    if (arr1[i] !== arr2[i]) {
      return false;
    }
  }
  
  return true;
}

// 사용 예시
function ProfileComponent() {
  const handleClick = useCallback(() => {
    console.log("Button clicked");
  }, []);

  return <button onClick={handleClick}>Click me</button>;
}

예제 소스코드: React Playground - useCallback Sample 1

개선 & 최적화 - useCallback Sample #2

첫 번째 예시는 정말 동작만 되게끔 만들기 위해 다수의 함수가 생성되고, 코드의 길이도 긴 편이라 가독성과 효율이 뛰어나지 못합니다. Javascript의 Prototype과 클로저를 적극 활용하여 코드의 길이를 전반적으로 줄여보겠습니다.

function customUseCallback(callback, dependencies) {
  const memoizedCallback = function (...args) {
    if (!memoizedCallback.cache) {
      memoizedCallback.cache = new Map();
    }
    const key = dependencies.join('-');
    if (memoizedCallback.cache.has(key)) {
      console.log('cache hit!');
      return memoizedCallback.cache.get(key);
    }
    const result = callback(...args);
    memoizedCallback.cache.set(key, result);
    console.log('cache miss!');
    return result;
  };

  return memoizedCallback;
}

// 사용 예시
export function App(props) {
  const [count, setCount] = useState(0);
  const handleClick = customUseCallback(() => {
    console.log('Button clicked');
  }, [count]);
  return (
    <div className='App'>
      <button onClick={handleClick}>Click me</button>
      <button onClick={() => setCount(c => c + 1)}>Count Up ({count})</button>
    </div>
  );
}

예제 소스코드: React Playground - useCallback Sample2

문제점

두 단계에 걸쳐 useCallback을 임의로 만들어보았는데요. 이 코드를 React에서 사용하기에는 큰 문제가 있습니다. 바로 렌더링마다 useCallback 함수가 새롭게 호출되면서 캐시도 초기화된다는 건데요.

이에 따라 의존성 배열의 변경과 상관없이 렌더링마다 새로운 함수가 생성됩니다. 즉, 함수를 캐싱한다.라는 초기 요구사항을 만족시키지 못한 것인데요. 그럼, 이 부분은 어떻게 개선해야 할까요?

문제점 해결

렌더링할 때마다 useCallback 함수 전체가 재실행되면서 캐시 초기화와 캐시 검증 로직 전체가 동시에 이루어지는 게 현재의 문제점입니다.

그럼, 이 두 영역을 분리하면 어떨까요?

리액트의 컴포넌트는 크게 mount, update, unmount 세 단계의 생명주기를 가지는데요. 이를 활용하면 힌트를 얻을 수 있습니다.

mount 단계에 캐시를 초기화하고, update 단계에 캐시 검증 로직을 실행하면 쉽게 해결할 수 있을 것으로 보입니다.

저희가 만든 useCallback 함수를 리액트 컴포넌트 생명 주기에 맞추어 각각 쪼개어 실행하게 하는 건 손이 많이 가고, 꽤 번거로운 작업이기에 실제 React의 useCallback 함수 구현을 보며 이야기해 보겠습니다.

/**
 * 대략의 구현
 */

function mountCallback () { /* */ } // 마운트 상황의 구현체
function updateCallback () { /* */ } // 렌더 상황의 구현체

const HooksDispatcherOnMount = {
  useCallback: mountCallback,
  // ...
}
  
const HooksDispatcherOnUpdate = {
  useCallback: updateCallback,
  // ...
};

/* 컴포넌트 렌더 시에 실행되는 함수 */
export function renderWithHooks() {
  // ...
  ReactCurrentDispatcher.current =
    current === null || current.memoizedState === null // 최초 마운트라면
      ? HooksDispatcherOnMount
      : HooksDispatcherOnUpdate;
  // ...
}

실제로 mountCallback과 updateCallback이 분리되어 있으며, 각 생명주기에 따라 적절한 함수를 호출하는 모습을 볼 수 있습니다.

자세한 구현은 내용이 길어져 관련 소스코드 링크로 생략합니다.

facebook/react on GitHub

마무리

이번 예시는 React라는 라이브러리의 생태계 위에서 코드를 작성하다 보니 React 컴포넌트의 생명주기까지 확인을 해야만 했는데요. 순수 Javascript 프로젝트에서는 함수의 파라미터가 동일하다면 반환 값을 캐싱하는 형태도 위 코드를 활용하여 구현해볼 수 있을 것으로 보입니다. 다들 한번 해보시면 어떨까요? 🙂

더 많은 기회를 발견하는 방법, The Red car theory

Wed, 17 Apr 2024 21:35:20 GMT

어떻게 그렇게 열심히 하실 수 있나요?라는 질문을 자주 받는데요. 이번 글에서는 그에 대한 이야기를 나눠보려고 합니다.

빨간 차 이론에 대해 들어보신 적 있으신가요?

출근하는 길에 빨간 차를 보셨나요? 혹은 퇴근길에 보셨나요? 대부분 아마도..?라고 이야기할 겁니다.

밖으로 나오기 전, 차를 타고 도로로 나오기 전에 누가 이렇게 이야기했다면 어땠을까요? 빨간 차를 발견 하실 때마다 100만 원을 드리겠습니다.

그럼 이동하는 길에 빨간 차를 몇 대나 봤는지 알 수 있었을까요? 오히려 빨간 차를 엄청나게 찾아다니겠죠.

그게 운이 작동하는 방식입니다. 기회도 그렇게 작동합니다.

인생을 살아가면서 아무 곳도 쳐다보지 않고 주의 깊게 보지 않으면 그런 기회들은 지나쳐버릴 겁니다.

저도 그렇습니다.

저는 사람들의 얼굴이나 이름을 억지로 기억하려고 노력하지는 않는 편입니다. 만나는 사람이 많고, 사람 뇌의 용량은 한정되어 있다고 생각해서인데요. 그중에서도 기억할 만한 임팩트나 사건 같은 게 있었다면 자연스럽게 기억하고, 정기적으로 연락드리면서 스몰톡도 나누곤 합니다. 단체로 만나는 경우도 있고요.

그 과정에서 다른 사람들은 요즘 어떤 고민을 하고 있을까, 나라면 그 문제를 어떻게 접근할까? 같은 생각을 많이 합니다.

그러다 1만 명 중 1명꼴로 정말 배울 점이 많은 사람이다.라는 생각이 들게 하는 사람을 만나기도 하고요.

이게 정답이라는 것은 아니지만 이러한 관점과 행동이 저의 성장에는 큰 도움이 되었습니다.

이렇게 10년 가까이 살아왔지만 아직까지도 항상 깨어 있는 시선으로 주변에서 일어나는 일들에 작은 관심이라도 가지며, 조금씩이라도 집중하려는 노력을 하는 것이 인생에서 스스로를 성장시키는 동력이라고 생각합니다.

[주간회고] 2024년 9주차

Sun, 03 Mar 2024 21:05:30 GMT

Do: Work

Frontend 리팩토링: 볼타가 만들고 있는 전자세금계산서 간편 발행/관리 SaaS는 상당히 복잡한 비즈니스 구조를 지니고 있습니다. 단순히 세금계산서 발행에서 끝나는게 아니라 기존에 발행된 세금계산서를 정정하는 수정 세금계산서의 경우 수정 사유에 따라 다양한 제약조건과 데이터 구조를 지닙니다. 그러다보니 기술적으로도 적절히 공통화하면서도 각기 다른 비즈니스를 표현해야만 하는데요. 해당 작업을 일부 진행하였습니다.
공동인증서 구조 RND: 공동인증서는 사용자 행위의 부인 방지를 위해 사용되는 개념입니다. 최근에는 별도 실행파일을 설치하지 않고도 컴퓨터에 저장된 파일을 읽고, 순수 HTML5 + Javscript 만으로도 공동인증서 서명을 위한 일련의 작업이 가능해졌는데요. 해당 작업을 지원하기 위해 구조를 분석하고 관련 개발을 진행했습니다. 🙂
신규 서비스 스터디: 내부적으로 논의 중인 신규 서비스가 있는데요. 해당 서비스에 대한 스터디를 했습니다.

Do: Academic

SLIT 오프라인 모임: SLIT은 스타트업 리더 모임이에요. 매주 온라인으로 모여 주간회고를 작성하고, 한 달에 한 번 오프라인으로 모여 리더십 관련 아젠다에 대하여 이야기 나누는 모임인데요. 이 주간회고도 온라인 모임의 일환이기도 해요. 모임 시작 후 처음으로 오프라인 모임을 진행했고, 1) 리더십 개발 및 팀 관리 2) 저성과자 관리 전략 3) 성공 사례 공유 등 주제로 이야기 나누었습니다. 평소 어렴풋 상상만하고 있던 주제에 대해 이야기 나눠보면서 기준과 가치관이 조금 더 명확해졌습니다.
HUSTLE 오프라인 모임: HUSTLE은 B2B 마케팅과 세일즈에 대한 이야기를 나누는 커뮤니티에요. 온라인 커뮤니티를 들어간지는 좀 오래 되었는데, 처음으로 오프라인 모임을 참석했어요. 최근 마케터/사업개발 매니저 채용을 시작하면서 실제 필드에서 해당 직무로 일하고 있으신 분들의 고민을 들어보고 싶다는 목적이 컸는데요. 마침 B2B 마케팅/세일즈 업무를 하면서 겪을 수 있는 여러 가지 챌린지에 대한 내용이 주제로 발제되었고, 큰 도움이 되었습니다. 특히 자기 자신에 대한 기대치를 낮추고, 세상 사람 모두가 날 싫어한다.라는 생각으로 일하라는 대목이 인상 깊었습니다.
도커 오프라인 스터디: 벌써 3회차를 맞이한 스터디입니다. 격주 일요일 오프라인으로 진행하고 있고, 앞으로 3회차만 더 하면 끝나네요. 이 스터디는 단순히 책을 읽고 서로의 생각을 공유하는 것에서 끝나는게 아니라 아젠다에 대하여 이야기 나눠보고, 스터디 주최자인 제가 그때그때 유용할만한 주제의 세션을 진행하는 방식으로 이루어지고 있어요. 이번 주는 책의 챕터가 컨테이너 모니터링과 Observerbiliity에 대한 이야기를 다루고 있었고, 세션은 도커는 무엇으로 어떻게 구성되어 있을까?라는 타이틀로 컨테이너와 도커, 그리고 Runc에 대한 이야기를 담아냈습니다.

Think

결정적 순간의 대화

결정적 순간의 대화는 동명의 번역서인데요. SLIT 모임을 만들어주신 인프랩의 홍연의님이 한기용님에게 추천 받았다며 추천(리퍼럴에 리퍼럴)해주셨어요. 아직 모두 읽어보진 못햇지만, 읽어보면서 공감가는 주제가 많았는데요.

이 책은 중요한 주제에 대한 대화가 성공적으로 이루어질 때 개인과 조직이 어떤 변화를 이끌어낼 수 있는지에 대한 이야기를 다루고 있어요. 특히 감정적으로 민감한 상황에서도 자신의 의견을 효과적으로 전달하고 상대방의 의견을 듣는 방법에 대해 다양한 실제 사례를 들어주고 있어 쉽게 이해할 수 있었어요.

그 외에도 대화를 유도하고 해결책을 도출하는 데 필요한 도구와 기술을 제시하면서 실제 상황에서 대화를 성공적으로 이끌어내기 위한 방법도 제시해줘요. 전반적으로 개인과 조직의 커뮤니케이션 스킬을 향상시키고, 어려운 상황에서도 건설적인 대화를 하는데 큰 도움이 될만한 내용으로 꽉차있습니다.

번아웃을 한 번에 해결할 수 있는 방법은 성과다

Tue, 27 Feb 2024 21:12:17 GMT

번아웃을 막는 건 워라밸이 아니다라는 게시글을 읽었습니다. 글의 시작에 아래와 같은 문장이 적혀있었는데, 너무 공감되는 말이라 번아웃에 대한 생각을 이야기해 보려 해요.

내가 생각하기에 일하면서 듣는 (또는 하는) 가장 어색한 말 중 하나가 야근하고 있는 사람에게 ‘천천히 하세요, 그러다가 번아웃 와요’ 하는 말이다.

주로 업무 압박이나 스트레스로 인해 자신을 잃어버린다는 느낌을 받을 때 나 번아웃 상태야라며 말하곤 하는데요. 저는 번아웃을 한 번에 해결할 방법은 성과라고 생각해요. 성과를 내기 위해 열심히 달려 나가는데, 막상 결실은 없으니 점차 지쳐가는 거죠.

그래서 조직은 항상 불타고 있는 상태가 가장 좋은 것 같기도 해요. 열심히 달리다가 갑작스럽게 느껴지는 온화함과 여유로움이 오히려 더 불안을 가져다주기도 하거든요. 간혹, 상대방의 상황을 고려하지 않고 자신의 상황에 빗대어 조언하는 경우를 접하는데요. 이런 조언은 최악의 조언이라고 생각해요. 가령, 위에서 예시로 보여준 그러다가 번아웃 와요라던가, 제가 해보니까 건강이 최고예요 같은 조언이에요.

사람마다 각자 성과를 내는 방법이 있고, 시기에 따라 주어진 기회는 한정적이에요. 그래서 그때 해볼 수 있는건 그때 해봐야만 하는 것 같아요. 그것도 내가 충분히 만족할 만큼이요.

그래야만 나의 능력 범위를 알아낼 수 있고, 그에 따른 목표 설정 경험도 해볼 수 있어요. 나의 능력 범위 내에서 최선을 다해보는 경험이 없다면 앙꼬 없는 찐빵 같은 커리어를 만들어 나가고 있을 가능성이 높아요.

여기서 이야기하는 능력 범위라는 개념은 시간이 지나면서 쌓아온 지식과 전문성의 영역을 의미해요. 우리는 모두 자신이 잘 이해하는 영역과 이해하지 못하는 영역을 가지고 있어요. 핵심은 자신이 가지고 있는 능력 범위를 파악하고, 충실하게 그 범위 안에서 행동하는 게 중요해요.

내 직무의 책임과 역할은 무엇인지
내가 잘하는 것은 무엇인지
내가 아는 것과 모르는 것의 경계가 어디에 있는지
내가 우위를 점하고 있는 영역은 어디인지

우선 능력 범위를 이해하고, 능력 범위 밖(자신이 모르는 것)은 멀리하면서 내가 잘할 수 있는 것을 단단하게 만들어야만 해요. 그 이후에 점진적으로 확장해 나가세요.

간혹 능력 범위 안에 머무르는 것을 두려워하는 것을 자주 목격하기도 해요. 특히 Engineering 조직에서 흔히 보이는데요. 이는 고립공포감(FOMO; Fear Of Missing Out)이라고 부르기도 하는 현상이에요. 하지만 능력 범위 안에서 머무르는 것은 여러 이점이 있어요.

더 높은 성공 확률: 진정으로 이해하고 있는 것에만 집중하면, 성과를 극대화할 수 있어요.
자신감: 자신의 논지에 의문이 들지 않고 확신을 가지고 움직이게 돼요. 자신만의 조타실 안에 있으면, 추측할 일이 없어져요.
위험 감소: 이해하고 있는 것만 고수하면, 영구적인 실패 가능성이 작아져요. 이해하지 못하는 것은 예상치 못한 위험을 가져와요. 이를 피하면 변동성이 줄어들어요.
더 나은 결정: 실제 지식과 추측에 기반하여 선택할 수 있어요. 자신의 전문 지식 내에서 사실을 과대광고보다 우선할 수 있어요.
더 빠른 학습: 기본 이해가 있을 때 새로운 분야를 마스터하기 더 쉬워요.
혁신: 전문성은 창의적이고 새로운 아이디어를 촉진해요. 진정한 변화와 혁신은 깊은 지식에서 나와요.
마음의 평화: 검증된 능력 범위 안에서 활동하면 무한한 마음의 평화를 얻을 수 있어요.

물론, 현실에 안주하고 하던 것만 하라는 이야기는 아니에요. 내가 해야만 하는 것과 잘할 수 있는 것을 명확히 인식하고 그것부터 잘하다 보면 성과를 낼 수 있고, 번아웃은 오지도 않을 거에요.

[주간회고] 2024년 8주차

Sun, 25 Feb 2024 21:09:03 GMT

Do: Work

다중 워크스페이스 기능 업데이트: 대표님 한 분이 여러 사업장을 운영하고 계신 경우가 많다는 걸 최근 고객 인터뷰를 통해 알게 되었는데요. 유료 고객 중에서도 이와 같은 페인 포인트를 가진 고객이 있었기에 빠르게 이를 지원하기 위한 업데이트를 선보였습니다.
세금계산서 변경 이력 기능 업데이트: 볼타 서비스를 협업 도구로 사용하는 고객이 늘어남에 따라 세금계산서에 대한 전체 변경 이력(생성, 승인, 변경부터 발행, 이메일 발송 등)을 확인하실 수 있게끔 업데이트를 선보였습니다.
볼타코퍼레이션-택스어드바이저스, 전략적 제휴: 법인 시장 공략을 위해 법인 전문 세무 서비스를 제공하는 택스어드바이저스와 전략적 제휴를 맺었습니다. 택스어드바이저스는 볼타의 파트너이자 주요 고객이기도 합니다. 볼타코퍼레이션-택스어드바이저스, 전략적 제휴…"법인 시장 공략 확대"
채용 페이지 리뉴얼 & 본격 마케터 채용 오픈: 기존에는 프로덕트 엔지니어(FE/BE) 포지션만 오픈 해두고 채용을 진행하고 있습니다. 최근 RoundHR에 채용 페이지 기능이 업데이트되면서 팀 채용 페이지도 리뉴얼하였는데요. 그와 동시에 콘텐츠 마케터 채용도 본격적으로 시작하였습니다. 볼타(Bolta) 채용 : 볼타는 고속성장 중!

Do: Academic

주주 총회 세미나: 볼타는 2023년 4월 창업하여, 올해가 2년차가 되는 기업입니다. 그 사이 여러 투자를 받으며 기관투자자를 비롯한 주주가 늘어났는데요. 3월 정기 주주 총회 시즌을 앞두고 그래도 대략은 알아두면 좋을 것 같아서 평소 도움을 많이 받고 있는 법무법인 디라이트의 주주 총회 세미나를 다녀왔습니다. 정기주주총회 준비 101
Frontend System Engineering: 미래에 출시 될 제품과 서비스에서도 볼타의 브랜드를 잘 녹여내면서도 UX의 유려함을 지켜내기 위한 고민을 이번주에도 가졌습니다. 저번주에는 단순히 혼자 생각하고 자료를 리서치하는 수준에서 그쳤는데, 이번주에는 프로덕트 디자이너분에게 고민을 털어놓고 이야기 나누었습니다. 다음주는 프론트엔드 엔지니어분과 함께 방향성을 논의해본 뒤 팀 전체에 내용을 공유드리고자 합니다.
유료화, 그 이후 (After Willingness to pay) 게시글 발행: 얼마 전 Disquiet에 공유된 유료화 관련 경험 공유 게시글을 보고 느낀 점을 정리해보았습니다. 유료화, 그 이후 (After Willingness to pay)

Think

채용

Contents Marketer: 콘텐츠 마케터 채용을 오픈하면서 어떤 분을 모시면 좋을지에 대한 많은 고민이 있었는데요. 공동창업자인 문혁님과 고민 끝에 내린 결론은 아래 중 하나라도 해당하시면 좋겠다는 결론이었습니다.

제품 팀의 일과 고객의 Wow moment를 이해하고, 이를 널리 알리는게 즐거우신 분
B2B IT 업계에서 Product Manager, Data Analytics, Product Designer 등 다른 직무로 일해보았지만 마케팅 업무가 적성에 맞는 것 같다고 느끼시는 분
마케팅 업무가 너무 즐겁고, 이제는 마케팅 성과를 내보고 싶으신 분
Growth를 위한 업무 뿐 아니라 Product 자체에 대한 경험과 이해를 기르고 싶으신 분

그러던 중 우연히 다른 산업에서 다른 직무로 업을 해오시다가 PM 포지션으로 전직하신 분을 알게 되었는데요. 하고 계신 업무가 100% PM에 Fit하다기보다는 고객의 Pain Point와 Wow moment를 이해하고, 이를 효과적으로 정리하고 팀 내외에 알리시는 모습이 Lead Acquisition 업무라는 느낌을 받았습니다.

개인적으로는 이분이 발행하시는 콘텐츠의 이미지와 텍스트 모두 멋들어졌기에 Contents Marketer 또는 Lead Acquisition Manager 같은 포지션도 잘 어울리시지 않을까 생각들었습니다. 동시에 팀에서도 이런 분을 콘텐츠 마케터로 모시면 좋을 것 같았네요. 🙂

Product Engineer: 프론트엔드와 백엔드 모두 장기적인 생산성을 위한 System Engineer과 Platform Engineering이 필요하겠다는걸 느끼는 시점인데요. 콘텐츠 마케터보다 더 많은 고민을 하면서 채용을 진행하고 있는 포지션입니다. 😅 추후 생각이 더 정리되면 다시 한번 글로 다뤄보겠습니다.

유료화, 그 이후 (After Willingness to pay)

Sun, 25 Feb 2024 12:41:25 GMT

지금까지 스타트업의 발전이란 일단 PMF(Product Market Fit)를 찾으면 빠른 성장을 목표로 투자를 받고 사람을 더 뽑는 루프를 계속 돌리는 형태로 가는 것이 일반적이었는데요. 이제는 아닙니다.

자금 시장이 공포에 얼어붙었고, 스타트업 투자보다 더 매력적인 투자 상품이 너무 많아졌습니다. 특히 Gen AI 등으로 인해 한 사람이 할 수 있는 일의 양이 점점 커지는 상황에서 성장을 위해 위험하게 몸집을 불리는 것보다는 적은 인원이 최대의 효율을 내는 정도로만 팀을 유지하는 게 더 바람직하지 않나 싶기도 합니다.

과거에는 서비스 출시 초기부터 플랫폼이나 커뮤니티 비즈니스를 추구하더라도 문제가 없었지만, 지금은 Apple 같이 누구나 인정할 만한 강력한 Power를 가진 게 아니라면 어려워졌습니다. 현재의 자금 시장은 그 정도 인원이 모일 때까지 기다려주지 않습니다.

그러다 보니 많은 스타트업이 매출에 대한 챌린지를 받고 있습니다.

그래서 돈은 어떻게 벌건가요?
광고 말고 다른 BM은 없나요?

서비스를 유료화한다고 하면 사용자 행동에 대해 단건으로 비용을 받거나(5,000원에 커피 원두 1회 배송), 서비스에 큰 효능감을 느끼는 사용자를 대상으로 멤버십 구독 비용을 받는 방법(월 8,000원에 커피 원두 월 2회 정기 배송)이 가장 대표적입니다. 그 외에 사용량(Usage)에 기반하여 정기적으로 비용을 청구하는 방법도 있습니다.

어떤 방법이든 유료화를 하고 나면 또 다른 고민이 생깁니다.

비용을 지불하는 고객의 목소리에 귀 기울이면서 꾸준한 수익화 이루어내기
돈을 낼 정도로 효능감을 느낀다는건 증명했으니, 스케일업과 더 많은 트랜잭션을 위해 무료로 전환하기

정답도 없고, 산업과 사업 아이템에 따라 다르겠지만 항상 고민되는 부분입니다. 성급한 유료화로 인하여 충분한 고객층을 확보하지 못하여 스케일업에 실패하기도 하고, 무작정 스케일업만 추구하다 정작 비용 지불 의사를 가진 고객을 뾰족하게 정의하는 타이밍을 놓치기도 합니다.

그럼에도 고객으로부터 돈을 실제로 벌어보는 경험 자체는 의미 있다고 생각합니다. Willingness to pay를 실제로 찾아낸 것이니까요. 물론 둘 중 어떤 선택을 했든 미래에는 그 선택을 후회하거나 그때 반대 선택을 했다면 어떻게 됐을까?라며 과거를 회상할 수도 있을 겁니다.

하지만 모든 스타트업은 어떤 선택에 대해 후회하기보다 Lesson 한마디로 이 선택을 정리 할 수 있어야 합니다.

Startup = LLM(Lessons Learned Machine)

스타트업은 Lessons Learned Machine입니다. 아래 네 가지를 계속 반복하는 기계라고 볼 수 있는건데요.

Experiment
Fail
Learn
Repeat

여기서 말하는 실험(Experiment)은 수많은 백데이터를 축적하고, 데이터 마트와 데이터 웨어하우스를 구축한 뒤 멋들어진 가설을 세우고 데이터를 기반으로 성공과 실패를 결정하는 행위를 의미하는 것만은 아닙니다. 데이터 없이 직관만으로 실행하는 실험도 존재합니다. (실험과 관련된 이야기는 다른 게시글에서 다루어보겠습니다.)

결국 모든 스타트업, 즉 우리의 목표는 Growth(성장)입니다. 성장을 해야만 성공 할 수 있으니 Growth = 성공이라고 볼 수도 있는데요. 이 과정에서 제품, 마케팅, 엔지니어링, 디자인 등 다양한 영역과 요소에서 다양한 의사 결정을 하게 됩니다.

이러한 과거 의사 결정에 대해 후회하고, 혼란스러워하는 이유는 크게 세 가지입니다.

문제 정의 자체를 잘못한 경우: 닥치는 대로 하면 성공과 실패를 명확히 정의 내릴 수 없습니다.
문제 정의는 잘 했는데, 전진과 후진을 반복하는 경우: 방향을 잡았다면 멈추지 말고 달려야 합니다. 앞으로 갔다가 뒤로 갔다 반복하는 경우 '그때 최선을 다할걸'이라며 후회하게 됩니다.
실행을 어떻게 할지만 고민하는 경우: 무엇을 할지가 중요하지, 어떻게 할 것인지는 중요하지 않습니다.

결과가 부정적이어도 괜찮습니다. 하나의 실험을 했을 뿐이고, 실패로 학습했다면 그걸로 충분합니다.

우리 모두 실패 했더라도 의기소침하지 맙시다. 모든 프로덕트 메이커 파이팅입니다!

[주간회고] 2024년 7주차

Sun, 18 Feb 2024 21:57:13 GMT

Do: Work

채용 커피챗: 여느 때와 다름없이 팀에 관심 가져주시는 분들과 고객과 제품 그리고 팀에 대한 이야기를 나누는 자리를 가졌습니다. 그중 이야기 나누는 내내 생동감 있는 시간을 보낸다는 생각이 들었던 분이 계셨는데요. 특히 챌린지하고자 하는 열정과 프론트엔드 시스템 엔지니어링에 대한 관심과 역량이 느껴져 다음 전형을 진행하게 되었습니다. 🙂
다중 워크스페이스 지원을 위한 사전 코드 작업: 현재 볼타 서비스는 1개의 계정이 1개의 워크스페이스에 소속되는 구조(1:1)입니다. 고객이 늘어나면서, 하나의 계정으로 여러 워크스페이스를 관리하고 싶다는 VoC가 종종 들어오고 있었는데요. 신규 기능 개발 시 약간 텀이 발생할 때를 이용하여 이를 지원하기 위한 사전 코드 작업을 해두었습니다. 처음 제품을 개발할 때부터 1:N 구조가 될 수 있다고 판단하고 확장할 수 있게끔 구조를 잡아두어서 금방 마무리할 수 있었습니다.
감사기록 사전 코드 작업: 감사기록(Audit History)는 특정 리소스의 변경 이력을 기록/관리하는 기능을 부르는 용어입니다. 기존에는 사용자에게 보여지지는 않고 운영을 위해서만 저장하고 있었는데요. 볼타 서비스를 자금 업무 협업 목적으로 사용하는 고객이 늘어나면서 사용자에게 제공하기 위한 코드 작업을 진행했습니다.
세금계산서 발행 처리 아키텍처 고도화: 볼타 서비스는 세금계산서 발행이 트리거되는 부분이 다양합니다.(관리자의 간편발행, 예약발행, 멤버가 올린 요청에 대한 관리자의 발행승인, 수정발행 등) 그리고 이들의 자세한 데이터 모델과 전처리/후처리 로직도 미세하게 다른데요. 조금 더 고도화 할 수 있는 부분이 보여 약간의 작업을 진행 했습니다.
Next Feature Overall Sketch: 2024년 8주차에 릴리즈될 예정인 2개의 기능에 대한 팀 단위 스케치와 사전 설계를 진행 했습니다.

Do: Academic

`Detail about Amazon, Coupang`

Customer Obsession의 대가로 알려진 Coupang과 Amazon에 대한 창업 초기 이야기를 살펴보았습니다.
여러가지 이야기가 있었지만 지금은 널리 알려진 내용을 10년, 15년 전에 이미 이야기하고 있었다는 부분이 놀라웠는데요.
그 중 쿠팡 김범석 대표님의 창업하면 누구나 하기 쉬운 5가지 실수가 인상 깊었습니다.

모든 것을 잘하려고 한다
- 스타트업은 특히나 가지고 있는 자원이 한정적이다.
- 창업 초기에는 모든 의사결정에 회사의 생사가 걸려 있기 때문에 모든 것을 다 챙기려고 하는 실수를 저지른다.
- 한가지의 핵심 경쟁력을 파악하고 그것에 집중하라
- 올해 다른건 다 포기해도 꼭 이루어 내야하는 한 가지는 무엇인가?라는 질문에 답할 수 있어야 한다.
고객이 아닌 경쟁에 집중한다
- 장기적인 성공은 결국 고객이 결정한다.
- 고객은 내부 고객(팀원)과 외부 고객(제품을 사용하는 사람들)로 나뉜다.
- 쿠팡은 매출이 3억원 나올 당시에도 외부 고객 만족을 위해 상담원 인력을 100명으로 파격적 증원했다.
- 경쟁사와의 상대적인 순위가 시장을 결정하기보다는 내부 고객과 외부 고객의 만족이 성공을 결정 짓는다.
선입견 또는 문화적 결정론에 빠진다
- 쿠팡의 모든 조직은 수평 조직 방식으로 운영되고 있다.
- 처음 도입시에 '한국에서는 이런 시도가 어차피 통하지 않을 것이다.'라는 부정적 의견이 나왔다.
- 하지만 지금은 쿠팡 직원들의 만족도가 높은 문화로 자리매김했다.
- 만약 한국적 문화에만 함몰 되어 있었다면 2002년 히딩크의 기적이 가능했을까?
- 동서양의 장점이 융합된 기업 문화를 지향하자
구성 인력에 맞춰 사업을 운영한다
- 사업 확장기에는 자연스레 인력을 충원 할 필요가 생긴다.
- 조직을 새로 구성할 때 기존 구성원들의 입사 순서나 사업 기여도를 고려한다.
- 하지만 그 정도가 사업의 방향을 좌지우지할 정도가 되어서는 안 된다.
- 사업과 성장에 맞춰 인력을 과감히 구성 해야 한다
문화보다 실적을 먼저 챙긴다
- 쿠팡은 인재를 크게 두 가치 축, 실적과 가치관을 바탕으로 평가한다.
- 이에 따른 네 가지 분류 중 조직에서 가장 문제인 사람은 실적은 좋지만 가치관이 안 맞는 사람, 즉 독(poison)에 속하는 사람이다.
- 장기적으로 독(poison)보다는 물음표(?)에 속하는 사람이 별(star)가 될 수 있도록 과감하게 기용할 수 있어야 한다.
- 비즈니스를 성립 시키기 위해서 기업문화가 존재하는 것이 아니라 기업문화를 성취하기 위한 도구로서 비즈니스가 존재하는 것이다.
- 문화가 없으면 장기적인 성과도 없다

쿠팡이 인재를 보는 시각

김범석 대표님의 시각에서는 우측에 보이는 것 처럼 기업문화가 비즈니스를 아우른다.

`Frontend System Engineering`

서비스 개발에 있어서 가장 중요한 부분은 서비스 개발 속도를 효율적으로 끌어올려 비즈니스를 성공시키는 데 기여해야 한다는 점입니다. 처음에는 손이 가는 대로 제품을 만들어내는 게 가장 빠릅니다. 하지만 팀원이 하나둘 늘어나고 기능이 수십 개를 넘어가는 순간 개발이 느려집니다. 제품을 만드는 개발자들은 어떻게든 이 비효율을 해소하여야만 합니다.

제품 개발 시 다양한 부분에서 느려질 수 있겠지만, 최근에는 Frontend Engineering 영역에 대한 비효율 해소하기 위한 방법에 집중하고 있습니다. 특히 개발자는 직관적으로 사용할 수 있고, 디자이너의 의도도 충분히 반영 가능하지만 시스템 수준에서 의도하지 않은 사용은 방지하는 디자인 시스템 구현체는 어떤 인터페이스를 가져야 할까? 고민하고 있습니다.

볼타는 현재 고객에게 제공되고 있는 서비스 외에도 몇 가지 서비스를 더 준비하고 있는데요. 미래에 출시 될 제품과 서비스에서도 볼타의 브랜드를 잘 녹여내면서도 UX의 유려함을 지켜내기 위해 고민하고, 준비해 나가면서 여러가지 아티클과 영상을 살펴보는 시간을 가졌습니다.

Think

Frontend Engineering Deep-Dive: 최적화, 공통화, DX, UX 등 부가적인 부분을 향상하기 위해 여러 가지를 고민하고 있습니다. 이를 위해선 Frontend Engineering 영역을 조금 더 깊게 파악해 볼 필요가 있으나 여전히 깊게 살펴보지 못하고 있어 항상 아쉬움이 듭니다. 다음 주에는 오픈소스 Design System을 조금 살펴보고, Next.js를 이용한 One Day Semi Project를 한 개 해보면서 조금 더 익숙해져보려고 합니다.

[주간회고] 2024년 6주차

Sun, 11 Feb 2024 21:41:23 GMT

Do: Work

2024년 6주차는 팀 전체가 조금은 쉬어가면서 밀린 부채를 해소하는 시간으로 보냈는데요. 미루고 미루던 부채들을 좀 많이 해소할 수 있었습니다.

WBR 개편: WBR은 Weekly Business Review의 약자로 주요한 비즈니스 지표를 주 단위로 기록하고, 공유하는 도구인데요. 유료화를 시작하면서 유료 플랜 구독과 관련된 비즈니스 지표를 추가하였습니다.
본격 유료화: 유료화를 시작하고, 2주간 제공되던 무료 체험이 종료됨에 따라 유료 전환이 다수 발생했습니다.
TechRND: 볼타는 제품 특성상 고객의 민감 데이터를 다루어야 하는 일이 잦은데요. 이를 위해 사용하고 있는 암호화 관련 기술을 고도화하기 위한 RND를 진행했습니다. 그 외에도 몇 가지 크고 작은 RND를 함께 진행했습니다.
Next Feature Overall Sketch: 2월 말 릴리즈를 목표로 개발준비 단계에 있는 기능이 있습니다. 이 기능에 대한 구체적인 기획에 앞서 대략의 사용자 Flow 스케치를 해두었습니다.
채용 원칙 정리: 볼타 창업 당시 공동창업자인 문혁님과 함께 둘만의 채용 원칙을 정했었는데요. 그 이후 2023년 3분기 채용을 거치며 지금에 이르기까지 그 원칙과 생각이 조금 더 구체화 된 것 같다는 생각이 들어 [볼타 이야기] 채용 원칙이라는 글을 작성했습니다.

Do: Academic

TDD(Test Driven Development)에 대한 단상: 최근(사실 더 과거부터) TDD에 대한 이야기가 자주 등장합니다. 저는 TDD에 대한 장점은 공감하고 있지만, 항상 필요한가?라는 의문을 가지고 있었는데요. 우연히 보게된 영상에 제가 평소에 가지고 있던 생각과 비슷한 의견이 담겨있어 놀랐습니다. 영상 속 댓글을 인용하자면 아래와 같습니다. / 영상: 효율적인 테스트 코드 작성법-포프TV

소프트웨어 개발, 테스팅 또한 경제적인 활동이다. 자원(시간, 인력)을 적게 투입하여 최대한의 효용을 뽑아내어야 한다.
코드에 따라 유닛 테스트는 필요할 때도 있고 필요하지 않을 때도 있다.
유닛 테스트가 필요한 경우는 다음과 같다.
1. 알고리즘이 매우 복잡하지만 수학적으로 잘 정의된 경우, 구현상의 명백한 버그를 없애기 위해 필요하다.
2. 제품이 실제로 사용되고 발전하면서 자꾸 변하거나 가정이 틀리는 부분의 버그를 없애기 위해 필요하다.
1에서는 TDD가 어느정도 유용할 수 있으나, 2에서는 쓸모가 없다.
- Why? 코드의 어떤 부분이 변경될지 예측하는 것은 어렵기 때문이다.
- TDD 방식으로 모든 코드에 대해 테스트를 작성하는 경우, 2번 상황에서 코드를 변경할 때에 테스트가 발목을 잡는다.
그러므로 (포프는) 제품 코드 전에 테스트 코드를 작성하자는 TDD 방식을 사용하지 않는다. 일단 코드를 작성하고, 실제로 버그가 일어나고 가정이 틀리는 시점에서 그에 대한 테스트 코드를 작성한다.

TDD를 하지 말자!라는 이야기는 아닙니다. 온전히 예측 가능한 코드를 작성할 때에만 TDD가 유효하며, 동시에 그런 경우는 잘 없다고 생각합니다. TDD와 별개로 적절한 테스트코드는 필요하다고 생각합니다.

Think

도파민 중독: 스타트업 대표/창업자 모임, 리더 모임 등에서 일도 도파민이라는 이야기가 나왔습니다. 이전까지는 일상에서 크게 재미를 느끼는 것 없이 가장 좋아하는 것, 잘하는 것을 하고 있을 뿐이라고 생각했는데요. 이 이야기를 듣고 잠시 충격을 받았습니다. 사실 저를 비롯한 그 모임의 모든 사람은 일이라는 도파민에 중독되어 있는 사람이었던거죠. 무의식중에 더 나은 고객 만족을 위해 일종의 중독적인 동기부여를 느끼고 있었습니다. 여기까지 생각이 미치고 과거를 돌이켜보니 지금 가장 기회가 많고, 기대도 많이 받고 있기 때문에 더 열심히, 잘해야겠다는 생각이 들었습니다.
두려움 없는 조직: 스타트업 리더 주간 회고 모임에 함께하고 계시는 분이 추천해 주신 책인데요. 왜 침묵하게 되는가, 왜 그들은 침묵하는가에 대한 이야기를 다루고 있습니다. 결론은 심리적 안정감 6글자로 요약할 수 있다고 합니다. 시간 될 때 한번 읽어보려고 합니다.🙂 추천해 주신 분의 리뷰: [두려움 없는 조직] 책 리뷰

Keep

Customer First 기조 유지하기
채용 원칙 유지하기

Problem

Customer First는 쉽지만, 여전히 Customer Obsession는 어렵습니다.

Try

Amazon, Coupang의 Customer 관련 아티클 읽어보기: 아마존과 쿠팡은 비슷한 듯 미세하게 다른 고객 철학을 가지고 있다고 익히 전해 들었는데요. 이번 기회에 관련 아티클을 읽은 후 정리 해보려 합니다.
Tech RND 사내 전파: 최근 제품 개발이 너무 바빠 Tech RND 과정과 결과를 문서로만 기록하고 있는데요. 조금 더 적극적으로 전파해 보면 좋을 것 같아 별도 세션을 잡고 적극적으로 공유 해보려 합니다.

[볼타 이야기] 채용 원칙

Mon, 05 Feb 2024 21:05:12 GMT

볼타 창업 당시, 공동창업자인 문혁님과 함께 둘만의 채용 원칙을 정했었는데요. 그 이후 2023년 3분기 채용을 거치며 지금에 이르기까지 그 원칙과 생각이 조금 더 구체화 된 것 같습니다. 이 글에서는 그 이야기를 적어보려고 합니다.

첫 번째 채용 원칙

정말 의외이지만 처음에 가졌던 원칙은 같이 일해본 적 있는 분들은 최대한 풀타임으로 모시지 말자였습니다. 많은 팀이 기존에 같이 일해봤던 분들을 모셔 오는 경향이 있는데요. 저희는 완전 반대의 길을 선택했다고 볼 수 있습니다. 초기 제품 개발은 공동창업자 두 명으로 충분했습니다. 속도도 큰 문제 없었고요. 물리적으로 시간이 부족했던 시기에만 지인분들을 파트타임으로 모셔서 함께 했습니다.

같이 일해본 적 있는 분들을 풀타임으로 모시지 않았던 이유는 크게 세 가지였습니다.

조직의 개성이 없어진다: 이미 비슷한 경험을 해왔던 사람끼리는 서로에게 새로운 자극을 주기 어렵습니다. 새로운 자극은 더 높은 챌린지를 달성하기 위해 노력하고 경쟁하는 데 큰 도움을 주는 요소이기 때문에 조직의 개성이 중요하다고 생각했습니다.
건강하게 싸우기 힘들다: 제품을 만들다 보면 팀 내에서 의견이 충돌하거나 갈등이 발생하는 경우가 자주 있습니다. 이때 이미 친분이 많이 쌓여있는 경우 친분이 틀어지는 게 두렵고, 나쁜 사람으로 기억되는 게 싫어서 갈등을 회피하기도 합니다. 이는 조직의 발전에 큰 제동을 걸 수 있는 포인트라고 생각했습니다.
의도하지 않은 커뮤니케이션 생략이 발생한다: 이미 서로에게 익숙한 경우 눈빛만 봐도 서로의 생각을 유추할 수 있기도 합니다. 불필요한 커뮤니케이션을 줄여 더 높은 생산성을 만들어 낼 방법은 맞지만, 팀원이 늘어날수록 의도치 않게 파벌이나 눈에 보이지 않는 벽이 생길 수 있는 부분이기도 합니다. 장기적으로 봤을 때는 큰 문제점이라고 생각했습니다.

두 번째 채용 원칙

2023년 2분기에서 3분기에 걸친 채용을 경험하면서 채용 원칙은 조금 더 구체화 되었습니다. 당시 채용을 위해 채용 플랫폼에 채용 공고를 정말 적극적으로 올렸었는데요. 세 분을 모시는데 약 3,500분 정도가 지원해 주실 정도였습니다. 모 채용 플랫폼에서는 인기순 정렬 시 1위를 2주 연속으로 유지하기도 했었고요. (정작 모시게 되었던 분들은 모두 이메일이나 자체 채용 플랫폼, 링크드인 등으로 지원해 주신 분들이었습니다)

많은 분의 이력서를 검토하고, 과제를 드려보기도 하고, 인터뷰를 진행하면서 많이 배울 수 있었습니다. 가장 크게 느꼈던 부분은 제품 개발 뿐 아니라 HR에서도 Fast Fail이 중요하다는 점이었습니다. 기존에는 이력서 제출 -> 검토 -> 사전 과제 -> 온사이트 인터뷰(3시간~4시간)의 흐름을 가져가면서 온사이트 인터뷰까지 짧으면 2주, 길면 3주에서 4주까지 걸리기도 했습니다. 후보자와 회사 모두 많은 시간을 할애하였던 것인데요. 막상 인터뷰까지 모셨지만 저희 팀이 생각하는 가장 중요한 부분에 대한 부분이 아쉬워서 불합격 소식을 안내해 드리는 경우가 많았습니다.

이에 채용 전형을 이력서 제출 -> 검토 -> 사전 인터뷰(온라인, 30분 남짓) -> 사전 과제(대부분 생략) -> 온사이트 인터뷰(3시간~4시간)로 변경하였고, 사전 인터뷰에서 꼭 확인하고자 하는 부분을 글로 정리하였습니다. 그리고 이게 곧 채용 원칙의 일부가 되었습니다.

팀의 Fit과 맞으면서 최대한 기존 팀에 없는 캐릭터를 지니신 분을 모신다: 채용 시 팀원들과 잘 맞을지 1순위로 판단하고, 합류 시 팀원들이 새롭게 배울 수 있는게 명확하신 분을 모신다.
주요 포지션의 양적 확장이 가능하신 분을 모신다: 기존 팀원들이 하는 일을 당연히 할 수 있으면서도 새로운 영역으로 확장하는데 기여하실 수 있는 사람을 모신다.

현재의 채용 원칙

볼타 팀은 2024년 시작과 함께 Pre-A 투자 유치 소식을 공개적으로 알렸는데요. 그와 동시에 신규 채용을 시작하였고, 기존의 채용 원칙과 과거 채용 프로세스를 회고해보며 채용 원칙을 다시 한번 정리하였습니다.

이전의 원칙들은 그대로 유지하면서 크게 6개의 원칙과 기준이 추가되었습니다.

같이 일해본 적 있는 분들은 최대한 풀타임으로 모시지 않는다.
팀의 Fit과 맞으면서 최대한 기존 팀에 없는 캐릭터를 지니신 분을 모신다.
주요 포지션의 양적 확장이 가능하신 분을 모신다.
근본적으로 회사에서 사람을 뽑는 이유인, 회사의 비즈니스를 실현하고 만들어 나가는 경험을 주도적으로 지금 하고 싶으신 분을 모신다.
미래에는 누구에게나 인정받는 제품 개발자가 되고 싶고, 이를 위해 필요한 기술적인 경험뿐 아니라 주도적으로 사업적 Impact를 내보는 경험, 그리고 제품 개발 조직을 함께 꾸려나가면서 배우는 다양한 경험까지 해보고 싶으신 분을 모신다.
훌륭한 동료들과 일하는 데에서 자극받는 분을 모신다.
직업적인 안정성을 갖고 안락하게 살며 큰 퇴직금을 받으며 다닐 수 있는 직장 생활보다, 시장에 혁신을 만들고 동료들로부터 존경받는 것이 훨씬 더 가치가 큰 분을 모신다.
조직 구성원들이 스스로 동기 부여되어서 열심히 일하며 서로를 자극하고, 더 높은 챌린지를 달성하기 위해 노력하고 경쟁하는데 기여해주실 수 있는 분을 모신다.
스스로 열심히 한다고 생각하는데, 나보다 더 열심히 하고 헌신하며 나에게 자극을 주는 사람들과 일하는 경험을 해보고 싶으신 분을 모신다.

꿈꾸는 조직 문화

저와 공동창업자 문혁님은 초기부터 팀원이 볼타를 떠나게 되었을 때 팀원들의 평가는 "그 사람 일 잘했지", "열심히 하지"보다 "정말 사랑받는 팀원이었어"라는 이야기가 나올 수 있는 문화를 만들고 싶다는 이야기를 자주 했는데요. 문득 그런 문화가 잘 만들어져 가는 것 같아서 다행이라는 생각이 듭니다.

최근 볼타 팀은 제품을 고도화 해나가면서 여러 가지 고민을 하고 있습니다.

금융/자금 업무를 필요한 정보만 확인하면서 편하게 하고 싶은 조직과 모든 정보를 상세하게 확인하고 싶은 조직. 전혀 다른 두 조직 모두가 편리하게 쓸 수 있는 기업 금융 플랫폼은 어떤 모습일까?
Frontend 제품의 안정성과 성능을 지속적으로 모니터링하고, 개개인의 역량에 의존하지 않고 함께 개선해 나갈 수 있는 Frontend SRE 문화는 어떻게 만들어 갈 수 있을까?
각기 다른 회사들의 다양한 업무 프로세스를 지원하면서 이를 자동화 할 수 있게 해주려면 어떻게 해야 할까?
민감 정보에 대한 접근을 제한할 수 있는 복잡한 권한 시스템을 적용하면서도 안정적인 성능을 제공하는 Open API는 어떻게 만들 수 있을까?
우리 팀과 제품의 존재 조차 모르는 고객들을 발굴하고, 우리 제품을 사용하게 하려면 어떻게 해야 할까?

미래에 창업을 꿈꾸고 계시거나, 마음 맞는 팀원들과 제품을 재미있게 만들어보는 경험을 하고 싶으시다면 볼타 팀에서 정말 귀중한 경험을 쌓으실 수 있을거라고 장담합니다.

B2B 마케터, 프로덕트 엔지니어(Frontend), 프로덕트 엔지니어(Backend) 포지션을 채용 중에 있으니 많은 관심 부탁드립니다. 볼타(Bolta) 채용 : 볼타는 고속성장중!

[주간회고] 2024년 5주차

Sun, 04 Feb 2024 21:15:20 GMT

Do: Work

리뉴얼 릴리즈 기념 회식: 볼타 서비스 리뉴얼은 꽤나 장기간으로 가져왔던 프로젝트입니다. 리뉴얼과 관련된 자세한 내용은 2023년 회고 게시글에서 다룬 적 있는데요. 정말 쉴 틈 없이 빠르게 달려왔기 때문에 피로를 푸는 느낌으로 회식을 진행했습니다. 🙂
외부 제휴사 미팅: 과거 제휴 논의를 해왔던 파트너사들과 밀린 미팅을 진행했습니다. 리뉴얼 릴리즈를 위해 기술과 제품 개발에만 집중하고 있던 시점이라 한없이 밀리고 있었는데요. 그래도 오랫동안 기다려주셔서 감사할 따름입니다.
스트롱벤처스 포트폴리오 밋업: 최근 볼타 팀은 스트롱벤처스로부터 Pre-A 투자를 유치하였는데요. 운 좋게도 직후에 분기별로 진행되는 스트롱벤처스 포트폴리오 밋업이 개최되었고, 이 행사에 다녀오게 되었습니다. 해당 행사에 참가하신 분 중에는 저희 고객사 분들도 계셨는데, 오프라인으로 처음 인사드리는 분들도 계셔서 만나 뵙게 되어 매우 반가웠네요.
채용 커피챗/인터뷰: 이번 주를 시작으로 본격적으로 신규 채용을 오픈하였습니다. B2B 마케터, 프로덕트 엔지니어(Frontend), 프로덕트 엔지니어(Backend) 포지션을 채용 중이며, 3분기까지 각 1명씩 모시는 걸 목표로 오픈해 두었지만 생각보다 많은 분들이 관심 가져 주셔서 후보자분들과 이야기 나눠볼 수 있는 시간을 가졌습니다.

Do: Academic

도커 교과서 스터디: 격주 일요일에 오프라인에서 모이는 도커 스터디를 진행하고 있는데요. 이번 한 주는 이 스터디를 위한 자료를 준비하고, 일요일에 모여서 스터디를 진행하였습니다.
찰리 멍거 바이블 2회독: 찰리 멍거 바이블은 2024년 1월 중순에 북클럽으로 읽었던 책입니다. 경제와 투자 관련 서적이지만, 현인들의 현자라고 불리는 찰리 멍거의 100년 치 인생 노하우가 담겨있는 책이라고 이야기해도 될 정도였습니다. 저는 항상 일을 잘하기 위해서는 내가 속해있는 섹터뿐 아니라 다른 섹터에 대한 이해를 바탕으로 새로운 방식의 문제 접근 방식이 필요하다고 생각했는데요. 찰리 멍거는 이를 격자형 멘탈 모델이라 소개하고 있습니다. 짧은 경험으로 어렴풋이 가지고 있던 생각이 100년의 현자와 비슷하다는 부분에서 놀랐고, 제 가치관이 더 명확해지는 기회였습니다. 다시 한번 리마인드하는 목적으로 완독 2주 뒤 한번 더 읽었습니다.

Keep

격자형 멘탈 모델에 대한 가치관 유지하기
사내 스터디 장려하기: 도커 교과서 스터디는 볼타 팀의 유일한 백엔드 개발자분과 외부 개발자분들까지 7명이 함께 하고 있는데요. 아무래도 작은 팀을 유지하다 보니 내부에서 다양한 사례를 공유하거나 기술을 공유하는 데에 있어 물리적인 한계가 있어 아쉬움이 있었습니다. 하지만 이번 스터디를 해보니, 백엔드 개발자분의 만족도가 높아 보여서 좋았네요. 🙂

Problem

그랜드 오픈은 신중하게 하기: 이전에 프라이머 권도균 대표님 께서 그랜드 오픈, 대규모 업데이트를 좋아하지 말라고 권고한다는 글을 쓰신 적 있는데요. 이 글을 읽었을 때 당시엔 '초기 스타트업 제품은 할만하지 않을까?'라고 생각했던 기억이 납니다. 하지만 실제로 리뉴얼을 준비하면서 그랜드 오픈/대규모 업데이트를 경험해 보니 아무리 초기 스타트업이어도 쉽지 않은 일이었습니다.

팀 매니지먼트, 프로덕트 매니지먼트, 실무 그리고 채용의 밸런스 조절: 이전 채용(2023년 3분기) 당시에도 여러 가지를 동시에 해오면서 하나하나 디테일을 챙기지 못한 것 같아 아쉬움이 있었는데요. 이번에 채용을 다시 시작하면서 약간씩 비슷한 징조가 보여 걱정이 됩니다.

Try

집중과 휴식을 시스템적으로 번갈아 하자: 팀 빌딩 초기부터 가지고 있었던 마음가짐입니다. 하지만 고객이 늘어나고 제품에 신경 써야 하는 것이 늘어남에 따라 잘 지켜지지 않았습니다. 이에 다음 주는 팀 전체가 쉬어가는 주간으로 보내보면 어떨까 하여 한 주정도 쉬어보려고 합니다. 물론 다른 회사처럼 아예 출근하지 않고 휴가!까지는 아니지만, 내부적으로 정비할 것들을 정비하는 시간으로 보내보고자 합니다.
고객과 팀에 최대의 시간을 쏟자: 채용이 아무리 중요해도 팀과 고객 그리고 제품만큼은 아니라는 생각이 문득 들었습니다. 최대한 대부분의 시간을 고객과 팀에 쏟고, 채용의 우선순위를 낮게 가져가 보려고 합니다. 메이저 채용 플랫폼에 공개적으로 채용 공고를 올리지 않고, SNS와 일부 아웃바운드 수준으로만 채용 기회를 노리고 있습니다.
주 1회 회고하기: 이 회고 글은 홍연의님이 만들어주신 IT 업계 스타트업 팀장 회고 모임 시간에 작성한 회고인데요. 매주 일요일 온라인으로 모여 각자 체크인 후 회고를 작성하고 매달 1회 모이는 방식입니다. 막상 회고를 작성해 보니 잊고 있었던 기억도 새록새록 나고, 생각을 정리하기 좋았던 것 같습니다. 빠지지 않고 잘 참가해 보려고 합니다. 공개적으로 공유하기 힘든 내용은 개인 메모로 작성 예정입니다.

[볼타 이야기] 작은 팀을 유지하려는 이유

Sun, 04 Feb 2024 13:45:50 GMT

이 글은 한기용님의 글 중 저희 팀이 생각하는 방향과 일치하는 부분이 있어 일부 재가공하여 작성되었습니다.

보통 스타트업의 장점은 빠른 의사결정 속도라고 이야기합니다. 하지만 나날이 성장하는 스타트업에서도 인원이 증가하고 인재 밀도가 낮아질수록 이 빠른 결정력은 점차 퇴화하는 경향을 보입니다. 마치 차량의 바퀴가 많다고 해서 더 빨리 움직일 것이라고 착각하는 것과 비슷한 맥락입니다.

물론, 그렇게 느려지더라도 스타트업은 대기업에 비해 의사결정 속도가 빠른 편입니다. 그러나 인원이 늘어나면서 더 많은 의사결정 레이어가 추가되고, 커뮤니케이션의 복잡성이 증가하는 등 새로운 도전에 직면하게 됩니다. 이러한 도전에 대처하려면 어떻게 해야 할까요?

신중한 의사결정: 바쁜 업무와 빠른 텀에 휘둘리기 쉽지만, 각 결정에는 신중한 고려가 필요합니다. 무분별한 의사결정은 오히려 업무 효율성을 떨어뜨릴 수 있습니다. 그러므로 중요한 결정에는 충분한 시간을 투자하고, 필요한 정보와 의견을 모아 팀 모두가 이해할 수 있도록 신중하게 판단해야 합니다.
불필요한 비용 최소화: 효과적인 커뮤니케이션을 통해 불필요한 비용을 최소화해야 합니다. 인원이 늘어남에 따라 의사전달이 더 어려워지고 오해가 증가할 수 있습니다. 이를 방지하기 위해 명확하고 투명한 커뮤니케이션 체계를 구축하는 것이 중요합니다. 팀 간의 협력과 정보 공유를 강화하면서 중간 단계의 의사결정 레이어를 최소화하여 불필요한 지연을 방지할 수 있습니다.
팀 내부의 업무 프로세스 최적화: 각자의 역할과 책임을 명확히 정의하고, 업무 흐름을 불필요한 복잡성 없이 단순하게 구성함으로써 의사결정 속도를 높일 수 있습니다. 업무의 목적과 우선순위를 명확히 이해하면서 일하는 것이 중요합니다.

일반적으로 규모가 커짐에 따라 특정한 역할을 염두에 두고 사람을 뽑기 시작하기 때문에 사업의 방향이 바뀜에 따라 새로운 역할로 배치하는게 어렵기도 하고, 매출이 나는 비즈니스를 버리고 새로운 것을 한다는 것은 생각보다 큰 뚝심과 결정을 필요로 합니다. 여기에 AI가 너무나도 빠르게 발전하다 보니 변화 방향성을 예측하기가 더 힘들어지고 있습니다.

가능하면 최대한 작은 규모를 유지하면서 점점 인재밀도를 높이는 방향으로 조직을 운영할 수 있다면 세상의 변화에 훨씬 더 빠르게 반응하면서 성장을 위한 성장이 아닌 건강하고 오래 갈 수 있는 성장을 할 수 있지 않을까? 생각됩니다.

관련 책: Company Of One: Why Staying Small Is the Next Big Thing for Business

이 책은 작은 규모를 유지함으로써 성장을 위한 성장에서 발생하는 골칫거리를 피할 수 있다는 내용을 담고 있고, 이와 관련된 부분을 사례 중심으로 잘 설명하고 있습니다.

정리

지금까지 스타트업의 발전이란 일단 PMF(Product Market Fit)를 찾으면 빠른 성장을 목표로 투자를 받고 사람을 더 뽑는 루프를 계속 돌리는 형태로 가는 것이 일반적이었는데 앞으로는 그렇지 않을 것으로 보입니다.

Gen AI 등으로 인해 한 사람이 할 수 있는 일의 양이 점점 커지는 상황에서 성장을 위해 위험하게 몸집을 불리는 것보다는 의사소통 비용이 많이 들지 않고 플랫한 조직으로 운영할 수 있는 정도로만 팀을 유지할 수 있다면 변화를 훨씬 더 빠르게 따라가면서 팀이 커지면서 생기는 다양한 이슈를 피할 수 있다는 점에서 매력적인 옵션이 아닌가 싶습니다.

실제로 볼타 팀도 최대한 불필요한 커뮤니케이션 비용을 다 줄이고, 효율적으로 일하기 위해 작은 팀을 유지하며 작은 팀의 강점을 모두 챙기기 위해 노력하고 있습니다. 이런 여정을 함께 하고 싶으시다면 언제든 연락주세요! 볼타(Bolta) 채용 : 볼타는 고속성장중!

[볼타 이야기] 결국 B2B는 잘 팔면 되는 거 아닌가?

Thu, 01 Feb 2024 00:15:12 GMT

최근 "결국 B2B는 잘 팔면 되는 거 아닌가?"라는 주제로 고민해 볼 기회가 있었습니다. 평소에도 자주 들리던 이야기였는데요. 이때 했던 고민을 조금 정리해서 작성해 보려고 합니다.

B2B 기업이 성장하는 방식은 크게 영업주도성장(SLG, Sales-led growth)와 제품주도성장(Product-led growth) 두 가지로 분류됩니다.

영업주도성장(SLG, Sales-led growth)

기업의 영업 담당자가 B2B 고객의 연락처(lead)를 확보하고, 상담을 통해 구체적인 니즈를 파악하여 견적이라는 형태로 기업 요구에 따라 맞춤 솔루션을 제안하는 방식입니다.

연 단위 라이센스나 사용자 수에 따른 사용료를 받으면서도, 기능 개선이 필요한 유지보수가 발생할 때마다 man month 단위로 개발 업무를 수행하기도 합니다.

조금 더 구체적으로는 영업 조직이 기업 전면에 나서서 불특정 다수 고객에게 콜드콜을 보내고, Demo를 보여주어 니즈를 이끌어낸 뒤 가격을 제안하고 솔루션을 판매하면서 기업의 성장을 이끌어 가는 방식이라고 볼 수 있습니다.

제품주도성장(PLG, Product-led growth)

기업 사용자의 Digital Literacy가 향상되면서 고객 스스로가 처음부터 적극적으로 필요한 기능을 검색하여 발견하고, 홈페이지를 통해 여러 제품을 비교해 보거나 무료 체험해 본 뒤 사용 가치가 크다고 판단하는 시점에 유료 플랜을 결제하는 방식입니다. (Try-before-you-buy)

홈페이지 SEO, Paid advertising, 투명한 유료 정책 공개 등에 집중하여 과거 영업 담당자가 하던 역할을 제품 커뮤니케이션에 쏟아 넣는 방식이라고 이야기할 수 있습니다.

참고: 제품주도성장(Product Led Growth)의 일곱가지 FAQ

생각

기업의 성장을 위해서는 당연히 둘 다 중요합니다. 하지만 어떤 방식으로 성장하든 결국 고객이 최대의 효용을 느껴야 한다고 생각합니다.

B2B는 제품 특성상 구매자(구매 결정권자)와 사용자가 다른 경우가 많습니다. 사용자가 한 달에 한두 번씩만 관심을 가져야 하는 제품이라면 괜찮을 수도 있겠지만 기업의 업무를 효율화해 주는 SaaS일수록 사용자들이 하루에도 몇 번씩 서비스에 방문해서 이용하기 때문에 더욱 고객의 효용이 중요합니다.

볼타 팀은 기업 금융에서 발생하는 비효율을 최적화하는 B2B 핀테크 SaaS를 만들어 나가고 있습니다. 현재는 전체 기업 금융/자금 업무 프로세스 중 고객들의 Pain Point가 가장 큰 전자세금계산서 분야를 날카롭게 파고들어 시장에 진입하고 있으며 빠른 속도로 모든 프로세스를 최적화하여 SaaS 형태로 제공하고자 합니다.

이를 위해선 새로운 기능과 서비스를 출시하더라도 사용자들이 큰 어려움 없이, 별도의 학습 없이도 스스로 제품을 이해할 수 있게 하는 것이 필요합니다.

초기 스타트업이 고객의 요구사항을 맞추어주려다 추후 돌이킬 수 없을 수준의 프랑켄슈타인 같은 제품을 만들어내는 걸 자주 목격했었는데요. 개인적으로는 사업적으로 성공하면서도 기술이나 UX적으로도 완벽한 B2B SaaS를 만들어 내고 싶은 욕심이 있습니다.

이런 여정에 함께 하고 싶으시거나 저희 팀이 이전에 어떤 레슨런을 해왔고, 앞으로 어떤 챌린지를 해나갈지 궁금하시다면 언제든 연락주세요! 볼타(Bolta) 채용 : 볼타는 고속성장중!

2023년 회고: 프로젝트, 퇴사, 창업, 채용, 기술

Fri, 26 Jan 2024 15:00:00 GMT

2023년은 여러 중요한 사건들이 있었던 한 해였습니다. 그 중 창업이 가장 기억에 남는데요. 이번 글에서는 2023년부터 게시글 발행 시점까지를 타임라인 순서대로 적어보고자 합니다.

카카오페이: 신규 프로젝트

2023년 초 당시 소속되어 있던 팀은 카카오페이 머니를 비롯한 현금 흐름을 지원하기 위한 플랫폼을 개발하는 팀이었고, 주로 실제 입금/출금 거래를 체결하기 위한 카카오페이<->은행 통신 Gateway, 머니 정산, 전사 자금 업무 지원 플랫폼 등의 프로젝트를 진행했습니다.

그러다보니 전사의 각 조직에서 필요로 하는 공통된 부분을 도출하고 이를 플랫폼으로 잘 만들어 제공하는 것에 항상 관심 있었는데요. 평소와 같이 타 조직의 Pain Point를 살펴보던 중 이건 꼭 필요하겠다는 판단하에 <은행정보 플랫폼>이라 불리는 신규 프로젝트를 추진하게 되었습니다. 좋은 경험을 하게 해주신 PM 말론에게 이 자리를 빌어 감사의 말씀을 드립니다. 🙇‍♂️

기존에는 수십 개의 개발 조직에서 은행에 대한 정보가 필요하다면 각자 관리하는 구조였습니다.

카카오페이 머니 개발 조직: 머니 충전/송금을 위한 은행 정보 조회
고객 문의 플랫폼 개발 조직: 착오송금 반환 중개 시 은행 정보 입력
환불 시스템 개발 조직: 환불 계좌 유효성 검사
등등..

은행 이름, 로고, 약관, 송금/계좌연결 가능 여부, 점검 유무 등 다양한 정보를 파편적으로 관리하고 있다보니 각 화면마다 보이는 로고가 다르거나 해당 은행이 점검 중인지 확인하기 위해선 실제로 송금과 같은 액션을 수행해봐야만 하는 문제가 있었습니다.

이에 가장 빠르게 협업 해볼만한 조직을 리서치하였고, 가장 밀접하게 협업 중이던 머니 서비스 개발 조직에서 송금 단계에서 계좌번호 입력 시 은행 추론 기능을 개발하고자 하는 니즈를 확인 할 수 있었습니다. 또한 각 계좌번호 패턴별로 어떤 은행에 해당하는지 추론하기 위한 정보는 해당 조직에서만 필요로하는 것이 아니었기 때문에 공통화하여 플랫폼으로 제공하기 충분하다고 판단하였습니다.

송금 단계에서 계좌번호 입력 시 은행 추론 기능(카카오페이 송금 화면 캡처)

그 후, 해당 조직을 1차 타겟으로 하여 MVP -> 1차 확장(M-1) -> 2차 확장(M-2)까지의 로드맵과 전략을 수립하였고 기술 아키텍처를 Design 하였습니다.

기술적으로도 많은 고민이 있었는데요. 첫 번째는 Server to Server 통신 시 발생하는 네트워크 병목과 오류에 대한 부분이었습니다. 네트워크 통신시에는 고려해야할 부분이 참 많습니다.

과도한 GET(Read) 부하
각종 Network I/O Exception(Timeout 등)
Known Error 처리
같은 요청이 짧은 시간에 두 번 이상 발생한 경우
네트워크 요청 순서가 뒤집힌 경우
등등..

이 중에서 MVP 개발 시에는 1번, 2번, 3번 부분만 고민하기로 했습니다. 4번과 5번은 데이터에 대한 Write 요청 시 발생할 수 있는 문제인데, MVP Spec에서는 Read에 대한 Spec밖에 없었기 때문입니다.

MVP Spec: 은행 목록 조회, 계좌번호로 은행 추론

Tech Challenge #1. 과도한 GET(Read) 부하

API 사용자가 늘어날수록 플랫폼 서버의 부하가 심해질 것 이기에 이 부분을 고려하지 않을 수 없었습니다. 세 가지 해결책을 후보로 두었습니다.

사용하는 쪽에서 Caching 하도록 가이드 전달
플랫폼 서버 차원에서 Caching 적용
두 가지 방법 모두 적용

Tech Challenge #2. 각종 Network I/O Exception(Timeout 등)

마땅히 플랫폼 서버 측에서 대신 해줄 수 있는 부분이 많이 없었습니다.

사용하는 쪽에서 적절히 처리할 수 있도록 가이드 전달

Tech Challenge #3. Known Error 처리

여기도 마찬가지로, 플랫폼 서버 입장에서는 해줄 수 있는 부분이 많이 없었습니다.

사용하는 쪽에서 적절히 처리 할 수 있도록 가이드 전달

음.. 정리하고보니 사용하는 쪽에서 '잘', '알아서' 해주길 기대해야 하는 부분이 너무 많았습니다. 그리고 잘 만들어서 편하게 쓸 수 있게하여 널리 보급해야하는 플랫폼 팀의 입장에서 이런 방식은 한계가 명확했습니다.

이 시점에 아래와 같은 Ground Rule을 정하게 됩니다.

연동은 최소한의 공수만으로 할 수 있게 한다.
모든 조직이 매 연동마다 반복해서 해야하는 고민은 모두 없애준다.
특정 기능을 사용하기 위해 '어떻게' 해야 하는지 고민하지 않게 한다.

이를 위해 SDK를 개발하기로 결정했고, SDK 아키텍처에 대한 고민을 시작합니다. 경험상 아키텍처는 여러명이 처음부터 다 같이 고민하면 좋은 결과가 나오기 힘들었기에, 한 명이 총대 메고 초안을 잡고 Review & Feedback 받는 구조가 가장 좋겠다는 판단을 내렸습니다. 그리고 그걸 제가 하게 됩니다.

조금 오래되어 정확하지는 않지만, 수요일 즈음 이 논의를 마치고 집에 돌아가 곧장 리서치를 통해 대략의 아키텍처를 잡고 그 주 주말까지 시연 가능한 프로토타입을 만들었던걸로 기억합니다. 프로토타입 GitHub Repository 상 커밋 기록을 보면 아마 맞는 듯 합니다.

그리고 그 다음 주 평일에 곧장 Review를 진행하고, 수정할 부분을 수정한 뒤 Sdk 개발을 본격적으로 진행했습니다. (실제 개발된 모습은 GitHub Repository와 다릅니다. 😅) 해당 프로토타입에 대해서도 이야기할게 많은데, 너무 길어질 듯 하여 추후에 기회가 되면 별도 게시글로 다루어보도록 하겠습니다.

Sdk 개발과 플랫폼 서버 개발까지 모두 끝마치고선 본격적으로 MVP 타겟 조직과 밀접하게 협업하며 Feature를 만들어 나갔고, 처음 보여드린 계좌번호 입력 시 은행 추론 기능이 개발되었습니다.

그 후에는 전사 확장을 위해 프로젝트의 이름이 로고로 프린팅된 반팔 티셔츠를 만들어 입고 다니며 홍보하기도 하고, 여러 프로젝트의 담당자들이 이 티셔츠에 대하여 물어볼 때 마다 '우리가 개발한 신규 플랫폼을 연동하면 드린다.'라고 답하기도 했던 기억이 나네요. 최근에는 반팔 티셔츠에서 맨투맨으로 확장되고, 초기 잡아둔 마일스톤에서 조금 더 확장하여 잘 Develop 되고 있다고 전해 듣고 있습니다. 😁

카카오페이: 퇴사

앞선 프로젝트를 마치고 신규 프로젝트를 준비하고 있던 시점에 퇴사를 결정하게 됩니다. 예정되어 있는 프로젝트 모두 기대 되는 프로젝트라 이 경험을 저 대신 하셨을 다른 팀원 분들에게 질투가 나기도 하는데요. 이 결정에 대해선 후회하지 않습니다.

왜 퇴사 했는지는 앞서 이야기 드렸지만, 저는 창업을 했습니다.

볼타: 창업

공동창업자인 문혁님이 처음 디스콰이엇을 통해 공동창업에 대한 이야기를 주셨는데요. 그때 당시엔 1주일에 몇개씩 비슷한 종류의 콜드메일이 왔기에 당연히 대수롭지 않게 무시하고 넘어갔습니다. 그랬더니 링크드인까지 찾아오셔서 자료를 전달주시며 이야기를 이어 나가려고 하셨고, 그제서야 메시지를 읽어보기 시작했습니다.

공감가는 내용이 꽤 많았으며, 자료를 읽고 든 궁금증을 링크드인 메시지로 질문드렸습니다. 그리고 마침 근처에 계시길레 오프라인에서 만나뵈었는데, 만난지 1시간 만에 같이 하시죠.라고 말씀 드리고 곧장 팀장님에게 퇴사 의사를 밝혔습니다. 조금 더 자세한 이야기는 코파운더를 찾은 Bolta 메이커 문혁님의 스토리 게시글을 참고해주세요.

초반에는 법인 설립과 사무실 없이 주말에 서로의 집 근처에서 만나서 이야기를 나눴습니다. 알고보니 서로의 집이 10분 거리였습니다. 처음엔 코딩, 개발 전혀 없이 노코드로 랜딩 페이지를 만들고 반응을 보는게 중요하다고 생각했습니다.(참고: 노코드 랜딩 페이지 만들기)

노코드 랜딩 페이지를 '이러한 기능이 제공될 예정인데 지금 신청하면 무료, 4주 뒤에는 유료!'라는 뉘앙스로 꾸미기 시작했고, 200곳 가량이 사용 신청을 해주셨습니다. 그 중 일부를 필터링한 뒤 한달 동안 모두 인터뷰하며 그들이 겪고있는 진짜 문제에 대하여 파고들기 시작했습니다. 그 과정에서 MVP Spec과 향후 방향성을 대략 잡을 수 있었고, 본격 개발을 통하여 MVP를 출시하게 됩니다.

볼타: MVP 출시

볼타 MVP 스크린샷

특별한 Section 구분 없이 Input과 Label, Button의 나열로 구성된 UI였습니다. 지금 보면 정말 기능에만 충실했던 것 같네요.😅 이때 당시 FrontEnd는 React 18(CRA)과 TypeScript 로 개발되어 정적 빌드 후 AWS S3에 배포되는 구조를 가지고 있었습니다.

MVP를 출시한 뒤 많은 고객분들이 Feedback 주셨고, 하나하나 개선해나가는 과정에서 누적되는 문제가 있었습니다. MVP를 만들 때 당시 속도만 고민하다 확장성을 사실상 모두 포기했던 부분이었는데요. 시간이 지남에 따라 더 큰 문제로 다가오게 되었습니다.

신규 기능을 하나 추가하려고 해도 Break-Change가 상당 부분 발생했고, 동일한 UI를 가진 컴포넌트를 다시 사용하는데에도 생산성이 더 높아지는게 아니라 기존 기능과의 호환성을 위한 고민과 컴포넌트 내 분기 처리가 너무 많이 필요했습니다.

그럼에도 많은 분들이 잘 사용해주고 있으셨지만 추가적인 기능 개발 외에도 UX Flow 개선, 테스트 용이성 향상, 개발 경험(DX) 향상, 장기적으로 Mobile 지원 등에 대한 고민이 있었기에 전면 리뉴얼이라는 결단을 내릴 수 밖에 없었습니다.

볼타: 전면 리뉴얼 & FrontEnd Engineering

볼타 전면 리뉴얼 스크린샷

리뉴얼에서는 사용자가 제품을 더 빠르고 효과적으로 사용할 수 있게 하는 동시에, 사용자 경험을 크게 향상시키기 위한 세 가지 원칙이 있었습니다.

원칙 1. 별도 학습 없이도 사용자 스스로 제품을 이해할 수 있게 한다.

이 원칙의 핵심은 직관적인 사용자 경험(UX)입니다. 사용자 인터페이스(UI)는 직관적으로 설계되어야 하며, 사용자가 추가적인 설명이나 교육 없이도 기능을 쉽게 이해하고 사용할 수 있어야 한다고 생각했습니다.

최대한 사용자 흐름을 간단하고 자연스럽게 만들며, 사용자가 원하는 정보나 기능에 빠르게 접근할 수 있도록 설계하였습니다.

원칙 2. 같은 목적을 가진 요소는 가까이 둔다.

이 원칙은 정보와 기능의 응집성의 중요성에서 시작되었습니다. 간단하게 설명하면, 같은 목적이나 기능을 가진 것들은 '가까이에 모아두는 것이 좋다'는 원칙입니다. 이렇게 하면 사용자가 필요한 정보를 빠르게 찾고 작업을 효율적으로 할 수 있게 됩니다.

원칙 3. 반응형과 접근성을 가능한 고려한다.

모든 사용자가 다양한 디바이스와 환경에서 원활하게 제품을 이용할 수 있도록 반응형 디자인과 접근성을 고려하였습니다. 이 원칙을 적용함으로써, 제품의 사용성과 접근성이 향상되어 더 많은 사용자분들이 편하게 사용하시기를 기대합니다.

그 외 원칙: 기술

그 외에도 다양한 기술적인 고민이 존재했습니다. 우선 각 컴포넌트의 코드 중복을 줄이고, 협업을 용이하게 하면서도 미래의 확장성 및 변경 사항에 대한 대응력을 향상시키기 위해 최대한 재사용 가능한 컴포넌트를 설계해야겠다는 판단을 내렸습니다.(100% 모듈 형태의 구조는 아닙니다)

최대한 UI 요소들을 범용적으로 사용할 수 있는 형태로 구성하였고, 비즈니스 로직과 UI 레이어를 분리하여서 각각의 부분이 독립적으로 발전할 수 있도록 했습니다. 이 덕분에 제품의 기능 확장이나 디자인 변경이 필요할 때, 전체 구조를 뜯어고치지 않고도 필요한 부분만을 쉽게 업데이트하거나 교체할 수 있게 되었습니다.

그리고 기술 스택도 일부 변경되었는데요. 가장 큰 변화로는 기존에 CRA 베이스로 구성되어 있던 프로젝트가 Next.js 베이스로 변경되게 됩니다.

기존
- React 18(CRA)
- AWS S3 + CloudFront 배포 환경
변경
- React 18
- Next.js 14
- AWS Amplify + CloudFront 배포 환경

프로젝트를 진행하다보면 성능을 최적화하거나 사용성을 개선하기 위하여 대규모의 보일러플레이트 코드를 작성해야하는 경우가 종종 있습니다. 하지만 매번 이러한 것을 직접 구현하는 것은 비효율이라고 판단하였고, 이를 선제적-적극적으로 지원해줄 수 있는 Framework를 사용하는 것이 효율적일 것이라는 이유였습니다.

여러 Framework 후보가 존재했지만, 그중에서 Next.js가 현재도 그렇고 앞으로도 Vercel에 의하여 여러 후보에 비해 가장 적극적으로 Maintaining 될 것이라 기대하며 도입하게 되었습니다.

볼타: 전면 리뉴얼 & BackEnd/Server Engineering

볼타 빌링 스크린샷

앞서 FrontEnd Engineering 영역에 대한 기술적 챌린지를 간략하게 이야기 드렸습니다. FrontEnd 리뉴얼에 맞추어 서버에서도 신규 API를 개발하거나 기존 API를 변경해야 하는 상황도 있었는데요. Down-Time을 발생시키며 리뉴얼을 진행할 것이 아니었기에 기존 API와의 하위호환성을 유지하면서도 대규모의 신규 API를 개발해야만 했습니다.

리뉴얼을 위한 BackEnd Engineering 영역에서는 크게 세 가지 기술 과제가 있었습니다.

과제 1. Leagcy, Shared, New 코드 베이스 영역 분리

리뉴얼 이전에만 사용되는 Legacy 코드 베이스, 리뉴얼 이후에만 사용되는 New 코드 베이스 그리고 양쪽 모두에서 사용되는 Shared 코드 베이스까지 방대한 코드를 효율적으로 관리하기 위한 고민이 필요했습니다.

수백, 수천 라인에서 그치는 게 아닌 수만 라인에 달하는 규모이다 보니 더욱 고민이 컸습니다.

볼타의 주요 API 서버는 가까운 시일 내에 예정되어 있는 API 서버 분리와 추가적인 외부 인프라 연동을 고려하여 아래와 같은 구조로 구성되어 있었습니다.

presentation layer: RestController 위치
core(domain) layer: POJO DomainModel, usecase interface 위치
application(implementation) layer: usecase의 구현체, external(infrastructure) 연동을 위한 interface 위치
external(infrastructure) layer: mysql, redis, AWS Managed Service 등 외부 인프라 연동을 위한 구현체 위치

이 중 presentation layer는 Shared 코드 베이스를 허용하지 않기로 결정하였고, 기존과 동작의 변경이 없더라도 리뉴얼용 API EndPoint를 별도로 작성하고 기존 API에는 모두 @Deprecated 어노테이션을 명시적으로 추가해 주었습니다. 신규로 필요한 EndPoint는 core layer에 신규 usecase interface를 함께 작성하며 추가하였습니다.

그 후 각 usecase에서 필요한 구현체와 infrastructure 연동을 위한 코드 작업을 하는 방식으로 코드 베이스를 구분하였습니다.

과제 2. 인프라 관리 효율화

볼타 팀의 모든 서비스는 AWS 인프라 위에서 운영되고 있습니다. EC2, RDS, Aurora, ParamterStroe, ALB, VPC, IAM 등 다양한 매니지드 서비스를 여러 목적으로 사용하다 보니 비슷한 부분이 반복되기도 하고 생성해 놓고 잊기도 하는 등 여러 가지 이슈가 식별되었습니다.

이에 IaC(Infrastructure as Code)의 필요성을 느끼게 되었고, 여러 후보를 두고 고민해 본 끝에 Terraform을 도입하게 되었습니다.

asbubam(이승우)님의 약 7년 전 AWS VPC with Terraform Modules 게시글과 KC(Chang Kyungcheol)님의 조언으로 1주일도 안되어서 모든 인프라를 테라폼으로 성공적으로 옮길 수 있었습니다.

이 작업을 통해 크게 세 가지 효과를 얻을 수 있었습니다.

하나의 인프라 요소를 추가/변경하더라도 추적하기 쉬워졌으며 전체적인 형상 가시성이 더 명확해졌습니다.
동일 애플리케이션의 phase마다 이름이나 컴포넌트 구성이 일부 다르던 부분까지 식별하고 통일할 수 있게 되었습니다.
aws infrastructure 다이어그램을 테라폼 state 기반으로 자동으로 그릴 수 있게 되어 AWS 인프라 변화가 문서에 반영되지 않는 문제를 해결할 수 있게 되었습니다. 이를 통해 팀에 새로운 분이 합류하시더라도 전체적인 구조를 조금 더 쉽게 이해하실 수 있지 않을까 기대합니다.

과제 3. 서비스 배포 효율화

기존에 모든 서버 애플리케이션은 EC2에 Docker Image를 기반으로 수동 배포하는 구조였습니다. 처음에는 혼자서 배포하고, 관리해 왔기 때문에 큰 불편함이 없었습니다. 다만, 새로운 팀원이 합류하는 걸 고려하였을 때 이 방식은 지속하기 어렵겠다는 판단하에 배포 프로세스를 개선하게 됩니다.

우선 서비스 실행 방식을 EC2에서 ECS(Elastic Container Service)로 이관하는 결정을 내렸습니다. 기존에도 모든 서버 애플리케이션은 도커 이미지로서 컨테이너화되어 관리되고 있었기에 큰 공수가 필요하지 않았습니다. 그럼에도 애플리케이션을 조금 더 효율적으로 배포, 관리하고 Scale을 조정하는데 큰 도움을 주기에 도입하지 않을 이유가 없었습니다.

그 후 배포 파이프라인도 손보게 됩니다. AWS CodeBuild/Pipeline, Jekins, CircleCI, Drone CI 등 전통적이거나 널리 사용되는 SaaS와 매니지드 서비스를 다양하게 고려해보았습니다. 비용과 효율성 등을 종합적으로 고려하였는데, 평균적인 Build Time이나 횟수를 명확히 판단할 수 없는 시점이었기에 이를 추론하는게 쉽지는 않았습니다.

또한 단순히 빌드와 배포 트리거만 필요한 것이 아니라 배치 애플리케이션 실행을 정기적으로 트리거해주는 기능도 필요했습니다. 이 시점에서 Jekins가 가장 가능성 높은 후보로 거론되었으나 젠킨스 파이프라인을 작성하거나 AWS, Slack, GitHub, Email 등을 연동하는데 필요한 공수까지 고려하였을 때 너무 비효율적이라 판단하였습니다.

추가 리서치를 통해 JetBrains TeamCity를 알게 되었고, 필요한 모든 외부 연동이 별도 플러그인 설치 없이 자체적으로 지원하고 있음을 알게 되었습니다. 결국 TeamCity를 이용하여 빌드/배포/배치 실행 프로세스를 셋업하게 되었고, 현재까지도 별도 LICENSE 비용 없이 무료 범위 내에서 잘 사용하고 있습니다.

먼 미래엔 AWS 매니지드 서비스로 넘어가지 않을까 싶기는 합니다.

볼타: 채용

두 명 뿐이었던 팀원은 약 8개월에 걸쳐 5명이 되었습니다.

기존 팀원: 글렌(CEO), 테오(CTO)
신규 팀원: 메이(Product Designer), 셰인(BE), 제이(FE)

길게 보고 채용을 진행하였고, 약 3000개의 이력서를 받아볼 수 있었습니다. 정말 좋은 분들이 지원해 주셨지만 모두 모실 수 없어 아쉬움이 컸습니다. 그런 마음에 불합격을 안내드린 분들에게는 500자~1000자 가량의 피드백을 전달해 드리기도 했습니다.

신규 팀원분들은 위에 적힌 순서대로 모시게 되었는데요. 리뉴얼을 결정한 직후 제품에 대한 고민을 함께 해주실 수 있는 프로덕트 디자이너분을 모셔야겠다는 생각이 들어 가장 먼저 채용을 진행하였고, 기존에 경험했던 환경과 업무에서의 강점이 명확하시면서도 새로운 환경에서 도전하는 것에 대한 확신이 뛰어나셨던 메이를 모시게 되었습니다.

그 후 백엔드 개발쪽에 굵직한 기술 과제들이 많아 새로운 백엔드 개발자 한 분을 모셔야겠다는 생각이 들었고, 결과적으로 셰인을 모시게 되었습니다. 셰인은 아직 대학에 재학중이신, 졸업예정 상태이셨는데요. 그럼에도 수많은 후보자들이 어려워했던 인터뷰를 정말 잘 답변해주셨고, 무엇보다 Fresh-Eyes와 열정으로 제품에 대한 새로운 의견을 적극적으로 제시해주실 수 있는 분이라는 생각이 들어 모시게 되었습니다.

마지막으로 제이를 모시게 되었습니다. 리뉴얼에서 필요한 프론트 엔지니어링 작업량이 상당하였고, 이를 제가 백엔드 엔지니어링과 함께 하는 것 보다는 프론트엔드 엔지니어를 한 분 새롭게 모시는게 더 효율적일 것이라는 판단이 있었습니다. 제이는 인터뷰 과정에서부터 한정된 시간 속에서 일을 효율적으로 하는 방법을 통달하신 분이라는 생각이 들게 하는 분이었습니다. 이 부분이 모든 팀원에게 귀감되며, 배울 수 있는 점이라고 생각되어 모시게 되었습니다.

볼타: 투자

간편 전자세금계산서 발행, 관리 - 볼타를 서비스하는 (주)볼타코퍼레이션은 2023년 4월 17일 법인을 설립하였습니다. 2호선 서울대입구역 도보 2분 거리에 위치한 BS타워(관악구 관악로 158)를 첫 사무실로 이용하였는데요.

이 사무실은 저희 Seed 투자사인 스프링 캠프의 사무실이며, 배치 프로그램 이전에 잠시 비어있는 공간을 대여해주셔서 이용했습니다. 덕분에 너무 넓은 공간을 편하게 이용할 수 있었습니다.

2023년 5월 10일에는 스프링 캠프로부터 Seed 투자를 유치하게 됩니다. 전자세금계산서 SaaS ‘볼타코퍼레이션’, 스프링캠프로부터 시드 투자 유치

그 후 시간이 지나 8월 1일, 강남역에 위치한 위워크 강남역2호점으로 이사하게 되었고, 추가 채용에 따라 조금 더 넓은 호실로 옮겨오면서 8개월만에 이사를 두 번하기도 했습니다. (참고: 공유오피스를 고를 때 고려했던 점들 )

2023년 8월 25일에는 중소벤처기업부 기술창업지원 프로그램 '팁스(TIPS)'에 선정됩니다. 세금계산서 발행&관리 서비스 '볼타' 운영사 볼타코퍼레이션, '팁스' 선정

2023년 12월, Pre-A 투자를 클로징 하였습니다. 해당 투자는 미국계 밴처캐피탈 스트롱벤처스(Strong Ventures)가 리드했으며, 컴패노이드 랩스와 한기용님이 함께 해주셨습니다. ‘볼타’ 운영사 볼타코퍼레이션, 스트롱벤처스로부터 프리 A 투자 유치

투자 소식 공개 이전 한기용님의 개인 SNS 🙂

기용과의 인연은 정말 우연히 이어졌는데요. 처음에는 EO에 소개된 인터뷰 영상으로 접하게 되었었습니다.

그 후 여러 회사에서 오프라인 세션을 진행하시는 것을 지인과 SNS를 통해 전해 들었는데요. 그러다 2023년 8월, 기용님이 한국에 들어오신다는 소식을 듣고선 한번 뵙고 싶다는 생각에 '기회가 된다면 뵙고 싶다'라고 드렸는데, 실제로 저와 같이 따로 연락드린 분들을 모아 세션을 진행해주셨습니다.

자리를 준비하시어 DM으로 연락주신 모습

세션은 개발자, 디자이너, PO, 사업개발, 데이터 분석가, 데이터 엔지니어 등 다양한 직군의 사람이 참가해주셨고 1) 해외취업, 2) 건강한 피드백, 3) 리더십 같은 주제로 구성되었습니다. 건강한 피드백과 리더십에 대한 내용은 한기용님과 함께하는 단체챗 회고에 간략하게 정리되어 있습니다.

그 후 시간이 지나 링크드인을 통해 엔젤투자 의사를 먼저 밝혀 주셨고, 기술 조직 운영에 대한 노하우 부분에서 많은 도움을 받을 수 있을 것 같다는 판단하에 엔젤투자자로 모시게 되었습니다.

컴패노이드 랩스는 HCI, UX 전문가 장진규 의장님과의 인연으로 함께 해주시게 되었습니다.

개인적인 이야기

창업하며 일하는 방식과 협업 방식이 크게 바뀌게 되었습니다. 과거에는 플랫폼 엔지니어링 위주로 경험했다 보니 서버 개발자와 PM을 제외한 프론트엔드 개발자, 프로덕트 디자이너와 밀접하게 협업할 기회가 많지 않았습니다. 협업 기회가 생기더라도 대부분 PM을 통해서 협업하거나 일시적으로 협업하고 끝났던 것 같습니다.

그래서 이 부분을 약 100개의 사이드 프로젝트를 경험하며 채워나갔지만, 그럼에도 마음속에는 약간의 결핍으로 남아있었다고 생각합니다. 어떻게 하면 더 효율적으로 가치를 만들 수 있을까, 어떻게 하면 한정된 시간 동안 최대의 효율을 낼 수 있을까, 어떻게 하면 다른 사람보다 100배 빠르게, 잘할 수 있을까라는 생각이 계속 들었습니다.

그러던 중 새롭게 모시게 된 제이 덕분에 대략의 방향성을 잡을 수 있게 되었습니다. 바로 나의 탁월한 역량으로 상대방이 일하기 편하게 해주자였습니다.

예를 들어 엑셀 파일을 업로드해서 파싱하고 양식에 맞게끔 작성하였는지 검증하는 로직이 필요하다고 할 때, 프론트엔드와 백엔드 중 어디서 하는 게 좋을까요?

각자 장단점이 있지만 백엔드에서 처리하는 방향으로 구조를 잡는다면 업로드된 파일의 State를 관리해야 한다거나 하는 등 여러 부분에서 복잡한 처리가 필요해집니다. 그런데 이때 '이건 프론트엔드 측에서 하는게 나을 것 같다.'라며 프론트엔드 개발자가 먼저 제안 해준다면 어떨까요? 구조는 훨씬 간단해집니다.

저는 저 상황에서 당연히 백엔드에서 해야지라고 생각했습니다. 제가 여태 해온 것이 백엔드 개발이니까요. 하지만 저 말을 듣는 순간 적절한 위임과 탁월한 역량으로 팀에 기여한다는 것의 중요성을 다시 한번 깨닫게 되었습니다.

그 이후 빌링(결제 및 구독) 프로젝트를 진행했는데요. 제가 백엔드 개발을 담당하였습니다.

결제와 구독 비즈니스는 정기 결제 실패, 유료 구독 연장, 무료 체험, 구독 플랜 변경 등 다양한 부분에서 복잡한 조건과 상태를 확인하고, API를 어떤 방법과 순서로 호출 하여야 하는지에 대한 이해가 필요합니다. 이러한 정보는 서버 개발을 담당한 백엔드 개발자가 가잘 잘 알고 있을텐데요.

백엔드 개발자가 이해하고 있는 조건과 정책을 프론트엔드 개발자에게 전파시키는게 쉬운 일은 아닙니다. 아무리 다이어그램을 잘 그리고 구구절절 설명 하더라도 그걸 보는 사람마다 다 다르게 이해할 가능성도 있습니다. 그래서 저는 관련 로직을 프론트엔드 코드로 직접 작성해서 전달했습니다.

그 결과 이해관계자들끼리의 커뮤니케이션 비용이 확연히 줄어들게 되었고, 실제로 커뮤니케이션을 위한 시간이 많이 줄어듦을 체감할 수 있었습니다. (서버 개발부터 프론트엔드 개발까지 working-time 3일이 안걸렸습니다.)

항상 내가 고민하는 시간보다 내 이야기를 듣기 위한 상대방의 시간이 더 소중하다는걸 명심하고, 탁월한 역량으로 팀에 기여하기 위한 방법을 고민하고, 어떻게 남들보다 100배 더 잘할 수 있을지 고민하는 것에 대한 중요성을 다시 한번 깨닫는 계기였습니다.

2024년 계획

2024년에는 크게 네 가지 목표를 가지고 나아가려고 합니다. 넘버링이 우선순위를 의미하는건 아닙니다.

목표 1. 고객

2024년의 주요 목표 중 하나는 제품을 이용해주고 있으신 고객분들에게 더 나은 가치를 전달하고, 더 나은 서비스와 경험을 제공하는 것입니다. 이를 위해 고객의 피드백을 청취하고 그에 따른 개선사항을 빠르게 반영할 수 있는 프로세스를 준비하고 있습니다.

목표 2. 제품

제품을 더 사용자 친화적이고 효율적으로 만들기 위한 연구와 개발을 지속적으로 진행하려고 합니다. 예정되어 있는 기능과 서비스 뿐 아니라, 앞으로 새롭게 챌린지하게 될 것들까지 상상 할 수 없는 속도로 준비하고 있습니다. 또한, 제품의 안정성과 보안성을 더욱 강화하기 위한 작업도 함께 진행할 예정입니다.

이 글에서 모두 밝히긴 어렵지만 2024년은 2023년보다 20배, 30배 빠르게 나아갈 수 있을 것으로 기대합니다.

목표 3. 채용

팀을 더 강화하고 더 많은 역량 있는 인재를 채용하는 것도 중요한 목표 중 하나입니다. 제품과 팀의 성장과 발전을 위해 필요한 역량과 경험을 가지신 분들을 영입하고자 합니다. 현재 B2B 마케터, 백엔드 개발자, 프론트엔드 개발자 포지션을 열어두었으며, 관심 있으신분을 위해 채용 공고를 함께 첨부합니다. 볼타(Bolta) 채용 : 볼타는 고속성장중!

목표 4. 건강

마지막으로, 2024년에는 개인의 건강에 대한 부분을 더 큰 중요성으로 다루고 관리하려 합니다. 다양한 스트레스를 관리하기 위해 지금보다 건강한 식사와 규칙적인 운동을 병행하고자 합니다. 최대한 컨디션의 Low-High 격차를 줄여 항상 뛰어난 판단을 내릴 수 있기를 기대합니다. 이를 통해 팀과 제품의 목표를 달성하는 데 큰 기여를 할 수 있다고 믿습니다.

마무리

그럼, 2024년에도 모두 잘 부탁드립니다. 🙂

다른 사람에게 도움을 구하는 가장 좋은 방법

Mon, 01 Jan 2024 00:06:38 GMT

인생을 살다보면 다른 사람에게 도움을 구해야하는 순간이 옵니다. 투자, 취업, 이직, 승진 등 다양한 상황에서 막연한 두려움, 지속적인 실패로 인한 좌절감과 혼란스러운 마음이 쌓이다보면 힘들고, 누군가에게 도움을 요청하고 싶어집니다.

그러나 남에게 도움을 구한다는게 쉬운 일은 아닙니다.

내가 겪고 있는 진짜 문제

교육/학습 과정에서 최대의 효율을 얻어내려면 아래의 두 조건이 모두 만족해야만 합니다.

내가 도움 받고 싶은 문제는 한 가지로 명확해야 한다.
나에게 도움을 주는(교수를 해주는) 상대방은 내가 겪고 있는 문제에 대한 전문가이어야 한다.

두 번째 항목은 같이 일해본 경험이 있거나, 과거부터 알던 사이라도 상대방이 이 문제에 대한 전문가인지 객관적으로 판단하기가 어렵습니다. 그렇기에 정말 도움 받고 싶다면 1번에 집중해야 합니다.

막연한 두려움과 좌절감을 가지고 있을 수록 진짜 문제에 집중하는 것이 중요합니다.

나의 고민을 남에게 위임하지 않기

도움을 구하는 것 자체가 고민을 남에게 위임하는 것 아닌가? 싶으실 수 있습니다. 하지만 도움을 구하는 것과 고민을 위임하는 것은 명백히 다릅니다. 아래는 도움을 구하는 몇가지 예시인데요.

1. 막연한 두려움

안녕하세요 XXX님, 저는 OOO입니다. 비전공자 출신으로 부트캠프를 수료하였지만 취업이 어렵습니다. 앞으로 어떻게 해야할지 막막합니다.

2. 객관적이지 못한 비교

안녕하세요 XXX님, 저는 OOO입니다. yyyy 포지션으로 회사에서 일을 하고 있지만 주변 사람과 비교해보았을 때 부족한 점이 너무 많습니다. 어떻게 해야할지 막막합니다.

3. 해결책 요구

안녕하세요 XXX님, 저는 OOO입니다. 최근 zzz라는 기술 경험을 해보고 싶으나 지금 회사는 그러기 힘든 상황입니다. 앞으로 어떻게 해야할지 알려주시면 감사하겠습니다.

위와 같은 요청을 받으면 도움을 드리고 싶어도 내가 도움을 줄 수 있는 문제를 겪고 계시긴 한건가?라는 생각에 선뜻 도움 드리기 어렵습니다. 시간적 여유가 많다면 몇시간씩 시간을 할애하며 진짜 겪고 계신 문제가 무엇인지 도출하고, 방향을 제안해드릴 순 있지만 현실적으로는 어렵습니다.

단순히 나의 고민을 남에게 위임하는게 아니라 진짜 '조언'을 구해보시면 좋을 것 같습니다.

진짜 조언 구하기

제가 경험해본 조언을 구하는 방법 중 정말 좋은 방법이라고 생각되는걸 소개해드리려고 합니다.

첫 번째 방법 - 평소 지속적으로 라포 쌓기

라포(rapport)는 사람과 사람 사이에 생기는 상호신뢰관계를 말하는 심리학용어입니다. 누군가에게 요청, 부탁할 때에는 서로 부담감이 있습니다. 그렇기에 평소 서로에게 신뢰감을 가지고 있다면 비교적 부탁하기에 용이합니다.

제 주변에는 실제로 많은 사람과 라포를 쌓고, 매 6개월마다 10명 가까운 사람을 만나며 주기적으로 조언을 구하는 분이 계시는데요. 조언을 구하고자하는 사람을 명확히 정하고, 그 사람이 있는 곳까지 찾아가서 커피와 밥을 사며 조언을 구하십니다. 그리고 그 방법이 정말 인상적입니다.

만나서 하는 질문: 지난 6개월동안 A라는 문제에 대하여 고민해볼 수 있는 기회가 있었는데요. 이 문제에 대해서 B와 같이 판단하고 행동했습니다. XXX님이라면 이 문제에 대하여 어떻게 접근하셨을 것 같으신가요?

내 고민 결과에 대한 피드백을 요청하는 것이 아니라 문제를 접근 할 수 있는 방법을 수집하는 방식입니다. 그리고 앞서 이야기한 것 처럼 도움 받고 싶은 문제가 한 가지로 명확합니다.

두 번째 방법 - 증명

이전에 모든 회사에 어필 할 수 있는 지원 동기와 목표설정 방법 게시글에서 나를 증명하는 것에 대한 중요성에 대하여 이야기한 적 있습니다. 모르는 사람에게 도움을 요청할 때에도 마찬가지로 나를 증명하는 것이 중요합니다.

저는 외부인이 도움을 요청하시는 경우 아래 부분에 대하여 고민합니다.

내가 정말 도움 드릴 수 있는 문제를 겪고 있으신걸까?
내가 도움 드린다고 끈기있게 도전 하실 수 있을까? 내가 투자한 시간이 의미없게 되지는 않을까?

끈기있게 도전하실 수 있는 분이라면, 지금은 부족하고 어려움을 겪더라도 그 중에서 빠르게 성장하고 발전하시는 경향이 있다고 믿습니다. 그리고 끈기있게 도전하실 수 있는지 판단할 때에는 아래 기준을 참고합니다.

결핍이 명확하고 그에 대한 트라우마가 있으신 분
잠을 포기하더라도 반드시 해결하고 싶은 문제가 있으신 분
나를 무시하고 부정한 사람들에게 나를 미친듯이 증명해내고 싶으신 분
아무리 힘들더라도 나를 믿어주는 사람을 실망시키고 싶지 않으신 분
지금 하는 일을 너무 사랑해서 성공/실패/유명세 등이 없어도 되시는 분
지금 하고 있는 일 외에 다른 하고 싶은 일이 없으신 분
개인의 행복을 포기해도 아쉽지 않으신 분

이 중 하나라도 있으시다면 끈기가 지속 될 것이라고 믿고 도움을 드리려고 노력합니다.

실제로 최근에 저에게 도움을 요청하신 분 중 인상 깊은 메일이 있었는데요. 그 전문을 공유해봅니다. 🙂 (개인을 특정하지 않기 위해 일부 내용은 가공하였습니다.)

메일 내용은 위에서 이야기한 1) 내가 도움 드릴 수 있는 문제를 겪고 있으신게 맞을까?, 2) 끈기있게 하실 수 있는 분일까? 라는 부분에 대한 검증을 해보고 싶다는 생각이 들기 충분했고, 이후에 추가 질문을 몇가지 더 드리며 이에 대한 1차적인 확신을 가질 수 있었습니다.

안녕하세요.
간단하게 제 소개를 드리자면, 저는 국비 교육을 들은 후 SI 프로젝트를 하는 회사에 재직하다 최근 이직하게 된 비전공자입니다.

개발자 이전에는 다른 직무로 일하다가 공부를 하면서 전문적인 지식이 쌓인다는 점, 그 지식을 다른 사람들과 공유하며 모르는 것을 알아간다는 점이 매력적이어서 개발자라는 직업으로 전향하게 되었습니다.

혼자 공부를 하면서 많은 개발자분들이 고민하듯 이 방향이 맞는지, 내가 잘하고 있는건지 확신이 없다는 등의 고민을 저도 하게 되었습니다.

그 고민을 풀기 위해 현재 모르는 개념들을 정리하고, 오픈채팅을 이용하여 다른 분들께 질문을 드려보기도 하며 해결해나가고 있다고 생각했지만, 가슴 한켠엔 답답함이 아직도 남아있는것 같습니다.

개발자로 전향하기 전에는 '이 정도는 알아야 한다'는 말을 많이 들었습니다. 경력 대비 부족함을 가장 두려워하며, 강한 성장 욕구를 가지고 있습니다. 그러나 욕구에 비해 성장하고 있다는 생각이 들지 않아 도움 요청을 드리고자 메일을 보내게 되었습니다.

첫 번째 어려움은 혼자 학습을 하는 방법을 잘 모른다는 것입니다.

현재는 Java, Spring, JPA를 공부하고 있습니다.

Java는 강의를 보면 몰랐던 퍼즐이 맞춰지듯, 개념 정리가 확실히 안된 부분이 있음을 느끼며 정리중에 있습니다.

Spring과 JPA는 현재 회사에서 SpringBoot, JPA로 구성되어있어 좀 더 강의와 블로그 등을 보며 이해하며 공부하고 있습니다.

하지만, 뒤돌아보면 모르는 지식들이 많고 반복 학습이 부족한건지, 개념 이해가 부족한건지 잘 파악이 되질 않고 있습니다.
예시로, 많은 사람이 듣는다는 김영한 - spring 기초 강의를 세번 보고서야 이해를 하였고, 자바의 정석을 두 번 정도 돌려봤지만 전혀 이해가 가질 않아 윤성우의 자바 프로그래밍 강의를 듣고 인터페이스가 이런 역할이었나..? 하며 강의를 듣는 제 모습에 다른 사람들보다 이해력이 느린건지, 다른 사람들과 이야기를 하다보면 세번 봤다는 이야기를 못할 정도로, 조금 주눅이 드는 것 같습니다.

물론 이해가 갔다는 게 중요하지만, 제가 너무 조급함을 느끼고 있는건지, 방법이 잘못된건지 잘 모르겠어서 이에 대한 이야기를 나누어보고 싶습니다. 또, 어떤 방식으로 공부를 진행해야 되는건지, 제 나름대로의 정리를 하고 싶습니다. 도움을 주시면 감사하겠습니다.

두번째는 이력서에 대한 내용입니다.
어떤 사람은 Notion 이력서가 좋다고 하고, 어떤 사람은 딱 떨어지는 형식의 이력서가 좋다고 하여, Notion으로 작성하였다가, 점핏 이력서로 바꾸었습니다. 이력서 안의 내용이 잘 정돈되어 앞으로의 개발생활을 적어가며 채우고 싶은데, 기초 틀이 잘못되어있는 느낌이 듭니다.

이직 당시에, 500군데 이상 지원하여 붙은 회사를 보며 경기가 어려운 점도 있지만, 제 이력서가 부족하진 않은지 누군가가 봐주었으면 하는 바램을 가지고 있었습니다. 부족한 점을 어떻게 고쳐나가면 좋을지 피드백을 주시면 감사하겠습니다.

전달하고자 하는 자료는 아래 링크와 첨부파일에 드리도록 하겠습니다.

[첨부파일]

OOO-이력서 : 현재 사람인, 원티드 등 사이트에 올려둔 이력서입니다.

이력서 및 자기소개서_OOO : 이직한 회사에 제출했었던 파일인데, 자기소개서가 포함되어있어 함께 첨부해드립니다.

[링크]

벨로그 : ____________

노션 : ____________

맺으며

Journey of Life, 인생의 여정에서 진정한 도움과 조언을 구하는 것은 단순한 과정이 아닙니다. 이 과정은 자신의 문제를 명확히 파악하고, 이에 대한 전문가를 찾는 것부터 시작됩니다. 또한 도움을 구하는 과정에서 자신을 증명하는 것도 중요한데, 이는 상대방에게 내가 끈기 있고 진지하게 문제를 접근하고 있음을 보여줄 수 있는 유일한 방법입니다.

막연한 두려움과 좌절감이 커질수록 문제와 관련된 명확하고 구체적인 질문을 준비하는 것이 중요하다는 것을 이해하고, 다른 사람에게 도움을 구할 때에 이런 방식으로 접근한다면 내가 직면한 문제를 해결하고 개인적으로 성장하는 데 큰 도움이 되실 것 같습니다. 🙂

Facebook을 다운 시킨 원인, BGP hijacking은 무엇인가?

Sun, 31 Dec 2023 06:21:20 GMT

개요

2021년 10월, 페이스북(현 Meta)의 서비스(FaceBook, Instagram, WhatsApp, Oculus, ...) 전반을 이용할 수 없는 장애가 발생 했었습니다. 해당 장애는 긴급 복구되는데 5시간, 완벽하게 복구되는데 12시간이 걸렸을 정도로 이례적으로 오래걸렸는데요.

이런 경우 일반적으로 서버 장애, 서버 다운이라고 표현하지만 정확히 말하자면 이는 서버 다운은 아니었습니다. 네트워크의 문제였습니다.

그리고 이렇게 복구에 오래 걸리는 네트워크 관련 문제는 대부분 "DNS"에 의해 발생합니다.

실제로 페이스북, 인스타그램 접속 제한의 문제도 DNS였구요. 구체적으로 공개되기 전 까지는 BGP hijacking을 비롯한 BGP 관련 문제가 아닐까 단순히 '추정'하고 있었는데, 그 추정이 사실이었습니다. What took Facebook down @ ZDNET

BGP(Border Gateway Protocol)는 인터넷 최상위에 존재하는 autonomous systems (AS) (ex. KT, SKT, LGU+ 등 ISP)간에 라우팅에 사용되는 표준 프로토콜입니다. 그렇기 때문에 대부분의 사람들과 각 기업의 네트워크 관리자들은 일반적으로 BGP를 다룰 일이 없습니다.

그리고 이 문제는 단순히 서비스를 이용할 수 없는 것에서 그치는 것이 아니라 여러가지 성가신 문제를 야기하기도 했는데요.

As annoying as this is to you, it may be even more annoying to Facebook employees. There are reports that Facebook employees can't enter their buildings because their "smart" badges and doors were also disabled by this network failure. If true, Facebook's people literally can't enter the building to fix things.

해당 네트워크 장애로 인해 건물 출입 인증 시스템 또한 무력화 되었다는겁니다. 즉, 복구를 위해 건물에 들어갈 수 없는 문제가 발생한건데요. 이정도로 장애의 범위가 컸기 때문에 복구까지 더욱 오래 걸린 것이 아닌가 싶습니다.

그래서 BGP와 BGP Hijacking이 뭐길레 이런 문제가 발생했을까 궁금 하실텐데요. BGP에 대해 이야기해보기 전, DNS의 전반적인 구조에 대해 먼저 이야기 해보겠습니다.

DNS

이 그림은 인터뷰에서 자주나오는 질문 중 하나인, “브라우저에 URL을 입력했을 때 일어나는 일”을 DNS 레벨에서 표현한 다이어그램입니다.

www.naver.com → Local DNS → Root DNS → com DNS → naver.com DNS → ...

내가 접속하고자 하는 도메인을 입력하면, 해당 도메인에 대한 정보를 가진 DNS로부터 IP 정보를 받아오게 됩니다. 그 후, 해당 아이피로 HTTP 요청을 보내는 것이지요.

그렇다면 네트워크 상에는 IP를 가진 정말 많은 디바이스가 존재할텐데, 내가 찾아가야 하는 IP는 어떻게 찾는걸까요?

디테일하게 설명하면 복잡하고, 오늘의 핵심은 아니기 때문에 정말 간단하게 설명하자면, 우리가 사용하는 모든 네트워크는 어떤 통신사에 소속되어 있습니다. 그렇기 때문에 통신사에서는 IP에 대한 모든 정보를 지니고 있습니다.

네, 맞습니다. 그냥 통신사에서 알려주는겁니다. 다만 내 IP 주소와 목적지 IP 주소가 같은 통신사라면 이렇다고 이해해주시면 좋을 것 같구요. 서로 다른 통신사에 속해있다면 BGP 라는 개념이 등장하게 됩니다.

BGP

앞서 잠깐 설명 드렸듯 BGP는 인터넷 라우팅 프로토콜이며, 사용자의 트래픽이 목적지 IP 주소에 최대한 효율적으로 도달할 수 있도록 방향을 제공합니다.

사용자가 웹 브라우저에서 도메인 주소(ex. facebook.com)를 입력하면 DNS에서 IP 주소를 제공해주고, BGP는 해당 IP 주소에 도달하는 가장 효율적인 방법을 제공하는 것이죠.

각 AS들은 BGP를 이용하는 BGP 라우터들을 가지고 있습니다. 그리고, 각 BGP 라우터는 AS 간의 최적 경로가 포함된 라우팅 테이블을 저장하고 있는데요.

이 라우팅 테이블은 각 AS가 자신이 소유한 새로운 IP 접두사를 브로드 캐스트함에 따라 거의 실시간으로 업데이트 됩니다. 여기서 보안 문제가 발생합니다.

BGP Hijacking

인터넷은 상호 연결된 여러 개의 대규모 네트워크로 구성되어 있습니다. 이들은 모두 분산되어 있기 때문에 데이터 패킷이 의도한 대상 IP 주소에 도달할 수 있도록 하는 관리 기관이나 교통 경찰 같은 역할이 특별히 존재하지 않습니다.

그래서 BGP가 이 역할을 수행합니다. BGP가 없다면 웹 트래픽은 비효율적인 라우팅으로 인해 목적지에 도달하는 데 엄청난 시간이 걸리거나 의도한 목적지에 전혀 도달하지 못할 수도 있습니다.

그리고 각 BGP 라우터들은, AS의 라우팅 테이블 업데이트 요청을 거의 무조건 신뢰합니다.

예를 들어, AS 100에 속하는 IP prefix가 192.0.2.0/24 라면, AS 100은 이웃하는 BGP peer 들에게 "192.0.2.0/24"에 속하는 주소는 자신에게 보내라고 알리는 것입니다.

그리고 이 전파는 또 다른 이웃 BGP peer에게 거의 실시간으로 전파되게 됩니다.

이를 이용한 하이재킹은 다음과 같은 방식으로 이루어집니다.

기존에 페이스북 IP에 대한 라우팅 정보를 갖고 있는 AS 1000이 있고, 페이스북의 IP Prefix는 다음과 같다고 가정해봅시다.

222.111.192.0/24
222.111.193.0/24
222.111.195.0/24
222.111.197.0/24
222.111.199.0/24

그런데 AS 2000이라는 곳에서 페이스북의 IP Prefix는 우리한테 연결해. 라고 브로드캐스트 해버리는 것입니다.

그렇게 된다면 다른 BGP Peer들은 이 AS의 업데이트 요청을 신뢰하게 되고, 실제로 페이스북 IP 주소로 연결되는 요청 모두를 AS 2000으로 보내버리게 됩니다. (가장 최근 발생한 브로드캐스트를 신뢰함)

다이어그램으로 표시하자면, 이런 느낌이 되겠네요.

이것이 BGP와 BGP Hijacking의 대략적인 설명이며, 이를 방지하기 위해 RPKI와 BGPsec라는 솔루션이 제시되기도 했지만, 이러한 솔루션들은 아직까지 널리 적용/구현되지 않은 상태입니다.

즉, 우리가 매일 사용하고 있는 인터넷 세상은 Routing Security 관점에선 아직 완전하지 못하다 볼 수 있습니다.

모든 회사에 어필 할 수 있는 지원 동기와 목표설정 방법

Thu, 28 Dec 2023 10:36:37 GMT

잘못된 지원 동기

취업/이직에 도전하는 많은 분들을 만나보니 지원 동기를 작성하기 위해 어려움을 겪으시는걸 자주 목격하는데요. 일부는 '당연히 돈을 벌기 위해서'라고 표현하시기도 하는데, 이건 정말 성숙하지 못한 이유라고 생각합니다.

다들 지원 동기를 작성하거나 말하라고 하면 어떻게 이야기를 풀어내시나요? 제가 가장 많이 본 유형은 아래와 같은데요.

OO 회사에서 만들고 있는 제품에 많은 관심이 있습니다. 해당 제품을 만드는 프로젝트에 정말 참여하고 싶고, 이를 열정적으로 원합니다. 또한 OO 회사에 합류하게 된다면 좋은 개발 문화 속에서 함께 배우면서 성장할 수 있을 것 같아 지원하게 되었습니다.

어떻게 보이시나요? 저는 정말 아마추어적인 자세라고 생각합니다. 소위 돈 받고 일하는 프로들은 이렇게 Job을 접근하면 안됩니다.

보통 회사에서 새로운 포지션을 외부에 오픈하고 채용을 진행할 때에는 어떤 문제를 함께 해결하는데 기여해줄 수 있는 사람을 찾길 기대합니다. 막연히 가르쳐주고 보살펴주기 위해 채용하는 경우는 없습니다. 이는 신입도 마찬가지입니다.

그럼 지원 동기는 어떻게 구성해야 할까요? 저는 아래의 포맷이 가장 바람직하다고 생각합니다.

제가 궁극적으로 해보고 싶은 것(목표)은 A입니다. 이를 위해선 xx, yy, zz 라는 경험이 필요할 것이라는 판단을 하였습니다. 과거에는 xx와 yy라는 경험을 해보았고, 이걸 바탕으로 OO 회사에서 ~~~ 이렇게 기여해볼 수 있을 것으로 판단됩니다. 또한 평소 관심있는 프로젝트에 직접 기여할 수 있다는 부분이 너무 기대 되고, 아직 경험해보지 못한 zz를 경험 해볼 수 있다는 부분에도 큰 기대가 있어 지원하게 되었습니다.

이 포맷은 크게 세 가지 정보를 포함하고 있고, 모두 채용하는 입장에서 중요하게 평가하는 부분입니다.

중장기적인 커리어 목표
과거의 경험과 강점
합류하게 된다면 회사와 팀에 기대하는 부분

그리고 내가 궁극적으로 해보고 싶은 것이 무엇인가라는 고민은 미리, 자주 해봐야합니다. 그래야 중간중간 방향을 잃거나 번아웃이 오더라도 다시 어떤 방향으로 나아가면 되는지 알려주는 이정표의 역할로 활용할 수 있습니다.

일반적인 사람과 일반적이지 않은 사람

회사에서 이력서를 검토하고 탈락시킬 때, 어떤 이유가 가장 많을까요? Hard Skill에 대한 Level과 Depth는 인터뷰 과정에서 검토해야하니 논외로 둔다고 생각하면,

경력과 이력이 너무 일반적이라서
커리어에 대한 진정성이 부족해서
이력서와 경험에 대한 디테일이 얼라인되지 않아서

이정도가 떠오릅니다. 경력과 이력이 너무 일반적이라서 서류 탈락하는 경우는 간단합니다. 비슷한 유형의 경력과 경험, 이력을 가진 사람은 정말 많습니다. 이제 막 개발자로 취업하기 위해 취업 시장에 뛰어드신 분들에게 왜 개발자로 일하고 싶으신가요? 라는 질문을 하면 많은 분들이 이렇게 대답합니다.

우연히 개발을 알게 되어서(또는 관련 학과를 진학하게 되어서) 개발을 해보았는데, 저랑 잘 맞는 것 같고 앞으로 계속 하고 싶다는 생각이 들었습니다.

이게 나쁘다는 것은 아닙니다. 다만 똑같이 이야기하는 다른 99%가 있다는게 문제입니다. 어떻게든 나는 99%에 속하는 사람이 아니라 1%에 속하는 사람이라는걸 평가자들에게 증명 해야만 합니다. 모든 평가자들은 평가를 할 때 원칙이 있습니다.

모든 평가자는 개인의 노력을 믿어주지 않는다.

그래서 더더욱 나는 99%의 일반적인 사람이 아니고, 개발자로서의 커리어를 진지하게 생각하고 있다라는 것을 어떻게든 증명해내야만 합니다. 그 방법 중 가장 쉬운 것이 앞서 이야기한 내가 궁극적으로 해보고 싶은 것은 무엇이고 이를 달성하기 위해 필요한 경험 및 기술은 무엇이 있을지 고민해본 과정을 진정성있게 설명하는거라고 생각합니다.

결론: 지원 동기, 단순한 문장이 아닌 나의 커리어 청사진

지원 동기 작성은 단순히 그때 잠깐 고민하고 끝나는 과제 같은게 아닙니다. 이는 나의 커리어 목표, 과거 경험, 그리고 잠재력까지 전달 할 수 있는 효과적인 수단입니다. 그렇기에 미리 자신에 대해 깊이 있게 탐색하고, 진정으로 원하는 바와 그것을 달성하기 위해 필요한 경험과 기술을 도출해내는 시간을 가져야 합니다.

이 과정은 단순히 취업과 더 나은 환경으로의 이직을 위한 수단이 아니라, 커리어 방향을 설정하고 장기적인 목표를 세우는데 매우 중요한 과정이라는걸 명심하고 꼭 따로 시간내서 고민 해보셨으면 좋겠습니다.

블로그 이관 및 앞으로의 계획

Mon, 25 Dec 2023 03:53:21 GMT

블로그를 이관했습니다! 🎉

기존에는 티스토리 블로그를 사용했었고, 여러 블로그 플랫폼을 이용해보면서 느꼈던 경험은 다음과 같았습니다.

네이버 블로그 : 개발자들이 기술 컨텐츠를 다루기에는 생태계 자체가 친화적이지 않았습니다.
벨로그 : Simple, but too simple. 사용하기 간편해진 네이버 블로그라는 느낌이 강했습니다. 커스터마이즈에 대한 한계가 명확했습니다. 오픈소스임에도 발전이 너무 느렸습니다.
워드프레스 : 간단한 정적 컨텐츠를 다루기에는 적합했습니다. 하지만 필요 이상으로 너무 무거웠고, 무엇보다 느렸습니다.
GitHub Pages 정적 블로그 : Jekyll/Gastby 기반 GitHub Hosting 정적 블로그입니다. 블로그의 테마나 소소한 설정을 변경할 때 마다 Commit이 생성되는게 너무 싫었습니다. 마크다운 파일을 하나하나 관리하는 번거로움도 있었구요.
티스토리 : 이리저리 옮겨다니다 결국 정착한 플랫폼이었습니다. 나름 OpenAPI도 제공하고, SEO도 준수 했습니다.

그렇게 티스토리를 몇년간 잘 사용하면서도 Custom Domain에 대한 지원이 미흡한 부분이 정말 아쉬웠습니다. 그럼에도 참아가며 잘 사용하고 있었는데, 이번에 올라온 [안내] 티스토리 Open API가 종료됩니다. 공지사항을 보고선 빠르게 블로그 플랫폼을 옮겨야겠다는 생각이 들었습니다.

아예 서비스를 버리지 않고 정비를 해나가는 부분에서 긍정적이기도 했지만, 대략 전해 들어 알고 있는 티스토리 개발 팀의 현황(?)을 고려해보았을 때 아쉬운 부분이 빠른 시일 내에 해결되기는 어려울 것이란 판단이 들었습니다.

그래서, 지금 보시는 블로그로 이관했습니다!

이 블로그는 GitHub Pages 정적 블로그입니다. 처음 GitHub Pages 정적 블로그를 접하고 몇년이 지나면서 처음 느꼈던 불필요한 Commit이 생성되는 부분을 회피할 방법을 알게 되었고, 무엇보다 너무 매력적인 블로그 테마를 발견했기 때문에 돌아오게 되었습니다.

vallista-land

해당 블로그는 우아한형제들에 재직중이신 마광휘님이 만드신 오픈소스 블로그 Vallista/vallista-land를 활용하여 만들어졌습니다.

vallista-land 프로젝트 소개 글을 조금 인용하자면 크게 신경 쓴 사항은 다음과 같다고 합니다. 자세한 내용은 링크에서 확인 부탁드립니다. 🙂

Windows, Mac OS 두 환경에서의 크로스 브라우징 대응 (Chrome, Safari...)
모바일 대응 (Android, iOS)
모노레포를 이용한 사이드 프로젝트에서 사용할 디자인 컴포넌트의 구축
다크 모드 지원
GraphQL query 성능 향상
컴포넌트 모듈화

Repository에 별도로 LICENSE가 명시되어 있지 않아 제작자분에게 별도로 문의해본 결과 마구 사용하여도 된다.는 답변을 받고, 컬러 토큰과 디자인 컴포넌트를 약간 커스터마이즈하였습니다. 덕분에 이전에 경험해본적 없던 lerna + yarn workspace 환경을 얕게나마 구경해볼 수도 있어서 좋은 경험이었습니다.

앞으로의 계획

점진적으로 기존 블로그에서 일부 게시글을 옮겨오고, 새로운 컨텐츠는 크게 네 가지 내용을 다루게 될 것 같습니다.

스타트업 공동창업가 겸 CTO로서의 업무/일상에 대한 소소한 이야기
웹 프론트엔드 엔지니어링에 대한 이야기
웹 백엔드 엔지니어링에 대한 이야기
소프트웨어 엔지니어 커리어 이야기

그럼, 잘 부탁드립니다!

???: 빌드가 완료되면 소리 나게 해주세요.

Sat, 23 Sep 2023 15:18:07 GMT

출처: https://xkcd.com/303

유명한 한 컷의 만화가 있습니다. <My Code's Compling>

업무 시간에 일은 안하고 동료와 칼싸움(...)을 하고 있는 사람에게 상사가 '돌아와 일해라'라고 이야기하니 컴파일중이라고 말하고, 상사는 알겠다며 하던 일(칼싸움)을 마저하라는 짧은 만화인데요.

이 만화가 처음 등장했을 때에는 C++ 언어로 작성된 소스코드를 컴파일하는데 오래 걸리는걸 유머스럽게 풀어낸 것이지만.. 그 이후 시간이 지나며 C++보다 더 오래걸리고 느린 언어들이 훨씬 많아졌습니다.

출처: https://thenewstack.io/which-programming-languages-use-the-least-electricity

최근 자바/스프링 진영에도 Spring Native, Native Compile이 도입되면서 이를 사용하는 경우 정말 느린 컴파일 속도를 경험해볼 수 있는데, 이와 관련하여 재미있는 오픈소스 Issue 및 PR이 있어 공유해봅니다.

Native Compile이 느린 이유는 여기서 서술하지 않으니 궁금하시다면 AOT Compile과 JIT Compile에 대해 찾아보시면 좋을 것 같습니다.

출처: https://github.com/oracle/graal/issues/5327

이 이슈는 joshlong(VMware Spring team 소속으로 Spring Project를 만들고 있음)이 올린 이슈로 컴파일이 오래 걸릴때 마다 엘리베이터에서 흘러나오는 음악이 머릿속에서 재생되고 있고, 다른 사람들도 이걸 들을 수 있으면 좋겠다는 이슈(기능 제안)이었습니다.

얼핏 보면 정말 황당한 이슈입니다. 하지만..

Andrew Dinn(adinn; Red Hat Distringuished Engineer), Ivan Ristović(ivan-ristovic; Oracle SDE), Fabio Niephaus(fniephaus; Oracle SDE) 같은 거장들이 이걸 재미있게 받아들이며, 관련 PR이 1차로 올라오게 됩니다.

출처: https://github.com/oracle/graal/pull/5331

1차 PR은 더 나은 확장성과 효율성을 고려하여 Closed 되었고,

출처: https://github.com/oracle/graal/pull/5395

2차 PR에서 최종적으로 Merged 되어 관련 내용이 문서에 포함되게 됩니다.

한기용님과 함께하는 단체챗 회고

Wed, 30 Aug 2023 11:41:00 GMT

어제(2023.08.29, 화) 저녁에 한기용님과 함께하는 단체챗에 참가했습니다.

평소 다양한 모임과 세미나, 컨퍼런스 등을 참가하는 편인데 여태 참가했던 모임 중 가장 인사이트가 있었던 시간이 아니었나 싶습니다.

간략하게 요약해보면,

[피드백을 주는 방법]

어떤 피드백을 주고 싶은지 -> 어떻게 전달할 것인지 순서대로 생각하자.
불편함과 친해지려고 노력해야 한다.
팀원에게 항상 좋은 사람이 되고 싶다면 좋은 매니저가 될 수 없다.
내가 하고 싶은 이야기를 명확히 하자.
- 건설적인 피드백 / 부정적인 피드백 등 하나만 이야기해야 한다.
내가 하고 싶은 이야기가 명확해졌다면 지금 하는 게 맞는지 고민하자.

Feedback Framework: 기대 한 것 -> 관찰 한 것 -> 차이 -> 개선계획

[리더로서 노력해야 하는 것]

질문을 잘하는 환경을 만드는 것이 중요하다.
- 의도적으로라도 질문을 할 수 있게끔 만들자.
- 순진한 질문이어도 좋다.
자기검열 하지 않는 환경을 만들어야 한다.

[피드백 한 번에 개선될 것이라 기대하지 말자]

기대-관찰-갭-개선계획 템플릿으로 자주 이야기하자.
그럼에도 변하지 않는다면 채용 노트를 살펴보며 채용 과정을 돌이켜보자.
대부분은 현재 환경과 이전 환경이 크게 달라 그런 경우가 많으니 이 부분에 대해 깊게 이야기해 보자.

[기용님이 생각하는 좋은 사람, 기억에 남는 사람]

자신의 일 뿐 아니라 주변 사람들을 함께 챙기는 사람

[추천 도서]

원서: The Five Dysfunctions of a Team
번역서: 팀워크의 부활

Java Compiler Optimization

Sun, 11 Dec 2022 23:03:12 GMT

시작하며

프로그래머가 작성한 자바 소스 코드가 실제로 실행되기까지는 꽤나 복잡한 과정을 거치게 됩니다.

자바 소스 코드를 바이트 코드로 변환
변환된 바이트 코드를 JRE(Java Runtime Environment)에 적재
JRE는 실시간으로 런타임에 기계(컴퓨터)가 이해할 수 있는 형태로 변환 후 실행

1번은 javac를 이용한 '컴파일' 행위이며, 2번은 컴파일된 결과물(.jar)을 java 런타임으로 실행하는 것이며, 3번은 얼핏 보았을 땐 인터프리터의 동작 방식과 유사합니다.

이번 게시글에서는 자바 컴파일의 각 과정에 대해서 간략하게 다루어 보고 그 과정 속에서 컴파일러가 자체적으로 어떤 최적화를 하며, JVM Option으로 컴파일러를 최적화할 수 있는 몇 가지 방법에 대해 이야기합니다.

Java Virtual Machine / Java Runtime Environment

우선 JVM, JRE이 등장하게 된 역사부터 살펴볼 필요가 있습니다. JAVA 이전에 등장한 C, C++ 같은 언어들은 컴파일 과정에서 어느 플랫폼(CPU Architecture)에서 실행할 것인지 명시해주고, 각 플랫폼에 최적화된 Native Code를 만들어내는 구조였습니다. 즉, 빌드 결과물은 특정 플랫폼에서만 실행 가능했다는 의미입니다.

하지만 이러한 방식은 여러 종류의 플랫폼이 등장하며 단점으로 대두되었습니다. 즉, 소프트웨어의 전파를 제한하고 사용자와 공급자 모두에게 번거로움을 가져다주는 단점이 있었던 것입니다. JAVA는 이러한 단점을 극복하고자 컴파일 과정에서 바이트 코드를 생성하고, 런타임에 각 플랫폼에 적합한 형태로 바이트 코드를 네이티브 코드로 변환하는 구조를 가지게 됩니다.

Java Compiler at compile time

컴파일 타임의 자바 컴파일러, 즉 javac는 소스 코드(.java 파일)를 바이트 코드(.class 파일)로 만들고 .jar 같은 형태로 패키징 하는 컴파일러입니다. 이후 JVM은 런타임에 바이트 코드를 한 줄씩 읽어가며 네이티브 코드로 변환하는 인터프리터 방식으로 동작합니다.

JIT Compiler at run time

하지만 매번 한 줄씩 읽으며 네이티브 코드로 변환하는 방식은 필연적으로 속도가 느릴 수밖에 없습니다. JIT 컴파일러는 자주 실행되는 코드 블록의 바이트 코드(.class 파일)를 네이티브 코드(binary code)로 컴파일해주는 역할을 합니다.

모든 바이트 코드를 일괄로 네이티브 코드로 컴파일할 수 있다면 좋겠지만 컴파일을 위해선 프로세서와 메모리를 사용해야 하고, 그 시간이 얼마나 걸릴지 장담할 수 없기 때문에 절충안으로 선택된 것이 JIT 컴파일러입니다.

만약 자바가 런타임 초기에 모든 바이트 코드를 일괄 컴파일하도록 되어 있고, 전체 컴파일에 1분이 걸린다면 사용자는 java 애플리케이션 실행 시 1분의 컴파일 타임을 대기하여야 합니다. 이는 자바 기반 웹 애플리케이션을 배포하는데도 그 정도 시간이 소요된다는 의미이기도 합니다.

이러한 이유로 JIT 컴파일러는 각 메서드마다 호출 카운트를 관리하고, 일정 횟수 이상 호출되면 just-in-time 컴파일을 수행합니다. 따라서 자주 사용되는 메서드는 런타임 직후 컴파일되며, 잘 사용되지 않는 메서드는 훨씬 나중에 컴파일되거나 전혀 컴파일되지 않습니다.

JIT 컴파일 & 최적화

Dynamic Lookup

/* .... */
obj1.equals(obj2)

이 코드는 obj1의 타입에 따라 동작이 달라집니다. 그렇기 때문에 어떤 동작을 할지 Dynamic Lookup이 필요하며 Dynamic Lookup은 런타임에 해당 오브젝트의 타입을 결정하므로 매우 느립니다.

따라서 JVM은 이 코드가 실행될 때마다 obj1이 String이라는 것을 안다면, Dynamic Lookup을 하지 않고 String.equals 메서드를 호출하도록 컴파일합니다. (물론 100% 보장할 수 있다면 베스트이지만, 다른 타입에 올 가능성이 있기 때문에 가능성은 열어두고 컴파일합니다.)

Code Cache

코드 캐시는 JIT 컴파일러에 의해 컴파일된 코드가 캐싱되는 저장 공간입니다. 캐시의 사이즈는 고정 크기이며, 가득 차면 JVM은 더 이상 코드를 컴파일할 수 없습니다. 즉, 컴파일되지 않은 많은 양의 코드가 인터프리터로 실행되어 느려지게 됩니다. 이 경우 JVM Warning이 발생하기는 하지만 이 로그를 체크하는 건 마냥 쉽지는 않습니다.

캐시 크기 조정 관련 JVM Option

코드 캐시 최대 사이즈

-XX:ReservedCodeCacheSize=XXXXX (240m, 2g, 100k 등등)

시작 시 코드 캐시 사이즈

-XX:InitialCodeCacheSize=XXXXX (240m, 2g, 100k 등등)

Java Monitoring & Management Console

JDK가 설치되어 있다면 $ jconsole 를 입력하여 힙 메모리, 코드 캐시 등을 모니터링할 수 있습니다

컴파일 임계치

앞서 JIT 컴파일러의 동작 기준이 '많이 사용되는 메서드'를 컴파일한다고 말했습니다. 여기서 '많이 사용되는'의 기준이 컴파일 임계치입니다.

컴파일 임계치는 메서드가 호출된 횟수(method entry counter) + 메서드 내 루프가 있다면 루프를 빠져나오기까지 실행된 횟수(back-edge loop counter)를 기반으로 측정하며, JVM은 지속적으로 두 카운터의 합계를 확인하고 메서드가 컴파일될 자격이 있는지 검증합니다. 만약 자격이 있다면 컴파일 큐에 추가됩니다.

OSR; On-Stack Replacement

처음 실행된 메서드이지만, 루프가 정말 길다면 남은 반복을 빠르게 실행하기 위해 중간에 컴파일될 필요가 있습니다. 따라서 루프의 실행을 그때그때 카운트하고 임계치를 넘어가면 전체 메서드가 아닌 루프만을 따로 컴파일해서 컴파일된 버전을 실행합니다.

이렇게 스택상에서 컴파일된 버전을 바로 실행시키는 것을 OSR이라고 부릅니다.

컴파일 임계치 변경 JVM Option

-XX:CompileThreadhold=N

컴파일 임계치를 지정하는 옵션으로 클라이언트 컴파일러에서 기본 값은 1,500이며 서버 컴파일러의 기본 값은 10,000입니다. JVM 튜닝에 있어 컴파일 임계치를 변경하는 것은 상당히 권고되는 최적화 방법입니다.

Why?

애플리케이션이 워밍업 하는데 필요한 시간을 절약할 수 있습니다.
- 1만 번 실행되어서 컴파일될 코드는 8천 번으로 줄여도 큰 차이가 없기 때문입니다.
절대로 컴파일되지 않을 일부 서버 메서드를 컴파일할 수 있습니다.
- 컴파일 임계치에 가까이 있지만, 아슬아슬하게 걸쳐서 컴파일되지 않는 것들을 컴파일해 실행 속도를 높일 수 있습니다.

마무리

컴파일 임계치와 관련된 카운터 값은 최근 기간에 대한 상대적 측정값입니다. 따라서 긴 시간에 걸쳐서 많이 호출되는 메서드(lukewarm method)는 카운터 값이 낮을 수밖에 없습니다. 컴파일러 최적화를 고려하고 있다면 컴파일 임계치를 낮추고, 그에 따라 코드 캐시의 크기를 늘리는 방식을 선제적으로 간단하게 적용해볼 수 있을 것입니다.

내가 개발 커뮤니티를 하는 이유 (a.k.a. 10년 회고)

Sun, 04 Dec 2022 02:35:00 GMT

children are together

시작하며

안녕하세요, 개발자 진태양(Theo)입니다. 어느덧 벌써 12월입니다. 슬슬 2022년 회고를 작성해볼까 고민하던 시점에, 문득 1년 회고가 아니라 10년 회고를 해보고 싶어졌습니다.

왜 10년이냐고요? 사실 10년 자체에 어떤 의미가 있지는 않습니다. 그냥 제가 개발에 처음 관심 가지게 된 것이 거의 10년 전이기 때문입니다. (정확히는 곧 13년인데 이뻐 보이려고 10년으로 추렸습니다.)

이번 글에서는 개발을 처음 알게 된 시점부터 현재까지의 제 이야기를 회고 형식으로 풀어내며 제가 개발 커뮤니티를 하는 이유에 대해 나눠보고자 합니다. 상당한 장문이 예상되기에 글을 크게 다듬지 않고 빠르게 초판을 먼저 발행해보려 합니다.(글을 다 쓰고 보니 거의 8시간에 걸쳐 썼네요.) 그렇기에 지속적으로 내용이 수정될 수 있으며, 글의 하단에는 '내가 개발 커뮤니티를 하는 이유'에 대한 요약본을 달아두겠습니다. 😊

2010년: 개발 시작

2010년의 저는 중학교 2학년 학생이었습니다. 그때 당시 다녔던 중학교는 2008년에 설립되어 제가 입학할 때 당시엔 학급 자체가 3학년이 없었으며 도서관을 비롯한 내부 시설이 정말 잘 되어 있었던 기억이 있습니다. 그리고 중학교 특성상 거주지 인근에 있는 학교로 배정되기 때문에 하교 후, 주말, 방학 같이 시간이 빌 때마다 도서관에 들려 관심 있는 책을 읽기도 했습니다. 물론 대부분 역사 소설이나 수필이었습니다. 🙂

중학교 입학 후 대략 1년 6개월 동안 수십(어쩌면 수백)권의 책을 읽다 보니, 더 이상 기존에 자주 들리던 도서관 섹션에서는 읽을만한 책이 남아있지 않았습니다. 그러다 그때 당시 정말 구석에 있었던 컴퓨터 섹션을 우연히 들리게 되었고 그곳에서 제가 태어나기 한참 전에 만들어진 Visual Basic 6.0 언어를 다룬 책을 발견하게 됩니다.

그 책의 제목은 정확히 기억나지 않지만, 그 옆에 '트위터 완전정복' 같은 뉘앙스를 지닌 트위터 사용법을 알려주는 책이 있었던 기억이 납니다. 최근에는 상상도 못 할 내용의 책이지만, 그때 당시는 컴퓨터와 인터넷 관련된 모든 것들이 아직도 새롭고 낯선 시기였습니다.

아무튼 Visual Basic 6.0 언어를 다룬 책을 빌려보았고, 관련 내용을 인터넷에 검색도 해보면서 여러 가지 예제를 만들어보았는데 그게 너무 재미있었습니다. 다른 사람들이 만들어서 공유해준 프로그램의 소스코드를 분석해보고 내가 만든 프로그램을 공유하는 것 자체가 즐거웠던 것 같습니다. 그리고 이때 당시에 빌려보았던 책 중에는 '프로그래머의 길, 멘토에게 묻다'라는 책도 있었는데, 이 책은 아직까지도 제 마음속 베스트셀러 1위로 남아있습니다.

2012년: 게임 개발

고등학교에 진학했습니다. 물론 일반적인 고등학교는 아니었고, 일부러 개발을 계속할 수 있는 학교로 지원하여 입학하게 되었습니다. 진학했던 고등학교는 모바일 로보틱스라는 종목으로 기능경기대회 팀을 운영하고 있었습니다. C언어를 이용해 모바일 로봇을 제어하고, 과제의 요구사항에 따라 동작하게끔 하는 종목이었습니다.

그런데 제가 입학하는 시점에 종목이 모바일 로보틱스에서 게임 개발로 바뀌게 되었습니다. 그러다 보니 학교나 팀에 노하우가 전혀 없는 상황이었고 학교에서는 그 팀을 처음부터 빌딩 해나 갈 멤버를 구해야만 했습니다. 그때 당시 저에게도 담당 선생님의 제안이 있었는데, 잠깐의 고민 후 팀에 합류하겠다는 의사를 전달했습니다. 그 후 3D 그래픽스와 사운드를 함께 해줄 수 있는 팀원을 한 명 더 찾을 수 있었고 두 명이서 C++, DirectX9, Windows API를 기반으로 한 2D Stripe Engine과 그 엔진을 이용한 게임을 만들기 시작했습니다.

팀 합류(=팀 빌딩) 이후 첫 1년은 정말 바빴습니다. 장비, 공간, 도서, 시스템, 정책 등 모든 걸 갖추어야 했고 정작 게임 개발 공부 자체엔 시간을 많이 쓰지 못했던 것 같습니다. 그래도 그때는 아무런 고민과 걱정 없이 시간을 보냈습니다.

2013년: 본격적인 시작

대략 1년이 지나니 어느 정도 팀은 안정화되고, 기존의 방식에는 꽤나 익숙해진 상태였습니다. 그런 시점에 신입생이 들어오며 팀에도 새로운 팀원이 합류하게 되었습니다. 다 함께 재미있게 공부하고, 대회를 준비했던 기억이 새록새록 납니다. 물론 중간중간 벤치마킹이라는 핑계로 이런저런 게임을 함께 했던 기억도 있네요. 😅

이때부터는 본격적으로 팀 단위로 기능경기대회를 비롯한 여러 대회를 나가며 경험을 쌓기 시작했습니다. 상을 받기도 하고, 아쉬운 결과를 얻기도 했지만 팀과 함께한다는 것 자체가 즐거웠습니다. 여러 경험을 하던 도중 인근에 있는 게임 개발사에서 일을 해볼 기회를 얻게 되었고, 그렇게 개발자가 되었습니다.

2014년: 고도화

주변을 둘러보니 대단한 사람들이 너무 많았습니다. 나이도 비슷하고, 과거 경험도 얼추 비슷한 것 같은데 국제무대에서 활동하는 소프트웨어 엔지니어, 보안 엔지니어가 즐비했습니다. 이때 즈음 내가 너무 세상을 좁게 보고 있는 건 아닐까? 걱정되었습니다. 자연스럽게 더 넓은 필드에서 더 다양한 경험을 해보고 싶어 졌습니다. 기존에 함께하던 게임 개발사를 떠나 규모가 더 큰 게임 개발사에서 일을 시작했습니다. 그리고 작은 규모의 게임 개발 교육원에서 교육 보조(조교)를 겸하였습니다.

하지만 아직까지 고등학생이었고, 무엇 하나 제대로 아는 것 같지도 않은데 이런 식으로 경험을 쌓아가도 되는 건가? 불안했습니다. 그러던 중 삼성에서 대규모 채용이 열렸습니다. 무턱대고 대기업이니 도전해보고 싶어 졌습니다. '여기에 합격한다면 나름 인정받을 수 있는 거 아닐까?'라는 생각도 있었습니다. 그렇게 서류 전형, 인적성 검사(SSAT), 면접 전형 어느 하나 제대로 준비하지 않고 누구에게도 알리지 않은 채 삼성전자 S직군 고졸/졸업예정 공개 채용에 지원하였습니다.

운이 좋았던 것인지, 서류 전형과 인적성 검사를 합격하였고 면접 전형에 참가하였습니다. 정확한 면접 전형이 기억나지는 않지만 간단한 정렬 문제를 A4 용지에 각자 풀이하고 그걸 면접관 앞에서 화이트보드에 풀이한 뒤 서류 기반 몇 가지 질문이 오고 갔던 기억이 있습니다.

물론 제가 진행했던 면접 과정과 내용은 초라하기 그지없었습니다. 화이트보드에 중구난방으로 판서했고, 면접관이 하는 질문은 모두 예상치 못한 질문들이었으니까요. 면접이 끝나고 그제야 인터넷을 통해 다른 사람들의 면접 사례를 찾아보니 저를 제외한 대부분의 사람들이 화이트보드에 플로우 차트를 그려가며 논리 정연하게 풀이하고, 소위 말하는 임원 면접도 멋들어지게 답변하는 연습을 했다는 것을 알 수 있었습니다.

면접 유형이나 예상 질문이 인터넷상에 돌아다니고 있었는데도 그걸 찾아볼 생각도 안 했고, 비슷하게 흉내도 못 냈기에 당연히 면접 전형에서는 불합격했습니다. 이때 면접에 응시한 80여 명 중 2명이 최종 합격했던 것으로 기억합니다.

2015년: 포기

고등학교를 졸업하였고, 여전히 게임 개발과 관련된 일을 하고 있었습니다. 1년 전에 했던 '이런 식으로 경험을 쌓아가도 되는 건가?'라는 고민과 걱정은 여전했습니다.

나는 이 일을 왜 하고 있는가? 근본적인 이유를 생각해보았습니다.

돈을 벌 수 있다.
게임이 즐겁다.
개발 외엔 경험해보지 않았다.

이 셋이 끝이었습니다. 그런데 이때 즈음부터 게임이 즐겁지 않았습니다. 특별한 이유는 없었습니다. 그냥 무슨 게임을 하든 즐겁지 않았습니다. 그리고 꼭 이 일로만 돈을 벌 수 있는 것도 아니었습니다. 4년 전에 했던 것처럼 C#을 이용해 윈도우즈 애플리케이션을 판매한다면 여전히 돈을 벌 수 있는 시장이었습니다.

그래서 게임 개발을 그만두었습니다. 약 1년간 쉬어가며 간간히 목돈이 필요할 때마다 외주를 했습니다. 이때 당시엔 자연스러운 의식의 흐름이었지만, 지금 돌이켜보면 '게임 개발을 포기했다'에 가까웠던 것 같습니다.

2016년: 휴식

군대를 가야만 했습니다. 주변에서는 산업기능요원으로 병역 문제를 해결하는 경우가 많았지만, 이를 위해 게임 개발 세계로 돌아가고 싶지 않았습니다. 그렇게 2016년 6월, 햇살이 가장 따스할 때 즈음 논산 훈련소로 입대하였습니다.

지난 6년간 나쁜 습관이 누적되었던 탓이었을까요, 훈련소 입소 이후 진행하는 간이 신체검사에서 허리 디스크와 관련된 질병이 식별되었고, 1주일이 채 되지 않아 훈련소에서 나오게 되었습니다. 그렇게 다시 민간인 신분이 되었습니다.

훈련소 밖으로 나와 정밀 검사를 받으니 현역에서 보충역으로 역종이 전환되었습니다. 하지만 보충역으로 복무하려고 보니 1년 이상을 기다려야만 했고, 복무 기간은 24개월로 너무 길었습니다. 결국 주사 시술과 재활 치료를 진행하며 또다시 현역으로 역종을 변경하였습니다. 그렇게 2016년 12월, 크리스마스 다음 날 공기가 가장 차가울 때 논산 훈련소로 입대하였습니다.

어쩌다 보니 논산 훈련소의 여름과 겨울을 모두 짧게나마 경험해보게 되었습니다. 둘 다 썩 유쾌한 경험은 아니었지만.. 그나마 겨울이 조금 더 나았던 것 같습니다. 여름엔 실외 샤워장에서 1분, 2분 안에 씻어야 했던 기억이 있네요. 😅

2017년: 재정비

군대에 있다 보니 시간이 정말 많았습니다. 과거와 현재, 그리고 미래를 생각해보기 시작했습니다.

나는 왜 개발을 하고 있는가? 지금 하고 있는 개발이 즐거운가? 앞으로도 계속할 수 있을 것 같은가?

첫 번째, 나는 왜 개발을 하고 있는가? 이 부분은 명확했습니다. 이거 말고는 해 본 적이 없었습니다. 그래서 그냥 하고 있었습니다.
두 번째, 지금 하고 있는 개발이 즐거운가? 모호했습니다. 즐거움의 기준이 뭘까?
세 번째, 앞으로도 계속할 수 있을 것 같은가? 단호하게 아니었습니다.

위 세 가지는 하루아침에 도출해낸 결론이 아니었습니다. 거의 3개월에 걸쳐했던 고민이었고 재정비가 필요한 순간이라는 결론을 내렸습니다. 그리고 그 방법은 개발 외에 다른 걸 해보자는 거였습니다. 그런데 무얼 해봐야 할지 알 수 없었습니다.

나름대로 기준을 세웠고, 해볼 만한 아이템을 도출했습니다. 그때의 기준은 '나의 미래에 도움이 될법하고, 개발과 전혀 상관없는 것'이었습니다. 그렇게 처음 선택한 아이템은 회계 공부였습니다. 정말 뜬금없지만, 나름 합리적이라고 생각했습니다.

하지만 시도해보고 한 달이 채 되지 않아 포기했습니다. 그 이유는 목표가 너무 막연했습니다. 회계를 공부해보자 -> 구체적으로 어떤 걸? 어떻게? 얼마나?라는 부분이 전혀 없었습니다. 그때 당시엔 CPA 응시를 위해 필요한 필수 과목에 대한 강의를 듣고, 공부해보자가 끝이었습니다. 그러다 보니 동기부여가 부족했고, 도전해볼 아이템을 바꾸었습니다.

그렇게 다음으로 선택한 아이템은 '공인중개사 시험 응시'였습니다. 아무래도 앞선 회계 공부에 비해 뚜렷하게 삼을만한 목표가 존재했고, 그 내용도 부동산 학개론, 민법, 부동산 중개 관련 공법 규정, 부동산 관련 세법 등으로 살면서 도움이 될법했습니다.

그렇게 인터넷 강의와 책을 구매해 공부를 시작하였고, 꽤 긴 시간 군 복무와 공인중개사 관련 학습을 병행하였습니다. 그리고 2017년 28회 공인중개사 시험에 응시하였습니다. 정말 다행히(?) 목표로 하던 응시를 넘어 시험에 합격할 수 있었습니다.

2018년: 결실

재정비 시간을 가지며 한 가지 깨달음을 얻었습니다. 바로 '나는 그래도 개발이다'였습니다. 공인중개사 공부 외에도 운동도 열심히 해보고, 글을 써보기도 하고, 사진을 취미로 가지며 여행 작가 흉내를 내보기도 하였는데 그래도 개발만큼 즐겁지 않았습니다.

이때를 기점으로 나는 개발이 즐거웠고, 단지 잠시 쉬어가고 싶었을 뿐이라는 결론을 내렸습니다. 그리고 앞으로도 개발을 계속하려면 어떻게 해야 할까? 라는걸 고민해보기 시작했습니다.

과거를 조금 더 돌이켜보았습니다. 나는 개발을 할 때 어떤 걸로 동기 부여하고, 즐거움을 얻었을까? 처음에는 돈이라고 생각했습니다. 하지만 내가 해왔던 것 중에선 돈을 전혀 받지 않고도 자발적으로 즐겁게 했던 개발도 존재했습니다. 그런데 그게 무엇인지 알 수 없었습니다.

그래서 무모한 도전을 해보게 됩니다. 모든 외주를 돈을 받지 않거나 최소(500원 ~ 1만원 수준)로 받으며 해보자는 생각을 하게 되었습니다. 그리고 조금 더 생각해보니 여태껏 독학 수준으로 공부하며, 직장을 다니며, 그리고 외주를 하며 다양한 사람을 만나보았지만 대학교에서 대학생 신분으로서 만날 수 있는 사람은 만나보지 못하였다는 사실을 깨달았습니다.

뜬금없긴 하지만, 대학을 가보고 싶어 졌습니다. 그런데 그 생각이 든 시점이 2018년 수시 접수 시작 이틀 전이었습니다. 여전히 군인 신분이었고요. 수능 공부는 당연히 하지 않았기 때문에 아래 세 가지 기준으로 대학을 선정하여 지원하게 됩니다.

고등학교를 졸업한 지 n년이 지났음에도 수시 전형 지원 가능한 곳
수시 전형을 통해 지원하는 경우 수능 최소 등급 기준이 없는 곳
집에서 가까운 곳

사실 이런 기준을 갖춘 곳은 많지 않았습니다. 그렇게 추려진 몇 곳에 지원하였고, 그 시점에 현역 -> 예비역으로 전역하게 되었습니다.

전역 이후 지원했던 몇 군데의 대학에 면접을 보았는데 모두 합격하였습니다. 그중 집에서 가장 가까웠던 대학에 입학 결정을 내리게 됩니다.

2019년: 새로운 환경

대학 신입생이 되었습니다. 모든 것이 새로웠습니다. 지난 몇 년간 만나보지 못한 유형의 사람들을 만나볼 수 있었습니다. 학생뿐 아니라 대학의 교수님, 총장님, 그리고 대학 본부의 직원분들을 많이 만나 뵈었습니다.

그리고 여전히 모든 외주를 돈을 받지 않거나 최소로 받으며 하고 있었습니다. 처음엔 C# 단일로만 진행했었는데, 시간이 지나며 Android, React, Node.js도 병행하게 되었습니다. 😅 2018년 중순부터 거의 1년 이상 돈을 거의 받지 않고 진행하다 보니, 어떤 것은 돈을 받아야 되고 어떤 것은 받지 않아도 할 수 있겠다는 어느 정도의 기준이 생기게 되었습니다.

점차 그 기준이 명확해졌고, '나와 친구, 가족, 그리고 대부분의 사람들이 공감할만한 사회 문제를 기술로 해결하는 것'은 돈을 받지 않아도 되겠다는 결론을 내렸습니다. 그 외의 것들은 다시 돈을 받기 시작했습니다.

그렇게 학교를 다니며 가끔씩 외주로 용돈벌이도 하고, 재미있는 사이드 프로젝트(위에서 말한 돈을 받지 않아도 될법한 일)를 여러 개 하기도 했습니다.

2020년: 더 많은 경험

그러던 2020년, 코로나19가 전국적으로 유행하기 시작했습니다. 이로 인해 개강 이전 마지막 방학 기간인 2월 즈음에 예정되어 있던 오프라인 해커톤이 취소되었습니다. 이때 당시 신천지 교회에서 시작된 대유행이 사회적으로 큰 이슈였는데.. 대회 장소가 이슈가 되었던 대구 소재의 신천지 교회 근처였기 때문에 다른 선택지가 없었던 게 아닐까 싶습니다.

원래 무박 2일로 진행되려던 해커톤이었는데, 이게 취소되어 그 시간이 붕 뜨게 되었습니다. 특별한 목적 없이 개발 커뮤니티를 이리저리 돌아다니던 중, '코로나19 관련 공공데이터 공동대응'을 함께 하자는 게시글을 보게 됩니다.

글을 읽어보니 코로나19와 관련된 몇 가지 사회문제를 기술적으로 해결해보고자 하는 사람들을 모집하고 있었습니다. 시간적 여유도 있었고, 재미있어 보였기 때문에 합류하게 되었습니다. 합류해보니 저를 포함해 20명이 조금 안 되는 인원이 있었고, 본격적으로 프로젝트를 추진하기 시작했습니다.

그렇게 진행된 프로젝트는 많은 수의 상을 받고, 언론에 노출되기도 하고, 코드포코리아라는 비영리 단체가 설립되는 등 큰 성과를 가져다주었습니다. 다만 그 과정은 꽤나 길었기에, 관련 링크를 첨부하는 것으로 대체하겠습니다.

그리고 2020년 하반기에는 새로운 기술 경험을 위한 도전도 해보게 됩니다. 기존에 경험해본 기술을 쭉 나열해보자면 정말 다양했습니다. VB 6.0, C#, C++(with Dx9, Windows API), PHP, Java-Android, C-Arduino, JavaScript-React, JavaScript-Node.js(Express.js), ...

여러 기술 경험을 통해 클라이언트 사이드 언어는 제 성향과는 맞지 않는다는 결론을 내리기도 했습니다. 무언가를 하려고 할 때마다 플랫폼의 주체에 의한 제한이나 한계가 너무 많았고 그게 썩 마음에 들지 않았습니다. 그래서 최근 2년 정도는 서버 사이드의 Javacript-Node.js(Express.js)를 주력으로 사용하고 있었습니다.

그리고 평소에 Node.js vs Spring Framework를 이야기하며 스프링은 '견고하다'라고 표현되는, 그 이유가 궁금했습니다. 기존에 Node.js로 개발해 운영 중이던 몇 가지 사이드 프로젝트를 스프링 부트로 바꿔보며 인프런에서 김영한님의 강의를 시청했습니다. 지금 생각해보면 정말 귀여운 질문을 남기기도 했었네요.

2021년: 확장

이 확장은 조금 복합적인 의미를 지니고 있습니다.

첫 번째로 프로젝트 경험의 확장입니다. 2020년에 어쩌다 시작하게 된 비영리 단체인 코드포코리아에서 다양하고 많은 수의 프로젝트를 진행하였습니다. 그중에서는 2020년 수준으로 큰 성과를 냈던 프로젝트도 존재했습니다. 정부에 재능 기부한 썰~ Feat. 코로나19 개인 안심번호

두 번째는 기술 경험의 확장이었습니다. 이것도 나름대로 순조로웠습니다. 특별한 어려움 없이 계획을 세워나가며 하고 싶은 공부를 마음껏 할 수 있었습니다.

그리고 대망의 세 번째는 직무 경험의 확장이었습니다. 조금 더 구체적으로는 회사에 소속된 웹 백엔드 엔지니어로서 할 수 있는 경험을 해보고 싶어 졌습니다. 그중에서도 특히 협업, 기술 전문성, 오너십 세 가지를 명확히 경험해보고 배워보고 싶었습니다.

이 생각을 했을 무렵이 2021년 2분기 즈음이었습니다. 곧바로 로켓펀치를 접속해 'Java', 'SpringBoot' 키워드로 채용 공고를 찾아보기 시작했습니다. 그리고 검색 결과 최상단에 노출되던 회사 한 곳과, 평소 관심 가지고 있던 '사진'과 관련된 제품을 만드는 곳, 전체 두 곳을 지원하였습니다.

검색 결과 최상단에 노출되던 회사는 홈페이지도 한번 접속해보지 않고 지원했던 회사였습니다. 그에 반해 사진과 관련된 제품을 만드는 곳은 그곳에서 만들고 있는 애플리케이션을 설치해보며 홈페이지도 많이 둘러본 뒤에 지원했었습니다.

본격적으로 두 회사의 채용 전형이 진행되었습니다. 검색 결과 최상단에 노출된 회사의 채용 전형은 매우 빨랐고, 사진 관련 제품을 만드는 스타트업의 1차 면접을 보기도 전에 처우 협상까지 모두 완료되었습니다.

그렇게 그 회사에 합류 결정을 내리게 되었고 정작 관심 가지던 회사에는 인터뷰 참석 포기 의사를 전달했습니다. 지금 생각해보면 정말 어리석은 행동이었습니다. 하지만 나름 변명하고 싶은 게 있습니다. 당시 저는 대구에 거주하고 있었고, 인터뷰를 보려면 서울로 올라와야만 했습니다. 그런 상황에서 처음 인터뷰 본 곳이 인터뷰를 통해 나름 괜찮은 곳이라는 시그널을 받을 수 있었고, 합격 시그널과 오퍼 레터를 빠르게 전달해주니 굳이 피곤한 과정을 또 경험하고 싶지 않았습니다.

그렇게 2021년 6월, 그 회사로 출근을 하게 되었습니다.

그리고 예상하셨을 수도 있겠지만, 정말 빠르게 재직 5개월 시점에 퇴사를 결정하게 됩니다. 회사에 불만이 있었던 것은 아닙니다.

다만, 제가 회사에서 일을 시작하게 된 이유가 불순했었기 때문이었습니다. 직무 경험을 확장하고 싶었던 가장 큰 이유는 밖에서 하는 것들(비영리 단체 활동이나 사이드 프로젝트)을 조금 더 잘해보기 위한 무언가를 회사에서 얻어가고 싶었기 때문이었습니다.

초기 스타트업에 합류하는 입장에서는 바람직하지 못한 마음가짐이었습니다.

그래서 이번에는 정말 내가 함께 하고 싶은 회사를 가보자는 생각에 많은 회사를 찾아보고, 지인에게 물어보기도 하며 몇 군데를 추려 지원하였습니다.

그렇게 지원하고, 인터뷰를 진행하며 오퍼를 받은 몇 개의 회사 중 채용 프로세스가 정말 독특했던 회사가 있었습니다.

그 회사는 50여 명 규모에 곧 시리즈 B를 클로징 하는 라운드에 있었음에도 서류 제출 -> 서류 합격 -> 인터뷰 일정 조율 -> 인터뷰 -> 최종 합격 -> 처우 협상까지의 과정이 24시간 안에 이루어졌었습니다.

특히 인터뷰는 대표님의 회사 설명(비즈니스 모델, 자금 계획, 인력 상황 등) 이후 개발팀 인터뷰, 대표님 인터뷰 순서로 진행되었는데 그 현장에서 곧장 의사 결정하여 최종 합격 통보를 주셨던 부분이 인상 깊었습니다. 자연스레 처우 협상도 그 자리에서 진행되었고, 다른 곳에서 받은 오퍼보다 높은 수준의 급여와 사이닝 보너스, 그리고 스톡 옵션까지 제시해주셨습니다.

더불어 대표님의 모든 말과 행동에서 확신이 느껴졌고, 사업 또한 순조로울 것 같다는 생각이 들었습니다. 그래서 이 회사로의 합류를 긍정적으로 고민해보고 있었습니다.

그러던 중, 현 회사에 먼저 재직 중이시던 지인분께서 '우리 회사에도 지원해봐라'라는 이야기를 해주셨습니다.

하지만 그때 당시 저는 대기업에 관심도 없었고, 무엇보다 이번에는 해보고 싶은 일을 할 수 있는 곳으로 가보고 싶었습니다. 그래서 거절은 했지만, 내심 한 번쯤 도전은 해볼까?라는 생각이 들기도 했던 것 같습니다.

그렇게 지인 몰래 수시 채용 전형에 지원했습니다. 몰래 지원했던 이유는 두 가지였습니다. 1) 자격 요건에 미달하였기에 불합격할 것으로 예상되는데, 괜히 민폐를 끼치는 것 같았습니다. 2) 사내 추천을 받으면 서류 전형이 100% 통과라는데, 그러고 싶진 않았습니다.

그런데 서류 전형에 합격하였고, 자연스럽게 과제 전형까지 진행하게 되었습니다. 다만 과제 전형 합격 이후 인터뷰 일정 조율 과정에서는 전형이 너무 길어질 것으로 보여, 이후 채용 프로세스 불참 의사를 밝혔고 전형 포기로 처리되는 등 해프닝이 있기도 했었습니다.

물론 1시간 뒤 즈음 다른 채용 담당자분에게 전화가 와서 인터뷰 일정을 다음 주 월요일로 조율 + 당일 합격 통보를 해주겠다고 말씀해주셔서 인터뷰를 보게 되었습니다. (이때가 금요일이었으니 정말 파격적이었습니다.)

우여곡절 끝에 현 회사에 최종 합격을 하고, 많은 고민 끝에 결국 합류를 결정하였습니다. 엔지니어라면 스타트업과 대기업 모두 경험해봐야 한다.라는 말이 흔했고, '한 번쯤 경험해보자'라는 생각이었습니다. 이전 회사와 마찬가지로 의도가 조금은 불순했던 것 같기도 합니다.

다만, 합류하고 나서 보니 눈앞에는 정말 새로운 세계가 펼쳐져 있었습니다.

2022년: 새로운 세계

괜히 대기업이 아니었습니다. 2014년 카카오 내에서 3명 규모의 작은 팀으로 시작한 회사는 2017년 60여 명으로 분사하였고, 현시점에서는 1100명을 바라보는 규모가 되었습니다. 그 과정에서 있었던 사업적, 기술적 의사 결정 과정과 다양한 히스토리가 내부에 아카이브 되어 있었고 그 내용은 정말 대단했습니다.

그리고 단순히 회사의 성장만을 위해 달리는 것이 아닌, 내부 구성원을 케어하기 위한 다양한 노력과 제도까지 함께 갖추며 달려 나가는 모습이 너무 신기했습니다.

무엇보다 제가 소속된 팀 자체가 너무 좋았습니다. 좋다는 것은 매우 추상적인 표현입니다만, 그 이유를 조금 구체적으로 생각해보자면 크게 두 가지 이유였습니다.

팀 모두가 각자의 Role에 따라 전문성을 갖고 있음이 느껴졌다.
단순히 회사/팀 차원의 프로덕트를 개발하는 것에서 그치지 않고 구성원의 커리어 패스와 동기부여에 관심 갖고 있다.

사실 첫 번째 이유는 당연한 내용입니다. 회사에 소속되어 일을 한다면 맡은 직무에 대해 전문성을 뗘야 하니까요. 그렇기에 두 번째 이유가 좋은 팀과 함께한다는 생각을 할 수 있게 해 준 결정적인 이유였습니다.

수많은 주니어 레벨의 구성원들은 '더 가치 있는 사람이 되어야겠다'라는 욕구를 지니고 있기 마련입니다.

하지만 막상 욕구를 실현하려 하더라도, 어떻게 해야 할지 알기 어렵습니다. 학교나 학원에서는 이런 것들을 알려주지 않으니까요.

만약 회사에서 문제를 해결해 나가는 과정 속에서 어려움을 겪는다면 어떻게 해야 할까요?
내가 현재 프로젝트에 동기 부여되지 않는다면 어떻게 해야 좋을까요?

개인적으로 이런 것들은 회사에서, 그리고 팀에서 챙겨줄 필요가 있다고 생각합니다. 제가 합류하게 된 조직, 특히 조직장님은 이런 부분에 많은 관심을 가지고 계시며 매우 적극적이셨습니다. 조직 외에도 회사 전반적으로 개인 기여자들의 성장을 지원해주려는 노력이 있었고, 이런 글을 쓸 기회도 얻을 수 있었습니다. 오픈소스 활동 이야기 - 카카오페이

물론 아쉬운 부분도 있었습니다. 조직에 대한 아쉬움보다는 대기업이라는 것에서 오는 아쉬움이었습니다. 아무래도 R&R이 명확해진 만큼 해볼 수 있는 경험의 범위에 한계가 있었습니다. 저는 그래서 개발 커뮤니티를 시작했습니다.

내가 개발 커뮤니티를 하는 이유

취미로 개발을 시작하고 현재까지 12년이 흘렀고, 곧 13년이 됩니다. 하지만 전체를 보았을 때 그 기간을 잘 사용하지는 못했습니다.

첫 9년은 개발 생태계에서 보고 듣기만 하는 리스너였으며,
이후 1년은 생태계에 조금씩 의견을 내보았으며,
최근 2년은 개발 생태계를 직접 만들어 보고자 했습니다.

이 중에서 가장 많은 걸 배우고 성장했다고 생각하는 시기는 최근 2년이었습니다. 앞선 10년간 이런저런 실패와 포기를 해보며 나름대로의 기준과 관점을 만들어나간 것이 도움이 된 것 같기도 하지만, 10년이란 시간은 너무 길었습니다.

그래서 다른 사람들은 이 정도의 시행착오는 하지 않았으면 했습니다.
제 경험을 타인과 나누고 싶었습니다.
제가 먼저 겪은 시행착오와 지금 새롭게 배우는 것들을 바탕으로 더 나은 개발 생태계를 만들어나가고 싶었습니다.
그렇게 만들어진 더 나은 개발 생태계 속에서 살아가고 싶었습니다.

물론 일방적으로 제 경험을 공유하기만 했다면 지속하지 못했을 것입니다. 커뮤니티 활동을 통해 평소에 생각해보지 못한 관점으로 문제를 접근하는 사례를 간접적으로 경험해볼 수 있었고, 제 생각과 관점을 타인에게 공유하며 피드백받는 그 사이클 자체가 저에게는 큰 가치였습니다.

평소 자주 함께 학습하고, 경험을 공유하던 10여 명의 사람들과 2022년 2월 즈음 만들게 된 기술 경험 공유 네트워크는 어느덧 100명을 넘어 200명 중반을 향해 달려가고 있습니다. 자연스럽게 검색을 통해 유입된 경우도 있었지만, 여러 경로를 통해 만나 뵙게 된 개발자분들을 하나둘 영업한 결과이기도 했습니다. 올 한 해는 100% 온라인으로 운영되었지만, 내년에는 기회가 된다면 오프라인으로 기술 경험을 공유할 수 있는 자리를 마련해보고 싶은 욕심이 생기기도 합니다.

혹시 관심 있는 분이 계시다면 함께해요! 🙂

홈페이지 -> https://weekly.ac
GitHub Organization 가입 -> https://github.com/weekly-academy/members
오픈 채팅방(비밀번호: 9323) -> https://open.kakao.com/o/gyvuT5Yd

그리고 최근에는 회사와 팀도 결국 하나의 네트워크이고, 하나의 커뮤니티라는 것을 깨달았습니다. 그래서 마음 맞는 조직에서 구성원 각자의 경험을 공유하고, 피드백을 주고받으며 회사, 팀, 그리고 구성원 모두 함께 성장할 수 있는 '상황 학습을 실현할 수 있는 조직'을 만들고 싶다는 욕심이 생겼습니다.

상황 학습은 구성주의 교육철학에 바탕을 둔 학습 이론입니다. 구성주의의 기본 가정은 다음과 같습니다.

'학습은 학습자의 경험에 기초하여 학습자의 머릿속에 구성되는 것'이다.

따라서 구성주의에서 말하는 학습은 현실과 유사한 맥락에서 이루어질 때, 실제로 활용할 수 있는 지식을 습득하는 것이라 볼 수 있습니다.

여기서 지식은 절대 정형화되고 정체되는 것이 아니라 개개인이 자신의 사회적, 역사적, 문화적 상황을 바탕으로 구성해나간다는 것을 유의하여야 합니다. 즉, 지식이란 상황적인 것이고 그 지식이 사용될 과제, 맥락, 문화 안에서 생성되는 것이지 결코 단독적으로 존재하는 것이 아니라는 것입니다. 따라서 실제와 유사한 상황에서 이루어지는 학습이야 말로 유의미한 학습이라 말할 수 있습니다.

모든 사람은 정체하기보다는 배우고 성장하기를 갈망합니다. 새로운 기술이나 이론을 배울 때 대부분의 경우 글로 읽는 것에서 그치거나 간단한 예제로 이해하고 넘어가게 됩니다. 하지만 그것으로 충분할까요?

당연히 아닙니다. 단순히 이론으로 이해하고 넘어가기보다는 내게 주어진 문제를 해결하기 위해 학습한 이론을 적용하거나, 고민하는 과정을 거치면 더 많은 것을 배울 수 있게 됩니다. 많은 분들이 공감할 것입니다.

물론 무조건 새로운 기술과 이론을 적용하는 것이 좋다는 것은 절대 아닙니다. 다만 문제 해결을 위한 다양한 방법을 접해보고, 그것을 주변에 있는 동료 혹은 친구와 함께 고민해보는 것이 정말 중요하다는 의미입니다.

아무리 혼자 고민해봐야 분명 한계가 있습니다. 저는 구성원들이 각자의 목표를 이루기 위해 고민하는 과정을 함께 할 수 있는, 그런 조직을 만들어가고 싶습니다.

다시 생각해보면 지금 개발 커뮤니티를 하는 이유가 이런 상황이 갖춰졌을 때 더 잘해보고 싶어서 인 것 같기도 합니다.

물론 몇 년이 걸릴지는 모르겠지만요. 😅 (대략 아래 같은 모습을 꿈꾸는 것 같기도 합니다.)

Google Calendar API 분석 및 시스템 구축 전략

Sun, 20 Nov 2022 05:14:27 GMT

들어서며

구글 캘린더는 전 세계적으로 널리 사용되는 캘린더 애플리케이션입니다. 그러다 보니 캘린더를 읽고 새로운 이벤트를 작성하는 데 이용할 수 있는 RESTful API인 Google Calendar API가 함께 제공되고 있습니다.

이번 글에서는 이러한 구글 캘린더 API의 주요 기능을 이해해보고, 관련된 시스템을 구축한다고 하였을 때 도움 될 만한 몇 가지 전략을 공유합니다.

유즈케이스

모든 팀원이 공통으로 가능한 시간을 찾아 회의 시간 후보를 제안하는 가상의 애플리케이션을 만든다고 생각해보겠습니다. 그러기 위해서는 모든 팀원이 각자의 구글 계정으로 로그인(OAuth)하고, 캘린더와 관련된 정보를 애플리케이션에 제공하겠다는 동의를 해야 합니다.

그 후에는 회의 시간 후보를 추천 받고 싶을 때마다 버튼을 누르는 등 명령을 실행하여 애플리케이션에 요청을 보내게 될 것이고, 그 요청을 받은 애플리케이션은 연결된 구글 계정의 모든 캘린더 이벤트를 불러와 비어있는 시간을 찾는 과정을 거치게 됩니다.

List Calendars & Events API

이러한 유즈케이스를 실제로 적용하기 위해서는 캘린더의 목록을 조회하고, 해당 캘린더에 등록된 이벤트를 조회하거나 새롭게 추가하는 등 몇 가지 구글 캘린더 API를 사용해야만 합니다. 이를 조금 더 자세히 알아보겠습니다.

CalendarList: list

https://developers.google.com/calendar/api/v3/reference/calendarList/list

캘린더 리스트 조회 API

캘린더 리스트 조회 API는 단순히 Authorization 헤더에 인증 토큰을 넘겨 해당 계정에 등록된 캘린더의 목록을 조회하는 API입니다. 이를 통해 캘린더의 ID와 같은 정보를 얻어올 수 있으며, 캘린더 ID는 각 캘린더를 고유하게 식별하는 ID로 사용됩니다.

Events: list

https://developers.google.com/calendar/api/v3/reference/events/list

이벤트 리스트 조회 API는 앞서 얻은 캘린더 ID를 이용해 해당 캘린더에 등록된 이벤트의 목록을 조회하는 API입니다. 2022년 11월 25일 19:00~21:00 <저녁 약속 & 네트워킹 파티> 같은 각 일정 정보를 이벤트라 부릅니다.

Strategy #1. Fetch every time

우리의 유즈케이스를 구현하는 방법은 정말 단순해 보입니다. 사용자가 요청할 때마다 팀원들의 모든 구글 캘린더를 조회하고, 그 캘린더의 이벤트를 모두 가져온 뒤 공통으로 빈 시간을 찾으면 될 것 같습니다. 하지만 이 방법에는 정말 큰 문제가 존재합니다.

4개의 캘린더, 전체 49개의 이벤트를 얻어오는데 소요되는 시간

캘린더 목록을 가져오고, 이벤트를 얻어오는 API가 아주 느리다는 부분입니다. 아무런 최적화 옵션이 없는 경우 각 캘린더의 이벤트 목록을 조회해오는데 500ms~1,000ms가 소요되며 gzip이나 optional field 같은 최적화 옵션을 적용하더라도 엄청나게 성능이 최적화되지는 않습니다.

그나마 각 API 요청에서 발생하는 네트워크 I/O를 Nonblocking I/O로 풀어낸다면 약간의 성능상 이점을 얻을 수 있습니다. 하지만 서비스의 사용자가 요청할 때마다 구글 캘린더 API를 호출해야 하므로 부하가 심하다는 단점이 존재합니다.

Strategy #2. Fetch every cycle

앞선 방법의 문제는 사용자가 요청할 때마다 외부 API를 호출해야 하는데, 그 속도가 느리고 그때마다 네트워크 통신 비용이 발생한다는 데 있었습니다. 그렇다면 어떻게 개선해 볼 수 있을까요? 단순하게는 시스템이 백그라운드에서 주기적으로 캘린더 정보를 가져오고, 준실시간 수준으로 이벤트 정보를 갱신하는 방법이 있을 것 같습니다.

예를 들어, 5분마다 서비스에 등록된 모든 구글 계정의 모든 캘린더의 이벤트 정보를 받아오는 방법입니다.

음..🤔 벌써 불안합니다. 서비스에 1억 개의 구글 계정이 등록되어 있다면 어떻게 될까요? 5분 안에 모든 이벤트 정보를 가져올 수 있을까요? 5분마다 네트워크 통신 비용을 지불해야 하는 걸까요? 만약 5분 안에 모든 이벤트 정보를 가져올 수 있고, 네트워크 통신 비용도 지불할 수 있다면 모든 문제가 해결되는 걸까요?

그렇지 않습니다. 사용자 입장에서 생각해보겠습니다. 이 구조에서는 구글 캘린더에서 일정 정보가 변경되었음에도 서비스는 아직 그 정보를 알지 못하는 상황이 발생할 수 있습니다. 그렇게 한번 오차가 발생하고, 오차가 누적되다 보면 사용자는 결국 서비스를 이탈하게 될 것입니다.

Strategy #3. Fetch every time with Sync Token

https://developers.google.com/calendar/api/guides/sync?hl=en

그럼 다시 매 요청마다 이벤트 정보를 가져오는 방법으로 돌아가 API 호출이 왜 오래 걸리는지 생각해보겠습니다. 일반적으로 API 호출이 오래걸리는 것은 네트워크가 느려서 일수도 있지만, 한번에 탐색하는 데이터의 양이 너무 많아서 그런 경우가 많습니다. 그리고 API Reference를 조금 더 자세히 살펴보면 syncToken이라는 필드가 존재하고 있음을 확인할 수 있습니다.

이벤트 리스트 조회 API syncToken 필드

이는 마지막으로 Sync한 시점으로부터 발생한 변경사항만 탐색하는 방법이라고 합니다.

그래서 이를 적용해보았는데..... 생각보다 엄청나게 빨라지지는 않았습니다. 또한 결국에는 일정주기로 전체 탐색을 해야하는 구조로 되어 있어, 앞서 존재했던 매 요청마다 사용자가 대기해야한다는 문제는 근본적으로 해결할 수 없었습니다.

Strategy #4. Get push notifications

https://developers.google.com/calendar/api/guides/push?hl=en

Get push notifications watch example

구글 캘린더 API는 사용자에 의해 트리거 되는 RESTful API 외에도 변경이 발생할 때마다 웹훅 형태로 변경 사항을 알려주는 기능이 제공되고 있습니다. 이 방법을 이용한다면 사용자가 요청할 때마다 이벤트를 얻어오는 것이 아니라 변경이 발생하는 즉시 사용자 캘린더 정보를 갱신할 수 있게 됩니다.

하지만 한 가지 걱정되는 부분이 있었습니다. 변경 사항이 우리에게 정상 수신되었다는 걸 어떻게 보장할 수 있는가?라는 부분입니다. 구글 측의 이슈, 혹은 구글과 우리 서비스 사이의 네트워크 이슈 등등 다양한 변수가 존재하기 때문에 100% 보장할 수는 없습니다.

그래서 구글은 웹훅 수신 서버가 웹훅 수신 후 200, 201, 202, 204 또는 102 상태 코드를 응답하는 경우 정상 처리되었다고 판단(ack)하며 500, 502, 503 또는 504 상태 코드를 응답하는 경우 재시도하는 지수 백오프(Expotential Backoff) 기능을 함께 제공하고 있습니다. 그렇기에 일반적인 서버 처리 오류나 Request Timeout 같은 상황에서도 요청 수신을 어느 정도 보장할 수 있습니다.

마무리

앞선 분석을 정리해보자면 결국 사용자의 대기를 최소화하고, 최대한 빠르게 데이터를 갱신하기 위해선 Strategy #4. Get push notifications 방식의 적용이 필수로 보입니다. 하지만 섹션의 마지막 문단에서 언급했듯 데이터의 동기화를 어느 정도 보장할 수 있을 뿐, 여러 변수로 인해 이를 100% 신뢰하는 것은 무리가 있습니다.

그렇기 때문에 베이스로는 변경 사항을 웹 훅으로 수신하며 사용자 일정 정보를 갱신하고 긴 주기 혹은 웹훅을 정상적으로 수신하지 못할 것으로 예상되는 시점에 일정 정보를 일괄로 받아오는 구조를 채택하는 것이 바람직합니다. 일괄로 받아올 때는 SyncToken을 활용한다면 조금 더 효과적일 것입니다.

Webhooks(웹훅) 시스템 체크리스트

Sat, 12 Nov 2022 03:10:32 GMT

들어서며

최근 Webhooks 시스템을 구성하기 위해 필요한 요소를 짤막하게 고민해볼 기회가 생겨, 그때 고민해본 내용을 공유해보고자 합니다.

많은 분들이 웹훅 시스템을 구성한다고 하면 애플리케이션 시스템 아키텍처보다는 인프라 측면의 보안적인 요소에 많은 관심을 가지실 것입니다. 그래서 이번 게시글도 보안에 대한 부분을 메인으로 다루어보겠습니다.

보안과 관련된 내용은 기존 경험에 의한 생각, 웹훅 서비스를 제공하고 있는 서비스 벤치마킹 그리고 네이버와 센드버드에서 보안 업종에 종사하고 있으신 분에게 조언받아 작성하였습니다. 🙂

시스템 체크리스트(보안)

1. 통신 암호화

100% 신뢰할 수 있으며 통제할 수 있는 내부 시스템이 아닌 이상 통신 암호화는 필수요소라고 말할 수 있습니다. HTTP 통신을 한다면 HTTPS는 필수입니다. 벤치마킹해보니 일부 웹훅 서비스는 수신 측에서 HTTPS가 아니라면 웹훅 자체를 발송해주지 않는 서비스도 존재하고 있었습니다.

2. 데이터 서명

데이터 서명의 경우 하면 좋은데, 수신 측과 발신 측 모두 약간의 번거로움이 생길 수 있는 기능입니다. 하지만 그와 동시에 이상적 시스템을 위해선 꼭 적용해야 하는 부분이기도 합니다.

막상 데이터 서명 기능을 제공하더라도 사용자에 따라 서명을 귀찮아하거나 검증을 위한 컴퓨팅 리소스 할애 등을 이유로 평문으로 데이터를 전달 받기 원하는 경우가 있을 수도 있습니다. 이 부분은 시스템을 구성하는 데 있어 고려해볼 만한 부분인 것 같습니다.

만약 데이터 서명을 선택적 기능으로 제공한다면 '기능은 제공하지만, 사용자가 안전하게 사용하지 않는 것'이라는 책임 회피/전가 즉, Shared Responsibility 구조를 가지게 됩니다. 이는 많은 소프트웨어와 정책, 사업 등에서 채택하고 있는 방법이고 웹훅을 정말 적극적으로 제공하는 깃헙 또한 데이터 서명을 선택적 기능으로 제공하고 있습니다.

https://docs.github.com/en/developers/webhooks-and-events/webhooks/securing-your-webhooks

3. 신뢰할 수 있는 발신처 제공

웹훅을 수신하는 입장에서 생각해볼 때, 우리가 수신한 웹훅이 정말 신뢰할 수 있는 시스템이 보낸 제대로 된 데이터일까? 라는 부분은 정말 중요한 요소입니다. 통신을 암호화하고, 데이터를 서명하였더라도 그때 사용하는 인증서나 키가 노출된다면 무용지물입니다.

'웹훅을 보낸 발신처를 신뢰할 수 있는가?'를 판단할 수 있는 가장 대표적 지표는 웹훅을 발신한 시스템이 '누구'인가입니다. 그렇다면 '누구'는 어떻게 식별할 수 있을까요? 방법은 L7에서 확인하거나 L3에서 확인하는 등 다양하겠지만, 가장 쉽고 널리 사용되는 방법은 웹훅 발신 시스템의 IP를 우리 네트워크에 화이트 리스트로 등록하여 L3에서 발신처를 검증하는 방식입니다.

4. 수신처의 제한

웹훅을 발신하는 입장에서 고민해보아야 하는 부분도 존재합니다. 일반적으로 외부에서 알기는 어렵겠지만 만약 내부에서만 호출 가능한 내부 서버(서버 애플리케이션, nginx, redis 등) 킬 스위치 같은 API가 있다면, 사용자가 웹훅 대상 URL을 해당 킬 스위치 API로 지정하였을 때 문제가 발생할 수 있습니다. 서버 자체를 킬 하는 스위치가 아니더라도 액츄에이터 재시작 엔드포인트정도는 쉽게 유추할 수 있기 때문에 유의해야만 합니다.

이런 부분을 방지하기 위해선 웹훅을 발송할 때 수신측이 내부망 대역의 IP라면 발송하지 않게끔 해야하며, 30x 리디렉션의 목적지가 내부망이라면 무시하는 등의 보안 조치가 필요합니다.

마무리

보안 측면의 체크리스트를 정리해보자면 결국 모든 통신은 신뢰할 수 있어야 한다는 것으로 귀결됩니다. 이는 수신 측 웹훅 URL은 어떠한 경로로든 외부에 노출될 가능성(내부 직원의 실수, 웹훅 발신 시스템 해킹 등)이 존재한다는 것을 전제로 하고 있기도 합니다.

만약 HTTPS 통신을 하고 있으며, 신뢰할 수 있는 웹훅 발신 시스템의 IP만 허용했다면 100% 안전한 시스템일까요? 그렇지 않습니다. 웹훅 발신 시스템이 해킹당하여 해커가 curl을 이용해 여러 수신처에게 요청을 보낸다면 어떻게 될까요? 웹훅을 수신한 시스템들은 '신뢰할 수 있는 시스템'의 요청이기 때문에 이를 신뢰하게 됩니다.

만약 데이터를 서명했다면 서명에 사용되는 키가 유실되지 않는 이상 문제가 발생할 가능성을 줄일 수 있습니다.

보안 조치라는건 결국 시스템이 취약해질 가능성을 줄이는 행위입니다. 그렇기에 우리는 항상 그 가능성을 줄이기 위해 노력하고 있는게 아닐까 싶습니다.

Why DDD, Clean Architecture and Hexagonal?

Thu, 10 Mar 2022 03:06:18 GMT

어느 순간부터 소프트웨어 개발 세계에서는 도메인 주도 설계, 클린 아키텍처라는 용어가 사용 되기 시작했습니다. 이것들은 도대체 어떤 것이며, 왜 등장하게 됐을까요?

도메인 주도 설계(Domain-Driven Design)

소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다

DDD와 객체지향

도메인 주도 설계를 보다 잘 이해하고 적용하기 위해선 객체지향에 대한 이해가 필요합니다. 객체지향의 본질과 핵심은 뭘까요? 저는 객체 그 자체라고 생각합니다. 객체지향이라는 것은 결국 각 객체간 역할을 명확히 가져가고, 각 객체간에 메시지를 주고 받는 형태의 프로그래밍 방법론이라 생각하기 때문인데요.

그렇다면 객체지향 프로그래밍에서 사용되는 이 객체들은 어떻게 추려낼 수 있을까요? 이 객체가 필요한지 어떻게 알 수 있을까요? 어떻게 하면 이 객체들이 서로 상호작용할 수 있을까요?

여러 방법이 있을 수 있겠지만, 이를 해결해줄 수 있는 것이 도메인 주도 설계입니다.

Focus on Domain

여기서 도메인은 실세계에서 발생할 수 있는 사건 그 자체라고 생각하면 쉽습니다. 간편결제 서비스를 예로 들어볼까요?

서비스에서 사용되는 포인트를 충전하기 위한 충전 도메인(Charge Domain)이 있을 수 있고, 이렇게 충전된 포인트로 결제를 수행하는 결제 도메인(Payment Domain)이 있을 수 있습니다. 그리고 각 도메인에는 이를 구현하기 위한 여러 객체가 필요하게됩니다.

충전 도메인: 포인트, 고객, 충전 수단, ...
결제 도메인: 포인트, 고객, 결제 상품, ...

잘 보면 서로 다른 도메인이지만 같은 객체(포인트, 고객)가 존재하는데요. 이는 같은 객체가 여러 개 존재할 수 있다는 도메인 주도 설계의 특징 중 하나입니다. 같은 객체이지만, 그 객체가 속한 도메인의 문맥(Context)에 따라 각 객체의 역할과 책임이 크게 바뀌게 되는 것이지요.

그래서 이러한 객체들은 외부로 노출시키지 않고, 내부에서만 알 수 있게 합니다. 다른 도메인에서는 알 필요가 없으니까요.

즉, 이는 서로 다른 도메인 영역에 영향을 끼치기 위해서는 API를 이용해야 한다는 말이기도 한데요. 이를 통해 각각의 도메인은 서로 철저히 분리되고, 높은 응집력과 낮은 결합도로 변경과 확장에 용이한 구조를 얻게됩니다.

그리고 DDD를 실제로 구현할 때에는 크게 3가지 Layer로 구분하는 것이 핵심입니다.

Application Layer: 주로 도메인과 Repository를 바탕으로 실제 서비스(API)를 제공하는 계층
Domain Model Layer: Entity를 활용해 도메인 로직(비즈니스 로직)이 수행되는 계층
Infrastructure Layer: 외부와 통신(RDBMS, Redis, HttpClient, ...)을 담당하는 계층

결국 각 도메인을 분리하고, 그 도메인을 위와 같은 Layer로 철저히 분리해서 만드는 것이 DDD라 볼 수 있습니다.

Introduce Clean Architecture

Clean Architecture는 Robert C Martin(Uncle Bob)이 블로그에 기재하면서 화제가 되었었는데요.

Clean Architecture에 대해서 이해하기 위해선 두 가지 개념을 이해하고 있어야 합니다.

Business Rule
System Architecture

What is Business Rule?

Business Rule(Logic)은 컴퓨터 프로그램에서 데이터를 생성, 표시, 저장, 변경하는 부분을 일컫습니다. (=domain logic)

Business Rule(Logic)은 유저의 입력(UI)과 DB 사이에서 발생한 정보 교환을 위한 특정 알고리즘이나 규칙이 정의된 tier를 의미합니다.

이러한 Rule(Logic)은 고객의 요구에 따라 변경될 수 있기 때문에 별도의 tier에 배치되어야 합니다. 만약 다른 역할을 하는 tier와 함께 존재한다면, 고객의 요구에 따라 변경해야하는 부분이 많아질 수 밖에 없기 때문입니다.

What is System Architecture?

System Architecture는 시스템의 구조(structure), 행위(behavior), 뷰(views)를 정의하는 개념적인 모델입니다.

즉, 시스템의 목적을 달성하기 위해 각 컴포넌트가 어떻게 상호작용하고 정보가 어떻게 교환되는 지를 정의하고 있습니다.

세상에는 정말 다양한 시스템 아키텍처들이 나왔지만 결국 그들의 목적은 하나로 귀결됩니다.

관심사의 분리

소프트웨어를 계층으로 나누게 되면 관심사를 분리할 수 있습니다. 그리고 관심사 분리에 목적을 가진 시스템 아키텍처는 최종적으로 다음과 같은 구조를 지니게 됩니다.

프레임워크 독립적
- 라이브러리 존재 여부나 프레임워크에 한정적이지 않아 도구로써 사용하는 것이 가능합니다
테스트 용이
- Business Rule은 UI, DB, Web Server 등 기타 외부 요인과 관계없이 테스트 가능합니다
UI 독립적
- 시스템의 다른 부분을 고려하지 않고 UI를 변경할 수 있습니다
Database 독립적
- Business Rule에 얽매이지 않고 Database를 독립적으로 변경할 수 있습니다(SQL, Mongo, CouchDB 등)
외부 기능 독립적
- Business Rule은 외부 상황(DB, UI)이 변하더라도 영향을 받지 않습니다

Uncle Bob은 이러한 특징을 가지는 Architecture 들에 대한 총 정리로 Clean Architecture를 내세운 것인데요.

Overall Clean Architecture

먼저 간단한 그림부터 살펴보겠습니다.

Domain

Domain Layer는 Business Rule이 존재하는 영역입니다. 번역앱은 번역을 하고, 결제 앱은 결제를 수행합니다. 이렇듯 비즈니스의 본질은 쉽게 바뀌지 않으므로 Business Rule은 잘 변하지 않는 안정된 영역입니다.

Infrastructure

Infrastructure Layer는 UI, Database, Web APIs, Frameworks 등이 존재하는 영역입니다. 이는 Domain에 비하여 자주, 쉽게 바뀔 수 있습니다. 예를 들어 다른 사용자에게 송금을 한다고 가정해봅시다. 송금을 위한 버튼의 형태는 쉽게 바뀔 수 있지만 송금 방법 (Business Rule)은 그렇지 않습니다.

Uncle Bob은 이렇게 경계를 두어 각 Layer를 분리하고, 관심사를 분리하는 규칙을 의존성 규칙(Dependency Rule)으로 설명했습니다.

Dependency Rule

모든 소스코드 의존성은 반드시 outer에서 inner로, 고수준 정책을 향해야 한다

Dependency Rule은 Business Logic을 담당하는 코드들이 DB 또는 Web 같이 구체적인 세부사항에 의존하지 않고 독립적으로 실행되어야 한다는 규칙입니다.

다시 이 그림으로 돌아와보겠습니다.

Dependency Rule에 따르면 inner circle에 해당하는 Domain은 outer circle에 해당하는 Infrastructure에 대해서 아무것도 모릅니다. 이는 UI, DB는 Business Rule에 의존하지만 Business Rule은 그렇지 않다는 것을 의미합니다.

UI가 웹이건 모바일이건, DB가 SQL이건 NoSQL이건 Business Rule 입장에선 아무런 관계가 없습니다.

The Clean Architecture

위의 그림을 더 자세히 들여다 보겠습니다.

Domain이 Entities, Use Cases로 세분화 되었고, Adapter가 새로 생겨 Domain과 Infrastructure 사이의 경계를 관리합니다.

이 그림 또한 마찬가지로 Dependency Rule에 따라 동작하여 outer에서 inner로 의존성을 가지게 됩니다.

Entity

Entity는 애플리케이션에서 핵심적인 기능인 Business Rule을 담고 있습니다.

다른 사람에게 돈을 보내는데, 같은 은행으로 보내면 수수료가 면제된다고 가정해 보겠습니다. 모바일 앱에서 돈을 보내던 PC 웹에서 돈을 보내던 같은 은행으로 보내면 수수료가 면제된다는 사실은 변하지 않습니다.

같은 은행이면 수수료가 면제된다는 규칙(Business Rule)은 외부 상황(outer layer)을 전혀 모릅니다.

즉, Entity들은 outer layer들에 속한 다른 class나 component들을 전혀 모르고 신경쓰지 않아도 됩니다.

Use Cases

Use Cases는 특정 application에 대한 Business Rule입니다. Use Cases는 시스템이 어떻게 자동화 될 것인지에 대해 정의하고 application의 행위를 결정합니다. 다시 말해, 프로젝트 레벨의 Business Rules(Entities)을 사용하여 Use cases의 목적을 달성합니다.

계좌 송금을 하기 위한 Use cases의 예시는 다음과 같습니다.

[계좌 송금]

입력: 수취인 계좌번호, 수취인 은행, 송금 금액
출력: 송금 성공 여부
적용되는 Business Rule
- 계좌번호의 양식은 유효해야 한다
- 해당 계좌가 돈을 수취할 수 있는 유효한 상태여야 한다
- 송금 금액은 1회에 1천만원까지만 허용된다
- ....

Use Cases는 Entities에 의존하는 동시에 상호작용합니다. 물론 outer layer에 대해서는 아는게 없습니다. 다만 이 계층에서는 outer layer에서 사용할 수 있는 abstract class나 interface를 정의합니다.

Adapters

Adapters는 domain과 interfaces 사이의 번역기 역할을 수행합니다.

예를 들어 GUI로부터 input data를 받아 Use cases와 Entities 에게 편리한 형태로 repackage 하고, Use cases와 Entities의 output을 가져와 GUI에 표시하거나 DB에 저장하기 편리한 형식으로 repackage 합니다.

Adapters는 GUI의 MVC 아키텍처를 완전히 내포하며, Presenter, View, Controller 가 모두 여기에 속합니다.

Infrastructure

Infrastructure는 모든 I/O components(UI, DB, Frameworks, Devices)가 있는 영역입니다.

이는 변화될 가능성이 매우 높기 때문에 stable 한 domain과는 확실히 분리가 되어 있고, 그렇기 때문에 비교적 쉽게 변화되고 component 또한 쉽게 교환됩니다.

Conclusion

결국 Clean Architecture는 다음과 같은 이점이 있다고 정의내립니다.

의존성 규칙에 따름으로써 관심사가 분리된다
본질적으로 테스트하기 쉬운 시스템을 만들 수 있다
의존성 규칙이 가져오는 이점을 가져올 수 있다

그리고 주요한 이러한 특징을 지닙니다.

같은 상황과 이유로 변경되는 Class들은 Components로 묶인다
Business Rule은 stable한 components로, 변경되기 쉬운 외부의 infrastructure components (UI, DB, web, frameworks, ... )를 알지 못한다
각 components layer 간의 경계는 adapter 인터페이스를 통해 관리된다
Adapter는 Layer 간의 데이터를 편한 형태로 변환시켜주고 더 stable한 inner components로 의존성을 가지도록 한다

Hexagonal Architecture

그럼 헥사고날 아키텍처는 무엇이고, 왜 쓰이는걸까요?

인프라 ← 서비스 ← 프레젠테이션의 방향으로 의존성이 설계된 MVC 아키텍쳐에서는 인프라의 변화가 곧 뷰의 변화로 이어지기 쉽습니다. 하지만 웹서비스에서의 핵심은 인프라가 아니라 실제 비즈니스 로직이 수행되는 서비스 계층, 더욱 정확하게는 개발팀의 의사소통 단위가 되는 도메인 객체들입니다.

도메인 객체들은 근본적으로 서비스가 지니는 바운디드 컨텍스트 안에서 독립적인 로직을 가지고 있습니다. 영속성 계층, 혹은 메시지 큐와 같은 인프라는 결국 이러한 도메인의 상태를 저장하거나 전달하기 위해 존재할 뿐입니다. 즉, 도메인 객체들은 인프라에 의존하지 않아야 한다는 것입니다.

그렇기 때문에 헥사고날 아키텍처는 의존의 방향이 레이어드 아키텍처와 다릅니다.

클린 아키텍처와 마찬가지로 어디에도 의존하지 않는 도메인 객체들이 존재하고, 이들에 의존하는 서비스계층(또는 usecase 계층)이 존재합니다. 서비스계층에서 수행되는 비즈니스 로직들은 외부와 연결된 포트를 통해 시스템 외부로 전달되며 인프라는 포트에 의존합니다.

한 마디로, 외부와의 통신을 인터페이스로 추상화하여 비즈니스 로직 안에 외부 코드나 로직의 주입을 막는다는 것이 헥사고날 아키텍처의 핵심입니다.

주요 컴포넌트

Adapter

포트를 통해 인프라와 실제로 연결하는 부분을 담당하는 구현체를 의미합니다. Adapter는 크게 두 종류로 구분됩니다.

Driving Adapter(Primary Adapter)

사용자의 요청을 받아들일 때 사용되는 Adapter
예시: AWS Lambda의 Handler, WebApplication의 Controller

Driven Adapter(Secondary Adapter)

도메인 모델의 처리에 사용되는 Adapter
예시: MessageQueue, Persistence Adapter

Port

서비스(또는 usecase)에 어댑터에 대한 명세(specification)만을 제공하는 계층을 의미합니다. 단순히 인터페이스 정의만 존재하며, DI를 위해 사용됩니다.

Application Service(usecase)

어댑터를 주입 받아 도메인 모델과 어댑터를 적절히 오케스트레이션하는 계층을 의미합니다. 예를들어 게시글 작성이라는 usecase는 그에 필요한 Adapter를 주입받고 게시글 도메인 모델을 적절히 제어하는 로직을 지닙니다.

Domain Model

DDD의 도메인 모델과 동일한 개념을 지닌 계층입니다. 비즈니스 로직이라 부르는 엔티티에 대한 변경은 모두 해당 계층에서만 실행됩니다.

원칙적으로는 어떠한 의존성도 없어야 하지만 Entity를 만들 때 Database에 적재되어 있는 데이터를 참고해야하는 경우와 같은 상황에서는 Port를 이용해 Adapter를 주입받아서 사용할 수 있다는 예외사항이 존재하기도 합니다. 이는 클린 아키텍처와 동일합니다.

Why DDD, Clean Architecture and Hexagonal ?

그래서 DDD, Clean Architecture, Hexagonal Architecture에서 중요한건 뭘까요? 바로 명확한 관심사의 분리 입니다.

외부와의 연결에 문제가 생기면 Adapter를 확인하면 될 것이고, 인터페이스의 정의를 변경하고자 한다면 Port를 확인하면 됩니다. 처리 중간에 Custom Metric 측정을 위해 Event Bridge에 이벤트를 보내거나 트레이스를 로그를 심고 싶다면 Service(usecase)를 확인하면 됩니다.

마지막으로 비즈니스 로직이 제대로 동작하지 않는다면 Domain Model만 확인하면 되는 것이지요.

이러한 구조는 결국 쉬운 테스트를 가능하게 해주기도 합니다. 본인의 역할을 수행하기 위해 필요한 Port만 모킹하여 테스트를 쉽게 수행할 수 있습니다.

Is Hexagonal Superior to MVC?

꼭 그렇다고만은 볼 수 없습니다. 아키텍처란 코드를 표현하는 방법 중 하나일뿐 그 자체로 우월성을 가질수는 없습니다. 도메인이 외부에 닫힌 정도에 따라서 MVC와 같은 단순한 구조가 더 좋을 수도 있습니다.

더욱 중요한 것은 깨진 창문을 만들지 않거나, 만들더라도 빨리 고치는 것입니다. 헥사고날에서 발생하는 가장 대표적인 깨진 창문을 하나 언급하고 싶습니다.

네이밍이 모호한 포트는 구현체의 의존성을 과도하게 많거나 적게 만듭니다. 포트의 이름이 너무 범용적일 경우에는 이런저런 외부 네트워크 콜이 구현체 로직에 포함되게 되는데 외부 의존성이 늘어날수록 코드의 로직은 깨지기 쉽고 유지보수하기 어려워집니다.

코드의 로직이 뚱뚱해지면서 선뜻 건들기 어려워진 코드가 탄생할 것이고 이는 결국 생산성 저하로 이어지게 됩니다. 반대로 포트의 이름이 너무 지엽적일 경우에는 보일러플레이트의 양이 과도하게 많아지게 됩니다. 의존성이 적다는 점에서 SRP를 그나마 잘 구현했다고 느낄 수 있겠지만, 현실 세계의 개발에서는 개발 속도 또한 무시할 수 없고, 지나치게 많은 코드는 서비스의 오류지점과 유지보수 비용을 늘린다는 점에서 생산성의 저하로 이어지게 됩니다.

도메인에 따라서 MVC로 작성한 코드가 거대한 레거시 덩어리로 느껴질 수도 있습니다. 하지만 그럼에도 불구하고 아키텍처 그 자체보다는 코드가 지니는 가치와 생산성에 집중해야만 합니다. 방식이 다를 뿐, 틀린 것은 아닙니다. 이를 얼마나 잘 타협하면서 의존성의 크기를 잘 조절하는지도 정말 중요합니다.