지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

클코나잇 2 웨비나의 첫 번째 발표였던 '코딩 말고 일: Repo를 세컨 브레인으로 1년 굴린 이야기'입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 저는 라인플러스에서 라인 플래닛(LINE Planet)이라는 음성·화상 SDK(Software Development Kit)를 담당하고 있습니다. 오늘 제가 이야기드릴 주제는 'Not Coding, Just Work'입니다.

작년 12월에 있었던 클코나잇 1에서 제가 이런 말을 한 적이 있습니다. "저는 코딩을 하지 않고 클로드 코드를 씁니다"라고 했는데요. 이번 발표에서는 그 사이 여러 가지가 업그레이드된 부분이 있어서, 그 후기를 들려드리고자 합니다.

"기억보다 기록을", 그리고 조직장이 건넨 레포지토리 하나

피터 드러커가 이런 말을 했습니다. “기억보다는 기록을(Memory fades. Write it down.).”

저는 예전부터 프로덕트 매니저로 일하다 보니, 여러 상황을 잘 기억해야 하는 일이 많았습니다. 그래서 기록하는 서비스들을 애용해 왔죠. 그런데 기록하는 것과 기억하는 것은 좀 다릅니다. 지금까지는 클로드 코드를 코딩할 때만 썼는데, 오늘 드리는 이야기는 이걸 '나의 기억력을 보강하기 위한 용도'로 바꿔서 생각해 봤다는 점입니다.

여러분도 1년 전에 썼던 메모, 혹은 몇 개월 전에 썼던 메모를 열어 보면 이걸 어떤 맥락에서 썼는지, 기억하지 못하는 경우가 많을 거예요. 저는 이런 걸 '죽은 문서(Dead Documents)'라고 부릅니다. 그때는 힘이 있던 문서지만, 나중에 열면 맥락을 잃어버리는 문서들이죠. 이 문제를 해소하려고 새로운 메모 도구가 나올 때마다 다 써 봤습니다. 노션, 베어, 옵시디언, 애플 노트, 카카오 메모, 에버노트까지요. 그래도 문서는 계속 죽었습니다.

이걸 보완할 방법이 없을까? 고민하던 차에 저희 조직장이 내부 저장소 하나를 건네주셨습니다. "이걸 쓰면 주간 보고 쓸 때 딸깍만 하면 됩니다."라고요. 그 레포지토리를 받고, 그때부터 그걸 기초로 제 업무 공간을 만들기 시작했습니다.

비개발자도 어렵게 생각하지 말 것

본격적으로 어떻게 만들었는지 말씀드리기 전에, 비개발자 분들을 위해 최소한의 개념만 짚고 가겠습니다. 저처럼 개발자가 아닌 분들도 너무 어렵게 생각하지 마세요. 딱 이 정도만 알고 있으면 돼요.

핵심은 레포지토리, 커밋, 푸시, 풀인데요. 되게 어려운 말처럼 느껴지지만, 쉽게 생각하면 금방 이해할 수 있습니다.

레포지토리(Repository): 그냥 폴더라고 생각하시면 됩니다. 이 폴더 안에 여러 파일을 놓는데, 개발이라면 코드 파일이 될 수도 있고 HTML이나 MD(마크다운) 파일이 될 수도 있죠. 여러 가지 파일이 쌓이는 공간입니다.
커밋(Commit): 저장되는 시점, 즉 '세이브한다'고 보시면 됩니다. 이 시점까지 저장한다는 개념입니다.
푸시(Push): 원격 저장소에 올린다는 개념인데, 쉽게 말해 구글 드라이브에 올린다고 생각하시면 됩니다. 깃(Git)이라는 공간을 구글 드라이브라고 본다면, 거기에 올리는 거죠.
풀(Pull): 반대로 구글 드라이브에 있는 문서를 내 로컬 PC로 다운받는다는 개념입니다.

이 정도만 알면 비엔지니어도 깃이나 깃허브(GitHub)를 가지고 나만의 업무 공간을, 그리고 그 공간을 잘 이해하는 어시스턴트를 쓸 수 있습니다.

