1. Introduction

퇴사를 하고 나서 어느덧 두 달이 조금 넘은 시점이었습니다.

처음에는 이번만큼은 쉬는 데 집중하자는 생각이 컸습니다.
그동안 계속 일해왔기도 했고, 의도적으로라도 잠깐은 숨을 고르고 싶었습니다. 하지만 학회 활동을 포함한 기존 스터디들을 이어가다 보니 생각보다 시간은 빠르게 흘렀고, 11월이 넘어가면서부터는 자연스럽게 다시 취업 준비를 조금씩 해야겠다는 생각이 들기 시작했습니다.

그렇게 면접과 과제를 병행하던 도중, 제가 속해 있는 크루 팀에서 해커톤 이야기가 나왔습니다. Sui와 Walrus 네트워크를 기반으로 한 해커톤이 열린다는 소식이었고, 팀원 중 한 분이 먼저 아이디어를 공유해주셨습니다.

사실 그 당시에는 고민이 많았습니다. 제출한 이력서 이후 과제와 면접 일정이 겹쳐 있던 시기였고, 해커톤에서는 이미 어느 정도 완성된 제품들과 경쟁하게 될 가능성도 높아 보였습니다. 무엇보다 계속해서 취업 활동에 집중해야 하는 상황에서, 해커톤에 참여하는 것이 괜히 집중력을 분산시키는 선택은 아닐지 걱정이 되었습니다.

아마도 혼자였다면 아마 쉽게 나서지 못했겠지만, 팀원 중 한 분은 오래 알고 지낸 지인이었고, 다른 분들 역시 열정이 느껴져서 함께해보고 싶다는 생각이 들었습니다.

그래서 결국 참여를 결정했습니다..!

결과적으로 이 해커톤은 크루 팀원들끼리 총 5명이서 참여하게 되었습니다. 아이디어톤은 이전에도 한두 번 참여해본 적이 있었지만, 실제로 구현까지 진행하는 해커톤은 이번이 처음이었습니다. 그래도 전면 온라인으로 진행되는 방식이라, 흔히 떠올리실 ‘한 공간에 모여 밤을 새우며 진행하는 해커톤’ 과는 조금 다른 형태로 진행되었습니다.

팀은 저와 오래 알고 지낸 지인분을 제외하면 대부분 비교적 짧은 개발 경력을 가지고 계셨기 때문에 저와 지인분이 팀을 리드해서 진행하기로 했습니다.

2. Sui, Walrus, and Seal

이번 해커톤을 준비하면서 가장 먼저 마주하게 된 것은 Sui, Walrus, 그리고 Seal이라는 비교적 생소한 생태계였습니다. 저는 Cosmos 생태계에 조금 더 익숙했고, Ethereum 생태계에 대해서는 어느 정도 알고 있는 수준이었기 때문에, Sui는 처음엔 꽤 어색하게 느껴졌습니다.

설계 철학부터 다른 부분이 많아서, 단순히 사용법을 익히는 것을 넘어 구조를 이해하는 데 시간이 필요했습니다.

2-1. Sui

Sui는 Rust로 구현된 Layer1 블록체인으로, 스마트 컨트랙트는 Move 언어로 작성합니다. 가장 큰 특징은 Account(계정) 중심이 아닌 Object(객체) 중심의 상태 모델이라는 점입니다.

토큰, NFT, 각종 데이터 등 모든 상태는 독립적인 객체로 관리되며, 각 객체는 명확한 소유자와 변경 규칙을 가지고 있습니다. 이 때문에 상태를 “계정의 저장 공간”이 아니라 “서로 독립적인 객체들의 집합”으로 바라보게 됩니다.

Move 언어 자체도 독특한데, resource(자원) 개념과 ability 시스템을 통해 자원이 임의로 복사되거나 암묵적으로 버려지는 것을 컴파일 타임에 방지합니다. 덕분에 토큰이 중복 생성되거나, 의도치 않게 사라지는 유형의 버그를 언어 차원에서 예방할 수 있습니다.

