Claude 및 Discourse 관련 개발. 성능이 얼마나 좋나요?

저는 개발자가 아닙니다. 기본적인 코딩 지식만 있을 뿐이고, 간단한 코드 정도는 읽을 수 있습니다.

최근에 플러그인을 하나 만들어 보았는데요, 대부분 Gemini 무료 버전을 이용했습니다. 코드의 95%가 AI가 생성한 것이었습니다.

플러그인은 확실히 작동하고, 인터페이스와 관리자 경험도 꽤 괜찮은 편이지만, 코드 청결성에 대해 정당한 우려가 있습니다. 제 프롬프트 작성 노력[1](그리고 공식 코드 발췌문을 AI에 수동으로 입력해 주는 것)에도 불구하고, 해당 코드가 Discourse 환경을 잘 활용하지 못하고 있다고 확신합니다. 헬퍼, 컴포넌트, 클래스 등 말입니다. 그래서 가끔 공식 코드의 일부를 AI에 입력해 주었습니다.

요즘 많은 개발자들이 워크플로우에서 AI를 사용한다는 이야기를 들었습니다. AI가 Discourse 생태계에 대한 인식이 있다면 AI가 생성한 Discourse 플러그인 코드가 얼마나 더 좋아질지 궁금합니다.

Claude, 특히 Opus 모델을 사용해 보라고 조언을 받았습니다. 또한 토큰 소모량이 많아 비용이 비싸다고도 들었습니다.

제 프로젝트에 대해 큰 야망은 없습니다. 그저 취미일 뿐이죠. 제가 상상하는 플러그인이 현실에서는 어떤 모습일지 궁금한데, AI는 이를 파악하는 데 꽤 뛰어납니다.

플러그인이나 컴포넌트를 개발할 때 AI를 사용해 보셨나요? IDE에 통합된 Claude Opus를 시도해 보셨나요? 도움이 많이 되셨나요?
기존 코드베이스를 적절히 활용하여 새 코드를 생성하나요?
비용은 얼마나 드나요? 어떤 요금제를 선택하셨나요?


  1. '프롬프트 작성 노력’이라고 쓰니 어색하고 부끄럽습니다 :lolsob: ↩︎

Discourse 작업을 할 때 AI에게 참고할 예시가 있으면 작업 효율이 훨씬 더 높아진다는 것을 발견했습니다. 특히 Claude Code는 이 부분에서 뛰어난 성능을 발휘합니다 (Google Gemini의 CLI도 마찬가지!).

취미 개발자의 경우, 월 $20 요금제로 꽤 멀리까지 갈 수 있을 것입니다… 일일 사용 한도에 도달하는 것은 어렵지 않지만, 그 시점에 한도가 리셋될 때까지 기다리거나 크레딧을 구매하면 됩니다.

