LightCS

팀을 믿자가 무관심의 핑계가 되었던 순간2편에서 나는 위기 상황(인력 이탈, 일정 압박) 속에서 통일보다 일관성을 우선하며 완성까지 끌고 가는 선택을 했다.다행히 이후에는 추가 기능 개발과 데이터 분석 결과를 받아 운영 DB에 반영하는 과정까지 안정적으로 마무리할 수 있었다. 위기 상황에서 기준을 세우고 완성까지 끌고 간 경험 자체가 내게 큰 학습이었다.그런데 백엔드의 역할이 끝났다고 해서 프로젝트가 끝나는 건 아니었다.오히려 진짜 어려움은 그 다음부터였다.CSV → S3 → 운영 DB 반영 (최소 수정을 목표로 설계한 분업)프로젝트 후반 운영 DB의 특정 필드를 추출해 CSV로 저장하는 기능을 개발하게 됐다. 원래 요구사항은 CSV를 로컬에 저장하는 것이 아니라 S3에 적재해 데이터 분석 파트가 KPI..

프론트 이탈, 남은 API 약 14개, 그리고 통일보다 일관성을 택한 순간1편에서 나는 프로젝트 초반 대기 시간을 세팅으로 바꾸며 팀이 빠르게 개발을 시작할 수 있는 기반을 만들었다.하지만 프로젝트는 언제나 계획대로만 흘러가지 않는다. 진짜 협업은 안정적인 때가 아니라 위기에서 어떤 선택을 하느냐로 드러난다고 느꼈다.이번 2편은 그 위기 구간의 기록이다.애정이 생긴 이유 ( 누군가만 열심히 하는 팀이 아니었다 )이 프로젝트에 애정이 생긴 이유는 여러 가지가 있지만, 가장 큰 이유는 나뿐만 아니라 팀원 모두가 정말 많은 시간을 투자했기 때문이다.데이터 분석 파트와 파이프라인 구축, 필요한 필드 설계를 맞추기 위해 해당 파트만 따로 회의를 두 번 이상 진행했고, 결정된 기획/요구사항에 맞는 ERD를 설계하기..

내가 리드를 맡아도 되는 걸까..?프로젝트 초반, 나는 “백엔드 리드”를 맡을 생각이 없었다.그런데 일을 처리해 나가다 보니 자연스럽게 그 역할이 되어있었다. 이유는 팀이 ‘대기’에 가까운 상태로 멈춰 보였고, 그 시간을 그냥 흘려보내고 싶지 않았기 때문이다.백엔드 팀은 총 3명이었고 PM 역할을 맡은 팀원도 동시에 백엔드 인력이었다. 문제는 PM이 기획 이슈를 우선 처리하는 동안 백엔드는 당장 착수할 수 있는 개발 업무가 부족해 보였다는 점이다.이때 나는 "기획이 다 정리될 때까지 기다리자"보다 "지금 당장 할 수 있는 것부터 해서 팀이 개발을 시작할 수 있게 만들자"가 더 낫다고 판단했다.일단 움직이자!내가 가장 먼저 한 일은 GitHub 초기 세팅이었다.이런 것들은 개발이 본격적으로 시작되면 오히려..

2025년 8월부터 9월까지 약 두 달 동안 학교 축제 웹사이트 개발 프로젝트를 진행했다.프로젝트가 끝난 지 두 달이 지난 지금에서야 이 회고를 쓰는 특별한 이유가 있다. 단순히 과거를 기록하는 걸 넘어, 지금 진행하는 새 프로젝트에서 똑같은 실수를 안 하기 위해 당시의 상황과 배움을 뼈저리게 되새기기 위함이다.이 프로젝트는 내가 참여했던 것 중 가장 큰 규모였다. 기획 1명, 디자인 4명, 프론트엔드 4명, 백엔드 3명, 총 12명의 팀원이 함께했다. 많은 팀원이 참여한 만큼 새로운 기술도 적극적으로 도입했고 그 과정에서 정말 많은 것을 배웠다.결과적으로는 꽤 성공적이었다. 우리가 만든 웹사이트는 학교 교내 신문에 발행될 정도로 주목받았다. 축제 기간 동안 방문자 수가 엄청나게 높았고, 축제 후 설문 ..

이번의 리눅스 버추얼 머신의 깃허브를 연결할때 https가 막혀 있는 환경이라서 ssh-key로 연결했다.지금부터 github설치부터 연결까지 해보자.1. 초기 설정사용할 pc의 터미널1.1 사용할 pc의 Git 설치하기/* 터미널에 아래 같이 입력한다.* 관리자 권한으로 깃허브를 설치한는 명령어* - 같은 리눅스라도 다를 수 있어요. 버전으로 먼저 설치를 확인하고 따로 검색하면 됩니다.*/sudo dnf install git1.2. 설치 후 올바르게 설치 되었는지 확인하기 git --version1.3. 사용할 계정의 이름과 이메일 주소 설졍 (push를 하려면 한번은 해야 함으로 미리하자!)// 개인적으로는 헷갈리는 것을 방지하기 위해 본인의 깃허브 이메일과 깃허브 닉네임을 사용하는 것을 추천한..

