요즘 AI 공부는 회사 안에서 강의를 듣는 것만으로는 한계가 있다. 바뀌는 속도가 너무 빠르다. 그래서 여러 커뮤니티에 나가고, AI를 쓸 수 있는 학교 연구 과제에도 참여하려고 애써 왔다. 일종의 개인 레벨업이다. 그러다 보니 지금은 흔히 AX(AI 전환), FDE(현장에 붙어 AI를 실제 업무에 적용하는 역할)라고 부르는 일을 하는 부서에 와 있다.
그 과정에서 회사 확인이 꼭 필요한 일이 하나 있었다. 소속을 확인해 주는 서류 한 장이었는데, 사정을 설명해도 결국 받지 못했다. 회사 이름을 걸고 AI로 하는 일이었는데도. 솔직히 화가 났다.
화가 나니까 이직 준비를 하겠다고, 이력서, 포트폴리오부터 정리하려고 했다.
근데 이 정리부터가 일이었다. 그 관문을 겨우 넘으면 이번엔 예전 자료를 뒤져야 하고, 그때 그걸 어떻게 정리했는지는 기억이 흐릿하다. 그러다 보니 문서마다 조금씩 오차가 생긴다. 기간이 살짝 다르고, 역할 이름이 바뀌어 있고, 숫자가 안 맞는다. 그걸 하나하나 신경 쓰면서 맞추는 작업이 생각보다 훨씬 많았다.
이렇게 정리하면 과정이 끝날까? 거기서 끝이 아니다. 취업문이 좁아지면서 요즘은 JD(채용공고)마다 맞춰서 내는 게 정석처럼 됐다. 공고 하나하나에 맞춰 다시 쓰려니 그것도 엄청난 일이다. 서류 합격이 안 되는 사람도 많아서 포트폴리오 과외를 받는 것도 봤고, 실제로 그 현장에도 가 봤다. 그 기억이 겹치면서, 이건 진짜 필요한 거구나 싶어졌다.
범용 AI한테 맡기면 그럴듯한 문장은 금방 나온다. 문제는 그다음이다. 원문에 없던 경력이 끼어들지 않았는지, 숫자가 부풀지 않았는지 한 줄씩 다시 확인해야 한다. 그렇게 확인한 것도 다음 지원 때는 또 처음부터다.
그때 깨달았다. AI로 글을 빨리 쓰는 것만이 능사가 아니다. 지원하려는 회사마다 공고를 분석해서 다시 써야 하고, 그렇게 쓴 걸 하나하나 확인하는 과정에 시간을 너무 많이 뺏긴다. 지원할 때마다 반복되는 건 글쓰기보다, 내가 실제로 뭘 했는지 확인하는 일이었다.
디디움은 이 확인을 다음 지원에서도 꺼내 쓸 수 있게 남겨 두는 데서 출발했다.
이번엔 일하는 방식도 바꿨다
필요성 말고 하나가 더 있었다. 개발자랑 일하는 방식을 조금 바꿔 보고 싶었다.
이제는 개발자도 기획을 해야 하는 시대라고 생각한다. 그래서 이번엔 기획을 내가 다 주도해서 잡는 방식 말고, 조금 느리더라도 함께 논의하고 함께 기획하는 방식으로 진행하고 있다. 개발 쪽도 기획자가 함께 본다. 효율이 떨어진다고 생각할 수도 있지만, 이 또한 AI로 개발하면서 줄어든 개발 시간과 상쇄된다고 생각한다. 서로 다 할 줄 아는 AI 인재가 되는 방향을 생각했다. 결국 이런 경험이 쌓여야, 다음에는 더 나은 서비스를 함께 논할 수 있는 팀이 될 수 있다고 생각한다.
그래서 이 연재는 디디움을 어떻게 설계했는지에 대한 기록이면서, 그렇게 같이 기획하는 방법을 나누려는 기록이기도 하다. 같이 기획하는 이야기는 3화부터 적기 시작했다. 디디움은 아직 만들어 가는 중이라, 이 이야기도 계속 이어서 적어 갈 생각이다.
그래서 순서를 바꿨다
디디움은 문장을 쓰기 전에 이력부터 확인한다. AI가 올린 이력서와 포트폴리오에서 이력 후보랑 근거 문장을 찾고, 사용자는 그 후보를 원문과 나란히 놓고 그대로 쓰거나 고친다. 이렇게 확인한 이력만 서재에 쌓이고, 공고에 맞춘 초안은 이 이력만 재료로 쓴다.
경험 하나가 공고 여러 개의 재료가 되려면
설명하려고 가상의 예를 하나 들어 보면, 포트폴리오에 "사용자 12명을 인터뷰하고 가입 화면을 개선했다"는 경험이 있다고 치자. 어떤 공고에선 사용자 조사 경험이 중요하고, 다른 공고에선 화면 개선 경험이 중요할 수 있다. 같은 경험이어도 힘주는 데가 달라진다.
그렇다고 인터뷰한 사람이 12명에서 20명으로 바뀌면 안 된다. 화면을 개선했다는 기록만 있는데 가입률을 높였다는 성과가 슬쩍 붙어도 안 되고. 공고마다 바꿀 수 있는 표현과, 바뀌면 안 되는 사실을 분리하는 것, 이게 이 설계의 핵심이다.
그래서 기획에서는 AI가 뽑은 사실이랑 문장, 역량 해석을 전부 사용자가 확인하기 전까지 제안으로 둔다. 자료에서 찾았다는 이유만으로 바로 확정 이력이 되지는 않는다. 원문을 가져오는 일, 그게 내 경험을 제대로 설명하는지 판단하는 일, 지원 문장으로 다시 쓰는 일을 일부러 나눠 둔 거다.
AI가 찾은 것은 사용자가 확인하기 전까지 후보일 뿐이다.
불편함을 일부러 남긴 곳
제일 오래 고민한 규칙은 이거다. 확인 안 한 이력이나 문서끼리 어긋난 값이 남아 있으면, 초안은 보고 고칠 수 있지만 제출용 파일은 안 만든다. 경고 창에서 "그래도 진행하기"를 눌러 넘어가는 길도 안 뒀다.
기획서에는 이 규칙의 대가도 적어 뒀다. 근거가 약한 사용자는 바로 완성된 문서를 받기 어렵다. 그래도 규칙을 남긴 이유는 두 가지다. 이게 없으면 디디움은 또 하나의 AI 글쓰기 도구가 되고, 서류에 쓴 내용이랑 면접에서 하는 말이 엇갈리기 시작한다.
여기서 막히는 건 제출용 파일을 만드는 순간뿐이다. 확인이 다 안 끝났어도 초안을 보거나 고칠 수는 있게 설계했다. 생각을 정리하는 과정까지 막지는 않되, 밖으로 제출할 문서를 만드는 순간에는 확인을 요구하는 거다.
반대 방향의 설계도 이해는 간다. 일단 파일을 내려받게 하고 주의 문구만 붙이면 사용자는 더 빨리 결과를 얻는다. 대신 어떤 문장을 아직 확인 안 했는지 기억하고, 제출 전에 돌아와서 고치는 책임이 사용자한테 남는다. 디디움은 그 편리함보다 확인 상태가 제출까지 이어지는 쪽을 골랐다.
이 선택이 좋은 경험으로 이어지는지는 따로 확인해야 한다. 기획서에는 막힌 뒤 확인을 마친 비율이랑 초안에서 이탈한 비율을 같이 보도록 적어 뒀다. 규칙을 엄격하게 세웠다고 사용자가 도움을 받았다고 말할 수는 없으니까. 이건 앞으로 확인할 기준이지, 사용자 테스트가 끝났다는 뜻은 아니다.
하지 않기로 한 것
합격 가능성을 숫자 하나로 예측하지 않는다. 채용 결과에는 경쟁자나 채용 인원처럼 지원자가 바꿀 수 없는 게 너무 많다. 디디움이 보여 주는 건 내 이력 중에 어떤 근거가 이 공고랑 이어지고, 어디를 더 보강하면 되는지다.
공고가 요구한 경험에 근거를 연결하지 못했다고 해서, 그게 그 일을 못한다는 판정은 아니다. 지금 서재에 있는 자료만으로는 연결을 보여 주기 어렵다는 뜻이다. 관련 경험을 더 적거나, 기존 경험의 근거를 보강할 여지를 남겨 둬야 한다.
기획을 맡으면서 분명하게 두고 싶은 경계도 여기 있다. AI는 자료를 정리하고 연결을 제안할 수는 있지만, 경험의 주인이 돼서 사실을 확정하지는 않는다. 그래서 후보를 확인하는 화면이랑 제출 파일을 만드는 조건에 같은 기준을 걸어 두도록 설계했다. 이 기준이 사용자한테 얼마나 버거운지는 아직 확인해야 한다.
다음 화에서는 AI가 찾았다는 근거 문장을 어떻게 믿을 수 있게 만드는지 써 보려고 한다.