Hello AI World !

ㅡ 게으른 백엔드 개발자의 반성 ㅡ

동적 CMS 설계

2026년 1월, 본사에 복귀해서 합류한 프로젝트는 “관광 콘텐츠 관리 시스템(Pinlime)”이었습니다. 과거 한 기업에 적용했던 프로젝트를 기반으로 최신 아키텍처 위에서 재작업을 진행 중이었습니다. 수많은 관광지 자원을 일목요연하게 관리하기 위해 JSON 구조를 유연하게 저장하고, UI까지 자유롭게 변형할 수 있는 형태로 설계가 이루어지고 있었습니다.

동적CMS설계

‘설악산’ 같은 자연경관에는 등산로 입구나 통제 기간 등의 필드를, ‘박물관’ 같은 경우 휴관일과 운영시간, ‘식당’에는 브레이크타임과 비건 메뉴 등을 입력할 수 있도록 입력 폼을 실시간으로 렌더링하고, 추후 데이터 구조가 변하더라도 손쉽게 구조를 바꿀 수 있는 교과서적인 시스템이었고, AI를 통해 분석을 해 보아도 크게 군더더기 없이 좋은 점수를 받는 설계였습니다.

사용하기 어려운 시스템

개발자로서 이 구조는 분명히 유연하고 매력적이었습니다. 하지만 관광지 데이터를 입력하기 위해 인풋 필드를 정의하고, 인풋 필드를 모아서 인풋 그룹을 정의하고, 특정 유형의 관광지 카테고리에 알맞은 콘텐츠 모델을 정의해서 관광지에 매핑하고 관광지 데이터를 입력하게 되면서 회의가 들기 시작했습니다.

이 시스템을 직접 설계했기에 인풋필드, 그룹, 모델을 만들고 관광지 데이터를 입력하는 흐름을 알고 있었음에도 불구하고, 이는 수많은 반복작업과 적절한 필드를 찾아서 모델을 정의하는 일에 금세 지쳐버리고 말았습니다. 시스템을 만든 나도 이렇게 지치는데, 시스템을 모르는 현장의 직원들이 이 시스템을 잘 사용할 수 있을까라는 의문이 머릿속을 떠나지 않았습니다.

손쉽게 예상되는 현장 상황

AI-LLM과의 만남

이 시점에서 저는 남들이 다 쓰는 클로드코드나 코덱스도 사용할 줄을 몰랐고, 겨우 LLM 웹사이트에서 코드나 설계에 대한 지식을 물어보고 검토하는 수준이었습니다. 한마디로 AI 문외한이었습니다. AI 엔지니어라고 하면 직접 모델을 만들고 학습시켜서 알파고 같은 제품을 만드는 것이라고 생각하고 담을 쌓고 살고 있었습니다. 따라서 이 시스템이 현장에서 쉽게 사용되도록 하는 방법으로 생각할 수 있는 것은 사용자 인터페이스의 개선 뿐이었습니다.

그 사이 Pinlime에 “AI여행작가” 기능을 추가하기로 결정되었습니다. 이 기능은 Lakey팀에서 작업을 하고, 저는 Pinlime과 Lakey간 데이터 파이프라인 연결에 참여하게 되었습니다. Lakey팀에 데이터를 전달하고, 만들어진 데이터를 화면에 전달하면 되는 일이었지만, 약간의 궁금함과 사용하기 쉬운 인터페이스 구성을 위해 좀 더 자세히 살펴보게 되었습니다.

AI를 시스템 구축에 활용하는 것은 예상외로 단순한 작업이었습니다. 우리가 제미나이 웹사이트에서 LLM에게 질문을 하는 수준에서 크게 벗어나지 않았습니다. 실제로 많은 AI기능들이 “프롬프트 작성 -> LLM 호출 -> 결과 보여주기” 수준에서 이루어지고 있습니다.

• 여행작가 : 관광지데이터 + 에세이 작성 프롬프트 + 요청 = 결과 에세이

• 다국어번역 : 번역대상글 + 번역 프롬프트 + 요청 = 번역결과

AI 적용 난이도

LLM을 이용한 개발에 살짝 들어가 보니, 관광지 소개 텍스트가 있다면 텍스트로부터 스키마에 맞게 JSON으로 결과를 만들어내는 것은 일도 아니었습니다. 이미 콘텐츠 모델에는 우리가 추출해내야 할 정보가 상세하게 정의되어 있으니, 사람이 하나하나 폼에 맞춰서 데이터를 입력하는 대신, 텍스트 입력창에 관광지 텍스트를 떨어뜨리는 것만으로 몇 초 안에 관광지 데이터가 입력 폼에 정확하게 꽂히는 것을 목격할 수 있었습니다..

일단 AI를, 아니 LLM을 이용하는 방법을 알게 되자, 더 많은 것들을 구상하는 단계에 이르렀습니다. 콘텐츠 모델은 필요에 따라 특정 필드가 추가되거나 삭제될 수가 있습니다. 그리고, 그 변경이 이루어지게 되면, 과거 버전으로 만들어진 콘텐츠는 과거 모델 구조를 알아야 데이터를 보여줄 수 있기 때문에 리비전 혹은 스냅샷이란 이름으로 관리를 했습니다. LLM 적용 이전에는 구버전은 구버전대로, 신버전은 신버전대로 보여주는 게 전부였으나, LLM을 적용하면 구버전의 데이터를 신 버전의 데이터로 컨버팅 하는 것도 어렵지 않은 작업으로 예측됩니다.

손은 조금 더 가지만 쉬워진 콘텐츠 마이그레이션

AI-Native로 개발 방식을 전환

물론 예시를 든 것만큼, LLM/LMM을 이용한 어플리케이션 개발이 쉬운 것은 아닙니다. 전통적인 프로그래밍이 “입력->규칙->정해진 출력” 이라면, LLM/LMM을 이용한 개발은 “입력->확률적 추론->가변적인 출력”이기 때문에 결과를 그대로 확정해버리면 문제가 발생할 소지가 큽니다. 할루시네이션 제어, 출력 형식의 구조화, 프롬프트 보안 및 악의적 입력 차단, 민감 정보 유출 방지, 토큰 비용 제어 등 전통적인 프로그래밍과는 다른 고려해야 할 점들이 많이 있습니다.

그럼에도 불구하고 전통적인 소프트웨어 개발 방식에서 LLM/LMM 기반 개발 방식으로 전환해야 하는 이유는 명확합니다. 기존 방식으로 해결하려면 비용 및 시간이 많이 들거나, 구현 자체가 힘들었던 영역을 LLM/LMM은 100% 정확한 결과는 아니더라도 압도적인 효율로 해결해주기 때문입니다.

어쩌면 저는 AI-Native 소프트웨어 개발의 Hello World 단계에 들어서 있는 것 같습니다. Hello World를 찍을 정도의 지식으로 이런 글을 남긴다는 것 자체가 사실 부끄럽기는 합니다. LLM/LMM API를 호출하는 것은 쉽지만, 프롬프트를 제대로 다루고, 전통적인 소프트웨어 공학 기법을 이용해 완벽히 통제하는 것은 다른 차원의 문제입니다. 비록 확률로 움직이는 AI일지라도, 우리가 만드는 '제품'만큼은 언제나 예측 가능한 범위 안에서 신뢰할 수 있게 작동해야 합니다. 그래야 사용자가 안심하고 쓸 수 있기 때문입니다. 이를 제대로 다루는 것이 AI 시대에 우리 개발자들의 역할이라고 생각합니다.

zacca