[엘리스 SW QA 트랙 9~10주차] 1차 팀 프로젝트 회고

ℹ️ 프로젝트 가이드

---

📌 3/21 - 1일차 회고 (대상 서비스 파악 및 프로젝트 환경 세팅)

 
어제 수업이 끝난 후 오후 8시 30분 기차를 타고 서울로 올라왔다. 고시원에 도착해 짐을 대충 풀고 나니 어느덧 밤 11시가 훌쩍 지나 있었다. 급하게 눈을 붙였지만, 낯선 잠자리 때문인지 자꾸 뒤척이게 됐다.
오늘은 엘리스Lab에서 팀원분들을 처음으로 오프라인에서 만나는 날이었다. 비몽사몽 일어나서 서울 구경도 할 겸 30분 정도 걸어서 엘리스Lab으로 향했다.
Jenkins는 CI/CD 자동화를 위한 도구이지만, Windows 환경에서는 Java 환경 설정 및 설치 과정에서 다양한 오류가 발생하여 로컬 설치에 어려움이 있었다. 이에 Jenkins 공식 이미지를 활용해 Docker로 Jenkins 컨테이너를 실행하였고, GitHub 레포지토리와 연동한 뒤, 해당 레포 내 파일을 실행하는 명령어를 Jenkins Job에 입력해 빌드를 수행해보았다. 명령어가 정상적으로 실행되는지 확인함으로써 Jenkins와 GitHub 레포지토리 간 연결이 잘 이루어졌는지를 검증할 수 있었다.


🔥 Jenkins 설정 및 GitHub Repo와의 연결

[ Jenkins와 연결할 GitHub 레포 생성 ]

https://github.com/kys0529/Jenkins_prac

 

[ 새로운 Jenkins 컨테이너 실행 (in cmd) ]

docker run -d -p {외부 포트}:{컨테이너 내부 포트} -p 50000:50000 --name {컨테이너 이름} jenkins/jenkins

 > Jenkins 공식 이미지를 기반으로 새로운 컨테이너를 백그라운드에서 실행

 > 포트 8080(웹 UI)과 50000(에이전트 통신용)을 오픈

 

[ 컨테이너 실행 여부 확인 (in cmd) ]

docker ps

 > 현재 실행 중인 Docker 컨테이너 목록을 확인하여 Jenkins가 잘 떠 있는지 체크

 

[ Jenkins 초기 비밀번호 확인 (in cmd) ]

docker exec -it {컨테이너 이름} cat /var/jenkins_home/secrets/initialAdminPassword

 > Jenkins 초기 설치 시 필요한 관리자 비밀번호를 출력

 

[ Jenkins 웹 UI 접속 및 초기 비밀번호 입력 ]

http://localhost:8080

 > 브라우저에서 http://localhost:8080 접속 후, 위에서 확인한 초기 비밀번호를 입력하여 초기 설정을 진행

 

[ Freestyle Job 생성 및 GitHub Webhook 연결]

Jenkins에서 New Item > Freestyle Project를 선택하여 새로운 Job 생성

http://{공인 IP}:8080/github-webhook/

 > GitHub에서 Webhook 설정 시 Payload URL은 위 같이 입력

 > 해당 Webhook은 GitHub에서 push 이벤트 발생 시 Jenkins Job을 트리거하는 역할

 

[ Jenkins 컨테이너 내 Python 설치 여부 확인 (in cmd) ]

docker exec -it {컨테이너 이름} bash

 > Jenkins 컨테이너 내부로 진입

python3 --version

 > Python이 설치되어 있는지 확인

 

[ Docker 컨테이너 내부에 python3 설치 ]

docker exec -it --user root {컨테이너 이름} bash

 > 루트 권한으로 컨테이너에 진입

apt update

apt install -y python3 python3-pip

 > Python3 및 pip 설치

 

[ Build Steps 설정 ]

Jenkins Job 설정 > Build Steps 항목에서 "Execute shell" 선택

python3 hello.py

 > 레포 내 hello.py 파일을 실행하여 Jenkins와 GitHub 레포 간의 연결 및 실행 여부를 확인

 

---

 

그 후 팀명과 팀장을 정했다. 팀명은 GPT의 도움을 받아 결정했고, 팀장은 아무도 하려고 하지 않아서 내가 맡게 됐다. 나서서 리더 역할을 하지는 않지만, 항상 그렇듯 할 사람이 없으면 결국 내가 하게 되는 편이다.
팀장을 정한 후에는 대상 서비스의 Figma, ERD, 기획서 같은 문서를 참고해서 기능들을 대략적으로 파악했다. 그리고 팀원들과 함께 서비스를 직접 사용해보면서 탐색적 테스트와 크로스 테스트를 진행했다. 어떤 기능들이 구현돼 있는지, 아직 구현되지 않은 건 무엇인지, 어떤 오류들이 있는지를 하나하나 직접 확인해보면서 전반적인 흐름을 이해했다.
 
 

그 결과를 바탕으로 구글 스프레드시트에 기능 명세서를 정리했고, 각자 하나씩 기능을 선정해서 TC 초안도 작성했다. 소통을 더 원활하게 하기 위해, Figma에 자주 쓰는 URL이나 프로젝트 산출물, 그리고 진행 상황 등을 한눈에 볼 수 있게 정리해두었다.
 
GitHub는 GitHub Desktop을 활용하면 GUI로 쉽게 조작할 수 있어서 Git 경험이 없어도 누구나 어렵지 않게 사용할 수 있었는데, GitLab은 우리 모두 처음이라 CLI 조작에 많이 헤맸다. 그래도 SSH Key를 발급받고, Clone과 Pull까지는 결국 다 성공했다. 오늘은 일단 프로젝트의 초기 디렉토리 구조만 만들어둔 상태다.
오후 8시에는 오피스 아워가 진행됐다. 이 시간은 QA 실무 및 자동화 경험이 있는 풀스택 현업자분께 1시간 동안 궁금한 점을 물어볼 수 있는 정말 소중한 시간이다. 사실 프로젝트 첫날이라 이것저것 정신이 너무 없었고, 질문 리스트를 미리 준비하지 못한 게 너무 아쉬웠다. 다음부터는 꼭 미리 질문을 정리해서 이 시간을 더 유용하게 활용해야겠다.
 
 
🔥 SSH Key 설정 및 GitLab 프로젝트 Clone

[ SSH Key 생성 (in cmd) ]

ssh-keygen -t rsa -b 4096 -C "{GitLab에 등록된 이메일}"

 > 위 명령어 입력 후 Enter 3번 입력

 > SSH 키가 생성되면 키 파일 저장 위치가 출력

 

[ SSH 키 복사 ]

파일 탐색기로 생성된 SSH 키 위치로 이동 (본인은 C:\Users\samsung\.ssh)

비밀 키(id_rsa)가 아닌 공개 키(id_rsa.pub) 사용 (공개 키 내용 ssh-rsa ~~~~ 형태로 시작)

공개 키 내용 복사

 

[ GitLab에서 SSH Key 등록 ]

GitLab 접속 후 프로필 설정으로 이동

좌측 메뉴에서 SSH Keys 클릭 후,  복사한 SSH 공개 키를 Key 입력란에 붙여넣기

 

[ 폴더 생성 및 클론 ]

원하는 위치에 프로젝트 폴더 생성 후, VS Code에서 해당 폴더 열기

git clone {GitLab SSH 키}

 

---

 
🔥 Git 명령어

[ Clone 명령어 ]
git clone {Gitlab에서 복사한 SSH}

[ Repo를 Clone한 폴더로 이동 ]
cd {폴더 이름}

[ branch 생성 및 해당 branch로 이동 ]
git checkout -b {branch 이름}

[ 현재 branch 확인 (*이 현재 위치한 branch) ]
git branch

[ Pull 명령어 ]
git pull origin {branch 이름}

[ Push 과정 ]
변경 사항 확인: git status
변경된 파일 스테이징: git add .
커밋 만들기: git commit -m "커밋 메시지"
Push: git push origin {branch 이름}

 

---

---

📚 3/22 - 개인 공부 (Sourcetree)

 
사실 주말은 암묵적으로 프로젝트를 진행하지 않기로 했었지만, 동기 친구가 SW 마에스트로 면접 때문에 서울에 올라온 김에 얼굴도 볼 겸 성수에서 밥을 먹고, 카페에 들러 잠깐 프로젝트 관련 공부를 개인적으로 진행했다.
마침 그 친구가 Docker를 다뤄본 적이 있어서, 어제 내가 Docker로 진행했던 "Jenkins 설정 및 GitHub Repo와의 연결" 과정을 설명해줬더니, 친구가 이런 말을 해줬다. “너가 지금처럼 명령어 하나하나 쳐서 Jenkins 컨테이너 띄우고 설정하는 이런 작업들은 Dockerfile이나 Docker Compose로 정리해두면, 한 줄 명령어로 통합 실행할 수 있어” 즉, Dockerfile을 만들어서 Jenkins와 Python까지 미리 설치해두면, docker build 한 번으로 Jenkins + Python3 환경이 구성된 이미지를 바로 생성할 수 있다는 뜻이었다. 물론 코치님께서 처음부터 Dockerfile로 주셨다면 금방 끝났겠지만, 이 실습의 목적 자체가 직접 Jenkins를 세팅해보는 데 있으니까! 그래도 Docker를 활용하는 방법에 대해 하나 배워간 셈이다.
그리고 덧붙여, GitLab 이야기를 하다가 GitLab에는 GitHub Desktop처럼 GUI 클라이언트가 없어서, CLI에 익숙하지 않은 나와 팀원들이 꽤나 힘들어하고 있다고 하소연했더니 친구가 "Sourcetree"를 추천해줬다.
 
