콘텐츠로 이동

2026#

  • 카테고리 AI/개발
  • 읽는시간 4분

Harness Engineering — AI 코딩 에이전트를 제어하는 기술

AI 코딩 에이전트가 만든 코드를 신뢰할 수 있으려면, 코드를 만드는 환경 자체를 설계해야 한다.

하네스 엔지니어링이란

2026년 초, OpenAI가 Codex를 활용한 내부 실험 결과를 공개하면서 "Harness Engineering"이라는 표현이 주목받기 시작했다. 100만 줄의 코드를 수동 작성 0줄로 만들었다는 실험이다. 3명으로 시작해 7명으로 늘어난 팀이 5개월간 약 1,500개의 PR을 병합했고, 1인당 하루 평균 3.5개의 PR을 처리했다.

핵심 원칙은 간단하다.

"Humans steer. Agents execute."

사람은 방향을 잡고, 에이전트가 실행한다. 여기서 "방향을 잡는다"는 것이 단순히 프롬프트를 잘 쓰는 것이 아니다. 에이전트가 작업하는 환경 자체를 설계하는 것이다. 이것이 하네스 엔지니어링이다.

전통적인 test harness가 "인간이 작성한 코드가 맞는지 검증하는 환경"이라면, agent harness engineering은 "AI 에이전트가 올바른 코드를 만들 수 있는 환경 전체를 설계하는 것"이다.

구분 Test Harness Agent Harness Engineering
대상 인간이 작성한 코드 검증 AI agent의 코드 생산 환경 전체
범위 테스트 실행, 리포트 스펙 전달 → 코드 생성 → 검증 → 피드백 루프
핵심 질문 코드가 맞는가? agent가 올바른 코드를 만들 수 있는 환경인가?
설계 대상 테스트 프레임워크 문서 구조, 제약 시스템, 컨텍스트 관리, 자동화

하네스 엔지니어링이 없으면

AI 코딩 에이전트를 아무 환경에 그냥 풀어놓으면 어떤 일이 벌어지는가.

1. 아키텍처 부식

에이전트는 "지금 당장 동작하는 코드"를 만드는 데 최적화되어 있다. 프로젝트 전체의 아키텍처 원칙이나 모듈 경계를 지키는 것은 관심 밖이다. 계층 간 의존성이 꼬이고, 추상화가 무너지고, 코드베이스가 점진적으로 썩는다. 인간 개발자도 같은 실수를 하지만, 에이전트는 훨씬 빠른 속도로 같은 실수를 반복한다.

2. 컨텍스트 분실

에이전트가 볼 수 없는 정보는 존재하지 않는 것과 같다. Slack에서 합의한 설계 결정, Google Docs에 적은 요구사항, 팀원의 머릿속에 있는 암묵지 — 이것들은 에이전트의 세계에 없다. 결과적으로 에이전트는 이미 결정된 사항을 무시하고, 이미 해결된 문제를 다시 만들어낸다.

3. 검증 부재

에이전트가 "완료했습니다"라고 하면 정말 완료된 건가? 테스트가 통과한다고 해서 요구사항을 충족하는 건 아니다. 스펙과 구현 사이의 정합성을 기계적으로 검증하지 않으면, 겉으로는 동작하지만 실제로는 다른 것을 만드는 상황이 생긴다.

4. 피드백 루프 부재

에이전트가 실패했을 때 무엇이 잘못됐는지 자동으로 파악하고 재시도하는 구조가 없으면, 결국 인간이 하나하나 확인하고 다시 지시해야 한다. 이러면 에이전트를 쓰는 의미가 반감된다.

5. 규모 확장 불가

위 문제들은 코드베이스가 작을 때는 사람이 감당할 수 있다. 하지만 코드가 수천, 수만 줄을 넘기는 순간 사람의 주의력만으로는 통제할 수 없게 된다. OpenAI가 하네스 엔지니어링을 제안한 것도 바로 이 지점이다.

하네스 엔지니어링은 이 문제를 어떻게 해결하는가

하네스 엔지니어링의 접근은 "에이전트에게 잘 시키는 것"이 아니라 "에이전트가 잘못하기 어려운 환경을 만드는 것"이다.

저장소를 시스템 오브 레코드로

