15.2 개발 방법론 — 방법론은 조율 비용에 대한 대응이다

폭포수·애자일·스크럼·칸반은 유행어의 목록이 아니라, 각각 특정 실패에 대한 대응이다. 방법론을 "무엇을 해야 하나"의 규칙으로 받으면 왜 하는지를 잃고, 원리는 사라진 채 의례만 남는다. 이 문서는 방법론을 요구 불확실성·조율 비용·피드백 지연이라는 근본 문제로 환원하고, 배치 크기와 피드백 주기를 프로세스 무게의 핵심 변수로 세우며, 애자일의 원리가 형식화되어 원리를 배신하는 지점을 판별한다.

학습 목표

• 폭포수·애자일·린을 각각이 대응한 문제(요구 불확실성, 조율 비용, 피드백 지연)로 설명한다.
• 배치 크기와 피드백 주기를 근거로 프로세스의 무게가 정당한지 판단한다.
• 애자일 선언의 원리와 그것이 형식화된 프랙티스(스크럼 의례 등)의 차이를 구분한다.
• 방법론의 오용(cargo cult, 벨로시티 타게팅, 의례화)을 식별하고 결과 지표로 프로세스를 평가한다.

배경: 왜 이렇게 많은 방법론이 있는가

소프트웨어를 만드는 데는 두 가지 본질적 어려움이 있고, 모든 방법론은 이 둘을 어떻게 다룰지에 대한 서로 다른 답이다.

• 요구 불확실성: 무엇을 만들어야 하는지를 처음에는 정확히 모른다. 사용자도, 만드는 사람도, 만들어 보고 써 봐야 안다. 이것은 게으름이나 무능이 아니라 소프트웨어라는 매체의 성질이다. 챕터 13이 다룬 요구사항 발견의 어려움이 여기서 온다.
• 조율 비용: 여러 사람이 여러 달에 걸쳐 하나의 시스템을 만든다. 각자의 작업을 합치고, 서로의 결정을 알리고, 충돌을 해소하는 데 비용이 든다. 사람이 늘수록 소통 경로는 조합적으로 늘어난다.

방법론은 이 두 어려움의 트레이드오프를 다르게 잡는다. 계획을 앞세워 조율 비용을 낮추면 불확실성에 취약해지고, 적응을 앞세워 불확실성에 강해지면 조율에 규율이 더 필요해진다. 어떤 방법론이 "옳은가"는 맥락 — 불확실성이 얼마나 높고, 잘못 만들었을 때 되돌리는 비용이 얼마인가 — 에 달렸다. 방법론을 그것이 대응한 문제와 분리해 규칙으로만 받으면, 자기 맥락에 맞지 않는 규칙을 따르면서 왜 안 되는지 모르게 된다.

핵심 개념

폭포수: 값비싼 후기 변경에 대한 대응

폭포수(waterfall)는 요구 분석 → 설계 → 구현 → 검증 → 유지보수를 순차 단계로 보고, 각 단계를 문서로 마무리한 뒤 다음으로 넘어간다. 이 모델의 문제의식은 분명하다. 변경이 늦게 발견될수록 비싸다. 하드웨어 설계, 건설, 규제 인증처럼 후기 변경 비용이 극단적으로 높은 영역에서는 단계적 검증과 문서 계약이 합리적이다. 뒷단계에서 앞단계의 결정을 뒤집는 것이 재앙이므로, 앞단계에서 최대한 확정하고 넘어간다.

역설은 폭포수의 출처다. 흔히 폭포수의 기원으로 인용되는 Winston Royce의 1970년 논문은 사실 순수한 순차 모델을 위험하다고 비판하며 반복(iteration)과 프로토타이핑을 권했다. 다이어그램만 인용되고 논지는 빠진 채 "순차 단계 모델"로 굳은 것이다. 이 오독의 역사 자체가 이 문서의 주제 — 원리와 형식의 분리 — 를 예고한다.

폭포수의 실패 지점은 요구 불확실성이 높을 때다. 초기 명세가 틀리면 그 위에 쌓인 설계·구현이 모두 재작업 대상이 되고, 그 사실이 검증 단계에 가서야 드러난다. 피드백 루프가 프로젝트 전체 길이만큼 길다. 6개월을 들여 만든 것이 사용자가 원한 것이 아니었다는 사실을, 6개월 뒤에 안다. 이 긴 피드백 루프가 다음 방법론들이 공격한 지점이다.

