Grafana Loki는 로그 집계 도구이며 모든 기능을 갖춘 로깅 스택의 핵심이다. 

Loki는 로그 데이터를 효율적으로 보관하도록 최적화된 데이터 저장소이다. 로그 데이터의 효율적인 인덱싱은 Loki를 다른 로깅 시스템과 구별한다. 다른 로깅 시스템과 달리 Loki 인덱스는 레이블로 만들어지며 원래 로그 메시지는 인덱싱 되지 않는다. 

에이전트(클라이언트)는 로그를 수집하고, 로그를 스트림(Stream)으로 변환하고 HTTP API를 통해 스트림을 Loki에 푸시(Push)한다. Promtail 에이전트가 Loki 설치용으로 설계되긴 했지만 다른 많은 에이전트들도 Loki와 원활하게 통합된다.

Loki는 스트림(Stream)을 색인화(indexing)한다. 각 스트림은 고유한 레이블 집합과 연결된 로그 집합을 식별한다. 좋은 레이블 집합은 간결하고 효율적인 쿼리 실행을 허용하는 인덱스 생성의 핵심이다. 

LogQL은 Loki의 쿼리 언어이다.

Loki 특징

로그를 인덱싱할 때 효율적인 메모리 사용 - 라벨 셋으로 인덱싱해서 다른 로그 집계 제품보다 인덱스가 상당히 작다. 동작할 때 메모리를 덜 쓴다.

멀티 테넌시(Multi-Tenancy) - Loki 사용 시 여러 테넌트가 단일 Loki 인스턴스를 활용할 수 있다. 개별 테넌트의 데이터는 다른 테넌트와 완전히 격리된다. 멀티 테넌시는 에이전트에서 테넌트 ID를 할당하여 구성된다.

LogQL, Loki의 쿼리 언어 - Prometheus 쿼리 언어인 PromQL 사용자는 LogQL을 통한 로그에 대한 쿼리 생성에 금방 적응할 수 있다. 이 언어는 로그 집계를 훨씬 능가하는 강력한 기능인 로그 데이터에 메트릭 생성을 용이하게 한다.

확장성(Scalability) - Loki는 단일 바이너리로 실행할 수 있다. 모든 구성 요소는 하나의 프로세스에서 실행된다. Loki는 Loki의 각 구성요소를 마이크로 서비스로 실행할 수 있으므로 확장성을 위해 설계되었다. Configuration을 통해 마이크로 서비스를 개별적으로 확장할 수 있으므로 유연한 대규모 설치가 가능하다.

유연성(Flexibility) - 많은 에이전트(클라이언트)가 플러그인을 지원한다. 이를 통해 현재 observability 구조는 Observability Stack의 기존 부분을 바꿀 필요 없이 Loki를 로그 집계 도구로 추가할 수 있다.

그라파나 통합 - Loki는 그라파나와 원활하게 통합되어 완전한 observability stack을 제공한다. 

다른 로그 시스템과 비교해 본 Loki

Grafana Loki / Promtail/Grafana vs EFK

EFK (Elasticsearch, Fluentd, Kibana) 스택은 다양한 리소스의 로그를 ingest(정제), visualize(시각화), query(쿼리)하는 데에 쓰인다. Elasticsearch의 데이터는 구조가 없는 JSON 오브젝트로 디스크에 저장된다. 각 오브젝트의 key들과 각 key의 내용은 색인된다. 데이터는 JSON 오브젝트를 사용해서 쿼리를 정의하거나 Lucene 쿼리 언어를 통해 쿼리될 수 있다. 

그와 비교해서, 싱글 바이너리 모드인 그라파나 로키는 디스크에 데이터를 저장할 수 있지만 수평적으로 늘어날 수 있는 모드(horizontally-scalable) 데이터는 클라우드 스토리지 시스템에 저장된다. S3, GCS, Cassandra와 같은. 로그는 레이블 쌍만 인덱싱되는 레이블 이름 및 값 세트로 태그가 지정된 일반 텍스트 형식으로 저장된다. 이 절충안으로 인해 전체 인덱스보다 운영 비용이 저렴하고 개발자가 애플리케이션에서 적극적으로 로그를 남길 수 있다. Loki의 로그는 LogQL을 사용하여 쿼리된다. 그러나 이런 설계 절충으로 콘텐츠(로그 내 텍스트)를 기반으로 필터링하는 LogQL 쿼리는 쿼리에 정의된 레이블과 일치하는 검색 창 내의 모든 청크를 로드해야 한다. 

Fluentd는 일반적으로 로그를 수집하고 Elasticsearch로 전달하는 데 사용된다. Fluentd는 많은 소스에서 로그를 수집하고 처리하고 하나 이상의 대상에 전달할 수 있는 데이터 수집기이다. 이에 비해 Promtail의 사용 사례는 특히 Loki에 맞춰져 있다. 주요 작동 모드는 디스크에 저장된 로그 파일을 발견하고 이를 레이블 세트와 연관된 로그 파일로 Loki에 전달한다. Promtail은 Promtail과 동일한 노드에서 실행되는 kubernetes 파드에 대한 서비스 검색(service discovery)을 수행하거나 컨텡너 사이드카 또는 Docker 로깅 드라이버로 작동하거나 지정된 폴더에서 로그를 읽고 systemd journal에 tail을 붙일 수 있다. 

Loki가 레이블 쌍으로 로그를 나타내는 방식은 Prometheus가 메트릭을 나타내는 방식과 유사하다. Prometheus와 함께 환경에 배포할 때 Promtail의 로그는 동일한 서비스 검색 메커니즘을 사용하기 때문에 일반적으로 애플리케이션 메트릭과 동일한 레이블을 가진다. 동일한 레이블의 로그와 메트릭을 사용하면 사용자가 메트릭과 로그 간의 컨텍스트 전환을 원활하게 수행할 수 있으므로 근본 원인 분석에 도움이 된다.

