AI가 쓰는 것은 코드이지 프로젝트가 아닙니다. 가격은 여섯 요소 중 하나입니다. 1분 적합성 점검이 내부 도구를 구매할지, 개발할지, 혼합할지 알려 줍니다.
AI는 코딩을 빠르게 만들 수 있습니다. 프로젝트의 나머지는 귀사 사람들과 파트너의 속도로 진행됩니다. 문제 이해, 프로젝트 주도, 테스트, 연동, 파트너 대기, 교육이 그것이며, 팀이 도구를 쓸지는 여기서 결정됩니다. 업무 흐름이 흔한 것이면 SaaS를 구매하세요. 프로토타입이면 AI로 직접 개발하세요. 운영이 그 도구로 돌아가게 되면 프로덕션용으로 개발을 맡기세요. 자체 AI 코드 팩토리를 운영하는 개발사라면 개발은 끊임없이 진행되고, 엔지니어는 귀사 팀과 함께 문제에 시간을 씁니다.
좋은 개발사도 AI를 쓰므로 코딩은 그곳에서도 빠릅니다. 개발사에 돈을 내는 이유는 AI가 하지 않는 부분입니다. 문제 이해, 프로젝트 주도, 인수, 연동, 변화 관리, 프로덕션 운영을 해 본 사람들이 맡습니다(저희가 AI로 개발하는 방식). 아래 적합성 점검을 써 보세요. 여섯 가지 질문에 1분이면 됩니다. 저희는 운영 소프트웨어를 개발하는 엔지니어링 회사이므로, 이 가이드는 언제 구매해야 하는지, 언제 프로토타입으로 충분한지도 말씀드립니다.
프로젝트 시간은 이제 어디로 가는가
예전에는 코딩이 소프트웨어 프로젝트의 큰 덩어리였습니다. 이제 Claude, ChatGPT, Lovable, Replit, Cursor 같은 AI 도구가 있으면 귀사 팀의 누군가가 프롬프트 하나로 작동하는 코드를 얻을 수 있습니다. 프로젝트의 나머지는 언제나 그랬듯 같은 크기입니다.
코딩은 언제나 일의 작은 부분이었습니다. IDC에 따르면 2024년에 개발자가 애플리케이션 개발에 쓴 시간은 16%였고, 나머지는 요구사항과 테스트 케이스 작성, 보안, 코드 배포 같은 일에 쓰였습니다(IDC, InfoWorld 경유, 2025년 2월 24일).
AI와 코딩 속도에 관한 연구는 결과가 서로 다릅니다. 2023년 실험에서 GitHub Copilot을 쓴 개발자는 JavaScript로 작은 HTTP 서버를 55.8% 더 빠르게 작성했습니다(Peng et al.). 2024년 Google의 시험은 엔지니어 96명을 대상으로 한 기업용 작업에서 약 21% 빨라졌다고 추정했으며, 오차 범위가 큽니다(Google 연구, 2024). METR의 2025년 시험에서는 숙련된 오픈소스 개발자 16명이 AI 도구를 쓰면서 19% 더 오래 걸렸는데, 본인들은 더 빨랐다고 믿었습니다(METR, 2025년 7월). METR은 이제 그 결과를 시효가 지난 것으로 표시합니다. 후속 연구는 2025년 말에는 AI가 그 개발자들의 속도를 높였을 가능성이 크다고 보며, 누가 참여를 선택했는지 때문에 자체 데이터는 그 정도를 보여 주는 “매우 약한 증거일 뿐”이라고 말합니다(METR, 2026년 2월). 이 연구들은 모두 프로젝트 전체가 아니라 개발 작업을 측정합니다. 속도가 크게 빨라져도 줄어드는 것은 한 덩어리뿐입니다.
아래 여섯 덩어리는 귀사 사람들, 파트너, 달력의 속도로 진행됩니다.
문제 이해
개발이든 구매든 그 전에 누군가는 지금 일이 어떻게 돌아가는지 그려 봅니다. 누가 무엇을 하는지, 어떤 데이터로 하는지, 어디서 막히는지입니다. 이 단계를 건너뛰면 도구는 엉뚱한 일을 빠르게 자동화합니다.
프로젝트 주도
누군가는 우선순위를 정하고, 범위를 지키고, 안 된다고 말합니다. AI가 있으면 이 일은 더 어려워집니다. 이제 어떤 아이디어든 금방 추가할 수 있어 보이기 때문입니다.
요구사항과 피드백
“이게 맞나요?”를 묻는 매 차례마다 도구를 쓸 사람들의 시간이 필요합니다. AI는 다음 버전을 몇 분 만에 내놓습니다. 그래도 팀이 써 보려면 오후 한나절이 필요합니다.
테스트와 인수
가동 전에 팀은 실제 사례로 도구를 점검합니다. 지난달의 특이한 주문, 주소가 두 개인 고객, 환불 같은 사례입니다. 그런 사례는 팀 말고는 아무도 모릅니다.
연동과 파트너 대기
회계 소프트웨어나 CRM에 연결하려면 API 접근을 요청하고, 벤더에 티켓을 열고, 회계사가 매핑을 승인하기를 기다려야 합니다. 이는 달력상의 시간이며, 벤더의 대기열은 그쪽 속도로 움직입니다.
변화 관리와 챔피언
사람들에게는 교육이 필요하고, 각 팀에서 첫 질문에 답해 줄 챔피언이 필요하고, 기존 스프레드시트를 끄는 날짜가 필요합니다. 어떤 도구를 고르든 이 부분은 귀사의 몫입니다.
짧은 답: 세 가지 선택지, 각각 유리한 곳이 있습니다
SaaS 구매
유리한 경우 업무 흐름이 다른 회사와 비슷하거나, 라이선스 비용이 작습니다.
- 코딩
- 벤더
- 설정
- 귀사
- 테스트와 인수
- 귀사
- 변화 관리
- 귀사
- 운영
- 벤더
AI로 직접 개발
유리한 경우 프로토타입이나 작은 도구: 사용자가 소수이고, 민감한 데이터가 없고, 하루 멈춰도 괜찮습니다.
- 코딩
- 귀사, AI와 함께
- 설정
- 귀사
- 테스트와 인수
- 귀사
- 변화 관리
- 귀사
- 운영
- 귀사
프로덕션용으로 개발 맡기기
유리한 경우 운영이 그 도구로 돌아가게 되고, 만든 사람이 떠나도 살아남아야 합니다.
개발사가 자체 AI 코드 팩토리를 운영하므로 개발은 끊임없이 진행되고, 엔지니어는 귀사 팀과 함께 문제에 시간을 씁니다.
- 코딩
- 개발사
- 설정
- 개발사, 귀사와 함께
- 테스트와 인수
- 귀사, 개발사와 함께
- 변화 관리
- 귀사
- 운영
- 개발사, 이후 귀사
업무 흐름이 다른 회사와 비슷하면 SaaS를 구매하세요
회계, 급여, 이메일, 채팅, CRM의 기본 기능은 대부분의 회사에서 같은 방식으로 돌아갑니다. 코드, 유지보수, 보안, 가동 시간은 벤더가 맡습니다. 설정, 연동, 교육은 여전히 귀사의 몫입니다.
프로토타입이나 작은 도구라면 AI로 직접 개발하세요
사용자가 소수이고, 민감한 데이터가 없고, 다른 시스템에 아무것도 기록하지 않으며, 하루쯤 멈춰도 피해 보는 사람이 없는 경우입니다. 코드는 빠릅니다. 현황 파악, 테스트, 교육은 본업에 더해 귀사의 몫입니다. 올바른 첫걸음일 때가 많고, 작동하는 프로토타입은 다음 단계를 위한 좋은 명세서가 됩니다.
운영이 그 도구로 돌아가게 되면 프로덕션용으로 개발을 맡기세요
사용자가 늘고, 권한, 실제 데이터, 연동, 가동 시간이 따라오며, 만든 사람이 떠나도 도구는 계속 돌아가야 합니다. 이것이 맞춤형 업무 소프트웨어를 쓸 이유입니다. 자체 AI 코드 팩토리를 운영하는 개발사라면 개발은 끊임없이 진행되고, 엔지니어는 귀사 팀과 함께 문제에 시간을 씁니다. 좋은 개발사는 코드뿐 아니라 현황 파악, 프로젝트 주도, 인수, 인계까지 프로젝트 전체를 맡습니다. 피드백, 테스트, 챔피언 역할은 여전히 귀사 사람들의 몫이며, 코드, 계정, 데이터는 귀사가 소유해야 합니다.
대개는 둘 다: 범용 도구는 구매하고, 핵심 업무 흐름과 연결부는 개발합니다
일상 운영 앱
개발- 승인
- 고객 포털
- 도구 간 동기화
이미 돈을 내고 쓰는 회계, 급여, 이메일, 채팅은 그대로 두세요. 일상 운영 앱과 도구 간 동기화를 개발하세요. 귀사가 다른 회사와 달라지는 부분입니다. 그 레이어가 자라서 백오피스가 그 위에서 돌아가게 되면, 귀사의 프로세스에 맞춘 운영 백오피스가 됩니다. 그다음은 맞춤형 ERP와 패키지 ERP 가이드가 이어받습니다.
가격은 작은 부분입니다: 구매냐 개발이냐를 가르는 여섯 가지
맞지 않거나 떠날 수 없는 저렴한 도구는 가격보다 더 많은 비용이 듭니다. 선택을 가르는 것은 여섯 가지이며, 가격은 그중 하나일 뿐입니다.
적합성: 도구가 귀사 팀과 일하는 방식에 맞춰지는가?
팀이 우회해야 하는 도구는 시간을 잡아먹고, 그 옆에 스프레드시트가 자라납니다. 구매 쪽: 표준 도구가 몇 가지 설정만으로 이미 귀사의 일하는 방식에 맞습니다. 개발 쪽: 팀이 자기 방식으로 일하며, 도구에 맞추다가는 그 방식을 잃게 됩니다.
로드맵 위험: 영영 나오지 않을지 모를 벤더 기능을 기다리는 일
벤더는 고객 대다수가 요청하는 것을 만듭니다. 필요한 기능이 목록에 없다면 기다리거나 우회해야 합니다. 구매 쪽: 지금의 기능으로 충분합니다. 개발 쪽: 벤더가 영영 내놓지 않을지 모르는 기능에 일이 달려 있습니다.
데이터: 어디에 저장되고, 누가 접근하며, 내보낼 수 있는가
어떤 회사는 평판 좋은 벤더의 클라우드라면 어디든 데이터를 둘 수 있습니다. 어떤 회사는 데이터가 어디에 있고 누가 보는지를 직접 정해야 합니다. 계약 전에 데이터를 어떤 형태로 어떻게 꺼낼 수 있는지 확인하세요. 구매 쪽: 평판 좋은 클라우드와 깔끔한 내보내기로 충분합니다. 개발 쪽: 데이터는 귀사가 정한 곳에, 귀사의 통제 아래 있어야 합니다.
종속: 락인, 가격 인상, 벤더의 폐업이나 인수
벤더는 가격을 올리거나, 요금제를 바꾸거나, 인수되거나, 문을 닫을 수 있습니다. 문제는 그때 타격이 얼마나 큰가입니다. 구매 쪽: 다른 도구로 쉽게 옮길 수 있습니다. 개발 쪽: 이 도구를 잃으면 사업이 멈춥니다.
경쟁 우위: 이 프로세스가 귀사가 이기는 방식인가?
고객이 이 일을 처리하는 방식 때문에 귀사를 선택한다면, 다른 모두의 방식에 맞춰 만든 도구는 그 우위를 내주는 셈입니다. 구매 쪽: 프로세스가 다른 회사와 비슷합니다. 개발 쪽: 그것이 귀사가 이기는 방식입니다.
비용: 3년으로 비교하기, 여섯 요소 중 하나
갱신 후 실제로 낼 가격 기준의 구독료 3년 치를, 개발 견적과 유지 비용과 비교하세요. 견적에는 코딩만이 아니라 코드를 둘러싼 프로젝트도 포함됩니다. 구매 쪽: 3년 기준으로 구매가 더 저렴합니다. 개발 쪽: 3년 기준으로 개발이 더 저렴합니다.
구매 또는 개발 적합성 점검
여섯 가지 질문에 1분이면 됩니다. 위의 다섯 가지에, “비용 비교”를 열어 숫자를 넣으면 비용까지입니다. 대신 답해 두는 항목은 없으며, 건너뛴 질문은 중립으로 칩니다. 답은 귀사의 브라우저와 페이지 주소에만 남으므로, 링크를 복사해 동료에게 보낼 수 있습니다.
질문에 몇 가지 더 답해 주세요.
균형
- 적합성미응답
- 로드맵 위험미응답
- 데이터미응답
- 종속미응답
- 경쟁 우위미응답
- 비용미응답
누가 팀을 교육하고, 고장 나면 누가 고치고, 출시 후 누가 소유하는지는 여전히 중요합니다. DIY AI 프로토타입으로 충분한 경우
결론을 내는 방식
- 각 답은 구매 쪽(−1), 중립(0), 개발 쪽(+1) 중 하나이며, 여섯 가지 모두 같은 비중입니다.
- 개발 쪽으로 2 이상: 개발. 구매 쪽으로 2 이상: 구매. 그보다 근소하면: 혼합, 진단으로 시작하세요.
- 답이 세 개 미만이면 아직 결론이 없습니다. 비용은 연간 비용과 견적이 모두 입력되면 계산에 들어갑니다.
결과 읽는 법
- 결론은 한 줄입니다. 각 답은 구매 쪽, 중립, 개발 쪽 중 하나이고, 여섯 가지 모두 같은 비중입니다. 한쪽으로 2 이상 기울면 구매 또는 개발입니다.
- 결정 요인은 이긴 쪽의 요소를 보여 주므로, 답만이 아니라 이유도 확인할 수 있습니다.
- 균형은 모든 요소를 한눈에 보여 줍니다. 각 요소가 어느 쪽으로 기우는지, 어떤 것이 미응답인지입니다.
- 혼합은 정직한 답입니다. 요소들이 양쪽으로 갈리면, 진단이 이를 비용이 산정된 계획으로 바꿉니다. 서면 계획과 첫 시스템의 고정 가격입니다.
AI가 빠르게 만든 것과 그렇지 않은 것
코드를 둘러싼 프로젝트
- 문제 이해
- 테스트와 인수
- 교육과 챔피언
- 연동과 파트너 대기
운영
- 접근과 권한
- 백업
- 데이터 모델
- 모니터링과 가동 시간
- 업그레이드
- 이름을 밝힌 책임자
이제 빠른 것: 첫 버전, 화면, 데모
양식, 대시보드, 작은 앱의 작동하는 첫 버전은 AI 도구로 금방 만들 수 있습니다. 그리고 어떤 문서 명세보다 사람들이 요청하는 바를 잘 보여 줍니다. 그렇게 쓰세요.
여전히 비용이 드는 것: 코드를 둘러싼 프로젝트, 그리고 운영
위의 프로젝트 덩어리가 먼저입니다. 그다음 매일 쓰는 도구에는, 누가 만들었든 매달 다음이 필요합니다.
- 유지보수. 업데이트, 수정, 사람들이 요청하는 작은 변경입니다. 널리 인용되는 경험칙은 운영, 유지보수, 개선이 시스템 수명 주기 비용의 60–80%라고 봅니다(Klotz, 2026, Lientz와 Swanson, 1980 및 후속 연구 인용).
- 보안과 접근. 모두가 자기 계정으로 로그인해 볼 수 있는 것만 보고, 누군가 떠나면 담당자가 접근 권한을 회수합니다.
- 데이터 품질과 데이터 모델. 도구는 각 기록의 한 가지 버전만, 다음 보고서가 읽을 수 있는 형태로 보관합니다.
- 연동. 다른 도구와의 동기화는 실패하면 재시도하고, 실패하면 담당자에게 알립니다.
- 가동 시간. 백업이 있고, 복원을 시험해 봤으며, 도구가 멈추면 누군가 알아챕니다.
- 만든 사람이 떠날 때의 소유권. 코드, 계정, 결정 사항이 다음 사람이 찾을 수 있는 곳에 적혀 있습니다.
DIY AI 프로토타입으로 충분한 경우
귀사의 도구에 대해 답해 보세요. 숫자는 예시이니 상황에 맞게 조정하세요.
- 사용자가 대략 10명 미만인가요?
- 개인, 고객, 재무 데이터가 전혀 없나요?
- 다른 시스템에서 읽기만 하고, 쓰지는 않나요?
- 하루 멈춰도 피해 보는 사람이 없나요?
- 만든 사람이 계속 남아 있나요?
- 고장 나면 고치기보다 다시 만들고 싶은가요?
- 교육 없이 쓸 수 있나요?
- 파트너나 벤더가 부여하는 접근 권한이 필요 없나요?
모두 예라면 프로토타입을 유지하고 돈을 아끼세요. 아니요가 하나 나올 때마다 프로덕션 개발의 견적을 받아 볼 이유가 됩니다.
Sabai가 AI로 개발하는 방식
AI는 저희가 개발하는 방식입니다. 코드는 AI로 작성하고, 납품 과정에도 AI가 함께합니다. 회의는 녹취되고, 결정은 코드베이스에 기록되며, 문서는 최신으로 유지되고, 피드백은 모든 채널에서 모입니다. 저희는 자체 AI 코드 팩토리를 운영하므로 개발은 끊임없이 진행되고, 엔지니어는 귀사 팀과 함께 문제에 시간을 씁니다. 문제를 이해하고, 프로젝트를 주도하고, 피드백과 인수를 거치며, 챔피언을 끌어들이는 일입니다.
저희는 귀사의 도구와 데이터 안에서, 운영을 맡은 분들과 나란히 일합니다. 범위는 귀사의 회의에서 나오고, 매 차례 결과는 실제 사용자에게 가며, 그들의 말이 다음 차례를 정합니다.
저희가 만드는 것은 계속 돌아가도록 만들어집니다. 모두가 자기 접근 권한으로 로그인하고, 백업은 시험을 거쳤으며, 도구는 모니터링되고, 모든 변경은 같은 방식으로 나가며 되돌릴 길이 있습니다. 첫날부터 귀사 계정에 자리 잡고, 결정 사항은 코드 옆에 기록됩니다. 가동 후에는 귀사가 직접 운영하거나 저희가 계속 운영합니다. 유지보수는 선택 사항이며, 코드, 계정, 데이터는 귀사의 것으로 남습니다.
작게 시작하려면 유료 진단 (영어 페이지)을 받으세요. 진단은 서면 계획과 첫 시스템의 고정 가격으로 끝납니다. 필요가 이미 분명하다면 바로 개발에 들어갑니다.
프로토타입이 프로덕션으로 가야 한다는 신호
- 매일 그 도구에 의존하는 사람이 늘어납니다.
- 회계 소프트웨어나 CRM에 데이터를 씁니다.
- 고객이나 직원 데이터를 담고 있습니다.
- 누가 무엇을 볼 수 있느냐는 질문이 나옵니다.
- 고장이 났는데 고칠 수 있는 사람이 한 명뿐이었습니다.
- 다른 곳에 있는 데이터의 두 번째 사본이 되었습니다.
- 어떤 팀이 교육을 받기 전에는 쓰려 하지 않습니다.
이런 신호가 보이면 앞으로의 일은 코드를 둘러싼 프로젝트입니다. 저희는 맞춤형 업무 소프트웨어 작업의 일환으로, 팀이 직접 만든 도구를 프로덕션으로 가져갑니다.
고장 나면 누가 답하는가
결정하기 전에 담당자 이름 쓰기 테스트를 해 보세요. 월요일 아침에 도구가 고장 났을 때 답할 사람이나 회사의 이름과, 그 시간에 드는 비용을 적어 보는 것입니다. 이름을 적을 수 없다면 구매하세요.
이 자리를 채우는 방법은 세 가지입니다.
- 만든 사람이 맡습니다. 본업에 더해서입니다. 그 사람이 떠나는 날을 위한 인계를 계획하세요.
- 귀사가 고용한 개발자. 그 도구에 쓰는 시간을 그 사람의 비용으로 치고, 대신할 수 있는 두 번째 사람도 두세요.
- 유지보수 계약을 맺은 개발사. 그 요금이 적합성 점검의 비용 항목에 더하는 유지 비용입니다. 저희 유지보수는 선택 사항입니다. 저희에게 계속 맡기거나, 교육과 함께 귀사 인력에게 넘기거나, 다른 개발사로 옮길 수 있습니다.
개발을 맡긴다면 떠나는 비용을 낮게 유지하세요
세 가지가 떠나는 비용을 작게 유지하며, 각각 계약 전에 쉽게 확인할 수 있습니다.
- 첫날부터 귀사의 계정. 호스팅, 데이터베이스, 코드는 귀사 명의로 개설하고, 개발사는 게스트로 그 안에서 일합니다.
- 누구나 반복할 수 있는 업데이트. 변경은 매번 같은 자동화 단계로 나가고, 이전 버전은 한 단계 거리에 있습니다.
- 코드 옆에 기록된 결정. 데이터가 왜 이런 형태인지, 동기화가 왜 밤에 도는지가 다음 엔지니어나 귀사의 AI 어시스턴트가 읽을 곳에 적혀 있습니다.
세 가지가 모두 있으면 귀사가 떠나도 도구는 계속 돌아갑니다.
AI 어시스턴트나 에이전트가 들어갈 자리
구매하든 개발하든, 어시스턴트나 에이전트는 별개의 결정입니다. AI 어시스턴트는 누가 물으면 답합니다. Claude나 ChatGPT 같은 어시스턴트를 이미 가진 도구에 연결하면, 팀은 주문이나 고객에 대해 평범한 말로 물을 수 있습니다. 에이전트는 작업을 맡아 해냅니다. 일정에 따라, 또는 데이터가 바뀔 때, 귀사가 정한 권한 안에서입니다. 둘 다 구매한 도구와 개발한 도구 모두에서 작동합니다. 단, 그 도구가 를 통해 다른 소프트웨어에 데이터를 읽게 해 주어야 합니다.
용어 API 애플리케이션 프로그래밍 인터페이스: 소프트웨어가 다른 시스템에 데이터를 요청하거나 일을 시킬 때 쓰는 통로입니다.
저희는 이를 별도의 서비스로 구축합니다. 귀사 데이터 위의 어시스턴트는 AI 통합, 스스로 돌아가는 작업은 AI 에이전트입니다.
자주 묻는 질문
AI가 코드를 쓰는데 왜 소프트웨어 프로젝트는 여전히 몇 달이 걸리나요?
코딩은 프로젝트의 한 덩어리일 뿐이기 때문입니다. 문제 이해, 여러 차례의 피드백, 테스트와 인수, 파트너 대기, 팀 교육은 귀사 사람들과 파트너의 속도로 진행됩니다. 그중 일부는 코딩이 빨라져도 그대로인 달력상의 시간입니다.
소프트웨어 프로젝트에서 실제 코딩은 얼마나 차지하나요?
대부분의 사람이 생각하는 것보다 적습니다. IDC의 조사에 따르면 2024년에 개발자가 애플리케이션 개발에 쓴 시간은 근무 시간의 16%였습니다. AI 연구는 개발 작업을 측정하며, 속도 향상 정도에 대해서는 결과가 서로 다릅니다.
AI가 있는 지금, 내부 도구는 개발하는 편이 구매보다 저렴한가요?
가격은 한 가지 요소입니다. 구독료 3년 치와 개발 견적을 비교한 다음, 적합성, 로드맵 위험, 데이터, 종속, 경쟁 우위를 따져 보세요. 이 가이드의 적합성 점검은 여섯 가지를 모두 1분 안에 해냅니다.
구매냐 개발이냐에서 가격보다 중요한 것은 무엇인가요?
다섯 가지입니다. 도구가 팀의 일하는 방식에 맞는지, 벤더의 로드맵을 기다려야 하는지, 데이터가 어디에 있고 누가 통제하는지, 벤더를 잃으면 얼마나 타격이 큰지, 그 프로세스가 귀사가 이기는 방식인지입니다.
AI가 코드를 쓰는데 왜 개발사에 돈을 내야 하나요?
코드가 프로젝트의 전부였던 적은 없기 때문입니다. 저희는 자체 AI 코드 팩토리를 운영하므로 개발은 끊임없이 진행되고, 엔지니어는 프로젝트의 성패가 갈리는 곳에 시간을 씁니다. 귀사 팀과 함께 문제를 다루고, 프로젝트를 주도하고, 피드백과 인수를 거쳐 사람들이 실제로 쓰게 만드는 일입니다. 가동 후에는 귀사가 직접 운영하거나 저희가 계속 운영합니다. 유지보수는 선택 사항입니다.
저희와 이야기해 보세요
적합성 점검 링크나 직접 만든 프로토타입을 가져오세요. 통화가 끝나면 구매할지, 프로토타입을 유지할지, 프로덕션으로 갈지 알게 됩니다. 저희가 도울 수 없다면 후속 연락은 드리지 않습니다.
30분 무료 상담 예약. 약정 부담 없음. 시간은 직접 고르세요.