2026년에는 코드를 읽고 수정하는 방법부터 반복 작업을 돌리는 환경까지 여러 번 바꿨다. 새로운 도구를 얼마나 붙였는지보다, 써보면서 어떤 확인이 더 필요해졌는지를 남겨두려 한다. 회사의 운영 코드, 별도 고객 과제, 개인 서비스에서 한 일은 구분해 적었다.
1월 · 설명이 매끄럽다고 경로가 맞지는 않았다
운영 중인 서버를 고치기 전에 요청이 어느 파일을 지나 어느 테이블까지 가는지 AI에게 찾아 달라고 했다. 함수 이름만으로 역할을 짐작하거나 호출되지 않는 코드를 넣기도 했다. 설명을 받은 뒤 파일과 줄을 직접 열고, 로그가 있으면 실제 요청 경로와 맞춰 봤다. 확인한 내용은 인수인계 문서 초안으로 썼다.
2월 · 확인할 화면에 들어가지 못했다
같은 설명을 반복하지 않으려고 저장소에 AGENTS.md를 뒀다. 브라우저 테스트도 자동화하려 했지만 Docker 안의 크롬에서는 구글 로그인 뒤로 넘어가지 못했다. 당장 우회하기보다 테스트 계정 경로의 보호 방법을 더 살펴보기로 하고 미뤘다.
3월 · 로그에서 운영 버전까지 질문이 이어졌다
Lambda 로그가 너무 많아 오류 한 줄을 찾기 어려웠다. 요청 ID와 오류를 중심으로 로그를 정리하다 보니, 지금 도는 함수가 어느 커밋에서 왔는지도 설명해야 했다. 배포 후 확인 방법을 모으고 소스·산출물·되돌릴 버전을 이어 적는 기준을 정했다. 기준을 세운 것과 모든 서비스에 적용한 것은 따로 남겼다.
4–5월 · 문장 생성과 기능 완성은 달랐다
개인 앱에서 llama.rn으로 Gemma·TinyLlama를 불러와 요약을 만들었다. 모델 선택과 다운로드, 모델이 없을 때의 기존 요약 복귀까지 붙여야 실제 기능으로 쓸 수 있었다.
화면 검수에서도 실행과 평가를 나눴다. DevTools MCP·Maestro로 캡처했지만, 캡처 90장 정도를 한꺼번에 평가시키니 빠진 화면이 있었다. 화면 목록과 개별 평가 결과를 맞추는 일이 새로 필요했다. 새 도구 몇 가지는 설치하거나 검토한 뒤 쓰지 않기로 했다.
6월 · 내 컴퓨터 밖에서도 실행돼야 했다
개인 예약 작업은 Ubuntu 미니 PC로 옮겼다. Mac에서 한 번 실행한 것만으로는 부족해 실행 계정과 재접속 뒤 명령, 예약 실행도 살폈다.
별도 고객 과제에서는 운영 원본을 보존하며 학습용 Arrow를 직접 생성했다. 연구자가 Windows에서 실행할 절차를 마련하고 자료와 전화 설명으로 인계했다. 내 실행 환경을 정리하는 일과 다른 사람의 실행 환경을 준비하는 일을 함께 겪었다.
7–8월 · 성공 응답 뒤의 상태와 보고를 살폈다
회사 커머스 배치에서는 후속 요청 충돌이 앞 거래까지 취소할 수 있는 경로를 고쳤다. 개발 DB와 회귀 테스트를 확인하고 7월 운영 Batch에 제한 적용했다. 후속 경쟁 상태 보완의 개발 검증은 그 적용과 구분한다.
개인 모니터는 정상일 때도 보고가 쌓이는 문제가 있었다. 정해진 주소의 응답 비교는 스크립트로 옮기고, 장애나 복구처럼 상태가 달라질 때만 알리게 했다. 조용해졌다고 실행까지 멈추지는 않았는지 기록으로 확인했다.
9월 · 실행한 것과 설명할 수 있는 것을 맞췄다
블로그를 만들고 통계 갱신을 서버로 옮겼다. 8월 청구서가 나온 뒤에는 AWS 비용 감소의 원인을 항목별로 살폈다. 같은 달의 온디바이스 평가에서는 형식상 정상인 요약에도 입력에 없는 내용이 섞일 수 있음을 확인했다. 실행 성공이라는 한 줄로 묶기 어려운 결과들이었다.
도구를 쓰는 사람에게도 전달해야 했다
2026년 회사 업무에서는 상담 담당자에게 클로바 전사·요약 활용법을 교육했다. 오인식은 담당자가 통화 뒤 텍스트 요약을 추가해 보정하도록 했다. 여기서는 프로그램을 만드는 것보다 결과를 어떻게 읽고 고칠지 설명하는 일이 중심이었다. 교육한 정확한 달을 확인하지 못해 위의 월별 작업과 합치지는 않았다.
지금도 새로운 도구를 보면 먼저 어떤 부분에 써볼 수 있을지 생각한다. 다만 더 많은 일을 실행하는 것만으로 다음 단계에 갔다고 보기는 어렵다. 빠진 화면, 앞 거래의 상태, 연구자의 실행처럼 그때 확인하지 못했던 것을 다시 볼 수 있어야 했다.