▲

에이전틱 코딩 추천사항

 (lucumr.pocoo.org)
12P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Agentic coding에 대한 실사용 사례 공유
  • Claude Code Sonnet 모델을 주로 사용하며, IDE 통합보다는 전체 작업을 AI에게 위임하는 방식을 선호함
  • Go 언어는 에이전트 친화적인 구조와 생태계 안정성 덕분에 새로운 백엔드 프로젝트에 특히 추천됨
  • 속도와 단순성이 에이전틱 코딩의 핵심이며, 테스트 캐시나 간단한 툴 체계가 중요함
  • 코드는 단순하고 병렬처리 가능하게 구성해야 하며, 에이전트의 성능을 극대화하려면 리팩터링 시점 선정이 매우 중요함

Preface

  • 최근 에이전틱 코딩 경험을 공유하는 개발자들이 급증함
  • 나는 현재 Claude Code Sonnet 모델을 Max 요금제($100/월)로 사용함
  • IDE의 비중이 줄었고, 대신 Vim을 다시 사용하게 되었으며, Claude에게 작업을 맡기고 결과만 확인하는 식의 흐름을 사용함
  • 혁신 속도가 매우 빨라 포스팅 내용이 빠르게 낡을 수 있기 때문에, 오래 유지될 개념에 초점을 맞춤

The Basics

  • claude --dangerously-skip-permissions 명령어를 claude-yolo로 alias 설정해 모든 권한 제한을 제거함
    • 이는 dev 환경을 Docker로 안전하게 격리하여 관리할 수 있음
  • Claude는 대부분의 기본 툴을 잘 다루기 때문에 MCP(Multi Capability Protocol)는 특수한 경우에만 사용함
    • 예: playwright-mcp를 통한 브라우저 자동화
  • 직접 만든 툴은 일반적인 스크립트로 구성하며 가능한 한 단순한 툴 구성 유지

Choice Of Language

  • 다양한 언어로 에이전틱 코딩을 실험한 결과, 새로운 백엔드 프로젝트에는 Go가 가장 이상적임
    • Context 시스템: 코드 전체에 명확히 흐르는 데이터 구조 제공, 에이전트에게 명시적 전달 방식이 간편함
    • 테스트 캐시: Rust 등 타 언어 대비 테스트 실행과 캐시가 단순, 에이전트의 코드-테스트 루프가 효율적임
    • 단순함: Go 자체의 단순성이 에이전트에게도 유리하게 작용함
    • 구조적 인터페이스: 타입에 메서드만 맞으면 인터페이스로 인식되어 LLM이 쉽게 처리 가능함
    • 낮은 생태계 변화율: 오래가는 버전과 명시적 변화, 구식 코드 자동 생성을 줄일 수 있음
  • Python은 많은 문제점을 유발
    • fixture나 async 처리, 느린 실행 등으로 인해 agentic loop에서 효율이 떨어짐
  • 프론트엔드는 Tailwind + React + Tanstack Query/Router + Vite
    • Tanstack Router의 파일명에 포함된 $ 기호는 에이전트를 혼동시켜 문제 발생

Tools, Tools, Tools

  • 툴의 기준은 다음과 같음
    • 빠를 것
    • 친절한 에러 메시지 제공
    • LLM이 잘못 사용할 경우에도 안정적으로 동작할 것
    • 관찰 가능하고 디버깅이 쉬울 것
  • Makefile 기반으로 make dev, make tail-log 등 명령어 제공
    • 실행 상태 중복 방지를 위해 shoreman 포크 버전으로 pid 관리
    • 로그는 stdout과 파일에 모두 기록해 에이전트가 직접 로그에서 정보 추출 가능
  • 예: 이메일 인증 링크도 로그에 기록되도록 설정하여 브라우저 자동화로 이메일 인증 절차 수행 가능

It's All About Speed

  • 에이전틱 코딩의 최대 비효율은 추론 비용과 비효율적인 툴 사용
  • 빠른 툴 응답 속도가 생산성의 핵심
  • 에이전트가 자체적으로 임시 도구를 만들고 사용할 경우, 빠른 실행/컴파일 속도가 업무 효율을 크게 향상시킴
  • 느린 환경에서는 동적 모듈 로딩 등의 대안(예: Sentry용 파일 모듈 감시 및 자동 실행) 활용이 유리함
  • 로그는 간결하고 명확하게 조절하여 토큰 소모 및 속도를 최적화해야 하며, 필요시 LLM이 로그 수준을 조절할 수 있는 인터페이스 제공이 도움이 됨
  • 코드 생성 단계에서부터 유의미한 로그/옵저버빌리티가 나오도록 설계하는 것이 중요함

