세일즈 엔지니어

파는 쪽에 기술을 아는 사람이 따로 필요해진 것은 제품이 고객사의 다른 시스템과 엮이기 시작한 뒤부터입니다. 도구 하나를 사서 그것만 쓰던 시절에는 영업 담당자가 화면을 보여 주고 값을 말하면 대화가 끝났습니다. 지금은 계약 전에 답해야 할 질문이 따로 있습니다. 사내 계정 체계에 붙일 수 있는지, 기존 도구에 쌓인 자료 8만 건을 옮길 수 있는지, 서버가 어느 나라에 있는지.

이 질문들이 오면 미팅이 같은 모양으로 멈췄습니다. 고객사 개발자가 인증 방식을 물으면 영업 담당자는 "확인해서 알려드리겠습니다" 하고 적었고, 그 답이 돌아오는 데 나흘이 걸렸습니다. 나흘 뒤에 온 답이 질문의 절반만 짚으면 미팅을 한 번 더 잡아야 했습니다. 그렇다고 개발팀에 매번 물을 수도 없었습니다. 만들던 것을 멈추고 답을 써 주는 일이 일주일에 다섯 번 생기면 개발 일정이 밀립니다.

세일즈 엔지니어는 그 자리를 전담으로 만든 역할입니다. 기술 질문에 그 자리에서 답할 만큼 제품 안쪽을 알고, 동시에 고객 앞에서 설명할 수 있는 사람을 한 명 두는 것입니다. 회사에 따라 솔루션 엔지니어라고 부르기도 하는데 하는 일은 같습니다. 개발팀에서 빼 오는 시간을 줄이고 고객이 기다리는 시간도 줄이는 두 가지를 한꺼번에 해결합니다.

하루가 미팅과 문서 작업으로 반씩 나뉩니다. 흔한 일은 다섯 가지입니다.

1. 데모 준비와 진행. 데모는 제품을 직접 돌려 보여 주는 자리입니다. 준비에서 하는 일은 그 고객사의 상황에 맞게 화면을 미리 꾸며 두는 것입니다. 물류 회사에 문서 협업 도구를 보여 줄 때 샘플 문서 이름이 배송 관련이면 상대가 자기 일로 읽습니다.
2. 보안 점검표 채우기. 보안 점검표는 고객사가 도입 전에 보내오는 확인 문서로, 문항이 마흔 개에서 수백 개까지 옵니다. 답을 모아 둔 문서를 관리하면서 새 문항만 개발팀에 넘기는 것이 실제 업무입니다.
3. 기술 검증 진행. 연동이 되는지 실제로 붙여 보는 일입니다. 고객사 시험 계정에 계정 연동을 걸어 보고 자료 100건을 옮겨 보는 식으로, 되는지 안 되는지를 말이 아니라 결과로 남깁니다.
4. 안 되는 것을 안 된다고 정리하기. 요구사항 열 개 중 셋이 지금 제품으로 안 되면 그 셋을 적고, 대신 쓸 방법이 있는지와 언제쯤 되는지를 붙입니다. 여기서 되는 것처럼 말하면 계약 후 석 달 뒤에 해지 요청이 옵니다.
5. 안으로 되먹이기. 같은 요구가 거래 다섯 건에서 반복되면 그 사실을 제품팀에 넘깁니다. 개별 고객의 부탁과 시장이 요구하는 기능을 가르는 근거가 이 숫자입니다.

코드를 매일 쓰는 자리는 아닙니다. 다만 API 문서를 읽고 요청 한두 개를 직접 보내 확인할 정도는 합니다. API 는 프로그램끼리 주고받기로 약속해 둔 창구입니다.

짝은 AE입니다. AE 는 상담부터 계약 체결까지 한 거래를 책임지는 영업 담당자로, 금액과 조건을 맡고 세일즈 엔지니어는 기술을 맡습니다. 한 사람이 여러 AE 를 지원하는 것이 보통이라, 어느 거래에 붙을지를 고르는 판단이 일의 일부가 됩니다. 규모가 작고 요구가 단순한 거래에 붙으면 정작 큰 거래의 검증이 밀립니다.

