클로드에게 앱 하나를 주고 네 명의 서로 다른 시니어 개발자처럼 행동해 달라고 부탁했습니다. 그 결과는 다음과 같습니다.

온라인, 특히 X 커뮤니티에는 챗봇의 효율성을 높여준다는 주장이 넘쳐납니다. AI 교육 전문가인 데이비드 맥스 의 주장을 처음 접했을 때는 회의적이었지만, 바로 그 점 때문에 직접 시도해 보기로 했습니다. 이 주장들은 챗봇 Claude를 숙련된 디버거부터 성능 전문가까지 모든 역할을 수행할 수 있도록 바꿔준다고 합니다. 제가 직접 조사해 본 결과는 다음과 같습니다. 더 효과적인 주장에 관심이 있다면, 아이디어를 발전시키고 생산성을 높이는 데 도움이 되는 7가지 효과적인 Claude 4 주장을 확인해 보세요.

Claude에서 내 가정 지출 내역을 확인하세요

저는 이미 ChatGPT Work를 사용하여 비용 입력란이 있는 일반 비용 추적기를 만들어 놓은 상태였기 때문에, 그 도구를 활용하여 클로드에게 네 번에 걸쳐 애플리케이션을 검토해 달라고 요청했습니다. 매번 저는 그에게 풀스택 엔지니어, 디버깅 엔지니어, 프런트엔드 엔지니어, 성능 엔지니어 등 서로 다른 주요 엔지니어링 역할을 부여했습니다.

그 결과는 단순히 클로드에게 "앱을 개선해 달라"고 요청하는 것보다 훨씬 더 많은 것을 드러냈습니다. 각 참가자는 서로 다른 문제점에 집중했고, 때로는 이전 "개발자"가 놓쳤던 문제점까지 발견하기도 했습니다. 어떤 일이 있었고, 그들이 어떤 주장을 펼쳤는지 살펴보겠습니다.

1. 선임 풀스택 엔지니어가 애플리케이션을 개발했습니다.

이 모든 것은 클로드가 누구나 사용할 수 있는 대화형 가계 지출 추적 앱을 만들어 달라는 요청에서 시작되었습니다. 클로드의 앱 개발 기능에 대한 자세한 내용은 " 클로드와 제미니를 이용해 몇 분 만에 앱 3개를 만들었습니다. 그중 하나에는 숨겨진 기능이 있습니다 ."를 참조하세요.

과제: 누구나 사용할 수 있는 대화형 가계 지출 추적 도구를 개발하여 지출 내역을 기록하고 분석하세요. 이 도구는 지출 내역 추가 및 삭제, 카테고리 지정, 거래 필터링, 총 지출액 계산, 카테고리별 시각적 분석 기능을 포함해야 합니다.

자신을 스타트업을 위한 완성도 높은 MVP를 개발하는 시니어 풀스택 엔지니어라고 생각해 보세요. 코드를 작성하기 전에 아키텍처, 데이터 구조 및 사용자 흐름에 대한 간략한 개요를 제공하세요. 그런 다음 애플리케이션을 클라우드 아티팩트로 구축하세요.

반응형 디자인을 적용하고 사용하기 쉽게 만드세요. 하지만 최종 코드 검토, 디버깅, 개선에 추가 시간을 쏟지 마세요. 그런 작업은 다른 개발자에게 맡기겠습니다.

클로드는 놀라울 정도로 완성도 높은 React 앱을 만들었습니다. 이 앱에는 샘플 거래 내역, 총 지출액, 카테고리 순위, 검색 및 필터 기능, 날짜별 거래 내역 정렬 기능 등이 포함되어 있었습니다. 또한 변경 사항을 저장하여 앱을 다시 실행한 후에도 변경 내용을 사용할 수 있도록 했습니다.

언뜻 보기에 미완성 프로토타입이라기보다는 완성품에 훨씬 가까워 보였다. 상단에는 통계 카드가 있었고, 깔끔한 지출 내역서와 각 항목별 지출액을 보여주는 색깔 막대가 있었다.

2. 선임 디버깅 엔지니어가 몇 가지 문제를 발견했습니다.

그 후, 저는 클로드에게 겉모습은 신경 쓰지 말고 디버깅 엔지니어로서 애플리케이션 출시를 준비하는 자신의 업무에 집중해 달라고 부탁했습니다.

요구 사항: 이제, 이 애플리케이션이 공개되기 전에 인수받은 수석 디버거처럼 행동하십시오.

의도된 기능이나 시각적 디자인을 변경하지 않고 애플리케이션과 기존 코드를 주의 깊게 검토하십시오. 주요 사용자 흐름을 테스트하고 기능 오류, 잘못된 입력 처리, 데이터 손실 위험, 잘못된 계산, 영구 저장 문제 및 예외 상황을 찾으십시오.