Kibana는 Elasticsearch 데이터를 시각화하고 검색하는 데 사용되며 해당 데이터에 대한 분석을 수행하는 데 매우 강력하다. Kibana는 위치 지도, 이상 감지를 위한 머신 러닝, 데이터의 관계를 발견하기 위한 그래프와 같은 데이터 분석을 수행하는 많은 시각화 도구를 제공한다. 예기치 않은 상황이 발생하면 사용자에게 알리도록 Alert을 구성할 수 있다.

이에 비해 그라파나는 Prometheus 및 Loki와 같은 소스의 시계열 데이터에 맞게 특별히 조정되었다. 메트릭을 시각화하도록 대시보드를 설정할 수 있으며 (곧 로그 지원 예정) explore view로 데이터에 대한 임시 쿼리를 만들 수 있다. Kibana와 마찬가지로 Grafana는 메트릭을 기반으로 한 Alert을 지원한다.

그라파나 로키의 구조

Multi-tenancy

메모리와 장기 스토리지의 모든 데이터는 Grafana Loki가 다중 테넌트 모드에서 실행 중일 때, 요청의 X-Scope-OrgID HTTP 헤더에서 가져온 테넌트 ID로 분할될 수 있다. Loki가 다중 테넌트 모드에 있지 않으면 헤더가 무시되고 테넌트 ID가 인덱스와 저장된 청크에 가짜(Fake)로 설정된다.

Chunk format

