[4주차 크루 미션 - 최종 발표 & 회고] ellipsis 미션 제출합니다.

[CommitTheKermit]

어느덧 마지막 PR이네요. 고생많으셨습니다~

4주차 보고서(수정)

A. 처음 의도 vs 결과

• 1주차에 정의한 문제와 4주 후의 문제 (차이가 있다면 이유)
  • 1주차
    • 플러피, 1주차에 정의한 문제 → 사람들은 SNS에 부담감을 느낀다?
    • 키버디, 1주차에 정의한 문제 → 키보드를 찾는데 사용자들이 불편함을 느낀다.
  • 4주차
    • 키버디, 4주 후의 문제(해결 대상) → 키보드를 구매하려고 할 때 알아야 할 정보가 너무 많고 여기저기 흩어져 있어, 원하는 키보드를 찾는 과정이 복잡하다.
    • 키버디, 4주 후의 문제(열린 의문) → 그렇다면 자연어 입력이 그 복잡함을 줄여주는, 사용자에게 편한 방법일까?
  • 이유
    • 처음에는 문제 정의를 너무 가볍게 생각했다. 인터뷰 결과 우리가 세운 가설은 깨졌으며, 우리가 생각한 문제는 사용자들이 문제라고 인식하지 않았다. 그래서 아이디어를 피봇하였다.
    • 사용자들은 본인이 원하는 키보드를 찾는데 불편함을 겪었고 우리가 세운 가설과 문제를 지지받을 수 있었다.
    • 그러나, 과연 키보드를 찾는데 불편함을 느끼는 사용자들이 내가 원하는 키보드를 설명하는 자연어를 입력하는 게 쉬울까? 하는 의문이 들었고 실제로 피드백 사항 중에 있었다.
    • 다만 우리는 미리 제시된 키보드 조건들을 선택지로 제공하여 자연어 입력에 대한 불편함을 줄이려고 하였다.
• 1주차 MVP 범위와 실제 만든 것 (차이가 있다면 이유)
  • 1주차 MVP 범위(사실2주차)
    • 자연어 설명
    • 선택지 제공
    • 추천 결과 페이지
  • 실제 만든 것
    • 자연어 설명
    • 선택지 제공
      • 선택지에 있는 키워드들이 어렵다는 피드백이 많아서, 선택지가 뭘 의미하는 지, 어떠한 특징을 가지고 있는지를 영상, 인포그래픽으로 제공하여 사용자의 이해를 높이고자 하였습니다.
    • 추천 결과 페이지

      • 쉬운 용어 풀이 키워드

        • 전문적인 용어가 키워드화 되어 각 키보드마다 태그 형식으로 달려있지만 이러한 용어를 좀 더 쉽게 풀이해둠

        “내가 이 서비스를 이용해서 키보드를 추천받고 구매하여 막상 받아보았을 때 내가 생각하던 키보드가 아닐 경우 서비스에 대한 신뢰도와 이용률이 적어질 것”이라는 피드백을 반영하여 좀 더 쉬운 말로 용어 키워드를 풀이하여 설명하도록 함

      • 각 키보드별 주의할 사항

        • 각 추천 결과 키보드마다 확인할 점을 제공해주어 구매하기 전에 좀 더 실패할 확률을 줄여주고 사용자가 쉽게 놓칠만한 주의사항들을 알 수 있도록 한 번 더 필터링 해준다

        “내가 이 서비스를 이용해서 키보드를 추천받고 구매하여 막상 받아보았을 때 내가 생각하던 키보드가 아닐 경우 서비스에 대한 신뢰도와 이용률이 적어질 것”이라는 피드백을 반영하여 키보드를 구매하기 전 쉽게 놓칠만한 주의사항들을 포함시킴

      • 접점 방식, 스위치 설계에 따른 키감, 소음 레벨미터

        초기엔 태그 chip을 통한 단어 중심 정보로 제작하려 했으나, 두 값 모두 “강도”와 관련된 필드여서 단어만으로 사용자가 어떤 느낌인지 파악하는데 한계가 있을 것이라고 판단해 레벨미터를 사용해 조금 더 시각적인 정보를 제공하고자 구현 방향을 변경함

      • 해당 키보드의 유튜브 영상 링크

        • Youtube Data API v3 콜을 통해 영상 링크 수집

        타건음을 태그 chip을 사용해 의서어로 제공하려 했으나, 소리의 경우 사람마다 다르게 받아들일 수 있겠다고 판단해 억지로 의성어를 제공하는 것 보단 동영상을 통해 사용자가 직접 판단하는 것이 더 좋겠다고 판단해 의성어 chip을 제거하고 영상 링크를 제공

    • 구매 링크 & 사용자 피드백
      • 사용자가 우리가 제공하는 추천결과를 실제로 마음에 들어하는지를 정량적으로 분석하기 어려워서, 구매 링크와 사용자 피드백을 통하여 검증기준으로 추가하려고 하였습니다.
