저는 서울에 사는 뉴질랜드 사람입니다. 이 글은 안에서 본 한국 개발 현장, 채용 테이블의 양쪽에서 본 모습, 그리고 한국에서 일해 보려는 사람에게 해 주고 싶은 이야기입니다. 외국인 개발자를 뽑으려는 한국 팀에게도 드릴 말이 조금 있습니다.

어떻게 여기까지 왔나

#

시작은 석사였습니다. 뉴질랜드에서 Waikato 대학교 학사를 마치고 통신사에서 1년간 네트워크 운영 일을 한 뒤, 2017년 3월부터 2019년 2월까지 경희대학교에서 컴퓨터공학 석사 과정을 밟았습니다. 연구실은 학기마다 국내 학회인 KSC와 KCC에 나갔습니다. 2018년 평창에서 열린 KSC에는 한국의 대형 IT 기업 여러 곳이 후원사로 참여했고 취업 준비생을 위한 채용 부스도 있었습니다. 한국에서 대학원을 다니는 외국인이라면 알아 두면 좋은 사실입니다.

그 뒤로는 이렇게 지나왔습니다.

엔지니어링은 익숙한 절반이었습니다. 소프트웨어를 출시하는 일의 상당 부분이 사실은 운영이라는 걸 배운 곳이 고객 지원 스타트업이었고, 크리에이터 플랫폼의 백엔드는 지금의 제가 고를 법한 것보다 훨씬 많은 스택 위에서 돌아갔습니다. 한국만의 차이는 가장자리에 있습니다. 네이버는 신경 써야 하는 검색 엔진입니다. Kiwi Alumni 웹사이트를 새로 열었을 때도 SEO를 구글과 네이버 양쪽에 맞춰 했습니다. 한국 플랫폼들은 짐작하기 어려운 이름으로 크롤링을 합니다(네이버 크롤러는 Yeti이고, 카카오톡 링크 미리보기는 kakaotalk-scrap이라는 녀석이 가져갑니다). 그리고 한국 인터넷 뱅킹은 아직도 내 컴퓨터에 자기네 보안 프로그램을 깔라고 하죠.

하지만 어느 것도 어려운 부분은 아닙니다.

눈치란 무엇이고, 왜 ‘optics’가 아닌가

#

한국 독자에게 눈치를 설명하는 건 좀 쑥스럽지만, 밖에서 들어온 사람의 눈에 어떻게 보이는지 적어 보겠습니다. 눈치는 상대가 무엇을 생각하고 원하고 기대하는지를, 말이 아니라 상황에서 알아차리는 감각입니다. 『The Power of Nunchi』(2019)로 눈치를 영어권에 가장 널리 알린 유니 홍(Euny Hong)은 이 단어를 ’eye-measure’, 그러니까 ‘눈으로 재는 것’이라고 옮겼습니다. 눈치가 빠른 사람은 분위기를 금방 읽고, 눈치가 없는 사람은 전혀 못 읽습니다. 칭찬이 아니죠. 그리고 눈치를 본다는 건 다른 사람, 대개는 윗사람의 반응을 계속 살피면서 미움받지 않는 쪽으로 자신을 맞추는 일입니다.

영어권 사람들이 이럴 때 꺼내는 단어가 ‘optics’인데, 저는 틀린 단어라고 생각합니다. optics는 실제가 어떻든 밖에서 어떻게 보이느냐의 문제입니다. “구조조정 발표와 같은 주에 보너스를 발표하면 optics가 나쁘다” 같은 식이죠. 겉모습의 문제이고, 관리하는 쪽은 보이는 사람입니다. 눈치는 대체로 반대 방향을 가리킵니다. 내가 남에게 어떻게 보이느냐가 아니라 내가 남을 얼마나 잘 보느냐의 문제입니다. 둘이 만나는 지점은 ‘눈치를 본다’뿐입니다. 남들을 지켜보면서 남들 눈에 내가 어떻게 보일지를 관리하는 것. 해외 기사에서 한국 직장 문화를 다룰 때 나오는 게 바로 이 버전입니다.

