컴포넌트를 분리하는 이유 하나의 파일만 있어도 프로그램은 돌아가고, 하나의 HTML 파일만 있어도 충분히 사용자에게 성능 좋은 웹을 제공할 수 있습니다. 그런데 왜 컴포넌트라는 개념이 생기고 분리에 힘을 쓸까요? 결국 코드는 나 혼자만 보는 것이 아니라 동료 또는 미래의 나와 공유해야 하기 때문에, 가독성이 좋고 유지보수가 용이해야 합니다. 그리고 잘 분리되어 있어야 가독성이 좋고 유지보수가 용이합니다. 나만의 분리 기준과 대처법을 정리해보자. 절대 은탄환은 없고 기준이 없어도 되지만, 제가 경험해본 상황과 대처를 정리하여 기준을 정리해보기로 했습니다. 기준을 정리해서 빠르고 여유있게 그리고 일관성 있게 개발하기를 기대합니다. 그리고 누구나 이해되는 코드를 작성할 수 있기를 바랍니다. 분리 기준 2가지 ..

피움 서비스는 기존에 EC2 + Nginx로 FE 정적 파일 서빙과 백엔드 API 응답을 하나의 EC2에서 하고 있었습니다. 백엔드와의 관심사 분리를 위해 EC2에서 S3로 FE 정적 파일을 옮기고, 보안과 CDN 캐시를 적용하기 위해 CloudFront를 통해 배포하였습니다. 더 나아가서, 같은 리소스는 더 빠르게 접근하고 네트워크 트래픽을 줄이기 위해 HTTP 캐시를 적용했습니다. 해당 과정을 어떻게 적용하였는지 공유하고자 합니다. S3 + CloudFront 배포 이미 S3와 CloudFront로 배포하는 방법은 피움 블로그에 잘 기록되어 있습니다! 이외의 프론트엔드 배포를 위한 차이점만 다루었습니다. S3 업로드 자동화 하기 aws cli 설치 가장 좋은 방법은 공식 문서의 설치 방법을 그대로 따..

기본형 / 참조형 데이터는 기본형이거나 참조형이다. 기본형 기본형은 원시값의 주소를 가리킨다. 값을 바꿔도 원시값을 가리키는 주소가 바뀌는 것이지, 같은 주소 안에서 원시값이 바뀌는 것이 아니다. 그래서 주소안의 값은 불변으로 여긴다. a = 1; b = a; a, b 둘다 '1이 담겨있는 주소'를 가리키고 있다. a === b; 둘은 같은 주소이기 때문에 true이다. a = 2; 새로운 주소에 2를 할당하고 a가 그곳의 주소를 가리키게 된다. 이때, 1을 담고있는 공간에는 어떠한 변화도 없다. (즉, 불변하다) 후에 아무도 1을 가리키지 않는다면 각 JS 엔진의 GC가 적당한 시기에 1을 담고있는 공간을 비운다. 참조형 참조형은 데이터가 아니라 그룹의 주소를 가리킨다. 그룹의 주소는 바뀌지 않지만 그..

빠르게 다름을 인정하자. 코드에 정답은 없지만 최소한 모두 통일은 되어야 한다고 생각했었다. 하지만 협업하면서 모든 코드 스타일이 통일되기란 정말 쉽지 않았다. 특히 수직적인 문화가 아닌 수평적인 관계에서는 더욱 그렇다. 정답도 없는 모든 컨벤션을 맞추고자 매번 토론을 진행한다면? 그 피로는 투자한 만큼 보상을 받지 못한다고 느겼다. 그래서 큰 문제가 없다면, 아주 큰 단위의 스타일과 컨벤션만 맞추고 그 외의 다름은 빠르게 인정하는 것도 또 하나의 방법이라고 생각한다. '옳고 그름' 대신 '장점 단점' '무엇이 맞다' 또는 '무엇이 틀리다'라는 표현은 상당히 위험했다. 이런 표현은 상대방에게 반박의 여지를 제공하곤 했다. 옳고 그름을 나누는 것보다 더 중요한 건 의견을 하나로 맞추는 것이라고 생각한다. ..