코드를 수정하기 전에, 테스트 내용, 발견된 문제점, 각 문제점의 근본 원인, 심각도, 그리고 권장하는 해결 방법을 포함한 간략한 디버깅 보고서를 제출해 주십시오.

그런 다음 수리를 진행하고 원래 기능이 여전히 작동하는지 확인하십시오. 외관을 재설계하거나, 대대적인 건축적 개조를 하거나, 단순히 미적인 변경만 해서는 안 됩니다.

디버깅 과정에서 여러 가지 실제 문제점이 드러났습니다.

예를 들어, 원래 입력 형식이 올바르지 않았습니다. "거래 저장" 버튼을 클릭하는 것은 작동했지만, 엔터 키를 누르는 것은 작동하지 않을 수 있었습니다. 클로드는 해당 섹션을 제출 버튼이 있는 올바른 형식으로 변환하여 이 문제를 해결했습니다.

그는 또한 사용자가 기록을 삭제하고 잘못된 날짜 정보로 거래를 저장할 수 있다는 사실을 발견했습니다. 클로드는 날짜 유효성 검사를 추가하고, 잘못된 금액에 대한 검사를 강화했으며, 추적기가 비어 있을 때에도 "주택"이 가장 큰 카테고리로 표시되도록 하는 계산 오류를 수정했습니다.

여전히 한 번의 클릭으로 거래를 영구적으로 삭제할 수 있었습니다. 저장소 오류는 개발자 콘솔에 숨겨져 있어 사용자는 정보가 저장되지 않았는데도 저장되었다고 생각할 수 있었습니다. 더욱이 Claude는 수정 사항이 제대로 작동하는지 확인하기 위한 자동화된 테스트를 구현하지 않았습니다.

3. 노련한 프론트엔드 엔지니어는 완전히 다른 활용 가능성을 발견했습니다.

세 번째 라운드에서 저는 클로드에게 반응형 디자인과 접근성을 전문으로 하는 프론트엔드 엔지니어의 관점에서 비용 추적기를 다뤄달라고 요청했습니다.

요구 사항: 접근성과 반응성을 갖춘 소비자 애플리케이션 개발에 특화된 숙련된 프론트엔드 엔지니어처럼 지금 바로 행동하세요.

현재 사용 중인 지출 추적 도구를 휴대폰, 키보드 또는 보조 기술을 사용하는 사람의 관점에서 검토하십시오. 기능과 전반적인 시각적 정체성은 유지하되, 사용성과 접근성을 개선하십시오.

코드를 변경하기 전에 모바일 기기의 동작 및 반응성, 키보드 탐색, 폼 사용성, 화면 읽기 프로그램 접근성, 색상 대비, 로딩 및 오류 상태, 파괴적인 동작, 혼란스러운 컨트롤 등을 간략하게 검토하십시오.

그런 다음 개선 사항을 구현하십시오. 모든 입력 필드와 대화형 컨트롤에 접근성 있는 이름이 지정되어 있는지, 포커스 상태가 명확하게 표시되는지, 확인 메시지가 화면 판독기에서 읽어질 수 있는지, 그리고 지출 내역이 색상 막대에만 의존하지 않고 정보를 전달하는지 확인하십시오.

이번 실험에 대한 가장 포괄적인 검토였다.

클로드는 해당 앱이 선택된 입력 필드 주변의 자연스러운 테두리를 제거하면서 대체 테두리를 제공하지 않았다고 지적했습니다. 결과적으로 키보드를 사용하는 사용자는 활성화된 필드를 확인하기 어려울 것입니다.

또한 시각적 레이블이 해당 입력 필드에 제대로 연결되지 않았고, 검색 필드가 자리 표시자 텍스트에만 의존했으며, 유효성 검사 오류가 화면 판독기에서 읽히도록 설정되어 있지 않은 것으로 나타났습니다.

클로드는 시각적 초점 표시기를 복원하고, 레이블을 폼 컨트롤에 연결하고, 화면 읽기용 설명을 추가하고, 밝은 회색 텍스트 요소의 대비를 높였습니다. 또한 작은 화면에서 검색창을 더 유연하게 사용할 수 있도록 개선하고 아이콘만 포함된 버튼에 더 자세한 설명이 담긴 레이블을 추가했습니다.

무엇보다 중요한 것은, 이 캐릭터가 디버거가 간과했던 삭제 문제를 발견했다는 점입니다. 클로드는 원클릭 삭제 버튼을 사용자가 거래를 삭제하거나 유지하도록 요구하는 2단계 확인 절차로 교체했습니다.

모든 주장이 완벽했던 것은 아닙니다. 클로드는 최소 터치 영역 크기를 44 x 44 픽셀로 설명했지만, 기본 삭제 버튼만 36 x 36 픽셀로 확대했습니다. 이는 WCAG 2.2 AA 기준의 더 작은 크기는 충족하지만, 그가 언급한 44 픽셀 권장 사항에는 미치지 못합니다.