그런 기사에 나오는 예시는 늘 비슷합니다. 팀장보다 먼저 퇴근하지 않기, 연차 쓸 때 보는 눈치, 회식에서 언제 일어나도 되는지 알기, 윗사람 말에 반대할 때 회의 중에 할지 끝나고 조용히 할지 정하기. 각각을 어떻게 보든, 모양은 같습니다. 모두가 따르지만 아무도 말하지 않는 규칙이라는 점입니다.

그리고 이건 언어와는 별개의 문제입니다. 한국어는 말 속에 있고, 눈치는 말을 둘러싼 모든 것 속에 있습니다.

개발팀에서 눈치가 드러나는 곳

#

개발팀은 바로 그 모양으로 돌아갑니다. 처음 매니저를 맡고 몇 달 뒤 팀 규범에 관한 글을 썼는데, 첫머리가 이랬습니다. 제가 다룬 마찰의 대부분은 기술 문제가 아니었다. 코드 리뷰가 얼마나 빨리 돌아와야 하는지, ‘완료’가 정확히 무슨 뜻인지, 두 번 핑하는 게 무례한지에 대해 사람마다 말하지 않은 가정이 달랐을 뿐이다. 그때는 그 단어를 쓰지 않았지만, 그 목록은 한 줄 한 줄이 다 눈치로 읽어 내야 하는 것들입니다. 팀이 말없이 합의한 규칙이고, 새로 온 사람은 지켜보는 것 말고는 배울 방법이 없습니다.

같은 글에서 저는 신입이 규범을 온보딩 때 명시적으로 듣는 대신 ‘구전 설화처럼’ 배운다고 투덜댔고, 글로벌 팀이 자기 기준을 모두의 기준으로 여긴다고도 썼습니다. 눈치가 무엇으로 돌아가는지 설명할 때 제가 찾은 가장 좋은 영어 단어가 folklore, 구전 설화입니다. 팀에 외국인이 나 혼자라면 어긋난 기준은 내 쪽이고, 그 설화는 어디에도 적혀 있지 않습니다.

비용이 가장 크게 드는 곳은 스탠드업입니다. 2023년에 제가 맡았던 프로젝트가 늦어지는데 누가 물어봐 주기만 기다렸던 이야기를 쓴 적이 있습니다. 3주 뒤에야 누군가 물었고, 그때는 이미 재앙이었습니다. 눈치가 좋다고 이게 해결되지는 않습니다. 분위기를 읽으면 아무도 듣고 싶어 하지 않는 말이 무엇인지는 알게 되지만, 그래도 말하라고 알려 주지는 않으니까요. 제가 얻은 습관은 기다림의 정반대입니다. 누가 묻기 전에 먼저, 글로 말하는 것. “생각보다 오래 걸리고 있습니다. 5일이 아니라 8~10일 정도로 보고 있습니다. 범위를 줄일까요, 마감을 미룰까요?”

내가 읽히는 쪽이 됐을 때

#

2024년 2월 서울의 한 소프트웨어 회사에서 엔지니어링 팀을 맡으면서 눈치의 방향이 뒤집혔습니다. 개발자일 때는 제가 분위기를 읽는 쪽이었습니다. 매니저가 되니 제가 곧 분위기였습니다. 회의에서 한 말과 하지 않은 말, 답장 속도, 퇴근 시간까지 전부 다른 사람이 읽을 수 있는 것이 됐습니다.

프로젝트 리드 시절에 썼던 것들 상당수가 매니저가 되면 더 강하게 적용됩니다. 사람들이 무엇이 망가졌는지 편하게 말하지 못하면, 매니저가 가장 늦게 알게 됩니다. 정보를 너무 오래 쥐고 있으면 사람들은 그걸 느끼고, 내가 남긴 침묵은 소문이 채웁니다. 회의에서 다섯 명이 내 답을 기다릴 때 “모르겠습니다"는 실패처럼 느껴지는데, 바로 그래서 말할 가치가 있습니다. 그리고 제가 늘 되새기는 한 줄. 사람들은 내 의도를 읽을 수 없고, 내 말만 읽을 수 있습니다. 눈치로 돌아가는 팀에서는 그래도 읽으려고 합니다. 표정에서, 내가 건너뛴 것에서, 퇴근 시간에서요. 그러니 추측할 거리를 줄여 주는 게 맞습니다.

