blog.holy.kiwi

👨‍💻 내가 맥북을 세팅하는 방법

업데이트 2021-04-21: 자주 사용하는 애플리케이션 추가함

맥북 2015년형에서 2019년형으로 바꾸는 김에 작성하는 나만의 맥북 세팅, 필수 애플리케이션 정리

시스템 환경설정

키보드

키보드 > 단축키

이전 입력 소스 선택(한영전환)은 command + space로 변경
Spotlight 검색 보기는 control + space로 변경

키보드 > 텍스트

맞춤법 자동 수정 X
자동으로 문장을 대문자로 시작 X
스페이스를 두 번 눌러 마침표 추가 X
Touch Bar 입력 제안 X

키보드 > 키보드 > Control Strip 사용자화

터치바 사용자화 가능
- 잠자기 버튼을 시리 대신 배치함

Dock

Dock은 오른쪽으로
확대 X
가리기 X

사운드

메뉴 막대에서 음량 보기를 체크

파인더

파인더 - 보기 - 경로 막대 표시, 상대 막대 표시
파인더 - 환경설정 - 고급 - 폴더우선정렬: 윈도우에서
- 정렬 상관없이 폴더가 맨 위로 정렬

Siri

Siri에게 요청하기 활성화 해제

트랙패드

탭하여 클릭하기

기타

오디오 파일이 음악앱에서 안열리게 하기
- 정보 가져오기 - 다음으로 열기 - 퀵타임 플레이어 - 모두 변경

필수 애플리케이션

VS Code (비주얼 스튜디오 코드)

JS 개발자가 가장 많이 사용하는 IDE

설치해야 하는 확장프로그램

eslint
prettier
Material Theme
- Material Theme High Contrast 사용중
Material Icon Theme
git lens
git history
Typescript React code snippets

폰트

FiraCode

설정

Settings > Format On Save 체크
Preferences > Keyboard Shortcuts
- 오른쪽 상단에 Open Keyboard Shortcuts (JSON) 클릭 후 다음 코드 추가
- command + 숫자 조합으로 탭 이동 가능

설정 코드 펼치기 / 접기

[
    {
        "key": "cmd+0",
        "command": "workbench.action.openLastEditorInGroup"
    },
    {
        "key": "cmd+1",
        "command": "workbench.action.openEditorAtIndex1"
    },
    {
        "key": "cmd+2",
        "command": "workbench.action.openEditorAtIndex2"
    },
    {
        "key": "cmd+3",
        "command": "workbench.action.openEditorAtIndex3"
    },
    {
        "key": "cmd+4",
        "command": "workbench.action.openEditorAtIndex4"
    },
    {
        "key": "cmd+5",
        "command": "workbench.action.openEditorAtIndex5"
    },
    {
        "key": "cmd+6",
        "command": "workbench.action.openEditorAtIndex6"
    },
    {
        "key": "cmd+7",
        "command": "workbench.action.openEditorAtIndex7"
    },
    {
        "key": "cmd+8",
        "command": "workbench.action.openEditorAtIndex8"
    },
    {
        "key": "cmd+9",
        "command": "workbench.action.openEditorAtIndex9"
    },
    {
        "key": "ctrl+1",
        "command": "workbench.action.focusFirstEditorGroup"
    },
    {
        "key": "ctrl+2",
        "command": "workbench.action.focusSecondEditorGroup"
    },
    {
        "key": "ctrl+3",
        "command": "workbench.action.focusThirdEditorGroup"
    },
    {
        "key": "cmd+'",
        "command": "editor.action.goToTypeDefinition"
    }
]

Alfred 4

Alfred 없이 macOS를 쓰는건 매우 불편하다.
Mega Supporter 파워팩을 구매해서 사용하고 있다.
주로 Alfred의 Clipboard History, Snippets, Web Search, Workflows 기능을 사용한다.
- Clipboard History 기능은 복사하는 내용들을 보관해준다. 텍스트, 사진 등 모두 보관해줘서 편리하다.
- Snippets 기능은 많이 쓰는 텍스트나 이모지를 짧은 텍스트로 매핑해놓으면 편하게 사용할 수 있다.
- cslg 네글자만 입력하면 console.log({cursor});과 같은 코드가 작성되도록 하는 등 설정할 수 있다.
추천 workflows는 alfred-workflows 참고

Git Kraken

Source Tree에서 Git Kraken으로 옮김
매우 직관적인 Git GUI 애플리케이션 (유료)

Magnet (마그넷)

유료 애플리케이션 (살 때는 1,200원이었는데 지금보니 3,900원이다)
단축키로 화면 분할을 쉽게 할 수 있게 해줌

TickTick

할일 목록을 체계적으로 관리할 수 있음
마크다운도 가능
모바일, 데스크탑 모두 지원함
유료임

Microsoft Office (Word, Powerpoint, Excel)

선택 애플리케이션

ScreenFlow 8

화면 녹화용
라이센스는 동시에 한 컴퓨터에만 적용 가능
버전 업그레이드 하는데 또 돈 내야해서 일단 8 쓰는중

CLI

Homebrew

macOS용 패키지 매니저

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

git

mac은 설치되어

yarn

Facebook에서 만든 node package manager

npm install -g yarn

oh my zsh

A delightful community-driven framework for managing your zsh configuration.

Git 권한 설정

터미널에서 키 생성

ssh-keygen -t rsa -C {이메일}

ssh 키 등록

ssh-add ~/.ssh/id_rsa

깃헙에 키 등록
github -> settings -> SSH and GPG keys -> New SSH Key -> public key 복붙!

커맨드마다 passphrase 입력하기 귀찮으면

eval ssh-agent로 agent를 실행
ssh-add -K ~/.ssh/<privatekeyfile> 프라이빗키를 등록
https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html 참고

터미널 환경 세팅

iTerm 2 설치
oh my zsh 설치
다음 명령어로 기본 쉘을 zsh로 변경

chsh -s /usr/bin/zsh

~/.zshrc 파일에 들어가서 ZSH_THEME="agnoster"로 터미널 테마 변경
ubuntu mono derivative powerline 폰트 설치

iTerm 2 -> Preferences -> Profile -> Text -> Font 변경

다음 레포지토리를 클론하여 dracula 테마 적용

git clone https://github.com/dracula/iterm.git

iTerm 2 -> Preferences -> Profile -> Color -> Color Presets 변경

터미널에서 username 제거

~/.zshrc 파일 맨밑에 넣어주면 된다.

