worxphere-tech - Medium 최신 글

최신 글

• [5편] 숫자가 정답이 아닐 때, 결국 사용자를 만나야 알 수 있습니다

  WORXPHERE 채용 지원 UT의 가설 세 개와 가설 밖 발견 세 개 안녕하세요. 잡플래닛에서 채용 지원 영역을 맡고 있는 6년차 프로덕트 디자이너 송인경입니다. 이번 글은 우리 팀이 연속 지원과 AI 이력서 매핑, 두 축에서 세 개의 가설을 기반으로 사용자를 만난 기록입니다. 결과만 먼저 공유드리면, 가설 두 개 중 둘은 기각되었고 하나만 조건부로 남았습니다. 대신 예상하지 못한 발견을 안고 돌아왔습니다. 정량 데이터가 가리키는 방향과 사용자가 실제로 원하는 방향이 다를 수 있다는 것을, 아홉 번의 인터뷰로 다시 배운 사흘이었습니다. 검증에 쓴 프로토타입은 Claude로 직접 만들어 GitHub Pages에 배포했습니다. 그 과정은 [2편] 코드 못 짜던 디자이너가, 네 프로젝트를 깃허브 저장소 하나로 합친 기록에서 자세히 다뤘으니 궁금하신 분은 2편을 봐주세요. 시작은 깔끔한 데이터 한 줄이었습니다 지원을 완료하고 10분 안에 다른 공고의 ‘지원하기’ 버튼을 누르는 사용자가 약 40% 였습니다. 채용 영역 중 어디부터 개선하면 좋을 지 지표를 훑다가 눈에 들어온 숫자였습니다. “사용자가 이미 연속 지원을 하고 있으니 연속 지원을 더 쉽게 해주면 더 많이 지원하지 않을까?” 생각은 자연스럽게 그쪽으로 흘렀습니다. 그렇게 가설을 세 개 세웠습니다. H1은 연속 지원, H2는 이력서 작성 부담을 줄이는 두 가지 접근(H2‑1, H2‑2)으로 나눴습니다. H1. 사용자는 지원을 완료한 뒤, 유사한 공고를 추천해주면 이어서 여러 군데 지원할 것이다. H2‑1. AI가 타사 혹은 가지고 있는 기존 이력서를 기반으로 자동으로 작성해주면, 잡플래닛에서도 이력서를 새로 작성할 것이다. (전제 조건: 새 이력서 작성에대한 부담감이 있을 것이다) H2‑2. 이력서 폼에서 필수와 선택 항목을 시각적으로 한눈에 구분해주면, 어디까지만 작성하면 되는지 빠르게 파악해 입력 부담이 줄 것이다. 채택 기준은 인터뷰 전에 미리 정해두었습니다. 9명 중 7명 이상이면 검증, 4~6명이면 조건부 채택, 3명 이하면 재설계로 판단하기로 했습니다. 결과를 본 뒤 기준을 바꾸는 일을 막기 위해서였습니다. 참여자는 이직이 급한 사람을 중심으로 모집했고, 긴급 7명과 비긴급 2명, 총 9명을 만났습니다. 그런데 가설이 뒤집혔습니다 첫 번째 가설은 9명 중 1.5로 연속 지원 40%라는 기존 데이터가 무색해졌습니다. 9명 중 7명이 거의 같은 이유로 거절했기 때문입니다. “진짜 막 지원할 때 아니고는, 첫 문장이라도 바꿔서 이력서를 다시 내려고 해요.” (P1, PM) “공고마다 직무 이름이 달라서 맞춰서 내요. 같은 이력서로 여러 군데를 어떻게 내지? 싶어서 저는 그냥 패스.” (P2, UX 리서처) “각각의 JD에 맞는 내용을 이력서에 넣어야 되기 때문에 똑같은 이력서로 연속 지원은 안 할 것 같아요.” (P4, 전략 기획) 여기서 알게 됐습니다. 40%는 ‘다시 지원하는 행동’의 숫자였지, ‘같은 이력서로 다시 지원하고 싶다’는 의향의 숫자는 아니었습니다. 사용자를 직접 만나지 않았다면 몰랐을 겁니다. 데이터만 봐서는 알 수 없는 이야기였으니까요. ‘방금 낸 이력서를 그대로 쓴다’는 건 우리 팀의 생각이었을 뿐, 사용자에게는 당연한 일이 아니었습니다. 화면 앞에서 머뭇거리는 모습을 보고 나서야 알았습니다. ‘AI 이력서’라는 단어가 만든 또 다른 오해 H2‑1, AI 이력서 매핑도 예상 밖이었습니다. 5명은 이력서 작성 화면에 진입조차 하지 않았습니다. “AI 이력서 채우기 기능이 있는 건 좋지만, 작성 페이지까지 넘어와서 이 여정을 시작하진 않을 것 같아요.” (P1) “이미 만들어 놓은 이력서가 있으니까, 여기서 새로 만들 필요가 없다고 느껴져요.” (P8) 힌트는 P8의 “여기서 만들 필요가 없다”는 말이었습니다. 우리는 기존 이력서를 그대로 불러올 수 있도록 설계했는데, 사용자는 새로 작성하는 기능으로 인지하고 진입 자체를 포기한 셈입니다. 진입한 4명 중 3명이 긍정적으로 반응했지만, 모두 조건을 달았습니다. 매칭률이 70%나 100%처럼

  2026년 11월 3일

