1편 바로가기

지난 1편에서 내가 일주일간 바이브코딩으로 만들어본 것들이 다음과 같다고 소개했었다.

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

근데 솔직히 2랑 3은 좀 라이트한 편이었고 1, 4, 5가 좀 빡셌는데 1에 대해선 지난 편에서 충분히 기술한 것 같으니 오늘 편에서는 2, 3을 합쳐서 다루고 그 다음 편에서 4, 5에 대해 다뤄볼까 함. (특히 4가 시간 많이 걸렸었음,,) 3이 그래도 2보다는 쉬웠으니 3 -> 2 순으로 오늘은 적어볼 예정.

최근 들어서 갑자기 coddy tech라는 사이트를 통해서 c 언어 공부하는 거에 또 꽂혀가지고 잠시 바이브 코딩은 maintenance 및 회사에서 필요한 것들 셋업하는 정도로만 쓰는 중이라 새롭게 뭔가 만든 것은 없는데 우선 1~5까지를 글로 좀 정리해서 남겨두고 또 이어서 도전해볼까 한다. 이거 글로 정리해서 남기는 것도 상당한 시간 소요가 필요한 일이군..

그래도 나름 내 성장의 기록이라고 생각해서 잘 정리해두고 싶었슨. 나중에 다시 읽어보면 그 땐 그랬지 하면서 웃을 날이 오겠지(?)

54일의 묵주기도를 도와주는 앱, "고요"

사실 나는 창의력이 0에 수렴하는 사람이다. 창작활동을 좋아하는 것과 창의력은 완전 별개의 영역이라는 것을 ISTP인 나는 잘 알고 있다.

엠벼갈리 같을 수는 있지만, 개인적으로 인간을 대략 16가지 정도의 유형으로는 구분할 수 있지 않을까 싶다. 물론 정확하진 않더라도, 비슷한 면을 가진 사람들끼리 묶어서 16개의 유형으로 정리하는 정도라면 꽤 실용적이라고 본다.여하튼 ISTP 설명을 읽을 때마다 나랑 비슷하다고 느끼는 지점이 있는데, 그건 바로 무언가를 조립하고, 맞춰보는 걸 좋아하는 유형이라는 점이다.

설명서 보고 조립하기, 퍼즐 맞추기, 그리고 (논란의 여지가 있겠지만) 연기하기 이런 것들은 0에서 시작하는 예술이 아니라서 재밌게 할 수 있고 흥미롭지만, 아예 아무 것도 주어지지 않은 상태에서 해야 하는 그림 그리기와 같은 활동들은 젬병에 가깝다. 그니까 최소한 어떤 가이드라인이나 일종의 설명서가 있어서 그대로 뭔가를 만들어내는 것은 굉장히 재밌어하는데 아예 아무 것도 주어지지 않고 '니 마음대로 해라' 하는 예술활동은 어디서부터 시작해야 할지조차 잘 모르겠어하는 성격임.

그래서 처음에 바이브 코딩에 도전해보자! 했을 때 나는 도대체 뭘 만들어야 할지 아무런 아이디어가 없는 사람이었다.

세상에 이미 차고 넘치는 게 앱 같은데? 나는 살면서 딱히 크게 불편함을 느끼는 게 없는데? 내가 쓰는 것들은 이미 내가 다 갖고 있는데? 뭘 해야 하지? 이러고 있었음. 그래서 제일 먼저 엄마한테 혹시 필요한 거 없냐고 물어봤더니 만들어달라고 했던 게 1탄에서 기술한 '밥심'이라는 앱이었고, 이번 편에서 기술하는 기도 앱 역시 같은 천주교 신자인 언니가 필요하다고 해서 만들기 시작한 것이었다.

사실 내 입장에서는 "54 Days"라는 아주 훌륭한 앱이 앱스토어에 있었고, 그래서 잘 쓰고 있었기 때문에 아무런 니즈가 없었는데 같이 묵주기도를 시작한 언니 덕분에 해당 앱이 구글 플레이에는 출시되지 않았다는 충격적인 사실을 알게 되었던 것이다.

