2023 Devfest WebTech 후기

책 쓰는 개발자

13 min readOct 29, 2023

요거 다녀왔다.

원래 행사의 존재를 몰랐어서 티켓을 못 구했었는데, 3일전에 운 좋게 취소표를 주워서 다녀올 수 있었다.

행사 주최는 GDG Korea Webtech라는 커뮤니티인데, 구글에서 지원하는 로컬 커뮤니티 Google Developer Groups가 있고 (전세계단위), 이 중 Google Developers Korea에 여러 챕터(지역단위)가 있는데, 이 중 GDG Korea WebTech 에서 주최하는 행사였다. 꽤 복잡해보이지만 아무튼 웹 개발과 관련된 여러 주제를 다루는 커뮤니티라고 생각하면 되겠다.

왠지는 모르겠지만 이번은 “웹 개발”은 아니고, “웹 개발” 관련 지식을 책으로 쓴 사람들의 이야기를 주제로 진행된 행사였다.

장소

장소는 성수의 엘리스랩이었다. (elice.io의 그 엘리스)

2호선 성수와 건대입구역 어디서 가더라도 어중간하게 꽤 걸어야 했는데 크게 문제가 되진 않았음.

건물 자체는 다른 건물과 독립적인 공간에 있었고, 층고도 높고 좋았다고 생각한다.

다만 의자는 대충 30석 언저리였고, 참여자는 (아마 연사 / 운영진 제외) 55명이어서 벽쪽 좌석까지 사람들이 자리했다.

세션 내용 요약

늘 그렇듯 메모와 기억을 기준으로 쓴 것이니 실제와는 다를 수도 있다 !

1. 책쓰는 개발자

제로초로도 알려진 조현영님의 세션 (풀 정장 입고 오심)

ZeroCho Blog

ZeroCho의 Javascript와 Node.js 그리고 Web 이야기

www.zerocho.com

이렇게 의자에 앉아서 진행자와 (GDG 운영진) 사전에 받은 질답을 주제로 이야기 나누는 시간이었음.

책 쓰게 된 계기

(자바스크립트를 다루는) 개발 블로그를 하면서, 다른 사람을 가르치는 말투를 사용했는데 글이 쌓이고 고쳐지면서 출판사(길벗)에서 집필을 제안하여 책을 쓰게 됨.

책을 쓰면서 어려웠던 순간은

600쪽을 1년 넘는 기간 동안 집필하다보니 포기 피로도가 높음, 포기하지 하지 않는 것이 중요함

다행히 책을 3권 출간 하고나니 요령과 노하우가 생기면서 점점 책을 집필하는 것에 쓰이는 시간이 줄어들고있다.

별도로 기술 책은 내용의 버전이 업데이트가 잦은데 (특히나 웹은 더) 출간 이후 개정을 위해 지속적으로 트래킹 하는 것이 어려운 문제가 되는 편

기존의 JS, TS, Node 외에 다른 주제로도 책을 쓰고 싶다면?

Nest.js를 고려하고 있음

책도 쓰지만 어쨌든 현업에서의 개발자인데, 현재 회사에서는 어떤 업무를 하시는지

출간과 강의는 부업이고, 본업은 창업. 지금은 생성 AI 서비스 (스모어톡)를 제공하는 조직의 CTO

같이 하기 위한 개발자로는 어떤 개발자상을 기대하시는지?

5년차 퍼포먼스를 가지고 있는 신입이라면 좋겠지만, (농담이고) 눈치가 있으면 좋고 지식을 빠르게 습득하는 능력과, 의사소통하는 능력. 그리고 절실함이 있으면 더 좋을 것 같다.

이러한 역량들을 어떻게 트레이닝 할 수 있을까?

눈치는 학습이 어렵지만 그나마 사회생활. 가정을 가지고 있으면 절실함이 좀 있고, 사실 프로그래밍이 적성에 맞는지 (재미가 있으면) 도 중요한 것 같다.

이전 창업 회사의 엑싯의 경험은 어떠셨는지

5년 창업 하고 전부 망하고 전업 강사를 고민하던중 마지막에 함께한 조직이 잘 된 운 좋은 케이스.

스타트업이 잘되고 망하는 것은 개발보다는 다른 부서의 몫이라고 생각함.
개발은 일종의 “조연” 이지만, 동시에 주연에게 민폐를 끼치지 않는 조연이 되도록 노력해야함.
개인적으로는 스타트업의 여러 역량들 중 특히나 운 >>> 실력 이라고 생각함

오늘의 픽업은 카카오 계열사의 마지막 인수 기업이었음.

높은 개발 퍼포먼스의 비결은?

