2026. 8. 27. 07:50ㆍpxd AI툴 이야기
UX 디자이너로서 화면 설계서를 작업해 본 분이라면 아실 겁니다. 화면을 그리는 일은 그래도 할 만합니다. 손이 가긴 해도 눈에 보이는 결과가 쌓이니까요. 문제는 그 옆에 붙는 디스크립션입니다.
버튼 하나에 번호를 매기고, 번호마다 “이건 무슨 버튼이고, 누르면 어떻게 되고, 어떤 조건에서 비활성화되는가”를 한 줄씩 적어 내려갑니다. 화면 하나에 요소가 스무 개면 스무 번. 화면이 쉰 장이면… 세는 것도 일입니다. 게다가 초벌을 넘겼다고 끝이 아닙니다. 개발을 하면서, 정책과 화면이 바뀔 때마다 몇 주에서 몇 달을 고칩니다. 이 팔로업이 사실 규격서 작업에서 가장 오래 걸리는 일입니다.
그러다 문득 궁금해졌습니다. 이 반복 작업의 절반 이상을 AI가 대신해 줄 수 있지 않을까요?
그래서 만들기 시작했습니다. 이름은 SpecSaver입니다. 스펙 쓰는 시간을 세이브하겠다는 포부를 담았지요. Figma로 작업된 화면 설계서 내의 Key screen을 분석해, 각 화면의 디스크립션을 자동으로 생성해 주는 플러그인입니다. 실제로 써 보면 체감이 꽤 큽니다. 화면 한 장의 디스크립션 초안을 손으로 쓰면 보통 30분에서 1시간은 잡아야 하는데, SpecSaver로 초안을 뽑고 검토, 보완까지 마치면 10분 안팎으로 줄어듭니다. 물론 화면 복잡도와 검토 꼼꼼함에 따라 편차는 있습니다. 중요한 건 0에서 문장을 쥐어짜는 시간이, 이미 있는 초안을 다듬는 시간으로 바뀐다는 점입니다.
만들면서 기준으로 삼은 건 하나였습니다. 기획자가 실제로 일하는 방식에서 출발하자. 없던 일을 새로 시키는 도구가 아니라, 이미 하고 있는 일을 덜어주는 도구여야 한다고 봤습니다.
그려진 화면을 이미지로 봅니다
사실 SpecSaver의 첫 버전은 화면을 지금과 다른 방식으로 읽었습니다. 선택한 화면의 레이어 구조를 읽었습니다. Figma 파일 안에는 화면을 이루는 레이어들이 이름표를 달고 트리로 쌓여 있는데, 그 트리를 훑어 “여기는 버튼, 저기는 입력창”을 찾아내는 방식이었죠. 텍스트와 좌표를 정확히 가져올 수 있어서 나쁘지 않았습니다.
문제는 이 방식이 디자이너 또는 기획자가 레이어를 얼마나 깔끔하게 정리했는지에 통째로 의존한다는 것이었습니다. 현실의 Figma 파일은 그렇게 단정하지 않습니다. 레이어 이름이 ‘Frame 42085672169’로 남아 있는 경우가 태반이고, 눈으로 보면 분명히 하나의 ‘검색 영역’인데 레이어 구조상으로는 뿔뿔이 흩어져 있기도 합니다. 그러면 도구는 “여기가 한 덩어리다”를 알아채지 못하고 엉뚱하게 쪼개거나 놓칩니다.
여기서 선택지가 갈렸습니다. 실무자에게 “도구가 잘 읽게 레이어를 깔끔하게 정리해 주세요”라고 요구할 것인가? 저는 그건 순서가 틀렸다고 봤습니다. 도구가 사람의 작업 방식에 맞춰야지, 사람이 도구에 맞춰 없던 일을 더 하게 만들면 안 되니까요.
그래서 SpecSaver 2는 읽는 방식을 바꿨습니다. 레이어 트리 대신, 다 그려진 화면을 이미지 자체로 인식할 수 있게 했습니다. 사람이 화면을 눈으로 훑으며, 이건 로그인 버튼, 저건 체크 박스… 이렇게 인식하듯이요. 이렇게 하니 레이어가 정리돼 있든 엉망이든 상관없이, 시각적으로 묶인 영역을 사람과 비슷하게 인식했습니다. 화면을 이미지로 이해하는 멀티모달(비전) 모델이 쓸 만해지면서 가능해진 전환입니다. 물론 더 비싸고 느리지만요.
AI가 펼쳐놓고, 사람이 완성합니다
아주 흔한 화면 하나를 예로 들어 보겠습니다. 아이디 입력창, 비밀번호 입력창, 자동 로그인 체크박스, 로그인 버튼, 비밀번호 찾기, 회원가입 링크가 있는 평범한 로그인 화면입니다. 이 화면을 넘겼을 때 SpecSaver가 하는 일을 네 단계로 나눠 보겠습니다.
1단계. SpecSaver가 화면을 통째로 봅니다
SpecSaver는 선택한 프레임 전체를 한 번에 보고 구조를 분석합니다. 그리고 화면 위의 요소들을 찾아 정해진 규칙대로 번호를 매기고, 유형을 판단합니다.
이렇게 정리된 번호는 버튼 한 번만 클릭하면 캔버스에 배지로 얹힙니다. 디스크립션을 쓰기 위해 손으로 하나하나 번호 배지를 찍어 본 분이라면, 이것만으로도 절반은 왔다는 느낌이 들 겁니다.
2단계. 사람이 한 번 봅니다
여기서 바로 디스크립션으로 넘어가지 않습니다. AI가 뽑은 구조를 사람이 먼저 검토합니다.
번호 순서가 마음에 안 들면 바꿉니다. 로그인 버튼을 자동 로그인 체크박스보다 먼저 설명하고 싶다면 리스트를 끌어 순서를 조정하면 됩니다. 이름을 바꾸거나 유형을 고칠 수 있습니다. 필요 없는 항목은 지웁니다.
AI가 한 번에 많이 뽑되, 최종 구조는 사람이 확정합니다.
3단계. 맥락을 넣고 초안을 생성합니다
구조가 확정되면 SpecSaver가 수초 내에 상세한 디스크립션을 생성해 냅니다. 생성 전에 미리 두 가지를 함께 넣어두면 디스크립션의 결과를 조절할 수 있습니다.
하나는 배경 자료입니다. 프로젝트 전체의 골격이 되는 사업기획서, 기능정의서 같은 정책 문서를 첨부해 두면, “어떻게 동작하는가”의 근거로 삼습니다.
다른 하나는 해당 화면에 특정된 컨텍스트입니다. “로그인 실패 시 5회까지만 시도할 수 있다” 같은, 화면에는 안 보이지만 반드시 들어가야 할 정책을 미리 적어두면 초안이 그 내용을 반영합니다. 화면으로 “무엇이 어디 있는가”를 보고, 입력된 컨텍스트와 문서로는 “어떻게 동작하는가”를 읽는 셈입니다.
그렇게 나온 초안은 대략 이런 모습입니다.
4단계. 사람이 또 한 번 봅니다
마지막은 다시 사람입니다. 디스크립션의 내용 편집 모드로 진입해서 [확인 필요]를 채우고, 어색하거나 보충이 필요한 문장을 다듬습니다. 편집 모드에서는 화면 설계할 때 자주 쓰는 ‘TBD, 참조 페이지’와 같은 입력을 도와주는 칩(Chip)이 제공되고, 가독성을 위한 문장 들여 쓰기 같은 디테일도 지원합니다.
정리하면 이렇습니다. AI가 화면을 보고 → 사람이 구조를 다듬고 → AI가 초안을 쓰고 → 사람이 내용을 완성합니다. AI 한 번, 사람 한 번. 이 리듬이 SpecSaver의 핵심입니다.
디스크립션은 표 형태와 리스트 형태 중에서 고를 수 있도록 했습니다. 팀이나 고객사가 쓰는 규격서 양식에 맞추기 위해서입니다.
조금 더 안을 들여다보면
이 네 단계는, 뜯어보면 두 번의 AI 호출로 이뤄집니다. 화면을 보고 구조를 뽑는 분석 호출, 그리고 확정된 구조에 맥락을 얹어 문장을 만드는 생성 호출입니다. 그 사이에 사람의 검토가 끼어 있는 구조죠.
두 호출은 모두 중간 서버를 한 번 거쳐 나갑니다. 이유는 둘입니다. 하나는 팀의 화면 설계서 작성 가이드와 프롬프트를 클라이언트에 노출하지 않고 서버 뒤에 숨기기 위해서고, 다른 하나는 모델 교체·재시도 같은 통제를 한곳에서 하기 위해서입니다. 작은 디테일 하나 더 붙이면, 작업마다 모델이 ‘생각하는 깊이’를 다르게 줬습니다. 구조를 빠르게 훑는 분석에는 얕게, 문장을 짓는 생성에는 조금 더 깊게. 필요 이상으로 뜸 들이지 않도록요.
실무자는 작업 도중에 멈추면 안 됩니다
여기엔 눈에 잘 안 띄는 고민이 하나 더 있습니다. AI를 부르는 도구는 AI 서버 사정에 휘둘립니다. 요즘처럼 다들 AI를 쓰는 시기엔 서버가 몰려서(과부하) 응답이 느려지거나 아예 실패하는 일이 생깁니다. 그런데 생성 버튼을 눌렀는데 그대로 멈춰버리는 경험은 실무자의 흐름을 가장 확실하게 끊는 일입니다.
그래서 안전장치를 겹겹이 넣었습니다. 요청이 실패하면 1초, 2초, 4초로 간격을 늘려가며 몇 번 다시 시도하고(지수 백오프), 그래도 안 되면 메인으로 쓰는 최신 모델 대신 더 가벼운 모델로 자동으로 갈아탑니다. 생성처럼 오래 걸리는 작업은 결과를 한꺼번에 기다리게 하지 않고 만들어지는 대로 흘려보내되(스트리밍), 첫 응답이 90초, 중간 응답이 20초를 넘게 끊기면 하염없이 매달려 있지 않도록 스스로 중단하며 상태를 안내합니다.
여기서도 한 가지를 지킵니다. 더 가벼운 모델로 자동 전환 됐을 때 대체 모델로 넘어갔다는 사실을 숨기지 않습니다. 품질이 평소와 다를 수 있으니 “지금은 대체 모델로 만든 결과”라고 배너로 알려줍니다. 뒤에서 설명할 [확인 필요]와 같은 태도입니다. 불확실한 것도, 평소와 다른 상태도 사람에게 숨기지 않고 드러내는 것입니다.
화면은 저장되지 않습니다
AI 도구를 쓸 때 가장 먼저 드는 걱정이 이겁니다. “내가 넘긴 화면과 정보가 어딘가에 저장되거나, 모델 학습에 쓰이는 건 아닐까?” 실무에서 다루는 화면은 대개 미공개 서비스이고 보안이라 민감한 부분이니까요.
먼저, SpecSaver는 화면 이미지를 서버에 저장하지 않습니다. 화면은 분석에 필요한 그 순간에만 중간 서버(프록시)를 거쳐 AI로 전달되고, 응답이 오면 그 자리에서 사라집니다. 실제로 서버에는 이미지를 담아둘 저장소 자체가 붙어 있지 않고, 이미지가 로그로 기록되는 경로도 없습니다. 화면이 향하는 곳은 오직 하나, Google의 Gemini 뿐입니다. 다른 어떤 제3의 서버로도 보내지 않습니다.
그다음이 중요한데, AI 호출은 사용자가 직접 넣은 API Key로 이뤄집니다. SpecSaver는 각 사용자가 자기 Google Gemini Key를 설정에 입력해 쓰는 구조입니다(BYOK, Bring Your Own Key). 즉 화면은 SpecSaver의 어떤 공용 계정이 아니라, 개인 소유의 Key를 통해 Google의 Gemini로 직접 갑니다.
그러면 “학습에 쓰이느냐”는 결국 사용자가 넣은 Key의 등급에 달립니다. Google의 유료 Gemini API는 프롬프트·응답을 제품 개선(모델 학습 포함)에 사용하지 않는다고 약관에 명시합니다. 반면 무료 등급은 제출한 내용이 제품·서비스 개선에 사용될 수 있고, 사람 검토자가 볼 수도 있습니다. (유럽경제지역·스위스·영국 사용자는 무료 등급에도 유료 약관이 적용됩니다.)
따라서 민감한 자료를 다룬다면, Gemini Key를 유료 등급으로 쓰길 권합니다. 학습 사용 여부의 최종 결정은 그 Key가 쥐고 있기 때문입니다. 정책은 바뀔 수 있으니, 민감한 작업 전에는 Google의 최신 Gemini API 약관을 한 번 확인하시는 편이 안전합니다.
100% 완성된 디스크립션을 제공하지 않는 이유
여기서 이상하게 느끼는 분이 계실 겁니다. 기왕 AI를 붙일 거면, 화면을 넣으면 완성된 설계서가 뚝 나오게 하면 안 되나요? 버튼 한 번에 규격서 완성. 데모로 보여주면 제일 그럴듯한 그림입니다.
만들면서 저도 그런 유혹을 받았습니다. 그런데 조금만 따져보니 그건 안 되는 방향이었습니다.
완성본을 받으면, 사람은 그냥 받아들입니다
연구자들이 반복해서 관찰한 현상이 있습니다. 사람과 AI가 함께 일하는 팀이 종종 AI 혼자 할 때보다 못한 결과를 낸다는 것입니다. 사람이 자기 판단을 AI 결과에 더하는 게 아니라, AI가 준 걸 그냥 받아들이기 때문입니다. 틀린 답까지 같이 통과시키는 것이죠.
그럼 차라리 사람을 빼고 AI가 완성본을 한 번에 뽑는 게 낫지 않냐고요? 그 결론이 성립하려면 전제가 하나 필요합니다. AI가 절대 안 틀려야 합니다. 그래야 사람이 안 봐도 되니까요. 그런데 디스크립션은 정확히 그 전제가 성립하지 않는 일입니다. 뒤에서 다시 이야기하겠지만, “이 버튼을 누르면 무슨 일이 벌어지는가”는 화면에 없는 정보라 AI가 구조적으로 틀릴 수밖에 없습니다. 틀릴 수밖에 없는 일에서 완성본을 한 번에 뱉으면, 그 틀린 부분을 사람이 그대로 받아들일 위험만 커집니다.
그러니 문제는 사람이 낀 것이 아니라 낀 사람이 판단을 안 한 것입니다. 하버드의 부친차(Buçinca) 연구진이 내놓은 처방도 사람을 빼라가 아니라 그 반대였습니다. 사람이 곧바로 수용하지 못하도록, 중간에 스스로 판단하게 만드는 장치. 이른바 인지적 강제 장치(cognitive forcing function) 를 끼워 넣으면, 틀린 AI 제안에 휩쓸리는 일이 줄어든다는 것입니다. 완성본을 툭 던지는 도구는 정확히 그 반대로 작동합니다. 받아들이기 가장 쉬운 형태로 결과를 내밀어, 사람이 판단을 건너뛰게 만들기 때문입니다.
SpecSaver가 ‘AI 한 번, 사람 한 번’의 리듬을 고집하고, 분석과 생성 사이에 사람의 검토 단계를 일부러 끼워 넣은 건 이 때문입니다. 검토를 권하는 게 아니라 구조적으로 거치게 만든 것입니다. 완성본을 받아 대충 넘기다 보면, 남는 건 빠르게 만들었지만 뭐가 맞고 뭐가 틀렸는지 모르는 설계서일 뿐이니까요.
화면은 무엇은 알아도 어떻게는 모릅니다
이유는 하나 더 있습니다. 화면 이미지가 알려주는 건 딱 하나입니다. 무엇이 어디에 있는가. 버튼이 여기 있고, 입력창이 저기 있다. 여기까지는 AI가 꽤 잘 봅니다.
하지만 디스크립션의 진짜 알맹이는 그게 아닙니다. 이걸 누르면 무슨 일이 벌어지는가, 어떤 조건에서 막히는가, 왜 이렇게 동작하는가. 이건 화면 어디에도 안 적혀 있습니다. 기획자의 머릿속과 기획서에 있습니다.
앞의 로그인 버튼을 다시 봅시다. “버튼을 누르면 로그인이 된다”까지는 화면만 봐도 짐작이 갑니다. 그런데 “실패하면 어떻게 되는가”는 화면에 없습니다. 5회 실패하면 잠기는지, 그냥 에러 메시지만 뜨는지는 정책의 영역입니다.
그럴듯한 거짓말이 제일 위험합니다
AI가 이 빈칸을 그럴듯하게 채우면 어떻게 될까요. 그럴듯한 거짓말이 됩니다. 화면만 보고 “이 버튼을 누르면 홈으로 이동합니다”라고 자신 있게 써놨는데, 실제로는 이전 화면으로 돌아가는 버튼일 수 있습니다. 검토하는 사람이 그 문장을 믿어버리면, 틀린 설계서가 그대로 나갑니다. 매끄럽게 쓰인 문장일수록 더 잘 통과되겠지요.
그런데 스탠퍼드 연구진(Vasconcelos 외, 2023)은 반대 방향의 실마리도 보여줍니다. AI가 무엇을 근거로 그렇게 판단했는지를 드러내면, 사람이 맹목적으로 따르는 정도가 줄어든다는 것입니다. 핵심은 판단의 근거와 불확실성을 감추지 않고 보여주는 데 있습니다.
그래서 SpecSaver는 화면만으로 단정할 수 없는 자리는 확신하는 척 채우지 않고, [확인 필요]로 남깁니다. 채워야 할 빈칸이 어디인지를 사람에게 짚어주는 것입니다. 비슷한 발상은 코드 자동완성 도구 연구에서도 나옵니다. 같은 스탠퍼드 그룹이 참여한 2024년 연구(ACM TOCHI)는, AI가 짜준 코드에서 확신이 낮은 부분을 골라 인라인으로 표시해 주는 방식을 실험했습니다. 개발자들은 이런 표시가 뭉뚱그리지 않고, 짚어주되, 과하지 않을 때 가장 쓸모 있다고 평가했습니다. [확인 필요]가 노리는 것도 똑같습니다. 문장을 매끄럽게 다 채워 넘기는 대신 여기가 불확실하다를 콕 집어 사람 앞에 놓아두는 것입니다.
금지해야 할 것은 추론 자체가 아니라 추론을 숨기는 것입니다. AI가 합리적으로 추측하는 건 괜찮습니다. 다만 다른 그럴듯한 답이 열려 있다면, 확신한 얼굴로 하나만 써 놓지 말고 “여기는 확인이 필요하다”라고 함께 적어두는 것입니다. 판단의 기준을 “내가 확신하는가”(주관)에서 “다른 그럴듯한 답이 존재하는가”(객관)로 바꾼 셈입니다.
결국 이 모든 결정은 한 가지 고민으로 이어집니다. 자동화를 너무 밀어붙이면 사람이 판단을 놓고, 반대로 사람이 다 붙들고 있으면 도구가 아무것도 덜어주지 못합니다. SpecSaver는 이 자동화와 통제감 사이의 균형을 맞추려고 했습니다. 지겨운 절반은 도구에 맡기되, 판단이 필요한 자리에서는 사람이 반드시 개입하게. 그 경계를 어디에 그을지가, 사실 이 도구를 만드는 내내 가장 오래 붙든 질문이었습니다.
진짜 오래 걸리는 일, 팔로업
앞에서 잠깐 말했지만, 규격서 작업에서 가장 시간을 잡아먹는 건 초벌이 아니라 이후의 팔로업 과정입니다. 한 번 쓰고 끝이 아니라, 몇 주에서 몇 달에 걸쳐 계속 고치고 고도화하는 일입니다.
이 팔로업에도 나름의 규칙이 있습니다. 수정한 부분은 빨간 글씨로 표시하고, 삭제한 부분은 취소선을 긋고, 수정한 페이지에는 변경 이력을 남깁니다. 손으로 하면 빠뜨리기 쉽고, 빠뜨리면 “이번에 뭐가 바뀐 거냐”는 질문이 돌아옵니다.
SpecSaver는 이 팔로업을 돕습니다. 업데이트해야 할 내용을 입력하면 선택한 기존 디스크립션 표 내에서 수정이 필요한 부분을 모두 찾아낸 뒤에 어떻게 수정이 되는지 미리 보여줍니다. 원본과 나란히 비교해서 보여주고, 확정하면 실제 디스크립션에 반영합니다. 기존 디스크립션에서 바뀐 부분을 빨간색으로 하이라이트하고, 삭제하는 정의에 취소선을 그어 기존 디스크립션 표에 반영합니다. 그리고 가장 중요한 것. 이전 버전에서 표시했던 바뀐 부분의 하이라이트는 보통 상태로 되돌려 놓습니다. 그래야만 이번에 고친 최신 내용만 하이라이트 할 수 있으니까요.
지금 그리고 앞으로의 계획
SpecSaver는 현재 사내에서 실무에 적용해 보는 단계입니다. 우리 팀의 실제 프로젝트에 매일 테스트하면서, 어떤 화면에서 잘 되고 어떤 상황에서 부족한지를 보고 있습니다. 도구를 팀 밖에 내놓기 전에, 먼저 충분히 써보려고 합니다.
앞으로 다듬어 갈 방향은 대략 이렇습니다. 지금 가장 공들이는 건 팔로업 고도화입니다. 버전 태그와 변경 이력을 캔버스에 남기고, 그 이력을 따로 뽑아낼 수 있게 만드는 일입니다. 그 밖에 규격서 표 양식을 더 갖추고, 여러 화면을 한 번에 처리하는 배치 작업, 도구 자체가 자기 초안의 누락·[확인 필요]를 점검하는 '자가 검증' 같은 것들을 로드맵에 두고 있습니다. 외국어 지원, Gemini 외 클로드, 챗GPT 같은 다양한 모델 선택도 고려 중이고요.
한 가지 방향은 특히 눈여겨보고 있습니다. SpecSaver는 표준화된 규칙에 맞춰 커스터마이즈 할 수 있습니다. 어떤 어체로 쓸지, 어떤 항목을 어떤 위계로 담을지, 무엇을 [확인 필요]로 남길지와 같은 규칙을 바꾸면 같은 화면에서도 전혀 다른 결의 디스크립션이 나옵니다. 여기에 플러그인 설정으로 조절할 수 있는 것들(표 양식, 번호 체계, 유형 분류 등)까지 더하면, 결국 각 기업마다 고유한 UX 규격서 표준에 맞춰 도구를 통째로 맞춤할 수 있다는 뜻이 됩니다.
화면설계서 양식은 회사마다, 심지어 프로젝트마다 다릅니다. 기존 규격서 스타일을 가이드로 녹이고 설정을 그 팀에 맞게 잡아주면, 범용 도구가 아니라 회사의 화면설계서를 쓰는 도구가 됩니다. 아직 구체적인 제공 형태를 정한 단계는 아니지만, SpecSaver가 팀 밖으로 나간다면 이런 커스터마이즈가 하나의 축이 될 수 있다고 보고 있습니다.
마치며
만들면서 계속 스스로에게 물었던 건 “이것이 기획자의 역할을 얼마나 대체하나?”였습니다. 답은 아니오입니다. 그리고 그래서는 안 된다고 생각합니다.
디스크립션 작성에는 두 종류의 일이 섞여 있습니다. 하나는 번호를 매기고 요소를 나열하는, 판단이 거의 없는 노동입니다. 다른 하나는 이 화면이 이렇게 동작해야 하는 이유를 정하고, 이 페이지에서 어디까지 설명하고 다음 페이지로 넘겨야 읽는 사람이 보기 더 좋을지에 대한 판단 그 자체인 일입니다. 전자는 AI가 덜어줄 수 있습니다. 후자는 여전히 사람 몫이고, 앞으로도 그럴 것입니다.
돌아보면 이 도구의 크고 작은 결정들은 대부분 한 방향을 봅니다. 레이어를 정리하라고 요구하는 대신 화면을 눈으로 읽고, 번호 배지를 대신 찍고, 서버가 몰려도 작업이 멈추지 않게 하고, 몇 달짜리 팔로업을 거들고, 확신할 수 없는 자리는 숨기지 않고 드러내는 것. 전부 기획자의 작업 흐름을 끊지 않으려는 선택이었습니다.
이건 저희 팀에서도 계속 나오는 이야기입니다. 같은 pxd의 동료가 쓴 글들도, 결국 ‘AI를 잘 부리는 기술’보다 ‘자기 일에 대한 사람의 판단력’이 진짜 변수라는 결론에 닿습니다. AI 앞에서 “이건 괜찮고 이건 아니다”를 가르는 기준은 프롬프트를 잘 쓰는 법이 아니라 사용자를 관찰하고 맥락을 이해해 온 경험에서 나옵니다.
SpecSaver가 하는 일도 딱 거기까지입니다. 그 판단력을 대신하려는 게 아니라, 판단력이 발휘될 자리를 비워두는 것. 지겨운 절반을 덜어주고, 아낀 시간을 단순 노동이 아닌 진짜 고민에 쓰게 하는 것.
그거면 충분하다고 생각합니다. 적어도 지금은요.
써보고 싶으시다면
앞서 말씀드린 대로 SpecSaver는 지금 사내에서 다듬는 중이라, 아직 외부에서 바로 쓰실 수는 없습니다. 그럼에도 “우리 팀 작업에도 이런 게 필요하다” 싶거나, 제품이 궁금하시다면 편하게 문의를 남겨 주세요.
- 프로덕트 문의: xdax@pxd.co.kr
참고 자료
연구
- Buçinca, Z., Malaya, M. B., & Gajos, K. Z. (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. Proceedings of the ACM on Human-Computer Interaction, 5(CSCW1). Harvard University. https://doi.org/10.1145/3449287
- Vasconcelos, H., Jörke, M., Grunde-McLaughlin, M., Gerstenberg, T., Bernstein, M. S., & Krishna, R. (2023). Explanations Can Reduce Overreliance on AI Systems During Decision-Making. Proceedings of the ACM on Human-Computer Interaction, 7(CSCW1). Stanford University. https://doi.org/10.1145/3579605
- Vasconcelos, H., Bansal, G., Fourney, A., Liao, Q. V., & Vaughan, J. W. (2024). Generation Probabilities Are Not Enough: Uncertainty Highlighting in AI Code Completions. ACM Transactions on Computer-Human Interaction. https://doi.org/10.1145/3702320
함께 보면 좋은 pxd 글
- 이예진 (2026). 「AI와 협업하는 최선의 워크플로우 찾기」. pxd story. https://story.pxd.co.kr/1914