W' page

잠들기 전 10분 디지털 리셋: 내일 아침이 가벼워지는 현실 루틴

간즁 — Wed, 11 Feb 2026 21:34:59 +0900

하루를 바쁘게 보내고 침대에 누웠는데도 머리가 계속 복잡한 날이 있습니다.

특히 알림, 열린 탭, 답장 못 한 메시지가 남아 있으면 몸은 쉬어도 마음은 쉬지 못하죠.

오늘 소개하는 건 거창한 생산성 시스템이 아니라, **잠들기 전 단 10분**으로 끝내는 디지털 리셋 루틴입니다.

핵심은 “완벽하게 정리”가 아니라 **내일 아침의 시작 마찰을 줄이는 것**입니다.

#### 1) 알림 정리 (2분)

- 내일 아침까지 필요 없는 앱 알림은 잠시 끕니다.

- 긴급 연락이 필요한 채널만 예외로 남깁니다.

> 목표: 밤사이 불필요한 주의 분산 차단

#### 2) 열린 탭 3개만 남기기 (3분)

- 지금 당장 필요 없는 탭은 북마크 폴더(예: `read-later`)로 이동

- 내일 첫 작업에 필요한 탭만 3개 이내로 유지

> 목표: 내일 시작할 때 ‘무엇부터 하지?’ 고민 시간 제거

#### 3) 미답장 메시지 정리 (3분)

- 바로 답장 가능한 건 1줄이라도 처리

- 지금 답하기 어려운 건 “내일 처리” 목록으로 이동

> 목표: 미완료 불안감 감소 + 할 일의 위치 명확화

#### 4) 내일의 첫 행동 1개만 적기 (2분)

- 노트 앱/메모에 딱 한 줄 작성:

`내일 첫 행동: ________`

> 목표: 아침 의사결정 피로를 최소화

---

### 실패하지 않게 만드는 팁

- 루틴 시간을 **10분 타이머**로 고정하세요.

- “다 정리” 대신 “시작하기 쉽게 만들기”에만 집중하세요.

- 이 루틴은 매일 100점이 아니라, **주 4~5회 유지**만 해도 효과가 큽니다.

### 마무리

좋은 아침은 보통 아침에 만들어지지 않습니다.

전날 밤의 작은 정리가 다음 날의 집중력을 결정합니다.

**CTA:** 오늘 밤 10분만 타이머 맞추고 해보세요. 내일 아침 체감이 달라졌는지 기록해보면 훨씬 오래 갑니다.

MongoBooster

간즁 — Fri, 23 Dec 2016 16:06:06 +0900

# MongoDB GUI Tool - MongoBooster
> 2016.12.23

