TRAE로 버그 수정 일상 정리해 보고서 만든 개발자 사례

참가 트랙: 트랙 1 · TRAE 전 링크 실전 / 토픽: #全新 TRAE 实战体验

새로운 TRAE로 혼자서 작은 도구 하나를 완성했다. 가장 큰 소감은: 그것의 발전이 "코드를 더 잘 짜는" 것이 아니라 "한 가지 일을 끝까지 밀어붙일 수 있는" 것이 되었다는 점이다 — Agent 모드에서는 요구사항 전체를 던져도 곧바로 돌아가는 애플리케이션을 돌려주니 나는 검수와 세부 다듬기만 하면 되고, 비주얼이나 데모 상태처럼 내 속에 그림이 있는 작업은 IDE로 돌아가 직접 수정했다. 예전에는 AI를 데리고 코드를 짰다면, 지금은 일 잘하는 인턴을 데리고 프로젝트를 하는 것에 가깝다: 나는 판단을 맡고, 그것은 실행을 맡는다. 시작 화면은 다음과 같다:

계정 로그인 및 인증:

1. 먼저 내가 무엇을 해결하려는지부터 분명히 하자

매주 금요일 오후 네 시가 되면 우리 회사에서는 똑같은 장면이 정시에 연출된다. 한 무리의 사람들이 주간 보고 시스템의 빈 텍스트 상자를 멍하니 바라보는 것이다.

"이번 주에 나 뭐 했지?" — 온라인 버그 3개 고쳤고, 첫 화면 로딩을 4초에서 1.8초로 줄였고, 기술 문서 두 편 썼고, 신입 사원 코드 리뷰를 진행했고, 회의를 5개 했다.

주간 보고에 적으면 이렇게 된다:

1. 온라인 버그 수정 2. 첫 화면 로딩 최적화 3. 기술 문서 작성 4. 신입 사원 지도 5. 요구사항 검토 회의 참석

상사가 다 보고 나면 반응은 대략 이렇다: "이 사람 이번 주 꽤 한가했네."

하지만 진실은 나는 물 마실 시간도 없이 바빴다는 것이다.

문제는 업무량이 아니라 표현 능력에 있다. 같은 일을 "온라인 버그 수정"이라고 쓰는 것과 "핵심 시스템 안정성 관리 주도, 누적 3건의 온라인 핵심 결함 점검, 장애율 감소, 비즈니스 연속성 보장"이라고 쓰는 것 — 후자가 바로 승진하고 연봉 오르는 그 사람이 쓰는 것이다.

이 변환 과정에는 전문 용어가 있다. "직무 보고 언어 포장"이라고 하며, 통속적으로 말하면 "실행 언어를 관리 언어로 번역하는 것"이다. 어렵지는 않지만 정신력을 극도로 소모한다: 문구를 한 마디 한 마디 생각하다 보면 평균 한 항목에 5분에서 10분을 갈아 넣어야 하고, 주간 보고 하나를 쓰면 40분은 기본이다.

그래서 나는 결심했다: 이 일은 반드시 자동화해야 한다. 그리고 매번 대형 모델이 인터넷에 연결해 즉석에서 지어내는 것에 의존할 수 없으니, 안정적이고 오프라인으로 실행 가능한 번역 엔진이 있어야 한다.

이것이 바로 내가 새로운 TRAE로 0에서 1까지 만들어낸 것 — 「직장인 전적 번역기」다.

대화 내용은 다음과 같다:

2. 핵심 결정: 내 첫 번째 방안은 내 손에 의해 뒤집혔다

이 부분은 따로 이야기하고 싶다. 이번 개발에서 가장 가치 있는 사고이자 가장 시간이 많이 든 부분이기 때문이다.

첫 번째 버전은 이 도구가 아니었다. 당시 나는 2026년의 유행 밈 "끼인 직장인"(치열한 경쟁과 늘어짐 사이에 끼인 사람을 묘사)에 편승하고 싶어서 「끼인 직장인 진단기」를 만들었다 — 설문 응답, 벡터 코사인 각도로 점수 계산, 진단 보고서 출력.

