요즘IT는 지난 10월 클로드 코드 세미나 ‘클코나잇’ 1회에 이어 11월 ‘클코나잇 2회 - 딥다이브’세션을 열고 개발자들이 클로드 코드를 현업에서 실제로 활용하는 다양한 사례를 공유했습니다. RSA 암호화 데스크톱 앱을 만들거나 AI 오케스트레이션을 실행한 사례, 3일 만에 위기를 해결한 사례 등을 공유했습니다. 참가자들에게 “명불허전” “안 들었으면 후회할 ” “아이디어 가득 얻고 가는 시간!”이라고 호평을 받았습니다. 아쉽게도 참석하지 못한 분들을 위해 그날의 핵심 내용을 정리해 콘텐츠로 다시 전해드립니다.

이번 글은 세미나 첫 번째 주제였던 “[Tool 개발] Claude Code로 만드는 개발자 툴: RSA 암호화 앱 RiSA 개발기”입니다. 발표자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다. 1월부터는 ‘AI 빌더스쿨’이라는 기획이 시작됩니다. 요즘 세미나 계정을 ‘최신 콘텐츠 알림받기’ 설정하시면 참가 페이지 오픈시 이메일로 알림 받으실 수 있습니다.

안녕하세요. 대교에서 소프트웨어 엔지니어로 재직 중인 조영록입니다. 오늘은 클로드 코드를 활용해 RSA 암호화 데스크톱 앱 ‘RiSA'를 개발한 경험을 공유하려고 합니다.

그린필드 프로젝트로 시작하다

먼저 바이브 코딩을 하는 두 가지 상황에 대해 말씀드리겠습니다. 소프트웨어를 만들 때 우리는 그린필드 프로젝트와 브라운필드 프로젝트로 구분합니다. 그린필드 프로젝트는 아무것도 구축되지 않은 빈 환경에서 새로 시작되는 프로젝트를 의미하고, 브라운필드는 이미 구축된 코드베이스가 있는 상황을 말합니다. 이번에 바이브 코딩을 통해 만든 암호화 앱은 아무것도 없는 상황에서 시작했기 때문에 그린필드 애플리케이션 개발이라고 볼 수 있습니다.

왜 이 앱을 만들게 되었나

저희가 만들고 있는 학습용 모바일 앱은 사내 데이터 API와 통신해야 할 일이 많습니다. 이 사내 데이터 API는 보안을 위해 고객 데이터나 민감한 데이터를 RSA 암호화 방식으로 전송합니다. 문제는 디버깅을 하거나 정보를 파악해야 할 때 데이터를 암호화하거나 복호화해야 할 일이 자주 발생한다는 것이었습니다.

기존에는 두 가지 방법을 사용했습니다. 첫 번째는 웹사이트에서 'RSA encryption decryption'을 검색해 누군가 구현해 놓은 사이트를 이용하는 방법입니다.

첫 번째 방법은 온라인 RSA 도구를 사용하는 것입니다. 암호화 방식, 키 비트 수, 알고리즘 등을 선택할 수 있고 퍼블릭 키와 프라이빗 키를 입력하는 란도 있습니다. 두 번째는 암복호화 로직을 로컬 스크립트로 만들어두고 필요할 때마다 실행하는 방법입니다.

각각 문제가 있었습니다. 웹사이트에 민감한 키를 입력하는 것은 보안상 위험하고, 로컬 스크립트는 암복호화 코드와 실행 스크립트를 어딘가에 따로 보관하고 관리해야 하는 번거로움이 있었습니다.

포스트맨 같은 GUI 데스크톱 앱을 만들자

당시 저는 데스크톱 앱 개발에 관심이 있었기 때문에 이 기회에 간단한 GUI 애플리케이션을 만들어보면 어떨까 생각했습니다. 포스트맨이 API를 관리하고 요청을 처리하듯, 암복호화 키를 로컬에서 안전하게 관리하며 쉽게 암복호화할 수 있는 데스크톱 앱을 만들고 싶었습니다.

기술 스택 선택

