운영중인 DB가 느려진 것 같아서 인덱스 리빌드를 결정했다.

대상 선정을 위한 쿼리를 만들어 보았다.

SELECT
    PSUI.schemaname
    , PSUI.relname AS table_name
    , PSUI.indexrelname AS index_name
    , PSUI.idx_scan /* 인덱스가 사용된 횟수 */
    , PSUI.idx_tup_read /* 인덱스 튜플 수 */
    , PSUI.idx_tup_fetch /* 인덱스에서 실제 검색된 튜플 수 */
    , pg_size_pretty(pg_relation_size(PSAI.indexrelid)) AS index_size /* 인덱스의 크기 */
    , 'REINDEX INDEX CONCURRENTLY ' || PSUI.schemaname || '.' || PSUI.indexrelname || ';'
FROM pg_stat_user_indexes PSUI
    LEFT OUTER JOIN pg_stat_all_indexes PSAI
        ON PSAI.relname = PSUI.relname
        AND PSAI.indexrelname = PSUI.indexrelname
ORDER BY PSUI.idx_tup_read DESC, PSUI.idx_scan DESC, pg_relation_size(PSAI.indexrelid) DESC
;
------------------------------------------------------------------------------------------------------------------------
-- 거의 사용되니 않는 인덱스 -> 삭제하는 게 나을 수 있겠다
SELECT
    PSUI.schemaname
    , PSUI.relname AS table_name
    , PSUI.indexrelname AS index_name
    , PSUI.idx_scan /* 인덱스가 사용된 횟수 */
    , PSUI.idx_tup_read /* 인덱스 튜플 수 */
    , PSUI.idx_tup_fetch /* 인덱스에서 실제 검색된 튜플 수 */
    , pg_size_pretty(pg_relation_size(PSAI.indexrelid)) AS index_size /* 인덱스의 크기 */
    , 'REINDEX INDEX CONCURRENTLY ' || PSUI.schemaname || '.' || PSUI.indexrelname || ';'
FROM pg_stat_user_indexes PSUI
    LEFT OUTER JOIN pg_stat_all_indexes PSAI
        ON PSAI.relname = PSUI.relname
        AND PSAI.indexrelname = PSUI.indexrelname
WHERE PSUI.idx_scan < 100
ORDER BY PSUI.idx_scan DESC
;
------------------------------------------------------------------------------------------------------------------------
-- 크기가 너무 큰 인덱스
SELECT
    PSUI.schemaname
    , PSUI.relname AS table_name
    , PSUI.indexrelname AS index_name
    , PSUI.idx_scan /* 인덱스가 사용된 횟수 */
    , PSUI.idx_tup_read /* 인덱스 튜플 수 */
    , PSUI.idx_tup_fetch /* 인덱스에서 실제 검색된 튜플 수 */
    , pg_size_pretty(pg_relation_size(PSAI.indexrelid)) AS index_size /* 인덱스의 크기 */
    , 'REINDEX INDEX CONCURRENTLY ' || PSUI.schemaname || '.' || PSUI.indexrelname || ';'
FROM pg_stat_user_indexes PSUI
    LEFT OUTER JOIN pg_stat_all_indexes PSAI
        ON PSAI.relname = PSUI.relname
        AND PSAI.indexrelname = PSUI.indexrelname
ORDER BY pg_relation_size(PSAI.indexrelid) DESC
LIMIT 50
;
------------------------------------------------------------------------------------------------------------------------
-- 테이블 싸이즈에 비해 크기가 너무 큰 인덱스
SELECT
    PSUI.schemaname
    , PSUI.relname AS table_name
    , PSUI.indexrelname AS index_name
    , PSUI.idx_scan /* 인덱스가 사용된 횟수 */
    , PSUI.idx_tup_read /* 인덱스 튜플 수 */
    , PSUI.idx_tup_fetch /* 인덱스에서 실제 검색된 튜플 수 */
    , pg_size_pretty(pg_relation_size(PSAI.indexrelid)) AS index_size /* 인덱스의 크기 */
    , pg_size_pretty(pg_relation_size(T.oid)) AS table_size /* 테이블의 크기 */
    , ROUND(pg_relation_size(PSAI.indexrelid)::numeric / pg_relation_size(T.oid) * 100, 2) AS INDEX_RATIO
    , 'REINDEX INDEX CONCURRENTLY ' || PSUI.schemaname || '.' || PSUI.indexrelname || ';'
