올해 회사에서 AI 서비스를 통한 워크 프로세스 자동화를 적극적으로 추진하기 시작하면서, 그동안은 chatGPT랑 소소한 잡담 나누고 마케팅이나 카피라이팅 정도만 수행하던 나에게 Claude Code라는 새로운 세계가 열리게 되었다.

나의 개발 지식은 사실상 없다고 보면 됨 ㅎㅎ 그냥 가끔 간단한 코드들은 까보고 유추해서 이해할 수 있는 정도..? 혹은 어떻게 보는지 한번 개발자 분들로부터 배운 파일들은 내가 직접 개발은 못해도 대강 구조 파악과 원하는 정보 캐치할 수 있는 정도?

직접 개발하라 -> 이건 아무것도 못한다고 보면 된다. 실제로 이번에 클로드 코드를 일주일간 삽질하면서 알게 된 커맨드는 cd ~ 이런 거 정도가 다임 ^_^*

여하튼 결론적으로 일주일간 클로드와 진대하면서 느낀 것은 이렇다. (참고로 내가 쓴 플랜은 Max다.)

• AI 시대가 오면 개발자들이 자리를 잃는 거 아니냐 이런 고민들을 들은 것 같은데 개인적으로 개발자는 절대 사라지지 않을 것 같다..
• 솔직히 아예 IT 관련 지식이 없는 사람이 뭔가를 뚝딱 만들기에는 아직은 힘들다. 나도 IT 소프트웨어 PM 4년차니까 그나마 기본적인 지식이 있어서 집요한 대화로 뭔가 만들 수 있는 듯 함... 정말 시간 많이 들이고 공부도 하면서 하면 가능할지도.
• 클로드 코드는 QA는 정말 못한다. 지가 구현해둔 코드(로직)에 에러가 없는지 버그는 없는지 등은 잘 확인하는데, 실제로 테스트 환경에서 돌려보면 진짜 인간이라면 할 수 없는 큰 UI/UX 결함이 많이 발견된다. 그래서 이 새끼 한 30%만 만들어놓고 지금 나한테 짬처리하네.. 싶을 때가 있음 ^_^
• 어찌되었든 만들고 나서 겉보기에 버그/에러 없이 돌아가는 뭔가를 만들 수 있긴 한데 코드를 얘가 잘 짠건지(?) 이런건 내가 평가를 할 수가 없다. 개발 배워야 하나(?)

여하튼 뭐 개발 한줄 하지 않고 여러 가지를 만드는 데에 성공했으니 나는 이 삽질 행위를 바이브 코딩이 아니라 바이브 PMing 이라고 부르기로 했다. 내가 클로드랑 거친 일련의 프로세스들은 솔직히 내가 PM으로 일하는 프로세스랑 거의 다르지 않았으므로..

• 먼저 대강 어떤 것을 만들고 싶은지 토픽을 정한다.
• 기능별 상세를 기술한다. (이 때, 로직이 쉽게 꼬일 수 있는 것들은 좀더 신경써서 내가 스코프나 제한할 것, 이런 케이스에는 이렇게 할 것 등을 결정하고 전달한다.)
• 뭔가를 요청했을 때 클로드가 몇 번이나 이건 불가능하다고 대답할 때가 있다. 그럴 때는 정말 안되는지 구글과 깃헙에서 집요하게 검색하다보면 누군가가 성공한 케이스를 발견한다. 그러면 그 리서치 결과를 또 클로드에게 전달해서 가능하다고 대답할 때까지 줘팬다(?).
• 위 과정을 거쳐 클로드가 만든 것을 테스트 환경이나 시뮬레이터에 돌려서 QA를 한다. UI/UX 면에서 보통 정말 상상치 못하게 후질 때가 많으므로 정말 개 집요하게 QA를 해야 프로덕션으로 내보낼 정도의 퀄리티를 만들 수 있다.

vibe PMing 을 위해 필요한 준비물은 1) 정말정말 기초레벨의 IT 소프트웨어 프로덕션 지식과 2) 미친 집요함과 3) 인내심이다. 여기까지를 갖췄다면 당신은 이제 무엇이든 적어도 UI/UX 상에선 기능적 버그가 없는 MVP 수준으로는 만들 수 있다.