평소 제가 사용하는 기술 스택은 Next.js 프론트엔드와 Node.js 백엔드 서버입니다. 저는 자바스크립트 환경에 익숙했기 때문에 데스크톱 애플리케이션을 만들 때도 Electron과 Next.js를 조합하기로 했습니다. Next.js로 UI를 구성하고, Electron의 메인 프로세스에서 Node.js를 활용하면 동일한 언어로 쉽게 애플리케이션을 만들 수 있겠다고 생각했습니다.

RiSA 앱은 RSA 키를 저장/관리하고 저장된 키를 통해 암복호화를 수행할 수 있도록 구현하였습니다. 앱의 아이콘도 ChatGPT의 이미지 생성 기능으로 제작하였습니다.

클로드 코드와의 첫 대화

앱을 만들기 위해 간단하게 프롬프트를 입력했습니다.

"Electron + Next.js를 사용해서 사내에서 RSA 암호화를 할 수 있는 간단한 데스크톱을 만들고 싶습니다. 아키텍처와 필요한 기능들을 제안해 주세요."

클로드 코드가 생각을 해서 답변을 내놓았습니다. "Electron + Next.js 기반의 아키텍처를 제안하겠습니다."

프론트는 Next.js, 데스크톱 앱 패키징은 Electron, 암호화 라이브러리는 Node.js crypto 모듈이나 node-forge를 추천했습니다. 현재 가장 많이 사용되는 기술들을 자연스럽게 선택해준 것을 볼 수 있습니다. 그리고 프로젝트 구조도 깔끔하게 정리해주었습니다.

최소 기능만 승인하기

클로드 코드로 바이브 코딩을 할 때 경험적으로 중요한 부분 중 하나는 필요한 최소 기능만 승인하는 것입니다. 너무 많은 코드가 한 번에 작업되면 컨텍스트 윈도우 문제로 인해 AI의 답변 품질이 떨어지고 사용자 입장에서 리뷰하기에도 어렵습니다. 또한 이해하지 못하고 추가된 불필요한 로직이나 낮은 품질의 코드는, 향후 작업에서 지속적으로 AI의 성능을 낮추고, 사람의 코드 이해력을 낮추는 부채로 작용하게 됩니다.

클로드 코드는 키 관리 기능, 암호화 기능, 보안 기능, 사용자 편의 기능 등 굉장히 많은 기능을 제시했습니다. 저는 일단 키 관리와 암호화, 이 두 개만 챙기기로 했습니다.

플랜 모드를 적극 활용하라

이쯤에서 제가 클로드 코드를 사용할 때 많이 사용하는 플로우와 중요하게 생각하는 포인트를 말씀드리겠습니다.

클로드 코드에는 플랜 모드라는 것이 존재합니다. 클로드 코드에서는 Shift + Tab으로 모드를 전환할 수 있는데, 세 가지 모드가 있습니다.

플랜 모드: 클로드 코드가 코드를 수정하지 않고 조사를 하고 충분히 사용자의 의도를 파악한 후 계획을 정리해서 제안합니다.
Ask before edits 모드: 클로드 코드가 코드를 수정하고자 할 때마다 사용자의 승인을 기다립니다.
Edit Automatically 모드: 클로드 코드가 모든 것을 자동으로 진행합니다. 물론 터미널 명령어나 웹 검색 같은 민감한 요청사항에 대해서는 여전히 사용자의 동의를 구합니다.

TDD와 유사한 개발 사이클

플랜 모드를 사용하다 보면 여러 가지 개발 사이클을 자연스럽게 돌아가는 모습을 경험하게 됩니다. 저는 이것이 TDD와 유사하다는 생각을 했습니다.

TDD 같은 경우 사용자가 먼저 동작하지 않는 요구사항에 대한 테스트 코드를 작성합니다. 실패하는 테스트(Red)를 작성하면 그 요구사항에 집중하며, 그 요구사항을 만족시키기 위한 최소한의 코드를 작성합니다(Green). 그리고 코드가 잘 돌아가게 되면 리팩터링을 진행하고(Refactor), 충분히 진행되었다고 생각하면 다시 실패하는 테스트 코드를 추가로 작성해서 요구사항을 점점 달성시켜 나갑니다.

클로드 코드 바이브 코딩도 이 세 단계가 돌아간다고 생각합니다.

