복붙은 빠르지만 실력은 늘지 않는다: '이해'가 개발자에게 주는 진짜 힘
한눈에 보는 핵심
- 깊은 이해는 통제력의 조건이다. 이해하지 못하는 코드는 고치거나 바꾸기 어렵고, 결국 내가 책임지는 시스템에 대한 소유권을 잃게 됩니다.
- LLM과 검색은 강력하지만 '먼저' 기본기가 있어야 증폭기가 된다. 설명하지 못하는 해법을 복사하는 습관은 핵심 역량을 조용히 갉아먹습니다.
- 상황에 따라 기준을 달리하자. 일회성 스크립트는 복붙해도 괜찮지만, 몇 년을 유지할 코드는 깊이 아는 기술로 만들어야 합니다.
- 생산성은 output이 아니라 outcome으로 재야 한다. 코드 줄 수나 PR 개수보다, 안정적인 릴리스와 단순화가 장기 가치에 더 가깝습니다.
- 복잡해 보이는 현대 소프트웨어도 기초 원리를 익히면 새 도구를 훨씬 빨리 흡수할 수 있다.
레오나르도 다 빈치는 "가장 고귀한 즐거움은 이해의 기쁨"이라고 말했습니다. 개발에서 이해는 단순한 만족감을 넘어, 실제로 시스템을 다룰 수 있는 힘으로 이어집니다.
이해가 주는 통제와 즐거움
무언가를 고치고 바꾸려면 먼저 그것을 이해해야 합니다. 너무 당연한 말 같지만, 실제 현장에서는 자주 잊히는 원칙이죠.
이해하지 못하는 대상은 손대기 두렵습니다. 손대기 두려운 코드는 점점 더 방치되고, 결국 내가 "책임진다"고 말하는 코드에 대한 통제권을 잃게 됩니다. 반대로 깊이 이해하면 도구의 주인이 되고, 환경을 더 잘 통제하게 됩니다. 그리고 통제감은 그 자체로 긍정적인 감정과 연결되는 자연스러운 즐거움입니다.
인간의 게으름과 LLM 의존
인간은 본능적으로 에너지를 아끼고 투자 대비 보상을 키우려 합니다. 이 "게으름"은 지루한 작업을 자동화하는 좋은 동기가 되지만, 학습과 숙련에서는 약점이 됩니다.
예를 들어 SQL을 직접 배우는 대신, 테이블 구조와 원하는 데이터를 LLM에 알려주고 결과만 복사하면 당장은 편합니다. 하지만 그렇게 해서는 SQL을 제대로 다루는 능력이 쌓이지 않습니다. 과거에 직접 반복하며 길렀던 읽기·이해 능력도 쓰지 않으면 줄어들죠.
LLM과 검색 엔진은 최선의 경우 역량 증폭기(force multiplier) 이지만, 그 효과를 누리려면 먼저 강한 기본기가 있어야 합니다.
그래서 정기적으로 게으른 본능에 맞설 필요가 있습니다. 문서와 소스를 읽고, 해법의 이유와 도구의 트레이드오프를 이해하고, 알고리듬을 직접 설계해 보는 것입니다.
단기 생산성과 장기 이해의 균형
그렇다고 모든 코드를 완벽히 이해해야 하는 것은 아닙니다. 상황에 따라 기준을 조절하는 현명함이 필요합니다.
- 복붙·생성이 합리적인 경우: 중요도와 위험이 낮은 일회성 스크립트, 두세 명이 쓰는 내부 UI나 페이지
- 깊이 알아야 하는 경우: 몇 달, 몇 년간 소유·유지·진화시킬 코드. 가능한 한 모든 줄과 설정 옵션을 이해하는 방향으로 가야 합니다.
MVP나 실험 기능처럼 성공 여부가 불확실할 때는 품질 기준을 잠시 낮출 수 있습니다. 다만 이는 일종의 인지 부채(cognitive debt) 를 지는 것과 같습니다. 지금은 빨리 움직일 수 있지만, 제품이 살아남아 수정이 필요해지면 나중에 더 많이 갚아야 하죠. 그래도 최소한 자신 있게 "이건 작동한다"고 말할 수 있을 만큼은 이해하고 검증해야 합니다.
지식과 기술의 복리 효과
가끔 쓰는 언어나 도구라면 깊은 학습에 큰 시간을 쏟지 않아도 됩니다. 결과를 검증할 수 있다면 부분적 이해로 복사·생성하는 방식도 때로는 괜찮습니다.
하지만 정기적으로 쓰는 핵심 기술 스택에서는 이야기가 다릅니다. 숙련이 수백, 수천 배로 보상되기 때문입니다.
지식과 기술은 복리로 불어납니다.
- 더 많이 알수록 더 빠르게 만들 수 있고
- 새로운 지식도 점점 더 빠르게 습득하게 되며
- 역량이 늘수록 새로운 해법과 아이디어가 떠오릅니다
Output이 아니라 Outcome
생산성을 재는 방식은 크게 둘로 나뉩니다.
Output 중심 지표 (세기 쉽지만 조작도 쉬움)
- 작성한 코드 줄 수, 병합한 PR 수, 구현한 기능 수, 고친 버그 수
- 장황한 코드를 쓰거나, PR을 인위적으로 잘게 쪼개거나, 쓸모없는 기능을 더하면 숫자는 늘어납니다. 하지만 숫자가 곧 올바른 방향을 보장하지는 않습니다. 때로는 기능을 더하는 것보다 쓰지 않는 기능을 제거하는 편이 낫습니다.
Outcome 중심 지표 (장기 가치와 직결)
- 새 CI/CD로 프로덕션 릴리스가 안정화됨
- 리팩터링과 단순화로 향후 변경이 쉬워짐
- 테스트를 늘려 회귀를 막고, 지표·알림으로 문제를 선제적으로 발견함
- 지루한 수작업을 자동화해 치명적 오류 가능성을 줄임
더 많은 output이 항상 더 나은 것은 아닙니다. 장기 생산성은 outcome과 훨씬 잘 맞습니다.
복잡해지는 소프트웨어, 그리고 기초 원리
현대 소프트웨어는 정말 복잡합니다. 런타임과 플랫폼(브라우저·서버·클라우드·모바일·임베디드), 네트워크(HTTP·DNS·TLS·TCP/UDP·WebSocket), 보안·인증·인가, 운영체제, 컨테이너와 오케스트레이션, 각종 데이터베이스, 컴파일러 파이프라인, 무수한 아키텍처 패턴(DDD·CQRS·Hexagonal·Microservices…), 그리고 이제 LLM과 AI까지.
다행히 희망이 있습니다.
- 많은 시스템은 과도하게 설계되어 있어 충분히 단순화할 수 있습니다.
- 특정 시점에는 보통 이 넓은 지형의 작은 일부만 전문적으로 익히면 됩니다. 나머지는 "인식하는 수준"으로도 충분합니다.
- 무엇보다 도구 뒤에 있는 일반 패턴과 원리를 익히면, 새 도구를 배울 때 강력한 지렛대가 됩니다.
기초 원리란 무엇인가
기초 원리는 도구·라이브러리·프로토콜 밑에 있는, 잘 변하지 않는 규칙과 메커니즘입니다.
- 컴퓨터 아키텍처: CPU, 명령 실행, 메모리 계층, 캐시
- 언어와 변환: 어셈블러·컴파일러·인터프리터가 필요한 이유와 트레이드오프
- 운영체제: 프로세스·스레드·스케줄링·락·가상 메모리·I/O
- 알고리듬과 자료구조: 복잡도 분석
- 네트워크: 신뢰성·처리량·지연시간·계층 구조
- 데이터베이스: ACID, 트랜잭션, 격리 수준, 인덱스, 데이터 모델링
- 설계와 아키텍처: 모듈성, 정보 은닉, 결합도와 응집도
- 분산 시스템: CAP 정리, 복제, 합의, 최종적 일관성
- 동시성과 병렬성: 경쟁 상태, 교착 상태, 동기화
모든 분야를 마스터할 필요는 없습니다. 각 분야를 조금씩 알고, 선택한 몇 가지에서 뛰어나지는 것이 목표입니다. 이렇게 기초에 집중하면 시간이 지나며 '보편적 직관'이라는 메타 기술이 생깁니다. 컴퓨터가 단독으로, 또 클러스터에서 어떻게 작동하는지 깊이 이해하면 유행하는 도구의 세부사항에 덜 휘둘리고, 오히려 새 도구를 배우기가 훨씬 쉬워집니다.
마치며: 이해의 기쁨을 포기하지 말 것
원문 댓글에서 인상 깊은 지적이 있었습니다. 사람들이 "이해하지 못한 결과물"을 내도록 밀어붙이는 흐름에는 경제적 동기도 섞여 있다는 것입니다. 사용자가 특정 제품에 의존할수록 그 가치가 정당화되니까요.
그렇기에 더더욱 주체성(agency)을 포기하지 않는 것이 중요합니다. 더 많이 알수록 더 많은 것을 할 수 있고, 그러면 또 더 많은 것을 알게 되는 아름다운 선순환이 만들어집니다.
무언가가 어떻게 작동하는지 이해하는 일은 의무이기 이전에 재미있는 일입니다. 그 즐거움이 곧 실력이 되고, 실력이 곧 영향력이 됩니다. 오늘도 자신의 인지 한계를 한 걸음 밀어붙여 보는 건 어떨까요?
출처: GeekNews — 'binaryigor.com'의 글 "이해의 기쁨과 힘" 소개