<div id="readability-page-1" class="page"><section itemprop="text">
        
        <h2 id="intro">Intro</h2>

<p>요즘 개발하면서 Claude Code, Cursor, Copilot 같은 AI 코딩 도구를 활용하지 않는 개발자를 찾아보기 힘들 정도가 됐다. 나도 그렇다. 몇 달 전부터 적극적으로 사용하고 있다.</p>

<p>그런데 솔직히 말하면, AI를 이용한 개발이 항상 “해줘”로 결과물이 나오는 건 아니다. 어떤 날은 몇 시간 대화해도 원하는 결과물을 얻지 못하고, 결국 직접 개발하는 게 낫겠다 싶을 때도 있다. 그럼에도 나를 포함해 많은 개발자들이 AI 도구를 계속 쓴다. 왜 그럴까? 내가 생각하는 이유들을 적어본다.</p>

<h2 id="그거-그렇게-하는-거-아닌데">그거 그렇게 하는 거 아닌데</h2>

<p>개발자라면 누구나 비슷한 경험이 있을 것이다. 시니어 개발자가 내 코드를 보고 “이건 이렇게 하는 게 더 낫지 않을까?”라며 훈수를 두던 순간. 나도 처음에는 지적받는 게 창피했지만, 그 과정에서 배운 것들이 가장 깊게 남아있다.</p>

<p>사람은 누구나 자신의 지식을 누군가에게 전파하고 싶은 욕구가 있다고 생각한다. 개발자들은 특히 더 그렇다. 개발 블로그나 오픈소스 같은 활동들이 일종의 그런 니즈에 의해 나온 결과물이라 생각하고, 이런 활동들이 지금의 개발 문화를 만드는 데 큰 기여를 했다고도 생각한다.</p>

<p>그런데 훈수를 받는 입장에서는 마냥 달가워하지 않는 사람들도 있다. 오죽하면 ‘훈수충’이라는 단어가 생겼겠는가. AI는 훈수 두기에 정말 좋은 대상이다. 언제나 긍정적이고 수용적이다. 내가 “이렇게 해봐”라고 제안하면 AI는 즉시 그 방향으로 수정한다. 실패를 두려워하지 않고 여러 방식을 시도해볼 수 있고, 내 아이디어를 빠르게 구현해서 검증해볼 수 있다. 과거엔 시니어에게 받던 피드백을 이제는 내가 AI에게 직접 줄 수 있는 입장이 된 셈이다.</p>

<h2 id="그건-니가-구현해야지">그건 니가 구현해야지</h2>

<p>훈수의 묘미는 “그건 네가 알아서 구현해”라고 떠넘길 수 있다는 데 있다. 방향만 던지고 세부는 듣는 사람의 몫이다. 생각해보면 AI 코딩 도구가 매력적인 이유가 여기 있는 것 같다. 처음으로 우리는 “알아서 구현해”라고 말할 수 있는 상대를 갖게 됐다.</p>

<p>실무를 보면 그렇다. 수많은 개발자들이 업무를 하면서 힘들어했던 가장 큰 부분 중 하나가 요구사항의 모호함이다. 개발자의 실력을 판가름하는 척도 중 하나도 이 모호한 요구사항을 잘 파악해서 구현해내는 능력이다.</p>

<p>AI 코딩 도구는 context만 잘 주어지면 모호하게 이야기해도 알아서 잘 해주는 능력을 보여준다. “사용자 정보가 담긴 JSON을 읽어서 User 객체로 변환한 뒤 데이터베이스에 저장해. 데이터 검증도 해야 하고 중복된 이메일은 건너뛰어야 해”라는 정도의 요구만 줬는데, AI는 라이브러리 선택부터 에러 처리까지 일관성 있게 구현해냈다.</p>

<p>반복적인 보일러플레이트 작업이 대부분인 실무에서 이건 정말 큰 변화다. 내가 JSON 파싱, 데이터 검증, 에러 처리 같은 세세한 구현에 시간을 쓰지 않아도 된다는 뜻이다. 대신 “이게 정말 필요한가?”, “더 좋은 방식이 있을까?” 같은 고차원의 질문에 집중할 수 있다.</p>

