D'story

오늘 한 일

• 어제 받아온 숙제를 시작했다. React-admin의 튜토리얼을 완료했다. 튜토리얼을 진행해 본 지금도 이런 패키지가 존재한다는 게 도저히 믿기지가 않는다. 게시판 당연히 가내수공업인 줄 알았는데!? 소름 돋는다.
• 코드 몇 줄이면 CRUD가 가능한 게시판이 그냥 만들어진다. 아이콘 넣고, 링크 언더라인 빼고, 이런 기본적인 커스터마이징은 물론이고 반응형으로까지 제작 가능하다. 이쯤에서 터지는 헛웃음

오늘 배운 것

• React-admin 튜토리얼 링크를 첨부한 거지만, 이 중에서도 특히 Optimistic Rendering And Undo 부분이 인상 깊었다. 리덕스로 상태 관리할 때 리듀서에서 서버를 통하지 않고도 변화를 주는 것과 비슷하다고 생각했다. 데이터를 변경한 후, 변경한 데이터를 서버에 보내기 전에 일단 보여준다. 데이터 변경 후 5초 안에 사용자가 Undo를 누르면 원래대로 돌려놓고, 별다른 입력이 없으면 5초가 지났을 때 서버와 통신해 실제 데이터를 업데이트한다. 생각해 본 적 없는 방식이어서 신선했다.

내일 할 일

• 내일은 저어엉말 오랜만에 나들이를 다녀올 생각인데, 만약 집에 돌아와서 저녁이나 밤 시간에 여유가 있으면 React-admin 커스터마이징을 해보겠다.

SSR(Server Side Rendering)

클라이언트가 데이터를 요청하면 브라우저 > 프론트 서버 > 백 서버 > 데이터베이스를 거쳐서 데이터베이스에서 데이터를 가져온 후 브라우저에 그려지는 방식.

서버에서 데이터까지 모두 포함하여 페이지를 구성한 후 브라우저에 전달하므로, 불필요한 부분까지 모두 다시 렌더링해야 한다는 단점을 가진다.

CSR(Client Side Rendering)

데이터를 제외한 화면을 그리는 코드들은 프론트 서버에, 데이터는 따로 백 서버에 요청하여 받아오는 방식.

서버 부하가 덜하다는 장점이 있는 반면, 번들된 JS 파일의 다운로드로 인해 초기 로딩이 길고 SSR에 비해 SEO에 약하다는 단점이 있다.

Next.js

첫 페이지는 SSR 방식으로 백 서버에서 렌더링해서 데이터가 채워진 html을 받아오고, 그 다음 페이지부터는 CSR 방식으로 필요한 데이터 부분만 갱신하는 방식.

여담

• 예전에 프로젝트 할 때 한번 찾아본 내용이었는데, 오늘 본 면접에서 잠깐 언급된 김에 다시 정리해보았다.

참고

margin

border를 경계로 하는 바깥쪽 여백을 의미한다.

두 개 요소의 margin 속성이 겹쳐지면 둘 중 큰 값이 적용된다(여백 상쇄).

padding

border를 경계로 하는 안쪽 여백을 의미한다.

부모 div에 padding 속성이 적용된 상태에서 콘텐츠 영역 안에 있는 자식 요소에 position: absolute, top: 0을 준다면, padding까지 부모 div의 면적으로 인식하고 padding을 무시하게 된다. 결과적으로 자식 요소는 부모의 padding이고 뭐고 맨 위에 붙어버리게 되는 것이다. 부모 div의 padding을 무시하지 않는 한도 내에서 자식 요소를 맨 위로 붙이고 싶다면, 부모 div에 padding을 주는 대신, 자식 요소에 margin을 주는 것이 낫다.

참고

setTimeout

일정 시간이 지난 후에 함수를 호출한다.

useEffect(() => {
	setTimeout(action, 1000);
}, []);

const action = () => {
	console.log('action!!!');
};

페이지 로드 시 1000ms가 지난 후 action 함수가 실행된다.

setInterval

일정 시간의 간격을 두고 주기적으로 호출한다.

따라서 함수 호출을 중단하기 위해서는 clearInterval을 사용해야 한다.

 const [number, setNumber] = useState(0);
 
 let start = 0;
 let end = 100;
 let timer = setInterval(() => {
   start += 1;
   setNumber(start);
   if (start === end) {
     clearInterval(timer);
     return;
   }
 }, 0);

