다른 글 보기

2026 W4 회고

2026 W4 라고 함은 2026.01.19. 월요일부터 2026.01.25. 일요일까지를 의미합니다.

원래는 2026 W3 의 회고를 했어야 하지만 이미 시간이 많이 지난 관계로 여기서 함께 이야기하는 것으로 갈음하려고 합니다.

또한 2025년 회고는 2번 퇴고한 초벌이 있지만 여전히 할 말이 많고 다소 어두운 이야기도 있으므로 그 초벌 대신 이 회고로 하여금 갈음하려고 합니다.

때문에 이 글은 아래와 같은 목차로 구성될 것이며, 오전 11시 20분 정도까지 1시간 정도를 할애하여 쓰기로 마음 먹었습니다.

2025년 요약

2024년 말을 기점으로 퇴사한 이후 1년을 쉬었습니다. 아예 구직활동을 하지 않았던 것은 아니고 6, 7월 즈음에 한 번 시도 했었고 이후로는 쉬었습니다.

원래 작성했던 초벌에서는 생각들을 줄줄이 늘어놨는데 간단히 현상만 말하면 정신적으로나 신체적으로나 많이 건강해졌다고 느낍니다. 체중 같은 수치도 많이 줄어들었고 정확히 측정할 수는 없지만 불안도도 많이 낮아졌습니다. 특별히 처방을 받지는 않았고 정말 잠만 많이 자고 밖에 나가 걸을려고 노력하고 그랬습니다.

신체적으로 건강해진 것은 작년 중순 즈음 부터 그랬지만 여전히 기력이 없었습니다. 나중에 12월이 되어서야 알게 된 것이지만 “기력이 없다” 보다는 무력감과 죄책감이 강하게 있었다고 느낍니다. 다른 사람에 말 못 할 이야기였다고 생각하며 살다가 11월 12월 즈음 되서 몇몇 사람에게 어쩌다 말을 해보다 보니 마음이 굉장히 편해지는 것을 보고 알게 되었습니다. 그래서 12월 즈음 이후로는 굉장히 기운이 넘쳐 지금까지도 의미있는 하루들을 보내고 있습니다.

아래는 초벌에서 적었던 좋았던 일들입니다.

그저 쉬기만 하였기 때문에 성과랄 것은 없는 1년이었지만 비교적 매우 건강해졌고, 2024년까지만 해도 미래가 암울하게 느껴졌던 반면 지금은 그렇지는 않습니다. 때문에 계엄이나 기타 여러 혼란스러운 정세들이 있었음에도 퇴사를 후회하지는 않습니다.

그저 기나긴 우울을 마무리 지을 수 있다는 것이 너무나 기뻤습니다.

2026 W4 까지 이야기

작년 11월, 12월부터 알게 모르게 남아 있던 죄책감을 내려놓은 뒤 전보다 많은 것을 하며 지냈습니다.

최적화 연습

우선 그 중 하나는 모 회사의 지원 공고에 성능 측정 기반 성능 최적화 경험 유무가 자격요건으로 있어 이를 위해 RustPython과 bencodex-rs의 성능을 개선하는 작업을 했습니다.

프로파일러를 활용해서 최적화를 해본 경험이 전혀 없는 것은 아니나 퇴사한지 1년이나 된 시점에서 잘 기억이 나지 않기 때문에 해보기로 하였습니다.

https://github.com/RustPython/RustPython/pull/6704 에서는 RustPython의 json.loads 성능을 개선했습니다. pip install 의 성능을 개선하려고 시도하던 중 json.loads가 꽤나 느리다는 것을 알게 되어 이 부분에 집중했습니다.

RustPython에서는 --features=flame-it 피쳐를 활성화 시키면 speedscope 포맷으로 결과를 제공해주고, speedscope 웹 앱을 통해 확인할 수 있습니다. 다만 잘 보이지 않아 trace 구간을 더 세세하게 나누었고 그러다 보니 눈에 띄게 큰 trace 구간이 있는 것을 확인할 수 있었습니다. 그리고 해당 구간이 느렸던 이유는 Rust Chars iterator를 사용하고 있었기 때문입니다. 말 그대로 iterator 이기 때문에 특정 시점으로 넘어가기 위해 O(n)의 연산을 계속 수행하고 있었습니다.

이는 명백히 느릴 수 밖에 없었습니다. 때문에 유니코드를 고려한 인덱스인 char_idx와 보통 바이트 배열에서 사용될 수 있는 인덱스 byte_idx를 같이 트래킹하여 byte_idx를 파싱할 때 사용하고 char_idx는 에러를 내보낼 때 사용하도록 하였습니다.

