Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
집중을 도와주는 타임 타이머를 웹에서 사용해보세요 + 개발 썰
#side_projects
3 weeks ago

프로젝트 링크

깃허브 링크

안녕하세요.

프론트엔드 개발자를 꿈꾸는 23살 현역 군인입니다.

이전에는 모든 것을 갈아넣은 ToDoList 프로젝트 로 찾아뵈었는데,

대략 2년이 지나고서 다시 찾아뵙니다.

프로젝트가 완성된 김에 프로젝트 썰좀 풀어보고자

이 글을 작성하게 되었습니다.

제가 프로젝트에서 생각했던 모든 것, 겪었던 것들

모든 것을 이 글에 넣고자 합니다.

그래서 글이 좀 많이 깁니다.

양해부탁드릴게요.

개발 개요

  • 개발 기간: 대략 2개월

  • 스택: Next.js / Typescript / Emotion / Firebase

  • 개발은 군대라 code-server를 열어서 진행했습니다.

만들게된 계기

저는 종종 장난감처럼 인터랙션할 수 있는 토이 프로젝트를 하는 것을 즐깁니다.

아무래도 제가 존경하는 개발자(이자 디자이너) 김종민님의 영향을 많이 받았던 것 같은데요.

그런 행동들 덕에 이번 타임 타이머 프로젝트도 진행할 수 있게 되었습니다.

프로젝트의 시작은 실제로 시중에 판매되고 있는 ‘타임 타이머’ 제품을 보고 나서 였습니다.

해당 제품은 단순한 1시간 타이머였는데, 다른 제품들과 구별되는 차이점이라면,

시각성이 매우매우 훌륭하다는 점입니다.

‘타임 타이머’는 손으로 중앙에 돌출되어 있는 모터를 돌려 시간을 맞추게 되는데,

군대 동기가 이 제품을 구매하여 직접 손으로 시간을 맞추는 것을 보며

인터랙션 쪽에서 영감을 받게 되었고, 이걸 한 번 웹으로 옮겨보자는 생각을 하게 되었습니다.

프로토타입 제작

저는 빠르게 바닐라 JS를 이용하여 손으로 시간을 맞출 수 있는 시계를 제작해 보았습니다.

(아쉽게도 이 시절 작동되는 영상이 없어서 보여드리긴 힘드네요)

pointer event를 이용하여 사용자의 포인터 좌표를 구하고,

간단한 수학과 선형대수를 이용해 시계가 돌아가는 프로토타입을 구현했습니다.

결과는 굉장히 만족스러웠고,

그렇게 저의 일용할 양식이 되는 간단한 프로젝트가 되나 했으나…

직접 타임 타이머를 만들기로 결심하게 되다

앞서 소개한 ‘타임 타이머‘를 사용하던 동기가 저에게 와서

” 오 이거 뭐임? 웹으로 만드는 거임? 그럼 나도 쓸 수 있음? ”

이런 말을 하는 겁니다.

저는

’ 만들 계획 없다 ’ , ‘ 그냥 장난감으로 돌아가는 거만 만든거다 ’

라고 말했습니다.

그런데 말하고보니 지금까지 제가 무언가 배포까지, 끝까지 진행해본게 그닥 없더라고요.

그래서 오히려 좋은 기회다. 프로토타입도 괜찮겠다. 이거로 끝장을 보자.

이런 생각을 가지고 프로젝트를 끝까지 진행해서 배포해보자고 마음을 잡게 되었습니다.

군대에서의 개발

군대에서의 개발은 정말 쉽지 않았습니다.

시간은 딱히 문제가 되지 않았습니다.

현재 현업에 종사하시는 개발자 분들도 야간에 시간을 내어 토이 프로젝트를 진행하고 있고

저 역시 같은 처지에 놓여있다 생각하여 시간은 그리 큰 문제가 되지 않았으나…

문제는 ‘개발 환경’ 에서 찾아왔습니다.

일단 군대 사이버지식방(사지방)의 PC로는 VSCode가 제대로 동작하지 않았거니와,

보안상 터미널도 막혀있어 지금까지 해온 개발 습관과 지식으로는 안되겠다 판단,

개발 전부터 큰 난관에 부딪히게 되었습니다.

물론, Web IDE를 사용하면 문제는 말끔히 해결되겠지만,

저는 생고집을 부리더라도 VSCode를 사용하고 싶었습니다.

