14 설렘을 주기

여러분의 일은 설렘을 주어야 합니다. 그러므로 여러분은 자신의 일에 설렘을 더하는 데 아주 능숙해져야 합니다.

코딩 커리어에 관한 책에서 다루기에는 정말 이상한 원칙처럼 보일 수도 있습니다. 하지만 이 원칙은 들인 노력에 비해 훨씬 큰 가치와 영향력을 여러분의 일에 더해 줄 수 있기에, 이 책에 넣지 않을 수 없었습니다.

14.1 설렘을 준다는 것은 무엇입니까?

곤도 마리의 2019년 Netflix 시리즈는 “설렘을 주다”로 번역되는 도키메쿠하지 않는 모든 것을 버림으로써 물건을 정리해야 한다는 생각으로 시대정신을 휩쓸었습니다.

우리는 소비자의 관점에서 이런 생각에 익숙하지만, 이 원칙은 반대 방향으로도 똑같이 적용됩니다. 우리는 풍요의 시대에 살고 있으며, 이는 곧 소음의 시대이기도 합니다. 창작자, 제작자, 개발자인 우리 모두는 다른 모든 것처럼 “곤도 마리”식으로 정리되어 버리지 않도록, 우리의 작업이 어떻게 하면 “설렘을 주는” 것이 될 수 있을지 고민해야 합니다.

“설렘을 주다”는 정의하기 어렵습니다. 인간의 감정인 “설렘”만큼만 정확할 수 있기 때문입니다. 하지만 그 모호함을 받아들이면, 우리는 사람이 근본적으로 이성적이지 않다는 것을 이해하게 됩니다. 무엇에 이끌려 주의를 기울이는지에서도, 무엇을 쓰기로 하는지에서도, 무엇에 관해 이야기하기로 하는지에서도 그렇습니다. 우리는 무언가를 좋아하는 이유에 대해 그럴듯한 합리화를 내놓을 수 있지만, 진짜 이유는 무의식 깊은 곳에 닿아 있는 경우가 많습니다.

“저는 사람들이 당신이 한 말을 잊고, 당신이 한 행동도 잊지만, 당신이 그들에게 어떤 감정을 느끼게 했는지는 결코 잊지 않는다는 것을 배웠습니다.” - 마야 안젤루

14.2 효과가 있는 이유

이 토마토 무리를 보십시오:

여러분의 눈은 곧바로 빨간 토마토로 향했습니다. 우리는 무언가가 눈에 띄면 알아차립니다. 이를 폰 레스토프 고립 효과라고 합니다. 비슷한 대상이 여러 개 있을 때 나머지와 다른 하나가 가장 잘 기억된다는 것입니다. 그리고 우리가 기억하는 것이 곧 우리가 가치 있게 여기는 것입니다.

인터넷 곳곳에서 폰 레스토프 효과가 작용하는 모습을 이미 보셨을 것입니다.

어쩔 수 없이, 시선은 그들이 의도한 곳으로 곧장 향하게 됩니다.

마찬가지로, 여러분은 동료부터 잠재 고객에 이르기까지 모든 사람의 기억 속에 여러분의 작업이 두드러지게 남기를 바라야 합니다. 그들이 붙잡을 만한 인상적인 무언가를 여러분이 건넸기 때문에, 그들은 이제 여러분의 가장 든든한 지지자가 될 수 있습니다.

하지만 설렘은 단지 눈에 띄는 것만을 위한 것이 아닙니다. 여러분의 작업이 사람들에게 좋은 느낌을 불러일으키기만 한다면, 사람들은 여러분을 긍정적인 감정과 연결 지을 것입니다.

깨진 유리창이 더 많은 범죄를 부추길 수 있는 것과 마찬가지로, 작업물에 탁월함의 본보기를 두면 그 반대 효과가 일어나는데, 이를 미적 도미노 효과라고 부릅니다. 작업물에 기쁨의 불꽃을 담으면 여러분이 정성을 쏟는다는 것이 사람들에게 전해지고, 다른 사람들도 그렇게 하도록 영감을 줍니다.