지난 일주일간 내가 개발해본 것은 다음과 같다.

1. 50대 이상의 시니어들이 사용할 수 있는 식단 추천 모바일 앱
2. 리니어(우리 회사에서 쓰는 태스크 매니지먼트 툴)의 티켓 내용을 댓글에 /translate을 남기면 영->한, 한-> 영 번역해주는 봇
3. 54일의 5단 묵주기도를 도와주는 모바일 앱
4. 개인 블로그 (지금 이 사이트! >.<)
5. 웹플로우에서 CMS 아이템들을 쉽게 업데이트할 수 있게 해주는 슬랙봇

그럼 각 프로덕트를 개발하는 데에 어떤 삽질을 거쳤는지 기술해보겠다.

50대 이상 시니어를 위한 식단 추천 모바일 앱 '밥심'

솔직히 제일 처음 개발 시도해본 앱이 이거였는데 이게 좀 빡셌던 점.. 나의 패기로움에 한 방 맞음

핵심 설계 결정

밥심은 큰 틀에서 50대 이상 시니어 유저가 연령대, 신체 정보 (키, 몸무게), 그리고 질환정보를 입력하면 그에 따라 매일매일의 식단을 아침, 점심, 저녁으로 추천해주는 앱이었다.

• 연령대/성별별 칼로리 기준: 2020 한국인 영양소 섭취기준 적용

50대 남성 2,200kcal / 여성 1,800kcal

60대 남성 2,000kcal / 여성 1,600kcal

70대+ 남성 1,900kcal / 여성 1,600kcal

• 질환별 영양 제한: 고혈압(저나트륨), 당뇨(저당), 신장질환(저단백) 등 상충하는 조건도 고려해서 추천하게 할 것

• 50+ UX 특화: 큰 글씨, 높은 명암비, 터치 영역 사이즈 고려

• 세부적으로 고려한 것: 오늘의 식단 외에도 이전 7일, 이후 7일의 총 15일의 식단을 화살표로 이동하여 확인할 수 있게 하기, 원하지 않는 식단인 경우 아침, 점심, 저녁별로 버튼 하나만 눌러서 다시 식단을 추천받을 수 있게 하기, db에 있는 식단들이 서로 같은 이름을 갖고 있는 경우 우선 칼로리가 가장 낮은 것을 위주로 추천하게 하기, 각 음식별 영양정보와 레시피를 제공하게 하기

• iOS, Android를 동시에 지원하기 쉽게 하기 위해서 Flutter를 사용하라고 했다. 그리고 기본적인 디자인도 Flutter library 갖다 쓰라고 했고, 폰트는 가독성 좋게 프리텐다드 쓰라고 함.

• 그리고 유저가 특정 레시피가 마음에 들었을 때 저장해두고 싶을 것 같아서 즐겨찾기 기능을 추가함

데이터 설계의 고민

일단 가장 고민이 처음에 되었던 부분은 식단 데이터와 영양 정보를 어디서 가져올 것이냐였다. 구글링을 해본 결과 식품안전나라의 DB를 무료로 사용할 수 있는 것을 알게 되었는데, api key를 발급받기 위해선 사이트에 가입을 해야만 했다. 근데 사이트가 후져서(?) 가입이 안되는 상황이 발생함. 그래서 해당 사이트 내에 어딘가에 게시되어 있었던 엑셀 파일을 저장하고 이를 학습시켰다. 식품안전나라 DB에는 총 19,495건의 음식 영양 정보가 등록되어있다.

• 장점: 정부 공인 영양성분 데이터, 한국 음식 특화
• 단점: 레시피(조리법) 없음 -> 여기서 레시피 데이터를 그럼 어디서 가져와야 하는지에 대해 고민이 생김

그 과정에서 누군가가 비슷한 사이드 프로젝트를 한 것을 발견, 만개의 레시피를 크롤링하면 되겠구나! 라는 깨달음을 얻게 됨. (누군지 모르지만 압도적 감사..) 은혜롭게도 코드까지 남겨주셨는데 내가 구현하고 싶은 거랑 다를 수도 있을 거 같아서 그냥 코드를 갖다 쓰진 않고 Claude Code를 개패서 내가 원하는 로직으로 코딩하라고 시킴

