RFP를 올바르게 실행하는 방법: 웹 개발 및 디지털 프로젝트를 위한 완전 가이드

나는 RFP 테이블의 양쪽에 서본 적이 있다. 에이전시로서 수백 개의 RFP에 대응했다. 컨설턴트로서 회사들이 RFP를 작성하도록 도왔다. 그리고 대부분의 가이드에서 말하지 않는 것이 바로 이것이다: 대부분의 RFP는 끔찍하다. 모든 공급업체가 동일한 일반적인 피치로 대응할 정도로 모호하거나, 실제로 최고의 것을 구축할 팀을 실수로 제거할 정도로 너무 규범적이다.

이 가이드는 2026년 웹 개발 및 디지털 프로젝트에 맞춘 7가지 구체적인 단계에서 전체 RFP 프로세스를 다룬다. 헤드리스 CMS 구축, Next.js 마이그레이션 또는 전체 플랫폼 재설계를 조달하고 있든 이 단계들은 가장 저렴한 입찰가가 아닌 올바른 파트너를 실제로 찾을 수 있는 프로세스를 실행하는 데 도움이 될 것이다. 그리고 이미 필요한 것을 알고 있고 건너뛰고 싶다면 RFP를 제출하면 우리가 도와드리겠다.

목차

RFP란 무엇이며 언제 실제로 필요한가?

RFP -- 제안 요청 -- 은 프로젝트 요구사항을 설명하고 공급업체에게 업무에 접근하는 방법, 비용이 얼마인지, 그리고 왜 자신들이 올바른 적합인지 설명하는 제안서를 제출하도록 초대하는 공식 문서이다.

하지만 실제 질문은 이것이다: 실제로 RFP가 필요한가?

$50K 미만의 프로젝트의 경우, 정식 RFP 프로세스는 종종 가치보다 더 많은 마찰을 만든다. 문서를 작성하고 응답을 관리하고 제안서를 채점하는 데 몇 주를 보낼 수 있지만, 3번의 견고한 발견 통화를 하고 결정을 내릴 수 있었다. RFP는 다음과 같은 경우에 적합하다:

  • 프로젝트 예산이 $75K-$100K를 초과하는 경우
  • 여러 내부 이해관계자가 공급업체 선택에 동의해야 하는 경우
  • 조달 또는 규정 준수에서 문서화된 선정 프로세스가 필요한 경우
  • 올바른 기술 접근 방식이 확실하지 않은 경우 (헤드리스 CMS 대 모놀리식, Next.js 대 Astro 등)
  • 3-4개 이상의 공급업체를 공정하게 비교해야 하는 경우

마케팅 팀이 현대적인 스택에서 빠른 사이트만 필요하다면 RFP를 건너뛰고 직접 연락하자. 진심이다. 최고의 에이전시는 종종 RFP를 완전히 건너뛴다. 왜냐하면 이 프로세스는 품질 구축자보다 대량 응답자를 선호하기 때문이다.

그렇긴 하지만, RFP가 실제로 필요할 때는 잘 실행하는 것이 매우 중요하다. 자세히 살펴보자.

단계 1: 솔루션 전에 문제 정의하기

이것이 80%의 RFP가 잘못되는 곳이다. 팀들은 왜 이 프로젝트를 수행하고 있는지 명확하게 설명하지 않고 기능 및 기술 요구사항 목록으로 바로 건너뛴다.

RFP 문서의 단 한 줄도 작성하기 전에 내부 이해관계자들을 한 방에 모으고 (또는 줌 통화로, 솔직하게) 이 질문들에 답하자:

비즈니스 컨텍스트 질문

  • 현재 사이트/플랫폼에서 무엇이 깨져있는가?
  • 런칭 후 12개월이 지난 성공은 어떤 모습인가?
  • 이 프로젝트가 움직여야 할 3가지 측정 가능한 KPI는 무엇인가?
  • 하드 예산 범위는 얼마인가? (예, RFP를 작성하기 전에 이를 알아야 한다.)
  • 마감일은 언제이며, 그것이 실제인지 아니면 열망적인지?

기술 발견 질문

  • 새 솔루션이 통합해야 할 시스템은 무엇인가? (CRM, ERP, PIM, 분석)
  • 기존 기술 제약이나 선호도가 있는가?
  • 런칭 후 누가 사이트를 유지보수할 것인가?
  • 팀의 기술적 편안함 수준은 어느 정도인가?

