비개발자의 AI 앱 배포 후기: 코딩 어시스턴트와 마키나락스 Runway

풍속과 풍향을 넣자 발전량 예측값이 떴습니다. 그 아래에는 입력 조건을 정리한 LLM 코멘트가 붙었습니다. 값을 바꾸면 결과도 바뀌었습니다. 고객에게 보여주고 싶었던 AI 활용 장면이 제 앞에서 실제로 돌아가고 있었습니다.

저는 마키나락스 AI플랫폼사업팀에서 Runway 사업개발을 담당하는 이승준입니다. 고객의 업무와 과제를 듣고, Runway로 어떤 AI 시스템을 구현할 수 있을지 함께 구체화하는 일을 합니다.

개발은 해본 적이 없습니다. 그런 제가 이번에 풍력 발전량 예측 대시보드를 만들어 배포했습니다. Runway 튜토리얼로 학습하고 배포한 모델에 화면과 LLM을 붙여, 누구든 URL로 들어와 쓸 수 있는 형태까지 올렸습니다.

제가 한 일은 셋입니다. 모델을 학습해 배포하는 것, 그 모델과 LLM을 앱에 연결하는 것, 앱을 접속 가능한 서비스로 배포하는 것. 코딩 어시스턴트로 만든 화면은 그중 하나였습니다.

Runway는 AI 개발부터 배포와 운영까지 하나로 묶은 마키나락스의 기업용 AI 플랫폼, AI 운영체제(AI OS)입니다. 이번 작업에서 Runway가 무엇을 대신해 줬는지 적어봤습니다.

“그래서 Runway로 무엇을 만들 수 있나요?”

Runway를 설명하면 고객은 대체로 고개를 끄덕입니다. 그리고 꼭 이 질문이 돌아옵니다. “그래서 Runway 위에서 저희가 실제로 무엇을 만들 수 있는 건가요?”

실험 관리와 모델 배포를 아무리 설명해도, 그 결과가 현업의 화면에 닿는 장면은 잘 그려지지 않습니다. 기능 목록과 업무 사이에 빈칸이 있는 셈입니다.

그 빈칸을 메우려고 고른 것이 풍력 발전량 예측 대시보드입니다. 풍속·풍향·온도 같은 센서값을 넣으면 학습된 모델이 발전 출력을 예측하고, LLM이 입력 조건과 예측값을 문장으로 정리해 줍니다. 화면의 예측값은 kW 단위의 출력이며, 일정 시간 생산한 전력량(kWh)과는 다릅니다.

예측하는 ML 모델과 문장을 쓰는 LLM을 한 화면에 두면, 서로 다른 AI를 업무 목적에 맞게 조합하는 그림이 됩니다.

Runway에서 모델을 학습시키고, 호출 가능한 서비스로 배포했습니다

출발점은 Runway 튜토리얼입니다. 예제 데이터로 발전량 예측 모델을 학습하고 실험 결과를 확인한 뒤, 새 입력에 대한 예측을 받을 수 있도록 배포했습니다. 학습된 모델을 띄워 요청을 받고 결과를 돌려주는 이 단계를 모델 서빙(Model Serving)이라고 합니다. 대시보드는 모델을 호출하는 API 주소, 즉 추론 엔드포인트로 입력을 보내고 예측값을 받아 표시합니다.

튜토리얼을 따라간 것이지만, 이 구간에서 플랫폼이 대신해 준 일이 많습니다. 어떤 데이터를 어떤 설정으로 학습했고 결과가 어땠는지가 실험 기록으로 남습니다. 배포할 모델을 고르면 추론 요청을 받는 서버가 함께 떴습니다. 모델에 맞는 서빙 런타임도 화면에서 고르면 됐습니다.

앱이 모델을 호출하는 경로와, 서빙 환경이 저장소에서 모델 파일을 읽는 경로는 다릅니다. 파일을 읽고 추론하는 일은 서빙 환경이 맡고, 대시보드는 추론 결과만 받아다 씁니다.

예측은 이렇게 준비가 됐습니다. 이제 남은 건 화면과 LLM입니다.

코딩 어시스턴트로 입력부터 결과까지 흐름을 만들었습니다

화면과 연결 로직은 코딩 어시스턴트로 만들었습니다. 원하는 기능을 자연어로 설명하고, 나온 코드를 실행해 보고, 결과를 확인해 다시 요청하는 식입니다.

처음 정리한 건 네 가지였습니다.

• 사용자가 어떤 센서값을 입력하는가
• 예측 모델에 어떤 형식으로 값을 넘기는가
• 받은 예측값을 화면에 어떻게 보여주는가
• LLM에 무엇을 전달해 코멘트를 만들게 하는가

화면을 보면서 입력 항목과 배치를 바꿨고, 예측값 아래에 설명을 넣어 달라고 요청했습니다. 기준은 하나였습니다. 고객이 이 화면을 처음 봤을 때 무엇을 입력해야 하는지 바로 알 수 있는가.