제가 기댄 건 화려하지 않은 것들이었습니다. 모든 팀원과의 1:1. 스프린트가 아니라 그 사람에 대한 이야기를 하고, 대부분의 일을 해 주는 평범한 질문을 던졌습니다. “업무에 도움이 되도록 저나 팀이 해 줄 수 있는 게 있을까요?”

모두가 볼 수 있는 곳에 적어 둔 서너 개, 많아야 다섯 개의 짧은 팀 규범. 매니저가 규범을 어기면 어떻게 되는지도 포함해서요. 여덟 명이 모인 자리에서는 절대 입을 열지 않을 사람에게 기다리지 않고 직접 찾아가 묻기. 그리고 다시는 언급되지 않을 “한번 보죠” 대신 솔직한 “안 됩니다, 이유는 이렇습니다”. 애매한 대답은 눈치 볼 거리를 하나 더 늘릴 뿐이니까요. 제가 온 지 한 달쯤 됐을 때 프로덕트 팀 워크숍은 카페에서 서로의 가치관과 팀 규범을 이야기하는 시간으로 시작했습니다. 회사가 눈치에 내놓을 수 있는 답으로는 이보다 직접적인 게 드물 겁니다. 평소에 말하지 않는 것들을 소리 내어 말하는 데 오전 한나절을 쓴 셈이니까요.

외국인으로 채용된다는 것

#

한국 채용에 관한 플레이북 같은 건 없습니다. 제게 있는 건 채용 매니저 쪽에서 본 경험이고, 거기서 나오는 조언은 결국 계약서에 서명하기 전에 회사를 향해 눈치를 쓰라는 겁니다.

매니저로서 채용할 때 제가 가장 뽑고 싶었던 개발자들은 채용 사이트에 한 번도 없었습니다. 그리고 예전에도 썼듯이 창업자들은 이미 같이 일해 본 사람을 훨씬 뽑고 싶어 합니다. 그러니 가장 좋은 입구는 사람들이 내가 일하는 모습을 먼저 볼 수 있는 곳입니다. 작은 회사 인턴십은 조용히 정규직 제안으로 바뀌는 경우가 많습니다. 해커톤은 주말 내내 그걸 보여 줄 기회입니다. 2023년에 저는 루닛 글로벌이 주최한 Seoul Tech Impact Hackathon에서 네 명이 한 팀으로 우승했습니다. 만든 건 한국에서 주소가 없는 길거리 음식 노점을 찾아 주는 앱이었습니다.

그리고 커피챗이 있습니다. 편한 대화에서 사람이 어떻게 행동하는지가 연습한 면접보다 같이 일하는 모습을 훨씬 더 많이 알려 준다고 썼는데, 이건 양방향입니다. 후보자에게는 팀 안에 들어가기 전에 그 팀을 읽어 볼 유일한 기회입니다. 후보자 자리에 앉는다면 저는 이렇게 묻겠습니다. 지금 팀이 마주한 가장 큰 과제는 무엇인가, 왜 합류했고 무엇 때문에 계속 있는가, 그리고 여기서 일하면서 저를 놀라게 할 만한 게 있다면 무엇인가. 마지막 질문은 눈치를 미리 알려 달라고 정중하게 부탁하는 방법입니다. 이직률이나 회사 방향에 대해 얼버무리는 대답이 돌아온다면, 그것만으로도 많은 걸 알 수 있습니다.

외국인 개발자를 채용하려는 팀에게

#

한국에서 팀을 운영하면서 외국인 개발자를 채용하려 한다면, 가장 도움이 되는 건 그 팀 규범 글에 썼던 한 구절입니다. 암묵적인 것을 명시적으로 만드세요. 새로 온 사람이 팀의 규칙을 구전 설화처럼 배우게 두지 마세요. 첫 주에 알려 주세요. 리뷰는 보통 얼마 안에 돌아오는지, ‘완료’가 무슨 뜻인지, 두 번 핑하는 게 무례한지, 사람들이 실제로 몇 시에 퇴근하는지, 연차를 쓸 때 신청서 말고 신경 쓸 게 더 있는지. 마지막 두 개가 전형적인 눈치 질문입니다. 팀 안에 있는 사람은 말할 생각조차 못 하는 것들이죠.

