코드를 쓰는 일은 병목이 아니었다: 진짜 어려운 건 이해와 협업

오랫동안 소프트웨어 엔지니어링에서 코드를 작성하는 일이 병목이라고 느껴본 적이 없었다고 글쓴이는 고백합니다. 실제로 개발 과정에서 시간을 가장 많이 잡아먹는 건 코드 작성이 아니라, 그 이후에 따라오는 여러 과정들이라는 거죠.

코드를 쓰는 것보다 더 많은 시간과 노력이 들어가는 일들은 다음과 같습니다.

이런 과정들은 품질을 높이기 위해 꼭 필요하지만, 오히려 코드 작성보다 더 많은 시간과 에너지를 요구합니다.
글쓴이는 이렇게 말합니다.

"이 모든 과정이, 코드 작성 그 자체보다 우리를 더 느리게 만든다. 왜냐하면 이 과정들은 생각, 공유된 이해, 그리고 올바른 판단을 필요로 하기 때문이다."

요즘은 Claude 같은 LLM 덕분에 코드를 훨씬 빠르게 만들 수 있게 됐습니다. 그래서 "이제야 코드 작성의 병목을 해결했다!"는 새로운 이야기가 나오고 있죠. 하지만 글쓴이는 이 주장에 동의하지 않습니다.

"새로운 소프트웨어를 추가하는 한계 비용은 거의 0에 가까워지고 있다. 하지만 그 코드를 이해하고, 테스트하고, 신뢰하는 데 드는 비용은? 그 어느 때보다 높아졌다."

즉, 코드를 만드는 건 쉬워졌지만, 그 코드를 제대로 이해하고 검증하는 일은 오히려 더 어려워졌다는 것입니다.

LLM이 코드를 빠르게 만들어주긴 하지만, 그 결과로 더 많은 코드가 시스템에 쏟아져 들어오고,
이를 검토하고 통합하고 유지보수하는 사람들에게 더 큰 부담이 생깁니다.

특히 이런 상황에서 문제가 두드러집니다.

결국, 코드를 만드는 건 쉬워졌지만, 검증하고 신뢰하는 건 더 복잡해진 셈입니다.
이런 현상은 예전부터 농담처럼 불리던 "복사-붙여넣기 엔지니어링"이
LLM 덕분에 훨씬 더 빠르고 대규모로 일어나고 있다는 점에서 심각해졌습니다.

글쓴이는 이렇게 강조합니다.

"코드의 가장 큰 비용은 그것을 이해하는 데 있다 — 쓰는 데 있는 게 아니다."

LLM이 코드를 만들어주는 속도는 빨라졌지만,
코드의 동작을 논리적으로 파악하고, 미묘한 버그를 찾고,
장기적으로 유지보수할 수 있을지 판단하는 데 드는 노력은 전혀 줄지 않았습니다.

오히려,

리뷰어와 팀원들이 더 큰 어려움을 겪게 됩니다.

소프트웨어 개발은 언제나 협업이 핵심입니다.
공유된 이해, 방향성의 일치, 멘토링이 필수적이죠.

하지만 LLM이 코드를 너무 빨리 만들어내면,
충분한 논의나 리뷰 없이 코드가 쌓이게 되고,
품질이 '보장'된다고 착각하는 위험이 생깁니다.

이런 상황은 리뷰어와 멘토에게 더 큰 부담을 주고,
겉으로는 빨라진 것 같아도 실제로는
더 느려지거나, 더 많은 문제가 쌓일 수 있습니다.

LLM 덕분에 프로토타입 만들기, 뼈대 코드 작성, 자동화는 정말 빨라졌습니다.
하지만, 명확한 사고, 꼼꼼한 리뷰, 신중한 설계의 중요성은 오히려 더 커졌습니다.

"코드를 쓰는 비용은 정말로 줄었다. 하지만,
그 코드를 팀이 함께 이해하는 비용은 줄지 않았다."

마지막으로 글쓴이는 이렇게 강조합니다.

"그게 여전히 병목이다. 그 사실을 외면하지 말자."

이 글은 코드를 빨리 쓰는 것이 개발의 전부가 아니며,
이해, 검증, 협업이야말로 진짜 어려운 일임을
친절하게, 그리고 현실적으로 짚어줍니다.
LLM 시대에도 기본에 충실한 개발 문화가
얼마나 중요한지 다시 한 번 생각하게 해주는 글이네요! 😊

함께 읽으면 좋은 글