Cursor IDE 에이전트: 리포지토리 규모의 편집 및 개발자 보고서

Cursor는 내장된 인공지능으로 전체 코드베이스를 관리하도록 설계된 AI 네이티브 코드 편집기(VS Code 포크)입니다. 기본적인 자동 완성 도구와 달리, Cursor의 에이전트 모드는 AI가 '운전석에 앉아' 여러 파일에 걸쳐 코드를 한 번에 읽고, 편집하고, 생성할 수 있도록 합니다 (federicocalo.dev) (www.datacamp.com). 이 모드에서 AI는 코드를 검색하고, 임포트를 업데이트하며, 함수 정의가 나타나는 모든 곳에서 변경하고, 빌드 또는 테스트 명령을 실행하고, 루프 안에서 오류를 수정할 수 있습니다. 이는 마치 선임 개발자가 병렬로 작업하는 것과 매우 유사합니다 (federicocalo.dev) (www.datacamp.com). 진정으로 리포지토리 규모로 작동합니다. 예를 들어, 한 가이드에서는 AI에게 “이 Angular 앱에 JWT 인증을 추가해줘”라고 명령하고, AI가 수동 편집 없이 서비스를 생성하고, 컴포넌트를 업데이트하고, 테스트를 실행하고, 오류를 수정하는 과정을 설명합니다 (federicocalo.dev). 이러한 에이전트 기능은 '도구 사용' 아키텍처에 의해 구동됩니다. AI는 read_file, edit_file, search_files, 심지어 run_terminal_command와 같은 함수를 호출하여 프로젝트를 검사하고 수정할 수 있습니다 (federicocalo.dev). 실제로 Cursor의 에이전트는 언어 이해와 직접적인 코드 조작을 결합하여 대규모 리팩토링 및 기능 구축을 자율적으로 수행할 수 있습니다.

Cursor는 여러 가지 상호 작용 모드를 제공합니다. 가장 강력한 것은 Composer(다중 파일 에이전트 모드)로, AI가 한 번의 작업으로 여러 파일에 걸쳐 블록을 읽고, 생성하고, 다시 작성할 수 있게 합니다 (www.slashavi.com). 에이전트 모드에서는 채팅과 유사한 "Composer" 창을 열고 목표를 알려주면, AI가 반복적으로 계획하고, 실행하고, 결과를 확인합니다 (www.datacamp.com) (federicocalo.dev). 예를 들어, 에이전트는 변경과 관련된 모든 파일을 찾고, 일관된 편집을 적용하고, 프로젝트의 테스트 또는 빌드 도구를 실행하며, 오류가 발생하면 다시 돌아옵니다. 각 단계는 체크포인트와 함께 버전 관리되므로 모든 변경 사항을 검토하고 되돌릴 수 있습니다. 팀은 종종 Cursor의 규칙 시스템을 사용하여 AI를 안내합니다. 간단한 마크다운 기반 규칙 파일(.cursor/rules/)은 프로젝트의 관례(코딩 스타일, 아키텍처 패턴 등)를 설명하므로 에이전트가 사용자의 표준에 맞는 코드를 작성합니다. 규칙, 리포지토리의 의미론적 인덱싱, 도구 사용의 조합은 Cursor 에이전트가 리포지토리 전반의 작업을 지능적으로 처리할 수 있도록 합니다 (federicocalo.dev) (www.datacamp.com).

계획 및 실행을 위한 에이전트

임시 편집 외에도 Cursor는 복잡한 작업을 체계화하기 위해 계획 모드와 백그라운드 에이전트를 제공합니다. 계획 모드에서는 고수준 목표를 설명하면 AI가 명확하게 질문하고, 단계별 계획을 개략적으로 설명한 다음, 사용자의 승인이 있어야만 해당 단계를 실행합니다 (www.datacamp.com). 예를 들어, AI는 큰 기능을 하위 작업으로 나누고, 가정에 대해 질문한 다음, 각 단계를 순서대로 실행할 수 있습니다. 이는 하나의 크고 모호한 지시(종종 오류로 이어짐)로 인해 발생하는 함정을 피하고 AI가 사용자의 의도에 부합하도록 돕습니다 (lilys.ai) (docs.cursor.com). Cursor는 또한 클라우드 에이전트와 다중 에이전트 워크플로를 지원합니다. 각 에이전트는 자체 환경(예: 별도의 Git 작업 트리 또는 원격 서버)에서 실행되므로 여러 AI "작업자"가 프로젝트의 다른 부분을 병렬로 처리할 수 있습니다. 한 보고서에 따르면 Cursor는 리팩토링을 위해 최대 8개의 에이전트를 동시에 실행할 수 있습니다. 이러한 에이전트에는 브라우저와 같은 도구도 있습니다. 한 데모에서는 에이전트가 빌드된 앱을 브라우저에서 열고, UI를 클릭하며, 성공을 보여주는 짧은 비디오를 녹화하는 것을 보여줍니다 (www.datacamp.com). 실제로 Cursor는 한 회사에서 병합된 풀 리퀘스트의 30% 이상이 이러한 자동화된 에이전트에서 나왔다고 주장합니다 (www.datacamp.com).

