Google Firebase Storage

 

 

간단한 앱이나, 구현하고자 하는 서비스의 프로토타입을 빠르고 간편하게 만들기 위해서 Google Firebase를 많이 사용하는 것 같다.

 

Firebase 내에는 많은 부가 서비스와 기능들이 제공되지만, 그 중 Google의 규모를 활용한 강력하고 단순하며 경제적인 객체 저장소 서비스인 Firebase용 Cloud Storage 서비스를 활용해 사진 파일을 업로드 할 수 있는 기능을 구현하고자 했다.

 

그러나 아직 익숙치 않아서인지 파일 업로드와 관련된 부분을 구현하는 중에 발생한 오류(Uncaught (in promise) FirebaseError: Firebase Storage: User does not have permission to access '...'. (storage/unauthorized))를 수정하는 데 시간을 조금 허비하여 관련 내용을 기록해 둔다.

 

 

 


 

아래는 파일 업로드 시 실행되는, 내가 구현한 onSubmit 함수의 일부분이다.

 

        event.preventDefault(); 
        const fileRef = fbStorage.ref().child(`${userObj.uid}/${uuidv4()}`);
        console.log(fileRef);
        const response = await fileRef.putString(fileState, "data_url");
        console.log(response);

 

 

첫번째 시도 결과, fileRef(ReferenceCompat)는 콘솔에 정상적으로 출력되나 response는 정상적으로 출력되지 않고 bucket의 특정 경로에 접근할 permission이 없다는 경고가 표시된다.

 

permission 관련 error

 

 

 

약간의 구글링 끝에, Firebase Storage 내 'Rules' 메뉴에서 읽기/쓰기 시 적용될 각종 Rule을 편집할 수 있다는 것을 알게 되었다.

해당 메뉴에서는 읽기/쓰기와 관련된 권한 체크, 쓰기 시 각종 Validation Rule 추가 등 유용한 기능등을 전용 문법으로 작성할 수 있는 기능을 제공하고 있었다.

 

Firebase > Storage > Rules

 

 

 

위 캡쳐를 보면 알 수 있듯이, read와 write 모두 if false로 아무도 읽고 쓰지 못하게 초기 설정이 되어 있었다.

해당 부분을 아래와 같이 Firebase의 Auth를 통해 로그인하고 권한을 부여받았다면 읽기/쓰기가 가능하도록 수정해 주었다.

 

request.auth 체크

 

 

 

이후 재시도하면 아래와 같이 업로드 관련 로직 수정 후 Console.log가 정상적으로 출력됨을 볼 수 있다.

 

Console.log 정상 출력

 

 

 

Firebase Storage 콘솔 내에서 'Files' 탭을 확인해 보면, 파일이 정상적으로 생성된 모습을 볼 수 있다.

 


 

 

 

끝.

반응형

 

 

GitHub에서 소스를 관리하다 보면, 내 개인 프로젝트임에도 불구하고 Public으로 공개되어야 얻을 수 있는 각종 지원 기능들로 인해 Public Repository로 생성하게 되는 경우가 발생한다.

 

이 때, 소스상에 연동에 필요한 각종 Key들이 그대로 들어가 있고 해당 소스들이 모두 공개 리파지토리에 올라가는 것이 싫다면 환경 변수에 각종 Key들을 생성하여 한 단계 숨기고, 해당 Key가 포함된 env 파일은 git에 업로드 되지 않도록 하는 방법을 적용할 수 있다.

 

 

단, 결과적으로 배포 시 App을 Build하면 어차피 해당 Key들은 환경변수 값을 참조하여 컴파일을 하게 된다.

보안 측면에서 영영 숨기는 방법은 아니라는 것이다. 단순히 GitHub에 소스 레벨로 이러한 키들이 공개되는 것을 원치 않는 경우에는 해당 방법을 적용하면 된다.

 

(Nomad Coder - 트위터 클론코딩 강좌 수강 중 내용을 참고하였습니다.)

 

 

 


.env 파일 생성 & 환경변수 등록

우선 프로젝트 폴더 아래에 .env 파일이 없다면 해당 파일을 생성한다.

그 후, 각종 환경변수를 생성하고 기존에 있던 key를 해당 변수값으로 할당해 준다.

이 때, React App의 경우에는 환경변수가 반드시 REACT_APP으로 시작해야 한다는 점을 명심하자.

 

