WEEK 15 나만무 TIL(6월24일 화요일)

Devkty·2025년 6월 26일

week 15 나만무 크래프톤 정글 연대기

크래프톤 정글(나만의 무기 만들기 WEEK 14 ~ 20)

목록 보기

18/57

[목표]
~~토스에서 이슈트래킹하는 방법을 공부합니다.~~
~~이슈트래킹 웹사이트를 클론 코딩할 수 있는 여부를 조사합니다.~~
아마존 내용을 정리합니다.

11:00 ~ 12:30

어제 한 내용에 대해서 정리했습니다.
토스에서 이슈 트래킹하는 방법에 대해 공부합니다.

12:30 ~ 13:00

식사를 했습니다.

13:00 ~ 13:30

토스의 QA 과정을 살펴보았다. 보통 QA 단계에서 트러블슈팅을 하기 때문이다.

토스 QA팀 정보들

https://toss.oopy.io/58d38b45-1653-4837-90f7-59c5d5bac684?utm_source=chatgpt.com
토스페이먼츠의 제품들은 매우 다양하고 각 제품들이 가지는 특성이 모두 다르기 때문에 제품에 대한 높은 이해도가 필요해요. 내가 무엇을 다루고 있는지 정확하게 알아야 제대로 된 테스트가 가능하기 때문이에요.
테스트 설계를 위해 제품의 기획 단계부터 참여하여 싱크를 맞추고, QA 과정에서 개발자분과 티키타카를 통해 이슈 트래킹을 하게 되며, 라이브 배포 후 모니터링까지 제품의 시작과 끝을 함께하게 되죠. 이 모든 과정에서 메인 기능부터 세부적인 스펙까지 보완할 부분이 없는지, 유저에게 더 나은 경험을 제공할 수 있는 방법이 있을지 팀/사일로 분들과 함께 고민하며 제품의 완성도를 높이기 위한 노력들을 하고 있어요.
또한 이렇게 업무를 하며 얻게 된 인사이트를 팀원들과 주기적으로 공유하며 서로 더 발전할 수 있는 방향을 모색하고 있습니다.

https://toss.tech/article/tosssec-qateam
QA Manager는 다양한 툴을 통해 서비스와 관련된 크고 작은 변경 사항들을 미리 확인할 수 있어요. 접근 권한 또한 열려 있어서 개발자의 작업 상태를 확인할 수 있고요. 자체적으로 QA계획을 수립해서 작은 단위부터 미리 테스트를 시작할 수도 있고, 통합테스트(Integration Test) 및 모니터링과 같은 QA 단계도 직접 조율할 수 있어요.

QA Manager가 테스트를 진행하지만, 살충제 패러독스(Pesticide Paradox)에 빠지지 않도록 개발자도 배포를 위한 Regression Test Case를 별도로 수행하고 있어요. 매주 랜덤으로 수행자를 지정한 뒤 테스트가 완료되어야만 앱 심사 등록 요청이 가능하도록 하고 있어요. 서비스를 만들어가는 담당자 모두가 안정적인, 높은 품질의 서비스를 제공하고자 하는 마음이 크기 때문에 가능한 방식이라고 생각해요.

토스증권에서는 기능별로 Silo가 만들어져있고, 그 Silo에는 PO, Developer, PD, DA, QA가 함께 서비스를 만들고 있는데요.

PO(Product Owner), 개발자(Front/Server/Core), PD(Product Designer), DA(Data Analyst), QA(Quality Assurance)

개발이 완료된 서비스들은 1차로 개발자 단위 테스트를 진행 후 QA Manager는 알파 환경에서 계획한 테스트를 진행하고, 이슈 수정이 모두 완료되면 QA 환경에서 최종 확인된 기능에 대해 서비스 Release를 Silo 별로 진행하고 있습니다. 이런 과정은 일반적인 IT 회사의 QA Cycle과 비슷하게 진행하고 있어요.

