만든다는 것 — 직접 만들어야 하는 이유와 AI 시대의 가치

AI가 코드를 짜고, 이미지를 그리고, 글까지 쓴다. 더는 뭘 직접 만들어야 할까, 하는 물음이 자연스러운 시대가 왔다. 하지만 곰곰이 따져 보면 결론은 놀라울 정도로 단순하다. 만드는 행위 자체가 사고의 연장선이기 때문이다. 도구가 아무리 똑똑해져도, 무엇을 왜 만들지 결정하는 것은 여전히 사람의 몫이다.

1. 만드는 것은 곧 생각하는 방법이다

개발자라면 한 번쯤 이런 경험을 해봤을 것이다. 머릿속에서 명확해 보이던 설계가 코드로 옮기는 순간 갑자기 모호해지는 순간. 추상적으론 완벽해 보이던 로직이 실제 타입 시스템과 부딪히며 미묘하게 깨지는 경험. 이건 사고가 부족해서가 아니라 사고의 구멍을 코드가 드러내줄 때 생기는 일이다.

소프트웨어에서 가장 가치 있는 산출물은 코드가 아니라 코드를 통해 명료해지는 사고의 형태다. 코드는 단지 사고의 저장 매체일 뿐이고, 그 매체를 직접 만져봐야만 비로소 진짜 생각이 정리된다. AI는 이 사고 단계를 단축시켜줄 수 있지만, 사고 자체를 대신할 수는 없다.

어떤 아키텍처가 옳은지, 어떤 인터페이스가 사용자에게 맞는지, 어떤 이름을 붙여야 의도가 분명해지는지 — 이런 결정들은 도구가 만들어주지 않는다. 도구는 후보를 빠르게 만들어줄 뿐, 결정은 여전히 사람의 일이다.

2. 자동화가 늘어도 손으로 해야 하는 일이 남는 이유

자동화 도구가 폭발적으로 늘었다. CI/CD는 클릭 한 번이 요건이 됐고, 코드 생성은 프롬프트 한 줄로 끝난다. 하지만 그 자동화의 위쪽, 즉 무엇을 자동화할지 정하는 단계는 여전히 사람이 결정한다. 자동화 가능한 후보가 100개라 치자. 그중 어떤 것을 우선해야 할까?

이 우선순위 결정은 단순한 ROI 계산이 아니다. 도메인 지식, 팀의 상황, 기술 부채의 무게, 사용자 경험 — 이 모든 변수가 뒤섞인 결정에서 맥락을 가진 사람만이 의미 있는 답을 낼 수 있다. AI는 후보를 정리해주고 비교표를 만들어줄 수 있지만, 그 결정을 대신 짓진 못한다.

더 본질적으로는, 자동화가 가치 있다는 판단 자체가 한 차위의 사고다. 어떤 반복이 의미 있고 어떤 반복이 노이즈인지 구분하는 능력, 그리고 그 자동화가 가져올 2차 효과를 미리 그려보는 능력. 이건 직접 무언가를 만들어본 사람에게만 자연스럽게 생기는 감각이다.

3. 만드는 시간이 길어질수록 효율은 올라간다

한 분야의 숙련자가 초보자보다 빠른 건 단순히 손이 빠른 게 아니다. 패턴을 보기 때문이다. 같은 코드를 봐도 숙련자는 “이 라이브러리는 3년 전에 이런 이슈가 있었다”는 맥락을 즉시 떠올린다. 이 경험적 직관은 시간을 들여 직접 부딪혀보지 않으면 쌓이지 않는다.

AI 시대에 이건 더 중요해진다. 도구가 빠르게 결과를 내줄 때, 사람은 “왜 이 도구가 이 답을 줬는지”를 평가해야 한다. 그 평가는 결국 도메인에 대한 깊은 이해가 있어야만 가능하다. 도구가 만들어준 결과를 그대로 받아쓰는 사람과, 그 결과를 비판적으로 검토하는 사람은 몇 달 사이에 명확한 성능 차이를 보인다.

코드리뷰 한 번 해보면 이 차이가 또렷하게 드러난다. AI가 짠 코드를 그냥 통과시키는 사람은 사소한 보안 이슈를 놓치고, 직접 구현해본 사람은 “이 에러 처리는 race condition을 일으킬 수 있다”는 점을 짚어낸다. 같은 코드를 봐도 보이는 것의 깊이가 다르다. 그 깊이는 직접 만든 경험에서만 온다.

4. 만드는 것으로 돌아가야 하는 이유

마지막으로 가장 개인적인 이유다. 무언가를 직접 만들어내는 행위는 성취감의 원천이다. 도구로 빠르게 끝낸 작업은 잊혀지지만, 밤을 새워 만든 첫 컴파일러, 통째로 다시 짜본 작은 게임, 손으로 직접 그린 와이어프레임 — 이런 경험은 오래 남는다.

