꿩이야기

데이터 이관이나 복제 구성 후에 데이터가 동일한지 어떻게 확인할까?

보통 row count부터 맞춰보는데, 건수가 같다고 데이터가 같은 건 아니다.

그래서 MySQL/MariaDB에 있는 checksum table을 테스트해본 내용을 정리해본다.

checksum table은 테이블 전체 데이터를 읽어서 하나의 checksum 값을 돌려준다.

원리는 간단하다. 행마다 CRC를 계산하고 그걸 다 더한다.

(CRC는 데이터를 정해진 다항식으로 나눈 나머지 값으로, 데이터가 1비트만 바뀌어도 값이 달라져서 변경 여부를 빠르게 확인할 때 쓴다. MySQL의 CRC32()는 32비트짜리 값을 돌려준다.)

그래서 같은 데이터라면 서버가 달라도 같은 값이 나와야 한다. (물론 조건이 있다. 뒤에서 다룸)

테스트용 테이블부터 만든다.

CREATE TABLE t1 (
  id      INT PRIMARY KEY,
  name    VARCHAR(50),
  amount  DECIMAL(10,2),
  memo    VARCHAR(100) NULL,
  reg_dt  DATETIME
) ENGINE=InnoDB;

INSERT INTO t1 VALUES
 (1,'kim',100.00,NULL,'2026-10-01 10:00:00'),
 (2,'lee',200.50,'',  '2026-10-02 11:00:00'),
 (3,'park',300.00,'x','2026-10-03 12:00:00');

-- 비교용 테이블
CREATE TABLE t2 LIKE t1;
INSERT INTO t2 SELECT * FROM t1;

-- checksum 결과
MariaDB [gwchu]> checksum table t1, t2;
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 | 1257747654 |
+----------+------------+
2 rows in set (0.000 sec)

checksum table은 여러 테이블을 한 번에 넣어서 바로 비교가 가능하다.

참고로 checksum table에는 quick 옵션도 있는데, 이건 MyISAM에서만 의미가 있다.

MyISAM은 checksum=1 옵션을 주면 checksum 값을 미리 저장해두고 변경 때마다 갱신하는 live checksum을 지원해서, quick으로 저장된 값을 바로 꺼내올 수 있다.

InnoDB는 live checksum이 없어서 QUICK을 주면 NULL이 나오고, 결국 매번 전체 스캔으로 계산한다.

데이터 변경시 checksum이 모두 동일한지에 대해서 테스트한 결과이다.

--------------------------- 데이터 변경 테스트
MariaDB [gwchu]> UPDATE t2 SET amount = 200.51 WHERE id = 2;
MariaDB [gwchu]> checksum table t1, t2;
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 | 2511561321 |
+----------+------------+

-- 원복시 checksum 동일해질까?
MariaDB [gwchu]> UPDATE t2 SET amount = 200.50 WHERE id = 2;
MariaDB [gwchu]> checksum table t1, t2;
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 | 1257747654 |
+----------+------------+


--------------------------- NULL과 빈 문자열 구분 테스트
MariaDB [gwchu]> UPDATE t2 SET memo = '' WHERE id = 1;
MariaDB [gwchu]> select * from t1;                    
+----+------+--------+------+---------------------+
| id | name | amount | memo | reg_dt              |
+----+------+--------+------+---------------------+
|  1 | kim  | 100.00 | NULL | 2026-10-01 10:00:00 |
|  2 | lee  | 200.50 |      | 2026-10-02 11:00:00 |
|  3 | park | 300.00 | x    | 2026-10-03 12:00:00 |
+----+------+--------+------+---------------------+
MariaDB [gwchu]> select * from t2;
+----+------+--------+------+---------------------+
| id | name | amount | memo | reg_dt              |
+----+------+--------+------+---------------------+
|  1 | kim  | 100.00 |      | 2026-10-01 10:00:00 |
|  2 | lee  | 200.50 |      | 2026-10-02 11:00:00 |
|  3 | park | 300.00 | x    | 2026-10-03 12:00:00 |
+----+------+--------+------+---------------------+
MariaDB [gwchu]> checksum table t1, t2;
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 | 1133446092 |
+----------+------------+