다른 최적화들도 있지만 위 사항에 비하면 정말 미미했습니다. 여기서 배운 점은 성능 측정을 하여 가장 오래걸리는 구간을 특정하여 그것을 수정하는 것이 가장 중요하다는 점이었습니다. 결과적으로 16배 빨라지게 되었습니다.

이어 bencodex-rs의 성능을 측정하고 개선해보기로 했습니다. 업무에 사용할 때도 불편함을 느끼지는 못했고 최근에는 사용할 일도 없지만 이것저것 적용해보고 있는 토이 프로젝트입니다.

이 과정에서는 Ubuntu VM을 띄워서 perf 나 valgrind, cargo-flamegraph 같은 도구를 사용해봤습니다. macOS에서는 perf가 없기도 할 뿐더러 cargo-flamegraph를 사용하려면 sudo 권한을 요청하였기 때문에 겸사 별도 환경에서 실행했습니다.

https://github.com/moreal/bencodex-rs/pull/34 벤치마크를 측정하고 하는 과정은 이 PR에 설명으로 기록했습니다.

RustPython의 사례에서는 이미 파일 사이즈가 좀 있기도 했고 RustPython에서 정의한 트레이스만 결과에 나와 보기 크게 불편하지 않았지만, bencodex-rs의 경우 다른 요소들도 많이 끼어 들어 보기 어려웠습니다. 우선 파일 사이즈를 크게 키워서 다른 로직들 말고 실제 처리(encode/decode)와 관련된 구간들이 차지하는 공간을 많아지게 만들었습니다. 그래도 실행 결과가 아무래도 들쑥날쑥하다보니 시뮬레이션 방식으로 동작하는 valgrind로 실행해서 각 함수별 소요 시간으로 정렬하여 하나하나 최적화했습니다.

hex의 느린 부분은 faster-hex crate를 활용해서 SIMD로 처리하게 하였고 BigInt를 문자열로 변환하는 것이 느린 경우는 i64 보다 작은 경우 itoa crate를 활용하게끔 fast-path 분기를 만들었습니다. 그 결과로 1.83배 빨라지게 되었습니다.

다만 faster-hex에서 어셈블리를 직접 작성해서 사용하는 구간이 있는데 이 때문에 현재 miri 인터프리팅이 실패하고 있습니다.

오픈소스 기여

기타 오픈소스 기여도 하였습니다.

Hackers' Pub 쪽에 기여하는 과정에서 Deno upstream에 패치도 하고, SolidJS SSR이 어떻게 돌아가는지 공부도 해봤습니다. 해결은 결국 간단하게 하기는 했지만요.

홍민희 님이 hongdown 라는 마크다운 포매터를 만드셔서 버그를 수정하는 PR도 2개 올렸습니다. 지금 이 글도 Zed 에디터에 hongdown을 포매터로 써서 글을 쓰고 있는데 굉장히 편합니다. vscode 확장 PR도 draft로 열었지만 마무리 짓지 못 했습니다.

그리고 Vertana 라는 번역 라이브러리도 만드셔서 properNoun 같이 고유 명사를 기술할 수 있는 헬퍼 함수를 추가했습니다.

RustPython에 위 성능 개선을 시작으로 PR을 여럿 올렸습니다. 그 내용들은 stdlib 업데이트, 그리고 그 과정에서 나오는 CPython 호환성 패치, 그리고 새롭게 추가된 update_lib 라는 stdlib 업데이트 용 툴체인 개선, upgrade-pylib Claude Code 커맨드 개선입니다.

그리고 ap-thread-reader 라는 ActivityPub Note들을 한 페이지에서 보는 간단한 프로젝트를 만들었습니다. Fedify를 object lookup할 때 활용했습니다.

2026 W4 좋았던 점

손 가는대로 버그 찾는대로 오픈소스 기여도 하고, 디자인 개선도 하고 그렇게 시간을 보냈습니다.

아직 해봐야할 것들이 많지만 프로파일링을 해서 최적화를 하는 경험을 해보아서 좋았습니다.

작업하면서 “재현 가능한 커밋” 라는 글을 적어보기도 하였습니다.

2026 W4 아쉬운 점

즉흥적으로 이것저것 개발해서 좋기는 하였지만 이런 기간을 거치며 느끼는 점은 코딩 에이전트가 코드를 아무리 많이 생산해도 결국 제 주의력에는 한계가 있다는 점입니다.

