반응형
반응형

오늘의 개발 뉴스 — 2026년 9월 8일 (화)

devday.kr 29건 · GeekNews 29건 · 중복 병합 후 주요 18건 선별

⚠ 확인·조치가 필요한 항목

주요 글

신규 (9월 7~8일 등록)

정부 조사로 약 3,954만 계정의 개인정보와 소스코드가 함께 유출된 사실이 확인됐다. 이름·휴대전화·이메일·생년월일·결제이력을 포함한 20개 항목 70종이 대상이고 휴면·탈퇴 계정도 빠지지 않았으며, 일부 정보는 암호화키까지 함께 노출됐다. 피해 보상이 자동 지급이 아니라 이용자 개별 신청 방식이라는 점이 실무적으로 가장 중요하다.

[국내 보도]보안개인정보사고GN ↗ 6p

Wireshark 분석 결과 LG 스마트 TV가 화면 꺼짐 상태에서도 로컬 네트워크를 스캔하고 마이크 오디오를 평문으로 로깅해 LG 서버로 전송하는 동작이 포착됐다. 같은 시기 webOS의 원격 코드 실행 취약점도 공개돼, 광고 프로파일링 논란이 단순 프라이버시 문제를 넘어 홈 네트워크 침해 경로 문제로 번지고 있다. GeekNews 쪽 논의는 “TV를 신뢰 경계 밖 기기로 취급하고 별도 VLAN에 격리하라”는 실무 대응에 초점이 맞춰졌다.

[NotebookCheck]webOS보안프라이버시devday ↗GN ↗ 6p

동일한 GPT-6 Astra를 ARC-AGI-3의 같은 High 추론 설정으로 돌렸을 때 하네스 구성에 따라 점수가 54.8%에서 99.9%까지 벌어졌다. 요청 사이에 이전 추론 상태를 보존하느냐가 결정적이어서, 장기 실행 에이전트는 모델 단독이 아니라 메모리·도구·문맥 관리·제어 루프를 합친 시스템으로 평가해야 한다는 결론이다. 같은 모델은 국내 수능 LLM 벤치마크에서 종합 450점 만점을 처음 기록해, 기존 모델들이 막혔던 사회문화 8번까지 풀어냈다.

[GeekNews]LLMAI 에이전트벤치마크GN ↗ 18pGN ↗ 수능 3p

기존 시스템과 조직 구조가 굳은 브라운필드 기업에서 AI 전환이 막히는 지점은 기술이 아니라 역할과 팀 권한을 정체성으로 여기는 문제라는 분석이다. 담당 업무를 AI로 몇 분에 끝내도 다른 팀의 승인과 백로그를 기다려야 하면 조직 경계에서 속도가 전부 상쇄된다. 함께 올라온 글은 “도구를 만드는 일과 기업을 바꾸는 일은 별개”라며, 어떤 도구가 필요한지 발견하고 전사가 쓰게 만드는 단계가 진짜 병목이라고 짚는다.

[GeekNews]AI 도입조직엔지니어링 문화GN ↗ 18pGN ↗ 6p

건물은 물리적으로 붕괴하지만 소프트웨어에는 그런 하한선이 없어, 시스템이 멀쩡히 돌아가는 동안에도 복잡도와 성능 저하가 무한히 쌓인다는 논지다. Amazon 주문 처리 조직 사례로 지식 소실과 중단된 재설계가 반복되며 기존 구조 위에 새 계층과 인력만 계속 얹히는 악순환을 보여준다. 리팩터링을 “언젠가”로 미루는 팀에게 그 언젠가가 오지 않는 구조적 이유를 설명한다.

[GeekNews]기술부채아키텍처GN ↗ 13p

GS리테일이 LiteLLM으로 AI Gateway를 세워 Amazon Bedrock의 Claude를 표준 AI 서비스로 채택하고, Virtual Key 중앙 인증과 크로스 계정 라우팅으로 인증·비용·보안을 한 곳에서 통제한다. 계정 온보딩 자동화와 Prompt Caching으로 운영 부담과 비용을 동시에 줄였고, 2부에서는 예산 기반 라우팅, 자체 가드레일, 목적별 관측 체계와 경영진 대시보드까지 다룬다. 수천 명 규모 사내 LLM 사용을 통제하려는 팀에 바로 참고가 되는 국내 사례다.

[AWS 코리아 블로그]Amazon BedrockLiteLLMAI 거버넌스devday ↗ 1부devday ↗ 2부

User 테이블에서 갱신이 잦은 배지 정보를 UserBadge 테이블로 떼어내 트랜잭션 충돌을 분당 10,000회에서 80회로 줄이고 WCU 사용량도 12~13% 절감했다. 그 결과 메시지 트래픽이 100배로 늘어도 견디는 구조가 됐다. 마이그레이션은 DynamoDB Export/Import와 AWS Glue ETL을 써서 5.3일 걸릴 작업을 6시간으로 단축했다.

[AWS 코리아 블로그]DynamoDBAWS Glue성능 최적화devday ↗

Amazon Bedrock AgentCore를 허브로 사내 데이터·웹 검색·시장 규제 분석 MCP를 엮어 미국 ERCOT 전력 시장 입찰을 분석하는 에이전트를 운영한다. 사용자 페르소나별 Guardrails를 걸어 권한에 따라 접근 범위를 나누고, 답변 품질 관리와 사용자별 데이터 격리를 설계에 포함했다. MCP를 프로덕션 에이전트에 실제로 붙일 때 필요한 격리·거버넌스 패턴을 볼 수 있다.

[AWS 코리아 블로그]Bedrock AgentCoreMCPAI 에이전트devday ↗

문서 작성에서 지식 시스템 설계로 역할을 넓힌 기록이다. 사내 챗봇 ‘박씨’와 지식 관리 플랫폼 todoc을 만들어 조직에 흩어진 맥락적 지식을 구조화했고, 최종 목표를 “AI 워크플로우 자동화로 우리 역할을 불필요하게 만드는 것”으로 잡았다. 사내 문서가 LLM의 입력이 되는 시대에 문서 조직을 어떻게 재배치할지에 대한 구체적 사례다.

[토스 기술블로그]지식관리AI 워크플로우테크니컬 라이팅devday ↗ 1부devday ↗ 2부

ArchUnit으로 레이어 의존성 같은 아키텍처 규칙을 테스트 코드로 옮겨, 문서와 코드 리뷰에 의존하던 규칙 준수를 CI에서 자동 검증하도록 바꿨다. 핵심은 FreezingArchRule로 레거시 위반은 현 상태로 동결하고 신규 위반만 차단한 점이며, Lombok 생성 코드가 잡히지 않는 한계는 소스 파일 스캔으로 메워 신규 위반 0건을 유지하고 있다. 규칙이 이미 무너진 코드베이스에도 점진 적용이 가능하다는 게 실전 포인트다.

[우아한형제들 기술블로그]ArchUnitSpring Boot아키텍처devday ↗

전역 설정에 모든 것을 몰아넣지 말고 프로젝트 폴더마다 필요한 설정만 두어 불필요한 컨텍스트·리소스 소모를 줄이는 방법을 정리했다. 스킬 문서는 처음부터 완비하지 말고 실제 업무에서 필요할 때 점진적으로 쓰라고 권하며, 권한(permissions) 설정은 데이터 무결성을 고려해 보수적으로 잡으라고 조언한다. VSCode 터미널에서 실행 위치를 명확히 하는 습관도 함께 다룬다.

[요즘IT]Claude Code개발 생산성AI 도구devday ↗

코드베이스 스캔부터 에이전트 간 해법 토론, 파일 편집, 테스트 실행과 자가 수정까지 한 런타임 안에서 처리하며, 여러 코딩 에이전트를 로컬에서 병렬로 실행한다. 클라우드 모델과 로컬 모델을 상황에 따라 갈아 끼울 수 있어 사내 코드를 외부로 보내기 어려운 환경에 쓸 만하다. 게임 개발용 Vulkan 3D 런타임 V-CORE도 함께 들어 있다.

