seukseok의 개인 블로그

GPT-5.5로 코딩하면 뭐가 좋아졌나

· tech

GPT-5.5가 나왔다고 해서 모든 코딩 작업이 갑자기 자동으로 끝나는 건 아니다. 그래도 코딩에 쓰는 입장에서는 꽤 분명한 변화가 있다.

내가 보기엔 핵심은 이거다.

GPT-5.5는 코드를 더 잘 짜는 모델이라기보다, 개발 작업을 더 오래 붙잡고 끝까지 밀어붙이는 모델에 가깝다.

단순히 “이 함수 고쳐줘”보다,

이런 흐름에서 차이가 커진다.

결론 먼저

사용자 입장에서 GPT-5.5의 코딩 체감은 네 가지로 정리할 수 있다.

체감 포인트실제 의미
덜 끊긴다긴 작업을 중간에 포기하지 않고 더 오래 끌고 간다
맥락을 더 잘 잡는다코드 한 조각보다 repo 전체 흐름을 보려 한다
도구 사용이 더 안정적이다검색, 파일 수정, 테스트, 검증을 더 자연스럽게 이어간다
프롬프트 방식이 달라진다세세한 절차보다 목표와 완료 기준을 주는 게 더 잘 맞는다

그래서 GPT-5.5는 짧은 코드 자동완성보다 작업 위임형 코딩에서 더 의미가 크다.

공식 자료에서 말하는 변화

OpenAI는 GPT-5.5를 “real work”를 위한 모델로 설명한다. 특히 코딩 쪽에서는 구현, 리팩터링, 디버깅, 테스트, 검증 같은 실제 엔지니어링 작업을 더 잘 수행한다고 말한다.

OpenAI Developers Models 문서 화면
OpenAI Developers Models 페이지. 모델별 특징과 선택 기준은 계속 바뀔 수 있으므로 공식 문서를 기준으로 확인하는 편이 안전하다.

숫자로 보면 OpenAI 공식 발표 기준으로 GPT-5.5는 GPT-5.4보다 여러 코딩/에이전트 벤치마크에서 앞선다.

예를 들어 발표 자료에서는:

다만 이런 숫자는 “내 프로젝트에서 무조건 10% 더 빨라진다”는 뜻은 아니다. 사용자가 실제로 체감하는 지점은 벤치마크 점수보다 작업 흐름에 더 가깝다.

1. 제일 큰 변화: 덜 babysitting 해도 된다

이전 모델을 코딩에 쓸 때 답답한 순간이 있었다.

GPT-5.5의 방향은 이 문제를 줄이는 쪽이다.

OpenAI의 GPT-5.5 가이드는 이 모델이 복잡한 코딩 작업, 도구 사용, 코드베이스 탐색, 검증, 다단계 실행에 더 잘 맞는다고 설명한다. 실제 사용자 입장에서는 “한 번 시키고 더 오래 기다릴 만한 작업”이 늘어난다는 뜻이다.

예를 들면 이런 요청이 더 잘 맞는다.

이 기능을 추가해줘.
단, 기존 UI 패턴을 먼저 확인하고,
관련 테스트가 있으면 같이 수정하고,
빌드가 깨지면 원인을 찾아서 고친 뒤,
마지막에 변경 파일과 검증 결과만 요약해줘.

이건 예전처럼 “1번 파일 열어, 2번 함수 고쳐, 3번 테스트 실행해” 식으로 모든 절차를 세세하게 지시하는 방식과 다르다.

GPT-5.5는 절차보다 결과와 완료 기준을 줬을 때 더 잘 움직이는 쪽에 가깝다.

2. 코드 한 조각보다 시스템 모양을 더 보려 한다

GPT-5.5의 장점은 단일 함수 생성보다 시스템 이해에서 더 크게 느껴진다.

예를 들어 이런 작업이다.

이런 작업은 단순히 코드를 잘 쓰는 것보다, “어디를 봐야 하는지”가 중요하다.

GPT-5.5는 공식 설명에서도 큰 시스템의 맥락 유지, 모호한 실패 원인 추론, 도구로 가정 확인, 주변 코드베이스까지 변경을 이어가는 능력을 강조한다.

사용자 입장에서는 이렇게 체감된다.

“코드를 하나 써주는 AI”보다 “repo를 보고 작업을 이어가는 동료”에 조금 더 가까워졌다.

물론 완벽하다는 뜻은 아니다. 그래도 복잡한 repo에서는 이 차이가 꽤 크다.

3. 테스트와 검증을 더 자연스럽게 묶을 수 있다

코딩에서 AI가 진짜 쓸모 있으려면 코드를 쓰는 것보다 검증까지 가는 것이 중요하다.

OpenAI Codex 문서도 Codex CLI가 로컬 터미널에서 repo를 읽고, 파일을 수정하고, 명령을 실행할 수 있다고 설명한다. 즉 GPT-5.5의 장점은 모델 단독보다 Codex 같은 도구 실행 환경과 붙었을 때 더 커진다.

