GPT-6.1 Sol이 일주일 만에 나왔다 — 6.0은 왜 이렇게 빨리 교체됐을까 성능은 Astra에 가까워졌지만, 5.6보다 느리다는 말이 나오는 이유 2026년 9월 22일 OpenAI가 GPT-6 Sol을 공개했습니다. 그리고 불과 7일 뒤인 9월 29일 GPT-6.1 Sol 이 나왔습니다. 보통 모델 세대에서 6.0 → 6.1 이 일주일 만에 넘어가는 경우는 흔하지 않습니다. 더구나 OpenAI도 6.1을 단순한 작은 수정이 아니라 GPT-6 Sol의 큰 업그레이드 라고 표현했습니다. Coding, Computer Use, 전문 업무 전반에서 성능이 크게 올라갔고, 여러 평가에서는 Astra에 상당히 가까워졌습니다. 그런데 실제 Codex 사용자 반응을 보면 조금 복잡합니다. 성능은 확실히 좋아졌다. 6.0보다 훨씬 낫다. 그런데... 느리다. 생각하는 시간이 길다. 5.6 Sol이 오히려 편한 작업도 있다. 라는 평가가 동시에 나오고 있습니다. 그래서 이번 6.1은 단순히: GPT-6 Sol보다 좋은 모델이 나왔다. 로 끝낼 모델은 아닙니다. 성능, Token 비용, 실제 Token 사용량, 그리고 작업 시간은 서로 따로 봐야 합니다. 1. GPT-6 Sol은 나온 지 일주일 만에 6.1이 됐다 날짜를 놓고 보면 상당히 빠릅니다. 2026.09.22 GPT-6 Sol GPT-6 Luna ↓ 7일 ↓ 2026.09.29 GPT-6.1 Sol GPT-6 Sol 자체도 작은 모델은 아니었습니다. OpenAI는 당시 GPT-6 Astra에서 사용한 Training과 Alignment 개선을 보다 빠르고 저렴한 모델로 가져온 것이 Sol이라고 설명했습니다. 가격도 GPT-5.6 Sol 대비 절반 수준으로 낮췄습니다. 그런데 일주일 만에 다시: GPT-6 Sol ↓ GPT-6.1 Sol 이 등장했습니다. 2. 6.1이 빨리 나온 정확한 이유를 OpenAI가 밝힌 것은 아니다 여기서는 구분할 필요가 있습니다. OpenAI가: GPT-6 Sol에 문제가 많아서 일주일 만에 6.1을 만들었다. 라고 발표한 적은 없습니다. 따라서 이걸 사실처럼 말하면 안 됩니다. 공식적으로 확인되는 건: 6.1은 GPT-6 Sol의 큰 업그레이드 Coding 크게 개선 Computer Use 개선 전문 업무 개선 Instruction / Alignment 개선 비용 효율 개선 정도입니다. 하지만 출시 직후 상황을 보면 6.0에 손볼 곳이 적지 않았다는 사실도 보입니다. GPT-6 Sol에서는 실제 문제가 있었다 3. 출시 사흘 뒤 Image Understanding 버그가 수정됐다 GPT-6 Sol 출시일은 9월 22일입니다. 그런데 9월 25일 OpenAI Release Note에 이런 수정이 올라왔습니다. GPT-6 Sol과 Luna의 Image Encoding 문제 때문에 이미지 이해 성능이 떨어지는 버그가 있었고 이를 수정했다 는 내용입니다. Codex와 Computer Use의 Visual Task에도 영향을 줬습니다. 즉 적어도 이 부분은 사용자 추측이 아니라 공식 확인된 문제입니다. GPT-6 Sol 출시 ↓ Image Encoding 문제 ↓ Visual Understanding 저하 ↓ 3일 뒤 수정 Computer Use를 중요하게 내세운 GPT-6 모델에서 꽤 민감한 문제였습니다. 4. Coding 쪽에서는 다른 불만도 빠르게 나오기 시작했다 이쪽은 공식적으로 확인된 버그와는 다릅니다. OpenAI Developer Community와 Codex 사용자 커뮤니티에서는 출시 직후 다음과 같은 경험담이 올라왔습니다. 간단한 작업이 너무 오래 걸린다. 계획만 세우다 시간이 많이 지나간다. 지시 범위를 벗어난다. 명확한 요청을 놓치는 경우가 있다. 5.6 Sol보다 작업이 답답하다. OpenAI Developer Community에는 평소 몇 분 걸리던 작업이 수십 분에서 한 시간 이상 걸렸다는 사례도 올라왔습니다. 한 사용자는 GPT-6 Sol 작업이 평소보다 10~20배 길어졌다고 보고했습니다. Reddit에서도 동일한 작업을 GPT-6 Sol과 5.6 Sol에 각각 맡겼을 때 5.6이 훨씬 빨리 진행됐다는 경험담들이 나왔습니다. 다만 이런 자료는 통제된 Benchmark가 아니라 사용자 경험이라는 점은 반드시 감안해야 합니다. 5. 그런데 공식 Benchmark에서 GPT-6 Sol은 5.6보다 좋았다 재미있는 부분입니다. OpenAI가 발표한 평가에서는 GPT-6 Sol이 GPT-5.6 Sol보다 분명히 좋아졌습니다. 특히 실제 Repository에서: 코드 수정 Test 품질 수정 범위 Coding Style Repository 규칙 준수 까지 평가하는 FrontierCode에서 개선됐습니다. 게다가 API 가격은: GPT-5.6 Sol Input $4 Output $20 ↓ GPT-6 Sol Input $2 Output $10 으로 절반이 됐습니다. 즉 공식적으로 보면: 성능 ↑ 가격 ↓ 였습니다. 그런데 실사용에서는: 작업 시간 ↑ ? 생각하는 시간 ↑ ? 체감 집중력 ↓ ? 이라는 불만이 일부 나온 겁니다. 이게 이번 모델을 이해할 때 중요한 부분입니다. 6. 그리고 6.1에서 성능이 다시 크게 뛰었다 GPT-6.1 Sol은 단순히 6.0의 작은 Patch가 아닙니다. OpenAI의 공식 평가를 보면 차이가 상당합니다. DeepSWE v1.1에서는 GPT-6 Sol의 최고 점수를 6.4%포인트 넘으면서도 더 낮은 Reasoning Effort와 비용 을 사용했습니다. AutomationBench에서도 같은 Reasoning 설정의 GPT-6 Sol보다: +4.8%p 높았습니다. Computer Use를 평가하는 OSWorld 2.0에서는 최대 Reasoning 설정 기준: GPT-6 Sol 대비 +7%p 올라갔습니다. Terminal-Bench Science에서는 6.0의 점수를 2배 이상 으로 끌어올리면서 작업당 비용은 절반 이하였습니다. 일주일 차이 모델치고 변화 폭이 꽤 큽니다. 7. 그래서 이름도 단순 GPT-6 Sol Refresh가 아니라 6.1이다 결과적으로: GPT-6 Sol → 저렴한 GPT-6 GPT-6.1 Sol → Astra에 가까운 실전 고성능 모델 로 성격이 조금 달라졌습니다. OpenAI도 6.1을: Near-Astra performance 라고 표현합니다. 1.05M Context와 128K 최대 Output은 그대로지만 모델의 실제 문제 해결 능력이 Astra 쪽으로 이동했습니다. 8. 특히 Coding에서 Astra와 상당히 가까워졌다 OpenAI가 6.1에서 가장 강조하는 영역도 Agentic Coding입니다. DeepSWE에서는 GPT-6.1 Sol이 약 5분의 1 비용으로 Astra와 비슷한 수준 까지 올라왔습니다. 구조적으로 보면: GPT-6 Astra 가장 높은 성능 가장 어려운 문제 ↓ GPT-6.1 Sol Astra에 가까운 성능 훨씬 낮은 비용 ↓ GPT-6 Luna 대량 작업 낮은 비용 이 훨씬 명확해졌습니다. 9. Computer Use도 6.1의 큰 변화다 Coding만 좋아진 것도 아닙니다. OSWorld에서 6.1은 6.0보다 크게 향상됐고, 최대 Reasoning에서는 Astra와의 차이가 2.1%포인트까지 줄었습니다. 그런데 작업당 비용은 Astra의 약 7분의 1 수준이었습니다. 그래서 6.1의 용도는: 코드 작성 Browser 사용 GUI 조작 문서 처리 Business Workflow Agent 작업 을 묶어서 오래 수행하는 쪽에 가깝습니다. 10. Multi-Agent도 6.1부터 붙었다 GPT-6.1 Sol에는 또 하나 중요한 변화가 있습니다. Responses API에서 Multi-agent Beta 를 지원합니다. Root Agent가 작업을 나눠 Subagent에게 넘길 수 있습니다. 예를 들어: GPT-6.1 Sol │ ┌───────┼───────┐ ↓ ↓ ↓ Agent Agent Agent 탐색 구현 Test 같은 구조가 가능합니다. 단순 모델 성능 향상보다 Agent Runtime에서 쓰기 위한 변화가 더 많아지고 있습니다. 그런데 여기서 문제가 하나 있다 11. 6.1도 여전히 느리다는 이야기가 많다 GPT-6.1이 나온 뒤 첫 반응 중 가장 많이 보이는 말 중 하나가: 좋긴 좋은데 정말 느리다. 입니다. 현재 Codex 커뮤니티에서는: 6.0보다는 훨씬 좋다. 결과물도 괜찮다. 사용 한도도 적게 줄어드는 것 같다. 그런데 작업 시간이 너무 길다. 는 경험담이 반복적으로 나오고 있습니다. 일부 사용자는 5.6 Sol보다 Token 생성 속도가 체감상 2~3배 느리다고 측정했고, 긴 Coding 작업에서 몇 분간 눈에 띄는 진행이 없는 경우도 보고하고 있습니다. 이는 서버 부하나 계정·처리 Tier에 따라 달라질 수 있는 커뮤니티 측정값이지 공식 성능 수치는 아닙니다. 12. 이건 ‘Token이 싸다’와 전혀 다른 문제다 AI 비용 이야기를 할 때 세 가지를 구분해야 합니다. Token 가격 Token 사용량 Wall-clock Time 입니다. 셋은 같은 개념이 아닙니다. 예를 들어: 모델 A 10,000 tokens 30초 $1 모델 B 8,000 tokens 3분 $0.50 이라면 모델 B는: Token 효율 ↑ 가격 효율 ↑ 일 수 있지만, 시간 효율 ↓ 입니다. 현재 GPT-6.1 Sol에서 보이는 현상도 이 구분으로 보는 게 좋습니다. 13. API 가격만 보면 6.1은 5.6보다 훨씬 싸다 현재 표준 짧은 Context 기준 가격을 보면: GPT-5.6 Sol GPT-6.1 Sol Input $4 $2 Cached Input $0.40 $0.10 Cache Write $5 $2.50 Output $20 $10 100만 Token 기준입니다. GPT-5.6 Sol의 현재 가격은 프로모션 가격이고, OpenAI는 최소 2026년 11월 21일까지 이를 유지한다고 안내하고 있습니다. 단가만 보면: Input 50% 감소 Output 50% 감소 Cache Read 75% 감소 입니다. 특히 Cache는 차이가 큽니다. 14. Repository를 계속 읽는 Agent라면 Cache 차이가 상당하다 Coding Agent는 매 요청마다 완전히 새로운 Context만 처리하지 않습니다. 계속 반복되는 내용이 많습니다. System Prompt AGENTS.md Tool Schema Repository Context Architecture 문서 이전 작업 내용 이런 부분이 Cache에 들어가면: GPT-5.6 Sol $0.40 ↓ GPT-6.1 Sol $0.10 입니다. Agent가 오래 실행될수록 이 차이는 꽤 커집니다. 6.1이 비용 기준으로 효율이 좋다 고 OpenAI가 강조하는 이유 중 하나입니다. 15. 그런데 Token을 실제로 덜 쓰는지는 별개의 문제다 여기서는 주의해야 합니다. OpenAI는: GPT-6.1 Sol은 항상 GPT-5.6 Sol보다 몇 퍼센트 적은 Token을 사용한다. 같은 일반적인 수치를 공개하지 않았습니다. 작업마다 완전히 다릅니다. 오히려 복잡한 Agent 작업에서는: 더 긴 Reasoning 더 많은 탐색 더 많은 Tool Call 더 긴 작업 지속시간 이 생길 수도 있습니다. 따라서: 6.1이 싸다 = 무조건 Token을 적게 쓴다 는 아닙니다. 16. 특히 Reasoning 설정에서 5.6과 중요한 차이가 있다 GPT-5.6 Sol은: none low medium high xhigh max 를 지원합니다. 반면 GPT-6.1 Sol은: low medium high xhigh max 이고, none 과 minimal 을 지원하지 않습니다. 이건 작은 차이처럼 보이지만 일상 Coding에서는 꽤 중요할 수 있습니다. 17. 5.6은 아예 ‘생각하지 말고 빨리 실행’이 가능하다 예를 들어 작업이: 버튼 이름 변경 문자열 수정 간단한 View 추가 정해진 Pattern대로 파일 생성 처럼 명확하다면 긴 Reasoning이 필요하지 않습니다. GPT-5.6 Sol은: reasoning.effort = none 으로 이런 작업을 처리할 수 있습니다. 하지만 6.1은 최소가: low 입니다. 따라서 구조적으로도 6.1은 어느 정도 Reasoning을 항상 수행하는 모델 에 가깝습니다. 단순한 작업에서 5.6이 더 빠르고 가볍게 느껴질 수 있는 이유 중 하나로 볼 수 있습니다. 이건 OpenAI가 공식적으로 “5.6이 더 빠른 이유”라고 설명한 것은 아니지만, 두 모델의 설정 차이에서 자연스럽게 예상할 수 있는 부분입니다. 18. Medium이 기본이라는 것도 중요하다 GPT-6.1 Sol의 기본 Reasoning Effort는: medium 입니다. Coding 작업에서 아무 설정 없이 실행하면 어느 정도의 Reasoning이 기본적으로 들어갑니다. 그리고: high xhigh max 로 올릴수록 일반적으로 더 오래 생각하고 더 많은 Reasoning Token을 사용할 가능성이 높아집니다. 그래서 단순한 Coding 작업까지 무조건: 6.1 Sol Max 로 돌리는 건 좋은 사용법이라고 보기 어렵습니다. 19. 6.1은 ‘빠르게 대답하는 모델’보다 ‘끝까지 해결하는 모델’에 가깝다 GPT-5.6 Sol을 사용할 때 만족도가 높았던 작업 중에는 이런 것이 많습니다. 정확하게 요청한 것만 수정 빠르게 코드 작성 짧은 반복 작업 즉각적인 피드백 반면 6.1이 목표로 하는 영역은 조금 다릅니다. 복잡한 Repository 긴 Coding 작업 Computer Use 여러 Tool 사용 전문 업무 Multi-Agent Long-horizon Workflow 입니다. 따라서 사용 경험 자체도 달라질 수밖에 없습니다. 20. 문제는 개발자는 Benchmark보다 기다리는 시간을 먼저 느낀다는 것 공식 Benchmark에서: +6.4%p +7%p 2배 이상 같은 개선이 있어도, 개발자가 실제로 보는 화면이: Thinking... Thinking... Tool... Thinking... 이라면 체감은 좋지 않을 수 있습니다. 특히 Coding은 대화형 작업입니다. 수정 ↓ 확인 ↓ 추가 요청 ↓ 수정 ↓ Build 을 반복합니다. 한 번의 결과가 조금 더 정확해도 매번 기다리는 시간이 길어진다면 생산성이 반드시 좋아지는 건 아닙니다. 21. 그래서 ‘효율’을 하나의 숫자로 보면 안 된다 GPT-6.1 Sol과 GPT-5.6 Sol을 비교하면 이렇게 보는 게 훨씬 정확합니다. 기준 GPT-5.6 Sol GPT-6.1 Sol API Token 단가 높음 낮음 Cache 비용 높음 매우 낮음 복잡한 Agent 성능 좋음 더 강함 Astra 근접 성능 낮음 높음 reasoning:none 가능 불가 짧은 수정 체감 유리할 수 있음 Reasoning Overhead 가능 긴 복잡한 작업 좋음 유리 현재 체감 속도 빠르다는 사용자 많음 느리다는 보고 많음 마지막 줄은 공식 Benchmark가 아니라 현재 사용자 경험을 정리한 것입니다. 22. 재미있는 건 ‘느린데 사용량은 잘 안 줄어든다’는 반응도 많다는 것 6.1 사용자 반응은 조금 이상하게 갈립니다. 한쪽에서는: 너무 느리다. 한 작업에 너무 오래 걸린다. 라고 하고, 다른 쪽에서는: 몇 시간 사용했는데 Weekly Usage가 거의 안 줄었다. 라고 합니다. 이 두 이야기는 동시에 사실일 수 있습니다. 왜냐하면: 사용 한도 소모 ≠ 실제 작업 시간 이기 때문입니다. 구독 서비스의 Usage Meter 역시 단순 Raw Token 숫자만 보여주는 지표라고 볼 수 없습니다. 23. 그래서 ‘6.1은 Token을 적게 쓴다’고 단정하는 것도 아직 이르다 지금 커뮤니티를 보면: 사용량이 거의 안 줄었다 는 사람도 있고, 긴 작업 하나에 사용량이 크게 줄었다 는 사람도 있습니다. Processing Tier, Effort, Context 크기, Tool 사용량, 작업 종류에 따라 결과가 크게 달라집니다. 따라서 지금 시점에서 가장 안전한 표현은: 6.1은 API 단가와 공식 작업당 비용은 매우 낮아졌지만, 실제 Token 소비량과 구독 사용량은 작업마다 크게 달라진다. 입니다. 24. 반대로 OpenAI의 공식 ‘작업당 비용’ 결과는 상당히 좋다 단순 Token 가격 말고 실제 Benchmark 작업 하나를 끝내는 비용을 보면 6.1이 상당히 강합니다. Terminal-Bench Science 최대 Effort에서 OpenAI가 발표한 평균 작업 비용은: GPT-6.1 Sol $5.47 였습니다. 비교 대상으로 제시된: Claude Opus 5.5 $23.21 GPT-6 Astra $23.80 보다 75% 이상 낮았습니다. 즉 복잡한 작업에서는 오래 생각하더라도 문제를 실제로 해결하는 데 들어가는 금액은 낮을 수 있습니다. 25. 그래서 Token Efficiency와 Time Efficiency를 나눠서 봐야 한다 정리하면 이렇습니다. 비용 효율 6.1 Sol ★★★★★ API 가격과 Cache는 확실히 좋아졌습니다. 복잡한 문제 해결 효율 6.1 Sol ★★★★★ 공식 Benchmark에서는 6.0과 5.6보다 확실히 강합니다. 짧은 작업의 반응 속도 5.6 Sol이 더 편한 경우가 있음 특히 빠르게 수정하고 결과를 보는 작업입니다. 긴 Agent 작업 6.1 Sol이 더 적합 한 번 맡긴 뒤 오래 실행시키는 작업입니다. 26. 5.6이 아직도 좋은 이유도 여기에 있다 새 모델이 나왔다고 5.6 Sol의 장점이 갑자기 없어지는 건 아닙니다. 5.6은 꽤 오랫동안 실제 개발자 Workflow에서 다듬어졌습니다. 그리고 사용 방식도 단순합니다. 요청 ↓ 빠르게 이해 ↓ 수정 ↓ 결과 특히 사용자가 원하는 범위가 명확할 때 좋은 경험을 주는 경우가 많습니다. 현재 커뮤니티에서도: 6.1의 결과는 좋지만 빠른 반복 작업은 5.6이 더 편하다. 는 반응을 쉽게 볼 수 있습니다. 27. 그렇다고 5.6이 더 좋은 모델이라고 볼 수도 없다 반대도 마찬가지입니다. 공식 평가에서는 6.1이: Agentic Coding Computer Use 전문 문서 Business Workflow 과학 작업 Alignment 대부분에서 6.0을 크게 앞서고 Astra에 접근합니다. 보안 평가에서도 일부 항목은 5.6보다 크게 향상됐고, Chain-of-Thought 제어 능력 역시 5.6보다 높아졌습니다. 따라서: 5.6 → 빠른 반복에 좋은 모델 6.1 → 더 큰 일을 해결하는 모델 정도로 보는 게 지금은 가장 자연스럽습니다. 28. 실제 Codex에서는 작업에 따라 나눠 쓰는 게 좋다 예를 들어 이런 작업이라면 5.6이 여전히 편할 수 있습니다. 간단한 UI 수정 이름 변경 작은 Bug Fix 정해진 Pattern 반복 짧은 Refactoring 빠른 질문 / 확인 반면 6.1은 이런 작업에서 매력적입니다. Architecture를 이해해야 하는 수정 복잡한 Bug 추적 대규모 Refactoring Repository 전체 탐색 Computer Use 여러 Tool을 사용하는 작업 오래 걸리는 Coding Agent 작업 29. 6.1에서는 Medium부터 쓰는 게 더 중요해졌다 6.1이 강하다고 처음부터: High XHigh Max 만 쓰면 기다리는 시간이 상당히 길어질 수 있습니다. 따라서 일반 Coding에서는: Medium 부터 시작하는 게 좋습니다. 문제가 잘 해결되지 않을 때: Medium ↓ High ↓ XHigh 순서로 올리는 편이 낫습니다. Max 는 정말 복잡한 작업을 장시간 맡길 때 쓰는 쪽이 자연스럽습니다. 30. 그리고 긴 작업은 오히려 밤새 맡기는 방식이 잘 맞는다 6.1에 대한 현재 사용자 반응 중 재미있는 표현이 있습니다. Overnight task에 좋다. 즉: 개발자와 계속 대화하는 모델 보다 큰 작업을 맡겨놓고 나중에 결과를 보는 모델 에 더 잘 맞는다는 의미입니다. Codex가 점점 Background Agent 쪽으로 가고 있다는 걸 생각하면 이상한 방향도 아닙니다. 31. 속도가 중요하다면 결국 Fast와 Ultrafast가 있다 OpenAI 역시 속도를 별도의 제품 축으로 만들고 있습니다. GPT-6.1 Sol에는 향후 Ultrafast 가 제공될 예정이며, OpenAI는 Standard 대비 최대 8배 빠른 Token 생성을 예고하고 있습니다. DevDay 기준으로 Codex에서는 최대 약 30
오늘의 인프런 강의 폴리싱 및 버그 해결에 생각보다 많은 시간이 소요되어 프로젝트 개발 일정이 지연되었다. 이에 오늘도 강의 수강을 생략하고 프로젝트 개발에 집중하였다. 방어구 & 방패 시스템이 어느정도 일단락되면 다시 강의 수강을 재개할 예정이다. 오늘의 프로젝트 개발 -> 링크 Blocking Locomotion Blocking 시스템 Parrying 시스템
AWS 네트워크 전체 구조 AWS 네트워크를 공부할 때 패킷이 목적지까지 이동하는 과정을 이해하면 좋은 거 같다. 패킷이 이동할 때는 항상 이 순서대로 확인한다. 1. 주소가 무엇인가? — IP, CIDR, VPC, Subnet, ENI 2. 어디로 보내야 하는가? — Route Table, IGW, NAT, Endpoint 3. 통과해도 되는가? — Security Group, NACL, WAF, Firewall 4. 어떤 서버로 전달할 것인가? — Route 53, ALB, Target Group 5. 문제가 생겼을 때 어디서 막혔는가? — Flow Logs, Reachability Analyzer, CloudWatch AWS에서 VPC는 논리적으로 격리된 가상 네트워크 이고 그 안에 서브넷,라우팅,게이트웨이,보안 규칙을 구성한다. 서브넷은 반드시 하나의 가용 영역에 속한다. 일반적인 웹 서비스 구성 사용자 -> example.com Route 53 - DNS 주소 조회 -> CloudFront / WAF - 선택 사항 -> Internet Gateway -> ALB - Public Subnet A, B Listener Rule Target Group -> EC2 / ECS - Private App Subnet A, B -> RDS - Private DB Subnet A, B EC2의 외부 통신 인터넷 → NAT Gateway → Internet Gateway S3 등 AWS 서비스 → VPC Endpoint 요약 구성요소 핵심 역할 VPC 네트워크 전체 경계 CIDR VPC와 서브넷에서 사용할 IP 범위 Subnet VPC를 가용 영역별,용도별로 분할 Route Table 목적지에 따라 패킷의 다음 경로 결정 Internet Gateway VPC와 인터넷 연결 NAT Gateway 프라이빗 서버의 IPv4 외부 통신 Security Group EC2, ALB, RDS 단위 방화벽 NACL 서브넷 단위 방화벽 Route 53 도메인을 주소로 변환 ALB HTTP 요청을 적절한 서버에 분배 Target Group ALB가 요청을 보낼 서버 묶음 VPC Endpoint 인터넷 없이 AWS 서비스에 접근 Flow Logs 네트워크 허용 거부 기록 IP 주소와 CIDR IP 주소 IP 주소는 네트워크에서 서버를 구분하는 주소 EX) 10.0.10.25 AWS에서는 EC2, RDS, ALB 같은 리소스의 네트워크 인터페이스에 IP가 할당됩니다. 사설 IPv4 VPC 내부에서 사용하는 주소 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 일반적으로 AWS VPC에는 10.x.x.x 대역을 많이 사용 10.0.0.0/16 10.10.0.0/16 10.100.0.0/16 공인 IPv4 인터넷에서 접근할 수 있는 주소 EC2에 자동 할당되는 공인 IPv4는 인스턴스를 중지했다가 다시 시작하면 바뀔 수 있다. 고정 공인 IPv4가 필요하면 Elastic IP를 사용한다. ** Elastic IP - AWS에서 할당받는 고정 공인 IPv4 주소 EC2의 네트워크 인터페이스에는 기본적으로 사설 IP가 있고 공인 IPv4는 인터넷 게이트웨이를 통해 사설 IP와 매핑된다. CIDR CIDR는 IP 주소의 범위를 표현하는 방식 10.0.0.0/16 IPv4는 총 32비트 /16은 앞의 16비트가 네트워크 영역이라는 뜻 즉 32- n비트를 사용가능하니까 2^(32-n)개만큼 사용가능함 CIDR 전체 IP 개수 AWS 서브넷에서 사용 가능한 IPv4 /16 65,536 65,531 /20 4,096 4,091 /24 256 251 /26 64 59 /28 16 11 AWS는 각 IPv4 서브넷에서 처음 네 주소와 마지막 한 주소 총 5개를 예약한다. EX) 10.0.1.0/24라면 .0, .1, .2, .3, .255를 사용할 수 없고 일반 리소스에는 .4부터 .254까지 할당할 수 있다. IPv4 서브넷의 크기는 /28부터 /16 범위로 생성할 수 있다. EX) VPC: 10.0.0.0/16 일 때 VPC를 용도와 가용 영역에 따라 나눌 수 있다. Public A: 10.0.0.0/24 Public B: 10.0.1.0/24 Private App A: 10.0.10.0/24 Private App B: 10.0.11.0/24 Private DB A: 10.0.20.0/24 Private DB B: 10.0.21.0/24 CIDR 설계에서 가장 중요한 규칙 서로 연결할 가능성이 있는 네트워크의 CIDR는 겹치면 안된다. prod VPC: 10.0.0.0/16 dev VPC: 10.1.0.0/16 회사망: 10.100.0.0/16 다음과 같이 겹치면 향후 VPC Peering, Transit Gateway, VPN 연결 시 목적지를 구분하기 어렵다. prod VPC: 10.0.0.0/16 dev VPC: 10.0.0.0/16 !! 겹침 AWS IPAM은 조직 전체의 IP 대역을 계획하고 할당 내역과 사용 현황을 관리할 수 있는 서비스 어떤 VPC에 어떤 CIDR를 쓰고 있는지 앞으로 어떤 IP 대역을 어디에 배정할지 관리하는 장부 느낌 ENI와 사설 IP가 리소스에 할당되는 방식 ENI(Elastic Network Interface)는 AWS 리소스에 연결되는 가상 네트워크 카드 EC2가 VPC 안에서 다른 리소스와 통신하려면 ENI를 통해 네트워크에 연결된다. EC2를 특정 서브넷에 생성하면 AWS는 해당 서브넷의 CIDR 범위에서 사용 가능한 사설 IP를 하나 할당하고 이 IP를 EC2의 ENI에 연결한다. Private App Subnet: 10.0.10.0/24 -> EC2 생성 연결 -> ENI 생성 Private IP: 10.0.10.25 MAC Address Security Group EX) 10.0.10.0/24 서브넷에 EC2를 생성하면 10.0.10.25와 같이 해당 서브넷 범위 안의 사설 IP가 할당된다. EC2 자체에 IP가 직접 붙는다고 보기보다는 EC2에 연결된 ENI에 IP 주소가 할당되고 EC2가 해당 ENI를 통해 통신한다. * Security Group 역시 EC2 자체보다는 ENI에 적용된다. * 따라서 ENI에는 사설 IP뿐 아니라 해당 네트워크 인터페이스의 트래픽을 제어하는 Security Group도 함께 연결된다. 하나의 ENI에는 기본 사설 IP 외에 여러 개의 Secondary Private IP를 추가 할 수 있으며 EC2 인스턴스 타입에 따라 여러 개의 ENI를 연결하는 것도 가능하다. EX) EC2에 연결된 ENI 1- 10.0.10.25, 10.0.10.26 ENI 2- 10.0.20.15 EC2에 공인 IPv4가 할당된 경우에도 실제 EC2 내부에서는 주로 사설 IP를 사용한다. AWS가 외부의 공인 IPv4와 ENI의 사설 IP를 매핑하여 인터넷 통신이 가능하도록 처리한다. Internet Public IP: 3.34.100.20 AWS에서 주소 매핑 Private IP: 10.0.10.25 ENI EC2 ENI는 EC2뿐 아니라 RDS, ALB, NAT Gateway, VPC Endpoint 등 VPC 안에서 동작하는 여러 AWS 서비스에서도 사용된다. AWS에서 리소스가 VPC 네트워크에 참여하려면 서브넷의 IP를 할당받고 네트워크 인터페이스를 통해 통신하는 구조이다.
오늘은 사용자 앱의 입구(스플래시 → 로그인 → 온보딩)와 핵심 화면인 스와이프 피드를 만들었다. API 연동 전이라 로그인과 피드 데이터는 모두 mock이다. 0. 작업 방식: Figma MCP로 디자인 읽기 이번 작업은 Claude Code에 Figma MCP를 연결해서 진행했다. 화면을 만들 때마다 Figma 링크의 노드를 읽어서, 크기·색·글자 스펙을 눈대중이 아니라 실제 값으로 가져왔다. 활용 방법 화면 스펙 읽기: 노드를 읽으면 요소별 크기, 여백, 색 토큰, 글자 크기가 나온다. 예를 들어 포스터 카드는 폭 328, 사진 높이 320, 모서리 12, 가게 이름 24px Bold처럼 정확한 값으로 확인했다. 디자인 시스템과 비교: 화면 값이 디자인 시스템 스케일에 있는지 확인했다. 화면은 좌우 여백 20px인데 그리드는 16px이고, 버튼 모서리 14px은 Radius 스케일(4, 8, 12, 16)에 없었다. 이런 경우는 디자인 시스템 기준으로 맞췄다. 디자인 수정: 스플래시 버튼 삭제처럼 Figma 자체를 고칠 때는 Codex에 Figma MCP 작업을 맡겼다. 이 과정에서 화면만 봤다면 지나쳤을 불일치도 꽤 찾았다. 성별 선택 칩 중 "기타"가 레이어 이름은 아직 "입력 안 함"이고 스타일도 달랐다. 마스코트 컴포넌트 이름이 Coupon Success 인데, 실제 그림은 X 표시된 쿠폰(쿠폰 없음)이었다. 디자인 시스템 안에서도 Button 컴포넌트(모서리 14)와 Radius 스케일이 서로 달랐다. 코드에서는 모두 디자인 시스템 기준으로 맞춰서 구현했다. 1. 로그인 흐름 로그인 상태 관리 (Context) 로그인한 사용자 정보는 라우트 가드, 온보딩 완료 처리, 마이페이지 등 여러 화면에서 필요하다. props로 한 단계씩 내려주면 중간 컴포넌트가 쓰지도 않는 값을 계속 넘겨야 한다. 그래서 React Context로 앱 전체에 공유했다. 파일 역할 authContext.ts 로그인 정보가 지나갈 통로를 만든다 AuthProvider.tsx 실제 값( useState )을 들고 아래로 전달한다 useAuth.ts 화면에서 const { user, login } = useAuth() 로 꺼내 쓴다 AuthProvider 를 앱 가장 바깥에 두니, 어느 화면에서든 로그인 정보를 바로 받을 수 있게 됐다. 상태별 라우트 가드 사용자 상태를 세 가지로 나눴다. 상태 갈 수 있는 화면 다른 화면에 들어오면 로그인 전 스플래시, 로그인 스플래시로 이동 온보딩 중 온보딩 온보딩으로 이동 회원 탭 화면 스와이프로 이동 화면마다 조건을 넣지 않고, 라우터에서 화면 묶음 단위로 감쌌다. { element: <RequireAuth access="guest" />, children: [스플래시, 로그인] }, { element: <RequireAuth access="onboarding" />, children: [온보딩] }, { element: <RequireAuth access="member" />, children: [탭 화면] }, 앞으로 화면을 추가할 때는 알맞은 묶음 안에 넣기만 하면 된다. 스플래시 화면 하단 버튼 삭제 처음 디자인은 스플래시에 [시작하기] 버튼이 있고, 버튼을 누르면 로그인 화면으로 넘어가는 구조였다. 그런데 로그인 화면에도 소개 문구와 [카카오로 시작하기] 버튼이 있어서, 사용자는 비슷한 화면을 두 번 보고 버튼도 두 번 눌러야 했다. 스플래시는 앱을 열 때 브랜드를 잠깐 보여주는 화면이면 충분하다고 판단했다. 그래서 버튼을 없애고, 1.5초 뒤 로그인 화면으로 자동으로 넘어가게 했다. 넘어갈 때는 replace 로 이동해서 방문 기록에서 스플래시를 지웠다. 로그인 화면에서 뒤로 가기를 눌러도 스플래시가 다시 나오지 않는다. 2. 스와이프 피드 드래그 제스처 (Pointer Events) 일정이 빠듯해서 버튼으로 찜/패스를 먼저 완성하고, 드래그 제스처는 그다음에 붙였다. 제스처도 결국 같은 찜/패스 함수를 부르기 때문에, 버튼으로 동작을 먼저 확인해 두니 제스처는 "끌기와 방향 판단"만 추가하면 됐다. 제스처 라이브러리는 새 패키지라 팀 합의가 필요해서, 브라우저 기본 기능인 Pointer Events로 직접 만들었다. onPointerDown // 시작 위치 기억 onPointerMove // 움직인 만큼 카드 이동, 살짝 기울이기 onPointerUp // 카드 폭의 30% 넘게 밀었으면 찜/패스, 아니면 제자리로 touch-action: pan-y 를 줘서 위아래로 끌면 화면이 스크롤되고, 좌우로 끌 때만 카드가 움직이게 했다. 화면 높이에 맞춘 카드 크기 이 부분에서 시행착오가 있었다. 고정 높이: Figma대로 카드 높이를 고정했더니, 긴 폰에서 카드 아래가 130px 정도 비었다. 남는 공간 채우기: 카드가 남는 높이를 모두 차지하게 했더니, 이번엔 사진이 세로로 길쭉해졌다. 4:5까지만: 사진이 4:5 비율까지만 늘어나게 제한하고, 남는 공간은 카드 묶음 위아래로 나눴다. <div className="@container ..."> <div className="max-h-[calc(125cqw+10.5rem)] flex-1 ..."> 125cqw 는 컨테이너 폭의 125%라서, 사진 높이가 폭 × 1.25를 넘지 않는다. 짧은 폰에서는 사진이 줄어서 스크롤 없이 한 화면에 들어가고, 긴 폰에서도 길쭉해지지 않는다. 찜 피드백 (배지와 토스트) 찜을 해도 카드만 넘어가서 저장됐는지 알기 어려웠다. 그렇다고 스와이프는 연속으로 하는 동작이라, 찜할 때마다 알림을 띄우면 방해가 된다. 그래서 두 가지로 나눴다. 헤더 찜 개수 배지: 찜할 때마다 숫자가 늘면서 살짝 튄다. 방해 없이 쌓이는 게 보인다. 첫 찜에만 토스트: 그날 처음 찜했을 때만 "찜 목록에 담았어요 · 11:00부터 받을 수 있어요"를 띄운다. 런치캐치에서 찜은 발급이 아니라 11:00 선착순에 참여하는 것이라, 이 규칙을 처음에 한 번 알려주는 게 중요했다. 느낀 점 이번 작업에서 Figma MCP를 써보니 정말 편했다. Claude Code가 Figma를 직접 읽어 들이고, 그 내용을 바탕으로 코드를 짠다는 게 신기했다. 디자인을 보고 크기와 색을 하나하나 옮겨 적던 과정이 줄어들면서, 개발이 훨씬 편해지고 있다는 게 느껴졌다. 오늘 작업 중 겪은 의존성 문제는 런치캐치 트러블슈팅 #1 에 따로 정리했다.
국세청은 사업자등록 상태를 알려주는 공개 API를 운영합니다. 10자리 번호를 넣으면 계속사업자인지, 휴업인지, 폐업인지 알려줍니다. 무료고, 빠르고, 정확합니다. 그런데 기억이 없습니다. 오늘 물어보면 이 회사가 폐업했다는 걸 알 수 있습니다. 지난달엔 어땠냐고 물으면 답이 없습니다. 그 질문이 API에 없으니까요. as_of 같은 파라미터도, 이력 엔드포인트도, 변경 기록도 없습니다. 쓸 수 있는 시제는 현재형 하나뿐입니다. AI 에이전트용 API를 만들면서 발견한 것 중 이게 가장 흥미로웠고, 그래서 당연한 일을 하기로 했습니다. 매일 보이는 걸 적어두기 시작한 겁니다. 무엇을 만들었나 하루에 한 번 도는 작업입니다. 정해진 목록에 있는 모든 회사의 현재 상태를 묻고, 답을 저장합니다. 그리고 오늘과 어제를 비교해서 바뀐 것만 따로 파일에 씁니다. 사흘째 숫자는 이렇습니다. 날짜 관측 기록된 변화 1일차 211,243 — (첫 실행이라 전부 신규) 2일차 211,243 70 3일차 211,243 94 하루치 스냅샷은 약 42MB, 변화 파일은 1.7MB입니다. 이 비율이 핵심입니다. 제가 기록하는 것의 99.2%는 "아무 일도 없었다"는 확인이고, 나머지 0.8%가 상품입니다. 실제로 저장된 변화 한 건은 이렇게 생겼습니다. json {"business_number":"...","field":"status","previous":"active","current":"closed", "previous_seen_at":"2026-09-29T00:05:14Z","detected_at":"2026-09-30T00:05:14Z"} 29일에 봤을 땐 영업 중이던 회사가 30일엔 폐업으로 바뀌어 있었습니다. 저는 이 회사가 실제로 언제 폐업했는지는 증명할 수 없습니다. 각 상태를 언제 봤는지만 알 뿐이죠. 그래서 그것만 저장합니다. "이 회사는 29일에 폐업했다"가 아니라 "봤을 때 영업 중이었고, 다시 봤을 때 폐업이었다". 둘은 다른 주장이고, 나중에 컴플라이언스 보고서에 들어갈 수도 있는 정보라면 이 차이가 중요합니다. 왜 할 가치가 있나 세 가지, 중요한 순서의 역순으로. 하나, 돈으로 살 수 없습니다. 원천에 이력이 없습니다. 원천을 감싼 다른 누구의 서비스에도 없고요. 경쟁자가 내일 "회사 상태 이력이 값지네"라고 깨달으면, 그의 이력은 내일부터 시작됩니다. 제 것은 오늘부터입니다. 이 격차는 벌어지기만 하고, 자본으로 메울 수 없습니다. 둘, 사업의 모양이 바뀝니다. 상태 조회는 일회성 거래입니다. 에이전트가 묻고, 2센트 내고, 떠나고, 다시 안 올 수도 있습니다. 반면 감시(watchlist)는 지속적인 관계입니다. 공급업체 100곳을 등록해두면 매일 제가 확인하고 움직인 것만 알려줍니다. 작지만 반복되고, 제 입장에선 이미 돌고 있는 인프라 위에서 공짜로 얹히는 겁니다. 셋, 신호는 상태가 아니라 변화입니다. "이 회사는 폐업했다"는 사실입니다. "이 회사는 3개월 전 휴업했다가 지난주에 재개했다"는 위험에 대한 해석이고, 조달 시스템이 실제로 알고 싶어 하는 건 후자입니다. 현재형 조회를 아무리 많이 해도 두 번째는 못 만듭니다. 쌓아야만 생깁니다. 하마터면 망가질 뻔한 것들 아무것도 안 하고 exit 0으로 끝난 작업. [지난 글](3편 링크)에 썼던 그 버그입니다. 엔트리포인트 가드가 파일 URL을 손으로 조립해서, 윈도에선 되고 리눅스에선 조용히 실패했습니다. 컨테이너는 뜨고, 아무것도 안 하고, 깔끔하게 종료되고, 스케줄러는 초록불이었습니다. 수동 실행 없이 스케줄을 믿었다면 일주일치 "아무것도"를 수집했을 겁니다. 첫날은 아무것도 증명하지 못합니다. 첫 실행에선 모든 레코드가 신규라 비교 경로가 한 번도 실행되지 않습니다. 결과물은 완벽해 보였지만 비교 로직이 도는지에 대해선 아무것도 말해주지 않았어요. 진짜 검증은 2일차에, 변화 70건이 나오고 이전값·현재값·양쪽 타임스탬프가 전부 채워졌는지 확인하면서 됐습니다. "어제와 오늘을 비교하는" 무언가를 만들었다면, 배포한 다음 날까지는 작동하는 시스템을 가진 게 아닙니다. 범위를 좁히는 게 보안 기능입니다. 어떤 회사를 추적할지 정하는 가장 쉬운 방법은 이용자가 조회한 번호를 쓰는 겁니다. 저는 일부러 안 했습니다. 목록은 공개 등록부(조달 업체 목록, 부정당업자 제재 목록)로만 구성했고, 이 원칙을 주석이 아니라 런타임 가드와 테스트로 강제했습니다. 주석은 급한 미래의 저를 막지 못하니까요. 이용자 조회 내용은 목록에 들어가지 않고, 따라서 이 데이터셋에는 제가 고객에게서 알아낸 것이 하나도 없습니다. 비용 하루 약 2,100콜(한도는 100만), 저장소는 월 수백 원, 작업 시간은 2분 30초. 프로젝트 전체에서 가장 싼 부분이고, 아마 가장 값진 부분입니다. 나머지는 전부 남이 일주일이면 다시 만들 수 있지만, 이것만은 못 만드니까요. 일반화하면 공개 데이터를 에이전트용으로 감싸고 계신다면, 원천이 답하지 않는 것이 무엇인지 물어볼 가치가 있습니다. 대개 시제 문제입니다. 무엇인지는 알려주지만, 무엇이었는지와 무엇이 바뀌었는지는 알려주지 않죠. 그 빈자리가 내가 소유할 수 있는 유일한 부분입니다. 나머지는 전부 원천이 이미 주는 것의 얇은 사본입니다. 내가 쌓은 이력만이 내 것이고, 그건 적어두기로 결심한 날부터 시작됩니다. 길게 썼지만 요지는 하나입니다. 할 거라면 필요해진 날이 아니라 오늘 시계를 켜세요. 기록하지 않은 데이터는 영원히 되찾을 수 없는 유일한 종류입니다.