[Product Hunt]코딩 에이전트로컬 LLM출시devday ↗

M3 지원 코드가 인스톨러에 병합되어 M3·M3 Pro·M3 Max 맥북과 iMac에서 설치가 가능해졌다. 웹캠, 마이크, WiFi, 블루투스, USB 3 10Gb/s, AV1 하드웨어 디코딩까지 M1/M2에서 되던 기능은 대부분 동작하지만 GPU 가속과 디스플레이 제어는 여전히 제한적이고 M3 Ultra 기반 Mac Studio는 미지원이다. 애플 실리콘에서 리눅스를 상시 사용할 계획이라면 아직은 조건부다.

[Asahi Linux 공식 블로그]Asahi LinuxApple Silicon커널devday ↗GN ↗

X.com의 요구로 중단됐던 Nitter 프로젝트가 법률 검토를 마치고 개발과 운영을 계속하기로 확정했으며, 세부 내용은 곧 공지될 예정이다. XCancel을 포함한 인스턴스도 서비스를 재개해 폐쇄 조치 이전보다 동작하는 인스턴스가 오히려 늘었다. devday 쪽 정리는 이 사건을 계기로 RSS 같은 개방형 표준의 가치와 플랫폼 독점 구조 비판이 다시 부각됐다고 덧붙인다.

[GeekNews · devday]Nitter오픈소스플랫폼devday ↗GN ↗ 3p

메시징 앱을 Android Compose 기반으로 다시 만들고 RCS를 지원하며, 남아 있던 AOSP 기본 앱들을 순차적으로 자체 앱으로 교체한다는 계획을 밝혔다. 보안 클립보드 같은 기능도 함께 강화됐다. 눈에 띄는 점은 이 속도를 내기 위해 AI 모델을 코드 리뷰와 개발 보조에 공식적으로 활용하고 있다고 밝힌 대목이다.

[GrapheneOS 공식 Mastodon]GrapheneOSAndroid보안devday ↗

이전 등록분 중 놓치기 아까운 글 (9월 6일)

Trusting-Trust 공격이 컴파일러 없이 GNU strip만으로도 가능함을 실증한 연구다. 소스 코드를 읽거나 생성·수정하지 않고 완성된 ELF 바이너리만 변조하기 때문에 소스 감사로는 잡히지 않으며, NixOS 부트스트랩 단계에서 감염되면 최종 환경까지 그대로 유지된다. 재현 빌드와 바이너리 서명 검증을 신뢰 근거로 삼고 있는 조직은 전제를 다시 점검할 만하다.

[GeekNews]공급망 보안NixOS툴체인GN ↗

AI SRE가 알림 분석부터 배포 수정까지 대신 처리하면 평균 복구 시간은 좋아지지만, 엔지니어가 시스템 거동과 실패 양상을 배울 기회는 사라진다. 그 결과 사람에게는 AI가 못 푸는 낯설고 심각한 장애만 남게 되어, 자동화의 이득이 장기적으로 상쇄될 수 있다는 지적이다. 온콜 자동화를 도입하는 팀이 학습 경로를 어떻게 남길지 함께 설계해야 하는 이유다.

[GeekNews]SRE장애대응자동화GN ↗ 18p

Claude 계열 세 모델에 코드 구조를 이해하는 LSP 도구를 붙여줬는데도, 대부분은 단순 위치 찾기에 grep을 먼저 썼다. LSP 우선 사용을 강제하자 오히려 성공률이 떨어지는 경우도 있었다. 정확도만의 문제가 아니라 결과를 곧바로 다음 행동에 쓸 수 있는 형태인지가 갈림길이라는 관찰로, 에이전트에 도구를 붙일 때 출력 형식 설계가 왜 중요한지 보여준다.

[GeekNews]코딩 에이전트LSP도구 설계GN ↗

그 외 눈에 띈 글

  1. Databasus — 실제 복원까지 검증하는 셀프 호스팅 DB 백업 도구 (PostgreSQL PITR 지원) (GN · 13p)
  2. Anubis, 1년 개발 끝에 WebAssembly 정식 지원 — Chrome 66까지 하위 호환 (devday)
  3. Mador — Proxy 기반 80줄 DOM 반응형 라이브러리 (devday)
  4. 채널톡 데브 세션, 자율 모임에서 월간 마감되는 문화로 (devday)
  5. 곱셈 2번으로 타임스탬프를 시·분·초로 변환하기 (devday)
  6. 가장 짧은 IPv6 주소에는 누가 응답하는가 (devday)
  7. 1024바이트 C 코드로 만든 파이썬 인터프리터 (devday)
  8. Chrome, 사이트 데이터 설정에서 Google을 또 예외 처리 (GN)
  9. Artificial Analysis, AAII v4.2 — 실제 업무 평가 강화·비공개 테스트 확대 (GN)
  10. LLGo — C·Python 라이브러리를 그대로 쓰는 LLVM 기반 Go 컴파일러 (GN · 2p)
  11. Show GN: monolog — 나에게 메시지하듯 남기면 AI가 정리·검색해주는 메모 앱 (GN · 3p)
  12. 카카오, AI 중심 기술 컨퍼런스 if(kakao)26 개최 (devday)

출처 · devday.kr/archive · news.hada.io/new

반응형

'오늘의개발뉴스' 카테고리의 다른 글

오늘의 개발 뉴스 — 2026년 8월 26일 (수)  (0) 2026.08.26
반응형

 

Daily Dev Digest

오늘의 개발 뉴스 — 2026년 9월 3일 (목)

devday.kr 28건 · GeekNews 21건 · 중복 병합 후 주요 18건 선별

주요 글

Anthropic이 Fable 5.1과 Mythos 5.1을 내놓았다. 가장 실무에 직결되는 변화는 캐시 읽기 비용 75% 절감으로, 프롬프트 캐싱을 쓰는 파이프라인이라면 단가 재계산이 필요하다. 과학 연구 벤치마크에서 약 2배 향상, 안전장치의 과잉 개입 완화와 글쓰기 스타일 개선이 함께 왔지만 일반 성능 개선폭은 제한적이라는 평가다.

GN 관점: 두 모델은 같은 기반을 공유하되 안전 메커니즘이 다르다 — Fable 5.1은 일반 사용자용, Mythos 5.1은 검증된 사이버보안·생명과학 전문가 대상이다.

요즘IT / Anthropic AnthropicLLM릴리스 devday ↗ GN ↗

홈 카드 클릭률 하락의 원인을 "형태가 같은 카드의 단순 나열"로 진단하고, 모듈의 역할 정의를 먼저 세운 뒤 Seamless·Discovery·Scalable 세 축으로 다시 설계했다. 2부에서는 JTBD로 모듈을 재정의하고 '최근 본 상품' 카드를 축소해 시선 흐름을 정리했으며, YDS SellerCard 안에서 재사용 가능한 확장 규칙을 만들었다. A/B 테스트는 전환율 상승을 보였지만 데이터 오류와 동시 변경이 겹쳐 인과 파악에 실패한 회고가 특히 읽을 만하다.

여기어때 기술블로그 디자인시스템FrontendA/B 테스트 devday 1부 ↗ devday 2부 ↗

프롬프트 캐싱의 TTL·무효화 조건·적용 범위를 이해하는 것이 비용 구조 파악의 출발점이라고 짚는다. 구독 / Console / Amazon Bedrock 세 경로의 과금이 다르므로 조직 단위로는 OpenTelemetry 기반 측정 체계부터 세우고, 그다음 컨텍스트 정리 습관, 마지막에 모델 선택 순으로 손대라고 권한다. 팀에 Claude Code를 깔아둔 상태라면 오늘 바로 적용 가능한 실무 문서다.

AWS 한국 블로그 Claude CodeBedrock비용 최적화 devday 2부 ↗ devday 1부 ↗