어떤 (개발)지식을 학습할때 (강의가 아닌) 공식문서 + 레퍼런스를 애용함. 이를 위해 평소에도 개발 생각을 많이 하고, 타자를 실제로 치는 시간은 업무 시간의 10% 미만이라고 생각함. 출퇴근 시간때 공식문서를 읽거나 코드를 생각하는 경향이 있음

개발 공부하는 순서는 어떻게 되는 것이 좋을까?

API에 너무 집착하지 말고 , 해당 기술을 사용하는 “순서”를 익히는 것에 집중하는 것이 좋다. React라면 Life cycle에 학습 시간을 우선 쏟는 것이 좋다.

시간관리는 어떻게 하시는 지?

(이것도 어렵지만) 남들보다 한두시간만 더 하자 라고 생각 . Power J 형 성격이지만 장기 계획은 크게 의미가 없는 것 같고, 방향만 잡아두고 그때그때 최선을 다하자 라는 마인드

Q&A

타입스크립트의 가장 중요한 개념?

JS가 90%의 내용과 겹치기 때문에 이를 보고 추가로 Generic, Infer 정도가 중요한 것 같다.

사업초기 MVP 전문 개발자가 되려면 어떤 경험과 지식을 쌓는 것이 좋을까? 최소기능의 범위와 당면한 상황에서의 최적의 도구는 어떻게 찾아낼까?

이건 개발이 아닌 기획 / 대표가 정해서 와야하는 것. MVP 로 한정하지 말고 프로덕트를 잘 만드는 개발자를 목표로. 최적의 도구는 자신, 팀이 자신있어하는 언어 라이브러리 프레임워크를 잘 활용하는 것

취준생인데 창업의 꿈을 갖고 있다. 실무 경험이 없지만, 창업팀 개발자로 활동하는 것에 대해 조언?

실무 경험이 없더라고 어느 정도는 아는 것이 중요. 절실함은 있겠지만 실력이 없다면 팀에게 민폐를 끼칠 수 있다. 아예 하지말라 까진 아니지만 일 마치고도 열심히 계속 공부를 해야한다.

개발팀이 빌딩 되는 상태, 문서화는 어떻게 하는 것이 좋을까?

남을 위해 쓰는 것도 맞지만, 미래의 자신을 위해 쓴다고 생각하면 좋다. 문서화를 하면 개발 시간이 줄어들기에 아쉽게 느껴질 수 있지만 개인적으로는 2번 반복되면 문서나 테스트를 남긴다.

기획에 참여하는 개발자의 역할은?

개인 경험에 따르면, 회의에서의 개발자의 역할은 다른 회의 참여자의 허무 맹랑한 아이디어를 판단하는 역할. 된다 / 안된다. 를 넘어서 안되면 대안을 제시할 수 있어야 함

2. ‘기술블로그'를 운영하며 개발 조직의 성장 과정을 기록하는 방법

우아한형제들(배민)의 유영경님.

기술 블로그로 개발 조직의 성장 과정을 기록 한다. = 글쓰기

개발자들은 이미 바쁜데 회사는 왜 글을 쓰라고 할까? (API, SDK, 운영 가이드등..) 3가지 이유가 있음

의사소통: 어느 회사던 어렵다.
기록 / 보존: 퇴사와 맥락, 히스토리를 유지
성장: 모호한 단어지만, 개인을 네임드로 성장시키는 회사가 좋은 회사

우형외에도 많은 조직들이 기술 블로그를 운영한다 (*차라투도 있다 !)

우형 기술 블로그의 특징은 오래되기도 했지만, 이전의 CTO / CEO가 진심을 담아 만들었고 적극 문화로 권장했다 (회사 문화가 뒷받침 되어야 잘 운영된다)

마찬가지로 책을 만드는 활동도 다른 조직에서도 하고있음 (네이버 시절 네이버는 이렇게 한다 시리즈를 만들었고 책 별로 짧겐느 6개월 길게는 2년이 걸리는 어려운 노력임)

글쓰기를 돕는 테크니컬 라이팅 코치

하는 일은 크게 3종류. 작성된 글을 검토, 테크니컬 라이팅을 교육. 마지막으로 1:1 코칭

이것들의 효과외에도 글을 쓰는 사람들의 심리적 부담감이 낮아진다는 큰 효과가 있음. 내 뒤에 “전문가”가 있다로 이 글 써도 되나, 부끄러운데, 이런 주제로 글을…? 과 같은 부담감이 줄어든다.

글 발행 과정은 아래와 같이 5단계로 구성되며, 보통 2–3주 걸리는 듯(*기억이 애매함)

테크니컬 라이팅 기본 원칙

테크니컬 라이팅이 다른 글쓰기와 다른점은 읽는 사람이 (명확하게 정해진)있는 글. 수필 메모장이 아니기 때문에 명확성, 간결성, 일관성이라는 3가지 원칙을 지키는 것이 좋음.

