OpenAI의 Harness Engineering 학습 정리와 적용 계획

지난 글인 AI 시대의 주니어 백엔드 개발자는 무엇을 붙잡고 무엇을 내려놓아야 할까를 쓰고 나서도 한 가지 질문이 남아 있었습니다.

AI 시대에 주니어 백엔드 개발자가 붙잡아야 할 것이 기본기, 문제 정의, 검증, 문서화, 회고라는 데까지는 어느 정도 생각이 정리됐습니다. 그런데 그 다음이 어려웠습니다. 그 역량을 실제로 어디서, 어떤 방식으로 훈련해야 하는지는 여전히 흐릿했기 때문입니다.

단순히 AI를 더 자주 써보는 것만으로는 부족하다고 느꼈습니다. 프롬프트를 잘 쓰는 감각은 분명 중요하지만, 그것만으로는 제가 지난 글에서 끝까지 붙잡고 싶다고 했던 책임, 검증, 도메인 이해를 훈련하기 어렵습니다.

그래서 최근에는 질문이 조금 더 구체적으로 바뀌었습니다.

AI 시대의 주니어 백엔드 개발자에게 필요한 다음 실전 경험은 무엇일까?

이 질문을 붙잡고 있다가 OpenAI의 Harness engineering: leveraging Codex in an agent-first world를 읽었습니다. 그리고 저는 이 글을 통해, 제가 막연히 “AI를 잘 쓰는 능력”이라고 불렀던 것의 더 정확한 이름이 어쩌면 Harness Engineering 경험일 수 있겠다는 생각을 하게 됐습니다.

OpenAI가 말한 Harness Engineering이 무엇인지, 어떤 기술적 구조와 안정화 원리로 작동하는지 다시 정리해보고, 마지막에는 제 git-ranker-workflow에 어떻게 처음부터 점진적으로 적용해나갈 것인지를 계획 형태로 정리해보려 합니다.

지난 글 다음에 남은 질문

지난 글에서 저는 AI 시대의 개발자를 “무엇을 AI에게 맡기고 무엇을 끝까지 책임질 것인가“를 설계하는 사람으로 보고 싶다고 작성했습니다.

그때 제가 붙잡고 싶었던 것은 분명했습니다.

• 문제를 정의하는 일
• 맥락과 제약을 설명하는 일
• 결과를 검증하는 일
• 도메인 규칙을 이해하고 문서화하는 일
• 최종적으로 책임지는 일

그런데 이 다섯 가지는 머리로 동의하는 것과 실제 프로젝트에서 반복 가능한 형태로 훈련하는 것이 전혀 다른 문제였습니다.

AI는 계속 더 많은 코드를 대신 써주고 있습니다. 그렇다면 남는 일은 단순히 “더 어려운 코드”를 쓰는 일이 아니라, AI가 만든 결과물을 신뢰할 수 있는 방식으로 생산하고 검증하는 시스템을 만드는 일일지도 모릅니다.

바로 이 지점에서 저는 Harness Engineering이라는 말을 조금 다르게 받아들이게 됐습니다.

저에게 Harness Engineering은 단순히 “AI에게 일을 잘 시키는 기법”이 아니었습니다.
오히려 AI가 읽을 수 있는 맥락을 저장하고 AI가 직접 검증할 수 있는 실행 환경을 만들어 실패했을 때 다시 수정 루프로 들어갈 수 있는 시스템을 설계하는 일에 더 가까워 보였습니다.

OpenAI Harness Engineering 정리

OpenAI의 글에서 가장 먼저 인상적이었던 것은, 그들이 단순히 “Codex를 많이 썼다”는 이야기를 하는 것이 아니라는 점이었습니다. 그들은 빈 Git 리포지터리에서 시작해 사람은 거의 프롬프트를 통해 일하고 에이전트가 코드 작성뿐 아니라 테스트, 문서, CI 설정, 리뷰 응답, 심지어 저장소 관리용 스크립트까지 생성하는 환경을 만들었다고 설명합니다.

하지만 이 글의 핵심은 “사람이 코드를 직접 쓰지 않았다”는 내용보다 더 중요한 건, 그렇게 일할 수 있도록 무엇을 리포지터리와 실행 환경에 미리 심어두었는가였습니다.

OpenAI가 보여준 흐름을 제가 이해한 방식대로 정리하면 대략 이렇습니다.

Harness의 개념