prompt_context() {
  emojis=("🥝" "🔥" "👑" "😎" "🐵" "🦄" "🌈" "🚀" "💡" "🎉" "🇰🇷" "🌙" "🌞")
  RAND_EMOJI_N=$(( $RANDOM % ${#emojis[@]} + 1))
  prompt_segment black default "${emojis[$RAND_EMOJI_N]} "
}

zsh 플러그인 zsh-syntax-highlighting 설치

터미널에서 사용 가능한 커맨드는 초록색, 사용 가능하지 않은 커맨드는 빨간색으로 표시해줌

# brew를 통해 설치해줍니다.
brew install zsh-syntax-highlighting
# 플러그인을 적용합니다.
source /usr/local/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh
# 위 커맨드를 ~/.zshrc 맨 아래에 넣습니다.

참고

서울리안님 유튜브 https://www.youtube.com/watch?v=WP1_CrtufvY

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

🎄 크리스마스에 치앙마이에서 2019년 회고 쓰는 내 인생이 레전드다

현재 시각 오후 12:47 (태국 현지 시간 기준) 치앙마이에서 일하기 좋은 카페 Brain Awake에서 이 글을 씁니다. 이름이 너무 마음에 듬. 아 에어팟 놓고 왔네 망했다.

올해 3월에 2018년 회고를 썼었는데 벌써 2019년 회고라니

🏫 여름까지 회사와 학교를 병행

2019년 3월, 학교에 복학했다. 하지만 일이 있었다. 1차 복학신청 기간을 놓쳐서 수강신청 후에 2차 복학신청 기간 때 복학 신청을 해야했다. ~~날짜를 잘못봤다.~~ 그래서 수강신청을 못했다. 당연히 ~~꿀 빠는~~ 인기 있는 수업들은 고사하고 전공필수까지 못듣게 될 상황이었다. 전공 수업 세 개를 개강 후에 겨우 GET했다. (교수님한테 찾아가서) 그리고 회사에 이번에 수업을 조금 듣게 되었으니 학교 다니면서 회사도 같이 다니고 싶다고 말했다. 회사는 OK 해주셨고 내 편의를 봐주셔서 80%의 근무만 하도록 허용해주셨다. ~~당연히 월급도 80% 히히~~ 하루는 원격으로 근무했고 토요일엔 10 to 7 FULL 근무를해서 근무시간 80%를 채웠다.

토요일에 회사에 혼자 가니 무척 심심했다. ㅠㅠ (가끔 스터디 하러 오신 동료 개발자 형님 오셔서 좋았음 shout to @knilnissim) 토요일 오전에 사먹는 타이거슈가 꿀맛!

주로 node.js 백엔드 업무를 맡았고 그렇게 6월 종강까지 학교와 회사를 병행하면서 바쁘게 지냈다. 바쁘게 지내서 뭔가 뿌듯했지만 너무 정신없었다. 다시는 못할것 같다. ~~시험기간 벼락치기를 위해서 휴가를 써야하는 슬픔.~~ 3학년 1학기 때 전공학점을 너무 못채워서 4학년 1학기 때 빡세게 들어야한다.

2019년 1학기 시간표

🚪 회사 첫 퇴사

6월 중순에 종강하고 7월말까지 회사를 다니고 퇴사했다. 인턴 기간까지 1년 8개월동안의 내 첫 회사생활을 마쳐서 아쉬움이 더 컸다. 전역하고 바로 입사해서 그런지 제 2의 군대를 전역하는 느낌이었다. ~~문화가 군대라는 건 절대 아님. 퇴사 느낌이 그렇다는거.~~ 하지만 회사생활은 정말 재밌어서 군생활보다 훨씬 짧게 느껴졌다. 첫회사를 핀다로 오게 된건 정말 큰 행운이었다. 모두에게 배울 점들이 넘쳤고 스타트업은 정말 재밌고 성장하는 곳이라는 느낌을 뇌리에 강하게 박히도록 했다. 전역 후 회사로 오지 않고 바로 학교에 갔더라면 시야가 좁은 우물 안의 개구리 학생으로 학교 생활을 마쳤을 것이다. (학교에서는 주로 Low Level의 시스템 프로그래밍 위주로 배우기 때문)

🎎 사이드 프로젝트

군돌이 - 국민 전역일계산기 앱

군돌이는 예전 포스트에서 말했듯이 2018년 8월에 React Native로 개발해서 9월에 런칭한 전역일계산기 앱이다. 2018년 회고글을 쓸 때만 해도 군돌이가 이렇게 클 줄 몰랐는데 2019년 4월 이후로 연예인 입대와 맞물려 급성장을 해서 현재는 누적 20만 다운로드에 달하는 애플리케이션이 되었다. (앱스토어에서 무료 라이프스타일 카테고리 3위, 전체 38위까지 랭크된 적도 있다.)

2019년 군돌이 작업 내용

군인 최대 8명까지 등록 가능
13개국 언어 지원
테마 변경 기능
iOS, Android 위젯 기능
공지사항 게시판 추가 (AWS Lambda, DynamoDB 이용)

유저와의 소통을 중요시하려고 매우 노력중이다. 플레이스토어와 앱스토어의 리뷰에 대부분 답변을 달고 있고, 이메일로 오는 문의 메일들로 소통하고 있다. 문의사항, 건의사항 등 피드백을 받다보면 여러 유저분들이 중복으로 느끼는 니즈가 있는데 (가령 몇개월 며칠 표시 기능) 유저들의 니즈를 바탕으로 작업의 우선순위를 정하고 있다.

군돌이 활성사용자 그래프

카카오톡 FUN 메인에 뜬 군돌이 관련 글

Playground - 교내 소프트웨어 공모전 참여 (학장상)

교내 소프트웨어 공모전이 매년 8월 ~ 9월에 열리는데 이 공모전에서 은상 이상을 수상하면 졸업요건 중 하나가 채워진다. 그리고 학교 다니면서 교내 소공전은 한 번 참여해봐야 하지 않겠나 하고 1학기 초반부터 팀 빌딩을 했다. 성실한 친구들 위주로 팀을 구성했고 1학기 내내 아이디어 회의를 했다. 그렇게 해서 나온 아이디어는 플러그인을 통해 확장하여 사용가능한 웹 대쉬보드였다. 사용자가 HTML, CSS, Javascript를 통해 플러그인을 개발해서 플랫폼의 마켓플레이스에 업로드할 수도 있고 다른 사용자가 개발해놓은 플러그인을 개발해서 다운로드할 수 있는 웹 기반 대쉬보드 플랫폼이었다. 팀 구성은 내가 전반적인 개발을 담당했고 웹 프론트엔드 개발 1명, 백엔드 개발 1명, 디자인 1명으로 구성했다. 사용한 기술 스택은 React, Typescript, Mobx, Node.js, Express, Serverless, AWS DynamoDB, AWS Lambda였다. 처음 서버리스 프레임워크를 사용해봤는데 서버 개발이 쉽고 재밌었다. 다음에도 서버 개발할 일이 있으면 서버리스로 할 것 같다. 또 리액트로 서버에서 받아온 동적인 JS 코드를 컴포넌트에 주입할 때 어려움이 있었지만 Function 생성자를 통해 서드파티 모듈을 사용할 수 있도록 하는 등 삽질 후 해결했다.

참 신기한 생성자다.

const sum = new Function('a', 'b', 'return a + b');

console.log(sum(1, 2));     // 3

플레이그라운드 대쉬보드 스크린샷

인공지능, 블록체인, 임베디드 등 상 받기 좋은 기술 없이 오로지 웹 기반으로만 개발해서 높은 상은 기대하지 않았는데 두번째로 높은 학장상을 받아서 기분이 너무 좋았다. 공모전 작품 전시할 때도 많은 분들이 칭찬해주셔서 보람 있었다. :)

프로젝트 링크: http://plgr.netlify.com/

2019 NAVER CAMPUS HACKDAY WINTER 참여

네이버에서 주최하는 대학생, 대학원생들만 참여할 수 있는 1박 2일 해커톤이다. 기존 해커톤 개념과는 다르게 미리 주제가 정해져 있고 참가자들은 정해져있는 주제 중에 선택해서 참가하는 방식이었다. 기본적으로 주제당 멘토는 1명, 멘티는 최대 3명이었다. 역시 네이버 해커톤이라 그런지 참가하는데에도 지원서에 쓸 내용이 많았고 코딩테스트까지 봤다. 코딩테스트를 못봐서 큰 기대를 하지 않았는데 다행히 운좋게 참가자로 선정돼서 참가할 수 있게 되었다. 사전 모임에서 멘토님께 들었는데 코딩테스트 결과는 참가자 선정에 크게 영향이 없었다고 하셨고 깃헙과 어떤 프로젝트를 했었는지 등을 최우선적으로 보셨다고 한다.

원래 주제와는 다르게 요즘 핫하게 떠오르는 프론트엔드 프레임워크인 Svelte로 컴포넌트 만들기를 하기로 했다. 아예 새로운 기술로 도전적으로 1박2일 해커톤을 하는 것이 의미 있어 보였다. 그렇게 1박 2일동안 네이버의 춘천 커넥트원에 가서 맛있는 것도 많이 먹고 스벨트로 코딩도 열심히 하고 좋은 시간을 보냈다. 무엇보다도 숙소가 대박이었다. 1인실이었고 시설이 무척 좋아서 호캉스 온 느낌이었다. ~~보안서약서를 작성해서 내부 사진은 공개하지 못합니다 ㅠ~~ 이후에 멘토님이 긍정적으로 평가해주셔서 네이버 핵데이 우수참가자 전형으로 인턴 면접을 볼 수 있었다.

awesome-apple-watch 레포지토리 ⭐100

심심풀이로 연습삼아 애플워치 앱을 개발할 때 작성한 애플워치 관련 라이브러리와 자료 등을 모아놓은 awesome-apple-watch 레포지토리다. 별이 꾸준하게 천천히 오르다가 시험 기간에 공부하다 심심해서 해외 커뮤니티인 레딧에 레포지토리 홍보글을 올렸더니 며칠만에 ⭐100이 되었다. 문서 레포지토리라서 개발 실력과는 관련이 없지만 많은 해외 개발자들이 관심을 가지고 별을 눌러줘서 기분이 좋았다.

awesome-apple-watch 레포지토리

1일 1커밋

2018년 4월 29일부터 꾸준히 1일 1커밋을 하려고 노력하고 있다. ~~듬성듬성 빠진 잔디도 있지만.~~ 역시 1일 1커밋을 습관화하다보니 알고리즘 문제를 풀어서 올린다던가 Readme 문서를 고친다거나 하는 쓸데 없는 커밋이 늘어가고 있는 느낌이 있긴 하지만 형식적으로라도 습관화하는게 중요하다고 생각한다. ~~아님 말구~~

1일 1커밋 잔디

첫 외주

11월에 동료였던 개발자분이 외주를 소개시켜주셔서 처음으로 외주를 해봤다. 프론트엔드 개발인줄 알았지만 거의 HTML, CSS 위주의 퍼블리싱 일만 해서 좀 힘들었다. 그래도 오랜만에 회사 다니는 느낌이 나서 좋았다. 직원분들이 다 너무 잘해주셔서 즐겁게 일했다.

👨‍💻 코딩테스트, 면접 경험

국내 IT 대기업인 네카라(네이버, 카카오, 라인)에 한 번 쯤은 가보고 싶어서 3학년인 지금 여러 인턴십을 지원해봤다.

2019 카카오 개발자 겨울 인턴십

코딩테스트

코딩테스트를 위해 9월부터 꾸준히 백준 온라인 저지 문제를 풀었다. 카카오 코딩테스트 열흘 전부터는 항상 도서관이나 카페에 가서 카카오 코딩테스트 기출 등 위주로 풀면서 코테를 준비했다. 대부분 고급 알고리즘보다는 시뮬레이션 유형이 많아서 가능성 있을거라 생각했다. 온라인 코테 당일날 카페에 미리 가서 몇문제를 풀면서 머리를 풀었다. 워밍업을 한 덕분에 5문제 중 1,2번은 빠른 시간 내에 풀 수 있었다. 그리고 3번은 히든케이스 하나가 말썽이었다. 4,5번은 효율성 문제였는데 5번은 의외로 솔루션이 번뜩 떠올라서 자바스크립트로 구현했는데 (본인은 코딩테스트에서 주로 자바스크립트를 이용한다.) 정확성만 통과하길래 C언어로 문법을 바꿨더니 효율성까지 통과했다. 역시 4번은 정확성만 통과되었고 효율성은 어려워서 못풀었다. PS 고인물들은 무난하게 5문제 모두 풀 수 있는 난이도였던것 같았다. 내 결과는 5문제 중 3문제 완료였는데 운좋게 커트라인에 걸쳤는지 서류 및 코딩테스트 합격 메일이 왔다. 이런 합격 메일은 거의 처음 받아본거라 기분이 좋았다.

기술면접

기술면접 준비는 역시 다른 지원자들도 많이 보는 Front End Interview Handbook, Technical Interview Guidelines for beginners 등의 레포지토리를 위주로 준비를 많이 했다. 또한, 지금까지 한 프로젝트나 회사에서 한 일들을 위주로 예상질문들에 대한 답변들을 준비했다. 인터넷 세계에 퍼질 글이라서 정확한 세부 내용은 공개하기가 그렇지만 프론트엔드로 지원해서 주로 자바스크립트 위주의 질문이 주를 이루었다. 많은 질문들이 예상한대로 나와서 대부분 잘 대답했다고 느꼈다. 하지만 역시 카카오의 문턱은 높았다. 결과: 불합격.

2019 네이버 동계 인턴십

기술면접

위에서 말한대로 핵데이 우수참가자로 선정되어 서류는 면제되고 바로 기술면접을 봤다. 시험기간이라 많은 준비는 못했다. 또한, 포지션이 명시되어 있지 않아서 어떤 질문이 올지 감이 안왔었다. 예상대로 질문은 정말 다양했다. 기초 CS 지식부터 백엔드, DB, 프론트엔드, 기술 외의 culture fit 질문 등 1시간 30분동안 탈탈 털렸다. 면접을 너무 못 본 느낌이라 큰 기대하지 않았는데 어떤 내 장점을 발견하셨는지 ㅠㅠ 운 좋게 합격했다. 감사합니당 :)

2019 네이버 동계 인턴십 합격 메일

카카오 계열사 인턴십

코딩테스트

출범한지 얼마 안된 카카오 계열사다. 수시채용 인턴십 공고가 뜬 것을 본 후 바로 지원했다. 지원한지 2일 이내에 서류 통과되고 그 다음날 코딩테스트 일정이 잡혔다. 수시채용이라 해커랭크로 혼자 편한 시간에 보면 되는 방식이었다. 시험기간이었지만 빨리 결과를 보고 싶어서 코딩테스트를 응시했다. 역시 해커랭크 코딩테스트라 그런지 들은대로 난이도는 무척 낮았다. 3시간반동안 3문제 푸는것이었는데 1시간만에 풀었고 1시간동안 리팩토링했다. (세 문제 모두 자바스크립트로 풀었다.)

화상 기술면접

채용프로세스가 무척 빠르게 진행되었다. 코딩테스트 합격 결과는 영업일 5일 이내에 도착했고 1~2일 후 전화로 화상 면접 일정을 잡았다. 화상 면접은 처음이었는데 나름 재밌었다. 바디랭귀지는 거의 없이 음성으로만 소통하다보니 더 집중력이 많이 필요했다. 그래도 지금까지 본 기술면접 중에는 제일 잘 본 느낌이었다. 집에서 화상면접을 진행해서 덜 긴장한 탓도 있는 것 같다. 주로 자바스크립트, 리액트, 그 외 경험에 관한 질문들이었다. 그 후 프로세스는 현장면접이다. 아직 화상 기술면접 결과를 기다리고 있다.

기술면접 후 느낀점

역시 면접은 많이 경험해보는 것이 승률을 높이는 것에 큰 도움을 주는 걸 느꼈다. 면접을 하면 할수록 면접 스킬이 상승하고 있다는 것을 느꼈고 어떤 방향으로 기술 면접을 준비해야할지 감이 잡혔다.

🏃 PT 후 몸무게 증가, 체력 상승

9월에 2년만에 다시 운동을 시작했다. 근래에 체력이 많이 떨어졌다는 것을 느꼈기 때문이다. 마침 학교 앞 PT 스튜디오에 12년지기 친구가 트레이너로 일하고 있어서 딱 좋았다. 지인 DC를 받고 학교 다니는 3개월동안 PT와 식단관리를 받았다. 벤치프레스, 스쿼트, 데드리프트, 랫풀다운, 숄더프레스, 브이싯업 등 다양한 운동을 올바른 자세로 배울 수 있는 점이 좋았다. ~~무지 비싸지만.~~ 그리고 혼자라면 절대 못할 양의 운동을 억지로라도 하니까 매우 고통스럽고 힘들었지만 하고 나면 기분이 좋았다. 그렇게 근력 운동과 런닝 머신 운동을 통해 체력이 좋아진 것을 체감했고 하루 4~5끼 식단을 통해 3개월동안 6~7kg 정도 찌울 수 있었다.

✈️ 여행

회사에서 돈도 벌었겠다. 모은 돈으로 시간 날 때마다 해외 여행을 다니고 있다. 한살이라도 젊을 때 많이 가야 나중에 후회하지 않을 것 같다.

🇻🇳 1월 베트남 다낭 (10일)

설날 껴서 휴가 3일 내고 다녀왔다. 곧 군대가는 친구랑 5일 지내고 혼자 5일 지냈다. 혼자 5일 지내는 동안 카페에서 다른 스위스인 디지털노마드 형님을 알게 되어서 좋았다. 역시 겨울에는 동남아시아가 최고다. ~~서울은 너무 추워;~~

다낭 용다리

🇭🇺 8월 헝가리 부다페스트 한달살기 (28일) (+ 🇸🇰, 🇦🇹)

7월 31일에 퇴사하고 항상 내가 노래 부르던 한달살기를 드디어 실천했다. 부다페스트로 선택한 이유는 여름이라서 동남아시아는 무조건 싫었고 nomadlist에서 부다페스트가 꽤 상위 랭크에 있었기 때문이다. 역시 동유럽이라서 물가도 괜찮은 편이었고 도시 자체도 무척 예쁘고 이국적이어서 좋은 선택이었다. 한달살기 초반에는 인터넷 속도도 느리고 버스 타는 것도 적응이 안되고 힘들어서 한국으로 돌아가고 싶었지만 적응할수록 떠나는게 아쉬웠다. 도시 자체가 작아서 금방 길이 익숙해지고 마음에 들었다. 트램도 멋졌고 강도 아름답고 밤에 야경 보는 것도 무척 좋았다. 중간에 2박 3일로 슬로바키아, 오스트리아도 잠깐 다녀왔는데 특별한 경험이었다. 주 3~4일은 여행하고 3~4일은 카페에 가서 군돌이 작업 등 개발을 했다. (카페는 California Coffee Company었고 일하기 좋은 카페로 추천!) 제일 궁금할 부분인 비용은 항공, 숙박, 슬로바키아, 오스트리아 간 것까지 다 포함해서 총 250만원 정도 지출했다. 요리를 해먹거나 항공권 등을 충분히 더 싸게 구하면 더 줄일 수 있을 것 같다.

부다페스트 국회의사당

🇹🇭 12월 태국 치앙마이 (10일) - 진행중

현재 나는 어제(크리스마스 이브) 태국 치앙마이에 도착했다. 원래 지원한 인턴십이 다 떨어지면 1월에 치앙마이 한달살기, 2월에 발리 한달살기를 하려고 했는데 생각지도 않게 네이버에서 불러주셔서 첫출근 전까지 크리스마스와 새해는 치앙마이에서 보내기로 했다. 새해 카운트다운을 외국에서 하는 것이 내 버킷리스트이기도 했다. 아직 태국이란 나라에 적응중이라 힘들지만 많이 힘들어야 좋은 추억이 되는 것 같다. ~~하하 :)~~

