내용에 문제가 있는 경우, 삭제, 수정조치하겠습니다.6,7주차가 끝났다.6주차 주말에는 너무 정신이 없어서 작성하지 못해서 이번주에 한번에 회고하고자 한다. 되돌아보기도구를 통해 UI정확성 확인하고, 수치값으로 한번 더 확인하기우선 PixelParallel보다 좋은 Pixel Perfect Pro라는 확장 익스텐션으로 변경했고, 작업중에 지속적으로 확인했다.완전히 UI에 대한 정확성을 100% 챙길수는 없었지만 그런 부분이 줄어들었다. 100%가 될 수 없었던 이유는, Figma와 브라우저 렌더링 방식이 100% 동일하지 않았기때문이다. 좀더 정확하게 써보자면 원인은 다음과 같다.1. 폰트크기가 같아도 브라우저와 피그마간에 미묘한 크기차이가 발생하고, 이로 인해 줄바꿈이 발생하는 경우 확인하기가 어려워진..
내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.5주차가 끝났다. 이번 주는 대체 휴일로 하루를 쉬어서 4일동안 일했기도했고 저번주에 설계한 것들을 바탕으로 리팩터링을 하거나 코드보다 스펙에 대해 이해하고 설계하는 시간이 대부분 이었어서 뭔가 따로 세운 목표를 적용해볼 기회가 좀 적었던 것 같다. 되돌아보기뽀모도로 휴식시간에 다음 계획 더 잘 작성해보기 이 부분은 좀 더 개선된 것 같다. 여전히 가끔은 놓치기도 하지만.... 어떤 테스크를 한다 -> 어떤 테스크중에 어떤 부분을 한다 형태로 좀 더 구체적으로 작성하려고 노력했다. 그리고 GPT사용해서 자체적으로 만든 업무 기록표를 넣으면 보고서를 만들도록 프롬포트를 만들어뒀는데, 이게 생각보다 유용해서 좀더 정확한 정보/인사이트를 얻기 위해서 앞으로 ..
내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다. 벌써 한달차가 끝나버렸다.돌아보기우선 이전 주 목표를 기반으로 돌아보고, 느낀 것들을 적어보려고 한다. 1. 뽀모도로 유지 및 좀 더 잘 작성하기 이전 주와 비슷하게 유지되었다. 다만, 좀더 익숙해져서 다음 일을 계획하거나 기록하는 것은 조금 개선됐다.아직까지 완벽하게 일하다가 돌아와서 5분간 다음 할일을 계획하는 수준은 아니어서 이 부분에 대해서는 계속해서 의식적으로 인지해서 개선할 필요가 있다. 2. 문제가 안풀릴 땐 다시 상단부터 다시 좁혀나가기 + 코드/맥락 파악시 그림을 적극 이용하기이번 주에 리팩토링을 진행할때 적극적으로 활용할 수 있었던 부분이다.추상화 방식 자체가 잘못되었을 수도 있겠다는 생각에 좀더 상단으로 돌아가 생각을 했고, 보다 ..
내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다. 점점 시간이 빨리 간다. 3주차가 지나갔다. 돌아보기쪼갠 문제를 푸는 시간이 기능을, 이 코드를 여기에 두는게 맞는가? 고민하는 시간을 줄이고자 했는데, 관련해서 직접 물어보고 한번 정리를 해서 시간을 조금 단축 시킬 수 있지 않았나 싶다. 사실, 이번 주에는 새롭게 컴포넌트를 짤 일이 거의 없었어서 그렇게 느끼는 것일 수도 있다.아마 이 목표는 다음 UI작업을 하게될 때 한번 더 되돌아볼 필요가 있다. 그래도 하다보니 5번 중에 한번은 맞게 예측하는 경우도 생기는 것 같다.사실 예측이라는게 기존 데이터가 있어야 가능한건데, 이전에 본격적으로 측정한 경험이 없어서 어려운 것도 있는 것 같다.우선 이건 한 주만에 해결되는 문제는 아니다. 우선은 측정을 ..
내용에 문제가 있는 경우 삭제, 수정조치하겠습니다. 순식간에 2주차가 지나갔다.첫주차는 주저리주저리 다 적었다면 이제는 좀 간결하게 작성해볼 예정이다. 돌아보기전주에 개선이 필요한 것들부터 돌아보자. 문제가 무엇인지 정확히 파악할 것 (섣불리 코드를 먼저 살펴보지 말 것) 이전보다 확실히 문제를 파악하는 시간이 단축된 것 같다.이 과정에서 가장 도움이 됐던 두 가지는이걸 해결해서 어떤 것이 나아지는가를 생각해보는 것, 그리고 그것이 완료되면 문제를 잘게 쪼개는 것이었다.내가 하는 작업이 어떤 것을 개선시키고 어떤 가치를 가져오는지 파악하고자 할때 문제를 좀더 잘 정의할 수 있게 됐다.그리고 테스크에서 주어지는 문제들을 다시 잘게 쪼개어 개발 단위로 쪼갰을 때, 확실히 시간이 단축되는 것을 느꼈다. Co..
내용에 문제가 있는 경우 삭제, 수정조치하겠습니다. 드디어 당근에서 일해보다나에게 당근은 꼭 일하고 싶은 회사였다.기술적인 부분도 분명 있지만, 무엇보다 프로덕트 자체가 로컬 플랫폼이기에, 삭막해져가는 사회에 동네라는 가치를 만들고 사람들과 사람들을 이어준다는 가치에 크게 공감하고 있기 때문이다. 이건 있다 설명할 당근에서의 이름인 Manolin과도 이어진다.또한, 내가 유튜브, 인스타 다음으로 많이 사용하는 앱이기도 하기 때문에 제품에 대한 애정과 오너십을 가질 수 있겠다는 생각에서 재작년 12월부터 계속해서 공고가 올라올때마다 도전하고 있었다. 세 번의 면접 불합격그래서 그전까지 인턴 포지션이 열릴 때마다 지원했다.아마 이번에 떨어졌어도 또 적었을 것이다.하지만 되돌아보면 불합격도 하나의 피드백이었..
![]()
문제점 네이버 부스트캠프에서 진행하고 있는 AlgoITNi프로젝트에서 아래와 같은 문제가 발생했다. 빌드하는 과정에서 이러한 경고 메시지가 발생한 것이다. 특정 청크가 500KB보다 크다는 것이 문제이다. 위 사진을 보면 번들사이즈가 1285kb이고, 사용자가 실제로 받는 번들사이즈인 gzip사이즈가 425.33kb이라 초기 렌더링이 느려질 수 있다는 문제가 있다. 청크 사이즈 줄이기 청크 구조 분석하기 원인을 알기위해서 vite-bundle-visualizer를 사용해서 청크의 시각적인 분석을 해보았다. highlight.js가 번들의 절반을 차지하고있었다. highlight.js는 에디터에서 코드하이라이팅에 사용되는 라이브러리인데, 여러가지 언어를 모두 지원하기때문에 이렇게 라이브러리 사이즈가 커지는..
![]()
그럼 이걸 활용해서 yml을 만들어보자. Github Actions Github Actions는 github에서 제공하는 CICD 툴으로써, 코드 저장소에 어떤 이벤트가 발생했을때 특정 작업을 일어나게 하거나 주기적으로 작업을 반복 실행시키는 일을해준다. 이에 따라 브랜치마다 다른 일을 할 수 있도록 처리해줄 수 있다. 그럼 브랜치마다 어떻게 작동하게 만들지 전략을 수립해보자. 배포 브랜치 전략 수립하기 우리팀은 프론트엔드 코드와 백엔드 코드가 한 레포지토리에 있기때문에, 각 파트별 배포가 필요한 상황이었다. https://github.com/boostcampwm2023/web05-AlgoITNi GitHub - boostcampwm2023/web05-AlgoITNi: 동료와 함께 할 수 있는 플랫폼, ..
![]()
CICD를 구성하기전에 우선은 배포를 위한 서버 자원(S3, CloudFront, IAM)을 생성하고, AWS CLI를 사용해보자. S3만들기 클라우드 프론트를 통해 OAC설정을 할것이기에 ACL비활성화, 퍼블릭 엑세스 차단설정을 해도된다. CloudFront배포 만들기 원본 도메인으로 S3 버킷을 연결시켜주자. OAC설정하기 클라우드 프론트로만 S3에 접근할 수 있도록 S3의 정책을 변경해주자 S3에 파일을 업로드 하기 웹 콘솔에서 업로드 버튼 누르기 사실 업로드하는 방법은 간단하다. AWS 콘솔에서 업로드 버튼을 누르면 된다 허허 그런데 git에 push 할때마다, 직접 빌드하고 빌드한 파일을 업로드 하기에는... 우리는 너무 할일이 많고, 충분히 자동화시킬 수 있는 부분이다. 그래서 github a..
![]()
들어가며 네이버 부스트캠프의 그룹프로젝트 과정에서 진행했던 AlgoITNi의 배포전략, 선택한 이유, 방법들을 기록해두고자 한다. 프론트엔드에서 배포는 어떻게 이뤄지는가? 프론트엔드의 배포는 결국 html,css,js 정적파일을 서빙하면 끝이다. (SSR 제외) 좀더 세부적인 동작은 이전에 작성한 아래의 게시글을 참고해주면 좋을 것 같다. https://0422.tistory.com/312 프론트엔드 웹서버 직접 만들기 (1) - Content-Type, MIME 프론트엔드 개발을 해본 사람이라면 vscode의 live-server, webpack-dev-server, vite등등 다양한 도구를 사용해서 프론트엔드 서버를 띄워본 경험이 있을 것이다. 심지어 express를 사용한 서버에서도 static ..
