한 시간 만에 만든 코드보다 먼저 설계해야 할 것: 속도와 공개의 역설

인공지능을 이용하면 외주 작업을 한 시간 안에 구현할 수 있다. 그렇다면 그 작업은 정말 한 시간짜리일까?

코드만 보면 답은 그렇다고 할 수 있다. 요구사항을 읽고, 화면을 만들고, 오류를 수정하고, 결과물을 전달하는 과정이 놀라울 만큼 짧아졌기 때문이다. 그러나 소프트웨어에는 코드로 적히지 않는 또 하나의 작업이 있다. 무엇을 외부에 맡길 것인지, 무엇을 공개해도 되는지, 누구에게 어떤 권한을 줄 것인지 결정하는 일이다.

이 두 가지는 얼핏 전혀 다른 주제처럼 보인다. 하나는 AI를 활용한 빠른 구현이고, 다른 하나는 채널 이름, 가입 상태, 혜택 제공을 위한 제3자 공유 같은 정보 공개의 문제다. 하지만 둘은 같은 질문을 향한다.

무언가를 더 빠르고 편리하게 만들수록, 우리는 무엇을 더 쉽게 넘겨주게 되는가?

오늘날의 생산성은 단순히 더 빨리 만드는 능력이 아니다. 속도가 만든 결과물이 어떤 데이터, 권한, 정체성 위에 세워졌는지 끝까지 추적하는 능력까지 포함해야 한다.

빠른 구현은 시간을 줄이지만 판단을 대신하지 않는다

바이브 코딩은 자연어로 원하는 결과를 설명하고, AI가 코드와 구조를 제안하도록 하는 방식이다. 개발자가 모든 문법을 직접 작성하지 않아도 되므로 진입 장벽이 낮아지고, 아이디어를 작동하는 화면으로 바꾸는 시간이 짧아진다. 특히 외주 업무처럼 요구사항이 비교적 분명하고 결과를 빠르게 보여줘야 하는 상황에서는 강력한 도구가 된다.

예를 들어 고객이 다음과 같이 요청한다고 해보자.

“회원이 문의를 남기면 관리자가 목록에서 확인하고 상태를 변경할 수 있는 페이지를 만들어 주세요.”

AI는 데이터베이스 구조, 입력 폼, 관리자 화면, 상태 변경 기능까지 한 번에 제안할 수 있다. 이전에는 기획, 설계, 프론트엔드, 백엔드, 테스트가 순차적으로 필요했지만 이제는 한 사람이 짧은 시간 안에 첫 번째 버전을 만들 수 있다.

문제는 첫 번째 버전이 너무 빨리 완성된다는 데 있다. 결과물이 보이면 사람은 자연스럽게 설계를 끝냈다고 느낀다. 하지만 실행되는 코드와 올바른 시스템은 같은 것이 아니다. 화면이 뜨고 버튼이 눌린다고 해서 권한 분리가 적절한 것은 아니다. 데이터가 저장된다고 해서 보관 기간과 삭제 정책이 정해진 것도 아니다. 로그인 기능이 있다고 해서 계정 정보가 안전하게 처리되는 것도 아니다.

AI는 빈 화면을 채우는 데 탁월하지만, 어떤 빈칸을 애초에 만들지 말아야 하는지는 자동으로 결정하지 못한다. 여기서 중요한 구분이 생긴다.

구현의 속도와 판단의 속도는 서로 다른 속도다.

구현은 명령을 받은 뒤 빠르게 진행될 수 있다. 그러나 판단은 맥락을 요구한다. 고객의 개인정보가 포함되는지, 운영자가 정말 모든 데이터를 볼 필요가 있는지, 제3자 서비스에 정보를 전송해도 되는지, 사용자가 그 사실을 이해하고 동의했는지 확인해야 한다. AI가 코드를 몇 분 만에 작성하더라도 이 질문은 몇 분 만에 사라지지 않는다.

공개는 버튼 한 번이 아니라 권한의 재배치다

