안녕하세요. 오늘의집 AI Solutions 팀입니다. 우리 팀은 구성원들이 AI를 활용해 업무의 문제를 직접 해결할 수 있도록 필요한 환경과 도구를 만들고 있습니다. AI 인턴 '오집사'와 전사 지식 탐색 시스템 'ORI(오리)'처럼 매일 쓰는 도구부터, 구성원이 직접 만든 앱을 실제 서비스로 올릴 수 있는 플랫폼까지 구축·운영하고 있습니다.

오늘의집은 구성원 누구나 AI를 자유롭게 활용할 수 있도록 지원하고 있습니다. 각자 필요에 맞는 도구를 선택하고, 사용량에 대한 부담 없이 활용하면서 '어떤 도구를 쓸지'보다 '어떻게 문제를 풀지'에 집중할 수 있도록 하기 위해서입니다.

이런 환경에서 개발팀의 생산성은 2배 이상 높아졌습니다. 하지만 한 가지 질문은 여전히 남았습니다.

"코드는 훨씬 빨리 만드는데, 그래서 고객에게 달라진 게 뭐지?"

개발 속도가 빨라지는 것만으로 프로덕트의 변화까지 보장되지는 않습니다. 실제 임팩트로 이어지려면 무엇을 만들어야 하는지부터 정확히 알아야 합니다. 그리고 그 답을 가장 가까이에서 알고 있는 사람은 고객과 업무의 문제를 직접 마주하고 있는 구성원들입니다.

우리는 여기서 한 단계 더 나아가 보기로 했습니다. 문제를 가장 잘 아는 사람이 직접 서비스를 만들고 배포할 수 있다면 어떨까?

그 질문에서 시작해 만든 것이 O!Ligo(올리고)입니다. 올리고는 AI 코딩 도구와 대화하며 앱을 만들고, 필요한 검토를 거쳐 오늘의집 서비스 인프라에 배포할 수 있도록 돕는 플랫폼입니다. 복잡한 규제와 시스템 요구사항, 실제 서비스 트래픽을 고려해야 하는 배포 과정을 플랫폼 안에 담아, 개발자가 아닌 구성원도 아이디어를 실제 서비스로 만들어 볼 수 있도록 했습니다.

이 글에서는 그 과정이 가능하도록 올리고에 어떤 기반과 장치를 마련했는지 이야기해 보겠습니다.

---

1. 만든 앱이 실제 서비스가 되려면

만드는 건 쉬워졌는데

오늘의집에서는 개발자가 아닌 구성원도 AI 코딩 도구로 직접 앱을 만듭니다. 기획자는 업무에 쓸 앱을 만들고, 운영 담당자는 반복 업무를 자동화하는 프로그램을 만듭니다.

하지만 내 노트북에서 돌아가는 앱을 모두가 쓸 수 있는 서비스로 만들려면 준비할 것이 더 있었습니다.

"팀에서 쓸 앱을 하나 만들었는데요, 이거 어디에 올려야 다른 사람도 사용할 수 있어요?"

우리 팀에 자주 들어오던 질문입니다. Lovable로 만든 앱을 회사 도메인에 연결해 배포하고 싶다는 문의도 그중 하나였습니다. 앱을 만든 구성원은 도메인 연결을 누구에게 요청해야 하는지부터 알아봐야 했습니다.

구성원마다 떠오르는 요구와 아이디어를 개발팀이 모두 일정에 담기는 어렵습니다. 좋은 아이디어도 순서를 기다리다 알맞은 때를 놓치곤 합니다.

우리는 팀의 방향을 "아이디어에서 서비스 오픈까지"로 정했습니다. 만드는 일을 돕는 데서 그치지 않고, 만들어진 것이 실제 서비스가 될 때까지 함께 가는 일입니다.

서비스가 되려면 지켜야 할 기준