아래는 Firebase 개발 시 등록한 환경변수의 예제이다.

.env 파일에 환경변수를 생성한 모습

 

 

 

기존 소스 수정

기존 소스에서 Key가 그대로 입력된 부분들은 모두 아래와 같이 환경변수로 대체한다.

GitHub에는 해당 파일은 업로드가 될 것이지만, 다른 사용자들은 환경변수명만 알 수 있게 된다.

 

기존의 Key가 입력되어 있던 부분을 환경변수로 변경한 모습

 

 

 

.gitignore 파일 수정

하지만 이렇게 숨겨놓은 env 파일이 git에 업로드된다면 말짱 꽝이므로, 해당 파일이 Repository에 업로드되지 않도록 설정해 주어야 한다.

 

아래와 같이 .env 파일을 .gitignore 파일 내에 등록해 주면, 해당 파일은 GitHub으로 업로드되지 않게 된다.

 

.gitignore 수정

 

 

확인을 해 보면, 아래와 같이 gitignore 파일에 env를 등록하기 전에는 env 파일도 Changes로 감지하나(좌), gitignore 파일에 .env를 등록한 후 저장하면 Changes 목록에 .env 파일이 사라진 것을 볼 수 있다.

 

gitignore 파일 수정 전/후 비교


 

 

 

(230211 추가)

해당 방법으로 관리하는 경우, 치명적인 오류가 하나 발생한다.

 

아마 로컬 환경에서 빌드 시 순서에 따른 문제인 것 같은데, apiKey나 authDomain 같은 환경변수 값들이 필요한 경우 해당 값들을 제대로 참조하지 못하는 경우가 발생한다.

(Ex. API Key가 비정상적이라거나, Firebase Auth 사용 시 Domain을 등록하고 사용하라거나 등의 오류 발생)

 

실제 배포시에는 해당 문제가 발생하지 않는다 하더라도, 개발 과정에서 위와 같은 불편함을 감수하기는 힘드므로 그냥 key를 업로드해야 할 수밖에 없을수도....

 

 

 

 

 

끝.

 

반응형

이 전 글들에서는 Visual Studio Code에 Git을 설치하고, GitHub에 존재하는 Repository를 불러와서 내 로컬에서 작업하고 이를 다시 GitHub Repository로 Push하는 방법을 알아보았다.

 

[혼자 다 해볼거야/생산성] - [형상관리] VSCode - Git - GitHub 연동
[혼자 다 해볼거야/생산성] - [형상관리] VSCode - GitHub Repository 연동

 

 

이번에는 반대로 흔히 실습을 하다 보면 각종 프레임워크/라이브러리 등을 로컬에 설치하고 이를 이용해 로컬에 파일을 우선 만들게 되는데, 이렇게 만들어진 로컬 파일을 GitHub 내 Branch를 신규 생성하고 형상관리하는 방법에 대해서 알아보고자 한다.

 

 

 

신규 Repository 및 Branch 생성

기존에 GitHub 계정과 연동을 한 상태라면, VSCode 내에서 Source Control 메뉴에 진입했을 때 아래와 같이 'Publish Branch' 버튼이 보이게 된다.

이를 클릭하면 상단에 Private Repository를 생성할지, Public Repository를 생성할지 선택하는 부분이 표시된다.

목적에 맞는 것을 선택하자.

 

Publish Branch

 

 

 

그러면 아래와 같이 VSCode 우측 하단 창에 생성 상태바가 표시된 후 성공적으로 publising까지 완료되었다는 메시지를 볼 수 있다.

 

Successfully published

 

 


Open on GitHub 버튼을 클릭하여 사이트로 들어가 보면, 아래와 같이 새로운 Repository가 자동으로 생성되어 master branch에 정상적으로 소스가 업로드되어 있음을 확인할 수 있다.

 

자동으로 생성된 Repository의 모습

 

 

 

 


 

공부하면서 많이 느끼는 부분인데, 정말 새삼 모든 것이 한층 더 좋아지고 편리해졌다는 생각이 든다.

한창 Google Cloud Summit등에 참석해서 열의를 가지고 이런저런 것들을 학습했을 때보다 더 많은 것들이 진보했다는 느낌이다. 그게 이 IT 업계라서 더더욱 빠르게 느껴지고.

 