HTTP Method?Http Merhod는 클라이언트(프론트 엔드)와 서버(백엔드) 구조에서 클라이언트가 서버에 요청할때 클라이언트의 요청의 의도를 표현하는 방식이다. 나는 지금까지 데이터를 조회한다 -> Get데이터가 변화한다 -> post위에 같이 생각했다.하지만 이제 부터는 HTTP Method의 의미를 올바르게 알고 사용해야 명세서를 보고 서로 이해를 못하는 문제를 해결할 수 있다.만약 인용 처럼 구분 없이 POST만 사용하면 각각의 API를 이해하기 위해서 백엔드는 꾸준히 API에 대해 설명해야 한다.HTTP Method은 국제적인 합의된 규약이다. 옆집 철수도 건너편 집 벤치 프레스도 같은 생각을 갖고 사용해야 한다.GET리소스 조회 : 단순히 정보를 조회할때 사용한다.저장 되어 있는 값의 ..

나는 이번 프로젝트를 진행하면서 이미지 같이 카카오톡 인증 문제도 만나고 동시성 문제도 만나게 되었다. 이야기할 동시성 문제의 상황은 아래 와 같다.1. 이미 매칭이 진행 중이라면 매칭을 시도해도 할 수 없다.2.소개팅의 기능에서 매칭을 하는 동안 사용자가 소개팅을 신청할 수 없다.이때 일반 boolean을 사용하면 둘 다 성공할 수 있다. 이러한 성공은 큰 장애를 만들 수 있다.신청과 매칭이 동시에 시도 되어 실행 된다면 매칭 도중에 값이 변경된다.int matchingCount = (int)Math.min(Math.min(maleCount, femaleCount), MAX_MATCHING_PAIRS);위에 같이 로직 상에는 최대값, 남자 수, 여자 수 중에서 가장 작은 값을 읽어 사용는 기준 값이 ..

구름톤 유니브 4기에 참여하게 되면서 6월 초 PR을 통해 팀 빌딩을 시작했다. 6월 23일까지 시험 기간으로 잠시 휴식을 취한 후 본격적인 회의와 개발에 돌입했다. 6월 24일부터 7월 11일까지 2주간 초기 기획 회의와 와이어프레임 세팅을 완료하고, 12~13일 대회를 진행했다. 우리 팀은 기획 1명, 디자인 1명, 프론트엔드 2명, 백엔드 2명으로 총 6명이 구성되었다.팀 빌딩부터 걱정 투성이였던 시작PR부터 불안해..사실 PR을 통해 팀을 구성할 때부터 걱정이 많았다. 우리 학교에서 나만 참여를 못하면 어떡하지, 거절당하면 어떡하지 또 백엔드 공부를 시작한 지 얼마 되지 않은 상황에서 다른 참가자들은 경력자일 거라는 생각에 주눅이 들었다. 그래서 나는 협업 능력을 강조하려고 노력했다. 백엔드 개발..

백준 덩치 문제는 몸무게와 키를 비교해 순위를 정하는 문제임다.실버 5에 2시간 이상 체류하는 경험"몸무게 기준으로 정렬하고, 정렬된 상태에서 키를 비교해서 랭킹을 부여하자."Comparable과 Comparator을 사용하는 방법을 찾았다.Comparable은 @Override, compareTo를 통해서 정렬하거나 Comparator은 @Override, compare를 통해서 정렬하는 방식이다.이외에도 람다를 통해 정렬하거나 Stream을 통해 정렬할 수 있지만 주변에서 문제 푸는 것을 보고 "너 이거 코딩테스트에서도 사용할 수 있어?"라는 질문에 나는 뭐 자주 쓰면 손에 익어서 사용하지 않을까? 라고 답했다.하지만 앞으로 자주 사용할 문법인가? 안 외우고 바로 사용할 수 있는가?에 대한 질문에서는..

District - 표준 자치구 테이블서울시의 자치구 정보를 기준으로 범죄와 CCTV 통계를 연결하는 중앙 허브 테이블사용자가 name_kor로 입력 혹은 name_full로 어떤 값으로 입력하든 같은 동작을 하기 위해 name_kor, name_full를 유지한다.필드명설명 district_id 각 자치구를 식별하는 고유 ID (기본 키)name_kor사용자 친화적인 간단한 이름 (예: "강남구")name_full전체 명칭 (예: "서울강남구") – 검색 시 기준 필드로 활용됨District은 CrimeStats, CCTVInfo와 각각 1:N 관계로 연결!CrimeStats – 범죄 통계 테이블자치구별 범죄 유형 및 발생 건수를 저장한 통계 테이블 [공공데이터]김덕배씨가 안전한 집을 확인하기 위해..