하지만 클로드의 역할을 바꾸자 관점이 확연히 달라졌습니다. 디버거는 애플리케이션이 제대로 작동하는지 확인하는 반면, 프런트엔드 엔지니어는 실제 사용자가 편안하게 사용할 수 있는지 여부를 검토했습니다. 이 실험은 단 하나의 요구사항이 클로드의 결과에 얼마나 큰 영향을 미칠 수 있는지 보여줍니다.

4. 성능 엔지니어는 해당 애플리케이션이 많은 개선이 필요하지 않다는 점을 인정했습니다.

마지막으로, 저는 클로드에게 최소 10,000만 건의 거래를 처리할 수 있는 지출 추적 시스템을 구축해달라고 부탁했습니다.

요구 사항: 이제 선임 성능 엔지니어로서 수천 건의 거래를 처리할 수 있도록 이 경비 추적 시스템을 준비하십시오.

현재 구현 방식을 분석하여 불필요한 렌더링, 중복 계산, 비효율적인 정렬 또는 필터링, 스토리지 병목 현상, 메모리 증가, 데이터 크기 증가에 따라 속도가 느려질 수 있는 상호 작용 등을 파악합니다.

성능 문제가 있다고 단정짓지 마세요. 최소 10,000건의 트랜잭션을 처리하는 현실적인 테스트 방법을 마련하고, 핵심 작업에 대한 기준선을 설정하세요.

분석 결과에 따라 타당성이 입증된 개선 사항만 구현하십시오. 앱의 외관, 접근성 향상 및 현재 동작은 그대로 유지하십시오. 속도 향상을 주장하려면 해당 사항을 측정했거나 예상되는 개선 사항으로 명확하게 정의해야 합니다.

클로드는 특히 심각한 병목 현상 하나를 발견했습니다. 해당 애플리케이션은 금액을 표시할 때마다 새로운 통화 형식 객체를 생성하고 있었습니다. 10,000개의 행을 기준으로 이 프로세스를 측정했을 때 349밀리초가 걸렸습니다. 단일 포맷터를 재사용함으로써 이 시간을 5.2밀리초로 단축할 수 있었고, 클로드는 이를 67배의 성능 향상으로 계산했습니다.

클로드는 또한 "테이블 가상화" 기능을 추가하여 브라우저가 수천 개의 행을 한 번에 표시하는 대신 현재 화면에 보이는 거래만 표시하도록 했습니다. 검색 및 저장소 업데이트는 매 키 입력이나 빠른 변경 후 발생하는 비용이 많이 드는 반복 작업을 방지하기 위해 아주 짧은 시간 동안 지연되었습니다.

클로드는 스트레스 테스트를 위해 1,000건, 10,000건 또는 50,000건의 샘플 거래를 생성할 수 있는 버튼까지 추가했습니다.

하지만 보고서에서 가장 설득력 있는 부분은 클로드가 이러한 개선 사항 대부분이 애플리케이션의 본래 목적에 필요하지 않다는 점을 인정한 것이었습니다.

일반 가정에서는 한 달에 30~50건 정도의 거래가 발생할 수 있습니다. 클로드는 10년이 지난 후에도 기존 애플리케이션이 이러한 데이터를 큰 문제 없이 처리했을 것이라고 결론지었습니다. 통화 포맷터 캐싱을 제외하면, 대부분의 개선 사항은 제가 수천 건의 거래 지원을 특별히 요청했기 때문에 유용했습니다.

이러한 자제력(또는 자기 통제력)은 단순히 변화를 만들어내는 것 자체보다 더 "성숙하고" "전문적"으로 보였다.

제 최종 결론은 다음과 같습니다.

저는 이러한 주장들이 매우 효과적이라고 생각했습니다. 각각의 주장이 클로드의 강점과 약점을 명확하게 부각시켜 주었기 때문입니다. 각 역할은 평가에 있어 독특한 관점을 제공해 주었고, 이는 매우 유용했으며 앞으로 다른 앱과 웹사이트를 검토할 때도 반드시 활용할 것입니다.

디버깅 엔지니어는 잘못된 동작을 발견했고, 프런트엔드 엔지니어는 접근성 및 사용성 문제를 발견했습니다. 반면 성능 엔지니어는 데이터 볼륨 증가의 영향을 고려하고 최적화가 불필요한 시점을 파악했습니다.

이 경험은 "이것을 바로 생산 가능한 상태로 만들어라"와 같은 포괄적인 단일 요구가 최선의 접근 방식이 아닐 수 있음을 보여주었습니다. 요구 사항이 아무리 포괄적으로 보이더라도 단 한 번의 검토로는 중요한 문제를 간과할 수 있습니다. 작업을 단계별로 세분화함으로써 클로드는 처리해야 할 우선순위가 줄어들었고, 결과 평가도 더 쉬워졌습니다.

클라우드 사용량 제한에 유의하세요. 다음번에는 최대 허용량을 초과하지 않도록 프롬프트를 조합해 보겠습니다.

---

---