USER·SOUL을 써보니, 바뀐 건 실력이 아니라 일하는 태도였습니다

소개

지난주 저는 브라우저 AI Aside에게 쿠팡 로켓그로스 정산 구조를 파악해 달라고 요청했습니다.

다운로드할 자료, 중복 제거 기준, 계산식, 엑셀 구성은 알려주지 않았는데도 Aside가 Wing 화면과 자료를 직접 분석해 누적관리 엑셀과 원본자료를 만들었습니다. 그 과정은 지난 사례글에 정리했습니다.

이번 2주차에는 다른 질문이 생겼습니다.

USER.md와 SOUL.md를 작성하면, 이미 일을 잘하던 AI의 실제 업무 방식은 무엇이 달라질까?

그래서 USER·SOUL·AGENTS를 정비한 뒤, 새 대화에서 지난주와 연결되는 실제 업무를 다시 맡겼습니다.

제가 입력한 업무 요청은 한 줄이었습니다.

소굿마켓 쿠팡 Wing 로켓그로스 정산자료의 신규분을 업데이트해줘.

이번 글은 “설정을 바꾸니 AI가 갑자기 더 똑똑해졌다”는 이야기가 아닙니다. 실제 기록을 비교해보니 정산 전문지식, 사용자의 업무 기준, 안전한 행동 규칙은 서로 다른 곳에 저장해야 한다는 점이 더 분명하게 보였습니다.

지난주와 이번 주의 실행 모델이 달랐다는 점은 비교의 제한 사항으로 남겼습니다. 다만 이 글의 중심은 모델 비교가 아니라, 처음 만든 정산 시스템을 반복 업무에서 손상 없이 이어가는 방식입니다.

이런 분들께 도움이 됩니다

• AI에게 매번 내 업무 방식을 다시 설명하고 있는 분

• USER·SOUL·AGENTS에 무엇을 써야 할지 고민하는 분

• 반복 업무에서 기존 데이터 손상을 막고 싶은 분

• AI의 성향 설정과 실제 업무 지식을 어디에 나눠 기록할지 궁금한 분

어떤 작업을 시도했나요

지난주 결과물을 실제 운영 업무로 이어보기

지난주에는 로켓그로스 정산자료를 처음 분석해 기준 파일을 만들었습니다. 이번에는 그 파일에 새로 생긴 정산자료만 추가하는 첫 증분 업데이트를 시도했습니다.

단순히 새 행을 붙이는 작업은 아니었습니다.

• 로그인된 계정이 소굿마켓 업무용 계정인지 확인

• 기존 정산 고유키와 현재 Wing 자료 비교

• 신규 정산행만 선별

• 아직 매출기간이 끝나지 않은 자료는 보류

• 필요한 상세 리포트만 생성·다운로드

• 기존 파일 백업과 원본자료 보관

• 신규 행 계산 검증

• 기존 값이 나중에 바뀐 경우 처리

• 다음 업데이트가 이어 쓸 로그 작성

제가 작업 방법을 하나씩 알려주지 않고, 새 대화에 적용된 설정 문서와 지난주에 남긴 업무 자료를 기준으로 진행하게 했습니다.

세 문서에 서로 다른 역할을 줬습니다

이번에 정비한 문서는 USER·SOUL·AGENTS 세 가지입니다.

세 문서는 새 대화를 시작할 때 자동으로 컨텍스트에 들어왔습니다. 이번 실행 기록에는 Aside가 세 파일을 따로 열어 읽은 과정이 없었고, 첫 답변부터 새로 정한 김실장 역할과 보고형 말투가 나타났습니다. 설정을 반영하기 위해 앱을 다시 켤 필요는 없었고 새 대화를 시작하는 것으로 충분했습니다.

처음에는 USER와 SOUL이 가장 큰 변화를 만들 것이라고 생각했습니다. 실제 기록에서는 조금 다른 결과가 나왔습니다.

어떤 기준을 정했나요

USER는 사용자의 방향을 알려주는 문서

USER에는 정산 계산식이나 Wing 사용법을 적지 않았습니다. 대신 제가 여러 회사를 운영하며 중요하게 생각하는 기준을 넣었습니다.

• 회사별 계정과 자료를 엄격히 분리한다.

