영타가 느린 개발자가 각 프로그래밍 언어별 빠른 영타 습득을 위해 코드 타자 연습을 할 수 있는 사이트입니다. 낱말연습, 짧은 글 연습, 긴 글 연습을 지원합니다.
프로젝트 페이지로 이동하기 <해당 페이지는 구글 크롬 환경에서 원활히 작동합니다>
- React
- React-Redux, Redux ToolKit
- Redux-Saga
- SCSS
- Firebase
- Electron
- 배포: Netlify
- Express
- MongoDB
- Firebase
- 배포: AWS
- Eslint 및 Prettier 공통 적용
Redux Toolkit
보일러코드가 많다는 점이 기존 redux의 단점인데, 우리 프로젝트는 여기다가 Redux-Saga까지 사용할 예정이었기 때문에 너무 많은 코드가 생성된다는 점이 예상되었습니다. 따라서 간편하게 사용할 수 있는 Redux Toolkit을 도입하였습니다. 결과적으로 코드를 관리하기가 수월하였고, 큰 어려움 없이 상태관리를 할 수 있게 되었습니다.
Redux-Saga
즉 비동기 작업을 동기적인 흐름대로 처리하기 위한 필요성이 있고, 따라서 Redux-Saga를 도입하였습니다. 그동안 사용할 일이 없었던 Generator 문법을 사용하기 때문에 진입장벽이 낮지 않지만, 로직의 흐름이 매우 직관적이고 파악하기 쉽다는 장점이 있어 장기적으로 보았을 때 Redux-Saga를 이용하는 것이 코드를 짜는데 용이할 것으로 판단하였기 때문입니다.
Electron
기술적 도전을 위해, 데스크톱 앱 환경에서도 실행 가능하도록 electron을 도입하였고, 이는 우리의 프로젝트의 성격과도 매우 잘 맞았음을 느꼈습니다. 또한 자바스크립트 언어의 적용 범위가 웹을 넘어 앱으로까지 확장되고 있음을 몸소 체험할 수 있었습니다.
프로젝트 폴더 root 위치에 .env 파일을 만들고 다음과 같이 환경변수를 설정해주어야 합니다.
아래 환경변수들은 firebase 로그인을 위해 필요합니다.
REACT_APP_API_KEY
REACT_APP_AUTH_DOMAIN
REACT_APP_PROJECT_ID
REACT_APP_STORAGE_BUCKET
REACT_APP_MESSAGING_SENDER_ID
REACT_APP_APP_ID
아래 환경변수는 server에게 fetch 요청을 보내기 위해 필요합니다.
REACT_APP_SERVER_URL
아래 환경변수들은 electron 빌드를 위해 필요합니다.
CLIENT_URL
WINDOW_WIDTH
WINDOW_HEIGHT
아래 환경변수는 firebase 로그인을 위해 필요합니다.
SERVICE_SECRET_KEY
아래 환경변수는 cors 정책을 위해 필요합니다.
CLIENT_URL
아래 환경변수는 mongodb 접속을 위해 필요합니다.
MONGO_DB_URL
아래 환경변수는 원활한 테스트코드 진행을 위해 필요합니다.
WEB_API_KEY
로그인
- 구글 계정을 이용한 로그인과 Guest 유저 로그인이 가능합니다.
- 만약 기존에 가입되어있지 않은 유저가 로그인을 시도한 경우 회원가입과 동시에 자동으로 로그인 됩니다.
마이 페이지
- 구글 로그인으로 접속한 경우 마이페이지를 사용할 수 있습니다.
- 유저의 점수와 지난 날의 기록에 기반한 평균 타수와 정확도가 계산되어 조회됩니다.
- 다양한 환경설정을 적용할 수 있습니다.
- 효과음을 설정한 경우 타자소리 및 문제의 맞고 틀림에 따른 소리가 출력됩니다.
- 특정 언어를 선택한 경우, 헤당 언어의 기록이 표시됨과 동시에, 해당 언어의 문제를 풀 수 있습니다.
- 문제 개수 설정을 통해 원하는 개수 만큼의 문제를 풀 수 있습니다.
- 색약 유저인 경우 색약 모드를 설정하면 다른 색상으로 문제가 표시됩니다.
- 지난 날의 기록 (짧은 글, 긴 글)이 최신순으로 표시됩니다.
- 푼 문제 유형, 날짜, 타속, 그리고 정확도를 조회할 수 있습니다.
낱말연습
- 각 언어별 사용되는 키워드 및 예약어 낱말을 타자연습 할 수 있습니다.
- 맞고 틀림에 따라 색깔이 다르게 표시됩니다.
- 정확도, 오타수, 진행도가 표시됩니다.
- 낱말연습이 모두 끝난 경우 모달 창을 통해 결과를 확인할 수 있습니다.
짧은 글 연습
- 각 언어별 코드 한 문장을 연습할 수 있습니다.
- 맞고 틀림에 따라 색깔이 다르게 표시됩니다.
- 현재 타수, 현재 정확도, 누적 정확도, 진행도, 획득 점수가 표시됩니다.
- 현재 타수는 다음과 같은 공식에 의해 구해집니다. $$ {현재 타수} = \frac{{옳게,입력한,글자,수} - {Backspace,입력,횟수}}{분}$$
- 현재 정확도는 다음과 같은 공식에 의해 구해집니다. $$ {현재 정확도} = \frac{전체,글자,수 - 틀리게,입력한,글자,수}{전체,글자,수}$$
- 옳은 문장 하나를 완성할 때마다 3점을 획득할 수 있습니다.
- 짧은 글 연습이 모두 끝난 경우 모달 창을 통해 결과를 확인할 수 있습니다.
긴 글 연습
- 각 언어별 긴 코드 문장을 연습할 수 있습니다.
- 맞고 틀림에 따라 색깔이 다르게 표시됩니다.
- 현재 타수, 현재 정확도, 누적 정확도, 진행도가 표시됩니다.
- 현재 타수는 다음과 같은 공식에 의해 구해집니다. $$ {현재 타수} = \frac{{옳게,입력한,글자,수} - {Backspace,입력,횟수}}{분}$$
- 현재 정확도는 다음과 같은 공식에 의해 구해집니다. $$ {현재 정확도} = \frac{전체,글자,수 - 틀리게,입력한,글자,수}{전체,글자,수}$$
- 모두 옳게 타이핑 한 경우 10점을 획득할 수 있습니다.
- 긴 글 연습이 모두 끝난 경우 모달 창을 통해 결과를 확인할 수 있습니다.
게스트 로그인 모드가 추가된 이유
따라서 electron 환경을 세팅한 뒤, 빌드까지 마치고 프로그램을 실행시켰는데, firebase가 제대로 동작하지 않았습니다. 원인을 파악해보니 electron은 firebase의 auth 기능을 지원하지 않는다는 점에 있었습니다.
우리의 프로젝트 작품은 로그인이 수행되어야만, 그 이후의 모든 기능을 사용할 수 있었기 때문에, electron으로 빌드된 프로그램은 아무런 기능도 수행할 수 없었습니다.
따라서 해결방안을 생각해야 했습니다.
로그인 방식을 firebase에서 다른 방식으로 바꾸기에는 프로젝트 일정 마감까지 얼마 남지 않았기 때문에 부담이 너무나 컸습니다.
그렇다고 로그인 기능을 완전히 제거하거나, 기껏 세팅해놓은 electron을 완전히 배제할 수도 없었습니다.
결과적으로 생각한 방법은 게스트 로그인이었습니다.
firebase를 거치지 않고 로그인하는 방법으로, 일종의 체험판 같은 느낌으로 진행되도록 하였습니다.
이것이 아주 완벽한 해결방법은 아니겠지만 제한된 여건 하에 요구사항을 모두 만족시킨 경험을 할 수 있었습니다.
색약모드가 추가된 이유
그 중 한 동료로부터 타자 검정시 옳고 틀림을 구분하는 색상이 잘 분간이 되지 않는다는 피드백을 받았습니다. 알고보니 그 동료는 적록색약이 있었는데, 우리의 디자인은 연두색과 분홍색을 사용했기 때문에 발생한 일이었습니다. 따라서 마이페이지 내 색약모드 기능을 추가했고, 이를 설정한 경우 연두색과 분홍색이 파란색과 노란색으로 색상이 변경되도록 하였습니다
스키마 설계의 중요성
데이터베이스의 스키마 설계는 아주 신중해야 한다는 말을 들었지만, 프로젝트를 기획할 때 이 점에 대해서는 매우 부족했습니다. 클라이언트는 서버에게 원하는 언어와 문제 타입에 대한 요청을 보내면, 그 요청에 대한 것만 응답을 받아야 하는데, 스키마 설계의 결함으로 인해 요청을 보내지 않은 정보들도 모두 불러와졌습니다. 따라서 원하는 값들만 따로 추출할 필요성이 생기게 되었고, 이는 불필요하고 복잡한 코드의 결과로 나타났습니다.
결국 기존 스키마를 모두 뒤엎고, 다시 스키마를 작성하였습니다. 그리고 백엔드 및 프론트엔드 로직 모두를 다시 수정했습니다. 그 결과 기존과는 비교할 수 없을 정도로 프론트 및 백엔드 로직이 간소화되고 효율적으로 바뀌었습니다.
스키마 설계에 좀만 시간을 들였다면, 프로젝트 기간 중 이런 불필요한 과정은 존재하지 않았을 것입니다. 결과적으로 스키마 설계에 많은 시간을 들이는 것은 결고 시간낭비가 아님을 깨닫게 되었습니다. 오히려 잘못된 스키마로 인해 코드가 복잡해지고, 추후에 이를 복구하는 과정에서 발생하는 시간적 손실이 압도적임을 몸소 체험하며 느꼈습니다.
강민성
그 중 한 분으로부터 타자 검증시 옳고 틀림을 구분하는 색상이 구분이 되지 않는다는 피드백을 받았습니다. 저희의 디자인은 연두색과 분홍색을 사용했기 때문인데, 이쁘면 그만이지라는 마인드로 색에 대한 감각이 좋지 못한 분들까지 생각을 못했었습니다. 내부 회의 결과 발표 날짜까지 얼마 남지 않았지만, 시간을 좀 더 쓰면 이 부분은 추가해볼만한 기능이라고 생각해 그날 바로 작업에 착수 하였고, 모든 색약에 대응 하지 못했지만 적록 색약부분에 대한 처리는 하였습니다. 사실, 이런 경험은 처음이라 이런 기능을 추가하는 것 자체가 유저에게 편의성을 제공하는 것인지, 차별을 만드는 것인지에 대한 생각이 들기도 했습니다. 사용자 피드백은 고객이 직접 자신의 시간과 공을 들여 만들어주는 고 관여 데이터입니다. 이런 특성 탓에 사용자 피드백은 우리 서비스를 사용자의 시각으로 바라 볼 훌륭한 기회를 제공해줬습니다. 사용자의 입장에서 그들을 공감하려는 시도는, 서비스 개선 측면에서 가치있는 정보를 찾아내는데 큰 도움이 된다 생각합니다. 반면, 한 명 한명의 피드백이 정규분포상의 어디쯤에 위치하는 의견일지, 성급한 일반화를 하는 것은 아닌지 늘 경계도 필요하다는 생각도 들었습니다. 아무리 고객의 입장이 되어보고 공감을 통해 제품을 관통하는 통찰을 찾아냈다 하더라고 팀 내에 적절하게 공유되어야 진정한 가치가 있다고 생각합니다. 이번 플젝을 통해서 개발 기술적인 면은 물론 이런 좋은 경험도 할 수 있게 되어 너무 재밌었고 이러한 기회를 마련해주신 켄님과 멘토님들 그리고 12기 여러분 모두에게 감사의 인사를 드립니다.
유동하
협업 과정을 통해 많은 것을 배울 수 있었는데, 그 중 가장 중요하다고 느낀 것은 바로 코드리뷰라고 생각합니다. 사람은 완전한 존재가 아니라고 생각하기 때문에, 누군가가 나의 실수를 잡아주고 교정해주는 과정, 그리고 더 나은 방향을 제시해줄 수 있는 과정이 코드리뷰라고 느꼈습니다.
일정이 너무 바빠서, 혹은 딜레이가 되어서 정신 없어서 코드리뷰를 제대로 하지 못한 순간이 꽤 있었습니다. 돌이켜 생각해보니, 코드 리뷰를 제대로 하지 못해 문제가 있는 코드가 메인 브렌치에 merge 되어 나중에 이를 바로잡는데 더 많은 시간이 쓰였던 것을 생각해보면, 코드 리뷰하는 시간이 결코 아깝지 않은 시간임을 깨닫게 되었습니다.
코딩을 할 때 기획, 설계, 검토하는 과정을 결코 시간 낭비로 여겨서는 안 된다는 것을 절실히 느꼈습니다. 꼼꼼함이 부족할 수록, 추후에 발생하는 문제를 해결하는데 더 많은 시간이 들어간다는 사실을 크게 배웠습니다.
앞으로 협업 작업을 할 때 양질의 코드를 위해, 저런 과정 하나하나를 소홀히 여기지 않는 개발자로 거듭나도록 할 계획입니다.
최현오
프로젝트 아이디어 기획부터 계획, git 관리, 구현 기능 분배, 배포까지 모두 다 직접 누구의 도움도 없이 팀원들과 함께 계획을 세우고 진행해야되는 부분이라 처음에는 많이 막막하고 어떻게해야될지 몰랐었는데, 팀원들과 소통을하고 제가 모르는 부분들은 도움을 주면서 저도 빠르게 적응해서 열심히 프로젝트를 진행할 수 있었습니다.
프로젝트가 계획대로 잘 진행되고 있는 상황에서 제가 긴 글타자 기능 구현을 맡으면서 기능 구현에 어려움이 있었습니다. 깔끔한 긴 글 타자 연습기능을 만들기 위해 계속해서 코드를 구현하고 수정하고 한 결과, 시간이 조금 걸렸지만 최대한 계획한 방향으로 기능을 구현할 수 있었습니다.
이런 기능 구현 업무를 맡아 하면서 느낀 점은 팀원들에게 피해가 가지않게 맡은 부분에 있어서 책임감을 가지고 끝까지 해결할 수 있는 능력이 필요하다고 느끼게 되었고, 기능 구현에 성공했을 때의 성취감도 느낄 수 있었습니다. 또한 회사에서도 매 프로젝트마다 기능구현을 맡아서 업무를 수행해야할텐데 계획에 차질없이 정확하게 기능이 구현될 수 있도록 코드를 작성할 수 있어야한다는 것을 깨달았습니다.
팀원들과 만든 타자기능 웹사이트를 배포를 하고 저희 프로젝트 사이트를 다른 동기분들에게 공유하여 피드백을 받아 필요한 기능을 추가해보았습니다. 피드백으로 타자연습에서 색깔이 나오는 부분에 있어서 ‘적록색약을 가지고 있는 사람들을 위해서 색깔 변경 모드가 있으면 좋겠다’ 라는 의견을 받았었는데 정말 뜻 깊은 의견이라고 생각했습니다. 그 이유는 저희가 프로젝트를 만들면서 어떻게보면 당연하다고 생각하고 누구나 이 색깔로 타자치는 부분이 맞고 틀림을 판단할 수 있을 거라 생각하였는데, 이런 피드백과 같은 부분을 개발자들은 세세하게 신경쓰고 유저들의 입장에서 개발하는 자세를 가져야 된다는 것을 깨달았기 때문입니다.
팀원들과 기획부터 배포까지 같이 하면서 많은 부분들을 배우고 경험할 수 있는 의미있는 첫 팀프로젝트였고, 이런 경험을 할 수 있게해준 팀원들과 바닐라코딩에도 감사의 인사를 전하고 싶습니다.