2026년 4~5월 작업 총평 — 기록이 있어야 패턴이 보인다

2026년 4월 1일부터 5월 19일까지, 총 33일치 일간 작업일지를 기반으로 한 회고입니다. 회사 업무 내용보다 개인으로서의 성장 패턴에 초점을 맞췄습니다.

1. 잘하고 있는 것

기록 습관이 존재한다

가장 먼저 눈에 띄는 강점은 매일 시간 단위로 기록한다는 것입니다. 시간 로그가 있다는 사실 자체가, 하루가 어떻게 흘렀는지 되돌아볼 수 있는 최소한의 재료를 확보한다는 의미입니다. 많은 사람들이 기록의 필요성을 알면서도 실천하지 않는다는 점에서, 이 습관은 유지할 가치가 충분합니다.

자기 인식이 있다

4월 24일의 “이번엔 물어보고 작업 진행함 — 도움을 요청하지 못하는 문제 고치기“, 4월 29일의 “예상했던 상황과 기대했던 상황이 일치하는지 검토 후 작업하는 게 정확함의 조건“, 4월 30일의 “상황부터 확인했어야 했다” — 이 회고들은 단순한 반성이 아닙니다. 자기 행동의 패턴을 언어로 포착하려는 시도입니다. 이게 반복되면 진짜 변화가 생깁니다.

기술 탐구에 적극적이다

두 달 사이에 Go, gRPC/RPC, DPI 크롤링, Kubernetes, ArgoCD, GraalVM Native Image, TTS/STT, F1 Score 측정까지 탐구 범위가 넓습니다. “MSA를 전환할 때 DLL과 Jar를 추출해서 Docker로 분리한 뒤 gRPC로 전환“처럼, 큰 그림에서 아키텍처를 사고하려는 흔적도 있습니다. 새로운 것을 배우는 것 자체를 두려워하지 않는 태도는 중요한 자산입니다.

복잡한 문제를 문서화하려 한다

4월 10일, 난이도 버그의 원인-경위-해결 과정을 “1월 11일 코드 개선 작업 중 소스가 의도치 않게 변경됨“처럼 정확하게 기술한 것은 좋은 습관입니다. 버그를 고치는 것과 그 버그를 설명할 수 있는 것은 다릅니다. 후자가 훨씬 어렵고 더 가치 있습니다.

2. 개발 관점 — 명료하게 했어야 했던 것들

① 작업 시작 전: WHAT / WHY / DONE을 먼저 쓴다

4월 30일 일지에서 스스로 “무엇을/왜/언제까지/경계/성공기준 — 작업 시작할 때 이미징하기 위한 절차“라고 적었습니다. 이걸 이미 알고 있다는 뜻입니다. 그러나 같은 기간 일지를 보면, 작업을 시작하고 나서 방향을 잡는 패턴이 반복됩니다.

작업 시작 전 3줄: 나는 지금 X를 한다 / 이유는 Y이다 / 완료 기준은 Z이다.

이 3줄이 없으면 “작업 중”과 “표류 중”을 구분하기 어렵습니다.

일지에 빈 시간 슬롯이 자주 등장하는 것(15:00~17:00 비어있는 날들)은 기록을 못 한 것일 수도 있지만, 작업이 방향을 잃은 시간일 수도 있습니다. 시작 전 3줄이 있으면 이 공백이 줄어듭니다.

② 버그 해결 순서: 틀어막기 전에 상황 파악

4월 30일에 이미 스스로 정리했습니다: 상황 확인 → 재현 → 패턴 분석 → 해결. 그리고 같은 날 “바로 문제가 발생할 법한 부분을 틀어막는 것에만 몰입함 — 이건 재현이 불가능했고 의미 없는 시간으로 소모됨“이라고 회고했습니다.

이것은 단순한 실수가 아닙니다. “빠르게 고쳐야 한다”는 심리적 압박이 순서를 뒤집습니다. 재현이 안 된다면, 재현 환경을 만드는 것이 먼저입니다. 재현이 안 되면 고친 것도 검증할 수 없습니다.

③ 테스트 완료의 기준을 명시한다

4월 29일: “테스트 성공 → 하지만 정확한 테스트는 미흡. 정확하게 진행하려면 이전에 선택되었을 때 내가 예상한 바가 맞는지 점검하고, 현재 선택했을 때 정확하게 맞는지 — 예상한 상황과 기대한 상황이 일치하는지 검토 후 작업하는 게 정확함의 조건“

이 인식은 정확합니다. “작동한다”와 “정확하게 작동한다”는 다릅니다. 테스트 케이스를 쓸 때 입력/예상 출력/실제 출력 세 가지를 미리 적어두는 것, 그리고 “성공”이라고 말하려면 예상과 실제가 일치하는지를 기준으로 하는 것이 다음 단계입니다.

④ 예외 처리에는 반드시 로그를 남긴다

4월 24일에 코드 리뷰 피드백으로 받은 내용입니다: “예외 케이스는 구현하지 않기. 꼭 구현되어야 한다면 로그가 기록되어야 함. 비동기 오류나는 부분은 특히 로그 기록이 진행되어야 함.“