이러한 객체 중심 구조 덕분에 Sui는 서로 독립적인 객체만을 다루는 트랜잭션을 병렬로 처리할 수 있습니다. 이는 처리 속도와 확장성 측면에서 큰 장점으로 작용합니다.

반면, 여러 트랜잭션이 동시에 접근해야 하는 Shared Object(공유 객체) 가 포함된 경우에는, 해당 객체에 대한 순서 보장을 위해 Consensus(합의)를 거쳐야 합니다. 이 경우에는 합의 없이 처리되는 fast path 트랜잭션에 비해, 병렬 처리의 이점이 줄어들게 됩니다.

그래서 Sui에서 컨트랙트를 설계할 때는 “이 객체를 Owned Object(소유 객체)로 둘 것인가, Shared Object(공유 객체)로 둘 것인가”를 초기에 신중하게 결정하게 됩니다.

EVM 기반 개발 경험이 있다면 Move 문법 자체보다도, 상태를 바라보는 관점의 차이 때문에 처음에 더 낯설게 느껴질 수 있다고 생각합니다.

2-2. Walrus

Walrus는 Sui 생태계의 탈중앙화 스토리지 네트워크입니다. 블록체인에 직접 올리기에는 부담이 되는 이미지, 영상, 문서 같은 대용량 데이터를 저장하고, 해당 데이터의 참조 정보(blob ID)와 메타데이터만을 Sui 온체인에 기록하는 구조를 가지고 있습니다.

처음에는 IPFS와 비슷한 역할을 하는 것처럼 보였지만, Walrus는 erasure coding 기반의 분산 저장 구조를 채택하고 있다는 점에서 차이가 있었습니다.

전체 데이터를 모든 노드에 복제하는 방식이 아니라, 데이터를 여러 조각으로 나누어 분산 저장하고 일부 조각만으로도 복구가 가능하도록 설계되어 있습니다. 이 덕분에 일부 노드가 오프라인이 되더라도 데이터 가용성을 유지할 수 있고, 저장 비용과 네트워크 효율 측면에서도 장점을 가집니다.

또한 Walrus는 Sui와 긴밀하게 연동되어 있어서, 온체인 컨트랙트에서 Walrus에 저장된 데이터의 참조나 무결성 검증을 자연스럽게 처리할 수 있습니다.

단순한 파일 저장소라기보다는, 탈중앙 환경에서 데이터 가용성과 무결성을 보장하기 위한 스토리지 레이어에 가깝다는 인상을 받았습니다.

이번 해커톤이 Walrus 중심으로 진행되었기 때문에, “어떤 데이터를 온체인에 둘 것인가, 그리고 어떤 데이터를 Walrus에 맡길 것인가”를 결정하는 것이 전체 설계의 중요한 포인트였다고 생각했습니다.

2-3. Seal

Seal은 Walrus와 함께 사용되는 데이터 보안 및 접근 제어 레이어입니다. Walrus가 “어디에 데이터를 저장할 것인가”를 담당한다면, Seal은 “누가, 어떤 조건에서 해당 데이터에 접근할 수 있는가”를 담당합니다.

Seal은 내부적으로 threshold encryption 기반의 암호화 구조를 사용합니다. 데이터는 암호화된 상태로 Walrus에 저장되고, 복호화에 필요한 키는 Seal의 키 관리 주체(키 서버)들에 분산되어 관리됩니다.

예를 들어, 특정 NFT 보유 여부, 특정 주소나 역할을 만족할 경우에만 이 키 조각들이 정책에 따라 결합되어 복호화가 가능해집니다. 이 조건 자체는 Sui의 온체인 로직으로 정의되고 검증됩니다.

덕분에 “이 콘텐츠는 특정 NFT 홀더만 볼 수 있다”, “이 문서는 DAO 멤버만 접근 가능하다”와 같은 조건부 접근 제어를 온체인 정책으로 표현할 수 있습니다.

Walrus와 Seal을 함께 사용하면, 단순히 데이터를 저장하는 것을 넘어, 프라이버시와 접근 통제가 중요한 서비스인 멤버십 콘텐츠, 비공개 문서 공유 등에도 적용할 수 있겠다는 가능성을 느꼈습니다.

