split (자르기)텍스트를 구분자를 기준으로 분리해 배열에 담아 변환구분자에는 문자열 가능, RegExp객체도 가능(But 문자열을 정규표현식으로 간주하지 않음) 옵션인 두번째 매개변수는 반환 받을 배열의 크기를 지정하는 숫자let colorText = "red, blue. green, yello";let colors1 = colorText.split(","); // ["red", "blue", "green", "yellow"];let colors2 = colorText.split(",", 2); //["red", "blue"];let colors3 = colorText.split("[^\,]; // ["",",",",',",",""] *split() 메서드 내의 정규 표현식 지원은 브라우저마다 다르다..

객체지향언어프로퍼티와 메서드를 가지는 객체를 여러개 만든다. 프로퍼티와 메서드는 이름으로 구별하며 값에 대응한다. 객체는 이름-값쌍의 그룹각 값은 테이터나 함수가 될 수 있다. 모든 객체는 참조 타입을 바탕으로 생성한다. 객체를 이해해보자객체를 만드는 가장 단순한 방법Object의 인스턴스를 만들고 프로퍼티와 메서드를 추가하는 방법let person = new Object();person.name = "Nicholas";person.age = 29lperson.job = "Software Engineer";person.sayName = function() { alert(this.name);}; 객체: personname, age, job => 3가지 프로퍼티sayName() => 메서드sayName(..

try { // 에러가 생길 수 있는 코드} catch (error) { // 에러가 생겼을 때 할일}try절에서 에러가 생기면 코드 실행을 즉시 멈추고 catch 절을 실행 catch 절은 에러에 대한 정보를 담은 객체를 받는다. finally 절try-catch는 옵션으로 finally절 사용 가능finally절의 코드는 항상 실행된다. 에러가 없어도, catch절을 실행하더라도 finally절은 실행된다. 에러 반환try catch문의 throw연산자는 언제든 커스텀 에러를 반환 가능throw 연산자에는 반드시 값이 필요하지만 값의 타입에는 제한이 없다.throw 12345;throw "Hello World";throw true;throw {name:"JavaScript"} try 연산자를 사용하면..

프로젝트 주제를 두고 고민하던 중, 거창한 목표를 세우기보다 "우선 내 주변에서 아이디어를 찾아보자"는 생각으로 시작했다. 그렇게 "내가 필요한 걸 직접 만든다"는 단순하지만 확실한 동기가 TiTaS 프로젝트의 출발점이 되었다. 이 프로젝트는 단순한 기능 구현을 넘어 나를 엔지니어로 한 단계 성장시켰다. 기술적으로는 React의 상태 관리 구조를 심층적으로 분석하고, 다양한 브라우저 API를 서비스 환경에 맞게 최적화하는 경험을 쌓았다. 또한, 개발자 관점을 넘어 사용자를 배려하는 UX/UI 설계의 중요성을 몸소 체감했다. 무엇보다 가장 큰 수확은 태도의 변화다. 기술적 제약 앞에서 '안 되는 이유'를 찾기보다, 어떻게든 '되게 하는 방법'을 찾아내는 집요한 엔지니어링 마인드셋을 갖추게 되었다. TiTa..

기능 구현과 버그 수정이라는 긴 터널을 지나고 나니, 문득 화면이 눈에 들어왔다. 기능은 완벽하게 돌아가는데, 어딘가 투박하고 정돈되지 않은 느낌. 마치 골조만 올라간 건물 같았다.사용자가 서비스를 처음 마주했을 때 "써보고 싶다"는 느낌을 받으려면, 탄탄한 코딩만큼이나 직관적인 디자인과 명확한 정체성이 필요하다. 이번 글은 TiTaS가 '돌아가는 코드 덩어리'에서 하나의 '그럴듯한 제품'으로 변모하는 과정에 대한 기록이다. 1. 얼굴 짓기: TiTaS로고Tiki-Taka Script이기에 상대방과 대화하는 느낌이 먼저 떠올랐다. 이름(TiTaS) 속에 알파벳 'T'가 두 번 들어간다는 점에 착안하여, 두 개의 'T'가 서로 마주 보고 대화하는 모습을 형상화했다. 2. UI 변천사: 사용성을 찾아가는 여..

기능 구현과 배포를 마친후 이제는 사용성에 대해서 눈에 들어오기 시작했다. 잠깐 떴다 사라지는 토스트 메시지는 talkpage에서 결과를 확인하기에는 너무 가벼웠고, 기계적인 TTS 목소리는 몰입을 방해했다. 또한 URL을 보낼때 사진과 설명이 없는 주소는 너무 휑하게 느껴졌다. 2%의 아쉬움을 채우기 위해 UX와 디테일 기능을 추가했다. UX 개선: 토스트(Toast)는 결과창으로 적합하지 않다처음에는 연습이 끝났을 때 점수와 결과를 react-hot-toast로 가볍게 보여주었다. 하지만 토스트는 몇 초 뒤 스르륵 사라져 버린다는 치명적인 단점이 있었다. 사용자는 힘든 연습을 마친 후 자신의 성취(정확도, 소요 시간)를 진득하게 확인하고 싶어 한다. 사라지는 메시지는 이런 성취감을 반감시켰다. 연습 ..

MVP 기능 구현을 마치고 배포까지 성공했지만, 실제로 앱을 돌려보면서 발견된 버그와 사용자 경험을 해치는 요소들을 수정하는 데 시간을 쏟았다. 특히 TypeScript의 타입 시스템과 데이터 초기화 시점, 그리고 텍스트 분석의 정교함을 높이는 과정에서 겪은 문제들을 정리해 본다. 1. TypeScript 타입 확장과 Type Guard: WeakSpot에 없는 속성을 써야 할 때Review 페이지에서 틀린 단어를 클릭하면 해당 단어가 포함된 전체 문장(lineContent)을 읽어주는 기능을 추가하려 했다. 그런데 기존에 정의해 둔 WeakSpot 타입에는 문장 정보를 담는 필드가 없었다.단순히 types.ts의 원본 인터페이스를 수정하면 간단하겠지만, WeakSpot은 DB(LocalStorage)에..

핵심 엔진인 STT, TTS, Diff 구현과 그 외 기능을 구현 후 프로젝트가 다 끝난 줄 알았다. 하지만 그것은 착각이었다.막상 직접 사용해보니 브라우저 기본 경고창은 투박했고, 삭제한 데이터는 새로고침하면 다시 살아났다.페이지마다 여백은 제각각이라 시각적으로 불안정했다. 기능적으로는 작동하지만 사용하기에는 불편한, 미완성의 상태였다. 부족한 디테일을 잡기 위해 코드와 씨름했던 시간이었다.1. 토스트 라이브러리 도입과 Stale Closure 문제처음에는 사용자 피드백을 브라우저 기본 기능인 alert으로 처리했다. 하지만 삭제, 저장, 역할 전환 등 인터랙션이 많아질수록 매번 팝업을 띄우는 방식은 사용자 경험을 해쳤다. 그래서 react-hot-toast 라이브러리를 도입해 더 부드러운 피드백을 주..

프로젝트 초기, 나를 괴롭혔던건 다름아닌 CSS 프레임워크 설정이었다. 2025년 현재 최신 버전인 Tailwind CSS v4를 호기롭게 도전했지만, 설정과정은 순탄하지 않았다. 처음엔 당연히 v4를 선택했다. tailwind.confimg.js파일이 사라지고 CSS 파일 하나로 설정이 가능하다는 점이 굉장히 매력적이었다. 첫번째 벽: @theme 문법 에러@theme { --font-family-sans: 'Inter', system-ui, sans-serif; --color-primary: #8b7355;} 개발 서버를 돌렸더니 바로 터졌다. [postcss] Unknown word --font-family-sans 알고 보니 @theme 블록은 Tailwind v4 표준 문법이 아니었다. P..