Video: 🚨 AI가 만든 앱은 왜 꼭 여기서 망가질까?
Channel: 노마드 코더 Nomad Coders
Duration: 7m 17s
Source: subtitle (auto, ko)
Transcript:
여러분의 앱을 포함하여 5개 이상의 코드로 작성된 모든 앱에는 이 두 가지 버그가 있으며, 이는 AI가 심어놓은 것입니다 . 얼마 전, 저는 개발자들이 대체되는 것이 아니라, 개발자라는 직업 자체가 변화하고 있다는 주장을 펼쳤습니다. 이제 더 이상 코드를 작성할 필요가 없습니다. 인공지능이 작성합니다. 자, 이제 여러분의 임무는 그것을 이해하고 검토하는 것입니다. 이해하지 못하는 것을 복습할 수는 없습니다. 그런데 여기서 함정이 있습니다. 만약 그것을 표현할 단어가 없다면, 인공지능에게 수정을 요청할 수 없습니다. 벌레가 보이지도 않아요. 사고는 인공지능에 맡길 수 있지만, 이해력은 맡길 수 없습니다. 그래서 오늘은 이 두 가지 버그를 식별하는 방법과 버그가 발생하는 이유, 그리고 예방 방법을 배우겠습니다 . 첫 번째 문제인 레이스 컨디션부터 시작해 보겠습니다. 다음은 간단한 함수 코드입니다. 사용자가 티켓을 구매하려고 합니다 . 남은 티켓 수를 확인했습니다. 하나라도 있으면 하나를 빼서 순서를 만듭니다. 이것은 당신과 내가 작성할 수 있는 코드이고, 인공지능은 항상 음악을 작곡합니다.

겉보기엔 멀쩡해 보이지만, 고장난 상태이고 노트북에 끼워 넣으면 안 돼요 음악 티켓이 딱 한 장 남았는데, 앨리스와 밥, 두 사람이 그 티켓을 원한다고 상상해 보세요. 앨리스는 먼저 구매 버튼을 클릭합니다 . 앨리스의 코드는 주식을 읽습니다. 주식은 그중 하나입니다. 주가를 읽고 1을 빼면 차이가 발생합니다. 음악이 10밀리초 정도 지속될 때도 있고, 더 길어질 때도 있습니다. 밥의 코드가 실행되기에 충분한 시간이었다. 밥의 코드는 주식도 읽습니다 . 앨리스가 아직 아무것도 빼지 않았기 때문에 주식은 여전히 ​​1입니다 . 이제 밥과 앨리스는 모두 주식을 1로 간주합니다. 앨리스는 1을 빼서 주문을 만듭니다. 밥도 1을 빼고, 자신만의 순서를 만듭니다. 당신은 방금 같은 티켓을 두 사람에게 팔았습니다. 현재 재고는 0이지만, 주문 건수는 하나인데 주문이 두 건 있습니다. 그리고 그것은 경쟁 조건입니다. 두 개의 코드가 동일한 데이터를 놓고 경쟁하고 있습니다. 동시에 읽기도 하고 동시에 쓰기도 한다. 둘 다 서로의 존재를 모른다.

그리고 여기서부터 마음이 아프죠. 이 버그는 컴퓨터에서 전혀 나타나지 않습니다. 왜냐하면 컴퓨터에서는 사용자 한 명(음악)이 탭 한 곳에서 버튼 하나만 클릭하는 상황이기 때문입니다. 실제 사용자에게 제품을 배송하고 두 사용자가 동시에 구매 버튼을 클릭하기 전까지는 이러한 결과를 재현할 수 없습니다 문제가 생겼네요. 거기에는 또 다른 버그 , 즉 부분 쓰기 오류가 있습니다. 이 두 줄을 보세요. 첫 번째 시도는 성공했지만 두 번째 시도는 실패하면 어떻게 될까요? 데이터베이스 연결이 끊어지고, 서버가 다운되고, [음악] 뭐든지. 재고는 하나 줄었지만, 그에 따른 주문은 없습니다. 티켓이 사라졌어요. 아무도 사지 않았어요. 부분적인 작성입니다. 작전의 절반은 성공했고, 절반은 실패했다. 자, 그럼 이 문제를 해결해 봅시다. 두 가지 버그가 있습니다. 하나는 경쟁 조건 문제이고 다른 하나는 부분 쓰기 문제입니다. 세 가지 개념이 있습니다. 각각은 이 문제의 일부를 해결합니다. 첫 번째 단어는 원자적 연산입니다. 이것을 자세히 살펴보세요.

