책에 나온 링크들을 한번에 찾아가실 수 있도록 모았습니다.
이외에도, 계속해서 데브렐에 대한 국내외 자료들을 확인하실 수 있도록 주기적으로 업데이트 할 예정입니다.
저자인 메리 셍발이 정리한 링크모음집은 아래 URL을 통해 확인하실 수 있습니다.
https://www.marythengvall.com/devrelbook
원서의 몇몇 링크가 만료되거나 접근이 불가능하게 된 경우가 있어,
링크를 삭제하거나 이해를 도울 수 있는 다른 적절한 링크로 대체했습니다.
또, 데브렐 관련 콘텐츠를 모아둔 사이트 <데브렐 리소스> 사이트도 공유드립니다.
https://devrelresourc.es
이 사이트 역시 저자인 메리 셍발이 운영하고 있습니다.
원서에는 소개되지 않았지만, 데브렐에 대한 주제별 콘텐츠를 찾아보기 정말 좋습니다.
이 밖에도 원서에는 없지만 디벨로퍼 릴레이션을 이해하는데 더 도움되실 수있는
추가 콘텐츠나 링크를 계속해서 업데이트 할 예정입니다.
감사합니다.
p.12
성공적인 데브렐 팀을 갖기 위해 필요한 요소에 대해서는 아닐 대시(Amil Dash)가 쓴 '데브렐 권리장전(A Developer Relations Bill of Rights)'에서 더 자세히 살펴볼 수 있습니다.
https://medium.com/glitch/a-developer-relations-bill-of-rights-21381920e273
p.14
https://twitter.com/matthewrevell/status/1003477945707462656
p.31
- https://businessdictionary.info/definition/community
- https://www.merriam-webster.com/dictionary/community
- http://www.dictionary.com/browse/community
p.32
- https://www.mckinsey.com/business-functions/people-and-organizational-performance/our-insights/why-diversity-matters
- https://hbr.org/2018/03/5-things-we-learned-about-creating-a-successful-workplace-diversity-program
p.40
만약 여러분이 데브렐 담당자라면 여기서 함께해요!
http://devrelcollective.fun
p.45
사이먼 사이넥의 TED강연 'Start with Why'에서 이 개념을 더 깊이 있게 설명합니다.
How great leaders inspire action
https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action
p.51
https://www.projectsmart.co.uk/raci-matrix.php 에서 더 자세히 알아볼 수 있습니다.
p.61
댄 히스, 칩 히스 저. ‘Chapter 4: Point to the Destination. p 93.’ 『Switch: How to Change Things When Change Is Hard』(Random House US, 2011.)
p.63
- 저와 제이슨 핸드, PJ 하제티가 함께 커뮤니티 전문가로서 여러 커뮤니티를 살펴보고 커뮤니티가 건강하게 잘 운영되고 있는지 관련 정보를 알려주는 팟캐스트의 이름이 ‘커뮤니티 펄스(Community Pulse)’인 이유이기도 합니다. communitypulse.io를 참고하세요.
- 개발자를 위한, 개발자에 의한 이메일 전송 API. 저는 2년 동안 해당 API의 커뮤니티 전략을 수립했습니다.
- 엔지니어링 매니저. 스카치를 조달해주는 스코틀랜드인(일명 스카치 엔젤). 트위터는 @ewanovitch
p.64
지리적인 요소도 기술 채택의 관점에서 볼 때 중요한 부분입니다. 일반적으로 기술 채택은 미국 서부가 동부보다 빠르고, 미국 동부는 유럽보다 빠르고, 유럽은 미국 중서부보다 앞서는 경향이 있습니다.
p.65
-
키뱅크 캐피탈 마켓(KeyBanc Capital Markets)의 부사장 겸 수석 모자이크 전문가. IBM의 전 테크니컬 에미넌스(eminence) 프로그램 디렉터. #CloudMinds를 만든 사람이자 멘토, 혁신가, 커뮤니티 엔터테이닝 디렉터이며 모든 면에서 멋진 사람. 트위터 @amyhermes. 팟캐스트인 ‘Geek Whisperers’에서 만나 알게 되었습니다. 관련 에피소드는 링크를 참고하세요. http://geek-whisperers.com/2015/08/bringing-people-together-isnot-marketing-with-amy-hermes-ep-93
-
다시 말씀드리지만, 이 책 곳곳에서 소개한 여러 도구를 다룰 때와 마찬가지로 두 가지 주의 사항이 있습니다. ① 제가 소개한 도구들보다 여러분에게 더 적합한 것이 있을 수 있습니다. ② 제가 언급한 도구들이 여러분에게는 적합하지 않을 수 있습니다. 제가 강조한 원칙들을 바탕으로 여러분의 목표, 커뮤니티, 회사에 적합한 툴이 무엇인지 파악해보세요.
p.67
저는 트위터를 예로 들어보려고 합니다. 그 이유는 현재 대부분의 개발자들이 사용하는 소셜 미디어 플랫폼이기 때문이기도 하고,
저의 가장 큰 전문 분야가 소셜 미디어 네트워크이기 때문입니다.
p.68
- 발표 영상: https://youtu.be/-WSvqM23Z64
- 인터뷰글: https://www.contagious.com/news-and-views/slacks-editorial-soul-anna-pickard-on-writing-the-brand-experience
p. 69
이에 대해서는 댄 토마스의 팟캐스트에서 자세히 다루고 있습니다.
https://tunein.com/podcasts/Business/The-Dan-Thomas-Podcast-p1088140
p.77
벤 하펜, 제스 리, 피터 프랭크가 만든 Dev.to는 제가 개발자 커뮤니티 관련 일을 하면서 본 커뮤니티 중
가장 사람들을 반겨주고 포용력을 가진 커뮤니티 중 하나였습니다. 트위터는 @thepracticaldev
p.79
https://github.com/RobSpectre/Talks/tree/master/Measuring%20Developer%20Evangelism
p.80
- https://twitter.com/SparkPostOps/status/667420447345102848
- https://www.sparkpost.com/blog/building-internal-community
- 스파크포스트에서 2년 동안 함께 일할 수 있어서 영광이었던 멋진 친구. 개발자들을 위해 일을 더 쉽게 만드는 데 열정적이죠. 트위터는 @ahoward
- 제 컨설팅 회사가 '페르세아 컨설팅(Persea Consulting)'이라고 불리는 이유이기도 합니다. 아보카도는 과학적으로 페르세아속에 속합니다. 저에게 있어 페르세아라는 이름은 인간(Persons)에 대한 고찰로도 연결되며, 이는 나아가 커뮤니티 및 데브렐을 의미하기도 합니다. https://www.marythengvall.com/blog/2018/1/31/developer-avocados-the-good-kind-of-fat
p.81
https://twitter.com/sherlyholmes/status/938934404251971584
p.82
- 월별 또는 분기별로 팀과 함께 해보면 좋습니다. 어떤 문제나 이슈가 처리할 수 없을 정도로 커지기 전에 미리 막을 수 있도록 도움을 줄 겁니다.
- 제 좋은 친구로, 오픈소스 커뮤니티에 대한 엄청난 인사이트와 열정을 지닌 에너지 넘치는 커뮤니티 빌더입니다. 트위터는 @mbbroberg
p.83
https://www.marythengvall.com/blog/almostanauthor
p.86
Community Metrics are a Trojan Horse for Real Relationships
http://cls.mediaspace.kaltura.com/media/CLS+2017+-+Matthew+(Brender)+Broberg+–+Community+Metrics+are+a+Trojan+Horse+for+Real+Relationships/0_ro0yrlfk
p.90
만약 오픈소스를 많이 사용하고 있다면 비테르지아(Bitergia)를 추천합니다.
비테르지아가 제공하는 대시보드를 통해 누가 가장 큰 깃허브 컨트리뷰터인지 알 수 있고
메일링 리스트, 포럼, 버그 등에 대한 통계도 살펴볼 수 있습니다.
넷플릭스의 OSSTracker(https://github.com/Netflix/osstracker)와 MeasureOSS(https://github.com/MeasureOSS/Measure)같은 도구도 있습니다.
가시성 측면에서 트위터 분석과 다른 API 지표들을 킨(Keen)이나 데이터독(Datadog)으로 가져오면 가시성 측면에서 매우 유용합니다.
지난 달의 트렌드를 파악하지 못한 상태에서 다음에 무엇을 해야 할지에 대해 정보에 입각한 의사결정을 내리는 것은 불가능할 겁니다.
p.91
p.95
- https://www.ftc.gov/tips-advice/business-center/guidance/can-spam-act-compliance-guidebusiness
- https://www.betterevaluation.org/en/blog/anecdote_as_epithet
p.101
- https://mcgaw.io/blog/aarrr-pirate-metrics-for-startups/#gs.0hthso
- https://devrel.net/strategy-and-metrics/introducing-aaarrrp-devrel-strategy
p.102
http://bit.ly/aaarrrp-template
p.109
https://twitter.com/mary_grace/status/843975759890800640
p.112
맥킨지 포겔슨(Mackenzie Fogelson)이 한 말입니다.
https://mackfogelson.com
p.115
- https://www.quora.com/What-are-some-good-alternative-titles-to-Community-Manager
- https://experts.feverbee.com/t/alternative-title-to-community-manager/5159/8
p.123
저는 Divio의 커뮤니티 및 도큐멘테이션 매니저인 다니엘레 프로시다(Daniele Procida)가 쓴 이 문서를 정말 좋아합니다.
https://www.divio.com/en/blog/documentation
p.125
https://en.wikipedia.org/wiki/Project_management
p.129
- 베어 더글라스는 대기업에서 커뮤니티를 구축해본 경험이 있는 데브렐 전문가입니다. 트위터는 @beardigsit
- https://www.heavybit.com/library/blog/building-developer-relations-teams/
p.137
카라는 멋진 여성이자 놀라운 커뮤니티 빌더로, DevOps 커뮤니티에서 만났습니다.
저와 카라는 경쟁사(카라는 퍼핏, 저는 셰프)에서 일하고 있을 때 알게 되어 친구가 되었습니다. 트위터는 @FeyNudibranch
p.145
http://cmxhub.com/keystocommunityreadiness
p.152
제레미 프라이스(Jeremy Price)예요. 트위터는 @jermops입니다. 그와 함께할 수 있어 행운이에요!
p.155~156
- 4장의 도입부에서 자동화된 데이터 수집이 중요하다고 한 이유에 해당합니다. 리서치를 위해 시간이 필요할 때, 그 리서치가 가치 있다는 것을 증명하기 위해 역추적하지 않아도 되기 때문이죠. 여기에서도 리비박스가 유용하게 쓰일 수 있습니다. 달성해야 하는 매출 관련 지표가 없더라도, 여러분이 정의한 지표들이 적어도 어떻게 영향을 주고 있는지 보여줄 수 있습니다.
- 여러분이 대기업에서 일하고 있다면, 영업 팀이나 지원 팀에 문의해서 피해야 할 고객이 있는지를 미리 확인해보세요. 최근 부정적인 경험을 한 고객이나 다른 회사의 프로덕트 사용을 고려하는 고객 등은 피하는 것이 좋습니다.
- API회사나 SDK를 제공하는 회사라면, SDK에 사용자 에이전트 문자열을 구현해 이 정보를 얻을 수 있습니다. 자세한 내용은 4장을 참고하세요.
- 이 사람들을 커뮤니티 멤버가 아니라 고객이라고 부르는 이유가 있습니다. 1장에서 커뮤니티는 ‘현재 프로덕트를 사용하고 있거나 사용하려고 하는 사람들의 모임 또는 프로덕트를 통해 도움을 받을 수 있는 모든 사람들’이라고 정의했습니다. 하지만 본문과 같은 상황에서는 현재 유료 또는 무료 고객의 정보를 활용해 그 고객들이 속한 더 큰 커뮤니티에 대한 인사이트를 얻으려 하고 있기 때문에 고객이라고 했습니다.
p.157
https://www.youtube.com/watch?v=Oq6tsM57JZ0
p.158
조노 베이컨(Jono Bacon)은 저서 『커뮤니티의 기술(The Art of Community)』의 2장에서 읽기 커뮤니티 vs. 쓰기 커뮤니티의 개념을 처음 소개했습니다.
p.159
옮긴이_두어크러시는 개인이 스스로 역할과 업무를 선택하고 실행하며 해당 일을 하는 사람에게 책임이 부여되는 조직 구조를 말합니다.
https://www.noisebridge.net/wiki/Do-ocracy
p.161
- http://thagomizer.com/blog/2017/09/29/we-don-t-do-that-here.html
- https://www.kubernetes.dev/docs/guide/
p.162
https://en.wikipedia.org/wiki/Benevolent_dictatorship
옮긴이_'자비로운 종신 독재자'는 개인의 이익보다 모두의 이익을 위해 결정을 내리는 독재자를 뜻하는 표현으로, 오픈소스 프로젝트를 리드하거나 큰 영향을 미치는 사람을 뜻합니다.
자비로운 종신 독재자는 커뮤니티에서 벌어지는 논쟁을 정리하고 의사결정을 내리는 경우가 많습니다.
- 원서에는 아래 링크가 첨부되어있습니다만, 보안이슈가 있을 수 있어 위의 링크로 대체했습니다.
https://www.catb.org/~esr/writings/homesteading/homesteading
p.163
- 르네 프렌치(Renee French, reneefrench.blogspot.com)라는 일러스트 작가가 그렸고, 예술가이자 멋진 데브렐 전문가인 애슐리 맥나마라(Ashley McNamara, @ashleymcnamara)를 통해 새로운 삶을 살게 된 캐릭터입니다.
- https://gopherize.me에서 여러분만의 고퍼를 만들 수 있습니다.
- 사이먼 옥슬리(Simon Oxley)가 만들고 카메론 맥에피(Cameron McEfee)에 의해 확장된 캐릭터입니다. 전체 스토리는 다음 링크에서 확인하세요. (http://cameronmcefee.com/work/the-octocat)
- http://www.extremeprogramming.org/rules/pair.html
p.171~173
- https://twitter.com/mattklein123/status/949387830588948480
- https://twitter.com/DrPizza/status/955552718126551041
- https://github.com/keen/community-team
- https://www.twilio.com/blog/developer-relations-at-twilio
p.176
- http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy
- http://thagomizer.com/blog/2017/09/29/we-don-t-do-that-here.html
p.178
체인지로그 또는 릴리즈 노트는 버그 수정, 새 기능 등을 포함해 프로젝트, 특히 응용 프로그램에 적용된 모든 주목할 만한 변경 사항에 대한 기록을 뜻합니다. 앱의 릴리즈 노트를 잘 쓰는 회사가 바로 슬랙(Slack)입니다. 저는 체인지로그나 릴리즈 노트를 잘 읽지 않는데, 슬랙의 앱 업데이트 내용만은 꼭 챙겨봅니다. 관련해서 다음 링크를 확인해보세요.
https://slack.com/apps/mac/release-notes
p.179
https://www.salesforce.com/products/community-cloud/overview
p.182
프란치스모(Fanchismo)의 오너이자 설립자. CMX 서밋에서 자주 발표하는 열정적인 사람입니다. 트위터는 @communitydrives
p.183
p.186
린지 얼릭의 발표(2016년 CMX 서밋 이스트): https://youtu.be/saTcOuAi0vc?t=5m54s
p.188
https://medium.com/google-developers/the-core-competencies-of-developerrelations-f3e1c04c0f5b
p.195
코드데이즈(CodeDaze) 2016에서 처음 만난 그녀는 저의 컨설팅 비즈니스에 도움을 주고 있기도 합니다. 트위터는 @rainleander
p.203
팁: 커뮤니티를 위한 콘퍼런스를 연다면, 소셜상의 친구와 동료들을 쉽게 알아볼 수 있도록 목걸이에 슬랙이나 트위터 아이디를 적어두는 것도 좋습니다.
p.214
후원 예산이 적은 스타트업 또는 작은 기업을 위한 팁: 콘퍼런스 주최 측에 후원 규모를 조정하는 것이 가능할지 물어보세요. 대부분의 콘퍼런스는 처음 후원하는 회사나 신생 기업을 위해 협상할 여지를 남겨두는 경우가 많습니다.
p.215
http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy
p.216~217
- 데브릴레이트(DevRelate)의 설립자이자 커뮤니티 펄스의 공동 호스트 중 하나인 PJ 해거티(PJ Hagerty)는 밋업닷컴에서 특정 주제에 대한 상위 20개 밋업을 큐레이션하기도 했습니다.
- 커뮤니티 펄스의 에피소드 20화에서 저와 공동 호스트들이 이 주제에 대해서 이야기를 나눴습니다(http://communitypulse.io/20-meetups).
p.222
https://groups.drupal.org/colorado
p.200
발표 관련 좋은 자료를 찾고 있다면 아래를 참고하세요.
- 발표에 대한 라라 호건(Lara Hogan)의 저서(http://larahogan.me/speaking)
- 스콧 버컨(Scott Berkun)의 이그나이트(Ignite) 강연 준비와 진행 방법에 대한 팁 (http://scottberkun.com/2009/how-to-give-a-great-ignite-talk). 이 팁은 긴 형식의 회담에도 적용할 수 있습니다.
- 크리스티안 하일만(Christian Heilman)의 ‘말하면 안 되는 것’ 블로그 포스팅 (https://christianheilmann.com/2016/07/06/things-not-to-say-on-stage-at-a-tech-event)
- 저는 특히 이 글을 추천합니다 https://medium.com/devrel-life/the-art-of-the-conference-talk-proposal-3e97cd3bd33a
p.227
커뮤니티 펄스(Community Pulse)에서 PJ 제이슨과 비키 브라수어를 인터뷰해
좋은 발표 개요서를 제출하고 멋진 발표를 하는 방법에 대한 이야기를 들어보았습니다.
http://communitypulse.io/23-cfps
비키 브라수어는 경이로운 발표자이며 오픈소스의 전설이자 놀라운 사람입니다. 트위터는 @vmbrasseur
p.229
- https://dev.to/mary_grace/burnout-what-happens-when-you-take-on-too-much-74d
- https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4911781
p.230~231
- burnout.io(https://burnout.io/en/latest/resources.html)에는 번어웃 관련 블로그 포스팅 링크와 커뮤니티 멤버들이 번아웃에 대해 이야기했던 내용(https://burnout.io/en/latest/furtherReading.html) 등 좋은 리소스들이 모여 있습니다.
- 이에 대해서 입증된 것은 아니지만, 디벨로퍼 애드보케이트들의 여러 블로그 포스팅에서 살펴볼 수 있습니다. 실제로 제 커리어에서뿐 아니라 동료나 친구들에게서도 이러한 추세를 확인할 수 있었습니다.
- https://medium.com/compassionate-coding/only-you-can-prevent-tech-burnout-be3f0504c627
p.233~234
- 니콜 포스그렌(Nicole Forsgren)이 제즈 험블(Jez Humble), 진 킴(Gene Kim)과 함께 쓴 『엑셀러레이트(Accelerate)』는 비난 없는 회고와 데브옵스, 애자일에 대해 참고하기 좋은 책입니다.
- https://landing.google.com/sre/book/chapters/postmortem-culture.html
- https://www.shrm.org/resourcesandtools/hr-topics/benefits/pages/unlimited-pto.aspx
p.237
블로그 포스팅의 주 내용은 커리어에 관한 것이지만, 글을 반쯤 읽어보면 제가 언급한 책장 이미지가 나옵니다.
https://waitbutwhy.com/2018/04/picking-career.html
p.241
저의 직장 생활 초반부터 함께해준 지지자이자 테크니컬 라이터. 트위터는 @kathrynb
p.243
- 릴리즈 엔지니어링 접근법을 만든 사람으로, 저의 오랜 친구이자 퍼시 컨설팅이라는 회사를 시작할 때 도움을 준 사업 멘토이기도 합니다. 트위터는 @jpaullied
- https://medium.com/@jpaulreed/dodging-burnout-4-hours-at-a-time-965f1921e6a2
p.245
https://adainitiative.org/continue-our-work/impostor-syndrome-training
p.246~247
- https://www.forbes.com/sites/lizryan/2015/06/29/im-so-over-we-need-a-rock-star/#3f4ddf050c1f
- http://communitypulse.io/24-imposter-syndrome
p.249
https://en.wikipedia.org/wiki/T-shaped_skills
p.251
https://medium.com/@ashleymcnamara/what-is-developer-advocacy-3a92442b627c
p.258
이 책을 집필하는 과정에 대해서는 다음과 같이 포스팅했습니다.
https://twitter.com/i/moments/983238008429133825
p.262~263
- 매주 목요일에 발송하는 데브렐 위클리(DevRel Weekly)는 관련 기사, 채용 공고 및 행사를 소개하는 주간 뉴스레터로, 여러분의 기고로 큐레이팅하고 있습니다(https://devrelweekly.com).
- REdeploy는 레질리언트 코드, 팀, 사람 간의 상호작용과 교차점을 탐구하는 콘퍼런스로, J. 폴 리드(J. Paul Reed)와 제가 공동으로 운영하고 있습니다. 첫 번째 콘퍼런스는 2018년 8월(https://re-deploy.io)에 개최했습니다.
- 개러스 그리너웨이(Gareth Greenaway)는 GIF 짤 장인으로 솔트스택(Saltstack)의 소프트웨어 개발자입니다. 트위터는 @garethg
p.264~265
- https://twitter.com/ember_dog/status/569246196759277569
- https://twitter.com/mary_grace/status/569316539989516289 를 참조하세요. 전 아직 이 왕관을 가지고 있어요!
p.268
p.277
https://www.sparkpost.com/docs/getting-started/getting-started-sparkpost
p.281
- 저는 아사나(Asana)를 주로 사용하며 트렐로, 에버노트, 지라를 사용하기도 합니다. 애자일하게 움직이기 위해 여러분에게 맞는 다른 툴들을 찾아보는 것도 좋습니다.
- 이 템플릿을 복사해 활용하세요. http://bit.ly/event-process
p.282
각 행사에 대해 설정하는 목표는 회사 전체의 목표에 따라 달라집니다. 회사 인지도를 높이기 위해 행사를 후원한다면 얼마나 많은 사람이 데모를 보거나 부스에서 소통했는가에 초점이 맞춰질 수 있습니다. 고객 커뮤니티를 구축하려 할 경우 추적하기 좋은 지표는 베타 테스트 프로그램에 가입한 사람 수가 될 수 있습니다. 팀의 올바른 목표를 설정하는 방법에 대한 자세한 내용은 4장의 리비박스를 참고하세요.
p.284~285
- 더 자세한 사항은 8장을 참고하세요.
- 보통 해커톤에서는 채용 기회보다 데모에 더 신경을 씁니다. 다만, 학생들은 채용 담당자가 있든 없든 상관없이 부스를 통해 이력서를 제출하곤 합니다. 채용 패키지를 빼는 대신 위 리스트에 있는 필요 사항을 받을 수 있을지 주최측과 협상해볼 수 있습니다.
- 콘퍼런스를 후원할 때 가장 중요한 사항이기도 합니다. 부스나 테이블이 없는 행사를 후원하면 참석자들을 만날 수 있는 장소가 없어 어려운 상황에 처할 수 있습니다. 8장에서 이야기했듯이 부스가 없더라도 현장에 직접 참여해 커뮤니티 멤버들을 만날 수 있는 방법도 있습니다.
- 행사 후원에 대한 결정을 내리는 사람들. 행사 예산을 가지고 있는 마케팅 팀이나 행사에 대해 결정할 부서장 또는 행사에 대해 알아야 할 동료들도 여기에 포함될 수 있습니다.
- 자세한 내용은 8장을 참고하세요.
p.286~287
- 이 네 단계는 링크 속 템플릿과 관련이 있습니다 http://bit.ly/sponsorship-spreadsheet
- 저는 아사나(Asana)를 주로 사용하며 트렐로, 에버노트, 지라를 사용하기도 합니다. 애자일하게 움직이기 위해 여러분에게 맞는 다른 툴들을 찾아보는 것도 좋습니다. 가장 좋은 방법은 매번 복사해서 쓸 수 있는 기본 템플릿을 갖추는 것입니다. 그러면 매번 새로 만들 필요 없이 날짜만 바꾸고 담당자가 누구인지만 업데이트하면 됩니다.
- ‘굿즈 바구니’ 템플릿은 다음 링크를 참고합니다. http://bit.ly/swag-buckets
p.289
기본적인 정보가 모두 포함된 이메일을 발송한 후, 미팅을 잡아 질의 응답 시간을 갖습니다.
고객과의 접점이 많을수록 팀이 준비해야 할 것도 많아집니다.
이메일 템플릿 예시는 링크를 참고하세요.
http://bit.ly/booth-staff-email
p.292
구글에서 ‘What is my IP address?’라고 검색하거나 다음 링크를 통해 확인할 수 있습니다.
https://whatismyipaddress.com
p.299
데브렐을 시작했을 때의 고군분투기를 마이크로소프트웨어 397호 ‘러닝커브’ 편에 <공부하는 개발자를 위해>라는 이름으로 기고했습니다. 개발 백그라운드가 없던 제가 개발자 커뮤니티와 소통하기 위해 어떤 노력을 했는지와 함께 당시 팀의 데브렐 활동도 자연스럽게 소개했습니다.
p.306
p. 308~309
- https://www.youtube.com/c/MicrosoftDeveloperKorea
- https://aka.ms/devKR
- https://docs.microsoft.com/ko-kr/users/ianchoi
p.320
https://devocean.sk.com