우리는 지난해 금융 서비스 클라이언트와 함께 이를 다뤘다. 그들의 RFP는 200개의 요구사항을 나열했지만 비즈니스 문제를 한 번도 설명하지 않았다. 그것에 대응한 모든 에이전시는 아무도 "성공"이 실제로 무엇인지 이해하지 못했기 때문에 다른 것을 제안했다. 이는 기술적으로는 준수하지만 전략적으로는 쓸모없는 제안서의 레시피다.

전문가 팁: 전체 RFP 전에 1페이지 프로젝트 브리프를 작성하자. 신뢰할 수 있는 1-2명의 자문가 또는 공급업체와 공유하여 gut check를 받자. 초기 단계에 맹점을 파악할 수 있다.

단계 2: RFP 문서 작성하기

이제 실제 문서를 작성할 준비가 되었다. 8-15페이지 사이로 유지하자. 그것보다 길면 솔루션을 과도하게 지정하거나 아무도 읽지 않는 필러를 포함하고 있는 것이다.

여기 내가 추천하는 구조다:

필수 RFP 섹션

1. 회사 개요 (1페이지)
   - 당신이 누구인지, 당신이 무엇을 하는지, 당신의 청중
   - 현재 기술 스택 및 플랫폼

2. 프로젝트 배경 (1-2페이지)
   - 이 프로젝트가 존재하는 이유
   - 현재 무엇이 작동하지 않는가
   - 비즈니스 목표 및 KPI

3. 작업 범위 (2-4페이지)
   - 기능 요구사항 (무엇을 해야 하는가)
   - 콘텐츠 및 디자인 기대사항
   - 통합 요구사항
   - 성능 및 접근성 표준
   - 47페이지 기능 매트릭스가 아님

4. 기술 환경 (1페이지)
   - 기존 시스템 및 제약
   - 호스팅 선호도 또는 요구사항
   - 보안 및 규정 준수 필요사항

5. 제안 요구사항 (1-2페이지)
   - 응답에서 원하는 것
   - 포맷 및 길이 지침
   - 답변할 구체적인 질문
   - 요청된 사례 연구 또는 참조

6. 평가 기준 (0.5페이지)
   - 제안서를 채점하는 방법 (공유하자!)
   - 기준의 가중치

7. 타임라인 및 프로세스 (0.5페이지)
   - RFP 응답 마감일
   - Q&A 기간 상세사항
   - 선정 타임라인
   - 예상 프로젝트 시작 날짜

8. 예산 범위 (예, 이를 포함하자)
   - 상한선이 아닌 현실적인 범위

예산 투명성 논쟁

알다. 예산을 공유하는 것은 포커에서 카드를 보여주는 것처럼 느껴진다. 하지만 어쨌든 이렇게 해야 하는 이유는 다음과 같다.

예산을 공유하지 않으면 세 가지가 일어난다:

  1. 최고의 공급업체는 프로젝트가 그들의 시간을 기울일 가치가 있는지 알 수 없다
  2. 비교하기 불가능한 매우 다른 범위의 응답을 받는다
  3. 품질이 낮은 공급업체는 저가로 입찰하여 이기고, 그 다음 change order로 당신을 죽인다

2025년 Hinge Research Institute 연구에 따르면, 전문 서비스 회사의 68%가 예산 범위를 포함하는 RFP를 선호한다. 정확한 숫자를 제공할 필요는 없다. "$150K-$250K"와 같은 범위는 공급업체에게 적절하게 범위를 정할 수 있을 만큼 충분히 알려준다.

만약 현재 RFP 문서를 작업 중이고 전문가의 눈을 원한다면 RFP를 우리에게 보내고 올바른 파트너를 끌어들이기 위해 설정되어 있는지에 대한 정직한 피드백을 제공할 것이다.

단계 3: 공급업체 단축 목록 구축하기

RFP를 20개의 공급업체에 전송하지 말자. 그것은 모두의 시간, 당신 포함한 시간 낭비다. 제안서에 빠져 그들 중 누구도 받을 자격이 있는 주의를 주지 않을 것이다.

4-6개의 공급업체를 목표로 하자. 그 목록을 구축하는 방법은 다음과 같다:

자격 있는 웹 개발 공급업체를 찾을 수 있는 곳

