149. 소프트웨어 요구사항 명세서 (SRS, Software Requirements Specification)

핵심 인사이트 (3줄 요약)

본질: SRS(Software Requirements Specification)는 요구공학 프로세스의 최종 산출물로, 시스템이 '무엇(What)'을 해야 하는지를 기능적/비기능적 요구사항, 다이어그램, 제약 조건으로 꼼꼼히 박제해 둔 소프트웨어 개발의 헌법이자 기준 도면이다.

가치: 고객(현업)에게는 "내가 원하는 시스템이 맞다"는 승인(Sign-off)을 받는 계약서 역할을 하며, 개발자에게는 코딩의 명세서로, 테스터(QA)에게는 결함(Bug) 여부를 판단하는 채점 기준으로 작용하여 프로젝트의 파국을 막아낸다.

융합: 작성 시 IEEE 830 글로벌 표준 목차를 따르되, 자연어의 모호함을 통제하기 위해 UML(유스케이스)이나 의사결정표 같은 반정형 명세 기법과 **요구사항 추적성 매트릭스(RTM)**를 융합하여 변경 관리에 완벽히 대비하는 것이 핵심 아키텍처 역량이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 소프트웨어 요구사항 명세서(SRS)는 시스템 개발의 방향타다. 개발될 소프트웨어가 정확히 어떤 동작을 해야 하고, 어떤 제약(속도, 보안, 용량) 위에서 굴러가야 하는지를 고객과 개발팀 모두가 이해할 수 있는 언어(글, 그림, 표)로 정리한 가장 중요한 공식 문서다.
필요성: 프로젝트 초기에 고객과 기획자가 카페에서 만나 "멋진 쇼핑몰 만들어 주세요"라고 악수를 나눴다 치자. 6개월 뒤 개발자가 시스템을 가져갔더니 고객이 노발대발한다. "아니, 장바구니에 100개를 담을 수 있어야지 왜 10개밖에 안 들어가요?" 개발자는 항변한다. "처음에 그런 말씀 안 하셨잖아요!" 이런 끝없는 진흙탕 싸움(Scope Creep)과 잦은 재작업(Rework)은 IT 프로젝트 10개 중 7개를 파산으로 몰고 갔다. "우리가 짓기로 한 집이 정확히 벽돌 300장짜리 단층집이라는 것을 도장 찍고 시작하자"는 깐깐한 합의문이 인류 소프트웨어 공학의 생존 필수로 떠올랐다.
💡 비유: 집을 짓기 전에 건축가와 집주인이 도장을 찍는 **'최종 건축 청사진(도면)'**과 같습니다. 이 도면에는 문이 몇 개인지, 벽지 색깔은 무엇인지, 지진 진도 몇까지 버텨야 하는지가 정확히 적혀 있습니다. 집주인은 도면을 보고 오케이를 하고, 인부들은 도면만 보고 벽돌을 쌓습니다. 나중에 집주인이 "왜 창문이 작냐"라고 따지면, 건축가는 이 도면을 꺼내 보여주며 "여기 동의하셨잖아요"라고 방어할 수 있는 유일한 증거물입니다.
등장 배경:
1. 폭포수 모델(Waterfall)의 정립: 요구 분석이 끝나야만 설계를 시작할 수 있는 1980년대 엄격한 폭포수 생태계에서, 단계를 넘어가기 위한 완벽한 통행증(Baseline)이 필요했다.
2. IEEE 830 표준의 제정: "문서를 쓰긴 써야겠는데, 목차를 어떻게 잡아야 할지 모르겠다"는 전 세계의 아우성을 잠재우기 위해, 1998년 IEEE가 좋은 SRS 문서의 조건과 목차 템플릿을 국제 표준으로 반포했다.