• 1주차에 고른 기술, 다시 한다면 같은 선택일지
  • 제미나이 캔버스
    • 종합 결론: 제미나이 캔버스는 최소한의 디자인·인터랙션을 갖춘 프로토타입을 빠르게 만들고 링크만으로 공유할 수 있다는 장점이 있어, “빠른 프로토타이핑” 관점만 보면 다시 선택할 여지도 있는 기술입니다.
    • 다만 이후 기능이 추가·확장되면서 많은 UI를 덧붙여야 했고, 그 과정에서 클로드 디자인이나 Pencil 같은 도구를 더 많이 활용했습니다. 어차피 Pencil로 UI를 다시 그릴 거라면 제미나이 캔버스 결과물을 포팅할 필요 없이 처음부터 Pencil로 시작하는 편이 낫다고 판단했습니다.
    • 따라서 “다시 한다면 제미나이 캔버스는 쓰지 않고 처음부터 Pencil로 UI를 만들고 진행”하는 쪽으로 의견을 모았습니다.
  • React + React DOM
    • 제미나이 캔버스 결과가 React + Tailwind + lucide-react로 만든 UI 프로토타입으로 구성되었습니다. 이 구조를 가장 잘 흡수할 수 있는 Vite + React + TS + Tailwind 구조로 구현하였습니다.
  • 파이어베이스
    • 서버 운영 부담을 최소화하기 위해서 사용하려 하였습니다.
  • 수파베이스
    • 파이어베이스와 제공하는 기능이 크게 다르지 않고, 서버 운영 비용을 최소화할 수 있어 선택하였습니다.
• 고려했다 안 쓴 선택지와 뺀 이유
  • 엑셀
    • MVP 제작 시 사용자가 Excel 프로그램을 보유해야 하고, 구글 스프레드시트는 작동이 부드럽지 않아 제외 (MVP 플랫폼 후보)
  • 제미나이 캔버스(플랫폼/지속 사용 관점)
    • 코드 베이스를 가진 계정에서만 작업해야 해 팀원 기능 분담이 어렵고, 컨텍스트 확장 한계가 있어 프로토타입 코드만 추출한 뒤 지속 사용은 중단
  • 파이어베이스 사용 → 수파베이스 사용
    • 파이어베이스에서는 Blaze 요금제로 바꿨을 때 서버 운영 비용이 발생하나, 수파베이스에서는 서버 운영 비용이 발생하지 않아 서버 운영 비용을 최소화할 수 있어 변경하였습니다.
  • 공통 하네싱
    • 코드 컨벤션, 깃 컨벤션, PR 포맷 컨벤션, 브랜치 컨벤션 등등 공통으로 작업할 내용에 하네싱이 필요했는데 이 부분에서 놓친 점이 많아, 사람과 AI에 불필요한 혼동을 줬다고 생각합니다.

B. 가설 검증 종합