일을 할 때나 오픈소스를 할 때나 결국 스스로 잘 검토하여 메인테이너 분들에게 “이거 동작하고 옳은 변경입니다”를 이야기해야 하는데 문제점과 나이브한 로직만 코딩 에이전트에게 얼추 넘기고 나온 결과를 대뜸 리뷰해달라고 할 수 없다는 점입니다.

결국 해당 작업을 하는데 필요한 관련 지식이 꼭 필요합니다. hongdown 에 올린 draft PR을 생각해보면 Claude Code가 얼추 얼개를 만들어줬지만 바로 열 수는 없었습니다. 결과물이 로깅도 제대로 나오지 않았고, 빈 곳이 많았거든요. 물론 Plan Mode를 활용하여 작업 시작전에 계획을 보았지만 vscode 확장을 만들때 로깅은 어디서 할 수 있는지, 포매터와 관련된 API는 무엇인지 전혀 알지 못 하니 제대로 피드백을 줄 수 있을리도 만무하였습니다.

결국 위와 같은 실패는 관련 지식이 없는 상태에서 무작정 에이전트에게 맡겼을 때 그것을 제대로 평가할 수 없어서 발생하는 문제입니다.

별개로 개인적인 우선순위를 잘 조절하지 못 하고 충동적으로 개발을 한 것이 있습니다.

개인적으로 읽으려던 책이 있고, 이력서도 갱신 및 지원해야 했으나 이를 수행하지 못 했습니다. 오픈소스 작업을 하다보니 계속 연달은 작업(Yak-shaving?)이 생기기 마련인데 그 흐름을 그냥 따라가다 보면 시간은 훌쩍 지나있습니다.

즐겁기는 할 지언정 돌이켜볼때, 그리고 장기적으로 볼 때 아쉬운 점입니다.

2026 W4 이어갈 점 & 개선할 점 & 2026 W5 목표

우선 이어가야 할 부분은 위에 적지는 않았지만 매일 정해진 운동을 하는 것과, 생각이 있을때 글로 써서 남기는 것입니다.

개선할 점은 충동적으로 개발을 하지 않는 것입니다. 회사에서 일 할 때 주간미팅을 하고 주간 목표를 정하고 일하듯이 개인으로써도 그런 것이 필요합니다. 그리고 그에 따라 하루 계획을 간략히 세우고 태스크를 처리하고 싶습니다.

그래서 이미 작성일이 화요일 이므로 2일차이지만 2026 W5에 달성할 목표, 실행할 아이템들을 정해보자면:

문장으로 적어보자면 기존에 여기저기 시작하고 마무리 하지 않은 오픈소스 PR들을 마무리하여 머지될 수 있는 상태로 만드는 것이고, CS 기본을 다시 공부하고, 이력서를 업데이트해서 원래 지원하려던 곳에 지원하는 것입니다. 이렇게 해야할 것들을 나열해보는 이유는 이것 외에 추가적으로 더 무언가를 충동적으로 하지 않고 원래의 목적을 달성하기 위함입니다.

회고 과정 회고

이전에 있던 일을 한 번 쭉 나열해보면서 무엇을 했는지 돌아보는 것이 좋았습니다. 이 과정에서는 최근에는 매일 적고 있는 개인 위키(Obsidian) 데일리 노트가 도움이 많이 되었습니다.

다음에 할 일을 미리 적어보는 것은 일단 1주일 해봐야 알겠지만 미리 생각해본다는 점에서 좋았습니다.

전체적으로 현재 마크다운으로 글을 작성하고 있는데 hongdown이 알아서 유려하게 포매팅을 적용해줘서 글쓰기 굉장히 수월했습니다. 이미지를 많이 사용하지 않아서도 있지만 이 정도만 되어도 Hashnode 에디터 같은 별도 에디터 없이 Zed에서 개인 블로그 글 쓰기 충분한 것 같습니다.

또한 글을 작성하기 전에 목차를 전부 나열하고 시작한 것이 좋았습니다. 시간도 어느 정도 소모할 것이라고 처음에 정하고 시작했고 결국 지키지 못 했지만 그 시간 안에 할 수 있는 목차를 작성하는데 도움이 되었습니다. 안 그랬더라면 2025년과 그 전 이야기, 그리고 이런 저런 생각들로 글이 끝나지 않고 또 잘 작성하지 못 했을 것입니다.

다음 회고에서는 지난 2일과 앞으로 남은 5일 정도만 타겟하게 되므로 2025년 이야기를 적었던만큼 다른 내용을 적어보고 싶은데 데일리 노트에 읽었던 책이나, 글 및 감상들을 남기기도 하므로 인상깊었던 점들을 정리해서 남겨보려고 합니다.