현재 치앙마이 카페 글 마무리 순간; 쓰는데 5시간 걸렸다 으아

🥝 2019년을 보내며

요약

1년 8개월 회사 다니고 퇴사함
3학년 복학함
군돌이 여러 기능 추가했고 다운로드 수 많이 늘어남
교내 소프트웨어 공모전 학장상 수상함
네이버 핵데이 참여함
기술면접 세번 봄
5개국 다녀왔고 한 도시에서 한달 정도 지내봄

올해 별로 한 것 없이 지나갔다고 느꼈는데 막상 적어보니 뭔가 많다. 학교 공부하고 ~~별로 하지도 않았지만~~ 군돌이 이런저런 기능 추가하고 이것저것 뭐든지 하느라 막상 내가 공부하고 싶은 기술에 대한 깊은 공부를 하는 시간이 좀 부족했던 것 같다. 내년에는 내가 정한 방향인 프론트엔드 기술을 더 깊게 공부하고 싶고 그걸 바탕으로 더 재밌는 토이 프로젝트들 많이 하고 싶다. 🥝

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

🗓 이제야 쓰는 2018년 회고

갑자기 2018년 회고를 쓰고 싶어서 씁니다. 지금 안쓰면 2018년을 기억할 수 없을 것 같아서. 기억에서 버리기엔 너무 소중한 시간들이었습니다.

🎡 첫 회사에서 첫 개발자 생활

회사에 들어간 계기

대학교를 졸업하기 전에 회사에 다니는 많은 멋있는 개발자 친구들을 보면서 나도 회사에 다녀보면서 직접 개발을 하고 많은 것들을 경험하고 배워보고 싶었다. 내 장점은 추진력이었다. GOP에 근무할 때 사지방(사이버지식정보방)에서 로켓펀치를 훑어보면서 갈만한 회사가 없나 살펴보고 많이 뽑는 개발자 포지션과 자격 요건 등을 연구했다. 핫하게 뜨고 있는 React가 가장 눈에 띄었고 React 관련 자료들을 찾아 인쇄해서 공부했다. 그리고 틈틈이 휴가 나와서 실습을 해보면서 React 관련 기술을 익혔다. 그 후, 예전에 만들어놓았던 개인 프로젝트들을 긁어모아서 보잘것없는 포트폴리오를 만들어서 수십 군데의 스타트업에 직접 이메일을 돌렸다. 수십 군데 중 네 군데에서 면접 연락이 와서 말년 휴가때, 월화수목 4일 빡빡하게 면접 일정을 잡았다. 그 중 현재 다니고 있는 회사, 핀다가 가장 배울 점이 많아 보였고 체계가 잡혀보였다. 그래서 2017년 11월에 육군 병장으로 만기 전역한 후, 현재 다니고 있는 회사에 소프트웨어 엔지니어로 합류하게 되었다.

React 프론트엔드 그리고 안드로이드

처음에는 웹 프론트엔드 개발 (React, TypeScript) 포지션으로 일을 시작했다. 아무래도 개발자로써의 첫 직장생활이다보니 Git으로 협업하는 것도 익숙하지 않았고 이렇게 매일매일 풀타임으로 코딩을 하는 경험은 많이 없어 회사의 레거시 코드들을 보면서 구조와 내용들을 파악하는 것이 무척 어려웠다. 하지만 CTO님과 같은 개발자 선배님 동료분들이 많은 도움을 주셨고 코드를 계속 보게 되니까 많이 익숙해졌다. 그렇게 1~2개월 웹 프론트엔드 관련 이슈들을 처리하면서 업무에 적응하고 있었다. ~~많은 스타트업이 그렇듯이 리소스 부족의 문제로~~ 회사에서 개발하고 있던 안드로이드 애플리케이션 막바지 개발 작업을 하게 되었다. 웹뷰 기반의 앱이어서 네이티브 소스코드는 그렇게 많지는 않았지만 새로운 프로젝트에 다시 적응해야하니 당황했었다. 하지만 자바로 안드로이드 개인 프로젝트를 한 경험도 있었고 나는 초짜개발자였기 때문에 최대한 많은 분야의 업무들을 넓게 해보고 싶었다. 그래서 즐거운 마음으로 안드로이드 앱 프로젝트 이슈들을 재밌게 처리했고 직접 구글 플레이에 베타버전을 출시하는 갚진 경험을 하게 되었다.

Node.js 백엔드

안드로이드 앱을 출시하고 나서는 웹 프론트엔드 이슈를 주로 처리하면서 백엔드단인 node.js(express)도 맡겨주셔서 간간히 처리했다. 2018년 4월 정도 회사생활이 많이 적응했을 때 쯤 또 하나의 새로운 프로젝트를 하게 되었다. 대형 포털과 제휴를 맺게 되어 관련해서 검색 키워드를 처리하는 API 개발 부분을 맡겨주셨다. 이것저것 많이 넓게 하는 느낌은 있었지만 많은 경험을 해보고 싶었기 때문에 좋은 기회라고 생각해서 열심히 했다. 해당 프로젝트를 하면서 요구사항이 점점 복잡해지고 검색 키워드가 점점 많아지면서 머리는 아팠지만 런칭하고 난 후, 내가 개발한 API가 대형 포털에서 돌아가는 것을 보고 보람을 많이 느꼈다.

iOS 스위프트까지