Chrome 독주를 견제하는 유일한 축이 Firefox 엔진이라는 옹호론과, Mozilla의 데이터 수집 정책·성능 저하로 신뢰가 무너졌다는 비판이 정면으로 부딪쳤다. 대안으로 거론되는 Ladybird·Servo는 아직 웹 표준 호환성이 과제다. 같은 날 Firefox iOS는 WebKit Content Blocker + EasyList 기반 광고 차단을 내장했다(설정 > 브라우징 > 광고 차단에서 활성화).

GN 관점: SNS 계정 운영 방식을 이유로 Firefox를 버리는 건 독립 엔진의 가치를 잃는 대가가 너무 크며, 같은 행동을 하는 Vivaldi에는 문제 삼지 않는다는 점에서 일관성이 없다는 반론이 나왔다.

Newsonaut / Mozilla 브라우저웹표준프라이버시 devday ↗ GN 논쟁 ↗ 7p GN iOS ↗

OpenAI Codex 데스크톱 앱이 시스템 캐시 디렉터리에 Python·Node.js·Poppler·git과 약 430MB의 헤드리스 LibreOffice를 포함한 1.7GB 런타임을 심어두고 있다는 사실이 드러났다. 구형 XLS 호환이 명분이지만, 커뮤니티는 동적 다운로드나 선택적 통합으로 충분하다며 디스크·보안 표면 낭비를 지적한다. 사내 단말에 배포 중이라면 디스크 사용량과 번들 의존성 점검이 필요하다.

Simon Willison OpenAI아키텍처데스크톱 devday ↗ GN ↗

신원 확인 서비스 업체(idscan.net으로 추정)가 수집한 운전면허증 이미지 1.53억 건이 다크웹에서 거래되고 있으며 FBI가 수사에 들어갔다. 근본 원인으로 지목된 건 해킹 기법이 아니라 필요 이상의 개인정보를 장기 보관한 데이터 최소화 원칙 위반이다. KYC·본인확인 플로우를 운영한다면 보관 기간과 원본 이미지 폐기 정책을 다시 볼 시점이다.

Krebs on Security 보안개인정보KYC devday ↗

Jujutsu(jj)를 만든 Martin von Zweigbergk가 ERSC의 CTO로 합류해 차세대 버전 관리 플랫폼을 맡는다. 목표는 AI 에이전트가 코드를 대량 생성하는 환경에서 Git의 스토리지·확장성 한계를 넘는 새 계층을 만드는 것. 당장 도구를 바꿀 일은 아니지만, 향후 2~3년 개발 워크플로 변화의 방향을 가늠할 신호다.

ERSC 블로그 VCSGitJujutsu devday ↗

지금의 에이전트 메모리는 특정 하네스나 별도 LLM이 낀 복잡한 파이프라인에 묶여 있어, 도구를 바꾸는 순간 기억이 통째로 사라진다는 문제 제기다. 대안으로 제시된 Memoryfield 방식은 선택적 YAML 메타데이터를 붙인 짧은 마크다운 문서로 메모리를 단순·이식 가능한 데이터 형식으로 다룬다. 사내에 여러 에이전트 툴을 병행 도입 중이라면 락인을 피할 실질적인 설계 선택지다.

GeekNews AI 에이전트아키텍처 GN ↗ 8p

에이전트가 시행착오·디버깅·탐색을 대신 처리하면서, 예전에는 저절로 쌓이던 반복 경험이 통째로 사라진다는 관찰이다. 역설적으로 에이전트를 잘 쓰려면 문제 도메인을 이해하고 "좋은 결과"를 정의할 수 있는 깊은 전문성이 필요한데, 그 전문성을 기를 반복 자체가 없어진다. 이제는 학습 기회를 의도적으로 설계해 넣어야 한다는 결론으로, 주니어 온보딩 설계에 직결되는 이야기다.

GeekNews AI 에이전트개발문화커리어 GN ↗ 8p

모델 호출 → 도구 사용 → 샌드박스 → 승인으로 이어지는 에이전트 실행 루프 전체를 한 곳에서 관리하는 오픈소스 하네스다. 스트리밍, 대화 저장, MCP 연결, 권한 검사, UI를 모두 내장하고 채팅 인터페이스·HTTP API·TypeScript SDK를 함께 제공한다. 에이전트 실행 인프라를 직접 짜고 있었다면 비교 검토할 만하다.

GitHub (truefoundry) AI 에이전트MCP오픈소스 GN ↗ 5p

RTX 5090 한 장으로 1.5시간, 총 67센트를 들여 학습한 소형 Transformer가 ARC-AGI-1 44%, ARC-AGI-2 7%를 기록했다. 3D RoPE에 색상·다면체 변환 증강을 결합하고 입출력 그리드를 태스크별 임베딩으로 토크나이즈한 것이 핵심. 태스크 구조에 맞춘 설계가 규모를 어디까지 대체할 수 있는지 보여주는 사례다.

GeekNews MLTransformerARC-AGI GN ↗

Wine과 같은 결의 호환 레이어로, 가상머신이나 하드웨어 에뮬레이션 없이 macOS 바이너리를 Linux에서 돌린다. 2022년 중단됐던 개발이 2025년 10월 재개되어 Apple 11.5 오픈소스 기준으로 올라섰고 그래픽·오디오·미디어 서브시스템이 개선됐다. macOS 전용 툴체인이 물려 있는 CI를 Linux로 옮기려던 팀이라면 다시 볼 만하다.

GeekNews LinuxmacOS오픈소스 GN ↗

자연어로 상품 검색·비교·구매까지 잇는 쇼핑 에이전트와 머천트 에이전트 2종 구성을 청사진으로 공개했다. 실제 적용 사례에서 장바구니 크기 35% 증가, 구매 완료율 60% 향상을 기록했다고 밝혔다. Amazon Bedrock·Microsoft Foundry·Google Cloud Vertex AI 어디에서도 며칠 내 도입 가능한 형태로 정리돼 있어 커머스 도메인이면 바로 참고할 만하다.

Anthropic 공식 블로그 커머스AI 에이전트Bedrock devday ↗ devday 심화 ↗

코드 생성 속도는 올라갔지만 프로젝트를 구조화하는 능력의 부재가 오히려 성장의 병목이 됐다는 진단이다. 구성 요소 분리, 단일 책임, 단일 진실 공급원 등 6가지를 "생존 기술"로 제시하며 AI를 코드 생성기가 아니라 구조 학습 도구로 쓰라고 권한다. 짝을 이루는 기술부채 글은 AI가 레거시 현대화를 가속하는 동시에 과도한 구현 속도로 새 부채를 찍어낸다고 지적하며, 학습·검증에 시간을 배분해 지식 격차를 줄이는 것이 유일한 방어책이라고 말한다.

Dev.to AI 코딩기술부채소프트웨어공학 devday 구조화 ↗ devday 기술부채 ↗

React 19의 Actions는 startTransition 내부에서 실행되는 함수라는 정의에서 출발해, 4개 훅이 각각 어느 지점을 담당하는지 정리한다. 흩어져 있던 로딩·에러 상태 관리가 훅 레벨로 통합되고, action prop 기반의 새 폼 제출 방식이 들어왔다. React 19 마이그레이션을 앞두고 있다면 훅 선택 기준을 잡기 좋은 글이다.

Dev.to ReactFrontendNext.js devday ↗

토큰과 컴포넌트 목록만 던져주면 AI는 규칙을 추론하지 못한다. 예외 케이스까지 문장으로 못 박은 명시적 규칙(Explicit Rules)을 Markdown·JSON으로 문서화하고, 피드백-재학습을 반복해야 결과가 안정된다는 실전 정리다. 부수 효과로 같은 문서가 신규 입사자 온보딩 자료로도 그대로 쓰인다는 점을 짚는다.

요즘IT 디자인시스템AI/MLFrontend devday ↗

파일 편집, 명령 실행, 웹 검색, 에이전트 협업 도구의 입력 형식과 호출 조건을 한 문서로 모았다. 자동화는 Gmail·Slack·GitHub 웹훅으로 스케줄·조건 모니터링을 지원하지만, 폴링은 시간당 최대 1회이고 사전 앱 연결이 필수라는 제약이 명시돼 있다. 업무 자동화 파이프라인을 설계할 때 한계선을 먼저 확인할 수 있는 자료다.

