본문 바로가기

전체 글

표준 라이브러리 네 개 — bisect·itertools·functools·math
Coding Test 2026. 9. 19. 표준 라이브러리 네 개 — bisect·itertools·functools·math 직접 구현하기 전에 표준 라이브러리에 이미 있는지부터 본다. 이분 탐색, 순열·조합, 메모이제이션, 정수 제곱근이 그렇다. 짧아지고 실수가 준다. 다만 넷 다 고유한 함정이 있어서, 꺼낼 때 그 함정도 같이 알아야 한다.bisect — 정렬된 배열에서 위치 찾기이미 정렬된 배열에서 "이 값이 들어갈 자리"를 O(log n)에 찾는다. bisect_left는 그 값 이상이 처음 나오는 자리(lower bound), bisect_right는 그 값을 초과하는 자리(upper bound)다.import bisectarr = [1, 3, 3, 5, 7]bisect.bisect_left(arr, 3) # 1: 3이 들어갈 수 있는 가장 왼쪽bisect.bisect_right(arr, 3) # 3: 3이 들어..
heapq — 최솟값을 반복해서 뽑아야 할 때
Coding Test 2026. 9. 19. heapq — 최솟값을 반복해서 뽑아야 할 때 "지금까지 나온 값 중 가장 작은 것을 꺼내고, 새 값을 넣고, 또 가장 작은 것을 꺼낸다." 이 동작이 반복되면 매번 정렬하는 건 낭비다. heapq는 전체를 정렬하지 않고도 최솟값 하나를 O(log n)에 꺼내 준다. 이 글은 언제 힙을 떠올리고, 파이썬 heapq의 어디서 자주 틀리는지 정리한다.언제 heapq인가최솟값·최댓값 반복 추출. 스케줄링, 우선순위 큐로 돌리는 시뮬레이션.다익스트라. 각 정점까지의 현재 최단 거리 배열과 최소 힙을 함께 쓴다. heapq에는 이미 들어간 값의 우선순위를 낮추는 기능(decrease-key)이 없어서, 더 나쁜 거리로 꺼내진 정점은 그냥 무시하는 지연 처리 방식을 쓴다.상위 K개. heapq.nlargest / nsmallest를 쓰거나, 크기를 K로 유지하..
collections — deque·defaultdict·Counter를 언제 꺼내는가
Coding Test 2026. 9. 19. collections — deque·defaultdict·Counter를 언제 꺼내는가 collections의 자료형은 리스트나 딕셔너리로도 흉내 낼 수 있다. 그런데 흉내 내는 순간 코드가 길어지거나 느려진다. 이 글은 세 자료형을 각각 어떤 신호가 보일 때 꺼내면 되는지, 그리고 꺼낸 뒤에 걸리는 함정이 무엇인지 정리한다.deque — 양끝이 O(1)이어야 할 때list는 끝에 붙이고 빼는 건 빠르지만 맨 앞을 건드리면 O(n)이다. 뒤에 있는 원소를 전부 한 칸씩 밀어야 하기 때문이다. 양쪽 끝을 다 빠르게 여닫아야 하면 collections.deque를 쓴다. 양끝 삽입과 삭제가 모두 O(1)이다.떠올려야 하는 신호는 이렇다.BFS. 큐에서 앞쪽을 꺼내고 뒤쪽에 새 노드를 넣는다. list.pop(0)은 O(n)이라 금지고, deque.popleft()가 O(1)이다. "최단 거리"..
자료형별 시간복잡도 — 같은 in도 비용이 다르다
Coding Test 2026. 9. 19. 자료형별 시간복잡도 — 같은 in도 비용이 다르다 x in 리스트와 x in 집합은 똑같이 생겼다. 그런데 하나는 O(n)이고 다른 하나는 평균 O(1)이다. 파이썬의 자료형은 겉보기 문법이 비슷해도 안에 든 구조가 달라서, 같은 연산이라도 속도가 크게 갈린다. 이 차이를 표로 외우는 대신 손끝에 익혀 두면, 자료를 어디에 담을지 고르는 순간 복잡도가 정해진다.리스트는 동적 배열이다파이썬 list는 이름과 달리 연결리스트가 아니다. 값들을 연속된 메모리에 나란히 늘어놓은 동적 배열에 가깝다. 그래서 "몇 번째 칸"을 지정해 읽고 쓰는 인덱싱은 위치를 바로 계산하므로 O(1)이다. 격자, 누적합 배열, DP 테이블처럼 위치로 바로 접근해야 하는 자료의 기본 그릇이 된다.끝에 붙이는 append도 O(1)로 친다. 가끔 내부에서 더 큰 공간을 다시 잡는 일..
입출력 최적화 — 왜 readline이 필요한가
Coding Test 2026. 9. 10. 입출력 최적화 — 왜 readline이 필요한가 알고리즘은 제대로 짰는데 큰 입력에서만 시간 초과가 나는 코드가 있다. 로컬에서 예제로 돌리면 멀쩡하고, 제출하면 N이 10만쯤 되는 케이스에서 무너진다. 이런 코드는 대개 계산이 아닌 입력을 읽는 데서 시간을 다 쓴다. 이 글은 파이썬에서 입력과 출력이 왜 느려지는지, 어떤 신호가 보일 때 무엇을 바꾸면 되는지를 정리한다.input()은 사람과 대화하려고 만든 함수다CPython에서 input()은 편의 함수다. 호출될 때마다 프롬프트를 띄울 준비를 하고, 한 줄을 읽고, 줄 끝의 개행 문자를 떼어내고, 함수 호출 자체의 비용이 붙는다. 한두 번이면 사람은 못 느낀다. 그런데 첫 줄에 N이 오고 그 뒤로 N개의 줄에 값이 하나씩 오는 문제에서 N이 10만이면, input()을 10만 번 부른다. 이 작..
시작하기 전에 — 왜 맞는 코드가 틀리는가
Coding Test 2026. 9. 10. 시작하기 전에 — 왜 맞는 코드가 틀리는가 코딩 테스트를 처음 준비할 때 거의 모두가 겪는 일이 있다. 예제 입력에서 분명히 맞는 답을 내는 코드를 제출했는데 "틀렸습니다"가 뜬다. 논리는 맞는데 왜 틀릴까. 답은 채점 서버가 코드를 사람처럼 읽지 않고 실제로 돌려 본다는 데 있다. 이 글은 그 채점 방식이 요구하는 세 가지 제약과, 파이썬으로 코드를 짤 때 그 제약에 걸리는 지점들을 정리한다.채점 서버는 코드를 읽지 않고 실행한다학교 시험은 선생님이 답안지를 눈으로 읽고 부분 점수를 준다. 코딩 테스트는 그렇지 않다. 채점 서버는 제출된 코드를 실제로 실행시키고, 미리 준비해 둔 입력 여러 개를 하나씩 흘려 넣은 다음, 프로그램이 내놓은 출력을 정답과 글자 단위로 비교한다. 레시피가 우아한지는 보지 않는다. 완성된 요리와, 요리에 걸린 시간과,..
훅과 미들웨어 — 설명하는 곳과 집행하는 곳
Agent/Agent Harness 2026. 9. 10. 훅과 미들웨어 — 설명하는 곳과 집행하는 곳 시스템 프롬프트 편에서 이 문장을 썼다. 프롬프트는 방침을 설명하는 문서이고, 실제 잠금장치는 코드로 만들어야 한다. 훅과 미들웨어가 그 잠금장치다. 한 줄로 줄이면 이렇게 된다. 시스템 프롬프트가 정책을 설명한다면, 훅은 정책을 집행한다.공장 조립 라인에 비유하면 차이가 분명해진다. 작업자에게 "부품을 잘 확인하세요"라고 말로 부탁하는 것과, 라인 중간에 실제로 부품 치수를 재는 센서를 박아 넣는 것은 신뢰도가 완전히 다르다.훅은 시간이 아니라 경계에 붙는다앞선 편에서 훅을 실행 순서대로 나열했다. 세션 시작, 도구 호출 전, 도구 호출 후 하는 식으로. 그런데 이 목록을 시간순으로 생각하면 왜 그 자리에 있는지가 안 보인다.다시 자르면 훅은 세 개의 경계에 붙는다. 각 경계는 신뢰 수준이 다른 두 세..
에이전트 루프 의사코드
Agent/Agent Harness 2026. 9. 10. 에이전트 루프 의사코드 지금까지 네 기둥과 런타임 패턴 열 개를 따로따로 봤다. 이 편에서는 그것들이 실제로 하나의 실행 흐름으로 어떻게 이어지는지를 코드로 본다.아래는 특정 SDK의 실제 API가 아니다. 하네스의 책임을 드러내기 위한 설계 표현이다. 함수 이름과 주석이 각 단계가 무슨 일을 하는지 설명하도록 풀어서 적었으니, 프로그래밍에 익숙하지 않더라도 순서를 따라가며 읽으면 된다. def run_agent(task, session_id): # 세션을 일회성 채팅이 아니라 "재개 가능한 작업"으로 만든다. # 승인 대기나 배포 재시작으로 중단됐다면 그 지점을 다시 집어 든다. state = load_or_create_checkpoint(session_id) # 과거 메시지를 무작정 붙이지 않고, 지금..
오케스트레이션 여섯 가지는 어떤 생각에서 나왔나
Agent/Agent Harness 2026. 9. 10. 오케스트레이션 여섯 가지는 어떤 생각에서 나왔나 ReAct, Planner-Executor, Supervisor, Orchestrator-Worker, Swarm, Reflexion. 에이전트 이야기에서 자주 나오는 이름들이다.이걸 "모델을 여러 개 쓰는 방법들"로 묶어 이해하면 고를 수가 없다. 정확한 관점은 다르다. 각 패턴은 한 에이전트의 컨텍스트, 계획, 도구 선택이 어느 지점에서 병목이 되는지에 대한 서로 다른 답이다. 병목이 다르니 답도 다르고, 답마다 새로 생기는 문제도 다르다. 작은 식당을 떠올리면 쉽다. 요리사 한 명이 주문부터 조리, 서빙까지 다 해도 문제가 없다. 손님이 많아지고 메뉴가 다양해지면 역할을 나누는 편이 유리해진다. 그런데 나누는 순간 새 문제가 생긴다. 누가 최종 책임자인가. 주문이 잘못 전달되면 누구 책임인가. 오케..
프레임워크 지형 — Deep Agents, Pi, 그리고 이미 쓰는 것들
Agent/Agent Harness 2026. 9. 5. 프레임워크 지형 — Deep Agents, Pi, 그리고 이미 쓰는 것들 이 편은 SDK 카탈로그가 아니다. 시리즈 내내 반복한 원칙을 한 번 더 쓰면 이렇다. 하네스는 프레임워크 이름이 아니라 운영 책임의 묶음이다.그런데 2025년부터 "agent harness"를 전면에 내건 구현체가 부쩍 늘었다. LangGraph나 OpenAI Agents SDK를 쓰고 있는 팀이라면 한 번은 비교해 볼 만하다. 물어야 할 것은 셋이다.이 구현체가 실제로 무엇을 하네스에 묶어 주는가우리 서버(또는 VPC)에서 고객에게 서비스로 제공할 수 있는가그 선택이 가져오는 이점과 숨은 비용은 무엇인가한 가지 미리 밝혀 둔다. 이 분야는 스펙과 호스팅 옵션이 자주 바뀐다. 아래 내용은 방향을 잡는 용도이고, 도입을 검토할 때는 반드시 공식 문서를 다시 확인해야 한다. Deep Agents, Pi, ..
런타임 패턴 8~10 — 권한, 훅, 공급자
Agent/Agent Harness 2026. 8. 31. 런타임 패턴 8~10 — 권한, 훅, 공급자 런타임 패턴 열 개 중 마지막 셋이다. 그리고 이 셋은 앞의 일곱과 성격이 조금 다르다. 앞의 패턴들이 "에이전트가 어떻게 일하게 할까"였다면, 이번 셋은 "에이전트가 무엇을 망칠 수 있는지를 어떻게 줄일까"에 가깝다.솔직히 말하면 셋 다 미뤄지기 쉬운 것들이다. 데모에서는 없어도 잘 돌아가고, 없을 때 생기는 문제는 대개 배포 이후에 나타난다.패턴 8. Scoped Tool Permissions호텔 방 키를 생각해 보자. 그 방 하나만 열린다. 모든 방을 여는 마스터키를 청소 직원 모두에게 나눠주면, 한 사람의 실수나 분실이 건물 전체의 위험이 된다.Scoped Tool Permissions는 에이전트와 도구의 권한을 작업 목적과 수명에 맞게 좁히는 패턴이다. 필요한 이유는 단순하다. 모델의 오류나 프..
런타임 패턴 4~7 — 압축·보관·재개·궤적
Agent/Agent Harness 2026. 8. 31. 런타임 패턴 4~7 — 압축·보관·재개·궤적 앞의 세 패턴이 실행 중에 무엇을 통제할지 다뤘다면, 이번 네 패턴은 실행이 끝난 뒤 무엇이 남는지를 다룬다. 컨텍스트를 어떻게 줄이고, 큰 결과를 어디에 두고, 중단된 작업을 어떻게 이어받고, 무슨 기록을 남길 것인가.네 패턴 모두 한 문장으로 요약되는 재정의를 갖고 있다. 각 절의 첫 문장이 그것이다.패턴 4. Two-stage Compaction압축은 토큰 절감 기능이 아니라 근거 보존 정책이다.Two-stage Compaction(2단계 압축)은 긴 컨텍스트를 한 번에 요약하지 않고 두 단계로 정리하는 패턴이다.이사할 때를 떠올려 보자. 먼저 버릴 물건을 걸러내고, 그다음 남길 물건을 정리해서 상자에 라벨을 붙인다. 두 작업을 한 번에 뒤섞어 하면 중요한 물건을 버리는 실수가 생긴다.이 패턴이 필..

티스토리툴바