ChatGPT Sol·Luna, 일주일 실무에 넣어보니 체감 차이는 이랬다

ChatGPT 모델 선택기에 Sol과 Luna로 표기된 옵션이 보이기 시작하면서, 둘 중 무엇을 기본으로 둘지 고민이 생겼습니다. 그래서 일주일 동안 실제 업무에 두 라인을 번갈아 넣어 보고, 어떤 일에서 어느 쪽이 “이 정도면 충분하다”고 느껴졌는지 기록했습니다.

먼저 선을 그어 두겠습니다. 이 글은 Sol / Luna 라인으로 표기된 모델 옵션을 일주일간 업무에 번갈아 써 본 개인 후기입니다. 점수나 벤치마크는 없고, 응답 대기 체감·수정 왕복 횟수·결과물을 그대로 쓸 수 있었는지 같은 정성적인 인상만 다룹니다. 계정·플랜·시점에 따라 선택기에 보이는 옵션과 한도는 달라질 수 있으니, 본인 계정 화면을 기준으로 읽어 주시면 됩니다.

일주일을 어떻게 나눠 썼나?

한 줄 답: 같은 종류의 업무를 두 라인에 나눠 던지고, “몇 번 고쳐야 쓸 만해졌는가”를 기준으로 비교했습니다.

평소 ChatGPT에 맡기는 일은 크게 네 가지였습니다.

코드 리뷰·디버깅 보조 — C++·리눅스 쪽 에러 로그를 붙여 넣고 원인 후보를 좁히는 작업
설계 메모 정리 — 흩어진 회의 메모를 근거와 결정 사항으로 재구성하는 작업
일상 초안 — 사내 메신저 답장, 이슈 설명, 커밋 메시지, 짧은 공지
블로그 글 뼈대 — 목차 잡기, 한·영 문장 다듬기

첫 이틀은 모든 일을 Sol로, 다음 이틀은 모든 일을 Luna로 처리했습니다. 나머지 사흘은 일의 성격에 따라 제가 직접 골라 가며 썼습니다. 비교 기준은 단순했습니다. 답이 나오기까지 기다리는 체감, 원하는 결과가 나올 때까지 다시 요청한 횟수, 그리고 결과물을 손대지 않고 쓸 수 있었는지였습니다.

Sol이 확실히 나았던 순간은?

한 줄 답: 조건이 여러 겹 얽혀 있고 한 번 틀리면 되돌리기 비싼 일에서는 Sol이 수정 왕복을 눈에 띄게 줄여 줬습니다.

가장 차이가 컸던 건 디버깅 보조였습니다. 빌드 로그와 링커 에러, 관련 CMake 조각을 함께 붙여 넣었을 때 Sol은 원인 후보를 나열하는 데서 그치지 않고, “이 증상이면 이 후보는 제외된다”는 식으로 스스로 가지를 쳐 나갔습니다. Luna로 같은 질문을 하면 그럴듯한 후보 목록은 금방 나왔지만, 제가 추가 정보를 몇 번 더 넣어 줘야 비슷한 결론에 도달했습니다.

설계 메모 정리에서도 Sol 쪽이 편했습니다. 서로 모순되는 회의 메모를 넣었더니 Sol은 모순 지점을 먼저 짚고 “어느 쪽을 결정으로 볼지 확인이 필요하다”고 되물었습니다. 결과적으로 정리본을 다시 뜯어고친 횟수가 적었습니다.

대신 기다리는 체감은 분명히 있었습니다. 짧은 질문에도 한 박자 생각하고 답하는 느낌이라, 메신저 답장처럼 가벼운 일을 Sol에 맡긴 이틀 동안은 오히려 답답했습니다. “무거운 일에는 기다릴 가치가 있고, 가벼운 일에는 과하다”는 게 Sol에 대한 첫인상이었습니다.

Luna가 오히려 나았던 순간은?

한 줄 답: 짧고 반복적인 초안 작업은 Luna가 더 빨리 “충분한” 결과를 줬고, 흐름이 끊기지 않는다는 점이 컸습니다.