외국인 개발자의 입장에서 보면, 한국어를 잘하는 것과 이런 규칙을 아는 것은 전혀 다른 문제입니다. 한국어가 유창한 외국인도 눈치 앞에서는 신입이고, 정작 본인은 무엇을 모르는지조차 모릅니다. 그래서 물어봐 주기를 기다리기보다 먼저 알려 주는 쪽이 훨씬 빠릅니다.

그다음은 읽을 거리를 줄여 주는 지루한 습관들입니다. 누가 묻기 전에 먼저 말하기. 금요일에 이해관계자들에게 세 줄짜리 메일(이번 주에 나간 것, 다음에 할 것, 걱정되는 것)을 보내는 데는 10분이면 됩니다. 회의에서 조용한 사람을 기다리지 말고 직접 묻기. “안 됩니다"를 포함해 진짜 대답을, 이유와 함께 주기. 그리고 모든 후보자를 같은 질문과 같은 평가 기준으로 면접 보기. 이건 저도 배우는 데 시간이 좀 걸렸지만, 사람을 공정하게 비교하는 유일한 방법입니다. 안 그러면 가장 최근에 이야기한 사람에게 점수를 더 주게 됩니다. 그리고 이렇게 하면 팀의 말하지 않는 규칙을 모르는 후보자도, 아는 후보자와 똑같은 질문을 받게 됩니다.

여기 있는 뉴질랜드 커뮤니티

#

2018년, 아직 학생이던 시절에 Kiwi Chamber 리더십 조찬 행사에서 사진을 찍었고, 그 뒤에 두 나라의 관계를 넓히는 행사에서 봉사하는 게 정말 즐겁다고 적었습니다. 2020년 1월부터는 Kiwi Alumni의 회장을 맡고 있습니다. 한국에 사는 뉴질랜드 사람들, 그리고 뉴질랜드에서 공부하고 지금은 한국에서 살며 일하는 사람들의 커뮤니티입니다. 자원봉사 자리이고, 대부분은 사람을 챙기는 일입니다. 행사를 기획하고, 주한 뉴질랜드 대사관과 교육 기관들과 관계를 쌓고, 새 로고나 회원들이 실제로 원하는 걸 찾을 수 있는 웹사이트 같은 티 안 나는 일도 합니다. 2023년에는 대사관과 함께 Kiwi Alumni Night를 열었고, KTV에도 나왔습니다.

그날 밤 이후에 쓴 문장이 이 글에서 주제문에 가장 가깝습니다. 한국과 뉴질랜드 양쪽에서 살아 본 사람들은 두 문화를 모두 겪어 봤기 때문에 그 차이를 어떻게 잇는지 압니다. 일하러 한국에 온다면, 어느 나라 출신이든 그런 사람들을 찾으세요. 그 자리의 분위기가 무슨 말을 하고 있었는지 평범한 말로 알려 줄 사람들입니다.

서울에서 프리랜서로

#

매니저 일을 그만두고 2025년 10월에 프리랜서가 됐습니다. 실제로는 계약직 DevOps·MLOps 일이고, 대부분 온프레미스입니다. 고가용성 PostgreSQL 클러스터를 만들었고, 이어서 같은 하드웨어에 LLM 서빙 인프라를 올렸습니다. 해 보니 배관 공사보다 품질 관리가 더 많았습니다. 트레이스와 멀티턴 대화를 지켜보면서 모델 출력이 어디서 어긋나는지 찾는 일이죠. 2026년 2월부터는 제 마켓플레이스·커뮤니티 앱도 따로 만들고 있습니다.