--------------------------- 대소문자 구분 테스트
MariaDB [gwchu]> UPDATE t2 SET name = 'KIM' WHERE id = 1;
MariaDB [gwchu]> select * from t1;                       
+----+------+--------+------+---------------------+
| id | name | amount | memo | reg_dt              |
+----+------+--------+------+---------------------+
|  1 | kim  | 100.00 | NULL | 2026-10-01 10:00:00 |
|  2 | lee  | 200.50 |      | 2026-10-02 11:00:00 |
|  3 | park | 300.00 | x    | 2026-10-03 12:00:00 |
+----+------+--------+------+---------------------+
MariaDB [gwchu]> select * from t2;                       
+----+------+--------+------+---------------------+
| id | name | amount | memo | reg_dt              |
+----+------+--------+------+---------------------+
|  1 | KIM  | 100.00 | NULL | 2026-10-01 10:00:00 |
|  2 | lee  | 200.50 |      | 2026-10-02 11:00:00 |
|  3 | park | 300.00 | x    | 2026-10-03 12:00:00 |
+----+------+--------+------+---------------------+
MariaDB [gwchu]> checksum table t1, t2;                  
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 |  633912448 |
+----------+------------+

그런데, 컬럼이 추가되어 NULL로 들어가거나 row_format이 변경되어도 checksum은 동일하게 나왔지만,

컬럼 순서가 변경되었을 경우 checksum은 다르게 나온 결과를 확인할 수 있었다.

--------------------------- NULL 컬럼 추가
MariaDB [gwchu]> ALTER TABLE t2 ADD COLUMN extra INT NULL;
MariaDB [gwchu]> checksum table t1, t2;
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 | 1257747654 |
+----------+------------+
MariaDB [gwchu]> select * from t1; select * from t2;              
+----+------+--------+------+---------------------+
| id | name | amount | memo | reg_dt              |
+----+------+--------+------+---------------------+
|  1 | kim  | 100.00 | NULL | 2026-10-01 10:00:00 |
|  2 | lee  | 200.50 |      | 2026-10-02 11:00:00 |
|  3 | park | 300.00 | x    | 2026-10-03 12:00:00 |
+----+------+--------+------+---------------------+
+----+------+--------+------+---------------------+-------+
| id | name | amount | memo | reg_dt              | extra |
+----+------+--------+------+---------------------+-------+
|  1 | kim  | 100.00 | NULL | 2026-10-01 10:00:00 |  NULL |
|  2 | lee  | 200.50 |      | 2026-10-02 11:00:00 |  NULL |
|  3 | park | 300.00 | x    | 2026-10-03 12:00:00 |  NULL |
+----+------+--------+------+---------------------+-------+


--------------------------- row_format 변경
MariaDB [gwchu]> ALTER TABLE t2 ROW_FORMAT=COMPACT;
MariaDB [gwchu]> checksum table t1, t2;
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 | 1257747654 |
+----------+------------+


--------------------------- 컬럼 순서 변경
MariaDB [gwchu]> ALTER TABLE t2 MODIFY COLUMN memo VARCHAR(100) NULL AFTER id;
Query OK, 0 rows affected (0.005 sec)
Records: 0  Duplicates: 0  Warnings: 0

MariaDB [gwchu]> select * from t1; select * from t2;                          
+----+------+--------+------+---------------------+
| id | name | amount | memo | reg_dt              |
+----+------+--------+------+---------------------+
|  1 | kim  | 100.00 | NULL | 2026-10-01 10:00:00 |
|  2 | lee  | 200.50 |      | 2026-10-02 11:00:00 |
|  3 | park | 300.00 | x    | 2026-10-03 12:00:00 |
+----+------+--------+------+---------------------+
3 rows in set (0.000 sec)