GeekNews OpenAI업무자동화문서 GN ↗

AuroraStore의 익명 계정 기능이 여러 Android 환경에서 "Server busy" 오류로 반복 실패하고 있다. VPN 우회, 캐시 삭제, 재설치 등 알려진 우회책이 모두 통하지 않아 Play 서비스를 배제한 GrapheneOS 사용자들이 앱 설치 경로 자체를 잃는 상황이다. 탈구글 환경을 테스트 단말로 쓰는 팀이라면 배포 검증 경로 점검이 필요하다.

GeekNews AndroidGrapheneOS앱배포 GN ↗

그 외 눈에 띈 글

반응형
반응형

AI 코드 리뷰는 몇 번 돌려야 할까

 

https://edgelog.dev/ko/blog/how-many-ai-code-reviews/

 

AI 코드 리뷰는 몇 번 돌려야 할까

같은 코드에 400회의 LLM 호출을 썼다. 리뷰 1회는 실제 결함의 34%만 본다. 그리고 가장 자주 지적된 항목 4개는 전부 오탐이었다.

edgelog.dev

 

 

AI 코드 리뷰는 몇 번 돌려야 할까? 약 400번의 LLM 호출로 직접 측정해봤습니다

AI로 코드를 작성하고 리뷰까지 맡기다 보면 생각보다 자주 이런 상황을 만납니다.

코드 작성 → 리뷰 → 수정 → 다시 리뷰 → 다시 수정 → 또 리뷰...

처음 리뷰에서 문제를 몇 개 찾아 고쳤는데, 다시 리뷰하면 새로운 문제가 나옵니다.
그걸 고치고 다시 돌리면 또 다른 지적이 나옵니다.

리뷰 → 수정 → 리뷰 → 수정이 끝나지 않습니다.

그러다 보면 애매해집니다.

대체 언제 끝내야 할까?

  • 지적(이슈)가 0개가 될 때까지?
  • 테스트가 모두 통과하면?
  • 2~3번 정도 돌리면 충분한가?
  • 계속 돌릴수록 실제로 코드가 좋아지는가?

특히 이 과정을 에이전트나 CI에 자동화하려고 하면 더 문제가 됩니다.

review → fix → review → fix

루프를 만드는 건 어렵지 않은데, 언제 멈춰야 하는지에 대한 근거가 없습니다.

저도 최대 3라운드까지 자동 반복하는 워크플로를 사용하고 있었는데, 어느 순간 궁금해졌습니다.

정말 리뷰와 수정을 반복할수록 코드가 좋아질까?

그래서 실제 C 펌웨어 코드와 별도의 벤치마크 과제를 대상으로 리뷰어와 수정자를 분리하고, 약 400회의 LLM 호출을 돌려 직접 측정해봤습니다.

결과는 생각했던 것과 조금 달랐습니다.

1. 리뷰만 반복하는 것은 효과가 있었습니다

같은 코드를 수정하지 않고 반복해서 리뷰하면 실제 결함 커버리지가 대략

34% → 61% → 76%

로 증가했습니다.

같은 코드, 같은 모델이어도 매번 보는 문제가 달랐습니다.
어떤 실제 결함은 10번 중 한 번만 발견되기도 했습니다.

즉, AI 리뷰 한 번만으로 충분하다고 보기는 어려웠습니다.

2. 하지만 리뷰와 수정을 반복하는 것은 다른 문제였습니다

리뷰 → 수정 → 리뷰 → 수정

루프를 반복했을 때 테스트/계약 준수율은 그대로인데, 코드는 조건에 따라

+24% ~ +152%

까지 커졌습니다.

즉,

리뷰를 반복하는 것과 리뷰-수정 루프를 반복하는 것은 같은 일이 아니었습니다.

발견의 이득은 리뷰에서 나오지만, 수정할 때마다 새로운 변경과 새로운 위험도 함께 생깁니다.

3. 여러 번 지적됐다고 더 정확한 것도 아니었습니다

처음에는 여러 리뷰에서 반복적으로 나온 finding일수록 진짜일 가능성이 높을 거라고 생각했습니다.

그런데 대상 파일 하나만 보여준 조건에서는 반대였습니다.

오탐이 실제 결함보다 더 자주 반복적으로 보고됐습니다.

여러 AI가 독립적으로 리뷰하더라도 모두 같은 context를 잃고 있다면,
같은 잘못된 가정에서 출발해서 같은 방향으로 틀릴 수 있었습니다.

4. Repository context가 오탐 제거에 상당히 중요했습니다

대상 파일 하나만 보여준 조건에서는 고유 지적의 29%가 오탐이었습니다.

반면 호출자, 헤더, 초기화 경로 등 repository를 읽을 수 있게 하자 동일한 오탐들이 사라졌습니다.

코드 리뷰에서는 모델 자체뿐 아니라,

모델에게 어디까지 볼 수 있게 할 것인가

도 상당히 중요한 변수였습니다.

5. AI가 조용해졌다고 리뷰가 끝난 것도 아니었습니다

몇 라운드 이후 "지적 없음"이 나오더라도 같은 코드를 다른 관점으로 구조화해서 리뷰하면 새로운 failure mode가 다시 나왔습니다.

그래서 단순히

finding == 0

을 종료 조건으로 쓰기도 어려웠습니다.

6. 테스트 통과만으로도 종료를 판단하기 어려웠습니다

여러 조건에서 테스트 결과는 계속 동일했습니다.

그런데 코드 크기와 복잡도는 크게 달라졌습니다.

즉,

테스트를 계속 통과한다 = 코드가 계속 좋아지고 있다

라고 보기는 어려웠습니다.


그래서 현재 제가 쓰고 있는 가장 단순한 원칙은:

리뷰는 여러 번, 수정은 한 번.

여러 독립 리뷰에서 finding을 먼저 모으고, 사람이 한 번 선별한 다음 수정자에게 한꺼번에 넘깁니다.

그리고 수정 폭이 충분히 크다면 다음 리뷰는 단순한 '재리뷰'가 아니라,

새로 생긴 코드에 대한 첫 리뷰

라고 보는 편이 더 맞다고 생각합니다.

다만 아직 일반화하기에는 작은 실험입니다.

다른 조건이나 모델에서도 다시 확인된 결과는 일부뿐이고, Python 벤치마크 과제도 두 개뿐입니다. 언어나 코드베이스가 달라졌을 때 결과가 달라진 경우도 있었습니다.

그래서 이 결과를 모델 성능 비교보다는,

“AI 코딩 에이전트의 review/fix loop를 어떻게 설계하고, 어디서 멈출 것인가?”

에 대한 실험으로 보는 것이 맞습니다.

실험 과정에서 초기 결론이 여러 번 뒤집혔고, 그 과정과 원 데이터, 벤치마크 코드, 현재의 실무 처방, 한계까지 모두 공개했습니다.

관련 자료

반응형
반응형

소프트웨어 개발의 미래는 소프트웨어 개발자들이다 

https://news.hada.io/topic?id=25448

  • 수십 년간 반복된 “프로그래머의 종말” 예언은 매번 틀렸으며, 기술 발전은 오히려 더 많은 개발자와 프로그램의 증가로 이어져 왔음
  • WYSIWYG, 4GL, No-Code, LLM 등 다양한 자동화 기술이 등장했지만, 실제로는 개발자의 필요성을 줄이지 못했음
  • LLM 기반 도구는 과거 기술보다 신뢰성과 유지보수성이 떨어지며, 대부분의 팀에서 생산성 저하와 품질 악화를 초래함
  • 프로그래밍의 본질적 어려움은 코드 작성이 아니라 인간의 모호한 사고를 논리적으로 변환하는 능력에 있으며, 이는 여전히 인간의 영역임
  • 따라서 AI가 개발자를 대체할 가능성은 낮고, 오히려 숙련된 개발자에 대한 수요가 더 커질 전망임