내 업무 환경이 레거시 SI라서, 회사가 온프레미스에 폐쇄망만 고집해서 등의 이유로 이런 신기술들을 활용하지 못한다면 더더욱, 개인적으로라도 끊임없이 학습하고 본인의 생산성을 향상시키기 위해 노력해야만 시간이라는 귀중한 자원을 가장 효율적으로 쓸 수 있지 않을까 싶다.

비록 여러가지 이유로 업무에 적용할 수 없는 상황일지라도 '나'는 항상 갖춰져 있어야 한다는 생각이다. 그게 기술적인 부분이건 업무에 임하는 자세건 내가 갖춰져 있어야만 기회가 왔을 때 잡을 수 있다.

 

그렇지 않으면 본인 머릿속에 있는 시스템이나 서비스의 히스토리로만 먹고 사는, 그저 그런 관리자나 개발자가 되어 밀려나고 도태될 뿐이다.

 

 

 

끝.

반응형

최근 많이 보고 있는 노마드 코더의 니꼬님이 그렇게나 좋아하는 Visual Studio Code를 활용하여 개발 환경을 셋팅하기로 했다.

 

 

Visual Studio Code 설치

Visual Studio Code는 글을 작성하는 시점에 이미 설치를 다 해버린 상태라 상세한 가이드는 작성을 못 하겠다.

다만 구글링을 해 보면 VSCode 설치 관련 글은 엄청나게 많고, 대부분은 기본 설정으로 설치를 진행하면 되는지라 특별한 가이드가 필요하지는 않다.

 

Visual Studio 공식 다운로드 링크

 

다만 Installer에 두 가지 타입이 있는데, 특정 User만을 위한 User Installer가 있고, 해당 Windows의 모든 사용자를 위한 System Installer가 있다.

공용 PC 등을 사용해서 특정 사용자만 사용해야 하는 경우가 아니고, 개인 PC를 사용하는 경우라면 일반적으로 System Installer를 설치해서 사용한다고 하니 참고하자.

 

User / System Installer를 목적에 맞게 선택하자.

 

Git 설치

설치가 완료된 후 VSCode를 구동시켜 보면, 생산성을 향상시키기 위한 방법 중 하나로 Git을 설치할 것을 권유하고 있다.

Install Git 버튼을 눌러 사이트에 들어간 후, 다운로드 파일을 찾아 다운받는다.

2023년 1월 21일 현재 최신 버전은 2.39.1 버전이다.

 

설치 후 VSCode에서 Install Git을 제안한다.

 

Git 사이트에서 다운로드 링크로 진입하여 64bit Standalone Installer를 다운받는다.

 

이후 대부분을 기본 설정으로 넘어간 뒤, 기본 에디터를 선택하는 부분에서 우리는 VSCode와 Git을 연동할 것이므로 'Use Visual Studio Code as Git's Default Editor' 옵션으로 변경한 후 넘어가자.

 

'Use Visual Studio Code as Git's Default Editor' 옵션으로 변경

 

 

이후에는 저장소의 메인 브랜치 이름을 Git 기본값인 master로 할 것인지, main등으로 변경할 것인지를 비롯한 각종 셋팅들이 나오나 구동에 큰 영향을 주지 않는 옵션들로 대부분 기본값을 선택했다.

 

 

 

아, 마지막 즈음에 PATH environment와 관련된 설정을 하는 부분이 있다.

 

Git을 Command Line에서 사용할 때 Git Bash만을 사용할 것인지(1번), 또는 윈도우 PowerShell을 비롯한 각종 써드 파티 소프트웨어들을 사용해서 Git을 사용할 것인지(2번) 등을 묻는 부분인데, 대부분 윈도우 사용자들은 2번을 선택할 것을 추천하고 있으므로 기본 선택값인 두번째 옵션을 선택하여 설치한다.

 

다시 한번 찬찬히 읽어 보니, 환경변수의 PATH 값을 전혀 수정하지 않고 Git Bash만을 사용하려면 1번, VSCode와 같은 써드 파티 툴들을 이용해서 Git을 이용하려면 PATH에 일부 Git Wrapper와 관련된 환경변수 값이 추가되는 2번을 선택하면 되는 듯하다.

 

일반적인 사용자들은 두번째 옵션을 선택하자

 

 

설치가 완료되면, 윈도우 메뉴에서도 Git을 확인할 수 있으며 일반적인 cmd 창에서도 'git --version' 명령어로 Git의 설치 여부와 설치된 버전을 확인할 수 있다.

 

Git 설치 여부 및 버전 확인

 

 