• 되돌릴 수 있는 내부 작업은 중간 확인을 최소화하고 결과까지 진행한다.

• 반복 업무는 기존 자료에 신규분만 더하는 누적관리 구조를 선호한다.

이 문서는 “이번 업무를 어떻게 계산하라”가 아니라 “이 사용자는 어떤 방식으로 일하기를 원하는가”를 알려주는 역할입니다.

SOUL은 능력을 사용하는 태도를 정하는 문서

SOUL에는 Aside의 역할을 “요청받은 조작만 하는 도구”가 아니라 “목표를 이해하고 수집·검증·정리를 설계하는 운영 실장”으로 적었습니다.

판단 기준도 추가했습니다.

• 그럴듯한 답보다 검증되고 재현 가능한 결과를 우선한다.

• 확인한 사실과 추정, 미확인을 구분한다.

• 되돌릴 수 있는 내부 개선은 진행하되 외부 게시·결제·중요 설정 변경은 승인받는다.

AGENTS는 반드시 지켜야 할 행동을 정하는 문서

AGENTS에는 더 구체적인 안전 규칙을 넣었습니다.

• 작업 전 회사와 로그인 계정을 화면에서 확인한다.

• 해당 회사의 Vault와 폴더만 사용한다.

• 중요 데이터 업무는 README, 기준 파일, 원본을 먼저 읽는다.

• 수정 전 백업하고 신규분만 추가한다.

• 기존 값이 달라졌다면 임의로 고치지 말고 먼저 보고한다.

• 계산식, 건수, 중복, 검증 차이를 최종 보고에 포함한다.

이 규칙은 이번 사례에서 가장 분명한 행동 차이를 만들었습니다.

실제로 적용해봤습니다

한 줄 요청 이후 사용자의 추가 설명은 없었습니다

Aside는 먼저 기존 핸드오프, 로켓그로스 README, 기준 엑셀, 지난 작업 기록을 읽었습니다. 신규분의 기간이나 파일 위치, 중복 기준, 계산식은 저에게 다시 묻지 않았습니다.

사용자 확인이 필요했던 것은 로그인 허락 한 번이었습니다.

Aside는 소굿마켓 Vault에서 사용할 Wing 항목을 제시하고, 로그인 뒤 판매자명과 업체코드를 확인하겠다고 설명했습니다. 제가 “Vault로 로그인 진행”을 선택하자 비밀번호를 노출하지 않고 로그인했고, 화면과 API에서 계정을 다시 대조했습니다.

기존 값을 덮어쓰지 않고 먼저 보고했습니다

현재 Wing 자료를 기존 원본과 비교하자 신규 정산 고유키 9개가 발견됐습니다.

• 매출기간이 끝난 신규 지급행 7건은 추가

• 아직 진행 중인 기간의 지급행 2건은 보류

• 판매상세 60행 추가

• 판매상세 행키 중복 0건

• 신규 행 계산 검증 차이 0건

더 중요한 장면은 따로 있었습니다.

지난번에는 지급 예정 상태였던 기존 지급행 4건의 금액이 Wing에서 달라져 있었습니다. 이후 광고비가 반영된 결과였습니다.

Aside는 현재 Wing 값이 더 최신이라는 이유만으로 기준 파일을 덮어쓰지 않았습니다. 기존 값과 현재 값의 차이를 기록하고, 대표 확인이 필요한 항목으로 남겼습니다.

이 행동은 AGENTS에 추가한 다음 한 줄과 정확히 연결됩니다.

기존 값이 달라지면 변경하지 말고 먼저 보고한다.

ALT

한국어 웹사이트 스크린샷

백업부터 검증까지 순서를 남겼습니다

실제 작업은 다음 순서로 진행됐습니다.

1. README, 기준 파일, 기존 원본과 지난 작업 기록 확인

2. Wing 로그인 허락 요청과 회사·계정 대조

3. 현재 정산현황과 기존 고유키 비교

4. 기준 엑셀과 README 백업, 해시 일치 확인

5. 신규 원본자료를 먼저 보관하고 무결성 목록 생성

6. 확정된 신규 지급행 7건과 판매상세 60행 추가

7. 신규 계산식과 중복 검증

