프론트엔드 개발자 활동을 하다보면, 아주 가끔 다른 사람들이 제가 왠만한 디자인은 구현할 줄 알고, 요청 사항대로 거의 모든 부분을 해결해주기 때문에 제가 뛰어난 개발자라고 말해주시는 고마운 분들을 만납니다. 하지만 저는 그런 말을 들을 때마다 마음 한쪽이 불편합니다. 사실은, 저는 '구현'만 할줄 알지 그 내부 원리는 제대로 안다고 말할 수 있는 것이 매우 적기 때문입니다. 물론 당장 개발 하는데 그런 이론들이 직접적으로 도움이 될지는 잘 모릅니다. 주된 코드들이 정해진 프레임워크 양식이나 API들을 따라서 작성되는 프론트엔드 개발의 특성상, 이런 내용들을 안다고 내 코드들이 조금이라도 달라지려나 하는 의구심도 드는 것은 사실입니다. 하지만, 어디가서 제가 '프론트엔드 개발자'라고 당당하게 말할 수 있..

브랜치 종류는 크게 아래와 같다. master develop feature release 실제 개발은 develop 브랜치에서 진행된다. 그리고 develop 자체에서 커밋 내역을 만드는 것이 아니라 feature 브랜치에서 커밋을 만들고 이를 develop 에서 병합하는 식으로 커밋이 이루어진다. 별거 아닌 버그 픽스나 기능 추가는 그냥 develop에서 빠르게 반영한 후 커밋한다. 즉, develop 에서 왠만하면 커밋이 발생하지 않지만 발생할 수 있으므로 feature 브랜치에서 작업을 할 때는 항상 develop 브랜치의 변경 사항을 pull 해와야 한다. 개발이 어느 정도 완료되고 이를 배포하는 시점에서는 Release 라는 이름으로 시작하는 브랜치를 만든다. 해당 릴리즈에서 발생하는 버그나 수..

git reset 리셋 작업은 크게 3가지로 나눌 수 있다. 하나는 add 가 끝난 시점으로 돌아가는 soft, 둘째는 staged 파일들(추적 중)과 untracked 파일들이 섞인 시점으로 돌아가는 mixed, 아예 그냥 이전 커밋 상태로 돌아가는 hard 가 있다. reset을 할 때 플래그로 이 옵션을 넣어주면 적용된다. (--soft, --mixed, --hard) Tip: 되도록이면 hard는 주지 않는 것이 좋다. 기존에 작업했던게 임시로라도 남아있지 않고 그냥 다 날아가 버리기 때문이다. 아니면 git stash 를 통해 임시 저장을 수행한 다음 해주는 것이 좋다. git stash 작업을 하다가 잠깐 작업을 중단해야하는 상황이 생겼는데, 커밋 내역을 만들기에는 애매할 때 쓴다. 해당 브랜..

EC2 인스턴스는 간단한 서버 운영을 위해 가벼운 마음으로 빌리기 쉽지만 복잡하고 정확히 이해하기 힘든 가격 정책 때문에 프리티어(t2.micro) 이상의 인스턴스를 이용하기가 꺼려지는게 사실입니다. 가장 많이 쓰일 법한 가격 정책 3가지를 선택해서 정리해보았으니 본인이 원하는 인스턴스가 한달 혹은 일년에 비용이 얼마나 드는지 확인하고 싶으신 분들은 참고하셔도 좋을 듯합니다. 아래 계산은 가장 일반적인 EC2 인스턴스 대여 서비스를 기준으로 가격책정. 프리티어인 t2.micro 보다 딱 한 단계 높은 t2.small 을 선택한다고 가정합니다. 다른 인스턴스에 대한 정확한 비용 계산은 아래 링크를 참고해보시기 바랍니다. aws.amazon.com/ko/ec2/pricing/on-demand/ EC2 인스턴..