비 개발자 출신 김땡땡은 IT 창업을 결심합니다.

개발은 모르는 김땡땡 대표는 개발 대리자 찾기부터 시작합니다

IT프로덕트를 만들려면 개발은 필수이고, 자신이 할 수 없는 영역이기 때문에 대리자는 꼭 필요합니다.

코 파운더, 직원, 외주업체 등 어떠한 형태든 상관없습니다.

다만 자신이 지고 있는 “개발”이라는 공포를 가져가 주길 바랍니다. 제발!

수많은 사람들을 만났고, 많은 시간을 투자했습니다.

김땡땡 대표는 드디어 대리자를 찾았습니다.

대표는 이제 개발이라는 짐을 대리자에게 넘겼고, 자유를 얻었습니다.

vincero!

많은 비 개발자 대표들의 공통적인 초기 행적입니다.

운이 좋다면 듬직하고 개발 경험 많은 코 파운더를 찾을 수 있었을 겁니다.

그렇지 않더라도 적당한 가격에 괜찮은 프로덕트를 만들어준다는 외주업체를 찾았을 겁니다.

김땡땡은 개발의 모든 것을 위임했기 때문에, 이제 개발이 두렵지 않습니다.

오히려 개발이 지연되거나, 과도한 비용이 발생한다면 불만이 생깁니다.

두려움 대신 불만입니다.

버그를 발견할 때나, 장애가 발생하면 개발자들이 제대로 하고 있는지 의심스럽습니다.

하지만 최대한 어른답고, 대표다운 모습을 유지하며 채근하고 위로하는 방법밖에 없습니다.

지나간 계절은 셀 수 없고, 많은 일들이 있었습니다.

많은 생략…

김땡땡 대표는 꿈을 만나지 못하고 사망했습니다.

사업을 정리하고 법인을 청산함과 동시에 찾아오는 대표로서의 사망입니다.

사망 보고서에는 몇 가지 사인이 적혀있습니다.

• PMF 검증 실패
• 자금조달 실패
• 시장 변화에 민첩하게 대응하지 못함
• 경쟁 업체와 경쟁에서 패배
• 과도한 burn rate

여기까지가 우리가 많이 지켜본 수많은 비 개발자 대표 창업스토리의 도입부와 결말입니다.

김땡땡은 최선을 다했을 겁니다.

많은 사람들은 김땡땡의 마지막을 자연사 또는 사고사라고 생각합니다.

하지만 어쩌면 이건 살인사건일지도 모릅니다.

표면적인 사인 뒤에는 다양한 이야기가 존재합니다.

믿을 수 있는 대리자

“당신이 세상에서 믿을 수 있는 사람은 얼마나 되나요?”

우리는 타인을 쉽게 믿지 않습니다.

이러한 조심성은 우리를 안전하게 합니다.

하지만 이러한 조심성이 무력화되는 순간이 있습니다.

바로 다른 공포심이 더 커질 때입니다.

김땡땡 대표는 개발에 대한 공포심과 불안감을 가지고 있었습니다.

개발을 공부해야 하는 두려움, 어쩌면 개발을 못해 제품을 만들지도 못할 거라는 절망까지요

이러한 심리는 대표가 대리자를 찾는 순간 그 대리자를 신뢰하게 만듭니다.

그 신뢰는 다시 대표가 개발 관련된 모든 것을 위임하게 만듭니다.

대표가 찾은 건 믿을 수 있는 대리자가 아니라, 믿고 싶은 대리자였습니다.

자신이 반드시 믿어야 하는 대리자였습니다.

글쓴이는 스타트업 생태계 내부 또는 지근거리에서 10년 가까운 시간을 보냈습니다.

공동창업자가 대표와 다툼으로 연락이 두절되는 경우도 봤습니다.

개발 직원이 좋은 회사 합격 후 퇴사를 통보하는 경우는 부지기수입니다.

외주업체와 결과는 대부분 버그투성이 반쪽짜리 결과물로 마무리됩니다.

대리자가 누구든 언제든지 떠날 수 있다는걸 잊어서는 안됩니다.

이제 개발 대리자가 떠난 상황을 상상해 봅니다.

대표는 다시 개발의 책임을 받아 왔습니다.

대표는 전 대리자가 작성한 인수인계 문서가 있다는 걸 떠올립니다.

그 문서는 비 개발자는 자신이 이해할 순 없는 용어가 잔뜩 쓰여 있었습니다.

다시 새로운 개발 대리자를 찾아야만 합니다.