에이전트가 참조할 모든 정보를 저장소 안에 버전 관리한다. 아키텍처 문서, 설계 원칙, 코딩 표준, 실행 계획이 마크다운 파일로 저장소에 존재한다. Slack 스레드도, Google Docs도, 사람의 기억도 아닌 — 저장소가 유일한 진실의 원천이다.

OpenAI는 이를 "AGENTS.md를 백과사전이 아닌 목차로 취급하라"고 표현했다. AGENTS.md는 100줄 내외의 짧은 진입점이고, 실제 지식은 docs/ 디렉토리에 구조화되어 있다.

기계적 강제

인간에게 "이 규칙을 지켜주세요"라고 부탁하듯 에이전트에게도 부탁만 하면 안 된다. 에이전트는 지시를 따를 수도 있고 무시할 수도 있다. 따라서 규칙은 기계적으로 강제한다.

  • 아키텍처 경계: 커스텀 린터가 모듈 간 import 방향을 검사한다. 위반하면 CI가 실패한다.
  • 코딩 표준: pre-commit hook이 네이밍 컨벤션, 파일 크기 제한, 구조화된 로깅을 강제한다.
  • 품질 게이트: 테스트 통과, 커버리지 임계값, 정적 분석 통과가 PR 병합 조건이다.

에이전트가 만든 코드가 이 게이트를 통과하지 못하면 자동으로 거부된다. 여기에 에이전트의 "판단"이 개입할 여지는 없다.

피드백 루프

검증 실패 → 에이전트에게 실패 원인 전달 → 에이전트가 수정 → 재검증. 이 루프가 자동으로 돌아야 한다. OpenAI의 경우 에이전트가 자기 변경사항을 자체적으로 리뷰하고, 다른 에이전트에게도 리뷰를 요청하며, 모든 리뷰어가 만족할 때까지 반복하는 루프를 구축했다.

점진적 공개

에이전트에게 한꺼번에 모든 정보를 주지 않는다. 작은 진입점(AGENTS.md)에서 시작해서, 필요한 시점에 필요한 문서를 참조하도록 안내한다. 컨텍스트 윈도우는 유한하다. 불필요한 정보로 채우면 정작 중요한 정보를 놓친다.

격리된 실행 환경

각 작업을 독립된 환경에서 실행한다. git worktree 단위로 앱을 부팅하고, 임시 관찰 스택(로그, 메트릭)을 붙이고, 작업이 끝나면 환경을 정리한다. 한 에이전트의 작업이 다른 에이전트의 작업에 영향을 주지 않는다.

어떤 도구들이 있는가

하네스 엔지니어링의 핵심 역할을 수행하는 도구들은 크게 두 부류로 나뉜다.

대형 도구 — 이미 대규모 커뮤니티를 형성한 스펙 주도 개발 도구들이다. 스펙 관리, 태스크 분해, 제약 주입 등을 다룬다.

도구 Stars 핵심
Spec Kit (GitHub) 83,000+ Phase gate 방식 스펙 주도 개발. constitution으로 에이전트 행동 제약.
BMAD-METHOD 42,600+ 12+ 전문 페르소나로 역할 분리. 구현자와 검증자가 다르다.
OpenSpec (Fission-AI) 35,000+ change 단위 격리. brownfield에 강함. "유연하되 엄격하지 않게".
Hive (Aden) 9,900+ 목표 주도 에이전트 프레임워크. 자기 개선 루프 내장. YC 투자.
Kiro (AWS) 3,300+ 스펙 주도 IDE. Steering + Hooks로 피드백 루프 자동화.

신흥 도구 — 2026년 초에 등장하기 시작한 하네스 전용 도구들이다. 검증, 측정, 기계적 강제에 특화되어 있다. 아직 초기 단계지만 독특한 접근을 가지고 있어 주시할 가치가 있다.

도구 Stars 핵심
Entrix 31 규칙을 실행 가능한 가드레일로 변환. tier별 검증.
AI Harness Scorecard 14 리포의 하네스 수준을 A~F로 정량 평가.
Reins 6 scaffold → audit → evolve → doctor. 점진적 하네스 도입 CLI.

각 도구의 상세 분석과 비교는 2편에서 다룬다.

참고 자료

  • 카테고리 AI/개발
  • 읽는시간 7분

Harness Engineering 도구 비교 분석

하네스 엔지니어링 도구들은 개발 프로세스의 어디를 다루고, 얼마나 체계적인가.

