구현 비용이 낮아질수록 먼저 고정해야 하는 것

AI 도구를 쓰면서 가장 크게 체감한 변화는 구현 속도였습니다. 이전에는 비용 때문에 미뤄두던 자동화나 개인 도구도 이제는 빠르게 형태를 만들 수 있습니다. 작은 자동화, 크롤러, OCR, 음성 처리, 영상 제작 파이프라인 같은 것들이 전보다 훨씬 가까워졌습니다.

이 변화는 생산성을 높이기도 하지만, 동시에 판단을 흐리게 만들기도 합니다. 만들 수 있는 것이 많아지면, 무엇이든 만들어봐야 할 것 같은 압박도 같이 커지기 때문입니다.

처음에는 저도 비슷했습니다. 다른 사람이 만든 자동화나 에이전트 조합을 보면, 그 흐름을 이해해야 한다는 압박이 있었습니다. 글을 보면 금방 따라 할 수 있을 것 같고, 실제로 따라 하면 어느 정도는 됩니다. Faceless 영상 제작 자동화, 음성 처리, CDP 기반 데이터 수집, 개인 건강 데이터 앱처럼 서로 다른 문제 영역을 직접 실험해봤습니다.

그 과정에서 얻은 결론은 단순했습니다. 만들 수 있다는 것과 계속 쓸 만큼 필요하다는 것은 다릅니다.

빠르게 만들 수 있다는 감각

AI를 활용하면 아이디어에서 결과물까지 가는 시간이 짧아집니다. 예전 같으면 하루나 이틀 잡아야 했던 것도 몇 시간 안에 형태를 볼 수 있습니다. 기술적으로 막히는 지점도 줄어듭니다. 모르는 라이브러리, 낯선 API, 익숙하지 않은 도메인도 예전보다 빠르게 접근할 수 있습니다.

이 감각은 중요합니다. 실제로 새로운 가능성을 열어줍니다. 예전에는 비용 때문에 시도하지 않았던 것들을 작은 실험으로 바꿀 수 있고, 머릿속에 있던 아이디어를 빠르게 검증할 수 있습니다.

다만 구현 비용이 낮아졌다고 해서 판단 비용까지 낮아지는 것은 아니었습니다. 오히려 반대에 가까웠습니다. 더 쉽게 만들 수 있기 때문에, 더 많은 아이디어가 실행 후보가 됩니다. 그만큼 무엇을 만들지, 무엇을 만들지 않을지, 어디까지 실험하고 어디서 멈출지를 판단하는 기준이 더 중요해졌습니다.

동작하는 것과 반복해서 쓰는 것은 다르다

몇 가지 실험은 데모 수준에서는 충분했습니다. 입력을 넣으면 결과가 나오고, 파이프라인은 돌아가고, 화면이나 파일 형태의 산출물도 만들어졌습니다. 기술적으로는 "된다"고 말할 수 있었습니다.

하지만 반복 사용 단계로 넘어가자 다른 기준이 필요했습니다.

• 이걸 실제로 다시 쓰는가
• 없으면 어떤 문제가 반복되는가
• 지금 해결한 것이 진짜 문제인가
• 도구를 만든 것인가, 문제를 줄인 것인가
• 유지보수할 만큼 충분히 중요한가

여기서 대답이 약하면, 그 결과물은 아직 시스템이 아니라 실험에 가깝습니다. 실험은 의미가 있습니다. 가능성을 확인하고, 도메인을 이해하고, 기술적 감각을 얻는 데 충분한 가치가 있습니다.

다만 실험과 시스템은 구분해야 합니다. 실험은 가능성을 확인하는 단계이고, 시스템은 반복 사용을 전제로 유지되는 구조입니다. 이 둘을 구분하지 않으면 데모가 된다는 사실을 실제 필요성으로 오해하기 쉽습니다.

How에 먼저 들어가면 생기는 착시

개발자는 불편한 것을 보면 구현 방식부터 떠올리기 쉽습니다. 이건 강점입니다. 문제를 구체적인 구조와 실행 단위로 바꾸는 능력이기 때문입니다. 하지만 AI 시대에는 이 본능을 더 조심해야 합니다. 구현 비용이 낮아졌기 때문에, 잘못 잡은 문제도 너무 쉽게 구현할 수 있기 때문입니다.

How에 먼저 들어가면 현재 떠올린 방식 안에서만 최적화하게 됩니다. 다른 해결책이 있을 수 있는데, 이미 정한 방식의 구현 문제처럼 다루게 됩니다. 자동화를 만들 것인지, 기존 도구를 조합할 것인지, 아예 하지 않아도 되는 일인지 판단하기 전에 구현 구조부터 정해버릴 수 있습니다.

이때 생기는 문제는 속도가 아닙니다. 방향입니다. 방향이 잘못된 상태에서 How를 최적화하면 더 빠르게 틀린 곳으로 갈 수 있습니다.

삽을 더 잘 쓰는 법을 고민하고 있는데, 애초에 굴착기를 써야 하는 상황일 수도 있습니다. 반대로 굴착기를 꺼낼 필요 없이 표지판 하나만 바꾸면 되는 문제일 수도 있습니다.

Faceless 영상 자동화에서 확인한 것

mwroh-dev/visual-creative-toolkit

Faceless 영상 제작 자동화를 만들 때도 비슷했습니다. 처음 목표는 A-Z까지 돌아가는 파이프라인을 만드는 것이었습니다. 소재를 만들고, 스크립트를 쓰고, 음성을 붙이고, 자막과 영상을 조합해서 결과물까지 뽑는 흐름을 확인하고 싶었습니다.