<h2 id="롤러코스터-타이쿤">롤러코스터 타이쿤</h2>

<p>롤러코스터 타이쿤을 해본 적 있는가. 나는 좋아했다. 내가 만들어둔 세상에서 사람들이 놀이기구를 타고 돌아다니면서 경제활동을 하고, 그렇게 번 돈으로 놀이기구를 추가로 만들면서 점진적으로 나만의 놀이동산을 키워나가는 재미. 해본 사람들이라면 다들 느꼈을 것이다.</p>

<p>AI 에이전트를 사용해본 사람들이라면 아마 내가 무슨 말 하는지 이해할 것이다. 요구사항을 주고 실행시켜두면 프롬프트 화면에서 에이전트가 파일을 읽고, 코드를 작성하고, 테스트를 돌리는 것을 지켜볼 수 있다. 내가 모든 걸 이해할 순 없지만 방향은 따라갈 수 있고, 중간중간 “이 부분은 이렇게 해줘”라며 조정하면서 원하는 결과물로 가이드하는 재미가 있다.</p>

<p>얼마 전에 내부 어드민 대시보드를 만들 일이 있었다. 과거 같았으면 라우팅 만들고, 폼 만들고, API 붙이고, 테이블 페이지네이션 짜고 하면서 이틀은 잡아야 했을 작업이었다. 에이전트에 작업을 맡겨두고 중간중간 방향을 조정하면서 하루 안에 동작하는 화면을 볼 수 있었다. 롤러코스터 타이쿤에서 놀이동산이 점점 완성되어가는 것을 지켜보는 것처럼.</p>

<h2 id="새로운-장인정신">새로운 장인정신</h2>

<p>어쩌면 디자인 패턴을 적용하고 가독성 높은 코드를 작성하는 등의 ‘사람’에게 좋은 코드를 작성하는 장인정신이, 이제는 ‘AI와 협업하기 좋은 코드’를 작성하는 장인정신으로 옮겨지고 있지 않나 생각이 든다.</p>

<p>코드를 쓸 때 “AI가 이걸 어떻게 이해할까?”를 먼저 생각하게 됐다. 추상적이면서 모호한 코드보다 명시적이고 구조적이어서 AI가 손쉽게 맥락을 파악할 수 있는 코드. 애매한 축약, 암묵적인 규칙, 마법 같은 패턴들은 AI 관점에서는 오히려 문제가 된다.</p>

<p>흥미로운 건, 그렇게 작성한 코드가 결과적으로 다른 사람도 더 쉽게 이해할 수 있다는 것이다. 좋은 코드의 본질은 결국 같다. 그 도구가 망치나 톱이 아니라 AI일 뿐이다.</p>

<p>한편으로는 코드를 한 땀 한 땀 작성하기를 좋아하는 사람에게는 아쉬움이 많은 현재가 될 것 같다. 반면 거시적인 관점에서 아키텍처를 그리고 제품을 만드는 것에 재미를 느끼는 사람이라면 아마 황금기가 아닐까 싶다.</p>

<h2 id="생산성의-역설">생산성의 역설</h2>

<p>밝은 면만 있는 건 아니다.</p>

<p>AI 도구 덕분에 MVP를 만드는 속도는 정말 빨라졌다. 원래 일주일 걸릴 일이 이틀에 끝나기도 한다. 빠른 실험과 빠른 검증이 가능해졌다. 이건 분명 좋은 변화다.</p>

<p>그런데 속도만 빨라졌지, 완성도는 어떨까? 보안 검토는? 성능 최적화는? 비기능적 요구사항들은?</p>

