목차9개 항목
출처와 참고
웹액츄얼리가 번역한 Paul Boag의 「실력이 성공을 좌우하는가」(2017.11), Jeffrey Zeldman의 칼럼 「당신이 베푼 사랑」(2015.04), Vitaly Friedman의 「열정있던 웹디자인계는 어디로 사라졌나」(2011.08), 《사람을 배려하는 디자인》 저자 인터뷰(2019.05)를 바탕으로 재구성한 노트다.
오픈 소스 공개 항목은 팔만코딩경(42Seoul 커뮤니티 위키)의 「오픈소스 만들고 먹고살기 v3」 특강 정리를 바탕으로 보강한 노트다.
왜 실력만으로는 안 되나
성공의 모양은 사람마다 다르다. 좋아하는 프로젝트, 돈, 가족과 보내는 시간. 하지만 어떤 성공이든 다른 사람의 손을 거친다. 좋은 직장, 좋은 일, 알맞은 보수는 남이 주는 것이다.
문제는 클라이언트와 채용자 대부분이 실력을 직접 판단하지 못한다는 점이다. 그래서 평판에 기댄다. 공정하지 않지만 현실이다. 명성은 돈과 비슷한 자산이다. 일을 따내게 하고, 일을 더 쉽게 진행하게 한다. 명성이 있으면 클라이언트가 전문가의 말을 더 존중해서 프로젝트도 순조롭다.
명성은 세 가지가 함께 있어야 쌓인다.
| 조건 | 설명 |
|---|---|
| 알려진다 | 결과가 훌륭해도 밖에서 말하지 않으면 아무도 모른다. 노벨상 수상자보다 스티븐 호킹이 더 유명하다 |
| 계속 보인다 | 사람들은 금방 잊는다. 꾸준히 드러내지 않으면 명성은 저문다 |
| 호감을 준다 | 실력이 최고여도 불쾌한 사람이면 반대 방향의 명성이 쌓인다 |
명성을 쌓는 원칙
1. 포기하지 않는다: 몇 년 단위로 본다
블로그를 열었는데 아무도 안 읽으면 의기소침해진다. 발표 지원이 몇 번 떨어지면 무릎을 꿇는다. 하지만 명성은 몇 주가 아니라 몇 년이 걸린다. 구독자 수십 명을 모으는 데 몇 년이 걸리고, 강연·집필 제안은 그 뒤에 온다.
그래서 명성 너머의 동기가 필요하다. 배운 것을 기록하려고 블로그를 쓰고, 사람과 이야기하는 게 좋아서 팟캐스트를 한다. 그리고 정해진 요일에 정해진 것을 낸다. 미루기 시작하면 자기 홍보는 늘 우선순위에서 밀린다.
2. 누구를 겨냥하는지 안다
처음엔 업계 동료에게 "멋진 사람"으로 인정받고 싶어서 글을 쓰기 쉽다. 하지만 명성의 목적은 결국 일을 맡는 것이다. 동경하는 기술 콘퍼런스 무대와 잠재 고객이 가득한 소박한 비즈니스 행사 중 하나를 고르라면 후자다.
- 넓은 분야의 스타가 되기는 어렵다. 작은 어항의 큰 물고기가 되는 편이 쉽다.
- 자원이 한정되어 있다면 어느 분야에서 이름을 얻을지 좁힌다.
3. 의견을 글로 쓰고 말한다
웹 디자이너와 개발자가 할 수 있는 가장 좋은 투자는 글쓰기와 발표다. 이유는 홍보보다 사고에 있다.
- 디자인·코드 작업은 말과 다른 방식으로 생각한다. 내가 왜 그렇게 했는지 언어로 설명해 봐야 비로소 생각을 이해한다.
- 그래서 까다로운 고객을 설득하고, 동료에게 결정을 설명하고, 면접에서 돋보이는 능력이 함께 자란다.
- 채용하는 쪽은 재능만큼 대화·토론·설득 능력을 본다. 블로그나 개인 사이트는 그 능력과 생각을 미리 보여 주는 가장 좋은 증거다.
일러스트레이터처럼 작업물 자체가 말하는 직군은 Dribbble·Behance 같은 포트폴리오면 충분하다. 하지만 웹사이트·앱을 만들거나 UX·전략·편집을 한다면 자기 의견이 있어야 한다.
4. 공개된 작업을 만든다
회사 일은 보안 때문에 보여 줄 수 없는 경우가 많다. 그래도 그 상황이 나를 규정하게 두지 않는다.
- 개발자라면 GitHub에서 보여야 한다. 다른 사람의 프로젝트에 기여하거나 내 프로젝트를 시작한다.
- 회사 일이 따분하면 나를 위해 만든다. 공개할 수 있는 부분은 오픈 소스로 내고, 블로그에 그 코드 이야기를 쓴다.
- 꿈의 일자리를 누가 제안해 주길 기다리지 않는다. 무언가 만들고 선의로 나눈다. 본업이 답답할 때 시작한 사이드 프로젝트가 경력의 중심이 되는 일은 흔하다.
오픈 소스로 공개할 때는 코드만큼 쓰는 사람을 위한 틀이 중요하다. 오픈 소스는 쓰는 문화가 아니라 함께 만들어 가는 문화이기 때문이다.
| 항목 | 내용 |
|---|---|
| 이름 | 기능이 늘어도 어울리게, 너무 좁지 않게 짓는다 |
| README | 프로젝트 개요, 설치·사용법, 기여 방법(CONTRIBUTING), 기여자, 사용하는 곳을 적는다 |
| 라이선스 | 반드시 고른다. 라이선스가 없으면 남이 합법적으로 쓸 수 없다. MIT는 저작권 고지만 남기면 되는 가장 단순한 허용형, Apache 2.0은 허용형에 특허 허락과 변경 고지가 더해진 것, GPL은 파생물도 같은 라이선스로 공개해야 하는 카피레프트다. 모르면 choosealicense.com에서 고른다 |
| 테스트 | 기여자가 내 변경이 무엇을 깨는지 확인할 수 있어야 PR이 들어온다 |
남의 프로젝트에 참여할 때는 관심 있는 기술의 저장소를 골라 쓰면서 불편한 점을 개선하고 커밋한다. 사용만 하지 말고 코드를 읽어 공부하고, 여력이 되면 후원한다. 오픈 소스를 사업으로 잇는 일은 상용 소프트웨어보다 더 많은 전략이 필요하다.
흔한 핑계를 넘는 법
| 핑계 | 답 |
|---|---|
| 다들 나를 거절한다 | 거절은 명성에 직접 영향이 없다. 강연이 떨어지면 웨비나를, 출판이 안 되면 1인 출판을, 기고가 안 되면 블로그를 연다. 처음엔 독자가 적지만 그 기간이 실력을 가는 시간이다 |
| 시간이 없다 | 하루는 모두 24시간이다. 문제는 시간 관리보다 우선순위다 |
| 아는 게 없다 | 나보다 모르는 사람은 늘 있다. 내 프로젝트 경험부터 쓴다. 내 경험은 나보다 잘 말할 사람이 없다 |
| 글쓰기·발표가 싫다 | 다른 기술과 같다. 하다 보면 는다. 오래 망설인 만큼 늦게 는다 |
| 전문가가 되면 쓰겠다 | 시작부터 전문가일 필요는 없다. 쓰는 과정(조사와 생각)에서 전문가가 된다. 충분히 아는 날은 오지 않는다 |
커뮤니티에 기여할 때의 태도
커뮤니티는 커질수록 깊은 토론이 줄고, 경험 많은 사람들이 바빠서 기여를 멈추기 쉽다. 건강한 커뮤니티를 지키는 기여의 태도는 다음과 같다.
| 원칙 | 내용 |
|---|---|
| 작게라도 매일 | 긴 글을 쓸 시간이 없어도 짧은 댓글, 답변, 짧은 글 하나가 토론을 일으킨다. 하루 10~15분이면 된다 |
| 받아들이기 전에 따져 본다 | 바쁘면 남의 아이디어와 디자인을 검증 없이 수긍하거나 무시하게 된다. 논의하고 비판한다 |
| 가치 있는 자료를 만든 사람을 지지한다 | 홍보성 튜토리얼과 아이콘 모음보다 깊은 사례 연구가 묻힌다. 좋은 자료를 알리고 만든 사람을 돕는다 |
| 용어를 정확히 쓴다 | 같은 단어(responsive, design, UX)를 서로 다르게 쓰면 오해가 쌓인다. 다른 분야에서 잘 알려진 개념을 빌려 오면 정확하고 기억에 남는다 |
| 과감하게 묻고 쓴다 | "CAPTCHA를 그만 써야 한다"고 생각하면 근거와 함께 말한다. 나와 같은 고민을 하는 사람이 반드시 있다 |
| 직업 윤리를 지킨다 | 복사·붙여넣기로 글을 퍼 나르지 않는다. 광고와 후원 글은 콘텐츠와 분명히 구분해 표시하고, 사용자를 속이는 패턴은 쓰지 않는다 |
| 트렌드를 의심한다 | 널리 쓰인다고 정답은 아니다. 남의 디자인 결정은 밖에서 볼 뿐 이유는 모른다. 충분히 실험한 뒤 목적에 맞을 때만 쓴다 |
정리
- 성공은 남의 손을 거치고, 남은 실력보다 평판을 본다. 명성은 커리어의 자산이다.
- 명성은 몇 년 걸린다. 명성 너머의 동기를 갖고, 정해진 주기로 꾸준히 낸다.
- 동료보다 일을 줄 사람을 겨냥하고, 넓은 바다보다 작은 어항을 고른다.
- 글쓰기와 발표는 홍보이기 전에 생각을 다듬는 훈련이다. 공개할 수 있는 작업을 만들어 나눈다.
- 커뮤니티 기여는 하루 몇 분의 짧은 답변으로도 된다. 따져 묻고, 정확하게 말하고, 윤리를 지킨다.
관련 노트: 사이드 프로젝트를 시작하고 끝까지 가는 10가지 팁, 회사에서 빠르게 성장하는 법, 온라인 글쓰기, 웹 프로젝트 가격 책정, 오픈소스 기여 시작하기, 개발자 기술 블로그