애자일: 피드백 루프를 짧게 만드는 대응

2001년 애자일 선언(Agile Manifesto)은 방법론이 아니라 네 가지 가치와 열두 원리다. 네 가치는 각각 왼쪽을 오른쪽보다 더 중시한다는 형태로 쓰였다.

• 공정과 도구보다 개인과 상호작용
• 포괄적 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협력
• 계획을 따르기보다 변화에 대응

이 가치들을 관통하는 하나의 메커니즘은 배치 크기를 줄여 피드백을 앞당기는 것이다. 6개월치 명세를 한 번에 검증하는 대신, 2주치 작동하는 소프트웨어를 만들어 사용자에게 보이고 배운다. 요구 불확실성이 높을 때 이 짧은 루프는 재작업 비용을 근본적으로 줄인다. 틀린 방향을 6개월이 아니라 2주 만에 발견하기 때문이다.

애자일은 단일 방법이 아니라 이 원리를 다른 각도에서 구현한 여러 실천의 우산이다.

• XP(익스트림 프로그래밍): 기술 프랙티스에 집중한다. 지속적 통합(CI), 테스트 주도 개발(챕터 14), 페어 프로그래밍, 짧은 릴리스 주기. 피드백 루프를 코드 수준까지 짧게 당긴다.
• 스크럼(Scrum): 조율 프랙티스에 집중한다. 고정 길이 스프린트, 역할(제품 책임자·스크럼 마스터·개발팀), 의례(계획·데일리·리뷰·회고). 팀의 조율 리듬을 정형화한다.
• 칸반(Kanban): 흐름에 집중한다. 작업을 시각화하고 진행 중 작업(WIP)을 제한해 병목을 드러낸다. 뒤에서 볼 린에서 왔다.

핵심은 이 실천들이 원리의 서로 다른 구현이라는 점이다. 스프린트나 스탠드업 같은 형식은 원리(짧은 피드백, 변화 대응)를 실현하는 수단이지 그 자체가 목적이 아니다. 이 구분이 무너질 때 다음 절의 함정이 생긴다.

배치 크기와 피드백 지연이 프로세스의 핵심 변수다

방법론 이름을 걷어내면, 프로세스 설계의 실질은 두 변수로 압축된다. **한 번에 얼마를 통합·전달하는가(배치 크기)**와 피드백을 받기까지 얼마가 걸리는가(피드백 지연). 이 둘은 15.1의 통합 빈도, 15.3의 배포 주기와 같은 변수다.

작은 배치의 이점은 여러 층에서 복리로 작용한다.

• 빠른 피드백: 틀린 방향을 일찍 발견해 재작업이 싸다.
• 작은 폭발 반경: 각 변경이 작으므로 장애 시 원인 범위가 좁고 되돌리기 쉽다(14.3의 폭발 반경).
• 낮은 통합 비용: 자주 통합하면 발산이 작아 머지 충돌이 작다(15.1의 merge hell).
• 꾸준한 흐름: 큰 배치가 만드는 "통합 지옥 → 안정화 기간 → 다음 큰 배치"의 롤러코스터 대신 일정한 리듬이 생긴다.

작은 배치의 비용은 배치당 고정 오버헤드(트랜잭션 비용)다. 배포·리뷰·테스트에 매번 드는 고정 비용이 크면 작게 나눌수록 총 오버헤드가 커진다. 그래서 작은 배치를 값싸게 만드는 것 — 자동화된 CI/CD, 빠른 테스트, 가역적 배포 — 이 전제가 된다. 이것이 방법론(15.2)과 자동화(15.3)가 분리될 수 없는 이유다. 자동화가 배치당 비용을 낮추면 더 작은 배치가 경제적이 되고, 더 작은 배치는 피드백을 앞당긴다.

프로세스의 "무게"(문서·의례·승인 단계의 양)는 이 변수로 정당화되어야 한다. 무게 자체는 좋지도 나쁘지도 않다. 불확실성이 낮고 후기 변경 비용이 극단적으로 높은 맥락(항공 소프트웨어, 의료기기, 결제 코어)에서는 무거운 검증이 정당하다. 불확실성이 높고 되돌리기가 싼 맥락(탐색적 제품 기능)에서는 같은 무게가 순수한 낭비다. 프로세스 무게는 배치 크기·되돌림 비용·불확실성에서 역산하는 것이지, 방법론이 지시하는 상수가 아니다.

