[엘리스 SW QA 트랙 15~16주차] 2차 팀 프로젝트 회고

ℹ️ 프로젝트 가이드

---

📚 5/4 - 개인 공부 (RealWorld 애플리케이션 구조 및 개발 환경 설정)

 
💡 RealWorld

RealWorld 프로젝트는 다양한 프론트엔드 및 백엔드 기술 스택으로 동일한 기능을 구현한 예제 애플리케이션을 제공하며, 단순한 "Todo" 앱 데모를 넘어 실제 애플리케이션 개발에 필요한 지식과 관점을 전달하는 것을 목표로 합니다. 본 가이드에서는 Node.js 기반 백엔드와 React 기반 프론트엔드 구현체를 대상으로 합니다. 공개적으로 호스팅되는 데모 버전이 존재하며 로컬 환경에서도 직접 설정하여 실행할 수 있습니다.

RealWorld 프로젝트는 프론트엔드와 백엔드가 명확히 분리된 아키텍처를 따릅니다.
 ✅ 프론트엔드: 다양한 프레임워크(React, Angular, Vue 등)로 구현 가능하며, 본 가이드에서는
   React + Redux 구현체(https://github.com/gothinkster/react-redux-realworld-example-app)를 기준으로 합니다.
 ✅ 백엔드: 다양한 프레임워크(Node/Express, Django, Rails 등)로 구현 가능하며, 본 가이드에서는
   Node.js + Express 구현체(https://github.com/gothinkster/node-express-realworld-example-app)를 기준으로 합니다.
 ✅ API: API 명세는 일반적으로 OpenAPI (Swagger) 형식 또는 Postman 컬렉션 형태로도 제공됩니다.
   인증 방식으로는 헤더에 JWT 토큰을 사용하는 방식을 사용합니다.

 
Notion에 공지된 QA 대상 서비스 글을 읽어보는데.. RealWorld 애플리케이션? 이게 대체 뭔데? 처음 봤을 땐 솔직히 좀 당황스러웠고, 설명을 읽어도 크게 와닿지 않았다. 하지만 이게 앞으로 진행할 팀 프로젝트의 핵심 대상 서비스라면, 제대로 이해하고 넘어가는 게 중요하다고 생각했다. 그래서 따로 시간을 내어 조금 더 자세히 알아보기로 했다.
 
RealWorld 프로젝트는 일종의 조립식 모델하우스 같은 개념이다. 이미 만들어진 벽, 문, 창문 같은 부품(프론트엔드와 백엔드 구현체)을 다양한 기술 스택으로 준비해두고, 우리는 그중에서 어떤 걸 조합해서 집을 완성할지만 정하면 된다. 직접 하나하나 벽돌을 쌓지 않아도, 어떤 구조로 완성되는지 체험해볼 수 있는 실습용 키트인 셈이다. 기능도 단순한 "Todo" 앱 수준이 아니라, 로그인/회원가입, 게시글 작성, 좋아요 등 실제 서비스에 가까운 구조로 되어 있다. 그리고 무엇보다 프론트엔드와 백엔드가 명확히 분리된 구조로 되어 있어서, 실무 아키텍처를 자연스럽게 체험할 수 있다는 점이 핵심이다.
 
원래는 다양한 구현체 중에서 원하는 걸 골라 조합할 수 있지만, 이번 프로젝트에서는 백엔드는 Node.js + Express, 프론트엔드는 React + Redux로 정해져 있었다. 우리는 이 부품들을 로컬 환경에 가져와 조립만 하면 된다. 조립이 끝나고 나면, 터미널에 npm run을 입력하는 것만으로 웹사이트를 바로 실행할 수 있다. 우리가 할 일은 이 완성된 웹사이트를 기준으로 QA 관점에서 테스트를 설계하고 자동화를 적용해보는 것이다. 새로 짓는 건 아니지만, 어떻게 돌아가는지 내부를 들여다보며 구조를 파악할 수 있는 기회인 셈이다.
 
💡 개발 환경 설정
우선 RealWorld 백엔드가 사용할 데이터베이스인 PostgreSQL 설치 및 초기 사용자/데이터베이스 생성을 진행했다.
 
그런 뒤, 시작 메뉴에서 SQL Shell (psql)을 실행하니 아래와 같은 화면이 바로 떴다. 

Server [localhost]: → Enter
Database [postgres]: → Enter
Port [5432]: → Enter
Username [postgres]: → Enter
Password: → 설치 시 입력한 비밀번호

중요한 점은, 처음 접속할 때는 반드시 설치 과정에서 생성한 슈퍼유저인 postgres 계정으로 접속해야 한다는 것이다. 왜냐하면 새 사용자나 데이터베이스를 생성하는 권한은 오직 슈퍼유저에게만 주어지기 때문이다. 위와 같이 입력하면 슈퍼유저 postgres로 접속할 수 있다.
 
그 후, 아래 SQL 명령어들을 순서대로 입력하여 새 사용자와 데이터베이스를 생성했다.

✅ 새 사용자 생성 (비밀번호를 꼭 기억하세요!)
CREATE USER {사용자 이름} WITH PASSWORD 'your_secure_password';
✅ 새 데이터베이스 생성 (소유자를 방금 만든 사용자로 지정)
CREATE DATABASE {데이터베이스 이름} OWNER {사용자 이름};
✅ 생성한 사용자에게 데이터베이스에 대한 모든 권한 부여 (선택 사항, 일반적으로 필요)
GRANT ALL PRIVILEGES ON DATABASE {데이터베이스 이름} TO {사용자 이름};
✅ psql 종료
\q

그리고 마지막으로, 다시 SQL Shell (psql)을 실행하여 방금 생성한 사용자 계정과 데이터베이스로 접속하면 되는 구조다.
 
💡 PostgreSQL
PostgreSQL을 설치하면, 내 컴퓨터 안에서 PostgreSQL 서버가 로컬로 실행된다. 즉, 내가 사용하는 데이터베이스는 외부 클라우드나 인터넷 어딘가가 아니라, 내 PC 안에서 돌아가는 독립적인 서버인 셈이다. 마치 Nginx나 Apache처럼, PostgreSQL도 하나의 서버 프로그램이며, 기본적으로 localhost:5432 포트에서 작동한다.
 
이 서버에 접속하기 위한 도구가 바로 psql이다. psql에서 CREATE DATABASE나 CREATE USER 같은 명령어를 입력하면, 그 정보는 로컬에 설치된 PostgreSQL 서버의 내부 데이터 디렉토리에 저장된다. 즉, 이 데이터는 RDS나 Supabase 같은 클라우드 데이터베이스에 저장되는 것이 아니라, 내 컴퓨터에서 작동 중인 PostgreSQL 인스턴스 내부에 저장되는 것이다.
 
결론적으로 말하자면, PostgreSQL을 설치하고 사용하는 순간, 내 컴퓨터에는 ‘나만의 데이터베이스 서버’가 실행되고 있는 것과 같다. 그리고 바로 그렇기 때문에, 이번 RealWorld 백엔드 프로젝트에서 사용하는 데이터베이스 역시 로컬 환경에 설치된 PostgreSQL을 기반으로 작동하는 것이다. 별도의 외부 서버나 클라우드 DB와 연결되어 있는 것이 아니라, 지금 이 컴퓨터 안에서 PostgreSQL 서버가 실행되고 있고, 그 안에서 모든 데이터가 관리되는 구조라는 점을 이해하면 된다.

---

📌 5/7 - 1일차 회고 (기능 파악 및 테스트 시나리오 작성 시작)

 
프로젝트를 시작하기 전, 로컬 환경 설정은 미리 완료해두었기 때문에 팀명, 팀장, 좌우명, 협업 툴 등을 우선적으로 정했다.
 
🛠️ 프로젝트 협업 툴 결정

• TC/시나리오: Google Spreadsheet 
• 이슈 관리: Jira
• 문서 정리: Notion & Confluence
• 코드 관리: GitLab & GitHub Desktop

 

이후, 팀원 각자가 대상 서비스를 직접 조작해보며 기능을 파악했다. 파악한 내용을 Notion에 정리했고, 모두가 해당 문서를 기반으로 다시 한번 기능을 확인하면서 놓친 부분을 보완했다.

 

"DB 내용을 어떻게 확인하지?" 하는 궁금증에 psql을 이것저것 만져보던 중, 능력자 팀원 분께서 PostgreSQL 설치 시 자동으로 함께 설치되는 pgAdmin 4를 이용하면 시각적으로 확인할 수 있다는 방법을 알려주셨다.

Servers > PostgreSQL > Databases > realworld > Schemas > public > Tables

덕분에 학부와 자격증을 공부하며 배웠던 SQL 명령어를 활용해 실제 DB 조작까지 가능했다. 1차 팀 프로젝트에서는 로컬 DB가 아니어서 조작은커녕 조회도 어려웠는데, 이번 프로젝트에서는 직접 데이터를 확인하고 조작할 수 있어 훨씬 수월했다.
 

해당 프로젝트는 기본적으로 Swagger 문서를 제공하지 않아서, 처음에는 API 명세를 직접 확인하기 어려웠다. 수업 시간에 배운 Postman을 실전처럼 써보고 싶던 마음이 컸기 때문에, 약간 아쉬운 상황이었다. 그런데 능력자 팀원 분께서 해결 방법을 알려주셨다! npm run dev 실행 전에 swagger-ui/dist/index.html에 <script> 하나를 추가한 후, npm run dev를 실행하여 Swagger UI 서버를 실행했다.
 

터미널에는 위와 같은 로그가 출력되며 Swagger UI 서버가 정상적으로 실행되었음을 확인할 수 있었다.

• Loopback은 http://localhost:3200/처럼 내 컴퓨터에서만 접근 가능한 주소이고,
• On Your Network는 같은 네트워크(예: 공유기)에 연결된 다른 기기에서도 접근할 수 있는 IP 주소이다.
   

이렇게 Swagger UI 서버가 실행된 뒤, 브라우저에서 http://localhost:3200/에 접속한 후 아래의 URL을 입력하면 정상적으로 Swagger UI를 통해 API 명세를 확인할 수 있었다. 물론 공식 GitHub 저장소에서는 Postman CLI 컬렉션(Conduit.postman_collection.json)과 실행 스크립트(run-api-tests.sh)도 제공되어, 터미널 기반 자동 API 테스트가 가능하지만, 나는 직접 명세를 보며 API 요청을 조작해보고 싶었기 때문에 이 방식이 훨씬 만족스러웠다.

https://raw.githubusercontent.com/gothinkster/realworld/main/api/openapi.yml

 

기능은 사다리 타기를 통해 공정하게 분담했다. 나는 마이페이지와 필터 기능을 맡게 되었고, 이후 오피스 아워를 대비해 질문 리스트를 미리 정리해두었다. 실제로 이 질문 리스트가 예상보다 훨씬 유익한 대화로 이어졌고, 테스트 전략을 결정하는 데 큰 도움이 되었다.

• 기능 단위 테스트 vs. 시나리오 흐름 테스트 중, 실무에서 시나리오 흐름 테스트가 더 자주 사용된다는 점
• JD 우대사항에 ‘시나리오 기반 자동화 구현’이 포함되어 있다는 점

위를 참고하여 이번 프로젝트의 자동화 코드는 시나리오 흐름을 따르기로 결정했다.

---

📌 5/8 - 2일차 회고 (테스트 시나리오 작성 완료 & 기본 코드 구조 설계)

 
"인기 태그 순위는 어떤 기준일까?" 궁금증이 들어 직접 DB를 들여다보았다. Tag와 _ArticleToTag 테이블을 보니, 아래와 같이 정렬되는 것처럼 보였다.

• 1순위는 횟수 기준 내림차순,
• 2순위는 알파벳 역순 (예: bca)

그런데 팀원분의 환경에서는 2순위 정렬(알파벳 역순)이 적용되지 않는 현상이 있었다. 혼란스러워하던 찰나, 능력자 팀원분께서 직접 태그 관련 코드를 찾아주셨다. (경로: backend\src\app\routes\tag) 
 
⬇️ tag.controller.ts

import { NextFunction, Request, Response, Router } from 'express';
import auth from '../auth/auth';
import getTags from './tag.service';

const router = Router();

/**
 * Get top 10 popular tags
 * @auth optional
 * @route {GET} /api/tags
 * @returns tags list of tag names
 */
router.get('/tags', auth.optional, async (req: Request, res: Response, next: NextFunction) => {
  try {
    const tags = await getTags(req.auth?.user?.id);
    res.json({ tags });
  } catch (error) {
    next(error);
  }
});

export default router;

 
⬇️ tag.service.ts

import prisma from '../../../prisma/prisma-client';
import { Tag } from './tag.model';

const getTags = async (id?: number): Promise<string[]> => {
  const queries = [];
  queries.push({ demo: true });

  if (id) {
    queries.push({
      id: {
        equals: id,
      },
    });
  }

  const tags = await prisma.tag.findMany({
    where: {
      articles: {
        some: {
          author: {
            OR: queries,
          },
        },
      },
    },
    select: {
      name: true,
    },
    orderBy: {
      articles: {
        _count: 'desc',
      },
    },
    take: 10,
  });

  return tags.map((tag: Tag) => tag.name);
};

export default getTags;

 
해당 코드를 확인해보니,

• take: 10 = 인기 태그 10개만 노출
• orderBy: { articles: { _count: 'desc', }, } = 사용 횟수 기준 내림차순 정렬

하지만 2순위 정렬(알파벳 역순)에 대한 로직은 구현되어 있지 않았고, 이와 관련해 코치님 및 GPT에게 질문한 결과, 정렬 조건이 명확히 명시되지 않은 경우, DB에서 임의로 결과를 반환할 수 있다는 답변을 얻었다. 결국 1순위 정렬 로직(_count 기준 내림차순)만 코드에 명확히 구현되어 있었기 때문에, 테스트할 때는 이 부분만 확인하면 될 것 같다는 결론을 내릴 수 있었다.
 

이번 프로젝트에선 테스트 중 실제 DB 값을 불러와 사용하는 경우도 있었기 때문에, "어떻게 불러올 수 있을까?" 고민이 많았다. 그 과정에서 팀원과 함께 해결 방안을 고민하다가 psycopg2-binary 라이브러리를 통해 DB 쿼리 결과를 가져올 수 있다는 점을 확인했다. 이를 통해 특정 테스트에서 필요한 DB 값을 자동으로 가져오고 검증할 수 있는 기반을 마련할 수 있었다.
 

같은 팀원 분과 함께 DB 구조와 처리 방식에 대해 화이트보드를 활용해 직접 논의해본 경험이 정말 좋았다. 막막했던 부분을 서로 아이디어를 주고받으며 정리해가는 과정이 재밌기도 하고, 함께 고민한다는 점에서 든든하기도 했다. 그 과정에서 DB 데이터를 효율적으로 불러오고 정제하는 구조를 어떻게 잡아야 할지에 대한 이야기가 나왔고, 함께 고민하며 아래와 같은 두 가지 방향을 도출할 수 있었다.

1. DB에도 POM 구조를 적용해보는 방식
   • DB마다 클래스를 만들고
   • query를 locator처럼 정의하며
   • 각 클래스에서 데이터를 정제하도록 구성
2. query 파일과 format 파일을 분리한 구조
   • query들을 정의한 파일과
   • DB 열 구조 및 포맷을 정의한 파일을 따로 구성
   • get_db() 같은 공통 함수를 통해 정제된 데이터를 반환

 

이에 대해 오피스 아워 시간에 코치님께 여쭤봤더니, 단 1초의 망설임도 없이 "DB는 POM 구조로 하면 안 된다"고 단호하게 말씀하셨다. 대신 2번 방식(query 파일과 format 파일을 분리해 사용하는 구조)이 더 적절해 보인다고 조언해주셔서, 나 역시 해당 구조를 한 번 시도해볼 생각이다.
 

오늘은 작성한 테스트 시나리오를 함께 검토하는 시간을 가졌다. 표현의 일관성, 단어 선택, 시나리오 흐름 등을 팀원들과 함께 맞춰보며, “나는 이렇게 생각해서 이렇게 썼다”, “이 부분은 이런 방식으로 개선해보면 좋겠다”와 같은 의견을 나눴다. 이 과정이 매우 유익했고, 모두가 납득할 수 있는 시나리오를 완성할 수 있었다. 이후 오피스 아워 시간에는 코치님께 테스트 시나리오에 대한 피드백도 받을 수 있었는데, 잘 작성되었다는 긍정적인 말씀을 해주셔서 큰 힘이 되었다. 처음으로 자동화 코드를 고려하여 작성해본 시나리오라 걱정이 많았지만, 이번 경험을 통해 확신과 자신감을 얻을 수 있었다.
 

팀원들이 각자 담당한 테스트 시나리오 중 DB 쿼리가 필요한 부분을 정리하는 동안, 나는 프로젝트의 기본적인 코드 틀을 구성하는 작업을 진행했다. 가장 기본이 되는 로그인 기능을 위한 conftest.py, BasePage, HomePage, LoginPage 등을 구현했고, 특히 로그인 함수까지 완성했기 때문에, 내일부터는 본격적으로 각자 맡은 기능에 대한 자동화 코드 작성에 들어갈 수 있을 것 같다.

---

📌 5/9 - 3일차 회고 (테스트 자동화 코드 본격 작성 시작)

 

처음에는 util 폴더 내 setupLogger 함수를 활용하여, 각 페이지 클래스(BasePage, HomePage 등)의 이름을 기반으로 개별 log 파일을 생성하도록 구현했었다. 즉, BasePage의 생성자에서 logger를 초기화하고, 이를 하위 페이지들이 상속받는 구조였다. 하지만 실제 테스트 시나리오에서는 다양한 Page 객체들이 생성되기 때문에, 하나의 시나리오 실행 중에도 여러 개의 log 파일이 생성되는 비효율적인 상황이 발생했다. 이로 인해 로그가 시나리오 단위가 아닌 객체 단위로 분산되며, 테스트 결과를 종합적으로 파악하기 어려워지는 문제가 있었다.
 

이를 해결하기 위해 구조를 다음과 같이 개선했다. BasePage에서는 더 이상 logger를 초기화하지 않고, 대신 각 테스트 시나리오 클래스 상단에서 전역적으로 setupLogger를 호출하여 logger를 초기화하도록 변경했다. 이때 logger 이름은 __qualname__을 사용해 시나리오 클래스 단위로 설정했다. 이 구조를 통해 테스트마다 log 파일이 하나씩 생성되고, 로그가 Page 객체마다 분산되지 않으며 시나리오 단위로 통합되도록 설계할 수 있었다. 이처럼 사소해 보이지만 중요한 구조 개선 덕분에 테스트 결과 해석이 훨씬 명확해졌고, 로그 관리의 효율성도 크게 향상되었다.
 

우리는 현재 POM 구조를 기반으로 페이지를 클래스화하고, 각 클래스 내부에 해당 페이지와 관련된 요소 정의 및 사용자 행위 메서드를 구성해두고 있다. 초기에는 상단에 항상 고정되어 있는 Home, Sign in, Sign up, New Post, Settings 버튼들을 HomePage 내부에 정의해두었다. 하지만 이 요소들은 사실 모든 페이지에 공통적으로 존재하는 UI 요소임에도 불구하고, HomePage에만 정의되어 있으니 마치 해당 페이지에서만 사용하는 전용 요소처럼 보이는 부자연스러운 구조가 되었다. 공통 UI 요소를 특정 페이지에만 묶어두는 것은 구조적으로도 어색하고, 재사용성과 유지보수 측면에서도 비효율적이라는 판단이 들었다.
 

이에 따라 해당 요소들을 별도의 Header 클래스로 분리하자는 논의가 자연스럽게 이루어졌고, 오피스 아워 시간에 코치님께 피드백을 요청드렸다. 코치님께서는 구조상 Header, Body, Footer로 나누는 방향이 바람직하며, Header를 별도로 구성하면 재사용이 용이하고, 현재 우리 프로젝트 구조와도 잘 맞는다고 말씀해주셨다. 또한 페이지에 따라 Header 구성 요소가 달라질 수 있는 경우를 고려해, Header도 유연하게 확장 가능한 구조로 설계하는 것이 좋다는 조언을 주셨다.
 
이에 따라 프로젝트 구조를 pages 폴더 하위에 다음과 같이 개선했다.

• header/: 상단 고정 UI 요소들을 관리
• body/: 페이지별 주요 내용 구성
• footer/: 하단 고정 UI 요소들을 관리

또한, BasePage는 각 페이지 클래스들이 상속받는 공통 기능 및 설계도 역할을 담당하는 파일이기 때문에, 특정 레이아웃(header/body/footer)에 직접 속하지 않는다고 판단하여 pages 폴더 바로 아래에 위치시키는 것으로 결정했다.

 

테스트 시나리오 자동화 코드를 작성하던 중, 발표자를 어떻게 정할까 하는 이야기가 나왔다. 그때 팀원분께서 공유해주신 룰렛 링크를 통해 발표자를 무작위로 정해보기로 했다. 평소 인스타 릴스에서 자주 보던 그 룰렛을 이렇게 직접 써보게 될 줄이야.. ㅋㅋ 진짜 흥미진진했고, 팀원들과 함께 돌릴 때마다 웃음이 끊이질 않았다. 몇 번 연습 삼아 돌려봤을 땐 5번 중 4번이나 내가 걸려서 이거 뭔가 이상한데..? 싶었지만, 정작 실전에서는 내가 아닌 다른 팀원이 뽑혔다. 발표자는 미리 정해졌지만, 결과물은 함께 만들었기 때문에 발표 준비도 함께 하기로 했다. 혼자만의 결과물이 아닌 팀의 작업물인 만큼, 모두가 내용을 숙지하고 의견을 나누며 완성도를 높이는 데 집중하기로 했다.

---

📚 5/10 - 개인 공부 (LINE QA분과 커피챗 & 테스트 자동화 코드 작성)

 
약 한 달 전, 멋쟁이 사자처럼 10기 활동 당시 함께했던 선배님께서 LINE에서 근무 중인 QA 지인을 소개해주시겠다며 자리를 마련해보겠다고 연락을 주셨었다. 그런데 요즘 너무 바빴다. 당장 10분 거리에 사는 사촌 언니가 밥 사주겠다는 약속조차 선뜻 날짜를 못 잡을 정도로 수업과 사이드 프로젝트 일정에 정신이 없었다. 그러다 보니 선배님의 소중한 제안도 바쁘게 지내는 사이 자연스럽게 잊고 있었다. 그러던 중 프로젝트를 진행하던 도중, 선배님께서 다시 연락을 주셨고, 그 순간 ‘아 맞다!’ 하고 기억이 떠올랐다. 정말 깜짝 놀랐지만 동시에 기쁜 마음으로 바로 답장을 드렸다. 약속 장소로 향하기 전, 이 기회를 절대 허투루 넘기고 싶지 않아서 평소 궁금했던 QA 실무 관련 질문들을 정리해보고 가기로 마음먹었다.

건대입구역에서 함께 식사를 한 뒤, 근처 할리스로 자리를 옮겨 내 이력서와 포트폴리오를 함께 보며 직접 피드백을 주셨다. 그 외에도 내가 준비해간 다양한 질문들에 대해 성심성의껏 답변을 해주셨고, 짧은 시간이었지만 정말 알차고 감사한 시간이었다. 헤어지기 전에는 “편하게 연락해도 된다”며 명함도 건네주셨는데, 그 명함이 라인 로고가 들어간 두툼하고 귀여운 명함이라 한참을 들여다보게 되었다. 실무자와 직접 마주하고 대화할 수 있었던 경험 자체가 너무 큰 자극이 되었고, 이 기회를 발판 삼아 더 열심히 준비해나가야겠다고 다짐했다.
 

초기에는 BasePage의 생성자 내부에서 driver.get()을 호출하도록 구현했었다. 하지만 테스트를 진행하면서 이상한 현상이 발생했다. BasePage를 상속받는 Page 클래스들의 객체를 생성할 때마다 각 객체가 생성되며 매번 driver.get()을 호출하게 되면서, 웹사이트 메인 화면이 여러 번 깜빡이고 지지직 거리는 듯한 현상이 나타났다. 처음에는 왜 그런지 몰랐지만, 한 시나리오 안에서 여러 Page 객체들을 생성하고 있다는 점을 떠올리며 원인을 파악할 수 있었다. 즉, 테스트 시나리오 함수 안에서 다양한 Page 객체들을 한 번에 생성하다 보니, 객체 생성 = 생성자 실행 = driver.get() 중복 호출 이라는 구조로 인해 페이지 진입이 불필요하게 여러 번 반복되고 있었던 것이다.
 
이 문제를 해결하기 위해, driver.get()을 BasePage가 아닌 테스트 클래스 쪽으로 옮기기로 했다. 구체적으로는 테스트 클래스에서 fixture를 autouse=True로 설정해 테스트가 시작되기 전 한 번만 driver.get()이 실행되도록 개선하였다. 이렇게 변경하고 나니, 테스트 실행 시 페이지가 단 한 번만 로딩되고, 테스트 흐름도 깔끔하게 유지되었다. 이번 경험을 통해, 공통 로직을 무조건 부모 클래스에 두는 것만이 최선은 아니며, 실제 실행 타이밍과 객체 생명 주기까지 고려한 설계가 중요하다는 점을 배울 수 있었다.

---

📚 5/11 - 개인 공부 (DB 조작 Util 함수 구현 & 테스트 자동화 코드 작성)

 

내가 맡은 기능 중 일부는 다른 팀원 분들이 구현을 마쳐야만 본격적으로 개발을 이어갈 수 있는 구조였다. 그래서 기다리는 동안, 기능 의존성이 없는 작업은 무엇이 있을까 고민하다가 예전에 이야기 나왔던 DB 데이터를 불러오고 정제하는 유틸 함수 구현을 떠올렸다. 팀원 분께서 알려주신 psycopg2 라이브러리를 활용해 DB 연결 및 쿼리 실행이 가능한 함수를 만들어보기로 했다. 먼저, 모든 테스트 시나리오가 시작되기 전에 DB 내 데이터를 초기화하자는 팀원들과의 논의가 있었고, 이는 테스트 간 데이터 의존성을 최소화할 수 있다는 점에서 나 역시 긍정적으로 동의했다. 직접 테스트해본 결과, User 테이블의 데이터를 삭제하면 다른 테이블의 데이터들도 연쇄적으로 제거되는 것을 확인할 수 있었고, 이를 기반으로 User 테이블의 내용을 모두 밀어버리는 초기화 함수를 구현하였다. 또한, 인기 태그(Popular Tags) 순위 로직을 테스트하기 위해 기초 데이터를 DB에 seeding하는 함수를 추가로 구현했다.
 
그리고 "특정 태그가 얼마나 자주 등장했는지"를 확인하기 위해 다음과 같은 방식으로 로직을 구상했다. Tag 테이블은 tag_id, name으로, _ArticleToTag 테이블은 tag_id, article_id로 구성되어 있고 이를 기반으로 tag_id를 기준으로 두 테이블을 join 시키면 tag_id, tag_name, article_id가 포함된 결과를 만들 수 있다. 따라서, 넘겨받은 태그 이름을 기준으로 게시글 수를 count하는 쿼리를 작성하고, 이를 함수로 구현하여 Popular Tag 순위 반영이 실제로 잘 이루어지는지 검증하는 테스트에 활용할 수 있도록 구성했다. 이 과정을 통해 DB 구조를 이해하고 테스트 목적에 맞게 데이터를 설계하고 다루는 감각을 키울 수 있었다.
 

하루 종일 프로젝트 작업에 몰두할 예정이었고, 곧 대구로 내려갈 계획이라 서울에 있는 동안 한 번쯤 만나자고 연락을 주셨던 분들께 연락을 돌리기 시작했다. 그중에는 사촌 언니도 있었고, 멋쟁이 사자처럼 활동을 통해 알게 된 또 다른 선배님도 계셨다. 그런데 선배님께서는 "지금 바로 보자!"며 갑작스럽게 연락을 주셨고 잠깐 고민했지만, 프로젝트 막바지인 17일보다는 오늘이 낫겠다 싶어서 대충 모자를 눌러쓰고 건대입구로 향했다. 사실 저녁으로 마라샹궈를 이미 아주 야무지게 먹고 와서 배가 부르다고 말씀드렸는데, 선배님께서 "간단하게 양꼬치 먹자~" 하셔서, 보고 싶은 마음에 결국 바로 나가게 되었다!
 
대학교 2학년 이후로 처음 뵙는 자리였지만, 정말 너무 편했고, 여전히 좋은 분이셨다. 이 날 티스토리 구독도 함께 했는데, 혹시 이 글 보고 계신다면.. "저에게는 아저씨 아니고, 찐 어른 '태무 이수혁'입니다 ㅋㅋㅋㅋㅋ" 이야기를 나누는 동안 취준생인 내게 정말 큰 힘이 되는 말씀을 많이 해주셨고, 이력서와 포트폴리오가 완성되면 꼭 보내달라며 직접 봐주시겠다는 말씀까지 해주셨다. 이런 순간마다 느낀다. 나는 정말 인복이 많은 사람이라는 것. 따뜻한 마음과 진심 어린 조언, 그리고 편한 공기까지 진심으로 감사한 하루였다. 저 취업하면 꼭 맛있는 거 사드리겠다는 약속, 반드시 지킬게요! 😆

---

📌 5/12 - 4일차 회고 (DB 보안성과 유지보수를 고려한 쿼리 분리 & 테스트 자동화 코드 완성)

 

DB 유틸 함수를 구현하면서 기능적인 부분뿐만 아니라 보안적인 측면도 함께 고려했다. 처음에는 f-string을 사용해서 쿼리를 구성했지만, 이 방식은 SQL Injection에 취약할 수 있다는 점을 알게 되었다. 그래서 보안상 더 안전한 %s 포맷 방식으로 전부 바꿨다. 또 하나 신경 썼던 부분은 쿼리문 자체를 코드 안에 직접 포함시키는 구조였다. 테이블 이름이나 컬럼 구조 등 민감한 정보가 그대로 드러나기 때문에, 이 역시 보안상 좋지 않다고 판단했다. 그래서 주요 쿼리문은 전부 별도의 파일로 분리했고, 해당 쿼리 파일은 .gitignore에 등록해서 GitHub에 올라가지 않도록 처리해두었다. 자동화 코드를 작성하면서 보안까지 함께 고려할 수 있었던 과정이었고, 실무에서도 이런 시각이 꼭 필요하겠다는 생각이 들었다.
 

이번에 마이프로필 관련 테스트 시나리오를 작성하면서 가장 고민됐던 부분은, 조건을 만족시키기 위한 절차까지 시나리오에 모두 포함시켜야 하는가였다. 예를 들어, 게시글이 없을 때 보여야 할 문구를 먼저 확인한 뒤, 실제로 게시글을 작성하고 다시 돌아와 해당 게시글이 정상적으로 표시되는지를 확인하는 흐름을 하나의 테스트에서 다루고 싶었다.
 
기대 결과는 조건(게시글 존재 유무)에 따라 명확하게 나뉘니까, 그에 맞춰 두 가지 상황 모두를 포함시키는 게 자연스럽다고 생각했다. 문제는 이를 위한 절차까지 어디까지 상세하게 기술해야 하느냐였다. 예를 들어 'My Feed 탭 진입 -> “No articles are here... yet.” 텍스트 확인 -> New Post 버튼 클릭 -> 게시글 작성 -> MyProfile 링크 클릭 -> My Feed 탭 클릭 -> 방금 작성한 게시글 노출 확인'과 같은 일련의 과정을 전부 절차에 담는 게 맞는지 계속 고민했다.
 
이런 고민은 결국 테스트 시나리오의 목적이 무엇인가에 대한 질문으로 이어졌다. 코치님께서 해주신 “테스트 시나리오는 코드 작성의 네비게이터 역할을 하며, 기대 결과를 유추할 수 있을 정도의 흐름만 잡혀 있다면 괜찮다”는 말이 굉장히 와닿았다. 자동화 테스트 시나리오를 처음 작성하다 보니 처음에는 모든 과정을 다 적어야 할 것처럼 느껴졌지만, 결국 중요한 건 읽기 쉬운 흐름과 테스트 목적에 맞는 구성이라는 걸 깨달았다.
 
그래서 절차 부분에는 해당 기대 결과를 확인하기 위한 마지막 단계, 즉 조건이 충족되었다는 전제 하에 실행되는 핵심 절차만 간단히 적기로 했다. 이 방식이 기대 결과를 더 명확하게 드러내면서도 시나리오 흐름을 깔끔하게 유지할 수 있어서, 지금 내 수준에서는 가장 적절한 구조라고 생각했다. 물론 아직은 자동화 테스트 시나리오 작성이 익숙하진 않지만, 이렇게 직접 부딪히며 하나씩 구조를 고민해보는 과정 자체가 정말 많은 걸 배우게 해준다.
 

처음에는 HomePage에 Your Feed 탭, Global Feed 탭, Popular Tags와 같은 요소들을 정의하고, Article 관련 요소는 ArticlePage로 따로 분리해서 관리했다. 그 이유는 Article 관련 요소가 단순히 Home 페이지에서만 사용되는 게 아니라, MyProfile 페이지 내에서도 사용되기 때문이었다. 즉, 특정 페이지에만 종속된 요소가 아니라고 판단되어 공통 요소처럼 별도로 분리하는 게 더 적절하다고 생각했다.
 
그런데 테스트 코드를 작성하면서 점점 고민이 생기기 시작했다. 예를 들어, Your Feed 탭 클릭 -> 해당 탭 게시글 확인이라는 단순한 흐름을 테스트할 때도, HomePage와 ArticlePage 객체를 모두 생성해야만 했다. 구조적으로는 분리한 게 맞지만, 실제 사용 시에는 오히려 단일 흐름을 위해 두 객체를 왔다 갔다 해야 한다는 불편함이 생긴 것이다. 처음에는 “해당 페이지에만 존재하는 요소, 해당 요소를 통한 행동만 정의한다”는 기준으로 나눴지만, 실제로는 그 기준이 테스트 작성 흐름을 끊어놓는 느낌도 들었다.
 
그러다 보니 또 다른 고민도 생겼다. 이걸 과연 page라고 불러도 되는 걸까? 사실 ArticlePage에 들어간 요소들은 하나의 독립된 페이지가 아니라, 다양한 페이지 내에 공통적으로 존재하는 것 뿐인데 굳이 page라는 이름을 붙이는 게 맞는가? 하는 의문이 들기 시작했다. 그리고 정말 이상하게도, 하나에 대한 의문이 들기 시작하면 그게 꼬리에 꼬리를 물고 계속 이어지면서 머릿속이 너무 복잡해졌다. 정답이 없는 문제일수록 “어떤 게 더 좋을까?”, “어떤 구조가 더 효율적일까?”라는 생각이 끝없이 이어졌고, 결국에는 고민 자체를 잠시 멈추기로 했다. 일단은 지금 구조 그대로 유지하기로 했지만, 어떤 구조가 더 나은 선택일지는 아직도 확신이 없다. 테스트 구조 설계라는 게 이렇게 끊임없는 질문과 선택의 연속이라는 걸 이번에 정말 체감하고 있다.

그래도 오늘은 DB 구조와 쿼리 처리 방식에 대해 팀원 분들과 함께 이야기 나눌 수 있어서 정말 좋았다. 서로의 의견을 공유하며 “어떻게 하면 보안성을 높일 수 있을까?”, “어떻게 하면 유지보수가 쉬운 구조가 될까?”를 함께 고민할 수 있었고, 그 과정에서 정말 유의미한 논의가 오갔다. 덕분에 하나의 방향성을 수립하고, 실제 코드에 적용해볼 수 있었던 것도 큰 수확이었다. 무엇보다 모두가 납득하고 만족할 수 있는 결과를 만들어낸 점이 뿌듯했다.
 
또한, 내가 담당한 기능 중 일부는 다른 분들의 선행 작업이 있어야 시나리오 작성이 가능했는데, 팀원 분들께서 해당 함수들을 빠르게 구현해주신 덕분에 오늘은 인증(로그인/회원가입), 필터, 마이프로필 기능의 테스트 시나리오를 모두 완성할 수 있었다. 내일은 다른 분들의 코드를 리뷰하고, 남아 있는 영역이 있다면 그 부분에 투입되어 함께 마무리 작업을 진행할 수 있을 것 같다.

---

📌 5/13 - 5일차 회고 (Allure 적용, 코드 리뷰, 컴포넌트 단위 구조 개선)

 

오늘은 Jenkins 연동을 어떻게 구현할지에 대해 고민했다. 현재 대상 서비스는 PostgreSQL DB를 설치하고, backend와 frontend를 각각 Git에서 clone한 뒤, 의존성 설치 및 DB 연결, 그리고 npx nx serve api, npm start 등의 명령어를 실행해야 한다. 즉, Jenkins에서도 로컬과 동일한 환경 구성이 필요하다. 문제는 이 로컬 환경을 Jenkins의 VM 상에서 어떻게 그대로 재현할 수 있을지 감이 잘 오지 않았다는 점이다. 내가 떠올린 방법은 단순히 VM에 로컬과 동일하게 환경을 하나하나 세팅해주는 방식이었지만, 이게 과연 최선일까 하는 의문이 계속 들었다.
 
그래서 레이서 분들과 매니저 분들이 계신 채널에 해당 상황을 공유하고 조언을 구했다. 다행히 Jenkins 연동을 이미 성공하신 한 레이서 분께서 직접 연락을 주셨고, 본인의 구성 방식을 자세히 설명해주셨다. 내가 생각했던 방식은 1번이었지만, 그 분은 전혀 다른 방식인 2번으로 구현하셨다고 한다. 사실 두 방법 모두 아직 나에게는 생소하고 감도 잘 오지 않는다. 로컬에서 직접 해보고 차근차근 익히는 수밖에 없을 것 같은데, 당장 무엇부터 어떻게 손대야 할지 막막하다.
 

일단 Jenkins 연동은 잠시 뒤로 미루고, 1차 팀 프로젝트 이후에 배웠던 Allure 리포트 기능을 적용해보기로 했다. Allure는 테스트 결과를 시각적으로 보기 좋게 정리해주는 리포트 도구로, 테스트 케이스별 실행 결과, 로그, 스텝 등을 한눈에 확인할 수 있게 도와준다.
 
우선 allure-pytest 라이브러리를 설치한 뒤, pytest.ini 파일의 addopts 항목에 --alluredir=reports/allure-results 옵션을 추가해주었다. 이후 Allure 명령어를 이용해 리포트를 생성하려 했는데, 명령어가 실행되지 않는 문제가 발생했다. 알고 보니 Allure는 단순한 파이썬 라이브러리가 아니라 로컬에 실행 가능한 프로그램 형태로도 설치가 되어 있어야 했다. 그래서 별도로 Allure CLI를 설치하고 환경 변수에 등록한 후에야 명령어가 제대로 작동했다.
 
한 가지 아쉬운 점은, reports/allure-results 폴더에 실행 결과가 계속 누적된다는 것이다. 이전 결과를 덮어쓰는 방식이 아니라서, 리포트를 새로 생성할 때마다 해당 폴더를 수동으로 삭제해주는 게 가장 깔끔한 방법인 것 같다. 
 

데코레이터를 적용하기 전의 Allure 리포트는 왼쪽 이미지처럼 다소 밋밋하고, 어떤 테스트가 무엇을 의미하는지 직관적으로 파악하기 어려웠다. 우리 팀은 이를 개선하기 위해 어떻게 구성하는 것이 좋을지 논의했고, 다음과 같은 기준을 정해 데코레이터를 적용하기로 했다.

• @allure.suite: 테스트 파일 이름을 기준으로 작성 (예: test_settings.py)
• @allure.sub_suite: 테스트 기능을 간단히 설명하는 용도 (예: SETTING TEST)
• @allure.title: 시나리오 ID + 대분류 - 중분류 형식으로 구성
• @allure.description: 해당 테스트의 목적과 내용을 구체적으로 설명

이렇게 데코레이터를 일관성 있게 적용한 결과, 오른쪽 이미지처럼 리포트가 훨씬 깔끔하게 정리되었고, 테스트의 목적과 내용을 직관적으로 파악할 수 있게 되었다. 심지어 @pytest.mark.parametrize로 전달된 매개변수까지 출력되어, 어떤 값으로 테스트했는지도 한눈에 확인할 수 있었다. 왜 이제야 이 기능을 알게 된 건지 아쉬울 정도였다. 진작에 적용했으면 테스트 리포트를 보는 시간이 훨씬 줄었을 텐데..!
 

그리고 테스트 로그도 각자 제각각으로 출력되고 있어, 로그 형식 역시 통일하기로 했다. 마침 모든 팀원이 테스트 코드 작성을 대부분 완료한 상태였고, 어느 정도 여유가 생기다 보니 이런 디테일한 부분까지 신경 쓸 수 있었다. 우리는 각 테스트 시나리오의 기대 결과를 중심으로 로그를 작성하기로 했고, 다음과 같은 아이콘 글머리 기호를 정해 통일된 포맷을 적용했다.

• 테스트 시작 시: ▶️
• 기대 결과 충족 시: ✅
• 테스트 완료 시: 🎉

이렇게 통일한 뒤에 각자 작성한 로그 파일들을 모아보니, 전체적으로 훨씬 정돈된 느낌이 들었다. 가독성도 확실히 좋아졌고, 무엇보다 로그만 봐도 테스트 흐름이 한눈에 들어와서 꽤 뿌듯했다. 작은 변화지만 팀 전체의 퀄리티가 올라간 느낌이라 만족스럽다.
 

오늘 오후 7시, 오피스 아워 시간에 코치님의 코드 리뷰가 진행되었다. 코치님께서는 지난 5/9에 주신 피드백과 관련해, 우리 조가 header/, body/, footer/ 구조를 다소 잘못 이해한 것 같다고 말씀하시며 올바른 방향을 짚어주셨다. 특히 page가 아니라 component 단위로 생각해야 한다는 설명을 들은 순간, 어제 느꼈던 답답함이 단번에 해소되었다. 기능별로 분리된 부품들을 조합해 하나의 페이지를 구성하는 방식이 핵심이었다. 기존에는 HomePage가 Header, HomePage, ArticlePage로 구성되었지만, 이제는 이를 HeaderComponent, ArticleTabComponent, PopularTagsComponent, ArticleComponent처럼 독립된 컴포넌트 단위로 보고 조립하는 구조가 정확하다는 것을 명확히 이해하게 되었다. "아하, 컴포넌트화로 생각하면 되는 거였구나!" 이해가 되자마자 머릿속이 환해졌고, 다른 분들이 Jenkins를 공부하는 동안 나는 시간을 들여 해당 구조를 전면적으로 수정했다.

---

📌 5/14 - 6일차 회고 (Jira를 활용한 이슈 정리 & Pytest 결과 요약을 Slack에 자동 전송)

 

AI 업무 관리 및 생산성 도구

실무에서 퇴근하기 전에 자동화 테스트를 돌려놓고 Slack을 통해 결과를 다 같이 확인한다는 이야기를 들은 적이 있었고, 그때부터 Slack 연동을 꼭 한 번 써보고 싶었다. 마침 다른 팀원 분들이 Jenkins 연동을 시도하는 동안, 나는 Slack 연동을 먼저 도전해보기로 했다. Slack 연동을 위해 먼저 Slack 앱을 생성하고, 워크스페이스를 선택한 뒤 Incoming Webhooks 기능을 활성화했다. 이후 전송하고자 하는 채널을 지정하고 Webhook URL을 발급받았다.
 

자동화 테스트와 관련해서는, pytest.ini 파일에 --alluredir=reports/allure-results 옵션을 넣어 테스트 실행 시 allure result가 생성되도록 설정했다. 다만 이 폴더는 실행할 때마다 누적되어 쌓이기 때문에, 테스트 세션 시작 전에 clear_allure_dirs()를 호출하여 기존 결과 폴더를 초기화했다. 테스트 세션이 종료된 후에는 generate_allure_report()를 호출하여 새롭게 생성된 결과를 기반으로 리포트를 생성했고, 마지막으로 send_test_result_to_slack() 함수를 통해 Slack에 테스트 요약 결과를 전송했다.
 

Slack 메시지에는 allure-report/widgets/summary.json 파일을 참고하여 테스트의 통과, 실패, 스킵 수와 전체 테스트 수를 포함시켰고, 누가 테스트를 실행했는지에 대한 정보도 함께 담았다. 여기에 더해, 실패한 테스트의 시나리오 이름까지 Slack으로 전송되도록 구성해 어떤 테스트가 문제였는지를 빠르게 확인할 수 있도록 했다. 처음엔 Slack 연동이 꽤 복잡할 거라고 생각했는데, 막상 Webhook 방식으로 연결해보니 생각보다 너무 간단하고 직관적이라 놀랐다. 테스트가 끝날 때마다 팀원들의 휴대폰에서 Slack 알림이 울리는 걸 보며 다들 기뻐하는 모습에 뿌듯함을 느낄 수 있었다. 물론, Allure HTML 리포트를 Slack에 첨부하거나 링크로 공유하고 싶었지만, 현재는 리포트가 실행자의 로컬 환경에서만 접근 가능한 구조라 팀원 모두가 동일한 링크를 열어볼 수 없다는 점은 아쉬움으로 남았다. 그럼에도 불구하고, 테스트 결과를 요약해 Slack에 자동 전송하는 기능 하나만으로도 협업 시 투명성이 높아지고, 실패 케이스를 빠르게 캐치할 수 있어서 꽤 만족스러운 개선이었다.

Jira는 아직까지 어렵게 느껴진다. 뭔가 이미 세팅된 포맷을 바탕으로는 그에 맞춰 뚝딱뚝딱 만들 수 있을 것 같은데, 아무것도 없는 빈 도화지 위에서는 어떻게 시작해야 할지 막막하다. 실무 경험이 부족해서 그런지, 화면만 바라보고 멍해질 때가 많다. 하지만 우리 팀의 능력자 팀원 분께서 체계적으로 정리된 Jira 이슈 템플릿을 만들어주신 덕분에, 나는 그 포맷에 맞춰 발견한 이슈들을 하나씩 정리할 수 있었다. 템플릿이 잘 구성되어 있어서 문서화 과정이 한결 수월했고, 놓칠 수 있는 항목들도 빠짐없이 체크할 수 있었다. 게다가 Confluence에서 문서가 생성되거나 수정되면, 해당 변경 사항이 Slack을 통해 Jira와 자동으로 연동되도록 설정까지 해주셔서 놀랐다. 이제는 누군가 문서를 만들었다고 따로 공유하지 않아도, Slack 알림을 통해 바로 확인하고 Jira에서 흐름을 파악할 수 있어 협업의 효율이 눈에 띄게 올라갔다.
 

와.. 오래 걸릴 것 같아서 미뤄두었던 Jenkins를, 오늘 내가 Slack 연동과 Postman을 만져보는 동안 우리 팀의 능력자 팀원분께서 구현에 성공하셨다! 익숙한 손놀림으로 외계어 같은 명령어들을 CLI에 와다다 입력하시는 모습이 정말 너무 멋졌다. 팀원 분께서 사용한 방식은 내가 처음에 생각했던 '직접 파일들을 VM에 설치하는 방식'이 아니었다. 대신, 다른 팀의 레이서 분께서 알려주신 방법인 Docker 기반의 환경 구성을 택하셨다. 즉, DB, 백엔드, 프론트엔드 환경을 각각 별도의 컨테이너로 구성하고, 이 세 개의 컨테이너를 하나의 docker-compose.yml 파일로 정의하여 docker-compose up 명령어 한 줄로 환경을 실행하고, docker-compose down으로 깔끔하게 종료할 수 있도록 구성하신 것이다. 아직 이 단계에서는 각 컨테이너 간 통신이 완전히 이루어진 상태는 아니었지만, 웹 대상 서비스를 성공적으로 띄우는 데에는 성공하신 셈이었다. 이 부분은 팀원분께서 정리해주신 파일을 바탕으로 직접 로컬에서 실습하며 익혀봐야 할 것 같다.

---

📌 5/15 - 7일차 회고 (Postman을 활용한 API 테스트 자동화 & API 테스트 케이스 작성)

 

API 테스트는 Swagger UI를 활용해 직접 URL을 지정하고 요청 body를 구성한 뒤 요청을 전송했다. 그 결과, 201 OK 응답을 받을 수 있었고 로컬 DB에도 데이터가 정상적으로 저장되는 것을 확인했다. 오피스 아워에서 코치님께서도 '응답 구조만 잘 들어오면 충분하다'고 말씀하셔서, 이 정도 구현으로 1차 목표는 달성한 셈이다. 앞으로는 newman을 사용해 자동 실행까지 해보고 싶어서, 우선은 Postman collection을 잘 구성해보는 것부터 시작할 계획이다.
 

Postman에도 협업 기능이 있다는 걸 처음 알았다. 팀원이랑 같이 작업하니까 확실히 속도가 훨씬 빨랐다! 내가 원래 개인 워크스페이스에서 작업하던 collection도 팀 워크스페이스로 옮기는 게 정말 간단했는데, 그냥 'Move' 버튼을 클릭해서 원하는 위치만 지정해주면 끝이었다. 생각보다 API 테스트에서 확인할 게 그렇게 많지 않았다. 체크할 항목도 많지 않고, 흐름만 잘 잡으면 금방 끝나는 느낌이었다.
 
처음에는 회원가입이 성공하면 응답으로 오는 token 값을 컬렉션 변수에 저장했는데, 알고 보니 로그인할 때마다 토큰 값이 바뀌는 구조였다. 그 이유는 대부분의 인증 시스템이 JWT(Json Web Token) 기반으로 구현되어 있고, 이 토큰은 로그인 시점에 사용자의 고유 정보 + 만료 시간 등을 바탕으로 서버에서 새로 생성되기 때문이다. 보안 상의 이유로 매번 로그인 시 새로운 토큰을 발급해서 이전 토큰이 유출되더라도 재사용되지 않게끔 막는 것이다. 그래서 결국 로그인 후에 응답으로 받은 token 값을 다시 컬렉션 변수에 저장해주는 방식으로 바꿨고, 이후 팔로우/언팔로우처럼 인증이 필요한 요청에서는 Authorization 헤더에 Bearer {{TOKEN}} 형식으로 값을 넘겨주었더니 정상적으로 잘 동작했다.
 

그리고 Articles, Comments, Favorites API 모두 URL에 {slug}가 포함되어 있었다. 처음에는 이 값을 어떻게 처리해야 할지 고민했지만, Postman의 요청은 순차적으로 실행된다는 점을 떠올리고, 그 흐름을 활용하기로 했다. 우선 Article 관련 API, 즉 POST 요청을 가장 먼저 실행되도록 구성했다. Swagger를 확인해보니 Article을 생성할 때 응답값에 slug가 포함되어 있었기 때문이다. 이 값을 pm.environment.set("SLUG", response.article.slug)와 같이 환경 변수에 저장해두고, 이후 Comments나 Favorites API에서는 {{SLUG}} 형태로 동적으로 재사용할 수 있도록 구성했다. API 자동화 테스트를 진행하면서 느낀 점은, 하드코딩된 값보다는 환경 변수로 분리해 유연하게 구성하는 방식이 유지보수나 확장성 측면에서 훨씬 뛰어나다는 것이다. 또한 테스트 시나리오 간에 데이터 흐름을 자연스럽게 연결해주는 점에서도 매우 유용했다. 사실 초반에는 token, slug 값을 컬렉션 변수로 저장하고, CLI 실행 시에는 컬렉션 파일만 추출했었다. 그런데 나중에 알게 된 건, Postman CLI에서는 컬렉션 변수만으로는 값을 읽어오지 못한다는 점이었다. 그래서 급하게 모든 값을 환경 변수로 옮겨 저장했고, 이후에는 컬렉션뿐만 아니라 환경 변수까지 함께 추출해 CLI에서도 테스트가 잘 작동되도록 구성했다.

 

오늘은 Collection 구성과 API 테스트 케이스 작성까지 완료했다. 사실 API 테스트 케이스를 작성하는 건 이번이 처음이라, 포맷도 정확히 모르겠고 이렇게 작성하는 게 맞는지도 잘 감이 오지 않았다. 예를 들어, 요청 데이터는 body에 어떤 값을 넣었는지까지 상세히 적는 게 맞는지, 예상 응답에는 객체의 키와 값을 모두 다 명시해야 하는지 등 여러모로 헷갈리는 부분이 많았다. 실제로 테스트 시나리오에 이런 정보들이 이미 일부 포함되어 있어서, 테스트 케이스에까지 똑같이 적는 건 중복이라는 생각도 들었다. 오피스 아워에서 코치님께서도 '결과값을 리포팅해서 뽑아낼 거라면, 테스트 케이스에는 테스트 코드 작성 시 어떤 부분을 검증했는지만 간단히 명시해도 된다'고 하셔서, 너무 디테일한 부분까지 억지로 채워 넣지 않기로 했다. 지금 작성한 수준에서도 나름대로 만족스럽고, 추후 리포트나 테스트 코드에서 얼마든지 보완할 수 있을 거라고 생각한다.
 

이 날은 엘리스 Lab 예약이 전부 차 있어서, 평소에 혼자 자주 공부하던 공유 오피스의 회의실을 빌려 작업했다. 사실 이 공간을 예약하기까지도 이런저런 일이 많았지만, 어쨌든 조용한 공간에서 집중할 수 있었던 건 다행이었다. 그리고 이날 처음으로 BHC 사장님께 추천받은 ‘맛초킹’을 먹어봤는데, 그동안 매번 뿌링클만 먹다가 색다른 맛을 발견한 기분이었다.
 
옆자리에서는 Jenkins 연동을 맡은 팀원분이 계속 머리를 쥐어짜며 고군분투하고 계셨다. 원래 Jenkins를 꼭 한번 다뤄보고 싶어 하셨고, 최근에 Docker 강의도 들으신 터라 “이번 기회에 꼭 도전해보겠다”며 직접 맡아주시기로 했던 상황이었다. 그런 모습을 보니 한편으로는 미안하면서도, 정말 고맙고 든든한 마음이 들었다. 사실 Jenkins는 세 명이 동시에 달라붙어도 하루가 다 갈 정도로 난이도가 높은 영역이라, 나는 Postman 테스트 쪽을 맡기로 했다.
 
처음에는 Postman이라는 툴 자체가 익숙하지 않았고, Swagger 문서를 보고도 무엇을 검증해야 하는지, 테스트 스크립트를 어떻게 작성해야 하는지, 그리고 테스트 흐름을 어떻게 구성할지조차 막막한 상태였다. 게다가 그동안 해봤던 건 대부분 연습용 API나 샘플 프로젝트 대상이었기 때문에, 실제 서비스를 대상으로 한 API 테스트를 구성하는 건 이번이 처음이라 낯설고 어려운 점이 많았다. 하지만 계속 손을 대다 보니 점차 감을 잡기 시작했고, 그 덕분에 하루 만에 Postman 테스트 스크립트 작성과 API 테스트 케이스 정리 작업을 모두 마무리할 수 있었다.

---

📌 5/16 - 8일차 회고 (Newman을 통한 report 생성 & API 테스트 결과 요약을 Slack에 자동 전송)

 

Docker를 활용해 Jenkins 연동에 도전하시는 팀원분의 천재성을 도저히 따라가기 힘들어서, 전날 새벽 3시까지 Docker와 Jenkins에 대해 GPT와 함께 공부했다. 1차 팀 프로젝트에서는 어떤 방식으로 Jenkins를 연동했었는지부터 시작해서, 현재 2차 프로젝트에서 그때와는 뭐가 다른지, Jenkins 연동을 위한 방법에는 어떤 선택지가 있는지, 그리고 각 방법들의 차이점은 무엇인지 하나하나 정리해가며 개념을 쌓았다. 특히 Docker를 통해 백엔드, 프론트엔드, DB를 각각 컨테이너로 띄우고, 이를 docker-compose.yml로 한 번에 실행하는 구조에 대해서도 집중적으로 학습했다. 환경 구성 흐름을 제대로 이해하려고 노력했고, 정리는 팀원분이 추천해주신 옵시디언으로 했다. 이거 써보니까 괜히 코치님 된 기분이 들었다 ㅋㅋ 아, 물론 그렇게 새벽 3시까지 공부한 덕분에 다음 날 늦잠 자서 지각한 건 안 비밀이다..
 

이 날은 같은 팀원분과 함께 완성한 Postman Collection을 전체적으로 실행해보면서 발생하는 오류들을 함께 찾아나갔다. 함께 하나씩 오류의 원인을 파악하고 고쳐나가며 Failed 수가 점점 줄어드는 걸 보는 과정이 정말 즐거웠다. 마지막에 Failed 수가 0이 되었을 때의 그 쾌감은 아마도 잊지 못할 것 같다. 그리고 팀원분께서 'Newman 테스트가 끝난 뒤에도 Slack에 자동으로 결과 알림이 전송되면 너무 좋을 것 같다'고 하셔서, 바로 기능을 추가했다. 예전에 작성해둔 pytest 테스트 결과를 Slack에 전송하는 코드와 구조가 크게 다르지 않아서, 이번에도 GPT의 도움을 받아 금방 구현할 수 있었다.
 

이 날은 팀원분들과 함께 Jenkins에서 테스트가 실패하는 이유를 끝까지 파헤쳐본 날이었다. 우리는 각 테스트 간 의존성을 없애기 위해 DB를 초기화하고 회원가입부터 시작하도록 구성했지만, 이상하게도 모든 테스트가 실패하고 단 하나만 통과했다. 그 유일한 성공 케이스는 리다이렉션 테스트였다. 이 테스트는 회원가입 없이 버튼 클릭 후 URL 변경만 확인하는 것이었다.
 
이 차이점이 힌트였다. 우리는 회원가입 로직에 print()문과 스크린샷 저장, DOM 구조 반환까지 넣어가며 원인을 추적해나갔다. 회원가입 버튼을 누르기 전과 누른 후의 print()가 모두 출력되었고, 클릭 이벤트도 문제없이 발생했다. 하지만 회원가입이 완료되었는지 확인하는 마지막 assert에서 계속 실패가 났다. 스크린샷을 보면 항상 회원가입 버튼을 누른 직후, 응답을 기다리는 상태에서 캡처가 되고 있었다.
 
이상했다. 로컬 환경에서는 문제 없이 회원가입이 잘 되었기 때문이다. 결국 우리는 '클릭은 되지만, 그 결과가 반영되지 않는다'는 점에서 컨테이너 간 통신 문제일 가능성을 의심하게 되었다. 프론트엔드와 백엔드, 혹은 백엔드와 DB 간 연결 중 어딘가가 제대로 작동하지 않고 있다는 추측이었다. 오피스 아워 시간에 이 상황을 코치님께 말씀드렸고, 코치님께서는 IP 및 네트워크 관련 설정 문제일 수 있다는 조언을 주셨다.

그리고 바로 그때, Jenkins를 담당하셨던 팀원분께서 조용히 말씀하셨다. '저 한 번만 믿어주세요.' 그러더니 과감하게 VM 내의 모든 파일을 밀어버리셨고, 얼마 후 갑자기 박수를 치셨다. 화면을 보니.. Jenkins 결과에 떠 있는 'PASSED'. 진짜 그 순간, 우리 모두 자리에서 벌떡 일어나 하이파이브를 치고, 신난 마음에 비를 뚫고 근처 편의점으로 달려가 머리를 식혔다.
 
그는... 진짜 신이었다. 이 복잡한 연동을 혼자서 해내시다니! 이후에는 어떤 과정을 거쳤는지 차근차근 설명도 해주셨고, 정말 많은 도움이 되었다. 다만 듣는 것만으로는 큰 그림이 완전히 그려지지 않아, 직접 공유받은 Dockerfile과 docker-compose.yml을 바탕으로 혼자 다시 한 번 해보면서 익히기로 했다. 설명 중에는 공인 IP, 사설 IP, 그리고 Docker 네트워크 구조 이야기까지 나왔는데..  그 순간 확실히 느꼈다. 아, 나는 아직도 모르는 게 너무 많구나. 배우긴 했지만 다 까먹은 것 같고, 부족한 부분은 다시 처음부터 차근차근 채워나가야겠다는 생각이 들었다.

---

📅 5/17 - 팀 모임 (테스트 데이터 분리 & Jenkins All Passed) 

  

Jenkins에서 run_prisma_seed() 함수를 사용하는 테스트가 모두 실패했다. 이유를 분석해보니, Backend와 Jenkins가 서로 다른 컨테이너 환경에서 실행되고 있다는 점이 원인이었다. run_prisma_seed() 함수 내부에서는 npx prisma db seed 명령어를 실행하면서, cwd 파라미터를 통해 backend 디렉토리에서 해당 명령어가 실행되도록 구성되어 있다. 즉, 로컬 환경에서는 잘 동작하지만, Jenkins 컨테이너 내부에는 backend 디렉토리 자체가 존재하지 않기 때문에 seed 명령어가 실패하는 구조였다. 이 문제를 해결하기 위해 Prisma CLI를 사용하는 대신, faker 라이브러리를 활용해 더미 데이터를 생성하고, 직접 DB에 삽입하는 방식으로 변경했다. Tag, User, Article, _ArticleToTag 테이블에 대한 랜덤 데이터를 넣어준 결과, 기존에 실패하던 테스트들이 모두 정상적으로 통과되었다!
 

그 후에, 팀원들과 함께 하나씩 실패한 테스트를 줄여나갔다. 그리고 마침내, All Passed! 🎉 그 결과 뒤에는 무려 10시간의 시행착오와 디버깅 과정이 숨어 있다. 이번 프로젝트를 통해, 오류를 파악할 때는 print()문과 스크린샷 등의 도구를 적절하게 활용하는 것이 정말 중요하다는 걸 다시 한번 느꼈다. 특히 print()문을 통해 현재 어떤 값이 담겨 있는지, 특정 로직이 실행되었는지 여부를 확인하는 과정은 문제 해결에 큰 도움이 되었다. 무엇보다도, 팀원들과 함께 머리를 맞대고 오류를 해결해 나가는 과정이 정말 즐거웠다. 실패한 테스트가 하나씩 줄어들 때마다 모두가 함께 기뻐하고, 디버깅 중에 "이 부분이 원인일 수 있다"며 의견을 나누는 과정 또한 매우 유익했다. 단순히 문제를 해결하는 것을 넘어서, 팀워크와 커뮤니케이션의 힘을 온몸으로 느낀 시간이었다.
 

오늘의 웃음벨 에피소드. 테스트 데이터 분리 작업을 맡아서, user_data.py 내에 있던 유효한 사용자 계정과 테스트 데이터를 분리하는 것이 적절하다고 판단했다. 왜냐하면, 유효한 사용자 계정은 보안상 .gitignore에 추가해 관리해야 하지만, 테스트에 사용하는 더미 데이터까지 굳이 감출 필요는 없다고 생각했기 때문이다. 게다가 이전부터 테스트 함수 내에 하드코딩된 테스트 데이터를 분리하고 싶다는 생각이 들어서, 이번 기회에 정리하려 했다. 그래서 user_data.py에는 유효한 사용자 계정만 남기고, 테스트용 데이터는 새로 만든 dummy_data.py로 옮기기로 했다. 그런데.. 그 파일 이름을 dummy_daya.py로 저장해버린 것이다. 테스트 실행 시 계속 오류가 나서 멘붕 상태였는데, 원인을 찾고 나서야 오타를 발견했다. 이걸 팀원들에게 말하자마자, 모두가 동시에 빵 터졌고 너무 웃겨서 배가 아플 정도로 웃었던 순간이었다. 작은 실수였지만, 덕분에 팀 분위기가 한층 더 밝아졌다. 😆

---

📚 5/18 - 개인 공부 (Docker 학습 및 자동화 흐름 정리)

 

정말 거의 2년 만에 만난 동기 친구! 서로 블로그를 통해 오랜만에 연락이 닿았고, 친구가 동아리 일로 서울에 온다는 소식을 듣고 만나게 되었다! 오랜만에 만난 만큼 할 얘기도 정말 많았다. 둘 다 취준생이다 보니, 서로의 진로 고민과 근황, 프론트엔드와 QA에 대한 이야기로 대화를 시작했다. 각자 하고 있는 프로젝트도 보여주며 "아, 이런 걸 하고 있구나", "너가 준비하는 직무는 이런 걸 만드는 거구나" 하며 서로의 분야에 대해 알아가는 시간을 가졌다. 그러던 중, 동기가 무려 1년 만에 완전히 이해하게 됐다는 Viewport 개념을 설명해줘서 그 이야기도 듣고, 새롭게 시작하게 된 동아리 얘기도 나누며, 사람들이 가진 스펙을 보며 “와 대단하다”는 반응도 나왔다. 쉬는 시간에 유튜브 보면 괜히 죄책감이 든다는 얘기까지 하면서, 공감하고 웃음이 끊이지 않았던 시간이었다. 역시 ISTJ와 ESTJ는 닮은 점이 많다. 생각하는 방식도, 살아가는 리듬도 비슷해서 더 잘 통했던 것 같다. "다음엔 대구에서 또 만나자!"고 약속하며 아쉬운 마음을 안고 헤어졌다. +TMI 하나 더! 카페 직원분이 내 사투리를 듣고 웃으면서 말을 거셨다 ㅋㅋ 그렇게 티가 나나봐..ㅎㅎ
 

그리고 오늘, 능력자 팀원분께서 "토스에서는 Slack에 /test (모듈명)을 입력하면 해당 모듈만 테스트가 돌아가게 한다"고 하시면서, 우리도 그걸 도전해보자며 직접 구현에 나섰다. 그리고.. 진짜로 성공하셨다! 🎉 Slack에서 /test를 입력하면 Jenkins가 자동으로 빌드를 실행하고, 테스트를 수행하도록 연동된 것이다. 정말 신기했다. 현업에서 쓰이는 기능들을 직접 구현해보니, 하나하나 붙일 때마다 자동화의 편의성과 효율성이 얼마나 큰지 실감할 수 있었다. 그리고 왜 요즘 CI와 테스트 자동화가 필수 요소로 자리 잡았는지, 뼈저리게 느껴지는 하루였다.
 

팀원분이 구현하신 모든 과정을 나도 스스로 공부해보았다. 컨테이너 간 통신이 가능하도록 설정한 network, subnet, gateway, IPv4Address, port 등의 개념을 하나하나 따라가며 학습했다. 직접 꼬리에 꼬리를 물며 개념들을 차근차근 정리해보니, 팀원분께서 Docker를 활용해 테스트 환경을 VM에 구성하신 전체 흐름을 대부분 이해할 수 있었다. 다만, 개념적으로만 아는 것에 그치지 않고, 직접 손으로 해보는 경험도 꼭 필요하다고 생각한다. 그래서 시간이 여유롭다면 프로젝트 기간 중에, 만약 그게 어렵다면 프로젝트가 끝난 후 대구로 돌아가 꼭 혼자 다시 시도해보고 싶다. 이 모든 과정을 약 3일 동안 산전수전 겪으며 묵묵히 구현해내신 팀원분께 진심으로 감사했고, 다시 한 번 존경스러움을 느꼈다. 또한, Jenkins 관련 내용을 정리한 파일을 팀원분들과 공유했는데, 모두 감사하다며 함께 읽어보았다. 내가 직접 정리한 글로 다 같이 공부하니 진짜 ‘하나의 팀’이 된 것 같아 뿌듯했다.
 

오늘은 사촌 언니가 오겹살에 베라까지 사주고 집까지 데려다줬다. 감동 파티.. 덕분에 하루는 Docker 관련 공부만 간단히 하고, OTT를 보며 행복하게 쉬는 중이었다. 그런데 늦은 시간, 동기에게 전화가 걸려왔다. SW 마에스트로에 참여 중인데, 창업을 시작했다며 나에게 “고객이 되어달라”는 제안이었다! 요즘은 AI의 발전 덕분에, 블로그 글이든 에세이든 AI 없이 글을 쓰는 사람이 드물 정도로 작성 환경이 편해졌다. 나 역시 마찬가지로, 아이디어와 의견은 내가 담되, 문장 다듬기는 주로 AI에게 맡기는 편이다. 그런데 친구는 이 AI 흐름을 한 단계 더 나아가, 데이터 기반으로 LLM을 활용해 '나만의 브랜딩'을 만들고, 블로그나 Thread 글처럼 콘텐츠 기반 수익화를 도와주는 서비스를 구상하고 있었다. 그리고 “이런 방향성에 관심이 있느냐”고 묻는 전화였다. 어차피 곧 부트캠프 수료이기도 하고, 합법적 백수 기간이 될 예정이기도 해서 “좋지! 재밌을 것 같아!” 하며 참여하겠다고 했다. 심지어 내가 두 번째 고객이라는 사실에 괜히 더 흥미가 생겼다. 많관부!

---

📌 5/19 - 9일차 회고 (JMeter을 활용한 성능 테스트 자동화 & 시연 영상 제작 및 발표 준비)

 

오늘은 다른 팀원 분들이 각자 맡은 작업을 진행하시는 동안, 나는 혼자 JMeter에 도전해보기로 했다. 테스트를 진행하면서 알게 된 점은, JSON Extractor로 추출한 변수는 해당 Thread Group 내에서만 유효하다는 것이다. 그래서 JSON Extractor 아래에 JSR223 PostProcessor를 추가하고, 아래와 같이 전역 변수로 저장해주는 방식으로 해결했다. 이후 다른 Thread Group이나 샘플러에서 이 값을 참조할 때는 ${__P(TOKEN_GLOBAL)} 형태로 호출하면 정상적으로 사용할 수 있었다.

def token = vars.get("token")
props.put("TOKEN_GLOBAL", token) 

 

처음에는 하나의 Test Plan 안에 모든 성능 테스트를 각각의 Thread Group으로 구성했었다. 그런데 Thread Group은 기본적으로 병렬 실행되기 때문에, 예상치 못한 문제가 발생했다. 예를 들어, 아직 Sign Up이 50번 다 돌기도 전에 Sign In이 먼저 실행되어 로그인에 실패하고(즉, 가입되지 않은 상태에서 로그인을 시도하게 됨), Sign In이 끝나기도 전에 Article POST 요청이 먼저 실행되면서 token 발급 전이라 Authorization에서 token 값을 제대로 읽지 못하는 상황이 벌어졌다. 이런 문제를 피하기 위해 결국 각 테스트를 Thread Group 단위로 분리해서 각각 .jmx 파일로 따로 나누기로 했다. 그런데 이렇게 나누면 또 다른 문제가 생겼다. JMeter에서 .jmx 파일이 분리되면 전역 변수를 공유할 수 없기 때문에, 이전에 저장해둔 token 값을 다른 테스트에서 바로 읽어올 수 없게 되었다. 그래서 이 문제는 token 값을 csv 파일로 저장해두고, 이후 테스트에서는 그 파일을 다시 읽어오는 방식으로 해결했다. 번거롭긴 했지만, 실행 순서 보장과 의존성 문제를 해결하기 위해 필요한 조치였다.
 

로컬 환경에서는 HTML 리포트 생성과 Slack 전송까지 모두 잘 작동했지만, 문제는 dev 환경이었다. 즉, Jenkins에서는 해당 기능이 제대로 동작하지 않았다. 아무리 살펴봐도 경로 문제처럼 보였고, 몇 시간을 붙잡고 있어도 쉽게 해결되지 않았다. 그러던 중, 어느덧 오후 7시. 오피스 아워 시간이 다가왔다. 오늘은 5팀 분들과 함께 오피스 아워를 진행했는데, 정말 뜻깊은 시간이었다. 각자 자기소개를 나누고 앞으로의 목표를 공유한 뒤, 코치님께서 이력서와 포트폴리오 작성 꿀팁까지 전수해주셨다. 덕분에 오늘 하루가 아주 알찼다. 이제 남은 과제는 하나. 내일 발표 전까지, 과연 jmeter의 dev 환경 오류를 해결할 수 있을까...?

---

📌 5/20 - 10일차 회고 (프로젝트 발표 및 회고)

 

오늘은 드디어 프로젝트의 마지막 날이다. 발표 제출을 위해 자료를 정리하고, 팀원들과 함께 발표 자료를 만들고, 또 그 자료를 검토하고, 발표 대본까지 작성하다 보니 다른 일에는 손을 댈 시간이 없었다. 오늘 하루는 오로지 발표 하나에만 집중하기로 했고, 실제로 발표 준비에 모든 에너지를 쏟아부었다. 특히 팀원 한 분이 편집을 담당해주셨는데, 생각보다 너무 잘하셔서 정말 깜짝 놀랐다 ㅋㅋㅋㅋ 완전 능력자!
 

발표를 맡아주셨던 팀원분께서 발표 전에는 정말 많이 떨려 하셨다. 그런데 막상 실전이 되자, 계속 감탄하면서 들을 수밖에 없었다. 어쩜 그렇게 차분하고 또렷하게 발표를 잘하시는지.. 발표가 끝난 후에도 내내 칭찬을 드렸다. 그만큼 너무 고마웠고, 든든했다. 이번 프로젝트는 정말 ‘버스를 탄’ 기분이었다. “내가 한 건 뭐지..?” 싶을 정도로, 두 분께 너무 감사드렸다. 프로젝트가 끝난 후, 혼자 러닝하러 갈 때마다 늘 만석이던 곱창집에 한 번쯤은 가보고 싶었는데 같이 갈 사람이 없었다. 이 얘기를 했더니, 마지막 날엔 꼭 같이 가자고 약속해주셨다. 그래서 함께 갔고.. 진짜 너무 맛있었다! 메뉴 이름도 하필이면 “삼총사”라니 ㅋㅋㅋㅋ 우리 셋이 딱 삼총사 같아서 더 의미 있었다. 1시간 만에 인당 소주 2병씩.. 술도 잘 드시더라. 대체 못하는 게 뭘까 싶을 정도였다. 곱창을 먹으며 회고도 함께 했다. 이번 프로젝트에 대해, 앞으로의 인생에 대해, 우리가 만든 결과물에 대해 이야기를 나누다 보니 시간이 정말 금방 흘렀다.

---

🎯 2차 프로젝트 최종 회고

 
✅ POM 구조 적용과 컴포넌트화

이번 프로젝트에서 가장 큰 발전이라고 느낀 부분은 구조적인 측면이었다. 특히 POM(Page Object Model) 구조를 적용한 것이 가장 의미 있었고, 여기에 더해 페이지를 header, body, footer로 나누어 바라보면서 자연스럽게 component 단위로 분리하고 적용할 수 있었던 점이 인상 깊었다. 공통적으로 사용하는 메서드들은 BasePage에 정의하고, 개별 페이지에서는 해당 페이지 전용 요소들과 함께 BasePage의 메서드를 활용해 동작을 구현했다. 덕분에 테스트 함수에서는 객체 생성 후 메서드 호출만으로 테스트를 구성할 수 있어, 유지보수성과 재사용성 측면에서 크게 발전한 구조라고 생각한다.
 

✅ 시나리오 형식 테스트 적용 경험

이번에는 테스트 케이스를 처음으로 시나리오 기반으로 작성해보았다. 팀원 모두에게 익숙하지 않은 방식이라 처음엔 다소 막막했지만, 함께 머리를 맞대고 고민하며, 또 오피스 아워에서 코치님의 피드백을 받아가며 끝내 완성할 수 있었던 게 정말 뿌듯했다. 다만 아직까지도 테스트 시나리오를 어떻게 구성하는 것이 가장 좋은 방식인지에 대해서는 확신이 서지 않는다. 앞으로 더 다양한 경험을 통해 기준점을 잡아가야 할 것 같다.
 

✅ Docker 환경 구성에 대한 새로운 이해

이번 프로젝트를 통해 내가 알고 있던 Docker는 극히 일부분에 불과했다는 걸 깨달았다. 이전까지는 Jenkins 설치 등을 위해 Dockerfile을 간단히 만들고, 포트 설정 등이 귀찮아 docker-compose.yml을 써본 정도였다. 하지만 이번에는 프론트엔드, 백엔드, 데이터베이스까지 전체 환경을 Docker로 구성했고, docker-compose를 활용해 네트워크 및 포트를 세세하게 지정하여 docker-compose up -d 한 줄로 통합 실행 및 종료할 수 있는 구조를 체험할 수 있었다. 이 경험을 통해 Docker의 실무적 활용 방식에 대해 감을 잡을 수 있었고, 실제로 관련 서적을 구매해서 더 깊이 공부해보고 싶다는 생각이 들 정도로 매력적인 기술이었다.
 

✅ API & 성능 테스트 도구 활용 경험

이번 프로젝트에서는 실제 서비스를 대상으로 Postman과 JMeter를 처음으로 직접 사용해보는 경험을 했다. 처음에는 두 툴 모두 익숙하지 않아서 API 테스트 하나를 완성하는 데도 몇 시간이 걸릴 정도로 막막했다. 하지만 팀원들과 함께 협업하고, 코치님과의 대화를 통해 "응답 확인 정도만 해도 충분하다"는 팁을 얻고 나서부터는 부담 없이 접근할 수 있었고, 점점 감이 잡히기 시작했다. 그 결과 빠르게 테스트 케이스를 작성하고 마무리할 수 있었다.
 
JMeter는 아직 성능 테스트의 방향성에 대해 감이 부족한 상태다. 다른 팀에서 진행한 스파이크 테스트, 내구성 테스트, 벤치마킹 등의 시도는 정말 인상 깊었고, "성능 테스트도 이렇게 체계적으로 접근할 수 있구나"라는 걸 느낄 수 있었다. 나는 단순히 로그인/회원가입 50회, 게시글 작성/조회 50회, 댓글 작성 50회 등 단순한 부하 테스트만 떠올렸지만, 실제로는 확인할 수 있는 포인트가 훨씬 다양하다는 걸 깨달았다.
 
그리고 로컬 환경에서는 잘 동작하던 JMeter가 Jenkins 환경(dev)에서는 제대로 작동하지 않는 문제가 있었다. 경로 문제인 건 확실해 보였지만, 해결하는 데 시간이 부족했고 결국 끝내 고치지 못했다는 점이 너무 아쉬웠다. JMeter는 내가 혼자 맡았고, 그날 처음 다뤄본 툴이라 하루 만에 완성하기엔 많이 벅찼다. 아무리 그렇게 변명을 해도 결국은 내가 책임지고 끝내지 못했다는 사실이 가장 미안했다. 회고를 하면서도 계속 팀원분들께 미안하다고 말씀드렸는데, 그럴 때마다 "괜찮다"고 따뜻하게 말해주시는 모습에 오히려 더 미안한 마음이 커졌다.
 

✅ Slack 활용

실무 경험이 있으신 팀원분께서 “현업에서는 퇴근 전에 자동화된 테스트를 돌려놓고, 그 결과를 Slack을 통해 팀원들과 함께 확인하곤 했다.” 라고 말씀해주셨다. 그 말을 듣고 나도 뭔가 꼭 한 번 도전해보고 싶다는 생각이 들었다. 사실 지난 사이드 프로젝트에서도 시도해보고 싶었지만, 시간 부족으로 결국 해보지 못했던 게 아쉬움으로 남아 있었기 때문이다. 이번 프로젝트에서는 드디어 그 기능을 직접 구현해볼 수 있었다. 놀라운 건, 생각보다 너무 간단했다는 점이다. 이렇게 간단한 설정만으로도 이렇게 큰 효율을 가져다줄 수 있다니! 진짜 실무에서 왜 이걸 쓰는지 체감할 수 있었다. 실제로 테스트가 끝난 후 Slack으로 알림이 전송되자, 팀원들 모두 “와 진짜 실무 같아!”라며 감탄했고, 나도 그 반응에 굉장히 뿌듯했다. 물론 GPT의 도움을 많이 받긴 했지만, 직접 구현해보고 그 과정을 이해한 것 자체에 대해 정말 큰 만족감을 느꼈다.

✅ 따뜻했던, 그리고 열정적이셨던 팀원분들

부트캠프 프로젝트를 한다고 무작정 서울로 올라온 나. 처음엔 걱정도 있었지만, 이번 부트캠프를 들으면서, 그리고 프로젝트를 진행하면서 정말 좋고 따뜻한 분들을 많이 만날 수 있었다. 내가 뭐라고.. 매번 응원해주시고, 칭찬해주시고, 격려해주셔서 몸 둘 바를 몰랐다. 기차 타고 대구로 돌아가는 길에 “기차 타셨어요? 조심히 가세요”라는 연락을 받았을 때, 정말 혼자 울컥해서 눈물이 났다.

 

우리가 오전 10시부터 오후 11시까지 함께하다 보니, 너무 빠르게 정이 들어버린 것 같다. 두 분 다 배려심 넘치고, 따뜻하시고, 항상 의견을 적극적으로 내주시고, 무엇보다도 열정적이셨다. 자신이 맡은 일은 집에서도, 주말에도, 끝까지 책임지고 마무리하는 모습에 진심으로 감동했다. 특히 한강에서 Docker 작업하시던 사진은.. 아마 평생 잊지 못할 것 같다. 사실 Jenkins 연동이 너무 어려워 보여서 엄두가 안 났는데, 그걸 끝까지 책임지고 해결해주신 것도, 발표 부담이 컸을 텐데 멋지게 마무리해주신 것도 너무너무 감사드린다.

 

서울에 머무는 동안 프로젝트를 통해 실력도 얻었지만, 무엇보다 사람에 대한 따뜻한 기억을 함께 안고 간다. 심지어 프로젝트가 끝난 뒤에도 편하게 연락하자며 서로 카카오톡 프로필까지 주고받았다. 그만큼 마음이 잘 통하고, 오래 기억에 남을 분들이다. 지난 4개월 동안 매일 수업 듣고, 함께 공부하고, 고생했던 모든 분들이 앞으로도 행복하게, 그리고 잘 되셨으면 좋겠다. 진심으로!