저는 17년 이상의 경력을 가진 실무 소프트웨어 엔지니어이며, 더 이상 직접 코드를 작성하지 않습니다. 그럼에도 불구하고 저는 매일 소프트웨어를 배포하고 있습니다. 버그를 수정하고, 분석을 수행하며, 시스템을 설계하고, 새로운 기능을 구현하며, 변경 사항을 테스트합니다.

실제 코딩 작업의 경우, 저는 제가 사용하는 에이전트 기반 코딩 도구(agentic coding tools)의 가이드가 되었습니다. 저의 책임은 이들에게 필요한 컨텍스트를 제공하는 것입니다. 저는 결정론적 검증(deterministic verification)을 사용하여 수용 기준(acceptance criteria)을 정의하고, 결과의 완전성과 정확성을 확인하기 위해 증거(evidence)를 검토합니다.

주니어 프로그래머처럼 안내하지만 영원히 그렇지 못한 이유

어떤 사람들은 LLM이 모든 것에 대해 적절한 지침을 제공해야 하므로 주니어 프로그래머와 같다고 말합니다. 이 비유는 어느 정도까지는 사실입니다. 주요 차이점은 인간의 주니어 개발자는 시간이 지나면서 전문가가 된다는 것입니다. 그들은 여러 실수를 저지른 후 더 나은 결정을 내리고, 팀 내에서 신뢰를 쌓으며, 자신의 작업에 자부심을 갖게 되고, 결국 다른 개발자들을 멘토링하고 코칭하게 됩니다.

하지만 LLM은 영원한 주니어 상태에 머물러 있습니다. 여러분은 그들의 에이전트가 항상 필요한 컨텍스트에 접근할 수 있도록 보장해야 하며, 이 컨텍스트는 실제적이고 최신 상태여야 합니다. 에이전트는 안전한 환경에서 올바른 도구에 접근할 필요가 있으며, 작업 중 어느 순간에도 여러분의 도움이 필요할 수 있습니다.

컨텍스트 관리하기

인간으로서 저는 작업을 시작하는 데 필요한 정보를 검색해야 합니다. 이 작업이 시스템의 일부이기 때문에, 저는 시스템이 어떻게 작동하고 어떤 기능(functionality)을 가지고 있는지 이해해야 합니다. 만약 제가 이미 그 시스템에 익숙하다면, 많은 분석을 할 필요가 없습니다. 단지 달성해야 할 결과를 확인하고, 수용 기준을 이해하며, 구현을 시작하기에 충분한 정보를 갖추고 있는지 확인할 뿐입니다.

안타깝게도 에이전트 도구는 아직 마음을 읽는 기술을 가지고 있지 않기 때문에, 제가 컨텍스트를 발견하도록 돕고야 합니다. 이 컨텍스트는 spec.md나 agent.md 파일에 있을 수도 있고, 에이전트가 MCP 서버를 사용하여 접근할 수 있는 티켓일 수도 있으며, README.md에 있거나 단순히 프롬프트에 직접 포함될 수도 있습니다.

에이전트가 실행되는 환경 또한 중요합니다. 노트북, 서버, Docker 컨테이너, 또는 샌드박스일 수 있습니다. 어디에서 실행되든, 환경은 보안 위험을 완화해야 합니다. 인터넷 접근 차단과 같은 결정론적 제한(deterministic restrictions)을 제공하고, 다른 폴더를 읽는 것을 제한하며, 레포지토리 접근을 관리해야 합니다(예: main 브랜치에 대한 푸시 거부).

마지막으로, 적절한 도구(tools), MCP, 그리고 기술(skills)에 대한 접근이 필요합니다. 백엔드 작업을 수행하는 경우, Playwright MCP가 필요하지 않을 가능성이 높습니다. 너무 많은 기술로 컨텍스트를 부풀리는 것을 피하고, 특정 작업에 필요한 올바른 것만 활성화하도록 하세요.