14.3 예시

가장 가까운 곳인 코드에서 출발해, 여러분이 마주치게 될 기회들을 동심원처럼 점점 넓혀 가겠습니다. 이 목록이 전부는 아닙니다. 그저 일상에서 하는 일들로 어떻게 설렘을 주는 순간을 만들 수 있을지 영감을 드리려는 것입니다.

14.3.1 코드에서 설렘 일으키기

지옥이란 내가 작성한 코드를 이해하지 못하는 것입니다. - Kyle Simpson

코드는 작성되는 것보다 읽히는 경우가 더 많습니다. 코드를 읽는 것이 즐겁지 않다면, 그 코드는 사용하기 어렵고 리팩터링하기는 끔찍할 것입니다. 성급한 추상화를 피하십시오. 가능한 한 말입니다. 우리에게는 코드 복잡성을 피하라는 상기가 끊임없이 필요합니다:

우발적 복잡성(Accidental Complexity)을 경고한 Fred Brooks부터 얽힌 것을 풀어내라(decomplect)고 권고한 Rich Hickey까지
밥 마틴이 클린 코드를 작성하라고 가르친 것부터 켄트 벡이 그 코드에 대한 합리적인 테스트를 작성하라고 가르친 것까지
지역적 추론을 쉽게 하라고 권하는 Sophie Alpert(전 React 매니저)부터 변경에 최적화된 코드를 설계하는 법을 보여 주는 Dan Abramov까지.

이름 짓기가 어렵다는 것은 누구나 압니다. 이에 대해서는 여러 의견이 있습니다. 어떤 것이 너무 복잡해서 좋은 이름을 붙이기 어렵다면, 아마도 그것에 너무 많은 책임을 부여하고 있는 것입니다. 코드 가독성을 코드 스멜로 여기고 주의를 기울이십시오.

주석은 왜를 설명하고, 코드는 어떻게를 설명합니다. - Jem Young

코드 주석은 개발자 소통의 치트 코드입니다. 주석은 성능에 아무런 영향을 주지 않으며(대개는 그렇습니다!), 다른 사람들이 시간을 낭비하는 일을 막는 데 도움이 됩니다. 코드가 무엇을 하는지 설명하는 대신(이는 코드 자체만 읽어도 분명한 경우가 많고, 코드가 바뀌면 쉽게 낡아 버립니다), 어떤 선택을 왜 했는지, 또는 “뻔한” 접근 방식을 왜 택하지 않았는지 적어 두거나, 코드가 어떻게 동작하는지 보여 주는 ASCII 아트 다이어그램을 그려 둘 수 있습니다. 제가 여러분의 코드를 읽으면서 물어보려던 것을 여러분이 미리 짐작해 두었다면, 믿으십시오, 그것이야말로 설렘을 줍니다.

Sarah Drasner에 따르면(여기 발표에서 자세히 설명합니다) 주석은 다음과 같은 다른 좋은 목적에도 쓰일 수 있습니다.

일반 사람이 읽어서는 이해하기 어려운 부분을 명확히 설명하기
책의 장(chapter)처럼 코드 덩어리 나누기
코드를 작성하는 동안 로직을 명확하게 정리해 두기 위한 의사코드
TODO나 코드의 어느 부분을 리팩터링해도 되는지 표시하기
동료 팀원들을 위한 학습 도구로 활용하기
StackOverflow에서 가져온 코드라면 출처 밝히기