앱을 만드는 일과 그 앱이 여러 사람에게 쓰이게 하는 일은 다릅니다. 오늘의집 서비스로 운영하려면 회사의 서비스 운영 기준에 맞춰 네 가지 허들을 넘어야 했습니다.

• 인프라. 앱을 올리려면 서버와 접속 주소만 있으면 될 것 같지만, 실제로는 훨씬 복잡합니다. 서버에 환경 변수와 비밀 값을 설정하고, 데이터베이스와 파일 저장소를 연결하고, 내부망과 외부망으로 나뉜 네트워크에 맞춰 접속 경로를 잡아야 합니다. 이 설정을 개발 환경과 운영 환경마다 따로 맞추는 일도 필요합니다.
• 인증. 오늘의집에는 구성원, 입점 파트너, 고객처럼 여러 종류의 사용자가 있고, 사용자마다 로그인 방식과 볼 수 있는 범위가 다릅니다. 앱마다 알맞은 로그인을 붙이고 권한을 나눠야 합니다.
• 데이터베이스. 데이터를 담을 공간만 만들면 되는 일이 아닙니다. 오늘의집 표준 규칙에 맞춰 스키마를 설계하고, 담당 조직의 검토를 거쳐 반영해야 합니다. 앱마다 계정을 따로 발급받고, 개인정보가 담기는 항목은 별도로 보호해야 합니다.
• 보안 검토. 앱이 다루는 정보가 다양한 만큼 확인할 것도 많습니다. 개인정보를 저장하는지, 누가 어디까지 볼 수 있는지, 로그나 파일로 정보가 새어 나갈 곳은 없는지, 회사 밖에 공개해도 되는지를 정보보안팀과 하나하나 점검해야 합니다.

더 큰 문제는 구성원이 무엇을 해야 하는지조차 알기 어려웠다는 점입니다. 이런 허들이 있다는 것부터 몰랐고, 알게 된 뒤에도 어디에 무엇을 요청하고 어떤 순서로 진행할지 하나하나 알아봐야 했습니다. 요청한 뒤에는 각 담당 조직의 답을 기다려야 했습니다.

물론 외부 서비스를 활용하는 방법도 먼저 검토했습니다. Lovable이나 Vercel 같은 외부 서비스로 앱을 만들고 배포하는 방법입니다. 하지만 오늘의집이 요구하는 보안과 운영 기준을 충족하기에는 한계가 있었습니다.

개인정보와 회사의 주요 데이터는 내부 데이터베이스에 저장해야 하고, 회원·상품 정보나 파일 저장소 같은 내부 시스템도 안전하게 연동해야 합니다. 구성원, 파트너, 고객의 로그인 체계를 갖추는 것은 물론, 앱의 관리자와 배포 승인 이력도 추적할 수 있어야 했습니다.

2026년 4월 발생한 Vercel의 보안 사고처럼 외부 서비스에 문제가 생겼을 때도 어떤 앱이 어디에 배포되어 있고 누가 관리하는지 신속하게 확인할 수 있어야 합니다.

아무리 잘 만든 앱이라도 이러한 기준을 충족하지 못하면 실제 서비스로 이어지기 어렵습니다. 그래서 우리는 처음부터 높은 수준의 오늘의집 보안과 운영 기준에 맞춰 앱을 만들고 배포할 수 있는 환경을 마련하기로 했습니다.

2. 올리고는 무엇인가

올리고는 누구나 자기 서비스를 오늘의집에 '올릴' 수 있게 하자는 뜻으로 지은 이름이고, 무지개색 앵무새 마스코트에는 구성원의 말을 알아듣고 어떤 앱이든 만든다는 뜻을 담았습니다. 5월 말 준비를 시작해 7월 초에 정식으로 오픈했습니다.

올리고에서 앱을 만드는 구성원을 'Maker(메이커)'라고 부릅니다. 메이커는 자신이 풀고 싶은 업무나 제품 문제를 가지고 시작합니다. 어떤 기능이 필요하고 누가 쓸지, 어떤 정보를 저장할지는 메이커가 정합니다. 이를 앱으로 구현하는 과정은 올리고가 돕습니다.