반복되는 “프로그래머의 종말” 주기

  • 지난 43년간 Visual Basic, Delphi, Executable UML, No-Code, Low-Code 등 다양한 기술이 프로그래머의 필요성을 없앨 것이라 주장되어 왔음
    • 1970~80년대에는 4GL, 5GL, 그 이전에는 Fortran, COBOL, 더 거슬러 올라가면 컴파일러 A-0조차 같은 예언을 받았음
    • 초기 전자식 컴퓨터 COLOSSUS는 물리적 배선으로 프로그래밍되었으며, 이후 세대가 “진짜 프로그래머가 아니다”라 조롱받기도 했음
  • 그러나 결과적으로는 프로그래머 수가 줄지 않고 오히려 증가, 이는 Jevons Paradox의 대표적 사례로 언급됨

LLM과 과거 기술의 차이

  • 과거 기술은 실제로 소프트웨어 생산 속도를 높이고 신뢰성도 확보했지만, LLM은 대부분의 팀에서 반대 효과를 보임
    • LLM은 코드 품질을 낮추고 유지보수를 어렵게 만들어 “LOSE-LOSE” 상황을 초래함
    • 동일한 프롬프트로도 동일한 결과를 내지 못하며, 생성된 코드에는 인간 개발자의 검증과 수정이 필수적임
  • AI가 개발자를 대체한다는 증거는 없음, 최근 인력 감축은 팬데믹 시기 과잉 채용, 금리 상승, 데이터센터 투자 집중 등 경제 요인 때문임

프로그래밍의 본질적 난제

  • 프로그래밍의 핵심은 인간의 모호한 사고를 논리적으로 정밀한 계산 사고로 전환하는 과정임
    • 이는 천공카드 시절부터 COBOL, Visual Basic, Python에 이르기까지 변하지 않은 어려움임
  • 자연어는 본질적으로 모호하고 비정확하기 때문에, 영어나 프랑스어로 프로그래밍하는 시대는 오지 않을 것이라 Dijkstra의 예언을 인용함
  • 이러한 사고방식을 배우는 것은 가능하지만, 모두가 즐기거나 잘할 수 있는 일은 아니며, 숙련된 인력의 공급은 항상 부족함

AI의 한계와 지속 가능성

  • AGI(범용 인공지능) 은 여전히 멀리 있으며, 인간 수준의 이해·추론·학습 능력이 필요함
  • 대규모 LLM은 막대한 비용과 손실을 초래하고 있어 장기적으로 지속 가능하지 않음
    • 시간이 지나면 모델이 학습한 언어·라이브러리 버전의 제약으로 인해 활용성이 떨어질 가능성 있음
    • 이러한 이유로 초대형 LLM은 ‘Apollo 달 탐사’처럼 비경제적 실험으로 남을 수 있음

미래의 개발 환경 전망

  • 가까운 미래의 소프트웨어 개발은 소규모 언어 모델 기반의 보조 도구가 프로토타입 생성이나 코드 자동완성 등 보조 역할을 수행하는 형태로 예상됨
  • 그러나 중요한 결정과 품질 확보는 인간 개발자가 주도하며, Jevons의 법칙에 따라 개발자 수요는 오히려 증가할 가능성 있음
  • 기업은 지금부터 숙련된 개발자 채용과 교육에 투자해야 하며, 이는 AI 유무와 관계없이 생산성과 신뢰성을 높이는 핵심 전략
반응형
반응형

나를 만들어준 소프트웨어 에세이들  

https://refactoringenglish.com/blog/software-essays-that-shaped-me/

 

Refactoring English

Effective writing for software developers

refactoringenglish.com

  • 20년간 수천 개의 소프트웨어 블로그 글을 읽었지만, 소수의 에세이만이 사고방식을 근본적으로 변화시켰으며, Joel Spolsky의 "Joel Test"부터 Julia Evans의 순수 JavaScript 옹호까지 10개의 핵심 에세이 소개
  • Joel Spolsky의 "Joel Test"는 고용주가 개발자를 존중하는지 평가하는 12개 질문을 제시하며, 소스 관리, 일일 빌드, 버그 우선 수정 등을 통해 개발자의 시간과 집중을 우선시하는지 확인
  • Alexis King의 "Parse, don't validate"는 데이터 검증 시 새로운 타입으로 변환하는 기법을 소개하여, 타입 시스템이 애플리케이션 보안과 신뢰성 향상에 기여할 수 있음을 보여줌
  • Fred Brooks의 "No Silver Bullet"은 소프트웨어 작업을 본질적 복잡성과 우발적 복잡성으로 구분하며, 도구와 하드웨어 발전으로는 10배 생산성 향상 불가능하다고 주장했으나 AI는 이 이론에 변수를 던짐
  • Julia Evans의 순수 JavaScript 에세이는 프레임워크 없이도 ES2018 JavaScript만으로 충분하다는 깨달음을 주었고, 이후 2020년부터 어떤 프로젝트에도 JavaScript 프레임워크나 빌드 스텝을 통합하지 않음

Joel Spolsky의 "Joel Test" (2000)

  • Joel Spolsky는 역대 최고의 소프트웨어 블로거이며, 그의 에세이들이 필자의 소프트웨어 접근 방식에 많은 영향을 미침
  • "Joel Test"는 고용주가 소프트웨어 팀에 얼마나 잘 투자하는지 평가하는 12개 질문 세트
  • 12개 질문 목록
    • 소스 관리 사용 여부
    • 한 단계로 빌드 가능 여부
    • 일일 빌드 수행 여부
    • 버그 데이터베이스 보유 여부
    • 새 코드 작성 전 버그 수정 여부
    • 최신 일정 보유 여부
    • 스펙 보유 여부
    • 프로그래머가 조용한 작업 환경을 가지는지
    • 돈으로 살 수 있는 최고의 도구 사용 여부
    • 테스터 보유 여부
    • 신규 후보자가 인터뷰 중 코드 작성 여부
    • 복도 사용성 테스트 수행 여부
  • 핵심 메시지
    • 일부 질문은 시대에 뒤떨어졌지만, 질문 자체가 아니라 질문의 메타 포인트가 중요
    • Joel이 실제로 묻는 것: 개발자를 존중하는가?
    • 모든 질문은 고용주가 저렴한 사무 공간과 단기 마감일보다 개발자의 시간과 집중을 우선시하는지 평가
    • 닷컴 붐 정점에 게시되었으며, 숙련된 개발자가 귀중한 자원이었지만 모두가 이를 깨닫지는 못한 시기
    • Joel의 블로그는 항상 프로그래머를 희귀하고 섬세한 천재로 제시하여 고용주가 추구하고 아껴야 할 대상으로 묘사
    • 필자는 경력 내내 Joel Test에서 높은 점수를 받는 고용주를 찾았으며, 그 지도를 제공한 Joel에게 감사

Alexis King의 "Parse, don't validate" (2019)

  • Haskell의 타입 시스템 활용에 관한 에세이이지만, 타입 시스템이나 Haskell에 관심이 없어도 소프트웨어 사고방식을 근본적으로 변화시킴
  • Go, C++, Rust 등 정적 타입을 지원하는 모든 언어에서 Alexis의 기법 사용 가능
  • 핵심 개념
    • 데이터를 검증할 때마다 새로운 타입으로 변환해야 함
    • 예시: 사용자 이름을 최대 20자 영숫자로 제한하는 규칙이 있을 때, 순진한 솔루션은 validateUsername(username string) error 함수
  • 문제점
    • 코드가 기본적으로 안전하지 않음
    • 수신한 모든 사용자 이름을 검증해야 하므로, 실수로 검증 없이 사용자 이름을 처리하는 코드 경로 생성 쉬움
    • 악의적 사용자가 실수를 발견하면 사용자 이름 필드에 악성 코드 삽입하거나 수십억 문자로 채워 서버 리소스 고갈 가능
  • Alexis의 솔루션
    • parseUsername(raw string) (Username, error) 함수 사용
    • 코드베이스의 나머지 부분에서 "username"이라는 string 대신 커스텀 타입 Username 사용
    • Username을 생성할 수 있는 유일한 함수는 parseUsername이며, 이는 Username 인스턴스를 반환하기 전에 검증 규칙 적용
    • Username 인스턴스가 있으면 유효한 사용자 이름을 포함해야 함
    • 신뢰할 수 없는 입력은 항상 string이므로, Username을 예상하는 함수에 string 전달 불가능
  • 영향
    • 이 에세이 이전에는 타입 시스템이 언어 너드를 산만하게 하는 재미있는 방법이라고 생각
    • "Parse, don't validate"는 컴파일러 기능이 애플리케이션의 보안과 신뢰성 향상에 얼마나 가치 있는지 눈을 뜨게 함