FROM pg_stat_user_indexes PSUI
    INNER JOIN pg_class T
        ON PSUI.relname = T.relname
    LEFT OUTER JOIN pg_stat_all_indexes PSAI
        ON PSAI.relname = PSUI.relname
        AND PSAI.indexrelname = PSUI.indexrelname
WHERE pg_relation_size(T.oid) > 0
AND pg_relation_size(PSAI.indexrelid) > 0
AND PSUI.idx_scan > 0
AND ROUND(pg_relation_size(PSAI.indexrelid)::numeric / pg_relation_size(T.oid) * 100, 2) > 100
ORDER BY INDEX_RATIO DESC
LIMIT 50
;
------------------------------------------------------------------------------------------------------------------------
-- 오래된 인덱스
SELECT
    PSUI.schemaname
    , PSUI.relname AS table_name
    , PSUI.indexrelname AS index_name
    , PSUI.idx_scan /* 인덱스가 사용된 횟수 */
    , PSUI.idx_tup_read /* 인덱스 튜플 수 */
    , PSUI.idx_tup_fetch /* 인덱스에서 실제 검색된 튜플 수 */
    , pg_size_pretty(pg_relation_size(PSAI.indexrelid)) AS index_size /* 인덱스의 크기 */
    , pg_stat_get_last_vacuum_time(PSAI.indexrelid) AS last_vacumm
    , 'REINDEX INDEX CONCURRENTLY ' || PSUI.schemaname || '.' || PSUI.indexrelname || ';'
FROM pg_stat_user_indexes PSUI
    LEFT OUTER JOIN pg_stat_all_indexes PSAI
        ON PSAI.relname = PSUI.relname
        AND PSAI.indexrelname = PSUI.indexrelname
WHERE PSUI.idx_scan = 0
OR PSAI.idx_scan = 0
ORDER BY last_vacumm ASC NULLS FIRST
;

2025년 SQLD 자격증 시험 일정과 준비 방법

SQLD (SQL Developer) 자격증은 데이터베이스 개발 및 관리에 필요한 SQL과 데이터베이스 관련 기술을 평가하는 자격증으로, IT 분야에서 데이터베이스 관련 업무를 담당하는 데 중요한 역할을 합니다. 2025년 SQLD 자격증 시험 일정과 함께, 효과적인 준비 방법에 대해 안내드리겠습니다.

2025년 SQLD 자격증 시험 일정

SQLD 자격증은 주기적으로 실시되며, 2025년 시험 일정은 다음과 같습니다:

• 시험 일정은 대체로 매 분기마다 실시되며, 응시 등록은 해당 접수 기간 내에만 가능합니다.
• 시험 방식은 객관식으로 진행되며, 온라인 또는 오프라인 시험을 선택할 수 있습니다.

SQLD 자격증 준비 방법

SQLD 자격증 시험은 데이터베이스와 SQL에 대한 기초적인 지식과 실무 경험을 평가합니다. 시험 준비를 위해서는 이론적인 학습과 실습을 병행하는 것이 중요합니다. 아래는 각 항목별로 준비 방법을 제시합니다.

(1) SQLD 시험 준비 개요

SQLD 시험은 데이터베이스의 기본적인 이해, SQL 사용법, 관계형 데이터베이스 설계, 성능 최적화 등 다양한 영역을 다룹니다. 시험 준비는 기본 이론과 실제 SQL 활용 능력을 키우는 데 집중해야 합니다.

(2) 주요 시험 과목

• SQL 기본 문법: SELECT, INSERT, UPDATE, DELETE와 같은 기본적인 SQL 명령어에 대한 이해.
• 데이터베이스 설계: ERD(Entity-Relationship Diagram) 설계, 정규화(Normalization)와 역정규화(Denormalization), 데이터 모델링.
• SQL 성능 최적화: 인덱스, 조인, 서브쿼리 등의 성능 최적화 기법.
• 트랜잭션 관리: ACID 속성, 트랜잭션 처리 및 관리.
• 데이터베이스 관리 시스템(DBMS): DBMS의 기본 개념, 종류, 사용법.