┌─────────────────────────────────────────────────────────────┐
│          SRS가 프로젝트 전 생명주기(SDLC)에 미치는 파급력              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│                 [ 📜 소프트웨어 요구사항 명세서 (SRS) ]              │
│                         │                                   │
│    ┌────────────────────┼────────────────────┐              │
│    ▼                    ▼                    ▼              │
│ [ 고객 / 현업 ]       [ 설계자 / 개발자 ]        [ QA 테스터 ]     │
│                                                             │
│ "이 문서대로 만들어       "이 문서의 명세대로       "이 문서에 적힌 대로  │
│  주시면 돈 드릴게요."     DB 스키마를 짜고         작동 안 하면 전부 다  │
│ (계약 및 인수 기준)       코딩(구현)하겠습니다."     버그(Defect)입니다."│
│                                                             │
│ 💥 만약 SRS가 엉터리라면?                                        │
│ ➔ 고객은 "내가 원한 게 아냐!" 라며 시스템 인수를 거부함.                 │
│ ➔ 개발자는 상상력을 동원해 엉뚱한 코드를 짬. (Rework 지옥 발생)          │
│ ➔ 테스터는 이게 버그인지 원래 그런 기능인지 채점할 기준이 없어 싸움만 남.    │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] SRS 문서는 기획자 혼자 쓰고 서랍에 처박아 두는 문서가 아니다. 소프트웨어 공학의 심장(Hub)이다. 고객(비즈니스), 개발자(구현), 테스터(품질)라는 서로 다른 우주에 사는 외계인 3명이 유일하게 머리를 맞대고 해석을 일치시켜야 하는 '단일 진실의 원천(SSOT, Single Source of Truth)'이다. SRS의 퀄리티가 프로젝트 전체 예산과 성패를 90% 이상 좌우한다. 요구사항 단계에서 발생한 1개의 오류를 코딩 다 끝난 뒤에 고치려면 100배의 비용이 든다는 '보엠(Boehm)의 곡선'이 이 문서의 파괴력을 증명한다.

📢 섹션 요약 비유: SRS는 국가의 **'헌법(Constitution)'**입니다. 헌법이 모호하게 적혀있으면 국민(고객)과 경찰(개발자), 판사(테스터)가 매번 서로 해석이 다르다며 멱살을 잡고 싸우지만, 헌법이 명확하면 누구도 딴소리를 하지 못하고 일사불란하게 나라(프로젝트)가 굴러가게 됩니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

잘 쓴 SRS의 6대 품질 조건 (IEEE 830 기준)

어떤 명세서가 훌륭한지 채점하는 기술사 시험의 0순위 핵심 잣대다. (암기 팁: 정/명/완/일/검/추)

특성	영문 (Keyword)	설명 및 검증 방법	안티패턴 (나쁜 예시)
정확성	Correct	고객이 실제로 요구한 기능과 100% 일치해야 함. 고객의 리뷰와 서명(Sign-off)을 통해 확보.	고객은 '할인'을 원했는데 '적립'으로 적어둠
명확성	Unambiguous	1개의 문장은 무조건 1가지 뜻으로만 해석되어야 함. 자연어의 한계를 표나 그림으로 보완.	"응답이 가급적 빨리 와야 한다" (1초? 10분?)
완전성	Complete	TBD(To Be Determined) 같은 빈칸이 없어야 하며, 예외 상황(에러 시) 대처법이 다 적혀 있어야 함.	결제 성공 로직만 있고, 잔고 부족 시 로직이 없음
일관성	Consistent	문서의 10페이지에 적힌 내용과 50페이지에 적힌 내용이 서로 충돌하거나 모순되지 않아야 함.	10쪽: 비밀번호 8자리, 50쪽: 비밀번호 10자리
검증 가능성	Verifiable	문서에 적힌 내용을 QA 테스터가 O/X로 채점할 수 있게 측정 가능한 수치로 적혀 있어야 함.	"디자인이 사용자 친화적일 것" (채점 불가)
추적 가능성	Traceable	각 요구사항마다 고유 식별자(`REQ-001`)를 달아 원천(어느 회의에서 나옴)과 산출물(어느 소스코드로 됨)을 추적할 수 있어야 함.	번호 없이 줄글로만 빽빽하게 씀

IEEE 830 문서 목차 구조 (표준 프레임워크)

글로벌 표준 SRS 문서는 아무렇게나 쓰는 것이 아니라, 3개의 큰 뼈대로 나뉜다.