가격에 대해 오해하고 있었던 것 같습니다. 무료/프로/맥스 플랜은 웹 인터페이스를 통해 Gemini를 사용할 때 적용되는 것이었네요. (https://claude.com/pricing). API 가격은 토큰 기반으로 부과되며(https://claude.com/pricing#api), API 사용에 대한 월정액 구독은 없나요?

VSCode 같은 도구에 AI를 사용하려면 그들의 API를 이용해야 합니다.

수정: 다음에는 글을 쓰기 전에 먼저 튜토리얼을 좀 읽어야겠네요 :upside_down_face:

지난주 저는 ask.discourse를 사용하여 Discourse 플러그인을 작성하는 데 시간을 보냈습니다. 만들고 싶은 플러그인의 기능을 설명하기만 하면 수많은 팁과 코드 스니펫을 출력해 주었고, 그중 일부는 실제로 실행되었습니다.

저는 취미로 프로그래밍을 하는 사람입니다. Discourse 인스턴스 외에도 MySQL 데이터베이스, PHP 백엔드, 그리고 Jquery/JavaScript 프론트엔드를 갖춘 다른 서버를 운영하지만 전문 프로그래머는 아닙니다. 해당 사이트를 개발할 때 대부분 그냥 구글에 원하는 것을 물어보면(아마도 Gemini일 텐데?) 코드 예제를 출력해 줍니다. 대부분의 코드가 바로 실행되며, 그렇지 않은 경우에도 저는 JavaScript에 충분히 익숙하여 원인을 파악할 수 있습니다.

수년간 다양한 프로그래밍 언어를 사용해 왔고, 과거에는 몇 시간씩 읽기, 검색, 실험을 반복해야 했던 것들을 이제는 구글에 물어보면 몇 분 만에 끝낼 수 있습니다. 과거에는 몇 시간 또는 며칠이 걸리던 작업이죠.

ask.discourse가 얼마나 잘 작동하는지 놀랐고, 결국 원하는 기능을 대략 수행하는 플러그인을 작동시켰습니다. 몇 가지 스타일링(CSS)을 추가하면 사용 가능한 플러그인으로 발전할 수 있을 것입니다. AI 지원 서비스가 코드 생성을 효율적으로 만들어 줄 수 있다는 가능성에 큰 관심을 갖고 있습니다.

Antigravity를 사용하여 제 디스코스 페이지용 플러그인을 작성했습니다. 이 플러그인은 가장 인기 있는 애니메이션 시리즈를 표시합니다. 시청 목록도 만들었습니다. 가끔 오류가 발생해 많은 수정이 필요하지만, 대체로 만족하고 있습니다.

VSCode에서 Pro 플랜(20달러)으로 작동하게 만들었습니다. 소비량은 적절하다고 생각합니다. 3시간 동안 프롬프트를 입력한 결과 이 정도가 나왔습니다:

지금까지 결과는 그다지 좋지 않았습니다. :thinking:

흥미로운 점은 Discourse용 플러그인이나 테마 컴포넌트를 만들 때(스켈레톤 기반) Claude에게 무엇을 설정해야 하거나 무엇을 알려야 하는지 설명하는 것입니다.

Claude의 효율성을 극대화하기 위해 CLAUDE.md 파일에는 어떤 지침을 작성해야 할까요?

AI가 코드베이스에서 정보를 찾을 때 특정 Discourse 디렉터리를 우선시해야 할까요(컨트롤러, 모델, 시리얼라이저, 서비스 등)?

표준 파일 계층 구조, 네이밍 규칙, 컨벤션을 인식시키려면 어떻게 해야 할까요?

스킬을 출시해야 합니다. @j.jaffeux와 저는 그것이 매우 유용할 수 있다고 생각합니다.

skills에 대해 말씀하시는 거죠?


skills를 처음 접하시는 분이라면 다음 자료들이 도움이 될 수 있습니다.

이 목록은 전체를 포함하지 않으며, 매일 더 빠르고 길게 늘고 있습니다.

I looked at https://github.com/discourse/discourse/blob/main/AI-AGENTS.md.

I have questions!

  • NEVER store find() results - causes stale element references after re-renders

ALWAYS lint any changes you make

Do AIs understand the all-uppercase emphasis? Would it act differently if written “Never” and “Always” instead?

Are things like “architect mode” or other “xxx mode” prompts becoming soft standards in AI development? Do they have any real effect on model behavior? Are they pure conventions?

  • Don’t write obvious tests

I can see what an obvious test is, but do AIs understand what an obvious test (or obvious anything) is?

I toyed for a couple of days with Claude in VSCode. It’s quite impressive to see everything working by itself. Reading, creating, modifying files, running bash commands, etc… :exploding_head:

About Claude’s work on plugin creation, this is what I observed:

  • When iterating over the same pieces of code and solving issues, it tends to use excessively specific variable names. For example, it would name a variable original_url instead of a very fine and simple url, as if meant to point out changes that were made, when it’s not necessary.

  • Iterations often lead to convoluted code, and sometimes, unnecessarily complicated queries. Asking the AI to review and point out parts of code that can be refactored from time to time is proven useful for this :slight_smile:

  • When asked to find solutions for a given issue, I’ve been pleased by the answers.
    The suggestions seem accurate. When it proposes several options, it can accurately weigh the pros and cons of each one.

  • In SCSS, it (rarely) uses hardcoded colors where it’s not advised, instead of using Discourse’s color variables.

  • It doesn’t seem to be aware of Designing for Different Devices (Touch & Hover) and will rely on standard media queries instead.

  • After several tasks have been made, I like to ask the AI to review the code and see if some parts can be optimized without impacting the maintainability. I didn’t have many issues with the results. Sometimes, it tweaks too much and breaks the code.

  • Occasionally, it seems to create unnecessary conditions for the sake of security and robustness, but for situations I’m not sure exist in real-world conditions.
    For example, in my search-related plugin, it would check if a post has any topics associated with it. But posts without a topic are not supposed to exist in Discourse, I think. If you have one, it means something went very wrong in your instance at some time, right? I feel it made no sense to make this check in my plugin. :thinking:

  • It seems good at scaffolding tests!

So, good experience so far, even without using advanced AI configuration.
I spent my weekly quota in four days, which is great because it forces me to take a three-day pause :raising_hands:

Curious to see how it will change when Discourse’s skills are added.

하루 종일 Claude와 함께 적응하는 시간을 보냈습니다 :heart_eyes: (ChatGPT와는 이별했죠). 이제 Claude Code를 활용해 최소한 프로토타이핑을 해보거나, Discourse 관련 궁금증을 풀어볼 생각에 기대가 큽니다. 어딘가에 숨겨진 기능이나 팁이 있다면 기꺼이 시도해 보고 싶습니다.

입력됨:


플러그인 개발을 실험해 본 후, Claude를 이용해 테마를 만들어 보았습니다. 결과는 재앙이었지만, 단순한 CSS 요청에도 자주 무의미한 내용을 출력하는 경향이 있어 크게 놀랍지는 않았습니다. 각 요소가 놓인 맥락을 제대로 파악하지 못하는 것 같아, 요소가 제대로 제작되거나 배치되지 않는 경우가 많았고, 쓸모없는 속성이 한가득 붙어 나오는 일이 잦았습니다.
테마 개발을 위한 구체적인 지침이 마련될 때까지, 이러한 작업에는 매우 신뢰할 수 없다고 생각합니다.

여러분, 몇 달 전 AI 개발로 작은 미니 프로젝트 두 개를 진행해 본 경험이 있어서 제 생각을 좀 말씀드릴게요:

요약하면, Discourse 테마/컴포넌트 개발에 있어 모든 모델이 상당한 가드레일(제약 조건)이 필요했어요!

학습 데이터가 구식이라 대부분 2년 전 것이어서, 플러그인과 테마 개발을 위해 매우 구체적인 지침이 필요합니다.

당시 제가 했던 일은 다음과 같습니다:

기본적으로 Discourse 테마 컴포넌트 개발 문서를 가져와 마크다운 지침 파일로 압축한 뒤, 각 프로젝트에 추가했습니다.

하지만 사실 SKILLS라는 개념이 생기기 전이었어요…

이것은 훌륭한 추가 기능이 될 거예요!

플러그인 개발, 테마 개발, 그리고 아마도 일반적인 Discourse 개발에 특화된 스킬을 별도로 제공하는 것이 합리적일 수 있습니다.

@sam Discourse 개발 문서가 더 이상 Github에 호스팅되지 않는 이유는 무엇인가요? 이제 Discourse Meta에서 직접 관리하고 있는 건가요?

리포지토리에 포함되었습니다: discourse/docs at main · discourse/discourse · GitHub

이 기사를 우연히 발견했어요:

https://sabaramalingam.medium.com/i-let-claude-code-build-my-wordpress-site-heres-what-happened-9e20f20970c6

이 주제로 인해, 이것이 ‘마이그레이션’(xyz에서 Discourse로의 전환)이라는 게임 자체를 바꿔놓을지 스스로에게 질문하게 되었습니다…

이 이야기가 사실이고 흥미로울 수는 있지만, 100%(또는 대부분) AI가 생성한 텍스트를 읽을 때는 항상 신중해집니다. :grimacing:

사람이 쓴 것처럼 보이는 경험 공유를 읽는 것을 더 선호합니다. 그렇게 하면 항상 더 신뢰할 수 있고 믿을 만한 느낌이 들기 때문입니다.