1. 멀티 에이전트 시스템
LLM의 본질
- LLM은 확률 기반 다음 단어 생성기
- 컨텍스트 = 전체 대화 기록 (대화가 핑퐁될수록 맥락 누적)
- LLM은 텍스트만 출력 가능 (JSON 포함)
프롬프트 설계 원칙
나쁜 예: 작성+검사 프롬프트 120줄
좋은 예: 작성 60줄 + 검사 60줄
- 작성 시점에는 검사 프롬프트가 지침 정도로만 기능
- 작성 완료 후 검사 프롬프트가 제대로 된 피드백 제공
- 각 단계마다 필요한 프롬프트만 포함
피드백 루프
- 한 번에 완벽한 결과 X
- 작고 빠른 루프를 반복하는 것이 효율적
- 각 서브 에이전트마다 작업 가이드 배치
- 구조: 오케스트레이터 / 서브에이전트 (예: FE 구현자/검토자)
개발 과정의 진화
CLI → 데스크톱 앱 → 컨텍스트 윈도우 문제 발생 → JSON 템플릿화
핵심 정리
- 논리적으로 압축하기
- 세부 스케치는 뒤에서 (같은 문서 공유)
- 같은 철학, 같은 가치관 유지
- 텍스트 양이 많아지는 순간 최대한 지연
- 자료구조 활용
- 프로그래밍 입출력 활용
2. 요즘 회사 일
변화한 업무 속도
- 2~3년 전 대비 피처 개발 시간이 크게 단축
- 회사마다 AI 수용 정도와 속도 차이가 큼
시니어 개발자의 하루
- AI를 통해 개발 진행도만 빨라짐 (코드 작성, 리뷰, 테스트)
- PM, 디자이너는 상대적으로 느림 (사람 중심 업무)
- 결과: 기다리는 공백 시간 발생
남는 시간 활용법
1) AI 에이전트/도구 개발
- 김재섭 mk.2
- 사내용 네트워크 디버거 (Proxyman 같은 도구를 사내 워크플로우에 맞게 구현)
- FE 의존성 업데이트 에이전트 (반복적 업그레이드 자동화, PR 자동 생성)
- 로우 시큐(?) or Obsidian으로 작업 내용, 회의록을 맥락으로 정리
2) 제품에 기여
문제 정의 (우선순위)
- 비즈니스 기회 / 성과 / UX 임팩트 관점
- 어떤 기능이 일정을 폭발시킬지 판단
본질부터 (대안 제안)
- PRD의 "왜 필요한지"를 먼저 질문
- 더 효율적인 대안 제안 (대부분 거절돼도 OK)
지표 설계 (다음 개선)
- 지표 대시보드 직접 설계
- 운영 이슈를 다음 제품 개선 아이디어로 전환
PM은 직책이 아니라 역할이다
3) AI 잘 쓰는 법
- 사내 스터디 진행
- 반복 가능한 컨텍스트로 작업 안정화
- 어떤 일을 에이전트/사람이 할지 잘 설계
- 노하우를 팀으로 공유해서 전체 수준 끌어올리기
AI에게 일을 시키는 능력도 차별점이다
4) 역할 변화
- 기존: 구현 업무를 직접 손으로
- 현재: AI와 페어로 작업
- 사람의 역할: 판단, 검증, 아키텍처 결정
AI가 코드를 짜줘도 그 코드를 책임지는 건 결국 나다
학생/저연차 개발자를 위한 조언
- AI로 비즈니스 대박 노리지 말기
- 정말 작은 문제를 한 번 풀어보기
- 무얼 할지 방향 잡고, 작더라도 성공 경험 쌓기
- 큰 성공보다 끝까지 풀어본 작은 문제가 다음 방향을 만든다
인디 개발의 현실
- A/B 테스트를 정말 빠르게 진행
- "돈 벌고 유저들한테 사랑받는 제품" → 진짜 어려움
앞으로 중요한 것
- 무엇을 실행할지 고르는 능력
- 고른 것을 실제로 성공시키는 힘
3. 신입 개발자 필요한가요?
AI의 한계
- AI는 "가챠" (비결정적)
- 예: 같은 코테를 같은 프롬프트로 맡겨도 매번 다른 결과
개발자 일이 줄어드는가?
줄지 않은 일:
- 요구사항 분석
- 리서치
- 아키텍처 인터페이스 설계
- 코드 설계
- 테스트/QA
변화:
- 한 번에 진행하는 프로젝트 개수 증가
- 그만큼 더 많이 일함
회사가 신입에게 바라는 것
"했습니다" ❌
"왜" 했는지를 구체적으로 설명 ✅
학생이 해야 하는 것: TF 리더 연습
1) 문제부터 정의
- "무엇을 만들지"가 아니라 "누구의 어떤 문제를 풀지"
2) AI 결과를 의심
- "짜줘" ❌
- "옵션 3개로 비교해줘" ✅
3) 기본기를 더 깊게
AI를 평가하려면 기준이 있어야 함:
- CS, 알고리즘, 자료구조
- 쓰는 기술의 동작 원리
- OS, 네트워크, DB 동작 원리
- 요구사항 분석
- 디자인 패턴, 클린 코드
4) 여정을 설명하기 - 5요소
프로젝트를 다음 순서로 설명할 수 있는가?
- 배경 - 누구의 어떤 문제였나?
- 임팩트 - 그 문제가 얼마나 풀렸나? (지표, 반응)
- 대안 비교 - 다른 안과 무엇을 따져 골랐나?
- 동작 원리 - 어떻게 돌아가나?
- 사이드 이펙트 - 어떤 케이스에서 어떻게 처리했나?
4가지를 훈련하고 하나라도 TF 리더처럼 행동해보자!
4. 눈물의 AI 격변기
- 링크드인 활용
- 넓고 얕게 경험하기
5. 경쟁력 있는 개발자는?
단순 코딩 ❌ 소프트웨어 개발자 ⭕
- 기술적으로 코드 깎는 장인보다 전체를 보는 E2E Engineer
- 개발자 한 명의 파트/역할이 늘어남
- "좋은 기술 만들기" → "좋은 경험 만들기"
안목 높이기
AI는 인형 뽑기 기계
뽑는 사람이 어떻게 뽑느냐?
피해야 할 세 가지
1) 인지 부채
AI에 지나치게 의존, 스스로 사고하지 않음
2) 지적 비만
너무 많은 정보를 섭취해서 실제로 소화하지 못함
3) 인지 중력
편해진 방법에서 벗어나는 것이 어려움
AI에 너무 의존하지 말라는 내용을 AI를 써서 요약했다.