좋은 대리자를 찾는다면 이 문서를 해석해 줄 수 있을 거라 믿습니다.

새로운 대리자를 곧 찾았지만,

보물 같았던 인수인계 문서를 쓰레기라고 말합니다. 

심지어 최신화되어 있지 않아서 신뢰할 수 없다고 말합니다.

신규 기능 추가만 하면 된다고 생각했는데, 새로운 대리자는 처음부터 다시 만들자고 이야기 합니다.

실제 극초기 스타트업들은

고객을 만나기도 전에

매출을 만들기도 전에

투자를 받기도 전에,

처음부터 다시 개발을 해야 하는 상황은 빈번합니다.

이 과정에서 많은 대표, 예비 대표들이 사망합니다.

직접 사인: PMF 검증 실패, 자금조달 실패

간접 사인: 핵심 개발 인력 이탈로 인한 프로덕트 유지 불가

개발자 친화적인 환경 만들기

“개발자 친화적인 환경이 뭐야? 내가 돈 많이 주잖아 그럼 된 거 아냐?”

여러분의 회사는 개발자 친화적인가요?

아니면 개발자들에게 고통스러운 공간인가요?

git은 사용하나요? (최근에 아직도 git을 쓰지 않는 곳이 있다는 이야기를 들었습니다. 정말 놀랍습니다.)

cicd는 구성되어서 손쉽게 배포 가능한 환경인가요?

각종 계정과 키는 안전하게 관리되고 있나요?

개발 인프라와 프로덕션 인프라는 분리되어 있나요?

개발자들이 시키는 대로 기능을 찍어내는 환경이 아니라, 스스로 문제를 정의하고 해결할 수 있는 환경인가요?

개발 부채를 해결하는 것도 업무로 인정되나요?

위 요소들을 다 만족한다고 완벽한 개발자 친화적인 환경을 갖추었다고 말할 순 없지만,

위 요소들 대부분을 만족하지 못한다면, 조만간 퇴사를 통보한 개발자를 잡기 위해 월급을 올려줘야 할지도 모릅니다.

개발자 친화적인 환경은 개발자의 근무 만족도와 관련이 깊습니다.

그렇다고 개발자만을 위한 이야기는 아닙니다.

개발자 친화적인 환경은 스타트업을 더 빠르게 움직일 수 있게 합니다.

개발 부채가 많이 쌓여있다면 신규 기능을 개발하는데 보다 많은 시간이 걸립니다.

오랜 시간을 들여 만든 기능은 오류, 버그투성이 일 거구요.

자동화되어 있지 않아, 사람이 수동으로 진행하는 배포 프로세스는 장애의 온상일 겁니다.

이미 더러운 코드 위에서 일하는 개발자들은 더 이상 작업환경을 깨끗하게 유지하려는 노력을 하지 않습니다.

그들은 더럽게 일할 거고, 대충 대충 일할 겁니다.

개발자가 성장하기 힘들거고, 의욕을 잃은 개발자들은 예민해져 있을 겁니다.

이러한 환경에서 대표도 예민해지기 쉽습니다.

신규 기능은 매번 딜레이 되고, 장애는 일상입니다.

기껏 출시한 기능은 버그투성이라, 기껏 유치해온 고객은 떠나갑니다.

개발자에게 불만이 쌓여있지만 대표이기 때문에 참아냅니다.

같이 성장하는 날을 기대합니다.

그러나 어느 날, 개발자는 더 이상 이런 환경에서 근무하고 싶지 않다며 퇴사를 통보합니다.

대표는 자신이 피해자라고 생각했는데, 가해자 라는 이야기를 듣습니다

직접 사인: 시장 변화에 민첩하게 대응하지 못함, 경쟁 업체와 경쟁에서 패배

간접 사인: 최악의 개발 문화로 인하여 사내 개발 퍼포먼스 둔화와 개발자 이탈

돈을 아끼고 아껴 낭비하자

많은 대표들은 사업을 최대한 오래 유지하고 싶어야 합니다.

강해서 버티는게 아니라, 버티는 사람이 강한거니까요.

결국은 버티기 위해 더 많은 자본이 필요합니다.

가장 쉽고 빠른 결과를 만들어 내는 건 비용 절감입니다.

그렇다고 무조건 돈을 덜 쓰는게 최고는 아닙니다.

비용 절감에는 “돈”만 해당되는 건 아니라 “시간”도 포함됩니다.

시간을 아껴야할 땐 돈을 써야 하고,

돈을 아껴야 할 땐 시간을 써야 합니다.