역할은 분명히 나눴습니다. 발전 출력 예측은 학습된 ML 모델이 하고, LLM은 전달받은 입력 조건과 예측값을 읽기 쉬운 문장으로 정리합니다. LLM 코멘트는 결과를 읽는 데 도움을 주는 보조 설명이지 예측 모델의 판단을 보여주거나 예측이 맞았음을 증명하지는 않습니다.

원하는 흐름을 자세히 설명할수록 고칠 곳도 분명해졌습니다. 물론 코드가 의도대로 도는지는 매번 실행해 봐야 했습니다.

예측을 설명하는 LLM도 Runway 안에서 배포했습니다

이 대시보드에는 모델이 두 개가 필요했습니다. 발전량을 계산하는 예측 모델, 그리고 결과를 문장으로 정리하는 LLM입니다. 예측 모델은 튜토리얼로 해결했지만 LLM은 따로 마련해야 했습니다.

외부 LLM API를 쓰지 않고, Runway 안에서 LiteLLM을 활용했습니다. 모델 서빙에서 텍스트 생성용 런타임을 골라 배포하면, 예측 모델과 똑같이 호출 가능한 엔드포인트가 생깁니다. 여러 모델을 한 창구로 부르는 게이트웨이도 함께 있어서, 뒤쪽 모델이 바뀌어도 앱에서 같은 방식으로 요청하면 됐습니다.

이 점이 저에게는 컸습니다. 외부 API 키를 발급받고 결제 수단을 등록하고 데이터 반출 검토를 거치는 절차 없이, 예측 모델과 LLM을 같은 프로젝트 안에 두고 같은 방식으로 호출했습니다.

코딩 어시스턴트가 Runway 위에서 잘 된 이유

코딩 어시스턴트 작업을 할 때 의외였던 건 “Runway에 배포할 수 있는 형태로 만들어 달라”고 했을 때, 대체로 잘 알아듣더라는 것입니다.

Runway가 자체 규격으로 만든 제품이 아니기 때문입니다. 컨테이너 이미지, Helm 차트, REST API 엔드포인트, Kubernetes 자원처럼 이미 표준이 된 방식 위에 얹혀 있고, Gitea·MLflow·Airflow·Keycloak 같은 구성 요소도 업계가 흔히 쓰는 오픈소스입니다.

코딩 어시스턴트가 그 표준을 이미 알고 있습니다. 그래서 Runway에 맞추려고 따로 가르칠 게 별로 없었습니다. 사내에서만 통하는 규격이었다면 저는 규격 설명부터 해야 했을 텐데, 아마 거기서 멈추었을 겁니다.

코딩 어시스턴트로 만든 AI서비스를 Runway에 배포한 이유

이유는 단순합니다. 이미 Runway에서 학습·배포한 모델을 그대로 쓰면서, 새로 만든 앱의 배포와 실행 자원까지 같은 플랫폼에서 관리할 수 있었기 때문입니다.

화면에 예측값이 뜨려면 여러 연결이 맞아야 합니다. 앱은 모델의 입력 형식에 맞춰 요청을 보내고, 응답을 받아 표시하고, LLM 호출 정보도 지정해야 합니다. 여기에 앱을 실행할 환경과 접속 경로가 더해집니다.

저는 앱 코드와 의존성을 컨테이너 이미지로 묶어 저장소에 올렸습니다. Runway에서는 그 이미지로 프로젝트 애플리케이션을 배포하면서 CPU·메모리와 접속 정보를 설정했고, 예측 모델의 추론 엔드포인트와 LLM 호출 정보를 앱에 연결했습니다.

여기서 짚어둘 것이 하나 있습니다. 컨테이너 이미지는 어딘가 올려두어야 Runway가 가져다 실행합니다. 그 저장소가 Runway 안에 이미 있었습니다. 이미지 레지스트리라고 부르는 공간입니다.

개발자에게는 당연한 이야기겠지만, 저에게는 여기가 관문이었습니다. 사내에 저장소가 없으면 외부 레지스트리 계정을 만들거나 인프라팀에 요청해야 하고, 인터넷이 끊긴 환경이면 그마저 어렵습니다. 프로젝트를 만들면 저장소가 딸려 온다는 건, 처음 앱을 배포해보는 사람에게 출발선을 몇 걸음 앞으로 당겨주는 일입니다.

완성된 앱의 최종적인 흐름은 다음과 같습니다.

센서값 입력 → 예측 모델 호출 → 예측값 수신 → 입력 조건·예측값을 LLM에 전달 → 예측값과 코멘트 표시

Runway는 JupyterLab·Code Server 같은 개발 환경을 제공하고, 직접 개발한 앱도 배포 형식만 맞추면 모델·앱 운영 환경에 붙일 수 있습니다.

앱을 만들 때마다 모델 실행 환경을 새로 마련하지 않아도 된다는 저에게 도움이 됐습니다. 준비된 예측 모델을 그대로 쓰면서, 입력과 결과를 어떻게 이어 붙일지에만 집중했습니다.

 