• 4주간 세운 가설과 결과 (지지 / 반박 / 불명확)
  • 플러피
    • 상대 상태가 궁금하지만 메시지 보내기가 부담돼 확인을 포기한 경험이 있다 → 반박
    • 공개 범위 때문에 게시를 망설이거나 줄인 경험이 있다 → 불명확
  • 키버디 (정성 요약)
    • 사용자는 키보드 구매 과정에서 높은 진입장벽과 선택 피로를 느낀다. → 지지
    • 키보드는 ‘선택형 취향 제품’으로 인식된다. → 지지이나, 너무 당연한 가설
    • 사용자는 ‘간단한 선택 → 맞춤 추천’ 형태의 가이드를 원한다. → 지지이나, 너무 당연한 가설
  • 키버디 (인터뷰 정량 결과, 29명 기준)
    1. 노트북에 별도의 키보드를 연결하여 사용하고 있다. → 부분 지지 (59%, 17/29명 “네”)
    2. 키보드는 더 이상 필수 입력장치가 아닌, 필요에 따라 구매하는 선택형 제품이라고 인식한다. → 강력 지지 (83%, 24/29명 “네”)
    3. 키보드 구매 시 입력이라는 목적성보다 취향을 따진다. → 강력 지지 (90%, 26/29명 “네”)
    4. 다양한 옵션으로 인해 부담을 느낀다. → 지지 (69%, 20/29명 “어렵다 / 너무 어렵다”)
    5. 키보드 선택 과정에서 정보 탐색(검색·리뷰·유튜브)에 많은 시간을 소비한다. → 지지 (66%, 19/29명 “오래 걸렸어요”)
    6. 자신의 사용 환경(사무실·집·게임 등)에 맞는 키보드를 명확히 추천받고 싶어 한다. → 강력 지지 (86%, 25/29명 “네”)
    7. 구매 과정이 복잡하여 추천 서비스 또는 가이드의 필요성을 느낀다. → 지지 (72%, 21/29명 “네”)
• 가장 크게 깨진 가설 1개와 받아들인 방식
  • 플러피에서 다뤘던 가설들이 많이 깨졌습니다.
    • 상대 상태가 궁금하지만 메시지 보내기가 부담돼 확인을 포기한 경험이 있다.
    • 위 가설이 저희는 문제라고 생각했는데, 상태가 궁금할 정도의 관계라면 메세지 보내는게 그렇게 부담스럽지 않다고 답변하신 의견들이 많았습니다.
    • 사용자들이 실제로 문제라고 생각하지도 않는 부분을 해결할 필요가 있을까라는 의문이 들어 아이디어를 피봇하였습니다.
• 중간 공유에서 검증하기로 한 다음 1가지와 그 결과
  • 다음 과제: “추천 결과의 품질 고도화”
  • 초기 추천은 사용자의 자연어 입력과 키보드 DB를 그대로 LLM에 전달해 결과를 받는 구조라, 사용자의 조건이 안정적으로 반영되지 않았습니다. (예: 조용한 키보드 요청에 시끄러운 축 추천, RGB 불필요에 RGB 백라이트 키보드 추천)
  • 개선: 자연어를 바로 추천에 연결하지 않고, 먼저 LLM으로 사용자 의도를 태그로 추출한 뒤 그 태그로 키보드 DB를 검색하도록 변경. (예: “사무실에서 쓸 조용한 키보드” → ‘사무용’,’조용함’ 태그 / “백라이트는 없어도 된다” → ‘백라이트 없음’ 하드 제약)
  • 결과: 추천이 이전보다 의도에 맞게 개선됨. 다만 정성적 판단에 가까워, 추천 정확도를 수치화하기 위해 “Rubric” 방식으로 정량 검증을 추가로 진행.
• 끝까지 검증 못 한 가설이 있다면 그 사실 그대로
  • 자연어 입력이 사용자에게 편한 방법일까?
  • 자연어 입력을 통하여 정말로 사용자의 취향을 반영한 키보드가 추천될까?