이것은 개인 성장에서도 동일하게 적용됩니다. 예외 상황(내가 예상하지 못한 케이스)을 처리할 때 로그가 없으면, 나중에 무슨 일이 있었는지 알 수 없습니다. 코드뿐만 아니라 일지에서도 “이상한 부분 발견“으로만 남기면 나중에 같은 패턴을 인식하기 어렵습니다.

⑤ 도움 요청을 더 빨리 한다

4월 24일: “이번엔 물어보고 작업 진행함 — 도움을 요청하지 못하는 문제 고치기. 틀린 것들이 많았고 도움을 요청함으로써 정리됨.“

혼자 오래 붙잡는 것이 실력이 느는 것처럼 느껴지지만, 방향이 틀린 채로 오래 붙잡는 것은 그냥 시간 소모입니다. “30분 넘게 방향이 안 잡히면 묻는다”는 개인 규칙을 만들어두면 심리적 장벽이 낮아집니다.

3. 회고 습관 자체에 대한 피드백

채워진 회고와 빈 회고의 차이가 크다

회고 3질문(“오늘 내가 다룬 문제는 무엇인가 / 어떻게 정의했는가 / 더 단순하게 만들 수 있는 방법은”)을 실제로 채운 날은 소수입니다. 채운 날의 일지는 읽으면 그날의 핵심이 보이고, 비워진 날의 일지는 무슨 일이 있었는지 알기 어렵습니다.

회고 질문이 있는데도 빈 채로 남기는 이유는 하나입니다. 그날 끝날 때 피곤하다는 것. 해결책은 질문을 더 쉽게 만드는 것입니다.

3가지 질문 대신, 하루 1문장만: “오늘 내가 막혔던 순간은 [ ]이고, 그 이유는 [ ]이었다.”

“시도 / 기대 / 결과” 패턴이 가장 유용하다

4월 24일과 4월 29일에 이 형식으로 회고를 남긴 부분이 있는데, 읽어보면 다른 날보다 훨씬 구체적이고 다음에 도움이 될 정보가 담겨 있습니다. 이것이 생각보다 강력한 형식입니다. 작은 단위로라도 매일 1개씩 남기는 것을 권장합니다.

4. 개인 성장 방향 — 앞으로의 초점

5월 18일 메모가 방향을 말해준다

“결국 가장 값비싼 자산은 AI가 만든 것을 보고 이건 틀렸다고 말할 수 있는 사람이 되었다.“

이 한 문장이 앞으로 어디에 시간을 써야 하는지를 정확히 가리킵니다. AI를 잘 쓰는 능력은 앞으로 계속 평준화됩니다. 반면 “이 결과가 맞는가”를 판단하는 도메인 이해와 비판적 사고는 희소해집니다. 5월 4일에 “AI 없이 어떻게 작업을 이어나갈지 고민 — 전체적인 맥락을 모두 알고 있어야 한다”고 쓴 것도 같은 방향입니다.

학습 목표가 분산되어 있다

4월 3일에는 SQLP·DAP·한자·수학이 등장하고, 5월 19일에는 COS Pro 1급이 등장합니다. 5월 8일에는 “자꾸 수학이랑 한자로 알고 싶은 부분에서 막히는 중. 너무 답답함“이라고 했습니다.

학습 목표가 넓으면 진척이 느리고, 진척이 느리면 포기하게 됩니다. 지금 6개월 안에 가장 직접적인 영향을 줄 하나를 고르는 것이 나머지 목표들에도 좋습니다. 기준은 단순합니다: “이걸 잘하게 되면 지금 하는 일이 더 빠르고 정확해지는가?”

Go와 클라우드는 계속 깊어질 가치가 있다

두 달간 gRPC, RPC 아키텍처, MSA 전환 설계, Docker, ArgoCD, Kubernetes를 꾸준히 탐구했습니다. 이 방향은 계속 유효합니다. Go 언어 자체에 대한 투자는 특히 값어치가 있습니다. 익숙한 언어로 코드를 짜는 것과, 그 언어의 동시성 모델·런타임·메모리 모델을 이해하고 짜는 것은 완전히 다른 결과물을 만듭니다.

요약 — 한 줄씩

항목	현재	다음 단계
작업 시작	시작 후 방향 잡기	3줄(WHAT/WHY/DONE) 먼저 쓰기
버그 해결	빠른 틀어막기	상황 확인 → 재현 → 패턴 → 해결 순서 고수
테스트	“작동한다”가 기준	입력/예상 출력/실제 출력 3개 먼저 정의
회고	질문은 있으나 자주 비워짐	1문장으로 낮추고 매일 채우기
도움 요청	늦게 요청	30분 규칙 — 막히면 묻는다
학습	목표 분산 (자격증·언어·수학)	6개월 단위로 하나만 선택
핵심 방향	AI로 빠르게 만들기	AI 결과물을 검증하는 판단력 키우기

기록은 이미 하고 있다. 남은 것은 기록한 것을 보고 패턴을 바꾸는 것.