Understanding Over Origin: The Missing Friction
A few days ago, I wrote "Understanding Over Origin" and it got alot of engagement and I'm really...
개요 #
며칠 전 Dev.to에 올라온 "Understanding Over Origin"은 코드의 출처가 품질을 결정하지 않는다고 주장했다. 반응이 컸고, 댓글창에서 긴 토론이 이어졌다. 그리고 필자 Adam은 후속 글을 썼다. 요지는 짧다. 앞선 글은 미완성이었다는 것.
빠진 조각은 마찰(friction)이다. Adam은 자신이 여전히 상당량의 코드를 직접 손으로 쓰고 있고, 그렇게 쓴 부분에 더 큰 자부심을 느낀다고 털어놨다. 게이트키핑도 아니고 향수도 아니다(약간의 향수는 인정했다). 원래 주장이 설명하지 못한 지점을 이제야 설명해 보겠다는 선언이다.
토론이 정리해 준 것들 #
Adam은 먼저 논지에 정면으로 부딪혀 준 사람들을 언급했다.
@unitbuilds는 이렇게 정리했다. "경쟁 상대를 두고 표준 벤치마크 스위트를 돌릴 수 있다면 증명 가능하고 재현 가능하다. 과학적 발견에 그 정도가 충분하다면 프로그래밍에도 충분하다." AI를 변호하는 말이 아니다. 더 나은 기준이 이미 존재하는데 굳이 무시할 이유가 없다는 뜻이다. 그리고 Adam이 놓친 지점도 짚었다. 정확성의 책임은 원래부터 PR에 승인 도장을 찍는 개발자에게 있었다는 것.
이 논쟁의 발단이 된 원글을 쓴 @madsendev도 돌아왔다. 논의가 "더 멀리 갔다"고 인정하면서 아이디어 하나를 던졌다. AI 보조 프로젝트에 자기 저장소를 스스로 퀴즈 내보는 표준이 있다면 어떨까. AI를 쓰지 않았음을 증명하려는 게 아니라, 자기가 만든 것을 실제로 이해하고 있음을 증명하기 위해서.
Adam이 토론에서 가장 마음에 들었다고 꼽은 문장은 @Komo의 것이다. "유지보수 기록은 위조하기가 훨씬 어렵다." 이 한 줄이 논쟁 전체의 틀을 바꿔놓는다. 테스트, 버그 수정, 프로덕션 장애 대응, 이슈 응답, 리팩터링. 하나하나가 누군가 프로젝트를 만들었을 뿐 아니라 계속 이해하고 개선하고 책임지고 있다는 증거를 남긴다. 면접에서 코드를 설명하거나 모든 줄을 직접 썼다고 주장하는 것보다 훨씬 위조하기 어려운 종류의 소유권이다.
가장 날카로웠던 반론 #
Photo by @darkwiiplayer는 이렇게 들어왔다. "동의 없이 훔친 코드로 AI를 학습시킨 건 절도다. AI로 만든 모든 것은 그 절도를 DNA에 품고 있다. 당신은 이 점을 간과하고 있다."
수사적 공격이 아니었다. 학습 데이터, 동의, 그리고 허락 없이 대규모로 이뤄지는 '학습'이 대체 무엇인지를 두고 던진 철학적 문제였다.
주장은 오갔다. Adam은 학습 데이터와 생성된 출력물이 자동으로 복제와 같아지지는 않는다고 반박했다. 상대는 학습 데이터에서 훔친 코드를 전부 제거하면 지금의 모델은 존재하지 않을 것이라고 되받았다. 아마 사실일 것이고, 그건 중요한 사실이다.
Adam은 이 반론이 엔지니어링 차원의 주장을 무너뜨린다고는 보지 않았다. 다만 대화에 두 층이 있다는 건 인정했다.
- 기술적 층위: 그 작업물은 유지보수되고 있고, 이해되고 있고, 좋은가?
- 윤리적 층위: 동의 없이 수집된 학습 데이터로 만들어졌을 수 있는 도구를 우리는 어떻게 받아들여야 하는가?
스레드의 대부분은 1번을 두고 다퉜고, @darkwiiplayer는 2번을 대화 안으로 끌고 들어왔다. 둘 다 실재하는 문제다. 어느 쪽도 다른 쪽을 무효화하지 않는다.
동시에 Adam은 원래 글이 답하지 못한 질문을 자각했다. 왜 손으로 쓴 코드가 자신에게 다르게 느껴지는가. 솔직히 다르게 느껴지니까.
세 갈래 중 어느 쪽인가 #
원래 주장은 이랬다. 출처는 품질을 결정하지 않는다. 이해, 테스트, 유지보수 가능성, 책임성이 결정한다.
Adam의 경험도 그 주장과 어긋나지 않는다. 2018년쯤 코드를 쓰기 시작했고, 그때만 해도 사람들이 이름을 댈 수 있는 AI라고는 홍콩에서 만든 휴머노이드 로봇 소피아 정도였다. 전부 직접 쓰는 전통적인 방식으로 배웠다. 지금도 손으로 코드를 쓸 때는 그 코드를 다르게, 더 깊이 이해한다. AI로 초안을 뽑았다면 넘겼을 엣지 케이스가 눈에 걸린다. 다 끝내고 나면 만든 결과물이 훨씬 자랑스럽다.
그런데 이 두 진술은 깊이 파고들면 양립하지 않는다. 가능한 답은 셋이다.
- 그 자부심은 그냥 자아(출처 편향)다
- 손으로 쓴 코드가 실제로 더 좋다(게이트키퍼들이 옳았다)
- 둘 다 사실이지만, 검토하지 않은 이유 때문이다
3번을 보게 해준 건 @fromzerotoship이다. 개발자가 아니지만 AI로 사내 도구 20개 이상을 만들어 돌리고 있고, 그중 일부는 병원이 쓴다. Adam의 기준으로는 '이해 테스트'에 낙제다. 시스템 어느 부분은 한 줄씩 설명하지 못한다.
그런데 그가 한 말이 판을 흔들었다. "의도적인 실패 상황에서 동작을 실증해 보이는 것도 신뢰를 얻는 한 방법이고, 나에게는 그것뿐이다. 그리고 이것도 위조하기 어렵다."
결함을 일부러 심고, 가드가 잡아내는지 지켜보고, 가드를 복구해 초록불로 돌아오는지 확인하고, 배포한 뒤 몇 초 후 URL을 눌러본다. 살아 있게 유지할 수 있다는 것을 증명하는 방식이다.
여기서 Adam은 진짜 구분선이 누가 타이핑했느냐가 아니라 마찰이라는 것을 깨달았다.
마찰이 학습 장치다 #
Adam은 몇 주 전에 쓴 다른 글에서, 어떤 로직을 완벽하게 리뷰할 수 있는데도 백지에서 다시 쓰지는 못했던 경험을 적었다. 단순한 기술 퇴화가 아니었다. 이해를 만들어 주는 마찰을 건너뛴 증거였다.
손으로 코드를 쓰면 문제를 실시간으로 만난다.
벽에 부딪힌다. 접근법이 안 통한다. 리팩터링한다. 제약과 실패를 거치며 문제 공간을 발견한다. 결정에 대한 결정을 한다. 타이핑이 아니라, 직접 걸어본 경로들 사이에서 선택하는 일이다.
AI를 쓸 때는 원하는 걸 설명한다. 선택지를 받는다. 맞아 보이는 걸 고른다. 탐색이 아니라 큐레이션이다.
둘 다 좋은 코드를 만들 수 있다. 하지만 이해에 도달하는 경로가 근본적으로 다르다.
- 손으로 쓸 때: 마찰 → 통찰 → 더 나은 다음 결정
- AI 보조: 선택 → 구현 → 검증
그러니까 손으로 쓴 코드가 더 자랑스럽다는 말은 고생을 낭만화하자는 얘기가 아니다. 가장 자랑스러운 코드는 싸워서 얻어낸 코드이고, 손으로 쓰는 방식은 그 싸움을 강제한다는 관찰이다.
그런데 이 논리에도 구멍이 있다 #
마찰이 장치라면, 중요한 건 누가 타이핑했느냐가 아니라 마찰의 종류다.
AI 보조로 코드를 쓰면서도 이렇게 할 수 있다.
- 프롬프트와 씨름한다
- 생성된 선택지를 전부 비판적으로 본다
- 과감하게 리팩터링한다
- 벽에 부딪히고 다시 설계한다
여기엔 마찰이 있고, 이해도 쌓인다.
반대로 손으로 쓰면서도 이럴 수 있다.
- 익숙한 패턴을 자동조종으로 통과한다
- 가정을 한 번도 의심하지 않는다
- Stack Overflow에서 복사해 붙인다
- 왜 작동하는지 끝까지 모른다
여기엔 마찰이 없고, 아무것도 쌓이지 않는다.
그래서 Adam이 정직하게 다시 쓴 입장은 "손으로 쓴 코드가 더 좋다"가 아니다. "마찰이 이해를 만들고, 손으로 쓰는 방식은 모든 줄을 생각하도록 강제하기 때문에 마찰을 만들어내는 경향이 있다." 절대적 진리가 아니라 조건부 진리다.
불편한 자각 #
Adam은 비판자들 — 이제부터 게이트키퍼라고 부르겠다고 했다 — 이 부분적으로 옳았고, 원래 자기 입장이 너무 관대했다고 인정했다.
게이트키핑 자체는 여전히 틀렸다. 그러나 경향성에 대해서는 맞았다. AI는 이해가 얕은 코드를 만들기 더 쉽게 해준다. AI가 나쁘기 때문이 아니라, AI가 하는 일이 곧 마찰을 걷어내는 일이고, 그 마찰이 바로 이해를 만들기 때문이다.
답은 "AI를 덜 쓰자"도 "절대 쓰지 말자"도 아니다. 코드든 실패 모드든 유지보수든, 문제와 씨름하는 과정을 건너뛰려고 AI를 쓴다면 더 나쁜 시스템을 만들게 된다는 것이다.
이건 사람에게도 적용된다. 다만 사람에게는 마찰 비용이 내장돼 있다. 지루해하고, 타이핑을 싫어하고, 실수한다. 짜증나는 마찰이지만, 그 덕에 계속 문제 안에 머물게 된다.
그래서 무엇이 달라졌나 #
원래 주장에 틀린 부분은 없었다. 다만 "이해 + 책임성"을 마지막에 확인하면 끝나는 체크박스처럼 다뤘다는 게 문제였다.
이해는 검사할 수 있는 속성이 아니다. 과정이다. 그리고 그 과정에는 마찰이 필요하다. 문제와의 진짜 씨름, 배움으로 이어지는 실수들.
손으로 쓴 코드가 더 자랑스러운 이유는 위조하기 어려운 방식으로 이해를 벌어들였기 때문이다.
그렇다면 모든 줄을 손으로 써야 하나? 아니다. 보일러플레이트는 보일러플레이트다. 어떤 마찰은 그냥 잡음이다.
하지만 핵심 로직, 아키텍처 결정, "이 코드를 이해한다"는 말이 실제로 중요해지는 지점이라면. 거기서는 싸운 흔적이 있기를 바란다는 것이다. 자신에게도, 중요한 코드를 배포하는 다른 누구에게도.
불편한 중간 지대 #
Adam이 도착한 지점은 이렇다.
게이트키퍼들에게: 필터가 잘못됐다. "AI냐 아니냐"는 아무것도 알려주지 않는다. 하지만 우려할 만한 실체가 있다는 점은 우연히 맞혔다. 도구 자체가 아니라, AI가 가능하게 하는 게으름이다.
AI 애호가들에게: 툴링이 훌륭한 건 맞다. 다만 그것으로 더 잘 생각하고 있는지, 덜 생각하고 있는지는 물어볼 만하다. 둘은 똑같이 느껴진다. 6개월 뒤 그 코드를 유지보수해 보기 전까지는.
스스로에게: 손으로 쓴 코드에 느끼는 자부심은 자아가 아니다. 정당한 감정이다. 직접 타이핑한 줄이 무슨 신화적 유니콘 같은 코드라서가 아니라, 거기 따라오는 마찰과 그 마찰이 만든 배움 때문이다.
건너뛰었음을 인정해야 하는 순간도 있다. 루틴한 작업이라면 괜찮다. 하지만 중요한 것을 만들고 있다면, 그것을 위해 싸웠기를 바라야 한다.
어디서 싸울지 고른다 #
Adam은 여전히 손으로 코드를 많이 쓴다. AI도 매일 쓴다. 이제 그 둘은 모순이 아니다.
원래 글은 맞았다. 출처가 품질을 결정하지 않는다. 놓친 건 이해가 마지막에 체크하는 항목이 아니라는 사실이다. 이해는 마찰을 통해 벌어들이는 것이다. 손으로 쓰면 마찰이 생기는 편이고, AI는 마찰을 없애는 편이다. 어느 쪽도 본질적으로 좋거나 나쁘지 않다. 둘 다 문제에 어떻게 관여할지에 대한 선택이다.
그래서 Adam은 더 이상 "AI 썼어요?"라고 묻지 않는다.
이렇게 묻는다. 중요한 부분을 위해 싸웠나요?
그리고 그 답을 도구가 대신 내줬다면, 다음에 뭔가 터질 때 알게 될 것이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.