[CommitTheKermit]

Keep

• 자연어 태그 추출
• 에이전트 코딩 - knowledge-loop, 지식 저장소
• AI 협업 의사 결정
• CLAUDE.md 심볼릭 링크, 하나의 프로젝트 메모리 파일 들고가기
• 주제 선정과정에서 잘못되었다고 생각이 들 때 주제를 피봇한 것
  • 실수 내지 잘못을 인정하고 돌아보며 어떻게할지 생각해본 시간이라고 느껴져 뜻 깊었다 생각함
  • 주제를 변경하게 되면 시간도 부족하고 그 만큼 힘들것이 예상되는 상황에서도 팀원 모두가 더 좋은 결과를 위해 노력해주었다는 점이 좋았다고 생각함
• 각자 해야할 일을 목록화
  • 각자가 달성해야할 목표를 글로 작성해 목록화 해놓아 어떤 작업을 해야할지 빠르게 결정할 수 있었음
• 우리가 서로 기획을 진행해나가면서 각자의 생각이 다를 수 있는데 이를 대면 회의를 통해서 지속적으로 소통하고 하나의 의견으로 취합해나가고자 한 점이 참 좋았었던 것 같습니다.
• 서로의 의견이 때에도 부담없는 분위기를 만들어주어서 자신의 의견과 그 근거를 들어서 다름 사람을 설득할 수 있는 시간이 되어 좋았습니다.
• 초반에 워크스페이스를 잘 횔용하여 회의 내용, 기획, 아이디어 등을 잘 취합하고 정리해나서 좋았습니다

Problem

• 문제 끼워 맞추기
• 외부 자료 의존 → 다나와
• 외부 서비스 의존 → LLM 의존
• 깃 컨벤션 전략
• 공통 하네싱
• 토큰 과다 사용
• 자명한 가설
• 결정이 느리다
  • 항상 의사결정을 수립해야 함
• 구현 방향 결정이 느리다
• AI 의존적인것 같다, 보고서든, PPT든, PR이든 거의 다 사람이 안 읽고 진행하지 않나,
• 주도적으로 진행했나?
  • 내가 의견을 낸 주제로 진행하게 되었음에도 그만큼의 책임감과 확신을 갖고 임했는가?
  • 솔직히 말하면 조장(아오)에게 의지한 면이 많다고 생각함 (의사결정, 구현 등등…)
  • 내가 낸 주제라 구현 방향에 대해 내가 더 적극적으로 고민하고 실험해 봤어야 했던 것 같다
  • 내가 모르는데 남들은 이 주제에 대해 어떻게 알고 뭐가 있으면 좋을지를 아는가…
• 인정 중독
  • 내 결정에 내 스스로가 확신을 갖지 못해 작업을 진행할 때 “이거다.”보다 “이러면 어떨까요?”가 많았다.
• 결정이 느리다
• 문서화의 부재
  • 제출용 자료와 그와 관련된 산출물들은 문서화가 되어 있지만 이 것들이 만들어지는 과정에 대한 문서가 단 하나도 없다고 생각함
  • 결과도 중요하지만 그 과정에서 발생한 내 생각과 고민, 결정들을 문서화 하는 연습이 필요해보임
• 서로 다른 ai를 사용하여 개발을 진행하다보니 이에 대한 통합된 하네싱이 있었다면 좀 더 규칙 반경 안에서 개발을 잘 방향대로 진행해나갔다면 좋겠습니다.
• 워크스페이스 할당량 만료로 인해서 추가적인 개발 문서 통합이 원활히 진행되지 못해서 아쉬움이 남습니다.
• Github의 Issue를 통해서 좀 더 개발 현황에 대한 보고의 동기화가 잘 이루어졌었다면 좀 더 좋지 않았을까 합니다.
• 문서화의 부재 → 노션 워크스페이스에서 벗어나기
• 체계적인 회의+개발 사이클이 부족했다
  • 회의 → 2~3일 개발 → 회의,,, 데일리미팅을 통해 어제 뭘 개발했는지,
