AI가 코드를 완성해도 왜 ‘내가 만들었다’라는 감각은 약할까요

AI가 코드를 완성해도 왜 ‘내가 만들었다’라는 감각은 약할까요

AI 코딩과 창작의 경계 썸네일

AI 코딩 도구로 미뤄 둔 프로젝트를 끝내는 일은 빨라졌어요. 그런데 결과가 제대로 작동해도 직접 만든 것처럼 느껴지지 않는다는 개발자도 있어요. Beej Jorgensen은 20년간 소프트웨어 업계에서 일하고 현재 컴퓨터과학을 가르치는 자신의 경험을 통해, 결과물을 얻는 일과 제작 과정에 참여하는 일이 주는 만족은 다를 수 있다고 말해요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
제작 경험	요청해서 얻은 결과와 직접 만든 결과는 성취감이 다를 수 있어요	개발 속도만으로 설명하기 어려운 AI 코딩 경험을 짚어요
실제 사례	177줄짜리 플래시 카드 코드를 손으로 쓰는 데 약 50배 더 걸렸어요	작은 작업도 과정에 직접 참여하면 애착이 커질 수 있어요
도구의 경계	컴파일러는 입력을 정밀하게 변환하지만 AI는 빈 부분을 판단해 채워요	개발자가 결과의 원인을 이해하고 책임지는 범위가 달라져요
활용 기준	반복 작업과 학습, 취미 제작은 같은 기준으로 나눌 필요가 없어요	프로젝트의 목적에 따라 AI에 맡길 범위를 조정할 수 있어요

1. 완성 속도보다 제작 과정이 남기는 감각

Jorgensen은 소설 장면과 그림, Rust 게임 코드를 제시한 뒤 대부분을 AI가 생성했다고 밝혀요. 현관 데크도 숙련공이 시공했어요. 자신이 시작했고 요구사항을 정했지만, 실제 작업을 맡지 않은 결과물에 “내가 만들었다”라고 이름 붙이기는 불편했다고 해요. 관리자가 팀의 제품을 혼자 만들었다고 말하지 않는 것과 비슷한 감각이에요. 2

이 불편함은 AI 사용 자체를 부정하는 주장과는 거리가 있어요. 자연어로 원하는 결과를 정확히 설명하고, 나온 결과를 판단하며, 잘못된 방향을 고치는 일에도 기술이 필요해요. 다만 그 기술은 코드를 한 줄씩 작성하는 능력과 다른 종류예요. 작업을 조율하는 경험과 직접 구현하는 경험이 서로 다른 만족을 줄 수 있다는 이야기예요.

728x90

177줄을 직접 쓰는 데 50배가 걸렸어요

아내가 스페인어 단어를 스프레드시트에 넣으면 플래시 카드로 보여 주는 작은 시스템을 부탁했어요. Jorgensen은 Google Sheets의 CSV 접근 방법만 도움받고 구현 코드는 직접 작성했어요. JavaScript 112줄, CSS 33줄, HTML 32줄로 모두 177줄이었어요. AI에 맡겼을 때보다 약 50배 오래 걸렸지만, 자신이 작성했다고 말할 수 있는 코드에 훨씬 큰 자부심을 느꼈어요. 2

177줄이라는 규모나 50배라는 시간 차이는 보편적인 생산성 측정값이 아니에요. 한 개발자의 체감과 사례예요. 그래도 이 사례는 사이드 프로젝트의 목표가 언제나 빠른 출시만은 아니라는 점을 잘 보여줘요. 새로운 기술을 익히거나 손으로 문제를 풀고 싶다면, 느린 과정 자체가 프로젝트의 목적일 수 있어요.

컴파일러와 생성형 AI는 판단을 맡는 범위가 달라요

C나 Rust 코드를 쓰는 개발자는 기계어를 직접 작성하지 않아도 프로그램을 만들었다고 느껴요. 컴파일러와 어셈블러가 변환을 대신하기 때문이에요. Jorgensen은 이 변환이 입력과 출력 사이의 관계를 비교적 정밀하게 추적할 수 있다는 점에 주목해요. 프로그램이 잘못 동작하면 소스 코드와 빌드 과정에서 원인을 좁힐 수 있어요.

생성형 AI는 자연어 지시에서 빠진 세부 사항을 스스로 채워요. 같은 요청에도 다른 구현을 내놓을 수 있고, 요청하지 않은 구조나 동작을 더하기도 해요. 개발자는 방향을 정했더라도 함수 구성과 예외 처리, 라이브러리 선택 같은 여러 판단을 직접 하지 않았을 수 있어요. 결과를 소유하는 감각이 약해지는 이유를 “얼마나 많이 타이핑했는가”보다 “중간 판단을 누가 했는가”에서 찾을 수 있어요.

이 경계는 선명하지 않아요. 직접 쓴 C 코드를 AI가 어셈블리로 바꿔 준다면 컴파일러를 사용한 경험과 비슷할 수 있어요. 반대로 기능 설명만 주고 전체 프로그램을 받은 경우에는 다른 제작자에게 맡긴 감각이 커질 수 있어요. 도구 이름보다 개발자가 설계와 구현의 세부 결정을 얼마나 이해하고 통제했는지가 더 실용적인 기준이에요.

프로젝트 목적에 따라 맡길 범위를 바꿀 수 있어요

업무에서는 납기, 유지보수 비용, 보안, 정확도가 중요해요. 반복 코드를 줄이고 테스트 초안을 만드는 데 AI를 쓰면 개발자가 더 중요한 검토에 시간을 쓸 수 있어요. 이때는 모든 코드를 손으로 썼다는 만족보다 팀이 결과를 이해하고 책임질 수 있는지가 우선이에요.

학습이나 취미 프로젝트는 기준이 달라질 수 있어요. 알고리즘을 익히고 싶다면 핵심 로직은 직접 작성하고, 문서 검색이나 막힌 개념 설명만 도움받는 방식이 맞을 수 있어요. 아이디어를 빨리 확인하려는 실험이라면 UI 틀과 반복 구현을 더 많이 맡길 수 있어요. 한 프로젝트 안에서도 배우고 싶은 부분, 책임져야 하는 부분, 빨리 넘겨도 되는 부분을 구분하면 속도와 제작 경험을 함께 챙길 수 있어요.

왜 중요한가요

AI 코딩 도구를 평가할 때 생성 속도와 완료한 작업 수만 보면 개발자가 결과를 얼마나 이해하는지 놓치기 쉬워요. 직접 구현한 과정은 디버깅할 때 떠올릴 수 있는 맥락을 남겨요. 어떤 선택을 왜 했는지 기억하면 장애 원인을 좁히고 다음 변경의 위험도 판단하기 쉬워져요. AI가 만든 코드를 쓰더라도 설계 근거와 테스트, 중요한 결정은 개발자가 확인해야 하는 이유예요. 2

개발팀은 AI 사용량보다 책임 경계를 먼저 정할 필요가 있어요. 핵심 로직의 설계자, 생성된 코드의 검토자, 테스트 기준을 승인한 사람을 명확히 두면 속도를 얻으면서도 품질 책임이 흐려지는 일을 줄일 수 있어요. 개인 프로젝트에서는 더 단순해요. 완성이 목표인지, 배우고 만드는 과정이 목표인지 먼저 고르면 어디까지 맡길지도 자연스럽게 정할 수 있어요. 1

참고 자료

1. 만든다는 것 — GeekNews
2. On Making — Beej's Bit Bucket