측정, 벤치마크, 배포: AI로 더 나은 소프트웨어 만들기
Source: Dev.to
죄송합니다만, 현재 저는 외부 웹사이트의 내용을 직접 가져올 수 없습니다. 번역이 필요한 텍스트를 그대로 제공해 주시면, 해당 부분을 한국어로 번역해 드릴 수 있습니다.
Source: …
볼 수 없는 것을 개선할 수 없습니다
속담에 “측정되는 것이 관리된다” 혹은 “돌출된 못은 망치에 맞는다” 라는 말이 있습니다.
무언가를 관리하려면 먼저 측정해야 하고, 못을 망치로 두드리려면 그 못이 튀어나와 있는 것을 감지할 수 있어야 합니다.
관심 있는 구체적인 지표를 식별하고 추적하세요. Hosaka Studio의 핵심 지표는 다음과 같습니다:
- 첫 번째 페인트까지 걸린 시간 – 앱을 처음 열 때
- 각 프레임 캡처에 소요된 시간 (스크린 및 웹캠) – 밀리초 단위
- 레코딩 편집기 열기 시 첫 번째 페인트까지 걸린 시간
- 편집기 미리보기 재생 성능 – 초당 프레임 수와 각 프레임을 처리하는 데 걸린 밀리초
이 지표들은 앱이 모든 것을 네이티브 프레임레이트로 캡처하고 동시에 사용자 입력에 즉시 반응하도록 보장합니다. 모든 지표는 디버그 모드에서 계산·로그되며(일부는 5초마다 샘플링) 터미널 색상이 회귀 값을 빨간색으로 표시해 주의를 끕니다.
AI는 소프트웨어 작성 비용을 크게 낮췄으며, 단위 테스트 작성도 포함됩니다—테스트를 작성하세요! Claude Code는 명시적인 프롬프트 없이도 테스트를 실행하지만, 프로젝트의 CLAUDE.md에 두 줄짜리 간단한 지시문을 넣어 Claude에게 테스트 실행 방법을 알려줄 수 있습니다:
# Run tests
uv run pytest
# Run the smoke test suite
uv run pytest -m smoke -v새 기능을 구현한 뒤에는 새롭거나 이전에 테스트되지 않은 동작에 대한 단위 테스트가 있는지 확인하십시오.
코드베이스를 변경할 때는 린트, 테스트, 그리고 수동 테스트도 수행하세요. 예외가 즉시 발생하는 수동 테스트는 시간도 많이 걸리고 좌절감을 줍니다. 가능한 한 많은 앱 기능을 CLI(또는 다른 방법)로 AI가 실행하도록 하세요—CLI나 배치 모드를 추가하는 경우도 포함합니다. 이렇게 하면 AI가 기능을 스모크 테스트하고 인수인계 전에 수정 사항을 찾아낼 수 있습니다.
Hosaka Studio의 경우, 사람과 AI가 비대화식으로 앱을 사용할 수 있도록 CLI 모드를 추가했습니다. 예시:
hosaka --auto --duration 60 --export이 명령은 60초 녹화를 생성하고 기본 위치(리눅스에서는 ~/Videos)에 내보냅니다. 이는 녹화 파이프라인이 엔드‑투‑엔드로 정상 작동함을 보장하는 확실하고 변조할 수 없는 방법을 제공합니다.
CI 작업을 모니터링하고, 실패를 분석하며, 수정 사항을 자동으로 생성할 수 있습니다. GitHub을 사용한다면 gh 도구를 설치·인증하세요(GitLab용 유사 도구도 존재합니다). 에이전트는 다음을 수행할 수 있습니다:
- CI 작업을 확인하고, 실패를 분석하며, 직접 수정 사항을 생성 (
Find out why this job failed and create a fix:) - 작업을 지속적으로 모니터링하고, 성공할 때까지 수정 사항을 푸시 (
Monitor this job, create and push fixes as appropriate until it runs green)
1번과 3번을 결합하면 성능 지표를 강타할 수 있습니다: AI에게 특정 지표에 대한 개선점을 식별하도록 지시하고, 벤치마크를 수행한 뒤 결과를 계획 형태로 제시하게 하세요. 이렇게 하면 AI가 당신이 중요하게 여기는 숫자를 볼 수 있게 되고, 실험하고 성능을 벤치마크할 수 있는 주도권을 갖게 됩니다.
이 기법의 직접적인 결과로, Hosaka Studio는 초기 프로토타입 단계에서 Pillow 의존에서 Pillow‑SIMD(OpenCV보다 빠르지만 여전히 CPU에 의존) 로, 그리고 GPU 합성으로 전환했습니다. 지속적인 GPU 최적화 덕분에 성능이 높게 유지되어 고성능 머신은 물론 수십 년 된 넷북에서도 화면 녹화에 뛰어난 성능을 발휘합니다.
이러한 제안은 표준 소프트웨어 개발 모범 사례를 대체하는 것이 아니라 보완합니다. 특히 규제가 엄격한 산업에서는 견고한 QA 프레임워크가 지속적인 코드 품질을 유지하기 위한 래칫 메커니즘을 제공합니다.
쓰레기를 넣으면, 쓰레기가 나온다
아이를 키우다 보면 “손 대지 마”, “형을 차지 마”, “벽에 그리기 금지” 같은 말을 하는 것이 시간 낭비라는 것을 금방 알게 됩니다. LLM 용어로는 쓸모 없는 컨텍스트를 제공하는 것이며, 그 결과는 그 도움이 되지 않는 입력을 중심으로 돌아갈 가능성이 높습니다.
대신 대화를 건설적이고 목표 지향적인 프롬프트로 이끌어 보세요. 예시:
Play with …Come and help me with …Stroke the cat gently
가능하면 좌절감은 개인적으로 처리하세요—당신이 (되어야 할) 성인입니다.
실수는 인간의 본성, 용서는 신성
실수가 인간의 특성이라면, 인간의 손으로 만든 기계는 더 많이 실수할 수 있습니다. AI가 말하거나 하는 모든 것을 약간은 의심하고 받아들이세요. 경우에 따라서는, 그 출력이 훈련 데이터의 총합만큼만 좋은 경우가 많습니다.
AI가 어떤 것이 불가능하다고 주장할 때는 무조건 받아들이지 마세요. 다음과 같이 요청하세요:
- 온라인 조사를 하고 결과를 보고합니다.
- 예시를 인용합니다: “X, Y & Z 모두 “를 구현했으니 절대적으로 가능합니다.”
- 상업적 제약을 강조합니다: “이것은 유료 사용자를 위한 상업용 제품이며, “는 허용될 수 없습니다.”
LLM은 FOSS(오픈소스) 관행에 크게 기반을 두고 훈련되는데, 그 중 일부는 도움이 되지 않을 수 있습니다—예를 들어, 사용자가 소프트웨어를 사용하기 위해 여러 절차를 거치게 만드는 경우 등. 소프트웨어는 삶을 더 편리하게 만들어야 합니다. 자신의 작업에 자부심을 가지고, 여러분이 만든 소프트웨어가 그 자부심을 반영하도록 하세요.