Mixby, 그게 뭔데 씹덕아..

1년 전 24년도 2학기에 진행한 프로젝트이다. LLM을 사용한 칵테일 퍼스널라이즈 ios 앱이다.

한학기정도 열심히 진행했는데 반년도 더 넘게 지난 프로젝트를 왜 이제와서 호들갑이냐 할 수 있겠지만 어쩌다보니 이걸로 대회? 부스 운영을 하게 됐다... (사실 뭔지 정확히 모름)

정식 출시를 하려고 했으나 앱 스토어의 문은 높았고 (비쌌고) 수익화 모델도 제대로 나오지 않아서 포기했었다.

다시 와서 코드를 보니 정식 출시했으면 저장하는 개인정보는 없었겠지만 지갑 탈탈 털리고 아무것도 못했을 것 같다. 이 기회로 정식출시하는 길까지 화이팅!

9월의 개발

사실 부트캠프를 듣고 있어서 짬짬히 내고 있어서 그렇게까지 효율 좋게 작업하진 못하고 있다. 하지만 과거의 나였다면 하루 종일 끙끙 됐던 걸 좌 cursor, 우 copilot, 중(?) codex 를 끼고 하다 보니 엄청난 작업 속도를 보이고 있다.

매도남이 되...
나중에 시간이 된다면 프롬프팅 관련 내용도 올려볼게요..

리펙토링 대작전

github로 프로젝트 구조를 확인하는데 답이 없었다. 프로젝트에 구조에 대해서 전혀 모르고 코드를 작성했었고, 그 결과 정말정말 답이 없는 구조였다.
그래서 리펙토링을 하기로 결정했다.

답이 없는 프로젝트 구조임다

이때 cursor에 남은 토큰이 간당간당해서 어떻게 할까 고민을 하다 새로운 접근을 하게 되는데...

gemini-cli

이 녀석을 잘 활용해보기로 했다. gemini-2.5-pro가 어느정도 잘해주기도 하고 cli 환경에서 동작하니 cursor에 claude가 gemini를 하청하는 식으로 작동하면 괜찮겠다고 생각했다.
그래서 일단 gemini로 현재 디렉토리의 문제점을 분석하라고 하고 해당 내용의 요약본을 solution.md로 저장했다.

cursor에 가서 해당 문서를 읽고 gemini를 사용해서 리펙토링 진행하라는 프롬프트를 작성했다.

'''
해당 solution.md 문서 참고해서 이 프로젝트의 문제점들을 해결할거야.
gemini cli를 너가 직접 컨트롤하면서 너는 계획과 명령을 gemini cli를 통해서 내리고 그 결과를 보고 받으면서 프로젝트 개선을 수행해.
'''

지금와서 보니깐 grok-code-fast-1을 쓴거 같기도 한데 그게 중요한게 아니다. 아무튼 이런 워크 플로우를 가지니깐 확실히 작업이 쪼개져서 꽤나 정확하게 수행했다.

결과

정말정말 괜찮은 구조로 작성됐다. 아싸라봉봉봉

근데 문제가 발생한게 내가 연결했던 openai-api코드들이 다 날아가버리는 바람에 추가 작업을 진행했다. 하지만 요종도야 머

아무튼 뽀뽀 마려워지는 cursor와 gemini의 합작품이었다.

git 관리

일단 사실상 혼자 Backend를 맡고 있어서 대충 해도 되겠지만 branch 관리를 제대로 해둬야 편할 거 같아서 어느정도는 하고 있다. 예전에는 정말 멍청하게 개발하는 사람 이름으로 적고 이랬었는데 이제는 기능, 목적 별로 구별하고 있다.

써보면서 느낀점은 feat/, fix/ 이런식으로 prefix를 정하는게 좋은 거 같다. 가끔씩 작업하는 내 팀원은 브랜치 작명을 제대로 안 하는게 문제이지만... 브랜치 따로 파는 것만으로도 만족하고 있다.

Docker

사실 docker가 거품이라고 생각했던 사람으로 이걸 어찌 활용해야 좋을까 생각했었는데 써보니깐 docker는 신이었다.

예전에 Makefile을 조금 다뤄본 경험이 있는데 makefile과 연계해서 사용하니 이만한 놈이 없다. 또 환경마다 의존성 생각 안 해도 되고 내 컴퓨터에 잡다한 라이브러리 안 깔아서 좋다.

요즘은 docker-compose를 더 많이 권장하는 거 같은데 해당 이유는 자세히 찾아보지 않아서 잘 모르겠다... 이거는 기회가 되면 조사해보는걸로 하자.

근데 docker 작업을 하고 팀원이 조금 싫어하긴 했지만 어떻게 상요하는지 방법 알려주니 곧잘 한다 ㅋㅋㅋ

Jenkins

팀원이 어디서 보고 왔는진 모르겠어도 이 놈을 우리 프로젝트에 연결해서 특정 브랜치에 새로운 커밋이 생기면 트리거로 작동해서 배포 해주는 프레임워크를 가져와서 끙끙되고 있었다. 포기하려고 하길래 그냥 내가 해보기로 했다. 재미있어 보였던 건 안 비밀.

원인은 .env 파일을 인식하지 못하는 것이었는데 git 에는 .env 파일이 없어서 오류가 나는 거 같았다. local에서 돌아가는 프레임워크라 당연히 읽을 수 있을 줄 알았는데 계속 못 읽길래 codex를 마구마구 채찍질을 한 결과, Jenkins에서 credential로 secret file로 .env를 업로드 해줘야 하는 걸 알게 됐다. 그렇다고 맨날 빌드할 때마다 넣어줄 순 없으니 .env가 바뀔 때 수동으로 넣어주는 방식으로 구현했다.

신기하고 생각보다 좋은 것 같다... 물론 github action으로 나중에 테스트 다 돌리고 동작하도록 플로우를 조금 수정해야 할 듯하다.

스팸 메일마냥 엄청나게 오고 있다 ㅋㅋㅋ

PR 이슈

팀원이 PR이 익숙하지 않은지 approved 로 code review를 해야 하는데 comment로 달았길래 오프라인에서 뭐라고 좀 했었다.

그러자 죄송합니다로 approved 보내는게 밈이 됐다. ㅋㅋㅋㅋ

걍 웃겨서 냅두기로 했다... ㅋㅋㅋㅋㅋㅋ

회고

Liked

• 서로 소통하면서 요구사항 이슈로 올려서 관리하는게 좋았다.
• 리펙토링 틈틈히 하면서 진행하는게 좋다.
• 코드 스타일이나 RULE을 정해두고 프로젝트를 진행하는게 개발에 도움이 된다. (생성형 모델을 사용할 때도 마찬가지)

Learned

• jenkins flow
• docker + makefile 로 쉽게 docker container 생성 가능
• 정형화된 프로젝트 구조

Lacked

• 효율적인 리소스 관리 부족
• 프로젝트 db 여뷰 결정을 빨리
• 추천 프롬프팅 빈약

Longed for

• LLM 기반 추천 시스템 학습
• Recommender system 관련 정보 학습
• Makefile 복습
• 브랜치 전략 공유