도입 (Introduction): 시스템의 목적, 범위, 그리고 문서에 쓰인 '용어 사전(Glossary)'을 정의한다.
전체 기술 (Overall Description): 시스템 환경, 제약 조건(오라클 DB만 쓸 것 등), 사용자 특성(노인 대상 등) 같은 배경지식을 적는다.
구체적 요구사항 (Specific Requirements): 문서의 진짜 알맹이다. (이 부분이 전체의 90% 분량).
- 기능적 요구사항: 시스템이 뿜어내야 할 입력, 처리, 출력 로직 (예: 결제 기능).
- 비기능적 요구사항: 시스템의 성능, 보안, 가용성, 호환성 (예: 1만 명 동시 접속 시 3초 이내 응답).
- 외부 인터페이스: 하드웨어, 소프트웨어, 통신(API 연동) 규격.

📢 섹션 요약 비유: 좋은 SRS는 '프라모델 조립 설명서'입니다. 1페이지엔 완성된 로봇 사진(목적)이 있고, 2페이지엔 가위와 본드 준비물(제약 조건)이 적혀있고, 3페이지부터는 부품 A와 B를 끼우라는 100% 명확한 조립 순서(구체적 요구사항)가 수학처럼 적혀있어 누가 조립해도 똑같은 로봇이 나옵니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: 기능적 요구사항 vs 비기능적 요구사항의 충돌

명세서 안에서 가장 첨예하게 부딪히고, 프로젝트 막판에 폭탄이 되는 딜레마다.

항목	기능적 요구사항 (Functional Req.)	비기능적 요구사항 (Non-Functional Req.)
정의	시스템이 무엇(What)을 하는가?	시스템이 그 기능을 어떻게(How well) 수행하는가?
도출 주체	현업 부서, 비즈니스 기획자	시스템 아키텍트, 보안팀, 인프라팀
주요 예시	장바구니 담기, 이메일 발송, 결제 취소	성능(응답 1초), 가용성(99.9%), 보안(AES 암호화)
명세 실패 시	고객이 "이 기능 없네?" 하고 바로 알아챔	평소엔 모르다가, 블랙프라이데이 때 서버가 터지고 뉴스에 남

딜레마의 융합: 고객은 "장바구니 띄우기(기능)"와 "화면이 0.1초 만에 뜨기(비기능)"를 동시에 요구한다. 하지만 비기능(성능)을 달성하려면 백엔드 개발자는 DB 조회 대신 거대한 Redis 캐시 인프라를 깔아야 하고 예산이 3배로 뛴다. 아키텍트는 명세서 작성 단계에서 이 둘 사이의 트레이드오프(Trade-off) 비용을 정확히 산정하고, 고객에게 "0.1초 만에 뜨게 하려면 예산을 1억 더 태워야 하는데, 1초로 타협하시겠습니까?"라고 협상(Negotiation)하여 문서에 남기는 기술이 필요하다.

과목 융합 관점

