DEVOCEAN

들어가며

오늘은, 9월 18일에 진행된 Dev Ground 2025 행사에서 보고 들은 내용들을 공유해볼까 합니다.

행사는 홍대에서 진행되었고 생각보다 많은 사람들이 와서 모든 세션이 만석이었습니다~!

출판사에서 하는 세미나 답게 재고 처리하는 느낌을 조금 받긴 했지만.. 랜덤도서증정 이벤트도 있었고요.

요래요래 간식도 주고요

점심으로 맛있는 햄버거도 받았습니다. 냠냠.

내가 들은 세션들

저는 AI 를 사용해서 좀 더 쉽고 빠르게 코딩하는 것에 관심이 많습니다.

그러다보니 거의 모든 세션을 Vibe Coding 트랙에서 들었습니다.

외부 회의를 하느라 놓친 세션도 몇개 있습니다만 ㅠㅠ

그래도 꽤 많은 재미있는 이야기를 들었고

'이건 누구나 알면 좋겠고, 내 업무에도 적용해야겠다' 싶은 것들만 공유드립니다.

특히 키노트의 하용호님 강연이 크게 도움이 되었고, 이 포스팅의 많은 내용이 이 강연에서 거의 대부분인 듯 나왔습니다.

누구나 알면 좋겠다는 생각이 들었던 이야기들

Claude Code 와 Cursor 같은 툴들은 어떻게 내 코드를 참고할까?

• 하용호 님의 장표가 너무 설명을 잘해놓아서 따로 설명 안합니다..

• Claude 만으로도 Cursor 보다 나은 성능을 보여줄 수 있다는 사기를 심지어 핫글까지 간 친 적이 있는데요. (https://devocean.sk.com/blog/techBoardDetail.do?ID=167513)

• 심각한 오류가 있었음을 알게되었고, 이 자리를 빌어 사과드립니다 ㅠㅠ

  
  

LLM은 대화가 길어지면 바보가 된다

• 다들 아시다시피 LLM은 1개의 대화세션이 길어지면 바보가 되곤 합니다.

• Chroma DB 에서 연구한 결과에 따르면 길어질수록 바보가 되고, 이 문제는 여전히 해결되지 않고 있습니다.

  
  

AI로 Gacha Coding 을 하면 내일의 우리가 힘들다.

• 올해 진행한 과제 중 하나는 3개월동안 기획 / 디자인 / 개발이 모두 진행되었습니다.

• 모든 이슈는 빠르게 처리되어야 했고 LLM에게 "고쳐줘. 모르겠고 아무튼 고쳐줘." 라고 지시하니 1-2분 후 바로 작동하는 경험을 여러번 했습니다.

• 하지만 그 다음에 같은 코드를 수정해야 할 일이 생겼을 때는 아예 코드를 이해하기 어려운 현상이 발생했습니다.

• 많은 개발자들이 LLM을 통해서 만든 코드는 Prototyping 에는 적합하지만 프로덕트 레벨에서는 적용하기 어렵다는 말들을 합니다.

• 실제로 이날 강연에서도 비슷한 이야기를 하고, 직접 수정 금지라는 룰을 만들었다는 이야기도 있었습니다.

  
  

  
  

그럼 Claude Code (이하 CC)를 어떻게 써야 하는데?

컨벤션이나 지켜야 할 팀의 관습이 있다면, 미리 지침으로 제공하자.

• CLAUDE.md 파일에 공통 지침을 만들어 놓으면, 매번 이야기하지 않아도, 알아서 참고합니다.

  • CC가 꼭 지켰으면 하는 것들

  • 팀 규칙이나 개인 선호사항

  • 자주 사용하는 명령어 (예: npm run lint, npm run typecheck)

  • 코드 스타일 가이드

  • 아키텍처 패턴

    
    

자주 해야 하는 작업은 Commands 로 만들자.

• 반복해서 수행해야 하는 일은 미리 Commands 로 만들어놓고 파라미터만 넘겨서 작업하게 할 수 있습니다.

  • 공식 가이드: https://www.anthropic.com/engineering/claude-code-best-practices

  • 사용사례

    • 팀장으로서, jira 보드를 읽고 병목을 파악하고 내가 도와줘야될 일을 찾는다.

    • github 이슈를 읽고 관련 코드베이스를 읽어서 코딩하고 커밋, 푸쉬까지

      
      

Context 관리를 잘하자.

• LLM은 대화가 길어지면 바보가 됩니다.

• 대화가 길어져서 바보가 되는 느낌이 조금이라도 들면 세이브 버튼을 누르고, 세션을 다시 시작하는 방식으로 문제를 해결할 수 있습니다.

계획은 길게. 코딩은 짧게

• 앞에서 발생한 AI의 코드를 이해하지 못하게 되는 문제는, 구조적인 설계과정 없이 바로 수정을 시키는 경우 자주 발생하게 됩니다.

  • 우리 팀이 쓰는 패턴과는 다른 패턴으로 코드를 만들게 되고

  • 내 프로젝트의 같은 역할을 하는 코드를 사용하지 않고 또 만들게 되고

  • 아무튼 이해하기 어렵게 됩니다.

• 그래서 나온 아래의 방법론은 다음과 같습니다.

  • 30분 이상 충분히 설계에 대한 대화를 나눕니다.

  • 중간중간 현재까지의 대화내용을 md 파일 형태로 저장하게 시킵니다.

  • 모든 설계가 정리되면 md 파일을 토대로 코딩을 시킵니다.

• 이렇게 하면 이해하지 못하는 코드의 함정으로부터 조금은 자유로워 질 수 있습니다.

대답이 너무 느리다고? 여러명의 AI와 작업하자

• CC 나 Cursor 같은 툴들은 여러개의 대화창을 열 수가 있습니다.

• LLM이 대답을 만드는 너무 길어서 지루하고 기다리기 힘들다면, 소스코드가 겹치지 않는 다른 대화를 여러 개의 창에서 동시에 진행해 보세요!

  • 답변을 생성하는 모델은 내 PC에 없기 때문에 CC는 동시에 대화할 수 있습니다.

  • 제 경우 뇌의 피지컬 이슈로 2개까지는 어떻게 진행해볼만 하지만, 3개 이상 진행은 거의 불가능했습니다 ㅠ

  • 이 주제의 발표를 진행하신 연사는, 발표를 시작할 때 홈페이지 제작을 LLM에게 시켜놓고 3-4번의 프롬프팅 끝에 발표가 끝나는 시점에 완성된 홈페이지를 보여주는 기적을 보여줬습니다.

    
    

육하원칙을 잘 지키고, 존댓말로 질의하자.

• 배경설명과, 기대효과를 잘 적어야 원하는 결과가 나온다고 합니다.

• 한국어는 주어가 생략되는 경우가 많기 때문에, 실제 의도와 다르게 이해하기가 쉽다고 합니다.

• 존댓말로 완결성있게 질의할 경우, LLM 이 비슷한 어투의 고급정보를 통해서 답변을 생성한다는 연구결과가 있다고 합니다.

마치며

• 발전속도가 너무 빨라서, 이렇게 별도로 시간을 내서 배우지 않으면 따라가기가 점점 어려워지는 느낌이 듭니다.

• 몇 시간 안되는 세미나였는데, 제 업무를 꽤 많이 바꿔놓을 정도로 임팩트가 있는 강의들이었습니다.

• 그럼 모두 행복코딩 하세요 😎