소프트웨어 엔지니어링에서 test harness라는 말은 원래 테스트 대상 시스템을 둘러싸고 입력을 주고, 실행하고, 결과를 관찰하고, 검증하는 보조 구조를 뜻합니다. 제가 이해한 OpenAI의 Harness Engineering은 이 개념을 개발 라이프사이클 전체로 확장한 형태에 가까웠습니다.

즉, 모델 자체가 하네스가 아닙니다.
하네스는 모델 바깥에서 아래를 통제하는 구조입니다.

• 어떤 맥락을 읽을 수 있는가
• 어떤 도구를 사용할 수 있는가
• 어떤 환경에서 실행되는가
• 무엇을 성공으로 판단하는가
• 실패했을 때 어디로 되돌아가는가

이 관점에서 보면 Harness Engineering은 “강력한 모델을 쓰는 일”보다 모델이 안정적으로 일할 수 있는 제어 시스템을 만드는 일에 더 가깝습니다.

네 개의 기술 레이어

OpenAI의 글을 읽으며 저는 하네스가 대략 네 개의 기술 레이어로 구성된다고 느꼈습니다.

1. Knowledge Layer: 지식 저장소

OpenAI는 에이전트가 실행 중에 접근할 수 없는 정보는 사실상 존재하지 않는 것처럼 취급했습니다. 그래서 AGENTS.md는 짧은 진입점만 두고 실제 규칙과 맥락은 문서 트리, 스키마, 실행 계획, 설계 기록 안에 분산하지 않고 구조화해 넣습니다.

여기서 중요한 기술적 포인트는 두 가지입니다.

1. 문서가 검색 가능하고 버전 관리되어야 합니다. 그래야 에이전트가 현재 코드와 같은 시간축 위에서 읽을 수 있습니다.
2. 계획이 일급 아티팩트여야 합니다. OpenAI는 복잡한 작업을 실행 계획에 넣고 진행 상황, 발견한 사실, 의사결정, 남은 부채까지 같은 저장소 안에서 관리했습니다.

이 레이어의 역할은 간단합니다. 암묵지를 검색 가능한 명시지로 바꾸는 것입니다.

2. Execution Layer: 격리된 실행 공간

OpenAI는 작업마다 분리된 git worktree에서 앱을 띄우고 작업별 로컬 관측 가능성 스택을 붙였습니다.

작업 공간이 분리되면,

• 서로 다른 작업이 같은 실행 환경을 오염시키지 않고
• 특정 변경과 특정 실행 결과를 같은 컨텍스트에서 묶어볼 수 있고
• 실패를 재현하거나 되돌리는 비용이 낮아집니다

이건 백엔드 개발자가 테스트 환경과 운영 환경의 차이를 줄이려는 태도와도 닮아 있습니다. 결국 중요한 것은 “돌아간다”가 아니라 어떤 조건에서 어떻게 돌아갔는지 다시 설명할 수 있는가이기 때문입니다.

3. Validation Layer: 동작 검증

에이전트는 코드를 읽는 데서 멈추지 않고 앱을 직접 실행하고, 브라우저 상태를 확인하고, 로그와 메트릭을 조회하며 결과를 확인합니다.

여기에는 몇 가지 기술적 의미가 있습니다.

• 정적 코드 검토만으로는 실제 동작을 보장할 수 없다는 전제
• UI, 네트워크, 로그, 메트릭을 서로 교차 검증해야 한다는 전제
• “테스트 통과”와 “사용자에게 맞는 동작”을 분리해서 본다는 전제

OpenAI가 Chrome DevTools Protocol, 로컬 로그/메트릭 스택, 구조화된 QA 루프를 붙인 이유도 여기에 있다고 봤습니다. 에이전트가 실제 시스템을 직접 읽지 못하면, 결국 성공 판단을 사람의 추론에 다시 많이 의존하게 되기 때문입니다.

4. Governance Layer: 규칙과 가드레일

OpenAI는 맞춤형 린터, 구조적 테스트, 명명 규칙, 파일 크기 제한, 구조화된 로깅 규칙 같은 제약을 기계적으로 적용했다고 설명합니다. 그리고 문서가 부족하면 규칙을 코드로 승격합니다.

또한 OpenAI는 에이전트가 추측한 데이터 형태를 바탕으로 “YOLO-style”로 구현하지 않도록, 경계 검증이나 타입이 지정된 SDK 같은 안전한 경로를 더 선호한다고 설명합니다. 이건 단순한 코드 스타일 문제가 아니라, 모델이 그럴듯한 추측으로 시스템 경계를 침범하지 못하게 막는 안정성 설계에 가깝습니다.