• 장점: 상세한 조리법, 재료 목록
• 단점: 영양정보 불완전, 같은 음식의 레시피가 굉장히 많이 등록되어 있어서 구현해야 할 검색 로직이 복잡해졌음

데이터 모델 통합 문제 (꽤 까다로웠던 이슈)

두 데이터 소스를 통합하면서 ID 체계 문제가 발생. 데이터의 출처 구분을 명확히 해야 나중에 검색 로직이나 이런 걸 구현할 때 편할 거 같아서 id에 접두사를 붙여야 했음.

//FoodData (식품안전나라 원본)
id: "D101-004160000-0001"

// UnifiedFood (통합 모델)
id: "fsk_D101-004160000-0001"  // fsk_ 접두사 추가

근데 이 과정에서 레시피 화면에서 id 매칭이 계속 실패해서 이걸 디버깅 하는 데에도 좀 시간이 걸렸음

기능 구현 과정

(이것도 한세월 걸렸던..)

• 건강 기반 음식 점수 시스템 :가장 많이 고민했던, 그리고 클로드와의 진대를 가장 오래해야 했던 것 중에 하나였는데 유저의 신체정보, 질환정보, 연령대를 바탕으로 추천할 때 어떻게 스코어링을 할지에 대한 설계였다.

• 점수 산정 로직 (0~100점):

기본 점수: 50점

영양소 점수: 단백질, 식이섬유, 미량영양소

질환별 맞춤 점수: 고혈압(나트륨↓), 당뇨(당류↓), 골다공증(칼슘↑) 등 고려 -> 이게 까다로웠는데 예를 들어서 유저가 저체중인데 고지혈증을 질환 정보에서 선택했다.. 그러면 저체중 식단에는 지방을 좀더 많이 구성해야 하는데 고지혈증의 경우 지방을 제한해야 해서 이런 식으로 상충하는 케이스들에 대한 고려가 또 필요했음

신체 정보 기반: BMI, 활동량

연령/성별 특화: 근감소증 예방(단백질↑), 폐경 후 여성(칼슘↑)

어려웠던 점은 위에 기술한대로 복합 질환자 또는 상충하는 건강 정보에 대한 처리가 어려웠다. 예시) 신장질환 + 골다공증: 단백질↓ vs 단백질↑ (상충!) → 질환별 가중치를 설정하고, 특정 질환에 대한 고려가 우선순위 높도록 조정

• 식단 추천 알고리즘: 오늘 포함 전 7일, 후 7일 총 15일치 식단을 한 번에 생성해서 유저가 navigate할 수 있게 하는 기능을 넣고 싶었음.

// 칼로리 목표의 80% 이상 달성 보장
while (totalCalories < targetCalories * 0.8) {
  // 높은 점수 음식부터 추가
}

고민했던 또 다른 부분 중에 하나는, 같은 음식이 자주 나오면 유저 입장에서 또 지루하거나 효용성을 못느낄 수 있기 때문에 최근 3일간 추천된 음식은 식단에서 제외하는 중복 제외 로직 추가가 필요했다. 또, 끼니별로 아침 30%, 점심 40%, 저녁 30%로 칼로리 배분을 할 수 있도록 지정함.

레시피 상세 화면의 진화

초기 구현:

// 하드코딩된 레시피 데이터
final recipes = {
  'hyunmibap': Recipe(name: '현미밥', ...),
  // ...
};

이게 클로드 샛기가 맨 처음에 구현해놓은 건데 모든 레시피가 탭했을 때 '현미밥'으로 뜨는 아주 초보적인 로직 실수를 했다. 멍청한 색기.. 큼큼

문제: 모든 레시피 클릭 시 "현미밥"만 표시됨. 아까 데이터 설계 파트에서 설명한대로 db에 있는 id를 매칭하는 데에 실패한 것 같은데 (아마도?) 여하튼 이거 디버깅하는 데에도 한참 걸렸음 후후..

버그 수정 과정

• "레시피 정보를 찾을 수 없습니다" 버그

홈 → "레시피 보기" → 에러

식단 탭 → 레시피 버튼 → 에러

레시피 탭 → 아무거나 클릭 → 현미밥 페이지

대강 이런 버그가 있었는데...

클로드 코드를 계속 팼더니 대충 아래와 같은 과정을 통해 해결하더라.

