비개발자가 직접 서비스를 만들어야 하는 진짜 이유

저는 개발자가 아닙니다. 코드를 직접 쓰지 못했던 사람입니다. 그런데 서비스를 만들려 할 때마다 제작에 적지 않은 비용과 시간을 써야 했습니다. 머릿속의 문제를 설명하고, 결과물을 기다리고, 다시 설명하는 동안 한 가지 질문이 남았습니다. 문제를 가장 잘 아는 사람이 정작 만드는 과정에서는 왜 멀리 떨어져 있어야 할까?

직접 빌드한다는 말을 ‘혼자서 모든 코드를 작성한다’는 뜻으로 받아들이면 답이 보이지 않습니다. 비개발자가 직접 빌드한다는 것은 개발자의 일을 흉내 내는 게 아닙니다. 자신이 아는 문제를 정확히 정의하고, 이번에 구현할 범위를 결정하고, 나온 결과가 실제 문제를 해결하는지 끝까지 검증하는 것입니다. 구현에 도구나 다른 사람의 도움이 들어가더라도 이 세 가지 판단을 넘기지 않는 것이 핵심입니다.

저는 실제로 영상 자동화 시스템을 6시간에 만들었고, 그 시스템을 해당 영상에 사용했습니다. 이 경험은 ‘비개발자도 무엇이든 단숨에 만들 수 있다’는 증명이 아닙니다. 오히려 내가 반복해서 겪은 일을 내가 정의하고, 필요한 범위를 좁히고, 결과를 직접 확인할 수 있을 때 빌드가 빨라질 수 있다는 사례에 가깝습니다. 그리고 이 경험에서 VUILD를 만들었습니다.

문제를 아는 사람과 만드는 사람이 멀어질 때 생기는 일

서비스 제작의 출발점은 기능이 아니라 문제입니다. 같은 “영상 작업을 줄이고 싶다”는 말도 실제 현장에서는 전혀 다른 뜻일 수 있습니다. 누군가는 자막 입력이 오래 걸리고, 누군가는 반복되는 파일 정리가 번거롭고, 누군가는 매번 같은 순서로 여러 도구를 오가는 일이 문제일 수 있습니다. 겉으로 같은 요구처럼 보여도 줄여야 할 행동은 다릅니다.

이 차이를 가장 빨리 구분할 수 있는 사람은 그 일을 반복해 본 사람입니다. 여기서 도메인 전문가는 특정 업무를 실제로 해왔고, 어디서 시간이 들며, 어떤 결과가 쓸 만한지 판단할 수 있는 사람입니다.

문제 정의를 다른 사람에게 전부 넘기면 설명 과정에서 맥락이 줄어듭니다. “자동으로 처리해 주세요”라는 요청은 구현할 수 있는 문장이 아닙니다. 무엇이 입력되고, 어떤 순서로 처리되며, 무엇이 나오면 완료인지 정해야 합니다. 반면 업무를 아는 사람이 주체가 되면 질문이 구체적으로 바뀝니다.

지금 반복되는 행동은 정확히 무엇인가?
그중 사람이 판단해야 하는 부분과 반복 처리할 부분은 무엇인가?
시작할 때 넣는 자료는 무엇인가?
끝났다고 판단할 수 있는 결과는 무엇인가?
결과가 틀렸을 때 가장 먼저 알아차릴 수 있는 신호는 무엇인가?

이 답은 코드 문법이 아니라 실제 문제에 대한 이해에서 나옵니다. 따라서 구현 방식 전체를 알지 못해도 문제를 가장 잘 아는 사람은 빌드의 출발점을 주도할 수 있습니다.

직접 빌드의 핵심은 범위를 결정하는 권한입니다

아이디어에는 기능을 계속 붙이기 쉽습니다. 하지만 처음부터 가능한 기능을 모두 넣으면 무엇을 검증하려는 서비스인지 흐려지고, 핵심 문제가 해결됐는지 판단하기도 어려워집니다.

범위 결정은 ‘할 수 있는 것’을 고르는 일이 아니라 ‘이번에는 무엇을 확인할 것인가’를 고르는 일입니다. 첫 빌드의 목적이 반복 업무 하나를 줄이는 것이라면, 그 흐름이 처음부터 끝까지 작동하는 데 필요한 것만 남겨야 합니다. 있으면 편리한 기능과 핵심 결과에 반드시 필요한 기능을 분리하는 판단은 도메인 전문가가 맡아야 합니다.

다음 표처럼 범위를 나누면 구현 수단보다 목적을 먼저 볼 수 있습니다.