소스 장점 단점
Clutch.co / G2 검증된 리뷰, 기술 스택별로 필터링 유료 순위는 결과를 왜곡할 수 있다
동료로부터의 추천 사전 심사됨, 정직한 피드백 네트워크에 제한됨
컨퍼런스 연사 깊은 전문성 신호 가능하지 않을 수도 있다
포트폴리오 검토 실제 작업 품질 확인 시간 집약적 연구
에이전시 디렉토리 (Sanity, Contentful, Shopify 파트너 목록) 플랫폼별 특화 전문성 그 플랫폼에 편향됨

헤드리스 웹 개발 구체적으로, 당신은 실제로 당신의 대상 스택에서 프로덕션 사이트를 배포한 공급업체를 원한다. 헤드리스 CMS 접근 방식을 고려 중이라면 입증된 헤드리스 CMS 개발 경험과 Next.js 또는 Astro의 구체적인 프레임워크 전문성을 가진 에이전시를 찾자.

사전 적격 심사 기준

RFP를 보내기 전에 빠른 선별을 수행하자:

  • 지난 18개월 동안 유사한 것을 구축했는가?
  • 팀 규모가 당신의 프로젝트에 적절한가?
  • 측정 가능한 결과가 있는 관련 사례 연구가 있는가?
  • 초기 소통에서 반응이 있는가? (이는 많은 것을 말해준다.)

단계 4: Q&A 기간 분배 및 관리하기

단축 목록의 공급업체에 명확한 타임라인과 함께 RFP를 보내자. 이 속도를 추천한다:

  • 0일: RFP 배포
  • 3-5일: 선택적 공급업체 브리핑 통화 (30분, 모든 공급업체 함께 또는 별도)
  • 7일: 작성된 질문의 마감일
  • 10일: 컴파일된 Q&A가 모든 공급업체로 전송됨 (익명화됨)
  • 21-28일: 제안서 마감일

Q&A 기간은 중요하고 자주 엉망된다. 다음은 규칙이다:

Q&A 모범 사례

  1. 모든 질문을 컴파일하고 모든 공급업체와 답변을 공유하자. 사적인 사이드 채널이 없다. 한 공급업체가 훌륭한 명확화 질문을 하면 모두 그 답변을 받을 자격이 있다.

  2. 질문 자체에 주의하자. 공급업체의 질문의 질은 그들의 제안서보다 그들의 전문성에 대해 더 많이 말해준다. 당신의 콘텐츠 마이그레이션 전략, 분석 설정 또는 배포 워크플로우에 대해 묻는 공급업체는 실제 작업에 대해 생각하고 있다. 질문을 하지 않는 공급업체는 거만하거나 주의를 기울이지 않고 있다.

  3. 당신이 모르는 것에 대해 정직하자. 공급업체가 "예상 월간 트래픽은 얼마인가?"라고 물었지만 그 숫자가 없다면 그렇게 말하자. 공급업체는 모호함을 처리할 수 있다. 거짓 정확성은 처리할 수 없다.

  4. 마감일을 유지하자. 공급업체가 제안 마감일을 놓칠 수 없다면, 그들은 프로젝트 마감일을 어떻게 처리할지에 대해 신호하고 있다.

단계 5: 채점 행렬로 제안서 평가하기

이것이 대부분의 팀이 날개짓을 하고 편향이 들어오는 곳이다. 단일 제안서를 읽기 전에 채점 행렬을 구축하자.

여기 나는 수십 개의 평가에 사용한 가중 채점 모델이다:

기준 가중치 점수 (1-5) 가중 점수
기술 접근 및 아키텍처 25% -- --
관련 경험 및 사례 연구 20% -- --
팀 구성 및 가용성 15% -- --
프로젝트 관리 방법론 10% -- --
타임라인 및 마일스톤 10% -- --
가격 책정 및 가치 15% -- --
문화적 적합성 및 소통 스타일 5% -- --
합계 100% -- --

제안서를 실제로 채점하는 방법

3-5명의 검토 패널을 소집하자. 최소 한 명의 기술 담당자, 한 명의 비즈니스 이해관계자, 그리고 일일 프로젝트 소유자를 포함하자. 모든 사람이 논의하기 전에 독립적으로 채점하게 하자.