플랜 모드(Plan Mode): AI와 충분히 계획을 논의하며 정렬합니다.
Auto Accept Mode: 계획이 완성되면 승인된 계획에 따라 AI가 구현을 자동으로 진행합니다.
User Evaluation: AI가 구현을 하면 개발자가 검토하고 요구사항이 달성 부와, 코드 품질을 평가합니다. 이때 요구사항이 충족되었다면 커밋하고, 구조 개선이 필요하다면 다시 플랜 모드로 돌아갑니다. 커밋 후 진척이 되었다 판단하면 다음 계획 다음 플랜으로 넘어갑니다.

계획을 구체화하는 과정

아이디어를 다듬어 클로드 코드에게 명령을 내렸습니다. "좋아요, 기능은 축소합시다. MVP니까 암호화와 키 관리를 탭으로 넣어서 관리하도록 합시다."

제가 암호화 라이브러리를 제대로 읽지 않아서 어떤 걸 사용해야 할지 재질문을 했고, 기능 간소화와 라이브러리 선택, UI에 대해 더 논의하며 플랜을 진척시켰습니다.

클로드 코드는 플랜 모드에서 계획을 제시했습니다.

RiSA MVP 프로젝트 최종 계획이 나오고, 암호화 라이브러리로 node-rsa를 사용하고, UI는 Ant Design을 사용한다고 했습니다. 구현 단계로 IPC 채널로 Electron의 백엔드 프로세스와 프론트엔드 프로세스를 연결하겠다고 했고요.

의문이 들 때는 멈춰라

웹 개발자로서 데스크톱 앱 개발이 익숙하지 않아 의문이 들었습니다. 키를 저장할 때 웹 브라우저의 localStorage처럼 별도 영역에 저장하는 것인지, 아니면 Electron의 Node.js 영역에 저장하는 것인지 궁금했습니다.

또 "암호화 연산의 실행 위치는 어딘가?" 웹 렌더러 프로세스 영역에서 실행되는 건가, 아니면 Electron 백엔드 Node.js 영역에서 실행된다는 것인가? 그런 의문이 들었습니다. Electron에 대해 많이 알진 못하지만 보안상으로는 Node.js 백엔드 영역에서 실행되는 게 조금 더 안전해 보였습니다.

이런 의문이 들 때 선택을 내려야 합니다. 계획을 승인할 경우 이런 의문스러운 영역들을 클로드 코드가 알아서 판단해 실행하게 됩니다. 그 과정에서 계획이 부정확한 면이 있다면 실패하거나 빙빙 맴돌게 되겠죠. 거절할 경우 컨텍스트 윈도우 사이즈의 제한이 있기 때문에 추가 컨텍스트를 소모하게 됩니다. (물론 클로드 코드가 알아서 잘 구현할 수도 있습니다. 요즘 성능이 많이 올라가서요.)

이런 경우는 아키텍처에 큰 영향을 끼치는 선택이고 변경 비용이 크기 때문에 저는 처음부터 명확하게 하고 들어가는 게 좋다고 생각했습니다. 구랴소 계획을 승인하지 않고 추가로 더 물어보고 계획을 더 구체화하는 단계에 들어갔습니다.

핵심은 플랜 모드를 놓지 말아야 한다는 것입니다. 계획이 완전히 이해되고 내가 원하는 요구사항과 완전히 맞을 때까지요. 클로드 코드가 계획을 구현하고 "완료되었습니다"라고 보고할 때 커밋 내용들을 충분히 검토하고, 생성된 코드들의 복잡도가 관리 가능한 수준으로 떨어질 때까지 플랜 모드를 유지해야 합니다.

브라운필드: 기존 코드베이스에서 작업하기

이제 브라운필드, 즉 기존 코드베이스가 있을 경우에 대해 말씀드리겠습니다. 많은 분들이 기존 코드베이스가 있을 때 성능이 떨어지는 문제를 경험하십니다. 사실 제가 말씀드릴 내용은 특별한 방법이라기보다 기초적인 것입니다.

코드베이스를 먼저 읽게 하라