meal_recipes_screen.dart: fsk_ 제거 로직 추가

recipe_detail_screen.dart: 전면 재작성 (하드코딩 → 실제 데이터 사용) // 근데 개인적으로 하드코딩이 효율적인 방법이었는지는 모르겠으나 그냥 뭐 내가 개발자가 아니니 넘어갔음

app_router.dart: path param → query param으로 변경 (복잡한 ID 인코딩 문제 해결)

• 검색 중복 결과 버그

그리고 db가 방대하다보니 검색 결과가 지나치게 diverse했는데 이러면 사용자 경험이 구릴 것 같아서 이것도 개선하고 싶었음. 예를 들면"아욱" 검색 시 "아욱국"이 5개씩 나오는데 이러면 오히려 유저가 불편하다고 생각. (유저는 선택지가 많으면 싫어한다고 생각함)

해결:

List<UnifiedFood> _deduplicateByName(List<UnifiedFood> foods) {
  final Map<String, UnifiedFood> bestByName = {};
  for (final food in foods) {
    final existing = bestByName[food.name];
    // 같은 이름이면 칼로리 낮은 것 선택 (건강 목적)
    if (existing == null || food.calories < existing.calories) {
      bestByName[food.name] = food;
    }
  }
  return bestByName.values.toList();
}

• 홈 화면 오늘 식단 표시 버그 홈에서 "오늘의 식단"이 표시 안 됨

원인:

// 잘못된 코드
mealPlanState.mealPlans[0]  // List로 접근 시도

// 올바른 코드
mealPlanState.plans[todayKey]  // Map<String, DailyMealPlan>으로 접근

데이터 구조 변경(List → Map) 후 일부 화면에서 업데이트가 누락된 거였는데. 내가 느끼기에 뭘 업데이트하고 나면 Claude Code가 알아서 다른 로직들에서 업데이트가 필요한 부분들을 착착 잘 해주진 않는다. 그래서 꼼꼼하게 매번 업데이트마다 근데 이렇게 했을 때 깨지는 로직이 있거나 하지 않은지 계속 Claude를 패야 함. 개잡도리 모드 on...

보안 이슈 예상?

api key나 firebase 설정 파일 같은 것들 .gitignore에 추가해두기 <- 이건 뭘 개발하든 다들 꼭 챙겨하십셔! 클로드 코드가 정신 못차리고 깃헙에 걍 올려놔버릴 수 있음 그러면 키 같은거 다 새로 발급 받아야하니께 매우 귀차늠..

QA?

QA는 솔직히.. 흠.. 우선 개잡도리로 클로드한테 지금까지 빌드한 것들 네가 유저 시나리오 3개 정도 랜덤하게 작성해서 이런 경우 문제가 없을지 로직들 전체 user flow에서 확인해봐라.. 물어보고 이거를 한 30번 돌려줬다. ㅎ 개잡도리... ㅎ 클로드가 나 혐오할 듯

그러고 나서 시뮬레이터 돌려봐도 놀랍게도 UI/UX에서 이 색기가 미쳤나.. 싶은 것들을 발견할 수 있다. 로그인, 로그아웃, 앱 삭제 후 재설치 등 엄청 간단한 것들도 진짜 꼼꼼히 실제로 QA해보길 바란다. 시뮬레이터에서만 끝내지 말고 실기기에서도 테스트해보길 바람.

우선 여기까지 하고 구글 개발자로 등록하고 뭐 이런거 다 귀찮아서 (이 과정에서 해두긴 했는데 뭐 어차피 계속 유지보수할 것도 아니고 엄마를 위해서 만든 앱이었어서 걍 앱스토어들에 배포까진 안했음.) 엄마한테 apk 파일로 전달해줬다. 좀 뿌듯했던 건 우리 회사 CTO님께서 앱 좀 써보시더니 '이 정도면 프로덕션에 내도 될 퀄리티인데요?'라고 했다는 점. 후후. 저의 잡도리력에.. 놀라셨나요? >.<

원래 계획은 모든 앱들에 대한 일지를 한 편에 남기는 거였는데 여기까지만 해도 글이 꽤 긴 것 같아 나머지 앱들에 대한 것들은 추후의 글들에서 기술하기로.... 큼큼 투비 컨티뉴드... 🌟