저는 무엇을 만들었는지 그 의도와 맥락을 전달하는 일에 있어서는 세상에서 가장 잘 작성되고 가장 우아한 코드라 할지라도 잘 쓰인 자연어 문서에 조금도 견줄 수 없다고 생각합니다. 이것이 어떻게 동작하는지, 우리가 왜 이것을 만들었는지 말입니다. 코드는 자신이 무엇을 하는지, 그리고 기술적인 수준에서 그것을 어떻게 하는지는 설명할 수 있지만, 비즈니스상의 이유와 영향을 설명하지 못하며, 심지어 그 코드에 의존하고 있을지도 모르는 다른 시스템들에 대해서도 설명하지 못합니다… 많은 사람들이 자리에 앉아 그런 문서를 직접 써야 한다는 것이 문서를 쓰는 사람에게 주는 가치를 과소평가합니다… 여러분은 방금 만든 것에 대해 새로운 사실을 발견하고 “아, 잠깐, 내가 뭔가 놓쳤구나!” 하고 깨닫게 될 수도 있습니다. - Jared Short

훌륭한 오류 설계는 설렘을 줍니다. 개발자는 같은 앱 안에서조차 다른 개발자가 사용할 서비스와 모듈을 작성하는 경우가 많습니다. 이러한 상호작용의 대부분은 설계 문서나 OpenAPI 명세 또는 그와 비슷한 것으로 명시적으로 규정된 일종의 계약에 따라 이루어집니다. 하지만 대개 충분히 규정되지 않는 것은 일이 잘못될 때 무엇을 해야 하는가입니다:

일반적인 오류 메시지는 어딘가에서 오류가 발생했다는 사실만 알려 줍니다.
좋은 오류 메시지는 오류를 일으킨 국소적인 상태를 알려 줍니다.
훌륭한 오류 메시지는 오류의 가능한 원인과 해결 방법을 알려 줍니다.
최악의 오류 설계는 아예 나타나지조차 않는 것, 즉 조용한 오류입니다.

오류 메시지의 양도 중요합니다. 오류를 절대 일상화하지 마십시오. 양치기 소년이 되지 마십시오. 사람들에게 여러분의 오류는 무시해도 된다고 길들이면, 그들은 중요한 오류까지 무시하게 되고, 여러분도 언제 어떻게 오류를 낼지에 대해 게을러지게 됩니다. 최소한 오류에 계층을 둘 수는 있습니다. 대개는 info, warning, error 정도의 단순한 계층이면 충분하지만, 좀 더 체계적으로 설계된 것을 원한다면 Syslog 심각도 수준을 살펴볼 수 있습니다. 오류를 너무 성급하게 내면 멈췄다 다시 시작하기를 반복하는 디버깅이 많아질 수도 있습니다. 대신 오류를 최대한 게으르게 만드십시오. 프로그램이 반드시 멈춰야 하는 것이 아니라면 멈추지 마십시오. 사용자가 이러한 오류를 버퍼링하고 기록하도록 설정할 수 있는 notify() 함수를 사용하십시오.

이런 내용은 코드 표준 문서에서 다룰 것이라고 생각할 수도 있습니다. 하지만 코드 표준은 보통 최소한의 필수 기준만 다룹니다(지나치게 부담스러워지지 않도록 하려는 것이니 그럴 만한 이유가 있습니다). 설렘을 주기 위해, 우리는 기대 이상으로 해낼 기회를 찾습니다. 다른 사람들이 함께 일하고 싶어 하는 개발자가 되는 한 가지 방법은 다른 사람들이 즐겁게 읽고 사용할 수 있는 코드를 작성하는 것입니다.

14.3.2 PR과 이슈에서 설렘 주기

잘 만들어진 PR과 이슈는 설렘을 줍니다. 문제를 해결하다가 답답한 마음에 글을 쓰는 순간에도, 침착함을 유지하고 맥락과 간결한 정보를 제공하며 상대가 여러분을 도울 수 있도록 돕는 능력은 큰 도움이 됩니다.

StackOverflow에는 좋은 질문을 하는 방법에 대한 훌륭한 안내서가 있지만, 간단한 방법으로 그 이상을 해낼 수도 있습니다:

GitHub에서는 이슈에 이미지와 GIF를 아주 쉽게 첨부할 수 있으므로, 적절한 곳이라면 어디서든 이를 활용해 정보를 전달해야 합니다. 이미지와 GIF는 매우 많은 정보를 한 번에 전달할 수 있기 때문입니다.
Annotate나 Zappy 같은 앱을 사용해 스크린숏을 찍고 주석을 다십시오.
GIF의 경우, 오픈 소스 앱인 LICEcap을 사용하면 프레임 레이트와 녹화 화면 영역까지 모든 것을 제어할 수 있습니다. 이는 움직이는 버그를 분리해 내는 데 도움이 됩니다.
때로는 스크린숏이나 GIF만으로는 부족하고 더 긴 설명이 필요합니다. 내레이션을 곁들여 짧은 영상 데모나 버그 리포트를 녹화하고, 이를 YouTube에 일부 공개 동영상으로 올린 다음 리포트에 링크를 포함하십시오. 여러분이 5분만 투자하면 프로젝트 메인테이너나 잠재적 사용자와 여러 번 주고받아야 할 대화를 크게 줄일 수 있습니다.

GitHub에서 이루어지는 협업의 상당 부분은 비동기적이고 얼굴을 마주하지 않습니다. 사람들이 재현 사례를 만들겠다, 베타를 써 보겠다, 수정 작업을 하겠다는 식으로 무언가를 하겠다고 말해 놓고는 다시 돌아오지 않는 일이 흔합니다. 그저 하겠다고 말한 일을 실제로 하는 것만으로도 기쁨을 줍니다.

메인테이너도 기여자가 환영받는다고 느끼도록 많은 일을 할 수 있습니다:

All Contributors 봇은 디자인, 재정 지원, 문서 번역처럼 코드가 아닌 기여까지 포함하여 모든 사람의 기여를 인정하는 데 도움이 됩니다.
Netlify의 Feedback Ladder나 Conventional: Comments 같은 피드백 등급 체계를 사용하여 칭찬을 전하고 문제의 심각도를 표시하십시오
병합된 PR이 릴리스되면 semantic release 봇이 기여자에게 이제 자신의 PR을 표준 배포판의 일부로 사용할 수 있다고 알려 줄 수 있습니다!

14.3.3 문서로 설렘을 주기

개발자가 설렘을 주는 가장 효과적인 방법은 좋은 문서를 작성하는 것입니다. 문서는 모든 새 사용자와 팀원이 가장 먼저 읽는 것이며, 여러분이 프로젝트를 아낀다는 것을 보여 줍니다.

작은 프로젝트마다 온갖 기능을 갖춘 문서 사이트를 만들 필요는 없습니다. 대부분의 경우 정말 잘 쓴 README 하나면 충분하고도 남습니다. 하지만 “README에 공을 들이기” 위해 할 수 있는 일은 많습니다.

바로 본론으로 들어가십시오. 설치 방법, 예제, API 문서를 앞쪽에 배치하고 목차 생성기를 사용해 쉽게 찾아볼 수 있도록 하십시오. 이 내용들을 항상 최신 상태로 유지하고, 개발자들이 설명 대부분을 대충 훑어보면서 복사해 붙여 넣는다는 점을 염두에 두고 예제 코드를 작성하십시오. 개발자 키처럼 복사해 붙여 넣기가 불가능한 경우에도, 키가 어떤 형태여야 하는지 보여 주면 사람들이 올바른 키를 가지고 있는지 눈으로 확인할 수 있습니다. 예: API_TOKEN= # e.g. MY_API_TOKEN_1234

팁: Node.js 생태계에서는 dotenv-safe를 사용하면 환경 변수가 올바르게 지정되었는지 검사하도록 강제하는 데 도움이 됩니다.

