2021년 메모
- 2021-01-01
- 2021-01-02
- 2021-01-05
- 2021-01-09
- 2021-01-13
- 2021-01-14
- 2021-01-15
- 2021-01-16
- 2021-01-24
- 2021-01-31
- 2021-02-05
- 2021-02-11
- 2021-02-13
- 2021-02-19
- 2021-02-20
- 2021-02-25
- 2021-03-01
- 2021-03-04
- 2021-03-06
- 2021-03-08
- 2021-03-12
- 2021-03-16
- 2021-03-18
- 2021-03-19
- 2021-03-21
- 2021-03-23
- 2021-03-26
- 2021-03-28
- 2021-04-04
- 2021-04-05
- 2021-04-06
- 2021-04-10
- 2021-04-15
- 2021-04-24
- 2021-04-27
- 2021-04-28
- 2021-05-01
- 2021-05-15
- 2021-05-19
- 2021-05-30
- 2021-06-08
- 2021-06-11
- 2021-06-29
- 2021-07-02
- 2021-07-04
- 2021-07-05
- 2021-07-07
- 2021-07-10
- 2021-07-12
- 2021-07-14
- 2021-07-20
- 2021-07-27
- 2021-07-28
- 2021-07-29
- 2021-08-01
- 2021-08-03
- 2021-08-05
- 2021-08-07
- 2021-08-08
- 2021-08-10
- 2021-08-15
- 2021-08-16
- 2021-08-27
- 2021-08-29
- 2021-08-30
- 2021-08-31
- 2021-09-03
- 2021-09-06
- 2021-09-07
- 2021-09-11
- 2021-09-17
- 2021-09-20
- 2021-09-23
- 2021-09-24
- 2021-09-25
- 2021-09-29
- 2021-10-03
- 2021-10-04
- 2021-10-05
- 2021-10-07
- 2021-10-08
- 2021-10-10
- 2021-10-11
- 2021-10-12
- 2021-10-14
- 2021-10-15
- 2021-10-17
- 2021-10-19
- 2021-10-20
- 2021-10-21
- 2021-10-23
- 2021-10-25
- 2021-10-25
- 2021-10-29
- 2021-10-30
- 2021-11-07
- 2021-11-08
- 2021-11-10
- 2021-11-11
- 2021-11-14
- 2021-11-19
- 2021-11-21
- 2021-11-25
- 2021-11-27
- 2021-11-29
- 2021-12-02
- 2021-12-03
- 2021-12-09
- 2021-12-10
- 2021-12-19
- 2021-12-21
- 2021-12-22
- 2021-12-26
- 2021-12-27
- 2021-12-28
- 2021-12-30
- 2021-12-31
2021-01-01
욕심을 버리는 한 해가 되자.
올해에는 내 성격(조급한 마음, 예민한 마음, 서두르는 마음)을 고치자.
2021-01-02
새벽 배포 작업을 마쳤다.
2021-01-05
일단 결정했으면 오래 붙들고 있는 거, 대단한 능력이다.
2021-01-09
조급해하지 말고, 중요한 일을 제일 먼저 하자. 급한 일보다 중요한 일 먼저. 어렵지만 해보자. 할 수 있다.
지난 6개월을 돌아보니 와장창 실수 대행진과 자신감 폭락 뿐이었던 것 같은데, 가만히 생각해보니 좋은 일도 많았다. 내 두뇌가 안 좋았던 것들만 과장해서 회상하는 것 같다.
좋았던 일, 즐거웠던 일을 떠올리자.
2021-01-13
퇴근길. 윌라로 오디오북을 듣고 있다. 가입하면 한 달 무료. 넷플릭스 창업자 마크 랜돌프의 "절대 성공하지 못할 거야"로 첫 책 시작. 되게 흥미로운 제목인데 처음 온라인 비디오 배달 사업 구상을 할 때 랜돌프의 아내가 웃으면서 “절대 성공하지 못할 거야”라고 했던 말에서 나온 것이라 한다.
2021-01-14
불량 모니터 반품하고 새 모니터를 사서 설치 완료. 잘 나오니 상쾌하다. 좀 피곤하긴 하다. 책상과 방은 난장판이 됐다. 이제 치워야지.
2021-01-15
유튜브 "인기"를 눌러보면 재미없을 것 같은 영상들만 줄줄이 나오는데 내 취향이 트렌딩에서 많이 떨어져있기 때문인 것 같다. 아무리 스크롤을 내려봐도 보고 싶은 게 전혀 없음. 한편 홈은 내가 자주 찾아보는 영상과 비슷한 영상을 많이 보여줘서 별로 신선하지 않다.
새로운 영상을 발견하려면 어떻게 해야 하나? "최근 인기 동영상"도 쭉 내려 봤는데 모두 내 취향과 전혀 맞지 않아서 클릭하고 싶은 영상이 없다.
2021-01-16
어렸을때부터 게임을 참 좋아했고 아직도 게임을 많이 하고 싶은데 그러면서도 게임이 전혀 하고 싶지가 않다. 게임을 하면 불안할 것 같고, 마음이 초조할 것 같다. 내가 자기계발로 인한 불안감에 빠진 상태인 것 같다.
작년 7월 무렵부터 급격한 기억력 저하로 엄청난 스트레스를 받았는데, 최근 동료들에게 털어놓고 나서 마음이 조금 편해졌다. 동료들은 업무 스트레스 때문에 그런 거 아니냐고 걱정해주시던데 음 뭔가 부정적인 루프가 있었던 듯.
2021-01-24
오후 2시부터 3시까지의 낮잠이 몸과 마음의 건강에 도움이 되는 것 같다. 하루에 30분 이상 낮잠을 자려면… 회사를 다니면서는 힘들겠구나. 점심시간에 20분 정도 잠깐 자는 수 밖에는 없는 걸까.
2021-01-31
가슴이 답답하다. 나에게 부족한 것만 자꾸 생각하는 나날이다. 내가 이미 갖고 있는 것들, 행복한 것들을 생각하자. 나는 지금도 행복하다.
2021-02-05
FireFox의 vim 플러그인인 Tridactyl 을 쓰기 시작했다.
2021-02-11
산의 심장이자 보석 중의 보석인 아르켄스톤을 빌보 배긴스가 훔쳤을 거라고 의심한 소린이 빌보를 돌려세우자 빌보가 도토리 하나를 들고 있었다는 사실이 드러난 장면을 좋아한다. 고향에 돌아가면 이 도토리를 심어 나무로 기를 거라고 대답하는 그가 기억에 오래 남는다.
이때 빌보 배긴스가 진짜로 아르켄스톤을 간직하고 있었지만 어떠한 탐욕도 없었다는 것이 절묘한 점. 그러나 그렇게 순수한 마음과 우정을 지닌 그가 샤이어로 갖고 간 것이 골룸에게서 훔친 절대반지라는 것이 아이러니하다.
2021-02-13
개인 프로젝트 안 한지도 너무 오래됐다. 집에서 퇴근 후에도 회사 일만 하고 있는 자신을 인지할 때 현타가 오는데 뭔가 다시 몰두할 만한 걸 시작하고 싶다. 요즘은 그냥 블로그만 하네.
2021-02-19
"칭찬은 고래도 춤추게 한다"라는 말을 들을 때마다 생각나는 것이 있다. 아마 사기꾼은 다른 사람을 조종하기 위해 칭찬하는 스킬부터 익힐 거라는 거.
2021-02-20
듀오링고 777일 달성.
하루에 한 번씩은 블로그에 글을 쓰거나, 문단 하나 정도를 추가하거나, 있던 글을 수정하거나, 적어도 오타라도 찾아서 고친다. 이게 벌써 3년이 넘었네… 이젠 개발보다 블로그 관리가 더 재미있다.
생각해보니 그냥 블로그에 글 쓰고 오타 찾아서 고치고 하는 게 내 가장 큰 개인 프로젝트인 것이다. 별 거 아니지만 내가 행복하니 됐다.
2021-02-25
오늘은 너무 힘든 날이었다. 삶이 고단하다. 그러나 힘내야지.
불평하지 말자.
2021-03-01
귀멸의 칼날 무한열차 보고 왔다. 막바지에 눈물 펑펑 쏟았네.
2021-03-04
제대로 일하고 싶다 좀
2021-03-06
하루에 딱 한 가지만 하려 해야지. 여러 가지 하려다가 한 가지도 못 해내는 날이 수두룩하다.
2021-03-08
동료들과 이야기하다 내가 입사한 후 업무와 별개로 팀을 위해 내가 가장 노력했던 건 팀에서 관리하고 있는 코드의 하한선을 높이는 활동이었다는 것을 깨달았다. 그리고 상당한 수준으로 성공했다는 것도 깨달았다. 은연중에 알고는 있었지만 어쩌다 표현을 하고 보니 확 와닿았다. 해낸 것이다.
환상적이라거나 엄청 멋있는 일을 한 것과는 거리가 멀었다. 그러나 내가 한 일은 분명 가치있는 일이었다. 지난 1년 4개월은 헛되지 않았다. 조금 감동했지만 좀 더 생각해보니 엔지니어라면 당연히 해야 할 일이었다.
내가 해야 하는 업무와 별개로 그 하한선을 천천히 높여가는 같은 일을 다시 해야 한다면 더 잘 할 수 있을 거라 생각한다. 이미 해봤으니까. 어느 팀에 가건, 어느 회사에 가건 더 잘 할 수 있다고 생각한다.
내가 평생 바라는 것은 무언가를 해내는 사람이 되는 것이다. 나는 내 단점도 아주 잘 알지만 그래도 내가 만족한 하루를 얻었으니 오늘은 스스로를 축하하고 칭찬하며 잠들 수 있겠다. 걱정도 근심도 많은 요즘이지만 적어도 오늘 저녁 퇴근하는 동안 나는 내가 바라는 인물에 가까운 사람이었다.
2021-03-12
같이 일하는 동료가 나한테 잘해주면 내가 잘나서 그러는 게 아니라 그 사람 인품이 좋아서 그러는 것일 가능성이 높다는 것을 잊지 말자. 그리고 고마워할 줄도 알자…
고맙다고 말할 타이밍 놓쳤다고 잠자코 있지 말고 꼭 말해야지. 쑥쓰러워도 말할거야.
2021-03-16
듀오링고 800일.
2021-03-18
회사는 내가 시니어이길 바라는데 내가 생각하는 나는 시니어가 아니고… 조금 우울하군. 하지만 최선을 다 해야지.
2021-03-19
- 온라인이건 오프라인이건 남을 무시하는 말을 하는 습관이 있는 사람을 조심해야 한다. 혹시 내가 그런 사람이 아닌지도 늘 생각하자.
- 언젠가부터 휴대폰으로 게임을 전혀 하지 않는다. 다른 사람들도 그럴까? 일단 내 경우엔 유튜브와 전자책 앱이 게임 앱을 완전히 대체해버렸다.
2021-03-21
난 코딩하는 것보다 생각하는 것, 생각하는 것보다 공부하는 것을 더 좋아하는 것 같다. 충분히 생각하지 않고 바로 손을 올려놓는 코드 작성은 나에게는 그닥 속도가 안 나는 것 같다. 예전엔 안 그랬는데 이젠 성향이 바뀐 것 같기도 하다.
2021-03-23
김창준님의 더 많은 일을 하면서 더 빨리 하기는 벌써 꽤 오래된 글이지만 언제 읽어도 용기와 영감을 얻는다. 특히 나처럼 공부하는 사람에게 너무 좋은 글이다.
2021-03-26
10년 후에 나는 어떤 일을 하고 있을까? 지금 무엇을 해야 10년 후에 후회하지 않을까?
2021-03-28
명료하게 생각하고 싶다.
알고 있다. 내가 나 정도면 조금은 잘 한다고 할 수 있겠지.. 싶을 때가 제일 위험하다는 것. 다만 요즘 못하는 게 너무 많아서 시시각각 자괴감이 드는데 이런 하나의 감정이 몹시 소중한 것이다. 내가 코딩도 못하고 이것도 못하고 저것도 못하지만 이거 하나는 그래도 조금은.
그래서 회사생활이 두렵다. 어떤 마음가짐을 갖고 일하는 것이 좋을까? 떠날 곳이라 생각하고 일하는 것은 자본주의 사회 속 현대인의 상식이지만, "마지막 회사"로 생각하고 "내 회사"로 생각하고 일할 수 있는 곳을 과연 언젠가는 만날 수 있게 될까. 그런 회사는 만나는 것일까 만드는 것일까.
지금 회사로 이직하던 날 생각했다. 여기서는 얌전히 있지 말자. 그랬더니 회사가 바뀌어갔다. 나 혼자만의 힘으로 된 것은 아닐 것. 회사가 바뀌어가는 과정에 내가 입사했기에 그렇게 보인 것일 수도. 설령 인과 없이 수반된 사건이라 하더라도 내 행동에 따라 환경이 바뀌어가는 경험은 놀라웠다.
행복한 경험이다. 주목을 받게 되니 하는 일도 조금씩 바뀌어간다. 시선과 기대가 느껴진다. 회사에서 말을 가려 하는 것은 당연한 일이지만 한두 번씩 더 생각하고 말하게 되었다. 더 신중하게 행동할 수 있으면 좋겠다. 품위에 대해 생각한다. 장인의 품위를 갖고 싶다. 품위있게 일하고 싶다.
회사원으로서의 나는 일을 더 잘 하고 싶을 뿐이다.
2021-04-04
재미는 평균적으로 친절하고 재치있는 동료들에게서 얻는 경우가 더 많았다. 친절하고 재미있고 건강한 표현을 사용해 말을 하는 동료들이란 얼마나 소중한지.
하지만 지구상 어디엔가는 정말 재미있는 일을 하는 회사가 있지 않을까. 그런 회사를 한번은 다녀보고 싶다. 그런 회사는 어디에 있을까. 아 이런 생각을 하니 너도나도 자기네 회사가 재미있을 거라고 하는 거구나.
2021-04-05
스스로 자기 인성 나쁘다고 자랑스럽다는 듯이 말하는 사람과 어울릴 생각은 없다. 돌아보면 평생 너무 많은 시간을 그런 사람들에게 허비한 것 같다.
2021-04-06
마켓컬리 채용 설명회 라이브 유튜브에 출연했다. 나는 1:12:40 즈음부터 나온다.
2021-04-10
남들 다 하는 것 같다고 나까지 할 필요가 없었던 것들을 생각한다.
2021-04-15
나는 생각보다 중요한 사람이 아니며 주위 사람들은 내 생각보다 나에게 별로 관심이 없다는 것을 깨닫은 것은 중요한 일이지만 너무 잘 깨달아도 문제인 것 같다. 하지만 이걸 너무 늦게 깨달아도 곤란.
2021-04-24
스마트 민방위 교육을 들었다.
2021-04-27
4월 24일부터 Jim Gray의 1981년 The Transaction Concept: Virtues and Limitations를 읽고 있다. 유머러스한 설명이 있어 참 재미있다. Jim Gray의 실종이 안타깝다.
2021-04-28
자신을 프로라고 생각하고 프로답게 행동하자.
2021-05-01
전직장 여기저기에 문구가 붙어있었다. "나도 누군가에겐 회사다" 회사를 욕하는 사람들을 살펴보면 회사가 싫기보다는 상사나 동료가 싫은 경우가 꽤 있다는 데에서 착안한 문구라고 기억. 나도 누군가에겐 회사일 수 있으니 주위를 돌아보고 언행을 신중히 해야 한다. 회사는 나만의 공간이 아니다.
특히 회사 내에서 영향력을 가진 사람이라면 더더욱 주의해야 한다. 내가 던진 농담 한 마디는 내가 던진 "웃자고하는 이야기"가 아니라, 누군가에게는 회사를 평가하는 기준이 된다. "구질구질하고 혐오스러운 말이 오가는 이 회사 확 퇴사하고 말지…" 같은 생각을 하게 된다는 것.
판타지소설에 나오곤 하는 인과율을 생각한다. 영향력이 있는 인물일수록 원인과 결과를 고려해 말하는 이들이 존경받는 듯하다. 내 영향력이 작다면 인과율의 제약도 적다. 그러나 영향력이 크다면, 즉 이끄는 조직의 규모가 크다면 인과율의 제약을 고려해야 한다. 말과 행동에 원인이 있어야 한다.
2021-05-15
유명한 재벌2세에게 거대한 오토바이를 선물받아서 맨몸이어도 어려운 높은 계단을 오토바이로 부왕 올라갔다가 다시 내려온 꿈을 꾸었다. 오토바이 힘이 대단해서 평소 생각도 못한 계단 오르내리기가 되어서 신기했다. 헬멧이 없어서 집에 어떻게 가져가지 하다가 꿈에서 깸. 하하 개꿈이네.
2021-05-19
2017년부터 써온 맥북 프로의 usb-c 포트 4개 중 하나가 먹통이 됐다. 으어.
2021-05-30
중요하지 않은 것들을 적당히 무시할 수 있어야 현명하다.
2021-06-08
인터랙티브 디벨로퍼 김종민님의 “일은 배신하지 않는다”를 끝까지 읽었다. 읽으며 여러 감정이 밀려와 몇 번씩이나 눈물이 났다. 특히 마지막 401~463페이지가 참 좋았고 기억에 오래 남을 것 같다.
김종민 님의 구글 입사 과정은 놀라운 이야기였지만 일에 대한 자세와 접근 방법, 삶의 철학 등에 대한 그분의 이야기가 좋았다. 내가 할 수 있었던 일들과 내가 선택하지 않았던/못했던 것들을 생각해 본다. 내 주위도 둘러본다. 나 자신에 대해서도 다시 생각해 본다.
2021-06-11
하하 전문가가 되고 싶다.
2021-06-29
회사 동료가 내 블로그 rss를 구독하고 있다고 한다. 업데이트가 올라올 때마다 열심히 살아야지 한다고. 내가 뭔가 하고 있는게 다른 사람에게 의욕을 준다니 나도 포기하지 말고 열심히 살아야지.
2021-07-02
요즘 능력의 한계를 느낀다. 힘들다. 해낼 수 있을까. 이번에도 할 수 있겠지. 힘을 내자.
2021-07-04
취미를 생각해보니 듀오링고 뿐이어서 뭔가 서글프다. 예전엔 게임을 참 좋아했고 책도 다양하게 읽고 운동도 나름 열심히 했고, 영화도 열심히 보러 다녔는데.. 2011년부터 게임은 가끔 폰으로 퍼즐 게임이나 잠깐 하는 정도고 책도 대부분 개발책 뿐. 운동은 이제 거의 안 한다.
지인과 친구들도 많아 주기적으로 모여 이야기도 많이 했지만 살다 보니 연락이 많이들 끊겼다. 먹고 살기 위해 자기개발에만 집중하다 보니 많은 것이 풍화된 느낌. 전염병 시국이나 어서 끝났으면 좋겠다.
난 이야기하는 것을 좋아한다. 사람들이 내 이야기에 귀를 귀울여줄 때 대단한 행복감을 느낌. 2020년 판데믹 이후에 깨달은 것은 내가 스스로 내성적이라 생각했던 내 성격이 착각이었다는 것. 나는 사람들과 만나 이야기하는 것을 좋아한다. 몇달간 재택한 끝에 얻은 깨달음이었다.
그래서 대화하며 작업하는 짝코딩, 코드 리뷰도, 화이트보드에 낙서하며 같이 코드 디자인 궁리하는 것도 좋아한다. 같이 이야기하는 분이 생각을 구체화하기 위해 말을 멈추고 천장을 보는 순간 같은 것도 엄청 좋아한다. 어떤 이야기가 나올까. 회의를 하며 다른 분들 말을 기록하곤 한다.
요즘 괴로운 것 컨텍스트 체인지. 이거 했다 저거 했다 반복되는데 내 메인잡과 관련된 컨텍스트가 기억 안 남. 다른거 하고 오면 동료들은 이미 저만큼 작업해놓고 논의도 끝내놨음. 자괴감 생기고 동료들에게 죄송한 마음. 무능감 때문에 매일 감정이 바닥으로 떨어진다. 피터의 법칙 생각이 난다.
음~ 모르겠다. 이럴 시간에 공부를 하거나 문서를 읽자.
2021-07-05
지난 3달간 생각만 한 걸 이제 했다. wiki 디렉토리 하나에 모든 문서가 들어가 있는게 그동안 계속 신경쓰였는데.. 이제 서브 디렉토리를 만들 수 있게 작업했다. vimwiki까지 뜯어고치거나 포크해서 다른거 만들까 했었지만 커스터마이징 필요없었고 데이터 수집 js 파일만 몇 줄 고침. 후련하다.
이제 짬날 때마다 하나씩 하나씩 디렉토리 만들어서 옮겨야지. 하나하나 써온 블로그에 벌써 마크다운 파일이 581개. 관리하기 점점 힘들어졌는데 아주 조금만 고쳐서 이렇게 운영할 수 있어 기쁘다.
전혀 난이도 높은 작업이 아니었다.
vimwiki는 이미 \[[dir/filename]]
과 \[[/dir/filename]]
형태의 문법을 제공하고 있었고, jekyll 도 nested markdown 파일을 잘 빌드해 주고 있었다. 고쳐야 했던 건 내가 2017년에 짰던 코드들.
2021-07-07
듀오링고 913일째. 생각해보니 쓰기 문제에서는 키보드로 답을 입력하지 않고 아이폰의 "받아쓰기" 기능을 써서 타이핑하면 더 공부가 될 것 같아서 일주일째 해보고 있다. 어렵지만 꽤 괜찮은 것 같다. 요즘 좋은 자극이 되는 중.
한편 아무리 말해도 어려운 문제도 있는데 She is the fourth queen
같은 문장은 아무리 말해도 아이폰은 내 말을 She is the poor skin
으로 듣는다.. 그래도 하다보면 언젠간 늘겠지.
2021-07-10
블로그 카테고리랑 부모문서 링크 만들어주는 기능 다 뜯어고쳤다. 4년짜리 레거시라 속이 다 시원하군.
2021-07-12
오늘, 올해 첫 휴가다.
2021-07-14
벌써 내 블로그 사이트맵에 들어 있는 url이 600개구나. 걍 기억 보존용 개인 블로그가 여기까지 오다니 좀 신기하다. 20대때 만들었다 관리를 안해 결국 삭제하게 되었던 여러 블로그들을 떠올려본다.
그럭저럭 블로그를 오래 하다보니 황당한 일들도 가끔씩 겪는다. 그중 앗 이건 좀 그렇지 싶은 건 내 블로그의 Google Analytics ua 값을 그대로 사용하는 경우. google search console에 들어가면 내 블로그 통계랑 포크한 블로그들 통계가 함께 보인다. 아니 host 주소 검사 안하냐 구글?!
블로그 repository fork하는 분들 마음도 이해는 하는데, 내 자기소개 정도는 지우고 사용하셨으면.. GA ua 값도 자기 것으로 수정하셨으면.. 내 이름 한 글자가 들어간 파비콘도 수정하셨으면..
2021-07-20
오늘은 반차를 내고 좋은분(엔라이즈 CTO 김문수님과 백엔드 리드 하시는 분(성함이 기억 안남))들을 원격으로 만나 대화하는 시간을 가졌다. 대화를 하며 많이 배우기도 했고, 기분 전화도 되어 즐거웠다. 이런 시간이 더 많았으면 좋겠다.
2021-07-27
아내와 함께 두 시간쯤 걷고 돌아왔다.
둘 다 재택근무를 하고 있어서 함께 5일째 24시간 동안 한 시도 떨어져 있지 않았다. 오 약간 신기록 느낌. 평생 이렇게 누구랑 오래 붙어있는데도 계속 기분이 좋은 사람은 아무도 없었던 것 같은데. 지금은 거실에서 둘이 마주보고 메론 먹으며 이야기한다.
2021-07-28
요즘 듀오링고 난이도를 올리기 위해 타이핑 문제는 아이폰 받아쓰기로 하는데 오늘의 난관은 girl. “걸” 하면 call이 나오고 “거얼” 하면 car가 나와서 한참 고생했다. 10분 넘게 삽질한 후 루이님의 코칭을 받아 “글”이라 말하면 girl이 된다는 것을 알게 되었다. 오늘 하나 배운 것 같아 기쁘다.
걸과 거얼에서 아이폰이 거의 99% call 과 car 로 알아듣는 걸 보고 L과 R발음의 차이에 대한 공부도 되었음. 한편 내가 구사하는 한국어의 ㄱ발음은 내 생각보다 ㅋ에 가까운 발음인 것 같다. ㄱ+ㅏ 발음이 하 처럼 소리가 튀어나와 ca 처럼 되기 딱 좋은 느낌. “글”은 ㄱ이 낮게 흘러나오는 느낌.
2021-07-29
오늘의 듀오링고. 몇 주간 내가 “This is”를 하면 높은확률로 “DC”나 “Decision”으로 아이폰 받아쓰기가 알아들어 고생했는데, 어제 일로 얻은 깨달음으로 “디스 이즈”가 아니라 “드스 이즈”로 하니 갑자기 잘 알아듣기 시작. 와! 디스 이즈가 아니라 드스 이즈로 해야 받아쓰기가 잘 알아듣는구나!
2021-08-01
https://github.com/p0deje/Maccy
지금까지 mac에서 써본 중 제일 괜찮은 클립보드 매니징 앱 같다. 지금까지 몇 년간 hammerspoon으로 클립 보드 매니저를 만들어서 쓰고 있었는데 주저 없이 이걸로 갈아탔다.
2021-08-03
내가 지쳤다는 사실을 인정하니 다음 할 일이 보인다.
2021-08-05
손목이 좀 아픈 가운데 문득. 발로 키보드를 쓰면 발목 터널 증후군이 올까? 발목 터널 증후군이 없다면 연습해볼만한 가치가 있지 않을까?
2021-08-07
다음은 내가 트위터에 쓴 글을 옮겨온 것이다.
꽤 긴 타래가 될 것 같다. 자의식 과잉일 수도 있겠지만 생각을 말끔히 풀어내기란 어려운 일이고 나는 이야기를 풀어보며 상황을 객관적으로 돌아보고 싶다. 무엇보다 생각의 앞뒤를 정리하고 싶다.
2달 후면 개발경력 만 9년이 된다. 먹고살기 위해 꾸역꾸역 일하다보니 주위의 기대를 받고 있다. 시니어 소리도 듣고 있다. 당혹스럽다. 실력을 짚어보면 시니어라는 단어가 버겁다. 두렵다. 그러나 어떨 때에는 어디에 있는지도 모르는 스위치를 찾아야 한다. 그래야 어두운 방의 불을 켤 수 있다.
2019년부터 2020년까지를 돌아보자. 괜찮았던 일들의 연속이다. 회사에 합류한 이후 테스트 코드 도입하고, 코드 리뷰 도입하고, git 사용 방법을 밑바닥부터 바로잡았다. 나는 git을 아주아주 좋아하고, git의 내부 구조부터 설명하는 것을 즐긴다. 이런 설명이 꽤 쉽고 재미있었다고 한다.
한편 회사 기술 블로그를 다시 만들고 사람들을 격려해 글을 써서 올리기도 했다. 매주 세미나에 참석해 내가 아는 것들을 공유했다. 가능한 한 자세하고 친절한 문서를 작성하려 했다. 이런 일들이 많은 업무에 지쳐있던 동료들에게 신선한 자극이 되었던 것 같다.
입사한 지 한 달만에 연말 타운홀 미팅에서 상을 받았고, 다음해에는 승진도 했다. 그리고 연말에 상을 또 받았다. 감사하게도 내 의견이나 제안에 지지해주시는 분들이 많았다. 칭찬해주시는 분들이 많으니 자연히 우쭐해지게 된다. 그리고 기대에 계속 부응하고 싶어진다. 이제 문제가 발생한다.
누군들 안 그렇겠느냐마는 나는 한 번에 한 가지 일을 할 때 생산성이 좋다. 시간을 들여 도메인 지식을 파악하고, 앞뒤관계를 살피고, 촘촘하게 계획해서 일을 진행하는 것을 좋아한다. 이 맛에 일한다고 생각한다.
나는 어떤 일을 할 때 반드시라고 해도 좋을 정도로 문서를 작성하면서 업무를 진행하는데, 이런 업무 습관은 항상 좋은 평가를 받았다. 이것이 가능한 이유는 우습게도 내 기억력이 좋지 않기 때문이다. 나는 다음날엔 머리가 포맷이 된다. 문서를 남겨두지 않으면 다 까먹는 것이다.
그래서 문서에 대해 고민하며 살아간다. 아무것도 모르는 내일의 나에게 보내는 편지. 친절할 수 밖에 없는 것이다. 글 쓰는 것도 좋아한다. 그런 성향이 잘 맞았는지 동료들도 내 문서를 좋아했다. 문서화를 좋아하는 개발자가 드물다던데 나에게는 좋고 나쁨의 문제가 아니다. 문서화를 해야 한다.
당장 해야 할 일들의 컨텍스트를 일목요연하게 표현하고, 지나가면 히스토리가 되는 문서들은 나에게만 도움이 되는 것이 아니다. 적절히 쌓인 문서는 개발팀의 발 밑을 튼튼하게 다져준다. 회사의 자산이다.
나는 업무 신념 하나를 얻게 되었다. 내가 일을 잘 하게 만들기 위해 일하자. 팀이 일을 잘 하게 만들기 위해 일하자. 그러므로 나를 위한 문서를 작성하자. 누군가 회사를 떠나도 문서는 오래 남아 길잡이가 된다. 그런데 문제는 점점 예상도 못한 다양한 일이 할당되기 시작했다는 것.
갑자기 이런상황이 되니 두려운것은 시간. 끔찍하게 빨리 흘러간다. 업무 집중력이 떨어졌을 때에도 흘러가고, 누군가와 면담을 하고 있는 동안에도 흘러가고, 의사 결정을 하기 위해 문서를 작성하고 읽고 생각하는 동안에도 흘러간다. 문제: 하나라도 딜레이가 생긴다면 다른 모든 일이 큐에 쌓인다.
컨슈밍 속도보다 큐에 쌓이는 속도가 커져서 극복하기 힘든 상황이 되면 마음 속에 돌덩이가 생긴다. 재빠르게 동료와 상사에게 공유하고 해결해야 하는데 이것이 쉽지 않았다. 자신감이 말라붙다. 바보가 된 기분에 빠져 종일 우울하게 보내며 꾸역꾸역 일을 한다.
토비 맥과이어는 스파이더맨2에서 벽을 타지 못하는 피터 파커 연기를 했다. 그는 스파이더맨 코스츔을 입은 상태로 엘베를 타고 건물에서 내려가야 했다. 나는 요즘 그런 피터 파커를 자주 떠올린다. 많은 일이 즉흥적으로 결정되거나 내 시야 바깥에서 흐름이 바뀌지만 벽을 타고 내려갈 수 없다.
빨리 따라가야 한다고 생각하지만 초초하므로 다음 버스를 기다리지 못한다. 좋지 않은 선택이란 것을 알면서도 떠나간 버스를 계속 따라간다. 해법은 단순하다. 좀 쉬었다가 그냥 다음에 오는 버스를 타면 되는 것이다.
누군가는 앗 당신 번아웃이야 하고 이야기를 해줬다. 번아웃이라는 생각은 안 들었다. 일은 어떻게든 하고 있다. 다른 사람이 한 걸음 걸을 때 두 걸음 걸으면 따라잡을 거라고 생각했다. 하지만 굉장히 짜증이 났던 어느 날 오후. 기운이 빠지는 것을 느꼈다. 몸이 젖은 양말처럼 바닥에 늘어졌다.
어떤 일도 할 수 없었다. 그래서 반차를 쓰고, 그 다음날은 휴가를 썼다. 일 할 의욕이 어디에도 없었으므로 일을 할 수 없었다. 그게 2주 전이다. 코드도 안 나오고, 문서도 안 나온다. 손가락이 키보드 위에 멈춰 있다. 신기하게 회사와 관련 없는 코딩은 잘 된다. 이것을 뭐라 불러야 한단 말인가.
휴가를 충분히 내면 되는 걸까? 이직하면 괜찮아질까? 고민 끝에 팀을 이동해 보기로 했다. 현명한 선택인지는 모르겠지만 큐가 쌓여서 터진 거라면 재시작을 해야겠지. 또는 재시작이 가능한지 알아봐야겠지. 당장은 아니지만 팀을 이동해 보면 많은 것이 리셋되지 않을까.
내가 바라는 하나는 다시 일에 몰두하는 것이다.
그러고보니 올해 휴가 1.5일 썼다. 생각해보니 벌써 8월이다. 내년까지 20주 밖에 안 남았다. 남은 휴가가 13.5일이니까 마주 반차를 써도 휴가가 3.5일 남는다. 다음주에 좀 쭉 이어서 쉬어볼까…
이에 대해 다음과 같은 감사한 조언과 격려를 받을 수 있었다.
시미어 개발자들이 흔히 겪는 문제. 읽어볼만한 타래. https://t.co/z6bczg5FXX
— 편전 (@pyeonjeon) August 7, 2021
시니어 개발자로 넘어가는 과정이 많은 사람들에게 있어 정신적으로 쉽지 않은 것 같다. 일의 범위가 넓어지면 당연히 작은 일에 집중할 수 있던 때만큼 코드를 짤 수는 없는데, 날 포함한 많은 사람들이 여기에 큰 죄책감을 느끼고 그게 상당한 스트레스로 이어진다. https://t.co/gA7WoALF9s
— 어엉부엉 (@d_ijk_stra) August 7, 2021
놀랍게도 관리자로 한참 왕성하게 일하면서 퇴사를 결심했던, 그리고 제일 안좋았던 내 경험과 똑같은 길.
— JP.Jung_대마왕 (@JPcorps) August 7, 2021
저 길이 잘못됐다기 보다는 너무 내 스타일에는 힘들었다의 이야기.
지금 다시 하라면 그때보다는 잘 할 수도 있을 것 같지만 스트레스는 여전할 것 같은 트라우마가 있다 https://t.co/BS7YMxu1om
저는 이런 상황에서... 내가 이런 상황이란 걸 자신이 인식도 못했었고, 남에게 설명도 못 했을 만큼 닥치는 상황에 따라 떠밀려 갔었는데... 이런 분석과 객관화를 한 것 자체가 대단하시네요~ https://t.co/F6QPZOxKSv
— WyChang 데헷~ (@10bosal) August 8, 2021
2021-08-08
하루에 두 번 자는 거 너무 좋다. 회사에서도 꼭 낮잠을 챙겨 자야 오후 일을 더 잘 할 수 있다고 생각해서 늘 점심먹고 낮잠을 잤는데 생각해보니 올해는 거의 낮잠을 못 잤다.
정정. 오후에 일을 더 잘 할 수 있다고 생각해서 => 오후 3시쯤 스멀스멀 brain fog 끼면서 아이큐 떨어지는 기분이 낮잠을 자면 안 느껴져서. 그게 그거 같긴 하지만 좀 더 개인적인 이유.
2021-08-10
그동안 매일 잔여백신 예약에 실패하다, 오늘 드디어 10부제 백신 예약에는 성공했다.
2021-08-15
오늘은 아내랑 종일 중요한 일 여러 가지를 처리했다. 깜빡하고 있었던 지방세도 냈고, 에어콘도 기사님을 불러 청소를 마쳤고, 집안 가구 구성도 여기저기 조금씩 위치를 옮겨서 집을 더 넓게 만들었다. 아 쾌적하고 재미있는 하루였다.
거실 한쪽 벽에 내가 좋아하는 마그리트의 그림을 걸었다.
TV가 있는 쪽 거실도 전선이 하나도 안 보이게 정리. 이사온 지 3년 만에 다시 이사한 것 같네.
2021-08-16
집안 정리를 하다 남는 매뉴얼이 있길래 매뉴얼 바인더를 꺼냈다. 가전이나 가구 등 각종 살림살이에 딸려온 매뉴얼을 보관하는 바인더. 하나하나 넘기며 둘러보는데 아내와 함께 고른 밥솥, 세탁기, 토스터, TV 등 설명서가 보인다. 당시의 웃긴 추억들도 떠올라 피식피식 웃는다.
내가 바인더로 매뉴얼 관리하는 방법은 하나다. "아이템을 집어넣을 때 제일 앞에 넣는다."
이 규칙을 지키면 새 매뉴얼은 앞에 들어간다. 그리고 문제가 생겨서 중간에 꺼내 읽은 매뉴얼도 앞으로 들어간다.
이러면 앞에서부터 넘겨보면 최근 문제가 있었던 가전/가구부터 하나씩 보게 된다.
보통 살림을 하면서 매뉴얼을 한 번 찾은 가전이나 가구는 또다시 찾게 될 가능성이 높으므로 이런 MRU 전략이 유용할 것이라 생각했다. 경험적으로도 검색하기 쉬워 좋았다.
이 방식은 클리어 파일로는 관리가 어렵다. 바인더가 쉽다. 한 번 읽은 매뉴얼을 비닐봉투째로 빼내어 읽은 다음, 제일 앞으로 보내야 하기 때문이다. 하지만 가전에 문제가 생겼을 때 매뉴얼을 못 찾아 겪는 수고로움을 생각하면 이 정도의 최근 히스토리 우선 인덱싱 관리는 감안할만 하다.
2021-08-27
지금 코딩하고 있는 프로젝트가 좀 재미있다. 거의 모든 클래스가 메소드를 딱 한개씩만 갖고 있음. 그래도 잘 돌아간다. 아직까진 깔끔하고 읽기 좋음. 프로젝트 후반에는 달라질 수 있겠지만, 일단 지금은 그동안 고민했던 것들을 잘 털어넣으며 개발중.
떠올려보면 1~2년차일 때 코드와 매우 다른 모습을 갖고 있다. 그때에는 클래스 하나에 메소드 수십개씩 쑤셔넣기도 했던 것. 생각해보니 그 때에는 쪼개는 방법이나 요령 몰랐고 왜 쪼개야 하는지도 생각하지 못했던 것 같다. SRP라는 좋은 힌트가 있었는데도 머리로만 알고 실천은 못했던 것.
그동안 작성했던 코드를 생각하니 아찔한 느낌도. 9년차가 되어서야 알던 것들을 알음알음 실천하게 되다니 싶어 부끄럽기도 하고, 이제서야 하는 게 어디인가 싶기도 하다. 한편으로는 지금 작성하는 코드도 미래의 내가 보면 어수룩하고 어리보기 같겠지. 다시금 겸손을 배우는 것이 중요하다 싶다.
아무튼 다른 회사는 몰라도 내가 일하는 환경에서는 쉬운 코드가 최고. 무조건 읽기 쉬워야 좋다. 읽기 쉬워야 뭘 추가할 때에도 아 여기구나 하고 빨리 찾고, 읽기 쉬워야 버그가 있어도 아 이거구나 하고 빨리 찾고, 읽기 쉬워야 다른 사람에게 인수인계해줄 때에도 아 그게 이거군요 바로 알겠네. 한다.
이건 내 성향이기도. 일단 돌아가게 만들고, 시간을 두고 조금씩 고쳐가는 게 재미있고 취향에 맞는다. 근데 코드를 알아볼 수가 없다면 시간을 두고 조금씩 고치는 게 삐걱거린다. 알아봐야 뭐든 한다. 성능을 향상시키려 해도 알아봐야 하고, 버그를 고치려 해도 알아봐야 한다.
2021-08-29
휴대폰에 오래된 광고 메시지가 너무 많길래 점진적으로 삭제해가기로 했다. 날 잡아서 한번에 정리하는 건 내 스타일이 아님.
- 광고 메시지 1개를 받으면,
- 방금 받은 광고 메시지를 삭제한다.
- 아무렇게나 스크롤을 내리다가 발견한 삭제할만한 메시지 1개를 삭제한다.
이걸 반복하면 되겠지.
- 광고 메시지가 아닌 메시지를 받으면?
- 메시지를 확인한다.
- 그리고 아무렇게나 스크롤을 내리다가 발견한 삭제할만한 메시지 1개를 삭제한다.
2021-08-30
술보다 안 좋은게 자기 자신에게 취하는 것. 특히 부정적인 의미의 자신에게 취하는 것은 그냥 안 좋은게 아니라 몹시 나쁘다. 이걸 깨달았을 때 알콜중독 치료하듯 털어내야 좋은 것 같다. 어떤 사람은 욕설을 잘하는 자신에게 취하고, 어떤 사람은 상점에서 무리한 요구를 잘하는 자신에게 취한다.
2021-08-31
나도 드디어 COVID-19 백신 맞았다. Pfizer.
2021-09-03
오늘 동료 두 명과(3명이 함께) Code with me로 작업하면서 엄청 들떴다. 다들 재밌어서 시간가는 줄을 몰랐음. 3시간 동안 10분 쉬었고, 밀린 일을 상당히 처리할 수 있었으며 너무 즐거워서 퇴근한지 3시간이 지난 지금까지 좀 들떠 있는 상태. 일정보다 훨씬 앞당겨서 일을 끝낼 수 있을 것 같다.
2021-09-06
요즘 회사일 재밌다.무조건 페어로만 코딩중. 나는 이 팀 도메인 지식이 부족해서 페어하면서 도움받고, 원래 팀에 계셨던 시니어 개발자님은 원래 나랑 서로 흠모하기도 했고 내 코드 디자인 스타일을 좋아하셔서 합이 잘 맞는다. 요즘 개발속도가 무지무지 빠르다. 3시간이 미친듯이 흐른다.
JetBrains의 CodeWithMe를 잘 쓰고 있다. 재택근무하는 3명이 함께 코딩을 하는데, 내가 테스트 코드 짜기 시작하면 한 명이 음성 대화하면서 fixture 만들고, 다른 한명이 구현체 시그니처 작성시작. 작업은 일단 내가 주로 주도하고 있어서 좔좔좔 끊임없이 계속 말해야 한다는 게 좀 피곤.
처음엔 둘이서 병렬로 두 개 파일 수정하는 게 빠를 거라고 생각했는데, 실제로 해보니 그렇지 않다. 두세 명이 파일 하나 열고 스워밍하면 순식간에 뚝딱. 그리고 다음 작업 대상으로. 스타크 저글링 무리 중 한 마리가 된 기분. 속도감이 장난아닌데 퇴근시간 알람 듣고 "벌써?" 하고 놀란다.
그런데 CodeWithMe 문제 많다. 특히 여러 명이 같은 파일을 작업할 때 제일 윗줄 편집하던 한 명이 엔터치면 밑에 줄에 난리가 난다던가.. 컴퓨터 배터리도 엄청 잡아먹는다. 아답터 연결하고 작업중인 맥북 배터리가 줄고 있는 걸 보고 경악. 메모리 누수도 있는지 5시간 작업 후에는 재부팅해야했다.
작업은 이렇게. Slack hurdle로 내 모니터 화면 공유하면서 내 컴퓨터를 CodeWithMe 호스트로 삼아 동료 둘이 접속. 먼저 작업 요구사항과 TODO를 문서로 정리해 놓고, 문서의 체크리스트를 체크해가며 내려가는 식으로 함께 작업. 방심하면 목이 쉬니 옆에 생수통이랑 물컵을 필수로 갖다놔야 한다.
함께 작업하니 주의가 분산되지 않는 것이 가장 좋다. 혼자 작업하면 코딩하다 마음에 안 드는 부분 나타나서 파고들어서 코드 읽고 아 여기 이번에 고칠까 다음에 고칠까 지워버릴까 이런 고민하다가 시간이 무심히 흐르는데, 여럿이 하니 이런 일이 없다. 멍때리는 시간이 사라져서 몰입도 잘 된다.
2021-09-07
일렉트론 기반 데스크탑 앱들 리소스 사용량 때문에 스트레스. 슬랙만 써도 메모리 낭비가 어마어마. 일렉트론으로 인한 탄소 발생량도 엄청나겠지.
2021-09-11
크레이그 라만의 책을 읽다가 "갯수"라는 단위를 영어로 어떻게 표기하는지 찾아보는 중인데, "ea"가 "갯수"를 표현하기에 적합하지 않다는 글이 여럿 있다. 4개 != 4 ea. 그런데 그 대안이 뭐가 있는지 써놓은 글은 아직까지 못 찾았네. 이렇게 하면 안된다는 글만 잔뜩. 더 찾아봐야겠다.
2021-09-17
요즘 레거시 하나 각잡고 리팩토링하는데 무척 재밌다. 계속 테스트 작성하고 고치고 테스트 작성하고 고치고.
2021-09-20
낙서와 메모가 있는 중고책을 읽을 때에는 속으로 열심히 1 챕터만 참고 읽자고 생각한다. 2챕터부터는 낙서가 현저하게 줄어들고, 3챕터부터는 거의 새 책이나 다름없어지는 경우가 많다.
2021-09-23
또 세면대 물이 천천히 내려가길래 아침에 각오를 단단히 하고 세면대 밑 배관을 풀어 깨끗하게 청소를 했다. 지옥에서 올라온 것 같은 덩어리를 한주먹 만큼 빼냈고 이제 물이 콸콸 잘 내려간다. 매번 비용을 써서 뚫곤 했는데 이젠 내 손으로 할 수 있다. 스스로 할 수 있게 된 것이 가장 기쁘다.
탄산을 쓰는 미스터 펑이니 하수구 뻥 용액 등 이젠 안녕~ 특히 용액을 쓰는 건 환경에도 나쁘지 않을까 하는 걱정이 많았는데 이젠 그냥 배관을 풀어 내부를 긁어내고 다시 조이면 된다고 생각하니 기분이 좋다.
2021-09-24
나는 월간 기록을 매월 말일이 아니라 다음달 1일에 한다. 이유는 매월 말일이 매번 달라지기 때문. 어떨 때에는 31일이고 어떨 때에는 30일이고, 어떨 때에는 28일이고… 매월 1일에 지난 한 달을 기록하면 뭔가 좀 더 규칙을 지킨 느낌이 좋다. 이것도 강박일까. 아무렴 어때 내가 기분이 좋은데.
2021-09-25
마인드 스톰 완독. 아침에 읽기 시작해 방금 다 읽었네. 오래간만에 하루 안에 책을 다 읽어 뭔가 보람찬 기분.
2021-09-29
요즘은 출근하면(물론 대부분 재택) 리팩토링 6시간, 기능 추가 2시간씩 하는 것 같다. 코드가 몹시 복잡해 혼란스럽지만 그래도 나름의 보람이 있다. 코드의 산더미 속에서 이제 정돈된 구획이 하나씩 생겨난다.
2021-10-03
해냈다 듀오링고 1000일!
2021-10-04
블로그 문서가 600개가 되었다.
2021-10-05
나도 드디어 COVID-19 백신 2차 맞았다. 이번에도 Pfizer.
2021-10-07
요즘 현관에서 루이님 신발을 볼 때마다 루이님이 바깥으로 신고 나가기 편하게 문 쪽으로 신발을 돌려놓는 습관을 들이고 있다. 신발장 정리는 덤. 아주 작은 일인데 흐뭇하고 좋다. 출근하실 때 1초 정도 조금 더 편하고 조금 더 기분 좋으시겠지.
결혼 생활이 행복하다.
2021-10-08
짝 코딩에 뒤늦게 푹 빠졌다. 시간이 엄청 빠르게 흐르고 일도 엄청 빠르게 쳐낸다. 짝이 있어 다행이다. 다음 회사를 고를 땐 꼭 짝 코딩 가능한지를 봐야지.
2021-10-10
시험 없고 과제 없고 일정 압박이 없으면 공부가 즐겁고 재미있다. 그래서 앞으로도 평생 즐겁게 독학을 할듯.
마음껏 공부할 수 있도록 상당한 여유 시간이 있다면 좋겠다.
2021-10-11
10년전에 산 "패턴을 활용한 리팩터링"을 지난 일주일간 다 읽었다. 그땐 어려워서 1챕터 읽다가 포기했었는데, 이제는 재미있게 읽어서 일주일간 무척 즐거웠다. 다행이라 느끼는 한편, 이런 내용을 나만 몰랐다가 이제야 알게 됐겠구나 싶어 서늘하기도 하다.
아무튼 다 읽어서 상쾌하다. 아직 오후 5시 밖에 안 됐으니 다음 책을 읽도록 하자. 다음 책은 그레이트 코드 3권. 2권은 구하지 못해 아직 못 읽었지만 언젠간 기회가 오겠지.
2021-10-12
요즘 떠오른 아이디어가 하나 있어 컨트롤러 클래스 패키징을 실험적으로 배치해보고 있다. 아이디어는 이렇다.
- 컨트롤러 하나가 API URI 하나를 담당하게 한다.
- URI 경로를 그대로 패키지 경로로 사용한다.
배드 아이디어일 수도 있지만 나름의 장점이 있다고 느껴 기록해본다.
보통은 컨트롤러 클래스 하나가 여러 엔드포인트를 갖게끔 코딩을 해왔고, 그런 코드를 많이 봤다. 하지만 이 방법은 조금 다르다. 가령 상품과 관련된 컨트롤러가 있다고 하자. URI가 /shop/product/
라고 할 때 패키지를 아예 web/shop/product
이런 식으로 만들고 이 안에 컨트롤러를 배치한다.
그리고 그 컨트롤러는 해당 URI에 대한 HTTP method 처리만 한다. (처음 컨셉은 이랬지만 지금은 이것도 분리했다) 만약 다른 URI가 필요하다면 해당 URI에 맞춰 패키지를 구성하고 새 컨트롤러를 그 위치에 만들어 준다.
이렇게 하면 컨트롤러 하나가 엔드포인트 딱 한개만 담당하게 된다. 그리고 URI와 패키지 경로가 일치하기 때문에 IDE 안에서 디렉토리 구조만 보고 해당 컨트롤러 클래스 파일을 찾아내기가 무척 쉽다.
그리고 그 컨트롤러에서만 필요로 하는 리퀘스트 객체와 리스폰스 객체도 package private으로 만들어준다. 이렇게 해보니 엔드포인트 관리가 꽤 쉬웠고, RestDoc 테스트코드를 작성할 때에도 테스트 파일의 사이즈도 이전에 비해 많이 작아졌다.
한편 URI 구성에 대해 계층구조로 표현한 명사의 집합관계라는 컨셉을 분명히 인식하며 URI를 디자인할 수 있었다. 자원의 아이디로서 계층구조의(/로 구분된) URI를 제공한다는 걸 동료들과 함께 인식하니 커뮤니케이션도 편리했다.
아직까지 단점은 거의 못 느끼고 있다. 패키지가 깊어지고 각 컨트롤러 클래스에 메소드가 한두개만 있다는 정도? 난 이건 오히려 장점이라고 생각한다. 패키지가 깊어져도 URI만 알아도 컨트롤러를 금방 찾아서 문제가 안 된다. 그리고 일단 배포하면 URI는 바꾸는 일이 드물기 때문에..
web 패키지 하위의 패키지들은 거의 불변으로 가져가게 된다. 만약 어떠한 URI를 더이상 서비스하지 않게 된다면 해당 패키지(와 그 안의 클래스)만 삭제하면 된다. 여러 URI를 리커시브하게 삭제할 일이 있어도 상위 패키지(디렉토리)만 삭제하면 된다.
URI에 버저닝이 포함되어 있는 경우도 마찬가지. 다음과 같은 API를 사용하는 업무 환경이라면
web/v1/product/product-a
web/v2/product/product-a
패키지 이름을 보고 아직 v1 이 남아있다는 걸 알 수 있고, 얼마나 v1에서 v2로 넘어왔는지도 쉽게 파악할 수 있다.
이 아이디어를 떠올린 건 2년 전에 [[#people.roy-fielding#]]{로이 필딩}의 [[/clipping/roy-fielding/rest-paper]]{논문}을 읽었을 때였는데, 차일피일 미루며 의견을 이야기하지 않고 있었다.. 하지만 이번에 팀이동을 한 김에 이렇게 해보고 있는데 나도 대만족, 같이 페어 프로그래밍하는 최선혁님도 대만족. 선혁님은 이런 생각을 왜 못했을까 하며 싱글벙글.
요즘 리팩토링하고 있는 프로젝트가 구조가 상당히 복잡했는데 이 방법을 도입하면서 컨트롤러를 하나씩 이 방법으로 발라내면서 관련 로직도 리팩토링하는 중. 리팩토링 진행도를 디렉토리 구조를 통해 파악할 수 있다는 장점도 있다. 결과가 눈에 보이니 작업도 즐겁고, 이동 방향도 가시적.
로이필딩 논문 이야기를 한 김에. 로이 필딩은 자원의 표현형을 전달하는 방식(REST)에 대해 이야기할 때 식별자가 중요하다는 말을 한다. 웹은 본래 다른 컴퓨터의 리소스를 이 컴퓨터에서도 조회하기 위해 만들어진 것. 자연스럽게 "/" 기호로 구분된 디렉토리/파일 구조의 식별자를 사용하게 됐다.
따라서 내 컴퓨터의 파일을 잘 찾기 위해서는 디렉토리 구조를 잘 갖추고 파일을 적절한 위치에 잘 저장해두면 도움이 되는 것처럼, 남의 컴퓨터의 자료도 디렉토리 구조가 잘 갖춰져 있으면 탐색용이성이 높아진다. 따라서 URI-디렉토리-집합의 개념은 모두 관계가 있다.
즉 이상적인 URI는 모두 /생물/동물/척추동물/포유류/강아지
와 같은 주소의 이념을 바탕으로 설계된다. 왼쪽으로 갈수록 상위 집합이며, 오른쪽으로 갈수록 하위 집합이다. 많은 URI가 이런 구조를 갖는다. 다음 URI도 하나의 트윗에 도달하기 위한 계층구조를 갖고 있다.
나는 이 지점에서 이 아이디어를 얻었다. 이런 식으로 URI를 구성하는 이유 중의 하나는 탐색 용이성 때문이다. → 그렇다면 컨트롤러를 배치할 패키지를 구성할 때에도 똑같은 방법을 사용하지 못할 이유는 무엇인가?
그래서 해보니 나름의 장점이 있고, 요즘 즐겁게 코딩하고 있다는 이야기.
아 맞다 남현우 님을 만났을 때 이 이야기를 했는데 리치 히키가 네임스페이스에 대해 한 이야기를 알려 주셨음. 인상깊고 즐거운 대화였다.
2021-10-14
아이폰 13 미니가 배송됐다. 오 그동안 써온 아이폰 7보다 조금 더 작네?
2021-10-15
오늘 페어 프로그래밍 동료 선혁님께 매우 즐겁고 행복한 말을 들었다. 같이 코딩하는 게 너무 좋아서 휴일에도 평일이 되기를 기다리셨다고. 이후 고맙고 배우는 것이 많다고 서로를 칭찬했는데 기분이 아주 좋았다. 오늘도 계속 주절주절 대화하며 사흘치 작업을 하루만에 끝냈다. 페어 코딩 짱.
선혁님은 나보다 7년 정도 더 나이 많은 시니어이신데 무척 겸손하고 팔로워십이 있으셔서 내가 어떤 선택을 해도 탄탄하게 뒤를 받쳐주심. 코드 디자인에 대해 가끔 태클 거실 때에는 이유가 충분해서 계속 신뢰가 쌓인다. 손발도 잘 맞고 성격도 잘 맞으니 작업 속도도 잘 나와서 스포츠카 타는 기분이다.
한편 요즘 두 번째로 많이 하는 이야기는 패턴에 대한 것들. "패턴 도입"이 아니다. "패턴을 걷어내는 작업"을 하는 대화라는 것이 중요. 레거시 프로젝트에 패턴 과잉이 보여서 패턴을 하나 하나 걷어내 "충분한" 정도로 리팩토링을 하고 있는데 이 과정에서 패턴 이름이라는 도구가 참 효율적이다.
한편 Java/Spring 하면서 가장 지겨운 건 컨트롤러-서비스-리포지토리를 맨날 만든다는 건데, 이건 본인이 만들고 있으면서 지겹다고 투덜대고 있는거라 누굴 욕할 수도 없는 일. 그래서 요즘은 코딩 짝과 함께 별로 새로울 것 없는 새로운 시도를 해보고 있다. 메소드를 딱 한 개만 갖는 서비스 클래스.
가령 게시판을 만든다고 하자. 1~2년차의 나는 BoardService
이런걸 만들고 이 녀석에 모든 메소드를 쑤셔넣고, 클래스가 600줄 넘어가도록 불안하게 방치하곤 했다. 그 외의 방법이 떠오르지 않았다. 5년차의 나는? 이걸 둘로 쪼개고 command, query로 나눴다. 반으로 나뉘었을 뿐 큰 차이는 없었다.
그 이후로도 크게 다르지 않았는데, 어느날 단일책임원칙은 좀 지키고 살아야 하지 않겠나 하는 생각이 들었다. 그래서 그냥 서비스 하나가 퍼블릭 메소드 하나만 서비스하도록 해봤더니 생각보다 괜찮았다. 테스트 클래스도 메소드 하나만 테스트하는 내용으로 채워지게 되어서 제법 읽기 좋았다.
그리고 서비스 이름에 모두 er
을 붙였다. 엘레강트 오브젝트 읽은 분들은 어 그러면 안 좋은데.. 라고 조언해주셨지만, 난 객체지향 별로 안 좋아하고, 내가 좋아했던 Go에서는 인터페이스 이름에 er
붙이는 게 당연했는데 뭔 상관인가 하고 걍 서비스 이름을 그렇게 지었다.
게시판 서비스 예제로 돌아가보자. 이렇게 하면 서비스가 촘촘하게 분리된다. BoardCreator
, CommentCreator
, CommentDeleter
, … 같은 녀석들이 서비스가 된다. 메소드가 하나이기 때문에 이 클래스들은 사실 메소드 하나를 제공하기 위한 껍데기일 뿐이다. 그리고 이름만 봐도 용도가 뻔하다.
클래스 하나가 30줄을 안 넘으니 파일 열어보면 오래 걸려도 5초 안에 뭐하는 파일인지 바로 파악이 된다. er
달린 녀석들끼리 이름으로 구분이 되니 읽는 사람의 마음속에서 er-layer 가 구분된다는 것도 특징. 테스트 코드도 심플해진다. 파일이 많아지는 건 단점일 수도 있는데, 난 신경 안 쓴다.
그리고 레거시에서 DTO 레이어마다 일일이 new
생성해서 들려보내는 걸 보는 것도 너무 짜증나는 일이라, 레이어별로 콘크리트 클래스를 받지 않고 전부 인터페이스로 받게 바꾸고 적당한 팩토리 하나 만들어서 new DTO를 볼 때마다 삭제해버렸다. 팩토리는 내부에 프라이빗 구현체 하나 갖고 있고
용도별로 호출할 수 있는 이름 적당한 메소드 여러개를 서비스하는 방식. 이렇게만 해도 파일을 많이 지울 수 있었기 때문에 er 클래스로 파일이 늘어나도 삭제한 게 많아서 거기서 거기인 느낌.
그래서 이번 프로젝트에서는 service
포스트픽스가 붙은 클래스가 1개도 없다. 이런 서비스 클래스 패키지 경로 전략도 철저하게 탐색 편의 위주로 고려했기 때문에 /생물/동물/포유류/강아지
이런 식의 개념적 계층화만 염두에 두고 만들어서 찾기도 쉽다. 이러면 접근권한 붙이기가 좀 짜증나는데
내가 자바에서 항상 필요하다고 생각하는 건 하위 경로에만 열려 있는 recursive private 인데, 사실 자바의 패키지 접근권한 개념은 내가 바람직하다고 생각하는 것과 개념이 달라서 이건 앞으로도 추가될 일이 없을 것 같다. 아무튼 그래서 클래스는 default 아니면 public으로만 쓴다.
한편으로는 퍼블릭이어도 큰 문제가 없는 구성이라 생각. 클래스 이름으로 용도를 광고하고 있는 메소드 딱 한 개만 지원하는데 퍼블릭이면 어떻단 말인가 하는 생각. 패키지 접근제한으로 멍청한 개발자를 방지하는 건 자바의 철학이지만, 나는 가독성이 개발자의 아이큐를 끌어올린다고 생각한다.
javadoc을 좋아하고 성실히 적으려는 이유도 같은 근거. 테스트 코드에서는 필요하다면 한글도 최대한 쓴다. 픽스쳐 이름도 한글로 지어버림. 알아보는 게 제일 중요하다. 계속 옆 동료에게 쉽게 읽히냐고 물어보고 잘 모르겠다고 하면 기각하고 다른 걸로. 코드 모양에 대한 내 고집은 덜 중요하다.
2021-10-17
얼마전 동료에게 이런 질문을 들었다. 책을 읽을 때 쉬운 부분도 있고 어려운 부분도 있어서 빠르게 읽어야 할 지 천천히 읽어야 할 지 모르겠는데 당신(나)은 어떻게 하고 있느냐는 것이었다. 그래서 나는 무조건 빨리 읽으려고 한다고 대답했다.
이유는 단순하다. 어떤 부분은 빨리 읽어도 이해가 될 것이다. 반면 어떤 부분은 천천히 읽어야만 이해가 될 것이다. 그렇다면 일단 빨리 읽다가, 이해가 안 되면 두 번 읽으면 된다. 그렇다면 빨리 읽어도 되는 부분은 계속 빨리 읽을 수 있고, 천천히 읽어야 하는 부분은 여러 차례 읽게 된다.
그런데 이거 말은 그럴싸하지만 누구나 하고 있는 거 아닌가. 책 한 권을 처음부터 끝까지 시작했을 때 결정한 속도로 읽어가는 사람도 있을까? 원체 빨리 읽는 사람이 '이번 책은 필요하다면 천천히 읽어야겠다'고 결심할 수는 있겠다.
한편, 정반대로 효율이 나쁜 독서를 일부러 선택하는 경우도 있다. 올해 초, 팀에서 어떤 기술에 대한 리서치가 필요해서 회사의 업무도서지원금으로 책을 구매하기로 했다. 그래서 나는 인터넷 서점에서 그 기술 이름으로 검색한 다음, 검색 결과로 나온 책을 몽땅 구매했다. 8권 정도였던 것 같다.
1권 살줄 알았지 다 살 줄은 몰랐다는 동료의 이야기를 듣긴 했는데, 결과적으로 괜찮은 방법이었다. 여러 책을 비교해서 정리하고 학습할 수 있었다. 각각의 책에는 각각의 관점이 있고, 나름의 맹점과 사각도 있다. 일을 잘 하기 위해서라면 어떤 경우에는 자원을 총동원해야 한다고 생각한다.
나는 이것이 조직의 연구개발비를 사용하는 바람직한 방법 중 하나라 생각한다. 책 8권 안 사고 1권만 사서 파고들었다면 7권 비용은 절약했겠지만.. 좋은 성과가 나왔을까? 목표달성의 이익을 생각한다면 책 7권 가격을 비싸다고 생각할 조직은 많지 않을 것이다. 심각하게 경직된 조직이 아니라면.
2021-10-19
내 관심 분야 중 하나는 초급 개발자 교육. 사내 교육을 통해 좋은 결과를 얻고 있고, 나도 노하우가 차곡차곡 쌓이는 중.
2021-10-20
내 개발실력을 생각하면 자괴감만 들게 되어 있다. 이건 너무나 당연한 것. 자신의 개발실력 떠올리며 자괴감 안 느끼는 사람은 극소수. 즉 생각해야 할 것은 내 개발실력이 아님. 생각해야 할 것은 해결해야 하는 문제. 문제의 해결책에 집중할 때 비로소 엉뚱한 우울감에 빠지지 않을 수 있었다.
모르는 게 너무 많기 때문에 하루종일은 물론이고 석달 열흘 자괴감에만 빠지는 경우도 흔하다. 모른다는 걸 인정하고 최대한 앞에 있는 문제를 해결하거나 공부를 하거나.. 그것 밖에 없는 것 같다.
2021-10-21
내려온 일정 겁나 타이트한 정도를 넘어서 2주 부족했는데, 야근 한 번도 안 하고 어떻게든 맞춰냈다. 기분 좋음. 남은 일정은 5일. 기능 구현 다 끝냈고 테스트 코드도 충분히 있다. 다행이다. 내일부터는 빠뜨린 거 없나 자체 QA 하고 테스트 코드 리팩토링하자.
일정을 이렇게 어떻게든 맞춰낸 건 짝 코딩과 테스트코드가 있어서 가능했던 것 같다. 최근 2달 내내 짝 코딩을 하며 깨달은 것도 좀 있고 나름의 흡족한 노하우도 얻었다. 짝 코딩을 하면 딴짓을 못하기 때문에 하루 8시간 중 7시간을 코딩과 업무 분석에 집중할 수 있었다. 내가 생각해도 놀랍다.
원격 재택근무를 하면 수시로 집중력을 잃는다. 괜히 안 읽던 책도 펼쳐보고, 책상 구석에 있는 비타민도 열어서 한 알 먹고, 휴대폰 보고.. 회사에서 일할 땐 좀 덜하긴 하지만 집중하고 있으면 슬랙 메시지 날아오고 다른팀 친한 동료가 찾아와서 말 걸고 해서 2시간 이상 집중하는 것도 꽤 어렵다.
다양한 해법이 있겠지만 마음 맞는 두사람이 두가지 일을 하는 것이 괜찮은 방법 같다. 핵심은 쉬지 않고 계속 말을 하는 것. 심지어 int i = 0
이런 걸 쓸 때에도 계속 말하는 것이 핵심이다. 그냥 코딩만 해서는 의도 전달 효율이 매우 낮다. 말하면서 타이핑해야 하고 설명하면서 코딩해야 한다.
짝에게 계속 생각을 노출해야 한다. 이게 안 되면 2분에 한번은 오해발생. 말을 안 하면 변수명도 아주 고심해야 하는데, "리스트의 길이를 잠시 변수 a에 넣을게요. 이름은 마음에 안 들지만 나중에 바꾸죠."라 하며 문제를 빨리 푼 다음에 테스트 코드까지 끝내놓으면 동료가 변수명 제안해 준다.
내가 특정 로직에 집중하느라 잠시 미뤄둔 서브 문제를 동료가 머릿속에서 풀어주는 것. 이거 잘 되면 신나고 쾌감까지 느껴진다. 반대 상황도 자주 나타나는데, 테스트 코드 작성하고 있을 때 동료가 스펙 헛점 발견해주면 나는 할일 목록 바로 업데이트하고, 그 사이에 동료는 새 시나리오 만들고..
책에서 읽은 짝 코딩하고는 꽤 다르다. 책에서 읽은 스타일의 짝 코딩은 네비게이터와 드라이버가 있어서 한 명은 말만 하고 한 명은 코딩만 하던데, 우리(선혁님과 나)는 코드위드미로 같이 계속 코딩을 한다. 말 겁나 많이 해서 오후 2시만 되어도 목이 쉰다는 게 단점.
보통 1시간 일하고 5~10분 쉬고를 반복하는데 가끔 엄청 피곤할 때에는 20분 정도 확 쉬기도 한다. 쉴 때는 눈 감고 누워 있기도. 그래도 회사에서 혼자 작업할 때보다 효율이 훨씬 좋다. 혼자서 머리 쥐어뜯을 때를 잘 생각해보면, 문제를 푸는 시간보다 부정적인 감정에 빠져있을 때가 많은데 감정적으로 완화가 되거나 시간이 생각보다 많이 흘러서 정신차리고 업무로 집중력이 돌아가는 게 보통이다. 하지만 마음 맞는 짝이랑 같이 작업한다면? 둘 중 하나가 땅 파고 들어가기 전에 다른 한 사람이 아이디어를 떠올리건 복붙을 하건 구글링을 하건 뭔가 가져온다. 어쨌든 문제로 돌아간다.
근데 이게 되려면 둘 다 양보할 줄 알아야 하고 배려하는 대화를 해야한다. 양보가 없으면 언젠간 틀어진다. 코드 모양이 마음에 안 들어도 과감히 포기하고 짝의 취향대로 간다고 생각해야 한다. 짝의 생각이 안 좋은 것 같아도 내 생각이 더 나쁠 수 있다고 하고 "그럼 그렇게 가죠 하하" 해야 한다.
어차피 코드 상의 문제는 며칠만 지나도 드러나는 경우가 많아서 안좋은 선택을 하면 금방 티난다. 그럴 땐 "제가 뭐랬어요"하면 안된다. 절대. 절대 안된다. "아 이거 아쉽지만 그때 우리가 얘기했던 두 번째 방법으로 해결해보면 어떨까요?"처럼 말하면서 서로 퉁 치고 후후 넘어갈 줄 알아야 한다.
어차피 실수는 누구나 하는 것이기 때문에 그래야 내가 실수를 했을 때에도 비슷한 반응이 오면서 부드럽게 해결하고 넘어가는 것. 코드 디자인은 며칠간 실패할 수 있어도, 짝과의 팀워크는 더 튼튼해져야 한다. 그래야 더 많은 문제를 더 빨리 풀 수 있다.
한 가지 아쉬운 점은 일정이 타이트하다보니 속도 위주로 작업을 했다는 것. 좀 더 흠 없고 튼튼하게 여기저기 보수하고 싶지만 처음엔 다들 불가능한 일정이라고 생각했으니 이 정도로도 만족. 그러면서 선혁님과의 팀워크가 아주 짧은 기간 동안 매우 튼튼해져서 그것도 만족.. 내가 복이 많은 것 같다.
2021-10-23
재택근무 장점 많지만 문제는 생산성과 고립감. 여러 사람과 어울려 토의하고 일주일에 한번씩 세미나하던 시절이 그리운 건 어쩔 수 없는듯.
2021-10-25
I.F.O 3way 176만9385점! 해냈다!
2021-10-25
국민학교 때 컴퓨터실에 이런 컴퓨터가 있었다. GW-BASIC이 되는 추억의 그린 모니터. 녹색과 검정색만 출력됐다. 컬러 모니터는 좀 더 나중의 이야기. 그래서 어렸을 적엔 녹색이 컴퓨터스러운 색이라 생각했었다. 매트릭스의 테마 컬러가 녹색인 것도 관계가 있겠지.
C 드라이브가 C 드라이브인 것도, 하드디스크가 신기술이었기 때문. 하드디스크가 없고 플로피디스크 드라이브가 1~2개 달린 컴퓨터가 기본이었다. (그보다 이전엔 카세트 테이프 같은 걸 재생해서 MSX 컴퓨터에 로딩을 시킴) 자연히 플로피디스크 드라이브= A 드라이브, B 드라이브로 상식이 되어버림.
하드디스크가 보급이 될 때에도 플로피디스크 드라이브가 2개 달린 컴퓨터에 세번째 드라이브를 추가하니 자연히 C 드라이브라고 다들 생각했다. 하드디스크가 생기니 운영체제 디스크를 따로 갖고다니지 않아도 됐고, 그래서 부팅이 끝나면 C:\>
프롬프트를 보게 됐다. 그 이전엔? A:\>
가 나왔음.
하드디스크가 없는 게 당연했던 무렵엔 A 드라이브에 MS-DOS 디스켓을 넣고 컴퓨터를 켜서 부팅을 시켰다. B 드라이브에 게임 디스켓을 넣고 b:
해서 b 드라이브로 간 다음 exe
, com
, bat
중 확장자를 가진 파일을 찾아 게임을 실행하곤 했다. 멀티 태스킹도 없어서 한번에 한 가지만 실행 가능했고.
90년대 초반의 국민학생들은 컴퓨터학원에도 많이 다니는 편이었는데, 컴퓨터학원에 가면 GW-BASIC을 배울 수 있었다. DOS나 HWP, 게임, v2, v3 백신 같은 프로그램을 서로 복사하는 일이 일상이어서 9살 10살도 다 format
을 할 줄 알았고 압축도 모두가 cmd 터미널에서 할 수 있었다.
그게 당연했던 게 당시에 컴퓨터를 할 줄 안다 = DOS를 쓸 줄 안다였고, gui는 없었다. 플로피디스크는 물리적으로 고장이 나기 쉬운 구조였기 때문에 그 어린애들도 노턴 디스크 닥터(NDD)로 썼고, 디스크 배드섹터가 어쩌고 저쩌고 그런 대화를 했다. PCTOOLS로 HEX값 편집하는 경우도 흔했다.
12살때 같이 컴퓨터 배우는 친구들 중에 16진수 FF가 255 라는 걸 모르는 애는 아무도 없었고, 암산으로 8진수 곱셈을 계산하는 애도 있었다. 지금 생각하면 넘나 대단하다.. 그런데 그렇다 해도 BASIC 프로그래밍을 정말 열심히하던 애들은 드물었다. 다들 남이 만든 게임에 초집중했다. 나도 그랬고.
그런데 그 때에는 640kb 메모리한계가 있어서 게임을 돌리기가 아주 어려웠다. config.sys
와 autoexec.bat
파일을 열심히 수정하며 시행착오를 거쳐야 돌아가곤 해서, 다들 himem.sys
나 emm386
같은 걸 설정하는 방법을 알고 있었다. 모른다 해도 친구들이랑 게임을 몇 번 주고받으면 알게 됐다.
친구들하고 모이면 서로 config.sys
나 autoexec.bat
파일 이야기를 하기도 하고 니 설정은 바보같으며 너도 멍청한 놈이라 하다가 내 설정 파일이 어떻다고? 하며 주먹다짐하는 애들도 있었다. 1994년이었나 1995년도 쯤이었던 것 같다. 윈도우 3.1 지나 95가 나왔지만 아무도 윈도우를 쓰지 않았다.
윈도우 3.1, 95는 사실 autoexec.bat
마지막에 win
이 있었기 때문에 DOS로 부팅이 완료될 때 실행되도록 되어 있는 응용 프로그램이었다. 근데 그 때에는 윈도우용 게임이 재밌는 게 별로 없었다. 좀 더 오래된 도스용 게임들이 재미있는 게 많았고, 친구들이 갖고 있는 것도 대부분 도스용이었다.
그래서 autoexec.bat
마지막의 win
을 지우고 그냥 도스 쓰다가, 어쩌다가 윈도우용 게임을 하게 되면 C:\>win
명령을 입력해 윈도우를 실행해 쓰곤 했다. 워크래프트2 까지였나? 윈도우 없이 도스만 썼던 게 그 쯤이었던 것 같다. 윈도우에서 실행하면 게임이 좀 이상하게 느껴졌다. 도스가 더 좋았다.
94~97년도(중학생때)에 안양1번가 대동서림에 자주 갔다. 대동서림 지하 절반에는 컴퓨터책만 있었는데 BASIC, C, C++, C# 책이 많았다. 로터스123이나 PC 일반에 대한 책도 많았다. MS-DOS 책을 사서 닳도록 읽은 기억이 난다. 고작 고거 하나 읽고 친구들 사이에서 컴도사 소리를 들었다.
그 때 구매한 책들 대부분은 지금까지 남아있지 않다. 부모님 집에 가면 아직도 MS-DOS 6.0은 있을듯. 하지만 아직까지 소중하게 곁에 두고 종종 살펴 읽는 책이 있다. 바로 중2 때 구매한 "배치와 매크로". 굉장한 책으로 기억한다. 무려 bat
파일로 프로그래밍하는 방법이 있었다. 너무 좋았다.
이 책의 1부는 도스의 메모리 관리에 대한 것이고 2부~6부는 도스에서의 셸 스크립트 프로그래밍을 다룬다. 640kb제한이 있던 시대에서 1부의 내용은 늘 필요했던 것이었기 때문에 굉장히 재미있어서 친구들하고도 같이 읽곤 했다. bat 프로그래밍도 C나 BASIC과는 다른 상쾌함이 있어 좋았다.
지금 생각해보면 내가 프로그래밍 언어 중 셸 스크립트를 가장 좋아하는 것도 어린 시절과 관련이 있지 않을까 싶다. 필요할 때 딱 한두줄만 코딩해서 그럭저럭 돌아가는 도구를 만들어 쓰고.. 나중에 또 읽으려고 디스켓에 옮겨서 보관하고..
하드디스크가 있었지만 언제든지 배드섹터가 발생할 수 있다고 생각했던 시절이었으므로, 하드디스크에 저장한 파일도 디스켓에 복사해서 보관하곤 했다. 그래서 나도 그렇고 친구들도 그렇고 다들 디스크 보관함을 집에 갖고 있었다. 5.25인치용은 대충 이렇게 생겼다.
휴대하고 다닐 때에는(그땐 인터넷 보급이..) 전자상가나 컴퓨터 가게에서 10개 들이 5.25인치 디스켓을 살 때의 포장 박스를 사용하곤 했다. 사이즈가 딱맞고 적당히 튼튼해서 디스켓을 갖고다닐때 쓰기 좋았다. 학교에서 가방 검사하면 한 반에서 열 몇장이 나오곤 했다. 선생님들이 많이 뺏어갔다.
2021-10-29
으 짝 코딩이 최고다. 우울감 다 사라지고, 작업도 잘 되어서 야근도 안 하고. 주말근무 해야 할 수도 있었던 상황인데 다 끝내고 퇴근한다. 으어.
같이 작업하다보면 내가 모르는 거 다 드러나게 되는데, 짝이 존구립님은 이런거는 다 아실 줄 알았는데 모르시는 거 보고 뭔가 자신감이 생기셨다고 한다. 하하… 아무튼 서로 모르는 거 많다는 게 오픈되니 모르는 게 나오면 그냥 어 모르겠는데요? 라고 마음 편하게 말하고 같이 열심히 생각한다.
'이거 남들 다 아는건데 나만 모르겠지'가 개발자 마음을 얼마나 좀먹는지. 이거 때문에 멘탈도 많이 망가지고 엉뚱한 공부에 빠져서 시간낭비하고. 건강하게 모르는 거 오픈할 동료가 있어 기쁘다.
최근에 업무 외의 일로 감정상의 스트레스을 많이 받았는데 일할 때마다 스트레스 날아가니 좋다. 나랑 일하는 게 좋아서 월요일이 기다려진다는 동료가 있는 것도 기쁘다. 저 저도 그래요! 라고 말할 수 있는 것도 즐겁다.
2021-10-30
생일이다. 나는 내가 오늘로 만 40이 되었는줄 알았는데 만나이 계산기로 계산해보니 만 39세가 된 거였어. 아직 삼십대다! 와~ 루이님이 다가오더니 여보 지금 만 39세 맞다고 말씀해주고 가심.
한편 오늘은 LiftIO 함수형 언어 컨퍼런스에도 참석했다.
2021-11-07
메타버스에 몇 가지 말을 얹어보자. 내가 경기도에 살고 있다고 하자. 경기도에 살고 있다는 것은 몇 가지 의미 레이어가 중첩되어 있다. 가장 바닥에는 물리 레이어가 있다. 그 위로는? 내가 21세기 경기도의 다양한 도구들의 사용방법을 알고 상호작용할 수 있다는 도구의 레이어가 있다.
즉 한국 현대 사회의 도시를 구성하는 다양한 도구들이 있다. 나는 교통수단(횡단보도, 신호등, 지하철역, 에스컬레이터, 주차장 등)을 식별할 수 있고, 사용할 수도 있다. 표지판의 글을 읽고 어딘가를 찾아갈수도 있고, 자동문이나 전기 콘센트라는 도구와도 내 목적에 따라 상호작용할 수 있다.
만약 꽤 떨어진 다른 공간으로 이동한다면 어떨까? 예를 들어 도쿄. 나는 일본어를 식별하지 못하므로 대단히 난감할 것이다. 다행히 프로토콜이 맞는 횡단보도나 에스컬레이터 등은 어찌어찌 사용할 수 있을 것이다. 그러나 관공서를 방문해 서류 제출하고 허가를 받는 등의 활동엔 문제가 생긴다.
즉 도쿄라는 도구의 집합을 사용하는 데에 능숙하지 못한 나는 대단한 불편함을 느낄 것이다. 편안하게 살아가려면 일본어도 배워야 할 거고 암묵적인 다양한 약속들과 그 나라에만 존재하는 사회적 도구들의 사용 방법도 익혀야 한다.
내가 살아가는 공간은 내가 능숙하게 사용하는 다양한 도구들의 연결망이다. 이 연결망에는 새로운 도구가 들어오기도 하고, 점차 쓰지 않게 되어 사라지는 도구도 있다. 이 수많은 도구들은 한번에 익숙해질 수 없으므로, 사람은 평생 살아가면서 다양한 도구의 사용법에 숙련되어간다.
가령 군대에서는 많은 물건들의 사용 방법이 자신이 원래 있었던 사회와 다르다. 어떤 것은 그대로인데 어떤 것은 새로 익혀야 하는 것이다. 그래서 누가 숟가락으로 병영 건물을 지었다고 농담을 하면 어떤 신병은 믿어버리기도 한다. 상점의 용도를 모르므로 총을 사오라는 말에 앗 어떡하지 한다.
많은 사람들이 생각하는 메타버스의 이상은 물리 레이어 위에(어떤 것도 물리 레이어 아래로 깔릴 수는 없다) 사회 레이어가 새치기해서 들어가는 것일 것이다. 그리고 그 사회 레이어는 도구들의 프록시(대리자)일 것이다. 이런 예의 가장 완성된 예제는 영화 매트릭스의 매트릭스 속 가상 사회이다.
매트릭스에서는 거의 모든 도구가 물리적 사회의 도구들과 같은 외양과 인터페이스를 갖는다. 매트릭스에서 망치를 본다면 그것은 망치이다. 자동차도 현실의 자동차와 똑같이 운전할 수 있고, 심지어 매트릭스 속 컴퓨터로 프로그래밍을 하는 것도 가능하다. 미스터 앤더슨의 직업은 프로그래머였다.
하지만 그것은 진짜 물리적 도구가 아니라 전자적 대리자에 불과하므로 매트릭스 속에서 깨달음을 얻은 자들은 "숟가락은 그곳에 없다" 같은 말을 한다. 그것은 숟가락이 아니라 매트릭스라는 도구의 연결망 내부에서 숟가락의 역할을 할 뿐이다. 그리고 사람은 그 대리자의 사용 방법을 알고 있다.
따라서 매트릭스 속은 90년대 사회인이 능숙하게 사용할 수 있는 도구의 연결망이다. 심지어 매트릭스 바깥에서 매트릭스로 돌아가고 싶어하는 사이퍼 같은 사람도 있었다. 매트릭스 속이 더 쾌적하고 덜 고생스럽기 때문이었다. 매트릭스 밖의 현실은 살아있지만 우리에겐 도구적으로 불편한 곳이다.
인간이 도구의 연결망 속에서 살아가기 때문에 이것이 실제인지 가짜인지는 별로 중요하게 생각하지 않는다는 말이다. 따라서 메타버스라는 이상은 목표로 삼을 수 있다. 하지만 현대인의 메타버스는 매트릭스와 같이는 되지 않을 것 같다. 매트릭스는 물리적 현실의 대리자로 기능했기 때문이다.
플랫폼으로서의 구글을 떠올려보자. 검색,지메일,캘린더,유튜브.. 다양한 도구가 있고, 스마트폰으로 상당수가 구글의 다양한 서비스를 연동해 사용하고 있다. 이들은 모두 자체의 도구 연결망을 갖고 있으며, 그 연결망들을 연결한 더 큰 규모의 연결망도 형성되어 있다. 구글 아이디만 있으면 된다.
나는 메타버스가 도구의 연결망에 매트릭스 판타지와 마케팅을 끼얹은 것이라 생각한다. 따라서 그 겉모습과 마케팅을 제거하고 도구의 연결망을 기준으로 보면 구글은 이미 상당한 수준을 이루었다고 생각한다. (카카오와 토스 같은 회사들도 어느 정도 달성했다고 본다.)
MMORPG를 하면서 불편했던 경험들을 떠올려보자. 상점은 상점의 역할에 충실하지만, 그 이상의 역할은 하지 못한다. 주인공 캐릭터는 걸어다니지만, 게임의 경계인 투명한 장벽은 넘어가지 못한다. 전설의 명검으로 몹은 잡아도 요리는 할 수 없으며 마법을 응용하는 데에도 제한이 있다.
현실의 도구연결망은 물리 레이어에 있어서 물리/화학적 단위의 상호작용이 가능하다. 그러나 비디오게임은 그 정도까지 구현하기 몹시 어려우며 사실 그렇게까지 만들지 않아도 된다. 게임은 재미가 있으면 되는 것이고, 플레이어들과 개발자들에게 심리적/물질적 보상이 돌아가는 것을 목표로 한다.
나는 앞에서말한 구글이나 카카오나 토스 같은 서비스들이 점점 늘어나면서 이것들이 서로 또 연결되고 그런 과정에서 현실 위에 덧씌워진 도구들의 연결망을 만들고 있다고 생각한다. 그리고 현실과 가상공간의 경계는 지금도 사람들이 충분히 넘나들고 있고, 영역도 점점 더 넓어지고 있다고 본다.
그래서 메타버스를 만들겠다고 단언하는 건 내게는 꽤나 복잡하게 들린다. 마치 좀 색다른 MMORPG를 만들겠다고 하는 선언처럼 들리는 것이다. 매트릭스를 능가하는 메타버스라면 인간이 팔다리라는 구속도 벗어나 활동할 수 있어야 할 것이다. 그렇다면 뇌도 그에 따라 구조가 바뀌겠지.
팔이 다섯개인 가상공간에서 평생 살아본다면 사고방식도 좀 달라지지 않을까? 뇌 API가 규명되어 전후좌우 360도를 동시에 볼 수 있는 시야를 뇌에 그대로 전송해주는 가상공간은? 물리 세계를 모방한 사이버스페이스는 메타버스라기보다는 걍 새로운 MMORPG일 것일 것 같다.
그런 스타일의 메타버스는 지금도 만들 수 있다. 전국민이 와우나 리니지 계정을 만들고 로그인할 수 있게 정부가 게임회사와 계약을 한다. 모든 관공서와 모든 부서에 수시로 로그인한 계정을 하나 두고, 게임 속에서 HWP 파일을 주고 받을 수 있게 하면 된다. 그렇다면 메타버스 정부는 완성된다.
NC소프트에 정부가 돈을 주고 서울,대전,대구,부산.. 등을 게임 속에 만들고 이동에 장애가 없도록 포탈이나 이동 스크롤 같은 걸 무제한으로 주고 그러면 끝나는 일이다. 회사 이름 안 바꿔도 되고 어려운 기술도 필요가 없다. 돈만 있고 사회적 합의만 있으면 지금도 가능한 것.
메타버스 안에서 크리에이터가 뭘 만들어 팔고 수익을 내고.. 이미 유튜브가 하고 있는 일이 아닌가? 평범한 MMORPG에서도 그에 맞는 새로운 기능을 기획해 추가하면 그럭저럭 할 수 있는 일이 아닌가?
2021-11-08
친절하고 상냥한 분들 너무 소중하다. 나도 친절하고 상냥한 사람이고 싶다.
2021-11-10
인중 위에 여드름이 생겨서 한동안 김흥국같은 콧수염을 길러야 한다.
2021-11-11
왜 요즘 일이 엄청 잘되는 걸까. 업무 속도, 문서 퀄리티, 일의 재미까지 모두 x4 상태. 내년에 해야 할 팀 업무들에 대한 아키텍처 문서도 촥촥 써내고 시스템 개선방안 문서도 신기하게 계속 줄줄 나온다. IQ가 +40은 된 기분. 신기하다. 기묘한 건 오늘이 퇴사 D-12일이라는 것.
참 감사하고 좋은 경험을 많이 한 회사라는 것을 깨닫는다. 이 회사에 오지 않았다면 오늘의 나는 없었겠지. 내가 제안해 만든 게 참 많았다. 프로세스도 있었고, 서비스도 있었고, 문화도 있었고. 기타등등 이것저것. 새 회사가 기대되기도 하지만 이 회사는 앞으로도 오랫동안 기억에 남을 것 같다.
내가 제안해 만든 게 참 많았다고 썼지만 쓰고 나서 후회했다! 사실 다같이 했다. 즐겁고 행복했다. 하하 이런 말은 퇴사일에 적어야겠지만 지난 한 주 내내 찾아와 아쉬워하고 격려해주는 여러 동료들을 보고 감정이 솟아올라 찔끔 눈물이 나기도 했다.
2021-11-14
최근 2년간 지속적으로 꾸준히 머릿속에서 지울 수 없었던 생각은 코딩 자체는 별로 안 중요하다는 것. 특히 언어는 거의 안 중요하다는 생각. 그러나 세상은 코딩 교육과 부트캠프가 흥하고 있다.
js, java, php 뭘 쓰건 상관없다고 생각한다. 어차피 다 AWS 인스턴스에서 블랙박스로 여겨지며 돌아가게 될 거고 API 약속만 잘 해두면 된다. 그래서 언어는 별로 안 중요하고, 유지보수가 가능한 사람을 잘 갈아끼울수 있는지가 중요하다. 그러다보니 사람 구하기 쉬운 언어 위주로 시스템을 구축..
아주 어려운 도메인을 해결하기 위해 뭉친 회사라면 이야기가 다를 수 있다. 하지만 여전히 아주 많은 곳에서 아주 단순하고 반복적인 코딩 작업을 아주 빨리 해내는 것만을 요구하고 있다.
누구도 풀지 못한 문제를 풀기 위한 코드를 작성하라고 독려하는 회사는 드물다. 보통 그런 문제는 CEO, CTO, 투자자들이 먼저 발견하고 의식을 갖게 되는 경우가 많은 것 같다. 이미 CEO, CTO, 투자자가 논리적으로 문제를 해결해 둔 상태에서 개발자들에게는 상세 구현만 맡기는 경우도 많다.
물론 이런 범주 바깥의 뛰어난 기술 회사들도 많다. 그러나 이 타래에서는 이 범주 안쪽의 회사들만 놓고 생각해 보자.
나는 함수형이냐 객체지향이냐도 별로 안 중요하다고 생각한다. 패러다임에 따라 몇 가지 문제가 해결되긴 하는데 이 패러다임 쓰고 있으면 저 패러다임이 아쉽고, 저 패러다임 쓰고 있으면 이 패러다임이 그립고 그렇다. 생각보다 많은 것이 감정과 얽혀 있다.
스트롭스트룹은 "세상엔 언어가 두 가지 있는데, 아무도 안 쓰는 언어랑 모든 사람이 욕하며 쓰는 언어가 있다" 라고 말했다. 난 이 말이 C++의 복잡도에 대한 변명이라 생각하지 않는다. 일과 관련된 많은 사람들의 복잡한 감정을 대변해 준다고 생각한다.
많은 전통적 회사들은 아주 까다로운 면접을 했다. 그러한 면접은 보통 업무상의 스트레스를 잘 견디는지 테스트하기 위한 것이라는 변명이 따라붙곤 했다. 그런데 가만히 생각해보면 면접에서는 업무를 하지 않는다. 그 변명의 본질은 면접관이 주는 스트레스를 잘 견디는지에 대한 테스트이다.
(면접의 통과라는) 목적을 위해 감정상의 스트레스를 잘 숨기고, 위장할 수 있는지를 본 것이다. 그런 사람들이 일을 잘 할거라는 환상이 팽배했던 시대이기도 했다. 실제로도 일을 잘 했을 것이다. 감정이 문제 해결에 부정적인 영향을 주는 사람들을 막는 데에는 도움이 되었을 테니까.
하지만 이제는 포트폴리오의 시대가 되었다. 특히 개발자들은 이직을 자주 하는데, 법적으로는 정규직이지만 2~3년마다 이직을 하고 있으므로 법적으로만 정규직이고 정신적으로는 프리랜서의 삶을 사는 것이라고 생각한다.
이직을 하면 그만이므로 감정의 손상을 참아가며 30~40년을 한 회사에 근속해야 할 이유가 없는 것이다. 게다가 이직을 하면 연봉도 오른다. 따라서 똑똑한 회사일수록 우리 회사에 오면 행복하게 일할 수 있을거라고 말하며, 실제로 행복한 기분이 들게 해주려 많은 노력을 한다. 이것도 감정 문제.
하지만 여기에서 착각에 빠지면 곤란하다. 몇 십 년 전의 양계장에서 닭들에게 음악을 틀어주는 곳이 있었다면 이유는 닭을 사랑해서가 아니었을 것. 좋은 계란의 생산과 향상된 품질의 닭고기를 위해 음악을 틀었을 것이다.
감정을 고려하는 것이 인간을 조종하는 방법이라는 말이다. 어떤 사람들은 갬성 마케팅하면서 감정의 영향력을 축소해 보곤 하는데, 기업이 연봉만으로 사람을 조종하는 게 아니라 감정까지 잘 이해해 들고 흔들면 나와 같은 평범한 직장인은 아마 벗어나기 무척 힘들 것이다.
기계는 논리적으로 움직이지만 기계를 움직이는 사람은 감정으로 움직인다는 것. 이성만으로 움직이던 사람도 삶의 어떤 순간엔 분명 감정을 통해 결정을 바꾸는 일도 일어난다. 그래서 일류대학을 중퇴하기도 하고, 결혼식장을 탈출하기도 하고, 업계 최고 회사를 때려치고 스타트업을 하기도 한다.
드라마 빌리온스에는 퍼포먼스 코치라는 직업이 나온다. 직원들의 감정 조절을 도와줘서 업무 퍼포먼스를 부스트하는 엄청난 일이었다. 드라마 바깥에도 이런 사람이 있다면 효율이 중요한 회사는 반드시 채용해야 할 것 같다. 왜냐하면 나도 마음맞는 분과 짝 코딩을 하면서 부스트를 느껴봤기 때문.
요즘 언어가 중요하다는 생각이 안 드는 여러 이유 중의 하나이다. 동료와 감정이 잘 맞고, 회사가 내 감정을 상하게 하지 않으며 오히려 부스트한다면 언어는 아무거나 상관없다. API 약속만 잘 지키면 끝나는 일이다. 감정이 손상되지 않고 부스트된다면 일에 대한 집중력이 대폭 향상된다.
게다가 내가 회사에 중요한 결정을 내리고 있다고 생각하게 만드는(실제로 그렇지 않더라도) 회사라면 정말 많은 좋은 직원들을 모을 수 있게 될 것 같다. 대부분의 사람들은 자신이 맞추고 있는 직소 퍼즐을 중간에 때려치고 싶어하지 않는다.
감정 문제를 면접관이 이해하지 못하면 인재를 놓치기도 한다. 어떤 질문은 면접자의 능력 검증보다 면접관 자신의 기분을 좋게 하려고 던져지기도 하는데, 한두개는 괜찮아도 그 이상 이어지면 대부분은 면접이 끝난 이후 감정이 나쁘면 처우가 어지간히 좋지 않은 이상 그 회사를 선택하지 않는다.
현재 회사의 면접에 들어갈 때마다 가장 신경썼던 것 중의 하나이기도 하다. 기술 질문도 준비하면서 어떻게 해야 내가 면접관으로서 면접자들의 감정을 상하지 않게 신사적으로 할 수 있을까 하는 고민들.
그래서 면접 전후에 인사를 하는 것부터 연습을 많이 했다. 어떻게 해야 정중하게 인사할 수 있을까. 어떻게 해야 사려깊게 질문할 수 있을까. 인사는 누구나 하는 것이지만 그래서 더 어려운 일이었고, 처음에 어떤 인사를 하는지에 따라서도 분위기가 달라진다는 것도 알게 됐다.
그러다 얻은 노하우 중의 하나가 특히 기술 질문을 할 때 질문을 하는 이유를 말하는 것. 나는 이걸 "깜빡이"질문이라 표현하곤 했는데 분위기가 많이 부드러워지고 쓸데없는 기술 지식 질문으로 삼천포 빠지는 것을 많이 방지할 수 있었다.
예를 들어 스프링의 빈스코프를 물어본다고 하자. 이때 그냥 "빈 스코프 뭐뭐 있는지 말해보세요"라고 하는 게 아니라 "저희 회사는 신규 프로젝트에 주로 스프링을 선택해 사용합니다. 그래서 이제부터는 스프링에 대해 질문드리려 해요."라고 깜빡이를 켜서 짧게나마 마음의 준비를 하게 해준다.
이렇게 하면 질문에 이유가 있어야 하므로 돌발 질문을 막을 수 있고, 실제 업무와 관련이 있게끔 질문이 응집된다. 더 성의있는 면접이 되어 면접자를 함부로 대하지도 않게 된다. 물론 이유를 설명하는 것도 노하우가 있어서 많은 연습이 필요하다.
그리고 면접 전 면접관이 모두모여 1시간씩 이력서를 보며 질문을 준비했다. 질문을 그냥 준비한 게 아니라 각자의 질문 담당 영역 배정도 하고 어떤 답변을 할 경우에 대한 추가 질문들도 준비하는 나날이었다. 준비한 시간이 아깝다고 생각하지 않았다. 다음엔 더 잘 할 수 있겠지 하며.
그러다 최근 우리 팀에 입사하신 분이 품위있고 좋은 면접으로 기억한다고 하셔서 기뻤다. 나는 곧 퇴사하지만… 그래도 회사에 괜찮은 것 하나는 남겼구나 싶어서 뿌듯하다.
2021-11-19
책을 읽다가 만난 문장. "사람은 재미있다고 생각하면 뭐든지 잘하게 되어 있다"
실제로 잘 하게 되는지는 잘 모르겠다. 세상엔 재미있어도 달성하기 진짜 어려운 것도 있으니까. 그래도 재미있다고 생각하는 것을 하게 된다면 그것을 하는 도중에는 다른 것을 잊고 몰두할 수 있는 것 같다.
요즘은 몰두가 아주아주 중요하다는 생각을 한다. 삶은 유한하다. 일이건 공부이건 취미이건 몰두할 수 있다면 시간의 흐름을 잊을 수 있겠지.
어떤 사람은 책이 있어야 몰두가 가능할 거고, 어떤 사람은 축구공이 있어야 몰두가 쉬울 거고. 그렇다면 명상 숙련도가 높아 명상만으로 몰두할 수 있는 사람은 정말 몰두의 효율이 좋을 것 같다. 책도 공도 컴퓨터도 필요 없으니.
2021-11-21
[[/java/feel-of-java]]{1997년 글 하나 번역했다.} 하하 나는 왜 옛날 글들이 좋을까.
2021-11-25
마켓컬리 마지막 출근일.
퇴사 많이 했는데 이번 퇴사는 특별했다. 많은 분들이 찾아와 아쉬워하시고 같이일할 때 좋았다고 하셔서 감정대폭발. 눈물펑펑. 다들 고맙다고 해주셨지만 나는 내가 받은 것이 더 많다는 걸 알고 있다. 사랑하는 우리들의 회사 마켓컬리 화이팅! 이젠 다른 회사로 가서 또 또 신나게 일해야지.
2021-11-27
나는 IntelliJ IDEA를 "인텔리제이 이데아"라고 읽는데, 이걸 "인텔리제이 아이디어"라고 읽는 사람을 보고 '앗..' 하는 느낌을 받은 적이 있다. 이걸 이야기했더니 서양철학 전공해서 그런가보다 하는 말을 듣기도. 생각해보니 맞다. 저걸 보면서 플라톤만 생각했지 아이디어라고 생각해본 적이 없어.
2021-11-29
삼성역 인근에서 윤형주님(@voiceman99)을 만나 티타임을 가졌다. 1995년 이전에 TCP/IP 스택 직접 구현한 엄청난 이야기도 듣고 따뜻한 조언과 격려도 해주셔서 행복한 시간이었다. 너무 좋은 분을 만나서 아직까지 기분이 좋다.
2021-12-02
최선혁님과 함께 인프런을 서비스하는 인프랩에 방문했다. 오래간만에 이동욱님을 만나 점심을 함께 먹고 차를 마시며 서로의 커리어에 대해 오래 이야기를 할 수 있었다. 인프랩 사무실에서는 인프랩 직원분들을 대상으로 "스타트업에서 개발자가 회사와 함께 성장하는 방법"이라는 주제로 강연을 했다. Q&A 시간에는 선혁님도 함께 참여하셔서 무척 보람차고 즐거운 시간을 보낼 수 있었다.
2021-12-03
경험이 참 중요하다는 생각이 요즘 많이 든다. 새로운 경험을 얻는 방향으로 자꾸 움직여야지.
많은 사람들이 시간만큼 소중한 것이 없다고 한다. 삶이 유한하고, 사람은 언젠가는 세상을 떠나기 때문. 삶을 좋은 경험들로 가득 채우고 싶다. 아름다운 경험들로 가득 채우고 싶다. 특히 겁쟁이로 살지 않고 용감하게 많은 문제를 직면하며 당당하게 살고 싶다.
2021-12-09
언젠가부터 오 우리 회사 꽤 괜찮네… 하는 시기마다 퇴사를 하고 있는데, 어떤 결과가 나오건 간에 마음가짐에 꽤 영향을 준다. 성향은 전혀 도전적이 아닌데 이력을 보면 계속 도전적인 선택을 해오고 있음. 내가 봐도 신기하네.
2021-12-10
오늘 점심에 먹은 부대찌개가 참 맛있어서 계속 생각이 나네.
그래도 오늘 점심은 밥 1/4 공기 먹고 라면도 최소한으로 먹었다. 제일 먼저 채소만 우걱우걱 계속 먹은 것도 스스로에게 칭찬을. 이렇게 먹으니 속이 망하지도 않고 좋다.
한동안 속이 안 좋아서(위염) 고생이 심했다. 처음엔 계속 적게 먹다보면 낫겠지 => 나으면 다시 맛있는거 많이 먹어야지 반복이었지만 요즘은 생각이 바뀜. 그냥 먹는 양 줄이고 짠거 매운거 최소한으로 먹고 살아야겠다로 결론.. 흑흑
10년 전에 처음 가슴 통증 느꼈을 땐 아닛 가슴이 아프다니 설마 심장에 문제가?? 같은 생각을 했다. 의료지식이 부족해서 막연히 심장 생각을 한 것. 그러나 의원에서는 심장엔 다 문제가 없다고 했고, 나는 아니 그렇다면 이 칼로 후비는 것 같은 아픔은 뭘까로 2년이나 고민을 했다.
나중에 알고보니 그게 위염과 식도 역류증이었다… 위산이 역류해서 식도 끝이 위산에 손상되는데 그 통증이 바로 내 가슴통증의 원인이었던 것이다. 그땐 뭘 먹건 많이 먹어서 항상 과식을 했고, 민감한 성격상 스트레스를 잘 받아서 첫 건강검진에서 만성위염이라는 이야기를 들었다.
그래서 좀 조심하면 괜찮겠지 하고 몇 년을 살았고 한동안 괜찮아서 또 방심하고 살았는데 요즘에 와서는 정말 쪼끔 먹지 않으면 속이 몹시 좋지 않아서 큰 위기감을 느낌.
아무튼 대단히 적게 먹으려 노력한다. 어제 점심의 경우 전날 배달시키고 남은 [치킨 한 조각, 연근반찬, 밥 1/3공기] 로 식사를 해결. 좀 허전하긴 했지만 먹고 좀 지나고 나니 나름 괜찮았다. 속이 불편하지 않은 것이 가장 좋은. 예전엔 배부르지 않으면 싫었는데 이제는 그런 생각이 안든다.
요약하자면 음식 욕심내지말고 살아야지 라는 결론.
2021-12-19
스파이더맨: 노 웨이 홈을 봤다.
2021-12-21
클래스101에서 라이브 발표를 했다. 큰 실수 없이 끝내서 다행이라 생각한다.
기념으로 링크와 스크린샷을 기록해 두자.
[라이브] 성장에 한계를 느끼는 순간, 스스로 돌파구를 찾는 개발자가 되려면 by 이종립
2021-12-22
문득 perl5 깃헙 리포지토리로 들어갔다가 75000 커밋이 된 것을 보았다. 어제도 커밋이 올라왔었구나.
2021-12-26
시간은 유한하므로 관심사가 너무 많으면 모든 것이 그냥 가루로 남는 것 같다. 관심사를 더더더 줄이고 중요한 것에, 내가 원하는 것에 집중하며 살고 싶다.
2021-12-27
오늘 공부한 것. http://PersistentVector.java 의 흥미로운 구조.
Java ArrayList와 상당히 달라서 들여다보는데 아주 재밌었다. 자바의 어레이리스트는 쉽게 말하자면 다이나믹 어레이를 구현한 것. 배열은 물리적인 이유로 사이즈 변경이 곤란하니 더 큰 배열을 만들고 새 배열로 이사가는 알고리즘이 어레이리스트의 핵심.
자바 어레이리스트는 이 과정에서 그로우 팩터로 1.5
를 쓴다. 배열이 꽉 차면 1.5배 사이즈의 배열을 만들고 배열을 복사해 쓰는 것. 자바 컬렉션 프레임웤의 대표적인 클래스이기도 하고, 이런저런 장점들이 있어서 많이들 사용한다.
한편 클로저의 PersistentVector
는 32
사이즈를 가진 배열의 배열 구조를 갖는다. tail
에 32
사이즈 배열을 달고 있다가 tail
이 가득 차고 새 아이템이 추가되면 tail
의 배열을 root
로 옮기는 식. 예를 들어 아이템이 70
개라면 root.array[0]
에 첫 32
개가 있고 root.array[1]
에 64
번까지 있고,
나머지 70
번까지는 tail
에 들어가는 식. 이렇게 하면 리스트 사이즈가 증가해도 배열전체를 복사하지 않아도 된다. 게다가 이건 불변성을 보장하도록 만들어져서 서브리스트를 만들어도 노드를 재활용할 수 있다는 특징이 있음. 불변성이 이런 면에서 짭짤한 장점이 있구나 싶어서 즐거웠다.
클로저의 즐거운 면 하나는 언어 구현이 자바로 되어 있어서 구현을 이해하기 용이하다는 것. clojure/clojure를 로컬에 하나 클론해뒀더니 세상 편하다. 구조 잘 모르겠으면 테스트코드 대충 짜서 디버거 돌리면 대강이라도 금방 이해가 된다.
2021-12-28
입사하고 2주 지나고 보니 회사가 투자를 받았네.. 좋은 시기에 입사한 모양이다. 열심히 다녀보자.
SK스퀘어, 농업 혁신기업 ‘그린랩스’에 350억원 투자
2021-12-30
수족냉증이 있지만 키보드 때문에 장갑도 못 쓰고 고민이 많았는데 어쩌다 떠올린 손가락 장갑이 생각보다 효과가 매우 좋았다.
한 켤레 사서 며칠 쓰다가 세탁이나 마모 등 고려해서 한꺼번에 사기로 결정. 2만 2천 700원에 30켤레를 한꺼번에 팔길래 한번에 다 샀음. 아아주 마음에 든다.
2021-12-31
중쇄를 찍자 드라마 1화 보고 감동받아서 밥먹다가 울 뻔 했다.