
저는 포맷을 하다가 중요 파일을 날려먹고 한숨을 내 쉬는 일이 많았습니다.
아직 맥을 산 이후로 딱 한번만 공장 초기화를 했지만, 언젠가 맥을 초기화하거나 다른 기계로 옮겨갈 경우에 무엇무엇을 챙겨야할까 생각하며 맥을 포맷하기 전에 개발자라면 꼭 해야할 일들을 정리해보기로 했습니다.

※ 이 글은 지속적으로 연구 및 갱신됩니다.

## 1. SSH

Mac을 쓰는 개발자라면 아마 모두가 SSH를 쓸거라고 봅니다.
SSH 관련된 설정들은 보안 문제가 걸려있으므로 백업 1순위가 아닐까 싶습니다.

### SSH Key

`~/.ssh/id_rsa` 파일과 `~/.ssh/id_rsa.pub` 파일을 챙깁시다.
각각 비밀키와 공개키입니다.
(아주 당연한 이야기지만) 비밀키는 gist 등에 올리면 위험합니다.

### SSH Config

`~/.ssh/config` 파일을 백업합시다.

## 2. VCS

버전관리를 한다면 버전관리에 쓰는 설정들도 백업하는게 좋습니다.

### Git

`~/.gitconfig` 파일에 설정이 저장되고, `~/.gitignore_global` 파일에 전역적으로 무시할 파일이 저장됩니다.

### Hg (Mercurial)

User 단위 설정은 `~/.hgrc` 에 저장됩니다.

## 3. GPG