• 채용 담당자의 업무는 어디서 시작될까?

  WORXPHERE 잡코리아 기업회원 GNB 개편기 안녕하세요, JK HC 프로덕트 디자이너 김정민, 김민주입니다. 지난 8월, 잡코리아 기업회원 서비스의 상단 내비게이션(GNB)을 개편했습니다. 기업회원 서비스의 메뉴는 오랜 기간 기능과 상품이 추가되면서 함께 확장되어 왔습니다. 제공하는 기능은 다양해졌지만, 그만큼 사용자는 필요한 업무를 어디서 시작해야 할지 점차 알기 어려워졌습니다. 저희는 이 문제를 해결하기 위해 기존 메뉴 구조와 실제 사용 데이터를 살펴보고, 채용 담당자의 업무 흐름을 기준으로 메뉴의 역할과 분류 체계를 다시 정리했습니다. 그 결과 기존 9개 섹션을 7개의 업무 영역으로 재구성했습니다. 다만 새로운 구조를 한 번에 적용하기보다, 현재 기술 환경에서 구현 가능한 GNB 개선을 먼저 진행하고 추후 좌측 내비게이션(LNB)으로 전환할 수 있도록 단계적인 방향을 함께 설계했습니다. 이번 글에서는 메뉴의 분류 기준을 다시 세우고, 실제 적용 범위를 결정하기까지의 고민과 선택의 여정을 담았습니다. 01. 메뉴 수보다 중요했던 분류 기준 기존 GNB는 9개 섹션, 약 50개의 메뉴로 구성된 메가메뉴 구조였습니다. 문제는 메뉴의 수 자체보다, 사용자가 자신의 업무에 필요한 메뉴를 빠르게 찾기 어려운 분류 구조에 있었습니다. 업무, 상품, 콘텐츠, 설정 등 성격이 다른 메뉴가 같은 위계에 놓여 있었는데요, 매일 사용하는 공고·지원자 관리와 마케팅 메뉴가 나란히 노출되고, 공고 등록과 관리, 상품 이용내역처럼 하나의 업무 흐름에서 이어지는 기능도 여러 위치에 흩어져 있었습니다. 반면 기업회원의 실제 업무는 공고를 등록하고, 지원자를 검토하고, 필요한 인재를 찾는 일련의 흐름으로 이어집니다. 메뉴 역시 이러한 업무의 흐름을 따라 필요한 기능의 시작점을 쉽게 찾을 수 있어야 했습니다. 따라서 메뉴 수를 줄이기에 앞서, 사용자가 이해할 수 있는 일관된 분류 기준을 세우는 것을 핵심 과제로 삼았습니다. 02. 데이터로 확인한 핵심 업무의 집중도 메뉴 구조를 바꾸기 전, 실제 사용 패턴을 먼저 확인했습니다. 최근 3개월간의 GA 데이터를 살펴보니, 클릭 수가 가장 많은 3개 메뉴가 전체 메뉴 클릭의 78.9%를 차지했습니다. 클릭 수가 많은 5개 메뉴까지 넓히면 그 비중은 94.4%에 달했습니다. 약 50개의 메뉴가 있지만, 실제 사용은 일부 핵심 메뉴에 집중되어 있음을 알 수 있었죠. 사용자가 어떤 메뉴를 통해 업무를 시작하는지도 살펴봤습니다. 1주일간의 이동 경로를 분석한 결과, 공고·지원자 관리를 통해 진입한 비율이 75.23%로 가장 높았습니다. 또한 해당 메뉴에 진입한 뒤에도 사용자당 2.06~2.53회의 클릭이 발생해, 하나의 업무 영역 안에서 탐색과 행동이 이어지는 패턴을 확인할 수 있었습니다. 물론 이 데이터만으로 사용자가 구체적으로 어떤 작업을 수행했는지까지 단정할 수는 없습니다. 다만 사용이 일부 핵심 업무에 집중되어 있고, 진입 이후에도 해당 영역 안에서 여러 행동이 이어진다는 점은 확인할 수 있었습니다. 이를 바탕으로 자주 사용하는 업무로 빠르게 진입하고, 그 안에서 필요한 기능을 이어서 사용할 수 있는 구조를 설계 방향으로 정했습니다. 03. 업무를 중심으로 세운 3가지 원칙 저희는 1뎁스 메뉴를 여러 기능이 나열된 곳이 아니라, 사용자가 지금 하려는 업무를 선택하는 시작점으로 정의했습니다. 공고를 관리하고, 지원자를 검토하고, 새로운 인재를 찾는 것처럼 채용 담당자가 하려는 업무에 따라 메뉴를 선택하고, 그 안에서 필요한 기능을 이어서 사용할 수 있는 구조를 만들고자 했습니다. 이를 기준으로 메뉴를 구성하는 3가지 원칙을 세웠습니다. 1. 1뎁스 메뉴는 업무의 시작점을 안내한다 1뎁스 메뉴에서는 ‘공고를 관리할지’, ‘지원자를 검토할지’, ‘인재를 찾을지’처럼 지금 하려는 업무를 빠르게 선택할 수 있도록 했습니다. 세부 기능은 2뎁스 메뉴와 본문에 배치해, 업무 영역에 진입한 뒤 필요한 작업을 이어갈 수 있도록 구성했습니다. 2. 핵심 업무와 계정·이용 정보를 구분한다 공고 관리, 지원자 관리

  2026년 10월 21일

• Batch Runner 를 만들다 (Event-Driven + Scheduled Batch 아키텍처)

  WORXPHERE 통합 서버에서 하이브리드 아키텍처로의 진화 [Batch Runner] 들어가며 잡코리아 메인 페이지에서는 다양한 형태의 CPT(Cost Per Time) 상품을 제공하고 있습니다. 주문 상품, 테마관, 슈퍼기업관 등 각기 다른 특성을 가진 상품들이 사용자에게 노출되는데요. 이러한 상품들의 데이터를 조회하고 HTML 데이터를 생성하는 작업은 초기에 Windows 스케줄러를 통해 5분마다 배치 API를 호출하고, 같은 서버에서 사용자 서비스도 함께 제공하는 방식으로 구현되어 있었습니다. 하지만 서비스가 성장하면서 개선이 필요한 부분들이 명확해졌습니다. 매번 전체 데이터를 조회하는 Full Scan의 부담, 서비스 서버와 배치 서버의 분리 필요성, 트래픽 증가에 대한 탄력적 대응의 어려움 등이었습니다. 이 글에서는 초기 배치 시스템을 개선하고, Event-Driven + Scheduled Batch 하이브리드 아키텍처로 어떻게 진화시켰는지, 그 과정에서의 의사결정과 구현 방식을 소개하겠습니다. 개선이 필요했던 이유 초기 구조 초기 구조는 API 서버와 배치 처리가 하나로 통합된 서버에서, Windows 스케줄러를 통해 5분마다 배치 API를 호출하여 모든 CPT 상품 데이터를 Full Scan으로 조회하고 HTML 데이터를 생성하는 방식이었습니다. [Windows 스케줄러] → (5분마다) → [통합 서버] ├─ 배치 API 호출 ├─ Full Scan 데이터 조회 ├─ HTML 데이터 생성 └─ 사용자 요청 처리 초기 구조의 강점 구현이 단순함: 매번 전체 데이터를 조회하기 때문에 실패해도 다시 실행하면 됨 데이터 정합성: 항상 최신 상태의 전체 데이터를 기준으로 처리 빠른 출시: 단순한 구조로 초기 서비스를 빠르게 런칭할 수 있었음 개선이 필요했던 포인트 서비스가 성장하면서 다음과 같은 개선 포인트가 명확해졌습니다. 비효율적인 조회 방식: 변경되지 않은 데이터까지 매번 Full Scan으로 조회하여 불필요한 DB 부하가 발생했습니다 서버 역할 분리 필요: 배치 처리 서버와 사용자 서비스 서버가 같은 서버이다 보니, 배치 장애 발생 시 서비스 전체에 영향을 줄 수 있었습니다 탄력적 확장의 어려움: 트래픽 증가 시 배치 처리와 서비스 처리를 독립적으로 스케일링하기 어려웠습니다 배치 윈도우 초과: 주문이 몰리는 날에는 5분 배치 주기 내에 데이터 처리를 완료하기 어려워 지연이 누적되었습니다 전환의 계기 서비스가 성장하면서 배치 처리와 사용자 서비스의 분리 필요성이 더욱 명확해졌습니다. 또한 주문이 많은 날에는 주문 데이터를 빠르게 처리해야 한다는 요구사항이 강해졌습니다. 기존 Full Scan 방식으로는 지연이 발생해 처리가 어려웠습니다. 새로운 아키텍처 설계 요구사항 문제를 해결하기 위해 새로운 아키텍처가 갖춰야 할 요구사항을 정리했습니다. 서비스 독립성 : 배치 서버 장애가 사용자 서비스에 영향을 주지 않아야 함 탄력적 확장 : 트래픽 증가 시 API 서버만 스케일 아웃 가능해야 함 실시간 반영 : 주문 상품은 결제 즉시 메인에 노출되어야 함 효율적인 조회 : 전체 데이터가 아닌 변경된 데이터만 조회해야 함 데이터 유실 방지 : 서버 장애 시에도 처리할 데이터가 유실되지 않아야 함 중복 방지 : 동일한 데이터가 중복 처리되어서는 안 됨 변경된 아키텍처 새로운 구조는 배치 서버, Data Express, Display API 서버로 역할을 분리하고, 주문 상품은 Kafka Event로 실시간 처리하며, 테마관/슈퍼기업관은 스케줄 기반으로 Full/Incremental 처리하는 방식으로 설계되었습니다. 새로 변경된 아키텍처 BatchRunner 모든 배치를 동일한 방식으로 처리할 필요는 없다. 상품 특성에 맞는 최적의 처리 방식을 선택하자. 왜 하이브리드 구조인가? 모든 상품을 동일한 방식으로 처리하지 않고, 상품 특성에 따라 서로 다른 처리 방식을 선택한 이유는 명확합니다. 주문 상품 → Event-Driven (Kafka) 주문 상품은 사용자가 결제하는 순간 주문 이벤트가 발생하므로, 이를 즉시 처리

  2026년 10월 8일

