기존 배포 방식서비스를 배포할 때마다 이 프로젝트는 내 AWS 계정에 있었는지, 팀원 계정에 있었는지, 프리티어 기간은 아직 남아 있는지, EC2 보안 그룹은 어디까지 열어뒀는지 같은 것들을 먼저 확인해야 했다.정작 서비스 자체는 그렇게 크지 않았는데, 배포를 하려면 주변에 붙어 있는 설정들을 매번 다시 떠올려야 했다.처음에는 그 방식이 크게 불편하지 않았다. AWS 프리티어 인스턴스 하나를 만들고 Docker Compose로 서비스를 올린 다음 nginx를 붙이면 웬만한 개인 프로젝트는 돌아갔고, 필요하면 RDS나 EC2를 하나 더 붙이면 됐으며, 팀 프로젝트에서도 빠르게 결과물을 보여줘야 할 때나 비용 측면에 있어 이 방식이 가장 현실적이었다.. 돈 없는 학생의 삶..문제는 프로젝트가 하나둘 늘어나면..

개발을 하다 보면 이런 경험이 한 번쯤 있을 것 같다.분명히 코드는 맞는 것 같고, GPT, 구글, 스택오버플로우도 뒤졌는데 해결이 안되는 경우. 그러다 몇 시간 뒤에 알고 보면 너무 단순한 이유였던 경우.실수는 실력과 무관하게 반복될 수 있다는 걸, 개발하면서 점점 실감하게 된다.이런 상황을 줄여주는 게 체크리스트다.왜 체크리스트일까항공이나 의료 분야에서는 체크리스트가 이미 표준으로 자리 잡혀 있다. 실수나 문제가 발생하는건 전문가가 몰라서가 아니라, 명시적으로 점검하지 않으면 당연히 됐겠지하고 넘어가기 때문이라고 한다.개발도 비슷한 것 같다. 단 한 줄의 점검이 몇 시간의 삽질을 막아줄 수 있다.막막할 때 꺼내볼 체크리스트1. 운영체제를 재시작해봤는가?생각보다 재시작 한 번으로 해결되는 경우가 생각보..

SSAFY 프로젝트에서 AI, Backend, Frontend를 한 repo에 담으며 고민한 것들SSAFY 프로젝트를 시작하면서 우리 팀은 AI, Backend, Frontend 세 개의 서비스를 동시에 개발해야 했다. 원래라면 각각을 독립된 레포지토리로 관리하는 게 맞겠지만, SSAFY에서는 단일 레포지토리, 단일 인스턴스로 운영해야 한다는 제약이 있었다.그냥 폴더만 나눠서 넣으면 되는 거 아닐까라고 생각했지만, 막상 고민을 시작하니 생각보다 복잡한 문제들이 보이기 시작했다. 로컬에서 개발할 때는 편해야 하고, 나중에 배포할 때도 간단해야 하고, CI/CD 붙일 때도 문제없어야 하고... 심지어 나중에 환경 분리(dev/prod)나 성능 개선도 고려해야 한다.그래서 어떻게 구조를 짜야 할까?에 대한 고..

뒤죽박죽이 되어버린 개발 환경을 정리하며 왜 이 글을 쓰게 되었나지금 우리 서비스는 운영 환경에서 RDS, MongoDB Atlas, S3를 모두 사용하고 있다. 문제는 테스트 서버였다. 비용 문제로 EC2 한 대로 버티다 보니 docker-compose를 이용해 DB와 Redis 같은 것들을 함께 띄워야 했는데, 여기서부터 문제들이 하나둘씩 터지기 시작했다. 문제 1. 환경 설정이 뒤죽박죽초기 .env 설정도 제대로 해두지 않은 상태에서 application-prod.yml에 모든 정보를 몰아넣은 구조였다. 이러다 보니 로컬에서 개발하다가 테스트 데이터를 넣는 과정이 귀찮고 시간이 걸리다 보니 그냥 운영 DB 붙어서 테스트를 하는 등 위험한 상황이 발생했다.과거에 운영 데이터를 건드려서 한번 복구 하는..