첫 배포는 모델 경로에서 막혔습니다

사실 첫 배포부터 예측이 정상적으로 실행된 것은 아닙니다. 모델 파일은 분명히 있는데, 예측을 실행하는 환경이 그 파일을 찾지 못했습니다. 저장된 위치와 실행 환경이 바라보는 경로가 어긋나 있었습니다.

오류 메시지와 설정을 그대로 전달해 확인할 항목을 좁혔고, 동료의 도움도 받아 설정을 고쳤습니다. 다시 배포한 뒤 예측 요청에 응답이 오는지 확인했습니다.

먼저 할 일은 문제가 생긴 지점을 발라내는 것이었습니다. 화면이 안 열리는 것과, 화면은 열리는데 모델 호출이 실패하는 것은 확인해야 할 대상이 다릅니다. Runway의 배포 관리 화면에서 리소스 상태와 컨테이너 로그를 볼 수 있어 문제 범위를 좁히는 데에 활용했습니다.

접속 URL에서 예측값과 LLM 코멘트를 확인했습니다

설정을 고치고 다시 배포하자 대시보드가 열렸습니다. 풍속과 풍향을 바꿔 넣을 때마다 예측값과 LLM 코멘트가 새로 떴습니다.

몇 번이고 다시 열어 봤습니다. 말로만 오가던 활용 방안이 값을 넣고 결과를 보는 형태가 됐습니다.

지금은 기능과 구조를 설명하면서 직접 만든 결과물을 같이 보여줍니다. 어떤 모델을 썼고, 화면과 어떻게 이었고, 어디서 설정을 고쳤는지까지요.

앱이 늘어나면 모델·자원·권한을 함께 봐야 합니다

이번에 제가 진행한 작업은 튜토리얼 모델을 대시보드에 잇는 데까지였습니다. 여기서 한걸음 나아가, 실제 고객 업무에 적용하는 단계를 생각하면 이다음에 필요한 것도 보입니다.

첫째, 모델을 계속 개선해야 합니다. 새 데이터로 학습한 모델이 기존보다 나은지 비교하고, 어느 버전을 서비스에 올릴지 정해야 합니다. Runway에서는 학습 파이프라인과 실험 관리 도구를 연계하고, 모델 서빙에서 여러 버전을 배포해 요청 비율을 조정합니다.

둘째, 자원과 권한을 같이 관리해야 합니다. 프로젝트 역할은 Gitea·MLflow·Airflow 같은 빌트인 앱 권한으로 자동 매핑되고, 앱 URL로 바로 들어가도 Keycloak 통합 인증이 그대로 걸립니다. 직접 개발해 배포한 앱은 다릅니다. 실행 자원과 배포 권한은 플랫폼이 관리하지만, 앱 화면의 접속 인증과 앱 안의 업무 권한은 따로 설계해야 합니다.

셋째, 폐쇄망에서도 돌아가야 합니다. Runway는 폐쇄망 환경의 AI 개발·운영을 지원합니다. 모델과 패키지, 컨테이너 이미지를 내부에서 쓸 수 있게 준비하고 외부 API 의존성을 점검하면, 인터넷이 차단된 곳에서도 AI 서비스를 구성할 수 있습니다. Runway 제품 소개

덧붙이면, Runway 2.3.0부터는 Code Server에 AI 어시스턴트 익스텐션이 함께 제공됩니다. 이번 작업에 사용한 것은 아니지만, 인터넷이 차단된 환경에서도 플랫폼 안에서 코딩 어시스턴트를 사용할 수 있다는 뜻입니다.

사내에서 앱을 운영할 때 필요한 것 중 상당수는 프로젝트를 만드는 순간 이미 붙어 있습니다.

이번에 다 써본 기능은 아니지만, 프로토타입을 사내 서비스로 넓히게 된다면 쓰게 될 범위입니다.

다음에는 제 업무에 필요한 에이전트도 만들어 봤습니다

풍력 발전량 예측 대시보드 이후에는 사업 공고와 RFP를 수집하는 에이전트도 만들어 봤습니다. LLM이 내용을 분석하고 관심 키워드에 맞는 공고를 추천하도록 구성했습니다. 우선순위가 높은 공고는 카카오톡으로 알림을 받도록 연결했습니다.

최근에는 동료도 자신에게 필요한 에이전트를 만들어볼 수 있도록, 노코드 방식의 에이전트 빌더 프로토타입도 시도하고 있습니다.

시작은 고객에게 보여주고 싶은 대시보드 하나였습니다. 한 번 만들어 보고 나니, 제 업무에서도 직접 바꿔보고 싶은 일이 보이기 시작했습니다.

업무를 아는 사람이 요구사항을 구체화하고, AI 코딩 도구의 도움으로 구현하며, Runway에서 모델과 앱을 연결해 실행하는 것. 제가 이번에 경험한 비개발자의 AI 활용 방식입니다.

여러분의 업무에서는 어떤 아이디어부터 작동하는 앱으로 확인해 보고 싶으신가요?