기술적으로는 가능했습니다. 실제로 파이프라인을 만들면서 어떤 도구를 연결해야 하는지, 어디에서 포맷이 깨지는지, 어느 단계에서 사람이 확인해야 하는지 감을 얻었습니다. 자동화가 가능한 지점과 사람의 판단이 필요한 지점도 조금 더 분명해졌습니다.

하지만 동시에 다른 문제가 드러났습니다. 파이프라인은 돌아가는데, 무엇을 기준으로 좋은 결과물인지 판단하기 어려웠습니다.

• 어떤 영상을 만들 것인가
• 누구에게 보여줄 것인가
• 어떤 톤이어야 하는가
• 어느 정도 길이가 적절한가
• 반복 제작할 이유가 있는가
• 결과물을 어디에 쓸 것인가

이 질문이 비어 있으면 자동화는 중간에서 멈춥니다. 정확히는 코드가 멈추는 것이 아니라 판단이 멈춥니다. A-Z 파이프라인을 만들기 전에, A를 왜 시작하는지부터 정해야 했습니다.

이 경험 이후로 자동화를 볼 때 기준이 조금 바뀌었습니다. 단순히 연결할 수 있는지보다, 반복 가능한 판단 기준이 있는지를 먼저 보게 됐습니다.

먼저 고정해야 하는 질문

AI와 대화할 때도 비슷합니다. How를 먼저 말하면 모델도 How 안에서 답합니다. 이미 정한 방식이 맞는지 의심하기보다, 그 방식을 더 잘 구현하는 쪽으로 들어갑니다.

예를 들어 "이 자동화를 어떻게 만들까"라고 물으면 모델은 구현 방법을 제안합니다. 하지만 "이 자동화가 필요한 문제는 무엇인가"라고 물으면 다른 답이 나옵니다. 질문의 출발점이 달라지면 결과도 달라집니다.

그래서 지금은 새로운 것을 만들기 전에 먼저 세 가지를 고정하려고 합니다.

What  → 무엇을 만드는가
Why   → 왜 필요한가. 없으면 어떤 문제가 생기는가
Who   → 누가 실제로 쓰는가

제 자신만 쓰는 도구여도 Who는 필요합니다. "내가 쓴다"는 말만으로는 부족할 때가 많습니다. 언제, 어떤 상황에서, 얼마나 자주 쓰는지까지 정해야 계속 쓸 수 있는 구조가 나옵니다. 여기에 하나를 더 붙이면 Use Case입니다.

Use Case → 어떤 상황에서 어떤 입력을 받아 어떤 결과를 내야 하는가

이 질문이 구체적일수록 How는 더 정확해집니다. 반대로 이 질문이 비어 있으면 구현은 가능해도 사용 맥락이 흔들립니다.

FOMO를 보는 기준도 바뀌었다

다른 사람들의 사례를 볼 때도 기준이 바뀌었습니다. 예전에는 이런 쪽에 먼저 눈이 갔습니다.

• 어떤 툴을 썼는가
• 어떤 조합이 되는가
• 내가 따라 할 수 있는가

지금은 먼저 다른 것을 봅니다.

• 무엇을 문제로 봤는가
• 왜 그 문제가 중요했는가
• 누가 반복해서 쓰는가
• 어떤 비용이나 병목을 줄였는가
• 그 사람의 환경과 내 환경이 같은가

이렇게 보면 따라 할 것과 참고만 할 것이 조금 더 분리됩니다. 어떤 사례는 기술적으로 흥미롭지만 저의 문제에는 맞지 않을 수 있습니다. 반대로 화려하지 않은 자동화라도 반복되는 병목을 줄인다면 더 가치 있을 수 있습니다.

중요한 것은 도구를 모르는 상태로 남는 것이 아닙니다. 도구를 따라가기 전에, 그 도구가 해결한 문제와 내 환경의 문제가 같은지 확인하는 것입니다.

How는 버리는 것이 아니라 뒤로 보내는 것

What과 Why를 먼저 본다는 말이 How를 가볍게 본다는 뜻은 아닙니다. 오히려 반대에 가깝습니다. What과 Why가 정리되어야 How가 제대로 힘을 받습니다.

목적이 분명하면 기술 선택도 달라집니다.

• 빠른 검증이 필요한가
• 반복 사용이 중요한가
• 품질이 중요한가
• 사람이 중간에 확인해야 하는가
• 유지보수할 가치가 있는가
• 실패했을 때 비용이 큰가

이 질문에 따라 구현 방식은 달라집니다. 하루짜리 실험이면 단순한 스크립트가 충분할 수 있습니다. 반복적으로 쓰는 내부 도구라면 입력 검증, 로그, 복구 방식, 문서화가 필요할 수 있습니다. 사용자가 있는 제품이라면 UX와 운영 기준까지 고려해야 합니다.

How는 여전히 중요합니다. 다만 너무 빨리 꺼내면 문제를 해결하는 도구가 아니라, 이미 떠올린 방식을 정당화하는 장치가 될 수 있습니다.

개발자로 일하다 보면 불편함을 How로 번역하는 습관이 생깁니다. 이건 강점이지만, AI 시대에는 동시에 관리해야 할 습관이기도 합니다. 구현 비용이 낮아질수록 잘못된 문제도 너무 쉽게 구현할 수 있기 때문입니다.