Fred Brooks의 "No Silver Bullet" (1986)

  • 대학에서 Fred Brooks의 The Mythical Man-Month 읽음
  • IBM의 OS/360 프로젝트 지휘 경험을 바탕으로 한 소프트웨어 엔지니어링 에세이 모음집
  • 본질적 복잡성과 우발적 복잡성
    • 본질적 복잡성: 도구와 하드웨어에 관계없이 반드시 수행해야 하는 작업
      • 예: 영업 사원 보너스 계산 소프트웨어에서 보너스 공식 정의 및 모든 엣지 케이스 커버
      • $5B 슈퍼컴퓨터든 $1 마이크로컨트롤러든 동일한 작업
    • 우발적 복잡성: 그 외 모든 것
      • 메모리 누수 처리, 코드 컴파일 대기, 제3자 라이브러리 사용 방법 파악
      • 도구와 하드웨어 리소스가 좋을수록 우발적 복잡성에 소비하는 시간 감소
  • Brooks의 결론
    • 도구나 하드웨어의 발전이 개발자 생산성에 10배 향상을 만들어내는 것은 불가능
    • 모든 우발적 활동을 제로 시간으로 줄여도 전체 노력의 9/10 이상이 아니면 규모 향상 불가능
  • 적용 사례
    • 경력 내내 사람들이 소프트웨어에서 프로그래머를 제거하려고 시도
    • 노코드 플랫폼이 비프로그래머에게 숙련된 웹 개발자의 모든 권한을 약속하며 화제 생성
    • Brooks의 에세이는 최신 버즈워드 플랫폼이 개발자를 대체할 수 없다고 항상 안심시킴
    • 플랫폼은 우발적 복잡성에 집중하며, 본질적 복잡성에는 집중하지 않음
    • 플랫폼이 기능 사양에서 마법처럼 작동하는 코드를 만들 수 있어도, 여전히 사양을 작성할 누군가가 필요
  • AI의 영향
    • 현대 AI는 Brooks의 이론에 렌치를 던짐
    • AI는 실제로 본질적 복잡성을 줄임
    • 불완전하거나 모순된 사양을 AI에 전달하면, AI가 유사한 사양에서 차용하여 공백 채움
    • AI가 알려진 프로그래밍을 제거하더라도, Brooks의 에세이는 결국 어떤 추상화 수준에서든 본질적 복잡성을 관리할 사람이 여전히 필요하다는 희망 제공

Joel Spolsky의 "Choices" (2000)

  • 좋아하는 Joel Spolsky 에세이를 하나만 선택하기 어려워 두 개 선택
  • "Choices"는 사용자 인터페이스 생성과 사용자에게 권한을 부여하는 미묘한 비용에 관한 것
  • 핵심 메시지
    • 옵션을 제공할 때마다 사용자에게 결정을 요청하는 것
    • 사용자가 무언가에 대해 생각하고 결정해야 함을 의미
    • 반드시 나쁜 것은 아니지만, 일반적으로 사람들이 내려야 하는 결정의 수를 최소화하려고 노력해야 함
  • Windows 98 예시
    • Joel은 Windows 98에서 도움말 문서 검색 시 나타나는 황당한 대화상자 공유
    • 대화상자가 Joel을 분노하게 만든 이유:
      • 사용자가 도움을 받으려고 할 때 중단
      • 데이터베이스 최적화에 대한 정보 없는 결정을 내리도록 요청
      • Windows가 결정을 회피하고 사용자에게 떠넘김
  • 적용 범위
    • Joel의 에세이는 그래픽 사용자 인터페이스에 초점을 맞추지만, 필자는 명령줄이나 작성한 함수를 호출하는 다른 개발자를 포함하여 코드를 접할 수 있는 모든 곳에서 이를 고려
    • 사용자를 대신하여 유용한 결정을 내릴 수 있는지, 동시에 그들이 관심 있는 것에 대한 권한을 제공할 수 있는지
    • Joel의 에세이는 내가 직접 내릴 수 있는 결정을 사용자에게 떠넘기는 것을 무수히 막아줌

Raymond Chen의 "“Application compatibility layers are there for the customer, not for the program” (2010)

  • Raymond Chen은 Microsoft Windows 팀에서 가장 오래 근무한 개발자 중 한 명
  • 블로그에는 Windows 프로그래밍 역사에 대한 수천 개의 유익하고 재미있는 이야기가 있음
  • 고객 요청 사례
    • Windows Vista 호환성 모드에 관한 고객 요청:
      • Windows XP 및 Windows Server 2003용으로 설계된 프로그램이 Windows Vista에서 어려움 겪음
      • Windows XP 호환성 모드로 설정하면 Vista에서 잘 작동
      • Vista에서 실행 시 자동으로 XP 호환성 모드로 실행되도록 설치 프로그램에 어떤 변경 필요한지 질문
  • Raymond의 비유
    • "나는 일반적으로 애완동물 가게 앞 보도에 쓰레기를 버리고, 매일 아침 가게가 열리면 누군가 쓰레기를 쓸어 쓰레기통에 버립니다. 하지만 애완동물 가게는 일요일에 열지 않아서, 일요일에는 쓰레기가 그냥 거기 있습니다. 일요일에도 애완동물 가게를 열게 하려면 어떻게 해야 하나요?"
  • 교훈
    • 비유가 너무 재미있어서 Raymond가 틀렸다는 것을 이제야 알아챔
    • 단일 릴리스 후 Windows가 앱을 깨뜨리지 않을 것으로 기대한 개발자의 죄를 조롱
    • 세부 사항에는 동의하지 않지만, Raymond의 글은 매우 재미있고 날카로워 결함을 넘어설 수 있음
    • 훌륭한 사용자 행동 영향 교훈:
      • 사용자가 당신을 돕는 무언가를 하도록 유도하려면, 사용자 관점에서 저항이 가장 적은 경로를 신중히 생각해야 함
      • 보도에 쓰레기를 버리는 것이 문제를 완전히 해결한다고 보여주면, 계속 그렇게 할 것

Erik Kuefler의 "Don’t Put Logic in Tests" (2014)

  • 필자는 항상 단위 테스트를 좋아했고 테스트 코드에 큰 자부심을 가짐
  • 이 에세이가 화장실에 나타나 경력 내내 끔찍한 테스트를 작성해왔음을 폭로해 충격
  • 문제가 있는 테스트 예시
  • @Test public void shouldNavigateToPhotosPage() { String baseUrl = "http://plus.google.com/";; Navigator nav = new Navigator(baseUrl); nav.goToPhotosPage(); assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl()); }
  • 발견한 문제점
    • 처음 에세이를 읽었을 때 "내가 단위 테스트를 작성하는 방식과 정확히 같다!"고 생각
    • http://plus.google.com/ 문자열을 두 곳에 중복하는 이유는? 프로덕션 코드처럼 단일 진실 소스 생성
    • 필자는 테스트에서 중복을 제거하기 위해 헬퍼 함수, 변수, 루프를 추가하는 것을 항상 했음
    • 문제는 이 접근 방식이 미묘한 버그를 가림: 실제로는 http://plus.google.com//u/0/photos를 assert(슬래시 두 개)
  • 깨달음
    • Erik의 에세이는 테스트 코드를 프로덕션 코드처럼 취급하지 말아야 함을 보여줌
    • 두 가지는 완전히 다른 목표와 제약 조건을 가짐
    • 좋은 테스트 코드는 무엇보다도 명확해야 함
    • 테스트 코드에는 자체 테스트 코드가 없으므로, 정확성을 검증하는 유일한 방법은 검사
    • 테스트는 어떤 동작을 assert하는지 독자에게 눈이 멀 정도로 명백해야 함
    • 이 목표를 위해 복잡성을 줄이기 위해 중복 허용 가능