(3) 준비 방법

1. 기본적인 SQL 문법 학습

   • SQL의 기본적인 문법을 철저히 이해하고 연습해야 합니다. 실습을 통해 각 SQL 명령어를 활용할 수 있는 능력을 기르는 것이 중요합니다. SELECT 문을 이용해 데이터 조회, JOIN을 이용한 다중 테이블 연산 등을 충분히 연습하세요.

2. 관계형 데이터베이스 이해

   • ERD 설계: 데이터베이스를 설계할 때 중요한 엔터티, 속성, 관계를 이해해야 합니다. 기본적인 정규화와 관계형 모델링을 학습하세요.
   • 정규화: 1NF, 2NF, 3NF에 대해 이해하고 실제로 이를 적용하는 연습을 해보세요.

3. 실습을 통한 SQL 활용 능력 강화

   • SQL을 이론만으로 학습하지 말고, 실제로 MySQL, PostgreSQL 또는 Oracle 등 DBMS에서 SQL을 실행하며 실습을 진행하세요. 다양한 데이터베이스와 상호작용하면서 문제 해결 능력을 키울 수 있습니다.

4. 성능 최적화 학습

   • SQL 쿼리의 성능을 최적화하는 방법을 공부하세요. 인덱스의 사용, 서브쿼리 최적화, 조인 방식에 따른 성능 차이 등을 이해하고, 실제 환경에서 이를 적용하는 방법을 학습하세요.

5. 이론과 실습 병행

   • 이론 공부와 실습을 병행하면서 문제 해결 능력을 키워야 합니다. SQLD 시험에서는 이론적인 부분뿐만 아니라 실무에서 겪을 수 있는 다양한 시나리오를 다루기 때문에, 기본 문제 풀이와 함께 실전 연습을 충분히 해야 합니다.

공부 방법과 팁

1. 공식 교재와 참고서 활용

   • SQLD 자격증을 준비할 때는 공식 교재를 활용하는 것이 좋습니다. 교재에는 시험에 나오는 기본적인 내용들이 포함되어 있으며, 실제 기출 문제를 통해 시험의 스타일을 익힐 수 있습니다.
   • SQLD 관련 서적이나 온라인 강의도 활용하면 도움이 됩니다.

2. 문제 풀이 및 모의 시험

   • 기출 문제나 모의 시험을 풀어보세요. 실제 시험에 나오는 문제 유형을 파악하고, 시간 관리 능력을 키울 수 있습니다.
   • SQL 문제는 실습을 통해 연습하는 것이 중요하므로, DBMS에 접속하여 쿼리 문제를 풀어보며 실력을 점검하세요.

3. 온라인 커뮤니티와 포럼 활용

   • SQLD 자격증 준비를 하면서 온라인 커뮤니티나 포럼을 활용하여 다른 사람들과 정보 교류를 하는 것도 유익합니다. 실무에서 겪은 다양한 SQL 관련 문제를 해결하고 서로 질문하고 답변하는 과정이 큰 도움이 됩니다.

4. SQL 실습 환경 구축

   • 시험 준비를 할 때는 반드시 DBMS 환경을 구축하여 실습해보세요. MySQL, PostgreSQL, Oracle 등 다양한 DBMS에서 SQL을 실행해보며 각 시스템의 차이점을 이해하고 SQL 실력을 높일 수 있습니다.

결론

SQLD 자격증은 데이터베이스에 대한 기본적인 이해와 SQL 활용 능력을 증명할 수 있는 중요한 자격증입니다. 2025년 SQLD 시험 일정에 맞춰 체계적으로 준비하면 좋은 결과를 얻을 수 있을 것입니다. 기본적인 이론을 탄탄히 하고 실습을 충분히 하며, 문제 해결 능력을 키워 시험에 임하세요. 좋은 결과가 있기를 바랍니다!

2025년 리눅스마스터 자격증 시험일정과 준비 방법

리눅스 마스터 자격증은 한국정보통신자격협회(KAIT)에서 주관하는 자격증으로, 리눅스 운영체제에 대한 지식과 활용 능력을 평가합니다. 1급과 2급으로 나뉘어져 있으며, 각 급수마다 1차와 2차 시험으로 구성됩니다.