이 레이어에서 특히 인상적이었던 부분은 린트가 단순히 실패만 알리는 것이 아니라 에이전트 컨텍스트에 수정 지침까지 주입하는 방향으로 설계되었다는 점이었습니다. 즉, 규칙은 단순한 차단 장치가 아니라 다음 수정 행동을 더 정확하게 유도하는 인터페이스가 됩니다.

또 하나 중요한 것은 제약과 자율성의 경계를 분리했다는 점입니다. OpenAI는 중앙에서 경계, 정확성, 재현성이 중요한 부분을 고정하고, 그 안에서는 에이전트가 표현 방식을 자율적으로 선택하게 했습니다. 이건 플랫폼 조직이 공통 정책을 두되 각 팀의 자율성을 남겨두는 방식과도 닮아 있습니다.

안정적 플로우의 구성 원리

여기서 말하는 안정성은 “항상 버그가 없다”는 뜻이 아니라, 문제가 생겨도 다시 같은 루프로 들어가 수정하고 검증할 수 있는 상태에 가깝습니다. 저는 OpenAI가 이 안정성을 아래 같은 구조로 확보했다고 이해했습니다.

1. 수용 기준

사람은 더 이상 모든 코드를 직접 치지 않지만, 여전히 루프 바깥으로 밀려난 것은 아닙니다. OpenAI 글에서 사람은 우선순위를 정하고, 사용자 피드백을 수용 기준으로 바꾸고, 결과를 검증하는 역할로 남아 있습니다.

에이전트가 강해질수록 오히려 처음 입력은 더 구조적이어야 합니다. 막연한 요청은 막연한 출력만 만들기 쉽기 때문입니다.

2. 표준 도구

OpenAI에서 에이전트는 gh, 로컬 스크립트, 저장소에 내장된 스킬 같은 표준 개발 도구를 직접 사용합니다. 사람이 CLI 명령을 복사해서 붙여넣어 주는 식이 아닙니다.

이 방식이 안정적인 이유는 사람과 에이전트 사이의 번역 레이어를 줄이기 때문입니다. 같은 도구, 같은 저장소, 같은 스크립트를 쓰면 “사람은 이렇게 이해했는데 에이전트는 다르게 이해했다”는 종류의 오해가 줄어듭니다.

3. 짧은 PR과 짧은 피드백 루프

OpenAI는 에이전트 처리량이 매우 큰 환경에서는 긴 수명의 대형 PR보다 짧은 수명의 작은 PR이 더 낫다고 설명합니다. 수정 비용은 싸고 기다리는 비용은 비싸기 때문입니다.

이건 일반적인 팀에 그대로 복제할 원칙은 아니지만, 하네스 관점에서는 꽤 중요한 논리라고 생각합니다. 검증 가능한 작은 단위로 쪼개야 루프를 더 자주 돌릴 수 있고, 루프를 자주 돌려야 자율성을 높일 수 있기 때문입니다.

4. 다중 신호 검증

OpenAI의 플로우는 대략 이런 순서로 정리됐습니다.

1. 현재 코드베이스와 상태를 검증한다
2. 버그를 재현한다
3. 실패 장면을 캡처한다
4. 수정한다
5. 애플리케이션을 직접 실행한다
6. 다시 검증하고 결과를 캡처한다
7. PR을 열고 피드백에 응답한다
8. 필요할 때만 사람에게 에스컬레이션한다

여기서 핵심은 “성공”을 하나의 신호로 판단하지 않는다는 점입니다. 테스트 통과, UI 상태, 네트워크 요청, 로그, 메트릭, 리뷰 피드백이 함께 맞물려야 비로소 완료에 가까워집니다.

장애도 보통 하나의 지표만 봐서는 원인을 모릅니다. 애플리케이션 로그, 메트릭, 요청 흐름, 사용자 증상을 함께 봐야 합니다. OpenAI는 이 운영 감각을 개발 루프 자체 안으로 넣은 것입니다.

5. 기계적 강제와 문서 운영

하네스가 계속 안정적으로 동작하려면 팀 안에서만 통하는 암묵적 룰에 덜 의존해야 합니다. OpenAI가 맞춤형 린터, 구조 테스트, 품질 문서, 실행 계획 검증, 문서 정리 에이전트까지 둔 것은 같은 이유라고 생각합니다.

