[회고] 24.06 - #1. 상반기 회고, 사이드 프로젝트, 기침, 생활
24년도 절반이 지나갔다.
작년은 나에 집중한 해였다.
모두가 놀랄 정도로 취미 활동을 끝장봤다.
주변을 돌아봤던 여유로운 휴식기였다.
올해는 개발에 집중하고픈 한 해다.
충분한 휴식을 취했던 탓일까,
얼른 에너지를 쏟고픈 갈증이 일었다.
상반기와 6월 한 주를 회고하는 글이다.
생각도 정리하고 주변에 알리는 목적도 있다.
블로그하는 걸 티내서 였을까,
글을 원하는 독자가 생각보다 여럿 있다.
블로그엔 조회수를 취하는 정보 글을 올렸다.
그러다보니 개인적인 건 지양했었다.
지인이 원하는 건 뭘까?
가장 궁금한 건 근황이겠지.
남의 일기를 보는 것만큼 재밌는 건 없으니까.
다음으로는 동기 부여가 아닐까.
글을 쓰고픈 개발자는 주변에 많다.
일어나서 출근하고, 퇴근하면 운동가고, 집안일하면 잠 잘 시간이라 그렇지. 주말이라고 다를까.
물론 동기 부여를 얻는다고 행동으로 옮기진 않는다.
내가 못한 걸 대신 이루는 걸 보며,
일종의 ‘대리만족’으로 바라본다.
유투브에서 게임 실황과 먹방을 보는 이치와 같다.
덕분에 글을 쓰는 부담감이 준다.
내 글을 보는 이들이 충분한 정보를 얻었을까, 내가 쓰는 건 단순 카피가 아닐까, 는 타인의 시선에 많은 신경을 요하더라.
반면, 요즘 이런 일을 했고 저런 생각을 했다, 는 오로지 나에 집중한다.
나에 집중하는게 독자의 요구이기도 하니깐.
서론은 이정도로 줄인다.
24년 상반기 회고 - 구직, 스터디, 캠프
구직
4월까진 개발 캠프를 했다.
정확하겐 2월까지 참여했고, 4월까지 스터디를 했다.
개발에 집중하고픈 한 해여서 그런걸까.
다른 생각이 쉽게 자리를 잡지 않았다.
원래는 캠프 도중에 취업 준비도 하려고 했었다.
이력서도 다듬고 경력 기술서도 다듬고.
실제로 면접 보러 다니는 애들도 있었기도 했고.
취업 생각이 들지 않았다.
이 순간에 집중하고 싶었을 수도,
귀찮아서 일수도,
배가 불러서 일수도,
막막해서 였을수도,
막연한 두려움이었을 수도.
캠프가 그만큼 바빠서였을까?
캠프가 끝난 3~4월이라고, 미친듯한 구직 활동은 하지 않았다.
운영체제 스터디에 더 집중하고 싶었다.
1, 2월과 같은 이유일 수도 있지만,
어쨌든 개발에 집중하고픈 목적은 지켰다.
미친듯한 구직 활동은 5월에 했다.
이력서는 100개를 제출했다.
과제와 면접은 20번 이상을 봤다.
내 상황과 채용 시장의 수요가 일치하지 않아,
객관적으로 불리한 입장이었다.
유사 경험만으로 어필해야만 했다.
그조차 없는 사람은 지금 시장에 몹시 힘들다는 걸 알기에,
다행이라고 생각하고 있다.
불리했지만 예상보다 빠르게 최종 합격까지 가기도 했다.
확실히 여러 오퍼가 있으니 부담이 절반 이상 줄더라.
그리고 기준이 생길 수 밖에 없더라.
이력서에 블로그도 기재했기에,
구직과 관련한 내용은 일부러 올리지 않았다.
구직 활동의 결과는 만나서 듣기를.
운영체제 스터디
최근에 스터디를 궁금해 하는 분들이 많다.
후기를 따로 쓰지 않아 자세하게 적어봤다.
스터디는 총 7번 했다.
‘뇌를 자극하는 윈도우 프로그래밍’ 교재를 추천받았다.
오랜만에 들어본 시리즈라 흥미가 갔다.
듣자마자 바로 주문했었지.
책은 어렵지 않았다.
윈도우에 녹아든 운영체제 기술의 흐름을 전달한다.
핵심을 압축해 지엽적인 이론은 과감히 생략했다.
인원은 총 5명이다.
모두 캠프에서 만난 친구들이다.
3명이 학생이고 2명은 졸업자다.
모두 열정이 대단했다.
3명의 학생은 매주 SRT를 타고 판교까지 올라왔다.
힘들게 온 만큼 많이 얻어갔으면 했다.
퀴즈와 칠판으로 복기했다.
화이트보드라고 했지만, 지원 받은 장소는 노랑 배경의 칠판이었다.
책을 최대한 보지 않고 마커로 복기하는 방식이다.
교재는 흐름을 중시한다.
흐름에 맡기는 효과적인 스터디 방법은 무엇일까.
그에 대한 해답이었다.
퀴즈는 각자 3개씩 준비한다.
쉬운 난이도부터 생각해 볼 만한 퀴즈까지.
꼭 책에 국한되지 않았다.
30분이면 되겠지, 싶었다가 1시간까지 늘어났다.
문제를 소개하고 고민하고 토의하기까지.
5분에서 10분은 걸렸다.
5명이니 1시간이 걸리는 건 당연했을수도.
퀴즈로 흥미를 돋고 전체를 복기했다.
그 다음엔 칠판 복기다.
소단원을 적고 내용 흐름을 적었다.
왜 등장하고, 어떤 개념인지, 다른 개념과 차이점은 무엇인지.
윈도우 운영체제의 핵심으로 프로세스 핸들 테이블이 있다.
프로세스 핸들 테이블은 윈도우 커널 오브젝트와 매핑한다.
윈도우 API를 경험한 사람은 알겠지만 hWnd, 핸들이 무수히 나온다.
속 편히 ‘고유 아이디’ 정도로 알고 있었다.
OS가 관리하는 영역(커널 오브젝트, 자원 등)을 추상화했다.
프로세스단에서 독립적으로 관리한다. 부모-자식 프로세스 상속 관계가 아닌 한 영향을 줄 수 없다.
여러 OS 자원(프로세스, 파이프, 스레드, 파일 등)을 구분한다.
운영체제에게 요청하는 단위다.
운영체제와 애플리케이션, 애플리케이션 끼리의 통신을 제어하는 핵심 개념이었다.
지식의 습득도 중요하다.
그러나 우리는 교훈에 집중했다.
습득에서 끝나지 않고 확장하고자 했다.
OS에서 관리하는 자원을 추상화한 커널 오브젝트.
추상화한 커널 오브젝트를 효과적으로 관리하기 위한 테이블 개념.
자원을 제어하는 OS단과 애플리케이션단의 책임 분리.
작은 티켓으로, OS와 요청을 주고 받는 프로세스 핸들.
프로세스 간 독립된 프로세스 핸들 테이블로 이룬, 접근 제어의 유용성.
용어는 '결과'다.
문제는 '원인'이다.
원인에서 결과까지, 문제를 해결하는 '과정'이 있다.
'원인'과 '과정'에 집중했다.
선대는 이런 문제에 이렇게 접근했구나.
비슷한 문제에 이렇게 먼저 접근을 시도해야겠구나.
프로세스, 스레드, 뮤텍스, 세마포어가 무엇인지 아는 게 중요할까?
개발 인생에 무수히 들어볼텐데. 직접적이든, 간접적이든.
'결과'를 아는 것이 곧, '원인'과 '과정'을 이용할 수 있다는 걸 뜻하진 않는다.
기술을 배우는 이유는 무엇일까.
문제를 해결하기 위함이다.
문제를 정의(원인)하고 해결(과정)한다.
CS와 IT 공부는 '케이스 스터디'다.
원인과 과정의 'Best Practice' 를 알려준다.
물론 그 당시엔 그랬지만, 지금은 아닐 수도 있다.
그러나 과거에서 발전한다.
과거의 문제를 발견하고 해결한다.
히스토리를 모르면 이해할 수 없다.
발전한 '과정'도 결국 과거에서 얻은 다른 'Best Practice' 를 적응했을 뿐이다.
퀴즈와 칠판 복기로 흐름을 따라가며
이런 철학을 녹였다.
캠프에서 같이 경험한 것도 나누고,
각자가 프로젝트에서 경험한 것도 나눴다.
암기하는 '고통'보단
앞으로 다가올 문제를 해결할 수 있는
‘자신감’, ‘기대’, ‘호기심’을 챙겼으면 했다.
스터디를 하며 느낀점이 있다.
첫 번째는 더이상 C언어를 알지 않는다.
가장 충격이기도 했다.
교재 WinAPI 코드 이해가 어려웠다고 한다.
코드 자체에 거부감이 일어난다고 한다.
포인터, 구조체 지식이 없다.
잠깐 수업에서 스쳐 지나간, ‘무언가’에 불과했다.
또는 학습 경험이 전무하다.
나도 C언어를 실무를 하지 않았고 입문 정도는 가르칠 수 있는 정도다.
그러나 ‘C언어 코드 = 저수준 = 이해할 수 없는 것’ 으로 인식되는 게 안타까웠다.
메모리를 배우고, 인다이렉트 참조를 배우지만,
C언어 포인터에 거부감이 든다.
‘과정‘을 실행해주는 ’도구‘를 익히지 못하는 것과 같다.
낫 놓고 기역자를 모르는 농부를 보면, 이런 기분일까.
그깟 ‘결과’를 모르는 건 중요치 않다.
필요할 때마다 학습하면 언젠가 이해되는 순간이 올 거다.
두 번째는 스터디는 하는 게 아니다. 만들어 가는 거다.
이를 가능케 하는 건 ‘심리적인 안정감’이다.
IT 업계에선 스터디가 활발하다.
아마 안해 본 사람을 찾기 힘들지 않을까 싶다.
좋은 스터디란 무엇일까?
모두가 만족하는 방법은 무엇일까.
우리 또는 주변과 나눠본 스터디 경험은 다음과 같다.
1. 친한 사람과 해야 한다.
2. 세미나는 발표하는 사람만 공부한다.
3. 퀴즈를 하는 게 재밌고 도움이 되더라.
4. 이끄는 사람이 중요하다.
등...
절대적으로 좋은 스터디를 찾는 것보다,
‘우리에게 맞는 스터디’를 찾아야 한다는 걸 깨달았다.
친한 사람과 해야 한다?
모르는 사람과 이야기를 잘 나누는 사람끼리는 큰 상관이 없다.
세미나는 발표하는 사람만 한다?
모두가 잘 알고 있는 주제면 보다 깊은 의견을 주고받을 수 있다.
그런 경험을 원하는 집단에겐 더 없을 것이다.
퀴즈를 하면 좋다?
누군가에겐 준비하는 게 부담이 될 수도 있다.
이끄는 사람이 중요하다?
참여하는 사람이 열정이 없다면 어쩔 수 없다.
인강 세대는 누구보다 잘 알고 있다.
뭔가를 많이 해야 한다?
정해진 시간에 모여 처음 책을 읽고 이야기를 나눠도 만족하는 케이스도 있다.
스터디는 우리가 만들어 가는 거다.
우리만의 입김이 들어갈 수록, 애정이 생긴다.
애정이 들어갈 수록, 몰입이 높아진다.
몰입이 높아질 수록, 학습의 효과는 커진다.
첫 단추가 중요하다.
우리만의 입김이 들어가야 한다.
이를 가능케 하는 건 ‘심리적인 안정감’이다.
단순하게 말해, 내 의견을 편하게 말하는 분위기다.
이 분위기는 사람마다 다르기도 하다.
누구는 친해야만 가능하기도 하고,
관심사가 맞아야만 하기도 하고,
비슷한 사람이어야 하기도 하고,
타인의 시선에 민감한 사람은 힘들기도 하다.
즉, 스스로가 편하다고 느껴야 한다.
스스로 편하다고 느끼는 환경을 알아야만 한다.
운이 좋게 맞을 수 있지만
다른 사람이 대신할 순 없는 영역이다.
각자의 입김이 들어간다면
모두가 편한 환경일 것이다.
편하다면 애정과 몰입이 생긴다.
애정과 몰입이 생기면 학습 효과가 커진다.
다소 서툴더라도 나의 시간, 정성이 들어간 것에
눈길이 가고 애정이 생기는 것과 똑같다.
스터디도 마찬가지다.
캠프
캠프는 이미 다른 글에서 많이 언급했다.
한 두번 투정 부리긴 했어도
놀랍게도 스트레스를 받은 적은 없었다.
주변에서 걱정하기도 했지만
정작 나는 아무런 걱정이 없었다.
오히려 뭐가 문제지? 싶은 반발심만 들더라.
이렇게 말하면 근거없이 낙관적이고 무감각한 사람으로 보이겠지.
스트레스를 받지 않았다고 고민하지 않은 건 아니다.
다른 이의 탓으로 돌리지도 않았다.
나와 이야기를 나눠본 지인은 잘 알 것이다.
두 달이라는 시간 동안 재밌었다.
소속감도 좋았고
판교에 사는 지인과 만난 것도 좋았고
많은 이야기를 나눈 것도 좋았고
좋은 인연을 만난 것도 좋았고
개발에 몰입할 수 있어서 좋았다.
그 외의 감정은 느낄 새도 없었다.
물어보지 않고 판단하는 건 언제나 좋지 않다.
전혀 색다른 시선을 알 수 있을 것이다.
사이드 프로젝트
현재 두 개의 사이드 프로젝트를 하고 있다.
하나는 부동산 투자 분석 서비스,
하나는 AI 활용 알람 앱.
전자는 올해 초부터 했고,
후자는 얼마 전에 작업했다.
부동산 투자 분석 서비스
부동산 서비스는 기간이 길다.
구현이 많은 건 아니고
현생을 고려했다.
여유롭지만 진행은 착착 되고 있다.
기술보단 비즈니스에 초점을 맞췄다.
그렇다고 기술력에 없는 건 아니다.
내 서버 분야와 직접 관련이 없을 뿐,
초기 스타트업 기술력 정도는 확보했다.
핵심은 데이터다.
데이터를 수집하고 가공한다.
어떻게 수집할 지, 어떻게 가공할 지,
최대 고민이다.
모두가 효율을 낼 수 있는 고민을 하고 있다.
데이터 파이프라인, 스트리밍,
Pandas 라이브러리,
대용량 데이터 관리, 데이터 모델링
조회 성능 향상,
의 주제에 집중하고 있다.
처음에는 간단해 보였지만,
도메인을 알면 알수록,
기능이 들어갈수록,
도전해보고픈 열정이 솟았다.
AI 활용 알람앱
알람앱은 기간이 짧다.
빠른 프로토타입을 만드는 게 목표다.
각자 원하는 욕구를 채우고자 한다.
고도화는 그 이후다.
공통적으로 AI를 활용한 서비스를 만드는 것이다.
우후죽순으로 많은 LLM 서비스가 나오고 있다.
생태계에 살짝 담가 보는 게 목적이다.
모바일 개발자 형은 이번 기회에 플러터 개발 경험을 쌓는다.
챗지피티와 코파일럿의 힘을 과감히 쓰고 있다.
디자이너 형은 AI 서비스 포트폴리오를 쌓는다.
간단한 프로젝트지만 개발자 지인 둬서 어따 쓰랴.
이런 데 쓰는거지.
나는 책과 강의에서 배운 걸 실전으로 쓰고 있다.
가장 신경 쓴 건 멀티 모듈이다.
멀티 모듈로 기능을 분리한다.
다른 모듈과의 연동은 ‘의존성 역전’으로 해결한다.
모듈을 이렇게도 나누는구나, 를 몸소 깨닫고 있다.
데이터베이스와 밀접한 테이블 엔티티와 도메인 객체를 분리한 게 핵심이다.
테이블 엔티티가 도메인의 기능을 수행할 순 있지만,
데이터베이스 벤더와의 의존성을 없애보고 싶었다.
도메인 모듈은 도메인 전용 언어로 기술된다.
더이상 데이터베이스와 같은 인프라에 영향을 미치지 않는다.
완전한 도메인 객체만의 세상을 만들었다.
인프라는 도메인을 어떻게 저장하고 불러올지만 걱정하면 된다.
혼자 개발하는 터라 모듈로 나눈 게 크게 와닿지는 않는다.
유즈케이스 모듈과 인프라 모듈을 연동할 때 ‘포트(Port)' 라는 인터페이스로 의존성 역전을 이용한다.
스프링 프레임워크에서 의존성 주입을 지원한다.
즉, 다른 모듈의 구현체는 자동으로 매핑된다.
어떤 구현체가 올 지는 현재 모듈에선 전혀 신경쓰지 않는다.
단지 인터페이스로 구현 책임을 넘긴다.
한 프로젝트를 분업할 때 효율적이라고 느꼈다.
한 모듈로 만드는 것보다 결합도가 낮다.
원하는 모듈만 임포트해 접근 권한을 제어한다.
즉, 다른 모듈의 영향을 최소화한다.
예측 가능한 범위로 축소시킨다.
고민은 여러 모듈에서 사용하는 기능은 어떻게 분리할지다.
특히 스프링 서블릿을 사용하는 곳은 어디로 한정해야할 지 고민이다.
일단은 여기 저기에 스프링 의존성을 넣고 있긴 하다.
API 모듈보단 보안 모듈에서 관리하는 게 맞지.
추후엔 도메인 영역을 견고히 설계하고
조회 영역과 쓰기 영역을 도메인과 인프라단에서 분리해보려 한다.
모바일에서 자체 DB를 가지고
서버와 ’동기화‘하는 통신 규약을 잡았다.
이 구조와 맞는 적절한 아키텍처라고 생각한다.
건강, 기침
입사하기 이틀 전인가.
공포 방탈출에서 비명을 몇 번 질렀다.
끝나고 목이 좀 잠겼더라.
그렇게 많이 지르진 않았는데...(아닐수도..)
잠깐 이러다 말겠지 싶었다.
다음 날, 완전히 잠겼다.
잔기침이 나기 시작했다.
열, 콧물, 가래, 몸살 증상은 없는 걸 보면,
감기는 확실히 아니다.
말하거나 숨을 쉴 때 잔기침이 심해서
강제로 차분하고 조용한 이미지가 됐다.
얼마 전 병원을 가니,
위산이 역류해 식도나 후두를 강타하는 것 같다,
라는 진단을 받았다.
자세한 진단은 아니지만,
목과 구강 점막은 멀쩡하다더라.
식도가 빨갛게 조금 부어있다더라.
예전에도 위염, 역류성 식도염으로
심하게 고생한 적이 있다.
무려 2년 동안.
그럴 수도 있겠다, 바로 수긍했다.
원인을 조절하면
자연스레 기침도 나을 거라고 본다.
소화 문제는 쉽사리 낫지 않는다. 특히 나에겐.
일주일 마다 경과를 살펴보자더라.
집 근처 주상복합이 완공했다.
그 곳에 이비인후과가 개업했다.
짧은 시간을 진료했지만,
발음도 또박또박하고 논리적으로 쉽게 설명하신 게
인상적이었다.
카메라로 코와 구강을 살펴보는데,
카메라 화질이 무척 선명하더라.
나도 볼 수 있게 배치했다.
기분이 묘했지만, 신뢰가 갔다.
주변 이비인후과를 갔으면...
그냥 감기약 지어졌을 것 같다.
호흡기에 좋은 이상한 스프레이와 적외선만 쐬고...
근처 병원에 신뢰가 안가던 터라 다행이었다.
그나저나 얼마나 놀랐으면
위산이 역류해 후두, 기도를 강타했을까.
그 날은, 첫 번째 사이드 프로젝트 같이 하는 형이
결혼식을 올린 날이었다.
뷔페를 맛있게 먹고 부랴부랴
방탈출을 하러 간 게 화근이었나 보다.
다음엔 끝나고 밥을 먹으리라.
회사 가야해서 스트레스 받은 거 아니냐.
주변 지인의 우스갯소리가 들린다.
오랜만에 직장을 다니던 터라,
매일 즐겁고 설레던 터라 스트레스는 받지 않고 있다.
의외로 아침 6시에 일어나는 아침형 인간이 되었다.
생활
루틴
아침에 일어나면 생각한다.
더 잘까?
얼마나 잘 수 있지?
그럴 때 이불을 박찬다.
냉수 한 잔을 마신다.
밤새 쌓인 위산을 청소한다. (중요)
찬 물에 세수하고
세수한 김에 머리까지 감는다.
그렇게 20분이 지나간다.
오늘 할 일을 생각한다.
집에서 할 일, 회사에서 할 일.
물론 거창한 건 아니다.
반드시 지켜지는 것도 아니고.
다만, 이 시간을 가지는 것과 안 가지는 것은 다르다.
이 시간이 없다면, 하루에 몸을 맡긴다.
시간에 몸을 맡기고, 하루가 지나간다.
내가 어디로 흐르고 있는지 점검할 필요가 있다.
그렇지 않으면, 내가 어디에 있는지 갈피를 못 잡게 된다.
이를 ‘루틴’ 이라고 부르더라.
습관은 무의식으로 일어난다.
반면, 루틴은 의식적으로 행한다.
의식적이라는 건, 그 목적을 바로 알고 이용하는 것이다.
회사를 제외한 시간에
무엇을 하면 좋을지 아직도 고민이다.
짧다면 짧고, 길다면 긴 시간이다.
자기계발 유투브를 보거나
책을 보거나
기술 공식 문서를 보거나
해외 아티클을 보거나
사이드 프로젝트와 블로그를 하고 있다.
위 4줄은 ‘입력‘이다.
마지막 줄은 ‘생산’이다.
입력도 좋은 활동이지만,
되도록 생산을 하고프다.
지금도 생산을 크게 하고 있지 않다.
아무래도 몰입하기 쉽지 않다.
예열이 필요하고 동기 부여가 필요하다.
적절한 시간에 체력이 뒷받침되어야 한다.
모든 이가 동의할 것이다.
이 글은 출퇴근 지하철에서 쓰고 있다.
’생산‘이지만 비교적 머리를 쓰지 않는다.
근황도 전할 겸, 머리도 정리할 겸.
지식 전달 목적인 ’생산‘은 모바일론 쉽지 않긴 하다.
출퇴근 시간이 긴 것도 도움이 됐다.
주변에선 걱정을 하지만,
오히려 생산 활동에 도움이 됐다.
그럼에도 걱정의 눈빛을 보내지만.
지하철을 한 번 환승한다.
7호선에서 46분. 3호선에서 26분.
글을 쓰는 데 더없이 최적이다.
몰입하기 위한 예열 시간은 못해도 10 ~ 20분이 든다.
의미있는 생산도 적어도 20 ~ 30분은 넘어야 한다.
그런 점에서 예열하는 데 도움이 된다.
만약 20분, 20분 정도로 짧았다면?
절대적인 출근 시간은 짧다.
그러나 출퇴근 시간엔 난 아무것도 할 수 없다.
가까스로 입력이라도 하면 다행이다.
금전 감각에 빠삭한 업을 하는 지인이 있다.
내가 가진 시간의 가치를 환산하고
출퇴근에 버린 시간만큼 계산한다.
대출 이자금과 비교하면 억단위의 손해를 본다고 한다.
바로 설득 당했지만... ㅋㅋㅋ
그걸 상쇄할 만큼의 비전과 전략을 갖추려고 노력해야지.
출퇴근 시간이 무서운 게 아니다.
입력과 생산을 할 수 없는
무의미한 시간을 두려워해야 한다.
라고 말하고,
나중엔 출퇴근 시간이 길어서 징징댈 수도 있다.
그럴 땐 좋은 입력과 생산을 추천해달라.
블로그
블로그는 늘 애증의 관계다.
잘하고 싶지만, 쉽사리 변하지 않는다.
마치 4년 전 만든 앱을 갈아 엎겠다!
라는 열정은 불타오르지만,
실행은 하지 않는다.
‘잘한다’는 절대적이고 객관적인 지표를 뜻하는 건 아니다.
내가 만족하는 양질의 컨텐츠를 만들고,
내 생활 전반을 올바르게 유지해주는 것이다.
결국 ‘내’가 만족해야 하는 것이다.
예전부터 양질의 컨텐츠를 만들고픈 목적이 컸다.
그게 8년 전이니, 잘 지켜지진 않은 셈이지.
글이 완벽해야 한다, 라는 관념에 사로잡혔다.
다음 블로그 목표는 더 짧게, 더욱 자주다.
이 글만 해도 길다.
출퇴근 시간에 적다 보니 며칠을 적었겠는가.
의도적으로 짧게 포스팅하려 한다.
소프트웨어 원칙 중 ‘단일 책임 원칙’이 있다.
인간의 뇌는 여러 개를 한 번에 처리하지 못하므로,
범위를 하나로 줄여 빠르게 받아들이도록 해준다.
전하고픈 주제, 목적에 맞게
핵심만 빠르게 짧게 작성하려고 한다.
쉽지 않겠지만.
여담도 짧게 언급할 거다.
다른 포스팅으로 만든다.
그러면서 포스팅을 하게 될 원동력을 얻게 되리라 기대한다.
양이 짧아 텅 비지 않을까 싶지만,
‘더 자주’ 목표도 함께 달성할 수 있을 것 같다.
‘더 자주’를 이루는 또다른 방법은
정기 콘텐츠를 만드는 거다.
특히 시리즈를 기획하면
글짓기의 첫 단계인 글감 정하기가 바로 해결된다.
그리고 템플릿을 만든다.
정해진 플로우에, 내용만 채우면 되게끔.
내용 구조, 구성에 관한 고민도 최대한 없앤다.
당장 방탈출 리뷰 글만 봐도 구조화 되었다는 걸 알 수 있다.
강의 글 대신, 리뷰 글을 올리는 걸 좋아하는 데엔 이유가 있더라.
뇌는 쉽고 편한 걸 좋아한다.
작성하기 쉬운 주제에 마음이 가는 걸 인정했다.
이 글처럼 날짜를 붙인 것도 그 이유다.
월마다 정기 컨텐츠가 생긴 거고,
생각날 때마다 개인 회고를 작성하면 된다,
라는 일련의 파이프라인이 생겼다.
이를 따르기만 하면 된다.
뇌가 더이상 개입할 여지가 없다.
좋은 컨텐츠가 있다면
언제나 추천받는다.