들어가며
”개발하기도 바쁜데, 비즈니스를 언제 신경 써요?”
새로운 프로젝트를 들어갈 때면 난 30명이 넘는 팀원을 앞에 두고 팀 전체에 브리핑을 진행했다. 다양한 프로젝트의 다양한 브리핑을 진행했지만 항상 내가 전달했던 포맷은 똑같았다.
“누가 사용하고, 왜 그들이 사용하는지”
사실 거짓말이고 여기에 하나 빠졌는데, 그래서 언제까지 해야 하는지가 포함되어 있었다. 전반부에서 (누가, 왜) 집중해서 듣던 팀원들이 일정을 얘기하는 후반부에 눈으로 무언의 욕을 하던 순간순간들이 아직도 실감 나게 기억이 난다. 아무리 숭고한 목적도 초인적인 일정 요구에서는 박살 날 수밖에 없다.
중요한 건 내가 “어떻게”에 집중하지 않았다는 것이다. 팀원은 30명이 넘었고 각 기능팀도 주니어부터 시니어까지 5~6명으로 구성되어 있었다. 그 안에서 내 역할은 목표를 하나로 정렬하는 것이었고, “어떻게”는 그들의 몫이었다. 내가 생각하는 좋은 팀은 목표(Outcome)를 명확히 제시하면 그걸 달성하는 것에만 온전히 집중하는 것이다. 5명 이내의 팀이면 모르겠지만 30명이 넘는 팀에서 내가 How to를 하나씩 알려주는 건 좋은 리더십도 좋은 팀도 아닐 것이다.
난 서사 덕후로 모든 일에는 인과가 있고 하나의 서사가 팀에 잘 정렬되어야만 온전히 한 팀으로 일할 수 있다고 믿는 사람이다. “누가 사용하고, 왜 그들이 사용하는지”는 우리 프로덕트 목표의 서사다. 그래서 이 브리핑/발표를 준비하기 위해 난 주말도 고사하고 시간을 많이 투자했다.
하지만 난 이것 때문에 두 가지 큰 좌절을 항상 겪었다. 그 첫 번째는 사업부(사업부라고 지칭하겠다. 특정 사람을 비난하고 싶지 않기 때문이다. 회사는 보통 그런 거니까.)에서 던져주는 목표의 형태였다. 내 직위에서 받는 스트레스 대부분은 여기에 기인했다. 팀원들에게 전달해야 할 서사가 완전히 빠진 채로 대개 이렇게 전달받았기 때문이다.
“어떤 기능을, 이렇게 구현해서 언제까지 주세요”
하지만, 어떡하겠나. 그들이 나에게 월급을 주는데. 돈에다가 영혼을 팔았으면 응당 그에 대한 대가를 지불해야 하는 법. 아니면 그 조직을 떠나든가. (결국 난 떠났다.)
사업부가 말한 그 기능의 서사를 찾기 위해 온 부서를 쑤시고 다녔다. 이 기능을 요청한 곳이 운영인지, 마케팅인지, 실제 사용자 피드백인지 등 내 권한에서 알 수 있는 모든 권력을 이용하고 남용했다. 도대체 내가 그리고 우리 팀이 왜 이걸 만들어야 하는지 리버스 엔지니어링한 것이다.
그 과정을 통해 드디어 서사의 마지막 퍼즐을 완성할 때면, 나는 하나뿐인 디자이너 엘리에게 이 서사를 제대로 전달할 포맷을 만들어 달라고 가끔 요청했다. 아주 심각한 말투로, 또는 애교로, 또는 맛있는 밥을 해주면서. 엘리는 대학 시절 교수님 전용 PPT 셔틀로 활동할 만큼 실력이 뛰어난 디자이너다. 하지만 나의 이런 부탁 때문에 그녀도 의무감을 가지고 월요일 발표를 위해 거의 밤을 새워 PPT를 만들었다. 이제 다들 내가 이 서사 전달에 얼마나 열심이었는지 이해할 것이다. (이제는 AI로 PPT를 만들지만, 중요한 순간이 온다면 난 여전히 그녀에게 부탁할 것이다.)
하지만 이런 노력에도 불구하고 날 더 좌절하게 만드는 또 하나가 있었는데 바로 이 말이었다.
“개발하기도 바쁜데, 개발자가 비즈니스를 언제 신경 써요?”
지난 회사들에서 특히 본인이 테크 베이스라고 주장하는 일부 주니어 개발자들은 고객과 비즈니스에 중점을 두어야 한다는 나의 조언에 저렇게 대꾸하기 일쑤였다. (일단 여기서 말하는 비즈니스는 단순히 매출 구조도 있겠지만 내가 앞서 서사라고 표현한 고객, 유저 시나리오, 고객 가치 그리고 이걸 통한 가설 등이다.)
초기에만 해도 화딱지가 나고 속으로 부글부글대고 한 대씩 머리통을 갈겨주고 싶은 순간들이 많았다. 그걸 꾹꾹 참고 수많은 우여곡절 끝에 다듬은 나의 감정 통제 기술과 소프트 스킬을 적극 활용하여 길게길게 말로 설명하던 때가 있었는데, 음, 지금 돌아보면 내 스킬들이 역부족이었나 보다. 그들에겐 씨알도 먹히지 않았다.
그런데 그 뒤로 저 대꾸를 듣는 순간 더 이야기하기를 관두었다. 맞는 말이었기 때문이다. 정확히 그들의 대답을 이렇게 이해했다.
“(저는 실력이 없어서) 개발하기도 바쁜데, 비즈니스를 언제 신경 써요?”
암, 그렇고 말고.
앞으로 채용 프로세스에 조금 더 고민해 봐야겠다는 생각만 다시 하게 되었다. 누구 책임이겠는가? 내가 리더인데 내 책임이지.
여전히 바쁘다
지난 글을 쓰고 2달여간 시간이 지났다. 삼체를 읽은 지 얼마 되지 않아 받은 감명과 현재 내가 AI 개발 과정에서 느끼는 위기감과 걱정들을 엮어낸 글은 역대급으로 많은 댓글이 달렸고 반응도 많았다. 특히 대부분은 좌절과 이제는 더 이상 개발자를 하지 않는다, 또는 개발자를 하고 싶지는 않다는 이야기였다.
나 또한 글 한 번으로 끝나지 않고 이 위기감을 해소하고자 《사고외주》, 《읽지 않는 사람들》, 《지능 파산》, 《생각을 넓혀주는 독서법》 등 다양한 책을 읽어냈고 완전히 무관한 문학, 에세이, 경제 경영 도서들을 읽으면서 AI로 작업하는 시간보다 책을 읽고 생각하고 엘리와 얘기하는 시간을 대폭 늘렸다.
요즈음 2달은 꽤 긴 시간이다. AI 모델 발표부터 여러 부분이 또 바뀌었지만 2달 전에 내가 느낀 위기감은 나에게 현실이 되지 않았다. 다행히도(?) 난 지금 Codex 20x pro 계정을 두 개 장착하고 ChatGPT 데스크톱 앱, gpt-5.6-sol과 gpt-5.6-luna를 활용해 여전히 하루 종일 개발하고 있다. 당시에 붕 뜨는 시간은 거의 사라졌다. 작업을 위한 사전 계획(기획, 설계, 디자인)에 쓰는 시간을 최대한 늘리고, 몰아서 집중해 정리한다. AI는 24시간 내가 먼저 끝낸 계획을 위주로 구현을 시작한다. 구현 결과를 확인하기 위한 검증 과정도 최대한 자동화했다. 하지만 결국 내가 직접 프로덕트를 빌드하고 써보고, 오류를 발생시키고 평가하는 데 대부분의 시간을 쓴다.
코드는 2달 전과 마찬가지로 이제 거의 읽지 않는다. 다만 신규 설계가 들어갈 때는 서비스 동작의 멘탈 모델과 메커니즘을 에이전트와 대화하며 채운다. 특히 현재 자체적으로 PI 에이전트 기반 StudyOS(가제)라는 데스크톱 로컬 프로그램에 AI를 물려, 인지 부채가 쌓이는 특정 기능 모듈이나 PR 또는 학습해야 하는 것을 꾸준히 학습하고 있다.
모든 줄을 읽었다는 사실만으로 책임을 다했다고 믿는 시대는 끝났다. 읽지 않은 만큼, 무엇을 직접 확인하고 무엇을 다른 증거로 검증할지는 더 집요하게 결정해야 한다.
오히려 에이전트와 함께 일할 때 가장 큰 장점은 일을 시작하는 데 드는 진입 비용이 거의 제로에 가깝다는 것이다. 나처럼 자기 일을 하는 사람에게는 최고의 환경이다. 아침에는 결과를 확인하고 싶어서 잠이 일찍 깨고, 최대한 에이전트에게 구현을 위임하고 싶어서 밤늦게까지 일하게 된다. 예전에는 코드 작업 자체를 시작하기 전에 항상 약간의 부담이 있었다. 미루고 미루다 쓰는 지금 이 글처럼 말이다. 노이즈 캔슬링 헤드셋을 끼고 인터스텔라 OST를 들으면서 고작 사소한 API 하나에도
“우리는 답을 찾을 것이다. 늘 그랬듯이(We will find a way. We always have.)”
라는 대사를 속으로 외며 웅장하고 거룩하게 작업에 집중하기 위해 여러 준비 작업을 하던 것 말이다. 책상을 치우고 물 한 잔을 채우고 플레이리스트를 고르고 Docker 환경을 열고 터미널을 열고 에디터를 여는 그런 과정들이 모조리 사라졌다.
지금은 24시간 켜져 있는 맥(언제 슬립 모드에 들어갔는지 모르겠다.)의 화면을 켜면 에이전트들이 내가 검토할 결과를 뱉어내고 있다. 쏟아지는 프로덕트를 보며 정말 잘 만들기 위한 고민과 그 디테일을 하나씩 따져보고, 에이전트와 대화하며 또 하나의 기획과 설계를 다듬는다. 그렇게 다듬어졌을 때 이전에 API 하나를 온전히 배포했을 때 못지않은 만족감이 든다. 10분이면 해당 문서의 프로토타입을 HTML로 만져볼 수 있고, 길어도 하루면 그걸 기반으로 구현된 결과를 살펴볼 수 있다.
결과가 100% 만족스러운 경우는 거의 없다. AI는 항상 구현을 어느 정도 축소하고 마치 사람처럼 편한 길을 택한다. 그리고 우리가 드라이브를 걸지 않으면 절대 새로운 길로 가려고 하지 않는다. 미친 듯이 달리는 적토마지만 말고삐를 틀어쥐고 강하게 제끼고 채찍질하고 밀어붙여야 한다. 그렇지 않으면 적토마는 이상한 곳 저 너머로 미친 듯이 달려 나가 버려서 우리는 다시 출발점으로 돌아와야 할지도 모른다.
우리가 방향을 제대로 잡기만 한다면 우리에게 모자란 건 말 먹이(토큰)뿐이다. 말 먹이가 떨어질 때쯤이면 항상 Tibo의 X를 예의주시하며, 그가 무소불위의 권력을 휘둘러 리셋해주길 간절히 기도한다. 그리고 먹이를 듬뿍 먹은 적토마를 몰고 다시 힘차게 앞으로 나아간다.
내가 전하려던 말은 딱 하나다. 그렇다.
개발자는 끝나지 않았다.
AI 시대에 우리에게 요구되는 건 하나다.
바로 상상력.
난 요즈음 내 상상력의 한계를 뼈저리게 느끼고 있다. 이 도구(AI)를 가지고 할 수 있는 역량은 결국 당신의 상상력에 달려 있기 때문이다. 그것이 기능의 고도화이든, 새로운 기술 스택이든, 비즈니스이든, 콘텐츠이든 당신이 결국 이 도구로 만들어내는 모든 결과물은 당신이 가지고 있는 상상력의 원대한 크기와 깊이, 즉 우리 머릿속 이매지네이션(영어가 좀 그럴듯해 보여서)의 해상도에 달려 있다. 용산 IMAX급 스크린 크기에 스크린 한 픽셀도 낭비되지 않고 디테일한 돌비 비전과 돌비 사운드를 갖춘 당신의 상상력은 그것이 디테일할수록 AI에게 위임하기 편할 것이다.
그렇다. “우리는 답을 찾을 것이다. 늘 그랬듯이”
상상력의 크기와 깊이, 그리고 해상도. 지금 시대의 개발자(엔지니어)들에겐 그것이 필요하다. (엔지니어라는 표현이 더 맞지만, 그냥 이제는 모든 개발자가 변해야 하는 시대니까 개발자라고 계속 지칭하겠다.)
개발자는 끝나지 않았다. 상상력의 크기와 깊이를 가지고 있다면 당신은 AI 시대에 더 좋은 개발자가 될 수 있다.
하지만, 당신의 의문은 해소되지 않았을 것이다. 여전히 이 시대가 주는 갑갑함. 무력감. 좌절감은 우리에게 남아 있다. 취업도 잘 안 되고 성장도 안 되고 일의 재미도 여전히 예전보다 많이 떨어진 것 같다.
오케스트레이터니 리더가 되어야 한다느니 어쩌느니 하는 이미 유명한 네임드들의 뭔가 뜬구름 잡는 팟캐스트, 유튜브들은 잠깐 내려놓고 당장 우리가 해야 할 것들은 여전히 모르겠다.
개발자는 끝났나보다 더 중요한 질문은 “그래서 우리는 이제 어떻게 해야 하는가?”이다.
다시 서문의 이야기로 돌아가 보자.
“개발하기도 바쁜데, 개발자가 비즈니스를 언제 신경 써요?”
문제는 문제야, 바보야 (It’s the problem, stupid)
다시 한 번 말하지만 개발자는 끝났다. 앞에서 낙관적인 소리를 하면서 개발자는 끝나지 않았다고 그렇게 말해놓고 갑자기 뭔 소리냐고?
코드만 쓰는 개발자, 이슈 티켓만 치던 개발자는 끝났다는 얘기다.
예전에는 디자이너나 운영, CS에서 이슈 티켓이 들어올 때마다 엄청난 스트레스에 시달렸다. 빠듯하게 움직이는 배포 타임라인에는 이슈를 처리할 시간적, 정신적 여유가 없다. 이미 해당 기능을 개발한 개발자는 다른 스프린트를 달리고 있고, 그마저도 빠듯한 일정인 상태다. 그에게 한두 번 노티를 주긴 했지만 나도 안다. 푸시하는 것 자체가 미안할 지경이다.
내가 직접 만든 프로덕트를 고객들이 하나둘씩 지적할 때도 마찬가지다. 이건 잘못되었다. 오류가 생긴다. 안 된다. 등등. 사용자들에게 그런 피드백을 지속적으로 받는 과정도 쉽지 않다. 누가 무플보다 악플이 낫다고 했나? 무조건 무플보다 선플이 낫다. 악플은 어떤 경우에도 좋지 않다. 그래서 개발자들은 항상 이런 말을 달고 산다.
“시간이 없다. 그건 중요하지 않다. 우선순위가 아니다.”
고객을 신경 쓰기엔 개발하기도 바쁜 사람들이 무슨 기준인지는 모르겠지만 이런 말을 달고 산다. 아마 대부분은
“(그것까지 할) 시간이 없다. (내 지금 일정에선) 그건 중요하지 않다. (현재 일정에서 그건) 우선순위가 아니다.”
일 것이다. 대부분의 경우에 맞는 말이다. 정말 바쁘기 때문이다. 적어도 내가 거쳐온 조직에서는 야근이 일상이었고, 주말까지 반납해 일하는 개발자도 수두룩했다. 혹시나 당신이 아직도 개발자를 희망하는 비개발자인데도 워라밸이 보장되는 개발자의 삶에 환상을 가지고 있다면 환상을 버리든지 개발자를 더 이상 희망하지 마라.
그런데 이제 세상이 바뀌었다. 작년 11월 Opus 4.6 릴리즈 시점부터 이슈 티켓은 나에게 더 이상 이전만큼의 정신적 에너지를 요구하지 않는다. 이슈 분석도, 해결도, 테스트도 AI가 다 해주니까. 지금 내가 만들고 있는 기능 구현 대부분도 AI에게 위임하고 있다. 오히려 딸깍 돌려놓고 이런 피드백을 뒤늦게 받아 AI로 수정하고 있는 스스로에게 죄책감이 들 정도다. 난 지금 돈을 받은 만큼의 책임과 직업적 의무를 다하고 있는 건가!?
AI가 매주 천 건이 넘는 코드 변경을 만들고, 사람이 이를 검토해 반영하는 조직도 이미 있다. 어떤 일을 AI에게 맡길지, 결과를 어디까지 믿을지, 무엇을 확인한 뒤 반영할지는 여전히 개발자가 결정한다. 코드를 직접 쓰는 일은 줄었지만, 오히려 내가 쓰지 않은 결과를 어디까지 믿고 누가 감당할지 결정하는 일이 남았다.
그렇다면 우리는 줄어든 노동만큼 책임까지 내려놓고 있는 건 아닐까?
당신의 직업적 의무에 대한 죄책감과 책임감을 느끼고 있다면, 당신은 가능성이 있다. 당신은 대부분의 경우 좋은 사람이다. 하지만, 어떻게든 지금 이 기회로 어떻게든 더 편하게 일을 덜하려고 죄책감없이 궁리하고 있다면, 당신의 앞날에 행복을 빌고 앞으로 나와는 마주치지 말았으면 좋겠다. 그리고 그냥 여기까지 읽었으면 그만 나가도 좋다. (죄책감을 가지고 궁리하는 건 괜찮은 것 같다.)
결론은 단순하다. 우리는 코드를 타이핑하는 부분에서 많은 경제적 가치를 생산했다. 개발자가 코드만 쓰는 사람이 아닌 것도 맞고, 설계가 중요할 수도 디버깅이 중요할 수도 코드 리뷰가 중요할 수도 있다. 하지만 “우리가 코드만 쓰는 줄 알아요?”라고 아무리 발끈해봤자 실제로 현장에서 개발자의 노동 가치를 시간으로 환산할 때 절대적인 시간은 코드 작성(과 읽기)에 있었다. 즉, 단순 코더냐 멋들어진 소프트웨어 엔지니어냐 이전에 모든 개발자는 어쨌든 코더다.
목적도 중요하고 비즈니스도 중요하지만, 애초에 코드를 잘 쓰지 못하는 개발자는 직업적 존재 의의가 없었다는 것이다. 솔루션도 중요하다. 개발자의 사전 지식에 따라 요구사항에 대한 적절한 설계, 기술 솔루션 도입은 비즈니스 성장을 원활하게 하고 발목을 잡지 않는다. 개발만 잘해서 비즈니스가 성공하는 케이스는 사실 희소하다고 본다.
정말 기술 베이스가 아니고서는 대부분 비즈니스는 비즈니스 전략에 의해 결정되고, IT 비즈니스의 핵심인 소프트웨어도 많고 많은 구성 요소 중 하나일 뿐이다. 하지만 개발을 잘 못해서 망하는 비즈니스는 수두룩하다. 잘못된 설계 판단으로 쌓인 더 이상 갚지 못하는 기술 부채, 섣부른 기술 솔루션 도입, 잘못된 엔지니어링 팀 인사 구성 등등. 여기에 힌트가 있다. 잘하는 개발자는 이미 이전부터 당장 주어진 요구사항 이상을 본다.
이걸 고객이, 사용자가 어떻게 쓸 것인지. 정말 우리가 풀려는 문제가 무엇인지. 앞으로 회사 전략, 비즈니스 전략, 프로덕트 철학을 생각했을 때 어떻게 확장될 수 있을지. 어떤 트레이드오프로 어디까지 신경 써야 할지. 테스트를 어떻게 할지, 배포 후에도 주기적으로 어떻게 개선해 나갈지 등등.
단순히 주어진 요구사항을 코드로 구현하는 걸 떠나서 전방위적으로 전략을 고려하여 기술 아키텍처를 채택한다. 그때 타협하는 것은 갚을 수 있는 부채가 된다. 갚을 수 있는 부채는 자산이 되지만, 갚지 못하는 부채는 그냥 망하는 것이다. 우리의 적토마(AI)는 내가 말고삐를 놓고 눈을 감고 있어도 정말 빠르게 달릴 수 있다.
하지만 말의 특성상 앞에 놓인 길로밖에 못 간다. 현재 나에게 주어진 프로젝트 컨텍스트와 구조를 그대로 답습하여 그 기반으로 최적화해 나간다. 프로젝트가 커지면 커질수록 이 구조를 뒤집는 결정을 AI는 하지 못한다. 바로 이 문제가 바이브 코딩 자체는 괜찮지만, 그 결과물은 대부분 별로인 이유다.
여기 모든 문제를 풀 수 있다는 유명한 파인만 알고리즘이 있다.
- 1단계: 문제를 적는다.
- 2단계: 매우 깊이 생각한다.
- 3단계: 답을 적는다.
이 농담 같은 알고리즘에는 엔지니어링의 정수가 그대로 들어가 있다. 이 단계 중에 가장 중요한 단계가 무엇일까? 항상 강조하지만 가장 중요한 단계는 1단계다. 바로 문제를 적는 단계. 우리의 결과물이 이상하고 내가 하는 일에 성과가 안 날 때 우리는 다시 돌아가서 물어봐야 한다.
“근데 문제가 뭐였지?”
모든 문제는 문제를 문제로서 인식하고, 깊이 숙고하는 과정을 거쳐야 해결할 수 있다. 개발자인 당신이 받은 요구사항에는 이미 답이 적혀 있다. 당신이 하는 일은 그 답을 코드로 옮겨 적는 일이었다. 근데 이 답을 코드로 옮겨 적는 일은 이제 AI가 대신한다.
그런데 생각해 보면, 문제를 적고 깊이 생각해 낸 답이 정말 맞는지는 결국 우리가 판단해야 한다. AI가 가끔 나보다 깊이 생각해서 좋은 답을 적기도 한다. 그게 한눈에 자명할 때가 있다. 그 과정에서 우리는 가끔 의욕을 잃기도 한다. 하지만 그 요구사항 이전에 우리는 도대체 무슨 문제를 풀려고 했던 걸까? 꼭 그게 맞는 요구사항이었던 건가?
gpt-5.6-sol을 high로 쓰다 보면 항상 드는 생각이 있다. 아, 이거 좀 오버했는데. 내가 진짜 풀려는 문제에 정말 필요한 해결책이 아니면 구현 계획을 쳐낼 수 있다. 사전에 비싼 토큰을 확 아낄 수 있는 것이다. 1단계, 문제를 잘 적기만 한다면.
이 문제를 문제로 인식하는 단계 중 하나가 바로 내가 서문에서 말한 “누가 사용하고, 왜 그들이 사용하는지”를 파악하는 것이다. 훌륭하신 (본인들 주장에) 테크 베이스의 개발자들이 말한 바로 그 “비즈니스”.
적토마가 힘차게 달리다가 잘못된 방향으로 갈 때마다 고삐를 틀어쥐고 세차게 꺾을 수 있는 사람은, 내가 어디로 가야 하는지를 명확히 아는 사람이다. 우리가 지금 풀려는 문제가 무엇인지 인식하는 사람만이 그 방향을 알 수 있다.
두 대의 엘리베이터가 너무 느려서 사람들의 불만이 지속되자 엔지니어들이 이 문제를 풀기 위해 달려든다. 짝수층? 홀수층? 출근 시간에는 무조건 1층으로 보내는 거? 아니면 엘리베이터를 하나 더 설치할까? 여러 솔루션이 제시되는데 여기에 노련한 엔지니어가 나타나서 이 문제를 해결한다. 바로 엘리베이터 옆에 커다란 거울을 설치한 것이다.
그랬더니 사람들의 불만이 가시적으로 줄었다. 그렇다. 사람들은 엘리베이터를 기다리는 그 시간이 지루했던 것이다. 문제의 핵심은 느린 엘리베이터가 아니라 지루함에서 오는 불만이었던 것이다.
스마트폰을 사용하지 않던 시대, 거울 하나로 사람들의 불만을 엄청난 비용 효율로 해결하면서 엔지니어링의 본질을 말하는 이 오래되고 낡은 예시는 이제 딱히 공감되지 않는다. 지금이라면 분명 더 좋은 엘리베이터 알고리즘을 적용하거나 돈을 투자해서 엘리베이터를 더 만드는 게 나을 것이다.
하지만 이 얘기가 주는 교훈은 여전히 인상적이다. 특히 요즈음처럼 AI로 엘리베이터 열 개는 더 지을 수도 있는 세상에서, 정말 엘리베이터를 더 짓는 게 맞는 솔루션인지, 우리가 해결해야 하는 문제가 정말 그 문제인지를 생각해 보게 한다. 이 이야기가 전하는 엔지니어링의 본질은 여전히 생각해 볼 만하다.
엘리베이터에는 1도 투자하지 않고 그 돈으로 거울을 설치한 후, 거울에 디스플레이를 연동해 광고 지면으로 만들 수도 있다. 사람들의 불만(지루함)도 해소하고 광고비까지 얻게 될지 누가 알겠는가. (그런 관점에서 포커스 미디어는 AI 광고 좀 그만 만들었으면 좋겠다. 엘리베이터 타면 이왕 보는 광고, 재미있는 콘텐츠로 좀 담아달라.)
회사의 프로덕트 철학, 비즈니스 전략, 고객에 대한 이해, 지금 내가 풀려는 문제, 우리가 가지고 있는 비용(일정, 리소스)을 고려하여 심사숙고해서 AI에게 던지지 않으면 대부분의 경우 우리가 만드는 솔루션은 빠른 시일 내에 쓰레기가 될 것이다.
상상력 얘기를 다시 해보자. 상상력은 아무거나 많이 만들어내는 능력이 아니다. 우리가 풀어야 할 문제를 다시 보고, 전달받은 요구사항 밖의 다른 답을 그려보는 능력이다.
예전에는 코드 작성에 시간을 대부분 쓰느라 문제를 제대로 쳐다보지 못했을 수도 있다. 우리의 상상력의 한계는 전달받은 요구사항이 한계였던 시절이 있다. 하지만 그 시절은 끝났다.
내가 진짜 무엇을 하려는지 문제를 제대로 정의하지 않으면 당신은 이제 더 이상 개발자로 경제적 가치를 만들기는 어렵다.
“문제는 문제야, 바보야” (It’s the problem, stupid)
알에서 깨어나기
여기까지 내 얘기를 따라왔다면 코드 작성이 사라진 영역을 어떻게 채워야 할지, 그 문제를 제대로 정의하기 위해 무엇을 해야 하는지 어렴풋이 감이 왔을 것이다. 아직 조금 모호한가? 조금 더 구체적으로 들어가 보자.
직업에 대한 에세이니 채용 시장에 대해 얘기하지 않을 수 없다.
개발자가 일할 수 있는 회사는 여러 종류가 있겠으나 내가 스타트업 전문가(?)(스타트업에서만 일했다는 뜻이다.)이니 총 세 개의 스테이지로 설명해볼 수 있을 것 같다. (모든 회사의 처음은 스타트업이었다.)
- Phase 0, zero to one: 아직 사용자가 없으므로 무엇을 만들지보다 어떤 문제를 상상하고 어떤 신호를 확인할지가 먼저다. AI로 프로토타입 열 개를 만들 수 있지만, 그중 아홉 개를 버릴 줄 아는 일이 핵심이 된다.
- Phase 1, 첫 실사용자와 첫 프로덕션 사고: 기능을 만들었다는 말이 사용자에게 실제로 작동한다는 말과 달라진다. 로그, CS, 재현, 복구, 다시 배포하는 과정이 비즈니스의 일부가 된다. 여기서 “그건 우선순위가 아니다”라는 말을 한 번 더 의심하게 된다.
- Phase 2, 사용자에서 스케일: 이제는 좋은 기능 하나보다 여러 사용자의 데이터, 권한, 비용, 성능, 팀의 작업 방식이 서로 충돌하지 않게 만드는 일이 중요해진다. 개발자는 더 많이 만들기보다 어떤 경계를 만들고 무엇을 제한할지 결정하게 된다.
Phase 2 이상부터는 10명 이내의 회사부터 대기업까지 다양한 스케일을 가지고 있다. Phase 2를 퉁치는 감이 없지 않아 있지만, 나로 말할 것 같으면 처음 창업해서 Phase 0, 1, 2를 모두 겪어봤고 Phase 1, 2의 회사에서도 월급을 받으며 일해보았다.
(아, 혹시 나를 모를 수 있으니 첨언하자면 나는 지금 Phase 0의 회사를 운영하면서 Phase 1, 2 단계의 회사에서 Fractional CTO로 컨설팅하고 있다. 그럴듯한 직함이지만 그냥 파트타임 알바라고 생각하면 된다. 현재 개발 조직에 불안(만)이 있고, 스케일업 직전의 비즈니스 모델이 PMF를 찾아 매출이 나고 있는 회사라면 나에게 연락하면 된다. 그래야 내가 돈을 청구할 수 있으니. 요즈음 비용 구조에서는 주니어 개발자만 두고 파트타임 CTO를 계약하는 것도 좋은 방법이다. 자, 이제 중간 광고 끝이다.)
기능 직무의 유예가 끝난 이유
여기서 회사를 이렇게 나눈 의도가 있다. AI에게 코드를 넘기기 이전 시대를 생각하면, Phase 1인 척하는 Phase 0 팀이 많았고 Phase 2인 척하는 Phase 1 팀도 많았다.
그리고 거기엔 항상 비용이 따랐다. 무슨 말이냐면 한국 테크씬의 노동자들은 전반적으로 국가 창업 지원금과 여러 VC 투자, 모태펀드에 큰 수혜를 받았다. 현재는 적자에서 이익으로 전환한 IT 회사들도(쿠팡, 토스 등) 대부분 투자금으로 생존해 있었다. 특히 내가 지난번에도 언급했지만, 약 5~6년 전에 개발자 초봉 ‘6,000만 원’ 시대가 열린 것도 투자가 활황이었던 그 시기다. 그 시기에 부트캠프도 엄청난 활황이었고 주니어 개발자들도 시장에 쏟아져 들어왔다.
내가 컴퓨터 공학 전공을 선택하던 시절만 해도 개발자의 끝은 치킨집, 그 유명한 ‘Java 두 명 타요’ 등의 분위기였다. 모바일 시대가 열리면서 나도 첫 창업을 했지만, 대개의 경우 열정과 지분, 스톡옵션에 기반했기 때문에 개발자들의 현금 급여는 딱히 좋지 못했다. (참 돌아보니 사람 쓰기 좋은 시대였다.)
하지만 이런 투자 분위기가 4년을 못 갔다. 대략 2023년 전후로 스타트업 씬에서 굵직한 구조조정들이 대규모로 일어났고 문을 닫는 회사도 허다했다. 내가 이전 회사에서 처음에는 개발자 채용에 엄청 애먹다가(지원자 자체가 없었다.), 나중에는 지원자 DB가 거의 터져 나가 검토 업무 자체가 마비될 지경이었으니까.
이 얘기를 길게 하는 건 바로 앞에서 말한 의도 중 하나 때문이다. 몇십억을 투자받아 외형은 이미 Phase 2처럼 보이지만 실상은 Phase 1, 아니 Phase 0인 회사도 꽤 있었다는 반증이었다.
즉, 비즈니스 모델이 제대로 검증되지 않았지만 테크 시장 투자에 힘입어 너도나도 투자를 받았고, 그 돈으로 높은 연봉을 주며 개발자들을 채용해댔다. 그 똑똑한 양반들이 이 시장에서는 모두 멀티플(투자 가치에서 또는 회사 성장 곡선에서)만 외치다가 다 같이 가라앉았다.
개발자들이 뭔 죄랴. 시장의 수요가 있었고 거기에 맞추어 공급해도 항상 모자란 게 개발자였으니. 그러고 한 2년 정도의 유예(?) 기간이 있었다. 투자 시장이 얼면서 그 기간 동안 쉽지는 않았지만, 그래도 증명할 수 있는 커리어만 있었다면 어떻게 어떻게 이직도 가능했다. 신입들이 좋은 기회를 캐치하는 게 아주 불가능한 일만은 아니었다.
그러고 나서 작년부터 AI 모델이 급격히 발전하며 코드 작성 업무를 홀라당 가져가 버렸다. 기업에서는 더 이상 이전과 같은 연봉을 맞춰 사람을 뽑을 필요가 줄었다. 무분별하게 스케일업하고 채용하던 회사들이 쓰러지는 모습을 보았거나 직접 겪은 경영자들이 개발자 채용 자체에 회의적인 것도 너무나 당연한 수순이다.
특히 창업지원금을 받은 Phase 0 회사들도 예전에는 프로토타입을 만들려면 백엔드 하나, 프론트 하나는 채용해야 했다. 잘은 모르지만 외주 시장의 단가도 박살이 나서 박리다매가 되었고, 이제는 외주 의뢰자가 바이브 코딩으로 직접 만든 뒤 “이렇게 만들어 달라”고 요청하는 시대가 되었다. 전반적으로 시장이 쪼그라들었다는 건 적어도 내가 현장에서 직접 체감한 변화다.
내가 지금 Phase 0 회사에 조언한다면, 기능별 개발자를 먼저 채용해서는 안 된다고 말할 것이다. 개발자인 당신이라도 비슷하게 조언할 가능성이 높다. Phase 1에 진입해 이것이 재현 가능한 증거라는 사실을 확인하는 순간부터 개발자 채용을 고민하기 시작한다. 냉정하게 말하면 이 시기의 대표들은 A부터 Z까지, End-to-End로 책임질 수 있는 풀스택 개발자를 원한다. 이전이었다면 이미 이 시기에 프론트 하나, 백엔드 하나, CTO까지 갖추었을 것이다.
사용자 서비스라면 디자이너도 있을 것이고, SaaS라면 PM도 채용했겠지. (여기서 PM은 대부분 고객사 땜빵을 할 것이다. 대표가 하기 싫은 일을 덜어야 하니.) 하지만 지금은? 방금 내가 언급했던 프론트, 백엔드, 디자인, PM(+고객사 땜빵)까지 같이 할 수 있는 개발자 한 명을 원한다.
아니 그 정도 개발자면 자기가 창업하면 되는 거 아니냐고? 창업을 한 번 해봐라. 그걸 잘 만드는 일과 돈을 버는 일은 엄연히 다른 영역이다. (둘 다 잘한다면 꼭 창업을 하시고 나에게 감사의 메시지를 보내달라.) 물론 나도 안다.
그런 개발자를 원한다고 했지, 그런 개발자를 채용할 수 있느냐는 또 다른 차원의 문제다. 사실 거의 없다고 봐야 한다. 특히 주니어 레벨에서는 기대하기 힘들고, 조금 연차가 있으면 난 백엔드요, 난 프론트요 하는 이미 2차 전직을 끝내 버린 개발자들밖에 없기 때문이다. 그래서 회사는 채용 페이지에서 거짓말을 한다.
‘백엔드 개발자’를 뽑는다고 적어 놓고 AI부터 풀스택까지 해주었으면 하고, ‘프론트 개발자’를 뽑는다고 적어 놓고 백엔드부터 디자인까지 해주었으면 하는 것이다. 여기서 채용된 개발자 중 회사가 요구하는 것을 눈치챈 일부 똑똑한 제네럴리스트들은 회사의 솔직한 요구를 수용하고 살아남는다. 어쩌면 이전 시대에는 코딩 능력만 딱히 특출나지 않았던 사람들이다. 나머지 개발자들은 이 말도 안 되는 인식 차이 때문에 또 이직할 수밖에 없다.
어느 정도 규모가 있는 회사들은 여전히 스페셜리스트가 필요하고 기능별 영역도 명확히 나뉘어 있을 것이다. 그것이 그 회사가 만든 시스템이고, 그 시스템은 AI가 도입된다고 하루아침에 바뀌지는 않기 때문이다.
하지만 여기서 내가 보는 슬픈 사실이 두 개 있다. 기능별 직무에서는 신입에게 돌아가는 기회가 급격히 줄고 있다. (스페셜리즘의 경험과 깊이가 아직 없기 때문이다.) 이런 회사들도 지금 막 탄생하는 AI 네이티브 조직에 뒤쫓기는 상황이 오면 결국 파괴적 변화를 선택할 수밖에 없을 것이다.
그러니 기능별 직무(백엔드, 프론트, 디자이너, 데이터 등)를 최대한 오래하고 싶다면, 내가 권할 수 있는 가장 현실적인 선택은 대기업이다. 좋은 명문 학위와 점수로 대기업에 맞는 인재임을 증명하거나 기존 커리어를 최대한 잘 패키징해서 말이다. 조직 단위, 매출 단위가 한 단계 높을수록 자리 보전 기간도 1년씩 늘어날 것이다.
(이 조언으로 이직을 했다면 나에게 꼭 감사의 메시지를 보내자.)
하지만, 이 글은 그런 사람들을 위한 글이 아니다. 우리가 흔히 말하는 네카쿠라배를 기준으로도 그 회사 내 이미 앞서가는 일부 조직들은 변화를 만들고 있고 그러지 않는다면 뒤처진다는 것을 그들도 알고 있다. 시간 문제라는 것이다. 그리고 우리 대부분은 그런 회사에서 일하고 있지 않다.
어쩌면 지금 직무에 대한 위기를 겪고 있는 개발자들도 있을 것이고, 취업하고 싶은데 도저히 취업문이 열리지 않는 신입들도 있을 것이다. (물론 힌트는 앞에서 주었다. 채용 페이지에 속지 마라.) 나조차도 개발자를 채용할 때 풀스택 개발 지원자는 걸러냈던 기억이 있다. 스페셜리즘이 없다고 판단했기 때문이다. 하지만 지금은?
내가 만약 Phase 1, 2가 되어 잉여 이익이 난다면 나는 무조건 하나의 비즈니스 목적을 가진 프로덕트 파트를 전체적으로 담당할 수 있는 개발자를 채용할 것이다. 돈을 주고 고용한다는 것은 내가 돈으로 시간을 사고 싶다는 말과 동일하다. 그 사람의 시간을 내 시간으로. 그리고 이왕이면 내가 시간을 쓰는 것보다 훨씬 효율적이길 바란다.
비개발자 CEO는 개발하는 데 시간을 많이 쓸 것이다. 그래서 이왕 채용되는 개발자가 본인보다 훨씬 더 잘 개발해주길 바란다. 그런데 여기에서 다들 실수하는 게 있다. 여기서 개발을 잘한다는 건 우리가 생각하는 코딩이나 기술을 말하는 것이 아니다.
이 비즈니스 목적을 달성하기 위한 프로덕트 목표 달성을 더 잘한다는 이야기다. 여기서 간극이 생긴다. (물론 CEO가 항상 비즈니스 목적을 달성하기 위해 프로덕트 목표를 제시하는 건 아니다. 비즈니스와 상관없이 말도 안 되는 걸 만들고 있는 경우도 다반사다.)
코드 작성자가 누리던 면죄부
개발자는 애초에 사회에서 덕후 이미지가 있다. 개발자는 사회성이 좀 떨어지고 “그건 그렇게 하는 게 아닌데”라고 혼자 중얼거리며 사람들과 잘 어울리지 못하거나, 맥락에 안 맞는 소리를 하거나, 너무 자존심이 세거나. 아니면 항상 안 된다고 말하는 부정적인 사람이거나, 항상 된다고 해놓고 밤을 새우며 자기 인생을 갈아 넣는 그런 이미지. 한편으로는 어린아이 같고 말도 안 듣지만 조직에서 연봉은 제일 많이 받아가는 그런 존재들. 어떤 건 정말 그런 부분도 여전히 있을 것이다.
이건 축복이다. 사회생활을 하면서 사회적이지 않아도 되는 축복. 소프트 스킬이라는 단어 자체가 웃긴 단어다. 영업직이나 일반 회사원들에게 물어봐라. 그들은 소프트 스킬이라는 단어를 쓰지 않는다. 눈치가 없다고 욕을 먹고 그런 사람들은 고립되고 도태된다. 살아남기 위해 눈치껏 행동해야 한다.
하지만 이 사회화되지 않은 어리석은 개발자 집단은 고작 코드를 친다는 명분으로 사회화라는 사회의 의무를 저버리고, 그걸 마치 추가적인 기술인 양 “소프트 스킬”이라고 명명해 서로 조언한다. 정신 차리자. “소프트 스킬”은 배워야 하는 기술이 아니라 사회와 조직에서 기본으로 요구되는 덕목이다. 왜 이렇게 심하게 말하냐고? 우리가 이런 개발자 “이미지”에 힘입어 비사회화된 행동을 해도 크게 욕먹지 않는 이유, 다른 직무의 모든 사람에게서 면죄부를 얻는 이유는 바로 코드를 작성하는 직무였기 때문이다.
AI 시대에도 여전히 희망이 있다. AI는 우리에게 “코드”를 작성하는 직무를 앗아가면서 그에 대한 면죄부도 가져갔지만 AI의 강력한 파워를 활용하면 그 모든 특권을 누리면서 혼자 일하는 것도 절대 불가능하지 않다. 앞서 말했지만 창업하라. 혼자 일을 해내면 된다. 아무도 당신의 비사회화된 면을 비난하지 않을 것이며(그것은 당신의 성공을 위한 서사가 될 것이다.), 성과를 내기만 하면 우러러봐줄 것이다. (꼭 나에게 감사 메시지를..!)
하지만 남은 나머지 개발자들은 어떻게 해야 할까? 여전히 AI에게 빼앗긴 직무로 불안에 떨며 월급을 받아가면서 죄책감을 느끼는 우리들 말이다. 이제 그만 알에서 깨어나라. 코드 작성자의 권위는 끝났다. 사회화되지 않은 개발자는 도태될 것이고, 이제라도 모든 직무에 관심을 두고 내가 진짜 해야 할 일이 뭔지 다시 생각해야 한다. 내 월급이 어디서 나오는지 말이다.
프로덕트 개발자
AI 개발이 보편화되기 훨씬 직전에 유행했던 새로운 직무 정의명이 있다. 바로 “프로덕트 엔지니어”.
시작이 X(트위터)였는지 모르겠지만 일부 주니어 개발자, 특히 프론트엔드 개발자들이 본인은 프로덕트 엔지니어를 지향한다는 얘기를 많이 했는데, 나도 면접에서 종종 이런 말을 들었다.
나에겐 이것도 마치 “소프트 스킬”처럼 의아한 직무 정의였다. (과연 그들이 프로덕트 엔지니어를 지향한다는 말의 뜻을 정말 이해한 것인지, 아니면 기술 지식의 미흡함과 경험 부족을 포장하기 위한 답변이었는지는 알 수 없지만.) AI로 할 수 있는 만큼 난개발을 벌이는 요즈음에는 오히려 정말 필요한 직무 정의가 아니었나 싶다.
정확한 정의를 살펴보면 다음과 같다.
드루 호스킨스의 《The Product-Minded Engineer》에서 프로덕트 사고(Product Thinking)를 다음과 같이 정의한다.
“사용자와 사용자의 배경지식·필요, 사용자가 밟는 행동의 순서, 집단의 역학, 그리고 이들을 지원하는 디자인 기법과 정보구조를 이해하는 것.” “Product thinking comprises understanding users, their background knowledge and needs, their sequences of actions, and group dynamics—plus the design techniques and information architectures that serve them.”
그리고 저자의 인터뷰를 찾아보면 프로덕트 엔지니어를 이렇게 정의한다.
“‘어떻게 만들 것인가’만큼 ‘무엇을, 왜 만드는가’를 중요하게 생각하는 엔지니어.
그리고 “무엇을 하고 있으며, 누구를 위해 하고 있는가?”를 계속 묻는 사람입니다.”“An engineer who cares at least as much about the what and the why as the how. So what are they doing and who are they doing it for?”
기시감이 들지 않나?
“누가 사용하고, 왜 그들이 사용하는지”
맞다. 내가 서문에서 그렇게 강조하던 서사. 또는 (일부) 개발자들이 비즈니스라고 치부하며 외면하려던 바로 그것이다.
여기서는 이렇게 정의한다.
- 제품 관리자(Product Manager)와 풀스택 소프트웨어 엔지니어의 결합형 역할
- 전체 제품 주기를 책임지고, 제품의 성패에 직접적으로 연관되는 인재
더 나아가서 조직 구조는 기존의 프론트엔드/백엔드/인프라 분리 대신, 제품·기능 단위(feature squad) 중심으로 조직되고 스택별로 나뉘지 않고 성과(outcome) 중심으로 정렬되는 것이다.
여기서는 이미 이렇게 정리하고 있다. 우리가 흔히 생각하는 기술 스택은 한 명의 풀스택 소프트웨어 엔지니어가 맡고, 거기서 한 발 더 나아가 제품 관리자(Product Manager/PM)의 역할까지 요구하는 것이다. AI 시대 이전에는 이런 관점이 조금 과한 요구처럼 느껴졌지만, 이제는 한 명이 이러한 직무를 수행하는 게 불가능하지 않은 시대가 되었다.
시장에서 여러 회사와 협업해 보면 새로운 기업, 특히 스타트업일수록 프로덕트 엔지니어의 역할이 빠르게 반영되고 있다. AI가 점점 더 자율성을 갖출수록 전통적인 PM–디자이너–엔지니어 삼각형 구조도 약화될 가능성이 높아 보인다.
비슷한 장면은 현업에서도 벌어진다. 얼마 전 SNS에서는 개발자가 바이브 코딩으로 만든 디자인 시안을 디자인 팀에 넘긴 이야기가 이슈가 되었다. 선을 넘었다, 월권 행위다, 싸가지가 없다, 태도가 문제라는 비난이 쏟아졌고 많은 사람이 그 비난에 동조했다.
이 과도기적 행태를 둘러싼 반응을 보며, 이미 분절된 R&R이 사라지고 통합된 AI 네이티브 조직으로 미친 듯이 성장하는 해외 유수의 조직 사례가 떠올랐다. 이 거대한 AI 시대에 우리가 정말 충분한 경쟁력을 가지고 있는가, 아니 가질 수 있는가에 대한 깊은 유감이 들었다.
이 변화가 왜 필요한지 보여주는 장면을 최근에도 보았다. 취준하는 친구들이 모여 기업 연계 AI 프로젝트를 진행하는 모습을 볼 기회가 있었다. 해당 그룹은 전형적인 기능 직무별로 구성되어 있었고, PM을 지망하는 친구가 PM 포지션에서 활개를 치는 모습을 심심찮게 볼 수 있었다.
개발자가 기술 얘기를 하면 “그건 우리가 알아야 할 필요가 없다”, 디자이너가 디자인 얘기를 하면 “그것도 우리가 자세하게 알 필요가 없다”라고 선을 그었다. AI 프로젝트에 사용할 API 서비스 리서치는 개발자에게 떠넘기면서 실제 프로젝트 수행 목표와 동떨어진 확장성 설계를 외쳤다.
취준생들끼리 모인 그룹에서 벌어지는 이 웃기지도 않는 희극, 아니 비극을 옆에서 보고 있자니 뼛속 깊이 좌절감이 들었다. 이 정도면 내가 무슨 말을 해도 바뀔 것 같지가 않다. 이런 상황에서 나에게 취업이 잘 안 되는 것 같아 조언을 구하기라도 한다면 당장 그 자리에서 도망가고 싶어질 것이다. 난 여기서 당신에게 말한 것처럼 친절하게 다시 말할 자신이 없기 때문이다.
그렇다고 기능별 직무가 당장 완전히 사라졌다는 뜻은 아니다. 기능별 직무로 취업하는 것도 현재 시장에서 아예 불가능한 일은 아니다. 다만 내가 만난 시장을 기준으로 보면 수요가 줄었고, 앞서 말한 여러 이유로 경쟁이 치열해진 것도 맞다. 거기서 상위 그룹에 들 실력이 있거나 이미 그런 경력과 경험을 쌓은 개발자라면 아직 직업적 수명이 남아 있다고 생각한다.
하지만 신규 스타트업의 SaaS 종말론처럼 작은 틈이 빠르게 줄어들고 있듯이, 이제 시작하는 개발자에게 기능별 직무로 일할 기회는 빠르게 줄어들고 있다고 봐야 한다. 적어도 부트캠프에서 React 프로젝트 12주, Spring 교육 12주를 받고 곧바로 취업하던 시절은 지나가고 있다.
요즈음 몇몇 부트캠프는 여기에 AI 교육을 덧붙여 직무 교육을 강화하고 있다. (AI 백엔드 개발자 양성과정은 도대체 뭘 양성하는 걸까.) 제발 그들이 책임감을 가지고 기업의 솔직한 수요를 파악해 차라리 제대로 된 프로덕트 엔지니어 양성 과정을 만들었으면 한다. 그 광범위한 업무 스킬을 과연 12주 안에 교육할 수 있는지는 차치하고라도 말이다.
이 글은 신입만을 위해 쓴 글은 아니다. 하지만 혹시 당신이 기능별 직무만 준비했던 사람이라면 선배들보다 신입인 당신만이 할 수 있는 일이 무엇인지, 그 길이 무엇인지 깊이 고민해 보았으면 좋겠다. 또한 이 글이 그에 대한 단서가 되었으면 하는 바람이다.
시장은 결과에 돈을 지불한다
왜 프로덕트 개발자가 필요한지 이해하려면 AI 시대의 비즈니스가 무엇에 돈을 지불하는지 들여다볼 필요가 있다. 이전 SaaS 모델들은 고객의 전체 라이프사이클 중 한 지점에 집중해 MVP를 만들고 초기 고객을 만족시키며 스케일업했다. 이후 시리즈 B, C 단계로 올라서면서 한 기능에 집중하던 제품이 점차 고객의 전체 라이프사이클을 책임지는 모델로 성장한다.
내가 익숙하게 보아온 SaaS 비즈니스의 성장 경로도 이와 비슷했다. 쉬운 예로, 소규모 팀에 Task 관리 툴을 제공하던 스타트업이 성장해 문서 툴이나 커뮤니케이션 툴까지 확장하는 그림을 생각해 보면 된다. Notion은 팀 클라우드 메모 프로덕트에서 커뮤니케이션과 Task 관리까지 포함한 툴이 되었고, Slack도 커뮤니케이션에서 시작해 Task 관리와 문서 툴까지 제공하고 있다.
제품이 너무 비대하고 복잡해지고 그로 인해 비용이 상승하면 소규모 니치 마켓에 틈이 생겼다. (기존 툴에 불만을 가진 사용자들이 그 틈으로 이동했다.) 새로 시작하는 기업들은 그곳에서 기회를 발견했다. 그렇게 수많은 스타트업이 성장하고 망하는 과정을 우리는 쉽게 떠올릴 수 있었다.
하지만 지금은 그 작은 틈 때문에 굳이 다른 SaaS를 사용할 필요가 줄어들었다. 팀에서 필요한 것을 직접 만들어 써도 될 만큼 AI 성능이 비약적으로 상승했고, 실제로 주변의 많은 조직이 간단한 관리 툴 정도는 직접 만들어 쓰고 있다. Slack이나 Notion 같은 프로덕트는 이미 고객의 라이프사이클 전반으로 확장되었고 많은 조직이 해당 SaaS에 락인되어 있기 때문에, 아직은 직접 만들기보다 가져다 쓰는 편이 이득일 수 있다.
하지만 내가 보는 한, 빅 플레이어들이 놓치는 작은 틈은 빠르게 줄어들고 있다. 최근의 SaaS 종말론도 이미 자리 잡은 빅 플레이어 SaaS 제품이 당장 사라진다는 뜻이라기보다, 작은 틈만 겨냥한 제품이 들어갈 시장이 크게 줄어들었다는 의미에 가깝다. 이제 작은 팀도 그 정도의 프로덕트는 직접 만들 수 있는 시대가 되었으니 말이다.
다행히 AI는 이런 기회를 빼앗는 동시에 새로운 기회도 제시한다. 예전에는 시리즈 C에서 수백억을 투자받아야 확장할 수 있었던, 고객의 전체 문제를 책임지는 프로덕트를 훨씬 작은 팀이 짧은 시간에 개발할 수 있게 된 기회 말이다.
비즈니스 규칙은 아주 간단하다.
- 고객은 문제를 느낀다.
- 문제를 해결할 솔루션을 찾는다.
- 솔루션으로 획득되는 비용이 솔루션에 사용되는 비용보다 초과된다면 고객은 기꺼이 돈을 지불한다.
비약이 있을지언정 SaaS 비즈니스든 사용자 B2C 앱 비즈니스든 모든 IT 프로덕트는 결국 이 비즈니스 규칙 아래에 있다. 그런데 이 규칙에 의하면, 우리 팀이 사용하는 Task 관리 툴 정도는 이제 돈을 내고 쓰는 것보다 직접 만드는 게 비용이 더 저렴해져 버렸다.
하지만 팀이 정말 성과를 내게 하는 프로세스나 라이프사이클 전반의 문제를 해소하는 일은 여전히 난이도가 있다. 커뮤니케이션 툴을 직접 만들까 하다가도 노트부터 Task 관리, 영상 통화, AI 요약까지 SaaS가 한큐에 제공한다면 여전히 솔루션의 가치가 존재하는 것이다. 여기서 착각하지 말아야 할 것이 하나 있다. 내가 말하는 결과까지 책임지는 솔루션은 있는 기능을 모두 집어넣은 짬뽕을 만들라는 뜻이 아니다. 하나의 프로덕트가 고객의 전체 라이프사이클을 깊이 있게 책임지며 고객이 직접 성과를 내게 하는 것. 그것이 결과까지 책임지는 솔루션의 목표다.
개발자의 미래를 논하는 자리에서 이러한 비즈니스 구조를 설명하는 것은(어느 정도 짐작하겠지만) 필연적이다. AI 시대가 되면서 내가 체감하는 변화는 고객이 과정을 일부 해결해주는 솔루션보다 결과에 가까이 데려다주는 솔루션에 더 기꺼이 돈을 쓴다는 것이다.
이걸 그대로 우리의 일로 치환해 보면 우리가 백엔드니 프론트엔드니 디자인이니 하는 기능 직무는 결국 과정과 수단이다. 거기서 나오는 산출물(Output)만으로는 성과(Outcome)를 담보할 수 없다. 하지만 성과(Outcome)가 있다면 그에 필요한 산출물(Output)은 따라올 수 있다. 내가 보기에는 산출물(Output)만 만들어내도 경제적 가치를 인정받던 시대가 끝나가고 있다. 시장이 실제로 그렇게 움직인다면 조직의 채용 구조도 결국 그 방향으로 바뀔 수밖에 없다.
다시 프로덕트 엔지니어로 돌아가 보자. 여전히 프로덕트 엔지니어에 대한 광범위한 직무를 정의하며 설명하면 몇몇 개발자들은 그거 그냥 PM이 바이브 코딩하는 거 아니냐 정도로 치부하고 만다. 지금 이 글을 읽고 있는 당신조차도 마지막 한 줌의 희망을 잃지 않고자 내 얘기를 삐딱하게 듣고 있을 수도 있다. 내 미천한 글솜씨로 충분한 설득력을 전달하지 못한 것이니 전적으로 내 책임이다. 그럼 그만 읽고 나가도 좋다. 다만 너그러이 마음의 준비가 되면 다시 돌아와서 여기서부터 다시 읽어주면 좋겠다.
그렇다. 개인은 시대의 흐름을 막을 수는 없다.
인간은 자유의지가 없다. 여기서 자유의지가 없다는 말은 어떠한 노력을 하든 결과가 이미 정해져 흘러간다는 운명론을 뜻하지 않는다. 인간은 (어느 면에서는) 기계에 가깝고, 어떤 환경이 주어지면(input) 대부분 그 환경에 맞게 행동할 수밖에 없다는 뜻이다.
극단적으로 생각하면 일하느라 3일을 굶은 사람에게 야근을 강요하면 살인이 일어날 수 있다. 인생에서 손꼽히는 크나큰 시련이 갑자기 닥친다면 지금 이 글도 도저히 읽지 못할 것이다. 오늘 열심히 하자고 마음먹고 침대에 앉아 일하겠다고 다짐하기보다, 침대를 박차고 나와 카페로 가는 편이 업무 수행 능력을 훨씬 높여줄 것이다.
육체, 호르몬, 매일 접하는 콘텐츠, 사람들, 공간에 우리는 모두 직접적으로 영향을 받는다. 그래서 나는 올바른 판단과 탁월한 업무 성과를 내려면 충분히 자고, 적당히 먹고, 좋은 사람과 대화하며 좋은 환경에서 일해야 한다고 생각한다. (의지력은 정말 중요한 개인의 요소지만, 힘들게 환경과 싸우며 의지력을 낭비하느니 환경을 바꾸어 쉽게 만드는 편이 인생에 100배는 이롭다. 혹시 내 관점이 더 궁금하다면 로버트 새폴스키의 《모든 것은 결정되어 있다》를 추천한다.)
하물며 이런 주변 환경에도 이렇게 약하디 약한 인간인데, 우리는 과연 이 거대한 AI 시대에 흐름을 막을 수 있느냐 말이다. 개발자인 당신에게 지불되는 경제적 가치는 결국 고객의 주머니에서 나온다. 당신도 지불하지 않는 가치에 왜 당신은 그것으로 경제적 가치를 얻으려고 하는가. 결국 이건 본질에 대한 문제이다.
가속화된 본질
분명 회사의 규모는 Phase 2인데, 여전히 Phase 1 심지어는 Phase 0에 머무른 회사들도 있었다. 그리고 회사의 규모만 보고 프로덕트 조직은 문화를 만들고 기능별 직무를 나누고 프로세스를 만들고 전문성 있게 일해야 한다고 내부에서 외친다. 이것이 지난 몇 년간 테크 시장에 쏟아져 들어간 비정상적인 투자금을 받은 부작용이다.
Phase 2(~3, 4, 5 또는 그 이상)처럼 보이는 회사에 직원들을 뽑아놓고 Phase 1 또는 0의 마인드셋을 요구하면 직원들은 불만만 생긴다. 왜 우리 회사는 프로세스가 없냐고 불평하고, 지금 중요한 건 생존인데 프로세스를 외치는 직원들을 보며 리더들은 좌절한다. 본인들이 다 좌초한 일인데 말이다.
본질은 동네 구멍가게도 안 되면서 그저 외형만 키워, 투자받은 돈으로 위대한 기업인 삼성인 양 시스템을 만들고 프로세스를 만들다가 그 돈을 다 날려 먹는 것이다. 당신이 일하는 회사에 프로세스가 없다고 느낀다면 당신은 두 가지 선택권이 있다. 이제라도 프로덕트 엔지니어가 되어 회사의 Phase를 끌어올리는 핵심 개발자가 되는 방향, 아니면 빨리 퇴사하는 방향이다.
만약 본인의 임파워먼트(Empowerment - 개인이나 집단이 자신의 삶과 업무, 환경에 대한 통제력과 자율성을 기르고 스스로 결정을 내릴 수 있는 힘과 역량)를 발휘해 전자의 선택을 할 수 있다면 그 조직에 머물러라. 대표님께 가서 정신 차리라고 한마디 해주고 본질에 집중하자고 하라. 그리고 일 못하는 놈들 내보내고 연봉을 더 올려달라고 하자. 제대로 된 회사라면 대부분 이 선택이 좋은 방향이다.
(그게 아니라면.. 내가 당신의 모든 경제적 책임까지 져줄 의무는 없고, 내 조언에 대한 책임은 어디까지나 귀하에게 있으니 혹시 일이 잘못되더라도 날 탓하지 말자. 투자와 퇴사는 언제나 개인의 책임이다.)
이제 우리 모두는 알에서 깨고 나와야 한다. 회사에서 정해준 대로 시키는 것만 해서 살아남았던 시대는 저물고 있다. 당신이 그 어떤 기술에 대한 깊이를 가지고 있더라도 그것이 성과(Outcome)로 연결되지 못하고 산출물(Output)에 불과하다면 이제는 더 이상 안전하지 않다.
AI가 우리 일자리를 빼앗아 간다고? 천만에 말씀. 회사도 당신도 사회도 외면하던 바로 그 진실, 자유시장 경제 가치, 즉 우리의 경제적 가치는 어디서 발생하는가라는 본질적 물음을 외면하고 코드만 작성하면 되던 그 시절을 빼앗아 간 것이다.
AI는 원래 드러나야 할 모든 본질적 가치에 대한 물음을 가속화했을 뿐이다. 응당 그래야 하는 것을 응당 그렇게 보이도록 했다는 말이다. 고객은 원래 본인이 얻는 실질 가치에 돈을 냈어야 했고, 개발자는 본인의 제품 성과에 책임을 가졌어야 했다. 하지만 이래저래 코드를 작성한다는 핑계로 미루고 미루며 감춰왔던 그 사실들이 AI로 인해 적나라하게 벗겨진 것이다.
아마 이런 질문이 남을 것이다
“회사가 권한도 정보도 주지 않는데, 개발자가 어떻게 결과까지 책임지는가?”
맞다. 권한 없이 책임만 요구하는 건 오너십이 아니라 착취다. 내가 말하는 책임은 회사의 모든 결과를 개발자 혼자 뒤집어쓰라는 뜻이 아니다. 내가 가진 권한 안에서 요구사항 뒤의 문제를 묻고, 필요한 정보와 권한을 요구하고, 무엇을 확인하지 못했는지를 드러내는 것까지가 책임이다.
앞에서 말한 임파워먼트는 회사가 언젠가 충분한 권한을 내려주기만 기다리는 태도가 아니다. 자신의 업무와 환경에 대한 통제력과 자율성을 기르고, 문제를 해결하는 데 필요한 정보와 권한을 요구하고, 이미 가진 권한은 실제로 행사하며, 스스로 결정을 내릴 수 있는 힘과 역량이다. 조직이 그 요구를 계속 거부하면서 결과에 대한 책임만 요구한다면 그것은 개인의 태도로 해결할 수 있는 문제가 아니다. 그리고 프로덕트 개발자가 되라는 말도 PM과 디자인과 개발을 한 사람에게 공짜로 떠넘기라는 뜻은 아니다. 더 넓은 결과를 요구한다면 그에 맞는 권한과 보상도 함께 주어져야 한다.
“코드를 거의 읽지도 않으면서 어떻게 결과를 책임진다고 말할 수 있는가?”
책임은 AI가 만든 모든 줄을 내가 직접 읽었다고 증명하는 일이 아니다. 그렇다고 코드를 읽지 않아도 된다는 뜻도 아니다. 중요한 것은 그 프로덕트가 어떤 과정으로 동작하는지에 대한 멘탈 모델을 내가 가지고 있느냐는 것이다. 데이터가 어디에서 들어와 어떤 상태를 거쳐 사용자에게 도달하는지, 그 사이에 어떤 의존성과 실패 가능성이 있는지를 설명할 수 있어야 한다.
해피 패스가 동작하는지만 확인하는 것으로는 부족하다. 외부 API가 실패하거나 응답이 늦어질 때 어디로 폴백할지, 일부 작업만 성공했을 때 어떻게 복구할지, 재시도와 중복 실행은 어떻게 다룰지, 데이터가 어긋났을 때 무엇을 기준으로 되돌릴지, 사용자가 예상하지 못한 행동을 했을 때 어떤 경험으로 돌아오게 할지까지 예외 처리 시나리오를 디테일하게 설계해야 한다. 위험한 설계와 중요한 로직은 직접 읽고, 나머지는 테스트와 로그, 실제 사용, 배포와 복구 과정으로 검증한다.
AI 시대에 개발자의 책임은 모든 코드를 직접 타이핑하고 읽는 데서, 무엇을 직접 확인해야 하고 무엇을 다른 증거로 검증할지 결정하는 쪽으로 이동한다. 결국 읽지 않는 것이 무책임한 게 아니라, 무엇을 왜 읽지 않아도 되는지 설명하지 못하는 것이 무책임하다.
이 글을 읽는 경영자와 리더에게
혹여 이 글을 읽고 신이 나서 팀에 섣불리 뿌려 반발을 만드는 어리석은 짓은 하지 말자. AI 시대에 당신이 원하는 개발자 또는 직원이 이 글에서 말한 모습과 가깝다면, 먼저 회사의 목표가 무엇인지, 직원들에게 그만큼의 임파워먼트를 줄 수 있는지, 그에 걸맞은 연봉과 보상을 제공할 수 있는지 고민해라.
직원들이 성과를 보여주면 그때 보상하고 싶다고? 제발, 정신 차리자. 당신이 좋은 리더라서, 자격이 충분해서 그 자리에 있다고 생각하나? 아니다. 그냥 어쩌다 보니 그 자리에 있는 것이다. 리더 역시 끊임없이 증명해야 하는 자리다. 마찬가지다. 그에 걸맞은 권한과 보상을 먼저 제공하고, 그 책임 아래 직원이 증명하게 해라.
AI를 핑계로 개발자를, 아니 사람을 줄이는 상상만 하지 마라. 그들에게 더 많은 권한을 주고 더 큰 책임을 맡겼을 때 어디까지 갈 수 있는지를 상상해보아라. 사람을 덜 쓰는 상상은 누구나 한다. 사람을 더 멀리 보내는 상상력이야말로 리더가 해야 할 일이다.
당신들의 상상력만이 우리 개발자들을 구원하리라.
그게 아니라면 이 글은 팀 안에서 반발심과 부정적 여론만 만들고, 당신이 생각하는 조직 구성의 목표는 또 한 번 멀어질 것이다. 거시적 국가 경쟁력을 위해서라도 리더들은 더 똑똑하게 움직여야 한다. 당신들은 그만큼의 권한을 가진 만큼, 그만큼의 책임도 있다.
나가며
처음에 이 글을 쓸 때는 온갖 사례를 리서치해서 AI 시대 개발자의 역할과 생존법, 어떻게 성장해야 하는지, 신입과 주니어와 시니어는 무엇을 해야 하는지를 쓰는 게 목적이었다. 리서치도 충분히 하고 글감도 찾고 기승전결이 완전한 글 구조도 세웠다. 하지만 AI가 만든 듯 완벽한 그 글 구조를 보고 있자니 아무것도 작성하고 싶지 않았다. AI가 좋다고 말하는 대로 정확한 논증 구조와 근거를 기반으로 주장하고 싶지도 않았다. 사실 그럴 거면 그냥 AI에게 글을 쓰게 하지, 왜 내가 글을 쓰겠나. 그러한 논증 구조를 갖춘 글은 당신이 직접 AI에게 작성해 달라고 해서 읽으면 될 것이다.
그래서 근거도 빈약하고 온갖 비약이 난무하며 품위라곤 느껴지지 않는 내 사고의 흐름을 그대로 담았다. 이 조악한 에세이(라고 부를 수 있을지도 모르겠다.)에 마치 그리스인 조르바의 야수성을 그대로 품고자, AI는 최소한의 맞춤법 교정과 기계적 다듬기에만 활용했다고 감히 내 모든 커리어를 걸고 장담하겠다.
이렇게 글을 쓴 목적은 하나다. 역할과 생존법 따위를 논하기에는 이미 유명한 해외 권위의 프론티어들이 여러 조언을 해주고 있거니와, 그렇게 글을 썼다면 당신은 그저 내 글을 또 다른 AI 요약하기로 읽고 있을 것이다.
이 글은 의도적으로 ‘직접’ 쓰인 만큼 전체를 읽지 않고 요약만 읽으면 절대 이 글의 감정을 느낄 수 없게 하는 것이 목표다. 우리가 이전과 다른 행동을 하고 알을 깨고 나와 새로운 세계로 가는 건 고작 ‘~하는 법’ 따위로 되지 않는다. 뒤통수를 한 대 맞든지 가슴으로 느끼든지, 일단 느낀 다음에야 그제야 무엇을 할지가 정해지는 것이다.
혹여나 이 글을 읽고 반감이 들었다면 유감이다. 난 당신에게 그 어떠한 강요도 하지 않는다. 난 고작 스타트업 몇 개를 전전한 일개 개발자이며 대단한 권위를 가진 사람도 아니고, 지금 프로덕트로 성공 스테이지를 달리고 있지도 않다. 어쩌면 계속해서 실패만 하고 있는 사람일 수도 있다. 다만 영화 평론가가 영화감독은 아니듯이, 내가 논평(?)하는 AI 시대 개발자의 역할에 대해 정말 솔직하게 얘기하고 싶었다.
개발자는 끝나지 않았다. 당신이 열정을 여전히 잃지 않고 어쩌면 잠깐 잃었더라도 이 글을 통해 그 열정을 되찾는 계기가 되길 간절히 바란다. 당신이 할 수 있는 최대한의 상상력으로 일을 더 밀어붙여보아라. 내가 하지 못한다고 생각했던 그 영역까지 상상하면서. 상상력이 충분하다면 당신의 AI는 당신에게 새로운 세상을 열어줄 것이다.
지난 글을 언급하지 않을 수 없다. AI로 인한 클로드 블루 현상은 SNS에서 까부는 일부 프론티어를 제외하면 여전히 꽤 만연한 것 같다. 하지만 내가 더 이상 어린아이로 남을 수 없다고 해서 좌절할 필요는 없다. 어른이 되면 된다. 우리가 장난감처럼 가지고 놀던 코드 작성 업무는 이제 AI에게 넘어갔다. 거기서 낭만을 계속 찾고자 하면 당신은 앞으로 좌절할 일밖에 없을 것이다.
그만 일어나서 다시 열정을 되찾길 바란다. 그리고 미친 듯이 토큰을 쏟아내며 일하고 나면 가끔은 독서도 하고 스마트폰 없이 산책도 하라. FOMO에서 벗어나 본질과 현재에 집중하면서. 세상은 빨리 바뀌지만 가끔 그 변화를 놓아주어도 큰 문제가 벌어지지는 않는다.
특히 이제 시작하는 신입인데 여기까지 읽고도 구체적으로 무엇을 해야 할지 모르겠다면 나에게 연락해도 좋다. 백엔드냐 프론트엔드냐를 대신 정해주거나 취업을 보장해줄 수는 없다. 다만 지금 가진 경험으로 어떤 문제를 끝까지 풀어보고, 무엇을 직접 만들어 사용자에게 내놓아야 하는지는 같이 고민해볼 수 있다. (이 글을 끝까지 읽었다는 말은 꼭 써달라. 그래야 내가 조금 더 친절하게 답할 가능성이 높다.)
여기까지 읽었다면 이제는 내가 당신에게 감사할 차례다. 내 공격적인 스타일에 반감이 들었더라도 잠깐 내려놓고, 그 안에 숨어 있는 이 시대 변화의 본질을 캐치했으면 좋겠다. 이 글을 쓰기까지 많은 고민이 있었다. 두 달 전에 초안과 구조를 만들어 놓고, 그 뒤로 일할 때나 쉴 때나 책을 읽을 때나 늘 머릿속 한편에서 이 글을 고민했다. 이 글을 읽으며 같이 고민하는 여러분 모두가 이 시대를 살아가는 동반자들이다.
감사합니다.
(항상 그렇듯이 악플과 논쟁은 내 메일로, 선플은 댓글로. 아, 혹시 Fractional CTO가 필요해도 메일로.)
훌륭한 개발자는 원래 코드만 작성하지 않았다. 그런 의미에서 AI 시대라고 해서 훌륭한 개발자의 직업적 본질이 크게 달라졌다고 생각하지 않는다. 다만 코드 작성만이 개발자의 모든 것이라고 믿는 사람들에게는 여전히 이렇게 말하고 싶다.
개발자는 끝났다.
니체의 한마디로 마무리하겠다.
“삶의 ‘왜’를 가진 사람은 거의 모든 ‘어떻게’와도 살아갈 수 있다.”
— 프리드리히 니체, 《우상의 황혼》, 「잠언과 화살」 12 (원문)
댓글
댓글을 불러오는 중...
댓글 남기기