미니베리

0. 배경최근에 React + Spring 기반 풀스택 프로젝트(ChaekList)를 시작하면서 “Codex를 활용한 하네스 엔지니어링 방식으로 개발”을 적용해봤다.하네스 엔지니어링이란?https://miniberry-coding.tistory.com/31결론부터 말하면,AI를 팀원처럼 만들어 “명확한 제한과 방향성을 명시하는 과정”이었다.1. Codex 처음 사용하면서 느낀 점처음에는 이렇게 생각했다.“Chat GPT보다 코드 조금 더 잘 짜주는 모델인가?”실제로 써보니까 완전히 달랐다.프로젝트 전체 구조를 읽음실행 방법을 분석작업을 계획처음 실행했을 때 나온 결과:frontend / backend 구조 분석실행 명령 자동 정리“Codex는 실제로 프로젝트를 이해하고 상황에 맞는 코드를 제시한다”2. ..

1. 하네스 엔지니어링이란 무엇인가최근 LLM 기반 서비스가 발전하면서, 단순히 모델을 잘 사용하는 것만으로는 실제 제품을 만들 수 없다는 한계가 드러나기 시작했다.이 과정에서 등장한 개념이 바로 하네스 엔지니어링(Harness Engineering)이다.하네스 엔지니어링은 다음과 같이 정의할 수 있다.LLM을 중심으로, 모델을 제외한 나머지 모든 실행·제어·검증·관리 시스템을 설계하는 엔지니어링조금 더 직관적으로 말하면,프롬프트 엔지니어링을 넘어, LLM에게 방향성을 제시하는 엔지니어링 기법이다.2. 왜 하네스 엔지니어링이 등장했는가(1) LLM은 완전한 시스템이 아니다LLM은 다음과 같은 한계를 가진다.상태를 기억하지 못한다 (stateless)외부 시스템과 직접 상호작용하지 못한다실행 흐름을 제어할..

1. 문제 요약https://www.acmicpc.net/problem/1781 각 문제마다데드라인 (d)컵라면 수 (c)가 주어진다.모든 문제는 1시간씩 걸리고,각 문제는 데드라인 이전에만 풀 수 있다.→ 목표:얻을 수 있는 컵라면의 최대 개수2. 처음 접근 (틀린 코드)처음에는 이런 식으로 접근했다.heapq.heappush(heap, (dead_line, -cup)) 데드라인 기준으로 정렬하면서같은 데드라인이면 컵라면 많은 것 우선 선택그리고 하나 선택한 뒤while heap and curr >= heap[0][0]: heapq.heappop(heap) 즉,하나 고르면같은 데드라인 이하 문제는 다 버리는 방식3. 왜 틀렸는가?핵심 문제같은 데드라인에서도 여러 개 선택할 수 있다 반례32 102 92..

1. 문제 요약https://www.acmicpc.net/problem/1655 정수를 하나씩 입력받을 때마다지금까지 들어온 값들의 중간값을 출력하는 문제홀수 개 → 정확한 중앙값짝수 개 → 중앙 두 값 중 작은 값2. 처음 접근 (실패)이렇게 생각했다.힙 두 개 쓰면 되지 않을까?min_heap (최소 힙)max_heap (최대 힙처럼 사용, 음수 저장)두 개를 만들고 입력값을 각각 넣어서 길이를 맞추려고 했다.if len(min_heap) > (i+1)//2: heapq.heapreplace(min_heap, x)else: heapq.heappush(min_heap, x) max_heap도 처리하고, 중간값은 출력if i % 2 == 0: print(min(min_heap))else: print(-m..

1. 문제 요약https://www.acmicpc.net/problem/1202보석 N개 (무게 M, 가격 V)가방 K개 (각 가방은 하나의 보석만 담을 수 있음)가방마다 최대 무게 제한 존재→ 목표: 담을 수 있는 보석 가격 합의 최대값2. 처음 접근 (실패)처음에는 이렇게 생각했다.“가장 비싼 보석부터 넣으면 되지 않을까?”그래서 구현:heapq.heappush(jewels, (-v, m)) # 가치 기준 최대힙 그리고:if bags[0] >= m: heapq.heappop(bags) 문제점이 방식은 보석 중심 사고였다.가치 높은 보석부터 꺼냄가장 작은 가방 하나만 보고 넣을지 결정 문제:뒤에 있는 더 큰 가방에 들어갈 수 있는 보석도 그냥 버려짐 핵심 반례2 210 1002 99210 내 코드 결..

