TL;DR

  • AI 코딩 도구는 버그 수정과 기능 구현을 빠르게 하지만, 개발자가 문제를 이해하고 직접 코드를 만들어 가며 얻던 경험과 만족감을 줄임.
  • 코드 읽기, 변수명 선택, 함수 구성, 정규식 조정 같은 느리고 세밀한 작업이 줄면서 코드를 직접 다루는 감각도 옅어짐.
  • 모델이 혼란을 겪고 해결책을 찾는 중간 단계를 건너뛰게 해 당장의 해결은 빨라지지만, 비슷한 문제를 알아차리는 학습 기회도 줄어듦.
  • 생산성 향상과 저렴해진 실험은 더 많은 프로젝트를 가능하게 하고, 아키텍처·사용자·개발하지 않을 대상을 고민하는 데 더 많은 여지를 줌.
  • 도구의 속도와 실제 이해 사이에서 사용 시점을 조절하는 것이 코딩의 장인정신과 생산성 향상을 함께 지키는 과제임.

코드를 직접 고치는 감각의 변화

  • 지난주 사이드 프로젝트의 백그라운드 작업에서 발생한 작은 경쟁 상태를 수정할 때, 모델에 문제를 설명하고 수정안을 적용한 뒤 테스트를 통과시키는 데 12분이 걸림.
  • 예전 같으면 코드를 읽고 수정하고 테스트를 반복하며 저녁 시간을 보냈을 일이지만, 이번에는 직접 문제를 해결했다는 느낌이나 자부심, 짜증 없이 그저 끝났다는 감각만 남음.
  • 문제 발생과 해결 사이의 간격은 개발자로서 경험이 쌓이는 주요 공간이었음. 답을 찾기까지 문제를 오래 생각한 끝에 코드를 원하는 대로 움직이게 했다는 만족감도 그 과정에서 나옴.
  • 그 경험의 결이 상당 부분 옅어지고 있음.

사라지는 느리고 세밀한 작업

  • 먼저 사라진 것은 몇 달 전 직접 쓴 코드를 읽으며 당시의 결정을 떠올리는 길고 복잡한 시간임. AI는 그런 맥락을 되짚지 않고 파일을 살펴 곧바로 구조를 바꾸는 세 가지 방법을 제안함.
  • 이는 유용하지만, 자신의 작업을 다시 익히고 그 과정에서 작은 개선점을 발견하던 느린 아침도 줄어듦.
  • 변수명을 고르고, 나중에 읽을 때 논리가 자연스럽도록 함수를 나누고, 실제로 도움이 되는 곳에만 주석을 다는 일도 예전에는 즐기던 세밀한 작업임.
  • 리팩터링을 요청하면 깔끔한 결과를 얻을 수 있어 이런 작업이 덜 필요하게 느껴짐. 결과 코드는 대체로 괜찮고 피곤한 목요일에 직접 썼을 코드보다 나을 때도 있지만, 내 코드라는 느낌보다는 승인한 결과물에 가까움.
  • 연산 순서를 바꿔 스크립트를 조금 빠르게 만들거나, 한 줄짜리 정규식을 20분 동안 다듬거나, 로직이 다른 곳에 있어야 한다는 점을 깨닫고 파일 하나를 통째로 지우는 작고 특이한 즐거움도 줄어듦.
  • 이제 그런 순간은 일부러 속도를 늦추고 제안을 무시할 때 찾아옴. 하지만 그런 선택을 해야 할 만큼 자주 하지는 않음.

해결 과정에서 사라지는 학습

  • 예전에는 “고장 났다”에서 “무슨 일인지 이해한 것 같다”를 거쳐 “고쳤다”에 이르는 진행 경로가 보였음. 학습의 대부분은 가운데 단계에서 일어남.
  • 이제 모델은 혼란을 느낄 시간도 주기 전에 답을 건네는 경우가 많음. 먼저 혼란을 겪고 해결책을 얻는 과정 없이 해결만 얻게 되며, 비슷한 문제를 다음에 알아차리는 능력을 키울 기회도 건너뜀.
  • 요즘 실제 업무는 검토와 방향 설정이라는 말은 맞지만, 모델이 쓴 코드를 검토하는 일은 직접 작성할 때의 조용한 만족감과 다름. 해결책을 만드는 대신 문제를 찾아내는 중요한 작업이지만, 개인적인 보람은 더 적음.

큰 프로젝트와 코드 장인정신

  • 기능을 완성하고도 직접 만들었다기보다 조율했다는 막연한 감각이 남을 때가 많음. 구현의 형태를 설명하고 제안을 받아들이거나 거절했지만, 실제 구성은 다른 곳에서 이뤄짐.
  • 작업이 너무 빨리 진행돼 기능의 구석구석에 대한 머릿속 지도가 쌓이지 않음. 2주 뒤 문제가 생기면 자기 코드를 남의 코드처럼 다시 읽어야 함.
  • 다른 사람이 보지 않더라도 코드의 모양을 신경 쓰는 장인정신도 약해짐. 도구가 다음 30줄을 기꺼이 생성하는 상황에서는 전체 작업을 임시적인 것으로 다루기 쉬워짐.
  • 나중에 정리를 요청할 수 있다는 생각에 코드를 아름답게 만들 이유가 줄고, 코드는 의도적으로 더 일회용이 됨.
  • 도구의 목적은 아니었겠지만, 속도와 품질을 내세운 도구는 소프트웨어를 작성하는 사적이고 내적인 경험을 압축함. 그 경험의 가장 좋은 부분 중 일부는 결코 빠른 과정이 아니었음.

생산성 향상과 새로운 가능성

  • 그렇다고 도구가 나쁘다거나 모든 일을 손으로 해야 한다는 뜻은 아님. 생산성 향상은 실질적이고 상당함.
  • 보일러플레이트와 맥락 전환으로 씨름하던 하루짜리 작업이 한 시간으로 줄어듦. 구현 비용이 내려가면서 팀은 1년 전이라면 우선순위를 낮췄을 기능도 출시함.
  • 배우는 중인 사람은 아직 외우지 못한 문법 때문에 며칠씩 막히는 대신 더 빨리 다음 단계로 넘어감. 지루하고 반복적인 작업은 분 단위로 처리됨.
  • 더 큰 변화는 가능해지는 일의 범위임. 이제 1인 개발자도 작은 팀이 있어야 첫 프로토타입을 만들 수 있었을 아이디어를 탐색할 수 있음.
  • 실험 비용과 실패 비용이 낮아져 어려운 문제에 한 가지 접근법을 고르고 결과를 바라는 대신, 같은 오후에 세 가지 접근법을 시험할 수 있음. 그 결과 시도할 가치가 있다고 느끼는 프로젝트의 범위가 달라짐.
  • 기계적인 작업 시간이 줄면 아키텍처 결정, 사용자에 대한 고민, 애초에 만들지 말아야 할 것을 판단하는 데 실제로 더 많은 여지가 생김.
  • 이런 도구는 이미 안목과 경험을 갖춘 사람에게 더 많은 기회를 주는 동시에, 아직 그 역량을 쌓는 사람들의 진입 장벽도 낮춤.

속도와 이해 사이의 균형

  • 속도는 가치가 있지만, 출시하는 내용을 실제로 이해하는 느린 과정도 중요함.
  • 도구를 잘 사용하는 방법은 언제 도구가 앞서 나가게 할지, 언제 속도를 늦추고 직접 문제 안에 머물지를 의식적으로 선택하는 데 있음.
  • 그 균형을 찾는 개발자는 실질적인 생산성 향상을 얻으면서도 코딩의 장인정신을 계속 살릴 수 있음.