현재의 KOSPI 공포·탐욕 지수는 “지금 시장이 과열인지, 위축인지”를 한눈에 판단할 수 있는 1차 목표를 어느 정도 달성했다고 생각한다. 하지만 이 지표가 더 의미 있으려면, 지속적으로 검증되고 확장되는 구조를 가져야 한다고 본다. 1. 서비스 배포 및 접근성 개선우선 가장 가까운 목표는 정식 배포다..사실 개발자의 관점으로 안정적으로 배포하고 싶어서 좀 더 심열을 기울이고 있어 시간이 소모되지만.. 벌써 해당 키워드로 블로그에 유입될 정도로 사용자들이 어느정도 존재할꺼란거 보고 기대가 되서 빨리 배포하고 싶기도.. 무튼 지금까지는 데이터를 검증하고 지표를 계산하는 데 초점을 맞췄다면, 앞으로는 일반 투자자도 부담 없이 접근할 수 있도록 안정적인 배포 환경을 구축할 예정이다.OCI 에서 고자원 리소..

API를 설계하다 보면 아래와 같은 구조로 설계하는 경우가 많았다{ "code": "AUTH_002", "message": "만료된 토큰입니다."}문득 Response를 설계하다가 생각이 들었다. “이미 HTTP Status Code가 있는데, 굳이 body에 또 담아야 할까?” 그래서 해당 고찰을 바탕으로 이 글에서는HTTP Status Code의 본래 역할Body에 status code를 중복해서 담는 패턴의 장단점프로젝트에서의 합리적인 선택 기준을 중심으로 이 질문을 정리해볼까 한다. 1. HTTP Status Code는 왜 ‘고수준’이라고 할까?HTTP Status Code는 의도적으로 고수준(high-level) 으로 설계된 표준이다.HTTP Status Code가 표현하는 것은 딱 하나다..

문제Codetree | Learning to Code with Confidence 알고리즘 [접근 방법]이 문제는 완전탐색 + 부분 조합 최적화 문제로 파악했다내가 처음 접근했을 때는두 도둑이니까 DFS를 두 번 돌려야 하는건가각 도둑의 선택 구간에서 부분집합을 또 만들어야 하는지? 등이런 식으로 고민했는데, 구현 자체는 의외로 단순했다.핵심 포인트는 두 가지다.도둑 A가 고를 수 있는 모든 구간을 탐색도둑 B는 A 구간을 침범하지 않는 곳에서 다시 고르기그리고 각각의 구간에서는“M개의 물건 중 일부를 골라 총 무게 ≤ C 를 만족하면서 가치(무게²) 최대화”라는 배낭문제를 풀어야 하는데,M이 최대 5 수준이라서 굳이 DP를 쓰지 않아도 “정렬 후 그리디”로 해결 가능했다. 사실 정석은 부분집합 전부 탐..

로그인/인증을 구현하다 보면“JWT 쓸까? 세션으로 쓸까?”이 고민을 한 번쯤은 하게 된다.어떤 방법이 더 효율적이고 좋은 방법일지 항상 고민하다막상 구현하고 비교해보니 철학 자체가 다르다는 걸 깨달았다.그래서 이번 2편에서는토큰 기반 인증과 세션 기반 인증을 비교해볼까 한다. 1. 둘의 차이점..?딱 한 문장으로 말하면 자면 음..서버가 인증 상태를 기억하는가 안하는가.세션 기반 인증→ 서버가 나의 로그인 상태를 기억하고 있음 (Stateful)토큰 기반(JWT) 인증→ 서버는 아무것도 기억하지 않음. 클라이언트가 인증 정보 들고 다님 (Stateless)철학부터 달라서, 구조, 운영방식부터 서로 다르다. 2. 세션 기반 인증 흐름세션 기반 인증은 밑과 같이 흘러간다로그인 성공 ↓서버: "해당 유저..