+----+------+------+--------+---------------------+
| id | memo | name | amount | reg_dt              |
+----+------+------+--------+---------------------+
|  1 | NULL | kim  | 100.00 | 2026-10-01 10:00:00 |
|  2 |      | lee  | 200.50 | 2026-10-02 11:00:00 |
|  3 | x    | park | 300.00 | 2026-10-03 12:00:00 |
+----+------+------+--------+---------------------+
3 rows in set (0.000 sec)

MariaDB [gwchu]> checksum table t1, t2;
+----------+------------+
| Table    | Checksum   |
+----------+------------+
| gwchu.t1 | 1257747654 |
| gwchu.t2 | 3132562731 |
+----------+------------+
2 rows in set (0.000 sec)

운영에서 사용하려면 제일 중요한 건 락이다. checksum table 도는 동안 쓰기가 막히는지?

결론부터 말하면 InnoDB에서는 DML은 안 막히고 DDL만 대기한다.

checksum table은 일반 SELECT처럼 메타데이터 락을 SHARED_READ로 잡는다.

이건 DML이 잡는 SHARED_WRITE와 호환되니까 UPDATE, INSERT, DELETE는 그냥 진행된다.

행 락도 안 잡고 MVCC 스냅샷으로 읽는다.

대신 ALTER, TRUNCATE, DROP 같은 DDL은 checksum이 끝날 때까지 기다린다.

여기서 주의할 점이 하나 있다.

스냅샷으로 읽기 때문에 checksum 결과는 실행 시작 시점 기준이다. 도는 중에 들어온 UPDATE는 반영이 안 된다.

그래서 운영 중인 Master와 Slave를 checksum table로 비교하면, 시점이 안 맞아서 데이터가 같아도 값이 다르게 나올 수 있다.

필요하다면 PK 구간을 나눠서 직접 구간별로 계산하는 방법이 있긴 하다.

checksum table은 테이블 단위라 어디가 다른지는 모르고, 운영 중에는 Master와 Slave의 시점을 맞추기도 어렵다.

이걸 PK 구간 단위로 나눠서 복제 환경에서 자동으로 비교해주는 도구로 Percona Toolkit의 pt-table-checksum라는 것이 있다.

이 Tool의 원리는 다음과 같다.

실행하면 Source에 결과 저장용 percona.checksums 테이블이 생긴다.

Source는 PK 구간별로 checksum을 계산해서 이 테이블에 저장하는데, 이 쿼리가 복제되면서 Replica도 같은 쿼리를 자기 데이터로 계산한다.

결국 Replica에는 Source 값과 자기 값이 나란히 남고, 이걸 비교해서 다른 구간을 찾는다.

결과의 DIFFS가 0이 아니면 불일치가 있는 거다.

checksum table은 NULL과 '' 차이, 대소문자 차이까지 잡아내서 row count보다 훨씬 꼼꼼하게 볼 수 있다.

다만 컬럼 순서나 내부 저장 형식이 다르면 데이터가 같아도 값이 달라질 수 있고, 테이블 단위라 어디가 다른지는 알 수 없다.

운영 중인 복제 환경이라면 pt-table-checksum를 고려해볼만 할 것 같다.

2025년은 행복한 한 해였다.

여느때와 같이 불행과 행복이 공존하는 삶이지만

올 한해는 행복이 좀 더 비중이 컸던 것 같다.

정말 말도 안되는 일들도 발생하고

드라마에서 볼 법한 일이 나한테도 일어나는구나라고 생각했었다.

그러나, 올해는 다른때보다 멘탈이 흔들리지 않았다.

오히려 주어진 것에 감사하고 지금 현재에 만족하면서 살았던 한 해였다.

그러나, 편안함은 독이다.

편안하고 행복했기에 반대 급부로 크게 성장하지도 않았고

뭘 열심히 하려고 노력도 하다가 그만두고 그냥 행복을 즐기면서 살았다.