글 고치기 사례

이거 진행하면서 답변 한 사람들에게 책 3권 주심 (우아한 개발 2권. 개발자를 위한 글쓰기 1권)

핵심은 이전 3원칙: 명확하고 간결하고 일관성 있게 작성하는 것.

글의 형식은 갖추되, 말하듯 작성해야하지만 동시에 DB를 까보고, 로직을 파보고… 와 같은 단어를 사용하여 독자를 소외시켜서는 안됨.

FAQ

글 써도 될까요 못쓰겠어요 너무 오래걸려요…

일단 쓰자

글은 어떤 순서로 쓰나요

“코드처럼” 덩어리 단위로 쓴 다음 나중에 맞춰도 괜찮다.

좋은 글을 위해 어떤 것이 필요할까요

고치기 시간 + 동료 (다양한 관점의)의 피드백

테크니컬 라이팅을 위한 학습자료는 어떤게 있을까요?

Google 의 TW 코스, MS의 Style guide, 이전에 올린 유데미 강의

번외

책 들고 가서 싸인 받았다 ㅋㅋ

3. 책쓰는 개발자의 고민상담소

캡틴판교님. 웃음 빌게이츠 + 웃음 소리가 엄청 특이함. 마찬가지로 진행자와 사전질문에 질답하는 형식으로 진행됨

캡틴판교 블로그

Javascript, Vue.js, Progressive Web Apps 그리고 재밌는 프론트엔드 개발 이야기

joshua1988.github.io

두번째 사진은 빵 터진 내용인데. 사전 질문중 주제가 커뮤니케이션인데 질문이 저렇게 커뮤니케이션을 잘 하는 방법. 이렇게만 와서 많은 의미를 담고 있던 질문 ㅋㅋ

책을 쓰고 난 이후에 바뀐 점이 있다면

집필 교정을 거치면서 글쓰기의 퀄리티가 좋아지고 덩달아 개인의 글쓰기도 발전됨. 처음에 쓰던 글에 비해 최근의 글을 보면 많이 체감 됨

지금 하는 활동 “지식 공유” 의 계기는?

지인이 판교의 기획자였는데 (개발자와의 소통을 위해) 기술을 알려주자 라는 생각을 하게 됨. 매번 파일로 하기도 벌거로워서 slideshare에 올리는 것으로 시작. 지금도 주말마다 멘토링을 하고 있는데 개인적으로 다른 사람을 돕는 것을 좋아하는 성품

시니어 개발자는 어떤 고민을 하는지?

연차가 10년 넘긴 했지만 시니어 인지는 모르겠음. 아무튼 고민은 회사의 업무와 개인의 콘텐츠 제작. 을 위한 시간 밸런스 조절 이 주로 고민. 회사, 팀빌딩, 나의 일 등 여러 고민이 있음

고민 상담소를 하는 이유?

이전에 GDG WebTech의 운영진 경험도 있고, 커뮤니티 자체를 좋아함

블로그가 취업, 이직에 도움이 되는지.

대기업은 시스템상 큰 도움이 되지 않고, 스타트업은 좋게 볼 수도 있음. 개인적으로는 블로깅이 성실하게 행위를 남기는 활동이라고 생각하여 좋게 보긴 함. 그러나 모든 블로깅이 좋은 것은 아니고, 일기쓰듯 하는 것은 오히려 안하는 것이 더 좋다고 생각. 문제 -> 해결 이 과정에서 논리적인 해석과 글로 풀어내는 커뮤니케이션이 드러나는 블로그가 도움 된다고 생각함

Q&A

어떻게 해야 사수 없이 잘 성장할 수 있을까? 다른 팀, 다른 회사, GPT , 테크닉 강의와 책… 등 다양한 시도를 해봤지만 여전히 어렵고 정답에 가까운 프로덕션 수준의 코드를 만들어야 한다고 생각하는데 방법이 궁금

태도가 이미 좋음. 이런 사람은 오히려 사수가 없어야 함. 회사의 개발 리소스가 적어서 코드를 고민할 시간이 없음에도 고민을 하고 있음. 사수가 있으면 오히려 그사람한테 일이 다 갈 수도 있고 성장이 어려워질 수 도 있으므로 이 사람은 회사에서 성장을 이끌어 낼 수 있는 일들이 잘 배치 되는 것만으로도 충분. 힘들겠지만 나도 사수 없이 컸고, 혼자 이것저것 고민하다보면 나오는 양질의 정보로 성장할 수 있다. 의도적 수련이 중요

커뮤니케이션 잘하는 방법 (위 사진)

개발자는 사람보단 코드와 이야기를 하게되고 언어능력이 점점 퇴화되는 것 같음. 개발자끼린 말을 못해도 키워드로 소통이 가능함. 의도적으로 비개발직군과 소통 연습