하지만, 토스증권에서는 내부 임직원들 대상으로 테스트 참여를 유도하여 미처 발견하지 못한 Edge Case 들과 보다 다양한 사용자의 피드백을 미리 얻고자 Closed Beta Test를 진행하기도 한답니다. 실제 제가 작년에 진행했던 토스증권의 해외 주식 서비스 런칭 경험을 소개해 드리려고 해요.

토스증권에서 진행한 내부 임직원 테스트는 아래의 다양한 테스트 방식의 개념을 조금씩 섞어서 진행했어요.

QA라면 모두가 알고 있는 탐색적 테스팅의 개념, Dog Fooding, Bug Bash를 모두 활용하였는데요. 그전에 개념들을 한번 언급하고 지나갈게요!

Closed Beta Test란?
비공개 베타 테스트로, 서비스를 정식으로 오픈하기 전에 프로그램의 버그를 찾거나 사용성, 요구사항 충족 등을 검증하기 위해 개발자와 관련되지 않은 사용자에 의해 진행되는 테스트

탐색적 테스팅이란?
테스트 대상 제품을 사용하면서 제품의 정보 습득과 동시에 테스트를 설계하고 실행하는 방식으로 탐색적 테스팅의 주요 구성요소는 Test Charter, Test Note, Time Boxing, Debrief가 있음

Dog Fooding 이란?
서비스 출시 전 사용자의 입장에서 내부 인원이나 개발자가 직접 사용하며 제품을 개선하는 것

Bug Bash란?
제품이 최종 릴리즈되기 전 다양한 직군의 인원들이 제품을 사용하며 아직 남아있을 수 있는 버그를 찾아내는 활동으로 짧은 시간에 많은 인원이 진행하기 때문에 상대적으로 빠르게 버그를 찾을 수 있음

대표적으로 Slack에서 JIRA(Bug Tracking System)를 바로 연동하여 이슈를 생성하고 완료까지 처리할 수 있는 (Bot)이 있어요. 또 Slack의 Workflow에서 Emoji를 남기면, 해당 게시글이 다른 채널로 전달되는 기능을 활용해서 보다 편하게 이슈를 모아볼 수 있었어요.

서비스 출시 전, 통합테스트는 어떤 의미였을까요?

임직원 대상으로 진행한 통합테스트는 QA팀에서 QA Plan에 맞게 여러 테스트 Iteration을 수행하고, 개발 Side의 단위 테스트, 성능 테스트가 진행이 되었다 하더라도 우리가 만든 서비스가 만든 의도에 맞게 동작하는지에 대해 미리 임직원 대상으로 실험할 수 있었어요. 우리가 만들었던 기능 중에서 우려했던 부분 역시 다시 드러나면서 개선이 더 필요한 부분에 대해 Maker 들과 공감대 형성에 가장 큰 역할이 되었습니다.

또한, 우리가 사용자에게 의도한 대로 동작하는 부분이 제대로 동작하는지까지 미리 알 수 있었고 그 장치들을 더 효과 있게 바꾸는 계기도 되었어요.

토스증권 QA팀에서는 정량적인 서비스 품질뿐만 아니라, 회사에서 품질을 생각하는 문화에 대해서도 모두가 참여하도록 유도하고 서비스 품질에 대한 정성적인 기준에 대해 다 같이 고민하는 시간을 만들어가는 과정에도 주도적으로 참여해야 한다고 생각합니다.

그래서 bugbash, closed beta testing, 탐색적 테스팅 등과 같이, QA라면 흔히 알고 있는 이런 여러 테스트 방식 중에서 필요한 부분으로 토스증권만의 ‘통합테스트’ 라는 컨셉을 만들었어요. 또한, 임직원 70% 이상이 참여하도록 만들었고 그 결과 또한 성황리에 마무리할 수 있었어요.