대화로 만들고, 안내 따라 배포합니다

초기 계정과 개발 환경을 준비하고 저장소를 내려받은 뒤, AI 코딩 도구를 실행합니다. 그다음부터는 아래 화면처럼 대화로 진행합니다.

예를 들어 메이커가 팀 위키를 만들고 싶다고 요청하면, 올리고는 누가 쓰는지, 어떤 기능이 필요한지, 로그인은 어떻게 할지를 먼저 PRD(제품 요구사항 문서)로 정리해 보여 줍니다. 메이커가 내용을 확인하면 오늘의집 디자인 시스템인 ODS(Ohouse Design System)를 적용한 화면과 서버를 만들고, 기본 동작을 검사한 뒤 실행해 보여 줍니다. 메이커는 글을 써 보고 검색해 보면서 원하는 대로 동작하는지 확인합니다.

배포를 요청하면 먼저 개발 환경에 올리고 주요 기능을 점검합니다. 메이커가 직접 로그인해 확인한 뒤 운영 배포를 요청하면, 담당자의 검토와 승인을 기다립니다. 승인이 확인되면 운영 환경에 배포하고, 팀원들과 함께 쓸 접속 주소를 알려 줍니다.

3. 어떻게 동작하나

올리고는 이렇게 동작합니다

메이커는 해결할 문제와 쓸 사람, 필요한 기능과 사용 흐름을 정리하고, AI와 함께 이를 PRD로 만듭니다. PRD에 담긴 기능과 사용자 시나리오, 완료 기준은 이후 개발과 검증의 기준이 됩니다. 화면은 ODS에 맞춰 설계하고, 메이커는 만들어진 결과를 확인하며 고칠 점을 다시 요청합니다.

AI 코딩 도구는 요구사항을 해석하고, 코드를 쓰고, 검사합니다. 이때 AI가 따르는 올리고의 도구와 규칙을 묶어 Harness(하네스)라고 부릅니다. 앱은 프런트엔드와 백엔드 코드를 함께 갖춘 풀스택 앱으로 만들어집니다.

완성한 앱은 오늘의집 서비스 인프라에 배포합니다. 하네스는 앱을 누가 쓰는지에 따라 알맞은 배포 환경을 고르고, 앱에 필요한 데이터베이스와 파일 저장소, 로그인도 함께 연결합니다. 구성원이 쓰는 앱은 사내에서, 고객에게 제공하는 서비스는 회사 밖에서도 쓸 수 있도록 배포되고, 공개하기 전에 단계별로 확인합니다. 보안 검토, 데이터베이스 변경 검토, 운영 배포 승인처럼 앱의 성격에 따라 필요한 검토도 이 과정 안에서 거칩니다.

내부 API는 정해진 경로로만

앱을 만들다 보면 회원 정보나 상품 정보처럼 오늘의집 다른 서비스의 데이터가 필요할 때가 있습니다. 이런 내부 API를 앱마다 직접 호출하면, 어떤 앱이 무엇을 쓰는지 한눈에 보기 어렵습니다.

올리고 앱은 내부 API를 통제된 연결 계층을 거쳐서만 호출합니다. 그래서 어떤 앱이 어떤 API를 쓰는지 한곳에서 확인하고 관리할 수 있습니다.

하네스, AI가 일하는 방식을 정합니다

AI 코딩 도구는 코드를 잘 쓰지만, 오늘의집의 배포 절차나 데이터베이스 생성 요청 방식, 개발 템플릿 같은 내부 규칙은 알지 못합니다. 우리는 담당 조직마다 흩어져 있던 이런 절차와 정책을 하나씩 꺼내 정리하고, AI가 참고할 규칙과 작업에 쓸 도구, 단계별 절차와 검사 장치를 하네스로 묶었습니다. 하네스의 주요 역할은 다섯 가지입니다.

