<div id="readability-page-1" class="page"><div tabindex="-1" id="___gatsby"><article><div id="article-body" itemprop="articleBody"><p>내가 처음 인공지능과 조우한 순간은 <a href="/dev/ai-driven-development/">깃헙 코파일럿이 출시되던</a> 시점이었다. 그때 바로 알게됐다. 이거 물건이다. 이건 우릴 드라마틱한 생산성 향상의 천국으로 안내할 호박마차다 싶었다. 그리고 제법 몇년이 지났고 2022년 당시의 인공지능은 오징어로 만들어버리는 기똥한 모델들이 줄지어 출시됐다. 가격은 기하급수적으로 싸졌다. 오죽하면 요즘은 세상에서 제일 싼 게 지능이라는 소리가 나올 정도니 말 다했다. 그럼에도 신기한 사실은 그런 세상이 왔지만 생각외로 생산성 향상은 잘 관찰되지 않는다는 점이다.</p>
<p>과거 왜 생산성 향상이 없을까란 생각에 빠져 주변을 관찰해보면 결과는 사람들이 인공지능을 사용하지 않기 때문이라는 단순한 사실로 귀결됐다. 그래서 처음에는 비싸니까, 돈이 드니까 안쓰나 보다 싶었다. 그리고 이후 쓸만한 무료 인공지능이 많이 출시됐고, 그런 것들의 존재를 알려주었지만 결과는 비슷했다. 아니 미묘하게 달라졌다고 해야 정확할 것 같다. 인공지능을 쓸 때는 쓴다. 다만 생산성 향상을 일으킬 수 있는 많은 문제들에 적극적으로 사용하지 않을 뿐이다. 정리하자면 1) 인공지능의 존재를 알고, 2) 문제를 마주했지만, 3) 생산성 향상이 발생하지 않는 이유 중 대다수는 4) 그 문제를 인공지능에게 물어보지 않기 때문이라는 사실. 뭐 결국 인공지능을 사용하지 않는다는 점은 똑같다. 주요한 차이는 인공지능의 존재를 몰라서 또는 싫어서 사용하지 않는 게 아니라 문제를 문제라고 인식조차 하지 못한다는 데 있다는 것이다.</p>
<p>일본어를 할 줄 모르는 내가 일본어 문서를 읽어야 한다는 상황을 생각해보자. 이 상황은 명확해서 인공지능의 존재를 아는 사람은 응당 인공지능에게 번역을 시킬 것이다. 사실 이런 건 누구나 불편하고 누구나 된다는 걸 알기 때문에 어느 정도 활용이 되고 있는 측면이 많다. 이 상황은 현재 많이 개선되서 이런 종류의 생산성 향상은 많이 관찰된다.</p>
<p>진정한 문제는 문제라고 인식조차 못하는 상황에서 발견된다. 예를들면 이런 상황이다. 1.1, 1.2, 1.3, 1.4, ..., 1.10, 2.1 버전까지 버전이 있다. 그런데 2.1 버전에서 문제가 발생한 걸 알게 되었다. 그 문제가 1.2 버전에서는 없었다는 사실도 과거 기록으로 확인됐다. 1.3 ~ 2.1 사이의 어디에서 문제가 발생했는지 테스트를 해야 하는 상황인 것이다. 이 상황을 마주한 담당자가 취할 수 있는 많은 선택지가 있겠지만 거칠게 두 부류로 나눈다면 A) 1.3버전부터 순차적으로 테스트 하는 사람이 있고, B) 1.7을 먼저 테스트하는 바이너리 서치 식으로 테스트를 하는 사람이 있다. 문제는 바로 옆에 나보다 똑똑하다고 평가 받는 인공지능이 있지만 이걸 인공지능한테 물어봐야지 라는 생각을 A도, B도 둘 다 하지 않는다는 점이다. 이건 내가 해야할 일이지, 내가 풀어야 할 문제라고 인식하지 않기 때문이다.</p>
<p>O(N) 세상에 살고 있는 A가 O(logN) 세상에 사는 B로 업그레이드가 돼야 생산성 향상이 발생한다. 그리고 이건 현재 시중에 나와 있는 조금 괜찮은 인공지능이라면 모두가 적절한 답을 정해줄 것이라 기대된다. 하지만 사람은 묻지 않는다. 아니 이걸 물어봐야 한다고 생각조차 하지 않는다. 그러니 A가 B로 업그레이드 되기는 요원한 것이고, 그러니 현실 세계에서는 생산성 향상이 생각만큼 많이 관찰되지 않는 것이다.</p>
<p>생산성 향상을 위해서 인공지능을 사용합시다, 라는 말에는 상당한 사람이 반감을 가진다. 하지만 같은 연봉으로 근무 시간을 주 40시간에서 30시간으로 단축시킵시다. 하면 쌍수들고 환영하지 반대할 사람은 없을 것이다. 둘은 같은 말인데도 반응이 천지차이라는게 웃픈 현실 아닌가 싶다.</p>
<h2>grok의 복음...</h2>
<blockquote>
<p>1.1, 1.2, 1.3, 1.4, ..., 1.10, 2.1 버전까지 버전이 있다. 그런데 2.1 버전에서 문제가 발생한 걸 알게 되었다. 그 문제가 1.2 버전에서는 없었다는 사실도 과거 기록으로 확인됐다.</p>
<p>이때 어떻게 테스트하는 게 좋은 방법이야.</p>
</blockquote>
<p>라는 질문에 대한 이하 grok의 복음...</p>
<p>주어진 상황에서 소프트웨어 버전 1.1부터 2.1까지 존재하고, 버전 2.1에서 문제가 발생했으며, 버전 1.2에서는 해당 문제가 없었다는 사실을 알게 되었습니다. 문제를 효율적으로 파악하고 해결하기 위해 다음과 같은 테스트 방법을 추천합니다. 이 방법은 이진 탐색(binary search) 기반의 체계적인 접근법을 사용하여 문제의 원인이 처음 나타난 버전을 빠르게 식별하는 것을 목표로 합니다.</p>
<h3>테스트 전략: 이진 탐색을 활용한 버전 테스트</h3>
<ol>
<li>
<p><strong>목표</strong>: 문제가 처음 발생한 버전을 정확히 찾아내기 위해 테스트를 최소화하면서 버전 간 비교를 수행합니다.</p>
</li>
<li>
<p><strong>단계별 접근법</strong>:</p>
<ul>
<li><strong>초기 범위 설정</strong>: 문제가 없는 것으로 확인된 버전 1.2와 문제가 있는 버전 2.1 사이에서 테스트를 진행합니다. 테스트 대상 버전은 1.3, 1.4, ..., 1.10, 2.1입니다.</li>
<li><strong>이진 탐색 적용</strong>:
<ul>
<li>전체 버전 리스트(1.3 ~ 2.1, 총 9개 버전)에서 중간 지점에 가까운 버전을 선택합니다. 예를 들어, 1.7(대략 중간)을 테스트합니다.</li>
<li>버전 1.7에서 문제를 테스트:
<ul>
<li><strong>문제가 있으면</strong>: 문제가 1.3 ~ 1.7 사이에 처음 발생했을 가능성이 있으므로, 이 범위로 범위를 좁힙니다.</li>
<li><strong>문제가 없으면</strong>: 문제가 1.8 ~ 2.1 사이에 발생했을 가능성이 있으므로, 이 범위로 범위를 좁힙니다.</li>
</ul>
</li>
<li>좁혀진 범위에서 다시 중간 지점의 버전을 선택하여 테스트를 반복합니다.</li>
</ul>
</li>
<li><strong>종료 조건</strong>: 문제가 있는 버전과 없는 버전이 인접한 두 버전(예: 1.x와 1.x+1)으로 좁혀질 때까지 반복합니다. 이로써 문제가 처음 도입된 버전을 정확히 식별할 수 있습니다.</li>
</ul>
</li>
<li>
<p><strong>세부 절차</strong>:</p>
<ul>
<li><strong>테스트 환경 준비</strong>: 각 버전을 테스트할 수 있는 일관된 환경(동일한 하드웨어, OS, 데이터 등)을 구축하여 변수 통제를 합니다.</li>
<li><strong>문제 재현</strong>: 버전 2.1에서 확인된 문제를 정확히 재현할 수 있는 테스트 케이스를 준비합니다. 문제의 재현 조건(입력값, 사용자 행동 등)을 명확히 정의합니다.</li>
<li><strong>버전별 테스트</strong>:
<ul>
<li>선택한 버전(예: 1.7)을 설치하고 테스트 케이스를 실행하여 문제가 발생하는지 확인합니다.</li>
<li>결과를 기록하고, 문제 발생 여부에 따라 범위를 반으로 나눠 다음 테스트 버전을 선택합니다.</li>
</ul>
</li>
<li><strong>결과 분석</strong>: 문제가 처음 발생한 버전을 찾은 후, 해당 버전과 직전 버전(문제가 없는 마지막 버전)의 변경 로그, 코드 차이점(diff)을 분석하여 문제의 원인을 추적합니다.</li>
</ul>
</li>
<li>
<p><strong>예시 시나리오</strong>:</p>
<ul>
<li>버전 리스트: [1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 2.1]</li>
<li>1단계: 중간 버전 1.7 테스트
<ul>
<li>문제가 있음 → 다음 범위: 1.3 ~ 1.7</li>
<li>문제가 없음 → 다음 범위: 1.8 ~ 2.1</li>
</ul>
</li>
<li>2단계: 새 범위에서 중간 버전(예: 1.5 또는 1.9) 테스트
<ul>
<li>이 과정을 반복하여 범위를 좁힙니다.</li>
</ul>
</li>
<li>최종적으로 문제가 1.9에서 없고 1.10에서 처음 발생했다고 가정하면, 1.10의 변경 사항을 분석합니다.</li>
</ul>
</li>
<li>
<p><strong>효율성</strong>:</p>
<ul>
<li>이진 탐색 방식은 최대 약 log₂(9) ≈ 4번의 테스트로 문제의 원인이 된 버전을 찾을 수 있습니다(최악의 경우).</li>
<li>무작위로 모든 버전을 테스트하는 대신 체계적으로 범위를 줄여 시간과 자원을 절약합니다.</li>
</ul>
</li>
<li>
<p><strong>추가 고려사항</strong>:</p>
<ul>
<li><strong>변경 로그 확인</strong>: 가능하다면 각 버전의 변경 로그를 미리 검토하여 코드 변경, 새 기능 추가, 버그 수정 등을 파악하면 문제 원인을 좁히는 데 도움이 됩니다.</li>
<li><strong>자동화 테스트</strong>: 문제가 명확히 재현 가능한 경우, 자동화된 테스트 스크립트를 작성하여 각 버전에서 빠르게 테스트할 수 있습니다.</li>
<li><strong>병렬 테스트</strong>: 리소스가 충분하다면, 여러 버전을 병렬로 테스트하여 시간을 단축할 수 있습니다(예: 1.5와 1.9를 동시에 테스트).</li>
<li><strong>환경 일관성</strong>: 버전 간 차이로 인한 오탐지를 피하기 위해 테스트 환경을 항상 동일하게 유지합니다.</li>
</ul>
</li>
<li>
<p><strong>다음 단계</strong>:</p>
<ul>
<li>문제가 처음 발생한 버전을 찾은 후, 해당 버전에서 추가된 기능, 수정된 코드, 또는 종속성 변경(라이브러리 업데이트 등)을 분석합니다.</li>
<li>코드 디버깅, 로그 분석, 또는 단위 테스트를 통해 문제의 근본 원인을 파악합니다.</li>
<li>필요하면 개발 팀과 협력하여 수정 패치를 개발하고, 문제가 해결되었는지 확인하기 위해 후속 버전(예: 2.2)에서 테스트합니다.</li>
</ul>
</li>
</ol>
<h3>주의점</h3>
<ul>
<li><strong>문제 재현성</strong>: 테스트 케이스가 2.1에서 문제를 확실히 재현할 수 있는지 확인하세요. 재현이 불확실하면 결과가 왜곡될 수 있습니다.</li>
<li><strong>버전 간 종속성</strong>: 일부 버전은 특정 라이브러리나 환경 설정이 달라질 수 있으므로, 설치 시 오류가 발생하지 않도록 주의하세요.</li>
<li><strong>문서화</strong>: 각 테스트 결과를 상세히 기록(버전, 문제 발생 여부, 테스트 조건 등)하여 추후 분석에 활용하세요.</li>
</ul>
<h3>결론</h3>
<p>이진 탐색 기반의 테스트 전략은 최소한의 테스트로 문제를 처음 도입한 버전을 효율적으로 찾을 수 있는 방법입니다. 버전 1.7을 시작으로 테스트를 진행하고, 결과를 바탕으로 범위를 좁혀가며 문제를 식별하세요. 문제가 발생한 버전을 찾은 후에는 변경 로그와 코드를 분석하여 원인을 파악하고 해결 방안을 마련하면 됩니다. 추가 질문이 있다면 말씀해주세요!</p></div><div id="bio"><p>돌아보니 좋은 날도 있었고, 나쁜 날도 있었다. 그런 나의 모든 소소한 일상과 배움을 기록한다. 여기에 기록된 모든 내용은 한 개인의 관점이고 의견이다. 내가 속한 조직과는 1도 상관이 없다.</p></div></article></div></div>