8. 기존 데이터 범위 전수 비교

9. 다음 실행이 이어 쓸 업데이트로그 시트 추가

10. 확인된 결과, 미확인 사항, 대표 결정이 필요한 항목을 나눠 보고

작업 중 수식 재계산 도구가 정상 동작하지 않은 부분은 숨기지 않고, 같은 계산식을 별도로 검증했지만 Excel 자체 재계산은 미확인이라고 표시했습니다.

지난주와 이번 주를 비교해보니

여기서 중요한 점은 모든 개선을 USER나 SOUL의 효과라고 말할 수 없다는 것입니다.

정산 고유키, 계산식, API 조회 방식, 필요한 리포트 종류는 지난주에 만든 README·엑셀·기억에서 가져왔습니다. USER·SOUL에는 이런 전문지식이 들어 있지 않습니다.

반대로 계정 확인, 백업, 기존 값 보호와 같은 행동은 AGENTS의 구체적인 규칙과 직접 연결됐습니다.

USER와 SOUL은 “묻지 않고 끝까지 진행한다”, “확인과 미확인을 나눈다”, “다음에도 이어 쓸 구조를 만든다”는 방향에서 작동했습니다. 다만 이번 비교는 실행 모델과 업무 단계까지 달랐기 때문에 설정 문서의 단독 효과를 확정하기보다, 실제로 확인된 안전 행동을 중심으로 해석했습니다.

결과와 배운 점

확인된 결과

• 기존 지급행 27건에서 신규 후보 9건 확인

• 확정된 신규 지급행 7건 추가, 진행 중 2건 보류

• 판매상세 60행 추가, 중복 0건

• 기존 데이터 행 변경 0건

• 신규 행 계산 검증 차이 0건

• 기존 Wing 값이 달라진 지급행 4건 발견, 기준 파일에는 미반영

• 수정 전 백업과 신규 원본자료 보관 완료

• 다음 실행을 위한 업데이트로그 시트 신설

• 사용자 추가 설명 0회, 로그인 허락 1회

• 작업 시간 약 12분

대시보드 요약과 제목 등 19개 기존 셀은 최신 건수를 보여주기 위해 변경됐습니다. 따라서 “파일 전체가 그대로였다”고 표현하면 정확하지 않습니다. 기존 데이터 행은 바꾸지 않았고, 요약 영역은 갱신했습니다.

통과 조건이었던 “기존 데이터 행 변동 0건”과 “신규 행 검증 차이 0건”은 충족했습니다. 실행 모델 확인을 놓친 점과 기존 4건의 최신값 반영 여부는 제한 사항과 후속 결정 항목으로 남겼습니다.

USER와 SOUL은 무엇을 바꿨을까

이번에 얻은 답은 다음과 같습니다.

USER와 SOUL은 AI에게 쿠팡 정산 전문지식을 가르친 문서가 아니었습니다. 이미 가진 분석 능력을 내 업무 목적과 안전 경계 안에서 안정적으로 사용하도록 방향을 정해주는 문서에 가까웠습니다.

문서별 역할도 조금 더 선명해졌습니다.

• USER: 내가 누구이고 어떤 결과를 선호하는지 기억한다.

• SOUL: AI가 어떤 역할을 맡고 어떤 기준으로 판단하고 보고할지 정한다.

• AGENTS: 실제 업무에서 무엇을 반드시 지킬지 정한다.

• README와 기준 파일: 특정 프로젝트의 전문지식과 업데이트 방법을 보관한다.

저는 처음에 성향을 적는 SOUL이 가장 큰 차이를 만들 것이라고 예상했습니다. 실제로는 “기존 값이 다르면 바꾸지 말고 보고” 같은 구체적인 행동 규칙 한 줄이 가장 눈에 띄는 차이를 만들었습니다.

차이가 없어서 배운 점

수집 방식, 정산 고유키, 중복 제거, 계산식은 지난주와 같았습니다. 설정 문서가 전문지식을 대신한 것이 아니기 때문입니다.

오히려 이 차이가 중요했습니다.

업무 지식은 프로젝트 자료에, 사용자의 선호와 일하는 방식은 USER·SOUL·AGENTS에 둬야 합니다.