플랜 모드에서 AI와 계획을 논의하는 단계에서 저는 먼저 AI가 현재 요구사항과 맥락을 잘 이해할 수 있도록 코드베이스를 먼저 읽도록 요구하는 편입니다.

예를 들어 히스토리 탭을 추가한다고 했을 때, "지금 내가 만든 앱에 이러이러한 탭들이 있고 이런 전체적인 구조가 있어. 새로운 기능을 추가하려고 하는데 한번 봐볼래?"라고 물어봅니다. 그러면 AI가 먼저 코드베이스를 간단히 훑어보면서 기능을 구현하기에 앞서 사전 맥락을 자연스럽게 쌓도록 합니다.

그런 다음 "좋아, 그러면 이제 내가 이런 기능을 구현할 거야"라고 점진적으로 플랜 모드에서 내가 원하는 요구사항을 자연스럽게 전달합니다. 그리고 아까 말씀드렸던 것처럼 점점 내가 원하는 요구사항과 완전히 정렬될 때까지 좁혀갑니다.

계획이 승인되면 AI가 구현을 자동으로 수행하고, 검토 단계에서 코드 품질과 요구사항 달성 여부를 평가합니다. 관심사가 잘 분리되었는지, 예를 들어 어떤 기능을 넣었는데 파일을 분리하는 게 더 좋은 상황인데 기존 코드베이스에 그냥 돌아가게만 짤 수도 있잖아요. 이런 부분들이 분리되었는지, 충분히 합리적인 변수명을 썼는지 등을 평가한 후 병합하거나 커밋합니다.

Clean Code가 더욱 중요해진 시대

개발자들도 한 달 전에 개발한 코드를 다시 보면 까먹잖아요. 본인이 작성한 코드도 잊어버리는데 맥락을 모르는 AI에게는 아예 모르는 상황입니다. 결국 제가 작성한 코드도 까먹는 상황이라면 코드를 작성하는 단계부터 나중에 내가 잊어버리고 다시 돌아와도 "아, 이건 이런 맥락으로 작성했구나"라고 이해할 수 있게 가독성 좋도록, 한 번에 읽히도록 작성해야 합니다.

LLM 시대에는 코드 품질이 더욱 중요해졌습니다.

AI가 점차 부정확한 답변을 제공하기 시작한다면, 예를 들어 불필요한 파일을 생성하거나 실제로 구현되지 않은 기능을 완료했다고 잘못 인식하는 경우, 이는 코드베이스의 복잡도가 높아져 기술 부채가 쌓였다는 경고 신호입니다. 이런 경우에는 현재 코드가 과연 충분히 직관적인지, 관심사는 잘 분리되어 있는지 중점적으로 검토하면서 코드를 개선하는 작업이 먼저 선행되어야 합니다.

AI 시대로 넘어오면서 개발은 AI로 플랜을 짜고, 충분히 플랜이 마련되었을 때 그 플랜을 승인해서 AI가 돌아가게 하는 방식으로 돌아갑니다. AI가 정해진 선로를 탈선하지 않도록 충분히 명확한 계획을 짜서 그 계획 단위로 AI 에이전트 실행을 반복 주기로 돌리는 방식이 현재 바이브 코딩에서 중요하다고 생각합니다.

AI가 코드를 알아서 짜주니까 Clean Code가 중요하지 않다고 생각했던 시기가 있었는데, 최근 바이브 코딩을 하면서 깨끗한 코드의 중요성에 대해 오히려 더 강하게 느끼게 되었습니다.

RiSA 앱 소개

만든 앱을 간단히 소개하겠습니다. GitHub 홈페이지에 들어가시면 모든 소스 코드가 공개되어 있습니다. 이 앱을 만들게 된 계기 자체가 암호화를 온라인 배포된 신뢰하기 어려운 웹사이트에서 실행하는 것 자체가 부담되는 상황이었기 때문에 데스크톱 앱으로 만들면서 아예 모든 소스 코드를 공개하기로 했습니다. 다른 분들도 사용하고 싶어 하실 수 있지 않을까 하는 생각도 있었습니다.