• Outbox Table에 PostgreSQL Daily Partitioning 적용하기

  JOBKOREA X ALBAMON pg_partman, pg_cron을 활용한 Outbox Table Partitioning 적용기 안녕하세요. 공통플랫폼개발팀 김성훈입니다. 🐥 입사한지 이제 막 6개월이 넘어가는 시점에 기술 블로그를 작성하려고 하니 감회가 새롭네요. 🥳 최근 프로젝트에서 Outbox Pattern을 사용하면서 PostgreSQL(이하 PG) Daily Partitioning을 진행했습니다. 이 과정에서 어떤 고민이 있었고, 어떻게 파티셔닝을 적용했는지에 대해 다음과 같은 순서로 공유드리도록 하겠습니다. 기존 보일러플레이트 Outbox Pattern 구조 (Transactional Outbox Pattern) PG Partitioning을 수행한 배경 Outbox Table에 파티셔닝 적용하기 pg_partman, pg_cron을 사용하여 파티셔닝 테이블 관리 자동화하기 마무리 1. 기존 보일러플레이트 Outbox Pattern 구조 저희 잡코리아는 각 프로젝트의 템플릿인 ‘보일러플레이트' 기반으로 프로젝트를 구성하고 있습니다. (관련 내용은 아래 포스팅에 있습니다.) 보일러플레이트 도입기, 그런데 이제 KLiK을 곁들인 따라서, 저희의 신규 프로젝트 역시 보일러플레이트를 기반으로 구성을 진행했었습니다. 기존 보일러플레이트에는 Event를 사용할 때 Transactional Outbox Pattern 이 적용된 상태였습니다. (Transactional Outbox Pattern을 다루는 글은 아니기 때문에 해당 패턴에 대한 설명은 생략하고 넘어가도록 하겠습니다.) 보일러플레이트 Transactional Outbox Pattern 도식화 Boilerplate Transactional Outbox Pattern 보일러플레이트의 지원 도메인 (Apply) 기준으로 현재 Event Produce & Consume Flow는 다음과 같습니다. Application 지원 도메인 이벤트 발생 하나의 Transaction으로 Apply CUD & Outbox Table Insert Transaction Log Tailing 방식으로 Debezium을 사용하여 CDC를 통해 Message Relay Debezium에서 Kafka Message Publish로 Event Produce 2. PG Partitioning을 수행한 배경 그렇다면 위의 Outbox 구조에서 왜 Partitioning이 필요했을까요? 보일러플레이트를 기반으로 신규 프로젝트를 구성했을 때, 이미 운영중인 다른 서비스들에서 Outbox Table을 보고 다음과 같은 개선점을 발견하게 되었었습니다. 많은 이벤트 발생으로 인해 Outbox Table에 너무 많은 데이터가 쌓였다. 따라서 지속적으로 Outbox Table에 쌓이는 데이터를 처리해야 한다. Transactional Outbox Pattern 사용 시에는 이벤트가 발생할 때마다 Outbox 테이블에 Row가 추가됩니다. 현재 약 6개월간 운영한 다른 서비스의 Outbox에 쌓인 Row는 약 2억건이었습니다. (WOW! 🤯 ) 하나의 서비스에서 이벤트가 발생하는 빈도는 너무나도 잦기 때문에 Outbox에 쌓인 Row 수 또한 많은 것을 확인할 수 있었습니다. 이러한 상황을 해결하기 위해 고려한 설계 방안은 다음과 같습니다. 데이터 삭제 주기를 두고 주기마다 쌓인 Row Delete DB 파티셔닝 후 주기마다 파티셔닝 테이블 삭제 이미 글에서 스포가 되었지만 결론적으로는 파티셔닝 방법을 택하게 되었습니다. 첫 번째 방법은 다음과 같은 이유로 선택하지 않게 되었습니다. 데이터 삭제주기마다 Outbox Table 쌓인 Row Delete 처음에는 간단하게 생각하여 해당 방법으로 진행하려고 했으나, PG의 Vaccum 동작 Side-Effect로 인해 전체 DB 부하가 발생할 위험이 있어 해당 방법을 사용하지 않았습니다. ※ PG Vaccum? PG의 Vaccum은 PG의 Dead Tuple 스토리지 공간을 회수하는 작업입니다. | VACUUM reclaims storage occupie

  2026년 9월 30일