여튼 그래서 사실 이 앱을 만들 때는 크게 기획할 것도 없었고, 애초에 이번에도 앱스토어나 구글 플레이에 등록할 생각도 없었고, 그냥 "54 Days"랑 똑같은 기능을 제공하는 앱을 이 언니를 위해 만들어서 apk로 보내주자! 가 목표였음. (사실 앱스토어에 54 Days의 개발자 분께 이메일로 구글 플레이에 출시해주실 생각 있는지도 문의드렸는데 아무 대답이 없으신 상태 ㅠ_ㅠ 만들어주시면 안될까요..? 저는 게으름뱅이라서 앱을 출시할 생각도 없고 당신의 앱 아이디어를 도적질할 생각이 없거등여..)

서론이 길었는데 각설하고...

54일의 묵주기도 앱은 큰 틀에서 이런 기능들만 제공하면 된다.

1. 54일간 기도할 지향 기도 작성하고 저장해두는 기능. (수정도 가능해야 함)
2. 묵주기도 시작 날짜를 설정하면 마지막 날짜를 알려주는 기능.
3. 묵주기도 시작 날짜를 설정하면 오늘이 몇일째인지 알려주고, 어느 기도를 할 차례인지 알려주는 기능.
4. 해야 하는 기도에 맞춰서 기도문을 조회할 수 있는 기능.

이 정도면 이미 밥심 앱에 비하면 쏘 심플 그 자체였기 때문에 두시간만에 뚝딱 만들었음. 후후.. 클로드 폭행력 상승(?)

개발 프레임워크는 이번에도 그냥 Flutter. iOS 지원 계획이 없으신데 굳이 왜 플러터를 쓰셨죠? 라고 물어본다면..

글쎄요.. 그냥 저희 회사 모바일 앱이 플러터라서 플러터가 왠지 친숙하게 느껴집니다...(?) 그리고 디자인 라이브러리 이런 게 기본적으로 잘 되어 있는 느낌이어서요...(?) 빠른 프로토타이핑에 좋은 프레임워크 같다고 생각해서요? 사실 다른 걸 굳이 안 써봤기 때문에..? 큼큼

그 외에는... 아무래도 기능 자체가 심플하기 때문에 각 페이지에서 독립적으로 데이터를 로드하는 구조만으로도 충분하다는 생각이 들었고, 그런 면들에서 의사결정을 클로드랑 대화하면서 진행했다. (외부 라이브러리 굳이 갖다 쓰지 말고 Flutter의 기본 Stateful Widget을 사용하자, 데이터가 단순하고 서버 동기화 같은 것도 필요 없으니 shared_preferences를 사용하자 라든가)

또다른 고민 포인트: 아무래도 54일 간 기도를 도와주는 앱이다보니 기도 진행일 계산 측면에서 "오늘"의 기준이 중요했으므로 UTC +9시간으로 한국 시간대를 적용할 수 있게 처리하기 (이건 뭔가 앱 스토어에 내가 공개하게 된다면 수정이 필요한 부분일 듯한데 우선은 한국에 거주하는 신자 1명만을 위해 만든 앱이라.. ㅎㅎ)

그리고 요일별 신비 기도문이 다 다르니까 요일별로 신비 계산하게하기 <- 이게 그나마 좀 큰 기능(?)이라면 큰 기능이었고..

String getTodayMystery() {
  final weekday = getNowKST().weekday;
  switch (weekday) {
    case DateTime.monday:
    case DateTime.saturday:
      return 'joyful';      // 환희
    case DateTime.tuesday:
    case DateTime.friday:
      return 'sorrowful';   // 고통
    case DateTime.wednesday:
    case DateTime.sunday:
      return 'glorious';    // 영광
    case DateTime.thursday:
      return 'luminous';    // 빛
  }
}

그리고 홈 화면에서는 저장된 기도 데이터가 없는 경우, 기도 진행 중인 경우, 기도가 완료된 경우로 세가지로 상태를 나눠서 화면 구성:

미설정 상태: 기도 시작 안내 메시지

진행 중: 진행률 바 (XX/54일, XX%), 오늘의 신비 강조 표시, 청원/감사 단계 표시

완료: 축하 메시지

그리고 추가로 스플래시 화면 대강 앱 이름만 뜨게 해서 보여주기 정도...? 흠.. 역시 별로 할 게 없었던 앱이라 쓸 것도 별로 없군.. ^_^;; 여튼 보내드렸는데 언니가 아직도 매일매일 잘 쓰고 있다고 하고 버그도 없는 것 같다고 해서 뿌듯함.

