비개발 PM의 Claude Code 활용기에 대한 분석과 의견
들어가며
라인플러스 정덕범 PM의 Claude Code 활용 사례는 2025년 이후 AI 시대의 소프트웨어 개발 패러다임 전환을 보여주는 상징적인 이야기입니다. 문과 출신 비개발자가 6,000라인이 넘는 코드를 관리하며 실제 서비스를 운영하게 된 과정은, 단순히 개인의 성공담을 넘어 AI가 가져올 업무 환경의 근본적 변화를 예고하고 있습니다.
이 사례에서 가장 주목할 점은 기술적 성취 그 자체가 아니라, 문제 인식부터 해결까지 이어지는 전 과정에서 AI가 어떤 역할을 했는지입니다. 정덕범 PM은 단순히 코딩 도구로서의 AI를 활용한 것이 아니라, 문제 정의, 설계, 구현, 테스트, 배포, 유지보수라는 소프트웨어 개발의 전체 생명주기를 AI와 함께 경험했습니다. 이는 AI가 개발의 일부를 돕는 수준을 넘어, 비개발자도 완전한 개발 워크플로우를 수행할 수 있게 만드는 시대가 도래했음을 의미합니다.
문제 중심 사고의 중요성
이 사례에서 가장 인상적인 부분은 시작점입니다. 정덕범 PM은 라인과 야후 재팬 합병 과정에서 보안 정책 강화로 외부 피그마 플러그인 사용이 금지되자, 화면 설계 이미지에 주석을 다는 단순 반복 작업에 막대한 시간을 소비해야 하는 상황에 직면했습니다. 스크린샷을 찍고, PPT로 옮기고, 번호를 매기고, 수정사항이 생길 때마다 처음부터 다시 작업하는 과정은 누가 봐도 비효율적이었습니다.
여기서 중요한 것은 많은 사람들이 이런 불편함을 경험하지만, 대부분은 그저 ‘원래 그런 것’으로 받아들이고 넘어간다는 점입니다. 하지만 정덕범 PM은 이 문제를 명확히 인식하고 “이 귀찮은 일을 어떻게든 자동화하고 싶다”는 간절함으로 행동에 옮겼습니다. 이것이 바로 AI 시대에 필요한 핵심 역량입니다. AI 도구의 존재 여부가 아니라, 문제를 문제로 인식하고 해결하려는 의지가 모든 것의 출발점입니다.
실제로 많은 기업들이 AI 도구를 도입했음에도 생산성 향상을 체감하지 못하는 이유도 여기에 있습니다. 도구는 있지만 ‘무엇을 해결할 것인가’에 대한 명확한 문제의식이 없으면, AI는 그저 또 하나의 검색 엔진이나 번역기 수준에 머물게 됩니다. 정덕범 PM의 사례는 구체적이고 반복적인 업무상의 문제가 있었고, 그것을 해결하려는 뚜렷한 동기가 있었기에 가능했던 것입니다.
Claude와의 만남: 프로토타입의 탄생
정덕범 PM이 사내 AI 페어 프로그래밍 스터디를 통해 Claude를 만난 시점은 2024년입니다. 당시에는 아직 ‘Claude Code’가 나오기 전이었고, ‘바이브 코딩’이라는 용어조차 존재하지 않았던 시기였습니다. 그는 Claude의 아티팩트 기능을 활용해 스크린샷에 번호를 입력하는 간단한 기능부터 시작했고, 웹 프리뷰를 통해 결과물이 즉각 동작하는 것을 확인할 수 있었습니다.
여기서 주목할 점은 초기 진입 장벽이 얼마나 낮았는지입니다. 파이썬 코드를 웹 기반으로 바꿔달라고 요청하자 Claude는 즉시 HTML/CSS/JavaScript로 된 웹 애플리케이션을 만들어주었습니다. 전통적인 개발 환경이었다면 로컬 환경 설정, 프레임워크 선택, 빌드 도구 구성 등 복잡한 초기 설정 과정을 거쳐야 했을 것입니다. 하지만 Claude의 아티팩트 기능은 이 모든 과정을 생략하고, 즉시 작동하는 프로토타입을 제공했습니다.
이것이 바로 AI가 가져온 혁명적 변화입니다. 과거에는 아이디어를 실제 동작하는 소프트웨어로 만들기까지의 간극이 너무 컸습니다. 개발 환경을 구축하는 것만으로도 초보자에게는 거대한 벽이었죠. 하지만 이제는 자연어로 요구사항을 설명하면 즉시 동작하는 결과물을 얻을 수 있습니다. 이는 ‘생각에서 실행까지의 시간(Time to Prototype)’을 극적으로 단축시켰고, 더 많은 사람들이 자신의 아이디어를 직접 구현해볼 수 있는 민주화를 가져왔습니다.
피드백과 성장: 커뮤니티의 힘
정덕범 PM은 만든 도구를 혼자만 사용하지 않고 사내 게시판과 동료들에게 공유했습니다. 그리고 즉시 뜨거운 반응과 함께 다양한 피드백을 받았습니다. 조직마다 다른 키 컬러를 고려한 주석 색상 선택, 모자이크 설정, 실행 취소, 주석 번호 크기 조절 등 실질적인 요구사항들이 쏟아졌습니다.
이 과정은 제품 개발의 핵심을 보여줍니다. 혼자만의 문제 해결이 아니라, 같은 문제를 겪는 사람들과 함께 솔루션을 발전시켜 나가는 것입니다. 피드백을 받고 빠르게 반영하는 과정에서 정덕범 PM은 단순한 도구 사용자를 넘어 제품 관리자로서의 역량을 발휘했습니다. 우선순위를 정하고, 어떤 기능을 먼저 구현할지 결정하고, 사용자의 요구와 기술적 실현 가능성 사이에서 균형을 맞추는 것은 전형적인 PM의 업무입니다.
초기에는 2~3일 간격으로 빠르게 배포하며 애자일한 개발 사이클을 유지했습니다. 이는 AI 도구가 가능하게 한 또 다른 변화입니다. 전통적인 개발 환경에서는 작은 기능 하나를 추가하는 데도 상당한 시간이 걸렸지만, AI와 함께라면 훨씬 빠른 이터레이션이 가능합니다. 사용자 피드백을 받고 즉시 반영해 다시 배포하는 빠른 순환 구조는 제품의 품질을 높이는 가장 효과적인 방법입니다.
첫 번째 위기: 기술 부채의 축적
하지만 기능이 많아질수록 문제가 생기기 시작했습니다. 배포 간격이 점점 길어지고, 코드가 길어지면서 사이드 이펙트를 관리하기 어려워졌습니다. 나중에는 배포 주기가 한 달을 넘기고, 결국 서비스를 제대로 관리하지 못한 채 방치하는 시기를 겪게 됩니다.
이것은 매우 중요한 교훈을 담고 있습니다. AI가 코드 작성을 도와주더라도, 소프트웨어 공학의 기본 원칙은 여전히 유효하다는 것입니다. 체계적인 구조 없이 기능만 계속 추가하다 보면 코드는 점점 복잡해지고, 새로운 기능을 추가하거나 버그를 수정하는 것이 기하급수적으로 어려워집니다. 이것이 바로 기술 부채(Technical Debt)입니다.
많은 사람들이 AI 시대에는 코드 품질이나 아키텍처 같은 것들이 덜 중요해질 것이라고 생각하지만, 실제로는 오히려 더 중요해집니다. AI가 코드를 빠르게 생성해주는 만큼, 관리하지 않으면 기술 부채도 빠르게 쌓입니다. 정덕범 PM이 경험한 3개월간의 공백기는 바로 이 기술 부채가 임계점에 도달했을 때의 결과입니다.
전통적인 개발에서는 숙련된 개발자들이 코드 리뷰, 리팩토링, 테스트 작성 등을 통해 이런 문제를 예방합니다. 하지만 비개발자가 AI와 함께 개발할 때는 이런 경험과 지식이 부족할 수 있습니다. 기능은 빠르게 추가되지만, 장기적인 유지보수성은 고려되지 않는 것입니다. 이것이 바로 ‘바이브 코딩’의 가장 큰 함정입니다.
Claude Code의 등장: 게임 체인저
2024년 중반, Anthropic은 Claude Code를 출시했습니다. 정덕범 PM은 사내 ‘LINE AI Summer Bootcamp’를 통해 Claude Code를 접하게 되었고, 이것은 그의 개발 경험을 완전히 바꿔놓았습니다.
Claude Code의 가장 큰 차이점은 단순히 코드를 생성하는 것을 넘어, 실제 개발 환경에서 파일을 읽고 쓰고, 터미널 명령을 실행하고, 테스트를 돌리고, 깃 커밋을 하는 등 개발 워크플로우 전체를 자동화할 수 있다는 점입니다. 이는 기존의 Claude 아티팩트나 ChatGPT의 코드 인터프리터와는 완전히 다른 수준의 통합입니다.
정덕범 PM이 Claude Code로 가장 먼저 한 일은 매우 전략적이었습니다. 새로운 기능을 추가하는 대신, 테스트 도구를 구축한 것입니다. 로컬 환경에서 핵심 기능들을 검증할 수 있는 유닛 테스트와 자동화 테스트 시스템을 만들어 50개 이상의 테스트 케이스를 구축했습니다. 이것은 그가 이전의 위기에서 무엇을 배웠는지를 보여줍니다.
테스트는 소프트웨어 개발에서 안전망 역할을 합니다. 새로운 기능을 추가하거나 코드를 수정할 때, 기존 기능이 망가지지 않았는지 자동으로 확인해줍니다. 정덕범 PM은 테스트 시스템을 구축함으로써, 이전에 겪었던 ‘기능 수정 시 발생하는 예상치 못한 버그’ 문제를 근본적으로 해결했습니다. 덕분에 개발의 안정성이 확보되었고, 크롬 익스텐션으로 영역을 확장할 수 있는 자신감을 얻었습니다.
팔방미인 Claude Code: 개발 워크플로우의 혁명
Claude Code의 진가는 단순히 코드 작성을 넘어 개발 프로세스 전반에서 드러났습니다. 이슈 관리에서는 요구사항을 말하면 몇 번의 대화로 훌륭한 이슈 디스크립션이 완성되었습니다. 커밋 메시지는 수정된 코드를 기반으로 세세한 내용까지 포함해 자동으로 작성되어 변경 이력 관리가 정확해졌습니다.
특히 인상적인 것은 4주 동안 업데이트하지 못했던 리드미를 최신화하고, 한 줄에 불과했던 릴리즈 노트를 상세하게 작성한 부분입니다. 이는 개발자들이 가장 소홀히 하기 쉬운 문서화 작업을 AI가 대신 수행할 수 있음을 보여줍니다. 실제로 많은 오픈소스 프로젝트나 사내 도구들이 훌륭한 기능을 가지고 있음에도 문서화 부족으로 활용도가 낮은 경우가 많은데, AI가 이 간극을 메울 수 있습니다.
정덕범 PM은 Claude Code를 도입한 후 개발 속도가 이전보다 8배나 증가했다고 합니다. 이것은 단순히 코드 타이핑 속도가 빨라진 것이 아닙니다. 코드 작성, 테스트, 문서화, 버전 관리 등 개발 과정의 모든 단계가 자동화되고 최적화되면서 전체적인 생산성이 비약적으로 향상된 것입니다.
두 번째 위기: 6,000라인의 코드 폭탄
하지만 2024년 8월, 다시 한번 위기가 찾아왔습니다. 많은 기능을 추가하다 보니 메인 파일 두 개가 각각 3,000라인에 육박하며 총 6,000라인이 넘는 ‘코드 폭탄’ 상태가 되었습니다. 문제는 파일이 너무 길어져서 Claude Code조차 전체 내용을 제대로 읽지 못해 리팩토링에 실패했다는 점입니다.
이것은 AI의 현재 한계를 보여주는 중요한 사례입니다. 2024년 중반의 Claude는 컨텍스트 윈도우가 제한적이었고, 너무 긴 파일을 한 번에 처리하는 데 어려움을 겪었습니다. AI가 아무리 강력해도, 입력으로 받을 수 있는 정보의 양에는 한계가 있었던 것입니다. 이는 결국 소프트웨어 아키텍처의 중요성을 다시 한번 강조합니다. 하나의 파일에 모든 것을 넣는 것이 아니라, 적절히 모듈화하고 분리하는 것이 왜 중요한지를 보여주는 사례입니다.
이 문제로 정덕범 PM은 약 3개월간의 공백기를 겪었습니다. 코드가 너무 복잡해져서 새로운 기능을 추가하는 것도, 버그를 수정하는 것도 두려워졌을 것입니다. 한 곳을 수정하면 다른 곳에서 문제가 생기는 상황이 반복되면, 결국 프로젝트를 손대기가 두려워집니다. 이것은 기술 부채가 임계점을 넘었을 때 나타나는 전형적인 증상입니다.
AI의 진화: 불가능이 가능으로
그런데 몇 달 후, 상황이 완전히 달라졌습니다. “클로드 코드가 그동안 많이 업데이트됐겠지”라는 믿음으로 다시 시도했을 때, 같은 프롬프트임에도 불구하고 Claude Code는 3,400라인이 넘는 코드를 500라인 이하의 논리적 모듈로 쪼개 체계적으로 구조화해주었습니다.
이것은 AI 발전 속도의 놀라운 면모를 보여줍니다. 불과 몇 달 사이에 이전에는 불가능했던 작업이 가능해진 것입니다. 2024년 10월 Claude Sonnet 3.5의 업데이트, 2025년 초 Claude Sonnet 4의 출시를 거치며 컨텍스트 이해 능력과 코드 구조화 능력이 크게 향상되었습니다. 특히 Claude는 대규모 코드베이스를 이해하고 리팩토링하는 능력에서 다른 AI 모델들보다 뛰어난 성능을 보여왔습니다.
정덕범 PM이 경험한 것은 단순히 도구의 업그레이드가 아니라, AI 기술 자체의 급격한 진화입니다. 과거에는 6개월, 1년 단위로 기술이 발전했다면, 이제는 몇 달, 심지어 몇 주 단위로 새로운 버전이 나오고 성능이 개선됩니다. 이것은 AI를 활용하는 사람들에게 중요한 교훈을 줍니다. 한 번 실패했다고 포기하지 말고, 조금 기다렸다가 다시 시도하면 예상치 못한 돌파구를 찾을 수 있다는 것입니다.
Zero to One: 무에서 유를 창조하다
정덕범 PM은 이 경험을 통해 비개발자로서 ‘Zero to One’의 귀중한 경험을 얻었다고 말합니다. 깃허브, VS Code, 터미널 같은 개발 도구들이 이제는 손에 익어 업무 전반에 자연스럽게 녹아들었습니다.
이것은 매우 의미심장한 변화입니다. 과거에는 이런 도구들을 배우는 것 자체가 진입 장벽이었습니다. 컴퓨터공학을 전공하거나 별도로 부트캠프를 다녀야 익힐 수 있는 것들이었죠. 하지만 AI와 함께라면 이런 도구들을 실제 프로젝트를 진행하면서 자연스럽게 배울 수 있습니다. 깃 명령어를 외우지 않아도 필요할 때마다 AI에게 물어보면 되고, 터미널 명령어의 의미를 모르더라도 AI가 설명해주고 실행까지 대신 해줍니다.
이는 학습 방식의 근본적인 변화를 의미합니다. 과거에는 ‘이론 학습 → 실습 → 프로젝트’의 순서로 배웠다면, 이제는 ‘프로젝트 → 필요한 지식을 AI와 함께 즉시 학습 → 적용’의 순서로 바뀌었습니다. 이것을 Just-in-Time Learning이라고 할 수 있습니다. 모든 것을 미리 배울 필요 없이, 필요한 순간에 필요한 만큼만 배우면 됩니다.
현실적인 수익화: 꿈과 현실의 간극
정덕범 PM은 AnnotateShot에 광고를 붙여 약 10일간 운영한 결과 수익이 고작 0.09달러였다고 솔직하게 공유합니다. 1년 도메인 비용 2만 원조차 충당하기 힘든 수준이었습니다. 또한 서비스 매각 플랫폼에서 5,000~25,000달러라는 가격이 나왔지만, Claude에게 비판적 분석을 요청하자 “수익 모델이 명확하지 않고, 큰 기업이 복제하기 쉬운 틈새 도구”라는 냉정한 평가를 받았습니다.
이것은 매우 중요한 현실입니다. AI 도구가 소프트웨어 개발을 민주화했다는 것은 동시에 진입 장벽이 낮아졌다는 의미이기도 합니다. 누구나 쉽게 만들 수 있다면, 그만큼 경쟁도 치열해지고 차별화도 어려워집니다. 특히 AnnotateShot 같은 생산성 도구는 기능 자체가 단순하고 명확해서 더 큰 기업이 쉽게 복제할 수 있습니다.
실제로 이런 문제는 AI 시대의 스타트업들이 공통적으로 직면하고 있는 과제입니다. AI를 활용하면 빠르게 MVP(Minimum Viable Product)를 만들 수 있지만, 그것을 지속 가능한 비즈니스로 만드는 것은 전혀 다른 문제입니다. 기술 장벽이 낮아진 만큼, 네트워크 효과, 브랜드 파워, 데이터 독점 같은 다른 형태의 해자(moat)가 더욱 중요해졌습니다.
하지만 정덕범 PM은 매우 현명한 결정을 내렸습니다. 이 서비스를 수익 사업으로 보지 않고, 자신의 역량을 증명하는 포트폴리오로 가치를 재정의한 것입니다. 실제로 비개발자가 실제 동작하는 서비스를 만들고 운영한 경험은, PM으로서의 경력에 큰 자산이 됩니다. 개발자와 협업할 때 훨씬 구체적이고 현실적인 대화가 가능해지고, 기술적 가능성과 한계를 더 잘 이해할 수 있게 됩니다.
세컨드 브레인: AI가 바꾼 업무 방식
정덕범 PM에게 가장 큰 변화는 AI가 ‘세컨드 브레인’이 되었다는 점입니다. 그는 사내 일정, 지라 티켓, 위키, 깃허브를 모두 Claude Code와 연결해 업무 로그를 아카이브하고 있습니다. 이슈가 발생했을 때 Claude와 토론하고, 의사결정 과정을 기록으로 남기는 방식은 업무 효율을 극대화했습니다.
이것은 단순히 메모 도구를 쓰는 것과는 차원이 다릅니다. AI는 단순히 정보를 저장하는 것을 넘어, 저장된 정보를 맥락에 맞게 검색하고, 관련된 내용들을 연결하고, 필요한 인사이트를 도출해냅니다. 예를 들어 새로운 기능을 개발할 때, 과거에 비슷한 기능을 어떻게 구현했는지, 어떤 문제가 있었는지, 어떤 결정을 내렸는지를 AI가 찾아주고 상기시켜줍니다.
이것은 조직 차원에서도 큰 의미가 있습니다. 많은 기업들이 사내 위키나 문서 시스템을 구축해놓고도 제대로 활용하지 못하는 이유는, 필요한 정보를 찾는 것이 어렵기 때문입니다. 하지만 AI는 자연어로 질문하면 관련된 문서들을 찾아주고, 여러 문서에 흩어진 정보를 종합해서 답을 줄 수 있습니다. 이것이 바로 ‘AI-Powered Knowledge Management’의 진정한 가치입니다.
다만 정덕범 PM도 인정했듯이, AI 의존도가 높아지면서 새로운 문제도 생겼습니다. 회사 토큰 사용자가 몰릴 때는 본인의 생산성도 함께 느려진다는 것입니다. 이것은 AI 시대의 새로운 리스크입니다. 과거에는 개인의 생산성이 주로 본인의 능력과 도구에 의존했다면, 이제는 AI 서비스의 가용성과 성능에도 크게 영향을 받습니다. 기업 입장에서는 중요한 업무에 AI를 활용할 때, 이런 의존성을 어떻게 관리할 것인지 고민해야 합니다.
PM 역할의 진화: 구현까지 하는 기획자
정덕범 PM의 사례는 PM 역할의 진화를 보여줍니다. 전통적으로 PM은 무엇을 만들 것인지를 정의하고, 개발자는 어떻게 만들 것인지를 담당했습니다. 하지만 이제 PM이 직접 프로토타입을 만들고, 심지어 간단한 기능은 직접 구현해서 배포할 수 있게 되었습니다.
이것은 제품 개발 프로세스를 크게 변화시킵니다. 과거에는 PM이 기획서를 쓰면 개발자가 구현하고, 결과물이 나와야 피드백을 받을 수 있었습니다. 이 과정에서 커뮤니케이션 비용이 크게 발생했고, 기획 의도가 제대로 전달되지 않는 경우도 많았습니다. 하지만 PM이 직접 프로토타입을 만들면 자신의 의도를 정확히 구현할 수 있고, 빠르게 사용자 피드백을 받아 개선할 수 있습니다.
또한 PM이 실제 구현을 경험하면서 기술적 제약과 가능성을 더 잘 이해하게 됩니다. 추상적인 아이디어만 생각할 때와 실제로 코드를 다뤄보는 것은 완전히 다른 경험입니다. 정덕범 PM이 경험한 것처럼, 기능을 추가할수록 복잡도가 증가하고, 리팩토링이 필요하고, 테스트가 중요하다는 것을 몸소 느끼게 됩니다. 이런 경험은 개발자와 협업할 때 훨씬 현실적이고 구체적인 대화를 가능하게 합니다.
다만 모든 PM이 개발을 해야 한다는 의미는 아닙니다. 정덕범 PM의 사례는 자신이 직면한 구체적인 문제를 해결하기 위해 필요에 의해 개발을 시작했고, 그 과정에서 많은 것을 배웠다는 점에서 의미가 있습니다. 개발 자체가 목적이 아니라, 더 나은 제품을 만들기 위한 수단으로 활용한 것입니다.
바이브 코딩의 명암: 호기심과 지속성
Q&A 세션에서 정덕범 PM은 바이브 코딩에 필요한 것으로 ‘호기심’을 강조했습니다. 특정 기술 지식보다 문제를 해결하려는 호기심과 의지가 더 중요하다는 것입니다. 실제로 주변 동료들을 보면 CTO나 임원들도 직접 회의용 도구를 만들고, 디자이너들도 사내 공유회를 열 정도로 AI 도구를 활발히 활용하고 있습니다.
하지만 동시에 지속성의 문제도 언급했습니다. “시켜서 하는 게 아니라 본인이 만들고 싶은 것이 확실한 사람들은 계속 이어가지만, 그렇지 않은 경우에는 금방 멈춘다”는 것입니다. 이것은 바이브 코딩의 본질을 정확히 짚은 통찰입니다.
AI가 개발을 쉽게 만들어주긴 하지만, 여전히 상당한 노력과 시간 투자가 필요합니다. 정덕범 PM도 1년 넘게 지속적으로 서비스를 개선하고, 여러 차례 위기를 극복하며 배워왔습니다. 단순히 도구를 사용하는 것과 제대로 된 제품을 만들어내는 것 사이에는 여전히 큰 간극이 있습니다. 그 간극을 메우는 것은 결국 만들고자 하는 대상에 대한 진정한 관심과 문제를 해결하려는 절실함입니다.
많은 사람들이 AI 도구를 시도해보다가 초기의 흥분이 지나면 그만두는 이유도 여기에 있습니다. 처음에는 AI가 마법처럼 느껴지지만, 실제로 무언가를 제대로 만들려면 수많은 시행착오와 디버깅, 개선의 과정을 거쳐야 합니다. AI가 도와주더라도 이 과정 자체가 사라지는 것은 아닙니다. 다만 과거보다 훨씬 빠르고 접근하기 쉬워졌을 뿐입니다.
MCP와 통합의 미래
발표 후 정덕범 PM은 MCP(Model Context Protocol)를 실제로 만들어보고 이해하게 되었다고 덧붙였습니다. 그는 특정 전문 지식이나 사내 지식이 존재하는 곳의 MCP가 유용하다고 판단했지만, 인증 문제 때문에 개별 Skill이 더 편리하게 느껴졌다고 합니다.
이것은 현재 AI 도구 생태계의 과도기적 상황을 보여줍니다. MCP는 Claude를 다양한 외부 시스템과 연결해 더 강력한 기능을 제공할 수 있는 표준 프로토콜입니다. 이론적으로는 매우 강력하지만, 실제 사용에서는 인증, 권한 관리, 설정의 복잡성 등 여러 실무적인 문제들이 있습니다.
다만 장기적으로 보면 MCP 같은 표준화된 통합 방식이 중요해질 것입니다. 현재는 각 도구마다 개별적으로 연결 방법을 만들고 있지만, 이것은 확장성이 떨어집니다. 표준 프로토콜이 정착되면 한 번의 설정으로 여러 도구를 연결할 수 있고, AI가 상황에 맞게 적절한 도구를 선택해 사용할 수 있게 됩니다. 정덕범 PM도 이를 인식하고 있어서 계속 학습하고 적용을 시도하고 있는 것으로 보입니다.
한국 기업의 AI 도입: 라인의 사례
정덕범 PM의 사례에서 주목할 또 다른 점은 라인플러스라는 기업의 AI 도입 전략입니다. 사내 AI 페어 프로그래밍 스터디를 운영하고, ‘LINE AI Summer Bootcamp’를 통해 직원들이 원하는 AI 도구를 선택해 사용할 수 있도록 지원한 것은 매우 선진적인 접근입니다.
많은 한국 기업들이 AI 도입을 고민하지만, 실제로는 보안 우려, 비용 문제, 활용 방법을 모르는 등의 이유로 주저하고 있습니다. 하지만 라인은 직원들에게 직접 경험할 기회를 주고, 자율적으로 활용 사례를 만들어가도록 했습니다. 정덕범 PM의 AnnotateShot이 사내에서 큰 반향을 일으킨 것도 이런 문화가 있었기에 가능했습니다.
특히 주목할 점은 CTO와 임원들도 직접 도구를 만들고, 디자이너들도 AI 활용 사례를 공유한다는 것입니다. 이것은 AI 활용이 특정 부서나 직군의 일이 아니라, 조직 전체의 문화로 자리 잡고 있다는 의미입니다. 위에서 솔선수범하고, 실패를 허용하는 문화가 있어야 구성원들도 적극적으로 시도할 수 있습니다.
한국 기업들이 라인의 사례에서 배울 점은 명확합니다. AI 도구를 도입하는 것 자체보다, 구성원들이 자유롭게 실험하고 공유할 수 있는 환경을 만드는 것이 더 중요합니다. 실패를 두려워하지 않고, 작은 성공 사례들을 축적해가는 것이 장기적으로 조직의 AI 역량을 키우는 방법입니다.
시사점과 전망
정덕범 PM의 사례는 여러 중요한 시사점을 제공합니다.
첫째, AI는 도구의 사용법이 아니라 문제 해결 의지가 핵심이라는 것입니다. 정덕범 PM이 성공할 수 있었던 것은 Claude의 사용법을 잘 알아서가 아니라, 자신이 매일 겪는 불편함을 해결하려는 간절함이 있었기 때문입니다. 도구는 계속 발전하고 사용법도 변하지만, 문제를 발견하고 해결하려는 태도는 변하지 않습니다.
둘째, AI 시대에도 소프트웨어 공학의 기본 원칙은 여전히 중요합니다. 정덕범 PM이 겪은 두 차례의 위기는 모두 기술 부채의 축적에서 비롯되었습니다. AI가 코드를 빠르게 생성해주지만, 장기적인 유지보수성을 고려한 설계, 테스트, 리팩토링은 여전히 필요합니다. 오히려 AI가 코드 생성을 빠르게 해주는 만큼, 이런 기본 원칙이 더욱 중요해졌다고 볼 수 있습니다.
셋째, AI의 발전 속도는 상상 이상으로 빠릅니다. 몇 달 전에 불가능했던 것이 지금은 가능해지고, 지금 어려운 것이 몇 달 후에는 쉬워질 수 있습니다. 따라서 한 번 실패했다고 포기하지 말고, 지속적으로 새로운 버전을 시도해보는 것이 중요합니다. 동시에 AI 도구에 대한 투자는 미래를 대비하는 투자이기도 합니다. 지금 배운 것이 몇 달 후 훨씬 강력한 도구로 활용될 수 있기 때문입니다.
넷째, 수익화는 여전히 어려운 과제입니다. AI가 개발을 쉽게 만들어주지만, 그것이 곧 성공적인 비즈니스를 의미하지는 않습니다. 진입 장벽이 낮아진 만큼 경쟁도 치열해지고, 다른 형태의 경쟁 우위가 더욱 중요해졌습니다. 다만 개인의 역량 개발이나 포트폴리오 구축 측면에서는 매우 큰 가치가 있습니다.
다섯째, AI는 단순한 도구를 넘어 업무 방식 자체를 바꾸고 있습니다. 세컨드 브레인으로서 AI를 활용하면 정보 관리, 의사결정, 지식 공유의 방식이 근본적으로 달라집니다. 이것은 개인뿐만 아니라 조직 차원에서도 큰 변화를 가져올 것입니다.
여섯째, 역할의 경계가 모호해지고 있습니다. PM이 개발을 하고, 개발자가 디자인을 하고, 디자이너가 코딩을 하는 시대가 왔습니다. 이것은 각자의 전문성이 사라진다는 의미가 아니라, 다른 영역에 대한 이해와 협업이 더 깊어진다는 의미입니다. T자형 인재에서 파이형(π-shaped) 인재로, 즉 두 개 이상의 전문 영역을 가진 사람들이 더 큰 가치를 발휘하게 될 것입니다.
2025-2026년 전망: 가속화되는 변화
2025년 들어 AI 개발 도구는 더욱 빠르게 발전하고 있습니다. Claude Sonnet 4.5의 등장으로 코드 생성 및 리팩토링 능력이 크게 향상되었고, OpenAI의 o3 모델은 추론 능력에서 새로운 지평을 열었습니다. 중국의 DeepSeek-R1은 오픈소스로 공개되어 누구나 사용할 수 있게 되었습니다.
이런 발전은 정덕범 PM 같은 비개발자들이 더 복잡한 프로젝트를 수행할 수 있게 만들 것입니다. 단순한 도구나 웹사이트를 넘어, 모바일 앱, 데이터 파이프라인, 심지어 AI 모델 학습까지도 비개발자가 직접 할 수 있는 시대가 다가오고 있습니다.
특히 주목할 것은 에이전틱 AI(Agentic AI)의 발전입니다. 현재의 Claude Code는 사용자의 지시를 받아 작업을 수행하지만, 앞으로는 더 자율적으로 문제를 분석하고 해결책을 제시하며 실행까지 할 수 있게 될 것입니다. 예를 들어 “사용자 피드백을 분석해서 가장 시급한 기능을 찾고, 그것을 구현해서 테스트하고 배포해줘”라고 하면 AI가 전체 과정을 자동으로 수행하는 시대가 올 수 있습니다.
이런 변화는 소프트웨어 산업뿐만 아니라 모든 지식 노동에 영향을 미칠 것입니다. 변호사가 AI와 함께 계약서를 작성하고, 의사가 AI와 함께 진단하고, 건축가가 AI와 함께 설계하는 것이 일상이 될 것입니다. 정덕범 PM의 사례는 이런 미래의 작은 조각을 보여주고 있습니다.
결론: 지금 시작하라
정덕범 PM은 발표를 마치며 “마음속에만 담아둔 아이디어가 있다면, AI라는 기회를 통해 지금 바로 시작해보시길 바랍니다”라고 말했습니다. 이것은 단순한 격려가 아니라, 매우 실질적인 조언입니다.
AI 도구는 이미 충분히 성숙했고, 앞으로 더 좋아질 것입니다. 지금 시작하면 도구가 발전할 때마다 같이 성장할 수 있습니다. 반대로 늦게 시작하면 그만큼 격차가 벌어집니다. AI 활용 능력은 단순히 도구 사용법을 아는 것이 아니라, 문제를 발견하고 해결하는 경험이 축적되어야 하기 때문입니다.
특히 정덕범 PM처럼 비개발자라면 더욱 좋은 기회입니다. 개발에 대한 선입견이나 고정관념 없이, 순수하게 문제 해결에 집중할 수 있기 때문입니다. 전통적인 방식으로 개발을 배우려면 몇 년이 걸리지만, AI와 함께라면 몇 달, 심지어 몇 주 만에 의미 있는 결과물을 만들 수 있습니다.
이 사례가 우리에게 주는 가장 큰 교훈은 “실행의 중요성”입니다. 정덕범 PM은 완벽한 계획을 세우거나 모든 것을 배운 후 시작한 것이 아닙니다. 불편한 문제를 발견했고, AI 도구를 알게 되었고, 바로 시도했습니다. 실패도 있었고 위기도 있었지만, 포기하지 않고 계속 개선해나갔습니다. 그 결과 1년 후에는 자신의 서비스를 운영하고, 다음 프로젝트까지 진행하는 단계에 이르렀습니다.
2026년은 AI와 함께 일하는 것이 선택이 아니라 필수가 되는 해가 될 것입니다. 정덕범 PM의 사례는 그 길을 먼저 걸어간 선구자의 발자취입니다. 이제 우리 차례입니다. 여러분도 해결하고 싶은 문제가 있다면, 오늘 당장 Claude Code를 열고 첫 대화를 시작해보시기 바랍니다. 1년 후 여러분의 이야기를 듣게 되기를 기대합니다.
작성 일자: 2026-01-13