온라인 서비스에서 공개 설정은 흔히 사소한 안내 문구처럼 취급된다. 채널 이름이 공개적으로 표시되고, 가입 상태가 드러나며, 특정 혜택을 제공하기 위해 제3자와 정보가 공유될 수 있다는 설명을 읽고 동의하는 장면을 생각해보자. 많은 사람은 이를 단순한 이용 절차로 통과한다.

그러나 이런 문구는 실제로 여러 권한의 이동을 포함한다. 사용자는 자신의 식별 정보 일부를 서비스에 보여준다. 서비스는 그 정보를 혜택 제공이나 운영 목적으로 활용할 수 있다. 경우에 따라 제3자가 그 정보에 접근할 수 있다. 즉, 사용자는 단순히 버튼을 누르는 것이 아니라 자신에 대한 정보가 어느 경계를 넘어갈 수 있는지 승인하는 것이다.

이때 핵심은 공개 여부만이 아니다. 공개의 범위, 목적, 기간, 대상이 함께 고려되어야 한다.

예를 들어 채널 이름이 표시되는 것과 가입 상태가 제3자에게 전달되는 것은 서로 다른 정보다. 하나는 공개적인 식별자일 수 있지만, 다른 하나는 특정 서비스와의 관계나 이용 자격을 보여줄 수 있다. 두 정보가 합쳐지면 각각 따로 볼 때보다 더 많은 사실이 추론될 수 있다.

이 현상을 정보의 조합 효과라고 부를 수 있다. 데이터 하나는 무해해 보여도, 여러 조각이 연결되면 개인의 행동, 소속, 관심사, 구매 가능성까지 드러날 수 있다. 이름표와 출입 기록을 따로 보면 단순하지만, 둘을 시간순으로 연결하면 누가 언제 어디에 있었는지 알 수 있는 것과 같다.

AI로 만든 서비스에서도 똑같은 문제가 발생한다. 개발자가 “회원 정보를 저장해 주세요”라고 요청하면 AI는 이메일, 이름, 사용자 식별자, 가입 일시 등을 자연스럽게 데이터베이스에 넣을 수 있다. 하지만 각각의 필드가 정말 필요한지, 내부 운영자 모두가 볼 수 있어야 하는지, 외부 분석 도구로 전송되는지, 로그에 그대로 남는지는 별도의 문제다.

데이터는 저장되는 순간부터 코드보다 큰 생명주기를 갖는다.

수집하고, 저장하고, 조회하고, 공유하고, 보관하고, 삭제하는 모든 과정이 시스템의 일부다. 화면을 완성한 뒤 마지막에 개인정보 안내를 덧붙이는 방식으로는 이 생명주기를 통제하기 어렵다.

생산성의 진짜 비용은 보이지 않는 곳에 있다

빠른 도구가 확산될 때 사람들은 대개 눈에 보이는 이익부터 계산한다. 몇 시간 걸리던 작업이 한 시간으로 줄었다면, 절약한 시간은 곧 생산성 향상으로 간주된다. 하지만 시스템의 비용은 항상 작업 시간에만 나타나지 않는다.

세 가지 비용이 숨어 있을 수 있다.

첫째는 검증 비용이다. AI가 만든 코드가 요구사항을 정확히 반영했는지 확인해야 한다. 정상적인 입력만으로 테스트하면 오류가 보이지 않을 수 있다. 권한이 없는 사용자가 다른 사람의 문의를 볼 수 있는지, 삭제된 계정의 정보가 남아 있는지, 오류 메시지에 민감한 값이 포함되는지 따로 확인해야 한다.

둘째는 설명 비용이다. 고객이나 사용자에게 어떤 정보가 수집되고 왜 필요한지 설명해야 한다. 특히 제3자 공유가 있다면 누가 받는지, 어떤 목적이며, 사용자가 선택할 수 있는지 명확히 전달해야 한다. 설명되지 않은 자동화는 편리할 수 있지만 신뢰를 축적하지 못한다.