프리랜서가 된다고 눈치에서 벗어나지는 않습니다. 읽는 대상이 바뀔 뿐입니다. 어느 팀에 가든 제가 가장 먼저 보는 건 모니터링입니다. 팀에 대해 README보다 더 많은 걸 알려 주니까요. 시스템에 쓰는 눈치인 셈입니다. 팀이 한다고 말하는 것이 아니라 실제로 하는 것을 읽는 일이요.

한국행을 고민하는 사람에게

#

1. 채용 전에 사람들이 내가 일하는 모습을 볼 수 있는 문으로 들어오세요. 제 경우엔 석사였습니다. 해커톤, 작은 회사의 인턴십, 여기 있는 자기 나라 커뮤니티도 같은 역할을 합니다. 양쪽에서 살아 본 사람들을 만날 수 있는 곳도 커뮤니티입니다.
2. 작은 회사를 배제하지 마세요. 제 경력의 대부분이 작은 회사였습니다. 열 명짜리 회사에는 지루한 일을 넘길 사람이 없고, 내가 만든 게 실제로 나갑니다.
3. 합류하기 전에 팀을 읽으세요. 커피챗을 활용하고, 여기서 일하면 무엇이 놀라울지 묻고, 이직률에 대한 얼버무림은 진지하게 받아들이세요.
4. 누가 물어봐 주기를 기다리지 마세요. 밀리는 일정, 위험한 변경, 다른 사람이 기다리는 결정. 먼저, 글로 말하세요.
5. 적혀 있지 않은 규칙을 소리 내어 물어보세요. 리뷰는 얼마나 빨리 돌아오는지, ‘완료’가 무슨 뜻인지, 두 번 핑하는 게 무례한지. 아무도 적어 두지 않았다면 내가 적겠다고 하세요.
6. 내 스택을 둘러싼 스택을 배우세요. 여기서는 네이버와 카카오가 구글 습관으로는 커버되지 않는 방식으로 중요합니다.

엔지니어링은 오기 전에 준비할 수 있는 절반입니다. 눈치는 일하면서 배우는 절반이고, 제가 아는 가장 빠른 방법은 사람들에게 말하지 않는 부분을 소리 내어 말해 달라고 부탁하는 것, 그리고 내 것을 먼저 말하는 것입니다.

편향부터 고백하자면, 제 커리어는 대부분 작은 회사에서 흘러왔고 지금도 작은 회사에서 개발팀을 맡고 있습니다. 그래도 학생들이 “어느 쪽 인턴을 가야 할까요?“라고 물으면 거의 매번 더 작고 더 정신없는 쪽을 권합니다.

스타트업 인턴 vs 대기업 인턴 한눈에 보기

#

나란히 놓고 보면 이렇습니다. 나머지는 이 표의 긴 버전이고요.

일이 진짜입니다

#

직원 10명짜리 회사에는 지루한 일을 떠넘길 사람이 없습니다. 인턴이 기능을 배포하고, 고객과 이야기하고, 기획 회의에 들어갑니다. 프로덕트, 마케팅, 운영을 다 건드리게 되는데 같은 주에 전부 하는 날도 있죠. 정신없긴 한데, 그만큼 빨리 배웁니다.

더 좋은 건 내가 만든 게 실제로 세상에 나간다는 점입니다. 프로덕트의 어딘가를 가리키며 “이거 제가 만들었어요"라고 말할 수 있습니다. 뭔가를 만들고 사람들이 쓰는 걸 지켜보는 그 루프는 중독성이 있는데, 대기업이 인턴에게 그 근처까지 가게 해주는 일은 거의 없습니다.

현실적인 이점도 있습니다. 성장하는 스타트업은 늘 사람이 부족하고, 창업자는 이미 같이 일해본 사람을 뽑고 싶어 합니다. 괜찮은 인턴십은 어느새 조용히 채용 제안으로 바뀌어 있곤 하죠.

창업자를 가까이서 지켜볼 수 있습니다

#

대기업에서는 CEO를 한 번도 못 만나고 끝날 수 있습니다. 스타트업에서는 아마 바로 옆자리에 앉아 있을 겁니다. 어떻게 결정을 내리는지, 압박을 어떻게 버티는지, 모든 게 급해 보일 때 무엇부터 잡는지를 매일 보게 됩니다. 교과서 어디에도 없는 내용입니다.