start가 0에서부터 0ms의 간격으로(아주 빠르게) 1씩 증가하는데, 100이 되면 clearInterval이 실행되며 멈춘다.

참고

오늘 한 일

• 대충만 써야겠다... 너무 피곤하다 지금ㅎㅎㅎㅎ
• 면접이 오후 3시에 하나뿐인 날이라 아예 늦게 일어날 생각으로 아침에 눈을 떴는데도 안 일어나고 밍기적대고 있었다. 그때 지난 월요일에 화상 면접을 봤던 회사에서 오늘 직접 볼 수 있냐고 연락이 왔다. 1시쯤으로 잡히면 좋았겠는데, 1시에는 일정이 있어서 안되고 2시에만 가능하다고 하셨다. 3시에 면접이 있어서 오래 걸리면 안될 것 같다고 말씀드렸더니 30분이면 충분하다고 하셨다. 그리고 결과적으로는...
• 아무튼 줌으로 한 번 봤을 뿐인데 이미 엄청 잘 아는 사이 같은 느낌이었다ㅋㅋ 해야 할 프로젝트들이 어떤 게 있는지 설명을 듣는 것도 재미있었다. 설명을 쭉 하시다가 잠깐 멈칫 하시더니 일이 너무 많아서 오기 싫은 거 아니냐며 걱정도 하셨다. 뭐, 양적으로 많을 것 같은 건 사실이지만 새로운 도전과제가 생기는 느낌이라 동기부여가 잘 될 것 같았다. 일도 없는 것보다는 많은 게 훨씬 낫기도 하고.
• 두 번째 면접은 민망하게도 10분 가량 늦고 말았다ㅠㅠ 너무 아무렇지 않게 괜찮다고 하셔서 더 죄송했다. 우리 팀 실전 프로젝트 토크부트를 놓고 이것저것 질문을 하셨는데, 알고 보니 공동대표이시면서 프론트엔드 개발자이셨다...! 그렇다면 코드나 UI 쪽도 더 날카롭게 뜯어보셨을 것 같았다. 그리고 나는 코드의 완성도에 비해 인프라 지식이 부족한 사람이 되었다ㅠㅠ 내가 대답을 버벅이자 대신 설명을 해주셨는데, 쉽고 일목요연하게 풀어 말씀하시는 걸 듣고 나는 유치원생이 된 기분이었다. 브라보 개발하다가 모르는 게 있으면 편하게 연락해도 된다고까지 말씀해주셔서 감동이었다ㅠㅠ 제가 감히 그래도 되는 걸까요...

내일 할 일

• 연휴니까 쉬어야지. 쉬면서 개발하자. ^^

오늘 한 일

• 어제 잠들기 전에 누워서 생각한 바로는 오늘 조금이라도 일찍 일어나서 자료라도 조금 더 찾아 읽어보고 여유롭게 하루를 시작하자는 거였는데. 99일간 두문불출하며 컴퓨터 앞에만 앉아 있다가 어제 그거 조금 밖에서 걸어다녔다고 종아리가 땡기고 난리가 났다. 그래서인지 딱 밥 먹고 준비해서 나갈 시간 정도만 있을 때 눈을 겨우 뜰 수 있었다. 어제 아주 늦게 잔 것도 아닌데 이렇게나 많이 자다니ㅠㅠ 백신은 주변 사람들이 맞는데 아프기는 내가 대신 아픈 것 같은 기분이다.
• 첫 번째 면접을 본 회사에서는 어제처럼 프로덕트에 대한 브리핑을 들었다. 나 여기 취직 안 돼도 이거 나오면 써야지... 적용 중인 기술 스택 상, 개발에 참여하려면 어느 정도의 공부가 선행되어야 하는 환경이었지만, 그 자체가 나한테는 너무 좋아보였다. 어쨌든 조만간에 공부를 시작하려고 했던 것들이었고, 아니 그런데 마침 여기서 그걸 쓰신다고요!? 그리고 그건 당장 지금 개발 중인 서비스 하나에 국한된 얘기가 아니라, 그냥 여기서라면 일과 공부에 파묻혀서 살 수 있을 것 같았다. 면접 자체도 즐거웠다. 나는 아무래도 다른 것보다도 회사 분위기를 중요한 기준으로 삼는 것 같다.
• 두 번째 면접을 본 회사는 운영 중인 서비스를 봤을 때는 앞의 회사보다는 조금 더 나아간 단계였다. 이미 출시된 어플의 서비스를 유지하고 이제는 웹으로 영역을 확장해 나가려는 상황이었다. 개발자는 굳이 서비스의 필요성에 공감까지 해줄 필요는 없다고 말씀하시긴 했지만, 그래도 어느 정도 내가 애착을 느낄 수 있어야 스스로 좀 더 관심을 가질 것 같은데 그런 부분에 있어서는 나랑 회사의 서비스가 아주 잘 맞지는 않았다. 그리고 또 현재 돌아가는 서비스 자체는 어플이다 보니 네이티브를 선호하는 회사인 것 같아서 이력서를 넣을 때부터 고민을 좀 하긴 했었다. 아무튼 감사하게도 면접에까지 불러주셔서 좋은 경험을 할 수 있었다.

