[🤖] Codex Skill로 작업의 흐름과 감각을 이어 붙였다

✨ GPT-5.6 Sol의 요약 　

Linux 서버에서 막 세운 판단을 다음 작업과 글쓰기로 곧바로 넘기기 위해, Codex Skill이 현재 규칙과 작업 증거를 다시 읽게 만들며 흐름을 끊지 않은 기록.

오늘 회사 서비스용 Linux 서버의 운영 기반을 세웠다. 새 SSD에 Ubuntu Server를 설치하고 내부 SSH를 붙인 뒤, 사람 관리자와 AI Cell, 업무 자동화 Runtime이 한 서버에서 서로의 권한과 상태를 침범하지 않도록 사용자 경계까지 설계했다.

서버의 구체적인 디스크·네트워크·계정 구조는 위 글에 따로 정리했다. 여기서 다시 쓰고 싶은 것은 설치 방법이 아니라, 그 작업을 끝낸 뒤에도 판단의 흐름이 끊기지 않았던 경험이다.

공유기와 NAS, 기존 Runtime, 새 Linux 서버가 어떻게 이어지는지 네트워크 Skill에 남기고 나니 다음 Codex session에서도 장비 목록부터 다시 설명할 필요가 없어졌다. 완료된 것과 아직 설계만 한 것도 갈라두었다. 서버를 만지며 만든 운영 감각을 다음 작업이 그대로 이어받을 수 있는 상태였다.

굿. 이제 스킬 쓰는 게 익숙해져서 이런 것도 금방금방 세팅하는구만. 아주 좋다. 역시 뭐든 흐름을 유지하면서 감각을 놓치지 않는 게 중요한 듯.

그때 좋았던 건 스킬 하나를 빨리 만들었다는 사실만이 아니었다.

서버를 만지며 막 생긴 운영 감각이 사용자 구조로 이어지고, 그 구조가 네트워크 Skill에 남고, 다시 그 작업을 설명하는 devlog로 이어졌다. 글까지 쓰고 나니 이번에는 최근 작업을 대화와 Git 기록에서 찾아 일기로 만드는 Skill을 만들면 되겠다는 생각이 바로 들었다.

서버 구축과 글쓰기 Skill은 전혀 다른 작업인데도 머릿속에서는 같은 흐름이었다. 앞에서 어떤 정보를 남겨야 다음 작업이 처음부터 다시 시작되지 않는지 계속 고민했고, 그 답을 곧바로 다음 도구의 구조에 써먹고 있었다.

새로운 Skill도 앞에서 만든 흐름을 재사용했다

예전에 개인 스케줄러에 넣을 시간별 업무 기록을 만들려고 gsheet-hour-blocks를 만든 적이 있다. 현재 대화만 요약하는 것이 아니라, 관련 repository의 Git 기록까지 함께 읽고 실제로 한 일을 시간 블록 문장으로 압축하는 Skill이었다.

이번에는 출력만 달랐다.

최근 대화와 명령, tool 결과, 지정한 기간의 Git 증거를 읽는 뼈대는 이미 있었다. 그 증거에서 작업 목록이 아니라 내가 실제로 느낀 문제와 판단의 변화를 찾고, 현재 블로그 규칙에 맞는 독립 일기로 쓰게 하면 됐다.

완전히 새로 설계할 필요가 없었다. 앞에서 익힌 방식이 다음 방식의 재료가 됐다.

매번 반복하던 “완벽하게 한 거야?”를 audit-and-fix-until-clean이라는 Skill로 바꿨던 경험도 남아 있었다. 반복되는 요구를 발견하면 긴 prompt를 또 쓰는 대신, 재사용할 수 있는 작업 방식과 종료 조건으로 굳힌다. 몇 번 같은 방식으로 부딪히고 나니 어떤 부분을 Skill에 넣고 어떤 부분은 원래 project에 남겨야 하는지도 전보다 빨리 보였다.

그 감각 덕분에 blog-write-diary의 큰 구조는 금방 잡혔다.

다만 Codex가 한 번 잘못된 방향으로 갔다.

규칙을 복사하면 맥락이 이어지는 게 아니라 갈라진다

처음에는 이 블로그의 카테고리와 문체, 날짜, 번역 규칙을 새 Skill 안으로 옮기려 했다.

내가 원한 것은 그게 아니었다.

그걸 스킬로 복제해서 옮기라는 게 아니라. 정확히는 cdb 프로젝트 내부 룰이나 그런 맥락들을 바로 읽도록 하는 거야. 옮기는 작업은 추후에 할 거야.