이제 우리는 주식 시세를 읽지 않는다는 점에 주목하세요. 제대로 작동하지 않는 버전에서는 세 가지 작업을 했습니다. 우리는 주식 정보를 읽고, 파이썬으로 확인한 다음, 결과를 다시 저장했습니다. 세 단계, 두 번의 [음악] 여정을 통해 데이터베이스에 접근합니다. 그 틈으로 밥이 들어갔습니다 . 이 버전에서는 한 가지 일만 합니다. 데이터베이스에 한 줄을 전송합니다. 재고량이 0보다 클 경우에만 재고량에서 1을 뺍니다. 데이터베이스는 읽기, 확인 및 빼기 작업을 모두 한 단계에서 수행합니다. 그리고 데이터베이스는 동일한 [음악] 행에 대해 한 번에 이 중 하나만 수행할 수 있습니다 . 앨리스가 매수 버튼을 클릭하면 그녀의 업데이트가 먼저 실행되고 주가는 0이 됩니다. 밥이 매수 버튼을 클릭하고 , 업데이트가 실행되지만 재고는 0이 되고, 위치 조회가 실패하여 아무 일도 일어나지 않습니다 . 앨리스는 티켓을 받았고, 밥은 받지 못했다. 그러면 경쟁 조건이 해결됩니다 . 하지만 한 가지 주목할 점은 두 번째 버그가 여전히 남아 있다는 것입니다.

이 회선에 문제가 생기면 어떻게 되나요? 재고는 이미 차감되었고 업데이트도 완료되었지만 주문이 생성되지 않았습니다. [음악] 부분 작곡. 원자 연산으로는 그 문제를 해결할 수 없습니다 . 그러려면 두 번째 단어, 즉 데이터베이스 [음악] 거래가 필요합니다. 거래는 래퍼(wrapper, 포장재)입니다. 그 안에 여러 작업을 넣으면 데이터베이스는 모든 작업이 동시에 성공하거나, 아니면 아무 작업도 수행되지 않도록 보장합니다. 우리는 우리의 운영을 거래라는 틀 안에 담아 처리합니다. 주문 생성에 실패하면 거래가 롤백됩니다. 롤백이란 데이터베이스 내에서 우리가 했던 모든 변경 사항을 되돌리는 것을 의미합니다 . 주가는 마치 아무 일도 없었던 것처럼 다시 1로 돌아갑니다 . 그것은 데이터베이스 트랜잭션입니다. 전량 아니면 전무. 이제 두 가지 버그 모두에 대한 해결책을 찾았지만, 한 가지 상황이 더 남아 있습니다. 때로는 모든 내용을 하나의 업데이트에 담을 수 없을 때도 있습니다 . 때로는 재고를 확인하고 , 예약하고, 할인을 적용한 다음 업데이트해야 합니다.

그러려면 세 번째 단어인 로우 락이 필요합니다. 행 잠금은 트랜잭션 내부에서 사용하는 도구입니다. 이는 데이터베이스에 "내가 작업을 마칠 때까지 이 행을 보류하고 아무도 건드릴 수 없도록 하라 "고 지시하는 것입니다. 방금 우리가 알게 된 거래 내용입니다. 새로운 부분은 업데이트용입니다. 업데이트해 주셔서 감사합니다. 앨리스가 이 코드를 실행하면 데이터베이스에서 그녀의 티켓 행이 잠깁니다. 할인 적용 중에는 해당 행이 잠금 상태로 유지됩니다. 밥이 같은 행을 읽으려고 하면 데이터베이스는 그에게 대기 시간을 줍니다. 앨리스가 끝낼 때까지 그는 글을 읽거나 쓸 수 없다. 그러다 밥이 주식 가격을 확인할 차례가 되는데, 주가는 0이고 밥은 아무것도 하지 않는다. 인종 차별도 없고, 편파적인 글쓰기도 없습니다. 세 단어로 요약하자면, 원자적 연산은 하나의 명령만으로 충분할 때 경쟁 조건을 해결합니다. 트랜잭션은 부분 쓰기 문제를 해결하고, 행 잠금은 여러 문장이 있을 때 발생하는 경쟁 조건을 해결합니다 . [음악] 정확한 코드는 언어와 라이브러리에 따라 다르지만, 개념은 동일합니다.

이제 인공지능에게 그 어떤 질문이든 할 수 있습니다. 어휘에 세 가지 개념을 추가하세요 . 그리고 수정된 코드를 보세요. 경쟁 조건 문제도 없고, 부분적인 권한 문제도 없지만, 여전히 버그가 하나 더 있습니다. 이 코드는 아이템 효능이 없습니다. 상상해 보세요, [음악] 앨리스가 구매 버튼을 클릭합니다. 함수는 실행되지만 네트워크 속도가 느립니다. 그녀의 브라우저는 계속 로딩 중입니다. 그녀는 클릭이 실패했다고 생각해서 다시 구매 버튼을 클릭합니다. 이제 브라우저는 [음악] 서버로 두 개의 요청을 보냅니다. 둘 다 티켓을 구매하라고 전화합니다. 둘 다 처음부터 끝까지 이어집니다 . 둘 다 질서를 만들어냅니다. 앨리스는 티켓을 한 장만 원했는데, 두 장을 발부받았다. [음악] 그녀는 자기가 요청한 적도 없는 티켓 두 장을 가지고 있어요. 이것이 바로 아이템 효능이 전혀 없는 모습입니다. 아이템 효능이란 어떤 아이템을 한 번 사용하든, 50번 사용하든 결과는 동일하다는 것을 의미합니다. 엘리베이터 버튼처럼요. 버튼을 한 번 누르면 엘리베이터가 옵니다.