• JOBKOREA HReka 26 Conference

  WORXPHERE Project Overview HReka는 기업 담당자와 HR 실무자를 위한 잡코리아의 B2B 브랜드입니다. HR과 Eureka를 결합한 이름처럼, 빠르게 변화하는 HR 환경에서 질문의 본질을 발견하고 새로운 관점을 얻는 ‘유레카’의 순간을 만들고자 했습니다. 브랜드팀은 HReka의 워드마크와 그래픽 모티브를 설계하고, 이를 바탕으로 브랜드 전반의 시각 언어를 구축했으며, 이어 HReka 26 컨퍼런스의 키비주얼과 다양한 온·오프라인 애플리케이션까지 디자인하며, 브랜드 경험이 하나의 흐름으로 이어지도록 완성했습니다. HReka Identity Design JOBKOREA B2B CONTENT BRAND HReka Logo Design HReka 로고는 HR과 Eureka(유레카) 의 결합 의미를 담은 워드마크형 로고입니다. 정교한 지오메트릭 조형을 기반으로 한 타이포그래피를 통해 신뢰감 있고 전문적인 브랜드 인상을 구축하며, 기본 텍스트 구조 안에 최소한의 포인트를 더해 흐레카만의 정체성을 강화했습니다. [ ! ] 포인트는 유레카의 [ A-HA! ] 모먼트를 상징하며, 질문에서 시작해 인사이트로 확장되는 흐레카의 콘텐츠 경험을 나타냅니다. 과도한 장식 없이 간결한 형태로 설계되어 뉴스레터와 온·오프라인 이벤트 등 다양한 B2B 접점에서 일관된 브랜드 이미지를 전달합니다. HReka Graphic Motif Expansion HReka 2026 Conference Concept ‘ HReka 26 Conference ’는 AI로 인해 변화하고 있는 HR의 흐름 속에서 더 나은 선택을 통해 승리를 만들어가는 과정을 이야기하는 B2B 컨퍼런스입니다. HReka의 핵심 그래픽 모듈인 Insight Block은 이번 컨퍼런스에서 승리를 향해 나아가는 트랙으로 확장합니다. 사각형을 길게 뻗은 다채로운 색상의 레인으로 확장하여, 서로 다른 속도와 경로로 달려가는 기업의 HR 여정을 표현했습니다. 트랙 끝에 위치한 빛인 Insight Block은 변화를 읽고 새로운 승리 공식을 발견하는 순간을 상징하며, HReka 26 만의 역동적이고 진취적인 컨퍼런스 경험을 완성합니다. HReka 2026 Conference Design Keywords Key Visual 컨퍼런스의 메시지를 매체별로 유연하게 전달하기 위하여 메인 키비주얼과 서브 키비주얼을 함께 개발했습니다. 메인 키비주얼은 트랙이 하나의 Insight Block으로 수렴하는 원근감 있는 장면을 통해, 승리를 향해 나아가는 컨퍼런스의 에너지와 속도감을 집중적으로 보여줍니다. 서브 키비주얼은 트랙의 색과 리듬을 수평 그래픽으로 간결하게 재해석해, 정보량과 비율이 다른 온·오프라인 매체에서도 일관된 인상을 유지하도록 했습니다. https://medium.com/media/7f5d07ef036f3e5095a57e06d7090911/hrefhttps://medium.com/media/5c0d40940c8ae3c5cb323aabbd521b24/href Application HReka 26 컨퍼런스 키트는 웰컴 페이퍼, 브랜드 택, 볼펜, 노트 등 참가자가 컨퍼런스 내용을 기록하고 기억할 수 있는 구성품으로 제작했습니다. 각 키트에는 키비주얼을 적용해 ‘Win Your HR Race’의 트랙 모티프와 브랜드 경험을 일관되게 전달했습니다. Space Insight Block에서 출발한 트랙 모티프는 하나의 키비주얼에 머무르지 않고, 공간·인쇄물·웹·영상 전반으로 확장되어 HReka 26 현장에서 하나의 브랜드 경험으로 구현되었습니다. JOBKOREA HReka 26 Conference was originally published in worxphere-tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

  2026년 9월 18일

• 지원자 관리(ATS), 익숙함은 지키고 경험은 확장하다

  WORXPHERE 하이어링 센터에서 시작해 잡코리아로 확장한 지원자 관리 개편기 안녕하세요, 프로덕트 디자이너 김정민입니다. 이번 글에서는 하이어링 센터에서 시작해 잡코리아까지 이어진 지원자 관리 개편 과정을 소개합니다. PM·엔지니어와 함께 전반적인 제품 경험을 설계하며, 익숙한 서비스를 새롭게 바꾸기 위해 어떤 고민과 선택이 있었는지, 그 과정을 함께 봐주시면 좋겠습니다. 01. 문제 정의 가장 많이 쓰는 화면에서 발생하는 채용 경험의 단절 공고 등록 이후, 잡코리아에서 기업 회원이 가장 많이 방문하는 화면이 어디일까요? 바로 ‘지원자 관리’ 화면입니다. 최근 6개월 기준, 기업 서비스 전체 PV의 약 90%가 이 화면에서 발생할 만큼 사용 빈도가 높은 핵심 영역이죠. 하지만 핵심 화면임에도 불구하고, 기존의 지원자 관리는 지원자 목록 검색과 이력서 열람 정도의 기초적인 기능만 제공하고 있었습니다. 채용 담당자는 이력서를 확인한 이후의 채용 과정을 플랫폼 내에서 이어가기 어려웠고, 일부 업무를 외부 도구에 의존해야 했습니다. 이러한 채용 업무의 단절을 개선하고 플랫폼 내 경험을 완결 짓기 위해 채용 여정(ATS) 개편을 진행했습니다. 02. 개편 방향 하이어링 센터에서 시작한 ATS 개편을 잡코리아로 확장 이번 지원자 관리(ATS) 개편은 하이어링 센터에 구축한 지원자 관리 경험을 기존 잡코리아 기업 서비스로 확장하는 작업이었습니다. 하이어링 센터의 구조와 사용 경험을 기본 뼈대로 가져오되, 기존 잡코리아에서 제공하던 핵심 기능과 데이터를 통합해야 했죠. 단순히 새로운 화면을 옮기는 것이 아니라, 기존 사용자의 익숙한 업무 방식과 기능을 유지하면서 잡코리아의 지원자 관리 경험 전체를 하이어링 센터의 ATS 구조로 전환하는 과정이었습니다. 03. 데이터 분석 단순 마이그레이션을 넘어선 UX 개선의 필요성 개편에 앞서 최근 1년간 기업 회원의 활동 데이터를 살펴봤습니다. 그 결과, 전체 지원 건수 중 실제 채용 단계가 변경된 비율은 8.4%에 불과했는데요, 칸반 뷰, 팀 협업, 평가 도구 등을 제공하는 나인하이어의 채용 진행률이 29%인 것과 비교하면 약 3.5배 낮은 수준이었습니다. (*잡코리아: 2024.9~2025.9 / 나인하이어: 2026.3~2026.5 기준) 더 주목한 것은 결과 통보율이었는데요, 전체 지원자의 약 94%가 채용 결과를 통보받지 못하고 있었습니다. 두 지표를 함께 살펴보며, 플랫폼 안에서 채용 프로세스를 이어가기 어려운 구조가 낮은 채용 진행률과 결과 통보율에 영향을 미치고 있을 것이라는 가설을 세웠습니다. 이는 단순히 기업 회원의 업무 효율에 그치는 문제가 아니라, 장기적으로 지원자의 구직 경험과 플랫폼에 대한 신뢰에도 영향을 줄 수 있다고 판단했습니다. 04. 설계 원칙 파편화된 채용 업무를 하나의 흐름으로 연결 기존 화면을 분석해 보니, 버튼 배치나 레이아웃 같은 개별 UI 요소보다 채용 업무의 흐름이 곳곳에서 끊긴다는 문제점에 있었습니다. 대표적인 사례가 다중 선택 기능이었습니다. 여러 지원자를 선택하면, 목록과 액션 패널이 화면 양쪽으로 떨어져 있어 시선 이동이 잦았고, 뷰포트가 좁아지면 우측 패널이 화면 밖으로 밀려나는 문제도 있었습니다. 정보를 확인하는 과정에서도 비슷한 문제가 있었는데요, 과거 면접 제안 내역을 확인하려면 다시 ‘면접 제의’ 버튼을 눌러야 하는 구조였습니다. 정보를 조회하기 위해 실행 버튼을 거쳐야 하는 구조로 인해 조회와 실행의 맥락이 뒤섞여 있었고, 사용자가 현재 상태와 다음 행동을 직관적으로 파악하기 어려웠습니다. 결국 필요한 것은 개별 UI를 보기 좋게 다듬는 것이 아니라, 이력서 검토부터 심사, 커뮤니케이션, 일정 조율까지 각 채용 업무가 맥락을 잃지 않고 자연스럽게 이어지는 흐름을 만드는 것이었습니다. 이를 이번 개편의 핵심 설계 목표로 삼았습니다. 05. 경험의 확장 리스트의 익숙함을 유지한 듀얼 뷰와 벌크 액션 지원자 관리는 기업 회원의 사용 빈도가 높은 핵심 메뉴입니다. 그만큼 인터페이스의 급격한 변화는 기존 사용자의 업무 루틴을 깨뜨리고

  2026년 9월 17일