• 깃 컨벤션, 공통 하네싱(오케스트레이션)의 공통적인 이해가 부족했다

TRY

• 외부 자료/LLM 콜 의존하지 않는 서비스 만들기
• 공통 하네싱 정하고 작업하기
• 공통 워크스페이스 오픈소스 앱 이용해보기 AppFlowy
• 의사결정을 할 때 조금 더 체계적으로 하기
  • 여러가지 선택지 중 어떤 선택지가 더 좋을지 고민해보고 더 자세히 알아보고 여러 실험을 계획해 실제로 선택지들이 갖는 장단점이 어떤 것들이 있는지 가늠해 근거있는 선택을 할 수 있게 되고 싶다.
  • 근거가 있는 선택이라면 남들에게 이건 어떤지 물어보면서 “인정”을 요구하지 않아도 자신있게 구현해갈 수 있을 것 같음
  • 체계적인 의사 결정이라면 의사 결정을 위한 체계를 정의해야할 것
  • 어떤 체계를 설계하고 사용할지 고민해보는 것이 앞으로의 과제일 것 같음
• 결과 뿐만 아니라 과정도 문서화하기
  • 회의, 작업 등등을 진행하면서 그 때 그 때 내 생각, 고민, 결정, 근거 등을 문서화한다.
  • 노션을 사용할 생각
  • Mind Note??
• 좀 더 체계적인 데이터베이스 생성
• issue 적극 사용
• 브레인 스토밍을 진행했던 순간들도 기록하기
• 녹음을 통한 모든 순간순간 기록
• 저한테 좀 더 확신 있는 근거를 가지고 주장할 수 있는 지식이 있으면 좋겠습니다.

팀이 다음에 가져갈 1가지

1. 공통 워크스페이스를 통한 문서화

[malibinYun]

최종 발표까지 정말 고생 많으셨어요.
제가 알림이 안와서 너무 늦게 봐버렸네요.. 죄송해요.
더 이야기 나누고 싶은 게 있거나, 제 의견이 더 궁금한 점들이 있다면 코멘트로 남겨주세요.
슬랙 방에다 말씀해주셔도 좋아요.

[malibinYun]

내가 만든 걸 어쨌든 팔기 위해서는 결국 쓰는 사람, 고객이 중요하죠.
고객의 목소리에 귀기울이고 피봇한 것 굉장히 쉽지않지만 멋진 결정이라 생각해요.

[malibinYun]

판단에 대한 근거를 좀 더 써보는 건 어떨까요?
위 항목에서는 피드백을 통해 반영했던 것 처럼요.

[first-woosun]

위 내용들의 경우 모두 “사용자의 감각”에 관련된 요소들로 단순히 태그로만 표현되면 제공된 정보를 봤을 때 직관적으로 이해되지 않을 것 같다는 피드백이 있었습니다.

“걸림”의 경우 여러 종류의 키보드를 타건해본 경험이 없는 사용자의 경우 걸림이라는게 어떤 느낌인지 조차 인식되어있지 않은 경우가 많았고, 소음의 경우에도 단순히 “조용함”, “보통”, “시끄러움”등으로 나타낼 경우 타건 소리가 얼마나 큰지 잘 안 와 닿을 것 같다는 피드백이 있었습니다.

따라서 단순히 단어로만 표시하는 것 보다, 좀 더 시각적인 정보로 제공해 사용자의 이해를 돕고자 레벨미터의 형태를 채택했습니다.

타건 소리 의성어 태그의 경우에도 위와 마찬가지로 사용자의 감각적 주관에 크게 의존하는 정보라고 생각했습니다. 다만 이 부분은 어떤 피드백을 받고 변경된 것이 아닌 제작과정에서 든 의문과 그 의문이 결과물에 반영된 결과입니다.

