목차06
ballast를 회사에서 사용하며 편리함을 느꼈다.
그 경험을 공유하려니 설명만으로는 부족했다. 무엇을 할 수 있는지 이야기하는 것보다 직접 만든 것을 보여주고 싶었다.
그래서 성격이 다른 프로젝트를 작업했다.
rutter, showhow, cicerone, ingot.
이름을 나란히 놓으면 하나의 시리즈 같지만, 실제로 다루는 문제는 꽤 다르다. 한국에서 마케팅하는 일, 업무를 문서로 남기는 일, 채용 공고와 지원 서류를 다루는 일, 이미지를 압축하는 일이다.
나는 이 차이가 오히려 궁금했다.
한 가지 분야에서 쓸모 있었던 작업 방식이, 다른 것을 만들 때도 도움이 될까?
1. rutter — 한국에서 실제로 쓸 수 있는 답
마케팅 문구를 부탁하면 문장 자체는 금방 나온다.
그런데 한국에서 사용하려면 문장 밖의 조건도 봐야 한다. 어느 채널에 올리는지, 그 채널이 요구하는 형식은 무엇인지, 확인해야 할 표시와 규정은 무엇인지 알아야 한다.
rutter는 이런 맥락을 AI에게 읽히기 위한 한국 마케팅 지침 묶음이다. 일반적인 문구 생성만이 아니라 우리 사업의 정보와 실제 채널의 자료를 함께 사용하도록 정리했다.[1]
여기서 좋은 결과는 유창한 문장 한 개로 끝나지 않는다.
필요한 정보를 빠뜨리지 않았는지, 무엇을 근거로 썼는지, 적용하려는 채널과 맞는지 확인할 수 있어야 한다. 정책과 규정이 바뀔 수 있으므로 확인 시점도 중요하다.
이 프로젝트에서는 모르는 조건을 자신 있게 채워 넣는 것보다, 확인할 부분을 정확하게 찾는 것이 필요했다.
2. showhow — 일을 하고 나서 다시 설명하는 일
업무를 한 번 수행하고 나면 다른 사람에게 설명할 문서가 필요할 때가 있다.
어느 화면에서 무엇을 눌렀는지, 다음에는 어떤 결과가 나오는지 다시 정리한다. 작업은 했는데 설명을 위해 같은 화면을 또 만드는 셈이다.
showhow는 화면의 변화를 담아 단계별로 정리하고, 문서로 내보내는 도구다. 브라우저에서 사용하는 HTML 파일 형태이고, 담긴 화면에 설명을 붙이거나 섹션을 나눠 PDF·PPT·워드 등으로 옮길 수 있게 구성했다.[2]
여기에서는 캡처가 된다는 사실만으로 충분하지 않았다.
필요한 순간이 빠지지 않아야 하고, 불필요한 화면이 너무 많이 쌓이지 않아야 한다. 나중에 설명을 고칠 수 있어야 하며, 받는 사람도 그 문서를 사용할 수 있어야 한다.
나는 이 프로젝트를 보며 사용자의 작업이 어디서 끝나는지 다시 생각했다. 화면을 담는 순간이 아니라, 누군가 그 설명을 읽고 일을 이어갈 수 있는 순간까지 봐야 했다.
3. cicerone — 사람의 이력을 대신 만들어서는 안 된다
cicerone은 한국 채용 공고를 평가하고 지원 서류를 준비하는 도구다. 공고의 조건을 보고, 지원자의 자료와 비교하고, 문항에 맞는 초안을 만드는 과정을 다룬다.[3]
여기서는 또 다른 기준이 필요했다.
글이 그럴듯하다고 좋은 자기소개서가 되는 것은 아니다. 실제로 해보지 않은 일을 경험처럼 채우면 안 되고, 지원자가 확인해야 할 조건을 흐리게 만들어서도 안 된다.
어떤 경험을 근거로 썼는지 보이고, 부족한 정보는 부족한 채로 남아야 한다. 공고에 있는 조건과 내가 추정한 내용도 구분해야 한다.
사용자가 원하는 선택을 대신 정하는 것이 아니라, 선택을 위해 읽어야 할 것을 정리하고 문서를 준비하는 역할에 가깝다.
문장을 잘 만드는 능력만 보고 있었다면 지나칠 수 있는 부분이었다.
4. ingot — 좋아 보인다는 말로는 부족한 분야
ingot에서는 이미지 압축을 다뤘다. C로 구현한 손실 이미지 코덱이다.[4]
이 분야에서는 결과물이 생겼다고 끝나지 않는다.
파일이 작아졌다면 화질은 어땠는지 봐야 한다. 화질 지표가 좋아졌다면 속도와 복잡성에는 어떤 비용이 생겼는지도 봐야 한다. 어떤 이미지에서 비교했는지에 따라 결과도 달라질 수 있다.
저장소에는 비교 결과뿐 아니라 채택하지 않은 변경과 한계도 남겨두었다. 압축 측면에서 유리한 항목이 있어도 인코딩과 디코딩의 속도 비용이 있고, 비교 대상의 설정과 이미지 구성에도 조건이 있다.[4]
그러니 ‘기존 코덱보다 좋다’라는 한 문장으로 정리할 수는 없다.
나에게는 그 점이 중요한 경험이었다. 개선하려면 무엇을 측정하는지부터 정해야 하고, 한쪽이 좋아진 만큼 다른 쪽에서 무엇을 잃었는지도 봐야 했다.
- rutter
- 한국 마케팅에 필요한 지침 묶음맥락·출처·채널 조건과 확인 시점
- showhow
- 작업 화면을 단계별 설명 문서로필요한 장면·수정 가능성·읽고 이어 할 수 있는지
- cicerone
- 채용 공고 평가와 지원 서류 초안실제 경험의 근거·부족한 정보·지원자의 판단
- ingot
- 손실 이미지 코덱비교 조건·파일 크기·화질·속도의 비용
같은 기준으로 성공을 말할 수는 없었다
네 프로젝트에서 결과물을 만들고 개선할 수 있었다. 서로 다른 특성의 작업에서도 이 방식이 내게 도움이 된다는 경험을 했다.
하지만 그 결과를 하나의 점수로 묶고 싶지는 않다.
rutter에서는 맥락과 출처가 중요했다. showhow에서는 실제 작업을 설명으로 남기는 흐름이 중요했다. cicerone에서는 사람의 실제 정보와 판단을 존중해야 했다. ingot에서는 비교 조건과 측정, 교환한 비용을 봐야 했다.
모두 만들 수 있었다는 말과, 모두 같은 수준으로 검증됐다는 말은 다르다. 코드 검사나 내부 비교가 외부 사용자의 만족과 시장 성과를 대신해주는 것도 아니다.
나는 그 차이를 남긴 채로 공유하고 싶다.
내가 보여주고 싶은 것
처음부터 이 네 분야를 전부 잘 알고 있어서 만든 것은 아니다.
모르는 것을 찾아보고, 이번 결과에 필요한 기준을 정하고, 에이전트와 작업하고, 나온 결과를 다시 확인하는 과정을 거쳤다. 분야가 바뀌면 배워야 할 것도 바뀌었다.
내가 공유하고 싶은 것은 그 과정이다.
AI가 무엇이든 완벽하게 만들어준다는 이야기가 아니다. 모르는 일을 만났을 때 어떻게 접근하고, 무엇을 확인하면서 결과를 만들 수 있는지 보여주고 싶다.
그래서 프로젝트의 이름과 기능만 나열하는 것보다, 각 프로젝트에서 어떤 문제가 달랐는지 남기려 한다.
저장소를 열어 실제로 사용해보고, 부족한 부분도 확인할 수 있었으면 한다. 나도 계속 배우면서 고치고 있다.
프로젝트 원문
자료 확인: 2026-09-06. 이 글의 적용 경험은 작성자의 경험이고, 저장소에 보고한 검사·비교 결과를 독립적인 외부 검증으로 표현하지 않았다.