에이전트, 채팅 또는 편집 모드에서 Cursor의 AI는 루프 안에서 작동합니다. 현재 프로젝트 상태를 관찰하고, 필요한 변경 사항을 계획하며, 코드를 작성하거나 명령을 실행하여 행동하고, 결과를 **평가(테스트 또는 빌드 출력 포함)**한 다음, 성공하거나 사람의 입력이 필요할 때까지 반복합니다 (federicocalo.dev) (www.datacamp.com). 이것은 많은 채팅 기반 코딩 도우미와의 주요 차이점입니다. 에이전트는 코드와 도구에 직접 접근할 수 있으므로 npm install 또는 git diff와 같은 명령을 실행하고 즉시 결과를 확인할 수 있습니다. 예를 들어, AI가 오류를 발생시키면 컴파일러/테스트 출력을 읽고 수정하려고 시도하며, 개발자가 오류를 잡도록 남겨두지 않습니다. 계획, 실행 및 검증의 이러한 긴밀한 통합은 Cursor의 에이전트 모드를 리포지토리 전반의 변경 사항에 대해 독특하게 강력하게 만듭니다 (federicocalo.dev) (www.datacamp.com).

개발자 피드백: 코드 품질, 차이점, 테스트

사용자들은 일반적으로 Cursor의 AI가 프로젝트 패턴에 맞는 상황 인지 코드를 작성한다고 보고하지만, 다른 AI 생성 코드와 마찬가지로 여전히 신중한 검토가 필요합니다. 가이드에서는 크거나 모호한 프롬프트가 실수를 유발할 수 있으며, 큰 작업을 작고 테스트 가능한 단계로 나누는 것이 일반적으로 더 좋다고 강조합니다 (lilys.ai) (docs.cursor.com). 실제로 Cursor는 제안된 변경 사항의 차이점(diff)을 제공하고 개발자에게 철저히 검토할 것을 권장합니다. 다중 파일 편집의 경우, 시스템은 집계된 차이점 보기를 보여줍니다. 각 에이전트의 변경 사항을 클릭하여 정확히 무엇이 추가되거나 수정되었는지 확인할 수 있습니다. AI는 각 에이전트 실행 반복에 대해 체크포인트를 생성하므로 잘못된 부분이 있으면 리팩토링의 어떤 부분이라도 되돌릴 수 있습니다 (www.datacamp.com) (www.datacamp.com).

일반적인 사용자 권장 사항은 에이전트별로 변경 사항을 수락한 다음 즉시 테스트를 실행하는 것입니다. 예를 들어, 한 튜토리얼에서는 다음과 같이 조언합니다. “차이점을 신중하게 검토하세요… 한 번에 한 에이전트의 변경 사항을 수락하세요. 다음으로 넘어가기 전에 해당 파일을 테스트하세요” (ginno.net). 이는 Cursor의 편집 기능이 강력하지만 완벽하지는 않다는 인식을 반영합니다. 실제로 한 예시에서는 50개 컴포넌트에서 프롭 이름을 변경할 때 Cursor가 일부 파일(인덱스 파일을 통해 암시적으로 임포트된 파일)을 놓쳐 개발자가 해당 파일을 컨텍스트에 수동으로 추가해야 했습니다 (ginno.net). 이 연구는 Cursor의 패턴 기반 분석이 프롬프트에 명시적으로 포함되지 않는 한 간접 참조를 간혹 놓칠 수 있음을 시사합니다.