구분	이번 빌드에 넣는 기준	판단 질문	예시
핵심 입력	결과를 만들기 위해 반드시 필요한 자료	이것이 없으면 작업을 시작할 수 없는가?	원본 파일, 작업 지시
핵심 처리	해결하려는 반복 업무와 직접 연결된 동작	이 동작이 빠지면 원래 문제가 그대로 남는가?	정해진 순서의 반복 처리
핵심 결과	사용자가 완료 여부를 확인할 수 있는 산출물	결과를 눈으로 보거나 직접 사용할 수 있는가?	가공된 파일, 정리된 목록
검증 장치	성공과 실패를 구분하기 위한 확인 수단	잘못됐을 때 알아차릴 수 있는가?	처리 상태, 오류 표시, 결과 비교
다음 범위	핵심 검증 뒤에 판단해도 되는 기능	지금 없어도 핵심 흐름을 시험할 수 있는가?	꾸미기, 편의 기능, 추가 연동
제외 범위	목적과 직접 관련이 없거나 별도 검토가 필요한 기능	넣는 순간 다른 책임과 위험이 커지는가?	불필요한 확장 기능, 검토되지 않은 민감 기능

‘제외’는 포기가 아니라 다음 판단을 위한 기록입니다. 무엇을 넣지 않았는지 알아야 결과가 기대와 다를 때 원인을 구분하고, 다음 범위를 추가할지 판단할 수 있습니다.

영상 자동화 시스템을 6시간에 만든 일도 무한한 기능을 완성했다는 뜻은 아닙니다. 제가 겪던 작업을 알고 있었고, 해당 영상에 사용할 결과를 직접 확인할 수 있었다는 점이 중요합니다.

결과 검증은 기술 지식보다 사용 맥락에서 시작됩니다

작동하는 화면이 나왔다고 해서 문제가 해결된 것은 아닙니다. 버튼이 눌리고 파일이 생성돼도 실제 업무에서 쓸 수 없는 결과일 수 있습니다. 반대로 내부 구현을 자세히 설명하지 못해도, 입력과 결과를 비교하고 실제 작업이 줄었는지 확인할 수 있다면 중요한 검증을 시작할 수 있습니다.

도메인 전문가는 평소의 입력, 허용할 수 없는 실수, 결과의 다음 사용처를 알기 때문에 ‘정답처럼 보이는 결과’와 ‘현장에서 쓸 수 있는 결과’를 구분할 수 있습니다.

검증은 감상평이 아니라 관찰 가능한 문장이어야 합니다. “잘 되는 것 같다”보다 “실제 입력으로 필요한 산출물이 생성됐고, 직접 열어 다음 작업에 사용했다”가 정확합니다.

결과 검증 체크리스트

[ ] 해결하려는 문제를 한 문장으로 설명할 수 있다.
[ ] 실제 업무에서 쓰는 입력으로 시험했다.
[ ] 입력부터 결과까지 핵심 흐름을 직접 끝까지 실행했다.
[ ] 결과물을 열어 보거나 다음 작업에 실제로 사용해 봤다.
[ ] 기대한 결과와 실제 결과를 비교할 기준이 있다.
[ ] 빈 값, 잘못된 형식 등 예상 가능한 실패 입력도 확인했다.
[ ] 오류가 났을 때 실패 사실을 사용자가 알아차릴 수 있다.
[ ] 사람이 계속 판단해야 하는 단계가 무엇인지 구분했다.
[ ] 이번 범위에서 확인하지 않은 항목을 따로 기록했다.
[ ] 다음 기능을 추가하기 전에 현재 문제가 실제로 줄었는지 확인했다.

이 체크리스트가 모든 기술적 검토를 대신하지는 않습니다. 보안, 개인정보, 법적 의무, 큰 규모의 운영처럼 전문 판단이 필요한 영역은 해당 전문가의 검토가 필요합니다. 직접 빌드의 의미는 전문가가 필요 없다는 데 있지 않습니다. 어떤 문제를 해결하고 무엇을 검증해야 하는지에 대한 주도권을 문제의 당사자가 갖는 데 있습니다.

“비개발자가 직접 만들면 오히려 위험하지 않나요?”

그럴 수 있습니다. 코드를 직접 쓰지 못하는 사람이 도구가 내놓은 결과를 이해하지 않은 채 곧바로 중요한 업무에 적용하면 위험을 발견하지 못할 수 있습니다. 한 번 실행된 결과만 보고 계속 작동할 것이라 가정하는 것도 피해야 합니다. 직접 만들었다는 사실이 품질이나 안전을 자동으로 보장하지는 않습니다.

그렇다고 문제 정의와 검증까지 모두 맡겨야 하는 것은 아닙니다. 개발자는 구조와 기술적 위험을, 도메인 전문가는 필요한 결과를 판단합니다. 둘은 서로 다른 역할입니다.

직접 빌드의 범위도 구분해야 합니다.

