2025-09-13 JDC Meetup

스테이지 세션 - 권한비님 - 성장하고 싶다는 착각

부제; 정글 이후 느낌이 아닌 시스템으로 성장하는 법

왜 성장하고 싶어요? 에 대한 질문이 들어옴. 저의 개인적인 성장과 조직의 성장은 무슨 관계인가?

"성장하고싶다"는 어떻게 보면 핑계가 될 수도 있음. 회사가 맘에 안들거나 같이 일하는 사람이 맘에 안들거나 하는 둥. 나한테 닥친 현상을 "탈출"하고 싶다는 핑계일 수도 있음. 우리가 해왔던 모든 활동은 단발적인 이벤트이고 회사가 원하는 건 시스템임.

현업에서는 복합한 기술문제, 동력을 스스로 만들고 비즈니스 중요도에서 내 의견이 좌절될 수도 있는것이 현실. 따라서, 성장에 대한 원칙을 세워봤다.

  1. 구체적으로 정의 가능
  2. 객관적으로 측정할 수 있어야 한다
  3. 시스템으로 개선할 수 있어야 한다.

시스템? 계획표, 일간 월간 주간 투두리스트가 아니다.

  1. 피드백루프가 있다. 실패 패턴을 분석하고 다음 PR 전에 체크리스트를 통해 미연에 방지할 수 있어야함. 결과가 다시 입력이 되어 다음 행동을 자동으로 교정하는 구조.
  2. 복리 구조: 하나를 배우면 둘이 쉬워지는 구조.
  3. 같은 실수는 두 번 안한다. 최소한의 에너지로 반복적인 의사결정과 실수를 미연에 방지.

시스템이 없으면 하게되는 행동: 일단 책을 읽자. 일단 강의를 듣자. 일단 스터디를 하자. 그러면 어떻게든 해결되겠지. ⇒ 열심히는 하는데 실무적으로 도움이 되지는 못한다. 이것은 이벤트 중심의 대응을 했기 때문이다.

HOW? 성장을 구체적으로 정의. e.g.) 한 번에 LGTM을 받는 PR을 올려보자. 예상 하위성장목표치를 쪼개어 다음과 같이 정의할 수 있다: 1. 셀프 리뷰 체크리스트 2. PR 설명에 의도와 이유를 작성하는 비율을 갯수를 센다. 3. PR 요청부터 승인까지 걸리는 시간을 계산한다.

가짜성장과 진짜성장을 비교해보자면

스테이지 세션 - 신민기님 - 초기 인디게임팀을 위한 제로 예산 전시회 참가 전략

정글 게임랩2기 출신.

게임 하츠카 시원하게 말아먹고 스페이스 리볼버, 본투게더 게임을 들고 많은 현장을 뛰어봤다. 어떤 이득을 취할 수 있응ㄹ지 고밍중. 인디게임 팀이라면 이 행사 저행사 다 다녀보는게 좋다.

WHY? 매니아 유저층들이 찾아온다는 점. 플레이테스트 굉장히 싸게 먹힘. 비즈니스적인 부분에 대한 매칭을 할 수 있음. 퍼블리셔, 아웃소싱 등등 "이 게임을 팔 수 있을 건지"에 대해 간과하고 있던 부분. 마지막으로 "업적작"을 계속 쌓아야 함. 무료로 부스를 지원한다는 건 심사를 통해서 선정하기도 하고, 최소한의 완성도를 보장한다는 의미이기도 함.

부스선정의 가장 중요한 건 완성도 <<<<<<<<< 업적 이다. 이전에 여타 지원사업들을 따냈을 경우 심사위원들이 상대적으로 그걸 통해서 이미 증명된 게임들을 선별하는 경향이 있다고도 한다.

스테이지 세션 - 정현우님 - 바이브 코딩이 아닌 증강 코딩으로 1인 창업 개발기

부제; AI를 잘 쓰기위해 고군분투하며 깨달은 결과물

AI 발전으로 한 명이 여러 Role을 수행할 수 있다. 개인적인 창업을 시도하고 있음.

창업아이템이라는 건 PayPoint를 찾고 돈을 벌 수 있는 무엇이든 될 수 있다.

개발자가 아니라 창업자가 되어야 한다. AI를 적극 활용해봐야 한다. ---> Vibe Coding; 항상 모두 수락을 누르고 변경점을 읽지 않고 될때까지 버튼을 누른다.