셋째는 회수 비용이다. 한번 외부 서비스나 다른 시스템으로 넘어간 정보와 권한을 되돌리는 데 드는 비용이다. 사용자의 데이터가 여러 도구에 복사되고, AI가 만든 코드가 여러 환경에 배포된 뒤에는 최초의 선택을 취소하기가 어려워진다.

이 세 비용은 초기 개발 화면에는 나타나지 않는다. 그래서 빠른 구현은 종종 비용을 줄이는 것이 아니라 비용의 지불 시점을 뒤로 미루는 것이 된다. 나중에 문제가 발생하면 절약한 한 시간보다 훨씬 큰 시간이 들어갈 수 있다.

이를 간단한 식으로 표현하면 다음과 같다.

실제 생산성 = 구현 속도에서 검증 비용, 설명 비용, 회수 비용을 뺀 값

물론 이것은 정밀한 회계 공식이 아니다. 하지만 생산성을 바라보는 관점을 바꾸는 데 유용하다. 코드를 빨리 쓰는 것이 목표가 아니라, 되돌리기 어려운 실수를 적은 비용으로 피하면서 유용한 결과를 내는 것이 목표라는 뜻이다.

가장 좋은 설계는 데이터가 흐르는 길을 먼저 그린다

AI를 이용한 개발에서 가장 유용한 습관은 프롬프트를 정교하게 쓰는 것만이 아니다. 코드를 요청하기 전에 데이터 흐름을 그리는 것이다.

간단한 문의 접수 서비스를 만든다고 하자. 많은 사람은 곧바로 다음과 같이 요청한다.

“문의 폼과 관리자 페이지를 만들어 줘. 회원 이름과 이메일도 저장해 줘.”

더 나은 시작은 다음과 같은 질문 목록이다.

1. 사용자가 반드시 입력해야 하는 정보는 무엇인가?
2. 문의 처리에 필요하지 않은 정보는 무엇인가?
3. 사용자, 운영자, 외부 서비스 중 누가 어떤 정보에 접근하는가?
4. 정보는 언제까지 보관하고 언제 삭제하는가?
5. 제3자에게 전달되는 값은 원래 값인가, 가공된 값인가?
6. 사용자가 공유를 거부해도 핵심 기능을 이용할 수 있는가?

이 질문에 답한 뒤 AI에게 구현을 요청하면 결과물의 질이 달라진다. 단순히 “회원 정보를 저장하라”고 하는 대신, “문의 처리에 필요한 식별자만 저장하고, 운영자 화면에서는 이메일 일부를 가리며, 외부 분석 도구에는 개인 식별이 불가능한 이벤트 값만 전달하라”고 지시할 수 있다.

이것은 AI에게 더 많은 일을 시키는 것이 아니다. 반대로 AI가 임의로 결정할 수 있는 영역을 줄이는 일이다. 좋은 프롬프트는 기능 명세이면서 동시에 권한 명세다.

데이터 흐름을 점검하는 가장 간단한 방법은 네 개의 상자를 그리는 것이다.

수집: 무엇을 받는가?

저장: 어디에 남기는가?

공유: 누구에게 보내는가?

삭제: 언제 없애는가?

이 네 상자 중 하나라도 비어 있다면 구현을 시작하기보다 먼저 그 공백을 채워야 한다. 특히 공유 상자에는 제3자 서비스뿐 아니라 AI 도구도 포함해야 한다. 개발 과정에서 입력한 요구사항, 오류 로그, 데이터 샘플이 외부 시스템에 전송될 수 있기 때문이다. 실제 개인정보를 그대로 넣지 않고 가상의 데이터로 테스트하는 원칙이 중요한 이유다.

속도를 포기하지 않고 안전성을 높이는 실전 순서

안전성을 확보한다고 해서 모든 일을 느리게 해야 하는 것은 아니다. 오히려 순서를 바꾸면 속도와 통제를 동시에 얻을 수 있다.

첫 번째 단계는 위험 분류다. 화면 색상이나 버튼 위치처럼 실패해도 쉽게 고칠 수 있는 요소와, 개인정보 수집이나 권한 설계처럼 한번 퍼지면 회수하기 어려운 요소를 분리한다. 전자는 AI에게 빠르게 맡겨도 되지만, 후자는 사람이 먼저 결정해야 한다.

