코드 품질

포스트모템은 열기는 쉽고 쓸모 있게 만들기는 어렵습니다. 회의가 열리고, 문서가 작성되고, 액션 아이템 네 개가 기록되고, 그리고 여섯 달 뒤에 똑같은 장애가 다시 일어납니다. 그 무렵 누군가가 전혀 다른 것을 찾다가 그 오래된 문서를 우연히 발견하게 됩니다. 이 주제를 이야기할 때 관심은 대부분 무비난이라는 단어에 쏠립니다. 그 원칙은 실제로 중요하지만, 실패가 일어나는 지점은 거기가 아닙니다. 아주 철저하게 무비난 원칙을 지키면서도 아무것도 바꾸지 못하는 회고를 돌리는 조직이 대단히 많습니다. 회고 자체를 결과물로 취급했고,...

기술 문서는 아주 구체적이고 예측 가능한 방식으로 실패합니다. 누군가 한가한 2주 동안 아주 많은 양을 써 놓고, 그러는 사이 시스템이 바뀌고, 아무도 갱신하지 않고, 1년이 지나면 그 문서는 확신에 찬 어조로 틀린 내용을 말하고 있습니다. 그 시점부터는 없느니만 못합니다. 문서를 믿은 사람이 이미 성립하지 않는 정보에 근거해 움직이기 때문입니다. 흔한 대응은 더 많이 쓰자는 압박이고, 그것은 같은 실패를 더 빨리 불러올 뿐입니다. 쓸모 있는 대응은 더 적게 쓰고 무엇을 쓸지 고르는 것입니다. 병목은 쓰는 노력이 아니라 유지하는 노력이기 때문입니다. 어떤 문서가 존재...

개발자 온보딩은 보통 입사 교육이 며칠 걸렸는지로 측정되는데, 그것은 문제의 잘못된 쪽 끝을 보는 일입니다. 정작 중요한 숫자는 따로 있습니다. 새로 온 엔지니어가 무언가를 고치면서 다른 것을 망가뜨리지 않았다고 확신하기까지 얼마나 걸리는가입니다. 대부분의 팀에서 이 값은 며칠이 아니라 몇 달 단위로 측정됩니다. 지연의 원인이 사람인 경우는 드뭅니다. 원인은 시스템의 얼마나 많은 부분이 다른 사람들의 머릿속에만 존재하는지, 그리고 첫 두 주의 얼마나 많은 시간이 그것을 한 번에 하나씩 질문으로 꺼내오는 데 쓰이는지에 있습니다. 추적할 가치가 있는 단 하나의 지표는, ...

API 버전 관리 논쟁은 대개 엉뚱한 쪽에서 시작됩니다. 버전 번호를 어디에 둘 것인가 하는 문제 말입니다. 이 주제 전체에서 결과에 가장 영향이 작은 결정이 바로 그것입니다. 정작 중요한 것은 어떤 변경이 애초에 새 버전을 요구하는가이며, 대부분의 팀은 이 지점에서 안이한 쪽으로 판단을 그르칩니다. 순수하게 추가만 했다고 믿는 것을 배포했는데, 어느 클라이언트가 깨집니다. 쓸 만한 사고 모형은 이렇습니다. 여러분의 API는 호출자가 무엇에 기댈 수 있는지에 대한 약속입니다. 합리적인 호출자가 기대고 있던 무언가를 무효로 만든다면 그 변경은 호환성을 깨는 변경입니다....

기술 실사는 코드 품질을 겨루는 대회가 아니며, 실사를 준비하는 팀은 대개 엉뚱한 곳에 시간을 쏟습니다. 회사를 인수하려는 사람 중에 당신이 만든 추상화에 점수를 매기려는 사람은 없습니다. 인수자는 이 시스템을 소유하는 데 얼마가 들지, 그리고 돈이 오간 뒤에 상황이 얼마나 나빠질 수 있는지를 계산하려는 것입니다. 이렇게 질문을 다시 세우는 일이 중요한 이유는, 무엇부터 손봐야 하는지가 달라지기 때문입니다. 보기에 지저분해도 돌아가고, 팀이 이해하고 있으며, 안전하게 바꿀 수 있는 코드는 사소한 지적에 그칩니다....

