AI가 개발자를 대체한다? 현업에서 보면 전혀 다른 이야기

 요즘 AI 관련 광고를 보면 공통된 메시지가 있다. “이제 개발자 필요 없다” “AI가 대신 다 만들어준다” 처음 보면 맞는 말처럼 들린다. 코드도 만들어주고, 수정도 해주고, 심지어 앱도 만든다고 한다. 그런데 실제 개발 현장에서 보면 이야기가 완전히 다르다. AI는 분명히 빠르다. 간단한 기능이나 화면 정도는 금방 만들어준다. 검색보다 빠르고, 기본 코드 작성도 훨씬 편해졌다. 문제는 그 다음이다. 실제 서비스는 단순히 “코드가 돌아간다”로 끝나지 않는다. 로그인, 결제, 데이터 처리, 오류 대응까지 들어가는 순간 상황이 완전히 달라진다. 예를 들어 이런 경우가 있다. 기능은 정상적으로 동작하는데 특정 상황에서만 데이터가 저장되지 않는다. 또는 결제는 됐는데 DB에는 기록이 안 남는다. 이런 문제는 AI가 해결해주지 않는다. 오히려 원인을 찾는데 더 시간이 걸리는 경우도 많다. 그리고 더 중요한 건 따로 있다. 고객은 “코드”를 원하는 게 아니다. “문제가 없는 서비스”를 원한다. AI는 코드를 만들어준다. 하지만 구조를 설계하고, 예외를 고려하고, 문제가 생겼을 때 책임지는 건 사람이 해야 한다. 그래서 현업에서는 이렇게 말한다. AI는 도구다. 좋은 도구인 건 맞지만, 개발자를 대체하는 수준은 아니다. 오히려 반대다. AI 덕분에 개발 속도는 빨라졌지만 검수와 안정성의 중요성은 더 커졌다. 결국 개발자의 역할은 사라지는 게 아니라 조금씩 바뀌고 있다. 코드를 직접 다 치는 사람이 아니라 전체를 이해하고 문제를 해결하는 사람이 더 중요해지는 방향이다. 정리하면 이렇다. AI는 코드를 만들어준다. 하지만 서비스를 완성하는 건 여전히 사람이다.

“AI로 앱 하루 만에 만든다고? 직접 해본 개발자 후기”

 AI로 앱을 하루 만에 만들 수 있다고 해서 직접 해봤다. 결론부터 말하면, 가능은 하다. 근데 우리가 생각하는 ‘앱 개발’이랑은 완전히 다르다. 요즘 유튜브 보면 AI 앱 개발 영상이 넘쳐난다. 챗GPT 개발만으로 서비스 하나가 뚝딱 만들어지는 것처럼 보인다. 비개발자도 하루 만에 앱을 만든다고 한다. 여기까지는 틀린 말은 아니다. 간단한 기능 하나 정도는 진짜 금방 된다. 버튼 누르면 텍스트 바뀌는 거, 이미지 교체하는 거 이 정도는 AI 도움 없어도 30분이면 끝난다. 문제는 그 다음부터다. 실제 서비스는 버튼 하나로 끝나지 않는다. 회원가입, 로그인, 데이터 저장, 결제, 오류 처리 이걸 하나 씩 붙이기 시작하면 상황이 완전히 달라진다. 특히 결제 붙이는 순간부터 난이도가 확 올라간다. 테스트 결제, 취소, 재결제, 실패 케이스까지 한 번 제대로 돌려보면 “하루 만에 개발”이라는 말이 얼마나 단순화된 건지 바로 느껴진다. 예전에 이런 적도 있다. 테스트 결제 몇 번 돌리다가 승인은 됐는데 DB에 값이 안 찍히는 상황이 있었다. 로그 뒤지면서 원인 찾는데만 2시간 날렸다. 이런 건 AI가 대신 해결해주지 않는다. AI는 코드를 만들어준다. 그런데 그 코드가 실제 환경에서 바로 정상 동작하는지는 완전히 다른 문제다. 그리고 더 중요한 건 따로 있다. AI로 앱 만들기에서 가장 어려운 건 코드가 아니라 “구조”다. 어떤 흐름으로 만들지 어디서 오류가 날 수 있는지 사용자가 어디서 막힐지 이건 사람이 직접 경험해보고 설계해야 한다. AI는 방향을 잡아주지 않는다. 그냥 시키는 대로 만들어줄 뿐이다. 그래서 요즘 AI 개발 광고 보면 솔직히 좀 과하게 느껴진다. 틀린 말은 아닌데 중요한 부분은 다 빠져 있다. 정리하면 이렇다. 간단한 기능 → AI로 빠르게 가능 실제 서비스 → 여전히 사람 손 많이 간다 AI 앱 개발이 개발 속도를 올려준 건 맞다. 하지만 개발 자체가 쉬워졌다고 보...

