요즘IT » 커리어 » 피드

AI로 프로젝트 10개 만든 개발자가 서류에서 떨어지는 이유

어느 순간부터 취업을 준비하는 방식이 꽤 달라졌습니다.

예전에는 프로젝트 하나를 완성하는 일조차 쉽지 않았는데, 이제는 AI의 도움으로 훨씬 빠르게 기능을 구현하고 결과물을 만드는 분들이 많아졌기 때문입니다. 실제 개발 포트폴리오를 보다 보면 짧은 기간 안에 여러 프로젝트를 만들고 배포까지 경험한 사례가 예전보다 확실히 늘었단 것을 느낍니다.

그런데 흥미로운 점은 그렇게 결과물이 많아졌다고 해서 서류 합격률이 함께 올라가지는 않는다는 사실입니다. 오히려 “이 정도면 충분히 열심히 준비한 것 같은데 왜 계속 떨어질까”라는 고민을 하는 분들도 봤습니다. 저는 그 탈락의 이유가 처음부터 프로젝트 수나 구현량의 문제가 아니었다고 생각합니다.

이제 기업은 ‘무엇을 만들었는지’를 넘어, 왜 그 프로젝트를 했고, 어떤 문제를 풀고자 했으며, 그리고 그 과정에서 어떤 판단을 했는지를 더 중요하게 보기 시작했습니다. 오늘은 바로 그 지점, 그러니까 AI 시대의 취업 준비에서 왜 ‘도메인 이해력’이 점점 더 중요해지고 있는지 이야기해보려고 합니다.

<출처: 작가, Gemini로 생성>

프로젝트는 많아졌는데, 왜 서류 통과는 더 어려워졌을까?

요즘 취업을 준비하는 분들의 포트폴리오를 보면 정말 열심히 준비한 흔적이 많습니다. 사이드 프로젝트도 하고, 팀 프로젝트도 하며, 배포까지 직접 해보는 등 예전보다 훨씬 다양한 기능을 스스로 구현합니다. AI의 도움으로 개발 속도까지 빨라진데다 결과물 역시 더욱 풍성해졌습니다.

그런데 이상하게도 서류 합격률이 함께 올라가지는 않는다고들 합니다. 그만큼 다른 지원자들도 일정 수준 이상의 결과물을 만들어낼 수 있기 때문입니다. 다시 말해, 프로젝트를 해봤다는 사실만으로는 예전만큼 차별화되기 어려운 환경이 온 것입니다.

결국 기업이 보는 기준도 달라지고 있습니다. 무엇을 만들었는가보다 왜 그걸 만들었는지, 어떤 문제를 보고 시작했는지, 그리고 그 과정에서 어떤 판단을 내렸는지가 더욱 중요해진 거죠. 기업은 멋진 결과물을 보려고 포트폴리오를 읽는 것이 아니라 함께 일할 수 있는 사람인지 판단하려고 검토하기 때문입니다.

그래서 프로젝트가 많아도 서류에서 힘을 쓰지 못하는 경우가 생깁니다. 무언가를 많이 만든 건 보이는데, 왜 만들었는지가 잘 안 보이기 때문입니다. 기능은 많지만 문제는 흐릿하고, 기술은 다양하지만 판단은 보이지 않는 겁니다. 이제는 프로젝트의 수보다 그 프로젝트를 어떻게 해석하고 설명하느냐에 따라 평가가 갈리는 시대에 더 가까워졌습니다.

‘무엇을 만들었나’보다 ‘왜 그렇게 만들었나’를 보는 회사

포트폴리오를 만들 때 개발자들은 자연스럽게 “내가 한 일”을 중심으로 정리합니다. 어떤 기능을 구현했고, 어떤 기술을 사용했으며, 배포는 어떻게 했는지를 적습니다. 물론 이 정보들도 중요합니다. 문제는 대부분 포트폴리오가 그 지점에서 멈춘다는 점입니다.

회사 입장에서 궁금한 건 조금 다릅니다. 무엇을 만들었는지도 보지만, 그보다 더 중요한 것은 왜 그 프로젝트를 진행했는지, 어떤 문제를 해결하려 했는지, 그리고 그 과정에서 어떤 판단을 내렸는지입니다. 사고 과정에 더 큰 관심을 두고 있는 겁니다.

예를 들어 같은 일정 관리 프로젝트를 진행했다고 가정해보겠습니다. 한 지원자는 “캘린더 기능 구현, 알림 기능 구현, 소셜 로그인 구현, Docker 배포”라고 정리합니다. 한 일을 나열한 것이니 틀린 말은 아닙니다. 하지만 이 설명만으로는 이 프로젝트가 어떤 문제를 해결하기 위해 존재하는지 충분히 드러나지 않습니다.

반면 다른 지원자는 이렇게 설명할 수 있습니다. “기존 일정 관리 앱은 개인 기록 중심이라, 여러 명이 함께 일정을 조율해야 하는 상황에서는 불편하다고 느꼈습니다. 그래서 이 프로젝트에서는 개인 기록보다 일정 조율 경험에 초점을 맞춰 기능 우선순위를 설정했습니다.” 같은 프로젝트라도 전달할 느낌이 완전히 달라집니다.

첫 번째 설명은 구현 내용이 보이고, 두 번째 설명은 그 구현 뒤에 있는 생각이 보입니다. 회사가 더 높게 평가하는 쪽은 대개 후자입니다. 실무에서는 결국 요구사항을 이해하고, 애매한 상황에서 판단을 내리며, 그 선택의 이유를 설명할 수 있는 사람이 필요하기 때문입니다.

좋은 포트폴리오에는 이러한 판단의 흔적이 남습니다. 왜 이 기능을 먼저 만들었는지, 왜 이 기술을 선택했는지, 왜 어떤 요소는 과감히 뺐는지가 보여야 합니다. 이제는 무엇을 만들었는가만큼 어떻게 사고하며 만들었는가가 훨씬 더 중요해졌습니다.

‘전문지식’보다 ‘현실감’에 가까운 도메인 이해력

이처럼 도메인 이해력이 중요하다고 하면 부담부터 느끼는 분이 많을 겁니다. ‘그럼 해당 업계 지식을 엄청 많이 알아야 하나?’라고 생각하기 때문이죠. 하지만 취업 준비 단계에서 필요한 도메인 이해력은 업계 전문가 수준의 지식을 의미하는 게 아닙니다.

제가 말하는 도메인 이해력은 훨씬 더 현실적인 개념입니다. 내가 만든 서비스가 어떤 문제를 해결하려는지, 사용자는 어디서 불편을 느끼는지, 실제 운영 과정에서는 어떤 변수와 예외가 발생할 수 있는지 고민해본 경험에 가깝습니다. 거창한 전문성이라기보다 ‘현실감’이라고 보는 편이 적절합니다.

이를테면 스터디 모집 서비스를 만든다고 해보겠습니다. 으레 필요한 게시글 CRUD와 댓글 기능을 구현하는 데서 끝날 수도 있습니다. 하지만 조금만 더 현실적으로 접근해보면 다른 질문들이 떠오릅니다. 사람들은 모집글을 꼼꼼히 읽을까? 신청만 하고 잠수 타는 경우는 없을까? 모집자와 지원자가 기대하는 운영 방식이 다를 때는 어떤 문제가 생길까? 같은 질문들입니다.

이러한 질문을 고민해본 사람은 기능을 구현할 때도 우선순위가 달라집니다. 단순히 만들 수 있는 기능이 아니라 실제로 자주 부딪힐 문제를 먼저 다루기 때문입니다. 그리고 바로 그 차이가 포트폴리오를 설명하는 방식에서도 드러납니다.

모든 프로젝트를 대단한 서비스로 출시해야 한다는 말은 아닙니다. 다만 가능하다면, 실제 사용자에게 보여주고 반응을 받아본 경험이 꽤 강력한 무기가 됩니다. 머릿속으로 상상한 문제와 현실에서 겪는 문제가 상당히 다르기 때문입니다.

정리하면, 취업 준비에서 말하는 도메인 이해력은 박사 수준의 전문지식을 뜻하지 않습니다. 사용자의 문제를 구체적으로 상상하고 서비스가 현실에서 어떻게 쓰일지 고민해본 흔적에 가깝습니다. 저는 이 정도 현실감만으로도 다른 포트폴리오보다 훨씬 더 세진다고 봅니다. 왜냐하면 대부분이 기술은 설명해도 현실은 설명하지 못하기 때문입니다.

기술 설명과 기여도는 중요하지만, 그것만으로는 부족합니다

이쯤에서 오해하지 말아야 할 부분이 있습니다. ‘기술 설명’이 필요 없다는 관점입니다. 저는 그렇게 생각하지 않습니다. 사용한 기술 스택, 구현한 기능, 맡았던 역할, 그리고 본인 기여도는 여전히 포트폴리오에 중요합니다. 특히 팀 프로젝트라면 “그래서 본인이 정확히 무엇을 했는지”가 분명하게 드러나야 합니다. 기본 중의 기본입니다.

다만 많이들 여기서 한 가지를 더 놓칩니다. 문서를 길고 자세하게 만드는 것과 설득력 있게 만드는 것은 전혀 다른 문제라는 점입니다. 저는 이력서와 포트폴리오를 굳이 나눌 필요는 없다고 생각합니다. 오히려 하나의 문서 안에서 핵심이 빠르게 읽히고, 면접관이 자연스럽게 궁금증을 느낄 수 있도록 정리된 쪽이 훨씬 실전에 유리합니다.

중요한 건 많이 적는 게 아니라 짧게 적더라도 방향이 보여야 한다는 점입니다. 안 좋은 사례, Before는 이런 식입니다.

Redis 적용
Docker 배포
JWT 로그인 구현
게시글 CRUD 개발

물론 틀린 말은 아닙니다. 다만 이 정보만으로는 기술을 사용했다는 사실만 보일 뿐 왜 그렇게 했는지는 잘 드러나지 않습니다. 조금만 바꿔도 이렇게 괜찮은 After를 만들 수 있습니다.

잦은 조회가 발생하는 인기 게시글 응답 속도 개선을 위해 Redis 캐시 적용
팀원간 개발환경 차이를 줄이고 배포 과정을 단순화하기 위해 Docker 기반 배포 구성
세션 방식 대신 확장성을 고려해 JWT 기반 로그인 구조 설계
단순 게시글 등록 기능이 아닌 스터디 모집 흐름에 맞춘 생성/조회/수정 기능 구현

길이를 크게 늘리지 않았지만, 느껴지는 인상은 꽤 다릅니다. 기술을 썼다는 사실 그 자체보다 어떤 문제를 보고 선택했는지가 보이기 때문입니다. 바로 이런 식으로 한 줄 안에서도 문제 인식과 판단을 드러낼 수 있어야 합니다.

결국 좋은 서류는 모든 걸 다 설명하는 문서가 아닙니다. 핵심만 빠르게 읽히면서도, “이 사람은 왜 이렇게 했을까?”라는 궁금증을 주며, 결국 면접으로 이어지게 만드는 게 필요합니다. 짧게 적는 것과 얕게 적는 것은 다릅니다. 기술 설명과 기여도는 여전히 중요하지만, 이제는 그 안에 문제 맥락과 판단의 흔적까지 함께 담겨야 합니다.

‘왜 그렇게 만들었는가’에 더 깊게 답하기

이처럼 AI 덕분에 구현 자체의 진입장벽은 확실히 낮아졌습니다. 예전보다 빠르게 화면을 만들 수 있고, API도 붙일 수 있고, 배포까지 가는 속도도 빨라졌습니다. 이건 분명 좋은 변화입니다. 다만 모두가 더 쉽게 만들 수 있게 됐다는 말은 반대로 단순 구현만으로는 예전만큼 차별화가 어렵다는 뜻이기도 합니다.

그래서 더 중요해지는 건 꼬리질문에 답하는 힘입니다. 왜 이 기술을 썼는지, 왜 이 구조를 선택했는지, 왜 이 기능을 먼저 만들었는지, 왜 이 문제를 풀 가치가 있다고 판단했는지까지 설명할 수 있어야 합니다. 결국 경쟁력은 구현한 양보다 판단의 깊이에서 갈리기 시작하니까요.

당연히 여기서 멈추면 또 아쉽겠죠. 그러니 가능하다면 실제 사용자에게 보여주고, 현실의 문제를 해결하려고 해본 경험까지 가는 게 훨씬 강력합니다. 규모가 작아도 괜찮습니다. 직접 배포해보고, 주변 사람이라도 써보게 하고, 예상과 다른 반응을 확인해본 경험은 분명 면접관한테 다른 인상을 줍니다. 머리로 상상한 문제와 현실에서 부딪히는 문제는 다르기 일쑤입니다.

결국 앞으로의 포트폴리오는 “이만큼 구현했습니다”에서 끝나서는 힘듭니다. “왜 이렇게 만들었고, 실제로 어떤 문제를 확인했고, 그걸 어떻게 바꿨는가”까지 이어져야 힘을 가집니다. 이제는 구현 뒤에 있는 사고와 현실 검증 경험이 더 중요한 시대로 가고 있으니까요.

앞으로 더 희소해질 ‘문제를 정의하고 해결하는 사람’

앞으로 개발자의 역량과 경쟁력은 더 선명하게 갈릴 겁니다. 코드를 빠르게 작성하는 사람은 점점 많아질 테고, 구현 자체의 진입장벽도 지금보다 더 낮아질 가능성이 높기 때문입니다. 그럴수록 결국 더 희소해지는 사람은 단순히 잘 만드는 사람이 아니라 무엇을 만들어야 하는지 먼저 정의할 수 있는 사람일 겁니다.

실무에서는 생각보다 “어떻게 만들지”보다 “무엇을 풀어야 하지”가 더 어려운 경우가 많습니다. 사용자에게 진짜 불편한 지점이 어디인지, 어떤 문제부터 해결해야 효과가 큰지, 기술적으로 가능하다고 해서 다 만들어야 하는 건 아닌지 판단해야 하는 순간이 계속 생기더라고요. 그리고 그 판단은 단순 구현 경험만으로는 와닿지 않습니다.

그래서 다가올 미래에 몸값이 높아질 개발자는 문제를 정의하고, 그 문제를 기술적으로 풀어내고, 필요하다면 비즈니스 관점에서도 설명할 수 있는 사람일 겁니다. 사용자의 불편, 서비스 운영의 현실, 팀의 자원과 우선순위까지 함께 고려할 수 있는 사람이 결국 더 필요해질 테니까요.

이제 회사는 많이 만든 개발자보다 왜 만들어야 하는지 설명해줄 개발자를 더 높게 평가합니다. AI가 발전할수록 이런 차이는 오히려 더 커질지도 모릅니다.

결국 살아남는 사람은 구현에 머무는 사람이 아니라, 문제를 정의하고 해결하는 사람입니다.

]]>

문돌이 PM이 만든 AI 세션에 대기자 200명이 몰린 이유

[바이브코더스] 비개발자를 위한 Claude Cowork 세션 운영자, 김동현 님 인터뷰

아마 비개발분들은 공감하실 텐데요. 요즘 AI 활용 콘텐츠는 넘쳐나지만, 정작 비개발자의 눈높이에 맞춰 실무에 바로 적용할 수 있는 현실적인 이야기는 많지 않습니다. 대부분의 AI 활용 콘텐츠도 개발자 시선에서, 코드를 활용한 사례를 다루는 경우가 많죠.

오늘 바이브코더스 인터뷰에서 소개해 드릴 분은 비개발자를 위해 ‘클로드 코워크(Claude Cowork)’를 실무에 적용할 수 있는 다양한 아이디를 나누는 세션을 직접 설계하고 운영하고 있습니다. 벌써 12회째 세션을 이어가고 있고, 현재 대기자가 200명이 넘을 만큼 많은 관심을 받고 있는데요. 스스로를 ‘AI와 함께 일하는 잡부’라고 소개하는 김동현 님의 이야기를 통해, 비개발자가 현실적으로 AI를 실무에 어떻게 적용할 수 있는지 그 이야기를 들어봤습니다.

김동현 님 <출처: 바이브코더스 인터뷰 화면>

Part 1. 비개발자, AI를 만나다

Q. 안녕하세요! 간단한 자기소개 부탁드립니다.

안녕하세요. 저는 현재 컬리 해외사업팀에서 Global PM(Project Manager)으로 일하고 있는 김동현입니다. 이전에는 캐치테이블에서 마케팅과 사업 기획을 맡았고, 그전에는 컨설팅 업무도 했어요. 한마디로 ‘문돌이’ 직무를 두루 경험해 온 사람이라고 소개할 수 있을 것 같은데요. 요즘은 클로드 코워크(Claude Cowork)를 활용해, AI로 일하는 방식을 어떻게 하면 더 효율적으로 바꿀 수 있을지 이것저것 이야기하고 다니고 있습니다.

Q. 문돌이 직무를 두루 경험했다고 말씀해 주셨는데, 처음 AI를 어떻게 접하게 되셨나요?

2년 전쯤, 제가 캐치테이블에서 일하던 시절이었어요. 일을 하다 보면 개발자가 이틀이면 끝낼 수 있을 것 같은 작은 개발이 필요한데도, 리소스나 우선순위에 밀려 업무가 지연되는 경우가 많았거든요. 아마 개발자분들과 함께 일해 보신 분들이라면 이런 경험을 많이 해보셨을 것 같아요.

그 당시에는 ChatGPT-3와 Copilot이 막 나오던 때였는데요. 그때 ‘나도 이런 AI 기술을 이용해서 직접 개발해 볼 수 있지 않을까?’라고 생각했던 것 같아요. 그래서 퇴근 후에 “비개발자도 코파일럿이랑 함께하면 코딩할 수 있다” 같은, 2주에 200만 원짜리 부트캠프를 듣고 제가 원하는 프로덕트도 만들어 봤어요. 그런데 이 과정을 거치면서, 조금 아이러니한 생각이 들더라고요. AI 기술의 발전 속도가 너무 빨라서, 제가 배우는 속도보다 기술이 발전하는 속도가 더 빠를 것 같았어요. 그래서 전략적으로 조금만 더 기다리면 기술이 더 빠르게 저에게 다가오겠다고 느껴서, 한동안은 노력을 조금 내려놓기도 했죠.

그런데 작년에 Claude Code가 나왔을 때, 이제는 제가 더 이상 크게 애쓰지 않아도 원하는 수준의 MVP나 업무 툴을 쉽게 만들 수 있겠다는 생각이 들었어요. 그 이후부터는 클로드를 적극적으로 활용해 보려고 노력하고 있습니다.

Part 2. 비개발자를 위한 ‘Claude Cowork 세션’을 열다

Q. 비개발자를 위한 Claude Cowork 세션을 직접 만들게 된 계기가 궁금해요.

작년에 Claude Code로 제 업무를 자동화하고, 업무 맥락을 AI에 담아 활용해 보니 효용이 굉장히 크게 느껴졌어요. 그래서 그 경험을 바탕으로 주변 지인들에게도 알려줬는데, 생각보다 다들 많이 어려워하시더라고요. 나중에 잘 쓰고 있는지 물어보면, 처음에는 의욕적으로 시작했다가도 CLI 터미널의 까만 화면이 익숙하지 않아 어렵다거나, 몇 번 시도해 봤는데 잘 안 되니 점점 손이 가지 않는다는 피드백을 많이 들었어요.

그러다가 Claude Cowork가 한두 달 전쯤 처음 나왔을 때, ‘이건 다르다’는 생각이 들었어요. 일반 사용자에게 익숙한 GUI(Graphical User Interface) 기반이라 진입 장벽이 훨씬 낮고, Claude Code에서 할 수 있는 기능도 상당 부분 커버할 수 있었거든요. 그래서 주변 사람들을 모아 몇 차례 세션을 함께 진행해 봤는데, 이전과는 확실히 다르게 많은 분들이 계속 Claude Cowork를 활용한다는 느낌을 받았어요. 실제로 1~2주 뒤에 연락해 보면 “나 이런 것도 만들어서 이렇게 쓰고 있어”라는 이야기를 들을 수 있었거든요.

이런 경험을 통해 비개발자에게도 Claude Cowork는 충분히 실질적인 효용이 있겠다는 확신이 들었고, 그때부터 본격적으로 세션을 운영하기 시작했습니다. 제가 사람들에게 Claude Cowork를 소개할때 이렇게 얘기하곤 해요. Claude Code가 두 발 자전거라면, Claude Cowork는 보조 바퀴 달린 네 발 자전거라고요. 이걸로 열심히 타다 보면, 어느 순간 두 발 자전거를 타고 싶어지는 좋은 중간 단계 도구라고 생각해요. 확실히 비개발자들에게 AI에 대한 흥미와 지속성을 가능하게 해주는 좋은 툴인것 같아요.

비개발자를 위한 Claude Cowork 세션 <출처: 김동현 님 홈페이지>

Q. 벌써 세션이 12번이나 진행됐다고 들었어요. 세션에서는 주로 어떤 내용을 다루나요?

제 세션을 한 문장으로 소개하면, ‘프롬프트를 잘 쓰는 법’보다는 ‘컨텍스트를 잘 설계하는 관점’을 다루는 세션이라고 생각해요. 주로 마인드셋 30분, Cowork 기능 소개 20분, 시나리오별 실제 시연 40~50분으로 구성해서 진행하고 있어요.

특히 마인드셋 파트에서는 세 가지를 강조하는데요. 첫째, AI가 나보다 똑똑하다는 걸 인정하는 데서 시작해야 한다는 점이에요. 둘째, 그렇다면 문제 해결은 내가 아니라 AI에게 위임해야 한다는 것이고요. 셋째, 내 역할은 ‘문제 해결의 주체’에서 ‘컨텍스트를 오케스트레이팅하고 결과를 밸리데이팅하는 역할’로 재정의해야 한다는 거예요.

시연 파트에서는 스킬이나 자동화 예약 기능, 폴더 인스트럭션 설정 등을 실제로 보여드리면서, ‘내일 출근해서 내 업무에 바로 이렇게 적용해 볼 수 있겠다’는 감각을 전하는 데 초점을 맞추고 있어요. 비개발자분들도 Claude Code를 활용해서 ‘나도 할 수 있겠다’는 감각이 생겨야, 실제로 꾸준히 활용하는 비율도 높아지더라고요.

에이전트와 함께 파워포인트에서 AI 느낌을 줄이고, 완성도를 높이는 시연 <출처: 김동현 님>

Q. 지금까지 세션을 진행하시면서 가장 기억에 남는 피드백이 있다면요?

전 직장이었던 캐치테이블에서, 비개발자분들 약 50명을 대상으로 세션을 진행한 적이 있어요. 캐치테이블에서는 직원들의 AI 토큰 사용량을 트래킹하고 있다고 들었는데, 제 세션 이후에 비개발자분들의 토큰 사용량이 개발자들과 비교해도 상위 30% 안에 들어왔다는 이야기를 들었어요.

최근 인터뷰에서 젠슨 황이 “연봉 50만 달러짜리 엔지니어가 1년에 25만 달러어치 토큰도 안 썼다면 일을 제대로 안 하는 것”이라고 말했는데요. 그 말처럼 요즘은 토큰 사용량이 직원들이 AI와 얼마나 함께 일하고 있는지를 가장 직관적으로 보여주는 지표인 것 같아요. 비개발자분들이 그 수준까지 올라갔다는 게 정말 뿌듯했습니다.

김동현 님의 Claude Cowork 오프라인 세션 <출처: 김동현 님 LinkedIn>

Part 3. 비개발자의 AI 장벽과 마인드셋

Q. 비개발 직무 분들이 Claude나 Claude Code를 접할 때 가장 많이 막히는 부분은 어디인가요?

아까도 말씀드렸지만, 가장 큰 장벽은 ‘익숙하지 않은 인터페이스’예요. UI 환경에서 일하던 사람이 갑자기 터미널의 까만 화면에서 자연어로 프롬프트를 입력하고 있으면, 뭔가 낯설고 이상하게 느껴지잖아요. 그런 심리적 거리감이 생각보다 커서, 한두 번 잘 안되면 금방 손을 놓게 되더라고요.

두 번째는 최근 AI 콘텐츠의 방향성이에요. 시중에 나와 있는 AI 콘텐츠 대부분이 개발자 시각에서 만들어지거든요. 바이브 코딩이나 멀티 에이전트 세팅 같은 주제는 보기에는 멋지지만, 비개발자에게는 실무적으로 바로 와닿지 않아요. PM이나 마케터 입장에서는 ‘내가 이 툴로 내일 당장 무엇을 할 수 있는지’가 더 중요하거든요. 그런데 그 부분을 채워 주는 콘텐츠는 아직 많이 부족하다고 생각해요. 그래서 비개발자들이 익숙하지 않은 툴과 정보를 접할 때, 분명한 허들을 느끼는 것 같습니다.

Q. 세션에서 마인드셋을 많이 강조한다고 하셨는데, 어떤 이유 때문일까요?

툴은 계속 바뀌잖아요. 지금은 Claude Cowork가 비개발자에게 가장 좋은 도구라고 생각하지만, 3~6개월 뒤에도 그럴지는 사실 모르겠어요. 구글이 클라우드 기반으로 비슷한 툴을 내놓는다면, 그게 더 좋아질 수도 있고요. 그만큼 AI 시장의 변화 속도가 너무 빠르다 보니, 사실 하나의 툴을 잘 사용하는 것 자체가 얼마나 오래 효용이 있을지는 확신하기 어려워요.

또 내가 특정 툴 하나를 잘 다룬다고 해서, 그것만으로 AI를 잘 활용한다고 말할 수는 없는 것 같아요. 반면, AI와 협업하는 마인드셋, 그러니까 어떻게 컨텍스트를 설계하고 결과를 밸리데이팅할지는 툴이 바뀌어도 크게 달라지지 않아요. 저는 이게 결국 AI를 잘 쓰는 사람과 그렇지 않은 사람을 가르는 핵심이라고 생각합니다. 그래서 프롬프트 스킬이나 툴 활용 스킬보다, AI를 활용하는 마인드셋이 더 중요하다고 보고 있어요.

Part 4. 현업에서의 AI 활용

Q. 현재 컬리에서 Claude 또는 다른 AI를 어떻게 활용하고 계신가요?

회사 차원에서도 다양한 시도를 하고 있는 것으로 알고 있어요. 최근 외부에 공개됐던 사례 가운데 하나가 ‘컬리 AI 스튜디오’라는 서비스예요. 본인 사진 한 장을 넣으면, 원하는 필터로 사진이 변환돼 나오는 재미있는 경험을 할 수 있는 서비스인데요. 원래는 컬리 앱 안에서 1~2주 정도만 운영하려던 서비스였는데, 반응이 좋다 보니 한 달 이상 운영하게 됐죠.

컬리에서 선보인 ‘AI 스튜디오’ <출처: 컬리>

또 팀 단위의 AI 활용에도 요즘 집중하고 있어요. 저 혼자 생산성을 200% 높이는 것보다, 팀원 전체가 함께 AI를 잘 쓰는 환경을 만드는 게 더 가치 있다고 생각하거든요. 예를 들면, 회의록을 트랜스크립트로 자동 변환해 관리하는 스킬을 팀원 전체가 함께 공유해서, AI와의 맥락만 쌓이는 게 아니라 팀 전체의 지식 저장소로도 활용하는 시도들을 하고 있습니다.

Q. 조직 차원에서 AI를 도입할 때 가장 중요한 게 뭐라고 보시나요?

제 생각에는 조직 차원에서 AI를 도입할 때 가장 중요한 건, 탑다운 방식으로 AI를 전파하는 것이라고 봐요. 먼저 팀의 리더가 직접 써보지 않으면 팀 리소스를 제대로 파악하기 어렵거든요. AI를 잘 활용했을 때, 같은 인원으로 얼마나 더 많은 일을 할 수 있는지에 대한 감각이 없으면 사실 리소스 관리도 쉽지 않을 거예요.

팀에 10명이 있다면, AI 도입에 관심을 갖고 잘 활용하는 사람은 약 10% 정도일 거라고 생각해요. 나머지 90%를 온보딩하는 과정에서는 분명히 어려움이 생기는데, 조직장이 그 과정을 직접 겪어보지 않았다면 현실적으로 도와주기 어렵다고 봐요.

그다음으로 중요한 건 에반젤리스트, 즉 챔피언 역할이에요. AI 구독을 제공한다고 해서 모두가 자연스럽게 활용하는 건 아니거든요. 같은 팀에서 비슷한 업무를 하는 사람이 AI를 통해 실제로 효율을 내는 모습을 눈으로 확인해야, 주변에서도 관심을 갖기 시작해요. 그리고 이런 챔피언들이 지치지 않고 계속 역할을 이어갈 수 있도록, 조직장과 경영진이 잘 지원하고, 관리해 주는 것도 굉장히 중요하다고 생각합니다.

Part 5. AI 전망과 마무리

Q. 앞으로 비개발자로서 AI를 어떻게 더 활용하고, 또 어떻게 알리실 계획인가요?

사실 다음 세션 일정이 아직 정해지지 않았는데도, 대기자가 200명이 넘은 상태예요. 50명 규모의 오프라인 행사를 혼자 운영하는 것도 쉽지 않다 보니, 어떻게 하면 더 많은 분께 메시지를 전달할 수 있을지 계속 고민하고 있습니다.

그래도 가능하다면, 오프라인 현장에서 직접 사람들의 반응을 보면서 세션을 이어가고 싶어요. 어떤 지점에서 사람들이 “와” 하고 반응하는지, 어떤 시연에서 눈빛이 달라지는지를 직접 확인하는 게 중요하다고 생각하거든요. 그런 반응 데이터를 쌓아가면서, 콘텐츠를 계속 다듬고 발전시켜 나가고 있습니다.

Q. AI 활용에 관심 있는 비개발자 독자들에게 한마디 해주신다면요?

실용적인 이야기를 꼭 드리고 싶은데요. 일단 AI를 활용해 일하고 싶다면, 1~2주만 참고 버텨보세요. AI 활용은 결국 습관을 바꾸는 일이에요. 처음에는 내가 봤던 세션이나 영상에서는 잘되던데, 왜 나는 이상한 답만 나오지 싶은 순간이 반드시 찾아와요. 그럴 때는 ‘내가 아직 컨텍스트를 충분히 설계해서 주지 못하고 있는 거야’라는 믿음을 갖고 버텨보시면 좋겠어요. 그렇게 1~2주를 넘기면, 정말 신세계가 열립니다.

그다음 단계에서 한 가지 더 당부드리고 싶은 게 있는데요. AI를 쓰다 보면 너무 신나서, 자동화를 위한 자동화, AI를 쓰기 위한 AI 쓰기에 빠지기 쉬워요. 그런데 한 달 뒤에 돌아보면 실제 임팩트는 생각보다 크지 않은 경우가 많거든요. 그래서 1~2주에 한 번씩은 ‘내가 AI를 정말 효율적으로 잘 썼나, 이걸로 실제 임팩트가 났나’를 돌아보면서 적응해 나가시길 추천드립니다.

정리하면, “AI 사용을 버텨서 습관을 만들고, 주기적으로 회고해 나가라” 이 두 가지가 비개발자가 AI를 실무에 제대로 녹이는 가장 현실적인 방법이라고 생각합니다.

마치며

지금까지 문돌이 출신 비개발자로서 AI를 실무에 녹이고, 그 경험을 12회에 걸쳐 세션으로 나눠 온 김동현 님의 이야기를 들어봤습니다. 그가 거듭 강조한 지점은 프롬프트 스킬이 아닌 컨텍스트 설계, 개인 생산성이 아닌 팀 단위의 변화, 도구 소개가 아닌 마인드셋이었는데요. 이런 관점은 AI 도구가 계속 바뀌더라도 오래 유효하겠다는 생각이 들었습니다. 마지막으로 AI에 대한 FOMO(소외되는 것 같은 불안감)를 느끼는 비개발자분들께 김동현 님이 남긴 말을 전하며 글을 마무리하겠습니다.

"AI가 나보다 똑똑하다는 걸 인정하는 순간부터, 일하는 방식이 정말 달라져요. 그 다음은 컨텍스트를 잘 설계하는 것뿐이죠. 도구는 계속 바뀌겠지만, 이 마인드셋만 있으면 어떤 도구가 와도 빠르게 적응할 수 있습니다. 비개발자라서 AI를 잘 못 쓴다는 건 이제 변명이 될 수 없어요. 1~2주만 버텨보세요. 신세계가 기다리고 있을 거예요."

이제, 여러분은 AI와 어떻게 함께 일해보고 싶으신가요?

]]>

개발자, 이직이 완벽한 도피처가 될 수 있을까요?

일본에서의 첫 이직: 개발자로서의 고뇌

여러분은 혹시 늦은 밤, 불 꺼진 방 안에서 모니터만 멍하니 바라보며 "나, 이대로 계속 개발을 해도 괜찮은 걸까?"라는 서늘한 불안감을 느껴본 적이 있으신가요? 아마 매일 똑같이 반복되는 업무에 지쳐서, 혹은 시간이 지나도 더 이상 실력이 발전하지 않는다는 생각에 이직 채용 사이트를 습관적으로 들여다보고 계실지도 모르겠습니다. 사실 저 또한 그런 시절이 있었습니다.

타국에서 커리어를 쌓아간다는 것은 생각보다 훨씬 외롭고 막막한 순간들의 연속이었습니다. 특히 일본에서의 첫 전직(轉職, 직업이나 직무를 바꾸어 옮김)은 단순히 제 명함의 로고를 바꾸거나 출근하는 지하철 노선을 바꾸는 가벼운 일이 결코 아니었습니다. 당장 제 체류 자격을 증명하고 삶을 지탱해 주는 비자 문제가 걸려 있었고, 한 치 앞을 알 수 없는 복잡한 연봉 체계를 새롭게 계산해야 하는 치열한 생존의 문제였죠.

무엇보다 일본 IT 특유의 파견 및 도급 중심 구조 속에서, 제가 개발자로서 올바른 방향으로 성장하고 있는지 스스로에게 냉정하게 물어야만 하는 고통스러운 과정이기도 했습니다. 처음 전직을 결심했던 순간만 해도, 제가 겪는 모든 성장의 정체와 불만족은 '내가 속한 환경' 탓이라고 굳게 믿었습니다. "회사가 나를 제대로 가르쳐 주지 않아서", "할당받은 프로젝트의 퀄리티가 너무 낮아서"라고 탓하곤 했죠.

하지만 본격적으로 이력서를 쓰고 면접의 문을 두드리며 뼈저리게 깨닫게 된 사실이 하나 있습니다. 그 견고한 산업의 구조보다도 먼저 부족했던 건, 바로 준비되지 않은 저 자신이었다는 사실을요. 오늘은 일본에서 첫 전직을 결심하고 실행에 옮기며 부딪혔던 차가운 현실, 그리고 그 과정에서 철저하게 제 부족함을 돌아봤던 이야기를 여러분과 허심탄회하게 나누어 보려고 합니다.

성장의 시계가 멈추다: 전직을 고민하게 된 진짜 이유

반복 업무, 1인 개발, 성장 정체의 악순환 <출처: 작가>

혼자라는 자유로움 뒤에 숨겨진 성장의 한계

제가 이전 회사에서 주로 담당했던 업무는 고객의 요구에 따라, 시스템을 만들어 납품하는 이른바 수탁 개발 형태였습니다. 다양한 산업군의 기능을 접해볼 수 있을 거라는 초기의 기대와는 달리, 현실은 늘 빠듯한 예산 속에서 쫓기듯 진행되는 소규모 프로젝트의 연속이었는데요. 회사의 이익 구조상 남는 것이 적다 보니 자연스럽게 저희의 급여도 제자리걸음을 면치 못하는 악순환이 계속되었습니다.

게다가 규모가 작다 보니 개발의 기획 단계부터 납품까지 온전히 저 혼자 감당해야 하는 1인 개발 형태가 매우 잦았습니다. 물론 1인 개발을 통해 처음부터 끝까지 혼자 고민해 보며, IT 기술의 전반적인 파이프라인(Pipeline)을 넓고 유연하게 접할 수 있었다는 점은 큰 장점이었습니다. 하지만 체계적인 코드 리뷰(Code Review)나 뛰어난 시니어 개발자의 멘토링을 기대하는 것은 사치에 불과했습니다.

당장 눈앞에 떨어진 버그를 고치고 납품 기한을 맞추는 데 급급하다 보니 설계의 본질에 대해 깊이 고민할 여유가 없었습니다. 막히는 에러가 발생해도 물어볼 곳 하나 없이 속 시원히 해결되지 않아, 퇴근 후에도 어김없이 집에서 노트북을 열고 끙끙 앓아야 했던 날들이 무수히 많았습니다. 이러한 환경에서 과연 5년 뒤, 10년 뒤의 제가 어떤 모습일지 상상하니 눈앞이 캄캄해졌습니다.

개발자 타이틀을 잃을지도 모른다는 깊은 위기감

이러한 불만족이 쌓여가던 중, 저를 본격적인 전직 시장으로 강력하게 내몬 결정적인 위기가 찾아왔습니다. 다니던 회사가 다른 기업과 합병을 겪게 되면서 심각한 영업 부진에 빠진 것이었는데요. 합병 이후 영업이 급격히 위축되면서, 동료 개발자들은 하나둘 회사를 떠나기 시작했습니다. 결국 남은 건 저 혼자였습니다.

개발할 프로젝트도 사라진 상황에서, 매출이라도 만들어야 했던 회사는 저를 IT 시스템 운영팀으로 보낼 수밖에 없었습니다. 그렇게 5개월이라는 결코 짧지 않은 시간 동안, 본연의 코딩 업무가 아닌 무미건조한 운영 업무만을 전담하게 되었습니다. 운영팀에서의 하루하루는 제게 커다란 절망감을 안겨주었습니다. 당장 이곳에서 아무리 훌륭하게 성과를 낸다고 한들, 개발자로서 급여가 더 오를 희망은 보이지 않았기 때문입니다.

무엇보다 하루가 다르게 새로운 기술이 쏟아져 나오는 이 업계에서, 소중한 제 커리어에 회복하기 힘든 공백이 생길 것이라는 걱정이 매일 밤 저를 짓눌렀습니다. 더 늦기 전에 멈춰버린 성장의 톱니바퀴를 다시 굴려야 한다는 확신이 들었습니다. 그것이 제가 서둘러 정든 곳을 떠날 채비를 하게 만든 가장 절박한 이유였습니다. 결코 여유롭고 안정적인 상황에서 준비한 이직이 아니었기에 제 마음은 더욱 초조할 수밖에 없었습니다.

피부로 느낀 일본 IT의 맨얼굴: 구조적 현실과 마주하다

일본 IT 산업의 다단계 하청 구조 <출처: 작가>

견고하게 자리 잡은 의존적 생태계

일본에서 개발자로 첫발을 내딛고 살아가다 보면, 피할 수 없이 마주치게 되는 단어가 있습니다. 바로 SES(System Engineering Service)라는 파견 위주의 기술 인력 제공 형태입니다. 한국의 시스템 통합(SI) 업무 환경과 비슷한 맥락이지만, 현장에 상주하는 방식과 다단계의 계약 구조에서 뚜렷한 차이를 보입니다. 실제로 수많은 일본의 IT 기업들이 자체적인 서비스를 기획하고 구축하는 사내 개발을 하기보다는, 이 SES나 수탁 개발 구조에 절대적으로 의존하고 있는 것이 엄연한 생태계의 현실입니다.

자체 플랫폼이나 서비스를 가진 사내 개발 환경에서는 하나의 프로덕트에 대해 깊이 있게 고민하고, 대규모 트래픽(Traffic)에 대비해 코드를 리팩터링(Refactoring)하며 성장해 나가는 경험을 차곡차곡 쌓을 수 있습니다.

반면, 수탁 개발이나 많은 외국인 개발자들이 흔히 겪는 SES 환경에서는 어떨까요? 짧으면 몇 개월, 길어도 1년 남짓한 프로젝트가 끝나면 또다시 새로운 환경의 전혀 다른 시스템 코드를 뜯어봐야 합니다. 잦은 환경 변화 속에서 자신만의 기술적인 철학과 깊이를 뾰족하게 가다듬는 것은 정말이지 쉽지 않은 일이었습니다.

언어 장벽과 홀로서기라는 미션

게다가 외국인 개발자에게 이러한 폐쇄적인 구조 속에서의 생존과 전직은 결코 가벼운 마음으로 던질 수 있는 출사표가 아니었습니다. 제가 처음 다녔던 회사는 다행스럽게도 한국인 동료들이 꽤 포진해 있어 심리적인 안정감이 매우 높은 편이었습니다. 기술적인 소통의 어려움이나 미묘한 문화적 차이를 선배들이 훌륭하게 메워주고 배려해 주었죠. 하지만 제가 진정한 성장을 위해 온전히 홀로 일본의 IT 생태계 속으로 뛰어들어 '완전한 일본계 회사'로 발걸음을 옮기려다 보니 상황의 온도는 180도 달라졌습니다.

철저히 내국인 일본 개발자들과 똑같은 기준의 잣대 위에서 평가받아야 했기 때문입니다. 회의의 논리 전개 방식, 까다로운 내부 문서 작성 프로세스 등 모든 것이 생경했습니다. 따뜻한 온실 속에서만 자라다가, 처음으로 매서운 야생 한가운데 내던져진 기분이랄까요? 단순히 코드를 잘 짜는 것을 넘어, 일본어라는 언어의 장벽을 뚫고 내 실력을 증명해야 하는 이중고를 겪어야 했습니다.

보이지 않는 모래주머니: 비자와 급여 체계의 공포

한국 여권과 급여 봉투 사이의 불안한 균형 <출처: 작가>

카운트다운이 시작되는 비자 문제

외국인으로서 타국에서 다른 직장을 알아볼 때 가장 먼저 우리의 숨통을 조여 오는 부분은 무엇보다도 '비자'라는 무거운 이름표입니다. 현지인들에게 전직은 그저 연금 수첩을 갱신하고 보험증을 새로 발급받는 약간의 수고로움일지 모릅니다. 하지만 우리는 상황이 완전히 다릅니다. 이직하려는 새 회사의 직무가 현재 소지한 취업 비자의 명목과 조금의 오차 없이 맞닿아 있는지 확인해야 하며, 퇴사 후 14일 이내에 출입국재류관리청에 의무적으로 소속 기관 변경 신고를 해야만 하죠.

만약 다음 행선지를 정하지 못한 채 무직으로 3개월이 넘어가 버린다면, 비자 갱신이 거절될 수도 있다는 보이지 않는 시한폭탄을 가슴에 안고 살아가야 합니다. 더 나은 내일을 위해 내린 결단이었음에도 불구하고, '공백기'라는 시간적 압박은 엄청난 족쇄이자 공포로 다가왔습니다. 당장 생활비도 문제지만, 일본이라는 나라에서 쫓겨날지도 모른다는 근원적인 불안감이 전직 활동 내내 저를 괴롭혔습니다.

연봉의 허수와 무퇴직금의 설움

급격히 달라지는 급여 구조의 맹점 또한 간과할 수 없는 심리적 짐이었습니다. 일본 회사들의 경우 기본 연봉을 단순히 12개월로 균일하게 나누어 지급하는 곳도 있지만, 상여금(Bonus)이 전체 실수령액에서 차지하는 비중이 비정상적으로 큰 구조가 빈번하게 존재합니다. 이 말은 곧, 이직 후 입사 첫해에는 자격 요건 미달로 이 상여금을 온전히 수령하지 못하는 경우가 허다하다는 뜻입니다.

결국 연봉 조건을 높여 이직했음에도 첫해에는 오히려 손에 쥐는 돈이 줄어드는 아찔한 기현상을 마주할 수도 있는 것이죠. 여기에 더해 한국인들에게는 너무나 당연하게 여겨지는 '퇴직금' 제도가 아예 존재하지 않는 일본 기업들이 부지기수입니다. 제가 몸담았던 첫 회사 역시 단 1엔의 퇴직금조차 위로금으로 나오지 않는 곳이었죠. 이직 사이에 잠깐의 빈 타이밍이 발생한다면, 매달 숨만 쉬어도 나가는 살인적인 월세와 각종 세금을 오로지 예금 잔고로 버텨내야 했습니다.

알량한 자만심의 붕괴: 나를 무너뜨린 처절한 실패기

면접장에서 말이 나오지 않는 순간 <출처: 작가>

과거의 애매한 스펙이 발목을 잡다

솔직히 고백하자면, 처음 이력서 작성을 시작할 때까지만 해도 제 마음 한구석에는 은근한 자신감이 깔려 있었습니다. 나름 4년제 대학교에서 컴퓨터공학과를 전공했고, OCJP나 정보처리기사, SQLD 같은 자격증도 몇 개 따 두었으니까요. 대단한 것은 아니었지만, 적어도 서류에서 빈칸을 채울 정도는 된다고 생각했습니다. 실무 경험도 나쁘지 않다고 자부했죠.

한국에서 꽤 비중 있는 SI 프로젝트와 대용량 빅데이터(Big Data) 처리, 전산실 실무까지 경험해 보았습니다. 일본으로 건너와서도 지난 3년 이상 묵묵히 버텨내며, 고객의 가혹한 수정 요청을 이겨내고 성공적으로 납품을 마친 소프트웨어 제품까지 포트폴리오(Portfolio)에 올릴 수 있었습니다. 제가 봐도 꽤 그럴듯한 이력서였습니다. 당연히 어디든 저를 원할 거라고 맹신하며 여러 회사에 과감하게 입사 지원서를 던졌습니다.

소통의 단절, 그리고 드러난 진짜 민낯

서류는 생각보다 쉽게 통과되었습니다. 하지만 실전의 공기는 제 예상과 너무나도 달랐습니다. 가장 뼈아팠고 치명적이었던 패인은 바로 언어, 즉 '일본어 구사력'이었습니다. 한국인 동료들의 친절한 통역 뒤에 숨어서 일하던 시절에는 미처 깨닫지 못했던 제 일본어의 얕은 밑천이 적나라하게 드러난 것이죠. 기술 면접 과정이나 왜 우리 회사여야만 하는지 꼬리를 무는 질문 앞에서 제 입은 무겁게 얼어붙고 말았습니다.

그뿐만 아니라 제 과거의 멋진 경험을 상대방의 관점에서, 매력적인 '이익'으로 포장해 내는 요령도 전무했습니다. "이것도 써봤고, 저것도 다뤄봤다"라는 식의 백화점식 나열형 대답은 면접관들의 흥미를 끌어내지 못했습니다. 기업이 진정으로 필요로 하는 핵심 역량이 무엇인지 꿰뚫어 보지 못한 채, 막연히 "열심히 하겠습니다" 식의 겉도는 파편만 나열했습니다. 철저한 자기 객관화 없이 과거의 타이틀에만 기대었던 안일함이 불러온 쓰라린 실패였습니다.

실패 속에 피어난 자각: 진짜 부족했던 세 가지

세 조각으로 갈라진 거울 속 나의 부족함 <출처: 작가>

얕은 기술력과 앵무새 같은 비즈니스 언어

수없는 불합격의 고배를 마시던 중, 정말 운 좋게도 제 가능성을 믿어준 지금의 회사를 만났습니다. 하지만 최종 합격 메일을 받은 그 밤, 제 마음속에 일렁이는 감정은 환희보다는 부끄러운 자기반성이었습니다. 제가 마주했던 결핍 중 첫 번째는 참담할 정도로 얕은 '기술의 깊이'였습니다. 외부 코드를 가져다 쓰는 임기응변은 능숙했을지 모르나, 정작 컴퓨터 공학의 본질적 코어 원리에 대해 집요하게 파고들어 본 경험이 부족했습니다.

두 번째는 처참했던 '비즈니스 일본어'의 부재였습니다. 코드야말로 만국 공통어라고 자위하며 살았지만, 결국 그 코드를 팀원들과 함께 어떤 가치를 위해 짤 것인지 설득하는 과정은 인간의 언어로 이루어집니다. 상대방의 의도를 곡해 없이 파악하고 나의 논리를 부드럽고 묵직하게 설득해 낼 수 있는 수준의 경어와 뉘앙스 최적화가 안 된다면, 누군가가 시키는 잡무만 받아내는 부속품으로 전락할 수밖에 없음을 아프게 실감했습니다.

모든 걸 밖에서 찾으려 했던 내면의 나태함

마지막으로 저를 가장 부끄럽게 만든 것은 모든 문제의 화살을 외부로 돌리기 바빴던 **'수동적인 태도'**였습니다. 멘토가 없었다면 외부 커뮤니티를 직접 찾아가 기꺼이 제 코드를 까발리며 리뷰를 간청했어야만 했습니다. 회사의 성장이 멈추는 것 같아 억울했다면, 주말을 반납해서라도 오픈 소스(Open Source)를 뜯어보며 스스로 생존의 길을 모색했어야 옳았습니다.

그러나 저는 그 귀중한 시간 동안 가혹한 현실을 불평하고 회사의 보수적인 시스템만 원망하며 한탄하는 구경꾼에 머물렀습니다. 스스로 배의 조타수를 쥐고 거친 파도 속으로 뛰어들 생각은 조금도 하지 못한 채, 언제나 잔잔한 우물 안에서 구조선만 기다리던 불쌍한 개구리였던 셈입니다. 이러한 자각은 저에게 큰 충격을 주었고, 비로소 제가 앞으로 가야 할 길이 보이기 시작했습니다.

환경을 원망하기 전, 내 안의 거울을 먼저 닦아볼까요?

참으로 다사다난했던 저의 첫 번째 전직 생활은 단순히 일하는 회사의 간판을 갈아 끼우는 과정이 아니었습니다. 제 자신을 냉혹한 시장의 저울대 위에 던져 넣음으로써, 그동안 외면하고 싶었던 실력의 비루한 민낯과 마주하는 시간이었습니다. 그리고 현재의 진짜 제 수준을 가감 없이 직시하고 바닥부터 인정하게 만들어 준 세상에서 가장 아프고도 찬란한 성장의 터닝 포인트였습니다.

여러분, 전직은 결코 지금 마주한 일상의 어려움에서 도망치기 위해 선택하는 달콤한 도피처가 되어서는 안 됩니다. 내가 향하고자 하는 뚜렷한 목표 깃발을 꽂고 정면 돌파하기 위한 철저하고 주도적인 '나침반'이 되어야만 하죠. 도전과 좌절이 공존하는 일본이라는 시장에서 우리는 어떻게 생존해야 할까요? 대체 불가능한 개발자로 뿌리내리기 위해서는 비즈니스 언어의 칼날, 시장을 꿰뚫는 통찰력, 그리고 기술적 소양이 완벽하게 맞물려 돌아가야 합니다.

지금 당장 이직 버튼을 눌러야 할지 고민하고 계신 여러분께 조심스럽게 여쭤보고 싶습니다. 지금 여러분이 떠나고 싶은 그곳은 숨 막히는 현실을 피해 도망갈 '안락한 퇴로'인가요? 아니면 나의 역량을 가슴 벅차게 증명해 낼 치열한 '새로운 전쟁터'인가요? 이력서를 쓰기 전에 부디 며칠 만이라도 시간을 내어 자신이 다져온 기술의 뿌리와 태도의 궤적을 서늘하게 되짚어보시기를 권해드립니다.

가장 초라한 내 부족함을 인정하는 그 아픈 순간이 역설적이게도 앞으로 맞이할 수많은 면접관들 앞에서 여러분을 가슴 활짝 펴고 도약하게 만들어 줄 강력한 무기가 될 것입니다. 오늘 비록 에러를 다 잡지 못해 속상했더라도, 묵묵히 전진하는 여러분의 눈부신 내일을 저 역시 뜨겁게 응원하겠습니다.

]]>

코드는 줄고 판단은 남았다: AI 시대 개발자의 일일일

AI 에이전트 시대의 개발자는 어떤 모습이어야 할까?
40년 차 미국 빅테크 개발자부터, 쿠팡·네이버 개발자 인터뷰

“딸깍” 코드가 생성된다. 테스트 코드도 함께 따라온다. 레거시 분석은 몇 분이면 끝난다. POC는 하루 만에 마무리되고, 위키 문서까지 자동으로 정리된다. 요즘 개발자들 사이에서 종종 듣는 말이다. IDE보다 채팅창을 더 오래 바라보는 날이 늘어나고, 최근에는 채팅창을 넘어 클로드 코드 같은 도구를 사용하며 터미널만 바라보는 시간이 많아졌다. 우리는 점점 코드를 덜 쓰는 방향으로 가고 있다. 시니어 개발자가 될수록 설계와 문서화 같은 더 높은 레벨의 일을 해야 한다는 이야기는 오래전부터 있었다.

하지만 이렇게 빠르게 “코드를 덜 쓰는 개발자의 삶”이 올 줄은 예상하지 못했다. 그래서 문득 이런 질문이 들었다. 이게 맞는 방향일까?

주니어는 앞으로 어떻게 성장해야 할까?
리드 엔지니어의 역할은 사라지는 걸까?
우리는 지금 무엇을 공부해야 할까?

그래서 40년 차 미국 빅테크 프린시펄 엔지니어부터 쿠팡, 네이버 개발자에게 같은 질문을 던져보았다.

“AI를 어떻게 받아들이고 있으며, 실제 업무에서는 어떻게 활용하고 있나요?”

“우리는 AI와 페어 프로그래밍을 하고 있다”

첫 번째 인터뷰: 40년 차 미국 빅테크 개발자
그는 세미나에서 만난 40년 차 개발자였다. 아마존을 포함한 여러 빅테크에서 시스템을 설계했고, 현재도 미국 빅테크에서 프린시펄 엔지니어로 일하고 있다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

내가 개발을 시작한 80년대에도 AI는 핫한 토픽이었어. Smalltalk 머신도 있었지. 다만 그때는 연산 능력과 데이터가 부족했을 뿐이야. 페어 프로그래밍(Pair Programming)에 대해 잘 알지? 내가 이렇게 연차가 쌓이고 나와 함께 페어 프로그래밍을 하겠다고 찾아오는 사람은 없는데, 지금은 AI와 페어 프로그래밍을 하는 것 같아. 다만 이제는 상대가 사람이 아니라 모델일 뿐이지.

그에게 AI는 처음 보는 토픽이 아니었다. 하지만 예전과 달리, 지금은 이론과 실험을 넘어 실용적인 도구로 실제 업무에 적극 활용된다는 점이 다르다고 했다.

AI는 정말 페어 프로그래머처럼 동작한다.

코드를 제안한다.
리팩토링을 제안한다.
테스트를 작성한다
구조를 정리해준다.
문서를 만든다.

하지만 그는 중요한 차이를 강조했다. “AI는 비판하지 않아. AI와 대화해 보면 알겠지만, 아직까지는 내가 질문한 의도대로 답변하는 경향이 있지. 그리고 이것이 사람과의 대화에서 가장 큰 차이점이라고 생각해.”

사람과 페어 프로그래밍을 하면 의견에 대한 반박이 오가고, 논리와 근거에 따라 때로는 내 의견이 받아들여지기도 하고, 상대방의 의견이 받아들여지기도 한다. 그리고 그 과정을 거쳐 코드가 완성된다. 나의 경우에도 페어 프로그래밍을 하다가 코드 컨벤션 문제로 크게 충돌했던 경험이 있었는데, 결국 그 사람과 팀이 달라지고 나서야 해결됐다. 지금 생각해 보면 아주 중요한 일은 아니었는데 말이다. 이렇듯 사람과의 페어 프로그래밍은 때로 강한 논쟁을 수반한다.

하지만 이와 달리 AI는 사람이 반박하면 대부분 수용적인 입장으로 바뀌고, 이를 최대한 답변에 녹여내려 한다. 최근에는 이런 점 때문에 코드 리뷰 에이전트에 ‘무조건 반대하는 입장에서 코드를 리뷰’하는 역할을 부여하기도 한다는 글이 종종 보인다.

Q. 우린 어떤 것을 준비해야할까요?

다들 느끼겠지만, AI의 결과의 퀄리티는 질문과 설계의 퀄리티에 달려있어. 그리고 이 말은 내가 개발을 시작했던 40년 전에도 똑같이 들었던 이야기야. 물론 AI의 결과가 아닌 사람의 결과라는 차이점이 있지만 말이지. 따라서 내가 어떤 문제를 풀고자 하는지를 정확히 아는지 중요해, 이전에 주니어 레벨은 주어진 것만 완벽히 그리고 빠른 시간내에 구현하는 것이 최고였지. 그런데 이제는 AI가 더 빠르고 더 완벽해, 물론 질문이 완벽하다는 전제가 필요하지만. 아무튼 이젠 질문하는 법을 배워야해 다른 것은 그 다음에 챙겨도 돼.

생각해 보면 이런 류의 작업은 전통적으로 주니어를 넘어 시니어의 일이었다. 어떤 문제인지 정의하고, 어떤 방법으로 해결할지를 설계하고, 또 일을 분배하는 작업을 말한다.

이 문제의 이해관계자는 누구인가?
언제까지 이 문제를 해결해야 하는가?
어떤 제약 사항이 있는가?
성공적인 문제 해결의 기준과 측정 방법은 무엇인가?

그는 또 하나의 우려를 덧붙였다. “나는 주니어가 초기에 겪어야 할 고통이 없다는 게 두렵다고 봐.그러니 그 경험을 준비하라고 말해주고 싶지.”

버그를 추적하며 스택을 따라 내려가는 경험, 잘못된 설계로 장애를 내보고 복구하는 경험, 이런 감각은 자동으로 생기지 않는다고 그는 말했다. 그리고 이런 경험을 바탕으로 시스템을 설계하면서, 시스템의 가용성, 회복성 등 여러 가지를 고려하는 능력이 자연스럽게 길러진다고 덧붙였다.

“그렇다고 AI를 쓰지 말라는게 아니야. AI와 함께 버그를 추적하며 설계를 해보면 돼.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

크게 두 가지가 있어. 원래 나는 간단한 사이트를 만들 시간이 없어. 그래서 대부분 주니어 개발자에게 위임하곤 했지. 그런데 이번에는 AI와 함께 주말 동안 만들어봤어. 피그마 디자인과 함께 말이지. 그다음으로는 특정 DB 버그의 stack trace 전문을 읽게 했더니, 한 번에 오류를 찾아냈어. 그 방법론과 접근법은 내가 생각한 것과 매우 유사했고, 결과도 내가 예상했던 이슈와 정확히 일치했지.

그가 사용했던 방법은 우리가 사용하던 것과 크게 다르지 않았다. 다만 이전에는 시간이 없어 하지 못했던 일, 그리고 본인이 생각했던 검증을 누구보다 빠르게 실행해 주는 도구로 AI를 활용하고 있었다.

그리고 덧붙여 말했다. “AI는 도구야. 장인은 도구를 탓하지 않는다던데, 실력도 좋은데 도구까지 좋으면 더 빨리, 더 멀리 갈 수 있지 않겠나?”

이 말을 듣고, AI에 매몰되지 말자고 스스로 다짐했던 생각이 다시 떠올랐다. 40년 차인 그에게 AI는 본인의 일을 빼앗는 경쟁자가 아니라, 만능 도구에 불과했다는 점이 아이러니하게 느껴졌다.

스킬을 만드는 스킬을 만들어요

두 번째 인터뷰: 쿠팡 9년 차 프론트엔드 개발자
여러 스타트업을 거쳐 쿠팡에 들어간 9년 차 개발자인 그는 개발을 시작할 때부터 프론트엔드만 집요하게 파고들었다. 그런 그를 이전 회사 동료로서 인터뷰해 보았다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

핫하기도 하고, 회사에서도 AI를 업무에 많이 녹이려고 노력하고 있어요. 그리고 매니저와 1대1 미팅을 할 때도 요새 AI를 업무에 어떻게 사용하고 있느냐는 질문을 꼭 받아요. 제가 여기 들어온 지 이제 반년인데, 입사할 때부터 계속 같은 질문을 하시더라고요. 재작년까지만 해도 AI는 딱 제 연차에 엄청난 기회를 준다고 했어요. 절대적인 코딩 시간이 부족한 시니어 개발자에게 주니어 개발자를 여럿 붙여준다는 의미였지요. 그런데 지금 생각하면 아니에요. 모든 개발자에게 엄청난 기회를 주고 있다고 느껴요. 물론 AI가 여기서 더 발전하면, 그때는 어떻게 될지 모르겠네요.

쿠팡에서는 대부분의 팀이 AI 도구를 활용하고 있다고 한다. 그리고 전사적으로 할당된 AI 툴을 선점하기 위해 오픈런이 가끔씩 벌어지기도 한다고 한다.

“agent.md 문서를 계속 업데이트해요. AI가 일관된 방향으로 작업하도록 규칙을 정리하고, 또 계속 추가하죠. 그리고 AI가 리뷰를 해주는데, 코멘트나 컨벤션에 어긋나는 부분이 있으면 바로 규칙에 반영해요. 제가 작성하는 PR 중 10%는 오로지 AI를 위한 수정 사항이에요.”

그러면서 간단한 예시를 몇 개 말해줬다.

“테스트 코드는 XXXX 이런 식으로 작성해야 해요. jest 규칙에 언급되어 있죠. 하지만 AI가 그것을 누락했으니 규칙을 추가해야 하죠. CSS의 design token은 YYYY에 있는 파일에서 가져다 써야 해요. 그런데 기존 코드베이스에서는 이게 섞여 있어서 잘못된 방식으로 읽어오고 있으니, 여기도 규칙을 추가해야 해요.”

옆에서 보는 그의 모습은 마치 AI에게 코드 리뷰를 하고 있는 듯했다. 그리고 그는 이렇게 말했다.

“실은 지금 말했던 예시들은 제가 초반에 입사하고 나서 받았던 코드 리뷰 내용이에요. 처음에는 하나의 PR에 대충 30개의 리뷰가 달렸었어요. 그중에는 간단하지만 반복되는 리뷰들도 있었죠. 그래서 중간에는 자체적으로 ‘pr-check’라는 스킬을 만들어, 코드 리뷰에서 반복적으로 나오는 코멘트를 먼저 수정하는 과정을 거쳤었죠. 그리고 최근에는 AI 리뷰가 자동으로 도입되면서, 이런 스킬들을 바탕으로 agent rule을 만들어 계속 추가하고 있네요.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

쿠팡은 아니고, 이전 회사에서 CMS(Content Management System)를 자체적으로 구현해야 했어요. 콘텐츠가 정적인 텍스트로만 이뤄지면 참 좋겠지만, 실제로는 다양한 미디어 파일과 인터랙션을 포함한 데모형 콘텐츠가 많았죠. 그래서 ‘puck editor’라는 오픈소스를 가져와 구현했어요. 이 라이브러리는 제가 사전에 구현해 둔 컴포넌트를 바탕으로, 사용자가 drag & drop으로 컴포넌트를 가져와 콘텐츠를 수정할 수 있어요.

<출처: 공식 홈페이지>

그리고 저는 여기에서 사용되는 컴포넌트들을 AI를 이용해 대부분 만들었어요. 예전 같으면 해당 컴포넌트를 만드는 데 컴포넌트 하나당 며칠씩은 걸렸을 거예요. 그런데 AI를 이용해 회사에서 쓰는 디자인 시스템을 바탕으로 puck editor에 필요한 컴포넌트로 포팅하는 작업을 전체 3일 만에 끝냈어요. 기본적인 레이아웃용 컴포넌트와 데모용 컴포넌트까지 포함하면 대략 30개 정도를 지원했던 것 같은데, 이전에는 상상도 못 할 속도예요. 그리고 저는 이 시스템을 만들어보면서 AI가 수평 확장에 정말 강력하다는 걸 깨달았어요.

같은 구조를 여러 곳에 적용해야 할 때, AI는 압도적으로 빠르다. 그러면서 그는 말을 덧붙였다.

“그렇다면 개발자가 할 일은 수평 확장이 가능하도록, 수직 확장의 토대를 마련하는 것이죠.”

AI는 지시된 방향 안에서 훌륭하다. 하지만 방향을 설정하고, 수직 확장이 가능하도록 토대를 만드는 일은 여전히 인간, 곧 개발자의 몫이다.

Q. 요새 어떤 것을 공부하고 계시나요?

방금 말한 것처럼, 수직 확장을 위해 조금 더 깊은 내용을 공부하고 있어요. 최근에 읽은 책으로는 <멀티패러다임 프로그래밍(유인동 저)>을 포함해, 테스트 코드를 위한 책들을 중점적으로 보고 있습니다.

인터뷰이가 공유해 준 책 구매 이력 <출처: 작가>

요새 AI가 테스트 코드를 잘 만들어주잖아요. 그런데 그게 테스트 개수만 늘리는 건지, 테스트 커버리지만 채우는 건지 제가 잘 모르겠더라고요. 그래서 이번 기회에 테스트 코드에 대해 깊이 있게 학습해보려고, 우선 5권을 구매해서 보고 있어요. 지금은 4권째 읽고 있습니다. 여기에서 읽은 지식과 학습한 내용을 바탕으로, 테스트 코드를 위한 agent.md 파일을 작성하는 것을 목표로 삼고 있어요.

현재 제가 주로 일하는 서비스는 AI가 본격적으로 도입되면서 테스트 코드가 3배가량 증가했어요. 제 목표는 이것들을 더 이상 늘리지 않고, 유의미한 개수로 유지하는 거예요. 테스트가 많아질수록 CI/CD 시간이 오래 걸리고, 불필요한 테스트는 오히려 리팩토링 프로세스에도 좋지 않은 영향을 주니까요.

Q. 왜 이렇게 테스트 코드에 진심이세요?

요즘 일부에서는 ‘코드를 안 보고 배포한다’는 말도 나오는데, 저는 AI를 신뢰하는 것과 판단을 위임하는 것은 다르다고 생각해요. 만약 제가 혼자 일하고 모든 책임도 혼자 진다면, 코드를 안 보고 배포할 수도 있겠죠. 하지만 실제 제품은 혼자 힘으로 동작하지 않아요. 따라서 안 보고 배포한다는 말은, 나는 책임질 수 없으니 너희가 책임지라는 의미처럼 들려요.

그렇지만 또 AI가 생성하는 코드를 안 쓸 수는 없죠. 저는 AI가 생성한 코드의 책임을 테스트 코드에서 찾아보고 있어요. 요새는 ‘테스트를 통과하면 제대로 된 기능이다’라는 말도 유행하고 있어요. 이게 맞는 명제인지는 모르겠지만, 현실적인 타협안이라고 생각하고 있습니다.

9년 차 개발자는 책임을 질 수 있는 수준으로 AI를 활용하고 있었고, 그 책임을 위해 여러 가지 자신만의 규칙과 환경을 만들어가며 깊이 공부하고 있었다. 그렇다면 규칙은 어떻게 세우고 있는지 물어봤다.

“요새 많이 하는 것 중 하나는 ‘이때까지 대화 중에 스킬이나 룰로 만들 수 있는 것이 있으면 만들어줘’라는 명령어예요. 그리고 이를 바탕으로, 위에서 말한 스킬을 만드는 스킬(/create-skills)을 커스텀해서 만들고 있어요.”

스킬을 만들기 위한 스킬이라니, 처음 재귀 함수를 봤을 때처럼 오묘하고 신기했다.

나는 직접 코드를 안 쓴 지 두 달째다

세 번째 인터뷰: 네이버 12년 차 백엔드 개발자
그는 프론트엔드로 시작해 백엔드를 거쳐, 현재는 풀스택으로 일하고 있다. 그리고 이제 막 매니저 역할을 시작한 초보 매니저이기도 하다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

갑자기 생각난 건데, 올해(인터뷰 날짜 기준 3월 초)에는 IDE를 안 켜본 것 같아요. 갑자기 소름이 끼치네요. AI가 핫한 만큼 저도, 그리고 조직도 AI에 발 빠르게 적응하려고 준비하고 있어요.

IDE를 안 켠다고 해서 개발을 안 하고 있는 것은 아닙니다. 오히려 PR 양은 이전보다 더 늘어났어요. 저는 주로 클로드 코드를 사용하고 있는데요. 문서와 지라 티켓에 상세하게 작성된 PRD(Product Requirements Document, 제품 요구사항 정의서의 약자로 서비스나 기능의 목표, 타깃 고객, 핵심 기능, 성공 지표 등을 명확히 정의해 개발팀, 디자인팀 등 이해관계자와 공유하는 문서)를 클로드 코드가 알아서 가져와 백엔드 코드를 작성해줘요.

물론 제가 하는 일이 단순히 API를 만드는 것뿐만 아니라 다양하게 있지만, 그래도 그중에서 가장 많은 시간을 잡아먹는 것은 단연 API를 만드는 부분이죠.

그는 최근 IDE를 사용하는 시간이 눈에 띄게 줄었다고 말했다. 그렇다면 개발 시간은 과연 줄어들었을까?

“단순히 AI가 있어서 개발 시간이 10분의 1로 줄었나? 생산성이 10배, 100배가 되었나? 이런 느낌은 아니네요. 제가 하는 업무가 단순히 코딩이 전부가 아니고, 또 AI가 이렇게 발전하기 전에도 코딩 그 자체가 시간을 가장 많이 잡아먹는 일은 아니었거든요. 요즘도 그렇고 이전에도 코딩보다는 컨텍스트를 정리하고 문서화하는 시간이 더 길어요. 여러 가지 문서를 읽고 R&R(Role & Responsibilities의 약자로, 조직이나 프로젝트 내에서 각 구성원이 맡은 ‘역할과 책임’을 의미)를 정리하는 일이죠. 대신 한 가지 고무적인 점은, 제가 하는 컨텍스트 정리와 문서화 작업이 실제로 개발 속도를 끌어올린다는 점입니다.

제가 이 작업을 하는 이유는 개발자들(프론트엔드, 백엔드)에게 스펙을 정의하고 전달하기 위해서였어요. 때로는 기획자의 역할도 해야 하니, 이런 부분을 구체화하고 통일한 문서를 바탕으로 기능을 만들기 위해 시간을 들여 정성껏 작성하고 공유하는 것이었죠. 물론 이 작업이 개발자들의 일을 줄여주기도 합니다. 제대로 된 문서는 잘못된 개발 방향을 초반부터 걷어내고, 불필요한 의사소통 비용을 줄여주니까요. 하지만 이게 직접적으로 코딩 그 자체의 속도에 영향을 주지는 않았어요.

그런데 AI가 본격적으로 업무 프로세스에 녹아들면서 달라졌어요. 제가 만든 문서는 AI가 일을 한 번에, 그리고 제대로 하게 만드는 잘 정리된 Plan 문서로 동작합니다. 실제로 저는 업무를 정리하면서 해야 할 To-do list를 만드는데, 이것조차 AI를 잘 동작하게 하는 하나의 방법론으로 작동합니다.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

아마 많은 분들이 직접적인 개발 과정에서 AI를 활용한 경험을 말씀하실 텐데요. 저는 오히려 비개발적인 부분에서 AI를 활용하는 일이 생산성을 더 높여준다고 생각합니다. 예를 들어, 매니저인 저에게 지라 티켓이나 일정을 관리하는 일은 항상 어렵고 큰일이지만, 사실 하기 싫은 일이기도 하죠. 왜냐하면 그 많은 지라 티켓을 일일이 확인하면서 기능 개발이 어디까지 왔는지, 또 일정은 잘 진행되고 있는지 체크하는 건 너무 번거로운 일이기 때문이에요.

지라 대시보드나 여러 기능도 있지만, 많은 개발자분들이 경험적으로 느끼시겠지만 생각보다 지라 티켓이나 일정 관리를 꼼꼼히 하지 않아요. 주로 개발을 시작할 때 한 번, 그리고 개발이 전부 마무리돼 ‘완료’ 처리할 때 한 번, 이렇게 두 번 정도만 상태를 변경합니다. 이게 개발자 입장에서는 꽤 번거로운 일이거든요. 그래서 저는 이 프로세스의 상당 부분을 클로드 코드를 이용해 자동화하고 있습니다.

클로드 코드를 연결해 지라 티켓을 가져온 뒤, 어떤 작업을 시작할 거라고 하면 클로드 코드가 다음 작업을 진행해줍니다.

지라 티켓 status 변경
지라 티켓 번호를 포함한 브랜치 설정
해당 브랜치를 기반으로 GitHub draft 작성

이렇게 되니 ‘지라 대시보드와 GitHub pull request에서 누가 어떤 작업을 진행 중이구나’를 한눈에 볼 수 있더라고요. 그리고 하루에 한 번씩 일정 관리 크론잡도 돌고 있는데요. 지라 티켓과 GitHub 정보, 그리고 일정 정보를 바탕으로 일이 어느 정도 진행되고 있는지 알려주는 스크립트입니다. 저는 이것을 통해 매니저 역할을 해 나가고 있어요.

그러면서 그는 클로드 코드에서 해당 화면을 보여주었다. 그의 클로드 코드는 터미널 기반이지만, 한껏 커스텀되어 필자가 보기에도 깔끔한 하나의 매니저 도구처럼 보였다.

“그리고 하나의 작업이 더 있어요. 제가 오늘 하루 동안 작업한 내용을 바탕으로 성과 관리 문서를 생성합니다. 그리고 주간, 월간, 분기 단위로 제 성과 관리를 해가고 있어요. 아직 이 자동화를 시작한 지 반년이 안 돼서 연간 단위는 없지만, 지금 추세라면 연간 성과 관리도 잘할 수 있을 것이라 생각합니다.”

그가 자동화에 푹 빠져 클로드 코드에 대해 설명하던 그 순간은, IDE를 몇 달 동안 켜지 않았음에도 가장 개발자답게 보이는 순간이었다.

Q. 요새 어떤 것을 공부하고 계시나요?

“제가 학부생 때는 동기들끼리 마우스 없이 코딩하는 날 같은 것도 만들어서 했었어요. 그때는 vim으로 빠르게 코딩하는 게, 뭔가 동기들 사이에서 실력의 척도였어요. 초등학교 때 타자 수가 빠르면 컴퓨터를 잘하는 사람 취급받는 것처럼요. 생각해 보니 그때도 속도가 전부였네요. 아무튼 그때 저는 코딩을 잘하기 위해 도구 사용법을 따로 시간을 들여 공부했어요. 그리고 AI도 마찬가지라고 생각해요. 시간을 들여 익혀야 해요. 우리가 vim 수련을 한 것처럼요.

요새는 또 하네스 엔지니어링(인공지능 모델, 특히 LLM(거대 언어 모델)을 감싸서 그 능력을 실전에 안전하게 활용할 수 있도록 통제하고, 도구와 연결해 실제 행동을 수행하게 하는 외부 소프트웨어 프레임워크 또는 구조)이나 AI 오케스트레이션(거대 언어 모델(LLM), 이미지 모델, 데이터베이스 등 서로 다른 AI와 시스템을 하나의 워크플로 안에서 지휘자처럼 통합·관리해, 단일 모델로 해결하기 어려운 복잡한 문제를 풀고 효율을 높이는 기술) 같은 것들을 어떻게 활용할 수 있을지 고민해보고 있어요.

그리고 이런 것들은 때로 너무 빨리 변해서, 제가 공부하기도 전에 새로운 방법론과 패러다임의 변화가 일어나기도 합니다. 그래서 불안하기도 하죠. 그래도 어쩌겠습니까? 다들 AI라는 비행기를 타고 날아가고 있는데, 저만 뛰어갈 수는 없잖아요.

신이 나서 클로드 코드를 만지고 있는 그의 모습에서, 어쩌면 AI라는 비행기의 속도보다 하늘을 난다는 그 기술 자체에 매료된 한 사람을 본 것 같았다.

세 명의 개발자와의 인터뷰를 마치며

세 사람의 이야기를 듣고 나니 한 가지는 분명했다. AI가 등장했다고 해서 개발이라는 일이 완전히 다른 일이 된 것은 아니라는 점이다. 다만 우리가 시간을 쓰는 방식이 조금 바뀌고 있을 뿐이다. 코드를 직접 작성하는 시간은 줄어들고, 문제를 정리하고 맥락을 설명하고 방향을 잡는 시간은 늘어나고 있다.

40년 차 엔지니어는 좋은 결과는 여전히 좋은 질문에서 시작한다고 말했다. 쿠팡 개발자는 AI가 잘 일하도록 규칙을 계속 추가하고 있었고, 네이버 개발자는 문서와 맥락을 정리하는 일이 개발 속도를 높인다고 했다. 세 사람의 이야기를 듣다 보니 결국 같은 결론으로 이어졌다. AI는 일을 더 빠르게 만들어주는 도구지만, 무엇을 만들지 결정하고 책임지는 일은 여전히 사람의 몫이라는 것이다.

그래서 요즘의 개발자는 코드를 얼마나 많이 쓰느냐보다 어떤 문제를 풀려고 하는지, 어떤 맥락에서 이 일을 하는지, AI에게 무엇을 맡기고 무엇은 직접 판단할지를 조금 더 깊이 고민하게 되는 것 같다. 아직 정답은 없다. 지금은 모두가 조금씩 자기 방식으로 실험해보고 있는 시기인 듯하다. 그래서 인터뷰를 마치고 나서 남은 질문은 이것 하나였다. “나는 오늘 AI에게 무엇을 시켰는가”가 아니라, “나는 오늘 어떤 문제를 풀려고 했는가?”라는 것. 여러분은 어떻게 생각하시나요?

]]>

채용 공고에서 말하는 ‘주도적인 사람’은 누굴까?

“주도적으로 문제를 해결하는 분”

채용 공고에서 정말 흔하게 마주치는 문구입니다. 하지만 이 단어를 보는 이들의 마음은 그리 편치 않습니다. 여기서 말하는 주도성이, 회사가 시키지 않아도 알아서 야근하고 남의 일까지 떠맡는 ‘가성비 좋은 일꾼’을 찾는 표현처럼 들리기 때문이죠.

하지만 우리가 느끼는 이 피로감은 단어 자체의 잘못이 아닙니다. 주도성을 단순히 개인의 성격 문제로 치부하는 오해, 나아가 이 주도성이 회사와 나에게 어떤 의미인지 제대로 알지 못해 생기는 오해, 이 두 가지 ‘해석의 오류’가 그 원인입니다.

<출처: 작가, Gemini 생성>

사실 진정한 의미의 주도성은 회사를 위한 무조건적인 희생이 아닙니다. 자기 전문성을 지키기 위한 전략이며, 협업에서 발생하는 불필요한 비용과 불확실성을 줄여 나가는 실력에 가깝습니다. “저는 시키는 대로 다 했는데요?”라는 말이, 그리고 그런 태도가 조직의 속도를 늦추고 나의 가치를 갉아먹고 있다면 더욱 주도성에 대해 완전히 다시 정의해야 합니다.

그렇게 이 글에서는 우리가 흔히 오해하는 주도성을 제대로 이해해 보고, 왜 주도적인 태도가 결국 ‘진짜 실력’으로 치환되는지 다음의 세 가지 관점에서 깊이 있게 다뤄보려 합니다.

첫째, 태도의 차이가 만드는 결과: “안 돼요”와 “이렇게 하면 돼요”라는 한마디가 프로젝트의 성패와 동료의 신뢰를 어떻게 가르는지 5가지 구체적인 사례로 살펴봅니다.
둘째, 태도가 실력이 되는 메커니즘: 주도적인 태도가 어떻게 기술 부채를 관리하고, 동료들에게 ‘예측 가능한 확신’을 주는 전문성으로 이어지는지 분석합니다.
셋째, 주도성과 조직의 상관관계: 개인의 주도성이 꽃피기 위해 필요한 환경은 무엇이며, 질문의 비용이 낮아질 때 조직이 어떻게 스스로 움직이게 되는지 이야기합니다.

결국 주도성은 회사가 원하는 인재상이 되기 위해서가 아니라, “이 회사에서는 더 이상 성장할 수 없을 것 같다”는 매너리즘에서 나를 구하고 나의 시장 가치를 스스로 증명하기 위해 필요한 능력입니다. 지금부터 주도성이 무엇인지, 그리고 어떻게 주도적인 사람이 될 수 있을지를 알아보겠습니다.

태도의 차이가 만드는 신뢰

우리는 늘 수많은 선택을 해야 합니다. 새로운 기능을 추가하자는 기획자의 요청, 갑작스러운 버그 수정 지시, 혹은 기존 시스템의 구조를 바꿔야 하는 기술적 결정에 따라서죠. 이때 우리가 내뱉는 말 한마디는 단순 의사소통을 넘어 내가 이 일을 어떻게 바라보는지 보여줍니다. 그렇기에 동료가 나를 신뢰할 수 있을지 가늠하는 지표가 되기도 합니다.

이 말들이 주도적인 태도와 수동적인 태도에 따라 어떻게 달라지는지, 5가지 예시 상황으로 살펴보겠습니다.

<출처: 작가, Gemini 생성>

1. 안 돼요 vs. 이렇게 하면요?

수동적: 그 기능은 지금 구조상 안 돼요. 서버 부하가 너무 커서요.
주도적: 현재 구조로는 서버 부하가 우려되네요. 하지만 데이터 노출 범위를 제한하거나, 캐시를 활용하는조건이라면 가능할 것 같습니다.

방어적인 태도는 늘 안 되는 이유를 찾기 바쁩니다. 기술적 제약을 자신을 보호하는 논리로 쓰기 때문이죠. 반면 주도적인 사람은 제약이 있음을 인정하면서도, 그 안에서 실행 가능한 옵션을 먼저 제시합니다. 동료에게 거절이 아닌 ‘대안’을 건네는 것, 바로 이 지점이 협업의 속도를 결정합니다.

다만, 오해는 말아야 합니다. 주도성이 모든 요청에 무조건적인 Yes를 외치는 희생을 의미하는 것은 아니라는 점입니다. 주도성은 오히려 프로젝트의 본질을 해치는 불필요한 요청을 논리적으로 거절하고, 진짜 해결해야 할 핵심 문제에 에너지를 집중하는 전략적 선택에 가깝습니다.

2. 다 했습니다 vs. 이게 최선일까요?

수동적: 요청하신 기획대로 구현 다 했습니다. 확인해 보세요.
주도적: 요청하신 기능을 구현하다 보니, 이 버튼을 누를 때 실제 사용자 흐름이 끊기더라고요. 이게 최선일까요? 로딩 애니메이션을 추가하는 게 나을 것 같아 함께 수정해 봤습니다.

수동적인 이들에게 완료의 기준은 전달받은 기획이나 티켓의 종료입니다. 하지만 주도적인 이들에게 완료의 기준은 문제의 원인 파악과 해결입니다. 단순히 코드를 짜는 행위를 넘어, 이 결과물이 사용자에게 어떤 경험을 줄지 고민하는 것이죠. 이러한 고민이 결국 제품의 퀄리티를 한 단계 끌어올리는 원동력이 됩니다.

3. 원래 이랬는데요? vs. 지금도 정말 유효할까요?

수동적: 이 코드 원래 이랬는데요? 전임자가 짜놓은 거라 건드리면 위험합니다.
주도적: 로직이 복잡하긴 하지만, 지금의 트래픽 규모에서도 정말 유효할까요? 리팩토링 계획을 세워 조금씩 개선해 보겠습니다.

익숙함은 편안하지만 동시에 위험합니다. 수동적인 사람은 변화로 인해 발생할 문제와 그에 따른 책임을 두려워합니다. 반면 주도적인 사람은 현재의 맥락에서 과거의 유산을 끊임없이 재평가합니다. 그리고 시스템이 점점 낡아가는 상황을 방지하려고 스스로 일을 자처합니다.

4. 제 일 아닌데요? vs. 같이 논의해 보겠습니다

수동적: 그건 인프라 업무잖아요, 제 일 아닌데요?
주도적: 이 이슈가 그대로면 결국 사용자에게 영향이 가지 않나요? 일단 제가 한번 확인해 보고, 담당자에게 로그 데이터 공유해서 같이 논의해 보겠습니다.

R&R은 책임의 범위를 정하기 위한 도구이지, 협력을 거부하기 위한 장치가 아닙니다. 주도적인 사람은 이슈의 주인이 누구인지보다 문제 해결이 더 중요하다는 사실을 알고 있습니다. 그래서 기꺼이 경계를 넘나들며 조직 곳곳에 흩어진 정보를 연결합니다.

5. 굳이 해야 해요? vs. 검증하고 결정하죠

수동적: 에이, 이거 예전에도 해봤는데 안 됐어요. 굳이 해야 해요?
주도적:과거에 실패한 이력이 있네요. 그때 실패 요인이 지금도 유효한지, 핵심 가설만 작게 검증(PoC)해보고 결정할까요?

부정적인 태도는 아무것도 하지 않는 방향으로 갑니다. 가장 쉽고 비용이 적게 드는 선택이죠. 하지만 주도적인 사람은 과거의 실패에 머물지 않습니다. 대신 지금, 여기서, 어떻게 검증할지, 그 방법을 제안합니다. 이들에게 실패는 좌절의 이유가 아니라 다음 실험을 더 정교하게 다듬을 데이터일 뿐입니다.

그렇다면, 이러한 차이는 어디에서 비롯될까요? 단순히 착해서 혹은 열정이 넘쳐서 생기는 것일까요?

아닙니다. 이는 바로 자신의 일을 대하는 오너십(Ownership)의 차이에서 시작됩니다. 한편 이런 태도의 차이는 실제 개인의 실력과 어떤 상관관계를 가지는 지도 궁금해집니다. 태도가 어떻게 기술적 실력으로 이어지는지, 그리고 왜 주도적인 사람이 결국 ‘진짜 전문가’가 될 수밖에 없는지 함께 살펴보겠습니다.

태도와 실력은 어떤 관계일까?

흔히들 엔지니어의 실력을 알고리즘 해결 능력이나 기술 스택의 숙련도로 생각합니다. 하지만 시니어 레벨로 올라갈수록 실력이란 복잡성을 관리하고 지속 가능한 가치를 만드는 능력으로 확장됩니다. 바로 이 지점에서 주도적인 태도가 압도적인 기술의 격차를 만들어 냅니다.

<출처: 작가, Gemini 생성>

1. 기술 부채를 만드는 나쁜 태도

개발 현장에서 말하는 기술 부채(Technical Debt)는 단순히 나쁜 코드를 의미하지 않습니다. 이는 현재의 편의를 위해 미래의 유지보수 비용을 미리 끌어다 쓰는 행위에 가깝습니다.

수동적인 개발자는 명시되지 않은 예외 상황을 종종 무시합니다. “로그 처리가 빠졌지만, 기획에 없었으니까” 혹은 “테스트 코드를 작성하기엔 일정이 너무 타이트하니까”라고 말하면서 말이죠. 이러한 선택은 당장의 배포 속도를 높여 주지만, 머지않은 미래에 누군가가 더 많은 시간을 들여 디버깅해야 하는 부채로 돌아옵니다.

반면 주도적인 개발자는 기술 부채를 더 전략적으로 다룹니다. 당장 구현이 급하더라도 “이 부분은 나중에 확장할 때 병목이 될 것 같다”며 의견을 먼저 제시합니다. 혹은 최소한의 인터페이스라도 미리 설계해 둡니다. 이런 방식은 더 큰 기술 부채로 이어질 요소의 범위를 제한하고, 시스템의 복잡도를 낮춥니다. 결과적으로 주도적인 태도가 곧 코드의 품질을 좌우하고, 조직 전체의 기술 자산을 지키는 실력으로 이어집니다.

2. 계산할 수 있는 신뢰의 가치

개발 과정에서 ‘확정된 기획’은 매우 중요합니다. 설계 과정에서 고민해야 할 범위를 줄여 주고, 시스템의 복잡도를 낮춰 주니까요. 협업에서도 상황은 크게 다르지 않습니다. 동료에게 가장 신뢰받는 사람은 결과물의 수준과 시점을 예측 가능하게 만드는 사람입니다.

그런 관점으로, 주도적인 사람은 협업에서 발생하는 변수를 예측 가능한 형태로 바꿔 줍니다.

일이 지연될 것 같으면 문제가 터지기 전에 미리 상황을 공유합니다.
불확실한 요구사항은 코드를 작성하기 전에 질문해 명확히 합니다.
본인의 작업이 다른 파트(QA, 디자인, 인프라)에 미칠 영향을 먼저 점검합니다.

이러한 행동은 동료들의 컨텍스트 스위칭(Context Switching) 비용을 크게 낮춰 줍니다. 리더의 입장에서도 이런 팀원은 사사건건 확인하지 않아도, 스스로 완벽한 결과를 가져오는 가장 든든한 동료가 됩니다.

이처럼 주도적인 사람은 조직의 커뮤니케이션 부채를 줄여 줍니다. 미리 공유되는 리스크와 진행 상황 덕분에 리더는 확인을 위한 불필요한 회의를 줄이며, 본질적인 의사결정에 집중할 수 있게 됩니다. 이것이 바로 주도성이 만들어 내는 ‘계산할 수 있는 신뢰’의 가치입니다.

3. 전문성을 확장하는 가장 빠른 경로

전문가는 자기 분야를 깊게 파는 사람(I자형 인재)을 넘어, 인접 분야와도 소통할 수 있는 사람(T자형 인재)으로 진화해야 합니다. 이 과정에서 주도성은 소통을 돕는 가장 중요한 요소입니다.

프론트엔드 개발자가 API 응답 속도가 느리다고 불평만 하는 대신, 직접 백엔드 코드를 열어보거나 쿼리 실행 계획을 함께 고민해 본다면 어떨까요? 그는 자연스럽게 네트워크 프로토콜, 데이터베이스(DB) 인덱싱, 서버 아키텍처까지 이해하게 됩니다. 이렇게 자신의 R&R을 넘어선 주도적인 관심은 기술적 시야를 넓히는 가장 빠른 경로가 됩니다.

결국 전문성이란 내가 하는 일의 앞과 뒤를 이해하는 힘입니다. 내 코드가 어디서 시작되고, 어디로 흘러가는지를 고민할 때, 비로소 전체 아키텍처를 설계할 수 있는 진짜 실력이 생깁니다.

이처럼 주도성은 나를 둘러싼 환경의 불확실성을 줄이고, 내 전문성의 영역을 넓혀 가는 행동입니다. 이러한 태도는 개발뿐 아니라 기획, 디자인 등 모든 직무에 동일하게 적용됩니다. ‘안 된다’며 제약 뒤에 숨어 방어적으로 대응하기보다, 제한된 자원 안에서 최선의 결과를 만들기 위한 구체적인 시나리오를 먼저 제시하는 것. 이것이 바로 주도성의 본질입니다.

주도성을 만들어주는 조직

많은 리더는 “우리 팀에는 주도적인 사람이 없어요”라며 한탄합니다. 하지만 팀원들의 이야기는 다르죠. “의견을 내봤자 바뀌는 건 없고, 일만 늘어나요.”라고 합니다. 이 간극은 어디서 오는 걸까요? 주도성이 건강하게 작동하려면 개인의 태도만큼이나 조직의 반응 또한 중요한 이유입니다.

1. ‘피곤한 오지랖’으로 보지 않는 환경

주도적인 사람은 기존 방식에 의문을 제기하는 경우가 많습니다. “이 방법이 최선일까요?” 혹은 “다른 방법은 없을까요?”라고 묻습니다. 이때 조직이 이런 질문을 도전이나 피곤한 오지랖으로 받아들인다면, 그 조직에서 주도성은 점점 사라지게 됩니다.

정체된 조직: 시키는 대로 하세요. 위에서 다 이유가 있어서 그렇게 정한 겁니다.
성장하는 조직: 좋은 지적입니다. 그 대안을 실행했을 때 예상되는 리스크는 무엇인가요?

주도성을 발휘하다가도 일만 더 떠맡거나, 혹은 비난만 받는 경험이 반복되면 인재들은 학습된 무기력에 빠집니다. 결국 유능하고 주도적이던 사람들은 조직을 떠나고, 자리를 지키는 수동적인 인력만 남습니다. 주도성을 존중하지 않는 조직의 끝은 결국 시스템의 경직과 도태뿐입니다.

만약 지금 여러분이 속한 조직이 주도성을 오지랖으로 치부하며 억압하고 있다 해도 포기하지 마세요. 그곳에서의 주도적인 시도를 단순히 회사를 위한 헌신으로 여기기 보다, 자신의 이력서를 채울 ‘주도적 문제 해결 사례’를 모으는 과정으로 써볼 수 있습니다. 당장 환경을 바꾸지는 못해도 그 과정에서 쌓이는 시장 가치는 조직에 귀속되지 않는 온전한 나의 자산입니다.

2. 틀려도 괜찮고 몰라도 비난받지 않는다

주도적으로 행동하려면 ‘내 의견이 틀릴 수도 있다’는 부담을 이겨내야 합니다. 내가 던진 질문이 누군가에게는 당연한 상식일 수도 있고, 공들여 낸 아이디어가 보기 좋게 거절당할 수도 있습니다. 조직이 이때 해줄 수 있는 것은 거창한 제도가 아닙니다. “틀려도 괜찮고, 몰라도 비난받지 않는다”라는 아주 기본적인 약속입니다.

성공적인 협업이 이루어지는 팀의 공통점은 질문의 비용이 매우 낮다는 것입니다.

경직된 조직: 질문 하나를 던지기 위해 “내가 이걸 모른다고 하면 무시당하지 않을까?”를 백 번 고민해야 합니다. 실수라도 하면 “누가 이렇게 하라고 했어?”라는 비난이 돌아옵니다. 이런 환경에서 주도성은 사치입니다. 가만히 있으면 중간이라도 가는데, 굳이 나서서 욕 먹을 이유가 없으니까요.
유연한 조직: “이 부분이 이해되지 않는데 도와주실 수 있나요?” 혹은 “이 방법은 리스크가 크지만 시도해 볼 가치가 있을까요?”라는 말이 당연합니다. 여기서 주도성은 실패에 대한 두려움보다 문제를 더 잘 해결하고 싶다는 욕구를 따라 움직입니다.

주도적인 시도가 비난받지 않고, 오히려 “좋은 시도였다”는 피드백으로 돌아올 때 팀원들은 비로소 마음 놓고 경계를 넘나들기 시작합니다. 결국 주도성을 이끌어내는 것은 조직의 배려가 아니라 실수를 대하는 조직의 수준입니다.

3. 문화로 퍼지는 전염성

다행히 주도성은 전염됩니다. 정체된 팀에 주도적인 인재 한 명이 합류하면 초기에는 마찰이 생길 수도 있습니다. 그러나 그가 만들어 내는 예측 가능한 결과물과 명확한 소통은 동료들에게 새로운 자극이 됩니다.

“아, 저렇게 일하니까 일이 훨씬 깔끔하게 끝나는구나”, “저 사람과 협업하니 내 업무 효율도 올라가네”라는 경험이 쌓이면 팀 전체의 기준선이 자연스럽게 올라갑니다.

그래서 리더의 역할도 중요합니다. 단순히 채용 공고에 ‘주도적인 분’이라고 적는 것이 전부가 아닙니다. 주도적인 인재가 만들어 낸 작은 가능성을 혁신의 신호로 읽어 내고, 그들이 마음껏 선을 넘나들 수 있도록 심리적 가이드라인을 쳐줘야 합니다. 한 사람의 주도성이 팀 전체의 오너십으로 번질 때, 조직은 관리자의 지시 없이도 스스로 움직이기 시작합니다.

나를 위한 주도성을 기르기

이렇듯 ‘주도성’은 단순한 인성 평가의 기준이 아닙니다. 개인에게는 성장의 지름길이며, 팀에게는 효율적인 운영 시스템입니다. 물론 주도성을 오지랖으로 치부하는 환경에서 오너십을 유지하기는 쉽지 않습니다. 그러나 이런 환경일수록 주도적인 태도는 더욱 강력한 차별화 요소가 됩니다. 환경에 매몰되어 수동적으로 변하는 순간 멈춰 버리는 것은 조직의 성장이 아니라 바로 ‘나 자신의 시장 가치’이기 때문입니다.

정말로 중요한 사실은, 주도적인 태도로 가장 이득을 보는 것은 회사가 아니라 바로 자신이라는 점니다.

1. 주도성이 시장가치를 결정한다

채용 시장에서는 연차가 쌓일수록 연봉의 격차를 만드는 것이 기술의 개수에 달려 있지 않습니다. 그 기술을 활용해 ‘비즈니스 문제를 얼마나 주도적으로 해결했는가’라는 경험의 차이입니다.

수동적으로 5년을 일한 개발자와 주도적으로 3년을 고민한 개발자가 면접장에서 만났다고 가정해 보겠습니다. 수동적인 개발자는 “어떤 기술을 써봤나요?”라는 질문에 기술 스택의 목록을 읊조릴 겁니다. 반면 주도적인 개발자는 “그 기술을 왜 선택했고, 도입 과정에서 무슨 한계를 어떻게 극복했는지”까지 전체 과정을 함께 설명합니다.

기업은 단순히 코드를 생산하는 사람보다, 문제를 정의하고 해결책을 제시하는 문제 해결사에게 더 높은 값을 지불합니다. 주도성은 우리를 대체 불가능한 존재로 만드는 가장 확실한 개인 브랜딩 방법입니다.

2. 성장에는 주도성이 필요하다

많은 직장인이 “이 회사에서는 더 이상 성장할 수 없을 것 같다”며 매너리즘에 빠집니다. 하지만 냉정하게 말해 성장은 회사가 시켜 주는 것이 아닙니다. 성장은 내가 업무의 밀도를 높이고 고민의 깊이를 더할 때 자연스럽게 따라오는 결과에 가깝습니다.

내가 주도권을 잡고 일의 맥락을 파악하기 시작하면 같은 업무라도 완전히 다른 경험이 됩니다. 단순히 티켓을 처리하는 노동이 아니라, 시스템 구조를 이해하고 문제를 해결하는 진짜 공부가 되기 때문입니다. 결국 주도적인 태도는 회사를 위한 헌신이 아니라 내 실력을 키우는 가장 확실한 수단입니다.

3. 주도적인 사람이 되는 시작

처음부터 대단한 일을 할 필요는 없습니다. 사실 주도성은 아주 작은 접미사 하나를 바꾸는 것에서 시작됩니다. 동료나 상사의 요청에 무의식적으로 “그건 안 돼요”라는 말이 나오려 할 때, 잠깐 멈추고 뒤에 이 말을 붙여 보세요.

“...그런데, 어떻게 하면 되게 할 수 있을까요?”

“어떻게 하면 될까?”라는 질문은 단순한 긍정적 말버릇이 아닙니다. 이 질문을 던지는 순간, 당신의 시선은 내가 쓴 코드 한 줄에서 서비스 전체 흐름과 비즈니스 구조로 확장됩니다. 이 작은 질문을 반복하는 것만으로도 우리는 단순히 지시를 수행하는 부품에서, 어떤 문제든 해결하는 ‘대체 불가능한 전문가’로 성장할 수 있습니다.

]]>

PM은 이미 끝났다? 제품 관리의 현실

본문은 요즘 IT와 번역가 Yuna가 함께한 조 스마일리(Joe Smiley)의 글 <The Death of Product Management>를 번역한 글입니다. 필자는 25년 경력의 디자인 리더이자 다섯 차례의 창업 경험을 보유한 전략가입니다. Microsoft, Marriott 등 글로벌 기업에서 디자인 시스템과 조직을 이끌었으며, 디자인과 기술, 조직 운영에 대한 경험을 바탕으로 다양한 관점을 제시하고 있습니다.

이 글은 PM 역할이 왜 무너지는지를 조직 구조와 리더십 관점에서 살펴봅니다. 역할 모호성, 권한 없는 책임, 가짜 애자일 등 반복되는 문제를 짚으며, 많은 대기업에서 제품 관리가 이름만 남게 된 이유를 설명합니다. 동시에 제품 관리가 다시 제 역할을 하기 위해 조직이 바꿔야 할 지점도 함께 제시합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

PM이라는 역할은 최근 몇 년 사이 확실히 주목받기 시작했습니다. 많은 기업들이 애자일 방식을 도입했고, 더 빠르게 혁신하고 높아진 고객 기대에 맞춰가려는 움직임이 이어졌기 때문입니다. 기술 변화의 속도까지 빨라지면서 제품 관리는 점점 복잡해졌는데요. 그럴수록 오히려 그 중요성은 더 커졌습니다. 이제 제품 관리는 제품의 성패를 좌우하는 핵심 역할로 자리 잡고 있죠.

그렇다면 정말 제품 관리는 사라지고 있는 걸까요? 아니면 조직들이 따라가지 못하는 사이, 역할의 형태만 바뀌고 있는 걸까요?

본격적으로 이 이야기를 꺼내기 전에, 먼저 왜 제품 관리가 그토록 중요한 기능으로 여겨지는지부터 짚어볼 필요가 있습니다.

PM은 어떤 역할을 하는가

PM의 역할과 책임은 회사마다 다르게 정의됩니다. 그럼에도 본질은 크게 다르지 않습니다. 제품 관리란 결국, 제품의 방향을 잡고 개발부터 출시, 성장까지 전 과정을 전략적으로 이끄는 일이기 때문입니다.

PM은 비즈니스, 기술, UX·디자인이 맞닿는 지점에서 일합니다. 그리고 제품과 관련해 이런 질문들에 끊임없이 답해야 하죠.

우리 고객이 이 기능이나 제품을 실제로 원하고 있는가?
이걸 우리가 제대로 만들어낼 수 있는가?
지금 우리의 비즈니스 목표를 봤을 때, 만드는 게 맞는 선택인가?

PM 조직이 제대로 돌아가면 혁신은 방향을 잃지 않습니다. 비즈니스 전략과 사용자 니즈 사이의 균형을 유지하면서, 제품이 장기적으로 살아남을 수 있도록 버팁니다. 하지만 현실에서는 여러 구조적인 문제들이 PM을 조금씩 갉아먹고 있습니다.

PM을 가로막는 6가지 문제

제품 관리는 분명 전략적으로 중요한 기능입니다. 그런데도 많은 조직에서 PM은 본래 역할을 충분히 발휘하지 못하는 상황에 놓이고는 합니다. 여러 조직을 보면서 반복적으로 마주쳤던 문제들인데요. 이 역할의 뿌리를 흔드는 대표적인 사례들이기도 합니다. 물론 각각의 대응 방향도 존재합니다.

1. 역할이 흐릿한 조직

특히 애자일을 막 도입한 조직일수록 PM이 실제로 어떤 일을 해야 하는지 명확히 이해하지 못하는 경우가 많습니다. 그러다 보니 제품 방향을 이끌어야 할 PM이 어느새 일정 관리나 진행 상황 보고에 집중하는 프로젝트 매니저처럼 쓰이기도 하죠.

이렇게 되면 PM 본래의 가치는 조금씩 희석됩니다. 결국 제품 전략은 흩어지고, 팀 간의 방향성도 조금씩 어긋나게 됩니다.

어떻게 해결할까

조직 차원에서 PM이 어떤 역할인지 명확하게 정의해야 합니다. 특히 프로젝트 매니저나 비즈니스 애널리스트와 무엇이 다른지 선을 그어야 하죠. 리더십은 PM이 제품 관련 결정을 실질적으로 이끌 수 있는 권한을 갖도록 보장하면서, 동시에 여러 팀과 원활히 협업할 수 있는 환경을 만들어줘야 합니다.

2. 너무 많은 역할을 떠넘기는 구조

PM이 자주 겪는 또 다른 문제는 역할 과부하입니다. 리소스 제약을 겪는 조직, 특히 규모가 큰 곳일수록 이런 현상이 두드러지는데요. PM에게 스크럼 마스터나 PO 역할까지 함께 맡기는 경우가 적지 않습니다. 단기적으로는 버틸 수도 있습니다. 다른 역할을 채용하는 동안 몇 번의 스프린트 정도는 병행할 수 있겠죠. 하지만 이 상태가 길어지면 문제가 깊어집니다.

여러 역할을 동시에 떠맡은 PM은 결국 번아웃이 옵니다. 고객 문제와 비즈니스 과제를 깊이 고민해야 할 리더가 사라진 자리에서, 팀 전체의 집중력과 방향성도 함께 흔들리게 됩니다.

어떻게 해결할까

PM이 자신의 본래 역할에 온전히 집중할 수 있도록 조직을 설계해야 합니다. PM의 주의를 분산시키는 요소를 줄이는 것, 이것이 결국 PM이 만들어낼 수 있는 가치와 성과를 끌어올리는 가장 현실적인 방법입니다.

3. 책임은 산만큼, 권한은 손톱만큼

많은 조직에서 PM은 제품 성공에 대한 막중한 책임을 지면서도, 정작 중요한 결정을 내릴 권한은 충분히 갖지 못하는 경우가 많습니다. 매트릭스 구조의 조직에서는 더욱 그렇습니다. 여러 기능 조직의 구성원들이 서로 다른 리더에게 보고하는 환경에서는, 이 모순이 훨씬 선명하게 드러나죠.

실제로 경영진이 데이터가 아닌 단편적인 인상이나 직감을 근거로 우선순위를 뒤집거나, 특정 이벤트나 대형 출시를 앞두고 세부 실행까지 직접 챙기려 드는 경우가 있죠. 팀을 돕겠다는 의도일 수 있지만, 결과적으로는 의사결정 구조를 흔들고 PM의 설 자리를 좁히는 방향으로 작용합니다.

속도를 높이겠다며 검증되지 않은 인력을 팀에 갑자기 추가하는 경우도 있습니다. 애자일 경험이 부족하거나 제품과 사용자에 대한 이해가 얕은 사람이 합류하면, PM 입장에서는 오히려 이들을 팀에 녹여내는 데 더 많은 에너지를 써야 합니다. 마이크로매니징이 반복될수록 팀의 사기는 떨어지고, PM 스스로도 판단하고 방향을 잡기보다 리더십의 눈치를 보는 데 익숙해집니다.

어떻게 해결할까

PM이 제품 팀 안에서 충분한 결정권을 가질 수 있어야 합니다. 리더십은 PM이 팀을 이끌고 방향을 잡는 역할을 신뢰해야 하고, 즉흥적인 지시나 과도한 개입으로 그 역할을 흔들어서는 안 됩니다. 리더는 지금 팀이 하는 일에 깊이 끼어들기보다, 최소 한 분기 앞을 내다보는 비즈니스 전략과 제품 방향을 준비하는 데 더 많은 시간을 쓰는 것이 바람직합니다.

4. 경영진이 애자일을 껍데기로만 받아들일 때

애자일 전환을 거치고도 여전히 예전 방식대로 생각하는 경영진을 자주 마주칩니다. 제품 전략 없이 결정을 내리고, 경직된 프로젝트 계획을 고집하고요.사용자 리서치 없이 우선순위를 일방적으로 정하거나, 스프린트 도중 갑자기 방향을 틀어버리는 일도 반복됩니다.

이런 환경에서는 이름만 애자일인, 이른바 '가짜 애자일' 이 자라납니다.

경영진이 애자일을 단순한 체크리스트 정도로 받아들이는 경우가 많습니다. 방법론은 도입하되, 그 안에 담긴 문화적 변화는 외면하는 거죠. 그 결과 협업과 유연함이라는 애자일의 본질은 사라지고, 형식만 남은 껍데기 애자일이 자리를 잡습니다.

이렇게 되면 PM과 팀원들의 피로와 불만은 쌓여가고, 애자일이 줄 수 있는 진짜 가치는 끝내 손에 닿지 못합니다.

어떻게 해결할까

가짜 애자일의 가장 큰 문제는 가치관의 불일치에서 시작됩니다. PM과 애자일 코치가 이 간극을 줄이기 위해 보다 적극적으로 나서야 합니다.

경영진을 대상으로 리더십 중심의 애자일 교육을 제공해야 합니다. 제품 팀이 자율성과 신뢰를 바탕으로 스스로 좋은 결정을 내릴 수 있다는 것, 그리고 그것이 비즈니스 목표와 어떻게 연결되는지를 이해시켜야 합니다.
경영진이 제품 팀 및 고객 피드백과 지속적으로 접점을 가질 수 있도록 유도해야 합니다.
조금씩 고쳐가며 만드는 방식이 실제로 더 나은 결과로 이어진다는 점을 데이터로 직접 보여주는 노력도 필요합니다.

5. 기술 스펙에 집착할 때 놓치는 것들

많은 조직에서 아직도 PM은 기술적으로 뛰어나야 한다는 인식이 강합니다. 물론 산업이나 환경에 따라 기술 이해도가 중요한 경우도 있습니다. 하지만 기술 역량만 지나치게 강조하다 보면, 훌륭한 제품을 만드는 데 정작 필요한 것들이 뒷전으로 밀립니다. 창의성, 비즈니스 감각, 사용자 리서치가 바로 그것들입니다.

물론 PM이 기술을 전혀 몰라도 된다는 뜻은 아닙니다. 회사나 산업에 따라서는 기술에 능한 PM이 성공의 핵심이 되기도 하는데요, 특히 복잡한 엔지니어링 문제를 다뤄야 하는 환경에서는 더욱 그렇습니다.

어떻게 해결할까

제품의 성격에 맞게 PM에게 필요한 역량을 다르게 정의하는 것입니다. 모든 PM을 하나의 틀에 끼워 맞추기보다, 제품마다 요구되는 것이 다르다는 걸 조직이 먼저 인정해야 합니다.

어떤 제품은 깊은 기술 이해도가 필수적입니다. (예: AI, 클라우드 인프라 등)
반대로 다른 제품은 UX 감각, 창의성, 시장 이해도가 더 강력한 무기가 됩니다. (예: 소비자 서비스, 미디어 플랫폼 등)
어떤 제품이든, 사용자 리서치·전략적 사고·비즈니스 인사이트를 아우르는 균형 잡힌 역량이 장기적인 성패를 가릅니다.

6. 다른 조직이 제품 방향을 좌우할 때

이상적인 구조에서 PM은 고객 니즈, 비즈니스 목표, 시장 맥락을 기반으로 제품 로드맵을 이끌어야 합니다. 하지만 일부 조직에서는 세일즈, 마케팅 등 다른 이해관계자들이 핵심 제품 의사결정을 사실상 주도하는 상황이 발생합니다. 문제는 이런 결정들이 충분한 사용자 리서치나 전략적 판단 없이 이루어지는 경우가 많다는 점입니다.

이렇게 되면 우선순위 충돌은 자연스럽게 나타납니다. 단기적인 매출 목표가 제품의 장기적인 방향성을 압도하거나, 사용자 가치보다는 기술적 제약이 로드맵을 좌우하는 구조가 만들어지기도 합니다.

어떻게 해결할까

제품에 대한 전략적 리더로서 PM의 역할을 조직이 확실하게 뒷받침하는 것입니다.

직무 간 협업은 장려하되, PM의 오너십이 침해받지 않는 환경이 함께 갖춰져야 합니다.
주요 제품 결정은 반드시 고객 데이터, 사용성 검증, 비즈니스 전략을 토대로 이루어져야 합니다.
고객 가치와 충돌하는 결정에 대해서는 PM이 근거를 갖고 이견을 낼 수 있는 권한과 분위기가 보장되어야 합니다.

그래서 제품 관리는 이미 끝난 걸까요?

안타깝지만, 솔직히 말하면 그렇습니다. 많은 대기업에서 제품 관리는 이미 오래전에 사실상 죽었습니다.

그 원인은 복잡하지 않습니다. 앞에서 짚은 문제들을 리더십이 제때 알아채지 못했거나, 알면서도 외면했기 때문입니다. 더 씁쓸한 건, 상당수 조직이 애초에 문제 자체를 감지하지 못하고 있다는 점입니다.

오랜 시간 쌓아온 고객 기반과 브랜드 충성도가 방파제 역할을 해줬기 때문입니다. 제품 완성도가 다소 떨어져도 고객이 계속 돌아오는 구조가 만들어진 거죠. 하지만 긍정적인 움직임도 분명히 있습니다. 많은 스타트업들은 제품 관리를 훨씬 건강하게 받아들이고 있습니다. 애자일, 린 방법론과 함께 제품 중심의 사고방식을 실제로 살아내고 있죠. 이런 조직들이 지금 기술 산업 전반의 혁신을 가장 많이 만들어내고 있습니다.

마치며

대기업의 제품 리더들에게 꼭 하고 싶은 말이 있습니다. 지금이 바로 제품을 만드는 방식을 다시 들여다봐야 할 시점입니다. PM을 조직의 변두리로 밀어내는 선택은 단순히 인재를 낭비하는 문제가 아닙니다. 혁신의 싹을 자르고, 제품을 그저 그런 수준에 머물게 만드는 일입니다.

대규모 조직에서 제품 관리가 다시 살아나려면 아래 조건들이 필요합니다.

PM의 역할을 명확히 정의하고, 프로젝트·프로그램 관리와 선을 긋는다.
PM이 본래 역할에 집중할 수 있도록 보장해야 하며, 역할 분산은 최소화한다.
팀을 제대로 이끌 수 있는 실질적인 결정권을 준다.
경영진의 사고방식을 애자일에 맞게 바꿔나가야 합니다.
제품 특성에 맞게 기술·창의성·비즈니스 역량의 균형을 고려한다.
제품 전략의 중심에는 언제나 PM이 있어야 한다.

이 조건들이 갖춰질 때, 제품 관리는 다시 혁신과 성과를 이끄는 기능으로 작동할 수 있습니다. 개인적으로는 리더십에게 ‘20가지 제품 모델 원칙’을 자주 권합니다. PM 역할을 설계하고 발전시키는 데 유용한 기준점이 되기 때문입니다. 이를 제대로 이해하고 적용하는 조직은 단순히 생존하는 수준을 넘어, 더 나은 제품과 더 강한 고객 관계로 경쟁 우위를 확보하게 됩니다.

마지막으로, 현실의 제약 속에서 일하고 있는 PM들에게 전하고 싶은 메시지가 있습니다. 자신의 역할에 대한 명확성을 끊임없이 요구하세요. 전략적 제품 관리가 왜 중요한지 주변에 설명하고, 데이터를 근거로 결정에 영향력을 행사하세요.

개인적으로 저는 제품 관리의 미래가 스타트업에 있다고 믿습니다. 스타트업들은 이미 판을 뒤집고 있습니다. AI라는 무한한 가능성 위에서, 거침없는 PM들이 자율성을 무기로 자신만의 세계를 만들어가고 있죠.

제품 혁명은 이미 시작됐습니다. 지금 당신의 조직은 PM이 앞장설 수 있도록 힘을 실어주고 있나요, 아니면 조용히 무덤을 파고 있나요?

]]>

기획자가 직접 99개의 서비스를 만들며 배운 것들

기획자가 개발자 없이 직접 99개의 서비스를 만들며 배운 인사이트

기획안으로 설득하는 데 2주가 걸리고, 수십 번 임원 리뷰를 받았던 일이 동작하는 결과물을 보여주자 30분 만에 끝났다. AI 코딩 시대에 기획자의 무기는 문서가 아니라 실행이다. 지난 4개월간 99개의 서비스를 만들며 깨달은 '검증의 기술'을 공유하고자 한다.

나는 사실 코딩 공포증이 있었다. 학교 다닐 때 c언어 과목 학점은 늘 C였다. 코딩을 싫어하고 재미도 못 느꼈다. 학교 다닐 때 코딩 중간고사는 구구단을 짜봐라 이런 내용으로 어렴풋이 기억난다. 그럼 난 코드를 이해하는 대신 암기를 하며 또각또각 글자를 쓰곤 했다. 그렇지만 언제나 학점은 c였고 나는 코딩과 정말 안 맞는 사람이라고 스스로를 단정했다.

그러던 세상이 천지개벽했다. 말만 하면 알아서 코딩을 해주는 시대로 접어들고 있다. 기획자인 나는 AI를 통해 바이브 코딩을 접하고 나니 내 생각들이 실현되는 과정이 너무 재미있다. 좋은 점은 점점 코딩 공포증이 사라지고 있다는 점이다. 나의 두려움 대상이 아니라 내 생각을 실현해 줄 또 다른 도구로서 코딩을 바라보는 중이다.

바이브 코딩 시작은 주로 제미나이 빌더로 시작한다. <출처: 작가>

이 변화가 업무에 적용된 건 4개월 전이었다. 작년 11월 회사 업무로 챗봇 서비스를 만들어야 했다. 이미 개발팀에서 작업을 다 마친 뒤 임원 보고를 했지만 가시성이 떨어지고 강조할 부분이 잘 안 보이는 문제가 있었다. 곧 이미 개발된 작업물을 다시 나에게 수정하라는 지시사항이 내려왔고 기획자로서 고민이 되었다. 그냥 이미지로 수정해서 보여주느니 동작되는 걸 직접 보여줘야겠다고 생각했다. 그래서 뚝딱뚝딱 바이브 코딩을 배우게 되었고 직접 수정해 가져갔다.

반응은 솔직히 좀 놀랬다. "이렇게 바꿔보는 게 어떨까요?"라는 말이나 문서보다 "이렇게 동작해요."라고 보여주니 설득의 시간이 획기적으로 단축되었다. 서로 다른 상상을 하며 소모되던 논쟁이 사라졌다. 눈앞의 결과물을 보며 이야기하니 "왜 진작 처음부터 기획자를 안 붙였냐. 역시."라는 말이 나왔다. 그 경험 이후 나는 아이디어가 떠오를 때마다 반복해서 실현했고 지난 1월 말까지 총 99개의 서비스를 배포했다.

물론 99개가 거창한 사업 아이템은 아니다. 90%는 하루 만에 버려진 '일회용 검증 도구'였고 나머지는 나와 동료의 시간을 아껴주는 '마이크로 서비스'였다. 하지만 이 과정에서 얻은 것은 명확하다. 의사결정 비용이 '0'에 수렴한다는 것이다. 단 한 사람의 개발자 없이 복잡한 코드는 AI에게 맡기고, 오직 문제 해결에만 집중해 본 99번의 실험 기록을 남긴다.

욕심을 줄이면 핵심이 보인다

바이브 코딩을 처음 접했을 때 가장 많이 빠졌던 함정이 '기능 과잉'이었다. 개발 비용이 들지 않으니 머릿속에 생각나는 모든 것들을 다 넣고 싶어졌다. 나의 야심작 드림보드가 대표적인 실패 사례다. 나는 AI에게 작업 지시서를 내리듯 아주 구체적인 프롬프트를 입력했다.

[실제 입력한 프롬프트]
Role: 너는 세계적인 수준의 UX/UI 디자이너이자 프런트엔드 개발자야.
Goal: 나의 꿈과 목표를 시각적으로 관리하는 '드림보드' 웹서비스를 만들어줘.
Design Style: 노션처럼 깔끔하고 여백이 세련된 느낌. 딱딱한 표 대신 핀터레스트처럼 벽돌 쌓기 형태의 'Masonry Layout'을 사용해 줘.
Core Features: 우측 하단 '+' 플로팅 버튼으로 빠른 추가. 진행률이 100%가 되면 'Framer Motion'을 활용해 축하 폭죽 효과를 터뜨려줘. (이게 핵심이야, 도파민 트리거가 필요해!)
Tech Stack: React, Tailwind CSS, Supabase

<출처: 작가>

결과는 놀라웠다. 엔터를 누르고 얼마 지나지 않아 내 머릿속의 막연한 드림보드가 모니터 위에 짜잔하고 나타났다. 미니멀한 드림보드라니. 폭죽이 터지는 애니메이션까지 구현되었다. 문제는 그다음이었다. "어? 이걸 매일 쓰도록 하려면.... 감사 일기 같은 것도 넣어볼까?" 나는 즉시 감사 일기 탭을 추가하고 기능을 덧붙였다. 서비스는 금방 누더기가 되었다. 미니멀은 온데간데 사라지고 정보 구조는 꼬여버렸다. 무엇보다 서비스의 정체성이 흐려졌다. 화면을 보면서 느낀 점은 코딩 비용이 0이라고 해서 사용자가 겪어야 할 복잡함의 비용까지 0이 되는 건 아니구나라는 점이었다.

그 이후 방식을 아예 바꿨다. 아이디어가 생기면 기능을 덧붙이는 대신 새 서비스를 만드는 방향을 택했다. 그게 99개 다작의 비결이자 실패를 최소 비용으로 소화하는 방식이 되었다. 이후 바이브 코딩으로 만든 서비스는 '육아 검진 알리미'였다. 동료와 대화하며 우연히 포착한 불편함이었다.

<출처: 작가, https://mysuksuk.com/>

"또 놓쳤어요. 일일이 육아 건강검진 챙기기 너무 힘들지 않아요?"

엄마 기획자로서의 공감이 시작이었다. 육아 건강검진 서비스는 간단했다. 아기의 생년월일을 입력하면 자동으로 건강검진 날짜를 계산해 주는 것이다. 1차부터 9차 건강검진까지 자동으로 계산되면서 각 차수에 맞춰, 발달 정도를 스스로 체크할 수 있는 서비스였다. 욕심을 부리지 않고 딱 필요한 기능만 프롬프트로 입력하니 1시간도 안 돼서 서비스가 뚝딱 만들어졌다. 내친김에 배포까지 해서 남편에게 공유했다.

기존 프로세스였다면 기획안 쓰고, 디자인하고, 개발 일정 잡느라 며칠이 걸렸을 일이다. 하지만 '구현의 비용'이 0에 수렴하자 나는 '기능의 화려함'보다 '고객(나와 동료)의 결핍'을 해결하는 데에만 온전히 집중할 수 있었다. 실패해도 1시간만 버리면 된다는 가벼움이 오히려 실행력을 극대화했다.

기술이 막힐 때, 기획자는 '우회로'를 뚫는다

남편이 배포한 서비스를 이용하면서 '공유' 기능이 있으면 좋겠다는 피드백을 줬다. 내친김에 카카오톡 연동을 해보려고 했다. 하지만 외부 서비스 연동부터 쉽지 않았다. 카카오톡 연동을 위해서는 API 키를 받아야 하는데, 일단 키를 아무리 발급받아도 연동 테스트는 계속 오류가 발생했다. 비개발자인 내가 해결하기엔 기술적 장벽이 높았다. 복잡한 DB 설계나 대규모 트래픽 처리와 같은 기능 역시 바이브 코딩으로 한계가 있었다.

여기서 기획자의 판단이 중요했다. 이 서비스의 목적을 다시 한번 생각해 보았다. 남편이 원한 건 '카카오톡' 자체가 아니라 '알림을 받는 것'이었다. 나는 과감히 카카오톡을 포기하고 이메일 알림으로 우회했다.

전문 개발자였다면 어떻게든 API 키를 연동해 기술적인 문제점을 찾아냈을 것이다. 그건 개발자만이 할 수 있는 전문적인 능력이다. 하지만 비개발자인 나는 그럴 능력이 부족했다. 대신 '목적'을 다시 생각했다. 남편에게 중요한 건 '카카오톡'이 아니라 '알림' 그 자체였으니까. 나는 빠르게 기술적 씨름을 멈추고 구현이 쉬운 이메일 알림으로 경로를 틀었다. 이것이 내가 깨달은 AI 시대의 기획력이다. 코딩 실력이 부족했기에 역설적으로 기술에 매몰되지 않을 수 있었다. 기술적 장벽 앞에서 '어떻게 뚫을까'를 고민하는 대신, '이게 정말 필요한가?'를 질문하며 문제 자체를 재정의했기 때문이다. '카카오톡'이라는 도구에 얽매이지 않고 목적을 향한 가장 빠른 우회로를 찾아내는 감각이 점점 내가 키워야 할 무기이지 않을까라는 생각을 해보았다.

만드는 것은 쉽다, '누가 쓰는가'가 진짜 문제다

<출처: 작가, https://mysuksuk.info/>

바이브 코딩은 빠르게 테스트하기 위한 용도로 활용하면 매우 좋다. 나는 최근에 습관 트래커를 구현했다. 어렸을 때 잘하면 칭찬 스티커를 받아서 유지하듯 나 스스로 어떤 일을 하면 스티커를 모아가는 프로젝트로 기획했다. 바이브 코딩으로 서비스 배포까지는 수월했다.

무엇보다 나에게 매우 유용한 서비스였다. 회사에서 하는 대부분의 서비스가 최종 고객의 반응까지 알아보기가 어려운 구조였다. 하지만 바이브 코딩으로 만든 서비스들은 그냥 내가 만들고 배포하면 끝이라서 반응도 빨랐다. 문제는 서비스 자체는 적어도 나에게만큼은 유용했지만, 문제는 나만 쓰는 게 문제였다. 즉 알릴 길이 없었다. 내가 지인에게 배포해도 한계가 있었다.

나는 다시 기획을 수정했다. 단순히 습관을 기록하는 게 아니라 '글 쓰는 사람을 위한 습관 트래커'로 타깃을 좁히고 기능을 변경했다. 글 쓰는 사람에게 필요한 건 체크박스가 아니라 한 줄을 쓰게 만드는 동료 같은 반응이라고 봤다. 그래서 AI에게 페르소나를 부여했다.

[변경 프롬프트]
타깃은 글감이 안 떠올라 괴로운 작가야. 사용자가 한 줄을 쓰고 저장을 누르면 너는 그 문맥을 읽고 동기부여를 해줘. 때로는 진지하게 때로는 아재 개그를 섞어서 웃게 만들어줘.

그 순간 서비스가 달라졌다. 단순한 텍스트 생성기가 아니라 썰렁한 농담으로 긴장을 풀어주는 '동료'가 생긴 것이다. 습관 생성기에 대한 기능은 AI가 만들지만, 서비스의 톤과 성격은 기획자가 잡아줘야 한다는 생각을 했다. 삭막한 습관 트래커에 '장난기 넘치는 페르소나'를 입히자, 비로소 코드는 단순한 프로그램을 넘어 사용자와 관계를 맺는 대상이 되었다. 사용자를 머물게 하는 건 뛰어난 기능이 아니라 바로 그 관계의 힘이었다.

실패 비용이 0이 될 때 얻을 수 있는 것

만약 내가 만든 여러 가지 서비스를 3개월 동안 거창하게 만들었다면? 아까워서라도 방향성을 우회하지 못했을 것이다. 하지만 바이브 코딩은 '실패 비용'을 확연히 낮춰주었다. 덕분에 나는 '만드는 방법'을 고민하는 대신, '누가 왜 써야 하는가'라는 기획의 본질적인 질문에 더 깊이 파고들게 되었다.

질문의 무게를 견디는 기획자 99개의 서비스를 만들며 배운 것은 코딩 기술이 아니었다. 기술 장벽이 사라진 시대, 기획자가 집중해야 할 것은 '구현 가능성'이 아니라 '해결해야 할 문제의 정의'라는 점이다. 문서로 설득하는 대신 결과물로 증명하고, 거창한 계획 대신 빠른 실패를 통해 정답을 찾아가는 과정. AI 시대의 기획자는 책상 위가 아니라, 동작하는 서비스 위에서 답을 찾아야 한다. 우리가 던지는 질문의 깊이가 곧 서비스의 깊이가 될 테니까.

C언어 중간고사 시험을 볼 때면 하얀 종이 한편에 코드 대신 편지를 썼다. '공부를 소홀히 해서 죄송합니다 교수님...'이라며 멘트를 썼던 기억이 난다. C언어 학점이 C가 되어 집으로 돌아오면 아빠는 나를 불러 "장학생은 기대도 안 하는데 C는 너무하지 않냐?"라며 하셨던 말씀도 생각난다. 내가 그 시기 힘든 점은 단순히 C 학점이 아니라, 동기들은 재미있는 뭔가를 다 구현하는데 나 혼자 아무것도 하지 못하는 무력감이었다.

세월이 흘러 바이브 코딩이 되면서 C언어를 못 하던 나도 뭔가를 실현할 수 있게 되었다. 그것도 마음껏 원하는 대로 실현할 수 있다는 감각이 생겼다. 누군가는 묻는다. AI가 코드도 짜고 아이디어도 내는데, 이제 기획자는 필요 없는 거 아니냐고. 냉소적인 질문 앞에서 나는 99번 바이브 코딩을 통해 서비스를 구현한 경험을 담아 단호하게 '아니요'라고 답하고 싶다.

AI는 효율적인 코드를 짤 수는 있어도 카카오톡 연동을 과감히 빼거나, 아재개그 같은 피드백을 넣어 서비스의 온도를 조정하는 결정을 하진 못했을 거다. 기술적 논리로는 설명되지 않는 판단과 온기는 여전히 기획자만이 불어넣을 수 있는 영혼이다.

모든 것이 빠르고 실현 가능한 시대다. 마음껏 실현하는 시대일수록 흔들리지 않는 중심을 가진 기획자가 더 특별해진다. 기술의 파도에 휩쓸리지 않고 깊은 생각으로 서비스의 가장 중요한 핵심을 끝까지 밀어붙이는 힘이 중요해진다. 나는 여전히 흔들리지 않는 기획자가 되기 위해 답을 찾아 나가는 중이다. 이때 무기는 코드 몇 줄이 아니라 생각의 깊이면 좋겠다. 그 무기를 갈고 닦는 나의 여정은 99개의 서비스를 지나 이제 막 시작되었다.

]]>

IT 지식으로 지금 당장 “부업”을 시작하는 3가지 방법

퇴근 후에도 코드 리뷰하고, 주말에도 새 도구 만져보는 IT 업계 사람들. IT 산업의 변화는 모든 일에 영향을 끼쳤고, 그 영향력은 점점 커지고 있습니다. 그런데 왜 앞서 얻은 그 지식으로 돈은 안 벌고 있을까요? 예전엔 부업이란, 본업을 하나 더 하는 노동집약 게임에 가까웠기 때문입니다. 시간도 체력도 두 배로 써야 하니 시작 자체가 부담이었죠.

지금은 판이 달라졌습니다. AI가 콘텐츠 초안을 잡아주고, 코드도 짜주고, 디자인 시안도 뽑아줍니다. 쉽게 말해, 혼자서도 작은 팀처럼 움직일 수 있는 시대입니다. 오래도록 쌓아온 IT 도메인 지식에 AI가 붙으면, 부업의 진입 장벽은 역대 최저가 됩니다.

그래서 요즘 막히는 지점은 실력이 아닐 때가 많습니다. 문제는 “내가 뭘 더 배워야 하지?”가 아니라, “이걸 어떤 형태로 팔지?”입니다. 같은 지식도 패키징(상품 형태), 유통(어디서 팔지), 가격(얼마를 받을지)에 따라 돈이 되기도 그냥 취미로 끝나기도 합니다.

이 글에서는 IT 지식을 수익으로 바꾸는 길을 크게 세 가지로 나눠 비교해 보려고 합니다. 각각 콘텐츠, 프리랜서, MVP입니다. 진입 난이도도 다르고 돈이 들어오는 구조도 다릅니다.

<출처: 작가, Gemini로 제작>

대 부업 시대를 선점해야 하는 이유

왜 지금이 부업에 진입하기 가장 좋은 때일까?

AI는 글 초안, 기획, 코드 작성과 리팩토링, 디자인 시안까지 돕습니다. 쉽게 말해, 예전엔 팀이 있어야 하던 일을 혼자서도 시작할 수 있습니다. 그래서 IT 지식 + AI 레버리지 조합은 지금이 가장 강합니다.

그리고 기술이 새로 퍼질 때는 의외로 실력보다 패키징이 더 중요합니다. 같은 지식이라도 어떤 형태로 파는지가 매출을 갈라놓습니다. 앱이든 글이든, 결국은 상품처럼 보이게 만들어야 합니다.

마지막으로 현실적인 이유도 있습니다. 내 자리가 언제까지 안전할지 장담하기 어렵습니다. 그래서 부업은 사치가 아니라 보험에 가깝습니다. 작은 수익이라도 내 힘으로 벌어본 경험을 남겨야 합니다. 그 경험이 다음 선택을 훨씬 가볍게 만듭니다. 혹은 AI를 써보고 싶어도 회사 일에서는 한계가 있는 사람에게도 부업은 좋은 선택지입니다. 대충 하는 사이드 프로젝트가 아닌 수익이 나는 프로젝트는 몰입도가 다르죠. 나를 위한 프로젝트로 실력을 쌓는 게 안전합니다.

부업의 3가지 루트

IT 지식을 돈으로 바꾸는 길은 크게 세 가지입니다. 콘텐츠, 프리랜서, 제품(MVP/템플릿)입니다. 셋 다 장단점이 달라서 상황에 맞게 고르는 것이 좋습니다. 핵심은 나에게 맞는 시간 구조를 고르는 겁니다.

콘텐츠는 진입장벽이 가장 낮습니다. 이미 아는 걸 글이나 영상으로 정리하면 시작입니다. 비용도 거의 들지 않습니다. 대신 수익화까지 시간이 걸립니다. 결국 신뢰 자산(사람들이 믿고 찾는 상태)을 쌓아야 하기 때문입니다.

프리랜서는 진입장벽이 중간 즈음입니다. 대신 현금흐름이 빠릅니다. 일을 맡고 끝내면 바로 돈이 들어옵니다. 다만 구조적으로 시간을 계속 투입해야 합니다. 쉽게 말해 일한 만큼 버는 노동집약 모델입니다.

제품은 MVP나 템플릿처럼 한 번 만들고 반복 판매하는 방식이 효율적입니다. 처음부터 네이버나 카카오톡 같은 서비스를 만들라는 것이 아니고요. 물론 그럼에도 진입장벽은 가장 높습니다. 게다가 초반엔 아예 안 팔릴 가능성이 높으니 불확실합니다. 그래도 레버리지가 큽니다. 시간이 지나면 내가 자는 동안에도 매출이 날 수 있습니다.

상황별 추천하는 시작법

시간이 없고 리스크가 싫다면, 콘텐츠나 소형 프리랜서부터가 좋습니다. 오늘 밤 2시간으로도 시작할 수 있습니다. 뒤에 설명하겠지만, 특히 콘텐츠는 완성보다 발행이 중요하거든요. 프리랜서는 작은 작업부터 잡으면 부담이 줄어듭니다.

당장 월 몇십에서 몇백의 추가 수입이 목표라면 꽤나 본격적인 프리랜서를 고려해 보는 것이 좋습니다. 고객은 이미 필요가 있는 상태이기 때문입니다. 그래서 첫 수주만 넘기면 속도가 붙습니다. 단, 이를 위한 포트폴리오 관리와 시간 투입이 계속된다는 점은 감안해야 합니다.

장기적으로 내가 자는 동안도 팔리는 것이 목표라면 제품화로 가야 합니다. 여기서 제품은 거창한 서비스만 뜻하지 않습니다. 반복하던 귀찮은 작업을 자동화한 작은 도구도 됩니다. 중요한 건 한 번 만든 결과가 여러 번 팔리는 구조입니다. 이번 주에 MVP 한 조각이라도 배포해보면 방향이 잡힙니다.

방법 1: 지식을 ‘콘텐츠 자산’으로 바꾸어 파는 법

콘텐츠를 만들 때 가장 흔한 착각은 내가 아는 걸 보여줘야 한다는 생각입니다. 하지만 요즘 같은 시기 독자가 돈을 내는 지점은 지식이 아니라 문제 해결법입니다. 그래서 좋은 콘텐츠는 완벽하게 짜인 강의안이 아니라 내가 겪은 문제를 어떻게 풀었는지의 기록에 가깝습니다.

예를 들면 이런 형태가 바로 팔릴 준비가 된 소재입니다. “배포 자동화 삽질 기록”처럼 시행착오를 줄여주는 글, “레거시 리팩토링 체크리스트”처럼 그대로 따라 할 수 있는 문서, “신규 도구 도입 비교표”처럼 결정 시간을 줄여주는 자료가 그렇습니다. 요약하면 내가 똑똑해 보이는 콘텐츠가 아니라 남의 시간을 아껴주는 콘텐츠가 자산이 됩니다.

여기서 핵심은 완성도가 아니라 발행 루틴입니다. 운동으로 본다해도 초보자에게는 완벽한 PT 한 번보다 주 3회 루틴이 몸을 더 키워주죠. 콘텐츠도 마찬가지입니다. 한 편의 걸작보다 매주 쌓이는 기록이 나중에 쓸 콘텐츠 자산이 됩니다.

IT 부업을 시작하는 콘텐츠 플랫폼

난이도 순으로 유통 채널에 다가가기

처음부터 블로그 연재나 유튜브를 잡으면 부담이 커져서 멈추기 쉽습니다. 채널은 내가 만들 수 있는 난이도 순으로 올라가야 오래 갑니다. 반응이 빠르고 가벼운 곳에서 시작해 점점 신뢰가 쌓이는 곳으로 이동하는 방식이 좋습니다.

가장 쉬운 시작은 짧은 글입니다. LinkedIn이나 X에 오늘 해결한 문제 1개만 올려도 됩니다. 길게 쓰지 않아도 되고, 반응이 바로 와서 다음 소재를 잡기 쉽습니다.

다음 단계는 긴 글입니다. 블로그나 요즘IT와 같은 매거진 기고처럼 검색과 아카이빙이 되는 곳에 정리하면, 시간이 지날수록 신뢰가 누적됩니다. 짧은 글이 관심을 만든다면, 긴 글은 이 사람은 이 주제를 끝까지 설명할 수 있다는 신뢰 자산을 만듭니다.

게다가 요즘IT는 기고를 마치면 편당 고료도 지급합니다. 물론 복잡한 작가 심사를 거쳐야 하지만요. (AI로만 만든 콘텐츠는 통과하기 많이 어렵습니다) 지금 당장 도전해 보는 것도 방법 중 하나죠. [요즘IT 작가 신청]

마지막이 꽤 큰 비용을 만들 수 있는 영상/강의입니다. 인프런 강의는 신뢰를 결제로 바꾸기에 좋습니다. 조금 더 자유롭게 가려면 유튜브도 있고요. 글로 쌓아둔 주제 중 반응이 좋았던 것만 골라 강의로 묶으면 상품화 난이도도 확 내려갑니다.

AI로 ‘초안 생산성’을 올리되, 마지막은 사람이 책임지기

어쨌든 이런 콘텐츠 작업은 AI 없이 하기에는 너무 힘든 일입니다. 그래서 도구를 잘 고르는 것이 중요합니다. 사실 지금 시대에 개별 콘텐츠를 알아서 떠먹여주는 도구는 없습니다. AI는 콘텐츠의 첫 삽을 대신 떠주는 도구로 보는 것이 좋습니다.

그러니 추천하는 것은 범용 AI 도구입니다. ChatGPT나 Claude로 목차를 뽑고, 초안을 만들고, 예시 코드나 비유를 여러 버전으로 받아볼 수 있습니다. 제목도 A/B 후보를 몇 개 뽑아두면 발행 속도가 확 빨라집니다.

다만 사람이 해야 하는 핵심은 따로 있습니다. 본인 경험을 넣는 일입니다. 숫자, 실패, 트레이드오프(무엇을 얻고 무엇을 포기했는지) 같은 디테일은 AI가 대신 못합니다. 그리고 마지막으로 검증이 필요합니다. 실제로 동작하는지 확인하고, 정보가 최신인지 한 번 더 체크해야 신뢰가 무너지지 않습니다.

첫 달 목표는 ‘수익’이 아니라 ‘신뢰 지표’

초반에 조회수만 보면 흔들리기 쉽습니다. 대신 저장, 공유, “이거 더 물어봐도 될까요?” 같은 댓글과 DM을 보세요. 이 신호들이 쌓이면 나중에 강의·컨설팅·프리랜서로 연결되는 고리가 생깁니다.

첫 달에 잘 안 돼도 괜찮습니다. 아니, 안 될 가능성이 더 크다 해도 괜찮습니다. 그 과정 자체가 내 커리어의 기록이 되니까요. IT 지식으로 부업을 시작할 때, 결국 남겨야 하는 건 내가 어떤 문제를 풀어본 사람인지 알려주는 겁니다.

방법 2: 일단 수주부터 도전하는 프리랜서 시작하기

프리랜서 부업을 시작할 때, 가장 흔한 실수는 프로필에 “무엇이든 개발합니다”를 적는 겁니다. 듣기엔 든든하지만 구매자 입장에선 ‘그래서 내 문제가 어떻게 해결되지?’가 남습니다. 구매자는 기술이 아니라 결과물을 삽니다. 즉, 버튼을 누르게 만들려면 기술이 아니라 완성품을 먼저 보여줘야 합니다.

“무엇이든 개발합니다”로는 구매를 못 만든다

스킬을 그대로 나열하지 말고, 패키지(상품)로 번역해보세요. 예를 들면 “React 가능”이 아니라 “1주일 안에 랜딩페이지 제작”처럼요. “Python 가능”이 아니라 “반복 업무 자동화 세팅”이 더 잘 팔립니다. 구매자는 언어 이름보다 자기 일이 얼마나 편해지는지에 반응합니다.

패키지 아이디어는 의외로 단순합니다. 랜딩페이지 제작, 자동화 세팅, 데이터 분석 리포트, 간단한 봇/스크립트처럼 한 번에 이해되는 결과물로 묶으면 됩니다. 이렇게 적으면, 의뢰자는 견적을 상상할 수 있고 비교도 할 수 있습니다. 반대로 개발 전반은 범위가 끝없이 커 보여서 문의가 끊깁니다.

포트폴리오도 마찬가지입니다. GitHub 링크를 잔뜩 걸어두는 것보다, 문제/해결/기간/성과로 정리하는 편이 설득력이 큽니다. 예를 들어 “수작업 2시간을 10분으로 줄였다” 같은 시간 절감, “입력 오류가 줄었다” 같은 오류 감소로 보여주는 것이 좋습니다. 큰 프로젝트가 없어도 괜찮습니다. 작은 샘플 2~3개만 있어도, ‘이 사람은 끝까지 마무리하는구나’라는 신뢰가 생깁니다.

제대로 채널을 알고 접근해서 팔아보기

그 다음, 프리랜서 일을 어디서 구하냐는 거겠죠. 국내에서 일을 구하는 곳은 어느정도 정해져 있습니다. 위시켓, 크몽, 숨고죠. 그리고 이 채널마다 잘 팔리는 방식이 다릅니다.

프리랜서로 IT 업무를 수주하는 플랫폼들

위시켓은 보통 IT 프로젝트 단위 외주가 올라옵니다. 요구사항이 비교적 길고, 기간과 커뮤니케이션이 중요합니다. 그래서 여기서는 “제가 뭘 할 수 있어요”보다 “요구사항을 이렇게 정리하고, 이렇게 진행합니다”가 먹힙니다. 기업이나 도메인에 대한 이해, 개발 경험 등을 조금 더 전문적으로 어필해도 좋고요.

반면 크몽·숨고는 소규모 작업에 유리합니다. 의사결정이 빠르고, 지금 당장 문제를 해결하는 것이 목적일 때가 많습니다. 그래서 패키지형 상품이 특히 강합니다. 가격, 범위, 납기만 한눈에 보이면 문의가 들어올 가능성이 있습니다.

본업 병행을 전제로, 일단 시작하는 것이 중요

본업을 하면서 프리랜서를 하려면, 첫 단추는 얼마나 벌겠다는 야망을 가지는 것이 아니라 리스크를 관리하는 것입니다. 퇴근 후·주말에 할 수 있는 범위가 작은 건부터 잡아야 납기 사고가 줄어듭니다. 처음부터 큰 프로젝트를 받으면 일정이 밀리는 순간 본업도 부업도 같이 무너집니다. 작은 성공을 반복하는 쪽이 오래 갑니다.

한편 스트레스를 줄이는 좋은 방법은 의외로 문서 한 장에서 시작됩니다. 커뮤니케이션 템플릿을 미리 만들어두는 거죠. 예를 들면 요구사항 체크리스트, 수정 범위, 일정을 처음에 합의하는 겁니다. 이렇게 해두면 “생각해보니 이것도요”가 끝없이 늘어나는 상황을 줄일 수 있습니다. 부업의 지속력은 결국, 기술보다 커뮤니케이션에서 갈리거든요.

방법 3: ‘반복되는 귀찮음’을 MVP로 바꾸어 팔기

프리랜서 부업은 보통 시간당 과금 구조입니다. 일을 한 시간 더 하면 수익이 늘지만, 그만큼 내 시간이 줄어듭니다. 반면 제품은 한 번 만든 뒤 반복 판매나 구독으로 같은 결과물을 여러 번 팔 수 있습니다. 그래서 같은 IT 역량이라도, 제품 쪽이 레버리지가 더 크게 걸립니다.

무엇을 만들 것인가: 아이디어는 “내 업무의 반복”에서 나온다

아이디어를 멀리서 찾을 필요가 없습니다. 매주, 매일 반복해서 하는 일 중에 “이거 또 해야 해?” 싶은 순간이 있죠. 예를 들면 리포트 생성, 알림 보내기, 데이터 정리, 파일 변환, 티켓 분류 같은 것들입니다.

여기서 관점만 한 번 바꾸면 됩니다. “내가 귀찮아서 만든 제품과 자동화”는 그냥 개인용 편의 기능이 아니라 누군가에겐 기꺼이 돈을 내는 상품이 됩니다. 특히 같은 직무, 같은 업계 사람들은 비슷한 귀찮음을 공유하니까요. 그러니 “쓸모 있는가?”를 고민하기 전에, “내가 반복하는가?”부터 체크하면 됩니다.

제작 루트 2가지와 적당한 도구

제품화를 시도하기에 가장 좋은 도구들

첫 번째 루트는 바이브 코딩입니다. Claude Code, Cursor 같은 도구로 빠르게 MVP를 구현하는 방식이죠. 크롬 확장, 봇, 간단한 웹앱처럼 작게 만들수록 출시가 빨라집니다. 중요한 건 정답 코드를 짜는 게 아니라 일단 돌아가게 만드는 겁니다. 당연히 사람들이 이걸 쓰는지 확인하는 작업이 필요할 거고요.

두 번째 루트는 자동화의 제품화입니다. Make, n8n 등으로 워크플로우를 만들어 템플릿으로 파는 방식이죠. 처음엔 템플릿 판매로 시작하고, 수요가 보이면 “우리 회사에 맞게 세팅해 주세요” 같은 세팅 서비스로 확장할 수 있습니다. 즉, 제품과 프리랜서의 중간 형태로도 자연스럽게 이어집니다. 요즘은 AI 도구의 활용법이나 하네스(harness)를 AX란 이름으로 묶어 파는 것이 유행입니다.

MVP의 기준: 기능이 아니라 “처음부터 끝까지 돌아가는 경험”

MVP는 기능 목록이 아닙니다. 로그인, 결제까지 완벽하게 갖추는 게 목표가 아니라 문제 해결 1개를 처음부터 끝까지 제공하는 게 목표입니다. 예를 들어 “파일 변환을 자동으로 끝내준다”처럼 한 가지를 확실히 끝내면 됩니다.

그리고 이 작은 배포 경험이 다음 제품의 속도를 올립니다. 한 번 만들어 배포해 보면, 어디서 막히는지 몸으로 알게 되거든요. 이게 쌓이면 학습 곡선이 생기고, 다음 MVP는 훨씬 빨라집니다. 결국 제품 부업은 큰 한 방 대신 작은 출시의 반복으로 굴러갑니다.

어떻게 팔 것인가?

판매는 다시 콘텐츠로 돌아가서 시작해 보면 됩니다. 내가 만든 MVP가 어떤 문제를 해결했는지, 어떤 시행착오가 있었는지 정리하는 겁니다. 콘텐츠가 신뢰 자산과 반복이 핵심이라면, 제품은 한 번 뜨면 확 퍼질 수도 있습니다.

형식은 하나만 고르면 됩니다. 짧은 글이든, 긴 글이든, 영상이든 상관없습니다. 중요한 건 “내가 겪은 문제 → 만든 해결책 → 결과”를 남이 이해하게 정리하는 겁니다. 그 기록은 곧 같은 문제로 고민하고 있는 다른 사람에게 가닿을 확률이 가장 높고, 또 첫 고객을 데려오는 소개서가 되기도 합니다.

마치며

부업을 시작할 때 콘텐츠, 프리랜서, 제품에 우열은 없습니다. 결국은 내 IT 지식을 어떤 수익 구조로 바꿀지에 대한 선택지입니다. 시간이 없으면 콘텐츠가, 당장 현금 흐름이 필요하면 프리랜서가, 레버리지를 노리면 제품이 더 잘 맞을 수 있습니다. 중요한 건 나에게 맞는 방식을 고르는 일입니다.

사실 부업으로 가장 추천하는 거는 고민을 끝내고, 뭐라도 실행해 보는 겁니다. 완벽하게 하려다 멈추는 대신 작게라도 굴려보는 게 핵심입니다.

콘텐츠: SNS에 짧은 글 1편 발행하기(링크드인, X 등)
프리랜서: 위시켓/크몽/숨고 중 1곳에 프로필 만들고 포트폴리오/패키지 1개 등록하기
제품: Claude Code/Cursor로 MVP 기능 1개 구현하고 배포하거나 링크로 공유하기

어느 길이든 시작의 목표는 돈을 많이 버는 것이 아니라 처음부터 끝까지 한 번 돌아가게 만드는 것입니다. 당장 오늘부터 돈이 들어오는 부업을 찾는다면 아르바이트 자리가 더 빠를지도 모릅니다. 대신 이 부업 방식은 한 번 돌아가면, 나도 모르게 속도가 붙을 겁니다.

]]>

AI 없으면 결정 못 하는 리더십, 주도권은 어디로?

기술을 넘어 ‘신앙’이 되어버린 AI에 대하여

본문은 요즘IT와 번역가 Yuna가 함께 레안드로 구아르니에리(Leandro Guarnieri)의 글<In 2026, Forget Being AI-Driven and Do This Instead>를 번역한 글입니다. 필자는 아르헨티나 출신의 데이터 사이언티스트로, 수학 연구를 바탕으로 소프트웨어·금융·보험 산업에서 데이터와 AI를 활용한 문제 해결을 해왔습니다. 현재는 분석 조직을 이끌며 ML·AI를 실제 의사결정과 비즈니스 성과로 연결하는 데 집중하고 있습니다.

이 글은 ‘AI 중심’이라는 말 뒤에 가려진 책임 회피의 구조를 살펴보고, AI를 활용하되 의사결정의 주도권을 지키는 리더십이 왜 중요한지를 설명합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

미리 요점만 콕 집어보면?

AI 중심으로 일한다고 해서 어떤 문제가 풀 가치가 있는지를 더 잘 판단하게 되는 건 아닙니다.
결정을 AI에 맡길 때마다, 스스로 결정하는 능력은 조금씩 떨어집니다.
리더로서 당신의 역할은 AI에 이끌리는 게 아닙니다.

요즘 이야기를 들어보면 방향은 하나로 모입니다. AI를 중심에 두지 않으면 뒤처진다는 거죠. 링크드인을 조금만 훑어봐도 비슷한 말이 계속 반복됩니다. 전략은 AI가 이끌어야 하고, 알고리즘의 추천을 믿어야 하며, 의사결정 과정 전반에 AI를 녹여야 한다는 이야기들입니다. 미래는 결국 AI 기반 조직을 받아들이는 리더의 몫이라는 주장도 빠지지 않고요.

꽤 그럴듯합니다. 데이터에 근거한 합리적인 이야기처럼 들리고, 거스를 수 없는 흐름처럼 느껴지기도 하죠.

<출처:Alicia Christin Gerald (Unsplash)>

하지만 저는 지난 10년 동안 이 장면을 이미 여러 번 봐왔습니다. 처음에는 '데이터 중심 의사결정'이었습니다. 리더들은 숫자가 찍힌 대시보드 뒤로 물러나 결정을 미루기 시작했죠. 지금은 그 자리를 'AI'가 대신하고 있을 뿐입니다. 회피는 그대로인데, 표현만 더 세련돼졌습니다.

알고리즘은 새로운 형태의 스프레드시트일 뿐입니다. 판단을 하지 않기 위한 도구라는 본질은 달라지지 않았죠. 아무도 선뜻 말하지 않는 사실이 하나 있습니다. AI를 사용한다고 해서, 그 자체로 더 나은 의사결정을 하게 되지는 않는다는 점입니다.

같은 패턴은 반복됩니다

저는 더 나은 의사결정을 만든다는 이유로 대시보드와 모델, 분석 플랫폼을 직접 만들었습니다. 하지만 대부분의 경우 결과는 같았습니다. 리더들은 3분이면 내릴 수 있는 결정을 두고 데이터를 사흘 동안 분석하고 있었죠. 필요했던 건 제때의 판단이었는데, 대신 더 깊은 분석이나 3차 미분 같은 요구가 이어졌습니다.

데이터 기반 의사결정이라는 흐름은 결과적으로 꽤 편리한 역할을 했습니다. 똑똑해 보이면서도 책임을 분산시킬 수 있었으니까요. 일이 잘 풀리면 통찰력 있는 리더가 되고, 일이 잘못되면 데이터가 그렇게 말했을 뿐이었습니다. 그리고 AI는 이 구조를 더 강화했습니다.

방식은 단순합니다. 팀은 진행 중인 프로젝트를 두고 ChatGPT에 질문을 던집니다. AI의 답변을 캡처해 발표 자료에 넣습니다. 그 판단에 질문이 나오면, AI의 응답을 마치 절대적인 진리인 양 내세우죠.

<출처: Julia Potter (Unsplash)>

결정을 내린 건 AI가 아닙니다. 바로 여러분입니다.

무엇을 물을지 정한 건 여러분이었습니다
어떤 답을 믿을지 선택한 건 여러분이었습니다
그걸 어떻게 실행할지 결정한 것도 여러분이었습니다

다만 이제는 "AI의 추천을 따랐을 뿐"이라고 말할 수 있게 됐죠. 기술 스택을 동원한 회피입니다. 예전에 데이터 중심 의사결정이 그랬던 것처럼, AI 중심 의사결정 역시 책임의 위치를 바꿔 놓습니다.

이미 드러나고 있는 세 가지 역효과

많은 사람들은 AI 도입이 곧 진보라고 생각합니다. 하지만 모두가 'AI 혁신'을 축하하느라 바쁜 사이, 아무도 눈치채지 못한 실패 패턴 세 가지가 이미 나타나고 있습니다.

책임이 흐려집니다

결과가 좋으면 리더들은 "AI를 효과적으로 활용한" 덕분이라고 자랑합니다. 결과가 나쁘면 "AI가 추천한 거였다"고 하죠. 저는 사후 분석 자리에서 다 큰 어른들이 ChatGPT 탓을 하는 걸 봤습니다. 마치 총으로 위협받아서 어쩔 수 없었다는 식으로요. 책임을 알고리즘에 떠넘길 수는 없습니다. 하지만 그런 척은 할 수 있죠.

질문은 점점 엉뚱해집니다

AI는 무엇을 물어도 훌륭한 답을 내놓습니다. 하지만 지금 던지는 질문 자체가 잘못됐다고는 말해주지 않습니다. 저는 팀들이 중요하지도 않은 문제에 대한 AI 솔루션을 완벽하게 다듬느라 몇 주를 보내는 걸 봤습니다. 그 사이 진짜 급한 불은 타오르고 있었는데 말이죠. AI 중심으로 일한다고 해서 어떤 문제가 풀 가치가 있는지를 더 잘 판단하게 되는 건 아닙니다. 그저 우연히 던진 질문에 대한 답을 더 빠르게 얻을 뿐이죠.

의사결정 능력이 퇴화합니다

결정을 AI에 맡길 때마다, 스스로 결정하는 능력은 조금씩 떨어집니다. 판단력도 다른 기술과 똑같습니다. 쓰지 않으면 잃게 되죠. 예전엔 어려운 결정을 직접 내리던 고위 리더들이, 이제는 AI 없이는 얼어붙어 있는 모습을 보고 있습니다. 자기 생각을 믿는 법을 잊어버린 겁니다. 15년 넘게 내려오던 결정조차 알고리즘의 검증 없이는 확신하지 못합니다.

이게 바로 AI 의존의 실제 모습입니다.

그리고 우리는 더 똑똑해지는 게 아니라, 점점 더 멍청해지고 있습니다.

<출처: JESHOOTS.COM (Unsplash)>

결국은 의사결정 중심입니다

6개월 전, 우리 팀은 제품 관련 결정을 내려야 했습니다. 알려진 한계가 있더라도 새 기능을 빠르게 출시할 것인가, 아니면 '완벽한' 버전을 위해 3개월을 늦출 것인가. 전형적인 트레이드오프였죠. 합리적인 사람들도 의견이 갈릴 수 있는 문제였습니다.

AI 분석 결과는 '연기'였습니다. 지원 비용이 낮아지고, 사용자 경험이 개선되며, 장기 유지율이 높아진다는 거였죠. 모델은 정교했고, 논리는 탄탄했으며, 권장사항은 명확했습니다.

우리는 그래도 출시했습니다. AI는 제가 알고 있던 걸 몰랐습니다. 가장 큰 경쟁사가 곧 비슷한 기능을 발표할 예정이었고, 영업팀은 이 기능을 기다리느라 계약을 놓치고 있었으며, 우리의 기회는 점점 좁아지고 있었습니다. AI는 제가 입력한 변수들을 최적화했을 뿐입니다. 하지만 어떤 변수가 중요한지 결정하는 건 제 몫이었죠.

AI가 틀렸던 건 아닙니다. 주어진 맥락만으로는 올바른 답에 도달할 수 없었을 뿐이죠. AI는 최적화할 뿐입니다. 맥락을 파악하지는 못합니다. 당신이 말해주지 않은 건 알지 못합니다. 이사회에서 CEO의 미묘한 표정이라든가, 아직 명확히 표현할 수 없지만 감지되고 있는 고객 심리의 변화 같은 건 반영할 수 없습니다.

리더로서 당신의 역할은 AI에 이끌리는 게 아닙니다. AI를 올바른 질문으로 이끌고, 그것을 논의한 다음, 나온 답변을 어떻게 활용할지 직접 결정하는 겁니다.

의사결정 중심 리더십은 이렇게 작동합니다

의사결정 중심이라는 건 AI를 무시하겠다는 뜻이 아닙니다. 누가 주도권을 쥐고 있는지를 분명히 안다는 의미죠. 이렇게 생각해보면 이해가 쉽습니다. 당신은 의사결정의 CEO입니다. 데이터는 CFO이고, AI는 아주 빠르고 지치지 않는 분석가죠. 하지만 회사를 실제로 운영하는 사람은 여전히 당신입니다.

질문은 리더의 책임입니다

AI에게 질문하기 전에, 먼저 스스로에게 물어야 합니다. 지금 내가 분석하려는 게 뭔지가 아니라, 실제로 결정하려는 게 무엇인지 말이죠. 많은 사람들이 이 단계를 건너뜁니다. 어떤 결정을 내려야 하는지 정리도 안 된 상태에서 곧바로 "AI는 뭐라고 할까?"부터 묻죠.

그래서 저는 이렇게 적어보라고 말합니다. "[날짜]까지 [X]를 할지, [Y]를 할지 결정해야 한다." 이 문장을 끝까지 쓰지 못한다면, 아직 AI 의견을 들을 단계가 아닙니다. 그저 뭔가 생산적인 일을 하고 있다는 기분을 원하고 있을 뿐이죠.

AI는 판단을 대신하지 않습니다

결정이 명확해졌다면, 이제 AI를 활용할 차례입니다. 내 생각을 검증하는 데 쓰세요. 반대 입장을 최대한 강하게 주장해달라고 하고, 논리의 허점이나 놓친 변수를 찾아달라고 하세요. 여기서 핵심은 AI는 정답지가 아니라 스파링 파트너라는 것입니다.

저는 Claude에게 제 입장을 가능한 한 강하게 반박해달라고 합니다. 그다음엔 다시 찬성 논리를 최대한 잘 구성해달라고 요청하죠. 양쪽의 주장을 모두 최고 상태로 보고 싶기 때문입니다. 하지만 그 주장들을 실제 맥락에 맞게 저울질하는 건, AI가 아니라 제 역할입니다. AI는 제가 보고 있는 현실 전체에 접근할 수 없으니까요.

데이터는 패턴만 보여줍니다

데이터는 이미 일어난 일을 보여줍니다. 때로는 앞으로 일어날 가능성도 예측해 주죠. 하지만 무엇이 중요한지는 알려주지 않습니다. 기술적으로는 정확하지만, 전략적으로는 아무 의미 없는 지표에 집착하는 팀들을 많이 봤습니다. 그들은 분명 데이터 중심으로 일하고 있었죠. 동시에 모두의 시간을 낭비하고 있었습니다.

어떤 패턴이 중요하고, 어떤 패턴은 무시해도 되는지 결정하는 것은 리더의 역할입니다. 데이터가 대신해 줄 수 있는 일이 아니죠.

결과에 대한 책임은 리더에게 있습니다

결정을 내렸다면, 그 결과를 받아들이세요. 잘됐으면, 좋은 정보를 바탕으로 좋은 결정을 내린 겁니다. 잘 안됐으면, 결과가 기대에 못 미친 결정을 내린 거고요. 어느 쪽이든, 그건 당신의 선택이었습니다. "AI가 추천해서요"라는 말이 나오기 시작하는 순간, 리더십은 거기서 끝입니다. 그건 판단을 내리는 사람이 아니라, 비싼 연봉을 받으며 버튼을 누르는 사람일 뿐이죠.

<출처: Sean Benesh (Unsplash)>

진짜 차이는 여기서 납니다

성과를 내는 리더들이 꼭 AI를 가장 잘 아는 사람들은 아닙니다. 프롬프트를 가장 잘 쓰는 사람도 아니고, 가장 정교한 도구를 갖춘 사람도 아니죠. 이들의 공통점은 무엇이 중요한지에 대한 판단이 아주 명확하다는 점입니다.

이들은 AI를 적극적으로 활용합니다. 하지만 누가 누구를 위해 일하는지는 절대 헷갈리지 않습니다. AI는 의사결정을 돕는 도구이지, 의사결정을 대신하는 존재는 아니니까요. 반면, 많은 사람들은 전혀 다른 게임을 하고 있습니다. 겉으로 더 세련돼 보이도록, 프로세스가 그럴듯해 보이도록, 이사회에서 "AI를 활용했습니다"라고 말할 수 있도록 최적화하고 있죠.

그사이 더 나은 판단을 내리는 사람들에게 계속 밀리고 있습니다. 미래는 AI 중심 리더의 것이 아닙니다. AI에 의존하지 않으면서도, 필요할 때 제대로 활용할 줄 아는 의사결정 중심 리더의 것입니다.

어떤 리더가 될지는, 이제 선택의 문제입니다.

<원문>

In 2026, Forget Being AI-Driven and Do This Instead

]]>

개발자 6인, 비개발자 4인의 클로드 코드 실전 사례집

요즘 클로드 코드가 여기저기서 핫하게 떠오르고 있죠? 뭔가 이것저것 대단한 걸 할 수 있다는데요. 그런데 내 업무에는 어떻게 적용해야 하는 걸까요? 뭐부터 해야 하는 건지, 어떻게 해야 하는 건지 잘 모르겠습니다. 이것저것 테스트해보면 토큰은 순식간에 바닥나고, 어느 순간 그냥 내가 하는 게 낫겠다는 생각이 들죠.

요즘IT는 이런 고민에 답이 될 수 있는 이야기들을 모았습니다. 스타트업 기술이사, 풀스택 개발자, PM, 영상 제작사 기술이사, 출판 에디터까지. 클로드 코드를 실무에서 직접 쓰고 있는 개발자 6인과 비개발자 4인이 시행착오 끝에 정립한 실전 방법론을 한 권의 사례집으로 만들었습니다.

참고로 이들의 이야기는 완벽한 성공담보단 삽질하고, 실패하는 과정 속에서 배운점, 그렇게 자기만의 방식을 찾아간 과정에 가깝습니다. 사례집에 담긴 이야기 중 두 가지만 먼저 소개해 드리겠습니다.

사표를 던지고 싶었습니다 — 서비스 중단 위기를 3일 만에 돌파한 기록

콩콩프렌즈에서 백엔드를 담당하고 있는 김형중 님의 이야기입니다.

그는 원래 콩콩프렌즈의 프론트엔드 개발자였습니다. 그런데 사수이자 CTO였던 분이 개인 사정으로 퇴사하면서, 팀원 만장일치로 백엔드를 떠안게 되었죠. 그렇게 2년, 미숙하지만 어떻게든 살아남고 있던 어느 날 회사의 핵심 시스템이 의존하던 외부 실시간 투표 프로그램의 정책이 갑자기 바뀌었습니다. 임베딩이 제한되면서, 시스템이 통째로 먹통이 될 위기에 처한 겁니다.

하필 다음 주 주말에는 심포지엄 행사가 잡혀 있었는데요. 이 상황을 해결하지 못 하면 거래가 끊기고, 최악의 경우 손해배상까지 갈 수 있는 긴급한 상황이었죠. 해외 프로그램이라 문의를 넣어도 답이 언제 올지 알 수 없었고요. 주어진 시간은 딱 일주일. (이때 그는 정말 사표를 던지고 싶은 상황이었다고 합니다)

결국 그가 내린 결론은 차라리 새로 만들자는 거였습니다.

그렇게 그는 클로드 코드와 함께 사용자 시나리오 문서부터 작성하기 시작했습니다. 행사장에 몇 번 가본 경험이 있었기에, 참여자가 태블릿으로 투표하고 관리자가 투표를 생성·조작하는 흐름은 손에 익어 있었죠. 이 도메인 지식이 문서의 뼈대가 되었고, CLAUDE.md 파일로 프로젝트 맥락을 잡은 뒤 본격적인 개발에 들어갔습니다.

그런데 문서가 2,000줄을 넘기면서 문제가 생겼습니다. 클로드 코드가 문서를 읽는 데만 토큰을 잡아먹으니, 정작 코드 작성 속도는 눈에 띄게 느려진 겁니다. 이때 그가 찾은 해법이 꽤 인상적인데요. 너만 이해하면 돼, 라는 마인드로, 사람이 읽기 좋게 쓴 문서를 클로드가 읽기 좋은 형태로 다시 압축하기 시작한 겁니다. 이모티콘, 도표, 줄바꿈 같은 가독성 요소를 전부 걷어내고, AI가 파싱하기에 최적화된 구조로 재작성했습니다. 2,046줄이 359줄로 줄었고, 체감 속도는 확실히 빨라졌죠.

그리고 프론트엔드와 백엔드를 연결해야 하는 시점이 왔습니다. 모노레포이긴 했지만 코드가 분리되어 있어서, 한쪽 클로드 코드 세션에서 다른 쪽 코드를 직접 참조할 수가 없었거든요. 마음은 급한데 속도의 한계를 느끼던 그 순간, 김형중 님은 꽤 독특한 아이디어를 떠올립니다.

그래서 그는 이 위기를 결국 해결했을까요? 행사까지 남은 시간은 고작 3일. 그가 떠올린 아이디어가 뭐였는지, 정말 그걸로 행사를 무사히 치를 수 있었는지는 사례집에서 직접 확인해 보시죠.

사례집에서 확인할 수 있는 것들
2,046줄 → 359줄, 문서 압축 전후 실제 비교 이미지
압축하고 → 검수하고 → 수정하고 → 다시 압축하고... 반복 프로세스의 구체적 실행법
문서가 다시 커졌을 때 역할 기준으로 쪼개는 분할 전략
프론트 클로드와 백엔드 클로드가 서로 소통하게 만든 방법의 전체 과정
완성 후 팀원들과 진행한 테스트 현장, 그리고 회고에서 나온 배운 점들

8개월 100건, 2,400만원 — 비개발자가 외주 개발로 먹고사는 법

불혹의바이브코딩이라는 이름으로 활동하는 분의 이야기입니다. 설명을 조금 더 덧붙이자면 기계공학과를 졸업하고 건설회사에 다니고 있는, 개발 경험이 전혀 없었던 40대 직장인입니다.

그가 바이브 코딩을 시작한 건 순전히 호기심이었습니다. 바이브 코딩이 여기저기서 핫한 주제니까요. 그런데 곧 많은 비개발자가 겪는 패턴에 빠졌습니다. 처음엔 재미있었죠. 뭔가 만들어지는 게 신기하고, 이걸로 돈 벌어볼까 하는 기대감도 생깁니다. 그러다 벽을 만납니다. 프로그램이 갑자기 안 되고, 에러 메시지는 이해가 안 되고, 어렵게 만들어서 출시해봐도 아무도 사용해주지 않습니다. 결국 열정이 바닥나서 포기하게 되는 거죠.

그가 이 구간을 버틸 수 있었던 건, 외주 개발이라는 지속할 이유를 찾았기 때문이었습니다. 처음에는 자기 아이디어를 구현하는 재미로 시작하지만, 외주를 하면 다른 사람이 만들고 싶은 것을 대신 만들어주는 거라 아이디어가 고갈될 일이 없습니다. 게다가 돈이 되죠. 그는 이 마진이 가장 중요한 요소라고 말합니다. 직장인이 월급 몇십만 원 오르면 기분 좋듯이, 부업으로 5만 원, 10만 원이라도 벌면 그것만으로 다음 프로젝트를 할 힘이 생긴다는 거죠.

그의 외주 개발 전략은 명확했습니다. 메이저리그가 아니라 마이너리그에서 시작하는 것. 다양한 외주 플랫폼에서 자동화라는 자기 도메인 하나에만 집중했습니다. 건설회사에서 쌓은 업무 경험이 자동화 쪽 요구사항을 이해하는 데 자연스럽게 도움이 됐고요. 포트폴리오도 없이 상품 등록부터 시작했습니다. 단돈 만 원이라도 좋으니 한번 시작해 보자는 마음이었죠.

이후로는 프로젝트를 금액대별로 구분하면서 체계적으로 경험을 쌓아갔습니다. 5분이면 끝나는 단순 매크로(10만원 이하)부터, 웹 자동화나 OCR이 필요한 중간 난이도(10~50만원), 복잡한 솔루션(100만원 이상)까지.

그런데 비개발자가 100만원 이상의 금액대 개발 외주 작업을 정말 완료할 수 있었을까요? 그는 어떤 프로젝트들을 수행했고, 클로드 코드를 구체적으로 어떤 프로세스로 활용해서 비개발자로서의 한계를 넘었을까요? 8개월간 100건, 2,400만원이라는 숫자 뒤에 있는 현실적인 이야기는 사례집에서 확인해 보세요.

사례집에서 확인할 수 있는 것들
10만원 이하 / 10~50만원 / 100만원 이상, 금액대별 실제 프로젝트 사례와 난이도 비교
5분 만에 8만원을 번 매크로 프로젝트의 실제 내용
고객 요구사항이 횡설수설할 때, AI를 활용해 정리하는 구체적인 방법
코드를 모르는 사람이 결과물을 검증하는 3단계 프로세스
외주를 고를 때의 기준 — 돈이 되는 프로젝트와 스트레스만 남는 프로젝트를 가르는 것

이 두 이야기 외에도 8명의 실무자가 각자의 현장에서 부딪히고 배운 기록이 사례집에 담겨 있습니다.

어떤 내용들이 있는지 아래에서 소개해 드리겠습니다.

「클로드 코드로 일하기: 10인 실제 사례집」

요즘IT는 2025년 10월부터 12월까지, 총 3회에 걸쳐 온라인 웨비나 클코나잇을 진행했습니다. 개발 생산성 향상, AI 에이전트 오케스트레이션, 비개발자의 바이브 코딩까지. 매 회차마다 예상을 뛰어넘는 관심이 쏟아졌고, 발표 후 Q&A도 뜨거웠습니다. 이 사례집은 그 세 차례 발표의 기록입니다. 완벽하게 다듬어진 강의가 아니라, 현업에서 직접 부딪친 실무자들의 시행착오와 성공기를 가감 없이 담았습니다. 발표 후 쏟아진 Q&A도 함께 실어, 독자들이 가질 법한 질문에 미리 답하고자 했습니다.

- SDD로 AI가 80% 구현하게 만드는 구조_김효준 / 패러다임 시프트 기술이사
- 토큰 70% 절약하고 생산성 5배 올리는 MCP 세팅 가이드_승형수 / 개발자
- PM 혼자 63일, 2,900커밋으로 엔터프라이즈급 앱 만들기_이애본 / 한신대 AI SW 대학 겸임 교수

PART 2 실전 프로젝트 사례

- Plan 모드로 설계하고, Auto로 구현하기_조영록 / (주)대교 소프트웨어 엔지니어
- Tmux + LangGraph 멀티에이전트 오케스트레이션_노성현 / 와탭랩스 개발자
- 서비스 중단 위기, 3일 만에 막아낸 기록_김형중 / 콩콩프렌즈 개발자

PART 3 비개발자의 클로드 코드 활용법

- 비개발자의 외주 개발: 8개월 100건, 2,400만원_불혹의바이브코딩 / 종합 건설회사 근무
- 영상 제작사 기술이사의 바이브 코딩 6계명_우탄 / 영상제작사 '한줄' 기술이사
- 문과생 PM의 6,000라인 돌파기_정덕범 / 라인 플래닛 프로덕트 매니저
- 출판 에디터의 AI 실험실: 바이브 코딩 생존법_차진우 / 도서 기획·편집자

부록 — 바로 써먹을 수 있는 것들

CLAUDE.md 템플릿 가이드
MCP 추천 리스트 정리표
클로드 코드 요금제 비교 (2026.02 기준)
Claude Skills 활용법

167 페이지에 담긴 10명의 고군분투가 궁금하시다면, 사례집에서 직접 확인해 보세요.

클로드 코드로 일하기: 10인 실제 사례집 보러 가기

]]>

프로그래머로서 이렇게 뒤처진 느낌은 처음입니다

안드레 카파시(Andrej Karpathy)를 아시나요? 테슬라의 AI 디렉터였고, OpenAI 창립 멤버이며, 스탠퍼드에서 컴퓨터 비전으로 박사 학위를 받은 사람입니다. 트위터 팔로워만 100만 명이 넘는, 말 그대로 AI 분야의 최전선에 있는 인물이죠. 그런 그가 지난 12월, X에 이런 글을 남겼습니다.

Andrej Karpathy, X

"프로그래머로서 이렇게 뒤처진 느낌은 처음이다."

AI를 만드는 사람이, 그것도 세계 최고 수준의 개발자가 "뒤처진다"고 말한다니요. 그는 계속 이렇게 말했습니다.

"지난 1년간 등장한 도구들을 제대로 엮기만 해도 생산성이 10배 가까이 증가할 수 있는데, 이를 활용하지 못하는 건 명백한 역량 부족이다."

에이전트, 서브에이전트, 프롬프트, 컨텍스트, 메모리, MCP, LSP, IDE 연동... 새로운 추상화 계층이 쏟아지고 있고, 설명서 없는 강력하지만 확률적이고 불완전한 도구들이 갑자기 기존 엔지니어링과 뒤섞였다고 합니다. 그의 표현대로 "규모 9의 지진이 개발 산업 전체를 뒤흔들고 있다"는 거죠.

저는 이 글을 읽고 멘탈이 붕괴되었습니다. 카파시 같은 사람도 뒤처진다면, 그저 평범한 개발자인 저는 어떻게 해야 할까요? 그리고 우리는 어떻게 해야 할까요?

미리 요점만 콕 집어보면?

테슬라 AI 디렉터 안드레 카파시조차 "프로그래머로서 이렇게 뒤처진 느낌은 처음"이라고 고백할 만큼, AI 도구의 발전 속도가 개발 산업 전체를 뒤흔들고 있다.
개발자의 역할이 '코드 작성자'에서 '여러 AI 에이전트를 조율하는 지휘자'로 바뀌고 있으며, 프롬프트 설계와 결과물 검증 능력이 핵심 역량이 되었다.
ChatGPT, Claude, Cursor 등 AI 도구를 제대로 조합하면 생산성이 10배 이상 증가할 수 있고, 4주 실전 로드맵으로 누구나 시작할 수 있다.

도대체 무엇이 바뀌었나?

제가 개발을 시작했을 때는 개발자에 역할이 명확했습니다. 좋은 개발자란 알고리즘을 잘 짜고, 클린 코드를 작성하며, 디자인 패턴을 적절히 활용하는 사람이었습니다. 코드를 얼마나 '잘' 작성하느냐가 핵심이었죠. 그런데 지금은 다릅니다. 카파시의 표현처럼 "프로그래머가 직접 작성하는 코드 비중은 점점 줄어들고 있다"는 게 현실입니다. 실제로 요즘 제 작업을 돌이켜보면, 순수하게 제가 타이핑한 코드는 전체의 20%도 안 됩니다.

지난주 프로젝트를 예로 들어볼게요. 새로운 API 엔드포인트를 만들어야 했는데, 코딩은 Cursor가 작업하였습니다. 저는 비즈니스 로직만 수정했습니다. 테스트 코드는 Claude에게 시킨 후 제가 검토했고요. 배포 스크립트는 ChatGPT가 작성한 걸 약간 수정했습니다. 제가 실제로 '작성'한 코드는 핵심 비즈니스 로직 50줄 정도였습니다. 나머지는 AI가 제안한 걸 반영한 것 입니다. 이게 2026년 개발자들의 현실입니다.

하지만 진짜 변화는 따로 있습니다. 바로 카파시가 언급한 "새로운 추상화 계층"의 등장입니다. 과거에 개발자가 다뤄야 할 추상화는 비교적 명확했습니다. 하드웨어 위에 운영체제, 그 위에 프로그래밍 언어, 프레임워크, 라이브러리... 예측 가능한 수준입니다. 지금은 에이전트, MCP, 프롬프트 같은 것들이 기존 스택 위에 얹혀 있습니다. 문제는 이게 예측이 안 된다는 거예요. 같은 입력 넣어도 결과가 달라지고, 왜 달라졌는지도 잘 모르겠고. 기존 엔지니어링이랑 섞이니까 더 헷갈립니다.

가장 당황스러운 건, 이 도구들에는 제대로 된 설명서가 없다는 점입니다. 전통적인 라이브러리라면 API 문서를 보면 됐어요. 함수 이름, 파라미터, 리턴 타입이 명확했죠. 하지만 AI 에이전트는 다릅니다. 같은 프롬프트를 넣어도 매번 다른 결과가 나오고, 왜 그런 결과가 나왔는지 설명하기 어렵습니다. 저는 이런 도구를 이렇게 표현해보고 싶습니다. 마치 웹툰에서 나오는 "확률 60%로 작동하는 마법 지팡이"처럼 분명 강력한데, 언제 어떻게 작동할지 모르겠고, 실패하면 왜 실패했는지도 모르는 것처럼 말이죠.

구체적으로 뭘 배워야 하나?

카파시의 트윗을 읽고 가장 답답했던 건, "그래서 뭘 어떻게 공부하란 말이야?"였습니다. 막연히 뒤처진다는 건 알겠는데, 구체적으로 무엇을 해야 할까요? 그래서 제가 실험하고 배운 걸 공유해 보겠습니다.

에이전트 오케스트레이션을 이해해야 합니다

에이전트를 단독으로 쓰는 시대는 끝났습니다. 이제는 여러 에이전트를 조율하는 능력이 핵심입니다. 실제 사례를 들어볼게요. 최근 레거시 코드 리팩토링 프로젝트가 있었습니다. 과거라면 제가 직접 코드를 읽고, 이해하고, 수정했겠죠. 하지만 이번엔 다르게 접근했습니다. 일단 Claude한테 코드 전체 구조 좀 정리해달라고 던졌어요. 파일이 한 50개쯤 되는데 제가 다 읽고 있을 순 없으니까. 정리된 거 보니까 대충 흐름이 보이더라고요. 그걸 ChatGPT에 넘기면서 "여기서 이상한 부분 있어?" 하고 물어봤습니다. 왜 두 개 쓰냐면, 같은 걸 물어봐도 찾아내는 게 좀 다르더군요.

그리고 Cursor에서 실제 리팩토링을 진행했습니다. ChatGPT가 지적한 문제점들을 하나씩 수정하면서, Cursor의 AI가 제안하는 코드를 검토하고 적용했죠. 마지막으로 Cursor로 테스트 코드를 보강했습니다. 제가 한 일은 무엇이었을까요? 각 에이전트에게 적절한 역할을 부여하고, 그 결과물을 검토하며, 다음 단계로 연결하는 것이었습니다. 오케스트라 지휘자가 연주자를 지휘하는 것처럼요.

프롬프트 엔지니어링은 이제 선택이 아닙니다

좋은 프롬프트와 나쁜 프롬프트의 차이는 엄청납니다. 같은 작업을 시켜도 결과물 품질이 10배 아니 20배 차이가 납니다. 예를 들어, API 문서를 작성한다고 해볼까요. 처음엔 이렇게 물어봤습니다. "이 API 문서 작성해줘." 결과는 형편없었습니다. 기본적인 설명만 있고, 예시 코드도 부실했죠.

그래서 프롬프트를 개선했습니다.

"다음 API의 문서를 작성해줘! 포함 사항은 ‘엔드포인트 URL과 메서드’,’요청 파라미터 (타입, 필수 여부, 기본값)’,’응답 형식 (성공/실패 케이스 모두)’,’실제 curl’,’에러 코드와 의미’,’인증 방법’ 그리고 독자는 주니어 개발자이니 초보자도 이해할 수 있게 작성해줘"

그러자 결과물이 완전히 달라졌습니다. 상세하고, 예시가 풍부하며, 실제로 바로 사용할 수 있는 수준이었습니다.

MCP와 LSP 같은 새로운 프로토콜을 이해해야 합니다

솔직히 저도 아직 완벽히 이해하진 못했습니다. 하지만 이것들이 왜 중요한지는 알겠더라고요. MCP(Model Context Protocol)는 AI 모델이 외부 데이터와 도구에 접근하는 표준화된 방법입니다. 과거에는 각 AI 서비스마다 다른 방식으로 통합해야 했다면, 이제는 MCP로 표준화되고 있습니다.

저도 MCP 하나 끄적여봤습니다. 생각보다는 쉬웠습니다. 로컬에 마크다운 파일 몇 개 모아놓고, Claude Desktop에서 "저번에 쓴 회의록 찾아줘" 하면 알아서 뒤져서 가져오게 한 거예요. 코드 한 80줄 정도면 됐어요. LSP(Language Server Protocol)도 비슷합니다. IDE와 언어 도구 간의 표준 프로토콜인데, 이제 여기에 AI가 끼어들고 있습니다. Cursor나 VS Code에서 AI가 코드를 제안할 때, LSP를 통해 프로젝트 구조를 이해하고 적절한 제안을 합니다.

IDE 통합의 의미가 바뀌었습니다

예전 IDE 통합은 "편의 기능"이었습니다. 자동 완성, 문법 체크, 디버거 같은 것들이죠. 하지만 지금은 다릅니다. IDE가 AI 에이전트의 작업 공간이 되고 있죠. Cursor를 예로 들어볼게요. 단순히 코드 에디터가 아닙니다. AI 에이전트가 프로젝트 전체를 이해하고, 컨텍스트를 유지하며, 여러 파일을 동시에 수정할 수 있는 플랫폼입니다.

저번에 버튼 하나 추가하는 작업이 있었는데, Cursor한테 "여기 버튼 누르면 모달 뜨게 해줘" 했더니 알아서 파일 찾아서 고쳐놓더라고요. 제가 한 건 "이거 맞네" 하고 승인 누른 것뿐이었습니다. 이게 가능한 이유는 IDE가 단순히 텍스트 에디터가 아니라, AI가 코드베이스 전체를 이해하고 조작할 수 있는 환경이 됐기 때문입니다.

10배 생산성의 실체와 현실

<출처: 픽사베이>

카파시는 "도구들을 제대로 엮기만 해도 생산성이 10배 증가한다"고 했습니다. 처음엔 과장이라고 생각했지만 놀랍게도 과장이 아니었습니다. 사실 10배 이상인 것 같습니다.

제 경우를 보면, CRUD API 하나 만드는 데 예전엔 서너 시간 걸렸거든요. 설계하고, 코드 짜고, 테스트하고. 지금은 한 30분이면 끝납니다.. 문서 작성도 그래요. 예전엔 API 문서 하나에 2시간 쓰던 게, 이제 AI 초안 뽑고 다듬는 데 20분이면 됩니다. 그렇다고 다 이런 건 아닙니다. 버그 수정은 한 5배 정도 빨라졌고, 코드 리뷰는 아직 제가 AI를 활용한 노하우가 부족한지 솔직히 크게 체감은 못하고 있습니다.

AI가 확실히 잘하는 게 있습니다. CRUD 같은 반복 코드, 문서화, 테스트 코드 생성. 이런 건 진짜 빠릅니다. 반면에 복잡한 비즈니스 로직이나 아키텍처 결정은 여전히 제가 하는 게 아직은 더 나아 보입니다. 특히 10년이 넘은 형편없는 수준의 오래된 레거시 코드 맥락 파악은 AI보다 제가 좀 더 잘하는 것 같고요. 그리고 처음 한두 주는 오히려 작업이 느려졌었습니다. 도구 익히느라 시간 쓰고, ChatGPT로 할 걸 Claude로 삽질하고, Cursor한테 잘못 시켜서 엉뚱한 파일 수정되고. 생산성 오른 건 도구가 손에 익은 다음부터였습니다.

코드 작성자에서 시스템 지휘자로

카파시 트윗 보고 계속 떠오른 질문이 있습니다. "개발자는 이제 뭘 하는 사람인가?"

예전엔 명확했습니다. 코드 짜는 사람. 근데 AI가 코드를 짠다면, 개발자의 역할은 뭘까요? 나름 열심히 실험해 보면서 내린 결론은, 개발자가 "지휘자"에 가까워졌다는 겁니다. 필요한 역량도 바뀌었습니다. 예전엔 알고리즘, 디자인 패턴, 언어 숙련도였다면, 지금은 작업을 AI한테 어떻게 분배할지 판단하는 능력, 프롬프트 설계, 결과물 검증 능력이 더 중요해졌죠. 다만 코딩 실력이 덜 중요해진 건 아닙니다. AI가 짠 코드가 괜찮은지 판단하려면 오히려 더 깊이 알아야 하거든요.

뒤처지지 않기 위한 실전 로드맵

카파시의 경고는 명확합니다. "이 변화에 대응하지 않으면 직업 자체에서 뒤처질 수 있다." 그렇다면 구체적으로 무엇을 해야 할까요? 막연한 조언 대신, 제가 직접 경험하며 만든 4주 실전 로드맵을 공유합니다. AI 시대 뒤처졌다고 생각하는 여러분을 위해 제안합니다.

1주 차: 일단 써보기

첫 주는 도구 익히는 데 집중하세요. ChatGPT, Claude, Cursor 중 하나 골라서 매일 뭐라도 시켜보는 겁니다. 코드 리뷰 받아보고, 간단한 함수 생성 시켜보고, 문서 초안 뽑아보세요. 이 단계에서 중요한 건 습관 들이는 거예요. 처음엔 귀찮아서 그냥 직접 짜게 되는데, 억지로라도 AI한테 먼저 물어보는 습관을 만들어야 합니다. 솔직히 이 주는 생산성 안 오릅니다. 오히려 느려질 수도 있습니다.

1주 차 체크리스트
최소 AI 도구 하나는 가입해서 사용해 봤는가?
일주일에 최소 서너 번은 사용했는가?

2주 차: 도구 조합 실험

한 도구에 익숙해졌으면, 이제 조합을 시도해봅니다. 저는 "Claude로 설계 -> Cursor로 구현" 조합을 이 때 찾았어요. 본인 업무에서 반복되는 작업 하나 골라서, AI 파이프라인을 만들어보세요. CRUD API 개발이든, 테스트 코드 작성이든. 처음엔 어색한데 몇 번 하다 보면 자기만의 흐름이 생깁니다.

2주 차 체크리스트
도구 두 개 이상으로 조합을 해봤는가?
반복 작업 하나에 AI 흐름을 적용해 봤는가?

3주 차: 프롬프트 다듬기

이쯤 되면 "AI가 말을 안 들어서" 답답한 경험이 쌓였을 거예요. 그게 정상입니다. 이 주는 프롬프트를 구체적으로 쓰는 연습을 합니다. "리팩토링해줘" 대신 "함수 50줄 이하로 분리하고, 변수명은 camelCase로 바꿔줘. 기존 API 스펙은 건드리지 마." 이런 식으로요. 뭘 넣으면 결과가 좋아지는지 감 잡는 시간입니다.

3주 차 체크리스트
같은 작업인데 프롬프트 바꿔서 결과 달라진 경험이 있는가?
"이렇게 쓰면 잘 되더라" 감을 잡았는가?

4주 차: 실전 적용

마지막 주는 실제 업무에 전면 적용해 봅니다. 스프린트 태스크 하나를 처음부터 끝까지 AI랑 같이 해보는 거예요. 이때 기록을 남겨두면 좋습니다. 어디서 시간이 줄었는지, 어디서 AI가 오히려 방해됐는지. 4주 끝나고 돌아보면 본인한테 맞는 방식이 뭔지 보입니다.

4주 차 체크리스트
태스크 하나를 AI랑 처음부터 끝까지 해봤는가?
예전보다 빨라진 게 체감되는가?

Andrej Karpathy <출처: The Information>

마치며: 지금 당장 소매를 걷어붙이자

카파시의 말대로 "Roll up your sleeves." 소매 걷고 직접 해보는 수밖에 없습니다. 저도 여전히 헤매고, 실패하고, 좌절합니다. 하지만 그 과정 자체가 성장이라고 믿습니다. 세계 최고 수준의 개발자도 뒤처진다고 고백하는 시대입니다. 완벽할 필요 없습니다. 모든 걸 다 알 필요도 없습니다. 그냥 어제보다 조금 더 알면 되죠. 결국 우리에게 중요한 건 멈추지 않는 태도 아닐까요?

<참고>

Andrej Karpathy, X

]]>

일본 개발자의 좌충우돌 첫 납품기: 기술 너머의 신뢰

담배 냄새 밴 낡은 사무실에서 시작된 도전

저에게 일본에서 개발자로 일하며 가장 긴장했던 순간이 언제였냐고 묻는다면, 주저 없이 그날을 꼽습니다. 난생처음 작성한 코드가 서버에 배포되던 날도, 심각한 버그를 냈던 날도 아니었습니다. 바로 고객 앞에 홀로 섰던, 도쿄 외곽의 어느 택시 회사 방문일이었죠. 도쿄의 화려한 빌딩 숲을 벗어나 전철로 한참을 달려 도착한 이바라키현의 한적한 시골 마을에는 세월의 흔적이 역력한 오래된 건물이 서 있었습니다.

<출처: 작가>

문을 열고 들어서자마자 켜켜이 묵은 담배 냄새가 코를 찔렀습니다. 쇼와 시대의 분위기가 그대로 남아있는 그곳은 최신 IT 기술과는 거리가 한참 멀어 보였습니다. 하지만 그곳을 지키고 있는 직원분들은 의외의 따뜻함으로 저를 맞아주셨습니다. 머리가 희끗한 연배 높은 직원분들은 서툰 일본어로 인사를 건네는 저에게 "멀리서 오느라 고생 많았어, 여기 좀 앉게"라며 기꺼이 자리를 내어주셨습니다.

일본어가 완벽하지 않은 외국인 개발자가 통역도 없이 마주 앉아야 했던 그 자리. 낡은 건물의 풍경만큼이나 낯설고 두려운 '맨땅에 헤딩'의 현장이었습니다. 당시 저는 속으로 "과연 내 일본어 실력으로 이분들의 업무를 이해하고 시스템을 만들 수 있을까?"라고 끊임없이 되물었습니다. 다행히 고객의 따뜻한 배려 덕분에 프로젝트는 첫발을 떼게 되었습니다.

하지만 그때는 미처 몰랐습니다. 제가 마주할 진짜 어려움은 언어 장벽이 아니라, 레거시 기술 속에 숨겨진 암호 같은 코드들, 그리고 바닥부터 신뢰를 쌓아가야 하는 고독한 과정 그 자체라는 것을요. 오늘 들려드릴 이야기는 실패로 점철된 아픈 첫 시도와, 그 실패를 딛고 다시 일어서며 배운 ‘기술 너머의 가치’에 대한 기록입니다. 비슷한 고민을 안고 있는 주니어 개발자들에게 작은 위로가 되기를 바랍니다.

미리 요점만 콕 집어보면?

일본어가 완벽하지 않은 외국인 개발자가 통역도 없이, 고객 앞에 홀로 섰던 순간은 낯설고 두려운 ‘맨땅에 헤딩’의 현장이었습니다.
회사 사정상 예산 문제로 프로젝트팀이 해체되었고, 기존에 델파이(Delphi)로 만들어진 프로그램을 저 혼자 복구하며 첫 번째 시도는 실패로 돌아갔습니다.
그러나 결국 기술을 완성하는 것은 사람 간의 신뢰이며, 끝까지 책임지려는 태도만 있다면 그 진심은 반드시 통하게 되어 있다는 교훈을 얻었습니다.

팀 해체, 그리고 홀로 남겨진 프로젝트

<출처: 작가>

기대감으로 시작했으나 마주한 현실

2022년, 일본에서의 첫 프로젝트를 무사히 마치고 본사로 복귀했을 때 제 마음은 기대감으로 부풀어 있었습니다. 회사로부터 사내 위탁 개발로 들어온 ‘택시 배차 및 관리 프로그램’을 개발하라는 지시를 받았기 때문인데요. 저를 포함해 경험이 적은 일본인 개발자, 열정적인 필리핀 인턴, 그리고 우리를 이끌어줄 한국인 베테랑 리더까지 총 4명이 한 팀을 이루게 되었습니다. 구성도 꽤나 완벽해 보였죠.

"드디어 우리만의 사내 솔루션을 만들 수 있겠구나!" 팀원들과 매일 머리를 맞대고 아이디어를 쏟아냈습니다. 일주일간 서로 으쌰으쌰 하며 화면 설계를 정리했고, 프론트엔드는 리액트(React), 백엔드는 스프링 부트(Spring Boot)로 개발하겠다는 구체적인 계획도 세웠습니다. 최신 기술 스택으로 무장한 프로젝트는 성공을 보장받은 것처럼 보였고, 저희는 자신감에 차 있었습니다. 이때까지만 해도 말이죠.

예산 삭감, 그리고 델파이(Delphi)와의 만남

하지만 그 부푼 꿈은 정확히 일주일 만에 산산조각이 났습니다. 월요일 회의 시간, 회사 사정상 예산 문제로 프로젝트팀을 해체해야 한다는 청천벽력 같은 소식이 전해졌기 때문입니다. 더 충격적인 것은 그다음 지시였습니다. 다른 팀원은 모두 철수하고, 이 프로젝트를 저 혼자 진행하라는 것이었죠.

심지어 요구사항도 "기존에 델파이(Delphi)로 만들어진 프로그램을 역컴파일(Decompile)해서 똑같이 복구하라"는 것으로 바뀌었습니다. 4명이 함께 최신 웹 기술로 만들려던 프로젝트가, 갑자기 저 혼자 짊어져야 할 짐이 되어버린 겁니다. 그것도 모자라 수십 년 전 기술인 Delphi 시스템을 복제해야 하는 ‘과거로의 회귀’가 시작되었습니다.

일본어 변수명과 동작하지 않는 코드의 늪

<출처: 작가>

외계어가 되어버린 코드들

지시받은 대로 기존 시스템을 역컴파일해 보았지만, 모니터에 뜬 결과물을 보는 순간 저는 말문이 막히고 말았습니다. 영어로 되어 있어야 할 변수명들이 가타카나와 한자로 뒤섞인 ‘일본어’로 되어 있었기 때문입니다. 변수명뿐만 아니라 함수명까지 일본어로 작성된 코드는 마치 난해한 고문서를 해독하는 기분이었습니다.

기능은 또 왜 그리 많은지, 수십 개의 화면과 복잡한 로직이 얽혀 있었지만 정작 제대로 동작하는 기능은 거의 없었습니다. 화면 껍데기만 겨우 복구되었을 뿐, 버튼을 누르면 에러 메시지가 쏟아졌고 데이터베이스(DB) 연결조차 불투명했습니다. Delphi는 최신 언어와 달리 관련 자료나 레퍼런스를 찾기가 너무 힘들었고, 구글링을 해도 2000년대 초반의 문서만 드문드문 나올 뿐이었죠. 매뉴얼도, 설계서도 없는 상황에서 오직 ‘제대로 동작하지 않는 일본어 코드 덩어리’만 붙들고 있어야 하는 절망적인 상황이었습니다.

번역기를 켜고 시작한 히어링

혼자서 끙끙 앓다가 도저히 답이 나오지 않아 결국 고객을 직접 만나러 가기로 결심했습니다. 당시 저는 일본에 온 지 1년도 채 되지 않아, 동행한 영업 선배님의 일본어조차 절반도 알아듣지 못하는 수준이었습니다. 담배 냄새 자욱한 사무실에서, 저는 스마트폰 번역기를 켜고 더듬더듬 단어를 조합해 질문을 던져야 했습니다.

하지만 “말이 통하느냐”보다 더 중요한 건 “이해하려는 태도”라는 것을 그때 깨달았습니다. 제가 서툰 일본어로 질문을 던지고, 못 알아들은 부분은 녹음을 해서라도 이해하려 노력하는 모습을 보이자 변화가 생겼습니다. 처음엔 경직되어 있던 고객도 조금씩 마음을 열어주기 시작한 것이죠. 창고에서 먼지 쌓인 매뉴얼을 찾아주신 것도 그즈음이었습니다.

한 달 250시간의 사투, 그리고 귀국을 고민하다

<출처: 작가>

두 마리 토끼를 쫓다 넘어진 날

하지만 1인 개발의 한계는 명확했습니다. 프로젝트 시작 후 2~3개월이 지났을 무렵, 회사의 지시로 저는 다른 신규 프로젝트에 추가 투입되었습니다. 이때부터 지옥 같은 이중생활이 시작되었습니다. 낮에는 본업인 신규 프로젝트를 수행하고, 퇴근 후와 주말에는 택시 앱 개발에 매달려야 했죠. 택시 프로젝트 업무를 제외하고도 본업 근무 시간만 한 달에 250시간을 찍을 정도로 살인적인 스케줄이었습니다.

체력은 바닥났고, 정신적으로도 한계에 봉착했습니다. "내가 여기서 뭘 하고 있는 거지? 그냥 한국으로 돌아갈까?" 이런 생각이 하루에도 수십 번씩 들었습니다. 결국 과부하가 걸린 저는 신규 프로젝트팀에서 퍼포먼스가 나오지 않는다며 호된 질책을 받았습니다. 심지어 팀에서 방출되는 수모까지 겪어야 했습니다. 기술적으로 Delphi 시스템을 단순히 베끼는 것만으로는 유지보수와 확장성 문제를 해결할 수 없었기에, 저의 번아웃과 맞물려 첫 번째 시도는 뼈아픈 실패로 돌아갔습니다.

로컬에서 클라우드로, 웹(Web)으로 다시 시작된 기회

<출처: 작가>

든든한 지원군과 함께한 재도전

실패의 쓴맛을 보고 난 뒤, 잠시 잊고 지냈던 택시 프로젝트가 기적처럼 다시 수면 위로 올라왔습니다. 회사를 잠시 떠나셨던 선배님이 복귀하시면서, 이 프로젝트를 Delphi가 아닌 ‘웹 기반 시스템’으로 다시 제안해 보자고 하신 겁니다. 이번엔 혼자가 아니었습니다. 제가 참여했던 프로젝트 회사의 사장님, 그리고 예전에 함께 손발을 맞췄던 필리핀 인턴 동료까지 합류하여 든든한 드림팀이 다시 꾸려졌습니다. 우리는 과거의 실패를 교훈 삼아, Delphi 대신 처음에 계획했던 웹 기술을 과감하게 도입했습니다.

기술적 난제를 해결한 협업의 힘

가장 큰 변화는 데이터의 안정성이었습니다. 기존 Delphi 시스템은 로컬 PC에 데이터를 저장하는 방식이라, 컴퓨터가 고장 나면 모든 데이터가 날아갈 위험이 있었죠. 우리는 이를 아마존 웹 서비스(AWS) 클라우드 기반으로 전환하여 데이터 안정성을 확보했습니다. 또한 투박하고 사용하기 어려웠던 기존 UI를 걷어내고, 웹 표준에 맞춘 직관적이고 편리한 사용자 경험(UX)으로 개선했습니다.

특히 가장 큰 난관이었던 ‘택시 요금 계산 로직’을 해결하던 과정은 지금도 생생합니다. 문서에도 없는 복잡한 수식을 찾아내야 했는데, 저는 숫자를 하나하나 대입하며 엑셀로 시뮬레이션을 돌렸습니다. 수많은 시행착오 끝에 심야 할증과 거리 비례 요금이 복합적으로 적용된 계산식을 역으로 찾아냈고, 이를 고객에게 제안했을 때 “맞아요! 바로 그 식입니다!”라는 답변을 들을 수 있었습니다. 혼자서는 절대 불가능했던 일이, 팀이 뭉치고 기술적 방향성이 명확해지자, 비로소 해결되기 시작했습니다.

“돈짱 덕분에 생각이 바뀌었어” - 오마카세와 눈물

<출처: 작가>

신뢰가 만든 기적

우여곡절 끝에 시스템을 무사히 납품하고, 택시 회사 사장님과 회식을 하게 된 날이었습니다. 그날은 특별히 오마카세와 비슷한 고급 코스 요리집으로 저희를 데려가 주셨는데요. 정갈한 요리가 나오고 분위기가 무르익을 즈음, 사장님께서 술잔을 기울이시며 의외의 고백을 하셨습니다. “사실 나는 어릴 적 재일교포들과 싸운 기억 때문에 한국인을 별로 좋아하지 않았어.”

순간 분위기가 정적에 휩싸였습니다. 하지만 사장님은 이내 웃으며 덧붙이셨습니다. “그런데 ‘돈짱(제 별명)’이 땀 흘리며 노력하는 모습을 보고 생각이 완전히 바뀌었네.” 60대 사장님의 입에서 나온 그 진솔한 말씀을 듣는 순간, 가슴 깊은 곳에서 뜨거운 것이 올라왔습니다. 지난 몇 달간 250시간씩 일하며 한국으로 도망치고 싶었던 순간들, 일본어 변수명을 보며 절망했던 순간들이 주마등처럼 스쳐 지나갔습니다.

인정받음의 안도감

<출처: 작가>

안도감과 함께 울컥하는 감정이 솟구쳤습니다. 단순히 시스템을 납품한 개발자가 아니라, 진정한 파트너로 ‘인정받았다’는 느낌이 들었기 때문입니다. 그날 먹었던 요리의 맛보다, 사장님의 그 한마디가 제게는 더 깊은 위로와 보상으로 다가왔습니다. 신뢰는 곧 새로운 기회로 이어졌습니다. 택시 회사는 배차 시스템에 이어 ‘급여 관리 시스템’ 개발까지 저희에게 맡기고 싶다고 제안해 왔습니다. 단순한 외주 개발자가 아니라, 회사의 문제를 함께 고민하고 해결해 주는 진정한 파트너가 된 것입니다.

결론: 기술보다 중요한 것은 진심을 다하는 태도입니다

<출처: 작가>

이바라키의 낡은 사무실에서 시작된 프로젝트를 통해 제가 배운 것은 명확합니다.

첫째, 언어와 환경은 결코 넘을 수 없는 장벽이 아니라는 점입니다. 유창한 일본어보다 중요한 것은, 현장을 직접 찾아가 이해하려 노력하는 ‘성실한 태도’였습니다.
둘째, 실패는 끝이 아니라 과정이라는 사실입니다. Delphi 프로젝트의 처절한 실패가 없었다면, 웹으로의 전환이나 AWS 도입의 필요성을 이토록 절실히 깨닫지 못했을 겁니다.
셋째, 결국 기술을 완성하는 것은 사람 간의 신뢰입니다. 아무리 완벽한 코드를 짠다 해도, 고객의 마음을 얻지 못하면 그 프로젝트는 절반의 성공일 뿐입니다. 지금 해외 취업을 준비하거나, 낯선 환경에서 고객과의 소통을 두려워하는 분들이 계신다면 꼭 말씀드리고 싶습니다.

실수는 누구나 할 수 있습니다. 때로는 도망치고 싶을 만큼 힘든 순간도 반드시 찾아옵니다. 하지만 그 자리를 지키며 끝까지 책임지려는 태도만 있다면, 언젠가 그 진심은 반드시 통하게 되어 있습니다. 저의 서툴고 부족했던, 하지만 치열했던 첫 납품 이야기가 타국에서 고군분투하는 모든 개발자들에게 “실패해도 괜찮다”는 작은 용기가 되기를 진심으로 바랍니다.

]]>

착한 개발자의 함정에서 벗어나는 법

거절과 협상 스킬: "네"라고 말하기 전에 알아야 할 것들

금요일 오후 4시. 퇴근 딱 한 시간 남았습니다. 이제 슬슬 가방을 챙기려던 찰나, PM이 모니터 너머로 고개를 빼꼼 내밀며 말합니다.

"이번 주 배포 기능들 다 끝났죠? 고객사에서 급하게 요청한 게 하나 있는데요. 간단한 거라 이번 주에 같이 넣으면 안 될까요?"

이 순간, 여러분의 머릿속에는 여러 생각이 스쳐 지나갑니다.

'간단하다고? 간단한 게 어디 있어...'

'주말에 또 일해야 하나...'

'거절하면 팀 분위기 이상해지는 거 아냐?'

결국 마지못해 대답합니다.

"네... 한번 해보겠습니다."

회의실을 나오면서 후회가 밀려옵니다. '왜 또 이러지? 왜 난 거절을 못 할까?'

혹시 이런 경험, 한두 번쯤은 있으신가요? 아니, 솔직히 말하면 이런 일이 일주일에 한 번은 생기지 않나요? 많은 개발자가 거절을 어려워합니다. 그리고 그 대가는 생각보다 큽니다. 주말 근무, 번아웃, 버그투성이 코드, 그리고 결국 "왜 그때 안 된다고 말하지 못했을까"라는 자괴감까지 들죠. 개발자에게 거절과 협상은 선택이 아닙니다. 자신의 시간을 지키고, 코드 품질을 유지하며, 10년, 20년을 버티기 위한 생존 기술입니다.

미리 요점만 콕 집어보면?

개발자에게 거절과 협상은 선택이 아닙니다. 자신의 시간을 지키고, 코드 품질을 유지하며, 10년, 20년을 버티기 위한 생존 기술입니다.
그런데 아이러니한 건, 거절하지 못하는 것이 오히려 팀에 더 큰 피해를 준다는 사실입니다.
역설적이지만, 가장 신뢰받는 개발자는 "No"를 잘 말하는 사람입니다.

왜, 자꾸 거절을 못 할까?

<출처: 픽사베이>

1) 착한 사람 증후군

제 주변에는 유독 "착한 개발자"가 많습니다. 아니, 정확히는 착해 보이려는 개발자가 많습니다. "내가 거절하면 동료한테 피해가 가는 거 아냐?", "팀워크 해치는 이기적인 놈으로 찍히면 어쩌지?", "도와달라는데 거절하면 너무 냉정한 거 아닌가?" 특히 한국 개발자들은 더 심합니다. 문화적으로 '눈치'를 보고, '분위기'를 읽고, '민폐'를 끼치지 않으려 하니까요. PM이 난처한 표정을 짓는 순간, 우리는 이미 반쯤 저버린 겁니다.

그런데 아이러니한 건, 거절하지 못하는 것이 오히려 팀에 더 큰 피해를 준다는 사실입니다. 과부하로 코드 품질이 떨어지고, 데드라인을 못 지키고, 결국 번아웃으로 한 달씩 쉬게 되면 그게 팀에 더 민폐 아닐까요? 적절한 거절은 이기심이 아니라 팀을 위한 책임입니다.

2) 기술적 낙관주의

개발자는 타고난 문제 해결사입니다. 문제를 보면 자동으로 "어떻게 풀지?"를 고민하죠. 이런 성향이 장점이기도 하지만, 거절을 어렵게 만드는 약점이기도 합니다.

"CRUD 하나 추가하는 거잖아. 하루면 되겠네."
"기존 코드 복붙해서 조금만 고치면 끝 아냐?"
"간단한 기능이니까 금방이지 뭐."

그런데 막상 시작하면 어떤가요? 예상치 못한 버그가 터지고, 엣지 케이스가 산더미처럼 쏟아지고, 레거시 코드는 스파게티처럼 엉켜있고, 기획서는 구멍투성이입니다. 결국 하루 작업이 일주일로 늘어나고, 자신을 자책하게 됩니다. '내가 멍청해서 그런가...' 아닙니다. 당신이 멍청한 게 아닙니다. 많은 개발자들이 기술적 낙관주의 실수를 합니다.

3) 평가에 대한 두려움

주니어 개발자일수록 이 두려움이 큽니다. "거절하면 평가에 안 좋게 나오는 거 아냐?" "승진에서 밀리는 거 아냐?" "다음 좋은 프로젝트에서 빠지는 거 아냐?" 그래서 무리한 요청에도 "네"라고 답합니다. 회사에 빨리 자리 잡고 싶고, 인정받고 싶으니까요.

그런데 여기 반전이 있습니다. 무조건 수락하는 게 오히려 평가를 깎아 먹습니다. 데드라인을 못 지키고, 코드 품질이 떨어지고, 결국 "저 사람 자기 관리 못 하네"라는 낙인이 찍힙니다. 반대로 적절히 거절하고 협상하는 개발자는 어떻게 평가받을까요? "현실적이고 책임감 있는 사람"으로 평가받습니다. 약속은 적게 하되, 한 약속은 반드시 지키는 사람 말이죠.

거절하지 못했을 때의 대가

<출처: 픽사베이>

1) 번아웃의 늪

모든 요청을 다 받아들이면 어떻게 될까요? 처음에는 괜찮습니다. "이 정도야 뭐"하면서 버티죠. 하지만 시간이 지나면서 과부하가 쌓입니다. 저녁 약속은 매번 취소되고, 주말에도 노트북을 열고, 취미는 기억 속에서 사라지고, 운동은 사치가 됩니다. 그리고 어느 순간 무너집니다.

거절을 모르는 시니어 개발자의 이야기를 한번 창작해 보겠습니다. 그는 거절을 모르는 개발자입니다. '시니어니까 이 정도는 해야지'라는 생각으로 모든 걸 떠안았습니다. PM의 급한 요청도, 주니어의 끝없는 질문도, 아무도 손대지 않는 레거시 코드도 전부요. 어느 월요일 아침이었습니다. 출근길 지하철 안에서 갑자기 숨이 막혔다고 합니다. 심장이 터질 것 같았고, 식은땀이 났고, 다리가 풀렸죠. 공황장애였습니다. 병원에서는 과로라고 했고, 그는 2개월간 병가를 냈습니다.

복귀 후 그가 동료 개발자에게 이런 말을 합니다. "거절은 무책임한 게 아니더라. 오히려 나를 지켜야 팀도 지킬 수 있어. 내가 쓰러지면 결국 모두에게 피해잖아." 그의 목소리에는 후회보다 깨달음이 묻어났습니다. "이제 알았어. 모든 요청에 '네'라고 하는 게 성실함이 아니라는 걸. 내가 할 수 있는 것과 없는 것을 구분하고, 솔직하게 말하는 게 진짜 프로더라고."

그 후 그는 변했습니다. 무리한 요청이 오면 현재 작업 목록을 보여주며 우선순위를 조율했고, 자신의 한계를 솔직하게 인정했습니다. 그렇게 거절을 모르던 개발자는 이제 현명하게 거절하는 개발자가 되었습니다.

2) 코드 품질의 하락

시간이 부족하면 뭐가 제일 먼저 희생될까요? 바로 코드 품질입니다.

"테스트 코드? 나중에 쓰지 뭐."

"리팩토링? 일단 기능부터 돌리고 보자."

"문서화? 코드가 문서지 뭐."

결과는? 3개월 후 그 코드를 다시 열었을 때 이렇게 중얼거리게 됩니다.

"도대체 이 코드를 누가 짠 거야... 아, 내가 짰네."

더 큰 문제는 악순환입니다. 코드 품질이 낮으면 디버깅에 시간이 더 들고, 그러면 새 작업 시간이 더 부족해지고, 결국 또 품질을 포기하게 됩니다. 거절하지 못한 대가를 미래의 내가 치르는 겁니다. 기술 부채는 이자가 붙는 빚과 같습니다. 나중에는 원금보다 이자가 더 커집니다.

3) 정작 중요한 일을 못함

항상 남의 급한 일만 처리하다 보면 정작 중요한 건 손도 못 댑니다.

시스템 개선? "나중에..."
새로운 기술 학습? "여유 있을 때..."
개인 프로젝트? "다음 달에..."
기술 부채 해소? "스프린트 끝나고..."

스티븐 코비의 시간 관리 매트릭스를 아시나요? 일을 네 가지 기준으로 나눕니다.

긴급하고 중요한 일
긴급하지 않지만 중요한 일
긴급하지만 중요하지 않은 일
둘 다 아닌 일

거절 못 하는 개발자는 3번(긴급하지만 중요하지 않은 일)에 시간을 다 쓰고, 2번(긴급하지 않지만 중요한 일)은 영원히 못 합니다. 그리고 나중에 이렇게 한탄하겠죠. "매일 남의 급한 일만 처리했더니 제 성장은 멈춰있네요. 새 기술도 못 배웠고, 포트폴리오도 없고... 남의 우선순위로 살다가 제 미래를 놓쳤어요."

효과적인 거절 방법

1) "No" 대신 "Yes, but..." 전략

거절이 어려운 진짜 이유는 "안 됩니다"라는 말 자체가 부담스럽기 때문입니다. 그럼 어떻게 할까요?

나쁜 거절: "안 됩니다. 저 바빠요."

좋은 거절:

"이번 주는 어렵지만, 다음 주 월요일부터 시작하면 수요일까지 완성 가능합니다."
"네, 가능합니다. 다만 지금 진행 중인 A 기능을 먼저 끝내야 하는데, 이걸 미루고 새 기능 먼저 할까요?"
"할 수 있습니다. 단, 예상 시간이 3일인데요. 범위를 줄이면 더 빨리 가능할 것 같습니다. 핵심 기능만 먼저 구현하고 나머지는 다음 스프린트에 하면 어떨까요?"

차이가 보이시나요? 거절이 아니라 협상입니다. "안 된다"가 아니라 "이렇게 하면 된다"를 말하는 겁니다.

2) 구체적 스크립트 제공

그럼 이제 실전에서 바로 쓸 수 있게 스크립트를 상황별로 정리했습니다.

시간이 부족할 때:

"이번 주는 A, B 작업으로 꽉 차 있습니다. 다음 주 화요일부터 가능한데 괜찮으신가요?"
"예상 시간이 3일인데, 현재 스프린트에는 2일밖에 여유가 없어요. 범위를 줄이거나 다음 스프린트로 조정하면 어떨까요?"

요구사항이 애매할 때:

"흥미로운 기능이네요. 다만 구체적인 요구사항 정리가 필요할 것 같아요."
"지금 정보로는 정확한 예상이 어렵습니다. 프로토타입 먼저 만들어서 검토 후 일정 확정하면 어떨까요?"

다른 일이 우선일 때:

"중요한 요청인 건 알지만, 현재 C 작업이 더 우선순위 높다고 알고 있어요. 팀장님과 우선순위 조율해 보면 어떨까요?"

전혀 모르는 분야일 때:

"할 수는 있지만 익숙하지 않아서 시간이 2배로 걸릴 수 있어요. 전문가한테 맡기는 게 효율적일 것 같은데 어떠세요?"

3) 우선순위 기반 협상법

거절의 핵심은 우선순위입니다. "안 된다"가 아니라 "이것보다 저것이 먼저입니다"라는 메시지를 전달하는 것이죠. 효과적인 방법은 현재 작업 목록을 시각화하는 것입니다. 간단한 테이블로 정리해 보세요.

<출처: 작가>

새 요청이 오면 이 표를 보여주며 물어보세요. "현재 이런 작업들이 있는데, 새 작업을 넣으려면 어떤 걸 조정할까요?" 이렇게 하면 의사결정 책임이 요청자에게 넘어갑니다. 그리고 대부분 이렇게 말합니다. "아, 그럼 다음 주에 해도 되겠네요." 현재 작업 목록을 시각화 하는 건 최고의 방어막입니다.

거절은 프로의 능력이다

<출처: 픽사베이>

역설적이지만, 가장 신뢰받는 개발자는 "No"를 잘 말하는 사람입니다. 왜? 그들은 약속을 지키니까요. 무분별하게 수락했다가 데드라인 못 지키는 것보다, 현실적으로 거절하고 확실히 완성하는 게 훨씬 프로페셔널합니다. 거절은 신뢰를 깎는 게 아닙니다. 오히려 신뢰를 쌓는 과정입니다. 물론 처음에는 어렵습니다. 특히 주니어 개발자에게는 더욱 그렇죠. 하지만 작은 것부터 시작하세요.

내일부터 당장 시작할 수 있는 것들

1) 즉답 금지령

PM이 "이거 이번 주에 가능해요?"라고 물으면 바로 "네"라고 하지 마세요. 대신 이렇게 말하세요. "잠깐만요, 현재 일정 확인하고 10분 후에 답변드릴게요." 이 10분이 당신을 구합니다. 감정이 아니라 현실로 판단할 수 있는 시간이니까요.

2) 투명한 일정 공유

매주 월요일, 이번 주 작업 목록을 팀에 공유하세요. 슬랙이든, 이메일이든, 스탠드업이든 상관없습니다. "이번 주는 A 기능 구현(3일), B 버그 수정(1일), C 리팩토링(1일) 예정입니다." 이렇게 하면 새 요청이 왔을 때 "월요일에 공유한 목록 보셨죠?"라고 자연스럽게 말할 수 있습니다.

3) "네, 그런데..." 화법 익히기

거절을 바로 하지 못하겠다면, 조건부 수락을 연습하세요. "네, 가능합니다. 다만 현재 진행 중인 A 작업을 미루면 되는데, 괜찮으신가요?" "할 수 있습니다. 단, 예상 시간이 5일인데요. 범위를 줄이면 3일로 가능할 것 같습니다." 이건 거절이 아닙니다. 의사 결정권을 상대에게 넘기는 겁니다.

4) 거절은 책임감의 표현

거절은 이기심이 아닙니다. 자신의 시간을 지키고, 코드 품질을 유지하며, 장기적으로 팀에 기여하기 위한 책임감의 표현입니다. 거절과 협상은 코딩만큼이나 중요한 커리어 스킬입니다. 코드를 잘 짜는 것도 중요하지만, 자신의 시간과 에너지를 잘 관리하는 것도 중요합니다. 그것이 10년, 20년을 버티는 개발자와 5년 만에 번아웃으로 떠나는 개발자의 차이죠. 여러분의 "No"는 미래의 더 나은 "Yes"를 위한 투자인 걸 잊지 마세요.

<참조>

[국민일보] 하루하루 알차게 보내고 싶다면… 코비의 시간관리 ‘매트릭스’ 활용을

]]>

프랑스 개발자는 왜 한국에서 테크 채용 플랫폼을 만들게 되었을까?

Dev Korea CEO 인터뷰

Entrepreneurship이라는 말을 들어 보셨나요? 기업가 정신을 뜻하는 이 말은, 제가 대학생이던 시절 IT 창업 붐이 일며 자주 접하던 단어 중 하나입니다.

구성도 발음도 어려워 찾아본 이 단어가 아직도 기억에 생생하게 남아 있습니다. 당시 단어의 어원도 함께 접했는데요, 이 말은 ‘시도하다’, ‘모험하다’, ‘착수하다’라는 의미의 프랑스어 동사 entreprendre에서 유래했다고 합니다. 즉, 기업가 정신이란 말은 위험을 감수하고 새로운 가치를 창출하는 정신을 의미하는 것이죠. 그렇게 이 단어 하나로, 제게 프랑스라는 나라는 기업가 정신을 대표하는 나라 중 하나로 자리매김하고 있었습니다.

Dev Korea 창업자 Florian <출처: Florian LinkedIn>

이 기업가 정신을 품고 한국에서 플랫폼을 만든 프랑스인 창업자, Florian의 이야기를 여러분에게 들려주고 싶습니다.

Florian은 3년 전, 처음 한국으로 넘어와 다양한 테크 밋업을 만들고 운영하다 Dev Korea(데브 코리아)라는 테크 채용 플랫폼을 만들었습니다. 이 플랫폼에서는 올해 1월 기준으로 3천 명 이상의 테크 전문가들이 활동하며, IT 전문가와 기업들을 연결하는 테크 채용 플랫폼으로 자리를 잡아 가고 있습니다.

Dev Korea는 국내 테크 시장의 인재 불균형을 해소할 목적으로, 영어 친화적인 소프트웨어 개발에 니즈가 있는 기업과 국제적인 커리어를 쌓고 싶은 개발자들을 서로 매칭해 주는 서비스를 제공합니다. 즉, “영어를 사용할 수 있는 개발자” 누구에게나 열려있는 플랫폼이죠. 한국 플랫폼이지만, 한국인뿐만 아니라 국적을 불문한 개발자들이 사용하며 해당 마켓에서 널리 알려진 플랫폼으로 성장했습니다.

한국이란 낯선 나라에서 Florian이 만들어 나가는 아이디어와 실행력, 그리고 결과들이 궁금해졌습니다. 그래서 직접 만나 인터뷰를 진행해 보았습니다. 그의 기업가 정신부터 창업 스토리, 그리고 한국 IT 채용 시장과 개발자에 대한 인사이트를 함께 들어보시죠.

영어를 할 수 있는 모든 IT인을 위한 채용 플랫폼

Q. 안녕하세요, Florian. 우선 가장 눈에 띄는 건 독특한 이력인데요. 프랑스에서 시작해 일본, 그리고 한국까지 온 배경이 궁금합니다.

저는 프랑스에서 태어나 컴퓨터 공학 석사 학위를 취득하고, Air France라는 회사에서 개발자로 일을 시작했어요. 그러다 우연한 기회로 일본에 여행을 갈 기회가 있었는데, 그때 일본에서 거주해 보고 싶다는 생각이 들었어요. 마침, 제가 원하는 일에 스스로 도전해 보고 싶은 마음이 커 안정적인 회사를 뒤로한 채, 일본으로 건너가 첫 회사를 창업했습니다.

두 명의 한국인 공동 창업자, 그리고 한 명의 프랑스 동료와 함께 약 6년 동안 일본에서 다양한 앱과 웹 서비스를 운영하며 16명 규모까지 팀을 성장시켰죠. 하지만, 규모가 커질수록 나만의 사업을 새로 시작하고 싶다는 갈망이 생겼습니다. 앞서 한국 사람들과 만나고 일하며 느낀 매력으로 3년 전 한국에 오게 되었습니다.

Q. 그렇게 한국에서 시작한 Dev Korea는 어떤 플랫폼인가요?

Dev Korea는 한국에서 일하며 영어를 사용하는 IT인들을 위한 테크 전문 채용 플랫폼이에요. 사실 처음에는 한국에 거주하는 외국인 개발자들을 위한 플랫폼으로 시작했죠. 그런데 운영 과정에서 실제로 한국인 개발자들이 채용되는 사례가 늘어나면서, 현재는 영어로 소통할 수 있는 모든 IT 전문가를 위한 플랫폼으로 정의하고 있습니다.

요즘 Dev Korea는 영어를 장벽이 아닌 ‘도구’로 보며, 한국 개발자가 국내외 글로벌 기업으로 커리어를 확장할 기회를 제공하려고 노력합니다. 앞으로 더 많은 한국인 IT 인재들이 참여해 국제적인 커리어를 쌓으며, 지속 가능한 글로벌 채용과 지식 공유 생태계를 구축하는 플랫폼으로 성장하는 것이 장기적인 방향이고요. 그렇게 외국 개발자를 위한 채용 사이트와 커뮤니티를 넘어, 한국 IT 인재들이 글로벌 무대에서 활약할 수 있도록 돕는 온/오프라인 통합 플랫폼을 목표로 하고 있어요.

1명에서 시작해 3,300명까지 커진 커뮤니티

Dev Korea의 3,300 팔로워 <출처: LinkedIn>

Q. Dev Korea를 이야기할 때, Meetup 커뮤니티를 빼놓을 수 없을 것 같아요. 어떻게 커뮤니티를 시작하게 되었나요?

가장 먼저 시작한 건 Seoul iOS Meetup으로, iOS 개발자를 위한 커뮤니티였어요. Dev Korea Meetup 보다 먼저 만들어 운영한 커뮤니티죠. 일본에서 Tokyo iOS Meetup 운영진으로 참여했던 경험을 바탕으로 한국에서도 비슷한 시도를 해보고 싶었습니다. 아직도 처음 커뮤니티를 열었을 때의 기억이 생생한데요. Meetup을 열고 카페에서 모임을 시작했는데, 저 혼자 앉아 있거나 한두 명만 오는 날들이 많았어요. 온라인 모임도 시도해 봤지만 큰 반응은 없었고요. 하지만 저는 ‘꾸준함’의 힘을 믿고 있습니다. 그래서 혼자 있더라도 약속된 장소에 계속 나타났고, 결국 잠시 멈췄던 오프라인 모임을 다시 열었을 때 16명이 모였죠. 이날을 시작으로 지금은 매달 40명 넘는 iOS 개발자들이 모이고요.

이 성공 경험을 더 넓은 곳으로 옮기고자, 모든 IT 주제를 다루는 Dev Korea Meetup을 만들게 되었어요. 지금은 100명 넘는 규모의 모임들이 열리고 있어요. 최근에는 Supabase, PostHog, ClickHouse와 같은 글로벌 기업들과 함께 이벤트를 주최하며 영어 사용자 테크 커뮤니티와 교류하고 업계 전문가들과 네트워킹할 수 있는 다양한 기회들을 만들고 있죠.

Q. 모임이 커질수록 운영에 들어가는 시간과 노력이 상당할 텐데요. 현재 Dev Korea와 Meetup이란 대규모 커뮤니티를 운영하며 어려운 점은 없나요?

사람이 많아질 수록 행사를 운영할 사람, 모임 장소처럼 챙겨야 할 것들이 많죠. 당연히 어려움도 큽니다. 게다가 Dev Korea는 모든 행사를 무료로 유지하는 것을 철학으로 생각하고 있어요. 더 많은 사람이 편하게 참여하며 다양한 사람들이 네트워킹할 생태계를 만들고 싶거든요. 사실 저희는 이벤트를 진행하며 간단한 음식들을 제공하고 있는데요, 최근에는 참석자가 많아진 탓에 운영 비용도 상당히 들고 있습니다.

그럼에도 불구하고 해외 몇몇 기업의 후원과 커뮤니티 운영을 자발적으로 도와주는 친구들이 있어 꾸준히 운영하고 있어요. 무엇보다 아내이자 공동 창업자인 Serin의 헌신적인 도움으로 Dev Korea의 다양한 이벤트가 훌륭하게 나가고 있다고 생각해요. Serin은 항상 누구보다 앞장서서 행사 준비와 통역, 현장 운영을 도와주며 가장 든든한 조력자 역할을 해주고 있죠.

Dev Korea Meetups <출처: LinkedIn>

Q. 다른 산업과 비교했을 때 IT 업계만의 커뮤니티 문화가 가지는 특별함은 무엇일까요?

전 세계적으로, IT 업계에서는 지식을 무료로 나누는 문화가 매우 강력해요. 누군가 문제를 해결하면 이를 오픈 소스로 공개하거나 커뮤니티에서 공유하죠. 이러한 자발적 공유는 산업 전체의 발전을 앞당깁니다. 저 역시 Dev Korea의 모든 이벤트를 무료로 제공하고 있는데요. 이를 유료로 만들면 접근성이 낮아지고 참여하는 사람들의 배경이 제한되기 때문이에요. 최대한 다양한 사람이 모여 서로의 배경과 지식을 교류할 수 있는 생태계를 만들고 싶거든요.

예를 들어, 지금은 개발자가 아니지만 커리어 전환을 생각하는 다른 직종의 사람도 편하게 네트워킹할 그런 문화가 필요하다고 봐요. 커뮤니티 참여는 단순한 정보 교류를 넘어, 나와 다른 관점을 가진 사람들을 만나며 커리어와 인생을 확장할 최고의 기회니까요.

기술력은 최고지만, 완벽주의라는 벽에 갇힌 한국 개발자

Q. 커뮤니티와 플랫폼을 운영하며 수많은 한국 개발자를 만나보셨을 텐데, 어떤 강점이 있다고 생각하세요?

한국 개발자들은 강점이 뚜렷해요. 정말 열정적이고 부지런합니다. 제게 한국 개발자는 무엇이든 잘하려고 하는 데다, 항상 새로운 기술을 배우는 데 적극적이라고 생각해요. 경쟁적인 사회 구조(?) 덕분인 것 같기도 한데요. 긍정적으로 생각하면 이러한 지점이 개인들의 성장에 촉매제가 되어 역량을 상향 평준화하는 듯해요. 그래서 실제로도 한국 개발자의 기술적 역량은 매우 뛰어나다고 생각하고요.

Q. 그럼 반대로, 만나본 외국인 개발자와 다르거나 아쉽다고 생각하는 부분이 있나요?

외국인인 제 관점에서는 한국 개발자들의 약점이 ‘영어’와 ‘네트워킹’에 있다고 느껴져요.

테크 산업에서 영어는 공용 언어로, 모든 최신 정보와 커뮤니티가 영어로 진행되고 있는데요. 제 생각이지만, 한국인이 가진 뭐든지 잘하며 완벽해야 한다는 성향 때문에 영어가 완벽하지 않으면 입을 떼는 것조차 주저하는 모습이 있어요. 하지만 비즈니스 영어는 의사소통이 목적이지 문법 시험이 아닙니다. 그런 완벽주의로 글로벌 커뮤니티에 참여하지 못해, 뛰어난 기술력을 세계에 알리지 못하는 점이 너무 안타까워요.

네트워킹에 대해서도 이야기하고 싶은데요. 사실, 외국에서는 커뮤니티 활동을 단순한 친목이 아니라 커리어 성장의 핵심 동력으로 보는 인식이 있어요. 실제로 다양한 사람이 네트워킹에서 얻은 정보와 기회로 커리어가 바뀌고, 완전히 다른 인생을 사는 것도 많이 봤거든요. 반면 한국에서는 그런 네트워킹 기회를 많이 살리지 못하고 있다고 느껴져요. 재미있는 특징이 있는데요. Meetup 마지막에는 늘 네트워킹 세션을 가지는데요, 한국 사람들은 항상 집에 가기 바빠요. 결국 남아있는 사람은 대부분 외국인이었죠.

한국 테크 시장 접근을 위한 인사이트 공유회(sharing insights on breaking into Korea's tech market) <출처: Florian X>

개발자의 미래와 지속 가능한 생태계를 위한 한 걸음

Q. 주제를 바꿔 볼게요. AI 기술의 급격한 발전으로 주니어 개발자의 채용 기회가 줄어드는 등 어려움을 준다는 얘기가 많은데, 채용 플랫폼 운영자로서 이에 대해 동의하시나요?

지금 시장에서 AI를 사용하는 것은 이제 선택이 아닌 필수라고 생각하고 있어요. 다만, 개발자들은 도구가 제안하는 코드를 무비판적으로 수용하지 않고, 왜 이 코드가 필요한지 근본 원리를 이해하려는 노력을 함께할 필요가 있죠. 그래야만 진정한 기술적 성장이 가능하다고 생각합니다.

요즘처럼 기술 변화의 속도가 빠르면 스트레스받을 수도 있지만, 역설적으로 그러한 변화 자체가 IT 업계의 가장 큰 매력이라고도 생각해요. 새로운 기술을 배우는 과정을 즐기는 사람이라면 채용 시장에서 절대 뒤처지지 않을 겁니다. 그런 면에서 AI 기술의 발전은 어쩌면 학습력이 뛰어난 한국 개발자에게 더욱 큰 이점으로 다가올 수도 있다고 봐요.

물론 저도 AI가 테크 채용 시장에 미치는 영향을 다룬 기사를 많이 접하지만, AI가 개발자 모두를 대체할 거라고는 절대 생각하지 않습니다. 결국 AI를 잘 활용할 수 있는 사람이 주니어나 시니어 여부에 상관없이 채용 시장에서 꾸준히 이점을 가져갈 거라고 생각해요.

Q. 마지막으로, 이런 시대를 살고 있는 Dev Korea의 목표와 비전, 그리고 개인적인 목표가 궁금합니다.

올해 제 가장 큰 숙제는 ‘수익 창출을 통한 플랫폼의 지속 가능한 운영 모델’을 구축하는 거예요. 지금까지는 Dev Korea를 열정과 후원만으로 잘 운영해 왔지만, 플랫폼이 더 크게 성장해 혜택을 주려면 안정적인 수익화가 필요하니까요. 지금도 Dev Korea는 매달 수익에 대한 정보를 공유하며, 많은 사람과 투명하게 소통하고자 노력하고 있습니다. 이런 점으로 여러 사람이 저희 서비스를 신뢰하고 좋아해 주는 이유이지 않을까 생각하기도 하고요.

또, 올해는 더 많은 한국 개발자가 Dev Korea를 활용하도록 만드는 것이 목표인데요. 영어가 어려운 한국 개발자들도 ‘영어’라는 장벽을 깨고 더 글로벌하게 일할 기회를 함께 만들어 나갈 수 있으면 좋겠습니다.

개인적으로는 올해 일과 건강의 균형을 찾는 삶을 살려고 해요. 창업자는 항상 일에 매몰되기 쉽거든요. 휴가 중에도 업무 생각을 떨치기 어렵고 꾸준한 건강 관리가 어렵기도 하죠. 하지만, 삶의 밸런스가 사업의 지속 가능성에도 필수라는 것을 최근 깨달았습니다. 그래서 앞으로도 건강한 모습으로 한국의 개발 생태계가 세계로 뻗어 나가는 데 기여하는 Dev Korea를 만들어 가도록 노력하겠습니다.

Dev Korea 메인 홈페이지 <출처: 편집부>

마치며

이번 인터뷰로 Florian을 만나며, 그가 보여준 기업자 정신에서 많은 인사이트를 얻어갈 수 있었습니다.

무엇보다 그가 한 말처럼, 한국 개발자가 가진 기술적인 역량은 글로벌 시장에서도 충분히 경쟁력이 있습니다. 글로벌 커리어를 원하는 개발자들이 더 많은 기회를 얻으며, 한국의 테크 생태계를 발전시켜 나갈 수 있으면 좋겠습니다.

]]>

경쟁력 있는 'AI PM'이 되기 위한 2026 로드맵

본문은 요즘IT와 번역가 Jane Heo가 함께 샤일레쉬 샤르마(Shailesh Sharma)의 글 <AI Product Manager Skill & Roadmap 2026>을 번역한 글입니다. 이 글은 AI 시대에 살아남고 성장하려는 프로덕트 매니저를 위해 확률적 제품 이해, 데이터·AI 아키텍처, 생성형 AI·RAG·에이전트, 프로토타이핑, 그리고 고난도 AI PM 인터뷰 대응까지를 단계적으로 제시하는 2026년 AI 프로덕트 매니저 로드맵입니다.

필자인 샤일레쉬 샤르마는 AI와 프로덕트, 전략을 제1원칙 사고(First Principles Thinking)로 풀어내는 프로덕트 리더이자 콘텐츠 크리에이터입니다. 그는 AI 시대에 PM이 갖춰야 할 실무 역량과 사고방식을 중심으로 글과 강의를 통해 인사이트를 공유하고 있습니다. 현재 AI Product Management 과정(및 AI PM Interview Preparation 포함)을 운영하며, 많은 PM들이 AI 커리어 전환과 인터뷰를 준비하도록 돕고 있습니다. 또한 Tech & Strategy 뉴스레터를 통해 기술과 비즈니스, 전략의 교차점에 대한 깊이 있는 분석을 정기적으로 전합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 각주(*표시)는 ‘번역자주’입니다.

미리 요점만 콕 집어보면?

우리는 이제 거의 모든 제품이 AI를 핵심으로 가지는 시대로 진입하고 있으며, 확률적 제품을 설계하고 관리할 수 있는 프로덕트 매니저가 요구되고 있습니다.
훌륭한 AI PM은 AI 플라이휠, 데이터 파이프라인, 생성형 AI·RAG·에이전트 구조를 이해하고 이를 제품 설계와 확장에 활용합니다.
이 로드맵은 프로토타이핑 역량과 AI 시스템 사고를 바탕으로 고난도 AI PM 인터뷰까지 대비하도록 단계적으로 안내합니다.

AI 프로덕트 매니저가 되기 위한 단계별 가이드

당신은 미래의 커리어가 불안한 프로덕트 매니저인가요?

당신은 자신의 직업과 고용 안정성에 대해 많은 불확실성을 느끼는 프로덕트 매니저인가요?

그렇다면, 당신은 올바른 곳에 왔습니다. 잠깐만 솔직해집시다. 그 낮은 수준의 불안감은 실제로 존재합니다. 수년 동안 “프로덕트 매니지먼트”는 비교적 정형화된 스킬로 설명됐습니다. 사용자 공감, *애자일 세레모니 운영, **백로그 우선순위 설정, 그리고 기본적인 SQL 쿼리를 돌릴 수 있는 정도의 역량으로 말이죠.

*애자일(Agile) 방법론에서 팀이 정기적으로 수행하는 공식적인 미팅과 활동

**앞으로 해야 할 일들을 우선순위에 따라 정리해 둔 작업 목록

괜찮은 *PRD를 작성하고 이해관계자를 잘 관리할 수 있다면, 당신은 충분히 경쟁력이 있었습니다.

*Product Requirements Document. 제품이나 기능을 왜, 무엇을, 어떤 기준으로 만들어야 하는지를 정리한 문서

하지만 이제 그 시대는 끝나가고 있습니다. 우리는 이제 거의 모든 제품이 AI를 핵심으로 가지는 시대로 진입하고 있습니다. 단순히 나중에 덧붙이는 기능이 아니라, 제품의 중심으로서의 AI 말입니다. 이 변화는 시장에 거대한 공백을 만들어냈습니다.

기업들은 단순히 “AI에 관심 있는 PM”이나 링크드인 프로필에 “AI Enable Product Manager”, “AI Product Manager”라고 적어 놓은 사람이 아니라, 실제로 확률적 제품을 설계하고, 측정하고, 확장할 수 있는 프로덕트 매니저를 절실히 찾고 있습니다.

문제는 무엇일까요? 대부분의 기존 PM들은 기술적인 격차 앞에서 공포를 느낀다는 겁니다. 신경망, RAG 시스템, 벡터 데이터베이스 같은 용어를 보는 순간 멈춰버립니다. 그리고 경쟁력을 갖추기 위해서는 컴퓨터공학 석사 학위를 다시 따야 한다고 생각하죠. 저는 지난 몇 달 동안 현재 시장에서 PM에게 정확히 어떤 스킬이 부족한지를 분석해 왔습니다.

프로덕트 매니저의 역량

전통적인 PM이 AI로 전환할 때 가장 크게 저지르는 실수는 제품 라이프사이클이 동일하다고 가정하는 것입니다. 그렇지 않습니다. 전통적인 소프트웨어에서는 버튼이 작동하지 않으면 그것은 버그입니다. 코드를 수정하면 100% 정상적으로 작동합니다. AI에서는 확률을 다룹니다. 출력은 결정론적이 아니라 “아마도”입니다.

당신의 챗봇은 95%의 시간 동안은 훌륭한 답변을 하지만, 5%의 시간 동안은 터무니없는 정보를 생성할 수 있습니다. 전통적인 PM은 이 5%를 보고 패닉에 빠져 버그처럼 제거하려고 합니다. AI PM은 다릅니다. 이 불확실성을 관리하는 것 자체가 바로 자신의 일이라는 사실을 알고 있습니다.

1) AI 플라이휠(The AI Flywheel)

사용자가 많아질수록 제품이 더 똑똑해지지 않는다면, 그 제품은 시작도 하기 전에 이미 끝난 것입니다. 이를 “AI 플라이휠”이라고 부릅니다. 훌륭한 AI PM은 사용자 상호작용을 어떻게 설계해야 데이터가 수집되고, 그 데이터가 다시 모델로 피드백되어 미래의 상호작용을 개선하고, 복리 효과를 만들어내는지를 알고 있습니다.

화이트보드 앞에서 자신의 제품 AI 플라이휠을 설명할 수 없다면, 당신에게는 AI 전략이 없습니다. 그래서 제 강의의 첫 번째 모듈인 AI와 머신러닝에서는 단순한 용어 정의를 넘어, PM을 위한 AI 플라이휠 개념을 깊이 있게 다룹니다. 우리는 이 루프를 제대로 구축한 기업과 실패한 기업의 실제 사례를 분석합니다.

2) AI 제품 아키텍처 & 데이터 파이프라인

또한 데이터는 이제 인프라의 일부라는 사실을 이해해야 합니다. 당신은 더 이상 UI만 관리하는 PM이 아니라, AI를 먹여 살리는 데이터 파이프라인을 관리하는 사람입니다. 데이터는 어디에서 오는가, 깨끗한가, 편향은 없는가를 알아야 합니다.

일반적인 PM은 데이터 사이언티스트가 데이터가 안 좋다고 불평할 때까지 기다립니다. AI PM은 처음부터 깨끗한 데이터 수집이 가능하도록 제품을 설계합니다. 이 부분을 잘못 설계하면 어떤 고급 알고리즘도 당신을 구해주지 못합니다. 그래서 우리는 강의 초반에 데이터 파이프라인과 AI 아키텍처의 핵심을 다룹니다.

데이터 사이언티스트가 아니어도 “데이터 사이언스 언어”로 말하기

이제 수학 이야기를 해봅시다. AI PM이 되기 위해 다변수 미적분을 알아야 할까요? 아닙니다. 하지만 선형 회귀와 로지스틱 회귀의 차이는 반드시 알아야 합니다. 엔지니어링 팀이 “새 모델을 시도했는데 정확도가 낮아서 출시할 수 없다”고 말했을 때, 약한 PM은 “알겠다, 올라가면 알려달라”고 말합니다. AI PM은 “어떤 지표를 쓰고 있는가, R스퀘어(R-Square)인가, 오버피팅은 아닌가, 피처 선택은 맞는가”라고 묻습니다.

필요할 때 기술적으로 문제를 지적할 수 있는 언어 능력, 그리고 팀이 막혔을 때 방향을 제시할 수 있는 능력이 필요합니다. 기본 알고리즘을 이해하지 못하면 눈을 가린 채 비행기를 조종하는 것과 같습니다. 이 부분이 비기술 배경의 PM에게 가장 위협적이기 때문에, 저는 알고리즘과 케이스 스터디 모듈을 만들었습니다. 수식은 제거하고 직관과 적용에 집중합니다. 선형 회귀, 로지스틱 회귀, 의사결정 트리를 실제 제품 사례로 다룹니다.

그리고 중요한 점은, 이론만 가르치지 않습니다. 실제 사례를 통해 “이 상황에서는 단순 회귀면 충분하다”, “이 문제는 결정 트리가 더 낫다”라는 것을 이해합니다. R스퀘어(R-Square), MLE 같은 지표도 시험을 위해서가 아니라, 제품이 실제 사용자에게 준비됐는지 판단하기 위해 배웁니다.

생성형 AI와 딥다이브

현재 우리는 골드러시의 한가운데에 있습니다. 많은 제품들이 AI를 무분별하게 적용하고 있으며, 그중 대부분은 OpenAI API 위에 얇게 덧붙인 형태에 불과합니다. 처음 시작 단계에서는 이러한 접근에도 문제가 없습니다. 그러나 만약 보유한 역량의 전부가“ChatGPT에 프롬프트를 보낼 수 있다”는 수준이라면, 커리어는 매우 취약해질 수 있습니다. 시장은 단순한 생성형 AI 구현이 쉽게 모방 가능하고 장기적인 경쟁 우위를 만들기 어렵다는 사실을 빠르게 인식하고 있습니다.

최상위 수준의 AI 프로덕트 매니저가 되기 위해서는 대형 언어 모델(LLM) 내부에서 실제로 어떤 일이 일어나고 있는지를 이해할 필요가 있습니다. 그 이유는 모델의 아키텍처를 이해해야만, 모델이 실패하는 원인을 정확히 파악할 수 있기 때문입니다. 생성형 AI 챗봇이 지속적으로 훈련 데이터나 근거에 기반하지 않은 정보를 사실처럼 생성하는 경우, 그 문제가 프롬프트 설계 때문인지, 아니면 *템퍼처(temperature) 설정 때문인지를 구분할 수 있어야 합니다.

*AI 모델이 얼마나 확률적으로 엄격하게 답할지, 아니면 다양하고 창의적으로 답할지를 조절하는 파라미터

생성형 AI 및 프로덕트 매니지먼트모듈에서는 이러한 단순한 설명 수준을 훨씬 넘어섭니다. 신경망과 딥러닝을 깊이 있게 다루며, 생성형 AI 모델이 근본적으로 어떻게 작동하는지를 체계적으로 설명합니다. 모델의 구조를 이해하게 되면, 이를 훨씬 효과적으로 제어할 수 있게 됩니다. 이는 곧 프롬프트 기법과 고급 프롬프트 설계에 대한 심화 학습으로 이어지며, 단순히 “고양이에 대한 블로그 글을 작성해 달라”는 수준을 넘어, 엔터프라이즈 소프트웨어 환경에서 모델이 안정적이고 신뢰성 있게 동작하도록 만드는 복잡한 프롬프트 구조를 설계하는 단계로 나아가게 됩니다.

프로토타이핑 & “바이브 코딩”

이것은 아마도 사고방식에서 가장 중요한 변화일 것입니다. 과거에는 아이디어가 있으면 스펙을 작성해 지라(Jira)에 올리고, 엔지니어가 대략적인 버전을 만들 때까지 3주를 기다리곤 했습니다. AI 세계에서는 속도가 전부입니다. 이제 도구들이 너무 좋아져서 PM이 무기력하게 있을 이유가 없습니다.

새로운 AI 기능에 대한 아이디어가 있다면, 반나절(오후) 안에 직접 프로토타입을 만들 수 있어야 합니다. 직접 손을 더럽히며 해볼 수 있어야 합니다. 프로덕션에 바로 올릴 수 있는 확장 가능한 코드를 작성할 필요는 없지만, 엔지니어링 팀을 불필요하게 방해하기 전에 API들을 연결하고, 파라미터를 조정하고, 아이디어가 실제로 가능한지부터 확인할 수 있어야 합니다.

이는 AI 보조 도구(예: Cursor, GitHub Copilot, 혹은 ChatGPT 자체)를 활용해 개념을 증명할 수 있는 작동하는 프로토타입을 빠르게 뚝딱 만들어내는 능력입니다. 지저분한 지라 티켓 대신 작동하는 프로토타입을 엔지니어에게 보여줄 수 있다면, 관계의 역학이 완전히 달라집니다. 당신은 큰 존중을 얻게 되고, 당신의 기능은 더 빠르게 출시됩니다.

RAG와 에이전트

위의 모든 것을 마스터했다면, 당신은 이미 PM 상위 10%에 들어 있습니다. 하지만 절대적인 최전선에서 일하고 싶다면, 업계가 다음으로 어디로 향하고 있는지 이해해야 합니다. 바로 검색 증강 생성(RAG, Retrieval-Augmented Generation)과 자율 에이전트(Autonomous Agents)입니다.

RAG 시스템

기성(off-the-shelf) LLM의 가장 큰 문제는, 회사의 비공개 데이터를 모른다는 점입니다. 특정 시점까지의 인터넷 정보는 알지만, 당신 회사의 3분기(Q3) 매출 수치나 내부 고객지원 문서 같은 것은 알지 못합니다. RAG는 이 문제를 해결하는 아키텍처입니다. 사용자 질의를 받아 사내(비공개) 데이터베이스에서 관련 정보를 검색한 다음, 그 정보를 AI에 제공하여 정확한 답변을 생성하게 하는 과정입니다. 현재 만들어지고 있는 거의 모든 엔터프라이즈 AI 애플리케이션은 RAG 시스템입니다.

PM으로서 당신은 RAG의 구성요소를 알아야 합니다. 벡터 데이터베이스란 무엇인가요? 검색(retrieval) 과정의 청킹(chunking)은 어떻게 작동하나요?

평가(AI Evals)

당신의 RAG 시스템이 좋은지 어떻게 알 수 있을까요? LLM이 문서를 요약했을 때, 그 요약이 정확한지 어떻게 측정할 수 있을까요? 전통적인 소프트웨어 지표로는 측정할 수 없습니다. 당신에게는 AI Evals가 필요합니다. 이는 AI 모델을 사용해 다른 AI 모델을 채점하는 ‘어두운 예술(dark art)’과 같은 영역입니다. 현재 엔터프라이즈 AI를 배포하는 과정에서 이것이 가장 큰 병목입니다.

에이전트형 워크플로우

단순히 질문에 답하는 것을 넘어, AI는 “일을 하는 것”으로 이동하고 있습니다. 에이전트는 계획을 세우고, 여러 단계를 실행하며, 도구를 사용하고, 사람이 계속 붙잡고 있지 않아도 목표를 달성할 수 있는 AI 시스템입니다. 에이전트를 관리하려면 사용자 경험과 안전 가드 측면에서 완전히 다른 접근이 필요합니다.

AI PM 인터뷰 공략은?

이 모든 스킬을 배울 수는 있지만, 구글, 메타, 혹은 AI 스타트업에서 45분짜리 인터뷰 루프 동안 이를 커뮤니케이션할 수 없다면 의미가 없습니다. AI PM 인터뷰는 일반 PM 인터뷰보다 훨씬 더 어렵습니다. 일반 인터뷰에서는 “시각장애인을 위한 알람 시계를 설계해 보세요”라고 묻습니다. 그러나 AI PM 인터뷰에서는 “GPT 5.0의 성공을 어떻게 측정하겠습니까? 정확한 지표는 무엇이며, 그 이유는 무엇인가요?”라고 묻습니다.

그들은 사용자 페르소나만 묻지 않습니다. 비정형 데이터를 다루고 확률적인 결과를 처리하는 시스템을 설계해 보라고 요구할 것입니다. 그들은 당신이 이론을 지저분한 현실에 적용할 수 있는지 확인하고 싶어 합니다. 많은 뛰어난 PM들이 여기서 실패하는데, 그 이유는 이러한 특정한 질문 스타일을 충분히 연습하지 않았기 때문입니다.

지금 여러분은 어떤 상황인가요? AI PM으로 거듭날 역량이 충분히 준비되어 있나요?

저자 소개
안녕하세요, 샤일레쉬 샤르마(Shailesh Sharma)입니다. 저는 제1원칙 사고(First Principles Thinking)를 활용해 PM과 비즈니스 리더들이 제품, 전략, AI에서 탁월해지도록 돕습니다. 더 많은 정보는 제 AI 프로덕트 매니지먼트 코스, PM 인터뷰 마스터리 코스, Cracking Strategy, 그리고 기타 리소스를 확인해 주세요.

AI 프로덕트 관리 강의 <출처: 원작자>

<원문>

AI Product Manager Skill & Roadmap 2026

]]>

어느 날 AI가 시니어 개발자를 모두 대체한다면

AI 시대, 회사가 시니어 개발자를 채용해야 하는 이유는?

디즈니 영화 ‘월-E’에는 인간 선장과 AI 비서가 지구 귀환을 두고 대립하는 장면이 등장한다. 700년 전 지구를 떠날 때 입력된 정보에 따라, AI는 지구로 돌아가는 것이 여전히 위험하다고 판단한다. 반면, 선장은 지구 탐사 로봇이 가져온 작은 식물을 보고, 이제 지구로 귀환해도 괜찮다고 결정한다. 이 장면은 흔히 경직된 AI 판단과 유연한 인간 판단의 대비로 해석된다.

그런데 만약 AI가 지속적으로 지구의 오염도를 학습해서, 이제 지구에 귀환해야 한다는 판단을 내릴 수 있었다고 가정한다면 어떨까? 그래도 인간 선장이 필요할까? 사실 우주선은 미리 정해진 경로에 따라 자율주행을 하며, 실질적인 업무는 AI 비서가 처리한다. 인간 선장이 하는 일은 거의 없다. 그런데도 선장의 역할을 대대로 인간이 맡아야 했던 것은, 판단할 책임자가 필요했기 때문이다. 만약 지구 귀환이 실패로 끝났다면, 그 선택의 책임은 AI가 아니라 선장이 져야 했을 것이다.

현실에서 우리는 AI에 점점 더 많은 판단과 역할을 위임하고 있다. 몇 년 전, 내가 개발을 시작한 지 얼마 안 됐을 때 코딩을 도와주는 AI가 등장했다. 그리고 얼마 지나지 않아 신입 개발자의 단순한 업무를 보조하는 수준을 넘어서더니, 이제는 구체적인 지시 없이도 하나의 서비스를 구현하고, 사람의 판단을 교정하기도 하는 능력을 갖추었다.

어쩌면 현재 시니어 개발자의 업무 상당 부분을 AI가 대체하는 날이 머지않았을지도 모른다. 최근 고도화된 AI 서비스들은 AI 에이전트들을 여러 개 만들어서 마치 하나의 팀처럼 역할을 부여하고 상황에 따라 적절한 에이전트에게 라우팅하는 방식을 사용한다. 그렇다면 만약에 좀 더 미래에, AI 시니어 에이전트를 만들 수 있다면, 그럼에도 회사는 시니어 개발자를 채용할 이유가 있을까?

나는 이 고민을 토대로, 평소 존경하던 시니어 개발자분들이 AI로 대체되는 상황을 상상해 보았다. 이 글에서는 그 질문을 따라가며, 내가 도달한 결론과 그 이유를 정리해 보고자 한다. 물론 미래는 열려 있기에, 나와 다른 예측을 하는 사람들도 있을 것이다. 내가 미처 생각하지 못한 다른 미래를 상상해 본 분이 있다면, 댓글로 공유해 주셔도 좋을 것 같다.

<출처: ChatGPT 생성>

미리 요점만 콕 집어보면?

디즈니 영화 ‘월-E’의 선장 사례처럼, AI가 판단을 대신하더라도 그 판단의 결과에 대한 책임을 지는 주체로서 인간은 여전히 필요하다.
국내 IT 조직에서 시니어 개발자는 기술 판단뿐 아니라 실패 시 설명과 수습, 신뢰 회복까지 담당하는 책임의 중심에 있는 역할이다.
AI는 판단을 정교하게 내릴 수는 있어도 책임을 자기 문제로 끌어안을 수 없기에, 회사는 여전히 시니어 개발자를 채용해야 한다.

국내 IT 조직 속 시니어의 역할은?

개발 직군에서 시니어는 기술 리더로서의 역할이 먼저 요구된다. 동시에 동료들의 성장을 돕는 역할도 함께 맡는다. 미국에서는 이를 엔지니어 트랙과 매니저 트랙으로 나누어 각각 다른 사람에게 맡기는 경우가 많지만, 한국 IT 조직에서는 많은 경우 ‘팀장’이라는 직함을 가진 한 사람이 두 역할을 함께 수행한다.

이런 구조에서 팀장은 프로젝트의 품질을 관리하는 동시에, 개별 팀원의 성장과 업무 분배에도 관여해야 한다. 권한이 많은 만큼 결정해야 할 일도 많고, 그 결정의 결과에 대한 책임 역시 팀장의 몫으로 귀속된다. 시니어라는 역할은 단순히 기술적 판단을 내리는 위치가 아니라, 그 판단이 실패했을 때 조직 내에서 설명과 수습을 담당해야 하는 자리이기도 하다.

이 지점에서 AI 시니어의 한계가 드러난다. AI는 기술적 판단을 내리는 데에는 충분히 도움을 줄 수 있지만, 그 판단의 결과에 대한 책임을 동일한 방식으로 떠안기는 어렵다. 책임을 진다는 것은 단순히 판단이 틀렸음을 인정하는 것을 넘어, 그로 인해 발생한 손실과 후속 영향을 자신의 역할과 신뢰에 반영하는 것을 의미한다. 급여나 인센티브 조정, 역할 변화, 평가 하락 등은 그 책임이 조직 내에서 가시화되는 대표적인 형태다.

AI는 판단의 결과로 인한 손실이 자기 존재에 귀속되지 않는다. AI에게 법인격(法人格)을 부여하자는 논의도 있지만, 그 법인격에게 책임을 묻는 행위 역시 결국은 인간 이해당사자에게 책임을 되돌리는 구조로 귀결된다. 이런 점에서 AI의 판단은 결과를 산출할 수는 있지만, 책임의 주체가 되기는 어렵다고 보는 편이 더 정확하다.

시니어 개발자의 정의

동료들과 대화해 보면, 단순히 연차가 많다는 이유만으로 시니어라 부르지는 않는다. 상황에 맞게 합리적인 판단을 내리고, 그 결과에 대해 설명하고 감당할 수 있는 개발자, 그리고 동료들이 신뢰하고 조언을 구할 수 있는 사람을 시니어로 인식하는 경우가 많다.

시니어는 보통 팀장이 되어 팀원들에게 업무를 분배하고 코드를 리뷰한다. 팀원들은 하루에도 여러 번 찾아와 현재 상황을 공유하고, 방향성에 대한 조언을 구한다. 경험이 많은 시니어는 많은 문제에 대해 적절한 해법을 제시하지만, 언제나 옳은 판단만을 내리지는 않는다. 중요한 차이는 판단의 정확성 자체가 아니라, 그 판단이 잘못되었을 때 책임을 질 수 있는지에 있다.

이 책임은 판단 이후에 발생하는 설명, 수습, 신뢰 회복까지 포함한다. 이 점에서 시니어의 역할은 단순히 정답을 맞히는 사람이 아니라, 판단의 결과가 조직에 남겼을 흔적을 끝까지 정리하는 사람에 가깝다.

AI 시니어 에이전트와 시니어 개발자: 같은 판단, 다른 책임

내가 존경하는 한 시니어 개발자에게 좋은 판단이 무엇인지 질문한 적이 있다. 그분은 “본인이 감당할 수 있는 선에서만 문제가 생기도록 만드는 것이 좋은 판단”이라고 말했다. 이 말은 판단의 질을 낮추자는 뜻이 아니라, 판단의 결과가 미치는 영향을 함께 고려해야 한다는 의미로 들렸다.

예를 들어, 한 온라인 서비스에서 트래픽 증가에 대비해 캐시 전략을 변경하는 작업을 진행하고 있다고 가정해 보자. 응답 지연이 잦아 성능 개선 요구가 지속적으로 제기되는 상황이다. AI 시니어 에이전트는 과거 트래픽 패턴, 장애 이력, 캐시 히트율 데이터를 분석한 뒤, 캐시 TTL을 늘리고 일부 동적 요청을 캐시 대상으로 포함시키는 것이 합리적이라는 결론을 내린다. 시뮬레이션 결과, 장애 가능성은 낮고 평균 응답 속도는 유의미하게 개선될 것으로 예측된다.

시니어 개발자 역시 같은 데이터와 설계안을 검토한 뒤, 같은 결론에 도달한다. 코드 변경 범위는 제한적이고, 롤백도 가능하며, 과거에도 유사한 설정 변경이 큰 문제를 일으킨 적은 없었다. 결국 AI와 시니어 개발자는 동일한 기술적 판단을 내린다. 캐시 전략을 변경해 배포하는 것이 좋겠다는 것이다.

다만 시니어 개발자는 여기서 한 가지를 더 고려한다.

‘이 판단이 실패했을 때, 그 결과를 어디까지 내가 감당할 수 있는가?’

<출처: ChatGPT 생성>

문제가 발생할 경우 예상되는 최대 피해 규모는 어느 정도인지, 해당 문제를 스스로 통제할 수 있는지, 수습을 위해 필요한 인력과 시간은 얼마나 되는지를 추가로 검토한다. 그 결과 위험이 크다고 판단되면, 작업을 연기하거나 영향을 받는 고객 범위를 제한하는 방식으로 결정을 수정할 수 있다.

이 차이는 사람이 더 현명해서가 아니라, 사람은 판단의 실패로 인해 잃게 되는 것이 있기 때문이다. 같은 근거와 같은 결론에 도달했더라도, 책임이 귀속되는 구조가 다르기 때문에 행동은 달라질 수 있다. AI의 판단을 아무리 정교하게 튜닝하더라도, 그 판단을 전적으로 신뢰하기 어려운 이유는 여기에 있다. AI의 판단은 결과를 산출할 수는 있지만, 그 결과로 발생하는 피해를 자기 문제로 끌어안을 수는 없다. 회사가 AI를 시니어로 고용하기 어려운 이유 역시, 판단 능력의 문제가 아니라 책임의 귀속 구조에 있다.

인간 사회에서는 판단의 실패가 곧 피해로 이어진다. 그렇기 때문에 누군가는 책임을 지고 문제를 사전에 줄여야 하며, 문제가 발생했을 경우에는 설명하고 사과하며 신뢰를 회복해야 한다. 이 역할은 아직까지 AI에게 기대하기 어려운 영역으로 남아 있다.

사람으로서 내가 할 수 있는 역할은?

AI가 점점 더 많은 판단을 대신하게 될수록, 시니어의 역할은 사라지기보다는 오히려 더 분명해진다. 다만 그 역할은 더 많은 코드를 작성하거나, 더 빠르게 문제를 해결하는 방향이 아니라, AI가 만들어낸 판단의 결과를 책임질 수 있는 위치로 이동한다. 시니어의 역할은 그저 AI가 틀리지 않도록 감시하는 것이 아니다. 오히려 AI의 판단을 전제로, 그 판단이 실패했을 때 조직이 감당할 수 있는 범위를 설정하는 일에 가깝다. 무엇을 자동화할지보다, 무엇까지 자동화해도 되는지를 판단하는 것이 중요해진다.

또한 시니어는 책임을 분산시키지 않는 역할을 맡는다. 문제가 발생했을 때 “AI가 그렇게 판단했다”는 말로 상황을 정리할 수는 없다. 누군가는 그 판단을 승인했고, 그 결과를 받아들이기로 했다는 사실을 설명해야 한다. 시니어는 그 설명의 주체가 되며, 판단의 맥락을 공유하고, 잘못이 있었다면 인정하고, 이후의 선택을 다시 해야 한다.

결국 시니어의 역할은 판단 자체보다, 판단 이후의 세계를 정리하는 일에 가깝다. AI가 만들어낸 결과를 조직과 서비스가 감당할 수 있는 형태로 연결하는 완충 지점, 그 자리에 사람이 필요하다.

결론: 시니어 개발자는 필요하다

AI는 앞으로도 더 많은 판단을 대신하고, 더 많은 업무를 수행하게 될 것이다. 시니어 개발자가 하던 일들 중 상당 부분도 AI가 충분히 잘 해낼 수 있을 것이다. 이 흐름을 되돌리거나 부정하는 것은 현실적이지 않다. 그럼에도 불구하고, 회사가 사람을 계속 채용해야 하는 이유는 분명하다. 판단의 결과에 대해 책임질 수 있는 주체가 필요하기 때문이다. 판단이 실패했을 때 손실을 감당하고, 피해를 설명하고, 무너진 신뢰를 회복하는 일은 꽤 오랫동안 사람의 영역에 남아 있을 것이다.

그래서 나는 더 정확한 판단을 내리는 사람이 되기보다는, AI가 만들어낸 판단을 바탕으로 최종 결정을 내리고 그 결과를 책임질 수 있는 시니어가 되어야겠다는 생각을 한다. 무엇을 자동화할지보다, 무엇까지 자동화해도 되는지를 고민하고, 문제가 생겼을 때 한 발 뒤로 물러서지 않고 그 선택을 내가 했다고 말할 수 있는 사람. 그것이 내가 생각하는, 앞으로도 여전히 사람이 시니어로 남아야 하는 이유다.

]]>

사수 없이 ‘대체 불가능한 사람’으로 성장하는 법

혹시 새로운 기능을 배포하기 직전, 배포 버튼 위에서 손가락이 머뭇거린 적 있나요? 주위를 둘러봐도 물어볼 사람은 없는 그런 환경에서요. 대표님은 돈에 관한 이야기만 하고, 동료는 모두 나만큼 바쁩니다. 이럴 때 우리는 처절하게 깨닫습니다.

‘아, 내게는 사수가 없구나.’

많은 주니어 개발자가 사수 없는 환경을 ‘성장의 무덤’이라 이야기합니다. 하지만 정말 사수가 없어서 성장이 멈추는 걸까요?

이 글은 기술적인 숙련도나 업무 능력 그 자체를 키우는 하드 스킬에 관한 이야기가 아닙니다. 그보다는 사수가 없는 야생에서 살아남기 위해 가장 먼저 길러야 할 무기, 바로 의사결정과 비판적 사고라는 소프트 스킬에 집중합니다. 정답이 없는 환경에서 스스로 판단하고 그 근거를 세우는 이 ‘판단의 근육’이야말로, 고립된 주니어를 시니어로 도약하게 만드는 가장 강력한 동력이기 때문입니다.

사수 없는 환경에서도 대체 불가능한 사람으로 성장하도록 하는 소프트 스킬에 대해 이야기해보겠습니다.

<출처: 작가, Gemini로 생성>

미리 요점만 콕 집어보면?

사수 없는 환경의 문제는 지식 부족이 아니라 실패를 감당해 줄 심리적 안전감의 부재에서 시작합니다.
진짜 성장은 정답을 찾는 일보다 트레이드오프를 인식하고 선택 근거와 판단의 기준을 기르는 과정입니다.
의사결정 기록과 비판적 파트너인 AI를 활용하면 사수 없이도 대체 불가능한 리더로 성장할 수 있습니다.

사수가 없다는 것 = ‘공포’의 시작

사수가 있는 환경과 없는 환경의 본질적인 차이는 기술적 지식의 양이 아닙니다. 바로 ‘내 결정이 틀려도 뒤를 봐줄 사람이 있다’라는 심리적 안전감입니다.

우리가 잃어버린 것은 지식이 아닌 ‘심리적 안전감’

만약 사수가 있다면, 그는 내가 짠 코드를 리뷰하며 “이 부분은 이렇게 고치는 게 좋겠어요”라고 말해줄 것입니다. 그 한마디는 단순한 가르침을 넘어 “내가 승인했으니, 문제가 생겨도 네 책임이 아니야”라는 무언의 보호막이 됩니다.

반면 사수가 없는 개발자는 모든 결정을 홀로 감당해야 합니다. 그 결과, 이런 문제들이 생깁니다.

책임의 비대칭: 내 연차에 비해 지나치게 무거운 비즈니스 결정을 내려야 합니다.
피드백의 부재: 내가 잘하고 있는지, 혹은 나쁜 습관을 쌓고 있는지 알 길이 없습니다.
평판에 대한 공포: 나중에 합류할 기업의 실력 있는 누군가가 내 코드를 보고 “도대체 어떤 초보가 이렇게 짰어?”라고 한숨 쉴까 봐 두렵습니다.

결국 우리가 사수 없는 곳에서 성장이 멈췄다고 느끼는 진정한 이유는, 실력이 부족해서가 아니라 ‘실패했을 때의 두려움’이 시도를 가로막기 때문입니다. 지식이 고갈된 것이 아닌 용기가 고갈된 상태에 가까운 것이죠.

성장이란 ‘정답’이 아닌 ‘준거’를 만드는 일

그래서 먼저 알아야 할 것이 있습니다. 우리는 흔히 시니어 개발자라면 정답을 알고 있을 거라고 생각합니다. 그래서 사수가 없으면 정답에 도달할 경로 역시 차단되었다고 믿죠. 하지만 개발의 세계에 완벽한 정답(Silver Bullet)은 존재하지 않습니다.

실제로, 시니어들이 내리는 결정 역시 완벽한 정답은 아닙니다. 그들은 단지 현재 우리 상황에서 가장 적절한 선택을 조금 더 잘할 뿐입니다. 이 과정에서 그들이 사용하는 것은 지식 그 자체가 아니라 상황에 맞는 지식을 골라내는 판단의 기준과 근거입니다.

따라서 우리 역시 성장의 정의를 바꿔야 합니다. 라이브러리 사용법 하나를 더 익히는 것은 기술적 숙련도를 조금 올릴 것뿐입니다. 진정한 성장은 수많은 선택지 중에서 ‘왜 이 선택을 했는가’에 대한 자기만의 논리를 세우는 과정에서 일어납니다.

이런 관점에서 사수가 없다는 것은, 역설적으로 누구의 눈치도 보지 않고 나만의 논리를 실험해 볼 자유로운 환경에 놓였다는 것을 의미하기도 합니다.

공포를 ‘준거’로 바꾸는 연습

이런 흐름에서 제가 제안하고자 하는 해결책은 더 많은 코딩 강의를 듣는 것이 아닙니다. 그 대신, 다음의 세 가지 질문을 스스로에게 던지는 연습을 시작했으면 합니다.

비판적 사고: 이 방식이 최선인가? 만약 아니라면 어떤 트레이드오프(Trade-off)가 있는가?
의사결정의 기록: 나중에 누군가 왜 이렇게 했냐고 물으면, 나는 어떤 논리로 대답할 것인가?
도구의 활용: AI를 단순한 코드 복사기가 아니라, 내 논리를 검증하는 스파링 파트너로 쓸 수 있는가?

사수가 없는 환경은 우리에게서 안락함을 앗아갔지만, 대신 독립적인 의사 결정권이라는 인생 최고의 기본기를 얻을 환경을 줍니다.

그렇다고 모든 것을 마음대로 결정하라는 것은 아닙니다. 그에 앞서 기존의 시니어들은 실제로 무엇을 근거로 선택하는지, 그들의 사고방식을 훔치는 방법을 구체적으로 알아보겠습니다.

시니어는 어떻게 판단할까?

구글에 ~ Best Practice만 한참을 검색해 본 적이 있나요? 아마 대부분 나와는 다른 상황이거나, “상황에 따라 다릅니다”라는 허무한 결론만 나왔을 것입니다. 이럴 때, 사수가 없는 주니어에게 가장 필요한 것은 지식의 양이 아닙니다. 복잡한 상황 속에서 무엇이 ‘최선’인지 골라낼 수 있는 사고의 틀입니다.

<출처: 작가, Gemini로 생성>

기술에 정답은 없다, 오직 ‘트레이드오프’만 있을 뿐

시니어와 주니어의 결정적인 차이는 기술을 대하는 태도에서 나옵니다. 주니어는 가장 좋은 기술을 찾으려 하지만, 시니어는 그보다 먼저 무엇을 포기할지 결정합니다.

모든 기술적 선택에는 얻는 게 있으면 잃는 게 있습니다. 성능을 얻으면 코드 복잡도는 올라가고, 최신 기술을 도입하면 안정성이 흔들립니다. 사수가 있다면 “지금은 성능보다 빠른 배포가 중요하니 이 방식을 쓰자”라며 포기할 지점을 대신 정해주겠지만, 혼자라면 그 판단을 직접 내려야 합니다.

그러니 “나는 무엇을 얻기 위해 무엇을 희생하고 있는가?” 이 질문을 스스로에게 던지는 순간, 당신의 사고는 이미 시니어의 영역에 한 발 들어선 셈입니다.

시니어가 의사결정을 내리는 3가지 핵심 축

그래도 혼자 결정하는 일이 막막하다면, 시니어들이 무의식중에 쓰는 세 가지 기준을 체크리스트로 삼아도 좋습니다.

비즈니스 가치: “지금 이게 돈이 되는가?”

완벽한 아키텍처를 설계하느라 출시가 한 달 늦어지는 것보다, 조금 지저분한 코드로 일주일 만에 출시해 고객의 반응을 확인하는 편이 회사에는 더 큰 가치일 수 있습니다. 이 기능을 구현하는 데 드는 시간 대비, 비즈니스 임팩트가 충분한지 먼저 따져봐야 합니다.

유지보수의 지속성: “6개월 뒤의 내가 이해할 수 있는가?”

사수 없는 환경에서 가장 무서운 적은 ‘미래의 나’입니다. 시니어는 멋진 코드보다 평범해서 읽기 쉬운 코드를 선호합니다. 나중에 합류할 누군가가 이 코드를 보고 30분 안에 구조를 파악할 수 있는지는 중요한 판단 기준입니다.

팀의 역량: “나와 동료가 감당 가능한가?”

아무리 좋은 기술이라도 나 혼자만 알고, 동료들이 따라오지 못한다면 곧 팀의 병목이 됩니다. 특히 주니어만 있는 팀이라면, 가장 화려한 기술보다 모두가 가장 빠르게 익숙해질 수 있는 도구가 오히려 최고의 선택일 수 있습니다.

‘최고의 선택’이 아닌 ‘설명할 수 있는 선택’

“왜 이렇게 하셨나요?”라는 물음에 가장 나쁜 대답은 “블로그에서 이게 좋다고 해서요”입니다. 반대로 가장 좋은 대답은 “A와 B라는 선택지가 있었는데, 우리 상황에서는 C라는 리스크 때문에 A를 선택했습니다”입니다.

사수가 없어도 성장하는 사람들은 결정을 내리기 전에, 짧게라도 의사결정을 시뮬레이션해 봅니다. 가설을 세우고, 스스로 반론을 제기하며, 감당할 수 있는 지점을 찾는 연습을 하죠. 이 사고 과정 자체가 바로 시니어들이 반복해 온 훈련법입니다. 정답이 없는 야생에서 당신을 끝까지 지탱해 주는 힘은 검색 결과가 아니라, 스스로 정교하게 다듬어 온 판단 알고리즘에서 나옵니다.

그렇다면, 이러한 시니어의 사고방식은 어떻게 기를 수 있을까요? 가장 현실적인 2가지 실천법을 정리했습니다.

실천법 1. 나를 지키는 기록의 기술

사수가 없는 상황에서 고군분투해 온 주니어에게 가장 뼈아픈 순간은, 공들여 짠 코드가 타인에 의해 부정당할 때입니다. 새로 합류한 동료가 툭 던진 “이 부분은 왜 이렇게 처리하셨어요? 보통은 이렇게 안 하는데…”라는 한마디가 깊은 내상을 남기죠. 그 당시의 촉박한 일정과 부족했던 리소스는 잊혀진 채, 오직 결과물만으로 평가받기 때문입니다. 이때 우리를 지켜주는 것은 기억이 아닌 기록입니다.

<출처: 작가, Gemini로 생성>

기록하지 않은 결정은 ‘변명’, 기록한 결정은 ‘전략’

우리가 타인의 질문 앞에서 위축되는 이유는 결정을 내렸던 당시의 맥락을 잊어버렸기 때문입니다. 개발자는 하루에도 수십 번씩 선택하기에, 기록하지 않으면 그 근거는 빠르게 휘발됩니다.

기록이 없을 때 할 수 있는 말은 “그게… 그때는 검색해 보니 이게 제일 많이 나와서요…” 정도가 전부입니다. 반면 기록이 있을 때는 “당시 서비스 오픈까지 24시간밖에 남지 않은 상황이었고, 그 인프라 구조에서 가장 리스크가 적은 방식이 이것이었습니다. 가독성은 희생했지만, 안정적인 릴리즈를 우선순위에 둔 결정이었다고 적었네요.”라고 말할 수 있습니다.

기록은 단순히 과거를 증명하기 위한 수단이 아닙니다. 상대방의 비판을 실력 부족이 아니라 당시 상황에서의 합리적 선택이라는 영역으로 옮겨오는 강력한 보호 장치입니다.

‘의사결정 이력’이라는 아주 쉬운 실천법

여기에는 거창한 문서화 양식은 필요 없습니다. 나중에 내가 다시 봐도 이해할 수 있을 만큼만, 중요한 결정을 내릴 때마다 딱 세 가지만 메모장이나 코드 주석에 남겨보세요.

상황(Context): 해결해야 했던 문제와 제약 조건(시간, 비용, 기술력)
결정(Decision): 여러 대안 중 결국 마지막에 선택한 방식
트레이드오프(Trade-off): 이 선택으로 얻은 이득과 감수한 부작용

이렇게 기록해 두면 누군가 당신의 코드를 비판할 때, 당신은 죄인이 아니라 ‘합리적인 판단을 내린 파트너’로서 대화에 참여할 수 있습니다. “맞아요. 그 부분은 리팩토링이 필요합니다. 다만 당시 상황에서는 최선이었습니다. 이제 함께 고쳐볼까요?”라고 말할 수 있죠.

기록은 스스로에게 ‘사수’가 되어주는 일

무엇보다 기록을 남기는 습관은 당신의 비판적 사고를 강제로 단련시킵니다. 기록하다 보면 “잠깐, 내가 왜 이 선택을 하려는 거지? 정말 다른 대안은 없을까?”라고 스스로에게 묻기 때문입니다.

이렇게 기록은 사수가 없는 우리가 스스로에게 해주는 사수 역할이나 마찬가지입니다. 내 결정을 한 걸음 떨어져 객관적으로 바라보고, 막연한 불안을 논리적인 확신으로 바꿔주는 성장의 촉매제가 됩니다.

실천법 2. AI를 사수로 임명하기

우리는 역사상 가장 똑똑하고 친절한 사수를 24시간 곁에 둘 수 있는 시대에 살고 있습니다. 바로 AI 사수죠.

사수가 없는 환경의 주니어들이 가장 흔히 범하는 실수는 AI를 단순한 코드 복사기로만 쓰는 것입니다. AI는 코드를 대신 짜주는 도구가 아니라 당신의 사고를 증폭시켜 줄 디지털 스파링 파트너가 되어야 합니다.

“코드 짜 줘”가 아닌 “내 설계를 비판적으로 판단해 줘”

AI에게 “게시판 기능 만들어줘”라고만 하는 것은 사수에게 “정답만 알려주세요”라고 조르는 것과 다르지 않습니다. 이렇게 얻은 지식은 내 것이 아닙니다. 진정한 성장은 비판을 받아들이고 스스로 문제를 해결하는 과정에서 일어납니다. 앞으로는 AI에게 당신의 생각이나 코드를 먼저 보여주고 이렇게 질문해 보세요.

아래와 같은 방식으로 구현하려고 해. 이 방식의 잠재적인 문제점 3가지만 지적해 줄래?
나중에 사용자가 10배로 늘어난다면, 이 설계에서 가장 먼저 터질 지점은 어디일까?

AI가 내놓을 날카로운 지적은 시니어가 코드 리뷰에서 던질 법한 질문과 매우 닮아 있습니다. 그 지적을 하나씩 방어하고, 더 나은 대안을 찾는 과정에서 당신은 예외 상황을 고려하는 법을 익히게 될 것입니다.

다양한 시니어의 ‘가면’으로 하는 비판

사수가 한 명뿐일 때는 그 사람의 스타일만 배울 수 있습니다. 반면 AI는 수많은 시니어를 연기할 수 있습니다. AI에게 특정한 역할의 가면을 부여해 보세요.

너는 성능 최적화에 미친 10년 차 개발자야. 내 코드에서 1ms라도 줄일 수 있는 부분을 찾아봐.
너는 가독성이 세상에서 가장 중요한 클린 코드 전문가야. 이 코드를 중학생도 이해하게 고치도록 비판해 줘.

이처럼 서로 다른 관점에서 결과물을 검토하다 보면, 특정 방식에 매몰되지 않고 상황에 따라 판단하는 시니어의 시야를 조금씩 갖추게 됩니다.

최종 결정권자는 언제나 ‘나’

AI는 그럴듯한 거짓말을 하거나, 우리 회사의 특수한 상황(예산, 일정 등)을 모른 채 교과서적인 답변만 내놓을 수도 있습니다.

결국 AI가 제안한 여러 선택지에서 무엇을 택할지 결정하고 책임지는 것은 우리의 몫입니다. AI의 조언을 참고하되, 최종 결정을 내리고 그 근거를 기록하는 주체가 ‘나’일 때, 비로소 AI는 당신을 성장시키는 진짜 사수가 됩니다.

마치며: 사수 없는 시간이 만들 ‘대체 불가능한 리더’

사수가 없는 시간은 고통스럽습니다. 하지만 이 시간의 끝에서 우리는 단순히 실력 있는 개발자를 넘어, 자기만의 길을 찾을 수 있는 리더로 거듭날 가능성을 지닙니다.

<출처: 작가, Gemini로 생성>

사수가 있는 환경에서 자란 개발자는 정답을 빠르게 배웁니다. 하지만 그 지식은 종종 사수에게서 빌려온 것에 그치곤 합니다. 반면 혼자서 머리를 쥐어뜯으며 내린 결정과 그로 인해 겪은 처절한 실패는 온전히 우리의 것입니다. 왜 이 방식이 통하지 않는지를 몸으로 겪어본 사람은 비슷한 문제를 마주했을 때 쉽게 흔들리지 않습니다. 사수가 없어 겪었던 모든 고생은 사실 우리 뇌에 ‘대체 불가능한 근육’을 새기는 과정일지도 모릅니다.

이처럼 자신의 선택에 책임을 지는 태도는 리더십의 시작입니다. 이미 주니어 시절부터 사수 없이 시니어의 무게를 견뎌온 사람들의 몸에 배는 태도기도 합니다. 우리도 언젠가 누군가의 사수가 될 것입니다. 그때 당신은 후배에게 단순히 코드를 고쳐주는 사람이 아니라 후배의 불안을 이해하고 그 불안을 논리로 바꿔주는 사람이 될 것입니다. “이 코드가 서비스에 어떤 영향을 줄까?”를 고민하며 배포 버튼을 눌렀던 그 떨림이 바로 리더십의 씨앗입니다. 혼자 기록하고, 고민하고, AI와 논쟁하며 쌓아온 그 ‘오답 노트’가 후배들에게 어떤 교과서보다 값진 이정표가 될 것입니다.

마지막으로, 사수가 없다는 것은 지도가 없다는 뜻입니다. 하지만 지도가 없었기에 우리는 직접 땅을 밟으며 자신만의 길을 걸어올 수 있었습니다. 완벽한 코드를 못 짰다고 자책하지 마세요. 당신이 내려온 모든 결정과 그 근거를 기록해 온 시간 자체가 이미 전문성을 줍니다.

이제 고개를 들어 발자취를 돌아보세요. 이미 충분히 멀리 왔고, 잘 해내고 있습니다. 사수 없는 환경은 안락함을 앗아갔지만, 대신 ‘독립적인 사고’라는 평생의 자산을 남겼습니다. 우리는 이제 정답을 기다리는 사람이 아니라 스스로 길을 만들어가는 개척자가 될 수 있습니다. 모두의 성장을 진심으로 응원합니다.

]]>

개발자에게 ‘신뢰 쌓기’가 중요한 이유

신뢰 쌓는 개발자의 태도: 그 사람이 말하면 왜 고개가 끄덕여질까?

"이번 마이그레이션, A 개발자가 말하는 거니까 믿고 갑시다." 회의실에서 팀장이 던진 이 한마디에 모두가 고개를 끄덕였습니다. 복잡한 데이터베이스 마이그레이션이었지만, 특정 개발자의 말이라는 이유만으로 팀 전체가 안심했죠. 반대로 어떤 개발자는 아무리 좋은 제안을 해도 "정말 괜찮을까?"라는 의구심부터 듭니다.

같은 회사, 비슷한 경력인데 왜 이런 차이가 생길까요? 바로 '신뢰'의 차이입니다. 개발자의 세계에서 신뢰는 단순히 인성의 문제가 아닙니다. 신뢰는 커리어의 가속 페달이자, 팀의 생산성을 좌우하는 핵심 자산입니다. 코드 리뷰에서 빠르게 승인받고, 중요한 프로젝트를 맡게 되며, 의견이 실제로 반영되는 개발자들에게는 공통점이 있습니다. 바로 신뢰를 쌓는 방법을 알고 있다는 것이죠.

미리 요점만 콕 집어보면?

개발자의 세계에서 신뢰는 커리어의 가속 페달이자, 팀의 생산성을 좌우하는 핵심 자산입니다.
과장된 자신감·변명과 책임 회피·말과 행동의 불일치가 반복되면 신뢰는 빠르게 무너집니다.
데드라인 버퍼·투명한 공유·일관된 코드 품질·배포 후 모니터링·“모른다” 인정이 신뢰를 쌓습니다.

신뢰가 개발자 커리어에 미치는 영향

<출처: 픽사베이>

1) 프로젝트 할당의 차이

신뢰받는 개발자에게는 중요한 프로젝트가 자연스럽게 몰립니다. 그 이유는 단순히 “실수를 하지 않을 사람”이기 때문이 아니라, 이 사람이면 끝까지 책임지고 최선을 다할 것이라는 믿음이 있기 때문입니다. 한 개발자는 자신의 블로그에서 “대부분의 협업은 신뢰를 전제로 한다. 이는 동료가 완벽할 것이라는 기대가 아니라, 좋은 의도와 노력을 가지고 문제를 해결하려 할 것이라는 믿음이다”라고 말합니다. 즉, 개발 현장에서의 신뢰란 무오류를 의미하지 않습니다. 오히려 문제가 생겼을 때 도망치지 않고 함께 해결할 사람이라는 확신, 그리고 그 확신이 쌓일수록 더 중요한 일과 책임이 자연스럽게 맡겨지게 됩니다.

신뢰받지 못하는 개발자는 아무리 실력이 좋아도 중요한 의사결정에서 배제됩니다. "저번에도 커뮤니케이션 제대로 안 했잖아", "데드라인 지킨 적이 있어?" 같은 과거의 기록이 발목을 잡습니다. 제가 함께 일했던 두 개발자를 예로 들어보게습니다.

B 개발자는 기술적으로는 평범했지만, 항상 약속을 지키고 투명하게 소통했습니다. 반면, C 개발자는 실력은 뛰어나지만, 예상 기한을 자주 어기고 문제를 늦게 알렸죠. 1년 후, 중요한 차세대 시스템 프로젝트의 리드는 B 개발자에게 맡겨졌습니다. 기술은 배우면 되는데, 신뢰는 좀처럼 변하지 않기 때문입니다.

2) 코드 리뷰의 속도 차이

신뢰받는 개발자의 PR(Pull Request)은 빠르게 승인됩니다. 리뷰어들이 "이 사람 코드는 믿을 수 있어"라는 전제로 접근하기 때문이죠. 같은 팀의 두 개발자를 비교해 보면 차이가 명확합니다. A 개발자의 PR은 평균 2시간 안에 승인되지만, C 개발자의 PR은 이틀씩 걸립니다. 코드 품질의 차이도 있지만, 더 큰 이유는 과거에 쌓인 신뢰의 차이였습니다.

실제로 회사에서도 신뢰도가 높은 개발자의 PR은 간단한 리뷰만으로 승인되지만, 신뢰도가 낮은 개발자의 PR은 리뷰어가 꼼꼼히 확인해야 했습니다. 이는 개발 속도에 직접적인 영향을 미쳤고, 결국 신뢰받는 개발자가 더 많은 기능을 구현할 수 있었죠.

3) 발언권의 차이

기술 회의에서도 신뢰의 차이가 드러납니다. 신뢰받는 개발자가 "이 방식은 위험할 것 같습니다"라고 말하면 팀 전체가 귀 기울입니다. 하지만 신뢰가 없는 개발자가 같은 말을 해도 "정말 그럴까?" 하는 의심부터 받죠. 직접 겪었던 일인데요. 한 개발자가 아키텍처 개선안을 제시했지만 무시당했습니다. 그런데 3개월 후 신뢰가 높은 개발자가 거의 똑같은 제안을 하자 모두가 찬성했죠. 아이디어의 차이가 아니라 신뢰의 차이였습니다. 이 경험 이후, 그 신입 개발자는 작은 약속부터 철저히 지키며 신뢰를 쌓기 시작했습니다.

개발자가 신뢰를 잃는 행동들

<출처: 픽사베이>

1) 과장된 자신감

"이거 30분이면 돼요" -> 3시간 소요
"버그 없을 거예요" -> 배포 후 핫픽스 3회

이런 패턴이 반복되면 신뢰는 빠르게 무너집니다.

한 주니어 개발자는 매번 낙관적인 예상을 했습니다. "간단한 기능이에요, 오늘 오전에 끝나요." 하지만 항상 예상의 3배는 걸렸죠. 6개월 후, 그의 말은 아무도 믿지 않게 되었습니다. 프로젝트 매니저는 그가 "하루면 됩니다"라고 하면 자동으로 일정표에 3일을 배정했습니다.

더 큰 문제는 이런 과장된 자신감이 팀 전체의 계획을 망친다는 점입니다. 예시를 하나 들어보겠습다. 새로운 프로젝트의 신규 기능 출시 일정을 잡았습니다. 담당 개발자는 자신 있게 말했죠. "이번 주 금요일까지 완성하겠습니다. 간단한 CRUD니까 문제없어요." 마케팅팀은 그 날짜에 맞춰 광고를 집행했고, 영업팀은 고객들에게 론칭 소식을 예고했습니다. 하지만 금요일이 되자 개발자는 이렇게 말했습니다. "생각보다 복잡하네요. 다음 주는 필요할 것 같아요." 결국 마케팅 비용은 날아갔고, 고객들에게 사과해야 했습니다.

신뢰받는 개발자는 다르게 말합니다. "기본 구현은 하루면 되지만, 엣지 케이스 처리하고 테스트까지 하면 3일 정도 필요할 것 같습니다." 불확실성을 인정하고, 여유를 두는 것이 오히려 더 프로페셔널한 태도입니다.

2) 변명과 책임 회피

"요구사항이 명확하지 않았어요"
"저는 백엔드 개발자라 프론트 몰라요"
“QA에서 테스트 안 했나요?"

이런 변명은 신뢰를 깎아 먹습니다. 문제가 생겼을 때 가장 먼저 나오는 말이 변명이라면, 그 개발자는 이미 신뢰를 잃고 있는 겁니다. 장애가 발생했을 때 "제 파트가 아닌데요.", "문서에 없었는데요.", "이전 담당자가 그렇게 만들어뒀어요."라며 책임의 경계선을 긋는 행동은 팀 전체의 사기를 떨어뜨립니다.

예시를 들어볼게요. 결제 시스템에 버그가 발생해서 고객들이 불편을 겪고 있습니다. 긴급회의가 소집됐고, 담당 개발자는 이렇게 말했습니다. "기획서에 이 케이스는 명시되지 않았어요. 그리고 QA 단계에서 발견했어야 하는 거 아닌가요? 저는 주어진 요구사항대로만 개발했습니다." 기술적으로는 틀린 말이 아닐 수도 있습니다. 하지만 지금 당장 고객들은 결제를 못 하고 있고, 매출 손실이 발생하고 있었죠.

반대로 신뢰받는 개발자는 이렇게 대응합니다.

"제가 엣지 케이스를 놓쳤습니다. 지금 즉시 핫픽스 작업 시작하겠습니다. 30분 안에 임시 조치 완료하고, 오늘 중으로 근본 원인 해결하겠습니다." 누구의 잘못인지는 나중에 따져도 됩니다. 문제가 생겼을 때 중요한 것은 원인 규명이 아니라 해결입니다.

아마존의 리더십 원칙 중 'Ownership'이 있습니다. "Leaders are owners. They think long term and don't sacrifice long-term value for short-term results. They act on behalf of the entire company. (리더는 오너처럼 행동한다. 장기적인 관점에서 생각하며, 단기 성과를 위해 장기적 가치를 희생하지 않는다. 회사 전체를 대표한다는 책임감으로 판단하고 행동한다.)"

내 파트가 아니더라도, 회사 전체의 문제라면 내 문제로 받아들이는 태도가 진짜 프로입니다. "제 실수입니다. 지금 바로 수정하겠습니다."가 신뢰를 쌓는 말입니다. 변명 대신 해결책을, 책임 회피 대신 주인의식을 보여주는 개발자가 결국 팀의 중심이 됩니다.

3) 일관성 없는 태도

오늘은 열정적으로 일하다가 내일은 무기력하게 대응하는 개발자가 있습니다. 컨디션이나 기분에 따라 코드 품질, 커뮤니케이션 태도, 업무 집중도가 들쑥날쑥합니다. 한 개발자는 관심 있는 프로젝트에는 완벽한 코드를 작성했지만, 유지보수 작업에는 "일단 돌아가게만" 대충 처리했습니다. 코드 리뷰에서도 하루는 친절하게 설명하다가, 다음 날은 "그냥 머지해주세요"라며 피드백을 무시했죠. 6개월 후, 팀원들은 그가 어떤 모드인지 파악하느라 시간을 낭비하게 되었습니다. "오늘은 협조적일까, 아닐까?" 이런 불확실성이 팀 전체의 생산성을 떨어뜨렸습니다.

4) 말과 행동의 불일치

"다음부터는 꼭 테스트 코드 작성하겠습니다"라고 매번 말하지만, 실제로는 한 번도 작성하지 않습니다.
"문서화가 중요하다"고 강조하면서 정작 자신의 코드에는 주석 하나 없습니다.
"협업이 우선이다"라고 말하면서 슬랙 메시지는 며칠씩 무시합니다.

한 시니어 개발자는 팀 회의에서 항상 "코드 리뷰는 24시간 안에 해야 한다"고 강조했습니다. 하지만 정작 자신은 동료의 PR을 일주일씩 방치했죠. 주니어 개발자가 조심스럽게 리뷰를 요청하면 "지금 바쁘니까 나중에"라고 미뤘습니다. 이런 이중 잣대가 반복되자, 팀원들은 그의 말 자체를 신뢰하지 않게 되었습니다. "또 말만 번지르르한 거 아닐까?" 결국 6개월 후 팀 회의에서 그가 새로운 프로세스를 제안했을 때, 아무도 귀 기울이지 않았습니다. 과거의 말과 행동 불일치가 현재의 발언권까지 앗아간 겁니다.

신뢰를 쌓는 구체적인 방법

1) 데드라인과 커밋먼트: "할 수 있다"와 "할 것이다"의 차이

주니어 개발자 시절, 저는 팀장에게 이런 말을 자주 했습니다. "이 기능, 이틀이면 될 것 같아요!" 하지만 실제로는 일주일이 걸렸죠. 예상치 못한 버그, 잘못된 라이브러리 선택, 요구사항 변경... 이유는 다양했지만 결과는 하나였습니다. 신뢰가 깎였습니다.

시니어 개발자가 된 지금, 저는 다르게 말합니다. "이 기능은 최선의 경우 3일, 보통은 5일 정도 걸립니다. 일주일을 주시면 여유 있게 테스트까지 완료하겠습니다." 그리고 5일 만에 완성하면 "예상보다 빨리 끝났네요"라는 평가를 받습니다.

한 선배 개발자의 데드라인을 어기지 않는 비결을 이렇게 설명해 주었습니다. "저는 항상 예상 시간의 1.5배를 요청합니다. 3일이면 될 것 같으면 5일을 달라고 하죠. 그리고 4일 만에 끝내면 모두가 행복합니다." 이 방법이 효과적인 이유는 심리학적으로도 근거가 있습니다. '플래닝 오류(Planning Fallacy)'라는 개념이 있는데, 사람들은 작업 시간을 체계적으로 과소평가하는 경향이 있다는 거죠. 실제 MIT의 한 연구에 따르면, 개발자들은 평균적으로 실제 소요 시간의 60%만 예상한다고 합니다. 그러니 버퍼를 두는 것은 과장이 아니라 현실적인 대응입니다.

실천 방법을 정리하면 이렇습니다. 예상 시간에 50% 버퍼를 추가하세요. 불확실한 요소를 명시하세요. "API 문서가 명확하지 않아서 하루 정도 더 걸릴 수 있습니다"처럼 구체적으로 말하는 겁니다. 그리고 데드라인을 지킬 수 없다면 최대한 빨리 알리세요. 전날 밤이 아니라 3일 전에 말입니다.

2) 투명한 커뮤니케이션: 문제를 숨기지 않기

가장 신뢰받는 개발자는 나쁜 소식도 빠르게 전달합니다. "배포 중 문제가 발견됐습니다. 현재 롤백 진행 중이고, 원인 파악 중입니다"라고 즉시 알립니다. 신뢰받지 못하는 개발자는 문제를 숨기려 합니다. "혼자 해결해 보자"며 시간을 끌다가 상황이 악화되고, 결국 더 큰 문제가 됩니다.

제가 겪은 사례입니다. 데이터베이스 마이그레이션 중 예상치 못한 데이터 손실이 발생했습니다. 당황스러웠지만 즉시 팀에 보고했고, 함께 백업에서 복구했습니다. 팀장은 나중에 이렇게 말했습니다. "문제는 누구에게나 생긴다. 하지만 빨리 알려준 덕분에 피해를 최소화할 수 있었어. 고마워."

반대 사례도 있었습니다. 한 동료는 성능 저하 문제를 발견했지만 혼자 해결하려다 3일을 허비했습니다. 결국 고객 불만이 접수되고 나서야 팀에 공유했죠. 문제 자체보다 숨긴 행동이 더 큰 신뢰 손실을 가져왔습니다. 아마존의 리더십 원칙 중 하나가 'Earn Trust'인데, 그 설명이 인상적입니다. "Leaders listen attentively, speak candidly, and treat others respectfully." 솔직하게 말하는 것(speak candidly)이 신뢰를 얻는 핵심입니다.

투명한 커뮤니케이션의 핵심은 이렇습니다. 문제 발견 즉시 공유하세요. 해결책이 없어도 괜찮습니다. 진행 상황을 정기적으로 업데이트하세요. 그리고 모르는 것은 "모른다"라고 인정하세요. "지금 파악 중입니다. 오후 3시에 다시 보고드리겠습니다."처럼 구체적인 타임라인을 제시하면 더 좋습니다.

3) 일관성 있는 코드 품질: 오늘도 내일도 A급 코드

신뢰는 일관성에서 나옵니다. 가끔 훌륭한 코드를 작성하는 것보다, 항상 준수한 코드를 작성하는 것이 더 신뢰를 쌓습니다. 제가 함께 일했던 한 개발자는 코드 품질이 들쑥날쑥했습니다. 여유로울 때는 깔끔한 코드를 작성했지만, 바쁠 때는 주석도 없고 변수명도 대충인 코드를 작성했죠. 결과적으로 그의 PR은 항상 꼼꼼한 리뷰를 받았습니다. "이번엔 괜찮을까?" 하는 의심 때문이었습니다.

반면, 일관되게 좋은 코드를 작성하는 개발자는 다릅니다. 바쁜 스프린트 기간에도 최소한의 품질 기준을 지켰습니다. 테스트 코드를 작성하고, 변수명을 명확히 했으며, 복잡한 로직에는 주석을 달았죠. 리뷰어들도 그것을 알았습니다. "이 사람 코드는 믿을 수 있어"라는 신뢰가 쌓였습니다.

특히 레거시 코드를 다룰 때 차이가 명확했습니다. 신뢰받는 개발자는 기존 코드를 수정할 때도 일관된 스타일을 유지했습니다. "나중에 리팩토링할게요."라고 말하고 실제로 했죠. 반면 신뢰가 낮은 개발자는 "급해서 일단 이렇게 했어요"라는 말만 반복했습니다. 일관성을 유지하는 실천 방법은 간단합니다. 컨벤션을 지키세요. 린터를 설정해서 자동으로 체크하면 편합니다. 테스트 코드를 작성하세요. 커버리지 80% 이상을 목표로 하면 좋습니다. 코드 리뷰 코멘트를 성실히 반영하세요. 그리고 문서화를 습관화하세요. README, 주석, API 문서 등 미래의 나와 동료를 위한 배려입니다.

4) 코드의 책임감 있는 주인 되기: "제가 만든 기능이니, 모니터링하겠습니다"

배포 후 사라지는 개발자와 끝까지 책임지는 개발자의 차이입니다. 신뢰받는 개발자는 자신의 코드가 운영에서 어떻게 작동하는지 끝까지 확인합니다. 제가 함께 일했던 시니어 개발자는 자신이 작성한 새 기능을 배포한 후, 2주간 매일 아침 모니터링 대시보드를 확인했습니다. 문제가 발생하기 전에 이상 징후를 발견하고 선제적으로 대응했죠. 이런 태도가 팀 전체의 신뢰를 얻었습니다.

한 가지 예시를 들어볼게요. 한 개발자가 새로운 추천 알고리즘을 배포했습니다. 배포는 성공적이었지만, 그는 일주일간 매일 사용자 피드백과 성능 지표를 모니터링했습니다. 4일째 되는 날, 특정 시간대에 응답 속도가 느려지는 패턴을 발견했습니다. 사용자가 불편을 느끼기 전에 캐싱 전략을 개선해서 문제를 해결했죠.

책임감 있는 개발자가 되려면 이렇게 하세요.

배포 후 24시간은 모니터링하세요.
에러 로그를 정기적으로 확인하세요.
장애 발생 시 포스트모템을 작성하고 공유하세요.
"제 코드에서 문제가 생겼습니다. 원인을 분석했고, 재발 방지 대책을 마련했습니다"라고 솔직하게 공유하는 것이 신뢰를 쌓습니다.

5) 겸손하게 인정하기: 최고의 개발자는 자신의 무지를 인정한다

역설적이게도, 가장 신뢰받는 개발자는 "모른다"고 자주 말하는 사람입니다. 왜냐하면 그들은 지식의 한계를 정확히 알고 있기 때문이죠. 코드 리뷰에서 "제 방식이 최선인지 확신이 없습니다. 더 나은 방법이 있다면 제안해 주세요."라고 말하는 개발자가 훨씬 신뢰받습니다. 반면, "이게 업계 표준이고 최선입니다"라고 단정하는 개발자는 의심받습니다.

오래전 기억이라 정확한 출처는 기억나지 않지만, 20년 차 개발자 기술 블로그에 이렇게 쓰인 글을 봤습니다. "저는 20년 경력 개발자지만, 매일 새로운 것을 배웁니다. 제가 모르는 게 더 많다는 걸 압니다." 이런 겸손함이 오히려 신뢰를 높입니다. 겸손한 개발자가 되려면 이렇게 해보세요. 코드 리뷰에서 질문을 환영하세요. 더 나은 방법을 제안받으면 감사하다고 전하세요. 실수를 인정하고 배운 점을 공유하세요. "제가 잘못 이해했네요. 덕분에 배웠습니다."라는 말이 신뢰를 쌓습니다.

신뢰 쌓기는 돼지 저금통

<출처: 픽사베이>

사실 신뢰는 하루아침에 쌓이지 않습니다. 돼지 저금통에 동전을 모으는 저축처럼 조용히 쌓입니다. 작은 약속을 지키고, 투명하게 소통하고, 책임감 있게 행동하는 것이 쌓여서 결국 "저 사람 말은 믿을 수 있어"라는 평판이 됩니다. 기술은 검색할 수 있고, 프레임워크는 공부하면 배울 수 있습니다. 코딩도 AI로 잘할 수 있습니다. 하지만 신뢰는 시간과 일관된 행동으로만 얻을 수 있죠.

신뢰는 쌓는 덴 오랜 시간이 걸리지만, 무너지는 건 한순간입니다. 그러니 지금 당장 실천할 수 있는 것부터 시작하세요. 오늘 약속한 데드라인이 있다면 반드시 지키세요. 문제가 생기면 30분 안에 팀에 알리세요. 코드 리뷰 코멘트에 24시간 안에 응답하세요. 배포 후 하루는 모니터링하세요. 동료의 질문엔 겸손하게 답하세요.

이러한 작은 실천이 쌓여서 "그 사람이 말하면 믿음이 가는" 개발자가 됩니다. 그리고 그 순간, 여러분의 커리어는 한 단계 도약하게 될 겁니다. 여러분이 쌓은 신뢰는 스펙보다 강하고, 학벌보다 오래가며, 기술보다 귀한 자산임을 잊지 마세요.

<참고 문헌>

]]>

이제 막 핵심 인재로 올라선 엔지니어들에게 주는 조언

본문은 유진 얀(Eugene Yan)의 글 <Advice for New Principal Tech ICs (i.e., Notes to Myself)>을 번역한 글입니다. 유진 얀은 아마존의 수석 응용 과학자(Principal Applied Scientist)로, 고객을 위한 대규모 추천 시스템과 AI 경험 관련 내용을 개발하고 있습니다. 필자에게 허락받고 번역과 게재를 진행했습니다.

[일러두기] 이 글은 아마존을 비롯한 글로벌 빅테크의 수석 엔지니어(Principal Engineer) 역할을 염두에 두고 쓰였습니다. 이들은 높은 수준의 능력을 갖춘 개발자로 팀장이 아닌 개인 기여자(IC)로 활동하며 폭넓고 다양한 역할을 수행합니다. 비록 직무 명은 다르지만, 조직의 핵심 인재로 활동하는 국내 개발자에 역시 유용한 조언이 많아 글을 옮겨왔습니다. 그에 따라 국내 상황에 맞춘 의역을 추가했습니다. 이를테면, 원문에는 수석 엔지니어를 비롯해 scientist나 principal tech IC 같은 표현이 등장하지만, 모두 ‘수석 엔지니어’로 통일했습니다.

수석 엔지니어는 어떻게 성과를 낼까요? 이글은 제가 롤 모델로 여긴 엔지니어들을 관찰하며 얻은 지식을 요약한 것으로 일부는 그들의 조언을 인용했습니다. 저의 직장인 아마존 중심으로 관점이 형성되었지만, 이 아이디어들은 수석 엔지니어 역할에 보편적으로 적용될 것입니다. 당연한 말이지만, 이 조언이 여러분과 상황에 맞는지는 스스로 평가하며 최선의 판단을 하세요.

1. 수석 엔지니어들은 저마다 다른 스타일이 있습니다

어떤 사람은 특정 분야에 깊이 파고들고, 어떤 사람은 동료나 타 부서와의 협력에서 영향력을 발휘하는 데 탁월합니다. 어떤 이는 기술적 선구자라 방법을 보여주고, 다른 이는 복잡성을 명확히 하며 앞으로 나아갈 길을 밝힙니다. 또 다른 이는 여러 조직을 하나의 비전으로 정렬시키는 데 능숙합니다. 어느 스타일이 더 중요하다고 할 수 없습니다. 자신의 강점에 맞는 스타일을 찾아야 합니다.

아마존은 수석 엔지니어가 직접 코드를 작성하기를 원합니다. 장기간 동안 코딩 작업에 직접 참여하지 않는 사람은 실패를 자초할 가능성이 큽니다(짧은 기간은 괜찮습니다).

*기울임체로 표기한 영역은 본문의 인용으로, 저자가 밝힌 바와 같이 그가 롤 모델로 여긴 엔지니어들의 조언이나 강조할 표현으로 보면 좋습니다.

2. 앞서 당신의 성공을 이끌던 핵심적인 작업은 이제 부수적인 일이 됩니다

수석 엔지니어 역할을 수행할 때는 직접 코드를 작성하는 것만이 능사가 아닙니다. 물론 코딩 감각을 유지하기 위해 여전히 코드를 작성해야 하지만, 이제는 기술 비전, 설계 피드백, 후원, 비즈니스, 제품, 기술 컨텍스트 제공, 문제 발견, 연결 고리 만들기 같은 일이 핵심적인 역할입니다.

L7 이상 역할*에서는 흔히 듣는 말입니다. 코딩 시간을 줄이라는 뜻이 아니라, 80% 시간을 여전히 코딩에 할애한다고 해도 모두가 더 효과적으로 일하도록 하는 것이 가장 영향력을 끼칠 수 있는 방법입니다. 한 프로젝트만 보고 코딩만 파고들거나 혼자 완벽하게 다듬는 데 집중하던 사고방식이 바뀝니다. 이제 모든 개발자가 여러 프로젝트에서 더 잘 만들 수 있도록 영향을 주는 쪽으로요. 저장소에 고품질 코드로 기여해 읽기 좋은 코드로 소통을 원활하게 하거나, 설계 제안 피드백, 기술 가이드 작성, 장기 비전 추진과 같이 분명하게 더 효과적인 활동을 할 수도 있습니다.

*L7(Level 7) 이상 역할: 주로 대형 IT 기업이나 테크 기업에서 사용하는 직급 체계의 ‘L7 이상’에 해당하는 고위급 기술 개인 기여자(Technical IC) 또는 관리자급 역할을 의미합니다.

3. 당신은 기술 분야의 파트타임 PM 같은 존재입니다

더 정확히 말하면, 제품, 디자인, 엔지니어링, 과학, 품질 보증, 채용, 금융, 문화와 같은 모든 분야를 고루 다뤄야 한다는 의미에서 파트타임 PM과 같습니다. 이들 가운데 당신 일이 아닌 것은 없습니다. 뛰어난 판단력으로 자신의 전문 범위를 넘어서 활동할 수 있습니다.

4. 더 많은 커뮤니케이션, 영향력, 적절한 사람들을 연결하는 역할입니다

여러분이 맡을 프로젝트는 범위가 넓고, 이사급, 부사장급을 넘나드는 팀들이 관여합니다. 이런 종류의 프로젝트는 효과적인 업무 조정과 협력이 없으면 성공할 수 없습니다. 또한, 고객에게 조직 구조에 따른 업무의 차이를 그대로 보여주지 않도록 주의를 기울여야 합니다.

5. 옳은 것만으로는 절반도 못 이깁니다

다른 사람을 설득하고, 그들이 움직일 만큼 관심을 갖게 해야 합니다. 추진력을 만드는 법, 아이디어를 후원할 사람, 마무리하는 방식을 찾아야 합니다.

때로는 프로젝트를 시작하고 가치를 보여주어야 이런 것들을 얻을 수 있습니다. 수석이 솔선하여 모범을 보이고, 사람들이 결정을 기다리는 대신 능동적으로 문제 해결에 나서길 지원합니다.

수석은 결정권을 쥔 자리라고 말할 수 있습니다. 누구를 기다리나요 :)

6. 조직이 관심 없던 것을 가치 있게 여기도록 가르치는 일은 중요한 부분입니다

여러분이 상대할 사람들은 임원부터 현장의 실무 개발자까지 다양합니다. 가장 어려운 작업인 동시에 실패하기 쉽지만, 미래를 볼 수 있는 넓은 시각을 가진 사람으로서 해야 할 일입니다. 제 멘토는 “자신이 제안한 10개의 문서 중 3개 정도만 실행돼도 좋은 결과”라고 말했습니다.

일상적 업무가 많고 팀 단위로 일하며, 즉각적 과제에 더 집중하는 개인 개발자와 달리, L7 이상 역할은 한발 물러나 회사의 더 넓고 장기적인 관점을 볼 여유가 있습니다. 그래서 보다 객관적으로 영향력을 판단할 수 있는 수준에서 기여하는 것이 가장 큰 가치를 만듭니다. 수석 없이 그러한 일들이 일어날 수는 없습니다.

7. 당신 없이는 절대 일어나지 않는 일들이 있습니다

보통 당신이 정말 특별히 중요하게 취급해야 할 교차점이 있습니다. 빠른 프로토타입 제작 같은 일, 새로운 고객 경험을 전파하는데 리더십을 발휘하는 일, 그리고 조직과 조직 사이 또는 업계 실무자 사이에 다리를 놓는 일, 또는 3개년 비전 수립 등 일입니다. 이런 종류의 일에 집중하세요. 경력이 쌓이면 당신만이 할 수 있는 일이 점점 깊고 좁아질 것입니다.

8. 때론, 연결 고리 역할만 하는 것이 가장 가치 있는 일이 되기도 합니다

여기에는 어떤 일을 새로 해보려는 팀을 그 일을 해본 팀과 연결시켜서 코드를 재사용하거나 경험을 나눌 수 있게 하는 것도 포함됩니다. 또한 그 일을 할 수 있거나 성장할 수 있는 적합한 사람을 찾는 것도 마찬가지입니다.

9. 혼자 할 수 있는 일은 제한적입니다

일부 업무 시간을 다른 사람들을 코칭하고 멘토링하여 효과를 내는 데 쓰는 것이 조직에 더 유익합니다. 매주 몇 시간씩 멘토링 시간을 갖거나 육성하려는 사람들과 정기적으로 소통할 시간을 마련하세요. 한두 명의 실무 개발자를 육성 대상으로 정하고 그들을 돕기 위한 목표를 세우세요.

핵심은 위임을 통해 조직을 성장시키는 것입니다. 조직 자체가 수석 엔지니어와 같은 결정을 내린다면 수석 엔지니어는 성공한 것이라 할 수 있습니다. 그렇게 되면 수석 엔지니어는 다른 모호한 문제에 나설 테고, 이것이 조직 문화로 자리한다면 올바른 결과에 이를 수 있습니다.

모든 사람을 돕고 싶겠지만, 장기적으로 당신 자리를 대신할 수 있는 사람을 키우는 데 에너지를 집중해야 합니다. 모두가 그런 능력이 있는 건 아니므로, 잠재력 있는 사람에게 시간을 집중적으로 투자하고, 그들이 다시 잠재력이 낮은 사람을 돕도록 하는 식입니다.

10. 다른 사람이 단순한 참여를 넘어 그 일을 자신의 일로 여기게 하세요

자신의 성장 경로에 큰 공헌을 한 일을 누군가에게 맡겨 성장 기회로 삼고, 그들이 성공할 수 있도록 지원하세요. 자신의 일이 사라질까 걱정하지 않아도 좋습니다. 고객을 위한 중요한 문제와 흥미로운 기회는 끊임없이 쌓여 있습니다.

사람들과 주 1~2시간을 함께 보내며, 선임 소프트웨어 개발자*가 당신의 통찰 아래 40시간의 가치를 낼 수 있게 하는 것이 수석 엔지니어의 진정한 확장 역량이라고 말합니다.

*원문에는 Sr. SDE로 표현된 직급입니다. 아마존, 마이크로소프트 같은 글로벌 기업에서 SDE(Level 4~6) 직급 체계 중 L6에 해당하는 주니어를 넘는 시니어급 개발자가 Sr SDE이며, 팀 내에서 기술 리더 역할을 수행하고 복잡한 문제를 다룹니다.

11. 일을 넘겨주면 이제 그 일은 그들의 일이 됩니다

맥락을 짚어 주고 지침은 줄 수 있지만, 최종적인 향방은 수행할 사람 스스로 정해야 합니다. 당신이 선택하지 않을 방식을 그들이 택해도 이를 내버려두는 것 역시 포함됩니다. 결과가 좋지 않아도 그걸 통해 배우고 나아갈 수 있다면 그것으로부터 당신도 배웁니다. 물론 돌이킬 수 없는 잘못된 결정으로 높은 위험에 빠지게 될 때는 개입이 필요합니다.

12. 회의에서 다른 사람들이 의견을 낼 여지를 만드세요

때때로 모두가 가장 고참에게 의견을 묻는데, 당신은 고참이 아닌 사람들에게 질문을 던져 발언 기회를 줄 수 있습니다. 또한, 논의에 참여하지 않는 사람이 있으면, 그 사람의 강점에 맞는 주제로 부드럽게 끌어들이세요. 때로 논의에 꼭 있어야 할 사람이 빠졌다면 다음 회의에 반드시 초대하세요.

13. 매번 가치를 드러낼 필요는 없습니다

제가 만난 가장 효과적인 수석 중에는 회의 내내 조용히 있거나 문서 검토 과정에서 거의 코멘트를 남기지 않는 이들도 있습니다. 팀에서 논의가 잘 돌아가면, 한 걸음 물러서서 다른 곳에 집중해도 괜찮다는 의미입니다.

하지만, 자리에 참석한 다음 침묵하고 있으면 암묵적 승인으로 보일 수 있으니 주의하세요. 한 번에 여러 가지 일을 다룰 때면 주의하세요. 당신의 존재가 무엇을 의미하는지 잘 생각해야 합니다.

14. 임원 회의에서 모든 안건을 다룰 필요는 없습니다

임원들이 주제에 관심을 보이고, 의미 있는 질문을 하며, 그들만이 할 수 있는 의사결정을 내리거나 장애물을 제거해 줄 수 있다면 그것만으로 좋은 회의입니다.

15. 주의: 역할이 넓어지면 근무시간이 빈틈없이 채워질 수 있습니다

리뷰, 상향 보고, 이메일, 도움 요청 같은 일들이 업무로 들어옵니다. ‘1순위 연락처’가 되는 것이야 좋은 일이지만, 근무 기간이 길어질 정도면 상황이 심각해집니다. 결과적으로 모든 회의에 필수 참석자가 될 수 있으니 시간을 아끼고 거절하는 법을 배워야 진짜 중요한 아이디어에 집중할 시간이 생깁니다. 모든 회의에 출석하거나 모든 아이디어에 의견 낼 필요 없이, 중요한 것에만 집중하세요.

특히 제 멘토가 알려준 중요한 한 가지는 생각할 시간이 필요하다는 것입니다. 끊임없이 회의에서 회의로 옮겨 다니면 생각을 정리하거나 앞을 내다볼 수 없습니다. 회의에서 떨어져 충분히 생각할 시간을 마련해야 다음에 주목받을 주요 이슈를 찾을 수 있습니다.

이를 위해서는 위임하는 법을 배워야 합니다. 누군가를 지정해서 당신의 시간을 확보하고, 그 사람에게 성장을 위한 기회를 주는 게 좋습니다.

16. 왜 스스로가 필요한지 설명할 수 없다면, 잘못된 일을 하고 있을지도 모릅니다

이것은 다른 중요한 역할에도 적용될 수 있습니다.

17. 지위 덕분에 비교적 적은 노력으로 결과를 크게 향상시킬 수 있습니다

핵심 개발자라는 직함은 조직 내 특권을 부여해 더 많은 관계와 상황에 대한 접근을 가능하게 합니다. 이러한 지위가 경험과 합쳐지면 앞을 더 잘 내다볼 수 있게 합니다. 그렇게 적은 노력으로 프로젝트 성공과 결과를 현저히 개선할 수 있습니다. 높은 투자 대비 수익이 나는 일므로, 이런 기회를 발견하면 행동으로 옮기세요.

18. 때로는 직함이 원치 않는 아우라를 부여하기도 합니다

낯선 사람은 당신이 툭 던진 말도 과대 해석할 수 있습니다. 그래서 당신이 무심히 한 말 하나 때문에 누군가 많은 일을 해야할 수 있습니다. 그들이 시간과 노력을 낭비할 수 있으니, 알고 있는 것과 모르는 것, 요청하는 것과 단순 의견인 것을 명확히 하세요.

19. ‘무엇’을 하지 말라고 할 때는, ‘왜’ 그렇게 생각하는지도 공유하세요

더 나은 결정에 도움이 됩니다. “모 수석이 이렇게 말했으니 따라야 한다”라며 다른 이들이 이유도 모르고, 그대로 따라 하는 걸 줄입니다.

L7 수준의 의견이 필요한 문제는 보통 상당히 불확실한 일에 대한 의사결정이 필요합니다. 이때 가장 중요하지만 어려운 것은 당신의 사고방식을 설명하는 것입니다. 어떻게 불완전한 정보만으로 새로운 판단에 도달했는지, 왜 특정 지식이 다른 데이터보다 중요한지 설명하는 일입니다.

20. 팀과 지속적으로 소통하는 방법을 찾으세요

디자인 리뷰, 주간 데모, 근처에 앉아 듣기, 함께 점심 먹기, 복도에서 하는 가벼운 대화 같은 것이 될 수 있습니다. 조직의 현황과 주요 문제/기회를 파악하는 데 도움이 됩니다.

21. 팀이 큰 그림을 잃지 않도록 돕습니다

실무진이 일상에 몰두하다 보면 장기적 문제와 기회를 놓치고 눈앞의 일에만 갇힐 수 있습니다. 당신이 보는 맥락을 팀원들에게 상기시켜야 합니다.

22. 다만 실용성을 떠올리며, 큰 그림과 당장의 해결책을 균형 있게 수용하세요

세부 사항은 실무진과 상의하고 의견을 경청하세요. 그들이 현장의 전문가입니다.

23. 고작 1, 2시간 정도만 겪어본 사람에 대한 리뷰나 승진 평가 요청을 받을 것입니다

전체 행동을 충분히 보지 못한 상태에서 부실한 의견을 주기보다는 거절하는 것도 괜찮습니다.

24. 인턴, 그리고 그들의 멘토와 교류할 시간을 만드세요

초기 점검, 데모데이 참석처럼 인턴 기간 개발자와의 몇 차례 만남은 무언가 큰 변화를 만들지도 모릅니다. 또 단순 인턴십을 넘어 누군가 프로젝트를 이어갈 수 있는 산출물을 만들도록 멘토, 인턴과 협력하세요. 산출물은 작동하는 소프트웨어는 물론 제품 요약 보고서나 기술 문서가 될 수 있습니다.

25. 수석이 되려면 핵심적인 역할을 해야 하지만, 효과적으로 수석 역할을 수행하고 더 나아가려면 스스로 그 역할에서 벗어나야 합니다

이전에 ‘1순위 연락처’였다면 이제는 주변에서 지원하는 역할로 전환해야 합니다. 조직은 점점 당신에게서 이익을 얻게 되지만, 당신 없이도 작동하는 상태가 되어야 합니다. 당신이 했던 기여를 다른 사람이 할 수 있도록 힘을 실어주는 방법을 고민하세요.

프로젝트의 핵심 영역에 개입하는 것에 유의하세요. 다른 우선순위에 집중이 빼앗길 수 있습니다. 핵심 역할을 맡고 있다면 엄격히 관리해야 합니다.

26. 승진했다면, 이미 그에 준하는 역할을 일정 기간 해왔다는 것입니다

보통 1년 이상 그에 준하는 일을 해 온 것입니다. 직함에 따른 기대를 걱정하지 마세요. 지금 하던 대로 계속 유지하고, 다른 직급들과 소통하며, 자신만의 스타일을 찾고, 직속 상사와 함께 집중할 분야를 정하세요.

27. 큰 자유에는 큰 책임이 따릅니다

무엇을 할지 자율권이 생기지만 책임과 영향력을 기대받습니다. 자유란 원하는 것을 하는 것이 아니라, 가장 영향력 큰 문제를 찾아 해결하는 주인의식을 말합니다. 지시받거나 안내받길 기대하지 마세요. 조직이 집중할 일을 스스로 찾아야 합니다.

28. 직속 상사와 당신의 역할을 정의하고 맞추세요

한 가지 방법은 일을 ①컨설턴트 ②후원자 ③책임자 관점으로 나누는 것입니다.

컨설턴트는 리뷰에 참여하고 가이드를 제공하며, 시스템이나 제품의 의도를 고수준에서 이해합니다. 후원자는 여기에 더해 아이디어를 조직의 우선순위로 만들고 정렬하며 의사결정을 주도할뿐더러 이해관계자와 소통합니다. 마지막으로 책임자는 위 모두에 더해 시스템 전문가이자 연락처 1순위이며, 설계, 실행, 성공에 집착 수준의 관심을 둡니다. 저는 1~2개 프로젝트를 주로 책임지고(50% 이상), 2~3개를 후원하며(약 20%), 나머지 시간에는 컨설팅합니다.

29. 핵심 인재는 외로울 수 있습니다

모든 팀의 일원이면서도 어느 팀에도 완전히 속하지 않은 상태입니다. 자유롭게 대화할 수 있는 동료 네트워크를 만드세요. 같은 회사나 분야인지 여부는 크게 중요하지 않습니다.

30. 자신의 욕구를 소홀히 하지 마세요

학습, 성장, 웰빙을 지원하는 프로젝트에 시간과 공간을 마련하세요. 그때 잠시는 이기적으로 느껴질 수 있으나, 번아웃 되는 것보단 훨씬 낫습니다. 건강하고 행복하게 성장할 수 있는 일을 찾으면 조직도 혜택을 볼 만큼 영향력을 유지하기도 쉽습니다. 관리자와 이 균형을 맞추는 법을 상의하세요.

31. 끊임없이 배우세요. 업계는 빠르게 변합니다

아무것도 배우지 못하거나 일과 관련 없는 일만 한다면 퇴보하는 것입니다. 때로는 그런 일을 맡는 것이 불가피하지만, 그런 프로젝트는 기간을 제한하세요. 또 배움이 반드시 직장 내에서만 올 필요는 없습니다. 저는 주말에 논문이나 기술 서적 읽고 프로토타입을 만들며 신기술과 아이디어를 이해하는 수석 엔지니어들을 잘 압니다.

]]>

회의 시간에 딴소리하는 팀원, 고칠 수 있을까요?

개발팀의 시간은 곧 비용입니다. 우리는 복잡한 로직을 구현하고 견고한 아키텍처를 설계하기 위해 시간을 쪼개어 집중해야만 합니다. 그런데, 이 귀중한 시간이 의미 없이 사라지는 경우가 있습니다. 바로 준비되지 않은 회의입니다.

흔히 마주할 수 있는 상황을 생각해 봅시다. 다음 스프린트의 핵심 기능인 ‘결제 모듈의 트랜잭션 롤백 전략’을 결정하기 위한 회의가 열렸습니다. 돈이 오가는 문제인 만큼, 데이터 정합성을 어떻게 맞출지가 중요합니다. 그렇게 개발자 A가 화이트보드에 케이스를 그리며 열심히 설명하고 있었습니다.

한창 열심히 설명하고 있을 무렵, 구석에 있던 팀원 B가 손을 듭니다.

“그런데, 결제 실패했을 때 유저한테 보내는 알림톡 문구는 정해졌나요? 지난번에 마케팅팀이랑 알림톡 템플릿 비용 때문에 이슈 있었잖아요. 트랜잭션 실패하면 알림톡이 두 번 발송될 수도 있는데, 비용 처리는 어떻게 하죠?”

<출처: 작가, OpenArt로 생성>

순간 회의실에 정적이 흐릅니다. 조금 전까지 논의하던 DB 데이터 정합성이라는 핵심 맥락은 끊어졌고, 사람들의 머릿속에는 갑자기 마케팅팀과의 비용 이슈와 알림톡 발송 정책만이 떠오르기 시작합니다. 주최자인 개발자 A는 당황합니다.

‘아니, 알림톡 비용도 중요하긴 하지만… 지금은 DB 설계를 결정해야 하는 시간인데…’

결국 참가자들은 DB 트랜잭션과 알림톡 비용 사이를 오가다 귀중한 30분을 허비합니다. 시계를 보니 회의 종료까지 남은 시간은 단 5분입니다. 마음이 급해진 주최자는 결국 쫓기듯 회의를 종료하기 위한 결정을 내립니다.

“음… 시간이 없네요. 트랜잭션 처리는 일단 가장 익숙한 A 방식으로 갈까요?”

치열하게 고민해야 했을 중요한 기술적 의사결정을 시간에 쫓겨 급하게 처리해 버린 것입니다. 회의실을 나서는 팀원들의 표정에는 개운치 않은 찜찜함만 남았습니다. 이런 일이 반복될 때 우리는 흔히 팀원 B를 탓합니다.

“쟤는 왜 저렇게 눈치가 없지? 왜 자꾸 딴소리로 회의를 망치지?”

하지만 여러 회의를 겪으며, 제가 찾은 원인은 다른 데 있었습니다. 회의 중 발생하는 딴소리는 그 팀원의 무능이나 무질서 때문만이 아니라 ‘회의 시스템의 결함’으로 발생한 문제입니다.

소프트웨어에 버그가 발생하면 코드를 수정하듯, 회의 중에 딴소리라는 버그가 생기면 ‘회의 시스템’을 수정해야 합니다. 그 수정 설계의 핵심에는 ‘무엇을(What), 왜(Why), 어떻게(How)’라는 3가지 필수 요소가 있죠. 하나라도 부족하다면 누군가 딴소리를 할 수 있는 여지가 생깁니다.

딴소리가 불러오는 ‘기술 부채’

회의에서 흘러나오는 딴소리는 단순히 “말이 좀 많네” 하고 넘길 문제가 아닙니다. 회의가 주제를 이탈하는 순간, 팀의 생산성에는 치명적인 세 가지 악영향이 발생합니다.

<출처: 작가, OpenArt로 생성>

첫째, 잘못된 의사결정을 유발합니다

방금 예시를 다시 떠올려 볼까요? 트랜잭션 롤백 전략은 시스템 안정성과 직결되는 문제입니다. 하지만 딴소리로 인해 충분한 토론 없이 “시간 없으니 익숙한 A 방식으로 하자”는 결정이 내려졌습니다. 이렇게 급하게 내린 판단은 장애로 이어지거나, 결국 코드를 다시 뜯어고쳐야 할지도 모를 ‘기술 부채’로 되돌아옵니다.

둘째, ‘회의 혐오’를 만듭니다

“우리 팀 회의는 들어가 봤자 시간만 낭비해.”라는 인식이 퍼지기 시작합니다. 개발자들은 회의를 일을 방해하는 요소로 받아들이고, 회의실에 들어올 때부터 방어적인 태도를 보이거나 아예 입을 닫아버립니다. 그렇게 팀원들의 참여는 점점 줄고, 주최자만 말하는 죽은 회의가 되어버립니다.

셋째, 우선순위의 혼란을 줍니다

가장 위험한 부작용입니다. 만약 딴소리하는 팀원의 목소리가 크면 어떨까요? 그가 꺼낸 알림톡 비용이란 이슈가 정작 회사에 더 중요한 결제 데이터 정합성보다 시급한 문제처럼 보이며 혼란을 주기 시작합니다. 팀의 리소스가 엉뚱한 방향으로 새어 나가는 출발점이 바로 여기입니다.

성공적인 회의를 위한 3가지 설계 요소

그렇다면 어떻게 해야 할까요? 회의 진행자가 말을 잘해서 흐름을 통제하는 데에는 분명 한계가 있습니다. 그래서 필요한 것은 회의 설계도입니다. 좋은 회의는 시작부터 다음 3가지 요소가 완벽하게 제공된 상태여야 합니다.

만약 스스로 주최한 회의에서 딴소리가 끊이지 않는다면, 팀원을 탓하기 전에 먼저 생각해 봐야 합니다.

‘나는 회의의 3가지 핵심 요소를 시작 전에 완벽하게 전달했을까?’

<출처: 작가, OpenArt로 생성>

무엇을(What): 이 회의의 최종 목표는 무엇인가? 정보 공유인가, 아이디어 발산인가, 아니면 의사결정인가?
왜(Why): 이 안건을 왜 지금 논의해야 하는가? 이 논의의 비즈니스 가치와 긴급성은 어떤가?
어떻게(How): 우리는 어떤 규칙으로 논의할 것인가? 시간 배분과 발언권, 이탈 방지책은 무엇인가?

What & How: 회의의 좌표와 경로 찍기

회의 주최자가 회의실에 들어와 가장 먼저 해야 할 일은 무엇일까요? 바로 좌표와 경로를 찍는 것입니다.

딴소리가 난무하는 회의의 90%는 참석자들이 ‘우리가 지금 어디로 가고 있는지(What)’를 모르거나, ‘어떤 도로를 타고 갈지(How)’ 합의하지 않았기 때문에 발생합니다. 내비게이션 없이 운전대를 잡으면 운전자는 결국 잘 아는 길, 즉 자기 관심사로만 핸들을 꺾습니다.

What “오늘 우리는 무엇을 결정합니까?”

회의 주최자들은 회의를 초대하며 ‘주간 개발 회의’, ‘아키텍처 논의’처럼 모호한 제목을 적곤 합니다. 하지만, 이는 시작부터 팀원들에게 “와서 아무 말이나 하세요”라고 판을 깔아주는 것과 다르지 않습니다.

목표(What)가 불분명하면 사람들은 본능적으로 자신이 가장 잘 아는 주제, 혹은 가장 걱정하는 문제를 꺼냅니다. 앞선 예시에서 팀원 B가 갑자기 알림톡 비용을 이야기한 것도, 그에게는 그것이 가장 시급한 문제였기 때문일 겁니다. 이는 회의의 목표가 DB 트랜잭션 설계 결정이라는 점이 명확히 인지되지 않아서 생긴 상황입니다.

물리적으로 목표를 시각화하기

말로만 전달한 목표는 공기 중으로 흩어지기 쉽습니다. 눈에 보이게 만드세요.

가장 좋은 것은 회의실에 들어가자마자 보드 맨 윗줄에 ‘한 가지 목표’를 적으며 회의를 시작하는 것입니다. 이 목표 역시 구체적이어야 합니다.

나쁜 예: 결제 시스템 회의
좋은 예: 신규 결제 모듈 트랜잭션 롤백 전략 결정(API vs Queue)

회의에 초대하거나 회의록을 작성할 때도 마찬가지입니다. 문서 최상단에 헤드라인으로 ‘의사결정 필요’ 섹션을 만들어 두세요.

이렇게 What이 시각화되어 있으면, 딴소리를 제어하기 훨씬 쉬워집니다. 누군가 엉뚱한 이야기를 시작할 때, 이제는 감정을 섞을 필요가 없습니다. 그저 화이트보드에 적힌 목표를 가리키며 이렇게 말하면 됩니다.

“B 님, 비용 문제도 중요하지만, 지금 말한 것이 저기 적힌 ‘트랜잭션 롤백 전략 결정’에 당장 필요한 내용일까요?”

한마디면 충분합니다. 팀원 모두 “아, 지금 주제가 아니구나”라고 깨닫고, 자연스럽게 원래 논의로 돌아올 겁니다.

How “우리는 어떤 규칙으로 논의합니까?”

목표(What)가 ‘도착지’라면, 규칙(How)은 ‘교통 신호’입니다. 신호등이 없는 교차로를 떠올려 보세요. 목소리 큰 차가 먼저 지나가고, 눈치 빠른 차가 마구 끼어들면, 결국 병목 현상에 도로는 꽉 막혀버릴 것입니다.

회의도 다르지 않습니다. 발언권을 독점하는 사람, 꼬리에 꼬리를 무는 논쟁, 주제를 벗어난 아이디어 발산까지. 이런 혼란의 대부분은 How를 정의하지 않아 발생합니다.

회의 안건별 데드라인 설정하기

개발자들에게 민감한 데드라인을 회의 안건에도 심어보세요.

“1번 안건인 ‘롤백 시나리오 리뷰’에는 딱 15분 쓰겠습니다. 15분 안에 결론이 안 나면, 추가 미팅을 잡거나 주최자가 결정하겠습니다.”

타이머를 화면에 띄워두는 것도 좋은 방법입니다. 시간이 줄어드는 모습이 눈에 보이면, 사람들은 딴소리할 여유를 잃고 자연스럽게 핵심에 집중하게 됩니다.

회의 안건이 아닌 중요한 것을 모으기

딴소리를 제어하는 가장 강력하면서도 세련된 방식입니다. 회의 중 누군가 주제와 직접 관련은 없지만, 중요한 이야기(또는 그 사람이 중요하다고 믿는 이야기)를 꺼냈을 때 무조건 자르지는 마세요. 무시당했다고 느낀 팀원이 입을 닫아버리거나 오히려 반발심을 가질 수 있습니다.

그럴 때는 화이트보드 한쪽에 나중에 논의라는 공간을 만들고 활용해도 좋습니다. 이런 말과 함께요.

인정: B 님, 알림톡 비용 이슈는 운영 관점에서 정말 중요한 문제네요.
저장: 하지만 오늘 안건(DB 설계)과는 거리가 있으니, 여기 ‘나중에 논의’ 영역에 적어두겠습니다.
약속: 회의가 끝나고 시간이 남으면 이야기하거나 따로 티켓을 만들어 논의하시죠.

팀원 B는 ‘내 의견이 존중받았다’는 느낌을 받으면서도 더는 같은 문제로 회의 흐름을 방해하지 않을 것입니다. 딴소리를 마냥 제거하는 것이 아니라, 적절한 위치로 이동시키는 것. 이 역시 회의를 원활하게 만들 How입니다.

Why: 가치를 알게 하기

앞서 우리는 ‘What(목표)’을 시각화하고, ‘How(규칙)’를 정비했습니다. 이 두 가지만 잘 갖춰도 무의식적으로 튀어나오는 딴소리는 대부분 사라질 것입니다.

하지만 회의를 가장 힘들게 만드는 존재는 따로 있습니다. 바로 똑똑한 팀원의 확신에 찬 딴소리입니다. 팀원 C는 회의의 목표(What)가 무엇인지 알고 있고, 발언 규칙(How)도 충분히 이해하고 있습니다. 그런데도 손을 들고 제동을 겁니다.

“트랜잭션 롤백 전략도 중요한데요. 저는 이번 기회에 레거시 코드를 먼저 리팩토링해야 한다고 봅니다. 지금 구조로는 어떤 전략을 써도 코드가 너무 지저분해져서 나중에 유지보수를 할 수가 없어요.”

회의 주제는 분명 롤백 전략 결정입니다. 그런데 갑자기 코드 품질과 리팩토링이라는 훨씬 큰 주제가 던져집니다. 틀린 말은 아닙니다. 맞는 말일 수도 있습니다. 하지만 지금 이 회의에서는 분명한 딴소리입니다.

그렇다면 왜 이런 일이 벌어질까요? 원인은 정보의 부재가 아닌 가치의 충돌에서 찾아야 합니다.

조직의 목표 vs 개인적 동기

모든 개발자는 마음속에 자신만의 개인적인 동기를 품고 있습니다.

‘나는 더 깔끔하고 우아한 코드를 짜고 싶어.’라는 기술적 완벽주의나, ‘새로 배운 기술(MSA, GraphQL 등)을 써보고 싶어.’라는 학습 욕구, ‘나중에 귀찮아지기 전에 지금 고치고 싶어.’ 같은 편의성도 있죠.

반면, 회의를 소집한 주최자는 분명한 조직의 목표를 바라봅니다.

‘코드가 좀 지저분해도 내일 당장 배포해야 해.’처럼 비즈니스 속도일 중요하게 볼 수도 있고, ‘새로운 기술 도전보다는 지금 잘 돌아가는 방식이 안전해.’라며 안전성을 따질 수도 있습니다.

딴소리는 바로 이 두 가지 Why가 정면으로 충돌할 때 발생합니다.

팀원 C는 자신의 개인적 Why(코드 품질)가 팀의 Why(출시 속도)보다 더 중요하다고 믿기에, 이를 관철하려 회의의 흐름을 끊었습니다. 만약 이때 권한이나 연차 같은 힘으로 “시키면 하세요”라고 찍어 누르면, 그 팀원은 입을 닫고 동기를 잃어버립니다. 그렇다고 모두 들어주면 배는 산으로 갈 것입니다. 어떻게 해야 할까요?

회의의 Why를 설득하기

그래서 회의 주최자는 회의 시작 전에, 팀원들에게 이 회의가 가지는 가치를 먼저 설득해야 합니다. 단순히 “모이세요”가 아니라 “왜 이 회의가 당신의 시간을 뺏을 만큼 가치 있는지”를 분명하게 증명해야 합니다.

회의 서두부터 비즈니스 맥락과 위협을 함께 공유하는 것이 가장 좋은 방법입니다.

나쁜 예: 자, 이번 스프린트 롤백 로직 개발 건 논의합시다.
좋은 예: 이번 결제 모듈이 다음 주 대규모 프로모션 때 배포됩니다. 만약 롤백 실패로 데이터가 꼬이면, CS 문의 폭주로 프로모션을 중단해야 할 수도 있습니다(Why). 그래서 오늘 회의에서는 완벽한 코드보다는 가장 확실하고 안전한 방법을 찾는 것이 먼저입니다.

이처럼 ‘안정성’이라는 이유를 명확히 하고 시작하면, 리팩토링이나 신기술 도입을 주장하려던 팀원도 스스로 브레이크를 밟게 됩니다. “아, 지금은 기술적 욕심을 부릴 때가 아니구나”라고 이해한 것이죠.

개인의 Why는 존중하되 냉정하게 다루기

그런데도 딴소리를 멈추지 않는 고집 센 팀원이 있다면, 어떻게 해야 할까요? 이때는 그들의 열정을 꺾지 않으면서도 회의를 구출하는 존중과 제어의 화법이 필요합니다. 핵심은 단순히 “틀렸다”라고 말하는 것이 아니라 “시점이 다르다”라고 말하는 데 있습니다.

1단계. 존중

“C 님의 리팩토링 의견은 정말 훌륭합니다. 장기적으로 우리 팀에 꼭 필요한 작업이고, 기술 부채를 진지하게 고민해 주신 점도 감사합니다.”

이처럼 먼저 팀원의 전문성과 동기를 인정하면, 그의 방어 기제를 내려놓는 데 도움을 줍니다.

2단계. 제어

“다만 앞서 말했듯이 오늘 회의의 목표는 ‘프로모션의 생존’입니다. 지금 리팩토링을 시작하면 우리가 목표로 한 프로모션 오픈 일정은 맞추기 어렵습니다. 다만, C 님의 소중한 의견이 묻히지 않도록 이 안건은 다음 안정화 스프린트 회의로 넘기는 게 어떨까요?”

그다음에는 팀의 Why를 근거로 우선순위를 다시 정렬합니다.

이 과정을 거치면 팀원은 자신의 의견이 무시당한 것이 아니라 ‘더 적절한 시기를 기다리고 있다’고 인식합니다. 회의의 목표를 지키면서도 가치의 우선순위를 정렬하는 방법입니다.

한계: 의지가 없다면 단호해지기

여기까지 왔다면 우리는 할 수 있는 모든 것을 다 했습니다.

What: 목표를 명확히 보여줬고,
How: 규칙을 세웠으며,
Why: 이유를 설득하고 가치의 우선순위까지 정렬했습니다.

이 정도 시스템이라면, 팀원의 95%는 딴소리를 멈추고 협력자로 바뀔 것입니다.

하지만 끝이 아닙니다. 만약 이 모든 것을 완벽하게 만들어도, 여전히 팔짱을 낀 채 딴소리를 하며 분위기를 흐리는 나머지 5%가 있다면 어떨까요? 시스템을 제공해도 거부하는 그들에게 우리는 어떤 카드를 꺼내야 할까요?

소통 vs 태도와 동기

여기서부터는 진단을 바꿔야 합니다. 이는 더 이상 회의 주최자가 해결할 수 있는 소통 문제의 영역이 아닙니다. 본질은 협업 태도의 문제입니다. 시스템으로 개선할 소통 문제에 비하면, 동료의 태도와 동기 문제는 주최자가 고칠 범위가 아닙니다. 시스템을 따를 의지가 없는 참여자에게 더 정교한 회의 기법을 쓰는 것은 솔직히 시간 낭비에 가깝습니다.

이때는 친절한 진행자의 가면을 벗고, 단호한 심판자의 역할을 해야 합니다. 억지로 설득하려 들기보다는 정해진 규칙에 따라 논의를 중단시키거나 문제 해결을 상위 리더에게 위임하세요. 만약 통제가 불가능한 상황이 온다면, 감정적으로 맞서지 말고 건조하게 선을 긋는 것이 낫습니다.

“의견은 충분히 들었습니다. 하지만 정해진 규칙과 시간 안에 결론을 내려야 하는 관점으로, 이 논의는 여기서 중단하겠습니다. 이견이 있다면 회의록에 ‘미해결 안건’으로 남기고, 팀장님(결정권자)과 별도로 이야기하시죠.”

이처럼 명확한 선을 긋는 것 역시 주최자의 중요한 역할입니다. 해결할 수 없는 문제까지 끌어안으려다 회의 전체를 망치지 마세요. 주최자의 책임은 모두를 만족시키는 것이 아니라, 회의에 참여한 다수의 시간을 보호하는 것입니다.

회고로 개선하기

마지막으로, 딴소리 없는 회의를 유지하려면 시스템을 꾸준히 개선해야 합니다.

이를테면, 아이디어 발산이 중요한 프로젝트 초반에는 딴소리를 어느 정도 허용해야 할 수도 있고, 마감이 임박한 시점에는 군대식 통제가 필요할 수도 있습니다. 그럴 때는 (애자일 조직이라면) 회의 자체를 하나의 안건으로 ‘회고’에 올려보세요. 이런 질문을 던지면 좋습니다.

이번 스프린트 회의의 What은 명확했나요?
우리가 정한 How가 너무 빡빡해 창의성을 해치진 않았나요?

팀원 스스로 “‘나중에 논의’ 제도가 좋았다”거나 “시간이 너무 부족했다”처럼 솔직히 피드백하도록 장을 열어주세요. 회의의 규칙이 리더가 시킨 것이 아닌 우리가 함께 합의한 문화로 인식되는 순간, 딴소리는 자연스러운 자정 작용으로 사라질 것입니다.

마치며

지금까지 ‘회의 시간에 딴소리하는 팀원’이라는 골치 아픈 현상을 함께 살펴봤습니다. 첫 질문으로 돌아가 봅시다. “회의 시간에 딴소리하는 팀원, 고칠 수 있을까요?”

제 대답은 “시스템이 그들을 돕는다면 가능하다”입니다.

우리는 너무 쉽게 동료를 비난합니다. “눈치가 없다”, “이기적이다”, “말귀를 못 알아듣는다”. 하지만 그 비난의 손가락을 거두고 내가 설계한 회의실의 풍경을 다시 한번 점검해 보세요. 화이트보드에 목표(What)는 적혀 있었는지, 팀원들에게 규칙(How)을 주었는지, 그리고 이 회의의 이유(Why)를 충분히 설명했는지 말입니다.

딴소리는 팀원의 입에서 나오지만, 그 원인은 회의 방식에도 숨어 있습니다. 어떻게 보면 딴소리는 ‘지금 이 회의의 시스템이 고장 났습니다’라는 경고음입니다. 그럴 때는 경고음을 낸 사람을 탓하기보다 시스템을 먼저 수리해 보세요. 말 잘 듣는 팀원을 찾기보다 누가 들어와도 몰입할 수밖에 없는 회의를 설계하는 것이 빠릅니다.

이렇게 What, Why, How가 제대로 채워진 회의실에서는 더 이상 낭비되는 시간이 없을 겁니다. 지금 당장, 다음 회의의 What을 적어보는 건 어떨까요?

]]>

뛰어난 개발자일수록 더 빨리 번아웃됩니다

최근 충격을 받았습니다. 평소 “저 사람은 절대 안 무너질 것 같은데….”라고 생각하던 시니어 개발자가 갑자기 회사를 그만뒀다는 소식을 들었거든요. 웃긴 건, 듣고 보니 저도 똑같은 길을 밟고 있다는 거였습니다. 일은 잘 풀려도, 마음은 조금씩 부서지고, 회사라는 공간은 더 버겁게 느껴졌죠.

“실력만 좋으면 어디서든 살아남겠지”라는 생각.

한동안 정말로 그렇게 믿었습니다. 그런데 8년 차에 접어들자, 완전히 다른 사실을 인정할 수밖에 없었습니다. 실력은 어디까지나 기본값일 뿐이고, 오래 버틴다는 건 전혀 다른 게임이라는 점이었죠.

돌이켜보면 제가 봐온 동료들 중에도 그런 사람이 꽤 많았습니다. 코드는 정말 잘 짜는데도 어느 순간 번아웃이 와서 갑자기 퇴사한 사람들 말이죠. 반대로 기술이 아주 뛰어나지 않아도, 꾸준히 인정받으며 오래가는 사람도 있었습니다.

그 차이는 도대체 뭘까요?

이 질문을 몇 년 동안 붙잡고 고민했는데, 결론은 의외로 단순했습니다.

회사에서 오래 살아남는 건 ‘개발 실력만’의 문제가 아니다. 보이지 않는 다른 스킬이 있다.

그렇게 깨달았습니다. 버티는 사람과 무너지는 사람의 차이는 실력이 아니라, 스킬에 있다는 것을요. 그리고 그 스킬들은 배우려고 노력한다면 충분히 좋아질 수 있는 것들이었습니다. 아예 그 중요성을 아예 모르거나, 너무 늦게 깨달을 뿐이었죠.

이 글을 그냥 넘기면, 누군가는 회사 생활이 더 힘들어질지도 모릅니다. 오늘은 지금까지 저를 붙잡아준 그 세 가지 스킬을 이야기해보려고 합니다.

미리 요점만 콕 집어보면?

회사에서 오래 살아남는 건 ‘개발 실력’만의 문제가 아닙니다. 보이지 않는 다른 스킬이 있습니다.
오래 버틸 생각이라면, 정치력은 필수에 가깝고 회사 생활은 장거리 달리기임을 기억해야 합니다.
기술만으로 리더가 될 수 있는 시대는 이미 끝났습니다. 사람을 움직이는 능력이 리더십의 핵심입니다.

생존 스킬 1: 보이지 않는 정치력

<출처: 작가, ChatGPT로 생성>

개발자들이 제일 듣기 싫어하는 단어 중 하나가 바로 ‘정치’입니다. 저 역시 예전에 이런 말을 수백 번쯤은 했던 것 같아요.

“아니, 개발자는 개발만 잘하면 되지. 왜 그런 걸 신경 써야 해?”

그런데 이 말은 한 회사에서 1~2년만 지낼 때나 가능한 말이었습니다.

오래 버틸 생각이라면, 정치력은 필수에 가깝습니다.

다만, 여기서 말하는 ‘정치’는 흔히 떠올리는 부정적인 의미와는 다릅니다. 이는 상황을 읽고 흐름을 파악하는 능력, 다시 말해 ‘정보전’을 뜻합니다.

회사라는 공간은 전쟁터와 크게 다르지 않습니다. 전쟁에서 가장 많은 시간과 에너지를 들이는 곳이 어딘지 아시나요? 바로 정보전입니다. 몇 마디 대화, 누군가의 표정 변화, 리더의 최근 발언 한 줄이 전쟁의 판도를 완전히 바꿔버리기도 하니까요. 회사도 똑같습니다. 총칼 대신 OKR을 들고 싸울 뿐입니다.

‘무기’가 되는 정보는 이런 것들입니다:

지금 회사가 가장 집중하는 핵심 목표
우리 팀 리더가 중요하게 보는 가치 기준
최근 인사평가에서 높은 점수를 받은 사람들의 공통점
반대로 낮은 점수를 받은 사람의 특징
이번 분기의 분위기가 흘러가는 방향

이런 정보들을 몰랐던 저는 잘못된 방식으로 에너지를 쓰고 있었습니다. 아무도 중요하게 생각하지 않는 문제를 붙잡아 밤을 새느라, 정작 팀이 진짜 필요로 하는 건 나중에야 알기도 했죠.

돌이켜보면 실력의 문제가 아니었습니다. 정보력의 차이였습니다.

평소에 “눈치 없다”는 말을 자주 듣는 사람

회사에서 가장 먼저 무너지는 사람들의 유형입니다. ‘눈치 없는 사람’이라고 불리는 건 성격 문제가 아니라 정보 처리 능력의 부족에 가깝습니다. 상황을 읽지 못하니 위험 신호도 놓치고, 기회가 와도 잡지 못하는 거죠.

본인은 아무 문제 없다고 생각하지만, 조직 안에서는 이미 “리스크가 큰 사람”으로 분류돼 있기도 합니다. 회사 생활에서 진짜 무서운 건 문제를 일으키는 사람이 아니라, 문제가 있는지도 모르는 사람이니까요.

나만의 ‘정보 데이터베이스’ 만들기

스킬을 가지는 법은 생각보다 어렵지 않습니다. 그냥 관심을 가지는 것부터 시작하면 됩니다. 주변 동료들이 어떤 일을 하고 있는지, 리더가 강조하는 포인트는 무엇인지, 회사 공지에서 유독 자주 등장하는 단어가 뭔지 살펴보세요. 또, 조직에서 잘나간다고 평가받는 사람들의 행동 패턴은 어떤지도 눈여겨볼 필요가 있습니다.

이런 파편화된 정보들을 가볍게라도 기록하기만 해도 충분합니다. 저는 노션에 탭 하나를 만들어두고, 생각나는 대로 그냥 쌓아두었습니다. 여기서 어느 순간부터 진짜 ‘흐름’이 보이기 시작합니다. 그리고 그 흐름이 보이기 시작하면, 일에 대한 판단도 이전보다 10배는 쉬워집니다.

고급 정보에 접근할 인맥 만들기

회사에서 말하는 ‘핵심 정보’는 위로 올라갑니다. 직급이 높은 사람, 조직 구조를 자세히 보고 있는 사람, 혹은 인사과처럼 내부 사정을 업무로 다루는 사람들만 알고 있는 정보들이죠.

그래서 이건 팁이라기보다는 법칙입니다.

인사과와 인맥을 쌓아라
조직의 흐름을 잘 아는 사람과 친해져라

밥을 사라는 뜻이 아니라, 부담 없이 대화할 수 있는 관계를 만들어두라는 이야기입니다. 이 사람들에게서 흘러나오는 미묘한 한 줄의 정보가 내 프로젝트, 내 평가, 나아가 커리어 전체를 바꿔놓기도 합니다.

다시 말하지만, 정치력은 부정적인 단어가 아닙니다. 이건 회사에서 살아남기 위해 필요한 상황 판단력과 정보력, 그리고 관계 감각의 조합입니다. 이걸 빠르게 익힌 사람은 훨씬 덜 아프고, 덜 다치면서 커리어를 길게 가져갑니다.

생존 스킬 2: 지치지 않는 멘탈 관리

<출처: 작가, ChatGPT로 제작>

회사라는 조직은 태생적으로 이익을 추구하는 집단입니다. 어쩔 수 없습니다. 회사 입장에서 성장은 곧 생존이고, 그래서 구성원에게도 계속해서 성장을 요구할 수밖에 없죠.

하지만 문제는 사람이 그렇게 태어나지는 않았다는 점입니다.

우리는 감정을 가지고 있고, 컨디션에도 영향을 받으며, 쉬지 않고 일만 하면서 살아갈 수는 없으니까요. 그래서 회사의 끝없는 성장 속도를 억지로 따라가다 보면, 결국 내가 먼저 지치게 됩니다. 어느 순간, 회사가 나를 떠나는 게 아니라 내가 회사를 떠나버리는 상황이 찾아옵니다.

너무 열심히 하지 않는 것

조금 웃기게 들릴지도 모르지만, 오래 가는 사람일수록 오버페이스를 하지 않습니다. 여기서 말하고 싶은 건 “열심히 하지 마라”가 아니라, ‘열심히의 기준을 나에게 맞추라’는 뜻입니다.

특히 주니어일수록 처음부터 미친 듯이 잘하려고 합니다. 한 번 일 잘하는 이미지를 만들어두면, 그걸 계속 유지해야 한다고 스스로 압박하죠. 그건 함정입니다. 한 번 너무 잘해버리면, 그 성과가 나를 판단하는 기준이 되어버립니다. 기대치를 그곳에 고정하는 거죠.

그래서 저는 늘 이렇게 말합니다.

“능력의 맥시멈을 100으로 잡으면, 회사에 60~70만 보여줘도 충분하다.”

나머지 30~40은 내년에 써도 되고, 정말 중요한 프로젝트가 왔을 때 꺼내도 됩니다. 이게 바로 완급 조절이고, 롱런하는 회사 생활의 기본 전략입니다.

신뢰와 기대치를 무너뜨리는 번아웃

회사가 진짜 무서운 건, 잘한 10번이 아니라 망한 1번을 기억한다는 것니다. 왜냐하면 평가는 결국 ‘사람’이 하기 때문이에요.

한 번 번아웃이 오면, 평소에 보여주던 퍼포먼스가 갑자기 뚝 떨어져버립니다. 그때 주변에서 느끼는 실망감은 생각보다 큽니다. “어? 얘 원래 이 정도 아니었는데?” 이런 생각이 드는 순간, 위험해지기 시작하는 거예요.

그래서 정말 중요한 건 잘하는 사람이 되는 게 아닙니다. 끝까지 안 무너지는 사람이 되는 거죠.

회사 생활은 장거리 달리기

장거리 달리기를 할 때 초반에 오버페이스를 하면 어떻게 될까요? 앞에서는 잠깐 선두를 달리지만, 중반에 가면 전부 무너집니다. 그리고 한 번 주저앉으면, 다시 일어나는 건 거의 불가능에 가깝죠.

회사도 똑같습니다. 조금 느리더라도, 내가 유지할 수 있는 리듬으로 꾸준히 가는 사람. 이 사람이 결국 완주합니다. 이게 현실이죠.

이건 제 개인적인 경험이기도 하고, 어느 정도 버텨온 시니어들에게서 공통으로 보이는 패턴이기도 합니다.

회사에서 7~8년 넘게 버티는 사람들? 다들 완급조절이 기가 막히게 좋습니다.

항상 잘하는 사람은 아닙니다. 때로는 평가가 떨어지고, 기대에 못 미치는 결과가 나올 때도 있습니다. 그럼에도 이 사람들의 진짜 강점은 자리를 지켜낸다는 것, 그리고 꾸준히 조금씩이라도 성장해 나간다는 것입니다. 이게 바로 장기전에서 승리하는 방법입니다.

생존 스킬 3: 쉬운 말 커뮤니케이션

<출처: 작가, ChatGPT로 제작>

개발자로 일하면서 정말 많이 봐온 유형이 하나 있습니다.

개발 실력은 미친 듯이 좋은데, 아는 걸 제대로 표현하지 못하는 사람.

이 사람들은 코드 레벨에서는 압도적입니다. 그런데 회의만 들어가면 말문이 막히고, 정작 하고 싶은 이야기는 다 빠진 채 “그냥 제가 처리할게요…”라는 말로 끝내버립니다.

이런 분들, IC(개인 기여자, Individual Contributor)로는 전혀 문제가 없습니다. 실력 하나만으로도 충분히 자리를 지킬 수 있습니다. 하지만 리더 자리로는 올라가지 못합니다. 스타트업이든, 네임드 회사든 옮겨 다니면서 이 케이스를 종종 봤습니다.

기술은 평범한데 리더인 사람들의 공통점

이게 참 아이러니합니다. 코드 실력만 놓고 보면 “그냥 나쁘지 않네?” 싶은데, 리더로는 승승장구하는 사람들이 있거든요. 이 사람들의 공통점은 딱 하나입니다.

커뮤니케이션 능력이 탁월합니다.

이들은 복잡한 내용을 쉽게 풀어내고, 기획자나 디자이너, 상사가 무엇을 궁금해하는지 정확히 짚어냅니다. 웬만하면 결론을 먼저 말하며, 필요한 선택지를 구조적으로 제시하죠. 회의에서 논점을 흐리지도 않습니다.

기술만으로 리더가 될 수 있는 시대는 이미 끝났습니다. 이제는 사람을 움직이고, 조직을 움직이는 능력이 리더십의 핵심입니다.

하고 싶은 말을 정확하게 전달하기

커뮤니케이션의 첫 단계는 단순합니다. 내가 하고 싶은 말을 있는 그대로 정확하게 전달하는 것입니다. 그런데 이게 생각보다 많이 어렵습니다. 대부분의 사람들은 ‘말하고 싶은 내용’과 실제로 ‘말로 나오는 내용’ 사이에 간극이 생기기 때문이에요.

그렇게 기본을 갖추고 나오는 궁극기는 따로 있습니다. 바로 내가 원하는 방향으로 상대를 설득하는 능력입니다. 문제를 한 번에 해결하게 만드는 것도, 필요한 리소스를 확보하는 것도, 내 의견을 끝까지 관철시키는 것도 결국 설득입니다. 이건 타고나는 게 아니라 진짜 많은 연구와 훈련이 필요합니다.

말을 잘하려면, 글부터 잘 써야 한다

이건 100% 확신을 가지고 말할 수 있습니다.

말을 잘하고 싶다면, 먼저 글부터 잘 써야 합니다.글쓰기는 생각을 구조화하는 가장 확실한 도구입니다. 글로 생각의 구조가 잡힌 사람은, 말도 자연스럽게 구조적으로 나옵니다.

그래서 저는 이렇게 추천합니다. 회사에서 기회가 된다면, 아주 작은 발표라도 계속 시도해보세요. 기술 발표든, 회고 공유든, 신규 기능 제안이든, 프로젝트 기획 문서 리뷰든 상관없습니다.

하다 보면 말은 단단해지고, 설득력도 함께 생깁니다. 그러다 보면 어느 순간, 사람들이 “아, 이 사람은 방향을 제시할 줄 아는구나.”라고 느끼기 시작합니다.

바로 그때부터 회사에서의 역할이 달라집니다. 그저 업무를 수행하는 사람이 아니라, 의사결정을 만들어내는 사람이 되는 거죠.

마치며: 실력은 기본, 생존은 전략

개발자로 살다 보면 이런 생각을 정말 자주 합니다.

“아, 그냥 실력만 좋으면 다 아닌가?”

하지만 회사라는 공간에서 버텨본 사람들은 압니다. 실력은 기본값일 뿐, 생존은 완전히 다른 영역이라는 사실을요.

정치력이자 정보력, 지치지 않는 멘탈 관리, 그리고 쉬운 말 커뮤니케이션.

이 세 가지는 어떤 기술 스택보다도 오래 나를 지켜주는 자산입니다. 게다가 특정 회사나 팀에만 통하는 기술도 아닙니다. 내가 어디에서 일하든, 어떤 조직으로 옮기든 평생 가져갈 수 있는 ‘재사용하는 근력’ 같은 것들이죠.

저는 이것들을 조금 늦게 배웠습니다. 실력만 믿었기에 몇 번이나 넘어졌고, 번아웃으로 한동안 아무것도 못 한 적도 있었습니다. 커뮤니케이션 부족으로 억울하게 평가받은 일도 적지 않습니다.

그래서 더 확신을 가지고 말할 수 있습니다. 회사에서 오래가는 사람들은 단순히 일을 잘하는 사람이 아닌 상황을 읽고, 자신의 페이스를 알고, 사람을 움직이는 방법을 아는 사람들입니다.

이걸 조금만 더 일찍 알았더라면, 제 20대 후반은 훨씬 덜 힘들었을 겁니다. 하지만 여러분은 저보다 훨씬 빨리 이 사실을 알게 됐습니다. 그러니 분명 더 멀리, 더 길게 갈 수 있을 거예요.

]]>

“나도 AI로 돈 벌 수 있을까?” 부업 시작을 위한 큐레이션

안녕하세요, 메리 크리스마스입니다! 한 해 마무리 잘하고 계신가요?

올해는 요즘IT 독자분들 사이에서도 “AI로 이런 거 만들어 봤어요!” 하는 분들, 꽤 많았을 것 같은데요.

2025년은 특히 ‘바이브 코딩’이라는 단어가 새롭게 등장할 정도로, 코딩을 몰라도 AI가 함께 뚝딱 무엇이든 만들어 주는 시대가 열렸습니다. 덕분에 개발자든, 비개발자든 AI를 활용한 부업으로 쏠쏠한 부수입을 올렸다는 이야기도 들려왔고요.

그럼 다가오는 2026년에는 “나도 AI로 부업 한 번 해볼까?” 하고 슬쩍 관심이 생긴 분들을 위해,

올해 발행된 글 중에서 여러분 상황에 맞게 참고하기 좋은 콘텐츠만 쏙쏙 골라 모아봤습니다.

가볍게 훑어보다가, 내 상황에 맞는 아이디어 하나만 챙겨가도 이득이에요!

✅ 이런 분들께 추천해요

AI로 뭔가 만들어보고 싶은데 어디서부터 어떻게 시작할지 모르겠는 분
바이브 코딩, 들어는 봤는데 진짜 되는 건지 궁금한 분
2026년 부업 아이템을 고민 중인 분
AI 시대, 커리어의 방향성을 고민 중인 분

비개발자도 도전할 수 있어요

“전 비개발자라 코딩을 모르는데 괜찮나요?”
“그럼요. 이젠 AI가 있으니까요!”

코딩을 잘 몰라도 괜찮아요. 일단 작은 프로젝트 하나라도 AI 도움을 받아 시작해 보세요. 용기 있게 저지르는 자에게, AI의 축복이 함께할지니!

40대 비개발자, 어떻게 바이브 코딩으로 월 300을 벌게 됐을까?

안녕하세요, 저는 비전공자로서 IT와는 전혀 다른 분야에서 일하고 있는 평범한 직장인입니다. 현재 두 돌 지난 아기가 잠든 뒤에는 외주 개발을 하며, 월 300만 원 정도의 부수입을 얻고 있는데요. 이번에 요즘IT에서 부업과 관련된 이야기를 나눌 기회가 생겨 글을 쓰게 되었습니다. 많은 개발자분들 앞에서 부족한 제 경험을 나누려니 다소 부담스럽지만, ‘이런 방식으로도 부업을 할 수 있구나’라는 마음으로 참고해 주시면 좋겠습니다.

정확히 1년 전, 회사에 구조조정 소문이 돌기 시작했습니다. 각 부서별로 일부 인원을 다른 부서로 강제 이동시키라는 할당이 내려왔죠. 불행히도 그 대상자 명단에 제 이름도 포함되어 있었고요. 아무도, 아무것도 모르는 새로운 부서로 옮겨지면서, 저는 더 이상 경쟁력 없는 소위 ‘깍두기’ 같은 직원이 된 것 같았습니다. 돌이 막 지난 아이와 남은 대출이 떠오르며, ‘이 상태로 앞으로 20년을 더 버틸 수 있을까?’하는 답답함이 밀려왔죠. 그때 마침 눈에 들어온 것이 AI였습니다.

그때부터 AI와 본격적으로 대화를 나누기 시작했죠. 처음에는 인생과 직장에 대한 하소연을 털어놓는 수준이었지만, 점점 업무와 관련된 질문으로 확장되기 시작했습니다. “어쩌면 내가 하고 싶은 것만 있다면, AI가 뭐든 도와줄 수 있지 않을까?” 그 생각이 들자, 회사에서 자동화할 수 있는 업무 영역을 구체적으로 탐색하며 질문했습니다.

챗GPT 보고 사표 쓴 비전공자, IT 커뮤니케이터가 되다

Q. 'IT 커뮤니케이터'가 되기 전에는 어떤 일들을 하셨나요?
이전에는 금융사에서 디지털 전환(DT) 전략을 기획했어요. 업무 특성상 새로운 기술과 서비스를 누구보다 먼저 접하고, 빠르게 분석해야 했죠. 그러다 보니 자연스럽게 기술 변화에 민감해질 수밖에 없었는데요. 그런 흐름 속에서 마주한 게 바로 ChatGPT였습니다. 이 서비스를 처음 봤을 때, ‘아, 이건 정말 세상을 바꾸겠구나’ 하는 확신이 들었어요. 그리고 그 거대한 변화 한가운데서 제가 해야 할 일이 뚜렷하게 보였죠. 그렇게 퇴사를 결심했고, 지금의 IT 커뮤니케이터로서 새로운 길을 걷게 됐습니다.

바이브 코딩을 시작하는 실무자를 위한 안내서

사람의 언어로 AI에게 코드를 생성하고, 설명하고, 변환시키는 새로운 개발 방식이 있습니다. 더 적은 시간으로 더 큰 결과를 만들 수 있고, 개발자뿐 아니라 기획자·디자니어·마케터 등 비개발자까지 활용할 수 있는 방식이죠. 우리는 이 방식을 바이브 코딩이라고 부릅니다.

하지만 ‘AI 시대니까 배워야지’ 같은 막연한 이유로 시작하면, 바이브 코딩은 의미가 없습니다. 우리가 업무에서 하는 모든 행위들은, 지금 당장 막힌 문제를 해결할 수 있을 때 의미를 가지기 때문입니다. “지금 내 상황을 가장 빠르게 풀어내는 방법”을 찾는 사람들을 위한 4단계 안내를 준비했습니다. 내 수준을 확인하고, 무슨 문제를 해결할지 탐색하며, 내게 가장 어울리는 도구는 무엇인지, 어떤 단계로 시작할지 체크할 겁니다. 바이브 코딩을 시작하는 실무자를 위한 안내서입니다.

개발자의 부업 도전기

개발자에게 부업은 ‘무엇을 만들지?’보다는 ‘어떻게 지속할 수 있을까’에 대한 고민이 클 텐데요. 실제 개발자들의 부업 도전기와 개발자를 위한 바이브 코딩 툴 추천까지 모아봤습니다.

본업과 부업 사이, 개발자가 퇴근 후 ‘내 서비스’ 만든 방법

Q. 부업을 꾸준히 운영하는 데 가장 도움이 됐던 방법은 무엇이었나요?
우선 AI를 사용하는 방식을 고도화하는 데 집중했어요. 마침 ChatGPT, Claude, Gemini 등 시중의 다양한 AI 툴들을 가리지 않고 닥치는 대로 써보고 있었거든요. 정말 많은 시행착오를 겪으면서 결국 깨달은 건, 돌고 돌아 ‘프롬프트를 잘 쓰는 게 핵심’이라는 점이었어요. AI 도구를 다양하게 쓰다 보니, 자주 사용하는 프롬프트가 여기저기 흩어져 있었거든요. 그래서 그걸 한데 모아 관리할 수 있는 앱을 직접 만들고, 프롬프트를 잘 관리하면서 업무 효율화를 높였죠.

8년 차 개발자가 부업으로 월 300만 원을 벌기까지

“이 회사가 과연 1년 뒤에도 안정적일까?”
“만약 지금 당장 나가야 한다면, 나는 회사 밖에서 어떤 가치를 만들 수 있을까?”

이 질문이 제 부업의 출발점이었습니다. 처음에는 단순히 ‘나도 뭔가를 만들어볼까?’ 하는 가벼운 마음이었지만, 곧 깨달았습니다. 내 이름으로 돈을 벌 수 있어야 이게 진짜 오래 살아남는 길이고, 내가 가야 할 길이라는 것을요. 그때부터는 회사 밖에서도 “나라는 사람”의 가치를 실험하기 시작했습니다. 글을 쓰고, 댓글로 멘토링을 하고, 앱을 만들며 작은 시도들을 이어갔습니다. 이번 글에서는 그 여정을 함께 돌아보고자 합니다.

개발자를 위한 바이브 코딩 추천 툴 7가지

개발자의 일하는 방식이 빠르게 달라지고 있습니다. 이제는 반박할 수 없는 현실입니다. 지금까지 작성과 학습, 반복적인 디버깅을 거쳐야만 업무가 이뤄졌다면, 이제는 자연어로 코드가 만들어지고 리팩토링과 테스트까지 자동으로 수행되는 시대가 되었습니다. 우리는 이 흐름을 바이브 코딩(Vibe Coding)이라고 부릅니다. 사람의 언어를 기반으로 AI가 개발 과정 전반을 보조하는 새로운 방식입니다.

그러나 혼란도 함께 커지고 있습니다. 바이브 코딩이라는 개념은 널리 퍼졌지만, 정작 어떤 도구를 선택해야 하는지는 여전히 모호하니까요. IDE를 통째로 바꾼 도구부터 터미널에서 대화하듯 코드를 고쳐주는 도구까지, 종류와 역할이 다르기 때문입니다. 지금 나의 개발 환경에 어떤 도구가 가장 잘 맞는지, 어떤 조합이 가장 효율적인지 판단하기가 쉽지 않습니다. 그래서 이번 콘텐츠에서는 현재 개발자들이 실제로 많이 사용하고 있으며, 앞으로 영향력이 커질 AI 코딩 도구들만 선별하여 정리했습니다.

2026년, AI에 대처하는 커리어 이야기

2026년, AI 시대에 흔들리지 않도록 업무는 더 똑똑하게, 내 커리어는 더 단단하게 만드는 이야기들만 쏙 모아왔어요.

개발자는 이제 일하는 방식부터 재정의해야 합니다

Q. AI가 ‘개발자의 역할을 대체할 수 있다’라는 불안감이 점점 커지고 있는 것 같아요.
물론 불안할 수 있어요. 그런데 실제로 보면, 개발자가 사라진다기보다는 개발자의 역할이 완전히 재정의되고 있다고 느낍니다. 요즘의 트렌드가 “AI를 조수처럼 쓰는 개발자”라면, 앞으로는 코드를 직접 들여다보는 시대가 아니라, AI가 개발적 의사결정까지 맡는 시대가 오는 거죠. 개발자가 AI를 레버리지하는 방식으로 일하게 되는 겁니다.

AI가 코딩을 더 잘하는 영역이 분명히 있어요. 그래서 사람이 직접 코드를 작성하는 건 오히려 비효율적인 경우도 많습니다. 중요한 건 문제를 정의하고, AI가 ‘생각하는 머신’처럼 작동하도록 설계하고 엮는 능력이에요. 이 부분은 여전히 사람의 역할이고, 앞으로 더 중요해질 겁니다. 결론적으로 개발자는 사라지지 않겠지만, 대신 공정을 설계하고 관리하는 역할, 즉 설계자·관리자 역할로 이동할 거라고 생각합니다. 생산직형 개발자는 줄어들 수도 있지만, AI 시대에 더 필요한 개발자는 확실히 존재하고요.

SKT 때려치우고 1인 창업가 변신한 프로덕트 디자이너

Q. 회사에 다니는 프로덕트 디자이너가 솔로프리너를 꿈꾼다면, 어떤 준비가 필요할까요?
가장 먼저 필요한 건 시장 검증이에요. 회사 안에만 있다 보면 외부 반응을 알기 어렵잖아요. 작게라도 외주를 해보거나, 사이드 프로젝트를 통해 실제 사용자에게 검증받는 경험이 중요하다고 생각해요. 저도 DIO라는 회사와 협업하면서 면접 대신 일로 평가받은 경험이 도움이 됐고요. 그리고 "혼자 일하고 싶다"는 막연한 생각보다는, 정확히 어떤 걸 혼자 하고 싶은지를 스스로 정의해보는 게 중요해요. 디자이너가 나와서 할 수 있는 일이 그렇게 많지는 않거든요. 프리랜서, 에이전시, 스타트업 창업... 그중 내가 원하는 방식의 독립은 어떤 모습인지 생각해볼 필요가 있어요.

요즘은 디자인만 잘해서는 안 되는 시대예요. AI 도구와 협업해서 비즈니스를 설계할 수 있는 관점이 더 중요해지고 있고, 디자이너도 더 상위 레이어에서 문제를 바라보는 훈련이 필요하다고 느낍니다.

진짜로 AI 때문에 신입 개발자 안 뽑습니까?

좀 살벌한 질문일 수 있습니다만, 모든 것이 AI 탓으로 돌아가는 이 시대, 우리에게 필요한 건 이 질문입니다. ‘AI보다 내가 나은 점이 있는가’를 생각해 봐야죠. AI를 써서 바이브 코딩을 하는 것이, 개발을 전혀 모르는 사람이 AI를 시켜 무언가 만드는 것과 별다를 바가 없다면 어떨까요? 인력 감축의 명분이, 명분으로 끝나지 않게 되어 버립니다.

(중략)

저는 예언자가 아닙니다. 그래서 유튜브에 수없이 올라오는 호들갑처럼 ‘이런 포지션만 살아남을 겁니다’ 라든가, ‘AI에게 이것 시켜야 합니다’ 같은 소리는 못 합니다. 그 대신 현직자로서, 현장에서 느끼는 것들을 이야기할 수는 있습니다. 무엇보다 지금까지처럼 ‘프론트엔드 개발자’, ‘백엔드 개발자’ 이런 식으로 특정 분야만 하려는 생각은 더 이상 안 통할 겁니다. 전체 흐름을 다 아는 사람이 AI를 이용하면, A to Z를 처리하는 효율이 급격하게 증가하고 있습니다. 구인구직 플랫폼에 ‘풀스택 개발자’를 필요로 하는 내용이 많아지고 있기도 하고요. 물론 신입에만 해당하는 소리가 아닙니다. 현직자들도 최선을 다해 달리지 않으면 뒤쳐질 겁니다.

마치며: 2025년을 보내는 마음♡

Merry Christmas! <출처: 제미나이 생성>

크리스마스임에도 불구하고 여기까지 읽은 여러분은, 이미 반은 시작하신 거예요! AI 부업이든, 내 커리어든 너무 거창한 계획보다는 작게 하나를 만들고, 적용해 보는 방법을 추천합니다. 이번 글에서는 ‘나한테 맞는 아이디어 한 가지’만 챙겨가셔도 충분하고요.

올해도 요즘IT와 함께해 주신 모든 분들께 감사합니다. 해피 크리스마스 & 따뜻한 연말 보내시고,

2026년엔 AI와 함께 ‘작게’ 시작해서 ‘크게’ 성장해 보아요!

]]>

당장 이직 안 해도 알아야 할 IT 커리어 탐색 전략

더 나은 직업을 구하기 위한 커리어 탐색의 구조

채용 플랫폼 하나로는 부족한 순간들

IT 직군에게 ‘직장을 구한다’는 일은 취업 한 번, 이직 한 번으로 끝나는 이벤트가 아닙니다.

모두 지금 당장 회사를 옮기지 않더라도 늘 다음을 고민하고 있습니다. 지금보다 더 나은 역할은 없는지, 내 직무는 앞으로 어떻게 변해갈지, 언젠가 이동해야 한다면 어떤 선택지가 있을지에 대한 질문이 맴돌죠. 이러한 고민은 특정 시점에만 나타나지 않습니다. 커리어 전반에 걸쳐 크고 작은 형태로 꾸준히 이어지고, 그래서 IT 직군의 커리어는 하나의 결말이 아니라 끝없이 새로운 시작을 준비하는 상태에 가깝습니다.

하지만, 이처럼 내내 따라다니는 고민을 제대로 마주하는 사람은 적습니다.

대부분은 첫 탐색을 채용 플랫폼에서 시작합니다. 그저 공고를 살펴보고 역할을 비교하며 현재 시장에서 어떤 기회들이 열려 있는지를 확인합니다. 그러나 몇 번만 들여다봐도 곧 한계를 느끼게 됩니다. 이 선택이 나에게 맞는지, 지금의 나에게 의미 있는 방향인지 판단하기에는 정보가 충분하지 않기 때문입니다. 그래서 자연스럽게 채용 플랫폼 밖으로 시선이 옮겨갑니다. 서로 다른 성격의 도구와 정보를 조합해 자신만의 커리어 탐색 방식을 만들려는 시도입니다. 물론 쉽지 않죠.

그래서 IT 직군이 실제로 커리어를 탐색할 때 활용할 여러 방법을 정리했습니다. 무슨 채용 플랫폼에 어떤 역할을 줘야 하는지, 커리어 커뮤니티와 IT 인사이트는 어떤 순간에 도움이 되는지, 그리고 이 서로 다른 도구들을 어떻게 조합해야 할지에 대해 이야기합니다. 아쉽게도 정해진 한 가지 방법은 없습니다. N명의 사람을 위한 N가지 방법이 존재하죠. 커리어의 다음 단계를 고민하는 모든 IT 직군이 참고할 관점과 프로덕트를 정리해 보겠습니다.

물론, 시작은 채용 플랫폼에서

이직을 결심하지 않았더라도 우리는 채용 플랫폼을 엽니다. 당장 회사를 옮기기 위해서라기보다 현재 채용 시장이 어떤 방향으로 움직이고 있는지를 확인하기 위해서입니다. 또는 오늘 낮에 회사에서 무척 열받는 일이 있었을 수도 있고요.

그렇게 채용 플랫폼의 일반적인 쓰임새는 어떤 직무의 수요가 늘고 있는지, 어떤 기술이 더는 선택이 아닌 기본 요건이 되었는지, 기업들이 어떤 역할을 새롭게 정의하기 시작했는지를 살펴보는 용도에 가깝습니다. 이런 이유로 실제 지원이 이루어지는 공간이면서 동시에 커리어 탐색의 출발점으로 기능합니다.

채용 플랫폼의 정보는 어떻게 써야 할까?

채용 플랫폼이 제공하는 정보는 대부분 기업이 공식적으로 정리해 공개한 내용입니다. 조직 내부에서 여러 차례 검토를 거쳐 나온 정제한 정보들이죠.

그래서 직무명, 요구 역량, 연차 조건, 근무 형태, 연봉 범위처럼 현재 시장에서 통용되는 역할 정의를 비교적 표준화된 형태로 확인할 수 있습니다. 즉, 지금 시장에서 어떤 역할이 요구되고 있는지, 어느 수준의 역량이 기본값이 되었는지를 빠르게 파악할 수 있습니다.

실제 활용도 단순한 지원 단계에만 머물지 않습니다. 포지션 알림을 설정해 두거나, 관심 공고를 저장해 두고, 연봉이나 역할 정의가 어떻게 변하는지를 주기적으로 확인합니다. 지원을 위한 도구이면서 동시에 시장 변화를 관측하는 레이더처럼 쓰이는 거죠. 즉, 채용 플랫폼은 결정을 내리는 공간이라기보다 언제나 탐색의 출발점에 가까운 역할을 합니다.

3가지 채용 플랫폼의 유형

채용 플랫폼은 제공하는 정보의 범위와 활용 목적에 따라 몇 가지 유형으로 나누어 볼 수 있습니다.

범용적인 채용 플랫폼

대기업과 중견기업 공고를 포함해 채용 시장 전반을 넓게 훑기 좋은 공간입니다. 흔히 아는 그곳들입니다. 이 유형의 플랫폼은 “지금 채용 시장이 전체적으로 어떻게 움직이고 있는지”를 파악하는 데 강점을 가집니다. 웬만한 공고들이 다 있으니까요.

잡코리아: 산업과 직무 전반의 채용 흐름을 파악하기에 적합한 대표적인 플랫폼입니다. 신입부터 경력까지 폭넓은 공고를 통해 시장의 전체적인 방향을 살펴볼 수 있습니다.
사람인: 중소·중견기업 공고 비중이 높고, 조건 비교와 지원 관리 기능이 잘 정리되어 있어 실제 이직을 현실적으로 검토하는 단계에서 활용도가 높습니다.
인크루트: 공채와 정기 채용 중심의 공고가 많아, 전통적인 채용 구조와 기업 채용 일정을 확인하기에 적합합니다.

스타트업·IT 직군 중심 플랫폼

역할이 비교적 명확하고 빠른 탐색과 지원에 최적화된 공간입니다. 조직 규모보다 역할의 명확성이나 성장 가능성을 중시할 때 자주 쓰이고요. IT와 이어지는 공간이어서 그런지 새로운 기능이나 비교적 편리한 UX 등도 특징이라 할 수 있겠습니다.

원티드: IT·스타트업 중심의 채용 플랫폼으로 역할과 직무 정의가 비교적 명확합니다. 포지션 단위로 빠르게 탐색하고 지원하기 좋으며, 성장 단계의 조직이나 명확한 역할을 찾고 있을 때 활용도가 높습니다.
점핏: 개발자 직군에 특화된 채용 플랫폼으로 기술 스택과 직무 요건을 중심으로 공고를 살펴볼 수 있습니다. 개발자로서 내 기술 포지션이 시장에서 어떻게 정의되는지 확인하는 데 적합합니다.
랠릿: 단순 채용 공고보다는 스타트업 커리어 전반의 흐름과 선택지를 함께 다루는 플랫폼입니다. 스타트업과 IT 직군 맥락에서 역할과 성장 경로를 함께 고민할 때 적합합니다.

커뮤니티·정보 탐색이 결합된 플랫폼

채용 공고 너머의 맥락을 함께 확인할 수 있는 공간입니다. 채용 공고와 함께 제공하는 정보의 질이 특이한 경우죠. 대부분 HR 중심 커뮤니티가 채용 정보를 흡수한 경우입니다. 그래서 커뮤니티와 이어 자연스럽게 새로운 채용 정보를 접하거나, “이 선택이 나에게 맞는가” 점검하는 과정에서 자주 쓰입니다.

링크드인: 글로벌 커리어 네트워크 플랫폼으로 채용 공고뿐 아니라 사람의 이동, 역할 변화, 업계 흐름을 함께 관찰할 수 있습니다. 커리어 전반의 흐름과 관계를 축적하는 공간에 가깝습니다.
리멤버: 이력 기반 네트워크를 중심으로 채용 제안과 커리어 정보를 함께 탐색할 수 있는 플랫폼입니다. 적극적으로 지원하지 않더라도, 제안을 통해 시장의 반응을 가늠해 볼 수 있습니다.
잡플래닛: 기업 리뷰와 내부 평가 정보를 통해 조직 문화와 근무 환경을 확인할 수 있습니다. 지원 전 판단 단계에서 공고의 내용을 현실적으로 보정하는 데 자주 활용됩니다.

여러분은 어떤 채용 플랫폼을 쓰고 있나요?

잡코리아, 사람인, 리멤버, 원티드, 잡플래닛, 인크루트, 점핏, 랠릿의 찐 사용자 리뷰를 남겨 주세요.
아래 폼으로 신청하고 리뷰를 남기기만 해도 네이버페이 3,000원을 무조건 드립니다.
여러분의 리뷰는 또 다른 콘텐츠로 만들어질 예정이에요. 최고의 리뷰를 남긴 분에게는 무려 30,000원!

리뷰어 신청하기

이처럼 같은 채용 플랫폼이라도 지금 내가 관망 중인지, 준비 중인지, 혹은 실제로 움직여야 하는 순간인지는에 따라 중심에 두는 서비스는 달라집니다. 채용 플랫폼은 결국 “지금 이 시점에 어떤 선택지가 열려 있는가”를 알려주는 공간입니다.

다만 그 자체만으로 결론을 내리기에는 여전히 정보가 턱없이 부족합니다. 그냥 회사 이름 따라 좋은 곳으로 가고 싶기도 하고요. 이 스택과 직무가 무엇을 의미하는지 모호한 때도 끝없이 많습니다. 그래서 자연스럽게 다음 단계의 탐색으로 나아가게 됩니다.

채용 플랫폼의 밖에서

JD를 해석하는 보조 장치로의 커뮤니티

채용 플랫폼이 역할을 정의하는 공간이라면 커리어 커뮤니티는 그 정의를 현실에 맞게 풀어주는 공간입니다. 공고에 적힌 JD는 역할의 윤곽을 보여주지만, 실제로 그 일이 어떤 맥락에서 수행되는지까지 설명해 주지는 않습니다. 그래서 채용 플랫폼에서 역할을 확인하고 자연스럽게 커리어 커뮤니티로 이동합니다.

커리어 커뮤니티의 가장 큰 특징은 공고에 없는 맥락과 실제 경험을 확인할 수 있다는 점입니다. 같은 직무라도 회사와 팀에 따라 역할의 범위와 기대치는 크게 달라질 수 있고, 이 차이는 JD만으로는 쉽게 드러나지 않습니다. 커뮤니티에는 이런 차이를 직접 겪은 사람들의 경험이 쌓여 있으며 성공 사례뿐 아니라 실패와 후회, 시행착오 같은 이야기들도 함께 공유됩니다. 이러한 정보는 선택을 보다 입체적으로 바라보게 만드는 중요한 재료가 됩니다.

마찬가지로 커리어 커뮤니티 역시 정보의 깊이와 목적에 따라 여러 레이어로 나뉩니다.

예를 들어 LinkedIn은 개인의 커리어 이력과 사람의 이동을 중심으로 흐름을 관찰할 수 있는 공간입니다. 누가 어디로 이동하고 어떤 역할을 맡는지를 통해 시장의 변화를 감각적으로 파악하는 데 활용됩니다. 한국에서도 요즘 페이스북이나 X에 대한 대안으로 IT 직군에서 특히 주목받는 듯하고요.

보다 실무 중심의 논의가 이뤄지는 곳도 있습니다. OKKY와 프로그래머스는 개발자 직군을 중심으로 실제 업무에서 마주하는 문제와 커리어 고민이 공유되는 커뮤니티입니다. 특정 기술이나 역할에 대한 질문과 답변이 축적되어 있어 JD만으로는 알기 어려운 현실적인 정보를 확인하는 데 도움을 줍니다. 블라인드처럼 익명성을 바탕으로 조직 내부 분위기나 보상, 문화에 대한 비교적 솔직한 이야기가 오가는 곳도 있겠죠.

이러한 커뮤니티의 역할은 분명합니다. 채용 플랫폼의 정보를 그대로 받아들이지 않게 만들고, “이 일을 실제로 한다는 건 어떤 의미일까?”라는 질문을 던지게 합니다. 커리어 커뮤니티는 선택을 늦추게 만드는 장애물이 아니라 판단을 현실에 가깝게 만드는 보정 장치에 가깝습니다. 감정 쓰레기통도 아니고요.

지금이 아닌 ‘긴 미래’를 바라보게 해주는 IT 인사이트

커리어를 확장하는 과정에서 가장 놓치기 쉬운 것은 관점입니다. 더 좋은 회사로 이동하는 것만으로는 커리어를 설명할 수 없기 때문입니다. 내 직무는 앞으로 어떻게 변할지, 지금 사용하는 기술은 어느 방향으로 진화하고 있는지, 기업과 산업은 어떤 역량을 더 중요하게 보기 시작했는지를 함께 이해해야 비로소 선택이 맥락을 갖게 됩니다.

이때 IT 인사이트는 중요한 입력값으로 작용합니다. IT 인사이트 채널의 공통적인 특징은 단기적인 채용 정보보다 중장기적인 변화를 다룬다는 점입니다. 직무, 기술, 산업의 흐름을 함께 살펴보며 당장의 결정을 재촉하기보다는 선택의 방향을 정리해 줍니다. 그래서 커리어를 하나의 점이 아니라 시간 위에 이어진 선으로 바라보게 만듭니다.

요즘IT는 국내 IT 실무자의 관점에서 기술과 일의 변화를 풀어내며, 직무와 조직의 변화를 이해하는 데 도움을 줍니다. GeekNews는 해외 기술 흐름과 개발자 커뮤니티의 주요 논의를 빠르게 훑어볼 수 있는 창구로 활용됩니다.

글로벌 기술·산업 흐름을 파악할 때는 TechCrunch, The Verge 같은 미디어를 통해 기술과 비즈니스의 접점을 살펴볼 수 있고, Hacker News에서는 개발자와 창업가들이 실제로 어떤 주제에 반응하고 있는지를 확인할 수 있습니다. 약간 독특하나 Product Hunt는 새롭게 등장하는 제품과 서비스가 어떤 문제를 해결하려 하는지 관찰하는 데 자주 쓰이죠. 물론 국내 시장의 흐름과 딱 맞지 않다는 아쉬움이 있긴 해도요.

그래서 IT 인사이트는 이직을 결심하기 전에도, 결심한 이후에도 계속 참고하게 되는 영역입니다. 커뮤니티가 현재의 현실 감각을 보완해 준다면 IT 인사이트는 그 현실을 더 긴 시간 축 위에 올려놓는 역할을 합니다. 그리고 이 두 가지가 함께 작동할 때, 커리어 탐색은 단기적인 판단을 넘어 구조를 갖추게 됩니다.

프로 레벨에서 중요한 건 조합이야!

그럼 이 재료들을 어떻게 활용해야 할까?

커리어 탐색의 핵심은 “어떤 프로덕트를 쓰느냐”가 아닙니다. 더 중요한 것은 지금 내 상황에서 무엇을 중심에 둘 것인가입니다. 같은 채용 플랫폼, 같은 커뮤니티, 같은 인사이트라도 어떤 시점에 어떻게 활용하느냐에 따라 전혀 다른 의미를 갖기 때문입니다.

채용 플랫폼, 커리어 커뮤니티, IT 인사이트는 서로를 대체하는 관계가 아닙니다. 각각의 도구는 서로 다른 역할을 맡고 있으며, 함께 사용할 때 비로소 하나의 탐색 구조를 이룹니다. 채용 플랫폼은 선택지가 어디에 열려 있는지를 보여주고, 커리어 커뮤니티는 그 선택지를 현실적인 맥락에서 해석하게 도와주며, IT 인사이트는 그 선택이 더 긴 시간 축에서도 의미가 있는지 점검하게 만듭니다.

이 흐름을 조금 더 단순하게 정리하면, 커리어는 탐색 → 판단 → 행동 → 회고가 반복되는 구조라고 볼 수 있습니다. 그리고 이 과정에서 매 단계마다 중심이 되는 프로덕트는 달라집니다. 중요한 것은 요즘 좋다는 프로덕트를 무작정 많이 쓰는 것이 아니라 지금 내가 서 있는 위치에 맞춰 중심을 이동시키는 일입니다.

지금 내 상황에 따라 달라지는 활용 조합

아래는 IT 직군이 실제로 자주 활용하는 커리어 탐색의 대표적인 조합들입니다.

핵심은 단순합니다. 커리어 탐색에는 정답 도구가 있는 것이 아니라 정답에 가까워지기 위한 순서와 조합이 있을 뿐이라는 점입니다. 지금 당장 이직을 하지 않더라도 인사이트와 커뮤니티를 통해 방향을 잡을 수 있고, 실제로 움직여야 하는 순간에는 채용 플랫폼이 중심이 됩니다.

커뮤니티의 활용 방식을 바꿔볼 수도 있습니다. 익명에 기대 정보만 취할 수도 있지만, 공격적으로 콘퍼런스나 스터디를 잡아 활동할 수도 있죠. 시간은 꽤 들어간다 해도 그 자체로 역량의 향상이나 인맥 확장을 노려볼 수도 있습니다.

결국 선택의 구조를 만든다는 것은, 더 많은 정보를 쌓는 일이 아니라 정보를 쓰는 순서를 정리하는 일에 가깝습니다. 이 구조가 정리되어 있을수록 커리어의 다음 선택은 우연이 아니라 의도에 가까워집니다.

마치며: 커리어에도 전략이 필요하다

어렵죠. 먹고 사는 건 쉽지 않습니다. 그렇다고 울고만 있기엔, 우리는 직장에서 너무 많은 시간을 보냅니다. 그러니 커리어를 우연에 맡겨두기보다는 한 번쯤은 구조적으로 바라볼 필요가 있습니다.

누군가는 인사이트니 성장이니 하는 것보다 유명해지고 아는 사람이 많아지는 것이 가장 중요하다고 말할 수도 있습니다. 또 누군가는 지금 맡은 실무를 잘 해내는 것이 전부이며, 커리어는 그 결과로 따라온다고 이야기할 수도 있습니다. 어떤 방식이든 틀렸다고 말할 수는 없습니다. 어떻게든 원하는 회사에서 원하는 일을 하면 되는 거니까요.

다만, 중요한 것은 멈춰 있지 않는 일입니다. 남들이 정한 정답 대신 지금의 나에게 맞는 방향과 속도로 방법을 찾아가는 것입니다. 더 나은 직군으로 확장한다는 것은 더 많은 정보를 모으는 일이 아닌 더 나은 선택을 반복할 수 있는 구조를 만드는 일입니다. 커리어에도 전략이 필요합니다. 거창한 계획 대신 어떤 시기에, 무슨 프로덕트에서, 어떠한 정보를 얻어낼지, 그 조합을 한 번 탐색해 보세요.

여러분은 어떤 채용 플랫폼을 쓰고 있나요?

잡코리아, 사람인, 리멤버, 원티드, 잡플래닛, 인크루트, 점핏, 랠릿의 찐 사용자 리뷰를 남겨 주세요.
아래 폼으로 신청하고 리뷰를 남기기만 해도 네이버페이 3,000원을 무조건 드립니다.
여러분의 리뷰는 또 다른 콘텐츠로 만들어질 예정이에요. 최고의 리뷰를 남긴 분에게는 무려 30,000원!

리뷰어 신청하기

]]>

AI 엔지니어가 말하는 2025년 회고와 2026년 예상

어느덧 2025년도 한 달이 채 남지 않았습니다. 올 한 해는 AI 업계 전반에서도, 그리고 개인적으로도 변화와 발전이 두드러진 시간이었습니다.

얼마 전 구글이 발표한 Gemini-3.0이나 오픈AI GPT-5.2 같은 SoTA(State of the Art) 모델은, 불과 3년 전 우리를 놀라게 한 챗GPT를 장난감처럼 보이게 할 정도로 성장했습니다. 여기에 더해, Cursor AI나 Claude Code 같은 코딩 어시스턴트의 등장이 실제로 미국 빅테크 기업의 엔지니어 대량 해고를 부르며, 더 이상 개념이 아닌 실존적인 위협으로 나타나기도 했습니다.

<출처: novelvista>

그러한 기술 발전과 함께 AI 엔지니어의 역할도 정말 많이 달라졌습니다.

제가 수년 전 처음 AI 분야에서 일을 시작했을 때만 해도, 직접 데이터를 수집해 라벨링하고, 과적합(overfitting)을 피해 모수와 초매개변수(Hyperparameter)를 조정하며, TensorFlow나 Keras 같은 라이브러리를 활용해 딥러닝 모델을 한땀 한땀 학습시키는 일이 주된 업무였습니다.

하지만 지금은 이런 종류의 작업에 대한 수요가 많지 않습니다. 그 대신, 누가 더 LangGraph 같은 프레임워크를 활용해 멀티 LLM 구조를 잘 구현하는지, 함수 호출(function calling)로 필요한 기능을 적재적소에 배치하며 빠르고 정확하게 구현하는지, 그러한 역량이 훨씬 더 중요해졌습니다.

문제는 변화의 속도가 너무나도 빠르다는 점입니다. 앞으로 2~3년 뒤 어떤 기술이 중요해질지조차 알 수 없을 정도입니다. 이처럼 AI 업계에 적응해 나아가는 과정은 고뇌의 연속입니다. 어제의 최신 기술이 내일이면 구닥다리로 전락할지도 모르는 환경이기 때문입니다.

그래도 어느덧 4년 차에 접어든, 아직은 많이 부족한 엔지니어의 시선으로 지난 한 해를 돌아보며 회고해 보려 합니다.

2025년도 쉴 새 없이 달려온 AI 업계

2025년 한 해도 AI 업계는 말 그대로 쉴 틈 없이 발전해 왔습니다. 돌아보면, 올해 AI 업계의 가장 큰 변화는 ‘LLM 성능의 상향 평준화’와 ‘에이전틱 AI의 확산’이라고 보입니다.

먼저 가장 눈에 띄는 변화는 AI의 ‘두뇌’라 할 수 있는 LLM 성능의 상향 평준화입니다.

올해 초 중국 딥시크가 출시한 가성비 추론 모델 DeepSeek-R1을 시작으로, 저가 추론형(reasoning) 모델 경쟁이 본격화됐습니다. 여기에 오픈AI가 가세하며, 8월에는 오픈웨이트 기반의 GPT-OSS 모델이 등장했고, 11월에는 최신 모델 GPT-5.1이 연이어 나왔습니다.

마치 화룡점정처럼 구글이 역대 최고 성능을 내세운 Gemini-3.0을 발표했고, 엔트로픽 역시 코딩에 강점을 가진 Claude-4.5-Opus를 선보였습니다. LLM 성능이 전반적으로 상향 평준화되고 있다는 경향이 뚜렷한 모습입니다.

<출처: prismetric>

또 하나의 중요한 변화는 에이전틱 AI(Agentic AI)의 보편화입니다.

멀티 에이전트 구조의 AI 에이전트를 손쉽게 구현할 다양한 오픈소스 프레임워크가 등장한 데다, 여러 데이터 소스와 도구를 에이전트 워크플로우에 쉽게 연결할 수 있는 MCP 같은 프로토콜도 등장했습니다. 그 결과, AI의 ‘손과 발’에 해당하는 다양한 도구를 ‘두뇌’인 LLM과 연결하는 일이 이전보다 훨씬 쉬워졌습니다.

그렇게 AI의 두뇌와 손과 발, 모든 기술이 고르게 발전하며 많은 기업과 개인이 본격적으로 업무와 일상에 AI 에이전트를 도입하기 시작한 것입니다.

<출처: Wing Venture Capital>

2025년도 내가 얻은 교훈

2025년을 돌아보며 가장 크게 느낀 점은, 빠르게 변화하는 AI 업계 속에서 결국 나를 앞으로 나아가게 하는 것은 거창한 기술이나 전략이 아니라 ‘태도’와 ‘행동’이라는 단순한 사실이었습니다. 화려한 기술들이 파도처럼 밀려온 한 해였지만, 그 속에서 오히려 더욱 선명해진 세 가지 교훈이 있었습니다.

1. 완벽보다는 일단 하는게 낫다(Done is better than perfect)

무엇보다 먼저, 올해는 “완벽보다는 일단 하는 것이 낫다(Done is better than perfect)”는 사실을 뼈저리게 느꼈습니다. AI 업계는 잠시만 머뭇거려도 흐름이 바뀌어 버리기 때문에, 완벽을 기약하며 준비만 하다 보면 뒤처지기 쉽습니다.

물론 AI 역시 최종 결과물이 주는 만족도가 높아질수록 비즈니스 임팩트도 함께 커집니다. 다만 어느 지점을 지나면, 추가로 투입하는 노력에 비해 기대되는 성과가 거의 늘지 않는 구간에 도달하게 됩니다. 즉 일정 수준에 이르면 더 다듬는 것보다 ‘내보내고 다음으로 넘어가는 것(Ship and move on)’이 훨씬 효율적인 선택이 됩니다.

<출처: Toward Data Science>

여러 AI 프로젝트를 진행하며 제가 느낀 지점도 바로 이것이었습니다. 변화가 빠르고 정답이 정해져 있지 않은 환경에서는, 완벽하지 않더라도 빠르게 시도해 보는 태도가 오히려 더 중요할지도 모른다는 것입니다.

경험상 새로운 기술을 접할 때, 완전히 이해할 때까지 기다리기보다는 작은 기능이라도 직접 만들어 보고 업무에 적용하는 편이 훨씬 빠른 성장을 가져왔습니다. 결국 많은 프로젝트와 사이드 작업 모두 이 ‘일단 해보는 용기’에서 출발했던 것 같습니다.

2. 모든 것을 알고있는 권위자 따위는 잊어라

두 번째로 느낀 점은, 생각보다 AI 업계에는 아직 “모든 것을 완벽히 꿰뚫는 권위자 같은 존재는 없다”는 사실입니다. 예를 들어 AI 에이전트는 단순히 하나의 LLM로 이루어진 시스템이 아닙니다. 플래닝(Planning), 도구(Tools), 상태(State), 거버넌스(Governance) 등 여러 요소가 유기적으로 연결돼 동작하는 복합 시스템에 가깝습니다. 다시 말해, 다양한 요소가 상호작용하며 결과를 만들어내는 일종의 종합예술이라고 할 수 있습니다.

어쩌면 아직 정답이 없는 AI라는 거대한 실체 앞에서 우리는, 코끼리를 더듬으며 서로 다른 방식으로 코끼리를 묘사하는 장님들과 비슷한 처지일지 모릅니다. 장님들이 코끼리의 한 부분만 만지고 ‘전체가 어떤 존재일 것이다’라고 설명하듯, AI 에이전트 역시 일부만 보고서는 그 전체를 오해하기 쉽습니다. 즉, 지금이야말로 내가 알고 있는 것이 AI의 전부가 아니며, 다른 사람이 말하는 내용 역시 절대적인 정답은 아니라는 시각이 필요하다고 느꼈습니다.

<출처: Freepik>

또한 AI 기술의 발전 속도는 너무 빠르기 때문에, 누구도 모든 것을 알고 있지 않습니다. 모두가 동시에 시행착오를 겪으며 길을 만들어 가고 있다는 표현이 더 가까울지 모릅니다. 당연히 직장 동료나 상사 역시 예외는 아니며, 세계적인 석학이나 기업가라고 해서 크게 다르지 않습니다. 그들의 말은 참고하되, 나만의 기준이 되는 필터로 걸러 듣는 태도가 중요합니다.

그런 만큼 잘 모른다고 불안해하거나, 반대로 자신이 아는 것이 전부라고 자만하기보다는 다양한 기술을 실험하고 새로운 아키텍처를 설계해 보는 경험이 더 의미 있다고 느꼈습니다. 그 과정에서 “내가 지금 하는 시도가 이 업계의 역사를 조금씩 만들어 가고 있구나”라는 감각을 가지고, 즐기면서 일하는 태도의 중요성도 함께 깨달았습니다. 바로 그 순간부터 자신의 판단과 경험을 믿는 법을 자연스럽게 익히게 되었고, 스스로의 역량을 과소평가하지 않는 자세가 얼마나 중요한지도 다시 한 번 깨닫게 되었습니다.

3. 끊임없이 배우고 변화하라

마지막으로, AI 업계에서 “끊임없이 배우고 변화하라”는 태도는 이제 선택이 아니라 생존 전략에 가깝다는 사실을 알았습니다. 어제의 최신 기술이 오늘의 구식이 되는 환경에서, 멈춰 있는 순간은 곧 뒤처지는 순간이었습니다.

다만 변화의 속도에 압도되기보다는, 매일 조금씩 배우고 시도하는 습관을 유지했을 때 오히려 기술의 폭풍 속에서도 중심을 잡을 수 있었습니다. 새로운 프레임워크를 익히고, 논문을 읽고, 직접 실험해 보는 과정은 결국 미래의 나에게 가장 큰 자산으로 남았습니다.

그렇게 올해 얻은 이 세 가지 교훈, 즉 완벽을 포기하고 일단 시작하는 용기, 권위자라는 환상에서 벗어나 스스로의 판단을 믿는 자신감, 그리고 끊임없이 배우고 변화하는 자세는 2026년을 준비하는 지금도 여전히 유효한 나침반입니다. AI 업계의 변화는 앞으로도 멈추지 않겠지만, 이 원칙들만큼은 시간이 지나도 변하지 않을 소중한 자산이라고 생각합니다.

마치며: 2026년은 어떤 한 해가 될까?

2025년은 LLM의 상향 평준화와 에이전틱 AI의 보편화, 그리고 끝없이 변화하는 기술 흐름 속에서 끊임없이 배우고 적응해야 했던 한 해였습니다.

이런 흐름을 돌아보면, 2026년 또한 올해의 연장선이면서도 한 단계 더 도약하는 해가 될 것처럼 보입니다. 매년 기술 트렌드를 예측하는 가트너는 2026년에도 멀티 에이전트, 도메인 특화 언어 모델, 피지컬 AI, AI 보안 플랫폼 등 수많은 AI 기술이 쏟아져 나올 것으로 전망하고 있습니다.

<출처: Gartner>

돌이켜 보면, 올해는 예측하기 어려운 변화 속에서 때로는 두려움도 느꼈지만, 그만큼 새로운 기회가 끊임없이 열렸던 한 해이기도 했습니다. 그렇기에 오히려 2026년은 조금 더 담대하게, 조금 더 즐겁게, 그리고 조금 더 주도적으로 미래를 맞이해 보면 어떨까요?

기술은 여전히 빠르게 변화하겠지만, 그 속에서 어떤 선택을 하고 어떤 길을 만들어 갈지는 결국 나의 태도와 실행에 달려 있을 것입니다.

]]>

질문도 아키텍처다: CDN으로 배우는 개발자 소통법

<출처: 작가, OpenArt로 생성>

혹시 이런 메시지 받아본 적 있나요?

질문 A | 저… 혹시 지금 시간 되시나요? 에러가 나는데 봐주실 수 있나요?

또는 이런 메시지를 받은 경험도 있을 거예요.

질문 B | 제가 어제 A 피처를 개발하다가 B 기획 문서를 다시 보게 되었는데요, C 기능의 히스토리를 살펴보니 과거 D라는 이슈가 있었더라고요. (중략) 그래서 말인데, 혹시 이번 E 이벤트 배너의 롤백 기준이 정확히 어떻게 되나요?

질문 A에는 맥락이 너무 없습니다. 그래서 답변자가 ‘무슨 에러를 말하시는 건가요?’, ‘어떤 상황인가요?’라며 되물어봐야 합니다. 반면 질문 B는 맥락이 지나치게 많습니다. 그러니 답변자가 ‘그래서 질문이 뭐지?’라며 핵심을 찾아내야 합니다.

두 상황 모두 개발 현업에서 흔히 벌어지는 대표적인 소통 문제입니다. 상대를 고려하지 않은 질문으로 동료의 몰입은 깨지고, 문제 해결은 자연스럽게 늦춰집니다.

그렇다면 이런 문제의 근본 원인은 무엇일까요? 저는 그 원인이 ‘소통 레벨 설정’의 실패에 있다고 생각합니다. 질문받는 상대방이 이미 알고 있는 정보가 전혀 고려되지 않은 상태죠.

아직 이해가 가지 않는 분들을 위해 이런 소통 문제를, 개발자에게 가장 친숙한 기술 중 하나인 CDN(Content Delivery Network)에 빗대어 설명해 보려고 합니다. 이제 질문은 하나의 ‘데이터 요청(Request)’으로, 그 질문을 받는 상대방의 머릿속은 ‘Edge(캐시 서버)’에 가깝다고 생각해 봅시다. 우리가 CDN을 어떻게 사용할지 설계하듯, 질문 역시 상황에 맞게 설계해야 합니다. 상대방이 알고 있는 정보를 활용할지, 아니면 모든 정보를 전달할지 고민해야 한다는 뜻입니다.

그렇게 질문이 막연히 두려운 주니어 개발자, 팀원들의 비효율적인 질문에 지친 시니어와 리더 모두에게 ‘효율적인 질문 방법’을 제시해 보려 합니다.

소통으로 생기는 문제는 비용이다

우리는 흔히 소통을 예의나 감정의 영역으로 생각합니다. 하지만 IT 현업, 특히 개발 조직에서 소통은 분명 비용의 영역에 속합니다. 비효율적인 질문은 그 비용을 기하급수적으로 키우는 요소입니다.

답변자의 비용: 컨텍스트 스위칭

개발자에게 가장 비싼 자원은 몰입입니다. 복잡한 로직을 머릿속에 펼쳐 두고 코드를 작성하거나 아키텍처를 설계하던 중, 맥락 없는 질문을 받는 상황을 떠올려 보세요. 집중하던 모든 정보가 한순간에 흩어집니다. 이때 뇌에서 발생하는 ‘컨텍스트 스위칭(Context Switching, 문맥 교환)’ 비용은 생각보다 훨씬 큽니다.

“팀장님, 에러가 나요…”라는 단순한 질문 하나가, 팀에서 가장 연봉이 높은 인력의 시간을 그대로 삭제하는 셈입니다. 이 비용은 결국 제품 출시 지연과 기회비용 손실로 이어집니다.

질문자의 비용: 재작업

그렇다면 비용은 답변자에게서만 발생할까요? 그렇지 않습니다. 질문자 역시 원하는 답을 제때 얻지 못하거나, 잘못된 답변을 바탕으로 의사결정을 하면 재작업 비용을 떠안게 됩니다.

대표적인 사례가 바로 ‘XY 문제(XY Problem)’입니다. 이는 질문자가 실제로 해결해야 할 문제 X에 대해, ‘Y가 해결책일 것’이라고 지레짐작한 다음, 다른 사람에게 Y를 수행하는 방법을 묻는 현상을 말합니다.

X(진짜 문제): 업로드된 이미지 파일의 확장자를 알아내야 한다.
Y(잘못된 가정): 확장자는 무조건 3글자니까, 파일명 마지막 3글자를 자르면 되겠다.
잘못된 질문: 팀장님, 자바스크립트에서 문자열의 마지막 3글자를 자르는 함수가 뭐죠?

팀장님은 string.substring(string.length - 3)이라는, Y에 정확히 부합하는 답변을 줍니다. 질문자는 감사 인사를 하고 코드를 적용합니다. 그러나 곧바로 버그 리포트가 올라옵니다. jpeg나 webp처럼 네 글자 이상의 확장자가 들어오면서 오류가 발생한 것입니다. 만약 질문자가 “파일의 확장자를 추출하고 싶어요”라며 X에 기반해 질문했다면, 팀장은 node.js의 path.extname()처럼 확장자를 추출하는 검증된 방법을 안내했을 것입니다.

이처럼 모호하거나 잘못된 질문은 질문자와 답변자 모두에게 재작업, 버그 픽스, 오해라는 여러 비용을 만들어 냅니다.

그렇다면 이 비용을 줄이기 위한 첫 번째 단계는 무엇일까요? 바로 상대방에게 어떤 정보들이 ‘캐시(Cache)’ 되어 있는지를 파악하는 일입니다.

Cache Miss: 컨텍스트를 전달하는 질문법

CDN에서 Cache Miss는 사용자가 요청한 데이터를 Edge가 가지고 있지 않아, Origin까지 데이터를 가지러 가야 하는 상황을 의미합니다. 즉, 비용이 많이 드는 요청입니다.

소통도 마찬가지입니다. 상대방의 머릿속에 관련 정보가 없는 상태, 다시 말해 내 문제에 대한 맥락이 전혀 없는 상황이 바로 Cache Miss입니다. 다른 팀 동료, 기술 커뮤니티나 사내 전체 채널, 해당 프로젝트의 히스토리를 모르는 신규 입사자, 어제 회의에 안 들어왔던 팀장에게 대뜸 상황을 뭉뚱그린 질문을 던지는 것과 같습니다.

<출처: 작가, OpenArt로 생성>

이들에게 그저 “저 에러가 나요….”라고 묻는 것은, 아무 정보도 없는 상태로 CDN에 “데이터 줘!”라고 요청하는 것과 같습니다. 상대방(Edge)은 질문자(Origin)에게 “무슨 데이터?”, “어떤 경로?”, “권한은?”처럼 맥락을 파악하기 위한 질문을 반복해야 합니다. 이 자체로 컨텍스트 스위칭과 재작업 비용은 급격히 커집니다.

그러한 Cache Miss 상황에서 우리가 해야 할 일은 명확합니다. 상대방이 다시 질문하지 않아도 되도록, 첫 질문에 필요한 모든 맥락을 담아 전달하는 것입니다. 그렇다면 이 첫 질문 요청에는 무엇이 담겨야 할까요?

Cache Miss를 만들지 않을, 질문의 4가지 필수 요소

목표: 내가 진짜 하려는 것은 무엇인가?
맥락: 이 문제가 발생한 환경은 어디인가?
시도: 문제를 해결하기 위해 내가 해본 것은 무엇인가?
질문: 그래서 내가 궁금한 것은 무엇인가?

이 네 가지 요소가 질문을 어떻게 바꾸는지, 조금은 극단적이지만 Before/After 예시로 살펴보겠습니다.

Before: 전형적인 Cache Miss 유발 질문

질문자(주니어): 선임님, 혹시 자바스크립트 정규표현식 잘 아시나요? 지금 제가 짠 게 동작하지 않아서요….

답변자(시니어): (한숨) 어떤 정규식이요? 어디서 쓰는데요?

질문자: 회원가입 닉네임 검증하는 건데요.regex.test(nickname)이 자꾸 에러가 나요.

답변자: 코드를 봐야 알 것 같은데... (하던 일 멈춤)

이 대화는 이미 시작도 전부터 3~4번의 질문과 답변으로, 시니어의 몰입을 깨뜨렸습니다. 아직 본론은 시작조차 하지 못했습니다. 이제 4가지 요소를 담아 질문을 개선해 보겠습니다.

After: 컨텍스트를 전달하는 질문

질문자(주니어): 안녕하세요, 선임님. 시간 괜찮으실 때 답변 부탁드립니다.

(목표) 지금 ‘신규 회원가입’ 페이지의 닉네임 유효성 검사 로직을 개발하고 있습니다. 기획상 닉네임은 ‘영문/숫자/한글 조합 2~10자’만 허용됩니다.

(맥락) feature/signup-validation브랜치의useNicknameForm.js훅 35번째 줄에서 작업 중입니다. 코드는 다음과 같습니다.

const REGEX_NICKNAME = /^[a-zA-Z0-9가-힣]{2,10}$/;
// …
const validateNickname = (nickname) => { if (!REGEX_NICKNAME.test(nickname)) { // <-- 35번째 줄 setError('닉네임 형식이 올바르지 않습니다.'); return false; } return true; }

(시도) 대부분 정상적으로 동작하지만, API에서 사용자 정보를 불러오기 전에validateNickname(null)이 호출되면서 35번째 줄에서TypeError: Cannot read properties of null (reading 'test')에러가 발생하는 것을 확인했습니다.

(질문) 이런 예외 케이스를 방어하기 위해 test 메서드 실행 전에 nickname 값의 null 또는 undefined 여부를 먼저 확인하는 것이 좋을 것 같은데요. 혹시 팀 컨벤션상 이런 경우 1) 명시적 null 체크를 선호하는지, 2) 아니면 옵셔널 체이닝(?.)을 사용하는지, 3) 혹은 정규식 자체에 빈 값 케이스를 포함시키는지 궁금합니다.

어떤가요? 이런 질문을 받은 시니어는 코드를 따로 찾아볼 필요도, “무슨 에러인가요?”라고 되물을 필요도 없습니다. 질문자의 고민을 즉시 이해할 수 있고, 질문을 읽는 순간 “우리는 1번 방식을 선호합니다. 이유는…” 또는 “좋은 질문이네요. 2번 방식이 더 깔끔해 보이니 그렇게 적용하죠”처럼 한 번에 가치 있는 답변을 줄 수 있습니다.

이것이 바로 ‘Cache Miss’ 상황에서 질문자가 갖춰야 할, 상대방의 비용을 최소화하는 기술적인 질문법입니다.

Cache Hit: CDN처럼 효율적으로 소통하는 법

Cache Miss와 달리, ‘Cache Hit’은 CDN의 존재 이유이자 가장 이상적인 상태입니다. 사용자의 요청이 가장 가까운 Edge에 이미 저장돼 있어, Origin까지 가지 않고도 빠르게 응답할 수 있는 것입니다. 비용과 시간을 극적으로 절약하는 요청입니다.

소통에서의 Cache Hit 역시, 답변자 모두 이미 맥락을 공유하고 있는 상태를 의미합니다. 이들은 프로젝트의 목표, 사용 중인 기술 스택, 최근 이슈 등 ‘원본 데이터’를 각자의 머릿속(Edge)에 이미 저장하고 있습니다. 이 상태에 머무른 팀의 소통 구조를 CDN에 빗대면 아래와 같습니다.

Origin(원본 서버): 프로젝트의 최종 목표와 핵심 기획 (예: PM의 머릿속, 최초의 사업 기획서)
메인 DB(중앙 저장소): Origin의 정보를 구체화해 정리한 ‘공식 문서’ (예: Jira Epic, Confluence 기획서, Figma 디자인)
Edge(캐시 서버): 이 문서들을 함께 읽고 회의하며 맥락을 공유한 ‘우리 팀원들’의 머릿속

그런데 우리는 종종 이미 Cache Hit 상태인 팀원에게, Cache Miss 질문법을 그대로 사용하기도 합니다. 상황의 네 가지 요소(목표, 맥락, 시도, 질문)를 모두 담아 모든 맥락을 전달하는 것이죠. 이는 실수에 가깝습니다.

Before: Origin 요청을 남발하는 비효율적인 질문

질문자: (어제 회의에 같이 참석한 팀 동료에게) 안녕하세요, A님. 이번 2주 스프린트 목표가 ‘로그인 플로우 안정성 강화’잖아요. 그래서 제가 맡은 티켓이 ‘소셜 로그인 실패 시 예외 처리’ 건인데요. 어제 회의에서 기획자님이 ‘협력사 SDK’의 특정 버전에서 간헐적 에러가 발생한다고 공유해 주셨던 히스토리를 기반으로 (중략) 그래서 말인데, 혹시 어제 공유된 API 에러 코드 목록 중에 ‘ERROR_003’ 코드가 정확히 어떤 케이스였는지 기억나시나요?

이 질문의 문제는 무엇일까요? 답변자는 이미 스프린트 목표와 질문자의 티켓 내용, 협력사 SDK의 히스토리까지 모두 알고 있습니다. 이 정보들은 팀원 A의 머릿속에 이미 캐시 되어 있는 상태입니다. 하지만 질문자는 불필요하게 Origin의 모든 데이터를 다시 전송하고 있습니다. 그 결과 답변자는 “이미 다 아는 얘기인데… 그래서 질문이 뭐지?”라며 방대한 정보 속에서 핵심 질문인 ‘ERROR_003’의 의미를 찾아내는 또 다른 비용을 치러야 합니다.

그래서 Cache Hit 상황에서는 질문을 완전히 반대로 설계해야 합니다.

After: Edge의 캐시를 활용하는 효율적인 질문

질문자: A님, ‘소셜 로그인 예외 처리’ 건인데요. 어제 공유된 API 에러 코드 중에 ‘ERROR_003’이 정확히 어떤 케이스였는지 다시 한번 알려주실 수 있나요?

어떤가요? 훨씬 간결하고 효율적입니다. 상대방이 이미 캐시하고 있는 정보, 즉 소셜 로그인 맥락과 어제 공유된 에러 코드 목록은 캐시를 불러오기 위한 데이터 키처럼 활용하고, 내가 정말 모르는 값인 ‘ERROR_003’의 의미만 콕 집어 요청했습니다. 이것이 바로 Cache Hit 상황에서의 소통법입니다.

<출처: 작가, OpenArt로 생성>

이처럼 팀이란 같은 맥락을 함께 캐시하고, 이를 기반으로 움직이는 집단입니다. 불필요하게 모든 맥락을 다시 설명하기보다는, 이미 캐시된 정보를 효율적으로 활용해야 합니다. 다만 이 강력한 캐시에는 치명적인 함정이 하나 숨어 있습니다. 바로 ‘오래된 캐시(Stale Cache)’ 문제입니다.

오래된 Cache의 함정: 무효화와 동기화

CDN을 운영할 때 신경 써야 할 문제 중 하나, ‘캐시 동기화’입니다. Origin의 원본 파일(예: main.js, event-banner.jpg)이 변경됐는데도 Edge가 이를 인지하지 못한 채 ‘오래된 캐시’를 계속 사용자에게 제공하는 것인데요. 그러면 사용자는 업데이트된 기능을 보지 못하거나, 깨진 이미지를 보게 됩니다. 경우에 따라서는 심각한 장애로 이어질 수도 있습니다.

이러한 문제는 특히 Cache Hit 상태의 팀 소통에서 훨씬 더 심각하고, 또 빈번하게 발생합니다. “팀이란 같은 맥락을 공유하고 캐시하여, 그것을 기반으로 움직인다”고 했지만, 만약 팀원들이 공유하고 있다고 믿는 정보가 사실은 갱신되지 않은 상태라면 어떤 문제가 생길까요?

기획이 어제 바뀌었는데, A는 모르고 이전 버전으로 개발 중이다.
API 명세가 수정됐는데, B는 옛 명세로 데이터를 요청하고 있다.
배포 일정이 금요일로 당겨졌는데, C는 다음 주 월요일로 알고 있다.

이것이 바로 팀을 망가뜨리는 오염된 캐시의 함정입니다.

<출처: 작가, OpenArt로 생성>

팀원들은 우리가 지금 Cache Hit라고 믿으며 효율적으로 질문하고, 효율적으로 개발합니다. 하지만 그 캐시 자체가 이미 오염되었다면, 결국 거대한 재작업이라는 장애로 되돌아옵니다.

“A님, 기획 바뀌었어요. 그거 다 엎어야 해요.”라는 끔찍한 말과 함께 말이죠.

이 재앙을 막기 위해 CDN은 무엇을 할까요? 바로 ‘캐시 무효화(Cache Invalidation)’를 실행합니다. 원본이 변경되면 전 세계의 Edge에게 “이 파일은 이제 쓰레기이니 삭제하고, 다음 요청이 오면 Origin에서 새 파일을 받아 가라”고 명령하는 과정입니다.

이처럼 팀의 소통에도 이런 ‘명시적인 무효화 명령’이 필요합니다.

많은 개발자가 “기획서가 바뀌었으니 Jira 티켓을 수정해 뒀다”거나, “API 명세를 Confluence에 업데이트했다”는 행동으로 자기 할 일을 끝냈다고 착각합니다. 하지만 이는 Origin의 데이터만 바꿔 놓고, Edge에게 “너희 캐시가 오염됐다”고 알리지 않는 것과 마찬가지입니다. 팀원들은 여전히 각자의 머릿속(Edge)에 저장된 ‘오래된 기획’을 기준으로, 자신 있게 Cache Hit를 외치며 잘못된 방향으로 달려가고 있으니까요.

캐시 무효화의 핵심은 전파입니다. 중요한 맥락, 즉 기획이나 명세, 일정이 변경됐다면, 그 정보가 담긴 문서(Jira, Confluence)를 수정하는 데서 멈추면 안 됩니다. 반드시 모든 Edge, 다시 말해 모든 팀원에게 ‘명시적인 무효화 요청’을 보내야 합니다.

A님, B님, C님! 방금 ‘로그인 기획’이 변경돼 Jira 티켓(JIRA-123)을 업데이트했습니다. 주요 변경점은 ‘소셜 로그인 버튼 순서 변경’입니다. 각자 내용을 다시 확인(캐시 무효화)하고, 새 문서 기준으로 작업 부탁드립니다!

이것이 Slack이나 이메일, 혹은 짧은 데일리 미팅을 활용한 ‘소통에서의 캐시 무효화’입니다. 이 명시적인 전파 한 번이, 팀 전체의 며칠 치 재작업 비용을 막아줍니다.

마치며: 내 질문은 Origin을 향하는가, Edge를 향하는가?

지금까지 ‘질문’이라는 소통의 문제를 ‘CDN과 캐시’라는 기술의 언어로 재해석해 보았습니다. 핵심은 이렇습니다.

1. 소통 문제는 ‘비용’이다: 비효율적인 질문은 답변자의 ‘컨텍스트 스위칭’ 비용을, 질문자의 ‘재작업’ 비용을 발생시키는 값비싼 문제입니다.

2. 맥락을 모르는 상대(Cache Miss): 상대가 내 맥락을 모른다면, ‘목표, 맥락, 시도, 뾰족한 질문’이라는 네 가지 요소를 담아 맥락 전체를 전달해야 합니다.

3. 맥락을 아는 상대(Cache Hit): 상대가 이미 맥락을 알고 있다면, 불필요한 배경 설명(‘Origin 요청’)은 줄이고, 상대가 알고 있는 정보(‘Edge’)를 활용한 간결한 핵심 질문을 던져야 합니다.

4. 정보 동기화(Cache Invalidation): 기획 변경처럼 중요한 내용이 갱신됐다면, 반드시 명시적인 ‘전파’(무효화 요청)를 통해 팀원들의 ‘오염된 캐시(Stale Cache)’를 삭제하고 동기화해야 합니다.

결국 소통을 원활하게 만드는 사람이란 단순합니다. “지금 이 질문이 Origin(원본 서버)을 향해야 할지, Edge(캐시 서버)를 향해야 할지 정확히 아는 사람”입니다.

상대방의 캐시 상태를 존중하는 질문법은 팀의 비용을 줄이고, 재작업을 막으며, 서로의 몰입과 시간을 지켜줍니다. 이 글이 여러분의 소통 병목을 개선하는 데 작은 도움이 되기를 바랍니다.

]]>

스타트업 출신 개발자로 네임드 기업에서 AI와 살아남기

2025년을 돌아보면, 그냥 ‘바빴다’는 말로는 도저히 설명할 수 없습니다.

올해 저는 어느덧 8년 차 개발자가 되었고, 작은 스타트업을 떠나 개발자 동료가 정말 많은 네임드 기업에서 새로운 도전을 시작했습니다.

솔직히 말해, 이 환경 자체가 저에게는 완전히 새로운 세계였어요. 7년 동안은 소규모 스타트업에서 ‘내가 모든 걸 직접 해내야 하는’ 구조 속에 있었습니다. 하지만 올해는 수십 명의 개발자가 함께 일하는, 체계적인 팀과 정교한 프로세스 한가운데에 섰죠.

그 순간부터 저는 자연스럽게 이런 생각을 하기 시작했습니다.

“여기서도 내가 살아남을 수 있을까?”

그런 관점에서 돌이켜보면, 올해 제가 했던 건 단순 ‘버티기’가 아니었습니다. 살아남기 위해 정말 필사적으로 발버둥 쳤던 한 해였어요.

개발 실력만으로는 밀어붙일 수 없다는 사실을 인정해야 했고,

새로운 조직문화와 커뮤니케이션 방식, 더 높은 기준,

그리고 무엇보다 ‘AI라는 거센 폭풍’을 온몸으로 맞아야 했습니다.

그래서 이번 글에서는 저처럼 변화 속에서 허덕였던 분들이 조금이라도 공감할 수 있도록, 그리고 앞으로의 시대에서도 잘 살아남을 수 있도록, 제가 몸으로 부딪치며 배운 노력과 작은 깨달음들을 솔직하게 나눠보려 합니다.

혹시 지금 여러분도 불안한 마음으로 막연히 “앞으로 괜찮을까?”라는 생각을 하고 있다면, 오늘 이 글이 아주 작은 힌트라도 되었으면 좋겠습니다.

PART 1. 스타트업 개발자가 네임드 기업에서 살아남는 방법

커뮤니케이션 능력이 더없이 중요하다

<출처: 작가, 챗GPT로 제작>

이번 이직 전까지 저는 매우 작은 스타트업에서 일을 해왔습니다. 같이 일하는 개발자가 많아봤자 6~7명 남짓이었고, 대부분 초기 서비스를 만들어가는 과정이었습니다. 자연스럽게 기획부터 참여했고, DB 설계, 인프라 구성, API 설계와 개발, 관리자 페이지 제작, 운영·유지보수까지 서비스 개발 전반을 거의 혼자 커버할 수 있는 환경이었습니다.

그러다 보니 제 역량도 넓고 얕지만 전체를 아우르는 형태로 확장되었고, 타 직군과의 커뮤니케이션에서도 큰 문제를 겪은 적이 없었습니다. 오히려 저는 소통이 나의 강점이라고 착각하고 있었습니다.

하지만 이미 오랜 서비스가 운영되고 있는 네임드 기업에 들어와 보니, 제가 커뮤니케이션에서 얼마나 약점이 많은지 뼈저리게 알게 되었습니다. 백엔드 파트 내 수많은 동료의 PR 리뷰 코멘트, 설계 과정에서의 깊은 토론, 기획과 정책에 대한 의견 조율 등 모든 과정이 이전과는 완전히 다른 깊이와 복잡도를 가지고 있었습니다. 어떻게 말해야 하는지, 어떤 방식으로 설득해야 하는지 감을 잡지 못했고, 그 상태로 3개월이 순식간에 지나갔습니다.

수습 기간은 무사히 넘겼지만, 그 이후 결제 관련 중요한 태스크를 맡았다가 정책을 잘못 이해해 큰 손실이 날 뻔한 적까지 있었습니다. 일정조차 지키지 못했고, 회사 입장에서는 시간과 인력 리소스를 낭비한 셈이 되어 버렸습니다. 그 시기에는 제 커리어 전체에 의문이 생길 정도로 큰 충격을 받았습니다.

그렇게 깨달았습니다. 큰 조직은 일하는 방식 자체가 완전히 다르다는 것을. 이곳은 혼자 다 이해했다고 생각하고 개발해서는 절대 안 되는 환경이었습니다. 모르는 것은 적극적으로 묻고, 완전히 이해될 때까지 확인하고, 관련자 모두에게 더블체크 받고, 작은 변경이라도 여러 직군과 함께 조율해야, 제 일을 제대로 한 것입니다.

처음에는 회사가 나와 맞지 않는다고 생각했습니다. 하지만 서비스 규모가 크고 레거시가 깊은 조직에서는 이런 방식이 필연적으로 발생할 수밖에 없다는 사실을 점차 받아들이게 되었습니다. 개발, 코드 수정, 배포 어느 하나 마음대로 하기보다, 전체 팀 관점에서 순서는 맞는지, 놓친 리스크는 없는지 먼저 판단해야 했습니다. 넓은 관점에서 보면 이것도 결국 커뮤니케이션 능력이라는 생각이 들었고요.

지금은 제 역할에서 최선을 다하며, 제가 맡은 일이 동료들의 작업 흐름에 방해되지 않도록, 그리고 어떤 문제도 생기지 않도록 꾸준히 노력하고 있습니다.

단순 개발 역량보다 눈치, 센스, 배려가 훨씬 중요하다

<출처: 작가, 챗GPT로 제작>

큰 조직에 들어와서 정말 크게 느낀 점이 하나 더 있습니다. 생각보다 개발 실력 자체보다 소프트 스킬이 훨씬 더 중요하다는 사실이었습니다. 왜냐하면 같은 개발팀 안에서만 협업하는 게 아니라, 사업실이나 QA팀, 운영팀 등 정말 많은 이해관계자와 함께 일하게 되거든요. 팀마다 일하는 방식도 다르고, 업무 우선순위를 바라보는 관점도 다르다 보니, 어떤 식으로 요청해야 하고 어떤 타이밍에 이야기해야 일이 매끄럽게 풀리는지, 모든 것을 몸으로 배우게 됐습니다.

한번은 이런 일이 있었어요. 배포 후 모니터링을 하면서 운영팀의 지원이 꼭 필요한 태스크가 있었는데, 제가 개발과 배포 준비에만 매몰돼서 운영팀 리소스를 미리 요청하는 걸 완전히 잊어버린 겁니다. 사실은 배포 일정을 잡을 때부터 운영팀과 먼저 커뮤니케이션하고, 어떤 시간대에 누가 지원할 수 있는지 확인해야 했는데, 그 과정을 통째로 스킵해버린 거죠.

결국 배포 직전에 운영팀에 급하게 사정을 전했는데요. 다행히 도움받아 큰 문제 없이 마치기는 했습니다. 하지만 이때 진짜 크게 배웠습니다. ‘내 파트만 보고 일을 처리하면 절대 안 되는구나’, ‘전체 관점에서 보고 필요한 건 미리미리 준비해 두는 게 얼마나 중요한가’를 뼈에 새겼죠.

그 이후로는 제가 원래 그런 일을 좋아하는 타입은 아니지만, 타팀 분들과의 관계를 조금씩 더 다져가려고 노력하고 있습니다. 가벼운 커피챗이라도 해보고, 평소 어떤 부분을 어려워하는지 듣기도 하고, 제 일정을 잡을 때는 어떤 팀의 리소스가 필요한지 먼저 리스트업해둡니다. 그리고 꼭 미리 연락을 드려요. 이 과정 자체가 제가 하는 일을 훨씬 수월하게 만들어주더라고요. 무엇보다 서로 신뢰가 쌓이니까, 작은 요청 하나도 더 자연스럽게 주고받을 수 있게 됐습니다.

‘시스템’과 ‘프로세스’라는 옷 입기

<출처: 작가, 챗GPT로 제작>

이전에는 주로 초기 팀에서 일을 해왔기 때문에, 사실 전체 시스템이 제대로 갖춰지지 않은 상태에서 시작하는 경우가 대부분이었습니다. 협업 문화라는 것도 처음부터 만들어진 것이 아니라, 일하면서 하나씩 직접 쌓고 정착시키는 과정이 오히려 자연스러웠어요. 특히 백엔드 중심으로 일하다 보니, 코드 리뷰나 코드 컨벤션처럼 여러 명이 함께 일할 때 필요한 룰들이 느슨했던 것도 사실입니다. 당장 서비스가 돌아가는 게 더 급했으니까요.

그런데 이번에 규모가 큰 회사에 오고는 완전히 다른 세계를 경험했습니다. 타 팀에 업무를 요청할 때도 일정한 약속, 즉 프로토콜이 있습니다. 어떤 양식으로 요청해야 하는지, 어느 단계에서 누구에게 먼저 공유해야 하는지, 언제까지 무엇을 준비해야 하는지가 다 정해져 있었죠. 그 흐름을 정확히 따라야만 일들이 자연스럽게 움직입니다.

새로운 프로그램을 사용하고 싶어도 바로 쓸 수 있는 게 아니라, 결제 문서를 올리고 승인을 받아야 합니다. 처음에는 이런 시스템과 프로세스가 정말 갑갑하게 느껴졌습니다. “이걸 굳이 문서로 또 올려야 하나?”, “이 절차만 없으면 바로 일할 수 있을 텐데…” 하는 생각을 수도 없이 했어요. 솔직히 시간 낭비라고 느낀 적도 많았습니다.

하지만 결국 받아들였습니다. 회사 규모가 커질수록 누가 어떤 권한을 갖고 무엇을 사용할 수 있는지가 명확하게 정리되어 있어야 합니다. 그게 팀을 보호하는 장치이기도 하더라고요. 모두가 각자 방식으로 일하기 시작하면 오히려 더 큰 혼란이 생기는 구조라는 걸 점점 이해하게 됐습니다.

그래서 요즘은 조금 더 센스를 발휘하려고 합니다. 필요한 프로그램은 미리미리 결제를 올려두고, 승인까지 걸리는 시간을 감안해 일정도 여유 있게 잡습니다. 꼭 결제가 필요하지 않을 것 같은 경우에는 미리 담당자에게 확답을 받아두고, 불필요하게 대기하는 시간을 만들지 않으려 해요. 결국 중요한 건 시스템과 프로세스를 거스르지 않으면서, 그 안에서 최대한 효율적인 흐름을 만드는 것이더라고요.

이제는 그 방식이 꽤 잘 맞는 편입니다. 오히려 한 번 세팅해 두면 예측 가능한 흐름 속에서 안정적으로 일할 수 있다는 점이 장점이라는 것도 깨달았고요.

대규모 트래픽에 대한 경험

<출처: 작가, 챗GPT로 제작>

스타트업에서 일하면서 개인적으로 가장 아쉬웠던 부분이 하나 있었습니다. 바로 대규모 트래픽을 직접 다뤄본 경험이 거의 없었다는 점이었어요. 이건 “하고 싶다”고 해서 할 수 있는 경험이 아니고, 회사가 가진 트래픽 규모에 따라 자연스럽게 정해지는 부분이니까요.

그래서 이번에 DAU 30만이 넘는 서비스를 다룬 건 저에게 정말 큰 도전이었습니다. 이 정도 규모에서는 아주 작은 기능 하나 추가하는 것도 조심스럽습니다. 사소한 부분만 놓쳐도 예기치 않은 장애로 이어질 수 있기 때문에, 더더욱 디테일하게 체크하고 설계해야 했습니다.

또 서비스가 MSA 형태의 여러 도메인으로 나뉘어져 있다 보니, 각각 서비스가 어떤 역할을 하는지 익히는 것부터 만만치 않았습니다. 처음에는 진짜 정신이 하나도 없었어요. 어떤 도메인에서 어떤 이벤트가 발생하고, 그게 어디로 전파되고, 어느 팀이 어떤 부분을 담당하는지 하나하나 이해하는 데 많은 시간이 필요했습니다.

CS 대응을 할 때는 더 복잡했습니다. 특정 문제가 발생하면 정책을 먼저 확인하고, 그 정책이 서비스 여러 개와 어떻게 연결돼 있는지 파악해야 하고, 복잡한 DB 구조와 의존관계까지 모두 살펴봐야 했습니다. 알아야 할 게 너무 많아서 처음엔 진짜 막막하다는 생각이 들 정도였어요.

하지만 그만큼 얻은 것도 컸습니다. 유지보수성을 고려한 디자인 패턴 적용부터 CPU 사용량을 생각한 코드 작성, 쿼리 성능을 높이기 위한 튜닝까지…. 지금 돌이켜보면 백엔드 엔지니어로서 이보다 더 좋은 학습 환경이 없었다는 생각이 듭니다. 이런 경험은 단기간에 얻을 수 있는 게 아니라, 트래픽 규모가 큰 서비스에서 직접 부딪혀야만 배울 수 있는 것들이거든요.

그래서 저는 이런 경험들을 그냥 흘려보내지 않으려고 합니다. 실수했던 부분, 배웠던 패턴, 개선했던 과정들을 모두 꾸준히 기록해 두고 있어요. 시간이 지나면 이 모든 것이 제 커리어에서 정말 큰 자산이 될 것 같다는 확신이 있습니다.

PART 2. AI 시대에 살아남는 방법

AI Tool이라는 신세계를 마주하다

<출처: 작가, 챗GPT로 제작>

솔직히 얘기하면, AI 도구가 이렇게 급속도로 퍼질 줄은 정말 상상도 못 했습니다. 처음엔 그저 하나의 유행처럼 스쳐 지나갈 줄 알았어요. 제가 AI를 처음 접한 것은 아마 Copilot이었던 것 같습니다. 그때만 해도 성능이 지금과는 비교도 되지 않을 정도로 제한적이어서 그저 간단한 예시 코드만 참고하는 수준이었습니다. 그 때문에 크게 관심을 가지지 않고, “아직은 멀었구나”라는 생각이 더 컸습니다.

그러나 GPT와 클로드 같은 모델들이 점점 발전하기 시작하면서 상황이 조금씩 달라지기 시작했습니다. 처음에는 저도 AI를 아주 부분적으로만 사용했습니다. 기술 검토를 해보거나, 설계 아이디어가 막힐 때 가볍게 물어보는 정도였죠. 제가 놓친 관점이 있는지 확인하고, 문서를 더 이해하기 쉽게 정리해달라는 정도로만 활용했습니다.

그런데 모델들이 업그레이드될수록 상황이 확확 바뀌기 시작했습니다. 어느 순간부터는 “이거 꽤 쓸 만한데?”라는 생각이 들 정도로 업무에 실질적인 도움을 주더라고요. 특히 코드 구현을 설계할 때, 좋은 패턴을 참고해야 할 때, 새로운 기술을 적용할 때, 이 모두를 충분히 검토하도록 지원해 주는 역할을 하기 시작했습니다. 마치 사수와 동료 사이 어딘가 보조 엔지니어가 하나 생긴 느낌이랄까요.

이 과정에서 작업 생산성도 자연스럽게 올라갔습니다. 반복 작업이나 문서 작성, 리뷰 포인트 정리 같은 부분은 AI에게 맡기다 보니, 저는 더 중요한 문제 해결에 집중할 수 있었거든요. “AI를 잘 쓰면 정말 좋은 보조 도구가 될 수 있겠구나”라는 생각이 들었고, 그 이후부터는 제 업무 흐름 안에 AI가 자연스럽게 녹아들기 시작했습니다.

물론 그때도 몰랐습니다. 이것이 단순한 도입 테스트 정도가 아니라, 제가 일하는 방식 전체를 바꿔버리는 시작점이 될 줄은 정말 상상도 못 했으니까요.

AI 도구로 생산성을 높이다

<출처: 작가, 챗GPT로 제작>

AI 도구 중에서 제 업무와 사고방식에 가장 큰 충격을 준 건 단연 Cursor였습니다. 아쉽게도 회사 보안 정책 때문에 실제 업무에는 적용하지 못했지만, 개인적으로 간단한 사이드 프로젝트를 만들면서 처음 Cursor를 제대로 사용해봤을 때의 경험은 지금도 잊기 어려워요.

정말로 코드를 일일이 짤 필요가 없었습니다. 그냥 자연어로 설명만 해줬는데, 마치 옆에 앉은 누군가 뚝딱뚝딱 코드를 만들어주는 느낌이 들더라고요. 당연하지만, 오류도 있었고, 제 지시 사항을 제대로 이해하지 못하는 경우도 여러 차례 있었습니다. 하지만 그럴 때마다 “이 부분은 이런 의도다”라고 다시 설명해 주고 apply 버튼만 누르면, 그 방향으로 코드를 고치고 프로젝트를 계속 완성해 가는 모습을 보였습니다.

그러자 갑자기, 서늘한 두려움이 느껴졌습니다. “아, 이거 진짜 곧 일이 크게 바뀌겠구나.” 그런 직감이 강하게 들었습니다.

Cursor가 불러온 화제가 끝나기도 전에, Claude Code라는 CLI 기반 도구가 등장하면서 이 흐름은 거의 전 세계적인 붐으로 번졌습니다. 개발자 커뮤니티 전체가 크게 출렁였고, 저 역시 이 흐름을 거스를 수 없겠다는 감각이 들었습니다. 그래서 회사 업무에서도 어떻게든 LLM 기반 도구를 적용하려고 정말 부지런히 애를 썼습니다.

물론 개인정보나 보안 이슈 때문에 사용할 수 없는 도구들도 많았습니다. 하지만 사용할 수 있다고 판단되는 건 전부 시도해 봤습니다. Claude, Gemini CLI, JetBrains IDE에서 지원하는 AI Assistant, Junie 등 가능한 건 다 직접 테스트하고, 일에 적용할 수 있는 부분을 계속 찾아 나갔습니다.

어느 순간부터는 단순히 AI 도구 하나를 쓰는 수준이 아니라, LLM을 활용한 개발 방법론 자체가 발전한다는 걸 느꼈습니다. “이걸 어떻게 써야 가장 효율적일까?”, “LLM에게 어떤 식으로 설명해야 원하는 설계를 얻을까?” 같은 고민을 하면서 제 개발 방식도 자연스럽게 달라지기 시작했어요.

솔직히 말하면, 회사 분위기는 그저 핫한 도구를 한 번 써보는 정도에 머무르는 느낌이 강했습니다. “편하면 쓰고 아니면 말고” 같은 기조라고 해야 할까요. 하지만 저는 포기하지 않았습니다. 어떻게든 업무에 AI를 적용해 생산성을 높이고, 반복 작업을 줄이고, 더 중요한 문제에 집중할 시간을 확보하려고 했습니다. 이런 변화는 앞으로 선택이 아니라 필수가 될 것이라는 직감이 있었기 때문에, 더 적극적으로 움직일 수밖에 없었습니다.

AI를 동료로 받아들이다

<출처: 작가, 챗GPT로 제작>

예전처럼 LLM에 단순히 질문을 던지고, 답변받고, 이를 업무에 적용하는 방식은 거의 사용하지 않습니다. 그 방식은 너무 느리고, 매번 주도적으로 모든 단계를 챙겨야 하기에 효율이 떨어졌습니다. 이제 저는 본격적으로 에이전트를 사용하며, 제가 하는 업무 프로세스 하나하나에 에이전트가 자연스럽게 들어오도록 꾸준히 시도하고 있습니다.

가장 먼저 자동화를 시도한 건 테스트 코드였습니다. 제가 직접 테스트 코드를 작성하는 대신 스펙을 정리해 에이전트에게 설명하고 맡겨봤습니다. 어떤 의도인지, 어떤 상황을 검증해야 하는지, 어떤 조건을 만족해야 하는지 하나씩 설명해 줬더니, 마치 제가 짰을 법한 테스트 코드를 거의 완성된 형태로 만들어주더라고요. 이 경험 이후로 생산성은 최소 30% 이상은 올라간 것 같습니다.

이제는 처음처럼 질문하고 답을 받는 방식이 아니라, 전체 맥락과 작업 목적을 설명한 뒤 “이 테스트 코드를 작성해라”라고 위임해 두고, 저는 더 중요한 작업을 먼저 처리합니다. 작업이 다 끝나면 에이전트가 알람을 보내주기 때문에, 그때 가서 검수만 하는 식으로 업무 방식 자체가 완전히 달라졌습니다.

이런 경험이 쌓이다 보니, 지금은 AI를 하나의 ‘도구’가 아니라 진짜 동료처럼 받아들이는 마인드셋이 생겼습니다. 그래서 동료에게 하듯 더 잘 이해시키고 더 잘 협업하고 싶어 여러 방법론을 직접 적용해 보고 있습니다. BMAD나 SDD 같은 새로운 개발 방식을 실제 업무 프로젝트에 적용해 보면서, 개발의 패러다임 자체가 바뀌고 있다는 사실을 강하게 체감하고 있습니다.

특히 역할을 나눈 여러 에이전트를 활용하는 BMAD 방법론이 제게 정말 잘 맞습니다. 최근에는 Gemini CLI에 BMAD 개발 환경을 구성해서 사용하고 있고요.

이제 저는 프로젝트 전체 구조나 변경 사항이 있을 때 ‘Architect 에이전트’와 논의합니다. ‘Fullstack Developer 에이전트’에는 실제 구현을 맡겨두고, 중간중간 의견을 주거나 설계 방향을 얘기하며 작업을 이어갑니다. 마치 진짜 팀원들과 일하는 것처럼 대화를 주고받으며 프로젝트를 완성해 가는 방식입니다.

그래서 전체 스펙을 잡는 게 제 업무의 70%를 차지하고, 나머지 구현은 에이전트가 계획한 대로 코드를 만들어줍니다. 저는 검수와 수정, 품질 관리에 집중하며 프로젝트의 큰 방향을 책임지는 역할을 합니다. 개발이라는 업무에서 “내가 손으로 직접 짠 코드의 양”보다 “내가 스펙을 얼마나 정확히 정의했는가”가 훨씬 중요한 시대로 넘어가고 있다는 생각이 듭니다.

마치며

돌이켜보면 2025년은 제게 그 어떤 때보다 변화가 극심했던 한 해였습니다. 완전히 다른 규모의 조직에서 새로운 협업 환경을 익히고, AI라는 거대한 파도 안에서 살아남기 위해 발버둥 치다 보니 어느 순간 시간이 훅 지나 있더라고요. 그런데 이렇게 회고를 해보니, 그 과정들이 결국 저를 더 단단하게 성장시켜 주었다는 생각이 듭니다.

2026년의 방향도 결국 AI일 것입니다. “AI를 동료로 받아들인다”는 건 말은 쉬운데, 실제로는 생각보다 훨씬 큰 마인드셋 전환이 필요하거든요. AI도 실수합니다. 제 말을 잘못 이해할 때도 많고, 엉뚱한 방향으로 답을 줄 때도 있습니다. 그래서 더더욱 함께 일을 잘할 방법을 고민해야 하고, 어떤 설명이 AI에게 가장 자연스럽게 이해되는지 실험해 보려 합니다.

이제는 모두 거부할 수 없는 흐름 위에 올라탔다고 생각합니다. 앞으로는 코드를 짜는 능력 그 자체의 의미는 점점 줄어들 가능성이 높습니다. 오히려 기본 지식에 충실한 상태로, 직접 경험한 문제 해결 과정과 배운 것을 얼마나 잘 정리하고 활용하는지가 훨씬 중요한 역량이 될 것 같습니다.

그렇게 2026년에는 이 흐름 속에서 더 단단해지고, 더 똑똑하게 일할 수 있는 개발자가 되고 싶습니다.

]]>

개발자는 이제 일하는 방식부터 재정의해야 합니다

‘커서맛피아’ 최수민 개발자 인터뷰

불과 몇 년 전까지만 해도 개발자는 누구나 부러워하는 유망 직종이었습니다. 하지만 요즘 분위기는 조금 다릅니다. "AI가 개발자를 대체할 거다"라는 말부터, "그래도 아직 개발자는 필요하다"까지, 개발자의 미래를 놓고 의견이 엇갈리고 있거든요.

결국 모두가 궁금해하는 건 하나입니다. "AI 시대에 개발자는 어떻게 살아남을 수 있을까?"에 대한 답이죠. 최근 요즘IT에서 만난 개발자들도 비슷한 고민을 안고 있었는데요. 이번에 만난 '커서맛피아' 최수민 개발자는 조금 다른 이야기를 들려줬습니다. 개발자의 역할이 사라지는 게 아니라, 일하는 방식 자체가 바뀌고 있다는 겁니다.

실제로 회사를 나와 홀로서기를 선택한 그는 현장에서 여러 변화를 체감했습니다. 특히 '바이브 코딩(Vibe Coding)'이라는 새로운 방식을 만나면서 완전히 다른 길을 찾게 되었다고 하는데요. 이번 인터뷰에서는 '커서맛피아'로 활동 중인 최수민 개발자를 만나, 변화하는 개발자의 역할과 바이브 코딩의 미래에 대한 이야기를 들어봤습니다.

커서맛피아 최수민 개발자 <출처: 요즘IT>

개발자, 왜 홀로서기를 택했을까?

Q. 자기소개 부탁드립니다.

저는 ‘커서맛피아’라는 닉네임으로 활동 중인 최수민입니다. 요즘은 다양한 바이브 코딩 관련 도구 사용법과 AI 코딩 지식을 가르치고 있으며, 유튜브와 스레드에 콘텐츠를 올리고 있고, 교육 과정도 운영 중입니다. 또 ‘부스터 AI’라는 서비스를 운영하면서, 바이브 코딩을 확산시키는 데도 힘쓰고 있습니다.

Q. ‘커서맛피아’라는 닉네임이 독특한데, 어떤 의미가 담겨 있나요?

저는 평소 닉네임 짓는 데 진심인 편인데요. ‘커서맛피아’라는 이름은 사실 ‘나폴리 맛피아’에서 영향을 받았어요. 제 캐릭터를 잘 드러낼 수 있고, 뭔가 고수 같은 느낌도 있어서 마음에 들었죠. 또 당시에는 AI 코딩 툴 중에 커서가 가장 인기가 많았어서, 사람들의 기억에 쉽게 남을 수 있었던 것 같아요.

<출처: 커서맛피아 유튜브 캡처>

Q. 안정적인 커리어를 두고, 새로운 도전을 선택한 이유는 무엇인가요?

사실 누구나 알만한 회사에서 개발자로 일했지만, 만족감이 높진 않았어요. 특히 AI 시대가 오면서 개발자의 역할이 점점 구현 중심으로만 좁아지고 있다는 생각이 들었죠. 비즈니스에 주는 영향력도 크지 않다고 느꼈고요. 결국 “이대로는 더 성장하기 어렵겠다”는 위기감이 들었습니다. 그리고 저는 개발자가 필요한 존재인 건 맞지만, 돈을 벌어다 주는 역할은 아니라는 점도 자주 느꼈어요. 저는 그 다음 단계로 가고 싶었고, 결국 디렉터의 역할을 해야 한다고 생각했죠.

TPM(Technical Project Manager) 역할도 경험해 봤지만, 저는 메이커로서 기여하는 게 더 재밌더라고요. 무엇보다 “사용자와 직접 닿아 있는 일을 해야겠다”는 생각이 강했거든요. 회사 안에서만 움직이면 제 능력을 100% 발휘하지 않고 있다는 느낌이 컸습니다. 그래서 회사를 나왔고, 결국 제가 원하는 건 더 큰 영향력을 만들 수 있는 일, 제 역량을 100% 쓰면서 성장할 수 있는 환경이었습니다.

Q. 회사에 다닐 때와 지금, 가장 큰 차이점이 있다면요?

회사에 다닐 때는 아무래도 제가 가진 잠재력을 온전히 쓰지 못한다는 느낌이 컸어요. 기존 개발자 역할이 점점 구현 중심으로 한정되고, 비즈니스에 끼치는 영향도 크지 않아서 “이대로는 성장할 수 있을까?”라는 고민이 계속됐습니다. 반면, 지금은 제가 원하는 방향으로 전체 공정을 설계하고, 제 리소스를 어디에 쓸지 스스로 결정할 수 있어요. 교육·커뮤니티·도구 개발까지 다양한 활동을 하면서, 제가 하고 싶은 일을 100% 집중해서 한다는 느낌이 강합니다.

또 회사 안에서는 안정적인 만큼 안주하게 되는 부분이 있었는데, 밖으로 나오니까 오히려 더 주도적으로 배우고 실행해야만 하는 환경이 되더라고요. 그래서 제 성장 가능성을 더 넓게 쓰고 있다는 확신이 들죠. 결정적으로 지금 하는 일이 ‘해외여행’보다 더 좋을 만큼, 재밌다는 점인데요. 제 에너지와 시간의 우선순위를 스스로 정하고, 몰입할 수 있다는 점이 회사 다닐 때와 가장 큰 차이점입니다.

빠르게 해결하는 AI 도구를 만들다

Q. ‘부스터 AI’라는 서비스는 어떤 계기로 만들게 되셨나요?

처음엔 저도 강의나 교육으로 문제를 해결하려고 했어요. 근데 이 방법은 시간이 너무 오래 걸리더라고요. 40분짜리 강의를 찍을 수 있는 시간에, 오히려 그런 니즈를 해결하는 제품을 만드는 게 더 효율적일 때가 많았거든요. 그냥 이걸 빠르게 해결해 주는 도구가 있으면 좋겠다고 생각했죠. 제 아이디어를 바로 기획으로 구체화하고, 문서를 만들고, 코드까지 시작할 수 있게 도와주는 도구요. 그 니즈를 해결해 보자는 마음으로 직접 만들기 시작했고, 그렇게 해서 나온 도구가 지금의 부스터 AI예요. 특히 PM분들이 바이브 코딩 기반으로 창업하거나, 무언가 만들어 보고 싶을 때 추천하는 도구입니다.

부스터 AI <출처: 최수민>

Q. AI 서비스를 직접 만들면서 느낀 점은 무엇인가요?

AI 서비스를 직접 만들면서 느낀 건, 좋은 도구 하나가 사람들의 문제를 정말 빠르게 해결해 줄 수 있다는 점이었어요. 그리고 예상보다 훨씬 다양한 사람들이 제 도구를 활용해 의미 있는 프로덕트를 만들어낸다는 사실도 크게 와닿았죠. 실제로 유의미한 프로젝트들이 만들어지는 걸 보면서, “이게 진짜 도움이 되는 방식이구나”라고 느꼈습니다.

또 하나 인상적이었던 건, 리텐션 데이터가 보여주는 사용자들의 열성도였어요. 리텐션 95% 이상인 유저가 전체의 15%를 넘었을 때, “아, 이 제품이 정말 사람들에게 가치가 있구나”라는 확신이 들었습니다. 그래서 결제 기능도 일부러 많이 미뤘고요. 결제 구현에 2~3일 쓰기보다, 그 시간에 제품을 더 만들고 개선하는 게 더 재미있고 동기부여가 됐습니다.

Q. 현재 ‘바이브 코딩’에 대한 반응이 뜨거운데요. 어떻게 보고 계신가요?

저는 바이브 코딩을 AI에게 ‘의도를 잘 전달하는 과정’이라고 생각해요. 누구나 활용할 수 있는 재밌는 도구고, 일상적인 니즈를 해결하는 데도 쓸 수 있지만, 개발자는 전문가로서 더 깊게 다뤄볼 수 있죠. 그리고 중요한 건 지금 많은 개발자들이 “AI 때문에 내 역할이 대체될까?” 걱정하지만, 저는 오히려 가장 유리한 포지션에 서 있다고 생각하거든요. 그래서 이 흐름에 잘 올라타는 게 정말 중요하다고 봅니다.

Q. 바이브 코딩을 두고 “나중엔 문제가 생길 거고, 유지 보수도 어려울 거다.”라는 의견도 있어요.

그런 이야기도 많죠. 그런데 저는 오히려 개발자로서의 자아를 조금 내려놓고, AI를 레버리지하는 방식으로 접근해야 한다고 생각합니다. 바이브 코딩이 등장하면서 생산성 시장에서 변화가 확실하거든요. 실제로 단가도 낮아지고 있고, 변화가 빠른 시장에서는 이 흐름이 더 강하게 체감되고 있어요. 또 비개발자가 만들었을 때 유지보수 문제가 생길 수 있다는 우려도 있는데, 저는 그게 “개발을 몰라서”라기보다는 서비스를 만드는 과정 자체가 어렵기 때문이라고 봐요. 기획, UX, 시스템 설계 등 고려해야 할 게 너무 많거든요. 그래서 일상적 용도로 만드는 건 크게 문제가 없지만, 실제 서비스로 출시할 때는 충분한 검토가 필요하다고 생각해요.

기술을 넘어, 배움과 연결로

Q. 기술 개발뿐만 아니라 교육/커뮤니티 활동도 하고 계신데, 특별한 이유가 있나요?

처음부터 교육이나 커뮤니티에 뜻이 있었던 건 아니었어요. 그냥 제가 시작할 때 SNS가 핫했고, “이걸 활용 안 하면 바보 아닌가?”라는 생각으로 가볍게 시작했어요. ‘커서맛피아’라는 활동도 별생각 없이 올렸고, 저에게 재밌는 주제가 AI였을 뿐이에요. 비즈니스로 키울 생각까진 없었는데, SNS를 하다 보니 브랜딩 채널로서의 힘을 확실히 느꼈어요.

확실한 장점은 무언가 새로 시작했을 때 사람들의 관심과 호응을 빠르게 확인할 수 있고, 팬층이 생기면 “지금 제 타깃 유저가 정확히 뭘 원하는가”를 피부로 느낄 수 있거든요. 특히 스레드는 발행하기도 쉬워서, 사람들이 좋아하는 흐름을 빠르게 파악하는 데 도움이 됐습니다. 그래서 어느 순간, 단순히 기술을 가르치는 게 아니라, 사람들과 연결되는 창구를 만드는 게 더 중요하다는 걸 깨달았어요. 지금은 그런 연결이 제 활동을 확장시키는 핵심 동력이 되고 있습니다.

Q. 스레드, 유튜브 등을 운영하시는데, 각 플랫폼에서는 어떤 방식으로 활동하시나요?

사실 유튜브는 저도 감을 잡아가는 중이에요. 개발하다가 “이거 괜찮네? 이걸 모른다고?” 싶은 포인트가 있으면, 바로 촬영해서 올리고 있습니다. 또 스레드의 경우, 발행 자체가 굉장히 쉬워서 훨씬 가볍게 지식을 공유하고 있어요. 레니 팟캐스트나 다른 콘텐츠를 열심히 보다가, 누가 좋다고 하면 바로 시도해 보고, 그 경험을 정리해서 개발자 관점의 인사이트와 팁을 곁들여 글을 올리죠. 그리고 그 과정을 궁금해하는 분들이 많아, 라이브로 직접 보여드리기도 하고요.

바이브코딩 라이브 교육 자료 <출처: 커서맛피아>

Q. 이런 활동들이 개발자에겐 어떤 도움이 되나요?

SNS 활동은 저의 ‘홀로서기’에서 중요한 지속 가능한 연결고리가 되어줬어요. 혼자 나왔을 때 제일 큰 고민이 “이제 혼자인데, 사용자는 어디서 만나지?”라고 생각했거든요. 그런데 스레드나 유튜브를 꾸준히 하다 보니, 나름 팬층도 생겼고, 다양한 업계 사람들과 직접 대화하며 네트워크가 넓어졌습니다. 예를 들면, 연구소 소장님이나 병원을 운영하시는 분들 등 상상도 못 한 분들과도 연결됐죠. 또 그분들의 집념과 고민을 보며 저도 많이 배웠고요. 결국 사용자와 가까워지면서, 시장의 흐름도 더 빨리 읽게 됐어요. 만약 혼자만의 길을 만들어가는 분들이 있다면 적극 추천하고 싶습니다.

개발자의 일과 성장

Q. 현재 여러 가지 일을 병행하고 계신데, 시간 관리는 어떻게 하시나요?

저는 저녁 시간에 집중이 잘 돼서, 저녁 이후는 온전히 코딩하는 시간으로 비워두고 있어요. 그전까지는 비교적 루틴하게 하루를 쪼개서 운영합니다. 오전에는 메일 답장하고, 커뮤니케이션하고, 필요한 의사소통을 먼저 처리해요. 점심 먹고 나서는 운동도 하고, 그다음엔 개발 작업이나 교육 관련 준비를 합니다. 그리고 저녁이 되면 다시 흐름이 잡혀서, 밤까지 쭉 코딩하는 편이에요. 이런 구조가 저에게는 여러 일을 병행하면서도, 페이스를 유지할 수 있는 가장 안정적인 방식이더라고요.

Q. AI가 ‘개발자의 역할을 대체할 수 있다’라는 불안감이 점점 커지고 있는 것 같아요.

물론 불안할 수 있어요. 그런데 실제로 보면, 개발자가 사라진다기보다는 개발자의 역할이 완전히 재정의되고 있다고 느낍니다. 요즘의 트렌드가 “AI를 조수처럼 쓰는 개발자”라면, 앞으로는 코드를 직접 들여다보는 시대가 아니라, AI가 개발적 의사결정까지 맡는 시대가 오는 거죠. 개발자가 AI를 레버리지하는 방식으로 일하게 되는 겁니다.

AI가 코딩을 더 잘하는 영역이 분명히 있어요. 그래서 사람이 직접 코드를 작성하는 건 오히려 비효율적인 경우도 많습니다. 중요한 건 문제를 정의하고, AI가 ‘생각하는 머신’처럼 작동하도록 설계하고 엮는 능력이에요. 이 부분은 여전히 사람의 역할이고, 앞으로 더 중요해질 겁니다. 결론적으로 개발자는 사라지지 않겠지만, 대신 공정을 설계하고 관리하는 역할, 즉 설계자·관리자 역할로 이동할 거라고 생각합니다. 생산직형 개발자는 줄어들 수도 있지만, AI 시대에 더 필요한 개발자는 확실히 존재하고요.

Q. 이런 불안 속에서 개발자가 성장하려면, 어떤 역량을 키워야 할까요?

의외의 답변일 수 있지만, 저는 글쓰기 능력이 정말 중요하다고 생각해요. 개발자분들 중에는 그런 감을 잘 못 느끼는 경우가 많은데, 사실 프롬프팅도 결국 글쓰기거든요. 경험을 블로그나 글로 정리해 보면 “어떻게 전달해야 AI가 더 잘 이해할까?”라는 감각이 자연스럽게 생기고, 이게 결국 AI 시대에 더 큰 힘이 됩니다.

또 한 가지는, 본인이 직접 만들어보는 경험이에요. AI가 이미 잘하는 건 굳이 사람이 연습할 필요 없어요. 대신 AI 없이 못 했을 법한 것들을 시도해보면서, “아, 이렇게 하면 AI를 레버리지해서 훨씬 더 높은 수준까지 갈 수 있구나”라는 감각을 익히는 게 중요합니다. 요약하자면, 글쓰기 기반의 프롬프팅 역량과 AI를 활용해 실제 무언가를 만들어보는 경험. 이 두 가지가 앞으로 개발자가 성장하는 데 핵심 역량이라고 생각합니다.

직접 운영하는 블로그 <출처: 최수민>

Q. 퇴사 후 홀로 서려면 어떤 준비가 필요할까요?

솔직히 말하면, 저는 마음의 준비는 거의 없었어요. “3년 정도는 죽만 쒀도 버틸 수 있다”는 마음으로 그냥 나왔거든요. 오히려 결론을 빨리 내리고 바로 움직이는 게 맞겠다 싶었습니다. 물론 나오고 나서 “준비 좀 하고 나올걸.”하는 생각도 들었죠. ‘외주나 프리랜서 경험을 회사 다니면서 조금씩 쌓아두면 좋았을 텐데…’라고 생각했지만, 막상 이런 걸 준비하려고 하면 계속 미루게 되잖아요.

그래서 저는 주저하지 않고 나오는 것 자체가 가장 중요한 준비였다고 생각합니다. 그리고 나와서 외주 프리랜서도 해보고, 포트폴리오도 만들고, SNS 운영하면서 부딪히고 배워가며 점점 자리를 잡아갔어요. 결국 홀로서기가 저한테는 “완벽히 준비된 상태”가 아니라, 부딪히며 배우는 과정 자체가 준비의 과정이었던 것 같아요.

Q. 최근 ‘부업’에 대한 관심이 높아지고 있는데, 뭐부터 해보면 좋을까요?

저는 사실 부업이나 부수입을 염두에 두고 시작한 건 아니었어요. “돈을 벌어야겠다”라는 마음으로 접근하면 오히려 망할 수도 있다고 생각하거든요. 항상 좋은 무언가를 만들겠다는 마음이 더 중요할 것 같아요. 개발자는 개발만 조금 아는 거지, 비즈니스 마인드로 접근하면 실패할 수도 있거든요.

그래서 처음부터 “이걸로 돈 벌겠다”라고 생각하기보다, “누구에게 어떤 임팩트를 줄 수 있을까?”를 먼저 고민하는 게 훨씬 중요해요. 그래서 처음 시작할 때는 퀄리티에 집중하고, 자신의 주특기를 살리는 것, “이걸로 얼마 벌지?”보다 “누구에게 도움이 될까?”를 먼저 생각하는 것. 이 세 가지가 정말 도움이 됩니다. 그러다 보면 자연스럽게 수익도 붙습니다.

부스터 AI로 MRR(월간 반복 매출) 600만 원 달성 <출처: 커서맛피아 스레드>

AI 시대에 다음 단계로 나아가는 법

Q. 평소 자주 쓰시는 도구는 어떤 건가요?

제 닉네임이 커서맛피아긴 하지만, 요즘은 클로드 코드(Claude Code)를 가장 많이 써요. AI 에이전트를 보조하는 기능이 굉장히 잘 되어 있거든요. 커서는 UI가 있는 대신 속도가 조금 느리지만, 클로드 코드는 개발 속도가 훨씬 빨라서 실무에 바로바로 쓰기 좋습니다. “이거 좋다” 싶은 기능도 금방 출시되고요.

또 많은 분들이 MCP를 쓰시는데, 저는 직접 만들어서 사용하고 있어요. 프로젝트 할 때 참고할 오픈소스가 있으면, 깃허브에서 코드 서치하고 불러오는 용도로 MCP를 만들고, 데이터 시각화 프로젝트를 할 때는 데이터를 탐색하고 불러오는 MCP를 따로 만드는 식이죠. 생각보다 만드는 데 오래 걸리지 않고, 한 번 만들어두면 비슷한 구조로 계속 재활용할 수 있어서 편해요. 커서도 물론 쓰지만, “터미널을 잘 못 쓰겠다”는 분들이 아니라면, 저는 클로드 코드를 더 추천하는 편이에요. 요즘은 바이브 코딩을 도와주는 주변 생태계 도구들도 점점 좋아지고 있고요.

최수민 개발자가 만든 MCP
https://github.com/greatSumini/nanobanana-api-mcp
https://github.com/greatSumini/sharp-mcp
https://github.com/Vooster-AI/github-fetcher-mcp

Q. 앞으로의 다음 단계는 어떻게 그리고 계신가요?

앞으로는 공정을 설계하는 개발 패러다임이 더 지배적으로 자리 잡을 거라고 보고 있어서요. 그 방향에 맞춰, 사람들이 AI 코딩을 더 잘할 수 있도록 도와주는 오픈소스 도구들을 계속 만들고 있습니다. 제가 하고 싶은 건 결국 교육이든, 소프트웨어든 코딩 생태계에 확실한 영향력을 주는 일이에요. 그래서 부스터 AI도 계속 발전시키면서, 사람들이 AI를 활용한 코딩과 제품 개발을 더 쉽게 할 수 있도록 다양한 도구들을 만들 계획입니다.

Q. 빠르게 변화하는 시장 속, 성장하고 싶은 개발자들에게 조언해 주신다면요?

저는 세 가지를 꼭 말씀드리고 싶어요. 첫 번째로 AI를 최대한 많이 써보세요. 가능하면 클로드의 가장 비싼 요금제를 긁어서라도 직접 써보는 게 좋아요. 실제로 써보면서 감각을 익히는 것만큼 빠른 성장은 없거든요. 두 번째로 AI 없이 못 했을 만한 일에 도전해 보세요. 예를 들어, 스탠퍼드 수학과 과제를 AI로 풀어보는 것처럼, AI 리터러시를 억지로라도 키우는 경험이 정말 큰 도움이 됩니다.

마지막으로 뭐든 만들고, 그 과정을 공유하세요. SNS 채널이든, 서비스든, 강의든 상관없어요. 직접 만들다 보면 “이건 반응이 없네”, “이건 관심이 많네”, “첫 문장이 이렇게 중요하구나”, “수익화는 이런 식으로 되는구나” 같은 것들을 경험으로 배우게 됩니다. 결국 중요한 건 AI로 레버리지하고, 위임하고, 만들어보는 경험 자체예요. 이 세 가지를 꾸준히 하다 보면, 변화가 아무리 빨라도 충분히 따라갈 수 있다고 생각합니다.

인터뷰를 마치며, 오늘 한 이야기에서 한 가지 중요한 힌트를 얻었는데요. 바로 AI 시대, 개발자를 비롯한 여러 직군의 미래는 그냥 '사라짐'이 아니라, '재정의'에 가깝다는 것이죠. 인류의 역사를 돌아봐도 세상은 빠르게 발전했고, 그 속에서 어떤 직업은 사라지고 또 다른 직업들이 등장했습니다. 지금의 AI, 바이브 코딩 열풍도 그 연장선에 있는 셈이죠. 막연히 불안해한다고 변화를 막을 순 없습니다. 우리가 할 수 있는 건 그 변화에 맞춰, 내 역할을 재정의하고 확장하는 것뿐이죠.

커서맛피아 최수민 개발자는 그 불안에 직접 뛰어드는 걸 선택했습니다. 그의 선택이 주는 메시지는 명확합니다. 조직 안팎을 떠나, 지금 내가 가진 것을 어떻게 공유하고 확장할 것인지를 고민해야 한다는 것이죠. 이제 "AI가 개발자를 대체할 것인가"라는 질문보다는, "나는 어떤 가치를 주며 살아갈 것인가”를 생각해 봐야 하지 않을까요?

김소희 에디터 sohee@wishket.com

]]>

이공계 출신 VC 심사역이 된다는 것

국내 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하고 있을까요?

이번 글에서는 국내 VC ‘매쉬업벤처스’의 박은우 파트너 인터뷰로 이공계 출신 VC 심사역의 커리어를 소개합니다. 스타트업 투자 업계에서 일하는 분에게는 VC로 성장하는 방법을, 심사역들의 사고 방식이 궁금한 분들에게는 새로운 인사이트를 전합니다.

매쉬업벤처스는 국내에서 보기 드물게 엔지니어 출신 인재 비중이 높은 VC입니다. 파트너 및 심사역 과반 이상이 컴퓨터과학, 전자공학 등 엔지니어링 전공자이며, 실제 투자도 AI, 로보틱스 등 기술 기반 스타트업을 중심으로 이루어지고 있습니다.

하지만 많은 이공계 인재들은 여전히 VC를 현실적인 진로 선택지로 인식하지 않습니다. "비즈니스 경험이 부족해서 어렵지 않을까?", "기술 공부를 해왔는데 투자 업무와 연결될까?"와 같은 고민을 자주 듣게 됩니다.

이런 고민에 답하기 위해, 이 길을 먼저 걸어온 투자자를 만났습니다. 매쉬업벤처스 박은우 파트너는 연세대학교 컴퓨터과학과를 졸업하고, 커리어 초기부터 VC 심사역으로 일했습니다. 이후 딥테크 스타트업 CSO를 거쳐 다시 VC로 복귀한 특별한 여정을 가진 투자자입니다. 그의 경험을 통해 이공계 출신에게 VC가 어떤 의미인지 들어보았습니다.

1. VC라는 커리어를 처음 인식하게 된 계기가 궁금합니다.

저는 대학 시절부터 스타트업에 관심이 많았지만, 당시만 해도 국내 VC 심사역이 500명도 채 안 될 때였고, VC라는 커리어는 굉장히 생소했습니다.

다만, 요즘 이공계 학생들이 젠슨 황이나 일론 머스크를 보며 창업을 꿈꾸는 것처럼, 저도 빌 게이츠 같은 엔지니어 출신 창업자를 롤모델로 삼았습니다. 그들이 창업에 성공한 후 또 벤처 투자를 통해 생태계를 넓혀간다는 걸 알게 되면서, '나도 성공한 후에는 투자자가 되고 싶다'는 막연한 생각을 갖게 됐습니다.

결정적이었던 건 학교에서 비영리 단체인 TEDxYonsei를 공동 설립한 경험이었습니다. 연사로 프라이머 권도균 대표님을 모시게 됐고, 그 인연을 통해 이택경 대표님, 송영길 대표님 같은 엔지니어 출신 창업자들을 만나게 되면서, 한국에도 기술 창업에 성공한 뒤에 스타트업에 투자하는 일을 하는 분들이 등장하고 있다는 사실을 실감했습니다.

이후 2000년대 후반에 캘리포니아의 UC Berkeley로 교환학생을 가면서 더 확신이 생겼습니다. 그 곳에서 함께 수업에서 공부하고 교류하던 지인들이 이미 고속 성장 중이던 구글, 페이스북을 비롯하여, 당시 실리콘밸리가 주목하던 스타트업인 드롭박스나 팔란티어에 합류하는 것을 보았습니다. 뛰어난 엔지니어들이 스타트업 생태계의 중심에 뛰어드는 것을 목격하면서, 앞으로 한국도 이런 움직임이 확산될 것이라는 강한 확신을 갖게 되었습니다. 그리고 프로그래밍 자체보다는 새로운 기술이 만드는 생태계 자체에 더욱 관심이 많아지면서, "나는 엔지니어로서가 아니라면 어떤 방식으로 기술 생태계에 기여할 수 있을까?"라는 질문을 하게 됐습니다.

그 고민의 끝에 VC라는 직업을 떠올리게 됐습니다.

2. 많은 이공계 학생들이 "비경영 전공자는 VC 하기 어려울 것 같다"고 이야기합니다. 실제로 어떤 준비가 필요했나요?

저는 VC 입사를 위한 특별한 루트를 밟진 않았습니다. 당시에도 VC는 경력직이나 창업 경험이 있는 사람들이 가는 곳이라는 인식이 강했고, 저도 "경험을 쌓고 나중에 가야지" 정도로만 생각했습니다.

병역특례로 3년간 개발자로 일했고, 대학 경영혁신 학회에서 케이스 스터디를 통해 경영학을 처음 접했습니다. 전략 컨설팅, 빅테크 마케팅, 대기업 해외 신사업 등 여러 인턴십을 거쳤고, 졸업 후에는 대기업에서 데이터 분석 업무를 했습니다.

당시에는 주변에서 "너처럼 관심사가 많고 이것저것 다 해보는 건 커리어에 오히려 독이 될 수도 있어"라는 이야기를 들으며, "한 가지 방향성이 없다"는 점이 약점처럼 느껴지기도 했습니다.

하지만 VC에 입문한 후 깨달은 건, 짧은 기간에 다양한 산업과 역할을 경험했다는 점이 오히려 늘 새로운 창업자를 만나고, 새로운 사업에 관심 갖는데 큰 도움이 되었다는 것입니다. 하나의 프레임에 갇히지 않고, 새로운 산업과 창업자를 편견 없이 마주할 수 있는 능력을 기를 수 있었습니다.

결국 비경영 전공이라는 것이 단점이 아니라, 오히려 다양한 경험을 통해 유연한 사고방식을 갖출 수 있다면 그것이 VC에서의 강점이 됩니다.

3. 이공계 출신으로서 VC에서 발휘할 수 있는 강점은 무엇일까요?

스타트업의 전형적 정의는 "첨단 기술을 기반으로 빠르게 성장하는 기업"입니다. 이공계 출신은 기술에 대한 거부감이 적고, 새로운 기술을 빠르게 이해할 수 있습니다. 창업자와 기술에 대해 깊이 있는 대화를 나눌 수 있다는 점에서 이는 큰 장점입니다.

또한 엔지니어는 문제를 구조화하고 논리적으로 해결하는 훈련을 받습니다. VC 업무도 새로운 시장과 기술을 접할 때 가설을 세우고 논리적으로 검증하는 과정이 핵심입니다. 공학적 분석 능력이 거의 그대로 적용되는 영역이죠.

무엇보다 엔지니어 출신의 좋은 기술창업자를 만날 때 그 강점이 발휘됩니다. 비슷한 학창 시절을 보냈고, 비슷한 고민을 해봤으며, 비슷한 방식으로 사고하기 때문에, 이공계 출신 VC는 창업자와 자연스럽게 공감대를 형성하고, 빠르게 신뢰 관계를 쌓을 수 있습니다. 이건 단순한 네트워크가 아니라, 엔지니어 출신끼리 자연스럽게 형성되는 유대감과 신뢰라는 점에서 차별화된 강점입니다.

4. VC에서 딥테크 스타트업 CSO로 이동하신 계기가 궁금합니다.

제게 VC는 커리어 후반부의 꿈 같은 계획이었는데, 예상보다 일찍 이뤄졌습니다. 그래서 우연치 않게 "꿈을 이루어서 꿈을 잃어버렸다"고 이야기한 적도 있습니다.

그 이후 VC 경험을 어떻게 의미 있게 확장할지 고민했고, 스타트업을 직접 경험하지 않으면 나중에 후회할 것 같다는 생각이 들었습니다.

그때부터 VC 커리어를 나의 공동창업자를 찾는 과정으로 바라보기 시작했습니다. 투자 검토를 위해 만나는 창업자들을 보며 "내가 이 회사에 합류한다면 어떤 역할을 할 수 있을까?"라는 질문을 던졌습니다.

결국 투자했던 딥테크 스타트업 니어스랩의 CSO(Chief Strategy Officer)로 합류했고, 회사를 성장시키는 과정에 직접 참여하게 됐습니다.

5. VC 경험이 스타트업 CSO로서 전략 수립과 실행에 어떻게 도움이 되었나요?

저는 기술력은 있지만 아직 제품이 없던 딥테크 스타트업의 CSO로 합류했습니다.

그 전까지 VC로서 다수의 딥테크 스타트업에 투자하고, 창업자들과 긴밀히 교류하며 사업 방향성을 함께 논의했습니다. 때로는 고객사나 잠재적 인수자와의 미팅을 주선하고 직접 참여하기도 했습니다.

VC는 창업팀의 소속은 아니지만, 창업자의 사업 고민을 함께 나누는 파트너가 되어주고, 때로는 CEO staff처럼 일할 수 있는 포지션입니다. 더 중요한 건, 하나의 회사 내부가 아니라 다수의 회사를 외부에서 조망하며 사업을 바라볼 수 있다는 점입니다. 이는 시야의 폭을 넓혀주고, 더 많은 케이스 스터디를 통해 날카로운 의사결정을 할 수 있는 밑거름이 됩니다.

특히 초기 기술 창업팀은 아직 제품이 없거나 PMF(Product-Market Fit)를 찾기 전인 경우가 많습니다. 이때 회사의 기술과 펀더멘털에 대한 깊은 이해가 있어야 비즈니스를 전개할 수 있습니다.

이미 만들어진 제품을 파는 세일즈가 아니라, 사업의 방향성을 정하고 실행하는 CSO 같은 역할은 창업자와 기술, 제품에 대해 깊이 있게 논의할 수 있는 사람이 맡아야 합니다. 기술에 대한 거부감이 적고 이해 속도가 빠른 이공계 출신일수록 더 강점을 발휘할 수 있는 영역입니다.

박은우 파트너는 국내외로 엔지니어 출신 창업자를 발굴하는 것부터 포트폴리오 기업의 성장을 돕는 일까지, 이공계 배경과 딥테크 스타트업, VC 경험을 살려 폭넓게 활동하고 있습니다. <출처: 매쉬업벤처스>

6. 스타트업 경험 후 다시 VC로 복귀하면서 투자자로서 어떤 관점의 변화가 있었나요?

창업자와 그들의 업에 대한 진심을 보는 관점이 완전히 달라졌습니다.

이전에도 초기 투자에서 창업자가 중요하다는 건 알고 있었습니다. 하지만 실제로 스타트업을 경험하면서, 창업자의 삶이 얼마나 고통스러운지, 그 과정을 버텨내는 비전의 힘이 얼마나 강력한지 체감하게 됐습니다.

초기 창업팀의 계획은 아무리 경험 많은 창업자라도 계속 바뀌게 됩니다. 시장이 변하고, 팀이 변하면서 의도와 무관하게 흘러가는 것이 스타트업입니다.

그 과정에서도 "업에 대한 믿음"을 갖고 있는 창업자는 태풍 속에서도 길을 잃지 않고 살아남습니다. 반면 아무리 똑똑하고 실행력이 뛰어나도 그 믿음이 약하면 무너지게 됩니다.

오늘날처럼 AI로 인해 모든 것이 빠르게 바뀌는 세상에서는 더욱 그렇습니다. 6년여의 창업 경험을 통해 '좋은 창업자'를 판단하는 구체적인 기준을 갖게 된 것이 가장 큰 자산입니다.

7. VC를 준비하는 이공계 학생에게 가장 먼저 권하고 싶은 '출발점'은 무엇인가요?

다양한 경험을 쌓으세요. 저처럼 개발, 컨설팅, 데이터 분석 등 여러 분야를 경험하는 것도 좋습니다. 다만 VC를 목표로 한다면, 그 과정에서 스타트업 환경은 꼭 한 번 경험해보길 권합니다.

직접 창업을 시도하거나, 이력서를 위한 형식적인 창업보다는 실제로 검증받은 스타트업에서 일하는 것이 더 효과적입니다. 학생 입장에서 어떤 스타트업이 좋은 회사인지 판단하기는 매우 어렵습니다. 배울 게 없거나 심지어 문제가 있는 곳도 있습니다. 가장 좋은 필터는 검증된 투자사가 투자한 초기 스타트업에 인턴으로 합류하는 것입니다. 그곳에서 스타트업이 어떻게 작동하는지, 좋은 창업자는 어떤 사람인지, 시장은 어떻게 움직이는지 배울 수 있습니다.

8. 초기 커리어를 VC로 시작한 분들 중 인상 깊었던 사례가 있나요?

스파르타클럽(구 스파르타코딩클럽)의 창업자인 이범규 대표를 꼽고 싶습니다.

이범규 대표는 제가 창업 전에 근무했던 VC에서 함께 일한 심사역이었습니다. 학창 시절 병역특례로 개발자 커리어를 쌓은 뒤 VC로 사회생활을 시작했죠.

재학 시절에도 봉사단체나 작은 사업들을 경험했지만, VC에서 스타트업 생태계와 자본시장에 대한 이해를 쌓은 뒤 스파르타클럽을 창업했고, 이를 멋지게 성장시켜 대형 Private Equity로부터 투자를 받는 성과를 거뒀습니다.

특히 사업 확장 과정에서 VC 시절 알게 된 네트워크를 임직원으로 채용하며 팀의 역량을 강화하는 등, VC 경험이 창업의 성공 확률을 실질적으로 높인 대표적인 케이스입니다.

마치며

VC는 이공계 출신 인재들이 기술적 강점을 유지하면서 시장 감각과 전략적 사고를 함께 기를 수 있는 곳입니다. 창업 준비를 위한 최적의 학습 경로를 찾는 분, 기술을 넘어 산업 전체를 보고 싶은 분, 전문직으로서 높은 성취를 원하는 분에게 생각보다 훨씬 가까운 선택지일 수 있습니다.

]]>

챗GPT 보고 사표 쓴 비전공자, IT 커뮤니케이터가 되다

평소처럼 출근한 어느 날, 그는 ChatGPT와 마주하게 됩니다. 그리고 “이 서비스가 세상을 바꿀 것이다”라고 직감했죠. 결국 그는 주저 없이 퇴사를 결심합니다. 남들이 부러워하던 안정적인 커리어를 박차고 나와, 여행 중 우연히 시작한 뉴스레터를 통해 완전히 새로운 커리어를 만들어가기 시작했습니다.

바로 'IT 커뮤니케이터' 이재훈 작가의 이야기입니다. 그는 매주 IT 트렌드레터 '테크잇슈'를 발행하며, 복잡한 기술을 누구나 이해할 수 있는 언어로 풀어냅니다. 여행지에서 시작한 뉴스레터는 어느덧 130회를 넘어섰고, 이제는 요즘IT를 비롯한 여러 매체에서 이재훈 작가의 글을 만나볼 수 있습니다.

한 가지 흥미로운 점은 그가 개발자 출신이 아니라는 겁니다. 오히려 그 덕분에 기술을 처음 접하는 독자가 어디서 막히는지 정확히 알 수 있었고, 이것이 그의 큰 강점이 되었죠. 실제로 그에게는 특별한 '최종 검수자'도 있습니다. 바로 일반 독자의 눈을 가진 아내입니다. 아내가 이해하지 못하면 원고를 처음부터 다시 쓴다고 하는데요. "독자가 이해하지 못하는 글은 의미가 없다"는 게 그의 원칙입니다.

그렇다면 대기업 직장인에서, 1인 크리에이터로의 과감한 전환 뒤에는 어떤 결심이 있었을까요? 이번 인터뷰에서는 이재훈 작가의 커리어 전환기부터 2025년 IT 트렌드, 그리고 2026년 전망까지 폭넓게 들어봤습니다.

이재훈 작가 <출처: 본인>

커리어 전환기: 안정적인 직장에서 1인 크리에이터로

Q. 안녕하세요 작가님, 자기소개 부탁드립니다.

안녕하세요. 기술과 사람을 잇는 IT 커뮤니케이터 이재훈입니다. 현재 IT 트렌드레터 ‘테크잇슈’를 운영하며, 독자들이 기술 변화의 흐름을 놓치지 않도록 돕고 있어요. 또 요즘IT를 비롯해 KB·현대카드·국민연금공단 등 다양한 기관에 기고하고 있죠. 최근에는 책 『샘 올트먼, 더 비전 2030』을 출간하여, 강연을 다니는 등 독자들과 직접 소통하며 기술과 더 가까워지는 경험을 만들고 있습니다.

Q. 'IT 커뮤니케이터'란 무엇이고, 어떤 역할을 하는지 궁금합니다.

과학 커뮤니케이터 ‘궤도’님을 떠올리면 이해하기 쉬울 것 같아요. 궤도님이 어려운 과학을 대중의 언어로 풀어내듯, 저 역시 복잡한 IT 기술과 사회 현상을 쉽고 재밌게 전달하는 것을 목표로 합니다. 제가 이 일을 하는 이유는 명확한데요. 2022년 말, ChatGPT 등장 이후 AI의 발전 속도는 모두를 놀라게 했어요. 그리고 하루가 아닌 시간 단위로 새로운 발표가 이어졌죠. 그래서 이 변화의 흐름을 따라가야 한다는 압박감, 뒤처질지 모른다는 불안감(FOMO, Fear of Missing Out)을 느끼는 분들도 많아졌습니다.

저는 이 지점에서 기술을 아는 사람과 그렇지 못한 사람의 격차, 즉, 기술 양극화의 간극을 메워줄 누군가가 필요하다고 느꼈죠. 기술에 대한 막연한 두려움을 없애고, 모두가 변화의 흐름에 동참할 수 있도록 돕는 것이 제 역할이라 생각해, 뉴스레터 ‘테크잇슈’를 운영하기 시작했어요.

Q. 'IT 커뮤니케이터'가 되기 전에는 어떤 일들을 하셨나요?

이전에는 금융사에서 디지털 전환(DT) 전략을 기획했어요. 업무 특성상 새로운 기술과 서비스를 누구보다 먼저 접하고, 빠르게 분석해야 했죠. 그러다 보니 자연스럽게 기술 변화에 민감해질 수밖에 없었는데요. 그런 흐름 속에서 마주한 게 바로 ChatGPT였습니다. 이 서비스를 처음 봤을 때, ‘아, 이건 정말 세상을 바꾸겠구나’ 하는 확신이 들었어요. 그리고 그 거대한 변화 한가운데서 제가 해야 할 일이 뚜렷하게 보였죠. 그렇게 퇴사를 결심했고, 지금의 IT 커뮤니케이터로서 새로운 길을 걷게 됐습니다.

Q. 뉴스레터는 어떤 계기로 시작하게 되셨나요?

IT 커뮤니케이터로 전향한 직후, 감사하게도 몇몇 매체에 글을 기고할 기회를 얻었어요. 처음에는 정말 기뻤지만, 그 기쁨이 오래가진 못했는데요. 한 플랫폼으로부터 갑작스럽게 계약 해지를 통보받은 일이 있었어요. 그 경험을 통해 깨달았죠. 플랫폼에만 의존하면 언제든 흔들릴 수 있으니, 독자들과 직접 소통할 수 있는 ‘나만의 채널’이 필요하다는걸요. 그렇게 시작한 게 뉴스레터 ‘테크잇슈’였습니다. 처음엔 딱 10번만 보내보자고 마음먹었는데, 어느덧 130회를 넘기게 되었네요.

뉴스레터 테크잇슈 <출처: 이재훈>

Q. 1인 크리에이터로 활동하며 가장 어려웠던 점과 좋았던 점이 있다면요?

가장 어려운 점이라면 역시 ‘수익화’예요. 지금은 숏폼 위주의 영상 콘텐츠가 대세잖아요. 그런 시대에 텍스트, 그것도 롱폼 텍스트로 가치를 온전히 인정받고 지속 가능한 모델을 만든다는 건 여전히 쉽지 않더라고요.

하지만 아이러니하게도, 저는 바로 그 지점에서 희망을 발견했어요. 다들 이제는 영상만 본다고 생각했지만, 여전히 깊이 있는 통찰을 담은 텍스트에 대한 ‘갈증’이 시장에 분명히 존재한다는 걸 직접 확인했거든요. 솔직히 처음부터 기대가 크진 않았어요. 어렵다는 이야기만 워낙 많이 들었으니까요. 그런데 예상 밖의 수요가 있었고, 그 덕분에 지금까지도 꾸준히 이어올 수 있었습니다.

Q. 현재 수익화는 주로 뉴스레터 중심인가요?

뉴스레터 ‘테크잇슈’가 제 모든 활동의 중심축이에요. 구독자 규모가 점점 커지면서 광고 문의도 꾸준히 들어오고 있고, 단가도 자연스럽게 높아지고 있습니다. 그런데 재미있게도 가장 안정적인 수익원은 의외로 뉴스레터가 아닌 곳에서 나와요. 여러 기업과 기관에 정기적으로 기고하는 콘텐츠가 그 역할을 해주고 있거든요. 뉴스레터를 통해 발행한 콘텐츠의 가치를 인정해 주신 덕분에 다양한 곳에서 먼저 연락을 주시는 경우가 많습니다. 또 최근에는 책 출간이 새로운 전환점이 되었어요. 인세 수입뿐 아니라, 강연 요청도 이어지면서 활동의 폭이 넓어졌고, 자연스럽게 수익 구조도 변화하고 있죠.

IT 트렌드를 예측하는 일

Q. 2025년 가장 주목할 만한 IT 트렌드는 무엇이었나요?

지난해 말, ‘2025년 기술 트렌드, 이거 하나만 기억하세요!’라는 콘텐츠를 쓴 적이 있어요. 여기서 말한 ‘이거 하나’가 바로 AI 에이전트였죠. 실제로 올해는 AI 에이전트가 가능성의 단계를 넘어, 제품과 서비스로 구현된 ‘상용화의 원년’으로 기록될 만한 한 해였다고 생각합니다.

그리고 AI의 ‘지능’이 고도화되면서, 자연스럽게 그 지능을 담을 ‘육체’로서의 휴머노이드에 대한 관심도 빠르게 높아지고 있어요. 특히 엔비디아, 테슬라, OpenAI 같은 빅테크 기업들이 이 경쟁에 본격적으로 뛰어들면서 시장의 기대감도 함께 치솟았죠. 다만, 기술적 완성도에 비해 다소 관심이 과열된 느낌도 있어요.

Q. 다가오는 2026년에는 어떤 기술 트렌드가 주목받을까요?

최근 AI 거품 논쟁이 치열합니다. 그러나 그 논의와는 별개로 AI에 대한 자본 쏠림은 여전합니다. 오히려 더 증가하고 있는데요. 그 이유는 바로 ‘인프라’ 때문입니다. 스케일링 법칙의 한계가 거론되지만, 결국 AI 경쟁의 승패는 막대한 데이터를 처리하고 모델을 구동할 인프라에서 갈릴 것이라는 점은 변하지 않았죠. 따라서 관련 기술과 기업은 계속해서 시장의 중심에 서게 될 것으로 보입니다.

여기까진 많은 분들이 예상할 수 있는 부분인데요. 개인적으로는 AI의 잠재력을 100%, 혹은 그 이상으로 끌어낼 ‘UI/UX의 근본적인 변화’를 주목하고 있어요. 지금의 그래픽 기반 UI는 AI라는 새로운 패러다임을 온전히 담아내지 못하고 있기 때문입니다. 결국 누가 이 새로운 인터페이스 표준을 선점하느냐가 차세대 플랫폼의 승자를 가를 것으로 보이며, 2026년은 거대한 변화의 윤곽이 드러나는 해가 될 것으로 전망해 봅니다.

Q. 그렇다면 국내 IT 업계의 변화는 어떻게 보시나요?

우선 긍정적인 변화는 2025년 들어 정부가 AI를 국가의 명운을 건 아젠다로 삼고 강력한 드라이브를 걸기 시작했다는 점이예요. 특히 대통령 직속으로 ‘국가AI전략위원회’를 출범시켜 AI 정책의 컨트롤 타워로 삼은 것은 매우 의미 있는 진전이라 생각해요. 특히 현장 경험이 풍부한 민간 전문가들을 요직에 배치하여 정책의 실효성도 기대됩니다.

다만 우려되는 점이 있다면, 이 거대한 흐름에서 스타트업 생태계가 위태롭다는 점이에요. 벤처 투자 빙하기가 계속되면서 혁신적인 아이디어를 가진 초기 스타트업들이 자금 조달에 어려움을 겪고 있는데요. 미국에서 OpenAI를 비롯해 Claude, Perplexity 등 스타트업이 기술 트렌드를 주도하고 있는 것과 대조적이라고 봅니다.

Q. 올해 『샘 올트먼, 더 비전 2030』이라는 책을 출간하셨어요. 특별히 ‘샘 올트먼’에 주목하신 이유가 있을까요?

샘 올트먼이라는 인물에 대한 호불호나 옳고 그름의 판단을 떠나, 현시점에서 그가 기술 트렌드의 ‘의제’를 설정하고 시장을 움직이는 가장 중요한 인물이라는 점은 부정할 수 없어요. 그의 말 한마디와 투자 하나가 업계의 다음 목표가 되고, 거대한 자본의 흐름을 바꾸고 있죠.

‘지피지기면 백전백승’라는 말처럼, 이 거대한 흐름을 주도하는 플레이어의 생각과 비전을 정확히 읽어내야만 다가올 변화의 본질을 이해하고, 우리만의 기회를 포착할 수 있다고 생각했어요. 이 책은 샘 올트먼을 분석 대상으로 삼아, 그가 그리는 미래 기술 지형도를 예측하고 독자들이 그 속에서 생존하고, 성장하기 위한 전략을 세우는 데 실질적인 도움이 되길 바라는 마음으로 썼어요.

<출처: 교보문고>

크리에이터로서의 삶을 지속하는 법

Q. 매주 뉴스레터를 발행하려면 많은 정보가 필요할 텐데, 어떻게 정보를 수집하시나요?

사실 특별한 방법은 없어요. 기사를 최대한 많이 찾아보고, SNS 등을 통해 정보를 수집하죠. 저의 작업 방식은 정보 ‘수집’보다 ‘연결’하는 데 있어요. 그 과정에서 정보를 데이터베이스처럼 정리하기보다는, 머릿속에 서로 무관해 보이는 기술, 정책, 시장의 단서들을 펼쳐놓고, 그 사이의 숨은 맥락을 찾는 데 대부분의 시간을 사용하죠.

예를 들어, 서로 무관해 보이는 기술, 정책, 시장의 변화를 계속해서 뒤섞어보며, ‘이 현상이 저기에 어떤 효과를 일으킬까?’라는 질문을 던지는 식입니다. AI가 자료 취합도 잘해주고, 글도 대신 써주는 시대지만, 여전히 인간이 돋보일 수 있는 역할은 바로 이런 ‘통찰’이라고 믿어요.

Q. 복잡한 IT 트렌드를 쉽게 풀어내는 본인만의 노하우가 있다면요?

아이러니하게도 저의 가장 큰 장점은 개발자 출신이 아니라는 점이에요. 기술을 처음 접하는 독자가 어떤 지점에서 장벽을 느끼고, 무엇을 궁금해하는지 그 ‘눈높이’를 잘 알고 있기 때문이죠. 물론 2년간 이 일을 하며 저의 눈높이도 조금씩 높아졌어요. 그래서 저에겐 글의 완성도를 결정하는 ‘최종 결재자’가 있는데요. 바로 아내입니다.

아내는 IT 기술에 대한 전문 지식이 없는, 딱 일반 대중의 시각을 가졌거든요. 아내가 제 글을 읽고 이해하기 어렵다고 하면, 저는 예외 없이 원고를 처음부터 다시 씁니다. IT 커뮤니케이터로서 독자가 이해하지 못하는 글은 결국 의미가 없다는 게 저만의 원칙입니다.

Q. 혼자 일할 때 시간 관리는 어떻게 하시나요?

사람마다 다르겠지만, 저는 보통 해가 지고 나서야 집중이 잘 되는 편이에요. 그래서 해가 떠 있을 때는 미팅이나, 일정 조율 등 일종의 비즈니스를 하는 데 활용하고, 대부분의 글쓰기는 밤에 이루어지죠.

또 프로젝트 관리는 디테일하게 하기보다는, 가장 중요한 ‘마감일’을 중심으로 매일 새롭게 업데이트하는 편입니다. 1인 기업가로서 모든 것을 혼자 책임지고, 매일매일 많은 변수들이 존재하기 때문에, 세세한 일정을 짜기보다는 매일 가장 중요한 일의 우선순위를 정해두면서 나머지는 자유롭게 일하는 편이에요. 다소 즉흥적이고 여유로워 보이지만, 지금까지 특별한 이유 없이 마감을 놓친 적은 한 번도 없어요.

Q. 새롭게 계획 중이신 일이 있다면요?

지금까지는 IT 커뮤니케이터로서 글과 강연을 통해 기술의 본질을 ‘해설’하고, 변화의 ‘의미’를 전달하는 데 집중해 왔는데요. 요즘은 AI 덕분에 개발의 장벽이 낮아지다 보니, 제 아이디어를 실현시킬 서비스를 만들어 보고 싶다는 생각이 들었어요. 아직 구체적인 아이템은 없지만, 이루고 싶은 목표는 명확합니다. 전 세계인이 모두 활용할 수 있는 서비스를 만드는 것입니다. 모두가 공통적으로 가지고 있는 아주 사소한 불편이라도, 여전히 아무도 해결하지 못한 문제라면, 그 문제를 제가 해결해 보고 싶어요.

바이브 코딩으로 포트폴리오 웹사이트를 만드는 모습 <출처: 이재훈>

Q. 마지막으로 커리어 전환이나, 새로운 일을 고민하는 분들에게 조언해 주신다면?

새로운 일을 시작할 때, 보통 내가 가진 전문성이 부족하다고 생각하기 쉬운 것 같아요. 저 역시 개발자 출신이 아니라는 점이 처음에는 걱정이었지만, 오히려 그게 가장 큰 도움이 됐습니다. 기술을 잘 모르는 사람의 입장에서 생각할 수 있으니, 더 쉽게 설명할 수 있었고요. 그러니 지금 내가 가진 것이 부족하다고 생각하기보다, 오히려 ‘나만 할 수 있는 이야기’가 무엇일지 고민해 보시면 좋겠어요.

또 처음부터 대단히 계획할 필요는 없어요. 저도 지금처럼 책을 내거나, 강연을 하게 될 거라고는 전혀 계획하지 않았거든요. 그저 하나만 꾸준히 잘 해보자는 막연한 마음으로 시작했을 뿐입니다. 그런데 세상은 의외로 그렇게 흘러가더라고요. 지금은 거대한 슈퍼앱이 된 토스도, 처음엔 그저 ‘간편 송금’이라는 단 하나의 기능으로 시작했던 것처럼 말이죠.

최근 이재훈 작가가 공감했다는 글 <출처: @syjkorea X, 캡처>

이번 인터뷰에서 가장 인상 깊었던 점은 ‘IT 커뮤니케이터’의 역할에 대한 이재훈 작가의 확고한 철학이었는데요. 기술을 ‘잘’ 전달하는 데 필요한 건 전문 지식만이 아니라, ‘독자의 눈높이에서 생각하는 능력'이라는 점입니다.

단순히 정보를 전달하는 데 그치지 않고, 기술의 의미를 해석하고 맥락을 연결해내는 그의 방식은 콘텐츠 제작은 물론, 제품 기획이나 전략 수립 등 다양한 영역에 적용해 볼 수 있다고 생각합니다. 이 인터뷰 역시 여러분께 작지만 의미 있는 ‘연결’이 될 수 있길 바랍니다.

김소희 에디터 sohee@wishket.com

]]>

"혼자 성장하는 개발자는 없다" 멘토가 필요한 이유

"혼자서는 갈 수 없는 길이 있습니다."

처음 개발자가 된 저는 모든 것을 혼자서 해결할 수 있다고 생각했습니다. 구글에 검색하면 나오는 답변들, 스택오버플로우의 수많은 해결책들, 유튜브 강의들까지 정보는 넘쳐났고, 저는 그것만으로 충분하다고 믿었죠. 하지만 3년 차가 되었을 때, 깨달았습니다. 기술적인 문제는 검색으로 해결할 수 있지만, 커리어의 방향성이나 기술 선택의 우선순위, 팀 내 갈등 해결, 번아웃 극복 같은 문제들은 검색만으로는 답을 찾을 수 없다는 것을요.

그때 저는 우연히 한 시니어 개발자와 커피를 마시며 이야기를 나눴습니다. 30분간의 대화였지만, 그는 제가 6개월 동안 고민했던 문제를 명쾌하게 정리해 주었습니다. "네가 겪고 있는 건 전형적인 개발자의 고민이야. 나도 똑같이 겪었어. 그때 나는 이렇게 해결했지." 그때 깨달았습니다. 멘토는 단순히 기술을 가르쳐주는 사람이 아니라, 이미 그 길을 걸어본 사람이 옆에서 지도를 펼쳐주는 존재라는 걸 말이죠. 이번 글에서는 제 경험을 토대로 개발자에게 멘토가 필요한 이유, 그리고 좋은 멘토를 만나는 법, 관계를 유지하는 방법 등을 살펴보겠습니다.

<출처: 픽사베이>

개발자에게 왜 멘토가 필요할까?

1) 실패의 지름길을 피할 수 있다

멘토는 이미 수많은 실수를 경험한 사람입니다. 그들의 조언은 여러분이 똑같은 구덩이에 빠지는 것을 막아줍니다.

제가 아는 한 주니어 개발자는 마이크로서비스 아키텍처를 무리하게 도입하려다 프로젝트를 지연시킨 적이 있습니다. "요즘 다들 마이크로서비스를 쓴다길래..." 하지만 멘토가 있었다면 이렇게 말해줬을 겁니다. "네 팀 규모와 프로젝트 성격을 보면, 지금은 모놀리식이 더 적합해. 마이크로서비스는 나중에 필요할 때 전환해도 늦지 않아."

멘토가 막아주는 흔한 실수들

과도한 기술 스택 도입으로 인한 복잡도 증가
커리어 초반 잘못된 선택 (예: 레거시만 있는 회사에 장기근속)
번아웃을 부르는 과도한 업무 수용
기술 트렌드만 쫓다가 기본기를 놓치는 실수

2) 보이지 않는 선택지를 알려준다

경험이 부족할 때는 선택지 자체를 모르는 경우가 많습니다. 멘토는 여러분이 생각하지 못했던 가능성을 열어줍니다.

한 개발자는 "백엔드 개발자로 계속 가야 할지, 프론트엔드로 전환할지" 고민하고 있었습니다. 멘토는 그에게 새로운 시각을 제시했죠. "왜 둘 중 하나를 선택해야 한다고 생각해? 풀스택 개발자로 성장하면서, 데브옵스 역량을 키워보는 건 어때? 네가 좋아하는 인프라 자동화와도 연결되고, 커리어 옵션도 훨씬 넓어질 거야."

멘토가 열어주는 가능성

생각지 못했던 커리어 경로
숨겨진 회사 문화나 채용 루트
효율적인 학습 방법과 리소스
업계 트렌드의 진짜 흐름(과대광고 vs 진짜 중요한 것)

3) 정서적 지지와 동기부여

개발자의 여정은 외롭습니다. 버그와 씨름하며 밤을 새우고, 코드 리뷰에서 지적받고, 새로운 기술이 나올 때마다 뒤처진다는 불안을 느낍니다. 이럴 때 멘토는 단순한 조언자가 아니라 정서적 버팀목이 되어줍니다.

"너무 힘들어요. 제가 개발자로서 재능이 없는 걸까요?" 한 주니어의 고민에 멘토는 이렇게 답했습니다.

"나도 2년 차 때 똑같은 생각을 했어. 지금 네가 느끼는 좌절은 성장통이야. 이 시기를 지나면 훨씬 단단한 개발자가 될 거야. 포기하지 마."

멘토가 제공하는 정서적 가치

"나만 힘든 게 아니구나"라는 안도감
좌절할 때 다시 일어설 용기
성장을 체감하지 못할 때 객관적인 피드백
외로운 여정에 동반자가 있다는 느낌

좋은 멘토를 찾는 구체적인 방법

1) 회사 내부에서 찾기

같은 회사의 시니어 개발자는 여러분이 직면한 문제를 가장 잘 이해합니다. 왜냐하면 그들은 이미 여러분이 사용하는 코드베이스를 알고 있고, 팀의 문화와 업무 방식을 이해하며, 회사의 기술 스택과 인프라 환경에 익숙하기 때문입니다.

실천 방법

코드 리뷰를 적극 요청하고, 리뷰어의 조언을 메모하기
점심시간이나 커피 타임에 가볍게 대화 시작하기
사내 스터디나 테크톡에 참여해서 자연스럽게 관계 맺기
"멘토링 프로그램"이 공식적으로 없어도, 비공식적으로 조언을 구하기

주의할 점

처음부터 "멘토가 되어주세요"라고 부담 주지 않기
작은 질문으로 시작해서 점진적으로 관계 발전시키기
일방적으로 받기만 하지 않고, 내가 도울 수 있는 부분 찾기

실제 사례: 신입 개발자 A씨는 매주 금요일 점심시간에 시니어 개발자 B씨와 식사했습니다. 처음에는 가벼운 잡담으로 시작했지만, 점차 기술적 고민, 커리어 방향, 팀 내 커뮤니케이션 방법 등 깊은 대화를 나누게 되었죠. B씨는 공식적인 멘토는 아니었지만, A씨의 커리어에 가장 큰 영향을 준 사람이 되었습니다.

2) 커뮤니티와 행사 활용하기

개발자 커뮤니티는 멘토를 만날 수 있는 보물창고입니다. 회사 밖에서 다양한 배경과 경험을 가진 개발자들을 만날 수 있기 때문입니다. 같은 회사 내부에서는 특정 기술 스택이나 도메인에 한정될 수 있지만, 커뮤니티에서는 다른 산업군, 다른 회사 문화, 다른 기술 스택을 경험한 시니어 개발자들을 접할 수 있습니다

활용할 수 있는 커뮤니티

OKKY, Devsnote 등 온라인 커뮤니티
GDG, AWSKRUG, 요즘IT 같은 기술 커뮤니티
온오프믹스, Meetup 등 IT 관련 오프라인 밋업
해커톤, 컨퍼런스, 기술 세미나 등

효과적인 접근법

행사 후 질문 시간에 적극적으로 질문하기
연사에게 명함 받고 LinkedIn으로 연결 요청하기
커뮤니티에서 꾸준히 활동하기
온라인에서 먼저 관계를 쌓고 오프라인 커피챗 제안하기

성공 사례: 주니어 개발자 C씨는 행사에 꾸준히 참여하며 발표자들과 질의응답을 나눴습니다. 어느 날 한 발표자에게 이메일로 "발표 내용 중 A 부분이 궁금한데, 30분 정도 커피챗이 가능할까요?"라고 요청했고, 그 만남이 1년 넘게 이어지는 멘토링 관계로 발전했습니다.

3) LinkedIn 등 소셜 미디어 활용하기

온라인 시대에는 방구석에서도 멘토를 만날 수 있습니다. 물리적 거리는 더 이상 장벽이 아닙니다. 서울에 사는 주니어 개발자가 부산이나 제주도에 있는 시니어 개발자에게 조언을 구할 수 있고, 심지어 해외에 거주하는 개발자와도 멘토를 맺을 수 있습니다.

LinkedIn 활용법

관심 있는 분야의 시니어 개발자들을 팔로우하기
그들의 포스트에 의미 있는 댓글 달기(단순 칭찬이 아닌 생각 공유)
연결 요청 시 맞춤형 메시지 작성하기: "안녕하세요, 저는 백엔드 개발 2년 차입니다. 프로젝트를 보고 큰 영감을 받았습니다. 혹시 이 분야에 대해 조언을 구할 수 있을까요?"

SNS 활용법

존경하는 개발자들을 팔로우하고 정기적으로 그들의 글 읽기
리트윗이나 댓글로 자신의 생각 덧붙이기
DM으로 짧고 구체적인 질문 보내기 (단, 예의와 간결함 중요)

주의 사항

스팸처럼 무작위로 연결 요청하지 않기
첫 메시지에 너무 많은 것을 요구하지 않기
상대방의 시간을 존중하고, 짧고 명확하게 커뮤니케이션하기

4) 역멘토링 제안하기

역발상적으로 시니어 개발자에게 여러분이 가진 것을 제공하는 것입니다. 많은 주니어 개발자들이 "나는 아직 배울 게 많은데 시니어에게 줄 게 뭐가 있을까?"라고 생각하지만, 실제로는 여러분이 제공할 수 있는 가치가 생각보다 많습니다.

역멘토링 아이디어

최신 프론트엔드 프레임워크 (React 19, Next.js 등)
새로운 개발 도구 (GitHub Copilot, Cursor 등)
MZ 세대 관점에서의 UX 피드백
소셜 미디어 마케팅이나 개인 브랜딩
접근 방법: "안녕하세요. 저는 개발자님이 연구하는 분야에 도움이 될만한 최신 기술 정보가 있습니다. 혹시 실례가 안 된다면 부족하지만 제가 가진 정보를 공유해 드려도 될까요?"

이런 방식은 일방적인 수혜 관계가 아닌, 상호 이익이 되는 관계를 만들어 멘토링이 더 지속 가능하고 부담 없게 만듭니다.

멘토와의 관계를 오래 유지하는 방법

<출처: 픽사베이>

멘토를 찾는 것도 중요하지만, 그 관계를 장기적으로 유지하는 것은 더 중요합니다. 멘토와의 관계를 오래 유지하려면 어떤 방법이 있을까요?

1) 명확한 기대치 설정하기

관계 초기에 서로의 기대치를 명확히 하는 것이 중요합니다. 많은 멘토, 멘티 관계가 흐지부지 끝나는 이유는 서로가 기대하는 것이 달랐기 때문입니다. 만남 빈도, 커뮤니케이션 방식, 멘토링 범위를 처음부터 솔직하게 논의하면 서로 부담 없이 장기적으로 건강한 관계를 유지할 수 있습니다.

논의해야 할 사항들

만남 빈도(주 1회? 월 1회? 필요시?)
커뮤니케이션 방식 대면? 화상? 메신저?)
멘토링 범위(기술만? 커리어 전반?)
시간 투자 가능 범위(30분? 1시간?)

좋은 예: "감사하게도 멘토링을 수락해 주셔서 정말 기쁩니다. 저는 월 1회 정도, 1시간 내외로 커피챗 또는 화상 미팅을 희망하는데 괜찮으실까요? 주로 백엔드 아키텍처와 커리어 방향에 대해 조언을 구하고 싶습니다."

2) 멘토의 시간을 존중하기

시니어 개발자들은 매우 바쁩니다. 그들의 시간을 존중하는 것이 관계 지속의 핵심입니다. 프로젝트 데드라인, 팀 관리, 기술 의사결정 등으로 하루가 부족한 시니어들에게 멘토링은 '추가 업무'가 될 수 있습니다. 따라서 사전에 질문을 정리해서 보내고, 약속 시간을 철저히 지키며, 받은 조언을 실천하는 모습을 보여주는 것이 중요합니다.

실천 방법

미팅 전 미리 질문 보내기: "멘토님 다음 주 화요일에 MSA 전환 시 고려 사항에 대해 질문드려도 될까요?”
시간 약속 철저히 지키기: 5분 전 도착, 정시 시작, 정시 종료
"이것만 빨리" 요청 자제하기: - 긴급한 것처럼 보이는 질문도 상대방 시간 고려
숙제 해오기: 멘토가 준 조언이나 자료는 반드시 학습한 후 피드백

3) 진전 상황 공유하기

멘토가 가장 보람을 느끼는 순간은 멘티의 성장을 볼 때입니다. 자신이 준 조언이 실제로 도움이 되었는지, 멘티가 어떻게 발전하고 있는지를 알 때 멘토링을 계속할 동기를 얻습니다. 따라서 작은 성과라도 정기적으로 공유하는 것이 관계 유지의 핵심입니다.

공유하면 좋은 것들:

"추천해 주신 강의를 완강했고, 프로젝트에 적용했습니다."
"면접 합격했습니다! 그때 알려주신 팁이 큰 도움이 되었어요."
"실패했지만, 교훈을 얻었고 다음에는 알려주신 개선 방향으로 다시 한번 시도하겠습니다."

나쁜 예:

조언을 받고 아무 행동도 하지 않기
같은 문제를 계속 질문하기
진전 상황을 전혀 공유하지 않다가 몇 달 후 연락하기

4) 일방적 수혜 관계에서 벗어나기

장기적으로 건강한 관계를 유지하려면 기브 앤 테이크가 필요합니다. 일방적으로 받기만 하는 관계는 멘토에게 부담이 되고 지속하기 어렵습니다. 내가 줄 수 있는 작은 것들을 찾아 제공하면, 멘토링은 단순한 수혜 관계가 아닌 상호 성장의 파트너십으로 발전합니다.

내가 줄 수 있는 것들

정보 공유: "최근 컨퍼런스에서 흥미로운 내용이 있어 공유드립니다"
작은 도움: "제가 도울 수 있는 부분이 있다면 언제든 말씀해 주세요."
네트워킹: "제 지인 중에 또 다른 전문가가 있는데 소개해 드릴까요?"
감사 표현: 명절이나 연말에 진심 어린 감사 메시지
공개적 인정: 허락 하에 LinkedIn이나 블로그에 감사 표현

실제 사례: 주니어 개발자 D씨는 멘토가 관심 있어 하는 AI/ML 분야의 최신 논문과 튜토리얼을 정기적으로 요약해서 보내드렸습니다. 멘토는 바빠서 최신 트렌드를 따라가기 어려웠는데, D씨의 큐레이션이 큰 도움이 되었다고 했죠. 이렇게 관계는 3년째 이어지고 있습니다.

5) 정기적이고 지속적인 커뮤니케이션

관계는 꾸준함에서 나옵니다. 필요할 때만 연락하면 진정한 관계로 발전하기 어렵습니다. 도움이 필요할 때만 찾는다면 그것은 멘토링이 아니라 일회성 상담에 가깝습니다. 정기적으로 안부를 묻고, 멘토의 소식에도 관심을 가져야 지속 가능한 관계가 만들어집니다.

커뮤니케이션 팁

가벼운 안부 주고받기: 큰 질문이 없어도 한 달에 한 번은 안부 메시지
멘토의 소식에 관심 갖기: 멘토가 쓴 블로그 글, 발표 등에 피드백
중요한 순간 함께하기: 멘토의 프로젝트 론칭, 이직, 승진 등 축하

나쁜 예:

6개월간 아무 연락 없다가 갑자기 면접 질문
멘토의 근황은 전혀 모르면서 내 이야기만 하기
도움이 필요할 때만 찾고, 해결되면 연락 끊기

6) 감사를 표현하되, 과도한 부담 주지 않기

감사 표현은 중요하지만, 방식이 중요합니다. 너무 과하거나 형식적인 감사는 오히려 멘토를 불편하게 만들 수 있습니다. 진심 어린 메시지나 부담 없는 작은 선물이 비싼 선물보다 훨씬 효과적이며, 무엇보다 조언을 실천하는 모습을 보여주는 것이 가장 좋은 감사 표현입니다.

적절한 감사 표현:

진심 어린 감사 메시지 (과장 없이 구체적으로)
커피값 계산하기 (부담스럽지 않은 선에서)
멘토가 좋아할 만한 작은 선물 (책, 굿즈 등)
멘토의 추천을 실천하고 그 결과 공유하기

피해야 할 행동:

과도하게 비싼 선물 (상대방을 부담스럽게 만듦)
지나친 칭송이나 아첨 (진정성을 의심받을 수 있음)
멘토의 모든 말을 무조건 따르는 맹신

7) 독립적으로 성장하기

역설적이지만, 좋은 멘티는 점점 멘토에게 덜 의존하게 됩니다. 영원히 의존하는 것이 아니라 독립적으로 문제를 해결하는 능력을 키워가는 것이 진정한 성장입니다. 멘토 역시 멘티가 자립하는 모습을 볼 때 가장 큰 보람을 느끼며, 이는 건강한 멘토링의 자연스러운 종착점입니다.

독립적 성장의 신호:

"이번엔 혼자 해결해 보고, 결과를 공유드리겠습니다."
"멘토님의 조언을 바탕으로 제 나름의 방법을 찾았어요."
"이제 저도 누군가를 도울 수 있을 것 같아요."

좋은 멘토는 멘티가 독립적으로 성장하는 것을 기뻐합니다. 영원히 의존하는 관계가 아니라, 결국 동료가 되는 것이 건강한 멘토링의 종착점입니다.

마치며: 멘토는 우연히 만나는 게 아니라 찾아가는 것

<출처: Freepik>

마지막으로 한 가지만 기억하세요. 좋은 멘토는 하늘에서 떨어지지 않습니다. 영화처럼 극적으로 나타나 여러분의 인생을 바꿔주는 것도 아닙니다. 그러나 멘토가 필요하다면 여러분이 용기를 내서 다가가고, 관계를 쌓고, 진심을 나누며 만들어가면 됩니다. 너무 두려워하지 마세요. 물론 거절당할 수도 있고, 어색할 수도 있습니다. 하지만 그 한 걸음이 여러분의 커리어를 완전히 바꿀 수도 있죠. 저 역시 처음 커피챗을 요청할 땐 손이 떨리기도 했습니다. 그러나 지금 돌이켜보면 그건 제 커리어에서 가장 가치 있는 선택 중 하나였습니다.

여러분도 할 수 있습니다. 지금 바로 존경하는 개발자에게 메시지 하나를 보내보세요. "안녕하세요! 개발자님 좋은 하루입니다! 잘 지내고 계신가요?" 그 한 문장이 여러분의 인생을 바꿀지도 모르니까요.

]]>