수평적인 구조는 양날의 검이기도 합니다. 배포까지 결재 세 단계가 끼어들지 않으니, 무슨 일을 어떻게 할지에 대해 진짜 발언권이 생깁니다. 대신 아무도 손잡고 이끌어주지 않습니다. 이런 환경에서 쑥쑥 크는 사람도 있고, 겁부터 나는 사람도 있어요. 지원하기 전에 자신이 어느 쪽인지 알아두면 좋습니다.

솔직한 단점들

#

급여는 보통 더 낮습니다. 체계는 최소한이고, 전담 멘토가 없을 수도 있고, 회사 자체가 2년 뒤에 사라질 수도 있습니다. 그 부분을 포장할 생각은 없습니다. 그래도 비즈니스가 실제로 어떻게 굴러가는지를 안에서 배우고 싶다면, 저는 아직 이보다 빠른 방법을 찾지 못했습니다.

아이디어

#

한국의 노점에는 주소가 없습니다. 포장마차는 자리 잡고 싶은 곳에 자리를 잡으니까, 그 자리를 원래 아는 사람이 아니면 온라인으로는 찾을 방법이 없죠. 우리 앱은 노점을 말 그대로 지도 위에 올립니다. 노점 사장님들한테도 좋고, 밤늦게 떡볶이 파는 곳을 수소문하는 사람한테도 좋습니다.

대회 당일

#

해커톤은 Lunit Global이 주최했고 사무 공간도 제공해 줬습니다. 별별 배경의 팀들이 모였고, 대부분 밤을 새워 가며 작업했고, 운영진 덕분에 행사는 매끄럽게 굴러갔습니다. 고개를 들어 보니 어느새 새벽 4시더라, 하는 류의 행사였죠.

팀

#

팀은 Sharon Levy, Jonothan Sue, 저, 그리고 Tiaan van der Riel 이렇게 넷이었습니다. 각자 잘하는 게 달라서 일을 나누는 데 잡음이 없었습니다. 피치가 심사위원들에게 먹힌 건, 문제 자체가 설명이 필요 없었기 때문인 것 같습니다. “노점은 온라인에서 보이지 않는다"라고 소리 내어 말하는 순간 해결책이 저절로 떠오르니까요.

앞으로

#

지금은 이 앱을 스토어에 올리는 작업을 하고 있습니다. 주말 프로젝트로 시작했지만, 풀려는 문제가 진짜인 만큼 여기서 멈추면 아까울 것 같거든요.

해커톤이 처음이라면

#

해커톤을 한 번도 안 해봤다면 꼭 해보시라고 권하고 싶습니다. 처음 만난 사람들과 빠르게 뭔가를 만들고, 압박 속에서 내가 실제로 어떻게 움직이는지 알게 되고, 가끔은 계속 키워볼 만한 결과물까지 들고 나오게 됩니다. 최악의 경우라 해봐야, 공짜 간식이 깔린 주말과 아무도 시키지 않은 작동하는 프로토타입 하나를 얻는 거고요.

해커톤을 준비한다면 미리 알아 두면 좋은 것들입니다.

• 한 문장으로 설명할 수 있는 문제를 고르세요. 심사위원이 문제를 이해하는 데 첫 1분을 쓰면, 정작 해결책은 제대로 듣지 못합니다.
• 역할은 일찍, 가능하면 첫 한 시간 안에 나누세요. 누가 개발하고, 누가 디자인하고, 누가 피치를 맡을지. 새벽 2시에 그걸 정하고 있으면 대가가 훨씬 큽니다.
• 데모 경로부터 만드세요. 무대에서 보여줄 흐름 하나를 처음부터 끝까지 돌아가게 만든 다음에 나머지를 붙이는 겁니다.
• 피치는 실제 데모를 띄워 놓고 소리 내어 최소 두 번은 연습하세요. 피치는 거의 항상 생각보다 길어집니다.
• 조금이라도 자세요. 두어 시간만 자도 아침에 내리는 결정과 피치가 눈에 띄게 나아집니다.

링크:

#

https://lnkd.in/drMXUgPB