직접 주도할 영역: 문제 문장, 사용자와 사용 상황, 핵심 입출력, 우선순위, 완료 기준, 실제 결과 확인
도움을 받아 결정할 영역: 구현 방식, 도구 선택, 데이터 구조, 유지보수 방식, 운영 환경
전문 검토가 필요한 영역: 보안, 개인정보, 법률·규제, 중요한 데이터의 보호, 장애가 큰 피해로 이어지는 기능

현실적인 원칙은 ‘모두 혼자 한다’가 아니라 ‘판단의 주체를 놓치지 않는다’입니다. 기술적 위험은 검토를 요청하되, 왜 만드는지와 어떤 결과가 맞는지는 스스로 답할 수 있어야 합니다.

구현은 외주나 개발팀에 맡길 수도 있습니다. 직접 빌드는 외주의 반대가 아니라 문제 정의, 범위 결정, 결과 검증을 넘기지 않는 방식입니다. 구현 주체가 누구든 실제 사용자가 결과를 확인하고 다음 범위를 결정하면 됩니다.

비개발자에게 필요한 것은 코딩 자신감보다 판단 기준입니다

도구보다 먼저 필요한 것은 무엇을 해결할지, 어디까지 만들지, 무엇을 보고 성공이라 할지에 대한 답입니다. 이 세 답이 없으면 구현이 빨라도 방향을 확인할 수 없습니다.

제가 영상 자동화 시스템을 6시간에 만들고 그 영상을 실제로 만든 경험에서 얻은 것도 막연한 자신감이 아니었습니다. 제가 아는 문제라면 필요한 결과를 정의할 수 있고, 범위를 정할 수 있으며, 실제 사용으로 검증할 수 있다는 것이었습니다. VUILD는 바로 이 경험에서 시작됐습니다.

비개발자가 직접 빌드해야 하는 이유는 개발자를 대체하기 위해서가 아닙니다. 문제를 가장 잘 아는 사람이 제품의 방향을 잃지 않기 위해서입니다. 직접 코드를 쓰지 못해도 다음 세 문장은 직접 써야 합니다.

내가 해결하려는 문제는 무엇인가.
이번에 반드시 작동해야 하는 범위는 어디까지인가.
어떤 결과를 직접 확인하면 해결됐다고 말할 수 있는가.

구현은 협업할 수 있지만, 문제와 범위와 검증의 기준은 현장을 아는 사람에게서 출발해야 합니다.

자주 묻는 질문 (FAQ)

Q. 코드를 전혀 쓰지 못해도 ‘직접 빌드한다’고 말할 수 있나요?
네. 여기서 직접 빌드는 모든 코드를 혼자 작성한다는 뜻이 아닙니다. 문제를 정의하고, 구현 범위를 결정하고, 실제 입력과 결과로 해결 여부를 검증하는 과정을 주도한다는 뜻입니다.

Q. 비개발자가 가장 먼저 정해야 할 것은 무엇인가요?
기능 목록보다 해결할 문제를 먼저 정해야 합니다. 누가 어떤 상황에서 무엇을 반복하고 있는지, 어떤 결과가 나오면 문제가 줄었다고 판단할지를 한 문장으로 적는 것이 출발점입니다.

Q. 첫 빌드의 범위는 어떻게 줄이나요?
핵심 입력, 반드시 필요한 처리, 직접 확인할 결과, 실패를 알아차릴 장치만 우선 남깁니다. 없어도 핵심 흐름을 시험할 수 있는 편의 기능과 추가 연동은 다음 범위로 분리합니다.

Q. 결과가 제대로 만들어졌는지는 어떻게 확인하나요?
실제 업무에서 쓰는 입력을 넣고 핵심 흐름을 끝까지 실행한 뒤, 나온 결과를 열어 보거나 다음 작업에 사용해 봅니다. 기대 결과와 비교하고, 잘못된 입력에서도 실패를 알아차릴 수 있는지 확인해야 합니다.

Q. 직접 만들면 전문가의 도움이 필요 없나요?
아닙니다. 구현 구조와 기술적 위험은 개발자의 도움이 필요할 수 있고, 보안·개인정보·법률·규제 등은 해당 전문가의 검토가 필요합니다. 직접 빌드는 전문성을 배제하는 방식이 아니라, 문제 당사자가 목적과 검증 기준을 놓치지 않는 방식입니다.

Q. VUILD는 어떤 경험에서 시작됐나요?
비개발자인 김봉준 대표가 영상 자동화 시스템을 6시간에 만들고, 그 시스템을 해당 영상에 실제로 사용한 경험에서 시작됐습니다. 문제를 아는 사람이 범위를 정하고 결과를 검증하는 빌드 경험이 VUILD를 만드는 계기가 됐습니다.