이 글은 1편에서 소개한 하네스 엔지니어링의 도구들을 심층 분석한다. GitHub에서 관련 저장소를 검색해 수집하고 검토한 뒤, 대중화된 도구 5개와 주시할 도구 3개를 선별했다.

"하네스 엔지니어링 전용 도구"는 아직 초기 단계(대부분 2026년 1분기에 등장, Stars 100 미만)다. 반면, 하네스의 핵심 역할(스펙 관리, 제약 주입, 피드백 루프)을 실질적으로 수행하는 도구들은 이미 대규모 커뮤니티를 형성하고 있다. 이 글에서는 두 종류를 모두 다룬다.

전체 수집 목록은 별도 문서에 정리했다.

도구 상세 분석

1. Spec Kit (GitHub)

항목 내용
저장소 github/spec-kit
Stars 83,000+
핵심 개념 스펙 주도 개발(SDD) CLI 툴킷
지원 에이전트 Copilot, Claude Code, Gemini CLI, Cursor, Windsurf 등 20개+

작동 방식

GitHub가 만든 스펙 주도 개발 도구다. Phase gate 방식으로 개발 과정을 단계별로 나눈다.

  1. /speckit.constitution — 프로젝트 거버닝 원칙을 생성한다. 에이전트의 행동 범위를 제약하는 최상위 규칙이다.
  2. /speckit.specify — what/why 중심으로 스펙을 작성한다. how는 에이전트에 위임한다.
  3. /speckit.plan — 기술 스택과 아키텍처를 선택하고 구현 계획을 생성한다.
  4. /speckit.build — 태스크를 분해하고 에이전트가 순차 구현한다.

constitution이 모든 후속 단계의 제약으로 작동한다는 점에서, 하네스의 "제약 주입" 역할을 수행한다.

하네스 관점 강점 - 명확한 phase 분리로 에이전트의 scope creep(범위 확대)을 방지 - 에코시스템 최대: 커뮤니티 확장, 프리셋 풍부 - 20개 이상의 에이전트 지원으로 도구 독립성 높음

하네스 관점 한계 - 검증과 피드백 루프는 에이전트 내부 판단에 의존한다. 기계적 강제가 없다. - phase gate가 슬래시 커맨드 기반이라 CI/CD 자동화 통합이 약하다. - brownfield 프로젝트 적용 가이드가 부족하다.

2. BMAD-METHOD

항목 내용
저장소 bmad-code-org/BMAD-METHOD
Stars 42,600+
핵심 개념 AI 에이전트 기반 애자일 개발 프레임워크
지원 에이전트 Claude Code, Cursor, 기타 IDE

작동 방식

12개 이상의 전문 에이전트 페르소나(PM, Architect, Developer, UX, Scrum Master 등)를 정의하고, 각 페르소나가 역할에 맞는 작업을 수행한다. "Party Mode"로 다중 페르소나를 한 세션에서 협업시킬 수 있다.

Scale-Domain-Adaptive 설계로 프로젝트 복잡도에 따라 계획 깊이를 자동 조정한다. 워크플로우가 34개 이상으로 가장 포괄적이다.

하네스 관점 강점 - 관심사 분리(SoC)를 에이전트 레벨에서 실현. 구현자와 검증자가 분리되어 있다. - 테스트 아키텍트 모듈(TEA)이 독립적인 검증 계층을 제공한다. - Edge Case Hunter가 코드 리뷰 시 경계 조건을 탐지한다.

하네스 관점 한계 - 복잡도가 높다. 소규모 프로젝트에는 과잉이다. - 기계적 검증보다 에이전트 간 대화 기반 검증에 의존한다. - 페르소나 전환에 컨텍스트 비용이 발생한다.

3. OpenSpec (Fission-AI)

항목 내용
저장소 Fission-AI/OpenSpec
Stars 35,000+
핵심 개념 경량 스펙 프레임워크. "유연하되 엄격하지 않게"
지원 에이전트 20개+ AI 코딩 어시스턴트

작동 방식

변경(change) 단위로 독립된 작업 폴더를 생성하고, 각 폴더에 proposal, specs, design, tasks를 구조화한다.

  1. /opsx:propose — 변경 제안. 독립 폴더 생성.
  2. /opsx:apply — 태스크를 순차 구현.
  3. /opsx:verify — 구현 결과를 스펙 대비 검증.
  4. /opsx:archive — 완료 후 아카이브, 스펙 갱신.

