소프트웨어가 작동하고 있는지 어떻게 알 수 있나요?

Source: Dev.to

위의 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.
(코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

우리가 다룰 내용

• Mindset – 당신이 맡게 될 다양한 역할: 제품 디자이너, 프로젝트 매니저, 기술 리드, 그리고 품질 보증 엔지니어.
• Brainstorming – 기능 아이디어를 구체적인 사양으로 전환하기.
• Managing coding agents – 규칙을 적용하는 방법, 규칙이 중요한 이유, 그리고 에이전트를 올바른 방향으로 유지하는 방법.
• Shipping – AI가 생성한 코드를 프로덕션에 자신 있게 배포하기 (네, 프로덕션에서 “바이브 코딩”도 할 거예요).

순서는 변동될 수 있습니다. 준비하세요!

요약

이전 글에서는 Claude가 규칙을 따르도록 만드는 방법을 보여줬습니다 (요약 – 스킬 + 훅이 해결책). 이제 Claude는 규칙을 따르지만…

Marcin, all tasks are complete.
브라우저를 열어 보면:
NoMethodError: undefined method 'hallucinated_method' for an instance of User (NoMethodError)

“잘했어, Claude! 하이‑파이브… 이제 프로덕션에 배포하자… 안돼.”

이것은 근본적인 질문을 제기합니다:

소프트웨어가 실제로 작동하고 있다는 것을 어떻게 알 수 있나요?

실제 사례 (2017)

• 회사: Paladin Software
• 작업: 거대한 YouTube‑수익 CSV 파일(기가바이트 규모) 처리.
• 맥락: 나는 호출 대기 엔지니어로서 시기적절하고 신뢰성 있는 처리를 보장했다.

아름다운 목요일 오후, 나는 크라쿠프에 있는 내가 가장 좋아하는 장소 Dolnych Młynów에 있었다. 금요일은 휴일이었다. 고객이 금요일에 스프레드시트를 업로드했지만, 월요일에 돌아왔을 때 수익이 아직 처리되지 않았다.

Sidekiq의 실패한 작업 큐를 살펴보니:

NoMethodError: undefined method 'hallucinated_method' for an instance of User (NoMethodError)

내가 LLM이 되기 전에도 그랬을까? 나는 확실히 그런 식으로 코드를 배포하고 있었다.

왜 LLM은 엄격한 가드레일이 필요한가

• 전향성 기억상실증: LLM은 세션이 시작된 후 새로운 기억을 형성할 수 없습니다. 훈련 데이터는 기억하지만 새로운 경험은 남지 않습니다.
• 비결정성: AI 에이전트가 한 번은 뛰어난 코드를 만들고 다음 번에는 깨진 코드를 만들 수 있습니다.

따라서 모델이 코드를 작성할 때마다 엄격한 규칙을 부여해야 합니다(규칙 적용에 관한 이전 게시물 참고) 그리고 검토와 체크를 추가해야 합니다.

워크플로우에서의 결정적 검사

아래는 로컬 CI에 포함되어야 한다는 제 의견입니다:

이것이 제공하는 것

• 단일 코드 스타일 – 일관된 포맷팅.
• 보안 – 알려진 취약점이 초기에 표시됩니다.
• 테스트 커버리지 – 새 코드와 변경된 코드가 실행됩니다.
• 런타임 오류 없음 – 실패가 CI에서 드러나고, 프로덕션에서는 발생하지 않음.

“AI 에이전트가 테스트 실패가 변경 사항과 무관하다고 말한 적이 몇 번이나 되었나요?”

보일러플레이트에 대한 우려?

아닙니다. 단위 테스트는 빠르고, 코딩 에이전트를 사용할 경우 그 어느 때보다 유지보수가 쉬워집니다. 신뢰성 향상이 약간의 보일러플레이트보다 훨씬 큰 이점을 제공합니다.

CI 샘플 출력

Continuous Integration
Running checks...

Rubocop
bundle exec rubocop -A
✅ Rubocop passed in 1.98s

Prettier
yarn prettier --config .prettierrc.json app/packs app/components --write
✅ Prettier passed in 1.57s

Brakeman
bundle exec brakeman --quiet --no-pager --except=EOLRails
✅ Brakeman passed in 8.76s

RSpec
bundle exec parallel_rspec --serialize-stdout --combine-stderr
✅ RSpec passed in 1m32.45s

Undercover
bundle exec undercover --lcov coverage/lcov/app.lcov --compare origin/master
✅ Undercover passed in 0.94s

✅ Continuous Integration passed in 1m45.70s

만약 **Rails 8.1+**을 사용하고 있다면, 이러한 검사 대부분이 프레임워크에 이미 내장되어 있습니다. Rails 8.0 이하를 사용한다면, 제 포팅된 구현을 사용하거나 직접 구현할 수 있습니다.

Lessons from My Early Career (2014)

• Job: Junior Rails developer at Netguru.
• Onboarding: “The Netguru way” – specific libraries and patterns.
• Feedback: My models were “fat”. I was pointed to Code Climate’s article “7 Ways to Decompose Fat ActiveRecord Models.”

I heard the rules but was too focused on business logic to apply them.

“The CLAUDE.md says ‘ALWAYS STOP and ask for clarification rather than making assumptions,’ and I violated that repeatedly. I got caught up in the momentum of the Rails 8 upgrade and stopped being careful.”

이것은 소프트웨어 산업에서 새로운 문제는 아니다. 해결책? 코드 리뷰. 모든 풀 리퀘스트는 다른 개발자가 검토해야 하며, 경험이 적은 개발자에게 안전망을 제공하고 전체적인 품질을 높인다.

…

(The post continues in the next installment.)

Source: …

3단계 검토 프로세스

목표:

• 좋은 실천 방식을 교육한다.
• 숙련된 개발자가 다른 사람을 멘토링하고 지식을 전수하도록 한다.
• 규칙을 적용해 모두가 승리하도록 한다.

기억하세요: 개발자가 자신의 코드를 직접 검토하도록 하지 마세요. AI 에이전트도 마찬가지입니다.

왜 3단계 검토인가?

1. 명세 준수 – 구현이 기능 명세와 정확히 일치하는지(더 많지도, 적지도 않게) 확인한다.
2. Rails 및 프로젝트‑특정 컨벤션 – 모든 컨벤션을 로드하고(이전 글 참고) 점검한다:
   • 인터페이스가 깔끔한가?
   • 파셜 대신 뷰 컴포넌트를 사용했는가?
   • 작업이 멱등적이고 얇은가?
   • 테스트가 동작을 검증하고 있는가?
3. 일반 코드 품질 검토 – 아키텍처, 설계, 문서화, 표준, 유지보수성을 평가한다.

각 단계는 서로 다른 에이전트가 새 관점으로 수행하며, 해당 기능에 대한 애착이 없기 때문에 구현 전체와 가능한 편차를 포괄적으로 파악할 수 있다.

예시 전체 보고서

1. 명세 준수 – 라인‑별 검증

2. Rails 컨벤션 – 체크리스트

3. 코드 품질 – 구조화된 보고서

• 강점
• 중요 / 필수 / 사소한 이슈 (참조 포함)
• 머지 평가

최종 요약 표

머지 준비 완료.

이슈가 발견되었을 때

리뷰는 이슈들을 하나의 실행 가능한 목록으로 통합하여, 작성자가 최종 머지 전에 각 항목을 쉽게 해결할 수 있도록 한다.

해결해야 할 정당한 발견