이번 성장일지는, 아직 개인적으로 많이 준비하지 못했지만 그래도 '리셋'이라는 프로젝트에 참여하면서, 관련하여 혼자 고민하고 준비했던 내용들을 정리해보려고 한다. 중요도의 여하를 떠나 아주 사소한 조각의 고민들이라 부끄럽지만, 그래도 정리하면서 마음가짐도 긍정적인 리셋도 되기를 바라며 작성해본다.
혼자서 머리를 싸매며 부딪혔던 문제들과, 그 안에서 나름대로 찾아낸 답들을 기록해본다.
# 감정 기록, '언제'의 문제
우리 앱에서 가장 기본이 되는 기능 중 하나가 바로 감정을 기록하는 일이다. 이 기능을 어떻게 가져갈지 처음부터 고민이 많았다.
나의 초기 생각:
처음에는 감정 기록 빈도수를 하루에 한 번으로 제한할까, 아니면 수정을 허용해야 할까를 두고 고민했었다. 그런데 아무리 생각해도 나 스스로의 변덕스러운 성향을 떠올려보면, 하루 한 번만 기록하게 하는 건 너무 제한적인 방식이라는 생각이 들었다. 사용자 입장에서 보더라도, 감정은 순간순간 바뀌는 건데 하루 한 번으로 고정한다는 건 현실과 맞지 않는 방향이라는 결론이 들었다. 그래서 감정 기록의 수정이 가능하도록 하는 방향을 제안하게 되었다.
새로운 고민:
수정이 가능하다고 결정하니, 또 다른 문제가 떠올랐다. 처음에는 그냥 recorded_at이라는 하나의 필드로만 관리하면 될 줄 알았다. 하지만 곰곰이 생각해보니 나중에 사용자가 감정을 수정하게 될 수도 있고, 그럴 경우 '처음 기록한 시점'과 '마지막으로 수정한 시점'을 구분해야 할 필요가 있겠다는 걸 알게 되었다.
나의 결정:
결국, 다음과 같은 방향으로 정리했다:
- recorded_at: 처음 감정을 기록한 시점 (이 값은 변하지 않아야 한다고 판단했다.)
- updated_at: 마지막으로 수정된 시점 (수정이 발생할 때마다 갱신된다.) 이렇게 필드를 나눠서 관리하는 것이 현재로서는 가장 현실적인 방안이라고 판단했다.
# 감정 목록, 코드성 데이터로 관리할까?
'좋음', '보통', '나쁨' 같은 기본 감정 데이터는 어떻게 데이터베이스에 넣어야 할지 고민이 됐다.
나의 초기 생각:
처음엔 그냥 공통 코드 테이블(tb_code)에 넣는 게 맞다고 생각했었다. 우리 회사 도메인에서는 tb_code 안에서 코드 데이터를 몰아서 관리하는 방식이 익숙했고, 워낙 데이터 양도 많다 보니 그렇게 된 것을 자연스럽게 그런 방식이 당연하다고 여겼다. 게다가 이 방식은 처음에 지인이 조언해준 아이디어이기도 해서, 어느 정도 받아들였던 부분이다.
새로운 고민:
하지만 다시 앱의 기획 흐름을 살펴보고, 우리 앱의 목적을 떠올려보니 이 방식이 꼭 맞는 건 아닐 수도 있겠다는 생각이 들었다. 감정마다 emoji나 level이 붙고, 나중에는 진단용/회고용 같은 context 구분도 생길 수 있기 때문에 단순한 코드 관리로 보기엔 무리가 있을 수 있었다.
나의 결정:
그래서 지금은 감정은 emotions라는 별도 테이블로 구조화하는 방향(기존의 방향)이 더 적절하다고 판단했다. 이렇게 하면 추후 감정별 통계, 분석, 추천 같은 기능을 붙이기에도 훨씬 유연할 것이라고 예상했다.
# 감정 기록 로그에 대한 고민
'로그'라는 개념에 대해 회사에서 익숙했던 경험과 앱의 목적 사이에서 고민이 있었다.
나의 초기 생각:
회사에서는 보통 로그는 그냥 이벤트 로깅의 의미였다. 그냥 다 쌓아두고, 이슈가 발생했을 때 로그를 추적해서 원인을 찾는 데 주로 쓰였다. 그래서 처음엔 "이건 PK 없어도 되는 거 아닌가?" 라는 생각까지 들었었다.
새로운 고민:
그러나 기획의도를 다시 살펴보면서 앱에서는 그 로그들이 단순 이벤트가 아니라, 나중에 데이터 분석이나 일/주/월 단위의 리포트에 활용될 수도 있다는 점을 고려하니, PK(Primary Key)는 꼭 있어야 할 것 같았다. 각 기록이 고유하게 식별되어야 의미 있는 분석이 가능하기 때문이다.
또 하나의 고민:
PK를 부여한다고 결정하고 나니, 또 하나의 고민이 생겼다. "수정이 생길 때마다 이력을 따로 저장해야 할까?" 즉, 감정 기록에 대한 모든 변경 이력을 남길 것인가 하는 문제였다.
나의 결정:
지금 시점에서는 모든 감정 수정 이력을 다 남기는 건 구조를 너무 무겁게 만들 수도 있다고 판단했다. 그래서 일단은 recorded_at과 updated_at 두 필드로 충분하다고 판단하고 있다. 이후 정말 필요한 상황이 생겨서 더 상세한 이력 추적이 요구되면, 그때는 감정 이력용 별도 테이블을 만들고 관리하는 방향으로 천천히 확장해보려고 한다.
# 더 사소한 고민들
사실 이 외에도 이런저런 사소한 고민이 많았다.
- 기획 의도에서 단어 하나가 주는 뉘앙스가 사용자 공감도를 떨어뜨리진 않을까?
- 감정을 입력받는 슬라이드 방식이 UX적으로 정말 괜찮은 걸까? 오히려 번거롭게 느껴지진 않을까?
이런 고민들이 정말 사소한 것 같지만, 하나하나 직접 부딪히고 생각하다 보니 나름대로 재미도 있고, 이제 진짜 개발을 '잘'해야 하는 지금, 지금껏 해왔던 고민들을 토대로 나도 조금씩 더 나아지고 있다는 생각이 든다. 무언가를 만들어나간다는 건, 이렇게 작은 물음표 하나하나를 끌어안고 가는 일이 아닐까 싶다. 여전히 foundation은 부족하지만 그 물음표들이 하나씩 느낌표로 바뀌는 과정을 잘 담아보고 싶다.