[keybase.io](https://keybase.io/)나 그 외의 [GPG](https://www.gnupg.org/) Key를 사용하는 경우엔 해당 키값도 보관해야합니다.
저장 위치는 `gpg -K` 명령어를 통해 알 수 있는데, 일반적으로 `~/.gnupg/` 입니다.

## 4. Bash

Bash를 시작할 때 실행되는 `~/.bash_profile` 파일도 백업해두면 나중에 이식할 때 자신이 무엇을 설치했었는지 알 수 있어 좋습니다.
프로그램에 따라 `~/.bashrc` 파일을 사용하기도 하는데, 한쪽으로 내용을 몰아주는게 좋습니다.

## 5. Brew

Mac에서 개발을 하다보면 brew로 이것저것 설치하게 되는데요, `brew list` 명령어를 실행하면 자신이 설치한 프로그램 목록이 나옵니다.

## 6. Language Version Manager

언어를 단일설치했다면 그냥 그대로 옮기면 되겠지만 여러 버전을 관리 툴을 사용해서 설치했다면 버전들도 옮겨야할 것입니다.

### Python - pyenv

`pyenv versions`를 실행하면 설치한 모든 Python 버전을 얻을 수 있습니다.

### Python - virtualenv-wrapper

Python을 사용하는 경우엔 virtualenv-wrapper도 많이 사용합니다.
`lsvirtualenv`를 사용하면 생성한 모든 virtualenv 이름을 얻을 수 있습니다.

### Node.js - nvm

`nvm ls`를 실행하면 설치한 모든 node.js 버전을 얻을 수 있습니다

### Ruby - rvm

Ruby의 경우엔 `rvm ls` 입니다.

## 7. Editor

사용하는 프로그램들의 설정 또한 백업하는 것이 좋습니다.

### Vim

`~/.vimrc` 파일에 설정, `~/.vim` 디렉토리에 관련 파일들이 위치합니다.

### JetBrains 제품군

`File > Export Settings...` 를 이용하면 추출할 수 있습니다.

### Atom

`~/.atom` 디렉토리에 여러 파일이 있는데, 여기서 백업해야하는 것은 `.json`, `.cson`, `.coffee`, `.less` 파일입니다.
패키지 목록은 다음 명령어로 백업합니다.

```
$ apm list --installed --bare > packages.list
```

복원은 다음과 같이 합니다.

```
$ apm install `cat packages.list`
```

## 7. Global Packages

패키지를 전역적으로 설치해서 사용하는 경우도 있습니다.
해당 툴이 없으면 불편해지는 경우도 많으므로 백업해둡시다.

### Python

`pip freeze` 명령을 통해 얻을 수 있습니다.

### Node.js

`npm ls -g` 명령을 통해 얻을 수 있습니다.

### Ruby

`gem list --local` 명령을 통해 얻을 수 있습니다.

## 8. Fonts

[이 글을 참조하세요](https://discussions.apple.com/message/3554362)

## 9. 그 외

- 아주 당연한 이야기지만 모든 소스코드는 저장소에 올려놓던가, 백업하셔야 합니다.
- Babel을 사용하신다면 `~/.babel.json` 을 백업하셔야 할 수도 있습니다.
- 설치하신 Database의 설정, 사용자, 내용 등도 백업하세요.
- 브라우저의 북마크나 설정 등도 백업하셔야 합니다. Firefox Sync 등의 브라우저 동기화 기능을 이용하면 편리합니다.
- FTP 등을 사용하신다면 해당 설정도 백업하셔야 합니다.
- 중요한 Wi-Fi 비밀번호 등이 Keychains에 있지 않나 확인해보세요.

## 요약

- `~/.ssh/id_rsa`
- `~/.ssh/id_rsa.pub`
- `~/.ssh/config`
- `~/.gitconfig`
- `~/.gitignore_global`
- `~/.hgrc`
- `~/.gnupg/` (DIR)
- `~/.bash_profile`
- `~/.bashrc`
- `$ brew list > brew_installed_programs`
- `$ pyenv versions > python_versions`
- `$ lsvirtualenv > python_virtualenvs`
- `$ nvm ls > node_versions`
- `$ rvm ls > ruby_versions`
- `~/.vimrc`
- `~/.vim` (DIR)
- `~/.atom/*.json`
- `~/.atom/*.cson`
- `~/.atom/*.coffee`
- `~/.atom/*.less`
- `$ apm list --installed --bare > packages.list`
- `$ pip freeze > python_requirements.txt`
- `$ npm ls -g > node_requirements.txt`
- `$ gem list --local > ruby_requirements.txt`


맥을 포맷하기 전에 개발자라면 꼭 백업해야할 것들을 정리해봤습니다.

맥 포맷 전에 당신이 꼭 해야할 일

Mac 자료 백업하기


어제 잠을 자다가 깨버려서 트위터를 보는데, [Outsider님께서 사내 프레임워크에 대해 쓰신 글](https://blog.outsider.ne.kr/924)이 타임라인에 있었습니다.
읽다보니 참 여러가지 생각이 들었는데, 그냥 흘려보내긴 아까운 것 같아서 글로 남겨보려고 합니다.

## 사내 프레임워크는 무엇인가?

업종에 따라 없기도 하기 때문에 잘 모르는 분이 계실 수도 있을 것 같아서 간단히 소개합니다.

사내 프레임워크는 말 그대로 회사 내에서만 쓰는 프레임워크입니다.
회사에서 반복적으로 쓰이는 작업에서 생산성 향상을 위해 개발됩니다.
직업교육을 아무리 받아도 회사에 가서 더 배워야 하는 원인 1위를 차지하고 있는 요소입니다.
회사 내에서 필요한 것들을 뭉쳐서 만들게 되는데, 이것이 방치되면 훗날 레거시가 됩니다.

## 사내 프레임워크는 왜 탄생하는가?

저는 웹 개발자니까 웹으로 예를 들겠습니다.
웹 사이트를 개발하다보면 반복적으로 하게 되는 작업들이 있습니다.
웹 사이트를 바닥부터 만든다고 생각해봅시다.
그렇다면 PHP로는 대략 이런 식으로 시작하게 되겠죠.[^1]

```php
<?php
$config = read_config();
$instance = new PDO($config['db']);


```

사이트를 100개 만든다면, 이런 작업을 100번 하게 될 것입니다.
이걸 매번 타이핑하는 것은 매우 귀찮은 일입니다.

더군다나, 웹 사이트의 경우에는 대부분 게시판이나 쇼핑몰 같은 기능이 필요합니다.
대부분의 게시판이나 쇼핑몰은 회원 시스템을 요구하게 되죠.
따라서 서로 얽힌 기능들이 서로간의 의존성을 가진 상태의 코드가 매번 필요해집니다.

이걸 매번 개발하는 것은 너무나도 실용성 면에서 나쁩니다.
그리고 그 결과 이러한 작업들을 하나로 뭉뚱그려서 하나의 틀(frame)위에서 동작하는 프로그램, 프레임워크(framework)가 만들어지게 됩니다.

## 사내 프레임워크는 나빠진다

사실 여기까지는 매우 자연스러운 흐름입니다.
하지만 여기엔 맹점이 존재합니다.

이제까지 100여곳의 쇼핑몰을 만들었고, 반복 작업이 싫어서 이것을 하나의 프레임워크로 만들어서 쇼핑몰 이란 문제에 대한 솔루션으로 쓰고자 한다고 칩시다.
그러면 보통 100여곳은 새로 만들어진 프레임워크로 커버가 가능할 것입니다.
만들어진 기능에 한해서는 프레임워크 내장 기능으로 인한 기능 추가가 용이하다던가, 개발성이 향상될 수도 있습니다.

하지만 개발이라는 것은 언제나 같은 명세가 아닙니다.
똑같은 회원 가입 시스템을 만든다고 해도 어디는 성과 이름을 나눠서 받을 것이고, 어딘가는 실명 인증을 해야만 하고, 어딘가는 외국어 이름을 받거나 아예 이름을 받지 않을 수도 있습니다.
이 모든 케이스를 사내 프레임워크에 넣을 것인가요?

사실 넣을 수도 있습니다.
하지만 보통 넣다보면 **급하게** 만들게 되는 경우가 대부분이고, 그마저도 **땜질** 수준이 되기 쉽상입니다.
점점 기능이 비대해지기는 하지만 아무도 관리를 제대로 하지 않기 때문에 기능의 정상 작동이 보장되지 않습니다.

그리고 이렇게 쑤셔넣은 기능들은 쉽사리 바꾸기 쉽지 않습니다.
왜냐하면 예전 소스들을 다 고쳐야하는 상황이 올 수 있기 때문입니다.[^2]
이러한 부담은 결국 회사 입장에서도 부담이기 때문에 프레임워크를 고치기보다는, 해당 케이스에서만 쓸 수 있는 임시 변통을 쓰게 됩니다.
예외를 위해 `if` 구문으로 도배된 비대 함수가 만들어지거나, 아니면 그냥 서비스마다 형태는 엇비슷하지만 사실 다르게 개조된 프레임워크 소스를 쓰게 됩니다.

**프레임워크를 만든 당초의 취지는 어디론가 사라지고 나쁨만이 남습니다.**

## 사내 프레임워크의 죄

이런 질문을 받을 수도 있겠군요.

> "그렇게 되면 뭐가 나쁜데요?"

사내 프레임워크는 갈수록 죄를 짓게 됩니다.
개발자를 위해 만든다면서 개발자를 더 힘들게 만듭니다.

보통 사내 프레임워크는 문서화, 테스팅이 잘 안됩니다.
빨리 상품을 만들어서 넘겨야하는 입장에서 프레임워크로 중복작업을 줄이는 것이 목적이기 때문에 문서화 같은 사후를 위한 부분들은 보통 뒷전으로 밀려나게 되기 때문입니다.
처음 만들 때 문서화를 잘 했더라도 추후에 기능을 추가 할 때는 (급하기 때문에) 못할 가능성이 높습니다.
테스팅도 마찬가지입니다.
아예 테스팅을 하지 않거나, 초기에 개발된 기능들만 테스트 대상에 들어있을 뿐이게 됩니다.

이렇게 된 상태에서 누군가 유지보수를 위해 투입되면 무슨 일이 벌어질까요?
문서가 없거나 도움이 안되는 상황이기때문에 결국은 프레임워크 소스를 뜯어보게 됩니다.
시간을 줄이기 위해 존재했던 프레임워크가 시간을 더 잡아먹기 시작합니다.
그리고는 ad-hoc한 동작들을 위해 프레임워크에 무언가 덧대여지는 경우도 허다해집니다.
프레임워크가 더 나빠집니다.

그래도 사내 프레임워크의 발전(?)과정을 계속 겪어온 사원들에겐 양반입니다.
신입사원의 경우는 어떨까요?
처음부터 모든 동작을 이해하기 위해 소스를 다 뜯어봐야 합니다.
열심히 읽은 복잡한 메소드의 구현이 사실은 지금은 별로 안 쓰이는 부분일 수도 있습니다.
신입 교육의 난이도 및 시간을 증가시킵니다.

## 은탄환은 없다

이 문제는 사실 첫 단추를 잘못 끼웠기 때문에 발생합니다.

**모든 문제를 해결해주는 은탄환은 존재하지 않습니다.**

개발을 하려면 적재적소에 적당한 소스를 넣어야 합니다.
하지만 사내 프레임워크의 최종 목표는 은탄환이라는 불가능한 꿈이기 때문에 언제나 점점 나빠집니다.

이 문제는 두 가지 문제 의식을 가져야 탈출이 가능한데, 첫째로는 무조건 덧대여 만드는 게 빠르다는 의식을 버리는 것이고, 둘째로는 [프로그램이 녹이 슨다는 사실](http://blog.dahlia.kr/post/82482810330)을 인정해야 하는 부분입니다.

## 누더기

녹이 슨다는 부분에 대해서는 글을 인용했는데, 덧대어 만드는 쪽은 어떤지 적어봅니다.

덧대어 만든다는 것은 사실 프로그램의 본 취지에서 벗어난 기능을 추가하는 경우일 수 있습니다.
가령 환율 계산기를 만들었는데, 국가명을 번역하는 기능을 추가로 넣어야 한다면 그 것은 프로그램의 본 취지를 벗어난 기능일 가능성이 큽니다.
그렇게 덧대고 덧대고 또 덧대서 만들어진 프로그램은 공룡이 아니라 누더기일 뿐입니다.

멋진 옷이 필요한데, 누더기를 기반으로 땜질을 하는게 빠를까요? 아니면 처음부터 만드는게 빠를까요?

## 탈출구는?

오픈 소스로 배포해서 고인 물이 아닌 흐르는 물이 되게 하는 것은 훌륭한 대안입니다.
하지만 사내 프레임워크가 만들어지는 경우엔 대부분 소스를 공개할 수 없는 경우가 많을 것입니다.
그 소스만 있으면 누구나 사업을 똑같이 할 수 있다던가 하는 문제점이 직면하겠죠.

이 문제를 해결하려면 결국 내부적으로라도 오픈 소스처럼 더욱 명확하게 문서화를 하고, 더욱 꼼꼼히 테스팅과 CI를 하며, 필요에 따라 리팩토링을 해서 스스로 정화가 되게끔 해야합니다.
하지만 이것은 사내 프레임워크를 만드는 흐름과는 반대되는 움직임입니다.

저 개인적으로는 보다 나은 생산성을 위한 투자라고 생각하면 어떨까 생각하지만, 이러한 투자를 싫어하는 회사도 많을 것입니다.
무엇이 절대적으로 옳다고는 말할 수 없지만, 답을 내야하는 문제라는 것은 명확합니다.

제가 할 수 있는 말은 구글의 [Code of Conduct](https://abc.xyz/investor/other/code-of-conduct.html)로 유명한 이 한마디가 아닐까 싶습니다.

<p style="font-size: 2em; text-align: center;">Do the right thing.</p>

[^1]: 소스 구조가 구린건 저도 압니다. 어디까지나 예시일 뿐.
[^2]: 특히 임대형 솔루션 업체


사내 프레임워크, 회사 내에서 내부적으로 사용하는 프레임워크들에 대한 개인적인 생각

사내 프레임워크에 대한 생각


저는 전공상 홈페이지를 만들어야한다는 사람을 꽤 자주 접하게 되는데 대부분 홈페이지가 어떻게 구성되는 지 알지 못하기에 계속 중복되는 설명을 하게 되더군요.
이번 글에선 그 중복되는 이야기를 정리해볼까 합니다.

※ 이 글은 비전공자들을 구독대상으로 작성되었습니다.

## 홈페이지는 어떻게 만들지?

홈페이지를 어떻게 만들지도 모르는 사람이 홈페이지를 공부해서 처음부터 만들어 나가는 것은 너무나도 고된 일입니다.
기술이 발전하면서 쉬운 저작 도구도 많이 나온게 사실이지만 그에 비해 현대의 웹은 너무 많이 발전해버렸습니다.
더군다나 사용자의 요구사항과 눈높이도 덩달아 올라가서 처음 배운 사람이 어느정도 만들 즈음이면 지금까지 만든 홈페이지는 이미 필요 없는 상황이 되어 있을겁니다.

홈페이지는 기본적으로 눈에 보이는 것(글, 그림, 동영상 등)을 웹 게시물의 형태로 구조화한 것을 서버에서 전송해주는 것입니다.
따라서 홈페이지를 만드려면 "눈에 보이는 것"에 해당하는 **사이트 콘텐츠**와 그 내용을 어떻게 구조화 할 것인가에 대한 **스토리보드**, 그리고 **서버**와 **개발적 요소들**이 필요합니다.

## 사이트 콘텐츠와 스토리 보드

홈페이지에서 무슨 이야기를 할 것인가 하는 부분입니다.

상당수의 사람들이 막상 이야기를 들어보면 홈페이지가 필요하다는 생각만 할 뿐, 홈페이지에 무엇을 넣어서 사용자에게 무엇을 보여주고 싶은지 구체화를 안해보는 경우가 많습니다.

**여러분이 스스로도 구체화하지 못하는 모호한 상상을 마법같이 만들어주는 도구나 기술자는 이 세상에 없습니다.**

일단 기본 기획이 나오지 않으면 디자이너도, 개발자도 아무것도 할 수 없습니다.
일단 어떤 사이트가 필요한지, 어떤 내용을 고객에게 어떻게 전달할 것인지를 고민해보세요.

실제 제가 최근에 겪은 예를 들면 이런 아이디어가 나올 수 있습니다.

> "나는 우리 학원 홈페이지를 만들 것이다."

하지만 이것만으로는 목적을 알 수 없습니다.
저는 이 고객과 긴 시간 대화를 해보면서 다음과 같은 정보를 얻어냈습니다.

> "네이버에 검색했을 때 잘 나오면 좋겠어."[^1]
>
> "따뜻하고 원생을 잘 챙겨주는 이미지의 학원임을 어필하고 싶어"
>
> "젊은 학원"
>
> "학원생에게만 제공되는 영상 강의 서비스가 필요해"

어떤 홈페이지가 필요한지 좀 더 구체적이게 되었습니다.
하지만 아직 기능적인 부분은 알 수 없습니다.
조금 더 구체적으로 들어가보도록 하겠습니다.

### 1. 학원의 이미지를 어필하고 싶다.

학원의 이미지를 어필하려면 **학원 소개**가 필요합니다.
학원 소개를 어떻게 하느냐에 따라 학원의 이미지가 달라질 것입니다.
이런 내용은 일단 기본적인 내용의 틀을 학원 주인이 정해서 준 다음 작문에 소질이 있는 사람이 교정하는 것이 좋겠죠.

### 2. 젊은 학원

역시 학원 소개가 필요합니다.
저는 여기에 추가로 **원장 소개**와 **교사 소개**를 제안했습니다.
실제로 교사진에 대한 정보를 제공하면 더욱 방문자의 신뢰를 얻을 수 있을테니까요.

### 3. 동영상 강의를 제공하고 싶다.

상당히 중요한 기능입니다.
이런 부분을 언급하지 않고 홈페이지 제작을 의뢰했다간 큰 낭패를 보게 됩니다.
왜냐하면 단순히 학원 홍보를 하는 사이트와 동영상 강의를 하는 사이트는 다르기 때문입니다.
의뢰자 입장에서는 사소하다고 생각하는 기능이 엄청난 변수가 될 수 있습니다.

이런 기능은 대체적으로 부가적인 문제를 포함하는 경우가 많습니다.
가령 이 사이트의 경우엔 학원 원생만 영상을 볼 수 있어야 하고, 관리자가 영상을 올릴 수 있어야 하므로 회원 시스템과 등급 시스템이 반드시 필요합니다.
영상이 자동으로 올라갈 리 없으므로 영상을 처리해주는 서버단 프로그램도 필요합니다.

### 4. 검색에 잘 나왔으면 좋겠다

이 문제는 좀 심각한 주제입니다.
뒤에서 설명하겠습니다.

### 요약

단순히 "학원 홈페이지" 라는 이름이었지만, 뚜껑을 열어보니 생각보다 많은 상세 사항들이 나오게 됩니다.
이런 사항들을 알려주지 않으면 디자이너도, 개발자도 아무것도 할 수 없습니다.

## 방문자 타게팅

홈페이지 방문자는 어떤 컴퓨터를 쓰고 있을까요?
어떤 사람은 Windows 7에서 Internet Explorer 10으로 접속할 수도 있고, 어떤 사람은 비전공자는 들어보지도 못했을만한 프로그램으로 접속할 수도 있습니다.

홈페이지 개발에 있어서 모든 사용자를 지원하는 것은 사실상 불가능에 가깝습니다.
왜냐하면 Microsoft사의 Internet Explorer이 다른 브라우저에 비해 너무나도 열악하기 때문입니다.
웹 개발에 있어서 최신 기술들은 대부분 Internet Explorer를 포기했습니다.
왜냐하면 이미 Microsoft도 IE를 포기하고 Edge라는 새 브라우저를 만들었을 정도니까요.

하지만 국내 사용자들은 아직도 IE를 가장 많이 사용하고 있습니다.
그렇기에 적절한 절충선이 필요한데, Windows XP를 사용하는 경우엔 IE 6~8 버전대를, Windows 7을 사용하는 경우엔 IE 8~11 버전대를 사용합니다.
국내의 Windows XP 점유율은 아직도 높은 편이지만 PC방 등의 환경들은 대부분 Windows 7 이상을 채택한 상황입니다.

방문자들이 어떤 환경에서 접속할 지 대략적인 자료가 있어야 범위를 좁힐 수 있습니다.
그래야 사용할 수 있는 기능을 추스릴 수 있기 때문입니다.

## 디자인적 요소

홈페이지의 모양은 자동으로 만들어지는 것이 아닙니다.
디자이너의 손을 거쳐서 만들어지는 것이죠.
디자이너를 통해 UI(사용자 인터페이스)와 UX(사용자 경험)을 구성해야합니다.

홈페이지 개발에서 많은 분들이 오해하는 부분 중 하나는 홈페이지에 들어가는 리소스입니다.
이미지나 동영상, 글꼴 등은 모두 저작권자가 존재하고, 저작권자 저작권을 행사할 수 있습니다.
따라서 합법적으로 돈을 주고 사용하는 것이 맞습니다.

이는 홈페이지 개발 단계 뿐만 아니라 홈페이지 개발 후에 운영시에도 적용되는 문제입니다.
홈페이지를 운영하는데 삽입한 이미지에 구입하지 않은 폰트가 사용되었다던가 하면 그로 인한 저작권 싸움에 휘말릴 것입니다.

## 개발적 요소

홈페이지는 그냥 보이는게 아닙니다.
보여지게 구성해야 비로소 보여지는 것입니다.
우리가 보기에는 매우 단순한 기능들이지만 사실 홈페이지로 만드려면 매우 힘든 문제가 되는 경우도 많습니다.
이러한 부분들은 결국 개발자가 개발을 해야하고, 다른 사람에게 맞기게 되면 그에 따른 비용이 발생합니다.

개발에는 돈만 드는 것이 아니라 시간이 듭니다.
당연히 작업의 난이도와 투입되는 개발자의 실력, 수에 영향을 받습니다.
하지만 그 중에는 개발자를 아무리 많이 투입해도 1명이 할 때와 진행 속도에 별 도움이 안되는 경우도 있습니다.
산모가 10명 있다고 아이가 한 달 만에 나오진 않습니다.[^2]

홈페이지 제작에서 개발을 하게 되는 부분은 크게 두 가지인데, 사용자에게 직접적으로 보여지는 부분과, 서버단에서 돌아가는 부분입니다.
후자의 경우는 사용자 눈에 바로 보여지지 않기 때문에 개발을 하지 않고 있는 것이 아니냐며 항의하는 경우도 많이 봤습니다.
하지만 그쪽 개발이 안되면 결국 사이트가 돌아가지도 못하는 경우가 허다하므로 중도 해약등은 하지 않는게 좋습니다.

## 서버와 도메인, 인증서

기본적으로 서버는 컴퓨터입니다.
홈페이지용 서버는 누가 접근하려고 해도 24시간 켜져있는 컴퓨터여야 합니다.
그리고 서버에는 서버용 프로그램들이 설치되어야 합니다.
그렇기 때문에 비전공자들이 관리하기에는 무리가 있기때문에 대부분 임대를 합니다.
대체적으로 서버의 일부만 빌려서 웹 전용으로만 쓰는 웹 호스팅과 그 외의 경우를 위한 서버 호스팅으로 나뉘는 편입니다.[^3]
서버 임대도 물론 돈이 듭니다.

서버만 있다고 되는 것은 아니고 도메인도 필요합니다.
서버를 실제 건물을 지을 수 있는 땅이라고 하자면 도메인은 해당 땅에 부여되는 주소입니다.
홈페이지를 만드는 것은 그 땅(서버)위에 건물을 짓는 것 같은 작업인 것이죠[^4]
이 역시 연단위로 임대를 해야합니다.
이 부분은 대행을 맞기지 않는 한 직접 해야하는 부분입니다.
도메인 주소는 생각보다 중요한 요소인데, 짧고 기억하기 좋으며 인상적인 주소가 좋습니다.

그리고 또 한가지 변수가 있다면 인증서입니다.
개인정보를 취급하는 홈페이지를 위해 사용자와 홈페이지 사이의 통신을 암호화하는데에 필요합니다.
국내 사이트라면 국내법 상 개인정보를 취급하는 사이트라면 무조건 필요하고, 해외 사이트도 인증서를 사용하는 추세입니다.
인증서는 인증 기관의 신뢰도에 따라 가격이 더 비싸며, 역시 연단위로 갱신이 필요합니다.

## 검색에 잘 나오기

대부분의 사람들이 홈페이지를 들어오는 출입문이 되는 것이 바로 검색엔진입니다.
따라서 검색엔진에 검색했을 때 잘 나와야 홈페이지가 의미있게 되는 경우가 많습니다.

국내의 경우엔 거의 대부분의 사람들이 검색을 네이버에서 합니다.
그리고 네이버는 외부 자료의 추적력이 약한 검색 엔진이지요.
따라서 네이버는 외부 자료를 직접 수집하는 대신 키워드 광고라는 시스템을 채택했습니다.
간단히 말하면 비싼 돈을 주면 검색했을 때 사람들이 잘 보는 자리에 자신의 사이트가 나오게 해주는 것입니다.
키워드 광고는 키워드에따라 단가가 다르다고 알고 있습니다.
보다 사람들이 자주 찾는 검색어는 그만큼 가격도 상승하겠죠.

해외의 경우엔 구글의 점유율이 높은 편입니다.
구글도 키워드 광고가 있긴 하지만 구글은 외부 자료를 적극적으로 활용하는 편입니다.
구글에 잘 나오기 위해선 구글을 위한 전략이 필요합니다. 이러한 전략을 검색 엔진 최적화(Search Engine Optimization)이라고 합니다.

## 홈페이지는 누구 것인가?

이렇게 개발한 홈페이지는 누구 것일까요?
여러분의 것이라고 생각하실텐데 일부분에 대해서는 아닐 수도 있습니다.
몇몇 제작사들은 홈페이지를 제작해서 고객에게 전달하는 것이 아닌 개발 후 임대를 해주곤 합니다.
이런 경우에는 나중에 홈페이지 서버를 옮기거나, 직접 서비스 코드에 무언가를 추가하고 싶어도 마음대로 할 수 없게 됩니다.
하지만 임대형도 나름의 장점이 존재하므로 적절한 선택이 필요합니다.

또한, 소유권이 자신에게 있다는 것은 책임소재 또한 자신에게 있음을 의미합니다.
자신의 사이트에 저작권법에 저촉되는 이미지 등이 사용된다던가 하는 경우엔 그 책임은 사이트의 주인이 지게 됩니다.

## 더 고민해볼 만한 요소

- 보안 (고객 고유정보는 어떻게 관리하지?)
- 소스 (내 홈페이지의 소스를 내가 관리할 수 있을까?)
- 확장성 (내 홈페이지에 나중에 기능을 추가하는 것이 가능할까?)
- 가용성 (내 홈페이지는 손님이 늘어나도 괜찮을까?)

---

이렇게 홈페이지 개발에 있어서 알아야할 아주 기초적인 부분들에 대해 알아보았습니다.
이 글에선 실제 개발을 어떻게 하는지 등에 대한 정보는 다루지 않았는데, 이 글은 어디까지나 비전공자를 대상으로 하는 글입니다.

그리고 이 글을 쓴 작성자는 Snoin이란 팀에 속해있고, Snoin은 웹 개발을 전문적으로 담당하고 있습니다.
실제 개발 의뢰에 대한 문의가 있으신 분은 http://snoin.com 으로 문의주시면 감사하겠습니다.

[^1]: 이 문제는 좀 더 뒷 단락에서 상세히 설명합니다.
[^2]: 맨먼스 미신의 명언 중 하나죠
[^3]: 그 외에도 많은 방식이 존재합니다.
[^4]: 하지만 홈페이지 개발을 포함한 모든 프로그램 개발은 건축과는 다른 메타포를 갖습니다.


홈페이지를 만들어야해서 막연해진 비전공자들을 위한 글

홈페이지를 만들어야겠다는 고민중일 때 생각해볼 것들


기존 본 블로그는 Jekyll로 구성되어 있었습니다.
별도로 블로그 툴을 개발하지 않아도 되고, markdown을 통해 블로깅이 가능하며, 문법 강조나 버전 관리 등의 여러 혜택을 받을 수 있었기 때문입니다.

하지만 한계가 분명했습니다.
일단 render를 GitHub 서버에서 하기 때문에 편리하긴 하지만 추가적인 기능을 얹을 방법이 없었습니다.
문법 강조도 pygments.rb가 버전이 올라가지 않는 한 대책이 서지 않는 상태였습니다.
무엇보다, Jekyll이 내부적으로 사용하는 템플릿 엔진, Liquid의 기능이 줄곧 불만이었습니다.[^1]

그리고 2015년 12월 22일, Python 웹 프레임워크 Flask의 개발자로 유명한 Armin이 Lektor라는 신제품을 내놓습니다.

<blockquote class="twitter-tweet" lang="ko"><p lang="en" dir="ltr">Website: <a href="https://t.co/1eYjlFy9R5">https://t.co/1eYjlFy9R5</a> — Overview blog post: <a href="https://t.co/9oecGC0MR4">https://t.co/9oecGC0MR4</a> — Quickstart/Screencast <a href="https://t.co/whN6bfoFF1">https://t.co/whN6bfoFF1</a></p>&mdash; Armin Ronacher (@mitsuhiko) <a href="https://twitter.com/mitsuhiko/status/678963678444691456">2015년 12월 21일</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

## Lektor

[Lektor](https://www.getlektor.com/)는 Python으로 개발된 정적 사이트용 CMS입니다.
Jekyll처럼 적당히 파일을 배치하고 빌드하면 정적 웹 사이트가 완성되는 방식입니다.

### 장점

- Python이다.
  - 따라서 Pygments등의 Python Third-party와의 궁합이 좋다.
  - ~~내가 잘 모르는~~ Ruby보다는 훨씬 익숙하다. 필요하다면 기여를 한다거나 하는 방식으로 문제 대처 가능
- 템플릿 엔진으로 Jinja2를 사용한다.
  - 보다 많은 표현식이 지원된다.
  - `{%- if some %}` 과 같은 `-`를 사용해서 소스상에 불필요한 여백 발생을 없앨 수 있다.
- Pagination을 여러 곳에 분산 배치 가능
- 다국어 지원 가능
- 여러 endpoint로의 배포 시스템
- 관리자 페이지
- 보다 효율적인 첨부 파일 관리 시스템
- webpack 지원

### 단점

- 보급이 덜되서 상대적으로 참고할만한 자료가 적다 (시간이 해결해줄 문제)
- DateTime형 변수가 없다. (2.0에 추가 예정)
- 문법 강조를 위해 플러그인을 추가로 설치해줘야 하는데, 아직 해당 플러그인이 PyPI에 올라가있지 않다. (시간이 해결해줄 문제)
- Jekyll이 아니므로 GitHub에서 자동 빌드를 해주지 않는다.
- 설정이 Jekyll의 `_config.yml`보단 덜 유연하다.
- 게시물 포맷이 다르다.

저는 단점이 별로 장애가 되지 않는다고 판단하고 과감히 Jekyll을 버리고 Lektor로 이사를 감행했습니다.

## Quickstart

[Lektor 공식 사이트의 Quick Start 섹션 내용이 좋습니다.](https://www.getlektor.com/docs/quickstart/)
공식 Screencast 영상을 첨부합니다.

<iframe width="420" height="315" src="https://www.youtube.com/embed/lTWTCwuPdrU?rel=0" frameborder="0" allowfullscreen></iframe>

## Webpack

Jekyll을 쓸 때는 내부적으로 sass가 돌아가기 때문에 `.scss`파일만 덩그러니 놔두면 모든 것이 해결되었지만, Lektor에서 예전 소스를 쓰려면 webpack 연동이 필수적이게 되었습니다.

주의할 점은 다음과 같습니다.

- `package.json`과 `webpack.config.js` 파일은 `webpack` 디렉토리 내에 생성해야 합니다.
- 의존성 파일들은 당연히 버전 관리의 대상이 아니므로 `webpack/node_modules`를 `.gitignore`에 추가합시다.
- 당연하지만, node 버전에 영향을 받습니다. 적절한 버전을 설치해야 합니다.
- Babel을 쓰실거면 Babel 버전에 주의하세요! Babel 6는 preset 설치가 필요합니다.

## Liquid to Lektor + Jinja2

사실 둘의 문법은 흡사합니다.
문법 자체는 그렇게까지 손이 가진 않습니다.[^2]
중요한 것은 기존의 변수명들인데, 변수명 사용법만 몇 가지 다뤄볼까 합니다.

### URL

- Liquid
  ```jinja2
  <a href="{{ page.url }}">this page</a>
  ```
- Lektor
  ```jinja2
  <a href="{{ this | url }}">this page</a>
  ```

Lektor는 `url` 필터를 사용합니다.
외부 링크용 주소가 필요한 경우에는 `url(external=True)`와 같이 사용하면 됩니다.
asset용 링크는 `asseturl` 필터를 사용하면 매 빌드마다 다른 쿼리문을 추가로 붙여줍니다.

### Variables

- Liquid

  ```jinja2
  <!DOCTYPE html>
  <html>
    <head>
      <title>{{ page.title }}"></title>
    </head>
    <body>
      {{ content }}
    </body>
  </html>
  ```

- Lektor
  ```jinja2
  <!DOCTYPE html>
  <html>
    <head>
      <title>{{ this.title }}"></title>
    </head>
    <body>
      {{ this.body }}
    </body>
  </html>
  ```

Lektor에서는 해당 페이지에 대한 정보는 모두 `this` 변수에 들어있습니다.
`this`에 어떤 프로퍼티가 있는지는 `models/` 디렉토리에서 각 모델별 구조를 보면 확인할 수 있습니다.

### Configuration

- Liquid
  ```jinja2
  {{ site.author }}
  ```
- Lektor
  ```jinja2
  {{ config['PROJECT'].author }}
  ```

Lektor는 `.ini` 형식으로 설정을 처리합니다.
다른 더 편한 방법이 있을 것 같은데 아직은 찾지 못했습니다.

### Pagination

- Liquid
  ```jinja2
  {% for post in paginator.posts %} {% endfor %}
  ```
- Lektor
  ```jinja2
  {% for post in this.pagination.items %} {% endfor %}
  ```

Lektor는 하위 디렉토리가 있는 모든 페이지에 대해서 pagination을 지원합니다.

## Deploy

Jekyll은 GitHub에 올리기만 해도 자동 배포를 해주지만 Lektor는 그렇지 못합니다.
Command Line으로 배포할 수 있는데, 당연히 CI에서 해당 명령을 실행하면 자동 배포가 됩니다.
저는 Travis-CI를 사용했습니다.

주의할 점은 다음과 같습니다

- 환경변수 `LEKTOR_DEPLOY_PASSWORD`값은 비공개로 하셔야 합니다.
- `.travis.yml`이 없으면 CI하지 않게 설정하셔야 합니다. 안그러면 master branch가 빌드 할 필요도 없는데 계속 빌드 시도되고, 실패합니다.
- webpack을 쓰신다면 node 버전에 주의하세요.[^3] stylesheet가 생성이 안된다던가 할 수 있습니다.
- Lektor 1.0 버전대에선 아직 지원이 안되는 기능들이 몇 있습니다.[^4] 저는 이 문제를 최신 버전을 설치하는 것으로 우회했습니다.

## 옮겨오면서 바꾼 사항

Jekyll에서 옮겨오면서 바뀐 사항들이 있습니다.

### 댓글을 disqus로 변경

기존에 사용하던 komments는 로딩 속도가 빠른 점을 제외하면 다른 장점이 없었습니다.
Lektor에서 기본적으로 disqus 플러그인이 있기도 하기에 옮겼습니다.

### 스킨 개발 목적 변경

Cute Polar Bear는 앞으로 Jekyll이 아닌 Lektor용 스킨으로 개발됩니다.

### Atom feed 생성기 변경

Armin이 Lektor 공식 사이트에서 사용하는 AtomFeedSupportPlugin을 사용합니다.
그러는 바람에 RSS의 unique id가 깨져서 RSS를 연동해놓은 곳이 난리가 난 모양입니다. (...)

## 지금 옮겨도 될까?

게시물 변환을 포함해서 옮기는 데에 하루 정도 소요되었습니다.
난이도가 높진 않지만 찾아볼 자료가 공식 사이트와 소스밖에 없다는 점이 문제인데, 공식 사이트도 꽤 잘 되어 있습니다.
저는 지금 옮겨도 된다고 생각하지만, 조금 더 안정된 상황(문법 강조, pagination 등의 시스템 확립 등)을 원하신다면 2.0까지 기다리시는 것도 나쁘지 않을 것 같습니다.

[^1]: 사실 이건 Liquid가 기능이 없는 것이라기 보단 제가 즐겨쓰는 Jinja2가 탁월하게 좋아서 생긴 문제 같습니다.
[^2]: 굳이 문법 차이를 꼽자면 `capture` 대신 `set`을 쓰고, `unless` 등이 없습니다.
[^3]: Travis-CI는 nvm을 사용합니다.
[^4]: `_discoverable: no` 등의 설정이 1.0에 없습니다.


Lektor 출시와 동시에 Jekyll을 버리고 Lektor로 옮겨간 이야기

정적사이트 생성기 Lektor 이용기


저는 네이버라는 웹 사이트를 웹 개발자로써 그다지 좋아하지 않습니다.
딱히 네이버만 싫어하는 것은 아니고, 국내 포털 사이트들은 다 싫어하는 것 같습니다.
이유는 여럿 있지만 오늘은 그 중 하나인 HTTPS에 대해 이야기해보려고 합니다.

네이버 주소는 뭘까요? [**http**://www.naver.com](http://www.naver.com/)입니다.
다음은 [**http**://www.daum.net/](http://www.daum.net/)이고, 네이트는 [**http**://www.nate.com](http://www.nate.com)입니다.
주소를 보면 알 수 있지만, 모두 공통적으로 **HTTP**를 씁니다.
아니 뭐 여기까진 당연합니다.
웹 사이트가 HTTP를 안 쓸 수야 없죠.
그럼, **HTTPS**로는 접속이 될까요?
[네이버](http://www.naver.com/)도, [다음](http://www.daum.net/)도, [네이트](http://www.nate.com)도 모두 접속이 안됩니다.

사실 전 세계를 기준으로 해도 HTTPS가 안되는 사이트가 더 많을 것입니다.
하지만 포털 사이트는 문제가 다르다고 생각합니다.
**접속자 규모를 생각하면** 절대로 HTTP로 놔둬선 안되는 상황이라고 봅니다.

문제는 크게 두 가지 입니다.

## 첫째, 내 정보가 줄줄 새고 있습니다.

여기서 포털들이 반론할 수 있습니다.
확실히 포털들은 HTTPS를 사용하고 있습니다.
**국내법에서 지정한 개인정보 항목에 해당하는 정보를 전송할 때"만"**말이죠.
법에 걸리지 않는 정보는 그냥 투과 시킵니다.
하지만 지금처럼 HTTP여서는 네트워크에 거쳐가는 무언가가 내 검색 등을 갈취해서 볼 수 있습니다.
네트워크 관리자, 인터넷 서비스 공급자(ISP)가 맘만 먹으면 사용자 검색 등을 조회해서 써먹을 수 있다는 말이 되지요.
그리고 이것은 네트워크를 장악한 나쁜 누군가가 볼 수도 있는 것입니다.

이 문제는 검색에만 국한되지 않습니다.
실제로 네이버는 이 글 작성 시점 기준으로 ME, 쪽지, 클라우드, 오피스, 가계부 등의 서비스에 HTTPS를 적용하지 않고 있습니다.
그마저도 적용되는 곳도 제각각이고 관리도 엉성합니다.
실제로 12월 17일에는 네이버 메일의 HTTPS 인증서 관리 문제로 네이버 메일이 마비되는 일도 있었습니다.
국내 점유율 1위인 네이버의 보안 관련 인식이 이러합니다.

**이런 국내 포털 사이트들을 믿고 써도 되는걸까요?**

## 둘째, HTTP 때문에 전기통신금융사기가 성행합니다.

HTTPS를 사용하면 사이트 주소 옆에 신뢰할 수 있는 사이트라는 마크가 붙습니다.
인증서에 투자를 한다면 브라우저에서 어느 회사가 어느 회사에게 인증서를 발급해줬는지까지 알 수 있습니다.
아주 단순히 국내 포털사이트들이 HTTPS를 적용하고 인증서 마크로 전기통신금융사기에 대한 홍보를 하는 것 만으로도 피싱, 공유기 해킹, 파밍 등의 여러 사기를 많이 줄일 수 있을 것입니다.
단순히 주소에 **HTTPS**가 들어있는지, 그리고 사이트에 들어갔을 때 신뢰할 수 있는 사이트라고 뜨는지만 확인해도 되니까요.
국내 포털 사이트들이 그걸 모를 리 없습니다.

저는 이걸 **방치**라고 생각합니다.

## 왜 안할까?

자, 포털사이트들 나름의 변명도 존재할 것입니다.
일단 HTTPS로 사이트를 처리하면 처리 부하가 증가합니다.
서브도메인을 왕창 써야하는 포탈 사이트라면 인증서 값도 만만치 않을 것입니다.
HTTPS를 도입한다고 해서 수익성이 증가되진 않을테니 투자할 이유가 없다는 것이겠죠.

결국 문제는 **돈**입니다.

## 어떻게 해야할까?

저는 HTTPS 무조건의무화에는 반대하는 입장입니다.
웹은 자유로워야 한다고 생각하고, 누구나 웹 사이트를 만들 수 있어야 한다고 생각하는데, HTTPS 인증서때문에 사이트를 만들 수 없다면 그건 웹의 방해요소라고 생각합니다.

저는 이 문제는 소비자 요구와 기업 윤리에서 해결봐야하지 않을까 생각합니다.
HTTPS가 도입된 사이트가 더 안전하며, 많은 국민들이 더 안전한 웹 서핑을 원한다는 소비자 요구가 먼저 있어야하며, 기업들이 이 요구에 윤리적으로 반응할 필요가 있다는 점이죠.

하지만 현실성이 없어보이는 것은 왜일까요.
이미 이 이야기가 수차례 누군가 말했었을 것 같고, 묻혀졌을 것 같다는 생각만 듭니다.

---

※ 국내 포털 사이트에 대한 다른 불만들은 다음 기회에 다른 글로 쓰겠습니다.


국내 포털 사이트에 대한 불평불만 1탄

item4 dev story

Posts