형식화의 함정: 원리와 의례가 분리될 때

애자일 선언의 마지막 문장은 자주 잊힌다. "오른쪽 항목도 가치가 있지만, 우리는 왼쪽 항목을 더 중시한다." 문서·계획·프로세스를 버리라는 것이 아니라 목적(작동하는 소프트웨어, 변화 대응)에 종속시키라는 것이다. 이 종속 관계가 끊길 때 방법론은 자신이 공격했던 것으로 변한다.

• Cargo cult(형식 모방): 원리는 이해하지 못한 채 형식만 도입한다. 스탠드업·스프린트·회고 같은 의례는 그대로 돌아가지만, 그것이 실현해야 할 짧은 피드백과 적응은 일어나지 않는다. 데일리 스탠드업이 "각자 어제 한 일 보고"로 굳으면 조율이라는 목적은 사라지고 상태 보고 회의만 남는다. 스프린트가 "2주 단위 미니 폭포수"가 되면 배치만 잘게 나뉘었을 뿐 피드백 루프는 여전히 스프린트 끝에 몰린다.
• 벨로시티 타게팅(Goodhart의 법칙): 벨로시티(스프린트당 완료한 스토리 포인트)는 팀의 계획 도구인데, 경영이 이를 목표·평가 지표로 삼는 순간 왜곡된다(14.2의 Goodhart). 팀은 추정을 부풀려 벨로시티를 "올리고", 지표는 좋아지지만 실제 전달은 그대로다. 측정이 목표가 되면 좋은 측정이기를 그친다.
• 프로세스 비대화의 역설: "애자일 도입"이 새로운 역할·회의·도구·인증의 층을 쌓아 오히려 폭포수보다 무거운 프로세스가 되는 경우가 흔하다. 원리(가벼움, 적응)를 잃고 형식(의례, 프레임워크)만 확장한 결과다. 방법론이 목적이 되면 방법론이 짐이 된다.

이 함정들의 공통 진단법은 하나다. "이 형식이 어떤 원리를 실현하는가"를 물어 답이 없으면 그 형식은 의례다. 스탠드업이 조율을 만드는가, 회고가 실제 변화를 만드는가, 추정이 계획을 돕는가. 답이 "원래 하는 거라서"라면 형식만 남은 것이다.

프로세스는 결과 지표로 평가한다

방법론의 오용을 피하는 실질적 방법은 프로세스를 의도가 아니라 결과로 측정하는 것이다. "우리는 애자일을 한다"가 아니라 "우리의 전달이 실제로 빠르고 안전한가"를 본다. Accelerate의 DORA 연구가 정립한 네 지표가 이 측정의 기준이 됐다.

지표	재는 것	좋은 방향
배포 빈도(deployment frequency)	얼마나 자주 운영에 배포하는가	높을수록 배치가 작다는 신호
변경 리드타임(lead time for changes)	커밋이 운영에 도달하기까지의 시간	짧을수록 피드백 루프가 짧다
변경 실패율(change failure rate)	배포 중 장애·롤백을 부른 비율	낮을수록 안전하다
서비스 복구 시간(time to restore)	장애에서 회복하기까지의 시간	짧을수록 가역적이다

이 지표들의 중요한 발견은 속도(앞 두 지표)와 안정성(뒤 두 지표)이 상충하지 않는다는 것이다(인트로에서 예고). 자주·작게 배포하는 조직이 실패율도 낮고 복구도 빠르다. 원인은 이 문서의 관점과 같다. 작은 배치는 폭발 반경이 작고, 자주 지나는 경로는 자동화·관측이 잘 갖춰지며, 가역적 배포가 실패를 값싸게 만든다. 이 지표들은 방법론 이름과 무관하게 전달 경로가 실제로 건강한가를 측정하므로, "우리는 무슨 방법론을 쓰는가"보다 나은 질문을 던지게 한다.

실무 관점

방법론 선택은 맥락 의존이다