이 좋은 신호들을 찾자:

  • 공급업체가 당신의 RFP에서 뭔가에 대해 반박했다 (이는 그들이 비판적으로 생각하고 있다는 의미다)
  • 모든 것을 한 번에 약속하는 대신 분할된 접근 방식을 제안했다
  • 정직한 위험 평가를 포함했다
  • 그들의 사례 연구는 스크린샷이 아닌 메트릭을 포함한다
  • 그들이 특정 기술을 선택한 이유를 설명했다, 단지 무엇을 사용할지만 아니라

그리고 이 빨간 깃발들:

  • 당신의 특정 프로젝트를 참조하지 않는 복사-붙여넣기 보일러플레이트
  • Q&A 기간 동안 질문 없음
  • 다른 모든 제안서보다 훨씬 낮은 가격 (나중에 change order에서 대가를 치를 것이다)
  • 마일스톤 세부사항이 없는 모호한 타임라인
  • 우선순위가 없는 "모든 것을 할 수 있다"

단계 6: 최종 진출자 발표 및 기술 검토 실시하기

2-3명의 최종 진출자로 좁혀가자. 그들을 발표에 초대하되, 단지 슬라이드 덱으로 당신에게 달려가도록 하지 말자. 세션을 구조화하여 실제로 뭔가를 배워보자.

권장 최종 진출자 세션 포맷 (90분)

0-15분:   공급업체는 그들의 접근 방식을 발표한다 (짧게 유지)
15-45분:  당신의 개발 팀과 기술 심화
45-60분:  시나리오 기반 질문 (아래 참조)
60-75분:  팀 소개 (실제로 작업할 사람을 만나자)
75-90분:  개방형 Q&A

실제 능력을 드러내는 시나리오 기반 질문

단지 "당신의 프로세스에 대해 말해달라"고 물어보지 말자. 그들에게 상황을 제공하자:

  • "우리 CEO가 스테이징 사이트를 보고 런칭 2주 전에 홈페이지를 완전히 재설계하길 원한다. 당신은 이를 어떻게 처리하는가?"
  • "우리는 프로젝트 중간에 레거시 CMS API가 우리가 가정했던 데이터를 노출하지 않는다는 것을 발견한다. 당신의 접근 방식은 무엇인가?"
  • "런칭 후 트래픽이 바이럴 순간 때문에 10배 스파이크한다. 당신의 아키텍처가 이를 어떻게 처리하는지 설명하자."
  • "당신 측의 중요한 팀 멤버가 프로젝트를 떠난다. 당신의 연속성 계획은 무엇인가?"

이 질문들은 팀이 압박 상황에서 실제로 어떻게 작동하는지 드러낸다. 누구나 이상적인 프로세스를 설명할 수 있다. 당신은 그들이 지저분한 현실을 어떻게 처리하는지 알고 싶어한다.

참조 확인

이를 건너뛰지 말자. 각 최종 진출자에게 지난 12개월 내에 완료된 프로젝트의 2-3명의 클라이언트 참조를 요청하자. 전화할 때 물어보자:

  • 프로젝트가 예산 내에서 왔는가? 그렇지 않으면 왜인가?
  • 그들은 의견 차이나 범위 변경을 어떻게 처리했는가?
  • 다시 그들을 고용하겠는가?
  • 개선할 수 있는 한 가지는 무엇인가?

그 마지막 질문이 가장 드러나는 것이다. 참조가 단 하나도 이름을 지을 수 없다면, 그들은 당신과 정직하지 않다.

단계 7: 협상, 선정 및 온보딩하기

당신은 공급업체를 선택했다. 이제 시작 전에 관계를 파괴하지 않으면서 거래를 종료하자.

계약 협상 팁

  • 순전히 가격으로 협상하지 말자. 비용을 줄여야 한다면 범위를 줄여라. 여백을 짜내는 것은 모서리 자르기로 이어진다.
  • Change order 프로세스를 미리 정의하자. 추가 요청은 어떻게 가격이 책정되는가? 승인 임계값은 무엇인가?
  • IP 소유권을 명확히 하자. 최종 제품을 소유해야 한다. 공급업체는 일반적으로 자신의 독점 도구 및 프레임워크에 대한 권리를 유지한다.
  • 전달물에 연결된 지불 마일스톤을 설정하자. 달력 날짜가 아니다. 킥오프에서 20%, 디자인 승인에서 30%, 개발 완료에서 30%, 론칭에서 20%와 같이.
  • 성과 벤치마크를 계약에 포함하자. Core Web Vitals 목표, 가동시간 SLA, 그리고 접근성 표준 (2026년에는 최소 WCAG 2.2 AA).