안드로이드 앱을 출시했으니 iOS 앱도 만들어야되지 않겠는가. 2018년 6월 즈음 합류한 시카고 대학원에 재학중인 개발자 형과 함께 iOS 앱을 백지에서 시작하게 되었다. 웹뷰 기반의 앱이고 기존 안드로이드 앱을 참고해서 개발하면 되어서 많이 어렵지는 않은 프로젝트였지만 iOS 플랫폼은 처음이었고 Swift 언어도 생소해서 막막했다. 하지만 열심히 스터디해가면서 영혼을 갈아넣어 2개월 정도 만에 출시했다.

다시 안드로이드

iOS 앱을 출시한 후, 백엔드 이슈를 처리하며 즐겁게 회사를 다니던 도중 또 하나의 프로젝트를 하게 된다. 안드로이드에서 차별화된 기능을 개발하기 위해 스크래핑 업체와 제휴해서 특정 데이터를 가져오는 것과 공인인증서, 보안키패드 관련 모듈을 연동하는 것이었다. 개인 프로젝트로는 쉽게 할 수 없는 것들이라 직접 이런 것들을 할 수 있었던 것에 대해서 정말 감사했다. 즐겁게 외부 업체와 미팅도 하고 관련 문서도 열심히 읽으면서 삽질을 했다. 현재는 오로지 백엔드 이슈만 담당하고 있지만 안드로이드 개발을 많이 할 수 있었던 것에 대해서 감사하게 생각하고 있다.

👑 개발자 컨퍼런스

회사가 코엑스 근처에 있어서 개발 관련 컨퍼런스들을 쉽게 참여할 수 있어서 좋았다. 4월에는 동료분들과 같이 AWS SUMMIT 2018에 참여해서 DevOps에 관련해서 궁금하거나 알고 싶었던 세션에 대해 자유롭게 참여했고 10월에는 네이버 개발자 컨퍼런스 DEVIEW에 참여해서 자바스크립트 관련 세션들을 들었다. 한국에 정말 멋있는 개발자분들이 많다는 것을 몸소 느낄 수 있었던 컨퍼런스였다. 동기부여와 자극도 충분히 되어서 컨퍼런스에 갈 기회가 있으면 자주 가고 싶다.

🦁 여러 사이드 프로젝트들

나는 코딩을 정말 좋아한다. 그래서 회사 업무로써의 개발 말고도 개인 프로젝트로 뭔가를 많이 했었다.

네뷸러스 DApp 개발

네뷸러스는 중국의 퍼블릭 블록체인이다. 2017년말, 2018년초에 블록체인(암호화폐) 열풍을 맞아서 블록체인에 한창 관심이 있을 때 쯤에 네뷸러스를 알게 되었다. 이더리움, EOS와 마찬가지로 DApp(탈중앙화 애플리케이션)을 개발할 수 있는 플랫폼 종류의 블록체인이다. 많은 플랫폼 블록체인 중에서 네뷸러스가 관심 있었던 것은 우선 로고가 이뻤고 자바스크립트, 타입스크립트를 사용해서 DApp을 개발할 수 있는 점이었다. 또한, Developer Incentive Program이라고 해서 네뷸러스로 DApp을 개발하기만 하면 상금을 준다는 것에 이끌렸다. (당시 금액으로는 100만원 이상이었다. 현재는 많이 떨어졌지만) 그래서 DIP 기간동안 Votestagram, Fortune Cookie, AddressBook 세 개의 DApp을 개발했다. DApp 개발을 계기로 3개월동안 네뷸러스 대사로 활동하면서 네뷸러스 깃헙에서 활동도 하고, 백서 검수 활동도 하는 등 뜻깊은 경험을 했다. 블록체인에 종사하는 좋은 사람들도 많이 알게된 것도 좋았다.

Inko 자바스크립트 오픈소스 라이브러리 개발

네이버나 구글 같은 검색엔진을 사용할 때, 한글로 쳐야할 검색어를 영어로 잘못 친 경험은 누구나 있을 것이다. 그리고 잘못 친 영타를 바로 한글로 잡아줬던 기억도 같이 있을 것이다. 바로 이 기능을 자바스크립트 오픈소스로 개발하고 싶었다. 자바스크립트로 영타를 한글로, 한타를 영어로 변환하는 함수 두 가지를 만들고 NPM에 inko라는 이름을 가지고 배포를 했다. (이름의 유래는 “english to korea” -> “inko” 이다.) 내 첫 오픈소스 프로젝트이기도 하고 다른 분들도 풀리퀘스트를 통해 프로젝트에 참여해주시고 그래서 나에게 정말 의미있는 프로젝트가 되었다.

React Native 군돌이 앱 개발

이전 포스트글에서 썼듯이 내가 개인프로젝트로 처음 출시한 앱이다. React Native로 빌드했고 많은 유저들이 사용하고 있어서 가장 신경을 많이 쓰고 있는 프로젝트이다. 앞으로도 계속 기능 추가, 관리를 이어갈 것이고 계속 잘되었으면 좋겠다.

🐙 1일 1커밋

2018년 4월 29일부터 1일 1커밋을 해오고 있다. (모두 다 채운건 아니지만 거의 다 채웠다.) 이제 습관적으로 뭐라도 깃헙에 커밋하고 있다. 오픈소스 프로젝트에 이슈나 풀리퀘스트를 하거나 BOJ 풀이, 사소한 개인 프로젝트 등을 주로 커밋하고 있다.

😶 한 해동안 느낀 점

지난 1년동안 개발자로써의 첫 회사 생활을 통해 정말 많은 것들을 하면서 Jira나 Confluence 같은 협업 툴이라던지 MVC 패턴이라던지 주변 동료분들에게 학교에서 배울 수 없는 것들을 배웠다. 그리고 이벤트 트래킹, 퍼널, 리텐션 등 스타트업에서 데이터 분석은 어떻게 하는지에 대해서도 알 수 있었다. 만약 학교에 3학년으로 복학해서 공부만 했더라면 이만큼 성장하지 못했을것이다. 또한, 회사에 다니면서 주말 혹은 퇴근 후의 시간에 개인 프로젝트를 하면서도 회사에서 사용하지 않는 기술들을 스터디하고 직접 해보면서 실력을 성장시킬 수 있었고 결과물이 나오면 보람을 느낄 수 있었다. 2018년 참 알차게 보낸 것 같아 기분이 좋다.

🛫 앞으로 올해에는?

올해는 3학년으로 복학을 했고 1학기동안에는 회사와 병행을 하기로 했다. 원래는 학교만 열심히 다니려고 했지만 지금 다니고 있는 회사에 좋은 사람들과 계속 일하고 싶어서 그만두기가 뭔가 아쉬웠다. 그래서 1학기만 더 일하고 나머지 학기에 더 학업에 열중하려고 한다. 올해 목표는 자바스크립트를 깊이 파는 것이다. 지난 1년동안 여러 포지션의 업무를 해보면서 모바일 네이티브보다는 자바스크립트가 더 나에게 맞는 것을 느꼈다. 그래서 JS를 더 파보려고 한다. 또 React Native 앱을 여러가지 만들고 싶고 군돌이도 계속 유지/보수, 기능 추가할 것이다. 결론, 학점도 잘받고 싶고 개인 프로젝트도 많이 하고 싶고 다 잘하고 싶다. 올해도 열심히 살아야지. 🥝

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

📘 [번역] NPM의 중첩된 종속성

이번 포스트는 NPM(Node Package Manager)이 다른 언어의 패키지 매니저와는 다른 특징인 Nested Dependencies에 대해 다루는 글을 번역한 글입니다. 원문: Nested Dependencies입니다. (첫번역글이라 오역이 있을 수 있습니다.)

✌ 중첩된 종속성과 평평한 종속성 (Nested Dependencies and Flat Dependencies)

오늘날 많은 패키지 매니저들이 있지만, 기본적으로 중첩된 종속성(Nested Dependencies)으로 작동하도록 설계된 패키지 매니저는 npm 밖에 없다. (적어도 내가 알기에는)

위 다이어그램에서 deps 컨테이너들은 종속성의 격리된 집합을 나타낸다. 대부분의 패키지 매니저들은 모든 종속성에 대해서 하나의 ‘네임스페이스’를 갖는다. 나는 이 상태를 ‘flat(평평한)’ 이라고 부른다. 왜냐하면 종속성을 풀 때 오직 한 단계의 검색 용이성을 가진다는 것을 의미하기 때문이다. 그것은 앱 전체에서 ‘foo’ 라는 이름을 가진 종속성이 하나만 있다는 것을 의미한다.

🥙 평평한 종속성 (Flat Dependencies)

평평한 종속성 시스템에서 종속성을 푸는 작업이 어떻게 일어나는지에 대해 알아보기 위해 예제를 살펴보도록 하자.

이 예제에는 세 개의 종속성이 있다. 검정색 선들은 ‘의존’ 관계를 의미한다. 즉, 우리 앱은 a, b, 그리고 c를 의존하고 있고, c는 a를 의존하고 있다. 우리 앱과 c는 모두 a를 의존하고 있다.

종속성이 평평하기 때문에 (우리 앱 전체에 오직 하나의 복사본만 가지고 있다는 것을 의미함) 우리 앱과 c가 모두 a의 호환되는 버전에 의존하도록 해야한다는 것을 의미한다. 만약 우리가 c를 새로운 버전으로 업그레이드하고 싶다면, 그러나 새 버전이 우리 앱과 의존하고 있는 a와 호환되지 않는 버전의 a로 업그레이드한다면, 종속성 충돌이 발생한다. 이 현상은 “DLL 지옥” (Windows) 또는 더 일반적으로 “종속성 지옥” 이라고 한다.

🐦 중첩된 종속성 (Nested Dependencies)

이번에는 중첩된 종속성 시스템의 같은 예제를 살펴보자.

여기서는 한 단계의 종속성이 아니라 여러 단계의 종속성을 가지고 있다. a와 b가 종속성을 가지고 있지 않다고 가정하자. 우리 앱과 c는 모두 여전히 a에 의존하고 있다.

중첩된 종속성에서는 a의 두 복사본을 가지고 있다. 우리 앱이 a의 버전 1이 필요하고 c가 a의 버전 2가 필요하다면 a의 두 버전을 모두 설치한다. c의 종속성들이 c에게만 이용 가능하고, 어떤 것도 그것들에 접근할 수 없다. 추가적으로, 우리 앱과 c가 모두 a와 호환되는 버전에 의존한다는 것이 드러난다면, c's deps 폴더를 생성할 필요가 없다. 이 경우에는 평평한 종속성처럼 보일 것이다. (이것이 npm dedupe가 동작하는 방법이다.)

