Applying Vault to Other Services

Vault is the file management service within Vizend. In Vault, the data structure of files is divided into reference files and physical files.

Reference files are structured to reference physical files, and even if multiple users have the same actual file, the storage space used is only that of one file's capacity.

From my experience maintaining the Vault functionality, it seems to be categorized into three main types.

Vault is divided into three main types of storage.

Type of storage

1) Personal storage: Stash

• Personal storage with a folder structure

2) General storage: Cabinet / Clip

Used as a 'general attachment storage' for announcements, post attachments, etc.

• Cabinet: The concept of a bundle (container) of Clips

• Clip: The concept of a bundle of ClipFiles (reference files)

• The application scope/unit may vary according to the service (devlime, vizend, BanJangNote, etc.) business logic.

• You can consider the 'entire service storage as 1 cabinet'.

• It is also possible to separate the cabinet for each bulletin board.

3) Photo Storage: MiniAlbum / Minipix

• Minipix : Photo storage “service name”

• Mini Album: Actual domain (administrative unit)

Common concept: 'Reference File Repository'

The three repositories (Stash / Clip / Photo) share the following in common reference fileSaving.

• Saved file

• Stash: StashFile

• Clip: ClipFile

• MiniAlbum: PhotoFile

They are all actual files VaultFileThis is a reference pointing to. Therefore, even if you replicate the reference file many times,The actual storage capacity does not increase immediately..

Challenges Faced When Applying to Other Services

While I was in charge of Vault, I took on the task of actually applying Vault to another service. The name of that service is 'BanJangNote'. BanJangNote can be said to be a personnel management app and is currently under development as of the first half of 2026. (Due to security reasons, I apologize for the limitations in providing detailed service descriptions.)

Features needed from Vault in the class leader's note included My Documents and submitting documents for announcements.

Initially, I thought it would be easy to implement Vault here, but there were some limitations in applying it.

First, my documents had to be applied using Stash, which is fundamentally a folder structure.

The class leader's note had a specific type of document that needed to be saved in my files, which did not fit the folder structure. However,Vault is one of the MSA services and must function as a general service, so we could not change the Vault Stash domain just because it is applied to another service.Therefore, it was necessary to apply it to the class leader's note while maintaining the structure of Stash.

1. The Paradox of Vault's Versatility

So, after much consideration, I decided to implement a method where folders are created in advance and the logic for changing and deleting folders is not provided to the user. After resolving this issue, another problem awaited. Since Vault only offers save and upload/download functions, I had to decide whether to save metadata for each uploaded file in a document domain structured similarly to Vault's backend in the BanJangNote. For Vault to effectively handle file management, it was necessary to have a structure for saving metadata as well, and to solve this, the CEO added a JSON format string column to each clipfile, stashfile, and photofile. For example, when uploading an ID card photo in the stashfile, I added metadata along with the file like fileMetaData = "{ documentType: /"ID_CARD/" }". This allowed us to eliminate the need to separately design and apply the document domain in the BanJangNote backend.

2. Backend to backend vs frontend to backend

There are two ways to use the vault feature in other services:

1. Directly call the vault backend in client form from the backend of another service

2. Import and call the API state management component of the vault front from the front of another service

At first, I tried the first method, but as the project progressed, I realized that this method puts a load on the server. For example, when uploading from the Banjangnote front, it sends an upload request to the Banjangnote backend, sends the file to the backend, and then transmits it to the vault backend, which unnecessarily consumes a lot of memory on the Banjangnote and vault servers. Therefore, it was necessary to call the vault backend directly from the Banjangnote front, and since there is already a custom hook component that automates state management for each API on the vault front, I realized that it would be better to import that front component.

3. Scope of Cabinet and Clip

A Cabinet is a collection of Clips, and a Clip is a collection of ClipFiles. This issue was the biggest challenge for me when I was in charge of the Vault. I received many inquiries on how to define the scope of Cabinets and Clips across different services.

It was difficult to provide a straightforward answer. Each bulletin board was viewed as a cabinet, and posts could be divided into clips or viewed only as clips. It is still difficult to give a clear answer, but from my experience, the most flexible structure seemed to be defining most file bundles as clips, where a whole service sharing one cabinet creates a clip when adding photos or attachments to the post, and a dedicated clip is created when submitting documents for that particular post. Clips were handled as the entire file for an individual, with metadata passed along during uploads. However, it was later decided in discussions whether to pass the metadata to the vault or to the manager's notes, and it appears that the latter was chosen due to the need for managing metadata within the manager's notes.

Therefore, we applied it in the following flow when implementing the class leader's notebook.

structure

• The class leader's note is announcement clip and submission document clipto separate

• the cabinet is the entire notebook of the class presidentShare 1 item

• cabinetKey and cabinetId must always be the same

flow

1) The leader (team leader) creates the announcement

1. RegisterJobPost in the BanJangNote backend (example)

2. When registering an image in the announcement, call registerClipFiles

3. Save the returned clipId to the corresponding JobPost in the BanJangNote backend upon success

2) The team leader clicks on the announcement → submit

1. FindJobPostDetail in the BanJangNote backend (example)

2. Submit → Document list → Click on ID

3. File upload or 'Load from my documents'

• When uploading a file

- Call registerClipFiles

- Store the returned clipId and clipFileIds in jobApplication (example)

- Use registerClipFile if there is no corresponding document type in jobApplication, or use addClipFile if it exists

• When loading from My Documents

- Use registerClipFilesFromstash

- If it is possible to check the stashFolderId of a specific document, process using registerClipFilesFromstash without saving metadata and then save in the captain's note backend

3) Team leader checks applicant documents

1. Query jobApplication from captain's note backend that includes clipId → extract clipId

2. Query clipFileIds from vault backend and use downloadFile(s) for thumbnail preview

Review

By applying the vault service to captain's note, I was able to learn a lot and realized that there is still much more to learn. There are compromises that need to be made for versatility, and I feel I grew in the process of compensating for this. In the future, as a vault manager, I think it will greatly help the development progress if I can clearly define how to manage the captain's note team. If I am assigned similar tasks in other services, I am determined to explain the structure of vault more concisely and work actively in domain structure design based on my experience, moving forward in a way that accepts mistakes and improves.

LEE DAVID