코드에서 사고로 — AI 시대, 개발자의 역할 재정의

코드를 짜는 시간이 줄었다

AI에게 구현을 맡기니 남는 시간이 생겼습니다. 그 시간을 처음엔 뭘 해야 할지 몰랐습니다.

이슈 사이클을 몇 바퀴 돌리고 나서야 패턴이 보였습니다. 구현 코드를 작성하던 시간이 줄어든 자리에, 설계를 검토하고 결과물에 반론을 세우고 기술 선택을 판단하는 일이 채워졌습니다.

“이 기능을 어떻게 구현할까”보다 “왜 이렇게 만들어야 할까”를 먼저 고민하게 된 것입니다. 그 변화가 의외로 큰 차이를 만들었습니다.

사상이 설계를 만든다

이슈 사이클 초기에는 AI에게 “로그인 기능 만들어줘”라고 지시했습니다. 코드는 나왔지만 에러 처리 방식이 매번 달랐습니다. “왜 이렇게 처리해야 하는가”를 먼저 정하지 않았기 때문이었습니다.

이 경험에서 세 겹의 판단이 필요하다는 걸 깨달았습니다.

Philosophy (사상)
    ↓ 정보화
Strategy (전략)
    ↓ 구체화
Tactics (전술)

Philosophy — “우리는 왜 이렇게 하는가”. 변하지 않는 원칙, 팀의 가치관. 예: “배우고 실험하면서도 신뢰성을 잃지 않는다”

Strategy — “어떤 방향으로 갈 것인가”. 프로젝트별, 분기별 중점 방향. 예: “이 분기는 마이크로서비스 도입보다 안정화에 집중한다”

Tactics — “구체적으로 어떻게 구현하는가”. 매일의 기술 선택, 프로그래밍 패턴. 예: “에러는 항상 명시적으로 처리한다”

대부분의 팀이 Tactics만 논의합니다. “변수 이름은 어떻게 짓지?”, “이 함수는 어디에 둘까?” Philosophy는 암묵적으로 방치되거나, 팀원마다 다릅니다.

AI 시대에는 이것이 문제가 됩니다.

AI에게 “왜”를 설명할 수 없으면, 잘못된 코드를 받아들이게 됩니다. 왜 틀렸는지 모르는 채로.

비판적 사고가 품질을 만든다

AI가 생성한 설계를 처음엔 그대로 썼습니다. 나중에 보니 과장되거나 불필요하게 복잡한 부분이 있었습니다.

그래서 AI가 내놓은 결과물에 “이게 정말 필요한가?”, “더 단순한 방법은 없는가?”를 먼저 묻기 시작했습니다.

비판을 먼저 세우면 AI와의 대화가 달라집니다. “틀렸다”는 거부 대신 “이렇게 개선하자”는 제안이 됩니다. 그 방향으로 다시 지시하면, 결과물이 한 단계 올라갑니다.

단순 지시로는 과장되거나 동작하지 않는 결과가 나옵니다. AI는 “왜”를 모르기 때문에 그럴듯한 결과를 만들어냅니다. “왜”를 아는 쪽이 판단해야 품질이 생깁니다.

트레이드오프는 경험에서 나온다

마감이 촉박한데 신기술도 도입해야 하는 상황이 생깁니다. 이럴 때 Go/No-Go 기준이 없으면 결정이 흔들립니다.

실제 경험을 예로 들면, 처음엔 k8s job으로 배치 작업을 관리했습니다. 속도 문제로 JobRunr로 마이그레이션했고, 규모가 커지니 결국 Airflow + k8s job 조합으로 돌아왔습니다.

각 단계의 선택이 틀렸던 게 아닙니다. 그때 그 조건에선 최선이었습니다. 하지만 “언제까지 이 도구가 맞을까”를 미리 가정해두지 않았다면 더 늦게 깨달았을 겁니다.

AI는 “이 기술이 좋습니다”라고 추천합니다. 하지만 “언제까지 이 기술이 맞을까”는 답하지 못합니다. 그 판단은 직접 겪어봐야 생깁니다.

많이 알아야 인사이트가 생기고, AI에게 올바르게 지시할 수 있습니다. 트레이드오프 판단은 기술력이 아니라 경험과 원칙에서 나옵니다.

코드를 덜 짜고, 더 많이 판단한다

코드를 짜는 시간이 줄어든 대신, 판단하는 시간이 늘었습니다.

사상이 없으면 설계가 흔들립니다. 비판이 없으면 과장된 결과를 그대로 씁니다. 경험이 없으면 트레이드오프를 놓칩니다.

이 사고방식이 실제로 작동하는지는 다음 글에서 확인할 수 있습니다. 방법론을 들고 실전 도구를 만든 경험 — 다음 글에서 이어집니다.

---

이 글은 Claude의 도움을 받아 작성했습니다.