3. Tusk

해커톤에서 진행한 프로젝트의 이름은 Tusk입니다.

현재 대부분의 채용 플랫폼에서는 구직자의 이력서가 비교적 퍼블릭한 형태로 공개되어 있습니다. 채용 담당자나 헤드헌터는 별도의 제약 없이 이력서를 열람할 수 있고, 이 과정에서 구직자의 개인정보가 충분히 보호되지 않는 경우도 많다고 느꼈습니다.

또한 구직자 입장에서는 공개된 공간에 작성하기 어려운 경력이 존재할 수 있습니다.
예를 들어, 아직 외부에 공개하기 곤란한 프로젝트 경험이나 보안, 계약, 조직 특성상 명시하기 어려운 이력이 이에 해당합니다. 이러한 경력은 분명 중요한 정보임에도 불구하고, 공개할 수 없다는 이유로 이력서에서 제외되곤 합니다.

결과적으로 이는 구직자와 기업 모두에게 손해라고 생각했습니다. 구직자는 자신의 역량을 충분히 드러내지 못하고, 기업은 더 적합한 인재를 놓칠 가능성이 높아지기 때문입니다.

Tusk는 다음과 같은 문제에서 출발했습니다.

• 구직자의 이력서가 과도하게 공개되어 개인정보 보호가 어렵다는 점
• 구직자가 “공개하기 어려운 경력”을 이력서에 담기 힘들다는 점
• 채용 담당자 역시 제한된 정보만으로 인재를 탐색해야 한다는 점

Tusk는 이력서를 완전히 공개하지 않고도, 채용 프로세스를 진행할 수 있도록 만드는 것을 목표로 합니다.

구직자는 자신의 이력서를 암호화된 형태로 업로드합니다. 이력서 원본은 누구나 열람할 수 없으며, 대신 AI를 통해 해당 이력서의 내용을 요약한 프리뷰 정보만 생성됩니다.

채용 담당자와 헤드헌터는 이 AI 프리뷰를 기반으로 필요한 인재를 검색할 수 있습니다. 검색 결과에는 조건에 부합하는 구직자 목록과 함께, 각 구직자의 AI 프리뷰가 표시됩니다.

만약 특정 구직자의 이력서를 직접 열람하고 싶다면, 채용 담당자는 해당 구직자에게 열람 권한을 요청할 수 있습니다. 구직자는 이 요청에 대해 허가 또는 거절로 응답할 수 있으며, 허가가 이루어진 경우에만 해당 채용 담당자는 이력서 원본을 열람할 수 있습니다.

이러한 구조를 통해 Tusk는 다음과 같은 가치를 제공하고자 했습니다.

• 구직자는 개인정보를 보호하면서도 자신의 역량을 효과적으로 전달할 수 있고
• 채용 담당자는 불필요한 정보 노출 없이, 더 효율적으로 인재를 탐색할 수 있으며
• 이력서 공개 여부에 대한 주도권이 구직자에게 돌아가게 됩니다.

결과적으로 Tusk는 구직자의 개인정보 보호와 채용 담당자의 인재 탐색 효율을 동시에 개선하는 것을 목표로 하는 프로젝트입니다.

4. What i did

해커톤을 진행하면서 팀을 리드하기로 했기때문에 저는 지인과 함께 Tusk의 전체 시스템 아키텍처와 시나리오 기반 플로우 설계와 프론트엔드 개발 및 배포, 문서 작업을 담당했습니다.

아키텍처는 사용자 행동 흐름(시나리오) 을 기준으로 총 다섯 단계로 나누어 설계했습니다.

4-1 아키텍처 설계

프로젝트의 전체 시스템 아키텍처를 설계하면서 Sui, Walrus, Seal에 대한 이해를 먼저 쌓는 데 많은 시간을 사용했습니다.
처음에는 각 컴포넌트가 어떤 문제를 해결하기 위해 존재하는지조차 명확하지 않아, 단순히 문서를 읽는 것만으로는 구조가 잘 그려지지 않았습니다. 하지만 이 과정 덕분에, 단일 시스템이 아닌 역할이 분리된 여러 레이어를 어떻게 조합해야 하는지, 그리고 탈중앙 환경에서 데이터 저장과 접근 제어를 어떻게 설계할 수 있는지에 대해 깊이 고민할 수 있었습니다.