Julia Evans의 “A little bit of plain Javascript can do a lot” (2020)

  • 소프트웨어 엔지니어로서 웹에 당혹스럽게도 늦게 입문
  • 경력 첫 10년간 데스크톱 앱과 백엔드 서버용 코드만 작성
  • 2017년까지 HTML이나 JavaScript를 신경 쓰지 않음
  • 프레임워크에 대한 오해
    • 프론트엔드 개발 학습을 진지하게 시작했을 때, JavaScript는 10일 만에 만들어진 엉망인 언어이며 브라우저마다 동작이 크게 다르다는 인상
    • 웹 앱을 작성하려면 JavaScript의 모든 담즙과 결점으로부터 보호해주는 현대적이고 세련된 무언가가 필요
    • Angular, React, Vue 같은 인기 있는 웹 프레임워크 시도
    • Vue를 충분히 학습했지만 여전히 의존성 문제와 프레임워크 함정에 엄청난 시간 소비
    • 이 모든 프론트엔드 프레임워크가 JavaScript를 수정하기 위해 한 작업 후에도 웹 프로그래밍은 여전히 형편없었음
  • Julia의 에세이가 준 깨달음
    • JavaScript가 수정이 필요하다고 너무 확신한 나머지 기회를 주지 않았음을 깨달음
    • TinyPilot 프로토타입 작업 중이었고, Vue로 웹 인터페이스를 구현할 계획
    • Julia의 에세이가 순수 JavaScript로 얼마나 갈 수 있는지 보도록 영감을 줌
    • 프레임워크, 래퍼 라이브러리, 빌드 스텝, Node.js 없이, 그냥 일반 JavaScript(ES2018)만 사용
    • 프레임워크나 빌더로 전환해야 할 문제에 부딪힐 것으로 계속 예상했지만 결코 일어나지 않음
    • WebComponents 관련 몇 가지 함정은 있었지만, Vue와 Angular로 겪은 고통에 비하면 아무것도 아님
  • 프레임워크 없는 자유
    • 프레임워크에서 자유로워지는 것을 좋아함
    • 런타임 오류가 있을 때, 스택 트레이스가 축소되고 변형되고 트리 쉐이크된 코드의 열악한 꿈이 아님
    • 작성한 대로 내 코드를 디버깅하는 것
    • JavaScript에 대한 편견이 틀렸음
    • 현대 JavaScript는 꽤 좋으며, 래퍼 라이브러리의 많은 아이디어를 흡수하여 이제 래퍼가 필요 없음
    • 브라우저들이 플랫폼과 디바이스 간 일관된 동작을 보장하기 위해 정신을 차림
    • 2020년 이후 어떤 새 프로젝트에도 JavaScript 프레임워크나 빌드 스텝을 통합하지 않았으며 뒤돌아보지 않음
    • 순수 JavaScript로 프레임워크 이점의 90%를 5%의 골칫거리로 얻음

Dan McKinley의 “Choose Boring Technology” (2015)

  • 이 목록에 포함하기 이상한 에세이인 이유는 실제로 읽어본 적이 없기 때문
  • 사람들이 이 에세이를 인용했고, 아이디어를 이해하자 너무 직관적이어서 읽을 필요를 느끼지 못함
  • 핵심 아이디어
    • 새 프로젝트를 시작할 때 화제가 많은 최첨단 기술을 사용하고 싶은 유혹
    • Google이 엑사바이트까지 확장되는 새 데이터베이스를 발표했고, Postgres보다 40% 빠르고 비용은 20%
    • 이 섹시한 새 대안이 바로 거기 있을 때 Postgres를 사용하면 바보
    • 실제로 새 기술에는 버그와 약점이 있지만, 아직 명백하지 않음
    • 이에 부딪히면 막막함
    • Postgres는 문제가 있지만, 30년의 현장 경험 후 직면할 가능성이 있는 모든 문제에 대한 검증된 솔루션 보유
  • 혁신 토큰 개념
    • Dan은 가끔 새 기술을 사용해야 한다고 인정하지만 전략적으로 그리고 제한된 수량으로만
    • 모든 비즈니스는 소비할 세 개의 "혁신 토큰" 을 얻음
    • 화려한 새 데이터베이스를 원하면 토큰 중 하나를 소비해야 함
    • Dan의 에세이는 Julia의 에세이와 자연스럽게 맞물림
    • 프론트엔드 프레임워크로 그 모든 시간을 낭비하기 전에 둘 중 하나라도 읽었으면 좋았을 것

Terence Eden의 “I’ve locked myself out of my digital life” (2022)

  • Terence Eden은 유쾌하고 절충적인 기술 블로거
  • 매주 여러 새 글을 쓰지만, 가장 큰 영향을 준 것은 "디지털 생활에서 나 자신을 잠갔다"
  • 재난 시나리오
    • 번개가 Terence의 집을 치고 모든 소유물을 파괴하면 어떻게 될지 시뮬레이션
    • 비밀번호 관리자에 모든 것에 대한 비밀번호 보관
    • 모든 디바이스가 파괴되면 비밀번호 관리자에 액세스 불가능
    • 하드웨어 패스키로 대체할 수 없는 이유는 그것들도 집에 있었기 때문
  • 깨달음
    • 필자는 중복 드라이브에 모든 것을 저장하고 두 벤더로 세 대륙에 오프사이트 백업을 가지고 있어 데이터에 대해 꽤 안전하다고 느낌
    • Terence의 글은 모든 디바이스를 동시에 없앨 수 있는 많은 신뢰할 수 있는 위협에 대해 생각하게 함: 화재, 홍수, 전기 서지, 범죄 수사
    • 모든 데이터는 머릿속에 있는 비밀번호로 암호화되어 있으므로, 기억 상실, 무능력, 사망도 목록에 추가
  • 온라인 서비스의 문제
    • 온라인 서비스는 사용자가 재난에서 복구하는 데 도움을 주는 데 취약
    • 전화를 잃는 것이 불가능하다고 가정하는 여러 서비스 사용, 이메일 계정과 소유한 모든 디지털 디바이스는 말할 것도 없이
  • 영향
    • Terence의 에세이를 읽은 이후 어떤 서비스와 디바이스가 중요한지, Terence가 설명한 시나리오에서 어떻게 복구할 수 있는지 더 많이 고려
    • 다음 노트북을 구입했을 때 도서관에서 설정하여 집에 있는 디바이스 없이 비밀번호 관리자와 중요한 계정에 대한 액세스를 복구할 수 있는지 테스트
    • 여전히 디지털 재난 대비를 더 잘할 수 있지만, Terence의 글은 디바이스와 데이터 보안 방법을 생각할 때마다 머릿속에서 울림
    • 모든 것이 갑자기 파괴되면 어떻게 될까?