특히 OpenAI는 제품 도메인과 아키텍처 레이어별 품질 등급을 문서화해 격차를 추적하고, 오래되거나 실제 코드 동작과 어긋난 문서를 자동으로 점검하는 doc-gardening 루프까지 둡니다. 즉, 문서도 정적인 설명서가 아니라 지속적으로 검증되고 정리되는 운영 대상이 됩니다.

한 번 말로 설명한 규칙은 다음 실행에서 사라질 수 있지만, 한 번 코드와 도구로 옮긴 규칙은 계속 재사용할 수 있습니다.
결국 안정성은 사람의 꼼꼼함보다 재실행 가능한 강제 장치에서 더 많이 나옵니다.

6. 드리프트 정리 루프

OpenAI 글에서 가장 현실적인 부분 중 하나가 바로 이 대목이었습니다. 에이전트는 기존 패턴을 빠르게 복제하기 때문에 잘못된 패턴도 빠르게 퍼뜨릴 수 있습니다. 그래서 좋은 하네스는 처음부터 “엔트로피는 반드시 생긴다”는 가정을 깔고 가야 합니다.

OpenAI는 이를 위해 황금 원칙을 저장소에 인코딩하고 품질 등급을 갱신하고, 편차를 검사하고, 작은 정리 PR을 계속 생성하는 백그라운드 루프를 운영했습니다.

에이전트-퍼스트 개발에서 유지보수는 부수 작업이 아니라, 처리량을 지탱하는 핵심 메커니즘에 가깝습니다.

주니어 백엔드 개발자와 Harness Engineering

이 글이 제게 크게 다가온 이유는 지난 글에서 제가 붙잡고 싶다고 했던 것들이 OpenAI의 실천 안에서 훨씬 더 구체적인 형태로 보였기 때문입니다.

제가 지난 글에서 중요하다고 말했던 기본기, 글쓰기, 검증, 도메인 이해는 Harness Engineering 안에서 아래처럼 다시 연결됩니다.

• 기본기는 에이전트가 만든 결과를 검토할 수 있는 판단력으로 연결됩니다.
• 글쓰기는 맥락과 규칙을 리포지터리에 인코딩하는 능력으로 연결됩니다.
• 검증은 테스트뿐 아니라 로그, 메트릭, 브라우저 상태를 읽는 운영 감각으로 연결됩니다.
• 도메인 이해는 암묵지를 문서와 계약으로 번역하는 능력으로 연결됩니다.

즉, AI 시대의 주니어 백엔드 개발자에게 필요한 것은 “AI 때문에 기본기가 더는 필요 없다”는 방향이 아니라, 오히려 기본기와 문서화 능력을 하네스라는 형태로 시스템에 연결하는 경험이라는 생각이 들었습니다.

저는 이게 특히 백엔드 개발자에게 중요하다고 느꼈습니다.

백엔드는 원래부터 코드만 맞으면 끝나는 일이 아니기 때문입니다. API 계약, 배치 실행, 장애 복구, 로그 구조, 메트릭 설계, 보안 경계, 데이터 정합성, 실패 재현 가능성 같은 것들이 모두 함께 움직여야 합니다. Harness Engineering은 결국 이런 백엔드적 감각을 AI 시대의 워크플로 안으로 끌고 들어오는 작업처럼 보였습니다.

그리고 이건 주니어에게도 꽤 중요한 훈련이 될 수 있습니다.

예전에는 주니어가 반복 구현을 하면서 시스템을 익혔다면, 앞으로는 그 반복 구현의 상당 부분을 AI가 먼저 가져갈 가능성이 큽니다. 그렇다면 주니어는 더 이른 시점부터 문제 정의, 검증 루프 설계, 문서화, 관측 가능성, 품질 유지 방식을 함께 배워야 할지도 모릅니다.

저는 이제 이 영역이야말로 AI 시대의 주니어 백엔드 개발자가 의식적으로 쌓아야 할 경험 중 하나라고 생각하게 됐습니다.

Git Ranker 재설계 관점

이 질문은 자연스럽게 제 프로젝트로 돌아옵니다.

처음 Git Ranker를 기획했을 때 저는 이 프로젝트를 통해 대용량 배치 처리, 데이터 파이프라인, 운영 경험, 모니터링 경험을 쌓고 싶었습니다. 즉, 단순히 기능을 하나 더 만드는 프로젝트가 아니라 서버가 실제로 힘들어하는 상황을 만들고, 그 상황을 관찰하고, 고치는 경험을 얻고 싶었습니다.

이 목표는 Harness Engineering과 의외로 잘 맞닿아 있습니다.

