갤러리 이슈박스, 최근방문 갤러리
연관 갤러리
나는 솔로 갤러리 타 갤러리(0)
이 갤러리가 연관 갤러리로 추가한 갤러리
추가한 갤러리가 없습니다.
0/0
타 갤러리 나는 솔로 갤러리(0)
이 갤러리를 연관 갤러리로 추가한 갤러리
0/0
개념글 리스트
1/3
- 부산 기장 아파트 화재 자매 사망 사고, 화재 전 정전 어깨왕
- 킹 짱 후 3루타 ⚡️⚡️⚡️.gif 이강준
- 실제 살인마의 죽음으로 결말을 수정했던 영화 ㅇㅇ
- 고깃집에 간 김두한 웅그림아이언피
- 솔직하게 말했다가 한소리 듣는 족발집 사장님 ㅇㅇ
- 일본근황) 외제차 10대 부수고 인생 조진 20대 쪽남 난징대파티
- 고동석 스카이데일리 편집국장 사망 ㅇㅁㅇ
- 싱글벙글 우왁굳의 영화평.....개빡친 신도....JPG ㅇㅇ
- 빌게이츠의 원래 재산 ㅇㅇ
- 스압) 7월 출시 인디 게임 모음 (전반부) 빗소리P
- 여자 손님이 더 무섭다는.. 사장님 ..jpg 3dd
- 뷔페에서 초밥에 소스 빼달라는 맘충 ㅇㅇ
- 조선왕들 이름이 외자인 이유.jpg 네거티장애
- 여자들끼리 의견 갈린다는 '머리감기' ㅇㅇ
- 리버풀 공격수 디오고 조타 교통사고로 사망 ㅇㅇ
바이브코딩 '해줘' - 가설편
대충 AI와 함께 챗봇이든 Cursor든 작업을 하다보면, 뭐가 됐든 우리는 '해줘'를 시전해야 한다.그게 기본적으로 인간과 AI가 함께 작업하는 방식이다.그게 API가 되었든, 구독형 챗(일반적인 웹 사이트)이 되었든 어쨌든 우리는 AI에게 '이거좀 해 줘'를 시전한다.하지만 아쉽게도 AI는 무한한 자원이 아니라서 제한이 존재한다. 챗봇에는 이러한 Context limit이 하나의 채팅방마다 존재한다.Claude는 굉장히 적극적으로 이러한 리미트가 존재하고, GPT나 AIS는 이러한 리미트는 비교적 적지만, 대신 채팅이 길어질수록 환각이나 정보가 희석된다.즉, 문제가 생긴다.1. 채팅을 길게 '못' 한다.2. 채팅을 길게 하면 '병신'된다.이 것이 현재 AI의 문제점이다.우리는 보통 지금까지 '프롬포트 엔지니어링'에만 신경을 써 왔다. 대충 AI에게 '너는 선생님이고 나는 학생이야. 근데 이래도 될까?'하는 컨셉을 부여하고, 그걸 고도화 하는 작업이다.하지만 아무리 컨셉질을 해봐야 '고객님. 시간 다 되었습니다. 연장하시겠습니까?' 앞에서는 컨셉질도 무효화 되는 법이다.실제로 현재의 많은 AI들은, 한번에 읽어들일 수 있는 컨텍스트의 제한이 매우 엄격하거나 한정적이다.똥피하기 게임 정도나 간단한 웹사이트 정도는 바이브코딩으로 어떻게든 가능하겠지만, 뭔가 전반적인걸 하기엔 제한이 많다는 뜻 이다.나중에 Chat GPT 2만달러 요금제 (월 요금 2800만원)짜리면 모르겠지만, 우리가 쓰는 일반적인 한달 2-3만원의 요금제는 물론이고, 혹은 한달 30만원짜리 고급 요금제로도 저런 한계가 존재한다.참고로 나는 현재 ChatGPT pro (월 약 30만원), Claude MAX 20 (월 30만원)의 요금제를 구독 중인데도 저런 한계를 매번 체감중이다.Pain point. 아 ㅅㅂ 대체 어디부터 어디까지 '해 줘'를 시전해야 하지?아무리 노련한 프로그래머라도, 프로젝트가 커지면 어떤 하나의 기능을 수정하기 위해 그 기능이 어떻게 동작하는지를 까먹기 마련이다.예를들어 [고추의 발기 기능]을 수정하고 싶은데, 그 것이 방광과 연결되는지 전립선과 연결되는지, 아니면 자율신경계와 연결 되는지,호르몬과 연결 되는지, 혹은 두뇌와 연결되는지, 아니면 겉 피부와 연결되는지 알 수가 없다는 것이다.때로는 고추의 발기 기능을 수정하기 위해서는 비아그라 한알이면 될 때도 있겠지만, 대체적으로는 그보다 많은 수정사항이 필요하기 마련이다.그래서 시중에는 이러한 painpoint를 돕기 위한 수 많은 프로그램이나 개념적 아이디어, 그리고 그를 돕기위한 도구가 존재한다.대충 몇줄로 설명 해 보자면, 엑셀과 같은 관계형 데이터베이스의 형태로 프로젝트를 분석해 놓은 기록을 바탕으로 전체 프로젝트를 둘러본다는 말이다.아래와 같이, 프로젝트의 기능들을 엑셀처럼 정리 한 다음에 관계적으로 나타내는 것이다.사실 한국의 대부분의 스타트업, 혹은 중견기업의 프로젝트들은 아래와 같은 형태로 프로젝트를 관리 하고 있을 것이다.관리의 효율성이 매우 뛰어나기 때문이다. 눈에 보이는 차이는 조금씩 있을지언정, 기본 컨셉트는 비슷하다는 말이다. 그리고 나도 대부분의 상황에서는 이러한 사용방식과 관리방식에 동의한다. (지금까지는)하지만 문제가 있다.이러한 방식은 대부분 프로젝트 전체의 온보딩을 담당하는 PM급의 인력이 '인간의 두뇌'를 이용하여 관리해야 가능한 방식이다.우리와 같이 바이브코딩을 하는 '해줘 충'들에겐 부적합하다.그래서 최근 이러한 '해 줘'충들이 징징거리는 테마가 하나 있다.'응, 프롬포트 엔지니어링보다 컨텍스트 엔지니어링이 더 중요해 ㅋㅋ'대충 해석하자면 컨셉질보다는 'AI에게 내용을 얼마나 잘 쑤셔박는지'가 더 중요하다는 뜻이다.그래서 나는 아이디어를 떠올렸다.필요한 컨텍스트만 추출하면 매우 쉬울 것이라고.그리고 이미 현실에는 이러한 컨텍스트만 뽑아서 추출하기 위해 설계된 아키텍쳐 구조가 존재한다.Graph DB 베이스의 지식 관리 툴인데, 대부분 엔터프라이즈급 사이즈 이상에서 사용하기 때문에 일반인들이 접할 기회가 적은것이 사실이다.우리에게 익숙한 코드 베이스의 관계형 시각형태를, 마치 GraphDB처럼 보여주는 CodeSee라는 서비스도 있고,혹은 '지금 당장 내가 코딩하는 기능'의 활성도를 동적으로 분석해주는 도구도 있다.이건 나도 이번에 처음 알았는데 신기하지만, 우리같은 해줘충에겐 부적합할 것 같기도?일반적인 사람들이 잘 쓰진 않지만, 코드 베이스들의 연결 구조를 시각화 해 보여주는 GraphDB 기반의 서비스들도 존재한다. ( Sonarsource )대충 위와 같은 서비스를 이용하면, 내가 특정한 기능을 관리/수정/추가 하기 위해서 영향받는 코드베이스가 무엇인지 시각적으로 파악이 가능하다는 뜻이다.그러나 또 문제가 발생한다.눈으로 볼 수는 있다고 하더라도, 아래와 같이 '특정 기능'을 수정하고 싶은데...대체 어디부터 어디까지 긁어야 되는지 범위가 감이 안잡힐 수 있다.그래서 기존 github베이스의 nx affected라는 도구는, 자주 커밋(소스코드 수정)하는 기능의 연결성을 통계 기반으로 분석해주곤 한다.이 정도만 해도 훌륭하긴 한데, 그래도 여전히 아래 기능에는 한가지 허점이 존재한다.'해 줘'를 시전하기 위해서 우리가 만들어야 할 컨텍스트의 연결성을 알아야 하는데, 위와 같은 분석 도구는 정량적 분석만 거의 가능하다.'거의'라는 말을 썼다는건, 추가적인 세팅이 없이는 정량적 연결만 평가한다는 뜻이다.예를들어 아래와 같은 연결 구조가 있다고 하자.1. 인간 - 마실것2. 마실것 - {물, 콜라, 주스, 탄산음료, 탄산수}그럼 상식적으로 물이 제일 중요하지 않은가?하지만 '정량적 연결 평가 기법'에 의해서는 모든 관계가 1:1로 대응 된다.인간의 마실것 <-> 물 : 이것도 1회 연결인간의 마실것 <-> 콜라 : 이것도 1회 연결인간의 마실것 <-> 주스 : 이것도 1회 연결이러한 식인 셈이다.이러한 개념을 결합도(coupling), 응집도(cohesion)라고 부른다.바로 정량적 기반의 연결성 분석 기법이고, 이 것이 현재 대부분의 시멘틱 리서쳐들이 취하는 방식이다.조금의 튜닝은 들어갈 수 있지만, 기본적으로 이 것은 인간의 시각적 분석들 돕기 위한 도구이지, 판단이 들어가 있지는 않다.위와 같이 nx affected같은 도구는 fan-in / fan-out을 기반으로 coupling, cohesion을 보여주는 도구인데...간단하게 연결 계층 깊이(DOI : Depth of Inheritance)를 눈으로 보기엔 좋지만, 해줘충에겐 역시 부적합하다.(아닌가? 이 시점에서 해줘충은 이것만 써도 충분할지도...?)아무튼... 나는 해줘충이 처한 현실이 참 안타깝다고 생각했다.그래서 현재의 정량적 평가 패러미터인결합도 ( Coupling )응집도 ( Cohesion )을 'Yes or No'가 아닌 수치화 될 수 있는 패러미터로 두고,거기에 새로 추가한 개념인 '가정치(Assuming)'를 결과값의 해로 두고자 한다.그러면 세개의 패러미터는 각기 아래와 같은 평가성을 띌 수있다.그래서 해줘충을 위해서 '신뢰도'개념과 '가중치'에 더해 '가정치(Assumed coupling reliability)'라는 개념을 Graph모델에서 보여주기 위해 다중 패러미터 도입을 손쉽게 할 수 있다면 어떨지 생각을 해 보았다.조금 생소할 수도 있는 개념인데, 우리는 무려 AI를 사용하지 않는가?솔직히 도메인한 영역을 던져주면 AI가 우리보다 이제 더 똑똑한데, 이걸 안 쓸 이유가 없지 않은가?결합도(1.0) * 응집도(1.0) * 신규패러미터(1.0) = 가정치(1)결합도(0.7) * 응집도(1.0) * 신규패러미터(0.5) = 가정치(0.35)이제 이러한 모델 가정을 기반으로 클러스터를 나타낼 수 있는 설계를 시작할 수 있는 것이다.아마도 위와 같은 의존성 그래프의 시각화는 물론이고, 그 중 해줘충이 원하는 영역....즉 선택 된 정적 메트릭을 그래픽 메트릭으로 쉽게 산출하는 것이 가능 해 지는 것이다.요약하면,AI에게 '해 줘'시전할 때 필요한걸 눈으로 보고 찍으면 된다는 뜻이다.다음편에서는 이를 기반으로 만든 프로토타입 버전을 들고 올 예정이다.한줄요약 : 근데 40분 지났는데 왜 아직도 딥리서치 안끝남?
작성자 : 아브소고정닉
차단 설정
설정을 통해 게시물을 걸러서 볼 수 있습니다.
[전체 갤러리]
차단 기능을 사용합니다. 차단 등록은 20자 이내, 최대 10개까지 가능합니다.
설정된 갤러리
갤러리 선택
설정할 갤러리를 선택하세요.
[갤러리]
차단 기능을 사용합니다. 전체 설정과는 별개 적용됩니다.