처음으로 스킬을 만들다: 복사-붙여넣기가 사라졌다

그 레포지토리를 기점으로, 저는 처음으로 스킬(Skill)을 만들었습니다. 과정은 먼저 개인 PAT(Personal Access Token, 개인 접근 토큰)를 발급받고, 클로드 코드에서 그 PAT로 사내 위키를 직접 읽게 한 다음, 그 안에서 바로 문서를 생성하도록 했습니다.

이 과정이 어떻게 바뀌었는지 좀 더 풀어 말씀드릴게요. 그전에 일하던 방식은 이랬습니다. 사내 지식 저장소가 위키였기 때문에, 위키에서 필요한 문서를 검색하거나 작성하고, AI를 활용하려면 본문을 복사해서 클로드 채팅이나 AI 채팅에 붙여 넣고, 피드백을 받아 나온 결과물을 다시 사람 손으로 위키에 업데이트하는 식이었습니다. 채팅으로 갔다가 다시 위키로 가는 '손 전환'이 여러 번 있었던 거죠.

바뀐 방식에서는 그 전환 과정이 사라졌습니다. 위키를 준비하고 클로드 코드와 토론하면 즉시 위키 문서가 만들어지고, 맥락이 그대로 유지됩니다. 사실 MCP가 사내에 제공되긴 했는데, 그때는 설정이 좀 불편했습니다. 그리고 PAT는 토큰 수명(lifetime)이 더 유연했습니다. 그래서 스킬을 직접 만든 거죠. 한마디로 "클로드 코드 안에서 생각하고, 클로드 코드 안에서 결과물을 냈다"고 보시면 됩니다.

스킬이냐 MCP냐가 아니라, '효능감'이 있는지

작년 12월 첫 번째 클코나잇 발표 때는 스킬을 썼다고 말씀드렸는데요. 당시 MCP도 추천해 달라는 질문을 받았지만, 그 당시엔 잘 쓰지 않았습니다. 그런데 지금은 MCP(Model Context Protocol)를 더 많이 쓰고 있죠. 앞서 말씀드렸듯 예전엔 MCP 설정 난이도가 조금 높았는데, 지금은 많이 낮아졌거든요. 그래서 MCP가 더 편하다고 말씀드리는 겁니다.

주변의 비개발자 분들에게도 처음 AI 세팅을 할 때, MCP가 지원하지 않는 영역이 아니라면 스킬은 나중에 만들어도 된다고 말씀드립니다. 그래도 저는 스킬을 계속 만들고 있긴 합니다. MCP로 안 되는 부분은 스킬로 만들어야 하니까요.

그래서 MCP가 좋냐, 스킬이 좋냐를 따질 필요는 없습니다. 클로드 코드 안에서 쓸 수 있는 도구가 있다면, 그 도구가 나한테 효능감이 있냐 없냐로 보시면 됩니다.

클로드 코드로 어떤 일을 하나요?

저는 코딩이 아니라 '워크', 즉 클로드 코드로 '일'을 한다고 말씀드렸는데, 어떤 일을 하는지 좀 더 구체적으로 말씀드릴게요.

회의 준비부터 회의록 정리까지: 회의 루프

가장 간단한 건 회의 준비가 달라진 겁니다. 예전엔 채팅 UI를 왔다 갔다 하며 업데이트한 내용을 손으로 옮겼습니다. 시간도 많이 들고, 정리하며 다시 쓰는 과정도 번거로웠죠. 구글 미트(Google Meet)이나 줌에서 회의하는 것 자체는 똑같지만, 회의하고 정리하는 과정이 달라졌습니다.

회의 전(BEFORE)에는 위키를 준비하고, 클로드 코드와 토론하며 위키 문서를 만듭니다. 회의(DURING)는 구글 미트로 진행하고요. 회의가 끝나면(AFTER) 구글 드라이브에 저장된 회의록을 MCP로 읽어옵니다. 그다음 후속 정리(FU) 단계에서 전문 용어 오인식을 필터링하고 후속 사항을 다시 정리하죠.