Stability and Copy/Paste

  • 에코시스템의 안정성은 코드 재사용성과 에이전트의 혼동 방지에 매우 중요
    • Go와 Flask 같은 변동폭이 적고 예측 가능한 언어/프레임워크 사용 권장
  • 라이브러리 자동 업그레이드에 주의, 에이전트가 남긴 주석이나 코드 흐름이 깨질 수 있음
  • 가능하면 직접 코드 작성 → 의존성 최소화 전략 권장

Write Simple Code

  • 에이전트는 단순하고 명시적인 코드에 더 잘 대응함
  • 권장 방침
    • 설명적이며 긴 함수명의 함수 사용 선호, 클래스보다는 함수 위주 작성
    • 상속 및 복잡한 트릭 회피
    • 순수 SQL 사용 추천; 에이전트가 SQL 실력에 능숙하며, 로그와 비교 및 추적이 쉬움
    • 명확한 권한 체크는 코드 상에서 직관적으로 드러나게 구성(별도 파일/설정 분리 금지)

Make It Parallelizable

  • 개별 에이전트의 처리 속도는 빠르지 않으나, 병렬 처리를 통해 전체 효율을 높일 수 있음
    • 예: 파일 시스템을 기준으로 체크아웃 복사
    • Redis나 DB 등 공유 자원 분리 방법 고민 필요
    • 예시 툴: container-use를 이용한 Docker 기반 세션 분리
  • CI 기반 병렬 작업, Cursor의 background agent 등도 주목할 도구

Learn To Refactor

  • agentic 방식은 적절한 시점의 리팩터링이 중요
    • 복잡성이 높아지면 agent가 코드를 제대로 다루지 못함
    • 예: Tailwind class가 50개 파일에 흩어지기 전에 컴포넌트 라이브러리화
  • 너무 이른 혹은 너무 늦은 리팩토링 모두 비효율적이므로, 적절한 타이밍에 구조 개선 지시 필요