동일한 키보드 타건 소리에 대해 어떤 사람을 “보글보글”이라고 느끼고, 어떤 사람은 “부글부글”이라고 느낀다고 가정해보겠습니다. 이 때 서비스를 제공하는 측에서 “보글보글”이라는 의성어로 픽스해 제공한다면 “부글부글”이라고 느낀 사용자의 입장에서 “이건 부글부글 아닌가? 이 서비스 이상하네?”라는 부정적 경험으로 이어질 수 있겠다고 생각했습니다.

물론 의성어 태그만 제공했을 때의 사용자 경험이 어떤지와 타건 영상을 제공했을 때, 두 정보 모두 제공했을 때의 사용자 피드백을 수집했다면 서비스 운영에 유의미한 데이터를 뽑아낼 수 있는 부분인 것 같은데, 실패 경험을 회피했다는 점에서 아쉬움이 남는 부분입니다.

[malibinYun]

위 내용을 바탕으로 그러한 피드백 기반으로 이러이러해서 변경햇다~ 이런식으로 문서를 개선하시면 좋겠네요!

[malibinYun]

조금 더 이유가 구체적이면 좋겠는걸요. 제가 생각하는 파이어베이스의 가장 강점은 무료 사용량이 매우 많은 거라 생각해요. 짧은 시간 내 높은 트래픽을 처리하긴 어렵지만요.

[chohs4164]

Firebase의 가장 큰 장점은 무료 사용량이 넉넉하다는 점이라고 생각합니다. 실제로 Firebase Spark Plan은 결제수단 없이 사용할 수 있고, Firestore도 일 단위 읽기/쓰기 무료 한도, Cloud Functions도 월 호출 무료 한도를 제공합니다. 그래서 초기 MVP나 짧은 기간의 실험 서비스에는 Firebase가 비용 측면에서 매우 유리하다고 판단하였습니다.

다만 KeyBuddy에서는 단순히 무료 사용량보다 데이터 구조와 이후 확장성을 더 중요하게 봤습니다. 저희 서비스는 키보드 catalog를 조건별로 필터링하고, 추천 결과와 사용자 이벤트를 구조화해서 다뤄야 했기 때문에 문서 기반 NoSQL보다 PostgreSQL 기반의 관계형 모델이 더 잘 맞았습니다. Supabase는 PostgreSQL을 그대로 사용하므로 SQL 쿼리, 테이블 구조, RLS 정책을 명확하게 설계할 수 있다는 장점이 있었습니다.

또한 Firebase는 Google Cloud 생태계와 강하게 결합되어 있어 Firestore,Firebase Auth, Cloud Functions 중심으로 구현하면 이후 다른 환경으로 옮길 때 데이터 모델과 인증 흐름, 함수 배포 방식을 다시 설계해야 할 가능성이 큽니다. 반면 Supabase는 PostgreSQL 기반이고 self-hosting 옵션도 제공하기 때문에, 장기적으로는 특정 벤더에 대한 종속을 조금 줄일 수 있다고 판단했습니다.

Edge Functions 측면에서도 Supabase는 Deno 기반 TypeScript 함수를 전 세계 edge에 배포할 수 있고, 로컬 실행 및 Deno 호환 환경으로의 이식 가능성을 제공합니다.

[malibinYun]

깃, PR 포맷, 브랜치 컨벤션은 정말 필요한 하네스였을까요?
그만큼 정밀했어야했는지요. 이런 경우 필요한 하네스는 무엇이었을지 고민해보는 것도 좋은 고민이란 생각이 들어요.

[CommitTheKermit]

이번 프로젝트를 돌아보면, 에이전트의 작업과 코드의 흐름을 잘 따라 가고 있었는가? 하고 질문을 던지자면 그렇지 않았다고 생각합니다. 전체적인 흐름은 잘 알고 있으나, 어떻게 태그를 추출했는지? 어떻게 추천을 하는지? 큰 흐름은 설명할 수 있지만 세부적인 흐름은 잘 모른다고 생각합니다.