🔖 장점과 단점

평평한 종속성 (Flat Dependencies)

두 가지 설계 중 더 단순하다. 얼마나 복잡한지를 결정하는 것은 사용자에게 달려있다.
종속성 충돌이 일어날 수 있다. (a.k.a 종속성 지옥)
종속성을 독립적으로 불러올 수 없는 언어의 유일한 옵션이다.

중첩된 종속성 (Nested Dependencies)

종속성 충돌이 일어나지 않는다.
작고 고립된 모듈의 사용을 권장한다.
더 복잡하다.
서로의 종속성을 격리하기 위해 1급 객체 범위 지정을 지원하는 자바스크립트 같은 언어에 좋다.
필요하다면 종속성의 여러 복사본을 설치한다. 즉, 더 많은 디스크 공간을 차지한다. (실제로 코드가 작기 때문에 거의 문제가 되지 않는다.)
모듈형으로 설계되지 않은 종속성을 사용하는 사용자를 혼란스럽게 한다. (예: ‘왜 내 앱에 jQuery 5개 버전이 있지?‘)

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

🥝 React Native 사이드프로젝트. 보름만에 iOS, 안드로이드 앱 출시하기

전역일계산기 앱 군돌이

2018년 9월 3일에 전역일계산기 앱 군돌이를 구글 플레이스토어에 처음으로 런칭하고, 그로부터 6일 후인 9월 9일에 추가로 애플 앱스토어에 런칭했다. 런칭한 이후로 어떤 블로그 플랫폼이던 React Native로 앱을 개발하고 안드로이드와 iOS 플랫폼에 모두 런칭했던 이야기를 공유하고 싶었다. (~~별거 아닌 앱이지만…~~) 하지만 귀차니즘으로 작성하지 못했다. 그래서 군돌이 앱의 만 명 설치를 핑계로 React Native로 하이브리드 모바일 애플리케이션을 개발한 후기를 작성해보려한다.

💫 시작

우선, 내가 개발한 앱을 소개하겠다. 간단히 전역일을 계산할 수 있는 애플리케이션이다. 다른 앱과의 차별점을 둔 것은 예쁘고 심플한 디자인과 사용성이다. 현역 생활 때 사용한 타 앱은 많은 유저들이 사용하는 것에 반해 사용성이 많이 부족하다고 느꼈다. 그래서 직접 전역일계산기 앱을 개발해서 현역 군인들과 고무신분들, 부모님들이 더 예쁘고 심플한 디자인의 전역일계산기를 사용하게 하고 싶었다. 물론 디자인은 똥손인 내가 하지 않았고 금손 디자이너 GOM님이 팀원으로써 도와주셨다. (감사합니다! 🥝)

런칭한지 대략 4개월이 지나지 않았는데 2019년 1월 25일 금요일 기준 안드로이드 3,400명 설치, iOS 6,600명이 설치하여 총 10,000명의 유저가 설치했고, 하루에 1,000명 ~ 1,300명 정도가 사용하는 전역일계산기 앱이 되었다. 구글 플레이스토어의 ASO가 더 좋음에도 불구하고 앱스토어의 설치량이 항상 더 좋은 것이 약간 놀라웠는데 아마 젊은 층의 여성분들이 아이폰을 많이 사용하기 때문이리라 짐작했다. 회사에 다니면서 사이드 프로젝트로 퇴근하고 저녁에 그리고 주말에 틈틈이 작업한 앱을 생각보다 많은 분들이 사용해주셔서 엄청 보람 있었다. 대략 앱을 만들고 처음 배포하기까지 보름 정도 걸렸는데 그 과정과 사용했던 라이브러리 등 그리고 RN으로 개발하면서 느꼈던 장점, 단점 정도를 써보겠다.

앱스토어 판매량

파이어베이스 애널리틱스 대쉬보드

⚛ 왜 React Native로 개발하였나

처음에는 패기에 가득차서 간단한 앱이니 swift로 iOS 앱을 개발하고, java나 kotlin으로 안드로이드 앱을 개발하면 되겠다싶어서 swift로 전역일계산기 앱을 구상하고 프로토타입을 개발해보았다. 간단할 줄 알았지만 date 계산 등 swift의 언어적 특징에 많이 익숙하지 않아 많은 난항을 겪었다. 그래서 자연스레 javascript를 사용하는 React Native에 눈을 돌리게 되었다. react와 javascript에는 웬만큼 자신이 있었고 한 번 개발해놓으면 iOS와 안드로이드, 두 플랫폼에서 작동하기 때문에 React Native는 내가 생각하기에 최고의 선택이었다.

react-native 공식 웹사이트를 참고해 공부하면서 개발했는데 웹 프론트엔드 개발하듯이 모바일 앱을 개발하는 개발 경험이 신세계였다. 게다가 expo를 사용하면 굳이 테스트 기기를 유선으로 연결하지 않고, expo 앱을 설치해서 QR코드로 인식하면 내가 개발하고 있는 앱을 실시간으로 확인해보며 개발할 수 있어서 네이티브를 직접 개발할 때와는 생산성과 편의성이 말도 안되게 차이가 났다. 이래서 RN RN 하는 구나 느꼈다. 그리고 모바일 앱의 반응형 디자인을 내가 가장 좋아하는 CSS의 flexbox를 사용해 처리하는 것 때문에 매력적이었다. 개발경험에 있어서 네이티브를 개발한다는 느낌보다는 웹뷰를 개발하는 느낌이지만 React Native는 네이티브 API를 사용하여 네이티브에서 직접 렌더링하기 때문에 네이티브와 유사한 성능, 사용성을 보여준다.

⚒ 개발환경 설정

처음에는 위에서 말했듯이 expo라는 React Native를 편하게 개발할 수 있도록 도와주는 서드파티 툴을 사용했다. 하지만 점점 더 많은 기능을 추가하면서 expo의 한계를 느꼈다. 일단 앱의 용량이 비정상적으로 컸고, 무엇보다 네이티브 모듈을 react-native link 할 수 없다는게 엄청난 단점이었다. 그래서 결국 expo eject 명령어를 통해 expo를 떼어냈다. 떼어내려면 힘들줄 알았는데 expo 관련 라이브러리를 쓰지 않아서 그런지 저 명령어를 통해 eject하고 빌드도 잘되었던 기억이 난다. 위 경험을 통해 처음부터 웬만하면 expo를 사용하지 않는 것이 좋다고 판단하여 다음 RN 프로젝트부터는 expo를 사용하지 않았다. 다른 분들에게도 그렇게 추천하고 있다.

또한, 추가적으로 정적 타이핑을 위해 typescript를 사용하였고, 더 편한 스타일링을 위해 styled-components를 사용하였다. 그리고 처음에는 상태관리 라이브러리로 redux를 사용했지만 mobx의 간편성에 반해서 중간에 mobx로 뜯어고치는 과정을 거쳐서 좀 빡셌다. 이러한 개발환경을 세팅할 때, 정말 오래 걸리고 매번 찾는게 번거로워서 react-native-awesome-starter라는 레포지토리를 생성해서 초기에 RN의 개발환경 세팅하는 방법들을 정리해놓았다.

💻 개발 과정

군돌이 초안(왼쪽)과 프로토타입(오른쪽)

사실 전역일계산기 앱에 기능이 많이 없어서 과정이랄게 있을까 싶긴 하지만 간단히 써보도록 하겠다. 우선 다른 앱들을 벤치마킹하고 어떤 내용들을 어떻게 표시하면 좋을지 생각을 해서 조잡하게 wireframe 삼아서 스케치로 대충 그려보았다. 바로 위의 왼쪽 사진이다. 현재의 디자인과 완전 다르다…! (감사합니다. 디자이너님, 저런 garbage를 심폐소생술시켜주셔서 ㅎㅎ) wireframe을 가지고 React Native로 앱 구조를 어떻게 구성할지 고민하고 프로토타입(오른쪽 사진)을 개발했다. 그 후, 디자이너님께 프로토타입을 드리고 바로 맨 위의 스크린샷과 같은 디자인을 주셨다. 컴포넌트 구조를 그래도 잘 해놓아서 디자인을 시안대로 그리는 것은 쉽게 했다. 그리고 편집 화면도 모달로 추가해서 기본적인 기능을 갖추었다.

기본적인 기능을 갖추었다고 생각한 후, 구글 플레이스토어와 앱스토어 개발자 계정을 구입해서 배포 준비를 했다. 개발자 계정이 비쌈에도 굳이 빨리 구입을 해서 추진했던 이유는 절박함을 만들지 않으면 프로젝트가 느슨해질 것 같았고 출시가 계속 더뎌질 것 같아서였다. 일단 내 목표는 기본 기능만 가진 예쁘고 심플한 전역일계산기 앱을 만들고 그 후에 버그도 고치고 기능도 추가할 계획이었다. 퇴근 후의 저녁과 주말을 반납하여 보름만에 뚝딱 개발을 마치고 플레이스토어와 앱스토어에 런칭했다. (애플은 심사가 오래 걸려서 6일 정도 후에 출시했다.)

앱스토어까지 출시한 후, 네이버 곰신 카페에 들어가서 군돌이 앱 홍보를 했다. 생각보다 반응이 뜨거웠다. 디자인이 예쁘고 심플하다며 좋아하시는 분들이 많아서 개발한 보람이 있었고 즐거웠다. 이 때, 버그가 많이 발견되었는데도 불구하고 많은 유저분들이 버그리포트도 해주시고 의견 제안도 많이 해주셔서 폭풍 수정하고 바로 배포하는 등 유저와 소통하고 열심히 하는 모습을 보여주려 애썼다. 첫 출시 이후, 예닐곱 번의 꾸준한 배포를 통해 버그 수정 및 기능 추가를 했고 그 결과로 만 명의 유저가 설치한 것을 보게 되어 감사하고 감회가 새롭다. 계속 재밌는 기능들을 많이 추가해서 군돌이 앱을 키워나가고 싶다. 🥝

과정은 여기까지로 하고 밑에서부터는 트러블 슈팅, 추천 라이브러리, 장단점 등을 공유해보도록 하겠다.

🌠 트러블 슈팅

React Native를 개발하면서 iOS는 x-code에서 직접 빌드하고, 안드로이드는 안드로이드 스튜디오에서 직접 빌드할 일이 많았다. 그리고 여러 네이티브 모듈을 사용하다보니 삽질할 일이 정말 많았다. 빌드 에러가 정말 많이 났다. 그래서 짧은 기간동안 RN으로 개발하면서 발생했던 에러들을 react-native-trouble-shooting 레포지토리에 정리해놓았다.