<p>AI가 생성한 코드는 “작동하는” 코드다. 하지만 “잘 만들어진” 코드인지는 별개다. 내가 속한 팀에서도 이 문제를 겪었다. 에이전트가 빠르게 만들어낸 코드에서 나중에 권한 체크 누락이나 동시성 문제가 발견된 적이 있다. 동작은 했다. PR도 통과했다. 문제는 뒤늦게 드러났다.</p>

<p>결국 개발자는 AI가 만든 코드를 읽고 이해하고 검토하고 수정하는 새로운 업무를 갖게 되었다. 생산성이 증가한 건 맞는데, 그만큼의 책임도 함께 증가했다는 걸 느낀다. 속도 vs 품질이라는 오래된 트레이드오프는 여전히 존재한다.</p>

<h2 id="집중력-상실의-시대">집중력 상실의 시대</h2>

<p>AI가 등장하면서 코드도, 문서도 폭발적으로 늘었다. 양과 퀄리티가 상당히 좋아졌지만, 점점 더 장황해지고 비대해지면서 오히려 맥락을 파악하기 힘들어졌다.</p>

<p>코드도 그렇다. 손쉽게 코드를 작성할 수 있다 보니 하나의 병합 요청에 수많은 코드가 작성되고, 맥락을 파악하기 힘든 병합 요청은 자연스럽게 LGTM을 유발하게 된다. 누가 이 코드를 깊이 있게 이해했는가? 솔직히 모른다.</p>

<p>과거에는 코드를 직접 모두 작성했기 때문에 자연스럽게 깊은 이해가 생겼다. 지금은 “이게 뭐지?”라며 읽기 시작하고, 이해하고 나면 다음으로 넘어간다. 깊이 있는 몰입보다는 표면적인 검토에 그치기 쉽다.</p>

<p>아무튼 이제는 디테일을 고민하지 않아도 되니 깊게 몰입하면서 생기는 집중력이 점점 더 떨어지지 않나 싶다. 이게 장기적으로 어떤 영향을 미칠지, 솔직히 아직은 잘 모르겠다.</p>

<h2 id="어쩌면-우리-모두-c레벨이-된-거-아닐까">어쩌면 우리 모두 C레벨이 된 거 아닐까</h2>

<p>어쩌면 우리는 모두가 관리자 역할을 수행하고 있는 건 아닐까. 제품을 잘 만들기 위한 방법을 고민하고, AI 도구가 좀 더 코딩을 잘 할 수 있도록 해서 효율적으로 제품을 만들어낼 수 있도록 하는 것.</p>

<p>이건 어떻게 보면 흥미롭고, 어떻게 보면 불안하다. 직접 코드를 작성하지 않으면 프로그래밍 언어에 대한 깊이 있는 이해를 유지할 수 있을까? 운전을 직접 하지 않는 운전강사처럼, 어쩌면 어색한 상황이 될 수도 있지 않을까.</p>

<p>물론 좋은 점도 있다. 기술 세부 사항에서 해방되어 더 큰 그림을 볼 수 있게 된다. 사업 가치, 사용자 경험, 아키텍처 의사결정 같은 고차원의 문제에 집중할 수 있다.</p>

<p>하지만 내가 생각하는 새로운 개발자 장인은, 평소엔 방향을 잡고 결과를 검증하면서도 필요한 순간엔 직접 코드의 가장 안쪽까지 따라 들어갈 수 있는 사람이다. 개발의 패러다임이 바뀌고 있지만, 새로운 관점에서 장인정신을 발휘하는 개발자들이 여전히 필요하다고 생각한다.</p>

<h2 id="마무리">마무리</h2>

<p>AI 코딩 도구가 처음 등장했을 때, 많은 사람들은 “개발자의 일자리가 없어질까?”라고 두려워했다. 지금 경험해보니 문제는 다른 곳에 있는 것 같다. 일자리가 없어지는 게 아니라, 하는 일의 성격이 완전히 바뀌고 있다는 것이다.</p>

<p>훈수를 두는 즐거움, 추상적 요구사항을 구현하는 경쾌함, 에이전트가 움직이는 것을 지켜보는 재미. 이런 것들이 AI 시대 개발의 매력이다. 동시에 생산성의 역설, 집중력의 감소, 역할의 재정의라는 도전도 함께 따라온다.</p>