급수별 특징

• 1급: 리눅스 시스템의 관리 능력에 중점을 두어 평가합니다.
• 2급: 리눅스 시스템의 사용 능력에 중점을 두어 평가합니다.

1급 시험 과목

1차:

• 리눅스 실무의 이해: 리눅스 개요, 시스템 이해, 네트워크 이해
• 리눅스 시스템 관리: 일반 운영 관리, 장치 관리, 시스템 보안 및 관리
• 네트워크 및 서비스 활용: 네트워크 서비스, 네트워크 보안

2차:

• 필기: 리눅스 시스템 관리 및 활용에 대한 단답형 및 서술형 문제
• 실기: 리눅스 시스템 운영 및 관리 작업 수행

2급 시험 과목

1차/2차 공통

• 리눅스 일반: 리눅스 이해, 설치, 기본 명령어
• 리눅스 운영 및 관리: 파일 시스템, Shell, 프로세스, 에디터, 소프트웨어 설치, 장치 설정
• 리눅스 활용: X 윈도, 인터넷 활용, 응용 분야

합격 기준

• 각 차수별로 평균 60점 이상을 획득해야 합니다.
• 1급의 경우, 1차 시험 과목 중 어느 하나라도 40점 미만을 받으면 과락으로 불합격 처리됩니다.
• 2급의 경우, 2차 시험 과목 중 어느 하나라도 40점 미만을 받으면 과락으로 불합격 처리됩니다.

응시 방법

한국정보통신자격협회 웹사이트 (www.ihd.or.kr)를 통해 시험 접수를 진행할 수 있습니다.

2025년 리눅스마스터 자격증 시험 일정

2025년 리눅스마스터 자격증 시험 일정은 아래와 같습니다. 시험을 준비하려면 각 회차의 접수 기간과 시험일을 확인하고 미리 계획을 세워야 합니다.

리눅스마스터 1급

리눅스마스터 1급은 리눅스 시스템의 고급 관리 능력과 이론적인 지식을 평가하는 자격증입니다. 1차 시험과 2차 시험으로 나뉩니다.

리눅스마스터 2급

리눅스마스터 2급은 리눅스의 기본적인 관리 능력과 실무 지식을 평가합니다. 1차 시험은 기본적인 리눅스 명령어와 설정, 2차 시험은 좀 더 실습적인 내용을 다룹니다.

시험 준비, 공부 방법과 팁

1. 교재 선정 및 학습 계획 수립
   • 공인 교재 선정: 인증된 교재를 선택하여 기본 개념 및 실습 위주로 학습합니다.
   • 학습 일정 계획: 시험일까지의 남은 시간을 고려하여 주간 및 월간 학습 계획을 세웁니다.
2. 기본 개념 이해
   • 리눅스의 구조와 작동 원리 이해
   • 파일 시스템 관리, 사용자 관리, 네트워크 설정 등 기본 개념 숙지
3. 실습 위주의 학습
   • 가상 머신 또는 실제 리눅스 환경 구축 후 명령어 및 설정 실습
   • 자주 출제되는 명령어와 스크립트 작성 연습
4. 기출 문제 풀이
   • 과거 기출 문제 분석 및 풀이를 통해 시험 유형 파악
   • 시간 관리 연습을 위해 실제 시험 시간에 맞춰 모의고사 실시

웹 개발자의 KPI(Key Performance Indicator)는 개인의 업무 성과와 팀 목표를 측정하는 데 도움이 됩니다.
아래는 일반적인 주니어 웹 개발자를 위한 KPI 항목입니다:

1. 코드 품질 및 생산성
   • 코드 리뷰 피드백 반영률: 코드 리뷰에서 지적된 사항을 얼마나 잘 반영했는지.
   • 주간/월간 코드 기여도: 작성한 코드의 라인 수보다는 기능의 완성도와 기여도를 평가.
   • 버그 발생률: 작성한 코드에서 발견된 버그의 수.
   • 테스트 커버리지 향상: 테스트 작성 여부와 코드 커버리지 증가율.