오픈 소스에서 라이선스는 중요합니다. 일부 법률 해석에 따르면 개발자는 라이선스가 없는 코드를 사용하거나 기여하는 것은 물론이고 보는 것조차 허용되지 않습니다. 저작권과 카피레프트의 차이를 배우고, 여러분의 가치관을 반영하는 라이선스를 고르십시오. 더 중요한 것은, 회사의 지적 재산권을 침해할 수 있는 소프트웨어를 사용하지 마십시오. tldrlegal을 사용해 라이선스를 이해하거나, 오픈 소스 이니셔티브(Open Source Initiative)에서 승인한 라이선스에 의존할 수 있습니다. 확신이 서지 않는다면 MIT를 사용하십시오. 라이선스를 추가하는 데는 CLI(npx license mit)를 통하든 GitHub의 UI를 통하든 몇 초면 충분합니다. 습관으로 만드십시오!

CI 배지는 품질과 관련이 있습니다. 문서 배지를 보여주기식 “장식품(pieces of flair)”으로 여기고 싶어지기 쉽지만, 이 현상에 대한 학술 연구에 따르면 빌드 상태, 이슈 해결 시간, 코드 커버리지처럼 실제 분석에 기반한 배지는 프로젝트 품질을 예측하는 지표가 됩니다. Shields.io를 사용하면 좋은 배지들을 손쉽게 설정할 수 있습니다. 상관관계가 인과관계는 아닙니다. 이는 배지가 프로젝트 품질을 높인다는 뜻이라기보다는, 배지를 다는 메인테이너가 어떤 유형의 사람인지와 더 관련이 있을 것입니다. 하지만 여러분도 관심을 기울이고 있음을 보여주는 그런 메인테이너가 될 수 있습니다!

참고로, 배지를 너무 많이 달지는 마십시오! 4~6개 정도가 가장 적당해 보입니다. 그보다 많아지면 “크리스마스 트리” 효과가 나타나기 시작해 “너무 애쓰는” 것처럼 보이게 됩니다.

저장소 메타데이터에도 적절한 주의를 기울여야 합니다. GitHub에서는 프로젝트 상단에 프로젝트 설명을 넣을 수 있을 뿐만 아니라 링크도 넣을 수 있습니다. 그곳에 가장 좋은 한 줄 소개를 꼭 넣고, 데모의 라이브 프로젝트로 연결되는 링크도 반드시 거십시오! 그곳은 말 그대로 개발자들이 가장 먼저 보는 곳입니다.

README는 보통 Markdown으로 작성하는데, Markdown은 콘텐츠에 다소 엄격한 질서를 부과합니다. 하지만 <div align="center">로 HTML 정렬을 조금 활용하거나, 로고나 배너를 추가하면(기여를 요청하거나 Hipster Logo Generator, Hatchful, Excalidraw 같은 생성기를 사용하십시오) 그 단조로움을 깨뜨릴 수 있는 경우가 많습니다. 영감을 얻으려면 Awesome README 목록을 살펴볼 수 있습니다. GitHub 프로필이 있다면 프로필 README도 멋지게 꾸미는 것을 잊지 마십시오!

문서의 구조와 상대적인 비중에 주의를 기울이십시오. 큰 텍스트 덩어리를 읽고 싶어 하는 사람은 아무도 없습니다. 가능하다면 글머리 기호나 표로 나누십시오. GitHub-flavored Markdown을 사용하면 Markdown 사이사이에 HTML <details>와 <summary> 태그를 섞어 넣어 엣지 케이스에 대한 긴 설명을 숨길 수도 있으며, 이렇게 하면 대충 훑어보는 사람과 더 깊이 파고들고 싶은 개발자 모두에게 유용한 문서를 만들 수 있습니다.

문서의 서식 정리를 자동화하십시오. prettier를 git hook으로 실행할 수 있고(빠르게 쓰려면 husky와 pretty-quick을 함께 사용하십시오), doctoc을 사용하면 목차를 항상 최신 상태로 유지할 수 있습니다(GitHub action으로도 제공됩니다).

때로는 그림 한 장이 천 마디 말보다 많은 것을 전합니다. 가능하다면 스크린숏이나 데모 gif를 넣으십시오. “작동 방식” 섹션에서는 ASCII Flow나 Monodraw 같은 도구로 간단한 ASCII 다이어그램을 만들어 시스템과 개념을 설명할 수도 있습니다. Excalidraw, Draw.io(VS Code에서도 쓸 수 있습니다!), Miro 같은 무료 드로잉 도구를 사용해 색을 입혀 그림으로 나타낼 수도 있습니다.