• [4편] 리뷰피드는 정말 발견의 공간이 될 수 있을까?

  WORXPHERE 12명의 사용자와 함께 가설을 깨고 다시 세운 이야기 안녕하세요, 저는 잡플래닛 프로덕트팀 프로덕트 디자이너 최경미입니다. 이번 글은 우리 팀이 ‘검색해야만 닿던 리뷰가, 사용자가 자연스럽게 발견하고 머무는 공간이 될 수 있을까?’라는 질문을 안고 12명의 사용자를 만난 뒤, 그것이 모두에게 통하지는 않는다는 걸 직접 확인한 이야기입니다. 짧게 말하면, 우리가 세운 가설과 사용자가 실제로 원하는 모습은 다를 수 있다는 걸 다시 배운 사흘이었습니다. 확인해보고 싶었던 것 “리뷰를 보려면 무조건 검색 밖에 없다” 먼저 데이터를 살펴봤습니다. 웹·앱 사용자 중 검색을 통해 기업 페이지에 도달한 비율은 각각 41.6%, 27.5%에 불과했습니다. 그렇다면 나머지 사용자는 어디에서, 어떻게 기업 페이지로 들어오고 있을까요? 재방문이 이어지지 않는 구조 MAU의 88%가 기업 페이지를 방문하지만, 2회 이상 방문한 사용자는 40%로 줄어듭니다. 일반 리뷰 조회도 58%에서 2회 이상은 31%에 그쳤습니다. 낮은 리뷰 작성률 활성 사용자 기준 리뷰 작성 완료율은 약 8%, 신규 가입 후 14일 내 작성 완료율도 9% 수준이었습니다. 저조한 재작성률 리뷰 작성 후 60일 내 다시 작성한 비율은 11.4%에 그쳤습니다. 이 숫자들을 한 줄로 요약하면 아래와 같습니다. 사용자는 잡플래닛에 들어오지만, 다시 방문하거나 직접 참여하는 단계까지는 좀처럼 이어지지 않고 있었습니다. ‘역구조 탐색’이라는 큰 가설 “검색이 아니라, 리뷰를 통해 기업을 발견할 수 있다면?” 지금까지의 잡플래닛은 검색 → 기업 페이지 → 리뷰 구조였는데, 이 흐름을 한번 뒤집어보기로 했습니다. 리뷰 피드 → 리뷰 발견 → 궁금해진 기업으로 이동 이를 검증하기 위해 5개의 가설을 세웠습니다. 역구조 탐색 리뷰를 먼저 노출하면 기업 페이지 혹은 리뷰 상세로 이동할까? 소비 지속성 탭·필터로 맥락별 리뷰를 연속 탐색할 수 있게 하면, 소비가 이어질까? 작성 전환 (권한 있는 경우) 유도 질문이나 면접 인사이트가 있으면 작성으로 이어질까? 작성 전환 (권한 없는 경우) 블라인드 vs 더보기 UI 중 어떤 형태가 더 궁금증을 유발할까? 면접 질문 탐색 면접 질문만 모아보면 더 잘 찾을 수 있을까? 피그마 프로토타입이 아닌 ‘진짜 프로토타입’으로 5개의 가설을 검증하려면 사용자가 실제로 클릭하고, 스크롤하고, 탭을 오가는 경험이 필요했습니다. 정적인 화면만으로는 부족했습니다. 그래서 실제로 동작하는 React 프로토타입을 만들고 GitHub Pages로 배포했습니다. AI를 활용해 인터랙션을 구현한 덕분에, 참여자들은 진짜 서비스처럼 화면을 탐색할 수 있었습니다. 이 경험의 밀도가 UT의 품질을 크게 좌우했습니다. UT는 내부 리허설 3명과 외부 참가자 9명, 총 12명을 대상으로 진행했습니다. 외부 참가자는 이직이 급한 사용자 7명과 그렇지 않은 사용자 2명으로 구성했고, 신입부터 10년 차까지 디자이너·UX 리서처·영업·연구개발·건축시공 등 다양한 직군을 만났습니다. 역구조 탐색은 작동했을까요? ‘역구조 탐색’이라는 큰 가설 아래, 어떤 형태로 보여주느냐에 따라 결과는 완전히 달랐습니다. 가설 1. 역구조 탐색 리뷰를 먼저 노출하면, 사용자는 리뷰를 통해 기업을 탐색하게 될 것이다 가설 1–1. 리뷰 원문 카드 → 9명 중 0명 가설 1–2. 리뷰 요약 타이틀 카드 → 9명 중 5명 가설 1–1. 리뷰 원문을 카드로 노출하면, 사용자는 내용을 읽다가 해당 기업이 궁금해져 기업명을 통해 기업 페이지로 이동할 것이다.가설 1–2. 리뷰의 한 줄 요약을 카드로 노출하면, 사용자는 제목만 보고도 해당 기업이 궁금해져 리뷰 상세 페이지로 이동할 것이다. 피드를 본 사용자 누구도 리뷰 원문을 읽다가 기업 페이지로 넘어가지 않았습니다. (가설 1–1) 뭘 놓치고 있었을까요? UT 전에는 하나의 피드 안에서 리뷰를 발견하고 소비하도록 만들 수 있다고 생각했습니다. 하지만 실제 사용자에게 리뷰는 새로운 기업을 찾는 콘텐츠가 아니라, 이미 알고 있는 회사를 판단하고 검

  2026년 9월 1일

