우리 회사는 AI를 적극적으로 활용하기로 결정했습니다. 코드를 작성해 본 적이 없는 사람들도 AI를 통해 실제 소프트웨어를 구축할 수 있도록 말이죠. 저는 그것이 옳은 결정이라고 생각했고, 지금도 그렇게 생각합니다.

이 결정 뒤에 숨겨진 논리는 완벽해 보입니다. Claude Desktop과 같은 도구들은 비개발자들도 쉽게 접근할 수 있도록 설계되었습니다. 이러한 도구들은 복잡성을 추상화(Abstraction)합니다. 자연어를 작동하는 소프트웨어로 변환해 줍니다. 하지만 이러한 도구들을 유능한 비개발자 앞에 놓았을 때, 뒤따르는 결과는 몇 주간의 혼란, 지저분한 저장소(Repository), 그리고 기능적으로는 작동하는 것처럼 보이지만 불안정한 기반 위에 세워진 아키텍처(Architecture) 결정인 경우가 많습니다.

저는 그 과정을 지켜봐 왔습니다. 그리고 "AI만으로 비개발자가 개발자가 될 수 있을까?"라는 질문에는 '예' 또는 '아니오'보다 더 유용한 답변이 있습니다. '예', 그들은 작동하는 코드를 만들어낼 수 있습니다. '아니오', 그들은 각 구성 요소가 어떻게 결합되는지 이해하지 못한다면 유지보수 가능한(Maintainable) 코드를 만들어낼 수 없습니다.

인프라 현실 점검 (The infrastructure reality check)

비개발자는 실제 개발자의 환경을 갖게 됩니다: GitHub, Python, Node.js, Visual Studio Code, 데이터베이스 서버, 그리고 그 위에 얹어진 AI 어시스턴트까지 말이죠. 전제 조건은 이러한 설정을 갖추는 것이 전투의 대부분을 차지한다는 것입니다. 기대치는 즉각적인 생산성입니다.

실제로 일어나는 일은 다음과 같습니다: Git이 첫 번째 장애물이 됩니다. 브랜치(Branches), 커밋(Commits), 푸시(Pushes), 풀(Pulls), 클론(Clones) — 이 모든 것이 불투명합니다. AI는 변경 사항을 만들고, 커밋을 생성하며, 저장소로 푸시합니다. 하지만 무엇이 왜 커밋되는지 이해하지 못하면, 저장소는 정당한 작업과 뒤섞인 무분별한 커밋들로 가득 차게 됩니다. 예상치 못한 변경 사항이 있어서는 안 될 브랜치에 반영됩니다. 히스토리(History)를 추적하기가 어려워집니다.

그다음은 로컬 환경(Local environment) 문제입니다. 포트 충돌(Port conflicts). 포트가 올바르게 구성되지 않아 UI가 API에 도달하지 못합니다. 서비스를 시작하고, 중지하고, 재시작해야 합니다. 모든 작업 세션은 개발자라면 반사적으로 자동 처리할 15분간의 트러블슈팅(Troubleshooting)으로 시작됩니다. 비개발자는 매번 의식적으로, 처음부터 이 문제를 해결해야 합니다.

멘탈 모델 문제 (The mental model problem)

더 깊은 문제는 기술적인 것이 아닙니다. 비개발자는 API가 무엇인지, 데이터베이스 (Database)가 무엇을 하는지, UI가 어디서 끝나고 백엔드 (Backend)가 어디서 시작되는지 알지 못합니다. 그러한 멘탈 모델 (Mental model)이 없다면, 모든 AI의 제안은 틀린 것을 포함하여 모두 똑같이 그럴듯해 보입니다. 아키텍처 (Architecture)를 볼 방법이 없기 때문에 출력물을 평가할 방법도 없습니다.