대AI 시대에 "몇번째 줄에 어떠한 코드가 있다" 정도는 아니더라도, "이 기능은 이러한 흐름으로 작동한다."를 잘 설명할 수 있어야 한다고 생각합니다. 그렇기에 AI를 사용해 개발을 했더라도, 흐름을 잘 따라가기 위해서라면 "PR은 손으로 작성해야겠다."라는 생각이 들었습니다. 이처럼 에이전트의 흐름을 따라가기 위해서 직접 읽고 직접 쓰는 부분이 많아야겠다라는 생각입니다.

깃 컨벤션 하네싱은 PreToolUse 하네싱을 통해서 할 수 있습니다. 정확히는 Bash Tool을 사용하기 전에 내가 정해진 포맷을 주입할 수 있습니다. 기존에는, Skill이나 MEMORY를 통해서 하네싱을 달성하려고 했는데, Skill은 항상 발동된다고 보장하기 어렵고 메모리는 Advisory 성격이 강해, 문맥이 너무 길어지면 클로드가 듣지 않는 경우가 있어 항상 규칙을 준수한다고 보장하기 어렵습니다.

그렇기에, git 명령어를 사용할 때 내가 원하는 포맷을 강제하도록 하고 만약 포맷을 따르지 않았다면 아예 에이전트 흐름을 Stop되게 하려고 합니다.

[malibinYun]

"이 기능은 이러한 흐름으로 작동한다를 잘 설명할 수 있어야 한"다 했을 때, PR을 손으로 작성하는 것과 어떤 연관이 있나요?
설계자체는 사람끼리 하고, ai의 도움을 받으면서, 그 결정과 내용들을 잘 담아서 ai에게 정리시키고, 그 정리된 문서를 팀원들이 다시 검토하고 하는 것은 어떨까요?
설계문서만 있으면 구현은 ai가 금방 해내니까요.
설계한 걸 까먹는 건 저처럼 청년 치매를 극복해야하는 문제가 될지도요..

[malibinYun]

깃, PR 포맷, 브랜치 컨벤션은 정말 필요한 하네스였을까요?
그만큼 정밀했어야했는지요. 이런 경우 필요한 하네스는 무엇이었을지 고민해보는 것도 좋은 고민이란 생각이 들어요.

[CommitTheKermit]

이번 프로젝트를 돌아보면, 에이전트의 작업과 코드의 흐름을 잘 따라 가고 있었는가? 하고 질문을 던지자면 그렇지 않았다고 생각합니다. 전체적인 흐름은 잘 알고 있으나, 어떻게 태그를 추출했는지? 어떻게 추천을 하는지? 큰 흐름은 설명할 수 있지만 세부적인 흐름은 잘 모른다고 생각합니다.

대AI 시대에 "몇번째 줄에 어떠한 코드가 있다" 정도는 아니더라도, "이 기능은 이러한 흐름으로 작동한다."를 잘 설명할 수 있어야 한다고 생각합니다. 그렇기에 AI를 사용해 개발을 했더라도, 흐름을 잘 따라가기 위해서라면 "PR은 손으로 작성해야겠다."라는 생각이 들었습니다. 이처럼 에이전트의 흐름을 따라가기 위해서 직접 읽고 직접 쓰는 부분이 많아야겠다라는 생각입니다.

깃 컨벤션 하네싱은 PreToolUse 하네싱을 통해서 할 수 있습니다. 정확히는 Bash Tool을 사용하기 전에 내가 정해진 포맷을 주입할 수 있습니다. 기존에는, Skill이나 MEMORY를 통해서 하네싱을 달성하려고 했는데, Skill은 항상 발동된다고 보장하기 어렵고 메모리는 Advisory 성격이 강해, 문맥이 너무 길어지면 클로드가 듣지 않는 경우가 있어 항상 규칙을 준수한다고 보장하기 어렵습니다.

그렇기에, git 명령어를 사용할 때 내가 원하는 포맷을 강제하도록 하고 만약 포맷을 따르지 않았다면 아예 에이전트 흐름을 Stop되게 하려고 합니다.