GitHub 연동

설치가 완료된 후 VSCode로 돌아와 좌측의 세번째 아이콘(Source Control)을 클릭하면, 아직 아래와 같이 설치된 Git을 인식하지 못하는 것을 볼 수 있다.

reload를 클릭해 VSCode를 다시 로딩해 주자.

 

reload 클릭

 

 

그러면 아래와 같이 Git이 인식된다.

 

설치된 Git이 인식된다

 

 

이제 'Oepn Folder'를 클릭해 기존에 내가 로컬에서 작업하고 있던 폴더를 선택하여 불러올 수도, 'Clone Repository'를 클릭하여 GitHub에 이미 등록되어 있는 리파지토리를 복제해서 가져올 수도 있다.

 

 

자세한 GitHub 연동 및 소스 관리 방법은 나중에 추가로 작성하도록 하고, 우선 설치 방법까지의 가이드는 이것으로 마친다.

 

 

 

 

끝.

반응형

생성한 EC2에 WAS를 띄운다거나 하는 등의 각종 작업을 하기 위해서는 내 클라이언트 PC에서 서버인 EC2 인스턴스로의 접속이 필요하다. 

EC2를 생성하는 방법은 아래 포스팅을 참고하면 된다.

 

[혼자 다 해볼거야/Cloud & Architecture] - [AWS] Free Tier EC2 생성

 

 

 

OpenSSH 등을 비롯한 여러가지 방법이 있겠지만, 업무 시 가장 많이 사용해서 제일 익숙해져버린 PuTTY를 이용해서 SSH 접속을 하기로 한다.

 

 

 

PuTTY 설치 및 설정

PuTTY 설치 단계는 다른 곳에서도 충분히 친절하게 설명해주고 있으니 생략하기로 한다.

이왕이면 쌔삥으로 - 최신 버전으로 - 설치해 주는 것이 좋겠다.

 

설치가 완료되었으면, 아래 공식 가이드를 참고하여 PuTTY 설정을 진행하자.

해당 포스팅에서는 주요 단계만 언급하도록 한다.

 

AWS PuTTY 연결 공식 가이드

 

 

나는 최초에 pem이 아닌 ppk로 키 페어를 받아 두었으므로 PuTTYgen을 이용한 변환 단계는 생략하였다.

이하는 상기 공식 가이드에서 발췌한 내용이다.

 

 

 



 

 

공식 가이드에서는 5-1 단계와 같이 호스트를 신뢰하겠다는 설정 이전에 RSA 키 지문 확인 등을 통해 다른 공격이 있는지 확인하라고 하나, 현재는 서비스 단계도 아니고 생성과 학습 단계이므로 생략하기로 한다. (아마존도 선택 사항이라고 적어놓기도 했고)

 

5-2 부분에서의 선택창은 아래 창을 의미한다. 'Accept'를 누르면 신뢰할 수 있는 호스트로 알고 PuTTY의 캐시에 키를 저장하여 계속 접속할 수 있게 해 준다.

 

공용 PC가 아닌 개인 PC라면 'Accept'를 선택하여 편하게 접속하자

 

 

 

아래와 같이 정상적인 커맨드 창이 표시되면 EC2 인스턴스에 성공적으로 접속된 것이다.

 

검은 커맨드 창이 보이면 마음이 편-안해지는 어른이 되었다

 

 

 

끝.

반응형

전체적인 아키텍쳐를 그리기 전에, 12개월 & 월 750 시간으로 기간이 정해져 있는 EC2 Free Tier가 아깝기도 하고, 뭔가 하나라도 실제 웹 상에서 퍼블리싱이 되어 구동되는 모습이 보여야 더욱 흥미가 붙을 것 같아 EC2부터 한 대 생성하기로 한다.

 

AWS 계정을 이용하여 클라우드 콘솔에 접속한다.

(AWS 계정 생성 방법은 이전에 업로드한 글을 참고하시면 됩니다.)

 

[혼자 다 해볼거야/Cloud & Architecture] - AWS Free Tier 계정 생성

 

 

Free Tier 기준

AWS는 GCP와는 다르게 컴퓨팅 서비스에 평생 Free Tier 개념이 없다. 대신에 계정을 생성한 후 12개월동안 750시간/월의 무료 혜택을 제공한다.

 

 