혹시 에러가 발생한다면 참고해주시면 좋을 것 같습니다. 레포지토리에 Trouble Shooting이라면 Pull Request 부탁드립니다.

최근에 가장 기억이 남는 트러블 슈팅 중에 하나는 iOS 위젯을 개발할 때였다. 유저분들의 위젯 기능 요청이 너무 많아서 큰 부담을 갖고 위젯 기능을 개발하고 있었는데 위젯 익스텐션에서 앱에 저장되어있는 데이터를 가져오는 부분이 정말 어려웠고, 몇 주째 삽질만 하고 있었다. iOS의 위젯을 개발하기 위해서는 당연히 iOS 개발 관련 지식도 필요했고, 계속 digging을 했다. 일단 RN에서 iOS의 위젯을 추가하려면 react-native-today-widget 라이브러리를 사용해야했고, 군돌이 앱의 메인과 today widget extension 간의 데이터를 공유하려면 iOS의 App Group이라는 개념을 사용해야 했다. 그래서 react-native-shared-group-preferences 라이브러리도 사용해야했다. 위젯 코드에서 SharedGroupPreferences를 import하고 getItem이라는 static 함수를 사용해야 했는데 getItem이라는 함수는 콘솔에 잘찍히는 것을 확인했지만 정작 사용할 때에는 SharedGroupPreferences가 undefined라는 에러가 나오는 상황이어서 진짜 포기하기 일보 직전이었다. 많은 것을 시도해보았고 많은 시간이 흘렀다. 지푸라기를 잡는 심정으로 해당 레포지토리의 이슈를 보았는데 내 상황과 비슷한 이슈가 있었다. 답변 중 하나가 link가 안되었을 것이라는 답변이었다. 하지만 나는 link가 잘되어있는 것을 확인해서 그 문제는 아닐 것이라고 생각한게 오산이었다. 앱 메인에는 해당 라이브러리가 link되어있었지만 today widget extension에는 이 라이브러리가 link가 안되어있었어서 SharedGroupPreferences를 사용할 수 없었던 것이다. today widget extension에 react-native-shared-group-preferences 라이브러리를 직접 link하니 정상적으로 작동했다! 다행히 문제에 대한 solution을 발견하고 다리 쭉 뻗고 잘 수 있었다. ☁ 내가 남긴 댓글

🙋 꼭 써야한다고 생각하는 라이브러리

react-native-code-push

Microsoft에서 만든 code push는 React Native를 사용하는 이유에도 포함되어있을 정도로 아주 강력한 기능이다. 네이티브 바이너리 파일의 업데이트 없이 간단한 명령어만으로 앱을 업데이트시킬 수 있는 기능이다. code push의 원리는 네이티브 파일에서 로컬이 아닌 code push 서버에 있는 자바스크립트 번들 파일을 바라보고 있다가 개발자가 code push 명령어를 통해 자바스크립트 번들 파일을 교체하면 앱이 업데이트된 것처럼 보이는 원리이다. 물론, 네이티브 모듈을 추가한 것은 코드 푸쉬로 적용이 안된다. 그 때에는 직접 업데이트를 해줘야한다. 하지만 계속 코드 푸쉬를 사용해서 업데이트하는 건 좋지 않다고 생각한다. 왜냐하면 바이너리를 얼마나 꾸준히 업데이트하는 지도 ASO에 영향이 미쳐지기 때문이다.

react-native-firebase

React Native에서 firebase를 사용할 수 있도록 도와주는 라이브러리이다. 내가 주로 사용한 부분은 analytics의 event이다. 유저가 특정 액션을 취했을 때, firebase에서 event를 tracking해서 유저가 어떤 플로우를 취하는지 볼 수 있고, funnel을 통해 어디서 bounce rate(이탈률)가 많이 발생하는지 볼 수 있는 등 제공하는 통계 기능이 많다. 위의 firebase 스크린샷은 analytics의 대쉬보드이다. 추가적으로 admob을 사용해 광고 배너를 달 수 있는데, react-native-firebase를 사용할 수도 있지만 더 편리하게 쓸 수 있게 제공해주는 react-native-admob을 사용했다. 또한 cloud messaging을 통해 푸쉬 알림을 보내는 기능을 해보고 싶었지만 한 번 삽질하다가 안되서 보류중이다. 어쨌든 analytics 기능만으로도 invertase 팀의 react-native-firebase 라이브러리는 React Native를 한다면 꼭 써야하는 라이브러리이다.

react-native-fast-image

react-native-fast-image 라이브러리는 React Native에서 기본적으로 제공하는 <Image /> 컴포넌트를 사용해도 되지만 react-native-fast-image의 <FastImage />를 사용하면 이름 그대로 더 빠르게 이미지를 렌더할 수 있다. 주기능으로는 이미지 캐쉬하기, authorization headers를 추가하기, 이미지 미리 로드하기, 이미지 우선순위 매기기 등이 있다. iOS의 이미지 로드 라이브러리인 SDWebImage와 Android의 이미지 로드 라이브러리인 glide를 플랫폼마다 직접 사용하여 성능을 높였다. 따라서 많은 이미지를 렌더할 일이 있다면, React Native에서 react-native-fast-image 라이브러리의 사용은 필수다.

⚽ 재밌는 라이브러리

react-native-egg

react-native-egg는 이스터에그를 심어놓기 위해 사용하는 라이브러리이다. 아직 사용은 안해봤지만 앱 안의 비밀스러운 제스쳐를 숨겨놓고 개발을 위한 테스트모드로 진입하게 하거나, 유저들이 우연히 발견한다면 재미 요소를 느낄만한 이스터에그를 숨겨놓을 수 있다. 군돌이 앱에도 나중에 이 라이브러리를 사용해서 이스터에그를 숨겨놓을 생각이다.

react-native-haptic

아이폰의 약한 진동인 햅틱을 구현해놓은 아주 좋은 React Native 라이브러리이다. 유저가 버튼을 누를 때, 피드백을 주는 데 햅틱만큼 좋은게 없다고 생각한다. 이 라이브러리를 사용하면 아주 손쉽게 React Native에서 햅틱 효과를 줄 수 있다. 대신 안드로이드는 지원하지 않기 때문에, Platform.OS로 분기 처리해주어야 한다.

💁 내가 생각하는 React Native의 장점

짧게나마 군돌이 앱을 React Native로 개발해보면서 많은 삽질이 있었지만 정말 좋은 개발 경험을 했다. 무엇보다도 자바스크립트로 네이티브 앱과 사용성, 성능이 거의 동일한 앱을 만들 수 있는 것은 정말 신세계였다. 게다가 iOS와 안드로이드 두 플랫폼에서 돌아가다니… React Native의 광팬이 된 것 같다. 내가 생각하는 React Native의 장점은 다음과 같다.

생산성이 엄청 높다.

Cake 앱의 이성민 개발자님이 Cake 앱을 안드로이드와 iOS 두 플랫폼의 앱을 혼자서 한 달만에 개발하고 출시하셨다고 한다. 만약에 안드로이드와 iOS 각각 개발을 했다면 인원과 시간 등 리소스가 더 필요했을 것인데 React Native였기에 가능했다. 한 가지 소스코드로 안드로이드와 iOS의 코드를 공유하게 되니 생산성도 높아지고 마찬가지로 유지보수 비용이 현저히 낮아진다. 또한, 안드로이드와 iOS는 코드를 고치고 확인할 때마다 빌드하면 꽤 오랜시간을 잡아먹는데에 반해 React Native는 live reload 기능을 통해서 코드를 고칠 때마다, 바로바로 수정사항을 확인할 수 있어서 엄청 편하고 빠르게 개발할 수 있다.

learning curve(학습 곡선)가 비교적 짧다.

Javascript, CSS 그리고 React가 익숙하다는 전제 하에 React Native의 learning curve는 말도 안되게 짧다. JS, React가 능숙하다면 React Native를 직접 개발하면서 모르는 것을 그때그때마다 찾아보며 능숙해지는 것도 좋은 방법인 것 같다. ~~많은 삽질이 필요하겠지만~~

라이브러리가 적지 않다. ~~필요하면 직접 만들면 된다~~

밑에서 한 번 더 언급하겠지만 awesome-react-native를 보면 필요한 라이브러리가 많이 만들어져 있어서 개발하는데 거의 문제가 없었다. 또한, 아주 방대한 npm 모듈들을 마음껏 설치해서 사용할 수 있는 점도 큰 장점 중 하나이다. 네이티브 관련 라이브러리가 안드로이드와 iOS 라이브러리보다야 훨씬 적겠지만 경쟁하고 있는 하이브리드 앱 프레임워크인 flutter보다는 라이브러리가 많다. 혹시 필요한 라이브러리가 없다면 직접 create-react-native-library를 통해 라이브러리를 개발할 수 있다. (물론 Android, iOS 플랫폼에서 돌아가도록 직접 코드를 작성해야해서 많은 어려움이 있지만 말이다.)

code push를 통한 빠른 배포

위에서 말했지만 code push는 React Native를 사용하는 큰 이유 중 하나이다. 며칠씩 걸리는 iOS 심사 및 배포를 생략하고 몇 초만에 배포할 수 있는 점은 아주 강력하다.

🙅 내가 생각하는 React Native의 단점

React Native의 팬이지만 아쉬운 점이 있다면 다음과 같다.

위젯이나 워치 익스텐션을 개발하기가 네이티브보다 까다롭다.

안드로이드 위젯은 react-native-android-widget-poc, iOS 위젯은 react-native-today-widget, 애플워치 앱은 react-native-watch-connectivity, 또한 앱 간의 데이터 공유는 react-native-shared-group-preferences 라이브러리를 사용하는 등 많은 라이브러리들이 오픈소스로 개발되고 있지만 아무래도 네이티브의 새로운 API들이 나오면 바로바로 지원되는 것은 어렵기 때문에 스마트워치 앱이나 위젯 같은 다른 확장 기능을 사용해야 한다면 React Native는 추천하지 않는다. React Native로 iOS 위젯을 개발하고 있지만 메모리 문제인지 가끔 “로드할 수 없음” 이라고 뜨는 문제가 있어서 살짝 불안정한 점이 보인다.

호환성 문제로 빌드가 안될 때가 있어 삽질 요소가 많다.

React Native 라이브러리를 많이 link시키다가 보면 라이브러리들이 꼬일 때가 있고, 시뮬레이터 기기에서 작동을 안하는 등 해결방법을 찾기 어려운 트러블이 발생하기 쉽다. 내가 아직 초보라서 못찾는 것일 수도 있긴 하지만, 불친절한 에러메세지도 많고 해서 안드로이드 혹은 iOS 빌드가 안될 때에는 많은 시간의 폭풍 구글링과 시행착오를 요한다. (이는 내공이 쌓이면 해결될 것 같다.)