언니.. 제가 비록 두시간만에 만든건 맞지만 그 두시간 사이에 큐에이를 얼마나 열심히 했는지 아시나요? ^_ㅠ 제 클로드는 저를 극혐할 거여요...

그리고 대망의 세번째 프로젝트.. (사실 대망까진 아님)

리니어 티켓 내용과 댓글 내용을 영-> 한, 한 -> 영 번역 해주는 봇

우리 회사에서는 태스크 매니징 툴로 Linear 라는 제품을 쓰고 있는데. 뭐 여기서도 약간의 잡설을 덧붙이자면... 왜 Linear를 쓰냐고 누군가가 묻는다면 아무래도 비개발자가 쓰기에 가장 직관적이고 쉬운 UI/UX여서? 그래서 개발자 입장에서 제일 편한지는 잘 모르겠고 비개발자들이 개발자랑 같이 일하기에 제일 쉬운 툴인 것 같긴 하다. 내가 입사 전에는 지라를 쓰고 있었어서 처음 입사했을 때 지라를 잠깐 사용해봤었는데 너무 어려웠었음 ^_ ㅠ 지금 쓰라고 하면 좀 다를지도....?

그리고 또 하나 좋은 점은 얘네 CS 속도가 장난 아님. 뭘 요청하거나 질문을 남기면 진짜 초스피드로 답변이 온다. 그리고 자기들이 생각했을 때 필요하다 싶으면 구현도 굉장히 빨리 해줌. 그래서 꽤 만족하면서 사용을 하고 있다.

여하튼~ 그래도 Linear를 사용하다보면 몇 가지 단점이 있긴 한데, 그 중에서 뭔가 바이브 코딩으로 해결할 수 있는 것은 리니어의 태스크 티켓 내용과 댓글 내용을 번역해주는 봇 정도가 아닐까 생각했다. 아무래도 우리 회사는 해외에서 일하시는 분들도 계시고 그러다보니 한국어 소통이 더 편한 한국인 팀원 분들과 영어가 더 편한 해외 팀원 분들 간의 소통이 중요할 때가 있는데, 그럴 때 매번 챗지피티 같은 거에서 번역해와서 붙여넣고 하시는 분들이 계셨음.

일단 이거는.. 그래도 생각보단 시간 투자를 꽤 한듯? 별 것도 아닌 거 같았는데 나름 46개의 커밋을 해야 했으며.. 처음으로 레일웨이라는 서비스를 가입해서 사용해볼 기회가 된 프로젝트(?)였다.

요약하자면.. 리니어 API <> Claude 연결해서 OpenAI API (gpt-4o-mini 모델)를 사용한 리니어 티켓 및 댓글 번역 기능 만들기! 단, 원본과의 대조가 항상 필요하기 때문에 원본 또한 유지할 것.

개발 단계별 히스토리

초기 구현

가장 기본적인 형태의 번역 봇을 구현

• Express 서버 설정
• Linear 웹훅 엔드포인트 (/webhook/linear)
• OpenAI를 통한 기본 번역 기능
• /translate 명령어 감지
• Railway 플랫폼 배포를 위한 Procfile 추가

주요 도전과제와 해결 과정

1. 비번역 코멘트 처리

/translate 외의 일반 코멘트도 웹훅으로 수신되어 불필요한 처리가 발생

해결

// Silently ignore non-translate comments
if (!commentBody.toLowerCase().includes(TRANSLATE_COMMAND)) {
  return res.status(200).send('ok');
}

2. 임베드(Embed) 깨짐 이슈

Figma 등 임베드된 링크가 텍스트로만 표시되고 임베드 형태가 깨짐

이게 제일 까다로웠는데.. 사실 아직도 해결하지 못한 이슈임. 계속 여러 차례 시도를 해보았으나 결국 해결하지 못해서 개발자 한 분께 도움을 요청드렸는데 잠깐 살펴보셨지만 둘 다 실패함. 근데 뭐 번역 기능 자체를 사용할 수 없는 건 아니고, 그냥 다 번역한 다음에 임베드를 추가하면 되는 거긴 해서 우선 패스하게 되었다.

이슈 해결을 위해 시도해본 방식은:

• URL이 포함된 라인을 그대로 유지하려 시도
• 이미지 및 비디오 임베드 유지 시도 - 마크다운 이미지 문법 ![alt](url) 보존
• URL 포함 단락 스킵 -> 이 경우 "자세한 내용은 링크 참고: https://..." 같은 중요한 설명도 스킵되어버림 ㅠ,ㅠ
• 마크다운 링크를 Raw URL로 변환
• Linear 첨부파일 예외 처리

일단 해결이 어려웠던 이유는... Linear API의 특성상 이슈 description을 업데이트하면 임베드 메타데이터가 사라지는 것, 그리고 Title` 형태는 Linear에서 임베드로 변환되지 않는 것.. 등등이 있었는데 여튼 결론적으로는 linear API의 한계로 댓글에 아예 새롭게 번역을 해서 달아주는 거면 몰라도 티켓 자체에 번역한 것을 달아주는 것은 임베드를 고대로~ 보존하기가 힘든 듯하다. 나중에 좀더 파보긴 할텐데..

그 외.. 이벤트 리스닝 관련한 추가 이슈들?

3. startsWith 사용 → /translate가 문장 처음이 아니라 중간에 있으면 무시됨

4. 중복 처리 없음 → 웹훅이 여러 번 오면 여러 번 번역됨 → 메모리 기반의 중복 방지는 서버가 재시작되면 초기화되어버려서 DB(코멘트) 기반 영구 중복 방지 (the issue has been translated와 같이 번역 완료 댓글을 봇이 달아주고 이 이벤트를 확인)

5. 번역 완료 감지 미흡 → 이미 번역된 것도 다시 번역 시도

그리고 그 외... 'Transaction Fee Modal에서 Priority Fee 설정 시 오류 발생'과 같이 대체로 영어인 경우에는 번역이 되지 않는 이슈가 있었는데 초기 isEnglish() 함수가 아래와 같이 구현되어 있었어서 그랬음. 이를 95%로 변경.

javascript
function isEnglish(text) {
  const englishChars = (text.match(/[a-zA-Z]/g) || []).length;
  const nonEnglishChars = (text.match(/[^\x00-\x7F]/g) || []).length;
  // 영어 비율 70% 이상이면 영어로 판정
  return englishChars / (englishChars + nonEnglishChars) > 0.7;
}

구현 중에 팀원들을 위해 UX상 추가 혹은 변경된 것

• 전체 통으로 번역해서 밑에 붙여넣는 것보다 문단별로 번역해서 문단 밑에 번역된 버전을 붙여주는 것이 서로 이해하는 데에 더 용이하다는 판단, 그래서 문단마다 번역하도록 수정.

• 초기에는 한국어 → 영어만 지원했지만, 영어 → 한국어도 필요해보여서 추가

• 입력 언어 감지를 자동으로 하도록 변경

• 이전에 한→영 번역한 이슈를 다시 번역하면 언어 감지가 달라질 수 있어서 두 가지 확인 메시지를 모두 검사

• 초기에는 티켓 본문 번역기능만 지원했는데 댓글 번역도 필요해보여서 기능 추가 → 이 경우, 댓글이 새로 달리는 게 아니라 반드시 해당 댓글의 대댓글로 번역문이 첨부되도록 구현

그리고 이걸 하면서 깨달은 것) [Debug] 로그가 문제 해결의 핵심이 되므로 반드시 디버깅이 필요해보이는 피쳐들은 디버그 로그에 잘 찍히도록 설계하자...

뭔가 흠.. 역시 나는 결론 쓰는 게 항상 어려운 듯한데 여하튼 특히 디자인 팀원 분이 요즘 번역봇 잘 쓰고 있는 듯해서 그럭저럭 만족.. 임베드 이슈를 끝까지 해결하지 못한 게 좀 아쉽긴 하지만.. 바이브 코딩 초보치고는 나쁘지 않았어(?) 라고 정신승리를 해보며...오늘의 글을 마무리해본다.

다음 글은.. 이제.. 가장 혼신의 힘을 다해서(?) 클로드와 싸워야만 했던 이 블로그 사이트를 만든 과정과... 그리고 웹플로우 permission 설정 같은 자잘한 것들이 생각보다 까다로웠던 웹플로우로 만든 웹사이트들을 쉽게 업데이트할 수 있는 슬랙봇 만들기 과정을 기술해보겠다! 두둥 투비 컨티뉴드~_~