---
title: "DORA와 SPACE 실제 적용 사례: 개발 생산성은 어떻게 개선됐을까? | Findy Team+"
description: DORA와 SPACE를 이해하고 나면 다음 질문이 생깁니다. “실제 개발 조직에서는 이 프레임워크를 어떻게 활용하고 있을까?” 개발 생산성 지표를 측정하는 것 자체가 조직을 개선해 주지는 않습니다. 중요한 것은 현재 조직의 문제를 정의하고, 필요한 데이터를 측정한…
image: https://kr.findy-team.io/hubfs/Imported_Blog_Media/s-1672x941_v-fms_webp_037411a4-302d-401f-ac03-cd3fb1e12f3a.png
---

[본문으로 건너뛰기](https://kr.findy-team.io/media/real-world-stories-dora-space#main-content)

[![Findy Team+](https://kr.findy-team.io/hubfs/kr-home-assets/20-s-300x42_ba0f0b6f-a8b7-4e01-8a3f-75a3ab15dc0d.svg)](https://kr.findy-team.io/)

[도입 사례](https://kr.findy-team.io/customers) [블로그](https://kr.findy-team.io/blog) [뉴스룸](https://kr.findy-team.io/newsroom) [회사 소개](https://kr.findy-team.io/aboutus) [문의하기](https://kr.findy-team.io/contact-us) [로그인](https://findy-team.io/login?lang=en)

×

[도입 사례](https://kr.findy-team.io/customers) [블로그](https://kr.findy-team.io/blog) [뉴스룸](https://kr.findy-team.io/newsroom) [회사 소개](https://kr.findy-team.io/aboutus) [로그인](https://findy-team.io/login?lang=en) [문의하기](https://kr.findy-team.io/contact-us)

[All posts](https://kr.findy-team.io/blog)

Blog Article 2024/10/30

# DORA와 SPACE 실제 적용 사례: 개발 생산성은 어떻게 개선됐을까?

![DORA와 SPACE 실제 적용 사례: 개발 생산성은 어떻게 개선됐을까?](https://kr.findy-team.io/hubfs/Imported_Blog_Media/s-1672x941_v-fms_webp_037411a4-302d-401f-ac03-cd3fb1e12f3a.png)

DORA와 SPACE를 이해하고 나면 다음 질문이 생깁니다.

**“실제 개발 조직에서는 이 프레임워크를 어떻게 활용하고 있을까?”**

개발 생산성 지표를 측정하는 것 자체가 조직을 개선해 주지는 않습니다.

중요한 것은 **현재 조직의 문제를 정의하고, 필요한 데이터를 측정한 뒤, 발견한 문제를 실제 개발 프로세스의 개선으로 연결하는 것**입니다.

[앞선 글](https://kr.findy-team.io/blog/dora-vs-space)에서는 DORA와 SPACE의 차이와 각각 어떤 상황에서 활용할 수 있는지 살펴봤습니다.  
이번 글에서는 한 단계 더 나아가 실제 기업 사례를 살펴보겠습니다.

일본의 SaaS 기업 **Uluru(うるる)**와 헬스케어 기업 **PharmaX**가 개발 생산성을 어떻게 측정하고 개선했는지, 그리고 그 과정에서 어떤 성과를 만들어냈는지를 중심으로 알아보겠습니다.

## 먼저 보는 핵심 성과

두 기업은 서로 다른 문제에서 출발했고, 개발 생산성을 바라보는 방법도 달랐습니다.

| 기업 | 주요 과제 | 주요 접근 | 대표적인 성과 |
| --- | --- | --- | --- |
| Uluru | 제품별 생산성 기준과 병목 파악 | SPACE를 중심으로 다양한 지표 설계 | 리드 타임 41.7% 감소 |
|  | 개발 활동 효율화 | PR 및 프로세스 데이터 측정 | Merge PR 수 51.9% 증가 |
| PharmaX | 긴 리드 타임과 개발 프로세스 개선 | DORA 중심의 개발 데이터 가시화 | 최대 220시간 → 약 20시간 |
|  | 코드 리뷰 병목 | 리뷰 대기 시간 측정 및 개선 | 리뷰 및 배포 프로세스 개선 |

두 사례에서 중요한 점은 특정 프레임워크를 그대로 적용했다는 것이 아닙니다.

**각 조직이 해결하려는 문제를 먼저 정의하고, 그 문제를 이해하는 데 필요한 지표를 선택했다는 점**입니다.

---

## [사례 1. Uluru](https://kr.findy-team.io/customers/Uluru)는 어떻게 리드 타임을 41.7% 줄였을까?

Uluru는 일본에서 여러 SaaS 및 BPO 관련 서비스를 운영하는 기업입니다.

여러 제품을 동시에 개발하면서 엔지니어링 생산성을 높이고 개발 프로젝트의 상태를 보다 명확하게 파악하고자 했습니다.

하지만 생산성을 개선하려고 하자 몇 가지 문제가 나타났습니다.

## Uluru가 가지고 있던 문제는 무엇이었나요?

첫 번째 문제는 **개발 생산성을 판단할 공통적인 기준이 명확하지 않았다는 것**입니다. 개발 속도가 현재 빠른 것인지 느린 것인지, 어느 정도 수준을 목표로 해야 하는지 판단하기 어려웠습니다.

두 번째는 생산성 향상에 대한 요구가 오히려 개발자의 부담으로 이어질 수 있다는 점이었습니다. 무엇을 개선해야 하는지 명확하지 않은 상태에서 단순히 '생산성을 높이자'고 요구하면 개발자 입장에서는 또 하나의 성과 평가처럼 느껴질 수 있습니다.

세 번째는 **제품마다 개발 방식이 다르다는 것**이었습니다. 여러 제품을 개발하고 있었기 때문에 모든 조직에 동일한 생산성 기준을 일괄적으로 적용하기 어려웠습니다.

따라서 Uluru에는 단순한 하나의 생산성 점수보다 **각 제품과 팀의 특성을 반영하면서 개발 조직의 상태를 파악할 방법**이 필요했습니다.

## Uluru는 SPACE를 어떻게 적용했나요?

Uluru는 기존에 활용하던 DORA 관련 지표와 함께 SPACE의 관점을 도입했습니다.  
하지만 SPACE의 다섯 영역을 그대로 동일한 KPI로 설정하지는 않았습니다.

### 1. 제품별로 필요한 생산성 지표를 정의했습니다

각 제품팀이 자신의 개발 환경과 목표에 맞게 **무엇을 생산성으로 볼 것인지 먼저 정의**했습니다. SPACE의 Satisfaction, Performance, Activity, Communication, Efficiency 등의 관점을 활용하면서도 실제 측정 지표는 팀의 상황에 맞게 설정했습니다.

예를 들어 Activity를 살펴보기 위해 Findy Team+에서 Merge된 PR 수를 확인하고, Satisfaction과 관련된 영역은 별도의 설문 도구를 활용했습니다.

즉, **프레임워크 → 일괄적인 KPI** 가 아니라,   
**조직의 문제 → 필요한 관점 → 적절한 데이터** 순으로 측정 체계를 설계한 것입니다.

### 2. 개인이 아니라 '팀'의 생산성을 측정했습니다

개발 생산성을 측정하기 시작하면 개발자가 가장 먼저 우려할 수 있는 것이 있습니다.

**“이 데이터가 나를 평가하는 데 사용되는 것은 아닐까?”**

Uluru는 이러한 문제를 고려해 생산성 지표가 **개인 평가가 아니라 팀의 개선을 위한 데이터라는 점을 명확하게 했습니다.** 측정 목적을 분명하게 공유함으로써 구성원의 불필요한 부담을 줄이고, 생산성 개선 활동에 대한 팀의 참여를 높였습니다.

### 3. 데이터를 통해 실제 병목을 찾았습니다

생산성 데이터를 지속적으로 살펴보면서 실제 개발 과정에서 발생하는 문제를 발견할 수 있었습니다.

예를 들어 리뷰 프로세스를 자동화한 이후에도 일부 수동 확인 과정이 늦어지면서 전체 업무 흐름을 지연시키는 문제가 발견됐습니다.

단순히 **“개발 속도가 느리다”** 라고 판단하는 대신, **“어느 단계에서 얼마만큼의 대기가 발생하고 있는가?”** 를 찾아내고 구체적인 개선 대상으로 바꾼 것입니다.

### 4. 한 번 측정하고 끝내지 않았습니다

Uluru는 생산성 측정을 일회성 프로젝트로 운영하지 않았습니다.

지표를 지속적으로 확인하고 개선 활동 이후 다시 데이터를 살펴보면서 **측정 → 문제 발견 → 개선 → 확인**의 과정을 반복했습니다.

생산성 지표 자체를 목표로 삼기보다 **개발 조직의 변화를 관찰하는 도구로 사용한 것**입니다.

## Uluru의 개발 생산성은 어떻게 달라졌나요?

이러한 활동 이후 Uluru에서는 실제 개발 프로세스의 변화가 나타났습니다. 가장 대표적인 결과는 **리드 타임 41.7% 감소**였습니다. 또한 **Merge된 PR 수는 51.9% 증가**했습니다.

하지만 사례에서 숫자만큼 주목할 부분은 조직 내 커뮤니케이션의 변화입니다. 개발 생산성이 가시화되면서 엔지니어뿐 아니라 다른 부서와 경영진도 개발 조직의 상태를 이전보다 이해하기 쉬워졌습니다.

개발팀 내부에서도 생산성에 대한 논의가 단순한 평가가 아니라 **“우리 프로세스에서 무엇을 개선할 수 있을까?”**라는 대화로 이어질 수 있었습니다.

### Uluru 사례의 핵심

> **개발 생산성 측정의 기준을 모든 팀에 동일하게 강제하기보다, 각 팀의 상황에 맞는 지표를 정의하고 팀 단위의 개선에 활용했습니다.**

SPACE를 활용하는 목적이 '다섯 가지 지표를 모두 측정하는 것'이 아니라는 점을 보여주는 사례라고 할 수 있습니다.

---

## [사례 2.PharmaX](https://kr.findy-team.io/customers/pharmax)는 어떻게 리드 타임을 220시간에서 20시간 수준으로 줄였을까?

PharmaX는 헬스케어 분야의 서비스를 개발하는 일본 기업입니다.

Primary Care 브랜드 YOJO와 약국 DX 사업 등을 운영하고 있으며, 2023년에는 생성형 AI를 헬스케어에 활용하기 위한 PharmaX Generative AI Lab도 설립했습니다.

사업과 개발 조직이 성장하면서 PharmaX에는 새로운 문제가 나타났습니다. 개발 프로젝트의 진행 상황을 정확하게 파악하기 어려웠고, 리드 타임과 버그 등의 문제가 프로젝트 진행에도 영향을 주고 있었습니다.

따라서 다음과 같은 개발 환경이 필요했습니다.

**개발 프로세스의 상태를 명확하게 확인하고, 프로젝트 진행을 예측하며, 코드 품질을 유지하면서 리드 타임을 줄이는 것**입니다.

PharmaX는 이를 위해 DORA 관련 지표를 중심으로 개발 프로세스를 측정하고 Findy Team+를 도입했습니다.

## PharmaX는 어떤 지표를 관리했나요?

PharmaX가 모든 개발 데이터를 동일한 중요도로 관리한 것은 아닙니다.

자신들이 해결하고자 하는 문제와 직접적으로 연결되는 몇 가지 지표에 집중했습니다.

### 1. 리드 타임

PharmaX가 중요하게 관리한 대표적인 지표는 **리드 타임**이었습니다.   
목표는 23시간 이하였습니다. 기획된 기능이 실제 사용자에게 전달되는 시간을 줄임으로써 사업의 변화에 보다 빠르게 대응하려는 목적이었습니다.

리드 타임을 지속적으로 가시화하면서 개발 과정의 변화가 실제 전달 속도에 어떤 영향을 주는지 확인했습니다.

### 2. 개발 활동

개발팀의 활동 상태를 이해하기 위해 Pull Request와 관련된 데이터도 살펴봤는데 **1인당 하루 최소 2개의 PR**이라는 목표를 두고 활동 상태를 확인했습니다.

여기에서 한 가지 주의해서 볼 필요가 있습니다.  
PR 개수 자체가 곧 개발 생산성을 의미하는 것은 아닙니다.

PharmaX 사례에서 이 데이터는 팀의 활동 패턴을 확인하고, 특정 시기에 활동이 감소했을 경우 회고를 통해 **“무엇이 개발을 막고 있었는가?”**를 살펴보기 위한 신호로 활용되었습니다.

### 3. 코드 리뷰 대기 시간

PharmaX가 특히 주목한 또 다른 지표는 **PR이 생성된 후 리뷰되기까지 걸리는 시간**이었습니다. 코드 작성이 빠르게 끝나더라도 리뷰가 오랫동안 대기한다면 전체 리드 타임은 길어질 수밖에 없습니다.

따라서 리뷰 대기 시간을 가시화하고 병목을 줄임으로써 변경 사항이 다음 단계로 보다 원활하게 이동하도록 개선했습니다.

이는 결과적으로 배포 프로세스의 효율성 향상으로도 이어졌습니다.

### 4. 데이터와 회고를 함께 활용했습니다

PharmaX는 대시보드의 숫자를 확인하는 것으로 끝내지 않았습니다.

1on1과 회고를 통해 구체적인 업무 내용을 다시 살펴보고, **어떤 작업에서 시간이 오래 걸렸는지, 무엇이 개발을 방해했는지, 다음에는 무엇을 개선할 수 있는지** 논의했습니다.

즉 정량적인 데이터로 이상 징후를 발견하고, 회고를 통해 그 숫자의 배경을 파악하는 방식입니다.

## PharmaX의 개발 생산성은 어떻게 달라졌나요?

가장 눈에 띄는 변화는 리드 타임입니다.

한때 **최대 220시간까지 늘어났던 리드 타임을 약 20시간 수준으로 안정화**했고, 평균적으로 하루에 하나의 구현을 완료할 수 있는 수준까지 개선했습니다.

단순 계산하면 최대치 기준으로 약 **91% 감소**한 것입니다.

코드 리뷰 시간도 지속적으로 측정하면서 리뷰 프로세스를 빠르게 만들었고, 이를 통해 코드 품질과 버그 발생 측면에서도 개선이 나타났습니다. 

또 하나의 변화는 **개발 조직의 성과를 경영진에게 설명할 수 있게 됐다는 점**입니다.

이전에는 개발 조직이 프로세스를 개선하더라도 그 효과를 명확하게 보여주기 어려웠다면, 개발 생산성 데이터를 가시화한 이후에는 어떤 개선이 있었고 결과가 어떻게 달라졌는지를 수치로 설명할 수 있게 됐습니다.

이는 개발 조직에 대한 경영진의 신뢰를 높이는 데도 도움이 됐습니다.

### PharmaX 사례의 핵심

> **측정 가능한 데이터를 만드는 것에서 끝나지 않고, 데이터를 회고와 연결해 실제 개발 프로세스를 바꾸는 데 활용했습니다.**

---

## 두 기업은 무엇을 다르게 했을까요?

Uluru와 PharmaX는 모두 개발 생산성을 개선했지만 접근 방법은 같지 않았습니다.

|  | Uluru | PharmaX |
| --- | --- | --- |
| 출발점 | 제품별 생산성을 어떻게 정의할 것인가 | 긴 리드 타임과 개발 병목을 어떻게 줄일 것인가 |
| 주요 접근 | SPACE 기반의 다차원 측정 | DORA 및 개발 프로세스 데이터 중심 |
| 측정 방식 | 팀·제품에 맞게 지표 설계 | 핵심 문제와 관련된 지표 집중 |
| 대표 데이터 | Satisfaction, Merge PR 등 | Lead Time, PR, Review Time 등 |
| 개선 방법 | 팀 단위 지속적 개선 | 데이터 + 회고 |
| 대표 성과 | Lead Time 41.7% 감소 | 최대 220h → 약 20h |
| 공통점 | **측정 자체가 아니라 개선을 위해 데이터를 사용** | **측정 자체가 아니라 개선을 위해 데이터를 사용** |

이 두 사례에서 중요한 것은 **어느 프레임워크가 더 좋은 결과를 만들었는지를 비교하는 것이 아닙니다.**

오히려 정반대의 교훈을 얻을 수 있습니다.

**좋은 개발 생산성 측정 방법은 조직마다 달라질 수 있습니다.**

## 실제 사례에서 발견할 수 있는 개발 생산성 개선의 4가지 공통점

두 기업의 접근 방식은 달랐지만 몇 가지 공통점이 있습니다.

### 1. 지표보다 문제를 먼저 정의했습니다

Uluru는 제품마다 다른 생산성 기준이 필요했고, PharmaX는 긴 리드 타임과 개발 프로세스의 병목을 해결해야 했습니다.

둘 다 단순히 **“DORA를 도입하자”** 혹은 **“SPACE를 측정하자”** 에서 시작하지 않고, 먼저 해결해야 할 조직의 문제를 정의했습니다.

### 2. 모든 것을 측정하지 않았습니다

개발 과정에서는 수많은 데이터를 수집할 수 있습니다.  
하지만 데이터가 많다고 반드시 더 좋은 의사결정을 할 수 있는 것은 아닙니다.

Uluru는 각 제품의 상황에 필요한 지표를 정의했고, PharmaX 역시 리드 타임과 리뷰 시간 등 해결하려는 문제와 직접 연결된 데이터를 집중적으로 살펴봤습니다.

즉, **측정할 수 있는 데이터가 아니라 의사결정에 필요한 데이터를 측정했습니다.**

### 3. 데이터를 개인 평가보다 팀 개선에 활용했습니다

특히 Uluru 사례에서는 이 원칙이 명확하게 나타났습니다.

개발 생산성 데이터가 개인을 평가하거나 비교하기 위한 숫자로 인식되면 구성원이 측정 자체에 방어적으로 반응할 수 있습니다.

반대로 데이터를 **팀의 프로세스를 개선하기 위한 공통 언어**로 사용하면 개발자 역시 문제 발견과 개선 과정에 참여하기 쉬워집니다.

### 4. 측정에서 끝내지 않고 행동으로 연결했습니다

이것이 두 사례에서 가장 중요한 공통점입니다.

두 기업 모두 대시보드를 만드는 것에서 끝나지 않았습니다.

**측정 → 문제 발견 → 원인 파악 → 개선 → 다시 측정**

이라는 과정을 반복했습니다.

결국 개발 생산성 데이터의 가치는 숫자 자체가 아니라 **그 숫자가 어떤 행동을 만들어냈는가**에 있습니다.

## DORA와 SPACE를 도입하면 개발 생산성이 자동으로 좋아질까요?

그렇지는 않습니다.

DORA나 SPACE를 도입한다고 해서 리드 타임이 자동으로 감소하거나 개발자의 만족도가 높아지는 것은 아닙니다.  
프레임워크는 **조직을 개선하는 방법 그 자체라기보다 현재 상태를 이해하고 올바른 질문을 하기 위한 도구**에 가깝습니다.

Uluru와 PharmaX 역시 지표를 측정했기 때문에 성과가 발생한 것이 아니라, **데이터를 통해 문제를 발견하고 → 팀이 원인을 논의하고 → 실제 프로세스를 변경하고 → 다시 결과를 확인했기 때문에** 성과로 이어질 수 있었습니다.

따라서 DORA나 SPACE를 도입할 때는 **“어떤 지표를 측정할까?”** 보다 먼저 **“이 데이터를 보고 우리는 어떤 의사결정을 내릴 것인가?”** 를 생각하는 것이 중요합니다.

---

## DORA·SPACE 실제 적용에 대해 자주 묻는 질문

### Q. DORA나 SPACE를 도입하면 어떤 성과를 기대할 수 있나요?

조직의 문제와 개선 활동에 따라 결과는 달라집니다. Uluru에서는 리드 타임 41.7% 감소와 Merge PR 51.9% 증가가 나타났고, PharmaX에서는 최대 220시간이었던 리드 타임이 약 20시간 수준으로 개선됐습니다. 중요한 것은 특정 수치를 그대로 목표로 삼기보다 현재 조직의 문제에 적합한 지표를 선택하는 것입니다.

### Q. 모든 DORA·SPACE 지표를 측정해야 하나요?

그럴 필요는 없습니다. 실제 사례에서도 각 기업은 조직의 목표와 문제에 맞는 데이터를 선택했습니다. 측정 가능한 모든 데이터를 수집하기보다 의사결정에 필요한 지표부터 시작하는 것이 중요합니다.

### Q. 개발 생산성 지표를 개인 평가에 활용해도 될까요?

PR 수, 커밋 수, 리드 타임 등의 데이터를 개인의 생산성과 직접 동일시하는 것은 주의할 필요가 있습니다. Uluru 사례에서도 개인 평가가 아니라 팀 단위의 생산성 개선을 목적으로 지표를 활용했습니다.

### Q. 데이터를 측정한 다음에는 무엇을 해야 하나요?

지표의 변화가 나타났다면 원인을 찾고 실제 프로세스 개선으로 연결해야 합니다. PharmaX처럼 정량 데이터와 회고를 함께 활용해 숫자 뒤에 있는 원인을 살펴보는 것도 하나의 방법입니다.

## 성과를 만든 것은 '측정'이 아니라 '측정 이후의 행동'입니다

앞선 1편과 2편에서 DORA와 SPACE의 개념과 차이를 살펴봤다면, 실제 사례에서 확인할 수 있는 것은 **프레임워크를 어떻게 조직의 행동으로 연결할 것인가**입니다.

Uluru는 팀과 제품의 특성에 맞는 생산성 지표를 설계했고, 그 결과 **리드 타임을 41.7% 줄이고 Merge PR을 51.9% 늘렸습니다.**

PharmaX는 리드 타임과 리뷰 프로세스 등 해결해야 할 문제와 관련된 데이터를 집중적으로 관리했고, **최대 220시간이었던 리드 타임을 약 20시간 수준까지 줄였습니다.**

하지만 이 숫자를 그대로 벤치마크로 삼는 것은 이 글의 핵심이 아닙니다.  
두 기업에서 공통적으로 발견되는 것은 다음과 같은 흐름입니다.

> **문제를 정의한다 → 필요한 데이터를 측정한다 → 병목을 발견한다 → 팀이 원인을 찾는다 → 프로세스를 개선한다 → 다시 측정한다**

결국 DORA와 SPACE의 가치는 대시보드에 표시되는 숫자 자체에 있는 것이 아닙니다.

**데이터를 통해 개발 조직이 더 좋은 질문을 하고, 더 나은 의사결정을 내리고, 실제 행동을 바꿀 수 있게 만드는 것**에 있습니다. 그렇다면 이제 다음 질문은 더욱 실무적으로 바뀝니다.

**“우리 조직에서 DORA와 SPACE를 실제로 적용하려면 무엇부터 시작해야 할까?”**

다음 글에서는 DORA와 SPACE를 개발 조직에 적용하기 위한 **구체적인 측정 방법과 도입 프로세스**를 살펴보겠습니다.

제품 개발팀의 생산성을 파악하고 싶으세요?  
지금 무료 체험 버전을 시작하세요!

[무료로 시작하기](https://kr.findy-team.io/contact-us)

![Findy Team+](https://kr.findy-team.io/hubfs/kr-home-assets/11-s-300x42_48c547e7-c8bf-46d6-a465-4746f75c9da3.svg)

Menu

[도입 사례](https://kr.findy-team.io/customers) [블로그](https://kr.findy-team.io/blog) [뉴스룸](https://kr.findy-team.io/newsroom) [로그인](https://findy-team.io/login?lang=en)

Company

[회사 소개](https://kr.findy-team.io/aboutus)

Language

[English](https://en.findy-team.io/) [日本語](https://findy-team.io/)

Follow us

[![](https://kr.findy-team.io/hubfs/kr-home-assets/04-s-150x150_ad141ed3-f00b-4b4a-ad93-306e56e01ffa.svg)](https://www.facebook.com/findyteamplus) [![](https://kr.findy-team.io/hubfs/kr-home-assets/03-s-1200x1227_06cf8e1b-a4be-4d23-bcb7-5de13610fdd5.svg)](https://x.com/FindyTeamPlus)

[Trust Center](https://kr.findy-team.io/trust) | [Terms of Service](https://kr.findy-team.io/terms) | [Privacy Policy](https://kr.findy-team.io/privacy-policy)

© 2026 Findy Korea Inc. All Rights Reserved.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Findy Team+",
    "url" : "https://kr.findy-team.io/media/author/findy-team"
  },
  "dateModified" : "2026-11-11T12:36:53.356Z",
  "datePublished" : "2024-10-30T15:30:00.000Z",
  "headline" : "DORA와 SPACE 실제 적용 사례: 개발 생산성은 어떻게 개선됐을까? | Findy Team+",
  "image" : [ "https://kr.findy-team.io/hubfs/Imported_Blog_Media/s-1672x941_v-fms_webp_037411a4-302d-401f-ac03-cd3fb1e12f3a.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://kr.findy-team.io/media/real-world-stories-dora-space",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject"
    },
    "name" : "Findy Korea Inc."
  }
}
```