AI가 프론트엔드 (Frontend)를 데이터베이스에 직접 연결하라고 제안하면 그대로 구현됩니다. AI가 사용자 비밀번호를 평문 환경 변수 (Plain text environment variables)에 저장하라고 권장하면 그 또한 그대로 실행됩니다. AI가 부주의한 것이 아닙니다. 개발자라면 자동으로 적용했을 제약 조건 (Constraints)들이 포함되지 않은 프롬프트 (Prompts)에 반응하고 있는 것입니다.

여기서 바닥을 짚어봅시다. AI 도구가 해를 끼치는 대신 도움이 되기 위해 비기술자가 이해해야 할 다섯 가지입니다. 이 중 어느 것도 코드를 작성하는 것에 관한 것이 아닙니다. 모두 구성 요소들이 어떻게 서로 관계를 맺는지에 관한 것입니다.

1. 데이터베이스가 무엇인지: 정보는 구조화된 저장소에 존재하며, 고객에게 창고 열쇠를 직접 건네주지 않는 것과 같은 이유로 프론트엔드를 데이터베이스에 직접 연결해서는 안 됩니다.

2. API의 용도: API는 사용자와 데이터 사이의 제어 계층 (Control layer)입니다. 누가 요청하는지 확인하고 규칙을 집행합니다. AI가 API를 건너뛰자고 제안한다면, 그 사실 하나만으로도 무언가 잘못되었다는 것을 알 수 있습니다.

3. 무엇이 어디서 실행되는지: 모든 앱의 일부는 사용자의 기기에서 실행되고, 일부는 서버 (Server)에서 실행됩니다. 사용자의 기기에 있는 것은 사용자가 보고 변경할 수 있으므로, 민감한 모든 것은 반드시 서버에 머물러야 합니다.

4. 버전 관리 (Version control)의 용도: 모든 변경에는 이유가 있어야 하며, 실험적인 작업은 라이브 시스템 (Live system)과 분리되어야 하고, 고객이 사용하는 기능은 계속 작동해야 합니다. 이러한 규율을 잃으면 무엇이 왜 바뀌었는지에 대한 기록을 잃게 됩니다.

5. 비밀 정보 (Secrets)가 머무는 곳: 비밀번호와 키 (Keys)는 코드와 분리되어 있어야 하며, 테스트 설정과 실제 환경은 서로 달라야 합니다. 이를 잘못된 곳에 두면 정보가 유출됩니다.

이 다섯 가지를 배우는 데는 몇 달이 아니라 몇 시간 정도면 충분합니다. 하지만 이것들이 없다면, AI 도구는 값비싼 기술 부채 (Technical debt)를 양산하는 코드 생성기에 불과하게 됩니다.

필요조건이지만 충분조건은 아님

그러한 멘탈 모델 (Mental model)은 더 나은 프롬프트 (Prompt)를 작성할 수 있게 해줍니다. 하지만 그것만으로는 안전한 결과물을 보장할 수 없습니다. 탄탄한 기초를 갖추었더라도, AI를 사용하는 비개발자는 여전히 스스로 내릴 준비가 되지 않은 결정들에 직면하게 될 것이며, 자신의 판단에 맡겨진다면 결국 그 결정들을 내리게 될 것입니다.

답의 나머지 절반은 제약된 환경 (Constrained environment)입니다. 즉, 나쁜 결정이 일어날 가능성을 낮추는 수준을 넘어, 나쁜 결정 자체가 불가능하도록 만드는 가드레일 (Guardrails)입니다. 마이그레이션 (Migration)을 통해서만 변경할 수 있는 스키마 (Schema), 입력을 반드시 검증해야 하는 엔드포인트 (Endpoint), 비밀 정보를 보유할 수 없는 프론트엔드 (Frontend) 등이 이에 해당합니다. 이러한 인터페이스를 구축하는 것은 그 자체로 하나의 과업이며 별도의 논의가 필요한 주제입니다. 여기서 중요한 점은 멘탈 모델 (Mental model)이 우선되어야 한다는 것입니다. 멘탈 모델이 없다면, 아무리 훌륭한 가드레일이라 할지라도 왜 그 가드레일이 존재하는지 이해하지 못하는 사용자와 싸워야 하는 상황이 됩니다.