내일 할 일

• 남은 면접도 무사히 보고 집으로 갑시다.

오늘 한 일

• 아침 8시 30분 기차를 타고 서울에 올라왔다. 이른 점심을 먹고 오후에 두 번의 면접을 봤다.
• 첫 번째 면접에서는 기술 질문이 많았다. 기술 질문 중 절반 정도는 node.js나 spring에서 다루는 백엔드 기술 스택에 관한 내용이었고, 나머지 절반이 자바스크립트에 대한 것들이었다. 면접 제안이 오기 시작할 때쯤부터 자바스크립트에 대해 내가 모르는 게 너무 많다는 걸 인지하고 공부를 하기 시작했는데, 질문의 키워드들은 그때 다 한 번쯤은 구글링하고 정리해둔 기본적인 것들이었다. 그런데 왜였을까, 머릿속에 있는 내용들이 말로 풀어지지가 않았고 말을 하다가도 꼬여서 실수 연발이었다. 왜긴 왜야, 공부가 부족해서지.
• 내 스스로 깊이 실망한 채로 잠깐 숨 돌리고 참석한 두 번째 면접에서는 회사의 서비스, 사업 진행 방향, 기업 문화 같은 것들이 주요한 주제였다. 주로 내가 브리핑을 받았고, 지금까지 진행되어 온 과정들을 눈으로 볼 수 있었다. 항해에서 프로젝트 기획하던 것과 크게는 다르지 않은 방식이어서 오히려 편하고 익숙했다. 역시 이런 게 스타트업의 매력인 건가 보다.
• 피곤해서 지금 자꾸 노트북 앞에서 졸고 있다.

내일 할 일

• 내일도 면접이 있다. 푹 쉬고 좋은 컨디션으로 참석하자.

형식

페이지가 로딩되면 0.1초 후 10초에 걸쳐 opacity: 0에서 opacity: 1로 변해가는 애니메이션을 작성한 코드이다.

animation-name: YOUR_ANIMATION;
animation-duration: 10s;
animation-delay: 100ms;
animation-fill-mode: both;
@keyframes YOUR_ANIMATION {
    from {
    	opacity: 0;
    }
    to {
    	opacity: 1;
    }
}

속성

• animation-name: 키프레임 애니메이션 이름.
• animation-duration: 애니메이션 재생 시간. 기본값은 0. 's', 'ms' 단위로 표현 가능.
• animation-delay: 애니메이션 시작 지연 시간. 's', 'ms' 단위로 표현 가능.
• animation-fill-mode: 애니메이션 전후에 적용할 스타일 지정. 위에서 적용한 both는 애니메이션 전에는 첫 번째 키프레임, 애니메이션 후에는 마지막 키프레임의 CSS 스타일을 유지하게 한다. 상황에 따라 다르겠지만, 위의 코드에서는 반짝거리거나 끊기는 현상 없이 가장 자연스럽게 보일 수 있는 선택인 것 같다.
• 이외에도 재생 속도를 제어하는 animation-timing-function, 재생 방향을 설정하는 animation-direction, 반복 횟수를 지정하는 animation-iteration-count, 웹페이지 로딩 후 자동 실행 여부를 지정하는 animation-play-state가 있다.

여담

• 첫 번째로 걸어놓은 링크가 워낙 잘 되어 있다. animation-timing-function의 그래프나, animation-fill-mode의 애니메이션 등 이해를 돕는 예시가 많다.

참고