"fluid not rigid" 철학으로, 엄격한 phase gate 없이 자유 반복을 허용한다.

하네스 관점 강점 - change 단위 격리가 에이전트의 컨텍스트 오염을 효과적으로 방지한다. - brownfield 프로젝트에 강하다. 기존 코드베이스를 분석해서 스펙을 생성할 수 있다. - verify 단계가 스펙 대비 검증을 명시적으로 수행한다.

하네스 관점 한계 - 검증이 에이전트의 자기 판단(semantic level)에 의존한다. - 기계적 강제 메커니즘이 없다. - 다중 에이전트 협업 시나리오를 지원하지 않는다.

4. Hive (Aden)

항목 내용
저장소 aden-hive/hive
Stars 9,900+
핵심 개념 목표 주도 에이전트 개발 프레임워크 + 런타임 하네스
투자 Y Combinator

작동 방식

자연어로 목표를 말하면, Queen Agent가 에이전트 그래프와 연결 코드를 자동 생성한다. 실행 결과를 기반으로 자기 개선(self-improving)하는 루프가 내장되어 있다.

MCP 102개 도구를 통합하고, Human-in-the-Loop으로 필요 시 인간이 개입할 수 있다.

하네스 관점 강점 - "목표를 말하면 에이전트 시스템을 만들어주는" 메타 하네스 - 자기 개선 루프로 피드백을 자동 처리 - 프로덕션 런타임으로 사용 가능

하네스 관점 한계 - 스펙 주도 개발보다 목표 주도(outcome-driven)에 가깝다. 스펙 정합성 검증이 약하다. - 프레임워크 종속도가 높다. Hive 밖에서 사용하기 어렵다. - 복잡도가 높다.

5. Kiro (AWS)

항목 내용
저장소 kirodotdev/Kiro
Stars 3,300+
핵심 개념 스펙 주도 에이전틱 IDE (VSCode 기반)
제공사 AWS/Amazon

작동 방식

IDE 안에서 스펙 → 코드 → 검증의 전체 루프가 완결된다.

  • Specs: 프롬프트를 구조화된 스펙(요구사항 → 설계 → 태스크)으로 자동 변환.
  • Steering: .kiro/steering/ 마크다운 파일로 에이전트 행동 규칙을 주입.
  • Agent Hooks: 파일 변경, 이벤트에 반응하는 자동 트리거. 코드 변경 시 자동 테스트 실행, 문서 변경 시 자동 sync 등.

하네스 관점 강점 - Hooks가 현존하는 도구 중 가장 강력한 자동 피드백 루프 메커니즘이다. - Steering이 에이전트 행동의 기계적 제약으로 작동한다. - IDE 통합으로 개발자 경험이 매끄럽다.

하네스 관점 한계 - IDE 종속. Kiro 밖에서는 사용할 수 없다. - 독립 CLI나 CI 통합이 제한적이다. - 모델 선택이 제한적이다.

6. Entrix (주시)

항목 내용
저장소 phodal/entrix
Stars 31
언어 Python
핵심 개념 품질 규칙과 아키텍처 제약을 실행 가능한 가드레일로 변환

작동 방식

규칙을 코드화하고, 변경사항에 대해 자동으로 실행한다. 세 단계의 검증 티어(fast/normal/deep)를 제공하며, 변경 인식(change-aware) 검증으로 diff에 대해서만 가중 점수를 매기고 하드 게이트를 적용한다.

review-trigger로 위험한 변경을 더 깊은 검증 단계로 자동 라우팅한다. 그래프 기반 영향도 분석, 테스트 반경 추정, 리뷰 컨텍스트 분석을 선택적으로 추가할 수 있다.

주시하는 이유

대형 도구들이 "에이전트에게 잘 전달하는 것"에 집중할 때, Entrix는 "규칙을 실행 가능한 가드레일로 변환하는 것"에 집중한다. 기계적 강제를 가장 직접적으로 구현하는 도구다.

7. AI Harness Scorecard (주시)

항목 내용
저장소 markmishaev76/ai-harness-scorecard
Stars 14
언어 Python
핵심 개념 리포지토리의 에이전트 코드 신뢰도를 정량 평가