이제는 이 편안함과 행복을 끝내야 할 것 같다. 미래를 위해서...

슬슬 블로그를 다시 시작해보려고 한다.

지금껏 놀기만 한 것은 아니지만...

언제든 항상 끊임없이 발전하고 있다는 기록은 남겨야한다는 생각이 들고 있다.

이것도 운이 점차 바뀌고 있어서 생기는 변화인가..

혹시 모를 미래를 대비해야 한다.

요즘 경제 유튜브를 많이 듣고 보는데

암울한 내용밖에 없다.

실제로 체감하는 상황도 그리 좋지는 않다.

이 AI 파동 속에서...

내가 이 IT 업계에서 언제까지 있을 수 있지는 모르겠지만

할 수 있을 때까지는 해보려고 한다.

그때까지는 IT 공부를 멈추지 말아야겠지..

뭐 잘 안되면 어쩌겠나.

알바하면서 살수도 있고

그러다가 뭔가 색다른 길을 발견하여

큰 성공을 거둘 수도 있는 법.

항상 인생이 내 예상대로 풀린 적이 단 한번도 없었기에.

그냥 현재에 최선을 다하고

혹시 모를 미래를 위해 준비하려고 한다.

내일부터 시작되는 2026년은 미래를 위해 준비하는 시기가 될 것 같다.

나가는 비용은 꽤 되겠지만

미래를 위한 투자라고 생각하자.

피스!

ClickHouse는 Columnar DBMS이다.

간단하게 mergetree 테이블을 생성해서 데이터를 넣으면 다음과 같이 데이터 파일이 생성된다.

Columnar DBMS인데... data.bin 하나로 뭉뚱그려서 저장이 된다.

이렇게 하나의 데이터 파트가 data.bin으로 저장되는 유형을 "Compact" 유형이라 한다.

데이터가 작을때는 컬럼별로 데이터 파일을 생성하지 않고 하나의 데이터 파일로 관리하다가

데이터가 많아지면 컬럼별로 데이터 파일을 생성해 관리한다. 이때 데이터 파트 유형을 "Wide" 유형이라 한다.

다음의 쿼리를 통해 테이블의 데이터 파트 유형을 확인할 수 있다.

SELECT
    name,
    rows,
    formatReadableSize(bytes_on_disk) AS bytes_on_disk,
    part_type
FROM system.parts
WHERE (database = 'gwchu') AND (`table` = 't_sample') AND active
ORDER BY modification_time DESC
LIMIT 5

   ┌─name──────┬─rows─┬─bytes_on_disk─┬─part_type─┐
1. │ all_2_2_0 │ 9000 │ 76.37 KiB     │ Compact   │
2. │ all_1_1_0 │    4 │ 760.00 B      │ Compact   │
   └───────────┴──────┴───────────────┴───────────┘

데이터 파일을 컬럼별로 저장하도록 변경하는 방법은 두가지가 있다.

1. 데이터를 많이 넣기

2. 관련 설정 변경

해당 테이블 파트 설정은 기본적으로 system.merge_tree_settings에서 확인할 수 있다.

시스템 설정 변경은 불가능하고. 개별 테이블 설정은 변경이 가능하다.

SELECT
    name,
    value
FROM system.merge_tree_settings
WHERE name LIKE '%min_%_for_wide_part%'

   ┌─name────────────────────┬─value────┐
1. │ min_bytes_for_wide_part │ 10485760 │
2. │ min_level_for_wide_part │ 0        │
3. │ min_rows_for_wide_part  │ 0        │
   └─────────────────────────┴──────────┘

위의 시스템 설정을 참고했을때, 10MB정도 데이터가 들어가야 Wide 타입으로 바뀌는 것을 확인할 수 있다.

테이블 개별 설정을 0으로 변경하여 바로 wide로 변경해보았다.

ALTER TABLE gwchu.t_sample
    (MODIFY SETTING min_rows_for_wide_part = 0, min_bytes_for_wide_part = 0)

