코드를 쓰는 일은 병목이 아니었다: 진짜 어려운 건 이해와 협업
오랫동안 소프트웨어 engineering에서 코드를 작성하는 일이 병목이라고 느껴본 적이 없었다고 The author 고백. 실제로 개발 과정에서 시간을 가장 많이 잡아먹는 건 코드 작성이 아니라, 그 이후에 따라오는 여러 과정들이라는 거죠.
진짜 병목은 어디에 있을까? 🤔
코드를 쓰는 것보다 더 많은 시간과 노력이 들어가는 일들은 다음과 같습니다.
- 코드 리뷰: 다른 사람이 쓴 코드를 꼼꼼히 읽고, 문제나 개선점을 찾는 과정
- 지식 전달: mentoring이나 페어 programming을 통해 서로 배우고 가르치는 일
- test와 debugging: 코드가 제대로 동작하는지 확인하고, 버그를 잡는 과정
- 조율과 소통: 여러 사람이 함께 일할 때 필요한 communication과 협업
- 티켓 관리, 회의, 애자일 의식: 업무를 관리하고 계획하는 각종 절차들
Such 과정들은 품질을 높이기 위해 꼭 필요하지만, 오히려 코드 작성보다 더 많은 시간과 에너지를 요구.
The author 이렇게 말.
"이 모든 과정이, 코드 작성 그 자체보다 우리를 더 느리게 만든다. 왜냐하면 이 과정들은 생각, 공유된 이해, 그리고 올바른 판단을 필요로 하기 때문이다."
LLM(large language model)이 바꾼 풍경
요즘은 Claude 같은 LLM 덕분에 코드를 훨씬 빠르게 만들 수 있게 . 그래서 "이제야 코드 작성의 병목을 해결했다!"는 새로운 이야기가 나오고 있죠. 하지만 The author 이 주장에 동의하지 .
"새로운 소프트웨어를 추가하는 한계 비용은 거의 0에 가까워지고 있다. 하지만 그 코드를 이해하고, test하고, 신뢰하는 데 드는 비용은? 그 어느 때보다 높아졌다."
In other words, 코드를 만드는 건 쉬워졌지만, 그 코드를 제대로 이해하고 검증하는 일은 오히려 더 어려워졌다는 것.
LLM은 일의 무게만 옮길 뿐, 없애주진 않는다 ⚖️
LLM이 코드를 빠르게 만들어주긴 However, 그 결과로 더 많은 코드가 시스템에 쏟아져 들어오고,
이를 검토하고 통합하고 유지보수하는 사람들에게 더 큰 부담이 생깁니다.
특히 Such 상황에서 문제가 두드러집니다.
- 작성자가 자신이 제출한 코드를 완전히 이해하지 못한 경우
- 생성된 코드가 기존과 다른 낯선 패턴을 Introduction하거나, 팀의 규칙을 깨는 경우
- 예상치 못한 예외 상황이나 부작용이 명확하지 않은 경우
결국, 코드를 만드는 건 쉬워졌지만, 검증하고 신뢰하는 건 더 복잡해진 셈.
Such 현상은 예전부터 농담처럼 불리던 "복사-붙여넣기 engineering"이
LLM 덕분에 훨씬 더 빠르고 대규모로 일어나고 있다는 점에서 심각해졌습니다.
코드를 이해하는 게 진짜 어려운 일 🧠
The author 이렇게 강조.
"코드의 가장 큰 비용은 그것을 이해하는 데 있다 — 쓰는 데 있는 게 아니다."
LLM이 코드를 만들어주는 속도는 빨라졌지만,
코드의 동작을 논리적으로 파악하고, 미묘한 버그를 찾고,
장기적으로 유지보수할 수 있을지 판단하는 데 드는 노력은 전혀 줄지 않았습니다.
오히려,
- 생성된 코드와 사람이 직접 쓴 코드를 구분하기 어려워지고
- 왜 Such 해결책을 선택했는지 맥락을 파악하기 힘들어지면서
리뷰어와 팀원들이 더 큰 어려움을 겪게 .
팀워크와 신뢰, 그리고 맥락의 중요성 🤝
소프트웨어 개발은 언제나 협업이 핵심.
공유된 이해, 방향성의 일치, mentoring이 필수적이죠.
하지만 LLM이 코드를 너무 빨리 만들어내면,
충분한 논의나 리뷰 없이 코드가 쌓이게 되고,
품질이 '보장'된다고 착각하는 위험이 생깁니다.
Such 상황은 리뷰어와 멘토에게 더 큰 부담을 주고,
겉으로는 빨라진 것 같아도 실제로는
더 느려지거나, 더 많은 문제가 쌓일 수 .
LLM의 힘과 한계: 기본은 변하지 않는다 ⚡️
LLM 덕분에 prototype 만들기, 뼈대 코드 작성, automation는 정말 빨라졌습니다.
However, 명확한 사고, 꼼꼼한 리뷰, 신중한 설계의 중요성은 오히려 더 커졌습니다.
"코드를 쓰는 비용은 정말로 줄었다. However,
그 코드를 팀이 함께 이해하는 비용은 줄지 않았다."
Finally, The author 이렇게 강조.
"그게 여전히 병목이다. 그 사실을 외면하지 말자."
Summary Keywords ✨
- 코드 작성의 병목은 환상
- 진짜 병목: 코드 리뷰, 지식 전달, test, debugging, 협업
- LLM은 코드 생산을 가속However, 검증과 이해의 부담을 키움
- 코드 이해와 팀워크의 중요성은 변하지 않음
- 기본에 충실해야 진짜 품질이 보장됨
This article 코드를 빨리 쓰는 것이 개발의 전부가 아니며,
이해, 검증, 협업이야말로 진짜 어려운 일임을
친절하게, 그리고 현실적으로 짚어줍니다.
LLM 시대에도 기본에 충실한 개발 문화가
얼마나 중요한지 다시 한 번 생각하게 해주는 글이네요! 😊