청년
개발자
외길
프론트

1. 프로젝트 중 백엔드 팀원의 이탈
백엔드 서버 및 모든 API를 쓸 수 없게 되었을 때는 막막하였습니다. 급하게 오라클 인스턴스를 추가, 당장 본인이 강한 언어는 JavaScript 였기에 Express로 서버를 구현하고 DB를 설정하였습니다. 5일의 기간 내에 이전 API들을 동일하게 구현할 수 있었고 이후 프론트엔드, 백엔드를 병행해야 했지만 원하던 기능들을 모두 구현할 수 있었습니다.처음으로 팀원의 부제 잠시 혼란스러웠지만 어플리케이션 필수 기능들을 직접 설계 하였기에 유연하게 대응할 수 있었습니다. 서버를 구현하며 데이터를 처리 시점에 대한 깊은 고민을 하며 대처능력과 데이터 핸들링 역량을 기를 수 있었습니다.

2. 안정적이지 않은 라이브러리
Native에는 아직 안정적인 리치텍스트 에디터가 없어, tip-tap을 기반의 10-tap 라이브러리를 선택하였습니다. 그러나 사용 과정에서 여러 가지 문제점이 있었고 그 중 크게 2가지가 발목을 잡았습니다.지원되지 않는 기능의 경우 직접 WebView 코드를 tip-tap의 문서와 비교를 통해 적용할 수 있었으나 네이티브 환경에서 렌더링 된 에디터가 준비 상태로 변하지는 않는 고질적인 문제가 남았습니다. 라이브러리 코드 내에서는 해결이 어려워, React에서 렌더링 상태를 지속적으로 확인하고 가장 빠른 시점에 재렌더링을 수행하는 방식으로 문제를 해결했습니다.목표 기능에 미치지 못한 상태로 타협하려는 순간도 있었지만, GitHub 이슈를 참고하며 스스로 해결할 수 있을 것이라는 확신을 가지고 시간을 투자한 끝에 목표 기능을 구현하며, 큰 성취감을 느낄 수 있었습니다.

3. OpenAI 토큰
Ai 대화에서는 비용적인 면을 고려하여 GPT 4.1 mini 모델을 선택하였으나 생각 이하의 성능을 보여주며 자연스러운 대화가 힘들었습니다. 비용과 성능의 최적화를 원했기에 관련한 키워드들을 검색하던 중 한글은 토큰이 글자 수에 비례하여 비용이 더 많이 발생하고 복잡한 지시의 경우 제대로 적용되지 않는 다는 것을 알 수 있었습니다.프롬프트를 영문으로 작성하여 토큰을 단어 단위로 줄임과 동시에 gpt가 학습된 원어이기에 '3번이상 동일주제 질문금지', '친절한 존댓말 한국어' 등과 같은 복잡한 지시도 영문일 때 가장 높은 성능을 보여주었습니다.

1. 개선 프로젝트
Nashda 프로젝트를 진행하며 Notion, Jira와 같은 협업 툴을 사용했지만, 기능이 복잡해 팀원 모두가 해당 툴에 익숙해져야만 제대로 활용할 수 있다는 한계를 느꼈습니다. 이에, 아무런 사전 지식이 없어도 직관적으로 사용할 수 있는 협업 툴을 만들고자 개선 프로젝트를 진행했습니다.프로젝트 중반 이후에는 완성된 협업 요청 탭을 통해 실제 협업이 활발히 이루어졌고, 이를 보며 큰 성취감을 느낄 수 있었습니다.

2. 협업 기능 개선
Quill 라이브러리는 웹소켓을 통해 실시간 협업이 가능하지만, 사용자의 활동을 추적하기 어려웠습니다. 이를 해결하기 위해 라이브러리의 유저 데이터 수정 코드를 활용하여 다음 기능을 직접 구현했습니다.  a. 사용자가 데이터를 수정하는 시점 실시간 추적
  b. 접속 및 이탈 여부 체크
  c. 수정 중인 영역을 다른 사용자가 동시에 수정할 수 없도록 잠금
  d. 사용자가 수정 중인 위치에 마크 표시라이브러리에서 지원하지 않는 기능을 처음으로 직접 구현하면서, 단순히 제공된 기능을 사용하는 것을 넘어 목표한 기능을 스스로 구현할 수 있다는 자신감과 역량을 키울 수 있었습니다.