스타트업의 비용 절감은 돈과 시간 균형을 잘 맞춰야하기 때문에 어렵습니다.

비용 절감에 목숨거는 대표라도, 인프라 비용 앞에서는 신용카드를 고민없이 내밉니다.

비 개발자 대표가 인프라 비용이 적절한지 아는건 쉽지 않습니다.

비슷한 규모의 스타트업보다 많은 비용을 낸다는게 이해가 되지 않습니다.

그렇다고 개발자에게 물어볼 수 없습니다.

물어본 질문에 대한 개발자의 대답을 이해할 수 없기 때문입니다.

비 개발자 대표가 인프라의 이해와 주도권을 놓지 않기란 쉽지 않습니다.

그렇다고 하더라도 결과의 책임이 면제되거나 용서받을 수는 없습니다.

• 비용(돈)을 아끼기 위해 적절한 크기의 인프라를 사용하고 있는지?
• 때로는 비용(시간) 아끼기 위해 적절한 saas를 사용하고 있는지?

관심을 가지고 개발자와 소통해야 합니다.

비용 관련하여 최악의 상황은 보안 사고입니다.

제가 아는 범위 내에서 법인 통장에 들어 있는 돈을 한 번에 쓰는 최고의 방법입니다.

개발을 처음 배우던 시절부터 지금까지 주변에 aws 키 유출로 인한 피해가 발생한 이야기를 빈번하게 접하고 있습니다.

클라우드 업체, 그리고 github도 해당 피해를 막기 위해 다양한 지원을 하고 있지만, 부족한 개인 또는 기업에 보안의식으로 발생하는 사고를 완전히 예방할 순 없습니다.

보안키 뿐 아니라, 계정 관리, 네트워크 보안관리 등 개발 보안에 관련된 것들은 항상 조심하고, 모든것을 의심한 상태로 대비해야 합니다.

보안이 잘 지켜지는지 물어보는걸로 만족하고 계시나요?

보안 관련된 내용은 대표가 이해하고 있어야 합니다.

지속적으로 개발자와 대화하고 파악하고 있어야 합니다.

그리고 개발자들이 보안에 시간을 투자할 수 있는 분위기를 만들어 줘야 합니다.

대부분의 클라우드 회사에서 보안에 관련된 다양한 자료를 제공하고, 교육도 진행하고 있습니다.

보안 역시 비 개발자 면책사유가 없는 영역이기 때문에, 시간을 투자해야 합니다.

직접 사인: 과도한 burn rate

간접 사인: 인프라 관리 실패로 인한 비용 누수 (업계 소문: 보안 사고로 인한 과도한 수습 비용 발생)

비 개발자기 때문에 이해하지 못하고, 놓치기 쉬운 부분에 대한 이야기였습니다.

사례는 최악을 가정하여 극단적으로 표현해보았습니다.

실제로는 개발을 모르는 모두가 위 내용같은 최악의 상황을 경험하지 않습니다.

하지만 it 기업을 만들기로 결심했다면, 개발에 대한 이해는 필수입니다.

개발을 두려움의 대상, 기피의 대상으로 여겨서 모든 것을 위임해선 안됩니다.

비 개발자 면책특권이 있는 세상이 오기전 까지는 끊임 없이 관심가지고 노력해야합니다.

반면에, 비 개발자 대표들의 특장점이 도움되는 케이스도 굉장히 많다고 생각합니다.

기술에 매몰된 개발자 출신 대표들 보다, 프로덕트에 관하여 더 뾰족하고 더 민첩한 경우가 많습니다.

그리고 좋은 스타트업을 만들어 낸 많은 비 개발자 대표들이 이것을 증명하고 있다고 생각합니다.

모든 비 개발자 대표님을 응원합니다. 

과거의 창업 경험을 가지고, 현재는 대기업에서 개발자로 일하고 있는 개대발표자라고 합니다.

현재에도 여러 스타트업에 컨설팅을 진행하고 있습니다.

쉽지 않은 길을 가고 있는 모든 스타트업 대표님들을 응원합니다

그 중에서도 특히 비 개발자 대표님들의 고충이 많다고 생각합니다.

현재 비 개발자 스타트업 대표, 예비 대표들을 위한 커뮤니티를 만들고 있습니다.

비 개발자 대표님들 모여서 고충을 나누고, 서로 도움되는 커뮤니티로 만들어보려고 합니다.

디스코드

https://discord.gg/45BzxsvaKx

카카오톡 오픈채팅

https://open.kakao.com/o/gJCqyrZg