OPTIMIZE TABLE gwchu.t_sample FINAL

SELECT
    name,
    rows,
    formatReadableSize(bytes_on_disk) AS bytes_on_disk,
    part_type
FROM system.parts
WHERE (database = 'gwchu') AND (`table` = 't_sample')
ORDER BY modification_time DESC
LIMIT 5

   ┌─name──────┬─rows─┬─bytes_on_disk─┬─part_type─┐
1. │ all_1_2_2 │ 9004 │ 76.76 KiB     │ Wide      │
2. │ all_1_2_1 │ 9004 │ 76.43 KiB     │ Compact   │
3. │ all_2_2_0 │ 9000 │ 76.37 KiB     │ Compact   │
4. │ all_1_1_0 │    4 │ 760.00 B      │ Compact   │
   └───────────┴──────┴───────────────┴───────────┘

컬럼별로 데이터 파일이 생성된 것을 볼 수 있다.

실제 데이터는 {컬럼명}.bin에 압축해서 저장이 된다.

bin 파일 안에는 데이터가 granule(데이터 블록)단위로 묶여서 저장된다. (기본 8192 rows)

{컬럼명}.cmrk2 파일은 bin파일에 저장되어 있는 granule 위치(offset)를 찾아가기 위한 인덱스이다.

참고로, cmrk2와 cmrk4는 mark 포맷의 버전 차이라고 한다.

[참고자료]
https://westlife0615.tistory.com/598
https://clickhouse.com/docs/operations/system-tables/parts

제주도를 다녀왔다.

맑고 강렬한 태양빛과 차가운 공기가 어루어져 있던 날씨였다.

이름 모를 꽃들이 가득 피었고,

많은 사람들이 삼삼오오 제주도의 봄을 만끽하고 있었다.

여행은 물론 좋았다 재밌었고.

그러나 집에 도착한 후, 느끼는 이 공허함은 무엇일까?

현실로 돌아왔기 때문일까?

여행은 잠깐의 일시적인 즐거움 뿐이라 그런걸까?

나는 확실히 여행을 좋아하는 타입은 아니다.

막상 가면 좋지만, 다녀온 후에는 집이 최고라는 것을 느낀다.

그리고 내가 원하는 것은 일시적인 즐거운 여행이 아니라

지금 이 반복적인 현실에서의 즐거움 또는 목표를 찾는 것이라는 것을 알게 되었다.

이 또한 여행으로부터 배운 점인가...

아마 앞으로 여행은 내 기억이 희미해지는 2년 후쯤 또다시 가지 않을까 싶다.

그래요, 난, 난 꿈이 있어요.

월급 받아서 쓸거 쓰고 반 이상 미래를 위해 저축할 수 있는 삶

직장과 가까운 곳에 있는 방 2개와 거실이 있는 집을 얻어 사랑하는 사람과 함께 사는 삶

미드 프렌즈처럼 크리스마스나 기념일에 친구들을 초대해서 음식을 대접하고 같이 게임하면서 시간을 보내는 삶

봄이 오면 벚꽃 구경, 여름이 오면 바다 구경, 가을엔 단풍 구경, 겨울엔 눈꽃 구경 하는 삶

주 3회 이상 운동하면서 건강한 몸과 마음으로 사는 삶

어쩌다 푸른 하늘을 보고 하느님께 감사한 마음을 갖게 되는 삶

매일 아침 회사 가서 일하고 싶어지고 활기찬 하루를 시작하는 삶

세안 후, 거울을 보면서 '아 멋있게 늙어가고 있다!!'생각하면서 기분 좋아지는 삶

지금 일을 당장 그만두어도, 생활하는데 문제없을 만큼 꾸준히 들어오는 안정적인 캐시카우가 있는 삶

무심코 나도 모르게 노래를 흥얼거리는 삶

"나는 잘될거야!" 라는 믿음이 있는 삶