회사에서 거대 소셜 플랫폼들 틈에서 살아가는 커뮤니티 앱을 만들다 보니, 이 주제를 자주 생각하게 됩니다. 거인 위에 올라탈 것인가, 아니면 경쟁할 것인가. 둘 다 답이 될 수 있지만, 정말 재미있는 질문은 “언제 갈아타느냐"입니다.

코피티션 사례

#

잘 알려진 사례는 전부 대기업 이야기입니다. 삼성은 iPhone에 들어가는 OLED 디스플레이를 대량으로 만들면서, 갤럭시로 바로 그 iPhone과 경쟁합니다. Netflix는 스트리밍 시스템을 아마존 웹 서비스(AWS)로 옮겼고(이전 완료는 2016년), 동시에 Amazon의 Prime Video와 시청자의 같은 저녁 시간을 두고 다툽니다. Google은 Safari의 기본 검색 엔진 자리를 얻으려고 Apple에 돈을 내면서, Android로는 iPhone과 같은 스마트폰 구매자를 노립니다. 어느 경우든 양쪽 다 경쟁자를 멀리하는 것보다 함께 나눠 갖는 몫이 더 크다고 판단한 겁니다.

스타트업 버전은 규모가 작고 훨씬 한쪽으로 기울어 있습니다. 사용자가 필요하니까 플랫폼과 협력하고, 그 사용자의 관심을 놓고 플랫폼과 경쟁하죠. 처음에는 거의 협력뿐입니다. 문제는 언제부터 반대쪽으로 무게를 옮기기 시작하느냐입니다.

일단은 공존부터

#

프로덕트 마켓 핏을 찾고 있는 초기 단계라면, 대형 플랫폼에 올라타는 게 대개 정답입니다. 이미 사용자가 모여 있는 생태계 안에서 움직이다 보면 사람들이 진짜 원하는 게 뭔지 보입니다. 인기 플랫폼용 연동 기능을 만들면 돈 주고도 못 사는 유통 채널이 생기고요. 거인과 정면 승부하는 대신 틈새를 파고들 수도 있습니다. PayPal은 eBay 사용자용 결제 수단으로 시작했고, 이름이 알려진 성공 앱의 절반은 Shopify나 Slack의 애드온으로 출발했죠.

경쟁으로 돌아설 때

#

전환점은 플랫폼보다 내 사용자를 더 깊이 이해하게 된 다음에 옵니다. Instagram이 대표적인 사례입니다. 사진 필터 앱으로 시작해 독자적인 소셜 플랫폼으로 컸으니까요. 제가 보는 신호는 두 가지입니다. 자체적인 도메인 전문성이나 기술이 정말로 쌓였는가. 그리고 기존 강자들이 못 주는 뭔가를 사용자들이 원한다는 게 행동에서 읽히는가. 둘 다 아니라면, 경쟁은 질 싸움을 먼저 거는 셈입니다.

커뮤니티 앱이라면

#

커뮤니티 프로덕트에서 공존이란 결국 수수한 연동 작업입니다. 계정을 또 만들게 하지 않는 소셜 로그인. 커뮤니티 콘텐츠를 소셜 피드로 쉽게 공유하게 하는 것 — 이게 곧 마케팅 예산입니다. 다른 플랫폼에서 언급되거나 소개되면 알려주는 알림, 파트너가 자기 사이트에 커뮤니티 기능을 얹을 수 있는 임베드와 위젯, 보완 관계에 있는 서비스와의 API 연동도 마찬가지고요. 기술 밖의 영역에서는, 대형 플랫폼에 뿌리내린 인플루언서와의 협업이나 여러 플랫폼을 가로지르는 캠페인이 자체 기능 몇 개 만드는 것보다 참여도에 훨씬 잘 먹힙니다.

이분법이 아닙니다. 애초에 코피티션이라는 말이 그런 뜻이고요. 대부분의 스타트업은 공존으로 시작해서 성장하면서 경쟁 쪽으로 옮겨 갑니다. 어려운 건, 그 전환의 자격을 어느새 갖췄다는 걸 스스로 알아차리는 일이죠.