<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>제임스</title>
    <link>https://brunch.co.kr/@@glrH</link>
    <description>소프트웨어 QA의 인식 개선을 위해 노력하고 있습니다. 쉽고 재밌는 주제로 다가가겠습니다.</description>
    <language>ko</language>
    <pubDate>Tue, 21 Apr 2026 13:04:40 GMT</pubDate>
    <generator>Kakao Brunch</generator>
    <image>
      <title>소프트웨어 QA의 인식 개선을 위해 노력하고 있습니다. 쉽고 재밌는 주제로 다가가겠습니다.</title>
      <url>//img1.kakaocdn.net/thumb/C100x100/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2FglrH%2Fimage%2FHurgCC4hdP-RVrr8i_mhKHpMVac.jpg</url>
      <link>https://brunch.co.kr/@@glrH</link>
      <width>100</width>
      <height>100</height>
    </image>
    <item>
      <title>빠른 개발이 만든 느린 세상 - 32GB를 먹는 계산기가 우리에게 보내는 경고</title>
      <link>https://brunch.co.kr/@@glrH/234</link>
      <description>출처 -&amp;nbsp;대규모 소프트웨어 품질 붕괴, 그리고 재앙이 일상화된 과정 - The Great Software Quality Collapse - Tech Trenches (위 글을 읽고 떠오른 생각과 QA 엔지니어로서의 경험을 함께 풀어냈습니다.  개발자 커뮤니티에서 &amp;quot;32GB를 먹는 계산기&amp;quot;라는 밈이 화제가 되었습니다. 실제 버그 리포트인지 과장된 비유인지는</description>
      <pubDate>Sun, 12 Oct 2025 15:00:30 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/234</guid>
    </item>
    <item>
      <title>Mock의 역설 - 격리와 통합 사이에서 균형 찾기</title>
      <link>https://brunch.co.kr/@@glrH/233</link>
      <description>&amp;quot;우리 테스트는 모두 통과했습니다. 100% 성공률입니다.&amp;quot;  월요일 아침 스탠드업 미팅. 시니어 개발자가 자신있게 보고했습니다. 하지만 화요일 오후, 프로덕션 배포 직후 고객 지원팀 슬랙 채널이 폭발했습니다. 외부 결제 API가 새로운 응답 형식을 반환하기 시작했고, 우리의 완벽했던 Mock은 이를 전혀 반영하지 못했던 것입니다.  이것이 바로 Mock의</description>
      <pubDate>Tue, 23 Sep 2025 23:00:17 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/233</guid>
    </item>
    <item>
      <title>테스트 데이터의 주권 - GDPR 시대의 합성 데이터 생성 전략</title>
      <link>https://brunch.co.kr/@@glrH/232</link>
      <description>가짜 데이터가 진짜보다 더 가치 있는 시대가 왔습니다. 2020년 10월, British Airways는 2018년 데이터 침해 사건으로 영국 ICO로부터 2,000만 파운드(약 330억원)의 과징금을 부과받았습니다. 약 40만 명의 고객 정보가 영향을 받은 이 사건에서 주목할 점은, 많은 보안 전문가들이 지적한 &amp;quot;테스트 환경 보안의 사각지대&amp;quot;였습니다. 실</description>
      <pubDate>Sun, 21 Sep 2025 23:00:41 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/232</guid>
    </item>
    <item>
      <title>AI 시대의 Quality Leadership - 테스트 자동화의 패러다임을 바꾸는 새로운 리더십</title>
      <link>https://brunch.co.kr/@@glrH/229</link>
      <description>&amp;quot;AI가 테스트 코드의 70%를 자동으로 생성합니다. 버그를 사전에 예측하고, 성능 저하를 미리 경고합니다. 테스트가 스스로 고쳐집니다.&amp;quot; 2024년, 글로벌 테크 기업들이 앞다투어 발표한 AI 활용 사례들입니다. Microsoft는 GitHub Copilot으로 테스트 작성 시간을 절반으로 단축했다고 발표했고, Google은 AI 기반 버그 예측 시스템으&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2FglrH%2Fimage%2FgTRIycFG85dZ3boT6tofelcFtKk.png" width="500" /&gt;</description>
      <pubDate>Thu, 18 Sep 2025 20:00:02 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/229</guid>
    </item>
    <item>
      <title>모놀리식 QA에서 분산 QA로 - Conway's Law가 테스팅에 미치는 영향</title>
      <link>https://brunch.co.kr/@@glrH/231</link>
      <description>&amp;quot;우리의 테스트 코드는 왜 이렇게 복잡해졌을까요?&amp;quot;  이 질문의 답은 코드베이스에만 있지 않습니다. 1968년 멜빈 콘웨이가 제시한 바와 같이 &amp;quot;조직의 커뮤니케이션 구조는 시스템 설계에 반영된다&amp;quot;는 원리는, 분산 시스템 시대의 테스트 아키텍처에도 그대로 투영됩니다. 팀이 기능 라인별로 갈라지면 테스트 리포지토리도 분화되고, 의사소통 경계가 많을수록 인터페이</description>
      <pubDate>Thu, 18 Sep 2025 01:00:12 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/231</guid>
    </item>
    <item>
      <title>원격 환경에서의 품질 팀 리딩 - 분산된 팀을 하나로 연결하는 품질 리더십의 진화</title>
      <link>https://brunch.co.kr/@@glrH/228</link>
      <description>&amp;quot;원격 팀원들이 서로 다른 시간대에서 일하는데, 긴급 버그가 발생하면 어떻게 대응하죠?&amp;quot; &amp;quot;테스트 환경이 충돌하지 않으려면 어떻게 조율해야 하나요?&amp;quot; &amp;quot;팀원들의 성과를 어떻게 공정하게 평가할 수 있을까요?&amp;quot;  2024년, 작년 한 스타트업 QA 리더가 저에게 던진 질문들입니다. 완전 원격 체제로 전환한 지 6개월, 품질은 떨어지고 팀은 흩어지고 있었습니다.</description>
      <pubDate>Wed, 17 Sep 2025 20:00:01 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/228</guid>
    </item>
    <item>
      <title>스타트업 QA 리더의 생존 전략 - 리소스 제약 속에서 품질 임팩트를 만들어내는 실전 가이드</title>
      <link>https://brunch.co.kr/@@glrH/227</link>
      <description>스타트업에서 QA 리더로 일한다는 것은 마치 폭풍우 속에서 항해하는 것과 같습니다. 제한된 리소스, 빠른 릴리즈 주기, 끊임없이 변하는 요구사항 속에서 품질을 지켜내야 하죠. 저는 지난 몇 년간 국내외 여러 스타트업의 QA 리더들과 일하며, 그들이 어떻게 이런 도전을 극복하고 성공적으로 품질 문화를 구축했는지 목격했습니다.   스타트업 QA의 현실: 숫자로&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2FglrH%2Fimage%2FatpKm5RpWkuu6YjaLqL3HMXiIIE.png" width="500" /&gt;</description>
      <pubDate>Tue, 16 Sep 2025 20:00:03 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/227</guid>
    </item>
    <item>
      <title>플레이키 테스트의 경제학 - 불안정성이 조직에 미치는 실제 비용 분석</title>
      <link>https://brunch.co.kr/@@glrH/230</link>
      <description>&amp;quot;테스트가 또 실패했네요. 다시 돌려볼까요?&amp;quot;  매일 아침 스탠드업 미팅에서 들리는 이 한마디가 얼마나 많은 비용을 발생시키는지 아시나요? Google Testing Blog(2016)에 따르면 사내 테스트의 약 16%가 일정 수준의 플레이키(Flaky) 특성을 보였다고 합니다. 이로 인한 개발자 생산성 손실은 조직 전체에 상당한 영향을 미칩니다. (참고:</description>
      <pubDate>Tue, 16 Sep 2025 01:00:16 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/230</guid>
    </item>
    <item>
      <title>실패에서 배우는 품질 리더십 - 포스트모템 문화로 성장하는 조직 만들기</title>
      <link>https://brunch.co.kr/@@glrH/226</link>
      <description>새벽 3시, 긴급 호출이 울립니다. 결제 시스템이 전면 마비되었고, 고객 문의가 폭주하고 있습니다. 4시간 후 서비스는 복구되었지만, 매출 손실은 수억 원에 달합니다. 이때 QA 리더인 당신은 무엇을 해야 할까요? 범인 찾기에 나설까요, 아니면 이 실패를 조직의 자산으로 만들까요?   실패를 대하는 자세의 전환 2017년 아마존 S3 서비스가 4시간 동안</description>
      <pubDate>Mon, 15 Sep 2025 20:00:03 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/226</guid>
    </item>
    <item>
      <title>QA 엔지니어 커리어 패스와 멘토링 - 주니어부터 리더까지, 성장 로드맵과 멘토링 시스템 구축하기</title>
      <link>https://brunch.co.kr/@@glrH/225</link>
      <description>&amp;quot;시니어가 되면 뭐가 달라지나요?&amp;quot;  4년차 QA 엔지니어가 1:1 미팅에서 던진 질문이었습니다. 순간 답이 막혔습니다. 개발자라면 &amp;quot;아키텍처 설계를 주도하고, 기술 의사결정을 내립니다&amp;quot;라고 명확히 답할 수 있을 텐데, QA 엔지니어의 시니어는 무엇이 다를까요? 많은 QA 엔지니어들이 비슷한 고민을 합니다. 개발자에 비해 QA 엔지니어의 커리어 패스는 여전</description>
      <pubDate>Sun, 14 Sep 2025 20:00:06 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/225</guid>
    </item>
    <item>
      <title>발표를 잘하는 사람은 대본이 없다 - 완벽한 발표 대본보다 중요한 것은 그 분야에 대한 깊은 이해다</title>
      <link>https://brunch.co.kr/@@glrH/223</link>
      <description>&amp;quot;발표, 정말 실력의 문제일까요?&amp;quot;  회사에서 발표를 앞두면 며칠 전부터 잠을 설칩니다. 새벽 3시, 침대에 누워서도 발표 시뮬레이션을 돌립니다. &amp;quot;안녕하십니까, 오늘 제가 발표할 내용은...&amp;quot; PPT는 몇 번이고 수정합니다. 폰트 크기, 애니메이션 효과, 슬라이드 전환 시간까지. 대본은 통째로 외웁니다. A4 용지에 빼곡히 적힌 문장들을 형광펜으로 칠하며</description>
      <pubDate>Sat, 13 Sep 2025 12:30:40 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/223</guid>
    </item>
    <item>
      <title>테스트 코드의 부채 - 기술 부채보다 위험한 이유와 측정 방법</title>
      <link>https://brunch.co.kr/@@glrH/221</link>
      <description>&amp;quot;테스트 커버리지 85%입니다. 우리 시스템은 안전합니다.&amp;quot;  많은 개발팀이 이런 숫자에 안도합니다. 하지만 높은 커버리지 수치가 실제 품질을 보장할까요? 테스트는 통과하지만 프로덕션에서는 버그가 발생하는 경험, 한 번쯤은 있으실 겁니다. 이것이 바로 테스트 코드 부채(Test Debt)의 전형적인 증상입니다.  Martin Fowler가 기술 부채(Tec&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2FglrH%2Fimage%2FGvXyZe2fJCkFGmBm8MbgayL0Q-U.png" width="500" /&gt;</description>
      <pubDate>Fri, 12 Sep 2025 01:00:11 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/221</guid>
    </item>
    <item>
      <title>프로덕션 환경 모니터링과 품질 리더십 - 실시간 품질 보장을 위한 관찰가능성 구축과 조직 문화 혁신</title>
      <link>https://brunch.co.kr/@@glrH/222</link>
      <description>솔직히 말씀드리면, 저는 경력이 적었을 때, 프로덕션 환경을 무서워했습니다. QA 엔지니어로 처음 일을 시작했을 때, 테스트 환경에서는 자신 있게 버그를 찾아내던 제가 프로덕션 모니터링 대시보드 앞에서는 한없이 작아졌습니다. 빨간색으로 깜빡이는 알람들, 이해할 수 없는 그래프들, 그리고 무엇보다 실제 사용자들이 겪고 있을 문제들의 무게가 저를 압도했던 것으</description>
      <pubDate>Thu, 11 Sep 2025 20:00:07 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/222</guid>
    </item>
    <item>
      <title>크로스펑셔널 팀의 QA 엠베서더 육성법 - 모든 팀원이 품질의 주인이 되는 문화 만들기</title>
      <link>https://brunch.co.kr/@@glrH/216</link>
      <description>우리 팀에는 QA 엔지니어가 없어서 품질이 문제예요. 스타트업에서 일하다 보면 자주 듣는 말입니다. 하지만 정말 QA 엔지니어가 없어서 품질이 문제일까요? 아니면 품질을 특정 역할의 책임으로만 여기는 인식이 문제일까요? 크로스펑셔널 팀에서 QA 엠베서더를 육성한다는 것은 단순히 개발자에게 테스트를 시키는 것이 아닙니다. 모든 팀원이 품질에 대한 주인의식을</description>
      <pubDate>Wed, 10 Sep 2025 20:00:03 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/216</guid>
    </item>
    <item>
      <title>Shift-Everywhere의 시대 - 전방위 품질 전략의 구현</title>
      <link>https://brunch.co.kr/@@glrH/220</link>
      <description>품질의 패러다임이 다시 한 번 전환되고 있습니다 최근 6개월, Shift-Left를 완비한 팀조차 프로덕션 품질이 정체하는 사례가 늘고 있습니다.  &amp;quot;우리는 Shift-Left를 완벽하게 구현했습니다. 개발자들이 테스트를 작성하고, CI/CD 파이프라인에 자동화된 테스트가 통합되어 있으며, 기획 단계부터 QA 엔지니어가 참여합니다.&amp;quot;  한 스타트업의 CTO</description>
      <pubDate>Wed, 10 Sep 2025 01:00:26 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/220</guid>
    </item>
    <item>
      <title>프로덕션 환경 모니터링과 품질 리더십 - 실시간 품질 보장을 위한 관찰가능성 구축과 조직 문화 혁신</title>
      <link>https://brunch.co.kr/@@glrH/217</link>
      <description>새벽 3시의 알람 새벽 3시, 온콜 엔지니어의 휴대폰이 울립니다. 프로덕션 환경에서 에러율이 급증했다는 알림입니다. 5분 뒤, 슬랙 채널에는 CS팀의 메시지가 올라옵니다. &amp;quot;고객들이 결제가 안 된다고 문의하고 있어요.&amp;quot; 30분 후, CEO로부터 전화가 옵니다. &amp;quot;지금 매출이 얼마나 손실되고 있는 건가요?&amp;quot; 이것이 프로덕션 모니터링이 제대로 구축되지 않은 조</description>
      <pubDate>Tue, 09 Sep 2025 20:00:07 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/217</guid>
    </item>
    <item>
      <title>테스트 피라미드의 죽음 - 마이크로서비스 시대의 새로운 테스팅 토폴로지</title>
      <link>https://brunch.co.kr/@@glrH/219</link>
      <description>피라미드는 무너지고 있습니다 2009년, Mike Cohn이 『Succeeding with Agile』에서 제안한 테스트 피라미드는 QA 업계의 황금률이었습니다. 단위 테스트를 기반으로, 통합 테스트를 중간에, E2E 테스트를 꼭대기에 두는 이 구조는 10년 이상 의심받지 않는 진리였습니다. 70% 단위 테스트, 20% 통합 테스트, 10% E2E 테스트라</description>
      <pubDate>Tue, 09 Sep 2025 12:08:40 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/219</guid>
    </item>
    <item>
      <title>QA 엔지니어도 해커가 되어야 한다 - 보안 취약점 사전 CWE로 시작하는 시큐어 테스팅</title>
      <link>https://brunch.co.kr/@@glrH/218</link>
      <description>&amp;quot;이 버그가 보안 이슈인가요, 아닌가요?&amp;quot; QA 엔지니어로 일하다 보면 이런 질문을 자주 받게 됩니다. 기능 테스트는 자신 있게 하지만, 발견한 버그가 얼마나 심각한 보안 취약점인지 판단하기는 쉽지 않죠. 오늘은 전 세계적으로 표준화된 보안 취약점 분류 체계인 CWE(Common Weakness Enumeration)에 대해 알아보고, QA 엔지니어 관점에</description>
      <pubDate>Tue, 09 Sep 2025 01:00:20 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/218</guid>
    </item>
    <item>
      <title>CI/CD 파이프라인에서 QA 엔지니어의 역할 - 품질의 문지기에서 배포의 가속기로</title>
      <link>https://brunch.co.kr/@@glrH/215</link>
      <description>QA 엔지니어가 병목이 되면 안 됩니다. QA 엔지니어가 엔진이 되어야 합니다.  한 스타트업의 CTO가 제게 했던 말입니다. 처음엔 부담스러웠지만, CI/CD 파이프라인에서 QA 엔지니어의 역할을 재정의하면서 이 말의 진정한 의미를 깨달았습니다. 오늘은 현대적인 CI/CD 환경에서 QA 엔지니어가 어떻게 품질의 책임자이자 배포의 좋은 스위치가 될 수 있는</description>
      <pubDate>Mon, 08 Sep 2025 20:00:02 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/215</guid>
    </item>
    <item>
      <title>테스트 자동화 ROI 극대화 전략 - 투자 대비 가치를 증명하는 스마트한 자동화 접근법</title>
      <link>https://brunch.co.kr/@@glrH/214</link>
      <description>&amp;quot;테스트 자동화를 도입했는데 정말 효과가 있나요?&amp;quot; QA 리더라면 누구나 한 번쯤 받아본 질문입니다. 경영진은 자동화 도구와 인프라에 투자한 비용 대비 실질적인 가치를 보고 싶어 합니다. 개발팀은 자동화 스크립트 작성과 유지보수에 들어가는 시간이 정말 의미 있는지 궁금해합니다. 이 글에서는 테스트 자동화의 ROI를 정확히 측정하고, 이를 극대화하는 실전 전</description>
      <pubDate>Sun, 07 Sep 2025 20:00:06 GMT</pubDate>
      <author>제임스</author>
      <guid>https://brunch.co.kr/@@glrH/214</guid>
    </item>
  </channel>
</rss>