내 글을 쓰고 있는 지금 이 시간의 내 기억은 사라지겠지만

이 글은 오래오래 남겨져 있을테니...

10년 후, 내가 어떻게 살고 있는지 비교해보면 과연 얼만큼 이뤄져 있을까?

모든게 이뤄져 있다면 참 나는 운이 좋은 사람일거야

설날이 지나고 곧 입춘이 온다.

올해 을사년은 나에게 좀 신기한 해가 될 것 같다.

나는 경신(庚申)일주로 을사와는 천합지합이 된다.

과연 무슨 일이 생길까? 무슨 사건이 터지고... 어떠한 사람을 만나게 될까?

물론 이번에도 신년운세를 봤지만...

좀 나의 올 한해 인생을 유심히 관찰해보려고 한다.

그리고 올해의 목표가 생겼다!!

바로 올해는 돈을 좀 쓰자는 것이다.

막상 옷들을 보니 많이 헤지고... 잘 어울리지도 않고.. 별로 입을 것도 없다는 것을 문득 느꼈다.

그래서 올해의 목표는 내 옷을 전반적으로 교체하자는 것이다.

물론 그만큼 돈이 많이 들겠지만...

친구가 그런다. 뭐 이러려고 돈 버는거 아니냐고 ㅎㅎ

그치... 돈 쓰려고 돈을 버는거지.

물론 내가 돈을 악착같이 모으는 스타일은 아니지만,

YOLO처럼 돈을 물쓰듯이 쓰는 사람도 아니긴 하다.

좋은 옷을 사고 싶다.

비싸도 한번 사서 10년 이상 입을 수 있는 옷..ㅋㅋ

그리고 요즘 주식에 관심을 많이 가지고 있다.

나도 요즘 트렌드인 IT 쪽 주식도 해보고, 비트코인도 해봤지만.

나와 맞지 않는다고 느꼈다.

나는 트렌드를 따라가지도 못하고 그런 소식에도 관심도 없는 사람이기에

나는 돈을 묵혀두고 그냥 잊어버리는게 좋은 주식을 사는게 맞다.

그래서 광화문 교보문고에서 배당주와 관련한 책 2권을 사서 읽고

내 기준에선 꽤 많이 들어갔다.

이제 차근차근 배당주를 조금씩 모아볼 예정이다.

배당주를 모으다보면, 나중에 퇴직 후의 연금이 될 수도 있지 않을까? ㅎㅎ

작년 한해를 돌아보면 삶이 점차 안정화가 되는 시기였던거 같다.

그렇다고 편하지만은 않았다.

특히, 11~12월은 업무가 너무 많고 힘들었다;;

다시 그런 시기를 보내라고 한다면;; 아마 퇴사할듯?ㅋㅋ

참 돈 버는 게 쉽지 않다.

내 팔자가 아무리 직장운이 좋은 팔자라 하더라도

힘들때는 진짜 개같이 힘들었다.

그래도 막 하늘이 무너지고 땅이 꺼지는 상황에서 점차 삶이 안정되고

어느정도 마음의 여유를 가지게 된거 같다.

그리고 좋은 사람들하고도 인연이 되었고

또 아쉽게 떠나보낸 인연도 있었다.

여러 사람들을 만나면서 다양한 삶을 배웠고

내가 추구하는 인생만이 답이 아니라는 것을 알게 되었다.

어짜피 한번뿐인 인생...

즐겁고 재밌게 사는게 뭐 어떤가

긍정적으로 생각하고 현재에 충실하고 재밌으면 됐지.

덕분에 즐겁고 재미있는 경험도 했다.

아 맞다.

제일 중요한 거 하나를 빼먹었네.

SQLP 자격증을 땄다.

일과 공부를 병행하면서 너무 힘들고 피곤했지만,

그래도 다행이 한번에 붙었기에..

참 나는 운이 좋은 사람인거 같다. (물론 일과 관련된 운만...)