저한테 가장 익숙했고, 나가서도 그 툴을 사용하고 싶었기에 더 익숙해지고 싶었죠.

결국 수 일의 구글링 끝에 저는 AWS의 EC2 인스턴스를 하나 구매하여,

그 위에 웹에서 작동하는 VSCode인 code-server를 구축함으로써

편하게 VSCode의 기능들을 사용할 수 있게 되었습니다.

(브라우저를 통해 EC2에 접속하면 보이는 화면입니다. 정말 만족스러웠습니다.)

개발의 준비

일단 기본 스택은 Next.js로 정했습니다.

그 이유는 2가지 였는데,

  • SSR이 CSR과 어떤 차이가 있는지, 이게 체감이 되는지 직접 보고싶었음

  • 단순하게 그냥 써보고 싶었음 (약간 Next.js는 필수라고 생각했던 것 같음)

함께 CSS-in-JS 라이브러리로 Emotion을 가져왔는데,

CSS module, styled-js는 제 취향이 아니었고

styled-components는 Next.js에서 여러가지 세팅이 필요한데 비해

Emotion은 styled-components의 대부분의 기능을 지원함과 동시에

.babelrc 파일을 통해 플러그인만 작성해주면 세팅이 완료되기에

Emotion이 적격이라 판단했습니다.

문제는 Next.js를 단 하나도 몰랐다는 점인데

니꼬의 무료강의 덕분에 정말 많은 도움을 받았고,

시작함에 있어서 정말 많은 시간을 절약할 수 있었습니다!

고마워요 니꼬 :)

그리고 너무 편한 Typescript도 가져와서 개발을 진행하게 되었습니다.

이렇게 준비물을 다 가져오고 프로토타입을 기반으로

개발을 시작하게 되었습니다.

개발… 개발… 또 개발…

React 관련해서 배운것들.

개발 과정에서 정말 많은 개발 지식을 얻게 되었는데,

가장 신선했던 것은 React의 함수형 프로그래밍 철학(순수성)과,

무엇보다도 useEffect는 다른 변수와 동기화될때 가장 유용하게 사용된다는 것이었습니다.

지금까지 저에게 있어서

‘useEffect는 그냥 컴포넌트의 mount에 가장 많이 사용’

이라는 생각을 계속하고 있었고,

‘의존성 배열에는 그냥 effect 안에서 사용하면 무지성으로 넣어주는게 원칙’

이라는 규칙을 계속 지켰었습니다.

그런데

“ 왜 strict 모드일 때 useEffect가 2번 실행될까?“

라는 의문에서 시작하여,

React가 추구하는 컴포넌트 순수성에 대해 이해하게되고,

useEffect를 mount에 사용하는 것은 굉장히 좋지 않은 것이라는 결론을 내렸습니다.

useEffect는 상태와 맞물려 사용하는게 좋다.

그렇게 뒤따르는 궁금증이 생겼는데,

“ 그럼 useEffect를 어디에 씀? ”

이었죠.

프로젝트를 진행하며 직접 느낀 이에 대한 저의 대답은,

‘컴포넌트의 상태와 맞물려 사용할 때 가장 베스트다.’

라고 결론을 내렸습니다.

위 코드에서 처럼 state의 값이 바뀌면 useEffect가 실행되게 되는데,

이때 state의 값에 따라 다른 로직을 실행시킬 수 있습니다.

이를 더 응용하면,

연쇄적으로 서로 다른 effect 로직을 실행하며 관심사를 분리해낼 수 있다는 것도 발견하였고,

이 컨셉을 프로젝트에 적극적으로 적용했던 것 같습니다.

의존성 배열에 아무거나 막 넣어도 되는 걸까?

또한, 앞서 말했던

‘의존성 배열에는 그냥 effect 안에서 사용하면 무지성으로 넣어주는게 원칙’

에도 의구심이 생겼는데요.

이런 방식으로 개발을 진행하면

의도치 않은 effect 실행을 야기할 수 있다는 생각을 하게 되었습니다.

위 코드는 만약 개발자가

stateA의 변화를 감지하기 위해 만든 effect라고 가정합시다.

그리고 해당 로직은 stateB의 상태에 따라 실행할지 말지 결정해야됩니다.

그런데 문제는 effect에서 stateB가 사용된다고 무지성으로 의존성 배열에 넣게되는 경우인데,