50번 밀어도 엘리베이터는 여전히 온다. 저희 티켓 구매 방식은 그렇지 않습니다. 중복 요청, 중복 구매. 그리고 이는 단지 참을성이 부족한 사용자들만의 문제가 아닙니다. 휴대전화 연결이 끊어지거나, 앱이 실패한 요청을 재시도하거나 , 결제 플랫폼이 웹훅을 재시도하는 경우입니다 . [음악] 동일한 의도가 서버에 여러 번 도달했고, 당신은 여러 번 수락했습니다. 이제 문제가 생겼네요. 그렇다면 이 문제를 어떻게 해결해야 할까요? 함수에 메모리를 할당해야 합니다. 중복된 [음악] 요청을 식별하는 방법 . 이 패턴은 아이템 효능 키라고 불립니다. 아이디어는 간단합니다. 사용자가 구매를 시작할 때마다 프런트엔드에서 고유 ID가 생성됩니다. [음악] 임의의 문자열을 생성하고, 해당 ID를 요청과 함께 전송합니다 . 요청이 실패하고 앱이 재시도하는 경우, 동일한 ID를 전송합니다. 사용자가 더블 클릭하면 브라우저는 동일한 ID를 다시 보냅니다. 의도는 같습니다. [음악] 제 의도도 같습니다. 서버는 해당 ID를 메모리로 사용합니다.

ID가 처음 도착하면 함수를 실행하고 결과를 ID와 함께 저장합니다. 그리고 동일한 ID가 다시 도착하면 함수를 실행하지 않고 저장된 결과를 반환합니다 . 이제 해당 함수는 멱 등성 키를 매개변수로 받습니다. [음악] 우리가 제일 먼저 하는 일은 이 키를 전에 본 적이 있는지 확인하는 것입니다 . 만약 캐시된 결과가 있다면, 캐시된 결과를 반환합니다 . 우리는 해당 함수를 다시 실행하지 않습니다 . 만약 키를 찾지 못했다면 이전과 마찬가지로 함수를 실행하지만, 마지막에 [음악] 키를 포함하여 결과를 저장합니다 . 그래서 다음에 같은 열쇠가 도착하면, 우리는 그 기억을 활용할 수 있습니다. 자, 이제 앨리스가 다시 더블클릭하는 상황을 상상해 보세요. 먼저, 멱 등성 키 ABC 123을 전송합니다. 서버는 해당 기능을 실행하여 주문을 생성하고 결과를 키 ABC 123과 함께 저장합니다. 두 번째 클릭도 동일한 구매이므로 동일한 키 ABC 123을 사용합니다 . 서버는 메모리에서 ABC 123을 확인하고, 실행하지 않고 저장된 결과를 반환합니다.

한 번 구매로 한 장의 티켓만 발급되며, 중복 구매는 불가합니다. 이제 해당 함수는 멱등성을 갖습니다. 한 번 호출하든, 같은 키로 50번 호출하든 결과는 동일합니다. 이 패턴은 정말 중요합니다. 온라인 결제를 해본 적이 있다면, 해당 요청에는 멱등성 키가 포함되어 있었을 것입니다 채팅 앱에서 메시지를 보내본 적이 있다면, 그런 기능도 있었을 겁니다. 당신은 그들을 보지 못했지만, 그들은 거기에 있었습니다. 기본적으로 함수를 두 번 실행했을 때 문제가 발생하지 않도록 하려면 함수가 멱등성을 갖도록 만들어야 합니다 주문 생성, 메시지 전송, 카드 결제 등 요청 횟수와 관계 없이 한 번만 실행되어야 하는 모든 작업 . 이것으로 바이트 코더를 위한 개념 시리즈 1화가 끝났습니다. 마음에 드셨다면 댓글로 알려주세요. 인공지능이 여러분에게 설명해주고 싶은 개념들이 너무나 많습니다 . 뮤텍스, 해시맵, 데이터베이스 인덱스, 캐시 무효화. " 바이트 코더를 위한 개념" 시리즈를 원하시면 알려주세요. 알았어, 그럼 이제 갈게.

제가 메시지를 보내겠습니다. 다음 영상에서 만나요. 모두 안녕히 계세요. 안녕.