[malibinYun]

이건 왜 두개지

[malibinYun]

이 가설들도 나중에 검증해보기 위해서 어떤 것들을 지표삼아볼 수 있을지 정리해보는 것도 좋은 방법이란 생각이 드네요!

[chohs4164]

저희가 제공하는 서비스에는

1. 자연어 입력을 통한 검색

2. 선택지 입력을 통한 검색

이 두가지 방식을 통해서 내가 원하는 키보드를 찾을 수 있도록 하고 있는데

이 두 방식 중에서 1번:자연어 입력을 통한 방식으로 검색하여 사용하는 비율이 높다면, “자연어 입력을 통한 검색이 사용자에게 편한 방법일 것이다.” 라는 결론을 낼 수 있을 것 같습니다.

한 세션 내에서 사용자가 자연어 검색을 통해서 키보드를 검색하는 횟수, 자연어 압력을 통한 검색을 사용하는 빈도 등의 데이터를 수집하여 지표로 삼을 수 있을 것으로 보입니다.만약 최초 검색 이후에 사용한 문구가 이전 검색과 동일한 의도를 가지고 재검색을 수행한다면 이것은 추천 결과가 만족스럽지 않았다는 것을 의미할 것 같습니다. 동일한 의도를 갖는지 여부는 입력된 자연어에서 추출한 태그들의 유사도를 분석하는 방법이 있을 것 같습니다.

[malibinYun]

Problem
구현 방향 결정이 느리다
AI 의존적인것 같다, 보고서든, PPT든, PR이든 거의 다 사람이 안 읽고 진행하지 않나,

설계와 구현을 잘 나누는 게 중요해보여요. 설계대로 잘 구현해냈는지에 대한 테스트, e2e 테스트 목록을 마련해서 그것을 모두 통과하는지 점검한다면 구현을 어떻게 했느냐는 사실 크게 중요하지 않아보여요.
설계를 어떻게 했는지는 모두가 잘 알고 있어야겠지요.

분산 처리를 했다던지, 트래픽 감당을 위한 전략을 어떻게 했다던지, 실패에 대한 처리는 어떤식으로 마련되어있는지 등등.. 설계와 방향을 잘 정해둔다면 그것들을 어떻게 코드로 실제로 구현했는지는 이제는 중요하지 않은 시대가 왔다고 생각해요.

문서화의 부재
제출용 자료와 그와 관련된 산출물들은 문서화가 되어 있지만 이 것들이 만들어지는 과정에 대한 문서가 단 하나도 없다고 생각함
결과도 중요하지만 그 과정에서 발생한 내 생각과 고민, 결정들을 문서화 하는 연습이 필요해보임

ADR을 잘 쌓아서 이것을 ai가 참조하도록 하는 것이 가장 좋지요.
ai가 기획이나 결정사항들에 대한 컨텍스트를 알면 알 수록 ai는 훨씬 똑똑하게 결과물을 내놓을 것이에요.

문서를 여러곳에 분산하는 것도 장점이 있을 수 있지만, 아예 하나 (깃) 에서 관리하는 것도 나쁘지 않다고 생각해요. ai가 mcp나 툴을 활용해서 보는 것 보다는 로컬 문서를 보는 게 더 즉각적이니까요. 장단점이 뚜렷해서 상황에 맞춰서 잘 활용하면 좋겠어요.

[malibinYun]

빠른 호흡의 프로젝트 진행하시느라 고생 많으셨어요.
중간에 아이디어 피봇까지 해서 더 힘들었을텐데 결국 완료까지 잘 하셨네요 👍
피드백은 이만 마무리 짓도록 하겠습니다.
그룹 DM 방 만들어놓은 것이나, 1:1 DM으로 언제든지 궁금한 점들 물어보셔도 좋으니 메시지 남겨주세요.
남은 3 4 레벨도 화이팅입니다 💪