BUT. 속도만 빠르지 수정할라니까 (기능, 디자인) 어려워짐. ---> 바이브코딩은 일회용 코딩이구나. 기술부채 해결이 쉽지 않더라.

AUGMENTED CODING (증강 코딩): 켄트벡 아조씨 (TDD 창시자)가 제시한 개념. 기능의 동작을 넘어 퀄리티, 구조, 유지보수, 협업성까지 AI한테 작성하게 만들어라.

  1. Spec Driven Development: 모호한 형태의 요청이 아닌, PRD (Production Requirement Document), TRD(Tech Requirement Document)와 태스크 목록을 함께 만들어서 스텝 바이 스텝으로 해야한다. 명세(spec)을 작성하고 이를 구현하기 위한 기술적 플랜을 작성하고 아주 작은 단위의 태스크로 쪼개고 새로운 스펙을 작성하는 것을 반복.
    1. 기획적인 용어들: PRD, TRD, DD(Design Document) → Epic, Story, Task 순으로
    2. 구닥다리로 취급받았던 워터폴 방식이 다시 돌아왔다. Epic, Story, Task 모두 마크다운으로 작성하고 (ai 활용) 그것을 묶어서 깃 이슈로 만들고 깃 워크트리로 만든 후 병렬작업한다.
    3. 문서 작성방법은 LLM한테 직접 할 수도 있고, 프롬프트 템플릿을 가져다 쓸 수도 있고, AWS Kiro라는 IDE가 있고, 깃허브에서도 Spec Kit가 있음.
  2. Rule Growing Development: 코딩 컨벤션(Rule) 기반으로 작업을 의뢰, 리뷰하는 개발 방법
    1. 지속가능한 코드가 되기 위해서는 AI가 쏟아내는 코드의 일관성이 중요해짐.
    2. 코드 퀄리티를 정의한 문서 === "Coding Convention"
    3. 클로드코드의 경우, /docs/rules에 주요 역할들 (reserchers, developers, reviewers, tests)에 대한 sub-agent를 생성, 피드백 루프를 반복한다.

Q. 증강코딩만으로 걸린 기간은? 생산성 향상을 수치적으로 어떻게 되었나?

A. 이미 한 번 MVP를 엎어봤기 때문에 기존보다는 빠르다. 서비스 출시일을 기준으로 생산성 향상은 AI 없을때 보다 (4달 반) 두달 반 정도로 두배정도 향상된 것 같다. 이 작업은 하지만, 복리로 돌아올 것 같다.

Q. 클로드코드를 돈을 많이 내는 모습을 봤다. 규칙을 많이 낼 수록 토큰소비가 빨라지던데 어떻게 아껴야 하는가?

A. 삽질도 많이하고 돈도 많이 쓴다. 월 100$짜리 플랜을 쓰고있지만 아깝지 않다고 느낀다.

Q. 주니어급 개발실력으로 AI를 자주 활용할 때 컨텍스트가 길어질 때는 말을 못알아먹게되는데 이를 위한 전략은?

A. 문서화가 이래서 중요하다. 너무 짧아도 너무 길어도 좋지 않다. 문서도 깃에 올려서 쓰고있음.

Q. AI를 쓰다보면 꼬리질문이 길어진다. 하나의 채팅을 길게하면 내 의중을 반영하게되더라. "너가 생각하는게 맞아" 이런 아첨모드를 어떻게 빠져나갈 수 있는가?

A. 웹 검색을 시킨다던지, MCP를 붙여서 외부의 객관적인 근거를 접근하도록 만든다거나, 아예 새로운 컨텍스트를 시작하는 것도 방법이고. 헤드리스 모드를 쓰게하면 제미나이와 클로드끼리 서로 대화하도록 만들 수도 있다.

Q. 기획, UX, UI 디자인은?

A. 기획의 경우, 내 문제를 골랐고, 디테일한 기획의 경우는 해외 서비스를 많이 참고했다.

Q. 데이터셋을 준비하는것이 창업의 핵심이라고 생각하는데, 준비를 어디서 가져오는지 궁금하다.

A. 객관적인 CS 지식 + 대답의 일관성 이렇게 주관적인 평가기준은 패스하고, 일단 하드스킬에 집중하고자 한다.

Q. 가중치를 이용한 평가점을 이용한 데이터셋?

A. 테스트 검증이 필요한 부분이라고 생각한다.