YoungJin Shin

내가 처음 인공지능과 조우한 순간은 깃헙 코파일럿이 출시되던 시점이었다. 그때 바로 알게됐다. 이거 물건이다. 이건 우릴 드라마틱한 생산성 향상의 천국으로 안내할 호박마차다 싶었다. 그리고 제법 몇년이 지났고 2022년 당시의 인공지능은 오징어로 만들어버리는 기똥한 모델들이 줄지어 출시됐다. 가격은 기하급수적으로 싸졌다. 오죽하면 요즘은 세상에서 제일 싼 게 지능이라는 소리가 나올 정도니 말 다했다. 그럼에도 신기한 사실은 그런 세상이 왔지만 생각외로 생산성 향상은 잘 관찰되지 않는다는 점이다.
과거 왜 생산성 향상이 없을까란 생각에 빠져 주변을 관찰해보면 결과는 사람들이 인공지능을 사용하지 않기 때문이라는 단순한 사실로 귀결됐다. 그래서 처음에는 비싸니까, 돈이 드니까 안쓰나 보다 싶었다. 그리고 이후 쓸만한 무료 인공지능이 많이 출시됐고, 그런 것들의 존재를 알려주었지만 결과는 비슷했다. 아니 미묘하게 달라졌다고 해야 정확할 것 같다. 인공지능을 쓸 때는 쓴다. 다만 생산성 향상을 일으킬 수 있는 많은 문제들에 적극적으로 사용하지 않을 뿐이다. 정리하자면 1) 인공지능의 존재를 알고, 2) 문제를 마주했지만, 3) 생산성 향상이 발생하지 않는 이유 중 대다수는 4) 그 문제를 인공지능에게 물어보지 않기 때문이라는 사실. 뭐 결국 인공지능을 사용하지 않는다는 점은 똑같다. 주요한 차이는 인공지능의 존재를 몰라서 또는 싫어서 사용하지 않는 게 아니라 문제를 문제라고 인식조차 하지 못한다는 데 있다는 것이다.
일본어를 할 줄 모르는 내가 일본어 문서를 읽어야 한다는 상황을 생각해보자. 이 상황은 명확해서 인공지능의 존재를 아는 사람은 응당 인공지능에게 번역을 시킬 것이다. 사실 이런 건 누구나 불편하고 누구나 된다는 걸 알기 때문에 어느 정도 활용이 되고 있는 측면이 많다. 이 상황은 현재 많이 개선되서 이런 종류의 생산성 향상은 많이 관찰된다.
진정한 문제는 문제라고 인식조차 못하는 상황에서 발견된다. 예를들면 이런 상황이다. 1.1, 1.2, 1.3, 1.4, ..., 1.10, 2.1 버전까지 버전이 있다. 그런데 2.1 버전에서 문제가 발생한 걸 알게 되었다. 그 문제가 1.2 버전에서는 없었다는 사실도 과거 기록으로 확인됐다. 1.3 ~ 2.1 사이의 어디에서 문제가 발생했는지 테스트를 해야 하는 상황인 것이다. 이 상황을 마주한 담당자가 취할 수 있는 많은 선택지가 있겠지만 거칠게 두 부류로 나눈다면 A) 1.3버전부터 순차적으로 테스트 하는 사람이 있고, B) 1.7을 먼저 테스트하는 바이너리 서치 식으로 테스트를 하는 사람이 있다. 문제는 바로 옆에 나보다 똑똑하다고 평가 받는 인공지능이 있지만 이걸 인공지능한테 물어봐야지 라는 생각을 A도, B도 둘 다 하지 않는다는 점이다. 이건 내가 해야할 일이지, 내가 풀어야 할 문제라고 인식하지 않기 때문이다.
O(N) 세상에 살고 있는 A가 O(logN) 세상에 사는 B로 업그레이드가 돼야 생산성 향상이 발생한다. 그리고 이건 현재 시중에 나와 있는 조금 괜찮은 인공지능이라면 모두가 적절한 답을 정해줄 것이라 기대된다. 하지만 사람은 묻지 않는다. 아니 이걸 물어봐야 한다고 생각조차 하지 않는다. 그러니 A가 B로 업그레이드 되기는 요원한 것이고, 그러니 현실 세계에서는 생산성 향상이 생각만큼 많이 관찰되지 않는 것이다.
생산성 향상을 위해서 인공지능을 사용합시다, 라는 말에는 상당한 사람이 반감을 가진다. 하지만 같은 연봉으로 근무 시간을 주 40시간에서 30시간으로 단축시킵시다. 하면 쌍수들고 환영하지 반대할 사람은 없을 것이다. 둘은 같은 말인데도 반응이 천지차이라는게 웃픈 현실 아닌가 싶다.
grok의 복음...
1.1, 1.2, 1.3, 1.4, ..., 1.10, 2.1 버전까지 버전이 있다. 그런데 2.1 버전에서 문제가 발생한 걸 알게 되었다. 그 문제가 1.2 버전에서는 없었다는 사실도 과거 기록으로 확인됐다.
이때 어떻게 테스트하는 게 좋은 방법이야.
라는 질문에 대한 이하 grok의 복음...
주어진 상황에서 소프트웨어 버전 1.1부터 2.1까지 존재하고, 버전 2.1에서 문제가 발생했으며, 버전 1.2에서는 해당 문제가 없었다는 사실을 알게 되었습니다. 문제를 효율적으로 파악하고 해결하기 위해 다음과 같은 테스트 방법을 추천합니다. 이 방법은 이진 탐색(binary search) 기반의 체계적인 접근법을 사용하여 문제의 원인이 처음 나타난 버전을 빠르게 식별하는 것을 목표로 합니다.
테스트 전략: 이진 탐색을 활용한 버전 테스트
목표: 문제가 처음 발생한 버전을 정확히 찾아내기 위해 테스트를 최소화하면서 버전 간 비교를 수행합니다.
단계별 접근법:
초기 범위 설정: 문제가 없는 것으로 확인된 버전 1.2와 문제가 있는 버전 2.1 사이에서 테스트를 진행합니다. 테스트 대상 버전은 1.3, 1.4, ..., 1.10, 2.1입니다.
이진 탐색 적용:
전체 버전 리스트(1.3 ~ 2.1, 총 9개 버전)에서 중간 지점에 가까운 버전을 선택합니다. 예를 들어, 1.7(대략 중간)을 테스트합니다.
버전 1.7에서 문제를 테스트:
문제가 있으면: 문제가 1.3 ~ 1.7 사이에 처음 발생했을 가능성이 있으므로, 이 범위로 범위를 좁힙니다.
문제가 없으면: 문제가 1.8 ~ 2.1 사이에 발생했을 가능성이 있으므로, 이 범위로 범위를 좁힙니다.
좁혀진 범위에서 다시 중간 지점의 버전을 선택하여 테스트를 반복합니다.
종료 조건: 문제가 있는 버전과 없는 버전이 인접한 두 버전(예: 1.x와 1.x+1)으로 좁혀질 때까지 반복합니다. 이로써 문제가 처음 도입된 버전을 정확히 식별할 수 있습니다.
세부 절차:
테스트 환경 준비: 각 버전을 테스트할 수 있는 일관된 환경(동일한 하드웨어, OS, 데이터 등)을 구축하여 변수 통제를 합니다.
문제 재현: 버전 2.1에서 확인된 문제를 정확히 재현할 수 있는 테스트 케이스를 준비합니다. 문제의 재현 조건(입력값, 사용자 행동 등)을 명확히 정의합니다.
버전별 테스트:
선택한 버전(예: 1.7)을 설치하고 테스트 케이스를 실행하여 문제가 발생하는지 확인합니다.
결과를 기록하고, 문제 발생 여부에 따라 범위를 반으로 나눠 다음 테스트 버전을 선택합니다.
결과 분석: 문제가 처음 발생한 버전을 찾은 후, 해당 버전과 직전 버전(문제가 없는 마지막 버전)의 변경 로그, 코드 차이점(diff)을 분석하여 문제의 원인을 추적합니다.
예시 시나리오:
버전 리스트: [1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 2.1]
1단계: 중간 버전 1.7 테스트
문제가 있음 → 다음 범위: 1.3 ~ 1.7
문제가 없음 → 다음 범위: 1.8 ~ 2.1
2단계: 새 범위에서 중간 버전(예: 1.5 또는 1.9) 테스트
이 과정을 반복하여 범위를 좁힙니다.
최종적으로 문제가 1.9에서 없고 1.10에서 처음 발생했다고 가정하면, 1.10의 변경 사항을 분석합니다.
효율성:
이진 탐색 방식은 최대 약 log₂(9) ≈ 4번의 테스트로 문제의 원인이 된 버전을 찾을 수 있습니다(최악의 경우).
무작위로 모든 버전을 테스트하는 대신 체계적으로 범위를 줄여 시간과 자원을 절약합니다.
추가 고려사항:
변경 로그 확인: 가능하다면 각 버전의 변경 로그를 미리 검토하여 코드 변경, 새 기능 추가, 버그 수정 등을 파악하면 문제 원인을 좁히는 데 도움이 됩니다.
자동화 테스트: 문제가 명확히 재현 가능한 경우, 자동화된 테스트 스크립트를 작성하여 각 버전에서 빠르게 테스트할 수 있습니다.
병렬 테스트: 리소스가 충분하다면, 여러 버전을 병렬로 테스트하여 시간을 단축할 수 있습니다(예: 1.5와 1.9를 동시에 테스트).
환경 일관성: 버전 간 차이로 인한 오탐지를 피하기 위해 테스트 환경을 항상 동일하게 유지합니다.
다음 단계:
문제가 처음 발생한 버전을 찾은 후, 해당 버전에서 추가된 기능, 수정된 코드, 또는 종속성 변경(라이브러리 업데이트 등)을 분석합니다.
코드 디버깅, 로그 분석, 또는 단위 테스트를 통해 문제의 근본 원인을 파악합니다.
필요하면 개발 팀과 협력하여 수정 패치를 개발하고, 문제가 해결되었는지 확인하기 위해 후속 버전(예: 2.2)에서 테스트합니다.
주의점
문제 재현성: 테스트 케이스가 2.1에서 문제를 확실히 재현할 수 있는지 확인하세요. 재현이 불확실하면 결과가 왜곡될 수 있습니다.
버전 간 종속성: 일부 버전은 특정 라이브러리나 환경 설정이 달라질 수 있으므로, 설치 시 오류가 발생하지 않도록 주의하세요.
문서화: 각 테스트 결과를 상세히 기록(버전, 문제 발생 여부, 테스트 조건 등)하여 추후 분석에 활용하세요.
결론
이진 탐색 기반의 테스트 전략은 최소한의 테스트로 문제를 처음 도입한 버전을 효율적으로 찾을 수 있는 방법입니다. 버전 1.7을 시작으로 테스트를 진행하고, 결과를 바탕으로 범위를 좁혀가며 문제를 식별하세요. 문제가 발생한 버전을 찾은 후에는 변경 로그와 코드를 분석하여 원인을 파악하고 해결 방안을 마련하면 됩니다. 추가 질문이 있다면 말씀해주세요!

[소고] 인공지능이 생산성 향상으로 이어지지 않는 이유 1

댓글