콘텐츠로 이동

코드 한 줄 없이 에이전트만으로 배포 코드 리팩토링해 보기

Cursor 활용 능력과 프롬프팅 능력을 키우기 위해 PopupWebview.cs(약 590줄) 리팩토링을 과제로 잡았다. 의도적으로 코드를 한 줄도 직접 작성하지 않고, 에이전트와의 상호작용만으로 진행했다.

처음에는 분석만 요청했다.

PopupWebView.cs를 리팩토링했으면 해 먼저 해당 스크립트를 분석해줘

이어서 안전성 요구사항을 명시했다.

해당 로직은 이미 배포된 서비스 코드이기 때문에 최대한 보수적으로 리팩토링했으면 해,
단계적으로 영향이 적은 로직부터 수정했으면 해, low risky한 문제부터 제시해줘

접근 원칙은 세 가지였다.

  • 보수적 리팩토링: 기존 동작을 보존한다.
  • 단계적 접근: Low Risk → Medium Risk → High Impact 순서로 진행한다.
  • 리스크 최소화: 각 단계를 독립적으로 적용할 수 있게 한다.

이후에는 “다음 단계로 넘어가자” 정도의 짧은 요청으로 4단계까지 진행했다. 각 단계의 변경은 git merge conflict를 해결하듯 하나씩 비교하며 수락했다.

에이전트가 정리한 단계별 작업은 다음과 같다.

단계 작업
1. Low Risk 매직 넘버를 상수로 추출(FRAME_MARGIN_X, DEFAULT_TIMEOUT 등), 주석 처리된 코드 정리, 중복 코드를 SetupWebViewFrame으로 통합, null 체크 개선
2. Medium Risk 콜백 관리 로직 분리(IsFullscreen(), SafeRaiseCallback()), 웹뷰 이벤트 핸들러 정리(HandleWebViewLoadComplete()), 오리엔테이션 관리 로직 분리, 에러 처리 개선
3. High Impact WebViewConfiguration 클래스 도입, 통합 Initialize 메서드 추가, WebViewState 상태 관리 도입, 기존 메서드를 Configuration 기반으로 변경
4. 최종 최적화 불필요한 계산 제거, 이벤트 핸들러 정리, 로깅 개선, 주석 처리된 코드 완전 제거

3단계에서 도입한 구조는 다음과 같다.

[System.Serializable]
public class WebViewConfiguration
{
public string url;
public int xPosition;
public int yPosition;
public int width;
public int height;
public System.Action<string> clickCallback;
public bool loadShowScreen = false;
public Orientation orientation = Orientation.Landscape;
public WebviewStyle webviewStyle = WebviewStyle.CenterWithFrame;
}
public enum WebViewState
{
Idle,
Loading,
Loaded,
Error,
Closed
}
public void Initialize(WebViewConfiguration config)
{
if (webView == null || string.IsNullOrEmpty(config.url))
return;
// 설정 적용
loadShowScreen = config.loadShowScreen;
orientation = config.orientation;
webviewStyle = config.webviewStyle;
// 프레임 설정
if (config.width > 0 && config.height > 0)
{
SetupWebViewFrame(config.xPosition, config.yPosition, config.width, config.height);
}
// 웹뷰 초기화
InitializeWebView(config.url, config.clickCallback);
}
private void ChangeState(WebViewState newState)
{
if (currentState != newState)
{
Debug.Log($"[PopupWebview] State Changed: {currentState} -> {newState}");
currentState = newState;
}
}

변경을 하나씩 리뷰하며 수락했는데도 결과물에서 컴파일 에러가 발생했다.

컴파일 에러 내용을 자세히 설명하며 수정을 요청해도 에이전트가 일부만 고치고 나머지는 처리하지 못했다.

  • “배포된 코드이니 보수적으로, 저위험부터”처럼 제약을 명시하면 에이전트가 단계를 나눠 제안하고, 사람은 단계마다 검토할 수 있다.
  • 에이전트의 완료 보고서는 “리스크 매우 낮음”, “기존 API 완전 호환”처럼 낙관적으로 쓰였지만 결과물은 컴파일되지 않았다. diff를 하나씩 리뷰했는데도 컴파일 에러를 놓쳤으므로 보고서가 아니라 빌드 결과로 검증해야 한다.
  • 에러를 자세히 설명해 주어도 에이전트는 일부만 고쳤다.