기술 리더 앞에 놓인 결정

우리 회사가 시작할 때 가졌던 야망은 올바른 것이었습니다. 실제로 중요한 선택은 그다음 단계에서 이루어집니다. 즉, 도구 주변에 얼마나 많은 인프라 (Infrastructure)를 구축할 용의가 있느냐 하는 것입니다. 이 선택은 이분법적이지 않습니다.

가장 저렴한 경로는 가벼운 교육과 함께 가공되지 않은 AI 도구를 사용하는 것입니다. 초기 비용은 저렴하지만 나중에 비용이 많이 듭니다. 작동하는 프로토타입 (Prototype)은 유지보수 부채가 되고, 누군가 모든 것을 제대로 다시 작성할 때까지 기술 부채 (Technical debt)가 눈덩이처럼 불어납니다.

중간 경로는 기초 교육과 제약된 환경을 갖춘 구조화된 도구를 사용하는 것입니다. 초기 비용은 높지만 장기적으로는 낮습니다. 제약 사항이 유지보수 불가능한 패턴이 발생하기 전에 차단해주기 때문에, 결과물은 첫날부터 유지보수가 가능합니다.

세 번째 경로이자 소규모 조직에 종종 가장 효율적인 방법은, 개발을 중앙 집중화된 상태로 유지하고 AI를 생성물을 평가할 능력이 아직 없는 사람들에게 분산시키는 대신, 이미 보유하고 있는 팀의 속도를 높이는 데 사용하는 것입니다.

작동하지 않는 경로는 어떻게든 잘 풀릴 것이라는 희망을 품고 선택하는 첫 번째 경로입니다.

진짜 질문

따라서 진짜 질문은 비개발자가 AI를 통해 개발자가 될 수 있느냐가 아닙니다. 진짜 질문은 당신의 조직이 이를 안전하게 만들어 줄 인프라(infrastructure) — 즉, 기초 교육(foundational training), 제약된 환경(constrained environment), 그리고 그 주변의 배포(deployment) 및 모니터링(monitoring)을 감당할 여력이 있느냐 하는 것입니다. 만약 이를 구축할 수 있다면, 그렇습니다, 비개발자도 AI를 사용하여 유지보수 가능한 소프트웨어를 출시(ship)할 수 있습니다. 만약 구축할 수 없다면, 개발을 중앙 집중화(centralized)된 상태로 유지하고 기존 개발자들의 속도를 높이는 것이 더 낫습니다.

다른 것은 하지 않더라도, 이것만은 하십시오: 어떤 AI 도구를 지급하기 전에, 몇 차례의 집중적인 세션을 통해 멘탈 모델(mental model)을 먼저 훈련시키십시오. 다섯 가지 개념과 당신의 시스템에서 가져온 구체적인 사례를 활용하십시오. 이 투자는 즉각적인 보상을 가져다줍니다. 왜냐하면 그 이후에 사용자가 작성하는 모든 프롬프트(prompt)가 더 나은 프롬프트가 되기 때문입니다. 그들은 입력 유효성 검사(input validation)가 선택 사항이라고 가정하는 대신 이를 요청할 것입니다. 자격 증명(credentials)을 하드코딩(hardcoding)하는 대신 필요한 환경 변수(environment variables)의 이름을 명시할 것입니다. 모든 것을 서로 연결하는 대신 엔드포인트(endpoints) 단위로 생각할 것입니다.

AI는 이미 존재하는 것을 증폭시킵니다. 만약 사용자가 기초를 이해하지 못한다면, AI는 그 격차를 그들이 출시하는 시스템 속으로 그대로 증폭시켜 전달합니다.

https://unlockedconsulting.ai