목차06
수정
AI에게 전문가의 역할을 주면 대답의 분위기가 달라진다.
분석할 항목을 나누고, 익숙한 용어를 쓰고, 단정하게 결론을 낸다. 처음에는 내가 혼자 생각할 때보다 훨씬 잘 정리된 것처럼 느껴진다.
그런데 그 대답을 실제 작업에 적용하려 하면 비어 있는 부분이 보인다.
무엇부터 해야 하는지. 어느 조건에서는 다른 선택을 해야 하는지. 무엇을 확인한 뒤에 끝났다고 할 수 있는지.
역할을 주는 것으로 시작할 수는 있었다. 하지만 역할만으로 내가 원하는 기준까지 전달되지는 않았다.
1. ‘전문가’라는 말 안에는 빈칸이 많다
전략을 잘 짜는 사람처럼 해달라고 말해도, 어떤 회사의 어떤 문제를 다루는지는 따로 알려줘야 한다.
디자인을 잘하는 사람처럼 해달라고 말해도, 어떤 사용자가 무엇을 해야 하는지는 남아 있다.
내가 원하는 것은 전문적으로 들리는 설명이 아니라 실제 결과였다.
그래서 추상적인 역할 대신, 참고할 만한 결과물을 먼저 놓고 싶었다. 제품의 흐름, 실제 문서, 코드와 실행 예시를 보며 어떤 기준이 필요한지 찾으려 했다.
2. 원본에서 관찰할 것을 정한다
좋은 결과물 하나를 통째로 닮게 만들려 하면 무엇을 가져왔는지 알기 어렵다.
먼저 이번 작업에서 볼 부분을 정하는 편이 낫다.
글이라면 도입에서 어떤 질문을 만들고, 경험에서 설명으로 어떻게 넘어가는지 볼 수 있다. 제품이라면 첫 행동과 결과를 받는 순서, 실패했을 때의 안내를 볼 수 있다. 문서라면 읽는 사람이 무엇을 먼저 알아야 하는지 살펴볼 수 있다.
원본에 드러나지 않은 이유까지 마음대로 설명하지는 않는다.
‘이 위치에 버튼이 있다’는 관찰과 ‘전환율을 높이려고 여기에 뒀다’는 해석은 다르다. 제작자의 설명이나 측정 자료가 없다면 후자는 가정으로 남겨야 한다.
3. 닮아야 할 것과 지켜야 할 것을 나눈다
내 문체로 글을 쓰게 한다면 호흡과 질문의 흐름을 참고하게 할 수 있다.
하지만 내 경험이 아닌 사건을 새로 만들어 ‘나도 그랬다’고 쓰게 해서는 안 된다. 문체가 닮을수록 오히려 꾸며낸 경험도 자연스럽게 읽힐 수 있다.
제품에서도 비슷하다.
좋은 온보딩의 질문 순서는 참고할 수 있지만, 다른 서비스가 가진 데이터와 성능을 내 제품에도 있는 것처럼 가져올 수는 없다. 화면의 구조와 실제 가능한 기능은 따로 확인해야 한다.
따라 할 대상을 정하는 것만큼, 따라 하지 말아야 할 경계도 필요했다.
대상은 문장의 호흡과 질문의 흐름. 사실과 경험은 별도로 확인한다.
- 원본에서 볼 부분
- 도입의 질문과 경험에서 설명으로 넘어가는 방식을 살핀다.
- 내 글에 옮길 조건
- 제공된 경험과 자료 안에서 호흡과 질문의 흐름을 참고한다.
- 만들지 않을 내용
- 제공되지 않은 사건을 내가 겪은 일처럼 채우지 않는다.
- 결과에서 확인할 것
- 말투가 닮았는지에 앞서 이번 요청을 충족하고 사실을 지켰는지 본다.
4. 분석한 것을 지침으로 옮긴다
나는 참고자료를 보여준 뒤 ‘느낌을 살려줘’로 끝내지 않으려 한다.
이번 작업에 무엇을 넣고, 무엇은 넣지 않을지 적는다. 좋은 결과가 어떤 모습인지 예시를 만들고, 수정해야 할 결과와 비교한다.
간단하게 사용한다면 다음처럼 요청할 수 있다.
만들 결과물: {이번 작업}
사용할 수 있는 사실과 자료: {확인된 내용}
참고할 원본: {직접 제공한 자료 또는 확인 가능한 링크}
원본에서 이번 작업에 필요한 구조만 관찰해라.
확인한 사실과 추정한 제작 의도를 나눠라.
내 조건에 맞춰 유지할 것, 바꿀 것, 버릴 것을 정리해라.
그 결과를 다음 작업자가 실행할 수 있는 지침으로 바꿔라.
필수 요소, 제외할 요소, 좋은 예시, 확인 방법을 포함해라.
그 지침에 따라 결과물을 만든 뒤,
참고자료와 얼마나 비슷한지보다 이번 요청을 충족했는지 확인해라.
제공되지 않은 경험과 성능은 만들지 마라.중요한 것은 마지막이다.
원본과 비슷해졌는데 내 문제를 해결하지 못했다면 잘된 작업이라고 보기 어렵다.
5. 가져오는 데에도 조건이 있다
참고할 수 있다고 마음대로 복사해도 되는 것은 아니다.
원본의 고유한 문장과 이미지, 브랜드 요소, 코드에는 각각 사용 조건이 있을 수 있다. 내 작업에 필요한 것이 구조인지 실제 파일인지 구분하고, 파일을 재사용하려면 해당 권한과 라이선스를 확인해야 한다.
내가 작성한 글을 다시 쓰는 경우와 다른 사람의 작업물을 가져오는 경우도 같지 않다.
좋은 것을 배운다는 설명으로 이 차이를 넘어가고 싶지는 않다. 무엇을 참고했고 무엇을 직접 바꿨는지 남겨두는 편이 다음 작업에도 도움이 된다.
모든 작업에 긴 분석을 붙이지는 않는다
아주 구체적인 요청이라면 바로 만들고 확인하는 편이 나을 수 있다. 원본을 더 넣을수록 좋은 결과가 나온다고 생각하지는 않는다.
나와 맞지 않는 기준이 들어오면 오히려 방향이 흐려질 수도 있다.
내가 이 방식을 사용하고 싶은 때는 분명하다. 좋은 결과를 알아보지만 설명이 부족할 때, 모델의 일반적인 답이 내 상황에 맞지 않을 때, 무엇을 기준으로 검토해야 할지 불분명할 때다.
그때 원본은 답안지가 아니라 공부할 재료가 된다.
나는 전문가라는 이름을 붙이는 것보다, 그 사람이 실제로 무엇을 했는지 알고 싶었다.
그리고 그것을 내 작업에 가져온 뒤에는 내가 왜 그렇게 바꿨는지 설명할 수 있었으면 했다.