남는 Q&A는 이후에 개인 유튜브 고민상담소에서 다뤄보겠음.

10년 전 자신, 혹은 초년생에게 하고 싶은 말?

딱히 없음… ㅋㅋㅋㅋ 개인 프로젝트에 진심을 담아서 엑싯을 빨리 했으면

네트워킹

같은 공간에서 피자를 나누고 (넉넉했다고 함) 자리를 바꿔서 이야기했음. 의자 그룹마다 연사자 1명씩 가서 이야기 나눔. (내가 있던 쪽에는 제로초 조현영님이 오심)

우리 그룹에는 (개발자라?) 사람들이 부끄러움이 많아서 그냥 내가 먼저 막 질문했다. 10개 정도 한 것 같은데 기억나는 것만 쓰겠다

창업에 중요한 것?

팀빌딩, 운, BM 등 정말 많은데, 의외로 아이템은 가장 중요한 것이 아님. 엄청 피봇팅함. 구성원에 적당히 밸런스를 잡는 것도 중요 (개발 + 기획 + 디자인+ 마케팅)

글 쓰기 동기부여?

개인적으로는 강의를 위한 글쓰기였음.

다른 강의와의 차별점?

다른 강의를 본 적은 없지만, 가격으로 차별을 주는 것은 어려운 것 같고, (특히 유데미를 포함한 해외강의) 그냥 내 스타일의 강의를 좋아하는 분들을 만족시키는 것이 좋은 것 같다.

본인 팀의 업무를 다 하고 다른 팀을 돕는 것은 이상하게 보일까?

전혀 그렇진 않지만, 업무 분배를 잘못했거나 (다른 팀의) 퍼포먼스가 예상 밖이거나 경영차원에서의 문제라고 생각함.

회사의 서비스나 강의 프라이싱은 보통 어떻게 하시는지?

유사한 서비스의 프라이싱을 참고할 수 밖에 없는 것 같다. 체감상 그들도 각자의 고민을 가지고 최대한 마진을 덜 내지만 굶어죽진 않을 정도로 내는 것 같고, 요즘은 특히 스타트업들이 손실을 기본 전략으로 정하는 것 같다.

기술블로그에 써도 되는 글과 안되는 글? (대외비 같은)

회사의 코드를 그대로 쓰는 것은 어렵지만 최대한 단순화해서 하다못해 변수 이름이라도 바꿔서 쓰는 것 정도는 괜찮지 않을까. 어차피 작정하면 블로그 글의 내용을 다 똑같이 만들어 낼 수 있다고 생각함

글감 관리 / 수집은 어떻게 하시는지

이제는 나이가 있어서 기억이 잘 안남. 미래의 자신을 위해 메모 한다는 느낌으로 글을 써두고 (발행을 하지 않을 뿐) 생각보다 구글링하면 내가 이전에 쓴 글이 나와서 도움이 됨

책 쓰기 위한 저술 과정에서의 좋은 출판사는?

판매가 목적이면 대형 출판사가 마케팅 역량에서 좋은 것 같다, 출판 자체가 목적이면 셀프 출판. 아니면 PDF 출판도 의미있는 경험이 될 수도 있음.

평소에 스트레스 관리 어떻게 하시는지

유튜브 2시간 씩 보면서 놈. (경제 사회 문화…등 지식을 채우는 유튜브라고)

이외에도 여러 Q&A가 있었는데 다른 일정이 있어서 중간에 나왔다. (현영님 특성상 창업에 대한 질문이 꽤 많았음)

정리

GDG WebTech 행사의 메인 주제는 “책 쓰는 개발자”. 라는 이름이었지만 “(책 쓸 수 있을 정도로) 자기 계발에 관심을 갖는 프론트엔드 개발자”… 라고 느껴졌다.
기대한 것은 얻지 못했지만, (당연히) 기대하지 않은 것을 얻을 수 있었다 !!!

Arcade | Create Interactive Product Demos

Arcades are super easy to create. Build interactive product tours to embed within websites, blogs, and social media.

www.arcade.software

성수는 너무 멀다.
네트워킹 시간에 너무 질답만 한 것 같다. 물론 명함을 주거나 사진을 찍었다고 해서 뭐가 바뀌진 않겠지만.
개인적으로는 (교육 업계에 있었던 만큼) 강의팔이, 책팔이… 가 되어버리면 어떡하지라는 걱정이 늘 있다. 너무 뻥튀기를 하거나 드러내지도, 그렇다고 아예 있는지 없는 지도 모를 정도로 숨지도 않는 적당한 PR은 가능한 것일까. 브랜드 설계자 라는 책을 읽고 있는데 실마리를 잡을 수 있을지도 모르겠다.