이후로 임직원과 함께하는 통합테스트는 토스증권의 QA 문화로 자리매김할 수 있었고, 지금도 큰 서비스가 출시될 때마다 통합테스트를 주기적으로 진행하고 있습니다.

13:30 ~ 15:00

코치님과 함께 개발에 대한 여러 이야기를 했다.

15:00 ~ 16:00

코치님하고 아이디어 관련 이야기를 하기 전에 팀원들하고 내용 정리를 했다. 어떤 식으로 말할지...

16:00 ~ 16:30

유윤선 코치님과 3번째 팀단위 커피챗을 했다. 우리가 진행하려는 이슈 트래킹 시스템에 대해서 확인해보고, 어떤 방향으로 나아가면 좋을지 말씀해주셨다.

기존의 이슈트래킹 방향보다는 우리가 학습을 목적으로 이슈트래킹 시스템을 클론 코딩해보고, 기존의 서비스들과 차별점을 두기 위해 우리만의 클론 코딩 룰을 검사하여 퍼센트지로 나타내고, 커밋을 하는 도중에 검사하여 일정 퍼센트를 넘지 않으면 다시 커밋을 요청하거나 반려될 수 있게끔 하는게 어떤지에 대해 피드백해주셨다. 특히나 코드 수정 요청을 하는 로직을 어떻게 할지 중요한 포인트이며 지식적으로 깊지 않기 때문에 애자일 기법이나 이슈트래킹의 장단점을 고친다는 말은 안하는 편이 좋다고 하셨다.

방향성자체는 좋기 때문에 팀원들도 이 주제를 그대로 가져가기로 했다.
노티드 도넛을 먹었다.

15:30 ~ 18:00

주제에 대해 나눴던 이슈트래킹 시스템에 대해서 곧 잇을 커피챗과 발표를 위해 가이드 라인에 따라 정리하고 있다.
명석: 스크럼 공부
진혁: 애자일, 지라 공부

18:30 ~ 19:30

식사를 하고 왔다.

19:30 ~ 23:00

우리의 주제 선정 배경, 아이디어 설명, 예상되는 기술적 챌린지, 부가적인 기술 구현에 대해서 확인을 했습니다.
프로젝트명, 와이어 프레임, PPT, 스크립트, 아키텍처 이유, 아이디어 설명, 핵심 기능 설명 필요

23:00 ~ 05:20

프로젝트 이름을 정하고자 했지만 정하지 못했습니다. 기술 스택에 대해서 이유들을 알아보았고, 엑셀에 변경된 주제에 대해 업데이트를 했다. 하지만, 이름은 미정으로 못올렸다.

PPT를 만들기 위해서 주요 내용들을 작성한다.

드디어 PPT작성과 대본 작성 완료했다. 긴 시간이 걸렸다… 그러나 내용은 훌륭한 것 같다.
밑에 내용이 완성된 내용이다.

Code Planner

코드 퀄리티 향상 도움 이슈트래킹 시스템.

기존의 이슈트래킹 서비스에 더해 코드 포맷과 정적 분석 기능을 추가하여 코드 퀄리티 향상 체계를 도입한 플랫폼입니다.

주제 선정 배경

여러분들은 정글에서의 지난 4개월동안 자신의 코드에서 발생한 이슈에 대해서 체계적으로 관리하고 기록을 하셨나요?

저는 4개월동안 정글에서 노션과 같은 협업툴을 사용하며 체계적인 이슈 관리가 되지 않음을 느꼇습니다. 이슈를 정리해둬야 나중에 회고하면서 실수하지 않는데, 구현에 집중하여 미처 관리를 하지 못했습니다.

이에 이슈를 현업에서 어떻게 관리하는지 궁금하게 되었고 조사해본 결과 이슈트래킹 시스템에 대해 알게 되었습니다. 이러한 이슈트레킹을 이해하고 가면 취업에 도움이 되지 않을까 해서 이슈트래킹 서비스를 구현하면서 이해하고자 주제를 선정하게 되었습니다.