OpenAI Codex CLI 공식 문서 화면
OpenAI Developers의 Codex CLI 문서. GPT-5.5의 코딩 체감은 모델 자체보다 도구 실행 환경과 함께 볼 때 더 잘 드러난다.

실제로 코딩 작업을 맡길 때는 이런 식이 좋다.

수정만 하지 말고 아래 순서로 끝내줘.

1. 관련 파일을 먼저 찾아라.
2. 기존 패턴을 요약해라.
3. 최소 변경으로 구현해라.
4. 가능한 테스트/빌드를 실행해라.
5. 실패하면 원인을 보고 한 번 더 고쳐라.
6. 마지막에는 변경 범위와 검증 결과만 짧게 말해라.

GPT-5.5가 좋아졌다고 해도, 검증 기준이 없으면 여전히 그럴듯한 답을 만들 수 있다. 그래서 “좋은 모델”보다 중요한 건 좋은 완료 조건이다.

4. 프롬프트는 더 짧게, 기준은 더 분명하게

GPT-5.5 API 가이드는 이 모델을 이전 프롬프트의 단순 교체판으로 보지 말고 새 기준으로 조정하라고 말한다.

특히 중요한 포인트는 이거다.

OpenAI Developers GPT-5.5 사용 가이드 화면
OpenAI Developers의 GPT-5.5 사용 가이드. GPT-5.5는 결과 중심 프롬프트와 명확한 성공 기준을 더 잘 활용하는 쪽으로 안내된다.

나쁜 요청은 이런 식이다.

이거 고쳐줘.

조금 나은 요청은 이렇다.

이 버그를 고쳐줘.
원인은 추측하지 말고 로그와 관련 코드를 확인해줘.
동작을 바꾸는 수정은 최소화하고,
테스트를 실행할 수 있으면 실행한 뒤 결과를 알려줘.

더 좋은 요청은 이렇게 간다.

목표: 로그인 후 대시보드로 이동하지 않는 문제를 고친다.
성공 기준:
- 기존 로그인 성공 케이스는 유지한다.
- 실패 케이스의 에러 메시지는 바꾸지 않는다.
- 수정 후 관련 테스트 또는 최소 빌드를 실행한다.
허용 범위:
- 라우팅/상태 관리 관련 파일 수정 가능
- UI 문구 변경은 하지 말 것
출력:
- 원인
- 수정 파일
- 검증 결과

GPT-5.5는 이런 식의 요청에 더 잘 맞는다. 세부 절차보다 작업 계약을 주는 느낌이다.

5. 언제 돈값을 하나

GPT-5.5가 돈값을 하는 작업은 분명하다.

돈값 하는 경우

이런 작업에서는 모델이 한 번에 더 멀리 가는 게 중요하다.

돈값이 애매한 경우

이런 건 GPT-5.5까지 필요 없을 수 있다. 더 싼 모델이나 에디터 자동완성으로 충분할 때가 많다.

즉 GPT-5.5는 짧은 질문용 모델이라기보다 작업 위임용 모델로 쓰는 편이 맞다.

6. 사용자가 조심해야 할 점

모델이 좋아졌다고 해서 검토가 필요 없어지는 건 아니다.

오히려 GPT-5.5처럼 더 오래 작업을 이어가는 모델일수록, 잘못된 방향으로 오래 달릴 수도 있다.

그래서 아래 기준은 꼭 필요하다.

특히 실제 프로젝트에서는 이런 문장을 자주 쓰는 게 좋다.

성공했다고 말하기 전에 실행한 검증 명령과 결과를 같이 적어줘.
검증을 못 했다면 못 한 이유를 적어줘.

AI 코딩에서 제일 위험한 건 실패가 아니다. 검증하지 않았는데 성공처럼 보이는 것이다.

7. 내 작업 흐름에서는 이렇게 쓸 것 같다

내 기준으로 GPT-5.5를 쓴다면 이렇게 나눌 것 같다.

작은 수정

굳이 GPT-5.5만 고집하지 않는다. 빠른 모델이나 Cursor 자동완성으로 충분하다.

중간 규모 작업

GPT-5.5에게 맡긴다.

예:

큰 작업

GPT-5.5를 바로 실행자로 쓰기보다, 먼저 계획을 만들게 한다.

바로 수정하지 말고,
영향 범위와 변경 계획, 검증 방법을 먼저 제안해줘.

그 다음 계획이 괜찮으면 작업을 맡긴다.

배포 전

GPT-5.5 하나만 믿지 않고, QA와 gate를 분리한다.

모델이 좋아질수록 오히려 이런 분업이 중요하다. 한 에이전트가 만든 결과를 다른 에이전트가 의심하게 만들어야 한다.

한 줄 결론

GPT-5.5로 코딩할 때 좋아진 건 “코드를 더 예쁘게 쓰는 능력”보다 “작업을 이해하고, 도구를 쓰고, 검증까지 오래 끌고 가는 능력”이다.

그래서 사용자는 GPT-5.5에게 짧은 질문만 던지기보다,

을 같이 주는 편이 좋다.

그렇게 쓰면 GPT-5.5는 단순 코드 생성기보다 작업을 맡길 수 있는 개발 보조자에 가까워진다.

참고 자료