• 기획·디자인: 메이커의 요청을 PRD와 사용자 시나리오로 정리하고, ODS에 맞춰 화면을 구성하도록 돕습니다.
• 데이터베이스 변경 관리: 필요한 데이터 변경을 명세로 정리하고, 내부 데이터베이스 도구와 연결해 표준 규칙 점검과 검토 절차를 거치도록 합니다.
• QA(품질 검증)·배포 관리: PRD에 담긴 사용자 시나리오를 기준으로 기능을 검사하고, 배포 전에 테스트 결과와 필요한 검토·승인이 갖춰졌는지 확인합니다.
• 개인정보 점검: 어떤 개인정보를 저장하고 누가 볼 수 있는지 확인합니다. 로그나 내려받기 기능처럼 정보가 노출될 수 있는 곳에서는 필요한 마스킹 처리가 적용됐는지도 점검합니다.
• 코드 보안 점검: 로그인과 권한 처리가 적절한지, 사용자가 접근 권한이 없는 데이터까지 볼 수 있는지, 코드에 토큰이나 비밀번호 같은 비밀 값이 노출됐는지 살펴봅니다.

메이커가 이 규칙을 일일이 알 필요는 없습니다. 규칙을 지키는 일은 메이커가 아니라, 작업하는 AI와 하네스가 맡습니다. 메이커가 요청하면 하네스가 요청의 뜻을 읽고 알맞은 작업으로 보내고, 변경이 자기 앱 밖으로 번지지 않도록 자동 검사로 확인합니다. 보안 헤더, 로그인, 환경 설정처럼 어느 앱에서도 빠지면 안 되는 것은 공통 템플릿에 미리 넣어 두었습니다. 메이커가 챙기기 어려운 것은 템플릿이 맡는다는 것이 올리고의 원칙입니다.

위 그림은 데이터베이스 변경 한 건이 반영되는 흐름입니다. 예를 들어 메이커가 신청서에 '연락 가능 시간' 항목을 추가하고 싶다고 말하면, AI는 SQL을 바로 쓰지 않고, 먼저 어떤 형식으로 둘지, 꼭 채워야 하는지, 개인정보인지를 메이커와 정리합니다. 이후 표준 규칙 점검을 거쳐 담당 조직에 변경 요청(PR)을 올립니다.

끝까지 사람이 판단하는 곳

자동화했다고 사람의 검토를 뺀 것은 아닙니다. 사람이 판단할 곳은 그대로 두고, 그 앞뒤의 확인을 하네스가 수행합니다.

• 보안 검토

올리고에서는 사내 구성원용 앱뿐 아니라 고객이 쓰는 서비스도 만들 수 있습니다. 어떤 앱까지 지원할지는 정보보안팀과 함께 정했고, 앱마다 필요한 검토 범위도 앱의 성격에 따라 함께 정합니다. 앱을 만들기 시작할 때 누가 쓰는지, 어떤 정보를 다루는지 같은 앱 정보를 먼저 접수(인테이크*)합니다. 접수를 마치면 검토 요청이 정보보안팀에 자동으로 전달되고, 담당자와 바로 소통하며 검토가 이어집니다. 메이커는 개발·검증 환경에 앱을 올려 둔 상태로 검토를 받으며 지적받은 부분을 고칩니다. 모든 앱은 운영 배포 전에 이 검토를 통과해야 하고, 배포할 때마다 통과 여부를 다시 확인합니다.

• QA 승인

이번 배포에 사람의 QA 승인이 걸려 있으면, 그 승인이 끝나야 운영 배포로 넘어갑니다. QE(Quality Engineering) 조직과 함께 만들고 있는 AI 기반 QA 자동화 플랫폼과의 연계도 준비하고 있어, 앞으로는 더 넓은 범위의 검증을 자동으로 이어 갈 계획입니다.

