AI로 코딩하다 보면 배우는 것 없이 끝나는 작업 방식 때문에 답답할 때가 있음. 목표를 아주 명확히 설명하고 원하는 결과가 나올 때까지 AI를 닦달하는 게 가장 효과적일 때도 있지만, 에너지는 많이 들면서 직접 코딩할 때처럼 유용한 기술이나 더 나은 방법을 익히지는 못함. 거대 AI 기업에 학습 데이터를 더 만들어줄 뿐이고, 그 대가가 돌아오는 주기는 느림.
이게 맞는 해결책인지는 모르겠지만, 무모할 정도로 효율을 추구하면서도 더 배우고 이해하고 성장하고 싶음.
예전처럼 직접 코딩해보면 어떨까? 효율은 떨어질지 몰라도 무엇을 했는지 이해하고 경험을 쌓을 수 있음.
사고를 예방하는 대신 절벽 아래에 구급차를 대기시킨다는 비유를 들어본 적 있는지?
내가 배포하는 코드에 대한 이해도가 떨어지는 걸 느끼고, PR이나 현재 브랜치에 관해 퀴즈를 내주는 스킬을 만들어 사용하기 시작함. 특정 커밋에 연결하지는 않았는데, 내게는 PR 전체를 살펴보는 편이 더 타당해 보임.
지금까지는 생각보다 좋은 질문을 만들어줘서 놀랐음.
나도 이걸 만들었지만 곧바로 짜증이 나서 사용을 중단함. 마법처럼 알아서 일해주길 기대하는 상대에게 질문받는 건 싫은 모양임.
동기는 이해할 만함. 저질 코드인지 천재적인 코드인지도 모르는 채 잔뜩 올리고 나면, 불과 몇 달 전 코드를 어느 정도 이해하던 시절처럼 좀 더 제대로 알아야 한다는 찜찜함이 남기 마련임. 하지만 이게 효과가 있을지는 의문임. 반복 확인에 따른 피로감을 잊었는지? 머지않아 우리 대신 Sphinx를 상대하는 에이전트가 생길 것 같음.
내가 만든 오픈소스 앱은 PR을 시각적으로 요약하고 관련 퀴즈를 내주는데, 여기에 비슷한 장치를 넣을까 고민했음. 결국 강제 통과 조건보다는 AI가 만든 PR을 이해하려는 사람을 위한 선택 기능으로 남기는 편이 낫다고 판단함. 이제는 물량이 점점 늘어 그것조차 감당하기 어려워지고 있음. 나도 필요성을 느꼈던 만큼 취지에는 공감함.
부정적인 댓글들이 모두 “저질 결과물은 나쁘다”는 이유로 일축하는 건 아이러니함. 저질 코드, 부주의, 이해 부족은 언제나 나빴음. Stack Overflow 코드를 복사하거나 내장 메서드와 표준 라이브러리를 잘못 쓰고, 예외 상황을 빠뜨리며, 시스템이 망가지고서야 요청 빈도 제한이나 안정성 강화를 챙기고, 코드 중복을 방치하는 일은 예전에도 있었음.
이제는 해결책을 구석진 코딩 도구나 마크다운 파일, 에이전트 실행 환경에 숨겨두는 데 그치지 않고, 개발자가 이해 부족에서 벗어나도록 돕는 검증 관문을 만들고 있음. 개발자 수가 약 3년마다 두 배가 되니, 어느 시점이든 절반은 경력 3년 미만이고 대부분 일을 시작하기 전에 컴퓨터과학을 공부하지도 않았음. 이런 도구는 5~10년 전 우리에게 이해하지 못한 코드는 복사하지 말라고 당부하던 목소리를 대신하게 될 테니 반가운 일임.
AI 소프트웨어 개발의 첫 번째 문제는 아키텍처 설계 없는 코드를 만든다는 것임. 두 번째 문제는 그보다도 못하는 사람이 많다는 것임.
오픈소스 유지보수 담당자에게는 아주 유용할 것 같음.
코드를 일일이 간섭하던 데서 도구와 마크다운을 일일이 간섭하는 것으로 옮겨왔음.
이 문제를 해결하려는 시도가 반가움! 나도 비슷한 프로젝트를 만들었는데, 내 쪽은 PR 단위로 병합을 막는 방식임. 언젠가 연락해서 이야기해보고 싶음. https://github.com/bhurghundii/vibecheck.dev
덧붙이자면, 가치를 의심하는 사람이 많지만 실제로 티켓을 그대로 AI에 던지고, 작업 내용을 이해하지도 않은 채 대량의 AI 코드를 배포하는 팀이 있음. 문화 변화가 정답이지만 매우 어렵고, 이 방식은 적어도 속도를 늦추면서 빠르게 도입할 수 있음.