바이브 코딩 패러독스

Source: Dev.to

AI as Co‑Developer in Owned Systems

내가 Nudges에 마지막으로 보낸 PR은 +96 −312였고, 38개의 파일을 건드렸으며, 약 90 %가 vibe‑coded였다. 나는 그것에 자신 있다.

하이룰을 누비고 있을 때, 두 개의 서로 다른 AI 에이전트가 조용히 Kafka 컨슈머를 리팩터링하고, 페이로드 형태를 검증하고, 변경 사항을 커밋하고 있었다—깨끗하고, 범위가 명확하며, 프로덕션에 바로 투입 가능한 상태였다. 그리고 여기서 중요한 점은: 기분이 좋다는 것이다.

그 시스템 안에서는 AI가 단순히 추측하는 것이 아니라, 내가 의도적으로 만든 시스템 안에서 작업하고 있기 때문이다.

그와 같은 경험—AI가 공동 개발자로서 마찰 없이 빠르게 작업하는 모습—은 내 계약 작업에서는 전혀 다른 느낌이다. 그곳에서는 내가 시스템을 소유하지 않는다. 시스템을 신뢰조차 할 수 없다. 그래도 코드는 여전히 AI가 만든다. 최고의 코드다. 그리고 이것이—무엇보다도—새로운 시대의 역설이다: AI가 마찰을 없애버린다.

시작은 존재해서는 안 될 티켓 중 하나에서였다. 한 클라이언트가 UI가 특정 상태에 있을 때 경고를 표시하도록 원했는데—그 규칙은 다른 수십 개와 겹쳤다. 상황은 엉망이었다: 일관성 없는 네이밍 규칙과 “다음 릴리즈에 처리하자”는 기술 부채가 수년간 쌓인 논리적 꼬임.

React 컴포넌트를 열어보니 1,100 줄에 달했고, 대부분이 조건문이었다. 테스트 커버리지는 없고, 문서도 없으며, 오직 분위기와 중첩된 삼항 연산자뿐이었다. Copilot을 열고 Win+H를 눌러 대화를 시작했다. 내가 달성하려는 목표, 왜 중요한지, 어디서 컨텍스트를 찾을 수 있는지를 설명했다.

그런 다음 나는 몸을 뒤로 기대고 눈을 비볐다. AI 에이전트가 나머지를 작성했다—새로운 변수와 체크가 하나씩 추가됐고, 각각은 메모이제이션되고, 방어적이며, 전체를 리팩터링하지 않고도 진행할 수 있을 만큼의 의미만을 담고 있었다.

그리고 여기서 매력적인 점은: 그것이 내가 직접 썼을 것보다 더 정밀했다는 것이다. 그래서 나는 그대로 받아들여 검증했고, 작동했다. 하지만 나는 깊은 곳에서 알았다—그 파일에 원래 300줄 정도였어야 할 부분에 또 30줄을 더 추가했다는 것을. 나는 나쁜 패턴을 지속하고 있었다.

The Contract Work Paradox

핵심은? 나는 PR을 제출했다. 직접 추출하고 스스로 작성할 수도 있었지만, 그 경우 엉망을 이해하는 데 두 시간이 걸렸을 것이다. 지금은 그게 수학이다.

몇몇 계약에서는 매주 수십 번씩 이런 선택을 한다:

• “올바른” 방법: 추출, 문서화, 테스트 — ≈ 2 시간.
• “충분히 좋은” 방법: 네이밍을 깔끔하게 유지하고, 동작하게 만들고, 배포 — ≈ 5 분.

이를 주당 수많은 결정에 곱하면, 그 형태가 보이기 시작한다.

나는 AI 때문에 코드를 쓰지 못해서가 아니라, 게으르거나 무관심해서가 아니라, 내 에너지를 가장 효율적으로 사용할 수 있는 곳을 배웠기 때문이다. 그리고 여기서 게임이 바뀌었다: “충분히 좋은” 일을 하는 것이 매우 쉬워졌다. AI는 깔끔한 이름, 스마트한 가드, 재사용 가능한 패턴을 제공한다. 위험은—그것이 눈에 띄지 않게 삼차 검사를 하게 만든다.

“컴퓨터는 증폭기다.” – 리처드 캠벨

패턴이 깔끔하면 명료성이 확장된다. 하지만 모든 것을 복제하기도 한다:

• 서비스가 되어야 할 인라인 함수.
• 삭제돼야 할 컴포넌트의 방어적 props.
• 나중에 고치려던 패턴이 이제는 모든 새로운 줄에 녹아들어 있다.

그리고 저항 없이—레드 플래그도, 오타도 없이—그렇게 된다. 예전엔 시스템을 몸소 느끼고, 몸부림쳤지만, 이제는 도구가 아니라는 차이가 있다.

Owning the System vs. Not Owning It

Nudges에서는 내가 시스템을 소유한다. AI가 뭔가를 추가하면 즉시 확인한다: 이게 여기 맞는가? 내가 만들고자 했던 시스템의 목표와 일치하는가? 맞지 않으면 멈추고, 고치고, 다시 정렬한다. 왜냐하면 시스템이 버티길 원하기 때문이다. 이 맥락에서 AI는 내 기준을 손상시키지 않는 배려의 증폭기다—그 기준은 처음부터 설계에 녹아 있었다.

계약 작업에서는 시스템을 소유하지 않는다. 질문은 다음과 같다:

• “이게 최선의 관행인가?”
• “이게 동작할까? 배포될까? 다음 머지에서도 살아남을까?”

왜냐면 그게 바로 일이다.

Conclusion

보상은 어느 쪽이든 동일하다. 기술, 나이, 속도와는 무관하다. 중요한 것은 내가 언제 무엇을 선택하느냐이다. 나는 Nudges의 PR을 머지했다—AI 에이전트가 내가 비디오 게임을 하는 동안 작성한 PR이다. 아름다웠다. 옳았다. 하지만 그것이 옳았던 이유는 내가 2년 동안 그 옳음의 제약을 만들었기 때문이다.

내일은 또 다른 클라이언트 티켓을 잡을 것이다. 2018년식 냄새가 나는 파일을 열고, 후회하고, 아마도 AI에게 소스에서 고쳐야 할 구멍을 패치하도록 요청할 것이다. 그 코드는 보기 흉할 것이고, “충분히 좋을” 것이며, 시스템이 받아 마땅한 바로 그 모습일 것이다.

코드가 스스로 작성된다면, 우리의 손은 키보드에서 떨어져 있지만, 지문은 어디에든 남아 있다.