• 운영 배포 승인

운영 환경에 올릴 때는 요청한 사람과 다른 사람의 승인이 필요한 경우가 있습니다. 승인은 이번 배포에만 유효하고, 다음 배포 때 다시 받습니다.

* 인테이크: 앱을 만들기 전에 누가 쓰는지, 어떤 정보를 다루는지 같은 기본 정보를 등록하는 절차입니다.

4. 무엇이 만들어졌나

지금까지 51개의 앱이 올라왔습니다

올리고로 만든 앱은 올리고 갤러리에 모여 있습니다. 구성원은 동료가 만든 앱을 찾아 바로 열어 볼 수 있습니다.

9월 말 기준으로 24개는 운영 환경에 배포됐고, 27개는 제작 중입니다. 업무 자동화 도구부터 기획전 페이지, 파트너용 도구, 해외 서비스까지 만들어졌습니다.

이런 앱들이 나왔습니다

올리고로 만든 앱은 사내 업무 도구부터 고객과 파트너가 사용하는 서비스까지 다양합니다.

사내에서는 구매 요청과 검토 절차를 한곳에 모은 전자구매솔루션, 채널별 규격에 맞춰 홍보 이미지를 제작하는 SNS 이미지 빌더 등 업무 효율을 높이는 도구가 만들어졌습니다.

고객과 파트너를 위한 서비스도 있습니다. 공간 멘토링 프로그램의 소개·신청 페이지, 개인정보 처리방침을 그림으로 쉽게 설명하는 안내 페이지, 테이블웨어 이야기를 담은 웹매거진 '식탁 위 예술 시리즈', 입점 인테리어 업체를 위한 교육 플랫폼인 사장님센터 아카데미 등이 대표적입니다.

모바일 화면에 맞춘 앱도 다양하게 만들어졌습니다. 고객용으로는 이사·청소·인터넷 신청을 한 번에 할 수 있는 '무빙플래너', 일본 고객이 오늘의집 룸투어 사진을 둘러볼 수 있는 페이지도 있습니다. 특히 룸투어 랜딩 페이지는 올리고를 통해 처음으로 해외에 배포한 앱이기도 합니다.

구성원들이 가볍게 즐기는 앱도 생겼습니다. 사주를 확인하는 '오늘의 사주'부터 동료들과 달리기 기록을 공유하는 '오늘의런'까지, 업무 외 일상에서도 올리고가 활용되고 있습니다.

5. 무엇이 달라졌나

20개가 넘는 조직에서 만들었습니다

제품 디자이너, PO, 마케터, 사업개발 담당자, 정책 운영 담당자, 엔지니어 등 다양한 직무의 구성원이 크리에이터팀과 피플앤컬처를 비롯한 20개가 넘는 조직에서 참여했습니다. 직군은 달라도 모두 같은 방식으로, 대화로 앱을 만들었습니다.

만든 앱 중에는 업무를 돕는 앱도 있지만, 공간 멘토링이나 무빙플래너처럼 고객과 파트너를 직접 만나는 앱도 있습니다. 운영을 시작한 뒤에도 메이커는 필요한 기능을 직접 고치고, 고칠 때마다 같은 검사와 승인을 거쳐 다시 배포합니다.

갈수록 빨라지는 운영 배포

올리고에서는 아이디어를 앱으로 만들어 직접 확인하기까지 오래 걸리지 않습니다. 대부분의 앱은 접수하고 일주일 안에 개발 환경에 올라가, 메이커가 직접 써 볼 수 있었습니다.

그 뒤 운영 환경까지는 보안 검토와 데이터베이스 변경 검토, 배포 승인을 거칩니다. 접수부터 첫 운영 배포까지 걸린 기간은 아래와 같습니다.