여기서 레포지토리를 만들어 둔 게 도움이 됩니다. 구글 회의록은 STT(Speech-to-Text)를 기반으로 만들어지는데, 한글 인식이 제대로 안 될 때가 많습니다. 주로 전문 용어나 사람 이름이 잘못 인식되죠. 그래서 특정 용어는 이렇게 변환해서 인식해 달라고 미리 일러둡니다. 저의 경우, 라인플러스의 모회사가 LY인데 항상 'Li'로 인식이 돼요. 그래서 클로드의 작업 메모리에 넣어 두고, 'Li'로 인식되는 것들은 'LY'로 바꿔서 인식해 줘"라고 해 두면, 제가 따로 수정할 필요 없이 정리가 됩니다.

그리고 이 모든 과정이 위클리 로그(weekly log)에 자동으로 기록(LOG)됩니다. 그래서 "이번 주 할 일 있어?"라고 물으면, 클로드 코드가 위클리 로그를 기준으로 답을 해 주죠(TASK).

슬랙으로 들어오는 기술 문의 대응: 글로벌 대응 루프

업무할 땐 슬랙을 쓰고 있는데, 해외 법인들이 있다 보니 태국어, 중국어(번체), 영어, 베트남어로 메시지가 옵니다. 저는 외국어를 못하지만, 걱정은 안 합니다. 다만 저에게는 제품 관련 문의나 테크니컬 서포트 문의가 많이 들어와서, 내부 지식을 기반으로 찾아야 하는 경우가 많죠.

그래서 질문이 들어오면 슬랙 스레드 URL을 복사해 클로드 코드에 주입합니다. 자주 묻는 케이스에 대비해, 로컬 RAG(Retrieval-Augmented Generation, 검색 증강 생성)도 만들어 봤어요. 서비스 도메인 지식을 담은 건데, PAT가 있으니 사내 위키를 로컬로 전부 내려받아 내부 로컬 DB로 만든 거죠. 이걸 바탕으로 1차 답변을 생성합니다.

다만 제가 이 서비스를 오래 담당하다 보니, '느낌이 싸한' 답변이 나올 때가 있어요. 그럴 땐 엔지니어에게 크로스체크를 받습니다. 그 답변을 다시 클로드 코드에 주입해 최종 답변 초안을 만들고, 리터치한 다음 발송하죠. 이 과정 역시 위클리 로그에 자동으로 기록됩니다. 그래서 동일하거나 유사한 문의가 다시 와도, 제 기억엔 없더라도 클로드 코드가 이 작업 폴더 안에서 기억하고 있기 때문에, 그 케이스를 꺼내 대응할 수 있습니다.

음성·화상 SDK 시장 리서치 자동화

제가 앞서 음성·화상 SDK를 다룬다고 말씀드렸는데요. 이 분야 시장 리서치를 하면 주로 data.ai나 센서타워(Sensor Tower) 같은 사이트를 봅니다. 지금 저희는 회사에서 센서타워를 제공하고 있어요. 센서타워에서는 예전엔 웹 UI에서 '어떤 앱이 최근에 이 SDK를 탑재했다'는 정보를 검색할 수 있었습니다. 그래서 웹 UI를 검색하고, 그걸 다시 스프레드시트로 옮겨 정리하는 과정을 거쳤죠.

지금은 클로드 코드 안에서 센서타워 API를 기반으로, "이번 주 신규로 음성·화상 SDK가 탑재된 앱들을 위키로 정리해 줘" 이 한마디면 됩니다. 제가 만들어 둔 스킬이 구동되면서 신규로 SDK가 탑재된 앱들이 추출되고, 그 회사 정보, 그리고 그 회사의 의사 결정권자(챔피언) 연락처 같은 것들을 구글 검색 등으로 찾아, 위키 안에 자동으로 넣어 주는 결과물을 줍니다.

심플하면서도 강력해진 부분이 많습니다. 업무 시간이 절약된 것도 있지만, 결과물 자체가 저에게 효용이 좋았고, 유관 부서들과 커뮤니케이션할 때 도움이 되는 자료를 많이 인풋할 수 있었다는 점을 말씀드리고 싶습니다.

