업무
TIPS - 챗봇 애플리케이션 기능 개발
챗봇 애플리케이션에 필요한 외부 인프라를 구현하고, 연결했습니다.
BackEnd Server
기존 API로는 처리할 수 없는 동작이 몇 가지 있어
백엔드 개발자분들과 공유 후 함께 작업을 진행했습니다.
대부분의 동작은 비슷했지만
1) 사용자가 달라, 기존 권한 확인 로직을 사용할 수 없음
2) 수집되는 데이터 차이 발생 으로 인해
챗봇 사용자 용 API를 새로 만들고, 이를 FE에서 호출하는 형태로 구현했습니다.
window popup
챗봇을 통한 예약 생성 Flow에는, 운영 중인 다른 웹 사이트의 UI/UX가 그대로 사용된 부분이 있었습니다.
(날짜 조회 및 선택, 동의서 서명 및 저장)
해당 컴포넌트를 그대로 복사붙여넣기 하고 싶지는 않았기 때문에... (사실 말도 안되죠)
좋은 방안을 고민하던 중, postMessage를 통해 window 간 통신이 이뤄지게 만들 수 있겠단 생각이 떠올랐습니다.
https://developer.mozilla.org/ko/docs/Web/API/Window/postMessage
챗봇 말풍선 내 버튼을 클릭하면 해당 웹페이지 창이 뜨는 형태였기 때문에
기존 웹 서비스에서 요구된 동작을 수행한 뒤, window.opener로 수집된 데이터를 postMessage 해줄 수 있었습니다.
export interface WindowPopup {
open(): void;
receive(e: MessageEvent): string | Record<string, string> | null;
}
위 형태로 해당 service의 interface를 구성한 뒤
import { WindowPopup } from './interface/window-popup.interface';
interface AgreementFormPopup extends WindowPopup {
receive(e: MessageEvent): Record<'signFile' | 'signName', string> | null;
}
export const useCreateAgreementFormPopup = (): AgreementFormPopup => {
const open = () => {
// 타겟 페이지로 window.open 호출
};
const receive = (
e: MessageEvent,
): Record<'signFile' | 'signName', string> | null => {
const message = e.data;
// MessageEvent에서, 정의된 데이터 조회
// e.origin을 통한 유효성 검사 추가
};
return {
open,
receive,
};
};
hooks로 이를 구현해
(반환값 타입은 각 웹서비스 별로 다르기 때문에, 해당 인터페이스를 상속해 receive 메서드 반환값을 지정하는 게 좋습니다)
const SignAgreementForm = () => {
const { open, receive } = useCreateAgreementFormPopup();
useEffect(() => {
window.addEventListener('message', receive);
return () =>
window.removeEventListener(
'message',
receive,
);
}, []);
return <> {...} </>
}
UI(React Component) layer에서 사용해 준 모습!
이를 통해 불필요한 중복 로직이나, 기존 로직의 수정 없이 요구사항을 빠르게 구현할 수 있었습니다.
회고
경쟁하지 않아야 한다.
수많은 스타트업 바이블들이 입을 모아 얘기합니다.
스타트업은, 경쟁하지 않아야 살아남을 수 있다.
전체 시장의 크기는 크되 기존 플레이어들이 간과하는 문제가 있는 곳을 찾아라.
해당 문제를 완벽히 해결한 뒤, 다음 문제로 확장하라.
예전에는 이러한 접근 방식을 비현실적이라 생각했습니다.
하지만 B사와의 POC를 진행하면 할수록...
이제는 어렴풋이 느껴집니다.
이런 시장은 존재합니다. 스타트업이 풀어야 할 problem들은 아직도 남아있습니다.
이를 찾지 못하면, 스타트업은 죽고 맙니다.
스타트업은 기존 플레이어들과의 정당한 경쟁으로는 살아남을 수 없습니다.
스타트업의 생존은 곧, 얼마나 경쟁하지 않을 수 있는 시장을 찾아내느냐 를 의미할지도 모릅니다.
하지만 우리는 너무도 쉽게, 기존 플레이어들을 흉내 내는 쪽을 택합니다.
왜? 그 편이 훨씬 더 그럴듯해 보이니까요.
이미 잘 성장하고 있는 기존 플레이들을 보며
그들의 제품에서 몇 가지 feature만 더하면
충분히 사용자들을 끌어모을 수 있지 않을까 하는 말도 안 되는 낙관론에 휩싸이고 맙니다.
단호히 말할 수 있습니다.
기존 플레이어들은 바보가 아닙니다. 사용자는 바보가 아닙니다.
우리가 한 발 나아가는 순간, 기존 플레이어들은 두발, 세발을 앞으로 나아갑니다.
우리가 특별한 기능을 홍보하는 순간, 사용자들은 기존 플레이어들의 제품과 우리 제품을 비교하기 시작합니다.
그리고... 스타트업은 그 격차를 따라잡기도 전에 사라질 가능성이 너무나도 높습니다.
(당연히 예외도 있습니다. 전체 시장 파이가 굉장히 크고, 기존 플레이어도 제대로 선점하지 못한 경우겠죠!)
경쟁하지 않아야 합니다.
현존하는 그 어떤 서비스도, 우리가 정의한 문제를 해결하지 못해야 합니다.
사용자가 우리와 다른 서비스를 비교할 가능성조차 없어야 합니다.
그런 시장을, 그런 문제를, 그런 해결 방법을 찾아야만 합니다.
그것이 유일한 스타트업의 생존 방법이자, 성공 방식입니다.
'lean > 주간 회고' 카테고리의 다른 글
24.06.23~24.06.30 (0) | 2024.07.01 |
---|---|
24.06.16~24.06.23 (0) | 2024.06.24 |
24.06.02~24.06.09 (0) | 2024.06.10 |
24.05.26~24.06.02 (0) | 2024.06.03 |
24.05.19~24.05.26 (0) | 2024.05.27 |