장점으로는 많은 사용자가 Cursor가 리팩토링 및 다중 파일 작업을 획기적으로 가속화한다고 생각합니다. 예를 들어, 한 개발자는 이틀 걸리던 리팩토링(150개 이상의 파일)을 다중 파일 편집으로 20분으로 단축했다고 보고했습니다 (ginno.net). 검토 설문 조사(예: G2)에 따르면 Cursor 사용자 대다수가 다중 파일 리팩토링이 이제 이 도구를 사용하는 가장 큰 이유라고 말합니다 (ginno.net). 그러나 그들은 또한 경계를 강조합니다. 에이전트를 실행하기 전에 항상 커밋하고, 각 배치 후 테스트하며, AI가 사용자가 아는 비즈니스 로직을 이해하지 못한다는 것을 기억해야 합니다 (ginno.net). 실제로 팀은 에이전트 편집 후 테스트 스위트를 실행하고 깨진 테스트를 수정합니다. AI를 작업을 가속화하지만 정확성을 보장하기 위해 여전히 사람의 감독이 필요한 도우미로 취급하는 것입니다 (ginno.net).

차이점 세분성과 관련하여 Cursor의 다중 에이전트 시스템은 실제로 매우 세분화된 제어를 제공합니다. 각 에이전트는 자체 작업 공간을 가진 파일 하위 집합에서 작업하며, 어떤 에이전트의 변경 사항이든 독립적으로 보거나 되돌릴 수 있습니다. 최종 차이점은 에이전트 또는 파일별로 구성되므로 코드의 각 부분에서 무엇이 변경되었는지 정확히 확인할 수 있습니다 (www.datacamp.com) (www.datacamp.com). 이는 하나의 거대한 변경 세트를 생성하는 도구와는 대조적입니다. 한 개발자가 관찰했듯이, Cursor의 접근 방식은 사용자가 승인할 때까지 메인 브랜치를 그대로 유지하며, 한 에이전트 작업의 오류가 다른 에이전트의 작업을 지우지 않습니다 (ginno.net) (www.datacamp.com).

전반적으로 코드 품질에 대한 평가는 조심스럽게 낙관적입니다. Cursor는 일반적으로 프로젝트 관례를 따르는(특히 규칙을 사용하는 경우) 논리적으로 일관된 코드를 생성하지만, 여전히 논리적 버그나 미묘한 오류를 유발할 수 있습니다. 이것이 개발자들이 각 배치 후 코드 검토와 테스트를 강조하는 이유입니다. AI 생산성 향상과 필요한 사람의 QA의 조합은 반복되는 주제입니다. 사용자들은 AI가 얼마나 빨리 작업할 수 있는지(예를 들어, Copilot이 한 줄씩 타이핑하는 것을 보는 것에 비해 문서를 "눈 깜짝할 사이에" 편집하는 것 (www.reddit.com))에 감사하지만, 초기 릴리스에서 "많은 버그"를 보고하고 제안된 변경 사항을 승인하거나 거부하는 것의 중요성을 강조합니다 (forum.cursor.com) (ginno.net). 이러한 엇갈린 피드백은 AI의 출력이 일반적으로 유용하지만 완벽하지는 않다는 것을 시사합니다.

알려진 한계 및 모범 사례

Cursor의 에이전트는 강력하지만 한계가 있습니다. 주요 제약 중 하나는 규모입니다. 매우 큰 모노레포(수십만 개의 파일)를 처리하는 것은 어떤 도구라도 압도할 수 있습니다. 널리 인용되는 사용자 가이드는 약 10만 개 이상의 파일로 구성된 코드베이스를 한 번에 리팩토링하려는 시도는 권장하지 않는다고 명시적으로 경고합니다. “의존성 그래프가 너무 복잡해지고” 에이전트들이 “서로 엉키게” 되기 때문입니다 (ginno.net). 이러한 거대한 프로젝트의 경우, 단일 전역 명령보다는 변경 사항의 범위를 더 작은 하위 집합(폴더 또는 청크)으로 지정하는 것이 좋습니다. Cursor 자체 문서에서는 리포지토리의 일부만 인덱싱하고, 관련 없는 폴더를 제외하며, 작업을 더 작은 채팅 또는 계획으로 나누는 기술을 제안합니다 (docs.cursor.com) (ginno.net).