코딩을 안 하고도 사내 토큰 사용량 상위권에 오르다

그러다 보니 사내에서 AI 토큰 사용량 순위를 조사한 적이 있는데요. 임직원이 수천 명인데, 제가 그 순위에서 15위 안에 들었습니다. 전 비개발자고, 코딩을 안 하고도 토큰을 이만큼 쓸 수 있구나 싶었죠. 물론 토큰을 많이 쓰는 게 일을 잘한다는 뜻은 아닙니다. 단지 코딩이 아닌 곳에도 이만큼의 토큰을 쓰면서 할 수 있구나 정도로 생각해 주시면 좋겠습니다.

예상 못한 결과: 성공은 다시 쓰고, 실패는 자산이 된다

앞서 세 가지 사례를 말씀드렸는데, 저는 대부분의 일을 클로드 코드로 시작해서 클로드 코드로 끝냅니다. 그러다 보니 예상하지 못한 결과도 나왔습니다.

첫째, 비개발자 PM인 제가 npm 패키지를 만들었습니다. 음성·화상 SDK는 프론트가 없는 서비스라, 엔지니어 분들이 이 서비스를 이해하는 데 기술 문서가 제일 중요합니다. 그런데 요새는 사람이 기술 문서를 잘 안 보고 AI가 보다 보니, AI에게 어떻게 잘 주입할까 고민하게 됐죠. 그때 MCP 서버를 한참 공부하던 시기였는데, 제가 서버를 만들 순 없으니 npm 패키지로 배포하는 방법을 택해 본 겁니다.

둘째, 지금 보고 계신 이 발표 자료도 클로드 코드로 만들었습니다. 이 슬라이드까지요. 클로드 코드의 PPTX 스킬을 그대로 쓴 건 아니고, 스킬을 '깎는다'고 하죠. 커스터마이즈를 많이 했습니다.

셋째, 실패 경험이 자산이 됐습니다. 실패하면 그 내용을 Git Issue로 쌓아 둡니다. 그리고 모델이 업그레이드되면 그 이슈를 다시 꺼내 봅니다. 그때는 안 됐던 게 지금은 되기도 하니까요. 그래서 내부 폴더 안에 성공과 실패에 대한 지식과 결과물을 계속 쌓는 과정을 반복했습니다.

이 이야기는 결국 안드레이 카파시(Andrej Karpathy)가 말한 ‘LLM 위키’ 개념과도 연결됩니다. 위키는 지속적으로 축적되는 산출물이고, 상호 참조와 모순이 이미 정리되어 있다는 거죠. 그리고 이제 문서는 사람이 아니라 LLM이 읽습니다. 저는 문서를 읽는다기보다, 지금 당장 해야 할 급한 일을 하는 거고, AI가 그 일을 도와주면서 기록을 남기고, 결국 그 기록이 제가 일을 더 잘하도록 도와주는 거라고 봅니다. 그래서 카파시가 이야기한 위키 개념을 더 보강해 나가는 과정에 있습니다.

오늘 바로 시작하는 세 단계

이렇게 말씀드리면 '내가 해볼 수 있을까? 내 일도 이렇게 할 수 있을까?' 하는 생각이 들 수 있습니다. 현대그룹 정주영 회장의 "해봤어?"라는 말처럼, 해본 것과 해보지 않은 것은 큰 차이가 있다고 생각합니다. 그래서 꼭 한번 해보시길 추천드립니다.

어떻게 해야 할지 모르겠다는 분들을 위해, 환경을 그대로 카피하는 방법을 세 단계로 정리했습니다.

클로드 코드를 엽니다. 채팅창 위 폴더 선택 메뉴에서 새 폴더(llm-wiki) 하나를 지정합니다.
이 링크로 들어가 주소를 붙여넣습니다.
한 마디만 던집니다. "나도 이거 세팅해줘."