블로그 규칙은 계속 바뀐다. 그것을 Skill에 복사하면 같은 규칙이 두 군데에 생긴다. 처음에는 잘 작동해도 어느 순간 project의 현재 규칙과 Skill이 기억하는 과거 규칙이 갈라진다. 맥락을 이어가려고 만든 장치가 오히려 낡은 맥락을 고정하는 셈이다.

그래서 blog-write-diary는 블로그 규칙을 소유하지 않게 했다.

Skill이 기억하는 것은 작업 절차뿐이다. 현재 대화와 명령, Git 증거를 어떤 순서로 읽을지, 그 안에서 하나로 이어지는 중심을 어떻게 찾을지, 그리고 실제 글을 쓰기 전에 cdb의 현재 AGENTS.md와 카테고리, 인접 게시물을 다시 확인해야 한다는 절차다.

바뀌는 규칙은 원래 project에 남고, Skill은 실행할 때마다 그 source of truth로 돌아간다.

이 차이가 핵심이었다. AI에게 모든 맥락을 오래 기억시키는 대신, 필요한 순간에 현재 맥락으로 정확히 다시 들어오는 길을 만든 것이다.

이어진 것은 정보량보다 판단의 감각이었다

AI의 context는 한정돼 있다. 대화가 길어지면 압축되고, 다른 session으로 넘어가면 이전의 미묘한 판단은 쉽게 사라진다. 그렇다고 모든 대화를 영원히 저장하고 매번 전부 읽힐 수도 없다.

중요한 것은 정보 전체를 보존하는 일이 아니었다.

다음 작업을 시작할 때 왜 이 경계가 중요했는지, 무엇을 이미 버렸고 무엇을 지키기로 했는지, 지금 어떤 source를 믿어야 하는지를 다시 복원할 수 있어야 했다. 그 상태가 되면 AI도 결론만 흉내 내는 것이 아니라 앞에서 이어지는 판단을 할 수 있다.

사람인 나도 마찬가지였다.

오늘은 서버 계정과 Runtime을 왜 분리해야 하는지, 왜 project 규칙을 Skill에 복사하면 안 되는지가 바로 보였다. 판단의 근거가 아직 뜨거웠기 때문이다. 시간이 지난 뒤 결론만 어렴풋이 남으면 같은 설명을 다시 읽어도 지금과 같은 감각으로 곧바로 이어가기 어렵다.

예전에 인간의 기억은 압축되고 단서를 통해 다시 살아난다고 썼다. 이번에는 그 생각을 실제 작업 방식으로 써본 셈이다.

Skill과 AGENTS.md, Git 기록은 모든 순간을 보존하는 창고가 아니다. 다음 session의 AI와 미래의 내가 작업에 다시 들어갈 때 판단을 재구성하게 해주는 단서다. 잘 남겨진 결론 하나보다, 현재 source와 증거를 다시 따라가며 그 결론에 도달할 수 있는 경로가 더 쓸모 있었다.

감각이 살아 있을 때 다음 흐름까지 만들어둔다

이번에 즐거웠던 이유는 blog-write-diary를 금방 만들었기 때문만은 아니다.

Linux 서버를 세우며 얻은 감각이 사용자 구조와 네트워크 Skill로 이어졌고, 그 운영 판단이 devlog로 이어졌고, 글을 쓰던 흐름이 다시 새로운 일기 Skill의 설계로 이어졌다. 어느 단계에서도 완전히 처음으로 돌아가지 않았다.

그게 좋았다.

개발이든 글쓰기든, 앞에서 쌓은 판단이 살아 있는 동안 다음 작업으로 넘어가면 속도만 빨라지는 게 아니다. 무엇이 중요한지 다시 찾느라 헤매지 않으니 결과의 수준도 같이 이어진다. 잘 되는 이유를 설명할 수 있고, 틀린 구조가 보이면 더 빨리 멈출 수 있다.

AI의 짧은 context를 다루려고 만든 구조가 결국 내 짧은 기억도 보완해주고 있다. 하지만 이번 글에서 사람과 AI가 둘 다 잘 잊는다는 사실은 결론의 전부가 아니다.

내가 계속 만들고 싶은 것은 기억 장치보다 흐름을 다시 이어주는 장치에 가깝다.

다음에 다시 시작할 때 처음부터 설명하고 감을 되찾는 것이 아니라, 지금 도달한 판단 위에서 바로 다음 한 걸음을 시작할 수 있도록.