한국어로 된 자료가 많이 부족하다.

React Native 관련 서적이 한국에 출판된 게 2~3권 밖에 보이지 않고, 한국의 React Native 커뮤니티가 작아서 그런지 한국어로 된 개발 자료를 많이 찾아볼 수 없었다.

🐘 도움이 되었던 라이브러리 혹은 자료

react-native 공식 홈페이지

React Native 공식 홈페이지는 RN으로 개발하면서 당연 제일 많이 들여다 본 홈페이지일 것이다. 어떤 컴포넌트, API를 제공하고 있는지 보는 재미가 있고, 필요한 컴포넌트의 예제와 명세가 상세히 적혀있어서 많이 참고해야할 사이트이다.

awesome-react-native

React Native에서 필요한 적재적소의 라이브러리를 나열해놓은 레포지토리다. RN으로 개발할 때 가장 많이 방문했던 레포지토리일 것이다.

React Native: 웹 개발자가 한 달 만에 앱 출시하기 (발표자료)

네이버 개발자 컨퍼런스인 deview 2018에서 cake 앱을 개발하신 snow의 이성민 개발자님이 발표해주신 React Native 발표자료이다. 현장에서 참석했는데 React Native가 이렇게 관심이 많은 기술인지 처음 알았다. 아마 세션의 이름으로 어그로가 많이 끌렸긴 하지만.. ㅎㅎ 진짜 서서 듣는 사람들까지 꽉찼을 정도로 인기 있는 세션이었다. 인기가 있는 만큼 강의 내용도 알찼다. 마침 군돌이를 한창 개발했을 때 쯤이어서 발표 내용이 쏙쏙 들어왔고, 몰랐던 React Native의 동작 원리와 여러가지 개발 팁, 노하우 등을 전수받을 수 있어서 좋았다. 발표 영상 제가 정리해놓은 자료

🚒 결론

React Native로 프로젝트를 진행하면서 많은 어려움이 있었지만 많은 삽질을 통해 새로운 기술을 익힐 수 있었다. 하지만 React Native는 개인 프로젝트나 프로토타입같이 빠르고 간단하게 만들 때에는 적합하지만 회사의 대형프로젝트에서 쓰기에는 부적합할 것 같다. 아직 React Native는 버전 업그레이드가 꾸준하고 빠르게 이루어지고 있고 그 말은 불안정하다는 말이니깐 말이다. 그래서 개인 프로젝트로 앱 만들 때에만 React Native를 주로 사용할 것이다. ~~React Native를 사용하는 회사가 거의 없긴 하다.~~ 이로써 React Native 첫 개발기를 마치도록 하겠다.

왠지 군돌이 앱 개발기를 쓰다가 React Native 찬양글로 바뀐 것 같은 느낌적인 느낌이 들지만… 초보 블로거라 글이 생각보다 두서가 없고 길어지기만 해서 죄송합니다 😅 부족한 글 봐주셔서 감사합니다 🥝

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

🏊 React의 JSX 파고들기

😻 JSX가 대체 뭐지

const element = <div>Hello world</div>;

React를 처음 접할 때, 보통의 자바스크립트와는 다른 문법을 볼 수 있다. 위 코드를 보면 변수에 <div>Hello world</div>를 할당하고 있는데 이는 문자열도 아니고, HTML도 아니다. 바로 JSX다.

JSX는 JS + XML의 줄임말로써 자바스크립트 안에서 <div>hello world</div> 와 같이 HTML 같이 생긴 XML 문법을 사용할 수 있는 자바스크립트에서 확장된 파일형식이다. 나는 React의 JSX를 처음 보고 정말 참신하다고 생각했다. UI에 해당하는 HTML과 로직에 해당하는 Javascript를 나누지 않고 JSX라는 파일형식을 창조하여 컴포넌트 단위로 UI와 로직을 한 파일에 합쳤기 때문이다.

물론 React에서 JSX를 사용하지 않을 수 있다. 하지만, Javascript 코드 안에서 UI가 동작하는 것을 시각적으로 바로 볼 수 있기 때문에 많은 사람들이 사용한다.

다음은 React에서 JSX의 예제이다.

class AwesomeComponent extends React.Component {
    render() {
        return (
            <MyButton color="blue" shadowSize={2}>
                Click Me
            </MyButton>
        );
    }
}

위 JSX 코드는 아래와 같이 컴파일된다.

class AwesomeComponent extends React.Component {
    render() {
        return React.createElement(
            MyButton,
            { color: "blue", shadowSize: 2 },
            "Click Me"
        );
    }
}

온라인 바벨 컴파일러에서 위 내용을 확인할 수 있다.

🍎 JSX를 사용할 때 주의할 점들

JSX를 사용하려면 React가 Scope 안에 있어야 한다.

XML 형식의 코드는 React.createElement 함수를 호출하는 코드로 컴파일되기 때문에 React를 직접 쓰지 않더라도 React를 임포트해주어야 한다.

import React from 'react';
import AwesomeButton from './AwesomeButton';

function BlueButton() {
  // return React.createElement(AwesomeButton, {color: 'blue'}, null);
  return <AwesomeButton color="blue" />;
}

최상위 부모 DOM은 하나여야 한다.

React.createElement 함수의 인자는 React.createElement(component, props, ...children)와 같다. 첫번째 인자에 component가 오고, 두번째에는 Object 형식의 props가 오고 세번째 인자는 가변인수로 children들이 온다. 여기서 중요하게 봐야할 점은 최상위 부모 DOM이다. 최상위에서 제일 처음 호출되는 React.createElement는 단 하나만이 호출되기 때문에 최상위 부모 DOM은 오로지 하나여야 한다.

// 나쁜 예: 최상위 부모 DOM이 두 개이다. 컴파일할 수 없다.
function BadComponent() {
    return (
        <div>hello</div>
        <div>world</div>
    );
}

// 좋은 예: 최상위 부모 DOM이 한 개이다.
function GoodComponent() {
    return (
        <div>
            <div>hello</div>
            <div>world</div>
        </div>
    );
}

// 위 GoodComponent.jsx를 컴파일한 GoodComponent.js
function GoodComponent() {
    return React.createElement(
        "div",
        null,
        React.createElement(
            "div",
            null,
            "hello"
        ),
        React.createElement(
            "div",
            null,
            "world"
        )
    );
}

직접 정의한 컴포넌트는 대문자로 시작해야 한다.

React는 소문자로 시작하는 컴포넌트를 HTML tag로 인지하기 때문에 대문자로 시작하는 네이밍을 사용해야 한다. 이는 보통 클래스는 대문자로 시작하는게 관습이므로 신경쓰지는 않아도 될듯 싶다.

props를 사용할 때 스프레드 연산자를 사용할 수 있다.

props를 Object type으로 정의하여 <Greeting {...props} />와 같이 사용할 수 있다. 부모 컴포넌트의 props를 자식 컴포넌트에서 그대로 자식 컴포넌트에게 물려줄 때 유용하게 사용할 수 있다.

function App1() {
  return <Greeting firstName="Ben" lastName="Hector" />;
}

function App2() {
  const props = {firstName: 'Ben', lastName: 'Hector'};
  return <Greeting {...props} />;
}

Children에 Javascript의 표현식을 사용할 수 있다.

배열에 있는 아이템을 차례대로 <li></li>로 보여주고 싶을 때 Javascript의 map을 사용하면 쉽게 처리할 수 있다.

function TodoList() {
  const todoItems = ['You don\'t know JS 책 읽기', '깃헙 커밋하기', '블로그 포스팅하기'];
  return (
    <ul>
      {todoItems.map((item, index) => <li key={index}>{item}</li>)}
    </ul>
  );
}

boolean, undefined, null은 렌더되지 않는다.

true, false undefined, null은 렌더되지 않기 때문에 이 특징을 사용하여 아래와 같이 쓸 수 있다.

// 좋은 예
<div>
  {showHeader && <Header />}
  <Content />
</div>

/* NOPE. 하지만 아래와 같이 사용하게 되면 props.messages.length이 0일 때
falsy한 값으로 뒤의 값들이 나오지 않겠지만 0이 렌더되기 때문에 옳은 방법은 아니다. */
<div>
  {props.messages.length &&
    <MessageList messages={props.messages} />
  }
</div>

// OK. 이와 같이 바꿔주어야 한다.
<div>
  {props.messages.length > 0 &&
    <MessageList messages={props.messages} />
  }
</div>

React 코드 살펴보기

React 16.4.0 버전의 코드를 살펴보겠다. ReactElement.js 파일에서 createElement를 정의하는 코드이다.

export function createElement(type, config, children) {

  // ... 중략

  return ReactElement(
    type,
    key,
    ref,
    self,
    source,
    ReactCurrentOwner.current,
    props,
  );
}

React.createElement 함수는 ReactElement라는 자료형으로 반환하는 것을 볼 수 있다.

const ReactElement = function(type, key, ref, self, source, owner, props) {
  const element = {
    // This tag allows us to uniquely identify this as a React Element
    $$typeof: REACT_ELEMENT_TYPE,

    // Built-in properties that belong on the element
    type: type,
    key: key,
    ref: ref,
    props: props,

    // Record the component responsible for creating this element.
    _owner: owner,
  };

  // ... 중략

  return element;
};

위 코드를 통해 ReactElement 자료형은 $$typeof, type, key, ref, props, _owner를 갖는 Object인 것을 확인할 수 있다.

class AwesomeComponent extends React.Component {
    render() {
        return React.createElement(
            MyButton,
            { color: "blue", shadowSize: 2 },
            "Click Me"
        );
    }
}

따라서 위에서 JSX가 컴파일된 코드는 아래와 같이 다시 ReactElement로 반환될 것이다.

class AwesomeComponent extends React.Component {
    render() {
        return {
            type: MyButton,
            props: {
                color: 'blue',
                shadowSize: 2,
                children: 'Click Me'
            }
        }
    }
}

👱🏻 JSX는 미쳤다.

React에서 가장 중요한 개념인 Component는 UI를 구성하는 개별적인 뷰 단위이다. React로 개발한다는 것은 블록을 조합해 집을 짓는 것과 같다. React 앱은 Component들의 결합으로 만들어지는 것이다. 여기서 주의 깊게 봐야할 부분은 Component가 재사용이 가능하다는 점이다. 재사용이 가능한 React의 Component는 생산성을 극대화시켜주었다. Component를 효율적으로 만들기 위해 React는 JSX라는 특이한 Syntax를 만들어냈고 그 결과는 탁월했다. Javascript 코드 안에 태그를 넣어 사용한다는 생각은 정말로 발상의 전환이었다. 정말 미친 것 같다.