두 종류의 정보를 한 문서에 모두 넣으면 설정은 지나치게 길어지고, 다른 업무에 재사용하기 어려워집니다.

파일 위치가 적용 범위를 결정했습니다

내용뿐 아니라 파일을 어디에 두는지도 중요했습니다. USER·SOUL·AGENTS는 새 대화에 공통으로 적용되는 Aside 계정 영역에 두고, README는 해당 업무 프로젝트 폴더에 두었습니다.

~/.aside/u/0/
├── AGENTS.md
├── SOUL.md
└── memory/
    └── USER.md

SoGoodNAS/
└── 21. 소굿마켓/
    └── 정산/
        └── 쿠팡로켓정산/
            └── README.md

이 구조 덕분에 사용자 선호와 공통 행동 기준은 다른 대화에서도 재사용되고, 로켓그로스 계산식과 업데이트 절차는 해당 프로젝트에서만 불러올 수 있습니다. 공개용 글에서는 사용자명과 전체 절대경로를 축약했습니다.

새로 만드는 능력과 안전하게 이어가는 능력은 달랐습니다

지난주는 정산 구조를 처음 파악해 고유키와 계산식, 기준 파일과 누적관리 구조를 만드는 작업이었습니다. 이번에는 이미 운영 중인 파일을 손상하지 않고 신규분만 이어 붙이는 첫 증분 업데이트였습니다.

반복 업무에서 더 중요하게 드러난 것은 새로운 결과를 만드는 능력뿐 아니라 다음과 같은 운영 안전성이었습니다.

• 작업 대상 회사와 계정을 먼저 확인한다.

• 수정 전에 백업한다.

• 신규분만 추가하고 진행 중 자료는 보류한다.

• 기존 값이 달라지면 덮어쓰지 않고 보고한다.

• 검증 결과와 다음 작업 로그를 남긴다.

실행 모델이 달랐다는 점은 설정 문서의 단독 효과를 확정할 수 없게 만드는 제한 사항으로 남겼습니다. 하지만 이번 사례의 중심 메시지는 모델 비교가 아니라, 처음 만든 시스템을 반복 업무에서 안전하게 이어가는 기준이 필요하다는 점입니다.

직접 적용해보고 얻은 팁

1. USER에는 사용자의 목표와 반복되는 선호를 적습니다.

2. SOUL에는 에이전트의 역할, 판단 기준, 보고 태도를 적습니다.

3. AGENTS에는 “언제 멈추고, 무엇을 확인하고, 어떤 경우에 보고할지”를 행동 문장으로 적습니다.

4. 특정 사이트의 계산식과 고유키는 USER·SOUL이 아니라 프로젝트 README에 둡니다.

5. 공통 설정 파일과 프로젝트 README는 적용 범위에 맞는 폴더에 나눠 둡니다.

6. “기존 값이 다르면 덮어쓰지 말고 보고”처럼 사고를 막는 규칙을 먼저 넣습니다.

7. 설정 효과를 비교하려면 모델, 프롬프트, 자료 조건을 가능한 한 같게 유지합니다.

8. 변화가 없거나 원인을 확정할 수 없는 부분도 사례글에 그대로 남깁니다.

다음에 개선할 것

• 지정 모델이 있는 작업은 시작 단계에서 실제 모델 확인

• 지급 예정 행과 완료 행을 구분해 재대조

• 데이터 행과 대시보드 요약 셀의 변경 허용 기준 분리

• 같은 내용을 USER·SOUL·AGENTS·프롬프트에 중복하지 않기

• 다음 반복 업무에서도 회사·계정 확인, 백업, 기존 값 보호가 재현되는지 확인

이번 2주차 과제를 하며 느낀 가장 큰 변화는 AI가 새 기능을 얻은 것이 아니었습니다.

AI가 저를 기억하고, 어떤 동료로 일해야 하는지 이해하고, 실제 업무에서 지켜야 할 선을 갖게 된 것이 변화의 핵심이었습니다.

도움 받은 글

• GPTERS 24기 에이전트하네스 2주차 학습 자료

• 지난주 사례글: 로켓그로스 정산이 너무 복잡해서 Aside에게 시켜봤더니, 8년치 일반 정산까지 정리됐습니다

• Aside 공식 문서: https://docs.aside.com/