시작은 아주 단순한 의문이었습니다
"채용 공고 하나 올리는 데 왜 이렇게 많은 도구가 필요할까?"
채용 공고 하나를 게시하기 위해서는 생각보다 많은 도구를 오가야 했습니다. JD 내용을 정리한 뒤 구글 스프레드시트에 입력하고, 이를 다시 엑셀 템플릿으로 옮긴 후 PPT에서 이미지를 제작하는 복잡한 과정이었습니다.
전 업무 프로세스 (기존 방식)
•
Google Spread Sheet: JD 내용은 현업팀과의 공유 및 히스토리 축적을 위해 사용
•
Excel: JD 이미지 템플릿은 폰트 수정, 관련 이미지 요소 추가, 이미지 축적을 위해 사용
•
Power Point: 복사한 이미지는 PNG, JPG 파일로의 저장을 위해 ‘그림으로 붙여 넣기’ 이후 ‘그림으로 저장’
•
Word Press: 공고 이미지의 채용 사이트 업로드를 위한 퍼블리싱 가능한 HTML 코드로의 변환을 위해 게시
•
최종 게시: 사람인, 잡코리아, 알바몬, 리멤버, 원티드, 자소설닷컴 등
문제는 수정이 발생했을 때입니다.
채용 공고는 오탈자 하나에도 지원자 경험이 달라질 수 있기 때문에 검수가 매우 중요합니다. 하지만 공고 업로드 전, 그리고 JD 변경 후, 수정이 필요한 경우에 다시 엑셀 단계부터 전체 과정을 반복해야 했습니다. 반복 작업이 많아질수록 시간은 늘어나고, 실수 가능성도 높아졌습니다. 그래서 이 과정을 조금 더 단순하게 만들 수 없을지 고민하게 되었습니다.
0부터 시작하는 바이브코딩
번거로운 과정에 대한 불편함을 가지고 있던 중, 마침 전사 AX 전환 물결이 찾아왔고 채용 업무 중에서 가장 보안 이슈도 적고, 해결했을 때 효율성 제고 효과가 높을 것 같아 이 작업을 AI와 함께 통합하는 툴을 제작하게 되었습니다.
처음엔 가장 간단하게
채용 공고 JD를 입력하여 이미지를 생성하는 도구의 프로토타입을 만들어줘
라는 간단한 프롬프트를 입력하여 프로토타입을 확인했습니다.
그렇게 만들었던 프로토타입의 결과물이 생각보다 깔끔하게 나왔고, 이미지 제작부터 PNG 추출까지 하나의 도구 안에서 가능하다는 점이 인상적이어서 이 도구를 발전시켜 나가게 됩니다. 앞으로 나올 수많은 기능 추가와 디버깅 과정은 모른 채로 말이죠…
신나게 기능을 추가하던 중 만난 벽
첫 프로토타입에 실제로 사용이 가능한 기능을 추가하는 과정은 즐거웠습니다. 디자인 편집 기능(폰트 크기, 섹션별 위치, 도형 이미지 변경 등), 검수 기능, 이미지 첨부 기능, JSON 저장 및 불러오기 기능, 테마 변경 기능 등 정말 다양한 기능을 넣었습니다. 기능을 추가할 때마다 AI가 빠르게 업데이트 해주었고, 저는 결과물을 확인하며 개선 방향을 피드백 하는 방식으로 개발을 진행했습니다.
생각보다 어려웠던 폰트 적용 기능
기능을 하나씩 추가하던 중 예상치 못한 문제를 만났습니다. 바로 폰트 적용 기능이었습니다. 채용 공고 이미지는 단순히 내용을 전달하는 역할만 하는 것이 아니라, 회사의 브랜드 경험을 전달하는 역할도 합니다. 그렇기 때문에 기존 프리윌린 채용 공고에서 사용하던 폰트를 동일하게 적용하는 것이 중요했습니다.
처음에는 단순한 작업일 것이라고 생각했습니다.
"이미 컴퓨터에 설치되어 있는 폰트인데, 선택해서 적용만 하면 되는 것 아닌가?"
하지만 실제로는 그렇지 않았습니다. Windows에서는 멀쩡하던 폰트가 웹 생성기 화면에서는 깨지거나 기본 폰트로 대체되는 문제가 발생했습니다. 처음에는 AI를 붙잡고 무작정 코드만 고쳤지만 허사였습니다. 문제는 코드가 아니라, ‘웹이 폰트를 인식하는 방식’을 제가 모른다는 데 있었기 때문입니다.
정확한 원인을 찾기 위해 브라우저 개발자 도구를 열어 실제로 렌더링된 폰트를 추적해 보았습니다. 화면에는 제가 지정한 폰트 이름 대신 엉뚱한 기본 폰트가 그려지고 있었습니다.
원인은 ‘폰트 이름’에 있었습니다. 우리가 하나라고 생각하는 폰트 파일 안에는, 사실 사람으로 치면 본명, 영문 이름, 별명처럼 여러 개의 이름이 함께 들어 있습니다. 이 때문에 윈도우 설정 화면이 보여주는 이름과, 웹 브라우저가 폰트를 찾을 때 기준으로 삼는 이름(Family Name)이 서로 다를 수 있습니다.
예를 들어 윈도우에서 'Sandoll 고딕Neo'라고 알고 있던 폰트가, 웹에서는 전혀 다른 Family Name으로 등록되어 있었습니다. 존재하지 않는 이름을 부르니 브라우저 입장에서는 알아듣지 못하고 기본 폰트를 내어줄 수밖에 없었던 거였습니다. 결국 개발자 도구에서 브라우저가 인식하는 진짜 이름을 찾아 매핑해 주면서 문제를 깔끔하게 해결할 수 있었습니다.
이 과정을 이해한 뒤에는 '폰트 테스트 화면'을 만들었습니다. 어떤 폰트가 실제로 렌더링되고 있는지 한눈에 파악할 수 있는 진단 기능을 추가한 것입니다. 결과적으로 원하는 브랜드 폰트를 안정적으로 적용할 수 있게 되었고, 더 나아가 채용 공고의 섹션별로 서로 다른 폰트를 지정할 수 있도록 기능까지 성공적으로 확장할 수 있었습니다.
돌아보면 폰트 적용 기능 하나를 만들기 위해 웹 폰트 렌더링 방식과 브라우저 동작 원리를 새로 공부하게 된 셈입니다. 이 경험을 통해 느낀 점은, AI가 코드를 대신 써줄 수는 있어도 문제를 해결하려면 결국 사람이 그 원인을 이해해야 한다는 것이었습니다.
채용 공고 이미지 생성기_업데이트 진행 중_26.06
프로토타입에서 기능 추가와 디버깅까지 마친 현재까지의 이미지 생성기의 기능을 소개합니다.
내용 입력 탭
가장 기본이 되는 직무 상세 정보를 입력하는 란입니다. 섹션별로 나뉘어져 있으며, 각 섹션의 위치 및 제목 변경도 가능합니다. 기본적인 디자인, 폰트 세팅을 마친 후에는 이쪽 탭에서 내용만 수정하면 바로 사용 가능한 이미지로 제작이 가능합니다.
기존의 엑셀과 PPT 툴
디자인 탭
디자인에 관련한 모든 설정이 들어있는 탭입니다. 섹션별 위치, 수직과 수평 정렬, 텍스트 크기와 위치, 폰트 적용, 세부적인 디자인 수정을 할 수 있습니다.
이외에도
•
검수 기능
•
저장 및 불러오기
•
테마 변경
•
자유 배치
등 다양한 기능을 추가했습니다.
그래서 무엇이 달라졌을까?
무엇보다 좋았던 점은 수정에 대한 부담이 줄어들었다는 것입니다. 기존에는 오탈자 하나를 수정하기 위해 여러 도구를 다시 열어야 했지만, 이제는 생성기 안에서 내용을 수정하고 다시 추출하면 됩니다. 덕분에 채용 공고를 더 빠르게 업데이트할 수 있게 되었고, 공고 검수 과정도 한결 수월해졌습니다.
기존에는 채용 공고 하나를 제작하기 위해 구글 스프레드시트 → 엑셀 → PPT → 워드프레스 → 채용 사이트를 반복적으로 오가야 했습니다. 공고 수정이 발생하면 다시 엑셀 단계로 돌아가 동일한 작업을 반복해야 했습니다. 현재는 생성기에서 내용을 입력하고 디자인을 수정한 뒤 바로 PNG를 추출할 수 있도록 변경되었습니다. 아직 워드프레스 HTML 추출 기능은 완성되지 않았지만, 공고 제작 과정의 상당 부분을 하나의 도구 안에서 해결할 수 있게 되었습니다.
앞으로 만들고 싶은 것
현재 생성기는 채용 공고 이미지를 만드는 데 필요한 대부분의 기능을 갖추고 있습니다. 하지만 아직 개선할 부분이 남아 있습니다. 개인적으로는 직무기술서(JD)를 입력하면 자동으로 디자인에 맞춰 배치하고, 최종적으로 PNG와 HTML까지 한 번에 생성하는 기능을 구현해보고 싶습니다. 또한 폰트 선택의 편의성, 이미지 자동 생성, 사용성 개선 등 실제 운영 과정에서 발견한 문제들도 계속 개선해 나갈 계획입니다. 어쩌면 다음 버전의 생성기는 제가 직접 내용을 입력하는 과정마저 줄여줄 수 있을지도 모르겠습니다.
생성기보다 더 크게 얻은 것
AI는 주어진 문제를 빠르게 해결하는 뛰어난 플레이어인 것 같습니다. 하지만 어떤 문제가 중요한지, 그리고 어떤 방향으로 해결해야 하는지는 사람이 결정해야 합니다. 감독이 없는 플레이어가 그렇듯, AI 역시 문제를 스스로 정의하지는 못하고 때로는 엉뚱한 방향으로 해결책을 제시하기도 합니다.
AI는 코드를 대신 작성해주지만, 문제를 정의해주지는 않는다.
실제로 AI 에이전트들과 프로토타입을 만들고, 기능을 추가하고, 문제를 해결하는 것에는 오랜 시간과 노력이 들어가지 않았습니다. 오히려 어떤 업무를 효율화하는 것이 좋을지, AI에게 맡겨도 보안 문제가 없는 업무는 무엇일지, 정보를 어디까지 넘겨줘도 좋을지에 대한 고민이 더 길었습니다. 결국 AI를 활용하는 과정에서 가장 어려웠던 것은 구현이 아니라 문제 정의와 보안 검토였습니다.
가장 좋은 자동화 아이디어는 가장 가까운 곳에 있다.
AI와의 협업, 그리고 바이브 코딩을 처음에는 AI와의 협업이나 바이브 코딩을 거창한 서비스 개발이나 비즈니스에 큰 임팩트를 주는 변화로만 생각했던 적이 있었습니다. 하지만 실제로는 매일 반복하는 작은 업무의 비효율을 하나씩 해결하는 과정이 쌓여 결국 더 큰 변화로 이어진다는 것을 알게 되었습니다.
AX는 기술 도입이 아니라 업무 재설계에 가깝다.
실제로 이번 프로젝트를 진행하며 가장 먼저 했던 일은 코딩이 아니라 업무 프로세스를 다시 정리하는 일이었습니다. AX를 적용할 업무를 찾기 위해 기존 업무 프로세스를 하나씩 점검하는 과정에서 예상보다 많은 비효율을 발견할 수 있었습니다. 이전에는 조금 불편해도 원래대로 하는 일들이 많았고, 다른 업무들을 처리하다 보면 비효율적인 업무도 관성대로 임하고 있었다는 것을 알게 되었습니다. 이번 프로젝트를 계기로 보안 이슈가 없는 범위 내에서 리쿠르터의 업무를 계속 재설계해보고 싶어졌습니다. 그리고 그 과정이 충분히 가능하다는 점도 확인할 수 있었습니다.
