AI와 사람이 팀을 이루어서 일하기
처음으로 콘텍스트만으로 AI를 이용해 개발 업무를 진행했다. 바이브 코딩이나, LLM을 활용해서 코드 일부는 생성해서 적용해보았으나, 코드를 아예 작성하지 않은 적은 처음이다.
내가 소속된 MHP팀에서는 여러 인프라를 모니터링하고, 장애를 감지하기 위해 "Zero Problem"이라는 시스템을 운영중이다.
우리가 사용하는 주 인프라 중 하나인 MongoDB는 멀티 클라우드, 클러스터 구조로 되어있는데, Primary는 쓰기 작업을 하면, 작업 로그라는 특수한 목적의 콜렉션에 기록한다.
두 개의 Secondary는 주기적으로 작업 로그에서 가져와서 Write를 한다. Disk I/O와 같은 DB에 큰 부하가 발생한다면, 앞서 처리해야 할 I/O 때문에, Replication Lag가 발생한다. 때문에, 클러스터 환경에서 대용량 트래픽을 모니터링할 때, Replication Lag 중요한 요소이다.
Zero Problem에 몽고 Replication Lag을 모니터링을 연동하는 간단한 LongTerm 프로그램을 만드는게 내 업무였다.
직접 코딩했으면 완료까지 2시간 정도를 예상했다. 하지만 내가 예측한 작업 시간이 긴지, 짧은지는 모른다. 나는 이 시간이 좀 크다고 생각했다.
작은 일을 하더라도, 노력은 덜하고, 적절한 결과 얻되, 가치를 가져갈 수 없을까 하는 의문과 함께 AI와 팀을 이루어 작업을 지시할 콘텍스트 작성을 시작했다.
진행 과정
- 콘텍스트 작성
- LLM으로 코드 생성
- 코드리뷰
- 개발환경에서 실행 후 검증
- 운영환경에서 실행 후 검증
팀 구성
내가 만든 간단한 팀은 팀장인 나와, 개발자인 AI팀원 두 명으로 구성된 단순한 팀이다.
- 사람(나): 팀장 - 작업지시서 작성, 작업 지시, 코드 실행, 테스트, 반영 여부 판단
- AI팀원 - 지시서를 바탕으로 코드를 작성한다.
콘텍스트 작성
우리는 Controlplane이라는 자체 개발 환경을 가지고 있는데, 테스트와 배포, 모두 같은 환경에서 이루어진다.
콘텍스트라는 단어에 대해 다시 생각해보자. 콘텍스트는 한글로 문맥인데, 글의 핵심을 말한다. 네트워트 프로그램에서 콘텍스트는 무엇일까.
- 목표 또는 비즈니스 로직, 의도
- 스키마
- API 설계
LLM의 역할, 페르소나를 넣어야 하기 때문에 지시 사항, Instruction도 함께 필요하다.
당신은 lc 프레임워크 코드를 생성하는 AI 에이전트입니다.
아래 본문 내용과 Instruction에 따라 별도 설명없이 LongTerm 코드를 작성하세요.
# Goal
클러스터 환경에서 서비스되는 몽고DB 인프라의 Replcation Lag 수집과 소비
# Instruction
- 서비스 아이디는 mhp.zeroproblem.mongo.replcationlag
- 몽고db 접속 정보는 "clusterKeeper" infra as label 사용
- 1분 마다 한번 씩 cluster mongo의 Replcation Lag을 수집
- Primary와 Secondary와의 lag 차이를 miliseconds 단위로 계산
- 수집한 Replcation Lag를 Schema 형태로 가공 후 API 형태로 조회
- messages 배열은 내용을 "단 하나"만 넣고 유지하고, actionBody 하위에 마크다운 문법의 문자열 사용
- RED, YELLOW, GREEN 기준
- Green (정상) 0 ~ 5000ms
- Yellow (주의) 5000 ~ 30000ms
- Red (위험) 30000ms 이상
- 수집한 Replcation Lag 데이터의 저장은 서비스 내부 변수의 메모리를 사용하세요
스키마와 API 설계도 함께 전달한다.
# Schema
{
[서비스아이디]: {
"status": "RED" | "YELLOW" | 'GREEN",
"timestamp": new Date().getTime(),
"messages": [
{
"statusCode": "",
"statusBody": "mhp.zeroproblem.mongo.replcationlag",
"actionCode": "",
"actionBody": `- Primary {서버이름} replcation lag 0ms \n- Secondary replcation lag 0ms \n- Secondary replcation lag 0ms`,
}
]
}
}
# API
- PUT /mhp.zeroproblem.mongo.replcationlag
- 수집한 Replcation Lag의 수집 결과가 담긴 Schema를 body 형태로 응답
- GET /liveness
- lc mongo connection 여부
- 최근 수집한 데이터의 timestamp가 3분 이내이며, 클러스터 환경에서 lag 데이터를 정상 수집 중인 경우 200 OK 응답
이 정도 컨텍스트로 코드를 생성하고, 리뷰하길 몇 번 반복한다.
AI 팀원에게 코드 작성을 지시하고, 나는 리뷰를 한다.
코드를 한 줄 한 줄 세세하게 보진 않지만, 대충 100줄짜리 코드를 보고, 팀장인 내가 리뷰를 한다.
콘텍스트 수정/코드실행 반복
우리가 구축한 LLM은 RAG 방식, 좀 더 세부적으로는 MCP 서버의 툴이기 때문에 생성할 코드의 산출물이 되는 프레임워크의 문법을 조금 알고있지만, 자세히는 모르기 때문에, 콘텍스트 노트에 예시 코드 추가해준다.
## 데이터 수집 로직 example
const db = $.mongoose('clusterKeeper');
const client = db.getClient();
const adminDb = client.db('admin');
adminDb.command({ replSetGetStatus: 1 })
.then((results) => {
console.log(JSON.stringify(results))
})
.catch(e => { $.log(`오류 발생 ${e?.message}`) });
이렇게 생성된 코드를 테스트도 하고, 실행도 시켜본다.
코드 생성
테스트 코드 실행
조금만 더 깊게 생각해보면, 테스트와 플레이도 내가 해야할까? 몇 번 반복하면 되지 않을까?
인풋으로 내가 만든 콘텍스트와, AI팀원이 생성한 코드를 받아, 테스트코드를 작성하는 개발자 AI팀원이 한 명 더 있을 수 있겠다. 코드를 실행시키고 결과를 리포팅하는 AI팀원이 한 명 더 있을 수 있겠다. 테스트코드를 실행시키고 결과를 리포팅하는 AI팀원이 한 명 더 있을 수 있겠다. 운영 환경에서 모니터링도 해야하잖아? 매일 재시작 회수나, 서비스의 안정성을 평가하자.
다음 팀을 다시 만든다면?
팀 구성
- 사람(나): 팀장 - 작업지시서 작성, 작업 지시, 최종 판단
- AI팀원 "A": 개발자 - 작업지시서 기반 코드 작성
- AI팀원 "B": 테스트 개발자 - 작업지시서와 "A"가 생성한 결과로 테스트 코드를 작성
- AI팀원 "C": 보조 개발자 - "A"가 생성한 코드 실행 후 서비스 상태, 실행 결과 리포트
- AI팀원 "D": QA개발자 - 테스트코드 실행 후 실행 결과 리포트
- AI팀원 "E": 모니터링 - 서비스의 지속적인 모니터링 후 이상 발생 시 결과 리포트
좀 더 쪼개졌다. 여기서 만든 A,B,C,D는 콘텍스트만 달라진다면, 다른 업무에서도 쓰일 수 있는 AI팀원 페르소나이다.
팀을 더 쪼개는 작업은 아직 구현물로는 나오지 않은 상상의 영역인데, 올해 말까지 팀의 KPI에 속해있으니, 어떤 결과가 나올지 기대가 된다.
회고
위 작업을 통해 내가 얻어간 가치는 다음과 같다.
원래 하던 방식 말고, 다른 시도
그냥 자연 상태의 나라면, 타이핑을 먼저 하지 않았을까? New File 눌러서 대충 LLM에게 채팅처럼 대화했을텐데, 콘텍스트를 작성하는 시도 자체가 좋았다.
적절한 수준의 콘텍스트 작성
콘텍스트를 작성한다는게 생각보다 어렵다. LLM이 이해할 수준의 문맥으로, 지시대명사, 명사를 적절하게 선택해야하기에 에너지 소비가 꽤 큰 작업이다. 그러나 이걸 잘 한다면, 작성이 당연해진다면 산출물의 언어는 중요하지 않을 것이다.
덜고 덜어서 마지막에 남는건 코드가 아니라, 콘텍스트이다. 앞으로 나올 LLM의 성능과 Spring, Node 등 산출물의 종류가 변수라면, 콘텍스트는 상수이다.
AI팀원과 함께 일하는 Agentic Workflow와 앞으로의 방향 가늠
업무를 다르게 해보니, 앞으로의 미래를 어렴풋이 상상하고 가늠해볼 수 있었다. AI와의 협업이 당연한 세상에서 극단적인 생산력 자체를 설계할 수 있는 조직이 승리할 것이다.
개발 도구에 대한 고민
우리 팀은 "생산"만 하는게 아니라, 생산을 끌어올릴 "생산 도구"도 함께 설계하고 구현한다. 지금 사용하고 있는 도구는 테스트 툴로 시작을 했다. 지금의 UI는 코딩을 하는 "사람" 위주의 디자인이라는 생각이다. 앞으로 사람의 업무 방식은 워크플로우를 디자인하고, 컨텍스트를 작성하는게 메인이라면, 지금 가장 넓은 영역으로 구성된 코드 영역이 더 축소되어야 하지 않을까 하는 Developer Experience에 대한 방향도 달라져야 할 것이다.
앞으로
이 글은 콘텍스트 엔지니어링이라는 주제로 시작했지만, 사실 AI와 사람이 팀을 이루어 일하는 것을 설계하는 Agentic Workflow가 주제였다. "AI+사람 조직" vs "사람 조직"의 경쟁 구도라면 결과는 불보듯 뻔하다.
LLM의 등장과 함께, 내가 10년 간 해오던 기술의 가치가 쓸모 없어진 세상을 맞앗다. 방직기를 처음 본 수공업자의 마음이 이것일까.
매일 전 세계에 AI와 관련한 뉴스와 새 발명품이 쏟아진다.
운이 좋게도 전 세계의 패러다임과 함께 앞서가는 방향으로 이끄는 리더와 조직에서 일한다고 있다.
올해는 또 다시 나를 다시 한 번 돌아보고, 지금의 패러다임에서, 내가 잘 하는 것이 무엇일지 가늠하고, 그것에 집중해야겠다.