핵심기능

이슈트래킹의 일부 기능 제공 (이슈 등록/검토/해결, 담당자 배정 등)
코드 퀄리티 향상 검사 기능 제공 (코드 포맷 clang-format, 정적 분석 clang-tidy)

Static Linter (문법‧규칙)	ESLint, TSLint, Pylint, Rubocop, Stylelint	변수/함수 네이밍, 사용 안 하는 코드, 스타일 일관성
Security & Bug Query	CodeQL, Semgrep, Bandit	취약점 패턴·타입 오류 → 클린코드 -5점씩 깎기(!)

clang-format (코드 포맷팅)

기능: 코드 스타일 일관성 유지. 자동으로 괄호, 들여쓰기, 공백 등 정리.
장점: LLVM 프로젝트의 일부로, 다양한 스타일 지정 가능 (Google, LLVM, Mozilla, WebKit 등).

cppcheck

기능: C/C++ 코드의 버그, 누수, 논리 오류 탐지. 주로 C에 최적화됨.
장점: 빠르고 설치 간편, 커맨드라인 통합이 쉬움.

clang-tidy (정적 분석 + 일부 스타일 검사도 가능)

~~기능: 코드의 버그 가능성, 성능 문제, 스타일 문제 등을 정적 분석.~~
~~장점: 모던 C++에 강하지만 C도 잘 지원함. clang-format과 함께 쓰기 좋음.~~
c언어 코드 분석기(lint, formatter)

clang-format

clang-format --dry-run --Werror main.c

indent 4일때의 코드 포멧팅 검사
```
younho@gim-yunhoui-MacBookAir lint-server % clang-format --dry-run --Werror main.c

main.c:3:11: error: code should be clang-formatted [-Wclang-format-violations]
int main()  {
          ^
main.c:3:14: error: code should be clang-formatted [-Wclang-format-violations]
int main()  {
             ^
main.c:4:15: error: code should be clang-formatted [-Wclang-format-violations]
        int x;
              ^
main.c:5:20: error: code should be clang-formatted [-Wclang-format-violations]
        int y = 10;
                   ^
main.c:6:21: error: code should be clang-formatted [-Wclang-format-violations]
        if (y = 5) {
                    ^
main.c:7:35: error: code should be clang-formatted [-Wclang-format-violations]
                printf("Hello\n");
                                  ^
main.c:8:10: error: code should be clang-formatted [-Wclang-format-violations]
        }
```
clang-format -i main.c

cppcheck

cppcheck -I /usr/include --enable=all main.c
```
(information) Couldn't find path given by -I '/usr/include/'
Checking main.c ...
main.c:1:0: information: Include file: <stdio.h> not found. Please note: Cppcheck does not need standard library headers to get proper results. [missingIncludeSystem]
#include <stdio.h>
^
main.c:6:11: style: Condition 'y=5' is always true [knownConditionTrueFalse]
    if (y = 5) {
          ^
main.c:6:11: style: Variable 'y' is assigned a value that is never used. [unreadVariable]
    if (y = 5) {
          ^
main.c:4:9: style: Unused variable: x [unusedVariable]
    int x;
        ^
nofile:0:0: information: Active checkers: 109/856 (use --checkers-report=<filename> to see details) [checkersReport]
```
코드 포매터 : 정해진 규칙(코딩 컨벤션)에 맞추어 코드를 정렬하는 도구