stateB가 true로 변화했을 때도 위 로직이 의도치 않게 실행된다는 겁니다.

이 문제를 어떻게 개선할지 고민하다가

그냥 useEffect 밖으로 빼버리면 해결되는 문제라고 생각했습니다.

왜냐하면, stateB를 의존성 배열에 넣은 이유는 단순히 값의 최신상태를 보장하기 위해서고,

문제를 해결하기 위해서는 stateB를 빼야하기 때문에,

항상 최신상태가 보장되는 effect 밖에서 arrow function을 이용하여 로직을 구성한다면,

문제가 해결될 것이라고 생각했습니다.

문제가 완벽하게 해결되었습니다!

.

.

.

개발을 진행하면서 이러한 컨셉들에 대해 굉장한 많은 고민과 연구를 했고

계속해서 최적의 답을 찾아나섰습니다.

가끔은 자다가 꿈에서 해답을 찾은 적도 있었고

더 나은 컨셉이라고 생각된다면 과감하게 이전 코드를 전부 지워버리고

새로운 코드로 다시 짜곤 했습니다.

굉장하게 어두운 밤에 항해를 하는 기분이었는데,

그래도 너무 즐거운 시간들이었습니다.

실시간으로 성장한다는 것이 피부로 느껴지고,

왜 개발자가 토이 프로젝트를 진행해야 하는지 몸소 느꼈습니다.

그렇게 첫 타이머를 완성하다

우여곡절 끝에 타이머라고 할 수 있는 무언가가 나왔습니다!

제가 추구했던 디자인 철학.

제가 추구하는 디자인은 plus design이 아닌 minus design인데요,

예전 프로젝트들에서는 그냥 버튼이나 기능들을

최대한 섹션안에서 보여주기 위해 우겨넣는 디자인을 했었습니다.

그런데 그러고보니까 시각성도 떨어지고

모던한 디자인을 하기도 힘들거니와, 한다고 하더라도

그 디자인이 오래갈 디자인처럼 보이지는 않았습니다.

물론 제 실력이 부족한 것도 있었지만요.

최근에는 이러한 문제들 때문에

과감하게 요소들을 제거하는 디자인을 선호합니다.

위 프로젝트 결과에서도 보이듯이,

결과물이 굉장히 무언가 ‘허전’합니다.

허전하지만 필요한 요소들만 추려서

알맞게 떨어지는 레이아웃안에 넣으려고 굉장히 노력을 했고

그 결과 허전함에도 깔끔하고 시각화가 잘 되어있는 느낌을 줍니다.

그렇게 보였으려나요?

트랜지션에도 많은 신경을 썼습니다.

또한 저는 인터랙션을 중요시 여기다보니,

인터랙션을 통한 요소들의 트랜지션에도 굉장한 노력을 기울였습니다.

가장 노력을 기울였던 것은,

’ 어떻게 하면 시선 분산을 막고 타이머에 집중하게 할 수 있을까? ’ 였습니다.

이런 문제는 저의 철학인 minus design과 섞여서

‘ 타이머에 집중해야 될 때는 다른 요소를 다 제거해버리자 ’

라는 결론에 도달했습니다.

거기에 더불어,

제가 존경하는 개발자 김종민님에게서 배운

‘ 트랜지션/애니메이션을 만들 때 연속되는 물체를 이용하면 좋다 ’

를 이용하여,

타이머 인터랙션이 실행되면 작았던 시간이 그 자리에서 자연스럽게 커지면서

사용자로 하여금 강조되게하는 트랜지션을 구상했습니다.

따라서 아래와 같은 타이머 트랜지션이 나올 수 있었습니다.

이제 추가적인 기능을 추가해보자

여기서 끝내면 이 프로젝트만의 개성이 없었습니다.

분명 웹이기 때문에 가능한 것들도 있을 것이고,

좀 더 도전해보고 싶었습니다.

그래서 가장 먼저 추가한 기능이

‘종료시 알림기능’ 입니다.

일단 종료시 소리 알림은 기본으로 넣어야 한다고 생각했고,

혹여나 사용자가 창을 잠시 닫았더라도 종료시에 백그라운드 알림이 왔으면 좋겠다고 생각했습니다.

오디오가 원할 때 실행이 안되요…

웹에 오디오를 넣는 것은 그렇게 어려운 기능이 아니지만,

가장 발목을 잡았던 것은 브라우저의 보안정책이었습니다.