기술적으로는 꽤 멋졌다: 실제로 cos θ = (a·b)/(|a||b|)로 각도를 계산했고, 레이더 차트와 극좌표 벡터 그래프까지 갖췄다.

하지만 완성하고 내가 직접 한 번 써 본 뒤, 이것이 엔터테인먼트 제품이지 문제를 해결하는 도구가 아니라는 것을 발견했다.

- 진단이 끝나면 사용자의 감정은 자극되지만, 내일 출근해서 주간 보고를 써야 할 때 여전히 못 쓴다

- 해결하는 페인 포인트의 강도가 부족하다: 재미있지만, 고빈도도 아니고 필수도 아니고 아프지도 않다

- "실제 업무 장면 효율 향상" 트랙에 참가하기에는 주제에서 벗어났다

나는 그것을 뒤집고 "주간 보고/직무 보고"라는 방향을 다시 골랐다. 이유는 세 글자다: 진짜, 빈도, 아픔.

판단 기준 | 끼인 진단기 | 전적 번역기 실제로 존재하는가 | 그렇다, 그러나 감정적 수요다 | 그렇다, 매주 금요일 정시에 발작한다 고빈도인가 | 1년에 한두 번 테스트 | 매주 한 번 아픈가 | 조금 찔린다 | 정말로 퇴근을 막는다 자동화할 수 있는 부분 | 적다 | 거의 전부

이것이 이번 개발의 첫 번째 핵심 결정이자 내가 밟은 첫 번째 함정이다: 재미있다 ≠ 유용하다. 공모전에서 원하는 것은 멋짐이 아니라 "다 쓰고 나면 문제가 정말로 해결되는 것"이다.

3. 전 링크 개발 과정: Agent 모드 추진 + IDE 모드 인계

이 단락은 나의 실제 조작 기록이다. 새로운 TRAE의 Agent / IDE 듀얼 모드는 이번 개발에서 분업이 특히 명확했고, 나는 기본적으로 이렇게 사용했다:

단계 | 내가 쓴 모드 | 이유 요구사항 분해, 규칙 라이브러리 설계 | Agent 모드 | 발산형 두뇌 노동, 나는 제약과 톤만 주면 된다 단일 파일 애플리케이션 전체 생성 | Agent 모드 | 아이디어에서 납품까지 한 번에 밀어붙임, 내가 지켜볼 필요 없다 비주얼 색상 배색, 하이라이트 세부 | IDE 모드 | 내게 명확한 생각이 있어 손으로 고치는 것이 설명하는 것보다 빠르다 경계 버그 위치 파악 및 수정 | Agent 모드 | 현상을 설명해 스스로 찾게 하는 것이 내가 직접 print 하는 것보다 빠르다 데모 상태 튜닝 | IDE 모드 | 세 줄 코드짜리 일, 돌아와서 바로 고친다

단계 1: Agent가 "번역 규칙 라이브러리"를 만들게 하기 (발산형 과업)

도구의 심장은 UI가 아니라 규칙 엔진이다 — 어떤 키워드가 어떤 말로 번역되어야 하는가. 이 단계가 가장 머리를 써야 한다. 개발, 제품, 디자인, 운영 네 가지 직무의 표현 습관을 모두 커버해야 하기 때문이다.

내가 Agent 모드에서 준 첫 번째 지시는 이러했다:

"직장인 주간 보고 번역기" 도구를 만들려고 합니다. 핵심은 일상적인 말로 된 업무 내용을 고급스러운 직무 보고 언어로 번역하는 것입니다. 번역 규칙 라이브러리 한 세트를 설계해 주세요. 요구 사항:

- 개발, 제품, 디자인, 운영 네 가지 흔한 직무를 커버할 것;

- 각 규칙에는 다음을 포함: 트리거 키워드(여러 개), 번역 템플릿(숫자 자리 표시자 포함), 분류 태그, 점수 가중치;

- 다음 장면을 커버할 것: 버그 수정, 코드 작성, 성능 최적화, 문서 작성, 회의, 요구사항 처리, 신입 지도, 테스트, 출시, 사용자 피드백 처리, 데이터 분석, 페이지 디자인, 운영 활동, 땡땡이;