기업에서 코딩 스타일, 컨벤션이 있는데
- 자동으로 코드 정렬하거나 보기좋게 커스터마이징 하여 꾸밀 수 있음
- 코드의 가독성을 높이는데 중요한 약속
- 협업에서 각각 코드스타일이 다르다면, 서로 코드 읽기에 불편할 것이다.
  
  코딩 컨벤션을 지키지 않아 코드의 질이 안좋아질 수 있기 때문에 필수적으로 협업하는 팀원들은 약속을 지켜야 함
  
  이걸 하나하나 지키는것이 어렵기 때문에, 코드 포매팅을 자동화 해주는 기술이 필요했다.
  
  코드 린터: 코드 포메터(줄간격, 띄어쓰기 간격, 함수의 선언, 스타일, 논리의 변경 없고, 코드의 변경이 없는)
  
  과 달리, 실제 논리적인 코드 부분에 관여하는 검사이다.
- 사용하지 않는 변수에 대해 경고
- 무조건적으로 실패하거나 성공하는 분기문 검사
  
  c언어에서 지원하는 도구는 2가지가 있다.
  
  clang-format : 코드 포멧 분석기
  
  clang-tidy: 코드 정적 분석기
  
  코드를 실행하지 않고 문제점 파악
  
  모던 c++ 스타일을 권장한다.
```
int x;
if (x = 5) {
  // ...
}
```
  컴파일러에서 못잡아준다. 물론 오류가 아니기도 하지만, 일반적으로 이런식으로 하면 버그가 난다는 것을 알려주는 것이다.
  
  하지만, modernize-*, cppcoreguidelines-*, performance-* 등, ㅊ다른 기능들에 대해서는 쓸 수 없음(사실 CppCheck 또는 Splint 를 쓰긴 한다.)
  
  그리고 gpt왈, clang-formater랑 cppcheck가 더 좋다
  
  (clang-tidy는 기준을 c++을 기준으로 하기 때문에, c에서 쓸대없이 트집을 잡을 수도 있음)
  
  그래서 cppcheck(c를 기준으로 만들어진 툴이기 때문에)를 쓸것이다.

설명(스크립트)

먼저 핵심기능입니다.

첫번째 핵심 기능은 ITS 사이트의 기능 중에서 이슈 보고 및 등록, 담당자 배정, 이슈 해결과 같은 이슈 관리 기능을 구현할 예정입니다. 깃허브 API와 이슈가 연동되어 브런치를 생성하고 커밋을 등록할 수 있고, 이 과정에서 깃허브의 OAUth를 이용하려고 합니다. 해당 이슈가 완료된 후에는 사용자가 PR을 보낼 수 있고, 보낸 PR은 PR 게시판에 자동으로 등록되어 담당자가 병합을 할 수 있게됩니다.

두 번째 핵심 기능은 코드 퀄리티 향상 검사 기능입니다. 이슈의 담당자가 할 일을 모두 완료하고, 커밋한 후 QA나 팀리더에 가기전에 이 기능을 통해서 개발자에게 코드의 형식을 지키게 하고 더 나은 코드를 유지할 수 있게 할 수 있습니다. 현재 계획으로는 C언어를 제한적으로 지원할 예정입니다.

시연/데모

와이어 프레임으로 대체.

아키텍처

아키텍처는 다음과 같습니다. 현재 구상 중이며 프론트엔드는 재사용 가능한 컴포넌트로 유지보수가 유리한 리엑트를 사용하고, 벡엔드같은 경우는 이슈 생성 버튼을 누르면 DB에 저장되는 동안 화면이 즉시 응답해야하므로 비동기 처리가 유리한 Node.js와 복잡한 기능을 만들때 역할을 분명히 분리하여 쓰기 용이한 NestJS로 결정하게되었습니다.

데이터 베이스 같은 경우, RDBMS인 MySQL와 NoSQL인 MongoDB를 쓰고자 합니다. MySQL은 회원정보와 같은 정형 데이터를 저장하기 위함이고, MongoDB는 커밋 로그와 같이 비정형 데이터를 저장하기 위해 두 유형의 데이터 베이스를 사용하게 되었습니다.

형상관리는 깃허브를 사용하고, 이슈트래킹 툴은 저희의 서비스 전신이라고 볼 수 있는 지라를 직접 도입하면서 벤치마킹하고자합니다.