-------------------------------------------------------------------
  |                               |                                 |
  |        MagicNumber(4b)        |           version(1b)           |
  |                               |                                 |
  -------------------------------------------------------------------
  |         block-1 bytes         |          checksum (4b)          |
  -------------------------------------------------------------------
  |         block-2 bytes         |          checksum (4b)          |
  -------------------------------------------------------------------
  |         block-n bytes         |          checksum (4b)          |
  -------------------------------------------------------------------
  |                        #blocks (uvarint)                        |
  -------------------------------------------------------------------
  | #entries(uvarint) | mint, maxt (varint) | offset, len (uvarint) |
  -------------------------------------------------------------------
  | #entries(uvarint) | mint, maxt (varint) | offset, len (uvarint) |
  -------------------------------------------------------------------
  | #entries(uvarint) | mint, maxt (varint) | offset, len (uvarint) |
  -------------------------------------------------------------------
  | #entries(uvarint) | mint, maxt (varint) | offset, len (uvarint) |
  -------------------------------------------------------------------
  |                      checksum(from #blocks)                     |
  -------------------------------------------------------------------
  |                    #blocks section byte offset                  |
  -------------------------------------------------------------------

mint와 maxt는 유닉스 나노초 타임스탬프의 최소와 최대를 각각 표시한 것이다.

Block Format

블록은 entries 시리즈로 구성되어 있다. entries 시리즈 각각은 개별적인 로그 라인이다.

수 bytes의 블록은 Gzip을 사용해서 압축되어 저장된다. 아래 형식은 압축되지 않았을 때이다.

 -------------------------------------------------------------------
  |    ts (varint)    |     len (uvarint)    |     log-1 bytes      |
  -------------------------------------------------------------------
  |    ts (varint)    |     len (uvarint)    |     log-2 bytes      |
  -------------------------------------------------------------------
  |    ts (varint)    |     len (uvarint)    |     log-3 bytes      |
  -------------------------------------------------------------------
  |    ts (varint)    |     len (uvarint)    |     log-n bytes      |
  -------------------------------------------------------------------

ts는 로그의 유닉스 나노초 타임스탬프이다. len은 수 bytes의 로그 entry 길이이다.

스토리지 (Storage)

Single Store

로키는 싱글 오브젝트 스토리지 백엔드에서 모든 데이터를 저장한다. 이 작동 모드는 일반적으로 loki 2.0에서 이용가능했고, 빠르고 비용 절감하고 단순하지만 모든 현재와 미래 개발사항에서 언급되지 않는다. 이 모드는 오브젝트 스토리지에 인덱스를 저장하기 위해 boltdb_shipper 라는 어댑터를 사용한다. (같은 방식으로 우리는 청크(chunk)를 저장한다)

Deprecated: Multi Store

청크 스토어는 백그라운드 유지 관리 작업 없이 대화형 쿼리 및 지속적인 쓰기를 지원하도록 설계된 Loki의 장기 데이터 저장소이다. 

청크에 대한 인덱스. 이 인덱스는 다음으로 뒷받침 됩니다.

Amazon DynamoDB

Google Bigtable

Apache Cassandra

다음과 같은 청크 데이터 자체에 대한 키-값(KV) 저장소:

• Amazon DynamoDB
• Google Bigtable
• Apache Cassandra
• Amazon S3
• Google Cloud Storage

Loki의 다른 핵심 구성 요소와 달리 청크 저장소는 별도의 서비스, 작업 또는 프로세스가 아니라, Loki 데이터에 액세스해야 하는 정제(Ingester) 및 쿼리(querier) 서비스에 포함된 라이브러리이다.

청크 저장소는 청크 저장소 인덱스를 지원하는 데 사용할 수 있는 NoSQL 저장소(DynamoDB, Bigtable, Cassandra)에 대한 통합 인터페이스에 의존한다. 이 인터페이스는 인덱스가 키(key)가 지정된 항목(entries) 모음이라고 가정한다. \

Hash Key : 모든 reads, writes를 요구한다.

Range Key (범위 키) : 쓰기(writes)에 필요하고 읽기(reads)에는 생략할 수 있으며 접두사(prefix) 또는 범위로 쿼리할 수 있음

이 인터페이스는 지원되는 데이터베이스에서 약간 다르게 작동한다.

DynamoDB는 기본적으로 범위 및 해시 키를 지원한다. 따라서 인덱스 항목은 다이나모디비 항목으로 직접 모델링되며 해시 키는 배포 키로, 범위는 다이나모디비 범위 키로 사용된다. Bigtable 및 Cassandra의 경우 인덱스 항목(entries)은 개별 열 값으로 모델링된다. 해시 키가 행 키가 되고 범위 키가 열 키가 된다. 

스키마 세트는 청크 저장소에 대한 읽기 및 쓰기에 사용되는 일치자(matcher)와 레이블 세트를 인덱스의 적절한 작업에 매핑하는 데 사용된다. Loki가 발전함에 따라 주로 쓰기 로드 균형을 개선하고 쿼리 성능을 개선하기 위해 스키마가 추가되었다.

Read Path

읽기 경로는 다음과 같이 동작한다.

1. querier는 데이터에 대한 HTTP/1 요청을 받는다. 

2. querier(쿼리자)는 메모리 내 데이터에 대해 쿼리를 모든 ingester에 전달한다.

3. ingester(수집기)는 읽기 요청을 수신하고 쿼리와 일치하는 데이터를 반환한다.(있는 경우)

4. querier는 백업 저장소에서 데이터를 느리게 로드하고 반환된 ingester가 없으면 이에 대해 쿼리를 실행한다.

5. querier는 수신된 모든 데이터를 반복하고 중복을 제거하여 HTTP/1 연결을 통해 최종 데이터 세트를 반환한다.

Write Path

쓰기 경로는 다음처럼 동작한다.

1. distributor는 스트림에 대한 데이터를 저장하라는 HTTP/1 요청을 수신한다.

2.  각 스트림은 해시 링(Hash Ring)을 사용해서 해시된다.

3. distributor는 각 스트림을 적절한 ingester 및 해당 복제본(replica)- 구성된 복제요소 기반-로 보낸다.

4. 각 ingester(수집기)는 스트림 데이터에 대해 청크를 생성하거나 기존 청크에 추가한다. 청크는 테넌트 및 레이블 세트 별로 고유하다.

5. distributor는 HTTP/1 연결을 통해 성공 코드로 응답한다.

정리하면서도 뭔 소리인지 몰랐는데 그림 보니까 동일한 라벨 키,값을 가지는 경우에는 로그 엔트리(로그 줄)이 하나의 청크에 저장되고, 그 청크가 꽉 차면 압축되어 저장된다. 나눠진 작은 인덱스는 청크를 찾기 위해 유지된다. 다른 라벨 키와 값은 다른 스트림(구별되게 하는 해시 키)과 청크에 저장된다. 라벨 키 값을 하나의 해시 키로 만들어서 위치 키로 놔두고, 로그 내용은 위치 키로 지정된 청크 안에 저장하는 원리.

Deployment 모드 https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/

이어서 번역할 것..

며칠 간 괜한 재채기를 할 때도 있었고 남들보다 좀 더 더워했다. 처서가 가까워져 새벽엔 싸늘해서 남편은 추워했는데 나만 더웠다. 배란기라 그런가. 비염이 있지만 평소보다 콧물도 더 있는 것 같고. 환절기가 다가와서 그런 거려니 생각했다.

주변 팀원들이 차례로 확진될 때마다 몇 번이고 신속항원검사를 해왔지만 맨날 꽝이었다. 팀 내에서 슈퍼면역자로 불렸다.

집에 있는 걸 좋아해서 회사 갈 때 빼고 거의 집에 있는데, 남편이 영화 보는 걸 좋아해서 어제 저녁에 한산을 보러 다녀왔다. 영화관에 우리 포함 7명 정도가 있었는데, 서로 둘 셋씩 멀리 떨어져 있었다. 앞 사람들이 마스크를 안 썼던 것 같긴 하다. 사람 별로 없는 영화관은 추워서 오들오들 남편한테 딱 붙어서 영화를 봐야했다. 나올 때 목이 거칠거칠 따끔거렸다.

1일차

자고 일어나니 몸이 물 먹은 솜처럼 무거웠다. 평소에 무겁던 것보다 더 무거운 느낌이었다. 어제 저녁에 폭식도 안 했는데. 내가 상태가 좀 이상해보이는 걸 보고 남편이 체온계로 내 체온을 쟀다. 37.1도. 이상하다고 보기엔 애매했다. 이틀만 근무하면 주말이니까 움직여지지 않는 몸을 이끌고 출근했다. 목이 간질간질해서 기침이 났고, 열도 나고 몸의 근육을 움직일 때마다 버거웠다. 목에 모래가 낀듯 타는듯한 목마름이 제일 괴로웠다. 옆자리의 팀원에게 확진 때 증상이 어땠냐고 물어보니 내 증상과 완벽히 일치했다. 다음주에 휴가가 잡혀 있어 확진되면 안 되는데 하면서 내과 병원 가서 신속항원검사를 받았는데, 음성 때와는 달리 웬일로 금방 나를 불러서 양성인 걸 눈치챘다. 호텔 숙박 취소, 약속 다 취소하면서 주변에 알렸다. 이번달에 임신 가능성이 있을지도 모른다고 하자, 의사가 그러면 타이레놀 빼고 약을 지어줄 수 없다고 했다. 산부인과 가서 약을 따로 받아서 먹으라고 했다.

회사로 돌아가서 가방을 챙겨서 얼른 나오고 집으로 돌아가면서 회사에 감염병 신고를 하고 지역 보건소에 전화해서 비대면 진료가 가능한 산부인과 전화번호 받아서 의사에게 처방 받고 처방전은 팩스로 받았다. 남편 직장으로 보내게 해서 남편더러 약을 받아오게 부탁했다. 산부인과 의사가 아직 임신이 확인되지 않은 상태라서 약을 먹어도 된다고 했던 것 같다. 항생제까지도 처방 받았다.

--격리 시작--

집에 가자마자 내가 있을 장소를 정하고 그 동선으로만 다녔다. 돌아다닐 땐 몰랐는데 집에 가니까 너무 열이 많이 나서 머리가 지끈거렸다. 가방 내려놓고 바로 미지근한 물로 물샤워를 했다. 상시 데워놓는 루이보스, 카모마일 차를 60도로 설정해두고 계속 마셨다. 1리터씩 계속 추가해가면서. 정확한 횟수는 기억 안 나는데 3-4번째부터는 너무 묽어지니 보리차를 넣어서 마셨다. 누워있다가 목 마르면 물 마시고 화장실 갔다가 물 샤워해서 온도 떨구고 물 마시고 눕고 그렇게 쉬다가 화장실 갔다가 물 마시고 눕고 계속 반복이었다. 너무 물을 많이 마셔서 잠이 안 왔다. 좀 쉴만 하면 화장실이 가고 싶으니 억지로 안 움직여지는 몸을 움직였다. 약 안 먹고 그러고 있다가 점심 때 되어서 남편이 밥 먹고 약 먹으라고 약을 놓고 갔다. 반찬 1가지에 밥 먹고 약 먹었다. 열이 많이 나는지 이마가 지끈거렸다. 타이레놀(해열제)를 빼먹고 다른 약만 먹었더니 체온이 38도를 넘어갔다. 선풍기를 약하게 틀고 물샤워를 몇 번이고 하면서 물 계속 마시고 계속 화장실을 들락거렸다. 하루종일 집에 혼자 있으니 말 거는 사람도 없어서 목이 아프지도 않았다. 가끔 기침을 할 때 죽을 사람처럼 가래기침을 했다.

계속 쉬지 않고 물 마시고 눕고 화장실 가고 물 마시고 반복했다. 이미 확진되었다가 격리 풀린 지 10일 된 동생에게 연락해서 열 떨어뜨리는 방법과 가래 기침 대응방법을 물어봤다. 젖은 수건으로 몸 닦아주는 거랑 샤워하면 열 떨어진다고 하고, 가래 기침은 굵은 소금을 진하게 물에 타서 가글하면 효과적이라고 한다. 그래서 저녁 먹고 해열제랑 같이 약 챙겨먹고 양치하고 소금을 물에 엄청 타서 그걸로 가글했다. 그랬더니 온갖 콧물과 가래가 나오는 것 같았다. 다 빼고 난 뒤, 물을 엄청 마시고, 누웠다. 호흡도 편안하고 살 것 같았다. 체온이 38.6도여서 이마에 젖은 수건을 올려서 열을 빼고 나니 잠도 잘 왔다. 젖은 수건을 이마에 올리면 몸은 추운데 머리가 덜 아프다. 목 상태도 많이 호전되었다. 새벽에 2-3시간마다 깨서 화장실 가고 물세수하고 따뜻한 물을 마셨다. 너무 얼굴이 뜨거우면 젖은 수건을 다시 올렸다. 그리고 중간 중간 에어컨을 틀었다가 껐고 선풍기를 약하게 틀어놔서 열을 내렸다.

2일차

아침에 일어나니까 상태가 많이 괜찮아졌다. 밤새 물 마시고 화장실 간 보람이 있는지 가래도 거의 느껴지지 않았다. 아침에 체온을 재보니 38.4도 였다. 일어나자마자 화장실 갔다가 물세수를 하고 물을 또 마셨다. 아침 먹고 약 먹고 1시간 정도 한숨 잤다. 땀을 흘리면서. 말을 거의 안 해야 회복이 빠르다고 해서 묵언 수행 중이다. 그럼 다시 물 마시고 화장실 가는 루틴을 반복하러 가야겠다.

피드백 받은 대로 성과 평가를 마무리해서 올렸다. 하던 업무가 마무리 되어서 새로운 업무인 기획에 매진해야 하는데 마인드 마스터로 물고기뼈를 하루종일 들여다 보고, 가지고 있는 기획 관련 책 중 4권을 골라서 대충 훑어봤는데 별 소득이 없었다. 근무 시간 중엔 뭘 그리는 것도 어려울 것 같아서 그냥 기획 책을 접었다. 머리가 멍해졌다. 익숙하지 않은 프레임에 뭔가를 채워넣기 보다는 내가 주로 하던 방식으로 그려놓고 정리한 다음, 물고기 뼈에 내용을 채우는 게 더 빠를 것 같다는 생각이 들었다. 그런 생각이 들었을 땐 이미 퇴근 시간이 지난 뒤였다. 일단 퇴근하고 가지고 있던 기획 책을 모조리 꺼내서 목차 훑고 대충 빠르게 넘겨보다가 실마리를 찾았다. 나는 아이디어가 바로 나오는 게 아니라 여러 책 보고 자료를 다 수집한 다음, 다른 일을 하다가 갑자기 아이디어가 번뜩이는 타입이니 일단 생각을 묵혀야겠다. 계속 생각하고 있다가 주말에 생각나는 키워드를 모두 적어보는 걸로 결론을 냈다.

리얼포스 30g 저소음 APC 맥 버전 화이트를 구매해서 윈도우즈 환경에서 몇 달 간 사용했는데 한영 키 위치가 달라서 엄청 애먹었다. 적응하는 것도 쉽지 않았는데, 몇 달 써서 적응하자 회사 회의실에서 타자를 칠 때 한영 키 바꿀 때마다 엄청 버벅거렸다. 가뜩이나 타자가 그렇게 빠른 편도 아닌데 그런 현상이 나타나서 또 큰 맘 먹고 리얼포스 차등 저소음 블랙을 구매해서 블로그 글을 작성 중인데, 30g 맥 버전에 적응했는지 계속 오른쪽 윈도우즈 키를 누른다. 처음에는 알파벳만 써있는 키보드에 적응하는 것도 어려웠는데 이제는 거의 안 보고 치는 것 같다.

리얼포스 사용하기 전 2013년 맥 키보드의 쫀득한 느낌이 좋아서 비슷한 키보드를 찾느라 i-rocks에서 나오는 얇은 키보드를 선호했다. 얇은 키보드는 누르는 거리가 매우 짧아서 손가락에 부담이 없었다. 그래도 보고서 작성하려고 타자를 오래 치면 손목이 아파왔다. 그래서 나름 5-6만원대 키보드를 찾았는데 세게 쳐도 이동거리가 짧지만, 키 간 거리가 있어서 손가락이 작은 나에겐 피로감이 컸다.

그래서 일단 리얼포스 키보드를 사려고 리더스키를 봤는데 다 품절이었다. 좀 지켜보다가 재고 풀린 키보드를 구매했는데, 그것이 바로 저소음 30g 맥 버전 화이트!

기계식 키보드를 리얼포스로 입문해서 처음 일주일은 손목 근처 근육이 아팠다. 높이가 높은 키보드를 쓰는 것이 처음이었기 때문에 안 쓰는 근육을 쓰는 느낌이었다. 그래도 나름 적응하고 수건도 갖다 대고 해서 지금은 아무렇지도 않다. 힘을 거의 들이지 않고 날아다니는 듯한 구름 타법을 구사하면 몽글몽글 구름 같은 소리도 좋다. 특히 키보드를 칠 때 끝에서 올라오는 반발력 같은 것도 거의 없다. 손가락에 무리도 없다. 단점은 너무 부드럽게 쳐서 그런지 오타가 많이 난다는 것이다. 한 문장 당 오타 한 번은 나타날 수 있다. 구분감이 약하고 살짝만 눌러도 인식이 되기 때문에 나도 모르게 한 키를 누르고 있는 경우도 며칠에 한 번은 나타난다. 타자를 안 칠 때 손을 아예 키보드에서 떼는 게 습관이 되면 괜찮다. 그래도 오래 글을 쓸 때 손목에 하나도 무리가 안 간다. 게임할 때 최고다. 물론 정확한 컨트롤로 게임해야하는 사람에겐 별로일 수 있지만 적응 되면 진짜 최고다. APC 모델이어서 가장 구분감을 느낄 수 있도록 레드로 지정했는데, 실상 별 차이는 못 느꼈다.

30g 과 차등은 확실히 느낌이 다르다.

저소음 차등 블랙

그동안 30g에 적응해와서 그런가 구름타법으로 타자치는 것이 굉장히 익숙해졌는데, 차등에 30g 입력할 때처럼 구름 타법을 구사하면 덜 눌려서 안 눌릴 때가 많다. 일반 키보드와 비슷한 정도로 누르면 되어서 일반 키보드에 익숙한 사람은 45g 저소음 모델도 무난하게 잘 쓸 수 있을 것 같다. 다만 반발력이 은근 있어서 팔 안 쪽이 조금 저리다. 손목과 손가락에 약간 무리가 오는 것 같은 느낌이 있다. 구분감이 있어서 오타는 거의 나지 않는다. APC 버전에 별 감흥이 없어서 없는 버전으로 구매했는데 좀 더 키보드 무게가 가볍다. 차등으로 구매했지만 대부분의 키가 45g이어서 누를 때 힘이 좀 들어간다. 키보드 덮개를 씌우면 소리가 적어지고 반발력이 덜 느껴진다. 45g은 APC 있는 모델로 구매해서 살짝 눌러도 인식되게끔 설정해도 좋을 것 같다는 생각이 든다. 그 초콜릿 부러뜨리는 느낌을 별로 좋아하지 않는 사람이라면.

차등은 30g에 적응된 나에게 조금 당황스러운 느낌이다. 키보드 키캡을 안 씌우면 팔 안쪽 근육이 욱신거리고, 오타가 안 난다. 키보드 키캡을 씌우면 덜 눌려서 오타가 난다. 특별히 붉은색 ESC 키도 구매해서 꽂았는데 먹색 키가 좀 멋있는 거랑 윈도우즈용 키보드 라는 것, 오타 안 난다는 것 빼고 뭐 그다지 특별할 게 없다. 30g이 나한테 가장 잘 맞는 키보드인 것은 맞는 것 같다. 지금은 재택근무 중이지만 회사에 가져갈 용도로 구매한 건데, 30g 균등으로 구매할 걸 그랬다고 생각이 든다. 아니면 APC이 탑재된 45g 균등도 나쁘진 않을 것 같다. 가장 구분감을 약하게 하면 손목에 무리가 덜 갈 것 같다. 화이트도 예쁘고, 블랙도 예쁜데, 뭐랄까 한 옵션씩 잘 못 산 느낌.

손가락 힘이 약하고, 손가락 길이가 짧은 나에게는 화이트는 맥 버전이라 불편하고, 블랙은 차등이라서 불편..ㅠ 디자인은 둘다 고급스럽고 예쁘다. 30g 균등 APC 윈도우즈 버전이 내겐 그나마 가장 잘 맞는 옵션인 것 같다 ㅠ

끝까지 눌러야 하는 기계식 키보드를 별로 좋아하지 않는다면 적응할 때 시간이 좀 오래 걸린다. 그래도 일단 왔으니까 적응해놓고 회사용으로 써야할 것 같다. ㅠㅠ 키보드 덮개 씌우면 덮개 표면 마찰력이 거슬리긴 하지만 눌리는 느낌이 부드러워서 괜찮은 것도 같다. 내가 키보드 따위에 66만원이나 쓰다니 ㅋㅋㅋ Nano IPS 모니터 가격만 하다ㅠ 다시 팔고 30g 균등으로 살까 생각도 들지만 덮개를 벗기고 입력하면 또 쓸만한 것 같기도 하고.. 적응해봐야 알 것 같다. 어느 정도까지 눌러야 하는지 아직 몰라서 그런 것 같다.

14일차

내가 개발하던 서버와 묶여있는 마스터 서버가 먹통이다. 그래서 쿠버네티스 관련 명령어가 하나도 듣질 않았다. 하는 수 없이 저번 화이트보드 세션에서 나온 이야기를 반영해서 지금까지 구성해둔 코드에 어떤 요소가 필요한지 정리했다. 엄청 막연했던 컨셉이 구체적으로 잡히니 무엇부터 해야할지 엄두가 나기 시작했다. State Machine 기법으로 나눈 각 State의 정의를 명확히 하고 그 안에 담을 기능을 구체화하니 구현해야할 함수도 명확해졌다. 화이트보드 세션에서 운영 관점으로 나온 이야기를 다 구현하려면 한 스프린트 (2주) 안에 못 나오므로 2주 안에 개발할 수 있는 것만 선정해서 개발하기로 했다. 일단 MVP니까 돌아가는 것만 보여주면 된다고 하셨으니 그에 맞게 열심히 설계하고 내가 짜둔 코드에 어디까지 구현됐는지 확인했다. 주간 보고 적느라 반나절 소요 됐다. 써머리도 적으라고 하니까..ㅠ

회사 출근

회사 출근해서 뭐했는지 기억이 잘 안 난다. 엄마가 새벽부터 쪄준 공주 밤을 숟가락으로 퍼먹고 간식 먹다가 플랫폼을 이용해주실 고객님 이야기를 오전 내내 한 것 같다. 목표를 정해야 하는데 정확한 상황을 몰라서 의사소통이 왔다 갔다 하는 시간이었던 것 같다. 네이버 앞 스시쿤? 무슨 쿤이라는 가게에서 오마카세 먹었는데 비장이 약해 비린내를 맡으면 구역질을 하는 관계로 마구로, 참치, 고등어 등 붉은 생선은 다 팀원들에게 양보했다. 크으 비싼 부위만 양보하는 관대함! 그대신 계란 초밥을 받아 먹었다. 팀원들이 회 먹을 땐 무조건 내 근처에 앉겠다고 한다. 어린 복어 튀김도 나오고 전복 내장 양념 전복도 나왔는데, 도미회가 제일 맛있었던 것 같다. 양보하고도 엄청 배불렀는데 이날 밤에 몸이 너무 가려워서 난생 처음 잠을 설쳤다. 처음 먹어본 전복 내장이나 어린 복어 튀김이나 처음 먹어본 물고기 중 무언가가 알레르기 증상을 일으켰나 보다.

15일차

몸이 가려워서 건조해서 그럴 수도 있으니 잘 씻고 기름진 로션을 듬뿍 바른 상태에서 일을 하려고 하는데 이상하게 몽롱했다. 몸이 안 좋은 것 같았다. 이상하게 눕고 싶은 마음이 들었다. 따뜻한 물을 많이 마시면서 코드를 단계별로 나누고 새로 필요한 기능 관련 함수를 짰다. 서버가 아직 먹통이라 테스트 없이 짜는 게 불안하지만 전에 짜둔 코드를 바탕으로 최대한 오류 없이 짜려고 노력했다. 클래스를 나눠서 하라고 했는데 일단 기본 기능부터 만족하는 게 우선이어서 클래스 없이 함수만 이용해서 짰다. 각 단계를 동시에 진행하지 않도록 하면서, 특정 조건을 벗어나지 않으면 무한 루프를 돌게 해야 하는 부분, 상황에 맞는 개수만큼 진행해야 하는 부분이 혼재되어 머리가 복잡했다. 어떻게 해야할 지 고민하다가 지쳤다. 의욕이 떨어졌는데 운전면허 갱신도 해야하고 피부과도 일단 가야해서 갔다오고 나서 하자고 생각했다. 저녁 먹고 느긋하게 내일 할 일을 정리해보고 마무리했다.

16일차

전날 정리한 내용을 바탕으로 새로운 기능에 필요한 요소 적고, 이미 짜둔 코드를 어떻게 활용할지 정리했다. 그러고나서 일단 할 수 있는 데까지 코딩했다. 안 되는 부분은 개발과정을 담은 컨플루언스 페이지에 정리했다. 추후 고민해야 할 부분도 따로 적었다. 계속 머릿속으로 시뮬레이션 돌려보면 문제가 생긴다. 이런 경우에 이런 문제가 발생할 거고 다른 경우엔 또 다른 문제가 생길 수 있다. 계속 이렇게 생각하다간 끝이 없겠다 생각이 들었다. 무언가를 개발하고 나면 개선해야할 점이 계속 생각난다. ㅠㅠ 이렇게 하고나자 피곤이 잔뜩 몰려왔다. 컨플루언스에 정리하고 컴퓨터를 껐다.

회사 출근

오전에 간식 먹고 개발하고 있는 것 중 궁금한 거 질문했다가, Agile한 방식으로 개발을 진행하는 방식에 대해 들었다. 2주 안에 MVP 하기로 마음 먹었으면 기간에 맞게 개발 범위를 한정하는 법에 대해서 알려주셨다. 내가 자꾸 파고드는 성향을 보여드리자, Devide and Concurr 방식으로 데모 시나리오도 정해주셔서 그렇게 데모하기로 했다. 테스트할 때 필요한 테스트 함수도 pseudo 코드로 짜주셨다. 뭐 엄청 이해가 쏙쏙 가는 건 아니지만 팀장님이 그렇다고 하시니까 믿기로 했다. 팀장님 반차셔서 우리 셋만 그램스 그라운드 가서 스노우 크랩 메뉴랑 무슨 스테이크, 멕시코 음식 그 뭐지 무슨 쵸? 또띠아 같은 거에 채소 이것저것 넣은 거 하여튼 그거 새우튀김 들어간 거랑 매운돼지볶음밥? 그런 거 시켜먹었는데 다른 건 별로였고 스노우 크랩이랑 멕시코음식 새우튀김 무슨 쵸가 젤 맛있었다. 아주 상큼한 느낌! 스노우 크랩은 단단한 살 부분은 괜찮고 껍질에 붙어있는 거품 같은 게 비린내가 좀 나기는 하는데 까먹기 좋아서 합격. 오후에는 챗봇의 구동원리에 대해 설명 듣고 예전에 건드려본 컨플루언스 REST API 이용하는 클라이언트를 활용해야 된대서 잠시 멘붕. 아 그거 다 까먹었는데. 개발 환경 구성해놓은 거는 라이센스 기간이 다해서 쓸 수 없다. 할 수 없이 회사 컨플루언스에 어떻게 연결했었는지 찾아야 한다! 계정 정보는 지라 들춰보면 나올 것 같은데 내가 지금 하고 있는 업무부터 끝내야지 그걸 건드리면 며칠 또 잡아먹을 것 같은데ㅜㅜ 금요일인데 세시반에 못 가고 5시에나 퇴근할 수 있었다. 그래도 희소식! 재택근무가 1주 연장 되었다! 덩실덩실~

17일차

팀장님께 마스터 서버를 재부팅해달라고 부탁 드렸다. 껐다 켜니 ssh로 잘 들어가진다. 쿠버네티스 명령어는 잘 되는데, 시스템 관련 팟 중 안 뜬 애가 있어서 마스터쪽 다시 다 지우고 다시 연결했다. flannel 쪽만 리셋하면 되는데 다 지우고 다시 까는 게 제일 깔끔하다. 워커 쪽도 지울까 하다가 팟 띄우려고 yaml 찾는 것도 귀찮기 때문에 그냥 진행했다. 팀장님이 스탠덥 미팅에서 내가 개발 중인 기능 MVP를 이번 스프린트 때 하자고 하셨다. 컨플루언스 REST API는 지금 당장 안 해도 된다고 한다. 덜컥 겁이 났다. 이렇게나 부족한 기능인데 어떻게 데모를 해? ㅜㅜ 기존에 짜둔 코드에 오류가 없는지 테스트 해보고, 화이트보드 기술 세션 때 들은 이야기를 바탕으로 코드를 다 뜯어가면서 수정했다. 아 왜 나는 회사가기 전날 이렇게 바쁘고 힘들고 일을 제일 많이 하는 것 같지? 주말 지나고 난 후라 일하기 싫었는데 그래도 꾸역꾸역 다 했다. 마음을 진정시켜주는 음악 찾아서 일하니 생산성이 최대로 오른다! 유투브에서 느낌 오는 음악 틀고 함수 간 역할을 잘 생각하면서 짜니까 물 흐르듯이 코딩했다. 다행히 저녁 먹기 전에 목표한 부분까지 잘 나와서 그 다음 고민해야할 내용은 컨플루언스에 정리했다. 코스트코 구매대행으로 시킨 러그가 커도 너무 크다. 반품할까 했는데 구매대행은 반품 안 된다고 그래서 반품하려고 다시 포장한 걸 다시 뜯었다. 사이즈 잘못 시킨 러그를 반으로 접으니 딱이다. 누워 있으면 아주 좋다.

회사 출근

궁금한 내용을 질문하고 이걸 어떻게 구현할 수 있을지 질문하자, 그건 MVP를 구현한 다음 추가로 개선해야하는 내용을 논의할 때 나와야 하는 이야기라면서 MVP는 최소의 기능만 되게 구현하면 된다고 하셨다. 그럼 다했잖아?! 라는 생각에순간 꿀먹은 벙어리가 되었다. 멍 때리는 표정으로 '그럼 다했는데요.' 하니까 팀장님이 바로 보여줄 수 있냐고 하셨다. 그래서 바로 시연했다. 그대로 MVP 종료. 바로 다음 Task로 넘어간다. 너무나 Agile해서 당황스러웠지만 그냥 아무렇지 않은 척 어른인 척 넘어갔다. 다음 업무는 기획이란다. 머리가 멍해진다. 뭐부터 해야하지? 그나마 스타트업에서 일해봤던 내가 더 빨리 잘할 것 같다고 한다. 이미 기획이 완료되어 구현된 것들이 있는데 뭘 더 하라는 건지 모르겠다. 그건 추후에 알려준다고 하신다. 회사의 임원급이 KPI를 바라보는 방식에 대해 팀장님의 강의를 들었다. 네트워크 강의도 듣고, 아이피 주소랑 도메인이랑 호스트 파일이랑 관계도 듣고 HTTP Request하면 나오는 결과값 코드 설명도 들었다. 팀장님이 은퇴하셔서 컴퓨터 학원 여시면 C 강좌 좀 들으러 가야겠다. 그래니 살룬에 가서 미트볼 잔치를 벌였다. 거의 다 토마토 소스 위주로 시켰는데 다 치즈가 그득그득, 피자를 게살 크림으로 시켰으면 큰일날 뻔 했다! 라구 소스 라자냐도 맛있고, 무슨 스테이크에 바질 페스토 같이 생긴 소스 다래순 맛 나는데 아주 고소해서 밥에 비벼먹으면 엄청 맛 날듯, 여기 스테이크 맛집! 냄새도 안 나고! 미트볼 싫어하는데 잘 만들어서 목이 막히지 않는 동그랑땡 느낌이었다. 맛있었다. 리조또도 시켰는데 많이 시켜서 남겼다. 고기와 치즈가 너무 많아서 오후에 너무 졸렸다. 오후에 임원들이 KPI를 보는 관점에 대해서 강의를 들었다. 그 와중에 우리 플랫폼 이용하는 고객님이 남들에게 뙇 뭐했는지 보여주는 자리가 있었다. 구경은 못하고 긴장된 상태로 반응을 기다렸는데 무난히 잘 넘어갔다고 한다. 다행이었다. 결론은 뭐든지 설계부터 잘해야 한다! SRA 99.9999% 흠.. 거참.. 금융 앱도 이렇게는 안 하는데. 통영 미나리즙으로 치즈와 고기에 탁해진 피를 정화했다.

18일차

회사 갔다온 다음날은 졸리다. 러그 깔아둔 온수매트에 엎드려서 고양이처럼 빵이나 굽고 싶은데 주간보고 쓰라고 해서 열심히 쓰고 써머리도 적으라고 그래서 5분만에 적은 것 같다. 갑자기 성과 평가 시즌이라면서 올해 내가 한 업무에 대해 평가를 하란다. 작년까지 데이터 분석 업무만 하다가 올해 3월부터 급 소프트웨어 개발에 뛰어든 거라 요리조리 배우고 새로 시도하고 책 사고 읽고 검색하고 읽고 코드 실행하고 응용하고 원하는 목표를 이룰 수 있게 구현하는 과정을 거쳤다. 성과 목표, 진행 내용, 의견 나눠서 쓰라는데 그동안 정리해놨던 컨플루언스 페이지, 지라 이슈, 주간보고 등을 계속 봐가면서 키워드 뽑고 그 내용으로 정리했다. 그 과정이 정말 고통스러워서 점심시간에 점심 안 먹고 나가서 산책하며 생각을 정리했다. 돼지고추장찌개에 밥을 후루룩 말아먹으면서 공격적이고 남들보다 뛰어나보이게 작성하는 방법을 연구했다. 최초? 안정? 비용 절감? 뭐.. 내가 담당한 영역이 Platform Orchestration이라서 일단 이 단어가 간지난다. 그런데 성과 평가 때 저 단어 하나만 쓸 수가 없으므로.. 머리를 쥐어짰다. 올해 이 팀 와서 jira 정리한 거 Task 별로 다 나누고 주간보고도 보면서 정리하다 보니까.. 삽질의 흔적이 보였다. 하다가 만 것들 말이다. 책도 사고 익히면서 하다가 성능을 낮출 수도 있어서 그만 둔 것들. Performance Tracing 하는 Jaeger, Envoy proxy, Istio 등. 다른 기능도 다 구현해놓고 끝을 안 봐서 의아해하던 중인데 이번 성과 평가에만 안 들어가지 결국 올해 안엔 할듯 싶다. 그동안 매번 바쁘게 뭔가를 새로 배우고 적용하고 가능성을 찾고 리서치했는데 결론난 게 별로 없어서 뭔가 해놓은 게 없다고 푸념했는데 지금 와서 보니까 무언가를 만들어가는 과정이었던 것 같다. 한 마디로 팀장님의 큰 그림. 큰 그림 안에서 꾸역꾸역 따라가다 보니까 뭔가 구현한 결과물이 있다. 최근에 완료한 MVP도 내가 엄두도 못 낼 큰 일이라고 생각했었는데 결국 완료했다. 시간은 오래 걸렸다. 바로 바로 피드백 받고 수정했으면 1달 반이면 충분했을 것을 2달 반이나 걸렸다. 원인은 재택근무, 회의 참석으로 인한 업무 시간 부족. 5일 중 2일은 거의 없는 셈이었다. 그래도 끝낸 게 용하다. 저녁 굶고 겨우 다 쓰고 나니 비근로시간 빼고 11.5시간 근무.. 저녁 먹고 바로 누워 잤다.

회사 출근

오전엔 재택근무하다가 오후에 출근. 오전엔 MVP 완료 문서 작업하고 어제 쓴 내 성과 평가도 좀 수정하고 jira 티켓 정리하고 개발한 기능 Bitbucket에 올렸다. 지난번 윈도우즈 업데이트로 다 날아가서 소스트리 다시 다운 받았는데 리눅스 연결방법대로 하면 필요 없어서 괜히 깔았다. 리눅스 서버 연결해놓은 상태인데 자꾸 에러나서 보니까 사용자 등록이 풀려있었다. 좀 고쳐주고 git add --all -> git status -> git commit -m "말말" -> git push origin master 하니까 잘 올라갔다. 이걸 오전 중에 하고 스탠덥 미팅도 했는데 주요 주제는 성과 평가였다. 나는 어제 다 해놔서 여유로웠는데 다른 팀원들은 다시 다 수정하느라 말이 없었다. 난 오후에 출근하기로 해서 직접 봐주시기로 했고 다른 분꺼 미리 보신다고 하셨다. 머리 감고 회사에 출근했는데 배고파서 사내 식당에서 10분만에 청국장찌개랑 보쌈 먹고 회의실로 향했는데 팀장님이 다른 팀원꺼 성과 평가를 첨삭하고 계셨다. 양치하러 갔다오는 동안 팀장님은 첨삭 마무리하시고 메일로 보내시는 것 같았다. 내꺼 보는데 꼼꼼하게 했다면서 칭찬해주셨지만 제목이 구려서 엄청 열심히 수정해주셨다. 성과 평가 항목도... 군데 군데 구린 부분을 지적해주셔서 고치는 방법을 듣고 따로 적어놨다. 성과를 달성하려면 위의 생각을 읽어야 한다고 강조하셨다. 외부 발표 자료를 봐야한다고.. 그런 다음 피곤하시다길래 커피 사드린다고 하고 나는 오미자냉차 시켰다. 다시 돌아와서 문제를 해결하는 방법인 피시 본을 활용해서 기획하는 방법을 알려주셨다. 마인드맵과 비슷하게 전개해나가다 보면, 현재 상태에서 빠진 부분이 무엇이고, 어느 방향으로 개발을 해나가야 하는지 보인다고 하셨다. 그 부분을 외주에 요청을 하라고 하셨다. 깊은 깨달음을 얻고 언제 팀장님처럼 될 수 있을까를 생각했다. 외주와 미팅을 한 후 EKS 쿼리문을 보고 비싼 거 싼 거 나누고 비싼 거는 뺐다. 오랜만에 쿼리 보니까 반가웠다. 용량 걱정을 하길래 추가 EKS 계정을 넘겨주기로 했다. AWS의 글래셔랑 S3처럼 한쪽은 장기간 데이터 보관, 다른 쪽은 단기 데이터 보관으로 가는 전략을 쓰기로 했는데, 실제로 그 방법을 쓰다니 신선하다. 외주에서 베타테스트 요청해서 다음주는 물고기뼈 그림 좀 그리고 베타테스트 하게 될 것 같다. 집에 와서 피드백 받은 내용 수정하고 퇴근!