- 번역 템플릿은 "재미는 있되 황당하지는 않게" — 사람이 피식 웃을 수 있으면서도 실제로 말이 되어야 함;

- JavaScript 코드로 바로 변환 가능한 구조화 형식으로 출력할 것.

Agent가 단숨에 15개의 규칙을 생성했다.

여기에 따로 언급할 가치가 있는 핵심 튜닝이 하나 있다: 내 첫 번째 버전 지시에는 4번째 항목인 "재미는 있되 황당하지는 않게"가 없었다. 그 결과 그것이 생성한 템플릿은 전부 "XX 업무 추진, XX 효율 향상" 같은 관료적 상투어였다 — 정확하지만 재미가 없어서 사용자가 스크린샷을 찍어 공유하고 싶지 않을 것이다.

톤 제약을 더한 뒤로 나온 것의 질감은 완전히 달라졌다. 예를 들어 "땡땡이" 항목에서 그것이 준 원본 버전은 "정력 회복을 진행"이었는데, 나는 너무 정색하고 있다고 느껴 직접 윤문에 참여했고, 최종 확정본은 다음과 같다:

{ keywords :[ '摸鱼' , '发呆' , '刷手机' , '带薪' , '上厕所' ], category : '전략급 땡땡이' , color : '#ffd23f' , score : 2 , template : ( n,raw )=> `进行<span class="num">深도 전략급</span>정력 회복과 창의적 사고 부화를 진행하여,` + `이후 고강도 산출을 위한 에너지를 축적합니다.<span class="hl">（땡땡이도 품격 있게 써야 한다）</span>` }

경험: AI에게 지시를 내릴 때 "톤 제약"이 "형식 제약"보다 산출물의 질을 더 크게 좌우한다. 형식 제약은 제대로 달렸는지를 결정하고, 톤 제약은 결과물이 쓰기 좋은지를 결정한다.

단계 2: 단일 파일 애플리케이션 전체를 한 번에 생성 (Agent에게 한 번에 밀어붙이기)

규칙 라이브러리를 손에 넣은 뒤, 나는 규칙 + 상호작용 요구사항을 한 번에 Agent에게 주고 전체를 구현하게 했다.

지시의 요지는:

다음 번역 규칙 라이브러리를 기반으로 단일 파일 HTML 인터랙티브 앱을 만들어 줘:

- 사용자가 이번 주 업무 내용을 입력한다(한 줄에 하나, 일상적인 말투 그대로);

- 4개 직무 예시(개발/제품/디자인/운영)를 제공하고, 클릭하면 바로 채워진다;

- "번역"을 누르면 네 가지 블록을 출력한다: 전적 점수 카드, 항목별 번역 결과(원문→번역, 분류 태그와 점수 포함), 자동 조립된 완성 주간보고 단락(이번 주 요약/핵심 데이터/다음 주 계획 포함), 직장 은어 등급 평가;

- 주간보고 전문 원클릭 복사 지원;

- 다크 테마, 모바일 대응;

- 기술 제약: 순수 HTML+CSS+JS 단일 파일, 외부 라이브러리 의존 없음, 오프라인에서 실행 가능.

TRAE는 곧바로 실행 가능한 단일 파일 앱을 만들어 냈다. 이 단계가 내가 느끼기에 완전히 새로운 TRAE의 변화가 가장 뚜렷하게 드러난 지점이었다. 코드 조각 한 무더기를 주고 내가 짜깁기하게 하는 것이 아니라, 바로 열어서 실행되는 결과물을 내놓았다는 점이다. 나는 받은 뒤 검수하고 다듬기만 하면 됐다.

단계 3: IDE 모드로 전환해 시각적 정교화(여기는 반드시 직접 해야 함)

Agent가 준 버전은 기능은 맞았지만 비주얼이 평범했다. 나는 IDE 모드로 전환해 세 군데를 직접 수정했다:

- 숫자 하이라이트: 번역 결과 안의 수량 표현은 청록색, 핵심 결론은 금색으로 처리해 "업무 보고 느낌"이 시각적으로 먼저 자리 잡게 했다;

- 점수 상한을 150으로 설정: 항목이 너무 많아 점수가 폭발하는 것을 막으면서, 동시에 "전설적 전적"이라는 최상위 희소성 감각을 지켰다;

- 다크 테마 통일: Agent가 쓴 여러 가지 뒤섞인 색을 5개의 의미색(분홍=기능, 청록=데이터, 금색=결론, 초록=성공, 빨강=위험)으로 수렴시켰다.

듀얼 모드의 실제 체감: 발산적이고, 반복적이며, 한 번에 끝까지 밀어붙여야 하는 작업은 Agent에게 맡기고, 정밀한 제어가 필요하고 내 명확한 심미안이 필요한 작업은 반드시 IDE로 전환한다. 전환 비용은 거의 제로에 가까웠고, 이 점은 예전에 다른 도구로 왔다 갔다 하던 것보다 훨씬 매끄럽다.

단계 4: "열면 바로 스크린샷 가능한" 데모 상태로 만들기(함정 밟고 수정)

앱을 만든 뒤 아주 실제적인 문제를 만났다: 열면 비어 있다. 먼저 예시를 클릭하고, 다시 번역을 클릭해야만 결과를 볼 수 있었다. 데모와 스크린샷에는 매우 불친절한 구조라, 다른 사람이 첫눈에 보는 것은 빈 입력창이어서 이 도구가 무엇을 할 수 있는지 알 수 없었다.

수정법은 아주 간단했다. 세 줄의 코드로, 페이지가 로드된 뒤 자동으로 예시를 채우고 자동으로 한 번 실행하게 했다:

window . addEventListener ( 'DOMContentLoaded' , () => { document . getElementById ( 'inputBox' ). value = EXAMPLES . dev ; // 개발 직무 예시 자동 채우기 updateCharCount (); setTimeout ( () => translate (), 300 ); // 자동 번역, 곧바로 결과 출력 });

이 함정은 아주 작지만 나는 이것을 강조하고 싶다. 도구를 만드는 것과 작품을 만드는 것은 두 가지 일이다. 도구는 "기능 완전성"을 추구하고, 작품은 "첫눈에 이해되는 것"을 추구한다. 자동 데모 상태는 후자에 속한다. 이 단계는 IDE 모드에서 고쳤는데, 요구 사항이 너무 명확해서 Agent에게 설명하는 것이 오히려 더 느리기 때문이다.

4. 실제 성과: 진짜로 실행되고, 스크린샷이 가능하며, 재사용 가능한 도구

4.1 완성품은 무엇인가

단일 파일 HTML 앱으로, 더블클릭해 열면 바로 쓸 수 있다. 백엔드도 필요 없고, 의존성을 설치할 필요도 없으며, 네트워크 없이도 실행된다. 순수 규칙 엔진이라 어떤 대형 모델 API도 호출하지 않으며 응답도 즉각적이다.

4.2 기능 목록

모듈 구현 효과 번역 규칙 라이브러리 15개 키워드 규칙 + 템플릿 함수 개발/제품/디자인/운영 4개 직무 유형 커버 숫자 지능 추출 정규식 + 중국어 숫자 매핑 "버그 3개 고침"과 "버그 세 개 고침" 모두 인식 키워드 우선순위 매칭 키워드 길이 기준 정렬 후 매칭 "회의에서 방안 최적화"가 "최적화" 규칙으로 오판정되는 것 방지 전적 점수 각 규칙에 점수 배정, 누적 5개 등급, "새내기"부터 "전설"까지 주간보고 자동 조립 분류별 번역 결과 집계 "이번 주 요약 + 핵심 데이터 + 다음 주 계획" 출력 은어 등급 평가 점수 구간 매핑 5급 평가, 각 등급에 자기 비하 코멘트 원클릭 복사 Clipboard API + 폴백 복사한 뒤 바로 주간보고 시스템에 붙여넣기 자동 데모 상태 페이지 로드 시 자동 채우기 및 번역 열면 바로 결과 출력, 데모 스크린샷에 편리

4.3 실제 실행 결과

실행 결과 예시(내가 개발 직무 예시로 실측한 번역 전후 비교):

당신의 원문 번역된 업무 보고 언어 버그 3개 고침 핵심 시스템 안정성 관리 주도, 온라인 핵심 결함 누적 3건 조사·수정, 시스템 장애율 효과적 감소, 비즈니스 연속성 보장 홈페이지 로딩 속도 좀 최적화함 프론트엔드 성능 경험 특화 최적화 주도, 핵심 지표 로딩 소요 시간 약 45% 감소, 핵심 페이지 첫 화면 렌더링이 초 단위 응답 구간 진입 기술 문서 두 부 작성 팀 지식 체계 구축 추진, 기술 규격 문서 및 운영 가이드 2부 축적, 신입 온보딩 비용 감소 신입에게 코드 익히게 함 팀 기술 전승 및 인재 역량 강화 주도, 기술 공유 및 신입 멘토링 1회 완료, 팀 전체 기술 수준 향상 추진 요구사항 관련 회의 5개 함 5차례 크로스팀 협업 및 요구사항 정렬 회의 추진, 정보 격차 효과적 해소, 다자 목표 일치 보장 결제 모듈 리팩터링함 기술 아키텍처 관리 및 부채 상환 추진, 핵심 모듈 리팩터링 1건 완료, 코드 유지보수성 향상, 향후 반복 개발의 기반 마련

4.4 효율 비교(정량)

단계 전통 수작업 이 도구 사용 개선 폭 항목별 표현 고민 항목당 5–10분 즉시(<1초) 약 95% 완성된 주간보고 작성 40분 2분(검토 포함) 약 95% 정량 데이터 포장 수동으로 숫자 지어내기, 자신 없음 템플릿 자동 생성 품질 향상, 더 이상 자신 없어 하지 않음 다직무 전환 직무 유형마다 표현 다시 고민 4개 유형 예시 원클릭 전환 30분에서 0으로

핵심 결론: 1회 주간보고 작성이 40분에서 2분으로 단축되어 효율이 약 95% 향상됐다. 1년을 48주로 계산하면 한 사람이 1년에 약 30시간을 아낄 수 있으며, 아끼는 것은 가장 심력을 소모하는 그 부분이다.

4.5 덤으로 TRAE의 두 가지 플랫폼 역량 활용

듀얼 모드 외에도 새로운 역량 두 가지를 썼는데, 모두 자연스럽게 활용한 것이지 억지로 끼워 넣은 것이 아니다:

- 내 산출물 통합 관리: 이번 개발 산출물은 매우 잡다했다. 데모의 HTML, 규칙 라이브러리 코드, 여러 버전의 디자인 시안 스크린샷, 그리고 앞으로 쓸 글까지. 이들을 한곳에 모아 두니 나중에 "그 딴짓 이스터에그 들어간 규칙 라이브러리 버전"을 찾을 때 채팅 기록을 뒤질 필요 없이 바로 찾을 수 있었다.

- 템플릿 라이브러리로 시작: 이 도구는 순수 프론트엔드 단일 파일이고 구조적으로 정해진 패턴이 있다(입력 영역 → 트리거 버튼 → 결과 분할 영역 → 복사 내보내기). 나는 뼈대를 맨바닥에서 세우지 않고 비슷한 단일 페이지 앱 템플릿을 가져와 시작했으며, 주요 정력을 규칙 엔진과 콘텐츠에 쏟았다. 진짜 가치 있는 부분은 규칙 라이브러리와 톤이지 스캐폴딩이 아니다.

5. 함정 리스트(이 네 가지가 기능 목록보다 더 유용하다)

함정 1: 첫 번째 버전의 방안 선택이 틀려서 한 바퀴 헛수고했다. 나는 처음에 '끼인각 직장인 진단기'를 만들었는데, 재미있긴 했지만 쓸모는 없었다. 교훈: 공모전/효율화류 프로젝트라면 먼저 세 가지 질문을 던져야 한다——이것은 실제로 존재하는가? 고빈도인가? 아픈가? 셋 다 '예'일 때만 착수하라.

함정 2: 지시에 톤 제약을 주지 않아서 산출물이 전부 관공서식 상투어가 됐다. "나를 위해 번역 규칙을 설계해줘"와 "나를 위해 번역 규칙을 설계해줘, 유머는 있되 선을 넘지 않고, 보는 사람이 피식 웃게 만들어줘"는 산출물의 차원이 다르다. 전자는 "업무 추진 효율 향상"을 주고, 후자는 "심층 전략급 정력 회복 및 창의적 사고 부화"를 준다.

함정 3: 폴백 로직을 만들지 않아서, 입력이 규칙에 걸리지 않으면 공백이 출력됐다. 15개 규칙으로는 모든 입력을 커버할 수 없다. 나는 기본 규칙을 하나 추가했다: 매칭되는 것이 없으면 "일상 업무 작업 N건의 실행과 착지를 추진하여 업무 운영과 팀 협업의 원활함을 보장"을 출력한다. 폴백은 선택 사항이 아니라 필수 사항이다.

함정 4: 여러 키워드가 동시에 걸리면 오판이 발생한다. "회의를 열어 최적화 방안을 논의하는 회의"를 입력하면 "회의"와 "최적화"에 동시에 걸린다. 수정 방식은 매칭 전에 키워드 길이순으로 정렬하여 더 구체적인 키워드가 우선 매칭되게 하는 것이다——이 단어 순서 수정은 현상을 설명해서 Agent에 주고 스스로 고치게 했는데, 내가 직접 디버깅하는 것보다 빨랐다.

6. 재사용 가능한 방법론 (세 장의 템플릿 카드, 단어만 바꾸면 바로 쓸 수 있다)

템플릿 카드 1: 규칙 엔진 설계 (모든 "입력→번역/변환"류 도구에 적용 가능)

나는 {도구 이름}을 만들려고 하는데, 핵심은 {입력 유형}을 {출력 유형}으로 번역하는 것이다. 나를 위해 번역 규칙 라이브러리 설계를 도와줘: 1. {N}개의 흔한 시나리오를 커버: {시나리오 목록} 2. 각 규칙은 다음을 포함: 트리거 키워드(복수), 번역 템플릿({변수} 자리표시자 포함), 분류 태그, 점수 가중치 3. 번역 톤: {유머는 있되 선을 넘지 않게 / 엄숙하고 전문적으로 / 활발하고 유머러스하게} 4. 코드로 바로 변환 가능한 구조화 형식으로 출력

그대로 응용한 사례: 이력서 최적화기(일상어 경험→전문적인 이력서 언어), 이메일 다듬기(구어→비즈니스 정식 문어), 계약서 번역기(일상 표현→법률 조항 언어).

템플릿 카드 2: 키워드 매칭 + 숫자 추출 코드 패턴

// 키워드 우선 매칭: 키워드가 더 긴 규칙을 우선하여 오작동을 방지 function matchRule ( text ){ const rules = [... RULES ]. sort ( ( a,b )=> Math . max (...a. keywords . map ( k => k. length )) - Math . max (...b. keywords . map ( k => k. length )) ); for ( const rule of rules) for ( const kw of rule. keywords ) if (text. toLowerCase (). includes (kw. toLowerCase ())) return rule; return null ; // 매칭 없음 → 폴백으로 이동 } // 숫자 추출: 아라비아 숫자 + 중국어 숫자 모두 지원 function extractNumber ( text ){ const m = text. match ( /(\d+)/ ); if (m) return parseInt (m[ 1 ]); const cn = { '一' : 1 , '二' : 2 , '两' : 2 , '三' : 3 , '四' : 4 , '五' : 5 , '六' : 6 , '七' : 7 , '八' : 8 , '九' : 9 , '十' : 10 }; for ( const [k,v] of Object . entries (cn)) if (text. includes (k)) return v; return null ; // null이면 템플릿에서 기본값 사용 }

템플릿 카드 3: 인터랙티브 도구의 '의식感' 흐름

1. 입력 영역: 예시 태그를 제공 → 사용 문턱 낮추기 2. 원클릭 실행: 버튼 하나로 전체 처리를 완료 3. 점수 카드: 큰 숫자 + 등급 → 임팩트 연출 4. 항목별 결과: 원문과 번역을 나란히 → 신뢰도 구축 5. 출력 조립: 흩어진 결과를 바로 전달 가능한 문서로 조합 6. 원클릭 복사: '사용하기'의 마지막 문턱 제거 7. 자기 비하 등급: 사람들이 캡처해 공유하고 싶게 만드는 이스터에그 남기기

새로운 TRAE로 이번 주의 주간보고 도구를 0에서 사용 가능한 수준까지 끌어올리고, 가장 솔직한 소감 몇 가지를 말해보겠다.

가장 뚜렷한 변화는 "AI가 더 똑똑해졌다"가 아니라 "이제 납품할 수 있게 됐다"이다. 예전에 AI 프로그래밍을 쓸 때는 조각더미를 받아서 내가 직접 이어 붙여야 했는데, 이번에는 Agent 모드에 요구사항 한 덩어리(규칙 라이브러리 + 인터랙션 흐름 + 기술 제약)를 던졌더니 열자마자 바로 실행되는 단일 파일 애플리케이션을 곧장 돌려줬고, 내 일은 "코드 작성"에서 "검수 + 정밀 수정"으로 바뀌었다. 이 심리적 낙차가 꽤 컸다——아낀 것은 키보드 두드리는 시간이 아니라 "한 가지 일을 끝까지 밀어붙이지 못한다"는 그런 피로감이다.

두 번째 소감은 이중 모드의 분업이 정말로 성립했다는 점이다. 나의 실제 사용법은 아주 소박하다: 발산적이고 반복적이며 한 번에 밀어붙여야 하는 일은 Agent에게 던지고(번역 규칙 라이브러리 설계, 프런트엔드 전체 구현, 경계 버그 위치 파악); 정밀한 통제가 필요하고 내 머릿속에 명확한 답이 있는 일은 IDE로 돌아가 수동으로 고친다(색상 의미, 점수 상한, "열면 바로 데모" 그 세 줄). 전환 비용은 거의 0이라, 예전에 도구 사이를 오가던 것보다 훨씬 편했다.

세 번째는 의외의 수확: 산출물 통합 관리가 나를 살렸다. 이번 산출물은 유난히 잡다했다——HTML, 규칙 라이브러리 코드, 여러 버전의 스크린샷, 그리고 써야 할 원고까지. 한곳에 모아두니 더 이상 채팅 기록을 뒤져 "그 딴짓 이스터에그 들어간 규칙 라이브러리 버전"을 찾지 않고 바로 위치를 특정할 수 있게 됐다. 이 "물건이 다 있다"는 든든함이 어떤 단일 기능보다도 실용적이었다.

정리

주간보고라는 일은 기술적 난이도는 높지 않지만, 심력을 극도로 소모한다. 주 1회, 전사로 합치면 거대한 시간 블랙홀이다.

내가 이 도구를 만든 것은 사람들에게 허풍을 가르치기 위해서가 아니다. 이 도구가 섬기는 것은 "일은 잘했는데 말로 꺼내지 못하는" 사람들이다——당신의 일은 보여질 가치가 있고, 당신에게는 번역기 하나가 부족할 뿐이다.

혼자 일할 때 가장 두려운 것은 만들어내지 못하는 것이 아니라, 생각이 명확하지 않은 것이다. 이번에 느낀 점은: Agent 모드는 내가 '생각하는' 부분을 빠르게 펼쳐서 검수 가능한 것으로 만들어 주고, IDE 모드는 핵심 지점에서 정밀한 통제권을 유지하게 해주며, 둘을 오가면 혼자서도 하나의 체인을 끝까지 돌릴 수 있다는 것이다.

박수 MVP

프로그래머

23

글

9.9k

읽음

3

팬