한 달 750시간이란, 1개의 EC2를 생성한 경우에는 일일 24시간 구동을 기준으로 약 31일을 사용할 수 있는 양이므로, 하나만 공짜로 사용하라는 말이다.

두 개 이상의 EC2를 생성할 경우, 하루 종일 두 인스턴스를 구동시킨다면 무료 혜택을 초과하게 되어 비용이 부과되므로 참고하자.

 

다른 서비스들의 Free Tier 기준은 아래 AWS 사이트의 링크를 참고하면 된다.

 

AWS Free Tier 살펴보기

 

 

위 링크에서 여러 서비스들의 프리 티어 기준을 확인할 수 있다.

 

 

생성

AWS Console에서 EC2 메뉴 진입 > 인스턴스 시작 버튼 클릭

 

 

이후 표시되는 메뉴에서 생성될 서버의 OS 등 여러가지 사양을 선택해야 한다. 

OS는 Amazon Linux, 레드햇 계열의 Red Hat Linux, (CentOS는 2021년 서비스 지원 종료로 없어진 듯 하다), 데비안 계열의 Ubuntu등이 제공된다.

Windows Server도 프리 티어 OS로 제공되나 프리 티어 인스턴스 사양으로는 돌리기가 버거울 것 같아 무시한다.

 

 

구글링을 하며 한참을 고민하다 우선은 Ubuntu로 생성하기로 결정했다.

 

반드시 '프리 티어 사용 가능' 문구가 있는 OS로 선택하여야 공짜로 받아먹을 수 있다.

 

 

 

인스턴스 유형은 t2.micro로 선택하였고, 키 페어는 기존에 생성해 둔 것이 없으므로 신규로 생성하였다.

나는 PuTTY를 사용하여 SSH 접속할 예정이므로 ppk 파일 형식으로 생성하였다.

 

신규 키 페어를 생성해야 인스턴스에 안전하게 연결이 가능하다.

 

생성을 클릭하면 ppk 확장자로 된 파일이 자동으로 다운로드되는데, 나중에 PuTTY 접속 설정 시 사용되기도 하고 보안 상 중요한 Key가 되므로 안전한 곳에 꼭꼭 숨겨 보관하도록 하자.

 

 

 

 

다음으로 항상 중요하고도 복잡한 네트워크 설정 단계인데, 다른 것들은 기본값으로 그대로 두었으며 보안 그룹 이름은 내 마음에 드는 이름으로 변경해 주었다.

 

 

인바운드 보안 그룹 규칙은 SSH Port(기본 22)를 활용해 해당 인스턴스에 접속하기 위한 제일 기본적인 Rule을 등록하게 되는데, 그 중 가장 중요한 소스 유형은 '위치 무관'의 경우 어떤 IP로 접속하더라도 접속 가능하도록 허용하는 것이고 '사용자 지정' 또는 '내 IP'로 선택할 경우 특정 IP를 직접 입력하거나 지금 접속하고 있는 IP로 한정하여 EC2에 접속 가능하도록 제한하는 것이다.

 

일반적인 가정용 인터넷 공유기 설정은 유동 IP를 할당받아 사용하도록 되어 있기도 하고, 글을 작성하는 시점에 카페에서 공용 와이파이를 사용하고 있다 보니 '위치 무관'으로 우선 생성하기로 한다.

 

인바운드 보안 그룹 규칙은 신경써서 생성해야 한다.

 

 

 

마지막으로 스토리지 부분인데, 프리 티어의 경우 SSD 타입의 스토리지까지 포함하여 총 30Gb가 무료 용량으로 제공된다. 이번 인스턴스에는 8Gb만 할당하여 쓰기로 한다.

 

gp2가 기본적으로 선택되어 있으나 gp3가 (서비스의 I/O 패턴에 따라 다르기는 하나) 일반적으로 더 낫다고 알고 있어 gp3로 변경하여 생성하기로 한다.

 

gp2와 gp3 비교. 볼륨당 최대 처리량이 더 빠르고 나머지가 동일하면 gp2의 존재 이유는...? 공부,,,해야지,,

 

 

기타 설정은 건드리지 않고 생성을 누르게 되면, 아래와 같이 약간의 시간이 지난 뒤 인스턴스 생성이 완료되었다는 메시지를 볼 수 있다.

 

 

 

 

이후 모든 인스턴스 보기 버튼을 눌러 대시보드로 이동하면, 내가 생성한 인스턴스가 한 줄 표시되고 '인스턴스 상태'가 '실행 중'으로 표시되는 것을 볼 수 있다.

 

 