우연한 중복인지 의심해보기 이전에는 명령의 집합, 컴포넌트 구조, CSS가 중복되면 바로 추출했다. 더 나아가서, 중복이 예상되어도 미래를 위해 추출했다. 당장엔 이뻐보였다. 이러다보면 차이점이 생길 때마다 완벽한 추상화를 위해 오버 엔지니어링을 할 위험이 있고, 좋은 코드의 본질을 잊어버릴 때가 있다. 결국 이해하기 쉽고, 확장하기 쉬운 코드가 좋은 코드 아니었던가? 추상화의 과정이 시간을 과하게 뺏어가고, 그 결과가 이해하기 어렵다면 시간을 한번 더 뺏는다. 중복제거만을 위한 추상화는 분명 정답이 아니라고 느꼈다. 서비스와 기획은 너무나도 빨리 바뀐다. 구현하는 방법 또한 계속 바뀐다. 미래를 예지한 것이 아니면, 결국 완벽한 추상화는 없다. 일반화의 끝은, 결국 아무것도 하지않은 기본 API들과 태..

학습 일단 해보자! 꼭 해야할까? 싶은 것들이 있었다. 구현할 기능 목록 작성, 리팩터링, 도메인 로직 분리, 타입스크립트, 테스트코드 작성, TDD로 개발 등이 그러하다. 우테코의 미션은 과제만 주어지는 것이 아니라 위와 같은 요구사항도 같이 주어진다. 왠지 하기 싫은 것들을 해보면서 느낀점은 일단 해봐야 비교해볼 수 있다는 것이었다. 특히 개발하기 전부터 테스트를 작성하는 TDD는 조금 과하다는 생각을 했었는데, 테스트 케이스를 작성하면서 예외처리를 바로바로 떠올릴 수 있다는 점이 매우 큰 도움이 되었다. 성공할 계획을 세우자! 멋진 계획을 세우고 이행에 초점을 맞추는 방법보다는 성공할 수 밖에 없는 계획에 발전에 초점을 맞추는 순서가 성공률이 더 높았다. 후자를 선호하지 않지만 지속적인 성장에 적합..

JS에서의 큐? 자바스크립트의 리스트는 큐의 디큐(dequeue) 역할을 하는 shift() 함수가 존재하기는 합니다만, 시간 복잡도가 O(n)입니다. 사실상 시간적으로는 디큐의 역할을 하지 못하는 것입니다. index를 활용해서 큐의 시작점을 바꿀 수 있지만, 이 또한 공간적으로 디큐의 역할을 하지 못합니다. 그렇다고 연결리스트로 큐를 구현하기에는 너무 코드가 길어지고 코딩 테스트에서 활용하기 어렵습니다. index와 delete 연산으로 해결하기 delete연산은 시간복잡도가 O(1)입니다. 다만 리스트의 길이가 줄어들지 않습니다. const list = [0, 1, 2]; delete list[0]; list // [ , 2, 3 ] list[0] // undefined 그래서 head 역할을 하는..

앞으로 우테코에 지원하실 분들에게 도움이 되었으면 하는 마음으로 작성했습니다. 지원서 작성 거의 모든 합격 후기와 모든 온라인 설명회를 참고했습니다. 개인적으로 자소서는 신경을 쓸수록 잘 써진다고 생각해서 1달 이상 준비했습니다. 특히 우테코는 지원서가 큰 비중을 가진다고 생각해서 더욱 신경 썼습니다. 1. 프로그래밍 학습 과정은? 중학생 때 스크래치로 개발에 흥미를 가진 이야기부터 웹 개발에 이르기까지 뭐든 궁금한 것이 있었고, 배우고 싶은 것이 있었고, 또 그것을 위해 독학을 했다는 점을 자세하게 풀었습니다. 실제로 독학하면서 개발한 프로젝트가 많이 있었기 때문에 경험과 근거를 바탕으로 작성할 수 있었습니다. 문제가 생기면 호기심을 가지고 스스로 해결할 수 있는 사람이라는 것을 어필하고 싶었습니다. ..