• [3편] 홈은 ‘탐색 시작점’이 아닌 ‘검색 시작점’이었습니다

  WORXPHERE 12명 모두, 홈을 그냥 지나쳤습니다 그래서 홈을 검색창 중심으로 다시 만들었습니다 (3편) 2편에서는 홈·공고·지원·리뷰 네 프로젝트의 사용자 테스트를 하나의 70분 세션으로 합쳐 검증했습니다. 이번 편부터는 그 테스트에서 각 영역이 무엇을 발견했는지 풀어봅니다. 첫 번째는 홈입니다. 단 한 명도, 홈에 머물지 않았습니다 저는 잡플래닛 프로덕트 팀에서 리드 프로덕트 디자이너로 일하고 있는 최지원입니다. 이번 분기에는 홈과 채용 공고 메인을 맡았습니다. 잡플래닛은 기업 리뷰와 연봉, 채용 정보를 제공하는 서비스입니다. 그중 홈은 앱을 켰을 때 가장 먼저 마주하는 화면이고요. 2편에서 이야기했듯, 이번 분기에는 참가자 12명과 70분씩 사용자 테스트를 진행했습니다. 참가자들에게 잡플래닛의 홈 화면을 보여주고, 어떻게 탐색하는지 지켜봤어요. 결과는 명확했습니다. 12명 모두 홈의 콘텐츠를 지나쳐 곧바로 검색하거나 다른 메뉴로 이동했습니다. 자의로 홈에 머문 사람은 한 명도 없었습니다. 한 가지 행동이 더 눈에 띄었습니다. 리뷰, 공고 같은 메뉴를 이리저리 오가며 둘러보는 사람도 없었어요. 사용자에게 메뉴는 ‘무엇이 있는지 둘러보는 곳’이 아니라, 원하는 곳으로 바로 이동하는 지름길에 가까웠습니다. 홈은 저희가 한 분기 동안 가장 공들여 다듬은 화면 중 하나였습니다. 하지만 정작 사용자에게 홈은 머무는 곳이 아니라, 목적지로 가기 위해 지나치는 곳이었습니다. 우리가 세운 세 가지 가설은, 하나도 맞지 않았습니다 인터뷰를 설계할 때 저희는 홈에 대한 가설 세 가지를 설정했습니다. ‘이렇게 만들면 사용자가 이렇게 움직일 것’이라는 기대였어요. 가설 1. 홈 상단에 ‘사용자 직군에 맞는 추천’이나 ‘관심 기업 바로가기’를 놓으면, 사용자가 홈에서부터 탐색을 시작할 것이다. 가설 2. 다시 방문했을 때 ‘팔로우한 기업의 마감 임박 공고’나 ‘최근 본 기업’을 함께 보여주면, 사용자가 홈에서 탐색을 이어갈 것이다. 가설 3. 각 메뉴 탭에 들어가자마자 상황에 맞는 콘텐츠가 바로 뜨면, 사용자가 메뉴 탭을 지름길이 아니라 탐색 흐름의 일부로 쓸 것이다. 판정 기준은 2편에서 정한 그대로입니다. 참가자 12명 중 9명 이상이면 검증, 5~8명이면 조건부, 4명 이하면 가설 기각으로 봤어요. 세션이 모두 끝난 뒤, 결과는 이렇게 정리됐습니다. 세 가지 모두 ‘이 정도면 당연히 되겠지’ 하고 봤던 것들입니다. 그런데 사용자는 그중 어느 쪽으로도 움직이지 않았습니다. 사용자에게 잡플래닛은 ‘리뷰 보는 도구’였습니다 12명이 똑같이 움직인 데는 이유가 있었습니다. 사용자들의 발화에서 그 이유가 또렷하게 드러났어요. “보통 잡플래닛 들어오면 바로 궁금한 회사부터 검색하니까, 화면 아래로는 잘 안 내려가는 것 같아요.” “홈에 뭐가 있는지 잘 몰랐던 것도 사실이에요. 여긴 기업 리뷰 보러 오는 거죠.” 사용자는 잡플래닛을 ‘이것저것 둘러보는 콘텐츠 플랫폼’이 아니라 ‘특정 목적을 위한 도구’로 여기고 있었습니다. 도구에는 몸에 밴 사용 순서가 있죠. 잡플래닛에서 그 순서는 ‘검색창에 회사 이름을 치고, 리뷰를 본다’였습니다. 이 습관은 생각보다 훨씬 단단했습니다. 저희가 홈에 ‘리뷰 인사이트’라는 새 기능을 만들어 뒀는데도, 7명 중 4명은 관심을 보이지 않았고, 어떤 기능인지 알아보려는 행동도 하지 않았습니다. 프로토타입 예시 “위쪽 리뷰 인사이트는 저한테는 의미가 없고, 아래 기업 리뷰 쪽이 주제별로 색이 달라서 눈에 띄었어요.” “어? 잡플래닛이 채용 공고도 해요?” 여기서 나온 결론은 단순했습니다. 사용자에게 ‘잡플래닛은 원래 이런 서비스예요’라고 새로 가르치기보다, 이미 몸에 익은 방식을 더 빠르게 받아주는 편이 나았습니다. 숫자도 같은 이야기를 하고 있었습니다 사용자를 직접 지켜보며 발견한 행동은, 기존 클릭 데이터에서도 그대로 나타났습니다. 메뉴 탭 클릭의 64%가 ‘기업 리뷰 보기’였습니다. 사용자는 들어오자마자 원하는 정보로 바로 이동하고 있었습니다. 홈 탭 클릭은 0.4%(모바일 기준)에 그쳤습니다. 홈은

  2026년 8월 21일