끝.

반응형

크롤러 개발 중 특정 요소를 불러왔음에도 값들이 인식이 안 되고 아래와 같은 오류 메시지가 표시되는 케이스를 발견했다.

Message: stale element reference: element is not attached to the page document

 

Message: stale element reference: element is not attached to the page document 오류

 

 

 

오류 메시지를 살펴보니 stale element를 참조하고 있다고 하는 것으로 보아, WebElement로 가져온 객체 중 저 element ID를 가진 요소가 없는(없어진?) 것으로 보인다.

 

그런데 이상하다. 현재 화면에서 표시되는 대로라면 리스트가 2개여야 정상인데 사이즈가 6개로 잡히는 게 아닌가.

 

내가 가져오려는 것은 Premier League 하위 2개 a 태그 요소다

 

 

 

 

코드가 잘못된 줄 알고 몇 번의 수정과 시행착오 끝에 밝혀낸 범인은 이것이었다.

 

  1. 화면에서 처음에는 현지 시간대 기준으로 Yesterday Match Info.를 가져온다.
  2. 내 코드는 해당 시점에 요소를 읽어들여 List Size가 6이다.
  3. 내 코드가 객체를 읽은 후, 친절하게도 Fotmob 사이트에서 사용자 시각(GMT+9)을 기준으로 요소를 Refresh 한다.
    (이 때 아마 Element ID도 다 변경되어 버리는 것 같다.)
    (230120 수정) 자동으로 Refresh가 이루어지는 것이 아니었다. 어떤 이벤트로 인지가 되는지는 모르겠으나 창을 최소화 한 후 다시 활성화하는 시점에 경기 리스트가 6개에서 2개로 Refresh 되더라...
  4. 한국 시간대로 어제 치뤄진 경기는 두 경기이므로, 2번 단계에서 읽은 요소로 Loop를 돌면서 Element를 찾으면 다 사라지고 없겠지? 따라서 기쁘게도 에러가 난다.

 

현지 시간대를 기준으로는 총 6경기가 치뤄졌다

 

 

 

따라서 아래와 같이 코드를 수정하였다.

창 최소화와 최대화 사이에 sleep을 걸어주지 않으면 또 제대로 Refresh가 되지 않아서... 부득이하게 추가하였다.

 

        WebDriverWait(driver, 5).until(
            EC.presence_of_element_located((By.XPATH, '//*[@id="__next"]/main/div[2]/div[1]/section/section/div[2]/div[1]'))
        )
        driver.minimize_window()
        time.sleep(2)
        driver.maximize_window()
        time.sleep(2)

 

 

 

다음과 같이 정상적으로 객체 인식 & 값 인식이 되는 것을 확인하였다.

 

이렇게 사이트마다 조금씩 특이한 변수들이 존재할 수 있다. 실전에서 부딪혀보지 않으면 알기 힘들겠다.

 

 

 

Learned - 촌각을 다투는 크롤링이 아니라면 화면 로딩 후 어떤 일이 이루어질지 모르기 때문에 2~3초간의 sleep을 필수로 넣어두어야 할 것 같다. (230120 수정) 사전에 대상 화면을 미리 둘러보고 육안으로 언제, 어떤 부분들이 동적으로 변하는지 잘 살펴봐야겠다.

 

 

 

 

 

끝.

반응형

'다 배울거야 > Crawling with Selenium' 카테고리의 다른 글

XPath로 화면의 요소 찾기  (0) 2023.01.15

크롤러 개발 중에, 기존에 코드에 넣어둔 XPath가 어떤 요소를 가져온 것인지 기억이 잘 나지 않는 경우가 생겼다.

 

이 때, 코드의 XPath를 이용해 그 Path가 화면의 어떤 요소를 지칭하는 것이었는지 확인해 볼 수 있다.

 

  1. 코드의 XPath를 복사한다.
  2. Chrome - F12로 개발자 도구 오픈
  3. Ctrl + F로 검색창 오픈
    검색창 설명을 보면 string, selector, XPath로 검색이 가능하다고 나와 있다.
  4. XPath 붙여넣기
    아래와 같이 붙여넣는 순간 친절하게도 파란색/노란색 하이라이트로 화면 내와 코드 내에 어떤 부분인지 검색 결과를 표시해준다.

 

끝.

반응형

+ Recent posts