GitHub 블로그 공부 정리 | 코드 작성 비용이 싸진다는 게 무슨 말인지

GitHub 블로그에서 “The cost of saying yes has changed”라는 글을 읽었다. 제목만 봤을 땐 의사결정에 관한 추상적인 이야기인가 싶었는데, 읽어보니 AI 시대에 개발 비용 구조 자체가 어떻게 달라지고 있는지에 대한 글이었다. 디자이너에서 프론트엔드를 배우는 입장에서 생각할 거리가 꽤 있었다.

핵심 주장은 이렇다. AI 덕분에 코드를 작성하는 비용은 급격히 낮아졌지만, 그 코드를 소유하고 유지보수하는 비용은 그대로라는 것. 이 간극이 점점 벌어질수록 “이걸 만들 수 있느냐”보다 “이걸 누가 책임질 거냐”가 더 중요한 질문이 된다고 본다.

1️⃣ 이게 뭐냐?

글에서 든 예시가 꽤 구체적이었다. 팀이 “설정 페이지에 last_active_at 타임스탬프를 보여주자”는 요청을 받았다. 예전이라면 스코프인지 아닌지 한참 토론하다가 “한두 시간 걸릴 것 같다”는 말로 끝났을 수 있다.

AI 도구가 있는 지금은 다르다. 30분 안에 패치를 만들어서 그 diff를 보고 판단한다. diff가 4줄이면 간단한 기능이라 바로 배포하고, 40줄이라면 요청이 단순해 보여도 구조적으로 복잡하다는 신호니까 그 기능이 실제로 필요한지부터 다시 생각해볼 수 있다.

👉🏻 “이걸 만들 수 있느냐”가 아니라 “누가 이걸 이해하고 리뷰할 수 있느냐”로 판단 기준이 이동했다는 게 핵심이다.

이에 따라 AI에게 주는 제약 조건도 명시적으로 설정해야 한다고 본다. “가장 작은 패치를 만들어라”, “기존 기능 플래그 뒤에 두어라”, “공개 계약을 바꾸지 말아라” 같은 것들. 이 제약이 AI에게 주는 지시이면서 팀 내 의사결정 기준이 되는 구조다.

2️⃣ 내가 든 생각

디자이너 입장에서 읽다 보니 자꾸 걸리는 지점이 있었다. 스펙의 명확성이 결국 소유권 문제랑 직결된다는 부분이다.

UI 컴포넌트 작업을 할 때 “어디까지 이 컴포넌트가 담당해야 하나”를 고민하는 것과 구조가 비슷하다는 생각이 들었다. 경계가 명확하지 않으면 나중에 유지보수하는 사람이 고생하는 건 코드나 디자인이나 마찬가지인 것 같다.

💡 여기서 드는 질문? 코드 작성 비용이 싸지면 “일단 만들고 나중에 갈아엎자”는 판단을 더 쉽게 하게 될까? 아니면 소유 비용이 그대로이기 때문에 오히려 더 신중해질까?

이 질문이 흥미로웠던 이유는, AI 도구를 쓸 때 “빠르니까 일단 만들고 보자”는 방향으로 가기 쉬운데, 글에서는 그게 오히려 소유하기 어려운 코드를 빠르게 쌓는 경로가 될 수 있다고 보기 때문이다. 속도가 올라갈수록 “이걸 누가 소유할 건지”를 더 빨리 물어야 한다는 논리가 됐다.

⭐️ 마지막으로, 개발 도구를 공부하며 느낀 점

글을 읽고 나서 든 생각은, 이게 AI 도구 효율에 관한 이야기라기보다 팀 안에서의 판단 구조에 관한 이야기에 가깝다는 거였다. AI가 코드를 빠르게 만들어준다는 사실 자체보다, 그 결과물을 보고 “이걸 팀에서 책임질 수 있는가”를 빠르게 판단하는 능력이 더 중요해졌다는 이야기인 것 같다.

공부 끝에 남은 건 “만드는 속도보다 판단하는 속도”라는 한 줄이다.

---

참고 원문: The cost of saying yes has changed