2. 프로젝트 완료 및 기여
   • 기한 준수율: 맡은 작업이나 프로젝트를 제때 완료한 비율.
   • 작업 완료 건수: 주어진 업무(예: Jira 티켓, Git 이슈) 처리 수량.
   • 기능 구현의 정확성: 요구사항을 충족하며 기능을 개발한 정도.

3. 학습 및 성장
   • 새로운 기술 습득: 업무와 관련된 새로운 기술, 프레임워크, 툴을 학습한 정도.
   • 교육 참여: 팀 내 세미나, 워크숍 또는 외부 교육 프로그램 참여율.
   • 지식 공유: 팀원들에게 학습한 내용을 공유하거나, 문서화한 빈도.

4. 협업 및 커뮤니케이션
   • 커뮤니케이션 명확성: 팀원 및 이해관계자와 명확히 소통하는 능력.
   • 팀워크 기여도: 코드 리뷰 참여, 동료와의 협업 빈도 및 품질.
   • 이슈 해결 참여: 문제를 발견하고 해결하는 데 기여한 빈도.

5. 운영 및 유지보수
   • 배포 안정성: 개발한 코드가 운영 환경에서 문제 없이 배포된 비율.
   • 긴급 문제 해결 기여: 운영 환경에서 발생한 문제를 얼마나 효과적으로 지원했는지.
   • 기존 코드 개선: 리팩토링, 성능 최적화 등 기존 코드에 대한 기여.

6. 사용자 중심 개발
   • 사용자 피드백 반영률: 사용자 요구사항을 코드에 잘 반영했는지.
   • UX/UI 향상 기여도: 사용자 경험과 인터페이스 개선 기여.

KPI 예시

주니어 개발자 KPI 설정 팁

1. 구체적이고 측정 가능하게: 모호한 목표 대신 측정 가능한 목표로 설정.
2. 성과와 성장의 균형: 단순히 업무량뿐 아니라, 개인의 성장과 학습도 포함.
3. 주기적인 리뷰: 분기별 또는 월간으로 KPI를 점검하여 조정.
4. 팀과 회사 목표 연계: 개인 목표가 팀 및 회사 목표와 맞물리도록 설정.

😊

PostgreSQL AccessShareLock 이해 및 해제 가이드

AccessShareLock이란?

• Oracle의 TM LOCK과 유사: 데이터를 읽는 동안(SELECT) 테이블 구조 변경을 막기 위해 걸리는 락입니다.
• 성능에 미치는 영향: 일반적으로 성능 저하를 유발하지 않지만, 테이블 구조 변경 작업 시 방해가 될 수 있습니다.
• PostgreSQL에서의 역할: 데이터의 일관성 유지에 기여합니다.

Lock 조회 및 해제

1. Lock 조회:

SELECT  t.relname,
        l.locktype,
        page,
        virtualtransaction,
        pid,
        mode,
        granted
FROM pg_locks l,
     pg_stat_all_tables t
WHERE l.relation = t.relid
ORDER BY relation ASC;

• relname: 락이 걸린 테이블 이름
• locktype: 락 종류 (AccessShareLock 등)
• pid: 프로세스 ID
• mode: 락 모드

2. Lock 해제:

• 단일 프로세스 종료:

  SELECT pg_cancel_backend(PID);

  • 해당 PID의 프로세스만 종료합니다.
• 상위 쿼리까지 종료:

  SELECT pg_terminate_backend(PID) FROM pg_stat_activity;

  • PID와 관련된 모든 상위 쿼리까지 종료합니다.

3. 실행 중인 쿼리 상태 조회:

select * from pg_stat_activity;

주의 사항

• pg_terminate_backend는 강제 종료이므로 데이터 손실 가능성이 있습니다. 신중하게 사용해야 합니다.
• 락 해제 전 반드시 원인을 파악하고 해결하는 것이 좋습니다. 락이 자주 발생하는 경우, 쿼리 최적화나 데이터베이스 설정 변경이 필요할 수 있습니다.

요약