🔥 Sourcetree 사용 방법

[ Access Token 발급 방법 - GitHub ]

Settings > Developer Settings 

Personal access token > Tokens (classic) > Generate new token (classic)

 

[ Access Token 발급 방법 - GitLab ]

User Settings > Access tokens > Add new token

 

[ Access Token 발급 방법 - GitLab EE ]

User Settings > Access Tokens

 

[ 호스팅 계정 연동 ]

(1) Host

     New tab > Remote > 계정 추가 > 호스팅 서비스 및 선호 프로토콜 선택

     GitLab EE는 호스트 URL 추가적으로 입력 (ex: https://kdt-gitlab.elice.io/)

(2) Credentials

     인증은 Personal Access Token 선택

     Personal Access Token 새로고침 버튼 클릭 > 본인 사용자 이름 입력 및 암호에 발급받은 Access Token 입력

 

---

---

📚  3/23 - 개인 공부 (Docker 및 Jenkins)

 
오늘은 팀 프로젝트를 함께 진행 중인 팀원분과 상봉역 카페에서 만나, Python의 기본 문법부터 Selenium, pytest, 그리고 디렉토리 구조에 대해 설명해드렸다. 설명을 하면서 나 역시 기본 개념들을 다시 떠올릴 수 있어 유익한 시간이었다. 그리고 오늘 새롭게 알게 된 사실 하나! conftest.py 파일은 pytest가 자동으로 인식해 fixture를 가져올 수 있기 때문에, 다른 모듈처럼 import할 필요가 없다. 다만 이 파일은 테스트 파일과 같은 디렉토리 또는 상위 디렉토리에 있어야 자동 인식되며, 하위 디렉토리에 있는 conftest.py는 자동으로 읽히지 않는다.
 
Docker
 • Dockerfile
  ~> 나만의 Docker Image를 만들기 위한 조리법(레시피)
  ~> 어떤 OS를 기반으로, 어떤 패키지를 설치할지, 어떤 설정을 적용할지 한 줄씩 작성하는 스크립트
  ~> 쉽게 말해 "내가 원하는 개발 환경을 그대로 이미지로 만들 수 있는 설계도"
 • Docker Image
  ~> 일종의 설치 CD나 프로그램의 완제품 템플릿
  ~> 애플리케이션, 설정, 라이브러리 등 실행에 필요한 모든 요소가 포함된 불변한 상태의 패키지
 • Docker Container
  ~> 이미지를 기반으로 실행 중인 인스턴스
  ~> 쉽게 말하면, 이미지를 실행해서 만들어낸 독립적인 운영 환경
  ~> 여러 개의 컨테이너를 같은 이미지로부터 생성 가능
 • docker-compose.yml
  ~> 여러 개의 Docker 컨테이너를 한 번에 실행시키는 실행 매니저
  ~> 어떤 이미지를 실행할지, 포트를 어떻게 연결할지, 볼륨은 어디에 마운트할지 등을 정의
  ~> 쉽게 말하면 "Docker 환경 전체를 자동으로 세팅해주는 시나리오 파일"
 
GitHub Webhook을 설정할 때 공인 IP를 이용해 아래와 같이 설정했지만, 정상적으로 연결되지 않았다는 사실을 뒤늦게 알게 되었다.

• GitHub Webhook: http://{공인 IP}:8080/github-webhook/

즉, 21일에 진행했던 Jenkins 실습 당시에는 Job의 Build Steps에 python3 hello.py를 입력한 뒤 Jenkins에서 수동으로 Build Now 버튼을 눌러 실행했기 때문에, Jenkins와 GitHub 간 연동이 정상적으로 작동하는 줄로만 알고 있었다. 하지만 실제로는 Webhook이 제대로 연결되지 않았기 때문에, 이후 GitHub에서 push 이벤트가 발생해도 Jenkins가 자동으로 빌드되지 않는 상태였다. 이 사실은 오늘 GitHub 레포 내의 hello.py 파일을 수정하면서 알게 되었다.
GitHub Webhook 설정에 공인 IP를 사용했음에도 자동 빌드가 작동하지 않았던 이유는, 외부에서 해당 포트(8080)로 접근이 불가능한 환경이었기 때문이다. 이러한 문제는 공유기 포트포워딩 미설정, 로컬 방화벽 차단, 또는 ISP의 포트 제한 등 여러 가지 원인으로 발생할 수 있다.
하지만 이 모든 설정을 하나하나 확인하고 구성하는 과정이 복잡하고 번거롭기 때문에, GPT의 추천대로 ngrok을 활용해 Jenkins를 외부에 안전하게 노출시키는 방법으로 전환해보기로 했다.
 
공인 IP
 ~> 현재 내 공인 IP 확인 사이트
 ~> 공인 IP는 인터넷상에서 고유하게 식별되는 IP 주소로, 외부에서 접근 가능한 주소
 ~> 보통 가정이나 회사에서는 하나의 공인 IP를 공유기(라우터)가 가지고 있고, 그 아래에 여러 대의 컴퓨터들이 사설 IP를 통해 연결
 ~> Jenkins가 로컬 PC에 설치되어 있고, 외부(GitHub/GitLab)에서는 공인 IP로 접속을 시도하더라도 다음과 같은 이유로 실패 가능
  • 공유기에서 포트포워딩 설정이 안 되어 있음
  • 로컬 방화벽에서 8080 포트를 차단 중
  • 인터넷 제공업체(ISP)에서 포트 차단 정책이 있음
 
ngrok
 ~> 로컬에서 실행 중인 웹 애플리케이션(예: Jenkins)을 외부에서 접속 가능하도록 만들어주는 도구
 ~> 즉, ngrok이 제공하는 임시 퍼블릭 주소를 통해 공인 IP 없이도 외부에서 내 Jenkins에 접근 가능
 ~> ngrok은 실시간 터널링 중계 프로그램이므로, ngrok이 실행 중인 동안에만 생성된 Forwarding 주소가 유효
 
🔥 ngrok 설치 방법

[ 공식 사이트에서 다운로드 및 압축 풀기 ]

https://ngrok.com/downloads/windows?tab=download

 

[ ngrok 회원가입 및 인증 토큰 발급 ]

https://ngrok.com/

Identity & Access > Authtokens > Add Tunnel Authtoken

 

[ 인증 토큰 등록 (in ngrok.exe) ]

ngrok config add-authtoken {발급 받은 토큰}

 

[ Jenkins용 포트 8080 터널링 실행 (in ngrok.exe) ]

ngrok http 8080

 

 > ngrok이 생성한 Forwarding 주소 예시

 

---

 
Jenkins
🔥 GitLab 저장소 연결을 위해 필요한 플러그인

[ Docker 컨테이너 내부에 플러그인 설치 (in cmd) ]

docker exec -it {컨테이너 이름} bash

 > Jenkins 컨테이너 내부로 진입

 

jenkins-plugin-cli --plugins git:5.7.0

 > Git SCM 지원: Jenkins가 Git 저장소에서 코드를 클론하고 가져올 수 있게 해줌

 

jenkins-plugin-cli --plugins gitlab-plugin:1.9.7

 > GitLab 연동: GitLab Webhook, GitLab credentials, GitLab SCM UI 연동 등을 담당

 

해당 컨테이너 Stop & Start

 > Jenkins 플러그인은 설치 후 반드시 재시작해야 적용

 

---

🔥 컨테이너 내부에 Python3, 가상 환경, Chrome 설치

[ 루트 권한으로 Docker 컨테이너 내부 진입 (in cmd) ]

docker exec -it --user root {컨테이너 이름} bash

 > 루트 권한으로 컨테이너에 진입

 

[ Python3 설치 (in cmd) ]

apt update

apt install -y python3 python3-pip

 > Python3 및 pip 설치

 

[ 가상 환경 설치 (in cmd) ]

apt-get update
apt-get install -y python3-venv

 > 필요 패키지 및 가상 환경 설치

 

[ Chrome 설치 (in cmd) ]

apt-get update
apt-get install -y wget gnupg2 curl unzip

 > 필요 패키지 설치

 

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
apt-get install -y ./google-chrome-stable_current_amd64.deb

 > Chrome 설치

 

---

🔥 headless 옵션 추가

import pytest
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

@pytest.fixture
def createDriver():
    chromeOption = Options()

    chromeOption.add_argument('--start-maximized') # 전체 화면
    chromeOption.add_argument('--incognito') # 시크릿 모드
    chromeOption.add_argument("--headless") # GUI 없이 테스트
    chromeOption.add_argument("--no-sandbox") # 브라우저의 보안 기능 없이 테스트
    chromeOption.add_argument('--disable-dev-shm-usage')  # shared memory 문제 방지
    chromeOption.add_argument('--disable-gpu')  # 가상환경에서 GPU 기능 비활성화
    
    driver = webdriver.Chrome(options=chromeOption)

    yield driver

    driver.quit()

.🔥 의존성 파일(requirements.txt) 추가

pytest
selenium

🔥 Jenkinsfile 추가

pipeline {
    agent any
    
    stages {
        stage('Run Tests') {
            steps {
                sh '''
                    python3 -m venv venv
                    . venv/bin/activate
                    pip install -r requirements.txt
                    python3 -m pytest
                '''
            }
        }
    }
}

🔥 GitLab과 Jenkins 연동 방법

[Jenkins] Jenkins GitLab 프로젝트 연동하기 01

[Jenkins] Jenkins GitLab 프로젝트 연동하기 02

[Jenkins] Jenkins GitLab 프로젝트 연동하기 03

 > Webhook URL에서 http://localhost:8080 부분을 ngrok이 생성한 Forwarding 주소로 변환

 

---

---

📌 3/24 - 2일차 회고 (대상 서비스 기능 명세서를 바탕으로 TC 작성)

 

오늘은 본격적인 작업에 앞서 간단한 스크럼 회의를 진행했다. 팀원별로 작성한 테스트 케이스를 함께 검토하고 피드백을 주고받았으며, AI 기반 기능(취합률, DB 저장소 등)의 구조 및 처리 방식에 대해 논의했다. 이어 사이트 전반을 분석하며 엣지 케이스와 누락된 오류들을 추가로 확인하고 공유했다.
테스트 케이스의 방향성도 명확히 재정의했다. QA 대상 홈페이지의 UI와 기능을 사용자 관점에서 다시 점검해, 테스트 케이스의 현실성을 높였다. 처음에는 회원가입, 후기관리, 데이터 시각화처럼 기능 단위로 테스트 케이스를 나눴는데, 실제 사용자 관점에서는 이런 기능들이 탭 안에서 통합적으로 동작한다는 점을 깨달았다. 그래서 이후에는 사이트 구조에 맞춰 '홈', '개인 피드', '팀 피드', '히스토리' 탭별로 테스트 케이스를 다시 정리했다. 이 방향 전환 덕분에 테스트 현실성이 높아졌고, 자동화 코드 작성도 한결 수월해졌다.
 
와 그리고 오늘 알게된 사실.. GitHub Desktop으로도 GitLab을 사용할 수 있었다..(사이트 바로가기)

---

📌 3/25 - 3일차 회고 (TC 작성 마무리)

경력이 없어서인지 가장 기본적인 TC인 회원가입과 로그인 파트를 맡게 되었고, 덕분에 나는 TC 작성을 가장 먼저 마무리할 수 있었다. 오후 7시에 예정된 오피스 아워 시간에 작성한 TC에 대한 피드백을 요청하기로 했고, 아직 다른 분들은 TC 작성을 진행 중이었기 때문에, 남는 시간 동안 GitLab 개인 프로젝트를 활용해 GitLab과 Jenkins 연동에 도전해보았다.
다행히 오늘은 약 3시간 만에 GitLab과 Jenkins를 정상적으로 연동했고, GitLab 프로젝트 내 Jenkinsfile을 통해 파이프라인이 제대로 동작하는 것까지 확인할 수 있었다. 이 작업을 2일 넘게 붙잡고 있었던 터라, Webhook 연동과 빌드 성공 메시지를 봤을 땐 정말 진심으로 기뻤다. 그래도 이틀 동안 여러 가지를 시도해본 덕분에 결국 문제를 해결할 수 있었던 것 같다. 그 과정에서 ngrok이라는 툴도 새롭게 알게 되어 활용할 수 있었다. 내 로컬 서버(localhost:8080)는 외부에서 직접 접근할 수 없었기 때문에, ngrok을 통해 외부에서도 접속 가능한 주소를 생성해 Webhook 연결을 테스트할 수 있었다.
 
현재는 Docker 환경에서 jenkins/jenkins 공식 이미지를 바로 사용해 Jenkins 컨테이너를 실행하고 있으며, 파이썬이나 크롬 등의 도구는 매번 수동으로 컨테이너 내에 설치해 사용하고 있다. 하지만 Dockerfile을 활용해 커스텀 이미지를 만들어두면, 이러한 도구들이 미리 설치된 Jenkins 컨테이너를 자동으로 실행할 수 있어 매번 수동 설치할 필요가 없다. 이렇게 하면 팀원들도 동일한 환경을 손쉽게 구축할 수 있어 설정 과정이 훨씬 간편해진다. 그래서 이번에 직접 도전해보기로 했다.
 
🔥 Dockerfile 생성 (Jenkins + Git Plugin + GitLab Plugin + Python3 + 가상 환경 + Chrome)

[ Dockerfile 생성 ]

FROM jenkins/jenkins:lts

USER root

# 필수 도구 설치
RUN apt-get update && apt-get install -y \
    python3 python3-pip python3-venv \
    git \
    curl wget unzip gnupg2 && \
    apt-get clean

# Chrome 설치
RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb && \
    apt-get install -y ./google-chrome-stable_current_amd64.deb && \
    rm google-chrome-stable_current_amd64.deb

# Git, GitLab 플러그인 직접 설치
RUN jenkins-plugin-cli --plugins \
    git \
    gitlab-plugin \
    workflow-aggregator \
    credentials-binding

USER jenkins

 

[ Dockerfile 빌드 (in VS Code 터미널) ]

위 Dockerfile이 담긴 폴더를 VS Code로 열기

docker build -t {이미지 이름} .

 

[ Jenkins 컨테이너 실행 (in VS Code 터미널) ]

docker run -d -p {외부 포트}:{컨테이너 내부 포트} -p 50000:50000 --name {컨테이너 이름} {이미지 이름}

 

---

 

정상적으로 동작한다! Plugin부터 Python3, 가상 환경, Chrome까지 모두 설치된 Jenkins 커스텀 Dockerfile을 빌드해 이미지를 생성하고, 이 이미지로 컨테이너를 실행한 뒤 GitLab과 연동하니, 해당 GitLab 프로젝트 내의 Jenkinsfile도 잘 인식된다. 이제 위 모든 과정들을 생략하고 ngrok 설치와 Dockerfile만 공유하면, 팀원들도 빠르게 동일한 환경을 구성할 수 있을 것 같다.
 

TC 작성은 오늘을 마지막으로 최종 마무리했다. 솔직히 계속 수정하려면 끝도 없고, 본격적으로 코드를 작성하기 전에 환경 설정부터 해야 할 일들이 많다 보니, 언제까지나 TC만 붙잡고 있을 수는 없었다. 코드를 작성하면서 발견한 부분에 따라 TC를 수정해도 괜찮을 것 같아서, 오늘을 기준으로 일단락 짓기로 했다. 어차피 개발을 하다 보면 미처 생각하지 못했던 예외나 흐름도 자연스럽게 드러날 테니까..

---

📌 3/26 - 4일차 회고 (코드 작성 전 교육 진행 및 구조 설계)

 
🔥 자주 사용하는 import

import time
import pytest
import selenium

 

from selenium.webdriver.common.by import By

from selenium.webdriver.chrome.webdriver import WebDriver

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

from selenium.webdriver.common.keys import Keys

from selenium.webdriver.support.ui import Select

from selenium.webdriver.common.action_chains import ActionChains
from selenium.common.exceptions import NoSuchElementException, TimeoutException

 

---

 

팀원들이 아직 Python 문법(매개변수, 인자, 클래스, 객체, 생성자 등)에 익숙하지 않은 상태라, 오늘은 내가 Live Share 기능을 활용해 간단한 코드 강의를 진행했다. 평소에는 서로의 화면을 직접 보여줘야 하는 불편함이 있었지만, Live Share를 통해 동일한 코드에 함께 접속하면서 실시간으로 서로 질문하고 피드백 주고받을 수 있어 훨씬 효율적으로 설명할 수 있었다.
 
🔥 mainPage.py

# Page Object 클래스 (UI 요소 및 메서드 정의)

import json
import time
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.webdriver import WebDriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

from src.utils import mainLocators

class mainPage():
    URL = "https://kdt-pt-1-pj-2-team03.elicecoding.com/signin"

    def __init__(self, driver: WebDriver):
        self.driver = driver
        self.wait = WebDriverWait(self.driver, 10)

        with open("credentials.json", "r", encoding="utf-8") as f:
            self.userInfo = json.load(f)

    def goToPage(self, depth2):
        if (depth2 == "메인 페이지"):
            self.driver.get(self.URL)
        elif (depth2 == "회원가입 페이지"):
            self.driver.get(self.URL)
            self.getElement(mainLocators.REGISTER_BTN).click()
            # 첫번째 여기서 url 검증
        elif (depth2 == "앱 인증 권한"):
            pass
        elif (depth2 == "로그인 오류 페이지"):
            pass
        elif (depth2 == "인적사항 작성 페이지"):
            pass
        elif (depth2 == "로그인 페이지"):
            self.driver.get(mainLocators.URL)
            self.getElement(mainLocators.LOGIN_BTN).click()
        elif (depth2 == "비밀번호 재설정 페이지"):
            pass

    def getElement(self, element):
        result = self.wait.until(EC.presence_of_element_located(element))
        return result

🔥 test_mainPage.py

# 실제 테스트 스크립트 (test_*.py 형식)

import time
import pytest
import inspect
from src.pages.mainPage import mainPage

# 구글 스프레드 시트 참고 (depth2 기준으로 하고, 옆에 test id 열 추가)
def test_login_001(createDriver):
    try:
        myMainPage = mainPage(createDriver)
        myMainPage.goToPage("메인 페이지")
        time.sleep(2)

        assert "signin" in myMainPage.driver.current_url
    except Exception as e:
        print(f"[❗] {e}")

def test_login_002(createDriver):
    myMainPage = mainPage(createDriver)
    myMainPage.goToPage("로그인 페이지")
    time.sleep(2)

def test_login_003(createDriver):
    myMainPage = mainPage(createDriver)
    myMainPage.goToPage("회원가입 페이지")
    time.sleep(2)

🔥 mainLocators.py

from selenium.webdriver.common.by import By

# 메인 페이지 요소
LOGIN_BTN = (By.XPATH, "//button[text()='로그인하기']")
REGISTER_BTN = (By.XPATH, "//button[text()='회원가입']")

ID_INPUT = (By.ID, "username")
PW_INPUT = (By.ID, "password")

PW_TOGGLE_BTN = (By.XPATH, "//button[@data-action='toggle']") #속성은 @로 찾기
PW_RESET = (By.XPATH, "//button[text()='비밀번호를 잊으셨나요?']")

GOING_BTN = (By.XPATH, "//button[text()='계속하기']") #텍스트는 @생략

작성한 테스트 케이스(TC)를 바탕으로 자동화 코드를 구현해야 하므로, TC 하나당 테스트 함수 하나씩 매핑해서 작성할 계획이다. 그런데 막상 코드를 짜다 보니, 페이지 이동이나 공통된 동작들이 반복적으로 등장해서 코드가 너무 중복되는 문제가 있었다. 그래서 이런 반복되는 부분은 별도의 함수로 분리하면 유지보수도 훨씬 쉬워지고, 전체적인 코드 구조도 더 깔끔해질 것 같다는 생각이 들어 goToPage() 함수를 만들었다.
 

오피스아워 시간에는 중복되는 페이지 이동 과정을 함수로 분리한 방식에 대해 코치님께 피드백을 요청드렸다. 원래 실무에서도 테스트 케이스(TC) 하나당 테스트 함수 하나로 구현하는 것이 일반적이며, 자동화 테스트에서는 TC가 코드 구조의 기준이 되므로, 내가 시도한 중복 로직 분리 방식은 나쁘지 않다고 하셨다.
다만 본인이라면 goToPage()와 같은 공통 이동 함수는 Util 모듈로 따로 빼고, 각 페이지 클래스 내에서는 goToSecondaryPage()처럼 해당 페이지 내의 세부 이동은 내부 함수로 처리할 것 같다고 하셨다. 이 방식이 더 효율적인지에 대해서는 검토해볼 필요가 있을 것 같다.
페이지 요소 관련 변수를 mainPage.py와 test_mainPage.py 두 파일에서 모두 사용하는 경우, 해당 변수들을 별도 Util 모듈로 분리해 관리하는 것이 더 깔끔하다는 피드백을 받았다. 이에 따라 일부 구조를 개선해, 요소를 Util에서 import해 사용하는 방식으로 변경했다. 또한 페이지별로 locator 파일을 따로 관리하면, 요소 변경 시 유지보수가 쉬워지고, 필요한 요소는 import만으로 편리하게 접근할 수 있다는 장점도 있어 이 구조를 채택했다.
특히 나는 해당 요소가 어떤 방식(id, name, xpath 등)으로 정의되었는지까지 함께 명시하는 것이 좋다고 판단해, locator를 튜플 형태로 정의했다. 이 튜플은 wait 기능을 포함한 getElement() 함수에 그대로 넘겨 사용할 수 있게 설계했다. 이렇게 정리한 구조는 재사용성, 가독성, 유지보수 측면에서 모두 만족스러웠고, 무엇보다 코드 작성 시 생각의 흐름이 명확해져서 개인적으로도 매우 만족스러운 리팩토링이었다.

---

📌 3/27 - 5일차 회고 (TC를 바탕으로 본격적인 자동화 코드 작성)

 

오늘은 팀원분들께서 로그인/회원가입 페이지의 UI 요소들을 모두 식별해주셨고, 해당 요소들은 공통 Util 파일로 분리하여 정리했다. 나는 이 과정에서 기존 테스트 케이스들을 함께 검토하면서, 하나의 테스트 함수 안에서 동시에 검증하는 것이 효과적인 케이스들을 묶어 재구성했다. 그 결과, 로그인/회원가입 페이지 관련 총 64개의 테스트 케이스를 분석해 25개의 테스트 함수로 나누었고, 각 묶음에는 별도의 테스트 함수 ID를 부여해 체계적으로 관리했다. 또한, 중복되는 동작은 별도 함수로 분리해 재사용할 수 있도록 정리했다.
이렇게 기본적인 준비를 마친 뒤, 본격적으로 테스트 자동화 코드 작성을 시작했다. 아직은 교육 및 연습 단계이기도 해서, 팀원들과 로그인/회원가입 페이지를 함께 작업하며 협업을 시도했다. 하지만 이 과정에서 Live Share의 한계를 뼈저리게 느꼈다. 각자의 로컬 환경에서는 테스트 실행이 어려웠기 때문에, 모든 테스트 실행은 내 컴퓨터에서만 가능했고, 팀원분들이 테스트를 요청할 때마다 내 작업은 중단될 수밖에 없어 코드 작성 속도가 현저히 느려졌다.
게다가 테스트 도중 오류가 발생하면, 오류 원인과 개념을 설명하고 직접 수정을 도와야 했기 때문에 작업에 대한 집중도가 자주 분산되었다. 물론 팀원들의 서로 다른 숙련도를 고려해 함께 공부하며 진행한 점은 의미 있었지만, 지금은 단순한 학습이 아닌 실제 결과물을 만들어야 하는 프로젝트이기 때문에, 역할을 분담해 보다 효율적으로 작업을 진행하는 것이 필요하다고 느꼈다.
남은 시간이 많지 않다는 현실적인 제약도 있어, 계속 함께 붙잡고 작업하기엔 어려움이 있었다. 그래서 각자가 작성한 테스트 케이스(TC)와 관련된 페이지를 개별적으로 맡아 자동화 구현을 진행하는 방식으로 전략을 변경했다.

내일부터는 본격적으로 각자의 TC와 관련된 코드 구현이 시작될 예정이었기 때문에, 나는 팀원들이 바로 작업에 투입될 수 있도록 각자의 코드 틀을 미리 잡아주는 작업도 함께 진행했다. 각 페이지별로 필요한 파일을 생성하고, 클래스 구조와 생성자 세팅, 전체적인 틀을 먼저 구성해 두었다. 이렇게 기본 골격이 잡힌 상태에서 시작하면 혼란을 줄이고, 각자 구현에 좀 더 집중할 수 있을 거라 판단했다.

나는 회원가입과 로그인이 포함된 메인 페이지의 테스트 케이스를 담당하고 있었기 때문에, 해당 페이지부터 빠르게 자동화 코드를 완성한 뒤, 다른 팀원들이 맡은 페이지 구현도 도울 계획이다. 이렇게 역할을 분배하면 전체 진행 속도를 높일 수 있고, 결과물 완성에도 보다 가까워질 수 있을 것 같다는 판단이 들었다.
 

그리고 각자 페이지를 맡아 작업을 진행하려면, 기본 개념에 대한 정확한 이해가 필수적이라고 판단했다. 특히 팀원분들께서 헷갈려하시는 클래스, 객체, self, 생성자 같은 개념은 반복적으로 설명하는 상황이 자주 발생했고, 같은 내용을 여러 번 설명하는 것이 점점 비효율적이라는 생각이 들었다.
그래서 오늘은 밤 10시 30분에 집에 도착하자마자, 피곤한 몸을 이끌고 아이패드를 꺼내 들었다. 그리고 굿노트를 이용해 해당 개념들을 정리한 PDF 자료를 만들어 팀원들과 공유했다. 사실 나도 프로그래밍을 처음 배울 때 이 개념들이 정말 헷갈렸던 기억이 있어서, 팀원들의 어려움에 충분히 공감할 수 있었다.
한 번 정리해두면 이후 설명에 드는 시간도 줄어들고, 팀원들도 각자 구현을 진행하는 데 훨씬 수월할 것 같아 늦은 시간이었지만 서둘러 정리해 공유하게 됐다.

---

📌 3/28 - 6일차 회고 (메인 페이지 자동화 테스트 구현 완료)

 

오늘은 어제 팀원분들께서 찾아주신 메인 페이지 내 요소들을 바탕으로, 변수명을 페이지 구조에 맞게 전반적으로 수정했다. 가독성과 유지보수 편의성을 고려해 이름을 일관되게 정리했으며, 그 과정에서 잘못 지정된 요소들도 꽤 많아 내가 직접 하나씩 페이지를 확인하면서 전부 검토하고 수정했다. 요소 정리가 마무리된 뒤에는 이를 기반으로 메인 페이지와 관련된 총 25개의 테스트 함수 구현을 완료할 수 있었다.
각 테스트 케이스마다 하나의 테스트 함수를 구현했기 때문에, 테스트 함수 이름을 구글 스프레드시트에 정리된 테스트 함수 ID와 동일하게 맞추었다. 또한, 테스트가 pass된 경우 해당 함수 이름을 자동으로 불러올 수 있도록 inspect 라이브러리를 활용하는 방안을 제안했고, 모두가 그 방식에 만족하여 정식으로 채택하게 되었다. 이를 통해 자동화 결과 로그를 확인하면서, 어떤 테스트 케이스가 통과(pass)되었는지 테스트 함수 ID 기준으로 직관적으로 파악할 수 있어 테스트 결과 분석이 훨씬 수월해질 것으로 기대된다.
슬라이더 자동화에서는 꽤 많은 시간을 허비했지만, 결국 ActionChains를 활용해 원하는 동작을 구현하는 데 성공했다. 처음에는 제대로 작동하지 않아 당황했지만, 직접 하나씩 테스트해보며 ‘내가 어떤 행동을 했을 때 요소의 속성값이 어떻게 바뀌는지’, ‘그 변경된 속성값을 기준으로 테스트가 성공했는지를 어떻게 검증할 수 있을지’, ‘해당 요소의 속성값 중 어떤 값을 기준으로 하면 더 정확하고 안정적으로 요소를 찾을 수 있을지’ 같은 부분들을 하나씩 체득해나가고 있다는 느낌이 들었다. 예전에는 단순히 보이는 UI만 따라갔다면, 이제는 실제 요소의 구조와 변화를 직접 파악하고 활용할 수 있는 수준으로 성장하고 있다는 게 느껴져서 뿌듯했다.
그리고 오늘 Jenkins 관련해서 중요한 공지가 전달됐다. 다른 팀의 한 분이 GitLab 레포지토리와 Jenkins를 SSH 방식으로 연동하는 시도를 하셨던 모양인데, 이 방식은 GitLab의 공유 러너가 자동으로 작동하면서 Merge 시 충돌 문제가 발생할 수 있다고 한다. 이에 따라 코치님께서 세 가지 대안 방법을 안내해주셨다.
 

• Ngrok을 이용한 로컬 터널링 방식
  → 이건 바로 내가 며칠 전에 직접 시도해서 성공했던 방법! 다만 이 방식은 Ngrok의 특성상 주소가 매번 바뀌기 때문에, 지속적인 사용에는 다소 불안정한 면이 있다.
• 공유 서버를 이용한 CI 구축 (추천)
  → 각 팀별로 공유 서버가 제공될 예정이며, 세팅이 완료되는 대로 팀별 안내가 있을 예정이라고 한다. 이 방법이 가장 안정적이라 추후 다시 시도해봐야 할 것 같다.
• GitLab 공유 러너를 비활성화한 뒤 SSH 방식으로 연동
  → 공유 러너가 자동으로 작동하지 않도록 설정한 후, SSH 방식으로 Jenkins와 GitLab을 연결하는 방식이다.

 

오피스아워 시간에 코치님께서 실무에서 요소를 찾는 방식에 대해 설명해주셨다. 실제로는 전체 컨테이너를 먼저 불러온 뒤, 그 안에서 필요한 요소에 접근하는 식으로 작업한다고 하셨고, 이런 방식이 더 안정적이고 유지보수에도 유리하다고 하셨다.
또한 실무에서는 테스트를 진행할 때, ‘해당 페이지에 <h1> 태그가 몇 개 있는지’처럼 단순한 기준을 활용하는 경우도 많다는 팁도 주셨다. 이유는 간단하다. 예를 들어, 개발자가 기능을 추가하면서 <h1> 태그가 하나 더 생기면, 테스트에서도 그 변화를 자연스럽게 감지할 수 있기 때문에, “아, 뭔가 추가됐구나” 하고 빠르게 파악할 수 있다는 것이다. 이처럼 페이지 구조 변경에 유연하게 대응할 수 있고, 세부 요소를 일일이 지정하지 않아도 변화 감지가 가능한 방식이 오히려 실무에서는 더 실용적일 수 있다는 점이 인상 깊었다.

---

📚 3/29 - 개인 공부 (개인 피드 탭 자동화 테스트 구현 시작)

 
오늘은 팀원 세 분이 각자 맡은 홈 탭, 팀 피드 탭, 히스토리 탭을 제외하고, 아직 아무도 작업하고 있지 않은 개인 피드 탭의 자동화 테스트를 맡아 진행했다. 서로 다른 장소에서 작업 중이기 때문에, 동일한 영역을 동시에 작업하면 충돌이 발생할 수 있어 가능한 겹치지 않는 영역을 맡는 게 안전하다고 판단했다. 그래서 개인 피드 탭을 맡아 오늘 하루 약 10시간을 집중 투자했다.
자동화 테스트를 구현하기 전, 기존 테스트 케이스들을 함께 검토하면서, 하나의 테스트 함수 안에서 동시에 검증하는 것이 효과적인 케이스들을 묶어 재구성했다. 그 결과, 개인 피드 탭과 관련된 총 111개의 테스트 케이스를 분석해 17개의 테스트 함수로 나누었고, 각 묶음에는 별도의 테스트 함수 ID를 부여해 체계적으로 관리했다.
 
그런데 로그인/회원가입 페이지에 비해 개인 피드 탭의 요소를 찾는 게 상당히 까다로웠다.

• visible 또는 clickable 상태가 될 때까지 명시적으로 기다려야 하는 요소들이 있었고,
• scroll로 화면을 내려야만 접근 가능한 요소들도 존재했다.

 
이로 인해 요소를 안정적으로 탐색하고 식별하는 데에만 전체 작업 시간의 절반 이상이 소요됐다. 게다가 오늘 찾은 요소들도 전체가 아니라, 테스트 함수를 작성하는 도중 그때그때 필요한 요소만 탐색한 수준이었다. 결국 오늘 하루 동안은 총 17개의 테스트 함수 중 단 5개만 구현할 수 있었지만, 그 과정에서 느낀 점도 많았다. 특히 ‘요소 찾기’에 대한 감각이 확실히 향상되었다는 점에서 기술적인 성장은 분명한 하루였다. 속도는 기대만큼 빠르지 않았지만, 완성도를 위한 발판을 튼튼히 다졌다고 생각한다.
 
🔥 요소 찾기 Tip

• /.. : 해당 요소의 부모
• /preceding-sibling : 해당 요소의 같은 부모 아래, 앞에 있는 형제
• /following-sibling : 해당 요소의 같은 부모 아래, 뒤에 있는 형제
• <svg>는 HTML이 아니라 SVG 네임스페이스(XML 기반)

 > //svg 또는 //preceding-sibling::svg 처럼 사용시 실패 확률 높음
 > *[name()='svg'] 처럼 네임스페이스 무시하고 svg 태그로 정확하게 인식

 > 네임스페이스 : HTML이나 XML에서 같은 이름의 태그가 충돌하지 않도록 구분해주는 것

 

---

---

📅 3/30 - 팀 모임 (이전 작업 이어 각자 자동화 코드 개발)

 

오늘은 평일 작업만으로는 시간이 부족할 것 같아, 주말임에도 팀원 모두가 시간을 내어 함께 모였다. 각자 맡은 페이지의 기능 구현을 계속 이어갔고, 나는 여전히 개인 피드 탭 자동화 함수 구현에 집중적으로 시간을 투자했다.
작업이 생각보다 효율적으로 진행된 이유 중 하나는, 팀원들이 각자 미리 잘 정리해둔 요소들 덕분이었다. 나 역시 사전에 정리해둔 요소들을 팀원들과 공유했고, 서로의 작업에 실질적인 도움이 되었다는 점이 인상 깊었다. 각자 맡은 영역을 문서화하고 공유하며 활용하는 방식이 우리 팀에게 잘 맞았던 것 같다. 게다가 페이지 간 기능 구조도 유사해서, 한 번 제대로 만든 요소 정의나 함수는 여러 테스트에서 반복적으로 재사용할 수 있었다. 이러한 구조 덕분에 전체 작업 속도도 생각보다 더 빠르게 진행될 수 있을 것 같다는 예감이 든다.
그리고 오늘 새롭게 알게 된 팁 하나! CLASS NAME 셀렉터를 사용할 때, 클래스가 여러 개인 요소는 정확하게 선택되지 않는 경우가 있다는 점을 경험했다. 그래서 이후에는 CSS selector를 사용하는 것이 더 정확하고 유연하다는 걸 새롭게 배웠다.
현재 목표는 화요일까지 코드 구현을 모두 마무리하고, Jenkins 연동까지 완료하는 것. 하루 만에 가능하겠지…?

---

📌 3/31 - 7일차 회고 (개인 피드 자동화 테스트 구현 완료)

 

엘리스 Lab에 도착하자마자 Jenkins 관련 공지가 도착했다. 놀랍게도 엘리스 측에서 공유 서버를 제공해준다는 소식!
덕분에 더 이상 로컬에서 터널링을 위해 ngrok을 쓰지 않아도 될 것 같다. 그동안 ngrok을 쓸 때마다 주소가 계속 바뀌어서 번거로웠는데, 공유 서버 덕분에 이 문제도 어느 정도 해결 가능할 것 같다. 이제 Jenkins를 좀 더 안정적으로 사용할 수 있을 듯!
 

공유 서버를 제공받자마자 몇 가지 의문이 바로 떠올랐다.

• 내가 만든 Docker 이미지를 그대로 써도 되는 걸까?
• 고정 IP라서 외부 접속이 더 편해진 건가?
• 그렇다면 그냥 로컬에서 하던 방식 그대로 진행하면 되는 건 아닐까?

궁금한 걸 바로 GPT에게 물어봤는데, 생각보다 놀랍게도(?) 내가 떠올린 의문이 전부 맞는 말이었다. 결론적으로는, 환경만 바뀌었을 뿐, 기존에 하던 방식 그대로 진행하면 된다. 서버 위치만 달라졌을 뿐, Docker도 Jenkins도 설정 방식도 전부 동일하고, 오히려 고정 IP 덕분에 외부 연동이 더 안정적이고 쾌적해진 느낌이다.

드디어.. 개인 피드 테스트 함수 구현 완료! 오늘은 팀원들 각자 맡은 페이지 구현에 집중하느라, 뭔가 새롭고 인상 깊은 인사이트를 얻었다기보다는, 전체 작업을 정리하고 디테일을 마무리하는 데 초점이 맞춰진 하루였다.
 
그나마 기억에 남는 건...

• fixture에 다양한 옵션을 추가해보니 테스트 속도가 확 줄었다.
• implicitly_wait을 설정해두니 요소가 바로 안 보여도 n초까지 기다려줘서, time.sleep이랑 병행하니까 자꾸 발생하던 timeout이 싹 사라졌다.

아주 작은 설정 하나가 전체 안정성에 꽤 큰 차이를 만들 수 있다는 걸 다시 느꼈다.
 
남은 기간 동안 내가 할 일 정리

• 팀원분들 코드 함께 리뷰하기
• Jenkins 연동 집중적으로 시도해보기
• 각 assert에 log 출력 넣기 (다만 전체 테스트 성공인지, assert 하나하나의 성공인지는 구분해서 적을 것)
• 아이콘 글머리 기호에 있는 [ ] 같은 대괄호 제거
• 사용하지 않는 폴더 정리: config, testdata
• 불필요한 함수 제거: getVisibilityElement, isContainAllField (in myFeed class)
• 의미 없는 주석 제거

 
결론적으로는, 지금 내 역할은 코드 정리 마무리 + Jenkins 연동 시도!
시간이 좀 남는다면 테스트 코드 리팩토링이나 강의에서 배운 @pytest.mark.parametrize 같은 기능도 하나씩 적용해보면 좋을 것 같다.

---

📌 4/1 - 8일차 회고 (Jenkins 연동 성공 / 테스트 로그 추가 및 리팩토링)

 

나는 내가 맡은 페이지들의 자동화 코드 구현을 모두 마친 상태였기 때문에, 오늘은 다른 팀원분들이 각자 맡은 페이지 구현을 계속 진행하는 동안 본격적으로 Jenkins와 GitLab 연동 작업에 도전했다.
연동에 앞서, 코치님께 내가 시도하려는 방식에 대해 먼저 여쭤봤는데, 엘리스 측에서는 hostname, user, password, public IP, 그리고 접속 방법까지만 안내되었는지 확인하시더니 포트 설정에 대한 부분도 함께 체크해보는 게 좋겠다고 조언해주셨다. 그래서 바로 매니저분께 포트 관련 문의를 드렸고, 그에 대한 답변을 받아 포트 정보까지 포함한 연동에 필요한 모든 정보를 확보할 수 있었다.
 
포트
 ~> 하나의 컴퓨터(서버) 안에서 여러 개의 프로그램이 동시에 통신할 수 있도록 해주는 ‘문’ 역할 (즉, IP 주소는 ‘건물 주소’, 포트 번호는 ‘그 주소 안의 문 번호’)
 ~> 포트가 "열려 있다'는 건? 서버의 방화벽(UFW, iptables 등) 혹은 클라우드 보안 그룹이 해당 포트로의 외부 접속을 허용해준 상태라는 뜻

서비스	IP 주소	포트 번호	전체 주소
웹 서버 (Nginx)	211.175.242.65	80	http://211.175.242.65:80
Jenkins	211.175.242.65	8080	http://211.175.242.65:8080
DB (MySQL)	211.175.242.65	3306	211.175.242.65:3306

 ~> 같은 서버에서 여러 서비스가 동작할 때, 이처럼 같은 IP를 가진 서버에서도 포트가 다르면 서로 다른 서비스에 접속 가능
 
🔥 변경 사항

[ 기존 방식 - Jenkins 컨테이너 실행 (in VS Code 터미널) ]

docker run -d -p 8080:8080 -p 50000:50000 --name {컨테이너 이름} {이미지 이름}

 > 기존에는 이렇게 실행했는데, 이 방식은 로컬 환경에서만 가능했던 방식이다.

 > 기존에는 내 컴퓨터에서 직접 접속하는 구조였기 때문에, 8080:8080처럼 내부 포트와 외부 포트를 동일하게 연결해도 문제 X

 

[ 변경된 방식 - Jenkins 컨테이너 실행 (in VS Code 터미널) ]

docker run -d -p {외부 포트}:{컨테이너 내부 포트} -p 50000:50000 --name {컨테이너 이름} {이미지 이름}

 > 하지만 공유 서버 환경에서는 서버 외부에서 열려 있는 포트가 정해져 있다.

 > 8080은 Jenkins 내부에서 고정된 포트이기 때문에 컨테이너 내부 포트는 절대 바꾸면 안 된다.

 > 바꿔야 하는 건 외부 포트이며, 열려 있는 포트를 사용하는지 꼭 확인이 필요하다.

 

---

 
🔥 시도 과정

[ 참고사항 ]

엘리스에서 제공한 서버는 Ubuntu 서버이므로 GUI 환경 제공 X

 > 따라서 Docker는 터미널 명령어를 통해 조작

 

[ 공유 서버에 SSH로 접속 (in cmd) ]

ssh {user}@{Public IP}

 > 공유 서버에 원격 접속

 

[ 컨테이너 실행 시도 중, Docker 미설치로 실행 실패 ]

docker run -d -p 3000:8080 -p 50000 50000 team5:jenkins_custom

 > 해당 서버에 Docker가 설치되지 않아 컨테이너 실행 실패

 

[ docker 설치 (in cmd) ]

sudo apt update

 > 기존 패키지 업데이트

sudo apt install -y docker.io

 > Docker 설치

 

[ Dockerfile이 있는 폴더 전체를 서버로 복사 (in VS Code 터미널) ]
위 Dockerfile이 담긴 폴더를 VS Code로 열기

scp -r . {user}@{Public IP}:{서버에서 복사될 경로}

 > 커스텀 Jenkins 이미지 생성을 위한 Dockerfile이 담긴 폴더를 서버로 복사

 

[ 복사한 폴더로 이동 후 이미지 빌드 (in cmd) ]

ssh{user}@{Public IP}

 > 공유 서버에 원격 접속

cd ~/jenkins-docker

 > 복사한 폴더로 이동

ls

 > 파일이 정상적으로 복사되었는지 확인

sudo docker build -t {이미지 이름} .

 > 관리자 권한으로 Dockerfile 기반 커스텀 이미지 생성

sudo docker images

 > 관리자 권한으로 Dockerfile 기반 커스텀 이미지 생성 확인

 

[ 생성된 이미지를 기반으로 컨테이너 실행 (in cmd) ]

sudo docker run -d -p{외부 포트}:{컨테이너 내부 포트}-p 50000:50000 --name {컨테이너 이름} {이미지 이름}

 > 관리자 권한으로 Jenkins용 컨테이너 실행 후, 외부에서 접근 가능한 상태로 구동

 

[ 웹 브라우저를 통해 Jenkins 접속 ]

http://{Public IP}:{외부 포트}

 > 웹 브라우저를 통해 Jenkins에 접속

 

[ Jenkins 초기 관리자 비밀번호 확인 (in cmd) ]

sudo docker exec {컨테이너 이름} cat /var/jenkins_home/secrets/initialAdminPassword

 > 관리자 권한으로 초기 비밀번호 출력

 

[ 연동 성공했지만, 문제 발생 ]

"No such file or directory: 'credentials.json" 오류 발생

 > 현재 프로젝트는 credentials.json 파일 안에 저장된 id와 pw를 읽어와 로그인하는 구조

 > 이 파일은 민감한 정보를 담고 있기 때문에 .gitignore에 추가해두었고, GitHub에도 올라가지 않도록 관리

 > Jenkins에서 해당 스크립트를 실행할 때는 이 파일이 존재하지 않기 때문에, 파일을 찾지 못한다는 에러가 발생

 > 이 문제를 코치님께 질문해보니, Jenkins 내의 Credentials 기능을 통해 해결할 것을 추천

 

[ 파일 등록 성공했지만, 문제 발생 ]

"cannot create credentials.json: Permission denied" 오류 발생

 > Secret file로 credentials.json 파일을 등록했을 때, 처음엔 잘 동작했지만, 어느 순간부터 권한 오류가 계속 발생

 > Secret text로 바꿔보기도 했고, pipeline 코드도 여러 번 수정해봤지만 결국 계속 같은 권한 에러만 반복

 > 알고 보니 Jenkins가 credentials 등록 시, 컨테이너의 워크스페이스 내 job 디렉토리에 해당 파일을 생성하는데,
     처음 만들어졌던 파일(credentials.json)이 이미 존재한 상태에서 같은 이름으로 파일을 다시 복사하거나

     생성하려고 하면, 기존 파일이 읽기 전용(read-only) 이기 때문에 쓰기 권한이 없어서 에러가 발생한 것

 

[ 기존 코드 ]

pipeline {
    agent any

    environment {
        CREDS_JSON = credentials('credentials-json')
    }
    
    stages {
        stage('Run Tests') {
            steps {
                sh '''
                    cp "$CREDS_JSON" credentials.json
                    python3 -m venv venv
                    . venv/bin/activate
                    pip install -r requirements.txt
                    python3 -m pytest
                '''
            }
        }
    }
}

 

[ 수정된 코드 ]

pipeline {
    agent any
    
    stages {
        stage('Run Tests') {
            steps {
                sh '''
                    python3 -m venv venv
                    . venv/bin/activate
                    pip install -r requirements.txt
                    python3 -m pytest
                '''
            }
        }
    }
}

 > 즉, 처음 실행할 때는 cp "$CREDS_JSON" credentials.json 코드를 통해 Secret file이 정상적으로 복사되었기 때문에 아무런 문제가 발생하지 않았다.

 > 하지만 같은 코드를 반복 실행하면서, 이미 존재하던 credentials.json 파일에 다시 덮어쓰려다 cp 명령어에서 "Permission denied" 에러가 반복적으로 발생했다.

 > 결국 cp "$CREDS_JSON" credentials.json 이 한 줄을 제거하는 방식으로 문제를 해결했지만, 어떻게 보면 야매에 가까운 해결이다.

 > 시간 부족으로 급하게 처리하긴 했지만, 나중에 여유가 생긴다면 보다 안정적이고 깔끔한 방식으로 다시 한번 해결 방안을 찾아보고 싶다.

 

---

 

공유 서버를 통한 GitHub와 Jenkins 연동에는 성공했지만, 로컬에서 정상적으로 통과되던 테스트들이 Jenkins에서는 실패 하는 현상이 발생했다. 처음에는 같은 테스트 코드인데 왜 Jenkins에서만 실패하는지 의문이 들었다. 오피스 아워 시간에 코치님께 질문을 드렸고, 코치님도 실무에서 종종 겪는 문제라고 하셨다.
그 이유는 Jenkins 자체가 어느 정도 리소스를 점유하고 있기 때문이라고 설명해주셨다. 즉, 로컬에서 테스트를 돌릴 때와 Jenkins 서버에서 돌릴 때의 환경이 완전히 동일할 수 없으므로, 테스트 코드가 서버 환경에서도 안정적으로 동작할 수 있도록, 더 많은 대기 시간을 부여하거나 가장 느리게 로딩되는 요소를 기준으로 검증 타이밍을 조정하거나 실패 시 자동으로 스크린샷을 찍어 디버깅에 활용하는 방식 등을 사용해야 한다고 하셨다.
결국 Jenkins 환경에서의 테스트는 속도나 자원 처리 방식의 차이를 감안해서 좀 더 유연하고 방어적인 방식으로 작성해야 한다는 점을 다시 한 번 느끼게 되었다. 시간상 이번 실습에서는 이 문제를 완전히 해결하지는 못했지만, 앞으로는 Jenkins와 같은 CI 환경에서도 안정적으로 동작할 수 있도록 테스트 코드 자체를 더 견고하게 설계할 필요성을 느꼈다.
 

@pytest.mark.ys
def test_myFeed_001(createDriver):
    try:
        myfeed = myFeed(createDriver)
        myfeed.goToPage("개인 피드")

        assert myfeed.getElement(myFeedLocators.MY_FEED_TXT)
        assert myfeed.getElement(myFeedLocators.MY_PROFILE_CHANGE_SVG)
        assert myfeed.getElement(myFeedLocators.MY_PROFILE_STAT_IMG)
        assert myfeed.getElement(myFeedLocators.MY_MENU_PLUS_BTN)
        assert myfeed.getElement(myFeedLocators.MY_EAT_SAME_MENU_BTN)
        myfeed.logger.info("▶️ myfeed_001 - 개인 피드 탭 선택 시 UI 요소 확인")

        myfeed.getElement(myFeedLocators.MY_FEED_BACK_PAGE).click()
        assert myfeed.getElement(myFeedLocators.HOME_TXT)
        myfeed.logger.info("▶️ myfeed_002 - [뒤로가기] 버튼 클릭 시 이전 페이지로 이동 확인")

        myfeed.logger.info(f"✅ {inspect.currentframe().f_code.co_name} 통과")
    except Exception as e:
        myfeed.logger.warning(f"❗ {inspect.currentframe().f_code.co_name} : {e}")
        raise

현재는 유사한 흐름이나 기능을 갖는 테스트 케이스들을 묶어, 하나의 테스트 함수 안에서 여러 TC를 동시에 검증하는 구조로 테스트를 구성했다. 각 테스트 함수 이름은 Google 스프레드시트에 정리한 자동화 함수 ID와 동일하게 설정했으며, inspect 라이브러리를 활용해 테스트가 성공하면 해당 함수명이 자동으로 로그에 출력되도록 구성했다. 덕분에 테스트 함수 단위로는 pass/fail 여부를 직관적으로 파악할 수 있었다.
하지만 문제는, 하나의 테스트 함수에 여러 TC가 묶여 있다 보니, 함수가 실패했을 때 어떤 TC에서 실패했는지까지는 알 수 없었다는 점이다. 그래서 우리는 이 한계를 보완하기 위해, 테스트 함수 내부에 각 TC마다 개별 assert를 작성하는 방식으로 구성을 변경했다. 이렇게 하면 특정 assert가 실패했을 때 어떤 TC가 문제였는지 로그를 통해 확인할 수 있고, TC 단위의 pass/fail 정보를 확보하면서도 기존 함수 구조는 유지할 수 있었다.
 

---

📌 4/2 - 9일차 회고 (시연 영상 제작 및 발표 준비)

 
오늘은 최종 시연 영상 제작을 위한 작업을 진행했다. 먼저 테스트 동작 과정을 영상으로 담기 위해, time.sleep()을 곳곳에 삽입하여 자막을 달 수 있는 여유 시간을 확보했다. 그 후 반디캠을 설치해 실제 테스트 동작 과정을 녹화했다. 녹화가 끝난 뒤에는, 각자의 코드를 최종적으로 정리한 후 develop 브랜치에 merge했고, 모든 변경 사항을 main 브랜치로 최종 반영했다.
영상 제작 경험이 있는 팀원분께서 편집과 영상 제작을 맡아주셨고, 아직 코드를 마무리하지 못한 팀원분들께서는 계속해서 각자의 구현 작업을 이어나갔다. 나는 개인적으로 코드 정리와 로그 캡처까지 모두 완료했으며, 영상 녹화도 마무리된 상태였다. 그래서 발표를 준비하시는 팀원분을 도와, 필요한 자료를 수집하고 문서를 정리하는 작업을 맡았으며, 필요한 내용은 바로바로 문서로 작성해 전달하면서 대본 작성에도 자연스럽게 기여하게 되었다.
 

지금까지 발견했던 오류들을 모두 Figma에 정리해두었고, 내가 직접 겪었던 작업 흐름과 시행착오, 주요 결정 사항들도 Figma에 타임라인 형식으로 정리해 공유했다. 이 자료는 발표를 준비하시는 팀원분께서 전체 프로젝트 흐름을 빠르게 파악하고, 발표 자료를 구성하는 데 큰 도움이 되었다.
 

팀원분들께서 각자 코드 마무리, 로그 추가, 영상 촬영 및 발표 준비 등으로 바쁘신 상황이어서, 해야 할 일들이 다소 흩어져 있는 느낌이었다. 그래서 내가 대표로 전체 작업 항목을 정리해 To-Do 리스트 형태로 공유했고, 이를 통해 각자의 작업 진행 상황과 앞으로 해야 할 일까지 한눈에 파악할 수 있도록 도왔다. 정리하는 과정에서 나 역시 팀 전체의 흐름을 다시 한번 점검할 수 있었고, 그 덕분에 이후 일정 조율이나 지원이 필요한 부분을 더 빠르게 캐치할 수 있었다.
 

Jenkins 설정 및 연동 과정, 그리고 디렉토리 구조에 대한 문서도 내가 직접 작성해 팀원들과 공유했다. Jenkins와 GitLab 연동은 처음부터 끝까지 내가 직접 진행했던 작업이었고, 디렉토리 구조 역시 구성 방향을 처음부터 정리하며 주도적으로 잡아갔던 부분이었기 때문에, 해당 내용은 내가 가장 정확히 설명할 수 있다고 판단해 문서로 정리하게 되었다. 이후 발표를 준비하시는 팀원께서는 이 문서를 참고해 관련 내용을 발표 자료에 반영하셨고, 필요할 때마다 추가 자료도 함께 정리해 공유드렸다.
 

오피스 아워 시간에는 코치님께서 이력서 작성과 면접에 대해 실질적인 조언을 해주셨다.
이력서를 작성할 때는 단순히 경험을 나열하는 것이 아니라, ‘현상 → 문제 정의 → 해결 과정 → 해결 결과(성과)’의 흐름을 갖추는 것이 중요하다고 하셨다. 이렇게 정리하면 내가 어떤 문제 상황에서 어떤 식으로 기여했는지, 그리고 어떤 결과를 이끌어냈는지가 명확하게 드러나기 때문이다.
또한 코치님은 면접과 관련해서도, 모든 질문에는 반드시 의도가 있다는 점을 강조하셨다. 질문의 표면적인 의미에만 집중하기보다, 면접관이 이 질문을 통해 어떤 점을 확인하고 싶어 하는지 역으로 생각해보는 연습이 필요하다는 말씀이 인상 깊었다.
그리고 JD(채용 공고)는 단순히 읽고 넘기는 정보가 아니라, 기업이 원하는 인재상과 역할이 명확히 드러나는 기준이므로 반드시 분석해야 한다고 하셨다. JD를 바탕으로 내가 어필할 경험을 선별하고, 그에 맞게 이력서나 면접 답변을 구성하는 것이 효과적인 준비 방법이라고 하셨다.

---

📌 4/3 - 10일차 회고 (프로젝트 발표)

이 날은 내가 맡은 TC 최종 마무리 작업을 진행했고, 발견된 이슈는 Jira를 활용해 버그 리포트로 정리해 공유했다. 또한, PPT 제작과 발표 준비를 맡으신 두 팀원분들이 워낙 바쁜 상황이어서 그분들을 대신해 필요한 문서 작성 및 자료 공유, 파일 정리와 자료 수집 등 마무리 작업도 함께 진행했다. 그렇게 하나하나 정리를 하다 보니 어느덧 발표 시간이 가까워졌고, 발표 자료 제출 마감이 오후 3시였는데, 정말 간발의 차이로 제출을 완료할 수 있었을 만큼 급박하게 돌아갔던 하루였다.
 

오후 3시에 발표 자료를 제출한 뒤, 곧바로 발표용 PPT와 대본에 대한 피드백을 주고받다 보니, 어느덧 발표 시작 시간인 오후 5시가 되어 있었다. 우리 조는 오늘 오후 12시부터 발표가 끝나는 오후 7시까지 단 한 끼도 먹지 못했다는 슬픈 사실.. 중간에 너무 배가 고파서 샌드위치를 사 오긴 했지만, 먹지도 못하고 스터디룸 경고 1회만 획득해버렸고, 그 샌드위치는 아직도 내 냉장고 안에 그대로 있다..
사실 오늘 공식적인 수업 종료 시간은 오후 11시였지만, 프로젝트가 성공적으로 마무리되기도 했고, 오프라인 조이기도 해서 회고는 자연스럽게 술자리에서 이어지게 되었다 ㅋㅋ 조퇴 처리 1회정도는 괜찮잖아 솔직히..
 

🎯 1차 프로젝트 최종 회고

 

✅ 함께 만든, 함께 성장한 열흘

이번 프로젝트에서 가장 인상 깊었던 점은, 팀 분위기와 협업이 결과에 미치는 영향이 정말 크다는 사실이었다.

실무 경험이 없거나 코드 작성에 익숙하지 않은 팀원들도 있었지만, 각자의 강점을 살려 자연스럽게 보완하고, 서로 배우며 함께 이끌어준 덕분에 단 한 명의 낙오 없이 끝까지 함께 완주할 수 있었다. 역할 분담도 자연스럽고 효율적으로 이뤄졌으며, 나는 특히 TC 작성 단계에서 팀원들에게 많은 도움을 받았고, 반대로 코드 구현이나 Jenkins 연동 같은 기술적인 부분에서는 내가 먼저 나서서 기여할 수 있었다.

무엇보다 이만큼 좋은 팀 분위기 덕분에 의견을 자유롭게 제시할 수 있는 환경이 만들어졌고, 그 과정에서 자연스럽게 기능 명세서를 기준으로 작성하던 TC를 화면(Tab) 단위로 정리하는 방식으로 전환할 수 있었다. 또한, goToPage 함수나 Locator 파일 분리와 같은 아이디어도 자유롭게 오갈 수 있었고, 이러한 구조 개선들은 자동화 코드의 완성도와 유지보수성을 높이는 데 큰 기여를 했다.

전체적인 흐름 속에서 가끔은 팀원들의 집중력이 흐트러지거나 방향이 흔들리는 순간들도 있었다. 그럴 때 나는 분위기를 다잡기 위해 조심스럽게 쓴소리를 하기도 했고, 흐름을 벗어나지 않도록 중심을 다시 잡는 역할을 하려 노력했다. 단순히 잘해보자는 마음만으로는 부족하다는 걸 누구보다 잘 알고 있었기 때문에, 마지막까지 우리 팀이 흔들리지 않고 끝까지 갈 수 있도록 이끌어가고 싶었다. 결국 그런 과정을 거치며, 우리 팀은 끝까지 집중력을 유지할 수 있었고, 스스로도 팀 전체가 잘 마무리될 수 있도록 조금이나마 방향을 잡아주는 역할을 했다는 점이 뿌듯하게 느껴졌다.

매일매일 정신없이 바빴지만, 팀원분들 덕분에 그만큼 많이 웃었던 시간들도 많았고, 정말 오랜만에 사람 관련한 스트레스는 크게 없었던 것 같고, 나름 즐겁게 일할 수 있었던 조합이었던 것 같다. 결과가 어떻든, 이번 팀 프로젝트를 통해 정말 많이 배우고 성장했다는 사실만큼은 분명하다. 짧지만 강렬했던 10일이었다!

 

✅ 테스트 케이스 작성과 자동화 구현에서의 고민들

이번 프로젝트를 통해 시나리오 중심으로 흐름을 고려한 TC 작성의 중요성을 확실히 배울 수 있었다.
이번에는 TC를 지나치게 세세하게 나눈 부분이 있었고, 그로 인해 자동화 코드 작성 시 흐름이 분절되고 반복이 많아져 오히려 비효율적이었다는 점도 실감했다. 그래서 다음에는 시나리오 중심 + 목적 단위 + 명확한 테스트 입력값을 기준으로, 자동화에 더 적합한 TC 작성 방식으로 개선해보고 싶다는 생각이 들었다.

그렇지만 우리 팀은 이 세세하게 나뉜 TC들을 하나의 테스트 함수 안에서 동시에 검증하는 것이 효과적인 케이스들로 묶어, 테스트 함수 ID를 부여해 체계적으로 관리했기 때문에, 정확성과 효율성이라는 두 마리 토끼를 모두 잡을 수 있었다고 생각한다. 이러한 접근은 자동화 코드를 작성해가며 자연스럽게 한계를 체감했고, 그때그때 유연하게 대처했기 때문에 가능했던 결과였다고 느낀다.

 

✅ Jenkins 연동과 실무 감각

Jenkins 연동은 내가 처음부터 끝까지 직접 맡아 진행한 작업으로, 이번 프로젝트를 통해 CI 환경을 스스로 구축해보는 경험을 할 수 있었다. 혼자서 해내야 한다는 책임감과 부담감 속에서, 하루에 10시간 넘게, 이틀 넘도록 삽질하며 노력한 끝에 결국 연동에 성공했고, 그 순간의 뿌듯함은 정말 컸다.

이 과정에서 Docker를 활용한 Jenkins 이미지 빌드와 컨테이너 생성, 프로젝트에 맞춘 환경 세팅, 그리고 팀원들에게 동일한 환경을 빠르게 적용하기 위한 Dockerfile 제작까지 정말 많은 실전 경험을 해볼 수 있었다. 그만큼 배운 것도 가장 많았던 파트였고, 동시에 가장 나를 괴롭혔던 파트이기도 했다.

많이 힘들긴 했지만, 그 과정을 통해 이론 수업보다 훨씬 강력한 실전 감각을 얻게 되었다고 느낀다.

 

✅ 자동화 코드와 구조 설계

자동화 코드를 작성하면서 가장 크게 느낀 점은, “아무리 자동화를 하더라도 반복은 존재한다”는 현실이었다.

반복을 최대한 줄이기 위해

• 중복 동작은 goToPage() 함수로 분리하고,
• 페이지별로 locator 파일을 따로 관리했으며,
• 반복되는 코드 흐름은 함수화하여 재사용성을 높이고자 했다.

이러한 구조는 실제로 유지보수성과 협업 효율을 높이는 데 꽤 효과적이었다.
그럼에도 불구하고, 여전히 반복적인 구조로 흘러가는 테스트 코드를 보면서 “자동화 역시 반복적이다 보니 실무에서 현타가 오기도 한다”는 오피스 아워 코치님의 말씀이 정말 공감되었다. 아무리 자동화를 해도 결국 변화에 따라 유지보수는 필수이고, "어떻게 하면 더 효율적으로 관리할 수 있을까?"라는 고민은 앞으로도 계속 반복될 수밖에 없는 숙제처럼 느껴졌다.

 

✅ 팀워크, 통일성, 그리고 진짜 실무 감각

프로젝트 후반부로 갈수록 일정이 촉박해졌고, 자료 정리, 발표 준비, 영상 촬영 등 해야 할 일들이 한꺼번에 몰리면서 전반적으로 다소 급박한 분위기가 있었던 점은 아쉬움으로 남는다. 그럼에도 불구하고, 모두가 자기 역할을 놓지 않고 끝까지 완주했다는 점은 정말 자랑스러웠다.

특히 이번 프로젝트에서는 Git을 활용한 협업 방식에 대해 실질적으로 많이 경험할 수 있었다. 각 기능을 개별 브랜치로 분리해서 작업하고, PR(Merge Request)을 통해 변경 사항을 공유하고 리뷰하며 충돌을 방지하는 흐름을 반복적으로 익혔다. 또한 커밋 시에는 [ADD], [UPDATE], [DELETE] 등 Prefix를 붙여 작업 내역을 명확하게 구분하고, 간단한 변경이라도 의미 있는 커밋 메시지를 작성하려는 습관을 익히게 되었다. Git 명령어뿐 아니라 GitHub Desktop, Sourcetree 등 다양한 도구들을 실전에서 사용해봤고, 실제 협업 상황에서 브랜치 전략과 버전 관리가 얼마나 중요한지 체감할 수 있었다.

그리고 무엇보다, 이번 프로젝트를 통해 코드 통일성과 일관성의 중요성도 깊이 깨달았다. 초반에 변수명, 함수명, 디렉토리 구조 등에 대한 기준을 명확히 정하고, 그 기준을 끝까지 유지하는 것이 협업 효율성과 유지보수성을 높이는 핵심 요소라는 점을 직접 경험했다. 물론 실제 작업 과정에서는 초안이 여러 번 바뀌기도 했고, 그럴 때마다 더 나은 방향이 보이면 과감히 수정하고 유연하게 받아들이는 태도도 중요하다는 걸 함께 느꼈다.