추가적으로 React의 또 하나의 가장 중요한 특징인 Virtual DOM을 빼놓을 수 없겠다. 아마 다음 포스트 주제가 될 것 같다. 🥝

참고

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

🚀 개발자에게 블로그는 선택이 아닌, 필수인가?

🔥 블로그의 시작

2019년을 맞이해서 평소에 내가 개발자의 덕목이라고 생각하는 블로그를 쓰려고 한다. 2019년 1월 1일부터 생각했지만, 블로그 시작하기가 여간 어려운 것이 아니었다. 이미, 티스토리(내 시험용 티스토리 블로그)로 시작해보려고 시도해보았지만 react-native 개발할 때 모아놓은 trouble shooting 포스트만 잔뜩 써놓고 그만두었다. 처음에 티스토리로 시작하려는 이유는 다음과 같았다.

티스토리의 장점

내가 통계 시스템을 신경쓰지 않아도 티스토리에서 알아서 해줘서 편하다.

개인이 직접 호스팅하는 블로그에서는 Google Analytics와 같은 통계 서비스를 이용해주어야 하지만, 티스토리나 네이버 블로그 같은 경우엔 통계 시스템이 아주 잘되어있다.

SEO 최적화를 개인이 호스팅하는 블로그보다 신경쓰지 않아도 된다.

SEO란, 검색엔진 최적화인데 티스토리가 일단 다음 회사 소유이기 때문에 다음의 검색엔진에 가장 최적화가 잘되어있고, 구글에도 개발 관련 글을 치면 티스토리 블로그가 많이 나온다는 것을 확인할 수 있다.

광고 붙이기가 쉽다.

애드센스 플러그인 등을 제공해서 글에 쉽게 삽입할 수 있다.

위 세 가지 장점을 가지고 시작했는데, 몇 가지 단점들 때문에 오래 가지 못할 것 같았다.

티스토리의 단점

편집기에서 마크다운을 지원하지 않는다.

티스토리에서는 아직까지 공식적으로 Markdown 편집 방식을 지원하지 않는다. 개발자에겐 마크다운이 편한데 지원하지 않는다는 것은 아주 큰 불편함이 될 수 있다.

템플릿이 너무 정형화되어있고, 덜 개성적이다.

티스토리에도 이쁜 스킨(디자인)들이 많겠지만 내 스타일이 아니고(~~주관적인 의견~~) 커스터마이징하는 것에 한계가 있어서 덜 개성적이라고 생각한다.

🕶 개츠비의 발견

몇개월 전에 React 개발자인 Dan Abramov가 블로그 Overreacted를 보고 디자인이 깔끔해서 무척 마음에 들었었는데 그게 gatsby-starter-blog였다. 그래서 Gatsbyjs에 관심 가지게 되었다. 예전에도 블로그를 시작하려고 알아본 정적 페이지 제너레이터 삼대장인 지킬, 헥소, 휴고를 알고 있었지만 개츠비는 처음 들어봤었다. 위 세가지 것들과 다르게 프론트엔드 템플릿에 react를 사용한다는 점이 마음에 들었다. 그래서 바로 개츠비 공식 웹사이트에 가서 세팅하는 문서를 차근차근 보고 따라해봐서 나온 결과물이 바로 이 곳이다. 개츠비를 더 열심히 파본 다음에, 개츠비 관련 포스트도 작성해봐야겠다.

🎆 2019년에는 블로거

어떤 책에서 개발자는 무조건 블로그를 해야한다는 글을 본 적이 있다. 그 글을 보고 나서 무조건 블로그를 시작하기로 마음을 먹었지만 좀처럼 쉽지 않았다. 블로그 플랫폼을 선택하는 것부터, 글을 쓰기 위해 노력하는 시간들까지 무엇 하나 신경이 쓰이지 않는 부분이 없었다. 하지만 내가 구글링을 하면서 다른 개발자분들의 기록, 정리들을 살펴보면서 개발에 대한 도움을 많이 얻고 있는데 나는 소비만 하고 생산은 하지않는다는 것이 받기만 하는 느낌이 들었다. 또한, 블로그 하시는 개발자분들을 보며 존경심이 생겼고 많은 자극과 동기부여를 받았다. 그래서 나도 다른 개발자분들에게 도움이 되고 싶고 나름대로 내 공부도 되기 때문에 일타이피로 블로그를 시작하기로 마음 먹었다. (또한, 현재 자기자신의 관심사가 뭔지 보여줄 수 있는 창구가 된다.)

다음은 내가 생각하는 블로그를 하면 좋은 점이다.

블로그를 하면 좋은 점

남에게 설명을 해야하기 때문에 더 깊이 있게 공부할 수 있다.

블로그 포스트를 쓴다는 것은 생각보다 만만치 않은 일이다. 포스트의 주제를 잡으면 그 내용에 대해 엄청 깊게 조사해봐야 하는 것이다. 내가 블로그를 시작하지 못한 이유 중 하나이다. 포스트를 쓰기 위해서는 대충 알아서는 안되기 때문이다. 대충 알면 독자들에게 제대로 그리고 쉽게 설명할 수 없다.

글쓰기 실력이 늘어난다.

개발자들은 보통 이공계 출신이기 때문에 글쓰기 능력이 많이 떨어진다.(~~아닌 사람도 많은듯~~) 따라서 블로그 포스팅을 함으로써 글쓰기 능력을 기를 수 있다.

포트폴리오가 된다.

개발자에게 블로그는 포트폴리오가 될 수 있다. 자신이 관심 있게 사용한 기술들과 그 기술들을 사용한 내용들이 좋은 글들로써 블로그에 충분히 담겨져 있다면 더할 나위 없을 것이다.

🌜 마지막으로

이 글을 쓰는데도 적잖은 시간이 들었다. 내가 제대로 꾸준히 블로그를 유지/관리할 수 있을지 걱정된다. 2019년에는 일주일에 퀄리티 좋은 글 하나 쓰기를 목표로 하겠다는 다짐으로 블로그를 시작하겠다. 아자아자!! 🥝

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

🍉 In JS, is an empty Array return false or true?

😃 General

When I was coding, there was a situation that if an array has values, it will return true. So I wrote like this bool = !!array. But, unexpectedly when array = [], bool is false, not true.

🤔 Why?

First, I thought if empty string or empty Array is conversed to Boolean, it must return false.
But it is not.

// Conversion
> Boolean("")
false
> Boolean([])
true
// Implied Conversion
> !!""
false
> !![]
true

In Conversion, the result is like this, so I thought '' is false, [] is true.

// Loose Equality
> "" == false
true
> [] == false
true

But here in Loose Equality, the result is '' is false(of course), [] is false too.
I found a doc about this. Equality comparisons and sameness
In Loose Equality, [] is Object, and false is Boolean. So in the table, it is applied that ToPrimitive([]) == ToNumber(false) and recursively ToNumber("") === 0. Eventually, it returns true.
I certainly realized when I saw this table. plz memorize it.

toBoolean Table

Argument Type	Result
`undefined`	`false`
`null`	`false`
`boolean`	same as input
`number`	`+0`, `-0`, `NaN` -> `false`, otherwise -> `true`
`string`	empty string -> `false`, otherwise -> `true`
`object`	`true`

🤖 Conclusion

Because Array is type of object, the fact that an empty Array is conversed to true is correct.
But in Loose Equality, [] == false is right.
So, above bool = !!array code can be changed bool = array == false.
Or, you can make function that checks array === undefined or array.length === 0. 🥝

📖 reference

(This is an article posted to my blog at blog.holy.kiwi. You can read it online by clicking here.)

blog.holy.kiwi

👨‍💻 내가 맥북을 세팅하는 방법

시스템 환경설정

키보드

키보드 > 단축키

키보드 > 텍스트

키보드 > 키보드 > Control Strip 사용자화

Dock

사운드

파인더

Siri

트랙패드

기타

필수 애플리케이션

설치해야 하는 확장프로그램

폰트

설정

Postman 혹은 Insomnia

선택 애플리케이션

CLI

git

Git 권한 설정

커맨드마다 passphrase 입력하기 귀찮으면

터미널 환경 세팅

참고

🎄 크리스마스에 치앙마이에서 2019년 회고 쓰는 내 인생이 레전드다

🏫 여름까지 회사와 학교를 병행

🚪 회사 첫 퇴사

🎎 사이드 프로젝트

군돌이 - 국민 전역일계산기 앱

2019년 군돌이 작업 내용

Playground - 교내 소프트웨어 공모전 참여 (학장상)

2019 NAVER CAMPUS HACKDAY WINTER 참여

awesome-apple-watch 레포지토리 ⭐100

1일 1커밋

첫 외주

👨‍💻 코딩테스트, 면접 경험

2019 카카오 개발자 겨울 인턴십

코딩테스트

기술면접

2019 네이버 동계 인턴십

기술면접

카카오 계열사 인턴십

코딩테스트

화상 기술면접

기술면접 후 느낀점

🏃 PT 후 몸무게 증가, 체력 상승

✈️ 여행

🇻🇳 1월 베트남 다낭 (10일)

🇭🇺 8월 헝가리 부다페스트 한달살기 (28일) (+ 🇸🇰, 🇦🇹)

🇹🇭 12월 태국 치앙마이 (10일) - 진행중

🥝 2019년을 보내며

요약

🗓 이제야 쓰는 2018년 회고

🎡 첫 회사에서 첫 개발자 생활

회사에 들어간 계기

React 프론트엔드 그리고 안드로이드

Node.js 백엔드

iOS 스위프트까지

다시 안드로이드

👑 개발자 컨퍼런스

🦁 여러 사이드 프로젝트들

네뷸러스 DApp 개발

Inko 자바스크립트 오픈소스 라이브러리 개발

React Native 군돌이 앱 개발

🐙 1일 1커밋

😶 한 해동안 느낀 점

🛫 앞으로 올해에는?

📘 [번역] NPM의 중첩된 종속성

✌ 중첩된 종속성과 평평한 종속성 (Nested Dependencies and Flat Dependencies)

🥙 평평한 종속성 (Flat Dependencies)

🐦 중첩된 종속성 (Nested Dependencies)

🔖 장점과 단점

평평한 종속성 (Flat Dependencies)

중첩된 종속성 (Nested Dependencies)

🥝 React Native 사이드프로젝트. 보름만에 iOS, 안드로이드 앱 출시하기

💫 시작

⚛ 왜 React Native로 개발하였나

⚒ 개발환경 설정

💻 개발 과정