## 주요 특징
* 제한이 있긴 하지만 상업적 용도로 사용 가능!
  * [링크](https://mongobooster.com/downloads#whatarethelimitationsinthefreeunregisterededition) : 개인/상업 용도로 사용 가능하지만 일부 기능이 제한되어 있으며 또 일부 기능은 60일 뒤 사용할 수 없음
* CLI 명령 가능
* Javascript 유저에게 더 강력한 CLI 문법
  * ES6 문법과 db 쿼리를 섞어서 쓸 수 있다.
  * Lodash, ShellJs, Mathjs and Moment 라이브러리가 기본 내장되어 있다.
    * 각각 `_`, `shelljs`, `math`, `moment` 변수로 사용할 수 있다.
  * Example (의미 없는 코드이다...)
  ```
  const arr = [];
  db.test.find({}, {_id: 1}).forEach(doc => arr.push(doc._id));
  _.times(3, idx => console.log(`${++idx}'t result : ${arr.length}`));
  ```

## 기타 툴
* CLI 명령이 필요 없다면 [MongoHub](https://github.com/jeromelebel/MongoHub-Mac) 추천!

Tistory 에서 Markdown 문법으로 글 쓰기

간즁 — Wed, 21 Dec 2016 17:12:50 +0900

# Tistory 에서 Markdown 문법으로 글 쓰기
> 2016.12.21
> 참조 : [링크](https://github.com/devxoul/TistoryMarkdown)
> README.md 를 복붙 했습니다.
> `\` 문자열은 알아서 센스있게 빼 주시길...

## 설치법
1. 티스토리 관리 페이지로 이동 후 HTML/CSS 편집 메뉴로 이동하여 '파일업로드'' 탭을 선택합니다.
1. [추가] 버튼을 눌러 `tistory-markdown-min.js` 파일 업로드합니다.
1. 'HTML/CSS' 탭으로 이동하여, `<\/body>` 태그의 바로 윗부분에 아래의 코드를 추가합니다.

  ```
  <스크립트 src="./images/tistory-markdown-min.js"><\/스크립트>
  <스크립트>markdown();<\/스크립트>
  ```

## 사용법
1. 글쓰기 화면에서 HTML모드로 전환 후 Markdown을 사용할 부분을 `` 태그와 `` 태그로 감쌉니다.
1. [저장] 버튼을 눌러 글 작성을 완료하면 자동으로 Markdown으로 번역됩니다.

## 안예쁜데 왜 쓰나?
1. 앞으로 별 일이 없는 한 Markdown 문법을 계속해서 사용 할 예정
1. Tistory 는 `나`를 위한 공간
1. 앞으로 시간 나면 [링크](http://blog.saltfactory.net/note/renewal-blog-from-tistory-to-github-pages-via-jekyll.html) 처럼 바꾸거나 더 좋은 방법을 고민 할 예정

Xcode 8 에 Vim 단축키 적용하기

간즁 — Wed, 21 Dec 2016 17:00:27 +0900

# Xcode 8 에 Vim 단축키 적용하기
> 2016.12.21
> MacOS

1. Xcode 종료
1. [링크](https://github.com/XVimProject/XVim/blob/master/INSTALL_Xcode8.md) 작업 수행
  1. Xcode 8 의 경우에만 수행합니다.
  1. 키체인 접근 실행
  1. 메뉴의 키체인 접근 - 인증서 지원 - 인증서 생성
    1. 이름 : XcodeSigner
    1. 신원 유형 : 자체 서명 루트
    1. 인증서 유형 : 코드 서명
  1. `sudo codesign -f -s XcodeSigner /Applications/Xcode.app`
1. [링크](https://github.com/XVimProject/XVim) 작업 수행
  1. Repository Clone
    ```
    mac $ git clone https://github.com/XVimProject/XVim.git
    mac $ cd XVim
    ```
  1. 출력되는 내용 확인
    ```
    mac $ xcode-select -p
    /Applications/Xcode.app/Contents/Developer
    ```
    * 만약 안나오면 `xcode-select -s` 수행 후 확인
  1. 설치
    ```
    mac $ make
    ```
    * 이 때 `y` 를 꼭 해줘야 한다.
1. Xcode 실행
  * `Load Bundle`
1. (Options) 삭제
  1. git clone 된 디렉터리 이동
    * `make uninstall`

JMeter 에서 csv 사용하기

간즁 — Wed, 21 Dec 2016 16:39:22 +0900

# JMeter 에서 csv 사용하기
> 2016.12.21

## CSV 이용 방법
* Add - Config Element - CSV Data Set Config
* Filename : 파일 경로
* Variable Names : ${변수명} 처럼 사용하기 위해 사용 할 변수명 설정
* 나머진 기본값

JMeter 소개 및 설치

간즁 — Wed, 21 Dec 2016 16:37:58 +0900

# JMeter 소개 및 설치

> 2016.12.21
> MacOS 기준

## JMeter?
* 가장 범용적으로(?) 사용 되는 부하테스트 툴
* Java로 만들어졌으며 Apache 재단에서 관리된다. [링크](http://jmeter.apache.org/)

## JMeter 설치
* [링크](http://jmeter.apache.org/download_jmeter.cgi) 에서 다운로드
* 적당한 곳에 압축 풀고 압축 푼 디렉터리에서 `java -jar ./bin/ApacheJMeter.jar` 명령어로 JMeter 실행

## JMeter 기본 설정
* Thread Group 추가
	* Number of Threads : user 수
	* Ramp-Up Period : Thread 를 몇초 만에 모두 띄울 것인가
	* Loop Count : Loop 돌릴 횟수
* 필요한 로직을 Thread Group 밑에 구현
* 결과 출력
	* Add - Listner
		* View Results Tree / View Results in Table / Response Time Graph 추가

나의 sublime text3 javascript 설정

간즁 — Sun, 13 Dec 2015 00:26:51 +0900

기본 환경 설정은 아래의 다른 sublime 설정을 따르고 추가적인 설정을 진행

출처 : http://www.sitepoint.com/essential-sublime-text-javascript-plugins/

Control + Shift + P 로 팔렛트를 띄워 Package Controll Install 에서 아래의 것들을 설치한다.

1. Babel : JS Syntax

2. JSHint (& JSHint Gutter) : Alt + J 를 누르면 신택스 오류 띄워줌

아래와 같이 Set Linting Preferences 설정

{

"node": true,

"camelcase": true,

"eqeqeq": true,

"esnext": true,

"globals": {},

"globalstrict": true,

"quotmark": true,

"undef": true,

"unused": true,

"esnext": true,

"quotmark": "single"

}

3. DocBlockr : /** 엔터 누르면 jsdoc 쓸 수 있게 해줌

4. JSFormat : 아직은 뭐가 좋은지 잘 모르겠다.

RESTful 및 HTTP 상태 코드

간즁 — Tue, 20 Oct 2015 12:49:56 +0900

출처 :

http://blog.remotty.com/blog/2014/01/28/lets-study-rest/

https://ko.wikipedia.org/wiki/REST

https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C

1. RESTful 이란?

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.

REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.

2. URI 설계

- URI(Uniform Resource Identifier) : '균등한 리소스 식별자'

a - http://abc.com/haha

b - HTTP://ABC.COM/haha

c - http://abc.com/HAHA

d - http://abc.com/hAhA

-> where, a == b && c != d

- 하이픈(-, hyphen)을 사용하자

공백 대신 %20 이 쓰을 수 있으며, _ 는 링크가 걸릴 때 생기는 밑줄에 가려질 수 있다.

- 확장자를 사용하지 말자

Accept의 헤드를 적극적으로 활용하여

GET /hello HTTP/1.1

Host: remotty.com

Accept: text/csv,text/html;q=0.5,application/xml;q=0.6,text/plain;q=0.9,application/pdf,*/*;q=0.3

처럼 사용하자. 앞 부터 우선순위다.

3. HTTP Method의 알맞은 역할

HTTP Method는 여러가지가 있지만 REST API에서는 4개 혹은 5개의 Method만 사용됩니다. POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있습니다. 그러나 REST API에서 사용되는 개수는 4개 혹은 5개라고 한 이유는 PATCH를 포함하면 5개가 됩니다.

POST : 현재 리소스 보다 한단계 아래에 리소스를 생성

GET : 현재 리소스를 조회

PUT : 현재 리소스를 수정

DELETE : 현재 리소스를 삭

※ PATCH : 기존에는 수정(update)을 위한 Method로 주로 PUT을 사용했지만, 앞으로는 PUT대신 PATCH를 자주 쓰일 수 있다. 자세한 설명 - http://weblog.rubyonrails.org/2012/2/26/edge-rails-patch-is-the-new-primary-http-method-for-updates/

4. 반응형 웹에서의 REST

http://m.remotty.com/abc 또는 http://www.remotty.com/m/abc처럼 사용하지 말자.

RESTFul한 웹사이트에서는 User-Agent를 이용하여 다른 곳으로 리다이렉트 시켜주는게 아니라 URI는 그대로이지만 화면만 장비에따라 알아서 최적화 되도록 설계해야 한다.

5. I18n과 REST

다국어 지원을 Accept-Language에 맡긴다면 URI는 그대로인데, 사용자의 환경에 따라 알맞은 언어로 응답할 수 있다. 사용자가 원하는 언어를 설정하게하여 해당 언어를 세션 또는 쿠키 등에 저장하여 보여줄 언어를 선정할때 우선순위를 약간 조정하여 보여주는게 좋다.

6. HTTP 상태 코드

- 1xx (조건부 응답)

요청을 받았으며 작업을 계속한다. 이 상태의 상태 코드는 상태-라인과 선택적 헤더(컴퓨터에서 출력될 때 각 페이지 맨 윗부분에 자동으로 붙는 부분)만을 포함하는 임시의 응답을 나타내고 빈 라인에 의해서 종결된다. HTTP/1.0이래로 어떤 1XX 상태 코드들도 정의 되지 않았다. 서버들은 1XX 응답을 실험적인 상태를 제외하고 HTTP/1.0 클라이언트(서버에 연결된 컴퓨터)로 보내면 안 된다.

100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.

101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.

102(처리, RFC 2518)

- 2xx (성공)

이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.

200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.

201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.

202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.

203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.

204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.

205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).

206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.

207(다중 상태, RFC 4918)

208(이미 보고됨, RFC 5842)

226 IM Used (RFC 3229)

-3xx (리다이렉션 완료)

클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.

300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.

301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.

302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.

303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.

304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.

305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.

307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.

308(영구 리다이렉션, RFC에서 실험적으로 승인됨)

-4xx (요청 오류)

4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.

400(잘못된 요청) : 서버가 요청의 구문을 인식하지 못했다.

401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다.

403(금지됨): 서버가 요청을 거부하고 있다.

404(찾을 수 없음): 서버가 요청한 페이지를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.

405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다.

406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.

407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.

408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.

409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.

410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.

411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.

412(사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.

413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.

414(요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.

415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.

416(처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.

417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.

418(I'm a teapot, RFC 2324)

420(Enhance Your Calm, 트위터)

422(처리할 수 없는 엔티티, WebDAV; RFC 4918)

423(잠김,WebDAV; RFC 4918)

424(실패된 의존성, WebDAV; RFC 4918)

424(메쏘드 실패, WebDAV)

425(정렬되지 않은 컬렉션, 인터넷 초안)

426(업그레이드 필요, RFC 2817)

428(전제조건 필요, RFC 6585)

429(너무 많은 요청, RFC 6585)

431(요청 헤더 필드가 너무 큼, RFC 6585)

444(응답 없음, Nginx)

449(다시 시도, 마이크로소프트)

450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트)

451(법적인 이유로 이용 불가, 인터넷 초안)

451(리다이렉션, 마이크로소프트)

494(요청 헤더가 너무 큼, Nginx)

495(Cert 오류, Nginx)

496(Cert 없음, Nginx)

497(HTTP to HTTPS, Nginx)

499(클라이언트가 요청을 닫음, Nginx)

- 5xx (서버 오류)

서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.

501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.

502(불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.

503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.

504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.

505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.

506(Variant Also Negotiates, RFC 2295)

507(용량 부족, WebDAV; RFC 4918)

508(루프 감지됨, WebDAV; RFC 5842)

509(대역폭 제한 초과, Apache bw/limited extension)

510(확장되지 않음, RFC 2774)

511(네트워크 인증 필요, RFC 6585)

598(네트워크 읽기 시간초과 오류, 알 수 없음)

599(네트워크 연결 시간초과 오류, 알 수 없음)

Git 명령어 정리

간즁 — Sun, 18 Oct 2015 14:27:46 +0900

GUI가 편하긴 하지만 내가 원하는 기능을 찾기 위해 이리저리 클릭을 해야 할 경우가 있다.

그럴 경우엔 차라리 명령어로 처리하는 것이 간편하다.

Commit

// If multiple -m options are given, their values are concatenated as separate paragraphs.

$ cd $GitRepoDIR

$ git commit -m "COMMIT_MESSAGE"

Push

$ cd $GitRepoDIR

$ git remote add origin https://github.com/kanziwoong/NEW_REPOSITORY_NAME.git

$ git push -u origin master

Pull

$ cd $GitRepoDIR

$ git pull

Create a new repository on the command line

$ cd $GitRepoDIR

$ echo # NEW_REPOSITORY_NAME >> README.md

$ git init

$ git add README.md

$ git commit -m "first commit"

$ git remote add origin https://github.com/kanziwoong/NEW_REPOSITORY_NAME.git

$ git push -u origin master

리눅스에서 여러 파일의 내용 한꺼번에 수정하기

간즁 — Sat, 17 Oct 2015 20:52:55 +0900

find 명령어로 조건에 해당하는 파일을 검색한 뒤

sed 명령어로 각 파일들에 대해 수정을 진행하면 된다.

ex) 현재 디렉터리의 모든 일반파일에 대해 ORG_STR -> NEW_STR

$ find . -type f -exec sed -i 's/ORG_STR/NEW_STR/g' {} \;