또 다른 한계는 이진 또는 비코드 자산입니다. Cursor의 AI 및 의미론적 검색은 텍스트(소스 코드, 구성 파일, 문서)에서 작동합니다. 변경 사항을 계획할 때 이미지, 비디오 또는 컴파일된 이진 파일을 일반적으로 무시합니다. 실제로 이는 Cursor에게 리포지토리의 모든 PNG 이미지에 워터마크를 추가하도록 요청할 수 없다는 것을 의미합니다. Cursor는 이진 형식을 구문 분석하거나 편집하지 않습니다. 즉, 리포지토리 전체의 모든 변경 사항은 임의의 파일이 아닌 코드/텍스트(함수, 주석, 구성 등)에 관한 것이어야 합니다. 이것이 사용자들이 코드 기호 이름 변경, 코드 패턴 업데이트 또는 파일 생성과 같은 작업에 집중하고 비코드 자산과 관련된 작업에는 집중하지 않는 이유입니다.

복잡한 빌드 시스템과 사용자 정의 환경 또한 어려움을 줄 수 있습니다. Cursor는 터미널에서 "npm test" 또는 "make"와 같은 명령을 실행할 수 있지만, 자신이 보는 출력만 알 수 있습니다. 빌드에 여러 단계, 사용자 정의 스크립트 또는 독점 도구가 필요한 경우, 에이전트의 안내가 필요할 수 있습니다. 예를 들어, 프로젝트가 다단계 Docker 빌드 또는 특이한 툴체인을 사용하는 경우 에이전트가 이를 자동으로 처리하지 못할 수 있습니다. 이런 경우, 에이전트에게 충분한 컨텍스트(예: 프롬프트 또는 규칙에 빌드 단계 나열)를 제공하고 더 작은 단계를 계획해야 합니다. 일반적으로 Cursor는 코드가 디스크의 텍스트 파일에 있고 CLI에서 빌드/테스트할 수 있을 때 가장 잘 작동합니다. 매우 복잡한 빌드 파이프라인은 반복적인 프롬프트 또는 수동 개입이 필요할 수 있습니다.

요약하자면, 이는 Cursor가 명확한 패턴을 따르는 변경 사항(예: 임포트 업데이트, 일반적인 코드 숙어 리팩토링, 상용구 컴포넌트 추가)이 있는 잘 구조화된 코드베이스에서 빛을 발한다는 것을 의미합니다. 숨겨지거나 암시적인 의존성(예: 런타임 동작으로만 연결된 객체 그래프, 동적으로 등록된 컴포넌트)이 포함된 작업이나 비코드 데이터에는 덜 적합합니다. 가장 좋은 방법은 Cursor를 강력한 코파일럿으로 취급하는 것입니다. 버전 관리(커밋 및 브랜치)를 철저히 사용하고, 테스트를 자주 실행하며, 루프에 계속 참여하십시오. 한 가이드에서 말했듯이, “반복 작업에 능숙하지만 여전히 다른 사람의 시선이 필요한 선임 엔지니어처럼 사용하라” (ginno.net).

Cursor, Copilot, ChatGPT 비교

Cursor를 다른 AI 코딩 도우미와 비교할 때, 주요 차이점이 드러납니다. GitHub Copilot(및 해당 에이전트 모드)과 Cursor는 모두 AI 기반이지만, 아키텍처 접근 방식이 다릅니다. Copilot은 기존 편집기에 통합되는 확장 기능인 반면, Cursor는 독립형 AI 네이티브 IDE입니다. Cursor의 긴밀한 통합은 전체 리포지토리를 인덱싱하고 임베딩하여 프로젝트에 대한 “아키텍처 수준의 이해”를 제공합니다 (opsera.ai) (www.datacamp.com). 실제로 DataCamp는 *“Cursor는 전체 코드베이스를 인덱싱합니다… 따라서 기본적으로 모든 파일을 통해 추론할 수 있습니다”*라고 언급합니다 (www.datacamp.com). 반면에 Copilot은 전통적으로 열려 있는 파일만 보며, 더 넓은 컨텍스트를 위해 GitHub 검색에 의존합니다. (Copilot은 최근 GitHub 코드 검색을 통해 더 많은 리포지토리 인덱싱을 추가했지만, 관찰자들은 전체 IDE 제어 덕분에 Cursor가 대규모 프로젝트에서 여전히 우위를 점하고 있다고 말합니다 (www.datacamp.com).)