<p>한 가지 분명한 건, AI에게 “구현해줘”라고 던지는 일이 점점 쉬워질수록, 던지기 전에 “내가 이걸 정말 이해하고 있나”라고 자문하는 시간은 점점 더 값비싸진다는 것이다.</p>

<p>새로운 장인은 거기서 갈린다고 생각한다.</p>

        
      </section></div>

Veluexer’s Blog

Intro
요즘 개발하면서 Claude Code, Cursor, Copilot 같은 AI 코딩 도구를 활용하지 않는 개발자를 찾아보기 힘들 정도가 됐다. 나도 그렇다. 몇 달 전부터 적극적으로 사용하고 있다.
그런데 솔직히 말하면, AI를 이용한 개발이 항상 “해줘”로 결과물이 나오는 건 아니다. 어떤 날은 몇 시간 대화해도 원하는 결과물을 얻지 못하고, 결국 직접 개발하는 게 낫겠다 싶을 때도 있다. 그럼에도 나를 포함해 많은 개발자들이 AI 도구를 계속 쓴다. 왜 그럴까? 내가 생각하는 이유들을 적어본다.
그거 그렇게 하는 거 아닌데
개발자라면 누구나 비슷한 경험이 있을 것이다. 시니어 개발자가 내 코드를 보고 “이건 이렇게 하는 게 더 낫지 않을까?”라며 훈수를 두던 순간. 나도 처음에는 지적받는 게 창피했지만, 그 과정에서 배운 것들이 가장 깊게 남아있다.
사람은 누구나 자신의 지식을 누군가에게 전파하고 싶은 욕구가 있다고 생각한다. 개발자들은 특히 더 그렇다. 개발 블로그나 오픈소스 같은 활동들이 일종의 그런 니즈에 의해 나온 결과물이라 생각하고, 이런 활동들이 지금의 개발 문화를 만드는 데 큰 기여를 했다고도 생각한다.
그런데 훈수를 받는 입장에서는 마냥 달가워하지 않는 사람들도 있다. 오죽하면 ‘훈수충’이라는 단어가 생겼겠는가. AI는 훈수 두기에 정말 좋은 대상이다. 언제나 긍정적이고 수용적이다. 내가 “이렇게 해봐”라고 제안하면 AI는 즉시 그 방향으로 수정한다. 실패를 두려워하지 않고 여러 방식을 시도해볼 수 있고, 내 아이디어를 빠르게 구현해서 검증해볼 수 있다. 과거엔 시니어에게 받던 피드백을 이제는 내가 AI에게 직접 줄 수 있는 입장이 된 셈이다.
그건 니가 구현해야지
훈수의 묘미는 “그건 네가 알아서 구현해”라고 떠넘길 수 있다는 데 있다. 방향만 던지고 세부는 듣는 사람의 몫이다. 생각해보면 AI 코딩 도구가 매력적인 이유가 여기 있는 것 같다. 처음으로 우리는 “알아서 구현해”라고 말할 수 있는 상대를 갖게 됐다.
실무를 보면 그렇다. 수많은 개발자들이 업무를 하면서 힘들어했던 가장 큰 부분 중 하나가 요구사항의 모호함이다. 개발자의 실력을 판가름하는 척도 중 하나도 이 모호한 요구사항을 잘 파악해서 구현해내는 능력이다.
AI 코딩 도구는 context만 잘 주어지면 모호하게 이야기해도 알아서 잘 해주는 능력을 보여준다. “사용자 정보가 담긴 JSON을 읽어서 User 객체로 변환한 뒤 데이터베이스에 저장해. 데이터 검증도 해야 하고 중복된 이메일은 건너뛰어야 해”라는 정도의 요구만 줬는데, AI는 라이브러리 선택부터 에러 처리까지 일관성 있게 구현해냈다.
반복적인 보일러플레이트 작업이 대부분인 실무에서 이건 정말 큰 변화다. 내가 JSON 파싱, 데이터 검증, 에러 처리 같은 세세한 구현에 시간을 쓰지 않아도 된다는 뜻이다. 대신 “이게 정말 필요한가?”, “더 좋은 방식이 있을까?” 같은 고차원의 질문에 집중할 수 있다.
롤러코스터 타이쿤
롤러코스터 타이쿤을 해본 적 있는가. 나는 좋아했다. 내가 만들어둔 세상에서 사람들이 놀이기구를 타고 돌아다니면서 경제활동을 하고, 그렇게 번 돈으로 놀이기구를 추가로 만들면서 점진적으로 나만의 놀이동산을 키워나가는 재미. 해본 사람들이라면 다들 느꼈을 것이다.
AI 에이전트를 사용해본 사람들이라면 아마 내가 무슨 말 하는지 이해할 것이다. 요구사항을 주고 실행시켜두면 프롬프트 화면에서 에이전트가 파일을 읽고, 코드를 작성하고, 테스트를 돌리는 것을 지켜볼 수 있다. 내가 모든 걸 이해할 순 없지만 방향은 따라갈 수 있고, 중간중간 “이 부분은 이렇게 해줘”라며 조정하면서 원하는 결과물로 가이드하는 재미가 있다.
얼마 전에 내부 어드민 대시보드를 만들 일이 있었다. 과거 같았으면 라우팅 만들고, 폼 만들고, API 붙이고, 테이블 페이지네이션 짜고 하면서 이틀은 잡아야 했을 작업이었다. 에이전트에 작업을 맡겨두고 중간중간 방향을 조정하면서 하루 안에 동작하는 화면을 볼 수 있었다. 롤러코스터 타이쿤에서 놀이동산이 점점 완성되어가는 것을 지켜보는 것처럼.
새로운 장인정신
어쩌면 디자인 패턴을 적용하고 가독성 높은 코드를 작성하는 등의 ‘사람’에게 좋은 코드를 작성하는 장인정신이, 이제는 ‘AI와 협업하기 좋은 코드’를 작성하는 장인정신으로 옮겨지고 있지 않나 생각이 든다.
코드를 쓸 때 “AI가 이걸 어떻게 이해할까?”를 먼저 생각하게 됐다. 추상적이면서 모호한 코드보다 명시적이고 구조적이어서 AI가 손쉽게 맥락을 파악할 수 있는 코드. 애매한 축약, 암묵적인 규칙, 마법 같은 패턴들은 AI 관점에서는 오히려 문제가 된다.
흥미로운 건, 그렇게 작성한 코드가 결과적으로 다른 사람도 더 쉽게 이해할 수 있다는 것이다. 좋은 코드의 본질은 결국 같다. 그 도구가 망치나 톱이 아니라 AI일 뿐이다.
한편으로는 코드를 한 땀 한 땀 작성하기를 좋아하는 사람에게는 아쉬움이 많은 현재가 될 것 같다. 반면 거시적인 관점에서 아키텍처를 그리고 제품을 만드는 것에 재미를 느끼는 사람이라면 아마 황금기가 아닐까 싶다.
생산성의 역설
밝은 면만 있는 건 아니다.
AI 도구 덕분에 MVP를 만드는 속도는 정말 빨라졌다. 원래 일주일 걸릴 일이 이틀에 끝나기도 한다. 빠른 실험과 빠른 검증이 가능해졌다. 이건 분명 좋은 변화다.
그런데 속도만 빨라졌지, 완성도는 어떨까? 보안 검토는? 성능 최적화는? 비기능적 요구사항들은?
AI가 생성한 코드는 “작동하는” 코드다. 하지만 “잘 만들어진” 코드인지는 별개다. 내가 속한 팀에서도 이 문제를 겪었다. 에이전트가 빠르게 만들어낸 코드에서 나중에 권한 체크 누락이나 동시성 문제가 발견된 적이 있다. 동작은 했다. PR도 통과했다. 문제는 뒤늦게 드러났다.
결국 개발자는 AI가 만든 코드를 읽고 이해하고 검토하고 수정하는 새로운 업무를 갖게 되었다. 생산성이 증가한 건 맞는데, 그만큼의 책임도 함께 증가했다는 걸 느낀다. 속도 vs 품질이라는 오래된 트레이드오프는 여전히 존재한다.
집중력 상실의 시대
AI가 등장하면서 코드도, 문서도 폭발적으로 늘었다. 양과 퀄리티가 상당히 좋아졌지만, 점점 더 장황해지고 비대해지면서 오히려 맥락을 파악하기 힘들어졌다.
코드도 그렇다. 손쉽게 코드를 작성할 수 있다 보니 하나의 병합 요청에 수많은 코드가 작성되고, 맥락을 파악하기 힘든 병합 요청은 자연스럽게 LGTM을 유발하게 된다. 누가 이 코드를 깊이 있게 이해했는가? 솔직히 모른다.
과거에는 코드를 직접 모두 작성했기 때문에 자연스럽게 깊은 이해가 생겼다. 지금은 “이게 뭐지?”라며 읽기 시작하고, 이해하고 나면 다음으로 넘어간다. 깊이 있는 몰입보다는 표면적인 검토에 그치기 쉽다.
아무튼 이제는 디테일을 고민하지 않아도 되니 깊게 몰입하면서 생기는 집중력이 점점 더 떨어지지 않나 싶다. 이게 장기적으로 어떤 영향을 미칠지, 솔직히 아직은 잘 모르겠다.
어쩌면 우리 모두 C레벨이 된 거 아닐까
어쩌면 우리는 모두가 관리자 역할을 수행하고 있는 건 아닐까. 제품을 잘 만들기 위한 방법을 고민하고, AI 도구가 좀 더 코딩을 잘 할 수 있도록 해서 효율적으로 제품을 만들어낼 수 있도록 하는 것.
이건 어떻게 보면 흥미롭고, 어떻게 보면 불안하다. 직접 코드를 작성하지 않으면 프로그래밍 언어에 대한 깊이 있는 이해를 유지할 수 있을까? 운전을 직접 하지 않는 운전강사처럼, 어쩌면 어색한 상황이 될 수도 있지 않을까.
물론 좋은 점도 있다. 기술 세부 사항에서 해방되어 더 큰 그림을 볼 수 있게 된다. 사업 가치, 사용자 경험, 아키텍처 의사결정 같은 고차원의 문제에 집중할 수 있다.
하지만 내가 생각하는 새로운 개발자 장인은, 평소엔 방향을 잡고 결과를 검증하면서도 필요한 순간엔 직접 코드의 가장 안쪽까지 따라 들어갈 수 있는 사람이다. 개발의 패러다임이 바뀌고 있지만, 새로운 관점에서 장인정신을 발휘하는 개발자들이 여전히 필요하다고 생각한다.
마무리
AI 코딩 도구가 처음 등장했을 때, 많은 사람들은 “개발자의 일자리가 없어질까?”라고 두려워했다. 지금 경험해보니 문제는 다른 곳에 있는 것 같다. 일자리가 없어지는 게 아니라, 하는 일의 성격이 완전히 바뀌고 있다는 것이다.
훈수를 두는 즐거움, 추상적 요구사항을 구현하는 경쾌함, 에이전트가 움직이는 것을 지켜보는 재미. 이런 것들이 AI 시대 개발의 매력이다. 동시에 생산성의 역설, 집중력의 감소, 역할의 재정의라는 도전도 함께 따라온다.
한 가지 분명한 건, AI에게 “구현해줘”라고 던지는 일이 점점 쉬워질수록, 던지기 전에 “내가 이걸 정말 이해하고 있나”라고 자문하는 시간은 점점 더 값비싸진다는 것이다.
새로운 장인은 거기서 갈린다고 생각한다.

AI와 함께 일한다는 것

댓글