데이터베이스 성능 작업은 보통 누군가 더 큰 인스턴스를 제안하는 것으로 시작해서, 페이지를 열 때마다 쿼리 하나가 400만 행을 순차 스캔하고 있었다는 발견으로 끝납니다. 제약은 처음부터 하드웨어가 아니었습니다. 제약은 실행 계획이었습니다. 이 패턴은 충분히 일관되게 반복되므로 기본 가정으로 삼을 만합니다. 애플리케이션이 느리고 데이터베이스가 바쁘다면, 원인은 거의 언제나 소수의 특정 쿼리이지 전반적인 용량 부족이 아닙니다. 그리고 서버를 키우는 일은 테이블이 다시 커지는 데 걸리는 시간만큼만 문제를 가려 줍니다. 무엇이든 바꾸기 전에 먼저 측정하십시오. 짐작으로 고...

소프트웨어 테스트 전략은 대개 커버리지라는 숫자로 설명되지만, 커버리지는 이 분야 전체에서 정보량이 가장 적은 숫자입니다. 커버리지가 구십 퍼센트인 코드베이스도 가장 많이 쓰이는 경로에서 버그를 그대로 배포할 수 있습니다. 커버리지는 테스트가 도는 동안 어떤 줄이 실행되었는지를 측정할 뿐, 그 줄에 대해 의미 있는 검증이 이루어졌는지는 전혀 측정하지 않기 때문입니다. 자기 테스트 스위트를 신뢰하는 팀은 퍼센트가 가장 높은 팀이 아닙니다. 무언가가 정말로 망가졌을 때 테스트가 빨간불을 켜고, 그 외의 순간에는 조용히 있는 팀입니다....

소프트웨어 개발 생명주기(보통 SDLC로 줄임)는 팀이 소프트웨어를 아이디어에서 기능하는 유지 관리 제품으로 이끌기 위해 따르는 구조화된 프로세스입니다. 소프트웨어를 개발하든 의뢰하든 이해하는 것이 중요합니다. 프로세스의 품질이 결과의 품질, 비용, 적시성을 크게 결정하기 때문입니다. 이 가이드는 소프트웨어 개발 생명주기를 명확하게 설명합니다: 각 단계와 그 내용, Agile과 Waterfall 접근 방식의 차이점, 프로젝트가 일반적으로 실패하는 곳, 그리고 좋은 프로세스가 비용과 리스크를 어떻게 통제하는지를 다룹니다. 요약 소프트웨어 개발 생명주기는 소프트웨어를 계...

웹 개발 모범 사례는 단순히 작동하는 웹사이트와 성능이 뛰어나고, 검색 순위가 높으며, 오랫동안 유지되는 웹사이트 사이의 차이를 만들어냅니다. 2026년에 기준은 그 어느 때보다 높아졌습니다. 사용자들은 즉각적인 로딩 시간을 기대하고, 검색 엔진은 속도와 접근성을 보상하며, 보안 위협은 끊임없이 이어집니다. 좋은 소식은 훌륭한 웹사이트를 만들어내는 실천 방법들이 잘 알려져 있다는 것입니다. 이 가이드는 오늘날 실제로 중요한 웹 개발 모범 사례를, 성능, 접근성, 보안, SEO, 코드 품질, 테스팅 분야에서,...

“기술 부채"에 대한 검색이 지난 2년 동안 35% 이상 증가했습니다. 이는 주로 마감 압박 하에 구축된 레거시 시스템을 물려받아 이제 유지하거나 확장하는 데 어려움을 겪고 있는 영국 엔지니어링 팀들에 의해 촉진되고 있습니다. 이 용어는 Jira 백로그와 스프린트 회고에서 느슨하게 사용되지만, 대부분의 개발자는 정확한 정의는커녕 이를 처리하기 위한 체계적인 전략을 본 적이 없습니다. 이 가이드는 기술 부채가 실제로 무엇인지, 어디서 오는지, 어떻게 측정하는지, 그리고 실제 영국 제품 팀에서 효과가 있는 실용적인 전략들을 다룹니다. Ward Cunningham의 원래 ...