실제로 이는 Cursor가 다중 파일 및 교차 서비스 리팩토링을 더 직접적으로 처리할 수 있음을 의미합니다. Cursor의 에이전트 모드에서는 단일 명령으로 수십 개의 파일을 한 번에 편집하고 임포트 또는 테스트를 일관되게 업데이트할 수 있습니다 (www.datacamp.com). Copilot도 이제 “에이전트 모드”에서 다중 파일 변경을 지원하지만, 더 수동적인 경향이 있습니다. 일반적으로 변경할 파일을 선택하고 하나씩 단계를 거쳐야 합니다 (www.datacamp.com). Copilot은 또한 GitHub에서 호스팅되는 별도의 “코딩 에이전트”를 제공하여 변경 사항이 포함된 풀 리퀘스트를 비동기적으로 실행합니다(GitHub에서 이슈를 위임하고 나중에 PR을 검토하기 위해 돌아옵니다). Cursor의 해당 기능은 백그라운드 에이전트 또는 훅을 사용하여 PR을 생성하는 것이지만, 핵심은 Cursor의 워크플로가 미세한 체크포인트를 통해 실시간으로 에디터 내에서 이루어진다는 점입니다 (www.datacamp.com).

코드 완성 및 즉각적인 제안의 경우, Copilot의 깊은 통합은 지원되는 모든 IDE(VS Code, JetBrains 등)에서 빠른 인라인 “고스트 텍스트” 제안과 함께 작동한다는 것을 의미합니다. Cursor도 인라인 완성 기능(자체 Tab 모델 사용)을 제공하지만, 진정한 강점은 한 줄 자동 완성 이상입니다. 두 도구 모두 이제 고급 “에이전트” 모드를 지원합니다. Cursor의 디자인은 더 큰 계획된 작업을 장려합니다. 내장된 계획 모드가 있으며, 기본 상호 작용은 에이전트가 실행하는 동안 개발자가 루프에 참여하는 것입니다 (www.datacamp.com). Copilot의 디자인은 가끔 위임을 통해 지속적인 코딩을 강조합니다. 하루 종일 자동 완성 및 채팅 도움말을 받고, 큰 기능의 경우 일반적으로 에이전트(또는 Copilot Chat)를 시작한 다음 나중에 돌아옵니다.

코드 품질 및 신뢰성 측면에서 두 도구 모두 개선되고 있지만 완벽하지는 않습니다. 한 비교에서 Cursor는 체크포인트를 통해 신뢰할 수 있는 상황 인지 변경 사항을 생성하는 것으로 알려졌지만, 커뮤니티 보고서에서는 가끔 체크포인트 실패와 원치 않는 롤백이 발생했다고 합니다 (www.augmentcode.com). Copilot의 변경 사항은 Git 브랜칭 및 PR 워크플로에 의존하며, 일부 팀은 이를 더 익숙하게 생각합니다. Cursor는 자동 롤백 및 다중 에이전트 차이점과 같은 기능을 자랑하지만, 사용자들은 프로덕션 환경에서 이러한 기능을 철저히 테스트해야 합니다. 반대로, Copilot의 에이전트 모드도 변경 사항을 생성하지만, 개발자들은 안전을 위해 기존 코드 검토 프로세스에 의존하는 경우가 많습니다.

마지막으로 ChatGPT와 같은 전통적인 채팅 도우미와 비교하면 차이가 확연합니다. ChatGPT(또는 채팅 인터페이스의 Claude Code)는 일반적인 챗봇입니다. 사용자가 붙여넣거나 설명하는 것만 알며, 파일에 직접 쓰거나 테스트를 실행할 수 없습니다 (www.lowcode.agency) (www.lowcode.agency). 반면에 Cursor는 코딩을 위해 만들어졌습니다. “전체 코드베이스 인지” 기능이 있으며, 복사 및 붙여넣기 없이 파일을 직접 조작할 수 있습니다 (www.lowcode.agency) (www.lowcode.agency). LowCode 가이드는 간단히 말합니다. 코딩을 위해 ChatGPT를 사용하는 것은 일반적으로 코드를 채팅 안팎으로 수동으로 복사하는 것을 의미하는 반면, Cursor는 IDE 내에서 워크플로를 유지합니다 (www.lowcode.agency) (www.lowcode.agency). 이는 Cursor를 반복적인 개발에 훨씬 더 효율적으로 만듭니다. 요약하자면:

• Cursor 대 ChatGPT: Cursor는 코드베이스를 제자리에서 편집하고, 프로젝트 아키텍처를 이해하며, 다중 파일 편집을 수행할 수 있는 AI 기반 IDE입니다 (www.lowcode.agency) (www.lowcode.agency). ChatGPT는 대화하는 일반적인 도우미이며, 파일에 대한 내장된 지식이 전혀 없습니다(코드를 직접 붙여넣어야 함) (www.lowcode.agency) (www.lowcode.agency). 리포지토리 전체 리팩토링의 경우, Cursor가 프로젝트에 네이티브하게 통합되므로 더 우수합니다.
• Cursor 대 GitHub Copilot: Copilot은 많은 편집기에 내장된 널리 사용되는 AI 도우미로, 인라인 제안 및 다양한 도구에서 빠른 코딩 도움말에 뛰어납니다. Cursor는 심층적인 다중 파일 코딩 작업을 위한 더욱 올인원 경험을 제공합니다. Cursor의 에이전트 모드(Composer)는 체크포인트를 통해 여러 파일을 한 번에 업데이트할 수 있는 반면 (www.datacamp.com), Copilot의 에이전트 모드는 파일을 한 번에 하나씩 또는 풀 리퀘스트를 통해 변경합니다. Copilot은 광범위한 IDE 지원 및 공식 엔터프라이즈 기능의 이점을 누리지만, Cursor는 병렬 에이전트와 풍부한 컨텍스트를 통해 복잡한 리팩토링을 위한 순수한 강력함을 강조합니다 (www.datacamp.com) (www.datacamp.com). 실제로 팀은 일반적인 코딩 지원 및 호환성을 위해 Copilot을 선택하는 반면, 심층적인 아키텍처 코드 이해 및 대규모 편집이 필요할 때 Cursor를 선택합니다.

결론

Cursor의 에이전트 기능은 코딩에 새로운 수준의 자동화를 가져옵니다. AI를 파일 시스템 접근, 다단계 추론 및 계획 기능을 갖춘 자율 보조원으로 취급함으로써, Cursor는 개발자가 수동 작업보다 훨씬 빠르게 리포지토리 전체 편집, 마이그레이션 및 테스트를 수행할 수 있도록 합니다. 사용자들은 엄청난 시간 절약(한 명은 리팩토링 작업에서 90% 감소를 언급함 (ginno.net))을 보고하지만, 이러한 이득은 AI 출력을 신중하게 검토할 책임과 함께 따릅니다. 요컨대, Cursor의 AI 에이전트는 크고 반복적인 코딩 작업을 관리 가능한 워크플로로 전환할 수 있지만, 명확한 지침과 인간의 감독이 필요합니다. 방대한 코드베이스로 어려움을 겪는 팀에게 Cursor는 강력한 생산성 증대 도구가 될 수 있습니다. 신중한 체크포인트와 강력한 테스트를 통해 사용되는 한 말이죠.

Cursor가 올바른 도구인지는 프로젝트에 따라 다릅니다. 심층적인 교차 파일 인텔리전스가 필요하고 새로운 IDE로 마이그레이션할 수 있다면, Cursor는 일반적인 자동 완성 도우미를 넘어서는 특화된 기능을 제공합니다 (www.datacamp.com) (www.datacamp.com). 현재 편집기에서 점진적으로 작업하는 것을 선호한다면 GitHub Copilot(또는 다른 채팅 기반 도구)이 더 편리할 수 있습니다. 코딩의 미래는 Cursor와 같은 AI 에이전트가 인간 개발자를 보완하는 형태가 될 것으로 보입니다. 지루한 기본 작업을 처리하고 프로그래머가 설계와 전략에 집중할 수 있도록 하는 것이죠. 한 전문가는 “코딩의 미래는 더 많은 코드를 작성하는 것이 아니라, 코드를 덜 변경하는 것입니다. 그리고 Cursor는 잘 사용될 때 정확히 그렇게 할 수 있게 해줍니다” (ginno.net)라고 언급했습니다.