고객사 쪽에서는 세 사람을 만납니다. 제품을 쓸 실무 팀장, 사내 시스템을 아는 개발자, 그리고 보안 검토자입니다. 세 사람의 질문이 서로 다릅니다. 실무 팀장은 옮겨 오는 데 얼마나 걸리는지를 묻고, 개발자는 인증과 연동 방식을 묻고, 보안 검토자는 사고가 났을 때 몇 시간 안에 알려 주는지를 묻습니다.

안에서는 개발팀과 제품팀에 기댑니다. 페이지덱에서는 태오가 새 문항의 답을 대고 지현이 로드맵 상의 시점을 확인해 줍니다. 계약이 끝난 뒤에는 AM에게 넘깁니다. AM 은 기존 고객사를 맡아 관계와 재계약을 관리하는 역할입니다. 넘길 때 함께 주는 것은 계약서가 아니라 검증 기록입니다. 무엇이 확인됐고 무엇이 안 된다고 말해 뒀는지가 그 문서에 있습니다.

"이 건은 요구사항이 복잡해서 SE 붙여야 할 것 같아요. 다음 미팅 같이 들어가 주실 수 있나요?"

혼자 답할 수 없는 질문이 예상되니 지원을 요청하는 말입니다.

"저희 제품으로 그건 지금 안 됩니다. 대신 이렇게 우회하면 같은 결과가 나오는데, 원래 방식은 내년 상반기 예정입니다."

되는 것과 안 되는 것을 그 자리에서 가르는 답변입니다.

"기술 검증은 통과했고 보안 점검표만 남았습니다. 이번 주에 답변 보내겠습니다."

기술 쪽 장애물이 몇 개 남았는지 보고하는 말입니다.

페이지덱에는 세일즈 엔지니어가 아직 한 명입니다. 수아가 기업 계약을 맡으면 두 번째 미팅부터 함께 들어갑니다. 첫 미팅은 무엇이 불편한지를 듣는 자리라 기술 질문이 나오지 않지만, 두 번째부터는 계정 연동과 자료 이전이 반드시 나옵니다.

붙을 거래를 고르는 기준은 따로 있습니다. 요구사항이 다섯 개를 넘거나 고객사 개발자가 미팅에 들어오는 건에만 붙습니다. 기준을 두지 않으면 진행 중인 거래 스무 건에 조금씩 다 붙어 어느 쪽도 끝까지 보지 못합니다.

영업을 돕는 보조 역할로 보는 경우가 많습니다. AE 가 거래를 책임지고 이 사람은 옆에서 답해 주니 그렇게 읽힙니다. 다만 실제로 하는 일에는 판정이 들어 있습니다. 요구사항이 제품으로 안 되면 안 된다고 말하는 것이 이 역할의 몫이고, 그 말 때문에 거래가 깨지기도 합니다. 그 판정을 하지 않으면 안 되는 것을 된다고 말한 계약이 남고, 석 달 뒤 해지 요청과 함께 개발팀에 급한 요구가 떨어집니다. 판정하는 자리를 보조로 두면 판정이 사라집니다.

개발자가 잠깐씩 도와주면 되는 일이라고 보는 것도 흔합니다. 질문에 답하는 일이니 아는 사람이 하면 된다고 느껴집니다. 하지만 이 일은 답을 아는 것과 고객 앞에서 답하는 것이 다른 능력을 요구합니다. 그리고 겸업으로 두면 둘 다 망가집니다. 개발자가 주에 다섯 번 불려 나가면 만들던 것이 밀리고, 불려 나간 자리에서도 준비 없이 들어가니 미팅 품질이 떨어집니다. 그래서 기업 계약이 분기 다섯 건을 넘어서면 대개 이 자리를 따로 둡니다.