구직자 등록 및 이력서 업로드

이 단계의 핵심은 허가되지 않은 사람들에게는 이력서 원본이 처음부터 끝까지 공개되지 않도록 하는 것입니다.

구직자가 이력서를 업로드하면, Sui 네트워크 상의 Access Policy Contract를 통해 해당 이력서에 대한 접근 권한을 관리하는 Access Policy Object를 생성합니다. 이를 통해 이력서 접근 정책을 중앙 서버가 아닌 블록체인 상에 명확하게 기록하도록 설계했습니다.

이후 클라이언트 단에서 Seal SDK를 사용해 이력서를 암호화합니다. 암호화에 사용되는 키는 Seal Key Servers에 분산 저장되며, 암호화된 이력서 파일만 Walrus 네트워크에 업로드됩니다.

이력서 내용은 AI를 통해 분석되어 직무, 기술 스택 등의 메타데이터로 라벨링되고, 검색을 위한 벡터 임베딩 데이터로 변환되어 저장됩니다.

이력서 원본 데이터와 검색용 메타데이터를 명확히 분리하여 개인정보 노출 가능성을 구조적으로 최소화하고자 했습니다.

채용 담당자 검색

채용 담당자는 조건을 기반으로 구직자를 검색할 수 있습니다. 이때 사용되는 정보는 이력서 원본이 아닌, AI가 생성한 프리뷰 및 벡터 임베딩 데이터를 사용합니다.

검색 쿼리는 벡터로 변환되고, 저장된 이력서 프리뷰 벡터와의 유사도 검색을 통해 조건에 부합하는 구직자 목록이 반환됩니다.

이 과정에서 채용 담당자가 확인할 수 있는 정보는 민감 정보가 제거된 최소한의 정보로 제한됩니다. 이를 통해 검색 단계에서는 개인정보 노출 가능성을 최대한 낮추고자 했습니다.

검색 단계에서는 “매칭 가능성”만 판단할 수 있도록 하고, 실제 데이터 접근은 반드시 별도의 권한 요청을 거치도록 분리했습니다.

접근 권한 요청

검색 결과를 확인한 뒤 특정 구직자의 이력서를 직접 확인하고 싶은 경우, 채용 담당자는 해당 구직자에게 열람 요청을 보낼 수 있습니다.

이 요청은 Sui 네트워크 상에 존재하는 Access Policy Contract를 통해 Access Policy가 업데이트 되며, 누가 언제 어떤 이력서에 대해 접근을 요청했는지가 온체인에 기록됩니다.

열람 요청 자체를 온체인 상태로 관리하여 요청 이력의 위변조 가능성을 최소화하고자 했습니다.

구직자의 승인 또는 거절

구직자는 들어온 열람 요청을 확인한 뒤 승인 또는 거절을 선택할 수 있습니다.

승인 혹은 거절 시, Sui 네트워크의 Access Policy Contract가 실행되며, 해당 이력서에 대한 접근 정책이 업데이트됩니다.

이를 통해 권한 부여 여부를 중앙 서버가 임의로 조작할 수도 없고, 관여할 수 없도록 진행됩니다.

이를 통해 접근 권한에 대한 최종 결정권을 구직자 본인에게 명확히 귀속시키고자 했습니다.

승인된 채용 담당자의 이력서 열람

암호화된 이력서 자체에 접근하는것은 Walrus를 통해 가능할 수 있지만, 복호화를 위해서는 Seal Server를 거쳐야 하기 때문에 열람 권한이 승인된 경우에만 채용 담당자는 Walrus 네트워크에서 암호화된 이력서를 복호화할 수 있습니다.

이때 Seal Key Server는 Sui 네트워크 상의 정책 상태를 검증한 뒤, 권한이 확인된 경우에만 복호화 키를 반환합니다.