왜냐하면 Harness Engineering 역시 본질적으로는 “AI가 만든 코드를 믿어도 되느냐”의 문제가 아니라, 실제 실행 환경에서 어떤 일이 벌어지는지 관찰하고 검증할 수 있느냐의 문제이기 때문입니다.

최근 저는 git-ranker-workflow라는 저장소를 따로 두고, 백엔드와 프론트엔드 사이의 AI 워크플로를 정리해보려는 시도를 하고 있습니다. 다만 지금 있는 1차 시도는 일단 정답처럼 취급하지 않으려 합니다. 이번에는 그 상태를 기준점으로 삼기보다 OpenAI의 글에서 배운 원리를 기준으로 처음부터 다시 설계한다는 마음으로 접근해보려 합니다.

여기서 중요한 것은 OpenAI의 방식을 그대로 복제하는 것이 아닙니다. OpenAI도 그들의 자율성과 병합 철학이 유사한 투자 없이 일반화될 수 있다고 보지 않는다고 분명히 말합니다.

그래서 제가 Git Ranker에 가져오고 싶은 것은 “OpenAI와 똑같은 규모”가 아니라, 그들이 보여준 원리의 순서입니다.

만약 git-ranker-workflow를 처음부터 다시 설계한다면, 이 저장소의 역할도 더 명확하게 나눌 생각입니다.

즉, 하네스는 애플리케이션 코드 위에 덧씌우는 부속물이 아니라, 두 저장소를 하나의 제품처럼 읽고 검증하게 만드는 조율 레이어로 두고 싶습니다.

Git Ranker 적용 계획

제가 지금 시점에서 생각하는 적용 순서는 아래와 같습니다.

1. source of truth

가장 먼저 해야 할 일은 에이전트가 참고할 진실한 기록을 저장소 안에 만드는 것입니다.

AGENTS.md는 길게 늘어뜨린 사용 설명서가 아니라 진입점으로만 두고, 실제 핵심은 문서 트리에 둬야 합니다. 서비스 요구사항, 주요 사용자 여정, API 계약, 아키텍처 규칙, 도메인 용어, 운영 규칙, 보안 경계, 배치 흐름을 모두 버전 관리되는 문서 안으로 끌어와야 합니다.

특히 Git Ranker에서는 아래가 먼저 정리되어야 한다고 생각합니다.

• 사용자 등록부터 데이터 수집, 점수 계산, 랭킹 산정, 배지 서빙까지의 핵심 흐름
• GitHub API 실패, 속도 제한, 부분 실패 시 재시도와 복구 규칙
• 백엔드와 프론트엔드가 공유하는 계약과 용어
• 어떤 변경이 “완료”인지 판단하는 수용 기준

이 단계가 먼저 있어야 나중에 에이전트가 작업을 이어받을 수 있습니다.

2. 작업 단위 실행 공간

다음은 작업 단위의 worktree와 runtime을 분리하는 일입니다.

기능 하나를 고칠 때마다 백엔드, 프론트엔드, 로그, 메트릭, 스크린샷, 테스트 결과가 같은 작업 슬러그 아래에 묶여야 합니다. 그래야 “어떤 코드 변경이 어떤 실행 결과를 만들었는가”를 한 덩어리로 볼 수 있습니다.

이건 Git Ranker처럼 배치와 API, 프론트엔드가 함께 움직이는 프로젝트에서 특히 중요합니다. 예를 들어 어떤 작업이 랭킹 계산 로직을 수정했다면, 그 작업의 로그와 메트릭도 같은 맥락에서 바로 조회할 수 있어야 합니다.

즉, 코드 작업 공간과 관측 공간을 분리된 태스크 단위로 맞물리게 만드는 것이 두 번째 단계입니다.

3. 동작 중심 검증 하네스

그 다음에는 Git Ranker의 핵심 사용자 여정과 운영 시나리오를 검증 가능한 형태로 고정해야 합니다.

제가 먼저 하네스로 만들고 싶은 대표 시나리오는 아래와 같습니다.

1. 사용자가 GitHub ID를 등록하면 초기 데이터 수집이 시작되고 상태가 일관되게 반영되는가
2. 배지 요청이 들어왔을 때 최신 점수와 티어가 올바른 SVG와 캐시 정책으로 제공되는가
3. 일일 배치가 실행될 때 점수 집계와 랭킹 산정이 기대한 순서로 수행되는가
4. GitHub API 호출이 실패하거나 속도 제한이 걸릴 때 로그와 복구 동작이 명확하게 드러나는가
5. 사용자에게 보이는 UI 상태와 백엔드 로그, 메트릭이 서로 모순되지 않는가