“저는 README.md의 svg 로고를 전적으로 신뢰합니다. 코드가 좋든 나쁘든 거기에 로고만 붙어 있으면 저는 아마 npm install 할 겁니다.” - Matt Hova (반쯤 농담으로)

훌륭한 문서를 위해 추가할 수 있는 것에는 끝이 없습니다. 그러니 프로젝트의 성숙도에 맞게 문서를 작성하는 것이 가장 좋습니다. 언제나 환영받는 좋은 기능이 두 가지 있습니다. 바로 검색 기능, 그리고 “트레이드오프” 또는 “이것을 사용하지 말아야 할 때” 섹션입니다.

일화 하나를 소개하겠습니다: 훌륭한 문서는 오픈 소스 마케팅과 채택에만 중요한 것이 아닙니다. 제 개발자 생활에서 가장 좋았던 기억 중 하나는, 한 신입 직원이 사내 저장소를 처음 접했다가 모든 것이 어떻게 동작하는지 보여 주는 다이어그램과 프로젝트 파일 구조에 대한 짧은 설명까지 곁들여 아주 상세하고 친절하게 설명된 README를 발견했다는 이야기를 들은 일입니다. 그 문서를 작성한 엔지니어는 1년 넘게 그 저장소에 손도 대지 않은 상태였지만, 신입 직원은 곧바로 작업을 이어받을 수 있었습니다. 그렇게 훌륭한 문서를 발견한 신입 직원은 당연히 뛸 듯이 기뻐했고, 회사 사내 채팅 곳곳에서 그 문서를 칭찬했습니다. 그렇다면 원래 그 문서를 쓴 엔지니어는 어떻게 되었을까요? 그녀는 얼마 지나지 않아 프린시펄 백엔드 엔지니어로 승진했습니다.

14.3.4 데모와 제품에서 설렘 불러일으키기

데모는 프로덕션용도 아니고 핵심 코드도 아닌 앱이라서 비교적 자유롭기 때문에, 설렘을 주기에 아주 좋은 기회입니다. 브랜드에 어울리는 유머는 마케팅에 도움이 될 뿐만 아니라 프로젝트의 의도를 전달하는 데에도 큰 도움이 됩니다. Muzzle의 랜딩 페이지와 소셜 미디어 반응을 한번 살펴보십시오.

API와 상호작용하는 방법을 시연할 때에도 “건전한” 농담을 위한 이 API나 개발자 농담을 위한 이 API, 데브옵스 농담을 위한 이 API 같은 농담 API를 사용할 수 있습니다. 좀 더 진지해야 한다면 Public API Lists에서 데모에 활용할 수 있는 흥미로운 API를 찾아보십시오.

최고의 데모는 청중에 맞게 현지화합니다. 사람들은 자신이 보고 있는 발표가 자신들 말고는 어떤 청중에게도 도저히 통할 수 없는 것일 때 이를 알아챕니다. Divya Tagtachian은 보스턴에서 발표할 때 그 지역의 해산물 맛집에 대해 이야기합니다. 같은 데모가 시카고에서는 시카고의 딥 디시 피자로 바뀝니다. 암스테르담에서 발표할 때는 재미있는 네덜란드어 말장난을 하고 GDPR을 다룹니다. 나이지리아에서는 밀크티를 사용하는 데모가 졸로프 라이스로 바뀝니다. 마케팅 페이지에서는 대상 청중의 다채로운 다양성을 반영하는 아바타와 일러스트를 사용할 수 있습니다. 청중은 여러분이 자신들을 위해 한 걸음 더 나아갈 때 이를 알아채며, 이것이 기쁨을 불러일으킵니다.