AI가 보편화될수록 이 “내가 만들었다”는 감각은 점점 희소해진다. 그리고 희소해진 만큼 더 값지게 된다. 모든 결과물이 도구의 결과로 채워질 때, 정말로 내가 만든 결과물은 분명한 개성을 갖는다. 그 개성이 결국 사람의 가치를 결정한다.

도구를 잘 쓰는 것도 능력이다. 하지만 그 도구 너머에 “나는 이것을 왜, 어떻게 만들고 싶은가”라는 확고한 의도가 있는 사람과, 도구가 만들어주는 결과를 그대로 소비하는 사람은 결국 다른 곳에 도달한다. 만드는 쪽이 결국 더 멀리 간다.

5. 실전에서 만들어보기 — 작은 예시

이론만 말하면 공허하니 작은 실전 사례를 하나 보자. 다음은 어떤 함수에 명시적인 에러 처리를 추가하는 간단한 Python 코드다.

import logging

import time
from typing import Optional
import requests
from requests.exceptions import HTTPError, JSONDecodeError

logger = logging.getLogger(__name__)

def fetch_user_profile(user_id, retries=3):
for attempt in range(1, retries + 1):
try:
response = requests.get(f"https://api.example.com/users/{user_id}")
response.raise_for_status()
return response.json()
except HTTPError as e:
logger.warning("attempt %d failed: %s", attempt, e)
if attempt == retries:
logger.error("user %d fetch failed after %d attempts", user_id, retries)
return None
time.sleep(0.5 * attempt)
except (JSONDecodeError, ValueError) as e:
logger.error("user %d returned invalid JSON: %s", user_id, e)
return None
return None

이 함수는 단순해 보이지만, 다음 결정을 직접 내렸다: (1) 재시도 횟수를 인자로 노출할지 하드코딩할지, (2) 최종 실패 시 None을 반환할지 예외를 던질지, (3) 로깅 레벨을 warning과 error로 어떻게 나눌지. AI는 코드의 골격을 빠르게 만들 수 있었지만, 이런 비즈니스 결정은 도메인에 손을 대본 사람만이 내릴 수 있다.

6. 전망 — AI와의 협업에서 사람의 역할

앞으로 AI는 더 빠르게, 더 많은 일을 해줄 것이다. 하지만 역설적으로 그럴수록 “무엇을 만들 것인가”라는 질문의 무게는 더 커진다. 결과물을 빠르게 만들 수 있다는 건, 잘못된 것을 빠르게 만들 위험도 함께 늘어난다는 뜻이다.

사람의 역할은 점점 방향 설정자(direction setter)로 이동한다. 무엇을 만들지 정하고, 무엇을 만들지 않을지를 결정하는 사람. AI는 그 결정을 빠르게 검증해주고, 다양한 후보를 빠르게 비교해주며, 실행을 빠르게 해준다. 하지만 첫 번째 결정과 마지막 평가는 사람의 몫으로 남는다.

그래서 우리는 더 많이 만들어야 한다. 도구가 빨라진 만큼 우리가 검토해야 할 양도 늘었지만, 그만큼 실험 가능한 범위도 넓어졌다. 작게 만들고, 빠르게 검토하고, 다시 만드는 이 순환이 일상화된 사람들이 결국 이 시대의 승자가 된다.

7. 요약 — 다시 만드는 쪽으로

• 만드는 행위는 사고의 연장선이며, 사고의 구멍을 직접 드러내준다.
• 자동화의 우선순위 결정은 여전히 사람의 영역이다.
• 숙련자의 직관은 직접 부딪혀본 시간에서만 쌓인다.
• AI 시대에 “내가 만들었다”는 개성은 점점 더 희소하고 가치 있는 자산이 된다.
• 앞으로 사람의 역할은 방향 설정자로 이동한다.

도구가 어떻게 발전하든, 우리는 계속 만들어야 한다. 그리고 그 만드는 시간 자체가 결국 우리를 그 도구의 소비자에서 그 도구의 방향을 정하는 사람으로 바꿔놓는다. 만드는 쪽이 결국 더 멀리 간다.

---

원문: 만든다는 것 — 긱뉴스(31728)

설명: 생성형 AI로 프로젝트를 완성해도 요청한 사람과 실제 제작 주체가 다르다면, ‘내가 만들었다’는 성취감을 얻기 어려움 프롬프트에는 비전·판단·소통·기술이 필요하지만, 직접 만드는 기술보다는 다른 존재에게 제작을 맡기는 기술에 가까움 직접 작성한 177줄짜리 스페인어 플래시카드 시스템은…

---

📰 원본 출처 · https://news.hada.io/topic?id=31728 (#N=31728)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.