altair의 프로젝트 일기

회고 취준과 공부, 개발을 동시에 하려니 생각보다 셋 다 속도가 나지 않았다. 그래도 이제는 프로젝트의 개발의 패턴이 어느 정도 자리잡아 간다고 느낀다. 기술 스택과 CI/CD 파이프라인 등이 정해지니 이제 비로소 개발 본질에 집중하게 된 듯하다. 이번 글에서는 지금까지 어떤 진전이 있었고 어떤 문제와 해결이 있었는지 적어보려한다.  프론트엔드 - 디자인 반영 가장 눈에 띄는 변화는 드디어 프론트엔드 디자인의 대부분이 반영되었다는 점이다. 다음은 디자인 가이드와 실제 웹 페이지다.  몇몇 수정 외에는 거의 디자인 가이드를 따라가보았다. 사실 보고 그대로 만들기만 하면 되는 건데 뭐가 대단하냐 할 지 모르겠다. 그렇지만 이전까지 바닐라JS만 겨우 끄적대봤던 나이기에 NextJS를 통해서긴 하지만 처음으로 ..

CI/CD를 해야하는 이유 내 서버에 올라가는 서비스를 개발할 때, 나는 제일 먼저 CI/CD 파이프라인부터 구축한다. 자동화된 테스트와 통합, 배포 과정은 개발이 진행될수록 점점 그 구축 비용이 증가하는 경향이 있다. 테스트는 라이브러리와 프레임워크 의존성에 큰 영향을 받고, 통합은 VCS의 브랜치 전략 등에, 배포는 Docker, LXC 등의 서버 인프라와 Dockerfile 등의 빌드 과정에 크게 좌지우지 된다. 만약 CI/CD를 미리 구축하지 않고 개발하기 시작하면 우선 로컬에서만 테스트할 것이고, 손수 SFTP 등으로 배포하게 될 것이다. 개발이 진행됨에 따라 테스트 및 배포 비용이 부담되어 그때 가서 CI/CD 파이프라인을 구축한다면 여러 문제가 발생한다. 다음은 내가 경험한 문제들이다. 기존..

한 때 새티스팩토리와  팩토리오라는 게임을 아주 열심히 했던 적이 있다. 둘 다 굉장히 복잡하고 광활한 공장을 짓는 게임인데, 친구하고 내 홈서버에 게임 서버를 올리고 같이 멀티플레이를 했던 즐거운 기억이 있다. 그렇게 복잡한 게임을 처음 시작하면 어디서부터 시작해야 할지 감이 오지 않는다. 저 돌을 먼저 캐야할까? 저 석탄을 먼저 캐야할까? 정찰을 먼저 해야할까?  어느 정도 완성된 게임 속 공장의 사진이다. 뭐가 뭔지 알아보기 힘들지 않은가? 마치 아랍어로 쓰인 글을 본 것 같은 이런 경험을 나는 '까만건 글씨요, 하얀건 종이로다' 상태라고 부르곤 한다.  림월드라는 게임을 만든 게임개발자 타이난 실베스터는 자신의 책 '게임 기획의 정석'에서 이러한 상태가 발생하는 이유가 정보의 과잉 때문이라고 했다..

개요 소프트웨어 마에스트로 과정에서 개발한 서비스가 단어마다 중요도를 매기는 서버를 필요로 했다. 우리의 백엔드는 스프링부트 웹서버와 단어 가중치 서버로 구성된다. 스프링 서버는 입력 받은 페이지의 단어들을 분석하기 위해 단어 가중치 서버에게 단어들의 중요도를 부여해달라고 요청한다. 이번 글에서는 더 늦어 잊어버리기 전에 해당 서버를 어떤 방식으로 구축하고 서버가 어떤 방식으로 단어들의 중요도를 평가하는지 설명해보려 한다. 문제 우리가 만든 서비스 빈채는 학생들을 위한 빈칸 자동 생성 서비스이다. 학생들이 개념서 페이지를 찍어 올리면 거기에 있는 단어들을 분석해 외워야 할 단어들에 빈칸을 치는 방식이다. 그렇기 때문에 OCR을 처리하는 기능과 단어 목록을 받아 각 단어들의 중요도를 평가하는 기능이 필요하..

개요요 며칠 영상 편집 용 워크스테이션을 알아보고 있었다. 원래 쓰던 데스크탑이 자꾸 자기 혼자 꺼지곤 하기 때문이다. 친구들끼리 게임하거나 게임하는 영상을 녹화하는 정도로는 크게 문제 없지만 작업을 하자니 생각보다 불안한게 사실이다. 프리미어나 유니티에서 작업하다가 갑자기 꺼지면 답도 없지 않은가.그래서 중고 워크스테이션을 찾아보고 있었다. 그렇게 중고 장터를 돌아다니던 중, 눈에 띄는 물건을 몇 개 발견했다. 그 중에 하나가 바로 이 씽크패드 X200이다.2008년 경 한국 시장에 출시된 이 모델은 Intel Core 2 Duo를 달고 있었다. 내가 본 중고 매물은 이 코어2듀오 CPU에 2GB 램을 달고 5만원 밖에 하지 않았다! 물론 업자가 모아놓은 고물 노트북 중 하나여서 그런 것 같긴 했다. ..

개요 요새 오랜만에 아주 각 잡고 백엔드 개발을 하고 있다는 생각이 든다. 여러 사람들과 협업도 하고 코드리뷰도 하면서 개발자다운 생활을 하는 기분을 만끽하고 있다.  이번 글에서는 소규모 팀이 협업하는 과정에서 사용할만한, 즉 우리 팀이 쓰고 있는 Git branch 전략에 대해 소개하고자 한다.  Git branch 전략  세상에는 정말 많은 Git branch 전략들이 있다. 대표적으로 Git flow와 Github flow를 들 수 있겠다.  Github Flow는 Git Flow보다 더 적은 브랜치를 관리한다는 특징이 있다. Github Flow는 과거 버전으로 쉽게 돌아가는 등의 안정성을 일부 희생하는 대신 더 낮은 복잡도를 제공한다.  우리는 이 둘과 조금 다른 전략을 사용 중이다. 이를 짧..