접근성에 공을 들이십시오. 프로덕션이 아닌 데모에서도 접근성을 챙기는 것은 좋은 습관일 뿐만 아니라, 접근성이 떨어지는 수많은 앱에 익숙해진 키보드 사용자와 스크린 리더 사용자에게 진정한 기쁨을 줍니다. 접근성은 장애가 있는 사람들만을 위한 것이 아닙니다. 접근성은 생산성 도구와 개발자 도구(Slides.com처럼 시각 요소가 많은 앱에서조차) 그리고 야외용이나 산업용 앱에서 핵심적인 제품 차별화 요소가 되어 가고 있습니다. Marcy Sutton, Lindsey Kopacz, Jen Luker가 제공하는 풍부한 발표, 자료, 워크숍을 살펴보십시오.

스토리텔링은 데모를 매력적으로 만들어 줄 수 있습니다. 등장인물이 지어낸 인물이든 대중문화를 차용한 인물이든, 방문자는 그 인물에게 몰입할 수 있습니다. 제가 본 가장 인상적인 DevOps 데모 중 하나는 Pavel이라는 동료의 이야기를 들려주는 방식으로 진행되었습니다. 몇 년이 지난 지금도 저는 Pavel의 이름과 그가 겪은 일을 기억합니다.

빈 상태(empty state)를 잊지 마십시오! 빈 상태는 데모에서 흔히 볼 수 있으며, 특히 사용자가 체험 계정을 만들었지만 아직 데이터가 하나도 없어서 대시보드에 아무것도 보이지 않을 때 그렇습니다. 대부분의 프로그래머는 빈 상태를 그냥 비워 둡니다. 하지만 그 빈 공간은 사용자에게 다음 행동을 하도록 유도할 수 있는 공짜 자리입니다! Superhuman 같은 앱에서는 빈 상태가 목표일 뿐만 아니라 경쟁 우위이기도 합니다. 실제 앱에서 더 많은 영감을 얻으려면 emptystat.es를 확인해 보십시오.

데모에 대한 우리의 논의가 그 두려운 ‘앱 전체 디자인’ 영역으로 빠져들기 시작하고 있습니다. 아름답게 디자인된 데모는 확실히 설렘을 주는 법입니다. 그렇다면 디자이너를 고용해야 할까요? 아니면 직접 디자이너가 되어야 할까요?

참고: 그럴지도 모릅니다… 아닐지도 모릅니다! 디자인으로 설렘을 불러일으키는 간단한 팁은 바쁜 개발자를 위한 디자인(Design for Developers in a Hurry)(장 33)을 확인해 보십시오!

14.4 한 걸음 더

여러분의 일에서 설렘을 불러일으킬 수 있는 가능성은 끝이 없습니다. 다음은 위의 범주에 딱 들어맞지 않았던 몇 가지 아이디어입니다.

빠른 피드백: 지금은 사람들을 “잠수 타는” 일이 흔하고, “이메일에 약하다”는 말을 웃어넘기는 시대입니다. 응답을 빠르게 하려고 노력하면 사람들이 알아차릴 것입니다. 여러분이 자신의 작업에 대한 피드백을 얼마나 갈망하는지 생각해 보십시오. 다른 사람들도 그것을 원합니다. 여러분은 피드백의 샘이 될 수 있으며, 사람들은 더 많은 피드백을 얻으려고 계속 여러분을 다시 찾아올 것입니다.