배포는 EC2를 사용하고, 리버스 프록시 역할을 하는 Nginx와 시스템 성능 향상과 부하 분산에 효과적인 Redis를 도입할 것 입니다.

메일같은 경우 AWS SES를 통하여 메일을 보낼 예정입니다. 상황에 따라 시놀로지 웹서버도 고려중입니다.
여기서 필요한 기능에 대한 기술 스택이 있다면 추가될 예정입니다.

(그림은 완벽하지 않습니다.)

기술적 챌린지

코드 퀄리티 향상 검사 기능 구현. (저희의 플랫폼 같은 경우 우선적으로 C언어에 대해서만 검사 기능을 제공할 예정입니다. 이러한 코드의 품질을 검사하기 위해 clang-format, clang-tidy 도구와 AST와 같은 안티패턴 탐지 알고리즘을 사용하여 구현할 예정입니다.)
코드 퀄리티 검사 우회 방지. (커밋 단위로 검사하는데, 수정하지 않고 커밋하는 우회를 방지하기 위해 PR단계에서 재검사를 실시하여 방지합니다.)
동시성 처리 문제 해결. (Jira 같은 경우에는 문서를 작성 중에 동시에 저장하면 마지막 작성한 사람이 최종 반영합니다. 저희는 이러한 동시에 문서를 편집할 시 내용 사라짐 현상을 방지하기 위해 정글 OS 주차에 배운 Lock을 사용하여 한쪽이 작성 중에는 편집하지 못하게끔 구현할 예정입니다.)
견고하고 빠른 DB 설계. (해당 플랫폼을 운영하기 위해서는 회원정보를 저장하고 커밋로그를 분석하기 위한 DB가 필요합니다. 이에 저희는 MySQL과 MongoDB를 ERD 모형을 구상하여 구축하고자 합니다.)
이슈 상태 변경 시 사용자에게 메일 알림 전송 (상태 변경시 타사용자에게 알리기 위하여 아마존 SES를 통해 이메일을 송신하는 방법과 Synology 웹 메일 서버를 통해 송신하는 방법 두가지 중에 적합한 하나를 구축할 예정입니다.)
안정적인 서비스와 낮은 Latency 제공. (Nginx를 통해 역프록시 기능을 사용한 효율적인 트래픽 처리와 보안의 안정성을 확보합니다. 또한 Redis를 통해 캐싱으로 데이터 접근의 안정성과 속도를 확보합니다.) → 이렇게 하면 Node.js 서버는 비지니스 로직에만 집중 가능합니다.
~~자동 태그 시스템 (Ai를 통해 이슈에 대한 태그를 제공합니다.)~~

Redis: 데이터 접근의 안정성과 속도 확보(내부)

목표 측면	Redis가 기여하는 방식
빠른 응답 시간	DB보다 수십~수백 배 빠른 메모리 접근으로 사용자에게 즉시 응답
중복 연산 방지	정적 분석 결과나 계산된 점수 등을 Redis에 저장해 서버 부하 감소
DB 부하 분산	모든 요청이 DB로 가지 않고, Redis가 캐시에서 응답함으로써 DB 장애 방지
일관된 데이터 제공	TTL 기반으로 일정 시간 동안 동일한 요청에 대해 일관된 결과 제공

예: 수천 명이 동일한 프로젝트 대시보드를 열람할 때, DB가 아닌 Redis가 응답 → 부하 제로

Nginx: 트래픽 처리와 보안의 안정성 확보(외부)

목표 측면	Nginx가 기여하는 방식
트래픽 분산 및 리버스 프록시	외부 요청을 내부 Node.js 앱에 안전하게 전달 → 서비스 다운 방지
SSL/TLS 암호화	HTTPS 지원으로 사용자 데이터 보호 및 보안 신뢰도 향상
정적 파일 캐싱	이미지, JS 등은 Nginx가 직접 응답 → Node 서버는 핵심 로직만 처리
과부하 차단/보안 규칙 설정	IP 차단, rate limit 설정 가능 → 악성 요청 필터링