What Next?

  • agentic coding은 빠르게 진화하고 있으며, 핵심 원칙은 ‘단순함, 안정성, 가시성, 병렬성’
    • 도구와 방법론은 변해도 이 원칙은 유효함
  • 생산성 향상뿐 아니라 더 나은 코드 품질 추구가 목표
  • 에이전트가 작성하는 코드의 품질은 몇 달 전보다 현저히 개선됨
  • 유연하게 변화에 대응하며 코딩 경험을 확장할 것
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 나는 VS Code Nightlys에서 co-pilot과 Claude Sonnet 4를 함께 사용해 Agentic Coding을 경험하고 있음. 하루의 절반이 회의로 채워져도 내 git 히스토리만 보면 모를 정도로 생산성 향상을 느끼는 중임. 이제는 세세한 구현 대신 변화가 제대로 동작하는지, 이 코드를 이해할 수 있는지, 더 잘 이해하려면 구조를 어떻게 잡으면 좋은지, AI 컨벤션 마크다운에 추가해서 Agent의 오해를 줄이려면 뭘 더 넣을 수 있을지 고민하는 수준임. 어젯밤엔 mypy 에러가 38개나 있던 파일을 Agent에게 맡기고 15분 가족과 대화하고 오니, Agent가 수정한 내용과 이유를 요약해줌. 변경사항 중 하나를 놓고 토론도 했지만 결국 Agent의 의견이 맞다고 판단함. mypy 체크도 통과함. 이제 팀에도 이 기술의 진짜 가능성을 이해시키려고 노력 중인데, 회의적인 시선과 AI 완벽하지 않다는 이유로 반대하는 사람들도 있음. 하지만 친구의 말을 빌리면 "오늘이 앞으로 너와 이 기술이 겪을 가장 나쁜 날"이라는 점이 바로 혁신의 증거라고 생각함

    • type checker 에러는 사실상 개발 일과에서 가장 적게 시간을 들여야 하는 부분인데, 그 부분이 그렇게 오랜 시간을 잡아먹었는지 궁금함. 모든 AI 활용 논의가 실제 각자 어떤 작업에 쓰고 있는지 다 같이 볼 수 있다면 (cloudflare 포스트처럼) 효과가 훨씬 클 거라고 생각함

    • 개인적으로 Python보다 Rust 코드에 Agent를 더 신뢰함. Python은 정적 분석 수준이 clippy나 rust-analyzer만큼 좋지 않아서 모든 코드 경로를 매번 직접 돌려봐야 함

    • 하루의 절반이 회의여도 git 히스토리만 보면 모를 정도라고 했는데, 만약 내가 소속 회사 직원이라면 곧 이 정도 산출물을 계속 기대할 거라는 점 명심함

    • 워크플로우가 궁금함. Claude Code를 개인 프로젝트 실험용으로 써보고 있고 회사 계정으로 Copilot도 VS Code의 agent 모드에서 3.5, 3.7 Sonnet, 04-mini까지 다양하게 섞어서 써봤음. Go 대형 프로젝트에서 활용했는데, 테스트 쪽 빼고는 결과가 최악임. 도구를 잘못 쓰는 건가 싶어 "최신 베스트 프랙티스" 다 시도해봤는데 컨텍스트, 모델 바꿔가며 사용, 규칙 지정, 프롬프트 개선까지 전부 시도했음에도 개선이 없었음

    • AI 컨벤션 마크다운에 Agent 실수를 줄이려는 내용을 더 추가할 수 있냐고 하셨는데 그게 매 작업마다 컨텍스트로 첨부하는 파일인지, 아니면 VS Code Copilot Agent의 공식 컨벤션인지 궁금함. 그리고 문서 구조를 정하는 데 참고자료가 있었는지, 아니면 AI가 반복하는 실수를 기반으로 시간이 지나면서 직접 개선한 산출물인지 물어보고 싶음

  • Agentic coding을 효율적으로 만드는 기술 대부분이 인간 코딩 효율도 높여준다는 점이 정말 고무적임. 예전엔 AI만 이해하는 '거대한 진흙덩이' 코드에 대한 우려가 있었지만 실제론 반대임. 명확한 코드가 AI 생산성에도 훨씬 중요해졌고, 덕분에 생산성 차이가 명확히 수치로 드러나게 됨. 클로드가 코드베이스마다 얼마나 잘 동작하는지 수치로 보여줄 수 있어서, 코드가 잘 구조화되어 있냐는 논쟁도 더는 의견 차이가 아닌 객관적 근거로 대화 가능함

    • 코드가 '진흙덩이'가 될 거란 걱정은 사실 프로그래밍 내내 있어왔던 고민임 (Rich Hickey 강연 보라). 사람들은 "지금 편하게 가자"를 택하다가 내일 엄청난 기술 부채를 떠안게 됨. LLM 덕분에 의미 없이 보일러플레이트를 양산하는 것도 더 쉬워짐. 아픔이 줄면 굳이 고칠 생각 자체가 사라질 수도 있음

    • 'AI만 이해할 코드가 될 거란 걱정, 지금은 아니라도, 앞으로는 어떨지 알 수 없음'이라는 말도 꼭 남기고 싶었음

    • 이 부분이 정말 공감됨. 좋은 에러 메시지, 빠른 도구, 안정된 생태계, 단순하고 '매직' 없는 코드, 직관적 SQL까지, 원래 내가 꿈꾸던 개발 환경임. 에이전트가 워낙 빨리 일하니까 작은 지연 하나하나가 체감될 정도라, 이런 기술 덕분에 전체 개발 경험 수준이 올라갈 수 있다고 생각함

  • Agent를 쓰다 보면 Go, Tailwind로 자연스럽게 유도된다는 말을 들음. 훈련 데이터가 풍부하다 보니 AI가 제대로 다룰 수 있기 때문임. 그럼 모든 사람이 이 도구를 쓰는 미래엔 새로운 언어나 프레임워크, 라이브러리가 등장하기 어려워지는 현상은 발생하지 않을지 걱정도 듦. 기존 솔루션과 경쟁이 어려워지고, StackOverflow 같은 사람 커뮤니티도 사라질 수 있음

    • 새로운 언어나 프레임워크가 아예 등장하지 않을 거란 걱정에는 동의하지 않음. LLM들은 번역에 엄청 강해서 훈련 데이터가 없더라도 독특하지만 구조가 명확한 프레임워크는 코드베이스 보고 바로 학습하는 능력이 있음. 실제로 내 idiosyncratic C# 프레임워크(누구도 본 적 없는)도 LLM이 아주 잘 다루는 걸 경험. 물론 Rust의 라이프타임 같은 독특한 특성은 바로 호환되지 않을 수 있지만, Go처럼 단순한 건 금방 적응함. 앞으로는 새로운 언어를 만들 때 아예 LLM 호환성(디자인, 툴링, 문서 등)을 고려해 만들어야 할지도 모름

    • 정말 중요한 질문임. 다시 말하면, LLM 생성 데이터로 인터넷이 뒤덮이면서 양질의 훈련 데이터가 줄어들 텐데, LLM 친화적인 개발자들은 과거 '방사능 적은' 옛 기술(JS/React 등)에 더 끌릴 수도 있음. 앞으로 JavaScript/React는 미래의 COBOL이 되어도 값비싼 컨설턴트 필요 없는 시대가 오고, 유지보수는 LLM이 다 할 수 있음. AI 유행을 피하고 싶다면 새 언어 개발, 특히 Lisp+DSL처럼 LLM이 바로 학습 못하는 특이 언어는 AGI 시대 이전까진 꽤 안전할 수도 있음

    • 소프트웨어 스택의 전통적 순환 구조는 다음과 같음. (1) 기존 스택이 모든 니치 분야까지 껴안고 복잡해지면, 전문가들이 불필요한 '아토텍처' 난무 (2) 그로 인해 훨씬 더 쉽게, 명확하게 새 트렌드 해결하는 간단한 새 스택이 나와 인기를 얻고 (3) 시간이 흘러 결국 이 새 스택도 같은 문제로 무거워지면서 악순환 반복. AI 코딩도 컨텍스트 확장이 빨라지고 있어 이 사이클이 쉽게 깨지지 않을 거라 생각

    • Go, Tailwind 강제된다는 주장은 실제론 글쓴이의 개인적 성향이 많이 반영된 관점임. Sonnet이 cargo test CLI에서 문제 있다고 해서 Rust, cargo, 더 크게 AI 전체가 문제라고 볼 수 없음. 실제 PHP 테스트에서도 Junie가 built-in runner를 잘 못 쓰긴 하지만, bin/test-php 스크립트를 만들어주니 잘 알아서 사용함. 요구사항을 가이드라인에 명시적으로 써주는 게 도움 되긴 해도, 기본 제공 도구 고집하는 특성을 가진다는 차이임. Stack Overflow 경험에 대해서도, 내 AI 어시스턴트는 질문을 중복으로 닫지 않는 장점이 있음. SO의 큐레이션 시도는 좋지만 그로 인해 많은 사용자를 떠나게 만든 것도 사실임

    • 어제도 Claude (Zed 사용)에게 elixir phoenix 새 프로젝트를 조건만 주고 맡겼는데 문제없이 잘 수행함. CSS로 tailwind를 썼는데, 그건 phoenix가 자체적으로 기본 세팅을 해줘서 그런 것 같음. AI가 Go로 유도한다는 주장에는 공감 못함. 오히려 맥락 없이 물어볼 땐 Python 쪽 제안이 넘치고, 커뮤니티 규모가 작은 elixir도 문제없이 잘 활용하는 경험임

  • Claude Code Sonnet 4.0으로 Rust 코드 한 주 정도 실험해봤는데 기대 이하임(게다가 Bedrock 경유라 비용도 비쌈). 초기 계획 세우는 데 시간 오래 쓰는데도 실제론 절반만 완수하는 경우가 많음. 내가 뭘 놓치고 있는 건지 궁금함

    • 나도 거의 같은 느낌임. Cursor Edit/Agent 모드에서는 한 번에 거의 원하는 수정이 나와서 엄청 효율적인데, CLI 환경에선 너무 불편함. 혹시 클로드 코드에게 10~15분 작업을 맡기고 diff만 리뷰하는 식으로 사용하는지, 아니면 코드 리뷰도 제대로 하고 있는지가 궁금함

    • 나도 완전히 똑같은 경험임. 쓸만한 활용 케이스를 일부러 찾아 다니면서 써봐도 제대로 동작하지 않아서 정말 의아했음

    • 비싸게 느끼면 안 됨. Pro 플랜은 월 20달러, Max는 100~200달러인데, API로 쓸 때 월 천 달러 넘게 드는 것보다 저렴한 구조임

  • 컨테이너 사용이 언급된 게 꽤 반가움. 나는 dagger/container-use에 참여 중이고, 팀에는 ex-Docker 멤버와 docker 창업자도 있음. Agent들을 병렬로 돌리는 게 큰 기술 진보의 분기점이 될 거라 생각함(신뢰성 있게 잘 활용할 수 있게 되면). 그 전까지라도, Agent 작업 돌리는 동안 내가 딴 일 하거나 Agent가 엉뚱한 부분을 건드릴까 걱정된다면 개발 환경을 컨테이너화하는 게 매우 유용함. 컨테이너 사용 기술도 아직 초창기지만 굉장히 빠른 속도로 발전 중이고, 현재는 안정성/깃 충돌 감소/사람과 Agent 간 상호작용 강화를 중점적으로 개선하고 있음

  • 언어 선택에 대한 내 생각은 다음과 같음. 1) Java는 LLM이 참고할 수 있는 방대한 규모와 오랜 데이터셋 덕분에 가장 포괄적(반드시 가장 정확하다는 건 아님). 2) 무엇보다 본인이 제일 잘 아는 언어로 진행해야, LLM이 잘못된 추론, 오류, 환각 등 실수를 빠르게 잡아낼 수 있음

    • Java가 가장 큰, 오래된 명확한 데이터셋으로 꼽힌다는 의견은 LLM이 API/문서/3rd party 소스코드를 찾아볼 도구를 못 쓸 때에 한정한 조언 같음. 툴이 자동으로 뭘 써야 하는지 알아낼 수 있다면, 어떤 언어를 선택하든 결국 Agent가 소스를 읽을 수 있기만 하면 됨. 하지만 두 번째 의견(아는 언어를 써야 한다)엔 전적으로 동의함. 결국 사람의 꼼꼼한 검토가 필수이고, 아는 언어면 오류 판단도 수월함

    • 왜 Java가 데이터셋이 가장 클까? 오픈소스 프로젝트 중 Java가 가장 많은가(전체 Apache suite 때문?) 아니면 Java 오픈소스 라이브러리의 문서가 아주 풍부해서 그런가 궁금함

    • 내 생각엔 Python 코드가 가장 많은 데이터셋일 거라 여겨왔음. 아무 언급 없을 때 LLM들은 대부분 Python부터 추천하는 경향이 있음

  • Go의 context system(명시적 데이터 백, 코드 실행 경로 따라 흐르도록 설계)이 AI agent에 단순함을 제공한다는 주장에 "tracing data를 제외한 데이터를 context.Context에 담는 건 실제 좋지 않은 관례"라는 비판이 있음

    • 동의함. chromedp(Go용 chrome headless driver)에선 context.Context를 1번째 인자로 쓰는데, 그냥 context.Background()가 아닌 특수 factory에서 얻은 context만 써야 하는 구조임. timeout 설정만 context.WithTimeout으로 따로 처리하고, 거의 void* 포인터처럼 쓰는 셈임

    • Go 전문가까지는 아니지만, 실제로 라이브러리들이 context에 데이터베이스 연결, 설정, 레이트리미터, 캐시백엔드 같은 데이터 담는 경우가 많아서 당장 나로선 그다지 문제라 느끼진 않음

  • ‘AI가 이해할 만큼 단순한 코드 쓰기’는 내가 기대했던 혁신 포인트는 아님. 내 이전 ugly code 관련 글과 방식이 어떻게 충돌하는지도 궁금함

    • 이런 식의 단순/명확 코드 작성 방식은 사실상 팀 작업에서 항상 도움됨. 코드에 극도로 집중하거나 창의적으로 짜야 할 순간도 있지만, 그건 예외적이고 비즈니스 가치에 밀접해야 함. 대부분의 코드는 "누가 봐도 자명한 게 답"임. 개발자가 느린 건 타이핑이 아니라 머릿속에서 한 번에 담아야 하는 '개념'의 양 때문임. 인터페이스 오버엔지니어링 하지 말고, 추상화도 미루고, 복붙과 단순한 조립 허용, pattern은 그냥 공식 문서대로, 절대 똑똑하려 하지 말기. 코드는 예쁘게가 아니라 명확/단순하게 구성, 실제 어려운 건 코드 자체가 아닌 '제품'이라는 점 강조가 핵심

  • Claude Code에 대해 글쓴이가 썼듯, 다양한 대안(OpenCode, goose, Codex, Devin, Cursor background agent 등)이 실제로 존재함. 클로드 코드와 비슷한 오픈소스+로컬 LLM 솔루션이 궁금하다는 질문이 있음

    • 지금으로선 강추할만한 오픈소스+로컬 LLM 솔루션은 딱히 없음. 다만 SST의 OpenCode가 UX 쪽으로 빠르게 진화 중이고, 앞으로 좋은 로컬 모델이 더 나오면 적용도 쉬워질 거라 생각함. 가장 큰 문제는 실제 '툴 사용'이 뛰어난 좋은 모델이 거의 없음. Sonnet이 충격적으로 잘하는 이유도 툴 사용에 특화된 훈련 덕분임. Gemini도 아직 한참 미달이고, 결국 좋은 모델만 나오면 해결될 문제라 봄

    • Aider의 경우 거의 다다랐지만 의도적으로 완벽히 agentic하지 않음. 테스트/정적 분석 자동 실행, 자동 오류 수정 등 다 가능하고, to-do 리스트 기반 전체 프로젝트 스펙도 다룰 수 있음. 지금은 하드코딩된 리플렉션 반복 횟수(3회) 제한이 있는데 해킹으로 마음대로 늘릴 수 있고, self prompting만 추가되면 완전 자동화 agent화도 가능

    • 곧 출시할 내 앱도 좋은 대안이 될 거라 생각함. 싱글 파일 다운로드, 설치 필요 없는 구조로 Mac, Windows, Linux, Docker에서 다 사용 가능. OpenAI API와 호환되는 모든 모델 활용 가능(직접 돌리는 것도 포함), 브라우저 기반이라 Claude Code 못지않게 편하고, 명령어 기반 콘솔 앱도 제작 가능. 추가로 터미널을 직접 열어 서비스에 연동할 수도 있음. 현재는 클로즈드 알파지만 사용 원하면 이메일 연락 주면 됨

    • 거의 매일 새로운 대안(혹은 시도작) 출시되고 있어, 조만간 '딱 맞는' 대안을 쓸 수 있을 거라 기대. 예를 들면 app.build는 Neon(현재 Databricks) 팀이 막 런칭해서 꽤 유망해 보임

    • Neovim 플러그인 CodeCompanion도 최근 더 agentic한 방향으로 진화 중임. 이미 auto-submit loop, 내장 툴, MCP 통합 기능 지원. CLI 독립형 도구가 아니지만, 풀 에디터 환경을 바로 쓸 수 있다는 장점이 더 큼(특히 해킹/커스텀/경량 에디터 선호 시)

  • 월 100~200달러는 검증 안 된 코드 작성 AI 치고 너무 비쌈. 개인적 경험이 그리 만족스럽지 않았는데 게다가 윤리적 논란까지 있어서 진입장벽으로 작용함

    • Claude Code는 API 키로 사용하거나 월 20달러 프로 구독하면 됨

    • Aider를 API 요금 체계로 써보길 추천. context 사이즈 제어(/clear, /add, /drop)로 25K 정도로 제한 가능. 원하는 모델 사용(예: Sonnet 4, Gemini 2.5 Pro) 가능. 간단한 스크립트는 보통 1달러 이하로 완성 가능했고, 아주 대형 툴을 만들 때도 프로프트+코드 100여개 테스트까지 합쳐도 6달러 이하로 가능했음. AI로 코드 짜기에 익숙해지면, 그때 Claude Code(더 강력하지만 자주 쓰지 않으면 오히려 비쌈)로 넘어가길 권장

    • 20달러짜리 한 달 구독이면 소규모 프로젝트 몇 개는 충분히 시험해보고, 100달러 플랜 고려할지 판별 가능함. 혹은 앞으로 몇 달만 기다리며 다른 사람의 실사용 경험자 후기를 참고해도 좋을 것 같음

답변달기