MCP 서버는 가능한 한 피하고 CLI 도구를 선호하세요. 예를 들어, playwright-cli, jira-cli, gh, glab 등을 사용하세요.

인간의 신뢰에서 확실한 증거로

Engineer validating evidence

LLM으로부터 모든 것을 검증하기

LLM의 결과는 신뢰할 수 없습니다. 비결정적(non-deterministic)이기 때문입니다. 완벽한 컨텍스트를 제공하더라도, 모든 것이 규칙을 따라 수행되었다고 가정할 수 없습니다. 실수는 발생하며, 계속해서 발생할 것입니다.

결과를 검증하는 방식은 컨텍스트에 따라 달라집니다. 자동화된 테스트 및 Playwright 테스트 실행부터 스크린샷이나 테스트 결과 확인까지 다양할 수 있습니다. 개발 환경에서 변경 사항의 영향을 보여주는 임시 보고서(ad-hoc reports)가 필요할 수도 있고, 수동 단계를 실행해야 할 수도 있습니다. 이는 작업의 성격에 따라 달라집니다.

저는 에이전트가 자체적으로 코드 리뷰를 수행한 후에야 코드를 검토합니다. 구현상 정말 개선할 부분이 있다면, 에이전트가 더 잘하도록 안내하는 댓글을 남깁니다.

나중에 실제 운영 환경(production)에서 결과를 검증해야 하며, 이는 수동으로 코드를 변경했을 때와 완전히 동일합니다. 이 모니터링 과정에서도 에이전트를 활용할 수 있습니다.

마지막 단계는 회고(retro)를 하는 것입니다. 중요한 학습 내용을 저장하세요. 어쩌면 다음번에 새로운 규칙이나 결정론적 도구(deterministic tool)가 되어야 할 공통 오류가 있었을 수도 있습니다. 이렇게 하면 다음 세션이 더 빠르고 토큰 비용 효율적(token-cost effective)이 됩니다.

Agent workflow overview

개발 작업을 위한 일반적인 워크플로우 개요

LLM을 탓할 수 없습니다

좋은 소프트웨어 설계, 낮은 결합도(low coupling), 높은 응집도(high cohesion), 고품질 코드, 그리고 단순성은 여전히 필수적입니다. 여러분이 이미 알고 있는 모든 소프트웨어 엔지니어링 지식은 여전히 중요합니다. 당신이 책임지는 인간입니다. 당신이 결정을 내립니다. 어쩌면 코드를 한 줄씩 작성하지 않을 수도 있고, 모든 줄을 검토하지 않을 수도 있지만, 결과물이 높은 품질을 갖도록 보장해야 합니다.

[!경고]
LLM은 아직 안정적이지 않습니다. 어떤 날은 좋은 결과를 얻지만, 어떤 날은 특히 새로운 모델 출시 직전에 얼마나 멍청해질 수 있는지 믿기 어려울 때가 있습니다. 저는 모델 제공업체들이 서비스의 실제 상태에 대해 투명성을 개선하기를 바랍니다. 핵심은 여러 공급업체를 백업으로 준비하는 것입니다.

결론

2026년 초부터 저는 직접 코드를 한 줄도 작성하지 않았습니다. 저는 LLM 기반의 에이전트형 코딩 도구에 전적으로 의존합니다. 저는 이 도구들이 충분한 컨텍스트(context)를 갖도록 하는 데 노력을 집중하고, 그들이 제공하는 결과물을 절대 신뢰하지 않도록 주의합니다. 지금 코드를 생산하는 것은 저렴하지만, 고품질의 소프트웨어를 더 빠르게 생산하는 것은 아직 저렴하지 않습니다. 저는 여전히 결과를 검증하고 유효성을 확인하는 데 상당한 시간을 할애합니다. 아직 만능 해결책(silver bullet)은 없습니다. 저는 여전히 배우고 있으며, 소프트웨어를 개발할 더 나은 방법을 계속 찾고 있습니다.