1. 문제를 처음 봤을 때처음에는 단순히“카드를 합치면 비용이 든다 → 그냥 순서대로 더하면 되지 않나?”라고 생각했다.하지만 예시를 보면(10 + 20) + (30 + 40) = 100(10 + 40) + (50 + 20) = 120합치는 순서에 따라 비용이 달라진다여기서 핵심은“어떤 순서로 합쳐야 최소가 되는가?”2. 처음 접근 (잘못된 방식)처음에는 이런 식으로 구현했다.answer += answer + heapq.heappop(heap)즉,이전 결과(answer)를 계속 재활용하면서 더하는 방식하지만 이건 문제의 구조를 잘못 이해한 것이다. 왜 틀렸는가?answer는 “총 비용”이지“카드 묶음”이 아니다나는 answer를 카드 묶음처럼 사용해버림3. 핵심 깨달음이 문제에서 중요한 건 딱 하나였다...

1. 문제 요약https://www.acmicpc.net/problem/2075N × N 크기의 표가 주어지고,각 열은 위에서 아래로 갈수록 값이 증가하는 특징을 가진다.→ 목표: 전체 수 중 N번째로 큰 값 찾기2. 처음 접근 (실패)처음에는 단순하게 생각했다.“전체에서 N번째 큰 수니까 다 넣고 뽑으면 되지 않나?”그래서 아래처럼 구현했다.import heapqimport sysinput = sys.stdin.readlineheap = []n = int(input())for i in range(n): row = list(map(int, input().split())) for x in row: heapq.heappush(heap, -x)for _ in range(n): k ..

이번에 React 공부하면서 가장 크게 이해가 정리된 부분이 두 가지였다.하나는 단방향 데이터 흐름, 다른 하나는 컴포넌트의 마운트와 클린업(useEffect)이다.겉으로 보면 단순한 개념인데, 직접 코드로 부딪혀보니까 생각보다 중요한 포인트들이 많이 숨어 있었다.1. 단방향 데이터 흐름 – React의 기본 철학React는 기본적으로 데이터가 위에서 아래로 흐르는 구조를 가진다.부모 컴포넌트가 state를 가지고 있고, 그걸 자식에게 props로 내려준다.function Parent() { const [count, setCount] = useState(0); return setCount(count + 1)} />;} 여기서 중요한 점데이터는 부모 → 자식이벤트는 자식 → 부모 (콜백 함수 호출)처음에..

1. 들어가며BenePicker 프로젝트를 진행하면서 인증을 JWT 기반으로 설계했다.로그인, 토큰발급까지는 비교적 자연스럽게 구현됐지만, 로그아웃 구현에서 예상 밖의 혼란을 겪었다."로그아웃인데… 왜 서버에서 아무것도 안 하지?"이번 글에서는 단순 구현이 아니라, JWT 로그아웃의 본질과 설계 관점에서의 깨달음을 정리해보려고 한다.2. 구현한 로그아웃 코드@PostMapping("/logout")public ResponseEntity logout() { return ResponseEntity.ok().build();} 처음 이 코드를 작성하면서 이런 생각이 들었다.“이게… 로그아웃 맞나?”로직이 없다.DB 접근도 없다.토큰 처리도 없다.그냥 200 OK 반환 끝이다.3. 왜 이렇게 구현했을까?이걸..

1. 들어가며BenePicker 프로젝트를 진행하면서 회원 기능과 조회 기능을 구현하다 보니 자연스럽게 이런 고민이 생겼다.“MyBatis랑 JPA 뭐가 다른거지?”“MyBatis는 XML 써야 되는 거 아닌가?”“어노테이션이 더 편한데 왜 XML 쓰는거지?”처음엔 단순히 “편한 거 쓰면 되는 거 아닌가?”라고 생각했는데, 직접 코드 작성하면서 생각이 완전히 바뀌었다.2. MyBatis vs JPA — 근본적인 차이처음엔 둘 다 그냥 “DB 연결 기술”이라고 생각했는데, 실제로는 패러다임 자체가 다르다는 걸 느꼈다.→ MyBatisSQL을 직접 작성DB 중심 개발SQL → 객체 매핑→ JPA객체(Entity) 중심SQL을 자동 생성객체 → JPA가 SQL 생성2. 핵심 깨달음JPA는 “객체 중심”MyBa..