데이터베이스 (DB): SRS의 구체적 요구사항 챕터에 나오는 명사들과 정보의 흐름은 즉각적으로 DB 모델러의 개념적 모델링(ERD) 재료가 된다. 문서에 "회원은 여러 개의 배송지를 가질 수 있다"는 한 줄이 명확히 박혀있어야, 모델러가 회원과 배송지 테이블을 1:N으로 찢어놓는 스키마 설계의 정당성을 확보하게 된다.
테스팅 (QA 품질 관리): 블랙박스 테스트 기법 중 가장 대표적인 것이 **'요구사항 기반 테스팅'**이다. QA 엔지니어는 소스 코드를 보지 않는다. 오직 이 SRS 문서만을 바이블로 펴놓고, 문서에 적힌 기능 하나당 테스트 케이스(TC)를 1개씩 엑셀로 뽑아낸다. 명세서에 TBD(미정)로 빵꾸가 나 있으면, QA 부서는 "테스트 불가"를 선언하며 개발팀에 문서를 다시 튕겨내는 살벌한 검문소 역할을 한다.
📢 섹션 요약 비유: 기능적 요구사항은 "자동차가 앞으로 굴러가게 만들어줘"라는 기본 조건이고, 비기능적 요구사항은 "시속 300km로 달려도 엔진이 안 터지게 만들어줘"라는 극한의 스펙입니다. 앞구르기만 잘하면 되는지, 레이싱을 해야 하는지(비기능)를 문서에 안 적어두면 개발자는 동네 마실용 꼬마 자동차를 만들어 납품하는 참사가 벌어집니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 모호성(Ambiguity)과 검증 불가(Unverifiable) 텍스트의 재앙: 공공기관 포털 재구축 프로젝트 SRS 문서에 기획자가 REQ-UI-005: 검색 결과는 사용자가 기다리지 않도록 신속하게 화면에 표출되어야 한다.라고 적고 양측 도장을 찍었다. 오픈 날, 검색 결과가 4초 만에 떴다. 기관장은 "왜 이리 느리냐, 당장 고쳐라"며 인수를 거부했다. 개발사는 "4초면 대용량 DB 치고 신속한 거다"라며 버텼고 소송전으로 번졌다.
- 판단: 전형적인 IEEE 830 '검증 가능성' 원칙 위배다. 형용사나 부사('신속하게', '친화적으로', '안전하게')는 명세서에서 절대 퇴출해야 할 암 덩어리다. 실무 아키텍트는 이 문장을 REQ-UI-005: 10만 건 데이터 검색 시, 95%의 요청에 대해 화면 렌더링 완료까지 2.0초 이내에 응답해야 한다.라는 계량화되고 테스트 툴(JMeter)로 증명할 수 있는 차가운 수치 문장으로 뜯어고쳤어야 했다.
시나리오 — 요구사항 추적성 매트릭스(RTM) 부재로 인한 폭파: 시스템 오픈 1달 전, 고객이 "법이 바뀌어서 미성년자 결제 차단 로직을 추가해 주세요"라고 변심(Change Request)을 날렸다. 개발팀은 SRS 문서를 뒤져 '결제 모듈'만 수정했다. 그런데 오픈하고 보니, 결제는 막혔는데 포인트 차감 모듈과 장바구니 모듈은 옛날 로직 그대로 돌아서 미성년자들의 포인트가 공중 증발했다.
- 판단: 요구사항이 변경될 때 그 파급 효과(Ripple Effect)를 파악할 수 있는 추적 가능성(Traceability) 뼈대가 없어서 터진 참사다. 요구사항 명세서는 단순히 워드 문서로 끝나는 게 아니라 엑셀의 **요구사항 추적표(RTM)**와 매핑되어야 한다. REQ-01 (결제)라는 문서 코드가 Payment.java (소스코드), DB_PAY_TABLE (DB), TC-101 (테스트케이스)로 어떻게 거미줄처럼 이어져 있는지 표로 만들어두어야, 하나를 고칠 때 어디를 같이 고쳐야 할지 1초 만에 뽑아낼 수 있다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 요구사항 추적성 매트릭스 (RTM)의 거미줄 생태계       │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [ 요구사항 ID ]   [ 설계 산출물 (UML/DB) ]  [ 구현 (소스코드) ]  [ 테스트 케이스 ]│
  │                                                             │
  │ REQ-MEM-001   ➔  Use Case: 회원가입     ➔  UserController.java ➔ TC-001 │
  │ (회원가입 기능)    DB Table: TB_USER                            │
  │                                                             │
  │ REQ-PAY-015   ➔  Class: PaymentMgr    ➔  PayService.java   ➔ TC-024 │
  │ (신용카드 결제)    API: POST /pay                            │
  │                                                             │
  │ 💥 고객의 변심 발생! "신용카드 결제 방식 싹 다 갈아엎어 주세요!"            │
  │                                                             │
  │ 🌟 아키텍트의 대처 (RTM 가동):                                   │
  │ "좋습니다. REQ-PAY-015를 변경합니다. RTM 표를 보니, 우리는 당장      │
  │  PaymentMgr 설계도를 고치고, PayService.java 소스코드를 수정하고, │
  │  TC-024번 테스트 시트를 다시 돌려야 하네요. 영향도가 명확히 뽑혔습니다." │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 거대 엔터프라이즈 프로젝트에서 수백 명의 개발자가 길을 잃지 않는 유일한 비법인 RTM(Requirements Traceability Matrix)이다. 폭포수(Waterfall) 개발의 가장 큰 단점은 요구사항 단계에서 만든 문서가 개발 단계에 가면 버려진다는 것이다. 이를 막기 위해 문서의 문장 하나하나에 ID 꼬리표를 달고, 그 꼬리표를 Git 커밋 메시지와 JUnit 테스트 코드 머리말에 강제로 박아 넣게 만든다. 이 거미줄이 완성되면, 비즈니스 요건 하나가 시스템 어디에 핏줄처럼 뻗어있는지 완벽하게 장악하는 중앙 통제력을 획득하게 된다.