왜냐하면 오디오를 실행하기 위해서는

먼저 사용자와의 click, pointer event와 같은 인터랙션이 있어야하는데,

문제는 ‘인터랙션 이후의 실행’에 대해 굉장히 까다롭다는 점인데요.

저 같은 경우는 타이머를 click 인터랙션으로 시작하고 나서

타이머가 종료되었을 때 오디오를 실행하게 되는데,

여기서 타이머가 종료된 시점에서는 브라우저가 이미 인터랙션이 종료되었다고 판단하여

오디오를 실행시키지 않던 문제가 있었습니다.

여러가지 편법을 연구했지만,

이에 대하여 브라우저마다 처리가 다른지

어떤 브라우저에서는 작동하지만, 다른 브라우저에서는 작동하지 않던 문제가 있었습니다.

결국 해결한 방법은

‘이미 인터랙션을 통해 실행되었던 audio 노드의 소스를 바꿔버려 실행시키면 정책에 걸리지 않는다’

에서 착안하여,

사용자 인터랙션 발생시, 매우 짧고 소리도 들리지 않는 오디오를 실행하고,

해당 오디오가 끝나면 실제로 재생할 오디오로 소스를 바꿔버려

나중에라도 실행할 수 있도록 로직을 구성했습니다.

백그라운드 알림을 넣어보자.

백그라운드 알림을 넣기 위해 많은 컨셉들을 공부했었습니다.

그 중에서 가장 신기했던 것이 Service Worker라는 것인데,

스크립트를 백그라운드에서도 작동하게 할 수 있다는 것을 보고 굉장히 감탄했었습니다.

또한, Firebase가 제공하는 Cloud messaging을 이용하여

백그라운드 알림을 제공할 계획을 세웠습니다.

Cloud messaging 문서에서 제시하는 Service worker 코드를 참고하여

messaging token을 부여받고, 테스트를 하려는 찰나,

제가 개발하는 사지방의 환경에서는 브라우저 알림을

군 정책상 기본적으로 막아놨던 것을 깨달았습니다…

따라서 이 기능에 대한 테스트 및 개발이 군 환경에서는 불가능했습니다.

이렇게 이 기능은 추가하지 말아야되나 생각을 하곤 했습니다.

그래도 어떻게든 완성시켜야겠다는 생각에

아껴두던 휴가를 주말 토요일 일요일 이렇게 2일정도 써서

집에서 날을 새며 개발하고 또 개발하고…

어떻게든 복귀전까지 기능을 구현하고자 했던 기억이 있네요.

결국 엄청난 삽질 끝에 기능을 추가하는데 성공하고

백그라운드 알림이 잘 오는 것을 확인했습니다.

(물론 아직 이 기능은 안정화가 되지는 않아서 추후 점점 개선할 예정입니다)

백그라운드 알림을 지원하지 않는 브라우저라면?

또한 이 기능은 모든 브라우저에서 지원하지 않기 때문에,

현재 브라우저가 지원하지 않는 브라우저인지 탐지하는 로직을 구성하여

브라우저가 지원하지 않는다면 아래와 같은 모달창을 띄우도록 하는 개발을 진행하였습니다.

지원하는 브라우저, 지원하지 않는 브라우저의 리스트를 만들어서

한 눈에 어떤 브라우저가 지원하는지 보기 쉽게 제작했습니다.

오디오를 미리 들어볼 수는 없을까요?

저는 다음날 일찍 일어나야 할 일이 있을때마다 알람을 맞추곤 하는데요.

군에서는 핸드폰으로 알람을 맞추기 힘드니,

적당한 자명종 시계를 사용하곤 합니다.

그런데 군대 생활관은 저 혼자 쓰는게 아니기 때문에

이 자명종 시계의 알람이 민폐가 될 수 있습니다.

그래서

‘미리 시계 알람 소리를 들어보고 소리를 조절할 수 없을까?’

라고 생각하던 찰나,

이 기능을 제 프로젝트에도 적용해야겠다는 생각을 했습니다.

미리 들어보지 못하고 알람기능을 켤지 말지 선택지를 주는 것은

사용자 경험에 있어서 굉장한 불편함으로 다가올 것이라 생각했습니다.

따라서 앞서 제작한 모달창을 재사용해서

오디오를 미리 들어볼 수 있는 기능을 제작했습니다.

모달창 하단의 버튼을 누르면

알람 소리를 미리 들어볼 수 있습니다!