접수부터 첫 운영 배포까지는 보통 3주 안쪽이 걸렸습니다. 절차가 자리 잡고 메이커들이 올리고에 익숙해지면서 기간은 계속 짧아지고 있습니다. 8월 이후에 접수한 앱은 대부분 2주 안에, 빠른 앱은 일주일 안에 운영 환경에 올라갔습니다.

빨라져도 기준은 그대로입니다

운영 환경에 올라간 앱 24개는 모두 정보보안팀의 기술 검토와 정책 검토를 마쳤습니다.

앞에서 외부 도구로 만든 앱을 쓰려면 데이터 저장 위치, 내부 시스템 연결, 인증, 관리 주체와 배포 승인 기록을 따로 챙겨야 한다고 이야기했습니다. 올리고에서는 이 네 가지가 앱을 만드는 과정에서 함께 정해집니다.

• 데이터. 앱이 모은 데이터는 모두 서비스용 내부 데이터베이스에 저장합니다.
• 내부 시스템 연결. 내부 API는 통제된 연결 계층을 거쳐 호출하고, 파일은 내부 파일 저장소에 저장합니다.
• 인증. 운영 중인 앱은 모두 사용 대상에 맞춰 로그인 방식이 정해져 있습니다.
• 관리 주체와 승인 기록. 모든 앱에 담당 메이커가 등록돼 있고, 운영 배포를 누가 승인했는지도 기록으로 남습니다. 그래서 보안 공지가 나오면 어떤 앱을 살펴봐야 하는지 바로 찾을 수 있습니다.

6. 올리고는 어디로 가나

올리고는 만들 수 있는 앱의 범위를 넓히고, 터미널이 익숙하지 않은 구성원도 편하게 쓸 수 있도록 계속 다듬어 가고 있습니다. 실제 사용에서 나온 사례로 하네스를 고치고, 특정 AI 모델에 묶이지 않는 구조도 함께 준비하고 있습니다.

마치며: 아이디어에서 서비스 오픈까지

처음 받았던 질문으로 돌아가 보겠습니다. "이거 어디에 올려야 다른 사람도 사용할 수 있어요?" 이제 그 답은 올리고입니다. 올리고와 대화를 이어 가면 오늘의집 서비스 인프라에 앱이 올라가고, 필요한 검토와 승인도 그 과정 안에서 거칩니다.

이 길은 AI Solutions 팀 혼자 만든 것이 아닙니다. 보안 검토 기준을 함께 세워 준 정보보안팀, 데이터베이스 생성 자동화에 힘을 보태 준 DBRE 팀, 배포 과정을 함께 다듬어 준 코어 플랫폼 팀, 그리고 먼저 앱을 만들어 보고 불편한 점을 알려 준 메이커들이 있었기에 가능했습니다.

올리고가 지향하는 것은 AI로 앱 하나를 대신 만들어 주는 도구가 아니라, 구성원이 자기 문제를 직접 풀 수 있게 하는 구조입니다. 누가 쓰고, 어떤 정보를 다루며, 누가 책임지는지에 대한 기준이 사람의 기억에 의존하지 않고 시스템으로 관리될 때, AI가 쓴 코드도 믿고 쓸 수 있는 서비스가 됩니다.

올리고는 쓰일수록 단단해집니다. 한 앱의 검토에서 나온 기준은 다음 앱의 템플릿이 되고, 한 메이커가 막혔던 곳은 다음 메이커를 위한 안내가 됩니다. 20개가 넘는 조직의 메이커 30명이 그 첫걸음을 함께 뗐습니다.

아이디어를 가진 구성원 누구나 서비스 오픈까지 직접 해낼 수 있는 회사. 이것이 올리고가 그리는 모습입니다. 지금보다 10배 많은 앱이 올리고에서 만들어지고, 아이디어를 떠올리는 순간부터 운영까지 AI와 함께 일하는 AI 네이티브(AI Native) 방식이 회사에 자리 잡을 때까지. 더 많은 구성원이 그 길을 걸을 수 있도록 돕겠습니다.