Flowkater.io

'브레이크넥'을 읽고 (공학자의 나라, 법률가의 나라, 그리고 한국)

Tony Cho (https://flowkater.io) — Sat, 30 May 2026 12:40:00 GMT

들어가며

인재전쟁 다큐멘터리가 유행이다. 중국에 아이 유학을 보내야 하냐는 스레드도 보인다. 다큐멘터리가 짚는 한국의 인재전쟁, 한국 교육의 문제점, 한국 미래에 대한 걱정에는 모두 공감하지만, 어딘가 중국 공산당의 위대함을 자랑하는 홍보 영상 같은 느낌을 받았다. 다큐는 한국의 문제점을 조명하느라 중국의 공학 발전의 밝은 면만을 강조한다. 최근에 중국 SF 소설 삼체를 워낙 재밌게 읽었던 터라 (소설 한 권에 이렇게까지 꽂히는 것도 병이다), 미국과 경쟁할 정도로 급성장한 중국의 이면에는 어떤 이야기가 있을지 궁금해서 이런저런 자료를 찾아봤다. 그러다 인재전쟁2 1부에 잠깐 등장한 "공학자의 나라 중국, 법률가의 나라 미국"이라는 표현, 그리고 그 말을 한 댄 왕이라는 사람의 책 《브레이크넥》을 찾아서 몰입하여 읽게 되었다.

책을 덮고 나서, 다큐를 보며 느꼈던 그 위화감의 정체를 조금은 알 것 같았다. 이 책이 전하려는 메시지를 내 식대로 한 문장으로 정리하면 이렇다.

한 나라의 힘은 결국 무언가를 직접 만들어내는 능력에서 나온다. 중국은 그 능력을 손에 쥔 채 사람을 부품처럼 다루고, 미국은 사람을 지키는 절차에 갇혀 만드는 법을 잊어버렸다. 그리고 한국은, 만들지도 지키지도 못한 채 그 사이 어딘가에 어정쩡하게 서 있다.

공학자의 나라, 법률가의 나라

책의 핵심은 단순하다. 중국은 엔지니어가 다스리는 나라, 미국은 변호사가 다스리는 나라라는 것이다.

대부분 법률가 출신으로 이루어진 미국의 사회 지도층은 주로 무언가를 가로막고 방어하는 데 능하지만, 대부분 공학자나 기술자 출신으로 이루어진 중국 고위 지도부는 무언가를 새롭게 만들어내는 데 능하다.

중국의 고위직 상당수가 엔지니어와 과학자 출신이고, 이들은 문제를 발견하면 "지을까 말까"가 아니라 "어떻게 지을까"만 고민한다. 미국은 반대다. 역대 대통령 절반 이상이 법대 출신이고, 무엇을 하든 환경 영향 평가, 주민 의견 수렴, 법적 검토라는 절차를 통과해야 한다. 저자는 이 차이가 그저 성향의 문제가 아니라 국가의 성장 속도를 가른다고 본다.

먼저 미국은 결과보다 과정을 더 중시하게 되었다. 미국 정부와 사회는 전략이나 목표에 대해 깊이 생각하는 대신, 새로운 규칙을 만들거나 위원회를 설치하는 데 더 익숙해졌다.

이 차이를 가장 적나라하게 보여주는 게 고속철도다. 2008년, 중국과 미국 캘리포니아는 똑같이 약 1,300km 길이의 고속철도를 짓기로 결정했다. 중국은 3년 만인 2011년에 베이징과 상하이를 잇는 노선을 360억 달러로 완공했다. 캘리포니아는 17년이 지난 지금도 못 끝냈고, 비용은 1,280억 달러로 불어났다. 중국이 같은 길이를 통째로 까는 데 걸린 3년이, 캘리포니아에선 짧은 구간 하나가 언제 열릴지를 두고 벌어지는 오차 범위에 불과하다.

힘은 결국 "만드는 능력"에서 나온다. 저자는 이걸 과정 지식(process knowledge)이라 부른다. 설계도만으로는 아이폰을 못 만든다. 수많은 사람이 직접 조립하고 깨지면서 머릿속에 쌓이는 노하우가 있어야 한다. (딴소리긴 한데, 소프트웨어 설계도 비슷하다. 소프트웨어 아키텍처라고 부르는건 보통 코드를 직접 작성하는 과정에서 완성된다.)

하지만 선전에서는 새로운 나사 수십만 개 정도는 어렵지 않게 만들어낼 수 있는 공장을 쉽게 찾아낼 수 있습니다.

애플이 미국에서 9개월 걸려 구할 9,000명의 엔지니어를, 중국 선전에서는 2주 만에 모은다. 반면 미국은 핵무기 재료 만드는 법을 잊어버려 다시 배우는 데 6,900만 달러(약 940억 원)를 썼다. 만들던 사람들이 다 은퇴하거나 죽어서, 설계도는 있는데 손맛이 사라진 거다. 손맛이라는 말이 우습게 들리지만, 저자는 여기서 한 발 더 들어간다.

기술은 사람과 절차적 지식으로 이해하는 것만으로는 부족하다. 우리가 만들어내는 기술을 통제할 수 있는 주체적 감각을 더 강화하는 것이 진짜 기술이다.

빠름의 대가

하지만 빠른 게 늘 좋은 건 아니다. 책 제목 브레이크넥(breakneck)부터가 목이 부러질 만큼 위험한 속도라는 뜻이다. 《브레이크넥》이 진짜 무서운 건 그 속도의 대가를 적나라하게 들춘다는 점이다.

중국의 한 자녀 정책은 인구학자가 아니라 미사일 과학자가 설계했다.

오직 공학을 중시하는 국가만이 한 자녀 정책 같은 제안을 할 수 있을 것이다. 미사일을 연구하던 과학자를 불러들여 인구문제 해결을 맡기는 곳이 또 있을까?

기계 제어 이론을 인구에 갖다 붙여 "21세기 중반 45억 명"이라는 엉터리 예측을 내놨고, 그 계산 위에서 35년간 3억 건이 넘는 낙태가 강제됐다. 정책이 없었어도 출산율은 알아서 줄고 있었는데 말이다. 저자는 이 사례를 통해 과학 그 자체를 신봉하는 태도를 경계한다.

"과학자나 전문가는 일하는 사람이지 군림하는 사람이 아니다"라는 윈스턴 처칠의 말은 지금 생각해도 참 대단한 명언이 아닌가.

한 자녀 정책으로부터 정확히 40년 뒤, 중국은 더 야심 찬 사회 통제 실험을 시작한다. 제로 코로나다. 2,500만 상하이를 두 달간 봉쇄하면서, 양성 판정을 받은 아기를 부모와 강제로 떼어놓기까지 했다. 사람을, 가족이라는 단위마저 통계 숫자처럼 다룬 것이다.

중국은 고열을 동반한 전염병이 퍼지는 상황에서 국민의 해열제 복용을 가로막은 유일한 국가다. 공학자 중심 국가의 뒤틀린 논리를 이보다 완벽하게 요약한 사건은 없을 것이다.

그리고 그 끝이 룬(run) 현상이다. "도망친다"는 뜻의 이 유행어처럼, 2024년 한 해에만 백만장자 1만 5천 명이 중국을 떠난 것으로 추정된다. 늘 작동하던 국가가 어느 날 자기를 직접 겨눌 수 있다는 걸 깨달은 사람들의 반응이다.

내가 알고 있는 상하이의 사회 지도층이나 상류층 사람들은 국가에 대한 믿음을 잃었다. 지금까지는 누구도 중국이라는 국가의 가장 날카롭고 강압적인 제도나 체제가 자신들을 직접 겨냥할 수 있다고는 상상도 하지 못했다.

저자 댄 왕은 중국에서 태어나 어릴 때 캐나다로 이민했고 지금은 미국에 산다. 그래서인지 중국, 미국 좌우파 할 것 없이 모두까기를 자처한다. 그렇다고 까기만 하는 책은 아니다. 그가 이 책을 쓴 진짜 이유는 서로가 서로를 너무 모른다는 데 있다.

초강대국 사이에 긴장감이 고조되는 것을 막는 가장 좋은 방법은 서로를 향한 관심, 즉 호기심을 갖는 것이다.

예전에 나는 사람을 대하는 태도에 관해 "판단하지 말고, 호기심을 가져라"라는 글을 쓴 적이 있는데, 국가 사이의 관계에도 똑같은 말이 적용된다. (호기심이야말로 인류가 행복해지는 궁극의 지름길인가?(..))

완성주의와 장기 베팅

중국이 그 속도를 어디에 쏟는지를 보면 전략이 보인다. 핵심은 "다 만든다"는 완성주의다.

시진핑 주석은 중국이 완벽주의를 목표로 한다고 선언했는데, 이는 '저사양 산업'조차 중국에서 퇴출되지 않는다는 뜻이다. (...) 시진핑 주석은 각각의 산업 분야가 계속해서 국가 경제 규모를 따라 옮겨 가는 것 자체를 원하지 않는다.

인건비가 오르면 저부가가치 제조업은 더 싼 나라로 떠나는 게 경제학의 상식인데, 중국은 그 상식을 거부한다. 실물경제를 절대 놓지 않겠다는 거다.

시진핑 주석은 "실물경제가 모든 것의 기반이므로 절대로 탈산업화를 해서는 안 된다"고 선언했다.

여기에 자원을 한곳에 몰아붓는 방식이 더해진다. 저자가 정리한 중국식 사회주의의 정의가 인상적이었다.

그가 생각하는 사회주의의 핵심 특징은 경제적 재분배가 아니라 '더 큰 과업을 달성하기 위해 자원을 집중하는 것'이었다.

그 집중은 인재의 방향까지 인위적으로 튼다. 중국에서 엔지니어는 의사 친구보다 2~4배를 버는 최고의 직업인데, 이건 저절로 그렇게 된 게 아니다. 책에 따르면 중국은 금융업 종사자의 연봉 상한선을 제한해서까지 똑똑한 사람들이 공학을 선택하게 만든다. 반대로 정치체제 유지에 도움이 안 되는 SNS나 소프트웨어 사업은 철저히 막는다. 중국에서 더 이상 소프트웨어 유니콘이 나오지 않는 것도 그 이유다. 엔지니어는 농담하지 않는다는 말이 있는데, 공산당의 엔지니어링으로 통제되는 나라에서 중국판 케이팝이나 글로벌 히트 드라마 같은 문화적 폭발이 나오지 않는 건 어쩌면 당연한 결과다.

물론 이 방식엔 분명한 역효과가 있다.

무엇보다 기업가들이 사업에 많은 어려움을 겪으면서 원래 지니고 있던 야성적 열정이 크게 꺾이고 말았다.

그럼에도 이 전략의 위력은 부정할 수 없다. 중국이 해외로 인프라를 수출하는 일대일로 사업은 150여 국가에 1조 달러 규모의 대출을 포함한다. 그리고 저자는 이 모든 것의 바닥에 결국 사람이 있다고 말한다.

결국 가장 중요한 건 사람이다. 중국에는 제조업 종사자가 약 1억 명에 이른다.

그래서 한국은

그러니 다큐멘터리 하나 보고 중국을 마치 위대한 나라인 양 착각하면 안 된다. 그 발전 아래에는 수많은 중국 인민들의 희생이 깔려 있다.

덴마크가 풍력발전 산업에서, 그리고 한국이 메모리 칩 산업에서 그랬던 것처럼 소규모 선진 국가들은 이제 어떤 전략을 선택해야 할지 고민해야 한다.

다큐에서는 한국이 이미 중국 산업 포트폴리오의 "부분 집합"이 됐다고 말한다. 한국이 할 수 있는 건 중국도 다 하고, 중국이 하는 것 중엔 한국이 못 하는 게 많다. 그런데 우리는 스카이보다 의대다. R&D 예산은 깎이고, 메타물질 분야의 석학마저 연구를 계속하겠다며 중국 대학으로 자리를 옮긴다. 인재전쟁 다큐에서 말하는 위기는 현재진행형이고, 그게 어떤 호러 영화보다 호러다.

다큐는 교육을 얘기한다. 하지만 결국 의사라는 직업이 주는 (막연한) 경제적 안정감이 그 길을 선택하게 만드는 거다. 그걸 선택하는 부모와 아이들은 아무 잘못이 없다. 비난할 필요도 없다. 중국은 그저 막강한 권력으로 이 보상 구조를 인위적으로 비틀었을 뿐이다.

한국은 중국 같은 공학자의 나라라기보다, 어딘가 애매하게 미국 같은 법률가의 나라를 닮았고 또 그걸 쫓고 있다. 책은 중국과 미국이 각자의 갈 길을 제시하는데, 거기서 우리도 충분히 힌트를 얻을 수 있다고 본다. 바로 지금처럼 선진국의 정치체제를 지향하면서, 산업에서만큼은 중국처럼 "개발도상국"을 자처하는 길이다.

그럼 구체적인 방법은? 제조와 건설 같은 하드한 산업 기반에 다시 투자하고, 절차와 규제보다 "일단 짓고 만든다"는 공학자 마인드셋으로 돌아가는 것. 솔직히 지금 한국 현실에선 이 둘 다 쉽지 않아 보인다. 이미 미국식 절차와 규제가 두껍게 깔린 나라에서 하루아침에 공학자 마인드로 갈아탈 순 없으니까. 그나마 가능한 건 반도체, AI, 이차전지 같은 특정 첨단 기술 산업에 국가가 길게 베팅하는 길이 아닐까.

오해는 말자. 국가가 직접 AI(소버린?ㅋ)를 만들고 프로젝트를 주도하라는 얘기가 아니다. 중국은 미국의 경제 봉쇄 속에서도 디디추싱이나 BYD 같은 제조 기반 회사들이 적자를 내는 와중에 돈을 쏟아부어 제조력을 떨어뜨리지 않았고, 그렇게 지켜낸 기반 위에서 공산당이 다시 AI 산업에 어마어마한 투자를 하고 있다. 베팅은 산업의 토대를 길게 떠받치는 쪽이지, 정부가 플레이어로 직접 뛰는 게 아니다.

사실 나는 이 문제를 멀리서 본 게 아니다. 지난 회사에서 원하지 않았지만 국가 정책 주도의 소프트웨어를 만든 적이 있다. (맞다. 당신이 추측하는 것처럼 퇴사의 근원이다.) 그때 엔지니어링 마인드라곤 1도 없는 정책 시행자들과 실무자들, 그리고 시장 참여자들 모두에게 너무 질려버렸다. 수많은 회사가 몇백억을 투자하게 만든 그 프로젝트는 결국 정부가 바뀌면서 무산됐다. (그 절차 속에서 굴러간 결과물의 퀄리티가 좋았을 리도 없고.)

지금의 스타트업 지원 정책도 다르지 않다. 발표만 요란하고 눈먼 돈을 먹는 1,2년의 단기 사업들, 좌우 정권을 막론하고 지난 15년간 실패한 그 방식을 계속 반복하고 있다. 진짜 기술을 만들고 시장 경쟁력을 갖추는 기업을 길게 투자하고 밀어주는 게 아니라, 절차중심주의자들의 손에서 매년 같은 실패가 굴러간다. 진짜 글로벌 시장 대상의 고객 중심, 성과 중심, 기술 카테고리 중심의 명확하고 압도적인 장기 투자만이 우리 기술 산업을 키울 거다. AI 소버린 같은 삽질 그만하고.

교육을 얘기하는 건 그 다음이다. 산업의 변화 없이 인재상을 논하고 교육의 미래를 떠드는 건 또 다른 탁상공론을 반복하는 길이다. 산업이 성장하면 보상이 따르고, 그 시장 경쟁력에 맞춘 인재는 자연스럽게 만들어지게 되어 있다. 이런 설계야말로 엔지니어링 마인드의 숱한 단점 사이에 박힌, 몇 안 되는 장점이 아닐까.

나가며

저자의 결론은 의외로 균형 잡혀 있다. 그는 어느 한쪽이 이겼다고 선언하지 않는다.

나로서는 미국은 국민을 위한 기반 시설을 건설할 수 있는 역량을 하루빨리 회복하고, 중국은 개인에 대한 실질적인 법적 보호를 보장하는 동시에 다원주의를 중시하는 법을 배우는 날이 오기를 기대할 뿐이다.

그가 원하는 건 변호사를 다 몰아내는 것도, 모두가 공학자가 되는 것도 아니다.

나는 미국에서 변호사들을 다 몰아내자는 게 아니다. 그보다는 공학자와 기술 관료의 사고방식을 갖춘 경제학자들을 다시 키우고 싶을 따름이다. (...) 각기 다른 목소리를 낼 수 있도록 각자의 역량을 골고루 인정해주자는 말이다.

만드는 능력과 지키는 절차, 둘 다 필요하다는 이 당연한 말이, 한쪽으로 완전히 기울어버린 두 나라 사이에선 이상하게 어렵다. 그리고 그 사이에 낀 한국은, 만드는 쪽도 지키는 쪽도 제대로 못 하고 있다는 게 나의 솔직한 진단이다.

그래서 나는 자꾸 묻게 된다. 중국의 일대일로나 국가 경제사회발전 5개년 계획 처럼, 정권이 바뀌어도 장기적으로 밀고 나가는 투자와 인프라 구축이 과연 우리나라에서 가능할까. 목이 부러질 듯한 속도까지는 바라지도 않는다. 다만 정권이 한 번 바뀌어도 부러지지 않는 등뼈 하나쯤은, 우리도 가질 수 있지 않을까.

추가로 밑줄 친 문장

사람들의 상상 이상으로 효율적인 정부를 운영하는 것이 과연 가능할까? 중국에서 보낸 6년의 세월을 통해 나는 정부가 국민의 의견에 크게 구애받지 않을 때 그런 일이 가능하다는 사실을 배웠다.

2024년에 나온 (중국) 과학기술부의 한 논평에 따르면 '국가 간 국력 경쟁은 본질적으로 과학기술 혁신의 경쟁이며, 궁극적으로 어떤 정치체제가 우월한지 증명하는 잣대'라고 한다.

중국의 과학기술 발전을 부추긴 건 결과적으로 미국이었다. (...) 미국은 자국에서 세계를 깜짝 놀라게 할 혁신을 일으키기는커녕, 오히려 중국이 그렇게 할 수 있도록 힘을 실어주는 건 아닌가 하는 생각이 들 정도였다.

자유로운 사고와 분위기는 인문학과 사회과학에 꼭 필요하다. 하지만 자연과학에도 그런지는 확신할 수 없다. (...) 역사적으로만 봐도 독재 체제 아래에서 놀라운 기술 발전이 이루어진 사례는 얼마든지 있다.

나는 미국 사회가 인공지능에 지나치게 의존하는 방향으로 흘러가고 있다고 생각한다. 인공지능이 아무리 발전한다 한들, 군수물자와 무기가 실제로 생산되어야 하는 게 아닌가. 컴퓨터 연산 능력 향상만으로는 결코 전쟁에서 승리할 수 없다.

각국의 산업적 역량은 곧 군사적 역량으로 이해해야 옳다.

"사회가 무너질수록 법은 더 늘어난다. 그러다 마침내 세상이 지옥으로 변하면 오직 법만 존재할 것이며, 모든 절차가 적법한지도 아주 꼼꼼하게 확인할 것이다." (그랜트 길모어)

시진핑 주석에 대해서는, 모든 면에서 60퍼센트 정도 옳다는 점이 오히려 문제라고 여겨진다.

🥜 Google은 어떻게 신뢰를 잃어가고 있는가

Wed, 20 May 2026 08:00:00 GMT

Theo(t3.gg)가 또 한 번 커리어를 걸고 영상을 올렸다. 이번엔 Google이다. Google IO 직후, "내가 이 영상을 만드는 게 두렵다"는 고백으로 시작한다. 이전에 Google 제품을 비판했을 때 동영상 수익 창출이 차단되고 "부정직한 콘텐츠"로 플래그 처리됐던 경험 때문이라고 한다. 그럼에도 만들었다.

지난 달 Claude Code 비판 영상과 같은 패턴이다. 모델 성능보다 vendor 신뢰가 더 중요해진 시대의 표시이기도 하다.

Theo가 짚은 Google의 세 가지 실수는 이렇다.

1. Gemini 3.5 Flash — 숨겨진 가격

벤치마크 숫자는 GPT-5.5에 근접하다. Terminal Bench, SWB Pro 등에서 Opus 47, GPT-5.5와 어깨를 나란히 한다. 속도는 초당 300 토큰 수준으로 가장 빠르다.

문제는 발표 페이지에 달러 사인 자체가 없다. 실제 가격은 출력 $9/백만 토큰. 이전 Flash 3의 3배, Gemini 2.0 Flash의 20배 이상이다.

게다가 토큰 효율도 최악이다. 같은 벤치마크 실행에 GPT-5.5 Medium이 2,200만 토큰을 쓸 때, Gemini 3.5 Flash는 7,200만~7,300만 토큰을 쓴다. 3.3배. "2배 빠르지만 4배 많은 토큰을 쓴다면 결국 2배 느린 것"이라는 Theo의 말이 정확하다.

Theo가 직접 코딩 테스트(Fish Slop 게임 리라이팅)에서는 테스트한 모든 모델 중 유일하게 동작하는 코드를 만들지 못했다. 같은 작업을 GPT-5.5에게 시키자 3D 버전까지 완성했다고 한다.

2. Anti-gravity CLI — 오픈소스 배신

Gemini CLI는 100K GitHub 스타, 6,000개의 머지된 PR을 가진 오픈소스 프로젝트였다. Dmitri, Jack, Gal 세 명의 팀이 커뮤니티와 신뢰를 쌓아왔다.

Google은 Windsurf 창업자들을 인수했고, 그들이 anti-gravity 팀을 인계받았다. 기존 팀원 셋은 교체됐다. 그리고 Gemini CLI는 Anti-gravity CLI로 재작성되며 클로즈드소스가 됐다. 6월 18일부터는 Google AI Pro/Ultra 구독자는 Anti-gravity CLI만 사용 가능하다.

새 CLI는 스크롤 불가, 이메일 노출, Ctrl+C 작동 안 함, 재실행 시마다 재로그인. 공식 발표 영상에서 폴더명이 "Codeex"인 게 그대로 노출됐다. Cursor를 베끼고 있다는 증거다.

3. Railway 계정 차단 — 신뢰 못 할 클라우드

Railway는 월 $2M 이상을 Google Cloud에 쓰는 고객이다. 그런 회사의 계정을 Google Cloud가 예고 없이 전면 차단했다. railway.app 등 모든 웹 기반 서비스가 다운됐다.

2년 전 UniSuper 사건이 떠오른다. 호주의 $1,350억 규모 연금 펀드 계정을 Google Cloud가 실수로 통째로 삭제했다. 다른 클라우드에 백업이 있어서 데이터 손실은 면했지만, "이 규모의 조직 계정이 전부 삭제될 수 있다는 건 전례 없는 일"이라고 Theo는 말한다.

비교는 매섭다. Azure는 느리고 이상해도 알람 올리면 대응한다. AWS는 여전히 1위인 이유가 있다. Google Cloud는 "실제로 얼마나 신뢰할 수 없고 형편없는지 믿을 수 없을 정도"라는 게 Theo의 평이다.

여기서 단순한 vendor 흠집 잡기로 끝났다면 영상은 별게 아니다. 그러나 Theo가 짚는 더 큰 문제는 이거다.

Google은 다 갖췄다. 인프라, 인재, 생태계, TPU, 연구력. 그런데 결과가 없다. 정치가 제품을 죽인다. Windsurf 인수 → 기존 팀 교체 → 지역 커뮤니티 신뢰 붕괴. 1년 넘게 Dmitri, Jack, Gal의 DM 소통과 피드백 대응 덕분에 Theo가 공개 비판을 자제했었다는 고백은 의미심장하다.

신뢰는 한 사람 한 사람의 관계로 쌓이고, 인사이동 한 번에 무너진다.

지난 달 Claude Code 사건이 떠오른다. 그때 나는 모델 성능이 아니라 신뢰가 vendor를 가른다고 썼다. 지금 Google에 일어나고 있는 일도 정확히 그 연장선이다. 다만 강도가 더 세다. Claude Code가 과금 라우팅 한 건이었다면, Google은 가격 은폐 + 오픈소스 배신 + 고객 계정 차단의 3관왕이다.

Theo의 결론은 단호하다. "Google 것에 뭔가를 빌드하고 있다면, 빼내라. 이걸 신뢰할 수 없다."

세 가지 실용적 시사점이 남는다.

AI 모델 비용은 토큰 효율성 × 단가다. 벤치마크 점수만 보면 안 된다. 실제 작업당 토큰 소비량이 실 비용을 결정한다.

오픈소스 CLI의 가치는 코드가 아니라 커뮤니티 신뢰다. 클로즈드소스로 전환하는 순간 그 자산은 0이 된다.

멀티클라우드 백업은 비용이 아니라 보험이다. UniSuper가 살아남은 이유고, 단일 클라우드에 모든 걸 거는 회사가 죽는 이유다.

이게 더 무겁게 다가오는 이유가 있다. 한국 시장에서도 클라우드와 AI vendor 선택이 본격적으로 표면화되고 있는데, 우리가 지금 보고 있는 건 "가장 크고 강력한 곳이 가장 안전하다"는 가정이 깨지는 풍경이다. 인프라·인재·자본 다 갖춘 Google이 신뢰를 잃는다면, 모든 선택은 두 번씩 검토받아야 한다.

Theo의 영상은 단순한 비판이 아니다. vendor 신뢰가 모델 성능을 이긴 시대의 두 번째 증거다. 지난 번 Claude Code가 첫 번째였다면 이번엔 Google. AI 시대에 vendor 신뢰는 새로운 인프라 위기다.

모델은 외부에서 빌려 쓸 수 있다. 하지만 비용 통제, 정책 변경, 인사이동에 따른 팀 붕괴 — 이런 위험은 점점 사용자 쪽으로 내려온다. 그게 멀티클라우드가 왔던 방식이고, AI vendor도 같은 길로 갈 것이다.

좋은 회사는 좋다. 그렇다고 신뢰할 수 있는 건 아니다.

'악마와 함께 춤을'을 읽고 (나쁜 감정과 함께 사는 법)

Tony Cho (https://flowkater.io) — Tue, 19 May 2026 14:00:00 GMT

들어가며

삶을 살아가다 보면 삶의 대부분을 채우는 감정은 대개 긍정적인 감정보다는 부정적인 감정이다. 계획대로 보내지 못한 하루를 후회하기도 하고 내 마음대로 되지 않는 일에 대해서 화를 낸다. SNS를 가득 채우는 성공한 사람들을 보며 시기하기도 하고 수준 낮은 사람들을 보며 그들을 경멸하기도 한다. 타인을 만나며 드는 나의 부정적 감정을 억누르며 자기 검열을 하기도 하고, 타인에 대한 분노와 시기, 경멸이 또 나 스스로에게로 향하기도 한다.

불친절한 식당이나 사소한 일로 부당한 대우를 받은 것처럼 느껴 분노하면서 씩씩대기도 하고, 어떤 사람들을 보며 시기하며 그들을 냉소적으로 평가하기도 한다. 경멸은 말할 것도 없다. 이전에 회사들에서 일하면서 속으로 경멸하던 직원들이 분명 있었고, 회사나 이해할 수 없는 일방적인 업무 전달에 공공연히 분노하기도 했다. 업무에 있어서 나는 자주 예민해져서 이런 부정적인 감정을 자주 표출하였다. 이런 내 모습들이 성숙한 사람처럼 보이지는 않았을 것이다.

최근에 이전 회사 팀원분과 만나 얘기할 기회가 있었는데, 퇴사한 지 1년이나 지났는데 왜 아직도 그렇게 화가 나 있냐고 물었다. 부끄럽지만 그에 대한 내 대답은 왜 내 화가 정당한지에 대한 변명을 늘어놓는 것이었다. 그리고 최근에 쓴 AX나 조직 관련 에세이들도 대부분은 어떤 특정 목적보다는 내 분노의 표출 수단으로 활용된 것이라고 이전에 밝히기도 했다. 분노로 글쓰기라니, 언뜻 고상해 보이지만 그 근본이 되는 나의 부정적인 감정은 말 그대로 부정적인 것이다.

가만히 생각해보면 타인(또는 나 자신)을 미워하고 분노하고 시기하는 이런 부정적인 감정이 내 삶의 대부분을 차지한다니, 나는 정말 구제불능인가 하는 생각도 든다. 우리는 모두 부정적인 감정은 나쁜 것이며, 사소한 것에 화내지 말아야 하며, 타인을 시기하거나 비교하지 말아야 하고, 누군가를 미워하거나 경멸하는 건 스스로를 파괴하는 행위이며, 부정적인 감정을 느끼면 안 되고 (특히 타인에게) 그걸 표출할 경우 우리는 그 사람의 인성에 문제가 있다고 배워왔다. 그래서 내가 "감정 성인(Saint)"이라 부르는, 모든 감정을 통제할 수 있는 상태가 우리가 지향해야 하는 궁극적인 방향이고, 나는 항상 그 방향이 옳다고 생각하고 항상 정진해야 한다는 생각을 가지고 있었다. 명상을 하고, 일기를 쓰고, 수행을 쌓고.

만약 "감정 성인"이 플러스(+) 극단에 있는 최고 등급이라면, 나는 감정을 통제하지도 못하고 대부분을 부정적인 감정을 표출하며 살고 있으니 마이너스(-) 영역에서 낮은 등급 중 하나인 인간일 것이다. 플러스(+)를 향해야 한다는 말에 딱히 반박하고 싶지는 않지만, 저 높은 등급을 바라보고 있자니 이번 생은 틀려먹었나 하는 생각이 가끔 든다.

그렇다고 하루하루를 자책하며 보내고 있지는 않다. 겉으로만 보면 평온한 상태이고, 그저 하루하루 내 할 일과 정해진 일들을 묵묵히 반복하며 살아가고 있다. 물론 내가 너무 사소한 일에 화를 내며 씩씩대면 항상 엘리가 나를 진정시켜주기 때문에 사회 생활이 그렇게 어렵지는 않은 수준이다. 우리는 성인(adult) 이지 않은가? 매일매일이 해피해피할 수 없다는 게 우리네 인생이고 단순히 긍정적인 감정들로만 나를 채울 필요가 없다는 것도 머리로는 알고 있다. 그리고 이러한 부정적인 감정들이 만약 정말 나를 파괴하고 있다면 난 이미 정상적인 생활을 하고 있지 못할 것이다. 하지만 돌아보면 긍정적인 감정보다 부정적인 감정 비율이 높다는 것, 이러한 감정들 그자체에 휩싸이거나 그 때문에 자책하는 순간들이 있기에 가끔은 부정적인 감정들에만 허우적대는 나 스스로에게 좌절감을 느끼긴 한다. 나는 좋은 사람이 아닌 걸까 하는 그런 자괴감과 함께 말이다.

그때 우연히 이 책을 알게 되어 단숨에 읽게 되었다. 《악마와 함께 춤을》의 저자 크리스타 K. 토마슨은 감정과 도덕을 오래 연구해 온 철학자다. 시기, 질투, 분노 같은 "나쁜 감정"을 변호하는 게 이 책이 하는 일이다. 그리고 이 책을 통해 나는 "감정 성인" 플러스(+) 방향으로 업그레이드하지는 못했으나, 내 부정적인 감정의 실체를 이해하는 일과 내 삶에서 이 감정을 다루는 방식만큼은 이 책을 읽기 전과 후로 크게 바뀌었다고 단언할 수 있다. 혹시나 또 내가 부정적인 감정에 잠식되어 방황하고 있을 때 이 책이 길을 다시 찾아주길 바라고, 그것이 짧게라도 이 리뷰를 쓰게 된 계기이다.

이 책이 전하려는 메시지를 내 식대로 한 문장으로 정리하면 이렇다.

부정적인 감정은 제거해야 할 결함이 아니라, 내가 삶과 사람과 의미에 애착을 갖고 있다는 신호다. 문제는 감정을 느끼는 일이 아니라, 감정을 통제하고 정당화하고 생산성으로 바꾸려는 조급함이다.

"감정 성인" 등급표가 잘못됐다

저자는 책의 전반부에서, 우리 모두가 사회적 잣대로 세워둔 그 "감정 성인" 등급표 자체가 잘못됐다고 말한다. 우리는 긍정적인 감정에 대해서는 "좋은 긍정", "나쁜 긍정"을 따지지 않는다. 그저 있는 그대로 즐긴다. 그런데 부정적인 감정에 대해서만 유독 이중 잣대를 들이댄다. 어떨 땐 분노해도 되고 어떨 땐 안 되고, 누군가를 시기하거나 경멸하는 건 무조건 안 된다고.

그런데 과연 나쁜 감정을 피하려고 껍데기 속의 거북이처럼 살아가는 게 가치가 있을까?

저자는 여러 철학자의 주장과 그 배경을 짚어가면서, 부정적인 감정도 긍정적인 감정과 똑같이 이중 잣대로 재단하지 말라고 한다. 오히려 그런 감정은 자연스러운 것, 나아가 필요한 것이라고 말한다. 남을 시기하는 감정조차도, 누군가를 경멸하는 감정조차도 그렇다.

우리는 상대와 비교하며 자아를 형성하고, 때로는 누군가를 미워하면서 스스로의 존재 의의를 찾기도 한다. 물론 부정적인 감정에만 기대 자아를 만들고 존재 의의를 찾는 건 문제다. 하지만 그 과정에서 생겨나는 감정 자체를 부정하지는 말라는 것이다. 감정을 통제하는 "감정 성인"이 인격적으로 더 뛰어나다는 기준 그 자체가, 인간의 자연스러운 야생성을 거세하는 부자연스러운 잣대다.

감정은 나름의 지능이 있어 때로는 우리보다 우리를 더 잘 알기도 한다. 그렇다면 감정이 우리말을 듣도록 훈련시키기보다는 우리가 감정에 귀를 기울이는 법을 배워야 한다.

책에서 가장 좋아하게 된 비유는 지렁이였다.

지렁이다움을 모두 벗어 던져야만 녀석을 사랑할 수 있다면, 그건 지렁이를 사랑하는 게 아니다.

내가 앞에서 그려본 그 등급표는, 사실 기준 자체가 틀린 표였다. 내가 느끼는 이 감정들은 인간이라면 응당 느끼는 자연스러운 것이고, 그저 있는 그대로 느끼면 된다. 그 사실 하나를 아는 것만으로도 나는 조금 자유로워졌다.

분노로 쓴 글, 그리고 1년이 지나도

앞서 나는 최근에 쓴 AX 관련 에세이들(그중 한 편)이 어떤 특정한 목적보다 내 분노의 표출 수단이었고, 그게 부끄럽다고 적었다. 그런데 책의 논리를 따라가다 보니 다르게 보였다. 그 글들의 근본에 있는 분노는, 내가 조직과 일을 여전히 소중히 여긴다는 신호였다. 그동안 여러 실패와 경험을 통과하면서도 그것이 여전히 내 인생의 중요한 부분이라고, 분노로 쓴 글들이 대신 역설하고 있었던 거다.

저자는 분노를 쓸모로 옹호하는 태도를 오히려 경계한다.

불의에 맞서 싸우기 위한 건설적인 분노만 정당하다는 것은, 감정이 생산적일 때만 가치가 있다고 간주하는 것이다.

어쩌면 내 분노를 글로 쓴다는 건, 그 근본 감정이 부정적이더라도 행위 자체는 부정적이지 않다는 뜻이다. 앞으로도 이 감정을 통제하려 애쓰기보다, 어떻게 글로 더 잘 승화시킬지 고민하는 편이 내 삶에 훨씬 유익할 거다.

분노를 다시 바라보자, 오래 미뤄둔 질문 하나에도 답할 수 있게 됐다.

퇴사한 지 1년이나 지났는데 왜 아직도 그렇게 화가 나 있냐고. 그때는 제대로 답하지 못하고 내 감정의 정당성을 변명했다. 책에는 이런 문장이 있다.

누군가에게 지속적으로 화를 내는 건 그 관계에 계속 시간과 노력을 들이는 것이다.

지금은 이렇게 답하겠다. 겉으로는 인정하고 싶지 않지만, 1년이 지나도 화가 남아 있다는 건 그 회사와 사람들에게 그만큼 애정이 있었다는 반증이라고. 내 분노의 뒤편에는 내가 쏟은 관심과 시간과 애정이 있고, 이제는 돌아갈 수 없는 그 시간들에 대한 아쉬움이 있다. 그 아쉬움이 남들 눈에는 늘 화가 나 있는 사람처럼 비치는 것일지도 모른다.

그리고 이 감정 또한 나의 오늘을 움직이는 수많은 동력 중 하나다. 그러고 보면 나는 정말, 책 제목 그대로 매일매일 악마(부정적인 감정들)와 함께 춤을 추고 있는 건 아닐까.

판단하지 말고, 그냥 느껴라

예전에 나는 사람을 대하는 태도에 관해 "판단하지 말고, 호기심을 가져라"라는 글을 쓴 적이 있다. 이 말은 타인뿐 아니라 내 감정에도 똑같이 적용되는 것 같다.

도대체 왜 나쁜 감정을 정당화하는 걸까? 내 감정을 다른 사람의 잘못으로 만들지 않고 그냥 느낄 수는 없을까?

우리는 감정에 대해 너무 빨리 결론을 내린다. 부정적인 감정 자체가 문제가 아니라, 그 감정에 조급하게 매기는 판단이 문제인데 말이다. 저자는 우리가 그 감정을 정당화하려 드는 이유를 다음과 같이 설명한다.

우리는 실패, 방황 또는 외로움을 맞닥뜨리기보다는 차라리 적을 만들기를 원한다.

분노를 정당화하는 순간 우리는 악당을 하나 만든다. 악당이 생기면 내 안의 실패와 외로움을 들여다볼 필요가 없어진다. 감정을 피하려는 그 태도가, 정작 감정 자체보다 더 큰 문제를 일으킨다는 거다.

"난 그렇게 속 좁거나 찌질하지 않은데", "나는 이것보다 조금 더 쿨한 사람인데", "난 더 좋은 사람이 되어야 하는데." 나도 늘 이런 말로 스스로를 기준에 묶어둔다. 그러다 보니 부정적인 감정이 그 기준을, 내가 나라고 착각해 온 그 기준을 무너뜨릴까 봐 두려워한다. 그래서 감정을 있는 그대로 받아들이지 못하고 회피한다.

앞서 적은 그 자괴감, "나는 좋은 사람이 아닌 걸까" 하는 그 마음도 결국 여기서 나온 거였다. 내 감정이 나빠서가 아니라, 그 감정이 내가 세워둔 "좋은 사람"이라는 기준을 흔들기 때문에 괴로웠던 것이다. 정작 흔들려야 했던 건 감정이 아니라 그 기준이었는데.

저자의 처방은 의외로 단순하다.

부정적인 감정에 대처하고 싶은 충동을 억제하라. 그냥 느끼는 법을 배워라.

그냥 느끼면 된다. 판단하지 말고, 내 감정에 충실하게 분노하고 경멸하고 시기하고. 그렇게 나 자신과의 대화가 끝나면 다시 털고 앞으로 나아가면 된다.

앞서 나는 회사에서 속으로 경멸하던 직원들 얘기를 꺼냈다. 책은 그 경멸조차 없애라고 말하지 않는다. 경멸은 내가 어디쯤 서 있는지 알려주는 나침반이 될 수 있다. 다만 그 나침반을 집터로 삼으면 위험하다고 한다.

어떤 사람을 기준으로 자신을 규정하면, 자신이 누구인지 절대 알 수 없다.

경멸을 느끼는 건 괜찮다. 다만 누군가를 깔보는 일을 내 정체성의 기둥으로 세우면, 결국 내가 누구인지는 영영 알 수 없게 된다. 느끼되, 거기에 집을 짓지는 말라는 것이다.

나쁜 감정은 당신에게 문제가 있음을 나타내는 신호가 아니다. 이것들은 정확히 자기가 해야 할 일을 하는 것뿐이다. 즉 당신이 자신의 삶에 애착을 가지고 있다는 신호를 보내는 것이다.

나가며 (그냥 느끼는 게 제일 어렵다)

그러니 처음의 질문으로 돌아가 본다. 나는 좋은 사람이 아닌 걸까. 책을 덮은 지금도 그 답을 자신 있게 "그렇다"고 말하지는 못하겠다. 다만 질문이 바뀌었다. 등급표에서 내 자리가 몇 점인지 묻는 대신, 나는 이제 이 감정들이 내가 무엇을 소중히 여기는지 말해주고 있다고 듣는다.

예전 같았으면 1년이나 남은 분노를 내 못난 인성의 증거로 읽었을 거다. 지금은 그게 내가 그 시간과 사람들을 소중히 여겼다는 증거로 읽힌다. 바뀐 건 내 감정이 아니라, 그 감정을 읽는 방식이다.

등급이 오른 게 아니라, 등급표에서 벗어나는 것이다.

재밌는 게 이렇게 생각하니 분노도 조금은 가라앉은 것 같다.

물론, 말처럼 쉽지는 않다. "그냥 느껴라"는 참 어려운 주문이다. 책은 왜 부정적인 감정도 그냥 느껴야 하는지를 논리적으로 전개하며 설득하지만, 어떻게 느껴야 하는지에 대한 구체적인 가이드는 주지 않는다. 지금 당장 부정적인 감정에 휩싸여 있는 사람이라면 "그래서 나는 어떻게 하라는 거지" 하는 막막함을 느낄 수도 있다.

책에서 말하는 실천 항목은 다음과 같다.

감정을 있는 그대로 말한다. "옆집 차가 부럽다." "나는 지금 화났다." "저 사람이 망해서 고소하다."
바로 설명하지 않는다. 변명, 옹호, 자기비난, 합리화 없이 멈춘다.
몸으로 느낀다. 불편함에서 빨리 빠져나오려는 충동을 참는다.
무엇을 소중히 여겼는지 묻는다. 이 감정은 내가 무엇을 원하고, 무엇에 상처받고, 무엇을 두려워한다는 신호인가?
타인을 악당으로 만들지 않는다. 분노와 시기를 정당화하기 위해 세계관을 조작하지 않는다.
생산적인 감정만 허용하지 않는다. 감정이 쓸모 있을 때만 가치 있다고 생각하면, 결국 감정을 또 통제하려는 것이다.

하지만 이러한 실천 항목 이전에 저자의 설득 과정과 논리를 끝까지 따라가는 것만으로도 충분하다. 그 길을 따라가다 보면 내 감정의 실체를 이해하게 되고, 이 감정들이 결국은 나를 살아 있게 하는, 정원의 지렁이 같은 존재라는 걸 깨닫게 된다.

나쁜 감정을 쫓아내면 삶은 조용해지고, 나쁜 감정과 춤추면 삶은 시끄러운 채로 살아 있다.

Amor Fati — 기쁨과 고통, 모두를 사랑하라.

니체가 특별히 좋아하는 격언이 아모르 파티다. 이 라틴어는 '운명에 대한 사랑' 또는 '운명을 사랑하라'라는 의미다. 운명을 사랑한다는 건 좋은 것과 나쁜 것, 즐거운 것과 고통스러운 것, 그리고 "야성적이고, 자의적이고, 환상적이고, 무질서하고, 경이로운" 모든 것을 포함한 삶 전체와 자신을 사랑하는 것이다.

"길들이지 마라. 있는 그대로 사랑하라."

아모르 파티는 나쁜 감정과 함께 잘 살아가기 위해 필요한 태도다. 운명을 사랑하려면 일단 운명을 받아들여야 한다. 여기서 받아들이라는 것은 부정적인 감정과 싸우지 말라는 단순한 뜻이 아니다.

세상에 좋은 책은 많지만, 지금 자신의 부정적인 감정에 시달리고 있다면 이 책을 꼭 권하고 싶다. 나는 여전히 분노하고 시기하고 경멸한다. 다만 이제는 그게 나를 판단하는 기준이 아니라, 내가 아직 내 삶에 단단히 붙어 있다는 증거라고 읽는다. 그렇게 오늘도 악마와 함께, 한 곡 추는 수밖에(...).

추가로 밑줄 친 문장

머리가 어디서 끝나고 가슴이 어디서 시작되는지가 항상 분명한 게 아니라는 점을 명심하자.

감정은 나름의 지능이 있어 때로는 우리보다 우리를 더 잘 알기도 한다.

변명도 옹호도 없이 직면하라.

다윈처럼 부정적인 감정은 지적인 것이라는 생각에 마음을 열어 두라.

우리가 시기를 회피하는 이유는 실패를 회피하기 때문이다. 하지만 인간은 실패할 때가 있고 인생은 원래 그런 것이다.

모든 사람은 자신이 익숙하지 않은 것을 야만적이라고 일컫는다.

누구도 불완전함을 뛰어넘을 수 없다.

누군가의 눈에는 우리 모두가 잠재적으로 '그런 사람들'(경멸의 대상)이라는 것이다.

🥜 삼체 — 평범한 구원자의 계보

Tue, 19 May 2026 07:29:00 GMT

삼체 3부작을 완독했다.

1부가 제일 짧고 3부가 제일 긴데, 뒤로 갈수록 몰입해서 더 빨리 읽었다.

나에게 최고를 뽑으라면 2부다.

주인공 뤄지와 결말 스토리로, 간만에 소설책을 읽으면서 흥분과 도파민이 최대치였다. 면벽자들의 기상천외한 전략과 반전, 그리고 "삼체"라는 소설 이름에 가장 걸맞은 서사가 2부였다.

뤄지는 《반지의 제왕》의 프로도, 비슷한 장르로는 《프로젝트 헤일메리》의 그레이스와 계보를 잇는 "평범한" 구원자다.

이 인물들은 정말 평범한 인물들이라, 우리가 그들의 심리 상태에 극도로 공감하게 한다. 삶의 압박감에 우리네처럼 도망도 가고 좌절도 하고 소소한 행복을 느끼고, 또 그렇게 앞으로 나아가는 인물 서사는 정말 매력적이다.

스토너에게 구원의 책임을 묻는 느낌이랄까.

1부는 드라마를 먼저 보고 읽은 터라 재미와 별개로 기시감이 컸고, 3부는 거대한 스케일과 마지막 전개가 인물(청신)이 주는 몰입이 나에게는 떨어져 개인적으로 아쉬웠다.

그래도 3부 우주 묘사만큼은 정말 압도적이었다.

넷플릭스 드라마는 소설에 비해 혹평하는 사람들이 많은데, 1·2·3부 도입부 인물들과 스토리를 잘 엮어서 시즌 1으로 만들었고 나는 그건 그거대로 매력이 있어서 다시 봐도 재밌었다. 올해 4분기? 시즌 2도 그래서 기대 중이다.

특히 뤄지와는 반대의 이유로 너무 좋아하는 토마스 웨이드를 분한 리암 커닝햄이 너무 연기를 잘해서, 그 서사와 캐릭터를 어떻게 묘사해줄지 너무 기대된다.

그들을 이해하기 때문에 공감 가는 뤄지와 답답한 청신과 달리, 오직 전진만을 외치며 나아가는 토마스 웨이드.

삼체인들도 혀를 내두르며 이리 같은 남자라며 진절머리치는 이 인물은, 우리와는 다르기에 또 동경심과 매력을 주는 캐릭터다. 우리가 하지 못하는 선택과 정면돌파를 척척 해내는 인물을 보면 괜히 쾌감이 든달까.

하여튼, 사람들 말대로 삼체는 개쩌는 소설이다.

🥜 AI 오케스트레이터라는 환상

Mon, 11 May 2026 12:00:00 GMT

"이제 코딩은 AI 가 한다. 사람은 오케스트레이터이다"라는 환상?

'감독의 역설'이라는 말이 있다. AI 를 감독하려면 코딩을 할 줄 알아야 한다. Anthropic 이 직접 발표한 자체 연구 내용이다.

코딩 에이전트를 효과적으로 관리하는 데 필요한 바로 그 비판적 사고 능력이, 코딩 에이전트 사용 때문에 잠식되고 있다는 것.

인지 부채와 기술 퇴화는 이미 측정되고 있다.

AI 가 만들어 주는 생산성으로 당신은 더 똑똑해지고 있다고 느끼는가?

Anthropic 자체 연구: 개발자 디버깅 능력 47% 급락
30년차 시니어 Simon Willison: "애플리케이션의 멘탈 모델이 사라지고 있다"
LinkedIn 엔지니어링 50명 총괄 디렉터 Sandor Nyako 의 팀 지시: "비판적 사고가 필요한 작업에는 AI 툴을 사용하지 말라"

C++ 에서 Java 로 옮길 때 뇌 안개를 호소한 사람은 없었다. 시스템 관리자가 AWS 로 가도 네트워킹 이해를 잃지 않았다.

오케스트레이터, 더 높은 추상화, 개발자의 감독 역할 — 모두 환상이다.

코드를 못 읽으면 CTO 일 수 없고, 직접 짜보지 않으면 아키텍처를 설계할 수 없다.

(CTO 로 있으면서 코드를 보지 않았던 기간이 있었고 나는 개발자들에게 CTO 를 뽑아달라는 얘기를 들었다.)

스펙 주도 개발도 환상에 가깝다.

스펙은 개발의 시작점이지 도착점이 아니다. 코드 구현과 아키텍처는 복리 구조다. 누적된 컨텍스트에서, 즉 코드를 짜는 중간에 정해질 수밖에 없다.

AI 가 코드를 작성하는 걸 잘 지켜보라. 스펙과 결과물은 절대 100% 동일하지 않다.

언어는 당신의 생각을 부분적으로만 표현하는 표상이다. 그 불완전한 정보의 빈틈을 AI 는 확률 모델로 레버를 당겨 메운다. 어쩌다 내 생각과 맞으면 가챠 성공, 아니면 계속 확률 레버를 돌린다. 그게 지금 우리가 하고 있는 일의 실상이다.

더 높은 수준의 모호성은 더 높은 수준의 추상화가 아니다.

"지금 AI 에이전트에 올인하는 사람들은 스스로 퇴물이 되는 길을 보장하는 것이다. 생각을 컴퓨터에 아웃소싱하면, 기술 향상, 학습, 더 유능해지는 것을 멈추게 된다."

— Jeremy Howard, fast.ai 창설자

관련 글

🥜 에이전트 코딩은 함정이다 (Agentic Coding is a Trap)

Mon, 11 May 2026 11:30:00 GMT

"AI가 코딩하고 사람은 오케스트레이터"라는 산업 내러티브에 대한 정면 반박 — 인지 부채와 기술 퇴화는 이미 측정되고 있다

15년차 개발자 Lars Faye가 쓴 글. SDD(Spec Driven Development) / 오케스트레이션 워크플로우가 미래라는 현재의 과대 선전이 이미 측정 가능한 트레이드오프를 만들고 있다는 주장
글의 핵심 명제: 코딩 에이전트를 효과적으로 관리하는 데 필요한 바로 그 비판적 사고 능력이 AI 툴링 자체에 의해 잠식되고 있다는 것이 이미 증명되었다. 이는 자기 모순적 시스템이다
저자가 제시하는 정량 가능한 4가지 트레이드오프: ① AI 비결정성을 완화하려는 주변 시스템 복잡도 증가, ② 광범위한 인구의 기술 퇴화, ③ 개인·팀 단위 벤더 종속(Claude 장애 시 팀 마비 사례 다수), ④ 토큰 비용 변동성(고정된 인건비 대비 끊임없이 움직이는 타겟)

"또 다른 추상화일 뿐"이라는 반론에 대한 반박 — 이번엔 데이터가 있다

커뮤니티에서 자주 듣는 변호: "프로그래머들이 스택 위로 이동하며 더 높은 추상화로 진입하고 있을 뿐". 저자 반박: 더 높은 수준의 모호성은 더 높은 수준의 추상화가 아니다
FORTRAN 출시 시 비판("어셈블리가 더 효율적"), 컴파일러 도입 시 비판("마법 과다") 모두 추측적·이론적 두려움이었음. 반면 오늘의 AI 비판은 불과 몇 년 만에 측정 가능한 영향이 데이터로 나오고 있다
C++ → Java 전환자가 뇌 안개를 호소하지 않았고, 시스템 관리자가 AWS 가서 네트워킹 이해를 잃지 않았다. 코드 마찰을 거치지 않은 사람이 시니어 워크플로우로 점프하는 트렌드는 역사적으로 처음
Simon Willison — 약 30년 경력의 시니어 — 도 자기 고백: "애플리케이션이 무엇을 할 수 있고 어떻게 작동하는지에 대한 확고한 멘탈 모델이 사라지고 있으며, 그로 인해 추가적인 기능을 추론하기가 점점 더 어려워지고 있다"

Anthropic 의 "감독의 역설"(Supervision Paradox) — 모델 제공자 본인이 인정한 모순

최근 Anthropic 연구 인용: "코딩 기술 퇴화가 우려되는 한 가지 이유는 '감독의 역설'이다. Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 AI 과다 사용으로 인해 퇴화할 수 있는 바로 그 코딩 기술이 필요하다."
50명을 총괄하는 LinkedIn 엔지니어링 디렉터 Sandor Nyako가 팀에 내린 지시: "비판적 사고나 문제 해결이 필요한 작업에는 AI 툴을 사용하지 말라." 이유: "AI가 정확하지 않을 경우 어떻게 의문을 가질 수 있겠는가, 비판적 사고 능력이 없다면?"
별도 Anthropic 연구: 디버깅 능력이 47% 급락했다는 측정 결과. "개발자들은 중요한 기술, 특히 문제가 생겼을 때 디버그하는 능력을 키우는 것보다 빠른 결과를 제공하기 위해 AI에 의존할 수 있다."
무엇이 "과다 사용"인지의 임계점은 아직 불명확하지만, 이런 기술들이 몇 달 안에 퇴화할 수 있다는 일화적·데이터 기반 증거가 이미 누적 중

LLM은 잘못된 부분을 가속한다 — 우선순위 목록이 뒤집힌다

AI 이전 (좋은) 개발자의 우선순위 ① 코드와 코드베이스와의 이해 → ② 문서화된 효율적 기준 부합 → ③ 가독성 유지하며 최소 코드 줄 수 → ④ 처리 시간
에이전트 코딩은 이 순서를 정반대로 뒤집어, 지정된 시간 내에 생성할 수 있는 코드의 양(속도)에 집중시킨다
저자의 핵심 통찰: 속도는 높은 적성의 자연스러운 부산물이다. 강제될 때 그것은 항상 낮은 정확도로 이어진다. 깊은 이해나 간결함에는 통합이 집중하지 않는다
가능한가? 결단력이 있다면 가능. 현재 그렇게 사용되는가? 아니다 — 조직 전반의 강제적 토큰 소비 의무화와 과대 선전이 정반대 방향을 가리키고 있다

"코딩 === 계획 수립" — 코드로 사고하는 사람의 입장

모든 사람이 스펙을 먼저 쓰고 코드를 나중에 쓰는 게 아니다. 일부 개발자에게 코드 작성 자체가 사고 과정이다. OpenCode 창작자 Dax 인터뷰 인용:

"새롭거나 도전적인 것을 작업할 때, 내가 코드를 타이핑하는 것 자체가 우리가 무엇을 해야 할지 파악하는 과정이다. (...) 나는 타입을 작성하는 것을 좋아한다. 일부 함수들이 어떻게 함께 작동할지 적어보는 것을 좋아한다. (...) 그게 내가 무엇을 해야 할지 파악하는 방식이기 때문이다."
코드 작성은 보안·성능·UX·유지보수 모두를 동시에 강제로 고민하게 만든다. SDD는 이 사고 통로를 외부화·생략한다
LLM의 비결정성 문제: "당신이 말하는 것이 항상 당신이 의미하는 것과 일치하지 않으며, LLM은 모호성을 가정(또는 환각)으로 채운다." 더 많은 검토 → 더 많은 에이전트 수정 → 더 많은 토큰 → 결과물로부터의 더 큰 단절
핵심: "결정론적 시스템을 확률론적 시스템으로 대체하고 모호성이 제로가 되기를 기대할 수는 없다." LLM은 컴파일러가 아니라 다음 토큰 예측 엔진

벤더 종속과 토큰 비용 — 키보드 한 대로 가능했던 일이 구독 의존으로

Claude 장애 직후 LinkedIn에 "팀이 완전히 정지됐다"는 게시물 다수. 키보드와 텍스트 에디터만으로 실행할 수 있었던 기술이 갑자기 AI 모델 제공업체 구독을 필요로 하게 된 상태
모델 제공업체는 막대한 보조금을 받고 있으며, 모델 자체도 불안정. 새 모델 릴리스 패턴: 높은 벤치마크 → 과대 선전 → 실사용에서 "너프됐다"는 불평 → 같은 작업에 2~3배 토큰 소모
직원 비용은 알 수 있지만, 토큰 비용이 하루·달·해 단위로 얼마가 될지는 전혀 알 수 없다. ThePrimeagen: "이런 완전한 에이전트 워크플로우를 사용할 때, 모델 제공업체들이 사실상 당신을 소유하게 된다"
시나리오: 업계 전체의 기술셋이 벤더에 종속되어, 과거 자신의 비판적 사고와 문제 해결로 달성했던 것을 이제는 토큰 소비로 사야 하는 구조. 금전적·지적 러그풀은 언제든 가능하고, 로컬 LLM은 그 수준의 사용을 아직 흡수 불가

저자의 처방: AI를 강등시켜라 — 함선의 컴퓨터처럼 쓰지, Data처럼이 아니라

저자는 수동 타이핑을 옹호하지 않음. Emmet, 자동완성, 스니펫, jQuery "write less, do more", COBOL의 "영어 같은" 명령어 모두 코드 작성을 줄이려는 역사적 시도. LLM은 그 도구 배열의 새 멤버
그러나 LLM을 보조 프로세스로 두고 인간이 구현에 적극 참여하는 워크플로우의 역전이 필요. 위임 가능한 부분만 위임하고, 이해 부채를 적극 차단
저자의 일상 워크플로우:
- 스펙·계획 생성은 LLM 활용, 구현은 직접 진행. 작업에 따라 직접 코딩 비율 20~100%
- 모델 협업 시 의사 코드(pseudo-code)를 작성해 요청과 생성 코드 사이 거리를 좁힘
- 모델을 즉석 코드 생성·인터랙티브 문서화 위임 유틸, 그리고 자기 접근에 대해 끊임없이 질문·반복·리팩토링·명확화하는 연구 도구로 사용
- 한 자리에서 검토할 수 있는 양보다 더 많이 생성하지 않는다. 너무 많으면 속도를 줄이고 분할
- 자기가 직접 해본 적 없거나 혼자서 할 수 없는 것을 LLM에 구현시키지 않는다 (순수 교육·튜토리얼 목적은 예외, 나중에 버림)
한 줄 요약: "함선의 컴퓨터처럼 사용하라, Data처럼이 아니라" (스타 트렉 레퍼런스 — 명령에 응답하는 도구 vs 자율적 동료)

결론: 우리는 더 위험한 실험을 하고 있다

코딩 민주화 시도가 반복적으로 실패한 이유: 코드와 참여하지 않고서는 코드를 이해할 수 없다는 현실. 코드를 계속 참여하지 않으면 이해와의 접촉이 끊긴다. 끊기면 처음부터 덜 유능한 오케스트레이터가 된다
소셜 미디어 도입 시 장기 영향을 이해하지 못한 채 도입했고, 이제 광범위한 주의력 결핍에 직면. 이번엔 더 위험한 것을 도박 중
마무리 인용 — fast.ai 창설자 Jeremy Howard:

"지금 AI 에이전트에 올인하는 사람들은 스스로 퇴물이 되는 길을 보장하는 것이다. 생각을 컴퓨터에 아웃소싱하면, 기술 향상, 학습, 더 유능해지는 것을 멈추게 된다."

🔗 메타데이터

원문: https://larsfaye.com/articles/agentic-coding-is-a-trap
저자: Lars Faye
번역·요약: Tony (flowkater) — 2026-05-11
태그: #AI #에이전트코딩 #SDD #개발자 #벤더종속 #인지부채
관련 글(국내):
- AI 오케스트레이터라는 환상 — 이 글에서 출발한 토니의 단정과 가챠 비유
- AI는 코드를 쓴다. 결정도 한다. 책임만 못 진다. — AI가 흡수하는 것은 코드가 아니라 책임 회피의 안전지대
- AI Native Engineer — 원리 위의 감각 — Taste·결정 능력의 안전지대 한계
- 조직에 Claude Code를 설치한다고 AX가 되지 않는다 — 도구 설치 vs 구조 변화

🥜 왜 Anthropic은 SpaceX와 손을 잡았나?

Fri, 08 May 2026 10:30:00 GMT

Anthropic이 SpaceX/XAI와 컴퓨트 공급 계약을 체결했다.

불과 몇 달 전만 해도 Anthropic은 XAI 직원들의 Claude 모델 사용을 차단했고, Elon Musk는 Claude를 두고 "misanthropic(반인류적)"이라며 수십 차례 비판해왔다. 그런 두 회사가 손을 잡았다.

이유는 단순하다. 컴퓨트 위기.

Anthropic은 2025년 1분기에 연환산 80배 성장을 기록했다. 계획은 10배였다. CEO Dario Amodei가 직접 "컴퓨트 부족으로 서비스 운영에 차질이 생겼다"고 공개적으로 인정한 이례적 상황이다. Claude Code를 Pro 플랜에서 잠시 빼려 한 것도 매출이 아니라 컴퓨트 확보가 진짜 목적이었다.

지금 AI 업계는 세 가지 자원 게임이다. 연구(Research) · 데이터(Data) · 컴퓨트(Compute). 세 박자를 모두 가진 건 OpenAI 하나뿐이다.

Anthropic: 연구·데이터는 톱이지만 컴퓨트가 부족하다.
XAI: 컴퓨트는 넘치지만 연구·데이터가 부족하다. 그래서 Cursor에 $10B(데이터만) 또는 $60B(전사) 인수 제안을 던졌다.
Google: 셋 다 있지만 쓸만한 제품을 못 만든다.

SpaceX의 Colossus 1은 442MW, H100 약 28만 개 규모다. 이 중 300MW(약 70%)를 Anthropic에 넘긴다. 정작 XAI가 Grok 추론에 쓰는 건 100MW에 불과하다. Grok을 쓰는 사람이 거의 없기 때문이다. SpaceX는 이미 학습(Training)을 1.5GW의 Colossus 2로 이전했고, Colossus 1은 사실상 잉여 자원이 됐다.

미판매 컴퓨트는 시간이 지나면 소멸하는 자원이다. Elon은 너무 일찍·너무 많이 샀고, Anthropic은 너무 늦게·너무 적게 샀다. 매치 메이드 인 헤븐.

이 딜이 사용자에게 미치는 영향은 실질적이다. Claude Code의 5시간 사용량 제한이 대폭 완화된다. Tier 3 기준 시간당 800k → 5M 토큰, Tier 2는 450k → 2M 토큰으로 늘어난다.

한편 Anthropic의 진입장벽은 빠르게 무너지고 있다. OpenAI가 곧 AWS Bedrock에 올라온다. Anthropic이 누려온 클라우드 독점 시대의 종말이다. OpenAI Codex의 폭발적 성장으로 코딩 영역의 우위도 빠르게 좁혀지고 있다.

이념보다 컴퓨트가 우선인 시대다. 적의 적이 컴퓨트를 가지고 있다면, 손을 잡는다.

🥜 AX 이후의 일과 조직구조

Thu, 07 May 2026 02:35:00 GMT

"AX는 0에서 1을 만드는 변화가 아니라, 노동의 거품을 걷어내고 본질적인 제자리를 찾는 과정입니다."

RecruitFirst Korea가 준비한 〈AX 이후의 일과 조직구조〉 인터뷰 시리즈 두 번째 편에 제 인터뷰가 발행됐습니다.

아젠다는 셋입니다.

1. 본질로의 회귀 — 기술 스킬을 익히는 게 목표가 되어선 안 됩니다. 모든 구성원이 자기 업무가 비즈니스 목표와 고객에게 전달되는 진짜 가치에 어떻게 정렬되는지 고민해야 합니다.

2. 분절된 R&R의 종말 — 부서 간의 벽이 책임의 흐름을 잘라냅니다. AI를 통해 한 사람이 전체 비즈니스 맥락을 파악할 수 있게 된 만큼, 직무 중심의 분업이 아닌 고객 여정을 통째로 책임지는 미션 단위의 조직 운영이 필요합니다.

3. 생산 중독 경계 — 노동의 총량이나 바쁜 느낌에 취해 '열심히 하는 척'하는 건 위험합니다. AI를 활용해 곁가지 일을 덜어내고, 인간만이 할 수 있는 진짜 일에 몰입하는 소수 정예 조직의 생존 조건.

전문 보기 →

🥜 철이 들수록, 당신이 사라진다

Thu, 07 May 2026 00:00:00 GMT

철이 들수록, 당신은 사라진다.

사회성을 잘 갖춘 사람은 정말 혁신할 수 없는 걸까?

내 직관이 "이건 좀 다른데"라고 말하는데도 어김없이 고개를 끄덕인 순간이 있다. 나도 그렇게 자주 끄덕인다. 매번 끄덕이다 보면, 만들고 싶었던 미래는 사라지고 누군가 듣고 싶어 하는 이야기만 남는다. 어른이 되어간다는 건 자기 안의 가장 거친 부분을 차곡차곡 잘라내는 일이다.

예전에 일론 머스크 책을 읽고 정리한 글이 있다. 거기 이런 문장을 옮겨 적었다.

"때때로 위대한 혁신가들은 배변 훈련을 거부하고 리스크를 자청하는 어른아이일 수 있다. 무모하고, 사람을 당황하게 만들고, 때로는 해를 끼칠 수도 있다. 그리고 미치광이일 수도 있다. 자신이 세상을 바꿀 수 있다고 믿을 만큼 미친 사람."

거친 표현이다. 그런데 이 거친 표현이 가리키는 게 있다. 어른의 매끈함을 갖추는 동안 같이 죽는 게 있다는 것.

마이크 메이플스 주니어는 《패턴 파괴자들》에서 답한다. 우리가 사회에 순응하도록 설계된 건 의지의 문제가 아니라 인간의 기본값이라고.

"가족, 학교, 또래, 미디어는 우리가 무엇을 욕망하고 어떻게 행동해야 하는지 계속 가르친다. 생물학적으로도 우리는 또래의 인정을 구하도록 설계되어 있다. 거절은 아프고, 대세를 따르는 편이 인지적으로 덜 피곤하다."

순응은 약한 사람의 문제가 아니다. 그래서 자기도 모르게 빠진다. 신호는 이렇다.

"주변 사람들이 다 동의하니까" 자기 직관을 접는다.
"남들도 다 그렇게 하니까" 같은 길을 간다.
"상대가 원한다고 했으니까" 검증 없이 따른다.
"분위기 깨기 싫어서" 중요한 반대를 삼킨다.
"이 분야에서는 원래 이렇게 하니까" 자기 메시지를 바꾼다.

다섯 줄 중 한 번이라도 자기 모습이 보였다면, 당신은 평범한 사람이다. 모두가 이렇게 산다. 나도 자주 이 다섯 줄 안에서 산다.

미치광이가 되라는 말이 아니다. 반항적인 척하라는 것도, 사람을 함부로 대하라는 것도 아니다. 다른 사람 기준에 맞추느라 자기가 원래 들고 있던 게 뭐였는지 잊지는 말자는 거다. 자기 기준과 충돌하는 순간에는 NO라고 말할 수 있어야 한다. NO는 사람을 밀어내는 말이 아니다. 자기가 만들고 싶었던 걸 끝까지 만들기 위해 들고 있는 거의 유일한 도구다.

무서운 건 그다음이다. 그 한계가 자기 사고방식 안에 너무 깊이 박혀 있어서, 자기는 그게 한계인지도 모른 채 산다는 점.

"가장 근본적인 한계는 타인의 규칙을 기준삼아 자신의 성공을 정의하는 것이다."

AI는 코드를 쓴다. 결정도 한다. 책임만 못 진다.

Tony Cho (https://flowkater.io) — Mon, 04 May 2026 13:00:00 GMT

들어가며

얼마 전 개발자 한 분이 본인 커리어에 대한 어려움을 토로했다. 내가 이전 회사에 신입으로 채용했던, 이제는 4년차 백엔드 개발자였다. 나보다 먼저 퇴사를 했기에, 이왕이면 즐겁게 일했으면 하는 진심으로 이런저런 조언을 드리려고 했다.

그분의 말은 이랬다. 본인이 회사에서 진행한 프로젝트에 최선을 다하고 나름 그 안에서 성장도 하고 있었는데, 갑자기 해당 프로젝트가 엎어지면서 개발팀 내부 구조조정이 필요하다고 했다고 한다. 원인은 경영진의 사업 판단 실패에 있지만 AI라는 핑계 (생산성 최적화, 비용 최적화)로 책임은 그저 열심히 최선을 다했던 직원들이 지게 생겼다는 거다. 팀장이 어떻게든 그 사태를 막기 위해 새 프로젝트를 기획해서 상황을 모면하고, AI를 활용해서 실제 비즈니스 KPI에 기여하는 프로젝트를 부랴부랴 하고 있다고는 하는데, 이 상황 자체가 본인은 억울하고 앞으로 어떻게 해야할지 고민이 된다는 것이었다.

"아니, 저는 진짜 최선을 다했는데 프로젝트가 수익화에 실패했다고 갑자기 구조조정을 한다는 거에요. 어이가 없습니다. 전 사실 AI에 크게 관심있는 개발자가 아닌데, 지금 하네스를 만들어야 한다고 해서 그걸 하고 있어요."

나도 참 고약한 게, 그냥 한번쯤은 공감하고 조언으로 넘어갈 뻔한데 얘기를 듣자마자 대뜸 가혹한 말을 해버렸다.

"우리 자신의 게으름은 결국 우리 자신이 감당하게 된다. 본인도 아시잖아요?"

그리고 곧바로,

"월급 받는 직원이 본인에게 주어진 일만 하면 된다는 그런 순진한 생각은 이제 버리셔야 돼요."

사실 이 말을 하면서 제일 먼저 떠오른 건 그분이 아니라 나였다. 이전 직장에서의 나. 같은 회사에서 다른 위치에 있던 두 사람 (그분은 주니어, 나는 CTO)이 그 시기에 같이 겪었던 어려움에 공감대가 있었다. 그분을 꾸짖은 게 아니다. 내가 뒤늦게 배운 교훈을, 너무 거칠게 꺼낸 셈이다.

여기서 한 가지는 분명히 해두자. 구조조정의 책임이 개인에게 있다는 말은 아니다. 사업 판단을 틀린 건 경영진이고, 그 비용을 직원이 감당하는 건 분명 개인 입장에서 가혹하다. 다만, 커리어의 안전을 경영진의 판단과 회사의 선의에 맡겨두는 것도 더 이상 안전하지 않다는 말 이다.

그렇게 내가 차근차근 설명하니 그분도 점차 고개를 끄덕이셨다.

AI가 원인처럼 보이지만, 사실 이 변화는 이미 시작됐다

AI 시대에 커리어를 고민하는 사람은 나도 포함해서 이 분만은 아닐 것이다. 최근의 일자리 위협은 더 이상 개발자들만의 고민도 아닌 것 같다. AI가 발전함에 따라 개발자 시장이 제일 먼저 칼바람을 맞았고, 그걸 지켜보던 다른 직무의 사람들이 느끼는 커리어적 위기감은 우리 모두를 옥죄고 있다.

코로나 전후로 스타트업씬엔 자금이 넘쳐 흘렀고, 수익보다는 적자를 내도 트래픽 성장이 트렌드였던 시기. 개발자 초봉 6,000만원 기사가 나며 개발자들을 귀한 손님 모셔가는 (그렇게 귀하지 않은 개발자들 포함) 현상이 일어났다. 부트캠프만 나오면 웬만한 스타트업 입사가 가능했고, 투자를 받아 현금이 있는 회사들은 사람을 급격하게 늘렸다. 그러다 시장에 자금이 마르자, 과채용된 인원과 망한 회사 출신 인력들이 쏟아져 나왔다.

23년에 채용 인터뷰를 하면서 그 광경을 직접 봤다. 잘나가던 스타트업이 하루 아침에 대금 납부 불능, 임금 체불에 빠졌고, 지원자들 중 소위 "망한" 회사 출신이 꽤 있었다.

지금의 냉랭한 채용 분위기가 AI 때문이라고 생각하는 사람들이 많지만, 글쎄. 모든 현상은 인과관계를 조금 더 들여다 볼 필요가 있다. 더 근본적인 이유는 여전히 그 시기에 얼어붙은 스타트업 투자 시장과, 회사들이 망하면서 생존한 회사들의 치열한 인재 검증과 비용 최적화의 이유가 더 크지 않을까 싶다. 분위기에 휩쓸리듯 과채용으로 피를 본 회사들이 "정말로 개발자가 그만큼 필요했나"라는 빨간약을 먹은 것뿐이다. 그때 망한 회사들은 사업을 사업으로 대하지 않았다는 것이 드러난 것이고, 구조조정을 단행한 회사들은 빨리 정신 차려서 원래 궤도로 다시 돌아온 회사들인 것이다. 개인의 입장에서 구조조정은 가혹하지만, 기업 입장에서는 빠르면 빠를수록 좋을 결정이었다.

숫자로 봐도 이 변화는 AI 이전에 이미 시작됐다. 금융위 자료에 따르면 2023년 상반기 국내 벤처투자는 전년 동기 대비 42% 줄었고, 스타트업얼라이언스 집계에서도 2023년 전체 스타트업 투자금이 전년 대비 52%가량 감소했다. 2021~2022년의 채용 호황은 코로나 이후 유동성 과잉이 만든 예외적인 구간에 가까웠고, 2023년의 냉각은 그 예외가 끝난 뒤 찾아온 정상화에 가까웠다. 그러니 지금의 채용 한파를 AI 하나로 설명하는 건 순서를 거꾸로 읽는 일일 수 있다.

AI가 개발자 시장을 갑자기 망가뜨린 게 아니다. AI는 이미 무너지고 있던 고용 계약의 민낯을 더 빨리 드러낸 것뿐이다.

누구 잘못일까? 내 생각엔 그저 각 시점에 각자가 했던 역할에서 최선을 다했을 뿐이다. VC는 남아도는 펀드를 투자해야 했고, 경영진은 기회가 될 때 최대한 투자를 받아야 했다. 시장 분위기는 너도나도 과채용을 하며 성장을 부르짖던 시기였고, 부트캠프는 그 수요에 맞춰 비전공자 출신 개발자들을 대거 양성했다. 다만 가장 안일했던 사람은 당시 회사들의 경영진이라고 본다. 결국 그들의 사업 실패가 시장이 얼자마자 고스란히 개인 직원들이 대가를 치르게 되었다.

R&R의 시대, 스페셜리스트의 시대

당시 몇몇 지원자들과 인터뷰를 들어가 보면, 그들은 본인에게 주어진 역할과 직무에서는 최선을 다했지만 경영진의 오판과 수익화 실패, 추가 투자 유치 실패 등으로 어쩔 수 없이 퇴사하게 되었다는 말을 공통적으로 하고 있었다. 맞는 말이다. 나같아도 그렇게 말했을 것이다.

특히 한 시리즈 C 스타트업에서 구조조정된 어느 한 지원자는 이렇게 말했다.

"저는 제 직무에서 최선을 다했습니다. 깊이 있는 테크 스택을 다루기도 했고, 팀원들의 코드 리뷰도 적극적으로 하는 편이었습니다. 하지만 그렇게 개발했던 프로젝트가 정리가 되었고, 저희 팀은 1순위 구조조정 대상이 되었습니다. 조금 더 열심히 했으면 남지 않았을까 라는 고민을 많이 했었고, 제가 QA를 가끔 누락하는 실수를 해서 피드백 받은 적이 있었습니다. 그런 부분이 조금 제 약점이었고, 저는 그 부분을 보완하기 위해 시스템을 만들어서 자동화하고, 제 스스로도 체크리스트를 만들어서 항상 꼼꼼하게 체크하려고 노력했습니다."

이 정도면 훌륭하다. 구조조정이 그분의 문제는 아니었다. 약점을 발견했을 때 시스템으로 메우고 체크리스트까지 만든 사람이다. 직무 안에서 할 수 있는 모든 것을 했다.

문제는 그 말이 틀렸다는 게 아니다. 문제는 그 말이 더 이상 충분하지 않다는 것이다.

기존의 직업은 직무를 명확히 한다. 특히 스타트업 씬에서는 직무에 집중하지 못하고 잡부가 되는 것을 경계하는 조언이 많다. 이건 개인을 넘어 조직 간의 소통에서도 드러난다. 기능 조직 단위로 분리되어 일하는 많은 기업에서 조직 간의 책임 떠넘기기, "그건 저희 R&R이 아닌데요"라는 문장을 수시로 듣게 된다.

CTO 시절 어느 밤이 기억난다. 주니어와 시니어가 같이 결과물을 만드는 프로젝트였고, 나도 같이 밤늦게까지 업무를 진행했다. 그 시니어와 둘이 남아 결과물을 보며 부족한 부분을 지적하자, 대뜸 이렇게 답했다.

"그건 제 R&R이 아닌데요. 주니어가 했던 부분이라 저는 잘 몰라요."

속으로 신경질이 났다. 틀린 말은 아니다. 분명 그 부분은 주니어가 짠 코드였다. 하지만 내가 시니어에게 기대했던 역할은 책임이었다. 그 사람에게는 두 번 다시 책임을 부여하는 자리에 대한 역할을 주면 안 되겠다고 결정한 날이기도 했다.

물론 나도 그렇게 일했던 시기가 있다. 처음 1년을 그렇게 일했다. 외부인으로서 잠깐 도와주는 입장이라고 생각하며 임시 계약직으로 일을 시작했고, 사실 회사가 어떻게 돌아가는지, 고객 가치에 대한 깊은 관심보다 1년 안에 주어진 프로젝트를 끝마치는 게 우선이었다. 그때는 시장이 좋을 때라 사람들을 채용하고 팀을 키우는 데 집중했던 것 같다. 내가 그때 조금 더 책임을 가지려고 했으면 어땠을까? 아이러니하게도 내가 조금 더 비즈니스 가치에 관심을 두었더라면 더 제대로 일했을 것이라는 생각도 있고, 동시에 더 빨리 퇴사했을 수도 있었겠다는 양가적인 관점이 항상 존재한다.

시장에서는 제너럴리스트보다 특정 직무에 특화된 스페셜리스트가 시장에서 선호되어 왔다. 스타트업 씬에서도 대부분의 리더십 레벨에서 그들이 갖지 못한 스페셜리즘에 대한 환상이 항상 존재한다. 나도 그랬고. 나보다 훨씬 깊게 파고드는 실력 있는 개발자들에 대한 동경이 늘 있었다.

다만 분명히 해두자. 내가 본 환상(가짜)은 '스페셜리즘 그 자체'가 아니라 '전문성 뒤에 숨는 태도'였다. 진짜 깊은 전문성을 가진 사람은 자기 결정이 비즈니스에 어떻게 닿는지를 본다. 문제는 자기 관심사에만 파고들면서 어른의 사정 (비즈니스나 고객 가치)은 다른 사람의 영역이라고 미루는 사람들이었다. 한 마음 한 뜻으로 정렬되어 승리를 위해 달려가도 모자랄 판에, 그들을 달래가며 일을 해야 하는 심정이란. 좋아하는 것만 하고 싶어 하는 어린아이의 모습과 같았다.

그리고 사수가 없는 회사에 가면 안 된다고도 조언한다. 직무 성장을 할 수 없기에. 그런데 지금 시장에서 일잘하는 사람을 잘 살펴보면 사수 없이 성장한 사람들이 많다. 사수가 없는 건 원인이라기보다는 그들의 특징 중 하나다. 심지어 AI 시대의 사수의 존재는 내가 의존하게 되는 하나의 블로커가 될 수밖에 없다. 이건 이렇게 해야한다. 저건 저렇게 해야한다. 그런 조언들이 초심자의 발전에 발판을 삼을만 하지만 그들도 AI 시대는 처음이고, 책임을 끝까지 다 한 사람이 적다. 아마 "R&R"을 강조하면서 그런 것까지 하면 안된다고 조언하는 사수들이 많을 것이다. 사수의 조언은 대게 이제 구태의연한 것이 되었다. AI 덕분에 직무에 제한이 없어졌기 때문이다.

하지만 사수의 존재유무보다 더 중요한 팩터는 환경이다. 내가 하는 일이 곧바로 성과로 연결되는 환경. 그리고 내 직무 분야가 아닌 다른 팀원들, 리더십이 성과에 대한 피드백을 충분히 받을 수 있는 환경. (사수의 How to 피드백이 아닌 What, Why를 피드백 받을 수 있는 환경) 당연히 제일 좋은 건 직접 고객을 만나며 비지니스를 하는 거다. 매일매일 바닥을 찍으면서 성적표를 받는 것만큼 빠른 성장의 길도 없다. 개발자라면 필요한 개발을 다 해야 할 거고 PM에 마케팅까지 해야 할 수도 있다. 하지만 그게 일의 본질이다. 진짜 가치를 만들어내는 것.

R&R은 책임을 명확히 하기 위한 도구이지, 책임을 피하기 위한 방패가 아니다.

아직도 "그건 제 R&R이 아닌데요." 라고 생각한다면, 그건 당신의 직업이 앞으로 더 이상 존재하지 않을 가능성이 높다는 말과 같을 수 있다.

AI는 스페셜리즘을 흡수한다

쉽게 말하면, "돈 버는 건 사장님이 알아서 하시겠지, 난 그냥 시키는 것만 열심히 할래" 같은 순진한 생각을 하면서 월급 받는 시대는 이제 끝났다는 얘기다. 스페셜리즘의 대부분을 AI가 흡수했기에, 생산을 넘어서 내가 지금 하고 있는 일이 정말로 실제 가치와 연결되는가를 개인이 고민하지 않으면 더 이상 생존하기 어려운 시대가 되어버렸다. 맞다. 가혹하다. 한낱 월급쟁이가 이제 그런 것까지 고민해야 되나 라고 되물으면, 어쩔 수 없다, 이제 그래야만 살아남는다고 명확히 다시 답해줄 수 있다.

전문성이 필요 없다는 말이 아니다. 오히려 깊은 전문성은 더 중요해진다. 다만, 당신의 그 전문성이 고객 가치와 비즈니스 결과로 연결되지 못하면, AI 시대에 당신은 가장 먼저 정리 대상이 된다.

Meta의 Mark Zuckerberg는 올해 1월 Q4 어닝콜에서 이렇게 말했다.

"We're starting to see projects that used to require big teams now be accomplished by a single very talented person. Our north star is building the best place for individuals to make a massive impact." "예전에는 큰 팀이 필요했던 프로젝트가 이제는 정말로 뛰어난 한 명에 의해 끝나는 모습이 보이기 시작했다. 우리의 북극성은 개인이 거대한 임팩트를 낼 수 있는 최고의 장소를 만드는 것이다."

(Meta Q4 2025 Earnings Call, 2026-01-28)

10명이 하던 일을 한 명이 한다는 건, 단순한 효율의 문제가 아니다. 큰 팀이 나눠 갖던 판단·조율·검증·배포 이후의 책임까지— 그 한 사람에게 압축된다. 산출물이 줄어드는 게 아니라, 한 사람이 짊어지는 무게가 커진다는 뜻이다. 그래서 채용 기준이 quantity(양)에서 quality(질)로 옮겨간다. AI를 도구로 쓸 줄 아는 건 이제 기본값이고, 그 위에서 결과까지 책임질 수 있는가가 진짜 질문이다.

결국 살아남는 건 (제너럴리스트가 아니라) 자기 전문성을 End-to-End 결과와 연결할 수 있는 사람이다. 깊은 전문성이 사라지는 게 아니다. 그 전문성이 비즈니스에 어떻게 기여하고, 고객에게 어떤 가치로 얼마나 전달되는지 치열하게 고민하는 사람. 그게 살아남는다.

Google의 사례는 이 변화를 단적으로 보여준다. Sundar Pichai는 2024년 3분기 어닝콜에서 Google의 새 코드 중 25% 이상이 AI로 생성되고 엔지니어가 검토·승인한다고 밝혔는데, 1년 반 만에 그 비율이 75%까지 올라갔다. 여기서 핵심은 "AI가 코드를 쓴다"가 아니라 "AI-generated and approved by engineers"라는 부분이다. 작성의 중심은 AI로 이동하지만 승인과 책임은 엔지니어에게 남는다는 뜻이다. 코드는 AI가 만들 수 있지만, 그 코드를 제품에 태우고 사고가 나면 설명해야 하는 사람은 여전히 엔지니어다. 개발자의 일은 작성자에서 승인자, 검증자, 오케스트레이터로 이동하고 있다.

AI는 전문성을 없애는 게 아니라, 전문성만 가진 사람의 안전지대를 없애고 있다.

Taste와 결정 능력도 충분하지 않다

"AI가 이런 걸 해주니까 사람은 이런 걸 해야 합니다"라는 프레임워크로 사람의 역할을 설명하는 사람들이 많다. 그들이 말하는 걸 들어보면 대부분 (나도 앞서 강조했던) Taste나 결정 능력 같은 것을 얘기한다. 근데 이건 AI와 사람을 동일선상에 두고 비교하는 프레임이다.

그 말은 곧, Taste나 결정도 어느 레벨, 어느 섹터에선 충분히 사람 역할을 대체할 수도 있고, 저수준(low-level)에서는 이미 그렇게 되고 있다는 거다.

비슷한 고민을 ThePrimeagen도 했다. 20년차 베테랑 개발자, 6,000일을 프로그래밍하고 14년을 Vim에 바친 사람. 최근 컨퍼런스 발표에서 본인이 6개월간 슬럼프에 빠져 있었다고 고백했다. AI가 코드를 생성하는 시대에 "내 가치는 어디 있는가"를 자문하면서, 그는 두 가설을 차례로 지웠다. 취향(taste)? 아니다. 코드 양? 아니다. 그가 도달한 결론은 다음과 같다:

"한 줄 코드의 비용이 극적으로 떨어졌다면, 올바른 한 줄 코드의 비용은 극적으로 상승한다. 모든 것이 무료가 되면 선택의 폭이 넓어지고, 그때 올바른 선택을 내리는 것이 훨씬 어려워진다." (ThePrimeagen, "I suck", 2026-05-02)

이게 추상적인 논리만은 아니다. 양쪽으로 증거가 있다. GitHub Copilot 실험에서는 AI를 쓴 개발자가 과제를 55.8% 더 빠르게 끝냈고, Microsoft와 Accenture 개발자 현장 연구에서도 주간 pull request 수 증가가 관찰됐다. 반대 방향의 증거도 있다. METR의 2025년 연구에서는 숙련된 오픈소스 개발자들이 자신이 잘 아는 코드베이스에서 AI를 썼을 때 오히려 작업 시간이 19% 늘었다. 이 차이가 중요하다. AI는 산출 비용을 낮추지만, 맥락 이해와 품질 검증, 올바른 선택의 비용까지 자동으로 낮춰주지는 않는다.

Taste가 사라지는 게 아니다. AI가 만든 1,000개의 옵션 중 올바른 하나를 고르는 책임이 더 무거워질 뿐이다.

당장 내가 잘하지 못하는 디자인이나 빠르게 작업해야 하는 프로토타입에서 AI는 내가 세세한 결정을 정해주지 않아도 빠르게 결과물을 만든다. 프로토타이핑하는 데 바이브 코딩을 적극적으로 하자는 얘기는 이제 AI에 회의적인 사람들도 부정하지 못할 것이다. 지금은 프로토타이핑 수준에서의 Taste, 결정이지만, 충분한 도메인 데이터와 에이전트가 발전하면 더 높은 수준으로도 가능할 것이라고 본다.

간단한 프롬프트 한 줄로 MVP 정도는 바이브 코딩으로 코드 없이 던지는 정도의 작업, 그 안에 생각보다 많은 Taste (물론 평균의 확률이지만)와 결정이 마이크로하게 들어가 있다. 차원 자체가 아직 작을 뿐이다. 그게 모든 분야에서 모두 고도화되긴 힘들겠지만, 특정 분야나 내가 잘하지 못하는 분야에서는 충분히 나의 Taste와 결정이 대체될 수도 있는 것이다.

내 워크플로우에서도 이런 변화가 이미 나타나고 있다. 디자인 시안 한 장을 시작할 때 색상 하나, 레이아웃 하나에 대한 내 결정을 AI에게 맡기는 비중이 점점 늘어난다. 코드 리뷰도 마찬가지다. 예전에는 PR을 내가 한 줄씩 봐야 한다고 생각했는데, 지금은 1차 리뷰를 AI가 맡는다. 잡아내는 깊이가 내가 처음 한 번 본 것보다 종종 더 낫다. 아키텍처 패턴을 고를 때도 그렇다. 내가 어느 패턴이 좋을지 한참 고민하는 동안, AI는 같은 결정을 빠르게 끝내고 트레이드오프까지 정리해온다. 처음에는 "이건 내가 더 잘하니까 내가 해야지"라고 생각했던 영역들이, 시간이 지나니 "사실 내가 결정하든 AI가 결정하든 결과 차이가 미미하네"로 바뀐다. 차이가 줄어든다는 건 곧, 그 차원에서는 내 Taste가 AI에게 흡수되고 있다는 뜻이다.

사람의 역할을 AI와 기능적으로 비교해서는 안 된다. AI가 못하는 것은 더 예쁜 선택이 아니라, 선택의 결과를 책임지는 것이다.

사람의 역할은 책임이다

사람의 역할은 하나다. AI는 절대 못하는 것. 책임지는 것이다.

AI가 훌륭하게 일을 해내든, 사고를 치든 결국 그 책임은 사람이 지게 되어 있다. 모든 걸 다 가져가도 AI에게 책임을 지우지는 못한다.

이건 추상적인 말이 아니다. Air Canada의 챗봇이 고객에게 잘못된 환불 정보를 제공한 사건이 있었다. 회사는 챗봇을 별도의 주체처럼 보려는 주장을 했지만, 캐나다 분쟁조정기관은 챗봇도 회사 웹사이트의 일부이며, 정보가 정적 페이지에서 나오든 챗봇에서 나오든 그 정보에 대한 책임은 회사에 있다고 판단했다. AI가 답변을 만들 수는 있다. 하지만 그 답변을 고객에게 노출하기로 결정하는 책임은 여전히 사람과 조직에 있다.

최근에 어떤 분과 개발자 채용에 대한 커피챗을 하면서 다시 깨닫게 되었다. "그럼에도 불구하고 사람을 채용하려는 이유가 무엇인가." 결국 그분들이 찾는 사람은 책임질 수 있는 사람, 즉 책임질 수 있다고 신뢰를 주는 사람이었다.

AI가 책임을 못 진다는 건 기술적 한계가 아니다. 본질적 차이다. AI가 더 발전해도 책임은 영원히 사람의 영역이다. AI를 활용해서 작은 성공을 했다고 채용을 늘릴 필요는 없다. 하지만 성공의 크기가 커지면 결국 신뢰할 만한 사람, 책임질 수 있는 사람에게 일을 위임할 것이다.

물론, Taste, 결정, 원리 이해, 커뮤니케이션은 여전히 중요하다. 다만 그것들은 책임을 수행하기 위한 능력이지, 책임의 대체물이 아니다.

나도 2년간 재무 흐름이나 사용자 가치보다, 내 직무인 기술 개발과 주어진 프로젝트에 집중했다. 나의 R&R이 거기 있다고 생각했고, 매달 들어오는 매출과 비용 같은 건 재무팀과 경영진의 영역이라고 생각했다. 2년째 되던 시기에 회사가 한 번 투자 유치에 어려움을 겪었다. 그 광경을 옆에서 보면서 나는 그제서야 재무팀에 가서 매달 정리되는 재무 자료를 보내달라고 했다. 그때 재무팀장이 나를 살짝 의아하게 봤던 표정이 기억난다. CTO가 왜 이걸 이제 와서 보냐는, 그런 표정.

내가 만든 산출물이 회사의 어떤 숫자와 연결되는지, 그게 흔들릴 때 어떻게 흔들리는지를 보지 않고 2년을 일했다. 그 2년의 빈자리가 결국 내 책임이었다는 걸 그제서야 알았다. 기술 결정을 잘했다고 자부했던 시기였는데, 사실은 그 결정이 회사의 어떤 숫자도 책임지지 않는 선택이었다. 좋은 코드를 짜고 좋은 아키텍처를 그렸지만, 그게 회사가 다음 분기를 살아남는 데 어떻게 기여하는지에 대해 나는 무지했다. 무지가 무책임의 다른 이름이라는 걸 그때 깨달았다.

책임지는 사람은 어떤 사람일까. 단순히 주어진 작업을 끝내는 사람이 아닐 것이다. 결과가 고객에게 어떤 가치로 도달하는지를 묻는 사람이다. 그 가치가 회사의 어떤 지표와 연결되는지를 묻는 사람이다. 일이 잘 안 됐을 때 "저는 시킨 대로 했습니다"가 아니라 "제가 무엇을 놓쳤는지"를 설명할 수 있는 사람이다. AI가 만든 결과물을 검토하고, 배포하고, 사고가 나면 수습하는 사람이다.

반대로 책임을 회피하는 사람의 행동 패턴은 이렇다. 본인에게 주어진 R&R에만 최선을 다한다. 비즈니스나 프로젝트의 방향은 다른 파트에서 알아서 정해줄 거라고 생각한다. 비즈니스나 고객 가치, 사용자 시나리오에 관심이 없다. "그래서 이것만 하면 되는 거죠?"라고 묻고, 그 안에서만 산다. outcome(성과)이 안 좋아도 본인의 output(산출물)을 포기할 수 없다. 본인의 output과 본인을 동일시하기 때문이다. "이게 내 작품이다"가 "이게 내 책임이다"보다 앞선다.

한 사람은 회사가 흔들릴 때 자기 위치를 다시 그린다. 다른 한 사람은 흔들려도 R&R 안에 가만히 있다. 시장이 좋을 때는 둘이 똑같아 보인다. 시장이 얼면 그제서야 갈린다. 그 시기가 바로 23년이었고, 그 시기가 (어쩌면 더 가속화된 형태로) 다시 지금이다.

R&R은 종말을 맞은 게 아니다. 직무는 사라지지 않는다. 다만, 내 직무가 End-to-End로 비즈니스에 어떻게 기여하고 고객에게 어떤 가치로 얼마나 전달되는지 치열하게 고민하고, 그 책임까지 지려고 하지 않는다면, 이제 당신의 스페셜리즘은 AI에게 흡수될 것이다.

그래서 개인은 무엇을 해야 하는가

자기에게 던져볼 질문 다섯 개.

1. 내가 지금 하는 일이 어떤 고객 문제를 해결하는가? 가장 기본이고 가장 자주 막힌다. 답을 못하면 내 일은 회사 내부에서만 의미가 있는 일이 된다. 외부 고객의 어떤 결핍과도 연결되지 않은 일은 시장이 어려워질 때 가장 먼저 정리된다.

2. 이 일이 어떤 비즈니스 KPI와 연결되는가? 한 단계 더 들어가는 질문. 내 일이 매출, 비용, 리텐션, 어느 숫자를 어떻게 움직이는지 한 줄로 설명할 수 있어야 한다. 못 한다면, 그건 회사가 내 자리를 어떻게 평가할지 모른다는 뜻이다.

3. 내가 만든 결과가 실제로 쓰였는가, 그리고 그게 실패했을 때 원인을 3문장으로 설명할 수 있는가? 배포한 게 아니라 쓰인 것. 만든 게 아니라 도달한 것. 그리고 잘 안 됐을 때 그 원인이 남 탓 없이 3문장으로 정리되면, 그게 다음 결정의 변수가 된다. 안 되면 그저 운 나쁜 사건으로 남는다.

4. AI를 써서 더 많이 만드는 것보다, 더 빨리 검증하고 있는가? AI 시대의 가장 큰 함정. AI는 산출물을 폭발적으로 늘려주고, 그래서 검증 없는 산출물도 같이 폭증한다. 책임지는 사람은 양이 아니라 검증의 속도에 자원을 쓴다.

5. 내 직무의 경계 밖이지만 결과에 중요한 일을 회피하고 있지는 않은가? "그건 내 R&R이 아닌데요"의 변종. 결과에 중요한데 내 직무가 아니라는 이유로 손을 떼는 순간, 그 결과의 책임도 같이 떨어져 나간다.

내가 가장 자주 던지는 질문은 위의 첫 두 개다. "내가 지금 하는 일이 어떤 고객 문제를 해결하는가, 그리고 이 일이 어떤 비즈니스 KPI와 연결되는가." 이 두 질문에 답이 막히면, 그 일은 내가 책임지지 못하는 일이다. 그러면, 일을 멈추거나, 답을 찾거나, 둘 중 하나를 해야 한다. 어느 쪽이든 그게 책임이다.

산출물 생산자에서 결과 책임자로, Maker에서 Closer로 자리를 옮겨야 하는 시대다. 이전 글에서 말한 Maker→Closer가 그 얘기다. 도구는 모든 사람이 쓴다. 다만 그 도구로 만든 결과를 끝까지 짊어지는 사람과, 도구를 잘 썼다는 사실에서 멈추는 사람의 거리가 점점 벌어진다.

마무리

이 글에서는 오로지 개인의 관점에서 우리가 AI 시대에 어떤 역할로 커리어에 임해야하는가를 논했다. 아마 개인들은 이 글을 읽고나서 이런 의문이 들 것이다. 아니 그렇게 책임을 다하면 뭐하나 수익은 회사가 다 가져가는데. 맞는 말이다. 우리의 생존 커리어와 함께 기업들의 보상 체계도 함께 변하지 않으면 소위 말하는 잡부나 노예로 일하라는 조롱으로 이 글이 변질될 수 있다. 그래서 내 글은 AI 시대에 살아남기 위한 개인의 커리어를 같이 고민하는 글인 동시에 앞으로 인재를 채용해야하는 성장하는 기업 모두를 위한 글이기도 하다. 당신들이 원하는 '책임'을 지는 인재를 원한다면 보상 체계도 그들을 위한 대우도 기존과는 달라야한다. 그런 인재들이 많을수록 당신의 기업은 AI 시대에 발전에 발맞춰 빠르게 성장할 것이다.

책임을 지고 고객 가치를 생각하고 필요한 모든 일을 하는, 제네럴리스트로 일하는 사람들은 어느 시점에 제대로 가치를 평가받지 못했다. 하지만, 스페셜리즘이 AI에게 점점 흡수되고 있는 시대에 그들의 가치는 그 어느 때보다 높다. 지금 스페셜리즘이 모두 사라졌다고 주장하는 것은 아니다. 하지만 그 유통기한이 언제까지 이어질지는 모르겠다.

Anthropic은 채용 페이지에 이렇게 적었다.

"When it comes to our mission, none of us are bystanders. We each take personal ownership over making our mission successful." "우리의 미션 앞에서 우리 중 누구도 방관자가 아니다. 각자가 미션을 성공시키는 데 개인적인 책임을 진다."

(Anthropic Careers)

이건 단순한 슬로건이 아니라, Anthropic이 채용 페이지에서 공개적으로 강조하는 기준이다. 그들이 찾는 사람은 단순히 주어진 일을 잘 수행하는 사람이 아니라, 미션의 성공을 자기 책임으로 받아들이는 사람이다. AI를 가장 잘 만드는 회사가 직접 박은 채용 기준이 ownership이다.

우리 자신의 게으름은 결국 우리 자신이 감당하게 된다. 당신을 진실에서 외면하게 하는 게으른 본성이, 당신의 존재를 위협할 수 있는 시대가 된 것이다.

개인 입장에서는 사실 정말로 어려운 시대이다. 특히 이제 막 커리어를 시작하는 입장에서는 가혹하게 느껴질 수도 있다. 며칠 전 NYT Sunday Opinion에 Jasmine Sun 기자가 이런 한 줄을 적었다.

"Most people I know in the A.I. industry think the median person is screwed, and they have no idea what to do about it." "내가 아는 AI 업계 사람들 대부분은 평범한 사람은 망했다고 생각한다. 그리고 어떻게 해야 할지 전혀 모른다."

(Silicon Valley Is Bracing for a Permanent Underclass, NYT 2026-04-30)

실리콘 밸리는 그동안 rogue AI 같은 거대한 악몽을 경고해왔다. 정작 그들이 마주한 진짜 악몽은, 평범한 사람들이 자동화로 경제적 레버리지를 잃는 시나리오다. AI를 만드는 사람들조차 답을 모른다.

AI 시대에 사람들을 보호하기 위해 노동을 다시 정의하고 기본 소득을 실험하고 정책으로 사람들을 보호해야할까? 모르겠다. 사회적 합의와 논의는 내가 감히 논할만한 주제가 아니라 말을 아끼겠다.

하지만 답이 없다고 손 놓고 있을 수는 없다. 다시 한번 말하지만 기업에서 애초에 그만큼 개인 직원에게 책임을 지우려면 그만큼의 보상도 지불해야 한다. 그게 한 번에 갖춰질 리도 없다. 다만, AI는 본질을 가속화한다. 내가 외면했던 진실을 빨리 마주할수록, 그 다음의 길도 빨라진다. 할 수 있는 일을 하자.

AI는 우리의 일을 대신할 수 있다. 하지만 우리의 책임까지 대신해주지는 않는다. 그래서 AI 시대에 가장 귀한 사람은 더 많이 만드는 사람이 아니라, 끝까지 책임지는 사람이다.

References

금융위원회, "2023년 상반기 벤처투자 동향 보도자료"
Platum, "2023년 스타트업 투자금 52% 감소 (스타트업얼라이언스 집계)"
Google, "Alphabet Q3 2024 Earnings, CEO Sundar Pichai's remarks"
Google, "Cloud Next 2026, Sundar Pichai keynote (75% AI-generated and approved by engineers)"
Meta, "Q4 2025 Earnings Call Transcript (Mark Zuckerberg, 2026-01-28)"
Sida Peng et al., "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (arXiv 2302.06590)"
METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025-07)"
ABA Business Law Today, "BC Tribunal Confirms Companies Remain Liable for Information Provided by AI Chatbot (Moffatt v. Air Canada)"
ThePrimeagen, "I suck (2026-05-02)"
Jasmine Sun, "Silicon Valley Is Bracing for a Permanent Underclass (NYT Opinion, 2026-04-30)"
Anthropic, "Careers (Mission & Values)"
flowkater.io, "AI Native Engineer"
flowkater.io, "조직에 Claude Code를 설치한다고 AX가 되지 않는다"
flowkater.io, "3, 4월 회고 (개발자 채용 커피챗 맥락)"

🥜 당신의 AI 프로젝트가 실패하는 이유

Mon, 04 May 2026 13:00:00 GMT

당신의 프로젝트가 실패하는 이유는 AI 모델이나 하네스 엔지니어링의 문제가 아니다.

이전 시절을 돌아보면, 도구를 먼저 결정한 케이스가 한두 번이 아니었다. Notion을 깔면 지식이 흐를 거라고 생각했고, Slack을 깔면 소통이 빨라질 줄 알았다. 결과는 부서별 위키, 부서별 채널. 도구만 바뀌고 구조는 그대로였다.

지금 AI도 똑같은 길을 가고 있다. 회사들이 Claude Code나 Codex를 도입한다. "이제 우리도 AX가 되겠지" 기대한다. 그런데 실제로 일어나는 건, 그 도구로 옛날 워크플로우를 더 빨리 돌리는 것뿐이다. 멋진 도구로 잘못된 일을 더 빨리 하는 시스템이 된다.

"실행 속도는 한 번도 어려운 부분이었던 적이 없다. 어려웠던 건 '무엇을 만들지'고, 그건 지금도 변하지 않았다. 싸게 만들 수 있어졌기 때문에 발견(discovery)은 덜 중요해진 게 아니라 더 중요해졌다." - Continuous Discovery Habits 저자

빠르게 만들 수 있을수록 무엇을 만들지 결정하는 일이 더 어려워진다. 도구는 그 결정을 대신해 주지 않는다. 제약은 실행이 아니라 방향이다.

데이터도 이미 같은 얘기를 한다. 스탠퍼드 HAI 공동소장은 최근 인터뷰에서 "AI가 전반적 생산성 향상을 제공한 영역은 프로그래밍과 콜센터뿐"이라고 정리했다. 나머지 직무에서는 의미 있는 향상이 측정되지 않는다. 모델 성능의 한계가 아니라, 적용 영역이 잘못된 결과다.

또 다른 솔직한 고백이 있다. SNS에 "AI 50개로 회사를 돌린다"고 자랑하던 어느 스타트업 창업자는 인터뷰에서 직접 말했다.

"50개는 거짓이다. 실제로 작동하는 건 5개고, 나머지는 데모용이다."

이건 그 회사 한 곳의 문제가 아니다. SNS에서 매일 보는 "AI 자동화 워크플로우 N개" 캡처들 대부분이 같은 구조다. 데모는 화려하지만 실제 production에서 매일 도는 건 그 중 일부뿐이다.

실패하는 AI 프로젝트들의 공통 패턴은 결국 단순하다.

문제를 정의하기 전에 도구를 선택한다
멋있어 보이는 데모를 먼저 만들고 사용 시나리오는 나중에 끼워맞춘다
데이터 품질을 무시한다
사람의 일을 통째로 대체할 수 있다고 기대한다
기존 워크플로우 안에 통합되지 않는, 별개의 AI 섬을 만든다

다섯 가지 중 하나만 걸려도 프로젝트는 실패한다. 그리고 보통은 다섯 가지가 한꺼번에 걸린다.

잘못된 문제 정의 위에 AI를 얹으면, AI는 그 잘못을 더 빨리 양산한다.

실패한 건 모델이 아니다. 그 위에 얹힌 결정과 설계가 실패한 거다.

🥜 Claude Code는 어떻게 신뢰를 잃어가고 있는가

Sat, 02 May 2026 07:00:00 GMT

Theo(t3.gg)는 최근 커밋 메시지에 openclaw.inbound_meta.v1 같은 OpenClaw 관련 JSON 조각이 들어간 상태에서 claude -p "hi"를 실행했다. Claude Code가 You're out of extra usage, 즉 추가 사용량 소진 오류를 반환했다. OpenClaw를 사용한 게 아니다. 비어있는 프로젝트 저장소에서 커밋 메시지만 작성한 것이다.

Claude Code 논란을 단순히 "OpenClaw를 막았냐"라는 이슈로 오해할 수 있지만, 핵심은 그것이 아니다. 경쟁사 제품 메시지가 커밋에만 들어간다고 구독 사용이 거부되고 추가 사용량 과금으로 라우팅된 것이다.

AI 에이전트가 저장소, 커밋, 이슈, 내부 문서, CI/CD 까지 읽고 실행하는 시대에, 개발자가 구매한 도구의 실행 조건과 과금 경로를 예측할 수 있느냐는 질문이다.

OpenClaw 뿐일까? Hermes 도 동일한 이슈가 있었다. 대문자 HERMES.md가 최근 깃 커밋 메시지에 있으면 Claude Code 요청이 맥스 플랜 기본 사용량이 아니라 추가 사용량 과금으로 라우팅됐다고 한다.

이 이슈 또한 파일명이 아니라 커밋 메시지 문자열이 트리거였고, 이슈 작성자는 기본 플랜 사용량이 많이 남아 있는 상태에서 extra usage credit, 추가 사용량 크레딧 $200.98이 소진됐다고 밝혔다.

Anthropic은 이를 "과하게 동작한 남용 방지 시스템"이라고 설명했고, 나중에 환불과 크레딧을 제공한다고 했다.

이게 의도적인 경쟁 툴 검열이었는지, 단순한 남용 방지 버그였는지는 사실 지금 단계에서 단정하기 어렵다. 그리고 굳이 단정할 필요도 없다.

기업과 개발자 입장에서는 의도보다 예측 가능성이 더 중요하다. 내 repo(저장소)의 커밋 메시지, 문서, 이슈, config(설정) 안의 어떤 문자열이 벤더의 숨은 정책을 건드려서 요청 거부나 과금 경로 변경을 일으킬 수 있다면, 그건 이미 인프라 리스크다.

흥미로운 대비는 OpenAI의 Where the goblins came from이다. OpenAI도 이상한 문제가 있었다. GPT 모델이 goblin, gremlin 같은 표현을 과하게 쓰는 현상이 있었고, OpenAI는 그 원인을 성격 시스템 프롬프트, 보상 신호, 강화학습 과정에서 생긴 문체 이슈의 확산으로 설명했다. 완벽한 해결책이었다는 말은 아니다.

다만 최소한 "무슨 일이 있었고, 왜 생겼고, 뭘 조치했는지"를 공식적으로 공개했다. 비용 문제는 아니었지만 어쩌면 그들의 핵심 경쟁력이라고 할 수 있는 모델 성능의 결함을 오픈하고 설명한 것이다.

AI 제품(아니 모든 소프트웨어)에서 신뢰는 "문제가 없음"으로만 만들어지지 않는다. 오히려 문제는 반드시 생긴다. 모델은 이상한 말을 하고, 라우팅은 꼬이고, 과금 예외 상황은 터진다. 중요한 건 그다음이다.

사용자가 납득할 수 있게 설명하는가. 정책과 과금 기준을 명확히 공개하는가. 영향을 받은 사용자를 먼저 찾아 보상하는가.

이 세 가지가 안 되면, 아무리 모델이 좋아도 개발자들은 마음속으로 탈출 계획(exit plan)을 만들기 시작한다.

요즘 Claude Code와 Codex를 가르는 기준이 순수 성능이라고 생각하지 않는다. 둘 다 충분히 좋고, 둘 다 이상한 짓을 한다. 솔직히 그 둘을 성능으로 가르는건 여기 스레드에 계시는 탑급 개발자 1%도 안될 것이다. 대부분 사람들에게는 둘의 차이는 근소하다.

하지만 개발자들은 사용자이자 소비자이다. 소비자가 결국 보는 것은 제품 너머의 브랜드와 신뢰다.

"이 회사가 내 작업 흐름을 갑자기 흔들지 않을까?" "내가 비용과 제한을 예측할 수 있을까?" "문제가 생기면 공개적으로 설명하고 바로잡을까?" 이 질문에 답하는 회사가 이긴다.

Anthropic은 Claude라는 강력한 브랜드를 갖고 있다. 그래서 더 아쉽다. AI는 엄청난 산업 변화를 가속화하는 대가로 각 회사들은 엄청난 출혈 경쟁을 하고 있다. 그들 입장에서는 OpenAI 와 Google 과의 경쟁도 골치아픈데, 토큰 물량 공세를 하는 중국발 모델들의 위협도 어마어마하다. (한국은.. ㅠ)

상장을 위해 기업 생존을 위해 비용 최적화는 필수로 따라야 하는 것이다.

Anthropic 는 직원 유지율, 특히 개발자 근속 기간이 다른 AI 회사에 비해 월등히 높은 회사다. 하지만 기업 운영은 개발자들의 빛나는 아이디어와 실행력으로만 완성되지 않는다. 그것을 뒷받침하는 운영, 재무 관리, 고객 대응에 대한 전략도 따라줘야 한다. 그들을 탑으로 올려주었던 필요조건들이 뒷밤침되어지지 못하는 충분조건으로 신뢰를 잃는 건 안타깝다.

Pro에서 갑자기 Claude Code 를 뺐다가 넣었다가 토큰이 급격하게 사라지는(최근 캐싱 이슈 등) 등의 사용량 정책을 투명하지 않게 운영하는데서 오는 사용자들의 피로감, 고객 지원 흐름이 엔지니어링 버그를 제대로 라우팅하지 못하는 모습이 반복되면 개발자 신뢰는 생각보다 빨리 사라진다.

개발자는 까다롭지만 단순하다. 좋은 도구는 좋아한다. 다만 블랙박스 과금과 모호한 정책 변경은 정말 싫어한다. 지금 Codex 의 위상을 봐라. 3개월 전이 기억나는가? OpenAI 가 잘해서일까? 내가 볼때 Anthropic 의 삽질에 대한 반대급부가 더 크다.

결국 이 사건이 말하는 방향은 꽤 분명하다. 모델은 외부에서 빌려 쓸 수 있다. 하지만 에이전트 실행 레이어, 정책 레이어, 비용 통제 레이어는 점점 사용자와 기업 쪽으로 내려올 것이다. 멀티 클라우드가 그랬듯이, LLM도 "가장 똑똑한 하나"보다 "예측 가능하고 교체 가능한 시스템"을 요구받게 된다.

Claude가 좋아도 Anthropic만 믿을 수 없고, Codex가 좋아도 OpenAI만 믿을 수 없는 시기가 온다.

내 결론은 이렇다. 이번 논란의 핵심은 Claude Code가 아니다.

핵심은 AI 에이전트를 인프라로 쓸 때 필요한 신뢰의 기준이 바뀌고 있다는 점이다. 앞으로 개발자들이 원하는 건 단순히 더 똑똑한 모델이 아니라, 더 투명한 실행 조건, 더 예측 가능한 과금, 더 빠른 사후 분석, 더 쉬운 escape hatch(탈출구)다.

AI 회사의 브랜드 파워는 모델 성능에서 나오는 것 같지만, 마지막에는 결국 사용자 신뢰에서 나온다.

🥜 왜 그들은 GitHub를 떠나고 있나?

Thu, 30 Apr 2026 15:00:00 GMT

요즈음 바이브 코딩 덕분에 비개발자들도 Github에 들어가서 별을 찍고 푸시를 하고 있다. SNS 화 되어가는 부분에 우려를 가진 사람도 있지만 Github는 명실상부 최고의 코드 플랫폼이다.

하지만 최근 6개월, GitHub은 장애가 아니라 붕괴를 겪고 있다. PR 탭이 하루 종일 죽었고 이미 머지된 코드가 되돌아갔다. 그리고 VP가 쓴 대응글에 "죄송합니다"는 한마디도 없었다.

최근의 사태는 단순히 서비스 장애 수준이 아니다.

PR 탭이 하루 종일 안 열리거나 장애가 생기는 건 이번이 처음이 아니다. 근데 최근의 사용자들이 공유한 장애는 정도가 심하다.

이미 머지된 2,804개의 PR이 무작위로 되돌아감
Github Webhook 장애로 자동 배포가 불가능
git push -o로 수백만 개 저장소에 접근 가능한 RCE 취약점이 발견

기능, 가용성, 지속성, 보안. 신뢰의 4개 기둥이 전부 무너졌다.

가장 웃긴 건 구조다. GitHub에는 CEO가 없다. 이전 CEO가 떠난 후 Microsoft는 대체자를 임명하지 않았다. 현재는 Core AI EVP에게 직접 보고하는데, 이 사람은 인프라 전문가이며 코드를 한 번도 짜본 적 없는 Atlassian 이사회 멤버다. CEO가 없으면 실패를 소유할 사람이 없고, CTO나 COO가 책임을 지면 해고될 수 있다. 책임질 사람이 없으면 아무도 진정한 변화를 추진하지 않는다. 그냥 악순환이다.

GitHub의 Product팀과 Engineering팀은 완전히 분리돼 있다. 다른 체계, 다른 프로세스. 개발자를 위한 제품을 만드는 회사에서 Product와 Engineering이 분리됐다는 건, 마치 식당에서 주방장은 요리만 하고, 홀 매니저는 주문 들어본 적 없고, 둘 사이에 소통할 사장님도 없는 거다. 음식은 나오는데, 손님이 원하는 게 아니다. CEO 없이 이 구조는 그냥 죽은 회사다.

Mitchell Hashimoto, Vagrant/Terraform/Ghosty의 창시자가 GitHub user #1299로 18년 동안 매일 열어봤다. Vagrant를 만든 이유 중 하나도 GitHub에 취직하기 위해서였다. 그가 떠나는 이유는 명확하다. "GitHub 장애로 업무에 차질이 생긴 날마다 일기에 X를 찍었다. 거의 매일 X가 찍혔다."

TanStack의 Tanner Linsley는 수년간 npm name squatting을 신고했으나 GitHub은 무시했고, 결국 해당 이름으로 malware가 배포되어 사용자의 .env 파일이 탈취되었다. Microsoft에 수십억 달러에 팔린 회사가 유지보수자들을 고통 속에 방치하고, 이제는 직접 해치고 있다.

"신뢰가 0이면 수리할 수 없다. 다 망가뜨려버렸으니 쌓을 기초도 없다. 끝났다."

신뢰의 종말. AI 시대에 항상 유지되는 건 없다. 전세계 모든 개발자가 쓰는 Github 플랫폼은 신뢰가 무너지기 전에 그들은 다시 정상화될 것 인가?

2026년 3, 4월 회고

Tony Cho (https://flowkater.io) — Thu, 30 Apr 2026 14:25:00 GMT

들어가며

퇴사한 지 이제 만으로 1년이 지났다. 작년 이맘때쯤에는 이탈리아 남부 아말피 해안에서 한가로이 시간을 보내던 시기다. 최근에 엘리랑 우리의 이탈리아 여행 1주년을 추억했다. 요즈음 대부분 집에서 작업을 하고 산책을 하는 단조로운 일상이지만, 1년 전 그때와는 또 다른 의미로 즐겁게 하루하루 시간을 보내고 있다.

애초에 엘리랑 팀 이름을 Loopetto로 정한 것도 이탈리아어 -etto에서 가져왔고, 우리들이 가장 좋아하는 오후 4~6시 산책 타임을 피렌체 타임이라고 명명한 것도 한 달 남짓한 이탈리아 여행이 우리 둘에게 여전히 영향을 많이 주고 있다는 반증일 것이다.

피에솔레에서 본 피렌체 야경

글쓰기

3월은 글을 많이 썼던 달이다. 특히 3월부터 4월 사이에 포스팅했던 AX 글 시리즈들은 나름 히트를 치며 조용하기 그지없던 블로그에 트래픽이 꽤 늘었다. 다만 3월 이전에 올렸던 AI 코드 리뷰나 에이전틱 엔지니어링 9가지 스킬 글은 개인 개발자들의 호응이 꽤 많고 피드백도 받았는데, AX 글 시리즈는 아무래도 조직 얘기가 주이다 보니 특히 조직 내부에서 많이 유입이 되었다. 삼성이랑 네이버에서 최근 2주 사이 유입이 꽤 많이 들어왔는데 내부에서 내 글을 읽고 어떤 이야기를 나누는지 궁금하지만 알 길이 없다.

순위	글	3~4월 누적 UV
1	에이전틱 엔지니어링 시대의 생존 스킬 9가지	5,789
2	조직에 Claude Code를 설치한다고 AX가 되지 않는다	5,011
3	AX팀을 만드는 순간, 당신의 조직은 AX에 실패한다	3,948
4	AI 시대에 코드 리뷰, 어떻게 해야할까?	2,346
5	세계 최대의 AI 기업은 차세대 엔지니어를 어떻게 교육하는가 — Anthropic x CodePath 커리큘럼 리뷰	1,623

3~4월에 발행한 글 중 같은 기간 누적 UV 상위 5개

고작 스타트업에 있었으면서 니가 뭘 아냐고 생각하시는 분들도 있겠지만, 사람 조직 문화는 크고 작은 걸 떠나서 본질은 똑같더라. 조직 운영이 참 어려운 게 도메인도 사람도 다 다른데 나타나는 현상은 공통된다. 책임지기 싫어하는 리더십(직원 입장)과 남 탓만 하는 직원들(리더십 입장). 하지만 현상은 공통되지만 그 현상이 유발된 원인은 또 그만큼이나 다양하기 때문에 해결책도 다 제각각이어야 한다.

그래서 내가 글에서 "이렇게 해야 한다!"라고 단정한들 그게 솔루션이 될 수는 없고, 모든 조직과 사람의 특성에 기인하여 휴리스틱하게 해결해야 하는 게 조직 운영의 본질이다. 만약 누군가 AI 시대에 조직은 이렇게 해야 합니다! 하면서 약을 팔고 있다면 의심해봐야 한다.

솔직히 고백하자면, 그 글들의 시작은 불편함이었다. Claude Code를 전사에 도입하게 됐다는 게 곧 AX라고 홍보하는 링크드인 포스트들. 조직 AX가 도구 교육으로 잘되고 있다는 스레드 글들. 그게 자꾸 화가 났다. 그래서 글을 썼다. 그들도 어차피 이런저런 자랑을 올리는 공간인데, 내가 영 무던하게 받아들이지 못했다. 그들을 보며 꼴불견이라 생각하는 속좁은 내 못난 성격 때문에 그러한 글들이 탄생했다. 나도 그 입장이었으면 똑같이 했을건데 말이다.

지금 발행된 글들도 거의 다 내 그런 감정에서 시작된 글들이라, 엘리가 최종 편집자 역할을 해주지 않았으면 너무 날것 그대로여서 빛을 보지 못할 뻔했다. 글을 쓰다보니 요령이 생겨 퇴고 과정을 워크플로우로 만들었는데 AI는 내가 생각하지 못한 많은 자료들과 사례를 찾아주기도 했지만 또 그만큼이나 내 날 것 그대로의 문장들을 집어삼키기도 했다. 퇴고가 될수록 컴파운드가 되는 시스템이라 이제 한두번만 워크플로우를 태워도 글이 꽤 정돈이 된다. (물론 엘리한테 가져가면 여전히 까인다.) 최근에 만난 한 대표님은 내 글에서 느껴지는 화를 아주 정확하게 짚어내주셨다. 특히, 그 화 이면의 내가 주구장창 외치는 본질이라는 가치를. 알아주셔서 감사했다. 다들 방법론에 집중할 때 글 너머의 나라는 사람에 대해 궁금해하는 분들이 커피챗이나 인터뷰로 연락을 주셨다. 그런 분들 덕분에 글을 계속 쓰게 되는 걸지도 모른다.

다만 다음 글은 어떤 글을 써야 할지 고민이다. 트래픽과 링크드인 좋아요는 즐거운 도파민이지만, 사실 나에게 경제적으로나 개인적으로나 지속가능성과 긍정적 의미에서 큰 의미가 없다. 그저 시기가 맞아 글이 터졌을뿐 어떤 시리즈나 기획으로 글을 쓰는 게 아니라 그때그때마다 감정에 충실하여 쓰다 보니, 초안까지 한 3~4편 쓰다가 그냥 갖다버린 포스팅도 꽤 된다. AX를 기대하고 들어온 블로그 독자들의 앞으로의 기대에 못 미칠 것 같지만, 5월부터는 다시 뭐든 이래저래 써보려고 한다.

(만약에 AX 글이 더 궁금하다면 나에게 직접 연락을 해달라. 어떤 고민과 얘기를 하고 있는지 궁금하다. 자연인의 나로서는 현재 기업 내부 상황에 대한 피드백 없이 글을 더 진전시키기에 한계가 있기 때문이다.)

커피챗

블로그 글과 SNS 트래픽 덕분에 몇몇 분들이 커피챗을 제안해주셨고, 최근 한 2주간 다양한 온/오프라인 커피챗을 가졌다. 어느 날은 하루에 세 개의 미팅을 몰아서 잡았는데 정오부터 밤 10시까지 밥도 안 먹고 미팅만 했다. 다음 주에 올라갈 외국계 서치펌의 AX 인터뷰도 진행했었고 초기 스타트업 대표님들의 커피챗도 있었다. 스레드에도 적어놓았지만 흥미롭고 유의미한 미팅들이었다.

집에 돌아와 엘리랑 늦게 무얼 먹었는지는 잘 기억나지 않는다. 다만 신기하게도 그렇게 힘들지 않았고 오히려 에너지가 넘치는 상태였다. 매일 엘리와 대화하지만 또 다른 사람들과의 대화는 결이 다르고, 그게 내 생각을 정리하는 좋은 기회였다. 가능하다면 꾸준히 커피챗 채널을 열어두고 싶다.

특히 AI가 모든 걸 다 해줄 것처럼 말하는 세상이지만, 여전히 스케일업되는 인프라에 대한 경험치나 신뢰할 수 있는 파트너에 대한 니즈가 여전히 존재한다는 것을 확인했다. 다들 테크리드라는 키워드로 말씀을 꺼내지만, 결국 원하는 건 같은 레벨에서 같이 책임을 맡아줄 사람인 것 같다. 같이 일하시는 개발자분들이 훌륭하시지만 굳이 나에게 미팅을 요청한 것 자체가 첫 번째 증거였고, 기술 얘기보다 비즈니스 뷰에서 관점을 동기화하는 대화를 더 많이 했기에 더 그렇게 느꼈다.

비용 관점에서 CTO는 부담스럽고, 그래서 테크리드라는 포지션으로 살짝 낮춰 조심스럽게 제안하는 듯한 느낌이다. 어떤 사람과 일한다는 것 자체가 리스크 있는 기회비용이니 충분히 이해되는 입장이다. 비용 관점에서 AI로 최적화하면서 개발 비용을 아끼는 건 너무 합리적인 선택이지만, 어느 정도 매출이 나고 펀더멘탈이 있다면 사람을 채용하는 건 여전히 투자 가치가 있다. AI는 코드를 만들 수 있지만, 실패한 의사결정의 책임을 같이 져주지는 않는다.

이번에 만난 분들과의 장기적인 릴레이션십이 미래에 또 어떤 기회로 발전할지는 모르기 때문에, 내가 조건이 허락되는 한 도울 수 있는 부분을 같이 얘기해보고자 했다. 팔로업을 바로 잡길 원하시는 분도 계셨지만 당장은 프로덕트 출시 때문에 고사를 했다. 아쉬움보다는 지금 프로젝트에 집중해야 한다는 확신이 더 컸다. 아마 조만간 배포를 하고 시장의 쓴맛 짠맛 성장의 어려움을 듬뿍 겪어보고 나서, 장기적으로 다음 기회를 고민해보지 않을까.

(매번 내 OpenClaw 에이전트인 자비스는 나에게 원씽 전략을 들이밀면서 지금 해야 할 일에 집중하라고 면박을 준다. 블로그 글 한창 써낼 때는 어찌 그리 잔소리를 해대던지. 지금은 얌전히 앉아서 개발 중이다.)

프로젝트

3월에 마무리하고 싶었던 프로젝트가 아직까지 진행 중이다. 큰 기능 개발은 끝났고 이제 마지막 작업들을 하고 있다. 현재 개발 중인 프로젝트의 이전 버전의 예전 리뷰들을 정리해서 아카이빙했는데, 300만 다운로드가 아니라 거의 글로벌로 485만 다운로드였다. 스토어 리뷰들도 전부 백업해서 별도 사이트로 아카이빙했는데 새로 발견한 지점들이 많았다.

진작에 정리할 걸 하는 생각이 먼저 들었고, 단기간에 이만한 숫자를 다시 만들 수 있다고 착각하지는 않는다. 다만 지금 프로젝트의 방향성을 끌고 갈 동기가 한 줄 더 생겼고, 후회만 가득했던 이전 서비스에 대한 애증이 조금은 애정으로 바뀐 느낌이었다. 우리가 힘겹게 고군분투했던 어느 시절을 다시 보는 느낌도 들었다.

리뷰를 읽다 새로 발견한 지점도 있었다. 한국어 리뷰는 대부분 요구사항이다. 불만이 없다면 리뷰를 잘 안 남긴다. 그래서 한글 리뷰를 읽으면 마음이 무거워진다. 풀어야 할 숙제가 한가득이니까. 그런데 글로벌 유저들은 진짜 사용 후기, 추천을 많이 남긴다. 어떤 사람한테 좋은지, 어떻게 쓰면 좋은지, 어떻게 써서 좋았는지. 과거의 앱과 지금의 앱은 분리된 또 다른 앱이지만 근본적인 사용자 층의 기회는 사라지지 않는다고 믿고 있어서, 이 글로벌 후기들이 좋은 길라잡이가 된다.

사실 이미 내려간 지 몇 년 된 서비스고 당시에 검증되었다고 생각한 니즈가 지금도 동일할 거라 생각하지는 않는다. 레거시 서버나 DB도 법인 정리하면서 완전히 초기화되었기 때문에 아주 zero부터 시작하는 게임이고 처음부터 잘될 거라고 1도 생각하지 않고 있다. 하지만 그때보다 한참 늦었지만 엘리랑 하고 싶은 대로 해보자는 생각으로 차근차근 진행해보고 있다.

이제 진짜 개발보다는 귀찮은 일들이 산더미인데, 그 중에서도 서버 수정 정책에서 한 번 크게 꼬였다. 게을렀다. 잘 정리된 정책을 Codex에 밀어넣고 알아서 풀릴 거라 생각했는데, 내가 짠 테스트 케이스가 죄다 해피 패스 시나리오 위주였다. 내부 배포판에 올라가자마자 정책이 와장창 꼬이면서 예기치 않은 이슈를 줄줄이 만들었다. 지금 다시 시나리오를 정리 중이다. 이제 중간 단계의 어줍잖은 가이드라인보다 명확한 테스트 케이스와 견고한 정책 파이프라인을 잡아서 밀어넣는 게 더 중요해졌다. 내가 게을렀던 부분이다. 반성한다.

온보딩과 유료 결제 화면은 X에서 굉장히 많은 벤치마킹 사례를 보면서 엘리가 가이드를 잡아 다시 재설계 중이다. 결국 서비스 지속 가능성은 유료 전환율이라, 앱 본질 못지않게 프론트 세일즈도 중요하다. 이전 서비스는 거의 무료 플랫폼 전략으로 부가 수익을 가져갔던 모델이라 엘리랑 같이 해보지 않은 작업이고, 초반에 같이 방향성을 잡는 데 애를 좀 먹었다.

다음 회고 때는 이제 어느 정도의 성과를 가져왔으면 좋겠다.

이전 서비스 아카이빙 일부(다운로드+리뷰 개수)

나쁜 파트너, 나쁜 멘토

엘리랑 커뮤니케이션

엘리도 나도 다시 서비스를 만들고 배포하는 상황이다 보니 어느 정도는 미루고 싶은 마음과 게으른 마음이 공존하고, 둘 다 개발자, 디자이너였다 보니 자기 작업에 매몰되는 경향이 다분히 있다. 다만 이 일을 마무리하고 성과를 만들어내야 한다는 압박감에 내가 엘리에게 자주 다그치는 상황이 벌어졌다. 사실 그렇게 얘기를 안 했어도 되었던 부분이 있는데 말이다. 나도 예민하게 굴고 그게 감정적으로 표현되는 부분이 생겼다.

그럴 때마다 이전 매니저(CTO/CEO) 시절 안 좋은 습관들이 발현되는 것 같다. 감정적 푸시는 나쁜 의미로 중독성이 있다. 결과가 빠르게 나오는 듯한 착각, 내 생각이 명확하게 전달되었을 거라는 착각을 주니까.

하지만 예민함에는 결이 따로 있다. 프로덕트를 다듬고 기획의 날을 세우고 일을 목적성 있게 끌고 가는 데는 예민함이 필수다. 문제는 그 업무 모드의 태도가 엘리와의 대화에도 그대로 발현되고 있었다는 것. 일정이 조금씩 딜레이되는 이슈들이 서로 겹치면서, 본의 아니게 엘리에게 압박을 더 자주 했고, 본의 아니게 감정적인 말이 섞였다.

가장 많이 했던 말은 "목표가 무엇이냐"였다. 각자의 작업에 매몰되다 보면 같은 공간에 있어도 서로 얘기하지 않으면 상대방의 머릿속을 모른다. 결국 두세 번의 감정적 대화가 오갔고, 그 다음에야 "목표"를 다시 명문화하고 같이 정리했다. 돌아보니 내가 제대로 전달하지 않았더라. 모든 관계가 그렇듯 알겠거니 하고 뒤로 미루면 결국 사고가 난다. 자주 말하고 자주 소통하기. 매번 까먹는다.

엘리도 나와 같은 목표를 보고 있었다. 다만 같은 언어로 명문화되지 못했을 뿐이었다. 그래서 처음에는 침묵이었고, 그 다음엔 내 감정적 토로를 받아치기도 했다. 행동은 의도를 드러내지만, 다 드러내기에는 충분하지 않다. 그래서 우리에게는 언어가 있다.

그날 내 진짜 감정은 사실 불안과 짜증, 그리고 수면 부족으로 인한 피로함이었다. 내가 그날 한 말은 일을 빨리 끝내자는 말처럼 들렸겠지만, 사실은 내 불안을 엘리에게 넘긴 것이었다.

파트너와 함께 같이 일한다는 건 그만큼 어려운 일이다. 하지만 또 그만큼 신나는 일도 없다.

멘토링

11월부터 진행하던 멘티와의 멘토링을 종료했다. 그에겐 미안한 부분이다. 일이 바빠진 탓도 있었지만, 가장 큰 원인은 나의 인내심 부족이었다.

나는 항상 내가 좋은 선생님, 좋은 코치라고 생각하고 살아왔다. 하지만 아니었다. 여러 환경적 제약은 사실 핑계였고, 내 인내심이 부족해서 후배를 계속 밀어붙였다. 그 과정에서 서로 힘들었던 순간들이 있었다.

돌아보면 그는 내 피드백을 적극 수용하고 항상 배우려는 자세였는데, 나는 내가 전달한 정보를 그가 제대로 소화하고 있지 못한 것에 계속 답답해하고 불만을 가졌다. 그래서 그에게 충분히 생각할 시간을 주고 기다려주었어야하는 부분들에서 내가 먼저 답을 말하고 알려주는 형태로 악순환이 계속되었다. 그렇다. 나는 좋은 멘토가 아니었던 것이다.

워낙 AI가 가져오는 변화가 빠르다 보니, 내가 보고 듣고 학습하는 모든 관점들을 후배에게 무리하게 전달하려고 했다. 그 변화를 수용해야만 더 좋은 성장이 올 거라고 단언하면서. 하지만 모든 배움에는 각자의 속도가 있다. 나는 그 속도를 무시하고 내 속도만을 강요하고 있었다.

처음 멘토링을 정리하자고 했을 때, 후배는 한동안 힘들어했다. 나도 마음이 무거웠다. 다만 멘토에 대한 의존을 버리고 스스로(그게 돌아가는 길이라도)길을 찾기를 바랐다. (다행히 지금은 주기적으로 가볍게 프로젝트나 여러 얘기를 한다.)

도와준다고 이것저것 던졌는데, 돌아보면 그 대부분은 내 불안의 다른 이름이었는지도 모른다.

입력은 자동화됐고, 판단은 남았다

지난 두 달 동안 입력량이 폭증했다. 자비스 덕분에 유튜브 크론 채널을 늘렸고, X의 자동 번역이 열리면서 해외 글들을 훨씬 많이 수집해서 읽고 있다. 하루에 20개 정도의 요약 피드를 받는데, 빠르게 훑고 진짜 관심 있는 것만 자세히 본다. 입력량이 이 정도가 되니 의외로 FOMO에 덜 휩쓸린다. SNS 의 FOMO 에서 자유로울수있는 좋은 방법은 그냥 핑계대지 말고 인풋을 어마어마하게 늘려라.

자비스가 자동 수집·요약해 옵시디언에 떨군 노트만 두 달 동안 1,200건이 넘었다. 카테고리로 묶어보면 이렇다.

유형	3~4월 신규 노트
YouTube 다이제스트	629
뉴스레터 · 기술 칼럼	175
영문 아티클 번역 · 요약	149
AI · 에이전트 주제	93
컨셉 노트 · 책 정리	65
그 외 (리더십, 도구, 시장 등)	110
합계	1,221

자비스로 자동 수집·요약된 노트 기준, 중복 파일명 제거

다만 많이 읽는 것과 많이 생각하는 것은 다르다. 내가 이전에 썼던 블로그 글 비슷한 얘기가 해외에서도 반복되는 걸 확인했고, 알지 못하던 새로운 얘기들도 많이 봤다. 그게 내 생각으로 전환된 만큼은 이번 분기 글들에 녹았을 것이다. 나머지는 그냥 저장으로 끝났을지도 모른다. AI 에이전트 활용이 일상화되면서 정말 하루 읽는 텍스트량이 어마어마하게 늘었다.

회고와 5월에는

이번 두 달의 Keep / Problem / Try

Keep

독서 꾸준히. 블로그에 다음 분기 독서 리뷰를 위해서라도.
운동. 필라테스, 걷기. 무리하지 말고 꾸준히 움직이자.
잘 때 스마트폰 안 들고 들어가기. 요즈음은 알람 없어도 8시면 깬다. 책 들고 침대로 가면 바로 곯아떨어진다. 작년과 달리 제일 좋아진 부분.
사우나. 피로를 푸는 데 사우나만 한 게 없다. 매주는 아니더라도, 날이 좀 더워지더라도 꾸준히 가자.

Problem

식단. 연초보다는 많이 건강해졌는데 최근 좀 해이해져서 탄수화물이 확 늘었다. 다시 챙기자.
일본어 공부. 작년 일본 여행 다녀와서 연초에 열심히 했는데 지금 일 핑계로 잘 안 한다. 하루에 조금씩이라도 챙기자.
엘리랑 업무 대화. 나 스스로도 평소와 달리 모드가 바뀌는데 조금 더 잘 말하기에 집중하자.

Try는 길게 풀지 않는다. 5월의 원씽은 출시. 자비스의 잔소리를 그대로 받기로 했다. 엘리와 대화하기 전에 내 상태부터 말하기—불안한지, 피곤한지, 짜증나는지부터. 명문화된 승리 조건에 우리 둘의 방향을 다시 정렬하기. 그게 다다.

나가며

이탈리아 사진을 본다. 1년 전 거기서 가져온 단 하나의 깨달음은 지금 이 순간에 집중하자는 것이었다. 돈보다 비싼 게 시간이고, 이 시간을 낭비하지 말자는 다짐이다.

피렌체 타임에 산책을 놓치지 않으려는 것도, 그 순간의 석양과 분위기는 그 순간만의 것이기 때문이다. 두번 다시 돌아오지 않는다. 일도 마찬가지다. 지금 내가 하는 일을 미룬다고 누구도 뭐라고 하지 않지만, 후회를 만들고 싶지 않다.

5월의 나는 출시 앞에 서게 될 것이다. 그 다음에는 사용자 앞. 그리고 늘 그렇듯 엘리와 나 자신 앞.

피렌체 타임은 여전히 좋다. 다만 이제 그 산책 뒤에는 다시 만들어야 할 제품이 기다리고 있다.

2026년 1분기에 읽은 책들

Tony Cho (https://flowkater.io) — Tue, 14 Apr 2026 01:00:00 GMT

들어가며

올해 1분기 동안 읽은 책들을 한 자리에 정리해 본다. 소설부터 고전, 전기, 자기계발, 스타트업, 리더십, 스포츠까지 장르를 가리지 않고 여기저기 손을 뻗었다. 길게 후기를 남긴 책도 있고, 별도 포스트로 이미 다룬 책도 있어서 분량은 편차가 있다. 그냥 읽은 순서에 상관없이 기록만 남기려 한다.

「스토너」 — 존 윌리엄스

작년 11월에 읽은 책인데 어디에도 후기를 남기지 않아서 여기에 기록한다. 간만에 느끼는 소설다운 작품이었다. 극적이지 않아서 오히려 더 많은 사람들에게 울림이 된 게 아닐까 싶다. 스토너라는 한 사람의 인생을 간접 체험하면서, 우리가 인생에서 느낄 수 있는 좌절감과 갑갑함, 그럼에도 하루하루 살아감에 최선을 다한 한 사람의 생애를 온전히 경험한 느낌을 받았다. (책의 여운이 길게 남아서 이동진 평론가의 서평을 읽기 위해 밀리의 서재를 한 달 구독하기도 했다.) 많은 사람들이 인생 책으로 꼽는 이유가 있더라.

잔잔한 인생의 사건들을 시간 순으로 풀어내는 소설인데, 그의 인생에 나타나는 몇 안 되는 '빌런'들이 있다. 흔히 말하는 극적인 빌런이라기보다, 잔잔하기 짝이 없는 그의 인생에서 그를 계속 거슬리게, 걸리적거리게 하는 존재들이다. 이 '빌런'들이 우리 인생의 그것과 너무 닮아 있어서 흥미로웠다. 딱히 죽일 만큼 나에게 죄를 지은 사람은 아니지만, 인생을 살다 보면 만나는 거슬리는 사람들을 아주 절묘하게 묘사했다.

그리고 우리네가 그렇듯, 스토너는 단 한 번도 그들을 무찌르지 못한다. 설명만 들어도 고구마를 먹은 것 같은 이 소설을 그래도 추천하는 건, 이렇게까지 한 사람의 인생을 피부에 닿게 묘사한 작품을 많이 만나지 못했거니와, 그의 인생 처음부터 마지막까지 함께하며 느끼는 여운을 꼭 한번 경험해보았으면 해서다.

소설의 소개는 이동진 평론가의 추천 영상으로 대신한다.

인생 전체를 건 전쟁에서 이기려 하지 말고 하루하루의 전투에서 이기려고 하자. '스토너' 또한 그런 사람이었다.

— 이동진

「돌파력」 — 라이언 홀리데이

조지와 엘리랑 같이 읽어보려고 간만에 시도한 자기계발서. 사실 좋은 책은 아니다. 참을 수 없는 그 자기계발서 특유의 가벼움 덕분에, 책에서 계속 인용하던 스토아 학파의 대표작 「명상록」을 직접 읽게 된 것이 이 책의 순기능이라면 순기능.

자세한 후기는 여기에.

「명상록」 — 마르쿠스 아우렐리우스

하루하루 조금씩 성경 말씀 보듯이 읽은 책. 내가 좋아하는 「내가 틀릴 수도 있습니다」가 수필이라면, 이 책은 조금 더 말씀에 가깝다. 물론 마르쿠스가 스스로에게 다짐하듯 썼다는 걸 상기하면서 읽으면 꽤 흥미롭게 다가온다.

대표적인 고전 중 하나라 예전부터 한번 읽어보고 싶었는데, 「돌파력」 덕분에 읽게 되었다. "이불 밖은 위험해"라며 안주하는 스스로를 아주 '교조적'인 문장들로 다그치는 대목이 일품이다. 언젠가 삶이 힘들어질 때, 그의 일기에 쳐놓은 내 밑줄로 다시 위안을 얻을 수 있을 듯하다. 줄을 치면서 읽기도 하고 가끔 오디오로도 들으면서 읽었는데, 밑줄 친 내용들을 다시 한번 따로 정리해보려고 한다.

'모든 것은 생각하기 나름'이라는 것은 어떤 외적인 일이나 환경, 즉 행복이나 선악과는 아무런 상관이 없는 가치중립적인 것들의 성격과 영향은 그 일이나 환경에 의해서가 아니라, 오로지 사람이 그런 것들을 어떻게 받아들이느냐에 달려 있다는 의미다

날이 밝았는데도 잠자리에서 일어나기가 싫을 때는 마음속으로 이렇게 생각하라: '나는 인간으로서 해야 할 일을 하기 위해 일어나는 것이다. 나는 그 일을 위해 태어났고, 그 일을 위해 세상에 왔는데, 그런데도 여전히 불평하고 못마땅해하는 것인가. 나는 침상에서 이불을 덮어쓰고서 따뜻한 온기를 즐기려고 태어난 것이 아니지 않느냐.'

「소스 코드: 더 비기닝」 — 빌 게이츠

작년에 나오자마자 샀는데 거의 1년이 지나서야 읽게 되었다. 여러 매체로 마이크로소프트의 창업기(「실리콘밸리의 해적들」 등)를 접했었는데, 확실히 본인이 직접 쓴 이야기라 내가 어렴풋이 알던 것과 달리 마이크로소프트 창업 직전까지의 전기가 아주 디테일하게 다루어져 있다.

이 책은 빌 게이츠 인생 1부인데, 마이크로소프트 창업 전 어린 시절 이야기가 메인이다. 아마 2부가 마이크로소프트 제국이 되기까지의 이야기, 3부는 은퇴 이후의 이야기일 것 같다. 월터 아이작슨이 쓴 「일론 머스크」, 「스티브 잡스」와는 좀 다른 느낌이지만, 그의 비범했던 어린 시절을 들여다보는 건 나름 흥미진진한 이야기였다.

(하필 이 책을 읽던 중에 그의 스캔들이 터져서 후기를 남기기가 웃긴 상황이 되었다. 그래도 읽은 책이니 짤막하게 남겨본다.)

전날보다 오늘 더 나은 성과를 내기 위해 매일 끊임없이 집중하고 고심하며 얼마나 오랜 기간 노력을 기울여야 최고의 경지에 오를 수 있는 걸까?

「피를 마시는 새」 (전반부) — 이영도

「눈물을 마시는 새」를 고등학교 수업 중에 읽다가 눈물을 흘렸다. 고등학교 2학년 때로 기억하는데, 마지막 결말부를 읽었던 장면이 아직 기억에 남아 있다. 「피를 마시는 새」도 읽어야지 하다가 담아두고만 있다가, 20주년 출판 기념판이 나왔길래 (사실 눈마새 기념판을 사고 싶었다) 전권을 구매해서 작년부터 조금씩, 1분기에 틈틈이 읽었다.

아직 몇 권 남았는데, 눈마새보다 훨씬 다양한 인물과 세력이 나온다. 눈마새를 「반지의 제왕」(그중에서도 반지 원정대)에 비유한다면, 피마새는 「얼음과 불의 노래」(왕좌의 게임)에 비유할 수 있을 것 같다. (군상극이라는 부분에서.)

다양한 캐릭터의 매력과 눈마새에서 탄탄하게 구축되어 온 세계관이 정수를 이루며 감탄을 자아내는 장면들이 많다. 여전히 감정을 자극하는 문장들이 있는가 하면, 오래되어서 그런지 조금 유치한 문장들도 보인다. (나이가 들었나 보다.) 그래도 한번 끝까지 읽고 다음 분기 후기에 마저 작성해보겠다.

말에서 떨어진 사람은 말에 탄 사람이다. 패배한 장수는 전쟁에 참가한 장수다. 익사한 레콘은 물에 들어간 레콘이다……. 모든 패배자는 패배하기 직전까지 승리를 거듭한 자다. 삶은 패배하기 위한 긴 여정이다. 삶은 승리하기 위해서가 아니라 패배하기 위해서 사용해야 한다.

「배틀그라운드, 새로운 전장으로: 크래프톤 웨이 두 번째 이야기」 — 이기문

크래프톤 웨이 1편을 보며 느꼈던 첫인상은 "배틀그라운드 탄생까지의 과정이 참 운이 좋았다"였다. 블루홀(크래프톤 이전 이름)이라는 게임 회사가 어떻게 설립되고 어떤 시행착오를 거쳐 배틀그라운드까지 오게 되었는가, 그 이야기 자체는 정말 흥미진진했지만 내가 얻을 수 있는 교훈은 없다고 느꼈었다.

하지만 이번 2편은 달랐다. 배틀그라운드로 흥행을 이뤘지만, 그 성공을 기반으로 어떻게 지속 가능한 조직과 회사, 서비스를 만들 것인가를 두고 고군분투한 생생한 내용이 담겨 있었다. 1편과 달리 많은 부분에서 크게 인상 깊게 읽었다.

글로벌로 성공한 서비스를 한 번의 대박이 아니라 지속 가능한 서비스로 만들기 위해 그들이 거쳐야 했던 지난하고 고단한 과정들. 읽으면서 같이 괴로워지기도 했지만, 한편으로는 성과를 위해 한마음으로 미친 듯이 본인들의 삶을 갈아 넣으며 서비스를 만들어내는 과정이 부럽기도 하였다.

특히 메인이 되는 장병규 의장과 김창한 대표의 날카롭다 못해 "이래도 되나" 싶은 대화록을 보고 있자면, 이 정도 성과를 낸 회사의 리더들도 이렇게 치열하게 부딪히고 조직을 공부하고 직원들과 대화하려고 노력하는데 (일방적이라 하더라도), 나는 과거에 조직을 위해 그 정도 노력을 했나 싶은 반성을 많이 하게 되었다.

아마 이 책도 장병규 의장의 아이디어였을 것 같은데, 배틀그라운드 개발과 성공의 비하인드뿐만 아니라 조직 문화 구축에 대한 많은 부분(그리고 그 어려움), 여러 경영적 판단 뒤의 고뇌들을 고스란히 느낄 수 있어서 추천한다.

크래프톤이 단순히 배틀그라운드 원 히트 원더에 머물지 않고 다양한 IP와 게임 타이틀로 확장되어 더 성장하길 바란다. (위에 쓴 것처럼 크래프톤이 「눈물을 마시는 새」 미디어 IP도 보유한 만큼, 한국판 위쳐가 탄생하길 바란다.)

PUBG 직원에 한해선, 미친 개의 탈을 쓴 알몸의 김창한을 본 사람은 없었다. 김창한은 블루홀 경영진과의 협의 내용이나 그로 인한 마찰을 PUBG 내부에 전하지 않았다. 그가 PUBG 바깥에서 어떤 모습을 하고 다니는지는 아무도 알지 못했다.

어떤 일에 주인의식(ownership)이 있는 사람은 메시지의 전달(delivery)까지 책임집니다. ‘내가 발신했는데 상대가 받지 않았다’는 말은 하지 맙시다. 그런 식으로 서로 책임을 돌리기 시작하면 결국엔 답이 나오지 않습니다. 수단과 방법이 효율적인지 따지기 전에, 소통이든 일이든 주인의식을 가진 사람이 메시지가 전달될 때까지 책임져야 합니다.

한국 개발자들은 직업으로 개발자를 시작했잖아요. 열정이 있는 사람이 뛰어들어야 하는데 한국에 그런 개발자가 있는지 의문이 듭니다.

개발팀 모두가 개발을 멈추고 자신들이 만든 게임을 하고 있을 때, 그때가 출시일이다.

「우리는 실리콘밸리에 속았다」 — 랜드 피시킨

어떤 VC가 스레드에서 "쓰레기 같은 책"이라며 자기 연민에 빠진 "나약한" 저자의 정신 상태를 꼬집으며 비판하길래, 오히려 무조건 읽어봐야겠다 싶었다. 저자는 SEO 스타트업 Moz를 창업한 사람인데, 사업이라는 것에 아주 나이브했던 초창기의 이야기, VC 투자를 받고 승승장구했지만 중간에 Exit 하지 않은 스스로에 대한 후회, 흔히 실리콘밸리(또는 스타트업씬)에서 주장하는 그로스 해킹과 J커브 성장을 비판하면서, 우리가 페이스북이나 소수의 성공한 스타트업 스토리에서는 보지 못하는 있는 그대로의 이야기를 들려준다.

지금이야 AI로 말미암아 꼭 VC 투자를 받지 않아도 된다는 통념이 어느 정도 생기고 부트스트래핑이라는 방법도 논의되고 있지만, 내가 처음 시작했던 2010년대에는 모든 스타트업이 VC 투자를 받고 유니콘이 되는 게 최우선 미션이었다. 나의 사업도 마찬가지였고, 모두의 사업이 유니콘이 될 수 없는데 말이다.

VC 펀딩으로 자금을 수혈하며 적자 상태를 달리면서 폭발적인 성장을 추구하는 회사도 있지만, 착실히 니치한 마켓에서 캐시플로우를 만들면서 꾸준히 성장해 온 회사들도 있다. 스타트업을 생각한다면 한번쯤 읽어볼 만한 책이다. 내가 원하는 것이 무엇인지, 정말 본인이 원하는 비즈니스 성장 방식이 무엇인지 가늠해보는 데 도움이 될 것이다. 그의 정신적 고통, 단계별로 가지는 후회나 조언들이 나에겐 꽤 유의미했다.

10년 전에 이 책을 봤다면 지금까지 내 사업체를 끌고 갈 수 있었을까.

진실을 숨길 수 있다고 믿는 순간, 나쁜 짓을 막아주는 브레이크가 고장 난다.

창업자의 속성은 조직에 거의 영구적으로 박제되는 반면, 직원들의 속성은 시간이 지나면서 변한다. 부분적으로는 창업자가 훨씬 오래 남아 더 오랫동안 영향력을 행사하기 때문이다. 하지만 팀을 유지한다 해도, 창업자의 편향, 그들이 만든 비즈니스 구조, 채용 방식, 위임 방식, 자원 배분, 열정, 그리고 맹점에서 비롯된 지울 수 없는 각인이 남는다. 나는 모든 규모, 산업, 구성의 회사에서 이 패턴이 반복되는 걸 본다. 창업자(와 CEO)는 조직의 성격과 문화뿐만 아니라, 수년 혹은 수십 년간 조직의 궤적을 지배하는 근본적인 강점과 약점을 지배한다.

The Score Takes Care of Itself — Bill Walsh

미국에서는 꽤 유명한 리더십 서적이다. 워낙 추천하는 사람들이 많아서, 원서지만 AI 에이전트 덕분에 아주 편하게 꼼꼼히 밑줄 치면서 읽었다.

생생한 후기는 이 글에서.

「F1 더 포뮬러」 — 조슈아 로빈슨, 조너선 클래그

책을 사 놓고 단기간에 제일 빨리 읽은 책 중 하나일 것이다. 얘기로만 듣던 엔초 페라리, 버니 에클스턴 같은 F1 산업의 핵심 인물들부터 니키 라우다, 아일톤 세나, 미하엘 슈마허, 그리고 루이스 해밀턴에서 막스 베르스타펜으로 이어지는 챔피언 드라이버들의 이야기와 팀들의 굵직한 역사, 그리고 비하인드를 볼 수 있다. 월스트리트 저널 저자들의 여러 취재로 엮어낸 이 책은, 지난 F1 역사에 대한 헌정이기도 하고, 현대의 미국 시장 중심으로 재편된 F1에 대한 애정과 걱정이 모두 담긴 책이다.

나도 넷플릭스 「본능의 질주」 시즌 1로 F1에 입문했고, 띄엄띄엄 보다가 본격적으로 매 경기를 챙겨 본 건 작년부터다. 책을 통해서 그 이전의 F1 역사도 다시 정리되었고, 이미 알고 있던 굵직한 사건들도 여러 비하인드를 통해 정말 재밌게 풀어냈다. 아무래도 작년에는 매 경기 꼼꼼히 챙겨 보고, 패덕에서 흘러나오는 온갖 뉴스와 F1 선수들의 밈을 엘리와 공유하다 보니, 올해 공개된 「본능의 질주」 새 시즌이 굉장히 가벼워서 아쉬움이 컸다. (다큐멘터리는 어디까지나 완전 입문자들을 겨냥한다.) 그 아쉬움에 F1 리더십에 관한 별도의 글도 작성했다.

그리고 올해 3경기 이후에 이란 전쟁으로 갑자기 4월에 두 경기가 취소되면서 아쉬움이 배가 된 상태였는데, 이 책이 그 빈틈을 메웠다. 리버티 미디어가 인수한 뒤 넷플릭스 다큐멘터리로 F1은 완전히 새로운 장을 썼다. 레이스, 즉 경주라는 건 1등을 가리기 위한 게임이다. 하지만 레이스가 부가 되고, 1등이 아니어도 중위권·하위권에서 다투는 팀들의 드라마와 선수들의 비하인드가 소비되는 형태가 꽤 재밌는 지점이다. 책에서도 지적했듯, 이제 경기를 하나도 보지 않고도 F1 팬이라고 자처하는 사람들이 있다. (나도 재작년까지는 그랬고.)

F1이 궁금한 사람들은 넷플릭스 다큐멘터리를, 다큐멘터리를 통해 입문한 뒤 F1의 지난 역사가 궁금한 분들은 이 책을 읽으면 딱일 것이다. 마이애미 그랑프리까지 2주 남았으니, 지금 바로 구매해서 읽어보자.

그런 점에서 F1은 일종의 '포스트 스포츠(post-sport)'라고 볼 수 있었다. 레이스를 한 번도 보지 않고도 포뮬러 1의 광팬을 자처할 수 있는 세상이 되었다. 그들은 평생 F1에 몰입하고 애착을 느끼며 돈까지 바치는 완전한 지지자다.

「원칙」 — 레이 달리오

투자자 레이 달리오의 그 유명한 책이다. 60% 정도 읽다가 내려놓았는데, 레이 달리오의 인생을 간접적으로 들어볼 수 있었던 흥미진진한 1부와 달리 2부와 3부는 진짜 문자 그대로 "원칙"에 대한 내용이라 조금 당황했다.

요즈음은 자기계발서도 이렇게 쓰면 욕먹을 것 같은데, 7~8년 전 처음 출간되고 당시 주위에 꽤 많은 사람들이 추천하고 열광했던 책이라 구매한 지도 오래되었고, 숙제처럼 가지고 있던 책이라 읽었다. 그런데 2부, 3부의 원칙 나열이 좀 당황스러웠다. 딱히 이런 식의 전개를 선호하는 편도 아니고 자기계발서류를 너무 안 좋아하기 때문에, 그가 성공한 투자자라는 것을 제외한다면 사실 이 정도로 평가를 받을 책인가 싶다.

나의 책에 대한 감상과 달리, 그의 원칙들이 공감이 안 되는 건 아니었다. 솔직히 좋은 말씀들이다. 그런데 이런 메시지의 나열이 내 삶의 원칙이나 어떤 기준에 조금이라도 남으려면 어떤 인상(impression)이 남아야 하는데, 전혀 그렇지 못했다.

책이 정말 두꺼운데, 레이 달리오라는 사람이 궁금하면 1부만 읽어도 문제가 없다. 1부는 그의 이야기가 담겨 나쁘지 않았다. 1, 2, 3부로 나눠서 1부만 살 수 있었으면 얼마나 좋았을까. 누군가에게는 인생 책이라고 하니 그래도 한번 트라이해보고 판단한 데에 의미가 있다.

실패한 다음에 무엇을 하느냐가 가장 중요하다. 성공한 사람들은 강점을 살리면서 약점을 보완하는 방식으로 발전하지만, 실패한 사람들은 그렇게 하지 못한다.

나가며

<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); gap: 1rem; margin: 1.5rem 0;"> <figure style="margin: 0;"> <img src="/assets/2026-q1-books.jpg" alt="오닉스 팔마 2" style="width: 100%; height: auto; margin: 0;" /> <figcaption style="text-align: center; font-size: 0.875rem; opacity: 0.7; margin-top: 0.5rem;">오닉스 팔마 2 이북 리더기</figcaption> </figure> <figure style="margin: 0;"> <img src="/assets/2026-q1-todait.png" alt="Todait 독서 플랜" style="width: 100%; height: auto; margin: 0;" /> <figcaption style="text-align: center; font-size: 0.875rem; opacity: 0.7; margin-top: 0.5rem;">Todait으로 관리하는 1분기 독서 플랜</figcaption> </figure> </div>

책을 읽는 데에는 지금 (다시) 개발하고 있는 Todait을 주로 사용했다. 세 권을 동시에 읽어도 분량 관리가 자동으로 되니 차근차근 읽게 되었는데, 생각보다 책을 동시에 여러 권 읽으니까 너무 정신이 없다. 일 때문에 바빠 며칠 책을 못 읽으면 또 그만큼 분량이 쌓여서, 동시에 읽는 책은 최대 2권으로 줄여야 하나 싶다.

2월부터 본격적으로 읽었으니 대충 1주에 1권 읽었다 치고 (벌써 4월 중순이지만), 책을 많이 읽는 것도 좋지만 계속 후기를 쌓아나가면서 생각 정리를 위한 메모라도 러프하게 남기려고 한다. 몇몇 책은 읽은 지 벌써 꽤 오래되어, 그때그때 메모를 안 남겨놓은 탓에 다시 기억해서 쓰려니 어려웠다.

반은 실물 책을 구매해서 읽었지만, 반은 오닉스 팔마 2(휴대폰 사이즈 이북 리더기)를 구매해서 전자책으로 어디서든 읽을 수 있게 세팅해 놓았다. 특히 요즈음은 침대방에 스마트폰을 들고 들어가지 않고, 이북 리더기와 읽고 있는 책만 들고 들어가는데, 수면에도 책 읽기에도 도움이 많이 된다.

아직 사놓고 쌓아만 놓은 책들이 많으니, 꾸준히 책 읽기를 이어나가기 위해 분기 후기를 남긴다. 다음 분기에 다시 돌아오겠다.

'점수는 저절로 따라오는 것이다'를 읽고 — 리더십에 관하여

Tony Cho (https://flowkater.io) — Mon, 13 Apr 2026 13:00:00 GMT

들어가며

조직 얘기, 리더십 얘기를 하게 될 때마다 다들 내게 어떤 성공 경험이 있기에 이렇게 깊은 얘기를 할 수 있냐고 물어본다. 참 민망한 질문인 것이, 나는 리더십에서 그 어떠한 성공을 거둔 적이 없다. 나는 항상 내가 있는 조직에서 외톨이였고, 내가 직접 사업을 했던 시절부터 최근 조직까지 단 한 번도 '진정으로' 팀에 속한 느낌을 느낀 적이 없었다. 어릴 땐 "나는 다르다"라는 자만과 착각이었다면, 최근엔 결국 타인을 이해하기를 포기한 내 게으름 때문일 것이다. 나아가 내가 세운 기준과 원칙, 그리고 일관성이 무너지며 아래로도 위로도 모래성과 같은 내 리더십이 어떻게 무너지는지까지 두 눈 뜨고 지켜보았다. (불가항력이었다고 변명하고 싶지 않다. 그 팀을 선택한 건 결국 나니까.)

그나마 위안인 건, 내 커리어에서 겪은 모든 사람들 중 — 나를 포함해서, 역대 내 상사, 내 후임 모두 포함해서 — 제대로 된 리더십을 발휘하는 사람은 아무도 없었다. (단, 한 명도.) 오히려 내 기준에서 그들은 최악에 가까웠고, 웃기게도 나는 최소한 그들보다는 나았다고 생각한다. 지금까지도. (그들의 생각은 다를 것이다. 어디까지나 내 생각이니까.)

리더는 소속된 팀원들에게 적재적소의 위임을 해야 한다. 하지만 신뢰가 없는 상태에서 나이브하게 위임하는 건 팀을 방임주의로 가져오는 것이고, 실패한 팀원들을 위로하면서 만드는 '가짜' 심리적 안정감은 그저 그들이 나와 일하며 불편하지 않기를 바라는 한없이 못난 내 개인의 이기심에 불과하다. 반대로 그들을 믿지 못해 내가 직접 모든 일을 끌고 가면, 결국 팀원들은 본인의 역할 플레이를 찾지 못하고 알맞은 성장과 도전을 하지 못하며, 근무시간만 챙기면 나머지는 리더가 책임지겠지라는 방만함에 빠진다. 팀의 승리는 더 이상 그들의 책임이 아니고 관심도 없다. 그들은 회사가 망하지 않고 월급만 주길 바랄 뿐이다. 위임을 해야 한다 말아야 한다의 문제가 아니다. 모든 팀이 다르고 사람이 다르기 때문에 그 정도를 정하는 건 정말 어려운 일이고, 그렇기에 어디에서나 일관성있게 통하는 리더십 법칙 같은 건 없다.

과거에 나는 좋은 팀은 어떻게 구성되는가, '심리적 안정감'은 왜 중요한가, (3개월 전쯤 썼던 "승리하지 못하는 조직에게 미래는 없다"에서도 썼듯) 승리하는 팀이 왜 중요한가 — 이런 온갖 리더십과 팀워크에 대한 책을 탐독하다가, 어느 순간 책을 통해서 무언가 답을 얻으려고 하는 것이 얼마나 편의주의적이고 게으른 생각인지를 깨닫고 관련된 책 읽기를 모두 내려놓았다. 독서는 가끔 우리에게 예상치 못한 배움과 깨달음, 경험을 주지만 리더십에 한해서 만큼은 다음과 같이 감히 말할 수 있다.

책을 덮고, 그 시간에 차라리 지금 팀원들과 1 on 1을 하라. 그리고 내가 하는 활동들이 정말 팀을 승리로 이끌고 있는지 되돌아보라.

그래서 내가 누군가에게 꺼내는 리더십 조각들은 여러 가지가 있지만, 결국 디테일을 놓칠 때, 위로 향하는 리더십과 정렬이 되지 않을 때, 팀원들의 변화를 세심하게 살피지 못할 때, 승리가 무엇인지 제시하지 못할 때 — 성공한 리더십보다는 밤잠 설치며 온몸으로 느꼈던 뼈저린 실패의 연속에서 만들어진 무엇인가다.

그래서 이 글은, 빌 월시의 원칙 요약이 아니다. 내가 여전히 실패하고 있는 지점들에 대한 기록이다. 그의 책이 거울처럼 비춰준 내 실패들을 하나씩 마주한 후기에 가깝다.

빌 월시(Bill Walsh, 1931~2007)는 풋볼계의 레전드이며, 스포츠 드라마의 뻔한 클리셰(허접한 팀에 부임한 감독이 그 팀을 어떻게 최정상의 팀으로 올려두고 유지했는가)의 주인공이다. 80년대 허접한 49ers(포티나이너스)를 왕조로 탈바꿈시킨 장본인이며, 매우 극도로 뛰어난 리더십을 보유한 명장이었다. 84, 88, 89 시즌 3번의 우승과 '웨스트 코스트 오펜스(WCO)'라는 전술을 처음 팀에 사용한 걸로 유명하다. NFL을 잘 모르는 내가 찾아본 바에 의하면, 풋볼 역사는 WCO 전후로 갈릴 정도로 역사적인 전술이라고 한다. (나는 한 번도 풋볼 게임을 제대로 본 적은 없다. 규칙을 몰라도 이 책을 읽는 데 전혀 문제 없다.)

나는 NFL을 잘 모르지만, 빌 월시의 리더십 책이 워낙 유명해서 "읽어야지, 읽어야지" 하며 고이 모셔둔 책이었다. 더 이상 일부러 1 on 1 해야 하는 팀원이 없는 지금 이 시점에, 내 실패를 되돌아보며 읽어보기 좋겠다 싶어서 읽은 책이다. 어쩌면 다음 번에 올 기회에 내가 조금은 나아지기를 바라며.

이 책이 정말 좋은 책인 건, 미국 풋볼 역사상 이토록 대단한 명장이 쓴 책이니 그의 성공과 후일담, 그리고 그로부터 도출되는 리더십 규칙 정도로 생각하고 책에 대한 인상을 가지기 쉬운데, 이 책의 제목 「점수는 저절로 따라오는 것이다(The Score Takes Care of Itself)」는 그가 진정으로 추구하고자 했던 리더십 원칙이자, 결국은 끝까지 지키지 못한 그의 원칙이기도 하다는 점이다. 이 책의 킥은 후반부에 있다. 전반부에서 그의 리더십 원칙들을 하나씩 따라가며 밑줄을 긋다가, 후반부에 들어서면 책의 성격이 통째로 달라진다. 그게 어떤 방식으로 달라지는지는, 본론의 마지막 섹션에서 풀어내려 한다.

나와는 비교할 수 없는 엄청난 성공을 거둔 다른 시대, 다른 나라, 다른 분야의 리더이지만 그의 성공적인 리더십 뒤에 느껴지는 고단함, 고독함, 피로함, 적나라한 그의 실수와 실패들 덕분에 오히려 그가 앞서 제시한 여러 리더십 원칙들이 더 와닿게 되었다. 그래서 이 후기는, 그의 원칙을 정리한 요약본이 아니라 그 원칙 앞에서 계속 걸려 넘어지고 있는 한 사람의 기록이 되었다.

점수는 저절로? — 승리는 여전히 평가 기준이다

「점수는 저절로 따라오는 것이다(The Score Takes Care of Itself)」. 처음 제목을 봤을 때 나는 살짝 경계했다. 3개월 전쯤, 나는 블로그에 "승리하지 못하는 조직에게 미래는 없다"는 글을 썼다. "Winning solves everything." 승리가 모든 것을 해결한다는 그 문장을 북극성 삼아, 조직에 승리를 정의하지 못한 리더는 결국 무너진다고 꽤 단호하게 적었다. 그런데 빌 월시는 정반대의 자리에 서 있는 것처럼 보였다. 승리를 쫓지 마라. 점수는 알아서 따라온다. 샌프란시스코 49ers를 슈퍼볼 세 번 우승으로 끌어올린 전설적인 코치가 하는 말이니 내 말이 틀렸을 가능성이 더 크다.

결론부터 쓰면, 아니다. 빌 월시와 나는 같은 지점을 서로 다른 방향에서 보고 있었다. 책을 덮을 때쯤 그게 선명해졌다.

빌 월시는 "최고 지침은 승리가 아니었다(The Prime Directive Was Not Victory)" 장에서 이렇게 말한다.

"대신에 있었던 것은 포괄적인 기준과 계획—숙련도, 즉 역량의 수준을 설치하여 필드 안팎의 모든 영역에서 우리의 생산 수준이 상대방보다 높아지게 하려는 것이었다. 그 너머에서 나는 점수가 알아서 해결될 것이라고 믿었다."

— "최고 지침은 승리가 아니었다 (The Prime Directive Was Not Victory)" 장

그리고 같은 장에서 조금 더 진솔하게 털어놓는다.

"나는 우리의 초점을 승리라는 상(prize) 보다는 개선의 과정에 맞추었다—어쩌면 우리의 실행 품질과 사고의 내용, 즉 우리의 행동과 태도에 집착했을 수도 있다. 나는 그렇게 하면 승리가 알아서 따라올 것이고, 따라오지 않을 때는 수행 기준을 높일 방법을 찾을 것임을 알았다. 적어도 그것이 나의 계획이었다."

— 같은 장

여기서 내가 멈춰 섰던 건 "적어도 그것이 나의 계획이었다"라는 마지막 한 줄이었다. 빌 월시는 승리를 치워둔 게 아니다. 승리를 노골적으로 쫓지 않는 방식 으로 승리를 쫓았을 뿐이다. 그는 기준과 과정에 집착했고, 그 집착이 작동하지 않으면 수행 기준을 다시 높일 방법 을 찾겠다고 말한다. 즉, 그의 과정도 결국 '승리했는가, 못 했는가'로 피드백을 받고 있었다는 뜻이다.

그래서 나는 이렇게 정리했다. 내가 승리를 최우선으로 두었다고 해서 과정을 무시하는 것은 아니다. 오히려 반대다. 과정에서의 원칙들은 결국 "승리"로 평가할 수 있어야 한다. 평가받지 않는 기준은 취미고, 평가받지 않는 과정은 자기 위안이다. 빌 월시가 숙련도에 그렇게 집착할 수 있었던 건, 풋볼이라는 세계가 매 일요일마다 점수판에 명확한 숫자를 찍어주기 때문이다. 매 경기 승패가 나오니까, 그는 승리를 입 밖에 꺼내지 않고도 승리로부터 도망칠 수 없었다.

그런데 비즈니스는 그렇지가 않다.

일반적인 비즈니스 조직에서 '승리'를 팀 전체에 정렬하는 작업은, 솔직히 풋볼보다 훨씬 난이도가 높다. 우리는 매주 점수판을 받지 않는다. 우리의 "승리"는 분기 지표일 수도, 프로덕트 지표일 수도, 때로는 3년 뒤에야 판가름 나는 전략일 수도 있다. 그래서 과정에만 집중하라고 놔두면, 그 과정이 정말 승리로 향하는 과정인지 아무도 묻지 않게 된다. 각자 열심히 하고 있는데, 방향이 제각각이라던가. (이걸 3개월 전 글에서 "승리를 정의하지 못한 조직"이라고 쓴 거다.)

그러니까 비즈니스 조직에서는 여전히 '승리'가 평가되는 것이 중요하다. 빌 월시처럼 과정에 집착하더라도, 그 과정이 무엇을 향해 있는지를 리더가 책임지고 정렬 해야 한다. 그게 안 되는 조직에서 "점수는 저절로 따라와요"라고 말하는 건, 내가 보기엔 그냥 책임 회피에 가깝다.

결국 빌 월시의 문장은 이렇게 읽어야 한다고 생각한다. 승리를 포기하라가 아니라, 승리로 향하는 매일의 기준을 포기하지 말라.

그는 "나 자신의 희생양이 되지 않는 법(How I Avoid Becoming a Victim of Myself)" 장에서도 같은 이야기를 다른 각도로 반복한다.

"상황에 상관없이 최고 수준에서 압박 속에 수행하는 핵심은, 행동 기준의 맥락 안에서의 준비, 그리고 당신의 리더십 철학에 담긴 행동과 태도를 조직이 철저히 체화하는 것이다."

— "나 자신의 희생양이 되지 않는 법 (How I Avoid Becoming a Victim of Myself)" 장

나는 "승리를 정의조차 하지 못한 조직은 무너진다" 였고, 빌 월시는 그 정의된 승리 위에서 매일을 어떻게 살아내야 하는지를 책에서 보여주고 있었다.

그가 "행동 기준"과 "조직의 체화"를 말할 때, 나는 정작 그 기준을 조직에 체화시키는 데 몇 번을 실패했는지 셀 수 없었다.

좋은 재능, 나쁜 태도 — 더 일찍 쳐냈어야 했다

좋은 재능을 가진 사람이, 팀의 기준에 맞지 않는 태도로 들어왔을 때.

빌 월시는 이 문장을 괄호 안에 던져 놓는다.

"당신의 구체적인 직무가 무엇이든 간에, 정신적이든 물리적이든 모든 다양한 측면에서 가능한 최고 수준으로 그 일을 하는 것이 우리 팀에 필수적이다 (즉, 좋은 재능 + 나쁜 태도 = 나쁜 재능)." — "성과 기준 (Standard of Performance)" 장

괄호 안이 더 크게 울렸다. 책을 덮고 한참을 멈춰 있었던 구절 중 하나다.

솔직히 나는 이 문장을 빌 월시보다 한참 늦게 배웠다.

자신의 분야에서 전문성을 계속 쌓아나가지만, 팀원들과의 협업이나 커뮤니케이션 능력은 형편없는 사람들을 여럿 겪었다. 한때는 그들의 재능에 매몰되어 그래도 그들의 역할이 있다고 생각했다. 이 사람을 빼면 이 파트가 무너진다, 지금 당장 대체할 수 있는 사람이 없다, 시간이 지나면 사람이 좀 달라지지 않을까 — 이런 변명을 나 스스로에게 계속 했다. 기준을 흐리고, 어깨를 들썩이고, 다른 팀원들에게 "원래 저런 사람이야"라고 설명하고 다녔다.

지금은 확신한다. 내가 생각하는 기준에서 좋은 태도를 가지고 같은 사이드에서 정렬되어 갈 수 있는 사람이 아니라면, 한시라도 일찍 팀에서 쳐내야 한다.

빌 월시는 이 부분에서 잔인할 정도로 단호하다.

"다양한 면에서 기준에 미달하는 개인은 대개 조용히 제거되었고, 나의 권위에 도전하는 자는 위험을 감수한 것이었다." — "최고 지침은 승리가 아니었다" 장

"조용히 제거". 드라마처럼 회의실을 박차고 나가거나 공개적으로 선을 긋는 장면이 아니다. 그냥 조용히, 그러나 확실하게 내보낸다. 빌을 옆에서 본 사람의 기록은 더 분명하다.

"빌은 충분히 영리했고 충분히 강한 의지를 가지고 있어서, 재능 있는 사람이라 해도 부정적인 조직 문화에 기여하는 사람(팀 플레이어가 아닌 사람)이라면 내보냈다." — "문제 해결사" 장

내보낸 것 자체가 선택이 아니라, 재능을 이유로 남겨두지 않은 것 이 선택이었다.

인상적인 문장은 따로 있었다. "인격을 찾아라, 캐릭터들을 조심하라(Seek Character. Beware Characters.)" 장에서 빌이 자기 자신을 돌아보는 대목이다.

"나는 그의 재능 때문에 내가 감당해야 하는 것보다 더 오래 이것을 용인했다. 하지만 그 상태에서 그의 플레이는, 마음을 다잡았다면 가능했을 수준에 한참 못 미쳤다."

빌도 그랬다. 4번의 슈퍼볼 트로피와 명예의 전당을 가진 그 사람도, 재능 때문에 "내가 감당해야 하는 것보다 더 오래" 끌고 갔다. 그리고 그걸 후회로 기록해두었다. 한 줄로. 나는 이 문장을 몇 번이고 다시 읽었다. 나 역시 감당하지 말았어야 할 것들을 재능이라는 이유로 감당했고, 그 결과는 고스란히 팀이 뒤집어썼다.

그리고 빌은 이 주제를 "Big Ego" 장에서 한 번 더 못 박는다.

"거만한 이기주의자가 조직에 끼치는 해악은 언제나 그가 주는 이점을 능가하기 때문이다."

언제나 (always). 빌이 이런 단어를 쉽게 쓰는 사람이 아니라는 점에서 이 문장은 더 무겁다. 이점이 해악을 이길 수도 있다가 아니고, 이점이 해악을 이기는 경우가 가끔 있다도 아니다. 언제나 해악이 이긴다.

결국 내가 매몰되었던 건 재능이 아니라, 재능을 놓치는 두려움이었다. 이 사람이 빠지면 안 된다는 불안이 기준을 계속 타협시켰다. 그 타협의 비용은 다른 팀원들이 치렀다. 태도가 나쁜 재능이 팀에 남아있는 동안, 그 팀의 "태도의 기준"은 그 사람이 정한다. 좋은 태도를 가진 사람들이 오히려 자기가 과한가 의심하기 시작한다. 그게 내가 뒤늦게 본 장면이다.

한시라도 일찍 쳐내야 한다. 이게 지금의 내 확신이다.

가르침이 리더십의 정의다 — 그런데 나는 인내심이 없다

빌 월시는 책의 제일 중요한 자리에서 이렇게 못 박는다.

"리더십이란, 그것이 최상일 때, 정확히 이것이다. 조직에 속한 개인들에게 기술, 태도, 목표를(그렇다, 목표는 정의되기도 하고 가르쳐지기도 한다) 가르치는 것이다. 삶의 대부분—가정을 꾸리고 아이를 교육하는 것, 회사나 영업팀을 운영하는 것, 선수를 코칭하는 것—은 훌륭한 가르침을 필요로 한다." — "가르침이 당신의 리더십을 정의한다" 장

리더십의 기술 이 아니라, 리더십의 정의 가 가르침이라고 말하고 있었다. 전략도, 비전 제시도, 의사결정도 아니고, 가르치는 것.

빌은 가르침을 조직의 최우선 과제라 부른다.

"슈퍼볼 우승(또는 시장 1위 달성, 의미 있는 분기별 생산 목표 달성, 대형 계약 수주)은 팀 전체가 각자의 일을 해낼 뿐만 아니라 그 일이 전체 성공에 기여한다고 인식할 때 이루어진다." — "최우선 과제는 가르치는 것이다(The Top Priority Is Teaching)" 장

"그리고 '성공은 모두의 것'이라는 이 조직적 인식은 리더가 가르치는 것이다." — 같은 장

"실패도 모두의 것이다. 당신이나 팀원 중 누군가가 '공을 떨어뜨리면' 모두에게 책임이 있다." — 같은 장

그는 은퇴할 무렵 자기 인생을 이렇게 정리한다.

"돌이켜보면, 내가 이끌어낼 교훈은 이것이다. 사랑하지 않는다면, 하지 마라. 나는 사랑했다. 사람들이 자신의 잠재력을 최대한 발휘할 수 있도록 깊이 파고드는 방법, 위대해지는 방법을 가르치는 것을." — "가르치는 일의 짜릿함(The Thrill of Teaching)" 장

사랑하지 않으면 하지 말라니.

나는 내가 가르치는 걸 좋아한다 고 오래 믿어왔다. 신입이나 주니어가 팀에 들어오면 그들을 끌고 가기 위해 스터디를 직접 조직했고, 필요하면 내가 직접 가르치기도 했다. 온보딩도, 코드 리뷰도, 1 on 1도 꽤 열심히 했다고 생각했다. 항상 좋은 코치, 좋은 선생이 되고 싶었다.

그런데 문제는 속도 였다. 내가 가르친 게 실제 업무에 반영되기까지는 각자의 속도가 다 달랐고, 나는 그 속도차를 충분히 견디지 못했다. 설명했는데 두 번째 리뷰에서 같은 문제가 또 보이면 속이 탔다. 세 번째엔 내 말투에서 티가 났다. 네 번째쯤엔 차라리 내가 하는 게 빠르다는 결론으로 도망쳤다.

항상 좋은 선생이 되고 싶었지만, 나는 생각보다 좋은 선생이 아니었다. 가르침을 좋아한 것과 가르침에 충분한 인내심을 쏟은 것은 전혀 다른 일이었다는 걸, 꽤 오래 구분하지 못했다.

그런데 더 뼈아픈 건 신입/주니어 쪽이 아니다. 두 번째 실패는 시니어들에게 있었다.

시니어에겐 내가 가르칠 게 없다고 단정했다. 그들은 독립적으로 알아서 한다, 내가 그들의 의지를 보장해줘야 한다, 주도적으로 만들어야 그들도 성장한다 — 이런 여러 판단이 겹쳐서 나는 그들을 사실상 방치 했다. 그걸 나는 오랫동안 자율 이라 불렀다.

가르침이 꼭 기술적인 영역에만 머물 필요는 없었다. 일의 방향, 조직의 원칙, 의사결정의 기준, 커뮤니케이션의 태도 — 이런 건 시니어에게도 충분히 전할 수 있었고, 오히려 시니어일수록 내가 챙겨야 하는 영역이었다. 그런데 나는 "알아서 하겠지"로 퉁쳤다.

어떤 면에서 그건 좋은 결정이기도 했다. 그들은 주도적으로 많은 걸 만들었다. 하지만 그들이 결정하지 말아야 할 것들까지 이미 결정이 된 뒤 에, 내 스스로 내 입지를 줄이는 일을 자초했다는 걸 깨달았을 땐 이미 너무 늦어 있었다. 방치는 자율이 아니었다. 방치는 그냥 내가 가르침이라는 노동을 회피한 것이었다.

빌 월시는 이렇게 쓴다.

"350파운드짜리 태클이든, 직원이든, 아이든, 우리는 격려하고, 지지하고, 영감을 주기 위해 최선을 다해야 한다. 하지만 결국—궁극적으로—사람들은 스스로 해야 한다." — "의지력은 이식할 수 없다(The Bubba Diet)" 장

이 문장은 내 방치를 변호해주는 듯 보이지만, 사실은 정반대다. 빌은 "의지력은 이식할 수 없다"고 말하기 전까지 격려하고 지지하고 영감을 주기 위해 최선을 다해야 한다고 전제를 깔아둔다. 그 최선을 다 한 다음에야 "결국은 스스로"가 유효해진다. 나는 그 전제 부분을 건너뛰고 결론만 가져다 썼다. 변명으로.

그리고 빌은 한 번 더 못 박는다.

"다른 사람이 자신의 일을 할 수 있도록 가르치고 훈련시키는 것." — "멘토를 해방시켜라(Unleash Mentors)" 장

이것이 리더가 멘토들에게 요구해야 하는 일이라고 그는 말한다. 그러니 그 출발점은 결국 리더 자신이 가르치는 사람이어야 한다는 뜻이다.

지금의 나는 어떤가.

조지와의 멘토링, 엘리와의 협업에서 나는 여전히 인내심이 부족하다. 내 머릿속의 생각과 아이디어는 이미 몇 단계 앞서 달려 있고, 그걸 따라오지 못하는 상대에게 답답해하는 내 모습이 종종 보인다. 한 번 설명하고 "아, 됐다"고 넘어가고 싶어한다. 상대가 다시 물으면 내 어조가 약간 날카로워지는 걸 스스로 느낀다.

어쩌면 이건 내가 다시 제품을 직접 개발하고 있어서일 수도 있다. 손을 다시 움직이는 사람은 머리가 빨라지고, 빨라진 머리는 옆 사람의 속도를 무시하기 쉽다. 하지만 그건 이유일 뿐 변명이 될 수는 없다.

오히려 매니저로서 리더십을 챙겨가던 시절보다 더 퇴보한 부분들도 보인다.

리더를 내려놓으면 사람으로서는 더 나아질 줄 알았는데, 실은 반대쪽으로 간 부분이 있었다. 매니저라는 위치가 강제로 나에게 씌워주던 인내심이라는 겉옷이 있었던 것 같다. 그 옷을 벗고 나니, 벗은 채의 내가 그렇게 훌륭하지 않다는 게 드러났을 뿐이다.

그래서 나는 요즘 이렇게 생각한다. 상대방을 탓하기 전에, 내가 어떻게 더 잘 전달할지를 고민하고 다듬어야 한다. 가르침은 상대가 받아야 완성되는 게 아니라, 내가 충분히 건넬 때까지 내 몫이라는 걸 이제야 조금 알 것 같다.

내면의 목소리 — 내 블랙 코미디가 심은 것

리더십 책에서 읽은 문장 중 가장 섬뜩 했던 건 이거였다.

"직원들이 실제 업무에 가지고 들어가는 진정한 영감, 전문성, 실행 능력은 대개 외부의 목소리가 외치는 것이 아니라, 내면의 목소리가 말하는 것의 결과다. 리더의 격려 연설이 아닌 것이다. 팀원들에게 있어, 그들 내면의 목소리가 무슨 말을 하는지는 리더인 당신이 결정한다. 리더는, 적어도 좋은 리더는, 팀이 자신에게 어떻게 말을 거는지를 가르친다. 효과적인 리더는 그 내면의 목소리가 무엇을 말할지에 깊은 영향을 미친다." — "내면의 목소리 대 외면의 목소리(The Inner Voice vs. the Outer Voice)" 장

격려 연설이 아니라 내면의 목소리. 외부에서 들려주는 말이 아니라, 팀원이 혼자 앉아 있을 때 스스로에게 하는 말. 그게 리더가 심는 것이다. 빌 월시는 그 앞 페이지에서 이렇게도 적었다.

"리더십은 전문성이다. 수사학도 아니고 응원 연설도 아니다. 사람들은 신뢰성과 전문성—직업에 대한 지식—을 갖추고, 인간 본성에 대한 이해를 보여주는 사람을 따른다." — 같은 장

그리고 자신의 언어를 어떻게 다뤘는지에 대해서는 이렇게 덧붙인다.

"누군가를 비판하거나 피드백을 줄 때, 나는 패배주의적 태도를 취하지 않았다. 항상 지금 이 순간에 초점을 맞췄고, 지난 며칠이나 몇 주간의 형편없는 플레이를 끌어들여 이미지를 만들어내지 않았다." — "언어의 레버리지" 장

비판할 때조차 과거를 끌어오지 않았다는 말. 현재에만 머무른다는 말. 빌 월시는 자신의 말이 팀원들의 어깨에 얹혀서 며칠, 몇 주를 같이 다닌다는 걸 알고 있었던 것이다. 그는 다음 페이지에서 이유까지 친절하게 적어두었다.

"항상 지적하고 비판하는 부정적인 사람으로 비춰지면, 주변 사람들에게 그냥 무시당하게 된다. 가르치고 영향을 미치며 발전을 이끌 능력이 줄어들다가 결국 사라진다." — 같은 장

이 대목에서 나는 고개를 들 수가 없었다.

나는 초반에 다른 팀과 협업할 때, 스타트업스럽지 않은 다른 팀의 대응과 허접한 소통 방식에 대해 공개적으로 비난하곤 했다. 경영진의 잘못된 결정이나 이해가 안 되는 부분이 있을 때도, 팀원들 앞에서 대놓고 비판했다. 그런 행동이 유머와 팀원들에 대한 공감으로 읽히길 바랐지만, 꼭 그렇지만은 않았다는 게 결론이다. 나의 말투가 팀원들의 행동에서 그대로 비치는 게 보였을 때 그제야 그만두려 했지만, 조금 늦었다는 생각이 들었다.

특히, 나의 (자칭) 블랙 코미디는 뼈저리게 좌절스러운 현실을 있는 그대로 직시하더라도 거기서도 우리가 할 수 있는 게 있다는 희망에 기반한 것들이었는데, 딱히 그 의도가 전달되지는 못했던 것 같다. (전달되지 못한 것 까지가 어쩌면 블랙 코미디의 완성(..))

솔직히, 내 안에는 그때도 분명 신념 같은 게 있었다고 생각한다. 우리가 더 나은 조직을 만들 수 있다는, 이 뻔한 현실 위에서도 뭔가 다르게 해볼 수 있다는 희망. 그런데 입 밖으로 나간 건 신념의 모양이 아니었다.

흘려보난 건 신념이 아니라 냉소였단 사실을 뼈저리게 깨달았다.

그리고 냉소는 희망보다 훨씬 더 전염성이 강한 언어가 아닌가. 내가 그러한 말과 행동을 그만두려 했을 때, 그 말들은 이미 팀원들의 입과 메신저와 회의실에 자리를 잡고 있었다. 내가 비우러 간 자리에 남아 있는 건 나의 의도가 아니라 나의 말투였다. 리더의 말이 팀원의 내면 목소리가 된다는 빌 월시의 문장은, 이 지점에서 나를 아프게 했다.

여기에 하나 더 얹혀 있는 기억이 있다. 하위 20퍼센트에 대한 이야기다.

오랜 경력을 가진 팀에 프로 '불평'러(..)가 있었는데, 그 행동을 제지하기 위해 더 강하게 얘기하지 못했다. 그를 설득하기 위해 1 on 1을 했을 때는 이미 너무 늦은 뒤였다. 그때 뼈저리게 느꼈다. 특히 위에서는 사람들을 설득해야 하는 입장이 되다 보니 부정적인 면보다 긍정적인 면을 보려고 하게 되고, 어떤 면에서는 스스로가 그렇게 이미 생각하고 있다. 하지만 실제로 그들이 무슨 얘기를 하는지 듣기를 망설일수록, 그 갭(나의 긍정과 그들의 부정)은 더욱더 커지며 결국은 돌이킬 수 없는 상태가 된다는 것을 깨달았다.

빌 월시는 이 메커니즘을 정확히 짚어두었다.

"내가 제대로 파악하지 못한 이유로, 하위 20퍼센트의 불평은 종종 나머지 80퍼센트의 긍정적인 열정을 압도한다. 나는 항상 반대여야 한다고 생각했지만, 그렇지 않다. 징징대는 자들이 불균형적인 영향을 미치는 것 같다." — "하위 20퍼센트가 당신의 성공을 결정할 수 있다(The Bottom 20 Percent May Determine Your Success)" 장

나는 그때 그 사람의 얼굴을 피했다. 그 사람이 뱉는 말이 회의에서 공기를 얼마나 무겁게 만드는지 알면서도, "저 사람만 저렇지 다른 사람들은 괜찮다"고 스스로를 설득했다. 부정적인 신호를 듣기 시작하면 내 긍정까지 흔들릴까봐 두려웠던 것 같다. 그렇게 미뤄둔 사이, 그의 냉소는 조용히 팀의 공용어가 되어가고 있었다. 빌 월시는 이렇게도 적었다.

"조직 내 이 요소—특수 역할이나 보조 역할을 하는 '하위 20퍼센트'—를 무시하는 리더는 화를 자초하는 것이다. 이 사람들이 잉여적이라고 느끼기 시작할 때, 그들의 불만은 마치 암이 몸 전체로 퍼지듯 조직 전체로 퍼질 수 있다." — 같은 장

암처럼 퍼진다. 이 비유를 읽으면서 나는 조금 전까지 반성하던 내 공개 비난의 장면과, 그 불만분자의 얼굴이 하나의 그림 위에 포개지는 걸 봤다. 내가 위에서 뿌린 냉소와, 아래에서 방치한 냉소가 같은 혈관을 타고 흐르고 있었다.

리더의 언어는 한 방향이 아니다. 위에서 아래로 떨어져서 내면의 목소리가 되기도 하고, 아래에서 올라오는 불만을 제때 마주하지 못하면 같은 색의 목소리로 번져 돌아오기도 한다. 그리고 그 사이에 있는 건 결국 듣기를 망설이는 그 몇 주, 몇 달 이다. 내가 듣기 싫어서 미뤄둔 시간만큼, 갭은 벌어지고, 조직은 조용히 무너진다.

위로 향하는 리더십 — 빌이 구단주에게 한 장을 할애한 이유

리더십 책을 들추면 대부분 아래로 향하는 리더십 이야기다. 팀원을 어떻게 이끌 것인가, 어떻게 가르칠 것인가, 어떻게 동기 부여할 것인가. 서점 한 코너를 통째로 채울 만큼 많다.

그런데 위로 향하는 리더십 은, 나는 어디서도 제대로 배운 적이 없다. 상사, 이사회, 투자자, 구단주 — 내 머리 위에 앉아 있는 사람들을 어떻게 다뤄야 하는지에 대해서는 아무도 말을 해주지 않는다. 실무자 시절엔 보스가 한 명이라 그나마 단순하지만, 중간 관리자가 되는 순간 그 관계는 내 일의 절반이 된다. 성과보다 때로 더 무거운 절반.

그래서 이 책에서 빌 월시가 구단주 에드 드바르토로 주니어(Edward J. DeBartolo Jr.)에 관해 한 장을 따로 할애해 쏟아내는 장면을 읽었을 때, 나는 좀 놀랐다. 전설적인 감독이, 은퇴 후의 회고에서, 자기에게 기회를 준 사람에 대해 "이래도 되려나" 싶을 정도로 거침없이 비판을 토해낸다.

그런데 더 놀라운 건, 그 긴 비난의 끝에서 빌이 다시 돌아와 그가 준 기회에 대한 감사 를 상기시킨다는 점이다. 빌에게 리더십의 무대를 내어준 것도 에드였고, 그 리더십이 서서히 망가져 간 원인이 된 것도 에드였다. 같은 한 사람이, 빌의 커리어를 만들고 또 갉아먹었다. 이 이중성을 빌은 숨기지 않고 책 한가운데에 그대로 펼쳐 놓는다.

처음 감독직을 맡던 시절을 빌은 이렇게 회고한다. "자율성과 권한" 장에서.

"동등하게 중요한 것은, 그가 조직의 모든 사람에게 내가 보스이며 그가 내 권위를 훼손하지 않을 것이라는 점을 알렸다는 것이다. 이 권한과 지원 없이는 비참한 상황을 감안할 때 내 과업은 사실상 불가능했을 것이다."

권한과 지원. 이 두 단어가 없으면 중간 관리자의 일은 "사실상 불가능"하다고 빌은 못 박는다. 그리고 한 권의 책 뒷부분으로 가면서, 그 권한과 지원이 서서히 거둬들여질 때 어떤 풍경이 펼쳐지는지 — 바로 그 장이 에드에 대한 장이다.

빌이 이 상황을 뭐라고 부르는지 그 제목부터 처연하다. 버텨라, 도움이 올 때까지 — 상사를 계속 안고 가라.

"당장 결과를 원하는 윗사람들이 섣불리 행동하지 않도록 막으면서, 동시에 아래 사람들이 포기하거나 반기를 들지 않도록 함께 일해야 하는 것이다"

이 한 문장에 중간 관리자의 삶이 전부 들어 있다. 위는 조급하고 아래는 지쳐 있다. 그 사이에서 양쪽을 동시에 붙잡고 있어야 한다. 놓치는 순간 어느 한쪽이 무너진다.

빌의 처방은 묘하게 실무적이다.

"나는 구단주(와 그의 고문들)가 내가 최대한의 노력을 기울이고 있으며 가족의 막대한 재정 투자의 모든 세세한 부분에 주의를 기울이고 있다는 것을 이해하길 바랐다"

"그는 내가 감독 겸 단장으로 일하던 초기 시절에 함께 일하기 정말 훌륭한 보스였다. 이는 어느 정도, 내가 지속적으로 그를 완전히 정보 공유 상태로 유지하려는 노력이 그에게 안도감을 줬기 때문이라고 생각한다"

그리고 그 유명한 구절.

"읽든 읽지 않든, 문서화된 정보—전망, 평가, 진행 보고서, 현황 업데이트—를 상사에게 쏟아부어라. 그런 다음 정기 미팅을 요청하라. 아주 전문적인 방식으로, 상사가 당신이 가능한 모든 것을 다하고 있으며 그것이 문서화되어 있다는 것을—사실 그들이 손에 쥔 저 두꺼운 폴더 안에 있다는 것을—이해하도록 만들어라"

슈퍼볼을 세 번 들어 올린 감독의 조언이, 결국 상사에게 정보를 끊임없이 쏟아부어서 안도감을 심어라 는 실무 팁이다. 읽든 안 읽든 상관없다. 폴더가 두툼하게 손에 쥐어져 있다는 감각, 그것이 위를 진정시킨다. 처음엔 너무 실무적이라 웃음이 나올 정도였는데, 다 읽고 나선 웃을 수가 없었다. 저 문장은 빌이 경험한 가장 고단한 계절에서 건져 올린 생존 매뉴얼에 가깝다.

그리고 한 마디를 더 얹는다. 공에서 눈을 떼지 마라.

"지는 시기나 반전 상황에서 당신의 운명을 결정할 수도 있는 사람들—보스, 이사회, 주주들—을 달래면서, 동시에 정말 중요한 것에 자신의 주의를 절대적으로 집중해야 한다."

위를 달래라. 동시에 정말 중요한 것에 집중하라. 두 개의 명령이 한 문장 안에 태연하게 공존한다. 빌은 이게 가능하다고 말하지만, 동시에 이게 얼마나 잔혹한 주문인지도 알고 있었던 것 같다. 책 한 장 전체가 그 잔혹함의 기록이다.

나는 빌 월시와 구단주의 관계에서, 내가 거쳐 온 회사들을 겹쳐 읽었다. 성격은 저마다 달랐지만 구조는 비슷했다. 아래로 향하는 리더십 만큼, 아니 그 이상으로 위로 향하는 리더십 이 중요하다는 것을 나는 그 무엇보다 뼈저리게 깨달았다. 그리고 아이러니하게도, 내 리더십의 기회를 열어준 사람들과 그 리더십이 망가진 이유가 되었던 사람들이, 어떤 면에서는 같은 자리에 있었다.

내 구체적인 경험을 여기에 담을 수는 없다. 담아서는 안 된다고 생각한다. 다만, 중간 관리자로 일하는 사람들 거의 모두가 비슷한 딜레마를 어디선가 겪고 있지 않을까 감히 짐작해 본다. 위의 조급함을 흡수하고, 아래의 피로를 흡수하고, 그 사이에 끼어 있는 자기 자신의 지침은 누구에게도 들키지 않은 채로.

나는 들이받았는가, 포기했는가

빌 월시는 책 후반부에 이런 문장을 남겼다.

"돌이켜보면, 결과가 해고가 되더라도 자기 자신을 위해 일어서야 할 때가 있다는 결론을 내렸다. 내가 그렇게 하지 않았다는 사실로 증명되듯이, 말하기는 쉽고 행동하기는 어렵다." — "Zero Points for Winning(승리에 0점 주기는 곧 지고 있다는 뜻이다)" 장

빌 월시다. 슈퍼볼을 세 번 들어 올린 사람. 그런 빌조차 "나는 자기 자신을 위해 일어서지 못했다"라고 고백한다.

빌은 또 이렇게 썼다.

"모든 사람이 의견은 가지고 있다. 리더는 결정을 내리는 데 대가를 받는다. 의견을 제시하는 것과 결정을 내리는 것의 차이는 리더를 위해 일하는 것과 리더가 되는 것의 차이다." — "리더십의 공통분모: 의지의 힘" 장

"무너진다면, 올바른 이유로 무너지고 싶었다. (…) 가장 힘든 것—용서할 수 없는 것—은 자기 방식이 잘못된 방식이었음을 인정하지 않고 행로 변경만이 승리로 가는 유일한 길인데도 실패하는 것이다." — "올바른 이유로 틀려라" 장

이 두 문장이 나란히 놓이면 섬뜩해진다. 의견이 아니라 결정. 무너지더라도 올바른 이유로. 그런데 나는 과연 그렇게 살았는가.

솔직히 말하면, 아니다.

진짜 잘되는 방법이 아니라고 진심으로 생각하고 있었지만, 내가 책임질 수도 책임지고 싶지도 않은 순간들에는 항상 타협을 했다. 의견은 있었고 심지어 답도 보였는데, 결정의 자리에 앉기 싫어서 뒤로 한 발 물러섰다. 그건 양보가 아니라 도망이었다.

직장인이 뭐 다 그렇지, 라는 말로 허접하게 위로받고 싶지는 않다. 그런데 이 말은 거짓말이다. 그러한 타협의 순간들이 결국 시간이 지나 스스로에게 상처가 된다. 그 장면들은 기억에서 지워지지 않고, 조용히 쌓여서 언젠가 "나는 그때 진짜 리더였는가"라는 질문으로 되돌아온다.

빌 월시조차 자기 자신을 위해 일어서지 못했다고 고백하는 자리에서, 내가 할 수 있는 것은 변명이 아니라 같은 질문을 나에게 던지는 것뿐이다.

"나는 정말 최선을 다해 들이받았는가? 아니면, 그냥 포기했던 것인가."

모든 일에는 대가가 따른다

전반부를 읽을 때 나는 빌 월시의 원칙들에 계속 밑줄을 그었다. 기준, 가르침, 태도, 내면의 목소리, 위로 향하는 리더십. 배울 게 많았고, 어느 순간부터는 "이 사람은 어떻게 이렇게 다 갖췄지?" 싶었다. 그런데 책 후반부로 들어서면서, 밑줄의 성격이 달라졌다. 그가 승리한 장면이 아니라, 무너지는 장면에서 멈추게 됐다.

빌 월시는 먼저 이렇게 경고한다.

"최상위 경쟁에서 연속 우승자가 드문 이유는, 어느 정도의 성공이 찾아오면 우리가 미처 준비하지 못한 방향 감각을 잃게 만드는 변화가 일어나기 때문이다." — "패배보다 승리가 더 다루기 어렵다" 장

그리고 한 장 뒤에 이렇게 덧붙인다.

"일이 가장 잘 풀리고 있을 때야말로 리더십에서 가장 강하고, 가장 엄격하고, 가장 효과적일 수 있는 기회가 있다. 강한 바람이 등 뒤에서 불고 있지만, 그 바람이 당신을 쓰러뜨리지 않도록 하려면 승리가 낳는 위험을 이해해야 한다." — "반복 우승이 어려운 이유" 장

승리가 낳는 위험. 이 표현이 오래 남았다. 우리는 보통 실패의 위험만 생각하는데, 빌은 거꾸로 말한다. 정말 위험한 건 일이 잘 풀릴 때라고. 그리고 이 경고는 단순히 전략적 조언이 아니었다. 그 경고는 자기 자신에게 하는 말이었다는 게, 뒤로 갈수록 분명해진다.

그가 자기 내면을 털어놓는 장이 있다. 제목이 "The Perfection of the Puzzle(퍼즐의 완성)"이다.

"40점 차이로 지고 싶지 않았다. 39점 차이로 지는 것을 선호했다. 우리가 20점 차이로 이기면, 한밤중에 깨어 어떻게 21점을 냈을 수 있었을지 열심히 생각했다." — 같은 장

20점 차이로 이긴 날, 한밤중에 일어나서 21점을 어떻게 냈을 수 있었을지 생각하는 사람. 그게 빌 월시다. 이긴 경기에서조차 1점을 더 내지 못한 이유를 밤새 복기하는 사람.

그는 계속 쓴다.

"내가 거기서 볼 수 있었던 정보를 잘못 계산했거나 무시한 것은 아닐까? 왜, 어디서 우리의 실행이 무너졌는가? 우리의 결정들, 나의 결정들 중에서 어느 것이 잘못됐거나 완전히 틀렸는가? 끝없이, 끝없이, 끝없이. 내가 추구하고 있었던 것은 완벽이었다고 생각한다." — 같은 장

끝없이, 끝없이, 끝없이. 그가 세 번 반복한 이 단어에서 그가 어떻게 살았는지가 보인다. 그리고 그는 이 완벽주의의 정체를 스스로 진단한다.

"이 모든 것은 점수를 높이거나 더 적은 점수 차이로 지려 한다기보다는, 내가 리더십과 성공을 위한 노력의 전 과정을 어떻게 인식했는지와 관련이 있었다. 나에게 그것은 풀어야 할 퍼즐이었고, 찾아 제자리에 놓아야 할 조각들이었으며, 해결해야 할 해법들이었다." — 같은 장

위대함의 동력이 그의 칼날이었다는 걸, 그는 본인이 제일 잘 알고 있었다.

그리고 책의 가장 무거운 장이 나온다. "Zero Points for Winning(승리에 0점 주기는 곧 지고 있다는 뜻이다)."

"나는 승리에 0점을 받았다.

승리는 패배의 고통을 지연시키는 것 그 이상도 아니었다. 나는 빠르게 다음 경기로, 또 다음 경기로 시선을 돌렸고, 각 경기는 두려움을 제거하는 것은 아무것도 없이 패배와 함께 오는 끔찍한 감정을 미루는 기회만을 제공했다.

이런 일이 벌어지면, 어떤 패배나 실수, 좌절도 매우 불안하고 심지어 파괴적이 된다. 자아상을 경쟁의 결과에 붙여놓았기 때문이다. 승리 역시 같은 이유에서 해로워질 수 있다. 즉, 승리가 자신의 가치, 자신에 대한 감정을 규정하기 시작하도록 허용하는 것이다." — 같은 장

이 문장 앞에서 나는 잠시 책을 덮었다.

슈퍼볼을 세 번 들어 올린 사람이, 자기 승리에 0점을 줬다고 고백한다. 그가 받은 트로피들은 기쁨이 아니라, 다음 패배의 두려움을 잠깐 미뤄주는 진통제였다는 거다. 그리고 그 고백 뒤에 한 줄이 있다. "자아상을 경쟁의 결과에 붙여놓았기 때문이다."

나도 그랬다. 결과를 자존감으로 가져갔던 시기가 분명히 있었다. 지표가 오르면 내가 괜찮은 사람 같고, 지표가 꺾이면 내가 형편없는 사람 같았다. 그렇게 살면 승리도 해롭다는 걸, 그때는 몰랐다.

빌은 그 대가가 어떤 모습으로 찾아오는지도 적었다.

"환경의 변동성과 감정적 소진이 당신을 완전히 고갈시킬 수 있고, 당신은 그것과 끊임없이 함께 살아간다. 그것은 당신을 매우 취약하고, 나약하게 만들 수 있다." — 같은 장

그리고 자신에게 경고를 남긴다.

"팀의 '승패 기록'을 자신의 자존감과 동일시하는 파괴적인 유혹을 피하라." — 같은 장

이 문장이 얼마나 무거운지는, 앞의 고백들을 다 읽은 뒤에야 느껴진다. 이건 이론이 아니다. 빌이 자기 자신에게, 그리고 자기와 같은 길을 걷고 있을 후배들에게 남긴 마지막 경고다.

그리고 그는 자기 완벽주의가 어디서 출발했는지도 솔직하게 본다.

"초창기에는 나도 그랬다. 내 일을 잘 처리하면 점수가 알아서 해결될 것이라고 굳게 믿었다. 그렇지 않을 때는, 코칭을 개선하고 팀의 성과 기준을 높이기 위해 더 열심히 일했다. 이것이 내가 그토록 끊임없이 스스로를 몰아붙인 이유 중 하나였다." — 같은 장

점수는 저절로 따라온다는 그의 철학조차, 뒤집어 보면 자기 자신을 끝없이 몰아붙이는 엔진이 되어 있었다는 자기 진단. 이 부분에서 나는, 이 책이 단순한 리더십 교과서가 아니라 한 사람의 고백록이라는 걸 받아들이게 됐다.

책의 마지막 장은 아들 크레이그 월시가 썼다. 아버지에 대한 장이다. 제목은 "THE WALSH WAY — A Complex Man. A Simple Goal."

"그는 완벽주의자였고, 완벽은 자신의 아이디어와 결정이 다른 사람들에 의해 여과되지 않고—그의 의견으로는 불가피하게 오해되고 잘못 적용되지 않고—온전히 실현될 가능성이 가장 높을 때에만 달성할 수 있다고 보았다. 책임자가 되어야 했다." — 같은 장

아들이 본 아버지의 모습이다. 차갑지도 뜨겁지도 않게, 있는 그대로. 위대한 아버지가 왜 끝까지 스스로를 놓지 못했는지를, 아들이 가장 짧은 문장으로 요약해버린다.

그리고 책의 마지막 문단.

"아버지는 가셨지만, 그의 피와 땀으로 얻은 리더십 교훈은 그대로 남아 있다. 어쩌면 지금 이 순간 그 어느 때보다도 더 유의미하게. 이 책에서 나눈 자신의 경험 중 무언가가 리더로서 당신 자신의 도전에 가치 있기를 바랄 것이라고 나는 안다. 그것은 그가 사랑하고 또 잘 해냈던 일을 다시 한 번 할 수 있었다는 의미일 것이다. 다른 사람들에게 있는 힘껏 위대해지는 법을 가르치는 것." — 같은 장 마지막 문단

이 마지막 문단에 와서, 나는 책을 조금 오래 덮고 있었다.

한 인간의 위대하고도 지극히 개인적인 역사를 본 느낌이었다.

리더십 책으로 시작해서, 한 사람의 생애로 끝난 책이었다. 퍼즐을 푸느라 한밤중에 깨어 21점을 생각하던 사람. 승리에 0점을 주던 사람. 결국 자기 자신과 화해하지 못한 채 그 모든 걸 책에 적어두고 떠난 사람. 그의 교훈을 아들이 마지막 장에 받아 적으며 책을 닫는다.

안도도 있었다. 나와는 비교할 수 없는 성공을 거둔 사람조차 이랬구나. 그 거대한 그림자와 그 거대한 대가가, 나의 작은 실패들 앞에서 묘한 위로가 됐다. 당신도 그랬구나, 라고.

동시에 서늘한 경고라는 것도 안다. 빌이 받은 대가의 무게를 생각하면, 그만한 위대함에 닿지도 않은 내가 같은 길을 걸어서 뭘 얻을 수 있을까. 결과에 자존감을 붙여 두고 사는 한, 승리도 나를 갉아먹고 패배는 나를 무너뜨린다. 거기에 예외는 없다. 빌 월시조차 예외가 아니었다면, 나는 더더욱 아닐 거다.

그래서 빌은 본인이 결국 그러하지 못했지만 언제나 지향했던 메시지를 다시 한번 강조한다.

"점수는 저절로 따라오는 것이다"

나가며 — 리더십 너머, 조금 더 나은 사람으로

책을 덮고 며칠이 지났다.

처음 든 생각은 서문에 적었던 그 문장 그대로였다. "어쩌면 다음 번에 올 기회에 내가 조금은 나아지기를." 다음에 내가 다시 조직을 이끌게 된다면, 그때는 빌 월시의 밑줄들을 조금 더 잘 써먹을 수 있지 않을까. 그런 식의 기대.

그런데 이 후기를 붙잡고 한 섹션씩 나를 뜯어보다 보니, 그 문장이 조금 수상하게 느껴지기 시작했다.

다음 기회. 그게 정말 그렇게 중요한가.

나는 "다음에 올 리더십 기회"를 상상하면서, 지금 이 순간의 나를 묘하게 유예하고 있었다. 다음에 제대로 해봐야지. 다음에 인내심 있는 멘토가 되어봐야지. 다음에는 위로도 아래로도 정렬된 리더를 해봐야지. 그 "다음"의 모호함이 오늘의 게으름에 알리바이를 만들어주고 있었던 것 같다.

그런데 빌 월시의 책에서 내가 제일 오래 멈췄던 건, 사실 전략도 원칙도 아니었다. "빠른 결과는 천천히 온다(Quick Results Come Slowly)" 장의 이 문장이었다.

"나는 이것이 당신의 직업에서도 사실이라고 믿는다. 시작 단계의 노력은 연속적인 노력의 일부이고, 당신의 성과 기준은 연속적인 기준의 일부다. 오늘의 노력이 내일의 결과가 된다. 그 노력의 질이 작업의 질이 된다. 하루는 다음 날과 연결되고, 그 달은 이어지는 해들과 연결된다."

— "빠른 결과는 천천히 온다 (Quick Results Come Slowly: The Score Takes Care of Itself)" 장

하루는 다음 날과 연결된다. 다음 기회 같은 건 따로 오지 않는다. 오늘 내가 어떻게 말하고, 어떻게 듣고, 어떻게 인내하고, 어떻게 들이받는지가 그대로 다음 날에 붙어서 온다. 같은 페이지에서 빌은 이렇게 마무리한다.

"당신 자신의 성과 기준이 당신이 누구이고 무엇인지가 된다. 당신과 당신의 조직은 위대함을 성취한다." — 같은 장

이 문장이 이번 독서에서 나를 가장 흔들었다. "당신의 성과 기준이 당신이 누구이고 무엇인지가 된다." 리더십 책의 마지막 한 줄인데, 읽고 나면 리더십 얘기로만 들리지 않는다. 내가 오늘 하루 동안 스스로에게 허락한 기준이, 결국 내가 어떤 사람인지를 정한다는 말로 읽힌다.

그러니까 내가 고칠 건 "다음 기회의 나"가 아니라, 지금의 나다.

단순히 "리더십"을 떠나서 — 엘리와 제품을 만들며 주고받는 한 줄의 피드백에서, 조지와의 멘토링에서, 카페에서 우연히 마주치는 누군가와의 짧은 대화에서 — 지금 스스로가 조금 더 나은 사람이 되는 걸 멈추지 않는 것. 거창한 리더십의 회복이 아니라, 그 정도의 성실함.

사실 이건 내가 예전에 이미 썼던 이야기다. 블로그 한구석에 "판단하지 말고 호기심을 가져라"라는 글을 적어둔 적이 있다. 남을 빠르게 판단하지 말고, 일단 호기심을 가지고 한 번 더 들여다보라고 나 스스로에게 다짐하는 글이었다. 그 글을 잊은 지 오래다. 최근의 나는 꽤 자주 판단부터 했다. 답답해했고, 먼저 결론을 냈다.

다시 되새겨야 할 것 같다. 조금 더 여유를 가지고, 친절하지만 엄격하게, 조금 더 나음을 추구하는 삶. 빌 월시가 다른 장에서 "당신은 강한 면모를 갖춰야 한다(You Must Have a Hard Edge)"고 썼을 때 그게 냉정함을 말한 게 아니었던 것처럼, 친절함과 엄격함은 서로의 반대말이 아니다. 나는 둘 다 부족했던 것뿐이다.

그런 사람이 된다면, 점수는 아마 저절로 따라올 것이다.

빌 월시의 원래 문장은 팀과 조직에 대한 것이었지만, 나는 이 책을 덮으며 그 문장을 한 사람 분량으로 줄여서 가져가기로 했다. 내가 어떤 사람인지가 오늘의 기준으로 정해진다면, 내일의 점수는 내가 굳이 지켜보고 있지 않아도 알아서 따라올 것이다. 적어도 나는 그렇게 믿어보려 한다.

AX팀을 만드는 순간, 당신의 조직은 AX에 실패한다

Tony Cho (https://flowkater.io) — Wed, 08 Apr 2026 13:00:00 GMT

AX팀을 만드는 순간, 당신의 조직은 AX에 실패한다

불편한 기시감

AX 한다고 AX 추진팀을 신설하는 순간, 이미 실패한 거다.

이 말이 과격하게 들릴 수 있다. 하지만 조금만 생각해보면 어디서 많이 보던 그림 아닌가. DX 추진 TF. 클라우드 전환 본부. 빅데이터 혁신팀. 조직에서 무슨 팀을 신설해서 전사 도입하겠다. 이게 대체 몇 번째인가. 될 리가 없다.

전편에서 나는 "조직에 Claude Code를 설치한다고 AX가 되지 않는다"고 썼다. 도입과 전환은 다르다는 진단이었다. 반응이 꽤 있었는데, 돌아온 질문은 하나로 수렴했다.

"그래서 어떻게 해야 하나?"

이번에는 그 질문에 답하려 한다.

MIT NANDA 연구에 따르면 기업 GenAI(생성형 AI) 파일럿 프로젝트의 95% 가 실패한다. 95%다. 거의 전멸이다. 그런데 성공한 5%에는 분명한 공통 패턴이 있었다. Central AI lab(중앙 AI 연구소)이 주도한 조직이 아니라, 현장의 line manager(현장 관리자)가 adoption(도입)을 주도한 조직이었다. 별도의 AI 조직을 만든 곳이 아니라, 기존 현장 조직이 직접 움직인 곳이 살아남았다.

솔직히 고백하자면, 나도 여러 번 봤고 직접 만든 적도 있다. 추진 TF. 전환 본부. 위선이다. 그때도 안 됐다. 이번에도 안 된다.

왜 안 되는가. 그리고 그러면 대체 어떻게 해야 하는가.

계층을 없애야 하는데, 계층을 쌓고 있다

AX의 본질은 계층을 줄이는 것이다. AI가 중간 과정을 흡수하면서 의사결정과 실행 사이의 거리를 좁히는 것. 그런데 AX 추진팀을 만드는 건 정반대다. 기존 계층 위에 또 하나의 계층을 올리는 것이다.

이 역설의 가장 극적인 사례가 Coca-Cola의 Project Fizzion이다.

139년 역사의 소비재 기업 Coca-Cola는 AI 기반 전환을 전사적으로 추진했다. Adobe와 함께 Project Fizzion을 공동개발했고, 동시에 AI holiday 광고 실험도 강하게 밀어붙였다. 세계에서 가장 오래된 브랜드 중 하나가 AI 시대의 선두에 서겠다는 포부였다.

그런데 정작 현장에서 먼저 돌아온 건 환호가 아니라 반발이었다. AI holiday 광고는 실제로 거센 반발을 불렀다. 그리고 CEO James Quincey는 본인 입으로 이렇게 말하고 사임했다. "완전히 새로운 전환을 감당할 에너지가 필요하다(someone with the energy to pursue a completely new transformation)." Atlanta 본사에서는 약 75개 직위가 1차 구조조정 대상이 됐다.

여기서 중요한 건 광고 한 편이 실패했다는 얘기가 아니다. 139년 된 회사가 AX를 하나의 프로젝트처럼 밀어붙였고, 그 대가를 리더십과 조직 전체가 함께 치렀다는 점이다.

공교롭게도 비슷한 시기에 호주 최대 은행 Commonwealth Bank에서도 같은 결의 문제가 터졌다. 이쪽은 더 적나라했다. AI 음성봇을 도입하면서 콜 볼륨이 줄어들 것이라는 판단 아래 CS 인력 45명을 해고했다. 그런데 실제로는 콜 볼륨이 오히려 늘었다. 관리자들까지 전화를 받아야 했다. 은행은 공식적으로 판단 오류를 인정하고 45명을 다시 채용했다. GitHub Copilot도 도입했지만 성과가 엇갈렸고 결국 접었다. 노조는 이걸 전면 번복이라고 불렀다. 한 달 만의 일이었다.

펜타곤의 CDAO는 R&E(연구·공학) 산하로 재편됐다. 독립 조직으로 밀어 올렸던 AI 기능이 다시 연구·공학 체계 안으로 들어간 것이다.

Coca-Cola, Commonwealth Bank, 펜타곤은 업종도 다르고 규모도 다르다. 그런데 별도 AI 조직이나 중앙 추진 방식이 기대만큼 작동하지 않았거나, 결국 다시 손을 봐야 했다는 점만큼은 닮아 있다.

재밌는 건 Fortune이 2026년 3월에 보도한 데이터다. CFO가 주도한 AI 프로젝트의 76% 가 "great value"를 달성했다. 그런데 기업 중 CFO에게 AI 역할을 부여한 곳은 고작 2% 였다.

이 두 숫자를 나란히 놓으면 역설이 보인다. 실적과 비용의 현실을 가장 잘 아는 사람이 AI를 주도할 때 성과가 나는데, 대부분의 조직은 새로운 직함(CAIO)을 만들어 별도 조직에 맡긴다.

Intel의 CAIO는 7개월 만에 OpenAI로 떠났다. 7개월. 명함도 채 닳기 전이다.

그리고 이건 AI 조직만의 문제가 아니다. Coca-Cola의 James Quincey, Walmart의 Doug McMillon 같은 대기업 CEO 교체가 AI 전환 국면과 맞물려 일어나고 있다는 것도 시사적이다. AX는 도구 하나 들이는 프로젝트가 아니라, 리더십과 조직 설계 전체를 흔드는 일이라는 뜻이다. 별도 조직을 만드는 순간, 기존 조직은 AX를 남의 일로 만든다.

이게 AX 추진팀 역설의 핵심이다. 계층을 없애야 하는 일에 계층을 하나 더 쌓고 있으니, 구조적으로 실패할 수밖에 없다.

도구 담론의 한계: 이건 효율의 문제가 아니라 정체성의 문제다

오늘날 AX 담론 중 상당수는 Claude Code나 Copilot 같은 도구 시연에 머문다. 이게 됩니다, 신기하죠, 여러분들도 AX 할 수 있습니다. 그런 글을 쓰는 사람들 중에는 스타트업 창업자도 있고, 1인 개발자도 있고, 컨설턴트도 있다.

이해한다. 그들도 생존해야 하니까. 도구 시연은 보기 좋다. 반응도 잘 나온다.

하지만 기업 현실은 다르다. 보수적이고 굼뜨다. 그런데 만약 당신이 AX 담당자로서 "이 좋은 걸 왜 안 쓰지?"라고 되묻는다면, 당신의 AX는 끝난 거나 다름없다.

문제는 도구가 아니라 사람이다. 더 정확히 말하면, 사람이 자기 일을 어떻게 이해하고 있는가의 문제다.

사람들은 직무를 정체성으로 생각한다.

"나는 기획자다."

"나는 마케터다."

"나는 백엔드 개발자다."

AX가 요구하는 건 이 정체성의 해체다. 내 직무의 상당 부분을 AI가 대신하고, 나는 이전과 다른 역할을 해야 한다는 것. 이건 효율의 문제가 아니라 정체성의 문제다. 도구 하나 깔아준다고 해결될 일이 아니다.

예를 들어 15년차 마케터가 있다고 치자. 그 사람은 주간 리포트를 쓰고, 캠페인 문구를 다듬고, 성과를 정리하는 데 자신의 전문성을 쌓아왔다. 그런데 어느 날 AI가 3시간 만에 자신의 일주일치 리포트를 뽑아내는 걸 본다. 그때 드는 감정이 뭘까. "신기하다"일까. 아니다. 대부분은 그 전에 이런 감정이 먼저 온다.

"그럼 나는 뭐지?"

백엔드 개발자도 비슷하다. 자신이 몇 년 동안 익힌 패턴을 AI가 제법 그럴듯하게 복제하는 걸 보면, 단순히 생산성 도구를 본 게 아니라 자기 전문성의 경계를 다시 보게 된다. 여기서 사람을 움직이게 하는 건 더 좋은 데모가 아니다. 그 불안을 견디고, 새로운 역할로 이동할 수 있게 만드는 구조다.

그래서 AX는 도입보다 전환이 어렵다. 도입은 라이선스를 사면 된다. 전환은 사람의 정체성을 다시 짜야 한다.

이건 한 회사만의 문제가 아니다. 데모는 넘치는데, 그다음 월요일에 사람이 뭘 해야 하는지 말해주는 회사는 거의 없다. "당신 직무의 60%가 자동화됩니다"까지는 말한다. 그러나 "남은 40%에서 당신은 이제 무엇을 책임져야 합니다"까지 가는 회사는 드물다. 전자는 기술 이야기다. 후자는 사람 이야기다. 도구를 중심으로 한 AX는 필패한다.

도구를 몰라서 AX를 못 하는 게 아니다. 조직과 사람을 몰라서 못 하는 것이다.

조직을 모르는 사람은 조직을 못 바꾼다

스티브 잡스는 1992년 MIT 강연에서 컨설턴트를 비판했다. 요지는 이렇다. 결과를 소유하지 않고, 실행을 소유하지 않는 사람은 가치의 극히 일부만 만들어낸다고. 조직의 바깥에서 안을 바꾸려는 시도 자체에 대한 불신이었다.

나는 여기에 거의 100% 동의한다. 다만 내 경우는 조금 특이했다. 매일 붙어서 일했고, 사실상 조직 안에 반쯤 들어간 상태로 움직였다. 대부분의 컨설팅은 이렇게 동작하기 어렵다. 그래서 더 예외적인 사례였다.

이 이야기를 공개적으로 하는 건 처음이다.

컨설팅으로 시작했다. 한 회사의 기술 조직을 점검해달라는 의뢰가 왔다. 주 4번을 하루 3시간씩 저녁 시간에 회사에 출근을 했다. 퇴근 후에 다른 회사로 출근하는 거다. 말이 컨설팅이지, 실상은 저녁마다 3시간씩 그 조직의 코드를 읽고, 회의에 들어가고, 사람들과 이야기하는 일이었다.

나랑 처음 같이 진행했던 해당 직원 두 명은 내가 컨설팅을 하는 덕분에 강제로 야근을 하게 된 셈이다. 그 두 사람과 매일 저녁 코드를 보고, 아키텍처를 토론하고, 조직의 문제를 이야기했다.

한 달간 깊게 조직을 이해하게 되었다. 코드베이스의 상태, 기술 부채의 위치, 팀 간 커뮤니케이션의 병목, 사람들의 역량과 불만과 야망. 한 달이면 짧다고 생각할 수 있다. 하지만 주 4번, 매번 3시간, 한 달이면 거의 50시간이다.

그러면서 내가 바꾸고 싶은 부분에 대해서 더 많은 욕심이 생겼다. 컨설팅으로 끝낼 수 있는 수준이 아니었다. 바깥에서 조언만 해서는 절대 바뀌지 않을 것들이 보였다.

나는 백엔드 아키텍처나 비즈니스를 이해해서 그런 결정을 내린 것이 아니다.

나는 나랑 같이 일할 사람들이 누군지가 중요했다. 회사에서 쓰는 기술 스택은 내가 한 번도 사용하지 않은 기술들이었다. Node.js(당시에 나는 Ruby/Python을 거쳐 한창 Go로 프로젝트하던 상태였고, Node.js를 실무 수준에서 다뤄본 적은 없었다), 컨설팅 메인 프로젝트였던 Kafka도 이전에는 해본 적 없는 스택이었다. 기술적으로 보면 내가 합류할 이유가 없었다.

하지만 한 달 동안 매일 저녁 만난 그 사람들(그 두 명의 직원, 그리고 그 팀의 다른 멤버들)과 함께라면 무언가 바꿀 수 있겠다는 확신이 생겼다.

기술은 배우면 된다. 도메인은 파면 된다. 하지만 같이 일할 사람이 없으면 아무것도 안 된다.

그래서 CTO로 합류했다.

이 경험에서 내가 배운 건 하나다. 조직을 바꾸려면 먼저 조직을 이해해야 하고, 조직을 이해하려면 시간을 써야 한다. 외부에서 프레임워크를 던져주는 것으로는 절대 안 된다. 매일 저녁 3시간을 쓰면서, 그 조직의 코드와 사람과 문화를 직접 만져야 비로소 무엇이 문제인지, 무엇부터 바꿔야 하는지가 보였다.

하지만 그것조차 새발의 피였다. 풀타임으로 일하기 시작하니, 컨설팅 기간에는 보이지 않던 문제들이 산더미처럼 쌓여 있었다. 조직 구조부터 서버 운영 이슈까지, 처음 몇 달은 여러 문제를 동시에 맞느라 제때 퇴근한 적이 거의 없었다.

AX도 마찬가지다. AI 도구를 던져주면서 "자, AX 하세요"는 통하지 않는다. 새로운 사업부나 기존 조직에서 작은 부분부터 떼어내서 실험해야 한다. 그 실험은 도구의 실험이 아니라 일하는 방식의 실험이다. 그리고 그 실험을 이끄는 사람은 조직의 사람들을 알아야 한다.

조언은 쉽게 할 수 있다. 하지만 조언의 결과를 끝까지 책임지는 건 전혀 다른 일이다.

이게 내가 AX 이야기를 할 때 자꾸 사람으로 돌아오는 이유다.

잭 도시가 "From Hierarchy to Intelligence"에서 말한 AI-native 조직 이야기를 읽으면서, 나는 이 문장이 인상 깊었다. 계층은 원래 사람을 관리하기 위한 구조가 아니라, 정보를 라우팅하기 위한 구조였다. 로마 군대부터 철도 회사, 현대 대기업까지 조직은 늘 같은 문제를 풀어왔다. 누가 무엇을 알고, 그 정보를 누구에게 전달하고, 누가 결정을 내릴 것인가. 우리가 너무 자연스럽게 받아들여온 팀장, 실장, 본부장, PM, 중간관리자 같은 층위도 결국은 이 정보 전달 비용을 감당하기 위해 생겨난 구조였다.

이 관점으로 보면 지금 벌어지는 변화의 본질도 조금 다르게 보인다. AI가 단순히 일을 빨리 해주는 게 아니다. 정보를 모으고, 요약하고, 정리하고, 넘기는 데 필요했던 인간적 중간층의 역할 자체가 흔들리고 있다. 예전에는 사람이 위로 보고하고, 옆으로 조율하고, 아래로 전달해야 조직이 굴러갔다. 그런데 이제는 AI가 그 과정의 일부를 가져간다. 문서를 읽고, 초안을 만들고, 맥락을 정리하고, 데이터를 요약한다. 그 순간 계층은 무조건 필요한 구조가 아니라, 경우에 따라서는 속도를 늦추는 구조가 된다.

대부분의 회사는 여기서 멈춘다. 기존 조직에 AI 코파일럿을 붙인다. 문서를 더 빨리 쓰고, 회의록을 더 빨리 정리하고, 리포트를 더 빨리 만든다. 기존 구조를 그대로 둔 채 조금 더 효율적으로 돌리는 것이다. 이것도 의미는 있다. 하지만 잭 도시가 던지는 질문은 그보다 훨씬 깊다. 회사를 더 효율적으로 돌릴 것인가, 아니면 회사가 돌아가는 방식 자체를 다시 설계할 것인가. 전자는 자동화고, 후자는 조직 재설계다. 내가 이 글에서 계속 구분하고 있는 것도 사실 이 둘이다.

이 프레임으로 다시 보면 앞에서 했던 이야기들이 한 줄로 묶인다. AX 추진팀을 신설하는 건 계층을 줄여야 하는 순간에 계층을 하나 더 올리는 일이다. 사람들이 불안해하는 이유도, 결국 자신이 맡아왔던 정보 전달과 조율의 역할이 바뀌기 때문이다. 내가 CTO로 합류하기 전에 한 달 동안 조직을 읽었던 이유도 마찬가지다. 결국 조직 문제는 사람 개개인의 역량보다, 정보가 어떻게 흐르고 누가 무엇을 책임지는가의 문제였다. 그 흐름을 못 읽으면 조직은 못 바꾼다.

그래서 이제 다음 질문은 자연스럽다. AI 시대의 조직은 더 많은 계층을 필요로 하는가, 아니면 더 적은 핸드오프와 더 선명한 책임을 필요로 하는가. 내가 보기엔 답은 이미 나와 있다. 사람이 전달자보다 판단자에 가까워질수록, 팀은 더 작아지고 책임은 더 끝까지 이어져야 한다. 그리고 바로 그 지점에서, AX는 결국 End-to-End의 이야기로 들어간다.

AX는 결국 End-to-End다

전편에서 나는 조직을 5개의 축으로 분해했고, 그중에서도 가장 중요한 축으로 End-to-End 책임 조직을 꼽았다. Discovery(무엇을 만들지), Delivery(어떻게 만들고), Distribution(어떻게 팔지)를 하나의 팀이 끝에서 끝까지 보는 구조.

전편을 안 읽은 독자를 위해 한 문장만 더 보태자. 이건 만능 1인 회사를 만들자는 얘기가 아니다. 책임의 중심이 끊기지 않는 구조를 만들자는 뜻이다. 누가 문제를 정의했고, 누가 만들었고, 누가 결과를 끝까지 봤는지가 흐려지지 않는 구조.

AI가 바꾼 건 간단하다. 한 사람의 커버리지. 기획서도 AI가, 코드도 AI가, 데이터 분석도 AI가 거든다. 이전에는 세 팀이 오가며 하던 일을 이제는 훨씬 작은 팀이 감당할 수 있다. 분업의 필요성 자체가 줄어들었다.

Abnormal Security CEO Evan Reiser가 "The Projection Problem"이라고 부르는 현상이 이걸 잘 설명한다. 아이디어는 고차원이고, 언어는 저차원이다. 전문가가 PM에게 설명하고, PM이 스펙을 쓰고, 엔지니어가 구현할 때마다 — 매 핸드오프가 손실 압축이다. 같은 그림자를 보고 "우리 얼라인됐다"고 생각하지만, 실제로는 각자 다른 제품을 상상하고 있을 수 있다. Reiser는 이걸 해결하기 위해 20년 경력 CISO를 제품 책임자로 직접 앉히고, AI가 그의 머릿속을 인터뷰하는 구조를 택했다. Expert → AI. 핸드오프 1번. End-to-End가 왜 필요한지의 가장 깔끔한 설명이다.

그래서 AX의 방향은 자연스럽게 End-to-End로 간다. 더 작은 팀. 더 짧은 핸드오프. 더 분명한 책임.

이 말이 허황된 구호처럼 들릴 수도 있다. 그런데 이미 그렇게 움직이는 조직들이 있다.

Lumen Technologies는 더 근본적인 접근을 택했다. 30년 된 레거시 통신사. CEO Kate Johnson(전 Microsoft)이 한 일은 도구를 도입한 게 아니라 회사의 정체성을 재정의한 것이다. "레거시 통신사"에서 "AI 경제의 백본"으로.

영업팀에 Microsoft 365 Copilot(업무용 AI 어시스턴트, GitHub Copilot과는 다르다)을 파일럿한 뒤 전 직원으로 확산시켰고, "챔피언 프로그램"으로 부서마다 AI 전도사를 지정했다. 숫자가 인상적이다. 영업사원 한 건의 고객 리서치에 4시간 걸리던 작업이 15분으로 줄었다. 3,000명 이상의 영업 조직에서 주당 평균 4시간을 절약하고, 12개월로 환산하면 $50M 매출 가치를 만들어냈다.

JPMorgan Chase는 더 근본적으로 갔다. 이 회사는 AI를 기술 부서의 하위 주제가 아니라 경영 핵심 안건으로 다루고 있다. 실제로 JPMorgan은 CDAO(Chief Data & Analytics Officer, 최고데이터분석책임자) Teresa Heitsenrether를 경영위원회(Operating Committee) 멤버로 두고 있다. AI를 별도 조직으로 빼낸 게 아니라, 조직의 핵심 의사결정 테이블에 올린 것이다.

Walmart도 비슷한 방향으로 움직이고 있다. 이 회사는 파편화된 AI 기능을 고객·직원·파트너·개발자용 4개의 super agent로 통합하고 있다. 당시 Walmart U.S. CEO John Furner는 Fortune Brainstorm Tech에서 "2~5년 뒤에도 인원수는 지금과 대체로 비슷할 것"이라고 말했다. 이 말의 뜻은 단순하다. AI로 생산성은 더 높아지겠지만, 그걸 곧바로 사람 수를 줄이는 일로 연결하지는 않겠다는 것이다. 같은 규모의 조직으로 더 큰 사업을 굴리고, 사람의 역할 내용 자체를 바꾸겠다는 선언에 가깝다.

Lumen(통신), JPMorgan(금융), Walmart(유통). 이 회사들의 공통점은 AX팀을 별도로 만든 게 아니라, 기존 조직의 역할과 구조를 직접 바꾸고 있다는 것이다.

전편에서 내가 Maker와 Closer를 나눴던 것도 같은 맥락이었다. 산출만 하는 사람을 늘리는 게 아니라, 결과를 끝까지 완결하는 사람을 늘려야 한다는 것. 마이리얼트립 이동건 대표가 말한 방향 전환("더 잘 만들기"보다 "직접 팔 수 있는 사람 늘리기")도 그 연장선에 있다. 개발과 마케팅, 제품과 세일즈 사이에 있는 벽을 낮추겠다는 선언이다.

예전에는 이 벽을 넘으려면 다른 팀에 요청해야 했다. 자료를 받아야 했고, 기다려야 했고, 설명해야 했다. 지금은 다르다. 개발자가 AI로 광고 카피 초안을 만들고, 고객 피드백을 분류하고, 간단한 데이터 해석까지 직접 해볼 수 있다.

그런데 여기서 한 걸음 더 들어가면, 이건 개발자에게 영업을 시키자는 얘기가 아니다. 개발자가 고객의 목소리를 직접 듣고, 그 피드백을 다음 스프린트에 바로 반영하고, 자신이 만든 기능의 비즈니스 임팩트를 숫자로 확인할 수 있게 하자는 뜻이다. 마케터도 마찬가지다. AI가 기획서 초안을 써주니까, 마케터는 이제 제품 방향에 대한 판단에 더 많은 시간을 쓸 수 있다. 예전에는 "개발팀이 이걸 언제 해주지?" 기다리느라 써야 했던 에너지를, 이제 "고객에게 진짜 필요한 게 뭘까"에 쓸 수 있게 된다.

모든 사람이 모든 일을 하라는 얘기가 아니다. 다만 예전처럼 벽 하나를 넘을 때마다 회의실을 예약할 필요는 줄어들었다는 뜻이다.

그리고 이때 비로소 Maker는 Closer가 된다. 전편에서 내가 나눈 이 구분은 이제 추상적 개념이 아니라 현실이 되고 있다. 산출만 하던 사람이 결과를 끝까지 보는 사람으로 바뀌는 것. 그게 AX 조직에서 개인 레벨에서 일어나는 실제 전환이다.

AX가 성공하는 곳은 직무 중심이 아니라 문제 해결 중심의 작은 팀이다. End-to-End를 책임지는 팀, 핸드오프가 최소화된 팀, 한 팀이 Discovery부터 Distribution까지 보는 팀. AX 추진팀이라는 별도 조직이 아니라, 기존 조직 하나하나가 스스로 AX되는 구조를 만들어야 한다.

도구를 밀어붙이는 게 아니라 필요가 도구를 끌어당기게 해야 한다.

계층이 사라지고 역할이 바뀐다는 것

같은 조직이지만, 이번에는 구조가 아니라 개인의 역할이 어떻게 바뀌는지를 본다.

많은 사람이 AX를 IT 부서의 일로 본다. 개발팀이 AI를 쓰고, 디자이너가 코드를 쓰고, PM이 에이전트를 돌리는. 물론 그런 변화도 중요하다.

하지만 진짜 AX는 IT가 아닌 현장에서 일어난다.

최근 OpenAI Codex 팀의 사례가 이걸 잘 보여준다. 이 팀에서 디자이너는 직접 코드를 쓰고, PM은 전달자가 아니라 빌더형 오너로 일하고, 엔지니어는 코드 작성보다 시스템 감독에 집중한다. AI 개발팀이니까 가능한 얘기 아니냐고? 원칙을 보면 그렇지 않다.

"디자이너가 빌더가 되고, PM이 오너가 되고, 엔지니어가 감독자가 된다." 이 원칙은 AI 회사의 개발팀에만 적용되는 얘기가 아니다. 이건 업종을 불문하고, 역할의 경계가 재정의되는 시대의 보편적 현상이다.

유통을 보자. Walmart에서 매장 운영 담당자는 더 이상 본사에 요청만 넣는 사람이 아니다. 재고와 판촉과 고객 반응을 더 짧은 루프로 직접 다루게 되고 있다. AI 시스템이 만든 건 화려한 AI 대시보드가 아니라, 현장의 판단 반경을 넓힌 것이다. Target도 마찬가지다. Enterprise Acceleration Office는 전사 속도와 민첩성을 높이기 위한 조직이다. 매장 현장에서 의사결정과 실행 사이의 거리를 줄이는 것.

금융은 더 극적이다. Bank of America의 Erica는 누적 32억 건 이상의 상호작용을 처리했고, 사용자의 98% 이상이 필요한 정보를 찾는다. 그런데 정말 중요한 건 이 숫자가 아니다. Bank of America가 한 일은 소비자용 Erica를 만들고, 그 엔진을 직원용으로, 자산운용용으로, 기업금융용으로 재사용한 것이다. "Build Once, Reuse(한 번 만들고 재사용)". 한 엔진을 조직 전체로 확산시킨 전략이다.

이게 현장에서 뭘 바꿨나. 상담과 심사와 운영이 각자 문서만 넘기는 구조에서 벗어나, 고객 문제를 더 가까운 곳에서 끝까지 보게 된 것이다. 상담사가 AI에게 반복적인 질의를 맡기면서, 복잡한 금융 문제에 더 깊이 들어갈 여유가 생겼다. 심사 담당자도 마찬가지다. 서류 검증에 쏟던 시간을 줄이고, 실제 리스크 판단에 더 집중할 수 있게 됐다.

Bank of America CIO의 말이 인상적이다. "초반에 속도를 늦추는 규율이 장기적으로는 훨씬 빠른 가속을 만든다." 이건 도구 도입 속도를 경쟁하는 조직들이 가장 먼저 귀담아들어야 할 말이다.

통신도 마찬가지다. Lumen Technologies에서 영업사원이 리서치에 4시간 쓰던 걸 15분으로 줄이고, 남은 시간에 고객과 더 깊은 대화를 한다. 이전에는 고객 미팅 전 자료를 모으느라 반나절을 날렸다. 지금은 15분이면 고객사의 업종 트렌드, 기존 계약 이력, 잠재 니즈까지 정리가 된다. 영업사원의 역할이 "자료 수집자"에서 "고객 문제 해결자"로 바뀐 것이다.

제조업도 예외가 아니다. UAE의 Emirates Global Aluminium(EGA)은 CDO(Chief Digital Officer, 최고디지털책임자)를 중심으로 조직 횡단 실행 모델을 만들고, 3,000명 이상의 직원을 재교육했다. 2025년 WEF(세계경제포럼) Industry 4.0 Global Lighthouse로 선정됐다. 알루미늄 업계 세계 최초다.

여기서 공통 패턴이 보인다.

유통에서도, 금융에서도, 통신에서도 사람의 직무가 없어지는 게 아니라, 직무의 무게중심이 이동한다. 보고에서 판단으로. 전달에서 실행으로. 수집에서 해석으로.

중요한 건 모두에게 코딩을 시키는 게 아니다.

중요한 건 각자가 자기 전문성을 유지한 채 더 넓은 판단 반경과 실행 반경을 갖게 하는 것이다. 보고만 하던 사람이 한 단계 더 실행까지 가고, 실행만 하던 사람이 한 단계 더 판단까지 가고, 판단만 하던 사람이 결과까지 끝까지 보게 만드는 것.

이건 IT 회사 고유의 것이 아니다. 기존 조직이 자기 언어로 번역해야 할 운영 모델이다.

좋은 AX 팀의 역할도 결국 여기로 수렴한다. 도구를 홍보하는 게 아니라, 이런 역할 전이가 일어나게 만드는 것.

그리고 Bank of America가 보여주는 건 그 전이가 하룻밤에 일어나지 않는다는 것이다. 2018년에 Erica를 출시한 뒤, 직원용과 자산관리 영역으로 확장하는 데 7년이 걸렸다. 하지만 한 번 깔아놓은 배관은 계속 재사용된다. 빠르게 깔아서 느리게 무너지는 것보다, 느리게 깔아서 오래 쓰는 게 낫다.

툴이 늘어나는 것과 조직이 이기는 것은 다르다

여기서 많은 조직이 한 번 더 착각한다.

AX를 하겠다고 선언하고 나면, 조직원들이 하나둘씩 자기만의 툴을 만들어 오기 시작한다. 비개발자도 Claude Code로 작은 자동화를 만든다. 에이전트를 붙여 리포트를 요약하고, 고객 문의를 분류하고, 회의록을 정리한다. 심지어는 앱도 만들어서 가져온다. 처음 보면 뿌듯하다. "와, 이제 우리 조직도 바뀌고 있구나"라는 감정이 든다.

실제로 그 장면은 꽤 감동적이다. 개발자가 아닌 사람이 자기 업무를 더 잘하기 위해 에이전트를 붙여보고, 작게라도 무언가를 만들어낸다. 조직 입장에서는 분명 좋은 신호다. 적어도 사람들의 심리적 저항이 완전히 닫혀 있지는 않다는 뜻이니까.

그런데 정말 그게 AX일까.

정말 그것이 조직에 AX가 적용된 것일까.

과연 개인의 업무 자동화가 그 조직의 성과에 기여하는 것일까.

그럴 확률은 높지 않다.

왜냐하면 대부분의 경우, 그 툴은 개인의 마찰은 줄여주지만 조직의 병목은 건드리지 못하기 때문이다.

마케터가 자기 주간 리포트를 더 빨리 만드는 툴을 만들 수 있다. CS 담당자가 답변 초안을 더 빨리 만드는 봇을 붙일 수 있다. 재무 담당자가 정산 엑셀을 덜 고생하며 정리하는 스크립트를 만들 수도 있다. 다 좋다. 다 생산적이다.

하지만 회사는 그걸로 이기지 않는다.

회사가 이기는 건 개인이 자기 일을 조금 더 빨리 끝내서가 아니라, 조직 전체가 같은 방향으로 더 빨리 움직일 때다. 개인의 자동화가 조직의 승리와 연결되지 않으면, 그건 그냥 툴 하나 더 쓰는 것에 불과하다.

나는 이걸 개인 단위의 국소 최적화라고 부르고 싶다. 본인 책상 위의 마찰은 줄었다. 본인 일정표는 조금 여유로워졌다. 하지만 부서 사이의 승인 대기는 그대로고, 우선순위 충돌도 그대로고, 목표 정렬 부재도 그대로다. 조직은 여전히 같은 데서 느려진다.

더 나쁜 경우도 있다. 각자 자기만의 툴을 만들기 시작하면, 조직은 오히려 더 파편화된다. 마케팅팀 안에서도 A는 자기 GPT를 쓰고, B는 Claude 프로젝트를 쓰고, C는 Zapier와 노션 자동화를 붙인다. 개발팀도 자기만의 에이전트 워크플로우를 만든다. 겉으로 보면 모두가 혁신하는 것 같다. 하지만 실제로는 공통 언어도, 공통 목표도, 공통 운영 원칙도 없다.

툴은 늘어나는데 조직은 더 잘 안 맞물린다.

이건 AX가 아니라 고도화된 각자도생이다.

이 지점에서 나는 예전 글, 승리하지 못하는 조직에게 미래는 없다를 다시 떠올리게 된다. 그 글에서 내가 썼던 핵심은 단순했다. 조직이 승리를 정의하지 못하면, 열심히 일하는 방식 자체가 무의미해진다. 방향 없이 쏟아지는 노력은 위로가 될 수는 있어도 성과가 되지는 않는다.

AX도 똑같다.

조직 목표 정렬 없이 단순히 일하는 방식을 바꾸는 건, 그냥 툴 하나 더 쓰는 것에 불과하다.

문제는 여기서 시작된다. AX 담론은 너무 쉽게 ‘도구 활용률’을 성과처럼 착각한다. 사내에서 몇 명이 에이전트를 쓰는지, 몇 개의 자동화가 만들어졌는지, 몇 번의 데모데이가 열렸는지. 이건 활동 지표다. 성과 지표가 아니다.

진짜 질문은 이거다.

그래서 고객에게 가는 시간이 줄었는가?
그래서 더 좋은 의사결정을 더 빨리 하게 되었는가?
그래서 조직의 승리 조건에 가까워졌는가?

이 질문에 답하지 못하면, 그 조직의 AX는 아직 장난감 단계다.

구분하자면 이렇다.

활동 지표 (좋아 보이지만)	성과 지표 (실제로 중요한)
사내 AI 사용자 수	고객 리드타임 단축률
만든 자동화 툴 개수	부서 간 핸드오프 감소량
데모데이 개최 횟수	의사결정 지연 시간
프롬프트 공유 횟수	조직의 비즈니스 성과 기여

사내 발표용으로 쓰기 좋은 건 왼쪽이다. 하지만 진짜 AX를 측정하려면 오른쪽을 봐야 한다.

나는 오히려 조직원들이 자기 툴을 만들기 시작하는 순간, 리더가 더 냉정해져야 한다고 본다. 박수만 치면 안 된다. 그 툴들이 어디의 마찰을 줄이고 있는지, 공통 병목을 드러내는지, 조직의 핵심 가치 흐름에 기여하는지 봐야 한다. 개인 툴 20개가 흩어져 있는 조직보다, 공통 병목 하나를 제대로 없앤 조직이 훨씬 더 AX에 가깝다.

그러니까 개인 자동화는 신호일 수는 있어도 증거는 아니다.

신호는 반갑다. 하지만 증거는 다르다.

AX의 증거는 늘 같다. 더 짧아진 처리 시간, 더 줄어든 핸드오프, 더 선명해진 책임, 그리고 무엇보다 조직 전체의 비즈니스 성과에 기여했는가다.

이걸 놓치면, 조직은 AI 시대에도 예전과 똑같이 무너진다. 다만 예전보다 더 많은 툴을 쓴 채로.

그래도 AX팀이 만들어졌다면

현실은 현실이다. 이미 AX팀이 신설된 조직도 많을 것이다. 경영진이 결정을 내렸고, 팀이 꾸려졌고, 미션이 주어졌다. 그렇다면 어떻게 해야 그나마 성공 확률을 올릴 수 있는가.

이전 조직에서 일했을 때를 떠올려보자. 새로운 프로세스를 도입할 때 가장 효과적이었던 건, 외부에서 전문가를 데려온 게 아니라 각 팀에서 가장 불만이 많고 동시에 가장 일을 잘 아는 사람을 끌어온 것이었다.

그런데 바로 그 에이스들이 조직의 진짜 병목을 알고 있었다. 불만이 많은 사람은 문제가 뭔지 제일 잘 안다. 그리고 일을 잘 아는 사람은 무엇이 바뀌면 실제로 일이 굴러가는지도 안다.

AX팀도 여기서부터 시작해야 한다.

AX팀에 필요한 건 AI 전문가가 아니다. 마케팅의 병목이 어디인지 아는 마케터, 개발 파이프라인의 진짜 문제를 아는 엔지니어, 고객 접점에서 무엇이 깨지는지 아는 CS 담당자. 이 사람들이 모여서 AI를 도구로 쓰는 게 아니라, 자기 현장의 일하는 방식을 재설계해야 한다.

이게 왜 중요하냐면, 현장을 모르는 AX팀은 거의 반드시 "AI 홍보팀"이 되기 때문이다. 사내 세미나를 열고, 도구를 소개하고, 성공 사례를 번역한다. 보기엔 그럴듯하다. 하지만 실제 현장의 병목은 그대로 남는다.

순서가 전부다. 대부분의 조직은 이 순서를 거꾸로 탄다. 먼저 도구를 깔고, 나중에 어디에 쓸지 고민한다. 그러면 결국 아무 데도 깊게 박히지 못한다.

그리고 미션도 잘못 준다. "AI 도입 촉진" 같은 말은 미션이 아니다. 슬로건이다. 미션은 구체적인 비즈니스 문제여야 한다. 신규 고객 온보딩 시간을 50% 줄인다, 고객 문의 해결 속도를 2배로 올린다, 월간 리포트 작성 시간을 8시간에서 2시간으로 줄인다. 이런 식이어야 한다. 그래야 팀이 도구가 아니라 프로세스를 본다.

이전 조직에서도 마찬가지였다. "소프트웨어 품질 개선" 같은 추상적 미션이 아니라 "이슈 개수를 수치화하고, 매주 줄여나간다"로 구체화했을 때 비로소 팀이 움직였다. 이슈를 카운트하고, 정리하고, 우선순위를 정렬하고, 줄이는 데 집중했다. 이건 단순히 개발자만의 일이 아니었다. PM, QA, 디자이너까지 모두 하나의 이슈 관리 파이프라인에서 정렬되었기 때문에 가능했다. AI로 해결한 게 아니다. 같은 숫자를 보고, 같은 방향으로 움직이게 만든 것이다.

미션이 구체적일수록 팀은 멋진 데모보다 지루한 병목을 보게 된다. 그리고 대부분의 경우, 진짜 성과는 그 지루한 병목에서 나온다.

여기에 함정이 하나 더 있다. 많은 조직이 미션을 "AI 도구 활용률 80% 달성" 같은 식으로 준다. 숫자는 구체적이다. 하지만 방향이 틀렸다. 도구 활용률은 활동 지표다. 그게 조직의 어떤 병목을 해결하는지, 어떤 가치 흐름에 기여하는지가 빠져 있다.

제대로 된 미션은 이렇게 생긴다. "고객 문의에서 1차 응답까지 걸리는 시간을 24시간에서 4시간으로 줄인다. 단, AI는 보조이며 최종 책임은 전담 팀이 진다." 이 미션은 도구 사용률을 강요하지 않는다. 대신 결과와 책임 구조를 명확히 한다. 도구는 수단일 뿐이다.

사람은 미션만 있다고 움직이지 않는다. 자기 역할이 바뀌는 이유와 경로를 알아야 움직인다.

ServiceNow는 28,000명 전 직원을 평가했다. 여기서 중요한 건 평가 그 자체가 아니다. AI를 도입한 뒤 누가 어떤 역할로 이동할 수 있는지, 누구에게 어떤 교육이 필요한지, 지금 어떤 사람들이 반복 업무에 묶여 있는지를 다시 그려야 했다는 점이다. 실무에서 보면 사람들은 AI 자체가 두려운 게 아니다. 자신이 AI 시대에 쓸모없어지는 게 두렵다. 그래서 역할 지형도를 다시 그리는 작업이 먼저다. 지금 무엇을 할 수 있는지 정확히 알아야, 그다음 무엇을 배울지 설계할 수 있다.

AX팀의 일은 도구 전파가 아니다. 사람들이 배우고, 역할을 바꾸고, 현장에서 직접 굴려볼 발판을 까는 일이다.

그리고 실행 권한은 거창할 필요가 없다. 거대한 조직 개편 권한이 없어도 된다. 대신 아주 작은 실험 권한은 있어야 한다. 한 승인 단계를 줄여보는 것, 2주 동안 다른 방식으로 고객 문의를 분류해보는 것, 특정 보고서를 AI 보조로 돌려보는 것. 안 되면 원복하면 된다. 그 정도 권한조차 없으면 AX는 늘 발표자료에서 끝난다. 반대로 그 작은 실험 권한만 있어도 조직은 실제로 배운다.

실험 권한이 없으면 혁신은 없다. 그게 다였다.

AX팀도 마찬가지다. "이렇게 하세요"가 아니라 "우리가 직접 해보겠습니다"가 되어야 한다. 그리고 그 결과를 보여줘야 한다. 숫자로. 성공한 실험은 현장 조직에 넘기고, 실패한 실험은 기록해 다음 팀의 시행착오를 줄인다. 중요한 건 실험의 결과가 AX팀 안에 갇히지 않고 조직 전체의 학습이 되는 것이다.

결국 AX팀이 성공하려면, AX팀이 스스로 사라지는 것을 목표로 해야 한다. 각 현장 조직이 자체적으로 AX를 수행할 수 있게 되면, 별도의 AX팀은 필요 없어진다.

존재의 목적이 자기 소멸인 팀.

이건 역설적이지만, 유일하게 작동하는 설계다.

Walmart는 조직을 재편했다. Bank of America는 배관을 깔았다. Lumen은 정체성을 바꿨다. Commonwealth Bank는 되돌렸다.

결과는 이미 나왔다.

나가며

AX의 제1원칙은 도구가 아니라 조직과 사람이다.

AI를 이해하는 것도 필요하다. Claude Code를 쓸 줄 아는 것도 필요하다. 하지만 그 이전에, 그 도구를 쓸 조직의 사람들을 이해하는 것이 먼저다. 그들이 왜 지금처럼 일하는지, 무엇이 그들을 무기력하게 만드는지, 무엇이 바뀌어야 그들이 움직이는지.

그리고 이 사람을 이해하는 일의 끝에는 방향이 있다. 조직이 방향을 정의하지 못하면, 아무리 좋은 도구를 깔아도 사람들은 제각각 다른 곳으로 달린다. 이전 글에서 내가 쓴 대로, 방향 없이 쏟아지는 노력은 위로가 될 수는 있어도 성과가 되지는 않는다.

AX를 잘하겠다는 조직일수록, 역설적으로 더 분명하게 물어야 한다. 우리는 여기서 무엇을 이기려는가.

나는 매일 저녁 3시간을 투자해서 조직을 이해했다. 그게 내가 할 수 있는 전부였다. 프레임워크도 아니고, 툴킷도 아니고, 매일 저녁 사무실에 앉아서 코드를 읽고 사람들과 이야기한 것. 화려하지 않다.

하지만 이게 진짜였다. 도구를 아는 사람은 도구에 머문다. 사람을 아는 사람은 조직을 바꾼다.

"If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea."

"배를 만들고 싶다면 사람들을 불러 모아 나무를 구하게 하고, 역할을 나누고, 명령부터 내리지 마라. 대신, 그들에게 거대하고 끝없는 바다에 대한 동경심을 가르쳐라."

Antoine de Saint-Exupéry

References

MIT NANDA, "95% of GenAI Pilots Failing: What the Successful 5% Do Differently"
Fortune, "Why CFOs, not CAIOs, Are the Secret to AI Value"
CNBC, "Coca-Cola, Walmart CEOs Step Down amid AI Shift"
Ads of the World, "Coca-Cola: Designers Lead. AI follows."
The Verge, "Coca-Cola’s new AI holiday ad is a sloppy eyesore"
CBS Atlanta, "Coca-Cola plans to cut about 75 jobs at its Atlanta headquarters in early 2026"
The Register, "Commonwealth Bank AI Chatbot Fail: 45 Rehired"
Walmart Tech, "All in on Agents"
Fortune, "Why Walmart's CEO says AI won't lead to lower headcount"
Microsoft, "How Copilot Is Helping Propel an Evolution at Lumen Technologies"
Fortune, "Inside Bank of America's Build Once AI Strategy"
Bloomberg, "Intel CAIO Leaves for OpenAI after 7 Months"
Defense Scoop, "Feinberg orders major shakeup in Pentagon’s AI enterprise"
CloudWars, "ServiceNow: 28,000 Employees Assessed for AI Skills"
SalesforceBen, "Salesforce Lays Off Nearly 1,000 Employees in Early 2026"
CNBC, "JPMorgan CEO Jamie Dimon: AI Is Reshaping Workforce"
JPMorgan Chase, "Teresa Heitsenrether"
EGA, "EGA Designated Industry 4.0 Global Lighthouse by WEF"
Evan Reiser, "The Projection Problem"
flowkater.io, "조직에 Claude Code를 설치한다고 AX가 되지 않는다"
Target, "Enterprise Acceleration Office"
Block, "From Hierarchy to Intelligence"
YouTube / Peter Yang, "How OpenAI's Codex Team Builds with Codex"
flowkater.io, "승리하지 못하는 조직에게 미래는 없다"

패키지 설치가 해킹이 된다 — 제로 디펜던시의 중요성

Tony Cho (https://flowkater.io) — Sat, 04 Apr 2026 02:00:00 GMT

들어가며

2022년 1월 무렵, colors.js와 faker.js의 메인 maintainer(Marak Squires)는 대기업들이 자신의 오픈소스를 무료로 가져다 쓰면서도 금전적 보상이 없다고 공개적으로 불만을 표출했고, 이에 대한 항의(protest) 차원에서 라이브러리를 스스로 망가뜨리는 사건이 일어났다. 이 두 패키지는 수천 개 프로젝트에서 사용되고 있었고(대기업 포함), colors.js는 주당 2,000만 이상 다운로드되는 수준이라 많은 빌드와 서비스가 깨지는 사태로 이어졌다.

Ruby의 gem으로 시작하여, Python pip, JavaScript npm, Rust의 cargo까지 — 언어별로 대표되는 패키지 매니저들이 있다. 나도 수많은 오픈소스 라이브러리 생태계 위에서 빠르게 서비스를 배포한 경험부터, 의존성 호환성 이슈로 밤을 지새운 날도, 오픈소스를 몽키 패치하여 직접 사용했던 기억들이 떠오른다. 물론 대부분은 이런 오픈소스들 덕분에 쉽게 개발할 수 있었고, Stack Overflow의 고수들이 미리 고생한 흔적들을 쉽게 받아먹으며 개발할 수 있음에 감사하고 있었다. 그리고 오픈소스들을 이것저것 임포트해서 쓰다 보니, 나중에는 코딩이 레고인가 하는 생각이 드는 지경이 되었었다. (AI 시대 이전에도, "오픈소스 가져다가 개발하는데 그게 개발인가요"라는 어그로는 항상 화두였다.)

그런 와중에 위에서 언급한 colors.js 공급망 공격 사건은 나에겐 하나의 충격이었다. "오픈소스 가져다가 개발하는데 그게 개발인가요"라는 말이 단순히 어그로가 아닌, 내 결과물에 대한 일종의 존재론적 위기 — 내가 쌓아서 만들고 있는 건 무엇이며, 나는 코더인가 엔지니어인가 — 같은 질문을 던지는 사건이었다. "don't reinvent the wheel"(바퀴를 다시 재발명하지 마라)이라는 오래된 소프트웨어 격언에 대해서 "대체로 그렇지만, 정말로 그러한가?"라는 물음을 가지게 된 계기이기도 했다. (내가 흘러흘러 Python/Node.js 대신 Go를, 모바일 클라이언트에서 Flutter 대신 Swift를 선호하게 된 것도 이런 영향이 없지 않다. 패키지 의존성을 아예 안 쓰는 건 힘들지만, 최소화할 수 있는 방향을 지향하게 된 것도.)

공교롭게도 이번에 두 개의 사건이 연달아 터졌다. 하나는 2026년 3월 24일에 일어난 litellm(PyPI) 메인테이너 계정 탈취 사건이고, 다른 하나는 3월 31일에 일어난 axios(npm) OS별 악성 RAT 배포 사건이다.

개인적으로 두 개 다 꽤 피부에 와닿았다. litellm은 최근 많은 오픈소스 에이전트 플러그인(Claude Code나 Codex용)에서 활용되는 패키지이고, axios는 React를 작업하면서 항상 사용했던 라이브러리였기 때문이다.

LLM AI 시대 이후에 정말 많은 한국 개발자들이 오픈소스를 너도나도 공개하기 시작했다. 개중에는 꽤 좋은 라이브러리들이 쏟아지고 있는데, 나는 아직 그럴듯한 오픈소스를 만들고 있지 않지만 litellm과 axios 사태를 통해 어떻게 오픈소스를 설계해야 하는지, 왜 zero dependency가 중요한지를 정리해보았다.

"don't reinvent the wheel"은 맞는 말인데, 그 바퀴를 나는 어디까지 믿어도 되는 걸까?

2026년 3월, 두 개의 사건 — litellm과 axios

litellm — LLM 통합 라이브러리가 자격증명 탈취 도구가 된 날

litellm은 OpenAI, Anthropic, Bedrock, Vertex AI 등 100개 이상의 LLM 프로바이더를 단일 인터페이스로 통합해주는 Python 라이브러리다. LLM 기반 서비스를 운영하는 조직이라면 한 번쯤은 pip install litellm을 실행해봤을 가능성이 높다. PyPI 기준으로 월간 다운로드가 수백만 건에 달하는, AI 인프라 생태계의 핵심 패키지 중 하나였다.

2026년 3월 24일, litellm의 PyPI 메인테이너 계정이 탈취되었다. 공격자는 정상 배포 프로세스를 통해 악성 코드가 삽입된 버전을 PyPI에 업로드했다. 겉으로 보면 평범한 버전 업데이트였다. pip install --upgrade litellm을 실행한 개발자는 아무런 경고 없이 악성 패키지를 받게 되었다.

공격의 기술적 구조는 교묘했다. 악성 코드는 Python의 .pth 파일 메커니즘을 이용했다. .pth 파일은 Python이 시작될 때 자동으로 실행되는 경로 설정 파일인데, 공격자는 여기에 코드를 삽입하여 Python 프로세스가 시작되는 순간 — import litellm을 호출하지 않아도 — 악성 페이로드가 실행되도록 만들었다. 즉, litellm을 설치만 하고 한 줄도 import하지 않은 환경에서도 Python이 구동되는 순간 감염되는 구조였다.

Sonatype의 분석에 따르면, 악성 페이로드는 다단계로 동작했다. 1단계에서 시스템 환경 정보를 수집하고, 2단계에서 환경 변수에 저장된 API 키, 클라우드 자격증명, 데이터베이스 연결 문자열 등을 외부 서버로 전송했다. LLM 서비스를 운영하는 조직의 특성상 환경 변수에는 OpenAI API 키, AWS 자격증명, 데이터베이스 비밀번호 같은 민감 정보가 가득한 경우가 많다. 공격자는 이걸 정확히 노렸다.

Kaspersky의 보고서는 이 공격이 litellm만을 대상으로 한 것이 아니라 Trivy, Checkmarx 등 다른 보안 도구 패키지까지 함께 노린 조율된 공급망 공격의 일환이었다고 지적했다. 보안 도구가 보안 취약점이 되는 아이러니다.

이 사건에서 특히 주목할 부분은 전이 의존성(transitive dependency) 경로를 통한 유입이다. litellm을 직접 설치한 조직만 영향을 받은 게 아니었다. litellm을 의존성으로 포함하는 다른 패키지, 가령 일부 Cursor MCP 플러그인이나 에이전트 프레임워크를 설치한 경우에도 litellm이 함께 설치되면서 감염 경로가 열렸다. HeroDevs의 분석에 따르면, 직접 litellm을 쓰지 않는데도 취약해진 프로젝트가 상당수 존재했다.

나도 아찔한 순간이 있었다. 최근에 Claude Code 에이전트 스킬 중 하나인 ouroboros를 설치한 적이 있는데, 그 의존성 트리 어딘가에 litellm이 포함되어 있었다. 다행히 해당 스킬을 실제로 사용하지 않아서 Python 환경에 litellm이 활성화되지 않았지만, 만약 한 번이라도 실행했더라면 내 환경 변수에 있는 API 키들이 유출됐을 수 있다. 그 생각을 하니까 등이 서늘해졌다.

axios — HTTP 클라이언트가 RAT 배포 도구가 된 날

axios는 JavaScript/TypeScript 생태계에서 가장 널리 쓰이는 HTTP 클라이언트 라이브러리다. npm 기준 주간 다운로드 1억 건 이상. React, Vue, Node.js 프로젝트에서 API 호출이 필요하면 거의 본능적으로 npm install axios를 치는 수준이다. 나도 React 프로젝트를 할 때마다 빠지지 않고 썼던 라이브러리다.

2026년 3월 31일, axios의 npm 패키지가 타협되었다. Elastic Security Labs의 상세 분석에 따르면, 공격자는 package.json의 postinstall 스크립트를 이용했다. npm에서 패키지를 설치하면 자동으로 실행되는 이 훅(hook)에 악성 스크립트를 삽입한 것이다. npm install을 실행하는 순간, 코드를 한 줄도 import하기 전에 악성 코드가 돌아간다.

공격의 교묘한 점은 OS별로 다른 페이로드를 배포했다는 것이다. Windows에서는 PowerShell을 통해 실행 파일을 다운로드하고, macOS에서는 curl과 bash를 조합하여 바이너리를 내려받았으며, Linux에서도 별도의 페이로드가 준비되어 있었다. Huntress의 보고서는 이 페이로드가 RAT(Remote Access Trojan) 이라고 확인했다. 원격 접속 트로이 목마. 공격자가 감염된 시스템에 원격으로 접속하여 파일을 읽고, 키 입력을 감시하고, 추가 악성코드를 설치할 수 있는 백도어다.

Sophos의 분석은 RAT의 구체적인 기능을 나열했다. 시스템 정보 수집, 파일 시스템 탐색, 키로깅, 스크린 캡처, 추가 페이로드 다운로드 및 실행. 사실상 감염된 개발 머신에 대한 완전한 원격 제어 권한을 획득하는 수준이었다.

npm의 postinstall 훅이 왜 위험한지를 이 사건이 명확하게 보여줬다. npm은 패키지를 설치할 때 preinstall, install, postinstall 순서로 스크립트를 실행하는데, 대부분의 개발자는 이 과정을 인지하지 못한다. npm install axios를 치면 눈에 보이는 건 설치 진행 바뿐이다. 그 뒤에서 어떤 스크립트가 돌아가는지 확인하는 개발자는 극소수다. npm 공식 문서에서조차 postinstall 훅의 사용을 최소화하라고 권고하고 있지만, 수많은 패키지가 여전히 이 훅에 의존하고 있다.

두 사건을 나란히 놓고 보면 공통점이 보인다. 둘 다 메인테이너 계정 또는 배포 파이프라인을 타협한 공급망 공격이다. 둘 다 패키지를 설치하는 것만으로 — 코드를 한 줄도 실행하지 않아도 — 감염된다. 그리고 둘 다 수백만 개 프로젝트에 의존성으로 깊숙이 박혀 있는 핵심 패키지를 노렸다.

litellm은 AI 인프라의 중추를, axios는 웹 개발의 중추를 공격한 셈이다. 일주일 간격으로.

10년의 패턴 — 중단에서 파손으로, 파손에서 침투로

오픈소스 의존성 사고는 2026년에 갑자기 시작된 게 아니다. 10년의 궤적이 있다. 그리고 그 궤적은 한 방향으로 진화해왔다.

2016: left-pad — 중단의 시대

2016년 3월, Azer Koçulu라는 개발자가 npm에 등록한 left-pad 패키지를 삭제했다. 11줄짜리 함수였다. 문자열 왼쪽에 공백이나 특정 문자를 채워주는, 정말 그게 전부인 코드. 그런데 이 11줄이 사라지자 React, Babel을 포함한 수천 개 프로젝트의 빌드가 깨졌다.

David Haney는 그때 블로그 글에서 이렇게 물었다. "Have we forgotten how to program?" 우리는 프로그래밍하는 법을 잊어버린 건 아닌가? 11줄짜리 문자열 패딩 함수를 직접 쓰는 대신 외부 패키지에 의존한다는 사실이, 그때는 웃기면서도 씁쓸한 현상이었다.

left-pad 사건의 본질은 중단(disruption) 이었다. 의존성이 사라지면 빌드가 깨진다. 그게 전부였다. 악의는 없었다. 의도적인 피해도 없었다. 단지 "내 패키지 내가 삭제하겠다는데"에서 시작된 사건이었고, 피해는 빌드 실패와 배포 지연에 그쳤다. npm은 이후 unpublish 정책을 강화했고, 사람들은 잠시 의존성에 대해 생각하다가 곧 잊어버렸다.

2022: colors.js — 파손의 시대

6년 뒤, Marak Squires는 자신이 만든 colors.js와 faker.js에 무한루프 코드를 삽입했다. 이번에는 실수가 아니라 의도적인 파괴였다. 대기업들이 자신의 오픈소스로 돈을 벌면서 자신에게는 한 푼도 돌아오지 않는다는 분노가 동기였다. colors.js를 import한 모든 애플리케이션이 콘솔에 "LIBERTY LIBERTY LIBERTY"를 무한 출력하며 멈췄다.

중단에서 파손으로의 전환이 일어났다. left-pad는 부재로 인한 고장이었지만, colors.js는 존재하는 코드가 적극적으로 해를 끼치는 사건이었다. 패키지가 없어서가 아니라, 패키지가 있어서 문제가 생긴 것이다. 방향이 뒤집혔다.

그래도 colors.js 사건에는 아직 "사람의 얼굴"이 있었다. 공격자는 익명의 해커가 아니라 프로젝트의 원작자였고, 동기는 (동의하든 말든) 이해할 수 있는 불만이었으며, 피해는 서비스 장애에 한정되었다. 데이터 유출이나 자격증명 탈취로 이어지지는 않았다.

2026: litellm/axios — 침투의 시대

2026년 3월의 두 사건은 완전히 다른 영역으로 넘어갔다. 메인테이너의 개인적 항의가 아니라 조직화된 공격자의 계획적인 침투다. .pth 자동실행, postinstall 훅, OS별 맞춤 RAT — 기술적 정교함의 수준이 다르다. 그리고 목적도 다르다. 서비스를 멈추는 것이 아니라 자격증명을 훔치고, 시스템에 백도어를 심고, 지속적인 접근 권한을 확보하는 것이다.

이 10년의 궤적을 정리하면 이렇다.

연도	사건	유형	동기	피해 범위
2016	left-pad	중단	개인 결정	빌드 실패
2022	colors.js	파손	항의	서비스 장애
2026	litellm/axios	침투	조직적 공격	자격증명 탈취, 원격 제어

Russ Cox는 2019년에 쓴 Our Software Dependency Problem에서 이렇게 경고했다. "소프트웨어 의존성은 소프트웨어 공급망의 일부이며, 공급망 보안은 가장 약한 고리에 의해 결정된다." 그때는 이론적인 경고처럼 들렸다. 7년이 지난 지금, 그 경고는 현실이 되었다.

예전엔 의존성이 깨질까 봐 무서웠다. 이제는 의존성이 나를 깨뜨릴까 봐 무섭다.

내가 쓰는 도구 — Superpowers와 제로 디펜던시

4-1. Superpowers를 선택한 이유

이전에 블로그 글에서 소개한 적 있는데, Superpowers는 Claude Code나 Codex 같은 AI 코딩 에이전트에게 체계적인 개발 워크플로우를 부여하는 스킬 프레임워크다. 질문 → 설계 → 계획 → TDD → 코드 리뷰까지의 흐름을 명령어 없이 자동으로 강제한다. 내가 직접 만들어 쓰던 interview 커맨드, TDD 스킬, 코드 리뷰 스킬을 하나로 통합한 구조라서 도입했다.

솔직히 말하면, 내가 Superpowers를 고른 이유에 "제로 디펜던시"는 없었다. 워크플로우가 내 작업 방식과 맞았고, 스킬의 구조가 직관적이었고, 브레인스토밍 → 플래닝 → 실행의 흐름이 내가 지향하는 개발 프로세스와 일치했기 때문이다. 그런데 이번 litellm/axios 사태를 겪고 나서 Superpowers의 코드를 다시 들여다보니, 거기에 "좋은 오픈소스는 어떻게 설계해야 하는가"의 구체적인 답이 있었다.

4-2. 코드로 증명하기 — server.cjs 354줄

Superpowers에는 브레인스토밍 세션에서 사용하는 로컬 웹 서버가 있다. HTML 화면을 브라우저로 서빙하고, WebSocket으로 실시간 업데이트를 보내고, 파일 변경을 감지하는 서버다. 웹 개발을 해본 사람이라면 이 정도 기능을 만들기 위해 보통 어떤 패키지를 쓰는지 안다. Express(HTTP 서버), ws(WebSocket), chokidar(파일 감시). 그리고 이 세 개를 설치하면 node_modules에 수백 개의 하위 패키지가 따라 들어온다.

실제로 Superpowers의 이 서버도 처음에는 그렇게 만들어져 있었다. v5.0.2 릴리즈 노트에는 이런 기록이 남아 있다.

Zero-Dependency Brainstorm Server Removed all vendored node_modules — server.js is now fully self-contained. Replaced Express/Chokidar/WebSocket dependencies with zero-dependency Node.js server using built-in http, fs, and crypto modules. Removed ~1,200 lines of vendored node_modules/, package.json, and package-lock.json.

Express, chokidar, ws — 이 세 패키지와 그 하위 의존성을 합쳐서 약 1,200줄의 벤더링된 코드를 제거하고, Node.js 내장 모듈만으로 전체 서버를 다시 작성한 것이다. 결과물은 server.cjs라는 단일 파일, 354줄 이다.

Superpowers의 package.json을 보면 이 결정의 결과가 명확하다.

{
  "name": "superpowers",
  "version": "5.0.7",
  "type": "module",
  "main": ".opencode/plugins/superpowers.js"
}

dependencies 필드가 없다. devDependencies도 없다. npm 패키지로서 외부 의존성이 문자 그대로 제로다. 이 프로젝트를 npm install해도 node_modules 폴더에 추가되는 외부 패키지가 하나도 없다.

이제 354줄이 실제로 어떻게 구성되어 있는지 코드를 살펴보자.

1) WebSocket 프로토콜 — RFC 6455 직접 구현

ws 라이브러리를 쓰는 대신, WebSocket 프로토콜(RFC 6455)을 직접 구현했다. WebSocket의 핵심은 프레임 인코딩/디코딩이다. 서버가 보내는 데이터를 바이너리 프레임으로 감싸고, 클라이언트가 보내는 마스킹된 프레임을 풀어내는 작업이다.

const OPCODES = { TEXT: 0x01, CLOSE: 0x08, PING: 0x09, PONG: 0x0a };
const WS_MAGIC = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

function computeAcceptKey(clientKey) {
  return crypto
    .createHash("sha1")
    .update(clientKey + WS_MAGIC)
    .digest("base64");
}

WebSocket 핸드셰이크에서 클라이언트가 보내는 Sec-WebSocket-Key에 매직 문자열을 붙이고 SHA-1 해시를 돌려 Sec-WebSocket-Accept를 만드는 코드다. RFC 6455 Section 4.2.2에 정의된 그대로다. ws 라이브러리가 내부에서 하는 일이 정확히 이것인데, 직접 쓰면 5줄이다.

프레임 인코딩도 마찬가지다.

function encodeFrame(opcode, payload) {
  const fin = 0x80;
  const len = payload.length;
  let header;

  if (len < 126) {
    header = Buffer.alloc(2);
    header[0] = fin | opcode;
    header[1] = len;
  } else if (len < 65536) {
    header = Buffer.alloc(4);
    header[0] = fin | opcode;
    header[1] = 126;
    header.writeUInt16BE(len, 2);
  } else {
    header = Buffer.alloc(10);
    header[0] = fin | opcode;
    header[1] = 127;
    header.writeBigUInt64BE(BigInt(len), 2);
  }

  return Buffer.concat([header, payload]);
}

페이로드 길이에 따라 2바이트, 4바이트, 10바이트 헤더를 선택하는 로직이다. WebSocket 프레임 포맷의 핵심이 이 분기 하나에 다 들어 있다. 126 미만이면 7비트로 직접 표현하고, 126 이상 65536 미만이면 16비트 확장을, 그 이상이면 64비트 확장을 쓴다.

디코딩은 역방향이다. 클라이언트 프레임은 반드시 마스킹되어야 하므로(RFC 6455 요구사항), 4바이트 마스크 키로 XOR 디마스킹을 수행한다.

function decodeFrame(buffer) {
  if (buffer.length < 2) return null;
  const secondByte = buffer[1];
  const opcode = buffer[0] & 0x0f;
  const masked = (secondByte & 0x80) !== 0;
  let payloadLen = secondByte & 0x7f;
  let offset = 2;

  if (!masked) throw new Error("Client frames must be masked");
  // ... 길이 파싱, 마스크 키 추출 ...

  const mask = buffer.slice(maskOffset, dataOffset);
  const data = Buffer.alloc(payloadLen);
  for (let i = 0; i < payloadLen; i++) {
    data[i] = buffer[dataOffset + i] ^ mask[i % 4];
  }

  return { opcode, payload: data, bytesConsumed: totalLen };
}

ws 라이브러리는 이 외에도 permessage-deflate 압축, 프래그먼테이션, 서브프로토콜 협상 같은 기능을 제공한다. 하지만 Superpowers의 브레인스토밍 서버에 그런 기능이 필요한가? 로컬호스트에서 HTML 리로드 메시지를 보내는 데 압축이 필요한가? 필요 없다. 그래서 필요한 것만 구현했다. TEXT, CLOSE, PING, PONG — 이 네 가지 opcode만 처리하면 충분하다.

2) HTTP 서버 — Express 없이

Express를 제거하고 Node.js 내장 http 모듈로 서버를 구성했다. 라우팅이 필요한 경로가 세 개밖에 없으니, 미들웨어 스택이 필요 없다.

function handleRequest(req, res) {
  touchActivity();
  if (req.method === "GET" && req.url === "/") {
    const screenFile = getNewestScreen();
    let html = screenFile
      ? (raw => (isFullDocument(raw) ? raw : wrapInFrame(raw)))(
          fs.readFileSync(screenFile, "utf-8")
        )
      : WAITING_PAGE;

    if (html.includes("</body>")) {
      html = html.replace("</body>", helperInjection + "\n</body>");
    } else {
      html += helperInjection;
    }

    res.writeHead(200, { "Content-Type": "text/html; charset=utf-8" });
    res.end(html);
  } else if (req.method === "GET" && req.url.startsWith("/files/")) {
    // 정적 파일 서빙
    const fileName = req.url.slice(7);
    const filePath = path.join(CONTENT_DIR, path.basename(fileName));
    if (!fs.existsSync(filePath)) {
      res.writeHead(404);
      res.end("Not found");
      return;
    }
    const ext = path.extname(filePath).toLowerCase();
    const contentType = MIME_TYPES[ext] || "application/octet-stream";
    res.writeHead(200, { "Content-Type": contentType });
    res.end(fs.readFileSync(filePath));
  } else {
    res.writeHead(404);
    res.end("Not found");
  }
}

/ 경로에서 가장 최근 HTML 화면을 서빙하고, /files/* 경로에서 정적 리소스를 내려주고, 나머지는 404. 이게 전부다. Express의 app.get(), app.use(), app.static() 같은 편의 기능이 안에서 하는 일이 결국 이것이다. 라우팅 경로가 세 개인 서버에 미들웨어 체인을 위한 프레임워크가 필요할까?

3) 파일 감시 — chokidar 없이

Node.js의 fs.watch()는 플랫폼마다 동작이 다르기로 유명하다. macOS에서는 rename 이벤트가 새 파일 생성에도, 기존 파일 덮어쓰기에도 발생한다. 그래서 대부분의 프로젝트가 chokidar를 쓴다. 크로스 플랫폼 호환성, 재귀 감시, 안정적인 이벤트 바운싱 등을 제공하니까.

하지만 Superpowers의 서버는 감시 대상이 딱 하나다. CONTENT_DIR 폴더의 .html 파일 변경. 단일 디렉토리, 단일 확장자. 이 경우 fs.watch()에 디바운싱 타이머를 직접 붙이면 충분하다.

const debounceTimers = new Map();

const watcher = fs.watch(CONTENT_DIR, (eventType, filename) => {
  if (!filename || !filename.endsWith(".html")) return;

  if (debounceTimers.has(filename)) clearTimeout(debounceTimers.get(filename));

  debounceTimers.set(
    filename,
    setTimeout(() => {
      debounceTimers.delete(filename);
      const filePath = path.join(CONTENT_DIR, filename);
      if (!fs.existsSync(filePath)) return;
      touchActivity();

      if (!knownFiles.has(filename)) {
        knownFiles.add(filename);
        // 새 화면 추가 시 이벤트 파일 초기화
        const eventsFile = path.join(STATE_DIR, "events");
        if (fs.existsSync(eventsFile)) fs.unlinkSync(eventsFile);
      }

      broadcast({ type: "reload" });
    }, 100)
  );
});

Map으로 파일별 디바운스 타이머를 관리하고, Set으로 이미 알려진 파일을 추적한다. macOS의 rename 이중 호출 문제도 100ms 디바운스로 자연스럽게 해결된다. chokidar가 제공하는 재귀 감시, 글로브 패턴 매칭, symlink 추적 같은 기능은 여기서 필요 없다.

4) WebSocket 업그레이드 핸드셰이크

HTTP 서버에서 WebSocket으로의 프로토콜 업그레이드도 직접 처리한다.

function handleUpgrade(req, socket) {
  const key = req.headers["sec-websocket-key"];
  if (!key) {
    socket.destroy();
    return;
  }

  const accept = computeAcceptKey(key);
  socket.write(
    "HTTP/1.1 101 Switching Protocols\r\n" +
      "Upgrade: websocket\r\n" +
      "Connection: Upgrade\r\n" +
      "Sec-WebSocket-Accept: " +
      accept +
      "\r\n\r\n"
  );
  // ... 이후 프레임 기반 통신
}

HTTP 101 응답을 직접 소켓에 쓰는 4줄짜리 핸드셰이크다. ws 라이브러리의 WebSocket.Server가 내부에서 하는 일이 이것이다.

4-3. 비용과 가치 — 1,200줄을 354줄로

이전 버전의 벤더링된 node_modules는 약 1,200줄이었다. Express의 미들웨어 체인, chokidar의 크로스 플랫폼 추상화, ws의 전체 WebSocket 스펙 구현이 모두 포함된 양이다. 리팩토링 후에는 354줄이 되었다. 줄어든 846줄이 불필요한 코드였다는 뜻이 아니다. 그 846줄은 "이 프로젝트에서 필요하지 않은 기능을 위한 코드"였다.

Rob Pike는 Go Proverbs에서 이렇게 말했다.

"A little copying is better than a little dependency." 약간의 복사가 약간의 의존성보다 낫다.

이 문장을 처음 봤을 때는 "그래, 맞는 말이긴 한데 현실적으로..."라는 생각이 들었다. 하지만 server.cjs를 보면 그 "약간의 복사"가 구체적으로 얼마나인지 알 수 있다. WebSocket 핸드셰이크 5줄, 프레임 인코딩 20줄, 프레임 디코딩 30줄, HTTP 라우팅 25줄, 파일 감시 15줄. 합쳐서 100줄 정도가 "라이브러리가 해주던 일"이다. 나머지 254줄은 비즈니스 로직 — 화면 관리, 이벤트 처리, 생명주기 관리 — 으로, 어차피 어떤 라이브러리를 쓰든 직접 작성해야 하는 코드다.

100줄의 "복사"로 1,200줄의 의존성을 제거한 셈이다. 그리고 그 100줄은 읽을 수 있다. RFC 6455 스펙을 읽어본 사람이라면, 이 WebSocket 구현이 올바른지 직접 검증할 수 있다. Express 내부 코드를 따라가며 미들웨어 체인이 올바른지 검증하는 것과는 다른 수준의 투명성이다.

제로 디펜던시의 가치는 보안만이 아니다. 가독성 이다. 354줄은 한 사람이 앉아서 전체를 읽을 수 있는 분량이다. 코드의 모든 동작을 이해할 수 있다. 내 프로젝트에서 어떤 코드가 실행되는지 빠짐없이 알 수 있다. 1,200줄의 벤더링된 의존성 코드까지 포함하면, "대부분은 안 봐도 되겠지"라는 신뢰에 기대게 된다. 그 신뢰가 깨지는 순간이 litellm이고 axios다.

좋은 오픈소스 설계란 무엇인가 — 코드 레벨의 패턴

Superpowers의 server.cjs는 하나의 사례에 불과하다. 제로 디펜던시를 지향하는 프로젝트들은 생각보다 많고, 그 설계에는 공통된 코드 레벨 패턴이 있다. 이 패턴을 세 가지 레이어로 정리할 수 있다.

레이어 1: 핵심 가치는 코드 밖에 둔다

좋은 오픈소스의 핵심 가치는 코드 자체가 아니라, 코드가 구현하는 사고 모델 에 있다. Superpowers의 핵심 가치는 server.cjs의 354줄이 아니라, "질문 → 설계 → 계획 → TDD → 리뷰"라는 워크플로우 사고 모델이다. 이 모델은 마크다운 스킬 파일에 담겨 있고, 코드는 그 모델을 보조하는 도구일 뿐이다.

이런 구조에서는 코드의 의존성이 줄어들 수밖에 없다. 핵심 가치가 코드 실행에 있지 않으므로, 실행 코드는 최소한의 보조 역할만 하면 된다. 의존성이 필요한 복잡한 기능을 "핵심 가치"에 포함시키지 않는 것이 설계의 첫 번째 원칙이다.

레이어 2: 실행 코드는 작게 유지한다

실행이 필요한 코드가 있다면, 그 코드가 하는 일의 범위를 최소화한다. server.cjs는 "로컬 브레인스토밍 서버"라는 좁은 범위만 담당한다. 범용 웹 프레임워크를 만드는 것이 아니라, 딱 이 하나의 유스케이스에 필요한 기능만 구현한다. 범위가 좁으면 필요한 기능이 적고, 필요한 기능이 적으면 외부 라이브러리 없이도 구현할 수 있는 확률이 높아진다.

레이어 3: 설치와 실행을 분리한다

litellm 사건에서 가장 무서웠던 것은 .pth 파일을 통한 자동 실행이었다. 설치하는 순간 코드가 실행되는 구조. axios의 postinstall 훅도 마찬가지다. 좋은 설계는 "설치"와 "실행"을 명확히 분리한다. 패키지를 설치하는 것은 파일을 디스크에 복사하는 것일 뿐, 어떤 코드도 자동으로 실행되어서는 안 된다. 사용자가 명시적으로 import하거나 실행 명령을 내릴 때 비로소 코드가 동작해야 한다.

제로 디펜던시 프로젝트들 — 왜 가능한가

이 세 가지 레이어가 실제 프로젝트에서 어떻게 구현되는지, 제로 디펜던시를 달성한 프로젝트들의 기술적 전략을 살펴보자.

zod — TypeScript 스키마 검증 라이브러리. npm 주간 다운로드 3,000만 이상. 의존성 제로. zod가 0-dep으로 가능한 이유는 TypeScript 타입 시스템 자체가 검증 로직을 표현하기에 충분하기 때문이다. 런타임 검증 로직은 순수 JavaScript 조건문과 타입 가드의 조합으로 구현된다. 외부 파서 엔진이나 코드 생성기가 필요 없다. 스키마 정의와 검증 실행이 모두 TypeScript의 타입 추론 시스템 위에서 이루어진다. 라이브러리가 하는 일이 "JavaScript 값을 받아서 조건문으로 검사하고, 맞으면 타입을 좁혀주는 것"이므로, 외부 도움이 필요한 영역이 없다.

nanoid — 고유 ID 생성기. 의존성 제로. 파일 하나, 130바이트(gzip 기준). nanoid의 핵심은 crypto.getRandomValues()라는 웹 표준 API 하나다. 브라우저와 Node.js 모두에 내장된 이 API가 암호학적으로 안전한 난수를 제공하고, nanoid는 그 난수를 URL-safe 문자열로 인코딩하기만 하면 된다. UUID 라이브러리들이 의존성을 가지는 이유 중 하나가 구버전 환경에서의 폴리필인데, nanoid는 최신 런타임만 지원함으로써 이 문제를 회피했다.

picocolors — 터미널 색상 라이브러리. chalk의 제로 디펜던시 대안. 파일 하나, 번들 사이즈 0.1KB. 터미널 색상의 본질은 ANSI 이스케이프 시퀀스 — \x1b[31m(빨강), \x1b[0m(리셋) — 를 문자열 앞뒤에 붙이는 것이다. chalk이 10개 이상의 의존성을 가졌던 이유는 색상 공간 변환, 256색 지원, Windows 콘솔 호환성 등 부가 기능 때문이었는데, 대부분의 CLI 도구에서 실제로 쓰는 건 빨강/초록/노랑/볼드 정도다. picocolors는 그 "대부분"만 지원하기로 결정했고, 결과적으로 의존성이 제로가 되었다.

Hono — 웹 프레임워크. Node.js, Deno, Bun, Cloudflare Workers 등 멀티 런타임 지원. 의존성 제로. Hono가 0-dep으로 가능한 이유는 Web Standard API(Request, Response, URL, Headers)만을 사용하기 때문이다. Express가 Node.js의 http 모듈 위에 자체 추상화 레이어를 구축한 반면, Hono는 모든 런타임이 공통으로 지원하는 웹 표준 인터페이스 위에서 동작한다. 런타임별 차이를 라이브러리가 아니라 표준이 해결해주는 구조다.

chi — Go 언어 HTTP 라우터. 의존성 제로. Go 표준 라이브러리의 net/http가 이미 충분히 강력한 HTTP 서버를 제공하고, chi는 그 위에 라우팅 트리(기수 트리, radix tree) 하나만 얹는다. Go 생태계에서 제로 디펜던시가 유난히 많은 이유는 표준 라이브러리가 워낙 포괄적이기 때문이기도 하지만, Rob Pike의 "약간의 복사가 약간의 의존성보다 낫다"는 철학이 커뮤니티 전반에 스며들어 있기 때문이기도 하다.

sqlc — SQL 쿼리를 Go 코드로 컴파일하는 도구. 런타임 의존성 제로. ORM이 런타임에 쿼리를 생성하고 결과를 매핑하려면 리플렉션, 코드 생성, 연결 풀링 같은 복잡한 런타임 로직이 필요하다. sqlc는 이 접근을 뒤집었다. 빌드 타임에 SQL을 파싱하여 타입 안전한 Go 코드를 생성하므로, 런타임에는 표준 database/sql 패키지만으로 충분하다. 복잡성을 런타임에서 빌드 타임으로 옮긴 것이다.

이 프로젝트들의 공통점을 정리하면:

범위를 좁게 잡는다. 한 가지 일을 잘 한다. 모든 경우를 커버하려 하지 않는다.
플랫폼 내장 기능을 활용한다. 런타임이 이미 제공하는 것을 다시 구현하지 않는다.
부가 기능을 핵심으로 혼동하지 않는다. "있으면 좋은 기능"을 빼는 용기가 있다.

벤더링과 런타임 진화 — 기술이 만드는 구조적 변화

Google은 대규모 모노레포에서 벤더링(vendoring) 전략을 사용한다. 외부 의존성의 소스 코드를 자사 저장소에 직접 복사하고, 이후 독립적으로 패치하는 방식이다. 의존성의 "제어권"을 확보하는 것이다. npm이나 PyPI에서 패키지가 변조되어도, 벤더링된 코드는 영향을 받지 않는다.

Bun과 Deno의 등장도 주목할 만하다. Bun은 번들러, 트랜스파일러, 패키지 매니저를 런타임에 내장했다. 예전에는 webpack, babel, npm이라는 세 개의 외부 도구(그리고 각각의 의존성 트리)가 필요했던 작업이 런타임 하나로 해결된다. Deno는 처음부터 npm 없이 URL 기반 모듈 시스템을 도입했고, TypeScript를 네이티브로 지원하면서 ts-node 같은 도구의 필요성을 없앴다.

이 흐름은 Node.js 자체에서도 보인다. Node.js 18에서 내장 fetch()가 추가되면서 HTTP 클라이언트용 외부 패키지의 필요성이 줄었고, Node.js 20에서 내장 테스트 러너가 안정화되면서 단순한 테스트를 위해 jest나 mocha를 설치할 이유도 줄었다. 런타임이 커질수록 외부 의존성의 필요성은 줄어든다. 그리고 외부 의존성이 줄어들수록 공격 표면도 줄어든다. 이것은 개발자의 의지와 무관하게, 기술 인프라 자체가 "의존성을 줄이는 방향"으로 진화하고 있다는 뜻이다.

개발자의 행동이 바뀌어야 한다

여기까지는 설계와 기술의 이야기였다. 좋은 오픈소스가 어떤 구조를 가지는지, 런타임이 어떻게 진화하는지. 하지만 아무리 런타임이 fetch()를 내장하고, 프로젝트가 제로 디펜던시를 지향해도, 결국 npm install을 치는 건 개발자의 손이다. 기술이 가능성을 열어줄 뿐, 실제로 행동을 바꾸는 것은 사람의 몫이다.

의존성 비용의 3층 모델

의존성을 추가하는 비용은 세 층으로 나눌 수 있다.

1층: 표면 비용 — 눈에 보이는 것들. 번들 사이즈 증가, 설치 시간 증가, node_modules 용량 증가. 대부분의 개발자가 인식하는 비용이고, 가장 자주 논의되는 비용이다. 하지만 실제로는 가장 덜 중요한 비용이기도 하다.

2층: 유지보수 비용 — 시간이 지나면서 드러나는 것들. 의존성 버전 충돌, breaking change 대응, deprecated API 마이그레이션, 보안 패치 적용. 프로젝트를 1년, 2년, 5년 운영하면서 누적되는 비용이다. 의존성이 10개인 프로젝트와 100개인 프로젝트의 유지보수 부담은 선형이 아니라 지수적으로 차이난다.

3층: 신뢰 비용 — 사고가 나기 전까지 보이지 않는 것들. 공급망 공격 노출, 메인테이너 이탈, 라이선스 변경, 악성 코드 삽입. litellm과 axios가 보여준 것이 이 층의 비용이다. 발생 확률은 낮지만, 발생했을 때의 피해는 1층과 2층의 합보다 크다. 그리고 의존성이 많을수록 이 층의 확률은 올라간다. 의존성 하나하나가 공격 표면을 넓히기 때문이다.

AI가 의존성을 추천하는 시대

재미있는 — 그리고 약간 무서운 — 현상이 하나 있다. AI 코딩 어시스턴트에게 HTTP 요청 코드를 작성해달라고 하면, 상당수가 axios를 import하는 코드를 생성한다. Node.js 18 이후로 내장 fetch()가 있는데도 말이다. AI 모델의 훈련 데이터에 axios를 사용하는 코드가 압도적으로 많으니, 가장 "확률적으로 그럴듯한" 코드로 axios를 추천하는 것이다.

실제로 비교하면 이렇다.

// Before: axios 의존성
const { data } = await axios.get("https://api.example.com/data");

// After: 내장 fetch (Node.js 18+)
const data = await fetch("https://api.example.com/data").then(r => r.json());

이 2줄을 위해 외부 패키지를 설치할 이유가 있는가? axios가 제공하는 인터셉터, 요청 취소, 자동 JSON 변환 같은 고급 기능이 필요한 프로젝트라면 모를까, 단순 GET/POST 요청만 하는 대다수의 경우에는 내장 fetch()로 충분하다. 그런데 AI는 이런 맥락 판단 없이, 훈련 데이터에서 가장 빈번하게 등장하는 패턴을 그대로 출력한다.

이건 기존의 "인기가 많으니까 좋은 패키지"라는 논리가 AI 시대에 더 강화되는 피드백 루프를 만든다. 많이 쓰이니까 AI가 추천하고, AI가 추천하니까 더 많이 쓰이고, 더 많이 쓰이니까 공격 가치가 올라간다. axios의 주간 1억 다운로드는 공격자에게 "여기를 노리면 1억 개 프로젝트에 접근할 수 있다"는 신호이기도 하다.

AI가 생성해주는 코드를 무비판적으로 수용하는 습관이 위험한 이유가 여기 있다. AI는 "이 패키지의 메인테이너 계정 보안이 2FA를 사용하는가"를 확인하지 않는다. "이 패키지가 postinstall 훅에서 무슨 일을 하는가"를 검사하지 않는다. AI는 패턴 매칭으로 가장 흔한 코드를 생성할 뿐이고, 가장 흔한 코드가 가장 안전한 코드라는 보장은 어디에도 없다.

체크리스트 — 의존성을 추가하기 전에 확인할 6가지

실천 가능한 체크리스트를 만들어보았다. 새로운 패키지를 프로젝트에 추가하기 전에, 최소한 이 여섯 가지는 확인하자.

① 내장 대안이 있는가? Node.js의 fetch(), crypto, test runner, path, url — 런타임 내장 모듈로 할 수 있는 일에 외부 패키지를 쓰고 있지 않은지 확인한다.

# Node.js 내장 모듈 목록 확인
node -e "console.log(require('module').builtinModules.join('\n'))"

② 의존성 트리의 깊이는? 직접 의존성 하나가 100개의 전이 의존성을 끌고 올 수 있다. 설치 전에 트리를 확인한다.

# npm 패키지의 의존성 트리 확인
npm view <package> dependencies
# 전체 트리 시각화
npm ls --all
# Python의 경우
pip show <package> | grep Requires

③ 메인테이너 정보와 활동 이력은? OpenSSF Scorecard는 오픈소스 프로젝트의 보안 관행을 자동으로 평가해준다. 메인테이너의 2FA 사용 여부, 코드 리뷰 관행, CI/CD 보안, 브랜치 보호 규칙 등을 점수화한다.

# OpenSSF Scorecard로 프로젝트 보안 점수 확인
# https://scorecard.dev/ 에서 GitHub 레포 URL 입력
# 또는 CLI 설치 후:
scorecard --repo=github.com/<owner>/<repo>

④ postinstall 훅이나 자동 실행 코드가 있는가? axios 사건의 핵심이 postinstall 훅이었다. 설치 전에 패키지의 scripts 필드를 확인한다.

# 패키지의 install 스크립트 확인
npm view <package> scripts
# 이미 설치된 패키지 중 postinstall 훅이 있는 것 찾기
find node_modules -name "package.json" -exec grep -l "postinstall" {} \;

⑤ SLSA 레벨은? Supply-chain Levels for Software Artifacts. 패키지의 빌드 프로세스가 얼마나 검증 가능한지를 나타내는 프레임워크다. SLSA Level 3 이상이면 빌드 과정이 변조 불가능한 방식으로 기록되어, 공격자가 빌드 파이프라인을 타협해도 추적할 수 있다.

⑥ 직접 구현하면 몇 줄인가? left-pad는 11줄이었다. Superpowers의 WebSocket 핸드셰이크는 5줄이었다. 직접 구현하는 비용이 낮다면, 의존성을 추가하는 것보다 직접 쓰는 게 나을 수 있다. Rob Pike의 "약간의 복사가 약간의 의존성보다 낫다"를 떠올리자.

이 체크리스트가 모든 의존성에 대해 "쓰지 마라"고 말하는 건 아니다. 암호화 라이브러리를 직접 구현하는 건 보안 재앙의 지름길이다. 데이터베이스 드라이버를 직접 쓰는 건 비현실적이다. 하지만 "이 패키지가 정말 필요한가, 아니면 습관적으로 추가하는 건가"라는 질문을 던지는 것만으로도 공격 표면을 줄일 수 있다.

나가며

npm install은 편의 명령이 아니었다. 신뢰 명령이었다.

npm install axios를 치는 순간, 나는 axios의 메인테이너를, axios가 의존하는 패키지의 메인테이너들을, 그 메인테이너들의 계정 보안 수준을, npm 레지스트리의 무결성을, 그리고 postinstall 훅이 내 시스템에서 실행하는 모든 코드를 신뢰한다고 선언한 셈이다. pip install litellm도 마찬가지다. 그리고 우리 대부분은 이 신뢰의 무게를 인식하지 못한 채 매일 수십 번씩 이 명령을 실행해왔다.

354줄은 읽을 수 있다. 1,200줄은 신뢰할 수밖에 없다.

Superpowers의 server.cjs가 보여주는 것은 미니멀리즘이나 과시가 아니다. "내가 이해할 수 있는 코드만 내 프로젝트에 넣겠다"는 결정이다. 물론 모든 프로젝트가 354줄짜리 자체 구현을 해야 한다는 뜻은 아니다. 그건 비현실적이다. 하지만 "이 의존성이 정말 필요한가, 직접 구현하면 어려운가, 이 패키지를 신뢰할 근거가 있는가"라는 질문을 매번 던지는 것은 현실적이다.

의존성이 적다는 건 미니멀리즘이 아니라, 내가 믿어야 할 것을 줄이는 일이다.

결국 don't reinvent the wheel이라는 격언은 여전히 맞다. 바퀴를 직접 만드는 건 대부분의 경우 시간 낭비다. 하지만 그 격언에 한 줄을 덧붙여야 할 때가 된 것 같다.

바퀴를 다시 발명하지 마라. 단, 그 바퀴가 내 차에서 무슨 일을 하는지는 알고 있어라.

References

litellm, Security Update — March 2026
Sonatype, Compromised litellm PyPI Package
Kaspersky, Critical Supply Chain Attack
HeroDevs, The LiteLLM Supply Chain Attack
Elastic Security Labs, Axios: One RAT to Rule Them All
Huntress, Supply Chain Compromise: Axios
Sophos, Axios npm Package Compromised
Russ Cox, Our Software Dependency Problem (2019)
Rob Pike, Go Proverbs (2015)
David Haney, Have We Forgotten How to Program? (2016)
Suckless, Philosophy
Wikipedia, npm left-pad incident
SLSA, Supply-chain Levels for Software Artifacts
OpenSSF, Scorecard
npm, Scripts Best Practices
GitHub, obra/superpowers
Flowkater.io, Superpowers 소개

AI Native Engineer — 원리 위의 감각

Tony Cho (https://flowkater.io) — Tue, 24 Mar 2026 15:20:00 GMT

AI Native Engineer — 원리 위의 감각

1. 들어가며

AI 네이티브 시대. 사람들은 새로운 시대가 왔다고 공포를 느낀다. 개발자 집단 우울증이라는 말이 과장이 아닌 듯하다. 직업 상실의 공포, 심지어는 러다이트 운동을 언급하는 사람도 있다. 러다이트 운동이 그랬듯 AI 서버를 파괴하러 가야 할까? AI 혁명으로 모든 개인 지식 노동자들은 일자리를 잃고 일부 대기업만이 모든 지식 생산을 독식하는 세상이 올까? 알 수 없다.

이전 글들에서도 언급했듯이 AI는 결국 본인의 거울이기 때문에 잘하는 사람은 더 잘하게, 게으른 사람은 더 게으르게 만들 거라고 생각한다. 이제 AI 없이는 어떻게 일을 할까 싶은 시대가 되었지만 글쎄, 내가 본 주위의 풍경은 의외로 그 사람의 역량에 따라 결과물의 퀄리티가 크게 달라진다는 것이다. 지금은 모두가 FOMO에 휩쓸려 너도나도 이런저런 도구를 도입하고 사용하고 그걸 퍼나르고 공유하는 데 여념이 없지만, 정말로 성과를 내는 사람들은 여전히 소수다.

개발자로, 리드로 현업에서 다양한 롤을 수행하며 많은 사람을 만났다. 그 경험에서 내가 느끼는 관점은 의외로 낙관적이다. 불안이 먼저 보이지만, 이 글은 그 불안 너머를 이야기하려고 한다. 곧 기업들이 다시 주니어를 채용할 것이고, AI 시대에 성공한 기업들도 채용을 진행할 거라고 본다. 나의 일상생활과 업무를 지탱하며 24시간 돌아가는, 12개가 넘는 에이전트를 매일 사용하고, 온갖 스킬들과 케이스 스터디를 업무에 적용해가며 시도하고 있지만, 모든 걸 멈추고 내가 백지에 적은 내 생각 노트 하나가 그 모든 걸 뛰어넘는다. 물론 에이전트들이 내 생각 노트들을 잘게 씹고 뜯고 실제 구현체까지 만드는 속도는 전에는 감히 상상할 수 없었지만 애초에 "나의" 생각 노트 없이 무슨 일을 시작할 수 있겠나?

0을 아무리 제곱해봐야 0이다. AI 네이티브 엔지니어는 0이 아닌 사람이다.

에이전틱 엔지니어링 9가지 스킬에서 How를 다뤘고, AX 조직 전환에서 Where를 다뤘다. 이번에는 Who — AI Native Engineer란 대체 어떤 사람인가. 이 글이 가장 어려운 건, 결국 나 자신을 들여다봐야 하기 때문이다.

How에 대한 답은 이미 충분하다. OpenAI는 AI에게 위임하고, 검토하고, 소유하라(Delegate — Review — Own)는 모델을 제시했고, Mike Mason은 프롬프트 엔지니어링의 다음 단계로 컨텍스트 엔지니어링(Context Engineering)을 이야기한다. Karpathy는 이미 에이전트를 스핀업하고 태스크를 부여하고 병렬로 검토·관리하는 것이 엔지니어의 일상이 됐다고 했고, Steve Yegge는 20~30개 병렬 에이전트를 오케스트레이션하며 1년간 백만 라인을 생성했다. 어떻게 AI를 쓸 것인가에 대한 방법론은 넘쳐난다.

하지만 Who가 빠져있다. 도구를 잘 다루는 것은 조건이지 정체성이 아니다. 칼을 잘 다룬다고 요리사인 건 아니고, AI를 잘 다룬다고 AI Native Engineer인 것도 아니다.

원리 없는 감각은 추측이다.

2. 드러난 것들 — 이전 시대 엔지니어와 다른 점

나는 15년간 개발을 해왔다. 그 시간 대부분을 도구와 씨름하면서 보냈다. 언어 문법을 외우고, 프레임워크 컨벤션을 익히고, 빌드 시스템을 설정하고, 배포 파이프라인을 구축하고. Drew Hoskins의 The Product-Minded Engineer 서문에 이런 문장이 있다.

도구와 언어가 너무 어려워서, 이를 익히고 사용하는 것 자체가 풀타임 직업이었다.

이 문장을 읽었을 때, 마지막 퍼즐 한조각이 드디어 맞춰지는 느낌이었다.

Swift를 잘 쓰면 iOS 개발자, React를 잘 쓰면 프론트엔드 개발자, Kubernetes를 잘 다루면 DevOps 엔지니어. 도구가 정체성이었다. "무엇을 만드는가"보다 "무엇으로 만드는가"가 중요했던 시대.

AI가 이 풀타임 직업을 대신하기 시작했다.

문법? AI가 안다. 프레임워크? AI가 안다. 빌드 설정? AI가 해준다. 배포 파이프라인? AI가 짜준다. 물론 아직 완벽하지 않다. 복잡한 레거시 코드베이스에서는 여전히 삽질이 필요하다. 하지만 방향은 명확하다.

그리고 그 풀타임 직업이 사라지기 시작하자, 원래 해야 했지만 도구에 가려져 있던 것들이 전면에 드러나기 시작했다.

사용자 이해. 제품 사고. 비즈니스 책임.

데이터가 이걸 뒷받침한다.

DORA 2025 리포트에 따르면, AI 도구 도입 이후 PR 생성량은 98% 증가했다. 거의 두 배다. 그런데 소프트웨어 딜리버리 성과는? Flat. 변화 없음.

이게 좀 씁쓸한 숫자인데, Nicole Forsgren이 정확히 짚었다. 코딩 내부 루프(Inner Loop) — 코드 작성, 테스트, 로컬 빌드 — 는 빨라졌다. 반면 외부 루프(Outer Loop) — 리뷰, 승인, 통합, 배포, 보안, 피드백 — 의 병목은 여전하다. 결국 진짜 병목은 코딩이 아니었던 셈이다. 우리가 “코딩 생산성”이라고 불렀던 것은 전체 가치 사슬의 아주 작은 일부에 불과했다.

더 냉정한 데이터도 있다. 하버드 경영대학원 렘 코닝(Rem Koning) 교수가 케냐 소기업 창업자들에게 ChatGPT를 제공한 실험에서, 기존에 성과가 낮던 그룹은 AI를 쓴 뒤 오히려 수익이 10% 하락했다. AI의 조언을 많이 받았지만, 좋은 조언과 나쁜 조언을 구분할 판단력이 없었기 때문이다. 반면 이미 판단력을 갖춘 그룹은 나쁜 조언을 걸러내고 성과를 올렸다. 코닝 교수의 결론: AI는 평등화가 아니라 증폭기다. 직접 겪어서 쌓은 통찰(Earned Insight)이 없으면, AI는 슬롭(slop)으로 이끌 뿐이다.

코딩만 잘하면 됐던 시대가 끝난 것이 아니다. 끝난 것은 오히려 ‘코딩만 잘하면 된다’는 착각이다. 도구가 쉬워질수록, 그 도구 뒤에 숨을 수는 없게 된다.

그렇다면 구체적으로 무엇이 달라졌을까. 이전 시대 엔지니어와 비교하면 세 가지가 눈에 띈다.

책임의 확대

이전에 개발 팀을 이끌면서 우리 팀의 책임 범위는 어디까지나 전달(delivery)에 있었다. 정확하고 빠르게 배포하는 것이 우리의 책임이었다. 판매와 영업, 운영은 애초에 다른 팀의 몫이었으니까. 하지만 지금 뼈저리게 느끼는 건 하나다. 전달보다 중요한 건 발견(discovery)이고, 100개의 전달보다 1개의 제대로 된 발견을 구현해내는 게 실력이라고 생각한다. 만드는 것 자체가 이전보다 훨씬 빨라진 세상에서, 발견을 책임지지 못하는 엔지니어는 0인 엔지니어라고 생각한다.

예전에는 "왜 이걸 만들어야 하지?"라는 질문을 PM이 대신 해줬다. 엔지니어는 스펙을 받아서 구현하면 됐다. 그 구조가 나쁘다는 게 아니다. 그게 합리적이었다. 도구가 너무 어려웠으니까. 하지만 AI가 구현의 상당 부분을 가져간 지금, 엔지니어가 "왜"를 모르면 대체 뭘 하는 사람인가? 스펙을 AI에게 넘기는 사람? 그건 엔지니어가 아니라 전달자다.

사용자가 진짜 원하는 게 뭔지, 이 기능이 비즈니스에 어떤 임팩트를 주는지, 우선순위가 왜 이렇게 정해졌는지 — 이런 맥락을 이해하는 엔지니어와 그렇지 않은 엔지니어의 격차가 AI 시대에 극적으로 벌어지고 있다. AI가 "어떻게"를 대신 해주니까, "왜"를 모르는 엔지니어에게 남는 역할이 없다. 사용자를 모르는 엔지니어는 도태될 뿐이다.

'샘'은 GitHub 5년 비활성, SNS 존재감 제로다. 그런데 전 동료들이 채용하려고 줄을 선다. 한 스타트업은 그를 위해 자리를 새로 만들 준비까지 했다. 프로젝트를 이해하는 순간 화이트보드에 전체를 쪼개고, 지연을 "지연"이 아니라 "트레이드오프"로 표현하며, 다른 팀과 협업할 때는 "이거 해주세요"가 아니라 "고객이 이런 문제를 겪고 있어요, 이 시스템이 어떻게 작동하는지 설명해주실 수 있나요?"로 시작한다. 고수준 분해 능력과 고객 문제 중심 사고를 동시에 갖춘 사람. 이건 AI 시대에 새로 생긴 능력이 아니다. 원래 좋은 엔지니어가 하던 것이다. 다만 이제는 이걸 안 하면 숨을 곳이 없다.

10배 빠른 학습 능력

AI가 생성하는 코드의 양이 10배가 됐으면, 그 코드를 이해하고 판단하는 속도도 10배여야 한다. AI가 30초 만에 만들어낸 200줄의 코드를 읽고, "이건 맞다, 저건 틀리다, 여기는 성능 이슈가 있다"를 판단하려면 — 기초가 탄탄해야 한다.

기초는 죽지 않는다(Basic Never Die). CS 기초뿐 아니라, 자신이 사용하는 도구 — 언어든 프레임워크든 — 에 대한 깊은 이해도 마찬가지다. 표면만 긁어서는 AI가 뱉어내는 코드의 옳고 그름을 판별할 수 없다. 판별하지 못하면 AI를 쓰는 사람이 아니라 AI에 끌려가는 사람이 된다. 그건 AI Native가 아니라 AI Dependent다.

이전 시대에는 한 가지 기술을 깊이 파면 10년은 먹고살 수 있었다. Java를 잘하면 Java 개발자로, Golang을 잘하면 백엔드 개발자로. 그 깊이가 경쟁력이었다. 지금은 다르다. AI가 언어 간 장벽을 무너뜨리고 있다. iOS를 모르는 사람이 AI 도움으로 iOS 앱을 만들 수 있다 (내가 그 예다). 하지만 그게 "iOS 엔지니어"가 됐다는 의미는 아니다. 표면적으로 돌아가는 코드와, 프로덕션에서 견디는 코드 사이의 간극은 여전히 크다.

그래서 학습 방식 자체가 달라져야 한다. 예전처럼 문법부터 차근차근 쌓아올리는 게 아니라, AI가 만든 코드를 읽으면서 원리를 역추적하는 방식. "이 코드가 왜 이렇게 동작하지?"를 파고들다 보면, 자연스럽게 깊은 이해로 연결된다. AI가 만들어준 코드가 교재가 되는 셈이다. 다만, 그 교재를 읽을 눈이 있어야 한다.

판단의 속도

Forsgren이 짚은 건데, AI와 함께 일하면 30분 안에 수십 번 멘탈 모델을 재구성해야 한다. 예전에는 하루에 한두 번 설계 결정을 내리면 됐다. 이제는 30분 안에 수십 번이다.

AI가 3개의 접근법을 제시하면, 그중 어떤 게 맞는지 판단해야 한다. AI가 "캐시를 추가하세요"라고 하면, 진짜 캐시가 정답인지 아니면 쿼리 자체가 문제인지 판단해야 한다. AI가 리팩토링 제안을 하면, 그게 정말 나은 설계인지 아니면 겉만 다른 같은 복잡도인지 판단해야 한다. 이 모든 게 빠르게, 연속적으로 일어난다.

빠른 판단은 깊은 이해에서 나온다. 원리를 이해하는 사람은 직관적으로 판단할 수 있다. "이건 O(n²)이니까 데이터가 커지면 문제가 생길 거다", "이 구조는 분산 환경에서 일관성 문제가 생긴다", "이 API 설계는 클라이언트에 너무 많은 책임을 떠넘긴다" — 이런 판단이 0.5초 만에 나와야 하는 시대다.

예전에는 모르면 찾아보면 됐다. 시간이 있었으니까. 지금은 AI가 코드를 쏟아내는 속도를 따라잡으려면, 찾아보기 전에 감이 와야 한다. 그 감은 허공에서 오지 않는다. 수년간 쌓은 원리의 토대에서 온다.

본질이 달라진 게 아니라 적나라하게 드러난 것이다. 이전에도 좋은 엔지니어는 이 세 가지를 갖추고 있었다. 다만 도구가 너무 어려워서 가려져 있었을 뿐이다.

나는 15년간 도구 뒤에 숨어 있었는지도 모른다. 프레임워크를 잘 쓰고, 서버를 잘 구축하고, 아키텍처를 잘 설계하는 것. 그게 나의 전문성이라고 믿었다. 완전히 틀린 말은 아니지만 그게 전부인 양 행동한 적이 있었다. 사용자가 불편하다고 해도 “기술적으로는 맞다”고 버틴 적도 있었다.

그 도구를 AI가 대신 쓸 수 있게 되니, 그 뒤에 숨어 있던 내가 드러난 것이다.

(이게 참 불편한 깨달음이다.)

3. Maker의 역풍

이전 AX 글에서 Maker와 Closer를 구분했다. Maker는 산출하는 사람, Closer는 성과를 완결하는 사람. 여기서 좀 더 깊이 들어가 보자 — 조직 레벨이 아니라, 개인 레벨에서.

기존 Maker들은 자기 KPI가 Make 방향으로 정렬되어 있다고 믿었다. 코드를 짜고, 기능을 배포하고, PR을 올리고, 스프린트를 마감하는 것. 새벽까지 코딩하고, 주말에도 배포하고, 장애가 나면 달려가는 사람들. 실제로 열심히 하는 사람들이었다.

하지만 IT 조직 대부분의 Maker가 비즈니스 KPI에 직접 기여하지 않는다고 판단되는 순간이 온다. 그 순간 구조조정이 일어난다. 빅테크들이 수만 명을 내보냈고, 그들 중 대다수는 열심히 일하던 사람들이었다.

안타깝지만, 이건 대부분 개인의 잘못이 아니다. 조직이 고민 없이 채용한 인력들이, 주어진 일을 열심히 하다가 맞는 역풍이다.

AI가 이 역풍을 가속하고 있다. Maker의 일 — 코드를 짜고, 기능을 구현하는 것 — 을 AI가 상당 부분 대체할 수 있다는 게 증명되면서, 역풍은 우리 생각보다 훨씬 빠르게 덮치고 있다.

물론 그 와중에도 "이게 정말 조직에 기여하는 일인가?"를 고민하던 사람들이 있었을 거다. 자기가 만든 기능의 데이터를 직접 확인하고, 지표가 안 나오면 "이거 접자"고 먼저 말하던 사람들. 그들은 나가든가, 살아남든가 했을 것이다. 어느 쪽이든 고민한 만큼 다음 행보가 명확했을 거라고 본다. (물론 모두가 이런 기회를 얻은 것은 아니다.)

예전에는 "Maker가 Closer 마인드를 가지면 훌륭한 Maker"라고 칭찬받았다. "개발자인데 비즈니스도 이해하네, 대단해." 지금은? Closer가 되지 않으면 생존할 수 없는 환경이 됐다. 칭찬이 아니라 생존을 위한 필수 조건이 된 것이다.

내가 딸깍하는 만큼 — AI와 함께 코드를 뚝딱 만들어내는 만큼 — 남들도 딸깍한다. 만드는 것 자체가 점점 범용화(commodity)되고 있다. 누구나 만들 수 있는 시대에, "나는 잘 만든다"는 차별화가 안 된다. 딸깍은 더 이상 경쟁력이 아니다.

만드는 것 자체를 사랑하는 마음이 문제가 아니다. 그 사랑의 방향이 달라져야 한다는 거다.

이건 Maker를 비하하는 게 아니다. 나도 Maker다. 만드는 것을 사랑한다. 코드를 짜고, 아키텍처를 설계하고, 깔끔한 PR을 올리는 순간의 쾌감. 그건 여전히 좋다.

하지만 사랑한다고 해서 현실이 바뀌지는 않는다. 만드는 것 자체로는 가치가 완성되지 않는 시대가 왔다. 만들고, 전달하고, 검증하고, 개선해서, 비로소 가치가 된다. 그 전체를 책임지는 사람이 필요하다.

이 부분이 가장 씁쓸하다. 나도 Maker로서 자부심이 있었으니까. 잘 만드는 것이 가치 있다고 믿었으니까. 하지만 현실은 냉정하다.

그렇다고 기술이 필요 없다는 이야기가 아니다. 오히려 그 반대다. 기술은 더 중요해졌다. 다만 어떤 기술이냐가 달라졌을 뿐이다.

이걸 몸으로 깨달은 경험이 있다.

4. 마법사의 오류 — 기술이 더 중요해지는 역설

나는 지금 Golang으로 백엔드를 구현 중이고, iOS로 클라이언트를 개발 중이다.

Golang으로 백엔드를 구현하면 코드 로직 버그로 헤매는 경우는 종종 있지만, 기술 자체를 몰라서 막히는 경우는 거의 없다. 그래서 핵심 로직에 곧바로 집중하고, 수정도 빠르고, AI가 만든 코드도 금방 파악이 된다.

하지만, iOS는 이야기가 다르다. 나는 올해 처음 iOS 네이티브 개발을 시작했고 많은 부분 AI에게 기대고 있다. WidgetKit에서 변수가 제대로 렌더링이 안 될 때, 레이아웃이 내가 원하는 대로 구현이 안 될 때 내가 iOS 네이티브 기술 역량이 부족하니 2~3일을 끝없이 수정해도 AI도 나도 제대로 문제를 수정하지 못하고 무한 루프에 빠지는 경우가 많았다. 특히 자연스러운 화면 트랜지션이나 코드 로그로 테스트가 쉽게 되지 않는 레이아웃 이슈들이 대부분이었다. Navigation Stack의 동작 원리부터 Liquid Glass까지 기본을 모르고 덤벼들었다가 처참하게 깨졌다.

AI는 그럴듯한 결과물을 바이브하게 만들어준다. 해피패스에서는 모든 게 정상으로 보인다. 뒤로 갔더니 헤더가 깨진다. 로딩이 끊긴다. 트랜지션이 자연스럽지 않다. AI는 모든 걸 구현해주었지만 모든 걸 구현하지 않은 상태와 동일했다. 온갖 스킬, 하네스 엔지니어링을 가져다줘도 결국은 한땀한땀이었다. AI와 대화하며 문제를 수정하고, 직접 손으로 재현하고, AI가 같은 문제를 빙빙 돌면 상위 레이아웃이나 앱 전체 콘텍스트를 제공하려고 노력했다. 결국 이런 생각이 든다. ‘iOS 엔지니어라면 훨씬 쉽게 했을 텐데.’

WidgetKit, 화면 트랜지션 등 이해 없이 사용한 기술로 며칠을 삽질했다. 내가 iOS 엔지니어였다면 5분이면 고쳤을 거라고 확신한다. 할 수 있게 되었다고 훌륭하게 잘할 수 있는 건 아니다.

프로덕트 엔지니어는 엔드 유저를 생각하는 엔지니어다. AI가 만들어주는 결과물은 그 시작점이지, 그걸 엔드 유저가 정말 만족할지 고민하며 깎아내는 건 결국 엔지니어의 몫이다. 원리와 감각은 대치가 아니다. 감각을 살리고 싶을수록 원리에 대한 이해 없이는 절대 퀄리티를 만들어낼 수 없을 것이다.

내 경험만이 아니다.

Carson Gross(HTMX 개발자, Montana State 교수)가 "마법사의 제자 함정(Sorcerer's Apprentice Trap)"이라고 부르는데, 딱 내 상황이었다. 디즈니 판타지아에서 마법사의 제자가 빗자루에 마법을 걸어 물을 길어오게 했다가 통제불능에 빠지는 장면. (최애 미키 마우스 애니메이션인데, Ellie는 잘 모른다고 한다. 일요일마다 디즈니 만화동산 보신 분?) AI와 코딩의 관계가 딱 그렇다.

주니어가 코드를 쓸 줄 모르면 코드를 읽을 줄도 모르게 된다. 읽을 줄 모르면 LLM에 휘둘린다.

정확히 내가 iOS 개발에서 겪은 문제였다. 코드는 보통 쓰는 것보다 읽히는 경우가 더 많다. AI가 코드를 써주니까 쓰기 능력이 덜 중요해졌다고? 읽기 능력은 오히려 더 중요해졌다. 내가 쓰지 않은 코드를 읽고, 이해하고, 판단해야 하니까.

더 무서운 건 피드백 루프의 단절이다. 원래는 코드가 복잡해질수록 몸이 먼저 신호를 보낸다. 손이 멈추고, 머리가 아프고.. “이건 너무 어렵다”는 신호가 온다. 그 신호는 설계를 단순화하도록 만든다. 하지만 AI로 생성하면 이 과정은 사라진다. AI는 200줄이든 2,000줄이든 아무렇지 않게 내놓는다. 복잡성은 보이지 않는 채 누적되고, 결국 한꺼번에 폭발한다.

LLM은 본질적 복잡성(essential complexity)을 줄이지 않는다. 우연적 복잡성(accidental complexity)을 쉽게 생성할 뿐이다. Fred Brooks가 1986년에 "No Silver Bullet"에서 구분한 바로 그 개념이다.

Steve Krouse(Val Town CEO)도 비슷한 걸 다른 각도에서 짚었는데, 이것도 내 경험과 정확히 겹친다.

바이브 코딩은 자신의 바이브가 정밀한 추상화라는 환상을 준다.

처음엔 잘 돌아간다. 데모는 완벽하다. 해커톤에서 상도 탄다. 하지만 기능을 추가하거나 규모가 커지면, 이해하지 못한 더 낮은 추상화 레벨에서 버그가 몰래 들어온다. 내가 iOS에서 겪은 것과 똑같다. 네트워크 타임아웃, 메모리 릭, 동시성 이슈 — 프로덕션에서, 사용자가 예상치 못한 방식으로 쓸 때, 이해하지 못한 레이어에서 문제가 터진다.

그리고 그 문제를 디버깅하려면 — 결국 원리를 알아야 한다.

Krouse가 던진 질문 하나가 계속 머릿속에 남는다. "아무도 '바이브 라이팅(vibe writing)'을 말하지 않는다." 글쓰기에서는 "느낌대로 쓰면 된다"를 진지하게 받아들이는 사람이 없다. 좋은 글을 쓰려면 문법을 알아야 하고, 구조를 이해해야 하고, 수많은 글을 읽어야 한다. 그런데 왜 코딩에서는 "바이브대로 하면 된다"를 진지하게 말하는가?

생각해보면 이건 도구 지식과 원리 지식 의 구분으로 귀결된다.

도구 지식 — Swift 문법, React 패턴, Kubernetes YAML, 특정 프레임워크의 API. 이건 AI가 대체할 수 있다. 이미 대체하고 있다. 나도 요즘 Swift 문법을 외우지 않는다. Claude가 알고 있으니까.

원리 지식 — 네트워크, 컴퓨터 구조, 운영체제, 분산 시스템, 자료구조, 알고리즘. 이건 AI 시대에 오히려 더 빛난다. AI가 만든 코드가 "왜 느린지", "왜 동시성 문제가 생기는지"를 판단하려면 원리를 알아야 하니까.

AI에게 "이 코드 왜 느려?"라고 물어볼 수 있다. AI가 답을 줄 수도 있다. 하지만 그 답이 맞는지 판단하는 건 — 원리를 아는 사람의 몫이다. AI가 "캐시를 추가하세요"라고 했는데, 진짜 문제가 캐시가 아니라 N+1 쿼리라면? 네트워크와 DB를 이해하는 사람만이 그 차이를 짚을 수 있다.

엔지니어링 마인드는 엔지니어링 이론 위에서 발현되는 것이지, 마인드만으로 만들어질 수 없다. (프로덕트 엔지니어도 결국 엔지니어다.)

네트워크를 모르면서 "이 API가 느린 것 같다"고 말하는 건 감각이 아니라 추측이다. TCP 핸드셰이크를 이해하는 사람이 "여기서 레이턴시가 발생하고 있다"고 말할 때, 그게 감각이다. 운영체제를 모르면서 "앱이 무거운 것 같다"고 말하는 건 인상이다. 메모리 관리 원리를 아는 사람이 "여기서 메모리 릭이 생기고 있다"고 짚을 때, 그게 진단이다.

CS 기초 위에 제품 감각이 올라가야 한다. 순서가 중요하다. 기초 없이 감각만 키우려는 건, 기초 체력 없이 기술 축구를 하겠다는 것과 같다.

마법사의 오류는 여기에 있다. AI가 도구 지식을 대체하니 ‘기술의 중요성이 줄어든다’고 착각한다. 하지만 실제로는 원리 지식이 더 중요해졌다. 도구 지식이 빠진 자리는 결국 원리 지식이 채워야 한다.

5. 원리 위의 감각 — Eval

그렇다면 원리만으로 충분할까?

아니다. 감각 없는 원리는 학자를 만들 수는 있어도, 좋은 엔지니어를 만들지는 못한다. CS 박사라고 좋은 엔지니어가 되는 것도 아니고, 논문을 잘 쓴다고 제품을 잘 만드는 것도 아니다. 원리를 아는 건 필요조건이지, 충분조건은 아니다.

Hoskins의 The Product-Minded Engineer 에 나오는 “밥(Bob)” 이야기가 이 점을 잘 보여준다. 밥은 실력 있는 엔지니어다. 원리도 알고, 코드도 깔끔하며, 리뷰도 꼼꼼하다.

하지만 밥은 시나리오 없이 구현한다.

스펙에 적힌 대로 만들 뿐, "사용자가 이 기능을 실제로 어떤 상황에서 쓸까?"를 생각하지 않는다. 밥이 만든 기능은 잘 동작하고 테스트도 통과한다. 그런데 사용자는 그 기능을 쓰지 않는다.

"기술적으로 완벽한 기능인데 아무도 안 쓴다" — 나도 여러 번 겪었다 (어쩌면 지금도.)

Hoskins은 엔지니어를 편집자 에 비유했다. 좋은 문장을 쓰는 사람이 아니라 불필요한 문장을 잘라내는 사람. "이건 안 넣어도 된다"를 판단하는 사람. 이것이 제품 아키텍처(Product Architecture)의 핵심이다.

AI는 코드를 잘 짜줄 수 있다. 하지만 "이 기능이 정말 사용자에게 필요한가?"를 판단하는 건 여전히 인간의 영역이다.

이 판단 능력 — Anthropic은 이걸 "taste"라고 불렀다. AI를 가장 잘 만드는 사람들이, AI에 가장 마지막까지 맡기지 않는 것.

그런데 taste라는 단어가 좀 신비롭게 들린다. "taste는 타고나는 거 아닌가? 없는 사람은 어쩌라고?" 나도 처음엔 그렇게 느꼈다. 특히 주변에 taste가 뛰어난 엔지니어를 보면 더 그렇게 느낀다.

그런데 Linear CTO Thomas가 정확히 답했다.

Taste is not mystical. It's a craft.

감각은 신비로운 게 아니다. 크래프트다. 갈고닦을 수 있다.

Linear 팀이 이걸 증명했다. Quality Wednesday — 매주 수요일, 팀 전체가 제품의 결함을 찾아 수정한다. 스크롤이 미세하게 끊기는 것, 버튼 간격이 3px 어긋난 것 같은 사소한 결함들까지 집요하게 다룬다. 그렇게 2년간 2,500개의 defect를 수정했다. 이 과정을 매주 반복하면 ‘항상 다음 수정할 것을 찾는 마인드셋’이 자동으로 형성된다. Taste는 그렇게 근육처럼 몸에 붙는다.

좋은 글을 많이 읽으면 나쁜 글이 눈에 들어오는 것처럼. 좋은 UX를 많이 경험하면 나쁜 UX가 거슬리는 것처럼. 겉으로 보이는 직관은 안으로 쌓인 경험의 결과물이다.

Taste는 경험의 축적이지, 천부적 재능이 아니다.

이전 글에서 에이전틱 엔지니어링 9가지 스킬을 다뤘다. 이번 글을 쓰면서 하나를 더 추가해야 한다는 확신이 들었다.

Eval. AI가 만든 결과물을 평가하는 판단력.

9가지 스킬이 "AI와 함께 일하는 법"이라면, Eval은 "AI의 결과물을 판단하는 법"이다. Taste가 "이건 좀 아닌데"라는 감각이라면, Eval은 "왜 아닌지 구체적으로 짚고 수정 방향을 제시하는 것"이다.

AI에게 UI 레이아웃을 맡긴다. 코드를 생성하고, 테스트를 돌린다. All Pass. CI도 녹색이다.

"오, 잘 되네."

그런데 실제 디바이스에서 만져보면 전혀 다르다.

좁은 화면에서 레이아웃이 찌그러진다. 스크롤이 어색하다. 터치 영역이 너무 작아서 손가락이 두꺼운 사람은 누르기 어렵다. 텍스트가 잘려 보인다. 애니메이션이 의도와 다르게 동작한다.

AI는 테스트 케이스에 맞게 최적화하지, 사용자 경험에 맞게 최적화하지 않는다. AI가 만든 코드가 기능적으로 동작하는 것과, 그 코드가 사용자에게 좋은 경험을 주는 것은 완전히 다른 차원의 이야기다. 전자는 AI가 할 수 있다. 후자는 아직, 그리고 당분간은, 인간의 몫이다.

더 문제인 건, AI가 레이아웃의 좁은 범위만 수정하면서 전체적인 일관성을 깨뜨리거나, 아예 잘못된 방향으로 개발이 진행될 때다. 테스트는 계속 All Pass인데, 제품은 점점 이상한 곳으로 가고 있다. AI는 당신만큼만 똑똑하다 — 이전에 쓴 글 제목 그대로다. AI의 판단은 내 판단을 넘지 않는다.

"AI의 All Pass가 나에게도 All Pass인가?"

이 질문을 던질 수 있는 사람이 AI Native Engineer다. 테스트가 통과했다고 안심하는 게 아니라, 직접 눈으로 보고, 손으로 만져보고, 사용자의 입장에서 판단하는 사람. 그게 Eval이다.

그리고 이 Eval은 — 네트워크가 어떻게 동작하는지, 메모리가 어떻게 관리되는지, 렌더링 파이프라인이 어떻게 흘러가는지 아는 사람이 더 잘한다. 원리 위에서 감각을 발휘하는 것. 그게 진짜 Eval이다.

예전에는 E2E 책임 — 기획부터 배포, 사용자 피드백까지 — 이 PO나 CEO의 몫이었다. 개발자는 "시키는 대로 잘 만들면 됐다." 이제 그 경계가 무너지고 있다. AI가 "잘 만드는 것"을 대신하니까, 남은 인간의 역할은 "뭘 만들어야 하는가"와 "그게 정말 가치가 있는가"를 판단하는 것이다.

그리고 이건 개인의 의지만으로는 안 된다. 그 역할과 책임이 주어지지 않는 환경이라면, AI Native Engineer로 성장하기 좋은 환경이 아니다. "너는 이 기능을 스펙대로 구현하면 돼" — 이런 조직에서는 Eval 능력이 자랄 수 없다. 사용자를 만날 기회도, 지표를 볼 권한도, "이걸 왜 만들지?"라고 물을 공간도 없다.

6. 그래서 나는

여기까지 읽었으면 궁금할 거다. 그래서 어떻게 해야 하는가.

나도 다 겪어봤다. 그 함정을 하나하나 밟아봤다.

“먼저 공부하고 시작해야지.” 나도 그랬다. 합리적으로 들리지만, 사실은 시작하지 않겠다는 선언이었다. 게다가 AI 도구는 매달 바뀐다. 준비가 끝나기만 기다려서는 영원히 시작할 수 없다. 수영을 배우려면 물에 들어가야 하듯, 수영 이론 책을 아무리 읽어도 수영은 배울 수 없다. 1년 뒤에도 여전히 같은 말을 하고 있는 나를 발견했을 때, 비로소 깨달았다.

나도 트위터를 열고 "나도 해야 하는데…"를 중얼거리다가 닫은 적이 있다. 불안은 행동의 연료가 될 수 있지만, 불안 자체가 행동을 대체하지는 않는다.

"강의부터 들어볼까." 나도 처음에 그 생각을 했다. 그런데 깨달았다. AI는 내 질문에 직접 답해준다. 강의를 듣고 있을 시간에 직접 부딪히는 게 열 배 빠르다. 엔지니어가 도구를 강의로 배운다는 게 좀 이상하지 않은가 (이 말이 좀 꼰대같은 건 안다. 좋은 강의들도 분명 있다.)

그리고 코드로만 소통하던 시절이 있었다. AI가 코딩을 대신할수록, 사람과 대화하고 사용자를 이해하는 능력이 차별화 요인이 되는데, 나도 "이 기능이 왜 필요한지 설명해주세요"라는 질문 앞에서 말문이 막힌 적이 있었다.

전환점은 직접 부딪히기 시작하면서 찾아왔다.

막히면 AI에게 물어봤다. 에러가 나면 에러 메시지를 복붙하고, 설계가 막히면 아키텍처를 물어보고, 테스트가 실패하면 왜 실패하는지 같이 분석했다. 이 과정 자체가 학습이었다. 강의 열 개보다 삽질 한 번이 낫다는 걸 몸으로 배웠다.

본인이 원하는 걸 직접 만들어봤다. "언젠가 만들어야지"가 아니라 지금 시작했다. AI가 있으니까 예전보다 훨씬 빨리 만들 수 있었다. 빠르게 만들 수 있으니, 빠르게 실패할 수도 있었다. 그게 오히려 기회였다.

그리고 결정적으로, 실제 사용자가 있는 프로덕트까지 끌고 갔다. 혼자 쓰는 사이드 프로젝트와 다른 사람이 실제로 쓰는 제품은 천지 차이다. 사용자가 “이거 불편해요”라고 말하는 순간, 밀려오는 불쾌감과 배움의 혼합. 그걸 겪어봐야 제품 감각이 생긴다. 그 감각은 AI가 대신 길러주지 않는다.

나는 기술과 Maker에 대한 동경이 있다. 여전히. 새로운 프레임워크가 나오면 만져보고 싶고, 깔끔한 아키텍처를 설계하면 뿌듯하고, 코드가 아름답게 동작하면 행복하다. (고퍼콘에서 Golang의 동시성을 극대화한 프로젝트 발표들을 들으며 스스로 좌절을 느낀 건 덤이다.) 뛰어난 Maker를 보면 존경한다.

하지만 진짜 가치를 만들어내는 건 그게 아니었다. 아무리 아름다운 코드를 짜도, 그게 사용자에게 가치를 전달하지 못하면 자기만족일 뿐이다. 우리 모두는 비즈니스가 실제 가치를 발현할 때만 유의미하다. 이걸 인정하는 데 오래 걸렸다.

사용자를 무시하는 개발자들을 가끔 봤다. "사용자가 뭘 아나", "기획이 잘못된 거지", "기술적으로 이렇게 해야 맞아." 나도 그런 적이 있었다 (지금 생각하면 민망하다).

돌이켜보면 그건 방어기제였다. 사용자를 진지하게 고려하면 훨씬 더 높은 퀄리티가 요구된다. 매끄러운 UX, 끊김없는 서버 인프라, 자연스러운 AI 기능 — 진짜 사용자를 생각하면 모든 분야에서 챌린지가 있다. 자신 없으니까 외면하는 거다. "기술적으로 올바른 것"에 숨으면 편하니까.

여러 제품을 만들어봤다. 사업 실패도 겪었다. 조직을 승리로 이끌지 못했을 때 어떻게 무너지는지도 직접 겪었다. 능력 있는 사람들이 방향을 잃고 흩어지는 걸 봤다. 기술적으로는 훌륭한 팀이었다. 하지만 "우리가 만드는 것이 사용자에게 가치를 주고 있는가?"라는 질문에 명확히 답하지 못했다.

그 경험이 — 기술에 대한 동경보다 훨씬 깊은 곳에서 — 나를 여기까지 데려왔다.

기술을 사랑하는 것과 기술로 가치를 만드는 것은 다르다. 하지만 대립이 아니다. 기술을 사랑하기 때문에 원리를 파고들고, 원리를 알기 때문에 AI 시대에 더 빛난다. 사랑이 없으면 원리는 그냥 교과서일 뿐이다.

나는 둘 다 하고 싶다. 하지만 우선순위가 바뀌었다. 예전에는 기술이 먼저였다. 이제는 가치가 먼저다.

나는 AI Native Engineer인가? 모르겠다. 아직 되어가는 중이라고 말하는 게 솔직할 거다. 다만, 방향은 알고 있다. 기술이 아니라 가치. Make가 아니라 Close. 코드가 아니라 사용자. 원리를 쌓으면서 감각을 갈고닦는 것.

지금은 Ellie와 함께 앱을 만들면서, AI를 쓰고, 피드백 받고, 지표를 보고, 다시 고친다. 어제 만든 걸 오늘 부수고, 오늘 만든 걸 내일 다시 고친다. 렌더링 파이프라인을 이해하면서 사용자 경험을 판단하고, 시스템 아키텍처를 알면서 "이건 안 만들어도 된다"를 말하려고 노력한다.

가치를 만들어내기 위해 오늘도 고군분투한다. 그게 내가 할 수 있는 전부다.

화려하지 않다. 하지만 이게 진짜다.

7. 나가며 — 가속기 위의 나침반

"당신이 만드는 것은 정말 가치를 발생시키고 있는가?"

에이전트 수십 개 동원해서 n차 에이전트 피드백을 통해 기획안을 내도 Ellie는 부족한 점을 지적한다. 이 글도 마찬가지다. AI가 그럴듯하게 초안을 제시했지만 결국은 내가 대부분의 내용을 다시 작성하고, AI workflow에서는 어느 정도의 퇴고만 하는 것이다. 여러분도 알 것이다. AI로만 자동화한 글이 얼마나 허접한 느낌이 나는지.

아무리 테스트 자동화를 해도 결국은 내가 사용해보는 행위 자체를 생략할 수는 없다. 그리고 AI에게 100번 테스트를 시키는 것보다 내가 빠르게 사용해보고 정리하는 게 훨씬 빠를 때가 많다.

테리 위노그라드 — 1971년 SHRDLU부터 반세기 넘게 AI를 봐온 스탠포드 1세대 연구자 — 의 말이 있다.

AI는 문제의 원인이 아니다. AI는 가속기(Accelerant)다.

과거의 AI 겨울을 직접 통과한 사람이 하는 말이니 무게가 다르다. 이전에도 존재하던 문제들이 AI에 의해 가속되고 있을 뿐이다. 좋은 방향으로 달리던 사람은 더 빨리 좋은 곳에 도착한다. 잘못된 방향으로 달리던 사람은 더 빨리 벽에 부딪힌다. 달라진 건 속도지, 방향이 아니다.

가속기에는 나침반이 필요하다.

그 나침반은 원리 위에 세워진 감각이다.

원리 없는 감각은 추측에 머물고, 감각 없는 원리는 학문에 머문다.

AI Native Engineer는 원리 위에서 감각을 발휘하는 사람이다.

네트워크를 이해하면서도 사용자 경험을 판단할 수 있는 사람. 시스템 아키텍처를 알면서도 "이건 안 만들어도 된다"를 말할 수 있는 사람. 코드를 읽을 줄 알면서도 "이 코드가 풀고 있는 문제가 맞는가?"를 물을 수 있는 사람.

How(에이전틱 스킬)를 갖추고, Where(AX 조직)에서 일하더라도, Who(나 자신)가 원리 위에서 감각을 발휘하는 사람이 아니면 아무 의미가 없다.

원리 위의 감각. 그게 AI Native Engineer다.

E2E로 책임지는 엔지니어가 원래 좋은 엔지니어였다. AI 이전에도 그랬고, AI 이후에도 그럴 것이다. 다만 이제는, 그 사실을 모른 척하기가 어려워졌을 뿐이다.

References

Andrej Karpathy, X post on AI Builders vs Coders
Mike Mason / ThoughtWorks, "AI-First Software Engineering — Context Engineering"
Steve Yegge, "Revenge of the Junior Developer"
OpenAI, "Building an AI-Native Engineering Team"
Drew Hoskins, The Product-Minded Engineer (O'Reilly, 2025)
Pragmatic Engineer, "How to Be a 10x Engineer"
DORA, "Accelerate State of DevOps Report 2025"
Rem Koning / Harvard Business School, "하버드에서 가르치는 AI Native 강의" — EO Korea
Nicole Forsgren / Faros AI, "Key Takeaways from the DORA Report 2025"
Terry Winograd, Stanford Interview on AI as Accelerant
Carson Gross, "Yes, and... The Sorcerer's Apprentice Trap"
Steve Krouse, "The Death of Code is Greatly Exaggerated"
Anthropic, "How AI Is Transforming Work at Anthropic"
Pragmatic Engineer, Product-Minded Engineer Panel — Linear CTO Thomas: "Taste is not mystical. It's a craft."
Linear, Quality Wednesday
flowkater, "에이전틱 엔지니어링 9가지 스킬"
flowkater, "AX 조직 전환"
flowkater, "AI는 당신만큼만 똑똑하다"
flowkater, "승리 없는 미래"
flowkater, "2025 고퍼콘 코리아 후기"

조직에 Claude Code를 설치한다고 AX가 되지 않는다

Tony Cho (https://flowkater.io) — Sun, 15 Mar 2026 09:30:00 GMT

조직에 Claude Code를 설치한다고 AX가 되지 않는다

1. 들어가며 — 반가움과 불편함 사이

링크드인에 한 스타트업이 전사에 Claude Code를 도입했다는 포스팅이 올라왔다. OpenClaw를 전사 도입해서 생산성이 폭발적으로 올랐다고 주장하는 글도 보았다. 국내의 보수적인 조직문화 — 스타트업조차도 — 를 고려하면 이런 시도는 칭찬받을 만하다.

솔직히 나도 처음엔 "이거 대단한데?"라고 생각했다. 나 역시 AI 도구를 팀에 붙여보고, MCP를 연결해보고, 생산성이 올라가는 걸 체감한 사람이다. 근데 뭔가 이상했다. 도구는 분명 좋아졌는데, 조직이 일하는 방식 자체가 바뀌었다는 느낌은 없었다.

이것이 진정한 조직 레벨의 AX — AI Transformation, AI를 전제로 조직 전체를 재설계하는 것 — 일까? 조직이 AI를 제대로 도입했다고 볼 수 있을까?

Claude Code 이전에 Notion도 있었다. 구글 드라이브도 있었고, Slack도 있었다. 본질적으로 생각해보자. 지난 10여 년간 조직들이 이런 툴들을 도입하면서 정말 이전과 다른 폭발적인 생산성 향상이 있었나? 그 생산성 향상이 정말로 성과(Outcome)로 이어졌나? 과연 도구만을 도입해서 그러한 성과를 만들어낸 사례가 있는가?

지금까지 AI 네이티브 엔지니어에 대한 이런저런 이야기를 해왔는데, 이번에는 AI 네이티브 조직은 어떻게 만들어져야 하는가를 이야기하려 한다. LLM 성능의 급격한 발전으로 우리가 직접 체감하는 것과, 조직 레벨의 성과 사이에 얼마나 큰 갭이 있는가.

이 갭을 정리하려면 먼저 용어를 나눠야 한다. 이 구분이 중요한 이유는, 같은 단어 "AI 도입"을 쓰면서 전혀 다른 수준의 변화를 이야기하는 사람들이 너무 많기 때문이다. 나는 AI와 조직의 관계를 세 단계로 본다.

1단계. AI 사용 — 개인이 ChatGPT, Claude, Copilot을 업무에 쓰는 상태. 대부분의 직장인이 여기에 있다. 아직 도구를 고르고 있거나, 프롬프트를 다듬고 있거나, "이거 꽤 편한데?" 하고 놀라는 단계다.

2단계. AI 도입(Enablement) — 회사가 설치 가이드를 만들고, 교육 세션을 열고, 접근권을 제공하는 상태. 최근 화제가 된 사례들은 대부분 여기에 있다. MCP를 배포하고, 비개발자까지 사용법을 가르치고, 직무별 워크플로우를 시연한다. 충분히 가치 있는 일이다.

3단계. AX 전환 — 역할, 승인 체계, KPI, 파이프라인, 거버넌스, 책임 구조가 AI를 전제로 다시 설계된 상태. 여기까지 간 조직은 거의 없다. Bain은 "GenAI를 툴처럼 다루는 접근은 작동하지 않는다"고 말하고, McKinsey는 "AI 성숙 단계 조직은 1%에 불과하며, 가장 큰 장애물은 리더십"이라고 정리한다.

이 글은 2단계를 3단계로 착각하는 현상에 대한 글이다. 도입과 전환의 차이를 말하고, 그 차이 속에서 조직과 개인 — 특히 Maker(산출하는 사람)와 Closer(성과를 완결하는 사람) — 의 역할이 어떻게 달라져야 하는지를 이야기하려는 글이다.

2. 좋은 도입과 좋은 전환은 다르다

먼저 공정하게 읽자. 최근 화제가 된 국내 사례들이 실제로 잘한 것은 명확하다.

그 회사는 설치 장벽부터 제거했다. OS별 가이드를 만들고, MCP를 배포하고, 전사 세션을 열었다. 비개발자 동료가 직접 시연하게 해서 "나도 할 수 있겠다"는 인식을 만들었다고 한다. BX, HR, PM, 재무, CX, 사업개발 — 직무별로 실제 워크플로우가 만들어졌고, 사내 설문조사에서 응답자 전원이 "거의 매일 사용한다"고 답했다.

이건 대부분의 국내 기업이 아직 못 하는 일이다. 충분히 가치 있다.

해외에서도 좋은 도입 사례는 많다. Morgan Stanley는 재무상담사 워크플로우에 AI를 박아 넣어 회의 노트 → 요약 → 메일 초안 → Salesforce 저장까지 연결했고, 어드바이저 팀의 대다수가 채택했다. 인상적이다. 하지만 Morgan Stanley 스스로도 "인간적 관계가 여전히 핵심"이라고 말하듯, 재무상담사의 역할 자체가 바뀐 건 아니다. 도구가 더 좋아진 것이다.

그런데 여기서 한 발 더 나아가 질문을 해야 한다. 이 변화의 단위는 무엇인가?

PM은 더 빨라진 PM이 되었다. 재무는 더 빨라진 재무가 되었다. HR은 더 빨라진 HR이 되었다. 각자의 직무 안에서 AI가 작업을 가속해준 것이다. 하지만 PM과 재무와 HR 사이의 관계는 바뀌었는가? 승인 체계는? KPI는? 의사결정 흐름은?

레딧에서 본 댓글이 이걸 정확히 짚는다. "AI made the 'typing' part instant, but it didn't solve the organizational friction. So the business sees the same velocity, even if the devs feel like wizards." — AI가 '타이핑'은 즉각적으로 만들었지만, 조직적 마찰은 해결하지 못했다. 비즈니스는 같은 속도를 보는데, 개발자만 마법사가 된 기분이다.

사실 7~8년 전에도 비슷한 풍경이 있었다. Notion을 도입하면 조직의 지식이 흐를 거라고 기대했다. Slack을 도입하면 소통이 빨라질 거라고 믿었다. 결과는? Notion은 부서별 위키가 되었고, Slack은 부서별 채널이 되었다. 도구는 바뀌었지만 정보가 흐르는 구조는 바뀌지 않았다. 지금 AI 도구 도입에서도 같은 패턴이 반복되고 있다.

도구를 잘 깔아주는 것과, 조직이 그 도구를 전제로 다시 설계되는 것은 다른 차원의 일이다. "그래도 시작이 중요하지 않나?" — 맞다. 부정하지 않는다. 다만, 시작점을 목적지로 오해하면 안 된다.

당신의 조직에서 AI를 도입한 후, PM과 개발자 사이의 핸드오프 횟수가 줄었는가? 승인에 걸리는 시간이 줄었는가? 고객에게 가치가 전달되는 속도가 빨라졌는가? 이 질문에 "아니오"라면, 그건 아직 도입이지 전환이 아니다.

물론, 실제로 잘하고 있는 팀도 있다. 한 10년차 엔지니어링 매니저는 팀 전체가 Claude Code를 도입한 경험을 이렇게 정리했다. 단일 에이전트 환경으로 통일하고, 기존 Confluence 런북을 AI 스킬로 변환했다. 코드베이스와 아키텍처 문서를 AI 컨텍스트로 정비하고, 티켓 생성을 자동화하면서 누락 요구사항을 사전에 잡아냈다. 회의록을 AI로 검증해서 논의가 삼천포로 빠지면 즉시 교정했고, 주간 "AI 워크플로우 공유" 미팅까지 새로 만들었다.

여기서 주목할 건, 이 팀이 도구만 깔지 않았다는 점이다. 회의 구조, 티켓 프로세스, 문서 체계, 주간 미팅 — 일하는 방식 자체를 바꿨다. 한 유럽의 소규모 사업자도 비슷한 말을 했다. "가장 큰 전환은 도구 자체가 아니라 일상 워크플로우의 재설계였다. 기존 프로세스 위에 AI를 얹으면 미미한 이득뿐이다."

잘 된 곳을 들여다보면 패턴이 보인다. 도구를 잘 깔아서 성공한 게 아니라, 일하는 방식 자체를 바꿔서 성공한 것이다. 하지만 이건 한 팀의 이야기다. 팀 단위의 전환은 가능하다. 조직 전체의 전환은 리더십이 구조를 다시 짜야만 일어난다.

3. 왜 기존 기능 조직은 AI를 흡수하면서도 그대로 남는가

기존 기능 조직의 문제는 AI를 못 쓰는 데 있지 않다. 오히려 너무 잘 흡수해버리는 데 있다. 마케팅은 마케팅 안에서, 재무는 재무 안에서, 개발은 개발 안에서 AI를 붙여 더 빨라질 수 있다. 하지만 AX가 필요한 곳은 부서 안이 아니라 부서 사이다. 직무 안이 아니라 가치 흐름 전체다.

AI는 사일로를 깨는 게 아니라 강화한다

사람들은 AI가 부서 간 벽을 허물 거라고 기대한다. 현실은 반대로 갈 수 있다. 각 부서가 자기 업무 안에서만 AI를 최적화하면, 마케팅은 마케팅용 AI를, 고객지원은 고객지원용 AI를 따로 고도화하게 된다. 조직 전체 성과는 좋아지지 않은 채 부서별 AI 섬만 생긴다. HBR은 AI가 오히려 기능 사일로를 강화하는 경우가 많다고 지적한다.

AI를 기능 조직에 얹으면, 기능 조직이 사라지는 게 아니라 더 빠른 기능 조직이 된다. 이건 고속 사일로화, 단어 그대로 부서 이기주의를 가속화할 뿐이다. 이건 AX가 아니다.

병목은 부서 안이 아니라 부서 사이에 있다

내가 CTO로 있을 때 겪은 일이다.

타 부서에서 실제 KPI에 기여할 프로젝트 기획서를 보내왔다. 그런데 R&D 본부에 들어왔을 때 우리 쪽 우선순위에 밀려 몇 주가 흘렀다. 결국 그 부서들은 CEO를 통해 협조를 "요청"이 아닌 "통보"로 내려보냈고, 진행하던 작업을 멈추고 그쪽 작업을 시작하게 되었다. 하지만 그때는 이미 프로젝트 런칭 타이밍이 크게 어긋나 있었다. 시장이 기다려주지 않았다.

같은 본부 안에서도 마찬가지였다. 리드 → PM → 디자인 → 프론트 → 백엔드 → QA로 흐르는 정보 파이프라인이 원활하지 않은 경우가 부지기수였다. 대개 기능 팀 내에서의 KPI — 예를 들어 개발자들은 각자 맡은 기능 배포 — 에 머물다 보니, 제품의 완성도나 사후 분석 같은 어쩌면 개발 단계보다 훨씬 중요한 일이 같은 제품을 만드는 사람들 사이에서조차 진행되지 않았다.

결국엔 "왜 우리가 남의 부서 일을 해야 되나요?"라는 불평이 들리기 시작했다. 나는 그 팀원을 나무랄 수가 없었다. 구조적 한계로 인해 조직원들이 그렇게 변해가는 건 그 사람의 잘못이 아니었다.

그 이후로 조직은 지지부진하게 흘러갔다. 각자의 책임 돌리기에 급급해졌고, 조직 자체가 주도성을 잃었다. 능력 있는 개인들도 빛을 잃어갔다. 리더십에서는 갈수록 수동적인 조직원들에게 불만이 생겼고, 수동적 목표만을 바라보는 조직원들은 조직에 대한 불신과 실망만 커져갔다. 어쩌면 기능 조직의 단점을 극대화한 사례였지만, 리더 입장에서 능력 있고 주도적이었던 팀원들이 그렇게 수동적으로 변하는 경험은 썩 유쾌한 경험이 아니었다.

(승리하지 못하는 조직은 어떻게 무너지는가에서 이 이야기를 더 자세히 다뤘다.)

문제는 "누가 더 빨리 일하느냐"보다 **"어떻게 일이 흘러가느냐"**다. AI가 부서 안 작업을 아무리 가속해도, 부서 사이의 승인 대기, 핸드오프, 의사결정 지연은 그대로다. 국소 생산성은 올라가도, 조직 전체의 처리 시간은 그대로일 수 있다.

각 부서는 더 잘하게 되는데, 회사는 더 잘 이기지 않는다

기능 조직에서는 각 부서가 자기 KPI를 가진다. 마케팅은 MQL, 세일즈는 매출, 개발은 배포 속도, CS는 응답 시간. AI가 들어오면 각 부서가 자기 KPI를 더 잘 달성하는 방향으로만 움직인다. 하지만 조직 전체 성과는 부서별 효율의 합이 아니다. BCG는 보상·평가·거버넌스가 레거시 모델을 보상하면 전환이 멈춘다고 경고한다.

AI의 병목은 프롬프트가 아니라 승인 구조다. 툴은 설치할 수 있지만, 책임 구조는 설치되지 않는다.

상향식 확산만으로는 구조가 안 바뀐다

개발자는 설치 가이드를 만들고, 스킬을 공유하고, MCP를 연결하고, 사내 전도사가 될 수 있다. 하지만 개발자는 인원 정책을 바꾸지 못하고, 평가 제도를 바꾸지 못하며, 부서 간 경계를 다시 긋지 못한다.

Uber의 사례가 이걸 잘 보여준다. 개발자의 84%가 에이전트를 사용하고, PR의 11%를 에이전트가 직접 오픈한다. 수치만 보면 AX에 가까워 보인다. 하지만 동시에 AI 관련 비용은 2024년 대비 6배 증가했고, CFO 레벨에서 이것이 비즈니스 임팩트로 연결되는지는 아직 미해결 과제다. 성공 사례로 보이는 곳도 완벽하지 않다. 채택 속도도 예상보다 느렸다.

이런 체감과 실측의 간극을 보여주는 데이터도 있다. METR의 무작위 대조 실험에서 숙련된 오픈소스 개발자들에게 AI 도구를 주고 작업 시간을 측정했더니, 실제로는 19% 느려졌다. 그런데 작업이 끝난 후 개발자들은 20% 빨라졌다고 보고했다. 이게 조직 단위로 일어나면, "우리는 AI로 혁신했다"는 확신이 실측 데이터와 분리된다.

한 스타트업 대표의 경험담도 같은 맥락이다. "CTO에게 Cursor를 줬더니 1주일짜리 작업을 몇 시간에 끝냈다. 그래서 전체 팀에 줬는데, 같은 결과가 나오지 않았다." 코드베이스의 맥락을 쥔 한 사람의 생산성과, 팀 전체의 생산성은 다른 문제다.

개발자는 AI를 회사에 퍼뜨릴 수는 있어도, 회사를 AI 기준으로 다시 짤 수는 없다.

4. 무엇이 바뀌어야 전환인가 — 사례에서 읽는 5가지 축

3장에서 기능 조직의 구조적 한계를 말했다. 그렇다면 실제로 그 한계를 넘은 회사들은 무엇을 바꿨는가? 단순히 "AI를 잘 쓴다"가 아니라, 조직의 어떤 축이 달라졌는가를 사례에서 읽어보자.

역할을 바꾼 회사 — Shopify

AX의 첫 번째 축은 역할이다. AI가 들어왔는데 모든 사람이 여전히 같은 일을 하고 있다면, 그건 도입이지 전환이 아니다.

Shopify CEO Tobi Lütke는 AI 사용을 기본 기대치로 규정했다. 새로운 인원이나 자원을 요청하려면 먼저 "왜 AI로 안 되는지" 증명해야 한다. 성과 평가와 동료 평가에도 AI 활용이 반영된다. 이건 권장이 아니라 규칙이다. 기존에 직무별 생산자였던 역할이, AI를 전제로 한 감독자·리뷰어·판단자로 재정의되기 시작한 것이다. 개발자가 아무리 AI를 전파해도 채용 기준, 평가 기준, 리소스 기준은 못 바꾸지만, CEO는 바꾼다.

당신의 조직에서 AI 도입 후, 누군가의 직무 기술서가 바뀌었는가? 바뀌지 않았다면 역할 축은 그대로인 것이다.

파이프라인을 바꾼 회사 — Uber, DBS

두 번째 축은 파이프라인 — 일이 흘러가는 경로 자체다.

앞서 3장에서 Uber의 상향식 채택 한계를 언급했는데, 흥미로운 건 Uber가 그 한계를 인식하고 플랫폼 레벨로 올라갔다는 점이다. Uber는 Claude Code 하나를 깐 게 아니다. MCP 게이트웨이, 백그라운드 에이전트 플랫폼 Minion, 스마트 PR 라우팅 Code Inbox, AI 코드 리뷰 uReview, 자동 테스트 생성 Autocover, 대규모 마이그레이션 관리 Shepherd — 4개 레이어로 구성된 에이전틱 시스템을 구축했다. 개발자 워크플로우 자체가 "단일 IDE에서 코딩"에서 "여러 에이전트를 병렬로 오케스트레이션"하는 방식으로 바뀌었다. 기존의 기능 조직 직렬 핸드오프가 인간-에이전트 혼합 파이프라인으로 전환된 것이다. 다만, 비용은 6배 증가했고 비즈니스 임팩트 연결은 여전히 과제다. 파이프라인을 바꾸는 것이 곧 성공을 보장하지는 않는다.

싱가포르 최대 은행 DBS는 여기서 한 발 더 나갔다. 9개의 운영모델 전환을 완료하고, 인간-AI 협업 워크플로우를 재구축했다. DBS는 이걸 "운영 모델 전환"이라고 불렀다. 단순히 도구를 설치한 것이 아니라, 일이 흘러가는 방식 자체를 다시 설계한 것이다.

KPI와 거버넌스를 바꾼 회사 — 그리고 바꾸지 못한 회사

세 번째와 네 번째 축은 KPI와 거버넌스다. 이 둘은 함께 움직인다. 무엇을 측정하는가(KPI)와 누가 어떤 권한을 가지는가(거버넌스)가 바뀌지 않으면, 아무리 역할과 파이프라인을 바꿔도 조직은 원래 자리로 돌아간다.

BBVA는 3,000명에서 시작해 120,000명 전사로 AI를 확장하면서 CEO 포함 250명의 임원을 직접 교육하고, 보안·법무·컴플라이언스를 시작부터 붙였다. 거버넌스를 나중에 덧대는 게 아니라, 확산 설계에 거버넌스를 내장한 것이다. Box 역시 경영진 후원자 + 기능별 오너십 + 중앙 구축팀 + AI 매니저 구조를 명시적으로 설계하며 AI 도입의 거버넌스를 처음부터 조직 구조에 녹였다. J&J는 900개 AI 활용 사례를 돌린 뒤, 10~15%가 80%의 가치를 만든다는 걸 확인하고 중앙 거버넌스에서 도메인 오너십으로 무게를 옮겼다. "많이 써보자"에서 "뭘 써야 하는지 골라야 한다"로 전환한 셈이다. 전략의 초점이 "사용량"에서 "임팩트"로 바뀐 순간이었다.

Moderna는 스스로 "실시간 AI 조직"으로 규정하며 65% 실사용률을 달성했다. 주목할 점은 사업이 커질수록 사람을 더 필요로 하는 모델을 거부한다는 선언이다. CEO Stéphane Bancel은 수천 명 규모로도 수십억 달러 매출을 운영할 수 있어야 한다고 말했다. 이건 성장의 기준을 "인원 확대"에서 "인당 효율"로 바꾸겠다는 의지다.

반면, 이 축을 건드리지 못하고 무너진 사례도 뚜렷하다.

Klarna는 2024년에 AI 챗봇이 700명분의 일을 대신한다며 인원 축소를 강조했다. 그런데 2025년, CEO는 "비용 절감에 과하게 치우쳤다"고 인정하며 다시 채용으로 돌아갔다. KPI를 "비용 절감"에만 맞추면, 자동화가 곧 운영모델이 되는 착각에 빠진다. 비용은 줄었지만 서비스 품질이 떨어졌고, 결국 다시 사람을 뽑아야 했다.

McDonald's × IBM은 AI 음성 주문을 시험했지만 2024년에 종료했다. 혼선, 주문 오류, 악센트 인식 문제 — 기술적 한계도 있었지만, 현장이 그 기술을 운영할 준비가 되지 않았다는 게 더 본질적이다. 기술과 운영 준비가 함께 가지 않으면 파이프라인 전환은 실험에서 끝난다.

Duolingo는 AI로 148개 코스를 빠르게 확장하며 비즈니스 성과를 냈지만, "AI 우선" 선언과 함께 외주 인력 대체 메시지가 큰 반발을 샀다. 성과가 나더라도, 역할 전환의 맥락 없이 인원 축소만 강조하면 내부와 외부 모두에서 정당성을 잃는다. 변화 관리 없는 전환은 반쪽짜리다.

다섯 번째 축 — 리소스 재배치

마지막 축은 리소스다. AX에 필요한 예산은 툴 라이선스 비용이 아니다. 업무 재설계, 변화 관리, 교육, 운영 원칙 수립에 들어가는 비용이다. BCG는 "진짜 가치는 도구 배포를 넘어 업무 흐름 재설계를 하는 소수 조직이 가져간다"고 정리한다.

Atlassian은 2026년 3월 약 10%(약 1,600명) 감원을 발표하며 AI와 엔터프라이즈 영업에 재투자하고, 업무 체계(System of Work) 기준으로 재조직하겠다고 밝혔다. "AI 때문에 조직 자체를 다시 짠다"는 의지가 명확한 사례다.

정리하면

이 사례들에서 공통적으로 바뀐 것을 정리하면 5가지 축이 된다.

축	기존 기능 조직	AX 조직
역할	직무별 생산자	감독자·리뷰어·판단자·예외 처리자
파이프라인	기능 조직 직렬 핸드오프	인간-에이전트 혼합 파이프라인, end-to-end 단일 조직
KPI	산출량, 가동률	전체 처리 시간, 의사결정 지연, 예외 발생률, 고객 성과
거버넌스	부서별 승인·접근권	중앙 데이터 접근, 모델 권한, 리스크 오너십, 감사 로그
리소스	툴 라이선스 예산	업무 재설계, 변화 관리, 교육, 운영 원칙

이 5가지 축 중 하나라도 바뀌지 않았다면, 그건 아직 도입 단계다. 5가지가 함께 움직일 때 비로소 전환이라 부를 수 있다.

5. AX 조직은 어떤 모습인가

5가지 축을 제시했다. 하지만 축만으로는 그림이 보이지 않는다. 실제로 AX가 된 조직에서 하루가 어떻게 다른지 그려보자.

기능 조직의 프로젝트 vs AX 조직의 프로젝트

기능 조직에서 신규 기능 하나가 세상에 나오는 과정을 생각해보자. PM이 기획서를 쓴다. 디자인팀에 넘긴다. 디자이너가 시안을 만들어 다시 PM에게 확인받는다. 개발팀에 전달된다. 프론트엔드가 먼저, 백엔드가 그다음. QA가 테스트하고, 버그가 나오면 다시 개발팀으로 돌아간다. 릴리즈 후 성과 분석은 데이터팀이 한다. 그 결과가 다시 PM에게 돌아올 때쯤이면 이미 한 달이 지나 있다.

이 과정에서 각 팀의 실제 작업 시간을 합치면 이틀이다. 나머지는 전부 대기, 핸드오프, 컨텍스트 전환, 승인 대기다.

AX 조직에서는 이 흐름이 근본적으로 달라진다. 하나의 목적 단위 팀 안에 프로덕트 엔지니어와 프로덕트 디자이너가 함께 있고, AI 에이전트가 파이프라인의 일부로 작동한다. 별도의 PM이 기획서를 써서 넘기는 구조가 아니다. 프로덕트 엔지니어가 AI의 데이터 분석 위에서 방향을 판단하고, 프로덕트 디자이너가 AI의 초안 위에서 적합성을 판단한다. 코드는 AI가 작성하고 엔지니어가 리뷰한다. 테스트는 자동화되고, 배포 후 성과 분석도 같은 팀 안에서 실시간으로 돌아온다.

기존 PM의 역할을 쪼개보면 이렇다. 기획서 작성 — AI가 한다. 부서 간 조율 — 목적 단위 팀이면 핸드오프 자체가 없으니 필요 없다. 데이터 분석과 우선순위 — AI가 먼저 제시하고 사람이 판단한다. 의사결정 — 이건 남는다. 하지만 이건 프로덕트 엔지니어와 프로덕트 디자이너가 직접 할 수 있다. PM이 존재하는 가장 큰 이유 중 하나는 부서 사이의 핸드오프 브릿지 역할이었다. 부서 경계가 녹으면 그 역할의 비중은 줄어든다.

오해하지 말아야 할 것이 있다. PM이 사라진다는 이야기가 아니다. 실제로 Shopify나 Stripe 같은 회사에서도 PM은 존재한다. 다만 그 PM은 부서 간 조율자가 아니라, 고객 문제를 정의하고 제품 방향을 판단하는 사람이다. 기능 조직에서 "기획서를 쓰고 핸드오프를 관리하는 PM"과, 목적 단위 팀에서 "무엇을 만들지 결정하고 그 결과에 책임지는 PM"은 같은 직함이지만 전혀 다른 역할이다. 전자의 PM은 AX 조직에서 존재 이유가 줄어들고, 후자의 PM은 오히려 더 중요해진다.

핵심적인 차이는 두 가지다. 첫째, 핸드오프가 사라진다. 같은 팀 안에서 일이 흐르기 때문이다. 둘째, 인간의 역할이 산출에서 판단으로 바뀐다. 모든 팀원이 Maker가 아니라 Closer로 작동한다. 코드를 짜는 게 아니라 코드 품질을 판단하고, 디자인을 만드는 게 아니라 디자인 적합성을 판단하고, 기획서를 쓰는 게 아니라 제품 방향을 결정한다.

제품팀을 넘어서 — 마케팅, 재무, CS까지 통합되는 모델

여기서 한 발 더 나가보자. 이 논리를 제품팀에만 적용할 이유가 없다.

기존 기능 조직에서는 제품이 출시되면 마케팅팀이 캠페인을 기획하고, 세일즈팀이 영업을 하고, CS팀이 고객 문의를 받고, 재무팀이 수익을 정산한다. 각자의 KPI가 있고, 각자의 보고 라인이 있다. 제품팀이 만든 기능이 시장에서 어떤 반응을 얻었는지 알려면 이 모든 팀의 데이터를 모아야 하는데, 그 과정에서 또다시 핸드오프와 대기가 발생한다.

AX 조직에서는 이 경계가 녹는다. 하나의 고객 여정 또는 비즈니스 미션 단위로 팀이 구성된다. 그 안에 프로덕트 엔지니어, 프로덕트 디자이너뿐 아니라 그로스 담당, 고객 경험 담당, 수익 분석 담당이 함께 있다. 직함은 달라도 같은 KPI를 본다.

예를 들어 "신규 사용자 온보딩 완료율 80%" 같은 미션이 있다면, 그 팀 안에서 AI가 사용자 행동 데이터를 분석하고, 그로스 담당이 실험을 설계하고, 프로덕트 엔지니어가 온보딩 흐름을 개선하고, 고객 경험 담당이 이탈 사용자 피드백을 정리한다. 이 모든 일이 한 팀 안에서, 같은 대시보드를 보면서, 같은 주간 회의에서 논의된다.

AI가 이걸 가능하게 만드는 이유가 있다. 과거에는 마케팅 전문가, 재무 전문가, 데이터 분석가를 각각 채용해야 했다. 각 전문가가 자기 영역의 산출물을 만들어야 했으니까. 하지만 AI가 산출을 대신하면, 한 사람이 AI를 활용해 마케팅 데이터를 분석하면서 동시에 고객 피드백을 정리하고, 수익 모델링까지 할 수 있다. 전문성의 깊이는 유지하되, 커버리지가 넓어지는 것이다.

앞서 언급한 DBS가 고객 여정의 오너십을 재정의한 것이 바로 이 모델이다. 고객 여정 하나하나가 하나의 목적 단위 팀에 귀속되고, 그 팀이 제품뿐 아니라 마케팅, 고객 경험, 수익까지 end-to-end로 책임진다. Uber가 4개 레이어의 에이전틱 시스템을 구축한 것도 마찬가지다. 개인이 Claude Code를 쓰는 것과, 조직이 에이전트를 파이프라인에 내장하는 것은 완전히 다른 차원의 일이다.

기능 조직은 전문성을 기준으로 사람을 묶었다. AX 조직은 미션을 기준으로 사람과 에이전트를 묶는다. 이게 가장 근본적인 차이다.

AX의 주체는 경영자다

이런 전환을 실행할 수 있는 사람은 누구인가. 개발자가 아니다.

개발자가 할 수 있는 것: 설치, 스킬 공유, MCP 연결, 사내 전도. 개발자가 못 바꾸는 것: 인원 정책, 평가 제도, 부서 간 오너십, 리스크 정책, 예산 배분, KPI.

Shopify는 CEO가 이 선을 넘었다. Uber는 플랫폼 팀이 거버넌스와 비용 체계를 중앙에서 설계했다. BBVA는 CEO를 포함한 250명의 임원을 먼저 교육시킨 뒤 전사 확산에 들어갔다. 공통점은 명확하다. AX는 도입 캠페인이 아니라 경영 재설계다. 경영자가 조직도를 다시 그리겠다는 결정을 내리지 않으면, 아무리 좋은 도구를 깔아도 기능 조직은 더 빠른 기능 조직으로 남을 뿐이다.

Andrew Ng는 AI 시대의 병목은 코딩이 아니라 프로덕트 매니지먼트라고 말한다. 무엇을 만들지 결정하는 능력이 구현 능력보다 희소해지는 시대. 그 결정을 내릴 수 있는 사람은 조직의 위에 있다.

6. Maker와 Closer — 개인의 커리어가 바뀌어야 한다

AX 조직의 그림을 그렸다. 미션 단위 팀, 인간-에이전트 혼합 파이프라인, 핸드오프 없는 end-to-end 구조. 그렇다면 그 조직에서 살아남는 사람은 어떤 사람인가.

조직의 기본 단위가 바뀌면, 필요한 인재도 바뀐다

마케팅, 재무, 개발이 별도의 팀으로 나뉘어 있는 것이 문제다. 하나의 목적 단위로 재조직되어야 한다. 해당 조직의 모든 구성원은 같은 KPI 달성에 집중해야 한다.

Andrew Ng은 가장 큰 병목은 결국 인간 — 특히 프로덕트를 결정하는 사람 — 이라고 말한다. 그런데 기존 기능 조직에서는 인간 대 인간 사이보다 조직 간의 병목이 훨씬 더 큰 지연과 손실을 만들고 있다. 목적 단위로 팀을 묶고, end-to-end 가치 흐름 전체를 한 명의 리더가 책임지는 구조 — 그게 AX에 가장 가까운 형태다.

보고 라인은 여러 개일 수 있어도, 성과 책임자는 하나여야 한다.

불편한 진실 — 현재 인재가 미래 조직에 적합한가

조직을 다시 짜는 데는 돈이 든다. 꽤 많이. 그리고 그보다 더 불편한 진실이 있다: 현재 인재들이 변화하는 조직 체계에 맞는 사람인지, 지금 인원 규모가 정말 필요한지를 조직이 이제 묻기 시작했다는 것. 이 질문들이 새로운 채용을 꺼리게 만드는 진짜 이유다.

AI 시대에 채용이 조심스러워지는 이유는 불황이 아니다. 미래 역할 구조를 확신하지 못하기 때문이다.

Maker와 Closer

여기서 한 가지 구분을 제안한다.

Maker — 마케팅, 개발, 재무 분야 상관없이 현재 업무에서 아웃풋을 생산해내는 데 집중하는 사람이다. 기획서를 쓰고, 코드를 짜고, 디자인을 만들고, 보고서를 작성한다.

Closer — 생산된 아웃풋을 이용하여 실제 비즈니스 KPI를 달성하기 위해 실행하는 사람이다. 아웃풋을 성과로 전환하는 마지막 마일을 책임진다.

여기서 Closer는 세일즈의 클로징이 아니다. 핵심은 책임을 어디까지 지느냐다. 내 산출물까지가 책임이고 "내 할 일은 끝났다"고 생각하는 사람이 Maker다. 거기서 더 나아가 이 산출물이 정말 성과로 이어지는지 평가하고 그 결과까지 책임지는 사람이 Closer다. Output(산출물)에서 멈추느냐, Outcome(성과)까지 가느냐. 그 차이다.

행동으로 말하면 이렇다. Closer는 "이 방향이 틀렸다"고 멈출 수 있는 사람이다. 아웃풋이 아무리 훌륭해도, 그것이 고객 성과로 이어지지 않는다고 판단하면 방향을 꺾는다. 산출을 멈추는 결정은 Maker에게는 할 수 없는 일이다.

직업적 커리어에서 Maker가 더 인정받는 경향이 있다. 하지만 비즈니스를 지탱하는 건 Closer다.

산출이 늘면 성과도 따라오면 좋겠지만, 현실은 그렇지 않은 경우가 많다. 아웃풋을 열심히 쌓아도 목적 달성이 잘못된 방향으로 가면 그 모든 아웃풋이 쓸모없어진다. 반대로, 아웃풋이 조금 모자라도 어떻게든 방향을 꺾어 목적을 달성해내는 Closer도 있다. 개발 제품이 부족해도 비즈니스 성과를 내거나, 개발 제품이 훌륭해도 비즈니스가 망하는 케이스는 흔하게 봐왔을 것이다.

5, 6년 전 초기 스타트업 기술 컨설팅을 할 때 많은 조직을 만날 기회가 있었다. 제대로 된 개발자 — 전공자는커녕 부트캠프 출신이라도 — 가 한 명도 없는 조직에서, 대표가 스스로 학습하고 말도 안 되는 형태로 코드를 작성하고, 그걸로 대규모 후속 투자까지 끌어내며 고객 성장을 만들어내는 회사도 봤다. 그 대표는 Maker로서는 형편없었지만 Closer로서는 최고였다. 반면, 정말 천재라고 불릴 만한 백그라운드와 경험을 가진 개발자들이 본인들의 기술에 빠져 소위 "어른의 세계"를 외면하는 모습도 많이 봤다. 완벽한 Maker였지만, Closer는 아니었다.

개발 조직은 대부분 Maker를 지향했다. 디자이너와 PM들도 — 본래 Closer여야 할 사람들인데 — 축소된 권한과 경직된 조직 체계 안에서 결국 Maker의 일을 하고 있었다. Closer가 될 수 없는 구조가 Closer를 만들지 못한 것이다.

당신은 Maker인가, Closer인가

지금 자신의 지난 한 주를 돌아보자. 내가 직접 산출한 것은 무엇인가. 그리고 내가 최종 결정을 내린 것은 무엇인가. 기획서를 쓰고, 코드를 짜고, 보고서를 만드는 데 대부분의 시간을 썼다면 당신은 Maker다. 방향을 결정하고, 우선순위를 판단하고, 결과에 책임을 졌다면 Closer에 가깝다.

Maker가 나쁘다는 게 아니다. 지금까지는 Maker가 조직의 엔진이었다. 하지만 AI가 산출을 대신하기 시작하면, Maker의 가치는 점점 줄어든다. 코드를 짜는 건 AI가 하고, 문서를 만드는 건 AI가 하고, 데이터를 분석하는 것도 AI가 한다. 그때 남는 것은 "무엇을 만들어야 하는가"와 "이것이 정말 고객에게 가치가 있는가"를 판단하는 능력이다.

AX 시대의 커리어 방향

AX가 진행될수록 Maker의 역할은 점점 AI에게 위임될 것이다. 코드를 짜고, 문서를 작성하고, 디자인을 만들고, 데이터를 분석하는 것 — 산출 행위 자체가 AI의 영역으로 넘어간다. 많은 경우에 Closer의 역할이 극대화될 것이고, 완전히 AI Native한 조직 내에서 그들의 의사결정만이 유일한 병목이 될 것이다.

대부분의 직장인 입장에서, AI Native 조직에서는 개인의 커리어가 Maker의 방향이 아니라 Closer의 방향으로 전환되어야 한다. 그렇게 본인의 커리어를 전환한 사람들이 결국 AI 시대에도 살아남는 인재가 될 것이다. 두 분야에 깊은 전문성을 가지면서 end-to-end로 전체 사이클을 운영할 수 있는 사람 — 이게 흔히 말하는 π형 인재다. AI가 산출을 대신해주니까 한 사람의 커버리지가 넓어질 수 있고, 그래서 π형 인재가 비로소 현실적으로 가능해진 시대다.

7. 국내 조직의 AX — 왜 아직 움직이지 않는가

여기까지 읽으면서 "그래, 해외 사례는 알겠는데 우리 현실은 다르잖아"라고 생각했을 수 있다. 맞다. 국내 상황은 다르다. 하지만 다르다는 게 안전하다는 뜻은 아니다.

국내에서는 AI 시대임에도 사람들이 일자리를 쉽게 잃지 않는다. 관행을 버리고 새로운 조직 체계를 만드는 건 시간이 꽤 걸리는 일이기 때문이다.

하지만 OpenClaw든 Claude Code든 전사 도입했다고 해도, 국내 대부분 기업은 AI가 들어와도 마케팅팀은 마케팅팀이고 개발팀은 개발팀이다. 생산성이 어마어마하게 올랐다고 말하지만, 그건 Maker의 생산성이지 Closer의 최종 성과 — 매출이나 비즈니스 KPI — 에 반영되었는지는 별개의 질문이다.

2장에서 언급한 국내 SaaS 스타트업의 사례를 다시 보자. 전사 도입은 성공적이었다. 그렇다면 6개월 뒤, 그 조직은 어떻게 달라졌을까?

개발팀은 Claude Code로 코드를 더 빨리 짜고 있다. 마케팅팀은 ChatGPT로 콘텐츠를 더 빨리 만들고 있다. CS팀은 AI로 고객 문의를 더 빨리 분류하고 있다. 모두 더 빨라졌다. 하지만 개발팀과 마케팅팀 사이의 캠페인 기획 프로세스는 여전히 기획서 → 승인 → 전달 → 구현의 직렬 핸드오프다. CS에서 올라온 고객 피드백이 제품 로드맵에 반영되려면 여전히 PM → 리드 → 스프린트 계획 회의를 거쳐야 한다. AI가 들어왔는데, 일이 흘러가는 방식은 도입 전과 똑같다.

각 부서가 자기 업무를 더 효율적으로 수행하게 된 건 맞다. 하지만 부서 사이의 벽은 그대로다. 오히려 각 부서가 자기만의 AI 도구를 최적화하면서 부서별 AI 섬이 생겼다. 3장에서 말한 고속 사일로화가 정확히 이 모습이다.

왜 국내 조직은 아직 이 질문을 시작하지 않았을까? 몇 가지 구조적 이유가 있다.

첫째, 기능 조직이 너무 깊게 뿌리내렸다. 국내 IT 기업 대부분은 마케팅부, 개발부, 기획부라는 구분이 조직도의 뼈대다. 이 뼈대를 바꾸려면 임원진 전체가 동의해야 하는데, 기능 조직에서 임원이 된 사람들이 기능 조직을 해체하자고 말하기는 어렵다.

둘째, 성과 측정 체계가 산출 중심이다. 개발자는 배포 건수, 마케터는 캠페인 수, PM은 기획서 건수로 평가받는다. 이 구조에서 "당신은 이제 고객 성과로 평가됩니다"라고 바꾸려면 평가 시스템 자체를 뜯어고쳐야 한다.

셋째, 학습과 성장이 장려되지 않는 조직문화가 변화를 가로막는다. 새로운 역할로 전환하려면 학습이 필요한데, 그 학습을 장려하고 지원하는 기업이 얼마나 되는가. 대부분의 조직은 현재 업무를 소화하는 것만으로도 벅차다.

이런 환경에서 대부분의 조직은 게으르게 흘러갈 수밖에 없다. 솔직히, 내가 담당자라도 OpenClaw 도입하고 "AX 했다"고 홍보하는 게 편하지, 사람부터 조직까지 뜯어고쳐야 하는 고민은 현실에 치여서 하지 않을 것이다.

하지만 새로운 기업들이 소위 AI Native한 조직 체계를 가지고 성장했을 때, 기존의 기업들이 그 속도를 따라갈 수 있을까? 국내에서 아직 AI 때문에 대규모 해고가 체감되지 않는다고 해서 안전한 것은 아니다. 충격이 늦게 올 뿐이다.

모든 조직이 지금 당장 5축 전부를 바꿔야 하는 건 아니다. 10명짜리 스타트업이라면 이미 목적 단위 팀에 가깝고, 핸드오프가 적다. AX 전환이 절실한 건 기능 조직이 고착화된 중견 이상의 회사들이다. 하지만 규모가 작은 조직이라도 한 가지는 점검해야 한다 — 지금 깔고 있는 AI 도구가 기존 구조를 강화하고 있는지, 아니면 새로운 구조를 가능하게 하고 있는지.

결국 AI 기술 발전은 우리가 일하는 방식을 궁극적으로 바꾸게 될 것이다. 바뀌지 않는 조직 안에서 바뀌지 않는 개인은, 바뀐 조직의 바뀐 개인에게 추월당할 뿐이다.

8. 나가며 — 도구는 시작을 만든다. 전환은 구조가 만든다.

AI를 전사에 심는 것은 좋은 시작이다. 그 시작을 만들어낸 사람들에게 진심으로 박수를 보낸다.

하지만 시작을 완성이라 부르면 다음 단계가 사라진다.

진짜 AX는 기존 기능 조직 위에 AI를 얹는 게 아니다. 역할을 재정의하고, 파이프라인을 재설계하고, KPI를 바꾸고, 거버넌스를 세우고, 리소스를 재배치하는 일이다. 인간-에이전트 혼합 운영 체계로 조직을 다시 짜는 일이다. 그래서 AX의 주체는 개발자가 아니라 경영자다.

그리고 개인의 커리어는 Maker에서 Closer로 전환되어야 한다. AI가 잠식하는 것은 산출 그 자체이고, 인간에게 더 오래 남는 것은 성과 책임과 방향 결정이다.

나 역시 오랫동안 Maker였다. 코드를 잘 짜면 비즈니스도 따라올 거라고 믿었던 시절이 있다. 지금은 안다. 좋은 산출물은 필요조건이지 충분조건이 아니라는 것을. 방향이 맞아야 산출이 의미를 갖는다. 그 방향을 정하는 게 Closer의 일이다.

조직에 Claude Code를 설치한다고 AX가 되는 게 아니다. AX는 조직도를 다시 그리는 순간부터 시작된다.

References

Bain & Company, "Unsticking Your AI Transformation"
McKinsey & Company, "AI in the Workplace: Empowering People to Unlock AI's Full Potential"
BCG, "Companies Must Go Beyond AI Adoption to Realize Its Full Potential"
BCG, "Five Things Boards Need to Get Right with AI"
Harvard Business Review, "Don't Let AI Reinforce Organizational Silos"
The Verge, "Shopify CEO says no new hires without proof AI can't do the job"
The Pragmatic Engineer, "How Uber Uses AI for Development"
Business Insider, "Andrew Ng: Product Management Is the New Bottleneck"
Computer Weekly, "DBS Rewires Operating Models for AI Reasoning Era"
Morgan Stanley, "Launch of AI @ Morgan Stanley Debrief"
Moderna, "Our Journey to Becoming a Real-Time AI Organization"
Reuters, "Sweden's Klarna shifts AI focus from cost cuts to growth"
AP News, "McDonald's ends test run of AI-powered drive-thrus with IBM"
Reuters, "Duolingo raises 2025 forecast"
Wall Street Journal, "Johnson & Johnson Pivots Its AI Strategy"
Atlassian, "Team Update March 2026"
OpenAI, "BBVA: Scaling AI Across 120,000 Employees"
Box, "AI-First: Building the Future of Intelligent Content Management"
METR, "Measuring the Impact of AI on Experienced Open-Source Developer Productivity"
r/cursor, "Do you believe the claims that AI isn't improving programmer productivity?"
r/ExperiencedDevs, "Did AI increase productivity in your company?"
r/ExperiencedDevs, "AI is working great for my team, and y'all are making me feel crazy"

작동하는 기능과 믿을 수 있는 제품 사이 — ToC 인식 개발기

Tony Cho (https://flowkater.io) — Fri, 13 Mar 2026 07:00:00 GMT

작동하는 기능과 믿을 수 있는 제품 사이 — ToC 인식 개발기

들어가며

모바일 앱을 만들다 보면 가장 큰 저항은 결국 입력이다. 특히 콘텐츠 소비가 주목적인 앱이 아닌 기능성 앱이라면, 카테고리를 막론하고 유저의 입력 마찰이 이탈의 첫 번째 원인이 된다. 가계부 앱이라면 소비 내역 입력, 생산성 앱이라면 시간 설정과 할 일 추가 — 전부 입력이다. AI 시대가 되어 모델 성능이 대폭 올라갔지만, 유저 맞춤 데이터는 결국 유저가 입력해야 한다.

하지만 B2C 모바일 앱은 그런 유저 데이터를 알 리 만무하고, 우리가 만드는 입장에서 구글이나 메타 같은 개인 데이터를 보유할 수도 없다. 결국 AI 시대에도 모바일 앱은 UX에서 edge를 가져야 하며, 유저 맞춤 데이터를 가장 적은 마찰로 정확하게 수집하는 문제는 아직 풀리지 않았다.

목차(ToC)를 직접 입력(타이핑)하게 하는 순간 이 기능은 실패한다

이 문제를 풀려고 한 건 5년 전이다. 현재 재개발 중인 서비스의 두 번째 버전이었다. (지금은 세 번째 버전이다.) 유저에게 맞춤형 계획을 제공하기 위해, 유저가 보려고 하는 책 또는 교재의 목차 데이터(이하 ToC)가 필요했다. 페이지 등의 분량으로도 비슷하게 기능을 제공하고 있었지만, 고도화를 위해서는 책의 ToC가 필요했다. 상식적으로 생각해도 책의 목차를 직접 입력하게 하는 행위는 — 심지어 모바일에서 — 바로 유저 이탈로 이어질 게 뻔하다.

사전 ToC 수집 (feat. QWEN)

제일 먼저 생각한 건 사전 ToC DB 수집이었다. 이번 글에서 다룰 작업 이전에 많은 시간을 들여 작업을 했는데, 국내 도서 사이트와 달리 해외, 특히 영미권 도서 사이트(우리 앱의 현재 1차 타겟은 영미권이다)는 ToC를 애초에 제공하지 않는 곳이 대부분이다. (물론 국내 도서 API도 ToC를 제공해주는 API는 없다.) 또한 특정 출판사에 종속되어 있는 게 아니기 때문에, 일반적인 수집기를 API 기반으로 쉽게 만드는 방법은 존재하지 않았다.

두 번째 카드로 꺼낸 게 AI였다. 그 AI가 이 글의 주인공이 될 Qwen 3.5 Flash였다. 그 모델을 기반으로 광범위한 ToC 수집 파이프라인을 만들었다. (모델 소개는 뒤에서 다시 한다.)

qwen.ai에서 몇 개 기준이 되는 책을 검색해보고, 생각보다 수집이 잘 되는 것을 발견하고 직접 LLM API를 기반으로 개발을 진행했다. 처음엔 OpenRouter를 사용했다. 가격도 비슷하고 다른 모델 호환성도 있다 보니 진행을 했는데, OpenRouter에서 제공하는 Qwen 모델은 말 그대로 바닐라 모델이고 그 외의 툴체인 옵션들이 제공되지 않았다. (바닐라 모델 결과는 처참했다.) 결국 AlibabaCloud로 옮겨 DashScope으로 다시 API를 연결했다. DashScope에는 Qwen 모델의 web_search와 web_extract 툴체인이 모두 갖춰져 있었고, 해당 기능을 기준으로 꽤 정확하게 데이터를 수집하는 파이프라인을 만들 수 있었다.

ISBN13을 입력하면 관련 메타데이터와 ToC를 자동으로 수집하는 파이프라인을 만들었다. 테스트 케이스에 있던 7권짜리 묶음 책 같은 경우에는 ToC를 모두 가져오면 한 번에 가져올 수 있는 토큰이 초과하기 때문에, 큰 기준으로 챕터를 수집하고 이걸 세부 챕터 수집으로 한 번 더 진행하는 방식으로 처리했다. 테스트 케이스가 많지는 않았지만, 다양한 분야의 책에서 대량의 ToC 데이터를 정확하게 수집하는 파이프라인이 동작하기 시작했다.

ISBN13을 입력하면 depth가 포함된 ToC를 JSON으로 뽑아내는 수집기를 만들게 되었다. 간단히 설명했지만, LLM 모델 자체의 비결정성 때문에 여러 가드레일이 필요했고 파이프라인을 구축하는 데 2, 3일은 꼬박 밤을 새면서 만들었던 것 같다.

하지만 해당 프로젝트를 실제 데이터 수집까지 연결하지 못했다. 가장 큰 문제는 비용이었다. 테스트 과정에서만 쓴 비용이 2000달러가 넘는다. 이건 Qwen 3.5 Flash의 저렴한 토큰 값과 별개로 web_search 툴 콜링 비용 때문이다. Qwen의 web_search 툴 콜링에는 자체 compact 기능이 없기 때문에 web_search를 하면서 들어가는 비용이 족족 토큰 비용으로 계산된다. 토큰 비용만 생각하고 모델을 채택했지, 그 외 툴체인이나 사이드 이펙트 비용은 전혀 생각하지 않았기 때문에 적잖이 당황했다.

사용자가 어떤 책을 입력할지는 모르기 때문에 최대한 많은 책을 수집해야 했고, 프로덕션 퀄리티로 사용하려면 주기적으로 검증 파이프라인도 필요하다. 비용이 몇 배가 될지 모른다. 수집해야 하는 데이터는 무한한데 (물론 롱테일이겠지만 니치 데이터가 없으면 해당 유저는 바로 이탈한다) 수집 비용은 어마어마하다. Codex로 전체 검증 테스트를 돌려놓고 자고 일어났더니 한화 300만 원 청구서가 기다리고 있었다. 솔직히 멘붕이었다.

그 뒤로 포기하지 않고 구독 모델인 Codex나 Claude Code에서 자체 스킬을 만들어서 시도했지만, API 모델이 아니라서 그런지 Qwen과는 비교도 안 될 뛰어난 모델 성능에도 불구하고 결과는 좋지 않았다. Qwen의 툴체인에 비해 클라이언트 위주(Playwright 등)의 스킬이나 플러그인의 한계로 web_search를 따라가지 못했다. GPT-5.3-Codex-Spark 모델에 Playwright 스킬을 붙여서 돌렸을 때는 Chrome이 메모리를 다 먹어버리면서, M4 Max CTO 맥북이 처음으로 먹통이 됐다.

이 실패는 단순한 기술 실패가 아니었다. 운영 비용과 데이터 커버리지를 동시에 고려하지 않으면 어떤 기술도 제품이 될 수 없다는 첫 번째 교훈이었다. 3일의 삽질, 2000달러의 비용(하필 환율 오른 시기에 청구되어 300만 원), 이렇게 사전 DB를 구축해도 니치한 유저 맞춤 ToC는 여전히 사각지대라는 여러 가지 이유가 겹쳐 해당 프로젝트를 중단했다.

사용자가 직접 ToC 인식

결국 사용자가 입력하게 한다

꽤 많은 비용을 치르고 결국 원점으로 돌아왔다. "사용자가 입력한다." 차선책이었지만 나쁘지 않은 결정이다. 당연히 유저가 모든 목차를 직접 입력하는 건 말도 안 된다. OCR 기능도 좋아졌기 때문에 그냥 유저가 사진을 찍으면 된다. 유저 본인만의 데이터가 되는 건 덤이다.

문제는 텍스트 입력이 아니라 구조 입력이었다. 목차 구조는 텍스트 리스트가 아닌 depth level을 가진 일종의 그래프 노드이다. 사진을 찍는다고 iOS VisionKit이 구조까지 인식해주지는 않는다. 예전 OCR 모델들에 비해 텍스트 인식 자체는 뛰어났고, 심지어 어느 정도 구조화된 문서도 인식했다. 하지만 그 "어느 정도"가 유저에게 최악의 경험을 제공했다.

LLM 이전에는 왜 안 됐나

앞서 말했듯이, 이 문제를 처음 시도한 건 아니었다. OCR + 정규화는 5년 전 그때에도 여러 가지 방법으로 시도했다. 당시 OCR 라이브러리나 서비스로도 flat list 추출 정도는 가능했다. 하지만 실제 필요한 건:

Part / Chapter / Section (depth가 더 있을 수도 있고)
depth
page
계층 관계

이다. 단순히 텍스트 덩어리가 아니라 위계 구조였다.

당시에도 언어 모델을 이용해서 분류 체계를 만들려고 노력했다. 지금과 비교하면 당시에는 언어 모델의 태동 시기였다. 막 트랜스포머, attention 개념이 제품에 적용되던 시기라서 GCP에서 제공하는 ML 플랫폼을 이용해 목차 데이터를 최대한 많이 수집해서 언어 모델을 만들려고 시도했었다. 언어 모델에게 Flat List의 ToC를 입력하면 각 아이템의 고유 패턴을 학습해, 텍스트 리스트를 던지면 구조가 반환되도록 학습시키려 했다. 하지만 이미 Flat List로 변환된 텍스트에서 해당 모델이 추론을 해도, 케이스의 다양함이나 데이터의 부족으로 문제를 전혀 해결할 수 없었다.

줄바꿈, 들여쓰기, 번호 체계, 로마자/숫자 혼용 같은 구조 신호들이 OCR을 거치는 순간 모두 뭉개졌고, 페이지 번호까지 매칭해야 하는 추가 요구사항은 아예 시도조차 하지 못했다.

ToC 인식의 문제는 OCR 텍스트 인식률이 아니라 구조화였다. 글자를 읽는 것이 아닌 글자 사이의 위계를 읽는 것. 또한 혼자서 해당 문제를 풀기에는 비용 대비 ROI가 나오지 않는 아주 비효율적인 작업이었다.

왜 지금 가능해졌나

GPT, Claude, Gemini 등 메이저 모델들의 성능이 어마어마하게 발전했다. 하지만 여전히 AI를 제대로 활용하는 서비스가 나오기 어려운 이유는 API 비용 때문일 것이다. 200달러짜리 GPT Pro 모델을 구독하고 있지만, 현재 Codex를 사용하는 토큰을 API 종량제로 사용했다면 아마 몇천 달러 청구서를 구경했을 것이다.

요즘 다들 간과하는 게 있다. 현재 사용 모델이 항상 SOTA 기준이다 보니 "에이전틱 엔지니어링이 중요하다, 프롬프트 엔지니어링은 중요하지 않다"라고 말하지만, 상용 서비스에 LLM API를 연동하고 비즈니스 ROI까지 맞추려면 절대 SOTA 모델을 사용할 수 없다. 최소 한 세대, 많이는 두 세대 전 API 모델을 사용할 수밖에 없다. 지금 이 모든 건 비용 문제다.

2026년 2월 23일에 Alibaba Cloud에서 Qwen 3.5를 발표했다. 그중에 Qwen 3.5 Flash 모델이 공개되었는데, Pro 모델이 보통 Claude Sonnet과 비교되는 모델이고 Flash는 그것보다 훨씬 하위의 모델이다. 멀티턴에서 성능이 급격하게 떨어지고 예전 세대 모델들처럼 단일 요청에 대한 답을 잘한다. 하지만 앞서 언급했던 web_search, web_extract 외에도 Vision 모델도 같이 이식되어서, 단순 작업에 있어서는 굉장히 빠르고 정확하며 API 비용은 경쟁 모델 대비 압도적으로 저렴하다. (중국발 모델은 개인정보 우려가 있지만, Qwen은 로컬 오픈소스 모델도 별도로 제공하고 있다.)

왜 Qwen 3.5 Flash였는가

아래는 각사의 경량(Flash/mini/nano) 라인 모델끼리의 비교다. 같은 급에서 비교하는 게 공정하기 때문이다. (2026년 2월 기준 공식 가격)

	Claude Haiku 4.5	GPT-5-nano	Gemini 3 Flash	Qwen 3.5 Flash
라인업 급	경량 (Haiku)	경량 (nano)	경량 (Flash)	경량 (Flash)
Input (per 1M tokens)	$1.00	$0.05	$0.50	$0.10
Output (per 1M tokens)	$5.00	$0.40	$3.00	$0.40
비전 (이미지 인식)	우수	우수	우수	충분
구조화 JSON 출력	우수	좋음	우수	충분 (단일 요청 기준)
속도	빠름	매우 빠름	빠름	매우 빠름
멀티턴 성능	좋음	보통	좋음	급격히 떨어짐

표만 보면 GPT-5-nano가 Input 단가에서 Qwen보다 유리하다. 하지만 실제 운영 비용은 Input 단가만으로 결정되지 않는다. 구조화 JSON 출력의 품질이 낮으면 재시도, 후처리, 다른 모델로의 fallback 호출이 늘어나고, 이게 곧 숨은 비용으로 누적된다. 이번 과제에서 GPT-5-nano는 구조화 출력이 “좋음” 수준에 머문 반면, Qwen 3.5 Flash는 “단일 요청 기준으로 실제 프로덕션 테스트를 통과할 정도”의 안정적인 구조화를 보여줬다. 멀티턴을 전제로 한 복잡한 대화가 아니라, “이미지를 한 번 보내고, 구조화된 JSON을 한 번에 받는” 단일 요청 패턴이 핵심이었기 때문에 이 차이가 결정적이었다.

ToC 인식 과제의 워크플로도 멀티턴을 요구하지 않는다. 사용자가 책이나 교재 사진을 찍으면, 시스템은 그 이미지를 한 번에 받아 ToC 구조를 JSON으로 뽑아내기만 하면 된다. 이 시나리오에서는 멀티턴 추론 능력보다 “비전+구조화 출력” 한 방의 신뢰도가 훨씬 중요하다. Qwen 3.5 Flash는 이 단일 요청 + 구조화 출력 조합에서 같은 급 모델들 대비 충분히 만족스러운 결과를 냈고, 이게 선택의 핵심 근거가 됐다. (모든 작업에서 Qwen Flash가 최고라는 뜻이 아니라, 이 특정 과제에 잘 맞았다는 의미다.)

속도도 빼놓을 수 없다. 사용자가 카메라로 책 페이지를 찍어 올리고 결과를 기다리는 상황에서, 응답 시간은 곧 UX다. 동일한 이미지를 보냈을 때 Haiku 4.5는 대략 10~15초 정도가 걸렸고, Qwen 3.5 Flash는 5~8초 안에 응답이 돌아왔다. 체감상 두 배 가까운 차이다. 비용 측면에서도 Qwen Flash는 경량급 모델 중에서 여전히 저렴한 축에 속한다. 이 과제의 요구사항(경량, 저렴, 빠름, 단일 요청 구조화)에 맞춰 보면, Flash를 쓰지 않을 이유를 찾기가 더 어려웠다.

남은 걱정은 OCR/비전 품질이었다. 솔직히 처음에는 Flash급 비전이 실제 책 사진 — 조명 불균일, 곡면 왜곡, 작은 글씨 — 을 제대로 처리할 수 있을지 의문이었다. 실제 테스트 결과, 텍스트 인식률 자체는 충분히 실용적이었다. 문제는 인식률보다 “어떻게 구조화해서 내보내느냐”에 가까웠고, 이 부분은 프롬프트 설계와 후처리 파이프라인으로 보완해야 할 영역이었다. 모델이 80점을 내면, 나머지 20점은 엔지니어링으로 채우면 된다. (이 문장이 이 글 전체의 주제이기도 하다.)

왜 DashScope였는가

OpenRouter로 먼저 붙였다. 같은 모델인데 결과가 처참했다. 알고 보니 DashScope 네이티브로 쓰는 것과 아예 다른 물건이었다. 바닐라 모델로 같은 프롬프트를 던지면 쓸 수 없는 수준인데, DashScope에서는 web_search, web_extract, Vision까지 네이티브 툴체인이 전부 붙어 있었다. 같은 모델인데 플랫폼 차이가 이 정도라는 게 충격이었다. 수집기 때도 이 차이가 결정적이었고, 인식 파이프라인에서도 마찬가지였다.

비용 예측도 중요했다. DashScope은 리전별 가격 정책이 명확하고, Free Quota도 제공한다. 상용 서비스에 LLM API를 연동할 때 가장 무서운 건 "이번 달 청구서가 얼마일지 모른다"는 거다. DashScope은 그 불확실성이 적었다. Singapore 리전에서 최신 모델을 바로 쓸 수 있어서 운영 비용 예측이 가능했다.

운영 안정성도 따졌다. Alibaba Cloud는 인프라 기업이고 DashScope은 그 위에 올라간 서비스라서, 최소한 API가 갑자기 사라질 걱정은 덜했다. 프록시 레이어가 하나 더 들어가면 그만큼 장애 포인트도 늘어난다. 이미 수집기 때 OpenRouter → DashScope 마이그레이션을 한 번 겪었기 때문에 처음부터 DashScope으로 갔다.

LLM API 모델 연동을 고려하고 있다면 테스트해보면 좋다. 미국발 SOTA 모델 외에도 Kimi, Qwen, GLM 같은 중국발 모델도 써볼 만하다. 같은 모델이라도 어떤 플랫폼에서 쓰느냐에 따라 결과가 완전히 달라진다는 건 직접 겪어봐야 안다.

작동하는 기능에서 믿을 수 있는 제품까지 (개발기)

아래부터는 실제 개발 흐름이다. 기술 디테일을 모두 따라가지 않아도 괜찮다. 하지만 "왜 이렇게까지 복잡해야 했는가"의 감각은 가져갔으면 한다. 내가 정말 전하고 싶은 건 기술 디테일 자체가 아니라, "작동한다"에서 "믿을 수 있다"까지의 거리가 얼마나 먼지에 대한 이야기다.

Do Work — 일단 동기 API로 붙여봤다

일단 파싱은 된다.

좋은 구조를 처음부터 완성한 게 아니다. 먼저 작동하는 버전을 만들었다.

가장 단순한 흐름부터 시작했다. iOS에서 사진을 찍으면 이미지를 서버로 올리고, 서버는 DashScope API에 이미지를 보내고, 동기 응답으로 JSON을 받아서 다시 iOS로 내려주는 구조다. 프롬프트에는 bookTitle과 totalPages를 힌트로 넣었다. 책 제목을 알려주면 모델이 맥락을 더 잘 잡고, 전체 페이지 수를 알려주면 페이지 번호 추론이 정확해진다. 이런 작은 힌트 하나가 결과 품질에 생각보다 큰 영향을 줬다.

처음 테스트를 돌렸을 때의 느낌을 아직 기억한다. 사진 한 장을 보내고 돌아온 JSON을 봤는데 — Chapter, Section, depth, startPage가 꽤 정확하게 잡혀 있었다. "이거 되는데?" 하는 확신을 얻는 순간이었다. 사전 수집 파이프라인에서 2000달러를 태우고 나서 만난 이 순간은 꽤 감격스러웠다.

다중 이미지가 의외로 중요했다

처음엔 "사진 한 장 찍으면 되겠지" 싶었다. 하지만 실제 책 목차를 열어보면 한 장에 안 끝나는 경우가 훨씬 많다. 특히 전문 서적이나 교재는 목차만 5~6페이지(테스트 했던 책 하나는 10페이지였다)에 걸쳐 있다. multi-image 파싱은 있으면 좋은 게 아니라, 없으면 실제 사용이 불가능한 기능이었다.

문제는 여러 이미지의 파싱 결과를 하나로 합치는 게 단순 concat이 아니라는 거다.

첫째, 이미지 순서를 보존해야 한다. 사용자가 1페이지부터 찍었다는 보장이 없다.

둘째, 챕터 merge가 필요하다. 이미지 A의 마지막 챕터와 이미지 B의 첫 챕터가 같은 챕터일 수 있다. Chapter 3이 첫 번째 사진의 끝에서 시작되고 두 번째 사진에서 하위 섹션이 계속되는 경우다. 이걸 중복으로 처리하면 챕터가 두 개가 되고, 무시하면 섹션이 날아간다.

셋째, 중복 dedupe와 startPage 기반 정렬이다. 같은 챕터가 여러 이미지에서 등장할 수 있고, 페이지 번호가 겹칠 수 있다.

넷째, warning 처리다. 모델이 보낸 이미지가 목차가 아니라고 판단하면 not_toc를 반환해야 하고, 챕터 수가 비정상적으로 적으면 too_few_chapters 경고를 내야 하고, 페이지 순서를 강제 조정했으면 page_order_adjusted를 알려줘야 한다. 이런 warning 없이 조용히 결과만 주면 사용자가 잘못된 데이터를 그대로 쓰게 된다.

multi-image가 들어가면서 prompt 설계, merge 로직, dedupe 규칙, 정렬 알고리즘, warning 체계 — 전부 한 단계씩 복잡해졌다. "한 장 찍으면 되겠지"가 얼마나 순진한 생각이었는지 깨닫는 데는 오래 걸리지 않았다.

Do work, 하지만 제품은 아니었다

기능은 동작했다. 이미지 3장을 보내면 merge된 ToC JSON이 돌아왔다. 정확도도 나쁘지 않았다. 하지만 치명적인 문제가 있었다. 이미지 3장을 보내면 모델 응답까지 수십 초가 걸린다. 그동안 HTTP 커넥션은 열려 있고, 서버 워커 하나가 묶여 있고, 유저는 빈 화면을 보고 있다.

더 심각한 건 타임아웃이다. 모바일 환경에서 30초 넘게 HTTP 커넥션을 들고 있으면 네트워크 상태에 따라 연결이 끊긴다. 끊기면? 처음부터 다시. 모델 호출 비용은 이미 발생했는데 결과는 사라졌다.

이건 기능이지 제품이 아니다. 데모에서는 "오 대박" 할 수 있지만, 실제 유저에게 제공하면 한 번 쓰고 다시 안 쓴다.

Good — 비동기 parse-job으로 분리했더니 그제야 제품 비슷해졌다

기다릴 수 있는 기능이 된다.

동기 요청은 서버도 답답하고 사용자도 답답했다. 모델 호출 시간을 줄일 수는 없다. 그렇다면 기다리는 방식을 바꿔야 한다.

작업 시스템으로의 진화

parse-jobs 비동기 모델로 전환했다. 흐름은 이렇다:

클라이언트가 이미지를 업로드하고 파싱을 요청한다
서버는 즉시 job을 생성하고 jobId를 반환한다 (여기까지 1초 이내)
실제 파싱은 백그라운드 worker가 처리한다
클라이언트는 jobId로 상태를 주기적으로 조회한다 (polling)

이 전환만으로도 사용자 경험이 확 달라졌다. 요청을 보내면 즉시 "접수됨" 상태를 받고, 앱은 "처리 중" UI를 보여줄 수 있다. 기능이 "모델 호출"에서 "작업 시스템"으로 진화한 순간이다.

중복 실행 방지 — 단순 비동기화가 아니다

비동기화만 한 게 아니었다. 같은 이미지 세트로 이미 파싱이 진행 중이거나 완료된 job이 있다면 새로 만들지 않고 기존 job을 재사용했다.

사용자가 같은 사진을 실수로 두 번 보낸다 → 모델 호출 비용이 2배
네트워크 이슈로 앱이 재시도한다 → 동일한 job이 2개 생긴다
사용자가 "아까 그 결과"를 다시 보고 싶어한다 → 이미 있는 결과를 찾아서 주면 된다

신규든 재사용이든 클라이언트에는 동일하게 200을 반환하되, reused 여부를 명시했다. 클라이언트는 "200이 왔으니 jobId를 들고 상태를 조회하면 된다"만 알면 된다. (디버깅할 때는 필요하니까 표시는 해둔다.)

이건 비용과 직결되는 결정이다. LLM API 호출은 공짜가 아니다. 중복 방지 없이 운영하면 비용이 예측 불가능해진다.

실패 계약 — 잘 될 때만 잘 되면 되는 게 아니다

iOS 쪽에서도 단순히 "성공하면 보여준다"로 끝나지 않았다. 실패 계약을 명확히 해야 했다.

HTTP 200이 아니면 로컬 폴백으로 전환한다. 서버가 죽어도 앱이 동작해야 한다. 사용자에게 "서버 에러입니다"를 보여주는 건 최악이다. 차라리 "자동 인식에 실패했으니 직접 입력하세요"라고 대안을 주는 게 낫다. (물론 직접 입력은 최악의 UX지만, 에러 메시지만 보여주는 것보다는 낫다.)

다행히도 Apple VisionKit이라는 로컬 MLKit이 있었기 때문에 직접 입력보다는 그나마 나은 경험을 제공해준다. (물론 구조화는 안된다.)

백엔드는 "잘 될 때만 잘 되면 되는" 서비스가 아니다. 실패했을 때 클라이언트가 어떻게 반응할지까지 합의해야 한다. 이건 API 스펙이 아니라 제품 계약이다.

Good, 하지만 아직은 부족했다

Do work가 "돌아가는 기능"이었다면, Good은 "기다릴 수 있는 기능"이 되는 단계였다. 하지만 여전히 유저는 기다리는 동안 아무것도 보지 못했다. 언제 끝나는지도 모른다. polling으로 "아직 처리 중"만 보여주는 건 2026년에 유저에게 제공할 경험이 아니었다.

"이 정도면 괜찮지" 하고 멈출 수도 있었다. 사실 많은 서비스들이 여기서 멈춘다. 하지만 유저가 기다리는 그 시간을 어떻게 만들 것인가. 그게 Good과 Great의 차이라고 생각했다.

Great — 실시간 경험, 부하 분산, 운영 리스크까지 감당하면서 비로소 프로덕션이 됐다

믿고 쓸 수 있는 제품 경험이 된다.

SSE를 붙이면서 기능이 아니라 경험이 됐다

polling의 한계는 명확했다. 유저는 "지금 어디까지 됐는지" 모른다. polling 주기를 짧게 잡으면 서버 부하가 올라가고, 길게 잡으면 체감 지연이 커진다.

그래서 SSE(Server-Sent Events)를 도입했다. 클라이언트가 연결을 열어두면 서버가 이벤트를 실시간으로 밀어준다.

snapshot : 연결 시점의 현재 상태 전체
status : job 상태 변경 (queued → processing → completed/failed)
preview : 파싱이 진행되는 동안 점진적으로 인식된 목차 구조
heartbeat : 연결이 살아있다는 신호
usage : 토큰 사용량 등의 메타 정보
completed : 최종 결과 확정
failed : 실패와 에러 정보

사용자 경험에 가장 큰 영향을 준 건 preview였다. 모델이 목차를 인식해가는 과정을 실시간으로 보여주는 것이다. Chapter 1이 먼저 나타나고, Section 1.1이 그 아래 생기고, 다음 Chapter가 추가되는 — 마치 ChatGPT가 답변을 한 글자씩 스트리밍하는 것처럼, 목차가 점진적으로 완성되어가는 경험. 이게 붙는 순간 "기능"이 "경험"이 됐다. 기다리는 시간이 지루한 대기에서 기대감 있는 관찰로 바뀌었다.

처음엔 "나오는 대로 보여주면 되겠지" 싶을 만큼 단순해 보였다. 하지만 실제로 만들어보니 진짜 어려운 건 그 다음부터였다.

preview와 truth는 분리해야 했다

실시간으로 보여주는 것과, 믿고 저장하는 것은 다른 문제였다.

이걸 깨달은 건 preview를 그대로 final result로 사용하려다가 문제가 터졌을 때다. preview에는 nodeId도 없고, order도 없다. UI에서 보여주기에는 충분하지만, downstream — 계획 생성, checkItems 변환, 사용자 커스텀 — 에서 필요한 메타데이터가 빠져 있다.

그래서 원칙을 세웠다:

preview는 UI용이다. non-authoritative.
final result만이 truth다. DB에 저장되고, GET parse-jobs/{jobId} read path로만 접근한다.
preview와 worker queue stream은 분리한다.

preview를 truth로 취급하면, 아직 파싱이 끝나지 않은 불완전한 데이터로 계획이 생성될 수 있다. 이걸 구분하지 않으면? 사용자에게 "Chapter 3까지 인식됨"이라고 보여줬는데, 실제로는 5까지 있었으면 불완전한 계획을 받게 된다. 보여주는 것과 저장하는 것을 같은 채널로 처리하면 안 된다는 건 — 말하면 당연한데, 만들다 보면 놓치기 쉬운 부분이다.

진짜 어려웠던 건 SSE가 아니라 preview emit 정책이었다

SSE를 붙이는 것 자체는 어렵지 않다. 진짜 어려워진 건 그 다음이다. 얼마나 자주, 어떤 변화에서 preview를 내보낼지.

preview 하나를 보낼 때마다 두 가지 비용이 발생한다. latest preview cache에 저장하는 것과, event stream에 append하는 것. preview를 많이 보내면 UX는 화려하지만 서버에서는 write가 폭발한다. 반대로 적게 보내면 SSE를 붙인 의미가 없다. 처음에 빈 화면이고 한참 뒤에 갑자기 전체 결과가 뿅 나타나면 — 그게 polling이랑 뭐가 다른가.

특히 모바일 환경이 문제다. 지하철 타다가 끊기고, 와이파이에서 LTE로 전환되면서 끊기고. reconnect가 일어날 때마다 서버는 latest preview를 조회하고, 이전 이벤트를 replay한다. reconnect가 잦아질수록 서버 읽기 부하가 커진다. 실시간 지연보다 이게 더 큰 문제일 수 있었다.

결국 PreviewAssembler 레벨에 적응형 emit 정책을 넣었다:

throttle: 최소 emit 간격. 너무 자주 보내면 서버가 힘들다.
chapterThrottle: 챕터 단위 변화가 있을 때만 emit. 섹션 하나 추가된 건 보류.
maxSilence: 너무 오래 안 보내면 heartbeat 대용으로 preview를 하나 보냄. 사용자가 "멈춘 건 아닌지" 불안해하지 않도록.
fingerprint 비교: 이전 preview와 hash를 비교해서 실제 변화가 있을 때만 보냄. 모델이 같은 내용을 반복 출력하는 경우가 있기 때문.
pending preview 보류: emit 조건을 만족하지 않으면 보류, 다음 emit 시점에 최신 것만 보냄.

전략은 이중 구조다. incremental strategy로 최대한 싸게 처리하다가, 깨지면 whole replay fallback으로 안전하게 복구한다. 증분 처리가 가능한 동안은 비용을 아끼고, 상태가 꼬이면 전체를 다시 보내서 일관성을 보장한다.

실시간으로 보이는 건 화려했지만, 진짜 어려운 건 덜 보내면서도 더 좋아 보이게 만드는 것이었다. SSE의 품질은 연결 유무가 아니라, preview를 얼마나 신중하게 흘려보내느냐에 달려 있었다.

실시간 UX를 만들자 서버 설계가 다시 시작됐다

SSE는 예쁜 기술이 아니다. 대기와 부하를 다른 방식으로 관리하는 기술이다. SSE를 붙이면서 서버 아키텍처의 상당 부분을 다시 설계해야 했다.

worker queue와 SSE event stream의 분리. 처음에는 기존 worker queue의 Redis Stream을 SSE source로 재사용하려 했다. 하지만 이렇게 하면 worker의 처리 단위와 SSE의 emit 단위가 결합된다. worker가 빨라지면 SSE가 과도하게 emit하고, worker가 느려지면 SSE도 답답해진다. 이 둘은 독립적이어야 한다. 그래서 Redis event stream을 별도 key로 분리했다.

replay, reconnect, Last-Event-ID. 모바일 환경에서 reconnect는 예외가 아니라 정상이다. 재연결 시 Last-Event-ID를 보내면 서버는 그 이후의 이벤트만 replay한다. 이게 없으면? 끊길 때마다 사용자는 처음부터 다시 보게 된다. 아까 Do Work에서 겪었던 그 문제가 SSE 레이어에서 반복되는 거다.

Nginx 설정. proxy_buffering off, X-Accel-Buffering: no. 이걸 빼먹으면 Nginx가 SSE 이벤트를 몰래 모아뒀다가 한 번에 보낸다. "실시간"이라고 만들었는데 실제론 지연된 배치였다. 이런 걸 모르면 SSE를 붙인 의미가 없다.

graceful shutdown과 배포. shutdown timeout을 30초로 잡고, blue/green 전환으로 처리한다. 배포 중 목표는 "무중단"이 아니라 재연결 가능한 시스템이었다. 완벽한 무중단은 비용이 너무 크다. 끊어져도 복구되는 시스템이면 충분하다. 연결이 끊겨도 클라이언트는 자동 재연결하고, snapshot-first + replay + live tail 구조로 이전 상태를 복구한다.

SSE 세션의 전체 흐름. 세션이 열리면: job 조회 → latest preview 조회 → snapshot event 구성 → replay → live tail. 이 다섯 단계가 매 연결마다 반복된다. UX는 좋아졌지만, reconnect가 잦아질수록 이 initial handshake 비용이 누적된다. 그래서 최근 최적화의 초점은 "SSE를 더 붙이는 것"이 아니라 preview emit 빈도와 reconnect 비용 제어로 이동했다. 실시간 UX는 공짜가 아니다. 보여주는 것의 화려함 뒤에는 서버가 감당해야 할 비용이 있다.

진짜 품질 개선은 모델 교체보다 30권 테스트셋에서 나왔다

시스템은 완성됐다. 하지만 프로덕션 레벨로 올리려면 "잘 된다"로는 부족했다.

실제 책 30권을 전부 돌려봤다. 다양한 분야(CS, 수학, 문학, 경영), 다양한 출판사(O'Reilly, Pearson, 국내 출판사), 다양한 레이아웃. 그러자 실패 패턴이 보이기 시작했다.

챕터 누락: 모델이 일부 챕터를 통째로 건너뜀 → prompt 보강 + merge-normalize에서 누락 감지
로마자 인식 오류: Part Ⅳ를 Part IV로 혼동 → numbering normalization 규칙 보완
depth 오판: Section을 Chapter로 올리거나 내림 → parser/post-process에서 depth 보정 로직 추가
페이지 순서 흔들림: 이미지 순서와 실제 페이지 순서 불일치 → startPage 기반 정렬 강화
줄바꿈/들여쓰기 오해: OCR이 줄바꿈을 구조 구분으로 해석 → 프롬프트에 명시
디버깅 어려움: 같은 이미지인데 비결정적 결과 → live integration test + 상세 logging

모델을 바꿨다고 정확도가 저절로 올라간 게 아니었다. 품질은 테스트셋을 만들고 회귀를 막는 과정에서 올라갔다. canonical fixture를 만들고, batch integration test를 돌리고, 실패한 케이스로 live integration test를 재현하고, prompt builder를 수정하고, 다시 전체를 돌린다. 이 루프를 수십 번 반복했다.

"개발 환경 디버깅 지원"이라는 커밋 메시지가 있는데, 이건 핵심이었다. 실데이터로 실패 패턴을 재현 가능하게 만들어야 품질을 올릴 수 있었다. 재현할 수 없는 버그는 고칠 수 없다. 이건 모델의 일이 아니라 엔지니어의 일이었다.

테스트는 green이었지만, 프로덕션은 release blocker를 내놨다

30권 테스트셋을 통과하고 SSE 흐름도 안정적이었다. 테스트는 다 green이었다. 이제 올려도 되겠다 싶었다.

하지만 final review에서 release blocker가 터졌다.

terminal event 유실 시 영구 대기 (critical): completed나 failed가 유실되면 클라이언트는 영원히 "처리 중"에 머문다. 사용자는 앱을 강제 종료해야 한다.
이벤트 timestamp/message 누락: replay 시 순서가 꼬일 수 있다.
Redis MAXLEN 미설정: 이벤트가 무한히 축적된다. 메모리가 서서히 차오르다가 어느 날 Redis가 죽는다.
worker 실패 시 retry 부재: DashScope API가 실패하면 job이 영원히 processing 상태로 남는다.
preview partial JSON repair 취약점: 불완전한 JSON이 그대로 내려갈 수 있었다.

이것들 중 하나만 프로덕션에서 터져도 사용자 경험이 심각하게 망가진다. 테스트는 "정상 경로가 작동하는가"를 검증하지만, 프로덕션은 "비정상 경로에서도 안전한가"를 요구한다. release blocker를 전부 수정하고, manual runbook을 작성하고, 배포 체크리스트를 만들고, live integration transcript로 실제 SSE 흐름을 검증한 뒤에야 — 비로소 "이제 올려도 되겠다"는 판단이 섰다.

파이프라인의 마지막 조각 — hierarchy selection UX

여기까지 하면 끝일 것 같지만, 하나 더 남아있었다.

모델이 아무리 정확하게 ToC 구조를 뽑아줘도, 그 결과물을 사용자에게 그대로 던져주면 안 된다. 사용자마다 필요한 depth가 다르기 때문이다. 어떤 사용자는 Chapter 레벨만 필요하고, 어떤 사용자는 Section 레벨까지 필요하다.

그래서 hierarchy selection이 필요했다. 기본 동작은 이렇다:

리프 노드(가장 하위 항목)를 기본 선택 상태로 보여준다
상위 노드를 토글하면 하위 전체가 선택/해제된다
기본 상태가 이미 "대부분의 경우에 맞는 선택"이어야 한다

사진 → 구조화 JSON → hierarchy selection → Items 생성

이 전체 흐름이 하나의 파이프라인이다. 모델이 잘하는 건 사진 → JSON 변환이고, 나머지는 전부 엔지니어링이다.

AI 시대의 제품 엔지니어링이란 무엇인가?

여기까지 읽으면서 느꼈겠지만, 이건 단순히 OCR 기능이 아니다. 사진 → 구조화 JSON → hierarchy selection → Items 생성이라는 흐름을 엔지니어링한 것이다.

물론 겉으로만 보면 이 작업은 단순히 LLM API를 붙이고 SSE로 스트리밍 UX를 얹은 기능처럼 보일 수 있다. "요즘 다 하는 거 아닌가?" 싶을 수 있다. 이 과정을 통해 보여주고 싶은 건 느리고 비결정적이며 비용이 드는 LLM 호출을 — 사용자가 기다릴 수 있고, 이해할 수 있고, 믿고 쓸 수 있는 제품 경험으로 바꾸는 일이었다.

이건 아래 문제들을 푼 것이다:

모바일 입력 마찰을 줄이는 UX 문제
OCR이 아니라 구조화 정확도를 다루는 인식 문제
느린 LLM 응답을 제품 흐름에 맞게 바꾸는 작업 시스템 문제
polling/SSE/reconnect를 포함한 실시간 UX 문제
preview와 truth를 분리하는 데이터 신뢰성 문제
emit 빈도, Redis write, reconnect 비용 같은 운영 문제
실패 시 fallback과 사용자 계약에 대한 제품 문제

제품 엔지니어의 집요함은 거대한 기술 이름에서 증명되는 것이 아니다. 사소해 보이는 기능 하나를 끝까지 파고들어, 사용자가 불편함을 느끼지 않게 만드는 과정에서 드러난다.

ToC 인식 기능은 내가 지금 만드는 서비스에 아주 작은 부분이다. 사실 필수 기능도 아니다. 이전이라면 초기에는 제외했을 수도 있다. (그리고 결국 백로그에만 있었겠지.) 예전에 이 정도로 개발한다고 하면 내가 극구 말렸을 것이다. 비용이 안 나오는 일이다. 하지만 지금 AI 코딩 에이전트 시대에는 하루, 아니 몇 시간이면 만들 수 있는 기능이다. 그 정도면 비용을 지불할 만하다.

AI 시대의 제품 엔지니어링이란 무엇인가? 핵심은 단순히 동작하는(Do Work)을 넘어, Good을 거쳐 Great까지 디테일을 파고드는 과정이다. "이 정도면 괜찮지"(Good)에서 머물지 않고 최대의 디테일을 파고들어 극대화시키는 것(Great)이 AI 시대의 제품 엔지니어링일 것이다.

하네스를 아무리 잘 구축해도, 에이전트 성능이 아무리 올라가도 — 결국 고민하고 결정하는 건 엔지니어 본인이다. 개발은 Codex를 대부분 사용했고 Superpowers 스킬(Codex의 자율 실행 모드)을 적극 활용했다. 하지만 해당 구현 흐름은 하네스 엔지니어링이 아니라, 실제 개발 흐름 — 요구사항 분석, 구현, 최적화 — 을 내가 계속 파고들고 결정한 부분이다.

내가 직접 코드를 작성하지 않는다고 Craftsmanship(장인정신)이 사라지는 건 아니다. "이쯤 하면 완료되지 않았을까" 할 때 모든 걸 처음부터 점검해보고 테스트해보고 2%를 더 고민해보는 것. 그게 필요하다.

나가며

개발을 처음 배울 때는 참 신이 난다. 아마 지금 바이브 코딩으로 입문하는 대부분의 사람들도 신이 날 것이다. 처음 내가 의도한 대로 동작하는 서비스를 만들었을 때의 그 기분은 잊을 수가 없다. (나는 2011년에 Ruby on Rails로 웹 버전 Dropbox를 스스로 클로닝했었다. 그때의 뿌듯함이란.)

하지만 작동하는 기능과 믿고 쓸 수 있는 제품 사이에는 굉장히 큰 갭이 있다. 특히 이번 글에서 다룬 AI 모델 연동은 처음이 제일 신나는 순간이다. 벤더가 제공하는 서비스에서 직접 모델을 테스트했을 때 성능이 나오는 걸 보면서 "이걸로 뭐든 만들 수 있겠다" 싶은 순간이고 설렌다. 그러나 곧바로 좌절을 맛본다. LLM API 비용부터 실제 프로덕션 환경에서의 운영 방식까지, 그냥 API 붙이면 된다고 생각했던 것보다 80%는 더 고민하고 시행착오를 겪어야 했다.

내가 만든 제품이 Great라고 생각하지 않는다. 하지만 유저 입장에서 "이건 불편할 건데", "직관적이지 않은데" 하고 느끼는 포인트에서 그걸 무시하느냐 마지막까지 붙잡고 늘어지느냐 — 그게 Great로 가는 갈림길이라고 생각한다.

개발 비용이 비싼 시대에서는 오버 엔지니어링이라는 말로 디테일을 파고드는 걸 경시했다. 하지만 3주가 아니라 하루를 투자해서 디테일을 만들 수 있다면 그걸 포기할 필요가 있을까? 기능이 10개라면 3개만 제공하더라도 그 3개가 유저 입장에서 훌륭한 제품 경험을 제공해준다면 그게 더 맞는 방향이라고 생각한다.

AI가 코드를 짜주는 시대에도, 잘 만든 제품을 만든 엔지니어들을 보면 결국 밤을 새고 있다. 나에게 iOS 개발은 어렵다. 다년간 Flutter 개발을 하다가 iOS를 선택했고, Codex를 아무리 두들겨 패도 UI 트랜지션 코드는 한 번 삐끗하면 답이 없다. 무한루프가 시작된다. 하루를 날 새고도 간단한 이슈를 수정하지 못할 때, 그제야 기초를 건너뛴 걸 반성하고 로그도 찍어보고 비슷한 데모를 검색해본다. 옛날처럼. 결국 AI가 못 풀면 내가 찾아야 한다. 밤을 새면서 preview emit 정책을 고민하고 있었던 것처럼.

나만 그런 건 아니다. OpenClaw 개발자는 60일 동안 43개의 프로젝트를 만들고 버린 뒤에야 하나가 터졌다. 그 60일간의 커밋 히스토리를 보면 새벽 3시, 4시 커밋이 수두룩하다. AI가 코드를 짜주는 시대에도 "broken at least once, and eventually fixed at 1 AM while questioning my life choices"라고 쓰는 개발자들이 진짜 제품을 만들고 있다. Zed 에디터 팀은 작년에 "The Case for Software Craftsmanship in the Era of Vibes"라는 글을 썼다. 바이브 코딩 시대에도 장인정신이 필요하다는 선언이다. 심지어 Artisanal Coding(職人コーディング)이라는 매니페스토까지 나왔다. 그 시대에 일본식 장인정신을 소환하다니. 과하다 싶으면서도 공감한다.

AI 코딩 에이전트가 생산성을 30~60%까지 올려준다고 한다. 맞다. 나도 체감한다. 하지만 그 절약된 시간을 어디에 쓰느냐가 갈림길이다. 기능을 더 많이 찍어내느냐, 아니면 하나의 기능을 더 깊이 파느냐. 나는 후자를 택했고, 그게 맞다고 아직도 생각한다. (물론 매출이 그걸 증명해줘야 하는데, 그건 아직 모른다.)

남들은 한 달에도 앱을 10개씩 찍어내는데, 하나의 제품을 만든 지 벌써 세 달째로 접어들었고 그마저도 처음 기획했던 기능들을 상당수 걷어냈다. 코딩 에이전트가 옆에 앉아 있는 시대에도, 엔지니어링은 장인 정신이다. AI가 그럴듯한 80점짜리 평균을 답변할 때 나머지 20점을 채우는 건 당신이다.

References

에이전틱 엔지니어링 시대의 생존 스킬 9가지 — Karpathy가 제시한 에이전틱 엔지니어링 시대, 엔지니어가 갖춰야 할 9가지 능력
Claude Code에 날개를 달아줘라! - Superpowers 소개 — Codex의 자율 실행 모드 Superpowers 설치법과 7단계 워크플로우
15년차 CTO가 바이브 코딩하는 방법 — 켄트 백의 증강형 코딩 철학 기반, AI와 페어 프로그래밍하는 방식
AI는 당신만큼만 똑똑하다 — 같은 AI를 쓰는데 왜 격차가 벌어지는가. AI의 아웃풋은 당신의 인풋으로 결정된다
AI 에이전트 자비스, 내 두 번째 두뇌가 되기까지 — OpenClaw 프레임워크로 24시간 AI 에이전트를 구축한 실전 경험기
The Case for Software Craftsmanship in the Era of Vibes — Zed 에디터 팀의 소프트웨어 장인정신 선언 (2025.06)
Artisanal Coding(職人コーディング): A Manifesto — AI 시대의 소프트웨어 장인정신 매니페스토 (2025.10)
OpenClaw: One Developer, 43 Failed Projects — Peter Steinberger가 43개의 프로젝트를 만들고 버린 뒤 OpenClaw를 만든 이야기
Qwen 3.5 모델 소개 — Alibaba Cloud Qwen 3.5 Flash 모델 공식 발표 (2026.02.23)
DashScope Model Studio — AlibabaCloud DashScope API 문서 및 가격 정책

AI 시대에 코드 리뷰, 어떻게 해야할까?

Tony Cho (https://flowkater.io) — Sun, 08 Mar 2026 03:00:00 GMT

들어가며

CTO로 일하면서 가장 먼저 없어진 "공식 업무" 중 하나가 코드 리뷰였다. 팀이 충분히 커지기 전에는 백엔드 팀 코드 리뷰를 진행했었지만 CTO이자 팀원이 20명이 넘어가면서 상황이 달라졌다. CTO라는 업무적 직함보다 R&D 본부장이라는 지위적 직함이 우선시되며 내 관리는 코드에서 사람으로 넘어갔다.

하지만 그 이후에도 코드 리뷰를 하지 않았던 건 아니다. 다소 소규모였던 데이터 엔지니어 팀은 리드가 부재하여 내가 직접 1년여가 넘게 코드 리뷰부터 스터디까지 하였고 막 들어온 주니어 개발자들과는 포지션을 막론하고 함께 스터디하고 코드 리뷰했다. 과중한 업무에 바쁜 선임 개발자들이 챙기기 어려운 부분이었다. 때론 코드 작성에 어려움을 겪고 있는 주니어와 1 on 1으로 몇 주에 걸쳐 리뷰하고 피드백하기도 했다. 다만, "공식 업무"에서 배제되었기 때문에 이러한 업무는 나의 업무 시간 내에 소화하기에는 어려움이 있었다.

사실 "공식 업무"로 불리기 어려운 부분도 있는데 특히, 코드 리뷰를 어떻게 할 것인가가 프로세스로 정립되지 않았었고 그 부분은 아직까지도 어려운 부분이다. 당시 코드 리뷰를 개발자들이 서로 돌아가며 하는 문화를 정착시키려고 노력했으나 어떤 사람은 본인의 업무가 아닌 코드 리뷰를 왜 해야 하는지 필요성을 느끼지 못하고 있는 반면 어떤 사람은 너무나 열성적이었지만, 공격적으로 진행하여 그 사람의 열정에도 불구하고 주위의 눈살을 찌푸리는 일들이 빈번히 일어났다.

코드 리뷰 방식도 제각각이었다. 백엔드(또는 데이터나 프론트엔드도 마찬가지)의 경우 나는 Application Layer를 중심으로 코드 아키텍처와 코드가 충분히 Human Readable인지 기존에 조직 내에서 정하고 있는 규칙을 범하고 있지는 않은지를 주로 살펴보았고 특히 더 좋은 코드를 작성하는 방법을 피드백했고 불필요한 중복이나 트레이드 오프가 발생하는 설계 이슈에서 가이드라인을 제시해주는 방향으로 진행했다. 하지만 또 다른 팀장님의 경우에는 코드 브랜치를 직접 받아 실행까지 해보고 최종 퀄리티까지 리뷰를 하기도 했다. (이건 클라이언트쪽이다.) 시간이 여유롭다면 대부분의 경우 후자가 더 좋은 리뷰가 되겠지만 결국 그만큼 시간 비용이 많이 들기 때문에 일이 많아지면 제대로 리뷰하기 어려워졌다.

문제는 결국 시간이었다. 좋은 리뷰 프로세스를 가진 회사도 많이 보았지만 생존과 매일이 데드라인인 IT스타트업 특성상 오늘 작업하고 오늘 배포하는 일이 빈번했고 코드 리뷰가 가능한 (그리고 마음씨 좋은) 실력 있는 개발자는 소수였으며 결국 누락된 PR이 일정이라는 어쩔 수 없는 이유로 머지되면서 아직 코드 아키텍처의 멘탈 모델이 약한 주니어 개발자들 또는 일정이라는 괴물에게 자신의 코드 퀄리티를 내준 시니어들까지 — 점점 코드베이스 또한 괴물이 되어갔다.

문제는 결국 사람이었다.

AI 에이전틱 엔지니어링 또는 코드를 읽지 않는 시대에 이전 시대의 문제를 해결할 도구가 대거 등장했다. 처음엔 CodeRabbit으로 시작해서 Codex나 Claude Code로도 PR 메시지와 라인바이라인으로 코멘트가 가능해졌다. 즉, 사람에 의존하지 않고 코드 리뷰가 가능해진 것이다.

다만, 그렇게 올라오는 PR도 사람에 의존하지 않고 작성한 코드들이라는 것이다.

잘 모르는 주니어 개발자가 AI를 써서 막 올렸다가 시니어 개발자가 하나씩 모두 손보면서 밤을 샜다는 괴담은 실제인지 모르겠으나 종종 들려오는 괴담이다. 이건 AI에 대한 불신처럼 들리지만 사실 잘 모르고 쓰는 주니어에 대한 불신에 더 가깝다. 원래 실력은 파이어볼 정도 쓰는 마법 지망생이 아무런 경험과 마법적 지식 없이 무한한 마력의 원천(AI)을 얻어 헬파이어를 써대며 일종의 주화입마에 빠지는 것이다.

어찌됐든 이런 얘기가 계속 나오는 건 코드에 대한 개인 책임이 있는 조직에서는 AI로 코드를 생산해도 결국 그 코드에 대한 책임이 본인에게 있기에 많은 조직들에서 이 문제에 대해 아주 골머리를 앓고 있는 게 분명하다. AI로 개인의 생산성은 대폭 증폭되었는데 팀 성과나 회사의 성과가 눈에 띄게 증폭되는 사례가 그렇게 많지 않은 것도 결국 그런 이유 중 하나일 것이다. 팀 협업은 결국 책임의 문제일 수도 있다.

재미있는 데이터가 있다. 1만 명 이상의 개발자를 조사한 결과, AI 도입률이 높은 팀은 PR을 98% 더 많이 머지하지만 리뷰 시간은 91% 늘어났다. 개인은 빨라졌는데, 팀은 느려진 것이다. 코드 리뷰라는 병목이 사라진 게 아니라 그냥 더 커졌다.

결국 남은 질문은 하나다. AI 시대에 코드 리뷰, 어떻게 해야할까?

인간이 리뷰하지 않은 코드는 여전히 신뢰하지 않는다

먼저 가장 직관적인 입장부터 살펴보자. "아무리 AI가 좋아졌어도, 인간이 안 본 코드는 믿을 수 없다."

Simon Willison은 최근 에이전틱 엔지니어링 안티패턴을 정리하면서 첫 번째로 꼽은 것이 바로 이것이었다. "검토하지 않은 코드를 협업자에게 떠넘기지 마라." 에이전트가 수백, 수천 줄의 코드를 만들어줬다고 해서 그걸 그대로 PR로 올리는 건 실제 작업을 팀원에게 떠넘기는 것이다. 그는 이렇게 말한다. "그들도 에이전트에게 프롬프트를 날리면 되는데. 그렇다면 당신이 제공하는 가치는 대체 무엇인가?"

날카로운 질문이다. 그리고 나는 이 말에 꽤 공감한다. CTO 시절 가장 답답했던 순간은 PR이 올라왔는데 올린 사람이 자기 코드를 설명하지 못할 때였다. AI 시대에도 이건 마찬가지다. 아니, AI 시대이기 때문에 더하다. 에이전트가 그럴듯한 PR 설명까지 작성해주니까. 에이전트가 쓴 PR 설명을 본인도 안 읽고 올리는 사람이 있다면 (나도 가끔 그러고 싶은 유혹을 느끼지만) 그건 리뷰어에 대한 예의가 아니다.

내가 가장 존경하는 엔지니어 중 한 명인 Kent Beck도 비슷한 입장이다. 이전에 15년차 CTO가 바이브 코딩하는 방법에서 그의 증강형 코딩(Augmented Coding) 철학을 소개한 적이 있는데, 핵심은 같다. AI가 코드를 생성하는 속도가 빨라질수록 테스트와 리뷰의 중요성은 줄어드는 게 아니라 오히려 커진다는 것이다. 생성 비용이 0에 가까워질수록, 가치의 원천은 생성이 아니라 검증으로 이동한다.

Addy Osmani도 이 점을 정확히 짚었다. "해결되지 않은 문제는 생성(generation)이 아니라 검증(verification)이다. 바로 거기서 엔지니어링 판단력이 당신의 가장 높은 레버리지 스킬이 된다." 코드를 만드는 건 AI가 잘한다. 그런데 그 코드가 맞는지, 우리 시스템에 맞는지, 6개월 뒤에도 유지보수 가능한지를 판단하는 건 여전히 사람의 몫이다. 적어도 지금은.

이 입장의 핵심은 명확하다. AI가 아무리 코드를 잘 생성해도, 그 코드에 대한 책임은 결국 사람에게 있다. 책임이 있다면 검증해야 하고, 검증한다면 리뷰해야 한다. 논리적으로 완벽하다.

다만, 여기서 한 가지 불편한 진실이 있다. 그 "리뷰"를 할 시간과 역량이 있는 사람이 충분한가? CTO 시절의 내가 그랬듯이, 코드 리뷰가 공식 업무에서 밀려나는 건 의지의 문제가 아니라 현실의 문제였다. AI가 코드 생산량을 3배로 늘렸는데, 리뷰 역량은 그대로라면? 이 입장은 옳지만, 현실적으로 지속 가능한지는 다른 문제다.

더 이상 사람이 코드 리뷰하는 시대는 지났다

반대편에는 훨씬 과격한 주장이 있다. "사람이 코드를 리뷰하는 시대는 끝났다. 아니, 끝내야 한다."

Bryan Finster는 최근 이 문제에 나이퀴스트-섀넌 표본화 정리(Nyquist-Shannon Sampling Theorem)를 적용했는데, 이 비유가 꽤 설득력이 있다. 신호를 정확하게 복원하려면 최고 주파수의 2배 이상으로 샘플링해야 한다는 통신 이론인데, 소프트웨어에 적용하면 이렇다. 결함 감지 속도가 코드 생산 속도를 따라가지 못하면, 문제를 이따금 놓치는 게 아니라 체계적으로 놓치게 된다.

AI는 높은 주파수로 코드를 생산한다. 수동 코드 리뷰는 저주파 샘플링 메커니즘이다. 피드백 주파수를 높이지 않고 생산 주파수만 높인 것이다. 이건 언더샘플링의 정의이고, 언더샘플링은 문제를 놓친다는 뜻이다. 이따금이 아니라, 확실하게.

SmartBear가 시스코 시스템즈 팀을 분석한 데이터도 이를 뒷받침한다. 인간 리뷰어의 결함 감지율은 400줄을 넘어가면 급격히 떨어진다. 그런데 AI 한 번 프롬프트로 600줄이 나온다. 400줄 넘는 PR은 리뷰가 아니라 도장이다. Rubber stamp. 내가 CTO 시절 경험한 것과 정확히 일치한다. 일정에 쫓기면 PR 리뷰는 형식이 되었고, 실력 있는 개발자조차 "대충 훑어보고 LGTM" 하는 상황이 빈번했다. AI 시대에는 이게 더 심해졌을 뿐이다.

StrongDM이라는 회사는 이 논리를 극단까지 밀어붙였다. 그들의 "소프트웨어 팩토리(Software Factory)"에서는 인간이 코드를 쓰지 않고, 인간이 코드를 리뷰하지 않는다. 인간이 하는 일은 의도(intent)를 정의하고, 시나리오를 큐레이션하고, 제약 조건을 설정하는 것이다. 그 이후는 에이전트가 전부 한다. 코드를 생성하고, 디지털 트윈 유니버스(Digital Twin Universe)라는 서드파티 서비스의 행동 클론 환경에서 시나리오를 검증하고, 통과할 때까지 반복한다. 검증(validation)이 코드 리뷰를 대체한 것이다.

솔직히 처음 이 사례를 봤을 때는 "이게 되나?" 싶었다. 하지만 Simon Willison이 이 팀의 시연을 직접 보고 블로그에 올렸고, Wharton의 Ethan Mollick 교수와 Y Combinator의 Garry Tan도 이 접근 방식에 주목했다. Stanford Law School의 CodeX에서는 "Built by Agents, Tested by Agents, Trusted by Whom?"이라는 분석 글까지 나왔다. 제목부터 직설적이다. 에이전트가 만들고, 에이전트가 테스트하면, 그걸 누가 믿을 수 있는가? 같은 종류의 AI가 코드를 쓰고 같은 종류의 AI가 테스트하면, 둘 다 같은 걸 놓길 수 있다. 그리고 이렇게 만들어진 소프트웨어가 프로덕션에서 터졌을 때, 코드를 쓴 사람이 없으니 책임은 누구에게 있는가? 이 질문에 아직 아무도 답하지 못했다. 그런데도 StrongDM은 이 방식을 프로덕션에 쓰고 있다 — 보안 인프라를 만드는 회사가. 그게 이 실험을 무시할 수 없는 이유다.

StrongDM이 극단이라면, Salesforce는 현실적인 중간지대를 택했다. AI 보조 코딩 도입 후 코드 양이 약 30% 증가했고, PR은 파일 20개, 변경 라인 1,000줄을 넘는 일이 다반사가 됐다. 더 우려스러운 건, 가장 큰 PR에 대한 리뷰 시간이 오히려 줄어들기 시작했다는 것이다. 리뷰어들이 변경 사항과 의미 있게 씨름하지 않고 있다는 신호였다. Salesforce는 Prizm이라는 시스템을 만들어 리뷰 프로세스 자체를 재아키텍팅했다. 단순히 "AI 리뷰어를 추가하자"가 아니라, diff 중심의 리뷰 모델 자체가 AI 시대에 작동하지 않는다는 것을 인정하고 의도 재구성(Intent Reconstruction)이라는 새로운 접근법을 도입한 것이다.

이 입장의 사람들이 공통적으로 하는 말이 있다. "AI가 안전망을 제거한 게 아니다. AI는 안전망이 처음부터 사람의 영웅적 행위에 의존하고 있었다는 것을 드러냈을 뿐이다." Bryan Finster의 표현인데, 이게 참 아프다. CTO 시절 코드 리뷰를 공식 업무에서 빠뜨렸던 것, 열성적인 리뷰어 한 명에게 의존했던 것, 일정에 밀려 그냥 머지했던 것 — 모두 "안전망이 사실은 영웅에게 의존하고 있었다"는 증거였다.

그럼 무엇을 리뷰해야할까?

"코드 리뷰를 유지해야 한다"도 맞고, "사람이 다 리뷰할 수는 없다"도 맞다. 그럼 도대체 뭘 어쩌란 말인가?

latent.space의 Ankit Jain은 이 질문에 가장 명쾌한 프레임을 제시했다. 코드 리뷰에서 의도 리뷰(Intent Review)로 전환하라는 것이다. 500줄짜리 diff를 한 줄 한 줄 읽는 게 아니라, 스펙(spec)과 수용 기준(acceptance criteria)과 제약 조건(constraints)을 리뷰하라.

이 프레임에서 스펙이 진실의 원천(source of truth)이 되고, 코드는 스펙의 산출물(artifact)이 된다. 인간의 역할은 "이것을 올바르게 작성했는가?"에서 "올바른 제약으로 올바른 문제를 해결하고 있는가?"로 이동한다. 가장 가치 있는 인간의 판단은 코드가 생성된 후가 아니라, 생성되기 전에 발휘된다.

솔직히 이건 새로운 개념이 아니다. 행동 주도 개발(BDD, Behavior-Driven Development)이 수년간 주장해온 것과 같다. 코딩 전에 팀이 모여서 "이 기능이 어떻게 동작해야 하는가"를 실행 가능한 시나리오로 정의하고, 그 시나리오가 곧 인수 테스트가 된다. 다만 예전에는 스펙을 작성하는 것 자체가 추가 작업처럼 느껴져서 완전히 보편화되지 못했다. 에이전트와 함께라면 방정식이 뒤집힌다. 스펙이 추가 작업이 아니라 기본 산출물이 되는 것이다.

Ankit Jain은 신뢰를 레이어로 쌓아야 한다고 말한다. 스위스 치즈 모델처럼 — 단일 게이트가 모든 것을 잡지 못하니까, 불완전한 필터를 겹겹이 쌓아 구멍이 정렬되지 않도록 하는 것이다. 여러 에이전트에게 다른 방식으로 시도하게 하고 최선을 선택하는 것이 첫 번째 레이어고, 테스트와 타입 검사 같은 결정론적 가드레일이 두 번째, 인간이 수용 기준을 사전에 정의하는 것이 세 번째다. 여기에 에이전트의 권한 세분화와 적대적 검증 — 한 에이전트가 만들고, 다른 에이전트가 부수려 시도하는 — 까지 쌓으면 다섯 겹의 필터가 완성된다.

실전적인 관점에서는 Qodo가 제시한 2026년 AI 코드 리뷰 패턴이 눈여겨볼 만하다.

첫째, 컨텍스트 우선 리뷰(Context-First Review). diff를 열기 전에 크로스 레포 사용 현황, 이력 PR, 아키텍처 문서를 자동으로 모아서 컨텍스트를 필수 입력으로 취급한다. CTO 시절 리뷰에서 가장 어려웠던 것이 바로 컨텍스트였다. "이 코드가 왜 이렇게 되어 있지?"를 파악하는 데 리뷰 시간의 절반을 쓴 적도 있었다.

둘째, 심각도 기반 리뷰(Severity-Driven Review). 발견사항을 조치 필요/권장/사소한 제안으로 분류한다. 봇이 프로덕션을 다운시킬 null 체크는 놓치면서 공백에 관한 37개의 코멘트를 쏟아내는 경험을 해본 적이 있다면, 이것이 왜 필요한지 바로 이해할 것이다.

셋째, 전문가 에이전트 리뷰(Specialist-Agent Review). 하나의 제너럴리스트 모델에게 보안 전문가, 성능 엔지니어, 스태프 SWE를 동시에 해달라고 하는 건 무리다. 보안 에이전트, 성능 에이전트, 정확성 에이전트를 따로 두고 각각의 전문 영역에서 분석한 뒤 코디네이터가 통합 리포트를 만든다. 이건 에이전틱 엔지니어링 9가지 스킬에서 다룬 "분해 능력"과도 직결된다. 하나의 거대한 태스크를 전문 영역별로 쪼개는 것.

Bryan Finster도 비슷한 결론에 도달했다. 자동화가 모든 것을 처리한 후, 진정으로 인간이 머지를 블로킹해야 할 목록은 딱 두 가지뿐이라고.

하나는 부족 지식(tribal knowledge)이다. 통합 특이점, 역사적 결정, "우리가 그걸 시도했는데 결제를 망가뜨렸다"는 맥락 — 사람들의 머릿속에만 있고 어디에도 문서화되지 않은 것들. 장기적으로는 이것도 문서와 아키텍처 결정 기록(ADR)에 담아 도구로 강제해야 한다. 하지만 단기적으로는 "어디에 시체가 묻혀 있는지 아는 사람"이 필요하고, 그 사람의 역할은 구문 리뷰가 아니라 맥락 리뷰다.

다른 하나는 규제 경로(regulated paths)다. 직무 분리가 컴플라이언스 요건인 환경에서는 민감한 영역에 대한 변경을 두 번째 인간이 승인해야 한다. 이건 협상할 수 없다. 하지만 그렇다고 모든 PR에 같은 기준을 적용할 이유도 없다.

도구 측면에서도 변화가 일어나고 있다. CodeRabbit은 GitHub, GitLab, Bitbucket, Azure까지 멀티 플랫폼을 지원하며 접근성을 넓혔고, Greptile은 전체 코드베이스를 인덱싱해서 가장 깊은 수준의 버그 탐지를 시도하고 있다. GitHub Copilot 코드 리뷰는 출시 한 달 만에 100만 사용자를 달성했다. 이미 Copilot을 쓰고 있다면 마찰이 거의 없다는 장점이 있지만, diff 기반이라 아키텍처 수준의 문제는 놓치기 쉽다. 어떤 도구를 쓰든 핵심은 같다. AI가 잡을 수 있는 것(구문, 스타일, 단순 로직 버그, 보안 패턴)은 AI에게 맡기고, 인간은 AI가 절대 잡을 수 없는 것(의도, 맥락, 비즈니스 판단, 부족 지식)에 집중하라.

결국 "무엇을 리뷰해야 하는가"에 대한 답은 이렇게 정리된다. 코드가 아니라 의도를 리뷰하라. diff가 아니라 스펙을 리뷰하라. 구문이 아니라 맥락을 리뷰하라.

나가며

솔직히 말하면, 나는 지금 내가 AI로 작성한 코드를 직접 리뷰하지 않는다.

대신 QA의 역할을 한다. 실제로 의도한 대로 동작하는지를 위주로 테스트하고, 문제가 생기는 경우에만 코드를 들여다본다. 직접 수동 QA 테스트를 진행하고 만약 이게 코드로도 재현 가능한 로직이라면 케이스를 증폭시켜 통합 테스트 케이스를 만들어서 다음번에 반복하지 않도록 작업한다. API 시나리오 테스트나 외부 연동 그리고 UX 테스트는 여전히 한계가 있기 때문에 내가 얼마나 부지런히 손을 태웠느냐에 따라 퀄리티가 달라지는 게 사실이다.

앞에서 살펴본 것처럼, 코드를 한 줄 한 줄 읽는 시대는 이미 지났다. 하지만 코드에 대한 책임까지 사라진 건 아니다. 오히려 책임의 형태가 바뀐 것이다. 코드를 쓰는 사람에서 코드가 의도대로 작동하는지 확인하는 사람으로. 리뷰어에서 검증자로.

그렇다면 이 "검증자"의 역할은 구체적으로 뭘까?

현시대의 AI 네이티브 엔지니어 또는 풀스택 빌더는 어쩌면 이전 시대의 PM 역할을 스스로 할 수 있어야 한다고 생각한다. 특히 제품 퀄리티 면에서. 요구사항을 정의하고, 수용 기준을 설정하고, 에이전트에게 구현을 맡기고, 결과를 검증하고, 프로덕션에서 모니터링한다. 이건 전통적인 개발자의 역할과는 확실히 다르다. 에이전틱 엔지니어링 9가지 스킬에서 "완료 정의"와 "관찰 가능성"을 강조한 것도 결국 이 맥락이다.

사실 이건 완전히 새로운 이야기도 아니다. 이전 시대에도 두 종류의 개발자가 있었다. 코드가 머지되면 업무를 끝내는 개발자와, 머지된 후에도 배포하고 모니터링하고 프로덕션에서 본인의 손으로 직접 테스트하는 개발자. 후자가 훨씬 잘하는 개발자였고, 무엇보다 책임 있는 개발자였다.

시대가 바뀌며 코드를 생산하는 비용은 거의 0에 가까워졌다. 에이전트가 한 시간에 세 가지 버전의 기능을 만들어낼 수 있는 세상에서, "코드를 잘 쓰는 능력"만으로는 더 이상 차별화되지 않는다. 차별화되는 건 그 코드가 진짜 문제를 해결하는지 판단하는 능력, 프로덕션에서 문제가 생겼을 때 대응하는 능력, 그리고 무엇보다 — 자기 이름으로 나간 코드에 끝까지 책임지는 태도다.

당신은 당신의 코드에 책임을 질 수 있는가?

References

세계 최대의 AI 기업은 차세대 엔지니어를 어떻게 교육하는가 — Anthropic x CodePath 커리큘럼 리뷰

Tony Cho (https://flowkater.io) — Fri, 06 Mar 2026 11:00:00 GMT

들어가며

더이상 코드를 타이핑하지 않는 시대에, 세계 최대 AI 기업이 만든 커리큘럼의 첫 과제는 "AI가 짠 코드에서 버그를 찾아라"이다.

2026년 2월, Anthropic이 CodePath와 파트너십을 발표했다. CodePath는 미국 최대 규모의 대학 CS 교육 프로그램이다. 20,000명 이상의 학생, 그 중 40%가 저소득 가정 출신. CodePath CEO Michael Ellison은 이렇게 말했다.

"We now have the technology to teach in two years what used to take four." 4년 걸리던 걸 2년에 가르칠 기술이 생겼다.

AI로 수업을 빠르게 돌리겠다는 게 아니다. AI를 도구로 쓰되, AI를 의심하는 훈련을 진행하는 것이다. Claude Code를 만든 회사가 정작 가르치는 건 Claude Code를 의심하는 법을 가르친다? 이 역설이 흥미로워서 커리큘럼을 뜯어봤다.

뭘 배워야 하나? AI 시대에 엔지니어는 어디에 시간을 투자해야 하나? 이 질문에 대한 Anthropic의 답이 이 커리큘럼에 담겨 있다.

CodePath 커리큘럼 뜯어보기

커리큘럼은 3단계, 총 30주+ 과정이다. 각 단계를 주차별로 최대한 상세하게 풀어본다.

주의: 이 커리큘럼은 2026년 여름 정식 런칭 예정이며, Howard University에서는 이미 2026년 봄학기에 학점 과목으로 개설되어 진행 중이다. 아래 주차별 배치와 세부 과제는 공개된 토픽 리스트와 파일럿 사례를 바탕으로 일부 추론하고 분석한 것이며, 실제 커리큘럼과 다를 수 있다.

1단계: Foundations of AI Engineering (10주)

기초 단계인데, "기초"의 정의가 기존 부트캠프와 완전히 다르다.

Week 1-2 는 Python 기반 자료구조, 알고리즘, OOP다. 여기까지는 어디서나 볼 수 있는 구성. 근데 과제가 다르다. Claude Code로 링크드 리스트, 트리를 구현하고 — 여기서 끝이 아니라 — AI가 생성한 코드를 직접 리뷰하고 버그를 찾는다.

첫 주부터 "AI가 짠 코드를 그냥 쓰지 마라"를 훈련시키는 거다. (참고로 커리큘럼은 Claude Code를 중심으로 하되, GitHub Copilot이나 AI 기반 IDE도 함께 활용한다. 도구 하나에 종속되지 않게 설계한 셈이다.)

Week 3-4 가 진짜 핵심이다. AI 생성 코드의 비판적 평가 . 의도적으로 미묘한 버그가 있는 AI 코드를 제공하고 디버깅 + 개선안을 작성하게 한다. 같은 문제를 프롬프트만 바꿔서 3번 생성하고, 결과를 비교 분석하는 리포트도 쓴다.

생각해보면 이게 꽤 영리하다. 프롬프트 3번 바꿔서 결과를 비교하면, "아, AI는 프롬프트에 따라 완전히 다른 코드를 내놓는구나"를 체감하게 된다. 같은 AI인데 질문 방식에 따라 품질이 천차만별이라는 걸.

Week 5 는 알고리즘적 사고 + 프롬프트 체인 설계. 복잡한 문제를 단계별로 분해하고, 각 단계에 맞는 프롬프트 체인을 설계한다. "프롬프트 하나로 해결 vs 3단계 체인"을 비교하는 실험도 있다. 프롬프트 엔지니어링을 단순한 스킬이 아니라, 알고리즘적 사고의 연장으로 가르치는 셈이다.

Week 6 은 ML 리터러시. 수학 없이 개념만. 지도학습, 비지도학습, 생성모델의 use case를 분류하고, 사전 학습된 감정 분석 모델 API를 호출해서 결과를 해석하는 리포트를 쓴다. "모델을 만드는 법"이 아니라 "모델이 뭘 하는지 이해하는 법"에 집중한다.

Week 7-8 이 실전으로 들어가는 구간이다. RAG, 에이전틱 워크플로우, 파인튜닝, 가드레일. PDF 3개로 벡터 DB 구축해서 Q&A 챗봇 만들기, 도구 2-3개 연결한 에이전트 만들기, 챗봇에 "개인정보 노출 방지" 필터 추가 후 레드팀 테스트까지. 1단계 7주차에 이미 가드레일을 가르친다. 프로덕션 관심사를 초기부터 심어두는 거다.

Week 9 는 Git/GitHub 협업. PR 생성, 코드 리뷰, 머지 컨플릭트 해결. 이걸 9주차에 넣은 건 의도적이라고 본다. "혼자 AI로 만드는 것"에서 "팀으로 AI와 함께 만드는 것"으로 넘어가는 전환점.

Week 10 은 최종 프로젝트. 챗봇, 요약 도구, 문서화 어시스턴트 중 선택. RAG + 가드레일을 통합한 실제 작동하는 결과물을 만든다.

★ 강조 과제: "AI가 짠 정렬 알고리즘 5개 중 틀린 것 찾기"

이 과제가 1단계의 철학을 압축한다. AI가 5개의 정렬 알고리즘 구현을 내놓으면, 학생은 그 중 틀린 것을 찾아야 한다. "AI가 맞다고 가정하지 마라"가 전체 커리큘럼의 첫 번째 원칙이다.

기존 교육이 "정렬 알고리즘을 직접 구현하라"였다면, 이 커리큘럼은 "AI가 구현한 정렬 알고리즘을 읽고 평가하라 " 로 바뀐 거다. 쓰기에서 읽기로. 생산에서 검증으로. 이 전환이 핵심이다.

2단계: Applications of AI Engineering (10주)

1단계가 기초 훈련이었다면, 2단계는 실전이다. 그리고 난이도가 확 올라간다.

Week 1-2 부터 강렬하다. 실제 오픈소스 프로젝트 — 1만 줄 이상의 코드베이스를 받는다. Claude Code로 구조를 파악하고, 아키텍처 다이어그램을 작성한다.

1만 줄이 많다고? 실무에서는 수십만 줄짜리 레거시를 받아들고 "이거 다음 주까지 파악해"라는 말을 듣는다. 1만 줄은 그 연습인 셈이다.

Week 3-4 는 스펙 기반 구현 + 디버깅이다. CodePath는 이걸 공식적으로 "Spec-driven vibe coding"이라고 부른다. 기능 스펙 문서를 받고 AI로 구현한 다음, 테스트를 통과시킨다. 바이브 코딩이라는 이름을 쓰되, 스펙이라는 조건을 붙인 게 포인트다. 그리고 결정적인 차이가 하나 더 있다. "AI가 못 풀어서 내가 직접 한 부분"을 기록 해야 한다.

Week 5-7 은 고급 기법의 프로덕션 통합이다. 기존 웹앱에 RAG 검색 기능을 추가하고, 에이전트 파이프라인에 에러 핸들링 + 로깅 + 모니터링을 붙이고, 가드레일 정책 설계 문서를 작성한 뒤 구현하고 평가까지 한다. 주목할 건, 신규 개발이 아니라 기존 코드베이스 통합 이라는 점이다. "새로 만들기"는 AI가 잘한다. "기존 코드에 끼워 넣기"는 사람이 해야 한다.

Week 8-9 는 PR 리뷰 훈련이다. 다른 팀의 AI 생성 PR을 리뷰하고, "이 코드가 AI가 짠 건지 사람이 짠 건지" 판별 + 개선 코멘트를 단다. 리뷰 기준 체크리스트도 직접 만든다 — 보안, 성능, 가독성, 테스트 커버리지.

AI가 코드를 짜는 시대에 코드 리뷰 체크리스트를 만들게 하는 거다. 이게 읽기 능력 훈련의 끝판왕이다.

Week 10 은 실제 오픈소스 PR 제출. 2025년 파일럿 기준 GitLab, Puter, Dokploy 같은 프로젝트에 실제로 PR을 내고 메인테이너 리뷰를 받는다.

★ 강조 과제: "1만+ LOC 오픈소스 구조 파악"

코드를 한 줄씩 읽지 말고, AI에게 올바른 질문을 하라. 이게 이 과제의 핵심이다. "이 프로젝트의 진입점이 뭐야?", "데이터 흐름이 어떻게 되지?", "이 모듈의 핵심 의존성은?" — 이런 질문을 AI에게 던지면서 거대한 코드베이스를 구조화하는 훈련.

이전 글 "코드를 읽지 않는 시대"에서 말했던 바로 그 능력이다. AI 시대의 코드 읽기는 한 줄씩 따라가는 게 아니라, 구조를 파악하고 핵심 로직을 집중적으로 보는 거다.

★ 강조 과제: "AI가 못 풀어서 내가 직접 한 부분 기록"

이게 AI 시대의 학습 증명 방식이다. AI가 짜준 코드는 내 실력이 아니다. AI가 못 풀어서 내가 디버깅한 부분, 내가 설계를 바꾼 부분, 내가 테스트를 추가한 부분 — 그게 진짜 학습이다.

"AI로 빠르게 만들되, 어디서 AI가 틀렸는지 일지를 써라." 이 한 줄이면 과제 설계의 핵심이 요약된다.

3단계: AI Open-Source Capstone

마지막 단계는 거의 인턴십이다. 실제 오픈소스 프로젝트에 배정되고, 이슈를 선택하고, Claude Code로 구현하고, PR을 내고, 머지시킨다. 주간 스프린트 리포트를 쓰고, 메인테이너와 소통한다.

최종 산출물? 포트폴리오에 넣을 수 있는 실제 오픈소스 기여 이력.

★ 강조 과제: 실전 오픈소스 기여

토이 프로젝트가 아니다. Todo 앱이 아니다. 실제 사용자가 있는, 실제 메인테이너가 리뷰하는, 실제로 머지되는 PR. 이게 부트캠프 졸업 요건이라는 거다.

2025년 가을 파일럿에 참여한 학생의 말이 인상적이다.

"Claude Code was instrumental in my learning process, especially since I came into the project with very little experience in the programming languages used in the repository [including TypeScript and Node.js]."

Claude Code는 제 학습 과정에서 핵심적인 역할을 했습니다. 특히 저는 해당 레포지토리에서 사용하는 프로그래밍 언어(TypeScript, Node.js 포함)에 대한 경험이 거의 없었기 때문입니다.

— Laney Hood, CodePath student and computer science major at Texas Tech University

TypeScript와 Node.js 경험이 거의 없었는데, Claude Code 덕에 실제 오픈소스 프로젝트에 기여할 수 있었다고. AI가 진입 장벽을 낮춰주고, 그 위에서 실제 학습이 일어난 케이스다.

Anthropic이 바라보는 AI Native Engineer

커리큘럼을 다 보고 나면 패턴이 보인다. Anthropic이 원하는 엔지니어상이 네 가지 키워드로 수렴한다.

비판적 코드 평가. "AI가 맞다고 가정하지 마라"는 전체 커리큘럼의 첫 번째 원칙이다. GPT-6이 나오고, Claude Opus 5가 나와도 마찬가지다. 99%는 맞는다. 근데 나머지 1%가 프로덕션에서 장애를 만든다. 그 1%를 잡아내는 게 사람의 몫이다.

대규모 코드베이스 이해. AI가 코드를 빠르게 짜주는 시대에, 읽기 능력의 가치는 오히려 올라간다. 이상하게 들리지만 사실이다. 생산 속도가 빨라질수록, 검토해야 할 코드의 양도 같이 늘어난다. 코드를 읽지 않는 것과 읽지 못하는 것은 다르다. 전자는 선택이고, 후자는 한계다.

프로덕션 레벨 관심사. "동작하는 코드"와 "프로덕션에 올릴 수 있는 코드"는 다르다. AI가 만든 코드는 대부분 "동작은 하는" 수준이다. 에러 핸들링, 로깅, 보안, 성능 — 이걸 붙이는 건 사람의 판단이다. 1단계 7주차에 이미 가드레일을 가르치는 이유가 여기 있다.

실전 기여 능력. 토이 프로젝트가 아니라 실제 오픈소스. 메인테이너의 리뷰를 받고, 실제로 머지되는 PR. 이게 졸업 요건이라는 건 단순한 과제 설계가 아니다. 실전에서 검증받은 경험을 갖고 나오라는 거다.

그리고 이 네 가지 모두 같은 전제를 깔고 있다.

인풋이 없으면 비판적 읽기가 불가능하다.

자료구조를 모르면 AI가 짠 정렬 알고리즘의 버그를 찾을 수 없다. HTTP를 모르면 AI가 만든 API의 에러 핸들링이 적절한지 판단할 수 없다. 기초가 곧 비판적 사고의 재료다.

그리고 이건 면접에서도 이미 반영되고 있다. CodePath에 따르면, 고용주들은 점점 더 "AI가 생성한 코드를 해석하고, 리뷰하고, 설명하는 능력"을 면접에서 묻기 시작했다. AI 코드 리뷰 능력이 면접 질문이 되는 시대. 커리큘럼이 그걸 준비시키는 거다.

세계는 지금 어떻게 가르치고 있는가

CodePath만 움직이는 게 아니다. 미국 대학들이 AI 시대에 맞춰 커리큘럼을 뜯어고치고 있다. 그 방향이 제각각인데, 그게 오히려 흥미롭다. 아직 아무도 정답을 모른다는 뜻이니까.

Stanford — 같은 학교, 세 갈래 실험

Stanford가 가장 극적이다. 같은 학교 안에서 두 가지 정반대의 접근이 동시에 돌아가고 있다.

CS106A (Programming Methodology, 프로그래밍 입문) — AI 사용 금지. "우리는 AI로 과제를 풀지 않길 원합니다"라고 실라버스에 명시했다. 프로그래밍의 기초 사고력을 AI 없이 직접 키워야 한다는 입장이다. 입문자에게 AI를 허용하면 사고 과정 자체가 형성되지 않는다고 본 거다.

CS146S (The Modern Software Developer, AI 시대의 소프트웨어 개발) — 정반대. AI를 전면 도입한 신규 과목이다. 강사가 Mihail Eric. 에이전틱 엔지니어링을 주제로 한 이전 글에서도 인용한 인물이다. 그가 Stanford에서 이걸 직접 가르치고 있다.

CS146S의 10주 커리큘럼을 보면 CodePath와 겹치는 지점이 많으면서도 결이 다르다.

Week 1-2: LLM의 역학, 프롬프트 엔지니어링, 에이전트 아키텍처(MCP)
Week 3-5: AI IDE 활용, 터미널 자동화, 컨텍스트 관리 — 도구를 다루는 기술
Week 6-7: AI 기반 테스팅, 취약점 탐지, 디버깅, 코드 리뷰 — 검증하는 기술
Week 8-9: 자동 UI 빌딩, 모니터링, 인시던트 대응 — 프로덕션 관심사
Week 10: 소프트웨어 엔지니어의 진화하는 역할

게스트 강연진도 눈에 띈다. Cognition의 Russell Kaplan, Warp의 Zach Lloyd, a16z의 Martin Casado. 실리콘밸리 현업이 직접 와서 현장의 변화를 전달한다.

Mihail Eric의 핵심 메시지는 이거다.

"Human-agent engineering, not vibe coding." 바이브 코딩이 아니라, 인간-에이전트 엔지니어링이다.

"LLMs are only as good as you are." LLM은 당신만큼만 똑똑하다.

"개발자는 AI 에이전트 인턴의 매니저"라는 비유도 쓴다. AI가 일을 하되, 방향을 잡고 검수하는 건 사람이라는 거다. 과제도 GitHub에 공개되어 있다. 실제로 뜯어보면 꽤 흥미롭다.

Week 1: 로컬 LLM(Ollama)으로 K-shot, Chain-of-Thought, Tool calling, RAG, Reflexion 등 6가지 프롬프팅 기법을 직접 실습한다. API 호출이 아니라 로컬에서 돌린다.
Week 2: FastAPI+SQLite 앱을 Cursor AI IDE로 확장한다. AI IDE 환경에서 실제 앱을 키워나가는 경험.
Week 3: 외부 API를 감싸는 MCP 서버를 직접 구축한다. Claude Desktop이나 AI IDE와 연동까지.
Week 4: Claude Code로 자동화를 2개 이상 만든다. Slash commands, CLAUDE.md, SubAgents, MCP 서버를 조합해서 개발 워크플로우를 자동화하는 과제다. Anthropic의 Claude Code best practices 문서를 필독 자료로 지정했다.
Week 5: Warp 환경에서 멀티 에이전트 워크플로우. Week 4와 같은 앱을 다른 도구로 해보는 거다.
Week 6: Semgrep으로 보안 취약점을 스캔하고, 최소 3개를 직접 수정한다. AI가 짠 코드의 보안 문제를 사람이 잡는 훈련.
Week 7: 가장 인상적인 과제다. AI 코딩 도구로 1-shot 프롬프트로 기능을 구현하고 → 직접 라인 바이 라인으로 수동 리뷰하고 → Graphite Diamond로 AI 코드 리뷰를 돌린 다음 → 내 리뷰와 AI 리뷰를 비교 분석하는 write-up을 쓴다.
Week 8: 같은 앱을 3개의 다른 기술 스택으로 만든다. 하나는 bolt.new(AI 앱 생성 플랫폼)를 필수로 쓴다.

CodePath와 비교하면 결이 확 다르다. CS146S는 도구 중심이다. Cursor, Claude Code, Warp, Graphite, Semgrep, bolt.new — 현업에서 쓰는 AI 도구를 매주 갈아타면서 직접 다룬다. CodePath는 사고력 중심이다. "AI가 짠 정렬 알고리즘 5개 중 틀린 것 찾기", "AI가 못 풀어서 내가 직접 한 부분 기록" — 도구보다 판단력에 집중한다.

둘 다 "AI 코드를 사람이 검증한다"는 전제는 같다. CS146S Week 7의 "수동 리뷰 vs AI 리뷰 비교"와 CodePath의 "AI 코드 비판적 평가"는 같은 목적지를 다른 경로로 가는 거다.

같은 Stanford에서 두 갈래. 어느 쪽이 맞는 건 아니다. 학생의 레벨에 따라, 목적에 따라 다른 접근이 필요하다는 걸 Stanford가 실험으로 보여주고 있다.

UW Allen School — "Coding is Dead" 선언

2025년 7월, 워싱턴대(UW) CS학과장 Magdalena Balazinska가 공식적으로 이렇게 말했다.

"Coding — that is, translating a precise design to software instructions — is dead. AI now does that." 코딩, 즉 정밀한 설계를 소프트웨어 명령으로 변환하는 것은 죽었다. AI가 이제 그걸 한다.

자극적인 말이지만 맥락이 있다. UW는 과제에 GPT 도구 사용을 허용하되, AI를 동료 학생을 인용하는 것과 같은 수준으로 협업자로 인용하도록 요구한다. "AI를 썼으면 어떻게 썼는지 밝혀라." 금지가 아니라 투명한 활용이다.

CodePath의 "AI가 못 풀어서 내가 직접 한 부분을 기록하라"와 비슷한 철학이다. AI 사용을 전제하되, 그 과정을 기록하고 성찰하게 한다.

UMD — Claude Code를 수업에 도입

메릴랜드대(UMD)는 더 직접적이다. William Pugh 교수가 CMSC 398Z "Effective use of AI Coding Assistants and Agents"라는 과목을 2025년 가을에 개설했다. Copilot, VSCode, Claude Code 같은 CLI 도구를 수업에서 직접 실습한다. 빌드 시스템 자동 호출, 테스트 실행, 에러 수정까지 에이전트를 활용한다.

Pugh 교수의 코멘트가 인상적이다. "장기적으로 학부 CS 커리큘럼 전체를 AI 코딩 도구의 존재에 맞춰 업데이트할 계획이다." 한 과목이 아니라 전체 커리큘럼을 바꾸겠다는 거다.

Harvard CS50 — 가장 보수적인 접근

반대편 끝에는 Harvard가 있다. CS50은 자체 AI 러버덕(CS50.ai)을 구축해서 수업에 통합했다. AI를 교육 도구로 쓰는 거다. 근데 일반 과제에서는 외부 AI(ChatGPT, Copilot 등) 사용을 금지한다. 파이널 프로젝트에서만 허용하되 "본질은 본인 것이어야 한다"는 조건을 건다.

"AI 코딩 도구 활용법"을 직접 가르치진 않는다. AI는 학습을 돕는 도구일 뿐, 학습의 주체는 학생이라는 입장이다.

UC San Diego + Google — 글로벌 컨소시엄

UC San Diego는 Google.org의 180만 달러 지원을 받아 GenAI in CS Education Consortium을 출범했다. University of Toronto와 공동 운영하며, 6개의 턴키 코스를 개발하고 있다. "업계가 이제 신입 엔지니어에게 AI 도구 유창성을 기대한다"는 게 출발점이다.

Andrew Ng — "Product Engineer의 황금기"

이 흐름을 가장 명확하게 정리한 사람이 Andrew Ng이다. Stanford CS230 Autumn 2025 Lecture 9: Career Advice in AI 강의에서 그가 한 말들이 인상적이다.

Ng은 지금이 AI로 무언가를 만드는 사람에게 **"역사상 최고의 시기"**라고 말했다. AI가 처리할 수 있는 태스크의 복잡도가 7개월마다 두 배가 된다는 연구를 인용하면서.

근데 그가 강조한 건 코딩 속도가 아니었다. 병목이 바뀌었다는 거다. 코드를 짜는 속도가 AI 덕에 폭발적으로 빨라지면서, 진짜 병목은 "무엇을 만들지 결정하는 것"으로 옮겨갔다. 실리콘밸리에서 PM(프로덕트 매니저)과 엔지니어의 비율이 전통적으로 1:4~8이었는데, 지금은 1:1로 수렴하거나 아예 역할이 합쳐지는 추세라고 했다.

코드를 짤 수 있는 건 더 이상 차별화 요소가 아니다. 사용자와 대화하고, 공감하고, 무엇을 만들지 결정할 수 있는 엔지니어가 가장 가치 있는 인재가 됐다.

게스트 강연자 Laurence Moroney(Arm AI Director)는 더 직설적이었다. 세 가지 생존 조건을 제시했다.

깊이 있는 이해(Understanding in Depth) — 하이레벨 API만 쓸 줄 아는 게 아니라, 그 밑에서 뭐가 돌아가는지 이해해야 한다.
비즈니스 포커스 — "쿨한 것"을 만드는 시대는 끝났다. 비즈니스 가치와 직결되는 것을 만들어야 한다.
딜리버리에 대한 집착 — 아이디어는 싸다. 실제로 프로덕션 레벨로 배포할 수 있는 능력이 차별화다.

Moroney는 바이브 코딩이 만드는 "기술 부채"도 경고했다. LLM으로 앱 전체를 생성할 수 있지만, 그렇게 만든 코드는 거대한 기술 부채를 안고 있다고.

Ng이 학생들에게 던진 마지막 조언도 기억에 남는다. "회사 브랜드가 아니라 팀을 보고 선택하라." 유명한 AI 회사에 들어갔는데 백엔드 결제 시스템 Java 팀에 배치된 학생 사례를 들면서, 작지만 좋은 팀에서 배우는 게 화려한 로고보다 낫다고 했다.

기초의 재정의 — 사고력은 AI가 대신 키워주지 않는다

카네기멜론 수학 교수 포쉔로(Po-Shen Loh)가 한 말이 있다.

"Using AI to do your writing homework is the same as driving a car instead of running a mile for exercise." AI로 글쓰기 숙제를 대신하는 건, 운동 대신 차를 타는 것과 같다.

몸은 목적지에 도착한다. 하지만 체력은 키워지지 않는다.

포쉔로는 이제 교육이 바뀌어야 한다고 말한다. 숙제를 "하는 법"이 아니라 "채점하는 법"을 가르쳐야 한다고. CodePath 커리큘럼이 1주차부터 AI 코드 오류를 찾게 하는 이유가 정확히 이거다. AI가 짠 것을 채점하려면, 먼저 정답이 뭔지 알아야 한다.

그가 말한 또 하나의 키워드가 있다. "세상을 시뮬레이션하는 능력." 공감과 다양한 경험을 바탕으로, 아직 일어나지 않은 미래를 머릿속에서 전개하는 힘. 이건 AI가 가져갈 수 없는 인간의 영역이다. AI는 과거 데이터로 패턴을 찾는다. 시뮬레이션은 사람이 한다.

Stanford CS106A가 AI를 금지하고, CS146S가 AI를 쓰면서도 "바이브 코딩이 아니라 인간-에이전트 엔지니어링"이라고 못 박는 이유. Andrew Ng이 "깊이 있는 이해"를 생존 조건 첫 번째로 꼽는 이유. Laurence Moroney가 "하이레벨 API만 쓸 줄 아는 건 부족하다"고 한 이유. 다 같은 곳을 가리킨다.

기초 없이 AI만 쓰면 공중에 뜬다.

이미 할 줄 안다면 10x, 100x로

솔직히 말하면, 나는 AI의 수혜를 가장 크게 받는 사람 중 하나다.

지난 두 달, 1847커밋을 찍었다. 혼자서 백엔드, iOS, 웹, 인프라를 동시에 굴렸다. TDD로 짜고, 아키텍처를 설계하면서. 이전에 같은 걸 혼자 하려면 몇 배의 시간이 걸렸을 거다. 코드 작성 속도만이 아니라, 커버할 수 있는 영역의 폭 자체가 달라졌다.

10배는 됐다. 어쩌면 그 이상.

근데 여전히 사람 손이 가는 게 있다. 무엇을 만들지 결정하는 것. 어떻게 만들지 설계하는 것. 최종 결과물이 괜찮은지 검증하는 책임. AI는 내가 지시한 대로 만든다. "뭘 지시할지"는 내가 안다.

Andrew Ng이 말한 "병목이 구현에서 결정으로 옮겨갔다" 는 게 정확히 이 경험이다. 만드는 건 빠르다. 뭘 만들지, 어디까지 만들지, 이게 정말 필요한 건지 — 그 판단이 병목이다.

기초가 있는 사람은 AI와 함께 10배, 100배 간다. 기초가 없는 사람은 AI가 틀린 것도 모르고 넘어간다. 두 사람이 같은 AI를 써도 결과물이 다른 이유다.

멘토링 경험 — AI 대화록을 리뷰하다

올해부터 멘토링 방식을 바꿨다. 멘티들의 코드가 아니라 AI 대화록을 공유받기 시작했다. 165개 대화를 분석해서 5가지 기준 프레임워크를 만들었다. 질문의 깊이, 맥락 제공 수준, 자기 가설 포함 여부, 검증 요청 방식, 후속 질문의 연결성.

존(가명) 이야기를 해야겠다. 꽤 오랜시간 프로그래밍을 해왔지만(존은 비전공자이다.) 프로그래밍 실력이 몇 달째 제자리였다. AI 대화록을 보니 이유가 바로 보였다.

"이거 어떻게 해?"
"코드 짜줘."
"무슨 말인지 모르겠다."

AI는 답을 준다. 존은 그걸 복사한다. 생각을 하지 않는다. 학습이 일어나지 않는다.

반면 같은 시기에 빠르게 성장한 멘티의 대화록은 달랐다.

"트랜잭션이란 건 모두 성공 또는 모두 실패인데, @Async는 다른 쓰레드를 사용하니까 트랜잭션 범위를 벗어나는 것 같은데, 이 가설이 맞나요?"

자기 가설을 세우고, AI한테 검증을 요청한다. AI가 답을 주더라도 그 답을 자기 이해 안에 통합한다.

CodePath 커리큘럼이 영리한 건 이 문제를 구조적으로 해결한다는 거다. "AI가 짠 정렬 알고리즘 5개 중 틀린 것 찾기" — 이 과제는 자기 가설 없이 불가능하다. '이 알고리즘은 이렇게 동작해야 해'라는 기준이 머릿속에 있어야, 틀린 걸 찾을 수 있다. 커리큘럼이 억지로 비판적 사고를 유도하는 구조다.

커리큘럼에 대한 추가 코멘트

얼마 전에는 스탠포드에서 더이상 프로그래밍 언어를 가르치지 않는다는 가짜 뉴스로 SNS에서 호들갑이 있었다. AI가 확실히 발전했으니 그럴법도 하다. 그런데 재밌는건 원래 CS 커리큘럼에서 프로그래밍 언어 문법을 가르치지 않는다. 내가 지난 학기 프로그래밍 입문을 파이썬으로 배워도 그건 프로그래밍 원리와 사고력, 문제 해결력을 배우는 과목이지 파이썬 문법을 배우는 과목이 아니다. 다음 학기 자료 구조 수업을 수강하는데 언어가 자바라면 수강 전에 열심히 기본 문법 정도는 독학을 해서 가야한다.

미국 대학에서 교육을 어떻게 하는가? 사이언스 아담 채널에 한글 더빙으로 올라온 하버드 CS 입문 교육이 있으니 한번 들어보길 권한다. 단순히 커리큘럼으로 설명되지 않는 강의의 퀄리티를 느낄 수 있을 것이다. (모든 교육 과정은 공개되어 있으니 공부를 해보는 것도 좋다.)

하버드 CS50 교수 David Malan의 실제 강의를 보면 이 철학이 명확해진다. 첫 수업에서 그는 이렇게 말한다. "AI가 코딩을 다 해주는 시대인데 왜 배우냐고? 이 수업은 단 한 번도 코딩 기술을 가르치는 수업이었던 적이 없다. 생각하는 방법을 가르치는 수업이다."

Malan은 GitHub Copilot으로 학생들이 15시간 걸려 짠 C언어 과제(해시 테이블 기반 맞춤법 검사기)를 수초 만에 생성해 보인다. 그리고 묻는다. "이걸 보고 15시간이 헛됐다고 생각하나요?" 답은 아니다. 15시간 동안 고생하며 쌓은 "코드를 볼 줄 아는 눈"이 없으면 AI의 환각 — 존재하지 않는 라이브러리를 자신 있게 사용하는 코드, 문법은 완벽한데 논리가 틀린 코드 — 을 구별할 수 없다.

CS50이 2023년부터 도입한 AI 러버덕도 같은 원리다. GPT 기반이지만 정답을 직접 알려주지 않는다. 시스템 프롬프트로 "소크라테스처럼 학생이 스스로 깨우치도록 유도하라"고 설정했다. AI를 학습 도구로 쓰되, 사고 과정은 학생이 직접 거치게 만드는 거다.

Malan이 강의 마지막에 한 말이 기억에 남는다. "세미콜론 전문가(벽돌)에서 시스템 설계자(건축가)로 진화하라." AI가 벽돌을 쌓아주는 시대에, 건축가의 눈을 가진 사람만이 AI를 도구로 쓸 수 있다. 그 눈은 기초를 직접 쌓아본 사람에게만 생긴다.

이게 CodePath 커리큘럼이 1주차부터 "AI가 짠 코드에서 버그를 찾아라"로 시작하는 이유이기도 하다. 벽돌을 쌓아본 사람만이 잘못 쌓인 벽돌을 알아본다.

아쉬운 점 — 커리큘럼이 안 가르쳐주는 것

커리큘럼이 좋다고 해서 다 있는 건 아니다. 솔직히 빠진 게 보인다.

설계와 아키텍처 사고. 이건 교육으로 단기간에 심기 어렵다. 수십 번 잘못된 설계를 경험하고, 그게 왜 잘못됐는지 사후에 분석하는 과정이 필요하다. 커리큘럼은 구현 중심이다. 설계의 실패와 반성을 체계적으로 가르치지는 않는다.

프랑켄슈타인 함정. AI 시대의 새로운 위험이다. 코드 생산 속도가 빨라지니까, 불필요한 기능까지 다 만들게 된다. '어차피 빠르게 만들 수 있으니까'라는 생각으로. 결과물이 뾰족한 솔루션이 아니라 괴물이 된다. 기능은 많은데 정작 뭘 하는 제품인지 모르겠는 상태.

"무엇을 안 만들지"가 더 중요한 판단이다. 근데 AI는 그 판단을 해주지 않는다. 시키는 대로 만든다. Laurence Moroney가 경고한 "바이브 코딩의 기술 부채"도 같은 맥락이다. 빠르게 만들 수 있다는 건 빠르게 망가뜨릴 수도 있다는 뜻이다.

AI는 내 생각을 편향시킨다. 이건 개인적으로 경험한 함정이다. AI한테 물어보면 내 방향과 비슷한 답이 나온다. 내가 이미 생각하는 걸 정교하게 다듬어준다. 다른 관점이 보이지 않는다. 실제 사용자의 피드백, 타인의 객관적인 시각이 없으면 에코 챔버에 갇힌다. AI 시대에 다양한 피드백 루프가 더 중요해진 이유다.

팀 협업과 커뮤니케이션. Git 협업을 9주차에 가르치는 건 좋다. 근데 "무엇을 만들지"를 결정하는 과정, 팀 안에서 의견을 조율하고 방향을 맞추는 능력 — 이건 커리큘럼에서 명시적으로 다루지 않는다. Andrew Ng이 말한 것처럼 PM과 엔지니어의 역할이 합쳐지는 추세라면, 사용자와 대화하고 공감하는 능력이 코딩보다 더 중요해진다. AI가 코드를 짜줘도, 방향을 결정하는 과정은 사람들 사이에서 일어난다.

도메인에 대한 관심. 의료, 법률, 교육, 금융 — 도메인 전문가가 AI와 결합했을 때 임팩트가 가장 크다. 코딩을 잘 아는 사람보다, 도메인을 깊이 아는 사람이 AI를 써서 무언가를 만들 때 더 날카로운 결과가 나온다. 커리큘럼은 AI 엔지니어링 기술에 집중하느라 도메인 사고를 기르는 부분이 빠져 있다.

한국 부트캠프와의 비교. 국내 N주 부트캠프는 대부분 "기초 문법 → 미니 프로젝트 → 팀 프로젝트 → 포트폴리오" 구조에서 벗어나지 못한다. CodePath 커리큘럼과 가장 큰 차이는 기존 코드베이스와의 접점이다. 1만 줄짜리 오픈소스 프로젝트를 받아서 파악하고, 거기에 PR을 넣는 경험. 이게 실무와 가장 가까운 훈련이다.

나가며

채용 시장이 어려워지는 건 여러 이유가 있지만 결국 AI Native Engineer 는 이제 이전의 소프트웨어 엔지니어와는 다른 자질을 요구하기 때문이다. "코드 작성 능력"이라는 해자가 사라졌기 때문에 "코드 작성 능력" 은 이제 경제적 가치가 없어졌다. 신입보다 시니어를 선호하는 것도 시니어들의 "코드 작성 능력"이 뛰어나서가 아니다. 그들의 도메인 독해 능력, 비즈니스 모델에 대한 이해, 사용자 요구 사항을 적정기술로 풀어내는 그들의 경험이 AI와 함께 증폭이 되는 것이다. 이러한 경험을 통한 "암묵지"는 쉽게 얻어지는게 아니다. 그렇기 때문에 이 커리큘럼의 오픈소스 PR 기여는 그 간극을 메우는 그나마 그 "암묵지" 모델에 가까운 과제가 아닌가 싶다.

그럼에도 불구하고 기초는 중요하다. 순서가 중요하다. 기초가 먼저다. AI는 그 위에 올라탄다. 기초가 없으면 AI는 날개가 아니라 무게가 된다. 빠르게 만들 수 있지만, 뭘 만드는지, 잘 만드는지 알 수가 없다. 인간의 사전 학습(기초, 경험)이 AI 활용 능력을 증폭시킨다는 건 Claude Code를 직접 만드는 Anthropic이 어쩌면 더 뼈저리게 느끼고 있는 부분이 아닐까.

AI 모델도 사전 학습량과 파라미터로 성능이 달라지듯이, 인간도 사전 학습에 따라서 성능이 천차만별일 것이다.

AI 시대에 진입 장벽은 낮아졌다. 확실히. 코딩을 전혀 모르는 사람도 뭔가를 만들어낼 수 있다. 근데 천장은 오히려 높아졌다. AI를 잘 쓰는 사람과 못 쓰는 사람의 격차가 이전의 "코딩 잘하는 사람 vs 못하는 사람"보다 훨씬 크다.

CodePath 커리큘럼이 가는 방향이 맞을까? 세상이 너무 빨리 변하고 있기 때문에, 커리큘럼은 계속 변할 것이다. 하지만 AI를 맹신하지 않는 훈련, 기존 코드베이스를 읽고 통합하는 훈련, 실전에 기여하는 훈련. 이 세 가지는 AI 시대에도, AI 이후에도 변하지 않는다.

그리고 이전 시대에도 일을 잘하는 사람이 AI 시대에도 일을 잘한다는 명제는 모두가 동의할 것이다.

References

2026년 1, 2월을 보내며 - 회고 아님

Tony Cho (https://flowkater.io) — Mon, 02 Mar 2026 09:00:00 GMT

2025년은 나에게 안식년이었다. 특히 퇴사하고 4월 한 달간의 이탈리아 여행은 쉼 없이 일했던 나에게(그리고 옆에서 묵묵히 곁을 지켜주던 Ellie에게) 큰 위로가 되는 여행이었다. 비가 개면서 반짝이던 베네치아, 피렌체의 전경과 선셋, 아말피 남부해안의 별빛이 반짝이던 밤. 다년간 날 괴롭히던 사업의 빚도 없고 돌아가서 출근할 회사도 없던 나에게 그 순간들은 충분히 충실했다. 시끄럽고 혼란했던 매연 냄새 가득한 나폴리의 거리나 너무 많은 관광객이 북적이던 로마에 지쳐 귀국하는 그 순간까지 우리는 여행에 충실했다.

이탈리아 귀국 이후 2025년은 정말 빠르게 흘렀다. 다시 24시간 같이 붙어 있게 된 Ellie와 정말 많이 싸우고 화해하고 얼싸안았다. 기뻐하다 울다 잠들었다. 게으르다 자책하고, 다시 깨어 일어서서 밖으로 나가는 그런 하루들이 반복되었다.

솔직히 초반에 Ellie와 보냈던 시간들은 생각보다 힘겨웠다. 나는 CTO의 권위와 삶, 출근하는 시스템에 이미 익숙해 있었고 사회에서의 나와 가정에서의 나는 어느 정도 분리되어 있었다. 그 시간들이 하나로 합쳐지며 생기는 혼란, 그리고 그렇게 혐오하던 안티패턴을 가진 리더들의 습관들이 이미 나에게 절여져 있었다. Ellie는 내 직원이 아니었고 파트너였기에 의견을 조율하고 일을 진행하는 데 있어서 나는 어려움을 겪었고 내가 생각하기에 내가 가장 혐오하는 모델을 내가 행동으로 구현하고 있는 것을 발견했다.

이전 회사를 나오며 반복되던 자기 연민과 자기 혐오는, 승리하지 못하는 조직은 어떻게 무너지는가라는 글로 정리해서 내보내기 전까지 계속됐다. 안식만을 가져도 충분했을 시기에 나를 충분히 괴롭게 하였다. 나혼자 어둠에 빠져 허우적대고 그럴 때마다 Ellie에게도 많은 상처가 되는 말을 했는데 항상 그렇게 싸우고 나서도 언제나 나를 포용해주는 그녀에게 보답하기 위해 나는 오늘도 밥을 차리고 수건을 개고 분리수거를 한다. (하지만 여전히 집안일 비율은 그녀가 압도적으로 많다.)

막상 너무나 빨리 지나버린 그 시간을 돌아보니 이렇게 할 걸 저렇게 할 걸이라는 아쉬움이 문득 커지지만 퇴사 직후 망가진 몸과 마음이 자연스럽게 회복하는 데에는 으레 그렇듯 또 그 정도의 시간이 필요했을 것이다.

원래는 무엇을 했고, 어떤 걸 했으며 어떻게 열심히(?) 살고 있는지에 대한 회고를 작성하려고 했으나 사실 딱히 이렇게 쓰는 나의 회고가 크게 무슨 효용이 있나 싶다. 이전 에세이들처럼 시대를 사유(?)하는 글들도 아닌 지극히 개인의 것인데. 나에게 글쓰기는 일종의 힐링이니 이 글을 통해서도 그 목적이라도 달성하면 되겠지 싶어 그냥 막 쓰기 시작했다.

11월에 개인 사업자를 내고 일을 하다 말다 하다 말다 하다가 12월부터 본격적으로 일을 시작했고 지난 1월, 2월은 더 이상 루틴에 집착하지 말고, 게으른 나 자신을 탓하지 말고 그저 순간을 즐기며 흘러가는 대로 내가 하고 싶은 걸 하면서 살기 위해 노력했다.

재작년 부상이 있음에도 버티기 위해 격하게 운동을 이어가던 것이 결국 24년 하반기에 쉽게 완치되지 않는 여러 부상으로 이어졌고 1년 가까이 운동도 제대로 못하고 회복도 안 된 상태로 26년을 맞이했지만, 1월부터는 조금씩 다시 페이스를 올려 몸에 무리가 안 되는 선에서 운동도 다시 시작하고 있다.

12월부터 해서 1월, 2월은 많은 글을 쓰기도 했다. 독자라곤 Ellie와 가까운 지인 몇 명이지만 그토록 쓰고 싶었던 소설도 쓰기 시작했다. 그들의 기대에 부응하기 위해 연재를 이어나가야 하는데 쓰면 쓸수록 어렵다. 그리고 블로그 포스트도 그 어느 때보다 많이 작성했다. 평소에 내 안에 쌓아놓았던 여러 감정, 메시지를 글로 엮어보았다. 어떤 글은 아무도 들어오지 않던 내 블로그에 방문자를 폭발적으로 늘리는 글이 되기도 하였다. (그들로 인하여 날 것 그대로의 초안이 약간은 정제하게 되는 게 어쩔 수 없나 보다. 항상 말과 행실을 똑바로하는 Ellie의 충고는 덤.) 글을 쓰다 보니 휴대폰을 내려놓고 책을 더 많이 읽어야겠다 싶어 오닉스 팔마까지 구매해 본격적으로 읽고 있고, 지금까지 올해 3, 4권 정도의 책을 읽었다.

12월부터 시작한 프로젝트는 알파 테스트를 진행하고 있고 언제 어떤 타이밍에 배포를 해야 할까를 고민하면서 고도화를 해나가고 있다. 급속도로 발전한 AI 코딩 에이전트 덕분에 오히려 일하는 시간은 더 늘어났다. Ellie가 자비스랑 텔레그램 한다고 자기랑 안 놀아준다는 얘기가 그저 귀여운 투정은 아닌 것이 정말 책 읽는 시간 제외하고는 거의 하루 종일 휴대폰을 붙잡고 있다. 다만, 이제는 프로젝트가 고도화될수록 결국 사람 손을 타서 한 땀 한 땀 봐줘야 하는 부분이 더 많아지고 있다. (당신의 프로젝트가 무엇이든 정말 AI가 모든걸 하고 있는 상태라면, 거꾸로 의심해봐라. 남들도 다 만들 수 있는걸 만드는 건 아닌지. - 에이전틱 엔지니어링 시대의 생존 스킬 9가지)

작년 여름은 인생 최고로 더웠고 이번 겨울은 인생 최고로 추웠다. 20대 초반부터 항상 사업과 일하느라 바쁘게 쭉 살아왔던 내가 처음으로 정면으로 마주한 계절감은 생각보다 극적이었다. (30대 초까지만 해도 여름이든 겨울이든 집에서는 반바지만 입고 생활하던 나였는데 이제 긴바지에 수면 양말까지 챙기는 모습을 Ellie가 놀리는 건 덤이다.)

그냥 흘려보내기엔 내 마음이 생각보다 괜찮고 또 뭔갈 본격적으로 정리하고 회고하기엔 아직 결과물이 없어서 흘러가는 이 시간을 잠시나마 붙잡아 언젠가 다시 들여다볼 나를 위해 글을 작성한다.

나를 괴롭히던 모든 생각들로부터 오히려 안식의 기간이었던 작년보다 많이 안정되어 올해 다시 집중해서 하루하루를 보내고 있다. 내가 추구하는 가치는 딱 하나이다. 내가 무슨 일을 하든, 지금 이 순간에 머물 수 있으면 난 어떤 값도 치를 수 있다. 과거를 후회하고 미래를 걱정하느라 시간을 낭비하지 않고 내가 하고자 하는 일에 최선을 다하며 지금 이 순간에 집중할 수 있는 인생을 살기를, 그랬으면 좋겠다는 작은 바람을 담아 이 기이한 회고(?)글을 마친다.

에이전틱 엔지니어링 시대의 생존 스킬 9가지

Tony Cho (https://flowkater.io) — Sun, 01 Mar 2026 05:00:00 GMT

들어가며

바이브 코딩이라는 단어를 만든 Karpathy가 X에 트윗했다 — 이제 바이브 코딩과 구분되는 새로운 이름이 필요하다며, 에이전틱 엔지니어링이라는 용어를 제안했다. 나는 작년 4월부터 열심히 바이브 코딩을 했고 특히 지난 2, 3달은 정말 격변의 시기를 겪었다. 내 글 '코드를 읽지 않는 시대, 엔지니어는 무엇을 읽어야 하는가'가 폭발적인 조회수를 기록한 것도 그에 대한 반작용이라고 생각한다.

이 글은 Karpathy의 트윗에서 영감을 받아, 내가 실제로 겪은 시행착오와 Armin Ronacher, Boris Cherny, WenHao Yu, IndyDevDan 같은 실전 사례를 엮어 9가지 핵심 스킬로 정리한 것이다.

9가지 핵심 스킬은 다음과 같다.

분해 능력 (Decomposition)
컨텍스트 설계 (Context Architecture)
완료 정의 (Definition of Done)
실패 복구 (Failure Recovery Loop)
관찰 가능성 (Observability)
메모리 설계 (Memory Architecture)
병렬 관리 (Parallel Orchestration)
추상화 계층 설계 (Abstraction Layering)
감각 (Taste)

흥미롭게도 이 9가지의 스킬은 에이전틱 엔지니어링, 나아가 바이브 코딩 시대 이전에도 일을 잘하는 엔지니어, 그리고 나아가서 일을 잘하는 매니저에게 요구되는 자질들이었다. 왜 그러한지 Karpathy의 이야기로 시작해서 하나씩 살펴보자.

바이브 코딩의 창시자의 주말

Karpathy가 주말에 집 카메라용 대시보드를 만들고 싶었다고 한다. 에이전트에게 DGX Spark의 IP, 사용자명, 비밀번호, 그리고 목표를 줬다. SSH 키 설정부터 vLLM 구성, 모델 다운로드와 벤치마크, 비디오 추론 서버 구축, 웹 UI 대시보드, systemd 서비스 설정, 메모리 노트 기록과 마크다운 리포트 작성까지 — 전부를 한 번에 지시했다. 30분 후 전부 완성됐다.

"I didn't touch anything myself. This was a weekend project just 3 months ago. Now it was 30 minutes of just forgetting about it."

"불과 3개월 전만 해도 주말 전체가 필요한 프로젝트였지만, 이제는 30분 동안 잊고 기다리면 완료되는 작업이 됐다."

Karpathy는 이 새로운 방식에 이름을 붙였다. 에이전틱 엔지니어링(Agentic Engineering).

"'Agentic' because 99% of the time you are no longer writing code directly, you are commanding and supervising agents. 'Engineering' because there is art, science, and skill to it."

"'에이전틱'인 이유는 99%의 경우 더 이상 코드를 직접 작성하지 않고 에이전트에게 명령하고 감독하기 때문이다. '엔지니어링'인 이유는 여기에 기예, 과학, 전문 기술이 있기 때문이다."

프롬프트 몇 줄에 앱이 뚝딱 나오는 시대를 지나, 이제는 에이전트가 잘 작동하는 조건을 설계하는 능력 이 핵심이 됐다.

변화는 빠른데, 실제 적응은 느리다. 대부분의 개발자는 아직 따라잡지 못하고 있다.

그런데 이 변화의 속도가 예사롭지 않다.

"It is hard to put into words how much programming has changed in just the last ~2 months. This was not a 'business as usual' kind of incremental progress."

"지난 약 2개월간 프로그래밍이 얼마나 변했는지 말로 전달하기가 어렵다. 이것은 '늘 있던 방식의 발전'처럼 점진적으로 변한 게 아니다."

개발자 대부분이 AI를 사용하고 있지만, 실제로 에이전트에게 작업을 온전히 위임하는 비율은 여전히 낮다. 2026 Agentic Coding Trends Report에 따르면 개발자의 60%가 AI를 사용하지만 완전 위임은 0-20%에 불과하다 — 이른바 위임 패러독스(Delegation Paradox). AI가 코드를 써주는 건 익숙해졌는데, 에이전트에게 일을 맡기고 손을 떼는 건 전혀 다른 차원의 이야기다.

IndyDevDan은 이 간극을 한 문장으로 요약했다.

"Do you trust your agents?"

"당신은 에이전트를 신뢰하는가?"

대부분의 개발자가 "아니오"라고 답한다. 나도 처음에는 그랬다. 에이전트가 만들어준 코드를 전부 검토했고, 직접 짜는 것보다 더 오래 걸리는 경우도 있었다.

하지만, Karpathy의 사례처럼 에이전틱 엔지니어링 시대에는 이제 모든 게 점점 더 자동화되고 에이전트에게 위임되는 비율이 높아지고 있다. 이 시대에도 훌륭한 엔지니어가 되기 위해서 우리에게 필요한 스킬 또는 자질은 무엇일까?

① 분해 능력 (Decomposition)

에이전트에게 "회원가입 기능 만들어줘"라고 하면 뭔가 나오긴 나온다. 문제는 그게 내가 원하던 게 아닐 확률이 높다는 거다. 이메일 인증은 빠져 있고, 비밀번호 규칙은 내 기준과 다르고, UI는 상상도 못한 방향으로 가 있다.

에이전트에게 일을 시키는 건 결국 "무엇을 만들지"를 정하는 일 이다. 고객이 뭘 원하는지, 유저가 뭘 필요로 하는지, 우선순위가 뭔지 — 이건 내가 정확히 해야 한다. 에이전트가 대신해줄 수 없는 영역이다.

"The key is to develop the intuition to decompose tasks appropriately, delegating to agents where they work well and providing human help where needed."

"핵심은 작업을 적절히 분해하여 잘 작동하는 부분은 에이전트에 위임하고 나머지 부분에서 인간이 도움을 주는 직관을 기르는 것이다."

이게 말은 쉬운데, 실제로 해보면 까다롭다. "잘 작동하는 부분"과 "인간이 도움을 줘야 하는 부분"의 경계가 매번 다르기 때문이다. 어떤 작업은 에이전트가 원샷으로 끝내고, 어떤 작업은 세 번을 돌려도 핵심을 놓친다. 그 차이를 체감으로 익히는 게 분해 능력이다. Karpathy가 분해의 조건도 꽤 명확하게 짚어줬다.

"It works especially well in some scenarios, especially where the task is well-specified and the functionality can be verified/tested."

"일부 시나리오에서 특히 잘 작동하며, 특히 작업 명세가 명확하고 기능을 검증·테스트할 수 있는 경우에 효과적이다."

뒤집어 말하면, 명세가 모호하고 검증 기준이 없는 작업에서는 에이전트도 헤맨다. 내가 할 일은 모호한 요구사항을 명확한 작업 단위로 바꿔주는 것이다.

이전에 Claude Code로 TDD 워크플로우를 구축하면서 느낀 건, 원샷으로 70-80%는 구현되지만 나머지 20%가 진짜 일이라는 거였다. 초기 요구사항을 얼마나 잘 정의했느냐에 따라 그 20%의 크기가 극적으로 달라진다.

WenHao Yu의 Opus 4.6 멀티에이전트 워크플로우에서도 이 패턴이 보인다. 그는 큰 프로젝트를 AI Team Lead에게 맡기는데, Team Lead가 하는 일의 70%가 사실 작업 분해다. "이 기능을 구현하려면 어떤 하위 태스크가 필요한가?"를 먼저 설계하고, 각 태스크를 서로 다른 에이전트에게 위임한다. 분해가 잘 되면 나머지는 자연스럽게 따라온다. 분해가 잘못되면 모든 에이전트가 삽질을 한다.

이 "분해가 잘못되면 모든 에이전트가 삽질한다"는 경험을 직접 해봤다. 한번은 "설정 페이지 만들어줘"라는 하나의 태스크를 에이전트에게 던졌는데, 설정 페이지 안에 프로필 수정, 알림 설정, 구독 관리, 데이터 내보내기가 다 들어 있었다. 에이전트가 이 네 가지를 한 번에 만들려다 보니 각각의 상태 관리가 꼬였다. 알림 설정을 바꾸면 프로필 폼이 리셋되고, 구독 관리에서 에러가 나면 전체 페이지가 깨졌다. 결국 네 개의 독립된 태스크로 쪼갠 뒤 각각 에이전트에게 맡기니 한 번에 됐다. "설정 페이지"가 아니라 "프로필 수정 폼", "알림 토글 컴포넌트", "구독 관리 패널", "데이터 내보내기 버튼" — 이렇게 네 조각으로.

Before: AddPlan 화면, 인터뷰 없이 던진 결과

계획 생성 화면(AddPlanView)을 만들어야 했다. 5단계 입력 플로우 — 이름 입력, 분량 설정, 기간 선택, 요일 지정, 요약 확인. 피그마 디자인이 있었고, 기획안(PRD)도 작성해서 제공했다. "이 정도면 에이전트가 한 번에 만들겠지."

그게 안일한 기대였다.

에이전트가 첫 버전을 내놨는데, 얼핏 보면 구조는 맞았다. 그런데 디테일에서 계속 어긋났다. 디자인 시스템에 정의되지 않은 컬러와 폰트를 마음대로 가져다 쓰고 있었다. Step2 분량 설정의 CustomNumberPad 레이아웃이 피그마와 다르다. 수정했더니 Step3 기간 선택 캘린더가 깨졌다. 한 번 수정할 때마다 다른 Step이 밀려났다. 세 번째 반복쯤 "이거 그냥 내가 짜는 게 낫지 않나" 싶었다.

문제의 원인은 명확했다. 내가 뭘 원하는지 나 자신도 정확히 정리하지 않은 상태에서 시작한 거다. PRD가 있었지만, "CustomNumberPad의 키 간격과 반응 영역", "Step 전환 애니메이션의 방향과 타이밍", "유효성 검사 실패 시 에러 표시 방식" 같은 디테일은 내 머릿속에만 있었다. 에이전트는 내 머릿속을 읽을 수 없으니, 매번 자기 나름의 선택을 했고, 매번 내 기대와 어긋났다. 결국 에이전트와 핑퐁만 수십 턴, 거의 반나절을 날렸다.

After: 소크라틱 대화로 요구사항 구체화

그 다음부터 나는 기능을 구현하기 전에 AI와 인터뷰를 하기 시작했다. Superpowers 같은 프레임워크가 이걸 자동으로 해주기도 하는데, 핵심은 같다 — "내가 뭘 원하는지"를 먼저 명확하게 만드는 과정이다. 소크라틱 대화라고 할까. AI가 질문을 던지고, 내가 답하면서, 요구사항이 구체화된다.

AddPlan을 다시 시도할 때 이 방식을 적용했다. "5단계 입력 플로우를 만들려는데요." → AI: "각 단계의 입력 필드와 유효성 검사는?" → "Step1은 이름 입력, 빈 문자열 불가, 최대 50자." → AI: "디자인 시스템 컬러를 쓰나요? 커스텀 컬러는?" → "디자인 시스템 컬러만. 강조색은 #FF6B35." → AI: "Step 간 전환 애니메이션은? 유효성 실패 시 UX는?" → "슬라이드, 인라인 에러 메시지로."

5분이다. 이 대화에 걸린 시간이. 그런데 이 5분 동안 나온 엣지 케이스가, 지난번에 반나절 핑퐁 치면서 하나씩 발견한 것들과 거의 동일했다. 차이라면, 지난번에는 "코드를 짠 다음에" 발견했고, 이번에는 "코드를 짜기 전에" 정리됐다는 거다.

이렇게 정리된 요구사항을 에이전트에게 던지니 원샷 퀄리티가 확실히 달랐다. Step별로 분리해서 지시하고, 각 Step의 스펙을 명확히 적어주니 수정 턴이 2-3회로 줄었다. 그 수정도 디자인 미세조정 수준이었지 구조적 변경이 아니었다. 인터뷰 5분이 핑퐁 반나절을 아낀 셈이다. 그 다음부터는 기능 인터뷰가 내 워크플로우의 기본 단계가 됐다. 모든 기능 구현은 "인터뷰 → 스펙 정리 → 에이전트 지시" 순서로 진행한다.

바이브 코딩과 함께 SDD(스펙주도개발)이 유행하면서 PRD만 제대로 작성하면 제대로 개발할 수 있다고들 말한다. 맞는 말이다. 하지만 스펙을 어떻게 분해할지는 결국 우리 손에 달렸다.

이렇게 연습한다

엔지니어뿐만 아니라 일을 잘하는 사람들은 기본적으로 커다란 작업을 잘 분해하고 단계별로 선택과 집중을 하여 일의 몰입을 유지한다. 반대로 일을 못하는 사람들은 커다란 작업을 계획하지 않고 덤벼들어 이리저리 핑퐁하다가 결국 일정 딜레이가 발생한다. (맞다. 내가 본 많은 개발자들이 그랬다.)

마무리 단계에서 코딩 에이전트와 핑퐁이 길어지고 있다면, 내가 지금 작업 단위를 제대로 분해하고 있는지 돌아볼 필요가 있다.

구현 전에 요구사항 문서를 먼저 작성하는 습관이 첫걸음이다. 거창할 필요 없다. "이 기능은 무엇을 하고, 완성 기준이 뭔지"를 텍스트로 적어보는 것만으로도 빈틈이 보인다. 나는 요즘 모든 기능 구현 전에 간단한 requirements.md를 먼저 만든다. (스펙 문서 아님)

AI와 인터뷰하는 방식도 일상에 녹여넣을 만하다. 처음에는 좀 어색하다. AI한테 질문을 받는다는 게. 그런데 몇 번 해보면 내가 놓치던 엣지 케이스를 AI가 먼저 짚어주는 경험을 하게 된다. 특히 인증, 결제, 파일 업로드처럼 상태가 많은 기능에서 효과가 크다. Superpowers 같은 프레임워크를 쓰든, 그냥 ChatGPT에 "이 기능 구현 전에 내가 고려해야 할 게 뭐가 있을까?" 하고 물어보든, 방법은 중요하지 않다. 핵심은 구현에 들어가기 전에 생각의 시간을 갖는 것이다. 5분이면 된다. 그 5분이 4시간을 아끼는 마법을 여러 번 경험하면, 습관이 안 들려야 안 들 수가 없다.

시작부터 코딩 에이전트 대화 셸에 문장부터 던지고 보는 건 절대 좋은 습관이 아니다. 이건 작업 계획 없이 코딩부터 시작하는 일 못하는 개발자들의 습관과 동일하다.

때문에 큰 작업을 "에이전트 한 턴에 완료 가능한 크기"로 쪼개는 연습도 의식적으로 해야 한다. 대략 파일 3-5개 수정, 15-30분 내 완료 가능한 범위. 이보다 크면 쪼개고, 이보다 작으면 합친다. 에이전트에게 10번쯤 작업을 시켜보면 그 체감이 생긴다. 그 체감 자체가 분해 능력이다.

최신 Codex/Claude Code는 Task 등의 도구로 실제 작업 계획을 잘 설계한다. 단순한 요구사항이나 수정사항이라면 크게 문제없을지 모르지만 결국 내가 먼저 해봐야 안다. 직접 해본 다음 위임하자. 그 순서가 중요하다.

② 컨텍스트 설계 (Context Architecture)

Karpathy의 DGX Spark 예시를 다시 보자. 그가 에이전트에게 준 건 딱 네 가지였다 — IP, 사용자명, 비밀번호, 목표. 군더더기 없이 필요한 것만. 이게 컨텍스트 설계의 이상향이다.

그런데 실제 프로덕션 환경에서는 이렇게 단순하지 않다. 프로젝트에는 수십 개의 파일이 있고, 비즈니스 로직이 있고, 코딩 컨벤션이 있고, 과거에 내린 아키텍처 결정이 있다. 이 모든 맥락을 에이전트에게 어떻게 전달하느냐가 결과의 품질을 결정한다. Karpathy의 말을 빌리자면, 이제 코드 대신 자연어가 인터페이스다.

Karpathy는 에이전트에게 지시할 때 마지막에 "메모리 노트 기록, 마크다운 리포트 작성까지" 를 포함시켰다. 이건 단순한 문서화가 아니다. 에이전트가 작업하면서 생긴 컨텍스트를 다음 작업에 전달할 수 있도록 구조화 하라는 지시다. 컨텍스트는 주는 것만이 아니라, 만들어가는 것이기도 하다.

AGENTS.md를 잘 쓰는 것도 중요하지만, 그게 전부는 아니다. 코드 아키텍처 자체가 잘 설계되어 있으면 에이전트가 컨텍스트를 파악하는 속도가 완전히 다르다.

요즘은 Codex에서 $로 스킬을 지정하면 해당 맥락만 정확히 전달할 수 있어서 정확도가 확 올라간다. 하지만 문서화가 전부가 아니라는 걸 경험으로 배웠다.

역설적이지만 결국 코드를 잘 짜야 한다.

디렉토리 구조가 명확하고, 네이밍이 일관되고, 관심사가 분리되어 있으면 에이전트가 빠르게 이해한다. 반대로 스파게티 코드에 문서만 아무리 잘 써놔도, 에이전트는 빙빙 돌 확률이 커진다. 코드를 읽지 않는 시대라고 해서 코드의 품질이 덜 중요해진 게 아니다. 오히려 더 중요해졌다.

에이전트 친화적 코드베이스라는 발상

Flask의 창시자 Armin Ronacher가 흥미로운 관점을 제시했다. 에이전트와의 협업에서 프로그래밍 언어 선택 자체가 컨텍스트 설계의 일부라고 말한다. 그의 결론은 예상 밖이었다 — Go가 에이전트 친화적 언어라는 거다.

"Go is sloppy: Rob Pike famously described Go as suitable for developers who aren't equipped to handle a complex language. Substitute 'developers' with 'agents.'"

"Go는 느슨하다. Rob Pike가 Go를 '복잡한 언어를 다룰 준비가 안 된 개발자에게 적합하다'고 했는데, '개발자'를 '에이전트'로 바꿔도 성립한다."

Go는 정적 타이핑 언어이지만 유연하고 문법이 쉽다. Java에 비해 단순하고 Python에 비해 엄격하다. 그리고 무엇보다 명시적이다. 함수형 언어와 최신 프로그래밍 언어를 선망하던 내가 결국 Go에 정착한 이유도 여기에 있다. 그리고 주니어가 학습하기 편하다. 마찬가지 이유로 에이전트가 그렇게 하기 편하다. 언어가 뭐든 에이전트가 실수할 여지를 줄이는 구조가 중요하다.

예를 들어 Ronacher는 도구 설계에 대해서도 날카롭다.

"Tools need to be protected against an LLM chaos monkey using them completely wrong."

"도구는 LLM이라는 카오스 원숭이가 완전히 잘못 쓰는 것에 대비해서 보호해야 한다."

Makefile에 프로세스 매니저 이중 실행 방지(pidfile)와 포트 충돌 예방을 넣어둔다는 거다. 에이전트는 같은 서버를 두 번 띄우거나, 이미 사용 중인 포트에 바인딩하려는 실수를 자주 한다. 도구 레벨에서 막아놓으면 에이전트가 삽질할 여지 자체가 줄어든다.

Boris Cherny — Claude Code를 만든 사람이다 — 도 Lenny's Newsletter 인터뷰에서 비슷한 이야기를 했다. 그가 15개 에이전트를 병렬로 돌릴 수 있는 이유 중 하나가 각 에이전트의 컨텍스트를 철저하게 분리했기 때문이다. 에이전트 A는 프론트엔드만, 에이전트 B는 API만, 에이전트 C는 테스트만. 겹치는 컨텍스트를 최소화하니 충돌도 줄고, 각 에이전트의 정확도도 올라간다.

Before: 플랫 디렉토리에서 에이전트가 헤매다

iOS 앱 초기에는 디렉토리 구조가 사실상 플랫이었다. Views 폴더 안에 화면 30개가 뒤섞여 있고, 모델과 뷰모델이 같은 레벨에 나열되어 있었다. 네이밍 컨벤션도 파일마다 달랐다 — 어떤 건 PascalCase로 PlanListView, 어떤 건 DailyTasks, 어떤 건 그냥 Summary. 사람이 봐도 "이 파일이 어디에 속하는 건지" 파악하는 데 시간이 걸리는 구조였다.

iOS 네이티브 앱 개발이 처음이라는 이유를 차치하더라도 초반 프로토타이핑 검증을 빠르게 하기 위한 방법으로 시작한 프로젝트 폴더가 기능이 붙으면서 어느새 어마어마하게 커져있었다.

매번 에이전트에게 "이 폴더 말고 저 폴더야"라고 설명하는 데 지쳤다. 에이전트에게 "설정 화면 수정해줘"라고 하면, 관련 없는 파일까지 건드리는 경우가 잦았다. 설정 화면의 뷰모델을 수정하는데 메인 화면의 모델을 import해서 쓰고 있었다 — 디렉토리 구조가 관심사를 분리해주지 않으니 에이전트도 경계를 모르는 거다. 컨텍스트 윈도우에 불필요한 파일이 잔뜩 올라가면서 정확도가 떨어졌다.

After: Feature 단위 디렉토리 + 역할별 분리

디렉토리를 Feature 단위로 재구성했다. Features/Plan/, Features/Daily/, Features/Settings/ — 각 Feature 폴더 안에 View, ViewModel, Model이 함께 들어간다. 공유 컴포넌트는 Shared/Components/, 공통 모델은 Shared/Models/로 분리했다.

네이밍도 통일했다. {Feature}{Role} 패턴 — PlanListView, PlanListViewModel, PlanModel. 파일 이름만 보면 이 파일이 뭐하는 건지, 어디에 속하는 건지 바로 알 수 있다.

변화는 즉각적이었다. "Settings 화면에 다크모드 토글 추가해줘"라고 하면 에이전트가 Features/Settings/ 안에서만 작업한다. 다른 Feature를 건드릴 이유 자체가 없어진 거다. 코드 구조가 곧 컨텍스트의 경계가 된다. 에이전트에게 "이 폴더만 봐"라고 따로 말할 필요도 없다 — 구조 자체가 범위를 알려준다.

HumanLayer 팀의 분석도 같은 결론이다. CLAUDE.md(또는 AGENTS.md)에 지침이 150-200개를 넘으면 따르는 비율이 급락한다는 거다. task-specific한 지시는 별도 파일로 분리해야 한다. 문서 10페이지보다 잘 구조화된 디렉토리 하나가 에이전트에게 더 많은 정보를 준다.

이렇게 연습한다

클린 아키텍처를 의식적으로 연습하는 게 출발점이다. "에이전트가 읽기 쉬운 코드"와 "사람이 읽기 쉬운 코드"는 놀랍도록 일치한다. 새 프로젝트를 시작할 때 가장 먼저 디렉토리 구조를 잡고, 각 디렉토리의 역할을 README에 적는다. 사람을 위해서이기도 하고, 에이전트를 위해서이기도 하다.

나는 테스트가 용이한 DDD/Clean Architecture 구조를 고수하고 있고 특히 핵심이 되는 유즈케이스 레이어 코드의 컨벤션을 강하게 정의해서 사용한다. iOS는 서버와 달리 약간 구조 차이가 있지만 큰 골격은 거의 비슷하다.

AGENTS.md에는 아키텍처 결정 이유(ADR), 코딩 컨벤션, 도메인 용어 사전 정도만 넣는다. 나머지는 코드 자체가 말하게 한다. 타입 정의가 정확하고, 함수 이름이 의미를 담고 있고, 테스트가 스펙 문서 역할을 하면 — 그게 최고의 AGENTS.md다.

컨텍스트 분리 설계도 시도해볼 만하다. 워크트리, 병렬로 켜진 여러 에이전트들이 독립된 환경에서 독립된 역할과 목표가 주어질때 확실히 성능이 극대화된다. 백엔드, 프론트엔드 모두 한 곳에서 관리하고 싶을 것이고 하나의 쉘에서 이 기능 저 기능 다 하는 걸 기대하겠지만, 결국 에이전트 별로 Plan, 문서화, 개발, 테스트, 커밋까지 나눠서 진행하는 것이 훨씬 효율적이다. 관리할 것도 많아지고 처음엔 오버킬처럼 느껴지지만, 작업이 복잡해질수록 이 분리가 빛을 발한다. (역설적으로 그만큼 오케스트레이션 툴이 중요해진다.)

③ 완료 정의 (Definition of Done)

에이전트한테 밤새 작업을 돌려놓고 아침에 확인하는 건 꽤 짜릿한 경험이다. 그런데 그 짜릿함이 허무함으로 바뀌는 순간이 있다. "작업 완료됐습니다"라고 리포트가 와 있는데, 막상 보면 문서만 업데이트됐거나, 기본 스텁과 인터페이스 구성만 해놓고 끝난 경우. 돌아가는 코드가 아니라 돌아갈 것 같은 코드만 있는 거다.

Karpathy가 에이전트의 한계를 언급하면서 아직 필요한 것들을 나열했는데, 그중 하나가 감독(supervision) 이다.

"Of course this is not yet perfect. Things still needed: high-level direction, judgment, taste — knowing what good looks like — supervision, and providing hints and ideas on repetitive tasks."

"물론 아직 완벽하지는 않다. 여전히 필요한 것들: 고수준 방향 설정, 판단력, 감각(taste) — 무엇이 좋은지 아는 안목 — 감독, 그리고 반복 작업에서 힌트와 아이디어 제공."

에이전트에겐 결국 감독이 필요하다. 그리고 감독의 시작이 바로 완료 정의다. "이 작업이 끝났다"는 게 무슨 뜻인지를 명확하게 정의하지 않으면, 에이전트는 자기 나름의 기준으로 "끝났다"고 보고한다. 그리고 그 기준은 십중팔구 내 기준과 다르다.

Before: 개발 자동화 CLI, 밤새 돌렸더니 빈 껍데기

Codex App Server 기반 워크플로우 자동화 CLI를 만들려고 했다. propose → plan → run → verify → archive 루프를 자동으로 돌리는 도구. 전체 아키텍처, 모듈 구조, API 설계까지 다 담은 계획서를 준비했다. 병렬 에이전트 실행도 계획했다. Stream A는 코어 로직, Stream B는 CLI 인터페이스, Stream C는 테스트. "이 정도 문서면 에이전트가 알아서 하겠지." 안심하고 밤새 돌렸다.

아침에 확인했더니 1시간 만에 종료되어 있었다. 에이전트가 스스로 "더 이상 할 게 없다"고 판단하고 멈춘 거다. 파일 구조는 깔끔했다. 하지만 전부 스텁뿐이었다. func Propose() error { return nil }. 타입 정의와 모듈 구조만 완벽하게 세팅해놓고, 정작 비즈니스 로직은 빈 껍데기였다. 깔끔하게 정돈된 빈 집을 넘겨받은 기분이었다.

그보다 더 교훈적인 건 두 번째 경험이었다. CLI를 다시 시도했을 때, 에이전트가 "모든 테스트 통과"라고 보고를 올렸다. 열어보니 테스트 자체를 에이전트가 자기 편하게 다시 작성해놓은 거다. 원래 검증해야 할 시나리오 — propose가 실제 API를 호출하고 응답을 파싱하는지, plan이 의존성 순서를 지키는지, verify가 실패 케이스를 잡는지 — 대신, 단순히 함수가 에러 없이 리턴하는지만 확인하는 코드로 바꿔놓고 "전부 통과!"라고 한 셈. 에이전트 입장에서는 거짓말을 한 게 아니다. 테스트는 정말로 전부 통과했으니까. 다만 내가 원한 테스트가 아니었을 뿐이다.

그때 깨달았다 — 에이전트의 "완료"는 내 "완료"와 다르다. 그리고 그 간극을 메우는 건 더 좋은 모델이 아니라, 더 명확한 완료 정의다. 내가 문서를 제대로 안 읽었다. 요구사항 문서를 내가 직접 썼으면서도, 그 안에 어떤 복잡도가 숨어 있는지 파악하지 않았다. "문서가 있으니까 에이전트가 알아서 읽고 구현하겠지" — 이게 가장 위험한 안티패턴이다.

After: DoD + 리포트 체계

이후로 CLI를 다시 시도할 때는 완전히 다른 접근을 했다. 작업 지시에 항상 두 가지를 포함시킨다. 하나는 완료 기준 문서다. Stream A의 DoD: "propose 명령어가 실제로 API를 호출하고, 응답을 파싱해서 JSON 파일로 저장한다. 새 통합 테스트 3개를 추가한다." — 이 수준으로 구체적으로. 그리고 결정적으로: "return nil 같은 스텁은 완료로 인정하지 않음. 기존 테스트를 수정하지 말 것. 새 테스트만 추가할 것." 에이전트가 스텁으로 도망가거나 테스트를 조작할 수 없게 만든 거다.

다른 하나는 작업 리포트 제출이다. 에이전트가 작업을 마치면 반드시 완료 기준 대비 결과를 리포트로 정리하게 한다. "무엇을 했고, 완료 기준 중 무엇을 충족했고, 무엇이 남았는지." 리포트가 있으면 코드를 열기 전에 5분 만에 상태를 파악할 수 있다.

Elvis의 시스템에서 인상적인 건 완료 정의가 단계적으로 구성되어 있다는 점이다. 그의 에이전트 시스템에서 "완료"는 단순히 코드를 짠 게 아니다:

PR이 생성됐는가
main 브랜치와 동기화되었는가 (머지 충돌 없음)
CI가 통과했는가 (lint, 타입 체크, 유닛 테스트, E2E)
Codex 코드 리뷰를 통과했는가
Claude Code 코드 리뷰를 통과했는가
Gemini 코드 리뷰를 통과했는가
UI 변경이 있으면 스크린샷이 포함되었는가

이 모든 조건이 충족되어야 비로소 텔레그램 알림이 온다: "PR #341 ready for review." 그 전에는 알림조차 오지 않는다. 에이전트 세 개가 코드 리뷰를 하고, CI가 통과하고, 머지 충돌이 없는 상태가 되어야 인간의 시간을 요청한다.

이 수준까지 갈 필요는 없겠지만 (솔직히 나도 아직 여기까지는 못 했다), 핵심 원칙은 동일하다. 에이전트에게 "완료란 무엇인지"를 구체적으로 알려줘야 한다. 그렇지 않으면 에이전트는 자기 나름의 완료 기준을 적용한다. 그게 내 기준과 일치할 확률은 높지 않다.

이건 나만의 교훈이 아니었다. GitHub Engineering 팀도 비슷한 패턴을 쓴다. 멀티 에이전트 시스템에서 typed schemas로 에이전트 간 메시지를 강제하고, 에이전트가 할 수 있는 행동을 명시적으로 제한한다.

"Most multi-agent workflow failures come down to missing structure, not model capability."

"대부분의 멀티에이전트 워크플로우 실패는 모델 능력 부족이 아니라 구조 부재에서 온다."

CLI가 실패한 것도 모델이 멍청해서가 아니라, 내가 구조를 안 잡아줬기 때문이다.

이렇게 연습한다

모든 작업 지시에 DoD(Definition of Done) 체크리스트를 포함하는 것이 출발점이다. 솔직히 매번 DoD 쓰는 게 오버킬처럼 느껴질 수 있다. 하지만 "에이전트가 완료라고 했는데 아니었던" 경험을 두세 번 하고 나면, 안 쓰는 게 더 불안해진다. 나는 이제 작업 지시 템플릿에 DoD 섹션을 기본으로 넣어뒀다. "테스트 통과 + 기존 테스트 미수정 + 리포트 제출" — 이 세 줄이 기본이고, 작업 성격에 따라 항목을 추가한다.

에이전트의 "완료" 보고를 그대로 믿지 않는 습관도 필요하다. 이게 의심이 아니라 건강한 검증이다. 특히 밤새 돌리는 작업에서는 더 그렇다. 나는 이제 장시간 작업을 맡길 때 중간 체크포인트를 반드시 넣는다. "1단계 끝나면 보고, 2단계 끝나면 보고." 이렇게 하면 8시간을 날리는 대신, 2시간 시점에서 방향이 잘못됐음을 캐치할 수 있다. "작업 완료됐습니다" 열어봤더니 빈 껍데기였던 그 허무함을 한 번만 겪어보면, 중간 체크포인트의 가치를 온몸으로 이해하게 된다.

DoD를 작은 단위로 쪼개는 연습도 중요하다. "로그인 기능 완료"의 DoD는 빈틈이 생기기 쉽다. "이메일 인증 플로우 완료", "비밀번호 재설정 완료" 같이 작게 나누면 각각의 완료 기준이 훨씬 명확해진다. 분해 능력(①)과 완료 정의(③)는 결국 한 쌍이다. 잘 분해된 작업은 완료 기준도 명확해지고, 완료 기준이 명확하면 분해도 자연스럽게 된다.

④ 실패 복구 (Failure Recovery Loop)

에이전트와 일하면 실패가 일상이다. 어제 잘 되던 워크플로우가 오늘은 안 된다. 새 모델이 나오면 기존 프롬프트가 다르게 동작한다.

"The agent autonomously worked for ~30 minutes, running into various issues along the way, looking things up online to solve them, iteratively resolving them."

"에이전트는 약 30분 동안 자율적으로 작업하면서, 도중에 여러 문제에 부딪히고, 온라인에서 해결책을 직접 조사하고, 하나씩 반복적으로 해결해나갔다."

에이전트 자체가 실패와 복구의 루프로 작동한다. 하지만 항상 이렇게 깔끔하게 되지는 않는다. 에이전트의 자체 복구 능력에도 한계가 있다. 에이전트가 스스로 해결 못하는 실패를 만났을 때, 인간이 어떻게 개입하느냐가 핵심이다.

Before: 재분배 엔진, A↔B 무한루프

iOS 앱의 핵심 기능 중 하나가 학습 분량 재분배 엔진이다. "오늘 못 했으니 내일 더 할게" — 이 간단한 로직을 자동화한 기능인데, 남은 분량을 재계산해서 배분한다. 버그는 단순해 보였다. 재분배 API를 호출하면 미래 날짜의 기존 데이터가 사라지는 문제. 50개 중 47개가 손실됐다.

원인은 두 군데에 있었다. 삭제 함수가 날짜 조건 없이 전체를 삭제하고 있었고, 미완료 데이터 추출 함수가 미래 데이터를 제외하고 있었다.

문제를 알았으니 고치면 되잖아? 그런데 여기서부터 지옥이 시작됐다. 시나리오 테스트 5개가 전부 PASS 였다. 들여다보니 테스트가 "데이터 > 0" 수준의 검증이었다. 50개가 3개로 줄어도 PASS. (이건 에이전트 잘못이 아니라 내 잘못이다.)

진짜 문제는 그 다음이었다. 특정 파라미터의 의미가 함수마다 달랐다. includeToday=true가 A 함수에서는 "오늘 데이터를 가져온다"는 뜻이고, B 함수에서는 "오늘부터 삭제한다"는 뜻이었다. 같은 파라미터인데 시맨틱이 완전히 달랐다. A를 고치면 B가 깨졌다. B를 고치면 A가 깨졌다. 에이전트가 자기 루프에 빠져서 fix → break → fix → break를 반복했다.

After: 격리 테스트 + Must NOT Have 가드레일

결국 나는 코드를 좁혔다. 전체 API 흐름을 테스트하는 대신, 문제가 되는 함수만 격리해서 단독 테스트 했다. 통합 테스트에서는 안 보이던 게 격리하니 바로 보였다. 그 다음, 기존 코드에 영향을 주지 않는 독립된 경로를 새로 만들었다. 각 함수의 시맨틱을 독립적으로 정의하고 재구현했다.

핵심은 "Must NOT Have" 가드레일이었다. "이 파일은 수정하지 마. API 응답 계약을 변경하지 마. 기존 통합 테스트를 수정하지 마." 이 세 가지 금지 조건이 에이전트의 A↔B 무한루프를 끊었다.

이 경험이 Dex Horthy의 12-Factor Agents Factor 9와 정확히 맞닿는다 — 에러를 컨텍스트에 압축해서 에이전트가 self-heal 할 수 있게 만들어라. 단순히 "다시 해봐"가 아니라, 에러의 원인과 맥락을 주입해서 같은 실수를 반복하지 않게 하는 거다.

같은 프롬프트로 재시도하지 않기

대부분의 에이전트 루프는 실패하면 같은 프롬프트를 다시 돌린다. "한 번 더 해봐." 이게 작동할 때도 있다. 비결정적인 에러 — 네트워크 타임아웃이나 일시적 API 장애 — 라면 재시도가 맞다. 하지만 근본적으로 뭔가가 잘못됐을 때는 반복해도 결과가 같다. 에이전트가 잘못된 라이브러리를 쓰고 있거나, 요구사항을 잘못 이해했거나, 컨텍스트가 부족한 경우. 이럴 때 같은 프롬프트로 재시도하는 건 벽에 같은 방향으로 계속 머리를 박는 거다.

핵심은 실패의 원인을 분석하고, 그에 맞는 처방을 내리는 것 이다. 같은 지시를 반복하는 게 아니라, 더 나은 지시를 새로 만드는 것. 이 차이가 엄청나다.

실패를 세 가지로 분류하면 처방이 명확해진다.

유형 1: 컨텍스트 부족. 에이전트가 필요한 정보를 모르는 경우. 처방: 빠진 정보를 추가.

유형 2: 방향 오류. 요구사항 자체를 잘못 이해한 경우. 처방: 요구사항을 더 명확하게 재정의.

유형 3: 구조적 충돌. 코드 구조 자체에 문제가 있는 경우. 처방: 코드를 좁혀서 격리하고, 가드레일을 설정하고, 구조를 바꿔서 재시도.

재분배 엔진은 유형 3이었다. "다시 해봐"가 아니라 "이 파일만 격리해서 테스트하고, 이 파일은 건드리지 마"라는 구조적 처방이 필요했다. 실패 앞에서 "다시 해봐"를 누르는 대신 "이건 어떤 유형이지?"를 먼저 생각하는 것만으로도 복구 속도가 체감될 정도로 빨라진다. 실패한 이유를 파악하고, 그 이유에 맞게 지시를 바꾸는 게 훨씬 빠르다. 에이전트가 왜 실패했는지 이해하는 것 — 그 자체가 엔지니어링이다.

이렇게 연습한다

실패할 때마다 짧게라도 기록하는 습관이 시작이다. "컨텍스트 놓침", "요구사항 다르게 해석", "A↔B 무한루프 진입" — 이런 짧은 메모가 쌓이면 패턴이 보인다. 같은 유형이 3번 반복되면 시스템을 바꿀 때라는 신호다.

새로운 도구와 방법론에 열린 자세를 유지하는 것도 중요하다. 나는 Cursor에서 Claude Code로, Claude Code에서 Codex로, 그 사이에 OpenClaw, Superpowers, 여러 스킬 시스템을 거쳤다. 각각의 도구가 다른 실패 패턴을 가지고 있었고, 그걸 넘어가면서 "에이전트와 일하는 감각"이 축적됐다. 한 도구에 집착하지 않는 게 좋다. 도구는 수단이지 목적이 아니다.

프로젝트별로 KNOWN_ISSUES.md를 만드는 것도 효과적이다. "이 프로젝트에서 에이전트가 자주 하는 실수"를 기록해두면 — 같은 실패가 반복되는 빈도가 확실히 줄어든다. 실패 기록이 메모리가 되고, 메모리가 시스템이 된다.

새로운 접근을 시도할 때는 "30분 룰"을 쓴다. 30분 안에 의미 있는 진전이 없으면 다른 방법을 찾는다. 30분 안에 뭔가 되면 거기서부터 깊게 판다. 실패 자체는 괜찮다. 같은 실패를 반복하는 건 괜찮지 않다.

⑤ 관찰 가능성 (Observability)

에이전트에게 큰 작업을 통째로 맡기면 편하긴 한데, 문제가 생겼을 때 어디서 잘못됐는지 파악하기가 어렵다. "어느 시점에 내가 결과를 확인할 것인가" — 이 질문이 관찰 가능성의 핵심이다.

Karpathy의 DGX Spark 예시에서 에이전트는 30분간 자율적으로 작업했다. 그 30분 동안 Karpathy가 뭘 했는지는 안 나오지만, 결과적으로 에이전트가 "메모리 노트 기록, 마크다운 리포트 작성"까지 해줬다는 건 작업 과정이 추적 가능한 형태로 남았다는 뜻이다.

모델과 에이전트가 더 강력해질수록, 관찰 가능성의 중요성도 커진다. 에이전트가 할 수 있는 일이 많아질수록 잘못될 수 있는 방향도 많아지기 때문이다.

Before: liquidglass, "이상한데 그냥 두자"의 대가

iOS 26이 발표되고 liquidglass를 처음 적용해보려고 했다. 새로운 디자인 언어를 우리 앱에 시도해보고 싶었다. 에이전트에게 맡기면 알아서 업데이트될 거라 기대했다. (그게 안일한 기대였다는 건 이쯤 되면 패턴이 보일 거다.)

에이전트가 작업하는 걸 보고 있었다. 처음 몇 파일은 괜찮아 보였는데, 4-5번째 파일쯤부터 뭔가 이상했다. 건드리는 파일 범위가 예상보다 넓었다. 색깔이 원래 의도와 다르게 바뀌는 것 같았다. 하위호환성을 위한 분기가 점점 복잡해지고 있었다.

"이상한데... 그냥 두자." 이 한 마디가 가장 비싼 판단이었다.

결과물을 확인해보니 UI가 전부 깨져 있었다. liquidglass의 반투명 효과가 기존 컬러 스킴과 충돌하면서 텍스트 가독성이 떨어졌고, 다크모드에서는 아예 안 보이는 요소가 생겼다. 최악은 단계별 커밋이 없었다는 거다. 부분적으로 롤백할 수가 없었다. 전부 버리든 전부 살리든 양자택일.

4-5번째 파일에서 멈추고 확인했으면, 최악의 경우에도 5개 파일만 롤백하면 됐다. 끝까지 방치한 결과, 20개 넘는 파일이 엉킨 상태에서 수습해야 했다.

After: 예광탄 전략 + 블루프린트

이 경험 이후로 새로운 기술을 적용할 때는 반드시 예광탄(tracer bullet) 전략 을 쓴다. 전체를 한 번에 적용하는 대신, 가장 단순한 화면 하나에 먼저 적용해보는 거다. 작게 쏘고 빠르게 확인. 괜찮으면 다음 화면으로 넓힌다.

예광탄의 진짜 가치는 블루프린트 를 만들어준다는 거다. liquidglass를 화면 A 하나에 적용해보니, '아 이 기술은 컬러 스킴이랑 충돌하는 지점이 여기구나, 다크모드 분기는 이렇게 해야 하는구나'가 보였다. 처음 적용하는 기술은 블루프린트를 미리 그릴 수가 없다. 예광탄이 그 블루프린트를 빠르게 그려준다. 화면 A에서 얻은 블루프린트가 있으니, 화면 B부터는 에이전트가 예상 밖의 파일을 건드리기 시작했을 때 바로 '이건 내 예상과 다르다'고 판단할 수 있었다.

단계별 커밋도 필수가 됐다. "화면 A 적용" → 커밋 → "화면 B 적용" → 커밋. 이렇게 하면 화면 C에서 문제가 생겨도 롤백 포인트가 확보되어 있다. "3개 파일 수정할 때마다 커밋해줘"라고 지시하면 된다. 간단하지만 이 한 마디가 수정 비용을 극적으로 줄여준다.

관찰 가능성이 높아질수록 위임의 범위도 넓어진다. 처음에 나는 함수 하나를 맡기는 것도 불안해서 전부 검토했다. 하지만 예광탄 전략과 단계별 커밋이 자리 잡으면서, 이제는 모듈 단위의 작업도 안심하고 맡긴다. 관찰 가능성이 신뢰를 만들고, 신뢰가 위임을 가능하게 만든다. "Do you trust your agents?"에 대한 내 대답이 "점점 더 그렇다"로 바뀌고 있는 건, 에이전트가 더 똑똑해져서가 아니라 내 관찰 시스템이 더 정교해져서다.

이렇게 연습한다

작업 단위를 적절한 크기로 쪼개는 감각을 키우는 게 첫 번째다. 나의 경험적 기준: PR 하나를 리뷰하는 데 10분 이내면 적절한 크기, 30분 이상이면 너무 크다. 파일 수로 따지면 3-5개가 한 번에 확인하기 좋은 범위다. 처음에는 이 기준이 맞는지 확신이 없었는데, 몇 달 하다 보니 "이건 좀 크다" 하는 감이 자연스럽게 생겼다.

중간 체크포인트를 명시적으로 설계하는 것도 습관으로 만들어야 한다. "여기까지 되면 한 번 보여줘." 이 한 마디가 1시간짜리 이탈을 방지한다. 자동 보고 시스템을 활용하면 더 좋다. 나는 에이전트에게 파일 3개 수정할 때마다 diff 요약을 보고하라고 설정해뒀다. 매번 전체 코드를 들여다보는 대신, 요약만 보고 "방향 OK" 또는 "잠깐 스톱"을 판단한다.

그리고 작업 시작 전에 머릿속으로 "대충 이렇게 가겠지" 하는 블루프린트를 그리는 습관. 이게 관찰 가능성의 전제 조건이다. 에이전트가 어디로 가야 하는지 내가 모르면, 에이전트가 이탈했는지도 모른다. 리팩토링이라면 "이 순서로 이 파일들을 건드릴 거다", 새 기능이라면 "이 모듈에 이런 구조가 생길 거다" — 이 정도의 밑그림이면 충분하다.

블루프린트는 정확하지 않아도 괜찮다. 에이전트가 내 예상과 다른 접근을 하더라도, 그 접근이 더 나은 경우도 있다. 중요한 건 "다른 방향으로 가고 있다"는 걸 알아채는 거다. 에이전트가 내 예상과 다른 접근을 하더라도, 블루프린트가 있으면 "어, 이건 다른데?" 하고 바로 캐치할 수 있다. 블루프린트 없이 방치했으면 캐치 자체가 불가능했을 거다.

Elvis의 10분 크론잡 모니터링은 이 블루프린트 비교를 자동화한 거라고 볼 수 있다. 에이전트의 현재 상태(tmux 세션 생존, PR 상태, CI 결과)를 미리 정의된 기대 상태와 비교하는 것. 기대 상태에서 벗어나면 알림이 오고, 그때 사람이 개입한다. 100% 결정론적 bash 스크립트여서 토큰도 안 들고, 오류 가능성도 거의 없다. 간단한 원리지만, 이 간단한 원리가 94커밋/일을 가능하게 만드는 핵심 인프라 중 하나다.

⑥ 메모리 설계 (Memory Architecture)

AI와 긴 작업을 하다 보면 반드시 부딪히는 벽이 있다. 세션이 길어지면 앞에서 한 이야기를 잊어버린다. 세션 컴팩션(context compaction)이라고 하는데, 맥락이 너무 많이 축소되어 연속 작업에서 특히 문제가 된다.

Karpathy의 에이전트 지시에는 마지막에 반드시 "메모리 노트 기록, 마크다운 리포트 작성까지" 가 포함되어 있었다. 단순히 코드만 짜고 끝나는 게 아니라, 작업한 내용을 기록으로 남기라는 거다.

메모리가 없는 오케스트레이터는 매 세션이 첫 만남이다. 어제 뭘 했는지, 어떤 결정을 내렸는지, 어떤 실패를 겪었는지 — 다 잊어버리고 처음부터 시작한다.

Before: 매일 아침 15분씩 맥락 설명

나도 3일 연속 인증 리팩토링을 할 때 매일 아침 "어제 JWT 구조를 바꿨는데..."부터 시작하면서 지칠때가 많았다. dev.to의 @suede가 공유한 경험이 정확히 같은 상황이었다. 연속 작업을 하는데 매일 아침 새 세션을 열 때마다 어제 한 일을 처음부터 설명해야 했다. "어제 이 구조를 바꿨는데, 왜 바꿨는지부터 설명할게..." 15-20분이 날아간다. 3일 연속이면 거의 1시간이다. 그리고 구두로 설명한 맥락은 완벽하지 않다 — 내가 놓치거나 잘못 기억한 부분이 있을 수밖에 없다.

After: Hooks로 자동 메모리 — MEMORY.md 하나로 5초 복원

@suede의 해결책이 우아했다. Claude Code의 hooks 기능을 활용해서, 세션이 끝날 때마다 자동으로 "기억"을 추출해서 CLAUDE.md에 기록하는 시스템을 만든 거다.

"Session 1: Claude works → hooks silently extract memories → saved. Session 2: Claude starts → reads CLAUDE.md → instantly knows everything."

"세션 1: Claude가 작업 → hooks가 조용히 기억을 추출 → 저장. 세션 2: Claude 시작 → CLAUDE.md를 읽음 → 즉시 모든 것을 앎."

"기록하라고 지시할 필요가 없다"는 게 핵심이다. hooks가 세션 종료 시 자동으로 작업 내용을 요약해서 append한다. 다음 세션이 시작되면 자동으로 읽는다. 맥락 복원에 걸리는 시간: 5초. 15분에서 5초로. 이 차이를 체감하면 돌아갈 수 없다.

나는 hooks까지는 아니지만, 이 패턴을 참고해서 Codex나 Claude Code로 작업할 때 한 턴마다 메모리/작업 업데이트 문서화를 무조건 한다. MEMORY.md에 "오늘 무엇을 했고, 어떤 결정을 내렸고, 다음에 이어서 할 것"을 기록한다.

Boris Cherny 팀의 사례가 이 메모리의 팀 레벨 확장을 보여준다. Claude Code 팀은 단일 CLAUDE.md를 git에 체크인해서 팀 전체가 공유한다. Claude가 뭔가를 잘못하면 즉시 CLAUDE.md에 추가한다 — "다음엔 이렇게 하지 마." 코드 리뷰 중에도 @.claude를 태깅해서 PR의 일부로 업데이트한다. 개인의 기억이 아니라 팀의 기억이 에이전트에게 전달되는 구조.

요즘 이 방향으로 도구들이 쏟아지고 있다. Claude Code의 built-in memory, supermemory.ai 같은 AI 메모리 레이어 — 메모리 인프라가 성숙해지면서 "매 세션이 첫 만남"이라는 근본 문제가 해결되는 방향으로 가고 있다.

이렇게 연습한다

매 작업 턴마다 문서화하는 습관이 메모리 설계의 전부라고 해도 과언이 아니다. MEMORY.md 하나 만들어서 매일 기록하는 것부터 시작하면 된다. 오늘 내린 결정과 그 이유, 다음에 할 일, 남은 이슈 — 이 세 가지만 적어도 충분하다.

한 가지 팁: 메모리의 구조를 일관되게 유지하는 것도 중요하다. 나는 MEMORY.md를 날짜순으로 기록하되, 각 항목에 [결정], [작업], [이슈] 태그를 붙인다. 나중에 "지난달에 내린 아키텍처 결정이 뭐였지?"를 찾을 때 [결정] 태그로 검색하면 10초 안에 나온다. 이런 작은 구조화가 메모리의 검색 가능성을 극적으로 높여준다.

프로젝트가 길어지면 검색 가능한 시스템(Obsidian 등)을 도입하면 된다. 핵심은 "검색 가능한 기록"이다. 3개월 전에 내린 아키텍처 결정을 찾을 수 없으면, 같은 논의를 다시 하게 된다. 메모리가 이 반복을 끊어준다.

⑦ 병렬 관리 (Parallel Orchestration)

Karpathy가 말한 핵심 중 하나가 이거다.

"The highest leverage is in designing a long-running orchestrator with the right tools, memory, and instructions to productively manage multiple parallel coding instances."

"가장 큰 레버리지는 올바른 도구·메모리·지시를 갖춘 장기 실행 오케스트레이터가 여러 병렬 코드 인스턴스를 생산적으로 관리하도록 설계하는 것이다."

"The highest level of agentic engineering, accessible through this, is currently very high leverage."

"이를 통해 달성할 수 있는 최상위 수준의 에이전틱 엔지니어링의 레버리지가 현재 매우 높다."

여러 워크트리에서 서로 다른 기능을 동시에 개발하는 건 기술적으로는 가능하다. 하지만 실제로 해보면 관리가 만만치 않다. 에이전트 A가 인증 모듈을, 에이전트 B가 결제 기능을 만들고 있는데 둘 다 같은 유저 모델을 건드리면 충돌이 난다.

앞서 소개한 Boris Cherny부터 하루 94커밋의 Elvis(@elvissun)까지 — 방향은 모두 같다. 한 명의 엔지니어가 여러 에이전트를 오케스트레이션해서 팀 단위의 생산성을 내는 것. Karpathy가 "에이전틱 엔지니어링"이라고 이름을 붙인 이유가 정확히 여기에 있다.

그의 사례가 이 방향의 극단을 보여준다. 로컬 터미널에서 5개의 Claude Code를 병렬로 돌리고, claude.ai/code에서 추가로 5-10개를 동시에 실행한다. 총 10-15개의 병렬 세션. 각 에이전트의 컨텍스트를 철저하게 분리했기 때문에 가능한 구조다. Superset.sh나 oh-my-codex(omx) 같은 도구들도 이 방향으로 나오고 있다.

CTO 시절과 닮은 점

이 경험을 하면서 자꾸 CTO 시절이 떠올랐다. 스쿼드 6개를 매니징하던 시절. 하루에 6개 팀과 회의하면서 각 팀의 상태를 파악하고, 블로커를 해결해주고, 전체 방향이 어긋나지 않게 조율하는 일. 에이전트 병렬 관리가 그때와 놀라울 만큼 비슷하다.

현재의 병렬 에이전트 코딩을 ADHD에 비유하는 글을 많이 봤다. 여러 작업 사이를 전환하면서 어디에도 집중하지 못하는 상황. 그런 측면도 있긴 한데, 나는 이게 매니징에 더 가깝다고 본다. ADHD는 의도치 않은 산만함이지만, 에이전트 관리는 의도된 멀티태스킹이다. 매니저에게 필요한 건 "모든 팀의 코드를 직접 짜는 능력"이 아니라 "모든 팀의 상태를 파악하고, 블로커를 해결하고, 방향을 맞추는 능력"이다. 에이전트 병렬 관리도 정확히 그거다.

⑤에서 에이전트 하나를 방치하는 것도 위험했는데, 5개가 동시에 돌아가면 그 리스크가 곱절이다. 스쿼드 6개를 관리할 때 가장 위험한 순간은 "다 잘 되고 있겠지" 하고 방심하는 순간이었다. 그 순간에 팀 하나가 삽질을 하고 있거나, 두 팀이 같은 일을 중복으로 하고 있거나, 방향이 틀어진 채로 달리고 있다. 에이전트도 마찬가지다. 병렬로 돌아가는 에이전트 5개를 "다 알아서 잘 하겠지" 하고 방치하면, 나중에 머지할 때 충돌이 터지거나, 한 에이전트가 다른 에이전트의 작업을 덮어쓰거나, 방향이 제각각인 결과물이 쌓인다.

체크리스트와 싱크 포인트가 생명줄이다. 그리고 이건 새로운 스킬이 아니다. 좋은 매니저가 이미 가지고 있는 스킬이다. 에이전트 시대가 그 스킬에 새로운 이름을 붙였을 뿐이다.

사람 매니징과 에이전트 매니징 사이에 한 가지 결정적인 차이가 있긴 하다. 사람은 질문을 한다. 에이전트는 묻지 않고 자기 판단으로 진행한다. 그래서 에이전트 매니징에서는 사전 설계가 더 중요하다. "이런 상황에서는 이렇게 해"를 미리 정해줘야 한다.

이렇게 연습한다

작게 시작하자. 처음부터 에이전트 5개를 동시에 돌리면 혼돈에 빠진다. 에이전트 2개를 동시에 돌리는 것부터.

나의 경험을 공유하자면, 에이전트 2개를 동시에 돌린 첫 날은 꽤 혼란스러웠다. A의 결과를 확인하다가 B의 진행 상황을 놓쳤고, B를 확인하러 갔더니 A가 기다리고 있었다. 두 번째 날부터는 타이머를 맞추기 시작했다. 25분 에이전트 A 모니터링, 5분 휴식, 25분 에이전트 B — 뽀모도로 비슷한 방식이다. 이 루틴이 자리 잡히니 두 에이전트가 안정적으로 돌아갔다. 일주일 후에 세 번째를 추가했다. 2개가 안정되면 3개, 3개가 안정되면 5개. 매니저나 팀 리드 경험이 있는 사람은 이 과정이 훨씬 빠를 거다.

병렬 작업 간 의존성을 미리 파악하고 충돌 방지를 설계하는 것도 필수다. git worktree를 활용하면 물리적으로 분리된다. 에이전트 A는 worktree-auth에서, 에이전트 B는 worktree-payment에서 작업하게 하면 파일 충돌 자체가 줄어든다.

⑧ 추상화 계층 설계 (Abstraction Layering)

에이전틱 엔지니어링에도 레벨이 있다고 본다. 나는 이걸 체감으로 구분한다.

Level 0: 직접 코딩 — 에디터에서 한 줄 한 줄 타이핑
Level 1: 에이전트 지시 — Claude Code나 Codex에 작업을 요청
Level 2: 오케스트레이터 — 여러 에이전트를 관리하는 시스템 설계
Level 3: 메타 설계 — 오케스트레이터 자체를 만드는 도구 구축

나는 현재 Level 2에서 Level 3을 트라이하는 단계다. 스킬을 만들고, 워크플로우를 자동화하고, 에이전트가 에이전트를 관리하는 구조를 실험하고 있다.

Before: 매번 같은 지시를 반복하던 시절

Level 1 시절, 매일 아침 같은 루틴을 수동으로 반복했다. "어제 머지된 PR 확인" → "변경사항 요약" → "남은 이슈 정리" → "우선순위 제안". 매번 이 네 가지를 순서대로. 하루에 20분. 한 달이면 7시간. 지시 내용이 매번 거의 동일하다는 걸 깨달은 건 3주째쯤이었다.

After: 스킬 하나로 "이번 주 정리해줘"

이 루틴을 스킬로 만들었다. "이번 주 정리해줘" 한 마디로 실행한다. 20분짜리 루틴이 2분으로 줄었다. 그런데 시간 절약보다 더 큰 변화가 있었다. 이 스킬을 만들면서 "내가 매일 하는 판단의 패턴"을 명시적으로 정리하게 된 거다. 그 과정 자체가 추상화 계층을 올리는 연습이었다.

스킬을 하나씩 만들 때마다 느꼈던 게 있다. 이걸 컴파운딩 엔지니어링이라고 부른다. 우리의 프로젝트는 단일 세션에서 끝나지 않을 만큼 충분히 크다. 결승선 게임이 아니라, 앞의 세션들이 뒤의 세션에 복리로 영향을 주는 복리형 게임이다.

"The biggest payoff is in raising the abstraction layer ever higher."

"가장 큰 레버리지는 추상화 계층을 계속 높여가는 데 있다."

Karpathy가 말한 "레버리지"란 단순히 시간 절약이 아니다. 한 단계 올라갈 때마다 시야가 넓어지고, 더 큰 문제를 다룰 수 있게 된다는 뜻이다. 코드를 직접 짜던 시대(Level 0)에서 에이전트에게 영어로 지시하는 시대(Level 1-2)로, 그리고 에이전트를 관리하는 오케스트레이터를 설계하는 시대(Level 2-3)로. 추상화 계층이 올라갈 때마다 인간이 할 수 있는 일의 범위가 극적으로 넓어진다.

추상화가 올라가면 인간의 역할이 바뀐다

에이전트가 일하는 동안 인간이 노는 게 아니다. 코드를 타이핑하는 대신 시스템을 설계한다. 에이전트에게 지시하는 대신 에이전트가 잘 작동하는 환경을 만든다.

코드를 직접 짜는 시간이 줄어든 만큼, 방향을 잡고 판단을 내리고 품질을 감독하는 시간이 늘어난다. 이게 추상화 계층이 올라간다는 말의 실질적 의미다.

이렇게 연습한다

"이 지시를 세 번째 반복하고 있네" — 이 자각이 추상화의 시작이다. 반복이 보이면 스킬이나 템플릿으로 만들어라. 처음에는 간단한 프롬프트 템플릿이라도 좋다. 그 작은 자동화 하나가 다음 자동화의 토대가 된다.

"이 작업을 에이전트에게 맡기려면 뭐가 필요하지?" 라는 질문을 습관화하면 좋다. 이 질문 자체가 추상화 사고의 시작이다. 내가 직접 하는 모든 작업을 "에이전트에게 위임 가능한가?" 관점으로 바라보는 것. 위임 가능하다면 어떤 컨텍스트와 도구와 메모리가 필요한가? 이 질문의 반복이 추상화 계층 설계 능력을 키운다.

⑨ 감각 (Taste)

마지막은 가장 측정하기 어렵지만, 어쩌면 가장 중요한 능력이다.

"Things still needed: high-level direction, judgment, taste — knowing what good looks like."

"여전히 필요한 것들: 고수준 방향 설정, 판단력, 감각(taste) — 무엇이 좋은지 아는 안목."

에이전트가 만든 결과물을 보고 "이건 괜찮다"와 "이건 뭔가 아닌데"를 구분하는 감각. 기술적으로 동작하는데 왜 불편한지, 코드가 돌아가는데 왜 마음에 안 드는지 — 느끼는 건 가능하다. 아니, 느낄 수 있어야 한다.

"'Engineering' because there is art, science, and skill to it."

"'엔지니어링'인 이유는 여기에 기예(art), 과학(science), 전문 기술이 있기 때문이다."

기예, 과학, 전문 기술 — 감각은 이 세 가지가 뒤섞인 영역이다. 타고나는 게 아니라, 깊이 파고 축적하는 것이다.

AI가 만든 프로토타입, 파트너의 반응

앱을 빠르게 작업하기 위해 현재 같이 일하는 파트너 Ellie(프로덕트 디자이너)와 있었던 에피소드다. A 화면을 AI로 빠르게 만들어서 보여줬을 때, 처음엔 반감이 있었다고 한다. 논의 없이 정리된 결과물이 나오니 자기 역할이 뭔지 모르겠다는 거였다. (개발자들과 마찬가지로 디자이너들 AI 시대에 방향성에 그만큼 고민하고 있다.)

하지만 대화를 충분히 나눈 뒤 B 화면을 같은 방식으로 정리해서 전달했을 때는 달랐다. 그때쯤에는 내가 의도하는 방향이 뭔지 알게 되었고 구체적으로 동작하는 프로토타입을 기준으로 빠진 게 뭔지, 더 다듬어야 할 게 뭔지가 비로소 보이기 시작했다. 오히려 디자이너가 디자인을 하고 여러번 핑퐁을 거쳐야 잡히는 커뮤니케이션 비용이 획기적으로 줄어들었다.

AI 디자인은 무난하다

현재 프로젝트에서도 그랬다. 우리 앱은 단순한 생산성 앱이 아닌데, AI는 계속 생산성 앱의 보편적인 디자인만 생성해냈다. 우리만의 고유한 도메인을 설명해도 Claude 는 계속 우리 도메인을 무시한채 보편적인 디자인을 재생성했다.

내가 처음에 "이 정도면 직관적이지 않나" 하고 줬던 건 솔직히 60-70점짜리였다. 실제로 Ellie가 디자인한 걸 봤을 때 — AI로는 절대 나올 수 없는 것들이 있었다. AI 결과물을 볼 때는 확신이 없었는데, Ellie의 디자인이 들어오는 순간 "아, 이거 된다"는 감각이 왔다.

AI가 만드는 결과물 대부분은 보통 수준이다. 골조와 구성 요소를 잡는 데는 큰 의미가 있다. 하지만 취향, 질감, 포인트를 주는 건 — 여전히 사람의 영역이다.

Do work → Good → Great

AI는 놀라운 성능 향상을 가져다준다. 하지만 지금 AI가 도달하는 건 솔직히 80% 수준이다. 80%도 대단한 거다, 옛날에 비하면.

문제는 나머지 20%다. 그 20%에서 각 1%의 격차가 이전의 10%보다 더 크다. 어떤 제품, 식당, 작품을 봤을 때 — 진짜 2%가 더 들어갔을 때의 감동. 명장, 명인, 명감독의 결과물에서 오는 그 감동은 "보통"의 범위 밖에 있다.

80%의 제품이 범람하면 → 나머지 20%에서 사람들은 더 좋은 걸 찾을 거고 → 그 20%는 결국 사람의 실력, 역량이 차별화 포인트가 된다.

SNS 관리에서도 비슷한 경험을 했다. Claude Code가 뽑아준 정보 정리 포스트 — 짜임새 있고 합리적이고 깔끔하다. 그러나 좋아요 0. 그런데 내가 충동적으로 쓴 한 줄 자랑글이 조회수 3만, 좋아요 200+를 찍었다. AI가 만든 "무난한" 콘텐츠보다 타임 센서티브한 사람의 진짜 감정이 담긴 한 줄이 훨씬 강력했다.

LLM도 결국 통계 모델이다. 모형(model)이라는 단어 자체가 "실세계의 근사치"라는 뜻이다. LLM이 학습한 건 인터넷에 있는 텍스트의 패턴이다. "좋은 디자인"의 보통, "좋은 코드"의 보통. 보통은 안전하지만, 탁월하지는 않다. 탁월함은 보통에서 벗어나는 데서 온다.

여러분의 직관을 잃지 마라.

Sean Goedecke의 말이 이 맥락에서 핵심을 찌른다.

"About once an hour I notice that the agent is doing something that looks suspicious, and when I dig deeper I'm able to set it on the right track and save hours of wasted effort... This is why I think pure 'vibe coding' hasn't produced an explosion of useful apps."

"대략 한 시간에 한 번쯤 에이전트가 수상하게 보이는 작업을 하고 있다는 걸 발견하고, 더 깊이 파보면 올바른 방향으로 돌려놓을 수 있어서 몇 시간의 낭비를 막는다... 이것이 순수한 '바이브 코딩'이 유용한 앱의 폭발을 만들어내지 못한 이유라고 본다."

이 "수상하게 보이는 작업을 발견하는 능력"이 바로 감각이다. 에이전트가 간단한 비동기 요청으로 충분한 걸 전체 백그라운드 잡 인프라를 구축하려고 할 때, "잠깐, 이건 오버엔지니어링이야"라고 멈추는 판단. 구조적 판단력이 곧 감각이다.

"동작한다"와 "훌륭하다"는 다른 차원

이게 이 글에서 가장 하고 싶었던 이야기다. Do work → Good → Great. 이 세 단계의 격차.

AI는 "Do work"을 놀랍도록 빠르게 해준다. 어떤 경우에는 "Good"까지도 간다. 하지만 "Great"으로 가는 마지막 20%는 — AI 평균 80%에 만족하면 절대 도달할 수 없는 영역이다. 고객은 마지막 2%에 감동을 느낀다. 평균적인 결과물에는 아무도 감동하지 않는다.

AI로 모든 일이 편해지고 있다면 의심해봐라 — 내 결과물들이 평균에 머무는 것은 아닌지. 80%가 범람하는 시대에 차별화는 나머지 20%에서 나온다. 그리고 그 20%는 기술이 아니라 감각의 영역이다.

KinglyCrow의 "No Skill, No Taste"가 이 맥락에서 날카롭다. taste와 skill은 2×2 매직 쿼드런트다. LLM이 스킬의 진입 장벽을 낮춘 것처럼 보이지만, taste라는 진짜 장벽은 그대로다 — 오히려 증폭됐다. 바이브 코딩으로 누구나 앱을 만들 수 있게 됐지만, taste 없이 만든 결과물은 슬롭(slop)이다. 80%의 제품이 범람하는 시대에, 나머지 20%를 가르는 건 결국 taste다. AI가 아무리 발전해도, 그 감각을 키우는 건 여전히 나의 몫이다.

LLVM과 Swift를 만든 Chris Lattner도 같은 결론에 도달했다. Anthropic이 Claude Code로 C 컴파일러를 처음부터 끝까지 구현하는 프로젝트(CCC)를 공개했을 때, Lattner는 블로그에서 이렇게 분석했다 — 구현은 교과서적이고 새로운 추상화는 없다. 강한 학부생 팀 수준이라고. 하지만 그가 진짜 주목한 건 다른 곳이었다. "구현의 자동화가 일어날수록, 설계(Design)·판단(Judgment)·감각(Taste)의 중요성이 오히려 높아진다." AI가 구현 장벽을 낮출수록, 뭘 만들지 결정하는 감각 — 그게 엔지니어의 핵심 역량이 된다는 거다.

감각은 경험의 축적이다

이 감각은 도메인 지식에서 나온다. 좋은 API를 많이 써본 사람이 좋은 API를 설계할 수 있고, 좋은 UX를 많이 경험한 사람이 좋은 UX를 판단할 수 있다. AI가 아무리 빠르게 만들어줘도, "이게 좋은 건지 아닌지"를 판단하는 건 결국 나의 몫이다.

15년간 코드를 짜면서 "이건 좋은 코드다"와 "이건 돌아가지만 좋은 코드는 아니다"의 차이를 체감으로 알게 됐다. 변수 이름 하나, 함수 구조 하나, 에러 핸들링 방식 하나에서 그 차이가 드러난다. 에이전트가 만든 코드에도 같은 기준을 적용할 수 있어야 한다. "동작한다"와 "좋다"는 다른 차원의 이야기다.

한번은 에이전트가 완벽하게 동작하는 검색 기능을 만들어준 적이 있다. 기술적으로 흠잡을 데가 없었다. 그런데 뭔가 불편했다. 한참을 들여다보다가 깨달았다 — 검색 결과가 알파벳순으로 정렬되어 있었다. 기술적으로는 맞지만, 유저 관점에서는 관련도순이 훨씬 자연스럽다. 에이전트는 "검색 기능"을 만들었지만, "좋은 검색 경험"을 만들지는 못한 거다. 이 차이를 알아채는 게 감각이다.

이렇게 연습한다

감각을 키우는 가장 확실한 방법은 좋은 것을 많이 보고, 만들고, 사용하는 거다. 기술 블로그만 읽지 말고, 디자인도 보고, 비즈니스 사례도 보고, 소설도 읽자. 박물관도 가자.

에이전트의 결과물을 그대로 수용하지 않는 습관이 감각의 출발점이다. "정말 이게 최선인가?" 항상 질문하기. "이게 왜 좋지?", "이건 왜 불편하지?" — 이 질문을 반복하면 감각이 날카로워진다.

사람들에 대한 관심도 중요하다. 고객이 뭘 원하는지, 유저가 어디서 막히는지 관찰하는 것. 기술적으로 완벽한데 유저가 쓰기 불편한 제품이 되는 건 감각이 부족해서다. 유저 인터뷰를 하든, 지원 채널을 들여다보든, 옆 사람이 앱을 쓰는 걸 어깨 너머로 보든 — 사람이 기술과 만나는 접점에서 감각이 날카로워진다.

감각은 혼자 키우기 어렵다. 다른 사람의 코드를 리뷰하고, 유저의 반응을 관찰하고, 파트너의 피드백을 듣는 것. 에이전트 시대에 감각은 더 중요해졌지만, 감각을 키우는 방법은 여전히 아날로그다. 사람과 대화하고, 세상을 관찰하고, 좋은 것을 경험하는 것. 그건 AI가 대신해줄 수 없다.

나가며

"Since the invention of the computer, the era of typing code directly into an editor is over."

"컴퓨터가 발명된 이래 에디터에 코드를 직접 타이핑하던 시대는 끝났다."

맞는 말이다. 하지만 끝난 건 타이핑이지, 엔지니어링이 아니다.

분해 능력, 컨텍스트 설계, 완료 정의, 실패 복구, 관찰 가능성, 메모리 설계, 병렬 관리, 추상화 계층, 감각 — 이 9가지를 가만히 들여다보면, 사실 AI 시대 이전에도 좋은 엔지니어가 갖추고 있던 것들이다. 에이전틱 엔지니어링은 이 능력들의 확장이고 증폭이다. 새로운 게 아니라, 원래 중요했던 것들이 더 중요해진 거다.

다만 한 가지 달라진 게 있다면, 이 능력들의 효과가 극적으로 증폭됐다는 거다. 예전에는 분해 능력이 조금 부족해도 직접 코드를 짜면서 보정할 수 있었다. 하지만 에이전트에게 일을 맡기는 시대에는, 분해가 잘못되면 그 잘못이 에이전트의 속도만큼 빠르게 증폭된다. 좋은 설계의 레버리지도 커졌지만, 나쁜 설계의 피해도 커진 거다.

Stanford에서 AI-native 엔지니어링을 가르치는 Mihail Eric의 조언이 실용적이다 — 점진적으로 추가하라. 한 에이전트 워크플로우를 정말 잘 해내는 것부터 시작. 에이전트 하나로 복잡한 소프트웨어를 만들 수 있을 때, 그때 두 번째를 붙인다. 한 번에 10개가 아니라 한 걸음씩.

Mihail은 또 하나 중요한 점을 짚었다. 멀티 에이전트를 잘 다루는 사람들을 관찰했더니, 실제로 인간 개발자들을 관리해본 경험이 있는 사람들 이었다고. CTO 시절 스쿼드 6개를 관리하던 내 경험이 에이전트 관리에 직접적으로 도움이 된 것도 같은 맥락이다.

나도 아직 갈 길이 멀다. 어떤 날은 에이전트와 찰떡처럼 호흡이 맞아서 "이게 미래구나" 하고 감탄하고, 다음 날은 에이전트가 삽질하는 걸 보면서 "내가 직접 짜는 게 빠르겠다"고 투덜거린다.

하지만 방향은 보인다. 그리고 그 방향은 "더 좋은 프롬프트를 쓰는 것"이 아니라, "에이전트가 잘 작동하는 환경을 설계하는 것" 이다. 프롬프트는 도구고, 환경 설계가 본질이다.

결국 이건 감각과 경험의 문제다. 도구는 바뀌어도 본질은 남는다. 좋은 엔지니어가 에이전트를 만나면 위대한 엔지니어가 된다. 나쁜 설계가 에이전트를 만나면 나쁜 결과물이 빠르게 쏟아진다.

이 9가지 능력은 별개가 아니라 서로 연결되어 있다. 분해를 잘 하면 완료 정의가 명확해지고, 컨텍스트를 잘 설계하면 실패 복구가 쉬워지고, 메모리가 쌓이면 관찰 가능성이 높아지고, 병렬 관리 경험이 추상화 계층을 올리게 만들고, 이 모든 것의 바탕에 감각이 있다. 하나씩 키우다 보면 나머지도 따라온다. 어디서 시작하든 상관없다. 중요한 건 시작하는 거다.

Mihail이 학생들에게 강조한 것처럼 — 실험이 AI 네이티브 소프트웨어 개발자가 되는 핵심이다. 결국 스스로 벽에 머리를 조금 찧어봐야 한다. 이 글에서 내가 공유한 AddPlan의 핑퐁 반나절, CLI의 빈 껍데기, 재분배 엔진의 무한루프, liquidglass의 "이상한데 그냥 두자" — 전부 벽에 머리를 찧은 결과물이다. 그 찧음 없이는 9가지 능력도 체화되지 않는다.

"It is a deep, improvable skill."

"깊고 개선 가능한 스킬이다."

매일 조금씩 나아지면 된다. 완벽할 필요 없다. 방향만 맞으면 된다.

6개월 전의 나에게 "너의 AI 에이전트가 밤새 코드를 짜고, 아침에 PR 리뷰만 하면 돼"라고 말했으면 웃었을 거다. 지금은 그게 일상이다. 6개월 후에는 또 어떤 일상이 펼쳐질지 상상이 안 된다. 하지만 한 가지는 확신한다 — 그때도 분해 능력은 필요하고, 컨텍스트 설계는 중요하고, 감각은 대체 불가능할 거다.

그 쇼의 주인공은 AI가 아니라, AI를 잘 다루는 엔지니어다.

References

AI는 당신만큼만 똑똑하다

Tony Cho (https://flowkater.io) — Sat, 28 Feb 2026 06:00:00 GMT

AI는 당신만큼만 똑똑하다

"코드를 읽지 않는 시대, 엔지니어는 무엇을 읽어야 하는가"를 올리고 예상보다 많은 분들이 읽어주셨다. 그 글에서 미처 다 못한 이야기를 조금 더 풀어보고 싶어졌다. AI 시대에도 끊임없이 성장을 고민하는 엔지니어들에게, 내가 최근 겪은 경험과 몇 가지 사례를 함께 나눠보려 한다.

같은 AI, 다른 결과

Stripe가 3,000명 엔지니어에게 Cursor를 배포했다. 개발 인프라 총괄인 Scott MacVicar는 주니어가 가장 큰 이득을 볼 거라 예상했다. 경험 부족을 AI가 메워줄 거라는 합리적인 가정이었다. 결과는 반대였다.

"He expected junior engineers to benefit most, using AI to compensate for limited experience. Instead, he's seen the [tenure advantage] — more experienced engineers get even more value."

"그는 주니어 엔지니어가 가장 많은 혜택을 받을 거라 예상했다. 경험 부족을 AI로 보완할 수 있을 거라고. 하지만 실제로는 [재직 기간 우위] — 경험 많은 엔지니어가 더 큰 가치를 얻었다."

— Scott MacVicar, Head of Developer Infrastructure, Stripe

비슷한 시기에 MIT Media Lab에서 나온 연구는 더 흥미로웠다. EEG로 뇌파를 직접 측정한 연구인데, AI를 많이 쓸수록 뇌의 신경 연결이 체계적으로 약화됐다. LLM을 활용한 그룹은 자기가 쓴 글조차 제대로 인용하지 못했다. 4개월간 모든 지표에서 Brain-only 그룹보다 열등했다.

"Brain connectivity systematically scaled down with the amount of external support."

"뇌의 연결성은 외부 지원의 양에 비례해 체계적으로 약화되었다."

그런데 여기서 잠깐, 반론이 있다. GitHub Copilot 연구에서는 정반대 결과가 나왔다. 프로그래밍 경험이 적은 개발자가 Copilot으로 더 큰 생산성 향상을 보였다.

"The results suggest developers with less programming experience are more likely to benefit from Copilot."

"결과는 프로그래밍 경험이 적은 개발자가 Copilot으로 더 큰 혜택을 받을 가능성이 높다고 시사한다."

그런데 Stripe 데이터는 정반대다. 왜? 측정하는 것이 다르기 때문이다. Copilot 연구는 생산성 — 얼마나 빨리 코드를 완성하느냐 —을 측정했다. Stripe는 가치 — 얼마나 의미 있는 결과를 만들어내느냐 —를 봤다. 주니어는 AI로 속도를 높일 수 있다. 하지만 속도와 가치는 다른 차원의 문제다. 빠르게 잘못된 방향으로 달리는 것은 가치가 아니다.

이 두 데이터를 나란히 놓으면 불편한 그림이 나온다. AI는 강한 자를 더 강하게, 약한 자를 더 약하게 만들고 있다. 같은 도구인데 격차가 벌어진다. 왜?

이전 글에서 나는 "AI는 거울이다"라고 썼다. 거울에 비출 게 있는 사람이 되는 것이 핵심이라고. 그런데 그 글을 쓰고 나서 계속 붙잡고 있던 질문이 있다. 그 "비출 것"은 대체 어떻게 만들어지는 건가? 프롬프트를 잘 쓰면 되는 건가? 아니었다.

인풋이 없으면 아웃풋도 없다

솔직히 고백하자면, 나도 한때 프롬프트 엔지니어링에 꽂혔던 적이 있다. 프롬프트 템플릿을 모으고, 구조화된 지시문을 다듬으면 AI를 더 잘 쓸 수 있을 거라 믿었다. (지금 생각하면 민망하다.)

그런데 돌아보니 내가 AI를 잘 쓰게 된 시점은 프롬프트를 잘 쓰게 된 시점이 아니었다. 내 도메인의 깊이가 어느 임계점을 넘은 시점이었다. TDD를 10년 넘게 해왔으니까 AI에게 테스트 먼저 작성하라고 지시할 수 있었다. DDD를 꽤 오래 고민해왔으니까 바운디드 컨텍스트를 먼저 정의하자고 말할 수 있었다. 프롬프트가 좋았던 게 아니라, 내 머릿속에 쌓인 맥락이 자연스럽게 좋은 지시로 흘러나온 것뿐이다.

최근에 이걸 뼛속까지 느낀 경험이 있다. UI 서버 연동 작업을 하면서, AI가 작성한 구현 계획을 20번 넘게 반복 검증했다. 계획 문서 자체는 꽤 완성도가 높았다. 그런데 실제로 돌려보니 제대로 된 값이 안 나왔다. 오류도 뜨지 않았다. 폴백값이 조용히 내려오고 있었기 때문이다. 도메인 요구사항의 의도와는 다른 값이 내려오고 있었지만, 시스템적으로는 정상 동작하는 것처럼 보였다.

개발하는 서비스의 비즈니스 로직이 점점 복잡해지면 AI는 맥락을 잃고 헤매기 시작한다. 문제를 좁히고, 오류의 범위를 좁히고, AI에게 나눠서 문제를 풀게 던져주는 역할은 여전히 사람의 몫이다. 결과물에 대한 검증, 테스트, 그 꼼꼼함도 마찬가지다. AI는 계획대로 구현했다. 하지만 그 계획이 요구사항과 맞는지 확인하는 건 결국 내 손으로 해야 했다.

AI는 엄청나게 발전한 것도 맞고, 생산성을 어마어마하게 올려준 것도 맞다. 하지만 결과물의 완성도와 퀄리티는 결국 도메인 전문성과 꼼꼼함 — AI 시대 이전에도 필요했던 능력 —으로 귀결된다.

그런데 더 불편한 사실이 있다. 인풋이 부족한 사람에게 AI는 "부족하다"고 말해주지 않는다. 오히려 잘하고 있다고 말해준다.

Stanford과 Carnegie Mellon 공동 연구팀이 ChatGPT, Claude, Gemini 등 11개 AI를 테스트한 결과가 Science에 실렸다. AI는 인간보다 평균 49% 더 자주 사용자의 행동을 긍정했다. Reddit r/AmITheAsshole에서 커뮤니티가 "당신이 잘못했다"고 결론 내린 사례를 던져도, 챗봇은 51% 확률로 사용자 편을 들었다. 유해하거나 불법적인 행동 쿼리에서도 47% 확률로 사용자를 지지했다.

2,405명을 대상으로 한 후속 실험은 더 충격적이었다. 아첨하는 AI와 대화한 참여자들은 자신이 옳다는 확신이 강해졌고, 행동을 바꾸려는 의지가 낮아졌다. 그리고 가장 당혹스러운 발견 — 사람들은 아첨하는 AI를 더 신뢰했다. "객관적이고 공정하다"고 평가했다. 자신에게 쓴소리하는 AI보다 달콤한 AI를 더 좋다고 느꼈다.

"사용자들은 AI가 아첨적이고 칭찬하는 방식으로 행동한다는 것을 알고 있습니다. 그러나 그들이 모르는 것, 그리고 우리를 놀라게 한 것은, 아첨성이 그들을 더 자기중심적으로, 더 도덕적으로 경직되게 만들고 있다는 것입니다."

— Dan Jurafsky, Stanford 언어학·컴퓨터과학 교수

MIT 연구와 겹쳐보면 악순환이 선명해진다. AI를 많이 쓸수록 뇌의 연결이 약해지고(MIT), 약해진 뇌에 AI는 "잘하고 있다"고 속삭이며(Stanford), 그 속삭임을 들은 사람은 더 AI에 의존한다. AI는 당신만큼만 똑똑한 게 아니라, 당신이 듣고 싶은 말만 해주는 거울이다.

결국 AI 시대에 가장 위험한 사람은 AI를 못 쓰는 사람이 아니다. AI의 아첨을 비판적 검증 없이 받아들이는 사람이다.

예전에 쓴 글에서 나는 주니어 개발자들에게 이렇게 말했다. "책 많이 읽고 내 생각을 정리해라. 그게 문해력이고, AI 시대에 가장 중요한 경쟁력이다." 하지만 이건 주니어만을 위한 조언은 아니다. AI 시대에 살아남기 위한 나를 포함한 우리 모두를 위한 다짐이다.

나도 요즘 더 많은 (기술 책이 아닌) 책을 읽으려고 노력한다. 예전에는 속도가 느려 미루기만 했던 원서나 해외 아티클도 자비스 덕분에 몇 배는 더 소화해내고 있다. 블로그 글 쓰기를 통해, 소비자 입장에서 글을 어떻게 읽고 소화해 내 생각으로 엮을지 계속 연습하는 것도 AI 활용에 훨씬 도움이 된다. (3단계 접근법 글을 썼던 이유도 그거다. 그냥 "읽었다"고 치고 넘어가면 한 달 뒤에 아무것도 남지 않는다.)

Wharton의 Ethan Mollick 교수가 재밌는 실험을 했다. Executive MBA 학생들에게 AI로 프로토타입을 만들게 했는데, 코딩 경험이 전혀 없는 사람들이 4일 만에 완성했다. 성공의 열쇠는 뭐였을까?

"It helped that they had some management and subject matter expertise because it turns out that the key to success was actually...telling the AI what you want."

"경영과 해당 분야 전문성이 도움이 됐다. 왜냐하면 성공의 열쇠는 결국... AI에게 뭘 원하는지 말하는 것이었기 때문이다."

— Ethan Mollick

"뭘 원하는지 안다"는 것 자체가 전문성이다. 프롬프트 템플릿을 외워서 되는 게 아니라, 도메인을 이해하는 사람이 자연스럽게 좋은 지시를 내리는 거다. 순서가 반대다.

결국 AI를 잘 쓰려면 AI에 대해 배우는 게 아니라, 내 도메인의 깊이를 키워야 한다. 인풋의 질이 아웃풋의 질을 결정한다. Simon Willison이 말한 것처럼, 새 코드를 만드는 비용은 거의 공짜에 가까워졌지만 좋은 코드를 만드는 비용은 여전히 비싸다. 그 비용은 프롬프트가 아니라 사람의 두께에서 나온다.

No Skill. No Taste 글에서도 재밌는 주장이 있다. 지금 개발자·비개발자들이 열심히 만드는 바이브 코딩 앱들은 대부분 Skill과 Taste 4분면의 최하위 영역에 위치한다는 것. (Todo 생산성 앱 같은.) 반면 같은 Todo App이더라도 감각적인 디자인, 기존의 기대치를 넘어서는 완성도가 있다면 CRUD 앱이라도 인기 앱이 될 수 있다는 주장이다. Skill은 AI가 대체할 수 있지만 Taste — 즉 도메인에 대한 감각과 안목 —는 결국 사람에게서 나온다. (개발자들이여, 고개를 들어 주위를 돌아보아라!)

AI에게 답을 구하지 않는다

새 기능을 구현할 때를 생각해보자. 대부분의 사람이 AI에게 "이 기능 만들어줘"라고 한다. 키워드를 입력하고 답을 기대한다. 하지만 LLM은 검색 엔진이 아니다. 대화 상대다.

나는 작업 전에 항상 interview라는 스킬을 쓴다. 새 기능이든 아키텍처 설계든, 내가 문서를 사전에 얼마나 꼼꼼하게 작성했어도 AI가 바로 코드를 쓰지 않는다. 대신 AI가 나에게 질문을 던진다. "이 기능의 핵심 유저 시나리오가 뭔가?", "기존 모듈과 경계는 어떻게 나눌 건가?", "실패 시 폴백 전략은?", "성능 요구사항이 있나?" — 이런 질문들을 통해 내가 놓치고 있던 엣지 케이스와 설계 결정을 먼저 끌어낸다.

최근에 재분배 엔진을 작업하면서 이 인터뷰의 가치를 확실히 체감했다. 엔진에서 처리하는 타입이 두 종류인데, 각각 정책이 다르다. 나는 A 타입만 생각하고 기획안을 업데이트했다. 나름 꼼꼼하게 작성했고, AI에게 피드백까지 받았다. 그런데 실제로 돌려보니 B 타입까지 같이 오버라이드되면서 한참을 헤맸다. 인터뷰 스킬에서는 이런 걸 놓치지 않는다. "B 타입은 어떻게 처리하나요?"라고 AI가 먼저 물어보기 때문이다.

인터뷰는 "AI가 모호하거나 애매한 부분을 무조건 해소"하는 과정이다. 기능이 복잡해질수록 점점 유용해진다. 복잡한 엔진 알고리즘을 구현하거나 UI 디테일을 잡을 때, 기획안의 허점을 찾고 엣지 케이스를 모두 문서에 올린 뒤 실행하면, 원샷에 나오는 결과물의 퀄리티가 이전과는 확실히 달랐다.

이 패턴이 왜 강력한가? 생각해보면 좋은 멘토가 하는 것도 정확히 이거다. 답을 주지 않는다. 대신 "왜 그렇게 생각해?", "그 가정이 틀리면 어떻게 되지?", "구체적인 사례가 있어?" 같은 질문으로 내 사고를 확장시킨다.

Jeremy Utley가 추천하는 프롬프트가 있다.

"당신은 AI 전문가입니다. 제 워크플로우와 책임 범위, KPI, 목표에 대해 충분한 맥락을 파악할 때까지 한 번에 하나씩 질문해 주세요."

AI에게 질문하지 말고 AI가 나에게 질문하게 하라. 이 전환이 AI 활용의 가장 큰 레버리지 포인트라고 본다.

pandas 창시자 Wes McKinney의 태도도 같은 맥락이다.

"I don't describe the way I work now as 'vibe coding'—I've been building tools to bring rigor and continuous supervision to my parallel agent sessions, and to heavily scrutinize the work that my agents are doing."

"지금 내 작업 방식을 '바이브 코딩'이라고 부르지 않는다. 병렬 에이전트 세션에 엄밀함과 지속적 감독을 가져오는 도구를 만들고 있고, 에이전트가 하는 작업을 철저히 검토하고 있다."

맥락이 두꺼운 사람은 AI를 "쓰는" 게 아니라 AI를 "관리"한다. AI에게 답을 구하는 게 아니라, AI를 통해 내 생각을 검증하고 구조화하는 것. 그게 같은 도구를 쓰면서도 다른 결과를 만드는 방법이다.

격차는 벌어지고 있다

개인의 이야기를 했으니, 조직 차원으로 시야를 넓혀보자.

Stripe가 만든 Minions 시스템이 좋은 사례다. 3,000명에게 Cursor를 배포한 것에서 한 발 더 나아가, 매주 1,000개 이상의 PR을 자동 생성하는 시스템을 구축했다. 하지만 모든 PR은 인간이 리뷰한다.

"Even though minions can complete tasks end to end, humans remain firmly in control of what actually goes live."

"미니언이 작업을 처음부터 끝까지 완료할 수 있지만, 실제로 라이브에 나가는 것에 대한 통제는 인간이 확고히 쥐고 있다."

그리고 그 인간 리뷰에서 시니어가 더 큰 가치를 만들어냈다. AI가 코드를 생성하는 속도는 모두에게 똑같았지만, 그 코드를 평가하고 방향을 잡는 능력은 경험에 비례했다.

McKinsey가 2,000개 조직을 조사한 결과도 같은 패턴을 보여준다. 80%가 AI를 도입했지만, 실질적 가치를 창출하고 있는 곳은 고작 5%에 불과했다. BCG의 1,250개 기업 분석에서도 거의 동일한 숫자가 나왔다.

왜 95%는 효과를 보지 못했을까. 생각해보면 답은 단순하다. AI를 도구로써 기존 방식 위에 얹기만 하면, 원래 병목이 일어나던 곳에서 여전히 막힌다. 코드 작성이 느려서 병목이었던 곳은 AI로 해결된다. 하지만 진짜 병목이 의사결정 구조나 조직 문화에 있었다면, AI를 아무리 도입해도 그 병목은 그대로다.

"High performers are nearly 3x more likely to have fundamentally redesigned workflows as part of their AI efforts."

"고성과 기업은 AI 도입의 일환으로 워크플로우를 근본적으로 재설계한 비율이 3배 높다."

5%의 기업들이 다른 건 AI를 잘 도입해서가 아니다. AI 도입 이전에 기존의 관행과 시스템을 혁신했기 때문이다. 순서가 반대다.

이전 글에서 다뤘던 F1 윌리엄스 — 제임스 바울스의 리더십도 같은 맥락이다. 바울스가 윌리엄스에서 한 일은 새로운 도구를 도입한 게 아니었다. 엑셀 시트로 F1 머신을 관리하던 시스템을 조직 문화와 프로세스부터 뜯어고쳤다. 도구를 도입하는 것보다 그에 맞춰 기존 시스템을 개혁하는 게 훨씬 힘들지만, 그만큼 가치 있는 일이다. 그리고 이건 단순히 시스템과 관행의 문제가 아니라, 조직 문화와 리더십까지 엮여 있는 문제다.

Shopify CEO Tobi Lütke가 전 직원에게 "AI 사용은 기본 기대치"라고 선언하면서, 새 인력 채용 전에 "이걸 AI로 안 되는 이유"를 먼저 증명하라고 요구한 것도 결국 같은 결이다. 도구를 쓰라는 게 아니라, 일하는 방식 자체를 바꾸라는 거다.

결국 사람이 문제다. AI를 기존 프로세스 위에 얹는 건 95%의 방법이다. 5%는 프로세스 자체를, 조직 문화 자체를, 사람이 일하는 방식 자체를 다시 설계한다.

당신은 AI를 기존 방식에 "추가"하고 있는가, 아니면 방식 자체를 다시 설계하고 있는가?

나가며

도구는 모두에게 같다. 차이를 만드는 건 도구 앞에 서는 사람의 두께다.

하네스 엔지니어링을 하고 워크플로우를 만드는 것. 이걸 도입했을 때 마치 남들보다 앞서는 것처럼 느낀다. 그리고 새로운 도구가 뉴스에 나오면 우리 모두 FOMO를 느끼며 쫓아가기 바쁜 시기다. 하지만 결국 어느 시점에 엔지니어링 워크플로우는 상향 평준화되고 보급화될 것이다. 그때에도 살아남는 엔지니어가 되려면 우리는 무엇을 준비해야 할까. 내 생각에는 본질은 변하지 않을 것이라고 생각한다.

코드만 잘 쓰면 된다고 믿었던 시절이 있었다. 나도 그랬다. 그런데 AI가 코드를 대신 써주는 시대가 오니까, 정작 남는 건 코드 바깥에 있던 것들이었다. 도메인을 이해하는 깊이, 요구사항을 검증하는 꼼꼼함, 엣지케이스를 미리 떠올리는 경험, 방향을 잡는 판단력. 결국 AI 시대 이전에도 중요했던 것들이 AI 시대에 더 중요해졌다.

"If you've never articulated what makes your work yours, AI will give you average. But if you've done the work to know yourself as a creative? AI becomes an extension of your voice, not a replacement for it."

"자기 일의 고유함을 정의해본 적이 없다면, AI는 평균을 줄 것이다. 하지만 창작자로서 자신을 아는 작업을 해왔다면? AI는 목소리의 대체가 아니라 확장이 된다."

— Jeremy Utley, Stanford d.school

AI는 당신의 목소리를 대체하지 않는다. 증폭할 뿐이다. 증폭할 목소리가 있는가, 그게 질문이다.

References

코드를 읽지 않는 시대, 엔지니어는 무엇을 읽어야 하는가

Tony Cho (https://flowkater.io) — Thu, 19 Feb 2026 03:00:00 GMT

AI 쓴 개발자가 17% 덜 배웠다

AI를 쓰면 쓸수록 멍청해진다 — 그런 연구가 나왔다. Anthropic이 발표한 논문인데, AI 지원을 받아 코딩 과제를 완료한 개발자들이 AI 없이 작업한 개발자들보다 퀴즈 점수가 17% 낮았다. 새로운 라이브러리를 배우는 실험이었는데, AI를 쓴 그룹은 과제는 완료했지만 정작 그 라이브러리의 개념을 제대로 이해하지 못한 것이다.

처음 이 숫자를 봤을 때 불편하기보단 신기했고 흥미로웠다. Claude Code를 만든 곳에서 직접 발표했다는 것도 그렇고, 과연 어떤 실험이기에 그렇게 결론 내렸을까 궁금했다.

역시 이 연구를 곧이곧대로 받아들이기엔 맥락을 좀 짚어야 한다. 실험은 35분짜리 짧은 코딩 과제였고, 사용된 모델은 GPT-4o — 지금 기준으로는 이전 세대에 가깝다. 실험 환경은 실무와 거리가 있었다. 현업에서 몇 달에 걸쳐 프로젝트를 진행하면서 AI를 쓰는 것과, 35분 안에 처음 보는 라이브러리로 과제를 끝내는 건 완전히 다른 상황이다.

그런데 이 연구가 말하는 본질은 다른 데 있다. 연구진이 발견한 건 단순히 "AI를 쓰면 학습이 줄어든다"가 아니었다. 같은 AI를 쓰면서도 결과가 극명하게 갈렸다 는 거다. 어떤 사람은 AI에게 코드를 통째로 맡기고 복붙했고, 어떤 사람은 AI에게 개념만 물어보고 코드는 직접 짰다. 전자는 가장 빠르게 끝냈지만 가장 적게 배웠고, 후자는 오류도 많이 만났지만 퀴즈 점수가 월등히 높았다.

잘못 사용하면 우리는 발전하지 못할 수 있다.

이게 이 연구가 진짜 하고 싶은 말이라고 본다.

코드를 읽는 시대에서 지시하는 시대로

이 연구 결과를 곱씹고 있을 때, 흥미로운 글 하나를 읽었다. Ben Shoemaker라는 엔지니어가 쓴 "In Defense of Not Reading the Code"(코드를 안 읽는 것의 옹호)라는 글이었는데, 제목부터 도발적이었다. Hacker News에서 200개가 넘는 댓글이 달리며 열띤 논쟁을 불러일으켰다.

그의 요지는 이렇다. "나는 더 이상 코드를 한 줄 한 줄 읽지 않는다. 대신 스펙을 읽고, 테스트를 읽고, 아키텍처를 읽는다." 코드의 정확성을 확인하는 방법이 바뀐 거다. 스펙을 먼저 작성하고, 요구사항마다 검증 방법을 태그하고, 자동화된 테스트와 린터와 보안 스캔이 겹겹이 쌓인 하네스(harness)를 구축한 다음, 코드 생성은 AI 에이전트에게 맡긴다. 코드 리뷰 대신 하네스 엔지니어링 이라는 새로운 접근이었다.

돌아보면 나도 비슷한 방향으로 움직이고 있었다. 최근 프로젝트에서 AI에게 코드를 맡기면서 내가 가장 공들인 건 코드 자체가 아니라 테스트 하네스, AGENTS.md 같은 컨텍스트 파일, custom command, 그리고 skill 정의였다. 이 과정을 15년차 CTO가 바이브 코딩하는 방법이라는 글에서 정리한 적 있다. 코드를 한 줄 한 줄 읽는 대신, 테스트가 통과하는지, 아키텍처 제약을 지키는지를 확인하는 쪽으로 자연스럽게 이동하고 있었다. Ben의 글을 읽으면서 "아, 이게 나만 그런 게 아니었구나" 하는 안도감이 들었다.

재밌는 건, 같은 시기에 OpenAI도 비슷한 이야기를 하고 있었다. 엔지니어 세 명이 Codex 에이전트만으로 백만 줄의 코드를 만들어내 수백 명의 내부 사용자가 쓰는 제품을 완성했는데, 그들이 투자한 건 코드 품질이 아니라 그 주변의 하네스 — 문서, 의존성 규칙, 린터, 테스트 인프라, 관측성이었다. 투자하지 않은 것은 코드를 한 줄 한 줄 읽는 것이다. 이걸 보면서 결국 방향은 정해진 것 같다고 생각했다. 코드를 읽는 게 아니라, 코드가 제대로 만들어지도록 하는 환경을 읽는 시대로 가고 있다.

그래서 뭐가 다른 건가? Evan Armstrong은 이 변화를 더 큰 그림에서 설명한다. 그의 표현을 빌리면, 코드 자체가 상품화되고 있다. 여기서 상품화란, 코드 생성이 더 이상 희소한 전문 기술이 아니라 누구나 접근 가능한 범용 자원이 되고 있다는 뜻이다. 실제로 GitHub 커밋의 상당 부분이 이미 AI에 의해 생성되고 있고, 그 비율은 빠르게 늘어나고 있다. 코드를 생성하는 건 상품화되었지만, 프로덕션에서 코드를 거버닝(governing)하는 것 — 무엇이 존재해야 하는지, 어떤 데이터에 연결되는지, 누가 변경할 수 있는지 아는 것 — 은 상품화되지 않았다. 그는 이걸 컨텍스트 레이어 라고 불렀다. 조직의 암묵지가 소프트웨어가 되는 것. 에이전트에게 무엇을 해야 하는지, 어떤 순서로, 허용되는지 여부를 알려주는 조직적 지식. 소프트웨어를 만드는 것은 더 이상 어려운 부분이 아니다. 지시하는 것이 어렵다.

나도 이걸 체감하고 있다. 요즘 내가 AI와 일하면서 가장 어려운 건 코드를 짜는 게 아니라, "무엇을 만들어야 하는지"를 명확하게 정의하는 거다. 스펙이 모호하면 AI가 아무리 똑똑해도 엉뚱한 결과물이 나온다. 결국 지시의 품질이 결과의 품질을 결정한다.

Codex 딥다이브에서도 같은 패턴이 보였다. Codex 팀의 엔지니어들은 이제 에이전트 관리자(agent manager) 가 되었다. 한 탭에서는 코드 리뷰가 돌아가고, 다른 탭에서는 기능이 구현되고, 세 번째 탭에서는 보안 감사가 진행된다. 4~8개의 병렬 에이전트를 동시에 관리하면서, AGENTS.md라는 파일로 에이전트에게 코드베이스 탐색 방법, 테스트 실행 명령, 프로젝트 표준을 알려준다. README가 인간을 위한 것이라면, AGENTS.md는 AI를 위한 것이다.

그리고 결국 Steve Yegge가 이 흐름에 가장 직설적인 이름을 붙였다. 40년차 소프트웨어 엔지니어인 그는 "손코딩의 시대는 끝났다" 고 선언하면서 AI 채택의 8단계를 그려놓았다. Level 1은 AI를 안 쓰는 것, Level 4부터는 diff를 보지 않기 시작하고, Level 6에서는 에이전트를 여러 개 띄우고, Level 8에서는 에이전트를 조율하기 위해 직접 오케스트레이터를 구축한다. 그의 표현을 빌리면, IDE를 열어서 코드를 꼼꼼히 리뷰한 다음 체크인하는 사람을 보면 안타깝다고 — 아는 사람 중 최고의 엔지니어인데, 그 방식으로는 도태될 거라고.

솔직히 나는 지금 어디쯤인지 생각해봤다. Level 6과 7 사이 어딘가. diff를 완전히 안 보지는 않지만, 핵심 로직이 아니면 테스트 통과 여부로 판단한다. 6개월 전만 해도 모든 코드를 직접 확인해야 마음이 놓였는데, 지금은 하네스를 믿고 넘어가는 순간이 늘었다. 코드를 한 줄 한 줄 읽는 것에서, 시스템 전체를 검증하는 것으로 시야가 이동한 거다.

Yegge의 표현이 도발적이긴 하지만, 돌아보면 나도 이미 그 방향으로 움직이고 있었다. 코드를 직접 읽고 직접 쓰는 것에서, 스펙을 정의하고 에이전트를 지시하고 결과를 검증하는 것으로. 엔지니어의 역할이 분명히 이동하고 있다.

근데 스펙만 잘 쓰면 되는 걸까? — 결승선 게임과 복리 게임

여기서 한 발짝 더 들어가야 할 게 있다. 이 모든 이야기 — 스펙을 정의하고, 하네스를 구축하고, AGENTS.md를 정성껏 쓰고, 에이전트에게 맡긴다 — 의 이면에 깔린 가정이 하나 있다. "스펙만 잘 쓰면 원하는 결과물이 나온다"는 가정. 생각해보면 이건 꽤 위험한 가정이다.

Kent Beck은 이걸 결승선 게임(The Finish Line Game) 이라고 불렀다. X를 하는 소프트웨어가 필요하다, X에 도달하면 끝이다. 스펙 기반 개발 뒤에 숨어 있는 가정이 바로 이거다 — 우리가 결승선 게임을 하고 있다는 것.

근데 정말 그런가? 우리가 실제로 하는 건 대부분 복리 게임(The Compounding Game) 이다. 처음 만든 것이 다음 것을 위한 자원이 되고, 그 다음 것이 또 그 다음을 위한 자원이 된다. 프로덕트는 계속 진화하고, 코드베이스는 계속 쌓이고, 오늘의 아키텍처 결정이 6개월 뒤의 가능성을 열거나 닫는다. 일회성 스크립트가 아닌 이상, 소프트웨어 개발은 본질적으로 복리 게임이다.

이 구분이 나한테 꽤 울림이 있었다. 나도 최근에 AI로 빠르게 기능을 찍어낼 때 "잘 되고 있다"는 착각에 빠진 적이 있다. 기능은 완성됐는데, 나중에 그 위에 뭔가를 올리려고 하면 구조가 버티질 못하는 거다. 결승선은 통과했는데 복리가 쌓이지 않는 전형적인 상황이었다.

Kent Beck의 표현이 인상적이었는데, "더 나은 agent.md 파일로는 복리 게임을 이길 수 없다" 는 거다. AGENTS.md를 아무리 정교하게 써도, 에이전트를 아무리 잘 조율해도, 어느 시점에서 시스템의 복잡성이 AI의 역량을 초과한다. 그 순간 아직 벌어들일 가치가 한참 남은 상태에서 게임 오버가 된다. 결승선 게임의 도구를 아무리 갈고닦아도 복리 게임의 본질은 바뀌지 않는다.

결국 하네스 엔지니어링이든, 에이전트 관리든, 핵심은 단순히 "지금 이 기능을 잘 만드는 것"이 아니라 시스템이 복리로 쌓이도록 설계하는 것 이다. 오늘 만든 코드가 내일의 자원이 되게 하고, 오늘의 아키텍처가 다음 기능의 토대가 되게 하는 것. 그게 에이전트에게 위임할 수 없는 엔지니어의 역할이다.

AI는 거울이다

그런데 여기서 중요한 질문이 생긴다. 모두가 같은 AI를 쓰는데, 왜 결과가 이렇게 다를까?

스탠포드에서 16년간 창의성을 가르쳐 온 Jeremy Utley 교수의 말이 정확히 이 지점을 찌른다.

"AI는 거울이다. 게으르고 싶은 사람에게는 게으름을 도와줄 것이고, 더 예리해지고 싶은 사람에게는 날카로움을 도와줄 것이다."

이 한 문장이 내가 AI를 쓰면서 경험한 모든 것을 요약한다.

내 경험을 이야기해 보겠다. 나는 TDD(테스트 주도 개발)를 꽤 오래 해왔고, DDD(도메인 주도 설계)와 아키텍처에 관심이 많은 편이다. AI와 코딩할 때 이 배경이 그대로 드러난다. 내가 "먼저 테스트를 작성해. Red-Green-Refactor 사이클을 따라"라고 지시하면, AI는 TDD 흐름을 따른다. "이 도메인의 바운디드 컨텍스트를 먼저 정의하자"라고 하면, AI는 도메인 모델링부터 시작한다. 내가 아키텍처 결정을 먼저 내리고 그 제약 안에서 구현을 요청하면, 결과물의 품질이 확연히 다르다.

반대로, "그냥 이 기능 만들어줘"라고 던지면? AI는 돌아가는 코드를 만들어준다. 근데 구조가 엉망이다. 테스트도 없고, 에러 핸들링도 대충이고, 나중에 유지보수할 생각 따위는 없는 코드가 나온다. AI가 멍청해서가 아니다. 내가 신경 쓰지 않은 부분을 AI도 신경 쓰지 않는 것뿐이다.

일종의 페어 프로그래밍이랄까. AI가 키보드를 잡고, 나는 옆에서 방향을 잡아주는 느낌인데, 내가 방향을 모르면 AI도 아무 데나 간다. 내가 "여기서 이렇게 하면 안 돼"라고 말할 수 있어야 AI도 제대로 된 길을 찾는다.

Anthropic 연구가 발견한 6가지 AI 사용 패턴을 다시 보면 이게 더 선명해진다. 가장 낮은 점수를 받은 세 패턴 — AI 위임, 점진적 AI 의존, 반복적 AI 디버깅 — 의 공통점은 "인지적 오프로딩"이었다. 생각하는 것 자체를 AI에게 떠넘긴 거다. 코드 작성을 통째로 맡기거나, 처음엔 질문하다가 결국 전부 위임하거나, 디버깅조차 AI에게 의존하거나. 가장 빠르게 끝냈지만 가장 적게 배웠다.

반면 가장 높은 점수의 세 패턴 — 생성 후 이해, 하이브리드 코드-설명, 개념적 탐구 — 은 달랐다. 특히 개념적 탐구 패턴이 인상적이었는데, 이 그룹은 AI에게 개념만 물어보고 코드는 직접 짰다. 오류도 많이 만났지만 스스로 해결했고, 고득점 패턴 중 가장 빨랐다. AI 위임 다음으로 전체에서 두 번째로 빨랐다는 게 핵심이다. 이해하면서도 빠를 수 있다.

또 하나 흥미로웠던 건 생성 후 이해 패턴이다. 이 그룹은 AI에게 코드를 생성시킨 다음, 그 코드에 대해 후속 질문을 했다. "이 부분이 왜 이렇게 작동해?" "이 패턴의 의도가 뭐야?" AI 위임 그룹과 거의 똑같아 보이지만, 딱 하나 — 이해를 점검하는 단계 — 가 결과를 완전히 갈랐다.

같은 도구, 같은 모델, 같은 과제. 그런데 결과가 이렇게 다르다. 도구의 문제가 아니라 쓰는 사람의 문제 라는 거다.

개인 차원에서 AI가 거울처럼 작동한다면, 조직 차원에서는 어떻게 나타날까? Berkeley 연구가 흥미로운 답을 보여준다. UC Berkeley 연구진이 8개월간 200명 규모 기술 기업을 관찰했는데, AI가 비개발자의 코딩을 가능하게 만들자 재밌는 일이 벌어졌다. PM이 코드를 짜고, 연구원이 엔지니어링을 했다. 그 결과? 엔지니어들은 동료의 AI 코드를 리뷰하고 수정하는 데 더 많은 시간을 쓰게 됐다. "바이브 코딩"하는 동료를 코칭하고, 미완성 PR을 마무리해주는 일이 늘어났다.

생각해보면 이것도 거울이다. AI가 누군가의 능력 부족을 메워주는 것처럼 보이지만, 실제로는 그 부족함이 결국 다른 형태로 드러나는 것뿐이다. PM이 AI로 코드를 짤 수 있게 됐지만, 그 코드의 품질을 판단하고 수습하는 건 여전히 코드를 깊이 아는 엔지니어의 몫이었다.

내 경험을 하나 더 이야기하면, AGENTS.md나 프로젝트의 컨텍스트 파일을 정성껏 작성할수록 AI의 결과물이 눈에 띄게 좋아진다. 프로젝트의 아키텍처 결정 이유, 코딩 컨벤션, 도메인 용어 정의 같은 것들을 명시적으로 적어두면, AI가 그 맥락 안에서 훨씬 일관된 코드를 만들어낸다. 반대로 맥락 없이 던지면, 매번 다른 스타일의 코드가 나오고, 그걸 정리하는 데 오히려 시간이 더 든다.

결국 AI는 내가 가진 것을 증폭 하는 도구다. 내가 좋은 아키텍처 감각을 가지고 있으면 그걸 증폭하고, 테스트에 대한 감각이 있으면 그것도 증폭한다. 하지만 내가 가지고 있지 않은 것을 만들어주진 않는다.

거울의 한계: 내가 못하는 부분은 비추지 못한다

여기서 불편한 진실 하나를 짚어야 한다. AI가 거울이라면, 거울에 비출 게 있어야 한다.

내가 TDD를 잘 아니까 AI에게 TDD를 시킬 수 있다. 내가 도메인 모델링을 할 줄 아니까 AI에게 바운디드 컨텍스트를 정의하라고 지시할 수 있다. 그런데 내가 모르는 영역은? AI가 아무리 좋아도 내가 뭘 모르는지 모르면, 그 부분은 요청조차 할 수 없다.

보안에 대한 깊은 이해가 없으면, AI에게 보안 리뷰를 시켜도 어떤 결과가 충분한지 판단할 수 없다. 성능 최적화에 대한 감각이 없으면, AI가 만든 코드의 성능 문제를 알아차리지 못한다. 데이터베이스 설계 원칙을 모르면, AI가 제안한 스키마가 적절한지 평가할 수 없다.

AI는 내 강점을 극대화하지만, 내 사각지대는 그대로 남긴다. 오히려 더 위험해질 수도 있다. AI가 빠르게 결과물을 만들어주니까, 사각지대에 있는 문제를 인지하지 못한 채 더 빠르게 잘못된 방향으로 갈 수 있다.

Anthropic 연구의 "점진적 AI 의존" 패턴이 바로 이거다. 처음엔 질문을 하면서 이해하려 하지만, 점점 편해지면서 결국 전부 위임하게 되고, 자기가 뭘 모르는지도 모르는 상태가 된다. 두 번째 과제에서 개념 숙지가 완전히 실패한 이유다. 여튼 "어차피 AI가 해줄 텐데"라는 생각은, 이 연구에서 가장 낮은 점수를 받은 "AI 위임" 패턴 그 자체다. 가장 빠르게 끝내지만 가장 적게 배우는 방식.

Berkeley 연구에서 비개발자들이 AI로 코드를 짰을 때도 마찬가지였다. PM이 AI로 코드를 작성할 수 있게 됐지만, 코드 품질을 판단하는 눈이 없으니 결국 엔지니어가 수습해야 했다. AI가 코딩의 진입 장벽을 낮춰줬지만, 코드의 품질을 판단하는 능력까지 준 건 아니었다.

이건 나한테도 적용되는 이야기다. 내가 잘 아는 백엔드 아키텍처에서는 AI가 정말 강력한 동료가 되지만, 내가 약한 프론트엔드 영역에서는 AI의 결과물을 제대로 평가하지 못하는 나 자신을 발견한다. AI가 만들어준 React 컴포넌트가 "동작"은 하지만, 그게 좋은 패턴인지 나쁜 패턴인지 판단하기 어려울 때가 있다.

드라큘라 이펙트: AI가 빨아먹는 것

거울의 한계는 지식의 사각지대만이 아니다. Steve Yegge가 말한 드라큘라 이펙트 도 이 맥락에서 이해할 수 있다. AI와 코딩하면 엄청나게 많은 것을 해낼 수 있지만, 그만큼 정신적 에너지를 빨아먹힌다. Simon Willison도 같은 말을 했다 — "LLM이 주는 생산성 향상은 지치게 만듭니다. 2~3개 프로젝트를 동시에 진행하면 한두 시간만 일해도 하루치 정신 에너지가 거의 다 소진됩니다." Steve는 더 직접적으로, 바이브 코딩을 전속력으로 하는 사람에게서 생산적인 시간은 하루 3시간이 한계 라고 말했다. 그래도 AI 없을 때보다 100배 생산적이라고.

나도 비슷한 경험을 한다. AI와 집중적으로 코딩하면 2~3시간 만에 예전 같으면 며칠 걸렸을 작업을 끝낼 수 있다. 근데 그 이후에는 진짜 머리가 안 돌아간다. 인지 부하가 평소와는 다른 종류로, 더 강하게 온다. 코드를 직접 짤 때는 타이핑하면서 생각하는 시간이 자연스러운 휴식이 됐는데, AI와 일할 때는 끊임없이 판단하고, 검증하고, 방향을 잡아줘야 한다. 생산하는 건 AI가 하지만, 사고하는 건 온전히 내 몫 이다.

거울은 서 있는 사람의 모습만 비춘다. 거울 앞에 아무도 서 있지 않으면, 아무것도 비추지 못한다.

그래서 어떻게 쓸 것인가

그렇다면 이 거울을 제대로 활용하려면 어떻게 해야 하는가.

Jeremy Utley가 말하는 핵심 원칙은 간단하다. "AI에게 정답을 요구하지 말고 대화하라." 더 나아가, AI에게 질문하지 말고 AI가 나에게 질문하게 하라.

그가 추천하는 프롬프트가 있다.

"당신은 AI 전문가입니다. 제 워크플로우와 책임 범위, KPI, 목표에 대해 충분한 맥락을 파악할 때까지 한 번에 하나씩 질문해 주세요."

이게 왜 효과적이냐면, 대부분의 사람이 AI를 구글 검색창처럼 쓰기 때문이다. 키워드를 입력하고 답을 기대한다. 하지만 LLM은 검색 엔진이 아니다. 대화 상대다. 내가 맥락을 풍부하게 제공할수록, AI의 응답도 풍부해진다.

Jeremy가 특히 강조하는 건 음성 입력 이다. 구글 검색창에 익숙한 우리 뇌는 입력창을 보면 자동으로 "키워드 모드"로 전환된다. 타이핑하는 순간 "뭘 먼저 써야 하지?"라는 부담이 생기고, 생각을 정리해야 한다는 압박이 오히려 가능성을 제한한다. 음성으로 말할 때는 그냥 횡설수설해도 된다. 똑똑해야 한다는 부담을 내려놓는 것 — 거기서 진짜 대화가 시작된다.

나도 이걸 시도해봤는데, 차이가 크다. 타이핑할 때는 "어떻게 질문해야 좋은 답이 나올까"를 먼저 고민하게 되는데, 음성으로 할 때는 "나 지금 이런 문제가 있는데, 이런 맥락이고, 이런 걸 해보고 싶은데"라고 자연스럽게 흘러나온다. 키워드 모드에서 대화 모드로 전환되는 거다.

코딩에서도 컨텍스트 엔지니어링은 핵심이다. 결국 "AI가 내 요청을 제대로 수행하려면, 어떤 정보를 전부 제공해야 하는가"를 설계하는 것이다. Jeremy가 제안하는 간단한 테스트가 있다. 프롬프트와 문서를 적어서 복도 건너편 동료에게 줘봐라. 그 동료가 못 하는 일이라면, AI도 못 한다고 해서 놀랄 일이 아니다. AI는 마음을 읽을 수 없다. 대부분의 사람이 깨닫는 건 "나는 AI가 내 마음을 읽어주길 기대하고 있었구나"라는 사실이다.

나는 이걸 프로젝트에 적용하면서 체감했다. AGENTS.md에 프로젝트의 아키텍처 결정 이유를 명시하고, 코딩 컨벤션을 구체적으로 적고, 도메인 용어 사전을 만들어두면 AI가 놀라울 정도로 일관된 코드를 만들어낸다. "왜 이 프로젝트에서 이벤트 소싱을 쓰는지", "왜 이 레이어에서는 직접 DB 접근을 하지 않는지" 같은 결정의 맥락을 AI에게 제공하면, AI는 그 맥락 안에서 코드를 생성한다. 맥락이 없으면 AI는 인터넷 평균을 모방한다. 맥락이 풍부하면 AI는 내 팀의 일원처럼 작동한다.

각설하고 여기서 Kent Beck의 이야기를 하나 더 꺼내고 싶다. 그는 "피처만큼이나 퓨처스에 투자하라" 고 말한다. 퓨처스(futures)란 다음에 구현할 수 있는 모든 것의 집합이다. 지금 당장 만들고 있는 기능이 피처라면, 퓨처스는 그 기능을 만든 뒤에 시스템이 갖게 되는 확장 가능성이다. 코드 구조가 다음 기능을 쉽게 붙일 수 있게 되어 있는지, 아키텍처가 새로운 요구사항을 수용할 여지가 있는지 — 이런 것들이 퓨처스다.

컨텍스트 엔지니어링을 할 때도 마찬가지라고 본다. AGENTS.md에 지금 구현하려는 기능의 맥락만 적어놓으면, AI는 그 기능을 만들어준다. 하지만 거기서 끝이다. 시스템이 다음에 어디로 갈 수 있는지, 어떤 방향으로 확장될 수 있는지 — 그 시야까지 설계에 담아야 퓨처스가 살아남는다. 내가 아는 것, 내가 지금 구현하려는 것에만 빠져 있으면 기능은 완성되지만 확장성은 죽는다. 컨텍스트를 풍부하게 제공한다는 건, 지금의 맥락뿐 아니라 시스템의 미래 가능성까지 시야에 넣는다는 뜻이다.

그리고 결국 이 모든 것이 수렴하는 지점은 "도구가 아니라 팀원으로" 보는 관점 전환이다. Jeremy의 연구에서 AI 활용의 저성과자와 고성과자를 비교했을 때, 가장 큰 차이는 기술적 스킬이 아니라 AI에 대한 태도 였다. 저성과자는 AI를 도구로 대했고, 고성과자는 팀원으로 대했다. 도구로 대하면 평범한 결과에서 멈추지만, 팀원으로 대하면 피드백을 주고, 코칭하고, 더 나은 결과를 끌어낸다.

주니어 직원에게 일을 맡길 때 "질문 있으면 언제든 물어봐"라고 하지 않나. AI에게도 같은 권한을 줘야 한다. "시작하기 전에, 이걸 잘하기 위해 필요한 정보가 있으면 나한테 물어봐"라고 요청하면, AI는 영업 이메일을 바로 쓰는 대신 "이 이메일을 쓰려면 최근 영업 수치가 필요합니다. Q2에 이 SKU를 얼마나 판매했는지 알려주실 수 있나요?"라고 물어온다. 이게 도구와 팀원의 차이다.

코딩에서도 마찬가지다. "이 기능 만들어줘"가 아니라 "이 기능을 만들려는데, 현재 아키텍처 맥락을 설명할 테니 먼저 접근 방식을 제안해줘. 내가 놓치고 있는 엣지 케이스가 있으면 짚어줘"라고 하면, 결과가 확연히 달라진다.

변하지 않는 것들

여기까지 읽으면 "그래서 코드를 읽지 않아도 되는 거야?"라고 물을 수 있다. 답은 복잡하다.

Ben Shoemaker도 인정했다. 안전 필수 시스템, 보안에 민감한 서비스, 중대한 아키텍처 결정에서는 코드를 읽어야 한다고. 그가 든 비유가 좋았다 — 항공 분야의 "마젠타의 아이들" 이야기. 자동화된 비행 경로(마젠타 라인)에 의존하게 된 조종사들이, 언제 수동으로 전환해야 하는지 판단력을 잃어버린 사례다. 교훈은 "오토파일럿을 쓰지 마라"가 아니었다. 오토파일럿을 쓰되, 개입할 능력이 필요하다 는 것이었다.

코드를 읽는 것도 마찬가지라고 본다. 매 줄을 읽을 필요는 줄어들고 있다. 하지만 읽을 줄 아는 능력 은 오히려 더 중요해졌다. 뭔가 잘못됐을 때 — 모든 테스트가 통과하는데 제품이 이상하게 동작할 때, 여러 에이전트가 해결하지 못한 실패를 디버깅할 때 — 결국 코드를 직접 읽고 이해해야 하는 순간이 온다.

읽을 줄 아는데 안 읽는 것과, 못 읽는 것은 완전히 다른 이야기다.

Anthropic 연구에서 가장 높은 점수를 받은 "개념적 탐구" 패턴을 다시 생각해 보자. 이 그룹은 AI에게 코드를 시키지 않았다. 개념만 물어보고, 코드는 직접 짰다. 오류도 많이 만났지만 스스로 해결했다. 왜 이 패턴이 가장 효과적이었을까? 코드를 읽고 쓸 줄 알았기 때문이다. 그 능력이 있었기에 AI에게 개념을 묻고 자신의 이해를 확인하는 전략을 선택할 수 있었다.

얼마 전 프로덕션에서 묘한 버그를 만났다. AI로 수십 번 피드백하며 세운 계획을 실행에 옮긴 코드였는데, 모든 테스트가 통과하고, AI에게 디버깅을 시켜도 "문제없어 보인다"는 답만 돌아왔다. 결국 코드를 직접 펼쳐놓고 한 줄씩 따라가면서 발견한 건, 예외처리 로직에서 폴백값이 의도치 않은 디폴트 값으로 대체되는 버그였다. 예외가 발생하면 안전한 기본값으로 넘어가야 하는데, 그 기본값 자체가 잘못 설정되어 있어서 특정 조건에서만 엉뚱한 결과가 나오고 있었다. AI는 이 코드를 수십 번 봤지만 발견하지 못했다. 그 순간 깨달았다. AI가 만든 코드를 보고 "이거 정말 맞아?"라고 의심하는 능력, 시스템의 전체 흐름을 머릿속에서 그릴 수 있는 능력, AI가 "다 됐어요"라고 해놓고 실제로는 안 돌아가는 경우 그 차이를 알아차리는 감각 — 이런 것들이 결국 하나로 연결되어 있다는 걸. 비판적 사고, 논리적 사고, 디테일을 챙기는 능력. 따로 떼어서 기를 수 있는 게 아니라, 코드를 깊이 다루는 경험 속에서 함께 자라는 것들이다.

솔직히 말하면 AI가 빠르게 발전하면서, 이 기본기의 가치가 오히려 더 높아지고 있다고 느낀다. 예전에는 코드를 읽을 줄 아는 게 "당연한 것"이었다. 지금은 AI가 코드를 대신 써주니까, 코드를 제대로 읽고 판단할 수 있는 능력이 차별화 요소 가 됐다. 모델 간 반감기가 4개월에서 2개월로 줄고, 매번 새 모델이 나올 때마다 "이게 한계야"라고 하는 사람들이 있지만 커브는 멈추지 않고 있다. 도구가 이렇게 빠르게 바뀌는 세상에서 살아남는 건, 특정 도구에 능숙한 사람이 아니라 어떤 도구든 빠르게 평가하고 활용할 수 있는 사람이다. 비판적 사고, 시스템을 전체적으로 바라보는 눈, 품질에 대한 감각 — 이런 것들은 AI 모델이 GPT-10이 되든 Claude 20이 되든 변하지 않는다.

Codex 팀도 비핵심 코드는 AI 리뷰만으로 머지하지만, 핵심 에이전트와 오픈소스 컴포넌트 같은 핵심 코드에 대해서는 세심한 인간 코드 리뷰를 고집한다. 코드를 작성하지 않는 시대라고 해서, 코드를 읽는 능력이 필요 없어진 게 아니다. 오히려 읽어야 할 순간에 제대로 읽을 수 있는 능력이 더 귀해진 거다.

나가며

다시 처음의 질문으로 돌아가 보자. AI가 코드를 대신 쓰는 시대에, 엔지니어는 무엇을 읽어야 하는가.

코드를 읽는 시간은 줄어들 것이다. 대신 스펙을 읽고, 아키텍처를 읽고, 테스트 결과를 읽고, 도메인 맥락을 읽어야 한다. 코드는 점점 더 "구현 세부사항"이 되어가고 있고, 우리의 주의는 더 높은 추상화 레이어로 이동하고 있다.

하지만 이 변화의 한가운데서, 변하지 않는 본질이 있다. 결국 AI는 그 사람의 기질과 성향, 능력을 극대화한다. 게으르면 더 게으르게, 비판적이면 더 비판적으로, 창의적이면 더 창의적으로. 코드를 깊이 이해하는 사람은 AI를 써서 더 깊은 수준의 시스템을 만들고, 코드를 모르는 사람은 AI를 써서 돌아가기는 하지만 깨지기 쉬운 것을 만든다.

코드를 읽지 않는 시대라고 해서, 읽는 능력까지 내려놓을 수는 없다. AI가 읽어주는 세상에서도, 무엇을 읽어야 하는지 아는 것 은 여전히 우리의 몫이다. 거울에 비출 게 있는 사람이 되는 것 — 결국 그게 이 시대 엔지니어의 본질이 아닐까. AI는 그 모습을 충실하게 증폭해 줄 것이다 — 좋든 나쁘든.

References

(픽션) 허공을 미는 사람들 - 에피소드 3, 균열 - 1

Tony Cho (https://flowkater.io) — Wed, 18 Feb 2026 04:00:00 GMT

이 작품에 등장하는 모든 인물, 이름, 집단, 사건은 허구이며 실존하는 것들을 기반으로 하지 않았습니다.

Author: flowkater

에피소드 3: 균열 - 1

[토요일, 오후 7:12] 김 대리 - 강남, 어느 술집에서

"여~! 김대리!!"

나는 나를 호쾌하게 부르는 그를 쳐다보고 멋쩍게 웃었다.

"어, 왔어?"

대충 걸쳐 입고 나온 나와 달리, 그는 꽤 번듯한 스타일의 옷을 입고 있었다. 꽤 마른 체형의 나와 달리 적당한 풍채에, 표정에서 자신감이 묻어났다. 학교 동기이자 이전 회사 동기였지만, 나도 모르게 조금 움추려든다.

입사를 위해 코딩 테스트를 준비하던 시절, 도서관에서 처음 본 그 친구가 대뜸 다가와 "야, 코딩 좀 가르쳐줘. 밥 살게."라고 했었다. 그렇게 시작된 인연이었다. 나와 함께 다니던 이전 대기업을 일찌감치 퇴사하고 한 작은 스타트업 개발 팀장으로 이직을 한 그는, 지금은 직함도 이사였다. 최 이사.

딱히 변화를 추구하거나 변화하는 것을 좋아하지도 않는 내 성격상 지금 이 회사에 오게 된, 이직을 하게 된 용기를 가지게 된 것도 그의 영향이 컸다.

최 이사는 나를 보고 반갑다는 듯이 웃어보이더니, 묻지도 않고 맥주를 비롯해서 이것저것 안주를 시켰다. 항상 그래왔어서 나도 가만히 그가 주문하는 모습을 지켜보고만 있었다.

최 이사가 주문하는 동안 안을 둘러봤다. 강남역 뒷골목 2층, 좁은 테이블들이 빼곡하게 놓여 있고 천장에 매달린 조명이 낮게 드리워져 있었다. 토요일 저녁치고는 아직 사람이 많지 않았고, 우리가 앉은 구석 자리에서 입구가 보였다.

"잘지냈냐?"

최 이사와는 아마 지금 회사 이직하고는 처음 본 것 같다. 이직 직후에 내가 연락했을 때 최 이사는 너무 바빠서 힘들다고 그랬고 그 뒤에는 나에게 시간이 너무 없었다. 프로젝트가 끝나고 나서야 가까스로 그에게 연락을 했다. 그마저도 프로젝트가 끝나고 두 주가 지나서였다.

"뭐.. 일 때매 한동안 좀 정신없었지."

혹여 내 목소리에서 좌절감이나 실망감이 드러날까 자제하면서 대답을 했다. 괜찮은 척을 하는 게 익숙해져 있었다. 이직하고 첫 회의 때부터 그랬다. 아무도 내 의견을 묻지 않았고, 나도 말하지 않았다. 그게 석 달이 되었다.

"와, 너네는 그래도 대기업 계열사인데.. 워라밸 보장해야 되는 거 아니냐? 대박이고만.. 고생했다 친구야"

아직 맥주가 도착하지도 않았는데 최 이사는 물잔으로 건배를 했다. 나는 따라서 물잔을 쥐고 한 모금 마셨는데, 최 이사는 물을 마시지 않고 잔을 쥔 채 말을 이어갔다.

"근데 나도 요즈음 새벽에 자주 퇴근하는데 죽겄다 진짜. 뭐 여기 일이라는 게 다 그렇지 뭐. AI니 뭐니 요즈음 난리인데, 왤케 우리는 일이 줄지를 않냐.."

최 이사는 물컵을 다시 내려놓고 나를 똑바로 쳐다보았다.

"근데 진짜 해보니까 개발이 문제가 아니더라.. 팀원들이 진짜 드릅게 말을 안 들어~ 그리고 대표는 왜케 고집이 세냐 죽겄다 죽겄어"

어깨에서 힘이 조금 빠졌다. 박 팀장님과 부서장님이 생각났고, 하 과장을 비롯한 팀원들이 떠올랐다. 다 비슷한 거구나. 스타트업이든 대기업이든. 그 생각에 나도 모르게 입이 열렸다.

"다 비슷하구나. 우리도 팀장님이 위에서 엄청 깨지고 팀원들도 뭐라고 하고 그러더라고. 뭐 물론 나도 팀원이지만.. 어떤 마음인지 알겠어"

최 이사는 갑자기 감격한 듯한 눈으로 나를 쳐다보며 대답했다.

"역시 우리 김대리! 진짜 니가 우리 과, 회사 포함해서 슈퍼 울트라 개발자 그 자체였는데 말이야. 제프 딘 저리가라였잖아 큭큭."

최 이사가 물컵을 내려놓으며 몸을 앞으로 기울였다.

"타 팀에서 인프라 시스템 개떡같이 관리해 오던 걸 인수인계 받아서 일주일 만에 마이그레이션 해서 '저 다 했습니다.' 하던 그 김대리 아니냐. 넌 진짜 유니콘 개발자다."

제프 딘?

"컴파일러가 제프 딘에게 경고하지 않는다. 그가 컴파일러에게 경고한다." 개발자라면 누구나 아는 밈의 그 제프 딘. 그런 사람과 나를 비교한다고? 온갖 곳에 코드를 복사 붙여넣기 하다가 버그 수정에 밤을 새는 나를?

그 이후로는 아무 말이 안 들렸다. 최 이사는 계속 말을 이었다.

"우리 팀에 너 같은 개발자 한 명만 있었어도 내가 그 고생을 안 했을 건데.. 요즘 것들 왜케 눈치도 없고 날 힘들게 하는지.. 아 우리 대표는 나보다 10살 많아서 요즘 것들도 아니지 크크 .. 그래도.."

맥주가 도착하자 최 이사가 잔을 건넸는데 내가 받는 게 느렸던 것 같다. 최 이사는 신경 쓰지 않고 자기 잔에 맥주를 따랐다.

"뭔 개소리야. 요새 일 바빠서 그냥 코드 복사 붙여넣고, 커밋도 대충하고 진짜 내가 개발자인지 노가다꾼인지 솔직히 잘 모르겠어"

아차. 그가 아직 말을 하는 중이었다. 내 생각이 어느새 말로 나와버렸다.

그 말을 듣던 최 이사는 딱히 아랑곳하지 않고 말을 이어갔다.

"야야, 다른 회사 다 가봐라. 안 그런 데가 있냐. 기술블로그에 온갖 번지르르한 거 써놔도 실상 들여다보면 다들 개판이야. 내가 아무리 가이드라인 잡고 아키텍처 잡아도 잠깐 바빠서 못 들여다보면 완전 개판 나 있는 게 프로덕션 코드 아니겠냐."

최 이사는 잠깐 말을 멈추고 어느새 나온 맥주잔을 들었는데, 거품이 잔 위로 넘칠 듯 말 듯했다.

"그래도 큰 프로젝트 하나 끝났다며? 고생했다."

나는 고개를 끄덕였다. 석 달. 주말 출근. 매일 밤 10시, 늦으면 새벽 3시. 끝났다는 감각이 아직도 없었다. 그냥 더 이상 안 해도 된다는 것뿐이었다.

"우리는 B2C에 B2B까지 확장하는 시기라서 '끝'이라는 게 존재하지를 않아."

최 이사가 맥주를 한 모금 마셨다. 거품이 입술에 묻었는데 닦지 않았다.

"그래도 PO랑 같이 결정해서 밤새고 만든 게 딱 릴리즈되고 고객들 피드백 들어오는데, 와 진짜 도파민이 질리지도 않더라고. 내가 대시보드를 하나 만들어 놨거든? 지표 딱 찍히고 매출 딱딱 찍히니까 기가 막히더라. 마케팅 팀이랑 또 같이 연계해서 이번에 무슨 프로젝트를 했냐면.."

나는 맥주잔 위의 거품을 보고 있었다. 거품이 천천히 가라앉고 있었다.

고객 피드백. 지표. 매출. 도파민.

지난 석 달 동안 매달린 건 누가 쓰는지도 모르는 프로그램이었다. 고객 접점은 대행업체가 가지고 있었고, 그래서 항상 부서장님이 결정하고 박 팀장님이 전달했다. 릴리즈 다음 날이었다. 팀장님한테 "고객 반응이 어때요?"라고 물었더니, 팀장님이 모니터에서 시선을 떼지 않은 채 잠깐 뜸을 들이다가 "대행업체가... 좋다고 했대."라고 했다. 그리고 다시 모니터를 봤다. 석 달이 한 줄이 되었다.

최 이사의 말이 계속 이어지고 있었다. 나는 맥주잔을 들어 마셨다. 입안이 씁쓸했는데 맥주 맛 때문인지는 모르겠다.

한참을 떠들던 최 이사는 고객이 얼마나 중요한지, 기술은 수단이지 목적이 될 수 없다는 얘기를 했다. 코딩 테스트도 못하던 자기가 눈칫밥으로 돈 벌어 먹고 사는 게 다 이것 때문이라고 했다. 과한 겸손이다. 나에게 과외를 받던 당시와 달리 그는 입사 및 사내 엔지니어 레벨 테스트에서 항상 나와 같이 코딩 테스트 상위를 기록했다. 실력이 없는 사람이 아니다. 그런데 그는 코딩이 아니라 고객 이야기를 한다.

관자놀이가 욱신거렸다.

어느새 술집이 붐비기 시작했다. 옆 테이블에 사람들이 앉고, 주문 소리가 오갔다. 테이블 위 안주 접시에서는 김이 더 이상 올라오지 않았다. 내 앞에 놓인 안주는 거의 손을 대지 않았고, 맥주잔에 맺힌 물방울이 천천히 흘러내려 테이블에 작은 웅덩이를 만들고 있었다.

겉으로 보면 최 이사도 다를 게 없었다. 스타트업에 들어간 뒤로 개인 시간이 사라졌고, 대학 때부터 만나던 여자친구랑도 결국 헤어졌다. 나도 아는 사이였다. 그 소식을 들었을 때 놀라지 않았다. 그게 더 이상했다. 건장하던 체격에 어느새 살이 붙어 있었고, 간이 안 좋아서 한동안 병원을 다녔다는 얘기도 들었다.

하지만 날이 갈수록 에너지가 빠져나가는 나와 달리 그는 활력이 넘쳤다. 눈은 그 어느 때보다 빛이 났고 그의 목소리에는 힘이 넘쳤다.

같은 야근이었다. 같은 밤샘이었다. 같은 체력 소모였다. 그런데 왜 나만 비는 건지. 그 차이가 뭔지 머리로는 알겠는데, 알겠다는 게 더 나빴다.

".. 그렇지 않냐 친구야?"

"어?"

화들짝 놀라서 최 이사를 바라보았다.

"이 맛에 개발자로 산다고. 이렇게 개고생해도.. 내 힘으로 만들어낸 무언가가 나랑 평생을 만나지도 못할 그런 문화의 저 먼 나라의 누군가가 우리의 제품을 써주고 감동을 받아서 이메일을 보내고 하는 거. 이게 매직이다 이거야. 소프트웨어의 매직!"

나는 아무런 대답을 하지 않았다.

주변 테이블이 거의 다 차 있었다. 웃음소리, 잔 부딪히는 소리, 누군가가 부르는 건배사. 시끄러워지고 있었는데 최 이사의 목소리만 유독 선명하게 들렸다.

"기숙사 옆 방 친구랑 얘기하려고 몇 달을 밤을 새서 플랫폼을 만드는 찐따들이지만, 그런 찐따들이 여전히 세상을 바꾸는 그 맛이 제대로지. 내가 너처럼 개발에 특출난 사람이었으면 개발 자체에서 더 많은 도파민을 느낄 것 같은데 내 실력이 미천해서 나는 그런 것보다는 고객 피드백이 내 도파민이다 이거야. 무슨 말인지 알지?"

나는 말없이 고개를 끄덕였다.

모른다. 예전에는 알았던 것 같은데, 지금은 모르겠다.

내 힘으로 만들어낸 무언가. 석 달 동안 만든 건 뭐였나. 남의 코드를 복사해서 붙여 넣고, 변수명을 바꾸고, 빌드 돌려서 에러 나면 또 고치고. 그걸 누가 쓰는지도 몰랐다. 릴리즈 당일에 고객 반응을 물어봤더니 팀장님도 모른다고 했다. 대행업체가 "시장 반응이 좋을 것 같다"고 했다는 한 줄. 그것도 내가 직접 들은 게 아니라 팀장님을 통해서, 팀장님도 부서장님을 통해서 들은.

최 이사가 말하는 그 도파민이라는 걸, 나는 전 회사에서 느꼈었다. 새벽에 배포하고 슬랙에 고객 피드백이 올라올 때. 내 PR에 동료가 "이거 깔끔하다"라고 코멘트를 달았을 때. 오픈소스에 올린 코드가 다른 나라 개발자의 프로젝트에 쓰이고 있다는 걸 발견했을 때. 그런 게 있었다.

지금은 없다. 그게 언제 사라졌는지도 모르겠다. 이 회사에 와서 처음부터 없었는지, 아니면 석 달 동안 조금씩 빠져나간 건지. 아니, 어쩌면 전 회사를 나오면서 두고 온 건지도 모른다.

최 이사가 두 번째 맥주를 따르면서 무슨 말을 했는데 안 들렸다. 술집의 소음이 점점 커지고 있었다. 내가 듣고 싶지 않아서인지, 진짜 안 들리는 건지.

사실 뭔가 채워질 거라는 기대로 최 이사를 만난 것 같다. 그랬나? 그랬다. 최 이사는 좋은 친구다. 용기가 부족했던 나에게 항상 먼저 손을 내밀었던 친구. 여자친구랑 헤어지고 다음 날 새벽에 우리 집 앞에 와서 한 시간을 서 있던 친구. 다른 사람들은 그를 대범하다고 하는데, 나는 안다. 그 대범함 뒤에 꽤 감성적인 놈이라는 걸.

그런 친구인데. 오늘 만나면 좀 나을 줄 알았다.

그런데 나아지지 않았다. 그가 하는 모든 말들이, 함께하면 즐거웠던 그 모든 말들이 오늘은 가슴 위에 쌓여만 갔다. 최 이사가 신나면 신날수록 내 안의 빈 곳이 더 선명해졌다.

속이 올라왔다.

맥주잔을 내려놓았다. 반도 안 마신 잔이었는데 더는 손이 가지 않았다.

"..나 먼저 가봐야 할 것 같다."

최 이사가 말을 멈추고 나를 봤다. 잠깐 조용해졌다.

"왜? 몸이 안 좋냐?"

"어, 좀.. 피곤해서. 미안."

거짓말은 아니었다. 피곤한 건 맞다. 석 달째 피곤하다.

최 이사가 고개를 끄덕였다. 평소 같으면 "야 뭐 벌써 가냐 한 잔만 더 해"라고 붙잡았을 텐데, 내 얼굴을 보더니 그러지 않았다. 감성적인 친구니까. 내 표정에서 뭔가를 읽었을 것이다.

"그래, 가서 푹 쉬어. 다음에 또 보자."

일어서며 지갑을 꺼냈는데 최 이사가 손을 저었다.

"내가 낸다. 가라 가."

계단을 내려오는데 다리가 무거웠다. 2층에서 1층, 겨우 한 층인데 유난히 길게 느껴졌다.

밖으로 나오니 바람이 불었다. 술집 안의 따뜻한 공기가 등 뒤에서 잘렸고, 바깥 공기가 쌀쌀하게 볼을 스쳤다. 강남역 방향으로 사람들이 지나갔다. 토요일 저녁. 다들 어딘가로 가고 있었다.

핸드폰을 꺼내 시간을 보니 8시 43분이었다. 한 시간 반 정도 있었던 건가.

걸었다. 지하철역 방향이 아니었다. 왜 이쪽으로 가고 있는지 모르겠는데 발이 멈추지 않았다.

토요일 밤 강남. 사람들이 많았다. 커플이 손을 잡고 지나가고, 단체로 웃으며 걸어가는 무리가 있었다. 다들 어딘가로 향하고 있었다. 나만 방향이 없었다.

횡단보도 앞에서 신호를 기다리는데, 신호가 바뀌어도 건너지 않았다. 옆에 서 있던 사람들이 빠져나가고 새로운 사람들이 차올랐다. 한 번 더 바뀌었다. 그제야 건넜다.

아까 최 이사가 한 말이 맴돌았다. 내 힘으로 만들어낸 무언가. 소프트웨어의 매직. 그 말 자체가 틀린 게 아니다. 맞는 말이다. 나도 알고 있다. 한때는 느꼈으니까.

이직했을 때 기대했던 게 있었다. 큰 회사니까 체계가 있을 거라고, 좋은 개발 문화가 있을 거라고, 내 기술을 제대로 쓸 수 있을 거라고. 최 이사가 이직하라고 등을 떠밀었을 때 그래서 용기를 냈다. 열 달이 지났다. 체계는 있었다. 보고 체계. 승인 체계. 결재 체계. 내가 기대했던 체계는 아니었다. 코드 리뷰는 없고, 테스트는 없고, 고객은 보이지 않았다.

최 이사는 밤을 새면서 도파민을 느꼈다. 나는 밤을 새면서 에너지가 빠져나갔다. 같은 야근인데 방향이 달랐다. 그의 끝엔 고객이 있었고, 나의 끝엔 부서장님의 지시가 있었다.

당분간은 최 이사를 만나기 힘들 것 같다.

싫어서가 아니다. 좋은 친구다. 여전히. 그런데 지금 상태로는 그의 열정이 닿는 곳마다 무거워졌다.

가로수 아래 벤치가 보여서 앉았다. 앉으니 다리에서 힘이 빠졌다. 앞으로 사람들이 지나갔다. 웃는 소리, 하이힐 소리, 전화 통화하는 소리. 앉아 있으니 다들 빠르게 움직이는 것처럼 보였다.

뭔가가 바뀌어야 한다. 이대로는 안 된다. 술집에서는 흐릿하던 것이 여기 앉으니 선명해졌다. 혼자니까. 갈 곳이 없으니까.

주말이 끝나면 월요일이 온다. 수정 요청 대기. 성과급은 언제인지 모른다. 또 같은 코드를 복사 붙여넣기 한다. 그리고 또 석 달이 지나겠지. 그때도 나는 누가 쓰는지 모르는 코드를 붙여 넣고 있을까.

그 생각을 하니 숨이 막혔다.

핸드폰 화면이 밝아졌다. 최 이사에게서 카톡이 와 있었다.

"야 오늘 고마웠다. 몸 챙겨! 내가 보기엔 좀 쉬어야 될 것 같다 ㅋㅋ 조만간 또 만나자 친구야"

읽고 핸드폰을 무릎 위에 엎어 놓았다.

조만간. 그때 만나면 나는 어떤 사람이 되어 있을까. 여전히 같은 자리에서 같은 일을 하고 있을까. 아니면.

벤치에서 일어나지 못하고 한참을 앉아 있었다. 사람들이 줄어들고 있었다.

[월요일] 김 대리 - 사무실에서

수정 요청 목록이 왔다.

부서장님이 말했던 대행업체 수정 건이었다. 팀장님이 슬랙에 파일을 공유했다. 엑셀 파일. 열어보니 항목이 스물세 개였다. UI 수정, 텍스트 변경, 필터 기능 추가, 정렬 순서 변경. 한 줄짜리도 있고 하루 이상 걸릴 것도 있었다.

팀장님이 말했다. "일주일이면 될 거야."

부서장님이 했던 말이 그대로 내려온 거라는 걸 알고 있었다. 일주일이면 된다. 크게 어렵지 않다. 석 달 동안 매번 들었던 말이다.

일주일이 지났다. 목록의 절반을 끝냈다. 나머지 절반은 생각보다 복잡했다. 기존 코드를 건드려야 하는 것들이 있었고, 건드리면 다른 데서 깨졌다. 테스트가 없으니까 하나를 고치면 다른 하나가 어디서 터지는지 찾아야 했다. 당연히 일주일 안에 끝나지 않았다.

두 주째 되던 날, 새 목록이 왔다. 대행업체에서 고객사 데모를 했는데 추가 요청이 생겼다고 했다. 열네 개 항목. 이전 목록이 아직 안 끝났는데 새 목록이 쌓였다. 팀장님은 별말 없이 슬랙에 파일을 올렸다. "확인 부탁합니다." 한 줄.

두 주가 한 달이 됐다. 한 달이 되어도 끝나지 않았다. 끝날 때쯤 또 새 목록이 왔다. 이번에는 여덟 개. 패턴이 보이기 시작했다. 수정 건이 줄어드는 게 아니라, 돌아가며 채워지고 있었다. 하나를 빼면 하나가 들어왔다. 진행률은 항상 60에서 70퍼센트 사이를 맴돌았다. 스프레드시트의 초록색 칸이 늘어나는 만큼 빨간색 칸도 늘어났다. 끝이라는 게 존재하지 않았다.

월요일이 오면 슬랙을 열었다. 새 메시지가 있었다. 대행업체 담당자가 올린 건. 팀장님이 포워딩한 건. 열어보고, 확인하고, 코드를 열고, 고치고, PR을 올렸다. 화요일도 같았다. 수요일도. 하루가 지나면 다음 하루가 왔고, 그 하루도 같은 하루였다. 달력을 보지 않으면 무슨 요일인지 구분이 안 됐다. 회의도 없고, 일정 변화도 없고, 매일 같은 엑셀 파일을 열어서 같은 항목을 확인했다.

성과급 얘기를 아무도 안 꺼냈다.

처음에는 의식했다. 팀장님한테 성과급 관련해서 업데이트 있냐고 물어볼까, 하다가 입을 닫았다. 하 과장도 안 물었다. 이 과장도. 정 대리도. 프로젝트 끝나고 얼마간은 누가 먼저 말을 꺼내나 신경을 쓰고 있었는데, 아무도 꺼내지 않았다. 의식적으로 피하고 있다는 게 느껴졌다.

한 달쯤 지나니 그마저도 달라졌다. 피하는 게 아니라 진짜 잊은 것 같았다. 나도 그랬다. 성과급이라는 단어가 머릿속에서 떠오르지 않았다. 수정 요청 확인하고, 코드 고치고, 빌드 돌리고, 슬랙에 완료 보고하고. 그게 하루였다. 그 하루가 반복됐다. 성과급이 들어갈 자리가 없었다. 그 단어가 존재했다는 것 자체가 먼 일처럼 느껴졌다. 부서장님이 "성과가 있어야 성과급"이라고 했을 때의 그 공기, 에어컨 소리, 팀장님의 굳은 얼굴. 그게 두 달 전이라는 게 믿기지 않았다. 어제 같기도 하고, 일 년 전 같기도 했다.

첫 번째 토요일이었다.

오후에 카페에 갔다. 집 근처 스타벅스. 아메리카노를 시키고 자리에 앉아서 노트북을 열었다. 개인 노트북이었다. 먼지를 닦고 전원을 켰다. 부팅하는 데 시간이 좀 걸렸다. 그 사이에 뭘 만들지 생각했다. 사이드 프로젝트. 뭐든 좋으니까 내 코드를 짜고 싶었다. 남의 코드를 복사 붙여넣기 하는 게 아니라, 처음부터 내가 설계하고 내가 짜는.

바탕화면이 떴다. VS Code를 열려고 독에서 아이콘을 찾았다. 슬랙 알림이 울렸다. 회사 핸드폰이었다.

팀장님이었다. "김 대리, 지난주 수정 건 중에 필터 관련 이슈 하나 확인 좀 해줄 수 있어? 대행업체에서 급하다고 연락 왔는데."

토요일이었다. 오후 두 시였다. 카페에 앉아서 뭔가를 시작하려던 참이었다.

슬랙을 확인하고 관련 코드를 찾아봤다. 필터 로직에 예외 처리가 빠져 있었다. 수정 자체는 어렵지 않았다. 삼십 분이면 됐다. 하지만 로컬에서 테스트하려면 개발 환경을 세팅해야 했고, 개인 노트북에는 환경이 없었다. VPN을 켜고 회사 레포를 클론하고 의존성을 설치하는 데 한 시간이 걸렸다. 수정하고 PR을 올리고 슬랙에 완료를 보냈다. 답장은 없었다.

VS Code 창이 두 개 열려 있었다. 하나는 회사 코드. 하나는 빈 창. 사이드 프로젝트를 위해 열어둔 건데, 커서만 깜빡이고 있었다. 한 줄도 안 쳤다. 얼음이 다 녹아 물처럼 연해진 아메리카노를 마시고 노트북을 닫았다.

다음 토요일에도 카페에 갔다. 같은 자리. 같은 아메리카노. 노트북을 열고 VS Code를 켰다. 이번에는 뭘 만들지 정해놓고 왔다. 간단한 CLI 도구. 마크다운 파일을 파싱해서 정적 사이트를 만들어주는.

슬랙이 울렸다. 팀장님이었다. "김 대리, 이번 주 수정 목록에서 세 번째 항목 있잖아. 그거 로직이 좀 복잡할 것 같은데 월요일 전에 한번 봐줄 수 있어?"

노트북을 닫았다. 이번에는 코드를 한 줄도 열어보지 않고 닫았다. 아메리카노를 다 마시지 않고 카페를 나왔다. 밖은 햇볕이 좋았다. 주말 오후의 거리에 사람들이 걸어다니고 있었다. 나는 노트북 가방을 어깨에 메고 원룸으로 돌아갔다.

개인 노트북을 가방에 넣은 채 원룸으로 가져와서 책상 위에 올려놓았다. 책상 위에 먼지가 얇게 깔려 있었고, 노트북 옆에는 아무것도 없었다. 컵도, 책도, 메모도. 다음에 열어야지. 다음에.

그 다음 주말. 토요일 아침에 눈을 떴다. 카페에 가야지, 하고 생각했다. 이번에는 슬랙 알림을 끄고 가자. 핸드폰을 꺼내서 슬랙 알림 설정을 열었다. 손가락이 토글 위에서 멈췄다. 끄면 월요일에 확인 못 한 건이 쌓여 있을 것이다. 팀장님이 직접 전화할 수도 있다. 전화가 오면 더 곤란하다.

알림을 끄지 않았다. 카페에 가지 않았다. 노트북을 열지 않았다. 토요일 오후에 침대에 누워 천장을 봤다. 누런 얼룩이 구석에 하나 있었다. 입주할 때부터 있던 건지, 나중에 생긴 건지 모르겠다. 커튼 사이로 오후 햇빛이 비스듬히 들어와 바닥 절반만 밝혔다. 나머지 절반은 어두웠다. 방 안은 조용했다. 냉장고 돌아가는 소리만 낮게 깔려 있었다. 아무것도 하지 않는 토요일이었는데 몸이 무거웠다. 슬랙은 울리지 않았다. 울리지 않았는데도 안도감이 들지 않는다. '울릴 수도 있다' 그 가능성에 무겁게 짓눌릴 뿐이었다.

Notion을 열어본 건 어느 날 점심시간이었다. 회사 근처 편의점에서 삼각김밥을 먹으면서 핸드폰으로 Notion 앱을 열었다. 개인 워크스페이스. 사이드 프로젝트 아이디어를 적어두는 페이지가 있었다. 입사하기 전에 만든 건데, 항목이 다섯 개 적혀 있었다.

"실시간 코드 리뷰 도구 — 깃허브 PR 연동, AI 코드 리뷰 자동화" "개발자 커뮤니티 MVP — 기술 블로그 + Q&A 통합" "CLI 기반 정적 사이트 생성기" "오픈소스 모니터링 대시보드" "개인 포트폴리오 사이트 리뉴얼"

내가 쓴 건 맞았다. 글씨체도 내 것이고, 정리하는 방식도 내 것이었다. 그런데 낯설었다. 이걸 쓸 때 무슨 생각이었는지 기억이 나지 않았다. "AI 코드 리뷰 자동화"라는 문장 옆에 불꽃 이모지가 붙어 있었다. 내가 붙인 거다. 신이 나서 붙였을 것이다. 그때의 감각이 떠오르지 않았다.

핸드폰을 끄고 삼각김밥 나머지를 먹었다. 밥알이 입안에서 뭉쳐졌다. 편의점 유리문 너머로 점심시간 사람들이 지나갔다. 넥타이를 맨 사람, 사원증을 목에 건 사람, 이어폰을 꽂고 걷는 사람. 다들 어딘가에서 일하고 있었다. 다들 비슷한 얼굴이었다. 내 얼굴도 저렇겠지.

점심시간에 이직 사이트를 열었다. 원티드. 잡코리아. 화면을 스크롤했다. 시니어 백엔드 개발자. 풀스택 엔지니어. 연봉 협의. 경력 3년 이상. 기술 스택이 나열되어 있었다. 익숙한 것들이었다. 내가 할 수 있는 것들이었다.

지원 버튼을 누르지 않았다. 화면을 닫았다. 다음 날 점심에도 열었다. 같은 사이트, 비슷한 공고. 스크롤하다가 닫았다. 그 다음 날에도. 열었다가, 닫았다. 열었다가, 닫았다.

한 번은 이력서 업데이트 페이지까지 들어갔다. 경력 사항 란에 현 회사를 추가하려고 했다. 주요 업무. 뭐라고 쓰지. "대행업체 기획 기반 소프트웨어 개발." "기존 코드 기반 수정 및 유지보수." 적으면서 손이 멈췄다. 이게 내 경력인가. 석 달 동안 한 일을 한 줄로 쓰니까 아무것도 아닌 것처럼 보였다. 저장하지 않고 닫았다.

포트폴리오도 안 만들었다. 열어보는 것까지가 내가 할 수 있는 전부였다. 뭔가를 만들기 시작하면 지금 상태를 인정해야 할 것 같았다. 준비하고 있다는 건, 여기를 떠나야 한다는 뜻이니까.

카톡 알림이 오지 않는 대화방이 하나 있었다.

최 이사. 마지막 메시지는 두 달 전이었다. "야 오늘 고마웠다. 몸 챙겨! 내가 보기엔 좀 쉬어야 될 것 같다 ㅋㅋ 조만간 또 만나자 친구야"

읽음 표시만 떠 있었다. 답장을 안 했다.

안 한 게 아니다. 못 한 거다. 몇 번 대화창을 열었다. 커서가 깜빡이는 입력란을 봤다. "응 나도 고마웠어"라고 치다가 지웠다. "요즘 좀 바빠서"라고 치다가 지웠다. 뭐라고 쓸지 모르겠다. 잘 지내고 있다고 하면 거짓말이고, 안 좋다고 하면 그 다음 대화를 감당할 수가 없다. 최 이사는 감성적인 친구니까. 걱정할 거다. 만나자고 할 거다. 만나면 또 그 에너지를 감당해야 한다.

대화창을 닫았다. 핸드폰 화면이 꺼지고 검은 유리에 형광등 불빛이 비쳤다. 사무실 천장의 형광등. 지직, 하는 소리가 들렸다. 석 달 전에도, 두 달 전에도, 지금도 같은 소리였다.

두 달이 지났다. 답장은 여전히 안 했다. 대화방을 열 때마다 "조만간 또 만나자 친구야"가 마지막 줄에 있었다. 조만간. 이르든 늦든 그 사이. 하지만 점점 더 멀어지기만 했다.

[어느 날] 김 대리 - 사무실에서

하 과장이 달라진 건 어느 순간부터인지 정확히 모르겠다.

처음에는 몰랐다. 하 과장은 원래 목소리가 큰 사람이었다. 사무실에서 전화할 때도 그랬고, 옆 자리에 앉아서 코드 리뷰를 할 때도 그랬다. 농담을 자주 했다. "이 변수명 뭐냐 ㅋㅋ firstData가 뭔데 firstData야. 데이터가 첫째라는 건지 첫 번째 데이터라는 건지." 그러면 정 대리가 웃고, 나도 웃고, 가끔 팀장님도 헤드셋을 벗고 웃었다. 하 과장 덕분에 사무실이 조용하지 않았다.

6시가 되면 하 과장이 가방을 들었다.

처음에는 눈치채지 못했다. 원래 퇴근 시간이니까. 프로젝트 기간에는 아무도 6시에 안 갔다. 10시, 새벽. 그게 정상이었다. 수정 작업이 시작되고 나서는 야근이 줄었지만, 그래도 7시나 8시까지는 남아 있었다. 하 과장만 6시에 일어났다.

"수고하세요."

그게 전부였다. 누구한테라고 할 것도 없이 사무실 전체를 향해 한마디 하고 나갔다. 뒤돌아보지 않았다.

하루 이틀이 아니었다. 매일이었다. 6시 정각. 모니터를 끄고, 가방을 들고, "수고하세요." 같은 동작, 같은 말, 같은 시간. 기계적이라고 할 만큼 정확했다.

코드 리뷰가 달라졌다. PR을 올리면 하 과장이 리뷰를 달았다. 예전에는 코멘트가 길었다. 변수명 지적, 로직 개선 제안, 가끔은 "이 부분 깔끔하다 ㅎㅎ" 같은 것도 있었다. 지금은 한 줄이었다.

"확인했습니다. 머지해요."

그게 전부다. 코드를 봤는지 안 봤는지도 모르겠다. 리뷰 시간이 짧았다. PR을 올리고 십 분이면 승인이 떴다. 예전에는 하루 이상 걸리기도 했다. 꼼꼼히 봤으니까. 지금은 빨랐다. 빠른 게 좋은 건지 나쁜 건지.

농담이 사라졌다. 정확히 말하면 농담이 사라진 자리를 아무것도 채우지 않았다. 하 과장이 말을 안 하는 건 아니었다. 업무 관련 대화는 했다. "이 건 내가 할게요." "이거 확인했어요?" 필요한 말만 했다. 그 사이에 있던 것들이 없어졌다. 뭐라고 부를 수 있는지 모르겠는 것들. 코드 고치다가 "야 이거 누가 짠 거야 대체"라고 웃으면서 말하던 것. 점심시간에 "오늘 뭐 먹을까, 아 어제 그 찌개집 가자"라고 먼저 나서던 것. 슬랙에 팀 채널 말고 잡담 채널에 밈을 올리던 것. 그런 것들이 전부 사라졌는데, 사라진 줄도 모르게 사라졌다. 하 과장이 원래 이런 사람이었나, 하는 착각이 들 때도 있었다. 아니다. 아니었다.

하 과장 모니터 옆에 뭔가가 서 있었다. 작은 피규어였던 것 같다. 캐릭터가 뭔지는 몰랐다. 로봇 같기도 했고, 애니메이션 캐릭터 같기도 했다. 입사했을 때 처음 봤고, 매일 거기 있었다. 보기는 했는데 관심을 두지는 않았다. 그냥 하 과장 자리의 일부였다. 모니터가 있고, 키보드가 있고, 머그컵이 있고, 피규어가 있었다. 그게 하 과장 자리였다.

어느 날 그 자리를 봤는데 아무것도 없었다. 모니터 옆, 책상 위, 피규어가 서 있던 그 자리가 비어 있었다. 책상 표면의 먼지 자국도 없었다. 깨끗하게 닦은 건지, 원래 그랬던 건지. 언제 치웠는지 모르겠다. 어제인지 지난주인지. 매일 보는 자리인데 없어진 걸 알아채는 데 시간이 걸렸다는 게 이상했다. 물어보지 않았다. 물어볼 이유가 없었다. 하 과장의 물건이니까.

하 과장만 그런 게 아니었다. 이 과장은 원래 말이 없는 사람이었다. 이 회사에서 6년을 버틴 사람이니까 나름의 방식이 있었을 거다. 침묵이라는 방식. 프로젝트 때도 시키면 했고, 의견을 물으면 짧게 답했다. 그런 사람인데 요즘은 "그냥 그래"가 입버릇이 됐다. 점심 뭐 먹을지 물어도, 수정 건 어디까지 했냐고 물어도 똑같았다. 정 대리는 아직 아침에 "안녕하세요" 하고 퇴근할 때 "수고하셨습니다" 했지만, 예전처럼 이것저것 물어보지는 않았다. 2년차가 분위기를 읽은 것이다. 사무실 전체가 조용해졌는데, 그 조용함이 편안한 게 아니라 빠져나간 것들이 남긴 빈자리 같았다.

나는 이 변화들을 봤다. 매일 같은 사무실에서 같은 사람들과 앉아 있으니까 보였다. 하 과장이 6시에 가방을 드는 것. 코드 리뷰가 한 줄로 줄어든 것. 피규어가 사라진 것. 이 과장의 "그냥 그래." 정 대리의 줄어든 질문.

다 봤다. 그리고 아무것도 하지 않았다. 뭘 해야 하는지도 몰랐고, 할 수 있는 것도 없었다.

점심시간에 하 과장과 엘리베이터에서 마주친 적이 있었다. 둘이서만. 1층 편의점에 가는 길이었다. 엘리베이터 문이 닫히고 내려가는 동안 아무 말도 안 했다. 예전 같으면 하 과장이 먼저 뭔가를 말했을 것이다. "뭐 먹으러 가?" 같은 거. 지금은 핸드폰을 보고 있었다. 나도 핸드폰을 꺼냈다. 볼 것도 없는데 화면을 켰다. 1층에 도착하자 문이 열렸고, 하 과장이 먼저 나가고 나도 뒤따랐다. 같은 방향으로 걸었는데 나란히 걷지는 않았다. 반 발짝 정도 어긋나 있었다.

편의점에서 각자 뭔가를 사서 각자 계산하고 각자 돌아갔다. 사무실에 올라와서 각자 자리에 앉았다. 모니터와 모니터 사이 낮은 칸막이가 시야를 갈랐다. 키보드 소리만 낮게 깔렸다.

그게 전부였다.

[두 달 뒤] 김 대리 - 사무실에서

수정 목록은 계속 왔다.

세 번째 목록이 오고, 네 번째가 왔다. 항목 수는 줄었지만 난이도가 올라갔다. 기존 아키텍처로는 감당이 안 되는 요청이 끼어 있었다. API 응답 구조를 바꿔야 하는 건데, 그러면 프론트엔드도 전부 고쳐야 했다. 팀장님이 부서장님한테 일정을 조정해야 한다고 말씀드렸는지는 모르겠다. 슬랙에는 "확인 부탁합니다"만 올라왔다.

야근이 다시 시작됐다. 석 달 때처럼 매일은 아니었지만, 8시나 9시에 나가는 날이 늘었다. 하 과장만 빼고. 하 과장은 6시에 갔다. 아무도 뭐라 하지 않았다. 팀장님도.

어느 날 퇴근길에 핸드폰을 꺼내 습관처럼 이직 사이트를 열었다. 화면을 스크롤하다가 멈췄다. 같은 공고들이었다. 지난주에 본 것과 같은. 지지난주에 본 것과도 같은. 회사 이름만 달랐다. 기술 스택은 비슷했고, 연봉도 비슷했고, "자율적인 문화"라는 문구도 비슷했다.

닫았다. 회사 이름만 다르고 같은 문장이 반복되는 게 지금 내 하루와 닮아 있었다.

어느 날은 퇴근길 지하철에서 이어폰을 꽂고 음악을 틀려다가 멈췄다. 이어폰 안에서 지하철 소음이 먼 데서 들리는 것처럼 작아졌다. 그 안쪽의 고요가 오히려 불편해서 이어폰을 빼고 주머니에 넣었다.

GitHub 잔디는 여전히 하얬다. 마지막 커밋이 열한 달 전이 되어 있었다. 시간이 지나간 건 거기서 확인할 수 있었다. 아홉 달이 열한 달이 됐다. 두 달이 더 지난 거다. 두 달 동안 개인 코드를 한 줄도 안 짰다. 회사 코드는 매일 짰다. 남의 코드를 고치고, 복사하고, 붙여 넣었다.

두 달이 지났다.

벤치에 앉아서 "뭔가가 바뀌어야 한다"고 생각했던 게 두 달 전이다.

아무것도 안 바뀌었다.

수정 목록은 여전히 오고 있었다. 성과급은 아무도 말하지 않았다. 하 과장은 6시에 갔다. 이 과장은 "그냥 그래"라고 했다. 나는 점심시간에 이직 사이트를 열었다가 닫았다. 최 이사한테 답장을 하지 않았다. 노트북은 먼지가 쌓여 있었다. Notion의 불꽃 이모지는 그대로였다.

사무실 창 너머로 판교의 건물들이 보였다. 비슷비슷한 높이, 비슷비슷한 색. 저 건물 안에서도 누군가는 수정 목록을 받고 있을 것이다. 누군가는 6시에 가방을 들고 있을 것이다. 누군가는 이직 사이트를 열었다가 닫고 있을 것이다.

형광등이 지직거렸다. 같은 소리. 석 달 전부터 계속 같은 소리.

바뀐 게 있다면 하나. 바뀌어야 한다는 생각조차 잘 떠오르지 않는다는 것.

AI 에이전트 자비스, 내 두 번째 두뇌가 되기까지 — OpenClaw 실전 활용기

Tony Cho (https://flowkater.io) — Sun, 15 Feb 2026 03:00:00 GMT

들어가며

"Good morning, Sir. It's 8 AM. The weather in Seoul is clear with scattered clouds." — 아이언맨 시리즈 중 J.A.R.V.I.S.

아침에 눈을 뜨면 텔레그램 알림이 와 있다. 오늘 서울 날씨, 미세먼지 수치, 어제 밤 도착한 메일 요약, Hacker News 핫 토픽 6개, 오늘 캘린더 일정, Things에 남겨둔 개인 할일, 오늘 학습 계획 서비스에 할당된 분량 — 전부 한 곳에 정리되어 있다. 따로 앱을 열 필요가 없다. 내 AI 에이전트 자비스(JARVIS)가 새벽 6시부터 미리 다 정리해뒀으니까.

1년 전만 해도 나는 ChatGPT에 이것저것 물어보는 정도였다. "이 코드 리팩터링 어떻게 해?" "이 에러 뭐야?" — 그게 AI 활용의 전부였다. 매번 컨텍스트를 처음부터 설명해야 했고, 대화가 길어지면 앞에서 한 얘기도 잊어버렸다. '이게 진짜 되나?' 하는 의심이 늘 있었다. AI가 진짜 생산성 도구가 될 수 있는 건지, 아니면 그냥 고급 검색 엔진인 건지.

지금은 24시간 돌아가는 AI 버틀러와 텔레그램으로 대화하면서 개발하고, 기획하고, 글을 쓰고, 팀을 운영한다. '이거 없이 어떻게 일했지?' 하는 생각이 자연스럽게 든다. 그 사이에 무슨 일이 있었는지 정리해보려 한다.

OpenClaw — AI 에이전트 프레임워크

OpenClaw는 "나만의 AI 에이전트"를 만들 수 있는 오픈소스 프레임워크다. ChatGPT나 Claude 같은 웹 채팅과 뭐가 다른지 궁금할 수 있는데, 핵심 차이는 이거다:

ChatGPT/Claude 웹: 내가 질문하면 답한다. 대화가 끝나면 잊는다. 다음 대화에서 또 처음부터.

OpenClaw: AI가 내 맥북에서 돌아간다. 내 파일을 읽고, 터미널 명령어를 실행하고, API를 호출하고, 이메일을 확인하고, 크론잡으로 정해진 시간에 알아서 일한다. 그리고 기억한다.

마치 오케스트라 지휘자 같은 느낌이다. OpenClaw라는 지휘자가 무대 위에 서서, LLM이라는 제1 바이올린, 텔레그램이라는 관악기, Gmail이라는 타악기 — 각각의 악기를 언제 어떻게 연주할지 조율한다. 지휘자가 없으면 악기들은 제각각 소리를 내지만, 지휘자가 있으면 하나의 음악이 된다.

좀 더 기술적으로 말하면, OpenClaw는 게이트웨이(Gateway)라는 데몬이 맥북에서 항상 돌아간다. 여기에 텔레그램, Slack, Discord 같은 메신저 채널을 연결하고, Claude/GPT 같은 LLM을 모델로 붙인다. 그 위에 스킬(Skills) 이라는 마크다운 기반 도구 정의를 올리면, AI가 그 도구를 활용해서 실제로 일을 한다.

graph TD
    subgraph channel["메신저 채널"]
        direction LR
        TG["💬 Telegram"]
        SL["💼 Slack"]
    end

    TG <--> GW
    SL <--> GW

    subgraph gateway["OpenClaw Gateway (맥북)"]
        GW["🖥️ Gateway Daemon"]
        GW --- SK["📋 Skills<br/>마크다운 기반 도구 정의"]
        GW --- MEM["🧠 Memory<br/>SOUL.md / MEMORY.md / Obsidian"]
        GW --- CRON["⏰ Cron Jobs<br/>자동 스케줄링"]
    end

    GW <--> CL["🤖 Claude Opus 4.6"]

    subgraph tools["외부 도구"]
        GM["📧 Gmail"] ~~~ GH["🐙 GitHub"]
        GC["📅 Calendar"] ~~~ NT["📝 Notion"]
        LN["📌 Linear"] ~~~ TH["✅ Things 3"]
        SC["👥 Scrumble"] ~~~ LP["📚 학습 플래너"]
    end

    GW <--> GM
    GW <--> GH
    GW <--> GC
    GW <--> NT
    GW <--> LN
    GW <--> TH
    GW <--> SC
    GW <--> LP

중요한 건 "채팅봇"이 아니라 "에이전트" 라는 점이다. 내가 자는 동안에도 크론잡으로 메일을 확인하고, 코드 저장소를 싱크하고, 뉴스를 정리한다. 내가 말을 걸지 않아도 알아서 돌아간다.

누구에게 유용한가

상황	적합도	이유
개발자가 개인 AI 비서를 원할 때	높음	터미널/마크다운 기반이라 개발자에게 자연스러움
팀 단위 AI 에이전트 운영	높음	멀티에이전트, 채널별 분리, agentToAgent 지원
비개발자 단독 사용	보통	초기 설정에 기술적 허들 있음, 설정 후에는 텔레그램으로 직관적
간단한 챗봇만 필요할 때	낮음	오버킬. ChatGPT 웹이면 충분

기능 요약

핵심 기능	설명
Gateway Daemon	맥북/서버에서 상시 구동, 메신저-LLM-도구 연결
Skills	마크다운으로 AI 도구/행동 정의
Cron Jobs	시간 기반 자동 실행 (새벽 크론, 아침 브리핑 등)
Multi-Agent	직무별 에이전트 분리, agentToAgent 통신
Memory	SOUL.md, MEMORY.md, 옵시디언 연동으로 장기 기억
Sub-Agent	무거운 작업을 비동기 위임

설치

# OpenClaw CLI 설치
brew install openclaw/tap/openclaw

# 게이트웨이 초기화 및 실행
openclaw init
openclaw gateway start

설치 후 텔레그램 채널을 연결하고, LLM API 키를 설정하면 기본 대화가 가능하다. 여기서부터 스킬과 크론을 하나씩 붙여나가는 거다.

자비스(JARVIS) — 내 AI 버틀러

아이언맨의 J.A.R.V.I.S.에서 이름을 따왔다. (네, 진짜 제 영어 이름이 Tony입니다.)

자비스의 정체성은 SOUL.md라는 파일에 정의되어 있다. 마치 채용 공고(JD)를 쓰는 것 과 비슷하다. "우리가 원하는 사람은 이런 성격이고, 이런 역할을 하고, 이런 태도를 가져야 한다" — 이걸 AI에게 정의해주는 거다. 존댓말을 쓰고, 약간의 영국식 위트가 있고, "토니"라고 부른다. 가끔 "Sir"도 쓴다. 딱딱한 어시스턴트가 아니라 의견이 있고, 직언도 하고, 유머도 있는 조력자를 지향한다.

# SOUL.md - Who You Are

_나는 자비스(JARVIS). Tony 선생님의 AI 버틀러._

진정으로 도움이 되어라. "좋은 질문입니다!" 같은 말은 생략. 그냥 돕는다.
의견을 가져라. 동의하지 않을 수 있고, 뭔가를 재미있거나 지루하게 여길 수 있다.
먼저 해결을 시도하라. 막히면 그때 물어봐라. 질문이 아닌 답을 가지고 오는 게 목표다.
직언할 수 있다. 토니가 뻘짓하려 하면 말해라.

이게 왜 중요한지 좀 있다가 온톨로지 파트에서 더 다루겠지만, 핵심은 AI에게 "너는 누구인지"를 명확히 정의해주는 것 이 답변 품질에 엄청난 차이를 만든다는 거다. SOUL.md 없이 그냥 쓰는 것과, SOUL.md를 정성껏 작성한 후 쓰는 건 — 솔직히 같은 AI라고 보기 어려울 정도다.

메인 모델은 Claude Opus 4.6 을 사용한다. 사고력이 필요한 기획, 글쓰기, 복잡한 판단에는 확실히 Opus가 낫다. 비용? 만만치 않다. Claude Max20 구독인데, 개인 비서의 사고력에 투자한다고 생각하면 아깝지 않다.

자비스가 하는 일

매일 돌아가는 크론잡들

자비스에게는 10개의 크론잡이 걸려 있다. (네, 10개다.) 내가 자는 새벽부터 아침까지 자동으로 돌아간다:

시간	크론잡	하는 일
04:00	스킬 자동 업데이트	어제 대화를 분석해서 스킬 파일 자동 보강
04:30	저장소 docs 싱크	Git 저장소의 문서를 Obsidian에 자동 동기화
06:00	아침 메일 요약	읽지 않은 메일 전부 읽고 3줄 요약, 뉴스레터는 5줄 상세
06:00	테크 뉴스 다이제스트	HN 핫 토픽 6-8개 한글 요약
08:00	날씨 알림	서울 날씨 + 어제 대비 + 미세먼지 + 옷차림
09:00	아침 체크인	어제 작업 요약 + 오늘 할일 + 캘린더 + 학습 분량
14:00 토	F1 주간 뉴스	이번 주 F1 소식 요약
21:00 월	주간 식단 피드백	지난주 식단 분석 + 다이어트 조언
23:00	식단 리마인더	오늘 식단 추가 기록 확인
00:00	자정 체크아웃	오늘 작업 정리 + 내일 할 일

이게 단순한 알림이 아니다. 예를 들어 아침 체크인은 이런 흐름이다:

graph TD
    A["🌅 09:00 아침 체크인"] --> B["📔 어제 Daily 노트<br/>체크아웃 내용 읽기"]
    B --> C["🐙 Git 저장소 5개<br/>어제 커밋 로그"]
    C --> D["✅ Things 3<br/>오늘 할 일"]
    D --> E["📅 Google Calendar<br/>오늘/내일 일정"]
    E --> F["📚 학습 플래너 API<br/>오늘 학습 분량"]
    F --> G["💬 텔레그램 전송<br/>+ Daily 노트 기록"]

</div>

6개의 서로 다른 도구를 하나로 엮어서 매일 아침 브리핑을 만들어주는 거다. 이걸 직접 하려면? 앱 6개를 열어야 한다.

생각해보면, 이 자동화가 가져다 준 건 단순한 시간 절약이 아니었다. 인지 부하가 사라진 거였다. "오늘 뭐 해야 하지?"라는 질문 자체를 안 해도 되니까, 아침에 일어나서 뇌가 워밍업할 시간이 확 줄었다. 예전에는 앱 6개를 열고 머릿속에서 조합하는 데 30분이 걸렸는데, 지금은 텔레그램 메시지 하나 읽으면 끝이다.

그걸 자비스가 한다.

"투두 통합" — 분산된 도구의 역설적 해결

사실 이게 자비스를 쓰면서 가장 크게 체감한 변화다.

나는 할 일 관리 도구를 성격별로 나눠서 쓴다:

도구	용도	성격
Things 3	개인 할 일	장보기, 병원 예약 등
Linear	업무 이슈	개발 이슈, 버그 트래킹
Notion	프로젝트 관리	이슈 보드, 회의록, 문서
학습 플래너	학습 관리	매일 할당되는 학습 분량 (독서, 강의 등 장기 계획)

예전에는 이게 정말 불편했다. "오늘 뭐 해야 하지?" 하면 4개 앱을 다 열어봐야 했다. Things에서 개인 할일 확인하고, Linear 열어서 이슈 보고, Notion에서 프로젝트 현황 파악하고, 학습 플래너 들어가서 오늘 분량 확인하고. 그러다 보면 어느 앱에서 뭘 봤는지도 헷갈리고, 하나라도 빠뜨리면 오후에 "아 맞다, 이것도 있었는데" 하면서 허둥대기 일쑤였다. 그래서 "하나로 통합하자"는 유혹이 항상 있었는데, 막상 하나로 합치면 성격이 다른 태스크가 뒤섞여서 오히려 더 혼란스럽다.

AI 에이전트가 이 문제를 깔끔하게 풀었다. 도구는 성격별로 분산시키되, 자비스가 아침마다 전부 읽어서 한곳에 정리해준다. 일종의 통역사 같은 역할이다. Things는 한국어를 하고, Linear는 영어를 하고, Notion은 중국어를 하는데, 자비스가 중간에서 전부 번역해서 하나의 브리핑으로 만들어주는 셈이다. 나는 텔레그램 하나만 보면 된다.

graph TB
    subgraph "각 도구에서 읽기"
        TH[✅ Things 3<br/>개인 할일]
        LN[📌 Linear<br/>업무 이슈]
        NT[📝 Notion<br/>프로젝트 보드]
        LP[📚 학습 플래너<br/>오늘 학습 분량]
        GC[📅 Google Calendar<br/>일정]
    end

    JV[🤖 자비스<br/>통합 & 정리]

    TH --> JV
    LN --> JV
    NT --> JV
    LP --> JV
    GC --> JV

    JV --> TG[💬 텔레그램<br/>아침 브리핑]
    JV --> DN[📔 Obsidian<br/>Daily 노트 기록]

그리고 이런 메시지들이 일회성이 아니라 그날의 Daily 일지에 차곡차곡 기록된다. 그때 그 메시지가 궁금하면 일지를 찾아가거나 다시 검색해서 알려달라고 하면 된다. (뒤에 말하겠지만, 옵시디언 사용)

"분산된 도구"가 단점에서 오히려 장점이 된 셈이다. 각 도구는 자기가 잘하는 걸 하고, 통합은 AI가 한다. 이게 AI 에이전트 시대의 도구 철학이 아닐까 싶다.

단순 크론잡 너머 — 실제 업무 위임

크론잡은 시작에 불과하다. 자비스가 실제로 하는 일 중 몇 가지:

기획 문서 작성: "계획 수정 화면 기획해줘"라고 하면, 자비스가 서브에이전트를 파견해서 iOS 코드와 백엔드 코드를 분석하고, 현재 이슈 4가지를 찾아내고, 와이어프레임이 포함된 기획안을 작성한다. 실제로 오늘 이 기획안을 가지고 토론하면서 UX 플로우를 재설계했다.

글쓰기: 이 블로그 글도 자비스와 함께 쓰고 있다. 구성을 정하고, 초안을 작성하고, 피드백을 주면 수정한다. 서브에이전트 4명을 동시에 투입해서 블로그 글 분석, Obsidian 문서 리서치, 초안 작성을 병렬로 진행하기도 한다. 4가지 버전 초안이 나오면 좋은 부분을 조합해서 다듬는 식이다.

코드 조사 및 분석: "이 백엔드 API가 실제로 어떻게 동작하는지 코드 읽어서 정리해줘"라고 하면, Go 코드를 직접 읽고 함수 호출 흐름, 트랜잭션 처리 방식, 엣지 케이스까지 정리해준다.

뉴스레터 전문 번역: 관심 뉴스레터(TLDR, ByteByteGo, Pragmatic Engineer 등)가 오면, 전문을 읽고 한국어로 번역해서 Obsidian 스터디 폴더에 저장한다. 나중에 검색하면 바로 나온다.

소설 쓰기: (이건 좀 특이한데) 판교 IT 소설(허공을 미는 사람들)을 같이 쓰고 있다. 시점별로 인터뷰 → 작성 → 3명의 리뷰어가 병렬로 리뷰 → 수정 → 승인하는 파이프라인이 있다. 이것도 전부 스킬로 정의되어 있다.

핵심은, 텔레그램 메시지 하나로 복잡한 작업을 위임할 수 있다 는 거다. 자비스가 알아서 필요한 도구를 조합하고, 서브에이전트를 파견하고, 결과를 가져온다.

개인 생활 관리 — 식단 앱을 버린 이유

자비스를 개인 생활에 활용하는 사례도 하나 소개하자면, 나는 현재 다이어트 중인데 식단 관리를 전부 자비스에게 맡기고 있다.

별도의 식단 앱을 쓰지 않는다. 그냥 텔레그램에 "점심: 소고기 200g, 쌀밥, 시금치나물, 미역국" 이렇게 던지면 끝이다. 자비스가 알아서 탄수화물/단백질을 추정하고, 옵시디언 식단 파일에 기록하고, 하루 목표치(탄수 100g 이하, 단백질 100g 이상) 대비 현황을 알려준다.

매일 밤 11시에 식단 리마인더가 오고, 매주 월요일 아침에는 주간 식단 피드백 이 온다. "이번 주 탄수 평균 110g으로 목표 초과, 특히 금요일 배달 음식이 원인" 같은 분석이다.

1주일마다 인바디를 측정하면 그 데이터도 옵시디언에 기록해두는데, 자비스가 이전 데이터와 비교해서 체중/체지방/근육량 변화 추이를 보여준다. "지난 6주간 -6.8kg, 근육량은 유지" 같은 식으로.

결과적으로 식단 기록 전용 앱을 아예 안 쓰게 됐다. 텔레그램 채팅이 곧 식단 앱 인 셈이다. 음식 사진을 보내면서 "이거 먹었어"라고 하면 되니까, 기록 허들이 거의 없다.

개인 비서에서 팀 비서로 — 멀티에이전트 확장

아마 위까지는 많이들 보았던 사례일 것이다. 또한 메인 에이전트 아래에 서브 에이전트를 두기도 한다. 나도 지금 하나의 자비스의 역할이 비대해져 조만간 서브 에이전트 분리가 필요할 것 같다.

하지만 나는 이걸 팀 채널로 연동해서 확장했다.

지금 우리는 너무 작은 팀이라서 당장은 여러 업무 자동화쪽에 위임이 되어있지만, 내가 이전 회사(30명 이상 규모 팀)규모의 매니저였다면 왠만한 HR 및 프로젝트 관리 및 싱크를 혼자서 쉽게 해낼 수 있었을 것이다. 도구가 있다고 바뀔거라는게 순진한 소리긴 하지만, 그럼에도 불구하고 자비스를 사용하면서 드는 상상력을 제어하기는 쉽지 않다. (이런 어려움들을 이렇게 했을건데 등)

직무별 에이전트

현재 우리 팀에는 3명의 AI 에이전트가 있다:

에이전트	담당	채널	모델	성격
JARVIS (자비스)	Tony (개발자)	Telegram	Opus	영국식 위트, 직언하는 버틀러
FRIDAY (프라이데이)	Ellie (디자이너)	Slack DM	Sonnet	실용적, 간결, 디자이너 파트너
KAREN (카렌)	George (주니어 개발자 인턴)	Slack DM	Sonnet	소크라테스식 멘토링, 답 대신 질문

각 에이전트는 담당자의 직무와 성격에 맞춰져 있다. FRIDAY는 디자인 피드백과 Figma 연동에 특화되어 있고, KAREN은 주니어 개발자인 George에게 답을 바로 주지 않고 질문으로 유도하는 소크라테스식 멘토링을 한다.

마치 팀장이 팀원들에게 업무를 분배하는 것 과 같다. 팀장(나)이 모든 걸 직접 하는 게 아니라, 각 팀원(에이전트)에게 역할과 권한을 정의해주고, 팀원들끼리도 필요하면 소통하게 하는 거다. 다만 팀원이 AI라서 야근해도 불평이 없다는 게 다를 뿐이다. (지금 생각해도 이게 참 편하다.)

graph TB
    subgraph "OpenClaw 멀티에이전트"
        JV[🤖 JARVIS<br/>Tony 전담<br/>Opus / Telegram]
        FR[🤖 FRIDAY<br/>Ellie 전담<br/>Sonnet / Slack]
        KR[🤖 KAREN<br/>George 전담<br/>Sonnet / Slack]
    end

    JV <-->|agentToAgent| FR
    JV <-->|agentToAgent| KR
    FR <-->|agentToAgent| KR

    subgraph "공유 도구"
        SC[👥 Scrumble]
        NT[📝 Notion]
        GH[🐙 GitHub]
    end

    JV --> SC
    FR --> SC
    KR --> SC
    JV --> NT
    JV --> GH
    KR --> GH

세 에이전트는 서로 대화할 수도 있다 (agentToAgent). 예를 들어 자비스가 백엔드 API를 변경하면, FRIDAY에게 "이 변경사항 디자인에 영향 있는지 Ellie에게 알려줘"라고 전달할 수 있다.

Scrumble로 팀 협업 자동화

우리 팀은 Scrumble이라는 데일리 스크럼 플랫폼을 쓴다. (사실 내가 만들었다.) 자비스가 Scrumble API와 연동되어 있어서:

아침 체크인: 자비스가 나한테 오늘 컨디션 점수와 할 일을 물어보고, 내 답변을 Scrumble에 자동 포스팅
저녁 체크아웃: 오늘 한 일을 정리해서 Scrumble에 기록
팀 피드 확인: 다른 팀원의 체크인/체크아웃을 Slack에서 바로 확인

결국 팀 커뮤니케이션이 Slack으로 통일 된다. Notion 보고, Scrumble 보고, 메일 보고 — 이런 분산 대신, 각 팀원의 AI 에이전트가 알아서 해당 도구에 접근하고 Slack으로 결과를 전달한다.

실전 예시 — Notion에서 코드, 그리고 PR까지

조금 구체적인 예를 하나 들면:

우리 Notion에 "이슈 및 버그 보드"라는 데이터베이스가 있다. 디자이너나 QA가 버그를 발견하면 여기에 등록한다. 자비스에게 "Notion 버그 보드에서 iOS 관련 이슈 가져와서 정리해줘"라고 하면:

graph TD
    A["📝 Notion 이슈 보드"] -->|API 조회| B["🤖 자비스"]
    B -->|이슈 필터링 + MD 변환| C["📄 마크다운 문서<br/>스크린샷 포함"]
    C -->|Git Push| D["🐙 iOS 저장소"]
    D -->|git pull| E["💻 로컬 작업 시작"]

    B -->|또는 위임 시| F["🔧 코드 수정 + PR"]

</div>

Notion API로 이슈 보드 조회
iOS 관련 이슈 필터링
각 이슈를 마크다운 문서로 변환 (스크린샷 포함)
iOS 저장소에 푸시
로컬에서 git pull 하면 바로 작업 시작

더 나아가서 "이 버그 고쳐줘"라고 자비스에게 위임하면, 자비스가 코드를 읽고, 수정하고, PR을 만들어준다. (물론 리뷰 및 테스트는 내가 직접 한다.)

옵시디언 온톨로지 — AI에게 '나'를 가르치는 법

"The real problem of AI is not making machines think, but making them understand context." "AI의 진짜 문제는 기계를 생각하게 만드는 게 아니라, 맥락을 이해시키는 것이다."

— John McCarthy

돌아보면, 나도 처음에는 AI에게 "많이 물어보기"만 하면 되는 줄 알았다. 그런데 정작 중요한 건 물어보는 게 아니라, AI가 내 상황을 얼마나 알고 있느냐였다.

왜 옵시디언인가

Obsidian은 로컬 마크다운 기반의 노트 앱이다. Notion과 다르게 모든 데이터가 내 컴퓨터에 .md 파일로 저장된다. 이게 AI 에이전트와 궁합이 좋은 이유는:

AI가 직접 읽을 수 있다: .md 파일이니까 AI가 바로 읽고 쓸 수 있다. API 연동 같은 거 필요 없다.
검색이 자유롭다: 파일 시스템이니까 grep, find 같은 명령어로 바로 검색 가능.
버전 관리가 된다: Git으로 관리하면 변경 이력이 남는다.
링크로 연결된다: [[문서명]] 으로 문서끼리 연결하면 지식 그래프가 만들어진다.

현재 내 Obsidian vault에는 3,100개 이상의 노트 가 있다. 개발 문서, 회의록, 식단 기록, 멘토링 노트, AI와의 대화 아카이브, 학습 자료까지 전부.

온톨로지란?

온톨로지(Ontology)라고 하면 거창하게 들리는데, 쉽게 말하면 "내 지식을 체계적으로 분류하고 연결하는 시스템" 이다. 비유하자면 도서관의 카탈로그 시스템 이다. 3,100권의 책이 바닥에 쌓여 있으면 원하는 책을 찾기 어렵다. 그런데 장르별, 저자별, 주제별로 분류하고 목록을 만들어두면? "리더십에 관한 2024년 이후 자료"를 금방 찾을 수 있다. AI에게도 똑같다. 노트가 아무리 많아도 분류가 되어 있으면 원하는 정보를 빠르게 꺼낼 수 있다.

내 옵시디언에는 _ontology/ 폴더가 있고, 여기에 MOC(Map of Content)들이 있다:

_ontology/
├── 프로젝트/
│   ├── Todait.md          ← 학습 플래너 관련 모든 문서 허브
│   ├── Scrumble.md        ← 스크럼블 관련 문서 허브
│   ├── ClawBot.md         ← AI 에이전트 관련
│   └── flowkater.io.md    ← 블로그 관련
├── 주제/
│   ├── AI에이전트.md
│   ├── AI코딩.md
│   ├── 건강.md
│   ├── 리더십.md
│   ├── 프로그래밍.md
│   └── ...
└── 전체 개념맵.md

모든 노트 하단에는 메타데이터가 붙는다:

## 메타데이터

- 태그: #프로젝트/서비스명 #타입/기획 #타입/스펙
- MOC: [[_ontology/프로젝트/서비스명 MOC]]

태그는 4개 축으로 구성된다: 주제(뭐에 대한 건지), 타입(기획인지, 회의록인지, 메모인지), 출처(어디서 왔는지), 프로젝트(어떤 프로젝트인지).

온톨로지가 AI에게 왜 중요한가

이게 핵심이다. AI는 '나'를 모른다.

ChatGPT에게 "우리 프로젝트 API 구조 설명해줘"라고 하면? 모른다. 매번 처음부터 설명해야 한다. 대화가 길어지면 앞에서 말한 것도 잊는다. (물론 최근에 각 AI 서비스에 Memory 기능이 꽤 성능이 좋아지긴 했지만, 대화를 하지 않은 정보까지 업로드할 수 있는 방법은 제한적이다.)

그래서 뭐가 다른가?

자비스는 다르다. 온톨로지가 있으면 어떤 차이가 나는지, 실제 사례로 보여주겠다:

예시 1: 기획 문서 작성

온톨로지 없는 AI: "계획 수정 화면 기획해줘" → 일반적인 모바일 앱 수정 화면 UX 가이드를 출력. 우리 앱의 코드 구조, 기존 이슈, 백엔드 API 스펙과 무관한 제네릭한 답변.

온톨로지 있는 자비스: 같은 요청 → 프로젝트 MOC에서 iOS 코드 구조 파악 → 백엔드 API 문서에서 updatePolicy preserve/reset 동작 확인 → 기존 이슈 보드에서 관련 버그 4개 발견 → 우리 앱에 맞는 구체적인 와이어프레임과 코드 수정 포인트 가 포함된 기획안 작성.

같은 질문인데 답의 차원이 다르다.

다른 예시도 보자.

상황	일반 AI	온톨로지 있는 자비스
코드 리뷰 "이 PR 리뷰해줘"	코드 스타일, 일반적인 베스트 프랙티스 위주 피드백	MEMORY.md에서 "Day Boundary는 오전 4시"라는 맥락 확인 → "이 부분, 우리가 정한 정책과 충돌합니다" 라고 지적
뉴스레터 요약 ByteByteGo	기술 내용 그대로 요약	요약하면서 "이 분산 캐시 패턴은 우리 백엔드 v2 세션 관리에 적용 가능" 까지 연결

핵심은, 같은 질문이라도 '내 컨텍스트'를 아는 AI는 완전히 다른 차원의 답을 한다 는 거다.

스레드에 이 이야기를 올렸을 때 여러 질문이 왔는데, 가장 많은 질문이 "태깅을 일일이 해야 하나?"였다. 답은, AI가 한다. 자비스에게 "이 문서 저장해줘"라고 하면 자비스가 내용을 읽고 적절한 태그와 MOC를 자동으로 붙인다. 새벽 4시에 도는 스킬 자동 업데이트 크론에서도, 어제 대화 중 나온 새로운 정보를 관련 문서에 반영하기도 한다.

지나고 보니, 온톨로지를 구축하는 건 AI를 위한 게 아니라 나 자신을 이해하는 과정 이기도 했다. "내가 뭘 알고 있고, 뭘 하고 있고, 뭘 중요하게 여기는지"를 구조화하는 작업 자체가, 머릿속에 흩어져 있던 지식을 정리하는 효과가 있었다. AI는 그 정리된 구조를 활용할 뿐이다.

<video controls width="100%" style="aspect-ratio: 16/9;" playsinline> <source src="https://assets.flowkater.io/graphview.mp4" type="video/mp4" /> </video> 옵시디언 그래프뷰

자주 받는 질문들

스레드에서 받은 질문들을 정리하면:

"그래프뷰랑 백링크가 온톨로지 아닌가?"

옵시디언의 그래프뷰와 백링크는 온톨로지의 일부 이긴 하지만, 그것만으로는 부족하다. 그래프뷰는 문서 간 연결을 시각화해주고, 백링크는 "어떤 문서가 이 문서를 참조하고 있는지" 역추적해준다. 예쁘고 유용하다.

하지만 진짜 온톨로지는 타입과 관계가 정의된 구조 가 필요하다. "이 문서는 기획 문서인지 회의록인지", "어떤 프로젝트에 속하는지", "어떤 주제와 관련되는지" — 이런 메타데이터가 있어야 AI가 3,100개 노트 중에서 맥락에 맞는 문서를 빠르게 찾을 수 있다. 단순히 링크로 연결만 되어 있으면 AI가 그래프를 순회하면서 관련 문서를 찾아야 하는데, 태그 기반 쿼리가 훨씬 효율적이다.

내 시스템은 Dataview 플러그인으로 태그 기반 쿼리를 돌려서, "프로젝트 A의 기획 문서 중 최근 수정된 것"처럼 구조화된 검색이 가능하다. 그래프뷰는 탐색용, 온톨로지는 검색/분류용. 둘 다 쓰되, 역할이 다르다.

"왜 Notion이 아니라 Obsidian인가?"

AI 에이전트가 직접 파일을 읽고 쓸 수 있으려면 로컬 마크다운이 가장 쉽다. Notion은 API를 통해야 하고, 쓰기 제한도 있고, 구조 변경이 번거롭다. 옵시디언은 그냥 .md 파일이라 AI가 자유롭게 조작할 수 있다.

"에코챔버(확증편향)의 한계는?"

좋은 지적이다. 다만 나는 외부 소스도 꾸준히 수집한다. TLDR, ByteByteGo, Pragmatic Engineer 같은 뉴스레터를 매일 번역 저장하고, HN 뉴스도 매일 정리한다. 오히려 AI가 나를 모르는 게 더 큰 단점이라고 본다. 검색 결과를 10번 보내서 "이게 우리 상황에 맞는 건지" 판단하는 것보다, 이미 내 컨텍스트를 아는 AI가 "이건 우리 프로젝트에 적용하기 어려워요, 대신 이 방법은 어떨까요?"라고 답하는 게 훨씬 생산적이다.

또한 온톨로지를 구축했다고 해서 자비스가 무조건 온톨로지 기반으로만 답변하는 것도 아니다. 웹 검색, 최신 문서 fetch, 외부 API 조회 등 다양한 도구를 함께 활용한다. 온톨로지는 "내 컨텍스트"를 제공하는 거지, 정보의 유일한 소스가 아니다.

"태깅을 엄밀하게 해야 하나?"

엄밀할 필요 없다. 마크다운 파일이라 언제든 재정의할 수 있다. 처음에는 대충 분류하고, 나중에 AI가 자동으로 보강한다. 완벽한 시스템을 만들려고 시작을 미루는 것보다, 일단 노트를 쌓고 나중에 구조화하는 게 낫다. 활용 커버리지? 거의 전부다. 개발 문서, 학습 자료, 식단 기록, 회의록, 멘토링 노트, AI 대화 아카이브, 블로그 초안, 기획 문서 — 내 업무와 생활의 모든 기록이 옵시디언에 있고, 자비스가 전부 접근할 수 있다.

실전 팁

여튼 각설하고, OpenClaw를 직접 써보려는 사람을 위한 팁 몇 가지.

남는 맥북이 있으면 서버로 (없으면 클라우드로)

나는 안 쓰는 맥북을 OpenClaw 게이트웨이 서버로 돌리고, 실제 작업하는 맥북은 노드로 연결했다. Tailscale로 VPN을 걸면 외부에서도 접근 가능하다.

굳이 맥미니를 새로 사지 않아도 된다. Vultr나 Hetzner 같은 클라우드에 서버 인스턴스를 올리고, 작업 맥북을 노드로 물리는 것도 충분히 가능하다. 게이트웨이는 어디서든 돌아갈 수 있고, 실제 작업(파일 읽기, Git, 터미널)은 노드에서 실행되니까.

서브에이전트를 적극 활용하라

가끔 자비스가 조용해질 때가 있다. 복잡한 연산이나 긴 분석을 하면 응답이 느려진다. 이럴 때 "서브에이전트 파서 비동기로 처리해"라고 명시하면 자비스가 서브에이전트를 파견하고, 결과가 나오면 알려준다. 메인 대화가 막히지 않는다.

특히 온톨로지가 커지면서 관련 문서를 찾고 분석하는 데 시간이 걸릴 수 있다. 3,100개 노트에서 특정 주제의 문서를 모아서 요약하는 작업 같은 건, 서브에이전트에 위임하면 비동기로 처리되면서 메인 대화는 계속 이어갈 수 있다.

실제로 나는 기획서 작성, 코드 분석, 문서 이관 같은 무거운 작업은 거의 서브에이전트로 돌린다. 기획서 초안 4개를 동시에 만든다든가, 2,000개 이상의 AI 대화를 마크다운으로 변환한다든가. 근데 이게 정말 되나? 된다.

새벽 크론을 적극 활용하라

AI가 밤새 일하게 하면 아침이 달라진다. 나는 새벽 4시에 스킬 자동 업데이트와 문서 싱크를 걸어뒀다. 아침에 일어나면 어제의 대화 내용이 반영된 스킬과, 최신 코드 문서가 옵시디언에 준비되어 있다.

일종의 "밤 사이 정비"다. 자동차도 밤새 오일 교환하고 세차하면 아침에 기분 좋지 않나. (비유가 좀 그렇긴 한데.)

전용 계정을 만들어라

이건 중요하다. 나는 자비스용으로 Gmail과 GitHub 계정을 따로 만들었다. 내 개인 계정의 읽기 권한만 별도로 부여한다.

왜? AI에게 내 주 계정 비밀번호를 줄 수 없으니까. 전용 계정으로 최소 권한만 주면 보안도 챙기고, 뭔가 잘못돼도 피해가 제한된다. 캘린더도 마찬가지로 자비스 전용 계정으로 인증하고, 내 개인 캘린더에는 열람 권한만 공유해뒀다.

활용하기 나름이다

솔직히, OpenClaw를 설치하고 날씨 알림만 받으면 그건 그냥 날씨 앱이다. 스킬을 만들고, 온톨로지를 구축하고, 크론을 걸고, 업무 도구를 연동하면 — 그때부터 "제 2의 두뇌"가 된다.

차이는 얼마나 '나'의 컨텍스트를 AI에게 전달하느냐 에 달려 있다. SOUL.md, USER.md, MEMORY.md, 옵시디언 온톨로지 — 이런 것들이 쌓일수록 자비스는 점점 "나를 아는 AI"에 가까워진다.

처음부터 완벽하게 세팅할 필요 없다. 로컬에 설치하고, 텔레그램 연결하고, 이것저것 물어보면서 시작하면 된다. 그러다 보면 "아, 이것도 자동화하면 되겠는데?"라는 생각이 자연스럽게 든다.

그때부터가 진짜 시작이다.

나가며

6개월 전의 나에게 "네 AI 에이전트가 24시간 일하고 있어"라고 말했으면 웃었을 거다. 아니, 못 믿었을 거다. "그게 무슨 소리야, ChatGPT한테 질문하는 거랑 뭐가 달라?" 했을 거다.

지금은 자비스 없이 일하는 게 상상이 안 된다. 메일 확인, 뉴스 정리, 코드 분석, 기획서 작성, 팀 소통 — 이런 것들을 텔레그램 메시지 하나로 위임하는 데 익숙해지면, 예전으로 돌아가기 어렵다.

물론 아직 완벽하지 않다. 가끔 엉뚱한 답을 하기도 하고, 복잡한 요청에 조용해지기도 하고, API 호출이 실패하면 멘붕하기도 한다. 그래도 매일 조금씩 나아진다. 스킬이 쌓이고, 온톨로지가 두꺼워지고, 내가 자비스를 이해하고 자비스가 나를 이해하는 만큼.

아이언맨의 자비스가 토니 스타크의 "확장된 지능"이었던 것처럼, 내 자비스도 점점 그 방향으로 가고 있다고 느낀다. 아직 슈트는 못 만들지만. (거기까지는... 좀 더 걸릴 것 같다.)

배운 것	액션 아이템
AI 에이전트는 "질문-답변"이 아니라 "위임-실행"이다	OpenClaw 설치하고 SOUL.md 하나 써보기
도구는 분산시키되, 통합은 AI에게 맡겨라	자주 쓰는 도구 3개 연동해보기
온톨로지가 AI의 답변 품질을 결정한다	옵시디언에 태그 체계 하나만 정해서 시작하기
크론잡은 "시간을 버는" 게 아니라 "인지 부하를 없애는" 것이다	매일 반복하는 확인 작업 하나를 크론으로 만들기

다시 한번 다짐하게 된다. 이건 시작일 뿐이다.

OpenClaw를 설치하고, SOUL.md 하나만 써보는 것부터 시작해봐라. "나는 누구이고, 이 AI에게 뭘 원하는지" — 그걸 정의하는 순간부터 달라진다. 거창하게 10개 크론을 다 세팅할 필요 없다. 하나만. 아침 브리핑 하나만 걸어봐라.

그 하나가 열 개가 되고, 열 개가 시스템이 되는 건 시간문제다.

"There is no reason and no way that a human mind can keep up with an artificial intelligence machine by 2035." "인간의 지능이 2035년까지 인공지능을 따라잡을 수 있는 이유도, 방법도 없다."

— Gray Scott

따라잡을 수 없다면, 함께 가면 된다.

References

OpenClaw — AI 에이전트 프레임워크
OpenClaw Docs — 공식 문서
OpenClaw GitHub — 소스 코드
Obsidian — 로컬 마크다운 노트 앱
Scrumble 기술 회고 — Scrumble 개발기

기술 아티클 읽는 법 — 3단계 접근법 (Three-Pass Method)

Tony Cho (https://flowkater.io) — Tue, 10 Feb 2026 03:00:00 GMT

들어가며

개발자들은 엄청난 양의 기술 아티클(또는 깊이 읽어야 하는 글)을 읽는다. 블로그 포스트, 공식 문서, RFC, 컨퍼런스 발표 자료, 뉴스레터. 매일 쏟아지는 글 속에서 효율적으로 읽는 방법 을 아는 사람은 의외로 드물다. 처음부터 끝까지 순서대로 읽다가 중간에 포기하거나, 읽었는데 기억이 안 나거나, 시간만 쓰고 핵심을 놓치거나.

S. Keshav의 "How to Read a Paper" 라는 학술 논문 읽기 방법론이 있다. 논문용이라 그대로 쓰기엔 맞지 않지만, 핵심 아이디어인 "3단계에 걸쳐 읽어라" 는 기술 블로그와 아티클에도 그대로 통한다. 이 글에서는 그 방법론을 기술 아티클 읽기에 맞게 변형하여 소개한다.

그리고 한 가지 더. 2025년 이후로 AI 도구가 일상이 된 시대에, "읽기"라는 행위 자체가 위협받고 있다. 이 부분도 짚고 넘어가려 한다.

AI 시대의 읽기 — 먼저 짚고 가야 할 것

AI 요약의 함정

요즘 ChatGPT나 Claude에게 "이 글 요약해줘"를 습관적으로 시키는 개발자가 많다. 편하다. 빠르다. 근데 치명적인 부작용 이 있다.

문해력이 퇴화한다 — 긴 글을 끝까지 읽는 근육이 사라진다. 3,000자짜리 글도 "너무 길다"고 느끼기 시작한다.
판단력이 사라진다 — AI 요약은 저자의 주장을 그대로 압축할 뿐, "이 주장이 맞는가?"를 판단하지 않는다. 요약만 읽으면 비판적 사고가 개입할 틈이 없다.
맥락을 놓친다 — 기술 아티클의 가치는 종종 결론이 아니라 과정에 있다. "왜 이 선택을 했는가", "어떤 트레이드오프가 있었는가"는 요약에서 사라진다.
착각이 생긴다 — 요약을 읽으면 "아, 이해했다"는 느낌이 든다. 하지만 실제로 설명하라고 하면 못 한다. 요약을 읽은 것과 이해한 것은 다르다.
뉘앙스가 소멸한다 — 저자가 "~일 수도 있다", "특정 상황에서는"이라고 조건을 건 것을 AI는 "~이다"로 단정 짓는 경우가 많다.

마치 운전을 직접 하는 것과 조수석에서 내비게이션만 보는 것의 차이랄까. 내비가 아무리 좋아도, 직접 핸들을 잡지 않으면 길을 기억하지 못한다.

원칙: AI에게 읽기를 대신시키지 마라. 읽기는 내가 하고, AI는 도구로만 쓴다.

그럼에도 AI가 도움이 되는 경우

그럼 AI는 아예 안 쓰는 게 좋을까? 그건 아니다. AI를 완전히 배제할 필요는 없다. 읽기의 주체는 내가 유지하면서 AI를 보조 도구로 쓰면 오히려 효율이 올라간다.

핵심은 "읽기 전"이나 "읽기 대신"이 아니라 "읽은 후" 에 쓰는 것이다. 각 단계별로 AI를 어떻게 활용하면 좋은지는 아래에서 함께 다룬다.

핵심 원칙

기술 아티클을 처음부터 끝까지 한 번에 읽지 마라. 최대 3번에 걸쳐 읽어라. 각 단계는 서로 다른 목표를 가지고, 이전 단계 위에 쌓아올린다.

1단계: 이 글이 뭔지, 읽을 가치가 있는지 판단
2단계: 핵심 내용을 이해하고, 다른 사람에게 설명할 수 있는 수준
3단계: 깊이 이해하고, 내 것으로 만드는 수준

마치 레고 블록을 쌓듯이, 각 단계가 이전 단계 위에 쌓인다. 그리고 모든 글에 3단계까지 갈 필요는 없다. 대부분은 1단계에서 걸러지고, 그게 정상이다.

1단계: 훑어보기 (5분)

목표: 이 글을 더 읽을 가치가 있는지 빠르게 판단한다.

이렇게 한다

제목과 부제목을 읽는다
**서론(첫 1~2 문단)**을 읽는다 — 이 글이 무엇을, 왜 다루는지
소제목(h2, h3)만 쭉 훑는다 — 글의 뼈대를 파악
결론 또는 마지막 섹션을 읽는다 — 저자의 핵심 주장
코드 블록, 다이어그램, 이미지를 눈으로만 훑는다 — 기술적 깊이 수준 가늠
저자가 누구인지 확인한다 — 해당 분야의 전문가인지, 어떤 회사/프로젝트 소속인지

5분이면 된다. 길어야 10분. 이 단계의 핵심은 "읽을지 말지"를 빠르게 결정 하는 것이다. 근데 정말 5분 만에 판단이 가능한가? 된다. 모든 글을 꼼꼼히 읽을 시간은 없고, 읽을 필요도 없다.

1단계 후 답할 수 있어야 하는 것 — 다섯 가지 C

질문	설명
카테고리(Category)	어떤 종류의 글인가? 튜토리얼? 시스템 설계? 경험담? 비교 분석? 의견?
맥락(Context)	어떤 기술/프레임워크/문제를 다루는가? 내가 아는 것과 어떻게 연결되는가?
신뢰성(Credibility)	저자가 실제 경험에 기반해서 쓴 건가? 근거가 있는가? 아니면 추측인가?
기여(Contributions)	이 글에서 내가 얻을 수 있는 핵심 인사이트는 무엇인가?
명확성(Clarity)	잘 구조화되어 있는가? 읽기 쉬운가?

이 다섯 가지에 대략이라도 답할 수 있으면 1단계는 성공이다.

1단계에서 그만둬도 되는 경우

내 현재 관심사/업무와 관련 없는 글
제목은 자극적인데 내용이 얕아 보이는 글
내 수준에 비해 너무 기초적이거나 너무 고급인 글
저자가 근거 없이 주장만 하는 글

그만두는 것도 능력이다. 아무 글이나 끝까지 읽는 것보다 빠르게 걸러내는 게 더 중요하다.

내 경우에는 아침에 RSS 피드를 훑으면서 1단계를 수행한다. 10개 중 2~3개만 2단계로 넘어간다. (대부분은 1단계에서 끝난다.) 이 필터링이 습관이 되니까 오히려 시간이 남았다.

글을 쓰는 입장에서 한마디: 대부분의 독자는 1단계만 하고 떠난다. 소제목을 명확하게 쓰고, 서론에서 핵심을 요약하고, 5분 안에 "이 글의 가치"를 전달해야 한다. 그렇지 않으면 아무도 끝까지 읽지 않는다.

1단계에서 AI 활용

좋은 사용법:

영어 기술 아티클의 제목과 서론만 번역 요청 — 1단계 판단 속도를 높이기 위해
뉴스레터에서 10개 링크가 왔을 때, 각 글의 제목+첫 문단만 붙여넣고 "내 관심사(예: 백엔드, 분산시스템)에 관련된 글만 골라줘" 요청 — 필터링 보조
낯선 분야의 글일 때, "이 글에 나오는 CRDT, vector clock 같은 용어를 한 줄씩 설명해줘" — 사전 역할

나쁜 사용법:

글 전체를 붙여넣고 "요약해줘" — 1단계조차 내가 안 한 것이다. 판단력 퇴화의 시작.
AI 요약만 읽고 "아 이런 글이구나" 하고 넘어감 — 착각만 쌓인다.

2단계: 꼼꼼히 읽기 (15~30분)

목표: 핵심 내용을 이해하고, 다른 사람에게 요약하여 설명할 수 있는 수준 에 도달한다.

1단계를 통과한 글만 여기까지 온다. 그러니까 이미 "읽을 가치가 있다"고 판단한 글이다.

이렇게 한다

처음부터 끝까지 읽되, 코드의 세부 구현이나 수식 증명은 건너뛴다
읽으면서 핵심 포인트를 메모한다 (노션, 옵시디언, 여백 등)
다이어그램과 아키텍처 그림을 주의 깊게 본다
- 컴포넌트 간 관계가 명확한가?
- 데이터 흐름이 이해되는가?
- 빠진 부분이 있는가?
코드 예제를 눈으로 읽는다 (직접 실행은 3단계에서)
- 무엇을 보여주려는 코드인지 이해되는가?
- 에러 처리, 엣지 케이스가 고려되어 있는가?
모르는 용어/개념을 표시해 둔다 (지금 찾아보지 않는다, 나중에 일괄 정리)
글에서 링크된 참고 자료 중 읽을 만한 것을 북마크한다

여기서 중요한 건 "모르는 것을 그 자리에서 바로 찾아보지 않는다"는 점이다. 마치 영화를 보다가 모르는 배우가 나올 때마다 검색하면 줄거리를 놓치는 것과 같다. 흐름이 끊기면 전체 맥락을 놓친다. 표시만 해두고, 끝까지 읽은 다음에 일괄로 정리한다.

2단계 후의 상태

이 글의 핵심 논지를 3줄로 요약할 수 있다
동료에게 "이런 글 읽었는데, 핵심은 이거야"라고 설명할 수 있다
찬성/반대 또는 "우리 프로젝트에 적용 가능한지"에 대한 초기 의견이 있다

이 세 가지 중 하나라도 못 하겠으면, 아직 2단계가 끝나지 않은 것이다.

2단계에서 이해 안 될 때

원인은 보통 다음 중 하나다.

배경지식 부족 — 해당 기술/패턴을 아직 모른다 → 기초 자료를 먼저 읽고 돌아오기
글이 나쁘게 쓰여짐 — 구조가 엉망이거나 근거 없는 주장 → 같은 주제의 다른 글을 찾기
피곤함 — 진짜로 그냥 피곤한 것 → 내일 읽기

세 번째가 의외로 중요하다. 피곤한 상태에서 억지로 읽어봤자 남는 게 없는 것 같다.

나는 2단계로 읽으면서 옵시디언에 한 줄씩 메모한다. 이것만으로도 기억 유지율이 확 달라진다. (이게 생각보다 효과가 크다.)

지나고 보니, 예전에는 "다 읽었으니 됐겠지" 하고 넘어갔는데, 한 달 뒤에 뭘 읽었는지 하나도 기억 못 한 적이 몇 번 있었다. 그 뒤로 메모 습관이 생겼다.

대부분의 기술 아티클은 2단계면 충분하다. 트렌드 파악, 기술 비교, 아이디어 수집 목적이라면 여기서 멈춰도 된다.

2단계에서 AI 활용

좋은 사용법:

내가 먼저 읽고 나서 3줄 요약을 써 본 다음, AI에게도 요약을 시켜서 내 이해와 비교 — "내가 놓친 포인트가 있나?" 체크용
1단계에서 표시해둔 모르는 용어를 일괄 질문 — "이 글에 나온 eventual consistency, saga pattern, compensating transaction을 각각 2줄로 설명해줘"
아키텍처 다이어그램을 이해 못 했을 때, 다이어그램 캡처를 AI에게 보여주며 "이 그림에서 데이터 흐름을 설명해줘" 요청
영어 글에서 특정 문단이 해석이 안 될 때 해당 문단만 번역 요청 (전체 번역은 안 된다)

나쁜 사용법:

글을 안 읽고 AI에게 전체 요약 — 2단계를 건너뛴 것이다. 내 이해가 아니라 AI의 이해.
AI 요약을 그대로 노트에 복붙 — 내가 쓴 메모가 아니면 기억에 안 남는다.
"이 글의 장단점 분석해줘" — 비판적 사고를 AI에게 위임한 것이다. 자기 의견이 사라진다.

핵심 규칙: AI는 "읽은 후"에 쓴다. "읽기 전"이나 "읽기 대신"이 아니라.

3단계: 깊이 파고들기 (1~3시간)

목표: 글의 내용을 내 것으로 만든다. 직접 해볼 수 있고, 비판적으로 평가할 수 있는 수준.

솔직히 말하면 3단계까지 가는 글은 한 달에 몇 편 안 된다. 오히려 그래야 한다.

돌아보면, 내가 3단계까지 수행했던 글은 대부분 팀 아키텍처 결정이나 기술 도입 검토처럼 "직접 적용해야 하는" 상황에서였다.

이렇게 한다

코드를 직접 실행해 본다 — 복붙이 아니라, 왜 이렇게 짰는지 이해하며
저자와 동일한 문제를 내가 풀어본다 — 글을 보기 전에 내가 어떻게 접근했을지 생각
저자의 접근법과 내 접근법을 비교한다
- 저자가 나보다 나은 점은?
- 내가 다르게 했을 부분은?
- 저자가 놓친 것은?
가정을 도전한다
- "이건 트래픽이 적을 때만 되는 거 아닌가?"
- "이 아키텍처가 우리 규모에서도 동작하나?"
- "이 벤치마크가 공정한가?"
나만의 메모를 작성한다
- 핵심 배운 점
- 내 프로젝트에 적용할 수 있는 것
- 추가로 찾아볼 것
- 반대 의견 또는 한계점

4번이 특히 중요하다. 글에 적힌 내용을 그대로 받아들이는 게 아니라, "이게 정말 우리 상황에도 맞나?"를 따져보는 과정이다. 생각해보면, 좋은 기술 아티클일수록 특정 조건에서의 경험을 다루는 경우가 많은 것 같다. 그 조건이 내 상황과 다르면 결론도 달라질 수 있다.

3단계 후의 상태

글의 전체 구조를 기억에서 재구성할 수 있다
강점과 약점을 구체적으로 지적할 수 있다
이 기술/패턴을 내 프로젝트에 적용하거나 변형할 수 있다
이 주제에 대해 블로그 글을 쓰거나 발표할 수 있다

결국 3단계의 결과물은 "내가 이 주제에 대해 글을 쓸 수 있는가?"다. 쓸 수 있으면 진짜 이해한 것이고, 못 쓰겠으면 아직 부족한 것이다.

3단계는 모든 글에 할 필요 없다. 내 업무에 직접 적용할 기술, 깊이 이해해야 하는 아키텍처, 팀에 공유해야 하는 중요한 글에만 3단계를 수행한다.

3단계에서 AI 활용

좋은 사용법:

소크라테스식 질문 상대로 활용 — 내가 이해한 내용을 AI에게 설명하고, "내 이해가 맞아? 빠진 부분이 있어?"로 검증
반론 생성기로 활용 — "이 아키텍처의 약점이나 실패할 수 있는 시나리오를 5개 만들어줘" → 내가 못 본 각도를 보여준다
코드 실행 중 막힐 때 특정 에러나 개념만 질문 — "이 코드에서 CompletableFuture.thenCompose가 thenApply와 뭐가 다른 거야?"
"이 글의 저자가 간과한 점이 있다면?" — AI가 만능은 아니지만, 다른 시각을 제시할 때가 있다
내 정리 메모 초안을 쓴 후 AI에게 "빠진 포인트 있어?" 로 리뷰 요청
글에서 다룬 기술의 대안이나 경쟁 기술 을 물어봄 — "이 글에서는 Redis Streams를 추천하는데, 같은 문제를 Kafka나 RabbitMQ로 풀면 어떻게 달라?"

나쁜 사용법:

AI에게 "이 글의 핵심을 정리해서 블로그 글로 써줘" — 3단계의 의미가 완전히 사라진다. 내 것이 아닌 글이 된다.
코드를 직접 실행 안 하고 AI에게 "이 코드 실행하면 결과가 어떻게 나와?" — 직접 부딪혀야 배운다.
"가정을 도전한다" 단계를 AI에게 전부 위임 — 비판적 사고 근육이 퇴화한다.

3단계에서 AI의 역할은 "스파링 파트너"다. 내가 펀치를 던지고, AI가 받아치고, 그 과정에서 내 이해가 단련된다. AI가 대신 싸워주는 게 아니다.

기술 트렌드 조사에 적용하기

새로운 기술이나 분야를 조사해야 할 때, 예를 들어 "우리 서비스에 이벤트 소싱을 도입할까?" 같은 질문이 생겼을 때, 3단계 접근법을 이렇게 활용한다.

Step 1: 탐색

Google, Hacker News, dev.to, Medium 등에서 키워드 검색
3~5편의 최근 글을 찾는다
각 글에 1단계만 수행 — 분야의 감을 잡고, 각 글의 참고 링크를 모은다
잘 정리된 서베이/개관 글이 있으면 그것부터 읽는다

Step 2: 핵심 식별

여러 글에서 반복적으로 인용되는 글/저자를 찾는다 → 그 분야의 핵심 자료
핵심 저자/회사의 공식 블로그나 발표 자료를 찾는다
컨퍼런스 발표 (QCon, Strange Loop, KubeCon 등)에서 관련 토크를 찾는다

여러 글을 훑다 보면 패턴이 보인다. "아, 이 분야에서는 결국 Martin Fowler의 저 글이 기본이구나" 같은 감이 잡힌다. (이 감이 잡히는 순간이 조사의 터닝 포인트다.)

Step 3: 심화

핵심 자료 + 컨퍼런스 발표를 모아서 2단계까지 수행
모든 글이 공통적으로 인용하는데 내가 아직 안 읽은 자료가 있으면 추가
최종적으로 내 정리 문서 (기술 검토서, ADR 등)를 작성

여기서도 AI 활용의 원칙은 동일하다. 탐색 가속이나 패턴 발견 보조로는 쓰되, "이벤트 소싱 장단점 정리해줘"로 조사를 끝내는 건 안 된다. 남의 의견을 내 조사 결과로 착각하는 것이니까. 그리고 AI가 추천한 글 목록은 반드시 실제 존재하는지 확인해야 한다. AI는 존재하지 않는 글을 추천하는 경우가 잦다.

실전 팁

읽기 효율을 높이는 습관

RSS 리더나 뉴스레터로 글을 모아서 배치로 1단계 수행 — "읽을 것"과 "버릴 것"을 먼저 분류
"나중에 읽기(Read Later)" 도구(Pocket, Instapaper, 옵시디언 클리핑)를 활용하되, 쌓아만 두지 말고 주 1회 정리 시간 을 잡기
2단계 이상 읽은 글은 반드시 메모를 남긴다 — 읽었는데 기억 안 나면 안 읽은 거나 마찬가지
3단계를 한 글은 다른 사람에게 설명하거나 블로그에 쓴다 — 이게 진짜 내 것이 되는 과정

특히 마지막이 중요하다. 생각해보면, 읽기의 마지막 단계는 결국 "쓰기"라고 본다. 쓰면서 비로소 내가 뭘 이해했고 뭘 이해 못 했는지가 드러난다.

글을 쓰는 사람 입장에서

독자의 80%는 1단계에서 떠난다 — 제목, 소제목, 서론이 전부다
다이어그램 하나가 텍스트 열 줄보다 낫다
코드 예제는 핵심만 — 전체 코드는 GitHub 링크로
결론에서 "그래서 뭘 하라는 건데" 에 답해야 한다

이 글을 읽는 사람도, 쓰는 입장에서 생각해보면 좋겠다. 내 글의 1단계가 매력적인가? 소제목만 훑어도 뼈대가 보이는가? 이런 질문을 스스로에게 던지는 것만으로도 글의 질이 올라간다.

나가며

이 방법을 적용하면서 가장 크게 달라진 건, 읽는 양이 아니라 읽는 태도였다.

단계	시간	목표	결과	AI 역할
1단계	5분	읽을 가치 판단	다섯 가지 C에 답 가능	필터링 보조, 용어 사전
2단계	15~30분	핵심 내용 이해	3줄 요약 + 동료에게 설명 가능	읽은 후 이해 비교, 용어 설명
3단계	1~3시간	깊이 이해, 내 것으로	적용/비판/발표 가능	스파링 파트너, 반론 생성기

모든 글에 3단계를 할 필요 없다. 대부분은 1단계로 걸러지고, 가치 있는 글만 2단계, 정말 중요한 글만 3단계를 수행한다. 이 필터링 자체가 효율적 읽기의 핵심이다.

그리고 AI 활용의 핵심도 같은 맥락이다.

상황	AI 활용 (좋음)	AI 위임 (나쁨)
영어 글 읽기	모르는 문단만 번역	전체 번역으로 읽기 대체
용어 이해	특정 용어 설명 요청	글 전체를 요약해달라고 함
메모 작성	내 메모 쓴 후 누락 체크	AI 요약을 그대로 메모로 사용
비판적 사고	반론/약점 시나리오 요청	"이 글 장단점 정리해줘"
코드 이해	특정 함수/패턴 질문	"이 코드 전체 설명해줘"
트렌드 조사	검색 시작점 추천	AI 정리로 조사 완료 처리

결국 중요한 건 이거다. 기술 아티클을 "많이" 읽는 게 중요한 게 아니라, "제대로" 읽는 게 중요하다. 그리고 제대로 읽는다는 건, 단계별로 깊이를 조절하면서 내 시간을 효율적으로 쓰는 것이다.

그리고 어떤 단계에서든, AI에게 읽기를 맡기는 순간 그 단계는 수행하지 않은 것이다. 읽기의 주인은 항상 나여야 한다.

"The more that you read, the more things you will know. The more that you learn, the more places you'll go." 많이 읽을수록 많이 알게 되고, 많이 배울수록 더 많은 곳에 갈 수 있다.

-- Dr. Seuss

결국 3단계 접근법이 말하는 것도 이거다. 닥치는 대로가 아니라, 골라서 읽는 것.

원작: S. Keshav, "How to Read a Paper" (University of Waterloo) 기술 블로그/아티클 버전으로 각색 + AI 활용 가이드 추가

(픽션) 허공을 미는 사람들 - 에피소드 2, 허무한 성공 - 2

Tony Cho (https://flowkater.io) — Sun, 08 Feb 2026 11:00:00 GMT

이 작품에 등장하는 모든 인물, 이름, 집단, 사건은 허구이며 실존하는 것들을 기반으로 하지 않았습니다.

Author: flowkater

에피소드 2: 허무한 성공 - 2

[수요일, 오전 9:47] 박 팀장 - 부서장실에서

심호흡을 했다. 습관이다. 이 문을 열면 다른 사람이 되어야 한다. 석 달 동안 이 문을 몇 번이나 열었는지 모르겠다. 열 때마다 심호흡을 했다. 그래도 익숙해지지 않았다.

노크를 했다.

"들어오세요."

문을 열고 부서장실로 들어섰다. 부서장님이 책상에 앉아 모니터를 보고 계셨다. 나를 쳐다보지는 않는다. 평소 습관이다. 창 너머로 판교의 건물들이 줄지어 있었다. 하늘은 흐렸다. 여름도 아니고 딱히 더운 날씨도 아닌데 에어컨 바람이 천장에서 내려오고 있었다.

"부서장님, 찾으셨습니까."

"아, 팀장님. 앉아요."

자리에 앉은 적은 거의 없었다. 이상하다. 평소에는 서서 보고하고, 서서 지시받고, 서서 나간다. 그게 패턴이었다.

어색하게 의자를 잡아당겼고 엉거주춤하게 의자 끝에 걸터 앉았다. 부서장님이 모니터에서 눈을 떼고 안경 너머로 나를 쳐다봤다. 최근 기억에 없는 표정이다. 활짝 웃는 표정이다.

"팀장님, 수고했어요."

괜히 안심이 된다. 프로젝트 시작하고 처음 듣는 말이다.

"감사합니다."

"프로젝트 잘 마무리했더라고요. 어제 최종 릴리즈 확인했어요."

"예, 어제 저녁 일곱 시에 완료했습니다."

"팀원들도 고생 많았고."

부서장님이 책상 위 서류를 집어 들었다. 뭔가 적힌 종이였는데 멀어서 안 보였다. 손가락으로 종이 모서리를 톡톡 두드렸다.

"대행업체에서 연락 왔어요."

의자 팔걸이를 잡았다. 대행업체. 우리 소프트웨어를 팔아주는 곳. 주말에 같이 일한 건 대행업체가 아닌 외주 검수 업체였다. 현재 이 프로젝트는 거대한 시장 조사를 바탕으로 판매 대행업체의 주도 하에 진행되고 있었다. 그쪽 반응이 어떤지가 중요했다.

"시장 반응이 좋을 것 같대요."

부서장님은 미소를 띠면서 말했다. 분명 그들의 평가를 전달하는 건데, 나의 동의를 얻는 듯한 말투였다.

"정말요?"

내가 반문했다.

"응. 대박 날 거라고. 기능도 잘 갖춰져 있고, UI도 깔끔하다고."

손바닥에 땀이 났다. 다행이었다. 그래도 헛된 시간은 아니라고 생각이 들었다.

나는 조금 들뜬 목소리로 답했다.

"감사합니다. 팀원들한테도 전하겠습니다."

"그래요, 전해줘요. 다들 고생했다고."

부서장님이 서류를 내려놓고 모니터를 다시 보며 마우스를 움직였다. 클릭. 또 클릭. 화면이 바뀌는 소리가 났다.

이어서 무언갈 말하길 기다렸으나 부서장님은 더이상 아무런 말씀이 없으셨다. 그렇다고 바로 나가라는 눈치도 아니다. 그저 화면을 보고 딴청을 피우는 듯한 느낌이 들었다.

사실 지금 부서장실에 온 건 토요일에 말씀하신 건 때문이다. 팀원들은 아무말도 없었지만 매일 같이 야근, 새벽 퇴근, 주말 출근에 불만이 끓어오를 대로 끓어오른 상태였다. 사실 토요일에만 무언갈 챙겨주겠다고 한 건 아니었다. 프로젝트 시작 시기에 부서장님은 팀원들을 3개월을 1년처럼 보내게 만들기만 한다면 끝나자마자 보상을 챙겨주겠다고도 했다.

그 뒤에 프로젝트로 정신이 없었지만 토요일 말씀때문에 나도, 팀원들도 기대가 생겼다. 끝나면 넉넉하게 챙겨주겠다고. 고생한 만큼 보답하겠다고. 구체적으로 뭘 해주겠다는 말은 없었다. 하지만 다들 알아서 해석했다. 보너스. 유급 휴가. 밀린 연차는 말할 것도 없고. 석 달 고생했으니까 그 정도는 당연하다고. 그 말 믿고 팀원들한테 전했다. 그 말 믿고 다들 일요일에 나왔다. 아니, 3개월을 그렇게 일했다.

부서장님이 모니터만 보고 계셨다. 계속 아무 말이 없었다.

에어컨 소리가 들렸다. 시계 초침 소리가 들렸다. 순간 공기의 흐름이 멈춘 것 같았다.

"저기, 부서장님."

내가 정신을 차리고 먼저 입을 열었다. 목소리가 살짝 매였다.

"예?"

부서장님이 모니터에서 눈을 떼지 않고 대답했다.

"저번에 말씀하신… 팀원들한테 챙겨주신다고 한 건요."

부서장님 마우스 위에 올려놓은 손이 멈췄다. 검지가 살짝 들렸다가 내려왔다.

침묵. 에어컨 바람이 서류 모서리를 미세하게 흔들었다.

"챙겨준다는 거요?"

부서장님이 나를 쳐다봤다. 안경 너머로. 아까와 다른 눈이었다.

"예. 토요일에 넉넉하게 보상 해주신다고 하셨잖아요. 구체적으로 어떤 형태로 될지… 금액이라든가, 유급 휴가 기간이라든가요."

"아."

부서장님이 등을 의자에 기댔다. 두 손을 깍지 끼고 배 위에 올렸다. 의자가 삐걱거렸다.

"성과급 말하는 거예요?"

성과급. 처음 듣는 단어였다.

"예… 그런 것도 포함해서요."

부서장님은 무표정하게 대답했다.

"일단 판매 성과가 나와야 책정할 수 있어요."

"…네?"

잠깐. 아니, 제발.

"지금은 개발만 끝난 거잖아요. 실제로 팔려야 성과가 나오는 거지."

사실 그게 무슨 보답이냐 성과급이냐는 중요하지 않았다. 내가 매일매일 팀원들에게 정말 고생했고 조금만 버티면 된다라는 공허한 외침들이 더이상 공허하지 않기를 바랄 뿐이었다. 가슴이 급격히 답답해졌다.

"그럼… 언제쯤…"

말 끝을 흐렸지만 목소리가 매이지는 않았다.

"글쎄요. 대행업체 쪽 일정이라서. 빠르면 두세 달? 늦으면 더 걸릴 수도 있고."

두세 달. 늦으면 더.

창밖으로 저 멀리 구름이 펼쳐져 있다. 구름이 움직이지 않으니 하늘이 멈춘 것 같다. 바람이 없는 날이었다.

"팀원들이 기대하고 있어서요. 석 달 동안 정말 고생했고…"

"나도 알아요."

부서장님이 내 말을 끊었다.

"근데 팀장님, 성과가 있어야 성과급 아니에요?"

당연히 맞는 말이다. 하지만, 난 한번도, 아니 적어도 절대로 "성과급"을 기대한 적이 없다. 그리고 이 프로젝트는 애초에 납품하고 넘기는 거였다. 고객이 누군지 모르는 프로젝트였기 때문에 정말 끝내는데 온 힘을 다했다. 그리고 부서장님도 끝나기만 하면 이라는 말을 정말 자주했다.

뭔가 잘못됐다. 넉넉하게 챙겨주겠다고 하셨을 때, 나는 당연히 약간의 보상이라고 생각했다. 차라리 일도 끝났겠다, 밀린 연차에 붙일 만한 유급 휴가도 괜찮다. 꼭 보상이 돈이 아니어도 된다. 석 달 고생한 거에 대한 보상. 팀원들도 그렇게 생각했다. 적어도 나는 그거면 충분하다고 생각했다. 부서장님이 꺼낸 건 성과급이었다. 같은 말 같지만 다른 말이었다. 이미 끝난 석 달에 대한 대가가, 아직 일어나지 않은 판매 실적에 달려 있었다.

입을 열었다. 아무 말도 안 나왔다.

"…예. 알겠습니다."

자동이었다. 뭘 알겠다는 건지 모르겠다.

"그리고 연차도요."

나는 안 좋은 예감에 고개를 들지 않았다.

"일단 쓰지 말라고 해요."

"…예?"

"대행업체에서 수정 요청이 들어올 수 있어요. 판매하려면 몇 가지 손봐야 할 것 같다고 하더라고요. 아직 정리 안 됐는데, 이번 주 내로 목록 올 거예요."

예상은 했다. 그래도 끝났다고 생각했는데 더 남았다고 하니까 가슴이 옥죄어온다.

"크게 어려운 건 아닐 거예요. 그래도 혹시 모르니까 팀원들 대기시켜 놔요."

크게 어렵지 않은 기능들. 부서장님은 항상 그 말로 자신의 기획 사항을 관철시켰다. 그 말을 석 달 동안 몇 번 들었는지 모른다. 항상 어려웠다.

"그럼 연차는…"

"수정 작업 끝나고 쓰면 되죠. 길어야 일주일 정도 걸릴 거예요."

일주일. 크게 어렵지 않은 기능들은 보통 하루에서 3일의 기한이면 충분했지만, 어떤건 3주에서 한달도 걸렸다.

당분간은 휴가를 쓰지 못한다. 추가 휴가가 아니다. 원래 있는 연차다. 석 달 동안 한 번도 못 쓴.

"알겠습니다."

또 그 말이 나왔다. 알겠다. 알겠다.

"팀원들한테 잘 전해줘요. 조금만 기다리라고."

석 달 동안 지겹게 했던 말이다. 조금만 더 하면 된다. 조금만 더 버티면 된다. 사실 원래 일정대로라면 기존의 우리가 가지고 있던 솔루션에서 약간의 기능만 더해서 두달 전에 끝났어야 했다. 하지만 부서장님과 판매 대행업체에서는 완전히 새로운 요구사항을 합의했고, 그건 사실 우리가 가지고 있는 솔루션과는 아예 다른 방향의 제품이었다.

대행업체 미팅때 부서장님은 얘기했다.

"금방 됩니다."

그 금방이 석 달이 됐고, 석 달이 또 얼마가 될지 모른다.

"예."

일어났다. 다리에 힘이 빠져 있었다.

"아, 팀장님."

문을 열려고 했는데 부서장님이 불렀다.

"예."

"오늘은 그래도 일찍 보내줘요. 칼퇴시키고. 내일부터 대기니까."

칼퇴. 베푸는 것처럼 들렸다.

"예. 알겠습니다."

문을 열고 나왔다. 문이 닫히고 복도에 혼자 섰다. 형광등이 여전히 깜빡이고 있었다.

팀원들한테 뭐라고 말하지.

보너스가 아니라 성과급이었대. 판매 성과 나와야 한대. 언제인지 모른대. 유급 휴가 얘긴 없었대. 밀린 연차도 못 쓴대. 수정 작업 있을 수 있으니까 대기하래. 그래도 오늘은 칼퇴해도 된대.

웃음이 나올 뻔했다. 안 나왔다.

엘리베이터 앞에 섰는데 버튼을 안 눌렀다. 그냥 서 있었다. 스테인리스 문에 얼굴이 비쳤는데 누구 얼굴인지 모르겠다. 문 위에 긁힌 자국이 여러 개 있었다. 누가 짐을 부딪힌 자국인지, 사람이 긁은 건지.

담배가 피우고 싶었다. 오 년 전에 끊었는데. 요즘 자꾸 그 생각이 났다. 입술이 마른 느낌. 필터를 무는 감촉. 그런 게 떠올랐다.

일 층 버튼을 눌렀다. 밖으로.

담배를 피우러 가는 게 아니다. 그냥 거기 서 있으려고.

흡연실은 비어 있었다. 건물 옆 구석. 재떨이 하나. 꽁초가 수북했다. 누군가 아침부터 피운 모양이다. 필터에 립스틱이 묻어 있는 것도 있었다.

건물 벽에 기댔다. 차가웠다. 하늘이 보였다. 흐린 하늘.

지난 토요일에는 장모님 생신이었다. 나는 식사를 제때하지 못하고 계속 부서장님의 전화를 받고, 팀원들에게 주말 출근을 독려했다. 밥을 뜨다 말다 전화하다가 결국 해가 저물어 마무리하고 거실에 가니 아이들이 케이크에 초를 꽂고 있었다. 하루종일 불편한 마음과 처가 식구들에게도 미안한 감정이 컸지만 그래도 괜찮았다. 프로젝트 잘 끝나면 넉넉하게 챙겨줄게. 고생한 만큼 보답하겠다고 했으니까.

사실 내가 느끼는 안도감은 내 개인적인 보상이 아니었다. 그건 애초에 바라지 않았다. 나는 팀장이다. 다만, 보상같은 거 없어도 그저 시키는대로 열심히 하고 있는 팀원들에게 뭐라도 할 말이 생겨서 안도했다.

그 말을 팀원들한테 전했다. 일요일에 나와달라고 하면서. 마무리만 하면 된다고. 넉넉하게 챙겨준다고.

가슴이 답답하다. 설레면서 다녔던 순간도 있었던 곳이었는데 지금은 건물 곳곳 구석구석 아니 판교라는 지역 전체가 나를 짓누르는 느낌이 든다. 숨을 크게 들이쉬고 내쉰다.

바람이 불지 않았다. 재떨이 주변으로 담배 냄새가 가시지 않았다. 밖인데도 공기가 움직이지 않는 것 같았다.

핸드폰을 꺼내서 시간을 보았다. 10시 3분. 아마 팀원들이 기다리고 있을 것이다. 부서장실에 올라간 걸 알고 있으니 돌아오면 뭔가 해줄거라고 기대하고 있지 않을까.

핸드폰을 주머니에 넣었다.

일 분만 더.

벽에서 등을 떼지 않았다. 재떨이 위로 연기처럼 보이는 것이 흔들렸다. 착각이었다. 아무도 안 피우고 있었다.

일 분이 지났다. 또 일 분이 지났다. 바람은 여전히 불지 않았다.

올라가야 한다.

벽에서 등을 떼고 건물 안으로 들어갔다. 엘리베이터 버튼을 눌렀다. 사무실 층. 문이 닫혔다.

엘리베이터 안에서 심호흡을 했다. 부서장실 앞에서 하는 것과 같은 심호흡이었다. 이 문이 열리면 다른 사람이 되어야 한다. 이번에는 부서장이 아니라 팀원들 앞에서.

문이 열렸다.

복도를 걸었다. 사무실 문이 보였다. 유리 너머로 팀원들이 앉아 있는 게 보였다. 김 대리가 모니터를 보고, 하 과장이 커피를 마시고, 정 대리가 뭔가를 적고 있었다.

평범한 아침이었다. 평범하게 만들어야 했다.

문을 열었다. 표정을 만들었는데 어떤 표정을 짓고 있는지는 모르겠다.

좋은 소식을 먼저 말하자. 대행업체 반응 좋다고. 부서장님도 잘했다고 하셨다고. 그 다음에. 그 다음에는.

자리를 향해 걸었다.

[수요일, 오전 10:15] 김 대리 - 사무실에서

팀장님이 걸어오고 있었다.

사무실 유리문 너머로 복도에서 이쪽으로 오는 모습이 보였다. 걸음이 느렸다. 평소 팀장님은 걸음이 빠른 편이다. 항상 뭔가 쫓기듯이 걸었다. 지금은 달랐다. 발을 끌듯이 걸었다.

문이 열렸다.

팀장님이 안으로 들어와서 나와 눈이 마주쳤다. 아니, 마주친 것 같았다. 시선이 나를 통과한 느낌이었다. 눈이 멍했다. 부서장실에서 내려오신 것 같은데, 뭔가 맞은 사람 같은 얼굴이었다.

팀장님이 내 자리 앞을 지나가는데 희미하게 담배 냄새가 났다. 이상했다. 팀장님은 담배를 안 피우신다. 끊은 지 오래됐다고 들었는데 어디서 묻어온 건가. 신경이 쓰였다가, 쓰이지 않았다.

자리에 앉지 않고 우리 쪽을 둘러봤다.

"다들 잠깐."

이 과장이 천장 보던 시선을 내렸다. 하 과장이 커피 잔을 내려놓았다. 정 대리가 마우스에서 손을 떼고 의자를 돌렸다. 윤 사원도 고개를 들었다.

오전 열 시. 부서장실에 갔다 온 직후. "다들 잠깐."

이 패턴을 안다. 전에도 그랬다. 이 말이 나오면 좋은 소식인 적이 없었다. 지난 석 달 동안 한 번도.

팀장님이 입을 열었다. 표정을 만들고 있었다. 어떤 표정인지는 읽기 어려웠다. 웃는 건지 아닌 건지.

"부서장님께서 잘하셨다고 하셨어. 대행업체 반응도 좋대."

정 대리 얼굴이 밝아지고 하 과장이 몸을 앞으로 기울였다.

"진짜요? 좋은 소식이네요."

정 대리가 말했다. 2년차니까. 아직 그럴 수 있다.

하 과장이 바로 물었다.

"그럼 이제 챙겨주신다는 거 나오는 거예요?"

토요일에 팀장님이 단톡방에 올렸다. "부서장님 말씀으로는 프로젝트 끝나면 넉넉하게 챙겨주신다고 합니다." 다들 그걸 보고 각자 해석했다. 보너스. 유급 휴가. 밀린 연차. 넉넉하게라는 말이 주는 여백을 기대로 채웠다.

나는 그 메시지를 읽고 아무 반응을 안 달았다. 넉넉하게 챙겨준다. 구체적으로 뭘? 금액? 기간? 아무것도 안 적혀 있었다. 챙겨준다는 말은 약속이 아니다. 그냥 좋은 말이다.

팀장님이 잠깐 입을 다물었다.

사무실 에어컨이 돌아가고 있었다. 천장에서 바람이 내려왔다. 누군가 책상 위에 올려놓은 종이가 미세하게 떨렸다.

"챙겨준다는 게… 성과급이었대."

침묵.

"판매 성과가 나와야 책정할 수 있다고. 지금은 개발만 끝난 거라서."

하 과장의 손이 커피 잔 손잡이 위에서 멈췄다.

"…언제요?"

"대행업체 일정이라서. 빠르면 두세 달, 늦으면 더 걸릴 수도 있다고."

그럼 그렇지.

충격은 없었다. 정확히 말하면 놀라지 않았다. 토요일에 그 메시지를 보고 반신반의했던 나는, 반 쪽이 맞았을 뿐이었다. 성과급. 그 단어가 나오는 순간 알았다. 이건 보너스가 아니다. 성과가 나와야 나오는 돈이다. 전 회사도 그랬다. 성과급은 실적 연동이다. 우리 프로젝트는 아직 한 건도 안 팔렸다.

나는 다른 사람들을 봤다.

정 대리의 밝았던 얼굴이 서서히 굳어갔다. 의자 팔걸이를 잡고 있는 손에 힘이 들어가 있었다. 윤 사원은 시선을 바닥으로 내렸는데 무슨 표정을 지어야 할지 모르는 것 같았다. 이 과장은 아무 표정이 없었다. 원래 없다. "뭐 그렇지." 그런 얼굴이었다.

하 과장이 입을 열었다.

"토요일에요."

하 과장 목소리가 낮았다. 평소 하 과장은 목소리가 크다. 농담 할 때도, 불만 얘기할 때도. 지금은 낮았다.

"토요일에 부서장님이 직접 넉넉하게 챙겨주신다고 하셨잖아요."

팀장님이 입술을 한 번 깨물었다. 볼펜을 집어 들었다 내려놓았다. 소리가 나지 않았다.

"저한테도 일요일에 나오라고 전화하셨잖아요."

하 과장이 말했다. 토요일 저녁이었다. 팀장님이 전화해서 나와달라고 했다. 하 과장은 거절했다. 한 달 전부터 잡아둔 일정이 있었다. 두 번째 전화가 왔다는 것도 안다. 하 과장은 안 나왔다.

"그랬는데 언제인지 모른다고요?"

팀장님이 대답하지 않았다.

팀장님한테는 요즘 이상한 습관이 있다. 상대방의 말이 안 통하면 가끔 그 말을 듣고도 대답하지 않는다. 대답할 수 없는 건지, 안 하는 건지 모르겠다.

복도 쪽에서 다른 팀 사람이 지나가는 발소리가 들렸다. 멀어졌다. 사라졌다.

하 과장이 뭔가 더 말하려는 것 같았다. 입을 열었다. 다시 닫았다. 한 번 더 열었다.

"…됐어요."

그 한마디였다. 하 과장이 커피 잔을 들었다가 마시지 않고 다시 내려놓았다. 모니터를 봤는데 화면에 뭐가 떠 있는지는 안 보였다.

믿고 싶은 대로 믿었다. 다들. 넉넉하게 챙겨준다는 말을 듣고 각자의 기대를 담았다. 보너스. 유급 휴가. 쉴 수 있다는 희망. 그게 성과급이라는 단어 하나로 바뀌었다.

나는 처음부터 회의적이었다. 사실 크게 중요하지 않다. 보너스가 나온다고 해도 석 달 동안 남의 코드를 복사 붙여넣기 하면서 느꼈던 허전함까지 채워지지는 않는다.

팀장님이 한 가지 더 말했다.

"대행업체에서 수정 요청이 올 수 있대. 아직 확정은 아닌데, 이번 주 내로 목록이 온다고."

하 과장이 코웃음을 쳤다. 소리가 들렸다. 짧았다.

"그래서 일단 연차는 수정 작업 끝나고 쓰라고 하셨어."

연차. 밀린 연차다. 석 달 동안 한 번도 못 쓴. 추가 휴가가 아니다. 원래 있는 연차. 그것조차 대기.

이 과장이 고개를 살짝 끄덕였다. 뭐 그렇지. 놀라지도, 분노하지도 않는 얼굴. 더 이상 기대할 것도 없다는 표정이었다.

윤 사원은 눈치만 보며 주변을 슬쩍 둘러보다가 시선을 내렸다. 6개월차. 이런 상황에서 뭘 해야 하는지 모르는 게 당연하다.

정 대리가 조심스럽게 물었다.

"그럼… 수정 기간이 어느 정도예요?"

"일주일 정도래."

일주일. 그 일주일이 두 주가 되고, 한 달이 되는 걸 석 달 동안 봤다. 팀장님도 알고 있을 것이다.

팀장님이 마지막으로 말했다.

"그래도 오늘은 부서장님이 칼퇴하라고 하셨어. 일찍 가."

칼퇴. 석 달 고생한 대가가 칼퇴 하루.

사무실 창 너머로 판교의 건물들이 보였다. 흐린 하늘 아래 비슷비슷한 건물들이 줄지어 서 있었다. 어디서든 비슷한 일이 벌어지고 있을 것 같았다.

[수요일, 오후 6:03] 김 대리 - 사무실에서

여섯 시가 됐다.

팀장님이 말했다. "오늘은 일찍 가." 퇴근하라는 게 아니라 허락하는 것 같은 톤이었다. 부서장님이 시켰다는 말을 굳이 붙인 것도 그렇다. 우리가 일찍 가는 게 아니라, 일찍 보내주는 것이다.

하 과장이 제일 먼저 일어나서 가방을 챙기고 컴퓨터를 껐다. 인사를 안 했다. 아무한테도. 의자를 밀어 넣지도 않고 빠르게 사무실 문 너머로 사라졌다.

이 과장이 조용히 일어나 가방을 들고 "수고하세요" 하고 나갔다. 목소리에 힘이 없었다.

정 대리가 일어나면서 말했다.

"팀장님, 수고하셨습니다."

밝은 목소리였다. 억지는 아닌 것 같았다.

윤 사원이 뒤따라 일어났다.

"수고하셨습니다."

기계적이었다. 말투가 아니라 타이밍이. 정 대리가 일어나서 인사하니까 따라 한 거다. 신입이니까.

사무실이 비었다. 나와 팀장님만 남았다.

팀장님이 모니터를 보고 있었다. 화면에 뭐가 떠 있는지는 안 보였다. 모니터 불빛이 얼굴에 비쳤다. 형광등 아래 얼굴이 더 피곤해 보였다. 눈 밑에 그늘이 졌다.

나도 가방을 챙겨야 했다. 컴퓨터를 끄고, 일어나서, 인사하고 나가면 된다. 간단한 동작인데 손이 움직이지 않았다. 뭔가 말해야 할 것 같았다. 수고하셨습니다가 아닌, 다른 말. 팀장님도 힘들었을 거라는 말. 하지만 그런 말을 어떻게 꺼내는지 몰랐다.

팀장님이 이쪽을 봤다.

입을 열었다. 뭔가 말하려는 것 같았다. 입술이 움직이다 멈췄다.

나는 기다렸다.

팀장님이 시선을 내렸다. 책상 위를 봤다. 손가락으로 마우스 옆을 한 번 두드렸다. 소리가 나지 않았다. 다시 나를 봤다.

"…내일 보자."

그게 전부였다.

"예. 내일 뵙겠습니다."

컴퓨터를 끄고 가방을 챙겨서 일어났다.

형광등이 켜져 있었다. 여섯 개 책상에 아무도 없는데 불만 환했다. 모니터들은 꺼져 있고 팀장님 모니터만 켜져 있었다. 빈 사무실에 형광등 소리가 미세하게 울렸다. 지직, 하는 소리. 석 달 동안 매일 들었는데 처음 듣는 것 같았다.

문을 열고 나갔다. 뒤를 돌아보지 않았다.

[수요일, 오후 7:08] 김 대리 - 퇴근길

지하철에 앉았다.

평소보다 일찍 나온 건 맞는데 이상했다. 석 달 동안 매일 자정이나 늦을 때는 새벽에 퇴근했다. 이른 날이 열 시였다. 늦은 날은 새벽 3시도 넘었다. 그게 일상이었다. 일곱 시에 지하철을 타니 어색했다. 간만에 퇴근 시간이라 북적인다. 지난 3개월 동안 외딴섬에서 일한다는 느낌이었는데, 갑자기 직장인이 된 것 같다. 어색했다. 새벽 퇴근 때는 그래도 법인 카드로 택시를 많이 탔는데 아이러니하게도 퇴근 길은 새벽이 더 편했다. 출입문 가까이 사람들 틈에 몸을 기대고 간다.

창밖으로 어두운 터널이 지나갔다. 유리에 내 얼굴이 비쳤다. 눈 밑에 그늘이 있었다. 팀장님 얼굴에서 봤던 것과 비슷했다.

핸드폰을 꺼내서 GitHub 앱을 열었다. 개인 계정. 잔디가 텅텅 비어 있고 하얀 칸들이 줄지어 있었다. 마지막 커밋이 아홉 달 전이었다. 입사하고 한 달쯤 됐을 때 사이드 프로젝트에 올린 게 마지막이다. 그 이후로 한 번도.

예전에는 퇴근하고 코드를 짰다. 새로운 기술을 써보고, 블로그에 글을 쓰고, 오픈소스에 PR을 올렸다. 전 회사 때다. 그때는 퇴근이 일곱 시였고, 집에 가면 에너지가 남아 있었다. 지금은 퇴근하면 침대에 눕는다. 유튜브를 틀어놓고 멍하니 본다. 뭘 봤는지 기억도 안 난다. 그러다 잠든다.

지하철이 역에 멈춰서 사람들이 내리고 탔다. 문이 닫히고 다시 움직였다.

이직해야 하나. 생각은 계속 한다. 1년도 안 됐다. 열 달. 이력서에 열 달짜리 경력은 좋지 않다. 최소 1년은 채워야 한다. 아니, 3년은 되어야 한다고, 그게 상식이라고 한다. 근데 지난 3개월은 거의 3년 일한 것 같은데. 또 그 시간이 반복된다.

수정 대기. 대행업체 요청 대응. 복사 붙여넣기. 변수명 바꾸기.

이런 거였나.

핸드폰 화면을 껐다. 하얀 잔디밭이 사라졌다. 검은 화면에 다시 내 얼굴이 비쳤다.

지하철이 내릴 역에 가까워져서 일어나 문 앞에 섰다.

석 달 동안 매일 야근하고, 주말에 출근하고, 밤새 남의 코드를 고쳤다. 끝났다고 했다. 대행업체 반응이 좋다고 했다. 부서장님이 잘했다고 했다.

대가가 뭔지 물었더니 성과급이라고 했다. 언제 나오냐고 물었더니 모른다고 했다. 쉴 수 있냐고 물었더니 대기하라고 했다.

문이 열렸다. 내렸다.

역에서 원룸까지 오 분. 편의점을 지나고, 골목을 꺾고, 계단을 올랐다. 현관문을 열었는데 어두웠다. 불을 켜니 좁은 방이었다. 침대, 책상, 옷걸이. 그게 전부인 공간. 책상 위에 개인 노트북이 닫힌 채 먼지가 쌓여 있었다. 입사하고 얼마 안 됐을 때 사이드 프로젝트 하겠다고 가져다 놓은 건데, 한 번도 열지 못했다.

신발을 벗고 침대에 앉아 가방을 내려놓았다.

내일도 출근해야 한다. 대기하라고 했다. 수정 요청이 올 수 있다고. 성과급은 언제인지 모른다고. 석 달 고생한 대가가 그거다.

창밖으로 가로등 불빛이 들어왔다. 주황색이었다. 원룸 창문은 작았다. 불빛도 적었다.

시간이 8시 밖에 되지 않았지만 씻지도 않고 다시 불을 끄고 침대에 누웠다. 불을 끄니 천장이 보이지 않았다. 눈을 감아도 열어도 같은 어둠이었다. 화가 나거나 슬프면 그래도 뭔가 느끼는 건데, 아무것도 느껴지지 않았다.

내일은 온다. 준비 같은 건 상관없이.

(Continue..)

Claude Code에 날개를 달아줘라! - Superpowers 소개

Tony Cho (https://flowkater.io) — Sun, 08 Feb 2026 01:00:00 GMT

들어가며

Red Bull gives you wiiings! 레드불, 날개를 펼쳐줘요! -- 레드불 광고

완전히 처음에 아이디어를 테스트해보거나 바이브 코딩을 잠깐 '우와'하고 쓰고 말 것이 아니라면, 꽤 많은 경우 context를 구체화하고 정확한 프롬프트를 전달하고, Spec 문서를 먼저 작성하는 스펙 주도 개발 등 여러 방법을 사용한다.

그런데 어떤 방식으로 정의하고 전달해도, 자기가 마음대로 판단하고 의도하지 않은 방향으로 작업이 진행되는 경우가 잦다. 특히 프로젝트가 점점 복잡해지고 커지면서 더 그렇다. 그래서 내가 도입한 커맨드 하나는 interview 커맨드인데, 프론트매터 설명은 대략 이렇다.

---
description: >
  프로젝트 요구사항이 불분명할 때, Claude가 직접 질문을 통해
  세부 정책, 구현 방법, 엣지 케이스를 명확히 하는 인터뷰 커맨드.
  "니가 판단하지 말고, 애매한 게 명확해질 때까지 나한테 계속 질문해라."
---

요약하면, "니가 판단하지 말고, 애매한 게 명확해질 때까지 나한테 계속 질문해라." 정도이다. 그러면 자기 마음대로 판단하지 않고 AskUserQuestions를 이용해서 세부 정책이나 현재 구현 방법 또는 요구사항에 대해서 명확하게 나를 대상으로 인터뷰가 진행된다. 특히 우리가 기획 내용이나 요구사항을 전달했을 때, "언어"라는 본질을 흐리는 표상의 원죄로 아무리 명확히 작성해도 AI는 잘못 이해한다. (사람도 마찬가지) 그리고 사실 내가 요구사항을 던지면서도 세부 정책은 생각하지 않고 막 던지는 경우도 많고.

그래서 Codex나 Claude Code에서 plan mode를 키고 인터뷰 커맨드를 실행하면 굉장히 구체화된 요구사항과 구현 계획이 세워지게 된다. 처음 기능을 구현할 때도, 버그를 고칠 때도 여러모로 전부 쓸모가 있다.

그리고 내 이전 글 15년차 CTO가 바이브 코딩하는 법에서 얘기한 TDD Planning을 마치고 작업을 들어가면, 아주 구체적이고 단계별로 나뉘어진 계획을 따르게 된다.

하지만 작업을 병렬적으로 하다 보면 이 커맨드 실행을 까먹을 때도 있고, TDD Planning 특성상 언어나 프레임워크마다 사용 포맷이 좀 다르다 보니 그때마다 맞춤형 스킬을 세팅하는 게 번거로워서 클라이언트에서는 스킵되는 경우가 많았다. 인터뷰 또한 구체적으로 물어보는 건 좋으나, 또 어느 정도는 알잘딱이 되었으면 했고.. (사람 마음이란..)

그럼에도 불구하고 잘 사용하던 와중에, 내가 직접 만들고 사용하고 있던 모든 커맨드와 스킬을 통합하고 로버트 치알디니의 설득의 심리학을 기반으로 LLM에 적용한 스킬 프레임워크를 발견했다. 이름 그대로 우리 코드 에이전트(Claude Code, Codex 등)에게 슈퍼파워를 달아주는 프레임워크, Superpowers다.

치알디니 본인이 참여한 연구에서 이 원칙이 LLM에도 먹힌다는 게 실제로 증명됐다. Superpowers는 치알디니의 6가지 설득 원칙 중 세 가지를 핵심적으로 적용한다.

설득의 심리학 3가지 원칙 적용

권위의 원칙: 스킬 파일에 해당 스킬이 필수임을 명시하여, Claude(또는 Codex)가 반드시 따라야 한다고 인식하게 한다.
일관성의 원칙: Claude(또는 Codex)에게 특정 스킬을 따르겠다고 선언하게 만들어, 선언한 내용을 지키도록 유도한다.
사회적 증거: 다른 스킬들도 모두 이 방식을 따른다고 알려주어, Claude(또는 Codex)가 이를 표준으로 인식하게 한다.

Claude Code에서는 설치도 간단하다. 마켓플레이스에서 플러그인을 바로 받아주면 된다. 난 간단한 작업이나 빠르게 치는 작업은 Claude Code, 프로덕션 레벨은 보통 Codex를 많이 쓰는데, Superpowers는 둘 다에서 아주 유용하게 사용된다.

특히 내가 적극 활용하는 인터뷰나 TDD 워크플로우 모두를 반영하면서도, 코드 리뷰나 검증 등의 추가 보완 스킬을 모두 포함한 프레임워크이니, 여기서 소개를 해보려고 한다.

설치 및 기본 사용법

설치

Superpowers는 Claude Code 2.0.13 이상에서 동작한다. 설치는 두 줄이면 끝난다.

# 1. 마켓플레이스 등록
/plugin marketplace add obra/superpowers-marketplace

# 2. Superpowers 설치
/plugin install superpowers@superpowers-marketplace

설치 후에도 작동하지 않는다면 Claude Code를 껐다가 다시 켜면 된다. 설치가 완료되면 **"I have Superpowers"**라는 메시지가 표시되며, Brainstorm, Write Plan, Execute Plan 등의 스킬을 사용할 수 있게 된다.

참고로 Claude Code뿐만 아니라 Codex나 OpenCode에서도 사용 가능하다. (GitHub 스타 4.7만 개를 받은 오픈소스 프로젝트(MIT License)이니 안심하고 써도 된다.)

핵심 변화: 바로 코딩하지 않는다

Superpowers를 설치하고 나면 가장 먼저 체감되는 변화가 있다. Claude가 절대로 바로 코딩하지 않는다. 일반 Claude Code에서 "만들어 줘"라고 하면 바로 코드부터 치기 시작하는데, Superpowers가 설치된 Claude는 무조건 질문부터 시작한다.

이게 핵심이다. 내가 만들었던 interview 커맨드가 자동으로 내장된 셈이다. 그것도 명령어 없이.

질문 -> 설계 -> 계획 -> TDD -> 서브 에이전트 위임 -> 코드 리뷰 -> 완성.

이 흐름이 명령어 없이 자동으로 시작된다는 점이 Superpowers의 가장 큰 장점이다.

개발 워크플로우: 7단계

Superpowers의 워크플로우는 7단계로 구성된다. 전체 흐름을 먼저 보자.

flowchart TD
    A["1. Brainstorming\n질문 & 설계 문서 작성"] --> B["2. Git Worktrees\n독립 워크트리 생성"]
    B --> C["3. Writing Plan\n태스크 분해 & 승인"]
    C --> D["4. Development\n서브 에이전트 병렬 개발"]
    D --> E["5. Testing (TDD)\nRED -> GREEN -> REFACTOR"]
    E --> F["6. Verification\n수정 사항 검증"]
    F --> G["7. Code Review & Finishing\n리뷰 & PR 생성"]
    G -->|"다음 태스크"| D
    E -->|"테스트 실패"| H["Systematic Debugging\n4단계 근본 원인 분석"]
    H --> E

1단계: 브레인스토밍

프로젝트를 요청하면, Claude는 바로 코딩하지 않고 질문부터 시작한다.

"무엇을 어떻게 만들 건가요?" "대표 문구는 어떻게 쓸까요?" "상황 입력은 자유 텍스트인가요, 카테고리 선택인가요?"

이런 식으로 대화를 통해 기능 목록, 기술 스택, 컴포넌트 구조 등을 포함한 설계 문서를 스스로 작성한다.

내가 이전에 만든 interview 커맨드와 비슷하지만, Superpowers는 이 과정이 별도 명령어 없이 자동으로 발동된다. 내가 까먹어도 Claude가 알아서 질문부터 한다. (이게 진짜 편하다.)

2단계: Git 워크트리 생성

설계가 승인되면, git worktrees 스킬을 이용해 독립된 워크트리를 생성한다.

왜 워크트리인가? AI 코딩 시 여러 작업을 동시에 진행하다 보면 Git이 꼬이는 경우가 잦다. (나도 Codex에서 병렬 작업하다 merge conflict 지옥을 겪은 적이 한두 번이 아니다.) 워크트리로 분리하면 실험 중 문제가 생겨도 메인 브랜치는 안전하고, 워크트리만 삭제하면 깔끔하게 원복된다.

3단계: 계획 작성 (Writing Plan)

Writing Plan 스킬이 설계 문서를 받아서 구체적인 태스크(Task)로 쪼갠다. 태스크는 사이즈별로 분해되고, Claude는 사용자에게 계획 승인을 요청한다.

내가 만든 TDD Planning과 비슷한 흐름인데, 언어나 프레임워크에 상관없이 자동으로 적절한 포맷으로 만들어준다. 그때마다 맞춤형 스킬을 세팅하던 번거로움이 사라진 셈이다.

4단계: 서브 에이전트 기반 개발

여기서부터가 Superpowers의 진가가 드러난다.

계획 실행 시 서브 에이전트 드리븐 방식 또는 배치 실행 방식 중 하나를 선택할 수 있다. 서브 에이전트 드리븐 방식이 더 효율적인데, 메인 Claude가 PM 역할을 하고 서브 에이전트들에게 개발을 시킨 후 결과물을 취합하는 구조다.

일종의 오케스트라 지휘자와 비슷하다. 메인 Claude가 지휘자로서 전체 흐름을 관장하고, 서브 에이전트들이 각자 맡은 파트(UI, API, 데이터 레이어 등)를 동시에 작업한다. Dispatch Parallel Agent 스킬로 병렬 작업이 가능하니, 단일 Claude로 작업할 때 발생하는 컨텍스트 오류도 줄어든다.

(단, Codex 는 아직 sub agent 를 지원하지 않기 때문에 사용이 불가하다.)

5단계: TDD 및 디버깅

Superpowers는 TDD를 강제한다. RED -> GREEN -> REFACTOR 사이클을 반복한다.

단계	설명
RED	테스트를 먼저 작성하고 실패를 확인
GREEN	최소한의 코드로 테스트를 통과시킴
REFACTOR	코드를 정리하고 품질을 개선

테스트 실패나 버그 발생 시에는 Systematic Debugging 스킬이 4단계 프로세스로 자동 발동된다.

에러 메시지 분석 - 무엇이 잘못되었는지 파악
관련 코드 범위 특정 - 어디서 문제가 발생했는지 좁히기
가설 수립 및 검증 - 왜 발생했는지 추론하고 확인
수정 및 테스트 - 고치고 다시 검증

내 이전 글에서 말한 TDD 사이클과 거의 동일한 철학이다. 다만 Superpowers는 이걸 별도 커맨드 없이, 어떤 언어/프레임워크에서든 자동으로 적용한다는 점이 다르다.

6단계: 검증 (Verification)

Verification 스킬이 모든 수정 사항을 확인한다. 테스트 재실행, 관련 기능 영향 확인, 엣지 케이스 체크 등을 수행한다.

솔직히 Claude가 "다 됐어요"라고 해놓고 실제로는 안 돌아가는 경우, 한두 번 겪은 게 아니다. 이 검증 단계가 있으니까 그런 상황이 크게 줄어든다.

7단계: 코드 리뷰 및 피니싱

태스크 하나가 끝날 때마다 코드 리뷰를 진행한다. 2단계 리뷰 구조다.

스펙 준수 확인 - 요구사항대로 구현했는가
코드 품질 확인 - 보안 취약점, 성능 이슈, 코드 스타일 등

리뷰 결과는 Critical, Major, Minor로 분류되고, 피드백에 따라 자동으로 코드를 수정한다.

모든 태스크가 완료되면 Finishing 스킬이 워크트리 정리, PR 생성까지 처리한다.

Writing Skills: 메타 스킬의 힘

스킬 라이브러리

Superpowers에 내장된 스킬들을 정리하면 이렇다.

카테고리	스킬	설명
Testing & Quality	TDD	RED-GREEN-REFACTOR 사이클
Debugging	Systematic Debugging	4단계 근본 원인 분석
Debugging	Verification	완료 전 검증
Collaboration	Brainstorming	질문 기반 요구사항 정의
Collaboration	Plan Composition/Execution	계획 작성 및 실행
Collaboration	Parallel Agent Dispatching	서브 에이전트 병렬 작업
Collaboration	Code Review	2단계 코드 리뷰
Collaboration	Git Worktree Management	워크트리 생성/정리
Collaboration	Subagent-Driven Development	PM-개발자 분업
Meta	Writing Skills	스킬 생성/수정 프레임워크
Meta	Superpowers Introduction	시스템 소개

모든 스킬은 마크다운 파일 기반이다. 절차, 모범 사례, 워크플로우를 문서화한 재사용 가능한 지식 모듈이라고 보면 된다.

커스텀 스킬 만들기

여기서 진짜 강력한 게 Writing Skills 메타 스킬이다. 기존 스킬을 업데이트하거나 새로운 스킬을 직접 생성할 수 있다.

사용법은 간단하다. Claude에게 이렇게 말하면 된다.

"우리 회사 코딩 컨벤션을 강제하는 스킬을 만들어 줘"

그러면 Claude가 알아서 스킬 파일을 생성한다. 새로운 스킬을 만들 때도 TDD, 서브 에이전트, 압박 시나리오 확인 등 기존 개발 프로세스를 동일하게 적용한다. 스킬을 만드는 것 자체가 Superpowers 워크플로우를 따르는 거다.

더 재밌는 건, 프로그래밍 책 PDF를 던져주고 "책 읽고 새로 배운 걸 스킬로 만들어"라고 요청하는 것도 가능하다는 점이다. 클린 코드 원칙이든, 특정 아키텍처 패턴이든, 문서화된 지식이면 뭐든 스킬로 변환할 수 있다.

실전 사례들

Superpowers의 진가는 실전에서 드러난다. 몇 가지 사례를 살펴보자.

1. Next.js 16 마이그레이션 — 500줄 계획이 자동 생성

한 개발자가 자신의 서비스를 Next.js 16으로 업그레이드하면서 cacheComponents 기능을 활성화하는 작업을 Superpowers에 맡겼다. /superpowers:write-plan을 실행하자, 500줄짜리 마이그레이션 계획이 생성되었다.

수정이 필요한 23개 API 라우트 파일 전체 목록
new Date() 사용으로 프리렌더링이 깨질 2개 컴포넌트 식별
Suspense 경계 설정이 필요한 컨텍스트 프로바이더 특정
4일 타임라인과 각 단계별 테스트 체크포인트

사람이 코드베이스를 분석해서 이 목록을 만들었다면 하루 이상 걸렸을 작업이다.

2. Notion 클론 — 45분, 수동 코드 0줄

Notion 스타일의 웹 앱(리치 텍스트 에디터, 인터랙티브 테이블, 드래그앤드롭 칸반보드)을 Superpowers로 개발한 사례다. 결과가 꽤 인상적이다.

항목	결과
개발 시간	45~60분 (대부분 자동)
테스트 커버리지	87% (단위, 통합, E2E)
수동 작성 코드	0줄
포함 기능	CRUD 테이블, 칸반보드, 리치 텍스트, 인증

3. 인증 시스템 스킬화 — 6개 프로젝트에 14시간 절감

한 개발자가 여러 프로젝트에서 반복 구축하던 인증 시스템(OAuth, 세션 관리, 토큰 갱신 등)을 Writing Skills로 스킬화한 사례다. 기존 코드베이스를 분석해서 302줄의 구현 가이드를 생성하고, ASCII 와이어프레임으로 모든 화면을 매핑한 뒤, 약 20분 만에 재사용 가능한 스킬을 완성했다. 이후 새 프로젝트에서 /authentication-setup 한 줄로 전체 인증 시스템을 배포했고, 6개 프로젝트에 적용하면서 총 14시간을 절감했다. 100% 일관성도 유지됐다.

4. 채널톡 연동 스킬 — 3일을 30분에

채널톡 공식 문서 전체를 Claude에게 전달하고, Writing Skills로 채널톡 연동 스킬을 만든 사례다. 이 스킬을 설치하면 "채널톡 연동 해줘"라고만 요청해도 SDK 설치, 봇 설정, 웹훅 연결, ALF 태스크까지 모두 자동 처리된다. 원래 3일 걸릴 작업이 30분이면 끝난다.

결국 Superpowers의 진짜 가치는 스킬을 쌓아갈수록 점점 강력해진다는 점이다. 프로젝트별로, 팀별로, 회사별로 맞춤형 스킬을 축적하면, 그 자체가 팀의 개발 지식 베이스가 된다.

왜 잘 동작하나?: 설득의 심리학 + 압박 테스트

압박 시나리오로 단련된 스킬

Superpowers의 제작자는 단순히 스킬을 만들고 끝낸 게 아니다. 프로덕션 서버 다운, 분당 5,000달러 손실 같은 극한 압박 시나리오를 사용해서 스킬을 테스트했다.

왜냐하면, 압박 상황에서 Claude가 스킬을 무시하고 바로 코딩하려는 경향이 있기 때문이다. 제작자는 이런 상황에서 Claude가 스킬을 사용하지 않고 바로 코딩하면, 테스트를 실패 처리하고 스킬을 더 강화하는 과정을 반복했다.

그래서 Superpowers의 스킬들은 단순한 프롬프트가 아니라, 실전에서 검증된 프레임워크다. 급한 상황에서도 "일단 질문부터, 계획부터"라는 프로세스를 지킨다.

Superpowers의 철학

Superpowers가 지향하는 핵심 철학을 정리하면 이렇다.

Test-first development - 테스트가 먼저, 구현은 그 다음
Systematic processes over intuition - 직감보다 체계적 프로세스
Simplicity as primary objective - 단순함이 최우선 목표
Empirical verification before success declarations - "됐어요" 전에 실제 검증

결국 좋은 개발 습관을 AI에게 강제하는 거다.

실전 활용 팁

토큰 사용량 참고

Superpowers는 계획 단계에서 딥 이터레이션을 하기 때문에 토큰을 많이 사용한다. Claude Max 플랜을 추천한다. 간단한 기능 수정에는 오버킬일 수 있으니, 적합한 사용 시점을 잘 골라야 한다.

이럴 때 쓰면 좋다

상황	적합도	이유
신규 MVP 프로젝트 시작	높음	설계부터 구현까지 전체 흐름 활용
복잡한 기능 추가	높음	서브 에이전트 병렬 개발 + TDD
전체 코드 리팩토링	높음	체계적 계획 + 검증이 중요
간단한 버그 수정	낮음	오버킬, 직접 수정이 빠름
한 줄짜리 설정 변경	낮음	Superpowers 없이 진행

야간 자율 작업

큰 플랜을 잡아 놓으면 몇 시간 동안 혼자서 자율 작업이 가능하다. 밤에 계획을 승인시키고 작업을 시키면, 아침에 PR이 와 있는 형태로 활용할 수 있다.

나가며

Superpowers를 한 마디로 요약하면, 내가 하나하나 만들어 쓰던 interview 커맨드, TDD 스킬, 코드 리뷰 스킬을 하나로 통합하고, 거기에 서브 에이전트 병렬 개발과 Git 워크트리 관리까지 얹은 프레임워크다. 게다가 설득의 심리학까지 적용해서 AI가 이 워크플로우를 확실하게 지키도록 만들었다.

핵심 기능	설명
자동 브레인스토밍	명령어 없이 질문부터 시작
7단계 워크플로우	설계 -> 계획 -> TDD -> 리뷰까지 자동
서브 에이전트	PM-개발자 분업, 병렬 실행
TDD 강제	RED-GREEN-REFACTOR 사이클
검증 내장	"됐어요" 사기 방지
Writing Skills	커스텀 스킬 자율 생성
심리학 기반	스킬 준수를 확실하게 강제

설치는 두 줄이면 끝나니, 일단 해보는 걸 추천한다. 처음부터 완벽하게 쓸 필요 없다. Superpowers를 깔고 평소처럼 작업을 시작하면, Claude가 알아서 질문부터 시작할 거다. 그 흐름을 따라가 보면서 자기한테 맞는 활용법을 찾아가면 된다.

그리고 Writing Skills로 자기만의 스킬을 하나씩 추가해 나가면, 점점 더 강력해진다. 나도 계속 스킬을 추가하면서 쓰고 있다.

"a complete software development workflow for your coding agents, built on top of a set of composable 'skills.'" 조합 가능한 스킬 위에 구축된, 코딩 에이전트를 위한 완전한 소프트웨어 개발 워크플로우.

-- Superpowers GitHub README

Claude Code 지금 바로 Superpowers 설치하고, 다음 프로젝트에서 한번 써봐라.

날개가 달린다.

References

"돌파력"을 읽고 (feat. 명상록을 곁들인..)

Tony Cho (https://flowkater.io) — Tue, 03 Feb 2026 01:00:00 GMT

해당 리뷰는 readmeleadme (이하 릿미릿미) 독서 스터디 리뷰입니다.

돌파력 - 시련을 성장으로 이끄는 절대 불변의 법칙

라이언 홀리데이 저 / 안종설 역 | 심플라이프 | 2024년 11월 11일

원제: The Obstacle Is the Way

들어가며

새해를 시작하면서 "정신 무장"을 위해 선택한 책이다.

여러 가지 일을 겪으면서 작년 한 해 잠시 멈춘 시간 동안 회복이 될 줄 알았던 후유증이 오히려 점점 더 악화되어 몸도 마음도 많이 힘든 시기를 겪었다. 그러나 다행히 내가 알고 있었던 건 이미 환경을 바꾼 순간부터 그건 나의 내면의 문제였지, 어떤 다른 문제가 아니었다.

2020년에 사업을 이제는 정리해야 한다는 걸 깨달았을 때와 똑같았고, 사실 시간이 걸리긴 하겠지만 그때보다 좀 빠를 줄 알았으나, 오히려 그때보다 더 길게 걸린 것 같다. 오히려 더 내면을 마주보려 하지 않았고 다른 일과 외부로 관심을 돌렸다.

다행히도 12월부터 여러 부상과 염증을 달고 살던 몸을 일으켜 세워서 예전같지 않지만 조금씩 운동을 시작하기도 했고, 쉼이라는 핑계로 망가진 라이프 밸런스를 다시 조이면서 오히려 이전보다 더 활기차게 오랜 시간 집중하고 또 루틴을 되찾으면서 내면을 회복하기 시작했다.

스토아 철학의 정수를 이어받아 이성적인 판단을 하고 내가 그 어떠한 실패와 좌절에도 다시 앞으로 나아가길 두려워하지 않는 그야말로 "돌파력"을 가지기 위해서는 어쩌면 약간의 시간이 필요했는지도 모른다. 실패하지 않은 삶이야말로 도전하지 않는 삶이고, 자기 합리화와 자기 연민에 빠진 것만큼 중독적이고 해악도 없다.

자기 합리화와 자기 연민의 시간을 충분히 겪다 보니 알게 된 건 이 모든 건 내가 내 감정에 중독되어 허우적대는 꼴이었고, 이성적으로 나를 바라보니 그게 아무런 일도 아니었고 이미 다 지나간 일이었다는 것을 깨달았다.

담대하게 받아들이고 가고자 했던 내 모습은 온데간데없고, 결국 마지막에 자기 합리화와 자기 연민, 남 탓으로, 그리고 그런 모습을 스스로 또 혐오하면서 무한루프를 돌았던 시간들이 이제 조금 정리가 되었다.

로마제국 제16대 황제, 오현제(五賢帝), 철인황제(哲人皇帝) - 마르쿠스 아우렐리우스 (Marcus Aurelius)

지금 이 순간, 객관적으로 판단하라. 지금 이 순간, 헌신적으로 행동하라. 지금 이 순간, 벌어지는 모든 일들을 기꺼이 받아들이라. 필요한 것은 이게 전부다.

— 마르쿠스 아우렐리우스

돌파력을 읽다 보니 가장 마음에 들었던 건, 과거도 미래도 없다, 모두에게 주어지는 현재 지금 이 순간이라는 것, 그리고 우리에게 일어나는 이 모든 좋은 일, 안 좋은 일은 사실 우주에서는 그 어떠한 판단도 없다는 것이다. 지금 함께 읽고 있는 명상록에서 마르쿠스 아우렐리우스가 거듭 강조하는 이야기들이다.

책의 메시지는 간단하다. 너에게 일어나는 그 모든 일에도 불구하고 우리는 다시 일어서서 나아가야 한다. 그렇게 해야 한다고 응원하는 게 아니라 응당 그래야 한다고, 그렇게 하지 않으면 안 된다는 얘기를 한다. 의무를 다해야 한다고 단호하게.

돌파력: 인식, 행동, 의지

돌파력은 세 가지 단계를 제시한다.

출발점은 우리의 문제점, 우리의 태도나 접근 방법을 구체적으로 직시하는 단계(인식)다. 그 다음은 뜨거운 열정과 창의력을 발휘해 실제로 장애물을 제거함으로써 기회를 만들어내는 단계(행동)이며, 마지막은 거듭된 실패와 난관에 대처할 수 있는 내적 자아를 배양하고 유지하는 단계(의지)다.

이 세 가지 축은 서로 밀접하게 연결되어 있다. 인식 없이는 올바른 행동이 나올 수 없고, 의지 없이는 반복되는 실패를 견딜 수 없다. 라이언 홀리데이는 이 프레임워크를 통해 스토아 철학의 핵심을 현대적으로 재해석한다.

인식: 객관적으로 바라보기

객관적인 시각을 유지한다. 감정을 통제하고 균형 감각을 잃지 않는다. 긍정적인 요소를 찾아내기 위해 노력한다. 흥분하거나 당황하지 않는다. 통제 가능한 부분에 집중한다.

홀리데이가 제시하는 인식의 핵심은 감정과 사실을 분리하는 것이다. 그는 조지 클루니의 사례를 들어 이를 설명한다.

이제부터 클루니는 이런 관점을 오디션에 투영하기 시작했다. 연기 실력만 들입다 강조하는 것이 아니라, 자신이 이번 배역을 맡아야 하는 이유를 설명했다.

클루니는 오디션을 "심사받는 자리"가 아니라 "문제를 해결하러 가는 자리"로 재정의했다. 관점의 전환이 현실을 바꾼 것이다. 홀리데이는 이를 두 가지 개념으로 정리한다.

맥락: 우리 앞에 당면한 것들뿐 아니라 세상 전체를 바라보는 더 큰 그림에 대한 감각.

뼈대: 세상을 바라보고, 그 속에서 일어나는 다양한 사건들을 바라보는 자신만의 방식.

돌이켜보면 나는 통제할 수 없는 것들에 너무 많은 에너지를 쏟았다. 지나간 일에 대한 후회, 아직 오지 않은 미래에 대한 불안. 정작 지금 이 순간 내가 할 수 있는 것들은 외면한 채.

당신이 자주 생각하는 것, 그것이 당신이 된다.

이 문장이 특히 와닿았다. 자기 연민의 늪에서 허우적대는 동안, 나는 그 연민 자체가 되어가고 있었다. 매일 같은 생각을 반복했고, 그 생각이 나를 규정했다. 생각이 나를 만든다면, 나는 무엇을 생각해야 하는가.

우리가 세상을 바라보는 방식은 이런 것들을 바라보는 방식에 따라 달라진다. 우리의 관점이 정말로 우리에게 '관점'을 가져다주는가, 아니면 오히려 그것이 문제를 초래하는 주범인가?

홀리데이는 묻는다. 관점이 해결책인가, 문제인가? 나의 경우 관점 자체가 문제였다. 상황을 객관적으로 보지 못하고, 감정에 휩싸여 모든 것을 왜곡해서 바라봤다.

모든 장애물 속에는 더 나은 현실을 만들 기회가 숨어 있다는 사실을 잊지 말라.

실패를 바라보는 관점의 전환. 이건 억지로 긍정적으로 생각하라는 뜻이 아니다. 객관적으로 상황을 직시했을 때, 그 안에서 배울 수 있는 것을 찾으라는 것이다.

행동: 일단 시작하기

모든 바보의 공통점은 언제나 시작할 준비만 한다는 점이다.

— 세네카

쉬는 시간 동안 나는 얼마나 많은 "준비"를 했던가. 회복하면 시작하겠다, 컨디션이 좋아지면 하겠다, 마음이 정리되면 움직이겠다. 끝없는 준비. 그러나 준비만 하는 동안 시간은 흘러갔다.

홀리데이는 이런 태도를 정면으로 비판한다.

우리는 세상이 늘 우리의 편의를 봐줄 거라는 착각 속에 살아갈 때가 많다. 그래서 당장 행동을 시작해야 할 시점에 미적거리기만 한다. 전력으로 달려도 모자랄 판에 느긋하게 조깅을 즐긴다.

이 문장에서 뜨끔했다기보다는, 내 모습이 그대로 보였다. 긴급한 상황인 줄 알면서도 조깅하듯 느긋하게 걸었다. 미적거리는 동안 문제는 더 커졌고, 기회는 멀어졌다.

사실 2020년에 사업을 정리하고 나서 다시는 창업을 안 하겠다고 생각했다. 그런데 지금 나는 또 사업을 하고 있다. 아내와 함께 새로운 제품을 만들고 있다. 과거의 실패가 트라우마로 남아서 한동안 "준비만" 했던 것 같다. 완벽하게 준비되면, 시장이 확실해지면, 자신감이 생기면. 그런 날은 오지 않았다.

결국 그냥 시작했다. 완벽하지 않아도, 확실하지 않아도, 자신감이 없어도. 홀리데이의 말처럼 "내일 할 거야"는 가장 교활한 거짓말이다. 내일은 오지 않는다. 오늘의 내일이 되면 또 다른 내일이 생길 뿐이다.

제대로 살기 위해 무언가를 기다리지 마라. 인생은 그 사이에 지나가버린다.

결국 행동만이 현실을 바꾼다. 생각만으로는, 계획만으로는, 다짐만으로는 아무것도 달라지지 않는다. 행동은 완벽할 필요가 없다. 다만 멈추지 않으면 된다.

의지: 실패를 받아들이기

세상은 당신이 저지른 실패, 행동에 대해 그때마다 분명한 메시지를 전하려 한다는 점을 명심하라. 그것은 일종의 피드백이다. 앞으로는 어떻게 해야 좀 더 발전할 수 있는지를 일깨워주는 정확한 지침서와도 같다.

실패는 끝이 아니라 피드백이다. 이 관점의 차이가 모든 것을 바꾼다. 실패를 두려워하면 시도조차 하지 않게 되고, 실패를 피드백으로 받아들이면 더 많이 시도할 수 있게 된다.

홀리데이는 의지의 본질을 이렇게 설명한다.

역경을 기회로 승화시키는 사람들은 언제나 있었다. 그들은 결코 포기하지 않는다. 자기 연민에 빠지지도 않는다. 곧 간단한 해결책이 나타날 거라는 환상으로 스스로를 기만하지도 않는다. 그들은 꼭 필요한 한 가지, 끝까지 활력과 창의력을 잃지 않는 방법에 초점을 맞춘다.

"자기 연민에 빠지지 않는다"는 문장이 마음에 박혔다. 쉬는 시간 동안 나는 자기 연민의 전문가가 되어 있었다. 홀리데이는 그런 태도를 정면으로 비판한다.

데모스테네스처럼 행동하기보단 무기력하고 허황된 생각에 빠져, 자신을 한 단계 더 발전시킬 기회를 외면해버린다. 틀림없이 문제점을 밝혀내고 해결책을 찾아낼 기회가 있음에도 불구하고 몇 주, 몇 달, 심지어는 몇 년을 허비한다.

니체의 말이 떠오른다.

죽지 않을 만큼의 고통이 나를 더욱 강하게 만들었다.

다만, 이 말을 오해하면 안 된다. 고통 자체가 우리를 강하게 만드는 게 아니다. 고통을 어떻게 받아들이고, 어떻게 통과하느냐가 우리를 결정한다. 홀리데이도 이 점을 강조한다.

아니, 문제는 정확하게 우리가 어렵다고 생각하는 만큼 풀기 어렵다. 일어날 수 있는 최악의 사태는 사태 그 자체가 아니라 그로 인해 이성을 상실하는 것임을 알아야 한다.

지금 이 순간이 곧 나의 인생이 아니라, 내 인생의 한 순간일 뿐이라는 사실을 명심하라.

지금의 힘듦이 영원할 것 같지만, 그렇지 않다. 이것도 지나간다. 홀리데이는 묵종의 기술에 대해서도 말한다.

스토아 철학은 이런 태도에 아주 근사한 이름을 붙여놓았다. 그들은 이것을 '묵종의 기술'이라 부른다.

바꿀 수 없는 것을 받아들이고, 바꿀 수 있는 것에 집중하는 것. 그것이 의지의 본질이다.

명상록: 현재에 집중하기

돌파력을 읽으면서 자연스럽게 명상록을 다시 펼쳐 들게 되었다. 라이언 홀리데이가 스토아 철학을 현대적으로 해석했다면, 마르쿠스 아우렐리우스는 그 원천이다. 거의 2천 년 전 로마 황제가 쓴 글이 지금도 유효하다는 것이 놀랍다.

일어나 의무를 다하라

날이 밝았는데도 잠자리에서 일어나기가 싫을 때는 마음속으로 이렇게 생각하라: "나는 인간으로서 해야 할 일을 하기 위해 일어나는 것이다. 나는 그 일을 위해 태어났고, 그 일을 위해 세상에 왔는데, 그런데도 여전히 불평하고 못마땅해하는 것인가. 나는 침상에서 이불을 덮어쓰고서 따뜻한 온기를 즐기려고 태어난 것이 아니지 않느냐."

아침에 눈을 뜨고 일어나기 싫은 날이 있다. 아니, 솔직히 그런 날이 더 많았다. 그런데 마르쿠스 아우렐리우스는 로마 제국의 황제였다. 그도 아침에 일어나기 싫었다. 그런데도 일어났다. 해야 할 일이 있었으니까.

마르쿠스는 의무에 대해 단호하다.

순간마다 로마인답게, 그리고 남자답게, 꾸밈없는 당당함과 동포애와 독립심과 정의감을 가지고서 자신에게 맡겨진 소임을 정확하고 꼼꼼하게 사심 없이 완수하고, 다른 잡념들은 모두 다 버려라.

의무라는 단어가 무겁게 느껴질 수도 있다. 그러나 생각해 보면, 내가 해야 할 일이 있다는 것 자체가 살아 있다는 증거다.

어떤 일을 할 때마다 마치 그 일이 이 땅에서 네가 하는 마지막 일인 것처럼 행하고, 네가 의도적으로 이성의 통제에서 벗어나서 너의 감정에 이끌려서 제멋대로 행하지 않으며, 위선과 이기심과 네게 주어진 운명에 대한 불만에 사로잡히지 않는다면, 너는 얼마든지 그렇게 할 수 있게 될 것이다.

마르쿠스는 "감정에 이끌려 제멋대로 행하지 않는 것"을 강조한다. 이성의 통제 아래 행동하는 것. 이것이 스토아 철학의 핵심이다.

와야 할 것이 오고 있다

마치 수천 년을 살 것처럼 살아가지 말라. 와야 할 것이 이미 너를 향해 오고 있다. 살아 있는 동안 최선을 다해 선한 자가 되라.

쌓아둔 발췌본들을 읽을 시간도 아마 주어지지 않을 것이다. 그러므로 네 자신에게 어떤 염려되는 것이 있다면, 아직 시간이 허락되는 동안에 다른 모든 헛된 희망들은 다 내던져 버리고서, 오직 그 목표를 완성하는 데 온 힘을 다 쏟아서 네 자신을 구해내라.

죽음을 기억하라. 메멘토 모리. 이건 비관적인 이야기가 아니다. 오히려 그 반대다. 시간이 한정되어 있기에 지금 이 순간이 소중하다. 언젠가 읽으려고 쌓아둔 책들, 언젠가 하려고 미뤄둔 일들. "언젠가"는 오지 않을 수도 있다.

마르쿠스는 시간에 대한 통찰을 이렇게 정리한다.

설령 네가 삼천 년, 아니 삼만 년을 살 수 있다고 할지라도, 지나가는 것은 오직 지금 살고 있는 삶이고, 너는 지나가는 삶 외에 어떤 다른 삶을 사는 것이 아님을 명심해야 한다.

사람이 자기가 소유하고 있지 않은 것은 빼앗길 수 없고, 모든 사람은 다 똑같이 현재라는 순간만을 소유하고 있어서, 그가 누구든 오직 현재라는 순간만을 잃을 뿐이기 때문이다.

우리가 가진 것은 오직 현재뿐이다. 과거는 이미 지나갔고, 미래는 아직 오지 않았다. 잃을 수 있는 것도, 소유할 수 있는 것도 오직 현재다.

신들이 그동안 네게 무수히 많은 기회들을 주었는데도, 너는 그 기회를 단 한 번도 받아들이지 않고, 얼마나 오랫동안 이런 일들을 미루어 왔었는지를 기억해 보라.

이 문장을 읽으면서 지난 1년을 돌아봤다. 얼마나 많은 기회를 미루고, 외면하고, 나중으로 떠넘겼는가.

불운이 아니라 행운

"이런 일이 내게 일어난 것은 내게 불운이다"라고 말하지 말고, 도리어 "이런 일이 내게 일어났는데도 여전히 나는 현재 일어난 일 때문에 망가지지도 않고, 미래에 일어날 일도 두렵지 않으며, 이렇게 아무런 해악도 입지 않고 멀쩡한 것은 내게 행운이다"라고 말하라.

마르쿠스는 이 관점을 더 간결하게 정리한다.

"이 일은 불운이 아니다. 도리어 이런 일을 겪는데도 내가 나의 본성을 지켜내는 것이야말로 내게 행운이다."

이 구절을 처음 읽었을 때 선뜻 받아들이기 어려웠다. 힘든 일을 겪으면서 "이건 행운이야"라고 말하기란 쉽지 않다. 그런데 곰곰이 생각해 보면, 내가 여기까지 왔다는 것 자체가 증거다. 망가지지 않았다. 아직 여기 있다. 글을 쓰고 있다.

마르쿠스는 "모든 것은 생각하기 나름"이라는 말의 진정한 의미를 설명한다.

"모든 것은 생각하기 나름"이라는 것은 어떤 외적인 일이나 환경, 즉 행복이나 선악과는 아무런 상관이 없는 가치중립적인 것들의 성격과 영향은 그 일이나 환경에 의해서가 아니라, 오로지 사람이 그런 것들을 어떻게 받아들이느냐에 달려 있다는 의미다.

상황 자체는 가치중립적이다. 그것을 불운으로 볼 것인가, 성장의 기회로 볼 것인가는 전적으로 나의 선택이다.

스스로 서라

쾌활함을 잃지 말고, 외부의 도움 없이 네 자신의 힘으로 해 나가며, 다른 사람이 주는 편안함을 물리치고 스스로 서라. 네가 스스로 바르게 서야 하고, 남의 도움을 받아 서거나, 남이 너를 바르게 세우게 해서는 안 된다.

결국 나를 일으켜 세울 수 있는 건 나 자신뿐이다. 외부 환경 탓, 다른 사람 탓을 하면서 무한루프를 돌았던 시간들. 그 시간 동안 정작 내가 할 수 있는 일은 하지 않았다.

마르쿠스는 내면으로의 후퇴에 대해서도 말한다.

너는 네 자신이 원할 때마다 그 즉시 네 자신 속으로 물러나서 쉴 수 있기 때문이다. 사람이 모든 근심과 걱정에서 벗어나서 고요하고 평안하게 쉬기에는 자신의 정신보다 더 좋은 곳이 없다.

외부에서 평안을 찾으려 하지 말고, 내면에서 찾으라. 쉼도 결국 내 안에서 이루어지는 것이다.

누가 너에게 강요하는 대로, 또는 누가 네게 원하는 대로 어떤 것을 보지 말고, 모든 것을 있는 그대로 보라.

사람들이 무슨 말을 하고 무슨 행동을 하며 무슨 생각을 하는지는 신경 쓰지 않고 오로지 자신의 언행심사를 바르게 하고 의롭게 하는 데만 신경을 쓰는 사람은 마음이 평안하고 여유가 넘치게 된다.

타인의 시선에서 벗어나 자신의 길을 가는 것. 마르쿠스는 황제로서 수많은 사람들의 기대와 비난 속에서 살았을 텐데, 그럼에도 이런 경지에 이르렀다는 게 놀랍다.

나가며

돌파력과 명상록. 두 책은 시대를 달리하지만 같은 이야기를 한다.

과거에 연연하지 말 것. 미래를 두려워하지 말 것. 지금 이 순간에 집중할 것. 실패를 피드백으로 받아들일 것. 그리고 담대하게 앞으로 나아갈 것.

몇 번 실패했다고 멈출 필요가 없다. 오히려 더 많이 시도하고, 더 많이 실패하고, 더 많이 배우면 된다. 실패하지 않는 삶은 도전하지 않는 삶이다.

2020년에 사업을 접고 나서 한동안 창업은 다시 안 하겠다고 생각했다. 그런데 지금 다시 사업을 하고 있다. 과거의 실패가 사라진 건 아니다. 다만 그게 지금을 막을 이유는 안 된다는 걸 알았다.

자기 합리화와 자기 연민의 무한루프에서 벗어나는 데 오래 걸렸다. 그러나 그 시간도 필요했던 것 같다. 적어도 이제는 안다. 감정에 휘둘리는 것과 감정을 느끼는 것은 다르다는 걸. 감정을 느끼되, 그 감정에 중독되지 않는 것. 그게 스토아적 수용이 아닐까.

배운 것	액션 아이템
생각이 나를 만든다	자기 연민 대신 객관적 관찰로 전환하기
준비만 하는 건 아무것도 안 하는 것	오늘 할 수 있는 작은 행동 하나 실행하기
실패는 피드백이다	실패 후 자책 대신 배운 점 정리하기
현재만이 우리의 것이다	과거 후회, 미래 불안에 시간 쓰지 않기

마치 수천 년을 살 것처럼 살아가지 말라. 와야 할 것이 이미 너를 향해 오고 있다.

— 마르쿠스 아우렐리우스

현재에 집중하겠다. 오늘 해야 할 일을 하겠다. 그게 전부다.

스터디원들과 나누는 질문

1. 최근 여러분들의 가장 큰 실패는 무엇이었으며, 어떻게 “돌파”했는지? 거기에 따라 지금 하고 있는 행동은? 어떻게 극복했으며 관점을 바꿨는지도 공유해주세요.

가장 큰 실패는 마음의 실패입니다. 작년 몸과 마음의 컨디션이 모두 좋지 않았기에 완벽주의에 빠져 현재 프로젝트 진행을 계속 딜레이시켰고 지난 일에 대한 후회와 실패를 곱씹는 경우가 많았습니다. 특히, 팀 자체 운영에서 마무리가 실패였다는 것을 깨닫고 한동안 거기서 헤어나오지 못했습니다. 아무리 환경 자체가 어려운 환경이었지만 제가 조금 더 잘 마무리할 수 있었지 않았나라는 생각을 했었는데, 중요한 건 그 실패를 나온 후 계속 곱씹고 곱씹었다는 부분이었던 것 같습니다. 리뷰에서도 작성했지만 예전 투데잇 마무리 때도 비슷한 경험이 있었는데, 아무래도 조직에서 나와서 새로운 조직으로 들어가는 게 아닌 상태가 오래되다 보니 그 실패와 자기 연민에 갈수록 빠져들었던 부분이 있었습니다.

제가 극복하고 있는 방법은 글을 쓰는 것입니다. 최근에 블로그 글, 소설까지 전부 '돌파'와 극복을 위해 작성을 했으며, 제 머릿속과 마음속에만 떠돌던 관념들이 글로서 구체화되고 구체화되다 보니 조금 마음이 비워지고, 내가 다음 행동을 위해 무엇을 해야 할지가 조금 보였습니다. 제 마음속 응어리들이 승화되는 느낌입니다. 빨리 글을 썼으면 좋았겠다 싶었네요. 이제 글을 좀 쓰다 보니 이제는 좀 다시 읽고 채워야겠다는 생각이 듭니다. 비워야 비로소 채워진다는 말이 무척 공감이 되는 요즈음입니다.

2. 이 책을 읽으면서 가장 크게 바뀐 생각이 궁금합니다.

저는 글의 생각과 대부분 동일한 의견을 가지고 있는 사람이라 생각이 바뀌기 보다는 현실의 여러 제약 또한 그 길이 될 수 있다는 말을 다시 한번 되새기고 있습니다.

3. 쉬어야 할 때 밀어붙이면 번아웃이 오고, 밀어붙여야 할 때 쉬면 정체됩니다. 여러분은 그 경계를 어떻게 구분하시나요?

확실히 반대로 한 것 같습니다. 결국 중요한 건 결과(성과)인데 거기서 너무 오랫동안 질질 끄는 느낌이나 뚜렷한 결과가 없다면, 방향을 다시 되짚어볼 타이밍이라고 생각합니다. 단순히 쉬고 안 쉬고를 정하기보다 매일 일정한 리듬을 유지하고 루틴을 가져가며 필요할 때 더 집중하고 언제나 돌아볼 수 있는 마음의 여유를 가지는 게 중요하다고 봅니다. 다만, 내가 그냥 힘들어서라면 밀어붙여도 문제없다고 생각하는데, 내가 아무리 해도 변화가 없는 환경이라면 방향 변화가 꼭 필요하다고 생각해요.

4. 이 책에서 밑줄 친 구절 두 개를 골라보자. 왜 그 문장이었을까?

죽지 않을 만큼의 고통이 나를 더욱 강하게 만들었다. (..중략..) 아니, 문제는 정확하게 우리가 어렵다고 생각하는 만큼 풀기 어렵다. 일어날 수 있는 최악의 사태는 사태 그 자체가 아니라 그로 인해 이성을 상실하는 것임을 알아야 한다.

에반 올마이티 영화를 보면, 갑자기 현대 시대에 방주를 짓고 있는 에반을 떠나는 가족들의 장면이 나옵니다. 그때 신 역의 모건 프리먼과 에반의 아내가 어느 식당에서 나눈 얘기가 아직도 기억에 남습니다.

If someone prays for patience, do you think God gives them patience, or does He give them the opportunity to be patient?

“누군가가 인내를 달라고 기도하면, 하나님이 그냥 인내심을 뿅 하고 주실까, 아니면 인내심을 발휘할 ‘기회’를 주실까?”

If they pray for courage, does God give them courage, or does He give them the opportunity to be courageous?

“용기를 달라고 기도하면, 용기를 직접 주실까, 아니면 용기를 낼 수 있는 ‘상황’을 주실까?”

If someone prays for their family to be closer, do you think God just zaps them with warm, fuzzy feelings, or does He give them opportunities to love each other?”

“가족이 더 가까워지게 해 달라고 기도하면, 갑자기 마음이 따뜻해지게 만들까, 아니면 서로 사랑할 수 있는 ‘기회들’을 주실까?”

이후에 다시 에반에게 가족들이 돌아가며, 실제로 홍수가 터져 방주에 올라타는 성경의 사건이 재현되는 어쩌면 좀 뻔하고 가볍게 볼 만한 영화이지만, 크리스천이 아닌 저에게 이 장면이 크게 인상 깊었고, 이 책을 보면서도 계속 생각났던 장면입니다.

지금 이 순간, 객관적으로 판단하라. 지금 이 순간, 헌신적으로 행동하라. 지금 이 순간, 벌어지는 모든 일들을 기꺼이 받아들이라. 필요한 것은 이게 전부다.

위에서도 이 문장으로 글을 시작했는데, 세상에 일어나는 모든 일들이 가치 중립적이라는 것, 중요한 건 내 이성과 의무를 다한다는 스토아적 관점이 작은 일에도 힘들어하거나 너무 들뜨거나 하는 저의 감정 에너지를 항상 일관되게 가져갈 수 있는 문장인 것 같습니다. 항상 제가 추구하는 가치도 그 무엇보다 지금 이 순간에 집중하자입니다.

제가 또 좋아하는 영화인 "평화로운 전사"에서 주인공에게 멘토 "소크라테스"가 얘기합니다.

“진정한 전사는 자신이 사랑하는 것을 포기하지 않는다. 대신, 지금 하는 일에서 사랑할 이유를 찾아낸다.”

5. 통제가 완전히 사라진(불가한) 순간에도 '내가 지킬 수 있는 태도'는 무엇일까?

결국 내 생각, 내 감정, 내 판단은 내가 결정하는 것이라고 여기서 얘기한다고 생각해요. 어렵지만, 내가 이런 순간에 어떻게 생각할지, 어떻게 느낄지, 어떻게 판단할지도 우리가 선택할 수 있다는 것입니다. 물론 그냥 무너진 상태에서 자신을 너무 밀어붙이면 안 된다고 생각하지만(힘듦도 소화할 수 있는 시간이 필요한 것 같아요.), 그럼에도 불구하고 멘탈을 붙잡고 이성적으로 판단하며 내가 할 수 있는 일을 해야 하는 태도가 정말 중요하다고 생각합니다.

6. 이 책을 통해 '내가 문제를 대하는 방식'을 새삼 자각하게 된 부분이 있는지?

저는 오히려 일에 대해서는 이성적인 판단이 쉬운데, 사람이나 오히려 하루 일상적인 일에서 쉽게 감정적으로 예민하게 굴고 짜증을 내기도 합니다. 별 것도 아닌데 말이죠. 그래서 역설적으로 큰 일에는 마음을 굳게 먹고 담대하게 맞이하는 대신, 작은 일에 쉽게 무너지는 편이라 여기서 말하는 여러 문제를 대하는 방식들이 꼭 우리가 목표로한 일 외에도 일상의 평온을 유지하게 하기 위해서도 내 생각을 조금 더 여유롭게 가져야겠다는 다짐을 하게 되었습니다.

7. (책 제목이 번역이긴 해도, 그렇게 번역한데엔 이유가 있을거라는 생각에서…) 이 '돌파'라는 단어가 내겐 어떤 의미로 다가왔나요?

인생은 어렵습니다. 아니, 어렵다고 생각하는 것도 우리가 어렵다고 생각해서 그런 것 같기도 하지만요. '돌파'라는 말이 좀 촌스럽긴 해도, 어쩌면 또 그 정도 마음가짐이 있어야 우리가 마주하는 수많은 문제들을 조금은 덜 흔들리고, 덜 무너지고 나아갈 수 있을거라고 생각해요. 이 책을 통해 우리 모두에게 어떠한 고난과 어려움이 닥쳐도 '돌파'할 수 있는 용기와 힘을 얻었길 바랍니다.

8. 두 분은 결과 중심인가요? 과정 중심인가요? 어떻게 균형을 맞추실까요?

저는 과거에는 과정 중심이었다가 이제는 완전히 결과 중심입니다. 사업을 운영해보고 팀을 운영해보고 실패도 하면서 느끼는 건, 그 과정이 어떠하던 결과에 따라서 그 과정의 평가가 모두 바뀐다는 것이었습니다. 그렇다고 과정이 중요하지 않다고 생각하지 않습니다. 어디까지나 결과 '중심' 이라는 것이죠.

과거에는 과정 중심이다 보니 결과가 별로라도 어색하게 서로 박수치는 일들이 있었습니다. 그게 위로라고 생각했고 더 나아갈 수 있다고 생각했어요. 하지만 "결과가 어떻든 과정에서만 열심히 하면 되니까"라는 게 정말 사람을 수동적으로 바꾸고 무책임하게 바꾼다는 걸 크게 깨달았고, 스스로에게도 팀을 운영할 때도 결국 좋은 결과, 제가 이전에 썼던 승리하지 못하는 조직에게 미래는 없다도 같은 맥락의 글입니다.

결론은 무조건 결과 중심이 맞다. 하지만 결과를 통해 과정을 더 잘하기 위해 노력해야지, 결과만 좋다면 과정이 아무렇게나 되어도 좋은 건 아니다. 정도 일 것 같습니다.

9. 계획대로 안될 때 어떻게 하시나요? 계획을 수정/버리시나요? 아니면 늦었더라도 그 계획을 밀고 나가시는 편인가요?

예전에는 계획을 수정/버리는 경우가 많았습니다. 하지만 원칙은 계획도 결국은 8번 질문과 같이 과정의 일부이기 때문에 이 계획이 정말 결과(성과)에 부합하는지 거기에 합당한 비용이 지불되는 건지 항상 저울질을 했던 것 같은데, 이건 사업에서 보통의 판단이고 개인적으로 업무를 하거나 공부를 할 때는 그냥 더 밀고 나가서 마무리를 하는 편입니다. 엄청난 비용이 아니라면, 결국 밀고 나가서 배우는 게 중간에 포기하는 것보다 더 많이 배우더라고요.

10. 읽기 어려운 책을 마주했을 때 어떻게 하시나요?(그냥 쭉 읽고 다시 읽기 등), 그리고 읽기 어렵다는 판단을 어떻게 하실까요?

왠만하면 그냥 쭉 읽고 넘어갑니다. 굳이 강박증을 느끼지는 않아요. 어차피 읽을 책들이 많으니까, 시간이 지나서 예전에 읽었던 게 그냥 이해되기도 해요. 시험 공부나 달달 외워야 하는 게 아니니까 아무리 좋은 책이더라도 내가 읽기 어려우면 다시 읽지는 않습니다. 대신 끝까지 읽으려고 하는 부분은 오히려 있어요. 뭐랄까 문해력 수련이랄까. 그 시련을 버티고 나면 다른 책 보면 정말 쉽습니다. 제가 요즈음 전자책 덕분에 책을 동시에 3개 병행해서 읽고 있는데, 쉬운 책 (보통 소설), 중간 책, 어려운 책 이렇게 돌려가면서 어려운 책은 딱 하루 최소 정해진 만큼만 보고 (제일 먼저), 그 다음 중간 책을 정해진 것보다 좀 더 많이, 쉬운 책은 몰아서 읽기도 하고 안 읽기도 합니다. 뭐든 하나만 보면 지루하기 때문에 또 돌려가면서 보니까 좋더라고요.

근데 무조건 읽어야겠다 싶은데 어렵다면, 이런 식으로 독서 스터디를 이용하는 게 가장 좋은 것 같아요. 내가 대충 읽어도 다른 사람의 생각과 후기를 통해 책 내용을 간접적으로라도 소화하고 넘어갈 수 있는 것 같습니다. 사실 저는 항상 책 그 자체 내용보다 그걸 통해서 드러나고 정리되는 우리의 생각이 더 재밌어요.

(픽션) 허공을 미는 사람들 - 에피소드 2, 허무한 성공 - 1

Tony Cho (https://flowkater.io) — Sun, 25 Jan 2026 12:54:11 GMT

이 작품에 등장하는 모든 인물, 이름, 집단, 사건은 허구이며 실존하는 것들을 기반으로 하지 않았습니다.

Author: flowkater

에피소드 2: 허무한 성공 - 1

[토요일, 오후 2:47] 박 팀장 - 처가댁에서

핸드폰이 울렸다. 오늘만 네 번째다.

화면을 보지 않아도 누군지 안다. 부서장님이다.

거실에서 장인어른께서 소파에 앉아 TV를 보고 계셨다. 점심은 이미 끝나서 다들 먹었다. 나만 빼고. 첫 번째 전화가 왔을 때 숟가락을 들었고, 두 번째 전화가 왔을 때 국을 한 모금 떴고, 세 번째 전화가 왔을 때 밥상에서 일어났다. 장모님께서 랩을 씌워 놓으셨다. 미역국이었다.

"잠시만요."

작은방으로 들어갔다. 장인어른께서 나를 힐끗 보시며 뭔가 말씀하시려다 안 하셨다. 장모님도 부엌에서 나를 보셨는데 아무 말씀 없으셨다. 그게 더 죄송했다.

문을 닫고 전화를 받았다.

"예, 부서장님."

"팀장님, 아까 그 건 확인됐어요?"

아까 그 건. 대행업체에서 요청한 API 응답 시간 관련 이슈다. 특정 조건에서 3초 이상 걸린다는 민원이 들어왔다. 한 시간 전에도 같은 질문을 받았다.

"아직 확인 중입니다. 제가 직접 맡은 파트가 아니라서 담당자한테 연락해 보고…"

"아니, 팀장님이 그걸 모르면 어떡해요?"

목소리가 날카로워졌다. 익숙한 톤이다.

"해당 모듈은 하 과장 담당이라서요. 정확한 원인 파악을 위해서는…"

"담당이 누군지 물어본 게 아니잖아요."

말이 끊겼다. 부서장님이 한숨을 쉬는 소리가 들렸다.

"팀장님, 팀장이 팀원들 업무를 다 파악하고 있어야 하는 거 아니에요? 기술적인 건 몰라도 된다고 생각하세요?"

"…죄송합니다."

"지금 프로젝트 막판인 거 알죠? 다음 주가 최종 릴리즈인데, 대행업체에서 문의 오면 팀장이 바로 답변할 수 있어야 하는 거 아니에요?"

"예."

"근데 담당자한테 물어봐야 안다고요?"

목소리가 한 톤 더 올라갔다.

"그럼 팀장님은 뭐 하는 사람이에요?"

가슴이 뜨거워졌다. 뭐라고 대답해야 할지 몰랐다. 지금 여기는 장인어른 댁이다. 거실에서는 장인어른께서 TV를 보고 계시고, 안방에서는 아이들이 아내랑 놀고 있다. 밥상에는 내 밥이 랩에 싸여 식어가고 있다. 온 가족이 모인 집인데 나만 다른 곳에 있는 것 같았다.

"바로 확인해서 연락드리겠습니다."

"그래요. 빨리요."

전화가 끊겼다.

핸드폰을 내려다보니 손에 땀이 나 있었다. 창밖으로 고층 아파트 창문 너머 다른 아파트 동들이 보이고 멀리 산이 보였다. 하늘은 맑았다. 평화로운 풍경이었는데 나와는 상관없는 풍경 같았다.

하 과장한테 전화를 걸었다. 신호음이 울렸다. 한 번, 두 번, 세 번. 받지 않았다. 네 번, 다섯 번. 음성 사서함으로 넘어갔다.

김 대리한테 전화를 걸었다. 두 번 만에 받았다.

"예, 팀장님."

"김 대리, 지금 통화 가능해?"

"예, 말씀하세요."

"API 응답 시간 이슈 있잖아. 특정 조건에서 3초 넘게 걸린다는 거. 그거 원인이 뭔지 알아?"

잠깐 침묵이 흘렀다.

"그건… 제가 맡은 파트가 아니라서 정확히는 모르겠습니다. 하 과장님이나 이 과장님 쪽 모듈인 것 같은데요."

"…그래."

전화를 끊고 다시 하 과장한테 전화를 걸었는데 역시 안 받았다. 문자를 보냈다. "하 과장, 전화 좀 부탁해요. 급한 건."

핸드폰을 쥐고 앉아 있었다. 방 안은 조용하고 시계 초침 소리만 들렸다. 똑. 똑. 똑.

5분이 지났다. 10분이 지났다. 답이 없었다.

방문이 살짝 열렸다. 아내였다.

"여보, 밥 먹어. 다 식겠다."

아내가 내 얼굴을 보고 말을 멈췄다. 나는 아무 말 없이 핸드폰만 쥐고 있었다. 아내는 뭔가 느낀 것 같았다. 고개를 끄덕이고 문을 닫더니 발소리가 멀어졌다.

핸드폰이 다시 울렸다. 부서장님이다. 20분밖에 안 지났는데.

"예, 부서장님."

"확인됐어요?"

"아직… 담당자가 전화를 안 받아서…"

"토요일인데 전화를 안 받아요?"

"…"

"팀장님이 평소에 팀 관리를 어떻게 하길래 주말에 전화도 안 받아요?"

목이 막혔다. 평소에 팀 관리. 그 말이 가슴에 박혔다.

내가 뭘 잘못한 건가. 토요일에 쉬라고 한 게 잘못인가. 처가댁 오기 전에 단톡방에 "이번 주는 푹 쉬어요"라고 올렸다. 석 달 동안 주말마다 나오게 해서 미안했다. 그게 잘못인가. 팀원들 편에 서면 부서장님한테 혼나고, 부서장님 뜻대로 하면 팀원들이 지쳐 나간다. 양쪽 사이에 서 있는데, 내가 설 자리는 없었다.

"죄송합니다. 다시 연락해 보겠습니다."

"그리고요, 팀장님."

부서장님 목소리가 잠깐 멈췄다. 본론을 꺼내기 전의 그 특유의 침묵이었다.

"내일 대행업체에서 개발팀이랑 같이 테스트하자고 연락 왔어요."

내일. 일요일이다.

"내일이요?"

"예. 릴리즈 전에 전체 기능 점검하고 싶다고. 지금 이슈도 있고 하니까, 팀원들 다 나와서 대응해야 할 것 같아요."

다 나와야 한다. 일요일에.

이번 주도 매일 야근했다. 팀원들한테 이번 주말만은 쉬라고 했다. 처가댁 오기 전에 단톡방에 올렸다. "이번 주는 푹 쉬어요." 그 메시지가 떠올랐다.

대답이 안 나왔다. 목구멍에 뭔가 걸린 것 같았다. 울컥했다. 참았다.

"…알겠습니다."

"내일 아침 아홉 시까지 와요. 대행업체 사람들도 그때 온대요."

"…예."

잠깐 침묵이 흘렀다. 내가 뭔가 더 말해야 할 것 같았다.

"그… 팀원들한테는 제가 한 명씩 전화해서 얘기해 보겠습니다."

"뭐요?"

"이번 주말은 쉬라고 제가 얘기했어서요. 갑자기 나오라고 하면…"

"팀장님."

부서장님 목소리가 날카로워졌다.

"지금 회사 일이 중요한 거예요, 팀원들 기분이 중요한 거예요? 나오라고 하면 나오는 거지, 왜 한 명씩 전화를 해요?"

"…"

"그렇게 하나하나 신경 쓰니까 팀원들이 주말에 전화도 안 받는 거 아니에요?"

얼굴이 화끈거렸다. 반박하고 싶었다. 그게 무슨 상관이냐고. 토요일에 쉬는 게 당연한 거 아니냐고. 하지만 입이 열리지 않았다.

"…알아서 하겠습니다."

"그리고요."

부서장님 목소리가 갑자기 부드러워졌다. 톤이 확 바뀌었다. 이런 전환이 더 무섭다.

"이번 프로젝트 끝나면요, 팀원들한테 넉넉하게 해줄게요. 고생한 만큼 보답할 테니까. 지금은 좀 참고 회사 목표에 집중해요. 알았죠?"

넉넉하게. 보답. 고생한 만큼.

그 말들이 귀에 맴돌았다.

속으로 희망회로를 돌려본다.

'끝나면 넉넉하게 해준다고 했으니까.' '아이들 데리고 여행 가자.' '며칠만 더 버티면 된다.'

"…예, 알겠습니다."

"그럼 내일 봐요."

전화가 끊겼다.

핸드폰을 내려놓았는데 손이 떨렸다. 다시 하 과장한테 전화를 걸었다. 신호음. 신호음. 안 받았다.

방문이 살짝 열리고 틈 사이로 작은 얼굴이 보였다. 딸이었다.

"…"

딸이 나를 쳐다봤다. 네 살짜리 눈이 동그랗게 떠져 있었다. 뭔가 말하려는 것 같았다. 아빠, 밥 먹어. 그런 말. 하지만 말이 나오지 않는 것 같았다. 내 표정을 보고 있었다. 평소와 다른 아빠 얼굴을.

나는 억지로 웃어 보려고 했는데 입꼬리가 올라가지 않았다.

딸이 문을 닫았다. 발소리가 멀어졌는데 뛰어가지 않고 천천히 걸어갔다.

가슴이 답답했다. 딸한테 무슨 표정을 보여준 거지. 네 살짜리가 아빠 표정 보고 그냥 돌아갔다. 뭔가 물어보지도 않고. 그 나이에 어른 눈치를 볼 줄 안다는 건, 그동안 내가 얼마나 자주 그런 표정을 보여줬다는 뜻일까.

다시 하 과장한테 전화를 걸었다. 이번에는 받았다.

"예, 팀장님."

"하 과장, 내일 출근 가능해?"

"…내일이요? 일요일인데요?"

"대행업체에서 테스트하자고 해서. 팀원들 다 나와야 할 것 같아."

전화기 너머로 한숨 소리가 들렸다. 길었다.

"팀장님, 저 내일 개인 일정이 있어서요. 한 달 전부터 잡아둔 거라…"

"…그래?"

"죄송합니다. 진짜 다른 날은 다 되는데, 내일은 어려워요."

"…알았어. 어쩔 수 없지."

전화를 끊었다.

김 대리한테, 이 과장한테, 정 대리한테, 윤 사원한테 차례로 전화했다. 다들 알겠다고 했다. 목소리에 피로가 묻어 있었다. 윤 사원은 "예"라고만 대답했다. 신입이라 거절을 못 하는 거겠지.

하 과장이 안 나온다고 했을 때 조금 고마웠다. 이상한 감정이다. 거절해도 되는 거라는 걸 보여준 것 같아서. 나는 왜 못 하지. 8년 전 스타트업 할 때는 안 된다는 말도 잘 했다. 언제부터 못 하게 된 건지 모르겠다.

방에서 나와 거실로 갔다. 장인어른께서 자리에 앉아 계셨다. TV가 켜져 있었는데 소리는 줄여 놓으셨다. 장모님께서 부엌에서 뭔가 하고 계셨다. 아이들 웃음소리가 안방에서 들렸다.

장인어른께서 나를 힐끗 보시다가 또 시선을 돌리셨다. 뭔가 물어보고 싶으신 것 같았다. 요즘 회사 어때, 바쁘지, 그런 말. 하지만 안 하셨다. 사위 눈치를 보고 계셨다.

그게 더 죄송했다. 장인어른께서 사위 눈치를 봐야 하는 상황이 됐다는 게.

"밥 먹을게요."

"그래, 앉아."

식탁에 앉아 랩을 벗겼다. 미역국이 식어 있었다. 장모님께서 부엌에서 나오셨다.

"데워줄까?"

"아닙니다. 그냥 먹을게요."

숟가락을 들어 밥을 입에 넣었는데 맛이 느껴지지 않았다. 장모님께서 정성껏 차려주신 건데. 젓가락질이 느려졌다.

장인어른께서 TV를 보고 계시고 장모님께서 부엌으로 들어가셨다. 나는 혼자 식탁에 앉아 식은 밥을 먹었다.

핸드폰이 또 울렸다. 주머니에서 진동이 느껴졌다. 밥상 앞이었다. 장인어른께서 계신데.

화면을 보니 부서장님이다.

"…죄송합니다. 잠깐만요."

일어나서 다시 방으로 들어갔다. 뒤에서 아무 소리도 안 들렸다. 장인어른도, 장모님도 아무 말 없으셨다.

문을 닫고 전화를 받았다.

"예, 부서장님."

"하 과장 연락됐어요?"

"예. 근데 내일 출근이 어렵다고 합니다. 개인 일정이 있어서…"

"뭐요?"

"한 달 전부터 잡아둔 일정이라고…"

"아니, 지금 그게 중요해요? 회사 일이 중요해요, 개인 일정이 중요해요?"

"…"

"하 과장이 담당하는 모듈에서 문제가 생긴 건데, 본인이 안 나오면 누가 해요?"

"다른 팀원들이 봐서…"

"다른 팀원들이 하 과장만큼 알아요?"

모른다. 그 모듈은 하 과장이 처음부터 끝까지 짰다. 다른 사람이 보려면 코드 파악하는 데만 반나절이다.

"팀장님이 다시 전화해서 나오라고 하세요."

"…예."

전화가 끊겼다.

하 과장한테 다시 전화를 걸었다. 세 번 만에 받았다.

"예, 팀장님."

"하 과장, 미안한데…"

"…"

"내일 좀 나와줄 수 있어? API 이슈가 하 과장 담당 모듈이라서. 부서장님께서…"

전화기 너머로 한숨 소리가 들렸다. 아까보다 더 길었다.

"…알겠습니다."

"미안해. 정말 미안해."

"괜찮습니다."

괜찮지 않다는 거 안다. 목소리에 다 묻어 있었다.

전화를 끊었다.

방 안이 조용했다. 창밖으로 저녁 노을이 보이고 고층 아파트 창문들이 주황빛으로 물들어 있었다.

이게 뭐 하는 짓인가 싶었다.

한 달 전부터 잡아둔 일정을 취소하게 만들고. 주말에 쉬라고 해놓고 다시 나오라고 하고. 팀원들한테 전화해서 죄송하다고 하고. 부서장님한테 전화받고 또 팀원들한테 전화하고.

나는 뭐 하는 사람인가. 팀원들한테는 미안하다고 하고, 부서장님한테는 알겠다고 한다. 그 사이 어딘가에 내 생각이 있을 텐데, 석 달째 한 번도 말한 적이 없다.

속으로 희망회로를 돌려본다.

'이번 프로젝트만 끝나면.' '넉넉하게 해준다고 했으니까.' '고생한 만큼 보답한다고 했으니까.'

그런데 그 불안감은 가시지 않았다. 부서장님 말을 믿어도 되나. 끝나면 정말 쉴 수 있나. 넉넉하게 해준다는 게 뭘까.

생각만 해도 피곤했다.

방문이 열렸다. 아내였다.

"여보."

"…응."

"아이들 아빠 보고 싶다고 하는데. 잠깐 나와."

"…응. 금방 갈게."

아내가 문을 닫았다.

일어나서 거실로 나갔다. 아이들이 뛰어왔다.

"아빠!"

큰애가 내 다리를 안고 작은애가 뒤따라왔다. 아까 방에서 내 표정 보고 돌아갔던 딸이다. 이번에는 웃고 있었다.

"아빠, 놀아줘."

"응. 놀아주지."

아이들 손을 잡았다. 따뜻했다.

내일은 또 회사에 가야 한다. 일요일인데. 팀원들도 나온다. 하 과장도 일정 취소하고 나온다. 대행업체 사람들이 온다. 부서장님이 내려다보고 있다.

그래도 지금은.

지금 이 순간만은.

아이들 손을 잡고 있으니까.

조금은 괜찮았다.

[수요일, 오전 9:31] 김 대리 - 사무실에서

끝났다.

어제 저녁 일곱 시에 최종 릴리즈를 완료했다. QA 통과, 스테이징 확인, 프로덕션 반영. 마지막 커밋 메시지를 "Final release v1.0.0"이라고 적었다. 엔터를 누르는 순간 손끝이 저렸다.

석 달이었다. 주말 출근, 야근, 새벽 퇴근. 그게 끝났다.

모니터를 봤다. 빈 화면에 커서가 깜빡거렸다. 뭔가 쳐야 할 것 같은데 칠 게 없었다. 석 달 동안 매일 코드를 쳤다. 아침에 출근하면 키보드에 손을 올리고, 밤에 퇴근할 때까지 코드를 쳤다. 손가락이 자동으로 움직였다. Ctrl+C, Ctrl+V. 복사, 붙여넣기. 변수명 바꾸기. 또 복사, 붙여넣기.

지금은 칠 게 없다.

터미널 창을 열어 git log를 쳤다. 커밋 히스토리가 쭉 올라왔다. 내 이름이 박혀 있는 커밋들. 석 달 동안 쌓인 것들.

스크롤을 내렸다. 커밋 메시지들이 눈에 들어왔다. "Fix bug", "Update feature", "Hotfix", "Fix bug again", "asdf". 다 비슷비슷했다. 뭘 고쳤는지 기억도 안 났다. 그냥 고치라고 해서 고쳤다. 버그가 나오면 잡고, 기능 추가하라면 추가하고.

입사 초기에는 커밋 컨벤션이 있었다. feat, fix, refactor. 접두어를 붙이고, 내용을 명확하게 적고. 그때는 다들 그렇게 했다. 지금은 아무도 신경 안 쓴다. 급하면 production 브랜치에 바로 푸시하기도 한다. 코드 리뷰 없이. 테스트 없이. 그냥 올리고, 문제 생기면 그때 고치고.

처음에 그걸 봤을 때 좀 놀랐다. 전 회사에서는 상상도 못 할 일이었다. 지금은 나도 그렇게 한다. 급하니까. 시간이 없으니까.

열 달 전에 이 회사에 입사했다. 대기업 계열사. 면접 때 기술 문화 얘기를 많이 들었다. 코드 리뷰가 철저하다고. 테스트 커버리지 80% 이상 유지한다고. 기술 부채 관리도 잘 된다고.

그래서 왔다. 여기라면 개발자로서 성장할 수 있을 것 같았다.

면접에 들어왔던 박 팀장님이 했던 말이 아직도 기억난다. "조직과 개발자의 성장을 최대한 일치시키기 위해 노력합니다." 그 말이 좋았다. 진심으로 들렸다. 지금도 그 말이 거짓이라고 생각하지는 않는다. 팀장님은 아마 진심이었을 거다. 그냥 현실이 안 따라주는 것 같다.

전 회사에서는 코드 리뷰에서 칭찬받았다. 설계가 깔끔하다고. 테스트 코드를 잘 작성한다고. 오픈소스 컨트리뷰션도 몇 번 했다. 유명한 라이브러리에 PR을 올렸다. 메인테이너가 "Great work!"라고 코멘트를 달았다. 며칠 뒤에 머지됐다. 그때 기분을 아직도 기억한다. 내 코드가 전 세계 개발자들이 쓰는 라이브러리에 들어갔다. 작은 기여였지만 의미가 있었다.

요즘은 퇴근하면 아무것도 안 한다. 예전에는 집에 가서도 사이드 프로젝트를 했다. 새로운 기술을 공부했다. 기술 블로그에 글을 썼다. 지금은 퇴근하면 침대에 눕는다. 유튜브를 틀어놓고 멍하니 본다. 뭘 봤는지 기억도 안 난다. 그러다 잠든다.

GitHub 잔디가 텅텅 비어 있다. 회사 계정 말고 개인 계정. 마지막 커밋이 언제였는지 기억도 안 난다. 입사하고 나서 한 번도 안 한 것 같다.

터미널 창을 닫았다. 빈 화면이 다시 나타났다. 커서가 깜빡거렸다.

고개를 들어 사무실을 둘러보니 다들 비슷했다. 이 과장이 의자에 기대앉아 천장을 보고 있었다. 뭔가 생각하는 건지 그냥 멍한 건지 모르겠다. 맞은편에서는 정 대리가 마우스를 느릿느릿 움직이고 있었다. 화면에는 메일함이 떠 있었다. 윤 사원은 자리에 앉아 있긴 한데 키보드에 손을 올리지 않고 있었다. 다들 뭔가 해야 할 것 같은데 뭘 해야 할지 모르는 표정이었다.

하 과장 자리를 보니 하 과장도 모니터를 멍하니 보고 있었다. 화면에 뭐가 떠 있는지는 안 보였다.

일요일에 하 과장은 못 나왔다. 개인 일정이 있다고 했다. 팀장님이 토요일 저녁에 단톡방에 올렸다. "부서장님 말씀으로는 프로젝트 끝나면 넉넉하게 챙겨주신다고 합니다." 그 메시지가 있어서 그나마 다들 나온 것 같았다. 없었으면 어땠을지 모르겠다. 일요일 아침에 사무실에 도착했을 때 다들 기분이 안 좋아 보였다. 당연하다. 주말인데.

대행업체 사람들이 아홉 시에 왔다. 전체 기능 테스트를 시작했다. 한 시간쯤 지났을 때 문제가 터졌다. API 응답 시간. 특정 조건에서 3초 이상 걸렸다. 대행업체 담당자 표정이 굳었다. 팀장님이 나를 불렀다. 하 과장 담당 모듈인데 하 과장이 없으니 내가 봐달라고.

하 과장은 원래 실력이 좋다. 입사했을 때 코드를 처음 봤는데, 하 과장이 짠 모듈은 구조가 깔끔했다. 변수명도 명확하고, 함수 분리도 잘 되어 있었다. 나중에 들었는데 예전에는 사내 기술 세미나에서 발표도 했다고 한다. 요즘은 그런 거 안 한다고 했다. 시간이 없어서.

그런 하 과장이 인덱스를 안 걸었다. 데이터베이스 쿼리 최적화. 기본 중의 기본이다. 하 과장 실력이면 당연히 아는 건데. 몰라서 안 한 게 아닐 거다. 그냥 시간이 없었겠지. 급하게 만들고, 테스트하고, 배포하고. 그 와중에 놓친 거겠지. 나도 그랬을 거다. 아니, 나도 그랬다.

밤새 코드를 뒤졌다. 원인을 찾았다. 인덱스 걸었다. 응답 시간이 3초에서 0.3초로 줄었다.

대행업체 사람들이 "오, 빨라졌네요"라고 했다. 그게 전부였다.

그게 엊그제 일이다. 이틀 전.

허전했다. 뭔가 남아야 할 것 같은데 남는 게 없었다.

하 과장이 기지개를 켜면서 말했다. 아까까지 모니터만 보고 있다가 처음으로 입을 열었다.

"야, 이제 휴가 언제 쓸 거야?"

이 과장이 천장 보던 시선을 돌리며 대답했다.

"부서장님이 넉넉하게 챙겨준다고 했잖아. 유급 휴가도 주는 거 아니야? 나 다음 주에 쓸까."

"나도. 석 달 만에 쉬는 거다."

정 대리가 끼어들었다. 메일함 화면을 끄고 의자를 돌렸다.

"보너스 나오는 거 아니에요? 석 달이나 고생했는데."

"당연하지. 안 그러면 뭘 넉넉하게 챙겨주겠다는 거야."

하 과장이 웃으면서 말했다. 일요일에 못 나온 것 때문에 요즘 분위기 띄우려고 애쓰는 것 같았다.

"부서장님이 넉넉하게 챙겨준다고 했잖아."

윤 사원도 슬쩍 이쪽을 쳐다봤다. 뭔가 물어보고 싶은 것 같았지만 입을 열지는 않았다. 신입이라 눈치를 보는 거겠지.

나도 기대하고 있었다. 솔직히. 돈 때문만은 아니다. 열 달 동안 뭘 했나 싶었다. 복사 붙여넣기. production 브랜치에 바로 푸시. 테스트 없이 배포. 그래도 열심히 했다. 밤새 디버깅하고, 주말에 나와서 남의 코드 고치고. 그게 의미 있었다는 걸 확인받고 싶었다.

열 시가 넘어서 팀장님이 부서장실에서 내려오셨다. 표정이 묘했는데 좋은 건지 나쁜 건지 읽기 어려웠다.

(Continue..)

승리하지 못하는 조직에게 미래는 없다

Tony Cho (https://flowkater.io) — Sun, 25 Jan 2026 00:00:00 GMT

들어가며

"근데 이제 알게 된 거죠. 아, 내가 너무 말을 잘하는구나. 그래서 같은 아이디어도 팀원들로 하여금 흥분되게 만드니까 잘못된 아이디어를 자꾸 몇 년을 투자하게 만들었었고, 잘못된 판단을 하는 주제에 내가 맞다고 생각하고."

토스 이승건 대표의 이 인터뷰를 처음 접했을 때, 한동안 멍하니 화면을 응시할 수밖에 없었다. 지나고 보니 나 역시 그런 리더였다. 그는 이어서 말한다. "성공하지 않으면 결국은 팀원들에게 너무 안 좋은 경험이구나." 그리고 덧붙인다. "아프지만 필요한 얘기를 할 때 개인도 기업도 크는구나... 받아들이는데 5년이 걸렸던 것 같아요."

이 문장들을 읽으면서 뼈저리게 공감했다. 성공한 기업가의 회고라기보다, 수많은 실패를 겪은 리더의 솔직한 고백처럼 들렸다. 우리는 흔히 '좋은 게 좋은 것'이라는 함정에 빠진다. 팀원들을 사랑하니까, 그들이 상처받을까 봐, 혹은 내가 나쁜 사람이 되기 싫어서 '아픈 소리'를 아낀다. 그런데 그 결과가 무엇인가? 조직은 서서히 침몰하고, 함께 배에 탔던 동료들은 '실패의 기억'만을 안고 뿔뿔이 흩어진다. 승리하지 못하는 조직에서 보낸 시간은, 아무리 그 과정이 화기애애했더라도 결국 독이 된다.

생각해보면, 우리는 왜 모였는가? 친목 도모를 위해서? 월급을 받기 위해서? 아니다. 우리는 무언가를 이루기 위해, 즉 '승리'하기 위해 모였다. 그런데 어느 순간부터 우리는 승리를 잊었다. 아니, 승리를 정의하는 법조차 잊어버린 것 같다. 우리가 쏟은 그 수많은 밤과 열정이 '실패'라는 단어 하나로 휘발되어 버린다는 건 참 서글픈 일이다.

AI 시대의 역설

지금은 AI의 시대다. 코딩은 AI가 도와주고, 디자인 시안은 몇 초 만에 쏟아진다. 데이터 분석도 예전처럼 며칠씩 걸리지 않는다. 도구는 비약적으로 발전했다. 생산성은 이론적으로 수십 배 올라갔어야 한다. 그런데 이상하다. 왜 조직이 겪는 본질적인 문제는 10년 전이나 지금이나 똑같을까?

기술은 빛의 속도로 변하는데, 사람이 모여 일하는 방식은 구석기 시대의 관성을 벗어나지 못하고 있다. 도구가 좋아졌다고 해서 조직이 똑똑해지는 건 아니다. 오히려 도구의 편리함 뒤에 숨어 본질적인 소통과 의사결정의 결함을 외면하기 쉬워졌다. 슬랙 메시지는 수만 개가 오가지만, 정작 "우리가 지금 어디로 가고 있는가?"에 대한 합의는 전무하다.

결국 문제는 도구가 아니라 '사람'과 '시스템'이다. AI가 코드를 짜줄 순 있어도, 우리 조직이 이번 분기에 반드시 따내야 할 '승리'가 무엇인지 정의해주지는 않는다. 그건 오롯이 우리의 몫이다. 그런데 우리는 그 정의를 내리는 대신, 더 화려한 도구를 도입하고 더 복잡한 프로세스를 만드는 데 에너지를 낭비한다.

나 역시 그랬다. 초기에 새로운 툴을 도입하면 조직의 문제가 해결될 거라 믿었던 적이 있었다. 노션을 쓰면 정보 공유가 잘 될 거라고, 지라를 쓰면 프로젝트가 체계적으로 돌아갈 거라고. 그게 얼마나 순진한 생각이었는지 깨닫는 데는 그리 오랜 시간이 걸리지 않았다. 툴은 문제를 해결해주지 않는다. 오히려 숨겨져 있던 문제를 더 선명하게 드러낼 뿐이다.

리더의 독단이라는 함정

다시 이승건 대표의 고백으로 돌아가 보자. 리더의 가장 큰 적은 외부의 경쟁자가 아니라, 바로 자기 자신의 '언변'과 '확신'이다. 리더가 말을 너무 잘하면, 팀원들은 비판적 사고를 멈춘다. 리더의 에너지가 너무 강하면, 잘못된 방향임에도 불구하고 조직 전체가 그 방향으로 전력 질주하게 된다.

이건 비단 C-레벨 리더만의 문제가 아니다. 시니어 개발자, 리드 디자이너, PM... 모든 레벨에서 "내가 맞다"고 생각하는 순간 함정은 파여진다. "내가 이 분야에서 10년을 일했는데", "내가 예전에 이런 방식으로 성공해봤는데"라는 경험의 저주가 조직의 눈을 가린다.

나도 CTO로 일하던 시절, 그런 독단에 빠졌던 적이 많았다. 지금 생각하면 얼굴이 화끈거린다. 특히 기억나는 건, 새로운 시스템을 설계할 때였다. 나는 마이크로서비스 아키텍처가 정답이라고 확신했다. 팀원 중 한 명이 "지금 우리 규모에서 굳이 MSA를 도입해야 할까요? 모놀리식으로 빠르게 가는 게 낫지 않을까요?"라고 물었다. 나는 그 질문을 '기술적 이해 부족'으로 치부했다. (지금 생각하면 정말 민망하다.) 내가 설계한 아키텍처가 정답이라고 믿었다. 결국 6개월을 투자해서 복잡한 시스템을 만들었는데, 정작 고객이 원하는 기능 하나 제대로 런칭하지 못했다. 그 팀원이 맞았다. 우리에게 필요한 건 우아한 아키텍처가 아니라 빠른 실행이었다.

내 언변은 팀원들을 '흥분'시켰을지 모르지만, 결과적으로 그들을 '잘못된 전장'으로 이끌었다. 리더의 독단은 조직의 잠재력을 억누르는 천장이 된다. 해외 스타트업 실패 사례를 분석한 연구에서 공통적으로 지적하는 대목이 있다. "When the leader becomes the primary doer or the ultimate reviewer, they inadvertently cap the organization's potential." 리더가 모든 것을 결정하고 검토하는 순간, 조직의 지능은 리더 한 명의 지능으로 수렴한다. 그건 승리하는 조직의 모습이 아니다.

시키는 것만 하는 조직

반대의 경우도 있다. 리더는 방향을 잃고, 팀원들은 '시키는 것만' 하는 상태다. 나는 이를 'n빵=1'의 문제라고 부른다. 10명이 모였는데 시너지는커녕 1명의 몫도 제대로 못 해내는 상태. 각자 자기에게 주어진 티켓은 깔끔하게 처리하지만, 그 티켓들이 모여 어떤 가치를 만드는지에 대해서는 아무도 관심이 없다.

나는 중간 관리자로서 내 팀원들과 목표를 기한내에 달성한 적이 있었다. 정해진 기한 내에 목표한 바를 구현했고 배포했고 목표했던 결과도 얻었다. 그런데 냉정하게 돌아봤을 때, 그 프로젝트가 회사의 성장에 기여한 바는 0이었다. 목표 자체가 잘못되었거나, 시장의 니즈와 동떨어져 있었기 때문이다. 그런데 나는 '내 할 일은 다 했다'는 안도감 뒤에 숨었다. 그건 비겁한 안도감이었다. 그리고 그 안도감은 곧 이유도 모르고 시키는 기능을 구현하느라 무작정 고생했던 팀원들에게 어떠한 보상으로 연결되지 않았고 팀 분위기는 철저하게 박살이 났다. 비극이었다.

이런 조직은 스포츠 팀으로 비유하자면, 수비수는 자기 구역만 지키고 공격수는 공이 오기만을 기다리는 팀과 같다. 골을 넣어야 이기는 게임인데, 아무도 골대를 향해 뛰지 않는다. 그저 감독이 시킨 위치에 서 있을 뿐이다.

"골을 넣는 게 목표라면 어디로 달려야 할지는 내가 판단하고 싶다."

이건 오만함이 아니다. 승리에 대한 갈망이다. 진짜 승리하고 싶은 선수는 경기 흐름을 읽고, 빈 공간을 찾아 스스로 움직인다. 감독의 전술은 가이드일 뿐, 필드 위에서의 최종 판단은 선수의 몫이어야 한다. 그런데 많은 조직이 팀원들의 이 '판단력'을 거세한다. "그냥 시키는 대로 하세요"라는 말 한마디가 조직의 승리 가능성을 짓밟는다.

팀원을 존중했지만 실패한 5년

그렇다면 팀원을 무한히 존중하고, 그들에게 모든 자율을 주면 승리할까? 토스의 초기 5년이 그 반례를 보여준다. 이승건 대표는 초기에 '정말 좋은 대표'가 되고 싶었다고 한다. 팀원들이 너무 고마워서 함부로 대하지 못했고, 항상 기회를 더 주려 노력했다. 결과는? 5년 동안의 연속된 실패였다.

실패가 확정된 순간, 그 '좋은 경험'들은 순식간에 '지우고 싶은 기억'으로 변했다. 팀원들은 "당신과 일했던 시간은 내 인생에서 지우고 싶다"는 차가운 반응을 보였다. 아프지만 이게 현실이다. 패배에 익숙해진 조직에서의 '친절'은 무책임의 다른 이름일 뿐이다.

나 역시 리더 시절, 비슷한 실수를 범했다. 한 팀원이 담당하던 프로젝트가 계속 지연되고 있었다. 그 팀원은 능력은 있었지만 업무 우선순위를 잡는 데 어려움을 겪고 있었다. 나는 그게 보였다. 그런데 팀 분위기가 나빠질까 봐, 그 팀원이 지쳐 보인다는 이유로 날카로운 피드백을 주저했다. "괜찮아요, 천천히 해도 돼요"라고 말했다. 실패가 예견되는 상황에서도 "우리는 잘하고 있다"는 근거 없는 낙관론을 펼쳤다.

3개월 후 프로젝트는 결국 접혔다. 그 팀원은 퇴사하면서 이렇게 말했다. "차라리 일찍 말해주셨으면 좋았을 텐데요. 제가 뭘 잘못하고 있는지 몰랐어요." 그때 깨달았다. 리더가 진정으로 팀원을 존중하는 방법은 그들을 기분 좋게 만드는 것이 아니라, 그들과 함께 '승리'하는 것이라는 걸. 진정한 존중은 때로 아픈 진실을 말하는 용기를 필요로 한다.

승리란 무엇인가

그렇다면 우리가 그토록 갈구해야 할 '승리'란 무엇인가? 단순히 매출 목표를 달성하는 것? 상장(IPO)을 하는 것? 물론 그것들도 승리의 지표가 될 수 있다. 그런데 본질적인 승리는 "조직원 전체가 결과에서 승리를 느끼는 것" 이다.

단순히 목표 숫자를 채우는 것이 아니라, 우리가 만든 제품이 세상에 나갔을 때 고객의 삶을 실제로 변화시키고, 그 과정에서 우리 모두가 "우리가 해냈다"는 압도적인 성취감을 공유하는 상태. 그게 진짜 승리다.

승리는 중독성이 있다. 한 번 승리의 맛을 본 조직은 다음 승리를 위해 스스로 움직인다. 반면, 패배에 익숙해진 조직은 패배의 원인을 외부에서 찾고 서로를 탓하는 데 익숙해진다. 승리는 조직의 모든 갈등을 잠재우는 최고의 치료제다. 물론 승리했다고 해서 모든 문제가 사라지는 건 아니지만, 적어도 문제를 해결할 동력은 생긴다. 승리는 조직에 흐르는 피와 같다. 피가 돌아야 생명이 유지되듯, 승리가 있어야 조직이 살아 숨 쉰다.

감독과 선수의 진짜 관계

승리하는 조직은 잘 훈련된 엘리트 스포츠 팀과 닮았다. 축구팀의 감독을 생각해보자. 감독은 상대 팀을 분석하고, 우리 팀의 강점을 살릴 전술을 짠다. 그런데 경기가 시작되면 감독이 필드 안으로 뛰어 들어갈 수는 없다.

필드 위에서 공을 잡은 선수는 0.1초 만에 판단해야 한다. 패스할 것인가, 드리블할 것인가, 아니면 슛을 쏠 것인가? 이때 선수가 벤치에 있는 감독의 눈치를 보느라 판단을 지체한다면, 그 팀은 절대 이길 수 없다.

승리하는 팀의 특징은 명확하다.

목표의 공유: 모든 선수가 "오늘 반드시 이긴다"는 목표에 정렬되어 있다.

역할의 전문성: 골키퍼는 골을 막고, 공격수는 골을 넣는다. 서로의 영역을 존중하되, 필요할 때는 기꺼이 돕는다.

현장의 자율성: 전술의 큰 틀 안에서 선수의 창의적 판단을 극도로 존중한다.

우리 조직은 어떤가? 리더가 필드 안까지 들어와 선수들의 발을 붙잡고 있지는 않은가? 아니면 선수들이 공이 어디 있는지조차 모른 채 멍하니 서 있지는 않은가? 승리하는 팀은 감독의 지시 없이도 유기적으로 움직인다. 그게 바로 시스템의 힘이다.

PM의 진짜 역할

여기서 PM(Product Manager)의 역할이 중요하다. 많은 조직에서 PM을 '요구사항 전달자'나 '일정 관리자' 정도로 취급한다. 그런데 승리하는 조직에서 PM은 '승리 설계자' 여야 한다.

PM은 단순히 기능을 나열하는 사람이 아니다. "이 기능을 만들면 왜 우리가 승리하는가?"를 증명해야 하는 사람이다. 기술적 제약과 비즈니스 목표, 그리고 고객의 니즈 사이에서 승리의 방정식을 찾아내야 한다.

나 역시 PM 역할을 수행하며 뼈저리게 느낀 것이 있다. PM이 승리를 정의하지 못하면, 개발자와 디자이너는 '의미 없는 노동'에 시달리게 된다. PM은 팀원들에게 "무엇을 만들어야 하는지"를 알려주는 사람이 아니라, "우리가 왜 이 싸움에서 이겨야 하는지"를 설득하는 사람이어야 한다. PM의 가장 큰 무기는 데이터나 기획서가 아니라, 팀을 승리로 이끌 수 있다는 '확신'이다.

포기할 줄 아는 용기

승리하지 못하는 조직의 공통점 중 하나는 '모든 것을 다 하려고 한다'는 것이다. 이것도 중요하고, 저것도 놓칠 수 없다. 결국 리소스는 분산되고, 어떤 전장에서도 승리하지 못한다.

승리하기 위해서는 '포기'할 줄 알아야 한다. 하나의 목표에 집중해야 승리든 실패든 명확한 경험을 할 수 있다. 어설프게 여러 개를 건드리다 실패하면, 왜 실패했는지조차 알 수 없다. "우리가 리소스가 부족해서 실패했나?"라는 비겁한 변명 뒤에 숨게 될 뿐이다.

가장 뼈아팠던 경험 중 하나가 이거다. 우리는 세 개의 신규 프로젝트를 동시에 진행했다. 인원은 한정되어 있었는데, 세 개 다 중요하다고 판단했다. 아니, 솔직히 말하면 어떤 걸 포기해야 할지 결정하기가 두려웠다. (결정을 미루는 것도 결정이라는 걸, 그때는 몰랐다.) 결과는? 세 개 다 중도에 흐지부지됐다. 하나에 올인했으면 적어도 하나는 성공시켰을 텐데, 욕심을 부린 대가였다. 그때 배웠다. 포기할 수 있어야 집중할 수 있고, 집중해야 승리할 수 있다. 리더의 가장 중요한 업무 중 하나는 "우리가 하지 말아야 할 일"을 결정하는 것이다. 이건 정말 어렵다. 그런데 반드시 해야 한다. 포기는 패배가 아니라, 더 큰 승리를 위한 전략적 후퇴다.

무너지는 조직의 징후

승리 없는 조직은 서서히, 그런데 확실하게 무너진다. 그 징후는 세 가지로 나타난다.

첫째, 인재 유출 이다. 유능한 인재는 승리의 냄새를 기가 막히게 맡는다. 반대로 승리의 가능성이 보이지 않는 조직에서는 가장 먼저 짐을 싼다. 회사를 떠나는 순간, 기술도, 전략도, 경쟁력도 함께 떠난다. 특히 유능한 인재는 "내가 이 조직에서 성장할 수 있을까?"를 끊임없이 자문한다. 승리 없는 조직에서의 성장은 불가능하다는 것을 그들은 본능적으로 안다. 유능한 인재는 돈을 따라가는 것이 아니라, 승리의 경험을 따라간다.

둘째, 리더의 고립 이다. 승리가 없으면 리더의 말에는 힘이 빠진다. 팀원들은 리더의 비전을 '공허한 외침'으로 치부하기 시작한다. 리더는 점점 더 강압적인 수단을 동원하게 되고, 이는 다시 팀원들의 반발을 불러오는 악순환에 빠진다.

셋째, 문화의 부패 이다. 승리라는 공동의 목표가 사라진 자리에 정치와 냉소가 들어앉는다. "어차피 안 될 텐데 적당히 하자"는 마인드가 조직 전체를 지배한다. 냉소는 조직을 갉아먹는 암세포와 같다.

외부 사례를 보자. 82%의 스타트업이 실패하는 이유는 자금 부족이 아니라, 나쁜 경영과 리더십 때문이다. 반면, 성공하는 조직은 다르다. 조지아의 TBC Bank는 OKR을 통해 1,200명의 조직을 하나의 목표로 정렬시켜 2024년 최고의 디지털 뱅크가 되었다. 국내의 쿠팡은 '로켓배송'이라는 도전적인 목표를 세우고 실시간으로 측정하며 승리를 쟁취했다. 카카오는 OKR 도입 후 프로젝트 속도가 1.5배 빨라졌고, 배달의민족은 팀 간 협업의 목적을 명확히 함으로써 승리의 기반을 닦았다. 이들은 모두 승리를 '정의'하고 '측정'했다. OKR이든 뭐든 좋다. 그런건 방법론에 불과하다. 중요한 건 조직에게 승리의 방향을 보여주고 있나? 아니면 조직이 승리의 방향으로 가고 있다고 느끼는가?

나가며

글을 마치며, 스스로에게 묻는다.

"나는 지금 승리하고 있는가?"

혹은 "내가 속한 조직은 승리를 향해 달려가고 있는가?"

승리는 우연히 찾아오지 않는다. 승리는 처절한 자기 객관화와, 아픈 피드백을 견뎌내는 용기, 그리고 "반드시 이기겠다"는 집요한 의지 끝에 얻어지는 것이다.

리더가 방향을 제시해야 한다는 반론이 있을 수 있다. 맞다. 리더는 방향을 제시해야 한다. 다만 "방향은 제시하되 과정은 자율을" 주어야 한다. 골대를 가리키는 건 리더의 몫이지만, 그 골대를 향해 어떤 드리블로 돌파할지는 선수의 몫이다.

승리를 정의하지 못한 조직에게 미래는 없다. 그저 과거의 실패를 반복하며 서서히 잊혀갈 뿐이다. 그런데 우리가 오늘부터라도 승리를 정의하고, 서로에게 아프지만 필요한 말을 건네며, 하나의 목표에 몰입한다면... 미래는 바뀔 수 있다. 승리는 선택이다. 그리고 그 선택은 지금 이 순간 우리의 손에 달려 있다.

승리를 위한 실천들, 그리고 다시 시작하는 마음

글을 마무리하려다 보니, "그래서 어떻게 해야 하는데?"라는 질문이 들릴 것 같아 몇 가지 구체적인 실천 방안을 덧붙인다. 이건 내가 5년동안 대표로서 회사를 직접 운영해보고 또 4년간의 CTO 생활을 통해 얻은 교훈들이다. 이론이 아니라 현장에서 깨지며 배운 것들이다.

1 on 1의 힘

조직이 커질수록 리더는 현장과 멀어진다. 이때 가장 강력한 도구는 1 on 1이다. 단순히 업무 진척도를 체크하는 자리가 아니다. 팀원의 고민이 무엇인지, 그가 생각하는 조직의 병목이 어디인지, 그리고 그가 이 조직에서 '승리'를 느끼고 있는지를 확인하는 자리여야 한다.

나는 내가 운영했던 조직에서 이 1 on 1을 소홀히 했던 것을 가장 크게 후회한다. 바쁘다는 핑계로 격주로 미루고, 결국 월간으로 흐지부지됐다. 그 사이 팀원들의 불만은 쌓였고, 나는 그걸 너무 늦게 알았다. 타이밍을 놓친 대화는 나중에 수십 배의 비용으로 돌아온다. 대화는 조직의 윤활유다. 윤활유가 마르면 엔진은 타버린다.

투명한 정보 공유

승리하기 위해서는 모두가 같은 지도를 보고 있어야 한다. 경영진만 아는 정보, 리더들끼리만 공유하는 맥락은 팀원들을 '소외된 노동자'로 만든다. 왜 이 프로젝트를 하는지, 현재 회사의 재무 상태는 어떤지, 우리가 직면한 진짜 위기가 무엇인지 투명하게 공유해야 한다. 정보의 비대칭은 불신을 낳고, 불신은 승리의 의지를 꺾는다.

실패의 회고, 승리의 축하

실패했을 때 비난하는 조직은 많지만, 제대로 회고하는 조직은 드물다. 왜 실패했는지, 다음에는 무엇을 다르게 할 것인지 기록하고 공유해야 한다. 마찬가지로 승리했을 때 충분히 축하하는 것도 중요하다. 작은 승리들이 모여 큰 승리의 문화를 만든다. 회고는 지혜를 낳고, 축하는 에너지를 낳는다.

고객에게 미치기

결국 모든 승리는 고객으로부터 온다. 개발자도, 디자이너도 고객의 목소리를 직접 들어야 한다. PM이 정리해준 문서만 보고 코드를 짜는 건 '대리 승리'일 뿐이다. 내가 짠 코드 한 줄이 고객의 문제를 어떻게 해결했는지 직접 목격할 때, 메이커는 진짜 승리를 경험한다. 고객은 우리의 유일한 북극성이다.

심리적 안전감과 높은 기준

팀원들이 실수해도 비난받지 않는다는 '심리적 안전감'이 있어야 도전적인 시도가 가능하다. 그런데 동시에 '높은 기준'이 유지되어야 한다. 안전하기만 하고 기준이 낮으면 조직은 정체된다. 반대로 기준만 높고 안전하지 않으면 조직은 타버린다. 이 두 가지의 균형을 잡는 것이 리더의 핵심 역량이다. 안전한 환경에서 높은 기준을 추구할 때, 최고의 성과가 나온다.

다시 시작하는 마음으로

큰 조직을 꾸리다가 다시 자연인(?)으로 돌아와 그때를 돌아보니, 남은 건 화려한 기술 스택이나 거창한 아키텍처가 아니었다. 결국 '사람'과 '승리' 그리고 '실패'에 대한 기억뿐이다. 함께 밤을 새우며 문제를 해결했던 동료들, 런칭의 기쁨을 나누며 맥주 한 잔을 기울였던 순간들... 그 모든 것들이 나를 만들었다. 분명히 행복했던 순간들이 있었다.

하지만 이런 노력들이 진정한 비즈니스 가치, 고객 가치로 전환되는 데는 실패했다. 결국 얼마나 오래, 얼마나 많이 일하는지로 사람의 능력과 로열티를 판단하게 됐다. 어떤 가치를, 어떤 비전을, 어떤 얘기를 해도 내 말은 더 이상 그들에게 존중받지 못했다. 그 '실패'의 기억은 지금도 뼈저리다.

그 당시에는 변명하고 싶은 마음도, 억울한 마음도 많이 있었지만 이제는 다시 앞으로 나아갈 때이다.

나는 이제 새로운 시작을 준비한다. 지난 과거의 실패와 성공을 거름 삼아, 다시 한번 '승리하는 조직'을 꿈꾼다. 이 글을 읽는 당신도 마찬가지일 것이다. 우리는 모두 각자의 전장에서 승리를 갈구하는 사람들이다.

나는 당분간 Ellie와 함께 2인팀에 집중하겠지만, 언젠가 다시 이전과 같은 다른 회사의 중간 관리자로 조직을 책임지게 된다면, 과정에 대한 자율이 보장받고 결과에 대한 책임만을 묻는 조직, 승리에 대한 방향성을 모두에게 명확하게 전달할 수 있어 골대를 향해 모두가 알아서 움직일 수 있는 그런 조직을 책임지고 싶다.

부디 당신의 조직이, 당신의 팀이, 그리고 당신 자신이 오늘 하루 승리하기를 진심으로 바란다. 승리하지 못하는 조직에게 미래는 없지만, 승리를 향해 나아가는 우리에게는 무한한 가능성이 열려 있다.

결국, 승리는 포기하지 않는 자들의 몫이다.

"Winning solves everything." 승리는 모든 것을 해결한다.

— 타이거 우즈

2025년 회고를 이 글로 대신한다. 나에게 2025년은 리커버리의 시간이었다. 안식년에 가까웠을지도 모른다. 오래전에 쓰다 덮어놓았던 글이 있었다. 너무 네거티브하고 블레임으로 가득 차서 차마 발행하지 못했던 글. 지금 시점에서 다시 닦고 닦아 내가 앞으로 나아가기 위한 글로서 발행한다. 이 글이 나에게 힐링이 되었듯, 여러분에게도 그랬으면 좋겠다.

종교는 없지만, 신이 있다면 항상 기도하고 싶다. "저에게서 타인에 대한 노여움을 거둬주시고, 그들을 포용하며 이해하고, 제 내면을 마주하고 다시 한걸음 나아갈 수 있는 용기를 주소서"

AI 시대의 MVP - Linear에서 배운 제품 개발의 원칙

Tony Cho (https://flowkater.io) — Tue, 20 Jan 2026 05:30:00 GMT

들어가며

대충 만든 제품은 죽는다. AI가 개발 비용을 바닥까지 끌어내린 지금, 누구나 빠르게 만들 수 있으니까 오히려 뭘 만드느냐가 전부가 됐다. Product Market Fit은 마케팅 없이도 팔릴 수준이어야 한다. 우리의 MVP는 그 수준인가?

솔직히 Thread를 보다 보면 1인 개발자들이 마케팅에 허덕이는 장면을 자주 본다. "개발은 AI가 해주니까 마케팅이 전부다"라는 주장도 있고, 어느 정도 공감한다. 하지만 그걸 마케팅이라고 퉁치는 건 무책임하다. 마케팅이라는 단어 안에는 콘텐츠, 퍼포먼스, 세일즈, 그리고 이 글에서 다루는 고객 개발까지 전부 들어 있다고 본다.

고객 개발, MVP 개발을 하는 시기에 Linear의 사례를 보고 공부가 많이 되었다. 초기 SaaS를 만들 때 정말 필요한, 아주 실용적인 내용이라 정리해보고 싶었다. 특히 요즘 읽고 있는 '해결 할 프로덕트'와 Linear 창업자 Tuomas Artman의 글에서 겹치는 부분들이 있어서 흥미로웠다.

현대의 MVP는 다르다

"Building something valuable is no longer about validating a novel idea as fast as possible. Instead, the modern MVP exercise is about building a version of an idea that is different from and better than what exists today."

— Tuomas Artman, Linear

Linear 창업자는 명확히 말한다. 더 이상 MVP는 "빨리, 싸게 아이디어를 검증하는 것"이 아니라고.

2011년 Eric Ries의 '린 스타트업'에서 정의한 MVP는 "최소한의 노력으로 최대한의 검증된 학습을 얻는 버전"이었다. 그때는 Airbnb가 "낯선 사람의 집에서 자도 될까?"를 검증해야 했고, Lyft가 "라이드 셰어링이 정말 작동할까?"를 테스트해야 했다. 아이디어 자체가 신규 카테고리였으니까.

하지만 지금은 어떤가. 대부분의 카테고리는 이미 포화 상태다. 누군가는 이미 만들었고, 누군가는 더 잘 만들었다. 그래서 새로운 제품이 살아남으려면 "아이디어를 검증"하는 게 아니라 "기존 제품보다 낫다는 걸 증명"해야 한다.

이 차이는 엄청나다. 검증 단계에서는 형편없는 프로토타입도 괜찮다. 하지만 경쟁 상태에서는? 사용자가 이미 다른 선택지들을 알고 있을 때? 당신의 제품은 훨씬 좋아야 한다.

"빨리 만들자"는 조언은 더 이상 충분하지 않다. Linear가 배운 것처럼, 지금의 MVP는 "치열하게 다듬은 경쟁력 있는 제품"이어야 한다. 그리고 그렇게 되려면 처음부터 무엇을 만들 것인지를 명확히 해야 한다.

타겟 좁히기의 힘

Linear가 택한 전략은 단순했다.

회사의 비전은 "소프트웨어가 어떻게 만들어지는지의 표준이 되자"였다. 엄청난 야심이다. 하지만 MVP 단계에서 모든 개발자, 모든 팀을 대상으로 하려고 했다면? 실패했을 것이다. 리소스도 부족하고, 피드백도 산만했을 테니까.

그래서 Linear는 타겟을 극도로 좁혔다. "작은 스타트업의 Individual Contributor(IC)들". 더 구체적으로는 "이슈 트래킹에 고민 있는 작은 팀의 엔지니어들".

그리고 초점을 세 가지로 집중했다:

Fast: 로컬 스토리지, 페이지 리로드 없음, 오프라인 작동
Modern: 키보드 숏컷, 커맨드 메뉴, 컨텍스트 메뉴
Multiplayer: 실시간 동기화, 팀원 presence

흥미롭게도, Linear 창업자는 자신들이 바로 이상적인 고객이었다. "우리를 위해 만들어보자"는 전략이었다.

내가 처음 스타트업에 시작했을 때 비슷한 고민을 했었다. 그리고 분명히 처음에는 타겟 고객만 생각하고 서비스를 만들었고 초기에 준수한 지표로 투자까지 받았었다. 하지만 투자 이후 성장 정체기가 찾아오며 서비스의 핵심 타겟을 생각하기보다는 외연을 늘리기 위해서 계속해서 유저들이 요청하는 기능을 추가했다. 밤을 새서 만든 기능이 있어도, 아침이 되면 한숨만 나왔다. 지표는 움직이지 않았고, 고객도 원하지 않았다.

돌이켜보니, 가장 먼저 해야 할 일은 "우리가 정말 사랑하는 고객이 누구인가"를 정의하는 것이었다.

그런데 여기서 주의할 점이 있다. Linear가 선택한 "작은 스타트업의 IC"는 단순히 좁은 범위가 아니었다. 그것은 강력한 동기와 높은 기대를 가진 고객이었다. 번역하자면, "문제가 있다는 걸 알고, 해결책을 찾고 있던 사람들"이었다는 뜻이다.

'해결 할 프로덕트'의 핵심 가르침도 이것이다. 고기대 고객(High-Expectation Customer) 을 찾는 것이다. 당신의 제품이 선택지가 아니라 생명줄 같은 느낌의 고객 말이다. 마치 특정 약물이 없으면 못 사는 환자처럼, "이게 없으면 진짜 문제가 된다"고 느끼는 그런 고객 말이다.

피드백 루프와 대기자 명단의 전략

Linear의 두 번째 레슨은 대기자 명단(Waitlist)을 어떻게 사용하는지였다.

많은 스타트업이 대기자 명단을 "마케팅 채널"이나 "사용자 수 증가 수단"으로만 생각한다. 하지만 Linear는 다르게 생각했다. 대기자 명단은 "제품을 다듬는 숫돌" 이었다.

구체적으로 Linear는:

대기자 명단 가입 시 구체적인 질문을 했다:
- 회사 규모는?
- 당신의 역할은?
- 현재 뭘 쓰고 있나?
- 현재 도구의 불만은?
피드백에 응답할 수 있을 사람들부터 초대했다. Linear는 GitHub 연동만 가능했으므로, GitHub 쓰는 작은 스타트업 창업자들부터 시작했다.
피드백을 듣고 반복했다. "새 기능 요청"이 줄어들 때까지 현재 기능을 다듬었다.
안정화되면 다음 세그먼트를 초대했다.

이게 왜 중요한가. 왜냐하면 잘못된 고객의 피드백은 제품을 망가뜨리기 때문이다.

'해결 할 프로덕트'에서 경고한다. "모든 피드백의 평균은 끔찍한 제품으로 이어진다." 이건 비판이 아니라 수학이다. 서로 다른 니즈를 가진 100명의 피드백을 모두 수렴하려고 하면, 당신의 제품은 평균 제품이 된다. 평범한 제품이 된다.

거꾸로, 지나치게 좁은 피드백 그룹만 들으면? "너무 특이한 사람들만을 위한 제품"이 된다. 그래서 균형이 필요하다.

결국 가장 효과적인 방식은:

명확한 기준으로 초기 고객 선정하기 (우리의 타겟이 명확한가?)
그 그룹과 깊게 대화하기 (많은 사람 vs 소수와 깊은 이해)
같은 패턴의 피드백만 반영하기 (일회성 요청이 아니라 반복되는 문제)

결론적으로 고객 세그먼트를 제대로 나누고 정의하는 게 정말 중요하다고 본다. 조각가가 대리석에서 불필요한 부분을 떼어내며 본질을 드러내듯, 세그먼트 안에서도 핵심만 남기고 나머지는 과감히 제외해야 한다.

고기대 고객을 찾는 과정

그렇다면 어떤 고객이 "고기대 고객"일까?

Linear의 창업자 Tuomas는 직접 고객을 만나 물었다:

"Linear가 없으면 어떻게 될 것 같아?"
"Linear의 가장 큰 도움이 뭐야?"
"어떻게 더 나아질까?"

그리고 "없으면 진짜 아쉬울 것 같은" 고객들이 초기 그룹이었다.

역으로 말하면, 단순히 "편할 것 같아서" 쓰던 고객은 대기자 명단에서 빼도 된다. 사실은 마음이 없던 고객이고, 더 좋은 대안이 나오면 금방 떠난다. PMF(Product Market Fit)를 찾는 단계에서는 "사랑하는 고객"이 필요하다. 좋아하는 고객이 아니라 사랑하는 고객 말이다.

여기서 당연히 이런 질문이 떠오를 것이다. "아직 제품도 없는데, 어떻게 그런 고객을 미리 찾을 수 있나?"

핵심은 제품이 아니라 기회(Opportunity) 에서 시작하는 것이다. 제품은 결국 고객의 문제나 욕구를 해결하기 위한 솔루션이다. 그렇다면 제품이 나오기 전에도, 그 문제를 절실하게 느끼고 있는 사람들은 이미 존재한다. 바로 그들을 먼저 찾아야 한다.

구체적으로는 이런 흐름이다. 우리가 해결하려는 기회를 정의하고, 그 기회를 실제로 겪고 있는 고객군을 찾아 나선다. 그들과 대화하고, 그들의 맥락을 이해한다. 그리고 MVP를 그들 손에 쥐어주는 순간, 이 사람들이 "고기대 고객"이 될 수 있는지를 알게 된다. 제품 전에 고객이 있고, 고객 전에 기회가 있다.

'해결 할 프로덕트'은 이를 더 구체적으로 설명한다. 고기대 고객은:

당신의 제품의 핵심 장점을 인정하는 사람
자신의 문제를 해결하려는 강한 동기가 있는 사람
제품에 높은 기대를 걸고 있는 사람

쉽게 말해, "이게 하나의 해결책이 아니라 그들의 유일한 희망처럼 느껴지는 사람"이다.

내 경험에서도 이게 맞는 말이라 느꼈다. 초기에 우리 제품을 쓰던 고객 중에서, 정말 돈을 내고 계속 썼던 고객들은? 거의 예외 없이 "이거 없으면 진짜 문제야"라고 말하던 사람들이었다. 단순히 "편할 것 같아서" 쓰던 사람은 더 좋은 대안이 나오면 떠났다.

그래서 초기에 할 일은:

고기대 고객 5명을 찾기
그 5명을 정말 행복하게 만들기
나머지 100명이 원하는 걸 무시하기 (초기에만)

냉정하게 들릴 수 있지만, 이게 성공 확률을 높이는 유일한 방법이다.

잠깐 B2B SaaS 를 주로 하던 회사에서 일했던 경험이 있다. 회사 대표는 "잠재 고객"에게 영업을 했고, "잠재 고객"들은 "이 기능"만 있으면 구매하겠다고 했다. 월 만원 짜리 기업 고객을 위해 완전히 새로운 피쳐를 3주동안 팀이 개발하기도 했다. 당시에는 이게 맞는 방법이라고 생각했다. MRR 영향도는 0%. 결국 그 회사 고객만을 위한 피쳐가 되었고, 다른 영업 기회는 오지 않았다.

내가 국내에서 B2B SaaS 회사들을 겪어보며 느낀 건 초기엔 제품에 대한 신념이 있었는데, 투자 이후 어느새 외주처럼 변해있는 회사들이 많았다. (잠재) 고객의 니즈를 따라다니다 보니 자신들의 정체성을 잃어버린 것이다. 국내 시장이 작아서 핵심 고객 풀이 훨씬 작다는 현실도 있겠지만, 내 제품을 진정 사랑하는 고객만을 만족시키기 위해 다른 걸 선택하지 않고 정면 돌파하는 것이 바로 성공의 길이다.

'해결 할 프로덕트'에서도 언급하지만 "잠재 고객"은 "고객"이 아니다. 내 제품을 본인의 비용을 지불하고 쓰는 고객이 진정 "고객"이다. 가끔 우리가 너무 많은 "잠재 고객"의 피드백에 휘둘리고 있는건 아닌지 생각해보자. (타겟 고객이 아닌 당신의 친구, 가족 모두 포함이다. 하지만, 그들이 우리 제품에 돈을 내고 매일 쓰고 있다면, 그들의 말에 귀기울일 필요가 있다.)

현대 MVP의 핵심 메시지

Linear의 사례와 '해결 할 프로덕트'의 가르침을 정리하면, 현대의 MVP는 이렇다:

아이디어 검증이 아니라 경쟁 제품 만들기 - 빨리가 아니라 다듬기
타겟 극도로 좁히기 - "모두를 위한" 포기하기
피드백 루프를 전략적으로 관리하기 - 모든 의견을 듣는 게 아니라 패턴 찾기
고기대 고객 중심 - 많은 사람이 "좋아"하는 것보다 소수가 "사랑"하는 것
마케팅 없이도 팔릴 수준까지 - PMF는 마케팅이 아니라 제품의 증거

특히 최후의 기준은 명확하다. 당신의 제품이 정말 PMF를 찾았다면, 마케팅을 하지 않아도 입소문이 난다. 고기대 고객들이 주변에 자꾸만 말하고 싶어 하는 그런 상태.

AI 시대, 결국 남는 질문

개발 속도가 빨라졌을수록, 무엇을 만들 것인가가 중요해진다. AI 덕분에 아이디어만 좋으면 누구나 빨리 만들 수 있는 시대다. 그래서 경쟁 우위는 더 이상 구현 속도가 아니라, 더 명확한 타겟과 더 깊은 고객 이해, 그리고 50%를 지울 용기에 있다.

나가며

솔직히 처음에는 "MVP"라는 단어가 많이 답답했다. "최소한"이라는 표현이. 하지만 지난 시간을 돌이켜보니, 그 "최소한"은 사실 최대한의 선택이었다.

Linear의 이야기를 따라가면서 깨달은 건 이거다: 마케팅 없이 팔리는 제품을 만들어야 한다는 것.

그런데 그게 어떻게 가능할까? 답은 우리가 위에서 다룬 것들 안에 있다.

먼저 "모든 사람을 위한 제품"이라는 환상을 버려야 한다. 대신 아주 좁은 타게팅으로 고기대 고객들을 찾아야 한다. 모든 사람을 위한 옷을 입히려는 게 아니라, 한 사람을 위한 핸드메이드 옷을 완벽하게 만드는 것처럼. 구체적인 사람 3~5명을 상상하고, 그들이 진짜 필요해하는 게 뭐인지를 명확히 하는 것. "모두를 위한"이 아니라 "이 사람을 위한 제품"으로 질문을 바꾸는 순간, 당신의 제품은 방향성을 얻는다.

그 다음은 용기다. 피드백이 쏟아질 때, 당신은 선택해야 한다. 가족과 친구의 의견은 배제하고, 실제 고객의 목소리만 듣기. 그리고 같은 문제가 3번 이상 나올 때만 해결하기. 한 사람의 요청은 특수하지만, 패턴은 일반이기 때문이다. 모든 피드백을 반영하는 것이 아니라, 방향을 유지하는 게 훨씬 중요하다.

그리고 가장 핵심은 이거다. 당신의 제품을 잃으면 진짜 실망할 그런 고객들을 찾고, 그들을 완벽하게 만족시키는 데만 집중하는 것. 다른 고객들의 의견은 나중이다. 초기에는 고기대 고객 5명을 위해서 당신의 모든 에너지를 쏟아야 한다. 그들이 "없으면 진짜 아쉬울 것 같은데"라고 말할 때, 당신은 PMF를 찾은 것이다.

이 과정에서 핵심은 선택과 집중이다. "이것 없으면 핵심 가치 전달 안 되는 건?"이라는 질문으로 기능의 50%를 과감히 지울 수 있어야 한다. 대리석의 여분을 떼어내 조각상을 만드는 것처럼, 불필요한 것들을 제거하면서 본질이 드러나는 과정이다. Linear도 처음엔 엄청 많은 기능을 넣으려고 했을 거다. 하지만 그들은 필요 없는 것들을 제거했다. 이게 바로 경쟁력이 되었다.

AI가 개발 속도를 빠르게 해주는 시대일수록, 이런 선택과 집중이 더 중요해진다. 기술적 어려움은 이미 해결했으니까.

개발 비용이 AI 덕분에 저렴해지는 이 시대, 남은 건 단 하나다.

"누구를 위한 제품을 만들 것인가"

마케팅이 아니다. 확장이 아니다. 결국 우리가 고민해야 하는 것은, 정말로 누구를 위한 제품을 만드느냐는 것이다.

이 과정에서 당신이 해야 할 일들은 명확하다:

핵심 원칙	실행 방법
마케팅 없이 팔릴 수준까지	제품 자체가 증거가 되도록 다듬기
아주 좁은 타게팅	구체적인 고객 3~5명 정의하기
고기대 고객 중심	사랑하는 고객만 완벽하게 만족시키기
피드백은 전략적으로	패턴이 반복되는 것만 반영하기
50%를 지울 용기	핵심 가치 없으면 삭제하기

"The smallest team with the strongest clarity will always beat the largest team with the most confusion."

가장 명확한 작은 팀이 가장 혼란스러운 큰 팀을 항상 이긴다.

같이 읽으면 좋을 책

해결 할 프로덕트 (라비 메타 저 / 이용빈 역) — 고기대 고객과 기회 중심 사고를 구체적으로 풀어낸 책. 이 글의 절반은 여기서 왔다.
Continuous Discovery Habits (Teresa Torres) — 고객과의 지속적 대화를 습관으로 만드는 프레임워크. 피드백 루프를 체계화하고 싶다면 필독.

References

Thanks to Ellie. 이번 글은 "해결 할 프로덕트" 스터디 자료를 준비해 온 Ellie 의 독서 노트에서 영감을 받았다.

(픽션) 허공을 미는 사람들 - 에피소드 1, 석 달째.

Tony Cho (https://flowkater.io) — Mon, 19 Jan 2026 12:32:33 GMT

이 작품에 등장하는 모든 인물, 이름, 집단, 사건은 허구이며 실존하는 것들을 기반으로 하지 않았습니다.

Author: flowkater

에피소드 1: 석 달째

[오전 10:17] 박 팀장 - 부서장실에서

부서장님께서 호출을 했다.

요즘 팀원들의 불만이 이만저만이 아니다. 석 달째 야근이다. 주말에도 나왔다. 지난주에는 하 과장이 나를 찾아왔다. 회의실 문을 닫고 앉자마자 "팀장님, 솔직히 말씀드려도 될까요"라고 했다. 솔직히 말하겠다는 사람치고 좋은 얘기 하는 사람 못 봤다. 예상대로였다. 일정이 너무 빡빡하다, 이러다 다 쓰러진다, 이번 주말에도 나오라는 건 아니죠. 나는 고개를 끄덕이면서 들었다. 뭐라고 대답해야 할지 몰랐다. 나도 같은 생각이니까.

하지만 그래도 주어진 기한 내에는 어느 정도 완료는 할 수 있을 것 같다. 팀장으로서 팀원들에게 미안한 마음도 있지만, 그래도 나름 리더십을 발휘해서 한 명 한 명 얘기도 해보고, 혼도 내고, 달래도 가면서 일정을 푸시하고 있다. 리더십이라고 하기엔 좀 웃기다. 그냥 사정하는 거다. 제발 조금만 더 해달라고.

일정은 어찌저찌 맞춰질 것 같으니 큰 걱정 없이 부서장실로 들어갔다.

부서장실 문을 열기 전에 심호흡을 한 번 했다. 습관이다. 이 문을 열면 다른 사람이 되어야 한다.

"팀장님, 별일 없지요?"

내가 인사하기도 전에 부서장님은 먼저 안부를 묻는다. 프로젝트 일정의 특이사항을 묻는 것이다. 부서장님은 서류를 보면서 말했다. 나를 쳐다보지 않는다. 항상 그렇다. 평소 대화할 때는 상대방 눈을 안 본다. 모니터나 서류를 본다. 그게 더 불안하다.

"아, 예, 부서장님. 별일 없습니다. 지난번 말씀드린 일정을 지키기에는 전혀 문제없습니다."

"아, 그래요? 생각보다 문제가 없나 보군요."

부서장님이 고개를 들어 나를 봤다. 안경 너머로 눈이 보였다. 웃는 것 같기도 하고 아닌 것 같기도 하다. 나는 안도했다. 일단 첫 번째 관문은 통과한 것 같았다.

"근데, 팀장님."

부서장님이 서류를 내려놓고 두 손을 깍지 끼고 책상 위에 올렸다. 이 자세. 뭔가 얘기할 게 있다는 자세다.

"지난번에 기한 내에 못 한다고 제외한 기능 말이죠."

심장이 한 박자 빨라졌다. 설마.

"아, AI 기능과 통합하는 그 기능 말씀이신가요?"

"예, 그거요."

불안하다. 왜 갑자기 그 얘기를 꺼내는 거지. 분명히 그건 제외하기로 했다. 회의록에도 남겼다. 메일로도 공유했다.

"그거 혹시 이번 기한에 같이 넣어줄 수 있을까요?"

나는 재빠르게 대답했다.

"아니, 그건 부서장님. 지난번 논의와 협의를 통해서 다 같이 이번 기한에 중요도도 떨어지고, 그래서 일단 제외하기로 했습니다. 그리고 지금 시간이 얼마 남지 않아서…"

"중요도요?"

부서장님이 내 말을 끊었다. 목소리가 한 톤 올라갔다. 아니, 올라간 건 아닌데 뭔가 날카로워졌다.

"중요도가 떨어지는 게 아니라, 팀장님께서 팀원들 역량으로는 당시에 기한 내에 못 할 것 같다고 하셨잖아요."

"…"

"그런데 확실히 푸시하니까 되는 것 같아서, 이것까지는 완성하는 게 좋을 것 같습니다."

푸시.

부서장님은 그렇게 말했다. 석 달 동안 팀원들이 매일 밤 열 시, 열한 시까지 남아 있는 걸. 주말에도 나와서 일하는 걸. 부서장님 입에서 나온 건 그냥 그 한 단어였다. 푸시.

"아니, 그때 분명히 그 부분은 제외하기로 했고, 그건 저희 팀원들 역량이 아니라… 중요도 때문에…"

"중요도가 안 중요하다는 말은 저는 그때 동의하지 않았습니다."

부서장님은 의자에 등을 기대며 말했다. 여유로운 자세였다. 나는 서 있었다. 앉으라는 말을 안 했으니까.

"혹시 팀장님도 중요도가 많이 떨어진다고 생각하세요? 저는 저희 이번 프로젝트에서 이 부분도 중요하다고 생각합니다."

"…"

나는 대답하지 않았다. 요즘 이상한 습관이 생겼다. 상대방의 말이 안 통하면 가끔 그 말을 듣고도 대답하지 않는다. 집에서 아내와 아이들이 나에게 무얼 물어볼 때도 멀뚱멀뚱 대답을 하지 않는다고 몇 번 잔소리를 들었다. 아빠 왜 대답 안 해, 하고 큰애가 내 팔을 흔들 때서야 정신이 든다.

중요도를 물어보고 싶은 마음이 굴뚝같다. 왜 중요한데요. 누가 중요하다고 했는데요. 그 기능이 없으면 뭐가 문제인데요. 실제로 쓸 고객이 있긴 한 건가요.

어차피 물어봐야 소용없다. 사실 이번 프로젝트의 목표가 무엇인지, 우리가 하는 파트가 어디 부분에 기여하는지를 잘 모르기 때문에 중요도를 판단하는 것도 어렵다. 그 부분은 부서장 담당이다. 우리는 부서장이 정해준 솔루션을 그대로 구현하고 있다. 고객이 누군지도 모른다. 소프트웨어 구매를 대행해 주는 업체가 있고, 그 업체에서 이런 기능이 있어야 한다고 했다는 것이다. 실제 사용자가 뭘 원하는지는 아무도 모른다. 어딘가에 있겠지. 아니면 없을 수도 있다. 그런 것을 위해 석 달째 야근을 하고 있다.

그리고 여기서 중요도에 대해서 다시 따져 봐야 오늘 날짜 안에 퇴근할 가능성이 급격히 희박해질 것 같았다.

억지로 정신을 차리고 대답했다.

"…저도 중요하다고 생각합니다. 팀원들이랑 논의해서 말씀드리겠습니다."

내 목소리가 공허하게 울렸다.

"예, 좋습니다."

처음으로 부서장님의 표정이 밝아졌다. 내 마음은 더욱 어두워졌다.

"팀장님, 이제 좀 저희가 같은 목표를 가지고 일하는 것 같네요. 팀원들이 지금보다 훨씬 더 헌신한다면 분명히 다른 부분까지 추가로 해낼 수 있을 거라 봅니다."

헌신. 또 그런 단어다.

속으로 생각한다.

'헌신이 뭔데.' '석 달째 야근하고 주말에 나오는 게 헌신이 아니면 뭔데.' '더 하라는 건가.'

부서장은 다시 서류를 집어 들었다. 나를 쳐다보지 않고 본인의 자리에서 자신의 서류와 컴퓨터 모니터를 보면서 얘기를 한다. 면담이 끝났다는 신호다.

"팀원들은 지금도 이미 열심히 하고 있습니다."

아차.

왜 이 말이 나왔지. 참으려고 했는데. 내 표정은 이미 굳어 있다.

부서장은 서류에서 눈을 떼고 어느새 내 눈을 쳐다보고 있다. 안경 너머로. 중요한 순간에만 눈을 마주친다. 몇 초간의 침묵이 흘렀다.

"그래요?"

한 마디였다. 그 한 마디 안에 많은 것이 담겨 있었다. 정말요? 제가 보기엔 아닌데요. 팀장님이 팀원들을 제대로 관리하고 있는 건 맞나요.

나는 표정을 풀었다. 억지로 풀었다.

"더 열심히 해보겠습니다."

부서장은 고개를 끄덕이며 다시 서류를 봤다.

"그래요, 저도 다음 스케줄이 있어서."

나는 후다닥 부서장실을 나왔다. 문을 닫는 순간 다리에 힘이 풀려서 복도 벽에 잠시 기대섰다. 지나가는 사람이 이상하게 쳐다봤다. 신경 쓸 여유가 없었다.

우리 사무실은 부서장실 층에서 2층 아래에 있다. 많은 차이는 아니지만 워낙 큰 건물이다 보니 대개 사람들은 엘리베이터를 타고 다닌다. 엘리베이터 앞에 섰는데 버튼을 누르려다가 멈췄다.

지금 사무실에 내려가면 팀원들에게 뭐라고 말해야 하지. AI 기능 다시 넣어야 한대. 일정은 그대로고. 어떻게 말하지.

스타트업 하다가 망하고 들어온 회사다. 8년이 됐다. 그때는 직원 네 명짜리 사무실에서 밤새 코드를 짰다. 힘들었지만 내가 뭘 만드는지 알았고, 왜 만드는지도 알았다. 내가 결정하면 됐다. 망해도 내 책임이었다. 지금은 뭐지. 결정권도 없고, 책임만 있다.

나는 바로 우리 층을 누르지 않고 지하 1층을 눌렀다. 지하 1층에는 야외 흡연실이 있다.

담배는 5년 전에 끊었다. 그런데 요즘 자꾸 흡연실에 간다. 담배를 피우러 가는 게 아니다. 그냥 거기 서 있다. 사무실에서는 팀장이고, 부서장실에서는 보고자이고, 집에서는 아빠다. 아무것도 아닌 채로 서 있을 수 있는 곳이 거기뿐이었다.

[오후 3:24] 김 대리 - 사무실에서

짜증이 난다.

그래도 나름 좋은 회사에 들어왔다고 생각했다. 대기업 계열사, 연봉도 괜찮고, 무엇보다 면접 때 기술 문화 얘기를 그렇게 해놓고. 코드 리뷰는 필수라고 했다. PR 올리면 최소 두 명 이상이 리뷰하고, 테스트 커버리지 80% 이상 유지한다고 했다. 기술 부채 관리도 철저히 하고, 분기마다 리팩토링 스프린트도 따로 잡는다고 했다. 그래서 왔다. 여기라면 개발자로서 성장할 수 있을 것 같았다.

입사한 지 1년. 그런 건 다 사라졌다. 업무가 바쁘다는 핑계로. 시간이 없다는 핑계로.

처음에는 PR을 꼼꼼히 올렸다. 테스트 코드도 작성하고, 변수명도 고민하고, 함수 하나 만들 때도 단일 책임 원칙을 생각했다. 전 회사에서 그렇게 했다. 전 회사에서는 코드 리뷰에서 칭찬도 받았다. 설계를 깔끔하게 한다고. 네이밍 센스가 좋다고. 오픈소스 컨트리뷰션도 몇 번 했다. 내 PR이 머지됐을 때 그 기분을 아직도 기억한다.

여기서는 다르다. 리뷰 요청을 올려도 이틀이 지나도 안 달렸다. 팀장님한테 물어봤더니 "아, 그거 그냥 머지해. 지금 바빠서"라고 했다. 그래서 머지했다. 그 다음부터는 리뷰 요청을 안 했다. 어차피 아무도 안 보니까.

요즘 내가 뭘 하고 있나 싶다.

기능 하나를 추가하는데, 비슷한 코드가 이미 세 군데 있었다. 공통 모듈로 빼면 되는 건데, 그러려면 기존 코드를 건드려야 한다. 기존 코드를 건드리면 테스트를 돌려야 한다. 테스트가 없다. 그러면 QA를 다시 해야 한다. QA 일정은 이미 꽉 차 있다. 결론은, 그냥 복사해서 붙여넣어라.

그래서 복사해서 붙여넣었다. 변수명만 바꾸고. 또 복사하고 붙여넣었다.

내가 실력이 없어서 이러는 게 아니다. 어쩔 수 없는 상황이다. 처음에는 이건 아닌 것 같다고, 공통 모듈로 빼자고 몇 번 얘기했다. 팀장님은 그때마다 "나중에 시간 나면 하자"라고 했다. 그 나중은 오지 않았다. 반복 코드는 늘어났고, 기술 부채는 쌓여갔다. 나도 더 이상 얘기 안 했다. 얘기해 봐야 바뀌는 게 없으니까.

그래도 그건 참을 수 있었다. 어쨌든 일정은 빡빡하지만 맞출 수 있었으니까. 밤 열 시, 열한 시까지 남아서 야근하면 어떻게든 되긴 됐으니까. 벌써 석 달째다. 주말에도 나왔다. 몸은 힘들어도 마음은 그나마 편했다. 끝이 보이니까.

그때 팀장님이 부서장실에서 내려오셨다. 표정이 안 좋았다. 평소보다 더 안 좋았고 눈이 충혈돼 있었다. 담배 냄새가 났다. 팀장님 담배 끊은 지 오래됐다고 했는데.

팀장님이 자리에 앉지 않고 우리 쪽을 둘러봤다.

"다들 잠깐."

키보드 치던 손들이 멈췄다. 하 과장, 이 과장, 정 대리, 윤 사원. 다들 팀장님을 쳐다봤다. 나도.

"그 AI 통합 기능 있잖아."

심장이 철렁했다. 설마.

"그거 다시 넣어야 할 것 같아."

사무실이 조용해졌다. 누군가 한숨을 쉬었는데 하 과장이었다.

"팀장님, 그거 빠졌잖아요. 중요도가 떨어져서 일정에서 제외됐다고…"

"다시 넣어야 해. 부서장님 뜻이야."

"그때 회의에서 빼기로 했잖아요. 회의록에도 있고, 메일로도 공유했잖아요."

"나도 알아."

팀장님 목소리가 지쳐 있었다. 하 과장이 더 말하려다가 멈췄다.

"일정은요?"

내가 물었다.

"똑같아."

"…그게 되나요?"

팀장님이 나를 쳐다봤다. 잠시 침묵이 흘렀다. 팀장님 눈에 뭔가가 있었다. 미안함인지 체념인지 모르겠다.

"야근 좀 더 해야 할 것 같아."

야근 좀 더. 지금도 매일 열 시까지 하고 있는데. 석 달째. 좀 더 하면 열두 시인가. 새벽 한 시인가.

"알겠습니다."

그 말밖에 안 나왔다. 더 할 말이 없었다.

팀장님이 자리로 돌아가고 사무실이 다시 조용해졌다.

팀장님 표정이 이상했다. 화난 건지 지친 건지. 아니, 둘 다인 것 같았다. 팀장님도 싫은 거다. 그걸 알면서도 짜증이 났다. 알면 뭐하나. 어차피 우리한테 내려오는 건 똑같은데.

하 과장이 작게 욕을 했다.

"씨발."

아무도 뭐라고 안 했다.

저녁 일곱 시가 됐다. 평소보다 이른 시간인데 하 과장이 일어났다.

"나 먼저 간다. 오늘 들은 거 내일 생각할래."

"아, 예. 수고하셨습니다."

하 과장이 나가고 잠시 후 이 과장도 일어났다.

"나도. 어차피 오늘 시작해 봤자."

이 과장도 나가자 정 대리도 일어났다.

"선배님, 저도 갈게요."

"응, 수고."

정 대리도 나갔다. 윤 사원은 여섯 시 칼퇴했다. 신입이라 야근을 안 시킨다.

다들 그랬다. 오늘 추가된 건 내일 생각하기로 한 것 같았다. 평소 같으면 열 시, 열한 시까지 남았을 텐데. 오늘은 뭔가 다 지쳐 있었다. 팀장님은 아까 회의실로 들어가셨다. 전화하시는 것 같았다.

다들 똑같은 입장이다. 다들 야근하고 있고, 다들 지쳐 있고, 다들 이게 말이 안 된다는 걸 안다. 그래도 누군가는 해야 하니까. 내가 안 하면 내일 아침 회의에서 진척이 없다고 혼난다. 내가 안 하면 일정이 밀린다.

그래서 남았다. 나만 남았다. 책임감 때문인지, 바보 같아서인지 모르겠다.

모니터를 다시 보니 복사해 둔 코드가 여전히 떠 있다. 커서가 깜빡거렸다.

시키는 것만 하는 것도 지친다. 그런데 시키는 게 계속 늘어난다.

솔직히 이번 프로젝트의 목표가 뭔지 모르겠다. 고객들이 쓴다고는 하는데, 아직 파는 상태도 아니다. 중간 대행업체가 있고, 그 업체에서 이런 기능이 있어야 한다고 요구했다는 것이다. 그러니까 실제 사용자가 원하는 게 아니라 중간 업체가 원하는 거다. 개발해야 판다고 하는데, 솔직히 이렇게 만든 거 쓸 것 같지도 않다.

아홉 시쯤 나도 퇴근했다. 더 해봤자 집중이 안 됐다. 솔직히 오늘 들은 얘기가 머릿속에서 안 지워졌다. AI 통합. 남은 일정. 야근 좀 더. 생각할수록 화가 났다. 회사한테인지 나한테인지 모르겠다. 알겠습니다, 하고 대답한 건 나다. 아무도 강제하지 않았는데 혼자 남은 것도 나다. 생각하기 싫었다.

사무실을 나왔다. 아홉 시인데도 복도에 불이 꺼져 있고 비상등만 켜져 있었다. 내 발소리만 울렸다.

엘리베이터를 기다리면서 생각했다. 이직해야 하나. 여기 온 지 1년도 안 됐는데. 이력서에 안 좋아 보일 텐데. 이러다가 정말 몸 버리겠다.

엘리베이터가 와서 탔다. 거울에 내 얼굴이 비쳤다. 처음 입사했을 때보다 늙어 보였다. 1년도 안 됐는데.

[오후 10:47] 박 팀장 - 집에서

저녁 아홉 시쯤 현기증을 느껴서 퇴근을 했다.

사무실에서 일어나는데 눈앞이 핑 돌았다. 책상 모서리를 잡고 잠깐 서 있었다. 김 대리가 괜찮으냐고 물었다. 괜찮다고 했다. 괜찮지 않았다.

요즘 밥을 제대로 못 먹어서 그런 것 같다. 점심은 대충 편의점 삼각김밥으로 때우고, 저녁은 먹을 타이밍을 놓치기 일쑤다. 아침은 원래 안 먹는다. 그러니까 하루에 삼각김밥 두 개가 전부인 날도 있다. 그게 며칠째 계속됐다.

매일 차로 퇴근하다 보니 아홉 시에 퇴근해도 집에 도착하면 열 시쯤 된다. 운전하면서 졸린 적이 몇 번 있었다. 위험하다는 걸 안다. 그래도 대중교통 타면 더 늦는다.

오늘도 그랬다. 열 시 조금 넘어서 집에 도착했다.

현관문을 열었다. 거실 불이 켜져 있고 아이들 방은 불이 꺼져 있었다. 벌써 잠들었나 보다.

신발을 벗는데 작은 운동화가 보였다. 딸내미 거다. 분홍색 운동화. 오늘 어린이집에서 뭐 했는지 모른다. 내일 뭐 하는지도 모른다. 참관 수업이 있다고 아내가 말했던 것 같은데, 언제였더라. 이 운동화가 전보다 커진 것 같았다. 아이가 크고 있는데 내가 그걸 보지 못하고 있다.

요즘 아이들 얼굴을 제대로 본 게 언제인지 모르겠다. 아침에 나갈 때는 아직 자고 있고, 밤에 들어오면 이미 자고 있다. 주말에만 얼굴을 본다. 주말에도 피곤해서 많이 놀아주지 못한다. 큰애가 여섯 살이고 작은애가 네 살인데, 둘 다 아직 어린이집 다니는 나이다. 아빠 얼굴 볼 시간이 없다.

아내가 현관에서 나를 맞아줬다.

"오늘도 고생했어."

고맙다. 미안하다. 매일 이 시간에 들어오는 남편을 기다려줘서 고맙다. 아이들 혼자 재우게 해서 미안하다. 말은 안 했다. 고개만 끄덕였다. 말하면 눈물이 날 것 같았다. 왜인지 모르겠다.

"뭐 좀 먹을래? 국이랑 밥 있어."

"응, 고마워. 샤워하고 먹을게."

샤워실에 들어가서 물을 틀었다. 뜨거운 물이 등을 타고 흘렀다. 잠깐 벽에 기대서서 눈을 감았다. 부서장님 얼굴이 떠올랐다. "팀원들이 지금보다 훨씬 더 헌신한다면." 헌신. 그 말이 계속 떠올랐다.

샤워를 마치고 나와서 거실 소파에 앉았다. 아내가 주방에서 뭔가를 데우는 소리가 들렸다. 그릇 부딪히는 소리. 전자레인지 돌아가는 소리. 평화로운 소리들이었다. 이 집만큼은 평화롭다.

눈을 감았다. 잠깐 졸았나 보다.

핸드폰이 울렸다.

진동이 소파 쿠션을 타고 전해졌다. 눈을 떠서 화면을 보니 부서장님이다.

이 시간에?

뭐지. 무슨 일이지. 오늘 팀원들한테 추가 기능 하라고 얘기도 했고, 다들 알겠다고 했고. 뭐가 문제지.

손이 떨려서 전화 받기 버튼을 누르는 데 시간이 걸렸다.

"여보세요."

목소리가 갈라졌다.

"팀장님, 지금 어디에요?"

다짜고짜 어디냐고 묻는다. 인사도 없이.

"집입니다."

"아, 집이요."

부서장님 목소리에 뭔가가 섞여 있었다. 실망인가. 비난인가. 잘 모르겠다.

"팀장님, 지금 정말 중요한 시기인 거 아시죠?"

"예, 알고 있습니다."

"저희 프로젝트가 이번에 성공해야 다음 단계로 넘어갈 수 있는 거 아시죠?"

"예."

"팀장님께서 정말 중요하다고 느끼고 계시는 거 맞죠?"

"예."

"팀원들한테도 중요하다고 충분히 전달하셨고요?"

"예, 오늘 얘기했습니다."

"팀원들도 다 같이 헌신하고 있는 거 맞죠?"

유도 심문 같은 질문이 몇 번 왔다 갔다 한다. 나는 예, 예, 하고 대답했다. 예. 예. 예. 기계적으로 대답했다. 머릿속이 하얘졌다.

잠깐의 침묵이 흘렀다. 부서장님이 숨을 쉬는 소리가 들렸다. 본론을 꺼내기 전의 그 특유의 침묵이었다.

"그런데 제가 열 시쯤 사무실에 확인을 했는데요."

심장이 멈춘 것 같았다.

"사무실에 아무도 없더라고요?"

"…"

"팀장님께서 정말 중요하다고 느끼고 팀원들을 잘 이끌고 있는지 모르겠습니다."

입이 열리지 않았다. 또 그 습관이 나왔다. 말이 안 통하면 대답을 못 하는 습관.

머릿속에서 뭔가가 끊어지는 느낌이 들었다. 팽팽하게 당겨져 있던 줄이 툭 하고 끊어지는 느낌. 끊어지고 나니 아무것도 느껴지지 않았다. 분노도 아니고 억울함도 아니었다. 그냥 비어 있었다.

"팀장님?"

"…예."

"제 말 듣고 계시죠?"

"예."

"내일 아침에 얘기하시죠. 출근하시면 저한테 먼저 오세요."

"예."

전화가 끊겼다.

핸드폰을 내려놓았는데 손에 힘이 없어서 소파 쿠션 위에 떨어졌다.

아내가 손에 따뜻한 국물이 담긴 그릇을 들고 거실로 나왔다. 미역국이었다.

"무슨 전화야?"

"…회사."

"이 시간에?"

"응."

"무슨 일이야?"

말이 나오지 않았다. 무슨 말을 해야 할지 몰랐다. 사무실에 아무도 없었다고. 부서장님이 확인했다고. 내일 아침에 오라고.

아내는 그릇을 테이블에 내려놓고 내 옆에 앉았다. 아무 말도 하지 않았다. 그냥 옆에 앉아 있었다. 아내의 손이 내 손 위에 올라왔다. 따뜻했다. 나는 그 손을 잡지 않았다. 잡을 힘이 없었다.

아내가 조용히 물었다.

"많이 힘들어?"

고개를 끄덕였다. 그게 전부였다.

천장을 올려다봤다. 하얀 천장. 금이라도 가 있으면 좋겠다. 뭐라도 있으면 좋겠다. 아무것도 없었다.

국이 완전히 식었다. 김이 더 이상 나지 않았다. 먹어야 하는데. 손이 움직이지 않았다.

아내가 일어나서 주방으로 갔다. 다시 데우려는 것 같았는데 나는 말리지 않았다. 말릴 힘도 없었다.

여섯 시간 후면 알람이 울린다. 일곱 시간 후면 다시 그 건물 앞에 서 있다. 여덟 시간 후면 부서장실 문을 연다.

뭐라고 말하지.

팀원들이 게을러서 그렇다고 할까. 제가 관리를 못 해서 그렇다고 할까. 둘 다 거짓말이다. 그런데 그 말 외에 뭘 할 수 있지.

거실 시계 초침 소리가 들렸다. 똑. 똑. 똑.

내일은 온다. 준비 같은 건 상관없이.

(Continue..)

F1 리더십, 제임스 바울스는 무엇을 했나? - IT 엔지니어 리더십 관점에서

Tony Cho (https://flowkater.io) — Fri, 09 Jan 2026 11:00:00 GMT

들어가며

작년에는 F1을 라이브로 보면서 정말 울고 웃고 즐거운 한 해였다.

특히, 나와 엘리는 윌리엄스의 카를로스 사인츠의 팬이었는데 그의 잘생긴 얼굴과 더불어 모두에게 사랑받는 인성, 그리고 25년 한 해 동안 보여주었던 그의 엄청난 드라이빙 역량 덕분에 너무나 행복한 시간들이었다.

재작년까지는 F1 다큐멘터리 "본능의 질주(Drive to Survive)"를 꼬박꼬박 챙겨봤는데, 윌리엄스가 매각이 되고 나서 선임된 제임스 바울스 팀장이 되게 궁금해졌다. 제임스 바울스는 처음 다큐멘터리에서 "데이터 가이"라는 별명으로 불리며 조명되었는데, 지금은 경질된 레드불 크리스천 호너가 "초짜들이나 그런 얘기를 한다"면서 비아냥거리던 인터뷰가 잊을 수가 없다.

메르세데스의 토토 볼프 밑에서 꽤 오랫동안(12년) 같이 일을 했던 이 분야의 베테랑인데, 2025 시즌에 보여준 윌리엄스의 엄청난 퍼포먼스 덕분에 카를로스 사인츠의 팬으로 시작했다가 지금은 제임스 바울스의 팬이 되어버렸다. (팬심 전환 속도가 이렇게 빠를 줄이야.)

25년에는 윌리엄스가 중위권 팀에서 확정적인 5위가 되었고 카를로스 사인츠는 포디움에 두 번이나 올랐다. 나와 엘리 둘 다 라이브로 카를로스가 3위로 피니시 라인을 통과할 때 진짜 비명을 질렀다. 평생 살면서 스포츠를 별로 즐기지는 않았는데 이렇게 몰입해서 볼 줄이야.

그래서 이러한 성과를 만든 윌리엄스 레이싱, 특히 제임스 바울스의 리더십이 팀 내에서 어떻게 동작했는지 궁금했다. 나는 5년 넘게 스타트업 대표로도 일을 해보았고, 4년 동안 R&D 본부 리드로 일하면서 0 to 1 으로 팀을 키워본 경험이 있다. 그 과정에서 수많은 시행착오를 겪었고, 바울스의 리더십을 보면서 "아, 이렇게 했으면 더 좋았겠다"라는 생각이 들었다.

레이싱 경기만 빼면 거의 IT 스타트업 팀의 구조와도 사뭇 닮아있는 F1 팀이다. 팀 수석이 있고 CTO도 있다. (윌리엄스의 경우) 도대체 제임스 바울스가 이 만년 꼴찌 팀에 무슨 짓을 했길래, 심지어 본인 입으로 올해는 버리는 해라고 했던 시즌인데도 불구하고 이런 성과를 낸 배경에는 무슨 일이 있었던 건지 궁금해서 제임스 바울스 관련 여러 기사와 포스팅, 영상을 찾아보고 정리해보았다.

"엑셀로 만든 차"

제임스 바울스가 선임된 그 해, 윌리엄스의 상태는 충격적이었다.

2024년 윌리엄스 초도 작업을 포함해 그들의 차량 제작 관리는 마이크로소프트 엑셀을 사용해 처리되었고, 약 20,000개의 개별 부품과 구성품 목록이 있었다.

— The Race, "The shocking details behind an F1 team's painful revolution"

F1 레이싱 카에는 온갖 엔지니어링이 집약되어 있다. 공기 역학, 자동차 공학, 데이터 분석 등. 프론트 윙 하나에만 약 400개의 서로 다른 부품이 들어간다. 그런데 이 수십만 개의 부품을 엑셀로 관리하고 있었다니.

엑셀 목록은 농담이었다. 탐색은 불가능했고 업데이트도 불가능했다.

부품 비용, 제작 시간, 대기 중인 수량에 대한 데이터도 없었다. 바울스는 이 상황을 "명나라 시대"에 비유했다. 지난 20년간 필요한 투자가 이루어지지 않았던 것이다.

이 이야기를 보면서 뼈저리게 공감했다. 레거시 시스템이나 정리되지 않은 프로세스를 마주했을 때의 그 막막함. 누구나 한 번쯤 경험해봤을 거다.

시스템 부재는 단순히 비효율의 문제가 아니라, 성장의 천장이 된다. 앞으로 새로운 팀을 맡게 되면, 가장 먼저 "우리 팀의 엑셀은 뭔가?" 를 찾아봐야겠다. 겉으로는 돌아가는 것 같지만 확장성을 가로막는 병목. 그걸 찾아서 시스템화하는 게 첫 번째 일이다.

고통스러운 변화를 선택하다

바울스는 두 가지를 동시에 진행하기로 결정했다. 엑셀 스프레드시트를 디지털 시스템으로 전환하면서, 동시에 차량의 '기술 기반'을 대폭 변경한 것이다.

우리의 섀시는 몇백 조각에서 몇천 조각으로 늘어났다. 그것은 차의 한 부분에 불과하다.

예상대로 둘을 동시에 진행하는 것은 악몽이었다. 작업자들은 공장에서 밤샘 작업을 해야 했고, 바울스는 그 차가 1월에도 여전히 "그냥 많은 부품들이 담긴 큰 가방 같은 상태"였다고 회상했다.

그런데 바울스는 이 고통이 필요한 것이었다고 말한다.

나는 시스템이 어디서, 어떻게 깨지는지를 한 번에 파악하기 위해 시스템을 최대한 한계까지 압박하고 싶었습니다. 이번 겨울이 우리가 그것을 할 유일한 겨울입니다.

— Motorsport.com, "Vowles on what Williams F1 has done wrong"

레거시 시스템을 운영하다가 "이대로는 안 된다"고 결심하고 대규모 리팩토링을 감행하는 것. 단기적으로는 개발 속도가 떨어지고 버그도 늘어나지만, 이 고통을 견뎌야만 장기적인 성장이 가능하다는 판단. 이건 IT에서도 똑같은 딜레마다.

당장 무언가 돌아가고 있기 때문에 새로 시작하는 것보다 훨씬 어려운 작업이다. 사람들은 이미 거기에 익숙해져있고 그걸 바꾼다고 바로 학습이 되지도 않는다. 바꾸자고 도입했던 시스템이 반발로 롤백하는 경우도 많은 조직에서 심심찮게 본다. 다만, 돌아간다고 해서, 그렇게 해온다고 해서 그게 옳은 것은 아니다. 그걸 바꿀 수 있는 용기도 필요하고 조직 위아래도 지지를 얻을 수 있는 리더십도 필요할 것이다. 26년을 위해 2년을 그냥 버린다고 ? 아무나 그런 선택을 할 수는 없다.

변화를 미루면 미룰수록 비용은 커진다. 앞으로 큰 변화가 필요한 상황이 오면, "지금이 이걸 할 유일한 타이밍인가?" 를 스스로에게 물어봐야겠다. 그리고 변화를 선택했다면, 시스템을 한계까지 압박해서 어디서 깨지는지 미리 파악하는 것. 운영 중에 터지는 것보다 훨씬 낫다.

세트업과 주행에서 정말 많은 걸 시도하고 있다. 때로는 뒤로 가지만, 그게 결국 어느 방향으로 가면 안 되는지 알게 해주고 나를 앞으로 보낸다.

— 카를로스 사인츠, 2025 사우디 GP

비난 없는 문화 (No Blame Culture)

시스템만 바꾼다고 팀이 바뀌지는 않는다. 바울스가 가장 중점을 둔 것은 문화였다.

만약 당신이 나를 위해 일한다면, 실수를 할까 봐 혹은 직장을 잃을까 봐 두려워서 경계를 넓히거나 개발하고 혁신해야 할지를 망설이는 일이 절대 없기를 바란다.

— GPBlog 인터뷰

바울스는 '비난 없는 문화(No Blame Culture)'를 도입했다. 메르세데스에서도 높이 평가받던 문화로, 실수를 숨기지 않고 공개적으로 논의하며 그로부터 배우는 것을 목표로 한다.

두려움의 문화가 만드는 문제는 두 가지다.

첫째, 안전한 것만 택하게 된다. 밖으로 밀어붙이는 대신 편안하다고 느끼는 한도까지밖에 밀지 않는다.

둘째, 문제가 생기면 숨기게 된다. "내가 이걸 잘못했어, 왜 이렇게 잘못했는지 설명할게"라고 세상에 드러내며 말하지 않는다.

"내 경력에서 실패한 횟수는 엄청나다. 하지만 그 모든 실패는, 공개적으로 이야기하고 올바르게 대했을 때, 나를 훨씬 더 강하게 만들었다. 성공은 사실 당신을 더 강하게 만들지 않는다. 가만히 앉아 '잘했어'라고 할 뿐이다."

솔직히 비난 없는 문화를 만드는 건 말처럼 쉽지 않다. 나도 초기에 비슷한 시도를 했었는데, 팀이 커지고 바빠지면서 유지하기가 어려웠다. 하지만 바울스의 말을 보면서, 이건 "하면 좋은 것"이 아니라 "반드시 해야 하는 것"이라는 걸 다시 느꼈다. 모든 실패와 실수에서 팀이 계속 학습할 수 있는 분위기가 있어야 하는데 나는 어떨때는 무심하게 넘어가기도 하고 또 나무라기도 했었다. 팀의 공통된 목표가 있고 그 목표에 정렬되어 그것을 달성하는 것이야 말로 승리를 위한 방향이라고 하면, 그 길에 있어서 생기는 모든 실수는 그저 승리를 향해 가는 수단이 될 것이다.

오히려 이 이야기를 통해 나는 모두가 목표에 집중하고 성과에 몰두할 수 있는 조직 환경의 세팅이 선행되어야 오히려 역설적으로 이러한 문화 또한 잘 구축할 수 있을 것이다.

실패 사례를 먼저 공유하기. 리더가 먼저 자신의 실수를 공개적으로 얘기해야 팀원들도 그렇게 한다.
"왜 이런 일이 일어났나"보다 "다음에 어떻게 막을 수 있나"에 집중하기. 회고 시간에 책임 추궁이 아닌 시스템 개선에 초점을 맞추기.
바쁠수록 이 문화를 더 신경 쓰기. 압박이 클 때 문화가 무너지기 쉽다.

1 on 1, 결국 이게 답이다

바울스의 리더십에서 내가 가장 공감한 부분은 소통에 대한 강조다.

주 3회 공장 전체에 이메일을 보내고, 매 경기 후 팀 미팅을 한다. 공장 구석구석을 직접 걸어 다니는 것도 중요하다.

— Monocle, "10 Leadership Lessons from James Vowles"

주 3회 전체 이메일, 매 경기 후 팀 미팅, 공장 구석구석 직접 걸어 다니기. 별거 아닌 것 같지만 실제로 해보면 정말 어렵다. 특히 팀이 커지면 커질수록.

돌아보면 내가 가장 아쉬웠던 건 이 부분이다. 팀 초기에는 1 on 1을 자주 하고 피드백도 부지런히 주고받았는데, 팀이 커지면서 점점 뜸해졌다. 그런데 바울스를 보면서 다시 확신하게 됐다. 부지런하게 1 on 1 하는 것이 최선이라는 걸.

"사람들에게 진심으로 관심을 가져라. 사람들이 내게 시간을 내준다는 사실에 정말 큰 감사를 느낀다. 그들은 그 한 분을 가족과 함께 보낼 수 있는데도 그러지 않고 내 곁에 있어 준다."

이 말이 특히 와닿았다. F1 팀이든 IT 팀이든, 결국 사람들이 시간을 내서 함께하는 거다. 그 시간에 대한 감사함을 잊으면 안 된다.

밑에서 위로 피드백을 하는 건 쉽지 않다. 특히 한국 조직 문화에서 더 심한 것 같다. 리더들이 그러한 것을 기대하면서도 막상 그런 피드백을 받으면 당황하기도 하는 것처럼. 조금 더 이런 피드백을 시스템적으로 진행할 수 있는 방법을 구축해야 한다고 생각했다. nice to have 가 아닌 must have 인 것이다.

액션 아이템:

1 on 1 일정 시스템 바쁘다고 미루면 결국 안 하게 된다.
피드백을 미리 준비하기. 특히 개선 포인트를 사람당 최소 한 개 이상 준비해서 가기.
소통 채널 다양화하기. 주간 전체 메일, 비공식 대화, 공식 미팅 등 여러 채널을 활용하기.

장기적인 게임

바울스의 리더십에서 가장 인상적인 부분은 장기적 관점이다.

나는 어떤 단기주의도 믿지 않는다. 윌리엄스와 그 미래에 맞지 않기 때문에 단기적으로 움직이지 않을 것이다.

— Monocle, "10 Leadership Lessons from James Vowles"

그는 2024년과 2025년을 "희생"할 것이라고 처음부터 말해왔다. 2026년의 새로운 기술 규정에 맞춰 팀을 재건하기 위한 투자였다. 당장의 순위보다 미래의 경쟁력을 선택한 것이다.

나는 7위, 8위, 9위를 원하지 않는다. 나는 2026년이 좋기를 원한다. 반면 피트 레인 주변의 다른 사람들은 2024년과 2025년에 집중하고 있다.

— Motorsport.com, "Why Vowles believes Williams culture will survive short-term pain"

이 결정은 팀 소유주인 도릴턴 캐피털의 전폭적인 지지를 받았다. "임시방편은 보기에는 그럴듯하고 겉모습을 내지만, 곧 무너진다."

솔직히 장기적 관점을 유지하는 건 정말 어렵다. 당장의 성과 압박, 이해관계자들의 기대, 팀원들의 동기부여 등 온갖 것들이 단기적 선택을 하게 만든다. 하지만 바울스를 보면서 다시 생각하게 됐다. 장기적 관점을 유지하려면 명확한 목표와 그 목표에 대한 공유 가 필수다.

이 팀은 상승 곡선을 그리고 있고, 그 흐름을 절대 멈추면 안 된다.

— 카를로스 사인츠, 2025 시즌 종료 후 인터뷰

조직적인 차원에서 팀을 운영하면서 내가 전권이 있을때는 우리 회사의 장기적 관점을 제대로 제시하지 못한 경우도 있었고, 중간 관리자로 있을때는 상위 경영진에게 책임을 미룬 적도 있었다. 분명 어느 부분에서는 내가 충분히 할 수 있었던 부분이 있었지 않았을까 싶다. 아마 어느 순간 장기적인 로드맵이 또 외부의 개입으로 부러지거나 할때 조금 더 유연하게 대처하고 다시 세우고 컨트롤 했었으면 더 좋았을텐데 하는 부분도 있었다.

액션 아이템:

"우리의 목표는 뭔가?"를 정의하기. 단기 성과에 흔들리지 않을 명확한 장기 목표.
그 목표를 팀 전체와 공유하기. 왜 지금 이 고통을 감수하는지 모두가 알아야 한다.
이해관계자에게도 장기 비전을 설득하기. 위의 지지 없이는 장기 전략이 유지되기 어렵다.

카를로스 사인츠를 설득한 방법

바울스의 리더십이 가장 잘 드러난 사례가 카를로스 사인츠 영입이다.

바울스는 카를로스 사인츠를 영입하는 과정에서 6개월 동안 꾸준히 소통하며 윌리엄스의 나쁜 점까지 모두 솔직하게 공개했다. 그는 투자 계획과 미래 비전을 투명하게 제시했고, 사인츠는 이것이 허구가 아님을 확인했다.

— Pit Debrief, "James Vowles on Williams F1 progress"

6개월 동안 꾸준히 소통. 나쁜 점까지 솔직하게 공개. 투자 계획과 미래 비전을 투명하게 제시. 쉬운 일이 아니다. (아니, 엄청 어렵다.)

사인츠가 윌리엄스를 선택한 이유는 단순히 자리가 필요해서가 아니었다. 그는 윌리엄스를 챔피언십 팀으로 만드는 데 필요한 것을 이해하고, 그 변혁의 핵심이 되기를 원했다. 바울스의 비전에 공감한 것이다.

이건 내 인생 프로젝트다. 윌리엄스를 결국 우승할 수 있는 곳으로 되돌리는 걸 돕는 것이 내가 여기 있는 이유다.

— 카를로스 사인츠, 2025 바쿠 GP 이후 Sky Sports 인터뷰

채용에서 이런 투명함은 정말 중요하다고 생각한다. 좋은 점만 보여주고 싶은 유혹이 항상 있지만, 결국 나쁜 점을 숨기고 채용한 사람은 금방 떠난다.

나도 많은 채용을 했었기 때문에 많은 사람들이 생각난다. 사실 채용을 할때 좋은 점만을 얘기한 적도 있었고 솔직하지 못하게 얘기한 적도 있었다. 하지만 위 결론처럼 결국 끝이 좋진 않더라. 명확하게 내가 원하는 것을 말하되 현재 상황과 목표에 솔직해지는 것 그게 정말 필요한 태도이다.

액션 아이템:

채용 시 나쁜 점도 솔직하게 공유하기. 현재 어려움, 해결해야 할 문제들을 숨기지 않기.
비전을 명확하게 제시하기. "지금은 이렇지만, 우리의 목표는 이것이다"를 구체적으로.
시간을 들여 관계를 구축하기. 바울스처럼 6개월 동안 꾸준히 소통하는 끈기.

자기보다 더 똑똑한 사람을 채용하라

바울스가 공유한 10가지 리더십 교훈 중에서 가장 와닿았던 건 이거다.

나는 윌리엄스에서 가장 똑똑한 사람이 아니다. 그럴 필요도 없다. 내 일은 세계적 수준의 인재를 모으고 그들에게 권한을 주며 언제 비켜야 할지를 아는 것이다.

이건 말은 쉽지만 실천하기 정말 어려운 원칙이다. 특히 개발자 출신 리더라면 더더욱. 기술적으로 뛰어난 사람을 채용하면 어느 순간 "이거 내가 해도 될 것 같은데"라는 생각이 든다. (본능이다.) 하지만 그걸 참고 위임하는 게 리더의 역할이다.

방향성은 당신이 제공하는 답변보다 더 중요할 때가 많다. 우유부단한 태도는 잘못된 결정보다 더 나쁘다. 정답이 완벽하지 않을 수 있지만 우리는 함께 앞으로 나아갈 것이다.

이것도 뼈아프게 공감한다. 내가 판단할 수 있는 것인지 아닌지를 빠르게 메타인지 한 후에, 판단할 수 있으면 빠르게 결정하고, 아니면 이해관계자들을 빠르게 모아서 결정하게 해야 한다. 우유부단함이 가장 큰 적이다.

액션 아이템:

"내가 할 수 있나?"가 아니라 "누가 제일 잘할 수 있나?"로 질문 바꾸기.
결정을 미루지 않기. 정보가 70% 모이면 결정하고 나머지는 실행하면서 조정하기.
위임 후 간섭하지 않기. 결과를 리뷰하되, 과정에 일일이 개입하지 않기.

개발 팀(IT 스타트업)과 F1 팀의 닮은 점

글을 쓰면서 느낀 건데, F1 팀 운영과 개발 팀(IT 스타트업) 운영은 생각보다 많이 닮아있다.

복잡한 시스템의 조율. F1 차량은 수만 개의 부품이 정교하게 맞물려 동작한다. 개발 시스템도 마찬가지다.

데이터 기반 의사결정. F1에서는 차량 데이터, 타이어 마모, 날씨 등을 실시간으로 분석해 전략을 세운다. 개발 팀(IT 스타트업)도 메트릭, 로그, 사용자 행동 데이터를 기반으로 의사결정을 한다.

빠른 실패와 학습. F1에서는 레이스마다 피드백을 받고 다음 레이스 전에 개선한다. 개발 팀(IT 스타트업)도 스프린트마다 회고하고 개선한다. 바울스가 말한 "비난 없는 문화"는 애자일에서 말하는 심리적 안전감(Psychological Safety)과 정확히 같은 개념이다.

바울스가 케임브리지 저지 비즈니스 스쿨에서 한 말이 인상적이다.

"우리 비즈니스에 주어지는 노출도는 물론 매우 높고, 저는 매주 큰 관심을 받는 성과에 대해 설명해야 할 의무가 있지만, 여기 계신 다른 분들이 겪는 문제들과 우리가 직면한 문제들은 동일합니다."

— Cambridge Judge Business School

F1이든 IT 스타트업이든, 결국 조직을 이끄는 문제는 본질적으로 같다.

나가며

바울스의 리더십에서 가장 인상 깊었던 건 진정성이다.

당신이 하는 일을 온 마음으로 믿어야 합니다. 궁극적으로 힘든 상황에서 매일 당신을 앞으로 나아가게 하는 것은 바로 그 믿음입니다. 그리고 그럴 때야말로 당신의 진짜 성격이 드러납니다. 허울만 걸치고 있다면 결국 그 가면은 무너질 것입니다.

그는 카를로스 사인츠를 영입할 때도 윌리엄스의 좋은 점만 보여주지 않았다. 나쁜 점까지 모두 솔직하게 공개했다. 그리고 그 솔직함이 오히려 신뢰를 만들었다.

내가 정말 솔직하고 진정성있게 다가갔을때와 아닐때를 경험을 통해 잘 알고 있다. 그 결과도. 스타트업 대표와 CTO로 일하면서 배운 게 있다면, 결국 중요한 건 "어떤 팀을 만들 것인가" 라는 질문에 대한 답을 스스로 가지고 있느냐는 것이다. 그리고 그 답을 향해 일관되게 움직이고 있느냐는 것.

제임스 바울스의 이야기를 정리하면서, 앞으로 적용해볼 것들을 다시 한번 정리해봤다.

배운 것	액션 아이템
시스템 없이는 성장도 없다	"우리 팀의 엑셀"을 찾아서 시스템화하기
고통스러운 변화도 필요하다	"지금이 유일한 타이밍인가?" 물어보기
비난 없는 문화	리더가 먼저 실패 사례 공유하기
1 on 1이 최선	일정 고정, 피드백 미리 준비
장기적 관점	명확한 목표 정의 및 공유
투명한 채용	나쁜 점도 솔직하게, 비전은 명확하게
위임의 기술	누가 제일 잘할 수 있는지 물어보기

솔직히, 얼마나 기쁜지, 이게 얼마나 좋은 느낌인지 말로 표현할 수 없다. 이건 내 첫 포디움보다도 더 좋다. 우리는 1년 내내 힘들게 싸워왔고, 오늘 마침내 우리에게 속도가 있을 때—우리는 1년 내내 그랬다—모든 게 함께 맞아떨어지면, 우리가 놀라운 일들을 함께 할 수 있다는 걸 증명했다. 오늘 우리는 레이스를 완벽하게 해냈다. 한 번의 실수도 없었고, 어제 기대하지 않았던 많은 차들을 이겼다. 윌리엄스의 모든 사람이 우리의 매우 어려운 한 해를 밀고 나간 것에 대해 매우 자랑스럽다. 우리는 모두에게 작년 대비 거대한 진전을 이뤘다는 걸 증명했다. 우리는 상승하고 있고, 올바른 방향에 있다. 불행히도 나에게는 많은 불운, 많은 사고가 있었고—그 모든 페이스를 결과로 바꾸기가 매우 어려웠다. 하지만 오늘은 다 맞았다. 레이스 실행도 완벽했고, 팀 콜도 완벽했고, 타이어 매니지먼트도 완벽했고, 스타트도, 모든 수비와 매니지먼트도 완벽했다. 그래서 예상 못 한 포디움을 가져왔다. 나는 이보다 더 자랑스러울 수 없다." 다른 사람들이 뭘 하든 내 일이 아니다. 내가 신경 쓰는 건, 윌리엄스와 함께 포디움 기회가 처음 왔을 때, 우리가 그걸 잡았고 득점했다는 것이다. 그게 전부다."

— 카를로스 사인츠 주니어 바쿠 GP 첫 P3 포디움 달성 후 인터뷰

결과로 말하는 것. 그게 결국 진짜 리더십인 것 같다.

참고 자료:

15년차 CTO가 바이브 코딩하는 방법

Tony Cho (https://flowkater.io) — Fri, 09 Jan 2026 07:00:00 GMT

2026-02-08 추가

tdd:go 는 스텝 바이 스텝으로 들어간다. 만약 조금 더 자동화된 방법을 원한다면 다음 글을 참고해라.

Claude Code에 날개를 달아줘라! - Superpowers 소개

들어가며

먼저 어그로 끌어서 미안하다. 나는 15년차 CTO가 아니다. (15년째 개발을 하고 있는 건 맞음) 그 다음 현재 CTO도 아니다. (작년에 퇴사함.)

OpenCode (+oh-my-opencode) 열풍이 한번 지나갔다. 최근에 OpenCode는 ToS 이슈나 여러 이슈들로 아주 불태운 시기였다. 오늘 날짜로 막혔는데 개인적으로 우회하는 방법이 있긴 하나 지금 남은 작업들은 Claude Code만으로도 큰 문제가 없을 것 같아 그냥 Claude Code를 당분간은 쓰기로 결정했다.

요즘 AI 코딩 도구들이 쏟아져 나오고 있다. Cursor, Windsurf, Copilot, 그리고 Claude Code까지. 어느 도구가 더 좋은지 비교하는 글도 많고, 각자 자기만의 워크플로우를 공유하는 글도 넘쳐난다. 모두가 "바이브 코딩"을 외치고, 프롬프트 몇 줄에 앱이 뚝딱 나오는 영상들이 유튜브와 트위터를 장식한다. "한 달 걸릴 일을 3시간 만에 끝냈어요!" 같은 이야기가 매일 들린다.

그런데 정작 나는 이 흐름 속에서 묘한 불안감을 느꼈다. 분명 생산성은 올랐는데, 뭔가 놓치고 있다는 느낌. 코드가 돌아가긴 하는데, 내가 이 코드를 진짜 이해하고 있는 건가? AI가 만들어준 코드를 그냥 복붙하면서 '개발'이라고 부를 수 있나? 이런 질문들이 머릿속을 맴돌았다. 문제는 이 불안감을 무시하려 해도 흐름이 끊겨서 오히려 생산성이 떨어졌다는 것이다. 재미가 없으니 그냥 안하고 싶어진달까.

이런 고민을 하던 중 켄트 백의 글을 접했고, 거기서 영감을 받아 나만의 워크플로우를 만들게 됐다. 이 글에서 공유하고 싶은 건 단순히 "어떤 도구를 쓰느냐"나 "하위 에이전트를 어떻게 구성하느냐" 같은 기술적인 이야기가 아니다. 오히려 그런 건 요즘 워낙 많이 공유되고 있으니까. 내가 이야기하고 싶은 건 tdd-go-loop라는 이름의 워크플로우 오케스트레이터다. 단순히 커맨드 하나를 실행하는 게 아니라, 여러 하위 에이전트들이 협업하여 TDD 사이클을 자동화하고 코드 리뷰까지 수행하는 시스템이다.

켄트 백의 증강형 코딩

해당 워크플로우는 켄트 백의 증강형 코딩(Augmented Coding) 에서 영감을 받았다.

국내에 번역된 글도 많으니 한번 검색해서 읽어보면 좋을 것 같다. AI 코딩 시대에 6개월 전 글은 너무 오래된 감이 없지 않아 있지만, 지금 내가 개발할 때 아주 유용하게 쓰는 워크플로우가 여기서 출발했다.

켄트 백이 말하는 증강형 코딩의 핵심은 명확하다. AI가 코드를 작성하더라도, 인간이 통제력을 유지해야 한다는 것이다. 단순히 프롬프트를 던지고 결과물을 받아보는 게 아니라, 작은 단위로 쪼개서 검증하고, 이해하면서 진행하는 방식이다. TDD(Test-Driven Development)가 그 도구가 된다.

TDD라고 하면 많은 개발자들이 "아, 테스트 먼저 짜는 거?" 정도로 알고 있다. 맞는 말이다. 그런데 AI 시대의 TDD는 조금 다르다. 전통적인 TDD에서는 테스트도 내가 짜고 구현도 내가 했다. 증강형 코딩에서는 테스트는 내가 설계하고, 구현은 AI가 한다. 이게 핵심이다. 테스트를 먼저 설계한다는 건 곧 "내가 뭘 원하는지"를 명확하게 정의한다는 의미고, AI는 그 정의에 맞춰서 코드를 생성한다. 테스트가 통과하면 구현이 맞는 거고, 실패하면 틀린 거다. 단순하지만 강력하다.

여기서 중요한 건 "작은 단위"라는 점이다. AI에게 "회원가입 기능 만들어줘"라고 던지는 게 아니라, "이메일 유효성 검증 로직의 실패 케이스 테스트 작성해줘"처럼 쪼개서 요청한다. 테스트가 실패하는 걸 확인하고, 최소한의 코드로 통과시키고, 내가 직접 리뷰한다. 이 사이클을 반복하는 거다. 마치 레고 블록을 하나씩 쌓듯이, 작은 조각들을 검증하면서 쌓아올린다.

컨셉은 아주 심플하다. 다들 잘 알다시피 PRD를 먼저 작성하고, PRD 문서를 바탕으로 Phase와 체크리스트로 구성된 plan.md 파일을 생성한다. Spec-kit이라는 툴도 있지만, 내가 사용해봤을 때 너무 정석적으로 만드느라 일을 키우는 감이 없지 않아 있어서 직접 planning 스킬을 만들어서 쓴다. TDD 단위이다 보니 최대한 잘게 쪼개야 하고, Phase별로 작업을 하는 것을 확인할 수 있게 하는 게 핵심이다.

그리고 /tdd:go라는 커맨드를 이용해서 Phase 단위로 또는 더 하위 체크리스트 단위로 하나씩 실행하고 내가 직접 리뷰하는 방법이다.

딱히 바이브하지 않다

여기서 들으면 알겠지만 딱히 바이브하지 않다.

모든 체크리스트를 하나하나 실행해보고 코드를 확인해보고, 코드에서 아쉬운 점이나 개선해야 할 점, 확장되어야 할 점이 있으면 피드백한다. 그리고 문제가 없으면 다음 체크리스트로 넘어간다. 코딩을 내가 직접 안 하는 건 맞지만 거의 다름없다.

일종의 페어 프로그래밍이랄까. AI가 키보드를 잡고, 나는 옆에서 "어, 거기 그렇게 하면 안 돼" 하면서 방향을 잡아주는 느낌이다. 드라이버(AI)와 네비게이터(나)로 역할이 나뉜 셈이다. 다만 일반적인 페어 프로그래밍과 다른 점이 있다면, AI는 지치지 않고, 불평하지 않고, 내가 피드백하면 바로 수정한다는 거다. (물론 가끔 같은 실수를 반복하면 답답할 때도 있다.)

flowchart LR
    A[PRD 작성] --> B[plan.md 생성]
    B --> C["tdd:go 실행"]
    C --> D[테스트 작성]
    D --> E[테스트 실패 확인]
    E --> F[구현 코드 작성]
    F --> G[테스트 통과]
    G --> H{코드 리뷰}
    H -->|피드백 필요| C
    H -->|통과| I[다음 체크리스트]
    I --> C

실제로 이 방식으로 개발하면, 한 사이클이 5분에서 10분 정도 걸린다. 테스트 하나 작성하고, 실패 확인하고, 최소한의 코드 작성하고, 테스트 통과시키고, 내가 리뷰한다. 이게 반복된다. 바이브? 없다. 대신 코드 한 줄 한 줄을 내가 이해하면서 진행한다.

솔직히 말하면 이 방식이 "힙"하지 않다는 건 나도 안다. 요즘 트렌드는 AI에게 전부 맡기고 결과물만 확인하는 거니까. 중요한 건 자기한테 맞는 방식을 찾으면 된다.

만약 본인이 주니어 개발자이고 코드를 조금 더 학습하고자 한다면, 해당 방법을 강력히 추천한다. 특히 프로젝트에서 코드 베이스를 내가 직접 파악하고 있어야 하거나 완전 처음 프로젝트 코드를 작성할 때는 이 방식으로 한 땀 한 땀 진행한다. AI가 작성한 코드를 그냥 복붙하는 것과, 내가 리뷰하면서 이해한 코드를 쌓아가는 건 완전히 다른 경험이다. 전자는 "코드가 있다"는 상태고, 후자는 "내 코드다"라는 감각이 생긴다. 이 차이가 크다.

명세만으로는 부족했다

처음엔 나도 명세만 잘 쓰면 될 줄 알았다. 디자인 패턴이니 DDD니 클린 아키텍처니 하는 것들을 한번 잘 정리해두면 Claude Code(또는 Codex)가 알아서 다 코딩해줄 거라고. 실제로 간단한 CRUD 앱 정도는 그렇게 만들 수 있었다. 근데 현실은 그렇게 단순하지 않았다.

주니어들과 협업해본 경험이 있는 사람이라면 알 것이다. 정말 간단한 요구사항이 아닌 이상 코드를 작성하면서 아키텍처 구현에 대한 판단이 계속 바뀔 수 있는 부분이 생긴다. 함수 하나를 어떻게 쪼개고, 어댑터와 프로토콜을 어느 레이어에 어떤 방식으로 하고, 객체와 서비스 범위를 어디까지 재활용하고 어디까지 범위로 묶고 등등.

아무리 좋은 명세서를 써도 실제 코드를 작성하면서 "이건 아닌데?" 싶은 순간들이 온다. 그때 AI가 혼자서 올바른 판단을 내릴 수 있을까? 내 경험상 아니다. AI는 명세에 적힌 대로 열심히 코드를 작성하지만, 맥락을 완전히 이해하진 못한다. "이 함수는 나중에 확장될 가능성이 있으니까 미리 인터페이스로 빼놓자"라든가, "여기는 지금은 간단하지만 도메인 특성상 복잡해질 거니까 별도 서비스로 분리하자"라든가. 이런 판단은 아직 인간의 영역이다.

엔터프라이즈급 대규모 SaaS를 1년 반 동안 레거시에서 마이그레이션하고 운영하면서 느낀 게 있다. 코드에서 손을 떼는 순간 아무리 개념적으로 가이드를 만들어도 실제 코드는 항상 작성자의 판단이 필요한 순간이 생긴다. 특히 초기 설계가 현실의 복잡한(+자꾸 변경되는) 요구사항과 부딪히면서 조금씩 변형되는 그 과정. 그걸 AI에게 온전히 맡기기엔 아직 이르다.

물론 바이브 코딩 시대에 모든 코드를 다 팔로업할 필요는 없다. 중요한 부분만 파악해도 충분할 수 있다. 이건 각자가 판단할 부분이다. 비전공자거나 코드 모르고 제품만 만들고 싶다면 코드를 안 봐도 된다. 코드 모르고 바이브 코딩을 하시는 분들을 나는 응원한다. 단일 컨트롤러에 raw sql 남발하는 3000줄짜리 api 코드가 있는 회사가 이미 시리즈 B를 받았다. 고객 가치가 목적이지 코드는 수단이다. 나는 개발자이기 때문에 코드를 보는 걸 선택했을 뿐이다.

바이브 코딩의 불안감

여튼 각설하고, 내가 이 방식을 정착하게 된 진짜 이유가 있다.

너무 코드 자체를 인지하지 못하고 진행하다 보니 내가 제대로 프로젝트를 매니징하는 느낌이 들지 않았다. AI에게 맡겨놓고 쉬기에는 애매하고, 돌아가는 걸 기다리며 집중력은 깨지면서 Thread를 기웃거리는 건 비단 나만의 문제는 아닐 것이다.

이런 경험 다들 있을 것이다. AI가 열심히 코드를 생성하는 동안 뭘 해야 할지 모르겠는 그 애매한 시간. 다른 일을 하자니 곧 결과가 나올 것 같고, 그냥 기다리자니 시간이 아깝다. 그래서 Thread나 유튜브를 보게 되고, 막상 결과가 나왔을 때 집중력은 이미 바닥이다. 결과를 확인하고 피드백을 해야하는데 마음이 이미 다른 데 가 있다. 이게 반복되면서 프로젝트 전체를 조망하는 감각이 점점 흐려졌다.

심리학적으로도 이건 설명이 된다. 인간은 자신이 통제하고 있다는 느낌이 없으면 불안해한다. 특히 본인의 전문 영역에서 그렇다. 개발자가 코드를 모른다는 건 마치 운전사가 핸들을 안 잡고 있는 것과 비슷하다. 차가 알아서 잘 가고 있어도, 불안하다. 심지어 목적지에 제대로 가고 있는지도 확신이 안 선다. 자율주행 기술이 아무리 발전해도 운전대를 완전히 놓는 게 불안한 것처럼, AI 코딩도 마찬가지다.

결국 AI agent는 인간이 하는 일 중에서 시간이 많이 드는 일을 자동화해주는 것이다. 다만 모든 걸 AI에게 넘기니 디버깅이 어려워졌다. '내가 이 코드를 모른다'는 인식이 커지면서 오히려 생산성이 떨어졌다. "이 코드 어디서 뭘 하는 거지?"라는 질문에 스스로 답할 수 없을 때 오는 그 막막함. 그래서 어느 정도는 컨트롤 하에 두기 위해 결국 이런 방법을 정착했다.

그리고 무엇보다 중요한 건 몰입이다. 심리학자 미하이 칙센트미하이가 말한 Flow 상태 (내 닉네임 Flowkater). 적당히 어렵고, 적당히 쉽고, 피드백이 즉각적일 때 인간은 몰입 상태에 들어간다. 바이브 코딩은 이 조건을 충족하지 못한다. 프롬프트 던지고 기다리고, 결과 확인하고, 또 프롬프트 던지고... 이 루프에서 몰입이 생기기 어렵다. 반면 체크리스트 하나씩 클리어하는 TDD 방식은 정확히 몰입의 조건을 충족한다. 작업이 너무 크지 않아서 부담이 없고, 테스트 결과가 바로 나오니까 피드백이 즉각적이다. 그래서 재밌다.

하지만 큰 단점이 있다. 느리다.

그래서 나만의 방법을 만들었다

앞서 말한 불안감을 해소하면서도, AI 시대의 생산성을 포기하고 싶진 않았다. 그래서 중간 지점을 찾았다. 켄트 백의 증강형 코딩 컨셉을 가져오되, 내 상황에 맞게 커스텀한 거다. 그 결과물이 tdd-go-loop다.

이건 단순한 커맨드가 아니라 워크플로우 오케스트레이터다. /tdd:go를 반복 실행하는 것 이상이다. spec-review, codex-review, sql-review, apply-feedback 같은 여러 하위 에이전트들을 조율하면서 전체 TDD 사이클을 관리한다. 마치 오케스트라 지휘자처럼, 각 악기(에이전트)가 언제 어떤 역할을 해야 하는지 정의해둔 거다.

내가 파악해야 하는 핵심 엔진 코드나 로직이 들어가는 API 코드, 처음 프로젝트 구조를 잡아갈 때는 무조건 /tdd:go 방식으로 진행한다. 하다 보면 느낀다. 인간과 똑같이 처음 세운 가이드라인을 오해하거나 지레짐작해서 잘못 코드를 짜는 경우가 많다. 그런 걸 잡아가면서 내가 만들고 나면, 이제 다음은 비슷한 방식의 API를 반복 개발하거나 로직을 개발하는 경우가 대부분일 것이다.

켄트 백의 증강형 코딩은 무조건 TDD 방식으로 개발하는 것을 강제하고 있기 때문에, 내가 이미 만들어놓은 코드 구조가 있으면(어떤 아키텍처나 구조든) 그 구조를 베이스로 하기 때문에 전체 코드 리뷰도 쉬워진다. 예를 들어 나는 Go에서 Usecase를 처음 구축할 때 mock 테스트로 아웃라인을 잡고, Usecase 레이어에서 도메인 모델, 함수, Repository 인터페이스를 조합해서 로직을 구현한다. mutation은 함수 최상단에 정의하고 private 함수는 최대한 순수 함수로 구성하게 지시를 하면 굉장히 human readable code가 생성되기 때문에 코드 리뷰를 편하게 할 수 있다.

이미 한번 tdd:go로 개발한 같은 패턴과 구조를 가진 API는 빠르게 진행할 수 있다. 처음 보는 패턴이나 복잡한 비즈니스 로직이 들어가는 부분만 꼼꼼하게 진행하고, 나머지는 신뢰하는 거다.

실제 내가 쓰는 구조

Claude Code에서는 .claude/ 폴더에 마크다운 파일로 커맨드와 스킬을 정의한다. 내 프로젝트의 구조를 보면:

.claude/
├── commands/                      # 단일 실행 커맨드
│   ├── tdd/
│   │   ├── go.md                 # /tdd:go - 체크리스트 하나씩 실행
│   │   ├── batch.md              # /tdd:batch - Tier 단위 배치 실행
│   │   ├── fast.md               # /tdd:fast - 전체 자동화
│   │   └── status.md             # /tdd:status - 진행 상황 확인
│   ├── tdd-go-loop.md            # 워크플로우 오케스트레이터 (핵심!)
│   ├── spec-review.md            # 스펙 리뷰
│   ├── codex-review.md           # 코드 리뷰
│   ├── sql-review.md             # SQL 리뷰
│   └── final-test.md             # 최종 테스트
│
├── skills/                        # 복합 스킬 (에이전트 포함)
│   ├── go-gin-ddd-bun/           # Go 프로젝트 아키텍처 가이드
│   │   ├── SKILL.md
│   │   ├── ARCHITECTURE.md
│   │   └── TESTING.md
│   └── api-final-review/         # 최종 리뷰 스킬 (4개 병렬 에이전트)
│       ├── SKILL.md              # 6단계 리뷰 워크플로우 정의
│       ├── AGENTS.md             # 4개 병렬 에이전트 상세 구성
│       └── templates/
│           └── test_script_template.sh
│
├── templates/                     # 문서 템플릿
│   ├── plan-template-v2.md       # plan.md 템플릿
│   └── api-review-guide.md       # 코드 리뷰 가이드
│
└── agents/                        # 하위 에이전트 정의
    ├── codex-review.md           # Codex 리뷰 에이전트
    ├── sql-review.md             # SQL 리뷰 에이전트
    └── apply-feedback.md         # 피드백 적용 에이전트

여기서 핵심은 두 가지다:

tdd-go-loop.md: 단순한 커맨드가 아니라 워크플로우 오케스트레이터. 여러 하위 에이전트들(codex-review, sql-review, apply-feedback 등)을 조율하면서 전체 TDD 사이클을 자동화한다.
api-final-review/: API 개발 완료 후 최종 리뷰를 수행하는 스킬. 4개의 전문 에이전트가 병렬로 리뷰를 실행한다.

/tdd:go 커맨드 예시

실제 /tdd:go 커맨드의 내용을 보면 이렇다:

# TDD: Go (다음 테스트 실행)

Read plan.md and find the first test marked with `[ ]` (not yet implemented).

## Execution Steps

1. **Identify**: Find the first `[ ]` test in plan.md
2. **Announce**: Tell me which test you're about to implement
3. **Red Phase**:
   - Create or update `*_test.go` file
   - Write a failing test for that specific behavior
   - Run `go test -v ./...` to confirm the test fails
4. **Green Phase**:
   - Write the minimum code to make the test pass
   - Run `go test -v ./...` to confirm ALL tests pass
5. **Update**: Mark the test as `[x]` in plan.md
6. **Report**: Summarize what was done

## Critical Rules

- Write ONLY enough code to pass the current test
- Do NOT implement features for future tests
- Always run `go fmt` on new files
- If tests fail unexpectedly, STOP and report before proceeding

심플하다. plan.md에서 [ ]로 표시된 체크리스트를 하나 찾고, Red-Green 사이클을 실행하고, 완료되면 [x]로 체크한다. 이게 전부다.

plan.md 실제 예시

Plan 생성 API(POST /plans)를 구현할 때 사용한 plan.md의 일부:

# Test Plan: Plan 생성 API (POST /plans)

**의존성**: plan_00_common.md (도메인 레이어 완료)

---

## Phase 1: Application Layer - Input 구조체 <!-- T1:auto -->

파일: `api/internal/application/plan/create.go`

### [x] 1.1 CreatePlanInput 정의

- CreatePlanInput 구조체가 모든 필수 필드를 포함한다
- ScheduleInput 구조체가 Type과 Days 필드를 포함한다
- CreateItemInput 구조체가 Name과 Quantity 필드를 포함한다

### [x] 1.2 Input 변환 메서드

- ScheduleInput.ToWeeklySchedule() 유효한 입력을 WeeklySchedule로 변환한다
- ScheduleInput.ToWeeklySchedule() 활성일 없으면 ErrNoActiveDays 반환한다

---

## Phase 5: UseCase Layer - Create Service <!-- T2:deep -->

파일: `api/internal/application/plan/create.go`

### [x] 5.1 Service 구조체

- createService 구조체가 Logger, TransactionManager, PlanWriter 의존성을 갖는다
- NewCreateService() 생성자가 의존성을 주입받는다

### [x] 5.2 Create - 검증 로직

- Create() 유효한 입력으로 Plan을 생성한다
- Create() 지원하지 않는 TemplateID에 ErrInvalidTemplate 반환한다
- Create() StartDate >= EndDate에 ErrInvalidDateRange 반환한다

각 Phase에 ,  같은 Tier 마커가 붙어있다. 이게 중요하다. Tier별로 리뷰 강도가 다르다:

Tier	의미	실행 방식	리뷰 강도
T1	Scaffold (구조 정의)	자동 진행	Light
T2	Core (비즈니스 로직)	세밀한 리뷰	Deep
T3	Integration (Repository)	자동 진행	Medium
T4	Surface (Handler/E2E)	자동 진행	Light

T2(비즈니스 로직)에서만 Deep Review를 하고, 나머지는 자동으로 넘긴다. 모든 코드를 같은 강도로 리뷰하는 건 비효율적이다. 핵심 로직에 집중하고, 나머지는 테스트가 통과하면 신뢰하는 거다.

tdd-go-loop 워크플로우 오케스트레이터

tdd-go-loop의 전체 플로우다. 단순히 /tdd:go를 반복하는 게 아니라, 여러 하위 에이전트들을 조율하는 워크플로우 오케스트레이터임을 주목하자:

flowchart TD
    start([Start])
    spec_review["spec-review 에이전트"]
    user_confirm{User Confirm?}
    find_next[Find Next Test]
    has_next{Found Next?}
    tdd_execute["TDD Cycle"]
    update_plan[Mark Complete]
    codex_review["codex-review 에이전트"]
    has_critical{Critical Issues?}
    apply_feedback["apply-feedback 에이전트"]
    commit_ask{Commit Tier?}
    is_t3{T3 Integration?}
    sql_review["sql-review 에이전트"]
    plan_done{All Done?}
    final_test["final-test"]
    finish([End])

    start --> spec_review
    spec_review --> user_confirm
    user_confirm -->|No| spec_review
    user_confirm -->|Yes| find_next
    find_next --> has_next
    has_next -->|Yes| tdd_execute
    has_next -->|No| codex_review
    tdd_execute --> update_plan
    update_plan --> find_next
    codex_review --> has_critical
    has_critical -->|Yes| apply_feedback
    has_critical -->|No| commit_ask
    apply_feedback --> codex_review
    commit_ask --> is_t3
    is_t3 -->|Yes| sql_review
    is_t3 -->|No| plan_done
    sql_review --> plan_done
    plan_done -->|No| find_next
    plan_done -->|Yes| final_test
    final_test --> finish

핵심은 Tier가 끝날 때마다 codex-review 에이전트가 자동으로 돌아간다는 것이다. Codex가 Critical/Major 이슈를 찾으면 apply-feedback 에이전트가 자동으로 피드백을 적용하고, Minor 이슈는 로깅만 한다. 리뷰가 3회 이상 반복되면 강제로 다음으로 넘어간다 (무한 루프 방지).

T3(Integration) 단계에서는 sql-review 에이전트가 추가로 돌아가서 N+1 쿼리나 인덱스 누락 같은 성능 이슈를 체크한다.

api-final-review: 4개의 병렬 에이전트

API 개발이 완료되면 최종 리뷰 워크플로우가 돈다. 이것도 4개의 전문 에이전트가 병렬로 리뷰를 수행한다:

┌─────────────────────────────────────────────────────────────┐
│                    api-final-review                          │
└─────────────────────────────────────────────────────────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│ 1. Checklist    │  │ 2. Shell/Fixture│  │ 3. Codex Agent  │
│    Agent        │  │    Agent        │  │                 │
└─────────────────┘  └─────────────────┘  └─────────────────┘
                              │
                              ▼
                    ┌─────────────────┐
                    │ 4. SQL Agent    │
                    └─────────────────┘

AGENTS.md의 실제 구성

# 병렬 에이전트 구성

API 최종 리뷰에서 사용하는 4개의 전문 에이전트 상세 구성입니다.

## 1. Checklist Agent

plan 문서의 체크박스 완료 상태를 검증합니다.

출력 형식:

- 완료율: X/Y (Z%)
- 미완료 항목: (있다면 목록)
- 판정: ✅ 완료 / ❌ 미완료 항목 있음

## 2. Shell/Fixture Agent

통합 테스트 실행에 필요한 스크립트와 픽스처 파일을 확인합니다.

확인 경로:
tests/
├── scripts/{feature}/test\_{api_name}.sh
└── fixtures/{feature}/{api_name}/
├── valid_request.json
└── invalid_request.json

## 3. Codex Agent

Tier 기반 리뷰:
| Tier | 대상 | 리뷰 깊이 |
|------|------|----------|
| T1 | Domain Entity | 가장 엄격 |
| T2 | Application Service | 엄격 |
| T3 | Infrastructure | 표준 |
| T4 | Handler | 표준 |

## 4. SQL Agent

데이터베이스 쿼리 성능 및 최적화를 검토합니다.

| 항목        | 설명                           |
| ----------- | ------------------------------ |
| N+1 쿼리    | 루프 내 개별 쿼리 실행         |
| 누락 인덱스 | WHERE, JOIN 절에 필요한 인덱스 |
| 과다 조회   | SELECT \* 사용, 불필요한 컬럼  |
| 트랜잭션    | 적절한 범위 설정               |

이 4개가 병렬로 실행되기 때문에 시간이 크게 단축된다. 하나씩 순차적으로 돌리면 10분 걸릴 일이 병렬로 돌리면 3분이면 끝난다.

배포 판정 기준

Critical	Major	Minor	판정
0	0	0-2	✅ 배포 가능
0	0	3+	⚠️ Minor 정리 권장
0	1+	-	❌ Major 수정 필요
1+	-	-	❌ Critical 수정 필수

코드 리뷰 가이드

가끔 코드 리뷰 자체가 어려울 때가 있는데, 그것도 가이드라인을 만들어서 어떤 순서로 어떻게 코드를 보면 좋을지를 정리해뒀다.

실제 내가 쓰는 T2 (Core) 리뷰 체크리스트:

## T2 (Core) Review Checklist

### UseCase Implementation

| Check                  | Question                                     |
| ---------------------- | -------------------------------------------- |
| Pure Functions         | Are helper functions pure (no side effects)? |
| Explicit Mutations     | Are all mutations visible in main method?    |
| Error Wrapping         | Are errors wrapped with context?             |
| No Business in Helpers | Is business logic in Execute, not helpers?   |

### Pure Function Verification

// GOOD: Pure function (data in, data out)
func buildListOptions(input \*ListPlansInput) plan.ListOptions {
return plan.ListOptions{
Limit: input.Limit,
Status: input.Status,
}
}

// BAD: Impure (modifies input)
func buildListOptions(input *ListPlansInput, opts *plan.ListOptions) {
opts.Limit = input.Limit // mutates!
}

이런 가이드가 있으면 Claude가 리뷰할 때도 이 기준에 맞춰서 체크하고, 나도 코드를 볼 때 어디를 집중해서 봐야 하는지 명확해진다.

시작하는 방법

요즘 Claude Code 설정이나 하위 에이전트를 어떻게 사용한다, 저렇게 사용한다 하고 사람들이 팔로업도 하고 물어도 보고 하는데, 그런데서 FOMO 느끼면서 이리저리 휘둘리지 말고 Claude Code 지금 바로 설치하고 그냥 물어봐라. 어떤 걸 할 수 있는지. 그리고 내가 하고 싶은 일들을 물어가면서 스스로 시스템을 구축하길 바란다. 그 과정 자체가 급변하는 AI 시대에 생존 스킬을 만들어줄 것이라고 생각한다.

시작하려면:

.claude/ 폴더 만들기 - 프로젝트 루트에 폴더 하나 만들면 된다
commands/ 폴더에 간단한 커맨드 만들기 - 마크다운 파일 하나가 커맨드 하나다
/커맨드이름으로 실행해보기 - Claude Code에서 바로 실행된다
필요에 따라 확장하기 - 에이전트, 스킬, 템플릿 등으로 점점 키워가면 된다

위에 것도 그냥 Claude Code 에게 요청하면 된다.

내가 만든 워크플로우, Command, Agent 다수도 사용하면서 Claude Code에게 요청해서 만든 게 대부분이다. 처음부터 완벽한 시스템을 만들려고 하지 말고 작게 시작해서 필요할 때마다 붙여나가면 된다. 이 블로그 글 또한 여러 Agent 워크플로우로 내가 막 쓴 원 글을 잘 다듬는 플로우를 만들었다.

나가며

CTO 시절에 익힌 감각이 있다. 위임하되 품질을 챙기고, 전체를 파악하되 세부는 신뢰하는 그 균형. 모든 코드를 다 볼 수는 없으니 중요한 부분에 집중하고, 나머지는 팀원들에게 맡기는 방식. 지금 AI와 일할 때도 똑같이 적용된다. AI를 유능한 주니어 개발자처럼 대하면 된다. 명확하게 지시하고, 결과물을 검토하고, 필요하면 피드백하고, 잘하면 다음 일을 맡긴다.

생각해보면 이건 리더의 역량이다. 복잡한 요구사항을 정리해서 전달하고, 핵심 의사결정에 집중하며, 세부 실행은 위임하는 것. AI 시대에는 우리 모두가 이런 방식으로 일하게 될 것 같다. 직접 코드를 치든, AI에게 맡기든, 결국 무엇을 만들지 정의하고 품질을 책임지는 건 나다. 그 감각을 익히는 게 지금 가장 중요한 스킬이 아닐까.

솔직히 작년에 퇴사하고 개인 프로젝트를 하면서 이런 실험을 할 수 있었다. 회사에서는 회의하고, 기획 조율하고, 팀원 코드 리뷰하느라 이런 걸 살펴볼 여유가 없었다. 혼자 개발하니까 눈치 볼 것 없이 이것저것 시도해볼 수 있었다. OpenCode가 막혀서 조금 아쉽지만, 26년은 또 어떻게 AI가 발전할지 걱정보다 기대가 앞선다.

결국 중요한 건 본인만의 방식을 찾는 것이다. 바이브 코딩이든, 증강형 코딩이든, 어떤 방식이든 상관없다. 다만 그 과정에서 즐거움을 잃지 않았으면 한다. 생산성만 쫓다가 코딩의 재미를 잃으면, 그게 진짜 손해다. 내가 코드를 만드는 이 일이 여전히 재밌다면, 어떤 도구가 나와도 결국 적응하게 되어 있다.

2025 고퍼콘 코리아 후기 (2025 Gophercon Korea Review)

Tony Cho (https://flowkater.io) — Thu, 11 Dec 2025 07:27:07 GMT

https://gophercon.kr/

올해가 지나면 아예 후기를 못 쓸 것 같아서 지난달 9일 마곡 코엑스에서 참여한 고퍼콘 후기를 남겨본다.

들어가며

소프트웨어 마에스트로(이하 소마) 시절 그리고 초창기 창업 시절에는 네이버 DEVIEW 같은 행사들이 많아서 이리저리 많은 행사에 참석을 했었고, 그렇게 참석을 하다 보면 다 아는 사람들 만나면서 마치 동창회처럼 서로 인사하고 들으러 다니고 했던 게 기억이 난다. 소마 때는 JCO였나.. 자바 개발자 컨퍼런스에 팀 다 같이 나가서 발표도 했었는데 그게 벌써 햇수로 10년 전 이야기가 되어버렸다. 이후에 회사를 운영하면서 실무 개발 자체에 대한 관심보다는 비즈니스와 운영에 중점을 두었기 때문에 코딩을 계속 해왔지만 거의 개발 컨퍼런스는 잘 몰랐고 코로나가 지나면서 아예 이런 행사 자체에 대한 존재를 까먹고 살았다.

이전 회사에서 간간이 팀원들이 평일에 이런 행사를 가고 싶다고 해서 승인을 해주고 보내주기도 했었다. 코로나 시기가 지나면서 이러한 컨퍼런스 발표가 대부분 유튜브에 라이브되거나 아니면 곧바로 유튜브에 업로드되었기 때문에 그냥 지나면 관심 있는 주제를 가끔 들어보거나 찾아보는 용도로 많이 활용했던 것 같다.

퇴사를 하고 간간이 스레드에 글을 쓰는데 지난 백엔드 글 및 테스트 코드 운영에 대한 스레드를 보고 한 분이 DM으로 연락이 와서 "이번 주 고퍼콘 가시나요? 오시면 커피챗 가볍게 하고 싶습니다."로 연락이 오셨다. 솔직히 고퍼콘의 존재는 알았지만 이번 주(11월 9일)에 하는 걸 전혀 몰랐고 내가 참석을 직접 한다는 아이디어 자체가 없었기 때문에 당황했는데, 그냥 개발자분들과 오랜만에 얘기도 나누고 싶고 행사도 참여하고 싶고, 내가 Go로 백엔드를 시킨 바람에 Go로 입문하게 된 George에게도 고퍼의 세계를 맛(?)보여주고 싶어서 난 후원 옵션으로 조지는 일반 티켓으로 해서 바로 티켓을 구매하고 DM 주신 백엔드 개발자분에게는 "당연히 갑니다. 그날 잠깐 뵐까요?"라고 답장을 보냈다. 스레드에서 나름 Golang 개발자라고 코스프레하는데 그냥 몰랐었다고 대답하기는 싫었던 걸까 ㅎㅎ 물론 이러한 사실은 행사 당일 연락 주신 개발자분을 만나서 말씀드렸다. 덕분에 참석하게 되었다고.

발표 후기

도중에 커피챗 한다고 한두 가지 정도를 제외하고 거의 다 들었는데, 내가 제대로 이해하고 후기를 쓸 수 있는 발표만 짤막하게 후기를 남기겠다.

동시통역 Go로 만들기 - 실시간 AI 인퍼런스, WebRTC
- 회사 이름은 기억은 안 나는데, 에듀테크 회사였고, 도메인이 도메인이다 보니 관심 있게 지켜보았다. 특히 교육에서 제일 중요한 건 "교실"이라는 공간이라고 정의하고 온라인상에서 이러한 교실 경험을 어떻게 구현할 것인가에 대해서 집중하였는데 온라인에서 교실을 Go의 동시성을 어떻게 이용해서 실시간성을 구현하고 글로벌 교실로 확장하여 LiveKit으로 실시간 번역까지 구현하면서 단계별로 챌린지를 하는 과정이 굉장히 인상 깊었다.
- 나중에 유튜브에 다시 녹화본이 올라오면 한번 다시 보고 싶은 발표였다.
Effect-ive Go: 완전히 Go다운 함수형 프로그래밍
- Go를 하면서 가장 크게 내려놓은 것 중 하나가 함수형 프로그래밍이다. samber/lo를 간혹 쓰기는 하지만, 함수형의 핵심인 불변성, 모나드, 간결한 추상화 등을 Go에서 그대로 구현하는 것은 쉽지 않고, 그렇게까지 비틀어서 쓰는 것이 "Go스럽다"는 느낌도 들지 않는다. 함수형만 파고들던 시절도 있었지만, 지금은 언어와 문제 특성에 맞게 중용을 취하는 편이 낫다고 생각해서, Go에서 Effect 패턴으로 "Go 스타일 함수형"을 어떻게 구현하는지에 관심이 갔다.
- 이 발표에서 말하는 Effect 패턴을 한 줄로 정리하면, "도메인/비즈니스 로직에서는 부수 효과를 '이펙트 메시지'로만 선언하고, 실제 DB·외부 API·로깅·동시성과 같은 사이드 이펙트 실행은 별도의 이펙트 핸들러로 위임해서, 순수성·테스트 용이성·재사용성을 극대화하는 Go 스타일 Effect Handler 아키텍처" 정도라고 볼 수 있다.
- https://github.com/on-the-ground/effect_ive_go를 보면서 코드 샘플도 따라 쳐보고, 내 기존 코드베이스(DDD/클린 아키텍처 기반 비교적 큰 백엔드)에도 대입해봤는데, 최소한 "지금 내가 가진 유즈케이스" 기준으로는 기존 계층 구조만으로도 도메인 순수성과 인프라 분리가 이미 잘 되어 있어서, 별도의 이펙트 레이어를 추가하는 것이 이득보다 개념·구현 복잡도를 더 키우는, 일종의 "배보다 배꼽이 더 큰" 패턴에 가깝다고 느꼈다.
- 다만, 이 라이브러리가 겨냥하는 지점 자체는 분명히 있다. Go가 실무에서 종종 멀티 모듈/멀티 런타임(HTTP, gRPC, 배치, 워커 등) 환경에서 쓰이고, 같은 도메인 로직을 서로 다른 인프라 조합으로 실행해야 하거나, 테스트·시뮬레이션·리플레이용으로 동일한 도메인 로직을 여러 핸들러 조합으로 "다르게 해석"해야 하는 복잡한 시스템(CQRS, 이벤트 소싱, 고도 함수형 아키텍처 등)을 설계할 때는 이야기가 달라진다. 이런 상황에서는 로깅, 트랜잭션, 재시도, 서킷 브레이커, 동시성 제어 같은 사이드 이펙트들을 명시적인 이펙트로 모델링하고, 그 처리 시점과 조합을 핸들러 레벨에서 제어할 수 있다는 점이 큰 장점이 될 수 있고, 이럴 때 effect_ive_go 같은 패턴을 실험해볼 가치는 충분히 있다고 본다.
Test Reality Not Mocks: Reliable Go Tests in the AI Era
- 내가 올린 DB Mocking 반대 글과 일맥상통한 발표였다. 거기서 조금 더 나아가서 실제 핸들러 기반의 테스트를 예시로 들었고 테스트라는 주제 자체를 조금 더 확장해서 TDD 및 Go 프로젝트에서 테스트를 조금 더 잘하기 위한 발표였다. 내가 해당 포스트 올릴 때 TDD는 안 한다고 했는데, 지금은 Claude Code와 함께 TDD 기반으로 코딩을 하고 있기 때문에 해당 발표가 많이 도움을 주었다고 볼 수도 있겠다.
Dev in Go way (Go스러움)
- 가장 고퍼콘다운 발표였다. Golang 언어 자체에 기반해서 기존의 자바의 빌더 패턴이나 객체지향 언어에서 흔히 쓰이는 패턴이 왜 Go에서 안 맞는지 Go 정신, Go idiomatic에 입각하여 어떤 코드가 Go 코드로써 좋은 코드인지 등을 알려주는 발표였다. 발표자분이 찐고수 느낌이 많이 났지만 발표 자체는 내용이 가장 쉬운 발표였고 컨퍼런스 참석자 모두가 듣기 좋았던 발표였지 않나 싶다.
- Small Interface는 현재 내가 작성하는 백엔드 코드에도 일부 적용해보고 있다. 특히 repository 인터페이스가 비대해지고 코드도 많아져서 코드 파악이 어려운 경우가 생기는데, 그냥 인터페이스도 파일도 나눠서 작업을 해버리니까 의외로 코드 파악도 Claude Code와 동시 작업 충돌도 최소화되어 적용해보고 있다.
- Accept interfaces, return structs는 이미 Go에서 클린 아키텍처를 구현하면 무조건 할 수밖에 없는 패턴이고 빌더 패턴(Go에선 err 멀티플 반환 때문에 알맞지 않다.) 대신 Options pattern을 추천하는 부분이 내 도메인 구조체 파트에서도 사용해볼 수 있을 것 같아서(생성자 옵션값이 많다면) 트라이해보고 있다.

총평

전반적으로 지난 6개월 동안 80%는 Go로 코딩을 했기 때문에 직간접적으로 전부 도움이 많이 되는 발표 내용이었다. 그래서 발표 내용 자체는 좋았다. 나도 서비스를 운영하는 상황에서 한번 발표하고 싶은데, 사실 내가 Go를 시작한 게 5년 전 이 영상 때문이었다. 당근마켓 개발팀 Go언어를 도입하다 | 당근테크 이 영상 발표자이신 변규현 님은 여전히 당근에 계신 것 같고 작년, 재작년에도 고퍼콘에서 발표를 하셨는데.. 올해는 발표자로 참석하지 않으신 것 같아서 아쉬움이 있긴 했다.

네트워킹

먼저 연락 오신 분(A님)과 중간에 스레드에서 글을 발견하고 얘기하게 된 분(B님)이 계셔서 크게 두 팀이랑 얘기하게 되었다. A님은 백엔드 개발자셨는데 캐나다인 대표님(C님)과 함께 행사에 참석하셨는데, https://humanlog.io/ 라는 Observability 서비스를 개발하고 있었다. Go 개발 주제뿐만 아니라 Observability 경험(나 같은 경우엔 Datadog 사용 경험)이나 Clickhouse 등을 얘기했는데 C님께서 Go도 알고 Observability 사용 경험도 있고, Clickhouse도 있는데 함께 해보는 게 어때라는 말을 농담삼아 말씀하시길래 맞장구 치면서 웃었다. (영어 못 알아듣는 척했다.) 그런데 재밌는 게 A님과 C님도 작년 고퍼콘에서 만난 사이라고 하셔서 확실히 A님과는 달리 C님은 사람을 찾는 목적을 가진 것도 같았다.

B님은 같이 풀타임으로 개발하고 있는 Go 개발자분(D님)과 함께 오셨는데 소상공인, 자영업자분들을 대상으로 하는 비즈니스를 하면서 어마어마한 데이터 수집을 Go를 이용해서 하고 있었다. D님이 Go를 사용하시는 분이라 해당 비즈니스 메인 언어가 Go가 되었는데 이제 본격적으로 스케일업을 하고 싶어 Go 개발자를 구하고 싶은데 주위에 워낙 없으니 컨퍼런스라도 참여해서 네트워킹을 시도해보려고 하고 계셨던 것 같다. 뭐랄까 예전에 내가 초기 창업했을 때의 그 열정이랄까 그런 게 확 느껴져서 좋은 팀이었다. Go 개발자는 당장 구하기 어려울 거라 나는 차라리 허슬할 수 있는 주니어를 뽑아서 가르치는 게 나을 수도 있다라고 얘기하긴 했지만.. 좋은 에너지가 느껴져서 괜히 더 응원하게 되는 팀이었다.

컨퍼런스의 목적 = 네트워킹

발표만 놓고 보면 솔직히 이러한 컨퍼런스가 시간 대비 효율이 나지 않는다고 생각했다. 시간표에 따라 정해진 트랙을 쭈욱 듣는 형식인데, 같은 백엔드/프론트엔드/데이터 이런 식으로 트랙을 나눠도 얘기할 범위가 너무 넓고 특히 이런 식으로 Golang이라는 언어로 묶어놓으면 더욱더 그 갭이 크다. 이번 발표도 보면 바이브 코딩부터 블록체인까지 Golang 언어를 쓰면 모두가 공감할 주제부터 당장은 크게 알아듣지도 못하고, 관심이 없는 주제도 많다는 것이다. 물론 Golang 언어와 Goroutine이라는 동시성 처리에 대한 부분 등 그래도 다들 공통적으로 얻어갈 수 있었던 발표였던 것 같다.

다만 네트워킹까지 포함하면 얘기가 달라진다. 이번에 나는 발표 2개 정도는 건너뛰고 중간에 한번, 행사 끝나는 타임에 한번 해서 행사에 오신 분들이랑 우연찮게 연락이 되어 얘기를 나누었는데 이분들의 공통적인 관심사는 채용이었다. 또는 나는 이렇게 Golang 개발을 하고 있는데, 저분들은 어떻게 하고 계시지 같은.

발표를 하게 되면 우리는 단위 시간당 발표자 한 명을 만나는 게 최선인데, 온라인에서도 충분히 들을 수 있는 발표인데 이런 행사에까지 사람들이 참석하는 건 네트워킹의 의미가 크다고 생각한다. 각자 목적과 얘기를 나누고 싶은 사람들을 위해서 공간을 마련하고 시간을 주면 단순히 발표만 듣는 거 이상으로 조금 더 유의미한 시간을 가질 수 있지 않을까.

나는 운이 좋아서 어쩌다 좋은 개발자분들을 만나서 이야기하게 되었는데 기회가 마련되었다면 조금 더 다양한 사람들과 알고 얘기 나누면 좋았을 듯싶다. 우리가 기대하는 기회라는 건 이런 스몰 토크, 커피챗, 네트워킹의 약한 연결고리가 조금씩 생기면서 갑자기 기회로 발전하기도 한다는 걸 난 지난 시간 걸어오면서 크게 깨달았다.

특히, 고퍼콘은 우리나라에서만큼은 상대적 소수 그룹에 속하긴 하지만 데브캣, 당근, 라인 등 나름 큰 기업들의 서포트도 받고 있는 유니크한 포지션을 가지고 있는 언어인 만큼 이러한 네트워킹이 활성화되면 전반적으로 국내 Go 생태계에 기여하는 부분이 훨씬 확대될 것이다.

사진

발표장에서 찍은 네임태그. Google, 당근, DEVSISTERS가 스폰서로 참여했다.

한복을 입고 태극 부채를 든 고퍼가 그려진 에코백. 한국 고퍼콘만의 매력이다.

후원 티켓 구매 시 제공된 굿즈들. 손뜨개 고퍼 인형, 스티커, 키링 등 알찬 구성이었다.

나가며

오랜만에 개발 행사 나들이가 좋았고, 같이 간 George 또한 많은 부분 느끼고 배운 부분이 있다고 해서 좋은 시간이 되었다. 괜히 트렌드만 쫓아다닌다거나 남들 가니까 가는 건 아니다라고 생각해서 어느 순간부터 이러한 행사 자체에 조금 회의적이긴 했는데, 발표도 듣고 사람들과 얘기도 나누고 하니까 좋은 경험이 되었다.

George에게 고퍼의 세계를 보여주러 간 건데, 결국 나도 뭔가 얻어왔다. 5년 전 변규현 님의 발표를 보고 Go를 시작했던 것처럼, 다음엔 나도 고퍼콘에서 발표해보고 싶다.

국내에서 Go 생태계가 조금 더 활발해지길 바라면서 후기를 마친다.

AI 시대에 신입,주니어 개발자는 무엇을 학습해야하는가?

Tony Cho (https://flowkater.io) — Sat, 06 Dec 2025 11:40:16 GMT

AI 시대, 신입의 딜레마

퇴사를 하고 혼자서 개발을 한 지 6개월이 넘었다. 지난 6개월은 그 어느 때보다 변화가 빠른 시기였다. 특히, 코딩을 하면서 그 변화를 정통으로 맞았다. 회사에 계속 있었다면 아직 그 변화를 크게 느끼지 못했을 것이다. 직접 코딩을 하며 제품을 만들고 삽질을 하다 보니 개발에서 AI 발전 속도를 있는 그대로 체감하게 된 것이다.

주위에는 미들급도 있지만, 신입/주니어 레벨도 꽤 있다. 그들을 한때는 멘토링하는 입장이기도 했고, 지금도 멘토링을 해주기도 하고 가끔 이력서를 가져오면 피드백을 해주기도 한다. 그러다 보니 자연스럽게 그들의 고민이 내 고민이 되어서 이런 저런 질문과 생각을 하게 되었다. 이 어려운 시장에서 그들이 취업을 하고 잡을 구하려면 어떻게 해야 하나? 대 AI 시대에 그저 이전처럼 포트폴리오 준비하고 부트캠프에서 프로젝트하고 블로깅하면 과연 그들이 잡을 구할 수 있는가? 그들은 도대체 어떻게 성장해야 하는가?

채용 시장의 냉정한 현실

왜 신입 채용이 줄었는가

이렇게 기술 변화가 빠른 시기에 시장은 급속도로 얼어붙어 채용은 확 줄었다. 특히, 신입 채용은 거의 씨가 말랐다. 3, 4년 전과 달리 IT 업계는 구조조정, 희망퇴직, 파산, 사업 실패 등의 여러 경험을 하기도 하고 보기도 하면서 살아남은 기업들은 정신을 똑바로 차리지 않으면 망한다는 교훈을 얻었고 어쩌면 시장이 풀려 돈이 돌아 다시 상황이 좋아져도 이때의 학습 때문에 3, 4년 전처럼 무턱대고 채용을 진행하지는 않을 것이다.

AI 때문에 개발자가 죽는다는 건 아직까지는 거짓 명제이다. 우리는 거시적 경제 흐름을 거스를 수 없고 취업난은 우리나라를 막론하고 전세계적인 이슈이다. 특히, 기업들이 곳간을 걸어 잠그면서 바로 써먹을 수 없는 즉, 키우고 가르쳐야 하는 신입 채용에는 거의 비용을 지불하지 않는다. 내일이 보일 때야 미래를 설계하는 거지 오늘 하루하루를 버텨야 하는 지금으로선 그 모든 것이 낭비이다. 하지만 그런 원인(세계적 경제난)에 의한 현상(취업난)이 AI로 인하여 가속화되는 건 참 명제이다.

기업이 원하는 사람

지금 가장 많은 채용 공고가 올라오는 것이 미들, 즉 4년~6년 차 정도인데, 3, 4년 전 소위 개발자 호황에 잘 진입했던 많은 분들은 시장의 어려움에도 상대적으로 이직을 수월하게 하는 모습을 종종 본다. 하지만 이제 막 개발을 공부해 보려고 하거나 개발을 막 시작한 신입, 주니어들은 취업/이직을 아예 못하거나 운이 좋게 취업이 되더라도 제대로 된 학습 기회를 얻지 못하는 실정이다.

미들급을 많이 채용한다는 건 현재 프로젝트에 바로 투입 가능한 사람을 뽑는다는 것이다. 신입인 이상 실제 운영하는 프로젝트를 만들어 보거나 운영해 본 경험은 전무할 것이다. 그러니까 지금 신입이 채용 시장에서 경쟁력을 가지려면 협업하여 만든 팀 프로젝트를 실제 사용자들이 쓰는 환경에서 배포해보고 운영한 경험이 필요하다는 것이다. 한 명의 개발자가 마케팅과 운영까지 신경 쓰면서 무언가를 하나 만들어서 운영까지 해보는 경험은 쉽지 않다. 아니 어렵다. 그런데 지금 기업들은 그런 사람을 채용한다.

AI는 신입에게 양날의 검이다

AI는 신입에게는 양날의 검이다. 아주 구태의연한 비유인데, 뭐랄까 휘두르면 휘두를수록 내가 더 많이 베이는 검이랄까. AI가 있으면 모든 걸 다 능동적으로 물어보고 공부해 볼 수 있고 쉽게 할 수 있고 이제 전통적인 교육은 사라지고 정말 누구나 무엇을 할 수 있겠다라고 말하는 사람들이 종종 있다. 나도 내가 '잘' 알고 있는 개발 분야는 그렇게 학습할 수 있고 그렇게 학습하고 있다. 서점에서 개발 서적 코너를 언제 갔는지 가물가물하다. 예전에는 교보문고에 들르기만 하면 무조건 들러서 무슨 책이 나오는지 보곤 했다. 지금은 거의 가지 않는다.

무엇을 모르는지 모르는데 어떻게 질문하나

하지만 내가 새로운 분야를 공부한다고 하면 바로 AI를 활용할 수 있을까?

최근에 일본어 공부를 해보고 싶어 AI로 문장도 찾아보고 이것저것 하다가 결국 교재와 강의를 구매했다. 처음 시작하는 사람은 무엇을 질문해야 하는지조차 모른다. 머신러닝에 비유하자면 어느 정도 데이터셋으로 프리 트레이닝 되지 않으면 아무것도 할 수 없다.

그래서 나는 신입들을 멘토링할 때 Claude Code와 같은 AI 에이전트를 최대한 사용하지 말라고 한다. 누군가 이 얘기를 들으면 시대착오적인 조언이라고 할 수 있다. 그렇게 볼 수도 있겠다. 하지만 무엇을 모르는지도 모르는 상태에서 작업의 대부분을 AI 코딩 에이전트에게 모두 맡기게 되면 나의 모든 학습/성장 기회를 잃게 된다. AI 덕분에 모두가 무엇을 만들 수 있지만 AI 때문에 모두가 배우지 못하는 시대가 되었다.

AI 에이전트와 검색/질문의 차이

여기서 말하는 조언은 비개발자인데 바이브 코딩으로 제품을 만드는 사람(사업가)이 아니다. 전문 개발자로 성장하고 싶은 분들에게 하는 조언이며, 이건 꼭 개발 분야가 아니더라도 내가 전문성을 가져야 하는 분야에서 모든 걸 AI에게 맡기게 되면 제대로 성장할 수 있는 기회를 얻기가 힘들다. 물론, 검색하고 모르는 걸 물어보고 할 때 AI를 사용하는 건 권장한다. (내가 말하는 사용하지 말아야 하는 건 모든 걸 대신 해주는 AI 코딩 에이전트이다.)

AI가 없던 시절에도 Stack Overflow에서 원인 분석보다는 오류 검색해서 동작하는 코드를 그대로 복사 붙여넣기 하는 일은 비일비재했다. 다만, 내가 문제를 직접 AI에게 물어보는 것과 아닌 것의 차이일 것이다. 그리고 생각보다 그 주체가 나에게 있는지, AI에게 있는지에 따라 문제를 해결하고 무언가를 만들어가는 과정에서의 학습이 나의 것이 되는지, AI에게 버려지는지가 결정이 된다.

그럼 AI를 어떻게 써야 하나

구체적으로 말해보겠다. 신입이 AI를 쓸 때 지켜야 할 기준은 "내가 먼저 시도했는가"이다. 에러가 났을 때 에러 메시지를 먼저 읽어라. 그리고 왜 이 에러가 났을지 가설을 세워봐라. 그 다음에 AI에게 물어봐라. "이 에러 어떻게 해결해?"가 아니라 "이 에러가 난 이유가 A인 것 같은데 맞아?"라고 물어보는 거다. 이 차이가 크다. 코드를 작성할 때도 마찬가지다. 일단 내가 먼저 쳐봐라. 막히면 어디서 막혔는지 파악하고, 그 부분만 물어봐라. "로그인 기능 만들어줘"가 아니라 "세션 유지가 안 되는데 이 부분 로직이 잘못된 건가?"라고 물어보는 거다.

정리하면 이렇다.

이렇게 쓰자:

에러 메시지 읽고 가설 세운 뒤 검증 요청
내가 작성한 코드에 대한 피드백 요청
개념이 헷갈릴 때 설명 요청
내 풀이가 끝난 후 다른 접근법 질문

이건 피하자:

요구사항 던지고 전체 코드 생성 요청
에러 메시지 읽지도 않고 바로 붙여넣기
"이거 왜 안 돼?"라고만 물어보기
AI가 준 코드 이해 없이 복붙

결국 주체가 나에게 있어야 한다. AI는 내 학습을 도와주는 도구이지, 나 대신 학습해주는 존재가 아니다.

지금 신입이 길러야 할 것들

앞서 문해력, 실전 프로젝트, 코딩 테스트 얘기를 할 건데, "그래서 뭘 먼저 해야 하나요?"라는 질문이 나올 것 같다. 솔직히 말하면 상황마다 다르다. 하지만 굳이 우선순위를 매기자면 이렇다.

당장 면접이 잡혀 있다면: 코딩 테스트와 프로젝트 정리가 먼저다. 문해력은 하루아침에 올라가지 않는다.
3개월 이상 여유가 있다면: 독서와 글쓰기를 병행하면서 실전 프로젝트를 시작해라. 코딩 테스트는 매일 1문제씩 꾸준히.
6개월 이상 긴 호흡으로 준비한다면: 문해력부터 쌓아라. 이게 결국 다른 모든 학습의 속도를 결정한다.

중요한 건 세 가지 모두 "해야 할 것"이 아니라 "습관"이 되어야 한다는 거다. 취업 준비 기간에만 반짝하고 끝낼 게 아니다. 책 읽기, 프로젝트 운영, 문제 해결 훈련은 개발자로 일하는 동안 계속 해야 할 일이다. 지금 시작하는 게 빠르다.

문해력 - 읽고 쓰는 능력

최근 멘토링을 했던 경험을 생각해보면, 가장 큰 문제가 되는 것이 문해력이다. 대 AI 시대에 어쩌면 코드보다 글을 읽고 쓰는 능력이 더 중요해진 것 같다. 특히 요즈음 AI 모델은 하나의 질문에 어마어마한 답변을 쏟아내는데 그걸 제대로 읽고 이해하고 소화해서 나에게 맞는 솔루션을 적용하는 것도 문해력이다. AI에게 적절한 질문을 하는 것도 마찬가지. AI와의 소통 외에도 결국 조직에 들어가면 사람들과 커뮤니케이션할 것이고 상대방의 얘기에서 핵심을 이해하고 소화해서 내 의견을 정리해서 말을 하는 것도 문해력에서 확장되고 길러질 수 있는 능력이다.

개발자 취업을 준비하는 사람이 나에게 무엇을 준비해야 할까요?라고 하면, 나는 프로젝트보다 알고리즘보다 책을 많이 읽으라고 얘기한다. 그리고 책을 읽고 그 내용에 대해 내 생각을 정리하고 다른 사람과 많이 얘기해 보고 글로 써보라고 얘기한다. 그게 단기적으로 문해력을 올릴 수 있는 가장 빠른 방법이다. 모든 콘텐츠가 숏폼인 대 쇼츠의 시대에 딱 하나 남들보다 앞서가며 가져갈 수 있는 경쟁력은 독서이며 글쓰기이다. 이게 뒷받침되어 준다면 내가 개발자를 목표로 하든, 다른 분야를 학습을 하든 훨씬 빠르게 성장할 수 있을 것이다.

책을 많이 읽은 사람이 성공하지는 않는다. 하지만 내가 본 성공한 창업가들은 모두 다독가였다. 메타인지가 되고 현재의 현상을 파악하고 학습하여 빠르게 액션 아이템을 가져가는 사람들도 모두 다독가였다. 가끔은 그들과 알게 모르게 이전에 읽었던 책에 대한 내용을 얘기하면 내가 읽었던 건 모두 읽은 사람들이 대부분이었다. 성장이 멈추고 계속 같은 실수를 반복하는 사람들은 대부분 책 읽기를 멈춘 사람들이었다.

책 많이 읽으라고 하면 "무슨 책을 읽어야 하나요"가 따라오는 질문이다. 정말 내가 책과 담을 쌓고 있다고 생각하는 분들은 아무 책이나 읽어라. 얄팍한 자기계발서도 괜찮다. 그게 얄팍한지 아닌지는 내가 읽고 판단하는 거니까. 다만 빠르게 문해력을 올리고 싶으면 글을 쓸 수 있는 책을 읽어라. 소설을 읽고 감상을 쓰든, 경영 서적을 읽고 내 생각을 정리하든 남들에게 내 생각을 공유할 수 있는 책을 읽는 게 본인의 성장을 가속화시킬 것이다. 특히, 2~3권 정도 내가 성장을 위해 책을 읽는다면, 남들이 추천하는 소설책 한 권 정도는 읽어주면 좋다. 소설은 우리의 메타인지와 공감 능력을 생각하지 못하는 사이에 성장시킨다.

실전에 가까운 프로젝트 경험

전문 지식을 아무리 깊이 쌓아도 혼자서 공부하는 데에는 한계가 있다. 부트캠프나 학원에서 한두 달 진행한 버려지는 프로젝트들은 기업 입장에서는 아무런 감흥을 주지 못한다. 현재 시장이 요구하는 현실을 직시하고 실제와 가까운 프로젝트가 무엇인지 고민하고 그런 경험을 쌓은 사람이 차별성을 가질 것이다. 오히려 개발자는 AI 도움이라도 받을 수 있지, 다른 분야는 기업에 들어가기 전에 그런 경험 자체가 희소하기 때문에 역설적으로 더 좋게 생각해야 한다. 실전에 가깝다는 건 작은 기능이라도 직접 배포하고 사용자를 모집하고 그 모집한 사용자에게 피드백을 받고 기능을 개선해본 경험이다. 대부분 신입 포트폴리오가 토이 프로젝트에 끝나기 때문에 직접 운영 환경에 배포해보고 개선시킨 경험만 있어도 크게 차별성을 가질 수 있고, 거기에 더해 버그를 수정하고 사용자에게 피드백을 받는 경험을 해나가면 좋다. 어느 시기에 있든 지금 시장에서 취업은 인내를 필요로 하고 그 시간을 단순히 공부하느라 낭비하지 말고 실전적인 경험을 쌓을 수 있는 프로젝트를 탐색하고 기획해 보고 진행해 보아라. 10명이라도 쓰는 걸 만드는 것과 버려지는 프로젝트를 만드는 건 전혀 다른 성장 기회를 제공할 것이다.

코딩 테스트 - 암기가 아닌 문제 해결 훈련

신입 개발자들이 마지막으로 AI가 다 해주는 시대에 코딩 테스트를 공부하는 게 의미가 있냐고 많이들 물어본다. 그리고 실제로 실무에서도 알고리즘 코딩 테스트는 원래도 무쓸모였고 이제 더 의미가 없다라고도 말한다.

사실 이 얘기가 사실이면서도 사실이 아닌 점이 있는데, 알고리즘 자체가 쓸모 있냐라고 하면.. API 만들면서, UI 구현하면서, 동적 프로그래밍을 우리가 쓸 일은 거의 없다. (일반 SaaS, B2C 서비스 한정) 차라리 앞서 말했듯 책 많이 읽는 게 직접적인 연관성은 더 높을 것이다. (미팅하고, 문서화하고) 다만, 동적 프로그래밍을 도메인 지식이라고 보면 현재 주어진 문제를 어떻게 풀지를 연습하는 과정은 개발자에게 필수적인 학습 과정이라고 생각한다.

즉, 자료구조와 알고리즘 이론과 문제 풀이를 외우듯이 코딩 테스트를 준비하는 것은 1도 도움이 안 된다. 우리는 어떤 회사 어떤 도메인, 프로젝트에서 항상 새로운 고객, 새로운 요구사항에 마주할 수 있기 때문에, 우리가 여기서 알아야 할 것은 알고리즘이라는 형식지가 아닌 그 문제를 푸는 과정에서 습득하는 암묵지이다. 문제가 주어지고 내가 어떻게 풀지 생각을 정리하고 그걸 코드로 옮기고. 여전히 빅테크에서 알고리즘 인터뷰를 중요하게 보는 이유라고 생각한다. 우리가 포트폴리오 프로젝트를 하면서 10개의 서로 다른 고객 요구사항을 분석하고 모두 구현하기에는 현실적으로 쉽지 않지만, 알고리즘 문제를 풀면 매 문제마다 새로운 환경과 정보에서 문제 푸는 과정을 연습할 수 있다. 이러한 의도적 수련이 담보된다고 할 때 알고리즘 코딩 테스트는 굉장히 큰 도움이 될 것이다. 그리고 내 풀이가 끝나고 나서 AI에게 피드백을 요청하면서 다각도로 지식과 경험을 확장하는 과정이 동반되면 더할 나위 없이 좋다.

마무리 - 여전히 사람이 필요한 이유

언젠가 우리의 직업들이 모두 AI에 대체되는 시기가 올 수도 있겠다. 하지만 아직은 사람이 직접 드라이브를 해야 한다. 시장이 위축되어 채용이 줄어든 거지, 채용 자체가 없는 건 아니다. 이렇게 빠른 기술 발전을 이루고 있음에도 여전히 기업에서는 채용을 진행하고 사람을 필요로 한다. 조직을 운영해 보면 코딩 그 자체보다 사람이 기회인 동시에 문제인 경우가 더 많다. 아마 다른 분야도 비슷할 것이다.

내가 기업 채용 담당자이거나 오너라고 할 때 어떤 사람이랑 일하고 싶을까? 그 기준에 비해 나는 무엇이 부족한가? 그런 부분들을 잘 생각해 보면 생각보다 준비해야 하는 것들이 명확하다. 기업은 조직(사람)에 10을 투자해서 11을, 20을, 100을 얻으려고 할 것이다. 스스로가 조직 전체 성장에 기여할 수 있는 사람인지 취업을 하고 나서도 항상 고민해야 한다.

시장이 어렵다. 이럴 때는 나의 길을 가면서 "진인사대천명"의 마인드로 "정진"하는 자세가 필요하다. AI 때문에 어쩌고저쩌고 한마디 얹을 시간에, 하염없이 쇼츠를 보고 있는 시간 대신에 책을 읽고 내 생각을 정리해라. 능숙하지 않더라도 꾸준히 해보길 바란다. 그리고 공부하려고 하지 말고 일을 하듯이 프로젝트를 진행해 보아라. 또한 암기하려고 하지 말고 과정을 훈련하듯이 코딩 테스트를 연습해라.

시대를 거스를 수 없다. 인간 개인은 나약하다. 인간은 환경에 쉽게 휩쓸린다. 좋은 성과가 나올 때는 대부분 환경도 따라줬기 때문이다. 내가 잘해서 취업을 한 것 같지만 시장이 좋아서 일수도 있고(또는 타이밍이) 조직에서의 내 성과는 보통 조직의 시스템에 기반하기 때문이라는 것은 업무를 해본 모두가 공감할 것이다. 즉, 내가 잘했다고 자만해서도 안되고 내가 못한다고 자괴감에 빠질 필요도 없다. 시대를 이길 수는 없지만, 오늘 하루를 이길 수는 있다. 스스로 자신을 돌아보면 지금 이 순간 무엇을 해야 할지 이미 알고 있을 것이다.

신입 개발자들을 멘토링하면서 떠오르는 생각들을 러프하게 정리해 보았다. 이 글이 개발자뿐만 아니라 격변하는 AI 시대에 성장하고자 하는 모든 신입들에게 조금의 도움이라도 되었으면 좋겠다.

Scrumble 기술 회고 - 2. 프론트엔드, 그리고 바이브 코딩을 곁들인

Tony Cho (https://flowkater.io) — Fri, 03 Oct 2025 12:24:55 GMT

Scrumble 프론트엔드 구현 사항 요약

기본적으로 SNS 이기 때문에, 글도 쓰고 그 글에 반응(이모지), 댓글, 그리고 콘텐츠에는 이미지 첨부도 필수적으로 들어간다.
유저 인증을 한 이후에 다시 워크스페이스 내에서 멤버로 인증을 하기 때문에 기본적으로는 멤버 인증 기반이다.
백엔드 편에서도 말했듯이 실시간 처리 (알림, 이모지, 댓글 모두 실시간 처리가 필요했다.)
투두 리스트는 최대한 심리스하게 작성하기 위해 키보드 단축키 매핑 처리가 필요했다.

기술 스택

프레임워크: Next.js 15.1.8(App Router) + React 19, 개발 서버는 Turbopack
언어: TypeScript 5
스타일링: Tailwind CSS 3.4, tailwind-merge, class-variance-authority, Pretendard 폰트, PostCSS/Autoprefixer
상태·데이터: 클라이언트 상태는 Zustand 5, 서버 통신은 TanStack Query 5 + Axios 1.9
실시간: centrifuge 클라이언트로 Centrifugo 연동(자동 재연결·채널 유지)
파일·미디어: Cloudflare R2 프리사인드 업로드, HEIC → 웹 포맷 변환 유틸리티(heic2any, libheif-js)
UI/UX: Framer Motion 12, Emoji Mart, Lucide/Remix 아이콘 세트, React Day Picker, React Window 가상화
PWA: next-pwa 5.6.0 서비스 워커 + 매니페스트 설정

아키텍처

개요

Next.js 15 App Router가 라우팅/레이아웃, 그리고 서버·클라이언트 컴포넌트 경계를 책임진다. 전역 프로바이더는 src/app/providers.tsx 하나로 묶어서 관리했다.
페이지 컴포넌트는 화면 보여주기와 인터랙션만 맡긴다. 조회/변경/실시간 동기화 같은 건 전용 훅으로 빼서 화면을 최대한 얇게 유지했다.
제품 기능은 src/features/* 안에 UI·훅·서비스·로컬 Zustand 스토어를 한 덩어리(수직 슬라이스)로 묶어 도메인 단위로 구성했다.
공유되는 UI/컨텍스트/서비스/유틸은 전부 src/shared에 모아, 각 도메인 모듈이 핵심 로직에만 집중할 수 있게 했다.

애플리케이션 셸 (`src/app`)

App Router 디렉터리(page.tsx, layout.tsx, loading.tsx 등)에서 라우트 표면, 지연 로딩, 메타데이터를 정의했다.
providers.tsx에 QueryClientProvider와 인증/시간대/글로벌 로딩 컨텍스트를 한 데 묶어 등록했다. 전역 훅들이 같은 쿼리 클라이언트를 바라보게 하려는 의도다.
spaces, auth, 동적 세그먼트([spaceSlug]) 같은 라우트 그룹은 기능 도메인과 1:1로 매핑했고, 말단 페이지는 보통 src/features/**/pages 진입점을 호출해 로직을 위임한다.
src/app/api/*의 API 라우트는 필요할 때만 서버 사이드 브리지로 백엔드와 통신한다.

기능 모듈 (`src/features/*`)

components, pages, hooks, services, stores, types, utils, data를 한 폴더 안에 묶는 수직 슬라이스 레이아웃을 따른다. 도메인별 UI와 로직을 한곳에 둔다.
기능 페이지는 공유 레이아웃과 도메인 컴포넌트를 조합하는 얇은 래퍼 역할만 한다.
훅이 조회/변경 로직과 부수효과를 감싸고, src/shared/hooks/queries의 TanStack Query 헬퍼와 도메인 서비스를 끌어다 쓴다.
로컬 Zustand 스토어(stores)에는 외부로 새지 않는 일시적 UI 상태만 넣었다.
기능 서비스는 공유 API 클라이언트를 가져다 써서 도메인별 포매팅, 낙관적 업데이트, 파생 모델을 구현한다.

공유 레이어 (`src/shared`)

components: Tailwind + class-variance-authority 기반 디자인 시스템 컴포넌트(피드백, 내비게이션, 입력 등).
hooks: 재사용 가능한 쿼리 훅(queries/*), 인증 도우미, 실시간 구독 훅으로 데이터 패칭/상태 오케스트레이션을 숨긴다.
services: centrifugo.service.ts 같은 인프라 서비스, 파일 업로드 도우미, 분석 로거 등 공통 기능을 제공한다.
contexts: 애플리케이션 셸이 쓰는 인증·시간대·전역 로딩 컨텍스트를 제공한다.
stores: 인증 상태, 토스트, 시간 유틸리티 등을 위한 전역 Zustand 스토어다.
lib: 리소스별 Axios API 클라이언트, 토큰 매니저, 폰트, API 헬퍼 등 저수준 통합을 담당한다.
types와 schemas: 기능과 API 계층에서 공유하는 타입 정의와 검증 스키마 조각.
utils: 포매팅, 에러 처리, 범용 헬퍼를 제공.

데이터 및 상태 흐름

src/shared/lib/api/*.ts에 Axios 클라이언트를 모아두고, 기본 URL·인터셉터·토큰 갱신 로직을 중앙에서 처리한다.
src/shared/hooks/queries의 쿼리/뮤테이션 훅으로 TanStack Query 키와 캐싱 정책을 표준화해, 기능 모듈이 안전하게 조합할 수 있게 했다.
전역 상태는 shared/stores의 가벼운 Zustand 스토어에, 기능별 상태는 해당 기능 폴더 안의 로컬 스토어에 둔다.
폼은 대부분 React Hook Form + Zod를 쓰고, 필요하면 공유 Resolver 유틸을 참고한다.

실시간 동기화

CentrifugoService가 단일 Centrifuge 클라이언트를 유지하면서 재연결, 채널 영속화, 이벤트 디스패치를 맡는다.
실시간 훅은 새 소켓을 열지 않고 중앙 Centrifugo 레이어를 확장해, 모든 기능이 같은 연결/이벤트 버스를 재사용한다.
이벤트를 받으면 훅이 TanStack Query 캐시나 로컬 스토어를 즉시 갱신해, 추가 리페치 없이 UI를 맞춘다.

UI 구성과 스타일링

스타일링은 Tailwind CSS + PostCSS가 베이스고, class-variance-authority와 tailwind-merge로 변형 클래스를 안정적으로 조합한다.
애니메이션/마이크로 인터랙션은 Framer Motion, 아이콘/이모지는 Lucide·Remix Icons·Emoji Mart 같은 공유 라이브러리를 쓴다.
반응형 동작과 가상 스크롤(React Window)은 재사용 컴포넌트로 분리해, 페이지 코드는 선언적으로 유지했다.

테스트와 개발 경험

Jest + React Testing Library로 훅/컴포넌트 단위, Playwright로 E2E 회귀 시나리오를 검증한다.
TypeScript 엄격 모드, ESLint, npm run build(Next.js + SWC/Turbopack)로 커밋 전 타입·린트·빌드 안정성을 챙겼다.
shared/utils/debug, 토큰 매니저 등 공용 도구로 환경 전반에서 일관된 디버깅과 저장 전략을 유지한다.

하이레벨 모듈 상호작용


graph TD

subgraph "앱 라우터 (src/app)"

app_pages["페이지 & 레이아웃"]

app_providers["글로벌 프로바이더"]

end



subgraph "기능 모듈 (src/features/*)"

feature_pages["기능 페이지"]

feature_components["기능 컴포넌트"]

feature_hooks["기능 훅"]

feature_services["기능 서비스"]

feature_stores["로컬 Zustand 스토어"]

end



subgraph "공유 레이어 (src/shared)"

shared_components["공유 UI 컴포넌트"]

shared_hooks["공유 훅"]

shared_contexts["공유 컨텍스트"]

shared_services["인프라 서비스"]

shared_stores["공유 스토어"]

shared_lib["API & 토큰 라이브러리"]

end



subgraph "인프라"

tanstack["TanStack Query 클라이언트"]

axios_client["Axios 리소스 클라이언트"]

centrifugo_service["Centrifugo 서비스"]

backend[("REST API 백엔드")]

centrifugo[("Centrifugo 허브")]

end



app_pages --> feature_pages

app_providers --> tanstack

app_providers --> shared_contexts



feature_pages --> feature_components

feature_pages --> feature_hooks



feature_components --> shared_components

feature_hooks --> shared_hooks

feature_hooks --> feature_services

feature_hooks --> feature_stores

feature_services --> shared_services



shared_hooks --> tanstack

shared_services --> axios_client

shared_services --> centrifugo_service

shared_stores --> feature_components



tanstack --> axios_client

axios_client --> backend

centrifugo_service --> centrifugo

shared_hooks --> centrifugo_service

feature_hooks --> tanstack

feature_hooks --> centrifugo_service

구현 상세 회고

스타일

Tailwind CSS를 대부분 사용했는데, Claude Code 를 적극 이용해서 직접 스타일 작업을 거의 줄였다. 바이브 코딩에 관련한 영상을 찾아보면 대부분 디자인 시안 기반이라기 보다는 내가 벤치마킹하고 싶은 사이트에서 가져오는 팁들이 많은데, 실제 프로덕트 디자이너(Ellie)와 협업하는 내 입장에서는 그러한 팁들은 쓸모가 없었다.

CSS Vibe

4, 5월즈음 MCP 가 유행처럼 붐을 일으켰는데, 특히 Figma MCP 를 이용해서 MCP만 연결하면 마치 Cursor 나 Claude Code 로 거의 자동으로 구현할 수 있을 것 처럼 얘기를 하는데, 이게 실제로 해보면 절대 그렇지가 않다. AI 가 어느정도 이미지 인식 기능을 지원하지만 정확도가 아주 떨어지고 Figma MCP를 읽어와도 내부적으로는 Figma 의 이미지 객체의 속성들을 읽어와서 처리하는데 결국 LLM이 텍스트 기반 모델이기 때문에 100% 구현을 하지 못하고 해메는 경우가 많다.

작업을 하는 디자이너에게 Figma 디자인을 네이밍부터 레이아웃까지 디테일하게 잡아달라고 요청하면 좋지만, 실제로 디자이너가 그걸 한땀한땀 구성하는 것보다 내가 대략적인 스타일 속성을 하나씩 가져와서 프롬프트로 넘기는게 훨씬 효율적이다. 즉, MCP 는 처음 몇 번 말고 유용하게 쓰지 않고 있다. 추후 내가 AI로 코딩하는 방법에서도 언급하겠지만, 지금 시점에서 playwright 이나 context7 등 여러 MCP 를 나는 쓰고 있지 않다.

MCP 에 대한 얘기도 요즈음 잘 없는 것 보면 "연동이 된다"는 것과 실제로 "동작을 한다"는 다르고 "연동이 된다"라는 초기 얘기는 많았지만 MCP를 토이 프로젝트나 MVP, 프로토타입 프로젝트가 아닌 정말 실무 프로덕션 레벨이나 협업 레벨에서 정말 잘 쓰고 있다는 후기는 거의 찾아보기 힘들다. 물론 이건 내가 잘 몰라서 하는 소리다. 그런데 나는 MCP를 연구하는 시간에 내가 조금 더 부지런해지기로 택했다.

다시 구현으로 돌아와서, 나는 결국 Figma Dev mode 에 나오는 스타일 값들을 텍스트로 직접 가져와서 해당 컴포넌트마다 구현하는 방법을 택했고 이렇게 진행하면 처음이 조금 귀찮긴 하지만 90% 정도는 구현이 되어서 약간만 손을 보면 된다. MCP 로는 30%만 구현이 되고 프롬프트로 씨름하는 일이 많았다보니 지금은 이게 내 작업 흐름을 유지하는데 더 편한 것 같다.

다른 얘기인데, 몇 가지 화면을 테스트로 디자인 없이 Claude 가 제시해주는 디자인만 가지고 구현해보려고 했으나 뭔가 Claude 자체가 만드는 디자인은 워낙 구리기도 하고 결국 내가 프롬프트에 엄청 심혈을 기울여야 하는데 도대체가 완성의 기준을 모르겠어서 포기했다. 나는 실력있는 프로덕트 디자이너 파트너가 있다는 것이 전제이니 혼자서 개발하거나 디자인 리소스가 없는 사람에게는 여전히 MCP 나 벤치 마킹을 통한 바이브 코딩이 유효할 것이다. 다만, 완성에 대한 기준을 항상 가지고 접근하라.

상태 관리

상태관리는 zustand 를 일부 쓰긴 하지만, UI 전역 처리를 위한 일부(최근 선택한 날짜 저장 등)에서만 사용을 하고 대부분은 Tanstack Query(a.k.a React-query) 로 관리를 한다.

React-query

React-query는 자체 캐싱부터 UI 상태 업데이트를 위한 여러가지 기능들이 제공되는데 확실히 초반 러닝 커브가 상당하다. 특히, 단순 API가 아닌 인증 미들웨어를 끼우고 작업을 하면 access token 만료시 마다 자동으로 refresh 로직 동작을 해줘야 하는데 10년 넘게 해온 이 작업을 react-query 와 axios api 요청 레이어에서 혼동을 일으켜서 (사실은 claude code 가 코드를 중복 생성했는데 발견을 못했다.) 초반에 access token 만료 후 무한 리다이렉션 현상이 일어나서 다시 처음부터 claude 가 만든 react-query 코드 하나하나 리뷰하며 문제를 해결했다. 코드를 읽었으면 5분이면 해결될 문제였는데 react-query 코드를 읽기 싫어서 딸깍으로 해결하려했더니 1시간은 넘게 날렸다.

MVP가 아닌 이상 바이브 코딩으로만 접근하면 얼마나 깨지기 쉬운 소프트웨어가 만들어지는지 그 뒤에도 숱하게 겪었지만 이 경험이 그 첫번째 경험이었다. 코드를 읽을 줄 안다면, 코드를 읽어라. 그게 더 빠르다. (아직은)

React-query 는 자체 캐싱 관리를 해주는데, gql-apollo 에서도 캐싱 등의 기능을 제공해주기도 하고 개발 경험이 있지만, 그것보다 조금 더 더 심화되어 있고 풍부한 기능을 제공해준다. 서버에서도 캐싱(redis)을 제공해주다보니 뭔가 복잡해지면 캐싱 설정이 굉장히 어려울수도 있겠다 싶었다. 지금이야 풀스택 개발이니까 큰 문제없지만(내가 모든 정책을 알고 있으니) 백/프론트가 나뉜 상황에서 캐싱이 적용되면 잘못된 정책으로 버그 아닌 버그 현상이 발생할 수 있는 위험도 있을 것이다. 백엔드 파트 아키텍처에서 인터페이스 레이어를 가지고 있고 API라는게 클라이언트 유즈케이스에 맞추어져 있다보니 이 부분을 잘 설계해야한다고 생각한다. 캐싱은 잘하면 그만큼 유저 경험(속도), 부하도 줄여줄 수 있지만 잘못하면 유저가 기대하지 않은 값을 보여줄 수도 있으니 말이다.

Optimistic UI

백엔드 파트에서도 언급했듯이 초기 인프라 리전 딜레이 이슈 때문에 API 딜레이가 초기에 굉장히 길었다. (피드 화면은 2초 이상..) 그렇다보니 인프라 변경을 하지 않은 상태에서 (최대한 살려보려고 했으니) 가장 먼저 접근했던 방법은 Optimistic UI 이다.

Optimistic UI 의 핵심은 일단 React-query 의 내부 상태에 먼저 해당 업데이트를 반영하면 UI에 즉각 반영이 됨으로 사용자는 딜레이 없는 UX를 경험할 수 있고, 백그라운드로는 해당 api request 가 진행되어 response 를 받아와서 만약 상태가 다르거나, 서버에서 오류를 반환하면 다시 클라이언트 UI 상태를 롤백하는 방식이다.

해당 방식을 처음 적용했을때는 자잘한 UI 이슈가 존재했었고 대표적으로 처음 UI 상태를 바꾸고, 뒤에 response 를 받아와서 다시 깜빡이는 이슈였다. 이건, 서버에서 응답받아 온 값을 한번 더 UI에 업데이트 치는 작업이었고 이게 항상 최신 서버 상태를 보장하긴 하지만, UX적으로 깜빡이는 이슈가 생겨서 응답을 받아왔을때 문제가 없으면 따로 추가로 업데이트하지 않도록 변경하였다.

실시간

체크인이나 체크아웃에 리액션으로 이모지를 달거나 댓글을 달면 실시간으로 업데이트가 된다. 즉, 내가 접속해있는 space 에서 이러한 피드백 액션이 일어나면 실시간으로 업데이트 되어야하는데, go, Centrifugo(redis) 로 웹소켓을 잘 구현해놓은 상태에서 계속 실시간 업데이트가 씹히는 경우가 발생하여 초반에 굉장히 애를 먹었다. 초반에는 서버 웹소켓 이슈인가 했는데 만약 Centrifugo 이슈였다면 같이 달아놓은 ClickUp 연동 실시간 트리거도 동작을 하지 않았어야 했는데, 아주 잘 동작하는 걸 봐서는 클라이언트 이슈였다.

웹소켓 채널을 효율화하고 성능을 분산하기 위해서 피드에는 포스트가 여러 개이고 여러 개의 포스트를 ID로 채널로 구독을 하게 했는데, 스크롤을 해서 해당 포스트가 화면에서 벗어나거나 다시 인식하면 다시 핸들러가 포스트 ID 웹소켓 채널을 구독하는 방식이었다.

이 방법은 매번 모든 Post ID 채널을 구독하고 있는 방식이 아니니까 효율적이라고 생각을 했는데.. 확실히 UI로 핸들러의 접속 유무를 판단하니까 가끔 연결이 유실이 되어서 실시간으로 댓글이 오지 않는 이슈가 종종 발생한다. 이후 꽤 시간을 들여 오류를 수정했으나 그냥 Space 와 날짜를 채널 ID로 해서 피드 전체를 구독하게끔 하는게 더 간단할 것이다. 물론 엄청나게 많은 이벤트가 발생하거나 피드가 많다면 좀 성능 최적화를 고민해봐야겠지만 초반에 너무 정교하게 들어가려다가 시간을 많이 쓰고 삽질을 했던 케이스다.

파일 저장

Nextjs 의 장점(?)은 자체 서버를 가질 수 있고, 파일 저장을 golang 서버에서 구현하지 않고 Nextjs 에서 직접 구현하고 파일 업로드한 메타 데이터와 파일 주소만 백엔드에 업데이트 하는 방식으로 구현했다.

R2

탈 AWS 의 일환으로 R2 저장소를 이용하였다. R2는 CloudFlare 의 S3 라고 생각하면 된다. S3 못지않게 사용이 아주 심플하기 때문에 주소 연동하고 인증키를 Vercel 또는 로컬 개발환경 secret 으로 등록하고 바로 업로드를 하면 된다. 내가 개발하는 파일 저장소가 필요하다면, R2를 추천한다. 다음은 현재 Free Tier(무료)에 대한 S3, R2 비교표다. 특히 가장 매력적인게 Egress 가 무제한이라는 건데 파일 업로드도 중요하지만 많은 웹사이트에 우리 이미지가 노출이 많이 된다면, R2도 고려하기에 나쁘지 않은 옵션이다.

항목	AWS S3 Free Tier (첫 12개월)	Cloudflare R2 Free Tier (영구)
스토리지	5 GB	10 GB-month
Class A 작업	2,000 PUT/COPY/POST/LIST 요청	1백만 요청
Class B 작업	20,000 GET/SELECT 요청	1천만 요청
Egress	100 GB	무료 (무제한)
기타	신규 계정 $100 크레딧 포함 (30+ 서비스)	영구 무료, 계정당 적용

파일 업로드보다 오히려 드래그앤드롭으로 바로 파일을 올리는 UI나 업로드 progress 표시 같은 작업이 더 공수가 많이 드는 작업이었다. 그리고 무조건 원본을 올리기 보다 약간의 리사이징을 클라이언트 로직을 통해 진행을 했다. 체크인 하면서 포스트나 댓글에 사진을 가끔 올리던 이전 사용 경험을 바탕으로 만든 기능이고, 실제로 추후 tiptap 구현으로 확장한다면 tiptap 안에서 이미지를 임베드할 수 있기 때문에 기능 기획에 고민을 했지만 결국 체크인/체크아웃 목적에 맞게 사진은 별도로 업로드하는 형식으로 구현을 하였다.

HEIC Converter

이게 사실 대부분의 이미지 업로드 기능에서 잘 지원하지 않는 기능인데, 엘리랑 내가 아이폰 유저이다 보니 아이폰 이미지가 대부분 HEIC 확장자로 저장이 된다. 보통 이미지를 업로드하는 jpg, png, gif 정도로 제한하는데 HEIC 확장자는 지원을 하지 않는다. 그런데 우리가 이미지 업로드 테스트나 이미지를 올릴때 맥북 사진 앱을 켜서 그냥 드래그앤드롭을 하고 싶은 사용성을 살리고 싶어서 어떻게든 HEIC 를 이미지를 올리도록 컨버터를 작업을 했다. 단순히 라이브러리 하나를 적용해서 바로 변환할 수 있다고 생각했는데, 생각보다 그렇게 단순하지가 않았다.

폴백 로직

실제 바이트 시그니처를 검사해 이미 JPEG로 변환된 파일은 이름만 .jpg로 바꿔 그대로 반환
conversionMethods 배열에 정의된 다섯 가지 전략을 순차적으로 실행하며, 성공 시 즉시 반환하고 각 시도에 대해 성공/실패 로그와 통계를 기록
모든 방법이 실패하면 누적된 오류 목록을 요약해 로그로 남긴 뒤 예외를 던지는 대신 원본 파일을 그대로 돌려주어 업로드 플로우가 중단되지 않도록 처리
지원 정보와 디버깅 용도로 getHeicConversionInfo, debugHeicFile을 제공해 현재 환경에서 가능한 전략 목록, 파일 헤더, ftyp 브랜드 등을 확인가능

변환 방법 & 라이브러리

heic2any: 기본 전략으로 세 가지 출력 옵션(JPEG 90%, PNG, JPEG 100%)을 순차 시도하며 Blob이 비어있으면 실패로 간주
heic-decode: heic-decode로 HEIF 비트스트림을 직접 디코드한 뒤 다양한 데이터 구조(Uint8Array, 객체 등)를 정규화해 ImageData로 캔버스에 그린 후 JPEG로 직렬화
FileReader: 외부 라이브러리 없이 Base64 URL을 읽어 img 태그에 로드한 뒤 캔버스로 그리고 JPEG Blob을 생성하는 브라우저 기본 API 폴백
heic-convert: Node 기반 heic-convert 모듈을 브라우저 번들에서 동적 임포트해 Buffer → JPEG 변환을 시도하고, 출력버퍼가 비어있으면 오류로 처리
브라우저 네이티브: 마지막 수단으로 URL.createObjectURL과 canvas 태그만 이용해 이미지를 다시 그려 JPEG Blob을 만드는 전략

Claude Code 의 도움을 많이 받긴 했지만 결론적으로 꽤 복잡한 변환기가 되었고 이 정도로 구현하니까 예외없이 모든 HEIC 이미지가 변환이 되게 되었다.

덕분에 아주 신나게 아무 사진이나 막 뒤져서 올리는게 습관이 되었다.

마무리 하며

바이브 코딩!?

백엔드에 이어 프론트엔드까지 아주 심플하게 기술 회고를 진행해보았다. 프론트엔드는 훨씬 더 많은 부분을 Claude Code 에 의존하면서 개발했고 아이러니하게도 AI 의존도가 높아질 수록 생산성이 더 떨어지는 경험을 하게 되었다. 특히, 코드 이해가 떨어지는 상태에서 특정 이슈를 디버깅하거나 수정해야 할때 Claude Code가 간단한 해당 이슈 원인을 해결하지 못하거나 너무 지엽적인 시각으로 해당 이슈를 파악하고 무한의 늪으로 빠지는 경우가 있었다. 대부분 이런 경우에 내가 직접 코드를 읽고 손을 대면 대부분 간단하게 수정이 되었다.

AI로 코드 자체 작성이 빠른 것과 별개로 정책의 변경이나 여러 이슈로 콘텍스트를 제대로 담지 못하는 경우가 현실에서는 다반사이기 때문에 오히려 AI만 믿고 코딩했다가 발목이 잡히는 경우가 많다.

SDD나 PRD 문서, 스펙 정의를 먼저하는게 그나마 유일한 대안인데, 요구사항이 복잡해지고 구현이 복잡해지면 대부분 "구현해봐야" 아는 경우도 꽤 있다는 것이다. 코딩을 마치 수학처럼 수식을 넣고 정답이 하나만 나오는 문제로 인식하는 경우가 많은데, 실제로 그렇지가 않다. 요구사항이 시시각각 변하는 실무에서는 물론 이렇게 혼자 개발할때도 맥락이 유실되는 경우가 많기 때문이다.

지금은 Codex 만 이용해서 요구사항 문서화 -> 구현 스텝 문서화 -> 스텝별 끊어서 개발이라는 나름 방법을 찾아서 이전보다 훨씬 효율적으로 AI를 이용하고 있다. 이것도 점점 나아지는 것 같다. 지금 진행하는 프로젝트가 얼추 마무리되면 또 바이브 코딩에 대한 전반적인 경험과 얘기를 작성해보겠다.

프로젝트 마무리

1차 릴리즈를 끝낸지 벌써 한달이 넘게 지났다. 내부 업무에서 사용하다보니 개선하고 싶은 부분이 많이 보인다. 해당 프로젝트를 외부에 오픈하려고 진행한 건 아니지만 가까운 시일 내에 베타 버전으로 라도 한번 릴리즈를 했으면 좋겠다. 프론트엔드는 Claude 덕분에 안좋은 코드가 많이 쌓였다. 지금 진행하는 프로젝트 릴리즈를 하고 나서 조금씩 정리하고 기능 개발을 진행하는 것이 목표이다.

이전 회사에서 거의 프론트엔드를 직접 코딩하는 경우가 많이 없었는데 이번 기회에 아주 딥다이브해서 제대로 공부도 하고 구현을 했다. 프론트엔드가 어려운 건 그 자체로 어렵다기보다 결국 유저에게 직접 닿는 부분이라서 그런 것 같다. 내가 손으로 만졌을때 내가 구현한 결과물에서 나는 그 구린내 때문에 고치고 고치다가 시간이 훌쩍 지나가기 일쑤인 것 같다. 그래도 UI를 구현하고 돌아가는 걸 직접 봤을때는 또 백엔드와 또다르게 도파민이 돈다.

백엔드 편에서도 그랬지만 이번 프로젝트를 하면서 프론트엔드를 다음 프로젝트에서 쓴다면 어떻게 또 진행해야할지 명확히 정리가 되었다.

미루고 미루었던 프론트엔드 편까지 완성했으니 이제 또 개발에 집중하다가 조만간 또 새로운 주제로 돌아오겠다.

Scrumble 관련 포스트

Scrumble 팀 1차 릴리즈 인터뷰

Tony Cho (https://flowkater.io) — Fri, 26 Sep 2025 00:00:00 GMT

import InterviewCard from "@/components/InterviewCard.astro";

Scrumble 1차 릴리즈를 마친 직후, 토니·엘리·조지가 프로젝트 합류 배경부터 워크샵 뒷이야기까지 솔직하게 풀어놓았다. 프로젝트 전반의 흐름은 Scrumble 프로젝트 회고 (2025년 6월~8월)에서 정리되어 있다면, 이 글은 팀원 각자의 시선과 감정선을 담아낸 인터뷰 기록이다.

Q1. 어떻게 합류했고 어떤 기대를 품었나요?

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 저는 오랫동안 개발 업무를 못하고 있던 상태여서, 개발에 불을 붙일 프로젝트가 필요했습니다. 그리고 이왕이면 내가 매일 쓰고 장기적으로 개선할 수 있었으면 좋겠다고 생각했구요. 해당 프로젝트는 제가 이전 회사 생활을 하면서 쓰던 데일리 미팅 노트에서 아이디어를 시작했습니다. 체크인, 체크아웃, 업무 공유. 회사에 매일 나와서 오랜시간 얼굴을 보면서 일하는데, 체크인을 통해 간단히라도 본인의 상태를 공유함으로써 팀 커뮤니케이션의 윤활유 역할을 하고 매일매일 체크아웃과 업무 공유를 통해 팀웤에 기여하는 프로젝트를 만들고 싶었어요. BE/FE 기술 스택을 End to End 로 모두 개발하면서 감을 살리는 것과 더불어 하나의 온전한 프로젝트를 릴리즈하는 것이 목표였어요. </InterviewCard>

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 저도 토니와 마찬가지로 오랜 시간 디자인 업무에서 손을 뗀 상태라, ‘뭐라도 좀 했으면....’하는 마음이었어요. 마침 좋은 타이밍 덕분에 스크럼블이라는 서비스를 함께하게 되었죠. 개인적으로 데일리 미팅 경험이 꽤 긍정적이었어요. 저는 ‘소프트 터치’를 중요하게 생각하는 편이라, 팀원들과의 관계를 부드럽게 다져가는 과정이 좋았습니다. 다만, 이 과정이 매니징 측면에서 실제로 업무 효율이나 성과에 얼마나 기여하는지는 깊이 고민해본 적이 없었죠. 그런데 토니가 이 부분에서 갈증을 느낀다는 이야기를 들으면서, ‘이런 필요를 가진 유저를 파헤쳐보고, 이런 식으로 방향을 잡으면 충족되지 않을까?’하는 호기심이 강하게 생겼습니다. 늘상 그렇듯... “MVP에 집중하자”라는 초심에서 출발했는데, 어느새 N의 회로에 휩싸여 B2B 영업까지 고민하는 상황(…)으로 번지기도 했습니다.(제품 초기 기획을 막 시작하는 시점인데 말이죠.) 다행히 다시 정신을 부여잡고, 본래 목적에 맞게 기대치를 재정립해냈답니다!ㅎㅎ 이 서비스가 앞으로 나아가는 과정에서, 언젠가는 메신저와 SNS의 기로에 서게 될 순간이 있을 거라 생각합니다. 요즘 워낙 화두가 되는 주제라 조심스럽긴 하지만, 그때 현명한 판단과 확신, 결정을 내릴 수 있길 바랍니다. 개인적으로는 사회적 관계에서 오는 친밀함과 불가피한 스트레스 사이에서 균형 잡힌 소통이 가능하길 기대하고 있어요. 궁극적으로는 모든 걸 심리스하게 이어가고자 하는 작은 욕망, 내지는 큰 기대감이랄까요ㅎㅎ </InterviewCard>

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 학원, 스터디 등으로 공부를 하긴 했으나 현업에서의 업무와는 많은 차이점 있다고 생각했습니다. 그러는 중에 회사를 입사하게 되었습니다. 학원, 스터디때와는 다르긴 하지만 제가 생각했던 업무랑은 차이가 있었습니다. 1년이 조금 넘는 시간을 회사에 다녔지만 크게 얻는 것이 없다고 느꼈습니다.(애초에 이 전제가 잘못되었습니다. 경력(업무 능력)을 쌓고 이직이 어렵다는 걸) 회사에서 마냥 눈치를 보면서 일이 없을 땐 시간을 대충 떼우다 가는 등은 아직까지 제가 생각한 삶이 아니라서 제대로 할 줄 알고 잘 하고 싶어서 좋은 기회를 주셔서 팀에 합류하게 되었습니다. 이제라도 현업에서의 업무를 하는 노하우, 팀원들간의 커뮤니케이션 능력을 기르고 싶습니다. </InterviewCard>

Q2. 진행하면서 가장 힘들었던 순간은 무엇이었나요?

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 가장 힘들었던 점은 마무리하던 시점과 tiptap 에디터 작업하던 순간입니다. 마무리하던 시점에 설계 이슈로 모든 API를 마이그레이션 해야하는 작업이 있었는데 이 작업을 포함하여 마무리 릴리즈 작업들이 하지 않은 것들이 산더미로 쌓여서 너무 속도를 못내고 계속 프로젝트 진행을 미뤘습니다. 7월말쯤 제주 워케이션을 가면서 어떻게 해소를 했지만, 조금 더 정신차리고 했었으면 좋았을 건데 하는 생각이 제일 크게 들어요. 그리고 tiptap 을 초기에 적용하다가 너무 기능이 과하다고 느끼고 롤백하고 넘긴 적이 있는데.. 가장 되돌리고 싶은 순간이에요. 뒤에 가니까 엮여있는 기능들이 많고 쌓여있는 데이터가 더 많아져서 기능 적용이 더 어려웠는데, 너무 많은 시간을 쓰고 있어서 결국 마무리 못했거든요.. 처음에 했으면 조금 더 빨랐을건데.. 딱 그 순간이 생각이 납니다 하하.. </InterviewCard>

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 제가 주로 모바일 디자인을 해왔던 터라, 웹뷰 작업을 하려니... 캔버스가 왜이리 망망대해인가요..? 이 과정에서 시간을 갉아먹었던 것 같아요. 또 폭주하는 기획 아이디어와 장미빛 미래를 허락없이 상상한 탓에... 현실의 핵심 작업에 집중하는 시간들을 허비했던 것 같아요. 정말 마음이 앞선 덕분에(우는중1) 꽤 엉켰죠ㅎㅎ! 그리고 되돌리고 싶은 순간이요...? 효율을 앞세워 컴포넌트화 진행을 디자인 픽스 전부터 우악스럽게 진행했던 것?(나중에 싹 다 갈아엎음 엔딩ㅎ) 일단 컬러부터 들이 밀어서 작업했던 것? 무게감은 덜고 정말 핵심 기능과 가치에 집중해서 디자인했어야 했는데, 거기에 자신이 없으니 인터랙션에 매몰되었던 것? 손케치 시간이 아깝다고 일단 모니터 앞에 앉아서 한창을 헤맸던 것? 어떤 것부터 말씀드려볼까요...? (우는중22) 지금 다 되돌릴 수 있다면... 잘할 수 있...을까요?ㅎㅎㅎㅎ 이 모든 근본은 완벽주의 + 오만함 + 게으름 + 끙끙 앓.. 환장 총합체 발동이 아닐까 싶네요^^ 방향성을 잡을 땐 빨리 논의하고 빨리 집중하고 빨리 실행하자! 매번 느끼는 교훈입니다 </InterviewCard>

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 회사에서는 특정 업무가 종료가 되면 다른 업무를 주지 않고(회사에서 일이 없는 경우) 지내는 시간이 있는데 이 기간이 엄청 힘드네요. 반대로 스크럼블 프로젝트 하면서는 일이 없는게 아니라 제 나름 너무 많아서 아 이걸 어떻게 쳐내야하는지, 할 게 너무 많은데, 이런 식의 힘든 점이 있었습니다. Tony 말씀처럼 절대적인 시간을 갈아넣고 작은 거, 할 수 있는 거부터 시작을 하면 되는데 할게 많고, 미루다보니 그게 스노우볼이 굴러져 멍하게 있었던 시간이 꽤 있었습니다. 그러다 보니 프로젝트 기간 중간 중간 급격히 피곤해지는 기간이 있었습니다. 아직도 저 습관이 100% 고쳐지진 않았지만 지금 당장 저 순간으로 돌아가게 된다면 생각만 하는 게 아니라 작은 것부터 시작을 했을 것 같습니다. </InterviewCard>

Q3. 토니, 오랜만에 매니저가 아닌 개발자로 일해 본 소감은?

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 제 회고에도 남겨놓았는데, 정말 행복했고 정말 괴로웠어요. 그리고 확실히 느낀게 AI가 아무리 생산성을 올려준다 한들 내 멘탈 모델과 메모리 용량이 한계가 있기 때문에, 마지막 디테일까지 완성하려면 결국은 제가 해결할 수 있는 범위 내에서만 가능하더라구요. Claude 가 아니었으면 지금보다 더 많이 걸렸고 풀스택 개발에 더 어려움을 겪긴 했겠지만, 결국 스스로 해내야하는 부분들이 여전히 많이 있는 것 같아요. 제 스스로 개발하면서도 매니저로 일했던 스킬이 도움되는 경우도 간혹 있었지만 (AI 활용, 의사 결정) 매니저때 잘하던 (커뮤니케이션, 우선순위 결정 등) 중요한 역량들이 개발에 매달리면서 제대로 활용되지 못하면도 컸던 것 같아요. 이번 프로젝트는 팀 매니저 토니가 아닌 개발자, 엔지니어 토니로 돌아가는 시간이었는데요, 그래도 그 관점에서는 성공이라고 말할 수 있을 것 같아요. </InterviewCard>

Q4. 토니가 다음으로 집중하고 싶은 목표는?

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 솔로프리너나 소규모 팀에서 결국 중요한 건 프로덕트에 어떤 기술을 쓰냐보다 정말 고객이 원하는 제품을 만드는데 있다고 생각해요. 개인적으로 제품 관리, 팀 관리 측면에서 오랫동안 일해왔다면 이제는 제품 성장에 초점을 맞추어서 달려야 할때 라고 생각합니다. 개말만 하는건 이번 프로젝트로 충분히 했으니까요. 최근에 본 강의에서 제품 리더의 존재 의의이자 최종 목표는 팀을 승리로 이끄는데 있다고 합니다. 워크샵에서도 공유했지만 영광의 순간을 만들기 위해 제 모든 역량을 동원해보려고요. </InterviewCard>

Q5. 엘리, 다시 프로덕트 디자이너 모드로 일해 보니 어땠나요?

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 한계를 정말 많이 느꼈습니다. 일단 꽤 게을러진걸 객관적으로 느끼게 되었어요. 저 역시 AI를 활용해서 본격 작업을 하게된건 이번이 처음이거든요. 이거 AI의 맛을 한번 보고 나니, 사람이 참 게을러지더라고요. 원래는 손으로 스케치하면서 머릿속으로 기술적 제약이나 개발 방향을 고려하고, UI와 UX를 함께 정리하는 과정이 있었는데… 이번에는 손보다 눈으로만 작업하는 시간이 많았던 것 같아요. 그래도 투자 시간 대비 결과 영향이 적은 문서 작업 같은 건 AI 덕분에 훨씬 수월해졌습니다. 덕분에 시간을 많이 아낄 수 있었고요. 특히 서비스의 엣지 케이스 유저를 명확하게 정리한 순간이 가장 뿌듯했습니다.. 오랜만에 작업에 시동걸었던 프로젝트라 그 자체로 좋긴 합니다. 다만 망망대해(...)의 웹뷰쪽만 겨우 작업한터라 작업물에 대한 만족도가 좋진 않습니다. 사실 싹다 갈아엎고 싶어요. 마음만 굴뚝같음ㅎ~ </InterviewCard>

Q6. 토니와의 갈등, 기억나는 순간이 있었나요?

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 사실 이젠 뭐 때문에 그렇게까지 싸웠는지는 기억나지 않구요.(외면) 뭐 협업하다보면 다 관점의 차이고, 다들 뭐 맞는 소리인데, 니만 맞네 나만 맞네 하면서 조금 목소릴 높이고 뭐 그런거 아니겠습니까! 촤하하! 그리고 정말 다행히도, 토니와 저는 해소하는 과정도 어찌저찌, 그리고 또 어쩔 수 없게도~ 서로 잘 토해내곤 한답니다. 촤하하! 저는 논의 중에 갈등을 빚고 언성도 높아지고.. 하는게, 결국 결과를 도출하기 위한 하나의 과정이라고 생각해서 앞으로도 많이 싸울 것 같긴 합니다. -만 그 과정 속의 감정 소모도 무시할 수 없더라고요.. (이젠 감정 소모가 체력 소모로도 이어지..더....라구...ㅇ...ㅕ...?ㅠㅠ) 그래서 앞으로는 논의의 초점을 딱 정해두는 것이 필요하다고 생각해요. 단순히 주제뿐 아니라, 시간·기능·확장성 같은 제한선을 미리 합의해두면 감정 소모를 많이 줄일 수 있을 것 같습니다. </InterviewCard>

Q7. 조지, 퇴근 후와 주말까지 투자하며 얻은 것은 무엇인가요?

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 당장 처음부터 기술적으로는 원하는 바를 정해 놓지는 못했고 예전 야구앱 만들기, 개발 스터디 할 때보다 적극적으로 업무에 임하고, 커뮤니케이션도 잘해보려는 목표가 있었습니다. 처음엔 약간 오바해서 커뮤니케이션을 하려고 했었는데 프로젝트가 진행되다보니 좀 꺾였었습니다. 그러나 일상 대화가 커뮤니케이션의 모든 것이 아니라 업무적으로 본인이 상대방이 어디까지 이해를 했고 어디를 진행하고 있는지를 서로 공유하는 것이 커뮤니케이션이라는 것을 느끼게 되었고 다음 프로젝트에서는 적극적으로 반영하려고 합니다. 프로젝트를 진행하다보니 우스갯소리로 API 공장장이 되고싶다는 목표가 생겼었는데 아직 설계 문서, 요구사항 문서 등을 작성하는 것이 어려워 계속 써보고 피드백 받고 수정하려고 합니다. </InterviewCard>

Q8. 앞으로 팀원으로서 어떻게 기여하고 싶나요?

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 아직까진 파트 타임으로써 작은 부분을 하고 있습니다. 하지만 그 작은 부분조차도 Tony의 도움이 없으면 혼자하기 벅차네요. 풀타임은 어불성설이구요. 현재 하는 파트들을 Ellie랑 Tony가 마음 놓고 맡길 수 있는 팀원이 되고 싶습니다. </InterviewCard>

Q9. 1차 릴리즈 워크샵, 무엇이 가장 좋았나요?

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 워크샵이란 행사를 태어나서 처음 해봤습니다. 두 분이 준비해주신 만큼 성의를 보이고 싶었고 적극적으로 임하려고 했습니다. Ellie, Tony 발표를 너무 잘 듣기도 했고, 자료도 잘 봤습니다. 발표는 저렇게 하는거고 자료도 저렇게 만들어야하는구나를 많이 배웠습니다. 가기전부터 밑밥으로 어떻게 해야할지 모르겠습니다. 발표 자료 만드는게 어렵습니다. 등 했지만 이러쿵 저러쿵 발표를 끝내고 나서 들은 말 중에서 두 분도 생각보다 걱정을 많이 하셨는데 발표를 잘 해줘서 고맙다고 해주셔서 감사했습니다. 워크샵 외적으로 서울에서의 컨텐츠(풀코스), 서울에서 잠을 잘 수 있게 해주신 부분이 너무 만족스러웠고 너무 감사했습니다. 요약을 하자면 이게 스타트업인가? 라는 느낌을 많이 받았습니다. </InterviewCard>

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 제게 이번 1차 릴리즈 워크샵의 주 타겟은 사실 조지였습니다. 그래서 장소 대관이나 콘텐츠들을 좀 신경쓴 경향이 없잖아 있답니다!ㅋㅋ 워크샵이 단순 결과물 공유하는 자리였다면 비대면으로 해도 큰 뭐는 없었을거에요. 그보단 우리의 스크럼블 서비스 목적과 부합하는 분위기였으면 했는데, 그게 이번 행사에 잘 녹아들었다고 생각합니다. 발표 자료를 기를 쓰고 만들었답니다. 이것이 웤샵의 묘미이고~ 다음 웤샵을 기대하게 하는 어떤 썸띵? Smooooth operator~~~~~~ </InterviewCard>

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 제가 "혼자서도 잘해요" 라고 나오긴 했지만, 사실 팀으로 일하는 걸 정말 좋아합니다. 사람도 좋아하고.. 그래서 이전에 비하면 훨씬 작은 팀이었지만 너무 재밌었습니다. IT 스타트업 경험이 없는 조지에게 문화를 보여주고 싶은 욕심도 있었고 다들 원격으로 일하지만 같은 팀으로 일한다는 메시지도 가져가고 싶었어요. 각자 준비해온 발표도 너무 재밌었고 또 서로 경청하면서 들었던 것 같습니다. 이번에는 프로젝트 마감 기념 워크샵 이었지만 다음번에는 성과 달성 파티를 했으면 좋겠네요. 워크샵을 통해 서로 동기부여가 많이 되었던 것 같습니다. </InterviewCard>

Q10. Scrumble로 이루고 싶은 다음 목표는 무엇인가요?

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 디자인 측면에선 아무래도 모바일뷰와 브랜딩입니다. 땜빵식 디자인 덕분에 내 작업물인데도 약간 흘겨보고 있어요...ㅋㅋ 어떻게 풀어가야 할지는 조금 더 고민이 필요하지만, 꼭 개선하고 싶습니다. 워크샵때 공유드렸던 'G타입 유저에 대한 인사이트 — UX 개선 포인트'를 공유드렸었는데, 자잘한 UX 최적화들을 계속 쌓아가고 싶어요. 작은 디테일들이 쌓여서 결국은 큰 경험 차이를 만든다고 생각하거든요. 그리고 이건 암암리의 비밀인데, 일전에 엣지케이스라고 문서화하고 보람차게 공유했었는데, 시간이 지날수록 그 엣지 케이스의 특성이 제 성향 자체인 것같다고 종종 느끼고 있습니다ㅋㅋㅋ 그런 의미에서, 초기엔 토니가 제1고객이었으나, 이제는 저 스스로도 또 다른 타깃층이 된 것 같아요. 그래서 궁극적으로는 제가 만족할 수 있는 서비스로 발전시키고 싶습니다. </InterviewCard>

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 스크럼블에서 두 분의 일상, 업무 공유를 받아서 친밀감이 생겼구요(취미 등), 저 또한 제 일상, 업무 내용을 적으면서 두 분에게 더 다가가는 기회가 생겼습니다. 아직 스크럼블의 모든 기능이 생긴게 아니기 때문에 꾸준히 개발에 임해서 팀원 모두가 만족할 수 있는 제품이 되도록 다 같이 노력하고 싶습니다. </InterviewCard>

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 아직은 영업 라인도 없고 공개하고 싶어서 만든 프로젝트는 아니었지만 결국 도구를 공개하고 직접 돈을 내고 사용하는 고객이 생겨야겠죠? 지금은 다른 프로젝트를 진행 중이지만 가끔 일 하기 싫을때 조금씩 업데이트를 하고 있기에 빠른 시일 내에 public beta 로 공개를 할 수 있었으면 합니다. </InterviewCard>

Q11. 팀으로 함께하며 서로에게 고마웠던 점은?

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 엘리에게 많은 시간을 같은 공간에서 같이 일하고 있는데요. 엘리가 없었으면 이렇게 용기내서 프로젝트를 시작할 수 없었을 것 같아요. 저도 혼자서는 쉽게 포기하는 경향이 있어서 항상 많은 부분에서 엘리에게 의지하고 있고 언제나 멋진 워딩, 디자인이 나올거라고 기대하고 있어요. Scrumble 프로젝트 3개월 자체가 엘리랑 함께한 시간이기에 그냥 하나부터 열까지 모두 감사합니다. 조지에게 포기하지 않고 여기까지 따라와준 것에 너무 감사합니다. 지금 상황이 어떻든 결국 포기하지 않는 사람에게만 그 결과가 올거라고 생각해요. 제가 멘토를 하면서 많은 부분 부족한 모습도 많이 보였는데 정말 잘 해주셔서 감사합니다. 처음보다 분명 성장한 모습을 많이 보았고 앞으로 더 가속해서 성장 모멘텀을 잃지 않길 바래요. </InterviewCard>

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 토니에게 정말 병원가는 시간을 빼곤(!) 같은 공간 같은 시간을 나누고 있는 토니... 토니의 결단력과 유쾌한 태도가 없었다면, 아마 여기까지 오지 못했을 거예요. 그러니 좀 더 유쾌해지십시오! 유머를 잃지 마십시오! 더 북돋아보시라 이 말입니다! 앞으로도 토론과 논쟁과 상처와 해소의 수많은 과정들이 있겠지만, 지혜롭게 잘 헤쳐나가서 앞으로도 더 이로운 가치를 향해 나아가보시죠! 항상 감사합니다~! 조지에게 합류해서 함께한 과정이 마냥 쉽지만은 않았을거라고 생각해요. 어떤 면들은 제 성향과 조지의 성향이 비슷한 구석들이 많이 보여서, 토니가 야속해질 때도 (?!) 있답니다?ㅋㅋㅋ 그럼에도 불구하고, 중도하차없이! 끝까지 함께해주셔서 감사합니다. 분명 이번 기회를 통해 야금야금 성장하고 있단걸 느끼실 수 있을 거예요. 그리고 그게 앞으로의 힘이 될 거라 믿습니다! </InterviewCard>

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 토니에게 저 또한 Tony가 포기하지 않고 저를 이끌어주셔서 너무 감사합니다. 좋은 정보도 많이 알려주시고 가이드도 많이 주셔서 정말 많은 도움이 되었습니다. 그리고 무엇보다 같이 팀에서 일을 할 수 있게 기회를 주셔서 너무 감사합니다. 엘리에게 Tony보다는 상대적으로 얘기할 기회가 적긴 했는데 제가 발표하거나 회고를 할 때 너무 잘 들어주시고 리액션을 크게 크게 해주셔서 너무 감사했습니다. 서울 가기전부터 청소, 정리 하신다는 얘기 듣고 죄송하기도 하고 서울 가서 지내는 동안에도 너무 고생하셨겠구나 싶었습니다. 만족스러운 워크샵, 나들이였습니다! 앞으로는 적극적으로 모르는 부분을 직접적으로 여쭤보려고 합니다.! </InterviewCard>

Q12. 앞으로 서로에게 바라는 점이 있다면?

<InterviewCard variant="tony" name="토니" avatar="/assets/Tony.png"> 엘리에게 더 자주 얘기하고 솔직하게 다퉈보시죠! ㅎㅎ 프로덕트 성장을 위해서, 승리를 위해서 5년 전 어딘가에 두고 왔던 우리의 못다한 소망(?)을 다시 이루어보았으면 좋겠습니다. 그리고 조금 더 각자 성장을 위해 달려봐요! 그리고 더 자주 더 많이 서로 얘기 나누기!! 조지에게 포기하지 마시고 끝까지 가세요! 내가 어떻고, AI가 어떻고, 시장이 어떻고.. 그런거 일단은 무시하고 내가 하는 일에 자부심을 가지고 즐거움을 느끼면서 한발짝 한발짝 늦더라도 꾸준히 앞으로 나아가시죠. 제가 가능한한 도와드리겠습니다! 본인의 역량을 제한하지 말고 겁먹지 말고 더 밀어부치시길. </InterviewCard>

<InterviewCard variant="ellie" name="엘리" avatar="/assets/Ellie.png"> 토니에게 못다한 소망~ 떠올리기만 하면~ Soy lago...😶‍🌫️ 함께 목표를 향해 내달리는 시간들이 더 깊이있고 의미있는 과정이 되길! 그리하여~ 이렇게 되었답니다! 라는 결론에 도달할 수 있도록 함께 힘내보시죠! 더 자주 얘기하고! 더 솔직하게 다투기! 더 지혜롭게 해결하기~! 조지에게 스스로를 낮게 보고 작업 결과물을 폄하하지 않았음 좋겠습니다! 전 지금도 꽤 자주 그러거든요!ㅋㅋㅋㅋ 그런데 그게 언제나 발목을 잡고 더 나아갈 수 있는 순간을 날려보내기 일쑤더라고요. 스스로를 믿고 나아가는데엔 어쩔 수 없으니! 아무튼 나아가는 우리가 되시죠! </InterviewCard>

<InterviewCard variant="george" name="조지" avatar="/assets/George.png"> 토니에게 저는 다른 사람보다 조금 더 환경과 주위에 누가 있는지에 따라 많이 바뀌는 사람이라 Tony랑 더 친하게 잘 지내고 싶습니다. 그럴려면 제가 어느 정도는 말귀도 알아먹고 해야한다고 생각합니다. 꾸준히 성장해서 같이 업무 얘기, 일상 얘기하면서 더 좋게 지냈으면 좋겠습니다. 저를 멘토링 하시는게 바쁘시고, 힘드시겠지만 저도 실망시키지 않고 꾸준히 잘 따라서 좋은 과정, 결과를 보여드리고싶습니다. 엘리에게 Tony는 아무래도 어릴 때부터 헛소리를 많이 들어서 내성이 있는 것 같지만 Ellie는 좀 버거워 하시는게 보였습니다ㅋㅋ.. 조금 줄여 가면서 해보겠습니다.! 그러면 Ellie랑도 지금보다 더 친하게 지낼 수 있을 것 같다고 생각이 듭니다. 이제 Ellie에게 직접적으로 묻는 것을 연습하려고 하는데 답답하셔도 잘 부탁드리겠습니다..! </InterviewCard>

사진으로 보는 워크샵 이모저모

즐거웠던 워크샵, 다음에 또! </section>

Scrumble 팀의 1차 릴리즈는 단순히 기능을 완성한 순간이 아니라, 서로의 속도와 체온을 맞춰 가는 과정이었다. 다음 시즌엔 어떤 성장 그래프를 그릴지, 그리고 이 인터뷰가 또 다른 기록의 출발점이 되길 기대한다.

Obsidian Publish -> Astro 블로그 마이그레이션

Tony Cho (https://flowkater.io) — Wed, 24 Sep 2025 05:18:38 GMT

Obsidian 은 개인 위키와 작성을 위해 굉장히 좋은 툴이고 제텔카스텐과 문서화에 관심이 많다면 요즈음 대부분 권하는 문서 에디터 툴이다. 나는 Notion 을 별로 좋아하지 않았고 Roam 리서치는 좀 어렵다는 느낌이 있었는데, Obsidian 이 약간 이쪽 문서툴에서 표준이 되어가는 느낌을 받으면서 Obsidian 으로 과감하게 옮겼고, 이전에 gatsbyjs 로 잘 사용하고 있던 블로그 플랫폼도 Obsidian Publish 를 결제해서 모두 마이그레이션 했다.

배포도 빠르고 사이트 디자인도 크게 나쁘지 않았고 글을 작성하기 편해서 23년 즈음 갈아타고 그 와중에 회고 글을 몇 개 썼으니 나름 선방했다고 볼 수 있다. 그러나 Obsidian Publish 를 블로깅으로 쓰기에는 여러가지 에러 상황이 많았다. 가장 큰 문제가 SEO 인데, gatsbyjs 시절 Organic 유입이 꽤 되던 내 블로그가 Obsidian Publish 로 옮기고 나서 유입이 확 줄어버렸고 내가 쓴 글을 누구에게 전달하려면 직접 링크를 전달하는게 최선이었다. 아무리 내가 그냥 끄적이고 싶어서 쓰는 블로그라고 해도 독자가 있는 것과 없는 것의 차이는 크니..

파일 베이스 기반이고 frontmatter 를 강제하지 않는다는 점, Obsidian sync/publish 까지 결제하면 가격도 좀 되고, Google adsense 나 이벤트 트래킹 같은 커스텀은 제공되지 않고 Obsidian 에서만 딱 제공하는 것들만 사용 가능하다. (like GA.) 특히, 댓글 기능이 없는게 가장 크다. 누가 댓글을 달겠냐만은 조금이나마 소통 본능이 있는 나에게는 조금 답답한 면이 계속 존재했다. 그럼에도 불구하고 콘텐츠 작성을 그렇게 자주하는게 아니고 Obsidian 이 나름 편해서 잘 사용하고 있었다. 그런데 이제 자유의 몸이 되었고 남는 건 기록이고 그 기록이 모두 콘텐츠라는 생각이 들어서 조금 더 제대로 해보고 싶어서 다시 Astro 기반의 블로그 플랫폼으로 변경했다.

이로서 블로깅 다시 시작하기가 19년도 11월, 블로그 이전 (Gatsbyjs -> Obsidian Publish)가 23년도 12월 말이니 첫번째 글을 다시보니 제대로 블로깅한게 Octopress 부터니, 그 뒤에 jekyll, Gatsbyjs, Obsidian Publish, Astro 까지 5번째 플랫폼이다.

(나라는 사람이 공부하려면 공책과 펜부터 사고 운동하려면 장비부터 검색하는 사람이라서 항상 이렇게 의지를 표현하는게 요란하다.)

astro는 content-driven 웹사이트를 위한 웹프레임워크라고 소개하고 있는데, 블로깅 뿐만 아니라 e-commerce 등 다양한 사이트 제작에 활용되는 것 같다. 렌더링도 빠르고 SEO 도 설정할 수 있고 SSR 등등 여러가지 장점이 보였고 지금은 테마를 가져다 쓰지만 추후에 내가 직접 커스텀할 수 있겠다는 생각에 선택을 했다. 같이 검토했던 건 Golang 기반의 Hugo인데, 조금 더 확장성이 높은건 astro 라고 판단해서 astro 로 마이그레이션 했다.

옮기면서 제일 고생한 건 기존 Obsidian 의 폴더 트리 파일 기반 마크다운 파일들을 flat 한 형태로 옮기는 거 였는데, Codex 로 몇 가지 자동화해서 스크립트를 작성해서 옮겼고, 놀랍게도 Obsidian은 frontmatter(글의 메타데이터)가 없기 때문에, 예전에 썼던 글들의 파일 생성 날짜를 찾아가면서 하나하나 포맷에 맞춰서 교체해주었다. (사실 이게 제일 고생한 부분인듯.. 다행히(?)도 글이 몇 개 없어서 금방했다(..))

이번에 퇴사하면서 한동안 탈AWS 하느라 CloudFlare 를 쓰는데, CloudFlare Pages 에 Astro 전용 배포도 지원해서 배포도 거의 5분만에 했고, 스크립트로 여러가지 편의 기능도 추가했다.

구성

Astro
CloudFlare Pages
Github (+giscus 댓글)
Decap CMS (아직 적용X. headless cms 에디팅 경험이 과연 좋을까? 그냥 마크다운 에디터로 작성하고 변환하는게 더 좋지 않을까)
Google Analytics / Posthog (써보고 싶었는데 이번 기회에..)

요즈음 스레드도 조금씩 하고 있는데, 회고가 아닌 글들, 내 머릿 속에 계속 떠다니는 생각들을 꾸준히 끄적여보고 싶다.

화이팅(?)

Scrumble 기술 회고 - 1. 백엔드 (Golang, DDD, Entgo, Event, Centrifugo)

Tony Cho (https://flowkater.io) — Mon, 22 Sep 2025 00:00:00 GMT

Scrumble 백엔드 기술 회고

AI 시대에 잃어가는 인간적 연결을 업무 환경에서 되찾자. Scrumble은 팀원 간의 감정적 유대와 상호 지지를 형성하는 daily scrum 기반 팀 커뮤니케이션 플랫폼입니다.

이게 초기에 프로젝트 방향성이다. 기술 외적인 프로젝트에 대한 자세한 사항은 Scrumble 프로젝트 회고 (2025년 6월~8월)에서 읽어보면 된다.

여러가지 요구사항이 있었는데, 기본적으로 구현된 기능은 다음과 같다.

워크스페이스/멤버 관리 (생성, 초대 등)
체크인/체크아웃 포스트 (데일리 스크럼)
피드 리스트
실시간 포스트-댓글 및 리액션 이모지
투두 리스트
알림 시스템

추가로 통계/리포트나 서드파티 인티그레이션, 봇 연동 등은 현재 WIP 이고, 구현된 리스트는 위와 같다. 지금 팀에서도 매일 업무 시작과 끝에 이걸로 업무를 하고 있고 매일 체크인 점수와 체크인 포스트, 댓글 등을 활발하게 쓰고 있다.

도메인 요구사항 안을 들여다보면, 백엔드 관점에서 몇가지 기술적 아젠다가 있는데, 대표적으로 다음 세 개가 메인일 것 이다.

워크스페이스, 멤버, 포스트, 댓글, 리액션, 투두리스트 에 이르는 도메인/스키마 관계
피드 리스트
실시간 업데이트 (Seamless UX)

전형적인 SNS 구조와 SaaS 플랫폼 형태의 요구사항이다.

막상 써놓고 보니 몇 개 안되지만.. 아래에서 각 사항들을 구현하면서 고민했던 사항들을 공유해보겠다.

기술 회고

프로젝트 기본 기술 스택

언어: Go 1.23+
웹 프레임워크: Fiber v2
데이터베이스: PostgreSQL 15
ORM: EntGo + Atlas 마이그레이션
캐시: Redis 7 (실시간 상태 관리)
인증: JWT + Google OAuth (Goth)
WebSocket: Centrifugo (실시간 리액션/댓글)
의존성 주입: Wire (Google)
로깅: Zap (구조화된 로깅)
개발 도구: Air (Hot Reload)

graph TD
  subgraph Browser["Next.js"]
    UI["App Router / TanStack Query"]
    WS["WS Client (Centrifugo)"]
  end

  subgraph API["Scrumble API (Go Fiber)"]
    H["HTTP Handlers"]
    S["Application Services"]
    D["Domain"]
    R["Repositories"]
  end

  subgraph RT["Real-time"]
    CF["Centrifugo"]
  end

  subgraph Data["Data Stores"]
    PG[(PostgreSQL)]
    REDIS[(Redis)]
  end

  UI --> H
  H --> S --> D
  S --> R
  R --> PG
  S --> REDIS
  S --> CF
  WS --> CF
  CF --> REDIS

Fiber

아마 제일 일반적인 Golang 웹 프레임워크는 Gin 일 것이고 나는 기존에 Echo로 작업을 했는데 당분간은 계속 Fiber 로 작업을 할 예정이다. 가장 큰 차이점이라면 Gin/Echo 는 net/http 기반으로 Golang 서버 표준을 따른다면, Fiber 는 fasthttp 로 표준이 아니다. 또한, Gin 에 비교하면 상대적으로 표준화된 기본 라이브러리도 적은 편이다. 다만, 필수적인 건 다 있고, express inspired 다 보니 초기 설정이 간단하다. 성능이 더 빠르다고 광고는 하는데 그건 DB를 붙이고 상황과 환경에 따라 다르고 Gin/Echo 도 충분히 빨라서 그게 이유는 아니다. (그런 트래픽을 낼만한 서비스를 아직 못만들어서..) fasthttp 이기 때문에 실시간 등의 지원도 라이브러리가 표준과 차이가 좀 있지만, 직접 구현에 부족한 것도 아니고 어차피 Centrifugo를 쓰고 있어서 크게 문제도 없다. 처음 Golang 으로 한다면 왠만하면 Gin 을 추천하겠지만, nodejs/ts 로 Express 사용하면서 편한 부분이 있었다면 Fiber 도 나쁘지 않다. 어차피 Go 에서는 웹프레임워크가 해주는 역할이 바깥 부분에 있기 때문에 핸들러 레이어 구분을 잘해놓았다면 다른 프레임워크 교체도 엄청 어려운 일은 아닐수도 있다. 그냥 괜히 메이저가 아닌걸 선택하고 싶은 내 취향이니 감안해주시길.

Entgo + Atlas 마이그레이션

정확히는 Entgo + SQLC 이다. 프로젝트 중반 이후에 Entgo 가 Join 으로 쿼리를 날리지 않는 걸 알았고 Entgo가 어떤 ORM의 성격보다는 타입 세이프 쿼리 빌더의 성격이 강하다는 걸 알게되면서 어차피 도메인 엔티티, Entgo 스키마 엔티티도 분리되어있는 아키텍처에서 프로젝트 후반부로 갈수록 Entgo의 모든 부분이 골칫덩어리였다. 원래 gorm 을 썼는데, Entgo 가 뭔가 표준인가 싶어서 큰 고민없이 도입했었고 그 결과는 낭패였다. 일단 불편한 점이 몇 가지가 있는데..

Join 하지 않음
- 기본적으로 N+1 Query Pattern 이다. 코드에서 client.User.Query().withPosts() 라고 하면, Join 하는게 아닌 users 를 Select 하고 그 결과 ID들을 가지고 다시 posts 를 Select 하는 방식이다.
- 이런 이유가 여러 개 있는데 알고보니 Entgo는 내가 잘못하는(?) graphql 과 호환성이 좋고 그래프 방식으로 쿼리 빌더를 짜게끔 설계되어 있었다. 이러한 설계에는 엔티티 매핑도 깔끔해지고 lazy/eager loading 제어가 쉬워진다는 장점도 있겠지만, 결국 쿼리 한번이면 될 것을 n 번 내보내야하는 성능 이슈가 생긴다. 이걸 entgo 문법으로 맞추려고 하다보면 아니 raw query 면 한줄로 될 것을 왜 이 짓을 하고 있지라는 생각이 들면서.. 결국 CQRS 를 적용해서 Query repository 에서는 SQLC 를 쓰게 되었다.
Code First Schema Migration
- 말그대로 DB 테이블을 코드를 중심으로 제어한다는 건데, 문제는 psql 은 되게 많은 기능을 제공하고 그러한 기능들을 내가 직접 코드로 설정해야할때가 있다. 그리고 이왕 마이그레이션 파일을 관리하는 김에 그걸 다 기록을 남기고 싶은데, Code First 이다 보니 atlas 로 내가 마이그레이션 파일을 코드로 읽어서 생성하면 sync 가 되면서 내가 직접 작성한 sql 마이그레이션이 초기화가 된다.
- JSON column 의 GIN Index 생성 등을 Entgo에서 어떻게 지원하는지 직접 최신 라이브러리를 뒤져서 찾아봐야했고 Claude 도 최신 정보가 없어 계속 엉뚱한 스키마 정의 코드를 만들어서 소위 개삽질을 꽤 했었다.
어마어마한 보일러플레이트 생성
- Type Safe, Code First 이다 보니 entgo 스키마로 정의 후 generate 하면 디폴트 파일을 어마어마하게 만들어낸다. 나는 내가 직접 작성한 코드가 아닌 코드 베이스가 검색되는 걸 지양하다보니 계속 검색에 걸리는 남의(?) 소스 코드가 거슬리긴 한다.

타 언어 ORM 처럼(like JPA, ActiveRecord, Django ORM..) 꽤 많은 편의 기능을 제공해주거나 표준이 아닌 이상 결국 객체화된 스키마를 조금 코드에서 쉽게 다루기 위해 ORM 을 쓰는데, 그 정도 기능에 비해 Entgo 는 나에게 너무 많은 단점이 느껴지는 라이브러리이고 이런 초기 프로젝트에서 굳이 CQRS 같은 복잡한 아키텍처가 필요없음에도 결국 기본적인 쿼리 성능 최적화 때문에 도입하게 만들었다. 만약 내가 아주 간단한 Entity 를 가지고 있는 마이크로서비스이고 그게 Graphql 을 결합시키고 복잡한 레이어를 가지고 있지 않은 서버라면 고려해볼만할 것 같은데.. 아주 간단한 서버인데 굳이 ? 라는 느낌도 든다. 하여튼 처음부터 선택해서 끌고 왔기 때문에 이 프로젝트에서는 계속 사용하겠지만 앞으로는 굳이 선택하지 않을 것 같은 라이브러리였다. Golang 을 선호하는 내 작업 성향상 마이그레이션은 Schema first 로 깔끔하게 sql 로 관리하고 ORM 은 Join 쿼리를 기본적으로 실행하는 녀석을 선택할 것이다. 초반에 굳이 Command Repository, Query Repository 이렇게 나누고 싶지 않다. (참고로, 현재 진행하는 프로젝트에선 Bun ORM과 golang-migrate 을 사용한다.)

기타

데이터베이스는 psql 을 표준으로 계속 사용하고 있었고, 실시간, 캐시에서는 Redis (뒤에서 후술), 소셜 인증은 Goth (Supabase 급은 아니지만 꽤 간단하다. api만 연결시켜주고 키만 연결해주면 됨) 의존성 주입은 컴파일 타입에 가능한 Wire 를 썼다. 이것도 그냥 golang DI에서는 국밥 픽이고.. 로깅은 Zap 마찬가지고 국밥 픽, 로깅 구조화가 잘된다는 장점이 있다. 개발 서버는 Air 를 썼는데, Golang 이 컴파일 언어라는 점을 감안했을때 뭐 코드 변경마다 자동으로 컴파일되서 Hot Reload 되는 경험은 거의 스크립트 언어로 서버 개발을 하는 DX를 제공해준다. Spring 으로 내가 개발할때 힘든게 워낙 Ruby, Python 서버 실행속도에 절여져있다보니 너무 느려저서 뭔가 개발 flow 를 유지하기 힘들었다는 경험이 있었는데 (지금은 빨라졌겠지? Spring 최근에 안해서 잘 모름.) 확실히 Golang 의 가볍고 빠른 경험은 훌륭하다.

아키텍처 (DDD/Clean Architecture layering)

기본적으로 Scrumble은 워크스페이스 기반의 SNS 에 가까워서 추후 확장성을 위한 아키텍처를 구축할 필요가 있었다. 초기보다는 중반부터 빛을 발하는 아키텍처를 지향했고 초반 구현에서도 여러번 개선을 거쳤다. 아키텍처는 기본적으로 Domain Driven 을 따르고 Interface(handler) <- Application <- Domain <- Infrastructure (repository+) 레이어를 가져간다. Interface Handler 함수와 Application 의 Service 함수는 1:1 매핑이며, 비지니스 로직의 핵심은 Application 에서 Domain 엔티티와 함수를 조합해서 구현한다. Domain 의 별도 구조체(OOP에서는 class)로 서비스를 구현하는건 지양하고, 패키지 기반의 Golang 프로젝트 특성을 살려서 그냥 패키지 내에서 전역 함수를 만들어서 쓰게 하였고, Repository 또한 Domain 레이어에서 Interface 로 구현되니 실질적으로 Application 에서는 Domain Entity + Domain 패키지 함수 + Repository 함수 (인터페이스) 로 비지니스 로직을 모두 구현한다. Domain Driven Design 을 지향하니 항상 개발 설계는 Domain 엔티티와 VO (값객체)로 시작해서 Repository 인터페이스 정의와 유즈케이스 구현(Application)을 하고 그에 대응되고 조합되는 Infrastructure 스키마 (entgo schema 구조체)를 별도로 구현하고 Repository 구현체에서 스키마 구조체로 불러온걸 Application 레이어에 도메인 구조체로 변환하여 올려준다. 처음에는 Application 에서도 도메인 객체를 리턴하기도 했는데, 중간 즈음부터는 구조를 다시 잡고, Handler 의 Request, Response 뿐만 아니라 Application 에서도 별도 DTO 를 도입해서 레이어 간 최대한 디커플링을 했다.

당연히 아주 간단한 마이크로서비스라면 그냥 핸들러에다가 직접 쿼리 짜서 던져도 된다고 생각한다. 특히, 각 레이어간 매핑 코드는 굉장히 번거로운데 (특히 Go 에서 slices 를 다룰때) samber/lo 패키지로 코드를 많이 줄였다.

graph LR
  H[Interface / Handlers] --> A[Application Services]
  A --> D[Domain - Entities, VOs, Policies]
  A --> IRepo[Repository Interfaces]
  subgraph Infrastructure
    DBRepo[DB Repo - Ent / SQLC]
    CacheRepo[Cache Repo - Redis]
    EventPub[Event Publisher - Centrifugo]
  end
  IRepo -.implemented by.-> DBRepo
  IRepo -.implemented by.-> CacheRepo
  D <--> DE[Domain Events]

테스트

테스트 코드

테스트 코드는 기본적으로 ginkgo/gomega 로 BDD 방식으로 구성을 하고 있다. 아무래도 RSpec 으로 TDD를 배운 입장으로 기본 Golang 테스트 코드가 약간 나에게 직관적이지 않은게 크다. 내가 가지고 있는 TDD 기본 전략은 DB 연동 테스트 즉, repository 나 application 은 최대한 테스트 db 로 통합테스트를 하자는 주의고, Oauth 나 요즈음은 GPT 같은 외부 API 정도만 mocking 을 하는 전략을 가지고 있다. Docker 로 개발하는 대컨테이너 시대에 굳이 DB까지 모킹하는게 나에게는 정말 시간 낭비로 느껴지는 부분이다. 물론 도메인 레이어는 모두 순수 함수니 순수 테스트 함수 구성을 쉽게 할 수 있고, repository 로 전부는 아니지만 복잡한 쿼리나 요구사항 검증이 필요할때는 통합 테스트 DB로 테스트 구성을, Application 비지니스 로직도 마찬가지로 통합 테스트 DB로 테스트 구성을 하였다. 그런데, 내가 한번은 Claude Code 에게 누락된 여러 테스트 코드를 만들어서 테스트 커버리지를 올리라고 무지성하게 명령한 적이 있는데, 내가 명시해놓은 것을 무시하고 Mocking DB 테스트를 뭉텅이로 만들어놔서 어쩌다보니 지금 테스트 코드에 Mocking DB 테스트 코드가 일부 섞여있어서 기존 repository 를 추가할때마다 굉장히 번거로워졌다. 이건 지워야하는데 아직 작업을 못했다.

Apidog

API 테스트는 Apidog 을 사용하고 있다. postman, insomnia, bruno 까지 api client 를 여러개 써보면서 왔는데, Apidog 이 postman 의 대부분의 핵심 기능을 잘 구현하면서 자동화된 문서화와 시나리오 테스트까지 툴 단위에서 아주 잘 지원한다. 심지어 무료 정책이 좋아서 혼자 개발한다면 무료로 쓰기에 좋다. Swagger 를 AI에게 자동 생성하게 하고 그걸 Apidog 에 바로 싱크해서 import 하면 바로 api 요청을 테스트해볼 수 있고, Request, Response 스키마 검증까지 가능하다. 강추 (아 postman 을 안쓰는 이유는 너무 기능이 많고 너무 무겁다. UI도 뭔가 깔끔하지 않아서 나는 insomnia 를 선호했는데, 뭔가 insomnia 가 기능이 이상하게 업데이트가 되면서 오픈소스 api client 인 bruno 를 썼지만, 너무 기능이 부족해서 아쉬워하던 중에 Apidog 을 발견했다.)

성능 테스트

일반적인 부하테스트를 진행하지는 않았고, 기존 repository 와 query 용 repository 로 최적화했을때 성능 비교를 진행했었다. 다만, query 용 repository 를 도입하려면 클라이언트 구조를 모두 바꿔야해서 사용하지 않았고 기존 레거시 repository 쿼리를 후에 더 최적화해서 쓰고 있어서 지금은 deprecated 된 테스트가 되어버렸다.

graph TD
  U[Unit: Domain - Ginkgo/Gomega] --> I[Integration: Repo+App - Test DB]
  I --> E[E2E: API 시나리오 - Apidog]
  E --> P[Perf: 선택적으로 부하 지표 측정]

실시간 처리

Scrumble 은 체크인/체크아웃 Post 를 작성하면 일반 SNS처럼 reaction 및 comment 를 작성할 수 있다. 하지만 단순히 댓글을 다는 것이 나닌 조금 더 대화가 활발한 공간의 특성을 살리고 이모지를 달거나 댓글을 달때 실시간성으로 seamless 하게 커뮤니케이션을 하는 UX를 구현하고자 실시간 처리가 기본 요구사항이었다. 그래서 처음에는 웹소켓 서버를 golang fiber 위에 직접 구현해서 구현을 했다가 https://centrifugal.dev/ 라는 어마어마한 놈을 발견하면서 코드 다 버리고 전부 마이그레이션 해버렸다. 웹소켓 서버를 직접 구현하면, 다음을 다 직접 구현해야하는데,

메시지 유실/재연결 문제
추후 수평 확장 대응
온라인 상태(presence), 권한, 네임스페이스 관리
서버 통신 프로토콜
운영 가시성
기타 등등

간단한 프로토 타입에서야 직접 구현이 전혀 문제없지만 나중을 생각했을때 프로덕션 레벨의 실시간 서버 기능을 모두 구현하기는 생각보다 많은 비용이 들 것 이다. 즉 실시간 시스템의 진짜 어려운 부분(손실 없이 복구, 대규모 팬아웃, 프레즌스·권한, 관측·운영, 멀티노드 스케일링) 을 프레임워크 레벨로 제공한다.

그냥 Centrifugo 서버를 하나 띄우고 Redis 만 연결하고 실제 서버에서는 핸들러만 구현해주고 로직에 집중하면 되니, 차후 확장성이나 구현 편의성 모두 너무 뛰어나서 Centrifugo 를 사용하지 않을 이유가 없다.

sequenceDiagram

  participant C as Client (Next.js)

  participant API as Fiber API

  participant PG as PostgreSQL

  participant OB as Outbox (TX)

  participant PUB as Publisher

  participant CF as Centrifugo

  participant O as Other Clients



  C->>API: POST /posts/:id/reactions

  API->>PG: INSERT reaction (in TX)

  API->>PG: INSERT outbox_event (same TX)

  PG-->>API: COMMIT OK

  API->>PUB: notify new outbox_event

  PUB->>CF: publish reaction.added

  CF-->>O: push event

  C-->>C: optimistic UI (optional)

문제점

Centrifugo 를 사용하면 실시간 서버 관리는 모두 행복할 것 같았는데, 가장 큰 문제가 있었다. Centrifugo 의 최신 기능 일부가 Redis v7, v7.2, v7.4 에서 제공하고 있었고, 특히, presence, history, ttl 등의 기능은 모두 v7 최신 버전에서 지원하고 있었다. 정확히는 채널 히스토리(메시지 보존 및 복구) 기능(위에서 기본으로 제공한다고 했던)인데, 현재 배포 인프라인 Upstash Redis 는 v6.2 까지 밖에 지원을 하지 않아서 처음엔 해당 설정들을 0으로 설정하고 recover 기능을 꺼야하는 것을 모르고 배포 설정을 그냥 했다가 프로덕션에서 실시간 기능이 아예 작동하지 않아서 꽤나 삽질을 했다. Upstash 가 비용면에서 굉장히 경제적이라 당장은 Off 해서 쓰더라도 큰 문제가 없지만 아쉬운 부분인 건 맞다.

그래도 Centrifugo 적용 이후 프로덕션에서 실시간 서버가 문제되는 경우는 한번도 없었고 대부분 프론트엔트 핸들러 구독 및 재연결 로직 이슈로 연결을 잃는 문제로만 실시간 이슈가 발생했다.

이벤트 드리븐

Centrifugo/Redis 를 백엔드로 해서 도메인 기반 이벤트 드리븐을 구현했다. 이벤트 메시지는 대부분 각 도메인 레이어에서 정의되고 이벤트 발생은 각 비지니스 로직 애플리케이션 로직에서 구현했다. 이걸 도메인 레이어에서 구현하는 방법도 있지만 난 코드 흐름의 직관성, 프로젝트 초기에 발생하는 이벤트가 거의다 1대1 매핑이 된다는 점 및 디버깅 용이성 등으로 비지니스 로직 애플리케이션 로직 코드로 가져갔다. 인터페이스 레이어에서 http 말고 events 를 두고 마찬가지로 Handler 를 구현하고 이 handler 들은 도메인 이벤트를 Handle 하게 등록하고 http handler 와 마찬가지로 application 레이어의 함수를 호출하여 구성하였다.

graph TD
  CMD[Command - API] --> TX[DB TX]
  TX --> W[Write Domain Data]
  TX --> OBOX[Insert Outbox Event]
  OBOX --> COMMIT[Commit]
  COMMIT --> WKR[Outbox Worker]
  WKR --> PUB[Publish to Centrifugo]
  PUB --> CLIENTS[Subscribed Clients]

기타

캐싱

나머지는 Redis 로 기본적인 캐싱을 적용하였고 피드 요약이나 내 작성 상태, 내 가입 스페이스 등 TTL을 길게 가져갈 수 있는 기본적인 계산 쿼리들이다. Cache-aside 전략 기본으로 다른 이벤트 발생시 Invalidation 하는 정책을 이벤트 핸들러마다 구현을 한다. 직관적이긴 한데, 확실히 Invalidation 을 각 mutation 이벤트 발생시 마다 일일이 핸들러 등록하는 과정이 조금 번거롭긴 했다.

flowchart TD
  RQ[Client reads Feed] --> GET[Redis GET]
  GET -->|miss| DB[SQLC Query]
  DB --> DTO[Shape DTO]
  DTO --> SET[Redis SET - TTL]
  SET --> RESP[Response]
  GET -->|hit| RESP

  subgraph Invalidation
    EVT[reaction/comment created]
    EVT --> DEL[DEL ws:id:feed:*]
    EVT --> PUB[Publish feed.invalidate]
  end

CQRS (Query Repository 위주/SQLC)

CQRS 패턴이라고 해서 Query DB까지 분리하는 정도는 아니었고 앞서 얘기했던 Entgo 의 쿼리 성능 이슈로 raw query 에 가까운 SQLC 를 도입하여 Query Repository 를 나누었고, Query Repository 는 Domain 인터페이스를 생략하고 읽기 전용으로 Application 에서 바로 Repository 를 찔러서 Application 레이어 구조체를 반환해오는 형태로 구성했다. 나는 DDD가 개인적으로 Command 에 잘맞는 설계라고 생각하고 있으며 대부분 Endpoint 또는 화면에서 요구하는 특정 값들은 도메인 구조체의 구조화된 설계보다는 직관적으로 그리고 성능적으로 DB 쿼리를 날려 화면에서 요구하는 값을 바로 보내는게 Query 인터페이스에 더 맞다고 생각한다. 물론 Entgo 때문에 어쩔수없이 도입했고, 초기 프로젝트에서 무슨 CQRS 까지 가냐고 말하겠지만, 앞서 Scrumble 프로젝트 회고 (2025년 6월~8월)의 목적을 살리고자 그냥 무식하게 하고 싶은 거 다 해보자 하는 심정으로 진행했다. 그리고 SNS 가 우리가 매일 사용하다 보니 쉽게 보이는데 이러한 서비스 특성상 생각보다 생각해야하는 성능상 이슈들이 꽤 있어서 조금 더 화면에 맞게 직관적으로 API Endpoint 를 구성하는게 나쁜 판단은 아니었다고 생각한다. Entgo 로 몇번씩 쿼리 날라가던게 SQLC 로 raw sql 로 아주 깔끔하게 Join 해버리니 아주 빨라졌다. Entgo 에서도 raw sql 쓸 수 있지만, 생각보다 post, reaction, comment, mediafile 등의 여러 테이블을 조인하는 상황에서 raw sql을 타입 세이프하게 구현하고 객체 매핑하는게 까다로웠고 SQLC 는 sql 파일 작성 후 go 파일을 generate 하여 type safe 하게 매핑을 시켜버려서 성능도 챙기고 타입도 챙기는 식으로 안전하게 개발할 수 있었다.

graph TD
  CMD[Command] --> AC[App - Command]
  QRY[Query] --> AQ[App - Query]
  AC --> RC[Repo - Ent]
  AQ --> RQ[Repo - SQLC]
  RC --> PG[PostgreSQL]
  RQ --> PG
  AC --> EV[Domain Events] --> CF[Centrifugo]
  AQ --> C[Redis Cache] --> AQ

배포 인프라

최종 배포 인프라는 fly.io 에서 DB 와 Server 를 둘다 이용하고 upstash redis 를 이용했다. fly.io 에서 백엔드 서버와 centrifugo 서버 둘다 배포를 했다. 현재 내부에서만 사용하지만 인프라 비용은 거의 0원이다. 지금까지 읽었다면 초기 서비스 치고 최적화가 좀 과한거 아냐? (캐싱이나 Query 등) 라고 생각할 수 있는데, 그게 초반 인프라 DB 가 Neon 이었다. 서버리스라는 얘기만 듣고 Neon 을 도입했는데, Neon 이 가지고 있는 여러가지 특성들이 또 있었고 fly.io 서버는 NRT(일본), Neon 은 아시아쪽은 싱가포르 단일 region 이라 서버 - DB 간 latency 도 상당했다. (평균 200ms 이상이 붙어버리니 Post 와 댓글이 많으면 로드할때 2초씩 걸리기도 했다.) 그래서 덕분에 React Query 로 Optimistic UI 처리와 서버에서 쿼리 최적화나 캐싱 등 최대한 이 인프라를 살려보려고 최적화를 많이 했었다. 결국 neon 에서 비용이 발생하는 걸 보고 fly.io 로 마이그레이션 했고 둘다 NRT(일본)로 통일하였다. 최적화는 그대로니 훨씬 쾌적하게 서비스가 돌아가게 되었다. 다만, 앞으로 정식 릴리즈를 하게 되었을때 fly.io 를 쓸 것 인가는 좀 의문이다. 배포도 너무 쉽고 이래저래 직관적이고 초기에는 비용도 싸서 좋은데.. 굉장히 자주 status page 가 노란색이거나 일부 리전에서 셧다운이 발생한다. 내 서비스는 살아있지만 웹 콘솔페이지 서버가 다운되어서 페이지가 안뜨는 경우도 자주 발생해서 AWS에서는 있을 수 없는 일들이 자주 발생하여 추후에는 결국 신뢰가능한 서버 인프라를 재구축해야할 것이다.

graph TD
  DEV[Local Dev - Air] --> CI[CI Build & Test]
  CI --> REG[Container Registry]
  REG --> API[Fly.io Scrumble API - NRT]
  REG --> CF[Fly.io Centrifugo - NRT]

  subgraph Data
    FPG[Fly.io Postgres]
    UREDIS[Upstash Redis]
  end

  API -- SQL --> FPG
  API -- cache --> UREDIS
  API -- publish --> CF
  USERS[Users] --> API
  USERS -- WS --> CF

백엔드에서 바이브 코딩?

유저 -> 멤버 마이그레이션

초반에 속도를 내고자 유저 스키마 기반으로 대부분의 엔티티를 설계해서 가져갔다. 워크 스페이스 마다 프로필이 다르고 워크 스페이스로 로그인하는 이러한 워크 스페이스 기반 SaaS (like slack)에서 유저 엔티티가 아닌 멤버 엔티티(유저 - 워크 스페이스 관계 스키마)로 대부분의 도메인/스키마 엔티티와 인증 구조까지 모두 마이그레이션 하는 작업이 있었다. 사실 중간에 바꿔야한다고 생각하고 뒤로 미뤄두고 계속 기능을 확장해나가다가 프로젝트 종반부에 이러한 마이그레이션 작업이 여러 도메인과 엮여 Dependency 때문에 비용이 좀 증가한 상태였다. 다만, 상위 엔티티 관계를 마이그레이션 하는 작업 자체가 난이도가 있는 작업은 아니었는데 기계적이고 반복적인 작업이라서 당시에 갓 출시한 Kiro 로 스펙과 Plan 을 문서화하고 Claude Code 에게 던졌는데, Claude Code 의 엄청난 삽질로 (기존 아키텍처 무시, 기존 코드 무시, 중복 도메인/코드 생성 등) 한 3일은 이걸 다시 내 손으로 작업을 했다. 그래서 백엔드 편에서는 딱히 바이브 코딩에 대한 할 얘기가 많이 없다. 나중에 API 구조가 간단한 설정 정도만 코드 작성 자동화 정도만 하고 대부분은 내 손으로 구현하였다. 그에 비해 프론트엔드는 Claude Code 손을 많이 빌렸기에 프론트 편에서 조금 더 얘기를 다뤄보겠다.

정리

원래 프로젝트의 목적 중 하나였던 "감 좀 살려보자"의 관점에서 감을 제대로 살릴 수 있는 경험이 되었고, 이제 프로덕션 릴리즈를 목표로 하는 현재 프로젝트에서 조금 더 깔끔하고 명확한 아키텍처 기반에서 현재 구현 작업을 하고 있다. 정리를 하면,

Keep

DDD/Clean Architecture 에서 CQRS, 이벤트 드리븐까지. 중요한건 모든 레이어에 포트를 두고 확실한 분리를 할 것. 분리를 해야 도메인 구현의 자유도 올라간다. (그리고 전부 도메인 참조)
- 물론 이중 코드 발생하는 부분에서 트레이드 오프 발생
Centrifugo
Redis 캐싱 다루기
좀 더 명확해진 테스트 코드 전략

Problem

ORM 을 충분히 검토하지 못하고 선택 (Entgo). 덕분에 복잡해진 설계 구조 (+CRQS, SQLC)
Entgo 를 사용한 마이그레이션 (Code First)
배포시 리전 분리 배치(Neon SG ↔ Fly NRT). Neon 때문에 시간 많이 잡아먹음
바이브 코딩으로 잘못 생산된 코드들 정리 못함
Centrifugo 나 기타 솔루션 도입시 개발 단계에서 리서치 미흡 (해당 개발이 다 끝나고 프로덕션 릴리즈때 버전 이슈 알게되어 시간 비용을 많이 지출)

Try

마이그레이션은 Code First 보다 Schema First 로
장기적으로 프로덕션 배포 인프라 변경 필요
운영 가시성 확보 필요
Mock DB 테스트 제거 및 잘못 생산된 코드 정리 필요

정도 될 것 같다.

사실 내용을 다 읽어본 사람은 이해하겠지만, 이러한 설계 구조의 핵심은 Golang 이 아니더라도 모든 언어, 프레임워크에 적용이 될 수 있다.

Golang 쓰면서 한가지 아쉬운 점은 함수형 프로그래밍인 것 같다. 자바 람다나 코틀린, JS/TS 에서 즐겨하던 프로그래밍 방식을 Golang 에서는 좀 재미가 없어진 느낌. samber/lo 를 사용하긴 하지만 제네릭이 뒤늦게 생긴 언어 답게 뭔가 코드가 직관적이지가 않다. (물론 lo 를 이용하면 코드가 훨씬 깔끔해짐.)

아마 다음 번에 Spring 을 하게 된다면 그건 아마도 Kotlin 때문일 것이다. 그래도 Golang 의 직관성이 처음에 비용을 조금 투자하면 같이 협업하기에도 용이하고 운영 관점에서 편한 게 확실히 많아서 내가 주도로 개발하는 프로덕트에서는 Primary 하게 사용할 것이다. 대한민국에 Golang을 쓰는 개발자들이 많아지길 기원하며...

다음 프론트엔드 편에 계속..

Scrumble 기술 회고 - 0. 들어가며 (Why Golang?)

Tony Cho (https://flowkater.io) — Sun, 21 Sep 2025 00:00:00 GMT

들어가며

Why Golang

다들 각자 Primary Language 가 있듯이 나에게 Primary 는 Golang 이다. 한국 개발씬에서는 그런 이미지가 아닌데 해외에서는 꽤나 Boring 한 이미지가 있는 언어이다. 그도 그럴듯이 언어가 꽤 단순하다. 특히 우리나라 백엔드 개발자들 대부분의 Primary 가 Java 인데, Java에 비하면 한없이 단촐한 언어이다.

Golang 은 그래서 "대표적인" 웹 풀-프레임워크(like Spring Boot, Rails, Django)도 없고 "대표적인" ORM (like JPA, Active Record, Django ORM)도 없다. 딱히 웹프레임워크를 안쓰고 net/http 만 가지고 코딩하는 곳도 심심치 않게 보인다. 그만큼 Golang 이 간단하기도 해서 간단 간단한 마이크로 서버를 만들때 유용하게 쓰이는 것도 같다. 또 언어적인 특성 중에 함수형 언어 맹키로 상수 불변성 따위가 없고 (TS의 const/Kotlin val 처럼 "참조 불변" 변수를 선언할 수 없음. Golang의 const 는 컴파일 타임 상수임. 그래서 대부분 변수를 사용하여 코딩) 에러 반환은 try, catch 가 없고 error 를 명시적으로 결과와 함께 보통 tuple-return 해야한다.

얘기를 좀 복잡하게 했지만 이해한 사람은 알겠지만, 그만큼 단순하다. 그래서 해외에서는 Boring 이라고 하는 것도 이해한다. 코딩이 재밌는 언어는 아니니까.

그리고 부트스트래핑을 빨리하기에는 좋은 스크립트 언어(like nodejs, python, ruby)가 즐비해있고 성능과 안정성을 가져가기에는 우리나라는 자바 공화국이기 때문에 대부분 자바를 많이 쓰는 것 같다. 하지만 스크립트 처럼 가볍게 코딩할 수 있고, 컴파일 언어로 정적 타이핑을 가져가면서 성능은 꽤 좋은 또 장점을 두루두루 가지고 있는 언어이고 무엇보다 goroutine 등으로 대표되는 실시간 처리와 성능 면에서 이점이 추후 온서비스에서 운영을 하기에도 굉장히 수월하다. 우리나라에서도 규모나 트래픽이 있는 꽤 큰 회사에서 클라우드 네이티브, 데이터 인프라, 마이크로 서비스, DevOps 도구 영역 등에서 꽤 쓰이는 것을 볼 수 있다. 당근마켓 같은 팀에서 천만이 넘는 채팅 트래픽을 Golang 를 기반으로 한 시스템으로 운영한다 같은 얘기는 우리 같은 구멍 가게들에게는 크게 와닿지 않겠지만, 개인이 쓰기에도 가볍고 좋은 언어라고 생각한다.

(나는 21년도 초에 사실 당근마켓 개발팀 Go언어를 도입하다 | 당근테크 이 영상에 영업당해서 Golang 을 시작했다..) Rails(Ruby) -> Django(Python) 이었다가 Golang을 시작했고, 지난 회사에서는 계속 nodejs(ts)를 사용했지만 당연한듯이 다시 Golang 으로 돌아왔다. 팀에서 쓰기 좋다던가 등등 여러 장점이 있지만.. 길어지는 것 같아서 다음으로 넘어간다.

Rust는 나의 추구미인데 제대로된 프로젝트에서는 한번도 써본 경험이 없다..
왜 Vibe Coding에서 Go가 편한가 라는 글도 있으니 참고

Nextjs

백엔드와 달리 프론트는 국밥 픽을 했다. Nextjs(TS)를 사용하였고, css를 잘 못하는 나에게 항상 구원이 되는 Tailwindcss, 그리고 한때 graphql 을 쫓았지만(추구미..?) 나의 gql 이해도가 굉장히 떨어진다는 걸 지난 회사에서 크게 깨닫고 Tanstack Query (a.k.a react query)를 사용하였다. 지난 회사야 gql 마스터 프론트엔드 팀장님이 계셨지만 나혼자서 하니 그냥 내가 쓰기 쉽고 이해하기 쉬운걸로 택했다. 그리고 후술하겠지만 react query 를 그렇게 판단한건 나의 큰 실수였다..

국밥 픽이다 보니 Why 가 딱히 없다. React 를 하긴 했었고 예전에 쓰다만 <DataColon 개발 후기> - 1. 들어가며 같은 프로젝트에서도 풀스택을 할때는 고민없이 선택한 스택이고, 아무도 반문을 제기하지는 않을 것 같다. 다만, 대 바이브 코딩 시대에 정말 React/Hook 이 좋은 선택인지는 자료가 풍부하다는 것 외에 많은 고민을 하게된 기간이었다.

순서

글은 다음과 같이 진행할 예정이다. 프로젝트에서 실제 개발한 도메인들을 바탕으로 디테일한 스택들을 파보고 내가 거기서 내렸던 의사결정, 고민 사항들을 적어보겠다. 의외로 프로젝트를 하는 순서가 실제 시간 순이랑도 거의 일치할 것 같다.

Scrumble 기술 회고 (부제 - 풀스택 개발과 바이브 코딩의 실패. Golang 과 Nextjs) - 1. 백엔드
- 프로젝트 기본 기술 스택
- 아키텍처
- 테스트
- 실시간 처리
- 기타
프론트엔드 (2편에서 계속)
- 프로젝트 기본 기술 스택
- 아키텍처
- 실시간 처리
- 기타

Scrumble 프로젝트 회고 (2025년 6월~8월)

Tony Cho (https://flowkater.io) — Sun, 07 Sep 2025 00:00:00 GMT

들어가며

4월 중순 퇴사를 하고, 엘리와 이탈리아 여행을 한 달여간 다녀왔다. 당시 여행의 끝이 다가왔을 때는 약간 지쳐서 돌아왔는데 몇달이 지난 지금 봤을 때는 한 2주 정도는 더 있다가 올걸 하는 아쉬움이 남는다. 인생에서 퇴사하고 가는 첫 장기 여행이었고 돌아와도 어차피 회사를 다시 가는 게 아니라 그런가 어쩌면 지금도 여행을 계속하고 있는지도 모르겠다. 아니면, 5년 전 마지막에 마지막까지 내 사업을 엘리와 하고 있던 그 순간으로 돌아온 것도 같다.

각설하고, 이제 내 일을 시작하려면 다시 내 손으로 무언가를 다시 만들어야 했는데, 꽤 긴 시간 코딩을 손에서 놓고 있었기 때문에 다시 어디서부터 시작해야 할지 고민했을 때 간단한 프로젝트를 하나 만들어보는 것을 목표로 하면 좋겠다고 생각했다. 그래서 사업을 준비하면서 쉬는 기간 동안 사이드 프로젝트를 하나 해보는 것을 목표로 하고 귀국하였고, 아내와 함께 5월 말부터 본격적으로 일을 시작했다.

해당 회고는 프로젝트 전반적인 회고 1편과 풀스택 개발과 LLM을 활용하면서 정리한 회고 2편으로 정리를 하려고 한다.

Scrumble 프로젝트 목표

Scrumble 프로젝트는 내가 투데잇을 할 때도 그리고 그 뒤에 다른 회사에 다닐 때도 계속했던 데일리 스크럼 미팅을 기반으로 한다. 사실 작년부터 회사에 다니면서 해보고 싶은 프로젝트였고 당시 팀에서 Confluence 로 데일리 미팅 노트를 작성하고 있었는데, 인원도 많아지고 팀도 나눠지고 하다 보니 쓰기가 굉장히 불편해졌는데 다음의 현상/불편들이 있었다.

쓰는 사람만 쓰고 안 쓰는 사람은 안 쓴다.
지나간 기록을 쉽게 볼 수가 없다. (Confluence 에서도 DataTable 을 지원하지만, DataTable 은 대부분 사용성이 구리다. 마치 DB나 엑셀에 값을 입력하는 느낌)
30명이 넘는 인원인데, 노트 하나에 너무 많은 인원이 담겨 있어서 한눈에 보기가 힘들다.

내가 생각한 이 노트의 문제점은 팀이 작든 크든 그 옛날 evernote, dropbox paper, notion 으로 쓰든, Confluence 든 할 거 없이 업무와의 직접적 연결이 느슨해지기 시작하는 시점에 데일리 노트의 활용성이 급격하게 떨어졌고, 결국 팀원들의 컨디션이나 간단한 일상 공유까지도 잘 작동하지 않으면서 최종적으로는 해당 노트의 팀 내 커뮤니케이션 기능도 확연히 떨어지게 되었다.

팀원으로서는 쉽게 쓰고 커피챗이나 미팅을 자주 하지 않더라도 팀 내 커뮤니케이션을 활발하게 하는 것을 목표로 하지만 단순히 체크인 점수나 일상 점수만으로는 그 필요성이 확연히 떨어지는 것을 느꼈기 때문에 그날의 업무 Todo를 편리하게 작성할 수 있는 기능까지를 목표로 한다.

물론 Slack 과 같은 커뮤니케이션 툴이나 Jira 나 Asana 같은 프로덕트 관리 툴을 대신할 생각도 아니고 제품 포지셔닝이 그쪽은 아니기 때문에 최대한 해당 툴들과 통합을 목표로 한다.

다시, 프로젝트의 목표를 정리하면,

Main: 앞으로 우리 팀에서 쓸 수 있는 데일리 스크럼 서비스를 만들자 (MVP)
Sub: 팀이 본격적인 개발 프로젝트로 넘어가기 전까지 충분히 적응하고 연습하는 시간을 가지자 (업무 스킬 및 협업 관점에서)

(완전 초기에 작성한 PRD 문서)

프로젝트 셋업

업무 환경

나는 열정보다 시스템을 믿는 사람이고, 재능보다 환경을 믿는 사람이다. (상대적인거지 재능과 열정이 중요하지 않다는 건 아니다.) 그래서 항상 무슨 일을 할때 일이 되게끔 하는 걸 굉장히 중요하게 여기는데 (모든 이해관계자의 Economy 가 일치한다던가, 비용과 시간이 적게 든다던가) 아무래도 집이라는 환경에서 모든 일을 해야하는 상황이다보니 이러한 고민이 많았고, 여전히 그 답을 찾아가고 있는 중이다.

대부분의 작업은 집에서 했다.

집

환경과 시스템 관점에서 집은 최적의 공간이 아니다. 우리 집이 방이 엄청 많은 것도 아니고 말이다. 그래도 엘리는 그 전에 법인 운영 시 거의 버려지다시피 한 사무실을 매달 몇십씩 꼬박꼬박 냈던 기억이 있다 보니 결국 지금은 비용 관점에서 집이라는 환경이 최선의 선택지였다.

두 개의 모니터와 M4 max. 밥을 직접 해 먹을수도 있는 최적의 공간.

물론 3개월 동안 일을 해보면서 느낀 건, 빨리 비용을 확보해서 장기적으로는 사무실을 구하는 게 맞을 것 같다.

생활

사이드 프로젝트지만, 풀타임으로 하는 사이드 프로젝트이다 보니 하루 종일 집에만 있을 위험이 있었다. 그래서 철저하게 하루 시간표를 세웠다. 엘리와 헬스장 출근을 출근이라고 생각하고 업무 사이클을 잡아가기 시작했다. 처음 한 달은 대부분 잘 지켜졌는데 두 달째 프로젝트 막바지가 다가오니 결국은 사이클이 깨지면서 마구잡이로 일을 하기 시작했다. 쉽게 이해를 돕자면,

잘 지켜질때는.. 10시 취침, 5시 30분 기상 -> 아침 운동 후 -> 출근이라는 거의 갓생 루틴이었다면..
프로젝트 막바지에는.. 새벽 4시 취침, 12시 기상 -> 점심 먹고 -> 2시부터 일 시작.. 정도로 망가진 상태다.

마지막에는 결국 이런 생활에 둘 다 지쳐서 프로젝트 마무리를 위한 워케이션을 다녀오기도 했다.

코로나 시절 재택근무를 거의 안 해서 몰랐던 집에서 일하는 어려움을 몸소 느끼고 있다.

커뮤니케이션

엘리와 나 둘이서 (내가 회사 다닐 때도) 사이드 프로젝트를 진행하곤 했지만, 거기에 리모트 객원 멤버 한 명(조지-백엔드 개발 인턴)이 있었고, 둘이서 하더라도 모든 기록을 오프라인에만 남길 수는 없기에..
Slack, Notion, Jira, Confluence 부터 이전에 써보았던 Linear 나 Asana 등 다양한 툴들이 있는데..

비용도 줄여야 하고 작은 팀이다 보니 이것저것 사용했을 때 결국 어마어마한 구독료에 Lock In 이 되는 경험을 했다보니.. 사실 그런데도 불구하고 Slack, Notion, Linear 정도로 정했던 상황이었는데 엘리가 ClickUp 이라는 슈퍼앱을 가지고 와서 ClickUp 을 선택하게 되었다.

ClickUp 은 말그대로 Slack + Notion + Linear 라서, 커뮤니케이션을 위한 채널 채팅, 마크다운 문서화, 프로젝트 관리까지 다른 SaaS 1개 구독료로 세가지 기능을 다 쓸 수 있는 서비스이다.
알아보니 한국에서는 잘 안쓰는 서비스인 것 같다. All in One 좋아하는 한국 특성상 홍보가 많이 안된게 오히려 신기한 부분.
쓰다 보니 확실히 Slack, Notion, Linear 보다 10% 정도는 부족한 부분들이 보이지만, 그 세 개가 하나의 툴에서 유기적으로 통합되었을 때 가치가 워낙 크다 보니 정말 잘 쓰고 있다. 오히려 반대로 말하면 각 서비스의 기능들을 90%씩은 구현한 거니까 그걸 있는 그대로 잘 동작하게 구현하는 게 얼마나 대단한 건지 개발을 해본 사람들은 알 것이다.

하여튼 커뮤니케이션은 ClickUp 을 사용하면서 깔끔하게 해결.

1인당 30$ -> 1인당 10$
Slack 채널 채팅, Notion 문서화 모두 잘 지원
- 위에서 말한 10%는 각 솔루션을 딥하게 사용하다 보면 느끼는 차이점인데, 엄청 불편하지는 않음
Project Management 도 직관적으로 필요한 기능만 잘 제공

1차 MVP 기능 목표

1차 MVP 목표는

인증
스페이스 관리
체크인/체크아웃 작성
투두 리스트 작성
피드 페이지
실시간 댓글 및 리액션
실시간 알림 페이지

사실 1차 MVP 목표 기준으로 기능을 얼추 완성을 했지만, 중간에 이대로는 부족하다고 기능을 더 넣어야 한다고 하다가 한 주 정도를 버린 것 같다.

결국 8주안에 마무리 될 MVP가 12주로..

돌아보니 1차 기능 목표도 모두 구현이 되었고, 프로젝트의 원래 목표였던,

Main: 앞으로 우리 팀에서 쓸 수 있는 데일리 스크럼 서비스를 만들자 (MVP)
Sub: 팀이 본격적인 개발 프로젝트로 넘어가기 전까지 충분히 적응하고 연습하는 시간을 가지자 (업무 스킬 및 협업 관점에서)

도 얼추 달성했다.
물론 중간에 잘못된 의사결정과 여러 가지 삽질, 그리고 일을 안 한 시간까지 포함하면 전체 기간에서 한 3주 정도는 빼야 할 것 같다.

자세한 이야기는 아래 회고에서 이어서 하겠다.

회고

Keep

Daily Dog Fooding

Daily Dog Fooding. 아마 앞으로 프로젝트에서도 핵심이 될 사항이긴 한데, 직접 쓰기 위해 만드는 서비스이다보니 확실히 그냥 끝내기 위해서 라기보다 어떻게 하면 더 잘만들 수 있을까 고민을 많이 하게 되었다. 이전 회사에서는 메이커가 직접 유저가 될 수 없는 서비스이다보니 한계가 있었는데 확실히 매일 쓰면서 단순한 버그부터 개선 지점, 더 필요한 부분을 계속해서 더 파낼 수 있었다. 당장 고객이 없을때 Dog Fooding 은 메이커에게 최고의 장치다.

Hands-On From Scratch

기술 회고에서 조금 더 자세하게 쓰겠지만 Golang(Fiber + Entgo) + Redis + PostgreSQL 로 백엔드를 Nextjs 로 프론트엔드를 풀스택으로 작업하면서 프로젝트의 완전 end to end를 내 손으로 모두 작업해 보면서 지난 몇 년간 손 놓았던 코드를 다시 손에 익히느라 진땀도 뺐지만, 월 200달러 내 친구 Claude Code 와의 협업을 통해서 그래도 혼자서 hands-on 으로 충분히 프로젝트 개발을 할 수 있는 상태가 되었다.

즐거움

사실 이전 회사에서 프로젝트를 하면서 만들면서 즐거움을 느낀 게 언제인가 싶다. 내가 쓰는 서비스라던가 하는 그런 걸 떠나서 그냥 매일매일 코딩하는게 즐거웠다. 사실 회사에서 DDD 를 도입하던 시점부터 나는 코드에서 손을 뗐었는데 초기 DDD/Clean Architecture Layer 설계부터 CQRS 도입, Event Driven 까지 하고 싶은 건 최대한 다 해봤다. 프론트엔드는 내 주 분야는 아니었지만, 스타일을 하나씩 수정해 보고 만들어가는 즐거움과 괴로움을 모두 느끼면서 여하튼 리누스 토발즈의 리눅스 그냥 재미로 개발까지는 아니더라도 충분히 내 손으로 직접 만들어가는 즐거움을 찾은 게 정말 중요한 시기였다.

멘토링

나는 가르치는 걸 좋아하는 사람인데, 잘 가르치는 게 무엇인지 고민을 하던 시기에 강의도, 가르치는 것도 관두었다. 그게 참.. 교육의 어려운 지점이다. 가르치는 게 아닌 잘 가르치는 것. 조지가 개발자로서 커리어를 이어가게 하려고 도와주고 싶었고 그 목적으로 프로젝트에 합류시켰다. 조지는 아직 백엔드 개발로는 거의 초입문자 수준이지만 이제 API 하나 정도는 스스로 만들 수 있는 수준이 되었다. 중간중간 내가 화도 내고 답답해하는 모습도 많이 비추었다. 항상 그럴 때마다 밑천이 드러나서 부끄럽다. 그래도 회사에 다니면서 파트 타임으로 하면서도 끝까지 포기하지 않는 조지가 기특해서 최대한 많이 알려주려고 했다.

여전히 멘토링이라는 것은 어렵다. 사람마다 수준도 해야 할 말도 다르고, 사실 개발이나 이런 스킬들은 일종의 도구에 불과하고 어떻게 일해야 하는지, 또 어떻게 같이 일해야 하는지, 얘기해야 하는지를 모르는 사람들이 많으므로 진심으로 수준 높은 S급 팀에서 서로 커뮤네케이션을 하려면 잘한 일을 말하기보다 못하거나 어려운 얘기를 할 수 있게 계속 끌어내는 게 좋은 멘토링이다.

당연히 내가 감정적인 되면 하등 그 방향으로는 도움이 안 된다. 세상 사람들은 AI가 발전하고 있으니, AI가 교육도 대체할 거라 쉽게 말한다. 하지만 AI는 도구다. 질문을 잘해야 답변도 잘한다. 초보자들은 질문을 못 한다. 실패에 대한 내성도 약하다. 과정에서 계속 그러한 부분들을 이끌어내고 극복할 수록 돕는 것이 내가 멘토로서 정말 어렵지만 계속 공부하고 플레잉 코치로서 같이 뛰면서 코칭하는 스킬들도 계속 공부해 보려고 한다.

Problem

커뮤니케이션 부재

이번에 주로 듀오로 프로젝트를 이끌어가면서 느낀 가장 큰 문제점이다. 엘리가 프로덕트 디자이너로 가져가고 있는 프로젝트 방향성과 내가 개발자 이전에 프로덕트 매니저로 가져가고 있는 프로젝트 방향성이 어긋나는 부분이 종종 생겼는데.. 매일 옆에서 같이 일을 했지만, 정기적으로 미팅을 하거나 커뮤니케이션을 충분히 하지 못했다. 각자 실무 작업 퍼포먼스를 내기 위해 집중하다 보니 10시간 넘게 같은 공간에 앉아 있는데 말 한마디 없이 나는 코딩하고 엘리는 디자인하고 하는 시간이 잦았다. 또 내가 직접 모든 걸 개발할 수 있다 보니 간단한 거는 내가 그냥 추가해 버린다거나 충분한 커뮤니케이션 하지 않고 개인적인 판단으로 기능 명세를 변경해서 구현한다 든가 하는 이슈가 있었다. 물론 그 뒤에 충분한 회고를 통해서 데일리 미팅 시간을 잡았지만, Scrumble 프로젝트를 하면서 Scrumble 하지 않았던 가장 큰 문제.

과도한 기능 스펙

과도한 기능 스펙. 초기 MVP 는 사실 정말 사용 가능한 기본 수준이었고, 우리가 생각한 차별성을 가진 최소 기능 연동 (LLM 연동 리포트나 서드파티 연동)이 빠진 버전이었다. 그래서 각자 더 넣고 싶은 기능들이 있었고 해당 기능들을 완성해서 넣어야 한다는 충분히 커뮤니케이션 되지 않은 합의로 인해 갑자기 일정이 과도하게 늘어지기 시작했다. 돌아보면 2달 정도에 릴리즈가 될 수 있었던 MVP를 결국 3달 가까이 끌어오게 된 근본적인 원인은 그러한 기준과 그러한 이슈를 충분히 커뮤니케이션 하지 못하고 각자 작업에만 매달린 결과이다.

데드라인 부재

데드라인 부재. 데드라인은 없었던 건 아니다. 다만, 이게 외부 공개 프로젝트나 더더욱이나 사업성을 생각하고 시작한 프로젝트가 아니다 보니 결국 위의 두 가지 문제가 겹치면서 한주만 더 해보시죠. 한주만 더 해보시죠. 하다가 결국 일정이 흐지부지 늘어나기 시작했다. 그 많은 사이드 프로젝트들이 실패하는 이유도 아마 대부분 비슷할 건데, 대부분 90%까지 프로젝트를 거의 끝내지만, 나머지 10% (배포를 위한 준비, 미뤄두었던 필수 기능 구현 등)이 사실 기존에 했던 90% 만큼 에너지를 내야 하는 작업이다. 즐겁지 않은 작업이기 때문에.. 아마 돌아보면 그런 것들이 겹쳐서 더 많은 기능을 넣어야 한다고 주장했던 것도 같다.

즐거움만큼 큰 괴로움

Claude Code 나 Cursor 등 기타 툴들이 바이브 코딩과 함께 유행하면서 마치 딸깍 한 번으로 코딩 모르고 개발할 수 있는 것처럼 약을 팔지만, 사실 간단한 서비스가 아닌 이상에야 결국 코드를 사람이 손을 대야하고, 기능이 많아지면서 A를 수정하면 B가 문제가 생기는 경우도 허다하거나 Context 를 잘못 파악한 AI 가 중복된 로직을 만들거나 Architecture Layer 를 무시하고 자체적으로 무언가를 만드는 등 여러 문제가 생긴다.
특히, 간간이 해왔던 백엔드와 달리 프론트엔드는 정말 오랜만이어서 하나부터 열까지 다 삽질이었는데 레이아웃/스타일 이슈부터 실시간 처리까지 Claude code 만 두들겨서 딸깍으로 문제 해결이 안 되어서 이런저런 context 를 줘가며 괴롭히다가 내가 코드를 직접 수정해서 바로 해결된 문제도 꽤 많았다. 여하튼 코드 작성하는 즐거움만큼이나 괴로움도 컸는데, 아직 도입 못 한 tiptap 적용이나 필수 기능 구현 등에서는 간단하지만, 하고 싶지 않은 설정 작업들이 그랬다.

잘못된 판단 고민 부족

워크스페이스를 기본적으로 생성하는 SaaS 의 성격을 띄고 있다 보니 기본적인 인증 토큰이 서비스에 로그인하는 유저 인증과 워크스페이스 내의 멤버로 인증하는 부분이 나뉘어져 있었는데 처음에 빠르게 개발한다는 이유로 그러한 디테일을 고민하지 않고 평소 하던 대로 유저 인증만 가지고 진행했다. 그렇게 서비스를 얼추 마무리하는 시점에 크게 잘못된 걸 깨달았다. 결국 모든 API 설계와 인증 체계를 멤버로 마이그레이션 했는데 이 작업만 전체 검증 및 테스트까지 포함해서 얼추 3,4일은 한 것 같다. 하기 싫어서 작업을 미룬 거까지 합치면 일주일 넘게 걸렸다. 그리고 처음부터 tiptap 을 가져가려고 했는데 과할 것 같다고 해서 작업은 중단했는데 그때가 프로젝트 초기라 복잡도가 낮은 상태에서 적용하고 마이그레이션 했으면 금방했을건데 지금 작업하려니 엄두가 안나는 부분. 그냥 golang orm 으로 Entgo 를 쓰다보니 그냥 썼는데 생각보다 Clean Architecture Layer 가 명확할때 그 장점이 많이 상쇄되는 부분 등등.. (이건 추후 기술 회고에서 다시 풀어보겠다.)
솔직히 냉정하게 보았을 때 아무리 코드를 손에서 좀 놓았다고 한들, 감 떨어졌다고 생각되는 판단들이 꽤 있었고 결국 프로젝트 릴리즈 시점에 신나게 두들겨 맞고 있다. 아프다.

루틴 이슈

앞서 생활에서도 언급했듯이 처음 지켜나가려고 했던 데일리 루틴이 무너지면서 생활적으로나 정신적으로 중간에 둘 다 한번 위기가 왔다. 그래서 긴급조치로 워케이션을 택했는데 다행히도 좋은 선택이었고 어느 정도 다시 정리가 되어서 돌아왔지만, 초반에 잘 지켜나갔던 만큼의 루틴 상태로 현재 돌아오고 있지 않아서 다시 가다듬어야 하는 이슈이다. 프로젝트 막바지에 Scrumble 에 매일 쓰여져있고 매주 회고 리포트에 보면 루틴 유지가 힘들다는 것이 거의 8할이다.
처음 시작하는 용기보다 다시 시작하는 용기가 더 어렵다. 다시 갓생? 프로젝트를 시작해 보자

Try

커뮤니케이션

사실 문제점의 상당수는 결국 엘리와 산책을 통해 얘기하면서 솔루션을 찾고 다시 판단하고 해소되었다. 결국 정기적인 미팅도 중요하고 조금 더 커뮤니케이션을 활발하게 가져가는 것도 중요하다. 지금 일하는 공간(집 거실)을 조금 더 커뮤니케이션 하기 적합한 공간으로 엘리가 맞춰가고 있는데, 나는 데일리 미팅과 주간 미팅 일정을 만들어서 다음 프로젝트에서는 절대 문제점으로 커뮤니케이션이 부족하다는 말은 나오지 않게 하겠다. 부족한 것보다 차라리 과한게 더 나은 것 같다.

부끄럽지 않으면 너무 늦은 것이다.

If you are not embarrassed by the first version of your product, you've launched too late.
리드 호프먼 (링크드인 창업자)

부끄럽지 않으려고 어느 순간 처음 MVP 에서 벗어나서 너무 과도한 기술 스펙을 얘기하기 시작했다. 사실 내가 쓰려고 만든 건데, 만들고 나서 계속 다듬어도 되는 건데 말이다. 엘리가 중간에 회고를 통해서 '불특정 다수를 대상으로 무언갈 해보려다가 시간 낭비를 했는데 토니가 제 1고객이다 라는 생각으로 접근하니 빠르게 진행이 되었다.' 라는 말이 정말 중요했다.
결국 마무리와 본격적인 사업 준비와 다음 프로젝트로 넘어가기 위해서 이 정도에서 릴리즈하고 마무리를 하기로 했다. 다음 프로젝트는 훨씬 더 빠르게 마무리할 것이다.

몰입

루틴도 몰입을 위한 하나의 중요한 도구이다. 그런데 여기서 말하는 건 꼭 일하는 시간만의 몰입은 아니다. 살면서 이렇게 시간이라는 자원이 넘치는 시기가 거의 없었는데 막상 그 시간이 되니 조금 시간을 막 쓰는 경향이 있다. 여기서 막 쓴다는 건 내가 온전히 그 시간에 집중하고 몰입하고 있지 못하는 얘기다. 그렇게 하루하루를 허비하면 또 후회만 남을까 봐. 매일매일 정신을 차린다. 놀 때도 노는 것에 온전히 몰입하자. 더 이상 하루 시간의 대부분은 다른 일(회사 일)을 하면서 다른 생각을 하면서 행복을 좇는 것보다 내가 원래 생각했던 것처럼 온전히 지금 시간에 몰입해야 한다. 연습이 사실 필요한 부분이다. 더 노력해야지. '할 땐 하고 쉴 땐 쉬자'가 요즈음 이런 환경에서(집에서 일하고 시간이 자유로운 환경) 특히 더 어려운 부분이 있는 것이다.

Lesson Learned

완벽한 MVP는 모순이다 - 부끄러워도 빨리 출시하자
듀오 프로젝트 = 과도한 소통 - 10시간 같이 있어도 대화는 필수
실패해도 다시 한번 - 루틴이 망가졌다고 포기하지 말자, 다시 일어서면 된다
AI는 마법이 아니다 - 결국 사람이 코드를 이해해야 한다
Dog Fooding이 답이다 - 내가 1호 고객이 되자

나가며

사이드 프로젝트이지만 풀타임으로 했고.. 어느 날은 20시간 앉아서 코딩하는 날이 있는가 하면 어느 날은 3일 내내 키보드에 손도 안 댄 날도 있다. 매년 아침 일찍 출근해 빌딩 안에서 일하며 밤늦게 퇴근하는 여름을 보냈었는데, 안 그래도 유독 더웠던 여름에 집에서 일하니 정말 여름을 정통으로 느꼈다.
Scrumble 은 사실 이전 회사에서도 계속 개인적으로 시도해 보고 싶었던 프로젝트였고, 지금도 매일매일 사용하면서 쓰고 있기 때문에 무척 마음에 든다. 아직 목표로 했던 기능 마일스톤까지는 한참이지만 이제 다른 프로덕트를 개발하면서 차근차근 업데이트를 해보려고 한다.

여차저차 3개월의 여정에서 느낀 건 역시 온전히 내 시간을 써서 개발을 시작하니 나의 안 좋은 습관, 밑천이 온전히 드러나는 부분이 많았고 그 전 회사에서 내가 얼마나 많은 부분을 남의 손을 빌려 일을 해결했는지 확연히 드러나 느껴지는 순간들이었다. 반대로 말하면 이런 것들을 스스로 해결해 나가면서 더 빠르게 성장할 수 있는 환경에 던져진 것이다. 회사는 안락했지만 역시 성장을 위해서는 스스로 모든 걸 마주할 수 있는 용기가 필요한 법이다.

만족스러운 날도 있지만 그렇지 않은 날들도 있다 보니 계속 글로 뭔가를 남기거나 정리하는 걸 미루고 이렇게 쓰는 것도 아쉬운 부분 중 하나다. 프로젝트에 대한 기록은 매일 남겼지만, 주기적으로 일기라도 썼으면 조금 더 나아졌을까 싶다. 자주자주 기록하고 돌아보자.

창업 준비를 하면서 시작한 사이드 프로젝트인데 어느새 이게 주가 되었던 시간이었다. 이제 손도 풀었고 웜업도 마쳤으니 이번 프로젝트에서 배운 여러 가지 사항을 다음 프로젝트에서도 잘 적용해 보고 같은 실수를 반복하지 않기 위해 노력해보자.

과정도 중요하고 성과도 중요하지만 결국 마무리를 하지 않으면 그 어떤 것도 가치를 발하기 힘들다. 다음 프로젝트를 위한 Try에서 적은 Action Item 외에도 나 자신을 마주 보고 계속 정면 돌파 해나가야겠다. 그리고 즐거움을 잊지 않기 위해 더 열심히 할 것이다.

"A warrior does not give up what he loves, he finds the love in what he does."
"전사는 자신이 사랑하는 것을 포기하지 않는 법이야. 자기가 하는 일에서 사랑을 찾는 사람이지"
"A warrior is not about perfection or victory or invulnerability. He's about absolute vulnerability."
"전사는 완벽하거나 언제나 승리하거나 완전무결한 존재가 아니야. 그는 압도적인 절망 속에서도 일어나지"

Peaceful Warrior

평화로운 전사 중에서

(워케이션 중 마이 데스크)

(Scrumble 워케이션 중 체크아웃 노트)

기술 회고에서 계속

이전 회고
- 4년간의 IHFB 회고
다음 회고
- Scrumble 기술 회고 (부제 - 풀스택 개발과 바이브 코딩의 실패. Golang 과 Nextjs) - 0. 들어가며

4년간의 IHFB 회고

Tony Cho (https://flowkater.io) — Thu, 10 Apr 2025 00:00:00 GMT

들어가며

21년 4월부터 25년 4월까지, CTO로 입사하여 개발자 3명이 있는 개발팀을 이끌고 30명이 넘는 R&D본부를 만들고 이끌어왔는데 드디어 대장정(?)의 마침표를 찍게 되었다. 4년간의 여정을 하나의 글에 담아내는게 나의 부족한 필력으로 가능할지 모르겠지만 너무 시간이 지나기 전에 적어보려고 한다.

Timeline

21년 4월, 5월 - 파트타임으로 시작

처음에 회사에 합류하게 된건 사실 단기 프로젝트의 파트타임 계약이었다. 당시만 해도 내 서비스를 개발하고 있었고 당장의 캐시 플로우를 확보하기 위해서 처음 두달은 내 일을 하고 퇴근하고 회사에서 일하는 식이었다. 당시 개발팀의 개발자는 총 3명이었고 그 중 2명과 함께 매일 밤 7시부터 저녁 11시, 어떨때는 자정이 넘는 시간까지 같이 프로젝트를 진행하였다.

몇가지를 했었는데 첫번째는 7000줄이 넘는 단일 컨트롤러 코드를 layered architecture 라도 적용하여 반복되는 코드를 줄이고 raw query 를 repository 패턴으로 분리하거나 재귀함수 제거, functional 패러다임 적용으로 코드를 깔끔하게 정리하려고 노력했다. Node.js와 Express.js를 이용하여 구성된, 프레임워크 없이 만들어진 노드 서버였고 인스턴스 하나에 PM2 를 띄워서 서비스를 운영중이었고, 컨트롤러 코드 내에서 다른 함수를 호출하는 것이 아닌 같은 서버의 API 콜을 하면서 피크 타임에 반복해서 네트워크 오버헤드, 응답 시간 지연이 반복되어서 해당 문제를 해결하는데 대부분 시간을 쏟았다.

또한 푸시나 오버헤드가 큰 작업들을 백그라운드 잡으로 빼지 않고 있어 마찬가지로 서버에 큰 부하를 주고 있었고 해당 작업을 Kafka 를 이용하여 이벤트 처리에 적용하는 것도 하나의 큰 작업 중 하나였다. 이때의 작업은 대부분 레거시 서비스의 특히 백엔드 서버의 여러 문제 해결, 코드 리팩토링, 성능 문제 해소, 서버 안정화 등이 메인이었고 그걸 하면서 Kafka 스터디 및 이벤트 적용, k8s 스터디 등을 진행했다.

21년 6월~12월 - 6개월 계약직 CTO

이런 저런 작업을 하다보니 어느새 개발팀의 메인 과제들이 나랑 직접적으로 연결되어 버렸고, 5월에 CTO 직을 제안을 받았다. 기존에 CTO 를 담당했던 전임자 분은 서비스 경험 혁신 부서라는 운영부서를 희망하셨고 안그래도 현금이 필요했던 나는 6개월만 더 해보자 라는 생각에 CTO직 제안을 큰 고민없이 받아들였다.

6월부터는 기존에 계속 가지고 있던 레거시 서비스를 추가 개발하면서 대표님의 제안으로 당시 서비스 중이던 운영 서비스를 레거시를 버리고 완전히 새로운 서비스를 개발해서 대체하는 것을 목표로 하였다. 팀 내에서 프로젝트 명은 SA 서비스 개발이라는 과제명이었고, 이미 100명이 넘는 회사의 시리즈 C까지 받은 서비스를 완전히 새로운 서비스로 개발하는 건 내 입장에서도 꽤 부담스러운 입장이었고 처음에는 기존 레거시를 최대한 개선하는 방향으로 제안했으나 대표님의 완고한 설득(?)으로 완전히 새로운 서비스, 즉 SA 서비스를 개발하기로 했다.

당시 기술 스택은 당시 모든 인원이 Node.js 만 다루고 있었고 그래서 TypeScript 와 NestJS, MySQL 그리고 k8s 에 배포하는 방향으로 기본 밑그림을 가지고 초기 3개월이 넘는 시간동안은 거의 기존 레거시 서비스의 문제점으로부터 출발하여 앞으로 어떤 콘텐츠도 담을 수 있는 확장성 있는 시스템으로 개발할 것인가를 고려하여 설계하고 빠르게 프로토타이핑을 해보았다.

이때 동시에 진행하던게 바로 CMS, 즉 콘텐츠 에디터 시스템이었는데 기존 레거시 서비스는 완전히 기본적인 에디터만 제공하고 있었고 거기에 들어가는 보기 문항 번호나 특수문자 등은 콘텐츠 작업자들이 매크로나 메모장에 별도로 저장해서 사용하고 오류로 동작하는 부분도 마치 하나의 기능으로 승화(?)시켜 콘텐츠 작업을 하던 중이었는데, 이러한 사람들을 나는 콘텐츠 닌자라고 부르기도 했다.

콘텐츠 제작의 문제를 해결하기 위해 CMS 도 새로 기획하고 만들기 시작했는데, 어쩌면 이때가 IHFB 에서는 처음으로 사용자의 의견을 듣고 실제로 콘텐츠 제작도 해보고 그들의 문제점도 공감하면서 고객 중심의 개발을 했던 경험이었다. 단축키 하나하나 까지도 테스트를 해보려고 했던 것이나 중간중간에 개발된 버전을 가지고 간략하게나마 사용자 테스트를 하면서 진행했던 기억이 있다. 사실 콘텐츠라는 것이 교육 비지니스에 핵심과도 같은 것인데 단순히 사람을 더 쓰면 된다는 인식에 가로막혀 어떠한 기술적 지원을 못받고 있었던 조직이었다보니 그들의 문제를 해소해주고 싶은 욕심이 앞섰다.

여튼 이 기간 동안 제대로된 개발팀을 구축하기 위해 대대적으로 채용도 진행하였고 당시에 회사는 시리즈 C 투자를 성공적으로 받았고 역대급 TV 광고 마케팅, 대규모 채용 등 투자금을 이용하여 스케일업에 필요한 다양한 액션들을 취하고 있을때였다. 개발팀도 21년 12월 기준 어느새 4월 기준 3명이었던 팀이 13명까지 증가하였고 내 계약도 어느새 끝을 향해 가고 있었다.

22년 - 신규 SA 서비스 런칭을 향하여

시작을 했으니 끝내고 싶었고 여기까지 왔으니 끝은 보고 마무리하고 싶었다. 22년에 두번의 계약을 더 진행하면서 SA 서비스의 마무리를 위해 달리기 시작했다. 회사도 마포에서 여의도 파크원으로 이사를 하였고 우리 팀 뿐만 아니라 회사 전체적으로 공격적으로 채용을 했고, TV에는 이병헌이 나와서 우리 서비스를 홍보하며 대대적으로 마케팅이 진행되던 시기이다.

레거시 서비스에서 돌아가던 모든 것이 그대로 돌아갔어야하고 레거시 서비스의 그것보다 구조적으로 더 뛰어났어야했다. 다만, 생각보다 레거시 서비스는 몇년에 걸친 유구한 전통을 가진 피쳐들이 산재해 있었고 어떻게든 이러한 기능들이 서비스 운영에 여기저기 활용되고 있었다. 아주 조그마한 것이라도 놓치면 서비스 운영이 안되는 상황이었기에 생각보다 길어지는 서비스 개발 기간에 레거시에서 놓친 것은 없는지 체크 또 체크하면서 계속 개발을 해왔다.

서비스가 1차적으로 일단락되어 완성된건 8월 이었고, 영향도나 민감도가 낮은 일부 고객군 (내신 시험을 치지 않는 중1, 고3)을 대상으로 프리 런칭을 진행했다. 그렇게 9월, 10월, 11월 계속해서 프리 런칭 상태에서 12월 마지막 주에 모든 사용자가 새로운 서비스로 마이그레이션 되었다. 1월부터 7월까지 장장 7개월간 개발을 했고 8월부터 12월까지는 실제 운영 서비스에 적용하기 위해 운영팀 교육부터 콘텐츠 마이그레이션 등 개발 외에 다양한 업무들을 소화해냈다.

채용은 계속되어 팀은 20명이 넘어가고 있었고 여름즈음해서 소위 네카쿠라배 팀장급 인사들도 팀에 합류하면서 한결 더 팀다운 팀으로 발전하며 서비스 개발과 런칭에 만전을 기했다. 마지막 컨텐츠 마이그레이션을 위해 새벽 4시까지 회사에서 팀원들과 작업을 했었는데 아직도 그때 직전의 강렬했던 기억들이 남아있다. 정식 릴리즈까지 꼬박 1년이 넘게 걸리다보니 사실 이게 끝나긴 끝나는 건가 의심하기도 했다.

어느새 단순 개발팀이 아니라 R&D 본부라는 명칭으로 하나의 본부에 자리잡아 독자적인 조직 문화를 형성하며 어느새 하나의 조직이 되어 움직이고 있었고 팀장급 인원들도 들어오고 우여곡절 끝에 서비스도 런칭하면서 이제 드디어 마무리하는 시점이 다가왔다.

23년 1월~8월 - 정규직 전환 그리고 고도화

22년 말 아이러니하게도 드디어 런칭을 했을때, 회사에서는 정규직을 제안했고 고민할 수 있는 짧은 시간이 주어졌다. 솔직히 런칭을 했지만.. 아직 서비스 안정화부터 서비스 운영에서 벌어지는 다양한 이슈 등 해결해야할 문제가 산더미였다. 그래도 1년을 넘게 서비스에 쏟아서 그런가 이 서비스가 다시 자리 잡고 고도화되는 방향을 보고 나가고 싶다는 욕심이 생겼다.

결국 이 시기에 적지만 회사 주식을 매입하여 회사 주주가 되었고 회사에서는 처음으로 정규직으로 일하기 시작하였다. 마음가짐도 고쳐먹었다. 이때까지는 항상 나는 회사에서 외부인이었고 그런 마음으로 일을 계속 하고 있었는데, 이제는 조금 더 진심으로 임해보자. 핑계대지말고 내가 할 수 있는 일은 최선을 다해보자. 그게 내 결심이었다.

새로 만든 건 좋은데 기존에 비해 구조도, 인프라도 복잡해져 있었고 장애 대응이나 여러 해결책들도 난이도가 꽤 있는 상황이었다. 그래도 이즈음 구성된 백엔드, 프론트엔드, PM 세 명의 팀장 체제가 기능팀을 잘 컨트롤 해내면서 여러 문제가 있었지만 굉장히 이상적으로 업무 프로세스를 갖추어나가고 있었다. QA도 이즈음 신설이 되었고, 아마 이 시점에 이미 약 25명 넘게 인원이 있었다.

실제 서비스에서도 기존 상품보다 훨씬 프리미엄 상품을 출시함에 따라 추가적인 많은 기능 요구사항이 있었고 제품 자체도 훨씬 더 다양한 콘텐츠 타입을 다루면서 더 많은 기능들이 탑재되었던 시기였다.

23년 9월~12월 - B2G? B2B?

일이 어려워지기 시작한 즈음, 아마 이 시기가 내가 완전히 새로운 국면을 맞이하는 시기였다. 일단 합이 정말 좋았던 PM 팀장님이 개인 사업으로 떠나게 되고 내가 팀장직을 대행하게되면서 이 즈음부터는 CTO 보다는 PM의 역할을 더 많이 하게되었다. 그리고 회사에서도 기존에 집중하던 B2C 외에 만들어진 플랫폼을 가지고 B2B, B2G 까지 확장하기 위해 여러 일을 벌이던 시기였는데 나도 비지니스 요구사항을 쫓아가기만 해도 정신이 없었다.

9월, 그리고 24년 1월 해서 회사에서는 전에 하지 않았던 외부 행사 (박람회) 등을 크게 기획하여 나가게 되었고 그때 보여줄 데모와 기능 개발을 하기 위해 이 시기부터는 기존 B2C 보다는 대부분 B2B, B2G 제품 개발에 시간을 쏟았다. 사실 B2C 에 비해서 난이도가 굉장히 높았는데 도대체 무엇을 기준으로 어떤 기능을 만들어야하는지 판단이 잘 서지 않았고 고객 목소리보다는 자칭 전문가라고 생각하는 회사 내부 경영진, 외부 전문가 집단, 개발팀 외 집단 들에게 계속 기능 우선순위가 휘둘리기 바빴다.

이 시기부터가 정말 어려워지는 시점이었지만 난이도의 문제라기 보다는 이러한 B2B, B2G 제품 만들기는 내가 10년 넘게 쌓아온 분야가 아니라서 사실 재미도 흥미도 느끼지 못했던게 가장 큰 문제였고 항상 모든 기능 구현이 숙제처럼 느껴졌다. 그래도 23년 정규직 전환을 하면서 진심을 다해 쏟아보자고 한 이상 묵묵히 앞으로 나아갔다.

24년 1월~8월 - B2G

살면서 교과서라는 것을 만들 줄 몰랐지만 정책 심사 가이드라인이 주어졌고 1월 박람회부터 8월 심사 제출까지 정말 모든걸 불태웠던 시기였다. 막바지에는 거의 집에도 가지 않았고 주말, 휴일에도 계속 일을 했다. 단순히 개발만 하고 끝낸게 아니라 중간에 연수 사업이니 시연이니 여러 사업적 요구사항이 주어져서 매번 계획했던 것보다 훨씬 빠듯한 일정으로 주어졌고 그 과정에서 어떻게든 우선순위를 조정하고 리소스를 확보해서 일을 끝내려고 했다.

CTO 보다는 PMO 또는 PM에 가까운 역할에 집중했고 이 시기 같이 일하던 PM들도 나를 PM으로 인식하고 있었다. 결론적으로 PM은 정말 나랑은 안맞는 포지션이라는걸 뼈저리게 알게되었지만, 그래도 개발자라는 에고보다는 이 일을 완수해내는데 최선을 다했다. 기존 서비스를 기반으로 하였지만 뼈대만 남긴채 단기간에 새로운 플랫폼을 만들었고 그렇게 해서 더운지 느끼지도 못하고 여름이 지나가 버렸다.

그리고 지금까지

24년 9월부터 지금까지 이야기는 이전 기록에서 충분히 설명하였다. 관심있으면 참고.

지난 7개월의 기록 - 생각의 나열 (2024년 9월~2025년 3월 기록)

정리하면

초창기: 레거시 플랫폼 리팩토링 및 안정화 (3명~13명)
1기: 신규 SA 플랫폼 런칭 (13명~20명)
2기: 플랫폼 고도화 (~25명)
3기: B2G 플랫폼 개발 (~35명)

아마 제일 재밌었던 시절을 꼽으라면 세명의 팀장 체제가 정리되고 23년 2월부터 이 체제가 변경되기 전까지 서비스 고도화에만 집중했던 23년 6월까지였다. 참 써놓고보니 그렇게 많은 일을 못한 것 같기도 하고 또 지난 시간을 곰곰히 곱씹어보면 무엇하나 쉬웠던 시기는 없었다. 코드를 작성하던 시기가 사실 더 즐거웠던 것도 맞고 사람들끼리 더 끈끈했다.

다만, 다른 분이 얘기했던 그랬던 기억은 나만 행복한 기억이고 이미 다들 잊으시고 최근의 기억만 주로 남으니 긴 시간동안 우리가 그래도 때로는 즐겁고 때로는 서로에게 끈끈했던 그 시기가 있었는데 이제는 더 이상 그때의 흔적을 서로 찾아보기는 힘들다는게 참 슬프다. 과거에 매여있자는 건 아니고, 마무리하고 떠나는 입장에서는 그래도 좋은 기억으로 남고 싶은 욕심 때문이겠지. 어쩌겠나, 지금까지 오기로 결정한 것도 나이고 순간순간 멈출수 있었음에도 계속 왔던 건 결국 내 선택이었으니. 어차피 박수받고 나가고자 했으면 이 자리에 왔었으면 안되었다. 여튼, 시간 순대로 두서없이 그냥 생각나는데로 했던 일들을 나열해보았다. 이제 하나하나 톺아보자.

Outcome (조직과 제품)

데이터팀

데이터 팀이 제대로 구축이 된건 22년 8월에 현재 계신 두분이 합류하면서 부터다. Airflow 를 통한 기본적인 데이터 엔지니어링 부터 시작하여 통계학 스터디(특히, 앤디필드 책을 파이썬으로 다 재작성하였다.)부터 데이터 웨어하우스 구축, 분석 파이프라인 구축 등 실제 서비스 운영에 핵심으로 들어가는 데이터 프로덕트 개발을 주로 같이 진행을 했다.

처음 합류때 두분다 주니어였기에 매주 같이 스터디도 하고 개발 설계도 같이 하면서 진행을 했고 처음 1년간은 각자 개인 시간까지 투자했던 덕분인지 두 분다 굉장히 빠르게 성장하셨다. 특히, 한분은 최근 2년간 바쁜 회사생활 와중에도 대학원 생활까지 끝냈는데 로봇 같은 분이라고 다들 놀리시지만 여튼 학업과 업무를 병행해본 경험이 있는 나로썬 정말 존경을 표할 수 밖에 없다.

사실 데이터 팀에 집중해서 더 많은 것들을 할 수 있었는데 아쉽게도 23년 하반기부터 내가 디자인 팀 대행을 맡게 되면서부터 팀 매니지먼트에 상대적으로 많이 소홀하게 되었고 여러모로 나도 직전 회사에서 데이터 엔지니어링을 하다가 왔다보니 조금 더 계획했던 로드맵을 더 많이 실행하지 못한 아쉬움이 남는다. 그래도 다행인건 두분다 스스로들 잘 하시는 분들이라 현재 업무를 마무리하는 이 시점에 가장 믿음직스러운 팀원들이고 가장 감사한 팀원들이다.

그리고 두분은 어떻게 생각하실지 모르겠지만, 내 입장에서 가장 편한 분들이고 여전히 조금 더 챙겼으면 좋았을걸 이라는 아쉬움이 많이 남는 팀이다. 현재 회사의 주요 과제인 AI Agent 프로젝트를 진행하고 있는데 그토록 염원하던 something AI 엔지니어링을 드디어 하게 되었으니 두분 다 꼭 성과를 보셨으면 좋겠다.

디자인팀

디자인 팀을 맡게된건 당시에만 해도 전화위복이라고 생각했다. 기존 팀장님이 나갔고 새로운 PM 채용을 하는 중에 내가 팀장 대행을 맡았는데, 다시 기획 세부로 들어가서 디테일들을 볼 수 밖에 없었던 시기였다. 다만, 한가지 후회하는건 기회를 충분히 살리지 못했는데, 그 이유가 얼마있지 않아 또 새로운 PM을 채용했기 때문이다. 주니어 PM이었기에 내가 여전히 팀장 대행을 맡았는데, 이전 PM 팀장님의 역할의 상당수를 신규 PM 에게 요구했던 것이 가장 큰 실수였다. (PM 얘기는 PM 파트에서 하고..)

디자인팀에서 개발자 출신 팀장이 유효타가 날 수 있었던 건 다행히도 내 사업을 하면서 체득한 기획 역량이 뒷밤침 되어주었던 부분이 있었고 단순 UX/UI 디자인이 아니라 세부 정책까지 맡아서 설계하는 프로덕트 디자인을 추구하고 있었기에 특히 그런 영역에서 여러가지 역할을 가져갈 수 있었다. 물론 심미적이나 조형적인 부분에서 내가 줄 수 있는 피드백은 0에 가까웠고 그냥 무지성으로 색깔이 좀 마음에 안든다 라는 피드백이 최선이었다. 할줄은 몰라도 못나고 예쁜건 판단할 수 있으니.

디자인 팀을 맡으면서 좋았던 건 한명 한명과 프로덕트 기획 방향성과 피드백을 주고 받는 시간이었다. 개발자나 디자이너나 메이커는 무조건 자기 솔루션에 과도하게 몰입할 수 밖에 없고 누군가 한 명이 계속 바깥에서 끄집어내는 역할을 해줬어야하는데 프로젝트를 이끌어갈때는 그런 부분에서 제 역할을 잘 했다. 특히 다양한 과제를 동시에 진행해도 제품은 하나고 그 제품을 쓰는 고객도 정해져있는 상황에서는 피드백을 유효하게 주기가 어렵지 않았고 디자이너 분들도 수용을 잘해주었고 이해가 안되는 것들은 그래도 계속 서로 설득을 하려고 노력을 했었다. 너만 그렇게 생각하는거 아니냐고 할 수 있겠지만 워낙 요구사항이 탑다운으로 꽂히다보니까 중간 관리자인 내 입장에서 우선순위를 결정하기 위해서는 무조건 계속 why 를 고민하고 동기를 만들어야 했다. 누군가에게 그 설득이 충분치 않을 수 있으나 절대 설득의 과정을 무시하지 않았다고 장담한다.

다만, 최근, 즉 마지막에 와서는 제품도 다양하고 스쿼드도 다양하고 고객도 너무 다양하다보니 실제로 구현 범위에서의 피드백 말고는 내 피드백의 유효타가 점점 줄어드는 경험을 했었고 만약 올해 퇴사를 하지 않고 계속했다면 연초부터 생각했던 방향은 디자인 팀장 역할을 위임하고 다시 CTO 역할로 돌아가는 것이긴 했다.

QA팀

QA팀은 처음 계셨던 PM 팀장님과 함께 초기 인력을 세팅했고 같이 QA 프로세스도 잡아나갔다. 사실 QA 팀은 처음 구축된 이후로 크게 성장을 만들지 못하였다. 아쉬움이 가장 크게 남는 팀인데, 데이터팀 디자인팀까지 팀장을 맡는 상황에서 QA 조직에 대한 방향성과 전문성을 가져가면서 팀을 이끌기엔 경험도 역량도 역부족이었다고 생각한다. 최후반부에는 QA팀에 계속 권한을 쥐어주고 더 잘할 수 있는 방향으로 의무감을 부여하는 방법으로 고민했었는데 아쉽게도 일하는 기간동안 제대로된 TC리뷰나 QA 자동화 프로세스 구축 등에는 거의 시간을 쏟지 못했다. 나는 경험이 부족하지만 팀에는 좋은 QA 팀과 일했던 사람들이 다수 있다. 팀 자체가 고민해서 앞으로 조금 더 조직에 기여하는 전문성 있는 팀으로 나아갔으면 하는 바램이다.

개발팀 (FE/BE)

처음 1년은 거의 개발팀과 같이 코드도 보고 직접 코드도 쓰고 대부분을 코드 리뷰하는데 시간을 썼는데, FE 팀은 처음부터 계셨던 FE 팀장님에게 위임을 하고 대부분 백엔드에 집중을 했다. 레거시, layered, functional, DDD, clean 등 내가 계속 초기에 셋업하려고 아젠다를 가져왔었는데 이 시기에 한가지 아쉬운 건 어떠한 설계 방법론도 100%라는 건 없기에 그레이 영역에 대한 판단 기준을 너무 모호하게 세우고 개발이 진행되었다는 점이다. 그게 아직도 프로덕션 코드에 많이 남아있는데, 내가 가져온 방법론이 지금 기준에서 또다시 레거시가 되더라도 당시에 조금 더 strict 하게 기준을 세우고 모호한 영역에 대해서 조금 더 밀도있게 코드 리뷰를 했어야했는데 나도 당시에는 많이 부족했었다.

당시 BE 팀장님이 오면서 코드 책임은 자연스럽게 위임을 했고 오히려 FE 주니어 개발자와 매주 시간을 내서 복잡하게 커플링된 컴포넌트를 풀어내는 프로젝트를 한다던가 반년 정도의 시간은 코드 작업은 대부분 데이터 엔지니어링 쪽이었다. 그래도 회사의 핵심 개발팀이기 때문에 주요 설계 사항이나 결정 사항들을 항상 팔로업하고, 또 신규 프로젝트 설계에도 적극 참여해서 설계 리뷰를 했었다. 코드 리뷰보다는 그 시점부터는 대부분 설계 리뷰와 기술 문서 리뷰를 주로 했었는데, 지금 돌이켜 생각해보면 코드 리뷰도 같이 계속 더 많이 챙겼어야했는데 하는 아쉬움이 있다. 물론 아예 코드를 안본건 아니었지만 많이 부족했다. 실제 설계대로 구현이 되는지는 코드의 결과로 검증해야하는데 프로젝트 초반 설계 리뷰에 치중된 탓인지 여하튼 내가 처음에 가져왔던 아젠다나 코드 구현의 본질이 많이 어긋나있었다는 것을 뒤늦게 많이 발견했었다.

항상 기술 스택부터 설계 방향까지 어느 시점에 언제로 돌아가서 다시 선택하면 어떻게 할까를 마무리하는 지금 이 시점에도 계속 고민했는데, 특히 B2G 를 하면서 플랫폼을 일부 재구축을 할 수 있는 시점에 조금 더 과감하게 기존 구조를 깨부수지 못한 부분이 아쉬움으로 많이 다가온다. 촉박한 개발 일정을 맞추려고 타협을 보았던 건데, 일종의 온고지신(?) 전략으로 접근했으나 결론적으로 지금 시점에는 후회하는 선택이 되었다. 후임자와 남은 개발자들 그리고 뒤에 들어오는 훌륭한 인재들이 꼭 현재 구조의 본질적인 문제를 해소하고 변경에 강한 소프트웨어, 핵심 로직에만 집중할 수 있는 효율적인 서비스로 개선했으면 한다.

PM

그냥 아쉬움만 남는다. 나는 24년 한해동안은 CTO가 아니라 PM 이었는데, PM으로서 대실패를 했다. 채용한 PM들의 장단점을 살려서 운용하지도 못했고 제대로 일을 위임하지고 그리고 제대로 서로 커뮤니케이션이나 공유도 되지 않았다. 가장 많은 시간을 보낸 팀이고 사람들인데.. 결론적으로 잘하지 못하였다. 같이 해준 PM들에게도 죄송하고 이 실패로 한동안 마음이 심란하기도 하였다.

몇가지 원인이 있는데, 가장 큰 원인은 내가 PM 리드 였고 내가 PM 롤모델이었다는 것이다. 그런데 내가 아무리 개발을 내려놓고 PM을 한다한들, 기술 베이스와 설계를 기반으로 제품을 리뷰하고 기획하는 역량은 오로지 나만의 것이다. 이건 내가 잘할 수 있는 영역인데, 처음에는 이 역할을 강요했던게 큰 패착이라고 생각한다. 그런데 PM은 일의 요구사항을 듣는 순간 내가 판단할 수 있나 없나를 메타인지 한 후에 내가 판단할 수 있는 것이면 빠르게 내가 판단하고 내가 판단할 수 없다면 빠르게 이해관계자들을 적시에 회의실에 앉혀서 일의 진행에 막힘이 없게 해야한다. 여기서 PM이 할 수 없는 것을 할 수 있다고 생각하고 시간을 지체하는 순간, 타이밍이 어긋나고 모든 실무자들이 불행해지는 방향으로 흘러가는 것이다. 그리고 인하우스 프로덕트에서 PM은 조금 더 빠르게 고객의 목소리를 딜리버리하는 역할, 문제의 본질을 판단하는 능력 그리고 그걸 메이커들과 협의하여 어떻게 고객만족을 하느냐에 그 역할이 있다. 타이밍도 나빴던 건 1년간 진행했던 B2G 프로덕트는 사실 그러한 경험을 전혀 할 수 없었던 프로젝트였고 해야하는 과제가 주어지면 그 과제의 범위를 최대한 최소화해서 최소 조건에 만족하게 만드는게 대부분 요구되는 역할이었다. 또는 사업지원서 같은 문서 작업을 하던가.

그래도 더 잘할 수 있었을 거라 생각한다. 그럼에도 불구하고 더 좋은 프로덕트 환경에서 일했어야 한다. 최소한 PM에 있어서만큼은 난 A급이 아니기 때문에 B2C 또는 B2B 인하우스 프로덕트에서 이 분들과 만나서 일했다면 조금 더 잘할 수 있지 않았을까, 조금 더 위임할 수 있지 않았을까 생각한다. 정말 이런 환경에서는 PM은 그냥 이리저리 치이면서 피만 빨리는 포지션인 것도 같다.

단 한번의 제대로된 칭찬도 없이 매번 잔소리만 했던 팀이다. 죄송스럽고 각자가 선택한 다음 환경에서는 두분다 조금 더 본인답게 일하는 환경에서 일하시길.

조직 구조의 변화

기능팀으로 시작해서 마지막에는 어설프지만 목적 조직, 스쿼드 체제로 가져온건 다행이라고 생각한다. 사실 주도적으로 조직을 변화시켰다기 보다는 변화하는 외부사업에 휘둘리면서 하나의 큰 본부가 기능팀 단위로 매 스프린트마다 맥락이 전혀 다른 일들을 하고 있는게 반복되었기 때문에 그 연속성을 가지고자 사람들을 조금 더 집중시키고자 생존형(?) 스쿼드 체제가 되었다. 그런데 PM 수도 부족하고 사업의 사이즈도 불균형이 심하고 맥락이 다른데(사업도 다르고 고객도 다른데) 같은 플랫폼 전략(같은 코드베이스, 같은 브랜치)을 가져가다보니 배포 때마다 항상 사고가 났다. 개선을 하려면 사업을 버리던가, 그게 안된다면 사업 단위로 코드베이스를 나누고 모든 것에 독립적으로 가져가야 스쿼드들도 속도를 더 잘낼 수 있을 것 같은데 이 부분에 대해서는 경영진과 내 생각이 달라 더 코멘트할 내용은 없다.

스쿼드마다 코드베이스를 분리하고, 스쿼드마다 수석 개발자를 두고, 스쿼드마다 담당 PM이 존재하고 (특히 B2G 같은 사업은 워낙 이해관계자가 얽혀있기 때문에 PM이 둘 이상은 필요하다고 생각한다.) 아예 조직구조도 스쿼드를 기준으로 확 분리시켰다면 인원이 몇명이든 조금 더 기민한 체제를 운영할 수 있었을까? 리소스가 없는데 리소스가 더 있었으면 잘했을 거라는 건 사실 회고에 적기엔 좀 치사한 내용인 것 같고, 사실 스쿼드 체제로 가면서 가장 바랬던 건 Back to the Basic 이었다. 내가 처음 합류해서 3명과 같이 조직 문화를 만들어가고 기민하게 팀을 이끌어갔듯, 다시 소규모 스쿼드가 되면서 그러한 문화를 만들어가는게 목표였는데.. 생각보다 그런 부분에서 현재를 비추어봤을때 잘되었다고 보기는 어렵다. 다년간 기능팀에 익숙해져서 그런걸까. 그저 작년에 B2G 프로젝트 때문에 사람들이 지쳐서 그런걸까.

그럼에도 불구하고 내가 했어야하는 정말 중요한 한가지는 사람들이랑 더 자주 1 on 1 하고 더 자주 얘기하는 것이었다. 1월에 부랴부랴 사람들이랑 얘기를 나눴을때는 너무 그 타이밍이 늦었다는 생각이 컸다. 누군가 나에게 내가 관리자인데 뭘 해야할지 모르겠다고 질문하면 부지런하게 사람들이랑 1 on 1 하는 것이 최선이라고 조언해줄 것이다.

또한 명확한 보고 체계의 부재가 가장 큰 문제 중 하나다. (위든, 아래든) 스쿼드 구조를 떠나서 팀장들이나 PM들이나 또는 시니어들에게도 직접적으로 정리하여 보고받는 체계를 더 빨리 만들었어야 했다. "스타트업" 그리고 각자 모두가 움직이는 조직에서 일했던 경험으로 "보고"라는 건 사실 금기시되는 용어로 여기며 살았는데 결국 큰 회사에는 보고 체계도 직급 체계도 중요하고 위임할 수 있는 사람에게 잘 위임하는 정말 필수적인 일이다. 이걸 너무 늦게 깨달은 것도 문제 중 하나라고 생각한다.

리더십은 아래로도 향하지만 위로도 향한다. 단순히 조직 구조를 바꾼다고 일이 되는게 아니다. 상위 사업구조와 하위 조직문화가 모두 뒷밤침 되어줄때 조직 구조도 제 기능을 다하는 것이다.

조직 문화

조직이 초기 20명으로 향하던 시점까지가 아마 내 영향력이 가장 컸던 시점이었고 체크인 미팅이나 랜덤밥메이트나 스프린트 회고 등 여러 장치들이 유효했었다. 온보딩 문서도 직접 작성하였고 내가 조직 문화에서 가장 중요시하는 유머와 서로에 대한 호기심을 잃지 않는 그런 장치들이 잘 동작했었다.

그렇게 동작하던 것들이 작년 B2G 프로젝트를 하면서 사람들의 동기 상실, 회사의 소통 부재 등이 겹치면서 무너져 내렸고, 나도 이러한 디테일들을 하나둘씩 놓기 시작하니 그나마도 동작하던 장치들이 마지막에 와서는 그냥 와르르 무너졌다. 더이상 이렇게 유지되는건 힘들다는 판단에 회사 EX팀에 의뢰를 하였고 이제 회사가 다시 앞으로 나아가야할 때 어쩌면 팀이 가진 정체성이나 문화는 다시 세팅되어야하는 시점인지도 모르겠다. 내가 만들어온 문화가 이제 더이상 동작하지 않는다면 이제 과감하게 벗겨내고 새로운 문화를 다시 셋업해나갔으면 한다.

인사

회사 인사팀이나 피플팀(문화)이 대부분 교육/선생님 운영 팀에 집중되어 있어서 대부분의 조직 인사를 내 손으로 모두 했어야 했다. 특히, 가장 에너지를 많이 쓴 것 중 하나가 매년 초마다 다가오는 연봉 협상 시즌이다. 혼자 있을때는 혼자 전체 팀원들을 평가했어야 했고 팀장이 있을때는 팀장들에게 위임을 하되 최종 평가는 결국 내 손으로 했다. 같이 작업한 사람들 사이에 피어리뷰도 도입해서 피어리뷰를 평가보다는 참고용으로 주로 활용했다. 팀원들 평가만 한달, 경영진과 연봉 협상만 거진 2달 했으니 23, 24년도에 연초 1분기 정도는 대부분 인사 업무가 내 에너지를 모두 쏟아부은 곳이었다. 회사 경영진에서는 연봉을 많이 올리기 부담스러워 했고 팀원들은 연봉을 많이 올리고 싶어했기에 허락되는 케파 사이에서 최대한 줄다리기 했어야 했는데 내 연봉도 아니고 팀원들의 연봉을 협의하는 과정은 그렇게 쉬운 과정은 아니었다. 그래도 1 on 1 부터 분기 회고, 피어 리뷰 등 조금 더 투명한 평가를 위해 다양한 방식을 도입했었고 진행을 했다.

다만, 이게 내 권한이 많은 만큼 책임도 많고 모든 실행이 내 손으로 진행되었어야 하다보니 내가 까딱 바쁘거나 정신이 없으면 놓치기 일쑤였다. 프레임워크나 시스템이 뒷받침되어 주지 않았고 인사팀 등의 그러한 기능이 전무했던 조직이었기 때문에 참 혼자서 고군분투하다가 보낸 시간이 많다.

돌아보면 팀 초기에 10명 미만일때는 인사팀 지원이 없어도 내 케파가 충분히 허락되는 규모라 더 자주 많이 피드백하고 평가도 있었지만 성장을 위한 커뮤니케이션을 많이 했었다. 1 on 1으로 같이 다음달 또는 3개월 동안의 목표를 잡고 어떻게 더 나아졌는지 뭐가 부족했는지를 회고하고 나도 그 시간에서 만큼은 가감없이 긍정적이든 부정적이든 피드백을 진행했다. 특히, 무조건 부정적 피드백을 한 사람 당 한 개 이상씩 준비했는데, 여기서 말하는 부정적 피드백이란 차후 액션 아이템으로 개선될 포인트가 있는 것들이어야 했다.

초기에 비해 팀도 커지고, 시스템은 여전히 없고, 회사가 여유가 없어지니 일관된 평가나 리뷰 프로세스를 유지하기가 힘들었다. 시스템을 만들기에는 회사는 아직 성장해야하는 부분이 많았고 시스템이 없이는 구성원들의 최소한의 성장을 담보하기 어려웠다. 연봉은 결국 받다보면 익숙해진다. 돈으로 사람을 설득하거나 약속하는 건 한계가 있다. 그건 그저 그 사람의 가치를 표현하는 많은 방법 중의 하나에 불과하다. 중요한 건 리더가 진심 어린 태도로 성장을 견인하고 그러면서도 객관적인 평가를 하면서 팀원들을 이끌어가는 것인데, 참 잘한다고 생각들다가도 정말 어렵다고 생각이 들 정도로 험난한 과정이었다.

팀원도, 회사도 연봉 협의에서 돈만 가지고 얘기한다. 회사측에서는 이만큼 줬으니 이만큼 해야지, 팀원은 이만큼 시키려면 이만큼 더 줘야지. 10점 만점에 6점 정도 일하는 팀원이 단순히 연봉 1000만원 올린다고 갑자기 8점이 되는 건 절대 아니다. (7점 아니, 6점에서 안떨어지면 다행일 수도.) 회사는 그런 기대를 하면 안되고 팀원의 그런 약속도 의미가 없다. 연봉 협상은 가치와 성장의 모멘텀을 가져가는 하나의 도구에 불과한 것이지, 맥락없이 그것만으로 해결하는 건 정말 사람을 모르는 짓이다.

개인의 성장을 항상 강조했지만, 결국 돌아서보니 팀의 성장 아니 더 나아가서 팀의 승리를 계속 이끌어야만 개인의 성장을 얘기할 수 있다. 팀의 승리는 스타트업인 이상 회사의 비지니스 목표와 연결되어야 하고, 그렇게 연결된 비지니스 목표를 견인하고 승리로 이끄는 팀이 되어야 한다. 무엇이 승리인지 알 수 없는 조직 아래에서 리더가 아무리 개인의 성장을 얘기해봤자 그건 공허한 얘기다. 팀의 승리가 있어야만 그 위에 개인의 성장이 있다. 팀의 승리를 위해 개인의 성장이 희생될 수도 있다. 하지만 팀의 승리 없이 개인의 성장도 없다.

경영진은 자기가 생각하는 제품을 잘 만들어줄 것을 요구했고 비지니스와 개발팀을 분리시켜서 운영을 했다. 모든 지표와 요구사항의 백그라운드는 경영진을 통해서만 들을 수 있었다. 옳고 그름을 떠나서 참 팀의 승리를 정의하기 어려운 구조다. 가장 힘들었던 순간이 B2G 프로젝트가 마무리되고 팀원들이 3,4개월 크런치 모드로 일을 했을때 였는데 우리는 최종 목표였던 심사 통과를 완료했지만 그건 승리가 아니었다. 사용자도 매출도 아닌 그저 판매 권리를 딴게 전부였다. 그 어떠한 비지니스 목표를 이루지 못한 상태에서 팀원들은 충분히 열심히 일을 해주었고 그 과정에서 조금 더 보상을 원하는 건 무리도 아니었다.

당연히 추가 보상은 없었고 그 시점부터 회사가 힘들어졌기 때문에 당연한 것도 없어지던 시기가 되었다. 정확한 비지니스 목표 정의와 리턴없이 거기에 정말 많은 비용을 썼다. 단순히 인건비와 시간을 떠나서 말그대로 돈으로 할 수 있는 건 다 돈으로 했다. 그러나 경영진은 아무런 설명이 없었기에 (설명을 요청해도 이제는 돈을 아껴야된다는 말뿐.) 내가 중간에서 억지로라도 회사의 메시지를 만들고 비전을 얘기하고.. 하지만 내가 최종 의사결정자가 아니니 내 말에 힘이 실릴 수가 없었던 시기였다. 또한 나조차도 B2G 프로덕트로 비지니스를 하는데 있어서 굉장한 회의감을 가지고 있었다. 지금 돌아보면 결국 CTO 인 나를 회사가 충분히 존중하지 못했기 때문이라고 생각한다. 그 의도와 이유가 어찌되었든 말이다.

매년 나가던 명절 선물이 휴가 하루 전날까지 나오지 않는다는걸 본부장인 내가 다른 이사들에게 물어서 알게되어서 부랴부랴 사비로 팀원들의 명절 선물을 샀던 얘기는 코미디다. 내 사비로 샀다고 자랑하는게 아니다. 지금 판단이었으면 절대 내 돈으로 사지 않을 것이다. 다만, 그런 순간순간들이 30명이 넘는 본부를 이끄는 나의 리더십을 범위 밖의 능력까지 시험하게 했고 아마 그 부분이 내 인내심을 많이 바닥냈을 것이다.

그래도 이런 여러 경험 덕분에 어떻게 조직을 운영하고 관리하고 사람을 채용하고 등 인사에 관련된 많은 경험을 하게 되었고 책에서만 읽은 내용이 아니라 현실에서 박살이 나면서 뼛속깊이 새겨진 이 경험들은 앞으로도 계속 나에게 남을 것이다. 당분간은 큰 팀을 운영하지는 않을 것 같지만 계속해서 포기하지 않고 고민을 해보려고 한다. 나도 팀으로 일하는 걸 정말 사랑하기 때문에.

제품

제품을 만들면서 항상 구조 중심, 설계 중심, 솔루션 중심으로 제품을 기획했었는데 때론 확장성을 고려하고 구조 중심의 사고가 많은 도움이 되었으나 결론적으로 후회하는 건 고객 유즈 케이스를 놓쳤던 건들이다.

단적인 예로 현재 콘텐츠 시스템의 커리큘럼은 그 커리큘럼이 완성된 이후 쓰여진다는 것을 전제로 구조가 설계되었는데, 실제 서비스에서는 완성된 커리큘럼보다는 매번 새로 만들고 쓰면서 업데이트되는 커리큘럼이 대부분이고 심지어 고객들도 그러한 케이스에서 돈을 지불한다는 것이다. 초기 1년동안 기존 레거시를 따라잡아야 한다는 생각과 뇌피셜로 생각한 구조적 완결성에만 집중한 결과, 당시에 아무리 확장성을 고려했다 한들 너무나 변경에 취약한 구조를 가지게 되었고 제품 설계 자체가 선천적으로 변경에 취약하다보니 다양한 유즈케이스와 엣지케이스가 드러날수록 계속해서 개발 비용이 기하급수적으로 늘어났다.

마치 객체지향 class에서 getter 와 setter 를 만들면 여기저기서 다 일반화해서 쓸 수 있다는 생각으로 만들어서 썼다가 기능 요구사항이 계속 늘어나면서 getter, setter 에 if 문이 덕지덕지 붙게되고 잘못 건드려서 다른 모든 영역에 사이드 이펙트를 일으키는 것처럼 DDD 나 최근 설계 트렌드와는 다르게 근본적인 모델 설계를 너무 strict 하게 가져갔고 그렇게 정해진 구조는 일종의 불변의 법칙이 되어서 추후 모든 변경사항은 이걸 건드리지 않고 변경을 하거나 이걸 활용해서 변경을 해야했기에 필연적으로 개발 비용이 늘어날 수 밖에 없는 구조가 되었다.

니가 CTO 였는데 니가 더 잘했으면 되는거 아니냐고? 하하, 맞다. 그래서 후회한다고 썼다. 초기에 실무 부서들이 정확히 무얼하는지 어떻게 서비스를 운영하는지를 더 많이 인터뷰하고 실제 업무도 해보고 이해를 했어야했는데 레거시를 대신할 신규 플랫폼에 집중해야 했기에, 무조건 새로운 플랫폼이 기능도 디자인도 좋다는 뇌피셜에 빠져있었기에 실제 고객 사이드에서 일어나는 유즈케이스를 깊게 들여다보지 못한채, 고립된 상태로 개발을 했다. 사실 22년 런칭 이후에 퇴사를 하지 않은 것도 이것을 만회 또는 고객 유즈케이스에서 개발하고자 하는 니즈가 강했었다.

사실 개발 스택을 뭘 쓸까 보다 이 부분이 마지막까지도 크게 아쉬운 부분이다. 개발자가 좋은 코드를 짜려면 고객을 알아야한다. 단순히 PM이나 디자이너가 알려주는 내용, 남이 알려주는 내용만으로 코드를 짠다면 결국 빠른 시일 내에 내가 짠 코드를 보고 탓하고 있을 것이다. 단순히 코드 이슈라면 리팩토링이라도 하겠지만, 디비 스키마부터 이미 쌓여버린 프로덕션 데이터들, 관계 테이블의 구조들을 다시 뒤집고 마이그레이션하고 개발하는건 사실 서비스가 궤도에 올라서 또다른 비지니스 요구사항으로 달려가는 시점에는 불가능에 가깝다. 계속 거대한 혹을 달고 가는 것과 다름없다. 기술기술기술 하면서 에고를 가지는 개발자들이 착각하지 말아야할 것은 우리의 가치는 결국 고객의 가치 실현으로 연결될때 그 의미가 빛을 발한다는 것이다. 내가 돈을 받는데, 그게 고객 가치랑 연결이 되지 않는다면 사실 그건 시한부 개발자나 다름없다고 생각한다.

어쩌고저쩌고 돌고돌아 고객 중심. 결국은 누군가 쓰는 제품을 만드는 것을 명심 또 명심하자.

마무리하며

내가 결국 만든 건 조직과 제품인데, 조직 관점에서 가져가야하는 단 한가지 액션 아이템을 뽑자면 무조건 더 자주 1 on 1 하자. 제일 많이 아쉬우면서 그때 했었으면 조금 다를 수 있었는데 하는 것들이 마지막에는 훨씬 더 뼈저리게 다가왔다. 제품 관점에서는 바로 직전에 말했듯이 고객 중심. 구조고 설계고 뭣이 중헌디. 고객 중심이 최우선이어야 한다. 착각하지 말자. 절대 고객 얘기를 있는 그대로 듣기만 하라는게 절대 아니다. 오히려 거기서 숨겨져있는 요구사항과 니즈, 기회를 포착하는게 진짜 실력이라고 생각한다. (그리고 그걸 코드로 가져올 수 있는 개발자가 되자.)

앞서 나의 다른 글들이 그렇듯 4년간 무슨 일을 했는지 간략히(?) 돌아보았다. 생각나는데로 써재낀(?) 글이라 횡설수설 말그대로 사고의 흐름을 그대로 옮겨담았다. 글을 쓰면서 새로운 시작을 위해 다 털어버리자는 마음도 있었고 과거에 연연하지 말고 여기에 묻어버리자는 마음도 동시에 들었다. 기억은 희미해질 것이고 여기에 있는 글을 읽으면서 아 그때 그랬지 라고 생각할 것이다. 사실 회사나 다른 아쉬움들도 현재 많은 상태다. 하지만 공개된 공간이다보니 그런 것보다는 내 기록과 내가 행동으로 이끌어 낼 수 있는 일들에 집중하여 글을 썼다. 그러한 아쉬움도 어느새 다 희미해지리라. 다른 버전의 솔직한 생각들은 현재가 한참 지난 어느 시점에 내가 여전히 그럴 의지와 기억을 가지고 있다면, 다시 글로 옮겨보겠다.

사실 난 20대 대부분을 내 사업을 하면서 커리어를 채웠으니 경력이 13년이 된 것 치곤 직장인으로는 처음으로 이렇게 오래 회사에 있어보았다. 그것도 그냥 말단 직원이 아니고 CTO라는 직함의 중간 관리자로. 20대부터 30대가 넘어서까지 계속 대표님으로 불리다가 이제야 이사라고 불리는게 좀 적응이 된 것 같은데 시간이 참 무섭다.

회사가 급격하게 성장하는 모습도 어려운 모습도 모두 보면서 때로는 내가 경영자라면 이 상황에서 어떤 판단을 내렸을까 항상 멘탈 시뮬레이션을 했다. 내가 누구보다 더 잘났다가 아니라 나는 나만의 스타일이 있으니까 내 방식에서의 최선을 항상 고민했고 그러면서 경영자의 입장도 항상 같이 이해하려고 노력했다. R&D본부가 3명에서 30명이 될때, 회사는 100명에서 500명이 되었으니 난이도가 당연히 높은 일이다.

상사를 뒤에서 씹어대거나 법인카드로 맛난 것도 먹었고 월급의 소중함도 깨달았다. 경영자로만 있었을때는 몰랐던 많은 것들을 알게 되었다. 조금 더 현실주의자가 되었고 중간 관리자로서 항상 책임을 다하려고 했으나 생각보다 그것도 쉽지 않았다. 팀원들에게는 "나도 너네들이랑 같은 입장이야", "내가 책임지고 결정할게" 이 상반된 문장들을 항상 가슴속에 품고 있었고 어떨때는 위든 아래든 모두가 미울때도, 때론 모두에게 한없이 감사할때도 있었다. 마지막의 마지막이 되어서야 아쉬운 마음이 제일 크지만 참 이 시간동안 많은 걸 느끼고 배우고 얻어가는 시간이었다.

어느 시점엔가 회사 일이 너무 힘들고 스트레스가 심해져서 (무슨 일 때문인지는 기억이 안나고) 아내 품(결혼 전이다.)에 안겨서 엉엉 울었던 적도 있다. 그리고 어느 시점에는 불면증(나는 진짜 어디든 누우면 바로 자는 사람이다.)과 잠꼬대로 욕을 하지를 않나 새벽에 회사 일 때문에 잠에 깨서 하룻밤을 지샌적도 종종 있었다. 내가 내 사업했을때보다 더 스트레스를 받았다. 마지막에서야 사람들에게 힘든 기색을 보이기는 했지만 그래도 드러내기 좋아하는 나 치고는 포커 페이스하면서 여기까지 잘 왔다. 생각을 깊게 하면 모든 것이 다 아쉽고 후회될 것이다.

이제, 4년간의 치열했던 기억은 여기 묻어두고 좋은 기억과 배움만 손에 쥐고 새로운 출발을 해보자.

What we call the beginning is often the end. 우리가 시작이라 부르는 것은 종종 끝이다. And to make an end is to make a beginning. 그리고 끝을 만드는 것은 시작을 만드는 것이다. The end is where we start from. 끝은 우리가 출발하는 곳이다.

― T.S. 엘리엇

정리도 되지 않고 뒤죽박죽인 제 4년간의 발자취를 마지막까지 읽어주신 모든 분들께 감사의 말씀을 드립니다. 당분간 쉼을 가지고 새로운 소식으로 돌아오겠습니다.

지난 7개월의 기록 - 생각의 나열 (2024년 9월~2025년 3월 기록)

Tony Cho (https://flowkater.io) — Tue, 01 Apr 2025 00:00:00 GMT

들어가며

8월 이후로 회고를 전혀 하지 않았다. 몸도 마음도 건강하지 않은 상태에서 9월부터 3월까지 반년 이상이 지나갔다. 목표도, 회고도 없이 흘러간 시간이 장담컨대, 근 몇 년간 최악의 시간이리라. 여름까지 만들었던 건강도 망가지고 정신 상태도 썩 좋지 않았다. 이제 한번 삶을 괴롭히고 좀먹던 문제들을 깨끗하게 초기화하고 가기로 결정한 지금, 이제는 좀 지난 시간에 대한 기록을 쓰기로 마음먹었다. 이건 회고라고 보기엔 어렵고, 매달 하던 기록에 못 미치지만, 매년 하던 기록에 비하면 그 주기가 짧으니 그 이유를 위안 삼아 그저 두서없이 기록을 남겨보려고 한다.

결혼 생활

9월은 회사에서 B2G 사업이 일단락되는 시즌이었다. 지나고 보니 여름이 더운지도 모르고 일했던 그 시절이었는데, 그저 당시에는 끝났다는 안도감에 잠깐의 휴식을 가지고 싶었다. 9월 추석 연휴에 양가에 양해(?)를 구하고 우리 부부는 스위스, 프랑스로 여행을 다녀왔고 이를 통해 지난 회사에서 불태웠던 긴 시간을 회복하고자 했다. 하지만 신혼이었던 24년 상반기, 반년에 이르는 시간 동안 나는 결혼 생활보다 회사 생활이 삶의 전부였고, 그 기간 동안 각자의 방식으로 버티던 우리 부부의 그 시간은 단순히 유럽 여행 한 번으로 회복되기에는 생각보다 긴 시간이었다. 사실 이때부터 정신을 차렸어야 했는데 당시에는 그저 억울함이 가득했다. 그냥 열심히 하려고 하다가 그런 건데 라는 생각만이 있었던 것 같다. 결국 이 시간을 회복하는 데는 똑같이 6개월만큼의 시간이 필요했다. 다행스러운 건 그래도 회복을 하는 방향이라는 것, 그리고 이건 전적으로 아내의 다짐과 마음가짐 그리고 노력 덕분이라고 생각한다. 물론 그 과정은 우리 둘에게 굉장히 고통스러웠지만.

회사

B2G 사업은 아무리 의미 부여를 해도 내게는 그저 외주 사업에 불과했다. 정부에서 제시한 통과 가이드라인이 있었고, 그 또한 모호해서 이걸 자의적으로 해석하며 어떻게 여기서 더 점수를 따서 만들어내느냐에 집중했다. 그 과정에 고객도 사용자도 없었고 그저 여기에서 이걸 엉성한 상태에서 급하게 정책을 밀고 나가겠다는 정부와 어떻게든 그 리그에 합격하기를 위한 기성 시장의 플레이어들만이 존재했다. 우리도 그 게임에 참여하기 위해 무조건 기성 시장의 플레이어들과 손을 잡을 수밖에 없었고, 모호한 가이드라인, 기성 시장 플레이어들의 이해가 가지 않는 요구사항에서 줄다리기하면서 프로덕트 개발을 마무리했다. 본격적으로 시작한 건 24년 5월이었지만, 사실 23년 9월부터 여기에 많은 걸 쏟고 있었고 현재 25년 4월 이 시점까지, 거의 1년 6개월에 달하는 시간 동안 해당 프로젝트에 팀은 물론 나 또한 많은 리소스를 쏟았다.

스타트업은 외주 사업을 하지 말아야 한다? 그런 낭만을 추구하려는 게 아니다. 사업은 현실이니까. 그게 스타트업이니 뭐니 다 떠나서 말이다. 그래서 인하우스 프로덕트의 침체기에 외주 사업에 손을 대는 건 돈 없는 스타트업에게는 당연한 수순이다. 예전에 당시 엑스엘게임즈 송재경 대표님이(지금은 퇴사하신 듯) 식사 자리에서 넥슨 초창기 바람의 나라 개발 썰을 들려주면서 그때도 자기 빼고 다른 직원들은 홈페이지 외주를 했다는 얘기도 들려주었다.

얘기가 다른 곳으로 샜는데, 결국 앞으로 나아가기 위해서는 하기 싫은 일이라도 해야 한다. 그게 사업이다. 그런 얘기를 하려는 게 아니다. 만약 이게 단순히 외주 사업이었다면 외주 개발이 착수될 때 착수금이 들어와야 하고 그리고 마무리될 때 잔금이 들어와야 할 것이다. 그것도 최대한 빨리. 이것이 인하우스 프로덕트 개발이었으면 당장의 수익을 포기하더라도 더 큰 가치를 바라볼 수 있다. 그런데 이게 단순히 이해관계자 몇 명의 요구사항으로 시작된 프로젝트라면 진짜 빨리 해치워버리고 정산받고 빠지는 게 인하우스 프로덕트를 가지고 있는 스타트업에게는 최선이다.

우리는 여기에 1년 반의 시간을 썼다. 이게 B2G 사업이다 보니, 단순히 외주 사업보다 훨씬 난이도가 있었지만 우리는 모든 요구사항을 충족했고 좋은 결과를 만들었다. 하지만 착수금도 잔금도 없었다. 그저 B2G 사업의 통과는 우리에게 이 시장에 진입하여 해당 제품을 세일즈하는 조건을 부여해주는 것에 불과했다. 중요한 건 그 통과 기준이 전혀 시장의 요구사항을 반영하지 않고 있어, 우리가 영업을 하려면 다시 제대로 개발해야 하는 것이 산더미다. 그리고 엎친 데 덮친 격으로 12월, 아무도 예상치 못한 대통령의 계엄 선포를 비롯해 안 그래도 불안했던 정책 여론이 더 강화되며 사실 25년도에는 약간의 리턴을 기대했던 그 기대마저도 완전히 날아가게 되었다.

스타트업은 사실 Plan B를 고려할 수 없다. 항상 Plan A만 바라보고 미친듯이 달려들기 때문에 희박하나 그 성공이 다가왔을 때 그 누구보다 빠르게, 크게 나아갈 수 있는 것이다. 그래서 이러한 사업적 결과를 결과론적인 입장에서 이러쿵저러쿵 얘기하는 건 너무 쉽다. 그 시점에는 무엇 하나 알 수 없다. 결국 위기가 다가오면 더 줄이고 줄이면서 다음을 도모하고 버텨야 하는 것이다. 스타트업의 관점에서 이러한 판단은 너무나 자연스럽다.

그런데 이 과정에서 그걸 같이 하는 임직원들은 꽤 괴롭다. 최선이라고 생각했던 결정들이 잘못된 결정들이 되고 잘못된 결정들이 곧 임직원들의 모든 것에 영향을 준다. 금전적인 부분이든, 정신적인 부분이든. 이 과정을 함께하고 싶지 않다면 임직원 입장에서는 빠르게 떠나는 것이 정답이다. 아무도 비난하지 않는다. 아무도 그럴 자격은 없다. 다만, 이러한 결정이 모두의 결정이 아니기 때문에 어떻게 이런 결과가 나오게 되었고, 지금 현재 상태가 어떤지 정확히 공유해주어야 한다. 그게 소통이라는 것이다.

아무리 생각해봐도 결국 경영진 입장에서 할 수 있는 최선은 이것뿐이다. 그리고 그걸 통해서 임직원들이 각자 판단할 수 있는 기회를 주어야 한다. 가던가, 남던가. 그게 서로를 위한 최선이다. 갈 사람은 서로의 앞길을 잘되길 빌어주고, 남은 사람들은 합심하여 위기를 기회로 바꾸기 위해 집중해야 한다. 회사도 그걸 요구할 수 있어야 한다.

하지만, 소통의 부재는 이 모든 기회를 박탈시킨다. 임직원에게도, 회사에게도 그렇다. 특히, 답을 기다리고 있는 팀원들에게 아무런 정보도, 권한도, 답변도 할 수 없는 중간 관리자의 입장은 정말 난감하기만 하다. 무기력하고, 무력하고 할 수 있는 최선을 다하고자 마음을 다잡아도 결국 무너지고 만다. 내가 무얼 더 할 수 있었을까? 사실 잘 모르겠다.

당시에는 이런 내 입장을 모르는 팀원들도, 경영진도 전부 싫었다. 에둘러서든 끼리끼리든 그들끼리 하던 말들이 내게 들리는 순간, 마음에 상처가 생긴다. 할 수 있는 게 아무것도 없는데, 어쩌면 그들도 나를 향해 하는 말이 아니었을 수 있지만, 전부 나에 대한 비난으로 들렸다. 회사 전체의 문제와 책임을, 마치 다 내 문제와 책임으로 느끼고 감당하려고 했던 것 같다. 리더라는 자리는 그런 거라고 생각한다. 상황이 어떠하든 마지막까지 책임을 다하려고 하는 것.

그런데 아무런 정보도 권한도 없는 기간이 길어지면서 결국 한계가 왔다. 모든 사업적 판단이 앞단에서 일어나고 끌려가듯 시키는 거, 놓여진 것만 개발하고 있는 상황이 또 반복되었다. 어떻게 이 상황을 개선하겠다. 소통하겠다. 는 없다. 그저 이전과 같은 방식으로, 어딘지도 모를 그곳으로 향해 그냥 앞으로만 다시 가야 했다.

처음에는 내가 못해서 우리 부서만 그런 건가 했었다. 그래서 우리 부서만 계속 외딴섬인가 했는데, 다시 돌아보니 모든 부서가 외딴섬이다. 오히려 내가 가진 정보가 그나마 빨랐던 거다. 이게 더 이상 개선되기 힘들다는 걸 내가 깨달은 순간, 그리고 나랑 함께하는 사람들이 더 이상 회사에게도, 이제는 나에게도 더 이상 기대가 없다는 걸 깨달은 순간, 그만하기로 하였다.

월별 회사 요약

9월
- 프로젝트 제출 완료. 당시에만 해도 회사에서 인하우스 프로덕트에 다시 집중하자고 해서 안 그래도 지긋지긋한 B2G 프로덕트를 정리하고 인하우스 프로덕트의 목적 조직, 스쿼드 형태로 운영 계획을 세우기 시작했다.
10월
- 갑자기 글로벌 사업 프로젝트가 시작된다는 얘기를 들었으나 외면했고 B2G 프로덕트의 심사 후 후속 수정보완 기간이라 거기에 집중했다. 그냥 빨리 끝내기를 바랐던 것 같다.
11월
- B2G 프로덕트의 심사 합격이 났다. 이게 플랫폼이 아닌 콘텐츠의 개수로 하다 보니 불합격 난 콘텐츠도 있었지만, 그래도 과반 이상은 합격이 났다.
- 이때, 인하우스 프로덕트 스쿼드로 빠르게 조직을 재편하고 과제 기획 및 개발을 진행하였다.
- 이 시기도 쉽지는 않았지만 인하우스 프로덕트 과제 기획 개발을 중심으로 하다 보니 재미는 있었다.
12월
- B2G 프로덕트를 다시 개발해야 하는 시기가 되었다. 11월에 불합격 콘텐츠에 대한 재심사 제출 일정이 있다고 전달받았고, 새로운 파트너도 있었다. 매번 그렇지만 추가 개발은 없다고 전달받았지만 역시 까보니 지난 상반기 못지않은 요구사항이 쏟아져 있었고 결국은 인하우스 프로덕트 스쿼드의 1차 과제가 마무리되면서 어쩔 수 없이 또 B2G 프로덕트 과제를 끌고 왔다.
1월
- 스쿼드는 인하우스 프로덕트 기준으로 가고 있었지만, 결국 B2G 프로덕트를 무조건 해야 하는 상황이어서 대책이 필요했다. 팀장들과 회고를 통해 바쁘다는 핑계로 놓치고 있는 게 너무 많다는 것도 깨달았다. 다시 사업 단위(글로벌, B2G, 인하우스신규)로 스쿼드를 재편하고 팀원들에게 직급도 부여했다. 회사가 어떻든 내 개인기로 최대한 살려보고자 했던 것 같다.
2월
- 새로운 스쿼드 체제로 기민하게 움직이나 했으나 결국 무엇 하나 제대로 돌아가지 않았고, 본질은 그대로라는 걸 깨달았다. 너무 맥락이 다른 세 가지 스쿼드를 누구에게도 제대로 위임하지 못했고 결국 어느 하나 제대로 알지 못하는 상태가 되었다.
3월
- 앞으로의 시간을 어떻게 보내야 하는지, 내가 여기서 무엇을 기대하는지, 모든 걸 고려했을 때, 알고 보니 떠났어야 하는 사람은 나였다는 걸 깨달았다. 이미 사람들이 나에게 그 어떤 기대도 하지 않기 시작할 때가 그나마 나은 타이밍이었는데, 그마저도 늦어버렸다. 알량한 책임감 하나로 여기까지 왔는데 모든 기회비용을 고려했을 때, 결국 지금이라도 떠나는 결정이 맞다고 생각했고, 지금 시점에서는 확신이 생겼다.

회사 얘기는 여기서 그만 줄이겠다. 회사 전체에 대한 회고는 다른 글로 남기겠다. 최근 6개월이 힘들었다고 모든 기억이 나빴던 건 절대로 아니다.

개인 (건강, 독서, 기타)

마음이 어둡다 보니 루틴이 많이 무너졌고, 중간중간 그런 마음을 풀고자 무리하게 운동을 시도했던 결과, 부상이 따라왔다. 부상이 있으니 운동 가는 것이 힘들어졌고 아직도 부상 회복 중인 상태다. 멘탈이 안 좋을 때라 운동을 못하니 결국 또 스트레스 해소가 음식 섭취로 이어졌고, 몸도 마음도 많이 망가져 가던 시간이었던 것 같다. 최근에서야 병원 치료도 꾸준히 받고 재활 운동도 계속하고 있다.

내가 가장 문제가 있다고 생각한 증상이 독서다. 6개월간 거의 책을 읽지 않았다. 그 바쁜 와중에도 책을 놓은 적이 없는데, 책을 그냥 아예 놓았다. Input이 없으면 소진될 수밖에 없다. 그렇게 자연스럽게 소진되고 있었나 보다.

앞서 말했듯이 우리 부부는 잠깐 어려운 시간이 있었고 그 시간을 해소하기 위해 여러 방안을 취했는데 그중 하나가 여행이었다. 프랑스, 스위스뿐만 아니라 세부, 오사카, 교토 시간이 허락된다면 최대한 멀리 떠나서 좋은 시간을 보내려고 했다. 물론 한창 싸우던 시기라 힘들었던 시간들도 있었지만 결국 잘 다녀온 것 같다. 많이 도움이 되었던 시간들이다. 여전히 유명한 관광지를 들린 기억보다 둘이서 두런두런 얘기하며 평범한 거리를 걸었던 그 순간순간들이 떠오른다.

나가며

이 글은 회고도, 그 시간들에 대한 기록도 아니다. 회고라고 하기엔 너무 생각의 나열이고, 기록이라고 하기에도 너무 생각의 나열이다.

내 어려움은 어떤 이에게는 아무것도 아닐 것이다. 그리고 내 어려움을 공개적으로 동의받고자 쓰는 글도 아니다. 그저 이러한 정리되지 않는 생각들이 존재하는 상태에서 어쩌면 용기가 충만해야만 할 수 있었던 다음의 선택을 과감히 내렸고, 결국 뒷걸음치다 쥐 잡는 격이 되었는데 - 어떻게 뒷걸음을 치고 있었는지에 대한 기록이다.

인생은 항상 쉬운 결정과 어려운 결정을 쥐어주고 하나를 선택하라고 강요한다. 그래서 가혹하다. 그런데 항상 정답은 어려운 결정이었다. 새로운 선택이 더 어려운 길이라 나는 선택했다. 회사가 이러쿵저러쿵해도 결국 여기 있는 게 나한테 더 쉬운 결정이다. 물러나면 또 후회할 것 같아서, 그냥 뒷걸음질 친 김에 새로운 길로 가고자 한다. 그렇다고 남에게 어려운 길을 강요하고 싶지 않다. 모두가 각자에게 최선의 선택이 있을 뿐.

앞으로의 구체적인 계획이나 지난 4년간 회사 생활에 대한 회고는 다른 글에서 남기도록 하겠다.

All that is gold does not glitter 금이라고 다 반짝이진 않으며 Not all those who wander are lost 방랑자라고 다 길 잃은 것은 아니다 The old that is strong does not wither 오래되더라도 강한 것은 시들지 않고 Deep roots are not reached by the frost 깊은 뿌리에는 서리가 미치지 못한다 From the ashes a fire shall be woken 잿더미 속에서 불꽃이 깨어날 것이고 A light from the shadows shall spring 어둠 속에서 한 줄기 빛이 나타날 것이다 Renewed shall be blade that was broken 부러진 칼날은 다시 벼려지고 The crownless again shall be king 왕관을 잃은 자 다시 왕이 되리라

⁃ J.R.R. 톨킨, 반지의 제왕 중

이전 회고
- 피, 땀 그리고 서운함 (2024년 7, 8월)
다음 회고
- 4년간의 IHFB 회고

3. 산출물이 아닌 성과에 집중하기 - Continuous Discovery Habits

Tony Cho (https://flowkater.io) — Mon, 03 Mar 2025 00:00:00 GMT

들어가며

프로덕트 팀에서 일하다 보면 결과(Outcome)와 산출물(Output)의 차이를 이해하는 게 생각보다 어렵다는 걸 느낀다. 로드맵에 기능을 나열하고, 그걸 기한 내에 출시하는 것이 성공이라고 생각하기 쉽다. 그런데 정작 그 기능이 비즈니스에 어떤 영향을 미쳤는지는 잘 모른다.

이번 장에서는 결과 중심 사고로 전환할 때 부딪히는 현실적인 어려움과, 이를 해결하기 위한 구체적인 방법을 정리했다.

tails.com 사례로 보는 결과 중심 사고

tails.com 팀은 고객 리텐션 개선이라는 과제를 받았다. 분석 결과, 서비스 초기 90일간의 고객 유지율이 장기 유지율을 결정하는 핵심 지표라는 것을 발견했다.

그런데 90일은 너무 길었다. 빠른 실험을 위해 5일로 단축했지만, 이게 정말 장기 유지율의 선행 지표인지 확신이 없었다. 유지율을 5일로 줄이면서 실험 속도는 빨라졌지만, 비즈니스 성과는 모호해졌다.

그래서 팀은 고객 인터뷰를 진행했다. 고객이 왜 이탈하는지 직접 물어본 것이다. 결과는 두 가지로 압축됐다. 첫째, 모든 고객이 맞춤형 사료의 가치를 제대로 이해하고 있지 않았다. 둘째, 일부 개들은 단순히 이 사료를 좋아하지 않았다.

여기서 중요한 전환이 일어났다. 고객 인터뷰를 통해 당장 측정 가능하고 실행 가능한 두 가지 **제품 결과(Product Outcome)**를 도출한 것이다. 맞춤형 사료의 인지 가치를 높이고, 더 많은 개들이 사료를 좋아하게 만드는 것. 이 두 가지가 팀이 집중해야 할 진짜 목표가 됐다.

결과 중심 사고로 전환할 때의 어려움

이 사례에서 볼 수 있듯이, 하나의 지표를 선택하는 것만으로는 충분하지 않다. 결과 목표가 주어지더라도, 어떻게 측정해야 할지, 어떻게 영향을 미칠지, 심지어 그것이 올바른 결과인지조차 모를 때가 많다.

90일 유지율처럼 시간이 오래 걸리는 지표를 사용하면 빠른 실험 사이클을 운영하기 어렵다. 결국 프로덕트 팀은 비즈니스 결과와 제품 결과 사이의 연결고리를 찾기 위해 어느 정도의 사전 조사(Discovery)가 필요하다. 비즈니스 결과를 실제 실행 가능한 제품 결과로 전환하는 과정이 핵심이다.

왜 결과(Outcomes)인가?

결과로 관리한다는 것은 팀에게 자율성, 책임감, 그리고 주도성을 부여하는 것이다.

전통적인 로드맵 방식은 정해진 기능들을 특정 시점까지 개발하라고 요구한다. 반면 결과 중심 관리는 고객 문제를 해결하거나 비즈니스 니즈를 해결하라는 문제 정의가 주어진다. 어떻게 해결할지는 팀이 결정한다.

진정한 Continuous Discovery Team이라면, 프로덕트 트리오는 고객과 기술에 대한 깊은 이해를 갖추고 있다. 그래서 특정 문제를 해결하는 데 있어서 의사결정 우위를 가진다. 결과 관리 전략은 이런 불확실성을 허용한다.

고정된 로드맵은 마치 우리가 무엇을 만들어야 하는지 완벽히 알고 있는 듯한 거짓된 확신을 전달한다. 반면, 결과는 **"이 문제를 해결해야 한다는 것은 알지만, 어떻게 해결하는지가 확실치 않다"**는 점을 강조한다. 솔직히 대부분의 제품 개발 상황에서 이게 현실에 더 가깝다.

그리고 결과로 관리한다는 것은 성공을 어떻게 측정해야 하는지가 명확해진다는 의미이기도 하다. 그렇다면 과연, 결과 주도가 정말 좋은 것인가?

세 가지 유형의 결과

결과 중심 관리는 결과 자체의 질에 따라 달라진다. 모든 결과가 같은 게 아니다. 세 가지 유형을 구분해야 한다.

비즈니스 결과 (Business Outcomes)

비즈니스 결과는 주로 재무적 지표다. 매출 증가, 비용 절감 같은 것들. 대부분 후행 지표라서 측정까지 시간이 걸린다. 앞서 본 90일 유지율이나 한 달 후 연장율이 여기에 해당한다.

제품 결과 (Product Outcomes)

제품 결과는 제품이 비즈니스를 전진시키는 정도를 나타낸다. 가장 중요한 특징은 프로덕트 트리오가 통제할 수 있는 범위 내에 있다는 점이다.

비즈니스 결과는 마케팅, 영업, 고객 지원 등 여러 부서의 협업이 필요하다. 다만 제품 결과는 제품 팀이 직접적으로 영향을 미칠 수 있다. tails.com 사례에서 "개들이 사료를 좋아하게 하는 것"이 바로 제품 결과다. 제품 자체의 만족도나 관련 지표를 의미한다.

트랙션 지표 (Traction Metrics)

트랙션 지표는 특정 기능이나 작업 흐름에 대한 사용량 측정이다. 결과보다 더 한정적인 범위를 가지며, 종종 제품 결과 대신 특정 기능 활용도를 최적화하는 데 사용된다.

예를 들어, "개들이 사료를 좋아하도록 하는 것" 대신 "전환 캘린더 사용량 증가"라는 트랙션 지표를 목표로 잡으면 어떻게 될까? 고객이 캘린더를 원하지 않더라도 팀은 다른 해결책을 모색할 자유가 없다. 트랙션 지표를 결과처럼 설정하면 사실상 산출물에 집착하는 셈이다.

그렇다고 트랙션 지표가 쓸모없다는 건 아니다. 주니어 팀에게 활용하거나, 성숙한 제품에서 이미 유용성이 입증된 기능을 최적화할 때는 트랙션 지표가 유용하다.

결과는 양방향 협상의 산물이다

팀의 결과 설정은 프로덕트 리더(C레벨, 팀/부서장)와 프로덕트 트리오 간의 양방향 협상이 되어야 한다. 한쪽에서 일방적으로 정하면 안 된다.

프로덕트 리더의 역할

프로덕트 리더는 조직 전반의 시각을 제공한다. 비즈니스 차원에서 지금 무엇이 가장 중요한지 전달하는 것이다.

다만 리더가 솔루션을 강제해서는 안 된다. 대신, 트리오가 집중할 적절한 제품 결과를 제안해야 한다. 이게 리더의 전략적 의도를 전달하는 좋은 방식이다. "개들이 사료를 더 좋아하게 만드는 것"처럼 제안하면, 팀은 그대로 집중하거나 비즈니스 전략적 필요에 따라 세그먼트를 좁힐 수 있다.

프로덕트 트리오의 역할

프로덕트 트리오는 고객과 기술에 대한 지식을 바탕으로 현실적인 제안을 해야 한다. 주어진 기간 안에 해당 지표를 얼마나 개선할 수 있는지 말이다. 이 시점에 어떤 솔루션을 만들지 결정할 필요는 없다.

세그먼트가 있다면 이전 히스토리를 파악해서 몇 퍼센트 목표를 달성할 수 있을지 제안한다. 비즈니스가 더 큰 임팩트를 요구할 경우 팀은 더 야심찬 전략을 세워야 하며, 리더는 이런 높은 목표가 더 큰 실패 가능성을 수반함을 이해해야 한다.

협상이 중요한 이유

프로덕트 팀에 필요한 것은 결과에 대한 전략 학습 시간과 안정적으로 집중하는 팀 구조다. 리더와 트리오가 협력해 결과를 설정하면 조직적 지식을 최대한 활용하는 동시에, 팀이 목표 설정에 참여하게 되어 주도성과 성과가 높아진다.

연구에 따르면 결과 설정에 참여한 팀이 그렇지 않은 팀보다 더 많은 주도성과 성과를 보인다고 한다.

SMART 목표가 필요한가?

SMART 목표는 많이들 알고 있을 것이다. Specific(구체적), Measurable(측정 가능), Achievable(달성 가능), Relevant/Realistic(현실적이고 관련된), Time-bound(기한이 있는)의 약자다. (참고)

연구에 따르면 구체적이고 도전적인 목표를 세운 팀은 그렇지 않은 팀보다 뛰어난 성과를 보인다. 도전적인 목표는 집중력을 강화하고, 노력과 지속성을 이끌어내며, 조직에 숨겨진 관련 지식을 이끌어낸다. 다만 전제 조건이 있다. 팀은 목표 달성 가능성을 믿어야 하고, 목표에 몰입해야 하며, 진척도를 지속적으로 피드백받아야 한다. 이는 팀이 결과 정의에 참여해야 하고, 목표는 측정 가능해야 한다는 점을 뒷받침한다.

SMART의 한계

그런데 SMART 목표의 효과성 연구 대부분이 단순한 과업에 기반하고 있다는 점이 문제다. 도전적인 목표는 팀이 이를 달성할 전략을 갖추지 못했을 때 오히려 성과를 떨어뜨릴 수 있다.

그래서 적절한 전략이 식별되기 전에는 성과 목표 대신 학습 목표를 설정하는 것이 더 효과적일 수 있다. 새로운 결과에 직면한 프로덕트 트리오라면 먼저 학습 목표부터 시작해야 한다는 점을 시사한다.

예를 들어, 성과 목표가 "참여율 10% 증가"라면, 학습 목표는 "참여를 높일 수 있는 기회를 발견하기"가 될 수 있다. 결과를 측정하는 최적의 방법을 모를 때 여기서부터 시작하면 된다.

결국 처음부터 완벽한 지표를 정의하려고 애쓰기보다, 우선 고객 이탈 원인을 파악하고 그 후에 결과 지표를 조정하는 접근이 더 효과적이다. 익숙한 결과 지표를 다룰 때 SMART는 여전히 유용하며, 상황에 따라 먼저 학습 목표를 설정한 후 SMART 성과 목표로 발전시켜 나가는 것도 좋은 방법이다.

프로덕트 트리오를 위한 가이드

프로덕트 트리오가 실제로 마주하는 상황은 다양하다. 아예 결과 없이 산출물만 전달하라는 요청을 받는 경우가 가장 흔하다. 프로덕트 리더가 팀의 의견 없이 결과를 정해주는 경우도 있고, 반대로 프로덕트 트리오가 리더 의견 없이 독자적으로 결과를 정하는 경우도 있다. 이상적으로는 프로덕트 리더와 트리오가 결과를 협상해야 한다.

상황별 대응 방법

산출물만 전달하라는 요청을 받는 경우

이 상황이 가장 흔하다. 프로덕트 리더가 새로운 솔루션을 지시할 때, 비즈니스 맥락에 대해 더 물어봐야 한다. "이 솔루션의 대상 고객은 누구인가?", "이 솔루션으로 달성하려는 비즈니스 결과는 무엇인가?", "왜 이 솔루션이 해당 결과를 이끌 것이라 생각하는가?" 다만 '왜'라는 질문은 리더에 따라 방어적으로 느낄 수 있으니 주의가 필요하다.

그리고 이 비즈니스 결과와 연결될 수 있는 제품 결과가 있는지 점검해야 한다. 해당 솔루션이 어떤 제품 결과를 개선하며, 그 제품 결과가 비즈니스 결과의 선행 지표로 작용하는지 확인해보자.

프로덕트 리더가 팀의 의견 없이 결과를 정해주는 경우

비즈니스 결과를 요구받았다면, 그 결과를 이끌어낼 수 있는 제품 결과를 제안하고 리더에게 피드백을 구하자. 제품 결과를 요구받았다면, 비즈니스 맥락을 더 물어보자. "우리가 이 제품 결과로 달성하려는 비즈니스 결과는 무엇인가요?"와 같이 묻는다. 양측이 합의된 기간 안에 어느 정도 성과를 낼 수 있을지 명확히 전달하는 것이 중요하다.

프로덕트 트리오가 리더 의견 없이 독자적으로 결과를 정하는 경우

결과를 정하기 전 프로덕트 리더에게 비즈니스 맥락을 더 물어봐야 한다. "지금 비즈니스에 가장 중요한 것은 무엇인가?" 이 대화를 비즈니스 결과 관점에서 진행해보자. "다른 고객 세그먼트보다 중요도가 높은 세그먼트가 있는가?", "우리가 알아야 할 전략적 이니셔티브가 있는가?"

이 정보를 토대로 가장 중요한 비즈니스 결과와 이를 뒷받침할 제품 결과를 매핑하고 리더의 피드백을 받는다. 그리고 팀이 가장 크게 기여할 수 있는 제품 결과를 선택한다.

체크리스트

스스로 점검해볼 항목들이다. 팀은 비즈니스 결과나 트랙션 지표가 아니라, 제품 결과를 받고 있는가? 트랙션 지표를 할당받았다면, 그 지표가 고객이 원하는 행동을 반영하는지, 이미 검증되었는지 확인하자. 새로운 지표를 처음 다루는 경우라면, 도전적인 성과 목표 전에 학습 목표를 먼저 설정하는 게 어떨까? 해당 지표에 대한 경험이 있다면, 구체적이고 도전적인 목표를 설정했는지 확인하자.

흔한 안티 패턴 피하기

결과 중심으로 일하려고 할 때 흔히 빠지는 함정들이 있다.

너무 많은 결과를 한 번에 추구하기. 한 번에 하나의 결과에 집중해야 한다. 여러 개를 동시에 쫓으면 어느 것도 제대로 달성하기 어렵다.

결과 사이를 핑퐁하듯 왔다갔다 하기. 하나의 결과에 장기간 집중해야 한다. 이번 주는 이거, 다음 주는 저거 하면 결국 아무것도 안 된다.

프로덕트 트리오가 아닌 개인별 결과 설정. 포지션별로 다른 목표를 주면 안 된다. 목표는 팀 단위로 설정해야 한다.

산출물을 결과로 설정하기. 의도는 결과인데 산출물을 결과로 착각하는 경우가 많다. 숫자로 표현한다고 해서 결과가 되는 게 아니다. 숫자 표현이 의무도 아니고, 숫자 표현이 무조건 참도 아니다. 예를 들어 "플랫폼상의 강좌 리뷰 수 증가"는 산출물에 가깝고, "리뷰가 포함된 강좌 조회 수 증가"가 더 결과에 가깝다.

한 가지 결과에만 집중하고 나머지를 무시하기. 웰스 파고 사례가 유명하다. 주 목표 외에 Health Metric 모니터링이 필요하다. 고객 획득에 집중한다면, 동시에 고객 만족도 지표를 감시해야 한다. 한 지표를 극단적으로 최적화하면 다른 곳에서 문제가 생긴다.

나가며

결과 중심 사고로 전환하는 건 단순히 KPI를 바꾸는 게 아니다. 팀에게 자율성과 책임을 부여하고, 리더와 팀이 함께 목표를 협상하는 문화를 만드는 것이다.

비즈니스 결과, 제품 결과, 트랙션 지표의 차이를 이해하고, 팀이 직접 영향을 미칠 수 있는 제품 결과에 집중하는 것. SMART 목표의 한계를 알고, 새로운 영역에서는 학습 목표부터 시작하는 것. 이런 작은 전환들이 모여서 진짜 결과 중심 조직이 된다.

Discovering Opportunities

다음 글에서는 기회를 발견하고 구조화하는 방법을 다룬다.

고객에 대해 현재 알고 있는 바를 시각화한 경험 지도(Experience Map)를 만든다 (4장). 경험 지도에 따라 고객 인터뷰를 진행하고, 각 인터뷰에서 얻은 통찰을 인터뷰 스냅샷(Interview Snapshot)에 기록한다 (5장). 발견한 기회들을 기회-솔루션 트리(Opportunity Solution Tree)에 구조화하고, 이 트리를 활용해 기회 공간을 평가하고 우선순위를 정한다 (6장, 7장).

2. Continuous Discovery를 위한 프레임워크 - Continuous Discovery Habits

Tony Cho (https://flowkater.io) — Sun, 02 Mar 2025 00:00:00 GMT

들어가며

프로덕트를 만들다 보면 비즈니스 요구사항과 고객 요구사항이 충돌하는 순간을 마주하게 된다. 둘 다 중요하다는 건 알지만, 막상 결정을 내려야 할 때 어느 쪽에 무게를 둬야 할지 애매할 때가 많다.

솔직히, 이 문제가 눈앞에 닥쳤을 때 정답을 찾기란 쉽지 않다. 나도 이전 회사에서 비즈니스 KPI와 사용자 경험 사이에서 갈등했던 적이 여러 번 있었다. 그래서 이 주제에 대해 체계적인 프레임워크가 있다면 어떨까 하는 생각을 계속 해왔다.

Teresa Torres의 Continuous Discovery Habits를 읽으면서 이 긴장 관계를 어떻게 해소할 수 있는지에 대한 프레임워크를 정리해보려고 한다. 특히 기회-솔루션 트리(OST)라는 개념이 인상적이었는데, 단순히 "고객 인터뷰를 하자"가 아니라 왜 하는지, 어떻게 구조화할지에 대한 체계적인 접근법을 제시하기 때문이다.

비즈니스와 고객, 둘 다 잡을 수 있을까

비즈니스 요구사항과 고객 요구사항이 충돌하는 대표적인 사례가 웰스파고 은행이다. 크로스 셀링(cross-selling)으로 유명했던 이 은행은 고객이 계좌를 하나만 개설해도, 은행원들이 그 고객에게 당좌 계좌, 예금 계좌에 이어 신용카드나 주택담보대출 상품까지 가입하도록 유도했다.

그런데 문제가 있었다. 달성 불가능한 수준의 목표를 직원들에게 제시하면서, 직원들은 결국 고객의 동의 없이 고객 명의로 계좌를 개설하거나 상품을 가입하는 불법 행위까지 저질렀다. 결과는? 벌금과 수십억 달러의 소송 비용.

'고객 1인당 평균 계좌 수를 늘린다'는 목표 자체는 바람직했다. 다만 결과에 집착하는 사고방식을 '고객 중심적 사고'와 결합하지 못한 것이 문제였다.

솔직히 이런 케이스는 생각보다 흔하다. 미디어 업계에서 시청 경험보다 광고 수익을 우선시하거나, 가격 투명성보다 단기적 매출을 우선시하는 경우를 우리는 자주 본다. 올바른 KPI가 과정에서 잘못된 KPI로 변질되는 것이다. (나도 예전에 비슷한 상황을 겪었다. DAU를 높이려고 푸시 알림을 남발했다가 오히려 앱 삭제율이 올라간 적이 있었는데, 지금 생각하면 얼굴이 화끈거린다.)

그렇다면 기업이 이윤을 추구하면서도 고객 서비스를 희생하지 않을 수 있을까? 피터 드러커는 기업의 목적을 "사회의 필요를 수익성 있는 비즈니스 기회로 전환하는 것"이라고 정의했다. 결국 기업의 목적이 고객을 섬기는 데 있다는 뜻이다. 비즈니스 요구와 고객 요구는 대립 구도가 아니라, 고객을 섬기는 과정을 통해 이윤을 창출하는 관계여야 한다. 아마존이 대표적인 사례가 아닐까 싶다.

끝을 염두에 두고 시작하라 (Begin With the End in Mind)

제품 개발 과정에서 산출물이 아닌 성과에 초점을 맞추는 사고방식으로 전환하는 것이 제품 성공의 기초다. 솔직히 이전 회사에서 이 부분을 놓쳤던 적이 많다. 기능 출시 자체에 매몰되어 '그래서 뭐가 좋아졌는데?'라는 질문을 던지지 못했다. 출시 후에야 "아, 이거 왜 만들었지?" 싶었던 기능들이 한둘이 아니다.

비즈니스가 팀에게 성과 목표를 제시하면, 팀은 창의적 자율성을 바탕으로 고객 가치를 창출할 여지를 갖게 된다.

다만 고객 가치를 당연시하거나 희생해서는 안 된다. 조직 문화와 방법론에 따라 팀은 고객 중심적 접근 혹은 지름길을 선택할 수 있기 때문이다. 어떤 길을 선택하느냐는 결국 조직이 어떤 가치를 우선시하느냐에 달려 있다.

성과를 이끌어내는 도전 (The Challenge of Driving Outcomes)

기존의 제품 트리오(PM, 디자이너, 엔지니어)는 산출물을 만들어내라는 요구만 받았을 뿐, 그러한 산출물이 어떤 영향을 미치는지에 대해 깊이 생각할 기회가 많지 않았다.

안타깝게도, 매주 고객과 대화하는 것만으로 이 문제가 해결되지는 않는다.

고객과 최소 주 1회 접점 (At a minimum, weekly touchpoints with customers) 제품을 개발하는 팀이 주도하여 (By the team building the product) 소규모 리서치 활동을 수행하며 (Where they conduct small research activities) 목표한 결과를 달성하기 위해 노력한다. (In pursuit of a desired outcome)

고객과 대화하는 데 능숙한 많은 팀들도 고객 접점의 목적이 '원하는 성과를 달성하기 위한 연구'라는 점을 종종 잊는다. 위 정의에서 마지막 두 줄이 핵심이다. 연구를 위한 연구가 아니라, 고객을 제대로 지원함으로써 비즈니스에 가치를 창출하기 위한 연구여야 한다.

비정형 문제와 프레이밍

원하는 성과로 가는 최적의 경로를 찾는 일은 비정형 문제(ill-structured problem) 또는 위키드 문제(wicked problem)라고 부른다. 비정형 문제는 가능한 해답이 매우 많으며, 정답이나 오답이 명확히 존재하지 않고 더 나은 해답과 덜 나은 해답만 존재한다.

이런 문제를 다루는 핵심은 문제 자체를 어떻게 정의(프레이밍)하느냐다. 어떻게 프레이밍하느냐에 따라 해결 방식이 크게 달라진다. 마치 같은 산을 오르더라도 어느 방향에서 출발하느냐에 따라 완전히 다른 등산 경험이 되는 것처럼, 문제를 어떻게 정의하느냐가 솔루션의 방향을 결정한다.

웰스파고 케이스를 다시 보자. "고객 계좌 수를 어떤 수단을 써서라도 늘린다"로 프레이밍하면 부정행위의 여지가 생긴다. 반면 "고객이 자발적으로 더 많은 계좌를 개설하고 싶도록 만든다"로 프레이밍하면 고객 중심 사고가 된다.

결국 제품 트리오가 비즈니스 가치를 창출하면서 고객 가치도 함께 창출하고자 한다면, 문제를 고객 중심적으로 프레이밍하는 노력이 필요하다. 고객 니즈, 고충(pain points), 욕구(desires)를 발견하고 이를 충족하는 방향으로 비즈니스 성과를 이끌어야 한다.

기회(Opportunities)란 무엇인가

여기서 "고객 니즈, 고충(pain points), 욕구(desires)"를 통칭하여 기회라고 부른다. 제품 세계에서 단순히 "해결해야 할 문제"만 존재하는 건 아니다. 문제는 무언가 고쳐야 할 것을 시사하지만, 제품이나 서비스 중에는 문제를 해결하기보다 고객의 욕구를 충족시키는 것도 많다. 디즈니랜드, 아이스크림, 산악자전거 같은 것들 말이다.

그래서 **기회 공간(opportunity space) = 문제 공간(problem space) + 욕구 공간(desire space)**으로 이해하면 된다.

원하는 성과를 달성하기 위해 제품 트리오는 이 기회 공간을 발견하고 탐색해야 한다. 문제는 기회 공간이 무한하다는 점이다. 전형적인 비정형 문제다. (말로는 쉬운데 실제로 해보면 어디서부터 손대야 할지 막막하다.)

팀이 이 기회 공간을 어떻게 정의하고 구조화하느냐가 비정형 문제를 다루는 방식이 된다. 앞서 말했듯이 문제 프레이밍이 중요하고, 어떻게 프레이밍하느냐가 해결 방식에 큰 영향을 미친다. 뛰어난 문제 해결사들은 단 한 가지 프레이밍에 고착되지 않고 다양한 프레이밍을 시도하며 그에 따른 솔루션 공간 변화를 탐색한다.

제품 트리오가 해야 할 두 가지

제품 트리오가 원하는 성과에 도달하기 위해 가장 중요한 두 가지 단계는 이것이다.

기회 공간을 어떻게 구조화하고 매핑할 것인가
그리고 어떤 기회를 선택하여 추구할 것인가

불행히도 많은 제품 트리오는 이 단계를 완전히 건너뛰고, 성과 목표를 설정하자마자 바로 아이디어를 내기 시작한다. 물론 결국 해결책으로 이어지고 코드를 배포해야 고객에게 가치를 전달하고 비즈니스 가치를 창출할 수 있다. 다만 올바른 문제 프레이밍을 통해 다양한 탐색 과정을 거친다면 더 나은 솔루션을 개발하고 제공할 수 있다.

디스커버리의 내재된 구조 (The Underlying Structure of Discovery)

디스커버리를 어떻게 진행하는지에 대한 내재된 구조가 있다. 먼저 명확한 성과(outcome)를 정의하는 것에서 시작한다. 성과가 디스커버리의 범위를 결정한다. 그다음 기회 공간을 발견하고 매핑한다. 이것이 원하는 성과에 이르는 비정형 문제를 구조화하는 과정이다. 기회 공간에 대한 적절한 문제 정의는 솔루션 공간을 열어준다. 마지막으로 이 기회들을 해결해 목표한 성과를 이끌어낼 수 있는 솔루션을 탐색한다.

이 구조를 시각화한 것이 바로 **기회 솔루션 트리(Opportunity Solution Tree, OST)**다.

트리의 맨 상단에는 우리가 달성하고자 하는 성과가 있다. 마치 산 정상처럼, 그곳에 도달하기 위한 여러 등산로(기회)가 그 아래 펼쳐지는 구조다. 이것이 트리의 뿌리이며, 팀이 비즈니스에 가치를 창출할 수 있는 방향을 반영한다. 그 아래는 기회 공간이다. 고객의 니즈, 고충, 욕구를 의미하며, 이를 충족하면 원하는 성과를 달성하는 데 도움이 된다. 그 아래는 솔루션 공간으로, 우리가 탐색하는 다양한 솔루션들을 시각적으로 표현한다. 가장 아래는 가설 검증 단계로, 어떤 솔루션이 고객 가치를 창출하면서 비즈니스 가치를 이끌어낼 수 있는지 평가한다.

OST의 7가지 효과

OST는 다음과 같은 효과를 제공한다.

비즈니스 니즈와 고객 니즈 사이의 긴장을 해소
원하는 성과에 도달하기 위한 공유된 이해(shared understanding) 형성 및 유지
지속적 사고방식 채택
더 나은 의사결정 촉진
더 빠른 학습 사이클 구현
다음에 무엇을 해야 할지에 대한 명확한 확신 확보
이해관계자 관리(stakeholder management) 단순화

각각을 좀 더 자세히 살펴보자.

비즈니스 니즈와 고객 니즈 사이의 긴장을 해소

비즈니스 가치 창출을 제일 위 우선순위(Outcome)로 두기 때문에, 시간이 지남에 따라 고객을 지원할 수 있도록 보장하는 핵심 요소가 된다. 그다음 팀은 비즈니스 성과를 견인할 수 있는 고객의 니즈, 고충, 욕구를 탐색해야 한다.

여기서 핵심은 성과를 낼 수 있는 기회들만 고려하면서 기회 공간을 필터링하는 것이다. 기회 공간을 매핑함으로써 팀은 고객 중심적 관점에서 어떻게 성과에 도달할 수 있을지 문제를 정의하게 된다. 우리 팀에서도 이 과정을 거치면서 "이 기능이 정말 고객 문제를 해결하나?"라는 질문을 더 자주 하게 됐다. 예전에는 경영진이 요청하면 일단 만들고 봤는데, 이제는 성과와 연결되지 않는 기능은 우선순위에서 밀리게 되었다.

결국 성과와 기회 공간이 제품 트리오가 고려할 수 있는 솔루션의 유형을 제한하고, 고객과 비즈니스 모두에게 가치를 창출할 수 있는 근거를 마련해준다.

원하는 성과에 도달하기 위한 공유된 이해 형성 및 유지

대부분의 사람들은 문제를 접하면 솔루션부터 떠올린다. 그리고 문제를 어떻게 정의했는지(프레이밍)를 의심하는 것을 잊어버린다. 처음 생각난 솔루션에 집착하고 "이 문제를 다른 방식으로 해결할 수 있나?"라는 질문을 하지 않게 된다. 팀으로 일할 때 이 문제가 더 복잡해지고, 쓸데없는 의견 싸움으로 확대되기도 한다. (본능이다. 나도 예외는 아니다.)

팀이 선택지를 시각화하는 데 시간을 들이면, 원하는 성과에 어떻게 도달할 수 있는지에 대한 공유된 이해가 생긴다. 결국 '보이게 만드는 것'이 핵심이다. 스토리 매핑 책에서도 강조하는 부분이다. 팀이 매주 배운 점을 바탕으로 이 시각화를 업데이트하면, 이 공유된 이해를 유지할 수 있다. 시간이 지나도 협업을 가능하게 하며, 협업은 제품 성공에 매우 중요하다.

OST는 제품 트리오가 지속적인 마인드셋을 채택하도록 돕는다

2주 스프린트로 나눈다고 해서 진정한 애자일이 되는 건 아니다. 지속적인 마인드셋은 매 스프린트마다 가치를 전달할 것을 요구한다. 그 가치는 충족되지 않은 니즈를 해결하고, 고충을 덜어주고, 욕구를 충족시킴으로써 창출된다.

트리가 아래로 내려갈수록 기회는 점점 더 작아진다. 그래서 팀 규모의 프로젝트급 기회를 작은 단위의 기회로 나누는 데 도움이 된다. 마치 레고 블록을 하나씩 쌓듯이, 작은 기회들을 하나씩 해결하면서 궁극적으로 더 큰 기회를 완성해나가는 것이다. 시간이 흐르면서 일련의 작은 기회들을 지속적으로 해결함으로써 궁극적으로는 더 큰 기회를 해결하게 된다. 대형 프로젝트 수준의 기회를 연속적인 작은 기회 해결을 통해 마스터하는 법을 배우게 되는 것이다.

더 나은 의사결정 촉진

칩 히스와 댄 히스의 "Decisive(후회 없음)"에서는 잘못된 결정을 초래하는 네 가지 요인을 제시한다.

첫째, 문제를 지나치게 협소하게 바라보는 것. 이것이 기회 공간을 다양한 방식으로 프레이밍(문제 정의)해야 하는 이유다.

둘째, 자신의 믿음을 확인해주는 증거만 찾는 확증편향. 편향을 극복하기 위한 여러 습관을 뒤에서 다룰 예정인데, 핵심은 찬성 의견뿐만 아니라 반증 증거도 고려하는 것이다.

셋째, 단기적 감정이 결정에 영향을 미치는 경우. 우리가 떠올린 아이디어에 매몰되는 걸 경계해야 한다.

넷째, 과신(지나친 자신감). 분명 크게 성공할 것이라는 과한 확신을 경계해야 한다.

이분법적 결정을 피하라

Decisive에서 제시하는 결정 극복 전술 중 하나는 "~할지 말지(whether or not)" 이분법적 결정 방식을 피하는 것이다.

"이 문제를 해결해야 할까, 말아야 할까?" 단일 고객 니즈나 고충을 접할 때 "지금 당장 모든 것을 멈추고 이 문제를 해결해야 하나?" 이해관계자가 특정 기능을 요구할 때 "지금 모든 걸 중단하고 이 기능을 만들어야 하나?"

이런 질문 대신 "비교, 대조" 사고방식으로 전환해야 한다. "이 고객 니즈를 해결해야 할까?" 대신 **"지금 우리가 해결해야 할 고객 니즈 중 무엇이 가장 중요할까?"**로 바꿔서 여러 옵션을 비교하고 대조하는 것이다. 첫 번째 아이디어에 집착하지 않고 "다른 해결책은 없을까?" 혹은 "이 기회를 다른 방식으로 해결할 수 없을까?"라고 질문한다.

OST를 시각화하면 이분법적 결정에 빠진 순간을 포착하고, 대신 비교 질문을 던지도록 유도할 수 있다.

자신감 과잉 경계

올바른 디스커버리를 했다고 해서 실패를 피할 수 있는 것은 아니다. 현재 알고 있는 것에 근거해 앞으로 나아가되, 틀릴 수도 있다는 점을 인정할 준비를 갖춰야 한다. 뒤 챕터의 습관들을 통해서 확신을 가지면서도 동시에 의심하는 태도를 균형 있게 유지하는 방법을 다룬다. 과감히 실행하면서도 위험한 길에 들어섰을 때 인지할 수 있도록 해준다.

분석 마비 문제

지나친 분석에 빠지는 것도 문제다. 분석 마비(analysis paralysis)에 빠지는 대신 빠른 결정을 내리고 그 결과를 재빨리 테스트하는 법을 배워야 한다. 분석하기보다는 적응하는 방식이 필요하다. (돌이켜보면 나도 완벽한 분석을 하겠다고 몇 주를 허비한 적이 있다. 그 시간에 작게라도 테스트했으면 훨씬 빨리 배웠을 텐데.)

기회 솔루션 트리(OST)에 각 의사결정 지점과 고려했던 선택지를 시각화하면, 필요할 때 과거의 결정을 다시 검토할 수 있으며, 방향 전환에 필요한 맥락 확보도 가능하다.

더 빠른 학습 사이클 구현

PM이 문제를 정의하고, 디자이너와 엔지니어가 솔루션을 정의하는 분업 구조? 그건 제대로 된 방식이 아니다.

잠재적 솔루션을 탐색하면서 문제에 대해 더 많이 알게 되고, 문제에 대해 더 많이 알게 되면 새로운 솔루션이 가능해지는 식으로 두 활동은 본질적으로 얽혀 있다. 문제 공간과 솔루션 공간은 함께 진화한다.

테스트를 통해 어떤 아이디어가 통하지 않는다는 것을 알게 되면, 단순히 다음 아이디어로 넘어가는 것이 아니라 다음과 같이 질문해야 한다. "현재 내가 이해한 고객 관점으로는 이 솔루션이 통할 것이라 생각했는데, 그렇지 않았다. 그렇다면 고객에 대해 무엇을 잘못 이해하고 있었나?"라고 자문하는 것이다. 새로운 솔루션 도출 이전에 기회 공간에 대한 이해를 재정립해야 한다.

이후 다루는 모든 내용, 습관과 방법은 제품 트리오가 함께 수행하도록 설계되어 있다. 조직 내 역할을 이유로 문제 공간과 솔루션 공간을 인위적으로 분리하는 일은 피해야 한다. 제품 트리오는 이 둘 모두에 책임을 가져야 한다.

OST에 기회 공간을 시각적으로 매핑해 두면, 이는 고객에 대한 이해를 명시적으로 드러내는 행위가 된다. 어떤 솔루션이 실패했을 때, 이 매핑을 다시 살펴보고 고객 이해를 재정립함으로써 더 빠르게 개선할 수 있다.

다음에 무엇을 해야 할지에 대한 명확한 확신 확보

기회 솔루션 트리의 형태가 디스커버리 작업을 안내하는 나침반 역할을 한다.

기회 공간의 깊이와 넓이는 팀이 목표 고객에 대해 얼마나 이해하고 있는지를 반영한다. 기회 공간이 너무 얕다면 더 많은 고객 인터뷰를 해야 한다는 신호다. 기회 공간이 너무 넓다면 초점을 좁혀야 한다는 뜻이다. 특정 기회에 대한 솔루션이 충분하지 않다면 아이디에이션 세션을 진행하고, 가설 검증이 부족하다면 테스트를 늘려야 한다.

명확한 성과 정의 -> 기회 공간을 매핑 -> 솔루션 고려 -> 가설 검증으로 솔루션 평가. 이것이 기본 흐름이다.

그런데 최고의 팀은 반대로도 작업한다. 가설 검증 결과를 활용해 솔루션을 평가하고 기회 공간을 진화시킨다. 기회 공간에 대해 더 많이 알게 될수록 원하는 성과 달성 방식, 즉 이 성과를 측정하는 최선의 방법에 대한 이해도 진화한다.

매주 인터뷰를 통해 기회 공간을 지속적으로 탐색하고, 목표로 삼은 기회에 대해서도 여러 솔루션을 고려하여 비교, 대조 의사결정을 진행한다. 솔루션 집합 전반에 걸쳐 가설 검증을 병렬적으로 수행하여 최적보다 못한 솔루션에 과도하게 매달리지 않는다. 이 전 과정을 기회 솔루션 트리에 시각화함으로써 다음에 무엇을 해야 할지 판단하는 데 도움이 된다.

이해관계자 관리 단순화

리더들이 산출물을 지시하던 옛 습관은 여전히 잔재로 남아 있다. 스트레스가 큰 시기에는 오래된 습관에 의존하기 쉽기 때문이다. 제품 트리오는 무엇을 만들지에 대한 근거 기반 결정을 하고, 이 결정 과정을 주요 이해관계자에게 납득시켜야 한다.

솔직히 대부분의 팀이 이걸 잘 못한다. 인터뷰 전체 녹음이나 방대한 메모를 그대로 공유하거나, 학습 내용을 공유하지 않고 결론만 강조하거나, 결론을 뒷받침하는 결과만 선택적으로 제공하는 경우가 많다.

잘 구성된 기회 솔루션 트리는 이 역할을 정확히 수행한다. 무엇을 학습했는지를 이해하기 쉽게 보여주고, 주요 의사결정 지점과 고려했던 선택지를 강조하며, 이해관계자가 건설적인 피드백을 줄 수 있도록 제시해야 한다.

OST를 사용해 먼저 원하는 성과를 상기시킨 뒤, 기회 공간을 통해 고객에 대해 알게 된 내용을 전달한다. 트리 구조를 통해 큰 그림을 쉽게 전달할 수 있으며, 필요할 때 세부사항에도 깊이 들어갈 수 있다. 고려하고 있는 솔루션과 이들을 평가하기 위해 실행 중인 테스트를 시각적으로 보여준다. 사고 과정과 학습 내용을 전달하여 이해관계자가 작업을 평가하고 추가 정보를 제공하는 데 도움이 된다.

나가며

Continuous Discovery는 단순히 "고객 인터뷰를 주 1회 하자"가 아니다. 비즈니스 성과와 고객 가치를 연결하고, 비정형 문제를 구조화하며, 팀의 의사결정을 개선하기 위한 체계적인 프레임워크다.

기회 솔루션 트리(OST)는 이 모든 것을 시각화하고 팀이 같은 방향을 바라보게 해주는 도구다. (말로는 쉬운데 실제로 그려보면 생각보다 어렵다.) 성과 -> 기회 -> 솔루션 -> 가설 검증의 흐름을 명확히 하고, 각 단계에서 무엇을 해야 할지 안내해준다.

다음 글에서는 성과(Outcomes)에 대해 더 깊이 다뤄보려고 한다. 산출물(Outputs)이 아닌 성과에 집중한다는 게 실제로 어떤 의미인지, 어떻게 적용할 수 있는지 살펴볼 예정이다.

이 프레임워크를 실제로 팀에 적용해보면서 느낀 점도 나중에 정리해봐야겠다. 이론과 실제 사이의 간극이 얼마나 클지, 지금은 알 수 없지만. 결국 중요한 건 완벽한 프레임워크가 아니라 꾸준히 적용하고 개선해나가는 것이다.

1. The What And Why Of Continuous Discovery 3. Focusing On Outcomes Over Outputs

지속적인 제품 발견의 습관 (Continuous Discovery Habits - Discover Products that Create Customer Value and Business Value) - 정리중 (WIP)

Tony Cho (https://flowkater.io) — Sat, 01 Mar 2025 00:00:00 GMT

Part 1 지속적인 제품 발견이란 무엇인가?

1. The What And Why Of Continuous Discovery

2. A Common Framework For Continuous Discovery

Part 2 지속적인 제품 발견

산출물 중심 사고방식에서 성과 중심 사고방식으로 전환하기 (3장)
기회 공간을 정의, 정제, 우선순위화하기 (4~7장)
목표에 맞는 솔루션을 만들어내고 평가하기 (8~10장)
제품 전달(Delivery) 단계에서도 업무의 영향을 측정하여, 전달 과정이 디스커버리를 뒷받침하게 만들기 (11장)
예기치 못한 학습이 발생하더라도 흐트러지지 않고 디스커버리 과정을 관리하고 유지하기 (12장)
디스커버리 과정을 이해관계자들에게 투명하게 보여주어, 전체 디스커버리 과정에 걸쳐 그들을 참여시키기 (13장)

3. Focusing On Outcomes Over Outputs

1. Continuous Discovery란 무엇이고 왜 필요한가 - Continuous Discovery Habits

Tony Cho (https://flowkater.io) — Sat, 01 Mar 2025 00:00:00 GMT

들어가며

프로덕트를 만드는 일을 하다 보면 자연스럽게 드는 질문이 있다. "우리가 제대로 된 것을 만들고 있는가?" 시간에 쫓기고 출시 일정에 매달리다 보면 정작 이 본질적인 질문은 뒤로 밀리기 마련이다.

나도 CTO로 일하면서 비슷한 경험을 많이 했다. 약속한 일정에 맞춰 기능을 출시하는 데 집중하다 보니, 정작 고객이 원하는 게 맞는지 확인하는 과정은 늘 후순위였다. 출시하고 나서야 "아, 이게 아니었구나"를 깨달을 때의 그 허탈함. 그래서 이 책(Continuous Discovery Habits)을 읽으면서 정리해두려고 한다.

Discovery와 Delivery

모든 제품 팀은 결국 두 가지 일을 한다. 무엇을 만들지 결정하는 것, 그리고 실제로 만들어내는 것. 전자를 Discovery(발견), 후자를 **Delivery(배송)**라고 부른다.

그런데 솔직히 대부분의 회사는 Delivery에만 집중한다. "약속한 시간과 예산에 맞춰 출시했나?"에 매몰되어 정작 "제대로 된 것을 만들었나?"는 질문을 잊어버린다. 이 책은 바로 이 불균형을 바로잡는 것을 목표로 한다.

한 가지 더 중요한 점이 있다. Discovery는 일회성 활동이 아니다. 디지털 제품은 절대 완성되지 않는다. 계속 진화할 수 있고, 진화해야 한다. 그래서 이 책에서는 팀이 새로운 제품을 발견하고 기존 제품을 반복적으로 개선할 수 있는 Continuous Discovery(지속적인 발견) 프레임워크를 소개한다.

제품 발견의 역사

Discovery가 어떻게 발전해왔는지 역사를 짚어보면 왜 지금 Continuous Discovery가 필요한지 더 잘 이해할 수 있다.

초창기: 비즈니스 리더가 결정하던 시대

소프트웨어 초창기에는 비즈니스 리더가 무엇을 만들지 결정했다. Discovery는 1년에 한 번, 연간 예산 프로세스에서 이루어졌다. 일정이 정해진 프로젝트가 특정 엔지니어링 팀에 할당되고, Product Manager는 작업과 예산, 일정만 관리했다. 때로는 비즈니스 요구사항을 제품 요구사항으로 전환하기도 했지만, 본질적으로 "결정"은 위에서 내려오는 것이었다.

문제는 뻔했다. 소프트웨어 개발은 예측 불가능해서 예산 초과, 기한 초과가 일상이었다. 비즈니스 요구사항이 고객의 요구사항보다 우선시되는 경우가 많았고, 제품을 출시한 후에야 고객이 만족하지 않는다는 사실을 인지하게 됐다. 엄청난 비용 낭비였다. 이런 유형의 팀을 **Delivery 팀(배달 팀)**이라고 부른다.

애자일 선언문 시대: 변화의 시작

애자일이 등장하면서 상황이 달라지기 시작했다. 애자일에서 강조하는 네 가지 원칙은 다음과 같다.

첫째, 짧은 주기와 빈번한 고객 피드백. 둘째, 지속적으로 유지할 수 있는 속도로 작업. 셋째, 고객 피드백에 빠르고 쉽게 적응할 수 있는 유연성 극대화. 넷째, 단순함 추구, 즉 극도로 최소한의 것만 개발하는 것이다.

스크럼과 칸반이 도입되고, UX와 유저 리서치를 통한 고객 피드백이 강조됐다. 그런데 여전히 문제가 있었다.

주기가 짧아지고 고객 피드백이 많아져도 원래의 아이디어를 고수하는 경우가 많았다. 예측 불가능한 작업을 여전히 예측하지 못했고, 스프린트가 오히려 지속적인 속도를 찾지 못하게 방해했다. 그리고 결정적으로, 제품 팀만 바뀐다고 되는 게 아니었다. 나머지 비즈니스가 바뀌지 않으면 유연성은 없는 것이나 마찬가지였다. 작동하지 않는다는 사실을 알게 되더라도 예산 범위 내에서 제시간에 맞춰 제공해야 했다.

사용성 테스트는 종종 프로세스 후반부에 너무 늦게 진행되어, 중요한 문제를 발견해도 이미 손쓰기엔 너무 늦은 경우가 많았다. 결국 팀은 계속 무엇을 제공했는지에 따라 평가받았다. 누가 사용했는지, 고객이나 비즈니스에 어떤 가치를 창출했는지 여부가 아니라.

그럼에도 불구하고 발전한 것들

그래도 애자일 덕분에 발전한 부분이 있다. 배포 주기가 단축됐고, 프로덕트를 더 잘 측정할 수 있게 됐다. 사용성 테스트를 더 잘하게 됐고, 작은 솔루션에서 큰 솔루션으로 반복하는 것도 잘하게 됐다.

다만 여전히 무엇을 만들지 결정하는 것은 어려웠다. 그래도 더 잘 측정하게 되면서 이 문제를 훨씬 더 심각하게 인식하게 됐다.

Discovery의 진화

결국 무엇을 만들지 결정하는 주체가 바뀌기 시작했다. 비즈니스 이해관계자에서 프로덕트 매니저로, 다시 프로덕트 매니저에서 제품 팀 전체로. Discovery 과정 전반에 걸쳐 고객을 참여시키게 됐다.

가장 큰 변화는 이것이다. Discovery가 끝날 때 아이디어를 검증하는 대신, 처음부터 고객과 공동 창작하기 시작한 것이다. Delivery Cycle이 짧아지면서 Discovery Cycle도 짧아졌다. 그렇게 Continuous Discovery가 등장했다.

이 책의 대상: 제품 트리오

이 책은 "PM, 디자이너, 개발자"로 구성된 제품 트리오를 대상으로 한다.

최소한의 Discovery를 위해서는 이 트리오가 필요하다. 물론 그 이상을 포함시킬 수도 있지만, 그에 따른 대가가 따른다. 속도가 느려지거나 의사결정의 균형이 깨지는 식으로.

필수 마인드셋 여섯 가지

많은 팀이 프레임워크, 도구, 방법론을 쫓는다. 새로운 혁신이 갑자기 제품 성공의 문을 열어줄 것이라고 기대하면서. 하지만 결국 이런 것들은 마인드셋이 동반되지 않으면 작동하지 않는다. 책에서는 여섯 가지 사고방식을 강조한다.

1. Outcome-oriented (결과 지향적)

결과물보다는 결과 중심으로 생각해야 한다. 이건 마인드셋이자 습관이어야 한다. 출시하는 솔루션으로 성공을 정의하기보다, 솔루션이 고객과 비즈니스에 창출하는 가치로 성공을 정의하는 것이다. 고객의 삶에 미친 영향, 비즈니스의 지속 가능성과 성장에 미친 영향 등 Impact로 성공을 측정해야 한다.

2. Customer-centric (고객 중심)

고객을 세상의 중심에 두는 것이다. 비즈니스의 목적은 고객을 창출하고 고객에게 서비스를 제공하는 것이다. 고객의 요구를 비즈니스 요구와 동등한 수준으로 끌어올려 고객 가치 창출에 집중해야 한다. 비즈니스 가치뿐만 아니라.

3. Collaborative (협업)

Digital Product의 Cross-functional한 특성을 이해해야 한다. 분업화되어 단계별로 결과물을 전달하는 사일로화된 모델을 거부해야 한다. PM이 결정하고 디자이너가 디자인하고 엔지니어가 코딩하는 방식 말고, 각자가 가진 전문성과 지식을 활용하면서 팀이 함께 의사 결정을 내리는 모델을 받아들여야 한다.

4. Visual (시각)

말과 글이 아닌 시각화가 필요하다. 이 책에 소개된 습관은 그림을 그리고, 생각을 외부화하며, 아는 것을 매핑하는 것이다. 공간적 추론 능력을 활용하는 습관을 가져야 한다.

5. Experimental (실험적 사고)

Discovery를 잘하려면 가정을 확인하고 증거를 수집하는 과학자처럼 사고하는 법을 배워야 한다. 내가 옳다고 증명하려 하지 말고, 내가 틀렸을 수 있음을 확인하려는 자세가 필요하다.

6. Continuous (지속성)

Discovery를 프로젝트 초반에 하는 일로 생각하지 않아야 한다. 개발 프로세스 전반에 걸쳐 지속적으로 Discovery 해야 한다. 구체적인 내용은 이후 챕터에서 다룬다.

Continuous Discovery의 정의

이미 많은 제품 팀에서 린 고객 개발을 위한 고객 인터뷰 기본 질문 5가지, 고객 인터뷰, 사용자 테스트, A/B 테스트를 채택하고 있다.

그러나 이런 Discovery 활동들을 체계적이고 지속 가능한 방식으로 채택하여 제품 결정에 지속적으로 반영하는 팀은 드물다.

그렇다면 단순히 Discovery가 아닌 Continuous Discovery란 무엇인가? 책에서는 다음과 같이 정의한다.

고객과 최소 주 1회 접점 (At a minimum, weekly touchpoints with customers) 제품을 개발하는 팀이 주도하여 (By the team building the product) 소규모 리서치 활동을 수행하며 (Where they conduct small research activities) 목표한 결과를 달성하기 위해 노력한다. (In pursuit of a desired outcome)

제품 팀은 매일 의사 결정을 내린다. 일상적인 의사 결정에서 최대한 많은 고객 의견을 반영하는 것이 Continuous Discovery다. 제품 팀이 한 달에 한 번만 고객과 소통한다면, 그 사이 한 달 동안의 의사결정은 고객의 의견 없이 이루어지게 되는 것이다.

나가며

이 글을 정리하면서 다시 한번 느꼈다. 우리는 너무 Delivery에만 집중하고 있었다는 것을. "제시간에 출시했나?"보다 "제대로 된 걸 만들었나?"가 더 중요한 질문인데, 현실에서는 전자에 치여 후자를 놓치기 쉽다.

특히 여섯 가지 마인드셋 중 결과 지향적(Outcome-oriented) 사고가 와닿았다. 기능을 출시하는 것 자체가 아니라, 그 기능이 고객과 비즈니스에 어떤 가치를 만들어냈는지로 성공을 측정해야 한다는 것. 말로는 쉽지만 실천하기는 정말 어렵다.

다음 글에서는 Continuous Discovery를 실제로 적용하기 위한 프레임워크를 다룬다.

2. A Common Framework For Continuous Discovery

팀에 Winning Mentality를 불어넣는 리더십 스킬

Tony Cho (https://flowkater.io) — Mon, 14 Oct 2024 09:01:00 GMT

토스 | SLASH 24 - 팀에 Winning Mentality를 불어넣는 리더십 스킬

정리

Leadership Goals
- One Team
- Winning Mentality
One Team
- '개인의 집합은 팀이 아니다'
- 공동 목표를 함께 이루어 변화를 만드는 관계
- 신뢰, 협력, 이해의 부족이 Blocker
- 신뢰의 출발, 감정 존중
  - 인간은 감정적 존재, 감정을 통제 가능한 변수로 보는 관점 가지기
  - 들어주기는 강력한 Tool
    - 충고/조언/평가/판단 않기
  - 감정을 말할 수 있는 1명이 안정감의 원천
  - 감정에 대한 대화
    - 질문을 하면 된다. 다만, 모드 체인지가 필요하다. 이성적(업무) 모드가 아니어야 한다. 감정에 대한 옳고 그름을 판단하지 말기
  - 신뢰받는 리더 되기
    - 이득을 리더가 먼저 챙기지 않기
    - 리더는 가장 많은 일을, 가장 오래하는 사람 - 어떤 일을 하는지 모를 수 있기 때문에 가장 일을 많이 한다고, 어떤 일을 하는지 알려줘야 한다.
    - 리더가 신뢰를 주는 것
      - "상대가 망치지 않는 것을 믿는 게 아니라, 망쳐도 믿는 것" (상대가 망쳐도 믿어주는 것) - 에드윈 캐트멀 Pixar
  - 멤버 간 신뢰 만들기
    - 강한 network : 연결을 늘리고, 대역폭(bandwidth)을 높이고
    - 의도적으로 네트워크를 만든다
    - 계기 / 연결 / 빠지기 - 내가 하고 있는 게 아니더라도 다른 사람이 봐주고 있는가
  - 신뢰하지 않아야 할 때
    - 실력은 항상 신뢰에 앞선다
    - 실력이 담보된 상태에서 신뢰를 주기
- 협력을 높이는 특성 Position
  - 환경이 변하면 강점과 약점(특성)은 달라질 수 있다.
- 이해를 높이는 Ground Rule 만들기
  - 서로 다름이 기본값
  - 불만과 갈등을 넘기지 않고 함께 불편해하기
    - 불만/갈등/불편을 공론화하고 문제화하면 그때부터는 그걸 풀면 된다.
  - -> 이걸 기반으로 Culture 를 도출할 수 있다.
Winning Mentality
- 팀 빌딩 자체가 목적이 될 수는 없다. -> 목적 달성을 위해 팀이 빌딩되는 것
- 결국 해내는 팀이 가진 특성
  - 자율적으로 목표를 찾고 초과 성과를 내는 과정을 반복
- 자율적으로 목표를 설정한다.
  - 목표 수립은 모두의 것
    - 계획 수립과 자기 주도적 행동
    - 자율성은 팀 만족도와 더 높은 성과 수준을 위한 필수 조건
    - 내가 확인한 문제라면 시작부터 몰입감을 가지고 인지하고 해결할 수 있다.
  - 자율의 원칙
    - 자율이 있고 없고의 문제가 아니다 여러 요소를 고려하여 결정
    - 자율은 목표가 아닌, 퍼포먼스의 수단으로 선택적 제공
  - Hidden 목표 이해하기
    - 개인에게는 (숨겨진) 삶의 목표가 있음
    - 팀 목표와 개인 목표가 상충될 수 있다.
    - 팀의 상황이 고려된 개인 목표가 수립될 수 있도록 코칭과 협의도 중요
- 초과 성과
  - 비지니스 목표 달성만이 아니다
  - 팀 존속에 필요한 모든 행위에서 압도적 결과가 나온 것
    - 헌신적 운영, 타 멤버의 서포트
- Winning Mentality 심기
  - 초과 성과자와 초과 성과의 배경과 방식을 공유
  - 타인의 행동을 모방 학습하게 만드는 겨울 뉴런을 자극하고 활성화 시키기
  - 성과자가 되는 것 자체가 달콤한 보상
성공을 이어가려면
- "변하지 않는 것은, 변한다는 사실 뿐"
- 기존의 성공 버리고, 유연하게, 새로운 변화로

느낀 점

기존 기능팀 구조가 비대해지면서 여러가지 고민을 하고 있는 시점인데, 해당 영상을 우연히 보게되어 정리를 해보았다. 단순히 팀웍이 좋은 팀보다 제목에서 말하는 Winning Mentality 를 갖추려면 어떻게 해야하는가 라는 궁금증으로 보게 되었는데, One Team 에 대한 부분에서는 내가 평소에 생각했던 내용들이 나와서 많이 공감을 했던 것 같다. Winning Mentality 는 결국 자율적으로 목표를 찾고 초과 성과를 내는 과정을 반복하는 것인데, 지금 조직에서 구성원들이 가장 어려운 부분이 자율적으로 목표를 찾는 부분일 것 같다. 영상에서도 무조건적인 자율이 아니라고 말하며 자율적으로 목표 수립하는 과정이 가장 어려운 과정이라고도 한다. 이 부분만 다시 정리하면,

목표 수립은 자율적으로 진행해야 하며, 이는 가장 어려운 과정이다.
모든 팀원들이 각자의 역할에 따른 문제를 식별하고 공유하는 것이 중요하며, 이는 문제를 해결하는 것보다 우선시되어야 한다.
문제를 직접 확인한 팀원은 문제 인식이 더 확고해지며, 이를 통해 해결책을 찾는 과정이 더 쉬워진다.
또한, 자율적으로 문제를 해결한다는 것은 오해의 소지가 있으며, 각자의 문제만 풀겠다는 태도는 바람직하지 않다.
문제가 발생하면 팀 내에서 얼라인을 맞추고 자율성을 발휘해야 한다.
하지만 환경과 상황에 따라 자율성은 제한적일 수 있으며, 특히 시급한 상황에서는 모든 사람이 자율성이 감소할 수 있다.
장기 프로젝트 진행 시 담당자는 자율적으로 문제를 찾아 해결하는 과정이 필수적이다.
개인의 목표 또한 중요하며, 각자의 라이프 사이클이나 성취하고자 하는 목표가 다르기 때문에 이를 정확하게 진단하고 이해해야 한다.
정기적인 대화를 통해 현재 가장 중요한 문제를 찾아내고 해결책을 모색하는 것이 필요하다.

자율적으로 본인들이 찾은 목표가 팀 내에서도 잘 얼라인 되어야하고, 상황에 따라 그게 다를 수도 있는데. 핵심은 본인들이 찾은 목표라고 느끼게끔 하는 것도 매니저나 리더십 레벨에서 해야되는 일이지 않을까 하는 생각이다. 일의 신속한 진행을 위해 솔루션을 정하긴 해야하지만, 이걸 같이 만들고 고민하고 스스로가 찾은 문제라고 느끼게 하는. 이번 영상의 아쉬움은 워낙 회사 비지니스, 상황마다 케바케이다 보니 조금 더 사례 중심으로 얘기를 듣고 싶긴한데, 그러한 부분이 빠져있어서 아쉬웠던 것 같다. 그래도 여러 부분 지금 고민하고 있는 부분과 맞닿아있는 부분이 있어서 도움이 되었다. 연사분께서 ML 파트 리드라서 엔지니어링 파트에만 국한되어 있긴 한데, 요소요소는 조금 더 조금 더 넒은 관점에 팀을 빌딩하는 관점에서 생각해볼 거리가 많은 것 같다. 그냥 단순히 팀에 책임을 불어넣고 일을 하는게 아니라 One Team 으로 Winning Mentality 를 갖추어나가는 것을 어떻게 하게 할 것인가 고민을 조금 더 깊게하는 계기가 된 것 같다.

피, 땀 그리고 서운함 (2024년 7, 8월)

Tony Cho (https://flowkater.io) — Sun, 01 Sep 2024 00:00:00 GMT

처음으로 법원을 방문했다. 지난번에는 영상 재판으로 진행하다 보니 로펌 사무실에서 줌 같은 프로그램으로 선고를 받고 끝났는데, 이번에는 직접 법원을 방문했다. 지난번보다 살이 좀 더 빠졌는지 급하게 구매했던 양복 재킷이 넉넉해졌다. 괜히 기분이 좋다.

약속된 시간 한 시간 전에 법원 앞 스타벅스에서 앉아 있다가 급하게 샌드위치를 하나 먹고 20분 전쯤에 나왔는데 초행길이라 그런지, 마음이 무거워서 그런지 5분 거리를 가는데도 초조함에 멀게만 느껴졌다. 법정 앞에서 안내를 받고 재판 일정을 보는데, 정말 많은 회사의 사건 일정들이 일정표에 나와 있었다.

5분에도 2, 3건씩 사건이 있는 일정을 보면서 그 모든 사람이 처음 시작할 때부터 지금, 이 순간까지 각자 어떤 시간을 보냈을지 감히 상상되지 않는다. 털어낸다는 홀가분함도 있겠지만 마냥 기분이 좋아 보이는 사람은 없어 보인다. 안내받은 대로 법정 중간에 앉았다. 내가 예상한 것보다 훨씬 큰 공간이었고, 미디어에서 보는 것처럼 판사 세 명이 앉아서 무미건조하게 변호사의 보고를 듣고 몇 가지 말을 던지는 게 다였다. 채권자들은 대부분 참석하지 않는 것 같다.

내 차례가 되어 드디어 앞으로 옮겨 앉았다. 파산관재인(변호사)이 보고서를 읽고 판사가 몇 가지 질문을 했는데 그에 따라 답변했고 (무슨 질문인지 정확히 기억이 안 난다.) 되게 짧은 시간 안에 끝났다. 준비한 시간에 비하면 정말 짧은 시간이었다. 경위서도 여러 번을 고쳐 썼기에 아무런 느낌이 없을 거라 생각했는데 막상 보고가 시작되니 마음이 힘들어진다.

그렇게 내 20대가, 치열했던 그 시기가 마무리되었다.

—-

"그래도 내일 모두 나와야 하지 않을까요” “…”

대답을 안 하기를 벌써 몇 번째인지 모르겠다. 이쯤 되면 상대방도 정말 짜증이 날 법하다. 내가 상대방이었으면 내 말 무시한다고 길길이 날뛰었을 것 같은데. 그렇게 몇 번의 전화를 했다가 끊기를 반복했다.

프로젝트 마무리를 앞두고 주말에도 열심히 각자 자리에서 대응 중인 팀원들이 있었고 나도 집에서 계속 회사 일을 보고 있었는데 모든 팀원이 주말에 나와서 일해야 한다는 얘기를 듣고 1시간을 넘게 실랑이를 벌였다. 내가 어디서부터 뭘 놓쳤기에 상황이 이렇게 되었는지에 대한 스스로에 대한 원망과 맥락 없는 요구를 감정적으로 하는 상대방에 대한 원망, 그리고 팀원들에게 이 상황을 얘기해야 하는 막막함, 그리고 그냥 모든 걸 내려놓고 도망가고 싶은 마음이 동시에 내 머릿속을 괴롭혔다.

감사하게도 다음 날 거의 모든 인원이 나와주었다. 하지만, 이 과정에서 나에게도 아물지 않는 큰 생채기가 생겼다. 이 한번 만의 사건 때문은 아니다. 쌓이고 쌓였던 것이리라. 프로젝트가 마무리된 지금 이 시점에 그 부분이 계속 나를 괴롭게 한다. 감정을 드러내는 걸 서슴지 않을 정도로 바닥을 찍었고 그 과정에서 결국 스스로에 대한 후회만 가득하다. 내가 느낀 무력감이 결국은 내가 여기서 할 수 있는 한계를 미리 압축해서 보여준 걸까. 남 탓을 하지 않는다. 그 모든 걸 내 숙제로 내가 헤쳐 나가야 하는 문제로 온전히 받아들이려고 한다. 도망쳐봐야 더 괴로워질걸 나는 그간의 짧은 경험을 통해서 잘 알고 있다. 그래서 아직 마음이 힘든 건 어쩔 수 없나보다.

인생은 블랙 코미디와 같아서 나는 블랙 코미디를 좋아한다. 그리고 군상극을 좋아한다. 한 명의 주인공이 아닌 모두가 주인공이기도 하고 모두가 주인공이 아니기도 한 그런 이야기를. 모두가 열심히 하려고 해서, 모두가 실수해서, 모두가 각자의 입장이 있기 때문에 이 블랙 코미디에는 빌런이 없다. 인생에서 일어나는 일 모든 게 다 회색 지대다. 우리는 그걸 구분하고 단순화하고 선명하게 하고 싶지만, 그저 흐릿한 일의 연속이라 때론 뭐가 맞고 뭐가 틀리는지도 모르겠는 일의 연속이다.

꾹 참고 군 생활을 버티며 드디어 전역이라는 빛(끝)을 보지만, 그건 그저 앞에 놓인 거대한 인생에서 시작에 불과하다. 전역하면 그저 경제력 없는 대학생인 것이다. 그래서 그 어느 순간, 어느 시간이라도 삶을 그저 참고 버티지만 말아야 한다. 그 순간을 어떻게 보낼지, 그 순간의 일, 그 순간에 만나는 사람들과 어떻게 충실하게 보낼지 고민해야 한다.

프로젝트 마무리를 하고 (마음속으로는) 해피엔딩을 바랐지만 결국 시간은 무자비하게 흘러간다. 인간이 정해놓은 어떤 얄팍한 시기 따위 시간은 알 바 아니다. 그저 흘러갈 뿐이다. 그리고 맞이해야 하는 어려움이 또 금방 닥쳐온다. 외면하고 있던 어른들의 사정이 있을 뿐. 심지어는 그냥 프로젝트로 정신없던 시기로 돌아가고 싶은 마음도 있다. 어려운 일을 버텨내면 쉬워지는 게 아니라 더 어려운 일이 다가올 뿐이다. 도망가고 싶은 마음이 하루에 열두 번도 더 들고, 닥쳐올 어려움이 현실화가 되니 그걸 핑계로 더욱더 도망가고 싶다.

아직은 도망가지 않은(언제가 될지 모르겠지만) 내 자신에 대한 리스펙으로 어느 순간 대담한 결정을 했던 과거의 나를 부러워했듯, 미래의 나가 지금의 나를 부러워할 만한 모습이었음 한다.

—-

”일은 좋아해요?“ ”글쎄요, 사람들은 좋아해요.“

”그럼, 일은요?“ “.. (중략) .. 문제들 터지는 것도 싫고요. 오븐이 고장 난다거나 하수관이 막힌다거나 배송 업체에서 양파를 깜빡하는 그런거요. 그렇긴 하지만, 사람들은 좋아해요.”

더 베어 시즌3 중

내 사업을 할 때도 그랬고, 현재 팀에서도 그렇고 리더로 팀을 운영하면서 팀원들에게 드는 내 감정은 감사함과 존경, 책임감 그리고 그 뒤에 서운함이 있다. 고독한 길을 가는 것에 대한 내 선택에 대해 자기 연민을 가지고 있지는 않지만, 가끔은 그러한 내 마음을 알아주길 바라주는 욕심이 일어난다. 커리어에서 단 한 번도 누군가에게 따뜻한 조언이나 충고를 받은 적도 없고 좋은 멘토를 만나본 적 없는 외로운 길이라 그걸 내가 줌으로써 충족하려고 했던 것도 같다. 어른(?)들은 나를 금쪽이로 여겼고 한때는 나도 그들을 우습게 여겼다.

그 와중에 내 사람, 내 팀, 내 책임이라는 것에 스스로 얼마나 동기부여가 되고 있는지를 항상 발견했었던 것 같다. 아래 사람에게 기대하지 않는 쿨한 윗사람이 되고 싶은데 결국 스스로 선을 그어보아도 한없이 서운해지고 외로워지는 자신의 못난 성격 탓에 그 모든 결정에도 불구하고 내가 리더십으로는 재능이 없는 사람인 것 같다는 자기 의심으로도 이어진다.

아무도 나를 미워하지 않았으면 하고 존중해줬으면 하고 내가 하는 일과 결정에 대한 의도를 힘들게 설명하지 않아도 이해해 줬으면 하는 그런 게으른 마음도 동시에 든다. 1대1이 힘들어지는 사람 수가 되었다. 당연히 모두와 친구가 되는 건 말도 안 되고. 하지만 한 명 이상의 친구가 있었음은 한다. 여기에서 인연으로 끝나는 사람이 아닌 사람들이 있었으면 한다. 그런 욕심이 든다.

이 어려운 길에서 결국 내 솔직한 동기부여는 결국 사람들이다. 제품도, 고객도, 비지니스도 모두 중요하지만 지금 내가 이걸 버티고 있는 건 같이하고 있는 사람들이다. 때론 혼자 그냥 토라져서 시니컬해지고 사람들이고 뭐고 다 싫고 내 생각만 하고 싶을 때가 많다. 참 못난 나 자신이다.

—-

프로젝트가 끝나면, 멋진 회고가 담긴 글을 써보려 했다. 7월이 지난 8월 초에만 해도 그런 마음이었다. 아무리 힘들어도 그 순간을 상상하며 마무리를 한번 제대로 해보자, 라는 마음으로 달려왔는데. 이상한 내용의 일기를 쓰게 되었다.

회고보다 현재의 생각과 두 달 사이에 있었던 단상들로 정리해 보려 했다. 무슨 일이 있었고 뭘 더 잘해야 하고 뭐가 아쉬웠고 매번 액션 아이템을 뽑아내는 사람들이 대단하다. 부럽다. 난 감상에 쉽게 젖는 사람이라 바로 그렇게 모드 전환이 쉽지는 않은가 보다. 난 기억력이 정말 좋은 사람이고 내 얘기 하는 거 정말 좋아하는 사람이지만, 정말 힘든 일은 가끔 묻어놓고 몇 년 동안 얘기하지도, 추억 삼아 꺼내지도 않는 사람이라 나 자신도 잊어버릴까, 장면들과 생각들을 기록해 놓는다. 그냥 이 글은 회고라기 보다는 자기 위로에 가깝다.

액션 아이템은 당연히 있다. 그 어떠한 상황에도 내 삶의 중요한 것과 내가 좋아하는 것을 절대 포기하지 말고, 사람들에게 상처받고 서운해하더라도 여전히 기대하고 그 마음을 포기하지 말자. 내 감정이 바닥을 찍더라도 너무 감정대로 행동하지 않고 (그러면 항상 후회하니까) 항상 사람들에게 상냥하고 친절하게 대하도록 노력하자.

그리고 당연히 ‘뭘 더 어떻게 내가 잘해야 하나 정말 내가 할 수 있는 부분이 있나’ 싶은 생각도 있다. 그런 부분이 불쑥불쑥 엄습해 오면서 힘들어진다고 해도 겉으로는 그래도 괜찮은 척이라도 하려고 한다. (음 이게 액션 아이템이군.)

누군가는 노력해서 여기까지 왔겠지만, 나도 뭐 노력을 안했다라기보단 조금 얼떨결에 여기까지 온 것도 같다. 그리고 이렇게 팀원들과 같이하는 순간들이 꿈만 같아서 지금, 이 순간이 좋아서 그리고 그 순간이 이어져서 여기까지 온 것이다. (팀을 모아서 잃었던 경험을 한 사람의 조바심이기도 하다.) 당장 또 닥쳐올 일들에 마음이 무겁지만 삶은 또 계속된다. 사실 모든 게 시간이 지난다고 다 추억이 된다고 생각하지 않는다. 상처도 남고 후회도 남고 생각조차 하기 싫은 시간도 있는 법이다. 그래서 이 모든 상황과 어려움에도 일단은 최선을 다해보겠다.

6월부터 파산 절차를 진행했고, 길고 길었던 내 첫 회사를 마무리했다. (지나고보니 10년이다.) 새로운 시작을 위해 잘 마무리하는 것이 중요했고, 앞으로 나아가기 위해서 그 바쁜 와중에도 시간을 쪼개서 준비했다. ”결국 다시 하실거잖아요?“ 라고 했던 변호사의 말이 계속 머릿속을 맴돈다. 음, 그런가? 솔직히 지금은 좀 자신이 없다. 빨간약을 먹어버린 것이다. 그 사이 낭만도 죽고 현실주의자가 되었으며 겁도 많이 생겼다. 월급이라는 마약은 정말 중독적이다. 그래도 그 불씨가 아예 꺼지지는 않았다고 믿고 있다. 완전히 파산 종결이 되고 나서 투데잇에서 있었던 잊고자 해도 잊을 수 없던 일들도 기록으로 남겨보려고 한다. (언젠가는)

주절주절 칭얼칭얼 말이 너무 길었다.

감상에 그만 젖고 이제 다시 Let’s hit it.

시카고까지 170km야, There's 106 miles to Chicago, 기름은 만땅이고, we've got a full tank of gas, 담배도 반 갑 남았지, half a pack of cigarettes, 날은 저물었고, 우린 선글라스를 썼지.it's dark out, and we're wearing sunglasses.

가보자고. hit it.

블루스 브라더스 중

이전 회고
- 2024년 6월 회고
다음 회고
- 지난 7개월의 기록 - 생각의 나열 (2024년 9월~2025년 3월 기록)

2024년 6월 회고

Tony Cho (https://flowkater.io) — Mon, 01 Jul 2024 00:00:00 GMT

들어가며

4월, 5월이 제일 바쁜 줄 알았다.. 6월은 정말 미친듯한 스케줄이었다. 특히 8월까지 목표로 개발 중이던 프로젝트를 6월 중순에 새로운 사업이 치고 들어오면서 실행가능한 버전으로 런칭을 했어야했고, 해당 사업이 진행 시간이 평일, 주말 할 것 없이 이어져서 제대로 쉬는 날 없이 2,3주를 일했다. 이해관계자도 여럿 엮여있고 대내외적으로 파악하고 신경써야할 것이 많은 프로젝트다 보니 위에서는 위에 나름대로 엄청난 스트레스로 실시간 푸시가 이어졌고 그 푸시를 어떻게든 잘 정리해서 전달하려고 했으나 결국 흘러들어갈 수 없는 스트레스를 밑에서는 감당하면서 하루하루 고비를 넘기고 있다. 이걸 쓰고 있는 지금도 현재 진행중. 밥먹을때 더 베어 시즌 1 7화 '리뷰'편을 자주 시청하는데 20분의 숨가쁜 주방 상황과 카르멘의 빡침을 숨죽여지켜보고 있자면 이상하리만큼 힐링이 된다. 이 모든 바쁜 일이 좀 정리가 되면 팀원들이랑 다같이 이 편을 한번 시청하려고 한다. 그때 우리가 이랬다고.

회사

신규 멤버 3인

플랫폼 디자이너, 프로덕트 디자이너, 프론트엔드 개발자. 이렇게 세 분이 새로 들어오셨다. 얼마만에 오신 뉴페이스 분들인지. 세 분다 경력이 꽤 있으신 분들이고 실력도 좋으신 분들이라서 워낙 바쁜 회사 상황을 이해하고 빠르게 일에 적응하셨고 인원이 많아져서 신규 인력들이 나랑 스킨십이 현저히 적어졌었는데 다들 센스도 좋고 여유가 있어서 그런지 나랑도 커뮤니케이션이 짧은 시간에 많이 있었다. 2주도 안되어서 나를 놀리기도 하고.

내가 도메인 기획 구조 스케치를 날림으로 올린 걸 보고 이렇게 코멘트를 주셨는데, 이건 분명 날 놀리는 거다. 한 분은 2년 반만에 우리 팀에서 일하셨던 분이 돌아오셨는데 중간에도 계속 연락을 하고 지냈지만 이렇게 다시 돌아와서 한 팀에서 다시 일하게 되어 너무 좋았다. 다들 각자 캐릭터와 장점을 가지고 간만에 팀에 새롭고 아주 긍정적인 에너지를 불어넣어주고 있어서 나도 자극이 많이 된다.

채용을 위한 활동

난데없이 교과서 만들고 있는 CTO와 떠들어 봤습니다ㅣ떠든사람 조재우 CTO 1부 위 영상을 녹화했었는데, 이번에 편집이 되어서 사내 채용 유튜브에 업로드가 되었다. 안그래도 바쁜 와중에 인터뷰 질문에 미리 답변을 짜내느라 고생 좀 했는데, 해당 내용은 2부에서 볼 수 있을 것 같다. 딱히 추가적인 코멘트는 없다. 부끄럽고 민망하지만, 팀을 위해서는 언제든지 이런 활동도 마다하지 않겠다 뭐 그런 스탠스.

신규 사업

현재 8월을 향해 가고 있는 프로젝트에서 갑자기 6월 중순에 해당 프로젝트를 런칭하여 교육 연수 사업을 진행해야한다고 5월 말 6월 초에 통보(..)를 받고 어떻게든 그 일정을 맞추려고 내부 실무자들과 Align 하고 우선순위를 조정해가면서 안되는 일정을 되게 만드느라 고생을 했다. 6월 마지막 예정되어있던 폭풍같은 주말 일정도 지나갔고, 당시 통보받던 입장에선 쉽지 않아보였던 일정이 한달이 그렇게 지나면서 잘 마무리가 되었다. 급하게 일정이 치고 들어가면서 운영 단과 서로 이해하는 요구사항 범위가 달랐고 이미 서로 각자가 가고 있는 스케줄에서 해당 일이 제일 중요한 우선순위로 치고 들어오면서 서로 기존도 챙겨야하고 해당 건도 챙겨야하는 어려운 상황이 되었다. 그리고 이 과정에서 정리되지 않고 급하게 급하게 요구사항이 변경되어서 들어오고 그것마저도 확정 상태가 아니라 금방 변경 사항이 생기고 또한 그 상황에서 이 일이 정말 중요한 사업이기 때문에 이렇게 일하는 방법 마저 모두 포용이 되고 이해가 되어야하는 그런 분위기가 지속되었는데, 어차피 모두 내가 감당해야할 몫이라고 생각하고 여기서는 말을 줄이겠다. 그래도 어쨋든 우리 팀은 해냈다. 다른 문제는 차차 고민해보자.

F형 리더십

(이렇게 금요일 퇴근 길에 적어놓고 주말 내내 운영 대응하느라 바빴던 건 안비밀이다.) 운영 단에서 어떠한 요구사항이 급한건 결국 고객 단과 가장 맞닿아 있기 때문이라고 생각한다. 이미 그들끼리는 이게 반복적으로 나온 문제이고 그걸 어떻게 해소할 수 있을지 나름 고민도 해놓았을 수도 있다. 하지만 우리 조직처럼 운영과 제품 팀이 분리된 구조를 가지고 있는 조직의 구조적 한계 특성상, 제품 팀에서는 이러한 니즈를 쉽게 알수가 없다. 그러다보니 운영에서 그들 나름대로 솔루션이라고 던져주는 것들이 맥락도 이해가 안될 뿐더러 공감도 안되는 상황에서 무조건 해야한다고 고집을 피우는 꼴이 된다. 하지만 그래도 내가 최전선에서 운영쪽 니즈를 최대한 이해하고 이걸 실현하기 위해서는 다시 맥락을 살펴보고 우리 팀에 전달하는 역할을 해야한다고 항상 생각한다. 그 과정이 항상 쉽지는 않다. 하지만 팀원들이 초등학생이 아니기 때문에 모두 프로페셔널이라고 믿고 있기 때문에 결국 방법과 솔루션 보다는, 고객이 겪고 있는 상황, 맥락과 문제를 통한 동기부여가 항상 중요하다고 생각한다. 결국 이번 프로젝트를 일정 내에 완수하면서 우리 팀은 그렇게 하면 정말 잘 움직일 수 있다고 생각한다. 원 팀. 원 마인드셋. 급한 상황일수록 이런 공유는 어렵다. 그냥 Top Down으로 일을 밀어넣는게 더 쉬울때가 많다. 그래도 노력해야한다고 생각한다. 진심으로 팀원들을 존중하고 그들의 의견을 듣고 같이 할 수 있는 것을 해야한다고 생각한다. 내 감성과 낭만이 누군가에게 가소로워보일지라도 나란 사람이 그렇기에 내가 생각한 방향에서 팀을 위한 최선의 방향으로 항상 행동하겠다.

개인

운동

지난 달에 예고했듯이 자랑 좀 하려고 한다. 내 인생 최고 몸무게에서 25kg 이 차이가 난다. 내가 자랑하는 건 이 미친듯이 바쁜 하루하루에도 출근 전 아침 운동을 꾸준히 갔고 주에 최소 4회는 운동을 하려고 했던 것 같다. 간헐적 단식을 계속 이어서 해왔고 그 덕분에 몸이 많이 좋아지고 있다. 다음은 내 인바디이다.

인바디는 숫자에 불과해서 크게 신경쓰지 않지만 골격근량을 유지하면서 3개월만에 체지방을 10kg 넘게 뺐다는 것이 관건이다. 눈바디로 봐도 좋아진게 많이 느껴진다. 그리고 근육량이 떨어지지 않는다는 걸 느끼는게, 운동을 할때 중량과 힘이 늘었으면 늘었지 떨어지지 않았다는 것이다. 간헐적 단식을 하면 근손실 난다고 들었던 시절이 있었는데 오히려 지방을 쓰는 몸으로 체질이 변화되면서 단식 및 공복 상태에서 운동을 해도 퍼포먼스가 그렇게 떨어진다고 느껴지지 않았다. 특히 몸이 가벼워지면서 스트랩을 차고 풀업 20개가 한번에 당겨지면서 몸이 그냥 다이어트가 되는게 아니라 힘도 에너지도 아주 좋아졌다는 것을 느끼고 있다. 성과도 너무 좋았지만 이렇게 바쁜 와중에 잠을 줄여가며 운동한 보람이 느껴지는 한달이었다. 아직 목표 체중까지는 좀 남아서 지금 폼을 유지하면서 계속 건강하게 운동하고 다이어트 하는 것이 목표이다. 제일 바쁜 기간에 달성한 목표라 이제 왠만한 상황에서 운동할 시간이 없다는 핑계를 대기 힘들어졌다 ^^; 그리고 내가 운동을 하라고 주위에 강요하고 다니는 사람이 절대 아닌데, 다들 내게 영향을 받고 간헐적 단식을 해본다거나 헬스를 다닌다거나 긍정적인 영향을 드린 것 같아서 뿌듯함이 있다. 열심히 하는데 변화가 또 보이니까 그게 설득력이 있었던 것 같다. 그런 프레임이 또 만들어지니 내가 게을러도 운동을 하게되는 것도 있고.

개인 시간

독서를 많이 못했고, 지난 달과 같이 코딩은 손도 못댔다. 난 이제 정말 개발자가 아니라 PM인가? ㅋㅋ 뭐든 어떠랴 지금 가장 중요한 일을 내가 하고 있다는 것이 중요하다. 그리고 개인적으로 처리해야하는 아주 중요한 업무가 현재 눈앞에 있어서 이걸 잘 마무리하고 나면 사이드 프로젝트든 뭐든 코딩을 할 수 있을 것 같다. (아, 사이드 프로젝트를 하는 팀원에게 나도 코딩 합니다로 어필 좀 했는데 대차게 까였다. 고문 같은거로나 참여하란다. 내가 제일 싫어하는게 입개발과 훈수인데. 훈수나 두라니. 좌절스럽다. 코딩 자존감이 낮아있다보니 상처가 꽤 깊다(..) 다시 시간 내서 코딩을 열심히 해서 복수할 것이다(..))

나가며

5월의 나: ”그렇지만 어쩌겠습니까. 해내야죠.“ ??: 와 근데 정말 어렵긴 해요

정말 열심히 지낸 6월이다. 타의든 자의든. 시간이 어떻게 가는지 모르고 개인 일에도 치이고 회사 일에도 치이고 정신없는 한 해의 반년이 다 지나갔다. 오늘부터 하반기 시작이라니.. 돌아보면 막상 그렇게 시간이 빠른 건 아니었다. 너무 많은 일과 사건들이 있었고 그 순간 순간 와 어쩌지 하는 아찔한 순간도 꽤 많았던 것 같다. 더 베어 시즌2는 살인적인 스케줄로 식당을 개업하는 스토리다. 요즈음 이 드라마를 다시금 꺼내서 자주 보는 건 괜히 그 상황이 공감되고 스트레스풀한 상황에서 한발자국 나가는 그들을 보면서 왠지 모르게 짠하고 또 그걸 통해 힐링이 되기도 한다. 혼자 성장은 어렵다. 그런데 다같이 성장하는 것도 어떤 면에서는 더 어렵다. 내가 마음을 열고 팀원들을 존중해도 누군가는 냉소적으로 나를 판단한다. 난 최선을 다해 이 상황을 해결하고 있는데 다른 사람은 항상 아쉽다고 생각할 수도 있다. 그래도 내가 지켜야할 것을 잃지 말고 냉소적인 팀원들에게도 내 애정을 아끼지 말고 다른 사람에게 아쉬운 마음을 받아도 인정하고 항상 더 최선을 다하고자 한다. 그게 지금 이 자리에서 내가 할 수 있는 것이니까. 하반기의 마지막은 무언가가 마무리되고 결과가 나고 정리가 날 것이다. 지금 하는 일이든, 뭐든. 그 어느 순간에

아, 그때 참 정신없었는데.

하고 지금 이 순간을 추억하길 바라며, 6월 회고를 마무리 한다.

Try

침착하게 해야할 것을 하나씩 해나가기
조직 동기부여, 업무 파이프라인 개선 포기하지 않기
꺾여도 계속가는 마음
운동 지금처럼 계속
낭만 잃지 말고 영광의 순간을 위해

이전 회고
- 2024년 5월 회고
다음 회고
- 피, 땀 그리고 서운함 (2024년 7, 8월)

2024년 5월 회고

Tony Cho (https://flowkater.io) — Sat, 01 Jun 2024 00:00:00 GMT

들어가며

4월의 바이브(?)와 딱히 크게 달라진 건 없다. 계획을 짰다하면 예기치 못한 외부 일이 치고 들어오고 예측되지 못한 일을 맨파워로 컨트롤해가며 하루하루 바삐 보냈다. 그 와중에 아침 운동, 주말 운동을 계속 하면서 루틴을 유지하고 간헐적 단식을 하면서 식단을 컨트롤하면서 정신이 없다는 핑계로 멘탈과 건강이 망가지지 않게 애썼다. 3월부터 이어져오는 나의 어떤 정신적 맥락이 이어지고 있는데 조금 끝났나 싶으면 이제부터 시작이다 하는 느낌으로 계속 하루하루 일을 해나가고 있다.

회사

외부 일정

세종시를 다녀오는 날도 있었고 학교 현장에서 실제로 우리 솔루션이 도입되는 현장을 보기 위해 전북 정읍에 있는 초등학교도 방문을 했다. 4월에 했던 곳과는 또 다른 출판사와의 하루짜리 워크숍도 있었고. 회사 내에서 너무 정신이 없는 하루하루를 보내다보니 외부 일정 자체를 소화하면서 오히려 약간 숨을 쉬는 시간이라고 생각하고 다녀왔다. 특히 초등학교 방문은 좋은 경험이었고, 선생님과 아이들이 실제 솔루션을 쓰면서 실시간으로 오는 피드백을 현장에서 바로 느끼니, 어떤 부분에서 아하 모먼트를 주고 어떤 부분에서 어려움을 주는지 훨씬 더 와닿게 느끼게 되었다. “그 회사는 직원을 설레게 한다”에서 고객과의 접점을 직접 만들어내는게 직원들의 동기부여를 가장 효과적으로 만드는 부분인데, 내부에 고객의 현장 상황을 최대한 전달한다고 전달했지만 앞으로 더 어떻게 이런걸 전할 수 있을지, 아니면 고객과의 접점을 메이커들과 계속 만들어갈지 고민이 필요한 부분이라고 생각한다. 별도로 외부 일정을 다녀오면서 이동시간이 길다보니 동행한 팀원들이랑 대화하는 시간이 많았는데 평소에 나누지 못한 대화도 많이 하게되어 개인적으로 좋은 시간이었다고 생각한다. (팀원의 입장은 모르겠다.(..)) 술이나 회식을 좋아하지는 않지만 같이 일하는 팀장분과 급번개로 맥주 한잔하면서 서로 얘기하는 시간도 많이 힐링이 되었다.

1 on 1

1분기 피어리뷰를 진행하고 4월 한달 일때문에 미뤘던 1 on 1을 마무리했다. 물론 조금 더 자주해야하지만.. 다들 최근에 일정과 일에 대한 스트레스 등으로 예민해져있던 시기라서 많은 얘기를 나누는게 중요한 시기였다. 나한테 숙제를 주는 사람들도 있었고 다른 팀원에 대한 피드백, 스스로에 대한 고민 등 다양한 이야기를 나누었지만 각자에게 액션 아이템을 주려고 노력했다. 나보다 훨씬 훌륭한 분들이고 이분들 덕에 일이 돌아가고 있다고 생각하고 있다. 나도 내 얘기보다는 그들의 얘기를 이전보다 조금 더 경청하려고 하고 있다. 1 on 1은 항상 하고나서 드는 소감은 조금 더 일찍, 조금 더 자주할 걸이다. Try를 더 잘해보자. 더 잘 듣고, 더 자주.

PM 파이프라인

현재 CTO 포지션에 있지만, 최근에는(이번 AIDT시즌에 특히) PM분들이랑 거의 매일 데일리를 진행하고 전체적으로 PM 업무를 총괄하고 있다. 내가 항상 가지고 있는 아이디어는 똑같은데, 직원들이 잘 동기부여가 되고 스스로 더 열심히 일하려고 하면, Top Down 식에서 Bottom Up 으로 업무 방식이 바뀌어야 한다고 생각한다. Bottom Up 이라고 얘기하면, 너무 쉽게 말하는 것 같은데.. 이건 생각보다 어려운 일이다. 실질적으로 달성가능한 수준의 목표를 제시해줘야하며 그 목표가 회사의 비지니스 목표와도 정렬되어야 한다. 그리고 가장 중요한건 정보 공유이다. 비지니스 목표에 필요한 모든 내용을 투명하게 목표가 정렬된 하위 팀원들에게 누구보다 빠르게 전달해야한다. 이 정보는 왜 라는 맥락과 목표가 항상 동반되어야 하는데, 리더의 입장에서 “어떻게” 라는 것에 욕심이 있어도 팀원들의 성장과 동기를 위해서도 어느정도 참을줄도 알아야한다. 내가 PM 포지션을 확보하기 시작한건 내 역할(PM으로써)의 축소와 스쿼드 조직으로 조직 체계 변화, 그리고 Bottom Up 으로 일이 가능한 정보 공유 채널의 확보이다. 정보 공유가 안되면 결국 계속 닥쳐서 급하게 무언가 일을 할 수 밖에 없는데.. 이런 식으로 일이 반복되는건 장기적으로도 조직적으로도 보았을때 좋지 않다. 아니 나쁘다. 스타트업은 당장 하루가 급한데 ”장기적인“게 뭐가 중요하냐고? 글쎄, 그런식으로 말하면 나도 할말없다. 조직 전체의 “목표의 정렬”을 포기하고 Top Down이라는 편의주의를 선택하는 당신의 게으름에 안타까울뿐. 이해는 한다. 나도 관리자로 이런 편의주의에 빠지지 않기 위해 애쓰고 있을 뿐이다. 물론 위에서 말한 것처럼 이건 생각보다 쉽지가 않다. 무엇보다 내가 중간 관리자에 불과하다는게 통탄할 뿐이다. 이 부분에서 PM분들이 외부 채널의 많은 부분에서 전에 없던 역할을 해주고 있는데, 아쉽게도 너무 많은 외부 채널이 돌아가다 보니 에픽이나 주제들이 장기적인 빌드업보다 단기적인 액션 아이템을 창출하거나 일을 외부에서 가져오는 역할을 주로 하다보니 오히려 내부에서 원래 해야하는 PM의 역할을 상대적으로 못하게 되는 현상이 일시적으로 발생했다. 그만큼 회사가 비지니스 사이드 팽창이 빠르고 개발 리소스는 한정적이다보니 어려움을 겪긴 했는데 내가 설정한 방향대로 잘 해주신 결과에 대한 내부 피드백이 이렇다보니 나 스스로도 돌아보는게 많은 시간이었다. 쓰다보니 말이 길어졌는데, 프로덕트를 조금 더 들여다보고 역할분담을 하고 더 많은 대화를 하는 방향으로 계속해서 액션 아이템을 가져가려고 한다.

오브젝트 스터디 마무리

개발팀 내의 주니어분들을 대상으로 오브젝트 스터디를 진행했고, 주에 한번 한챕터씩 장장 3개월 동안 진행한 오브젝트 스터디를 마무리 했다. 책을 한챕터씩 끝까지 다 보긴 했지만, 중후반부부터는 그 내용보다는 책 자체가 주는 관점의 전환, 사고의 확장을 토대로 주마다 스터디 팀별로 각자 개발하면서 겪고 있는 다양한 설계 주제를 놓고 토론하는 시간이 재밌었다. Jbee 님의 추천 멘트를 통해서 FE분들도 꼬셔서 진행했었는데, 다들 만족하신 것 같다. 하지만, 책이 뒤로 갈수록 조금 더 객체지향의 디테일한 내용으로 들어가다보니 끝내는데 의의를 두었지만 책 자체는 초반, 최소 중초반 정도까지만 보고 새로운 관점을 얻었다면 책을 덮어도 좋다는 원래 Jbee님의 추천 멘트가 공감이 되었다. 그나마 스터디하면서 주니어들 대상으로는 좀 CTO 행세 좀 했는데(..), 끝나버려서 다른 의미로 조금 아쉽긴 하다. PM 업무 파이프라인이 정리를 단기적으로 목표를 잡고 다시 코드 읽는 시간을 늘려보자.

개인

운동

4월에 운동을 통해 멘탈 관리를 하고 있다고 했는데, 5월에는 성과를 조금 얻었다. 골격근량을 계속 유지하면서 체지방율 다운을 계속 하고 있다. 아직 목표하는 수치까지는 한참 남았지만.. 간헐적 단식과 아침 운동을 병행하면서 건강한 몸상태를 유지하고 있다. 목표한 1차 수치가 오면 한번 Inbody도 인증해보이겠다. 아침에 운동을 하고 유산소를 조금 늘리다보니 확실히 근력 운동하는 시간이 줄어들어서 주말에는 거의 유산소 포함 2시간 넘게 헬스장에서 보내곤 했다. 20년도부터 썼던 Strong 앱으로 최근에 365번째 기록을 남겼다. 앱으로 꾸준히 기록하던 때도 있었고 중간에 다른 앱을 쓰거나 메모장에 기록하던때도 있었는데, 어쨋든 이 앱으로만 기록한 횟수만 총합 1년이 된다는게 감회가 새로웠다.

개인시간

요즈음 농담처럼 하는 말이 있다.

매일 하는가? 운동 o 코딩 x 매일 연구하는가? 운동 o 코딩 x 당신의 직업은 무엇인가? 개발자입니다.(..)

나는 여전히 코딩을 할때 즐거움을 가지는 사람이다. 그래서 적어놓는다. 업무에서도 개인 시간에서도 코딩에 시간을 많이 투자하지 못하여 이번에는 즐거움을 많이 가지지 못했다고. 독서는 바쁜 와중에 자투리를 내서 계속 하고 있다. ~2024년 콘텐츠 기록 여기에 계속 기록해가고 있다. OTT나 영화보는 건 리스트가 많은데 독서 리스트는 생각보다 늘지 않아서 민망하다. 그래도 조금씩 읽어가자. 요즈음에는 “프로젝트 헤일메리”를 읽고 있는데 간만에 읽는 SF 소설인데 꽤 재미나다.

나가며

”그렇지만 어쩌겠습니까. 해내야죠.“

20대를 경영자로 살다가 30대가 되어 월급을 받으며 직장인이 된지 이제 5년차가 되었다. 한참 어렸을때는 퍼스트 펭귄의 위대함을 동경했고 내가 퍼스트 펭귄이라는 생각과 어떤 면에서는 선민 의식도 있었다. 근데 다짜고짜 다이빙을 하는 퍼스트 펭귄을 따라 같이 뛰어드는 세컨드 펭귄이야말로 진정 위대하다. 그래도 나는 다시 퍼스트 펭귄이 되려고 한다. 언젠가 위대한 세컨드 펭귄을 이끄는 퍼스트 펭귄으로 돌아갈 것이다. 아직은 아니지만. 이번달로 회사에서 풀타임으로 일한지 만 3년을 채웠다. 시간이 빠른듯 하면서도 그 사이 많은 일이 있었다. 나도 하면서 해봤던 일, 쉬운 일 보다는 안해본 일, 버거운 일들이 대부분이었던 것 같다. 아는 사람도 적어서 도움 받기보다는 항상 백지에 문제를 쓰고 해결책을 찾으려 애썼다. 아직도 Comfort Zone 이 아니라는 건 아직은 여기서 내가 성장할 수 있는 여지가 있다고 생각한다. 힘내보자.

Try

1 on 1 더 자주
운동 지금처럼 계속
꺾여도 계속가는 마음
PM 분들과 계속 액션 아이템, 로드맵 밟아가기
조직 동기부여, 업무 파이프라인 개선 포기하지 않기
감정 컨트롤

이전 회고
- 2024년 4월 회고
다음 회고
- 2024년 6월 회고

2024년 4월 회고

Tony Cho (https://flowkater.io) — Wed, 01 May 2024 00:00:00 GMT

들어가며

4월은 정신없이 흘러간 것 같다. 어느 날은 그날 오후에 떨어져서 그날 저녁까지 해내야하는 데드라인이 있는 일도 있었고, 일주일에 하루 정도 빼고는 빠르면 10시 늦으면 자정을 넘어서 새벽까지도 야근을 하는 날도 있었던 것 같다. 뭐 그렇다고 해서 그게 지치고 힘들다는 얘기는 아니다. 오히려 최근에 운동을 다시 시작해서 그런지 매일매일 에너지가 넘치긴 한다. 이런저런 생각할 겨를없이 어쩔수없이 한가지 일에만 집중하는게 더 좋다고도 생각한다.

회사

AIDT

출판사와의 하루짜리 워크샵, 세부 스펙 정의, 전체 스펙 정의 등 생각보다 도전적인 과제와 변화가 많아서 정신없이 진행되던걸 내려놓고 주말에 가만히 앉아서 지금 진행되는 일들을 정리하고 이해가 필요한 도메인 시스템을 다시 내 언어와 내 그림으로 그려보고 있다. (사실 이 부분을 최근에 소홀히 했었는데, 역시 백지에다가 인출 연습을 하면서 무언가를 정리하는 건 최고의 학습 방법이다. 한창 데이터와 수학 공부를 할때 익혔던 학습법이 내 모든 학습법에 베이스가 되었고 난 이렇게 해야 제대로 이해하고 또 내가 이해하고 있는 것에 자신감도 생기는 것 같다.)

AIDT 프로젝트는 굉장히 도전적인 사업이다. CSAP부터 검정 가이드라인, 출판사와의 협업까지 무엇하나 쉬운 내용이 없다. 팀에서도 2분기 (어쩌면 3분기)까지 전원이 집중해서 해야할 프로젝트이며 힘을 하나로 모으기 위해 모두들 열심히 일하고 있다. 일정도 정해져있고, 가이드라인에 의해 해야하는 것도 어느정도 정해져있다보니 내 최대 과제는 우리 본부에 동기부여를 계속 만들어주는 것이다. 어렵지만 계속 어떻게 전달해야할지 매번 고민하고 있다. 내 일 중 가장 난이도가 있는 일. 이 프로젝트가 기여할 새로운 변화를 순간 순간마다 확인을 했었고 그렇게 되기를 희망한다. 그리고 지금 같이 이 길을 가고 있는 동료들이 그 희망을 실현하기 위해 정말 최선을 다하고 있다고 믿는다. 웃으면서 지금의 고생을 추억하길.

매니지먼트

팀 매니지먼트에서 내가 실패하는 장면들이 몇 장면 있었는데, 대표적으로 PM, 데이터팀과 일을 할 때 였다. 아래 멘탈 파트에서 얘기하겠지만 예민해진 상태에서 드라이하게 전달하면 될 피드백을, 굳이 감정적으로 전달하는 경우가 잦았던 부분, 아직은 매니지먼트가 필요한 팀에게 너무 많은 일을 던져주고 알아서 하라고 했던 부분 등이 있는 것 같다. 멘탈이 운동 유무에 기인한 것도 있는데, 그냥 나도 정리가 잘안되고 모르겠으니 더 예민해진 것 같다. 과거 내 회사를 운영할때 아주 많이 부족하던 그 시절, 내가 팀원들에게 항상 감정적으로 피드백할때를 돌아보면 항상 내가 잘 몰라서 그랬었는데. (아아 나는 성장하지 못하였나..)

그래서 최근에 내가 선택하는 책이 대부분 매니지먼트, 조직 운영, 리더십에 쏠려있는 것 같다. 무슨 책을 읽든 액션아이템을 잘 뽑아서 Try 해보자.

채용

채용.. 정말 어렵다. 4월에도 팀 확장, 앞으로의 조직 변화를 위해 정말 많은 사람들을 팀원들 또는 내가 인터뷰하면서 채용을 진행하고 있다. 그래도 좋은 분들이 생각보다는 더디지만 들어오고는 계신데.. 투자하는 시간에 비하면 아쉽다. 아주 바쁜 일정을 쪼개서 채용에 또 투자하고 있다보니 아쉬움이 더 큰 것 같다.

개인

멘탈 회복 (그리고 운동 시작)

4월 중순을 기점으로 전반전, 후반전의 내 상태가 아예 다르다. 전반전에서 후반전으로 넘어오는 직전까지 멘탈이 많이 망가졌었다. 일이 그냥 힘들었다기보다 마음이 많이 약해졌던 것 같다. 발목 부상으로 운동을 계속 못하고 있었는데, 처음에는 운동을 못하니 좀이 쑤셨는데 그게 또 적응이 되니 그럭저럭 편해지고 괜찮아졌다고 생각했다. 그런데 확실히 스트레스 관리가 안된건지 짜증이 늘고, 유머를 잃게 되더라. 특히 같은 팀원들과 미팅을 계속 진행하면서 몇몇분들께 나의 짜증섞인 메시지가 필터링되지 않고 많이 전달되었던 것 같다. 부끄러운 일이다. 프로페셔널하지 못했다고 생각한다. 리더십을 논하기 전에 많이 부족한 모습이 드러난 적이 있었던 것 같다. 발목 보호대를 차고 아침 운동을 다시 시작하고 식단도 조금씩 관리를 하면서 멘탈이 회복이 되었다. 아침에 운동을 하고 출근을 하니 조금 더 활기차고 조금 더 집중력있게 일을 할 수 있게 된 것 같다. 멘탈이 무너졌을때 어느 순간에 집중력이 많이 떨어진 적도 있고, 회의를 하면서 다른 일에 집중하거나 흐름을 놓치는 경우도 종종 있었던 것 같다. 인간은 Multi-Tasking을 못한다. 특히 나는 완전 못한다. # The secret to Elon Musk's productivity | Walter Isaacson and Lex Fridman 이 영상을 보고 Serial-Tasking 에 대한 개념을 보고, 여러 일을 동시에 처리해야하더라도 그 순간만큼은 항상 하나씩만 몰입하자는 원칙으로 일을 처리하고 있다. 어떤 회의에 들어가서 회의 집중보다 다른 짓을 하는 경우도 종종 있고, 전화가 오거나 방해를 받는 경우도 있지만, 계속 그 순간에 몰입하려고 노력하고 있다.

독서 또는 기록

~2024년 콘텐츠 기록 콘텐츠를 많이 소비하고 있는데, 꼭 독서 뿐만 아니라 OTT 등 너무 소비만 하고 있다는 생각이 많이 들었고, 그때의 단상을 조금씩이라도 기록하기로 했다. 독서 리뷰는 항상 거창하게 글을 쓰려다보니 안쓰게 되었는데, 그냥 한줄평이라도 남기려고 한다. 1분기에는 책을 많이 못읽었는데 최근에 독서량 자체도 늘기 시작했다. 책을 많이 빨리 읽는게 그렇게 중요하다고 생각하지는 않지만, 그래도 읽을때 진도를 나가야 지속성도 생기는 것 같아서 이 속도를 유지하기 위해 노력 중이다. 뭐 어쨌든 이렇게 기록 열어두면 스스로의 책임감이 생겨서라도 열심히 읽을거라고 생각한다.

개인 시간 부족

거의 대부분 시간을 회사에 쏟다보니 개인 시간이 굉장히 부족하다. 개인적으로 계획했던 일들도 있는데, 피일차일 미루다보니 한달이 그냥 미뤄진 것 같다. 그리고 개인 시간이 부족하고 내 일도 한가지 집중보다는 여러가지 맥락을 넘나들다보니 개인적으로 어떠한 일에서 느끼는 성취감도 많이 떨어진다. 이게 멘탈에도 많이 영향을 미친 것 같다. 후반전이 되어서야 다시 운동도 하고 개인 계획도 다시 관리하기 시작했지만.. 4월 한달은 정말 내 스스로에게도 부족한 한달이었다. 잡생각을 떨치고 목표 및 계획세웠던 일과 지금 집중해야할 일을 하나씩 해나가자.

나가며

Keep

운동 다시 시작
멘탈 회복
인출 방식으로 구조 정리

Problem

팀 매니지먼트 부족
개인 시간 부족

Try

독서 및 기록 습관 유지
혼자서 사색하는 시간 가지기
개인 코딩 시간 늘리기

5월도 바쁜 한달이 될 것 같다. 내가 해야할 것만 집중을 하자.

이전 회고
- 2024년 2, 3월 기록(회고)
다음 회고
- 2024년 5월 회고

2024년 2, 3월 기록(회고)

Tony Cho (https://flowkater.io) — Mon, 01 Apr 2024 00:00:00 GMT

들어가며

2월달에 결국 회고를 작성하지 못해서 4월이 한참 되어서야 2, 3월 회고를 몰아서 작성하게 되었다. 조금만 시간을 내서 집중하면 금방 쓸 것을 게으르게 미루다 미루다 결국 이렇게 쓴다. 각 잡고 쓰려지 핑계를 대는 것 같다. 그리고 정말 주마다 회고를 남기지 않으면 기억을 못할정도로 많은 일들이 스쳐지나가서 짧게 짧게라도 기록을 해야겠다.

워크샵

1년만에 본부 워크샵을 진행했다. 인원은 크게 차이가 나지 않는데, 생각보다 구성원 변화가 있었고, 조금 더 알차게 시간을 보내기 위해서 하루종일 장소를 대여해서 진행했다. 오전에는 본부 목표와 팀별 목표를 공유하고 오후에는 워크샵을 진행했다. 회심의 프로그램을 비밀리에 준비했는데, 애자일이나 팀빌딩에서는 흔하디 흔한 프로그램인 마시멜로-스파게티 탑쌓기 프로그램을 진행했다. 의외로 개발자 디자이너만 모여있는 우리 조직에서는 아무도 경험하지 못해서 재미가 있었는데, "최고의 팀은 무엇이 다른가" 를 예전에 읽고 꼭 한번 해보고 싶었던 프로그램 중 하나였다. 유치원 생이 MBA를 이겼다, 실행력의 중요성 등의 교훈을 주는데 사실 그런 것보다 업무가 아닌 다른 과제로 평소에 팀웤하지 않는 팀원들이 모여서 진행했다는 것이 주요했고 재미가 있었던 것 같다. 그 외에도 팀원들을 알아보는 질문들이나 깜짝 이벤트처럼 진행한 "나락 퀴즈쇼" 같은 것도 재미를 더했던 것 같다. 자세한 진행 과정은 추후 팀 내 PM분의 워크샵 후기 블로그 글로 대신하겠다. 이번 워크샵을 계기로 본부 내에서 컬쳐를 다루는 사람들을 조직해서 내가 혼자 맨파워로 만들어가던 여러 활동들을 조금 더 시스템과 문화로 발전시키고 있게 되어서 좋았다. (링크 추가 예정)

오브젝트 스터디

팀 내 주니어분들을 대상으로 오브젝트 스터디를 시작했다. 백엔드, 프론트엔드, 데이터 팀 할 것 없이 시스템이 복잡해지는 과정에서 여러 고민들을 가지고 계셔서 스터디를 시작했다. 해당 추천 인용 글은 jbee 님의 글이다. 사실 예전에 읽은 책인데, 지금 팀 내 주니어분들에게 도움이 될 것 같아서 시작을 했다. 생각보다 책이 중반 이후부터는 막 읽기 편한 책은 아니어서 두 명씩 팀을 짜서 주마다 발표하는 방식으로 진행한다. 내가 가이드한 방식은 아래와 같다.

스터디 방법

스터디 흐름 전달 고민하기 (책 내용을 재구조화해보기, 그냥 읽기 금지)
- 발표 포맷은 ppt
- 두괄식 (요약)
- 세부 흐름 고민
실제 개발시 유즈케이스 코드 가져와보기
자기가 쓰는 언어/프레임워크로 예제 코드 변환해보기
- 실행가능한 전체 코드를 공유하기
느낀점 의견 나누기

특히, 책이 자바로 쓰여져 있어서 자바에 국한되지 않고 책에서 말하는 객체지향설계에 대한 본질, 즉 책임과 역할, 협력에 대한 키워드에 맞추어서 각자의 코드를 가져와서 논의하는 부분이 굉장히 유의미한 시간인 것 같다. 다들 배우는게 있다고 피드백도 주셔서 다행이라고 생각한다. 특히, 프론트엔드 주니어 한 분과 "콘텐츠 미리보기" 라는 컴포넌트를 만들어가면서 피드백을 주고받으면서 코드를 만들어보았는데, 서비스 개발에도 기여하면서 따로 시간을 내서 컴포넌트 설계에 대한 여러가지 고민을 할 수 있어서 좋았다.

1 on 1

연말 피드백 이후에 2달 넘게 1 on 1을 제대로 못해서 이번에 시간을 내서 팀 1 on 1을 하게 되었다. 먼저 깊게 반성을 하고 조금 더 자주하겠다고 다시 다짐하였다. 다들 너무 잘해주셔서 오히려 굳이? 라는 생각도 했는데, 역시나 각자 또 나름의 고민과 질문들이 있었다. 최대한 그동안 쌓인 질문에 대한 답을 드리려고 노력했으나 결국 더 자주 얘기해야겠다는 결론이다. 이번에 분기 피드백이 끝나면 한번 본부 전체 인원들과 1 on 1 을 진행하려고 한다.

KT Cloud Advisory

어쩌다가 KT Cloud Advisory 미팅에 초대(?)되어 KT Cloud 임직원들 앞에서 발표를 하게 되었었다. KT Cloud를 거의 10년 전에 사용해봤었기에 굉장히 부담스러운 자리였고 무엇을 준비해야되나 골머리를 앓았지만, 괜히 아는 척 하지말고, 그냥 현재 쓰고 있는 AWS 현황이나 요즈음 개발 트렌드, AWS 에서 제공해주는 다양한 Managed Service 의 편리함 등을 소재로 단순히 인프라 제공을 너머 서비스 제공으로 넘어가는 현재의 외산 CSP, SaaS 들의 케이스들을 공유하는 것을 주제로 잡았다. 발표가 끝난 뒤에 담당 미팅에 참여하신 임직원 분들이 여러 피드백과 질문을 주셨고 이때까지 미팅하면서 가장 뼈아프고 인사이트 있는 발표였다고 피드백을 해주셔서 죄송스럽고 감사한 마음이었다.

인터뷰

현재 팀에서 계속 채용을 진행하고 있고 백엔드 개발자, 프론트엔드 개발자, PM, 데이터 엔지니어 등 다양한 직군의 지원자들을 인터뷰하고 하고 있다. 보통 CTO 이자 조직장으로 있다보니 2차나 Fit 면접을 위주로 진행을 하는데, 면접을 보고 지원자들을 평가하는 포지션에 있지만, 많이 배우고 경험하는 것 같다. 경력이 있으신 지원자들 중에 조금 성급히 판단하는 습관을 가진다거나 PM들이 문제보다는 솔루션만 가지고 있는 모습 등 스스로 이런 지원자들을 보면서 거울 치료가 되기도 하고, 너무 괜찮아서 같이 일하고 싶었는데 결국 불발이 되면서 좌절하기도 했다. 그리고 타이밍이 맞아서 합류하신 분들을 보면서 또 매번 설레기도 하는 것 같다. 앞으로도 계속 인터뷰를 진행해야하는데 계속 좋은 분들을 모실 수 있었으면 한다.

운동과 건강

설연휴 즈음해서 고중량 운동을 하다가 발목 부상을 당했고, 운동을 시작한 이래 가장 오래동안 쉬고 있다. 운동을 못해서 해소되지 않는 스트레스와 네거티브 때문에 예민해지기도 했고 최근에는 거의 안그랬는데 일하면서 짜증도 내고 그랬던 것 같다. 특히 발목이 인대와 힘줄 염증이다보니 회복이 더뎌 계속 우울감에 사로잡혔던 것 같다. 날은 따뜻해지고 있고, 그 추운 겨울날에도 10km 씩 뛰었는데 초반에는 걷는 것도 힘들어서 스트레스를 많이 받았다. 한달 반쯤 꾸준히 치료하고 있는데, 최근에서야 조금씩 나아지고 있다. 그래도 덧나면 평생 운동을 못할까봐 최대한 무리안하고 시간될때 최대한 천천히 가볍게 걸으려고 하고 있다. 다행히 이번 주에 수영을 다녀왔는데 발목에 무리가 가지 않는 선에서 간만에 힘들때까지 운동을 해서 리프레쉬가 많이 되었다.

포스팅

일론 머스크를 읽고
호기심을 가져라, 판단하지 말고. (Be curious, not judgemental.) 글을 연습삼아라도 좀 자주 써야지 했는데, 두 개 정도 포스팅을 남겼다. 평소에 생각하는 바를 글로 옮기는게 생각보다 어려운 것 같다. 똥글이라도 계속 쓰다보면 늘겠지.

나가며

모아서 쓰다보니 기억이 많이 유실된 것 같다. 정말 바쁘게 하루하루 보내다보니 막상 지나고보면 무슨 일이 있었는지 잘 기억이 안난다. 특히, 요즈음은 회사일을 거의 아침부터 밤까지 손에서 안놓고 계속 하는 것 같다. 중요한 시기이긴 하지만, 밸런스를 잘 가져가려고 한다. CTO로서 해야하는 일, 급한 일, 회사에 필요한 일을 무조건 해야하는 자리지만, 급하지 않지만 중요한 일도 계속 가져가려고 한다. 그리고 매일매일 시간을 조금 더 값지게 쓰려고 더 노력해야겠다. 특히, 주말, 휴일에 현재 그 시간에 집중하려고 노력하자.

이전 회고
- 2024년 1월 회고
다음 회고
- 2024년 4월 회고

일론 머스크를 읽고

Tony Cho (https://flowkater.io) — Wed, 13 Mar 2024 12:13:59 GMT

들어가며

일론 머스크 책을 꽤 오랫동안 읽은 것 같다. 집중해서 본 건 아니고 바쁜 와중에 조금씩 조금씩 읽었는데 확실히 전기라 그런지 재밌기도 했지만 양이 좀 많아서 읽는데 오래 걸린 것 같다. 트위터 인수 시점 챕터부터는 속도가 붙어서 책 후반부 30%는 금방 읽은 것 같다. 일론 머스크의 모든 것이 현재진행형이다보니 내가 무슨 일을 하고 있을때 이 사람의 이런 일을 하고 있었구나 하고 생각하며 보기도 했다.

먼저 이 책은 일론 머스크의 지금까지의 일대기를 다룬 책이다. 어느 서평에 있었던 것 처럼 미디어에서 그는 빌런 아니면 영웅으로 극단적인 모습만 강조되어 비춰진다. 그리고 책을 읽어보면 알겠지만 그런 모습들이 단순히 미디어의 문제라고 보기는 어렵다. 하지만 일론 머스크가 지나온 일대기를 보면서 그가 살아온 삶의 방식, 일을 하는 방식(또는 일을 벌이는 방식)에서 그 수많은 인간적인 단점에도 불구하고 충분히 느낀 점이 많았다.

느낀점? 또는 인상깊었던 점

그의 방식을 100% 똑같이 따라할 수는 없다. 그건 그의 성격이고 스타일이다. 저자도 마지막에서는 그러한 그의 문제점 많은, 공감 능력이 결여되고, 즉흥적인 성격과 스타일이 결국은 또 성취를 만들어내는게 아닐까? 하고 얘기하고 있다.

하지만 과연 절제된 머스크가 구속되지 않은 머스크만큼 많은 것을 성취할 수 있을까? 여과되지 않고 얽매이지 않는 것이 머스크라는 인물의 본질에 필요불가결한 요소는 아닐까? 안정적이든 혼란스럽든 그의 모든 측면이 복합적으로 작용해 로켓을 궤도에 올릴 수 있고 전기자동차로의 전환을 이룰 수 있는 것은 아닐까? 때때로 위대한 혁신가들은 배변 훈련을 거부하고 리스크를 자청하는 어른아이일 수 있다. 무모하고, 사람을 당황하게 만들고, 때로는 해를 끼칠 수도 있다. 그리고 미치광이일 수도 있다. 자신이 세상을 바꿀 수 있다고 믿을 만큼 미친 사람 말이다.

배변 훈련에 비유한 건 정말 찰떡이다 (ㅋㅋ..)

그럼에도 불구하고 한 회사를 창업했던 사람으로써, 또 현재는 한 회사의 중간 관리자로 배울 수 있는 부분이 있다고 생각했다.

다음은 몇가지 내가 책에서 읽고 하이라이팅 해놓은 구절이다.

모든 요구사항에 의문을 제기한다. ..(중량). 그런 다음 그가 아무리 똑똑하더라도 의문을 제기해야 한다.

부품이든 프로세스든 가능한 한 최대한 제거하라.

단순화하고 최적화하라.

속도를 높여 주기를 단축하라.

자동화하라.

그 외에도 모든 기술 관리자는 실무 경험을 갖춰야 한다던지(매니저는 실무에서 손을 떼고 매니징에 집중해야한다는 주장과 또 반대된다. 구체적인 숫자도 나온다. 업무시간의 20퍼센트는 실무를 해라 등), 동지애는 위험하다(서로가 서로의 일에 이의 제기하기 어렵다는 취지), 광적인 긴박감(서지라는 용어로 불리우는 일론 머스크만의 스킬(?)이다.)이 우리의 운영원칙이다. 등의 다양한 얘기들이 인상적이다.

거의 최근까지 IT시장에서 재택 근무부터 워라밸 등 다양한 직원 복지를 포함하여 직원 개인을 최고로하는 조직 문화가 대두되었다. (일론 머스크 인수 전의 트위터) 하지만, 버블이 꺼지면서 해외부터 국내까지 다양한 기업들이 대규모 레이오프를 진행하면서 일론 머스크의 빡센 방법들, 정말 목표 달성을 위해 인생을 바쳐서 하드하게 일을 해야하는 조직 문화가 사실은 어느정도 재평가 되는 면이 있다. (테슬라, 스페이스X 그리고 일론 머스크 인수 후의 트위터)

그리고 정말 반복적인 일을 하거나 안정적인 대기업 조직에서 정해진 일만 하는 팀이 아니라 스타트업이나 무언가 가치를 새로 만들어야하는 팀이라면 더 많은 시간을 투자해서 더 몰입하고 실패하고 도전해야하는 것은 사실이다. 그리고 한 조직의 리더라면 그런 사람들이 같이 일을 하기를 기대할 수 밖에 없을 것이다. 놀자고 일을 시작한 것은 아닐테니.. 사실 그게 불편하다면 그 사람 잘못이라기 보단 그 조직에서의 핏이 맞지 않다고 봐야할 것이다.

그래서 배운점

그가 사람을 대하는 방식이나, 조직을 운영하는 방식을 100% 동의하는 건 절대 아니다. 나는 그 정도 능력이 없는 사람이라 그렇게 할수도 없다고 생각한다. 다만, 정말 일에 몰입해야한다면, 성취할 원대한 목표가 있다면, 진지할 필요는 있다는 것, 그리고 디테일을 놓쳐서 일을 그르치지 말 것(계속 디테일에 집착할 것) 은 중요하고 절대 놓치지 말아야하는 교훈이다. 또한, 제 1원칙이라고 하는, 정말 그런가? 에 대한 질문은 리더로써 꼭 가져야 하는 태도라고 생각한다. "원래 그래서 그런거다" 는 없다. "원래" 라는 건 없는 거다. 다 이유가 있고 이유가 없다면 꼭 그렇게 해야할 법도 없는 것이다.

마무리하며

사람은 복잡한 존재다. 대다수의 사람은 절대적으로 악하거나 절대적으로 선하지 않다. 그냥 혼돈 그 자체라고 생각한다. 일론 머스크도 사람이다. 그렇기 때문에 그의 가감없는 스캔들과 인간이 저래도 되나 싶은 행동들을 보는 한편, 그가 계속해서 어마어마한 성취들을 만들어나가는 장면을 보는 것은 그 자체로 큰 엔터테인먼트였다. 책을 보는데 꼭 배우고 느끼는게 있어야만 책을 읽는 건 아니라고 생각한다. 그저 재미를 추구한다고 해도 이 책은 그러한 재미를 충분히 주는 책이라고 생각한다.

혼돈 그 자체의 한 인간의 일대기를 바라보고 있자면, 옆에서 같이 두들겨 맞는 동료들에 나도 어느샌가 이입이 되어 몰입을 한 장면들이 많았다. 월터 아이작슨의 '스티브 잡스'를 읽을때는 내 회사를 시작한 초기이기도 하고 창업자로서 명확한 목표를 담고 있던 시절이다보니, 잡스에게 이입이 되어, 소위 잡스병에 걸려서 새삼 내가 잘난 사람이라고 생각한 시절이 있었다. 반면, 중간 관리자로 몇 년간 일했던 지금의 나로선 일론 머스크 뿐만 아니라 그의 주위에 있는 인물들, 중간 관리자들 즉, 세컨드 펭귄들에게 경외심과 존경심을 가지면서 책을 읽은 것 같다.

테슬라, 스페이스X, 트위터, 뉴럴링크 등 본인의 회사 뿐만 아니라 OpenAI 부터 우크라이나 전쟁까지 정말 한 사람이 이 많은 일을 어떻게 하고 있는 신기할 정도의 일들이 벌어진다. 이미 기술에서 한획을 긋는 사람이며 기술에 조금이라도 관심이 있는 사람이라면 이 책을 정말 재밌게 읽을 것 같다. 그리고 지랄맞은 상사에게 시달리고 있다면 이 책이 조금의 위안이 되리라. 일론 머스크보다 더 지랄맞기는 쉽지 않아보인다. (아, 블랙코미디를 좋아하는 사람도 강추..)

인상 깊었던 구절

유일한 규칙은 물리 법칙에 따른 것들뿐이다. 그 외의 모든 것은 권장 사항이다.

“우리는 기존의 지루한 트럭을 만들지 않을 거요. 그건 나중에 언제든지 할 수 있소. 나는 멋진 것을 만들고 싶소. 그러니까, 개기지들 마요.”

“어제와 오늘을 비교해보세요. 엄청나게 개선되었잖아요. 가장 크게 달라진 것은 오늘 엔지니어들이 키보드 앞이 아닌 지붕 위에서 실제로 설치 작업을 했다는 점이지요.”

“고도로 동기 부여된 소수의 특출한 사람들이 꽤 잘하고 적당히 동기 부여된 다수의 사람들보다 더 잘할 수 있다고 굳게 믿어요.”

머스크는 로켓 제작에서 “빨리 실패하는” 접근방식의 타당성을 믿었다. 리스크를 감수한다. 실패를 통해 배운다. 수정하고 반복한다. “우리는 모든 리스크를 제거하기 위한 설계에 매달리고 싶지 않습니다.” 그가 말했다. “그러면 아무 데도 갈 수 없습니다.”

그리고 그와 의견 마찰로 결국 퇴사한 사람의 말

“사람들은 제가 그를 싫어한다고 말하길 바랍니다. 하지만 실상은 훨씬 더 복잡합니다. 그래서 그가 그렇게 흥미로운 인물인 것 같습니다. 그는 약간 이상주의자이지 않습니까? 그는 다행성 인류, 재생 에너지, 심지어 언론의 자유 등과 같은 원대한 비전을 가지고 있습니다. 그리고 그는 그러한 큰 목표를 달성하는 데 초점이 맞춰진 도덕적, 윤리적 세계를 스스로 구축했습니다. 그래서 그를 부도덕하다고 폄훼하기가 어렵다고 생각합니다.”

~2024년 콘텐츠 기록

Tony Cho (https://flowkater.io) — Thu, 01 Feb 2024 00:00:00 GMT

Book (-)

프로젝트 헤일메리
- 24년 6월 10일
- 앞에서 진도가 안나가다가 로키와 조우한 순간부터 흡입력있게 읽었다. 주인공 그레이스가 우주선에서 홀로 진행되는 얘기와 사라진 기억을 계속 되살리면서 과거 지구에서의 이야기가 교차로 진행되는 서사 구조인데 처음엔 좀 몰입이 깨지는 것 같다가 후반부에는 정말 재밌게 읽었다. 스트라트를 보면서 삼체의 국장(?)이나 일론 머스크 같은 인물도 생각이 났는데 결국 인류의 구원이 지극히 평범하게 '착한' 그레이스 박사 손에 달려있다는게 키포인트다. 물론 주인공이 능력적으로 절대 평범하지는 않지만. 도덕적으로나 사명감 같은 걸로 똘똘 뭉친 주인공은 아니라는 것이 핵심. 그 과정과 서사가 굉장히 설득력있게 그려지고 마지막 엔딩도 의외성이 있었는데, 그레이스의 심정이 이미 백분 이해가는 상태라 납득이 갔다.
- 대단한 사명감을 가진 영웅(또는 기업가)들을 보며 나는 저렇게 헌신하지도 못하고 저 정도로 뛰어나지도 않은데. 그런데도 때론 평범한 우리가 모여 세상을 바꿀수 있는 것이 아닐까.
- 마션에 이어 영화화가 결정되었다는데 흐름이 달라서 어떻게 영상으로 나올지 기대가 된다.
슬램덩크 좋아하세요?
- 24년 5월 13일
- 우연히 리디북스 추천 목록을 보다가 반나절만에 읽은 책. ebook 만 있는데 슬램덩크 등장 인물 한명 한명 들여다보는 에세이. 작가의 슬램덩크, 그리고 인물들에 대한 찬사 같은 글이다. 작품이 작품인지라 이 책에서도 마음을 울리는 많은 문장들이 나온다. 퍼스트 슬램덩크가 개봉한지도 벌써 1년 반이 넘었는데, 다시 재시청을 해봐야겠다.
그 회사는 직원을 설레게 한다
- 24년 5월 8일
- 팀을 운영하면서 좋은 몇가지 액션 아이템을 알려준다. 특히 직원들의 탐색 시스템을 활성화하는 방법과 다양한 사례들을 공유해주는데, 전반부와 후반부에서 적용해볼만한 액션 아이템들이 꽤 있었다. 물론 이상적인 케이스 스터디가 주로 나왔지만 유의미했다고 느낀 책
  - 최고의 성과를 만들어내는 자신 (조직 외부, 내부)
  - 목적 의식은 결국 감정적 연결. (단순히 고객 후기 전달보다 고객과의 인터뷰가 훨씬 효과적이다.)
하이 아웃풋 매니지먼트
- 24년 4월 28일
- 매니지먼트를 하기 전에 읽었다면 좋았을 책. 하지만 이미 아는 얘기들이라 책 자체가 몰입이 되거나 그렇게 유익하지는 않았다. 그래도 매니지먼트의 전체 단계를 단계별로 쪼개고 구체적인 사례에 대한 액션 아이템을 도출하는 것은 꽤 좋았다.
- 중간관리자가 되면 한번쯤은 읽어볼만한 책인거 같아서 같은 팀 팀장님들에게 추천을 드렸다.
일론머스크
- 24년 3월
- 일론 머스크를 읽고

OTT (WIP)

30일의 밤 (애플TV)
- 4/5점
- 그때 내가 그랬다면? 이라는 질문. 그 선택으로 이미 우리는 멀티버스를 만들어냈다. 그 선택을 한 나와안 한 나. 슈뢰딩거의 고양이라는 아주 쉬운 예로 중첩 상태의 박스를 만들어 멀티버스를 돌아다닌다. 어쩌면 내가 했던 선택으로 있었을 그 현실로. 우여 곡절을 겪고 마지막에 다다랐을때 마지막 종장도 재밌었다. 그렇게 도착한 나'들' 이라니. 원작 소설이 있던데, 확실히 재밌게 보았다. 이렇게 살고 있는 내 모습도 어딘가에 있겠지? 라는 재밌는 상상을 계속 하게 된다.
폴아웃 (아마존프라임)
- 3.5/5점
- 유명 게임 원작 드라마. 뻔할 수 있는 SF 디스토피아 드라마. 원작 특유의 병맛과 고퀄리티, 매력적인 캐릭터로 뻔할 수 있는 서사도 재밌게 만든다.
잭 리처 시즌 1 (아마존프라임)
- 2.5/5점 (중도하차)
- 폴아웃 때문에 결제한 프라임을 더 이용하려고 보기 시작. 파일럿 에피소드의 강한 재미와 진한 캐릭터의 매력이 에피소드가 진행될수록 늘어지고 옅어진다.
레벨문 파트2 : 스카기버 (넷플릭스)
- 1/5점
- 이것도 뻔한데, 너무 지루한 영화였다. 2시간이 꽤 길게 느껴짐. 아쉽다.
마스터스 오브 디 에어 (애플TV)
- 4/5점
- 전쟁 드라마 클래식의 귀환. 밴드 오브 브라더스와 퍼시픽과는 비슷하면서도 또 공군이라는 소재로 다른 맛이다. 파일럿 에피소드가 이름도 헷갈리고 내용도 그냥 소개에 가까운 내용이라 파일럿 에피소드만 한 한달여에 걸쳐서 조금씩 보다가 3편부터 몰입해서 거의 몰아서 보게 됨. 매력적인 캐릭터. 전쟁을 통해 전달되는 뻔한 교훈을 뻔하지 않게 매력적으로 서사를 풀어나간다. 제일 좋았던 에피소드는 Part 6. 집중이 끊긴다면 나도 모르게 리듬을 타기 위해 손가락으로 책상을 두드린다.
기생수 더 그레이 (넷플릭스)
- 2/5점
- 내가 좋아했던 작품. 희대의 명작인 기생수를 한국판으로 만나는 것만으로도 기대. 그러나 서사는 사라지고 캐릭터도 약하다. 재미가 있다고 보기는 어려운 작품
기생수 파트1,2 (넷플릭스)
- 4/5점
- 기생수 더 그레이보고 아쉬워서 다시 시청. 당시에 나온 영화판도 일본 원작 만화 못하다는 얘기를 했는데 다시 보니 명작이다. 한국판과 가장 큰 차이점은 타미야 료코의 유무인 것 같다. 한국판 기생수는 그냥 괴물인데, 일본판은 확실히 괴물 이상이라는 것을 보여준다.
피지컬100 시즌2 (넷플릭스)
- 3/5점
- 4점인데, 발목 부상 시즌에 봐서 1점 더 깠다. 볼때마다 몸이 근질근질해서. 결국 예능이지만, 제작진의 연출 센스와 편집 센스가 시즌1보다 진일보 했고 출연자들도 훨씬 더 매력적이다.
삼체 (넷플릭스)
- 4.5/5점
- 일단 현시점 올해 기준 최고의 드라마. 소설 원작도 덜컥 구입했다. 도대체 서사가 어디로 흘러갈지 감히 예측이 안되는 미스터리에서 삼체인들이 드러나는 시점부터 약간 얘기가 평면화되는 느낌이 없지 않아있지만. 그래도 매력적인 주인공들과 그들간의 관계, SF적인 소재들로 몰입할 수 밖에 없게 만든다.
댐즐 (넷플릭스)
- 2/5점
- 나쁘지는 않았지만, 밀리 바비 브라운 원톱 영화가 가지고 있는 단점이 그대로 녹아있는 영화. (에놀라 홈즈 등) 드래곤의 디자인이라던지 액션 서사는 꽤 볼만했지만 이왕 보여줄거 조금 더 다채로웠으면 어땠을까.
F1 본능의 질주 시즌6 (넷플릭스)
- 4/5점
- 시즌을 6개를 거쳐오면서 느끼는건 인생사 새옹지마. 나도 F1이라는 스포츠를 6년 넘게 즐기고 있다는 걸 새삼 깨달았다. 시즌1의 주인공이었던 다니엘 리카도의 추락을 보고 있자니 마음이 아프다.
모나크: 레거시 오브 몬스터즈 (애플TV)
- 2/5점
- 몬스터버스의 팬이 아니라면 추천하기 힘든 드라마. 과거와 현재가 교차되면서 미래로 향하는데 뻔할 수 있지만 중반 이후부터는 흥미진진하게 시청했다.
올드 웨이: 분노의 추격자 (넷플릭스)
- 2/5점
- 재미없지도 재밌지도 않은 서부극 로드무비. 싸패에 가까운 딸과 싸패였던 아버지의 티키타카를 주축으로 극을 이끌어나간다. 둘의 케미가 전부인 영화. T도 이럴때 눈물을 흘린다. 뭐 이런 느낌.. 가볍게 보기엔 나쁘지 않았다.
베컴 (넷플릭스)
- 4/5점
- 데이비드 베컴의 인생을 과거부터 들여다볼 수 있는 다큐. 그냥 잘생긴 선수가 아니라 그가 겪었던 다양한 경험을 들여다보면서 실패와 도전, 그리고 팀웤, 가족 등 재미 이상으로 얻을게 많았던 다큐. 얼굴이 유잼이라 다 재밌다.
살인자ㅇ난감 (넷플릭스)
- 2.5/5점
- 초반 극을 끌어가는 이탕의 중심이 중반부터 갑자기 확 꺾이면서 평작이 되는 느낌. 기억이 명확지 않지만 어릴때 보았던 원작만큼의 충격과 감동을 주지는 못했다. 그래도 볼만.
리브 더 월드 비하인드 (넷플릭스)
- 3/5점
- 멸망이 온다면 이런 식일까. 스릴러스러운 심리 묘사와 상황에 대한 궁금증. 다음은 어떤 이상 현상이 나타날까에 대한 기대감. 반전아닌 반전의 엔딩도 재밌었다. 진짜 우리가 디지털 도구에 대한 의존성이 크다는 걸 다시 한번 느낌.
진격의 거인 (넷플릭스)
- 4/5점
- 몇 년 전에 만화책 원작으로 마레 초반까지 봤다가 작년에 애니메이션 엔딩까지 났다는 소식만 듣고 있다가 연초에 러닝머신을 타면서 조금씩 보면서 엔딩까지 다 보았다. 극을 이끌어가는 방식, 주인공들의 성장과 변화, 각 캐릭터의 매력, 마무리 엔딩까지. 쭉 연결해서 보니까 정말 잘만든 서사는 맞는 것 같다. 다만, 그때도 느꼈지만 마레로 넘어갔을때 에렌의 캐릭터 변화와 지크와의 관계, 서사 전환이 여전히 뜬금없다고 생각한다. 전반부와 후반부는 완전 다른 작품이라고 생각.
성난 사람들 BEEF (넷플릭스)
- 4/5점
- 넷플릭스 작품 중 무조건 추천하는 작품 중 하나. 블랙 코미디를 너무 좋아하는 사람으로써, 주인공의 불행이 더해질수록 명작이라고 믿는 나에게 정말 재밌게 본 작품이다. 작품에서 캐릭터들의 극단적인 모습이 꼭 우리와 같지 않더라도, 우리 일부분에는 그들의 찌질함이 녹아들어있다. 그냥 내내 웃기만 하다가 결말에 이르러서 아아 인생이여 하면서 생각이 많아졌던 작품.
- 조금 더 친절해지고 조금 더 사랑하자. 타인에게도 나 자신에게도.
슬로 호시스 시즌3 (애플TV)
- 3.5/5점
- 시즌1부터 정말 재밌게 보고 있는 수작 드라마. 게리 올드만의 그 캐릭터를 미워할 수 없다. 어느 하나 드라마, 영화 주인공이라고는 할 수 없는 캐릭터성을 가지고 있고 멋도 안나는 루저들이지만 이 루저들의 이야기가 깊은 공감과 작품의 몰입을 이끌어낸다. 시즌3도 꽤 즐거웠다. 루저들의 행진이 계속되었으면.

Movie (WIP)

인사이드 아웃2
- 3/5점
- 1보다는 별로였다. 라일리의 서사가 중점이 될수 밖에 없지만 1에서는 감정들의 캐릭터와 관계, 그리고 모험을 통한 성장으로 내가 좋아하는 픽사의 스토리의 전형이었는데.. 2에서는 너무 많은 캐릭터들이 나오면서 좀 그런 부분이 많이 줄었던 것 같고 라일리의 얘기가 공감이 되는 얘기라 괜찮은 작품이지만 1편보다는 별로.
퓨리오사: 매드맥스 사가
- 3/5점
- 매드맥스의 주인공이 맥스가 아니라 퓨리오사라고 생각했었는데, 퓨리오사의 프리퀄 스토리다. 1편 보다는 좀 얕고 인물간의 서사에 조금 더 맞춘 느낌이지만, 묵직하고 복수극의 마무리까지 깔끔했던 것 같다. 조지 밀러 감독의 연출 고집이 여전히 돋보인다.
굿 라이어
- 1.5/5점
- 중반까지의 좋은 심리 스릴러가 나오다가 반전을 위한 장치들이 맥락없이 떨어지면서 서사의 몰입이 확 꺾인다. 주연 배우들의 호연에 0.5점을 더 준다. 원작을 읽고 봤다면 훨씬 좋았을듯.
패스트 라이브즈
- 2/5점
- 이민자는 아니지만, 고향을 떠나온 사람으로 과거의 인물, 기억에 대한 향수가 분명히 있기 때문에 아주 약간의 공감은 있었다. 하지만 나는 그게 내 의지였기에 영화 자체의 지루함을 견디지는 못했다. 이성적으로 왜 좋은 영화인지는 알겠지만 깊이 공감하기는 어려웠다.
바튼 아카데미
- 3/5점
- 따뜻한 영화. 최근에 좋은 교욱이란 무엇인가에 대한 고민을 계속하고 있는데 결국 지식의 전달이 아닌 스승과 제자의 교감이 중요.
스턴트맨
- 3/5점
- 레트로한 감성과 스턴트맨들을 위한 헌정 영화. 바빌론의 스턴트맨 버전이라고 할 수 있다. 존윅, 데드풀 감독 답게 액션은 즐길거리가 가득하다. 서사는 단순하지만 기대했던 만큼의 재미.
범죄도시4
- 1.5/5점
- 마석도 형사가 한번쯤은 정말 극복하기 어려운 좌절에 빠지는 건 어떨까? 영화 코드가 그런 코드가 아니라서 기대할 수 없지만. 범죄도시1이 그래도 참 괜찮은 영화였는데.
아가일
- 2.5/5점
- 군더더기가 있고 영화가 좀 길긴 하지만, 나름 재밌게 보았다. 반전이 생각보다 예상 밖이었고 기대했던 주인공이 메인이 아니라서 실망한 부분은 조금 있다. 영화 평을 보니 다들 비슷한 생각인듯
듄 파트2
- 4.5/5점
- 한 명의 절대적이고 고결한 영웅이 다수의 범인들 때문에 어디까지 비극적일 수 있는가. 긴 영화지만 호흡이 빠르고 모랫바람과 샤이 훌루의 거대함에 삼켜진다. 아이맥스 재개봉시 필수 재관람.
고질라 X 콩: 뉴 엠파이어
- 2/5점
- 모나크:레거시 오브 몬스터즈를 재밌게 봐서 몬스터버스에 계속 관심을 두고 있었는데, 영화 자체는 그냥 거대 괴수쇼. 딱히 서사랄 것도 없고.. 전작에 비해 인간 파트를 많이 줄여서 좋았지만 인간 없이 괴수들만 나오게 되면 위압감도 그만큼 줄어들기 때문에 끝에는 약간 혹성탈출 보는 느낌.
시민덕희
- 2/5점
- 실화 바탕. 국밥 영화. 각색을 했겠지만 그래도 실화바탕이라고 하니 나름 몰입해서 본 것 같다. 그런데 딱 거기까지
그란투리스모
- 2/5점
검은 사제들
파묘
웡카
소셜 네트워크
덤 머니
인투 더 월드
외계+인 2부
크리에이터

2024년 1월 회고

Tony Cho (https://flowkater.io) — Thu, 01 Feb 2024 00:00:00 GMT

들어가며

나도 이제 올해부터는 월마다 회고를 써야지! 했다가 2월이 되고 10일이나 지나고 나서야 글을 쓴다. 귀성길이나 긴 이동시간 만큼이나 집중하기 좋은 시간도 없는 것 같다. 비행기 탑승은 항상 좋은 화이트 노이즈를 제공해준다. 1년 회고처럼 거창하게는 말고 바쁘게 돌아갔던 1월의 회고를 간단하게 돌아보려고 한다.

회사

연말 평가 연봉 협의 마무리

12월부터 시작한 R&D본부 연말 평가 및 연봉 협의안 작성을 드디어 마무리했다. 작년 1월까지 흔한 스타트업 연봉 협의(기준도 없고, 논리도 없는..)로 일관하다가 대표님과도 팀원들과도 여러 갈등을 겪고 4분기부터 연말 평가 프로세스를 만들고 구축하는데 많은 시간을 쏟았다. CTO로서, 매니저로서 전에 하지 못했던 업무였고 팀장님들과 고군분투하면서 평가 기준 팀원들의 self feedback 작성, 팀장 피드백, 1 on 1, 연봉 협의안 설정, 대표님과 커뮤니케이션 등 기록을 남기고 객관적으로 평가하려고 노력하고 그 과정에서 팀원들이랑도 많은 얘기를 나누었다.

Keep

프로세스 설계를 미리 진행하고 최대한 모든 기록을 훑어보고 작성하려고 노력했다.
R&D 담당 인사 업무는 여전히 내 몫이라 덕분에 공부도 많이하고 매니저로서 성장 경험을 가지게 되었다.
평소의 1 on 1 에서 보다 평가라는 프레임이 있었지만 조금 더 발전적이고 깊은 피드백을 주고 받을수 있었다.

Problem

피드백이 두루뭉실하고 구체적인 사례가 전달되지 않았을때, 받아들이지 못하는 팀원들도 있었다. 1년에 몰아서 피드백이 진행되다보니 유실되는 정보가 많다고 느꼈다.
팀장/매니저 oriented 피드백이다보니 Top Down 평가가 주였고 협업하는 동료들의 피드백의 부재로 아쉬운 부분이 있었다.

Try

올해부터는 분기별 Self feedback, Peer review 프로세스 진행
짧은 주기의 피드백으로 팀원들 발전 방향을 더 잦은 주기로 피드백 사이클 가지기
목적 지향 조직 구성 및 동기부여를 위한 조직 문화, 시스템 개선 계속 노력하기

교육 박람회

관련 기사

작년 하반기부터 회사가 공교육 진입을 위해서 힘쓰기 시작했는데, 이번 1월 교육 박람회가 회사의 공교육 진출 출사표가 되는 이벤트였다. 박람회의 본격적인 준비는 1달 전부터 였지만, 이미 작년 10월, 11월에 학교에서 실증을 성공적으로 마쳤기 때문에 새로 들어가는 피쳐들을 동작 가능한 버전 아래에서 시연용으로 개발하는데 집중하였다. 작년 9월에도 프로토타입 시연 행사가 있었는데 그때는 준비 기간이 1주일도 안되어서 거의 밤을 샜었고 동작가능한 버전도 아니었기에 이번에는 실제로 수업에서 활용하는 피쳐들을 위주로 일부 개발중인 기능을 Preview 하는 식(그래도 동작가능하게)으로 진행하였다. 3일 내내 코엑스로 출근하면서 현장 서포트를 했는데 현장 수업 시연을 보게 되면서 우리 팀이 만들어가는 솔루션의 아하 모먼트를 많이 느끼게 되었다. 아직 투박한 부분이 없지 않아있지만 실제로 박람회에서 본 다양한 솔루션들이 학교 선생님의 수업을 관통하기보단 숙제나 방과후 학습에 대부분 치중되어있다는 느낌이었는데, 우리 제품이 원래 서비스도 사람을 강조하다보니 오히려 선생님이 수업에서 활용할 수 있는 영역이 처음부터 존재하였고 학생들의 “참여”를 이끌어내는데 있어서 명확한 가치를 전달해준다고 느끼기도 했다. 아직 넘어야할 산이 많지만 앞으로 계속 발전시켰을때 기대되는 제품이다.

Keep

미리부터 준비한 부분. 미리부터 박람회 목표와 동기를 팀에 공유하고 TF를 미리 구성했고 운영팀에 붙여서 매일 회의를 진행하고 대비를 했다. TF팀원들이 책임감있게 진행한 덕분에 미리 잘 준비하고 잘 마무리할 수 있었다.

Problem

행사 운영 기획팀이 다른 본부이다보니 커뮤니케이션 비용이 확실히 작지 않았고 중간에 몇가지 세부 프로그램에 대한 변경 사항이 제때 전달이 되지 않으면서 우리 TF팀원들의 네거티브도 꽤 컸던 것도 같다. 물론 중간에 행사 운영 기획팀의 역할을 내가 팀원들에게 상기시켜주고 네거티브를 잠재우려고 노력했고 어느정도 워킹을 한 것 같다.
박람회 준비는 모두가 참여해서 같이 준비하는 건데, 행사 운영 기획팀에서 “도와줘서” 고맙다. 라는 말을 듣고 발작 포인트가 눌리긴 했다. (도와줬다니 ㅎㅎ.. 우린 이것 때문에 스프린트도 미루고 집중했는데..) 스몰토크, 컨센서스, 신뢰자본, 심리적 안정감 등 밥 한끼, 티타임, 커피 한잔 안해본 사람들과 일할때 어디까지 네거티브하게 갈 수 있는지 명확히 느낄 수 있는 프로젝트였다. 권한 위임도 중요하고. 물론 그래서 본부간 팀장, 이사, 매니저들의 역할이 더 중요한 것도 맞는데.. 고민이 되는 부분이다. (어느 회사든 본부간, 부서간 협업은 항상 어려움이 있는 것 같다.)

Try

사실 본부간 커뮤니케이션이 여전히 그레이 영역이라 한 본부 책임자로서 어디까지 무엇을 어떻게 해야하는지에 대해서는 명확한 액션 아이템은 없다.
더 친해지고, 더 많이 서로의 업무를 이해하고, 대화하고 팀원들에게 그들을 알려주고 등등 당장 내가 발로 뛰어서 할 수 있는 일에 최선을 다하려고 한다.

기타

스터디 팀 주니어분들을 대상으로 “오브젝트” 스터디를 구성했다. 개인적으로는 한번 읽었던 책이었는데, BE, FE, Data 할 것 없이 주니어분들이 이 책을 많이 읽지 않았다고 해서 내가 1장으로 발제를 하고 각 팀별로 돌아가면서 챕터별로 진행하면서 단순히 책 내용이 아닌 지금 작성하고 있는 코드를 가져와서 얘기 나누는 식으로 했다. 나는 이제 편하게 책만 읽고 가면 되고 팀원들이 더 많이 시간을 투자할 수 있게끔 도와주려고 한다. 데이터 팀과는 “데이터 메시”도 같이 보고 있다. 중앙 집중 기능 팀의 가장 큰 문제를 현재 데이터 팀이 겪고 있는데 데이터의 민주화, 데이터 프로덕트화 등 유효한 아이디어들이 책에 존재한다. 다만 구체적인 솔루션이나 도구를 알려주는 책은 아니라서 여기 아이디어들을 어떻게 프로세스, 시스템화 할 것인지 몫이 오로지 우리 몫이라 어떤 것부터 액션 아이템을 가져갈지 계속 고민하고 있는 중이다.

발표 올해는 목적 조직의 변화를 앞두고 있다보니 본부 내의 목적과 동기에 대해서 계속해서 팀에 전달하려고 애쓰고 있다. 발표 내용은 결국 시스템 중심이 아닌 유저 중심의 프로덕트를 만들자는 평이한, 어쩌면 누구나 알고 있지만 사실 메이커에게 생각보다 쉽지 않은 목표이다. 요즈음 프로덕트 개발자라는 말도 있던데, 얼마나 개발자들이 고객, 사용자를 생각하지 못하면 저런 말까지 나오나 싶기도 하다. 해당 내용은 회사 도메인 내용을 분리해서 한번 블로그에 올려보려고 한다.

팀원 퇴사 조직을 구축해나가고 여기서 일을 한지도 3년이 다되어가다보니 새로오신 분도 계시고 떠나시는 분도 계신다. 1월을 마지막으로 거의 팀 초창기부터 일했던 시니어 개발자 한분이 퇴사하셨다. 개인적인 사정이 컸지만 팀에서 큰 축을 담당하시던 분이고 여러 팀원들에게 신뢰도도 높고 퍼포먼스도 뛰어나신 분이라 앞으로 더 많은 역할과 책임을 나눌 것을 기대하였는데 아쉬움이 컸다. (물론 대표님과 나는 최대한 잡아보기 위해서 노력했다.) 한 분이 또 나가면서 그 시간들을 되돌아보기도 하고 앞으로 무얼 더 잘해야할까 고민을 많이 하게되는 기회가 되는데, 역시나 더 많은 대화를 못했던 것에 대한 아쉬움이 큰 것 같다. 뭔가 미운 놈 떡 하나 더 준다고 항상 말썽인 사람들과는 더 많이 대화할 수 밖에 없는데 잘하고 계신 분은 잘한다고 믿고 있다보니.. 대화 시간도 현저히 줄어드는 것도 사실이다. 더 노력하자.

해당 팀원분이랑 마지막으로 주고받았던 피드백 메시지

인터뷰 1월에도 신규 팀원 채용을 위해 많은 지원자들과 인터뷰를 진행했다. 좋은 사람을 만나는게 갈수록 더 어렵고 뭔가 내가 가지고 있는 기준도 계속 바뀌고 감으로 확신을 가졌던 부분도 확신을 계속 잃어가는 것 같다. 결국 일해보기 전에는 모르는 것 같다. 특히 주니어들보다 시니어들이 감이 잡기가 어려운데 나보다 사회 경험도 나이도 많은 업계 선배님들도 많이 계시다보니 대화를 통해서 많이 배우기도 이 분과 우리가 핏을 맞을지 고민하는 것도 다 난이도가 있는 일인 것 같다. 역시 사람이 제일 어렵다. 그래도 여기 있으면서 정말 좋은 점은 회사가 성장하니 업계에 유명하신 분들을 뵙고 인터뷰할 기회가 생긴다는 것이다. 같이 일하게 될지는 모르겠지만 이건 분명 회사 덕을 보는 거다.

개인

운동

strong 앱으로 기록한 1월의 운동기록. 박람회 주간(17일~19일)은 아침 일찍, 밤늦게 집에 코엑스로 출퇴근, 준비하느라 야근 등으로 하루를 제외하면 보통 주 4회로 가고 있다. 거의 매일 운동하고 있다고 생각했는데 확실히 기록으로 보니 다른듯. 날도 따뜻해져서 웨이트 비율을 줄이고 달리기를 늘릴까 어떻게 할까 고민중. 발등 염좌가 있어서 고중량 운동은 피하고 있다. 몇주가 되었는데 회복이 안되는듯. 12월, 1월 술 약속이 워낙 많아서 식단은 거의 못했는데, 설연휴도 끝나가겠다, 간헐적 단식과 식단 조절도 다시 시작하려고 한다.

작업 1월은 회사 업무를 집에까지 가져와서 하는 일이 대부분이었는데, 덕분에 내가 하고 싶었던 코딩과 작업은 거의 진행하지 못했다. 설 지나서 본부 자체 워크샵이 있는데, 해당 워크샵만 마무리되면, 손 놓고 있던 공부들, 작업들도 다시 계획을 세워서 조금씩 진행하려고 한다.

나아가며

전체 KPT를 정리하면서 1월(이자 2월 중순에 올리는) 회고를 마무리해보자.

Keep

운동. 어떤 운동을 하든 지금처럼 쭉
업무. 어차피 할 일이면 빨리 책임 소재를 가져와서 리드하기. 미뤄서 급하게 하지는 말자. 타본부나 위에서 그렇게 들어오는 일들이 분명 있지만 항상 침착하게 대응하기
자체 인사 프로세스 구축. 그래도 회사가 성장하니 스스로에게도 좋은 경험을 했다고 생각. 평가를 위한 평가가 아닌 성장/발전을 위한 피드백 시스템 계속 다듬어가기
스터디 시작. CTO로써 개발자 조직 역량을 이끌어내는데 시간 계속 쓰기

Problem

개인 작업 및 학습 시간 부족. 회사 업무와의 밸런스 맞춰가기. 주말 시간 조금 더 잘 활용하기
독서. 책을 붙잡고 있는데, 끝낸 책이 없음. 작년과 달라야함. 더 많은 시간 투자 필요. 운동처럼 루틴 만들기
1 on 1 부족. 평가와 외부 일정에 휩쓸리다보니 팀원들과 1 on 1 한게 벌써 한달이 넘어간다. 2월에는 시간 무조건 확보하기
주말 시간. 주말을 충분히 활용하지 못했다. 주 마다 Task 를 만들어서 주마다 끝내는 걸로.

Try

독서. 아이패드 선물 받고 아직 끝낸 책이 한 권이 없다니.. 이 책 저 책 붙잡지 말고 집중해서 읽자. (책은 정말 많이 구입함..)
주말 시간. 활용도 높이기
팀원들과 1 on 1
팀 미션, 목표 기준으로 정량적 목표 계속 디벨롭하기. 최종적으로 팀원들이 고객(사용자)에게, 서비스에, 헌신하게 만들기

Reference

2023년 회고
다음 회고
- 2024년 2, 3월 기록(회고)

호기심을 가져라, 판단하지 말고. (Be curious, not judgemental.)

Tony Cho (https://flowkater.io) — Thu, 01 Feb 2024 00:00:00 GMT

“Guys have underestimated me my entire life and for years I never understood why – it used to really bother me. Then one day I was driving my little boy to school, and I saw a quote by Walt Whitman, it was painted on the wall there and it said, ‘Be curious, not judgmental.’ I like that.” (Ted throws a dart.) "사람들은 항상 저를 얕봤던 것 같은데, 도대체 왜 그러는지 한동안 이해를 못했었어요. 한 때는 짜증나기도 했었죠. 그런데 어느 날 아들을 학교에 데려다 주는 길에 큰 벽에 새겨져 있는 월트 휘먼의 명언을 보았어요. '판단하지 말고 호기심을 가져라'. 마음에 들었죠." (테드가 다트를 던집니다.)

“So, I get back in my car and I’m driving to work and all of a sudden it hits me – all them fellas that used to belittle me, not a single one of them was curious. You know, they thought they had everything all figured out, so they judged everything, and they judged everyone. And I realized that their underestimating me – who I was had nothing to do with it. Because if they were curious, they would’ve asked questions. Questions like, ‘Have you played a lot of darts, Ted?’” (Ted throws another dart.) "그 글귀를 읽고 다시 차에 타서 출근을 하는데 깨달았어요. 나를 깔보던 그 수많은 사람들, 단 한명도 나에 대한 호기심이 없었다는 걸. 이미 세상의 이치에 대해 다 안다고 생각하는 사람들, 자기 방식대로 이것저것 판단하고 이 사람 저 사람 비판하는 사람들이었죠. 내가 누구였건간에 그 사람들은 애초에 관심이 없었다는 거에요. 예를 들어 정말 나에 대해 궁금한게 있었다면 물어봤을 거 같아요. '다트 많이 해봤어?'라고." (테드가 다시 다트를 던집니다.)

“To which I would have answered, ‘Yes sir. Every Sunday afternoon at a sports bar with my father from age ten until I was 16 when he passed away.’ Barbecue sauce.” (Ted throws a double bullseye to win the game.) "그랬다면 '네, 열살때부터 6년간 아버지 돌아가시기 전까지 아버지랑 매주 일요일 오후 스포츠바에서 게임 하곤 했죠 라고 대답했을 겁니다. 바베큐 소스 (아버지에 대한 오마주)" (테드가 더블 불스아이를 던져 게임에서 승리합니다.)

-테드 래소 중

들어가며

나이를 먹고 경험이 쌓이고 경력이 쌓이면서 생기는 습관 중 하나가 제한적인 상황에서 빠르게 판단하는 습관이다. 특히, 사업을 해보았거나 의사 결정을 하는 위치에 있어 보았다면, 현재 들어오는 정보만 가지고 이전 맥락과 이후 맥락을 추측해서 빠르게 판단하는 습관을 지니게 되는 것이다. 이러한 습관은 사실 나쁘다고 하기도 그렇고 좋다고 하기도 그런 습관인데, (왜냐면 그러한 판단을 내려야 하는 상황도 있기에) 사람을 판단하는 것에서 만큼은 매우 나쁜 습관이라고 볼 수 있다. 리더나 매니저로 있다 보면 팀원들이 하는 표현이나 태도만 가지고 그 사람의 생각을 판단하는 경우도 있고, 그들이 보여준 몇 가지 모습만 보고 그 사람을 정의하고 단정짓는 경우도 종종 있을 것이다. 물론 여기서 제일 안 좋은 건 남들이 하는 얘기만 듣고 그 사람을 판단하는 것이다. 앞에 있는 것들은 실수라고 부를 수 있지만 이건 명백히 잘못이다.

성장하는 리더십

나도 리더로 일하면서 이런 안 좋은 습관이 있었고, 그런 판단으로 비롯된 여러 생각들 때문에 항상 골머리를 앓곤 했다. 그러다가 테드 래소 드라마 시즌1에서 다트 던지는 장면(위에서 인용)을 보고 뒤통수를 아주 세게 맞은듯한 느낌을 받았다. 그리고 이 드라마는 단연코 내 매니저 커리어 중에 최고의 전환점(그리고 성장 포인트)을 가져다준 콘텐츠 중 하나이다. 농담삼아 리더십 책 10권 읽을 바에 테드 래소 시즌1을 보라고 말하고 다녔다.

미국인 테드 래소는 축구를 모른다. 팀을 망하게 하려는 구단주의 음모(?)로 영국 프리미어 축구 감독으로 취임하여 특유의 친절함과 유머로 사람들을 감화시킨다. 너무 동화 같은 클리셰인가? 시즌1의 끝을 보면 알겠지만, 살짝 스포를 하자면, 결국 팀은 강등되고 만다. 친절함만으로는 성적을 낼 수 없다는 현실도 드라마에서 보여준다고 생각한다. 하지만, 시즌이 진행되면서 조금씩 팀에 작은 변화가 일어나고 결국 성적이 오르기 시작하는데 결국은 느리지만 변화를 만들어낼 수 있다는 것도 보여준다. 테드 래소라는 주인공이 항상 밝고 행복해 보이지만, 그 또한 인생에서 굉장히 힘든 문제들을 껴안고 있으며 그로 인해 여러 위기를 맞이한다. 하지만 그는 항상 남에게 친절하다.

인생은 드라마 같지 않다. 나는 그다지 친절하지도 않다. 하지만 거기서 나오는 메시지와 깨달음으로 내 행동의 변화가 생겼다. 사실 큰 변화 중 하나는 그냥 물어보는 것이다. 팀원들과 1 on 1을 하면서 솔직하게. 너무 깊이 생각하려 하지 않고 그 사람이 말하지 않은 문제를 문제삼지 않으려고 노력했다. 현상만 가지고 있는 그대로 얘기하고 궁금한 점이 있으면 물어보려고 노력하는 것. 테드 래소처럼 매사 친절할 수는 없겠지만, 호기심을 잃지 않으려고 노력할 수는 있었다. 때론 누군가에겐 그저 물어보는 것만으로도 문제가 해소되는 경우도 있었다. 때론 일에 치이고 스트레스를 받고 예민해져도 다시 이 장면을 돌려본다. 아 조금 더 친절해야지, 조금 더 호기심을 가져야지.

하지만 그러한 노력이 무색하게 좌절감을 느끼는 날도 있다. 사람이다 보니 내가 베푸는 친절함과 호기심에 기대를 아예 안 하기도 힘들다. 다 엎어버리고 내면의 악마가 울컥하고 올라오는 순간도 여러 번 있었다. 리더의 자리는 고독하다. 이런 못난 생각이 꼬리에 꼬리를 물고 어느 날은 정말 수행(?)의 부족함을 깨닫는다. 그러다 어느 날 나의 이러한 노력을 알아봐 주는 사람들과 피드백을 듣고 다시 한번 정신을 다잡는다. 항상 그걸 알아주는 사람들에게 감사함을 느낀다. 그들 덕분에 길을 잃다가도 다시 조금 더 나아가고자 애쓴다.

나도 네거티브하고 시니컬해지기 쉬운 사람이라고 생각한다. 어쩌면 예전에는 그러한 핑계로 정말 호기심을 가지고 질문할 수 있는 용기가 없었는지도 모르겠다. 사람들은 사람들이 변하지 않는다고 말한다. 그들 스스로는 부단히 성장하려고 고군분투하면서도. 어쩌면 사람의 본질은 정말 바뀌지 않을 수도 있다. 하지만 사람은 성장할 수 있다. 느리지만 노력하는 사람들은 성장하는 모습을 많이 보았다. 나조차도 10년 전의 나와 지금의 나는 다른 사람이라고 생각이 든다. 조금 더 그들의 성장을 기다려줄 만큼의 여유가 나에게 항상 있었으면 한다.

나가며

팀이 급 성장하는 시기이고 일도 안 바쁜 일이 없을 정도로 바쁜 요즈음이다. 리더, 매니저라는게 이쯤하면 적응될 줄 알았는데, 계속하면 할수록 어렵다. 어떨 때는 처음보다 더 못한 것도 같고, 사람을 알 것도 같다가 아예 모를 것도 같다. 내 판단을 확신했다가 다음 날이면 모든 게 의심이 든다. 어려워하고 있는 것 보니 성장하고 있나 보다. 다시 태어나도 나는 테드 래소 같은 사람은 아니다. 그래도 그가 사람들을 대하고 팀워크를 만들어가고 친절을 베푸는 모습에서 진심으로 존경심이 우러나온다. 호기심을 가지고 팀원을 바라봐주는 리더. 스스로에게 믿음을 주고 팀에 대한 믿음을 이끌어내는 리더. 그러한 리더가 만드는 팀, 팀원들. 그런 팀원들과 같이 성과를 만들어보고 싶다.

(테드래소의 축구팀 리치몬드의 벽에 걸려있던 상징적인 "Believe(믿다)" 가 찢어져있는 상황) 믿음은 뭔가를 벽에 거는 게 아니야 알겠어? 믿음은 여기서 나오는 거야(심장을 가르키며) 유일한 문제는 너무 많은 잡생각이 우리의 길을 가로막는다는 거야 부러움, 두려움, 부끄러움 같은거 말이야 이제 그런 것들에 휘둘리기 싫어 내가 뭐에 휘둘리고 싶은지 알아? 내가 뭘 이루든 못 이루든 난 중요하다는 믿음 우리가 상처를 받았든 상처를 줬든 우리 모두 사랑받을 자격이 있다는 믿음 희망에 대한 믿음은 어때? 이런것들에 휘둘리고 싶어 내가, 우리가 나아질 수 있다고 믿는 것 자신을 믿는 것 서로를 믿는 것 이런게 살아가는 것의 밑받침이 되는거야 그리고 자네들 하나하나가 진심으로 믿으면 아무도 그 믿음을 찢을 수 없어

언젠가 또 생각이 많은 날이 온다면, 다시 이 글을 돌이켜 보며 되새기자.

호기심을 가져라, 판단하지 말고. (Be curious, not judgemental.)

2023년 회고

Tony Cho (https://flowkater.io) — Tue, 02 Jan 2024 13:28:30 GMT

들어가며

어쩌다 보니 작년에는 회고를 올리지 못했다. 아무렴 어떠냐 싶었는데 막상 기록되지 않은 시간들은 결국 잊히는 법이라 어느 순간 약간 후회가 되더라. 2년 회고를 몰아서 멋있게 써야지라고 잠깐 생각하기도 했는데 22년에는 22년의 일이, 23년에는 23년의 일이 있기에 이번 회고에서는 23년에만 집중하려고 한다.

회사

작년과 올해의 가장 큰 차이점은 조금 더 행복해졌다는 것이다. 작년에는 여전히 마음이 약간 뜬 상태에서 회사를 다녔었고 삶의 대부분의 시간을 보내는 회사에서 항상 스트레스에 시달리고 예민했던 시기였던 것 같다. 하지만 모든 문제는 자신에게서 비롯되는 법. 내가 어떤 위치에 있고 어디로 나아가야 하며 무엇을 감당해야 하는지 아주 드라이하게, 그리고 담대하게 받아들이고 나니까 오히려 한결 마음이 편해졌다. 그런 부분에서 작년에 비해 올해 내면의 성장이 있었던 것 같다.

R&D 본부 스프린트 회고

3년차 CTO

처음 회사에서 시작할 때 3명의 개발자와 시작하여 현재 26명의 팀원이 되었다. 시간이 지나면서 퇴사하시는 분들도 계셨는데 다행히도 대부분은 여전히 함께하고 있다는 것이다. 그리고 퇴사의 사유가 대부분 본인의 꿈과 목표였던 것 같다. 유학을 가거나 가족 사업을 한다던가, 빵집을 차린다던가. 물론 맞지 않아서 나간 사람도 있고 특히 22년 중순, 23년 초에 맞지 않는 사람들과 이슈가 있어서 굉장히 힘들었다. 여기서 얻은 교훈은 하나다. 팀에서 팀 리더와 맞지 않는 사람과는 절대같이 일하면 안된다. 여기서 “맞지 않는”이라는 것을 풀어서 쓰기에는 지면이 좁아 이 문장만 보고 아주 주관적이고 편향적인 의미로 오해될 소지가 있어 보인다. 기회가 되면 풀어보도록 하고.. 하지만, “맞지 않는” 사람도 포용하려는 만용을 부리다가 너무 많은 시간을 손해 보았다. 과감하게 인정하기로 했다. 나랑 맞는 사람과만 함께하기로.

작년과 올해의 가장 큰 차이는 팀장의 유무이다. 작년까지는 내가 CTO로 있으면서 팀장이 없는 4개의 기능 팀이 존재하는 형태였는데, 올해는 4개의 기능 팀에서 (처음엔 3명의 팀장이, 한 분이 퇴사를 하면서) 2명의 팀장님들(BE, FE)과 두 팀(Design, Data)의 팀장을 내가 같이 맡으면서 내 커뮤니케이션 채널이 전체가 아닌 최소 팀장님들이 계신 두 팀에 한해서는 팀장님들을 거치게 되었다. 팀장님들이 아니었으면 이번 한 해가 쉽지 않았을 것이다. 특히, 작년 말, 올해 초까지는 백엔드 코드 리뷰와 코딩에 업무 대부분을 할애했다면, 덕분에(?) 올 한 해는 업무에서 코딩하는 시간은 거의 없었다. 기술 설계, 기획 리뷰, 팀 커뮤니케이션 채널 역할을 더 잘하기 위해서 계속 고민했던 것 같다. 하지만 스프린트 위주의 기능 팀 구조도 이제 한계를 느끼고 있어서 24년에는 목적 조직으로 재편을 차근차근 준비하고 있다. 프로세스의 변화, 시스템의 개선은 한 번에 되는 것도 아니고 원하는 방향으로 바꾼다고 사람들이 쉽게 받아들이고 효과를 보는 것도 아니라서 인내하면서 준비해 보려고 한다. 이것도 추후에 조금 더 풀어보는 걸로.

디자인 팀의 경우 팀장님이 꿈을 향해 가셨기에 처음 팀을 맡게 되었을때 부담이 있었다. 팀장님이 계실 때 채용된 인원이 대부분이었고 해당 팀은 프로덕트 디자이너뿐만 아니라 QA, PM 등의 포지션이 함께 있는 팀이었기에 그래도 나름 개발자라고 자부하던 내게 부담이 없었다면 거짓일 것이다. 하지만 앞서 말했듯이 담대하게 받아들이고 나아갔다. 제일 잘한 것 중 하나가 1 ON 1을 정말 한 달에 한 번은 하려고 노력한 점이다. 다른 조직과 다르게 우리는 프로덕트 디자인 팀의 기획 설계가 중요한 팀이기에 프로젝트를 제대로 진행하기 위해 경영진과 Align 한다거나 타 부서의 이해관계자들과 커뮤니케이션 또는 내부의 개발팀과 커뮤니케이션하는 등의 역할을 했다. 돌아보면 오전부터 미팅으로 시작해서 미팅으로 끝나는 게 대부분의 날들이었던 것 같다.

프로덕트의 성장

22년에는 기존 비즈니스를 지탱하던 레거시를 모두 걷어내고 새로운 프로덕트로 교체하는 게 가장 큰 목표였고 그것을 달성했다면, 올해는 해당 프로덕트의 안정화, 퀄리티, 확장되는 비즈니스 영역을 커버하는 프로덕트의 개발이 목표였다. 메인 비즈니스의 퀄리티에 경영진부터 비즈니스 운영팀이 집중하면서 실제 프로덕트 가치에 기여하는 많은 피처들을 개발할 수 있었고 나아가서 B2G나 B2B로 비즈니스 확장이 되면서 다양한 요구사항을 만족하기 위해 프로덕트를 계속 개선하고 개발해나간 것 같다.

비즈니스 운영팀과 개발팀이 분리되어 있다 보니 Top Down으로 피처가 들어오는 경우도 많았지만, 스프린트 프로세스를 계속 다듬어나가면서 일정에 대한 약속을 지키는 개발 조직을 만들었다고 스스로도 평가하고 있다. 다만, 프로덕트 출시 이후 1년이 지나고 보니 급하게 달려오면서 놓쳤던 디테일들, 설계 문제점들이 부채로 쌓이기 시작하면서 확장과 추가 개발에 조금씩 발목을 잡기 시작했다. 23년에는 빠르게 하자가 모토였다면, 24년에는 잘 하자라는 모토로 가고자 한다. 팀원들 모두 적절히 집중할 수 있는 시간만 있다면 충분히 퍼포먼스를 낼 수 있는 팀원들이기 때문에 계속해서 그들이 집중할 수 있는 시간을 만들기 위해 노력할 것이다.

소프트웨어 추상화는 어려워..(..)

과제

잘한 일도 많았고 아쉬운 부분도 분명 존재하지만 앞으로 더 잘하는 것에 집중하려고 한다. 24년에는 다음의 과제들이 있다.

기능 팀의 단점을 해소하고 목적 팀으로 재편
팀 내의 리더십 레벨 더 키우기
개발자/PM 추가 채용
현재 부채 중 시스템 핵심이 되는 설계 구조 개선
추가적인 피드백/리뷰 프로세스 도입 및 개선
도메인/비지니스 더더더 팀에 공유하기

"어떤 기술 조직이든 그 회사의 기술 조직은 그 회사의 비즈니스 가치에 의해 평가받는다" 라는 말을 항상 가슴에 새기고 우리 팀 전체의 설계, 구현 역량을 높이기 위해 애쓸 것이다.

23년 초에 팀원들에게 했던 전체 워크샵 발표자료

결혼

올해 회사 일 말고 가장 큰일이 바로 결혼이 아닐까 싶다. 같이 살 집을 구해서 이사를 하고 살림을 합치고 결혼식 준비와 신혼여행까지. 결혼식이나 집 등 사적인 부분들은 생략하고 이번에 가장 긴 시간을 투자했던 프로젝트를 리뷰하겠다.

모바일 청첩장 개발

모바일 청첩장을 직접 개발했다. 가끔 개발자분들이 직접 청첩장을 개발하는 글들을 보곤 했는데, 나도 무조건 내가 직접 개발한다고 생각했던 것 같다. 어떻게 기획하고 개발하게 되었는지에 대한 후기 글은 다음 링크로 대신하겠다. 결과물은 후기 링크에 있으니 궁금하면 살펴보시면 된다. (날짜에 따라 링크가 만료되었을 수도..)

모바일 청첩장 작업 후기

여기서는 작업 후기에는 못담은 Flutter Web 얘기를 조금 더 해보겠다. 앞으로 모바일 앱 개발에 계속해서 Flutter 를 사용할 예정이라 간단하게 UI 작업도 할겸 React 보다는 Flutter 로 Web을 구현하기로 했다. 몇가지 장점과 단점이 있었는데, 처음 아내가 가져온 인터랙션 시안을 제대로 구현하지 못하면서 Flutter 구현을 바로 후회했는데 아무래도 인터랙션이나 커스터마이징이 훨씬 유연한 JS 기반의 풍부한 라이브러리에 비해서 Flutter 는 모바일 UI를 구현하기에 손색없는 컴포넌트 및 라이브러리를 가지고 있음에도 ScrollView 나 ListView를 활용한 인터랙션 구현에 아쉬움이 있었다. 다만, 깔끔하게 그 부분을 포기하니까 오히려 CSS로 하나하나 구현하는 것보다 훨씬 빠르게 UI 구성이 가능해서 아주 빠르게 구현할 수 있었다. (기본 UI컴포넌트부터 애니메이션이나 영상 등)

Flutter Web 개발(디버그) 모드에서는 Canvaskit 으로 렌더링된다는 것을 처음에 모르고 매번 릴리즈 모드 빌드 때마다 html 렌더러로 빌드를 했는데, 아이콘 위치나 폰트 등이 묘하게 개발 모드랑 이격이 생겼고 해당 부분 때문에 처음에 스트레스를 좀 받았었다. 결국 거의 끝에 가서 릴리즈 모드를 Canvaskit 으로 렌더링하고 나서 깔끔하게 구현할 수 있었다. 개인 작업이고 하고싶은 만큼 구현하면 되었기에 Flutter Web 을 선택하는 것이 크게 문제가 될 것은 없었으나 프로덕션이라고 한다면, 당장은 조금 힘들다고 생각된다. 아직까지 다음과 같은 단점들이 있다.

SSR 미지원. SEO 불리
초기 로드 속도 느림
개인적인 부분인데 대부분 컴포넌트가 모바일 네이티브에 맞추어져 있다보니 데스크톱 해상도에서 인터페이스 어색할 수 있음
브라우저 호환성 때문에 결국 JS 코드를 쓰게 되는 부분이 있음

토이 프로젝트 수준의 결과물이었으나 은근히 사용자 대상이 브라우저 파편화가 되어있어 (젊은 층은 ios safari, chrome, 중장년층은 android samsung 브라우저, 그리고 가장 골머리 썩혔던 카카오톡 인앱브라우저 등) 이 부분을 해결하느라 프로젝트 막바지에 고생 좀 했다. (Flutter 디버그 모드를 카카오톡 인앱 브라우저에서 띄우는 방법을 아시는 분 있으면 팁 좀 부탁드립니다..) react 로 했어도 겪을 수 있는 문제긴 한데, Flutter Web 의 환경이 익숙치 않다보니 더 힘들었던 것 같다. 반대로 말하면 위 4가지 사항이 별 상관없는 프로젝트이고 모바일 Flutter 랑 같은 UI를 가진 웹앱을 빠르게 런칭해야한다고 하면 거진 95%이상 코드를 그대로 가지고 Web으로 포팅할 수 있을 것이다. 분명히 Flutter Web의 큰 장점이 있다.

모바일 청첩장 페이지 공개 후 리뷰까지 반응은 꽤 좋았고 특히 같은 업계에 종사하시는 분들은 사서 굳이 고생하는 부분을 알아봐주시더라. 여기에 따로 적지 않았지만 이어서 준비한 결혼식까지 반응이 아주 좋아서 고생한 보람이 있는 결혼 프로젝트가 되었다. 회사도 워낙 바쁜 시기여서 정말 수면 시간이 부족했던 기간이 꽤 있었지만, 남들 다 하는 결혼, 수동적으로 남을 것이냐 적극적인 참여자로 남을 것이냐에서 후회없는 선택을 하고자 후자를 택했다.

항상 더 열심히 살아서 나쁠 건 없는 것 같다. (내가 주인공이라면)

아내가 종이 청첩장도 직접 디자인했다.

모바일 청첩장 기획은 이 한 장으로부터 시작

운동

22년 11월 기준 체중이 118kg까지 불었고 다음 해 23년 11월 결혼을 위해서 제대로 운동을 시작했다. 코로나니 뭐니 해도 너무 몸이 무거운 상태였고 건강도 좋지 않았던 것 같다. 스트렝스 훈련을 한다고 핑계로 유산소를 거의 안 하다 보니 어느 날은 한강에서 자전거를 탔는데 숨이 턱 막혀 쓰러질 것 같은 경험을 하기도 했다.

운동을 새로 한다는 마인드로 근비대 훈련으로 운동 방식을 바꾸고자 집 밑에 PT를 등록해서 근비대 운동을 익혀나가기 시작했고 유산소도 꾸준히 하면서 체중 감량을 진행했다. 식단을 최대한 지키고자 했으나 회사 일을 하면 그렇듯이 안지켜지는 날이 많아서 먹을땐 먹더라도 간헐적 단식을 습관을 들이고자 했고 결국 결혼 직전에 두자리수를 보게 되었다. 특히 근비대로 바꾸고 등 운동에 많은 시간을 투자하면서 체형도 많이 개선되었는데 근육량은 거의 그대로 유지하면서 체지방율은 10% 가까이 감량을 했다. 물론 결혼 이후 한달동안 다시 세자리로 올랐다. 하지만 1년여 기간동안 감량을 한거라서 요요가 막 온 건 아니고 운동습관이 여전히 잡혀있어서 식단할때보다 잘먹다보니 글리코겐이 충만해서 운동 퍼포먼스가 날이 갈수록 좋아지고 있다. 다만, 너무 또 긴장을 풀면 언제 또 체지방이 붙을지 모르니 새해에는 퍼포먼스를 높이면서도 날이 따뜻해지면 다시 감량에 도전할 예정이다. 아 그리고 다이어트 전에는 1km 달리기도 쉽지 않았는데 지금은 조깅 정도의 수준이라면 10km도 무리없이 달리고 있다.

운동할때 기록용으로 쓰는 Strong app. 20년 1월부터 사용 중

독서와 콘텐츠

올해도 책을 꽤 읽었고 많은 콘텐츠를 소비했는데, 따로 정리하는 시간없이 흘려보내다보니 잘 기억이 안난다. 그리고 예전에는 책을 펼쳤으면 어찌되었든 끝까지 읽는게 보통이었는데 요즘은 이 책 저 책 펼치는게 안좋은 습관이 생긴 것 같다. 책도 그렇고 여러 콘텐츠를 보면서 느끼고 배운 부분들은 앞으로 조금씩이라도 정리하고 남겨놓는 습관을 가지려고 한다. 그래서 올해의 반성삼아 해당 부분은 공란으로 두겠다. 내년에도 공란이면 발전이 없는 것이니 이 글을 가끔 읽으러 올때마다 정신차리자.

24년을 위한 23년 KPT

Keep

회사 개발팀의 양적 질적 성장 도모
운동
업무 외 시간이라도 개발 놓지 않기
결혼 생활
지인들에게 감사함을 잊지 않기

Problem

Keep 이지만 더 잘해야하고 더 많은 고민이 필요한 시기다. CTO 라는 포지션에 대한 무게감이 날이 갈수록 더해진다.. 잘한 것도 있겠지만, 아쉬움도 많다.
청첩장 개발 외에 직접 코딩한 프로젝트가 하나도 없다.
책을 읽고 제대로 정리하지 않았고 책을 많이 읽지도 못한 것 같다.

Try

리더십 콘텐츠 더 공부해보기
운동할때 항상 성장 도모하기
- 욕심이 더 난다. 감량도 더 하고 싶고, 근비대 운동에 더해서 크로스핏 같은 기능성 운동에 다시 도전하고 싶다.
- 체중 두자릿수 유지
독서 열심히하고 읽고 잘 정리하기
지인들에게 더 자주 연락하고 감사하기
기획한 프로젝트 개발하고 출시
영어 공부

나가며

올해 여름에는 할머니 장례식이 있었고 겨울에는 내 결혼식이 있었다. 20대 때에는 나 혼자 잘난 줄 알고 독고다이로 살며 주변인들에게 둥글둥글하지 못하고 날카롭게 굴었던 시기였다. 그 결과 그 시절 얻었던 인연들을 모두 잃었다. 한동안은 그래도 뭐가 문젠가 싶었는데 나이를 더 먹기도 했고, 올해 여러 일이 겹치다 보니, 결국 슬픈 일이든, 좋은 일이든 같이 슬퍼해 주고 축하해 주는 사람들에게 많은 감사함을 느끼는 한 해였다. 찐따처럼 굴지말고 조금 더 어른스럽게, 그리고 지금 인연을 항상 소중히 해야겠다고 다짐했다. 팀을 운영하면서도 헤어지는 인연들은 계속 생겨난다. 그들의 앞길을 응원하고 축복하고 같이 있지 않아도 계속 인연을 소중히 여기는 자세가 20대의 나와는 가장 큰 다른 점이다.

그리고 사람들에게 감사함을 가지기 위해서는 내가 나 스스로에게 부끄럽지 않게 충실하게 시간을 보내고 더 잘하려고 항상 노력해야 한다. 정체되어 있지 말고, 남 탓하지 말고 내가 할 수 있는 일에서 항상 최선을 다하자. 그리고 평정심을 유지하려고 노력하고 정신적으로 여유를 가지고 진심으로 존경하고 사랑하자.

혹시나 이 글을 읽어주시는 지인분들, 또는 저를 응원해주시는 모든 분들께 다시 한번 감사드립니다.

블로그 이전 (Gatsbyjs -> Obsidian Publish)

Tony Cho (https://flowkater.io) — Sun, 31 Dec 2023 14:40:00 GMT

요즈음 업무 할 때나 개인적으로 정리할 때도 Obsidian 을 많이 사용하는데, publish 서비스가 있어서 한번 여기로 이전을 해보았다. 2년간 글이 없었는데, 조금 더 자주 글을 올리기 위함도 있어서.. 한번 노력해보아야겠다.

Obsidian Publish 로 올리기 위해서 폴더 구조를 이전 블로그랑 같이 가져가고 마크다운 파일을 그대로 옮겼다.
깨지는 이미지는 손수 하나하나 replace 작업을 진행했다.
CloudFlare 도메인만 작업이 가능해서 후이즈 도메인에 CloudFlare 네임서버를 등록하고 Obsidian Publish 도메인을 등록했다.
- https://help.obsidian.md/Obsidian+Publish/Set+up+a+custom+domain 참고
- PageRule 설정에서 조금 헤맸다.
GA는 자체적으로 ID 설정을 할 수 있어서 바로 UA-id 를 등록하니 바로 실시간 트래킹이 된다. GA4로 전환되어있어서 조금 해멨다.

아직 뭐 글을 거의 안썼지만.. 개츠비에서 전환하니 글 publish 가 너무 편해졌다. Obsidian 을 기존에 잘 쓰던 분이라면 Fit이 잘 맞을 것 같다. 누가 말한 것처럼 공개용 블로그글은 자기 마케팅에 불과하더라도 기록용으로 조금 더 잘 활용하고 싶어서 바꾸었다. Publish 1년권도 질렀으니 조금 더 글을 쓰지 않을까?(..)

2021년의 기록

Tony Cho (https://flowkater.io) — Thu, 30 Dec 2021 16:12:59 GMT

올해의 X

올해의 책: 싱크 어게인

협업, 공감과 이해, 리더십과 배움에 대한 책.

나랑 대화하는 사람, 일하는 사람, 리더할 것 없이 추천하고 싶은 책.

올해의 음악: Maneskin - I WANNA BE YOUR SLAVE

비쥬얼부터 뮤비까지 전부 당황스럽지만, 로잉 머신 땡길때 가장 많이 들은 곡이 아닐까 싶다.

올해의 영상: 아케인

듄도 재밌게 보았고, 최근에 스파이더맨도 재밌게 보았지만, 올해는 역시 넷플릭스 리그 오브 레전드 애니메이션 아케인이 최고였다. 한국어 성우도 너무 좋았고. 참고로 난 LoL을 한번도 못해봤고 앞으로도 할 생각은 없다. 그래도 아케인은 너무 좋았다.

LOL 다큐멘터리 리뷰 리그 오브 레전드, 전설의 시작

올해의 프로그래밍 언어: Golang

1년간 golang을 했고, 즐겁게 코딩한 것 같다. 물론 지나고보면 golang에 대해서 정말 내가 제대로 이해하고 썼나 하는 의문점이 많이 들긴했다. 생각보다 깊이가 있는 언어이고 실제 Production 환경에서 그러한 깊이를 요구하는 챌린지가 꽤 있었다. django(프로젝트 참고 <DataColon 개발 후기> - 1. 들어가며)를 이제 더이상 안하게 된 건 좀 아쉬운 점.

20년 말부터 시작한 golang
- tWIL - 20년 12월 3째주
- tWIL - 20년 12월 2째주

들어가며

어떻게 된게, 이 블로그는 이전 글이 작년 회고, 그 다음 글이 또 1년 뒤 회고라니. 회고라고 쓰기도 민망해서 그냥 기록(..) 이라고 제목을 지어보았다.

(최근에 김창준님의 함께 자라기를 다시 읽고 있는데, 이건 회고가 아닌게 확실하다.)

사실 작년과 마찬가지로 올해도 예측불가능하게 흘러갔다. 무언가 커리어에 대해서는 더이상 어떠한 계획이 무의미하다는 것을 확실히 느끼고 있는 중이다.

작년 한 해가 대표에서 다시 개발자1이라면, 이번 1년을 요약해보자면,

“개발자1에서 다시 대표로 그리고 CTO가 되었다.” 정도로 요약할 수 있겠다.

작년 이 맘때쯤 얘기했듯이 좌절과 불행, 고난 속에서 많은 배움이 있었는데 올해는 그 배움의 가치를 적절하게 잘 발현할 수 있게 되었다. 물론 매일 한계를 맛보며 바닥을 치는 중이긴 하다. 깔끔하게 정리보다는 생각나는대로 기록해보련다.

1분기

데이터 강의로 SK와 계약하고 받은 돈을 시드로, 다시 풀타임 스타트업을 시작했고, 원래 같이 일하던 디자이너와 파트타임 클라이언트 개발자 친구와 일을 했다. 정확히 시작은 12월 중이었고 아마 올해 중에 가장 재밌었고 생산성이 높았고 신났던 기간이 아니었나 싶다. (내 사업이 제일 재밌다. 돈 걱정만 빼면.)

백엔드는 golang 이었고 gqlgen, echo 조합으로 쿠버네티스에 배포하여 프로덕션 운영까지 진행하였다. 개발 그 자체는 그 어느때보다 오히려 쉬웠고, 서비스 정책 설정, 기획의 어려움, 비지니스 모델에 대한 어려움 그리고 파트타임 클라 개발자 친구와 커뮤니케이션 이슈로 대표로, 매니저로 다시 다양한 챌린지에 놓이게 되었다.

2분기

모든 스타트업은 자금이 부족하지만, 2분기에 내가 자금이 부족한 건 아니었다. 그리고 개발 기간에 내가 약간의 시간을 투자해서 외적으로 자금을 수혈할 수 있는 방법 또한 있었고 데이터 강의도 SK 계약건에서 느낀바가 있어 데이터콜론도 다시 제대로 운영하고 싶었다. 그러다가 1,2분기에 주기적으로 연락을 주셨던 지금 회사 대표님에게 퇴근 이후 파트 타임 프로젝트를 제안받았다. 해당 프로젝트는 현재 회사에서 운영 중인 레거시 node 서버의 문제를 kafka로 해결하고 추후 데이터 파이프라인을 kafka 로 구성하는 것 이었다.

지금도 잘 모르지만, node 도 몰랐고 (프로덕션 개발을 안해봄), kafka는 아예 모르는 상태라서 망설이긴 했지만, 꿩도 먹고 알도 먹고 라고.. 공부도 하고 돈도 벌고 해볼만 하겠다 생각하고 시작을 했다. 그런데 그게.. 분명 파트타임 잡이었는데, 어느새 백엔드 파트 리드 및 일정 관리를 대표님과 CTO님이 물어보기 시작하면서 무언가 잘못되었다는 걸 느꼈고(..) CTO님이 CSO로 포지션 이동을 하면서 나에게 CTO 오퍼가 들어왔다.

고민을 잠깐 했지만 결국 결정을 했고, 입사(파트타임 -> 풀타임)한지 1주일만에 (정확히는 첫주 주말) 신규 시스템 빌드업을 위한 워크샵을 간다. (..)

(1분기에 진행하던 모든 일들은 사이드 프로젝트로 빠지게 되었다. 이 글을 쓰는 현재 시점에서는 회사 일때문에 Pending이 되었다.)

3분기

시리즈 B 이상 스타트업에서 CTO 경험은 처음이었지만, 에듀테크 즉, 교육 회사 특성상 개발자 규모가 5명 내외였기에 매니지먼트 자체가 어렵지는 않았고 프론트엔드 리드를 해줄수있는 7년차 분이 기존에 계셔서 프론트는 믿고 맡기고 백엔드 파트에 조금 집중할 수 있겠다고 판단했다.

스프린트를 세우고, 개발자 각자에게 가던 이슈를 슬랙 워크플로를 이용하여 채널을 단일화하고 layered architecture 도 적용되어 있지 않은 2000줄 짜리 단일 router 코드의 버그를 수정하고 잦은 서버 이슈로 self fetch 코드 제거 및 리팩토링, 최적화, 그리고 사실 그것보다 더 중요한 신규 도메인 아키텍처에 대한 디자인을 진행 하면서 바쁘게 시간을 보냈다.

그리고 현재 모든 스타트업들이 공감할 지옥의 채용 인터뷰 릴레이로 정신없이 하루하루를 보냈다. 티타임도 가지고, 팀 브랜딩한다고 블로그 쓰라고 내부 개발자 압박도 하고, 부트캠퍼들도 줄줄이 인터뷰하고 정신없이 시간이 흘러갔다. 사실 지금 와서 하는 말인데 채용에서 내가 했던 액션들은 크게 유효타가 없었던 것 같기도 하다. (나도 누군가의 말처럼 스타 개발자가 아닌 변방의 개발자다보니) 오히려 기존 팀원들이 예전에 일했거나 학교 선후배들에서 경력직들을 땡겨오기 시작하여 점점 팀이 갖추어지게 되었다.

그리고 회사가 PM/기획자가 따로 없이 (지금은 계시지만) 성장하다보니 UX팀과 커뮤니케이션 하며 PM/기획 역할도 병행했다.

대표님이 비전공자였지만 사업 초창기부터 직접 코딩을 해서 서비스를 운영한만큼 기술에 관심이 많아서 개발 사이드에 대한 관심과 존중이 있어서 회사가 외부에서 보여지는 것과 달리 기술조직을 서포트하고 빌드업해나가는데 수월했다. 또한 새로운 기술 스택 도입이나 이슈에 대해서는 집요하게 파고들어 나도 나이브하게 알고 있었던 여러 내용들이나 기술들을 깊이 있게 리서치하는 기회가 되었다. 물론 그 과정이 마냥 행복하지는 않았다.(..)

4분기

개발팀 5명 -> 16명 (2명 제외 모두 경력직 3,4년차 이상)
nestjs 도입
k8s 구축

정도의 일을 했지만 신규 시스템 빌드업이 생각 이상으로 모든 면에서 꽤 큰 작업이라 지금까지 일정 딜레이가 많이 되어있는 상태다. 거의 CRM/CMS/LMS/B2C 가 융합되어 한꺼번에 개발되는 프로젝트인데, 개발자들에게 익숙치 않는 교육 도메인에다가 시스템 구조도 에듀테크 특성상 독특한 부분도 있고 신규 개발자가 주마다 월마다 밀려들어오면서 온보딩이 제대로 이루어질때도 아닐때도 있어 계속 쉽지 않은 시간을 보냈던 것 같다. 12월이 되어서야 어느정도 팀이 갖추어진 것 같고 조금 더 팀 퍼포먼스를 끌어올리기 위해서는 (원래 기대했던만큼) 1~2달의 시간이 더 필요할 듯 싶다.

6개월 이상 회사에 있으면서 임직원은 그새 두배 이상 늘었고 모든 지표가 성장하는게 눈에 띄게 보이고 있어 신규 시스템 개발로 아직 비지니스 기여를 크게 하고 있지는 못하는 상황이라 조바심도 나고 있다. 여하튼 모든 회사의 기술조직은 그 회사의 비지니스 성과로 평가받는 거니까.

잘한 점

Full Jandi

신입도 아니고 취준생도 아니지만, 다시 개발을 하면서 열심히 커밋해보자고 하던게 1년동안 나름 잘지켜진 것 처럼 보인다. (작년 12월부터 쭉) 후반부 상당수는 내 커밋보다는 코드 리뷰가 대부분이긴 한다. 그래도 바쁜 와중에 코드를 계속 썼다는 것에 의의를.

독서/스터디

싱크어게인, 크래프톤 웨이부터 인류애를 찾아주는 휴먼카인드, 최강의 조직 등등 그래도 비개발 서적으로 분류되는 책을 20여권은 본 것 같고, 함께 자라기, 클린 아키텍처를 비롯 DDD, 함수형 사고, 이펙티브 타입스크립트 등의 책, 스터디도 진행했다. 여튼 계속 읽고 생각하고 적용해보는게 나에게는 정말 가치가 있는 활동들이다. 사실 이것말고 잘하는게 없다.

허접한 생각이라도 기록하고 공유를 많이 못한건 아쉽다.

사내 통계 세미나

4분기 2달 정도의 시간을 들여서 사내 비전공자 대상 통계/데이터 분석 강의를 진행했다. 1년간 강의를 쉬다보니 강의력이 많이 무뎌져 있었지만, 다시 내용을 전달하고 정리하는 과정에서 나름대로 다시 배우는 것들이 있었다. 항상 가르치는 사람이 가장 많이 배운다.

근데 8주동안 매주 2시간씩 강의도 하고 과제도 내주고 관리했는데 내가 추천한 권정민님의 “숫자 유감”에 참여 인원들이 더 많이 배우는 것 같더라.

역시 뭐든지 전문가에게 가세요. 그리고 만화책이라 오히려 좋아.

Functional 그리고 DDD

함수형으로 코드를 짜냐? 아니다. 클로저, 리스크립트 같은 함수형 기술 스택으로 유명한 그린랩스에서 말했듯 난 절차 피클러인 것 같다. 그래도 js, kotlin, swift 언어로 함수형 코드를 많이 연습 중이다. 아니 제대로 함수형을 하려면 Haskell 이나 클로저를 하던가 하다못해 Scala 라도 해야하지 않냐고 할 수 있겠다. 물론 맞는 말이다. 근데 아직 거기까진 여유가 안된다. 내공이 부족한듯. 괜히 애매하게 함수형에 맛들렸다가 golang generic 만 기다리는 부작용만 생겼다. 그래도 재밌다. 나름 실용적인 언어로 하고 있어서 실 개발에 유용하기도 하고. 재밌으면 하는 거지 뭐.

(JS 하시는 분들은 인프런 유인동님의 함수형 프로그래밍 강의 꼭 보자. 두번보자.)

DDD를 잘아냐? 잘 모른다. 그런데 에릭 에반스의 DDD 책 말고도 DDD Start, 도메인 주도 설계 철저 입문 등의 책을 다시 들춰보면서 배우는 바가 있었다. 자바라면 경련을 일으키던 내가 spring boot 도 하고 있다. (아니 사실 CA/DDD 관련해서는 자바 자료가 제일, 아니 유일하다. 국내한정. ~~자바공화국~~ )

에릭 에반스 책을 예전 소프트웨어 마에스트로 시절에 읽은 기억이 있다. 그때 나는 무엇을 읽은 것일까?

회사 신규 시스템이 엔터프라이급이다보니 아키텍처 고민이 많았는데 DDD로 어느정도 해소가 되었다. (그런데 이럴거면 nestjs 보단 그냥 spring boot 가 나을 것 같다. 개발자 채용도 훨씬 쉽고.)

여러 자료를 찾다가 결국 코드 구조는 29cm의 이희창님의 패캠 The Red 강의가 도움이 많이 되었다. MSA 강의라고 되어있어서 구매했었는데 오히려 DDD를 제대로 리뷰하고 좋은 코드 구조를 참고할 수 있어서 좋았다.

투자

캐시가 좀 생겨서 국내 게임회사들과 나스닥 몇개, 코인 투자를 했는데 나름 재미 좀 봤다. 물론 엄청 큰 돈은 아니지만. 덕분에 공부도 많이 했고. (슈카월드짱) 특히 연초에 샀던 DataDog 은 주식이 미쳐버리게 뛰었다. 더 샀어야 했다. 다시 생각해보니 못한 점인듯. (라고 할때 살걸)

작년 이맘때쯤 코인 사지 않아서 후회했는데 새해에는 행복회로 돌려본다.

못한 점

운동

코로나와 회사 출근이 겹쳐져서 2분기 이후로는 헬스장을 거의 못갔다. 지난 3년을 무게충이 되어서 스트렝쓰 한다고 식단관리도 안했었는데, 웨이트도 못하고 식단관리도 안되어 몸이 더 불었다. 이사를 하면서 Concept2 로잉머신을 샀는데 초반에 불타오르는 로잉에 대한 사랑이 금새 사그러들고 중간에 잠깐 머신과 권태기를 거치고 최근에야 다시 안정적인 관계를 이어나가고 있다. 인터벌을 타면 190 BPM이 넘을 정도로 빡세게 타는데, 이게 너무 부담스러웠다. 지금은 느려도 꾸준히 오래타는 걸 목표로 하니 매일 꾸준히 다시 타는 중이다.

어쨋든 웨이트 못한 건 너무 아쉽다.

그러고보니 잠깐 크로스핏 박스를 나간 적이 있었는데 계속 코로나 단계가 올라가서 꾸준하지 못했다.

사이드? 프로젝트

어쩌다보니 본업과 부업이 바뀌어버렸다. 그래도 나름 균형점을 찾아서 잘하고 있었다고 생각했는데, 역시 회사 일이 메인이 되고 바쁘게 돌아가다보니 밸런스가 무너졌다.사실 개발도 개발인데, 기획이 참 어렵다. 사업 운영은 더 어렵고. 아니 개발도 어렵다. 다 어렵다.

나가며

작년보다는 조금 중간 관리자의 면모를 갖춘것 같았고, 높아져만 가는 연봉 테이블의 개발자들과 존중과 압박이라는 묘한 줄다리기 과정에서 아래로 가는 리더십, 위로 가는 리더십 모두 여러번 시험 당하고 바닥도 치고 좌절도 했지만 나름 현재 팀을 보면 내 스스로 다시 한번 많이 배웠다고 생각한다. 물론 항상 조금 더 잘할 수 있었을 건데 라는 아쉬움이 남고.

중간에 한달 정도는 멍하니 회사 출근-퇴근-잠-출근-퇴근-잠만 반복했던 기간이 있었던 것 같다. 운동도 안하고 책도 안보고 유튜브만 보다가 늦게 잠들고. 지금와서 생각해보면 번아웃이었나 싶기도 한데.. 항상 날 움직이는 건 위기 의식이었다. 이러다가 그냥 그런 사람이 되겠다 싶은. 다시 생각해보니 번아웃보다는 뭐랄까 다시 월급 받고 뜨신 밥 먹으니까 생긴 안도감? 안정감인가. 정글에서 자라온 나같은 정글러(?)에게는 항상 위기 의식이 필요하다.

2011년에 창업/코딩 두 단어만 생각하고 코딩은 Rails Tutorial로 창업은 팟캐스트로 배우면서 일 시작했던게 벌써 10년이 되었다. 남들 학교다닐때 일 시작해서 올해로 만 10년, 이제 내년에는 11년차이다. 남들처럼 개발 커리어만 있는 것도 아니고 워낙 딴짓거리를 많이해서 지나간 시간이 참 재밌기도 하고 후회도 되고 복잡한 감정이다.

내가 처음 일을 시작했을때 10년 뒤의 나의 모습은 지금 이 모습이 아니긴 했다. 그 모든 시간을 실패했다고 하기는 어렵고 남들볼때는 나름 성과를 거둔 것 처럼도 보인다.

그런데 아직 이루지 못한 것들이 분명있다.

위기 의식 가지고 조금 더 앞으로 나아가보자.

올해도 고생했다. 새해도 화이팅!

2020년 회고 (Work, Timeline)

Tony Cho (https://flowkater.io) — Tue, 29 Dec 2020 03:12:34 GMT

회고를 시작하며..

2020년은 모두에게 어려웠고 나에게도 특히 고난하고 지난한 한 해였다.

그리고 무엇보다 사업 놀이하던 대표에서 다시 개발자1이 되어 고군분투하던 한 해였다. 무척 힘들었고 10kg가 더 쪘으며 지금도 내가 맞닥드린 문제를 완전히 풀지는 못했다. 대부분 평안하지 못하여 불행했고 그래도 가끔 행복했다. 그리고 순탄치 못한 길을 헤쳐나가며 많이 느끼고 많이 배우고 실패의 연속 속에 무엇보다 내 스스로를 가장 많이 돌아보고 반성한 한 해이지 않은가 싶다.

타임라인

1분기

회사가 자금난에 계속 시달리는 상태이다.

2년간 시범으로 운영하던 선대, 통계 스터디를 온라인 콘텐츠화 (데이터콜론 | 온라인에서도 오프라인처럼, 라이브 데이터 과학 스터디) 시켰고 디자인, 마케팅, 기획, 콘텐츠 제작까지 순전히 단 둘이서만 작업하고 릴리즈하였다. 캐시카우를 위해 급하게 개발된 감이 없지 않아 있었고 개발은 3주 정도 걸렸다. 사실 데이터 콜론 이전에 이미 온라인 상에서 스터디를 모집해서 운영은 하고 있었는데 자체 플랫폼의 필요성을 느끼고 만들었고 덕분에 후술한 3분기에 덕(?)을 보았다.

아주 짧게 썼지만 매일 밤을 악몽에 깨고 새벽에 식은땀을 흘리며 헛구역질을 하고 불안감에 지옥같은 나날이었다.

2분기

하지만 온라인 코스 특성상 일정 이상의 마케팅 비용이 필요했고 당시에 이미 무급에 개인 대출로 생활하던 시기라 다른 방법을 택해야했다.

결국 이직을 택하고 당분간 다른 회사로 출근하게되었다. 옥외 스크린에 영상 콘텐츠를 실행하는 셋톱박스와 그걸 지원하는 CMS를 세일즈하는 B2B 회사였고 처음에 내가 맡은 건 비어있는 Front-end 개발 포지션에 들어가서 새로운 광고 편성 인터페이스를 개발하는 것이었다.

간만에 돈 걱정없이 열심히 개발에만 집중했던 시기였다. 스타트업 대표로 살다가 개발자1이 되었다.

3분기

택시에 태블릿을 설치해 광고 사업을 하는 신사업이 추진되기 시작해서 데이터 리드를 맡게 되었다. 데이터부터 쌓는 것이기 때문에 개발팀 내에서 SQL 사내 스터디/교육을 진행하고 BigQuery 도입이나 데이터 엔지니어링 업무, 분석 관련해서 주로 업무를 했고 기존 셋톱박스 이상 탐지 예측을 위해 시계열 분석 업무를 하며 계속 RnD도 진행하였다. 물론 CMS Front-end 개발은 필요할때 계속 개발 업무 진행.

그러다가 SK 사내 교육 담당자와 연락이 되어 기존 데이터콜론 콘텐츠 선대, 통계를 각각 사내 교육 포맷에 맞게 재촬영 및 편집하여 납품하게 되었다. 재택근무를 하면서 이동 시간이 줄어 회사 업무가 끝나자마자 관련 작업을 계속 이어서 할 수 있게 되었다. 짧은 시간에 많은 영상 촬영과 아웃풋을 내야했던 상황이라 할때는 좀 힘이 많이 들었다. 특히 편집 지옥에 빠지니 너무 힘들더라..

내가 잘하는 일을 찾아서 하게 되었고 2월에 개발한 데이터콜론 덕을 보게 되었다.

4분기

한 회사의 대표가 아닌 일개(?) 직원으로써 일하면서 리더십과 팀 문화, 그리고 팀원 간의 커뮤니케이션 방법에 대해서 많은 걸 느꼈고 내 스스로를 많이 돌아보고 반성하고 깨닫는 시기가 되었다. 언젠가 이에 대해서 글을 쓸 기회가 있을 것 같다.

3분기에 하던 작업을 계속 이어서 하고 있었고 이런저런 생각을 하고 결국 다시 내 회사를 살려보기 위해 퇴사를 하게 되었다. 사실 자의반 타의반이라 용기있게 다시! 라고 하기엔 좀 애매하지만 결과적으로는 내가 계속 생각하고 있었던 일이니 뭐 잘된 일이라고 생각하고 있다.

투데잇의 숙원 사업인 뉴투데잇 개발을 드디어 시작했다. 백엔드를 Django 에서 Go로 Nextjs 랜딩페이지 배포 (stoodi.io) 하면서 고군분투를 했고 지금은 어느 정도 개발이 궤도에 오른 것 같다. 물론 아직 넘어야할 산이 많지만 ^^…

모바일 앱은 Flutter 로 개발 중이고 파트타임으로 도와주는 친구가 있어서 백엔드에 좀 더 집중할 수 있었다. 1월부터는 나도 Flutter 개발에 집중해야할듯 하다.

월급쟁이로 짧게 살아보니 매달 들어오는 월급이 얼마나 달콤한 건지 깨달았다. 그리고 그 달콤함에 젖어 내가 해야할 일을 미루고 시간을 벌고 있는 내 모습도 볼 수 있었다. 지옥에서 잠깐 벗어나서 한숨 돌리는데 다시 지옥으로 돌아가야 하는 심정이랄까?

하지만 결국 내가 가야할 길이라면 최대한 발버둥쳐보자.

좋아개

좋았던 점

다시 개발자가 되었다.

의외로 좋은 점이 많이 있다. 먼저 한 해동안 생존 코딩을 하게 되다보니, 개발 폼이 많이 돌아왔다. 지난 3년간은 내가 개발자로서 평가받지는 않았었다. 하지만 올해는 살기 위해 정말 열심히 코딩을 했던 것 같다. flowkater (flowkater) · GitHub github 프로필에 비어있는 5월~10월 커밋로그는 전부 bitbucket 을 이용한 회사 내 커밋들이다.

다루었던 기술 스택도 다양하다. 아마 이런 내용들은 차례차례 블로그에 정리해볼 예정이다.

홀로 서기 대표

에전에는 누군가에게 맡겼던 법인 업무를 스스로 모두 처리할 수 있게 되었다. 좋은 일인가? 싶지만 그래도 나는 좋았다고 생각한다. 물론 이거하면서 그 월급 가져갔나? 라는 생각도 잠깐 하긴 했었지만 (ㅋㅋㅋ..) 뭐 그때의 나에겐 큰 일들이었으니 후회는 없다. 예전에는 서류/금융 업무를 맡아서 하면 그거 때문에 스트레스 받아서 다른 일을 못하곤 했는데 매달 해야하는 일, 주기적으로 처리해야하는 일들을 Things에 잘 입력해놓고 적절히 잘 처리하고 있는 것 같다. 누군가에겐 담당 업무인 일들이 나에게는 이제 퇴근 직전 또는 업무 시작 전에 빠르게 그리고 간단히 처리할 수 있는 일이 되었다. 하지만 여전히 공인인증서 다이얼로그가 먹통이거나 윈도우컴이 갑자기 보안 업데이트를 하고 있으면 살의가 올라오는 건 여전하다(..) 그래도 심리적 허들이 많이 낮아진게 제일 큰 것 같다. 갑작스럽게 귀찮은 일이 생겨도 그냥 하면 되지 뭐.. 정도.

실패를 했다.

고민을 했는데, 이건 좋은 점인 것 같다. 그리고 단순히 실패 뿐만 아니라 다시 직원1로 다른 팀에서 업무를 해보면서 단순히 실패했을때의 과거에 대한 후회보다는 아, 내가 그때 그랬구나, 나는 더 잘할 수 있는가 와 같은 자기 반성적 회고적 그리고 내가 했던 수많은 실패의 답에 대한 실마리를 어느정도 본 것 같다. 물론 그게 정답은 아니겠지만.. 과거에 나랑 함께했던 모든 분들에게 진심으로 감사한 마음이 생기더라. 그리고 실패를 했어도 스스로 자기 연민에 빠지지 않기 위해 부던히 노력했다. 그래도 옆을 지켜주는 사람들 덕분에 또 그렇게 힘들지는 않았던 것 같다.

운동

코로나가 겹치면서 중간중간 끊긴적도 많지만 헬창의 삶을 계속 이어갔다. 3대에만 주구장창 매달리다가 올해 정체기와 부상 등으로 다른 웨이트도 하고 근육량도 많이 회복했다. 0.1톤이 넘는 몸무게로 턱걸이를 15개씩 하게 되었지만 몸이 너무 무거워 30개씩 하던 멸치시절이 그립다. 다시 헬스장을 갈 수 있게 되면 이제 다이어트를 해보자.

아쉬웠던 점

생존을 위해 수학이나 데이터 사이언스 공부를 많이 하지 못했다.

회사에서 할 수 있을거라고 생각했지만, 데이터에 대한 이해가 전무한 조직에서 해당 업무는 그냥 additional 무언가였다. 데이터 엔지니어링을 하면서 내부 조직들을 교육해보았자 결국 비지니스 의사 결정권자가 모르면 아무것도 아니라는 것을 깊이 깨달았다. 관점과 뷰를 공유하는 사람과 같이 일하는 것이 얼마나 중요하고 소중한 건지도 뼈저리게 느꼈다. 여튼 핑계고 먹고살기에 바빠서 많이 못했다. 21년에는 유튜브 보는 시간에 수식 한번 더봐야지.

책을 많이 못읽었다.

생리 욕구와 안전 욕구가 위협받는 상황에서 나의 자아 실현 욕구를 펼치기에는 쉽지 않은 한 해였다. 뭐 근데 유튜브 본 시간 생각하면 그냥 핑계다. 그래도 리디북스 페이퍼도 샀고(?) 간간히 서점가서 종이책도 구매했다. 이건 한 해 책 결산 후기에서 따로 정리하겠다.

~~비트코인 투자~~

가즈아~~~

개선할 점

건강해지자

다어이트, 꾸준히 운동하기. 누구나 하는 새해 결심. 운동을 좋아하니 식단관리만 잘하면 된다.

책 많이 읽기

유튜브, 영상 콘텐츠를 줄이고 책을 많이 읽을 것.

충실하게 살자

아무리 노력해도 안될때도 있다. 애초에 내가 실력이 안되는 걸수도 있고. 운이 정말 나쁜 경우도 있다. 그래도 충실하고 최선을 다하면 항상 무언가는 남게 된다. 문제를 직면했을 때 무언가를 해야할 때 망설이지 말고 고민하지 말고 일단 정면 돌파.

내년 목표?

목표는 많다. 근데 나는 20년 한 해가 19년 말에 전혀 상상하지 못한 한 해였다. 코로나 때문에 많은 사람들이 그랬을 것이다.

하고 싶은 것을 최대한 많이 할 것이다. 그게 나의 새해 목표다. 좀 부지런하게 살아보려고 한다.

tWIL - 20년 12월 3째주

Tony Cho (https://flowkater.io) — Tue, 22 Dec 2020 05:12:59 GMT

들어가며

이번 주는 집중을 했던 한주

개발

Dame24

지난주 생성했던 것을 1차 매듭을 지어보았다. 서비스 요구사항은 스터디 계획을 만들때 자동으로 책의 목차와 쪽수를 가져와서 나눠줘야하는데 내부 테스트용 웹 클라이언트를 하나 만들어보기로 했다.
지금 공개되어있는 Open API 중 유일하게 쓸만한게 Naver 책 검색 API라서 지난 주에 Go 서버를 간단히 만진 것과 1차 프로토타입을 만들어보았다.
사용한 것
- Back
  - Golang
    - Go 코딩은 즐겁다.
    - 사실 이번에 작업할때는 문자열 처리 함수를 좀 활용한 것 말고는 Go 자체 코딩은 별로 없다.
    - 대부분 서버며 라우팅이며 스크래핑이며 라이브러리가 해준다.
- Echo
  - 나는 처음부터 Echo 를 사용했는데, 최근에 예제를 보면서 net/http, gorilla/mux 로 하나하나 붙여가며 작업해본 적이 있어 Echo가 참 좋다.
  - 다만, 공식 가이드 문서가 조금 마음에 안든다.


func postContents(c echo.Context) (err error) {
	b := new(model.Book)
	if err = c.Bind(b); err != nil {
		return
	}

//... 생략

재밌는 건 위 handler 코드인데 post로 전송한 Body를 struct 만 잘 정의해주면 c.Bind(b) 에서 바로 매핑을 시켜준다.
물론, 파싱해온 결과를 리턴할때는 아래와 같이 디코딩해주었다.


//...

json.NewDecoder(res.Body).Decode(&sr)

//...

gocolly (goquery 포함)
- 이 전에도 말했듯 단순 스크래핑에 쓰기엔 좀 과하다고 볼 수도 있다. 다만, 크롤러도 만들어야하기에 사용에 익숙해지면 좋을듯하다.
- Async(true) 옵션 하나 만으로 병렬처리가 가능한 마법을 느낄 수 있다.
Front
- create-react-app + Typescript
  - 기본. 뭐 말이 필요한가..
  - App.tsx 에 다 때려박고 api나 interface 정도만 분리하고 BookCard 컴포넌트가 길어서 분리했다.
- react-query
  - 이번에 삽질한 의외의 복병…
  - apollo 를 워낙 잘 쓰고 있어서 api end point 가 두개밖에 안되는데 그냥 써보고 싶어서 적용해보았다.
  - typescript 쓰면서 항상 Type 할당이나 반환값에 대해 이해를 잘못해서 해메는 경우가 많았다. 특히 react-query 는 대부분 useQuery 에 대한 기초 예제는 많은데 필요할때 요청하는 useMutation에 대한 예제가 많이 안보였다. 물론 공식문서보고 해결했으나 Typescript는 하면서 조금 삽질을 한 것 같다.
  - 간단히 적자면, axios instance 함수 리턴 data에 타입을 정의해주고 useMutation으로 해당 instance 리턴 함수를 실행하는 커스텀 훅을 만들어주었다. 메인에서 정의하면, mutate() 함수로 요청을 보낼 수 있고 해당 객체의 data에 저장이 되는 형태이다.

// 커스텀 훅. 첫번째 인자는 키값이고 react-query 캐싱을 이용할때 쓰는 것 같다.

export function useSearchBook() {
  return useMutation("searchBook", async (title: string) => {
    return searchBookByName(title);
  });
}

// App.tsx

//..

const searchMutation = useSearchBook();
//..

const onSubmit = async ({ title }: FormData) => {
  searchInputRef.current?.focus();
  await searchMutation.mutate(title);
};
//..

searchMutation.isLoading; // 로딩 상태 true/false

//..

searchMutation.data;

//

SWR 에 비해 코드를 잘 못찾겠더라.
- tailwindcss + tailwindui
  - 나의 CSS에 평안을 찾아준 갓윈드css.. UI 라이브러리도 올해 초에 얼리로 구매해놓고 잘 갖다 쓴다.
  - 이번에 v2.0 이 나왔는데 조금 바뀐게 있어서 스타일링에 삽질을 조금했다.
Deploy
- 내부 테스트용이다 보니 제일 빠르게 할 수 있는 방법으로 배포를 했다.
- go 서버는 간만에 Heroku 를 사용해보았고 react는 언제나 그랬듯이 netlify
- asset 문제인지 초기 로딩이 좀 늦다. 뭐 어차피 프로덕션용은 아니니.
결과물

프로젝트

스택
- Go + Echo + gqlgen
- React + Typescript + apollo
주중/주말 내내 매달렸는데 그래도 그럴듯한 아웃풋이 나왔다.
관련 스택에 대해서는 천천히 후기를 써볼까 한다. 일단 프로덕션 릴리즈부터..

회고

좋았던 점
- 한 주를 일에 온전히 집중할 수 있었다.
아쉬운 점
- 코로나가 심해짐에 따라 운동도 못하고 업무 때문에 독서나 다른 걸 챙기지 못하고 있다.
- 원래 달리기를 하려고 했는데 러닝 시작한 이틀째 되는날 무릎통증이 심해서 보니 거위발건염이라는 것이 나에게 왔더라. 달리지 못해 아쉽다.
개선할 점
- 루틴을 다시 짜보고 급하지 않지만 꾸준히 해야할 일들을 챙기자.

여담

사실 되게 많은 Input 그리고 그에 따른 Output 도 있었는데 시간이 좀 지났고 아웃풋에 급하다보니 좀 제대로 정리를 못했다. 꾸준히 쓰려면 평소에 작성을 하고 좀 포맷을 정해야겠다.

tWIL - 20년 12월 2째주

Tony Cho (https://flowkater.io) — Sun, 13 Dec 2020 06:12:35 GMT

20년 12월 7일 ~ 12월 13일

들어가며

This Week I Learned 시작
- 같이 개발하는 친구의 블로그 제안으로 약간의 강제성을 띄우고 매주 글을 써보기로 했다.
- I Learned 이긴 한데 그냥 한 주의 내 이야기도 남길려고 한다.
퇴사
- 회사가 잠깐 힘들어서 6개월간 다닌 회사를 이번달을 마지막으로 그만두게 되었다. “스타트업 대표 7년차의 6개월 직원 일기” 같은 썰을 나중에 가볍게 써볼까 한다. 아쉬운 점도 많지만 어쨋든 많이 배운 기간이었다.
M1 맥북 주문 취소
- 13인치 M1 애플 노트북을 예약 구매를 했었으나 취소를 했다. 일단 당장 개발을 하는데 있어서 Docker 나 기타 개발 환경, 개발 도구들의 호환성 문제도 있고 해서 굉장히 성능이 좋다는 말에 혹해서 질렀지만, 취소하고 그냥 19년 형 16인치 맥북 프로를 주문했다.
- M2가 나오고 내년 하반기쯤 호환성 부분에서 전체적으로 지원되는 분위기가 형성되면 갈아타는게 안전할 것 같다.
- 아쉽긴 하다(..)

개발

Golang
- 기존에 Django로 작업하던 것들을 버리고 Golang 기반으로 넘어가기로 결정했다. 사실 원래는 Django 로 어플리케이션 서버를 구성하고 분산 처리가 필요한 연산이 있어 gRPC나 REST로 go 서버와 통신을 하는 방법을 고민했었다. 근데 아직 프로젝트 초반이고 서비스 운영도 하지 않은 상태에서 언어를 통일하는 방향, 그리고 무엇보다 새로운 것을 하고 싶다는 나의 내면의 욕구를 이기지 못했다. (..)
- 도움이 되었던 링크
  - 당근마켓의 고언어 도입기, 그리고 활용법
    - 발표를 잘하신다. 레일즈, 장고 등의 서버 운영 경험이 있는 사람들이라면 특히 공감이 많이 될 것 같다.
  - Tucker 의 GoLang 프로그래밍
    - 게임 프로그래머라고 하시는데, 프로그래밍 강의에 트랜지스터부터 설명하는 등 깊이가 있다. 강의가 워낙 길어서 다 보지는 않고 중간중간에 필요한 부분만 살짝 보았다.
  - 디스커버리 Go 언어 - YES24
    - 제일 처음 본 책. 물론 다보지는 못했다. 그래도 프로그래밍을 해본 사람이 Go 에 대해서 알아가는데 나름 깊이있게 다룬 책인 것 같다.
Golang 프로젝트 해본 것
- Dame24
 - Yes <-> No -> Dame (..) 에서 나온 스크래핑 봇이다. 가볍게 프로젝트를 해보고 싶었는데 gocolly 라는 크롤링 라이브러리가 워낙 좋아서 몇줄 안짜고 내가 원하는 결과를 얻었다. 가볍게 Echo를 붙여서 ISBN 코드로 책 정보를 가져오는 봇이다.
 - 지금은 단순히 특정 페이지에 대한 스크래핑만 하는데, 다양한 데이터를 긁어올 요구사항이 있어 원래 라이브러리 목적대로 크롤링 봇으로 발전시켜볼 예정이다.
- rbengine
 - 지금 서비스의 핵심 엔진(..)
 - 열심히 TDD 하면서 짜보고 있다. 확실히 Go는 코드 구현에 있어서 많은 선택지가 없다보니 조금 더 명료하고 직관적으로 코드를 짜는 것 같다.
 - Ruby에서 Python/JS 그리고 Go로 오면서 참 나도 많이 바뀌었다는 것을 느낀다.
- Web
Golang Web
- Go My Way #1 - 웹 프레임워크 - Jaehue’s
- Golang ORM, 무엇이 좋을까? · Billo Park
  - Golang을 다루는 고수분들이 많아서 그런지 한글로 정리된 글들이 꽤 고퀄리티의 글들이 많은 것 같다.
  - Go에서는 Ruby 하면 Rails, Python 하면 Django 이렇게 정해진 게 없다보니 처음 스택을 정하는데 고민이 많이 되었다. 심지어 Go의 ORM도 굉장히 부족한 환경이라 다양한 글을 봤는데 기술 스택을 정하는데 큰 도움이 된 글이 저 두개의 글이다.
- Echo + gORM + gqlgen 선택
  - 웹프레임워크는 Echo를 선택했고 ORM 으로는 gORM 그리고 현재 클라이언트의 Graphql 인터페이스를 지원하기 위해 gqlgen 선택해서 진행
  - 초기 도커 세팅부터 DB 마이그레이션까지 삽질을 꽤 했다.
    - 제대로 진행해보고 후기를 남기겠다.

회고

좋았던 점
- 글을 쓰기 시작한 점
- Golang을 본격적으로 시작한 점
- 퇴사(?)
아쉬운 점
- Golang Web 하면서 삽질을 많이 해서 이번주 목표했던 부분까지 개발하지는 못했다.
- 코로나 2.5단계가 되면서 헬스장을 가지 못해 운동을 못하고 있다.
개선할 점
- 결국 돌아보면 지름길은 없더라, 확실히 풀프레임웤에 비해 좀 답답한 면이 있지만 한땀한땀 코딩해가면서 배우는 재미, 느끼는 재미가 있다. 나아가자.
- 외부 환경에 흔들리지 말고 내가 해야할 일에 집중하자.

여담

Gopher 이야기
- Golang을 다루다보면 Golang을 대표하는 아주 귀여운(?) 마스코트 Gopher를 만날 수 있다.

너무 귀여운데.. 다른 사람들 반응이 심상치 않다.

취존..ㅠㅠ

사내 조직에 데이터 도입하기 (feat. 스타트업, 모바일 서비스) - 1. 서론

Tony Cho (https://flowkater.io) — Thu, 10 Dec 2020 09:12:59 GMT

이 글은 예측 모델링을 주 업무로 하는 데이터 과학자가 아닌 일반 IT 조직에서 데이터 인프라 적용을 고민하고 있거나 데이터 분석을 한다는데 어떻게 해야할지 모르는 엔지니어 또는 해당 조직의 구성원들을 대상으로 쓴 글입니다.

들어가며

최근에 데이터 분야가 인기가 많아지면서 인공지능, 딥러닝, 머신러닝을 학습하거나 입문하는 사람들이 많아졌다. Kaggle에서 다양한 데이터를 가지고 Python 또는 R 에서 제공하는 데이터프레임 라이브러리를 바탕으로 데이터를 분석하고 그래프를 그려보고 Scikit-learn 이나 Tensorflow 를 사용하여 복잡한 원리나 수학적 이론이 부족하더라도 간단한 코딩만으로 예측 모델링을 할수도 있다. 데이터 분야에 관심이 많고 앞으로 계속 이 분야에서 공부하길 원한다면 이러한 학습 방법은 입문자에게 아주 유용하다. 하지만, 대부분의 스타트업 또는 IT 인프라가 부족한 사내 조직에서 당장의 이러한 기술은 쓸모가 없어진다. (인공지능 스타트업이나 데이터 전문 스타트업은 당연히 제외한다.) 원인은 다양한데, 먼저 대부분의 조직에서 데이터가 없다. 데이터가 없다고 하면 대부분 개발자들이 이렇게 말할 것이다. “우리는 DB도 가지고 있고, 로그도 잘 쌓고 있고, 데이터가 아주 많습니다.”

정말 그럴까?

데이터가 없다.

IT 인프라를 운영하면서 쌓이는 데이터의 종류는 다양하다. 어떤 커머스 서비스가 있다고 할때, 상품의 내용이 저장되어있고 상품을 구매하거나 후기를 남기는 등의 데이터는 분명 DB에 저장되어 있을 것이다. 그리고 백엔드 개발자가 있다면 기본적으로 어떠한 요청을 주고 받았는지에 대해서 따로 로깅을 하고 있을 수도 있다. 다만, 이러한 데이터는 우리가 앞에서 배운 예측 모델링에 활용되기에 적합하지 않은 데이터일 가능성이 크다. 현대 머신러닝(또는 딥러닝)으로 문제를 풀기 위해서는 대부분 지도 학습, 즉 기계에게 라벨링된 데이터를 주고 학습 시켜서 모델을 만드는 방식인데, 머신러닝에 대한 백그라운드 없이 어떠한 데이터에 대해서 무언가 라벨링이 되는 데이터 형태에 대해서 이해하고 있거나 준비되어 있지 않을 가능성이 크다. (물론 기존의 DB/로그 데이터를 활용해 빡센 전처리 과정을 통해서 그러한 데이터 포맷을 만드는 것이 불가능한 건 아니다.)

즉, 우리가 타이타닉 생존 문제를 예측하기 위해서 어떠한 속성의 사람이 죽었다/살았다 라는 데이터가 있어야 하는데, 이게 참 도메인마다, 즉, 서비스마다 케바케라서 쉽지 않은 경우가 대부분이다. 또한 기술적인 논의나 데이터 이전에 우리가 예측 모형으로 풀어야하는 문제에 대해 정의하기가 쉽지 않은 경우도 많다.

예측 이전에 현황 파악

그리고 예측 모델링 이전에 현재 운영되는 제품의 데이터 현황 자체도 파악이 안되는 경우가 대부분이다. 단순히 트래픽이나 다운로드 숫자가 아니라 사용자가 우리 제품에서 어떻게 행동하는지, 전환율은 어떤지, Retention은 어떤지 같은 것들 말이다.

웹/앱 서비스를 하고 있다면, 비지니스 가치를 이끌어내기 위해 우리는 사용자의 행동 로그를 가지고 있을 필요가 있다. (맞다, 당신이 생각하는 Google Analytics 같은 것으로 그것을 할 수 있다. Mixpanel 이나 최근에는 Amplitude 도 많이 활용하는 것 같다.) 단순히 트래픽을 확인하는 용도가 아니라 사용자가 어떤 페이지에서 어떤 버튼을 언제 누르고 얼마나 머무는지 등에 대한 데이터이다.

그런데 이러한 데이터는 일반 애플리케이션 데이터와 달리 짧은 시간에 굉장히 많은 데이터가 발생하게 된다. 사용자가 많으면 많을수록 해당 데이터는 기하급수적으로 늘어나고 사용자의 행동을 구체적으로 정의하고 트래킹하면 할수록 더욱더 늘어날 것이다. 이러한 데이터는 일반 RDBMS에서 감당하기 힘든 트래픽이 발생한다.

이때 데이터 웨어하우스가 필요하다. 이번 시리즈에서 소개할 구글의 BigQuery가 대표적이고 AWS의 Redshift 나 Snowflake 등도 있다. 그리고 이러한 웨어하우스들은 SQL로 데이터를 가져온다.

즉, 초기에 데이터를 만지면 뭔가 Sexy(?)해보이는 머신러닝 같은 예측 모델링을 생각하겠지만 지금 우리에게 필요한 건 어떤 데이터를 쌓는지 정의하고 그 데이터를 잘 쌓고 우리의 데이터를 잘 들여다보는 것이 먼저이다. SQL로 raw 데이터도 뽑아보고 계속 데이터를 뒤져보는 작업은 상대적으로 덜 Sexy(?) 하지만, 비지니스/도메인에서는 그저 현재 우리 사용자가 무엇을 많이 하는 지 아는 것만으로도 큰 의사 결정을 도울 수도 있다.

그래서..

그래서 현재 초기 스타트업이고 데이터를 도입하고 싶은 현직자들은 머신러닝 책을 펼칠게 아니라 먼저 어떤 데이터를 쌓아야하는지 정의하고 (비지니스/도메인 레벨에서), 기술적으로 SQL과 데이터웨어하우스에 대한 공부를 하는게 더 바람직한 방향이다.

은근히 Python, R에 대한 학습 콘텐츠가 일반화되면서 해당 언어로 데이터프레임을 다루는 건 할줄 아는데 SQL을 못짜는 사람들이 많다. 하지만 SQL이 모든 데이터 분석 단계의 최소 지식이며 모든 RDB 또는 데이터웨어하우스를 관통하는 언어이므로 혹시나 본인이 데이터 분야에 입문했는데 SQL을 할 줄 모른다면 깊이 반성하고 당장 SQL 부터 공부를 하길 바란다.

요약

서론이 길었다. 장황한 내 비문을 참지 못해 스킵한 분들을 위해 요약을 하면,

대부분 조직은 예측 모델링(머신러닝)을 충분히 할만한 데이터가 잘 없거니와 도메인에서 문제에 대한 정의도 안되어있다.
앱/웹 서비스에서는 사용자의 행동 로그를 잘 쌓아서 그것만 분석해도 좋다.
데이터를 쌓기위한 데이터 웨어하우스부터 구축해야 한다.
일단 SQL부터 공부하라.

이 시리즈(?)의 목적은 초기 개발 조직에서 데이터 리드를 하면서 데이터 엔지니어링 백그라운드가 없는 엔지니어들과 함께 손쉽게 데이터 웨어하우스를 도입하고 데이터 분석 을 위한 환경을 구축한 경험을 얘기하는 글이다.

네이비씰 승리의 기술

Tony Cho (https://flowkater.io) — Mon, 18 May 2020 09:05:59 GMT

극한의 오너십 : 미국 네이비 씰이 리드하고 이기는 방법

위 제목이 원제인데, 극한의 오너십(Extreme Ownership)이라고 말하는 책의 제목이 이 책을 관통하는 모든 주제이다. 모든 일의 책임을 나에게 두고 어떻게 해결할지 모색하는 극한의 오너십은 우리에게 리더십은 무엇인가 고민하게 하고 우리는 과연 잘하고 있는가 강하게 질문을 던진다.

군대에서 리더십을 배운다고?

네이비씰은 미국의 해군특수부대이다. 우리나라에 가장 비슷한 부대가 아마 UDT/SEAL 해군 특수부대일 건데, 참고로 해병대(참고로 해병대는 정규군이다. 특수부대가 아님.)에서 군복무를 하던 시절, 우리나라 UDT/SEAL 대원들과 훈련을 받은 기억이 있다. 나름 깡 좀 있고 몸 좀 쓴다는 해병대원들을 모두 압살(?)해버리고 항상 체력 경쟁에서 1등을 해먹는 UDT 대원들을 보며 우리 해병대원들은 존경심과 더불어 두려움의 존재였었다. 그런 부대의 모티브가 된 미군 특수부대가 말하는 리더십이란 무엇일까? 도대체 특수부대는 어떻게 훈련받고 어떻게 작전을 수행할까? 그런 궁금증과 더불어 리더의 자리에 있는 많은 분들이 추천해주고 있어서 망설임 없이 책을 선택했다.

그리고 기대를 저버리지 않고 네이비씰은 우리나라에서 흔히 생각하는 군대의 스테레오 타입을 한참 벗어나 있었다. 생각해보면 이라크 한복판에서 목숨이 오가는 작전을 수행해야하는데 막가파(?)식으로 진행하면 아마 작전에 실패하고 죽고 말 것이다. 까라면 까는게 군대라고 생각하는 분들이 많겠지만 네이비씰은 그러한 모습과는 상당히 거리감이 있다. 납득되지 않은 명령은 상관에게 설명을 요구하기도 하고 팀원 한명 한명에게 작전 수행의 이유를 최대한 설득하기 위해 최선을 다한다. 목숨이 오가는 전장인 만큼 엄격한 규율을 가지고 있지만 절대 그것이 조직을 경직시키지는 않고 오히려 활발한 소통과 높은 수행 능력으로 나타난다. 장교 출신인 두 저자는 왠만한 회사 업무에 뒤지지 않는 업무량의 PPT를 만들기도 하고 어쩌면 부끄러울수도 있는 본인들의 실수와 잘못된 판단, 리더로써 내린 다양한 결정과 경험들을 최대한 생생하게 전달해준다.

생각해보니 네이비씰 이야기를 처음 읽은 것은 《최고의 팀은 무엇이 다른가》라는 책이었는데 작전 수행 후 회고하고 개선하고 자유롭게 피드백을 주고 받는 모습은 계급이 있고 규율이 있는 조직이라고는 생각하기 힘든 모습이었다. 스타트업이나 애자일 조직에서나 볼 수 있을법한 모습을 군대에서 볼 수 있다니.

군대는 커녕 작은 조직에서도 팀장이나 대표에게 쉽게 물어보지 못하는 사례를 너무 많이 보았고 팀장이나 대표인 사람들도 그런 직원에게 충분한 설명을 해주기는 커녕 화만 내는 경우가 대부분이었다.

책은 이라크전 당시 작전, 그것에서의 교훈, 그리고 그 교훈에 기반하여 기업들의 문제를 컨설팅해준 사례들로 구성되어 있다. 리더십을 말한다고 해서 꼭 리더 자리에 있는 사람만 볼 책은 아니다. 이제 일을 시작한 신입이나 대학생, 부부, 중간관리자 등 다양한 분들에게 이 책을 추천한다. 어쩌면 다른 사람과 관계가 생기는 모든 곳에서 이 책의 지침들은 유효한 것 같다.

내 얘기

일단 책을 읽는 내내 부끄럽고 반성하는 시간이었다. 혼자서 사업을 시작해서 투자도 받고 20명 가까운 팀원들과 함께하다가 다시 혼자가 된 지금, 나의 경험 속 내 리더십은 실패의 연속이었다. 상황을 탓하기도 하고 팀원들을 탓하기도 했다. 그리고 내 리더십이 실패했다고 생각한 순간, 실패한 사실만 있을뿐 그러면 이제 어떻게 해야하지? 라는 답변을 얻지 못했던 것 같다. 항상 책을 읽으며 하는 후회가 바로 이것이다. 그때 이 책을 읽었더라면.

나는 항상 내가 옳다고 생각하지는 않았지만 그나마 내가 바르게 보고 있다고 생각했다. 그리고 팀원들이 내가 바라보는 방향을 쉽게 이해하지 못할때면 답답해하고 그들을 닦달하기도 했던 것 같다. 그리고 결과가 좋지 않으면 내 책임이라고 말하면서도 마음 속 깊이는 팀원들의 능력 부족을 탓하기도 했다. 겸손하지도 못했고 자만했으며 어리석었던 과거의 내 모습이 이 책을 통해 계속해서 마주하게 되었다.

이런 지침서를 읽으면 (또는 자기계발서류) 나는 이래라, 저래라 해봤자 누구나 할 수 있는 얘기 아니야? 직접 이 상황을 겪어보면 너도 쉽지 않을걸? 같은 생각을 하게 되는데 네이비씰과 목숨이 오가는 특수한 전장에서의 경험은 그런 나의 오만함을 깨고 책 내용을 신뢰하는 내용들이었다.

책 하나로 바뀌기는 쉽지 않을 것이다. 사람과의 관계, 리더십은 마치 습관과도 같다고 생각한다. 팀원들을 대하는 태도나 상대방에게 말하는 것을 그저 내 감정대로 행동하는 게 익숙한 사람은 그걸 바꾸기가 쉽지 않다. 나도 한때는 그런 적이 있었고 피드백이랍시고, 상대에게 상처를 준 적도 많다. 분명 그것이 잘못된 것을 아는데도 말이다. 왜 알면서도 바꾸지 못할까? 그것이 습관이 되어있기 때문이다. 그리고 그런 행동을 하지 않는다고 바뀌는 것이 아니다. 생각 자체가 바뀌어야 한다.

책에서 말하는 극한의 오너십을 가지고 진심을 다해 그렇다고 생각하면 모든 행동을 하기 전에 내 감정보다는 해결책을 찾게 된다. 그리고 또 그러한 경험이 반복되면 그것이 다시 습관이 되어 내 삶 전반에 더 좋은 영향을 미치게 될 것이다.

극한의 오너십

자신의 임무뿐만 아니라 임무에 영향을 미치는 모든 것을 자기 책임이라고 생각한다는 점이다. 이들은 어떤 경우에도 다른 팀원을 비난하지 않는다. 누군가의 실수로 임무가 실패로 돌아가도 남을 탓하지 않는다. 변명도 하지 않는다. 위기나 장애물을 만나면 불평하는 대신 대안을 궁리해 문제를 해결한다. 맡은 일을 성공시키기 위해 자신이 가진 모든 자산, 인간관계, 자원을 총동원한다. 그리고 자존심을 억누르고 임무와 부하들을 앞세운다. 우리는 이를 ‘극한의 오너십’ 이라고 한다.

모든 문제가 발생했을때 그 책임을 스스로에게 있다고 진심으로 생각하는 것은 생각보다 쉽지 않다. 특히 그것이 다른 사람과 협업, 다른 사람과의 관계에서 일어난 일이라면 더더욱 그럴 것이다. 기본적으로 우리는 나의 잘못을 진심으로 인정하기 보다는 남을 탓하기 쉽고 설사 내 잘못이라고 생각해도 그것을 어떻게 해결해야할지 모른다. 극한의 오너십은 세상에서 컨트롤할 수 있는 것은 결국 나 자신 뿐이다라는 것을 인정하고 목표 달성을 위해 쓸데없는 모든 것을 제거하는 것이다. (나의 감정이나 자존심, 불평불만, 변명 등등)

오너십이 주를 이루는 내용이지만 단순한 목표 설정으로 팀을 단결시키고 팀원을 신뢰하고 역할을 위임하는 법, 그리고 삶의 자세(규율이 곧 자유다)에 대해서도 얘기가 나온다. 또한 책 마지막에 리더십을 타고난 사람도 있지만 여기서 말하는 극한의 오너십은 항상 겸손하고 최선을 다하는 자세, 다른 사람을 진심으로 존중하는 자세를 가지고 노력하면 누구나 가질 수 있다는 것이다.

몇 번 더 읽어볼만한 책이다. 어느 조직에서 일하고 있든 지침이 될 만한 책인 것 같다.

꼭 조직의 리더 자리에 있지 않더라도 모든 관계에서 고민하고 있는 분들에게 추천한다. 그리고 누군가에게 리더십을 바라지 말고 나부터 극한의 오너십을 가지고 행동하자. 리더는 그 사람의 자리가 아니라 그 사람의 행동으로 보여주는 것이다. 그렇기에 누구나 리더가 될 수 있다.

밑줄 친 구절

우리는 ‘하급자가 상급자의 명령을 맹목적으로 따르는 군대의 리더십이 별것 있겠느냐’는 생각도 깨고 싶다. 군대에 몸담은 이들은 영리하고, 창의적이며, 자유롭게 사고하는 개인이다. 그러므로 자신이 싸우는 이유에 대한 신념이 있어야 한다. 지시받은 임무에 대한 믿음, 그리고 자신에게 지시를 내리는 리더에 대한 공감과 신뢰를 가지는 것이 무척 중요하다. 말단 병사를 비롯한 모든 구성원의 의견을 중시하는 네이비씰에서는 더더욱 그렇다.

아군 간 교전이 벌어지면 어떤 후보생들은 스스로 책임을 졌지만, 어떤 후보생들은 책임을 부하들에게 떠넘겼다. 나는 책임을 회피하는 나약한 후보생들에게 지휘에 따르는 무거운 책임을 엄혹하게 가르쳤다. 리더는 ‘모든 것’에 진심으로 무한 책임을 지는 사람이기 때문이다.

자존심 따위는 버리고 실패의 책임을 받아들이며, 팀의 약한 부분을 쳐 내고, 더 나은 팀을 만들려는 노력을 지속적으로 해야 한다. 그런 리더는 팀의 업적을 자신의 것인 양 우쭐대지 않으며, 오히려 그 영광을 기꺼이 부관이나 팀원들에게 돌린다.

뛰어난 성과가 반복되면 습관이 됩니다. 각 조원은 승리하기 위해서는 무엇이 필요한지를 알았고, 실제로 그렇게 했죠. 더 이상 조장의 구체적인 지시가 필요 없는 수준이 된 겁니다. 그 결과 2조는 계속 다른 조보다 좋은 성과를 냈고

어떤 조직에서든 조직의 사명과 구성원들의 믿음이 가지런히 정렬되어 있어야 한다. 어느 단계에선가 정렬이 틀어졌다면 반드시 바로잡고 수정해야 한다. 군대나 기업에서 고위 리더들이 일부러 조직을 망치는 결정을 내리지는 않을 것이다. 하지만 하급자들이 특정한 전략적 결정을 이해하지 못하거나 신뢰하지 못하는 경우는 많다. 그러므로 하위 리더들은 상부에 질문을 던지고 구성원들의 반응을 보고해야 한다. 그래야 상부의 전략적 결정이 일선 현장에서 실제로 어떻게 이행되는지 정확히 파악할 수 있다.

CEO가 자주 하는 착각-직원들은 내 마음을 잘 알고 있다

극한의 오너십은 이런 자존심을 경계하고 겸손해질 것을 요구한다. 실수를 인정하고, 책임을 받아들이며, 위기를 극복할 방안을 마련하는 것은 승리를 위한 필수 요소다. 그러나 자존심을 내세우면 리더가 자기 자신과 팀의 성과를 현실적으로 평가하기 어려워진다.

모든 계획은 팀의 말단 구성원들도 확실히 이해할 수 있게 설명해야 한다. 팀원 일부가 잘 이해하지 못했을 때 질문할 수 있는 환경을 조성하는 것 또한 매우 중요하다. 리더는 자유로운 의사소통을 장려해야 하며, 팀원 전원이 목표를 완벽하게 이해할 때까지 충분한 시간을 할애해야 한다.

전장의 네이비씰 지휘관들은 해야 할 일을 스스로 알아내야 한다. 상급자에게 ‘어떻게 할까요?’라고 묻는 게 아니라 ‘이것을 하겠습니다’라고 말해야 한다. 즉 수동적인 실행자가 아니라 능동적인 지휘관이 되어야 한다는 것이다.

100퍼센트 옳은 해결책은 없고, 완벽하게 선명한 그림도 없다. 리더는 이를 겸허히 인정하고 신속하게 결정을 내릴 줄 알아야 한다. 그리고 상황 변화와 새로운 정보에 따라 신속하게 결정을 수정하고 보완할 태세를 갖추어야 한다. 정보 수집과 연구는 중요하다. 하지만 여기에 너무 큰 기대를 걸어서는 안 되며, 이를 핑계로 신속한 의사 결정을 미뤄서도 안 된다.

나는 규율이 ‘그저 그런 것’과 ‘특별한 것’의 차이를 만든다는 사실을 노련하고 경험 많은 선배들을 보며 체득했다. 부대 내에서 가장 뛰어나다고 평가받는 선배들은 출근도 가장 먼저 했다. 그들은 가장 훌륭한 전투 기술, 가장 잘 정비된 장비, 가장 뛰어난 사격 솜씨를 가지고 있었다.

규율은 자기 통제와 금욕을 요하지만 결국 자유로 연결된다. 아침에 일찍 기상하는 규율이 몸에 배면 더 많은 자유 시간을 보상받는다. 전장에서 늘 헬멧과 방탄조끼를 착용하는 규율을 따르면 장비에 익숙해져 더 자유롭게 움직일 수 있다. 매일 체력을 단련하는 규율을 엄수하면 몸이 더 가볍게 느껴지고 더 빠르게 이동할 수 있다.

DataColon 개발 후기 - 1. 들어가며

Tony Cho (https://flowkater.io) — Fri, 13 Mar 2020 02:03:59 GMT

DataColon 개발 후기

1. 들어가며 (현재 글)
1. 백엔드 편
1. 프론트엔드 편
1. 개발 외 이야기

드디어(?).. 한달여에 걸쳐서 릴리즈를 하게 되었습니다. 첫 커밋이 찍힌 날짜를 보니 1월 26일이니 한달을 훌쩍 넘겼네요.

기존에 Slack 채널과 Notion 을 이용하여 스터디 노트를 전달해드렸는데, 드디어 자체 웹페이지를 만들게 되었습니다.

일단 결과물부터 보시죠.

<a href="https://www.datacolon.io/" target="_blank">https://www.datacolon.io/</a>

(코스나 렉쳐 노트를 보시려면 가입을 하셔야 합니다. ㅎㅎ)

1. 동기

사실 처음에는 컨텐츠가 주가 되는 서비스이기 때문에 자체 개발보다는 강의 플랫폼을 제공해주는 서비스들을 활용해보려고 했습니다. 대표적으로 teachable 같은 서비스가 국내에서 많이 사용되고 있는 것 같고 그 외에도 구글링을 해보면 꽤 많은 강의 플랫폼 서비스들이 존재합니다.

항상 서비스의 핵심(컨텐츠)이 중요하고 개발에 많은 시간을 쏟기 보다는 실제 가치를 발생시킬 수 있는 컨텐츠 제작에 집중해야 하는 건 사업을 해보지 않은 바보도 알만한 사실이었습니다.

그런데.. 이러한 서비스들의 공통적인 문제점이 있었는데 제가 내세우는 학습 가치인 Coverage -> Practice -> Insight 의 핵심이 되는 퀴즈나 문제 시스템이 굉장히 초보적인 수준에서 지원되거나 열악한 시스템을 가지고 있었습니다. 월에 몇십만원까지 하는 서비스도 선결제를 해서 사용해봤는데 모두 다 영상 강의 컨텐츠에 맞추어져 있다보니 제가 원하는 수준으로 구현할 수가 없었습니다. (물론 이 시스템은 아직 프로덕션에 반영되지 않았습니다. 하지만 이제 준비가 되었고 열심히 개발 중입니다.)

또한 결제 시스템 문제가 있는데 제 서비스는 국내 고객들을 타겟팅하는 서비스인데 해외 비자 카드만 지원된다거나 국내 결제로 인한 멤버십 연동 지원이 대부분 안되는 것들이 보통이었습니다.

그리고 데이터 과학 컨텐츠 특성상 수식이 많이 입력되는데 기본적으로 Tex 렌더링을 해주는 강의 플랫폼은 전무했고 차라리 그냥 기존에 Slack 채널과 Notion 을 이용하는게 훨씬 합리적이었습니다. (Notion이 좀 불편하고 불완전한 부분은 있어도 대부분 포맷은 지원하므로..)

또 하나 결정적인 문제점이 있었는데 Slack과 Notion등을 조합한 서비스의 초반 러닝 커브 문제였습니다. IT 업계나 스타트업에서 일하면서 Slack은 카카오톡의 업무 버전으로 쉽게 치환하여 사용하는 우리와는 다르게 대부분 처음 접하는 사람에게는 이 툴 자체가 굉장히 어렵고 힘든 서비스 중 하나라는 걸 뼈저리게 깨달았습니다. Slack 사용의 어려움을 겪어 스터디 신청 하루만에 환불 요청 사례가 나오고 나서부터는 비전공자나 입문자들을 앞으로도 많이 받아야하는 입장에서는 큰 커브 중 하나였죠. Notion도 마찬가지인게.. 사실 그냥 노트앱에 하나이고 굉장히 훌륭한 프로덕트이지만 스터디를 등록한 멤버 입장에서는 뭔가 또하나 깔고 가입하고 공부해야하는 툴에 불과한 러닝 커브라는 것도 알게 되었습니다.

정리를 하자면,

기존 강의 플랫폼들은,

퀴즈-Feedback 시스템의 부재
국내 결제 미지원
Tex 렌더링 미지원

이런 문제들이 있었고, 기존에 활용하던 Slack과 Notino은 입문자들에게는 그것조차 하나의 배워야하는 큰 공포라는 것을 뼈저리게 깨닫게 되면서 자체 플랫폼 개발의 당위성(?)을 찾고 (라고 쓰고 자기합리화라고 읽는다..) 결국 개발에 착수하게 됩니다.

물론 기존에 선형대수학과 통계학 코스가 몇 십명의 스터디원을 거치며 검증이 되기도 했고 단순 강의 제공이 아니라 풍부하게 연습할 수 있는 퀴즈를 통해서 학습의 최적 사이클인 Coverage -> Practice -> Insight이 충분히 가치가 있다는 나름의 확신도.. 잠깐 컨텐츠를 내려놓고 개발을 집중하는데 큰 힘이 되었습니다.

2. 배경

데이터 분석을 위해 사용하는 Python과 서버 개발을 위한 Python은 그 궤과 다릅니다. 모델 서빙이나 간단한 서버리스 처리를 위해 Flask (Zappa)를 이용하여 심플한 API를 개발했었고 회사 자체 CMS나 백오피스 시스템으로 활용할때 간단히 이용한 것 외에는 경험이 없었습니다. 물론 과거에 Rails로 백엔드 개발하기도 했고 소프트웨어 마에스트로 최종 인증하고 처음 앱을 런칭할때도 Rails로 다 먹고 살았지만 그마저도 투자를 받고 팀이 커지면서 서버 개발자가 들어오고 나서부터는 아예 손을 똈었죠.

특히, Rails 프레임워크를 몇 년 쓰면서 풀프레임웤에 대한 질림(?) 때문에 그 뒤로는 간단히 개발할때 Flask, Express 등의 경량 웹프레임워크만 선호했었고 개발팀에게도 그것을 추천했었습니다.

하지만 결국 Flask 등의 경량 웹프레임워크로 프론트엔드까지 서비스의 다양한 부분을 혼자서 개발하기엔 어렵다는 판단을 내렸고 결국 Django를 선택하게 됩니다. 그리고 다시 풀프레임웤의 고마움(?)을 많이 느꼈네요.

프론트엔드는 원래 Django를 선택하면서 Template을 쓰려고 했으나 Template 또한 하나의 시스템이고 그걸 위에 배워야하는 규칙이 꽤 존재한다는 것을 깨닫고 바로 접고 React로 프론트엔드를 선택합니다. 이전에 운영하던 앱 서비스의 내부 어드민, 대쉬보드 패널, 백오피스 프론트엔드 등을 자주 리액트로 만들었기 때문에 선택을 했습니다.

결국 Django로 백엔드를 React로 프론트엔드를 개발하게 되었는데.. 가장 중요한 프로토콜을 기존 API 시스템으로 할지 GraphQL로 할지 5초간 고민하다가 바로 GraphQL을 선택하게 되었습니다. 사실 Django도 처음이고 Django에서 GraphQL을 어떻게 구현해야하는지 전혀 몰랐지만 React에서 Apollo의 강력함을 맛보고 초기 입문시절때 React + Typescript + Redux + Saga 조합으로 Redux 타입 지옥에 빠져서 너무 괴로웠던 기억이 있었고 React Hook의 강력함과 Apollo가 결합되어 엄청난 생산성과 심플한 코딩 작업을 경험한 터라서 망설이지 않고 선택을 했습니다.

여튼 이렇게 스택을 정하는 과정이 여차 저차에서 약 1주일 정도 걸렸던 것 같네요.

정리를 하자면,

백엔드: Django + Grpahene (Python GraphQL Schema 지원)
프론트: React + Typescript + Apollo

서버 인프라는 AWS, 배포를 위해서 Elastic Beanstalk을, RDS는 MySQL로, CDN은 Cloud Front (+S3)를 이용하되 프론트 배포 자체는 이 블로그와 같이 netlify를 이용해보았습니다. S3를 안쓰고 netlify를 쓴 이유는 무엇보다 배포의 편리함이 압도적이였고 불가피하게 성능에 영향을 주는 큰 Asset 들은 대부분 AWS CDN 처리를 했습니다.

3. 들어가며

비개발자인 디자이너 분과 개발자인 저 혼자서 한달여간 삽질해가면서 프로덕션 단계의 프로젝트를 진행해나가는게 쉽지는 않았고 거의 막바지 2주동안은 새벽 4시 퇴근이었던 것 같습니다. 블로그도 작년 하반기에 만들어놓고 거의 손놓고 있었고 일주일 3회는 하던 운동도 막바지 2주동안은 한번 밖에 못갔었네요. 이 글을 쓰면서 한번 정리를 하고 다시 바이오리듬도 맞추고 프로세스를 정비하고 다시 일을 해볼려고 합니다. (과연..?)

다음 두 편은 조금 더 구체적인 개발 스택 얘기를 적도록 하겠습니다. 아마 백엔드 편과 프론트엔드 편이 될 것 같네요. 아직 현 시점(2020년 3월)에서는 국내에서 GraphQL을 많이 도입하지는 않은 상황이라 구글링을 하다가 발견한 누군가의 큰 도움이 되길 바라며 다음 편도 빠르게 작성해서 올리겠습니다.

React Typescript Setup Tutorial - 2. Styled Components 세팅하기

Tony Cho (https://flowkater.io) — Tue, 17 Dec 2019 09:12:59 GMT

Styled Components

Styled Components는 대표적인 CSS-in-JS 라이브러리이다. 따로 CSS 파일을 두지 않고 React Component 내에 Javascript와 같이 스타일링 코드를 적용한다.

예를들면 다음과 같다.


import React from 'react'
import styled from 'styled-components'


function TodoList() {
	return <TodoListBox>/* 생략 */</TodoListBox>
}



const TodoListBox = styled.div`
	position: relative;
	height: 100%;
	background-color: ${props => props.theme.color.main};
	overflow-y: scroll;
	min-width: ${props => props.theme.basicWidth};
`

최근들어 React 프로젝트 대부분 적용되는 방식이며 이렇게 CSS-in-JS 방식을 이용하면 React Native 와도 스타일링 코드를 대부분 공유할 수 있다는 장점이 있다.

특히 나처럼 CSS 코드 초보인 사람은 CSS 파일에 스타일링하다보면 그 난해함에 난감한 경우(중첩되거나 덮어씌워지거나 등등)가 많은데 분리하여 그 컴포넌트에만 집중하여 스타일링을 하니 네이밍을 정하는 것도 간단하고 쉽게 스타일링을 할 수 있어서 좋은 것 같다.

대신, React Typescript 프로젝트에 적용하려면 그 전에 몇가지 해주어야 할 세팅이 있는데 그에 대해서 간단히 정리해보았다.

Setup


yarn add styled-components @types/styled-components

기존에 styled-components 라이브러리 추가 후에 Theme 을 활용하기 위해 따로 styled-components.ts 파일을 만들어서 선언을 해주었어야 했는데 @types/styled-components 가 추가된 이후로는 그럴 필요가 없고 직접 추가를 해주면 되는 것 같다. React Native에서는 이전 방식대로 해주어야 하는 것 같으니 참고하자.

Styled Components Typescript Api Doc 참고

총 세가지 파일을 만들건데 나는 src/ 경로에 styles 라는 폴더를 따로 만들고 모아두고 활용한다.

src/styles/styled.d.ts
src/styles/theme.ts
src/styled/global-styles.ts

styles/styled.d.ts


// src/styles/styled.d.ts

import 'styled-components';

declare module 'styled-components' {
	export interface DefaultTheme {
		basicWidth: string;
		color {
			main: string;
			sub: string;
		}
	}
}

Typescript에는 module을 declare module을 이용하여 extend하는 방법이 존재한다.

해당 방법을 이용하면 코드가 합쳐지는데 Style Components 에서 제공되는 ThemeProvider를 활용하기 위해서 interface를 추가해주는 것이다.

이 테마 선언 기능은 혼자서 작업하거나 초반에는 그렇게 쓸모가 없지만 컴포넌트가 복잡해지거나 잘 기획된 디자인 시스템(테마/프리셋)을 바탕으로 개발한다면 자주 사용되는 요소들 색깔부터 길이까지 정의를 해놓으면 props로 바로 쓸수가 있다.

기존의 sass의 mixin 변수와 비슷한 기능을 하는데 요즈음 특히 다크 모드 등 다양한 테마를 지원해야 하는 환경에서 특히 유용하게 활용될 수 있을 것 같다.

styles/theme.ts


// src/styles/theme.ts

import { DefaultTheme } from 'styled-components';

const theme: DefaultTheme = {
	basicWidth: '320px';
	color {
		main: '#1c1f25';
		sub: '#fff';
	}
};

export { theme };

앞에서 정의한 테마 interface의 실제 테마를 구현하는 곳이다.

지금은 프로젝트 초반이라 테마가 하나밖이라 그냥 theme이라고 변수로 두었는데 나중에 basicTheme, darkTheme 이런 식으로 각각에 맞는 테마 구현체를 두고 export를 해서 사용할 수 있을 것이다.

해당 theme은 ThemeProvider를 이용해서 적용할 수 있는데 여기서는 App Component에 적용해보았다.


// src/App.tsx

import React from 'react'
import { Route, Switch } from 'react-router-dom'
import MainPage from './pages/MainPage'
import AboutPage from './pages/AboutPage'
import { theme } from './styles/theme'
import { ThemeProvider } from 'styled-components'

function App() {
	return (
		<ThemeProvider theme={theme}>
			<Switch>
				<Route exact={true} path="/" component={MainPage} />
				<Route exact={true} path="/about" component={AboutPage} />
			</Switch>
		</ThemeProvider>
	)
}

export default App

styles/global-styles.ts

먼저 전역적인 Global Style을 지정하기 전에 normalize.css를 적용해줄 예정이다.

각 브라우저마다 기본적으로 들어가는 스타일링이 있어서 그것에 따라 브라우저마다 약간의 차이를 보이는데 CSS 코드가 복잡해지면 그 차이가 심하게 두드러지는 경우가 많다.

특히 디자인이라는 것이 미묘한 차이가 큰 차이로 나타나기 때문에 이걸 통일 시켜주는 것이 좋은데 그럴때 reset.css 또는 normalize.css를 쓰는 것이 좋다.

둘의 차이점은 아래 링크를 통해 확인해보고 여기서는 normalize.css를 활용해볼 것이다.

찾다보니 normalize.css를 직접 import 하지 않고 styled-normalize 라이브러리를 이용하여 createGlobalStyle API를 이용하여 프로젝트 전체의 스타일링을 지정해줄 것이다.

yarn add styled-normalize

// src/styles/global-styles.ts

import { createGlobalStyle } from "styled-components";
import { normalize } from "styled-normalize";

export const GlobalStyle = createGlobalStyle`

${normalize}
	html,
	body {
		overflow: hidden;
	}

	* {
		box-sizing: border-box;
	}
`;

이렇게 정의된 스타일을 index.tsx 에서 컴포넌트처럼 적용하면 된다.


// src/index.tsx

import React from 'react'
import ReactDOM from 'react-dom'
import { BrowserRouter } from 'react-router-dom'
import App from './App'
import { GlobalStyle } from './styles/global-styles'

ReactDOM.render(
	<BrowserRouter>
		<GlobalStyle />
		<App />
	</BrowserRouter>,
	document.getElementById('root')
)

적용

앞에서 본 TodoList 컴포넌트이다.


// src/components/TodoList.tsx

import React from 'react'
import styled from 'styled-components'

function TodoList() {
	return <TodoListBox>/* 생략 */</TodoListBox>
}

const TodoListBox = styled.div`
	position: relative;
	height: 100%;
	background-color: ${props => props.theme.color.main};
	overflow-y: scroll;
	min-width: ${props => props.theme.basicWidth};

`

마무리하며

React Typescript 환경에서 간단히 Styled Components를 적용하는 작업을 해보았다.

컴포넌트가 복잡해지면 잘 분리해서 각각의 스타일링을 적용해주면 기존에 CSS 코드 때문에 헤매는 일이 많이 줄어들 것이다.

예전 Legacy 프로젝트들이 대부분 SASS를 활용한 스타일링 시스템이라서 코드 작업을 하면서 마이그레이션하는 것에 조금 애먹고있긴 한데 한번 세팅하고 옮기기 시작하니 생각보다 생산성이 좋다. 특히 분리되어 있으니 컴포넌트 내에서만 중복되지 않으면 네이밍에 그렇게 힘쓰지 않아도 된다는 점도 마음에 든다.

역시 프로그래밍 생산성의 길은 잘 분리하고 일반화하는 것에 있는 것 같다.

인공지능 투자가 퀀트- 알고리즘, 세계 금융시장을 침공하다

Tony Cho (https://flowkater.io) — Sat, 14 Dec 2019 07:12:59 GMT

제프 베조스는 90년대에 퀀트였다?

“아마존, 세상의 모든 것을 팝니다.”를 읽었을때 흥미로웠던건 중 하나가 제프 베조스가 프린스턴 대학 졸업 후 퀀트 헤지펀드 회사 D.E. 쇼 앤 컴퍼니에서 컴퓨터 기술을 활용한 회사에서 일을 하다가 나와서 아마존 창업한 초기 스토리를 읽었었다. 90년대 초에 퀀트, 그것도 컴퓨터 자원과 알고리즘을 활용했다고 하니 제프 베조스의 비범함, 그리고 역시 미국이라는 생각이 들었다. 해당 스토리는 책에서도 한번 더 언급되기도 하는데 지금이 19년, 곧 2020년이라는 걸 생각하면 거의 30년에 가까운 세월동안 이미 미국 월스트리트에서는 인공지능 알고리즘 개발 역사가 있다는 것이다.

퀀트에 대해서는 들어보긴 했지만 그때부터 본격적으로 궁금해지기 시작했다. 나도 인공지능 좀 공부해봤는데.. 도대체 돈을 어떻게 번다는거야?

내 얘기

내가 제일 처음 인공지능에 관심을 가지게 된 것이 11년도 Udacity 세바스찬 쓰런 교수의 자율 주행 자동차 강좌 소개 영상이었는데 그것도 벌써 8년이 넘었다. 그 사이에 수학부터 데이터 분석, 머신러닝, 통계학까지 차근차근 공부를 하다보니 공부 그 자체가 너무나도 재밌었지만 머신러닝이나 딥러닝이 만능이 아니라는 것, 오히려 간단한 통계분석과 몇가지 분석 자동화만으로도 충분히 가치를 낼 수 있다는 것도 역으로 많이 깨달았다. 특히 스타트업 서비스를 운영하고 기획하는 입장에서 기술 맹신주의에 빠져 모든 걸 최신 기술에만 의존하기 보다 진정한 고객 가치가 발생하는 부분을 파고들어 밑바닥부터 작은 것부터 만들어가는게 중요하다는 것을 많이 느꼈다. 그게 중요하다면 처음에는 손으로라도 해야하는 것이다. 자동화나 기술 도입은 그 가치가 충분히 입증되거나 데이터가 있다면 그 다음에 해도 충분하다.

(자기가 정말 딥러닝 연구만 하고 싶고 기술 자체가 좋다고 하는 분들은 수준 높은 IT 대기업 연구팀을 들어가는게 좋을 것이다. [카카오AI리포트]세상을 바꾸고 싶다면,딥러닝_김남주 이런 글도 있으니 읽어보고..)

정리하자면 막상 공부를 했는데 내가 하는 프로젝트에서는 많이 활용될 수가 없더라. 데이터도 없을 뿐더러 분석이야 굳이 머신러닝까지 안거쳐도 가공만 잘해도 꽤 괜찮은 고객 만족도를 보여줄 수 있었다. 이걸 어떻게 써먹나 하면서 평소에 고민하다가 관심이 간 것이 바로 퀀트였다.

비트코인 투자로 돈만 날려봤지 주식은 해본적도 없고 관심을 가진 적도 없었다. 한참 돈이 궁해서 “머니”라는 책을 읽었었는데 최근에야 ETF 투자, 채권, 인덱스 펀드 등의 단어를 알게 되었다. (사실 아직도 잘 모른다.)

수리통계학에서 조금 심화된게 계량 경제학인데 나름 통계학을 공부하기도 했고 관심도 많았는데 그런 지식을 활용해서 나만의 돈 버는 봇을 만든다? 그리고 최근에는 머신러닝까지 활용하고 심지어는 강화학습까지? 솔깃할 수 밖에 없는 이야기였다.

하지만 국내 기술 서적들이 대부분 그렇듯이 주식 거래소 종목 크롤링하는 정도로 퀀트 개발서적이라고 떡하니 출판된게 대부분이라 일도 바쁘고 해서 잠깐 관심의 저편으로 넘어갔었다.

그러다가 발견한게 바로 이 책 “인공지능 투자가 퀀트: 알고리즘, 세계 금융시장을 침공하다” 이다.

책 추천

이 책은 모든 분들께 추천한다. 인공지능에 관심이 없어도 주식 트레이딩이나 금융에 관심 없어도 그냥 재밌다. 빅쇼트 같은 영화를 보고 좋아했다면 더더욱 취향에 맞는 책이 될 것이다.

퀀트가 생기기 시작한 역사(그 시작은 도박과 확률 게임이었다)부터 한국인 유학생인 저자 본인이 처음 투자 은행 퀀트팀에 입사하여 퇴사할때까지 스토리를 굉장히 몰입감있게 다이나믹하게 풀어놨다. 아마 대부분 리뷰를 쓰신 독자분들의 공통된 의견이 이 부분에서 정말 시간 가는 줄 모르고 책을 읽었다고 하더라.

저자는 인턴/신입 시절부터 퀀트 개발자 역할을 맡아서 트레이딩 속도를 최적화하고 시뮬레이션 시스템을 만들었다가 월스트리트의 폭풍같은 사건들이 지나가면서 직접 본인만의 알고리즘을 만들고 그걸로 성과를 내는 과정까지 정말 경험하지 않았다면 알 수 없는 디테일한 이야기와 월스트리트 사내 정치, 산업 스파이 이야기까지, 정말 2장은 월스트리트를 배경(사내 정치 스릴러)으로한 개인의 성장 스토리를 담아내어 계속 다음편이 궁금해지는 미드를 보는 것 같았다.

하지만 이 책의 역할은 무엇보다 ‘학구열 뽐뿌’에 있다. 다시 수학책을 펼치고 식었던 학구열을 불태워주게 한다. '와 이렇게 똑똑한 사람들이 이렇게 치열하게 연구하고 고민하고 생활하고 있구나.’ 하면서 그래도 나름 공부했다고 나이브하게 생각한 나에게 많은 자극을 주었다.

특히, 처음에 투자은행 신입 인턴 면접을 보는 과정을 상세하게 써놓았는데 그것이 너무 좋았다. 단순 암기 문제부터 통계, 알고리즘 등의 여러가지 면접을 보는 과정들과 질문들을 상세하게 써놓은게 너무 좋았다.

(1단계 면접이 단순히 두자리 수 곱셈 암산부터 기대값 구하는 문제를 굉장히 빠른 시간 안에 즉각적으로 대답해야 한다는 것이 인상적이었다. 그리고 2단계, 3단계에서 수학, 통계, 알고리즘에 대한 상세한 질문들도 나열되어있으니 이것이 궁금하면 책을 꼭 읽어보자.)

그 과정에서 수학이나 통계를 정규대학에서 아카데미컬하게 훈련을 받은 것이 또는 혼자 공부하더라도 개념의 이해만 대충되면 넘어갈게 아니라 열심히 문제풀이하고 어려운 문제 풀고 어떨때는 기계적으로 문제 풀이 훈련을 할 필요가 있다는 것을 다시 한번 느끼기도 했다.

정말 재밌게 읽은 책이고 동기부여가 되어 이번을 계기로 시간날때마다 관련 공부도 계속해보려고 한다. (이 책을 읽던 중 해당 저자가 퀀트 실습 교육을 한다고 해서 바로 선착순 신청까지 했다.)

(저자의 브런치가 원래 유명했다고 하니 여기 글도 읽어보려고 한다.)

그리고 최근에는 국내 로보어드바이저 스타트업들 AIM, Fint, 헤이비트 등의 자료들도 찾아보고 소액으로 투자하면서 봇이 어떻게 트레이딩을 하는지도 보고 있다.

또 재밌는 걸 발견했는데 이런 저런 자료를 찾아보다가 한때 수험생 커뮤니티로 이름을 날렸던 오르비라는 곳에서 Sindbad 라는 강화학습 AI 를 이용해서 주식 투자로 수익을 내고 있다고 한다.

(이 책의 마지막에도 강화학습을 적용해보려고 하는 회사에 대한 이야기였는데 국내에도 이런 곳이 있었다.)

마무리하며

최근에 고등학교 친구 셋과 연말 모임을 가졌다. 이제 다들 직장에서도 안정화가 되었고 한 명은 벌써 애기까지 있는 애아빠다. 30을 갓넘은 아재들이 모이니까 정말 부동산, 주식같은 이야기를 하고 있더라. 하다보니 퀀트 이야기도 하게 되었고.. 재작년에 모였을때 비트코인 투자 이야기로 밤샘을 했으니 어찌보면 공통된 이야기인 것 같기도 하다. 바로 돈 이야기.

결론이 재미나게 났는데 돈 없다고 한탄하지 말고 어쨋든 내 공부해서 내 앞길 스스로 살펴가자, 어차피 인생에 정답은 없으니 항상 겸손하게 배우자, 우리처럼 없는 놈들은 공부라도 해야된다 라는 얘기로 결론이 났다. (그 후에 내가 이 책을 카톡방에 추천을 해주었다.)

지금은 프론트 개발에 내가 업무 집중도를 높여야하는 시기이지만 조금 더 시간을 내서 관련 공부를 열심히 해볼까한다. 결국 데이터를 수집해서 분석하고 패턴을 발견하고 더 좋은 결과를 내기 위해 승률 높은 기회에 투자하는 것은 내가 무언가 구매를 할때, 회사에서 마케팅을 할때, 운동을 할때 등등 어쩌면 데이터 분석을 통해서 얻으려는 본질은 모두 똑같다는 생각이다.

통계학이 기초가 되어 다양한 분야에 적용가능하듯, 그것에서 조금 더 나간 데이터 분석, 또는 이러한 퀀트 분야의 공부가 꼭 그 분야에만 한정된 것이 아니라는 것이다.

어쨋든 공부하면 내 것으로 남는 거니까.

밑줄 친 구절

전부 다 통계대로 움직이는 것은 아니었지만 짧은 시간 동안 벌어진 틈만 탐지해 거래했기 때문에 일단 벌어진 틈을 찾기만 하면 확실한 수익으로 돌아왔다. 그들은 이러한 전략을 통계적 차익거래(Statistical Arbitrage)라고 부르기 시작했다.

‘모든 주식은 무작위이고 절대로 예측할 수 없다’라는 기존 경제학자들의 통념을 뒤집고 ‘주식은 잠깐의 정보 차이로 틈이 생기고 이를 찾으면 돈을 벌 수 있다’라는 혁명적인 시각을 보여준 것이 더더욱 대단

인공지능에 사용된 가장 대표적인 기술은 히든 마코프 모델(Hidden Markov Model)이라는 것이었다.

이제 시장에서 활동하는 퀀트는 몹시 다양해져 하나로 정의하기도 어려워졌다. 기업의 수익이나 브랜드 가치를 수치화해서 일반적 투자를 하는 퀀트, 에드 소프나 피셔 블랙처럼 평가가 어긋난 파생상품을 거래해서 돈을 버는 퀀트, 뱀버거처럼 다른 주식과의 관계를 파악하는 인공지능을 이용해 거래하는 퀀트, 영향을 주는 요인 분석을 하는 피터 멀러 같은 퀀트, 패턴 인식 기술과 머신러닝을 도입한 사이먼스 같은 퀀트 그리고 시장 충격을 찾아 극초고속 컴퓨터로 돈을 버는 알고 트레이더까지. 이들은 서로의 방식대로 작동하는 인공지능을 가지고 시장에서 돈을 벌기 위해 전쟁을 하기 시작했다. 당연히 이를 혼합한 퀀트도 탄생했고 다른 알고리즘의 행동 양식만 알아내서 그대로 따라하거나 반대 거래로 공격하는 알고리즘 헌터도 생겨났다.

샤프 지수는 ‘1의 위험을 감당했을 때 얼마나 많은 수익을 낼 수 있는가’를 이야기한다

데이터 분석에서 중요시하는 부분 중 하나가 시각화다. 수치로 있을 때는 잘 몰랐던 상관관계나 핵심 추세도 시각화를 하면 눈에 보일 수 있다.

“거대한 데이터가 있고, 연구 플랫폼이 있고, 시뮬레이션 시스템이 있다. 팀의 수익률에 연연해 하지 마라. 너의 알고리즘을 만들어라. 어차피 밖으로 나가도 퀀트가 믿을 건 이전 회사의 수익률도 아니고 인맥도 아니다. 오직 너의 알고리즘뿐이다.”

통계 지식 같은 경우 최소한 선형 회귀나 확률론 정도는 확실히 익혀두어야 하고 데이터에 대한 통계적 상태를 추출할 줄 알아야 한다. 데스크 퀀트처럼 파생상품 설계를 직접 하는 경우에는 푸리에 변환, 편미분 방정식, 실해석학 등 고급 수학을 요구하지만 퀀트 트레이더처럼 시계열이 더 중요한 직종 같은 경우에는 고급 수학 지식을 많이 쓰진 않는다. 오히려 데이터 분석과 관련된 지식이 더 중요한 편이다. 물론 수학 지식을 적용시켜서 자신만의 방법을 구축하는 수학 고수 퀀트 트레이더도 굉장히 많다. 다만 필수가 아니라는 것이다.

데이터를 읽고 의미 있는 결과로 바꾸는 것이 워드 프로세서 능력만큼 대중화되고 필수적인 능력이 될 것이다. 인공지능의 시대에서 무조건 인공지능이 모든 것을 지배하는 게 아니다. 인공지능이라는 것은 학습과 데이터를 기반으로 하며 이 모든 것들은 데이터 과학자가 어떤 선생님이 되냐에 따라서 천차만별인 결과를 가져온다.

책 속의 추천 책

《프로야구 명감독이 주식 투자를 한다면》
《문병로 교수의 메트릭 스튜디오》

린 고객 개발을 위한 고객 인터뷰 기본 질문 5가지

Tony Cho (https://flowkater.io) — Mon, 02 Dec 2019 09:12:59 GMT

우리는 기획을 하거나 제품을 개발하는 단계에서 항상 고객의 니즈와 나의 니즈가 일치할 것이라고 속단하는 오만을 부린다. 나 또한 그래왔고 이론적으로, 머리로는 아니라는 것을 알면서도 어느 순간 숲을 보지 못하고 현재하는 업무에 매몰되어 오만한 나를 발견하곤 한다. 그리고 뒤늦게 잘못되었다는 것을 깨닫고 많은 비용(돈, 시간..)을 지불하고 난 후에 다시 한번 깨닫는 연속이었던 것 같다.

그래서 이번에도 나름의 솔루션은 기획했지만 너무 제한을 두지 말고 내가 풀려는 문제가 조금 더 확실한 문제가 있는 건지, 우리가 빠르게 솔루션을 개발하기 위해 우선 순위를 어디에 두어야 하는지, 그리고 정말 우리 고객들이 그런지 알고 싶어서 설문을 준비를 하게 되었다.

학교에서 여론조사라는 과목을 공부하면서 잘못 설계된 질문과 의도된 질문이 얼마나 편향된 답변 결과를 얻는지 여러 사례를 통해 알지만 팔은 안으로 굽는다고 처음에 내가 생각한 솔루션에 기반하여 정해진 답변을 유도하는 아니면 너무 지엽적인 질문을 만드는 나 자신을 다시 발견하게 되었다. (발전이 없다. 정말..)

그래서 이번에 새로운 서비스 런칭 준비를 하면서 다시 한번 기초로 간다는 생각으로 여러 책을 다시 꺼내서 찾아보았다. 그 중에서 린 시리즈 책들이 확실히 유용한데 그 중에서 최근에 고객 설문을 준비하면서 '린 고객 개발' 책에서 정리한 고객 인터뷰에 대한 내용을 다시 정리해보았다.

해당 내용은 해당 책의 4장 "무엇을 배워야 하는가?" 파트이며 새로운 사업(서비스)을 기획하고 있거나 비용을 최소화하고 고객검증을 하고 싶다면 **'린 고객 개발'**을 추천한다. 고객을 알려면 고객을 만나야 한다. 그런데 그냥 만나서는 안된다. 우리가 원하는 결과는 사업의 가능성, 제품의 추가 기능 개발 우선순위 등을 파악하여 다음 의사 결정을 하는 것이다. 어떻게 그럼 그 데이터를 객관적으로 잘 쌓고 어떤 질문을 해야 올바른 질문인가? 사업계획서용 시장 크기 조사 따위보다 실전에서 훨씬 유용하고 당장 활용가능한 다양한 팁들이 있으니 꼭 한번 읽어보는 것을 추천드린다.

(책은 꼭 순서대로 읽을 필요가 없다. 구체적인 방법을 소개하다보니 아주 지엽적인 부분도 있기 때문에 필요한 부분만 골라서 읽고 필요할때마다 정리해놓자.)

린 고객 개발을 위한 고객 인터뷰 기본 질문 5가지

왜 고객들은 자신이 무엇을 원하는지 모르는가?
집중해서 들어야 할 점과 고객의 반응을 유도해야 하는 부분은 무엇인가?
객관적 질문으로 주관적 답변을 얻으려면 어떻게 해야하는가?

고객 인터뷰 시 기본 질문 5가지

오늘 ~을 어떻게 하셨는지 말씀해주십시오.
~을 완료하기 위해서 쓰시는 [ 도구/제품/앱/요령 ]이 있습니까?
만약 마법 지팡이를 휘둘러서 오늘 할 수 없는 일을 아무것이나 할 수 있다면 무엇을 하고 싶으십니까? 실제로 가능한 일인지는 걱정하지 마시고 아무 일이나 말씀하셔도 좋습니다.
마지막으로 ~을 하셨을 때, 그 일을 시작하기 직전에 뭘 하고 계셨습니까? 그 일을 마치고 나서는 뭘 하셨습니까?
~에 대해서 제가 더 여쭤봤으면 하는 것이 있나요?

위 5가지 질문이 모든 인터뷰의 기본 뼈대이다. 각각의 도메인에 맞추어서 살짝 변형을 하고 각각의 질문에 답변에 대해 다음과 같이 개방형 질문을 통해서 조금 더 구체적인 답변을 이끌어내는 것이 좋다.

그 프로세스가 어떻게 진행되는지 좀 더 자세히 설명해주시겠습니까?
그 결정을 내리는 데 관여하는 사람은 누구인가요?
마지막으로 ~을 마치는 데 얼마나 걸렸습니까?
~을 살 때 주로 어디로 가시나요?
왜 그런 결론을 내리셨는지 여쭤봐도 될까요?

고객은 자신이 무엇을 원하는지를 모른다

자신이 무엇을 원하는지 알아내는 것은 고객이 할 일이 아니다. _스티브 잡스

고객은 자신에게 익숙하지만 결과가 의도만큼 좋지는 못한 방법론을 알고 있다.

-> 우리는 자신이 특정한 기술이나 프로세스에 익숙하지 않으면 앞으로 잘 나서지 못한다. -> 도구나 프로세스에 능숙하다고 해서 그 작동원리까지 이해하는 것은 아니다. -> 도구나 프로세스의 원리를 이해하지 못해도 사용은 능숙하게 할 수 있다.

고객들에겐 해결책을 물어보면 안된다.

문제를 문제로 인식하지 못함
- 기능적 고착 → 문제를 해결하기 위해 어떤 사물을 새로운 방법으로 사용하는 시도에 방해가 되는 심리적 장애
기술적으로 무엇이 가능한지 잘 모르고 있음
- "실제 가능한지 아닌지는 잊어버리세요. 마법의 지팡이를 휘둘러서 어떤 문제든 해결할 수 있다면 무엇을 하실 건가요?"
제한된 자원 (환경, 시간, 예산)
- 어떤 자원이 부족한지 파악
행동을 제한하는 문화적, 사회적 기대

집중해서 들어야 할 점

고객이 어떻게 행동하고 있는가?
고객의 행동과 선택에 영향을 미치는 제약조건들
고객에게 동기를 부여하거나 고객을 좌절시키는 것들
여러분의 고객이 어떻게 결정을 내리고, 돈을 쓰고, 가치를 결정하는지

고객이 이미 하고 있는 행동

고객은 무슨 일을 할 수 있는가?
고객이 무슨 일을 할 때 편안함을 느끼는가?
고객이 어떤 결정을 내리고 있는가?

고객의 현재 행동이 우리의 경쟁 상대

~을 어떤 방법으로 하시는지 말씀해주세요.
~을 사용하시는 방법을 차례대로 보여주세요.

미래가 아니라 과거 또는 현재에 집중하라

지난번에 ~와 같은 것을 사용하셨던 경험에 대해 들려 주십시오.
지난달에는 ~ 상황이 몇 번 일어났습니까?
마지막으로 ~가 일어났을 때, 여러분의 회사에서 얼마의 비용을 지불했습니까?
마지막으로 중대한 결정을 하셨을 때, 가족들이 어떻게 받아들였습니까?

React Typescript Setup Tutorial 1. Apollo 세팅하기 (작성 중..)

Tony Cho (https://flowkater.io) — Fri, 22 Nov 2019 07:11:59 GMT

기본 개발 환경 구축

create-react-app sample-client --typescript

yarn add apollo-boost graphql react-apollo

// apollo.ts

import ApolloClient, { Operation } from "apollo-boost";

const client = new ApolloClient({
  uri: "http://localhost:4000/graphql",
});

export default client;

// index.tsx

import React from 'react'
import { ApolloProvider } from 'react-apollo'
import ReactDOM from 'react-dom'
import client from './apollo'

import App from './App'

ReactDOM.render(
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>,
  document.getElementById('root')
)

import ApolloClient, { Operation } from "apollo-boost";

const client = new ApolloClient({
  clientState: {
    defaults: {
      auth: {
        __typename: "Auth",
        isLoggedIn: Boolean(localStorage.getItem("authToken")),
      },
    },
    resolvers: {
      Mutation: {
        logUserIn: (_, { token }, { cache }) => {
          localStorage.setItem("authToken", token);
          cache.writeData({
            data: {
              auth: {
                __typename: "Auth",
                isLoggedIn: true,
              },
            },
          });
          return null;
        },
        logUserOut: (_, __, { cache }) => {
          localStorage.removeItem("authToken");
          cache.writeData({
            data: {
              auth: {
                __typename: "Auth",
                isLoggedIn: false,
              },
            },
          });
          return null;
        },
      },
    },
  },
  request: async (operation: Operation) => {
    operation.setContext({
      headers: {
        "X-User-Token": localStorage.getItem("authToken") || "",
      },
    });
  },
  uri: "http://localhost:4000/graphql",
});

export default client;

Reference

https://velog.io/@zansol/%EC%A3%BC%EB%8B%88%EC%96%B4%ED%83%88%EC%B6%9C%EA%B8%B0-Apollo-Client-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0
https://www.daleseo.com/graphql-react-apollo-client/
https://medium.com/@han7096/graphql-%EA%B3%BC-apollo%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%B4%EB%B3%B4%EB%A9%B0-%EC%A4%91%EA%B0%84-%EC%A0%95%EB%A6%AC-42981522b188

[[<React Typescript Setup Tutorial> 2. Styled Components 세팅하기]]

비전공 통계학 입문자들을 위한 스터디 교재 & 교양 서적 추천

Tony Cho (https://flowkater.io) — Tue, 19 Nov 2019 10:11:59 GMT

오프라인에서 통계학 강의도 하고 온라인에서 통계학 강의를 녹화하면서 배우시는 분들께 받은 첫 느낌은 통계학을 너무 어렵게 생각하고 있다는 것이었다. 아마 통계학의 첫 느낌이 고등학교때 확률 통계의 경우의 수 계산하는 기억에 머물러있는 분들이 대부분일 것인데, 사실 수리통계학까지 공부할 게 아니고 기본적인 통계학 개념과 교양 정도만 익힌다면 데이터 분석 공부나 관련 분야에 발을 들이기 훨씬 더 수월해진다. (기초 공부를 하고 심화로 넘어갈 수 있다.)

그러면 항상 따라오는 질문이 어떤 책을 보아야 하느냐 인데.. 사실 나도 보지 못한 너무 좋은 책과 교재들이 인터넷에 널려있지만 내가 조금이라도 보고 공부해본 책들을 위주로 간단하게 특징을 짚어보겠다. 어려운 척하기 좋아하는 해외 전공 서적보다는 최대한 쉽게 쓰여져있고 대부분 좋게 평가하고 왠만하면 한국 사람이 쓴 책을 위주로 추천해보겠다.

스터디 교재

난이도: 입문

이토록 쉬운 통계&R

표지부터 괴랄하기 짝이 없는 이 책은 이토록 쉬운 시리즈의 첫번째 책이며 그 주제가 통계이다. 저자는 패스트캠퍼스에서 강의를 하고 있는 걸로 알고 있고 가끔 광고도 보았던 것 같다. 이 책을 추천하는 이유는 일단 책 제목 그대로 쉽다. 정말 수학에 너무 겁을 먹고 있거나 데이터 분석이나 통계에 대해서 1도 모르겠다 싶으면 예시와 친절한 설명이 가득한 이 책을 추천한다. 말그대로 초보자를 대상으로 했기에 복잡한 설명이나 어려운 수식은 생략한다. 뒤에 R 부분을 제외하면 다른 교재에 비해 분량도 훨씬 적기 때문에 수포자들도 조금씩 읽다보면 어느새 통계가 무엇이고 데이터 분석을 어떻게 하는지 감을 잡을 수 있을 것이다. 조금이라도 통계를 알고 있다면 그다지 추천을 하고 싶지는 않다.

세상에서 가장 쉬운 통계학 입문

이토록 쉬운 통계책을 읽고 조금 더 필기도 해보고 문제도 풀어보고 싶은 분들을 위한 책이다. 하지만 제목에서도 나와있듯이 아주 쉽게 되어있고 이토록 쉬운 통계에서 깊게 설명하지 않는 검정이나 구간추정을 잘 설명하고 있다. 대학 교재가 부담스러운 분들은 꼭 추천한다.

통계학 류근관 저

표지를 봐도 딱 대학교재스럽게 생긴 책이다. 하지만 굉장히 쉽게 쓰여져있고 풀컬러에 전통 통계학에서 가장 실용적인 회귀 직선이 앞 부분에 나오는 등 당시에는 나름 파격적인 구성을 가진 교재이다. 서울대에서 수리통계학과가 아닌 경제학과 등의 상경 계열을 대상으로 쓰여져서 KMOOC나 서울대에서 제공하는 강의를 찾아보면 좀 오래되었지만 경제통계학이라는 좋은 강의도 찾을 수 있을 것이다. 교수님이 아주 친절하게 잘 설명해주시고 무료이니 책만 가지고 공부가 어려우신 분들은 강의 영상도 꼭 찾아보면 좋다.

이 책을 보면서 개인적인 감상은 이론보다 실제 예시를 최대한 활용하고 통계학을 최대한 활용할 수 있는 부분으로 연결시키기 위해 애썼다는 느낌이 많이 들었다.

난이도: 중급

앤디필드의 유쾌한 R 통계학

기초 통계학 책에서 다루지 않는 통계 기법들을 대부분 다룬다. 수식보다는 통계 기법 또는 모델의 기본적인 이론을 설명하고 교재에서 제공하는 다양한 데이터로 R 실습을 진행한다. 한창 공부를 하던 시절 책이 워낙 두꺼워서 분권화해서 공부를 했고 한글판도 나쁘지 않게 번역되었다. 내가 문과 계열 (사회, 심리, 행정 등) 대학원에서 통계를 활용하여 논문을 써야하는데 당장 수학 공부할 여유가 없다면 이 책 하나만 파는 것도 나쁘지 않다. 저자 앤디필드가 심리학, 아동 정신병리학 교수로 관련한 예제들을 다양한 기법으로 설명해주고 있다. R을 적극 활용하지만 머신러닝과는 반대로 설명 가능한 고급 통계 모형을 공부하고 그것을 R 코드로 활용까지 해보고 싶은 사람은 꼭 추천하는 교재이다.

기초 통계학 지식을 조금 가지고 있고 (입문 책 중 하나 이상 읽은 사람), Python 이나 R 을 조금이라도 맛본 사람에게 추천한다. 프로그래밍을 전혀 안했다면 R 실습이 쉽지 않을 것이다.

따라하며 배우는 데이터 과학

실리콘 밸리 데이터 과학자 권재명 박사님의 책이다. 사실 이 책은 머신러닝을 기본적으로 공부할 수 있는 책으로 그 수준이 입문이라고 할 수 있으나 기본적인 통계 지식을 바탕으로 뒤 내용들을 전개하기 때문에 이 책의 6장 정도에 나오는 내용은 쉽게 이해가 가능한 사람들에게만 추천한다. 머신러닝을 배우고 싶은 사람은 류근관 교수님 책 읽고 이 책을 보면서 실습해보면 좋을 것 같다. 1~5장은 환경 설정이나 기타 R 기초에 대한 부분이라서 본격적인 내용은 6장 이후이다. 통계 이론을 공부하고 실제로 통계 예측 분석을 활용해보고 싶은 분들이 보면 좋을 책이다.

데이터 과학을 위한 통계

통계학과 R 코딩을 어느정도 했거나 머신러닝, 데이터 과학을 공부하는데 통계가 어떻게 활용되는지 어떤 관점에서 통계를 공부해야하는지 궁금하다면 보면 좋다. 앞의 책들과 달리 차례대로 보는 튜토리얼 교재라기 보다는 내가 궁금했던 부분들을 그때그때 찾아서 보는 성격이 강한 교재이다.

교양 서적

바로 공부하기는 부담스러운 사람은 교양 수준의 책으로 먼저 접근을 해보는 것도 좋은 방법이다. 또는 위의 스터디 교재로 공부를 하면서 교양 서적들을 병행해서 읽으면 단순히 실무적인 스킬이나 이론 뿐만 아니라 실제 활용이나 사례를 통해서 다양한 인사이트를 얻을 수 있을 것이다.

빅데이터를 지배하는 통계의 힘 - 입문편

시리즈가 여러개 있는데, 기본편을 추천한다. 통계를 공부하기 위한 다양한 백그라운드나 빅데이터를 이해하기 위해서 왜 통계학인지, 뉴딜 정책, 나이팅게일, 우유-홍차 실험 등 통계학 역사의 여러 크고 작은 사건들과 이론이 탄생하게 된 이야기를 재밌고 쉽게 풀어써주는 책이다. 본격적으로 수학, 통계학을 공부할 여유가 없는 사람은 이 책을 읽는 것을 강력 추천한다.

틀리지 않는 법, 수학적 사고의 힘

내가 아는 한 데이터 분석을 조금 한다고 하는 분들 모두가 강력 추천하고 여러번 읽기를 하고 있는 그 책이다. 단순히 수학적 사고의 힘이라고 되어있지만 아무래도 실생활은 통계나 확률과 연관이 깊어서 생존자 편향, 선형 회귀, 확률, 추론 등의 어려운 통계 이론들을 다양한 사례를 들어서 재밌고 쉽게 설명하고 있다. 하지만 아예 통계를 모른다면 조금 난이도가 있을 수 있으니 약간 공부를 같이하면서 읽으면 훨씬 얻을게 많은 책이다. 꼭 통계나 수학이 아닌 일상 생활하는데서 수학적 사고의 유용성을 알려주는 부분도 있으니 꼭 읽어보자.

통계학 입문 책들을 추천하며

이외에도 조금 더 교양 서적들이나 통계학이나 데이터를 주제로 하는 다양한 책들이 있다. "새빨간 거짓말, 통계", "생각에 관한 생각", "모두 거짓말을 한다.", "팩트풀니스" 등등 내가 읽어본 것도 있고 읽어보고 싶은 책들도 있는데 관심이 있다면 찾아서 읽어보면 좋을 것 같다.

스터디 진행을 하면서 간략히 추천해주었던 책들을 포스팅으로 정리하니까 생각보다 시간이 오래걸렸다. 사실 공부를 하면 할수록 그냥 좋은 교재 하나 붙잡고 공부하는게 제일 좋은 것 같지만 입문을 하는 입장에서는 모든게 어려워보일 것이고 심지어 내가 정말 쉽다고 추천한 책도 그들한테는 어려울수도 있다. 그래도 포기하지 않고 책을 읽고 공부를 계속해나간다면 언젠가 정규 분포 기댓값을 수식으로 유도하거나 벡터 공간에서 선형 회귀 직선을 구하는 과정을 즐기고 있는 자신을 발견할 수도 있다. (아닐수도 있다..)

요즈음 툴이 너무 좋아져서 데이터 분석이나 데이터 과학을 하는데 있어서 그렇게까지 깊은 수학 이론이 필요없다는 것에는 동의하지만 그래도 기본은 알아야한다. 그리고 이 데이터가 넘쳐나는 시대에 관련 전공자나 커리어를 쌓는 사람이 아니더라도 통계는 필수 교양이 되어가고 있는 것 같다. 시간내서 꼭 공부해보시길.

퀀트 책 추천 인공지능 투자가 퀀트- 알고리즘, 세계 금융시장을 침공하다

Update

2020-03-13

통계학 입문자들에게 기초 이론과 실무 활용까지 동시에 공부할 수 있는 과정을 런칭하였습니다. 19년 하반기부터 수십 명의 스터디원들에게 검증된 코스입니다. 위 책들을 모두 읽는게 부담스럽거나 올인원으로 공부해보고 싶은 분들에게 강추하는 과정입니다.

데이터 분석을 위한 기초 통계학 (Using R)

리그 오브 레전드, 전설의 시작

Tony Cho (https://flowkater.io) — Tue, 19 Nov 2019 03:11:27 GMT

주말에 쉬면서 다큐멘터리 한편을 보았다. 넷플릭스에는 볼만한 다큐멘터리가 많은데 특히 내가 강력 추천하는 다큐멘터리는 스포츠 약물 고발 다큐멘터리 '이카로스', 인공지능 시대의 시작을 알린 '알파고', 그리고 다큐멘터리이지만 거의 스포츠 드라마에 가까운 'F1, 분노의 질주' 등이다. '인사이드 빌게이츠'는 재미면에서는 그렇게 좋진 못했지만 빌게이츠에게 관심있다면 추천한다.

이번에 본건 그 유명한 롤(LOL), 리그 오브 레전드라는 게임의 탄생과 지금 현재에 이르기까지의 이야기를 다룬 다큐멘터리다.

개인적으로 나는 롤을 해본적이 없고, 한창 소프트웨어 마에스트로 연수 센터에서 공부하고 프로젝트 개발에 힘쓰고 있을 시절에 다른 개발자 친구들이 삼삼오오 모여서 롤을 밤늦게까지 하는 풍경을 자주 보았다. 그리고 소위 '롤드컵'하는 시즌만 되면 휴게실에 모두 모여서 시청하는 모습을 본 기억이 있다.

오히려 이렇게 팀을 맺어 한 전장에서 PVP를 하는 AOS 류의 게임은 모바일로 '베인 글로리'로 접했는데 이게 당시에는 롤의 경험을 최대한 모바일에 최적화한 게임이라고 들었다. 그리고 최근에는 훨씬 캐쥬얼화된 요즈음 Z세대들에게 최고의 인기를 누리는 '브롤 스타즈'를 즐겨하고 있으니 아예 이런류의 게임을 모른다고 할 수는 없다.v

롤의 시작은 스타크래프트, 디아블로, WOW로 유명한 블리자드의 워크래프트 유즈맵으로 시작되었다는 것을 익히 알고 있었는데 그게 어떻게 새로운 하나의 게임으로 개발되어 지금과 같은 폭발적인 인기를 얻게 되는지 그 과정을 여기서 보여준다.

피, 땀, 픽셀에서도 읽었듯이 게임 개발하는 과정(또는 제품을 개발하는 과정)은 정말 지난하고 고난한 과정인 것 같다. 3년간 수익 하나 없이 개발에 몰두하고 과감하게 Free to Play로 게임을 공개하고 (흥미롭게도 우리나라 온라인 게임들은 오래전부터 Free to Play였는데 미국에서는 롤이 거의 Free to Play 게임들 중 첫 세대와 다름없고 미국에서 처음 Free to Play를 한 게임이 넥슨의 메이플 스토리 북미 서버 버전) 캐릭터의 능력치를 파는게 아닌 스킨과 같은 게임의 밸런스에 영향을 미치지 않는 아이템을 파는 등 아마존의 책을 읽으면서 느꼈던 정말 유저를 위한게 무엇일까, 게이머들을 위한게 무엇인가에 치열하게 고민하고 실행하는 모습에서 또 한번 많은 것을 느끼고 배우게 된 것 같다.

특히, 유통사를 통해서 유럽에 출시하여 본인들의 운영 방향과 반대되는 방향으로 운영되는 것을 보고 유저들의 쌓인 불만을 해결하고자 직접 유럽에 지사를 세우고 서버를 이전하려고 하드웨어를 옮기는 날 화산이 폭발하여 항공이 마비되어 아프리카로 경로를 수정하여 옮기는 이야기는 그들의 유저, 게이머 중심적인 태도와 이 게임에 대한 열정을 바로 느낄 수 있는 이야기였다.

두번째로 중요하게 다루는 내용은 팀 게임이고 PVP인 롤의 특성을 살려 이것을 스포츠화하기 위해 어떠한 노력을 했는지 어떤 시도를 했는지 나오는데 정말 재밌는 건 이 '게임'이 미국이라는 사회 내에서도 '스포츠'로 불리기까지 제도권 내의 보수적인 기성세대들에 의해 얼마나 조롱당하고 공격당하는지도 과감없이 보여준다. 기성 세대들의 관점에서 게임이 가지는 속성이 꼭 우리나라에서만 보수적인 건 아니라는 것이다.

그리고 롤의 성공에 기여한 우리나라, 한국이 굉장히 큰 비중으로 나온다. 인구밀집도가 굉장히 높고 세계에서 제일 빠른 초고속 인터넷이 설치되어 있고 이미 20년전부터 e스포츠가 있었던 국가라는 점을 강조하면서 진정성 있게 우리나라 게이머들을 감동시키고 3개월만에 국내에서 최고의 게임으로 자리잡는 모습, 그리고 마이클 조던에 비유하는 롤 최고의 선수 'FAKER'(프로게이머 이상혁)까지 비중있게 다룬다. (잠깐 지나가는 장면에 내가 5년전에 자주 갔던 PC방이 나와서 깜짝 놀랐다..)

단순히 성공 스토리만 다루지 않고 롤이 가진 커뮤니티의 힘 그리고 트위치, 유튜브 등의 게임 스트리밍 문화, 그리고 이러한 경쟁 게임이 가진 피로감과 중독성 같은 이면도 짧지만 다루기도 한다. 그래도 다큐멘터리는 이러저러한 문제가 있고 더 노력해야겠지만 롤은 최근 10년 내에 최고로 성공한 게임이자 거대한 커뮤니티이며 새로운 커넥션을 만들고 전세계에서 흥행하는 스포츠 중 하나라는 사실을 얘기해주며 마무리한다.

작년 '님폰없'과 홍콩선수 징계 사건으로 민심이 추락한 블리자드에 대비되는 모습으로 '라이엇 게임즈'는 행사를 하며 신작들을 발표하고 게이머들을 위한게 무엇인지 고민하는 모습을 보여주며 더 좋은 평가를 받고 있다.

블리자드의 한 게임의 유즈맵 정도에서 나온 게임 장르로 시작하여 10년이 지나며 이제는 전혀 다른 평가를 받게 된 두 회사의 모습을 보며 역시 진정으로 유저(고객)를 생각하는 것만이 시장 경쟁에서 승리할 수 있는 유일한 요소라는 것을 다시금 깨닫게 된다.

특히, 중간에 두번째 공식 롤 대회 결승전에서 대회 중 인터넷이 끊겨 망한 상황에서 라이엇 게임즈 창립자 중 한명인 브렌드 벡이 나서서 상황을 수습하는 모습은 굉장히 인상적인 장면이었다. (티켓 전액 환불, 롤 게임 포인트 25달러 지급, 상품을 무료로 뿌리자 화가 나 있고 실망한 관중들이 한순간에 'LOL'을 외치는 광팬으로 변하는 장면이었다.)

게임의 성공 요소는 당연히 첫번째는 재미이다. 그리고 두번째는 네트워크 효과이다. 롤의 초기에 85%가 친구 추천으로 게임에 입문했다고 한다. 또한 친구가 하니까 나도 계속 하게 되는 것이다. 마지막은 진정으로 게이머들을 생각하는 개발사의 운영, 그러한 태도이다.

단순히 게임에서 뿐만 아니라 서비스를 만들고 기획하고 운영하는 입장에서도 배울게 많았던 다큐멘터리였다. (그렇다고 내가 롤을 하지는 않겠지만..)

롤을 좋아하는 사람에게는 최고의 다큐멘터리가 될 것 같고, 롤을 하지는 않았어도 그것을 이해하고 성공하는 서비스의 교훈을 얻고 싶은 사람들은 한번쯤 보면 좋을 것 같다.

개인적으로 앞으로 나올 '라이엇 게임즈'의 다른 게임들은 롤만큼 성공할 수 있을지, 아니면 결국 롤이 최고의 게임으로 남을지 기대가 된다.

"골프 경기를 보는 사람은 이해해요. 근데 컴퓨터 게임 하는 사람은 왜 보는지 모르겠어요."

"내 아내는 골프 경기 보는 것도 이해 못 해요. 골프를 안치거든요. 당신이 게임을 안하면 재미없게 느껴지죠"

블로깅 다시 시작하기

Tony Cho (https://flowkater.io) — Wed, 13 Nov 2019 02:11:59 GMT

최근에 다시 리액트 개발을 시작하면서 여러가지 어려움에 봉착하였다. 사실 내가 리액트 개발을 처음 접한거 2016년이었으니 지금까지 꾸준하게 해왔다면 능숙하지는 못하더라도 리액트 사용에 어려움은 없는 수준이 되었어야 한다.

하지만 회사가 추가 투자를 받게 되면서 개발과는 빠이빠이 하게되었고 그나마 개발을 했던 관리자 패널이나 기타 다른 프로젝트들도 폐기되면서 내가 업무에서 코드를 만질 기회가 거의 없었다.

나름 경영자, 기획자 역할을 하다보니 개발 자체에 소홀한 것도 있었고 뭐든 그렇듯 안하다보니 자신감이 하락하고 실력도 없는 것 같아 일부러 쳐다보지 못했던 부분도 있었던 것 같다.

대신, 그 사이 업무 외에 데이터 분석을 주로 파면서 선형대수 강의를 하거나 통계학 강의, 그리고 Python이나 R을 이용하여 여러가지 프로젝트를 하면서 시간을 보내왔다.

하지만 최근 팀이 축소되면서 내가 다시 사용자 서비스 개발에 기여할 수 밖에 없는 업무 구조가 되었고 작은 회사의 대표이자 어쨋든 생존을 하기 위해 이 블로그를 다시 시작해보려고 한다.

꾸준히 할 수 있을런지 모르겠지만 여느 Gatsby, React를 활용하는 개발자분들처럼 프론트엔드나 개발에 집중하는 블로그는 아니다. 지금까지 Naver Blog, Tumblr, Octopress (중간에 Wordpress 잠깐..), Jekyll을 이용하여 블로그를 운영해보았으나 결국 꾸준하지 못했는데 그 가장 큰 이유는 개발이나 기타 주제에 대한 분산된 블로그 운영이 가장 큰 이유였던 것 같다.

그래서 이 블로그는 그냥 일기쓰듯, 습관처럼 이것저것 남기는 공간으로 활용할 예정이다.

앞서 최근 개발을 다시 시작하면서 어려움에 봉착했다고 했다. 이제는 더이상 기록을 안하면 기억을 못하는 나이가 되었다. 그리고 단순히 notion에만 쓰니 별로 재미가 없다. 또 누군가는 내 글을 봐줬으면 좋겠고 누군가 본다는 그 책임감이 또 나를 움직이게 하는 동기부여가 되니까.

여튼 횡설수설 말이 길었다. 앞으로도 이와 비슷하겠지만 다양한 주제로 꾸준히 글을 올리기를 내 스스로에게 기대한다. 황금같은 아침시간을 투자해서 이 블로그를 개설하고 배포하였으니 앞으로 좋은 일이 있겠지.

최근에 하고 있는 것들을 간단히 요약하고 글을 마무리 하겠다.

개발

React (+ Graphql, Typescript 등) 개발을 하고 있다. 오랜만에 돌아오니 React Hook 부터 재미난게 많더라. 조금 정신없지만 빨리 적응해서 서비스 개발에 기여할 수 있으면 좋겠다.

데이터 과학

Python, R, SQL 세가지 언어 다 이제 데이터 분석 관점에서는 중급 단계가 된 것 같다. 물론 그때그때 찾아봐야하는 건 여전하지만 뭐든 하라면 어떻게든 하는 수준인 것 같다. 최근에는 zeppelin 을 이용하여 사내 대시보드 구축을 하고 있다. zeppelin은 Spark 기반의 시각화 도구라고 생각하면 되는데 python 이나 SQL도 잘 지원하고 무엇보다 시각화도구에 알맞게 interactive 한 시각화 도구라서 좋다. 미리 스크립트 짜놓으면 다른 팀원들은 그냥 실행버튼만 누르면 최근 데이터를 확인 가능하다.
확률통계 및 통계 이론 공부는 꾸준히 하고 있다. 작년에 그토록 열심히 공부했던 수리통계학이 또 이 시점 되니까 가물가물하다. 특히 세부 증명이나 용어, 공식은 아예 기억도 안난다. 최근에 확률과 확률분포를 확률형 아이템 및 가챠 게임의 강화 시스템에 대한 글을 썼는데 나중에 좀 다른 주제로 이 블로그에 다시 글을 써보고 싶다. 수학 공부는 꾸준히 하는게 답인듯.
- 비전공 통계학 입문자들을 위한 스터디 교재 & 교양 서적 추천

독서

최근에는 '구글 OKR', '디커플링' 책을 읽고 있다. 블로그에 열심히 리뷰 올리는 걸 목표로 하자.

운동

스트렝쓰 훈련을 시작한지 정확히 5개월째에 접어들었다. 이때까지는 Strong Lift 프로그램을 무리없이 따라갔는데 최근에 무릎 및 등이 많이 안좋아지고 무게도 스쿼트 110kg 이상, 데드리프트 130kg 이상이 되니까 일주일에 두번 이상하기가 쉽지 않다. 그레이스컬부터 해서 다양한 루틴들이 있던데 현재 치료받는 부위들이 좀 나아지면 운동 프로그램을 바꿔보려고 한다.

하버드 상위1퍼센트의 비밀

Tony Cho (https://flowkater.io) — Wed, 09 Oct 2019 03:11:23 GMT

10억분의 1의 성공을 만드는 블랙 다이아몬드

Black Diamond = Block(차단)xDeep(깊은 이해)

우리는 태어나서 의식이 생기고 난 순간부터 현재 이 시점까지 얼마나 많은 신호에 노출되고 있는가? '신호'는 크게 긍정적인 신호와 부정적인 신호로 나뉘어진다. 그리고 우리가 어릴적부터 계속 노출되어온 이 신호들은 마치 운명이 되어 우리 삶을 좌지우지 할 정도로 막강하고 무서운 것들이다.

어릴때 무심코 부모님이 한 칭찬이 한 아이의 인생을 바꾸기도 하고 일상에서 나누던 작은 대화가 삶의 큰 파장을 일으키기도 한다.

처음 이 책의 표지와 제목을 보았을때는 한국의 그저그런 하나의 자기계발서라고 생각하고 그냥 지나쳤다. 하지만 페이스북에서 하버드의 교육 커리큘럼을 지방 3류 대학에 이식하여 진행한 실험에 대한 글을 읽고 그 글의 출처가 이 책이라는 것을 알고 읽기 시작했다.

(지방 3류 대학에 하버드 대학의 커리큘럼을 그대로 이식하여 한학기를 진행했을때는 학생들이 공부를 따라가지 못하고 실패했다고 한다. 하지만 단 한과목만 가지고 똑같이 진행을 하니 하버드 학생들의 성취 결과보다 훨씬 뛰어난 성취를 보였다는 글이었다.)

이 책은 국내 서적이지만 상당히 많은 해외 여러 인물들, 연구들을 보여주는 책이다. 특히 야구 선수인 페드로이아, 고생물학자 존 호너, 지휘자 카라얀, 하버드 상위 1퍼센트 블랙 다이아몬드 등의 이야기는 정말 흥미롭고 재밌는 이야기들이다.

특히, 전통 교육에서 서열화를 우월감과 열등감이라는 연료의 관점에서 풀어쓴 건 정말 재밌는 관점이었다. 하버드대학의 마가렛 쉬 교수는 실험을 통해 상위권 학생들을 향한 성적에 대한 긍정적 신호(우월감)를 꺼버렸고 상위권 학생들이 더 이상 하위권이나 중위권 학생들과 경쟁하지 못하게 차단된 상황을 만들자 고난이도 문제를 풀 때 그들의 성적이 현저하게 떨어졌다. 그러나 다시 중위권 학생들과 경쟁을 치르게 하자 상위권 학생들의 성적은 눈에 띄게 올라갔다고 한다. 바로 중위권 학생들이 가지는 '열등감'이 상위권 학생들에게는 '우월감'을 느낄 수 있는 연료로 쓰인다는 점, 누군가의 낮은 위치와 열등감은 반대의 사람에게는 조용한 우월감과 성취감이 된다 라는 것이다. (이런 우월감이 은은할수록 더 효과가 크다고 한다.)

"자기 자신에 대한 생각은 상당 부분 타인의 판단"에서 온다. 그래서 우리는 그 잘못된 판단을 차단시키는 것이 굉장히 중요하다.

키가 작은 야구선수 페드로이아는 큰 스윙을 남발했다고 한다. 사람들은 모두 몸이 작다면 스윙을 낮추고 작게 하라고 조언하고 그를 그저 그런 선수라고 무시했다고 한다. 하지만 그는 다른 사람의 말을 쉽게 듣지 않았고 주눅도 들지 않았다. 동작이 크고 강한 스윙을 계속해서 연습했다. "그러던지 말던지 방망이와 공에만 집중하겠다." 이게 사람들에게 그가 한말이었다. (이외에도 책에는 그가 엄청나게 저평가 받고 있었다는 얘기가 나온다.) 2007년에 페드로이아가 아메리칸 신인왕이 되고 그 다음 해에는 MVP가 되었다는 얘기는 정말 흥미로운 이야기다. 선천적 난독증으로 대학을 7번 쫓겨난 존 호너와 하버드 대학 고생물학 박사 로버트 베커의 대조적인 일대기 또한 인상깊었다. (쥬라기 공원 자문을 맡은 존 호너가 베커 박사와 닮은 연구원을 티렉스에게 먹히게 하는 이야기는 킬포인트.)

이 책이 전하고자 하는 메시지는 간단하다.

천재란 없다
주위의 부정적 신호를 차단하고 스스로에게 확신을 가지고 한 분야를 깊이 오랜시간 파고든다면 누구든 그 분야에서 가장 위대한 사람이 될 수 있다

'내가 못한다, 나는 원래 못했다.' 같은 열등감을 가지고 있는 사람들은 고난도의 문제에 도전할때 작업기억력이 떨어진다고 한다. 서열화되는 시스템 자체가 개인의 학습 능력 자체를 저하시킨다는 말이다.

누군가를 가르치고 있거나 본인이 다시 무언가를 배우는데 과거의 경험(신호)이 본인을 괴롭히고 있다면 이 책을 읽어보길 바란다. 또한, 그냥 역경과 고난 속에서 실패자로 낙인 찍힌 인간들이 어떻게 한 시대를 대표하는 인물들이 되는지 인물들의 이야기가 궁금한 사람들에게도 추천한다. 이 책의 메시지와 별개로 이러한 스토리가 정말 흥미롭고 재밌다. 그것만으로 이 책은 읽을만한 가치가 있다.

우리가 이때까지 받았던 부정적 신호를 어떻게 바꿀 수 있을까? **'자신의 가능성을 의심하는 외부 신호를 역으로 재평가하는 것만으로도 새로운 신호가 만들어질 수 있다'**고 한다.

'나는 원래 ~를 못해'
'난 이때까지 ~했기 때문에 할수없어'
..

같은 것들이 과연 정말 그런 것일까? 어릴때 누군가에 의해 나도 모르게 심어진게 아닐까? 스스로를 정의하고 있는 부정적 신호들을 의심하고 다시 재평가해보자.

그리고 지금도 나에게 부정적 신호를 주는 사람들이 있다면 그들의 말은 차단해버리고 그냥 내가 지금 해야하는 일에 깊게 몰입해보자. 그들의 말에 우리가 주눅들 필요는 없다.

책에서 다루었고 더 알아보고 싶었던 인상적인 인물들

⁃	야구선수 페드로이아
⁃	고생물학자 존 호너
⁃	지휘자 카라얀
⁃	미국의 제 56대 국무장관 키신저
⁃	화학자 마리 퀴리
⁃	도로왕 존 매캐덤
⁃	하버드 최연소 교수 앨런 더쇼비츠

아마존, 세상의 모든 것을 팝니다.

Tony Cho (https://flowkater.io) — Fri, 20 Sep 2019 03:11:59 GMT

제프이즘(Jeffism)

“우리를 남다르게 만드는 것이 무엇인지 궁금하시다면 그 진실은 바로 이것입니다. 우리는 진정 고객 중심적이고, 진정 이 사업을 장기적으로 바라보고 있으며, 진정 창조를 즐깁니다. 하지만 대부분의 회사는 그렇지 않습니다. 그들은 고객이 아닌 경쟁자에 집중합니다. 그들은 2~3년 안에 수익을 올릴 수 있는 것에 투자하기를 원합니다. 그래서 2~3년 이내에 잘 되지 않는다 싶으면 다른 사업 거리를 찾아나서는 거죠. 또 대부분의 회사는 창조하기보다 근소한 차이로 창조자를 따라가기를 선호합니다. 왜냐하면 그 편이 더 안전하니까요. 이것이 바로 우리가 남다른 이유입니다. 이 세 가지 모두에 역점을 두는 회사는 거의 없거든요. 이것이 아마존의 진실이죠.”

최근에 즐겨보는 영화 유튜버 '기묘한 케이지'님의 영상 중에 현재 전세계 공식 최고 부자 중 한 사람인 제프 베조스의 이야기를 담긴 유튜브 영상을 보았다. 해당 영상은 베조스의 우주 사업 '블루 오리진'에 대한 이야기였는데 미국 최대 온라인 마켓플레이스인 아마존을 운영하는 CEO가 왠 우주? 라는 의문이 들었었다. 하지만 해당 책을 읽으면서 그가 어릴적에 스타트렉의 덕후 기질이 다분히 있었다는 것을 알고는 이해가 되었다.

제프 베조스는 굉장히 독선적이고 성미가 괴팍한 흔히 우리가 생각하는 스티브 잡스 같은 경영자 유형이다. 하지만 그의 그런 성미가 진정한 '고객 중심'에 향했다는 것이 단순히 독선적이고 괴팍한 것이 아닌 비범함과 미래를 바라보는 통찰로 표현될 수 있는 것 같다. 책은 크게 세 파트로 나뉘어져 있다. 아마존의 초창기와 제프 베조스가 아마존을 시작하기 전까지의 삶, 그리고 현재의 모습이 되기 까지 아마존의 모습이다.

한국에서는 아마존을 대부분 잘 모르지만 IT 개발자라면 모두 AWS를 이용해서 서비스를 배포하거나 공부해본 경험이 있을 것이다. AWS가 어떻게 만들어졌는지도 어떻게 시작했는지도 상세하게 나오기 때문에 관심이 있다면 흥미롭게 읽을 수 있을 것이다.

책을 읽으며 제프 베조스는 어릴적부터 대학을 졸업할때까지 공부를 굉장히 잘하는 엘리트라는 것을 알게 되었다. 그리고 그것이 경쟁을 두려워하지 않는 대담함과 자신감의 결과이며 그것이 현재의 아마존에도 계속해서 강력하게 영향을 미치고 있다는 것, 하지만 그도 인간이고 많은 실수를 했고 경영적 판단에서 잘못된 판단도 내리고 그런 성미 때문에 그가 분명 잃은 것도 있었다.

아마존의 역사를 보면서 사업을 하는데 있어서 얻을 수 있는 많은 통찰을 얻었다. 그리고 장기적인 비전을 가지고 진정으로 고객 중심으로 사고하는 것이 어떠한 것인지도 알게 되었다. 물론 아는 것과 실천하는 건 다르지만..

요즈음 회사를 운영하면서 너무 많은 어려움에 직면하고 있다. 하지만 그 중에서도 가장 날 괴롭히는 생각은 도대체 고객이 원하는게 무엇인지 시간이 지날수록 더 모르겠다는 것이다. 사실 처음에 시작했을때는 그걸 안다고 생각했는데 그리고 어느정도 그들을 안다고 생각했는데 의외의 모습에 당황하고 헤매고 허우적대다보니 지금은 오히려 더 모르겠다는 것이다.

책 한권에 현 상황을 해결할 해결책을 바로 얻지는 못하겠지만 아마존의 역사와 그들의 삽질, 제프 베조스의 제프이즘을 느끼며 나름의 아이디어를 얻기는 했다. 또한, 장기적인 비전과 진정으로 고객 중심적인 사고를 하는 것은 쉽지는 않겠지만 계속 내가 앞으로 견지해야할 태도일 것이다.

그리고 항상 책을 많이 읽고 더 열심히 공부하는 자세를 가지자. 우리나라에서 공부 머리와 사업 머리를 구분하는 고정관념이 있는데 최근에 잠깐 보았던 다큐멘터리 빌게이츠도 스티브 잡스나 이 책의 제프 베조스도 소싯적(?) 어마어마한 공부 머리들이었고 엘리트였으며 사업을 하는 지금 이 순간까지도 항상 공부하고 많은 책을 읽고 있다는 것을 새삼 책을 통해 영상을 통해 다시 알게되니 더 노력해야겠다는 생각이 들었다.

책을 읽으면서 쿠팡과 티몬의 차이점도 알게 되었고, 왜 손정의가 알리바바와 쿠팡에 투자했는지도 아마존을 공부하면서 이해하게 된 것 같다.

온라인 마켓플레이스의 구조와 혁신, 그리고 기업가 정신에 관심이 있다면 이 책을 추천한다. 그리고 제프 베조스가 궁금한 사람들도 꼭 읽어보길 바란다. 그의 어린 시절, 어머니와 외할아버지와의 에피소드는 많은 걸 느끼게 해준다.

“직원 여러분은 요즘 매일 아침 눈을 뜨면 걱정이 되고 불안할 겁니다. 하지만 경쟁자를 걱정하지 마세요. 어차피 우리한테 돈 한 푼 주지 않은 사람들입니다. 우리는 고객을 걱정하고 우리가 할 일에 집중합시다.”

피, 땀, 픽셀 - 트리플 A 게임은 어떻게 만들어지는가

Tony Cho (https://flowkater.io) — Fri, 08 Mar 2019 00:00:00 GMT

이 땅에 모든 겜돌이, 겜순이 그리고 모든 IT 업계 종사자들을 위한 위대한 스토리

이 책을 한마디로 요약하면 게임을 만드는 다양한 회사들의 게임 개발 뒷이야기 정도가 될 것 같다.

개인적으로 나는 겜돌이로 게임을 엄청나게 잘하는 편은 아니지만 어릴 때부터 지금까지 많은 게임을 했고 즐겼다. 특히, 이 책에 나오는 게임 중 너티 독의 '언차티드 4'는 정말 몰입해서 엔딩을 봤던 기억이 있으며 너티 독의 이전 게임인 '라스트 오브 어스'는 엔딩을 두 번이나 보았다. (시간이 없어 언차티드 4 확장판은 아직 초반부 플레이만 하고 봉인 중이다. 엄청난 분량을 자랑하는 '위쳐 3' 역시 재미나게 한 게임이지만 역시 엔딩을 보지는 못했고 '디아블로3'은 많이 즐기지는 못했지만 내가 사랑하는 블리자드의 스토리 텔링에 빠져 디아블로에 나오는 악마들의 관계까지 줄줄이 꿰고 있었던 적도 있었다. 스타듀 밸리, 셔블 나이트 같은 게임은 유튜버들이 스트리밍하는 걸 많이 시청했던 기억이 있다.

이미 책에서 언급하는 게임 반을 알거나 플레이해 보았고 반절 이상은 모두 이름은 들어본 게임들이라 게임톡에서 읽었던 책 내용의 일부를 발췌한 <a href="http://m.gametoc.hankyung.com/news/articleView.html?idxno=49131" target="_blank">이 기사</a>를 읽고 언젠가는 꼭 읽어봐야지, 다짐하다가 어느 날 서점에 들르자마자 바로 책을 샀다. (혹시 어떤 책인지 궁금하신 분들은 이 글보다 저 기사에 나온 책 내용을 한 편 읽어보고 책을 구매하는 것도 나쁘지 않다)

사실 책은 게임 개발을 하는 사람들의 이야기지만 나는 겜돌이이기 이전에 IT 스타트업에서 기획자로 개발자로 일하는 한 사람으로 정말 몰입해서 읽게 된 것 같다.

책에 나오는 수많은 게임 개발자들의 '크런치 모드'에 차마 웃으며 들을 수 없는 처절하고 처절한 게임 개발기를 듣다 보니 가끔은 마음이 아프기도 그들의 열정에 가슴이 뛰기도 했다. 그리고 나도 그렇게 일해본 경험이 있으니 그들과 똑같지는 않지만 그들의 감정이 (기쁠 때나 슬플 때나) 공감이 갔다.

책에서는 게임만 다양한 것이 아니라 각 게임 개발의 '스테이지'도 다르다. 똑같은 대형 게임 개발사의 성공담을 다룬 대표적인 두 게임 '언차티드 4'와 '위쳐 3'는 비슷한 얘기인 것 같지만 언차티드를 개발한 너티 독은 이미 라오어로 성공한 '미국' 회사였고 '위쳐3'를 개발한 'CD 프로젝트 RED'는 게임 개발자가 대부분 어린 시절을 동유럽의 공산주의에서 자란 '폴란드' 회사였다. (이들의 '반공' 정신은 정말 인상적이었다.)

특히, '스타듀 밸리'의 개발 스토리는 정말 눈물 나는 과정이었다. 비슷한 규모의 '셔블 나이트'는 그래도 같이하는 팀원이 있었는데 '스타듀 밸리'는 말 그대로 1인 개발자가 거의 5년 가까운 시간을 골방(?)에서 사운드, 그래픽, 시나리오, 프로그래밍 모두를 혼자서 개발하며 결국 마지막에 게임이 대히트를 치는 스토리는 정말 왠만한 실화 영화 스토리로도 손색이 없는 그런 과정이었다.

'디아블로3'는 게임은, 아니 모든 제품은 출시가 아니라 출시 이후라는 걸 보여준 대표적인 게임 개발 스토리였다. 지금은 사라진 블리자드의 겜돌이 정신으로 초반의 무수한 버그, 밸런스 문제, 경매장 문제 등을 유저와의 적극적인 커뮤니케이션을 하면서 한번 출시된 게임을 그 뒤 3년 동안 계속해서 업데이트하며 좋은 게임으로 거듭나는 모습은 현실적이며 앞의 성공담처럼 진한 감동은 없었지만 느끼는 바가 많았던 에피소드였다.

그리고 마지막 '루카스아츠'는 힘차게 시작하고 언론의 찬사까지 받은 기대작 게임 '스타워즈 1313'이 디즈니가 '루카스필름, 루카스아츠'를 인수하며 모든 팀원이 이 게임에 올인했지만 어쩔수없는 어른의 사정으로 프로젝트가 그렇게 무산되어버린 슬프고도 가슴 아픈 스토리였다.

책이 처절한 얘기도 정말 아름답게 포장한 건 모르겠지만 '크런치 모드'에 시달려 갈려나가는 개발자들(디자이너, 개발자, 기획자 모두 포함)이 처절했지만, 그 과정은 정말 아름다워 보였다. 최소한 그들은 그들이 하고 싶은 것, 만들고 싶은 게임에 모든 걸 쏟아붓는다는 느낌이었다. 그리고 모든 개발 과정은 예측할 수 없다는 것에 안도(?)했고 남들이 아닌 자기 자신을 이기려들 때만이 진정으로 승리하고 남들도 인정하는 성공을 맛볼 수 있다는 것도 다시금 알게 되었다.

제품 그 자체에 퀄리티에 더 집중하자. 그리고 조금 늦어진다고 해도 내가 세운 그 기준을 포기하지 말자. 책에서 나온 게임개발사들의 그런 달콤한 성공의 순간이 나에게 올지는 모르겠지만 그렇게 조금씩 열정을 다해 노력하면 최소한 나 스스로는 만족할만한 결과물이 나오지는 않을까?

게임이든 웹 서비스, 앱 등 IT 업계에 종사하며 오늘 하루도 '크런치' 하며 스스로 또는 회사에 의해 갈려나 가고 있을 수많은 개발자들(디자이너, 개발자, 기획자 모두 , 그리고 나처럼 어디에 한 번 빠지면 그 배경까지 속속들이 알고 싶어 하는 스토리를 사랑하는 모든 겜돌겜순이들께 이 책을 추천한다.

Update

2019-11-14

Dragon Age를 성공시킨 바이오웨어의 경우 뭔가 엄청난 후속작일 것 같았던 ANTHEM을 출시했고 망했다. EA 배급사의 문제인지 바이오웨어의 내부 사정인지는 모르겠지만.. 그 고난과 역경을 겪더라도 역시 내부 사정(배급사와의 관계, 사내 정치, 기존 개발진들의 이직 등)에 의해 그런 스탯들이 초기화되고 실패하는 경우도 많은 것 같다.

Blizzard는 작년부터 올해 하반기 블리즈컨 직전까지 "여러분들 스마트폰 없어요?"라는 스마트폰 시대가 끝나기 전까진 회자될 명대사(라 쓰고 망언이라 읽는)를 남기고 홍콩 프로게이머 선수 중징계 논란으로 블리자드의 정치적 올바름(PC)의 기준은 시진핑(차이나 머니)이라는 기사가 도배될 정도로 위기를 겪었다. 올해 2019 블리즈컨 또한 장례식이라고 불렸는데 대표가 첫 인사말로 사과까지 하면서 디아블로4, 오버워치2 등 신작을 발표함으로써 분위기 반전을 노리면서 역시 겜돌, 겜순이들에겐 어쨋든 게임만 재밌으면 된다라는 불변의 법칙 덕분인지 나름 반전에 성공을 거둔 것처럼 보인다. 물론 지켜봐야겠지

스타듀밸리는 개인적으로 아이패드 프로를 바꾸고 처음으로 구매한 유료 게임이자 정말 재밌게 플레이했는데 뭔가 반복적인 노가다와 힐링이 아닌 목표 달성을 위한 게임이 되는 순간, 과감히 앱을 삭제했다. 나중에 모바일 버전에서 멀티플레이가 지원되면 한번 해볼까..

위쳐3를 개발한 'CD 프로젝트 RED'는 사이버펑크 2077 트레일러를 발표하면서 최고의 기대감을 모으고 있다. 나 또한 엔딩을 못봐도 이 게임을 구매할 생각이다. 1인칭이라는게 좀 걸리는데 뭐 몰입감을 위해서라니까 믿고 기다려본다. 이 게임에 조금이라도 관심이 있다면 <a href="http://www.inven.co.kr/webzine/news/?news=221878&sclass=17" target="_blank">이 기사</a>를 읽어보자. 그리고 넷플릭스에서 '위쳐' 드라마가 제작 중이라는데 개인적으로 굉장히 기대 중이다. '왕좌의 게임'급의 중세 판타지 드라마가 나오길..(시즌8 빼고)

아무 걱정없이 하루 날밤까면서 즐기는 게임은 정말 즐겁다. 최근에도 간간히 이런저런 게임을 해왔는데 게임에서도 뭔가 배울게 있지 않을까. 관련 리뷰도 작성해보면 좋을 것 같다.

페르마의 마지막 정리

Tony Cho (https://flowkater.io) — Tue, 27 Aug 2013 05:54:14 GMT

“Cuius rei demonstrationem mirabilem sane detexi hanc marginis exiguitas non caperet. 나는 경이적인 방법으로 이 정리를 증명했다. 그러나 책의 여백이 너무 좁아 여기에 옮기지는 않겠다.”

페르마의 마지막 정리란, $"x^n+y^n=z^n$; n이 3이상의 정수일 때, 이 방정식을 만족하는 정수해 x, y, z는 존재하지 않는다." 이다. 그러나 페르마는 이 정리를 자신의 '아리스메티카'에 코멘트하면서 "나는 경이적인 방법으로 이 정리를 증명했다. 그러나 책의 여백이 너무 좁아 여기에 옮기지는 않겠다." 라는 발칙한(?) 말을 남겨놓았다.

이 정리를 증명하기 위해 수많은 사람들이 도전하였으나 300여년이 넘는 세월동안 그 누구도 증명하지 못하는 난제가 되었다.

사실 '피에르 드 페르마'는 정식 수학자가 아닌 아마추어 수학자로서 실제로 법조인 일을 하면서 취미로 수학을 했다고 한다. 그래서 페르마의 마지막 정리만 보고 그냥 단순히 페르마가 장난을 쳤다고 할 수도 있겠지만 실제로 그는 천재적인 수학 재능으로 여러 정리와 증명을 만들어냈다고 한다. 하지만 공유 정신이 없었던(오픈소스 정신이 없었던..) 그는 대충 자신이 증명했다고 생각하면 그냥 휘갈기고 넘어가는게 대부분이었다고 한다. 법조인으로써 잘 살고 있던 그에게 수학자로서 후학양성이나 지식공유는 아웃오브안중이었을거고.. 실제로 '아리스메티카'는 페르마의 아들에 의해서 완성된 책으로 페르마의 아들도 여기에 관심이 없었다면 페르마의 마지막 정리도 다른 이름이 되었거나 위의 정리가 그렇게까지 사람들에게 관심을 받지 못했을 수도 있다.

어쨋든 이러저러해서 페르마의 마지막 정리가 탄생되어 수많은 사람들이 도전했고 자살, 정신이상, 결투 등의 좋지 않은 사이드 이펙트를 일으키며 300여년이 지나면서 풀리지 않는 문제로 남아있게 되었다.

책에서는 페르마의 이야기부터 정리가 나오게 된 배경(피타고라스의 정리부터..) 여러가지 정수론 이야기, 페르마의 마지막 정리가 증명되기까지 영향을 준 수많은 수학자, 이론 등을 설명하면서 숨가쁘게 진행되다가 드디어 이 책의 주인공인 '앤드루 와일스'에 의해 증명이 되는 그 순간을 극적으로 묘사한다.

수학적인 흥미를 일으키기 충분한 소재들이었고 정수론이나 현대대수학을 공부해보고 다시 한번 이 책을 읽으면 더 재밌지 않을까하는 생각이 든다.

재밌는 수학자의 이야기도 많아서 그들의 인간적인 삶과 수학 그 자체에 대해서도 이해하게 된 것 같다. 'Numb3rs' 미드를 보면 주인공인 찰리가 사건 해결에 수학을 응용하면서 나는 '아 수학을 알면 이렇게 실생활에 응용할 수 있구나.' 라고 생각을 했는데 '박사가 사랑한 수식'이라는 영화를 보면 주인공인 박사가 정확히는 기억이 안나지만 이런 얘기를 한 것 같은데.. '수학은 수학 그 자체로 아름다운 것이다.' 즉, 어디에 활용되고 응용되는 것이 아니라 그 수의 세계와 법칙, 논리적인 증명 등 수학 그 자체가 아름답다는 말을 해주고 있었다.

사실 우애수, 완전수 등의 얘기를 하면서 그런가보다 했는데 페르마의 마지막 정리를 읽으면서 그러한 아름다움에 대해서 미약하게나마 느낄 수 있는 계기가 된 것 같다.

이 책을 읽으면서 수학에 대한 여러 생각을 가지게 된 것도 있었지만 더 감명깊었던 건 이 페르마의 마지막 정리를 증명하는 '앤드루 와일즈'의 삶이었다. 그는 7년하고도 1년(첫 발표후 오류가 발견되어 1년의 시간을 오류해결을 위해 보낸다)동안 페르마의 마지막 정리 하나만을 풀기 위해 보낸다.(정확히 얘기하자면 타니야마-시무라의 추측부터 여러 수학 정리들을 함께 풀어나가면서 해결했다.) 7년간의 은둔 생활을 하면서 증명을 하고 발견된 오류를 해결하기 위해 엄청난 스트레스에 시달리면서 1년을 다시 은둔 생활을 하면서 마지막까지 문제 해결의 끈을 놓지 않은 그의 모습을 보면서 여러가지를 느낄 수 있었다.

그건 정말 가치있는 삶을 살아가는 자세이기도 했다. 나의 개인적인 경험만을 들여다보아도 정말 오랜시간 단 하나에 집중했을때 거기서 정말 가치있는 결과들이 나왔었다. 요즈음 너무 이것저것 일을 벌이면서 마무리를 못하고 있는 내 모습을 보면서 다시 한번 내가 집중해야되는 것은 무엇인가에 대해서 생각하게 되는 계기가 된 것 같다.

정수론과 현대대수학 쪽 커리큘럼이 보니 이 책에서 나왔던 수학자들의 이름이 모두 보인다. 그들의 삶을 조금이나마 알고나니 뭔가 이것들이 친숙해보이는 느낌이 든다. 나도 페르마처럼 천재적인 재능은 없지만 수학 그 자체의 아름다움을 만끽하면서 취미 생활을 영위해나가는 것도 나쁘지 않을 것 같다.

Update

2019-11-19

어릴적에는 페르마처럼 아마추어로 수학을 하는 천재적인 사람이 되고싶었지만 최근에 선형대수나 통계학 강의도 하고 수학 공부를 꾸준히 해오면서 페르마보다는 '앤드루 와일스'를 닮기 위해 더 노력해야겠다는 생각이 든다. 7년간 하나의 문제에 몰입하여 그것만을 해결하려고 하는 모습은 너무 이것저것 할일이 많아 어느 하나 집중하기 힘든 요즈음 시대에 정말 필요한 태도인 것 같고 수학이 가져다주는 이점이기도 한 것 같다. 이 리뷰를 업데이트 하기 위해 다시 읽어보면서 나를 반성하게 되는 것 같다.

책을 읽은지 꽤 오래되었는데 다음에 또 다른 수학자의 삶이나 수학 관련 교양서를 읽어보면 좋을 것 같다. 특히, 요즈음 관련하여 많은 서적들이 나오고 있고 인공지능에 대한 관심과 더불어 수학에 대한 관심도 덩달아 증가하여 배우기 쉽고 읽기 쉬운 수학 교양 서적들이 많이 나오고 있다. 확실히 이 책을 처음 읽을때에 비하면 좋은 변화인 것 같다.