도입 체크리스트

기술적: SRS를 워드(Word) 파일 수백 장으로 흩뿌리지 않고, Jira, Confluence, Redmine 같은 요구사항 관리 전문 도구(ALM Tool)에 티켓 단위로 올려 형상 관리(버전 컨트롤)와 히스토리 추적을 강제하고 있는가?
운영·보안적: 비기능 요구사항 챕터에 개인정보보호법, ISMS 인증 기준, GDPR 등의 법적/규제적(Compliance) 제약 사항이 누락 없이 명시되어, 아키텍트가 DB 설계 시 전화번호 암호화를 빼먹는 불상사를 원천 차단하고 있는가?

안티패턴

구현 방식(How)의 하드코딩 침범: 명세서에 "메인 화면의 추천 상품은 넷플릭스처럼 가로 스와이프가 되는 캐러셀(Carousel) UI 위젯을 쓰고, 백엔드는 Spring Boot 3.0과 Redis 캐시를 써서 JSON으로 던져라"라고 꽉 막힌 디자인과 기술 스택을 박아버리는 짓. SRS는 "고객 맞춤형 상품 5개를 1초 이내에 추천한다(What)"까지만 적어야 한다. 기술 스택과 UI는 아키텍트와 디자이너가 나중에 결정할 몫(How)이다. 요구사항 단계에서 기술을 제약하면 미래의 더 좋은 아키텍처 도입 기회를 스스로 날려버리게 된다.
📢 섹션 요약 비유: 요구사항 명세서는 "서울에서 부산까지 2시간 안에 도착하게 해 줘(What)"라고 적는 문서입니다. 여기에 "KTX를 타라, 고속버스를 타라(How)"라고 적어버리면, 나중에 비행기라는 훨씬 좋은 수단이 생겨도 규정에 묶여 쓸 수 없게 되는 치명적인 족쇄가 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	모호하고 장황한 구두/산문 명세	IEEE 830 기반 정규화 SRS + RTM 구축	개선 효과
정량	구현 이후 설계 결함 발견	설계 단계에서 논리적 모순/누락 사전 식별	전체 프로젝트 결함 수정 비용 최대 80% 사전 절감
정량	기획자 퇴사 시 시스템 스펙 유실	SSOT(단일 진실 원천) 문서의 자산화	차세대 시스템 개편 및 인수인계 시간 수개월 단축
정성	"만들어주기로 했잖아!" 끝없는 갈등	기준선(Baseline) 서명을 통한 범위 통제	무분별한 Scope Creep(요구사항 팽창) 차단 및 성공적 프로젝트 클로징

미래 전망

문서 중심에서 백로그(Backlog)와 코드 중심으로 (Agile의 역습): 1,000페이지짜리 두꺼운 SRS 책자를 6개월간 찍어내는 무거운 행위는 더 이상 환영받지 못한다. 애자일 스크럼(Scrum) 생태계에서는 거대한 SRS를 해체하여 잘게 쪼갠 에픽(Epic)과 유저 스토리(User Story) 묶음으로 대체했다. "문서보다는 작동하는 소프트웨어"라는 철학 아래, 무거운 명세는 최소화하고 즉각적인 피드백 루프를 돌리는 방향으로 진화했다.
실행 가능한 명세 (Executable Specification)의 완성: BDD(Behavior-Driven Development) 도구인 Cucumber 등의 발전으로, 기획자가 작성한 요구사항 텍스트 파일(Gherkin 문법)이 곧바로 서버 빌드 파이프라인에서 JUnit 테스트 코드로 실행되는 융합이 일어났다. 즉, "명세서가 낡아서 실제 코드와 다르다"는 50년 묵은 소프트웨어 공학의 딜레마가 코드가 명세서 자체를 검증하는 방식으로 완벽히 치유되고 있다.