이 단계에서는 테스트만으로는 부족합니다. Playwright 같은 E2E 확인, 브라우저 상태 점검, 구조화된 로그 조회, 메트릭 확인까지 한 루프로 연결해야 합니다.

그래야 에이전트가 “테스트는 통과했지만 실제 흐름은 어색한” 상태를 직접 감지할 수 있습니다.

4. 가드레일

한 번 리뷰에서 끝날 규칙은 점점 줄어들 것입니다. 자주 반복되는 판단은 린트, 구조 검증, CI 검사, 문서 검증으로 승격해야 합니다.

예를 들어 아래 같은 규칙은 Git Ranker에 기계적으로 심을 가치가 있습니다.

• 구조화된 로그 필드 규칙
• 백엔드 계층 의존 방향
• API 스키마와 명명 규칙
• 지나치게 큰 파일이나 역할이 섞인 모듈 감지
• 문서 링크와 실행 계획의 최신성 확인

이 단계의 목적은 에이전트를 통제하기 위해서만이 아닙니다. 사람인 저 자신도 같은 실수를 반복하지 않게 만들기 위해서입니다.

5. 점진적 자율성

가장 나중에 해야 할 일은 에이전트의 자율성을 높이는 것입니다.

OpenAI 글을 읽으며 가장 분명하게 배운 점 중 하나는, 자율성은 출발점이 아니라 결과라는 사실이었습니다. 문서, 계획, 실행 환경, 검증 루프, 관측 가능성, 가드레일이 충분히 쌓인 뒤에야 에이전트가 더 긴 작업을 맡을 수 있습니다.

그래서 Git Ranker에서도 처음부터 “기능 하나를 끝까지 알아서 구현하게 하자”는 방향으로 가기보다, 먼저 작은 범위에서 검증 가능한 작업을 맡기고, 그 결과를 바탕으로 점차 루프를 확장해야 한다고 생각합니다.

저는 이 순서를 지키는 것이 “완벽한 적용”에 더 가깝다고 봅니다. 겉모습만 하네스를 흉내 내는 것보다, 자율성이 올라갈 수밖에 없는 토대를 차례대로 만드는 편이 더 정직하기 때문입니다.

Git Ranker에서 쌓고 싶은 경험

정리해보면, 제가 Git Ranker에서 새롭게 쌓고 싶은 경험은 단순히 “AI를 써서 더 빨리 기능 만들기”가 아닙니다.

그보다는,

• AI가 읽을 수 있도록 맥락을 구조화하는 경험
• AI가 직접 검증할 수 있는 실행 환경을 만드는 경험
• 로그와 메트릭을 통해 결과를 판단하는 경험
• 문서, 계획, 테스트, 관측 가능성을 하나의 루프로 묶는 경험
• 드리프트를 방치하지 않고 작은 정리 루프로 유지하는 경험

이 다섯 가지를 실제 프로젝트 안에서 반복해보는 쪽에 더 가깝습니다.

예전에는 서버를 띄우고 장애를 겪고 복구하면서 운영을 배웠다면, 이제는 거기에 하나가 더 붙습니다. AI가 만들어내는 빠른 출력 속도를 감당할 수 있도록 개발 시스템 자체를 설계하고 유지하는 경험입니다.

정리

지난 글에서 저는 AI 시대의 주니어 백엔드 개발자가 붙잡아야 할 것으로 문제 정의, 검증, 문서화, 책임을 이야기했습니다.

이번 글을 쓰면서는 그 생각이 한 단계 더 구체화됐습니다.

이제 저는 AI 시대의 주니어 백엔드 개발자에게 필요한 다음 실전 역량 중 하나가 Harness Engineering 경험이라고 생각합니다.

AI에게 더 많은 일을 맡기는 시대일수록, 누군가는 그 일이 안전하게 이루어질 수 있는 맥락, 실행 환경, 검증 루프, 정리 규칙을 설계해야 합니다. 그리고 저는 그 역할이 생각보다 백엔드 개발자의 감각과 깊이 맞닿아 있다고 느꼈습니다.

그래서 앞으로 Git Ranker에서는 단순히 기능을 더 붙이는 것보다, AI가 일할 수 있는 저장소와 실행 환경을 더 선명하게 만드는 작업을 해보려고 합니다.