• [2편] 코드 못 짜던 디자이너가, 네 프로젝트를 깃허브 저장소 하나로 합친 기록

  WORXPHERE 잡플래닛 네 프로젝트의 사용자 테스트를 한 저장소에서, 한 참가자와 70분 동안 진행한 기록 (2편) 1편에서는 이직이 얼마나 급한지, 정보를 얼마나 깊이 찾는지에 따라 사용자의 행동이 달라진다는 걸 확인했습니다. 이번에는 그 차이가 실제 화면에서도 나타나는지 직접 만나 확인해봤습니다. 네 프로젝트의 테스트 도구를 직접 만들고, 가설을 한 번에 검증한 기록입니다. 확인하고 싶은 영역은 네 가지였습니다 저는 잡플래닛 프로덕트 팀에서 리드 프로덕트 디자이너로 일하고 있는 최지원입니다. 이번에 저희가 하려던 건 사용자 테스트, 줄여서 UT였습니다. 실제 사용자에게 화면을 써보게 하고, 어디서 헤매는지 지켜보며 출시 전에 “이거 정말 쓸 만한가?”를 확인하는 과정이죠. 올해 1분기, 저는 두 명의 팀원들과 홈, 공고, 지원, 리뷰 네 프로젝트를 나눠 진행하고 있었습니다. 마침 각 프로젝트마다 실제 사용자에게 검증해보고 싶은 지점들이 있었습니다. 홈: 새 홈 화면이 탐색의 출발점으로 잘 작동하는가 공고: 새 공고 카드가 필요한 정보를 보기 좋게 제공하는가 지원: AI로 여러 곳에 한 번에 지원하는 흐름을 자연스럽게 받아들이는가 리뷰: 새 리뷰 모아보기 페이지가 여러 리뷰를 탐색하는 데 도움이 되는가 문제는 네 프로젝트를 따로 테스트하면 준비와 운영도 네 번 반복된다는 것이었습니다. 참가자도 그만큼 많이 필요했고, 세 명이 감당하기에는 부담이 컸어요. 무엇보다 사용자는 서비스를 프로젝트 단위로 경험하지 않습니다. 홈에서 공고를 찾고, 지원하고, 리뷰를 확인하는 과정이 하나의 흐름으로 이어집니다. 그런데 테스트만 프로젝트별로 나누면 정작 그 흐름을 볼 수 없었어요. 사용자는 하나의 흐름으로 움직이는데, 우리는 왜 검증을 나눠서 하고 있었을까요? 그래서 네 개의 테스트를 하나로 합치기로 했습니다 물론 테스트를 하나로 합치는 만큼 걱정되는 지점도 있었습니다. 회의에서 가장 먼저 나온 건 이런 질문들이었어요. 70분 동안 진행되는 테스트에 사용자가 끝까지 집중할 수 있을까? 뒤로 갈수록 답변의 밀도가 떨어지지는 않을까? 각 프로젝트마다 확인하고 싶은 게 다른데, 어떤 시나리오를 먼저 보여줘야 할까? 한 사람이 네 개의 화면을 연달아 보면, 앞에서 본 경험이 뒤의 평가에 영향을 주지는 않을까? 그럼에도 네 개의 테스트를 하나로 합치기로 했습니다. 이유는 분명했어요. 프로젝트를 따로 테스트하면 각자의 화면 안에서만 문제를 볼 수 있지만, 하나로 합치면 같은 사용자 한 명의 흐름 안에서 네 프로젝트를 함께 볼 수 있기 때문입니다. 예를 들어 한 사용자가 홈에서는 별다른 탐색 없이 곧장 검색으로 넘어가고, 공고를 보다가 자연스럽게 리뷰를 확인하러 갈 수 있습니다. 이렇게 하나의 테스트 안에서 행동이 이어지면, 각 프로젝트는 서로 다른 사용자의 반응이 아니라 같은 사용자의 흐름을 바탕으로 판단할 수 있게 됩니다. 따로 테스트했다면 각자의 화면 안에서 “여기서는 잘 됐는데요”라고 끝났을지도 모릅니다. 하지만 하나로 합치면 한 화면에서의 선택이 다음 화면의 행동으로 어떻게 이어지는지까지 볼 수 있었습니다. 누구를, 어떤 순서로 볼지 정했습니다 네 개의 테스트를 합친 뒤에는 누구와 테스트하고, 어떤 순서로 보여줄지 정해야 했습니다. 총 12명과 테스트했습니다 참가자는 총 12명이었습니다. 1편에서 세운 두 축 중 ‘이직이 얼마나 급한가’가 행동을 가장 크게 가르는 기준이었고, 특히 이직이 급한 사용자를 중심으로 확인했습니다. 다른 한 축인 ‘정보를 얼마나 깊이 탐색하는가’는 미리 나누지 않고, 테스트에서 실제로 어떻게 탐색하는지 보기로 했습니다. 시나리오는 두 갈래로 나눴습니다 이직이 급한 사람과 급하지 않은 사람은 홈에 들어온 뒤의 행동도 다를 거라 추측했습니다. 그래서 시나리오를 다르게 설정했습니다. 이직이 급한 사람: 홈 → 공고 → 지원 → 리뷰 이직이 급하지 않은 사람: 홈 → 리뷰 → 공고 → 지원 보는 영역은 같지만 흐름은 다르게 설계했습니다. 공고부터 보는 사람과 리뷰부터 보는 사람의 행동이 어떻게 달라지는지 확인

  2026년 8월 18일