같은 조직 안에서도 시스템마다 답이 다르다. 결제 정산 코어는 되돌림 비용과 규제 요구가 높아 무거운 검증·변경 관리가 정당하고, 실험적 추천 기능은 불확실성이 높고 되돌리기가 싸므로 가벼운 반복이 맞다. "전사 단일 방법론"을 강제하면 한쪽은 위험하고 한쪽은 낭비다. 판단 기준은 방법론의 이름이 아니라 그 시스템의 불확실성 × 되돌림 비용이다.

스크럼 의례가 가치를 잃는 신호

회고에서 나온 개선 항목이 다음 스프린트에 실행되지 않고 쌓이기만 하면, 회고는 적응이 아니라 감정 배출 의례가 된 것이다. 데일리가 30분을 넘기며 상세 논의로 흐르면 조율이 아니라 회의가 된 것이다. 스프린트 리뷰에 실제 사용자·이해관계자가 없으면 피드백이 아니라 내부 시연이 된 것이다. 이 신호가 보이면 의례를 더 엄격히 지키는 것이 아니라 그 의례가 실현해야 할 원리로 돌아가 형식을 다시 설계해야 한다.

추정과 벨로시티의 건강한 사용

추정과 벨로시티는 팀 내부의 계획 도구로 쓸 때 유용하고, 팀 간 비교나 성과 평가에 쓸 때 파괴적이다. 팀 A의 5포인트와 팀 B의 5포인트는 다른 척도이므로 비교가 무의미하고, 비교되는 순간 인플레가 시작된다. "포인트를 많이 쳐낸 팀"이 아니라 "가치를 자주·안전하게 전달한 팀"을 보려면 벨로시티가 아니라 DORA 지표를 본다.

Conway의 법칙: 조직이 아키텍처를 결정한다

Melvin Conway의 1968년 관찰 — "시스템을 설계하는 조직은 그 조직의 소통 구조를 닮은 설계를 만든다" — 은 프로세스가 코드에 남기는 흔적을 설명한다. 팀 경계가 모듈 경계가 되고, 팀 간 소통 비용이 높으면 그 경계의 인터페이스가 경직된다. 이 법칙의 실무적 활용이 **역콘웨이 전략(inverse Conway maneuver)**이다. 원하는 아키텍처(예: 독립 배포 가능한 서비스)가 있으면, 그에 맞는 조직 구조(독립적으로 배포·운영하는 팀)를 먼저 만들어 아키텍처를 유도한다. 마이크로서비스가 조직 정렬 없이 실패하는 흔한 이유가 이것이다. 코드는 서비스로 쪼갰지만 팀과 배포 파이프라인은 여전히 하나라, 소통 구조가 아키텍처를 다시 결합으로 끌어당긴다.

더 깊이: 린과 흐름의 관점

칸반과 "작은 배치"의 뿌리는 도요타 생산 시스템(Toyota Production System)에서 정립된 린(lean)이다. 린의 핵심 통찰은 제조에서 왔지만 소프트웨어 전달에 그대로 적용된다. 재고(inventory)는 낭비다. 제조에서 완성되지 않은 부품 더미가 재고이듯, 소프트웨어에서 통합·배포되지 않은 채 브랜치에 쌓인 코드, 검증되지 않은 채 대기하는 기능, 배포됐지만 노출되지 않은 코드가 모두 "재고"다. 재고는 자본이 묶이고(피드백 없이 대기), 진부화 위험을 안고(요구가 바뀌면 재작업), 문제를 숨긴다(어디가 병목인지 안 보임).

