하네스 전에 클로드 코드와 클로드를 나름대로 잘 써먹기 - 브런치

프로젝트 데이비드: 다시 개발을 시작하다 아내를 위한 오름 깨기 앱 개발 과정에서 구축한 인프라를 멀티 앱 배포를 위한 데브옵스 서버로 바꾸기로 결정했습니다.[1] 경험으로 클로드에 의존했더니 친절하게 구성도까지 그려 줍니다. 하지만, 반복적인 실패를 맛보게 됩니다. 알고 보니 Python 특정 버전의 서버 빌드 과정에서 계속 SSH가 타임 아웃이 되는 것이었습니다. 클로드 코드가 아니라 클로드에 의존했더니 시스템 맥락을 무시한 제안을 한 것이고, 그걸 그대로 옮기는 행동을 제가 저지른 것이죠. 낮에 훑어본 논문 이 떠오릅니다. 논문 내용을 모두 파악한 것은 아니지만, 프롬프트에 제 서버 구성을 모두 입력할 수는 없기 때문에 클로드 코드를 쓰면 메모리 역할이 블랙박스로 수행된다는 사실을 짐작할 수 있습니다. 아무튼 무지성으로 바이브만 타는 방식으로는 에이전트를 이용하는데 분명 한계가 있음을 확인하는 장면입니다. 그래서 앞으로 나아가기 전에 잠시 멈추고 현재 상황을 인식하기로 합니다. 그래서, 클로드 코드에 이렇게 물은 후에 그렇다면 오름 관리자 앱(해당 url)과 오름앱(해당 url)에서 python이 쓰이고 있나요? 대답으로 받은 내용을 다시 클로드에 던져서 오름 앱 구성을 파악해 달라고 했더니 다음과 같이 풀어줍니다. 구성도를 그리는 일도 클로드에 위임해 봅니다. URL을 허위 사실이 들어가 있는데, 약간의 오류는 이해하고 넘어가기로 합니다. DBMS도 허위 사실을 생성하여 그린 것인데, LLM을 챗봇으로 쓸 때 종종 나타나는 현상이란 점을 알고 있었습니다.(역시나 무지성 바이브의 한계를 또 확인합니다.) 그래서, 클로드 코드에게 사실 확인을 다시 하고 난 후에 클로드가 상상한 그림의 사실 여부와 빠진 부분을 확인합니다. 클로드에게 정답을 기대했다면 실망하겠지만, 클로드의 파악을 바탕으로 클로드 코드에 지시할 사항을 배울 수 있기 때문에 클로드는 여전히 쓸만한 동료입니다. 자, 이제 잘 차려서 앞으로 나아가 보기로 합니다. 분명히 인공지능 코딩 에이전트의 기술을 놀랍도록 발전한 것은 맞지만, 바이브로 순식간에 만들어진 것에 취해서 운을 바라는 식으로 계속해서 서비스와 시스템을 유지하기는 힘들다는 상식을 확인합니다. 앞서 잠시 언급한 라는 논문이 있습니다. 작년에 썼던 글 중에 가 있는데, 논문 수준에서 보인 기술이 클로드 코드 안에서 작동한다고 느낍니다. 논문에서도 기술 변화 추이를 도식화한 그림이 등장합니다. [1] 더불어 아내를 위한 오름 깨기 앱 개발은 거의 끝난 상태라 는 여기 흡수합니다. 11. 애플리케이션 구성 변경도 수행해 주는 클로드 코드