와... 1년 동안 많은 걸 배우고 많은 걸 경험했구나

잊고 살았는데... 참 신기하네.

작년 한 해는 좀 알차게 보낸 느낌이 든다.

인간관계적인 면에서도... 일적인 면에서도... 자기계발 관점에서도...

확실히 작년 운이 나쁘지 않은 운이라서 그런가.

전반적인 관점으로 보자면 긍정적이었다.

그렇다면 올해 을사년은 어떨까?

음... 사주 봐주신 분이 올해 좋다고 하시긴 했다.

내가 봐도 올해도 좋은 운인거 같긴 하다.

그래서 좀 기대되는 면도 있다.

어떤 좋은 일이 생길까?

내가 항상 바래왔던 삶이 펼쳐질까?

아니면 또다시 내 희망은 짖밟히고 

여지껏 그래왔던 것처럼

내가 예상하지 못했던 곳에서 좋은 일이 생길까?

내가 항상 바라는 삶이 이뤄지길...

문득 부모님을 가만히 바라보니 참 많이 늙으셨다는 생각이 든다.

기력이 하나도 없는 모습에 마음이 좋지 않았다.

노화란 인간으로 태어난 이상 피할 수 없는 숙명

거울을 보니 나도 예전같지 않다.

나이 드는게 나쁜 것만이 있는건 아니다.

젊고 새파란 시절엔 오히려 돈이 없어서 맨날 전전긍긍...

편의점에서 주스 사먹고 싶은 마음을 꾹 참고

그냥 학교에서 무료로 마실 수 있는 물로 갈증을 채웠고

항상 보급형 휴대폰을 쓰고 남들 다 스마트폰 쓸 때 난 폴더폰을 썼었다.

그러나 이제 많지는 않지만 돈을 조금이라도 벌면서

프리미엄 스마트폰을 쓰기도 하고

게임에도 현질도 하고

편의점에서 먹고 싶은거 마시고 싶은거 돈 생각없이 사먹는다

근데 울적한건 왜일까...

부모님의 기력없는 모습에 나의 어깨가 무거워진 탓일까?

나도 나중에 저렇게 무력해졌을때 옆에 누가 없을 걸 상상하니 무력해지는 걸까?

생로병사

생로병사란 사람이 반드시 겪어야 할 네가지 고통이라고 한다.

태어나고, 늙고, 병들고, 죽는 것을 말한다.

멋들어지게 늙고

병들지 않고

조용히 죽는 방법은 없는 걸까?

희망

나에겐 희망이 필요하다

더나은 미래가 기다리고 있을 희망

늙고 병들어도 괜찮을거라는 희망

불확실한 미래라도 감당할 수 있을 거라는 희망

그 희망은 어디에서 나오는가?

일단 태어났으니 살고 있다.

일단 취직을 해야하니 대학교를 갔다.

일단 돈이 필요하니 일을 하고 있다.

희망은 어디에 있는걸까?

누구는 가정을 꾸리기 위해 노력해서 결혼에 성공했다.

누구는 열심히 일하고 번 돈으로 여행을 다니며 삶을 즐기고 있다.

나는 무엇을 위해 사는 것일까?

만약 내가 로또 1등에 당첨이 되어서 경제적으로 여유가 생기더라도

이 느낌은 사라지지 않을 것이다.

나름 나만의 동기를 만들어 노력해봤지만

내 팔자에도 없는 걸 바래서 그런가 잘 되진 않았다.

그래도 아직 포기하진 않았다.

나의 희망은 언제쯤 오는 것일까? 아니면 언제쯤 얻을 수 있을까?

다람쥐 쳇바퀴 굴러가듯 살고 있는 삶이다.

그 속에서 먼 미래의 조그마한 희망을 갖고 싶다.

도파민이 뿜뿜 나올만한 변화를 바라는 것은 아니다.

갑자기 일확천금을 얻는 변화를 바라는 것도 아니다.

그저 내일이... 