“location.href vs replace 차이 때문에 삽질한 이야기”

 하이브리드 앱을 개발하면서 단순한 페이지 이동 로직을 만들었다. 버튼을 누르면 location.href 로 다른 페이지로 이동하고, 이전 버튼을 누르면 다시 돌아오는 구조였다. 웹에서는 이전 버튼을 자주 사용하지 않기 때문에 이 부분을 깊게 테스트 해 본적이 없다. 그런데 하이브리드 앱(WebView)에서 테스트하는 순간 문제가 바로 드러났다. 뒤로가기를 누르면 이전 페이지로 돌아가는 것이 아니라 같은 페이지를 계속 반복하면서 무한루프처럼 동작하기 시작했다. 처음에는 WebView 문제라고 생각했다. 하지만 원인은 location.href 와 히스토리 스택 구조였다. location.href 로 이동할 때마다 히스토리에 페이지가 계속 쌓이고 뒤로가기를 눌렀을 때 페이지가 다시 로드되면서 이동 스크립트가 또 실행되는 구조가 만들어진 것이다. 흐름은 이렇게 반복된다. A 페이지 → location.href → B 페이지 B 페이지 → 뒤로가기 → A 페이지 A 페이지 로드 → location.href 실행 → B 페이지 이 과정이 계속 반복되면서 하이브리드 앱에서는 뒤로가기 무한루프가 발생한다. 웹에서도 발생하는 문제지만 하이브리드 앱에서는 시스템 하단의 뒤로가기 버튼이 존재하기 때문에 이 문제가 훨씬 쉽게 드러난다. 특히 Android 물리 백버튼이나 iOS 제스처 뒤로가기와 결합되면 사용자는 앱이 고장난 것처럼 느끼게 된다. 해결 방법은 간단하다. 첫 번째는 location.href 대신 히스토리를 남기지 않는 location.replace 를 사용하는 것이다. location . replace( 'pageB.php' ); 이렇게 하면 히스토리가 쌓이지 않아 뒤로가기 루프가 발생하지 않는다. 두 번째는 자동 이동 로직이 한 번만 실행되도록 조건을 추가하는 방법이다. if (!sessionStorage.getItem('moved')) { sessionStor...

개발자가 AI를 고르는 기준, ChatGPT vs 퍼플렉시티 vs 제미나이 vs 그록

 요즘 개발자에게 AI는 필수 도구가 됐다. 대표적으로 많이 사용하는 AI는 ChatGPT, 퍼플렉시티, 제미나이, 그리고 그록이다. 각각 성격이 조금씩 다르다. 퍼플렉시티는 검색형 AI에 가깝다. 질문을 하면 핵심 정보를 빠르게 정리해 준다. 최신 문서나 정책 확인할 때 유용하다. 다만 코드 수정처럼 구체적인 작업에서는 설명이 짧게 끝나는 경우가 있어 추가 테스트가 필요할 때도 있다. 제미나이는 비교적 신중한 스타일이다. 정확성을 중요하게 보는 답변이 많다. 개념 설명이나 방향 정리에 도움이 된다. 하지만 코드 디버깅에서는 다소 보수적으로 느껴질 수 있다. ChatGPT는 대화형 AI에 가깝다. 코드 흐름을 같이 분석하고 문제 원인을 설명하고 바로 수정 가능한 방향까지 제시하는 방식이다. 그래서 기존 프로젝트 수정이나 디버깅 작업에서 활용도가 높다. 그록은 실험적인 기능이 빠르게 추가되는 편이다. 특히 이미지나 동영상 생성 기능이 주목을 받았다. 다만 일부 기능은 유료화되면서 접근 방식이 바뀌고 있다. 그래서 간단한 테스트 용도로는 괜찮지만 지속적으로 사용하려면 비용을 고려해야 한다. 결국 어떤 AI가 더 좋다고 말하기는 어렵다. 최신 정보 검색 → 퍼플렉시티 개념 설명 → 제미나이 코드 수정 / 디버깅 → ChatGPT 이미지 / 동영상 생성 → 그록 AI는 하나만 쓰기보다 상황에 맞게 선택하는 것이 가장 효율적이다. 개발자가 AI를 사용하는 이유는 단순하다. 삽질을 줄이기 위해서다. 어떤 AI를 쓰든 내 작업 스타일에 맞는 도구를 고르는 것이 가장 중요하다.

하이브리드 앱을 웹이랑 똑같이 견적 내면 안 되는 이유

 하이브리드 앱은 처음 보면 그냥 웹이랑 똑같아 보인다. URL 하나 올리면 끝나는 구조니까 쉽다고 생각하기도 한다. 나도 처음에는 그렇게 생각했다. “웹 만들었으니까 앱은 금방 나오겠지.” 이게 가장 큰 착각이었다. 실제로 개발을 시작해보면 완전히 다른 문제가 계속 나온다. 웹에서는 정상인데 앱(WebView)에서는 레이아웃이 깨진다. SafeArea 처리도 따로 해야 하고 스크롤 이벤트도 브라우저랑 다르게 동작한다. 하단 고정 버튼 하나 만드는 것도 웹에서는 간단하지만 하이브리드 앱에서는 기기별로 다 테스트해야 한다. 특히 로그인이나 결제 같은 외부 페이지를 거치면 화면이 풀스크린으로 깨지는 문제도 발생한다. 브라우저에서는 절대 안 나오던 버그가 앱에서만 나온다. 또 하나 큰 차이는 테스트다. 웹은 브라우저 하나에서 확인하면 되지만 하이브리드 앱은 안드로이드 iOS WebView 버전 기기 해상도 이걸 다 확인해야 한다. 결국 작업 시간은 웹보다 훨씬 오래 걸린다. 그런데 겉보기에는 웹이랑 비슷해 보여서 견적을 웹 기준으로 잡아버리면 개발자는 무조건 힘들어진다. 하이브리드 앱은 "웹 + 앱 대응 작업"이 추가된 구조다. 그래서 웹이랑 동일한 견적으로 보면 안 된다. 직접 개발해 보니까 느낀 건 하나다. 하이브리드 앱은 생각보다 훨씬 어렵다. 하지만 제대로 만들면 네이티브에 가까운 결과를 얻을 수 있다. 그래서 더 신중하게 견적을 잡아야 한다.

하이브리드 앱 개발하면서 느낀 것 – 웹이랑 같을 거라고 생각하면 큰 착각이다

 하이브리드 앱을 처음 만들 때 나는 단순하게 생각했다. 웹사이트 잘 만들어 놨으니까 WebView에 URL만 올리면 끝이라고. 하지만 실제로 개발을 시작해 보니 웹 브라우저와 WebView는 완전히 다른 환경이었다. 겉으로는 똑같이 보이는데, 동작 방식이 미묘하게 다르다. 이 미묘한 차이 때문에 예상 못한 문제들이 계속 발생한다. 1. fixed가 WebView에서 다르게 동작하는 문제 웹에서는 하단 고정 버튼을 만들 때 position: fixed를 사용하면 끝이다. 하지만 WebView에서는 부모 요소의 구조에 따라 fixed가 깨지는 경우가 많다. 특히 상위 요소에 transform이 들어가면 fixed가 화면 기준이 아니라 부모 기준으로 움직이기도 한다. 이걸 모르고 애니메이션 효과를 넣었다가 하단 고정 버튼이 같이 스크롤 되는 문제를 겪었다. 웹에서는 정상인데 앱에서만 깨지는 대표적인 사례다. 2. SafeArea 문제는 웹에서 테스트하면 절대 모른다 iOS에서 WebView를 사용할 때는 SafeArea를 항상 신경 써야 한다. 웹에서는 정상인데 앱에서는 상단 상태바를 덮어버리는 문제가 생긴다. 특히 로그인 화면을 거쳤다가 돌아오면 레이아웃이 깨지는 경우도 있다. 이건 CSS 문제가 아니라 iOS WebView 렌더링 문제라서 웹에서 아무리 수정해도 해결되지 않는다. 3. 스크롤 주체가 다르면 UI가 깨진다 웹에서는 body 스크롤이 기본이지만 하이브리드 앱에서는 특정 컨테이너가 스크롤을 담당하는 경우가 많다. 이때 하단 고정 버튼, floating 버튼, sticky 요소들이 예상과 다르게 동작한다. 그래서 하이브리드 앱에서는 “누가 스크롤을 담당하는지”를 먼저 정해야 한다. 4. 애니메이션도 함부로 넣으면 안 된다 웹에서 자연스럽게 보이던 페이지 슬라이드 효과가 앱에서는 fixed 요소를 깨뜨리기도 한다. 특히 transform을 사용하는 애니메이션은 하단 고정 UI에 영향을 줄 수 있다. 하이브리드 앱에서는 단순한 opacity나 ma...

iOS WebView 네이버 로그인 후 화면 깨짐 해결 (SafeArea 무시 / 상태바 사라짐)

iOS WebView 기반으로 앱을 만들면서 네이버 로그인을 붙였는데, 이상한 버그를 하나 만났다. 로그인까지는 문제없이 잘 된다. 그런데 로그인 이후부터 앱 화면이 전부 이상하게 깨지기 시작한다. 상단 상태바가 사라지고, SafeArea가 완전히 무시되면서 모든 화면이 풀스크린처럼 표시된다. 기존에는 정상적으로 보이던 페이지들도 전부 영향을 받는다. 처음에는 웹 쪽 문제라고 생각했다. CSS나 viewport 설정이 잘못된 줄 알고 이것저것 수정해봤는데 전혀 해결되지 않았다. 이상하게도 이 문제는 항상 발생하는 게 아니라 네이버 로그인 화면을 한 번 거쳤다가 돌아온 이후부터 발생했다. 이 시점에서 웹 문제가 아니라 iOS 쪽 문제일 가능성이 높다고 판단했다. 결론적으로 원인은 WebView의 SafeArea 처리와 네이버 로그인 과정에서의 화면 전환이 충돌하면서 발생한 문제였다. 네이버 로그인은 내부적으로 SafariViewController나 외부 웹뷰 형태로 화면이 전환되는데, 이 과정에서 iOS가 SafeArea를 다시 계산하지 않거나 WebView가 풀스크린 상태로 고정되는 경우가 있다. 특히 SwiftUI에서 아래와 같은 설정이 들어가 있으면 문제가 더 확실하게 나타난다. .ignoresSafeArea() 이 설정이 있는 상태에서 로그인 화면을 거치고 돌아오면 WebView가 계속 전체 화면을 덮어버리는 상태가 된다. 해결 방법은 생각보다 단순했다. 우선 .ignoresSafeArea() 설정을 제거하거나 꼭 필요한 영역에서만 제한적으로 사용하도록 수정했다. 이것만으로도 대부분의 경우 문제가 해결된다. 그리고 WebView를 감싸는 구조도 한 번 점검해봤다. 불필요하게 전체 화면을 덮는 구조 대신, SafeArea 기준으로 자연스럽게 렌더링되도록 단순하게 구성했다. 예를 들어 이런 식으로 정리했다. VStack {     WebView(urlString: "https://example.com") } 그래도 로그인 이후 화면이 깨지는...

증산동에 이런 카페가? 디저트 카페 펀스터

이미지
 벚꽃이 피던 금요일 오전 친구들과 증산동 빵 맛집으로 브런치하러~~ ===== 오시는 길 ===== 버스 ---> 증산 초등학교 하차 후 뒷골목 지하철로 오시는 길 ---> 1. 증산역 3번 출구300m 직진 후 증산도서관 등지고 수색방향으로 200m 오른쪽에 빨간색 건물입니다. 2. 디지털 미디어 시티역 5번 출구로 나오셔서 자이아파트 쪽으로 300m 가량 직진 증산골프장 옆 빨간색 건물입니다. 들어오기 전에 외부 테이블도 있답니다. 안으로 들어오는 햇살이 너무 눈부셔 사진이 뿌옇게 나오네요 ㅎㅎ 크로와상에 앙버터를 ㅎㅎ 맛있어 보여 사진만 찍음 소시지 페스츄리~~ 우리 아들 좋아하는건데.. 그 옆에는 남편이 좋아하는 애플파이 요 파이도 맛있다고 하네 집에 와 생각해보니 엄청 컷던 걸로 기억 담엔 사와야지 ㅋ 매콤한 명란 바게트에 감태를 올려 너무 파릇하죠? 매콤한 맛을 감태가 잘~~ 감아줄 듯 하네요. 깜빠뉴가 좀 작긴 한데 실해 보임 많이들 사가는 걸 보고 먹어볼 껄 후회 막심. 토마토 치아버터 vs 크리스피 치아버터 뭐가 맛있을까요?  글쎄요.. 둘 다 맛있겠죠. 2층올 올라가는 계단 옆이 화장실입니다. 근데 화장실 옆에서 빵이 나와요 ㅎㅎ 화장실 끼고 계단으로 올라가면 2층올 올라가면 로스팅 룸이 보이네요 커피가 맛난 이유가 여기 있었군요. 2층이 꽤 넓고 밝습니다. 햇살이 눈부시게 들어와서 창을 등지고  큰 원형 테이블에 자리 잡았습니다 벌집라떼 & 펀스터크림 & 아메리카노 단호박 깜빠뉴 & 잠봉 뵈르 & 쪽파크림치즈 베이첼(베이글+프레첼) 부드러운 크림과 찐한 커피가 잘 어울리는 펀스터 크림, 풍미가 좋아요 잠봉뵈르 바게크가 좀 딱딱하니 힘 주고 깨물어 주세요! 잠봉 듬뿍, 버터는 고소하니 담백함에 홀딱 캬~ 쪽파가 쫑쫑쫑, 크림치즈도 듬뿍이네요 베이글모양의 프레첼입니다. 크림치즈의 느끼할 수 도 있는 맛을 쪽파가 향긋하게 잡아줘요 주차는 카페앞 3대까지 가능하다고 하니 참고하세요....