코덱스 사용일지 - 2월 16일 아침부터 17일 새벽까지
코덱스 사용일지 - 2월 16일 아침부터 17일 새벽까지
잡담
하루가 길어지면,
코덱스로 이것저것 많이 했는데 기억이 한 덩어리로 뭉개진다.
그래서 이번엔 타임라인 나열 말고
“중요한 일 + 왜 그걸 했는지”로 정리해본다.
로그 기준 기간
- KST 기준
2026-02-16 06:00~2026-02-17 05:59 - 이 구간 로그에서 확인된 세션: 92개
어제~오늘 새벽에 한 큰 일들
- 아침에는 OMX 팀 병렬 실행 실험
- 한 일:
codex_bot에서 여러 에이전트를 동시에 돌리는 방식(팀 실행)을 크게 테스트. - 왜: 혼자 순차로 하면 느리고, 어디서 막히는지 늦게 보이기 때문.
- 결과: “요구사항 분석 -> 구현 -> 검증”을 병렬로 굴리는 작업 습관을 실제로 돌려봄.
- 낮에는 Ju Office 기획을 제품 형태로 정리
- 한 일:
Ju_Office아이디어를 문서 중심으로 구조화하고, 해야 할 일의 기준을 세움. - 왜: 아이디어만 있으면 계속 방향이 흔들리기 때문.
- 결과: 추상적인 생각이 “어떤 기능을 어떤 순서로 만들지” 수준으로 내려옴.
여기서 Ju Office는
가상 스타트업처럼 여러 AI 에이전트가 협업하는 걸 보여주는 실험 프로젝트다.
- 오후에는 화면/데모 완성도 올리기
- 한 일:
codex_office/Ju_Office에서 사무실 바닥, 에이전트 캐릭터, 좌표, 시각 요소를 보강. - 왜: 내부적으로만 좋은 구조보다, “보는 사람이 이해되는 데모”가 필요했기 때문.
- 결과: GitHub 협업 흐름 + 2D 오피스 UI를 같이 보여주는 방향이 선명해짐.
- 저녁에는 리뷰 루프를 강하게 돌림
- 한 일: Architect/Security/Code 리뷰를 반복해서 받고, 막히는 항목을 다시 수정.
- 왜: 빨리 만드는 것만큼 “부서지지 않게 만드는 것”이 중요해서.
- 결과: 단순 구현이 아니라, 검증 가능한 상태로 다듬는 흐름을 경험함.
- 밤에는 OMX Autopilot과 Ju Office 간격 줄이기
- 한 일:
Ju_Office의 동작 흐름을 OMX의 autopilot 방식과 비교하고 맞추는 작업 진행. - 왜: 실제 사용 시 명령/상태 전환/완료 조건이 복잡하면 결국 못 쓰게 되기 때문.
- 결과: “작동은 하는데 쓰기 어려운 상태”에서 “어떻게 단순화할지 보이는 상태”로 이동.
- 늦은 밤에는 블로그 복구/운영도 같이 처리
- 한 일:
poul.kr의 배포 구조 확인, 소스 복구, 불필요 포스트 정리, 점검, 글 작성/배포. - 왜: 개발 기록을 쌓을 기본 채널(블로그)을 다시 정상화하려고.
- 결과: 블로그를 다시 쓰고 배포하는 루틴이 재가동됨.
- 새벽에는 실제 사용성 체크
- 한 일: 설치/실행 명령이 실제로 헷갈리지 않는지, 바로 동작하는지 확인.
- 왜: 문서가 좋아도 첫 실행이 막히면 사용자 입장에서는 실패라서.
- 결과: “복잡도 낮추기”와 “설치/실행 안내 단순화”가 다음 우선순위로 확정됨.
오늘 결론
어제~오늘 새벽은
“기능 하나 대박”의 날이라기보다
“여러 프로젝트를 실제로 굴러가게 만드는 뼈대”를 잡은 시간이었다.
한 줄 요약:
“속도, 품질, 사용성 세 가지를 동시에 맞추는 쪽으로 코덱스 사용법을 다듬은 날.”
코덱스 사용일지 - 2월 16일 아침부터 17일 새벽까지
https://poul.kr/2026/02/17/20260217-codex-log-diary-0216-0217/