일상 초안에서는 Luna가 확실히 손에 맞았습니다. 커밋 메시지, 이슈 설명, 짧은 공지처럼 형식이 정해져 있고 틀려도 바로 고칠 수 있는 일은 응답이 빨리 오는 쪽이 생산성이 높았습니다. 한 번에 완벽하지 않아도 “조금 더 짧게”, “톤을 더 담백하게” 같은 수정을 가볍게 여러 번 주고받는 흐름이 자연스러웠습니다.

블로그 글 뼈대도 비슷했습니다. 목차 후보를 여러 개 받아 보고 고르는 작업은 속도가 곧 품질이었습니다. Sol로 같은 요청을 하면 목차 하나하나가 더 논리적이긴 했지만, 어차피 제가 다시 고칠 뼈대라서 그 차이가 크게 와닿지 않았습니다.

사흘간 직접 골라 쓰면서 보니, 제 경우 하루 요청의 대부분은 Luna로 충분했습니다. Sol을 켠 건 막힌 문제를 풀어야 할 때나, 결과물이 그대로 문서로 남는 경우 정도였습니다.

아쉬웠던 점은?

한 줄 답: 두 라인의 경계가 생각보다 흐릿해서, “어느 쪽을 써야 하나”를 고르는 판단 자체가 일이 되는 순간이 있었습니다.

첫째, 선택 비용이 있었습니다. 질문을 던지기 전에 “이게 Sol감인가 Luna감인가”를 고민하는 시간이 은근히 쌓였습니다. 중간 난이도의 일, 예를 들어 짧은 스크립트 수정은 어느 쪽으로 해도 결과가 비슷해서 고민한 게 아깝게 느껴졌습니다.

둘째, Luna의 자신감입니다. 가벼운 작업에서는 장점이지만, 사실관계가 걸린 질문에서도 매끄럽게 단정하는 답을 줄 때가 있었습니다. 문장만 보면 그럴듯해서 오히려 검증을 놓치기 쉬웠습니다. 사실 확인이 필요한 내용은 라인과 관계없이 공식 문서로 다시 확인하는 습관이 필요했습니다.

셋째, Sol도 만능은 아니었습니다. 답이 길고 신중해지는 만큼, 제가 원한 건 한 줄 결론인데 긴 분석이 돌아오는 경우가 있었습니다. “결론부터 세 줄로”처럼 형식을 먼저 지정해야 체감이 좋아졌습니다.

마지막으로, 사용 한도나 제공 범위는 계정과 시점에 따라 달라질 수 있어서 “Sol을 기본으로 켜 두고 계속 쓴다”는 전략이 늘 가능한 건 아니었습니다. 이 부분은 본인 계정의 모델 선택기와 공식 안내를 기준으로 판단하는 게 맞습니다.

누가 굳이 신경 써서 나눠 쓸 만한가?

한 줄 답: 막히는 문제를 자주 푸는 사람은 Sol을 따로 챙길 가치가 있고, 짧은 초안이 대부분이라면 Luna 기본으로도 충분합니다.

일주일을 써 보고 정리한 제 기준은 이렇습니다.

Sol을 챙겨 쓸 만한 경우: 디버깅·설계 검토처럼 조건이 여러 겹이고, 틀린 답을 따라갔을 때 되돌리는 비용이 큰 일이 자주 있는 분
Luna 기본으로 충분한 경우: 메신저 답장, 요약, 커밋 메시지, 짧은 문서 초안처럼 빠르게 주고받으며 다듬는 일이 대부분인 분
굳이 고민하지 않아도 되는 경우: 하루에 몇 번 가볍게 물어보는 정도라면, 선택 고민에 드는 시간이 차이보다 클 수 있습니다

제 결론은 “기본은 Luna, 막히면 Sol”입니다. 처음부터 Sol로 시작하기보다 Luna로 빠르게 돌려 보고, 두세 번 왕복해도 답이 안 좁혀질 때 Sol로 넘기는 흐름이 가장 덜 피곤했습니다.

도구 구독이 부담되면 할인 경로만 보시면 됩니다.