작동 방식

ai-harness-scorecard assess . 하나로 현재 리포의 하네스 수준을 A~F 등급으로 평가한다. 5개 카테고리, 31개 체크를 수행한다.

  1. 아키텍처 문서화 (20%)
  2. 기계적 제약 (25%)
  3. 테스트와 안정성 (25%)
  4. 리뷰와 드리프트 (15%)
  5. AI 특화 세이프가드 (15%)

DORA 2025 보고서, OpenAI Harness Engineering, SlopCodeBench, Kent Beck의 테스트 원칙을 근거로 한다.

주시하는 이유

기존 도구들이 "하네스를 만드는 것"에 집중할 때, 유일하게 "하네스를 측정하는 것"에 집중한다.

8. Reins (주시)

항목 내용
저장소 WellDunDun/reins
Stars 6
언어 TypeScript
핵심 개념 OpenAI 방법론의 CLI 도구화

작동 방식

4단계 CLI로 리포의 하네스 성숙도를 점진적으로 높인다.

  1. reins scaffold — 하네스 구조 초기 생성
  2. reins audit — 현재 리포의 하네스 수준 진단
  3. reins evolve — 진단 결과를 기반으로 개선
  4. reins doctor — 하네스 건강 상태 확인

주시하는 이유

의존성 0개. 하네스 엔지니어링을 "도입하는 과정"을 단계적으로 안내한다.

비교 분석

비교를 위한 두 가지 참조 프레임

하네스 엔지니어링 도구를 평가할 확립된 기준은 아직 없다. 다만, 하네스 엔지니어링은 완전히 새로운 분야가 아니다. 소프트웨어 엔지니어링에서 프로세스 관리와 품질 보증을 다루던 영역이 AI 에이전트 환경에 맞게 형태가 바뀐 것에 가깝다. 그렇다면 기존 소프트웨어 공학 표준을 참조 프레임으로 활용하는 것은 자연스러운 접근이라고 생각한다.

이 글에서는 두 가지 표준을 참고한다. 하네스 엔지니어링을 위해 만들어진 표준이 아니므로 직접 적용은 아니다.

ISO/IEC 12207 — 소프트웨어 생명주기 프로세스

소프트웨어 개발과 유지보수에 필요한 전체 프로세스를 정의한 국제 표준이다. 요구사항 정의, 설계, 구현, 검증(Verification), 확인(Validation), 유지보수, 품질 보증 등 30개 프로세스를 체계화한다. 하네스 도구가 이 프로세스 중 어디를 지원하는지를 매핑하면, 각 도구가 개발 과정의 어느 영역을 커버하는지 파악할 수 있다.

CMMI — 프로세스 성숙도 모델

Carnegie Mellon 대학에서 개발한 프로세스 수준 개선 프레임워크다. 프로세스의 성숙도를 5단계로 평가한다.

  1. Initial: 프로세스가 정의되지 않은 상태. 결과가 개인의 역량에 의존한다.
  2. Managed: 기본적인 프로젝트 관리가 존재한다. 요구사항이 관리되고 프로세스가 계획된다.
  3. Defined: 프로세스가 조직 차원에서 정의되고 문서화된다. 프로젝트 간 일관성이 있다.
  4. Quantitatively Managed: 프로세스가 정량적으로 측정되고 관리된다.
  5. Optimizing: 측정 결과를 기반으로 프로세스가 지속적으로 개선된다.

ISO 12207 프로세스 커버리지

도구 요구사항 정의 설계 구현 검증(V&V) 품질 보증 측정/분석 구성 관리
Spec Kit (83K) O O O
BMAD (43K) O O O △
OpenSpec (35K) O O O △
Hive (10K) O
Kiro (3K) O O O △ △
Entrix (31) O O
Scorecard (14) △ O
Reins (6) △ △ O

O = 해당 프로세스를 명시적으로 지원 / △ = 부분 지원 또는 에이전트 판단에 의존

대부분의 도구가 요구사항 정의, 설계, 구현에 집중하고 있다. 반면 검증, 품질 보증, 측정은 상대적으로 비어 있다. 특히 구성 관리(변경 이력 추적, 베이스라인 관리)를 체계적으로 다루는 도구는 거의 없다.

CMMI 성숙도 관점

