AI Native Dev - Intro
목적
왜 하는가? ADD : AI Driven Development
- AI을 활용한 A-Z 비즈니스 및 개발 방법론을 연구, 실제 PoC을 통해서 AI의 한계가 어디까지 가능한지 실험 한다.
리서치
📌 AI-DLC 기반 웅진씽크빅 북큐레이터 AI 에이전트 구축
📌 Harness Engineering (AI / Software context)
- AI agent 또는 LLM이 실제 시스템에서 안정적으로 작동하도록 주변 인프라와 환경을 설계하는 엔지니어링 방식
- 모델을 둘러싼 실행 환경 (Harness) 을 설계
📌 Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기
문제 : 같은 LLM을 써도 팀 내 결과물 편차가 큼, LLM Literacy(컨텍스트 설계 능력) 격차
- 목표: 팀 생산성의 저점(Raising the Floor) 상승
- LLM 활용을 개인 역량이 아닌 조직 차원의 하네스(Harness) 로 설계
솔루션 : 조직 차원의 워크플로우 배포 플랫폼
- 조직이 일하는 방식을 워크플로우로 정의하고 이를 한곳에서 배포&관리한다.
- 시나리오 예) /new-feature 입력 : 티켓 발급 -> 브랜치 생성 -> 구현 계획 작성
- Executable SSOT : 문서는 사람이 읽으면 매뉴얼, LLM이 읽으면 실행 가능한 코드형 지식
- Layered Architecture : 글로벌 수준, 팀 수준, 로컬 수준 등 레이어마다 다른 워크플로우
- Data Flywheel 가설 : 플러그인 기반 워크플로우 → 정형화된 데이터 축적 → 도메인 특화 모델 파인튜닝
언제 AI의 효용이 높을까?
AI가 딸깍 수준으로 잘 했던것들 테스크
- 대출상담사 진위 여부 판단 해줘 : 오픈클로가 브라우저 검색 및 자동화로 대출상담사 조회 후 결과를 사진 캡처해서 알려주었다.
- *답이 정해져 있는 행정 업무 + AI가 접근 가능한 리소스
AI가 못해서 블록킹이 발생한 테스크
- Markup 작성, 언어모델이 UI을 작성하고 실제 그 화면을 보고 재검증 하지 않는다.
원칙
1, 생산과 배움은 다르다.
- AI가 생산한 코드는 나의 능력 안, 능력 밖의 코드일 수 있다.
- AI가 생산한 코드가 나의 능력 밖의 코드라면 나의 사고력 밖의 부분이다.
- 이 부분을 명확히 짚고 넘어가야 한다. 한번 이해하고 넘어가면 된다. 그 다음부터는 알던 지식의 반복이다.
2, AI 개발 프로세스에서 검증은 중요하다.
- 개발자가 작성한 코드를 QA팀이 한번 더 검수를 진행한다. 생산과 검증 완전히 다른 영역 이다.
- 반드시 사람이 검증을 하고 넘어가야 한다. (제품팀에서 리뷰 없이 실사용자에게 나간다면 실고객이 검증자이다. )
3, 최소 요구 양식(템플릿)
- AI의 생성의 자유도를 막을 필요는 없다. 하지만 어느 정도 틀을 제공 할 필요는 있다.
- AI작성한 모든 계획과 생산 결과물을 볼 수 없다. 보는데 시간이 많이 걸린다.
- 인간이 걸림돌이며 이는 사람이 봐야 할 양이 너무 많고 머리속 처리(내용의 재구조)의 한계에서 발생한다.
- 1, 양을 해결 하기 위해서는 상위 수준의 계획서, 상위 수준의 설계, 상위 수준의 검증 리포트가 필요하다.
- 2, 머리속 처리 가속을 위해서, 미리 사전에 정의한 프레임워크, 템플릿, Problem Solving 양식을 정의하는게 필요하다.
4, 발산과 수렴 그리고 운영
- AWS AI DLC(https://aws.amazon.com/ko/blogs/tech/aws-aidlc-woongjinthinkbig-tech-blog/) 을 보고 Inception, Construction 단계는 각각 발산과 수렴으로 보인다.
- 발산 단계에서는 상위 수준의 목표, 의도를 가지고 브레인 스토밍, 목표 설정, 구체화, 제약 사항, 리스크 검토 등 Why, How에 집중하는 것 같다.
- 수렴 단계에서도 What에 집중하여 기술적으로 어떻게 구현하고 검증할지에 집중하고 있다.
5, 사람은 상위 수준의 계획과 검토을 검증한다.