웹사이트로 들어가시면 간단하게 데모 사이트가 나옵니다. 데모 사이트에서 체험도 해볼 수 있고 다운로드 링크도 있습니다. 직접 다운로드해서 사용해보실 수도 있고, 원하신다면 코드를 뜯어보시면서 버그를 찾으시거나 이런 기능이 있으면 좋겠다 싶으면 PR을 올려주시는 것도 언제든지 환영합니다.

발표를 들어주셔서 감사합니다.

Q&A

Q. 아까 기존 코드를 수정할 때는 컨텍스트를 먼저 설명하고 코드를 읽게 한다고 말씀하셨는데요. 혹시 그 과정을 좀 더 쉽게 할 수 있는 요령이나, 구체적으로 어떻게 진행하시는지 자세한 설명을 들을 수 있을까요?

기존 코드를 수정할 때 컨텍스트를 어떻게 읽게 하는지, 그 구체적인 방법에 대해 물어보셨는데요. 저는 무엇보다 현재 코드의 맥락을 AI가 먼저 이해하게 만드는 과정이 중요하다고 생각합니다.

갑작스러운 질문이라 답변이 충분할지 모르겠지만, 구체적인 예를 들어 설명해 볼게요. 만약 '키 관리 기능'을 수정한다고 가정해 봅시다. 현재 코드는 RSA 방식처럼 공개키와 개인키, 이렇게 두 개가 한 쌍으로 저장되는 구조로 되어 있다고 칩시다. 그런데 여기에 키를 하나만 저장하는 옵션을 추가하거나, 혹은 그럴 일은 드물겠지만 키 세 개를 한 세트로 저장해야 하는 변경 사항이 생길 수 있잖아요?

이때 저는 바로 수정 코드를 짜달라고 하지 않습니다. 대신 "나는 이런 새로운 기능을 구현하고 싶은데, 일단 지금 있는 키 관리 기능 코드를 먼저 읽어볼래?"라고 요청합니다. 그러면 AI가 코드를 분석하고 현재 구조에 대해 먼저 설명을 해주거든요. '아, 지금은 한 가지 데이터 구조로만 저장하고 있어서 별도의 타입 관리 로직이 없군요' 하는 식으로 AI가 현재 상태를 스스로 파악하게 되는 거죠.

그렇게 맥락이 파악된 상태에서 "그럼 여기서 키 세 개를 저장하려면 구조를 어떻게 바꿔야 할까?"라고 질문을 던지며 아이디어를 제안받습니다. 정리하자면, 대화를 나누면서 AI가 자연스럽게 기존 컨텍스트를 먼저 읽어오도록 유도하는 것이 저의 방식입니다. 명확한 코드를 띄워놓고 설명드린 게 아니라서 답변이 충분했는지 모르겠네요.

Q. 발표에서 설명하신 사이클을 계속 돌리려면 토큰을 효율적으로 사용하는 게 중요할텐데요, 토큰 관리는 어떻게 하시는지 궁금합니다!

토큰 효율 관리 방법은, 이어지는 순서에서 다른 분이 훨씬 더 자세하게 설명해 주실 것 같아서 그 내용을 참고해 주시면 좋을 것 같습니다.

대신 스펙 변경 내역을 어떻게 관리하는지 말씀드리면, 저는 전체적인 구조가 바뀌거나 새로운 모듈이 추가되는 등 큰 변화가 있을 때 클로드를 활용해 기록을 남깁니다. 직접 작성하기보다는 클로드에게 변경 사항을 마크다운(.md) 파일로 정리하게 하거나, 프로젝트의 리드미(README) 파일에 내용을 업데이트하도록 시켜서 관리하는 편입니다.

Q. 이렇게 바이브 코딩으로 개발한 앱은 추후 유지보수가 편할까요? 버그가 있었다고 하셨었는데 코드 가독성 등은 어떤지 궁금합니다.

코드 퀄리티가 유지될 수 있는 정도의 계획의 크기와 명확성을 유지하고, 충분한 퀄리티라고 판단될 때가 아니면 다음 기능으로 넘어가지 않는 편입니다.

Q. 개발하면서 사용하신 MCP는 주로 어떤 게 있을까요?

MCP는 따로 사용하지 않았습니다.

요즘IT 유튜브에서 보기
요즘IT 디스코드에서 발표자료 다운로드 받기