'잘 훔치는 것'도 실력이다 — 개발자를 위한 모방 사용법

“위대한 예술가는 훔친다”는 말, 들어보셨죠

피카소가 했다고도 하고 스티브 잡스가 인용해 유명해진 말이 있어요. “좋은 예술가는 베끼고, 위대한 예술가는 훔친다.” 이번 글은 이 문장을 개발자와 창작자의 관점에서 다시 뜯어봐요. 핵심 주장은 단순해요. 훔치는 것, 그러니까 남의 것을 가져와 내 것으로 만드는 일은 타고난 재능이 아니라 따로 연습해야 느는 기술이라는 거예요.

베끼기와 훔치기는 달라요

글이 짚는 가장 중요한 구분이 바로 이거예요. 베끼기(copy)는 겉모습을 그대로 옮기는 거예요. 디자인을 픽셀 단위로 따라 하거나, Stack Overflow 코드를 이해 없이 붙여넣는 거죠. 작동은 할지 몰라도 왜 그렇게 됐는지 모르니까 조금만 상황이 바뀌어도 무너져요.

훔치기(steal)는 한 단계 더 들어가요. “이 사람은 왜 이런 선택을 했을까?”를 분해하는 거예요. 예를 들어 잘 만든 오픈소스 라이브러리를 볼 때, API 이름은 왜 이렇게 지었고, 에러 처리는 왜 여기서 했고, 추상화는 왜 이 지점에서 끊었는지를 읽어내는 거죠. 그 판단의 이유를 가져오면, 똑같이 베끼지 않아도 내 코드에 같은 품질을 심을 수 있어요. 이게 훔치기가 기술인 이유예요. 표면이 아니라 의사결정을 가져오는 거니까요.

왜 ‘연습이 필요한 기술’일까

좋은 걸 알아보는 눈, 즉 안목이 먼저 있어야 훔칠 수 있어요. 무엇이 좋은 코드인지 모르면 애초에 뭘 훔쳐야 할지도 모르거든요. 그래서 잘 훔치려면 일단 많이 봐야 해요. 좋은 코드베이스를 읽고, 잘 쓴 글을 분석하고, 멋진 UI를 뜯어보는 입력의 양이 쌓여야 안목이 생겨요.

그다음은 분해와 재조립이에요. 마음에 드는 결과물을 그냥 감탄하고 넘기지 말고, 부분으로 쪼개서 “이 조각은 왜 필요하지?”를 물어보는 습관이요. 그리고 결정적으로, 가져온 조각을 내 문제에 맞게 변형해 붙여야 해요. 출처와 다른 맥락에 자연스럽게 녹여내는 그 변형 과정에서 진짜 실력이 자라요. 그래서 모방은 창작의 반대말이 아니라 창작의 입구에 가까워요.

업계 맥락에서 보면

사실 소프트웨어 세계는 통째로 ‘잘 훔치기’로 굴러가요. 디자인 패턴이라는 것 자체가 선배들의 좋은 해법에 이름을 붙여 재사용하라고 정리해둔 거고, 오픈소스 생태계는 “내 걸 가져가서 네 걸 만들어”를 제도화한 문화예요. 리액트가 나온 뒤 수많은 프레임워크가 그 아이디어를 좋은 의미로 훔쳐 자기 식으로 발전시켰고요.

요즘은 AI 코딩 도구 때문에 이 이야기가 더 날카로워졌어요. Copilot이나 Claude가 코드를 척척 뱉어주니까 베끼기는 그 어느 때보다 쉬워졌거든요. 그런데 바로 그래서 훔치기의 가치가 올라가요. 누구나 코드를 받을 수 있는 시대엔, 받은 코드의 판단을 이해하고 내 맥락에 맞게 고를 줄 아는 안목이 사람의 진짜 경쟁력이 되니까요.

한국 개발자에게

특히 주니어 분들께 와닿을 거예요. 처음엔 다 따라 하면서 배우는 게 맞아요. 부끄러워할 일이 전혀 아니에요. 다만 붙여넣고 끝내지 말고, “왜 이렇게 짰지?”를 한 번 더 물어보는 습관을 들이면 같은 시간을 써도 성장 속도가 완전히 달라져요. 좋은 PR 리뷰를 정독하거나, 유명 오픈소스의 커밋 히스토리를 따라가 보는 것도 훌륭한 훔치기 훈련이에요.