보너스: Brad Fitzpatrick의 "parsing user input" (2009)

  • 기술적으로 에세이는 아니지만, 소프트웨어 인터뷰의 인용문을 지속적으로 생각
  • 2009년 Joel Spolsky의 극찬 리뷰 결과로 Coders at Work 읽음
  • 성공한 프로그래머들과의 인터뷰 모음집
  • Brad Fitzpatrick의 명언
    • LiveJournal과 Memcached 창시자 Brad Fitzpatrick이 인터뷰이 중 한 명으로 등장
    • 당시 28세로 책에서 가장 어린 프로그래머이자 가장 욕이 많고 재미있는 사람
    • 소프트웨어 엔지니어링 윤리에 대한 질문에 입력 검증에 대한 열정적인 발언:
      • "모두가 신용카드 양식에서 공백이나 하이픈을 입력할 수 있게 일관되게 해주기를 요청하고 싶습니다. 컴퓨터는 그런 것들을 제거하는 데 능숙합니다. 내 숫자를 어떻게 포맷할지 말하지 마세요."
  • 적용
    • 웹 양식에 전화번호를 붙여넣으려고 할 때마다 이 인용문을 떠올림
    • 괄호나 공백이 허용되지 않는다고 투덜거리거나, 더 나쁜 경우 괄호 때문에 전화번호를 잘라내고 괄호가 허용되지 않는다고 불평
    • 소프트웨어에서 입력 필드를 만들고 예상치 못한 문자에 대해 생각할 때마다 Brad Fitzpatrick이 "컴퓨터는 그런 것들을 제거하는 데 능숙합니다" 라고 말하는 것을 들음
반응형
반응형

[python] I'm Switching to Python and Actually Liking It  파이썬으로 전향중이고, 생각보다 꽤 마음에 들어요  

 

https://www.cesarsotovalero.net/blog/i-am-switching-to-python-and-actually-liking-it.html

 

I’m Switching to Python and Actually Liking It

I’ve started writing more Python code lately (because of… AI, you know). In this post, I share the tools, libraries, configs, and other integrations I use for building production-grade Python applications following a frontend-backend architecture.

www.cesarsotovalero.net

 

 

  • 최근 AI 개발의 트렌드로 인해 본격적으로 파이썬 학습 및 사용을 시작했고, 이제는 그 생태계에 큰 만족을 느끼고 있음
  • Python은 과거보다 훨씬 빠르고 현대적인 언어로 발전했고, Cython을 통한 성능 향상 등 급격한 발전을 체감함
  • uv, ruff, pytest, Pydantic 등 최신 개발 도구와 라이브러리를 본인의 워크플로우에 적극 도입하여 개발 생산성을 높이고 있음
  • 프로덕션 환경과 Jupyter 노트북/스크립트 기반 개발 간의 차이를 줄이기 위한 프로젝트 구조 및 자동화 방안도 적용
  • GitHub Actions, Docker 등을 활용해 CI/CD, 테스트, 인프라 관리를 효율적으로 구축함.

 

I’m Switching to Python and Actually Liking It 요약

왜 파이썬으로 전향했는가

  • AI 중심의 개발 환경에서는 Python이 사실상의 표준 언어로 자리잡고 있음
  • 과거에는 단순한 스크립트 작성에만 사용했지만, 최근에는 RAG, 에이전트, 생성형 AI 등의 “실전용 앱”을 만들기 위해 진지하게 사용하게 되었음
  • 그 과정에서 Python 생태계가 과거에 비해 매우 진화했다는 사실을 체감하게 되었음

Python의 강점 3가지

  1. 풍부한 라이브러리와 도구 생태계: 데이터 처리, 분석, 웹, AI에 특화
  2. Cython 등으로 인한 성능 개선: 컴파일 기반 최적화 가능
  3. 개선된 문법 가독성: __init__, __new__ 같은 레거시 문법은 감춰지고, 더 직관적인 문법 제공

주요 도구 및 설정

  • uv
    • Astral에서 제공하는 최신 파이썬 패키지 매니저 및 빌드 도구
    • 의존성 관리, 가상환경 생성, 프로젝트 초기화 등 대부분의 작업을 빠르게 처리함
    • pyproject.toml이 핵심 설정 파일로, 모든 메타데이터 및 의존성 정보가 통합됨
    • uv init, uv add, uv sync 명령어로 빠르게 프로젝트 환경 구성 가능
  • ruff
    • 초고속 파이썬 린터 및 코드 포매터
    • isort, flake8, autoflake 등을 통합한 도구
    • ruff check, ruff format 으로 린팅 및 자동 수정
    • PEP 8 코딩 스타일 가이드 기본 지원
  • ty
    • Astral이 만든 Python용 정적 타입 검사기
    • typing과 조합해 정적 분석, 초기 버그 방지에 효과적
    • 초기 개발 단계임에도 안정적으로 사용할 만한 수준임
  • pytest
    • 단위테스트 및 확장 가능한 테스트 환경을 제공하는 대표적인 파이썬 테스트 프레임워크
    • 간단한 파일 네이밍 규칙과 명령어 한 줄로 바로 통합 테스트 가능함
      • test_*.py로 테스트 구성 후 uv run pytest로 실행
    • 간결한 문법, 풍부한 플러그인 생태계
  • Pydantic
    • 데이터 검증 및 환경 설정 관리 라이브러리
    • .env 환경변수 기반 설정 로딩 및 타입 검증
    • BaseSettings 클래스를 통해 API 키나 DB URL 등을 안전하게 관리
  • MkDocs
    • 파이썬 프로젝트의 정적 웹사이트 및 문서 생성을 간편하게 지원
    • 오픈소스 프로젝트 스타일의 미려한 디자인 빠른 적용 가능
    • GitHub Pages 연동도 용이
  • FastAPI
    • 빠른 RESTful API 구축 프레임워크
    • 자동 검증 및 문서화, 빠른 성능, 쉬운 Pydantic 통합 장점
    • Starlette 및 Pydantic 기반으로 높은 타입 안정성과 성능 제공
  • Dataclasses
    • 파이썬 표준 기능으로 데이터 중심 클래스를 간편하게 정의할 수 있음
    • 특별 메소드 자동 생성으로 보일러플레이트 코드 대폭 감소

버전 관리 및 자동화

  • GitHub Actions
    • project-api와 project-ui 각각에 대해 별도 CI 파이프라인 구성
    • 다양한 OS에서 CI 파이프라인 구축에 최적화된 워크플로우 제공
    • 도커 기반 테스트 환경으로 프로덕션과 동일한 환경에서 테스트 시행 가능
  • Dependabot
    • 자동 의존성 최신화 및 보안 패치 관리를 자동화함
  • Gitleaks
    • 민감 정보(비밀번호, API 키 등) 유출 방지 도구로 git 커밋 전에 보안 검사를 수행함
  • Pre-commit Hooks
    • 커밋 전 자동 린팅, 포매팅, 보안 검사를 위한 도구임
    • ruff, gitleaks 등과 함께 사용해 코드 일관성과 품질 유지

인프라 자동화

  • Make
    • make test, make infrastructure-up 등의 명령어로 일관된 개발 워크플로우 지원
    • 프로젝트 루트와 project-api에 각각 Makefile 존재
  • Docker & Docker Compose
    • project-api, project-ui 각각을 컨테이너로 분리 실행
    • docker compose up --build -d 한 줄로 전체 앱 실행 가능
    • Dockerfile에는 uv 설치, FastAPI 앱 실행 명령어 포함

마무리

  • 위와 같이 최신 파이썬 개발 환경에서는 효율적이고 견고한 프로덕션 워크플로우를 구성할 수 있음
  • AI, 데이터, 웹 개발 등 다양한 영역에 걸쳐 파이썬 생태계의 성장과 도구 발전으로부터 많은 이점을 경험 가능
  • 모노레포 구조, 자동화 도구, 린터 및 타입 검사기, 즉각적인 테스트 환경, 문서화, 인프라 오케스트레이션까지 하나의 통합된 개발 문화를 구현할 수 있음

https://news.hada.io/topic?id=22028&utm_source=weekly&utm_medium=email&utm_campaign=202529

 

파이썬으로 전향중이고, 생각보다 꽤 마음에 들어요 | GeekNews

최근 AI 개발의 트렌드로 인해 본격적으로 파이썬 학습 및 사용을 시작했고, 이제는 그 생태계에 큰 만족을 느끼고 있음Python은 과거보다 훨씬 빠르고 현대적인 언어로 발전했고, Cython을 통한 성

news.hada.io

 

반응형

+ Recent posts