이 링크를 넣으면 제가 만들어 둔 세컨 브레인 레포지토리의 스켈레톤을 그대로 카피해 옵니다. 시작되면 첫 질문이 메모리와 위클리 로그를 만들면서, 그 안에서 작업 기록이 쌓여가는 구조라고 보시면 됩니다.

제가 일하는 방식: VS Code, 바이패스 퍼미션, 경로 주입

저는 VS Code를 이용합니다. 많은 분들이 터미널로 쓰거나 CLI 도구 등 다양한 도구를 쓰시더라고요. 제가 VS Code를 쓴다고 하면 "왜 쓰세요?"라는 질문을 많이 주셔서 말씀드리면, 저는 터미널이 익숙하지 않습니다. 엔지니어가 아니라서 그런지, 좌측에 폴더가 보이는 게 굉장히 심리적 안정감을 주더라고요. 뭐가 추가됐고, 삭제됐고, 업데이트됐는지 보이는 그 안정감이 도움이 됩니다.

VS Code 작업 화면: 좌측 파일 트리에서 추가·삭제·수정 내역이 보이는 구조

그리고 클로드 코드 익스텐션을 깔면, 터미널을 여러 개 띄워 멀티 세션을 만들 수도 있지만, VS Code에서 익스텐션을 쓰면 그 세션을 계속 반복해서 사용할 수 있습니다. 물론 반복 사용은 여러 번 압축하게 되면 안 좋은 점도 있지만, 그 정도로 쓰는 것보다 효능감이 더 높기 때문인데요. 압축을 자주 하더라도 주제별 세션으로 분기해서 필요한 업무에 맞춰 세션(탭)을 바꿔 가며, 쓰는 게 더 편리했습니다.

또 제가 코딩하는 게 적다 보니 퍼미션 체크하는 게 되게 귀찮습니다. 그래서 물론 코딩을 하실 때는 조심해서 쓰셔야겠지만, 저는 바이패스 퍼미션(bypass permissions)을 한 번만 설정해 두고 씁니다. 물론 코딩할 때는 종종 오토 모드(auto mode)나 다른 모드를 쓰고요.

마지막으로 경로를 써서 주입하는 걸 자주 합니다. 로컬에 파일이 있으면 그 파일을 어태치해서 하는 경우도 있지만, 폴더를 통째로 다뤄야 할 경우엔 경로를 보내는 게 효율적이더라고요. 그래서 제 작업 레포지토리에서는 경로로 주입해서 다른 레포지토리에 있는 걸 핸들링하는 식으로 쓰고 있습니다. 이렇게 해도 일하는 데 큰 무리가 없었는데, '이런 식으로 일을 하는구나' 정도로 참고하시면 좋을 것 같습니다.

결국 에이전트는 '조련'하는 것입니다

많은 분들이 스킬을 깎는다, 에이전트를 깎는다고 표현하는데, 저는 '조련한다'고 생각합니다. 에이전트가 시간이 지날수록, 내 업무 패턴과 스타일에 맞춰 조련되고 있다고 보시면 됩니다.

대신 에이전트는 항상 실수할 수 있습니다. 뭔가 이상하다 싶으면, 먼저 제가 내린 지침을 따랐는지 확인합니다. 헛소리를 할 때도 있는데, 헛소리하는 것까지는 이해할 수 있죠. 다만 그럴 땐 왜 헛소리를 했는지 분석하고 재발 방지 조치를 합니다. 저희가 장애가 나면 재발 방지 대책을 세우잖아요. 그것도 일이라고 생각합니다.

다른 분들의 발표를 보면서 따라 할 부분이 많겠지만, 참고는 해도 일하는 사람마다 스타일이 다 다릅니다. 그래서 결국 나만의 지침을 만들어가는 게 맞습니다. 저도 작년 11월부터 지금까지 지침을 계속 추가하고 수정해 왔습니다. 이렇게 다마고치처럼 조련하다 보면, 같은 클로드 코드라도 나한테 최적화된, 든든한 조력자를 만나실 수 있을 겁니다.

▶ 발표 영상 유튜브에서 보기