데이터 저장(Walrus)과 접근 제어(Sui/Seal)를 분리하여 단일 컴포넌트에 대한 신뢰를 최소화하고자 했습니다.

결과적으로 권한이 없는 사용자는 기술적으로도 이력서 원본에 접근할 수 없으며, 접근 제어가 구조적으로 보장되는 흐름을 만들고자 했습니다.

4-2 Frontend 개발 및 배포

해커톤을 진행하면서 평소에 사용하지 않던 기술 스택을 더 적극적으로 활용해보고 싶다는 생각도 들었지만, 구직 활동을 병행해야 했고 제한된 기간 내에 완성해야 했기 때문에 저는 주로 프론트엔드 전반의 초기 세팅과 랜딩 페이지 개발, 그리고 배포를 담당했습니다.

렌딩페이지는 해커톤 특성상 첫인상이 중요하다고 판단해 UI 측면에서는 React Bits를 적극적으로 활용했습니다. 또한 비즈니스 로직이 많지 않은 랜딩 페이지의 특성에 맞게 Atomic Design Pattern을 적용해 화면 구조를 구성했습니다.

프론트엔드 개발 과정에서는 Sui 네트워크와 Slush Wallet을 연결하기 위한 Provider 설정, 네트워크 연결 구성, 상태 관리 구조를 직접 설계하고 구현했습니다. 지갑 연결을 위한 커스텀 훅 역시 이 구조 위에서 동작하도록 구성했으며, 이를 통해 이후 팀원들이 별도의 환경 설정 없이도 Web3 기능을 바로 개발할 수 있도록 했습니다.

배포는 Vercel을 통해 진행했으며, 기존에 운영 중이던 개인 도메인에 서브도메인을 구성하여 프로젝트 결과물을 안정적으로 확인할 수 있도록 https://tusk.lapidix.dev로 접근 가능하게 설정했습니다.

배포 이후에는 전체 사용자 흐름을 기준으로 QA를 진행하며 기능과 화면을 점검했고, 이 과정에서 발견된 UI/UX 상의 미비한 부분이나 동작 흐름상 어색한 지점들은 직접 수정하여 개선했습니다.

4-3 문서 작업

프로젝트 설계를 주도한 사람이 문서 작업까지 함께 진행하는 것이 효율적이라고 판단하여 제가 README 작성을 담당했습니다.

README에는 프로젝트의 문제 정의와 당위성, 해당 문제를 어떤 방식으로 해결했는지, 그리고 사용자 시나리오별로 시스템이 어떻게 동작하는지를 중심으로 정리했습니다.

영문 문서가 필요했기 때문에 번역 도구의 도움을 받아 작성했으며, 외부에서 보더라도 프로젝트의 전체 흐름을 이해할 수 있도록 구성하는 데 초점을 맞췄습니다.

5. Limitations

Tusk는 해커톤이라는 제한된 시간과 리소스 안에서, 전체적인 구조와 흐름을 검증하는 데 초점을 둔 프로젝트였습니다. 그 과정에서 명확하게 드러난 한계점들도 있었고, 실제 서비스로 확장한다면 반드시 고민해야 할 지점들도 분명히 존재했습니다.

5-1. 채용 담당자 신뢰 및 검증 구조의 부재

현재 Tusk에서는 클라이언트 단에서 지갑 연결을 통해 채용 담당자를 식별하는 구조를 사용하고 있습니다. 이 방식은 구현이 단순하고 Web3 환경과도 잘 맞지만, 해당 사용자가 실제로 어떤 기업에 소속된 사람인지, 또는 그 기업을 대표해 접근 권한을 요청할 수 있는 주체인지에 대한 검증이나 인덱싱은 존재하지 않습니다. 이는 구직자가 접근 권한 허가에 대한 중요한 지표이지만 현재는 부재합니다.

실제 채용 환경을 고려해보면, 이는 구직자 입장에서 신뢰 문제로 이어질 수 있다고 생각합니다. KYC나 기업 인증 절차를 통하여 채용 담당자의 소속과 신원을 검증할 수 있다면, 열람 요청에 대한 신뢰도를 한 단계 더 높일 수 있을 것입니다.