참고 표준

IEEE Std 830-1998: 소프트웨어 요구사항 명세서 작성을 위한 권장 관행 (SRS의 글로벌 바이블)
ISO/IEC 29148: 기존 IEEE 830을 대체/흡수한 최신 시스템 및 소프트웨어 수명주기 프로세스 요구공학 국제 표준

"명확하게 정의되지 않은 문제는 영원히 풀 수 없다." 소프트웨어 공학 역사를 관통하는 가장 뼈아픈 진리다. 수천만 줄의 아름다운 Java 코드와 화려한 마이크로서비스(MSA) 아키텍처도, 결국 첫 단추인 '우리가 무엇을 지어야 하는가'가 흔들리면 웅장하고 견고한 쓰레기를 만드는 삽질에 불과하다. 비록 애자일의 시대가 오며 두꺼운 SRS 책자는 슬림한 백로그 티켓으로 쪼개졌지만, "모호성을 타파하고, 예외를 빠짐없이 메우며, 테스트 가능한 계량적 언어로 쓴다"는 IEEE 830의 위대한 공학적 결벽증과 철학만큼은, 클라우드 네이티브 시대의 아키텍트들에게도 여전히 가슴에 새겨야 할 헌법 제1조다.

📢 섹션 요약 비유: SRS는 험난한 항해를 시작하는 배의 선장, 항해사, 갑판원이 다 같이 모여 찍은 **'최종 목적지 좌표와 항해 수칙 계약서'**입니다. 바다 한가운데서 폭풍(이슈)을 만나 서로 싸우고 헤맬 때, 언제든 주머니에서 꺼내어 "우리가 가려던 진짜 목표는 여기였어"라고 모두의 고개를 끄덕이게 만드는 나침반이자 진정제입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
요구공학 (Requirements Engineering)	요구사항을 1.도출, 2.분석, 3.명세, 4.확인, 5.관리하는 전체 프로세스의 통칭이며, SRS는 3번 명세 단계의 거룩한 최종 산출물이다.
비기능 요구사항 (Non-Functional)	"응답 속도 1초, AES256 암호화" 등 고객은 잘 모르지만 아키텍트가 목숨 걸고 SRS에 박아 넣어야 서버 폭발과 보안 참사를 막을 수 있는 숨은 기둥이다.
요구사항 추적성 매트릭스 (RTM)	SRS에 적힌 1번 요구사항이 DB 테이블, 소스코드, QA 테스트 결과까지 빵꾸 없이 끈끈하게 이어져 있는지 감시하는 엑셀 거미줄이다.
베이스라인 (Baseline)	고객과 개발자가 SRS 문서의 최종본을 검토하고 "이제부터 바꾸려면 돈 내고 결재 올리시오"라고 쾅 도장을 찍어버려 요구사항 팽창을 막는 통제 기준선이다.
User Story (유저 스토리)	거대한 SRS 책자를 쓰기엔 너무 느린 애자일(Agile) 시대에, "나는 [역할]로서 [기능]을 원한다"라는 3줄짜리 문장으로 쪼개어 포스트잇에 적는 현대판 미니 명세서다.

👶 어린이를 위한 3줄 비유 설명

친구들이랑 아지트를 만들기로 했는데, 서로 생각하는 모양이 다르면 나중에 싸움이 나겠죠?
**소프트웨어 요구사항 명세서(SRS)**는 삽을 들기 전에 다 같이 모여서 "창문은 2개, 지붕은 빨간색, 튼튼해서 비가 새면 안 됨"이라고 꼼꼼하게 적어놓은 **'비밀 아지트 건축 계약서'**예요!
이 계약서가 완벽하면 벽돌을 쌓는 사람(개발자)도, 지붕이 잘 덮였나 검사하는 사람(테스터)도 싸우지 않고 완벽한 아지트를 뚝딱 만들어 낼 수 있답니다!