새 공급업체 온보딩하기

처음 2주는 전체 프로젝트의 톤을 설정한다. 이를 준비하자:

  • 그들이 필요로 할 모든 시스템 및 계정에 대한 접근
  • 실제 의사결정 권한이 있는 지정된 내부 연락처
  • 브랜드 가이드라인, 콘텐츠 자산 및 디자인 파일
  • 목표, 소통 캐던스, 그리고 에스컬레이션 경로를 다루는 킥오프 회의 의제

200페이지 요구사항 문서를 건네고 사라지지 말자. 최고의 프로젝트는 파트너십이고, 그것은 1일차에서 시작된다.

웹 개발 프로젝트를 위한 RFP 타임라인 템플릿

여기 중급-대형 웹 개발 RFP 프로세스를 위한 현실적인 타임라인이다:

단계 기간 누적
내부 요구사항 수집 2-3주 3주
RFP 문서 작성 1-2주 5주
공급업체 단축 목록 1주 6주
RFP 배포 + Q&A 1주 7주
공급업체 응답 기간 3주 10주
제안서 평가 1-2주 12주
최종 진출자 발표 1주 13주
참조 확인 + 결정 1주 14주
계약 협상 1-2주 16주
총 RFP 프로세스 14-16주 --

예, 프로젝트가 시작되기도 전에 3-4개월이다. 이것이 내가 이전에 말한 이유다: 프로젝트가 작을 정도라면 정식 RFP를 건너뛰자. 투자가 그것을 정당화하는 프로젝트의 경우, 이 타임라인은 현실적이고 급하는 것은 나쁜 결과로 이어진다.

최고의 공급업체를 놓치게 하는 일반적인 RFP 실수

RFP에 대응한 지 몇 년이 지난 후, 여기 내가 공급업체 쪽에서 가장 자주 보는 실수들이다:

1. 예산을 공유하지 않는 것. 나는 이미 이 북을 쳤지만, 반복할 가치가 있다. 예산 범위가 없다 = 모두를 위한 추측 게임.

2. Spec-work를 요구하는 것. 공급업체에게 RFP 응답의 일부로 목업, 와이어프레임 또는 기술 프로토타입을 만들도록 요청하는 것은 무료 작업을 요청하는 것이다. 좋은 에이전시는 거절할 것이다. 당신은 절망적이거나 유능하지 않은 공급업체로 끝날 것이다.

3. 기술을 과도하게 지정하는 것. 진정한 기술 제약이 없다면, 스택을 지정하지 말자. 공급업체에게 솔루션이 무엇을 해야 하는지 말하고 구축 방법을 권장하도록 하자. 당신은 Astro가 React를 의무화하는 RFP라면 콘텐츠가 많은 사이트에 Next.js보다 더 나은 적합이라는 것을 발견할지도 모른다, 하지만 당신은 절대 그것을 배우지 못할 것이다.

4. 비현실적인 타임라인. 공급업체에게 RFP가 7일 내에 기한이라고 말하는 것은 당신이 그들의 시간을 소중히 여기지 않거나 이미 누군가를 선택했고 이것은 체크박스 연습이라는 신호를 보낸다. 3주는 신중한 응답의 최소값이다.

5. 위원회 마비. 12명이 제안서를 평가하는 것은 아무도 결정에 책임을 지지 않는다는 것을 의미한다. 평가 패널을 작게 유지하고 한 사람에게 최종 권한을 주자.

6. 문화적 적합을 무시하는 것. 가장 저가의 입찰자와 가장 인상적인 포트폴리오는 여전히 함께 작업하기 악몽이 될 수 있다. 소통 스타일, 반응성 및 평가 프로세스 중 의견 차이를 어떻게 처리하는지에 주의하자.

FAQ

웹 개발 프로젝트를 위한 RFP 문서는 얼마나 길어야 하는가?