PostgreSQL의 AccessShareLock은 데이터 일관성을 위해 필요한 락입니다. 일반적으로 문제가 되지 않지만, 테이블 구조 변경 등 특정 상황에서 방해가 될 수 있습니다. 위의 SQL 쿼리를 사용하여 Lock을 조회하고 해제할 수 있으며, pg_terminate_backend를 사용할 때는 주의가 필요합니다.

더 자세한 정보는 PostgreSQL 공식 문서를 참고하세요.

핵심:

• AccessShareLock은 SELECT 시 걸리는 락으로, 일반적으로 성능에 영향을 주지 않습니다.
• Lock을 조회하고 해제하는 방법을 알아두면 문제 해결에 도움이 됩니다.
• pg_terminate_backend는 강력한 명령어이므로 신중하게 사용해야 합니다.

array_agg is an aggregate function 에러는 pg_get_functiondef가 aggregate 함수나 window 함수에 대해서 동작하지 않을 때 발생할 수 있습니다. 이 문제를 해결하려면 함수 정의를 얻는 다른 방법을 사용하거나, pg_proc에서 특정 조건을 추가로 설정해줘야 할 수 있습니다.

아래는 이 문제를 해결할 수 있는 개선된 쿼리입니다:

1. Aggregate 및 Window 함수 제외:

PostgreSQL에서는 집계 함수와 일반 함수가 모두 pg_proc에 저장되지만, 집계 함수와 window 함수는 pg_get_functiondef로 정의를 조회할 수 없습니다. 이를 필터링하려면 proisagg와 proiswindow 컬럼을 활용할 수 있습니다.

SELECT
    n.nspname AS schema_name,
    p.proname AS function_name,
    pg_get_functiondef(p.oid) AS function_definition
FROM
    pg_proc p
JOIN
    pg_namespace n ON p.pronamespace = n.oid
WHERE
    NOT p.proisagg -- 집계 함수가 아닌 것
    AND NOT p.proiswindow -- 윈도우 함수가 아닌 것
    AND pg_get_functiondef(p.oid) LIKE '%검색할_문자열%';

2. PostgreSQL 11 이상 (prokind 사용):

PostgreSQL 11 이상에서는 pg_proc에 prokind 컬럼이 추가되어, 함수 유형을 더 쉽게 필터링할 수 있습니다. prokind = 'f'는 일반 함수를 의미합니다.

SELECT
    n.nspname AS schema_name,
    p.proname AS function_name,
    pg_get_functiondef(p.oid) AS function_definition
FROM
    pg_proc p
JOIN
    pg_namespace n ON p.pronamespace = n.oid
WHERE
    p.prokind = 'f' -- 일반 함수만 선택
    AND pg_get_functiondef(p.oid) LIKE '%검색할_문자열%';

3. 특정 스키마에 대해서만 검색 (옵션):

SELECT
    n.nspname AS schema_name,
    p.proname AS function_name,
    pg_get_functiondef(p.oid) AS function_definition
FROM
    pg_proc p
JOIN
    pg_namespace n ON p.pronamespace = n.oid
WHERE
    p.prokind = 'f'
    AND n.nspname = '특정_스키마명'
    AND pg_get_functiondef(p.oid) LIKE '%검색할_문자열%';

위 쿼리 중 하나를 사용하면 pg_get_functiondef에서 발생하는 문제를 방지하고, 함수 정의를 성공적으로 검색할 수 있을 것입니다.

회사와 개인프로젝트의 계정을 분리한다던지, 개인 프로젝트와 스터디 그룹의 계정을 분리한다던지 한 컴퓨터에서 여러 Github 계정을 사용해야 할 경우가 있다. SSH를 활용하여 관리하는 방법을 사용하면 편하다.

기존에 ssh 키가 있는지 확인

  ls -al ~/.ssh

ssh 키를 생성 및 agent 등록

  # 2개의 키 생성하기
  ssh-keygen -t rsa -C "{private}@mail.com" -f "~/.ssh/{rsa file for private}"
  ssh-keygen -t rsa -C "{group}@mail.com" -f "~/.ssh/{rsa file for group}"

  # 키 생성 확인
  ls -al ~/.ssh

  # ssh-agent 실행 확인
  eval "$(ssh-agent -s)"

  # 생성한 키 등록
  ssh-add ~/.ssh/{rsa file for private}
  ssh-add ~/.ssh/{rsa file for group}

  # 등록한 키 확인
  ssh-add -l
  4096 SHA256:... {private}@mail.com (RSA)
  4096 SHA256:... {group}@mail.com (RSA)