3. 1인 프론트엔드 경험
6인 팀에서 홀로 프론트엔드를 맡게 되었을 때, 프로젝트 초반에는 많은 어려움이 있었습니다. 첫 번째는 아이디어 제안자로서 다양한 기능의 방향을 제시해야 했고, 처음 구현해 보는 팀원에게 예시 코드를 제공해야 했습니다. 두 번째는 완성된 API 테스트 요청이 동시에 몰리면서 우선순위 설정에 어려움을 겪었습니다그러나 프로젝트 중반 이후, 지속적인 스크럼과 문서화 요청을 통해 정리된 형태의 요청을 받게 되면서 개발 속도가 크게 향상되었습니다.이 경험을 통해 여러 태스크가 동시에 발생할 때 우선순위를 정하는 방법과 문서화의 중요성을 깊이 깨달을 수 있었습니다.

1. 첫 React 사용
팀원의 권유로 React를 처음 도입하며, 강력한 기능만큼 최적화를 요구하는 특성 때문에 일정한 학습이 필요했습니다. 초반에는 프롭 드릴링, 불필요한 재렌더링, 마운트 과정 등에서 어려움을 겪었지만, 다양한 최적화 기법을 익히고 적용하여 문제를 해결했습니다.React의 가상 DOM과 컴포넌트 구조를 이해하면서, 사용자에게 더 다양한 방식의 인터랙티브한 경험을 제공할 수 있게되어 프로젝트에 큰 만족감을 느꼈습니다.

2. 방대한 라이브러리와 커뮤니티
React는 방대한 라이브러리를 갖추고 있어 많은 기능을 직접 구현하지 않고도 라이브러리를 활용해 구현할 수 있었습니다.예를 들어, 차트 생성이나 입력된 음성 데이터의 파형 시각화 같은 기능은 라이브러리를 통해 쉽게 구현할 수 있었습니다. 다만, 문서를 충분히 확인하지 않으면 최적화 문제나 원하는 형태로 적용하기 어려운 경우도 있었습니다.이를 극복하기 위해 공식 문서와 GitHub 이슈를 적극적으로 참고하며 목표 기능을 구현했고, 그 과정에서 능동적으로 문제를 해결하는 역량을 키울 수 있었습니다.

1. 데이터 연동
해당 프로젝트는 게스트 모드와 사용자 모드 두 가지 환경을 지원하기에 게스트 환경에서 작성된 콘텐츠를 사용자가 로그인했을 때 계정에 자연스럽게 반영하는 동기화 알고리즘이 필요했습니다. 여러 접근 방식을 고민하던 중, 자주 사용하는 Git의 commit 기록 방식에서 아이디어를 얻어 각 DB에 데이터 변동 이력을 기록하고, 존재 여부와 업데이트 시점을 비교하여 최신 상태를 유지하는 알고리즘을 구현했습니다.단순한 프론트엔드 렌더링이나 백엔드 API 구현과 달리, 이 과정에서는 데이터 동기화 문제를 직접 다뤄야 했습니다. 이를 통해 평소 익숙하게 사용하던 프로그램의 동작 원리를 깊이 이해할 수 있었고, 알고리즘 학습의 필요성과 중요성을 체감할 수 있었습니다.

2. 더블클릭
브라우저 기본 동작으로 단어를 더블클릭하면 단어 뒤의 **공백(trailing space)**까지 함께 선택되는 문제가 있었습니다. 그러나 제가 구현하려던 기능에서는 단어만 정확히 선택되어야 했습니다.
관련 자료를 찾아보았지만 이 문제를 다루는 사례가 거의 없어, 직접 해결책을 고안했습니다.  a. 단어 선택 전에는 selection 색상을 투명하게 유지
  b. 선택 시 trailing space 포함 여부를 판별 후 제거
  c. 수정된 selection에 다시 색상을 적용이 과정을 통해 사용자는 선택 영역이 바뀌었다는 인식 없이 자연스럽게 단어만 선택할 수 있게 되었습니다.개발 중 문제가 발생하였을 때 다른 개발자들은 문제 삼지 않는 경우가 있으면 굉장히 당황스러웠습니다. 하지만 본인이 처음이 되어 해당 문제를 원하는 목표에 맞춰 해결하는 과정을 통해 언어를 더 깊게 이해하고 해결 능력을 키울 수 있는 좋은 기회가 되었습니다.