# 사회학적 상상력으로 IT 스타트업에서 살아남기 서강대학교 "사회학과 기업현장의 만남" 강연에서 이야기했던 내용을 적절히 갈무리해서 다시 이야기합니다. 해당 강연에서 사용했던 대본의 중간 버전이므로, 최종 대본과는 일부 상이할 수 있습니다. ## 1부: 사회학과 현실 사이 ### 1. 들어가는 말 - 오답노트의 시작 안녕하십니까. 사회학과 10학번 서요한입니다. 제 이름 앞에 사회학이라는 단어가 올 일이 잘 없어서 좀 신기하네요. 다행히 어색하지는 않고, 그냥 고향 온 것 같고 좋습니다. 사실, 더 대단하신 선후배님들이 지금 제가 서있는 자리에 많이 다녀가셨고, 또 다녀가실 예정이시죠. 다른 쟁쟁하신 분들도 계신데 제가 초대받아서 조금 부끄럽습니다. 저는 대단하다고는 절대 할 수 없고, 그냥 간신히 1인분을 하는 사람으로서 왔다고 생각합니다. 대학 생활을 하다보면 "여기 졸업하고 뭐해먹고 살지?"라는 질문을 꼭 한 번쯤 스스로에게 하거나, 하다못해 누군가에게 한 번쯤은 듣게 됩니다. 그리고 저는 오늘, 그 질문에 대한 답 하나를 보여드리려 합니다. 우선 제 소개를 간단히 해보겠습니다. "UX 기획자"라는 이름으로 커리어를 시작했고, 이후 PM(프로젝트 매니저)이라는 이름이 붙었습니다. 좀 있다 보니 "시니어"라는 수식어까지 붙었고, 그 이후로는 쭉 개발팀과 함께 살았습니다. 아, 시니어라는 타이틀은 원래 10~15년차 사이에 붙어요. 제가 좀 이상하게 일찍 달긴 했는데, 뭐 그리 희귀한 사례까지는 아니긴 해요. 혹시라도 관심 있어 하실 분이 있을까 봐 기술 스택을 먼저 말씀드리자면, 모바일 앱 기획으로 커리어를 시작했고, 라이브커머스와 웹 프로젝트 관리를 했고, 블록체인과 보안 분야에 있었고, 지금은 언리얼엔진으로 3D 지도와 시뮬레이터를 만듭니다. 최근에는 유니티와 LLM으로 미디어아트 전시회도 참여했어요. 최근에는 취미로 옵시디언 볼트에 임베딩모델 붙여서 클로드 MCP 연동했어요. 클로바노트 클론코딩도 하고있고요. 이건 깃헙에서 [RecordRoute](https://github.com/john33fiao/RecordRoute)로 검색하면 나올 거에요. 뭐 기술적으로 대단한 거는 아니라서, 아직 스타는 못받았어요. 잡다하죠? 사실 그냥 재밌어보이면 다 했어요. 근데 알고보면 그냥 살아남기 바쁜 기획자였고, 이제 간신히 한 사람 몫을 하고 있습니다. 방금 이야기했던 것처럼, 저는 오늘 기술 분야에 대해 주로 다룰 예정입니다. 그리고, 저에게는 당연한 지식이 여러분한테는 금시초문일 수도 있어요. 그러니 뭔가 모르겠다싶은 용어가 나오면, 바로 질문을 하셔야합니다. 안그러면 저 혼자만 재밌는 강의가 될 수 있어요. 지금부터 제가 말할 내용은 정답이 아닙니다. 이건 제 포트폴리오에도 나와있는 내용이기는 하지만, 오답노트라고 생각해주길 바랍니다. 저는 보통 많이 듣고 적게 말하는 사람이라... 말을 잘하지는 않지만 뭐... 견디세요. 아, 못 견디겠으면 질문을 하시고요. 그러면, 본격적으로 시작해봅시다. 취업 전에 했던 일에 대해 소개하기는 좀 애매합니다. 사회학 전공, 경제학 복수전공, 취미로 종교학을 했어요. 그 외에도 고등학교 동창들이랑 뮤지컬을 하기도 하고, 전상진 교수님과 함께 "잉여학회"에 참여하기도 했는데, "쟤 공부 진짜 더럽게 안 해"라는 말을 전해들은 것도 여기였어요. 솔직히 말하자면, 공부 빼고는 다 열심히 하던 사람이었어요. 사실 사회학을 선택할 때도 그랬어요. 재수 때 진로를 고민하다가 "사회학은 졸업 후 진로가 교육과 연구 외에는 아무 것도 없다"는 말에 겁을 먹고 경제학과로 상향지원을 했다가 모두 떨어졌거든요. 그래서 무기력한 한 학기를 보내며 "사회학이 정말 하고 싶은 공부"라는 걸 깨달았습니다. 어쩌다 여기까지 왔는가 하면... - 사회학과 다니다가 - 취업은 해야지 싶어서 > 경제학 - 군대 늦게 갔다가 > 취사병 - 신학 하려고 했는데 > 종교학 - 밥벌이부터 하려고 보험영업 갔다가 > 삼성생명 - 교회 청년부가 공중분해되고 > 명성교회 - 영업은 내 길이 아님을 깨닫고 > 경주 여행 - UX 얘기 들었는데 재밌어보여서 > 이주현 - 일단 개발 기초부터 배우고 > 비트 컴퓨터 아카데미 - 에이전시에서 UX 기획으로 시작해서 > MetsHIT - PM으로 전직하고 > 일레븐스퀘어 - 블록체인에서 개발 PM 맛을 좀 보고 > SCVSoft - 지금은 진짜 개발 PM으로 일하는중 > 테크트리이노베이션 --- 일단 저는 지금의 저를 Project Manager라고 소개했죠. 그러니 먼저 제가 참여했던 프로젝트에 대해서도 이야기할 거에요. 그런데, 제가 말하는 내용 중 꽤나 많은 부분이 NDA, 즉 비밀유지계약에 묶여있습니다. 그러니 어지간하면 녹음은 하지 말아주세요. 하셔야한다면... 재밌는 이야기 몇 개를 빼고 가긴 해야죠 뭐... 농담이에요. 제가 적절히 조절해볼게요. 아무튼, 진짜로 시작합니다. ### 2. 사회학적 상상력의 실무 적용 처음 입학한 뒤에 들었던 "사회학적 상상력"이라는 단어는, 세상에 이미 존재하는 너무나 자명한 사실을, 뒤틀고 꼬아서 이상한 언어로 길게 이야기하는 방식이라고만 생각했습니다. 하지만, 사회학적 상상"력"이라 했죠? 따지고 보면 이것도 사실 역량입니다. 그리고 이 역량은 IT 업계에서 이는 매우 구체적이고 실용적인 도구가 됩니다. 일단 사회학적 상상력의 기본 정의부터 짚고 갈게요. > 개인적 경험과 광범위한 사회적 맥락 사이의 관계를 이해하고 연결하는 능력 예를 들어, 어떤 앱의 사용률이 떨어졌을 때, 다른 직군에서는 보통 이렇게 접근합니다: - 마케터: "광고비를 늘려야겠다" - 개발자: "기능을 더 추가해야겠다" - 디자이너: "UI를 더 예쁘게 만들어야겠다" 하지만 사회학도는 다르게 접근할 수 있습니다: - 사용자들의 라이프스타일 변화는 없었나? - 경쟁 서비스의 등장이 시장 구조를 바꾸지 않았나? - 사회적 담론의 변화가 우리 서비스에 대한 인식을 바꾸지 않았나? - 사용자 집단 간의 권력관계 변화는 없었나? 쉽게 할 수 있는 질문이죠? 의외로 어렵지 않아요. --- 참여했던 프로젝트 중 그나마 알려졌을 것들만 소개해보겠습니다. 먼저 [SKT ZEM](https://www.bworld.co.kr/product/btv/zem.do?menu_id=P03050300)입니다. 오늘 강연중에 주로 언급할 프로젝트에요. 이미 출시된지 꽤 오랜 시간이 지났고, 제가 참여했던 기능도 많이 사라져서, 조금 자유롭게 언급하기 좋아서... 아마 계속 이 프로젝트를 예로 들 거에요. ZEM은 자녀보호, 혹은 감시, 뭐 빅브라더 그런 어플리케이션이에요. 혹시라도 썼을 사람 있으면 미안합니다. 버그 찾겠다고 ZEM 안티 카페도 돌아다녔었습니다. 이 프로젝트에서 저는 처음으로 기술이 갖는 윤리적 딜레마를 마주했습니다. 부모의 보호 의지와 자녀의 프라이버시 사이에서, 기술은 과연 중립적일 수 있는가 하는 질문이었죠. 여기서 제가 적용한 것이 바로 사회학적 상상력이었습니다. 이 앱은 단순히 "보호" 기능을 제공하는 것이 아니라, 특정한 가족 모델과 권력관계를 전제하고 있었어요. 유교적 가족관에서 "부모는 항상 옳고, 자녀는 순응해야 한다"는 가정이 기술 설계에 그대로 반영된 거죠. 다음은 [꿀스테이](https://www.coolstay.co.kr/)입니다. 모텔 대실/숙박을 예약해주는 서비스였어요. 대구경북 쪽에서는 나름 알아준다고 하더라고요. 야놀자 잡겠다고 만든 거긴 한데... 덕분에 제 이직은 잡았습니다. 여기서는 티켓 예약 시스템과 커머스, 특히 B2B와 B2C를 동시에 운영하는 서비스를 일관성 있게 제공하려면 어떻게 하는지 많은 고민을 할 수 있었어요. [캠프통](https://www.camptongforest.com/)에서는 가평 빠지에서 수상레저 티켓을 예매하는 부분을 주로 다듬었어요. 홈페이지 예약에서부터 관리자페이지까지 웹서비스 전반을 리뉴얼했고, 키오스크의 화면을 디자인하기도 했어요. "키오스크는 원래 불편해야 제맛"이긴 한데 그래도 제가 싫어서 개선했습니다. 다들 불편함을 당연시할 때, 기획자는 그 사소함을 기어이 찾아내야합니다. [벨리곰](https://bellygom.world/)은 블록체인 쪽인데, 이거 말고는 공개를 못 합니다. 암튼 NFT입니다. 블록체인 쪽은 죄다 NDA 걸고 일하다 보니, 좀 깊게 말하다 보면 민사로 이놈 해요. 근데 제가 다녔던 곳은 정부기관쪽 업무도 있어서 더욱 발언이 곤란하고, 가볍게 NFT 얘기만 할 수밖에 없네요. 현재는 [언리얼로 3D 지도](https://www.tt-inno.com/)랑 이것저것 합니다. 원래도 지리학을 좋아하긴 했었고, 3D 공간 내에서 무언가를 할 수 있어서 재밌어 보였는데, 여기서 만난 사람한테 소개받아서 미술전시도 참여했어요. 이때부터 뉴스 검색에 제 이름과 사진이 같이 뜨기 시작합니다. 다이어트를 좀 미리 해둘 것을 싶어요. 최근에 국립 현대미술관에서 전시했습니다. 들어보신 분도 있긴 할 텐데, <[프로젝트 해시태그](http://projecthashtag.net/)>라는 전시에 <소망사무국> 팀으로 참여했습니다. 그 전시 과정에서 인터뷰할 일이 많았어서 사회학 이야기를 많이 하긴 했고, 꽤 즐거웠어요. 그치만 역시 사회학 이야기는 사회학과에서 해야죠. 밖에서는 사회학 이야기를 할 사람이 정말... 정말 없어요. 국현미 인터뷰에서는 주로 사회학의 구조구성주의, 언어, 타자화를 이야기했습니다. 나의 외부에 있는, 지금 여기에 있지 아니한 것이 "소망"이라 생각했고, 언어화되지 않는 것은 소망이 아니라, 권력자에 대한 의전일 뿐이죠. 그러한 소망을 모았을 때 어떠한 세계가 탄생하는지 이야기했어요. ### 3. 일관성을 찾아서: 주체와 타자의 사회학 제 이력을 보면 뭔가 이상함을 느껴야해요. 찾으신 분? 그냥 제가 말하죠 뭐. 어디에서도 일관성이 보이질 않습니다. 그래서 제가 한 일은 구체적으로 무엇이냐, 그 일을 하려면, 혹은 피하려면 어떻게 해야 하느냐는 질문이 나오게 됩니다. 먼저 일관성 측면을 봅시다. 여기서는 잠시 또 사회학 이야기를 해야 해요. 기든스의 구조화 이론이 IT 서비스 기획에서 매우 유용합니다. 구조(structure)와 행위자(agency) 사이의 상호작용을 이해하면, 사용자 행동을 더 정확히 예측하고 서비스를 설계할 수 있습니다. **구조의 이중성(Duality of Structure) 개념 적용**: - 사용자는 기존 서비스 구조에 의해 제약받지만, 동시에 그들의 사용 패턴이 서비스 구조를 변화시킵니다 - 예: 인스타그램의 스토리 기능은 사용자들의 "일상적 순간 공유" 욕구(행위자)와 "24시간 후 삭제"라는 기술적 제약(구조)이 만나 새로운 소통 문화를 만들어냈습니다 매우 많은 사람들이 "나는 복잡하게 좋은 사람, 쟤는 단순히 나쁜 사람"이라고 이야기해요. 여기서 나를 "우리"로, 쟤를 "그들"로 바꿀 수도 있어요. 나와 우리가 분리된 것은 근대 이후고요, 나와 우리는 반복과 의례(혹은 의례의 반복)를 통해 경계가 흐려진다... 정도는 다들 아시리라 믿어요. 혹은 주체와 타자라고 하기도 하죠. 여기서 UX와 사회학이 연결됩니다. 나에게 쉬운 일이 다른 사람에게는 어려울 수 있고, 그것이 정상이에요. 그래서 우리는 절대 타자인 "사용자"의 입장이 되는 연습을 합니다. 사실 이 부분은, 저의 종교학 경험도 많이 연관되어 있어요. 그리스도교 전통은, 제게는 이래요. "1. 네 이웃을 네 몸과 같이 사랑하라." "2. 어렵냐...? 네가 대접받기 원하는 대로 남을 대접하라." "3. 하... 그것도 안 되겠으면, 네가 당하기 싫은 건 남에게도 하지 말아라." 서비스가, 어플리케이션이, 웹사이트가, 제가 늘 곁에 두는 각종 전자기기가, 쉬웠으면 좋겠다고 생각했어요. 편한 것까지는 바라지 않아요. 내가 예상하는 대로 움직이고, 실수해도 되돌릴 수 있어야죠. 이 무한한 "불편함"만 해소할 수 있다면, 세상의 많은 부분이 나아지리라 생각했어요. 그리고 그 과정이, 제게는, 재밌었어요. 앞서도 이야기했지만, 일단 재밌어보이면, 했어요. 이렇게 말하면 좀 가벼워 보이고, 있어 보이는 말로는 "관심의 지평을 꾸준히 확장하고, 배움을 멈추지 않았다"라고 말해요. 근데 솔직히... 그냥 재밌어보이면 했어요. 무언가 만들고 개선하는 과정은, 엄청나게 재미있어 보였어요. ## 2부: 권력과 기술의 해체 ### 4. 권력이 보이면 해체했어요 이제 좀 더 구체적인 실무 이야기를 해보겠습니다. 제가 할 수 있는 일을 했다고 했는데, 대략적인 카테고리는 사용성 최적화, QA, 아키텍처, 프로젝트 관리 및 문서화입니다. 말은 어려운데, 쉽게 요약하면 이러해요: 문제를 발견하고 해결책을 찾는다. 그런데 여기서 중요한 건, 소프트웨어는 낡는다는 점입니다. 프로그램일 뿐인데 어떻게 낡아가냐면... 소프트웨어는 사회적 맥락에 놓여있기때문에 그래요. 낡지 않고 버티면 그건 레거시가 되고, 레거시는 권력과 매우 유사한 형태로 작동합니다. 음... 이 부분은 잠시 뒤에 좀 더 디테일하게 이야기할게요. 그런데 권력이라는 말 대신, "이데올로기"가 더 편하게 들리는 분들도 있겠죠. 정부과제에서는 "차세대"라는 말로 이데올로기 전환을 시도하기도 하는데, 저는 그냥 "사용성 분석"을 하거나 "리뉴얼 제안"으로 해체를 시도했어요. 여기는 사회학적 상상력과 직접적으로 연결되는 부분입니다. 소프트웨어의 "문제"는 단순히 기술적 오류가 아니라, 그 소프트웨어가 만들어진 사회적 맥락과 권력관계의 문제인 경우가 많습니다. 어플리케이션이나 웹사이트를 최대한 다양한 방식으로 사용하면서 오류를 찾고 수정을 제안하는 QA 과정에서, 저는 사용자를 두 종류만 있다고 가정했습니다. 중학생 천재 해커와 동굴에서 방금 나온 원시인. 이 이분법이 중요한 이유는, 대부분의 소프트웨어가 "normal user"를 가정하고 만들어지는데, 이 "normal"이라는 것 자체가 이미 특정한 사회적 계층과 문화적 배경을 전제하고 있기 때문입니다. 예를 들어, "normal user"는 보통 다음과 같이 가정됩니다: 서울 거주, 대학 교육을 받은 20-40대 남성, 일정 수준 이상의 소득, 스마트폰과 컴퓨터를 다룰 수 있는 기본적 디지털 리터러시, 한국어나 영어를 유창하게 사용할 수 있는 능력. 한 단어로 표현하자면, 정상성. 하지만 실제 사용자는 이런 가정에서 지속적으로 이탈합니다. QA는 둘 모두를 대비하는 작업에 해당합니다. QA 작업까지 해보고 나면, 이제 어떤 방식으로 해야 설계가 가능한지 보이기 시작합니다. 방향성을 알았으니, 이제 직접 만들 수도 있게 된 셈이죠. --- 방금 언급한 **소프트웨어는 낡는다**는 부분에 대해 좀 더 이야기해볼게요. 이는 물리적인 마모가 아니라, 사회적이고 구조적인 낡음을 의미합니다. 낡지 않고 버티면 그건 레거시가 되고, 레거시는 권력과 매우 유사한 형태로 작동합니다. 권력이라는 말 대신, "이데올로기"가 더 편하게 들리는 분들도 있겠죠. 그 맥락으로 이해하셔도 어느정도 비슷합니다. 기본적인 배경지식이 필요할 수도 있어서 간단히 언급해볼게요. 먼저 대부분의 웹사이트는 서비스 제공을 위해 자바스크립트를 사용합니다. 그런데 그 자체로 이용하기는 너무 복잡해서, 누가 미리 만들어둔 도구를 사용해요. 라이브러리, 프레임워크, 패키지...같은 다양한 도구가 이에 해당하죠. 이 도구들은 각자 상호의존성이 있어서, 하나가 망가지면 다같이 망가지는 일이 비일비재합니다. 생각보다 허약한...보다는 뭐랄까, fragile 하다는 용어가 적절하겠네요. 이 fragile 함이 매우 강렬하게 나타났던 사례가, 2016년 초 일어났던 Left-pad 사건입니다. #### Left-pad 사건: 11줄의 코드가 인터넷을 마비시킨 날 2016년 3월 22일, JavaScript 생태계에 대지진이 일어났습니다. **left-pad**라는 단 11줄짜리 npm 패키지가 삭제되면서, 전 세계 수많은 웹사이트와 서비스가 동시에 마비되었습니다. 이 사건은 현대 소프트웨어 개발의 구조적 취약성을 극명하게 드러낸 상징적 사건이 되었습니다. 시작은 매우 평범한 개인적 갈등이었습니다. 애저 코출루(Azer Koçulu)라는 개발자가 npm에 kik라는 패키지를 제출했어요. 그런데 이 이름을 가지고 Kik Interactive라는 회사에서 분쟁을 걸어왔어요. "당장 그 이름을 철회하지 않으면, 변호사가 당신 집 문을 두드릴 것이다."라는 협박성 이메일까지 보냈습니다. 심지어 이러한 분쟁을 중재해야하는 npm 운영진은, 기업 편을 들면서, kik 패키지의 소유권을 Kik Interactive로 강제로 이전했어요. 결국 개발자는 분노해서, 자신이 관리하던 모든 패키지를 npm에서 삭제해버립니다. 이제, 개발자 커뮤니티가 불타기 시작합니다. 근데 세상이 불바다가 된 이야기 하기 전에, 이게 얼마나 사소한 부품이었는지 한 번 짚고 넘어갈게요. 특정한 문자열이 있으면, 그 앞에 0을 추가하는, 매우 간단한 기능을 해요. 코드로 보면 대략 11줄 정도 하고요. 파이썬으로 11줄이면 꽤나 거대한 기능이지만, 자바스크립트에서 11줄이면 간신히 기능 하나 정도 나와요. 근데 문제는, 이 패키지에 의존하는 다른 패키지가 수백 개 정도 됐습니다. 그리고 그 패키지들에 의존하는 패키지들이... 수천 개쯤 됐어요. 결국 React, Babel 같은 주요 패키지가 모두 작동이 중단됩니다. 이제, 세상이 불타기 시작합니다. 넷플릭스, 스포티파이, 페이팔 등 주요 서비스의 배포가 중단됐어요. 큰 서비스는 보통 여러 부품을 조합해서 만드는데, 부품 각각이 맛이 가면서 전체 서비스가 맛이 가버리는 거죠. 기존 기능을 유지보수하거나 새로운 기능을 추가하려는데, 빌드가 안돼서 배포 파이프라인이 꼬여버립니다. 결국, npm은 강제로 Left-pad 패키지를 복원하고, 패키지 삭제 정책까지 바꿔버렸어요. 이 사건은 단순한 기술적 문제가 아니라 **권력관계의 문제**였습니다: ``` npm (중앙 저장소) ↓ 패키지 관리자들 (개별 개발자) ↓ 패키지 사용자들 (전 세계 개발자) ↓ 최종 사용자들 (일반 사용자) ``` 단 한 명의 개발자가 패키지를 삭제하는 것만으로도 전 세계 인터넷이 마비될 수 있는 구조였습니다. 부르디외가 말한 **상징적 권력**의 현대적 변형이라고 봐도 되겠죠. 소수가 갖는 "패키지 삭제 권한"이 막대한 사회적 영향력을 행사할 수 있게 됐습니다. left-pad 같은 기초 패키지들은 "당연히 있어야 하는 것"으로 여겨집니다. 하지만 실제로는 누군가가 만들고, 유지보수하고, 책임지고 있는 노동의 산물입니다. 이런 **보이지 않는 노동**이 갑자기 사라질 때, 비로소 그 가치가 드러납니다. 현대 소프트웨어는 레고 블록처럼 작은 모듈들을 조합해서 만듭니다. 이는 효율성을 높이지만, 동시에 **체인의 가장 약한 고리**가 전체를 무너뜨릴 수 있는 구조를 만들어냅니다. (굿 플레이스) #### 소프트웨어 노화의 다양한 형태 이러한 기본적인 의존성 문제 외에도, 사용중인 모듈 중 하나에 보안 취약점이 생긴다거나, 개발자 커뮤니티 자체가 "물리적으로" 노화되는 경우도 있고, 제도가 변하다보니 프로덕트가 낡은 것처럼 바뀌는 경우도 있어요. 하나하나 다 이야기하기에는 너무 긴 이야기라서, 적당히 넘어갈게요. - [[그래서 인공지능이 대체 뭔가요]] - [[디자인의 사회적 맥락]] #### 기술, 사회, 변증법 소프트웨어의 낡음은 단순히 기술적 문제가 아닙니다. 그것은 권력관계, 제도, 문화가 복합적으로 작용하는 사회적 현상입니다. 사회학적 상상력을 가진 기획자나 개발자는 이런 구조를 읽어내고, 더 민주적이고 지속가능한 대안을 모색할 수 있습니다. Left-pad 사건이 보여준 것은 현대 기술 사회의 취약성이지만, 동시에 변화의 가능성이기도 합니다. 11줄의 코드가 세상을 멈출 수 있다면, 11줄의 코드로 세상을 바꿀 수도 있다는 뜻이니까요. **권력이 보이면 해체하라.** 하지만 그 해체는 파괴가 아니라 재구성이어야 합니다. 그리고 이 모든 일은, 사람을 위해서 행해집니다. IT 업계의 위대하고 완전무결하신 절대 갑, 사용자를 위해서입니다. #### 검색엔진 최적화 프로젝트 그리고 이러한 사용자 중심 재구성을 위해, 프로덕트 자체를 수정한 사례를 이야기해볼게요. 사용성 최적화의 일환이기는 하지만, 개발자가 부족할 때는 저도 개발을 합니다. 회사 홈페이지를 직접 수정해서 사용성을 개선한 사례를 이야기해볼게요. 그 외에도 다양한 개선 사례가 있지만... NDA가 제 입을 막고있어서요. 시작은 되게 간단했어요, 증빙자료 하나 필요해서 사업자등록번호 확인하려고, 회사 이름을 검색했어요. 근데 구글에 안나오더라고요. 그래서 회사 이름을 영문으로 바꿔서 검색하니, 대략 세번째 페이지쯤에서 표시가 되고있었습니다. 마음에 안들었죠. 아무튼 저도 웹을 배우긴 했으니, 회사 홈페이지에 검색 인덱싱용 키워드를 끼워넣는 식으로 고쳐보려고 했어요. 그런데도 여전히 구글 검색 결과에 안 뜨더라고요. 단순히 구글 검색에서 크롤링을 안하는게 문제가 아니라, 홈페이지 구조 자체가 문제임을 깨닫게 됩니다. 그래서 검색엔진 최적화 작업을 진행했어요. 이 과정에서 저는 처음으로, 기술에 내재된 권력관계를 보기 시작했어요. URL 구조를 수정하는 것부터 시작했어요. 기존 URL은 대략 이런 식이었습니다: - `company.com/page.php?id=123&category=news&type=article` 이거를 - `company.com/news/123` 형태로 바꿨어요. 단순한 변경처럼 보이지만, 여기에는 중요한 철학이 담겨있어요. 아, 웹개발에서는 조금 오래된 규칙 중 하나이긴 한데, RESTful URL이라고 합니다. 이 키워드는 제가 직접 설명하기보다는, 직접 검색해서 보시는게 나아요. 기존 URL은 "데이터베이스 중심"적 사고를 반영했습니다. page.php라는 파일이 id=123이라는 데이터를 받아서 처리한다는 개념이죠. 이건 개발자에게는 직관적이지만, 사용자에게는 의미가 없어요. 바뀐 URL은 "사용자 중심"적 사고를 반영합니다. 매우 간단하죠, 회사 홈페이지에 123번째 뉴스를 보겠다는 뜻입니다. article라는 단어도 빼버렸어요. 사용자에게는 불필요한 정보니까요. 다음은 메타태그와 OG 태그 작업이었어요. 구글 애널리틱스와 네이버 웹마스터도 붙였고요. 직접 DB랑 소스코드 까서 성능 최적화까지 진행했어요. 이 과정에서 깨달은 것은, 기술적 문제 해결이 단순히 코드의 문제가 아니라는 점이었습니다. 검색엔진이라는 거대한 알고리즘 시스템과 우리의 작은 홈페이지 사이의 권력관계를 이해해야 했어요. 구글의 알고리즘은 투명하지 않고, 우리는 그 불투명한 규칙에 맞춰서 콘텐츠를 조정해야 합니다. 이건 명백한 권력관계죠. 아까 사용자는 둘뿐이라고 했죠? 해커와 원시인. 여기서는 원시인을 위한 개발입니다. 기능은 있는데, 사람들이 못 찾는 구조가 많더라고요. 그래서 사용자 흐름(User Flow)을 보고, 재정렬했습니다. 기존 내비게이션 구조는 "관리자의 사고방식"을 반영하고 있었습니다. 메뉴가 "회사소개 - 사업영역 - 프로젝트 - 뉴스 - 연락처" 순서로 되어 있었는데, 이건 회사의 조직도를 그대로 웹사이트에 옮겨온 것이었어요. 하지만 사용자의 입장에서 생각해보면, 그들이 우리 사이트에 오는 이유는 "내 문제를 해결해줄 수 있는지 알고 싶어서"였어요. 그래서, 검색 직후 홈페이지에 들어오자마자, 즉시 "목적 페이지"로 이동할 수 있도록, 곳곳에 CTA 버튼을 배치했습니다. > 아 CTA는 Call To Action이라고 해요. 쇼핑몰로 치면 "구매 버튼"이, 게임 소개 페이지라면 "사전 예약"이 CTA에 해당하죠. 그리고 외주를 위주로 돌아가는 에이전시의 경우, 영업 담당자의 연락처가 CTA에 해당합니다. 아무튼 이렇게 간단한 수정만으로... 단순 조회수 50배, 전환률(목적 페이지 도달률)은 대략 10배 정도 늘었어요. 만약 이게 쇼핑몰이었다면, 매출 500배에 해당하는 성과겠지만, 물론 실제 매출은 아니고, "유효 클릭" 정도로만 생각하시면 됩니다. 여기서 중요한 건, 이런 개선이 단순히 기술적 최적화가 아니라는 점입니다. 기존 구조가 왜 그렇게 만들어졌는지, 누구의 편의를 위해 설계되었는지를 이해해야 했어요. 대부분의 경우, 관리자의 편의를 위해 만들어진 구조는 사용자에게는 불편합니다. 이걸 사용자 중심으로 재구축하는 과정이 바로 권력관계의 재구성이죠. ### 5. 기술은 윤리가 없지만, 그걸 사람이 쓰는지라 자본도 기존 권력을 해체하기는 하죠. 하지만 자본은 그걸 둔탁하게 하는 편이고, 예리하게는 오히려 우리가 더 잘 할 거에요. 기술 중립성이라는 신화가 있습니다. 기술은 가치중립적이고, 사용하는 사람에 따라 선악이 결정된다는 이야기죠. 거짓말입니다. 기술은 설계 단계부터 특정한 가치와 권력관계를 내재하고 있습니다. 예를 들어, 페이스북의 타임라인 알고리즘은 "engagement"를 최대화하도록 설계되어 있습니다. 이게 중립적인가요? 아니죠. 분노와 혐오가 engagement를 높인다는 걸 알고 있으면서도, 그 방향으로 최적화된 알고리즘을 만든 거예요. SKT ZEM 프로젝트를 다시 생각해보면, 이 앱은 "자녀 보호"라는 명분으로 만들어졌지만, 실제로는 감시와 통제의 도구였습니다. 부모가 자녀의 스마트폰 사용을 실시간으로 모니터링하고, 특정 앱의 사용을 차단할 수 있는 기능이 있었어요. 이게 보호인가요, 감시인가요? 사실 답은 간단해요. 우리는 도구를 만들 뿐이고, 어떻게 사용할지는 사용자가 결정한다. 전형적인 기술 중립성 논리죠. 하지만 우리가 만든 UI/UX 자체가 이미 특정한 사용 방식을 유도하고 있었습니다. 예를 들어, 자녀가 어떤 앱을 주로 사용하는지의 목록을 부모가 모두 조회할 수 있고, "과도한 사용"이 있다면 부모가 일방적으로 제한할 수 있어요. 하지만 이 "과도한"은 누가 결정할까요? 개발자? 아뇨, 그냥 부모가 결정합니다. 그리고 이 제한 "기능"을 제공하는 것 자체가, 가치판단을 내포하고있다고 봐야죠. 앱 차단같은 경우도, 기능 설명만 보면 매우 단순해요: 부모가 자녀의 특정 앱 사용을 제한할 수 있다. 하지만 실제 구현 과정에서는 수많은 디자인 결정이 필요했어요. 차단되었을 때 어떤 메시지를 보여줄 것인가? 자녀가 이의제기를 할 수 있는 방법이 있어야 하는가? 결국 선택된 방향은 "즉시 차단, 설명 없음, 부모에게 간청 후 추가 사용시간 획득" 방식이었습니다. 쉽게 말하면, 앱을 쓰다가 그냥 사용 불가 메시지 뜨고 끝이에요. 기술적으로는 가장 간단한 방법이었지만, 동시에 매우 거친 방법이기도 했습니다. 그 이유는 우리가 무의식적으로 특정한 "가족 모델"을 가정하고 있었기 때문입니다. 부모는 항상 옳고, 자녀는 부모의 결정에 순응해야 한다는 유교적 가족관이 기술 설계에 그대로 반영된 거예요. 사회학도가 더 예리하게 할 수 있는 윤리적 사고라는 게 바로 이런 겁니다. 기술의 사회적 맥락과 권력관계를 읽어내는 능력이죠. 자본은 이런 것들을 "효율성"이나 "수익성"으로 뭉뚱그려서 처리하려고 하지만, 우리는 그 안에 숨어있는 구조를 볼 수 있어야 합니다. 맥락이 배제된 상태에서 개발이 이루어지면, 사용자에게 전달되는 과정에서 반드시 문제가 발생합니다. 그리고 보통, 대부분의 소프트웨어에는 문제가 존재합니다. 다만 문제를, 혹은 문제에 의한 피해를 최소화하고자, 서비스 출시 전에 QA라는 과정을 거칩니다. 보통 사용자용 어플리케이션은 출시 전에 일정기간 오류수정 기간이 있어요, 베타테스트라고도 하죠. 이때 저는 매우 다양한 경로로 앱을 쓰면서 오류를 찾았어요. 깊게 들어가기는 좀 애매하고, 예를 들어 설명해볼게요. QA에 대한 농담이 있어요. ``` QA 엔지니어가 술집에 들어왔습니다. 맥주를 1개 주문해봅니다. 맥주를 0개도 주문해봅니다. 999999999개도 주문합니다. 도마뱀도 주문합니다. -1개 맥주도 시켜봅니다. ㅋ@태ㄱㄴ먀ㅣ;ㅂ도 주문해 봤어요. 드디어 첫번째 실 사용자가 들어와서는 화장실이 어디냐고 물어봤습니다. 술집은 불길에 휩싸였고, 모두 죽어버렸답니다. ``` 저는 보통 이런 식이었습니다. ``` 낙하산 타고 지붕에 내린 뒤 2층 창문으로 잠입해서 물구나무서기로 계단을 내려가면서 화장실을 주문하면... ``` 보통 그 중간 어디선가 서비스가 터지더라고요. 좀 더 구체적으로는, ``` 인텔칩 8인치 안드로이드 태블릿에서 카톡으로 링크 공유한 다음에 삼성브라우저(베타)에 애드블록 두 개 깔고 폰트 좀 조정해서 마이페이지 직접 열었는데 들어가니 회원가입 버튼 보이기에 눌렀는데 반응없어서 한 다섯 번 정도 더 누르고 길게 눌러서 새 탭에서 열기 몇 번 하면... ``` 이쯤 되면 백엔드는 담배피러가고, 프론트랑 DBA가 같이 와서 멱살을 잡아요. 하지만 이런 극한 QA가 단순히 재미있는 일화는 아니에요. 여기에는 매우 중요한 사회학적 통찰이 담겨있습니다. 이런 극한 상황을 만들어내는 능력이 어디서 오는가 하면, 바로 "상상력"에서 옵니다. 그리고 이 상상력은 사회학적 훈련과 직접 연결되어 있어요. 예를 들어 저는 문화인류학 수업시간에 "일탈행위"를 직접 해보는 과제를 받은 적 있어요. 뭐 불법적인 행동을 하는 것은 아니고, 그냥 "이상한" 행동을 해보는 거죠. 예를 들어 벤치에 커플이 앉아있으면 바로 그 옆에 앉아본다거나, 엘리베이터에 타자마자 뒤를 돌아보고 있는다든지 하는 행동이요. 그리고 놀랍게도, 사용자는 이런 "이상한" 행동을, 매우 당연하게 합니다. 개발자는 사용자가 어떻게 행동한다는 일종의 "페르소나"가 있어요. 하지만 사람은 어떻게든 행동할 수 있고, 예측은 당연히 빗나가요. 여기서 중요한 건, 사회학에서 배운 "일탈"에 대한 이해입니다. 뒤르켐이 말한 것처럼, 일탈은 사회의 정상적인 부분이에요. 모든 사회에는 일정 수준의 일탈이 존재하고, 이는 사회의 경계를 명확히 하고 변화를 이끄는 역할을 합니다. 소프트웨어에서도 마찬가지예요. "정상적인" 사용 패턴만 가정한 시스템은 필연적으로 "일탈적인" 사용에서 문제가 발생합니다. 그리고 이러한 "일탈"의 반대편에는, UX의 중요한 원칙 중 하나인 "일관성"이 있습니다. 일관성은 일탈과는 반대입니다. 지극히 정상적인 흐름을 통해, 그 어떤 "이상함"도 없이, 처음부터 끝까지 동일한 컨셉으로 서비스를 제공하는 거죠. 서비스 흐름 그 어디에도 "일탈"이 없어야한다는 뜻입니다. 서비스가 일관성을 유지하면서 제공된다면, 즉 일탈의 여지 없이 매우 단단하게 제공된다면, 동굴에서 나온 원시인도, 중학생 천재 해커도, 서비스를 "정상적으로" 사용할 수밖에 없게 됩니다. 그리고 이러한 "정상성"을 만들어내는 능력은, 역설적으로, 일탈을 찾아내는 능력에서 나옵니다. 일탈을 찾아내는 능력은, 일관성을 유지하는 능력과 일맥상통합니다. 그리고 이러한 "일탈"은, 보통은 상상조차 하지 않습니다. 보통은 일관성조차 잘 말하지 못해요. 하지만, 우리는 그러한 일관성과 일탈행동을 이야기하는 방법에 대해, 4년 정도는 훈련받고 현장으로 나갑니다. UX 원칙에서 말하는 일관성은, 알고보면 사회학에서 이야기하는 "사회적 사실"과 매우 유사한 개념으로 이해할 수 있습니다. 개인의 행동은 예측할 수 없으나, 사람이 셋 이상 모이면 특정한 패턴이 나타나고, 우리는 그 패턴을 이야기할 수 있어요. 그래서 우리는 사람의 다양한 행동을 바탕으로, 서비스에 미치는 영향을 아주 "자연스럽게" 이야기할 수 있어요. 다른 전공자들은, 이걸 잘 못해요. 신방과? 글쎄요. 심리학과? 개인에 대해서는 잘하죠. 정외과...는 좀 해요. 다만 제도라는 틀을 벗어난 시점에서의 분석은, 여전히 우리가 더 잘 하죠. 다시 QA 이야기로 돌아와볼게요. 여기서 중요한 건, 이런 QA 과정이 단순히 버그를 찾는 작업이 아니라는 점입니다. 사용자의 예상치 못한 행동 패턴을 통해서, 시스템의 숨겨진 가정들을 드러내는 작업이에요. 개발자가 "당연히 이렇게 사용할 것"이라고 가정한 부분들이 실제로는 전혀 당연하지 않다는 걸 보여주는 거죠. 그리고 우리 기획자들은, 이러한 일탈이 존재할 수도 있음을 가정하고, 질문을 던집니다. ## 3부: 스타트업에서의 실전 생존법 - 질문하는 방법과 협업의 기술 ### 6. 잘 틀리면 됩니다 - 가설과 실험의 사회학 이제 슬슬 스타트업 얘기를 해봅시다. 스타트업에서 가장 중요한 역량은 "좋은 질문을 던지는 능력"이라고 봐도 좋습니다. 보통은 질문 대신 "가설"이라는 말을 많이 쓰기는 하죠. 그런데, 좋은 질문이 뭘까요? 좋은 가설이라는 거, 존재는 할까요? 지금은 은퇴하신 김경만 교수님께 들은 이야기입니다. 분명, 좋은 질문은 존재합니다. 질문, 혹은 가설에는 네가지 종류가 존재합니다. - **사소한 것을 말하고 틀린다** → 언급할 가치가 없다 - **사소한 것을 맞힌다** → 학생 때나 그래라 - **중요한 것을 맞힌다** → 도달할 수 없는 목표 - **중요한 것을 건드리고, 크게 틀린다** → 위대한 기록으로 남으리라 그리고 우리는 좋은 질문을 만들어내기 위해 노력합니다. 학술 현장에서처럼, 기업 현장에서도 동일합니다. 그리고 이것이, 제가 오답노트를 쓰기 시작한 이유입니다. #### 좋은 질문 스타트업 환경에서 이 원칙이 어떻게 적용되는지 구체적으로 살펴봅시다. 여기서는 제 사례 대신, 대중적으로 유명한 사례를 이야기해볼게요. 스타트업 현장에서는 이미 지루한 옛날 이야기지만, 분명 처음 들어본 분들도 계실 거라. ##### 사례 1: 에어비앤비(Airbnb)의 초기 가설 **설정된 가설**: "사람들은 낯선 사람의 집에서 잠을 잘 의향이 있을 것이다" **사회학적 분석**: - **신뢰의 사회학**: 현대 사회에서 낯선 이와의 거래는 제도적 신뢰(평점 시스템, 보험 등)를 통해 가능합니다. 이거 얘기했던게 아마 짐멜이었나요? 경제학에서는 보통 이것을 "신뢰 비용"이라고 이야기하기도 합니다. - **공유경제의 사회적 기반**: 2008년 금융위기라는 사회적 맥락에서, "부가 수입 창출"이라는 니즈와 함께, "저렴한 숙박"이라는 니즈가 동시에 생겨납니다. - **도시화와 개인주의**: 또한, 도시 거주자들의 라이프스타일 변화 덕분에, 새로운 형태의 숙박 서비스가 가능해집니다. 즉, 어차피 혼자 사는 집인데 가끔 비우는 경우가 있다면, 그 시공간 자체를 "짧은 기간동안" 거래하기를 원했다는 사실입니다. **검증 과정**: - 시작 자체는 간단했어요, 샌프란시스코에서 에어매트리스 3개로 시작합니다. 공간을 빌려주고, 소정의 숙박비용을 받습니다. 이름을 보면 알 수 있죠? 베드 앤 브랙퍼스트. - 그래서 수요와 공급 양측의 행동 패턴을 관찰하고, 끊임없이 개선합니다. - 현재는 평점 시스템과 보험 제도를 통해, 자체적인 신뢰 제도를 구축하기에 이릅니다. **결과**: - 즉, 기본 가설(저비용 숙박) 자체는 들어맞았으나, 사람들의 기존 행동양식 자체를 수정하지는 않았고, 오히려 기존 방식에 대응하기 위해 자체적인 신뢰 제도를 구축한 셈이죠. - 어쩌면 이 또한, 새로운 이데올로기라고 봐도 좋겠습니다. ##### 사례 2: 우버(Uber)의 한국 시장 진입 **설정된 가설**: "택시보다 편리하고 저렴한 서비스를 제공하면 사용자들이 환승할 것이다" **사회학적 분석**: - **기존 관성**: 아비투스 개념으로 접근하면, 기존 택시이용 습관을 바꾸기에는 기능적 우위만으로는 불가능에 가깝습니다. 이미 사람들은 길에서 손을 들어 택시를 잡는 일을 "당연하다"고 생각하고 있기 때문입니다. - **디지털 격차**: 무엇보다, 이러한 서비스 자체를 이용하는 집단 자체가 그리 넓지 않아요. 당장 우리는 손에 스마트폰을 들고있으면서도, "ㅇㅇ 가려면 어떻게 해요?" 라고 묻는 행인을 본 기억이 있을 거에요. 지도 앱을 열어서 길찾기를 한 뒤에 대중교통 탭을 선택하고 갈아타는 역을 확인해서 가라...는 말이, 생각보다 쉽지 않은 행동이에요. - **규제 권력**: 무엇보다, 기존 택시 산업 뿐만 아니라 정부 규제 기관 간에도 복잡한 이해관계가 얽혀있습니다. 단순히 혁신이라는 관점에서 접근하기에는, 오랜 기간 쌓여온 시스템을 극복하기는 쉽지 않죠. 그래서 우버는 특정 지역에서는 과도한 행운을 누렸으나, 한국이라는 특정 지역에서는 여전히 택시사업 위주로만 작동하고 있습니다. **예상치 못한 변수들**: - 각국의 노동법은 매우 상이한 형태로 작동합니다. 명문법 외에도, 이미 사람들이 당연하게 여기는 "관행" 같은 제약조건이 존재해요. - 무엇보다, 기존 택시 기사들의 조직적 저항을 예상하지 않았습니다. 그리고 그것을 "레거시 권력"으로만 보고 해체하기에는, 오히려 생존권이라는 기본권을 해치기도 합니다. - 여기까지면 어떻게 협상을 통해 개선안을 제기할 수 있겠으나, 이번에는 윤리적 문제가 등장합니다. 플랫폼에 종속된 노동자는 분명 노동을 공급하고 급여에 준하는 금전을 수령하면서도, 노동자성을 인정받지 못하는 경우가 허다합니다. 쉽게 말해, 기업에 필요할 때는 고용 노동자, 불리하다 싶으면 개인사업자가 되는 현실이 있어요. #### 그래서 다시 애자일 스타트업에서는 그 질문을 "가설"이라고 부른다 했었죠? 네 맞아요, 양적방법론에서 부르는 그 가설입니다. 실무에서는 그걸 다른 용어로 부르기는 한데, 그래도 맥락 자체는 동일해요. 그리고 실제로 데이터를 다루면서 매출과 연계되기도 하죠. A/B테스트, 독립/종속 변수, 통제집단... 등 매우 동일한 맥락으로 사용됩니다. 그리고 기획자는 그 "가설"만 잘 세워도 됩니다. 다만 그 검증과정을 잘 만들고, 검증된 이후에는 다음 가설을 세워야죠. 이제 어디서 많이 들어본 용어가 나옵니다, 애자일. 애자일, 스크럼 뭐 그런 용어의 맥락이 다 같아요. 가설을 세우고, 적당한 규모로 실험하고, 증명/반증 이후에 다음 가설을 세워요. 이 과정이 반복되면 끊임없는 개선으로 나타납니다. 그래서, 간단하게 표로 한 번 정리해봤어요. 디테일은 조금 다를 수 있긴 한데, 큰 틀에서는 매우 흡사합니다. | 사회과학 방법론 | 애자일 방법론 | 공통점 | | -------- | ---------- | ------------- | | 문헌 검토 | 시장 조사 | 기존 지식 체계 파악 | | 가설 설정 | 가정 정의 | 검증 가능한 명제 설정 | | 조작적 정의 | 성공 지표 정의 | 측정 가능한 기준 마련 | | 표본 설계 | 타겟 사용자 정의 | 대상 집단 명확화 | | 데이터 수집 | 사용자 피드백 수집 | 경험적 증거 확보 | | 분석 및 해석 | 데이터 분석 | 패턴 인식 및 의미 부여 | | 가설 채택/기각 | 피벗/지속 결정 | 행동 지침 도출 | #### 다시, 사회과학 방법론으로 아 여기서부터는 제 전문분야는 아니에요. 현재 제 커리어는 개발PM쪽에 좀 더 가깝고, 서비스PM쪽하고는 조금 거리가 있어요. 그래도 뭐 지금까지 해온 역량이 어디 가는 것은 아니니까... 간단히 설명하고 넘어가볼게요. 사회과학 방법론을 사용해서 고객 행동을 분석하면, 개인의 경험과 사회적 맥락을 연결하여, 특정 개인의 불편함이 어떠한 구조적 문제에서 기인하는지 파악할 수 있어요. 일반적 접근에서는 단순히 "사용자들이 왜 우리 앱을 안 쓸까?"라고 생각한다면, 사회학에서는 "어떤 사회적 구조가 기존 행동 패턴을 유지시키는가?"라고 질문할 수 있습니다. 혹은 계급과 계층을 분석하여, 일반적인 페르소나인 "2~30대 직장인" 대신에, 사회-경제적 상태(SES) 및 문화적 자본 상태에 따라 세그먼트 자체를 "스토리"의 관점에서 접근할 수 있어요. 무엇보다, 권력관계 자체를 분석하여 접근할 수도 있습니다. 단순히 기존 업체들과 경쟁해서 이기자는 주장을 하는 대신, 기존 권력구조에서 우리가 도전할 수 있는 지점과 연합 가능한 세력은 어디인지 살펴보고, 신규 서비스의 방향성을 결정하기도 합니다. ##### 1. A/B 테스트 사용자 집단을 무작위로 둘로 나눠서, 기능을 조금씩 다르게 제공한 뒤, 사용자 피드백을 수집하는 방식입니다. 과거에는 페이스북이 많이 했고, 요즘은 쿠팡에서 자주 볼 수 있어요. 배분을 하는 것 자체가 이미 연구자의 편향이 들어갈 수 있죠. 하지만 "모든 조건이 동일하다고 가정할 때"라는 기본 전제를 만족하려면, 좀 더 구체적인 세그먼트별 분석이 필요합니다. 사용자의 사회적 배경, 사용 맥락, 사용 동기까지 "최대한 비슷하게" 맞춘 뒤에 테스트를 진행하면, 훨씬 더 신뢰도가 높은 데이터를 얻을 수 있어요. ##### 2. 사용자 인터뷰 혹은 테스트를 위해 인터뷰 대상자를 모집해서, 그 사람이 어떤 방식으로 서비스를 사용하는지 관찰하기도 합니다. 이거는 보통 어느정도 규모가 큰 서비스에서 사용해요. 질적방법론에서 접근하는 방식과 동일합니다. - **일반적 접근**: "이 기능에 대해 어떻게 생각하세요?" - **사회학적 접근**: - 어느정도 구조화된 인터뷰를 통해서, 사용자의 의견을 좀 더 구체적으로 "이해"할 수 있습니다. - 그리고 사용자의 "생활세계" 분석을 통해 맥락을 이해할 수도 있죠. 이거 종교학에서는 아마 "삶의 자리"라는 개념으로 배웠던 것 같은데, 배운지 시간이 좀 지나서 기억이 잘 안나네요. - 그리고, 사용자의 언어 사용 패턴을 파악하여, 담론 분석을 진행할 수도 있습니다. 여기까지 가면 진짜 전문가들이 하는 영역이라, 저는 여기까지는 못해봤네요. 조금 아쉬워요. ##### 3. 참여관찰법 인터뷰만으로는 당연히 정보가 부족할 수 있겠죠? 그러면 이제 직접 사용자 집단으로 들어갑니다. 별도의 배경지식을 제공하지 않고, 아예 그냥 직접 사용해보도록 시간을 주며 관찰하는 거죠. 그런데 이 과정에서 테스트를 진행하는 사람이, 사용자 집단에 섞여들어가서, 사용자의 "생생한" 의견을 청취하기도 합니다. 라포 생성에서부터 서비스에 대한 멘탈모델 분석까지, 다양한 용도로 사용되는 기법입니다. 혹은 상호작용 의례 분석 방법을 사용할 수도 있겠죠. #### 결국 먹고사는 문제로 왜 이렇게까지 하는지 묻는다면, 결국 답은 하나입니다. 사용자의 선택을 받지 못하는 서비스는, 기술력이나 마케팅 여부와 관계 없이, 빠르게 시장에서 사라집니다. 즉, 프로덕트와 시장이 맞물려 돌아가야해요. 이를 보통 PMF(Product Market Fit)라고 부릅니다. 끝없는 수정을 민첩하게 반복해서 시장에서 좀 더 선택받는 "상품"을 만들어내야, 살아남을 수 있어요. 즉, 여기서부터는 개인의 역량이 아니라, 사회라는 맥락이 더 중요해진다는 뜻입니다. 맥락을 이해하지 못하는 상품은, 서비스는, 즉 프로덕트는, 빠르게 소멸합니다. ### 7. 다시 사람을 봅시다 #### 왜 천재는 없는가 현대 사회에서는 천재란 존재하지 않습니다. 이 부분도 김경만 교수님께 들은 이야기이긴 한데요. 개인이 세상을 바꾼 사례는 존재하지 않습니다. 인문학에서는 천재가 존재하지 않죠? 물론 학계라는 장 안에서야 수련과 인정 과정이 더 중요하기 때문이라고는 합니다. 하지만, 스타트업이라는 장에서는 다르려나요? 결론부터 이야기하자면, 별 차이 없습니다. 많은 사람들이 스티브 잡스를 천재라고 부르지만, 사회학적으로 분석해보면 다른 그림이 보입니다: - **구조적 조건**: 1970년대 실리콘밸리의 특수한 환경 (히피 문화 + 기술 혁신) - **협업 네트워크**: 스티브 워즈니악의 기술력, 애플 팀 전체의 기여 - **시대적 배경**: PC 혁명이라는 사회적 변화의 흐름 - **제도적 지원**: 벤처캐피털 시스템, 대학-산업 연계 구조 잡스는 뛰어난 개인이었지만, 그의 성공은 개인적 천재성보다는 **사회적 조건들의 우연한 만남**에서 비롯된 것입니다. 혼자서는 세상을 바꾸지 않고, 보통은 협업을 통해 바꿉니다. 그리고 협업을 위해서는 소통이 필요하죠. **전형적인 스타트업 협업 구조:** ``` 기획자 ↔ 개발자 ↔ 디자이너 ↓ ↓ ↓ 마케터 ↔ 데이터분석가 ↔ QA ``` 이외에도 규모가 커지면 경영, 재무, 영업, 인사 등의 담당자가 "이해관계자"로서 프로덕트 개발에 참여하게됩니다. 그리고 각 이해관계자는, 각기 다른 언어로 이야기합니다. 당장, 제가 지금까지 말한 것 중에서 못알아듣은 단어가 꽤 많으셨을 거에요. 지극히 정상입니다. 기획자는 이 과정에서 "통역가"로서 프로덕트 개발이라는 전장에 참여합니다. 그리고 개발 자체가 체계적인 과정으로 이루어지도록 통제하기 위해, 문서라는 수단을 사용하죠. #### 언어가 현실을 구성합니다 소통은 언어로 하지만, 기록이 없다면 평가기준도 없고, 평가기준이 없다면 의사결정이 불가능하므로, 모든 "일"은 문서로 이루어져야 합니다. 스타트업인데 왠 문서냐고 물으시냐면... 슬랙 메시지도 문서고, 지라나 아사나의 티켓도 문서입니다. 기술 문서는 당연히 문서고요. 그러니 이제, 실제 문서를 한 번 봅시다: 1. **요구정의서** - 권력관계의 명문화 2. **정보구조** - 지식 체계의 물질화 3. **[[화면정의서]]** - 사용자 경험의 설계 > [로제타](https://www.figma.com/design/h4rMFw8UPU5cWOAMpLEJnd/Rosetta?node-id=18-640&t=BRVpYH7MVbjiWEkQ-4) 4. **와이어프레임** - 상호작용의 시각화 > [로제타](https://www.figma.com/design/h4rMFw8UPU5cWOAMpLEJnd/Rosetta?node-id=0-1&p=f&t=BRVpYH7MVbjiWEkQ-0) 5. **프로토타입** - 가능성의 구현 > [로제타](https://www.figma.com/proto/h4rMFw8UPU5cWOAMpLEJnd/Rosetta?node-id=13-8&p=f&t=ZrkzGKBdP4Ms4jX5-1&scaling=min-zoom&content-scaling=fixed&page-id=0%3A1&starting-point-node-id=13%3A8) 6. **GUI 가이드** - 일관성의 표준화 7. **업무티켓** - 노동 과정의 세분화 8. **위키** - 집단 지식의 축적 ##### 문서를 통한 권력관계의 재편 **사례: 요구정의서 작성 과정에서의 권력 게임** - 고객사 담당자: "사용자가 로그인하면 대시보드가 나와야 해요" - 기획자의 번역: "사용자 인증 후 개인화된 정보 화면 제공" - 개발자의 해석: "JWT 토큰 검증 후 사용자별 데이터 렌더링" - 최종 요구사항: "로그인 성공 시 사용자 권한에 따른 차별화된 대시보드 화면을 3초 이내에 로딩하여 표시한다" 이 과정에서 보이는 것: - **언어의 정치학**: 같은 요구사항이 서로 다른 전문 용어로 번역됨 - **권력의 재분배**: 모호한 요구사항이 구체적 기능으로 변환되면서 해석 권한이 이동 - **책임의 명확화(혹은 관료제화)**: 문서화를 통해 각자의 역할과 책임 범위가 확정됨 ##### 업무 프로세스의 사회학적 분석 각 문서는 실무에서 어떻게 사용되는지도 볼게요: **1. 요구사항 분석 단계** - 사람은 자신이 무엇을 원하는지 잘 모르고 - 어디까지 개발이 가능한지도 모르고 - 만드는 데 얼마나(시간이든 금액이든) 필요한지도 몰라요 - 그래서 이 과정을 구체화하고, 계약서에 준하는 문서로 정제해요 **2. 기획 단계** - 무엇을 해야할지 큰 그림이 나왔으니, 이제 세부 업무로 분해합니다 - 분해된 세부 업무를 WBS(Work Breakdown Structure)라고 부르고 - 이 업무 각각에 종속성이나 선후관계, 일정이 부여되면 Gantt Chart가 됩니다 **3. 개발 단계의 문서들** - 그리고 이러한 세부 기능의 동작방식을 "고정"하기 위해 설계 단계를 진행합니다 - 와이어프레임과 프로토타입을 통해 의사결정을 진행하고 - 화면정의서를 통해 세부 동작방식을 구체화합니다 - 사용자 경험의 사전 구성이라고 보면 좋아요 - 그리고 이제 협업 단계로 넘어가요 - 여기서부터는 개발문서라서, 제가 언급하기엔 애매한 부분이니 패스할게요 **4. QA와 납품** - 개발이 마무리되는 단계에서, 납품 전에 품질을 테스트해야합니다 - 개발 초기 단계에서 요구정의서를 만들었죠? 그 문서를 기반으로 테스트케이스를 작성합니다 - 테스트케이스는 이 프로덕트가 일정 "기준"을 통과하는지 확인하는 절차입니다 - 일종의 통과의례라고 생각하시면 대충 비슷해요 - 이후, 배포 단계로 넘어갑니다. 즉, 마켓으로 나오는 거에요. 이렇게 한 프로젝트가 끝났습니다. 그럼 이제 무엇을 해야할까요? 다음 질문을 던질 차례입니다. ### 8. 일상과 이상 사이에서 #### 소망사무국 [소망사무국](https://www.mmca.go.kr/exhibitions/exhibitionsDetail.do?exhFlag=1&exhId=202403250001774) 전시에 참여하게 된 계기가 있어요. 보통 소원을 물어보면 각자 다양한 소원이 있기는 한데, 저는 언제나 망설임 없이 "세계평화"를 말했어요. 그래서 전시에 참여할 캐릭터도 평화와 심판의 상징으로서 "고래"를 맡았고요. 그리고, 그 소망이 이루어지는 세계를 보고 싶었어요. 국현미(국립현대미술관) 인터뷰에서 말했던 내용을 다시 정리해보면: - **구조구성주의**: 현실은 고정된 것이 아니라 끊임없이 구성되는 과정 - **언어의 정치학**: 언어화되지 않는 것은 소망이 아니라 권력자에 대한 의전 - **타자화의 극복**: 나의 외부에 있는 것들을 하나의 언어로 엮어내기 그래서, 세계평화가 이루어진 세계는 어땠냐면... 참혹하지만 만족스러웠어요. 또다른 "재미있는 일"을 했고, 그래서 꽤나 즐거웠습니다. #### 결국 먹고사는 문제라니까요 근데, 그래도 밥벌이는 필요하죠. 뭘 하고 싶은지 잘 몰랐는데, 그래도 재미있는 일을 하며 살고 싶었어요. 보통의 경우 30~60세, 그 중 1/3을 일터에 바쳐야 해요. 그래서, 하고 싶은 일을 선택했어요. 밥벌이라는 "의무"를 다해야 하긴 하지만, 그래도 우리는 직업 선택의 자유가 있잖아요? 분명 자본은 중요한 논리로 작동하지만, 자본 논리를 생각했으면 애초에 사회학을 선택하지 않았겠죠. 그리고 여러분 정도면 어지간해서는 굶지 않을 거예요. **직업으로서의 학문:** 베버는 학문을 "직업"과 "소명"의 두 측면에서 봤죠. IT 업계에서도 마찬가지입니다. 단순히 돈을 벌기 위한 직업이 아니라, 기술을 통해 사회를 더 낫게 만든다는 소명 의식으로 접근하면 더 좋겠네요. 그리고, 그 과정이 즐겁다면 더 좋겠고요. #### 어쩌다 PM이 되어 ##### 1. 비판적 거리두기 - 기술 결정론에 빠지지 않기 - "효율성"이라는 이름으로 포장된 권력관계 간파하기 - 사용자를 "매출"이 아닌 "시민"으로 보기 ##### 2. 구조적 사고 - 개별적 현상을 사회적 맥락에서 이해하기 - 단기적 성과와 장기적 변화 사이의 균형 잡기 - 의도하지 않은 결과(unintended consequences)에 대한 민감성 ##### 3. 윤리적 성찰 - 기술의 사회적 영향에 대한 지속적 고민 - 다양한 이해관계자들의 목소리 경청하기 - 권력의 재생산이 아닌 권력의 민주화를 위한 기술 설계 ## 그러니, 가슴뛰는 일을 합시다 저는 사회학과에서 이론을 공부하기는 했으나, 사람을 보는 방식을 더 많이 배웠습니다. 그리고 이러한 "방식"은, IT 스타트업이라는 환경에서도 여전히 유효한 도구로 기능합니다. 1. **맥락적 사고**: 기술적 문제를 사회적 맥락에서 이해 2. **비판적 분석**: 당연시되는 것들에 대한 의문 제기 3. **소통 기술**: 서로 다른 전문 영역 사이의 번역 능력 4. **윤리적 민감성**: 기술의 사회적 영향에 대한 성찰 5. **변화에 대한 개방성**: 사회 변화의 흐름을 읽고 적응하는 능력 6. 그리고 가장 중요한, **학습 능력** 사회학적 상상력으로 무장한 여러분이라면, IT 스타트업에서도 충분히 "살아남을" 수 있을 뿐만 아니라, 기술이 좀 더 인간적인 방향으로 발전하도록 기여할 수 있을 것입니다. 그러니, 겁내지 말고, 가슴뛰는 일을 합시다. --- ## 질의응답 시간 주요 예상 질문들: - 사회학과 출신이 IT 분야에서 겪는 현실적 어려움은? - 사실 어려움은 없어요, 다들 저보다 잘 모르더라고요 - 초창기에는 최대한 사수를 의지하세요 - 제가 사수 없는 환경에서 굴렀다가 아주 잠깐 사수가 생겼었는데, 그때 제일 많이 배웠어요 - 그리고 "학습"이라는 역량만 충분하다면, 어딜 가서도 잘 버틸 거고 - 여러분의 학습 능력은... 생각보다 대단합니다 - 서강대생이라는 짬빠가 어디 가는 것은 아니라서요 - 무엇보다 디자이너가 자기는 개발 잘 모른다고 할 때 써먹을 수 있어요 - "저는 디자이너라 잘 몰라요" - "어라 저는 사회학과인데" - "예?" - "예" - 기술적 지식이 부족한 상태에서 어떻게 PM 역할을 수행할 수 있는가? - 요즘엔 GPT 좋아요 - 학교 이메일만 있으면 돼요 - 대학생이시면 10월까지 구글 제미나이 가입하세요, 1년 무료 줍니다 - 퍼플렉시티도 1년 무료일텐데 한 번 확인해보시지요 - 깃허브도 괜찮아요, 학교 다니는 동안에는 코파일럿 무료 줍니다 - 스타트업의 빠른 속도와 사회학적 성찰 사이의 균형을 어떻게 맞출 것인가? - 의외로 느려요, 우리의 사고가 더 빠릅니다 - 윤리적 고민과 비즈니스 성과 사이의 갈등을 어떻게 해결할 것인가? - 보통 큰 기업은 윤리팀이 있을 거에요, 자주 연락하세요 - 아니면 일단 법과 제도를 먼저 리서치하세요, 거기 최소 조건이 있어요 - 제도를 해킹하기 전에, 먼저 사용성에 대해 그로스해킹부터 시도하세요 - 그리고 이 부분은 [구글(혹은 알파벳)의 행동 강령](https://abc.xyz/investor/google-code-of-conduct/)을 한 번 봐주세요 - Don't Be Evil - 사악해지지 않아도 돈을 벌 수 있어요 - 뭔가 잘못됐다고 생각한다면, 일단 이야기하세요 - 그리고 아니다싶으면... 도망쳐도 됩니다 - 사회학도가 IT 스타트업에 입사하기 위해 필요한 구체적인 준비 사항은? - 우선 JD를 보세요 - 코딩을 전혀 모르는데 괜찮을까요? - 생활코딩의 WEBn 과정을 추천합니다. - 이 과정은 소개문구 자체가 걸작이에요 - 앞으로 개발을 계속 할 사람에게는 입구가, 개발과 관련 없는 삶을 살 사람에게는 출구가 되는 강의입니다. - 디자이너와 이야기할 때 자주 부딛히는 지점이기도 한데요 - 보통 이렇게 말해요: 네가 표현하는 예술의 매체 특성을 몰라도 되겠냐? - 알면 더 할 수 있는 영역이 많아져요 - 그런데... 요새는 GPT가 진짜 잘 합니다 - 저는 아예 답변들만 따로 모아서 개인용 위키를 만들었어요 - 저의 [[UX 기획 서요한|포트폴리오]]를 봐주세요 - 기획자 외에 다른 직군은 어떤가요? - 개발자와 디자이너는 전혀 다른 분야니까 일단 논외로 하고요 - 홍보를 좋아한다면 마케터 - 사람 좋아한다면 영업 > 이 부분은 기술영업 분야도 있어요 - 쉬운 글을 좋아한다면 UX 라이팅 - 기술 문서를 좋아한다면 테크니컬 라이터 - 공무원이 잘맞는다면 사업기획 - 그 외에도 더 있겠지만... 저와 업무상 접점이 있는 직군은 이정도겠네요 - 대기업 vs 스타트업 선택 기준은? - 갈 수만 있다면 당연히 대기업을 가세요, 보통은 시작점이 달라집니다 - 부품으로 살기 싫다고요? 기본기를 쌓는 과정이라고 생각하세요 - 기본기가 많이 쌓이면, 할 수 있는 일이 더더욱 많아집니다 - 제 기술에는 근본이 없어요, 이게 좀 아쉽긴 하네요 - 경력 쌓이면 사실 스타트업이 좀 더 낫기는 해요 - 1인분을 한다는 말은, 어디에 던져져도 버틸 수 있다는 뜻이에요 - 기획자의 권력이란? - 사실 이걸 권력이라 해도 되는지 모르겠어요. 가장 많은 이해관계자와 이야기하고, 가장 많은 문서를 남겨서, 가장 많은 방향성에 개입한다지만... - 생각해보면 기획자는 가장 큰 족쇄를 걸고있다고 생각해도 좋겠네요. - 여성으로서 IT업계에서 겪을 수 있는 어려움은? (이건 GPT 추천 질문이에요) - 일단, 저는 시스젠더 헤테로 남성으로서 말한다는 점을 염두에 두시고 - IT 업계는 "그나마" 성차별이 덜한 분야이기는 합니다 - 다만 한국이라는 맥락에서는 여전히 성차별이 존재해요 - 번아웃을 경험한 적이 있다면? - 있어요, 많아요 - 다행히 저는 사진이라는 취미를 가지고있고 - 번아웃이 올 때쯤이면 휴가가 꽤 많이 쌓여있더라고요 - "이 차에 치이면 출근 안해도 된다"는 생각이 드는 순간, 일단 휴가를 씁니다 - 먹고 "살기" 위해 일하는데, 삶을 구하지 않는다면... 좀 도망쳐도 됩니다 ## 마무리 오늘 강연을 정리하겠습니다. 1. 사회학적 사고는 IT 현장에서 차별화된 경쟁력입니다 2. 기술은 중립적이지 않으며, 우리의 관점이 필요합니다 3. 협업과 소통 능력이야말로 가장 중요한 생존 스킬입니다 마지막으로, 혹시 오늘 이후에 개별 상담이나 포트폴리오 피드백이 필요하신 분은 제 이메일로 연락 주시기 바랍니다. 여러분의 성공적인 커리어 전환을 응원합니다.