정식 CMMI 평가가 아니다. 각 도구를 사용했을 때 에이전트의 개발 프로세스가 도달할 수 있는 성숙도 수준을 기능 기반으로 가늠한 것이며, 도구를 도입한다고 해당 레벨이 보장되는 것은 아니다.

도구 성숙도 수준 근거
Spec Kit (83K) Level 2 (Managed) 요구사항이 관리되고 프로세스가 계획되지만, 검증과 품질 보증이 에이전트 자기 판단에 의존
BMAD (43K) Level 2~3 프로세스가 페르소나 단위로 정의되고 역할이 분리되지만, 기계적 강제가 약함
OpenSpec (35K) Level 2 (Managed) change 단위 관리가 체계적이지만, 검증이 기계적이지 않음
Hive (10K) Level 2 (Managed) 런타임 관리가 있고 자기 개선 루프가 있지만, 프로세스 정의가 느슨함
Kiro (3K) Level 3 (Defined) Steering으로 프로세스가 조직 차원에서 정의되고, Hooks로 일부 자동 강제
Entrix (31) Level 3~4 규칙이 코드로 정의되고 기계적으로 강제되며, tier별 측정이 존재
Scorecard (14) Level 4 (Quantitatively Managed) 정량적 측정과 등급화가 핵심 기능
Reins (6) Level 2~3 프로세스 정의(scaffold)와 진단(audit)을 지원하지만, 정량 측정은 제한적

Level 5(Optimizing) — 측정 결과를 기반으로 프로세스가 지속 개선되는 단계 — 에 도달한 도구는 없다. 측정(Scorecard)과 개선(Reins의 evolve)을 각각 다루는 도구는 있지만, 이 둘이 자동으로 연결되어 지속적 개선 루프를 형성하는 도구는 아직 존재하지 않는다.

현재 한계

하네스 엔지니어링은 아직 초기 단계다.

  • 도구 간 파편화: 도구마다 다루는 영역이 다르고, 통합 표준이 없다.
  • 검증의 한계: 대부분의 검증이 정적 분석에 머물러 있다. 스펙과 구현의 의미적 정합성을 기계적으로 검증하는 도구는 아직 없다.
  • 규칙 형식 파편화: CLAUDE.md, .cursor/rules, AGENTS.md, .kiro/steering 등 에이전트마다 형식이 다르다.
  • 현실적 복잡도 미반영: 대부분의 도구가 단일 저장소, 단일 프로젝트를 전제한다. FE/BE 분리, 마이크로서비스, 스펙 비대화, 테스트 전략 정의, 모노레포/멀티레포 같은 현실적 문제를 다루는 도구는 아직 없다.

마무리

다만, 이 한계들이 영구적인 문제인지는 생각해볼 여지가 있다.

FE/BE나 BE 내 서비스를 분리하는 이유는 담당자가 다르고 배포/개발 사이클이 다르기 때문이다. 에이전트 중심 환경에서는 이런 구분이 의미를 잃고, 하나의 프로젝트에서 통합 관리하는 것이 자연스러워질 수 있다. 코드가 매번 다르게 생성되는 문제도, 정적 분석 기준을 통과하고 full coverage 테스트를 통과하는 코드라면 일관성보다 정확성이 더 중요한 기준이 될 수 있다.

더 근본적으로, 하네스 엔지니어링이 성숙해질수록 "무엇을 관리해야 하는가"의 대상 자체가 달라질 수 있다. 스펙과 설계가 관리 대상이고 코드는 빌드 단계의 산출물이라면, git에서 추적해야 할 것은 코드가 아니라 스펙이 된다. 컴파일된 바이너리를 버전 관리하지 않듯이, 에이전트가 스펙으로부터 생성한 코드도 같은 위상이 될 수 있다.

이 패러다임에서는 코드 일관성, 프로젝트 분리, 스펙 비대화 같은 현재의 문제는 질문 자체가 달라진다. 현재의 한계에 매몰되기보다, 이런 방향성의 변화에 관심을 두는 것이 더 유의미하다.

하네스 엔지니어링은 "에이전트가 더 똑똑해지면 필요 없어지는 것"이 아니라고 생각한다. 에이전트의 능력이 커질수록, 그 능력을 올바른 방향으로 쓰게 하는 환경 설계의 중요성도 함께 커질 것이다.

참고 자료