30. 오늘은 개발자가 된다고 말했다.
LLM 활용 현실적 접근법 : 개발은 혁명, 배포는 한계, 프로토타입은?
“오늘도 개발자가 안 된다고 말했다”의 익숙한 풍경
김중철 김수지 작가의 『오늘도 개발자가 안 된다고 말했다』를 읽어보신 적 있으신가요? 이 책은 많은 직장인들에게 뼈아픈 공감을 불러일으키는 상황들을 유머러스하게 그려냅니다. 기획자가 “이 정도 기능은 하루면 만들 수 있을 것 같은데요?“라고 말하면, 개발자는 “그건 기술적으로 불가능합니다”라고 답하는 그 절망적인 순간 말입니다. https://product.kyobobook.co.kr/detail/S000000938510
이런 대화가 반복되는 이유는 무엇일까요? 서로 다른 언어를 사용하기 때문입니다. 기획자는 비즈니스의 언어로, 개발자는 기술의 언어로 이야기하니 영원히 평행선을 달릴 수밖에 없는 것이죠. 마치 한국어만 하는 사람과 독일어만 하는 사람이 대화를 시도하는 상황과 비슷합니다.
하지만 여기서 흥미로운 반전이 시작됩니다. LLM(대규모 언어모델)의 등장으로 이런 소통의 벽에 균열이 생기기 시작한 것입니다. ChatGPT, Claude, Gemini 같은 도구들이 일상화되면서, “우리 회사도 AI로 업무 효율을 높여보자”는 목소리가 곳곳에서 들립니다. 더 나아가 “이제 개발자 없이도 뭔가 만들 수 있지 않을까?“라는 희망적인 상상도 펼쳐지기 시작했습니다.
하지만 막상 시작해보면 예상보다 훨씬 복잡한 현실과 마주하게 됩니다. 특히 IT 전공이 아닌 문과 기반 직장인들에게는 새로운 형태의 벽이 기다리고 있습니다. 시스템 개발 배포 운영이라는 전체 프로세스에서 각 단계마다 전혀 다른 수준의 접근성과 난이도를 보이기 때문입니다.
그렇다면 정말로 “오늘도 개발자가 안 된다고 말하는” 상황에서 벗어날 수 있는 현실적인 방법은 무엇일까요? 이 글에서는 LLM 업무 활용의 솔직한 한계를 살펴보고, 그 속에서 문과생들이 찾을 수 있는 실용적이고 창의적인 해결책을 단계별로 제시해보겠습니다.
1단계 : 개발 영역의 혁명적 변화
프로그래밍 언어에서 자연어로의 패러다임 전환
먼저 개발 단계에서 일어나고 있는 혁명적 변화를 이해해봅시다. 과거 50년간 컴퓨터와 소통하려면 반드시 프로그래밍 언어를 배워야 했습니다. C, Java, Python 같은 언어들 말이죠. 이는 마치 외국인과 대화하려면 그들의 언어를 배워야 하는 것과 같았습니다.
하지만 LLM의 등장으로 이 관계가 완전히 뒤바뀌었습니다. 이제는 컴퓨터가 인간의 자연어를 이해하고, 우리의 의도를 파악해서 프로그램을 작성해줍니다. 이는 단순한 기술적 개선이 아니라, 인간-컴퓨터 상호작용의 근본적 패러다임 전환입니다.
문과생도 쉽게 개발자할 수 있는 시대
예를 들어 마케팅 담당자가 “고객 구매 패턴을 분석해서 차트로 보여주는 웹페이지를 만들어줘”라고 Claude에게 요청하면, 실제로 작동하는 프로그램을 받을 수 있습니다. HTML, CSS, JavaScript 문법을 몰라도 됩니다. 데이터베이스 연결 방법을 공부하지 않아도 됩니다.
이는 글쓰기를 할 줄 아는 사람이라면 누구나 프로그래밍을 할 수 있게 되었다는 의미입니다. 정확한 문법보다는 명확한 의도 전달이 더 중요해진 것이죠.
2단계 : 배포와 운영의 냉혹한 현실
블랙박스 문제의 본질
하지만 개발에서 한 걸음 더 나아가면 곧바로 높은 벽과 마주하게 됩니다. 바로 배포와 운영 단계입니다. 여기서 가장 큰 문제는 LLM이 본질적으로 ‘블랙박스’라는 점입니다.
기존 프로그램은 if-then-else 같은 명확한 논리 구조를 가지고 있어서, 문제가 생기면 코드를 따라가며 원인을 찾을 수 있었습니다. 하지만 LLM은 수십억 개의 매개변수가 복잡하게 얽힌 신경망 구조로 되어 있어서, 왜 특정 답변을 했는지 정확한 이유를 알기 어렵습니다.
문과생이 마주하는 기술적 장벽
더 큰 문제는 배포와 운영에 필요한 기술적 지식이 개발보다 훨씬 복잡하다는 점입니다. 서버 관리, 데이터베이스 최적화, 보안 설정, 모니터링 시스템 구축 등은 여전히 전문적인 IT 지식을 요구합니다.
클라우드 환경에서 API 호출 횟수를 관리하고, 토큰 사용량을 최적화하며, 응답 속도를 모니터링하는 일들은 문과 기반 직장인에게는 여전히 큰 부담입니다. 간단한 프로토타입을 만드는 것과 실제 업무에서 안정적으로 사용할 수 있는 시스템을 구축하는 것 사이에는 깊은 골이 있습니다.
3단계 : 새로운 해결책 - 프로토타입 기반 커뮤니케이션
‘오늘도 개발자가 안 된다고 말했다’의 교훈
여기서 우리는 완전히 다른 접근법을 생각해볼 필요가 있습니다. 김동규 작가의 『오늘도 개발자가 안 된다고 말했다』는 개발자와 기획자 간 소통의 어려움을 생생하게 그려낸 책입니다. 기획자는 “이 정도 기능은 금방 만들 수 있을 것 같은데”라고 생각하지만, 개발자는 “이건 기술적으로 불가능하다”고 답하는 상황이 반복됩니다.
이런 소통 문제의 핵심은 서로 다른 언어를 사용한다는 점입니다. 기획자는 비즈니스 언어로, 개발자는 기술 언어로 이야기하니 서로의 의도를 정확히 파악하기 어려운 것이죠.
하지만 LLM을 활용해서 작동하는 프로토타입을 만들어서 보여주면 상황이 완전히 달라집니다. “이런 기능이 필요합니다”라는 추상적 설명 대신, “이렇게 작동하면 됩니다”라는 구체적 시연이 가능해지기 때문입니다.
프로토타입은 기획자와 개발자 사이의 공통 언어 역할을 합니다. 개발자는 기능 요구사항을 정확히 이해할 수 있고, 기술적 제약사항이나 개선 방안을 구체적으로 제시할 수 있습니다. 시행착오도 크게 줄어들고, 최종 결과물의 품질도 높아집니다.
구체적 활용 사례 시나리오
마케팅 담당자의 고객 분석 대시보드 프로젝트
실제 사례를 통해 이런 접근법이 어떻게 작동하는지 살펴보겠습니다.
A회사의 마케팅 담당자 김팀장은 매월 고객 구매 데이터를 분석해서 보고서를 작성해야 했습니다. 엑셀로 차트를 만들고, 파워포인트에 정리하는 작업이 매번 3-4일씩 걸렸습니다. 자동화된 대시보드가 있으면 좋겠다고 생각했지만, 개발팀에 요청하면 “최소 3주는 걸릴 것 같다”는 답변만 돌아왔습니다.
김팀장은 Claude를 활용해서 직접 프로토타입을 만들어보기로 했습니다.
먼저 요구사항을 정리합니다.
“월별 고객 구매 패턴을 보여주는 웹 대시보드를 만들어주세요. CSV 파일을 업로드하면 자동으로 차트가 생성되고, 주요 지표들을 요약해서 보여주면 됩니다.”
다음은 기능을 구체화하는 단계입니다.
“차트는 월별 매출 추이, 고객 연령대별 구매 현황, 인기 상품 순위 이렇게 3개가 필요합니다. 각 차트 아래에는 전월 대비 증감률도 표시해주세요.”
프로토타입 완성이 완성되었습니다.
Claude가 제공한 HTML/JavaScript 코드로 실제 작동하는 대시보드를 만들었습니다. 실제 데이터를 넣어보니 원하는 형태의 분석 결과가 나왔습니다.
드디어 개발자와 대화가 통합니다.
완성된 프로토타입을 가지고 개발팀에 갔습니다. 이번에는 대화가 완전히 달랐습니다. “아, 이런 UI를 원하시는군요. 데이터 연동은 이 부분을 수정하면 되고, 보안 설정은 이렇게 추가하면 됩니다. 1주일이면 완성 가능할 것 같습니다.”
주의해야 할 요소들
하지만 이런 접근법에도 반드시 고려해야 할 위험 요소들이 있습니다. 특히 보안과 개인정보 보호 측면에서 각별한 주의가 필요합니다.
프로토타입 단계에서는 실제 고객 데이터나 민감한 정보를 사용해서는 안 됩니다. 가상의 더미 데이터나 익명화된 샘플 데이터를 활용해야 합니다. LLM 서비스에 입력된 데이터가 어떻게 처리되고 저장되는지도 반드시 확인해야 합니다.
데이터 품질과 편향 문제
LLM이 생성한 결과물에는 편향이나 오류가 포함될 수 있습니다. 특히 데이터 분석이나 의사결정에 관련된 기능의 경우, 프로토타입 단계에서도 결과의 타당성을 전문가가 검토해야 합니다.
예를 들어, 채용 관련 시스템을 만들 때는 성별이나 나이에 따른 편향이 없는지 반드시 확인해야 합니다. 고객 세분화 분석에서도 특정 집단에 대한 부당한 차별이 발생하지 않는지 점검이 필요합니다.
법적 규제와 컴플라이언스
업종에 따라서는 엄격한 법적 규제를 준수해야 합니다. 금융업의 경우 금융감독원 규정을, 의료업의 경우 의료법 규정을 따라야 합니다. 프로토타입이라고 해서 이런 규제에서 자유로운 것은 아닙니다.
특히 고객 정보를 다루는 시스템의 경우, 개인정보보호법과 신용정보법 등의 제약을 미리 고려해서 설계해야 합니다. 프로토타입 단계에서 이런 요소들을 무시하고 진행했다가, 실제 구현 단계에서 전면 재설계가 필요한 상황을 피해야 합니다.
조만간 다가올 미래에는
앞으로 5년 후에는 지금보다 훨씬 발전된 형태의 프로토타입 기반 협업이 가능해질 것으로 예상됩니다. 단순히 코드를 생성하는 것을 넘어서, AI 에이전트가 비즈니스 요구사항을 이해하고 최적의 기술 스택을 제안하며, 심지어 배포와 운영까지 자동화하는 시대가 올 것입니다.
예를 들어, “우리 회사의 고객 서비스 품질을 개선하고 싶다”고 말하면, AI 에이전트가 현재 고객 불만 데이터를 분석하고, 유사한 업종의 성공 사례를 찾아보며, 맞춤형 솔루션을 제안하는 식입니다. 그리고 그 솔루션을 프로토타입으로 구현해서 실제 테스트까지 진행할 수 있게 될 것입니다.
노코드/로우코드 플랫폼들도 LLM과 결합해서 더욱 강력해질 것입니다. 지금은 미리 정해진 템플릿과 구성 요소를 조합하는 수준이지만, 앞으로는 자연어 요청만으로 완전히 새로운 기능을 만들어낼 수 있게 될 것입니다.
“매주 목요일 오후 3시에 지난주 판매 실적을 정리해서 팀장들에게 슬랙으로 알려주는 봇을 만들어줘”라고 요청하면, 관련된 모든 시스템을 자동으로 연결하고 배포까지 완료해주는 시대가 곧 올 것입니다.
이런 변화 속에서 인간의 역할도 크게 바뀔 것입니다. 기술적 구현보다는 문제 정의와 해결 방향 설정이 더욱 중요해질 것입니다. “무엇을 만들 것인가”와 “왜 만들어야 하는가”에 대한 판단력이 핵심 역량이 되는 것이죠.
문과 기반 직장인들이 가진 업무 맥락 이해력, 사용자 공감 능력, 비즈니스 센스가 바로 이런 미래에서 가장 중요한 자산이 될 것입니다. 기술은 AI가 담당하고, 인간은 방향성과 가치를 제시하는 역할 분담이 이루어질 것입니다.
현실적 접근법으로 AI 시대 준비하기
LLM을 업무에 활용하려는 시도에서 가장 중요한 것은 현실적 접근법입니다. 모든 것을 AI로 자동화하려는 이상보다는, 현재 가능한 범위에서 최대한의 효과를 얻는 것이 더 실용적입니다.
개발 단계에서는 LLM이 제공하는 혁명적 변화를 적극 활용하되, 배포와 운영의 한계는 인정하고 프로토타입 기반 협업으로 해결하는 것이 현명한 전략입니다.
특히 IT 전공이 아닌 문과 기반 직장인들에게는 이런 접근법이 더욱 현실적입니다. 완벽한 기술적 구현을 목표로 하기보다는, 자신의 도메인 전문성과 LLM의 기술적 능력을 결합해서 개발자와의 효과적인 소통 다리를 만드는 것이 핵심입니다.
AI 시대에서 성공하는 사람은 기술을 완벽하게 이해하는 사람이 아니라, 기술을 현명하게 활용해서 실제 문제를 해결하는 사람이 될 것입니다. 그리고 그런 사람이 되기 위한 첫걸음은 바로 프로토타입을 만들어보는 것부터 시작됩니다.