8-15페이지 사이로 유지하자. 더 짧으면 공급업체가 의미 있는 제안서를 작성할 수 있을 만큼 충분한 컨텍스트를 주지 않고 있는 것이다. 더 길면 솔루션을 과도하게 지정하거나 발견 단계가 아닌 RFP에 속해야 하는 정보를 포함하고 있는 것이다. 비즈니스 목표, 기능 요구사항 및 평가 기준에 초점을 맞추자.

RFP에 예산 범위를 포함해야 하는가?

예. 나는 그것이 직관에 어긋나는 것처럼 느껴진다는 것을 안다, 하지만 현실적인 예산 범위를 공유하는 것은 공급업체가 적절하게 범위를 정할 수 있게 도와주고 그들이 적합하지 않으면 자체 선택하게 한다. 당신은 더 비교 가능한 제안서를 받을 것이고 당신의 요구사항의 매우 다른 해석을 검토하는 데 시간을 낭비할 것이 적을 것이다. "$100K-$175K"와 같은 범위는 당신을 잠그지 않으면서도 유용할 정도로 구체적이다.

몇 개의 공급업체에게 RFP를 보내야 하는가?

4-6이 최적의 지점이다. 3개보다 적으면 비교 포인트가 충분하지 않다. 6개보다 많으면 제안서에 빠져 공정한 평가 시간을 각각 줄 수 없다. RFP를 보내기 전에 공급업체를 사전 심사하여 받은 모든 응답이 읽을 가치가 있는지 확인하자.

2026년에 RFP 프로세스의 일반적인 타임라인은 무엇인가?

내부 요구사항 수집 시작부터 계약 서명까지 14-16주를 예상하자. 공급업체 응답 기간만 최소 3주여야 한다. 프로세스를 급하는 것은 거의 항상 잘못된 공급업체를 선택하거나 프로젝트 중간에 나타나는 중요한 요구사항을 놓치는 결과로 이어진다.

RFP 전에 RFI를 사용할 수 있는가?

절대, 그것은 복잡한 프로젝트를 위한 현명한 움직임이다. RFI (정보 요청)는 전체 RFP에 위탁하기 전에 시장을 이해하는 데 도움이 되는 더 가벼운 문서다. 기술 선택이 진정으로 불확실할 때 사용하자 -- 헤드리스 CMS 아키텍처로 가야 할지 아니면 전통적인 모놀리식 플랫폼으로 가야 할지처럼. RFI 응답은 당신의 RFP 요구사항을 알릴 것이다. 맥락을 위해 우리의 헤드리스 CMS 개발 능력을 확인하자.

웹 개발 RFP에 가장 중요한 평가 기준은 무엇인가?

기술 접근 및 관련 경험이 가장 많은 가중치를 들고 가야 한다 -- 약 45% 결합. 가격이 중요하지만 주요 드라이버가 아니어야 한다. 가장 저가의 입찰가를 선택했기 때문에 많은 프로젝트가 옆으로 가는 것을 봤다. 가격을 15%로 가중치하고 공급업체가 실제로 당신이 그들에게 구축하도록 요청하는 것을 구축했는지, 증명할 수 있는 결과가 있는지에 더 집중하자.

공급업체가 대면으로 발표해야 하는가?

2026년에 원격 발표가 표준이고 품질 페널티가 없다. 비디오 통화는 실제로 이점이 있다: 참석할 수 없는 이해관계자를 위해 그들을 기록할 수 있다 (허락을 얻어). 인사 통화 컴포넌트를 원한다면, 초기 평가가 아닌 최종 진출자 라운드에서 최고 2명의 공급업체로 저장하자.

모든 공급업체 제안서가 내 예산을 초과하면 어떻게 해야 하는가?

이는 보통 세 가지 중 하나를 의미한다: 범위에 대해 당신의 예산이 비현실적이거나, 범위가 단일 단계에 너무 크거나, 우선순위를 명확하게 충분히 소통하지 못했다. 최고의 움직임은 최상위 1-2개의 공급업체로 돌아가 분할된 접근 방식을 제안하도록 요청하는 것이다. 1단계에서 핵심 기능으로 론칭하고 이후 단계에서 기능을 추가하자. 대부분의 경험 많은 에이전시, 우리 포함, 모두를 위해 위험을 줄이기 때문에 이런 방식으로 프로젝트를 구조화하려 한다. 당신의 옵션을 우리와 직접 이야기하고 싶다면 48시간 내에 제안을 받고 우리가 올바른 경로를 알아내는 데 도움을 드리겠다.