그저 1년 후, 10년 후, 30년 후의 나의 모습이 괜찮을 거라는 희망을 바란다.

나의 하느님이 마련해준 내 삶의 여정은 어떤 식으로 흘러가게 될까?

부디 내가 감당할 수 있는 길이기를...

그리고 외롭지 않은 여정이길...

어느 토요일 밤

불광천이 보이는 분위기 좋은 카페에 앉아 노트북을 켠다.

사실, 일을 하려고 노트북을 가져왔지만

오후에 모두 했기에

무엇을 할까 고민하다가 

무작정 블로그를 켜본다.

카페는 완전 내 취향

노래도 잔잔하고

너무 시끄럽지도 너무 조용하지도 않은 소음

깨끗하고 큰 창문

창문 너머로 보이는 불광천

글을 몇번 쓰다 지웠다

굳이 의미있는 글을 써야할까?

그냥 내 생각의 흐름대로 키보드를 휘갈긴다.

사람이란 참 모르겠다

아니 나를 잘 모르겠다

나는 좋은 사람이 아닌 건 맞다

근데 좋은 사람의 기준이 뭘까?

사회와 환경에 따라서 기준의 잣대를 다 다르게 들이미는데

그렇다면 좋고 나쁜 것을 구분하는 건 의미없는게 아닐까?

근데 이건 있다

내로남불

내가하면 로맨스

남이하면 불륜

하핫... 한편으로는 내로남불이 뭐 어떠냐고 쓰고 싶지만

막상 내가 당하면 좀 가슴 아플거 같다

나는 의지가 약한건가

모르겠다

그리고 나는 사람을 잘 믿지 않는다.

내가 정직하지 못해서 그런가? 

내가 나쁜 사람이어서 그런가?

웃긴건 다 의미없다

보잘것 없는 한낱 인간의 생각일뿐

정말 쓸데없어

굳이 왜 이런 생각을 하는거고 이런 생각이 드는거지?

어짜피 죽으면 한줌의 재로 흩날리는 인생.

내 뼛가루를 흩날려줄 이라도 있을지 모르겠다

어쨋든 걍 대충 살자

생각하지 말고 그냥 고민없이 스트레스없이 대충 살자

안그래도 생각하고 고민할게 많은 인간의 삶인데

굳이 스스로에 대해서 생각해서 더 나를 고통스럽게 하지 말자

어짜피 운이 좋으면 될건 되고 운이 나쁘면 될것도 안된다.

인연도 마찬가지

애쓰지 않아도 알아서 이어지는 인연이 있는 반면

아무리 애를 써도 이어지지 않는 인연도 있는 법

여러 사람을 만나면서 확실히 나와 인연이 되는 사람들의 특징이 보인다

나는 누가 나를 자꾸 괴롭혀야한다

만나자고 하고 귀찮게 하고 부탁하고

나는 어쩔땐 싫어하면서 어쩔땐 좋기도하고 참 웃기네

그리고 중요한게 한가지 있다

내가 가끔 예민해져서

북풍 한설의 휘몰아치는 한줄기 고드름으로 심장에 못을 박아도

개의치 않고 평소와 동일하게 나를 귀찮게해야

좀 관계가 오래가는 것 같다.

유튜브인가 인스타인가

아름답다라는 말에서 아름은 나라는 뜻이라고 한다.

다시 말해서

꾸밈없이 진정한 나의 모습일때 아름답다고 한다고 한다.

맞아.

이게 나야

굽히느니 꺾여서 부셔지고 말지

그리고 귀찮아

아놔 이 글 쓰는 것도 귀찮네.

에휴 뭐하는 건지

이 동네까지 와서 이러고 궁상떨고 있네

모르겠다

모르겠어

그냥 대충 살자

내 인생 그리 좋은 일이 많진 않았지만

그래도 좋은 일 마니마니 생기겠지

내가 원하는대로 인생이 흘러가겠지

내 전성기는 아직 오지 않았어!

개굴개굴