ssh 설정 파일 수정

ssh 설정 파일은 ~/.ssh/config이다. 파일이 존재하지 않는다면 생성 후 진행한다.

  # 파일 존재 여부 확인
  cat ~/.ssh/config

  # 파일 생성
  touch ~/.ssh/config

  # 파일 수정
  vi ~/.ssh/config

  # IDLOOK
  Host github.com-{group_name}
    HostName github.com    
    User {group_github_name}
    IdentityFile ~/.ssh/{rsa file for group}

  # PRIVATE
  Host github.com-{private_name}
    HostName github.com
    User {private_github_name}
    IdentityFile ~/.ssh/{rsa file for private}

git 설정파일 수정

git user name과 user email 설정 파일을 각각 생성 수정한다

  touch ~/.gitconfig-{private}
  touch ~/.gitconfig-{group}

개인용

  vi ~/.gitconfig-{private}

  [user]
    name = {private_github_name}
    email = {private}@mail.com

업무용

  vi ~/.gitconfig-{group}

  [user]
    name = {group_github_name}
    email = {group}@mail.com

git 설정 파일에서 해당 파일을 읽어오도록 한다

  vi ~/.gitconfig

  [includeIf "gitdir:{개인 프로젝트 경로}"]
    path = .gitconfig-{private}
  [includeIf "gitdir:{그룹 프로젝트 경로}"]
    path = .gitconfig-{group}

Github 계정에 SSH 키를 등록

생성한 ssh 키를 각각 두개의 github 계정에 등록해준다.

우측 상단 Github Profile > Settings > 좌측 SSH and GPG keys > 우측상단 New SSH Key
타이틀은 편하게, Key type은 Authentication Key, Key 부분에 생성한 키를 복사해서 붙여 넣는다.

  # shell에서 명령어로 복사하는 방법
  pbcopy < ~/.ssh/{rsa file for private}

  # shell에서 명령어로 출력한 후 terminal에서 복사하는 방법
  cat ~/.ssh/{rsa file for private}

Github 등록 확인

  ssh -T git@github.com-{private_name}

로컬로 Github 레포지토리 복사

복사시 https가 아닌 ssh로 한다

  git clone git@github.com-{private_name}:{user-name}/{repository-name}.git

로컬이 이미 레포지토리가 있을 경우 주소 변경

  # 기존 리모트 url 확인
  git config --get remote.origin.url
  git@github.com:{A}/{B}.git
  # 리모트 url 변경
  git remote set-url origin git@github.com-{private_name}:{A}/{B}.git

  # 동작 확인
  git pull

clone, pull등 git 명령어 결과에서 에러가 나올 경우 ssh를 디버깅 모드로 시도

  GIT_SSH_COMMAND="ssh -v" git fetch

DL;DR

모든 내용은 git manual에 있다.https://git-scm.com/docs/git-config#_conditional_includes

참고

• https://git-scm.com/docs/git-config#_includes
• https://git-scm.com/docs/git-config#_conditional_includes
• https://www.lesstif.com/gitbook/git-ssh-verbose-mode-125305437.html

1. 테스트 프로세스

테스트 프로세스는 테스트와 관련된 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 모든 구성요소를 엮어주는 역할을 함.

테스트 프로세스 5 단계

  계획/제어 -> 분석/설계 -> 구현/실행 -> 완료/리포팅 -> 마감

테스트 프로세스는 계획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 5단계로 구성.

1. 계획과 제어 :
   테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 확인하고 필요한 활동을 정의.
   테스트 제어는 계획 대비 실제 신행 상황을 비교하는 지속적인 활동.
2. 분석과 설계 :
   테스트 분석과 설계는 일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환.
3. 구현과 실행 :
   테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트스를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시져를 명세화.
4. 완료 조건과 리포팅 :
   초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가.
5. 테스트 마감 :
   완료된 테스트에서 발견된 사실 및 수집된 데이터, 경험을 취합하고 축적.