기능이 점점 추가되는데요?

이 외에도 넣고 싶었던 많은 기능을 넣었습니다.

  • 타이머 최대 시간 변경

  • 타이머 색상 변경

  • 한국어, 영어 토글하기

  • 분/초를 퍼센트로 표시하기

  • 등등…

그런데 이런 기능이 추가되다보니

점점 공간이 부족해졌습니다.

따라서 메뉴를 제작해야함을 느끼게 되었습니다.

그래서 메뉴를 만들었습니다.

메뉴는 구글의 material design 3의 디자인을 참고하여 제작했습니다.

material design의 심플함이 제 프로젝트에 잘 맞을것 같다 판단했습니다.

모바일 메뉴

그러나 위의 메뉴 디자인은 모바일 환경에서는

불편한 디자인으로 다가올 수 있습니다.

상대적으로 화면의 너비가 부족한 모바일 환경 특성상,

위의 고정 메뉴바는 화면의 너비를 꽤나 잡아먹는 요인이 되어

다른 중요한 요소를 더욱 강조해야하는 것을 힘들게 합니다.

따라서 모바일 메뉴를 따로 제작하기로 결정했습니다.

그러나 이 과정에서 뼈아픈 경험을 했는데,

바로 모바일 우선 디자인의 중요성입니다.

데스크탑 디자인을 먼저하고, 모바일 디자인을 나중에 하게되니

넓은 화면과 많은 기능을 가진 데스크탑 디자인을

작은 화면의 모바일 디자인 속으로 우겨넣는 느낌이 강하더라고요.

그래서 두 개의 디자인이 굉장히 일관성 없다는 느낌을 받았고,

이 간극을 최소화하기 위해 많은 노력을 기울였습니다.

만약 모바일 우선 디자인을 진행하였다면,

훨씬 수월하게 반응형 디자인을 구상하지 않았을까 생각했고

반응형 디자인에 대해 많은 것을 배웠습니다.

LocalStorage에 옵션 값 저장하기

브라우저에 어떠한 값을 반영구적으로 저장하는 방법으로는 많은 방법들이 있지만,

제가 크게 선호하는 방식은 LocalStorage 입니다.

물론, IndexedDB와 비교하면 단점들도 많지만,

(예를 들자면 용량 부족, JSON 객체의 메소드 cost 문제 등)

이 프로젝트에서는 그러한 단점들이 의미가 없었습니다.

왜냐하면 저장할 데이터의 양이 극히 적었기 때문인데요.

따라서 그냥 간편하고 익숙한 LocalStorage를 사용하여

설정한 옵션 값을 반영구적으로 저장하는 구성하기로 했습니다.

LocalStorage는 클라이언트 환경에서만 사용가능하므로,

Next.js를 사용하는 저는 여러가지 예외처리를 해주어야합니다.

컴포넌트 내부에서 해당 로직을 남발하게될 경우에

모든 로직에 항상 예외처리하고 사용해주어야하고,

심지어 코드도 예쁜 편은 아니기 떄문에

해당 기능을 커스텀 훅으로 빼내어 기능 개발을 진행하였습니다.

결과적으로는 잘 작동하는 코드를 구성했습니다!

마지막 피날레, PWA

프로젝트를 어찌저찌 만들고 나니

욕심이 생겨 앱으로도 만들고 싶어졌지만

군 환경에서는 사실상 불가능에 가깝기 때문에 포기하려던 찰나,

최근 유튜브에서 본 PWA 관련 영상이 떠올랐습니다.

“ PWA 쓰면 데스크탑/모바일 앱처럼 쓸 수 있다던데? ”

라는 생각을 가지고 PWA의 결과물을 봤는데…

제가 원하는 결과물에 가까웠습니다.

그래서 바로 PWA 개발에 착수했습니다.

고마워요 Next-PWA!

고맙게도 이미 누군가가 만들어놓은

next-pwa라는 라이브러리가 있었고,

이를 이용하여 PWA의 Service Worker 구성은 손쉽게 끝날 수 있었습니다.

덕분에 저는 manifest 구성에 몰입할 수 있었고,

manifest에 필요한 로고들을 부족한 실력으로 전부 그렸습니다.

(실제 제가 만들어 사용한 favicon)

벡터 그래픽에는 거의 문외한이다보니 만드는게 쉽지는 않았지만,

어릴 때부터 그림그리기를 좋아했는데,

