강연 주요 내용
1. 강연 시작 및 개인적 배경
- 하버드 CS50 강연자로 소개됨. 당시 페이스북은 이미 2,000개 이상 학교에서 사용.
- 저커버그는 자신이 수강했던 CS 과목들이 페이스북 개발 과정에서의 의사결정에 어떤 영향을 미쳤는지 설명하고자 함.
- CS121은 수강했으나 CS50은 수강하지 않았다고 밝힘 (룸메이트이자 공동창업자 더스틴 모스코비츠가 CS50 수강).
2. 페이스북 초기 개발 및 기술적 결정 (PHP, 아키텍처)
- 사이트는 PHP로 작성됨. C언어 배경이 있으면 PHP는 며칠 만에 배울 수 있다고 언급.
- 2004년 2월 하버드에서 론칭 후 몇 주 만에 수천 명 가입, 다른 대학에서도 론칭 요청.
- 당시 CS161(알고리즘 과목으로 추정) 수강으로 바빠, 룸메이트 더스틴이 확장 작업 담당. (더스틴은 주말 동안 "Perl for Dummies"를 사서 공부하고 돌아와 PHP를 익혔다는 일화 소개)
- 첫 번째 주요 아키텍처 결정: 데이터베이스 분산.
- 문제점: 사용자 간의 연결 관계(친구의 친구 등) 계산은 친구 수(n)에 따라 n², n³ 등으로 연산량이 기하급수적으로 증가. (프렌스터가 이 문제로 어려움을 겪었다고 언급)
- 해결책: 사용자의 활동 대부분(약 90%)이 소속 학교 내에서 이루어진다는 점에 착안, 각 학교별로 MySQL 데이터베이스 인스턴스를 분리.
- 효과: 연결 관계 계산 범위를 학교 내로 한정하여, 전체 사용자(당시 600만)가 아닌 학교별 사용자(약 1만) 기준으로 연산량을 크게 줄여 확장성 확보.
- 초기에는 한 대의 서버(임대)에서 웹서버(Apache)와 데이터베이스를 함께 운영.
- 학교별 DB 분산 덕분에 서버를 선형적으로 증설하며 확장 가능.
3. 인프라 최적화 (서버 분리, 캐싱 계층)
- 30~50개 학교로 확장 후 성능 최적화 필요성 대두.
- 웹 서버와 데이터베이스 서버 분리:
- 문제점: 웹/DB 통합 서버 장애 시 전체 서비스 중단, 학교별 사용량 편차(펜스테이트 5만 명 vs. 소규모 학교 2천 명 미만)로 인한 비효율.
- 해결책: 웹 서버(Apache) 풀을 구성하여 로드 밸런싱, 데이터베이스 계층은 독립적으로 유지.
- 캐싱 계층 도입:
- 일일 페이지뷰 1억 건 도달 시 MySQL 병목 발생 (쿼리당 2-4ms, 페이지당 30-50개 쿼리).
- 오픈소스 Memcache를 사용하여 캐싱 계층 구축, 접근 시간 0.3-0.5ms로 단축.
- Memcache의 문제점: 분산 해시 테이블이지만, 특정 노드 다운 시 데이터 중복성 부재로 DB 부하 급증.
- 결국 Memcache와 MySQL 인덱스 위에 자체적인 추가 중복성 계층을 구축.
4. 질의응답 (경쟁, 기술 공개, 채용, 법률, 사진 기능 등)
- 경쟁에 대한 생각:
- 구글 같은 대기업의 위협보다, 현재는 개인이 적은 비용으로 강력한 기술을 활용해 큰 영향력을 발휘할 수 있는 시대임을 강조. (예: 페이스북은 적은 서버와 인력으로 구글보다 많은 페이지뷰 처리)
- 분산 해시 테이블(DHT) 라이브러리 공개 여부:
- Memcache를 확장하기보다 자체적으로 많이 구축. 오픈소스로 공개하는 것은 경쟁 우위 및 지원/라이선스 문제로 어렵다고 토로.
- 자체 개발한 검색 서버(앤드류 맥컬럼이 개발)의 오픈소스화도 고려했으나 라이선스 문제로 보류.
- 현재(2005년) 주된 업무:
- 인재 채용. 기술이 보편화될수록 사람의 중요성이 커지며, 똑똑한 인재 확보가 핵심.
- 새로운 기능 디자인. 아직 관료주의는 적다고 언급.
- 법률 자문의 중요성:
- 초기에는 법률 문제보다 제품 개발에 집중. 나중에 일부 문제가 생겼으나, "일단 만들고 나중에 사과하는 것"이 더 낫다고 생각하는 경향.
- 구글, 야후, 이베이 등 성공한 많은 회사들이 처음부터 완벽한 법률 검토를 하지는 않았을 것이라고 언급.
- 회사의 아이디어 고갈 시점 및 대처:
- 모든 회사는 핵심 아이디어에서 시작하며, 그 아이디어에 대한 창업자의 독특한 이해가 성공 요인.
- 그러나 다른 분야에 대해서는 다른 사람과 마찬가지이므로, 똑똑한 사람들로 주변을 채우는 것이 중요.
- 사진 기능 및 태깅:
- 사진 태깅을 통해 프로필과 연결하는 것이 핵심. 이는 네트워크 효과(ubiquity of usage)가 있어야만 가능.
- 기술 선택 및 도입 과정:
- 똑똑한 사람들을 신뢰. 회사 내 소수의 뛰어난 엔지니어들이 기술적 방향을 제시하면 지지하는 편.
- 목표 지향적 접근. (예: 사진 기능 - 무제한 업로드 목표)
- 처음에는 대용량 스토리지 업체(NetApp) 고려.
- 결국 분산된 소형 박스(HDD+RAM)와 캐싱 계층으로 아키텍처 설계.
- 네트워크 병목 문제(라우터 처리 용량 한계) 발생 -> 클라이언트 사이드 압축(Java 애플릿, ActiveX 컨트롤)으로 해결.
- 업로드 급증으로 인한 속도 저하 -> 에지 캐싱(Akamai 등)으로 정적 콘텐츠 분산.
- "기술적 천재성"보다는 각 단계에서 문제를 예상하고, 옵션을 평가하여 적절한 결정을 내리는 능력의 중요성 강조.
- 소프트웨어 엔지니어링 문화 (협업 방식):
- 능력주의 지향. 최고의 해결책을 가장 빠르고 버그 없이 구현하는 사람이 주도권.
- 신입은 우수 인력과 협업하며 스타일과 방법론을 배움.
- 반복적 프로세스. 처음부터 완벽할 필요는 없으며, 아키텍처를 올바르게 설계하는 것이 더 중요. (MS나 구글 베타 출시 사례 언급)
- CS 지식 습득 방법:
- 주로 인터넷을 통해 필요한 지식을 습득.
- 특정 기술 보유자보다 "원초적 지능(raw intelligence)"을 가진 젊은 인재 선호. 빠르게 배울 수 있기 때문. (더스틴은 경제학 전공, 스탠포드/버클리 EE 전공자, 수학 전공자 등 사례)
- 채용 우선순위 (기술 vs. 사업):
- 단순히 사업 기술만 가진 사람은 채용하지 않음.
- 핵심 CS 지식(복잡성, 확장성 등)은 사업에서도 매우 중요.
- 단기적 수익 극대화보다 장기적 가치 극대화를 위해 지속적으로 인프라 구축에 투자.
- 트래픽 피크 타임:
- 새벽 5시에는 사용자 적으나, 밤 9시(태평양 표준시)에는 동시 접속자 40만 명 육박. (TV 프로그램 '라구나 비치' 방영 시 트래픽 급감 일화)
- 데이터 삭제 및 보관 정책:
- 현재(2005년)는 삭제된 정보를 보관하지 않으나, 미래에는 할 수도 있다고 언급.
- 개인 정보 보호 및 보안:
- 정보가 원하는 사람에게만 공개되도록 하는 것이 핵심.
- 초기에는 같은 학교 학생들끼리만 프로필 열람 가능. (스탠포드 학생이 하버드 학생 휴대폰 번호를 알 필요는 없다는 논리)
- 민감 정보(휴대폰 번호 등)는 공개 범위 세분화.
- 사용자 정보 오용 방지:
- 사용자가 일단 정보를 공개하면 통제하기 매우 어렵지만, 정보 공개 범위를 사용자가 직접 설정하도록 하는 것이 최선.
- "담벼락(The Wall)" 기능의 변화:
- 초기에는 30분 만에 만든 기능. 마우스를 올리면 누가 작성했는지 보여주는 위키 방식이었으나, 복잡하고 제대로 작동하지 않음.
- 이후 게시물 상단에 작성자 사진과 이름을 바로 표시하도록 개선.
- 페이스북 창업 아이디어의 근원:
- 단순히 "사람 이름을 입력해서 그 사람에 대한 정보를 얻을 수 있으면 멋지겠다"는 생각에서 시작.
- SMS 알림 기능:
- SMS 게이트웨이는 이메일 대응 기능이 있어, 특정 이메일 주소로 메일을 보내면 휴대폰으로 문자 전송 가능 (무료).
- 대량 발송 시 안정성을 위해 직접 휴대폰으로 문자 메시지를 보내는 방식으로 전환 중.
- 마이스페이스와의 경쟁:
- 마이스페이스와 경쟁한다고 생각하지 않으며, 다른 종류의 애플리케이션이라고 생각.
- 이메일 주소 이미지 처리 이유:
- 페이지 스크레이핑을 통한 이메일 주소 수집 및 스팸 발송 방지 목적. 이미지로 처리하여 자동 수집을 어렵게 함.
- 비정상적인 프로필 조회 패턴을 감지하는 베이즈 필터 사용.
- 사용자 데이터 활용 (익명 통계):
- 개인 정보 보호에 매우 민감.
- 집계된 익명 통계(예: 하버드 학생의 2%가 자유지상주의자)를 공개할 예정. 흥미롭지만 매일 찾아보는 정보는 아닐 것.
- 향후 공개될 기능 (2005년 말 ~ 2006년 초 예상):
- 통계 정보: 트렌드, 놀라운 통계 등을 집계하여 공개.
- 관계 명확화 기능: 친구 관계의 깊이를 표현하는 기능. 단순 친구 여부가 아닌, "CS50을 같이 수강했다", "같은 집에 살았다" 등 양방향적이고 사실에 기반한 관계로 표현. 각 관계의 시점도 중요하게 고려. (예: 어제 친구가 된 것과 3년 전 CS50을 같이 들었던 것은 다른 의미)
- 아이디어 유출 우려:
- 팔란티어는 독특한 플랫폼을 가지고 있어 다른 회사(구글 포함)가 쉽게 모방하기 어렵다고 생각.
- 사진 태깅 기능도 네트워크 효과(모든 주변인이 사용해야 유용) 때문에 모방이 쉽지 않음.
- 아이디어 실행 및 협업 방식:
- 직원들이 자유롭게 아이디어를 내고 코드베이스를 실험. (예: "if user is me, then...")
- CEO 오피스 아워 등을 통해 직원들이 개발 중인 기능을 공유.
- (예시) 프로필 변경 사항 하이라이트 기능: 직원이 개인적으로 만든 기능에서 아이디어를 얻어 전체 기능으로 발전 고려.
- 프로필 페이지 디자인 일관성 유지 이유:
- 페이스북의 주 목적은 '인명 디렉토리'이므로, 모든 페이지 구조를 동일하게 유지하여 정보 검색 용이성 확보. (예: '미혼/기혼' 상태를 찾기 위해 페이지를 스캔할 필요 없음)
- 사용자별 CSS 변경 허용 시 가독성 저해 우려 (예: 검은 배경에 진한 파란색 텍스트).
- 고등학생용 페이스북의 성공 및 차이점:
- 사람을 검색하고 정보를 얻고자 하는 것은 핵심적인 인간의 욕구이므로 고등학생에게도 유용.
- 성장세는 하루 5,000명 이상으로 양호.
- 대학 버전과 달리 고등학생 버전은 "파티" 기능 삭제 (부모 반발 및 미성년자 음주 문제 우려), 연락처 정보 비중 축소 등 일부 기능 조정.
- 창업 초기 비즈니스 의도:
- 처음부터 완전한 사업체를 의도한 것은 아님. 단순히 "사람 이름을 입력해서 정보를 얻을 수 있으면 멋지겠다"는 생각으로 시작.
- 부모님은 페이스북 이전 프로젝트로 인해 퇴학당할 뻔했던 저커버그의 새 아이디어를 이해하지 못했으나, 지금은 인정한다고 함.
- 추천 CS 과목:
- 가장 어려운 과목을 수강하라. 도전할 때 가장 많이 배울 수 있음. (CS161, CS121, CS124 언급)
- CS124 (데이터 구조 및 알고리즘): 가장 효율적인 알고리즘 구현도 중요하지만, 효율적인 프레임워크(기반 설계)를 잘 구축하는 것이 더 중요함을 가르쳐 줌. 이것이 페이스북 확장에 큰 도움.
- 사용 편의성 및 아이디어 구현 과정:
- 직원들이 자유롭게 아이디어를 내지만, 사이트에 적용되기 전에는 많은 검토를 거침 (저커버그도 최종 확인).
- 직원의 아이디어가 최종 버전이 아닐 수 있음. 아이디어의 핵심 개념은 좋지만, 인터페이스나 구현 방식은 개선될 수 있음 (프로필 변경 하이라이트 기능 예시). 아이디어는 상향식으로도, 하향식으로도 나올 수 있음.
- 고등학생 사진 및 개인 정보 필터링:
- 기술적/조직적 해결책보다 사회적 압력을 긍정적으로 활용.
- 마이스페이스는 직원의 1/3이 음란물 모니터링에 투입되지만, 페이스북은 실명 및 실제 학교 이메일 사용으로 인해 음란물 업로드가 거의 없음. 이것이 복잡한 기술적 문제에 대한 간단한 사회적 해결책이라고 설명.
핵심 메시지
- 문제 해결에서 출발: 성공적인 서비스는 거창한 사업 계획보다 사용자의 실제 필요와 문제를 해결하려는 순수한 동기에서 시작된다.
- 빠른 실행과 반복적 개선: 처음부터 완벽을 추구하기보다 빠르게 실행하고, 사용자 피드백과 데이터 분석을 통해 지속적으로 개선해 나가는 것이 중요하다.
- 기술적 토대의 중요성: 확장 가능하고 효율적인 시스템 아키텍처 설계는 서비스의 장기적인 성공에 매우 중요하다. (데이터베이스 분산, 캐싱 전략 등)
- 인재의 핵심은 학습 능력: 특정 기술 보유보다 뛰어난 지능과 빠른 학습 능력을 가진 인재가 장기적으로 더 가치 있다.
- CS 교육의 실용적 가치: 대학에서 배우는 컴퓨터 과학의 근본 원리(알고리즘, 데이터 구조, 복잡도 분석, 시스템 설계 등)는 실제 복잡한 시스템을 만들고 확장하는 데 매우 실질적인 도움이 된다.
- 사회적 맥락 고려: 기술적 해결책만큼이나 서비스가 사용되는 사회적 맥락을 이해하고, 사회적 압력이나 문화를 긍정적으로 활용하는 것이 중요하다.
이 강연은 2005년이라는 초기 시점에서 마크 저커버그가 가졌던 페이스북에 대한 비전, 기술적 접근 방식, 그리고 하버드에서의 배움이 어떻게 실제 서비스 구축에 영향을 미쳤는지를 보여주는 귀중한 기록입니다.