예: DDoS 시도를 Nginx가 차단하고, 내부 애플리케이션 서버는 그대로 정상 작동

Redis + Nginx를 함께 쓰면?

구조	결과
Redis로 데이터 응답 속도 향상	사용자 입장에서 빠르고 부드러운 UX 제공
Nginx로 트래픽 제어 및 보안 강화	외부 공격/실수로 인한 서비스 다운 방지
둘 다 서버 부하 분산 역할	Node.js 서버는 오직 핵심 비즈니스 로직에만 집중 가능

요약

목표	해결 방법	사용 기술
빠르고 끊김 없는 응답	캐싱으로 DB 접근 최소화	Redis
안전하고 유연한 트래픽 처리	프록시 및 암호화	Nginx
과부하와 장애 예방	트래픽/요청 분산	Redis + Nginx

부가적인 기술 구현

실시간 채팅 기능 (기존의 Jira는 많은 기업에서 Slack과 연동하여 매핑하여 사용합니다. 사용자 편의성을 위해 웹소켓.io를 통해서 추가적인 기능 구현합니다.)
사용자화 시각효과 (Jira에서는 밋밋한 카드 디자인과 UI로 강조가 되지 않는다고 평가된 사례가 존재합니다. 그래서 사용자화 시각효과로 시각적 편리함을 제공하고자 합니다.)

해당 두가지 기술은 프로젝트 진행 상황에 따라 진행할 예정입니다.

이렇게 2조 김태용의 발표를 마치겠습니다. 감사합니다.

Q & A 리스트

왜 Node.js을 사용했나요?

→ 스프링은 비동기 처리를 할 수는 있지만 복잡하고 난이도가 높아서, 다소 러닝커브가 낮고 비동기처리에 유리한 nodejs를 선택했습니다.

동시성 관련된 문제는 왜 생각하지 않으시나요?

→ 조사한 바로는 실제 이슈트래킹을 사용하기 전에 채팅을 통해 의사소통 후 수정하기 때문에 문제가 발생하지 않는다고 합니다. 또한 동시성처리로 인해 서버의 부하가 증가될 가능성을 우려하여 배제했습니다.

우회를 방지하기 위해 PR 단위에서 재검사를 실시한다는데, 왜 PR 단위에서 재검사를 하나요?

→ 커밋으로는 공백과 같은 커밋을 통해 건너뛸수 있습니다. 그러나 PR의 File changed를 기준으로 재검사를 하여 특정 퀄리티 이상으로 유지 않으면 PR이 거부되는 방식으로 구현을 하면 됩니다.

무엇을 기준으로 코드를 심사해서 코드의 퀄리티를 향상시킬 예정인가요?

→ 선언되었지만 실제로는 쓰이지 않는 변수, 한글로 명명되어있는 변수와 같은 코드의 스멜이 나는 경우를 기준으로 코드의 퀄리티를 향상시킬 예정입니다.

굳이 MongoDB와 MySQL로 데이터베이스를 이원화 시킨 이유를 들어볼 수 있을까요?

→ 현재로서는 커밋 로그를 저장할 필요가 있어보여 mongodb를 사용할 예정인데, 개발 과정중에서 필요치 않다고 판단되면 사용하지 않을 예정입니다.

Devkty

모든걸 기록하며 성장하고 싶은 개발자입니다. 현재 크래프톤 정글 8기를 수료하고 구직활동 중입니다.

WEEK 15 나만무 TIL(6월24일 화요일)

크래프톤 정글(나만의 무기 만들기 WEEK 14 ~ 20)

11:00 ~ 12:30

12:30 ~ 13:00

13:00 ~ 13:30