현이의 개발 이야기

제미나이 2.0은 매우 강력한 성능을 가지고 있다. 현재 2.0은 실험적으로 공개된 상태인데, 다음의 두 모델이 공개되어 있다. 무료 버전인 Gemini 2.0 Flash 유료 버전인 Gemini 2.0 Advanced 제미나이 2,0은 이전 버전에 비해서 자연어 이해는 물론, 코드 생성 능력도 비교할 수 없을 만큼 향상되었다고 느꼈다. 이전 버전의 제미나이는 코드를 생성했다 하면 다음 문제점 중 하나를 가지고 있었다. 컴파일 되지 않는 코드 이전 버전의 코드 원하는 기능이 누락된 코드 제미나이 2.0은 이러한 점들이 대폭 개선되어 몇 번의 코드 생성만으로 거의 모든 원하는 결과를 얻을 수 있게 되었다. 지뢰 찾기 만들기 제미나이 2.0의 향상된 기능을 테스트해보고자 지뢰 찾기를 만들어 보았다. 이번 경험으로 제미나이를 활용한 개발에 대한 감을 잡을 수 있을 것이다. 1. 첫 코드 생성 맨 처음 다음과 같이 살짝 무책임하게 보일 수도 있는 프롬프트를 입력했다. " html / css / js로 지뢰찾기 만들어줘. 제미나이는 index.html, style.css, script.js 파일을 생성해 주었다. 이를 복사해서 넣어봤는데, 아무런 오류가 없었다..! 그리고 실행 화면도 놀라웠다. 상당히 깔끔하게 스타일을 입혀 놓았다. 배경 색과 지뢰 찾기 판의 색, 버튼 색까지 어색하지 않다. 기능도 잘 동작했다. 클릭으로 해당 칸 확인, 우클릭으로 지뢰를 표시할 수 있다. 왼쪽 위에는 첫 클릭 기준으로 게임 플레이 시간이 표시되며, 오른쪽 위에는 찾은 지뢰의 개수가 표시된다. 모든 지뢰를 다 찾으면 게임 승리 창도 띄워준다. 아래 난이도 버튼을 통해서 판의 크기를 조절할 수 있다. Beginner는 9 x 9 칸에서 10개의 지뢰를, Intermediate은 16 x 16 칸에서 40개의 지뢰를, Advanced는 30 x 16 칸에서 99개의 지뢰를 찾아야 한다. (해보니 지뢰가 너무 많은 것 같아 75개로 줄였다) 지뢰도 매번 랜덤으로 심기 때문에 중복 게임이 발생하지 않는다. 2. 지뢰 찾기 판 가운데 정렬 그런데 한 가지 걸리는 것이 있다. 다른 난이도에서는 괜찮은데, Beginner일 때 지뢰 찾기 판이 왼쪽으로 치우쳐져 있다. 이것을 수정해달라고 요청해보자. " Intermediate나 Advanced에서는 지뢰 찾기 판이 가운데 잘 있는데, Beginner에서는 왼쪽으로 치우쳐져있어. 제목이나 버튼 같은 다른 요소들은 괜찮은데 지뢰 찾기 판만 그래. 수정해줘. 제미나이 2.0은 성공적으로 원인을 찾아 수정 사항을 제시해 주었다. \ table { border-collapse: collapse; box-shadow: 0 0 10px rgba(0, 0, 0, 0.3); background-color: #eee; margin: auto; /* 이것을 추가하여 테이블을 중앙에 정렬 */ } 복사하기 편하게 전체 코드도 제공해 주었다. 제시된 수정 사항을 반영하여 다시 실행해보니, 원하는 대로 가운데에 지뢰 찾기 판이 정렬되게 되었다. 휠 클릭으로 인접 칸 열기 지뢰 찾기 게임에는 휠을 클릭하여 주변 지뢰를 모두 찾은 숫자 칸 주변을 자동으로 오픈하는 기능이 있다. 이를 구현하기 위해 다음과 같이 프롬프트를 추가로 입력했다. " 원래 지뢰찾기는 다음과 같은 편의 기능이 있어. "공개된 숫자 칸에 마우스 휠 버튼으로 클릭한 경우, 만약 해당 숫자 칸으로 인한 지뢰에 전부 깃발 표시를 한 상태이면, 해당 숫자 칸 주변의 8칸 중 나머지 칸을 자동으로 클릭하여 오픈." 이 기능을 구현해줘 제미나이는 코드를 뱉었고, 이를 적용해 보았다. 안타깝게도 코드에는 문제가 있었다. 마우스의 휠 클릭이 아니라, 휠을 돌렸을 때 해당 기능이 동작했다. 사실 몇 번 해보니 휠을 클릭하는 것보다 돌리는게 훨씬 편하긴 했지만, 원하던 방향은 아니니 다시 프롬프트를 입력했다. 제미나이는 다음과 같은 대답을 하며 수정된 코드를 알려 주었다. 휠을 "돌렸을 때"가 아닌 "클릭했을 때" 기능이 동작하도록 수정해달라는 요청을 정확히 이해했습니다. wheel 이벤트는 마우스 휠을 스크롤할 때 발생하기 때문에, 휠 클릭을 감지하려면 mousedown 이벤트를 사용하고 event.button 속성을 확인해야 합니다. event.button 값이 1이면 휠 클릭을 의미합니다. script.js에서 다음과 같이 수정합니다. 그리고 이 코드를 적용하니 휠을 클릭했을 때 주변 칸이 열리는 기능이 정상적으로 동작하였다. 3. 제미나이 2.0을 써보니... 제미나이 2.0이 공개되면서 코드 생성 성능 또한 매우 강력해졌다. 이번에 특히 느낀 것은 다음의 네 가지다. 코드에 버그가 없다.물론 완벽히 없을 수는 없겠지만 이번 지뢰 찾기 정도 수준에서는 찾아볼 수 없었다. 코드를 확인하지 않고 그대로 복사 붙여넣기만 했는데도 원하는 기능이 만들어졌다. 기억력이 좋아졌다.여러 차례 대화가 오갔음에도 처음 생성했던 코드 기반으로 업데이트를 해 나갔다. 기능이 추가되면서 수정된 코드나 처음의 코드를 잊어버릴 법 한데 원하는 수정을 다 할 때까지 누락된 것이 없었다. 이해를 잘 한다.내가 원하는 것을 파악하고 코드로 옮겨 주었다. 휠 클릭과 굴리는 것을 혼동하기는 했지만, 기능 자체는 매우 잘 구현하였고, 수정을 요청했을 때 바로 알아듣고 성공적으로 수정하였다. 답변이 길어졌다.이전에는 답변이 조금 길어진다 싶으면 에러를 뱉고 뻗어버리는 경향이 있었는데, 지금은 상당히 긴 답변을 한다. 지뢰 찾기를 작성하면서 부분적으로 코드를 수정할 때에도 수정된 부분을 보여주고, 이어서 전체 코드를 한 번 더 보여주었다. 이렇게 강력해진 제미나이를 활용하면 코드 작성에는 확실히 신경을 덜 쓸 수 있을 것이다. 앞으로 더욱 프로젝트의 방향성과 논리적 사고에 집중하며 실력 있는 개발자로서의 역량을 키워나갈 수 있을 것 같다. 이번에 작성한 지뢰 찾기 코드는 내 깃헙 Playground 리포지토리에서 찾아볼 수 있고, 다음 링크에서 실제로 해볼 수 있다. https://playground.hyuni.dev/minesweeper/

웹 퍼블리셔라는 말을 들어본 적 있을 것이다. 이 용어는 디자인된 페이지를 그대로 HTML / CSS / JS로 옮기는 작업을 하는 사람들을 일컫는다. 얼핏 들으면 프론트엔드 개발자와 같은 역할인 것 같다. 실제로 이러한 인식 때문에 프론트엔드 개발자들이 백엔드 개발자보다 실력 없는 개발자라는 이야기가 많이 있었다. 그러나 웹 개발이 발전해 나감에 따라 웹 퍼블리셔가 없어지고 프론트엔드 개발자가 등장하게 된 데에는 이유가 있다. 이것을 이해하기 위해서는 과거의 웹 개발이 어땠는지 살펴보고, 웹 개발에 획기적인 전환점을 불러일크킨 SPA (Single Page Application)에 대해서 알아볼 필요가 있다. 과거의 웹 개발 전통적인 웹 개발은 백엔드 개발에 많은 부분 얽매여 있었다. 웹 사이트는 여러 개의 HTML 페이지로 구성된 MPA (Multi-Page Application) 형태였으며, 새로운 페이지를 요청할 때마다 서버는 매번 새로운 HTML 파일을 생성하여 브라우저에 전송했다. 즉, 모든 페이지의 렌더링이 서버에서 이루어지는 서버 사이드 렌더링 (Server-Side Rendering) 방식이었다. 이러한 구조에서 Javascript는 주로 폼 유효성 검사나 간단한 시각 효과를 위한 보조적인 역할에 머물렀다. 간혹 api 요청 등 비동기 작업이 있다고 하더라도 대부분의 로직은 서버에서 처리되었기 때문에, 프론트엔드 개발자의 역할은 상대적으로 제한적일 수 밖에 없었다. 과거 웹 개발 방식 (MPA)의 문제점: 느린 페이지 로딩새로운 페이지를 요청할 때마다 전체 페이지를 다시 로드해야 했기 때문에 속도가 느리고 사용자 경험이 좋지 않았다. 아예 새로운 페이지를 로딩하는 것은 감안하더라도, 페이지의 일부분만 업데이트 할 때도 페이지 전체를 새로 로드해야 했다. 높은 서버 부하모든 페이지 요청에 대해 서버가 전체 HTML을 생성해야 하므로, 서버 부하가 높고 많은 양의 데이터가 전송되어야 했다. 제한적인 상호작용사용자와의 상호작용이 많은 웹 애플리케이션을 구현하기 어려웠다. 부드러운 페이지 전환은 불가능했고, Javascript의 비중이 많은 페이지를 개발하는 것도 쉽지 않았다. 복잡한 상태 관리여러 페이지에 걸쳐 애플리케이션의 상태를 관리하는 것이 번거로웠다. SPA의 등장 이러한 문제점을 해결하기 위해 등장한 것이 바로 SPA (Single Page Application) 이다. SPA는 이름 그대로 단 하나의 HTML 페이지를 기반으로 하는 웹 애플리케이션이다. (간혹 여기서 오해하는 경우가 있는데, 개발은 여러 HTML 페이지로 한다. SPA는 이를 webpack으로 묶어 하나의 HTML 파일로 빌드한다.) React.js, Angular, Vue.js와 같은 프레임워크 및 라이브러리가 SPA를 구현하기 위해 대표적으로 사용되며, 최초 로드 시 하나의 HTML 페이지만을 받고, 이후에는 Javascript를 사용하여 동적으로 콘텐츠를 변경하는 클라이언트 사이드 렌더링 (Client-Side Rendering) 방식을 사용한다. SPA는 사용자와의 상호작용에 따라 필요한 데이터만 서버로부터 비동기적으로 가져와(AJAX, Fetch API 등) 화면의 일부분만 업데이트한다. 따라서 전체 페이지를 다시 로드할 필요가 없기 때문에, 훨씬 빠르고 부드러운 사용자 경험을 제공할 수 있다. SPA의 장점 빠르고 반응성 좋은 사용자 경험페이지 전체를 다시 로드하지 않기 때문에, 부드러운 화면 전환과 빠른 반응 속도를 제공한다. 서버 부하 감소필요한 데이터만 요청하고 클라이언트 측에서 렌더링을 수행하기 때문에, 서버 부하를 줄일 수 있다. 코드 재사용성 및 유지보수 용이컴포넌트 기반 아키텍처를 통해 코드의 재사용성을 높이고 유지보수를 쉽게 할 수 있다. SPA의 장점은 그 무엇보다 사용자 경험이 크게 향상된다는 것에 있다. 버튼을 클릭할 때 마다 페이지 전체가 로딩되던 과거와 달리, 버튼을 누르자마자 페이지가 부드럽게 전환되고, 데이터가 로드되면 자연스럽게 보여주는 방식은 SPA를 사용하는 브랜드 자체를 더욱 친근하고 고급스럽게 만들었다. SPA의 대표격인 리액트의 수요가 크게 증가했으며, 단순히 디자인 된 것을 코드로 옮기기만 하는 웹 퍼블리싱보다 더욱 높은 기술적 난이도가 요구되었다. 부드러운 사용자 경험이 안정적인 서비스만큼 중요해지면서 프로젝트에서 Javascript의 비중이 함께 증가했고, 재사용성 높은 컴포넌트를 설계하고 복잡한 프로젝트를 오류 없이 관리해나가는, "엔지니어"의 역량이 필요해진 것이다. 이 때 부터 퍼블리싱 보다는 더욱 사용자와 가까이서 그들을 이해하고, HTML, CSS, Js를 넘어 여러 라이브러리와 프레임워크를 활용하여 알맞는 기술적 솔루션을 구현해내는 프론트엔드 개발자가 등장하기 시작하고, 프론트엔드 기술도 한층 박차를 가해 발전하기 시작했다. SPA의 단점 초기 로딩 속도초기에 모든 Javascript 파일을 로드해야 하기 때문에 초기 로딩 속도가 느릴 수 있다. SEO (검색 엔진 최적화) 문제검색 엔진 크롤러가 Javascript를 실행하지 못하는 경우, 콘텐츠를 제대로 수집하지 못할 수 있다. 대부분의 최근 검색 엔진 크롤러는 SPA를 고려하여 Javascript를 실행한 후, 콘텐츠가 로드되면 크롤링을 한다. 보안클라이언트 측에서 많은 로직이 처리되기 때문에 보안에 더 신경 써야 한다. 높은 사용자 친화적 경험을 제공해서 각광받았던 SPA는 시간이 지남에 따라 그 단점 또한 부각되었다. 대부분의 단점들은 SPA가 발전해나감에 따라 같이 해결되었지만, 기술적 한계로 인해 그렇지 못한 것들도 있다. 초기 로딩 속도 같은 경우, 사이트 전체에서 사용될 코드를 전부 초기 로딩 시에 불러오기 때문에 느릴 수 밖에 없다. 한 번 로드된 이후부터는 매우 빠르게 페이지를 전환할 수 있다는 장점에 대한 트레이드 오프이다. 보안은 각별히 신경써야 한다. 대부분의 로직이 서버에서 돌아가던 과거와 달리, 클라이언트에서 돌아가는 로직은 전부 공개된 것이나 다름 없다. SPA를 구동하기 위한 Javascript는 브라우저에서 실행되어야 하기 때문에 브라우저의 개발자 모드를 열어보면 전부 까볼 수 있다. 난독화 과정을 거치기는 하지만 마음만 먹으면 읽을 수 있기 때문에 안전하다고는 할 수 없다. Javascript에서 사용하는 API 키나 비밀번호 같은 중요한 정보도 모두 공개되기 때문에 중요한 정보는 노출시키지 않도록 세심한 주의가 필요하다. SPA는 분명 장점과 단점을 모두 가지고 있으며, 이러한 단점을 보완하기 위한 차세대 라이브러리와 프레임워크 또한 많이 등장했다. 그러나 사용자에게 더 나은 경험을 제공하고, 개발 생산성을 향상시킬 수 있는 잠재력이 크기 때문에, 현대 웹 개발의 핵심 기술로 자리 잡았다. SPA의 단점을 보완하는 Next.js 등과 같은 프레임워크도 React.js 기반이므로 React.js와 SPA의 장단점을 명확히 파악한다면 Next.js가 어떤 문제를 풀기 위해 탄생했는지, 그로 인해 발생하는 Next.js의 장단점은 무엇인지 또한 자연스럽게 알 수 있을 것이다.

프로그래밍과 글쓰기는 언뜻 비슷하면서도 다른 것 같이 느껴진다. 코드를 쓰는 것과 글을 쓰는 것. 둘 다 무언가를 쓰는 것이기 때문에 비슷한가 하면서도 막상 쓰는 것이 다르기 때문에 별개로 접근해야 하지 않나 싶기도 하다. 그러나 그 본질을 들여다보면 두 행위는 같고, 심지어 개발자라면 글쓰기 연습을 필수적으로 해야 한다고 생각한다. 물론 개발자가 깔끔하고 명확한 문서를 작성하기 위해서는 글쓰기 능력이 필요할 것이다. 하지만 그것보다 더욱 본질적인 세 가지 이유가 있다. 읽는 사람을 생각한다코드와 글은 모두 읽는 사람을 고려해서 작성해야 한다. 단순히 원하는 기능이 작동하기 위해 코드를 쓰거나, 말하고 싶은 내용을 담기만 하는 글쓰기는 이해하기 어렵다. 가독성을 따지기 위해 읽는 사람 입장에서 생각하는 연습을 한다면 좋은 코드나 글을 작성하는 것이 훨씬 쉬워진다. 논리적 근거를 생각한다글을 쓸 때 무언가 주장을 하기 위해서는 근거가 필요하다. 프로그래밍도 어떤 코드를 작성할 때 근거가 필요한다. 한 가지를 구현하더라도, 여러 방법을 비교해보고 장단점을 파악하여 프로젝트 상황에 가장 적합한 것을 논리적 근거와 함께 선택해야 한다. 비판적 사고를 한다."인용"은 글을 쓸 때 이름 있는 사람의 말을 빌려 주장을 뒷받침할 수 있다. 그러나 그 인용이 내가 쓰고 하는 글의 상황에 맞는지를 잘 따져봐야 한다. 프로그래밍도 마찬가지로 공신력 있는 문서의 주장을 근거로 삼기 위해서는 해당 문서의 상황과 현재 프로젝트의 상황이 얼마나 일치하는지를 생각해 봐야 한다. 상황이 다르다면, 해당 문서의 주장은 그저 참고용일 뿐이다. 나중에 이와 관련해서 요즘IT에 글을 써봐야겠다. https://yozm.wishket.com/magazine/@spaceship00/

우리가 프로그래밍을 할 때 많은 자료 구조를 활용하면서 알고있는 각 자료 구조의 연산별 시간 복잡도를 고려하여 코드를 작성한다. 이것만으로 충분히 논리적인 사고를 하고 있다고 할 수 있지만, 사고할 수 있는 영역과 배경 지식을 늘리기 위해서는 해당 자료 구조가 데이터를 어떻게 처리하는지를 추상적으로나마 파악할 수 있어야 한다. 이러한 논리적 사고력은 누구나 차근차근 생각해나가는 훈련만 한다면 익힐 수 있는 것으로, 한 번 논리적으로 사고할 수 있게 된다면 앞으로 겪게 되는 모든 경험을 성장의 밑거름으로 만들 수 있을 것이다. 요즘 IT에 최근에 올린 글이 바로 이러한 논리적 사고 과정을 보여주기 위한 글이다. Set이 왜 필요한지의 목적을 세우는 것으로부터 시작하여, 가장 나이브한 접근에서부터 현재 많은 Set들이 구현되는 방식까지 어떻게 발전되었는지를 하나씩 살펴보았다. 이 글을 읽을 때에는 단계별로 마주치는 한계와 제한사항을 어떻게 해결해나갈 수 있는지를 생각하면서 읽어보자. 자연스럽게 확장성 있고 범용성 있는 자료 구조를 설계할 수 있는 능력을 갖출 수 있게 될 것이다. https://yozm.wishket.com/magazine/detail/2723/