2. TC 작성 절차

  문서 수집 -> TC 작성 -> 내부 검토 -> 커버리지 분석 -> 승인

1. 참조 문서 수집 :
   테스트 계획서에 명시된 테스트 케이스 작성 지침과 수준을 고려,
   테스트 설계에 필요한 분석 및 설계 문서 수집.
2. TC 작성 :
   테스트 설계 기법을 이용하여 TC를 작성.
3. 내부 검토 :
   PM, 아키텍트, 디자이너, 기획자, 개발자, QA 담당자가 작성된 TC의 적정성 검토.
4. 요구사항 대비 커버리지 분석 :
   TC가 어느 정도 요구사항을 반영하는가에 대한 분석.
   기본적으로 테스트 가능한 요구사항은 모두 TC에 반영되어있는지 확인.
5. 승인 :
   작성된 TC를 클라이언트(현업), 기획자 및 PM에게 승인을 받음.

3. TC 구성요소

• 식별 번호 :
  TC의 고유 식별자.
• 이슈 번호, 제목 :
  제목과 이슈 번호를 기입. (Redmine NO., Jira NO.)
• 요약 (Description) :
  TC의 목표 등 요약된 정보
• 사전 조건 (Precondition) :
  테스트 수행에 필요한 조건 및 실행환경. (선행 조건, 전제조건)
• 종속성 (Dependencies) :
  테스트 요구사항 또는 기타 TC에 대한 의존성 판단.
• 수행 절차 (Test Step) :
  TC를 수행하기 위한 정확한 단계.
• 기대 결과 (Expect Result) :
  절차대로 진행 시 테스트 통과 여부를 결정하는 기대 결과.
• 실제 결과 (Actual Result, PASS / FAIL) :
  테스트 수행 후 실제 결과.
• 비고 (Remark, Note, Comment) :
  기타 비고 사항을 기입.
• 그 외 :
  우선순위, 모듈 이름, 테스트 설계자, 설계일, 테스트 수행자, 수행일 등

구성 요소는 조직이나 프로젝트에 따라 변경/추가/삭제 될 수 있다.

4. TC 작성 시 주의 점 및 장/단점

주의점

• 절차의 누락 :
  테스트 절차를 정확하게 입력하지 않을 경우 테스트 수행의 어려움이 생기는 테이스 발생 가능.
• 장황한 설명 :
  TC 작성 시 상세하고 충분한 정보를 제공해야 하지만, 너무 많은 단어와 불필요한 설명으로 소통의 오류 유발 가능.
• 전문 용어의 과다 사용 :
  TC 작성 시, 직군간 소통이 불가능한 전문용어를 과다사용시 테스트 수행에 어려움이 있을 수 있음.
• 분명하지 않은 PASS/FAIL 기준 :
  테스트 수행 후 테스트 결과가 통과인지 실패인지 예상 결과에 정확히 기입하지 않아 결과 판단에 어려움 유발 가능.

단점

• TC 작성 시간이 수행 시간보다 오래 걸릴 수 있음.
• 기능 변화에 따른 TC 변경 :
  기능을 자주 변경한다면 추후 테스트 케이스의 통제에 어려움이 생기게 될 수 있음.
• 배경 지식 판단의 어려움 :
  TC를 작성하는 사람은 테스트 하는 기능을 잘 알고 있으나, 테스트 수행자는 배경 지식이 없을 경우 테스트 수행 시간이 길어지거나 수행에 어려움이 있을 수 있음.

장점

• 이력 참조 :
  TC는 어플리케이션 런칭 후에도 사용, 유지보수 팀과 추후 어플리케이션의 버전을 담당자의 테스트 이력 참고가 가능.
• 테스트 진행 상황 추적 :
  TC를 문서화 하면 수행한 TC의 수, 통과/실패 수, 과업 범위 별 케이스 수, 테스트 커버리지 등의 정보를 추적/확인 가능.
• 반복성 :
  잘 작성된 TC는 누구나 반복적으로 수행 가능.

5. TC 정렬

TC의 정렬은 업부의 효율과 연결될 수 있다. 테스트의 흐름, 테스트 환경 등을 고려해서 정렬 하도록 하자.

흐름이 이어지는 TC 정렬

환경이 비슷한 TC 정렬