칸반이 WIP(진행 중 작업)를 제한하는 이유가 여기 있다. 진행 중 작업을 강제로 줄이면 재고가 줄어 병목이 드러나고, 팀은 새 일을 시작하기보다 있는 일을 끝내는 데 집중하게 된다. 리틀의 법칙(Little's Law, 챕터 8의 큐 이론과 같은 관계)은 이를 정량화한다. 평균 리드타임 = 평균 WIP ÷ 평균 처리율. 처리율이 같다면 WIP를 줄이는 것이 리드타임을 줄이는 직접적 수단이다. "일을 덜 시작하고 더 끝내라"는 칸반의 격언은 이 산수의 표현이다. DORA의 변경 리드타임 지표가 개선되지 않는 팀은 대개 처리율이 아니라 과도한 WIP(동시에 벌여 놓은 미완성 작업)가 문제다.

정리

• 소프트웨어의 두 본질적 어려움은 요구 불확실성과 조율 비용이고, 모든 방법론은 이 둘의 트레이드오프에 대한 서로 다른 답이다.
• 폭포수는 값비싼 후기 변경에 대한 대응으로 불확실성이 낮은 맥락에서 정당하고, 불확실성이 높으면 긴 피드백 루프가 재작업을 폭발시킨다. 애자일은 배치를 줄여 피드백을 앞당기는 대응이다.
• 방법론 이름을 걷어내면 프로세스의 실질은 배치 크기와 피드백 지연 두 변수다. 작은 배치의 이점은 복리로 작용하고, 그 전제는 배치당 비용을 낮추는 자동화다. 프로세스 무게는 불확실성×되돌림 비용에서 역산한다.
• 형식화의 함정은 원리와 의례가 분리될 때 생긴다. "이 형식이 어떤 원리를 실현하는가"에 답이 없으면 의례다. 벨로시티를 목표로 삼으면 Goodhart로 왜곡된다.
• 프로세스는 의도가 아니라 결과(DORA: 배포 빈도·리드타임·변경 실패율·복구 시간)로 평가한다. 속도와 안정성은 상충하지 않으며, 잘 설계된 전달 경로에서 함께 온다. Conway의 법칙에 따라 조직 구조가 아키텍처에 반영된다.

확인 문제

1. 한 팀이 "우리는 스크럼을 한다"며 2주 스프린트를 돌린다. 그러나 각 스프린트는 계획 → 2주 개발 → 마지막 날 통합·테스트 → 데모의 순서로 진행되고, 통합에서 나온 문제는 다음 스프린트로 넘긴다. 이 운영이 애자일의 어떤 원리를 실현하지 못하고 있는지, 그리고 스프린트라는 형식이 어떤 함정에 빠졌는지 진단하라.
2. 경영진이 "팀 생산성을 높이자"며 모든 팀의 스프린트 벨로시티를 대시보드에 걸고 분기마다 비교하기 시작했다. 6개월 뒤 모든 팀의 벨로시티가 올랐지만 실제 기능 전달 속도와 장애율은 그대로다. 무슨 일이 일어났는지 설명하고, 생산성을 보려면 무엇을 대신 측정해야 하는지 제시하라.
3. 어떤 조직이 규제가 엄격한 결제 정산 시스템과 실험적 A/B 테스트 기능을 같은 팀이 개발한다. CTO가 "일관성을 위해 두 시스템에 같은 릴리스 프로세스(2주에 1회, 3단계 승인)를 적용하라"고 지시한다. 이 지시가 두 시스템 각각에 만드는 문제를, 불확실성과 되돌림 비용의 관점에서 설명하라.
4. 한 팀의 DORA 지표에서 배포 빈도는 높은데(하루 여러 번) 변경 리드타임이 유독 길다(커밋에서 배포까지 평균 5일). 이 조합이 가리키는 병목의 후보를 리틀의 법칙과 WIP 개념으로 추론하라.

정답과 해설

1. 실현하지 못한 원리는 짧은 피드백 루프다. 통합·테스트를 스프린트 마지막 날에 몰면, 2주 동안 만든 것이 실제로 합쳐져 동작하는지에 대한 피드백이 스프린트 끝에 가서야 온다. 배치만 2주로 나뉘었을 뿐 각 스프린트 내부는 여전히 순차(개발 후 통합)이므로, 이것은 "2주 단위 미니 폭포수"다. 스프린트라는 형식은 cargo cult 함정에 빠졌다 — 스크럼의 겉모습(고정 스프린트, 데모)은 있으나 그것이 실현해야 할 지속적 통합과 조기 피드백은 없다. 게다가 통합 문제를 다음 스프린트로 미루는 것은 재고(미완성 통합)를 쌓는 것이고, 이 부채가 스프린트마다 누적된다. 처방은 스프린트를 더 엄격히 지키는 것이 아니라 원리로 돌아가는 것 — 통합을 스프린트 끝이 아니라 매일 하도록(15.1의 trunk-based, 15.3의 CI) 만들어 피드백을 스프린트 내부로 당긴다.
2. Goodhart의 법칙이 작동했다. 벨로시티는 팀 내부 계획 도구인데 평가·비교 지표가 되는 순간, 팀은 실제 전달을 늘리는 대신 추정을 부풀리는 것이 합리적이 된다(같은 일에 더 많은 포인트를 매김). 게다가 팀 A와 B의 포인트는 서로 다른 척도라 비교 자체가 무의미하다. 결과적으로 지표는 개선됐지만(인플레), 그것이 재려던 실제 전달은 그대로다. 측정이 목표가 되면 좋은 측정이기를 그친다. 대안: 벨로시티 같은 대리(proxy) 지표가 아니라 결과 지표인 DORA 네 지표(배포 빈도·리드타임·변경 실패율·복구 시간)를 본다. 이들은 팀 간 척도가 통일돼 있고(시간·비율), 부풀리기 어려우며(실제 운영 사건에서 계측), 속도와 안정성을 함께 본다. 다만 이조차 개별 팀 순위 매기기가 아니라 조직 전체 추세로 봐야 왜곡을 피한다.
3. 결제 정산: 불확실성이 낮고(요구가 규제·회계 규칙으로 명확) 되돌림 비용이 극단적으로 높다(잘못된 정산은 금전·법적 피해). 여기서는 2주 1회 + 3단계 승인이 오히려 부족할 수도 있는 정당한 무게다 — 문제는 없거나 작다. A/B 테스트 기능: 불확실성이 높고(가설을 검증하려 만듦) 되돌림 비용이 낮다(플래그로 끄면 됨). 여기에 2주 1회 + 3단계 승인을 강제하면, 짧아야 할 실험 피드백 루프가 프로세스에 막혀 늘어진다. 가설 하나를 검증하는 데 몇 주가 걸리면 실험의 가치가 사라지고, 팀은 프로세스를 우회하거나 실험 자체를 포기하게 된다. "일관성"이라는 명분이 한 시스템에는 무의미하고 다른 시스템에는 낭비를 강제한다. 프로세스 무게는 시스템별 불확실성×되돌림 비용에서 역산해야 한다.
4. 높은 배포 빈도는 배포 파이프라인 자체는 자주 도는데(처리율은 낮지 않음), 리드타임이 긴 것은 커밋이 배포되기까지 어딘가에서 대기한다는 뜻이다. 리틀의 법칙(리드타임 = WIP ÷ 처리율)에서 처리율이 낮지 않은데 리드타임이 길다면 WIP가 크다. 후보 병목: (a) 코드 리뷰 대기 — PR이 리뷰어를 기다리며 쌓임. (b) 긴 브랜치 수명 — 커밋 후 머지까지 며칠씩 브랜치에 머묾(15.1의 배치 크기). (c) 릴리스 배칭 — 커밋은 자주 되지만 실제 배포는 모아서 나감(배포 "빈도"가 높아도 특정 커밋이 자기 차례를 오래 기다림). (d) 수동 승인·QA 게이트에서의 대기. 공통 처방은 새 작업을 덜 시작하고(WIP 제한) 대기 중인 것을 먼저 흘려보내는 것 — 리뷰 SLA, 짧은 브랜치, 커밋별 즉시 배포 파이프라인. "일을 덜 시작하고 더 끝내라"가 이 상황의 처방이다.

참고 자료

• Manifesto for Agile Software Development와 12 Principles (2001) — 애자일의 네 가치와 열두 원리의 1차 자료로, 원리와 형식을 구분하는 기준이다.
• Winston W. Royce, Managing the Development of Large Software Systems (1970) — 흔히 폭포수의 기원으로 인용되지만 실제로는 순수 순차 모델을 비판하고 반복을 권한 원 논문이다.
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (IT Revolution, 2018) — DORA 네 지표와 속도·안정성이 상충하지 않는다는 발견의 근거다.
• Melvin E. Conway, How Do Committees Invent? (1968) — 조직 소통 구조가 시스템 설계에 반영된다는 Conway의 법칙 원문이다.
• David J. Anderson, Kanban (Blue Hole Press, 2010) — 소프트웨어에 린·흐름·WIP 제한을 적용한 칸반의 기준 문헌이다.
• Martin Fowler, The New Methodology — 계획 주도와 적응 주도 방법론의 구분과 각각의 적용 조건을 정리한 자료다.