• 끝나지 않는 루프 에이전트를 멈추기까지

  WORXPHERE 끝나지 않는 AI 에이전트 루프를 멈추기까지 React On Rails → Next.js 마이그레이션으로 시작한 루프 엔지니어링 안녕하세요. 웍스피어에서 잡플래닛 서비스를 담당하고 있는 프론트엔드 개발자 강태완입니다. 잡플래닛은 10년 넘게 운영된 서비스입니다. 오랜 시간 서비스를 운영하면서 Rails 위에 React가 붙고, 거기에 Next.js까지 들어왔습니다. 지금의 프론트엔드를 아주 단순하게 표현하면 대략 이런 구조입니다. 오래된 화면은 Rails가 렌더링하고, 그 안에서 React 컴포넌트가 동작합니다. 페이지를 이동하면 React가 들고 있던 상태도 함께 사라집니다. 한 페이지 안에서는 React를 사용하고 있지만, 페이지를 넘어 상태를 이어가기는 어렵습니다. 이전 단계의 값을 다시 전달하거나 복원하는 별도의 처리가 필요해서 페이지가 이어질수록 처리도 복잡해졌습니다. SEO도 비슷했습니다. 못 하는 건 아니지만, Rails와 React에 렌더링이 나뉘어 있다 보니 페이지마다 따로 챙겨야 할 부분이 있었습니다. 이런 불편함 때문에 지금은 오래된 Rails 페이지를 하나씩 Next.js로 옮기고 있습니다. 그런데 마이그레이션 기간이 길어질수록 또 다른 문제가 생겼습니다. 아직 안 옮긴 페이지는 Rails에 있고, 옮긴 페이지는 Next.js에 있습니다. 예를 들어 Rails와 Next.js 양쪽에서 공통으로 노출되는 상단 GNB를 수정하려면 두 프로젝트를 모두 수정해야 합니다. 한쪽만 고치면요? 당장은 아무 일도 일어나지 않습니다. 그리고 한참 뒤에 누군가 발견합니다. “어? 여기랑 저기 UI가 다른데요?” 그때 알게 됩니다. 아, 한쪽만 고쳤구나. 그래서 가능한 한 빨리 마이그레이션을 끝내는 것 자체가 이중 관리 비용을 줄이는 방법이었습니다. 문제는 옮겨야 할 페이지가 한두 개가 아니었다는 겁니다. 페이지마다 원본을 확인하고, Next.js로 구현하고, 다시 원본과 비교하는 비슷한 작업이 계속 반복됐습니다. 이 반복을 좀 줄여보고 싶어서 AI 에이전트를 사용하기 시작했습니다. 에이전트를 썼는데, 제가 더 바빠졌습니다 처음에는 단순하게 생각했습니다. “이 Rails 페이지를 Next.js로 옮겨줘.” 에이전트가 구현하면 결과를 확인하고, 다른 부분이 보이면 다시 요청했습니다. 수정이 끝나면 또 확인했습니다. 페이지 하나를 옮기는 데도 이 과정을 몇 번씩 반복해야 했습니다. 페이지가 많아지니 제가 확인해야 할 결과도 같이 늘어났고요. 에이전트를 쓰면 제가 편해져야 하는데, 제가 계속 에이전트를 감시하고 있었습니다. AI가 코드를 쓰는 속도보다 사람이 결과를 확인하는 속도가 느렸습니다. 병목은 에이전트가 아니라 사람 쪽에 있었습니다. 그러다 루프 엔지니어링에 대한 이야기를 접했고, 아이디어는 단순했습니다. 에이전트에게 사람이 매번 프롬프트하지 말고, 에이전트에게 프롬프트하는 프로그램을 만들자. 생각해보니 마이그레이션은 이 방식과 꽤 잘 맞아 보였습니다. 이미 원본 Rails 페이지가 있습니다. Next.js로 구현하고, 원본과 비교하고, 다르면 다시 고치면 됩니다. 그래서 사람이 반복하던 요청과 확인을 루프로 옮기기 시작했습니다. Workflow({ scriptPath: '.claude/workflows/rails-migration-loop.js', args: { page: 'welfare-review-write', phase: 'verify', }, }) 구현과 검증을 반복하다 보면 자연스럽게 원본에 가까워지고, 어느 순간 끝날 거라고 생각했습니다. 처음 돌려본 결과는 꽤 인상적이었습니다. 루프가 안 멈췄습니다. “더 고칠 게 있어?”라고 물으면 영원히 끝나지 않는다 첫 시도는 사실상 무한 루프였습니다. 루프에게 준 목표는 단순했습니다. “이 페이지를 Next.js로 옮겨줘.” 문제는 그다음이었습니다. 루프는 매 라운드마다 에이전트에게 “더 고칠 게 있어?”라고 물었습니다. 그러면 에이전트는 항상 고칠 것을 찾아냈습니다. “여백이 2px 정도 어색합니다.” 그걸 고치면 다음에는 타입을 조금

  2026년 8월 14일

• Worxphere Welcome Kit

  WORXPHERE 새로운 사람들에게 우리가 일하는 방식을 어떻게 전달해야 할까? 웍스피어는 새로운 이름 아래, 새로운 구성원들을 맞이했습니다. 그 시작에서 웰컴 굿즈보다 먼저 담고 싶었던 것은 HR 업계를 선도해 온 기업으로서 ‘일’에 대한 생각, 그리고 함께 일하는 방식이었습니다. 우리는 책상 앞에 앉아 있는 것만이 일이라고 생각하지 않습니다. 기록하며 생각을 열고, 동료와 차 한 잔을 나누고, 비 오는 날 먼저 우산을 건네는 것. 그 모든 순간이 웍스피어가 일하는 방식입니다. 그래서 입사 첫날 새로운 구성원이 받아 드는 것이 단순한 물건을 넘어, 이곳에서 함께 일하는 태도를 자연스럽게 보여줄 수 있기를 바랐습니다. Your Work Experience Starts Here 키트를 마주한 순간 우리는 이 키트를 처음 마주하는 순간부터 새로운 경험이 시작된다고 생각했습니다. 패키지에 담긴 문장 속에서 ‘Worxphere’를 이루는 글자를 강조해, 왜 우리의 이름이 ‘웍스피어’인지 자연스럽게 발견하고 새로운 회사에서의 첫 경험으로 이어지도록 했습니다. 일상으로 이어지는 경험 일은 거창한 순간보다, 반복되는 일상에서 만들어집니다. 매일 사용하는 물건을 통해 웍스피어가 함께 일하는 방식을 경험합니다. 노트와 펜 : 매일의 성장을 가볍게 기록해 보세요. 텀블러 : 따뜻한 차 한 잔과 함께 동료와 잠시 이야기를 나눠보세요. 마우스패드 : 손끝이 닿는 자리부터 업무의 흐름을 만들어보세요. 칫솔 살균기 : 동료와의 협업을 상쾌하게 이어가보세요. 우산 : 동료가 비를 맞을 땐 먼저 우산을 건네보세요. 양말 : 건강한 하루를 힘차게 시작해보세요. 후드티 : 소속감을 느끼며 편안하게 몰입해보세요. 스티커 : 당신만의 방식으로 일과 공간을 표현해보세요. 각각의 물건에는 저마다의 쓰임과 의미를 담았습니다. 한 번 받고 끝나는 웰컴 키트가 아니라, 일상 속에서 자연스럽게 사용하며 웍스피어가 일하는 방식을 조금씩 경험할 수 있기를 바랐습니다. https://medium.com/media/03b9c87e7ca97706c7b31c6e8fc2397a/hrefhttps://medium.com/media/719c170a41fb5e559cb957812ec95f49/href 경험을 잇는 연결 NFC 키링을 터치하면 웰컴 웹사이트가 열립니다. 각 구성품에 담긴 이야기부터 리유저블 패키지의 활용법까지, 웰컴키트의 경험은 디지털에서도 이어집니다. https://medium.com/media/fc83a194123d16417d9292b4f550b22c/href 언박싱으로 끝나지 않는 경험 웰컴키트는 언박싱으로 끝나지 않습니다. 리유저블 패키지는 새로운 쓰임을 더하며, 일상 속에서도 웍스피어의 경험을 이어갑니다. Worxphere Welcome Kit was originally published in worxphere-tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

  2026년 8월 13일

이 블로그의 주제