다만 이러한 구조를 도입할 경우, 사용자와 기업 정보를 관리하기 위한 데이터베이스 구조가 필요해지고, 탈중앙화 수준과 사용자 편의성 사이에서 명확한 트레이드오프가 발생하게 됩니다. 그럼에도 불구하고, 실제 서비스로 발전시킨다면 반드시 고민해야 할 부분이라고 느꼈습니다.

5-2. AI 프리뷰 및 검색 정확도의 한계

Tusk에서는 이력서 원본을 직접 노출하지 않기 위해 AI가 생성한 프리뷰와 벡터 임베딩 데이터를 기반으로 구직자 검색을 수행하고 있습니다.

전체적인 방향성은 적합하다고 생각하지만, 해커톤 기간 동안 확보할 수 있었던 실제 데이터의 양이 매우 제한적이었기 때문에 프리뷰의 품질이나 검색 정확도를 충분히 검증하거나 고도화하지는 못했습니다.

특히 직무별 특성이나 경력의 깊이, 기술 스택의 중요도를 세밀하게 반영하기에는 데이터와 시간 모두 부족했던 것이 사실입니다.

이 부분은 구조적인 문제라기보다는, 데이터 축적과 운영 측면에서의 아쉬움에 가깝다고 느꼈습니다.

5-3. 접근 권한 정책의 단순함

현재 구조에서는 이력서 단위로 열람 권한을 허용하거나 거절하는 방식으로 설계되어 있습니다. 해커톤 범위에서는 명확하고 이해하기 쉬운 구조였지만, 실제 채용 과정에서는 다소 단순하게 느껴질 수 있습니다.

이력서의 특정 섹션만 공개하거나, 일정 기간 동안만 열람을 허용하는 방식, 혹은 1회성 열람 권한과 같은 보다 세밀한 접근 권한 정책이 필요할 가능성도 충분히 있습니다.

Sui의 객체 모델을 활용한다면, 접근 권한을 더 작은 단위의 정책 객체로 분리하여 확장하는 것도 가능할 것이라고 생각합니다.

5-4. 사용자 경험(UX) 측면의 아쉬움

이번 프로젝트에서는 보안과 접근 제어라는 구조적인 문제에 우선순위를 두다 보니, 상대적으로 UX 개선에는 많은 시간을 투자하지 못했습니다.

접근 요청 상태가 직관적으로 드러나지 않거나, 승인·거절 이후의 피드백이 부족한 부분 등은 실제 사용자를 기준으로 보면 개선의 여지가 많다고 느꼈습니다.

기술적인 안전장치뿐 아니라, 사용자가 흐름을 이해하고 신뢰할 수 있는 UX 역시 중요한 요소라고 생각합니다.

6. Conclusion

이번 해커톤은 Sui와 Walrus, Seal이라는 새로운 기술 스택에 대해 이해할 수 있었던 좋은 경험이었습니다.

해커톤을 통해 단순히 기능을 구현하는 것보다, 문제를 어떻게 정의하고, 그 문제를 어떤 구조로 풀어낼 것인지를 고민하는 과정이 얼마나 중요하고 재미있는지 다시 한 번 느낄 수 있었습니다.

특히 팀을 리드하는 역할을 맡으면서, 기술적인 선택뿐 아니라 시간과 리소스를 어떻게 할당할지에 대한 판단 역시 중요한 역할이라는 점을 체감했습니다.

Tusk는 완성된 서비스라기보다는, 이력서 접근 권한과 개인정보 보호를 이런 방식으로 풀 수 있다는 가능성을 검증한 프로토타입에 가까운 프로젝트였습니다.

오히려 한계점과 보완 방향이 비교적 명확하게 드러났다는 점에서, 해커톤 프로젝트로서 충분히 의미 있는 결과물이었다고 생각합니다.

결과는 아직 나오지 않았지만 결과를 떠나서 아키텍처 설계부터 구현, 배포, QA, 문서화까지 프로젝트 전반을 경험해볼 수 있었다는 점에서 개인적으로 충분히 의미 있고 재미있는 경험이었다고 생각합니다!