프로그래밍과 라이브러리, 그리고 AI 시대의 코드 작성에 대하여
비개발자인 제가 AI와 함께 코드를 다루며 품게 된 생각을 정리해 봅니다.
프로그래밍이라는 용어가 개념적으로 정확하지 않을 수 있으나, 떠오르는 생각을 담기에 이보다 적절한 말을 찾지 못해 그대로 사용하겠습니다.
1. 프로그래밍이란 무엇인가
프로그램은 목적성을 가집니다. 글을 쓰기 위한 것, 보기 위한 것, 사진이나 영상을 편집하기 위한 것 등(주로 제 사용 범위에 국한된 예시임을 밝힙니다)과 같이 말입니다.
이런 목적성은 필요한 기능을 호출하고, 결국 프로그래밍이란 필요 기능의 구현과 그 구현된 것들의 정합성 있는 통합이라 할 수 있을 것입니다.
2. 라이브러리에 대하여
그럼 여기서 왜 라이브러리를 덧붙여 이야기하는가?
라이브러리에 대한 이야기로 **“바퀴를 다시 발명하지 마라(Don’t reinvent the wheel)”**는 격언이 존재합니다. 모듈화와 같은 재사용성을 위한, 미리 작성된 코드 묶음의 필요를 이해하기에 충분한 말이라 생각합니다. 이러한 이유로 개발의 속도와 효용성을 위해 만들어진 라이브러리를 사용하는 것이 합리적일 것입니다.
하지만 최근, AI에게 코드 작성을 요청하면 앞서 다룬 라이브러리를 이용하여 여러 작업들을 수행하려 합니다. 이 지점에서 문제가 발생합니다.
학습이라는 과거로 고정될 수밖에 없는 데이터와, 할루시네이션이라는 그럴싸한 말 만들어내기의 특성으로 인해, 폐기되었거나 사용성이 맞지 않는, 나아가서는 존재하지 않는 라이브러리를 코드상에 위치시켜 나쁜 코드를 생성한다는 것입니다.
이러한 이유에서인지, 숙련된 개발자는 또는 시니어 개발자는 오래되고 수차례 검증된 언어로, 묶음의 사용 없이 순수하게 풀어진 코드로 작업하는 것이 좋은 형태라고 조언합니다.
비개발자이며 무언가를 직접 작업해 보지는 못했지만, AI와의 경험을 통해 예방 차원에서 좋은 팁이란 생각이 들었습니다.
3. 순서를 바꿔 생각하다
그리고 패턴의 발견에 그 어느 것보다 탁월한 AI라면, 일단 풀어진 코드로 만들어낸 프로그램을 다시 살펴서 묶을 수 있는 것을 찾아내어, 그때에 라이브러리로 재작성해 가는 것이 맞다는 생각을 하게 되었습니다.
즉, **“바퀴를 다시 발명하지 마라”**는 격언을 ‘이미 만들어진 라이브러리를 찾아서 활용하라’로 적용할 것이 아니라, 다르게 읽어야 한다는 것입니다.
내가 만들어 내는 **차(바퀴를 이용하는)**가 어떤 모습이며, 그에 맞는 바퀴가 몇 인치의 크기를 가져야 하는지 모르니, 프로그램(차)을 먼저 만들고 나서 라이브러리(바퀴)를 자체 제작하여 쓰는 것이 맞겠다는 이야기입니다.
물론 AI의 발전으로 할루시네이션이나 잘못된 라이브러리 선택은 해결될 수 있겠지만, 오히려 그 발전은 순수한 코드만으로 기능 구현을 할 수 있게 하기도 하며, 전체적으로 목적성에 맞게 잘 통합시키기도 할 것입니다. 발전된 AI는 자체적인 라이브러리를 더 잘 만들 수 있을 것이라 할 수 있습니다.
4. Claude를 통한 비평
위의 생각을 Claude에게 공유하고 비평을 요청했습니다. 돌아온 응답을 정리합니다.
동의한 부분
AI의 라이브러리 선택 문제는 실제로 존재합니다. 특히 JavaScript나 Python 생태계처럼 라이브러리가 빠르게 생기고 사라지는 환경에서 심합니다. 더 이상 사용되지 않는(deprecated) API를 자신 있게 쓰거나, 존재하지 않는 함수를 호출하는 것은 흔한 일입니다.
그리고 “먼저 만들고 나중에 묶어라"는 접근은 프로토타이핑 단계에서 특히 유효합니다. 뭘 만들지 모르는데 바퀴 사이즈부터 정하는 것은 비효율적이라는 통찰은 정확하다고 했습니다.
보완을 제안한 부분
첫째, “순수 코드"의 범위 문제입니다. HTTP 통신, 암호화, 데이터베이스 연결 같은 것은 라이브러리 없이 처음부터 작성하면 보안 취약점이 생길 수 있습니다. 바퀴에도 종류가 있다는 것입니다. 타이어는 직접 깎아도 되지만, 베어링은 공장 제품을 써야 안전한 것처럼요.
둘째, 적용 범위의 한계입니다. 이 접근법은 1인 시스템처럼 자기만 쓰는 도구를 만들 때 매우 적합하지만, 팀 프로젝트나 유지보수가 필요한 시스템에서는 널리 쓰이는 라이브러리가 ‘공통 언어’ 역할을 합니다. 자체 라이브러리는 만든 사람만 이해하는 방언이 될 수 있다는 지적이었습니다.
셋째, 용어의 발견입니다. 제가 생각한 논리를 따르면, AI 시대의 라이브러리는 ‘미리 만들어진 부품’이 아니라 ‘내 설계도에서 추출한 패턴의 결정체’가 됩니다. 이는 소프트웨어 공학에서 말하는 **상향식 추상화(bottom-up abstraction)**라는 개념과 일치한다고 합니다. 먼저 구체적으로 만들고, 반복되는 패턴을 발견하면 그때 추상화하는 것입니다.
이렇게 해서 Claude가 제시한 정리는 다음과 같았습니다.
“인프라 수준의 검증된 것은 쓰되, 비즈니스 로직은 순수하게 먼저 짜라.”
5. 비평을 통해 인지한 것
Claude의 비평을 받아들이면서도, 한 가지 질문이 떠올랐습니다.
비개발자인 입장에서 **“인프라 수준의 검증된 것”**은 어떻게 분별해야 하는가? AI가 “검증되었다"라고 역사와 활용 사례를 이야기한다면, 그런데 그것이 만약 할루시네이션이라면, 어떻게 판단하고 선택해야 하는가?
이 질문에 Claude는 솔직하게 답했습니다. 완벽한 분별은 불가능하다고요.
비개발자뿐 아니라 개발자도 자기 전문 영역 밖의 라이브러리는 ‘남의 말을 믿고’ 쓰는 경우가 많다는 것입니다. AI가 “이건 검증됐어"라고 말하고, 그 근거도 AI가 제공하면, 결국 AI의 말로 AI의 말을 검증하는 순환이 생긴다는 점을 인정했습니다.
그리고 이 질문이 오히려 처음의 주장을 더 강하게 만든다고 했습니다. ‘검증된 라이브러리를 골라 쓰라’는 조언은 그 검증을 판단할 능력이 전제되어야 하는데, 비개발자에게 그 전제가 없다면, 차라리 순수 코드로 작성하고 — 적어도 그 코드가 실행되는지, 원하는 결과가 나오는지 직접 확인할 수 있으니 — 그것이 더 정직한 접근이라는 것입니다.
실용적 팁의 발견
이 대화를 통해 실질적으로 적용할 수 있는 것들을 얻었습니다.
코드 작성 요청 시의 프롬프트:
“외부 라이브러리 없이, 언어 기본 내장 기능만으로 작성해줘”
언어에 기본 포함된 표준 라이브러리(Python의 os, json, http 등)는 언어 자체의 일부이므로 할루시네이션 가능성이 매우 낮습니다. 그리고 실행해서 동작하면 일단 맞는 것입니다. 이것이 비개발자가 가진 가장 정직한 검증 도구입니다.
기술 명세를 먼저 받는 과정에서의 체크리스트:
- 라이브러리 이름을 검색하여 공식 사이트나 GitHub 페이지의 존재 여부 파악
- GitHub에 있다면 star 수, 마지막 업데이트 날짜, 이슈 대응 활동 체크
- 직접 검색하여 AI가 추천한 것과 실제 커뮤니티가 쓰는 것이 일치하는지 교차 확인
글을 마치며
이번 글은 기술적 깊이보다는 비개발자의 시선에서 AI와 코드를 다루며 느낀 고민을 정리한 것에 가깝습니다.
핵심은 간단합니다. 목적을 먼저 구현하고, 추상화는 나중에. 그리고 AI에게 코드를 맡길 때, 라이브러리라는 ‘남의 바퀴’를 먼저 끼우지 말고, 내 차의 모양을 먼저 만드는 것이 순서라는 생각입니다.
AI의 비평을 통해 이 생각에 상향식 추상화라는 이름이 붙었고, 동시에 그 한계도 확인했습니다. 하지만 한계를 아는 것 자체가 더 나은 선택을 가능하게 한다고 믿습니다.
무엇보다, AI와의 대화가 단순한 질의응답을 넘어 자신의 생각을 검증하고 다듬는 도구가 될 수 있다는 점을 다시 한번 확인한 경험이었습니다.