두 번째 단계는 최소 데이터 설계다. 기능을 위해 필요한 정보만 수집한다. “나중에 쓸 수도 있으니 일단 받자”는 생각은 작은 서비스에서 특히 위험하다. 저장된 데이터는 언젠가 노출될 가능성, 잘못된 접근 가능성, 관리 비용을 함께 만든다.

세 번째 단계는 가짜 데이터로 프로토타입을 만든 뒤 실제 데이터와 연결하는 것이다. AI가 만든 화면과 흐름은 실제 사용자 정보 없이도 대부분 검증할 수 있다. 이 단계를 거치면 기능의 문제와 개인정보의 문제를 분리해서 발견할 수 있다.

네 번째 단계는 권한 테스트다. 최소한 다음 시나리오는 직접 확인해야 한다.

• 일반 사용자가 다른 사용자의 정보를 볼 수 없는가?
• 관리자가 꼭 필요한 정보만 확인하는가?
• 로그와 오류 화면에 이메일, 토큰, 식별자가 노출되지 않는가?
• 공유에 동의하지 않은 사용자의 정보가 외부 서비스로 전달되지 않는가?
• 계정을 삭제했을 때 관련 정보가 실제로 제거되는가?

다섯 번째 단계는 공개 문구를 기능 설계와 함께 작성하는 것이다. 안내문은 마지막에 붙이는 법률 문장이 아니라 시스템이 실제로 하는 일을 설명하는 사용자 인터페이스다. 무엇을 수집하는지, 왜 필요한지, 누구와 공유하는지, 선택하지 않을 경우 어떤 일이 생기는지를 짧고 구체적으로 알려야 한다.

이 순서는 AI의 장점을 훼손하지 않는다. 오히려 AI가 잘하는 일과 사람이 해야 하는 일을 분리한다. AI는 반복 구현과 대안 제시에 강하고, 사람은 책임의 범위와 허용 가능한 위험을 정하는 데 강하다.

Key Takeaways

• 구현 속도와 판단의 속도를 분리하라. AI가 코드를 빨리 만들수록 권한, 보관, 공유에 대한 사람의 판단을 먼저 명시해야 한다.
• 프롬프트를 기능 명세이자 권한 명세로 작성하라. 어떤 데이터를 수집하고 누가 볼 수 있으며 어디로 전송되지 않아야 하는지까지 적는다.
• 데이터 흐름을 네 단계로 점검하라. 수집, 저장, 공유, 삭제 중 설명되지 않은 단계가 있다면 구현을 멈추고 결정한다.
• 실제 개인정보 없이 먼저 검증하라. 가짜 데이터로 화면, 흐름, 오류 처리를 테스트한 뒤 필요한 범위에서만 실제 데이터와 연결한다.
• 생산성을 총시간으로 계산하지 말라. 구현 시간뿐 아니라 검증, 설명, 문제 발생 시 회수에 드는 비용까지 포함해 판단한다.

빠른 코딩의 시대에 경쟁력은 더 이상 코드를 많이 쓰는 능력에만 있지 않다. 무엇을 자동화하고 무엇을 자동화하지 않을지 구분하는 능력, 무엇을 공개하고 무엇을 보호할지 설명하는 능력, 그리고 이미 넘겨준 권한을 다시 거둘 수 있도록 설계하는 능력이 중요해진다.

결국 가장 빠른 팀은 가장 빨리 만드는 팀이 아닐 수 있다. 되돌릴 수 없는 결정을 늦추고, 되돌릴 수 있는 구현만 빠르게 진행하는 팀이 장기적으로 더 빠르다.

한 시간 만에 기능을 만드는 것은 이제 가능하다. 그러나 신뢰를 만드는 데는 여전히 시간이 필요하다. 앞으로의 좋은 개발자는 AI에게 코드를 맡기는 사람이 아니라, AI가 만든 속도가 사람과 데이터의 경계를 무심코 넘어가지 않도록 경로를 설계하는 사람일 것이다.