이런 분야에서 그림을 그리게 되었다는 생각에

막막했었다기 보다는 신났었던 기억이 있네요.

그러다보니 생각보다 쉽게 PWA를 만들었고,

너무나 만족스러운 결과물이 나와 기분이 좋았습니다!

(실제 IOS에 깔린 제 프로젝트)

여기서 더 추가하고 싶은 PWA 기능이 있다면,

데이터를 캐싱하여 오프라인으로도 앱을 실행할 수 있는 기능을 제작하고 싶네요.

배포

배포는 vercel로 진행했습니다!

Next.js를 배포해보는 것은 처음인데,

vercel은 최곱니다.

github repo랑 연동해서 push하면 자동으로 빌드해주고,

배포까지 전부 자동화시켜주니 참…

예쁜 녀석이 아닐 수 없네요.

항상 수동으로 AWS나 Github Pages에 배포해오던 저는

이때 이론으로만 보던 CI/CD의 중요성을 몸소 느꼈습니다.

vercel은 CI/CD 전부를 지원하지는 않는 것 같기에

(CD를 중심으로 지원하는 듯 함)

다음 프로젝트에는 말로만 듣던

Github Actions, Travis CI, Circle CI 요런 것들로

CI 까지 추가해서 자동화 시켜볼 계획입니다.

거기에, 도메인도 추가로 구입해서 배포를 진행했습니다.

제 닉네임을 딴 fecapark.com 을 구매하고,

여기에 CNAME으로 timer.fecapark.com 을 만들어

해당 도메인에 프로젝트를 배포했습니다.

현재까지는 아직 구글 검색엔진이 제 사이트를 크롤링하지 않아

검색해도 뜨지는 않지만…

주기적으로 체크해주면서 SEO도 진행해갈 상태입니다.

웹 사이트 공유하기!

그냥 이건 연습삼아 재미삼아 만든 기능아닌 기능인데,

단순하게 SNS에 공유하면 카드가 뜨게 만드는 겁니다.

간단하게 meta tag를 추가함으로서 제작이 가능했고,

결과물도 만족스럽게 나온 것 같습니다.

(디스코드)

(카카오톡)

결론 & 내 생각

우선 여기까지 와주신 모든 분들께 감사드립니다.

근 2개월동안 정말 재밌는 시간이었습니다.

그만큼 배운것도 많고 버려야할 것도 많았습니다.

항상 느끼지만 개발이란 분야는 정말 신기하고 새로운 것 같습니다.

아무래도 항상 무언가로부터 배워야하는 직종이기 때문일까요.

그렇기에 한편으로는 정말 무섭기도 합니다.

“ 아직 난 이정도의 간단한 토이 프로젝트밖에 못하는데,

실제 현업에서 인정받으면서 뛰려면 얼마나 많은 노력을 해야하는 것일까? ”

라곤 종종 생각하기도 합니다.

오랜만에 제가 썼던 프로젝트 글(모든 것을 갈아넣은 ToDoList 프로젝트)을 보니

굉장히 무언가 작은 것을 배운다는 것에도 들뜨고 신났던 제가 있네요.

물론 지금도 그런 기분이 들고 무엇을 배우게 될지 기다려지기도 합니다.

하지만 얕아보이는 바다에 다이빙을 했는데

막상 잠수해보니 끝이 없을 정도로 어두운 심해가 펼쳐진 기분이랄까요.

그런 심해속에는 배워야할 것도 정말 많고, 해결해야 할 문제도 정말 많다고 생각합니다.

저는 개발자는 개발하는 것도 중요하지만,

무언가를 만들어가는 과정에서 발생하는 문제를 해결하는 사람이라고도 생각합니다.

그렇게 문제를 해결하다보면 제가 만들고자 했던게 만들어져 있을테니까요.

신에게 감사하게도 저는 아무래도 이런 과정을 진심으로 즐기고 재밌어하는 사람인 것 같습니다.

그래서 개발자가 천직인거 같기도 하고요.

이번 프로젝트를 끝내고 잠깐 쉬면서

혼자 이런저런 내용들을 생각해보았는데요.

뭔가 글로 털어내고 싶었습니다.

그렇기에 제가 지금 여기서 날을 새면서 글을 쓰고 있는 거 같습니다.

긴 글 읽어주셔서 정말로 감사합니다.

좋은 하루 되세요.

9 comments