이메일을 잘 다루게 되는 것은 단순하지만 쉽지는 않습니다. 부족한 필자도 아직 노력하는 중입니다. 하지만 핵심 아이디어는 데이비드 앨런의 Getting Things Done 방법론과 같습니다. 2분 안에 할 수 있는 일이라면 바로 하십시오. 대부분의 이메일은 그렇게 처리할 수 있습니다. 채팅, GitHub 알림, 문자 메시지 등도 마찬가지입니다. 늘 확인하고 있을 필요는 없지만, 하루에 한두 번은 꼭 확인하고 답하면 여러분을 아끼고 함께 일하는 사람들에게 계속 빠르게 응답할 수 있습니다. 이것이 설렘을 줍니다.
다른 사람을 배려하십시오: 모든 것이 항상 당신에 관한 것은 아닙니다. 다른 사람들의 작업을 지켜보고, 그들이 작업을 진행하는 동안 격려의 댓글을 남기십시오. 저는 다른 누구도 볼 수 없는 비공개 GitHub 저장소에도 별을 달아 두는데, 제가 지켜보고 있으며 동료들을 응원하고 있다는 작은 신호를 보내기 위해서입니다.
회의록을 작성하십시오: 현대의 직장에서는 회의가 너무 가볍게 이루어집니다. 특히 정보가 수많은 비동기 채팅 기록에 흩어져 있다면, 나중에 찾아보거나 참고하기 어려울 수 있습니다. 어떤 말이 오갔는지, 어떤 입장들이 검토되었는지, 어떤 결정이 내려졌는지를 수고스럽더라도 정리해 두면 여러분의 이미지를 높이는 데 도움이 될 뿐만 아니라 팀 커뮤니케이션도 실제로 더 좋아집니다! 여러분이 남성이고 회의록 작성이 여성 동료에게 불균형하게 몰리는 것을 보게 된다면 보너스 점수를 드립니다(실제로 그렇게 몰리며, 여성 동료들은 이를 지적해 주는 지지자를 고마워합니다).
깊이 있는 조사: 팟캐스트 게스트에 대해 깊이 있게 배경 조사를 하고, 그 사실을 넌지시 알려 주십시오! (예시 - Rob Hope는 Adam Wathan을 인터뷰할 때 Adam이 헤비메탈을 좋아한다는 것을 알아내고 그에 대해 질문했습니다)
비밀 칭찬: 누군가가 여러분에게 호의를 베풀었거나 특히 훌륭한 성과를 냈다면, 그 사람의 관리자에게 칭찬이나 감사의 말을 전하십시오. 그 사람의 연간 평가에 도움이 될 것입니다!
손으로 쓴 감사 카드. 더 말할 필요가 없습니다. 감사 인사가 몇 년이나 늦었더라도, 진심 어린 감사 편지는 상대방의 하루를 행복하게 만들 수 있습니다.
이스터 에그: CLI 출력에 사인 버니와 Cowsay 넣기

Sign Bunny and cowsay
유쾌할 만큼 브랜드에 충실하기: 예시 - Design Pickle이 피클 옷을 입고 피클을 나눠 준 일은 사람들의 기억에 남았고 입소문을 탔습니다
개인적인 기념품: 셜리 우(Shirley Wu)는 데이터 시각화를 하는 사람이어서, 직접 만난 사람만 받을 수 있도록 자신의 작업을 보여 주는 명함을 인쇄했습니다.
독특한 비유: 친구의 책 “Exactly What To Say”를 리뷰하면서, Clay Hebert는 이 책이 “알짜배기만 담겨 있다”고 말할 수도 있었고, 이는 책의 주제와도 잘 어울리는 표현이었을 것입니다. 하지만 그는 그 대신 이 책을 “책계의 발사믹 식초 졸임”이라고 불렀습니다. 그 독특한 이미지는 독자들의 기억에 남으며, Clay가 그날 친구와의 우정을 더욱 돈독히 했다는 것은 분명합니다.

기쁨을 불러일으키는 능력은 오직 여러분의 창의력에 의해서만 제한됩니다. 그리고 여러분이 그렇게 할 때 사람들은 언제나 알아차립니다. 사람들을 기쁘게 하기 위해 한 걸음 더 나아가면 상호성의 원칙이 작동하는데, 이는 가장 강력한 영향력의 형태 중 하나입니다.

“남들보다 한 걸음 더 나아가는 길에는 교통 체증이 없습니다.” - 명예의 전당에 오른 미식축구 선수 로저 스타우바흐

다른 사람에게 설렘을 주는 것이 얼마나 큰 힘을 지니는지 몰랐다면, 이제는 아셨을 것입니다.