회사 내부에서 프로젝트 및 개발 관리 툴을 도입하고자 했다. 이전부터 노션으로 고객사와 협업 및 파트관리를 해왔었는데, 이를 보고 센터교육을 지시 해서 교육을 진행하게 됐다.

1️⃣ 내가 노션을 사용하게 된 이유

내가 노션을 도입하게 된 이유는 단순히 ‘문서화’ 때문이 아니었다. 프로젝트 운영 과정에서 반복되는 비효율과 혼선을 근본적으로 해결하고 싶었다.

매번 느꼈던 문제는 세 가지였다.

💥 Pain Point 1. 고객사 커뮤니케이션 누락으로 인한 설계 혼선

• 비즈니스 로직 변경 사항이 문서로 정리되지 않음
• 구두 전달이 많아 개발 과정에서 맥락이 단절
• 결과적으로 재작업과 일정 지연 발생

✅ Solution: 회의록 기반의 협업 및 히스토리 관리 노션 데이터베이스를 중심으로 회의 내용을 실시간 기록하고 논의된 결정과 변경사항을 히스토리로 남겨 “설계의 맥락”을 보존했다. 모든 팀원이 같은 문서를 보며 일하니, 더 이상 “누가 최신 버전이냐”는 말이 사라졌다.

💥 Pain Point 2. 개발·배포 표준 컨벤션 관리의 어려움

• 개발자마다 코드 스타일, 네이밍, 배포 방식이 달랐음
• 표준이 없어 산출물의 일관성이 떨어지고 유지보수 부담이 증가

✅ Solution: 개발 컨벤션 및 산출물 아카이빙 노션에 표준화된 개발 문서 템플릿을 만들어 명명규칙, 코드 스타일, 배포 방식까지 체계적으로 관리했다. 이후 산출물을 아카이빙하여 재사용성을 높이고 새 프로젝트에서도 바로 참고할 수 있도록 했다.

💥 Pain Point 3. 프로젝트 진행 현황의 가시성 부족

• 개발 일정, QA 이슈, 담당자별 진행률이 한눈에 안 보임
• 실시간 파악이 어렵고, 일정 관리에 차질 발생

✅ Solution: QA·진행 현황의 시각화 및 자동 관리 노션 데이터베이스를 기반으로 보드, 차트, 타임라인 뷰를 구성했다. QA 요청부터 개발 진행 단계까지 한 화면에서 관리할 수 있었고, 태그와 상태 자동화로 “어디까지 진행됐는가?”를 즉시 확인할 수 있었다.

2️⃣ 노션 접목 — 직급별 As-Is / To-Be 워크플로우 변화

노션을 단순한 툴이 아닌 팀의 운영 체계로 바라봤을 때, 각 직급별로 일하는 방식이 완전히 달라졌다.

👨‍💼 관리자(파트장 이상급)

📈 관리자 입장에서는 커뮤니케이션 비용이 줄고, 전체 프로젝트의 진행 상황을 한눈에 파악할 수 있게 됐다.

👨‍💻 개발자(연구원~선임급)

⚙️ 개발자는 “보고”가 아닌 “기록”으로 자신의 업무를 남기며, 모든 업무가 자동으로 추적되고 관리된다.

🧑‍💼 고객사 PM / 현업

💬 고객사는 개발팀의 진행 상황을 실시간으로 가시화할 수 있었고, ERP와 현업 간의 간극이 현저히 줄어들었다.

결론

노션은 단순한 메모 툴이 아니라, “팀의 일하는 문화를 바꾸는 시스템”.

기획부터 QA까지의 모든 흐름을 문서와 데이터로 연결하고, 각자의 워크플로우를 노션이라는 한 공간에서 통합했을 때 프로젝트의 속도와 품질이 모두 올라갔다.

1. MVP
2. 내부 QA, 테스트 출시
3. 앱 배포
4. 웹, 앱 출시

🧭 마일스톤

⏱️ 프로젝트 종료 목표일 : 9월 26일

1️⃣ MVP

⏱️ 일정 : 1차MVP 8월 28일, 2차MVP 9월 2일 🔥 목표 : 핵심플로우 완성 ✚ 기본적인 사용자 경험 제공

🚀 Task 1️⃣ : 1차MVP

1. 게시글상세페이지 - 마감기능, 투표기능, 댓글기능
2. 마이페이지 - 제작, 참여 게시글 조회
3. 메인페이지 - 공개 게시글 조회
4. 투표제작페이지 - 이미지업로드 기능, 게시글생성기능
5. 투표확대페이지 - 투표사진확대
6. 온보딩페이지
7. 스플래시페이지
8. 투표수정페이지 - 투표수정기능 💡 2차 MVP는 완성도 ⭐️⭐️⭐️⭐️⭐️

🚀 Task 2️⃣ : 2차MVP

1. 알림페이지 - 알림 기능
2. 설정페이지 - 알람설정, 회원탈퇴, 로그아웃 기능
3. 코치마크페이지 - 사용자온보딩수행 확인
4. 내정보변경페이지 - 개인정보변경 기능
5. 이용약관,개인정보처리방침페이지 💡 2차 MVP는 완성도 ⭐️

2️⃣ 내부 QA ✚ 베타테스트

⏱️ 일정 : 9월 7일 🔥 목표 : 안정성확보 ✚ 사용자피드백 수집

🚀 Task 1️⃣ : 내부 QA

1. QA(버그, 핵심플로우 검증)

   🚀 Task 2️⃣ : 사용자 테스트

2. 뽀또픽 테스터 재방문 및 심층 인터뷰(5인)
3. 원격으로 테스트 사용 권유 및 설문(20명)
4. 테스트 결과 취합 및 보완사항 도출(5가지)

3️⃣ 앱 배포

⏱️ 일정 : 9월 10일 🔥 목표 : 스토어 등록(심사대기) ✚ 초기배포 안정화

🚀 Task 1️⃣ : 안드로이드 / IOS 배포 프로세스 확인

1. Android/iOS등록(스토어 필수 항목 최소화)
2. 스토어 이미지/설명(ASO기본)

   🚀 Task 2️⃣ : 앱 기능 테스트

3. 안정성 모니터링
4. 쌓여 있는 이슈 트래킹 및 수정 작업

4️⃣ 웹, 앱 출시

⏱️ 일정 : 9월 26일 🔥 목표 : 데이터기반 개선 사이클 시작 ✚ 서비스 안정화

🚀 Task 1️⃣ : 웹서비스 분석 툴

1. 분석툴 1, 2개 연결
2. 서비스 목표 달성 지표 데이터 확인, 리뷰(KPI)

   🚀 Task 2️⃣ : 서비스 홍보

3. 웹서비스 홍보용 SNS 개설 및 콘텐츠 생성
4. 서비스 홍보자료 제작 및 커뮤니티 배포

   🚀 Task 3️⃣ : 운영 개선

5. 기술개선, 비즈니스 개선 항목 정리

✔️ 참고 - KPI 예시

구분	지표 예시	기준선(목표)	문제	긍정
유입	신규 방문자 수	X명/주	전주 대비 -20% 이상 감소	안정적 유지 또는 증가
전환	회원가입 전환율	≥ 25%	15% 이하	30% 이상
행동	투표 생성 수	X건/주	급감	꾸준한 증가
리텐션	D1/D7 재방문율	D1 ≥ 35%, D7 ≥ 15%	D1 < 20%	목표 초과 유지
참여	평균 투표 참여 수	≥ 5명/투표	2명 이하	목표 이상
품질	오류율	< 1%	지속 증가	0.5% 이하 유지

✔️ 주요지표

• 전환율 : 유입 이후, 회원가입/투표 생성 ▶︎ UX 문제
• 리텐션 : 콘텐츠 확대 알림, 재참여 유도 ▶︎ 기획, UX 문제
• 참여율 : 투표 참여 분석 ▶︎ 유입과 홍보
• 오류율 : 앱 신뢰도 관리 ▶︎ 개발 문제

✨ 서비스 개요

CHOOZ는 사용자가 여러 장의 사진 중 "SNS에 어떤 사진을 올릴지 고민될 때" 도움을 받기 위해 만든 사진 기반 투표 SNS 서비스입니다. 사진 업로드와 투표 생성, 실시간 결과 확인, 댓글 참여, 공유 등 다양한 API를 서버에서 제공합니다.

✅ RESTful API 설계 전략

1. 도메인 중심의 리소스 설계

• 모든 API 엔드포인트는 도메인 개념(Post, Comment, Notification, User 등)을 중심으로 나뉘었습니다.
• /api/posts, /api/users/me, /api/notifications 등 리소스 경로 유지

2. HTTP Method의 역할 분리

• GET: 조회
• POST: 생성/액션 트리거
• PUT: 전체 수정
• PATCH:일부 수정
• DELETE: 삭제

예시: /api/users/me/device-tokens 하나의 엔드포인트에서

• POST로 등록
• DELETE로 해제

3. 리소스 계층 구조 표현

• /posts/{postId}/comments, /posts/{postId}/choices와 같이 하위 리소스를 명확하게 표현하여 의미 전달력 강화

4. Query Parameter 활용 최적화

• 페이징, 정렬, 필터 조건은 모두 Query로 처리

  • /api/posts?cursor=...&size=10
  • /api/posts/{postId}/comments?page=0&size=5

• 캐싱과 브라우저 히스토리를 위해 같은 url에서 조건만 바뀌는 조회일 경우, 쿼리파라미터 적극적 활용

5. me 표현 도입

• 사용자 ID를 알지 않고도 클라이언트에서 내 정보 처리 가능

6. 공개범위에 따른 설계 분기

• /posts/{id}: 공개 또는 내 게시물만 접근 가능
• /posts/share/{token}: 난수 기반 공유 링크 접근 전용
• 서버에서는 항상 권한 검증(토큰 또는 작성자 여부)

7. 푸시알림은 비동기 내부 트리거로 처리

• 투표, 댓글 등의 이벤트 발생 시 서버 내부에서 알림 발송
• REST API는 디바이스 등록, 알림 설정만 제공하고, 실제 발송은 로직에 내재화

8. 확장 가능한 전략 패턴 구조 도입

• /users/me/posts?type=created 등 쿼리 기반 분기는 전략 패턴으로 처리
• switch-case가 아닌 ~Strategy 인터페이스로 각 타입을 유연하게 분리 → OCP

🔐 보안 설계 원칙 적용 사례

✅ /users/me vs /users/{userId} 명확한 분리

• /users/me: 민감 정보 포함 가능 (이메일, 알림 설정 등)
• /users/{userId}: 프로필만 공개, 다른 유저 정보는 권한 제한 필수

🔍 이유 및 장점

/me는 JWT 기반 사용자 판별이 확정적이므로 실수 가능성이 거의 없음 /users/{userId}는 보안 실수로 인해 다른 사용자의 정보가 노출될 수 있음(권한체크로직 필수) 공개된 프로필 게시물 조회시에만, {userId}로 접근.

예시 문제

//내정보조회
@putMapping("/users/{userId}") 
public UserInfo getUser(@PathVariable Long userId) {
    return userRepository.findById(userId); // 권한 체크 빠짐
}

필수사항

• /me는 민감 정보 전용(내정보조회 및 수정)
• /users/{id}는 공개 정보 전용(상대프로필 조회)
• 프론트엔드는 두 경로를 명확히 구분해 사용

🔬 고려한 RESTful 설계

1. 자원 중심(Resource-Oriented)
   • 모든 기능은 도메인 단위 리소스로 분리됨
2. HTTP 명세 준수
   • 메서드 별 역할 구분 (GET, POST, DELETE, PUT)
3. URI의 일관성과 명확성
   • /posts/{id} vs /posts/share/{token} 구분 명확
4. 무상태성(Stateless)
   • JWT 토큰으로 인증, 요청마다 독립 처리
5. 클라이언트-서버 분리
   • 프론트는 상태만 관리, 백엔드는 명확한 API 응답 설계
6. 캐시 가능성
   • GET 요청 중심의 리스트 조회는 캐싱 가능성 고려함

✨ 마무리

CHOOZ의 API는 단순한 CRUD 설계가 아닌, 도메인 구조에 기반한 명확하고 RESTful한 설계 전략을 만드는 것이 목표. 유지보수성, 확장성, 사용자경험과 관련된 효율적인 API설계 필요.

웹 개발 입문자도 따라할 수 있는 웹이력서 만들기

🚀 목표

• Next.js + TypeScript로 웹 이력서 프로젝트 만들기
• Tailwind CSS로 디자인 적용
• GitHub에 코드 업로드
• Vercel에 무료로 배포하기

🧱 1단계: 개발 환경 준비

🔧 필수 설치 항목

• Node.js (최소 v18 이상 권장)
• 코드 에디터: Visual Studio Code 또는 IntelliJ

✅ Node.js 설치 확인

터미널 또는 명령 프롬프트에서 아래 명령어 입력:

node -v
npm -v

문제 없이 버전이 출력되면 설치 완료!

⚙️ 2단계: Next.js 프로젝트 생성

npx create-next-app@latest resume --ts

설정 질문이 나오면 이렇게 답변하세요:

💡 참고: Turbopack은 최신 번들러지만 불안정하다. 문제가 생기면 --turbo=false 옵션을 추가하여 Webpack으로 실행!

📁 3단계: 프로젝트 구조 이해

resume/
├── src/
│   ├── app/            # 페이지 구조 (App Router)
│   ├── components/     # 재사용 컴포넌트 보관
│   └── styles/         # 전역 CSS (globals.css)
├── public/             # 이미지 등 정적 파일
├── tailwind.config.js  # Tailwind 설정
├── postcss.config.js   # PostCSS 설정
├── tsconfig.json       # TypeScript 설정
└── package.json        # 프로젝트 메타 정보

🎨 4단계: TailwindCSS 적용 확인 및 설정

1. globals.css 수정 (src/app/globals.css)

@tailwind;

:root {
  --background: #ffffff;
  --foreground: #171717;
}

body {
  background: var(--background);
  color: var(--foreground);
  font-family: Arial, Helvetica, sans-serif;
}

2. tailwind.config.js

module.exports = {
  content: [
    './src/app/**/*.{js,ts,jsx,tsx}',
    './src/components/**/*.{js,ts,jsx,tsx}',
  ],
  theme: {
    extend: {
      colors: {
        primary: '#facc15',   // 노란색
        secondary: '#a855f7', // 보라색
      },
    },
  },
  plugins: [],
};

3. postcss.config.js

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

또는 Turbopack을 사용할 경우:

// postcss.config.mjs
const config = {
  plugins: ["@tailwindcss/postcss"],
};
export default config;

🧪 5단계: 개발 서버 실행

cd resume
npm install
npm run dev

브라우저에서 http://localhost:3000 접속

🌐 6단계: GitHub에 올리기

1. .gitignore 확인

.gitignore 파일에 다음 항목이 포함되어야 함:

node_modules/
.next/
dist/
.env

2. GitHub 연결 및 업로드

git init
git remote add origin https://github.com/your-username/resume.git
git add .
git commit -m "first commit"
git push -u origin main

❗ GitHub에서 레포지토리 먼저 생성

🚀 7단계: Vercel에 배포하기

1. vercel.com 접속

• GitHub 계정으로 로그인
• "Add New Project" → **resume** 선택 → Import
• 설정은 기본값 유지
• Environment Variables는 생략가능(지금은 필요 없음)
• Deploy 클릭!

2. 배포 완료 🎉

• https://your-project-name.vercel.app 주소 생성됨
• 이후 GitHub에 푸시만 해도 Vercel이 자동 재배포 💫

🎯 마무리

이제 웹 이력서 공개! 간단하게 프로젝트 생성 > 배포까지! 내용 채워서 웹 링크로 지원~ ㅎㅎ Next.js배우면서 spa 구조도 알아보면서 해봐야겠다!

⛳️Action Item

• Tailwind로 예쁘게 스타일링하기
• 섹션별 컴포넌트로 나누기 (프로필, 경력, 기술 스택 등)
• 도메인 연결하고 완성도 올리기

점선 네모 - 그룹 그룹하는 방법 command + g 그룹해지 방법 command + shift+ g 레이어 층의 개념 앞과 뒤 z축 그래서 순서에 따라 보이는 것이 다르다. 레이어 앞으로 가기 command + [ 레이어 뒤로 가기 command + ] 레이어 맨 앞, 뒤로 가기 command + option [, ] 요소 복제 option + drag

프레임

ui 작업을 위한 틀 하나의 화면을 구성하는 틀 단축키 f + freeset고르기 프레임 안에 프레임을 넣을 수도 있음

섹션

여러화면에 대한 프레임을 그룹화할 수도 있음 ex) 시안1, 2 shift + s option + 커서 이동하면 간격을 다 알아볼 수 있음 페이지 페이지는 여러개로 나눌 수 있다.

레이아웃, 그리드

웹 : 12단 그리드 모바일 : 4, 6단 그리드 column, gutter, margin grid : 작은요소 columns : 전체 레이아웃 shift + g : 레이아웃 그리드를 보였다 안보였다 할 수 있음

도형

appearance fill : 배경 컬러, 이미지 삽입, 비디오 삽입(미리보기 시) fit으로 하면 비율에 맞춰서 작악짐 crop : 잘라서 원하는 부분만 보여줄 수 있음 tile : 원본크기에 맞춰서 반복 remove background : 배경 없어짐 fill, stroke 안에서도 레이어를 조절 할 수 있음 line모양도 설정할 수 있음 effects inner shadow drop shadow background blur : 레이어를 활용해 블러처리 시키고 싶은 이미지를 뒤로 보냄, 투명도를 넣어줘야 함 text : 미래의 건강 산업, 개인 맞춤형 의료 layout에서 truncate text - inabled 처리 auto height로 변경하면 max lines 설정에 따라 ...표시가 됨 command + option + g 하면 프레임으로 묶여짐 command + option + c 하면 속성을 복사 할 수 있음 clip content radius 맞춰줌

팀 운영에서 소통하는데 어려움이 적었지만, 없던 것은 아니었다. 업무소통하고 트래킹 하는 것은 시스템 없이도 노력과 시간을 투자하면 충분히 가능하다. 하지만, 팀원 모두 주어진 시간과 에너지는 정해져 있기 때문에 결국 다른 부분에서 손해로 이어졌다. 개개인의 성향을 적극적으로 만들거나, 팀에 필요한 부분에 자발적으로 기여하게 하는 것은 불가능하다. 결국에는 협업하는데에 있어서 시스템을 만드는 것이 굉장히 중요하다는 생각을 했다.

📌 기록보관소(Archive)

📌 노션

• 기록보관용
• 실시간 협업 가능(생성, 편집)
• 데이터베이스(보드, 칸반, 캘린더 등 다양한 보기형식 지원)
• wiki형태로 변환 가능

  📌 프로젝트관리(Project Planning)

  📌 디스코드

• 회의, 업무대화용
• 프로젝트 논의 : 전체 채팅방
• 기술 논의 : 각 기술 분야 채팅방
• 스프린트(MVP) 논의 : 기획/디자인 채팅방

📌 트렐로

• 업무할당 및 진행상황 추적용
• 칸반형태의 업무 체크리스트
• 각 업무에 대해 전체적인 파악이 바로 가능
• 디스코드와 연동하여 대화하며 추가 및 수정 가능

📌 카카오 오픈채팅방 + 챗봇

• 일상대화용
• 디자인 및 개발을 하지 않는 순간에도 꾸준히 프로덕트 관련 정보 제공
• 그라운드룰, 정책 등과 관련된 내용을 미리 작성후 제공
• 이동 중에 가볍게 정보확인 가능한 용으로 사용

  📌 제품개발(Product Development)

  📌 피그마

• 서비스 컨셉
• 서비스 흐름
• UX리서치
• UI디자인
• 와이어프레임
• 프로토타입
• UT
• MVP기획
• 기능명세
• 🚨코멘트 달기 👉 회의 때 전 인원 점검 및 피드백🚨
• 🚨문서 작성 완료 👉 회의 때 전 인원 점검 및 피드백🚨

  📌 Git & Github

• 웹서비스 코드 개발 및 서비스 구현
• PR을 통해 개발 내역 confirm
• 워크플로우 작성
  • PR - Preview - dev - prd 시스템 구축

📌 기대하는 업무진행 플로우

1. 디스코드로 회의 및 업무대화 진행 sub(카카오 오픈채팅)
2. 트렐로로 업무할당(기획, 디자인 위주)
3. 피그마로 제품 개발 sub(카카오 오픈채팅)
4. 디스코드로 회의 및 업무대화 진행 + 피그마 점검 및 피드백 sub(카카오 오픈채팅)
5. 트렐로로 업무할당(개발 위주)
6. 서비스개발
7. Preview를 보며, 1 ~ 6 or 3 ~ 6반복

📌 보완사항

1. 국소적으로 발생하는 기획 건을 전부 소통할 수 있도록 오픈채팅방을 사용
2. 대화했던 내용을 바로 업무리스트로 옮기기 위해 디스코드with트렐로 활용
3. Preview 배포를 통해 디자인과 프론트의 단차 제거
4. 피그마 코멘트 후 회의를 통해 전 인원 기능 및 디자인 점검 및 피드백 👉 최종 락인하여 기능 범위와 일정의 애매함 해소

공식적으로 프로젝트 하기로 한 6주가 지나갔다. 빠듯한 기간동안 좋았던 점도 많았고, 보완해야할 부분도 많았다. 팀원 한분이 KPT회고라는걸 알려줬다. 이 회고를 통해 교훈을 얻으며 끝 매듭을 짓고, 새로운 시작을 준비할 수 있었다.

📌 KPT 회고란?

Keep, Problem, Try의 약자로 Keep은 잘 한 것, Problem은 아쉬운 것, Try는 K와 P 기반으로 실행가능하고, 측정가능한 Action을 도출.

회고의 목적

지금보다 더 나은 협업을 위해 실행할 action item을 2~3가지 정도 도출해내기.

회고의 시기

kpt회고를 해보면서, 이 회고방식을 도입하는 시기가 중요하다고 느꼈다. 6주동안의 빠듯한 프로젝트가 끝나고, 새로운 시작을 준비해야했기 때문에 지금 한번 잡고 가는건 좋은 것 같았다.

회고의 구성

1. Keep (유지할 것)

• 이번 스프린트(또는 프로젝트)에서 잘된 점
• 효과적이었던 방법이나 프로세스
• 계속 유지하고 싶은 팀의 문화나 협업 방식

2. Problem (문제점)

• 비효율적이었던 점이나 개선이 필요한 요소
• 업무 진행 중 겪은 어려움
• 팀 내 의사소통이나 도구 사용의 문제

3. Try (시도할 것)

• Problem에서 도출된 개선안을 구체적으로 실천할 방법
• 다음 스프린트나 프로젝트에서 적용할 변화
• 새로운 도구나 프로세스를 도입할 아이디어

📌 진행 방식

1. KEEP/PROBLEM은 각자 미리 작성해오기
2. 회고 미팅에서 동료들에게 내용 공유
   • 회고 미팅에서는 노션을 활용해 함께 브레인 스토밍하며 진행했다. Keep, Problem을 이야기 하면서 Try부분을 함께 적었다.
3. 다같이 TRY와 Action Item을 추출하기
   • 도출된 Try항목 중에서 우선순위를 정했다.
   • Try에서 적었던 내용들을 구체적이고 실행가능한 Action Item으로 정리했다.
   • 다음 회고 때는 이 Action Item들이 잘 적용됐는지 점검하자.

📌 작성 시 고려할 것들

• 기획, 디자인, 개발 협업관계
• 서버 ↔ 클라이언트간 협업관계
• 스스로 깨달은점
• 다른사람에게 주고 싶은 피드백
• Problem은 특정 사람을 탓하고, 비난하기 위한 항목이 아님. 대상이 사람이 아닌 현상이면 좋아요!
  • 발생했던 문제가 왜 발생했는지를 파악하고, 앞으로 일어나지 않도록 개선해나가기 위한 과정이라고 생각해주세요!

📌 뽀또픽 KPT회고

📌 K - Keep

📌 1. 주기적인 회의, 기획 단계부터 전원이 적극적으로 참여

• 주기적인 회의를 통해 기획, 디자인, 개발 모두가 기획 단계부터 함께 참여.
• 이로 인해 팀원 모두가 서비스의 전반적인 흐름과 방향성을 명확히 이해할 수 있었고, 서비스에 대한 오너십이 자연스럽게 생겼다.
• 지금과 같이 기획에 적극적으로 참여하려는 마인드를 가지고 이어가면 될 것 같습니다.

  📌 2. 2차 MVP 때부터 Technical Document를 작성하여 개발 간 싱크를 맞췄던 것

• 개발 전에 문서화를 통해 싱크를 맞추어 개발 기간 동안의 소통 비용이 확실하게 줄었다.
• 스펙이 이미 논의되어서, MSW를 통해 api 개발에 병목 없이 클라이언트 개발이 가능했다.
  • 특히, 2차 MVP 몇몇 기능은 서버 개발 이전에 클라이언트 개발이 끝났었음
• 앞으로도 개발 이전에 Technical Document를 통한 싱크를 컨벤션으로 가져간다!

  📌 3. 의견 있으면 숨김 없이 제안했던 것

• 개발이나 디자인이나 생각한 것과 다른 부분이 있으면 의견을 제안한 것
• 그 제안을 통해서 내용이 바뀌는 것을 떠나서 이런 과정을 통해 서로의 의견을 맞추는 것이 좋았다
• 지금처럼만 해도 의견을 모으는데 부족함 없을 것 같다

  📌 4. 팀 구성원의 목표와 상황을 인지하고 있던 것

• 프로젝트 시작 전에 목표를 공유하여, 프로젝트 중에 목표에 어긋나지 않도록 동기부여할 수 있었음
• 개인적인 하루일과를 알고 있어서, 감안하여 일정을 조율할 수 있어 좋았음
• 좀 더 친해지면 좋을 것 같다(너무 친하면 안되지만…)

  📌 5. MVP를 쪼개어 진행한 것(피드백)

• MVP 작게 만들고 사용자 피드백을 받아, 우선순위를 정할 수 있었다.
• 의견이 분분할 때, 사용자 피드백은 가불기였다
• 이를 바탕으로 개선해나가는 작업이 결국 프로덕트를 만드는 궁극적인 이유와도 같았다.
• 피드백 받은 것을 문서화 하여 깔끔하게 정리해야 된다. (피드백에 대한 서로의 생각 공유)
• 피드백은 아주 소중하고 두고두고 봐줘야할 요소인데, 피드백 공유에 참여한 인원이 없어 그냥 넘어갔다.
• 만약에 문서화를 한다면 같이 보면서 기획의 시간을 가졌으면 좋겠다.

  📌 6. 자발적인 개발과 디자인

• 문제가 될 수 있는 부분을 자발적으로 캐치하여 개발해주신 덕분에 좋았다.
• 서버문제, 확장자 문제, UI, 캐릭터, 기능 예외 등등
• 문제가 될 부분을 미리 알려주고 진행하면 더 좋을 것같다.
• 그리고 문제가 될 부분을 알게 되면 문서화 하여 팀 전체에 공유 해야겠다. → 일정파악 / 우선순위 파악

  📌 7. 매주 만나고, 매주 2회씩 회의

• 회의 참석률이 너무 높아서 좋았다. 의견공유 활발

P - Problem

📌 1. 1차 MVP 배포된 이후에 디자이너가 원하는 디자인이 적용되지 않음을 알았다.

• QA를 위해 1차 MVP 배포를 했는데, 그때서야 디자인이 의도한대로 나오지 않았음을 알았음
• 1차적으로는 프론트엔드 팀에서 디자이너에게 결과물을 미리미리 공유하지 못한 점이 아쉬웠다.
• Preview를 통해 미리 보여드렸다면 진작에 소통해서 해결할 수 있는 문제라 더욱 아쉬웠다.
• 가이드를 잘못줬다.
• PR (개발) 커밋 → 리뷰 → Dev Deploy (기획, 디쟌)

  📌 2. 게스트 로그인 개발이 예상한 시간보다 오래 걸렸다.

• 게스트 로그인 개발 시간을 하루 미만으로 예상했는데, 2~3일이 지나도 해결되지 않았다.
• 2~3일이 밀렸는데, 팀에게 상황이 공유되지 않았다.
• 프론트 내에서 내가 맡은 작업은 개인적으로 책임감을 가지고 충분히 고민하여 해결하면 된다고 생각했지만, 이를 팀에게 충분히 공유하지 않고 스스로 고민하고 해결하려다 보니 결국 시간이 지체됨. 조직 전체 일정과 협업에 영향을 미친다는 점을 간과함.
• 작업 상황을 공유하며 백엔드 팀과 정리하고 공유드린 부분들을 이해하셨다고 생각했지만, 이후 보니 내 설명이 충분히 전달되지 않았고, 정확히 이해하지 못하신 부분이 있었음.
• 작업 상황과 문제를 설명할 때, 배경과 맥락을 구체적으로 전달하지 못함.

  📌 3. 기능명세가 나온 이후에 의견들을 제시하여 두 번 일하게 되었다.

• 기능명세가 이미 완성되었는데, 그 이후에 개발자들이 개발을 진행하면서 기획 쪽에 의견들을 계속 제시했다.
• N차 MVP 범위가 정해졌는데 새로운 기능(버그 픽스 x)을 추가하여 범위가 늘어났다
• 명세 완성 이후 팀 전체가 싱크 맞추는 기회가 없었음
• 당연히 개발자들이 명세를 보면서 미리미리 의견을 제시하면 좋겠지만, 개발을 시작할 때 명세를 보기 시작한 것도 문제라고 생각

  📌 4. 개발자들의 개발 진행 상황 트래킹이 잘 안 되었다.

• 개발자들의 개발 진행 상황 트래킹이 잘 되지 않았음
• 데일리 스크럼, 기획자 분께서 개인 연락으로 트래킹을 열심히 시도해주셨으나, 팀에게 잘 공유는 안되었음
• 1차적으로는 개발자 개인이 매일매일 진행상황을 공유했으면 해결됐을 문제
• 회사가 아니니 어쩔 수 없는 것은 인지하고 있다.

  📌 5. 일부 팀원들이 논의한 상황이 팀 전체에게 공유되지 않고 반영된 경우들이 있었다.

• 정기회의 이외에 일부 팀원들의 논의를 통해 결정된 사항들이 팀 전체에 공유가 잘 되지 않았음
• 일부 팀원들의 논의를 통해 결정된 사항들을 피그마에 잘 기술해주셨으나, diff를 파악하기 어려워서 개발자 입장에서 어느 순간 반영된 것처럼 느껴질 수 있을 것 같음
• 개발자들이 개발을 시작한 이후에나 왜 바뀌었는지에 대한 히스토리를 파악하게 됨

  📌 6. 개개인의 회의 준비 부족 → 회의 지연

• 회의 시작 전 어떤 내용을 논의해야 할지 파악되지 않아, 회의 자리에서 문제를 인식하고 바로 해결법을 찾는 형식으로 회의 진행.
• 논의에 대한 의견이 생각나지 않은 경우엔 의견을 피력하지 못하거나 고민하는 시간이 길어져 회의 시간이 불필요하게 지체됨.
• 회의 안건이 사전에 명확히 공유되지 않았음.
• 프로젝트 데드라인으로 인해 팀원들이 회의 전에 충분히 고민할 시간적 여유가 부족했음.

  📌 7. 디자인 수정이 빈번히 발생함.

• UI 작업을 완료 했으나, 이후 추가 수정 요청이 발생해 동일한 작업을 여러 번 반복해야 했음. → 시간 지체
• 예상 가능한 수정 사항에 대한 사전 협의 부족.

  📌 8. 기획 변경 사항 공유 부족 (+ 피그마 반영)

• 마감 기한을 맞추기 위해 최소 기능으로 조정한 내용이 피그마에 반영되지 않음. (피그마에는 2차 MVP 수정 사항이 반영되지 않은 채로 초기 디자인 작성 후 업데이트 되지 않아 업데이트 된 점을 인지 하지 못한 상태로 UI 반영, 추후 다시 롤백)
• 개발 중 기획 변경 사항 파악이 어려워 혼란 발생.
• 소수 인원 회의로 결정된 내용이 전체 팀원에게 충분히 공유되지 않음.
• 피그마/노션 등 협업 툴에 변경 사항 기록 미흡.

  📌 9. 공통 컴포넌트 정의와 소통 부족

• 1차에서 투표 상세 페이지에만 있던 vertical Ellipsis가 2차에서 홈에도 추가.
• 초기 공통 컴포넌트로 지정하지 못한 채 기존에 사용하던 것들을 리팩토링 하다보니 시간 지체.
• 재사용 시도 실패 → 개발 시간이 불필요하게 지연. 홈에서는 결국 vertical Ellipsis 없는 상태로 배포.
• 디자인 단계에서 해당 컴포넌트의 재사용 가능성, 공통화 여부에 대한 논의 부족.
• 컴포넌트가 추가되는 시점에서 개발자-디자이너 간 협의 없이 바로 적용 시도.

  📌 10. 케이스별 화면 UI 부족

• 기능 명세서 및 피그마 UI가 케이스별 흐름, 예외 상황이 충분히 명확하게 정리되지 않아 UI를 구현할 때 예상하여 구현하거나 재차 확인해야 하는 상황 발생.
• 초기 기획에서 케이스별로 깊게 고민해볼 시간 부족.
• 케이스 별 UI가 피그마에 명확하게 정리되어있지 않은 경우가 있었음.

  📌 11. UX 완성도 미흡

• 1차 MVP 이후 UX/UI 피드백 다수
• 초기 ux 설계가 미흡했음

  📌 12. 협업 툴 사용 어려움

• 개발 체크리스트를 놓치는 경우가 많음

  📌 13. 이유를 말하지 않고 주장을 어필했다.

• 건 주고 받을 때, 했음 좋겠다. 이거 있어야된다. ~왜하냐, ~~굳이 해야되냐?라고 하니 생각을 알 수 없어 답답했다.

  📌 14. 체크리스트의 부재

• 명세만 있고, 완료여부를 모르겠음
• 할일 목록이 없음

  📌 15. 그라운드 룰 안지킴

• 그라운드룰을 잘 안보고 잘 안지키게 됨(전원)
• 그라운드룰이 실상 막 중요한 느낌은 아닌데, 지나고보면 좀 중요한듯.
• 추가할만한 룰이 있는데, 어차피 안보니까 잘안하게됨

  📌 16. 답답할때, 빠르게 의견공유 안함

• 생각 달라서 지연됨
• 생각이 다른데, 말을 안했음
• 사람한테 싫은소리하게 될까봐 싫어서 안함

  📌 17. 연락 및 트래킹 시간 축소 필요

• 명세나 문서화, 추후 기획과 정의작업이 연락하고 트래킹하는데 시간 다써서 넘 힘들었음
• 그러다 보니 나중엔 명세에 있었는지, 얘기가 정확히 됐는지 잘 모르겠음
• 아주 보잘 것 없는 질문이어도 답변을 해줘야될 것 같음.
• 확인 하라는 공지에 확인 후 피드백이 적었다.
• 완료건, 진행 건 혹은 답답하고 이해안되는 건 등등 서로 미루지 않고 바로 말하기

  📌 18. 기획 방향이 명확하지 못했음

• 기획과 결과의 차이 발생

  📌 19. api 설계를 다같이 안 해서 수정이 자주 일어남

• api 개발을 다같이 안 해서 계속 수정이 발생함
• 백에서 임의로 만들고 프런트에서 보면서 부족한 부분 수정 요청하는 방식으로 개발됨
• 백에서 프런트가 어떤 데이터를 필요로 하는지 완벽하게 알기가 힘듬

  📌 20. 기능 구현 기간을 애매하게 정함

• 기능 구현을 할 때, 정확한 기간을 정하지 않아서 기획/개발자 간의 싱크가 맞지 않았음
• 그래서 누구는 언제까지 구현되어야 한다 하고, 누구는 더 우선인 기능을 구현하고 나서 작업해야한다는 등
• 기능 별로 완료 기간을 정확하게 정하지 않고, 각자 생각하는 방향과 그림이 다름

  📌 21. 성능이 너무 안나옴

• 돈이 듦

  📌 T - Try

  📌 ✅ 1. Trello 사용방법 리서치 및 발표

  📌 ✅ 2. 기능명세서 완성 후 팀원들과 공유하는 시간을 갖자

  📌 ✅ 3. 기획 + 프론트 + 백엔드가 설계를 같이해본다

  📌 4. 더 많은 피드백을 얻기 위한 방안을 마련한다.

  📌 5. 피그마에 변경내역만 있는 명세 추가

  📌 6. 케이스 별로 화면 구성하기

  📌 7. 피드백 받은 것을 문서화 및 리뷰

  📌 8. 개발에서 마주한 문제를 팀에게 공유하자

  📌 9. Preview Deploy 도입 검토

  📌 10. 그라운드 룰 다시 작성 후 상기하는 시간

  📌 11. 성능 개선

📌 회고의 장점

📌 간단하고 직관적

• Keep, Problem, Try라는 3가지 요소로 구성되어 있어 누구나 쉽게 적용할 수 있었습니다.
• 팀원 간 피드백을 자연스럽게 유도하여 그동안의 답답한 부분을 해소할 수 있었습니다.

  📌 팀 성장

• 회고를 통해 문제점을 파악하고, 해결 방안을 함께 고민할 수 있다.
• 지속적인 개선이 가능
• Try에서 나온 개선 사항을 실천하고, 이후 회고에서 점검하는 방식으로 지속적인 개선이 가능하다.
• 긍정적인 팀 문화 형성에 기여합니다.
• 단순히 문제를 지적하는 것이 아니라 잘된 점(Keep)을 공유하며 동기부여할 수 있다.

  📌 KPT회고가 필요했던 이유

  📌 적극성 부여

  팀의 성장 때문에 필요했다. 팀이 성장한다는 것은 팀원들 간의 긍정적인 상호작용이 일어나고 있다는 뜻이다. 우리 팀에서 가장 부족했던 것은 적극성이다. 찔러야 나오는 것이 아쉬웠다. 찌르기 전에, 문제가 있으면 이야기하고 소통할 수 있어야 했는데 그렇지 못했다. 그러다가 서로의 입장이 쌓인 뒤, 유야무야 푸시해서 진행된 적도 몇 차례 있었다. 그래서 회고가 어찌보면 늦은 감이 있었나? 싶을 정도로 필요 했다.

  📌 발언의 기회 부여

  각 팀원들에게는 일부는 쌓아두는게 어쩔 수 없는 선택이기도 하다. 왜냐하면 어떤 직책 혹은 책임을 지지 않고 동등한 레벨의 멤버에게 어필하기란 쉽지 않다. 게다가 전달하고자 하는 내용이 상처가 될 수도 있기 때문에 문제와 해결책을 알면서도 마음 속에 쥐고 있을 수 밖에 없다고 생각한다. KPT회고는 팀원들에게 의사를 말할 수 있는 기회를 제공하고, 다른 팀원들의 상황을 이해하게 만든다. 이후에는 종합적인 상황안에서 모두가 동의하는 해결방안을 마련할 기회를 제공한다.

PM을 맡고 4주차... 큰 고민과 시련에 빠졌다. 참신한 아이디어로 시작한 프로덕트가 더 이상 참신해 보이지 않았고, 이게 사용자의 문제를 해결해줄 것 같지 않았다. 사실 팀원들은 큰 걱정이 없었을 수도 있다. 그러나 나는 알 수 없었다. 기존에 있던 서비스도 아니고, 이제 막 1차 MVP를 수립하고, 인프라를 구축하던 시점이니 의견을 구하고 싶다는 생각이 들었다. 개인적인 나의 성향상 과몰입이 심한 사람인데, 문득 "사진을 SNS에 올리기 전, 고민되는 사진을 투표하는 어플리케이션"이라는 주제가 정말 사용자들의 문제를 해결해 주는 어플리케이션인가? 라는 의문이 맴돌았다. 내가 이프로젝트를 하면서 가장 진지하고 심도있게 빠졌던 시기 같다.

✔️ 문제정의와 가설수립, 검증

그래서 나는 혼자 기획에서의 문제와 가설 그리고 검증이라는 것에 대해서 공부해보고, 우리 서비스에 대입하여 생각해보는 과정을 거쳤다.

문제란 무엇일까? 보통 문제는 현상으로 나타난다. 우리의 경우에는 SNS에 사진 올리기전에 어떤 사진을 올릴지 고민된다. 라는 현상을 발견했다. 근데 우리는 이 현상을 문제로 정의하는 오류를 범했다. 현상은 문제가 아니다. 내 나름의 문제와 현상의 차이를 정의 헀다.

1. 해결할 가치가 있는가?
2. 사용자들이 적극적을 해결책을 찾는가?
3. 사용자들이 시간과 돈을 쓰는 문제인가?

문제는 위와같은 물음에 Yes라는 답이 나와야 기획단에서 정의 하는 문제인 것이다. 사용자는 생각보다 더 냉정하고 게으르기 때문에 조금의 불편함은 감수하고 산다. 그렇기 때문에 '중요한 문제'가 아니면 관성에 의해 살던 대로 살 가능성이 크다.

그렇다면 우리는 우리가 발견한 이 현상을 어떻게 문제로 정의할 것이냐? 라는 큰 숙제에 직면한 것이다.

문제를 추론해가는 과정에서 추상적인 생각 지양, 비판적인 사고, 가치제공에 대한 의식 등이 필요하다. 나는 이런 상황에서 아무리 머리를 굴려봐도 뾰족한 수가 나오진 않았다. 그래서 나름대로의 문제정의와 가설과 검증방법에 대한 내용을 정리하여 팀원들과 의논하는 시간을 가졌다.

✔️ 팀원들과의 논의

팀원들은 어떻게 생각하고 있었을까? 팀원들의 생각

• 우리는 사용자가 느끼고 있는 '불편함'을 찾지는 않았다.

• 우리는 사용자의 '욕구'를 충족시켜줄 현상을 찾았다.

• 그 현상은 SNS에 가장 잘 나온 사진을 올리고 싶었다는 것.

• 그럼 우리는 그 작은 현상이라도 투표를 통해 이 욕구를 충족시켜줄 문제를 정의하면 된다.

  나는 이 이야기속에서 큰 깨달음을 얻었다. 어떻게 6주짜리 프로덕트에서 이 세상에 없어서 해결할 가치가 있으며, 사용자들이 적극적으로 해결책을 찾고, 시간과 돈까지 쓰는 문제를 우리가 정의할 수 있을까? 그건 불가능하다. 그 덕에 다시 초심으로 돌아와 '작은 문제라도 해결하자' 라는 생각이 들었다. 이후, 사용자에게 피드백 받아 또 다시 문제를 세우고 가설을 검증하며 다시 사용자에게 피드백 받는 과정을 거치기로 마음 먹었다. 이 과정을 이터레이션 이라고 하는데 이 과정속에서 우리 서비스가 사용자의 문제를 해결해줄 수 있도록 구체화되고 확장될 것이라고 생각한다.

✔️ 문제정의에 대한 결론

이후, 나는 우리 프로덕트의 문제를 다음과 같이 정의 했다.

👿 결정 피로 문제

사용자들은 SNS에 사진을 올리기전에 선택의 어려움을 겪으며, 이과정에서 혼자만의 고민과 불필요한 에너지를 소비한다

👉 투표를 통해 빠르게 결정을 내릴 수 있다.

👿 긍정적인 반응을 원하는 욕구

사용자들은 SNS에 사진을 올리고 긍정적인 반응을 얻고자 하지만, 어떤 사진이 더 좋은 반응을 얻을지 예측하기 어렵다.

👉 ** 어떤 사진이 인기있을지 투표를 통해 예측해볼 수 있다.**

이 두가지 문제는 사용자들의 행동과 심리를 미루어 짐작해, 해결할 만한 문제로 구체화 해본 것이다. 그렇다면 이 문제에 대한 가설을 세우고 검증하는 과정을 거쳐 서비스의 핵심 줄기를 만들어야한다. 이전에는 정량적 리서치를 통해 위 문제들에 대한 해결 니즈를 확인한 상태였다. 이후에 또 다른 💡 검증 결과를 토대로 계속 이터레이션 과정을 거치며 사용자에게 선택받는 프로덕트로 발전시켜봐야 하는것이 숙제.

굉장히 바쁜 한 주가 지나갔다. 갑자기 회사에서 발생한 큰 이슈 때문에 사이드프로젝트에 집중을 하지 못했다. 매일 참여해야한다는 생각 때문에 야근까지 하고 와서 사이드프로젝트를 해보려하니, 도저히 집중할 수 없었다. 차라리 쉬는게 나을 뻔했다.

PM으로서 아쉬웠던 점 😢

저번 주는 아이디에이션을 구체화하고 1차 MVP를 어떻게 설정하느냐에 초점이 맞춰졌다. 그러면서 WEB/WAS서버 환경 구축 및 개발 워크플로우 작업을 병행했다.

처음 PM을 해보기 때문에 이런 방향으로 나아가는게 맞나 싶다. 웹프로덕트 개발이론이나 협업 시스템을 현재의 프로젝트에 적용해 보면서, 효용성을 체크하고 보완하고 싶은 욕심이 매우 컸다. 그래서 비슷한 서적과 강의, 블로그 등을 구비해놨는데 생각보다 프로젝트가 빨리 시작됐고, 회사 일도 있다보니 우선순위에서 계속 멀어졌다.

그래서 아이디에이션 과정에서도 충분한 리서치나 아이디에이션 도구 활용 등에 대한 적극성은 좀 떨어졌다. 그래도 구글폼을 활용해 리서치 해본 것은 프로덕트를 구상하는 관점에서 많은 도움이 됐다.(이게 유일한 리서치😢)

PM으로서 배웠던 점 😃

아마도 처음만난 팀원과도 어색하다보니, 의견공유도 적극적으로 이루어지진 못했다. 그래도 팀원 모두가 기획의 첫 단계에 참여한다는 것은 큰의미가 있다.

1. 프로덕트에 오너쉽을 갖고 시작할 수 있다.
   • 자기가 하고 싶은 주제를 갖고 디자인과 개발을 시작한다는 것은 추후에 어려운일이 생겼을 때 끝까지 마무리 하고자 하는 데 큰 도움이 된다.
2. 프로덕트에 대한 관심은 개발의 완성도에 기여한다.
   • 프로덕트에 대한 이해, 비즈니스 로직에 대한 이해는 개발 완성도에 큰 영향을 미친다. 당연히 관심이 많을수록 Usecase, 예외처리 등 비즈니스에 대해 깊게 고민해 볼 수 있고, 팀원과 수 없이 많은 의견을 공유할 수 있다.

많은 시간을 아이디에이션과 첫 기획에 담아보면서 리서치도 부족하고, 적극적인 협업도 부족했다. 그래도 이런 어리숙함 속에서 모두가 원하는 주제를 선정했다는 것은 만족스러웠다.

앞으로 진행할 모든 일들에 대해 미숙함은 발생할 수 밖에 없고, 받아들이고 발전하는 것은 시간의 몫에 달렸다고 생각한다. 그래서 더 앞으로 있을 일들에 대한 배움과 기록이 중요할 것이다.

📌 중요성

• 아이디에이션은 첫 시작이자, 가장 중요한 관문이라고 생각한다.
• 얼마나 만족스러운 아이디어가 나오느냐에 따라 성패가 달라질 것이라고 생각한다.
• 서비스가 대중들에게 선택받지 않더라도, 만드는 과정 내내 확신과 오너쉽으로 프로덕트 개발에 빠져들 수 있도록 해야한다. 또, 서비스가 전달하는 핵심이 직관적이고 명확하며, 쉽게 다가와야한다.
  • 와이어프레임, 기능명세, 화면설계, 요구사항, UserInterface 등의 문서작업과정이 빠르고 확실할 수 있다.
  • 디자이너 및 개발과 제품기획에 대해 피드백 하는 과정이 수월할 것으로 예상된다.
  • 개발단계에서 지치지 않고 지속적으로 나아갈 수 있는 동기를 부여한다.

📌 아이디에이션을 도와주는 툴, 블로그, 이미지

• 피그잼 - 잼봇
• 미로 - 미로어시스트
• https://brunch.co.kr/@msmmx/4
• 비즈니스모델 캔버스

📌 회고

• 아이디에이션 과정이 상당히 힘들었다.
  • 문제를 발견, 인식하는 것이 사람마다 달랐다.
  • 무자본, 콜드스타트 상태에서 서비스의 핵심가치를 정의하는 것이 어렵다.
  • 핵심가치가 나오더라도 어떻게 서비스로 녹일지, 방법론 등에 대한 지식과 정의가 부족하다.
• 내일 15시에 디스코드로 다시 만나서 아이디에이션을 이어나가기로 했다. 그 전까지 아이디어를 디벨롭 하는 과정에서 어떤 부분을 중점적으로 두고 서비스로 발전시킬지 항목화 해야겠다.
• 항목화한 리스트에 아이디어에 대한 질의를 쌓아가면서 디벨롭 하고, 육각형의 아이디어가 나올 수 있도록 하자.
• 기획단계에서 비용구조, 수익원, 파트너쉽 등 금전과 관련된 부분에 대해 논의를 하는 것은 거의 삭제되는 수준이었다. 상업적 목적의 어플리케이션 개발이 아니라는 것을 감안하여 위와 같은 부분은 소거하여 진행해야하는 것인지 고민이 된다.😂
• 팀원분들이 정말 많이 도와줬다. 사이드프로젝트 유경험자, 현업경험 있으신 분들이 기획의 가이드라인을 주셨다. 기획은 생각보다 많은 역량을 요구했는데, 부족한 점이 많았다. 그냥 백앤드개발로 지원할걸... 이라는 생각이 1주동안 엄청 들었다ㅋㅋ... 하던게 이것 뿐이라 기획을 하면서도 어떤 기술스택을 쓸까, 서버구성 및 아키텍처는 어떤게 좋을까 등 기술쪽으로 자꾸 생각이 치우쳤다. PM의 역할을 수행하는데 있어서 오히려 이런 것들이 방해가 되기도 했다.
• 도움받은 부분
  • 기획자가 어떤 방식으로 각 분야의 담당자들과 워크플로우를 구성해야하는지(커뮤니케이션 방법)
  • 기획단계에서 사용자 요구사항을 받는 방법(인터뷰, 리서치 등)

📌직무 간접경험 - PM

현재는 개발자든 설계자든 PM이든 어떤 IT직무에도 기술만 맞으면 지원할 수 있다는 생각을 한다. 근데 내가 개발, 설계, 기획을 모두 경험해보면서 서비스기획과 현실적인 아이디어를 제안하는 일련의 과정이 가장 흥미 있었다. 폭넓은 IT지식을 갖추고 싶고, 프로덕트가 개발부터 릴리즈까지 어떤 요소가 필요하고 어떤 과정을 거쳐야하는지 알고 싶다. 개발을 하다보면, 서비스를 구성하는 기술에 깊은 전문가가 된다. 근데 나는 이런 저런 기술에 관심이 많고, 그 기술로 이루어진 혁신적인 서비스에 관심이 많다. 그래서 사이드 프로젝트를 하면서 PM의 업무를 간접경험 해보고 싶다.

📌네트워킹

비전공자인 내가 백앤드, 프론트엔드, 디자이너 등의 직무를 꿈꾸는 사람들을 만날 수 있는 기회가 있다. 이들이 각자 갖고 있는 경험이 있을 것이고, 나와 공감할 수 있는 경험, 내가 겪어보지 못한 경험들을 나눌 수 있을 것이라 생각한다. 서로의 경험을 공유하고 같은 프로덕트를 만들다 보면 든든한 동료, 친구가 생길 것 같아 기대된다.

📌장기적 지속

사이드프로젝트는 기술과 역량을 키우기 위한 것이다. 경력사항에 큰 자리를 차지하진 않는다. 나도 마찬가지로 IT업계종사자로서 회사말고 IT관련 재미있는 무엇인가를 만들어가고 싶어서 사이드프로젝트에 관심을 가졌다. 회사와 집을 반복하는 직장인1 보다는 경력 외로 다른 IT세상을 맛보고 장기적으로 이 일에 흥미를 두고 싶다.

📌사이드프로젝트를 어떻게 시작할 수 있을까

📌IT동아리

• 대학생이 아니기 떄문에 PASS
• 강제성과 기한의 부재로 인해 늘어질 가능성이 있다.

  📌동료, 친구

• 가장 어려운 것 같다.
• 프로젝트라 하면 트러블의 여지도 있기 때문에 이런부분을 해결하는게 동료나 친구는 어렵다.
• 이탈의 확률이 크다.

  📌모집 사이트

• 여러 사이트가 있다. 렛플이라든지 수프라든지 OKKY 등...
• 여기서 한군데를 정해서 지원하는 것. 나쁘지 않다.
• 대신 나의 목적과 사이드프로젝트의 목적, 조직문화 등이 일치하는지 잘 확인해봐야 한다.

  📌해커톤

• 많은 시간이 들어가서 일을 하면서 사이드로 하기에는 어렵다고 생각했다.
• 다양한 해커톤들이 진행되는데, 이 기회가 항상 있는것이 아니라 진행될때를 노려야한다.
• 만약 하게 되면 짧은 시간에 각 분야별로 모여서 할 수 있어서 좋다.

📌사이드프로젝트로 얻고자 하는 것

📌자신감, 네트워킹, 기술연습, 이력보완

• PM으로 직무전환을 고려하면서 작지만, 완성된 어플리케이션을 만들어보고 싶다. 이 경험을 통해 내가 직무에 적합한 사람인지, 적합하다면 이 경험을 토대로 관련 기술을 익히고, 자신감도 가질 수 있을것 같다. 네트워킹은 덤!

• 현업에서 일하면서 배운 지식과 경험을 작은 프로젝트 안에 녹여보고 싶다.

📌실패경험을 복기해서 완주로 마무리하기

사이드 프로젝트는 보수가 없다. 말그대로 하고 싶어 하는것. 끝까지 완주하기 위해 실패경험을 적어보고, 보완점을 토대로 프로젝트 완주해보자.

📌실패경험. 😠팀내불화

📌원인

• 기대가 일치하지 않음
  • 각자 프로젝트에서 기대가 있고, 목적, 목표 등이 있을 것이다. 누구는 커뮤니티를 원하고, 누구는 기술적 발전에 초점을 둘 수도 있다. 그런 팀원들과 의사소통 없이 마감에만 집중하고 어떠한 그라운드 룰 없이 프로젝트가 진행됐다. 당연히 서로 다른 목표 때문에 속안의 스트레스, 불만이 쌓일 수 밖에 없었다.
• 솔직함의 부재
  • 솔직하지 못해 이런 불만들이 쌓이게 두었다. 솔직하게 불만을 표출하면 친절함을 잃고 싸움이 될까 두려웠기 때문이다. 결국, 마감 때 터지고 말았다.

    📌해결방안

    지금와서 생각하면, 꼭 말해야했다. 그리고 말하는 방식에 대한 우리만의 문화가 필요했다. 서로 합의된 룰 안에서 솔직하다면, 솔직함은 친절함과 배타적인 의미가 아닐 것이다.

1. 컴플레인 무조건 말하기
   • 어떤 내용이든 속안의 내용들은 무조건 말해야 한다.
   • 컴플레인 표출에 대한 긍정적 함의 필요.
2. 말하는 방식 정하기
   • ~님 사용, 존댓말 유지
3. 각자 목적, 목표, 동기, 원하는 바 등을 공유하고 인지.(팀캔버스활용)
4. 안점감과 소속감, 주인의식을 갖기 위한 각 인원 존중.
5. 완성된 어플리케이션에 대한 기대치 맞추기(개발 및 설계의 범위, 기술수준 등)
6. 결정의 방법과 주체를 정하자.(기술PL필요)
7. 숙제가 아니라 활동한다고 생각하기.
8. 일이 아닌 기여라고 생각하기.
9. 마감 집중에서 우선순위와 속도에 집중하기(우선순위매트릭스 활용)

📌사이드프로젝트를 완주하기 위해 필요한 요소는 뭘까

사이드프로젝트는 경제성도 보수도 경력도 아니다.😂 무엇이 Grit(힘들어도 이겨낼 수 있는 능력!)을 가지며 꾸준하게 프로젝트를 진행할 수 있을까?

1. 성취와 성장
2. 경험과 탐험
3. 관계

이러한 요소들이 사이드프로젝트를 완수할 수 있는 주 요소가 될 것이다. 나 같은 경우는 2번 경험과 탐험이다.

1. 팀원들과 팀빌딩 시간에 자유롭게 이야기해 보고 싶다. 각자 프로젝트 성공의 정의는 무엇인지, 각자 능력의 한계는 무엇인지, 하고 싶은 과제와 역할은 무엇인지...등등 프로젝트는 함께 풀어야할 문제이다. 역할을 부여받고 혼자 풀어내야할 문제가 아니라는 점을 분명히 하고 싶다.

2. 편안한 분위기에서 프로젝트 회고는 필수다. 각자 매주 간단한 회식이든 식사든 만남을 갖고 회고하는 시간을 가져보고 싶다. 의미는 만드는 것이 아니라 찾는 것이라 생각한다.

ERP를 설계하다보면, 수많은 테이블의 조인연산이 이뤄지고, 원하는 데이터를 얻기위해 서브쿼리도 자주 사용하였습니다. 이렇게 되다 보니, 조인을 10~20개씩 걸어서 데이터를 조회 했습니다. 예를들어, 프로젝트 관련된 정보를 조회하고 싶다.

프로젝트 테이블 - 영업기회 테이블 - 수주 테이블 - 사원 테이블 - 부서 테이블 - 거래처 테이블 - 신용정보 테이블 - 프로젝트 타입 테이블 - 라이선스 테이블...

원하는 데이터를 얻고자 쿼리는 계속 늘어나게 됐습니다. 처음에는 성능상의 이슈가 없다가도 데이터가 늘어나게 되면 WAS서버가 다운되는 일까지 발생했습니다.

이를 해결하기 위해, 다양한 방법으로 쿼리를 튜닝해보고 비즈니스에 맞게 DB 아키텍쳐도 구성해보는 등 의미 있는 시간을 가져봤습니다.

1. 인덱스(Index) 설계 최적화

인덱스는 데이터 검색 속도를 크게 향상시키는 데이터베이스 구조입니다. 하지만 모든 컬럼에 인덱스를 추가하는 것은 성능 저하를 초래할 수 있습니다.

기술적 원리와 작동 방식

• B-Tree 기반 인덱스: 데이터를 정렬된 트리 구조로 저장하여 검색 연산의 시간 복잡도를 O(log n)으로 감소.
• 해시 기반 인덱스: 키 값에 대한 해시 함수를 사용하여 데이터 위치를 직접 참조, 특정 값을 찾는 데 매우 빠름.
• 클러스터드 인덱스: 테이블의 실제 데이터가 인덱스 순서에 따라 정렬.

적용 예시

• 조회 빈도가 높은 user_id 컬럼에 인덱스를 추가.
• 주문 상태(status)를 기준으로 조회하는 경우 status 컬럼에 인덱스를 설정.

CREATE INDEX idx_user_id ON users(user_id);
CREATE INDEX idx_status ON orders(status);

예시: B-Tree 인덱스 구조

2. 쿼리 작성 방식 개선

비효율적인 쿼리는 데이터베이스 리소스를 과도하게 소모합니다. 이를 방지하기 위해 쿼리를 간소화하고 최적화해야 합니다.

기술적 원리와 작동 방식

• SELECT 최적화: SELECT *는 모든 컬럼을 불필요하게 조회하므로 특정 컬럼만 선택.
• JOIN 최적화: 서브쿼리는 각 쿼리를 독립적으로 실행하므로, JOIN으로 병합하여 성능 개선.
• 필터 조건 최적화: WHERE 절을 사용하여 데이터를 미리 필터링.

적용 예시

• order_items 테이블에서 수량(quantity)이 10 이상인 데이터를 조회.

-- 비효율적인 쿼리
SELECT * FROM orders WHERE id IN (SELECT order_id FROM order_items WHERE quantity > 10);

-- 최적화된 쿼리
SELECT o.id, o.date
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
WHERE oi.quantity > 10;

3. 데이터 정규화와 비정규화

데이터 정규화는 중복을 최소화하고 데이터 일관성을 유지하는 데 효과적입니다. 반면, 비정규화는 읽기 성능을 높이는 데 유리합니다.

기술적 원리와 작동 방식

• 정규화: 테이블을 분리하여 중복 데이터를 제거하고 데이터 무결성 유지. 대표적으로 1NF, 2NF, 3NF 등이 있음.
• 비정규화: 읽기 성능을 위해 필요한 데이터를 하나의 테이블에 결합하여 저장.

적용 예시

• 정규화: 고객 테이블과 주문 테이블을 분리.
• 비정규화: 고객 이름과 주문 데이터를 하나의 테이블에 저장.

-- 정규화된 테이블 설계
CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    date DATE,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

-- 비정규화된 테이블 설계
CREATE TABLE orders_with_customer (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    date DATE
);

예시: 정규화와 비정규화 비교

4. 실행 계획(Execution Plan) 분석

데이터베이스가 쿼리를 처리하는 과정을 분석하여 병목 지점을 식별할 수 있습니다.

기술적 원리와 작동 방식

• Access Path: 테이블 전체를 스캔하는 Full Table Scan을 피하고 인덱스를 활용.
• Cost: 실행 계획에서 비용이 높은 연산(예: Sort, Hash Join 등)을 줄임.

적용 예시

• EXPLAIN 명령어로 실행 계획 확인.

EXPLAIN SELECT o.id, o.date FROM orders o WHERE o.status = 'completed';

5. 데이터베이스 통계 정보 최신화

최신 통계 정보는 쿼리 최적화 도구가 효율적인 실행 계획을 수립하는 데 도움을 줍니다.

기술적 원리와 작동 방식

• 옵티마이저(Optimizer): 통계 정보를 활용하여 가장 적합한 실행 계획을 자동으로 선택.
• 통계 정보 갱신: 테이블과 인덱스의 데이터 분포를 주기적으로 분석.

적용 예시

• ANALYZE 명령어로 통계 정보 갱신.

ANALYZE TABLE orders;

예시: 옵티마이저와 통계 정보

• 회사에서 소프트웨어 회사에 특화된 영업관리 모듈을 설계하고 개발하는 업무를 맡았다. N개의 고객사의 비즈니스에 맞게 ERP시스템을 설계하고 개발해야했다. 표준이 되는 패키지 서비스를 갖고 모든 업체의 비즈니스를 소화해야하기 때문에 무지성으로 만들면, 업체 전용으로 프로젝트가 과생산 되는 경우가 발생했다.

• 이렇게 되면, 향후 업체가 늘어날수록 유지보수가 힘들어지고, 추가공수가 발생하는 문제가 생긴다.

• 예를 들면, A업체는 전자계약으로 글로사인 사용하고, B업체는 스마트빌을 사용할 수 있다. 각 전자계약 업체마다 API가 다르니 업체 전용프로젝트를 만들어서 전용으로 나가는 방식을 채택하게 되면 향후에는 OO전자계약을 사용하는

• *회사 N개에 N개의 무지성 클론프로젝트가 생기는 것**이다.

• 이를 효율적으로 확장하기 위해 여러가지로 찾아보다가 팩토리패턴으로 패키지서비스를 설계했다.

📌 팩토리패턴

✔️ 장점

1. 객체 생성 코드 재사용 가능
   • 객체 생성 로직을 캡슐화하여 코드 중복을 줄임.
2. 유연성 증가
   • 클라이언트 코드가 생성 로직에서 분리되어 새로운 타입의 객체를 쉽게 추가할 수 있음.
3. 유지보수성 향상
   • 객체 생성 로직이 한곳에 집중되어 변경이 쉬움.
4. 결합도 감소
   • 클라이언트 코드와 객체 생성 로직 간의 의존성을 줄임.

• 나의 경우 여러 전자계약 시스템별로 유지보수 가능하면서, 유연하게 확장해야 했다.
• 일단, 스프링을 활용한 팩토리패턴은 DI기능을 사용하여 객체생성을 프레임워크가 관리한다. 등록기반팩토리패턴 활용에 좋다.
• 이유는 스프링 컨텍스트에서 팩토리 빈 생성 시점에 내가 정의 해놓은 전자계약 클래스들(Bean)을 주입받기 때문이다.

✔️ 전자계약의 종류에 따른 팩토리패턴 설계구조

✔️ 팩토리 패턴의 구성 요소

• Product: 생성할 객체의 인터페이스 또는 상위 클래스.
• ConcreteProduct: 실제로 생성되는 객체.
• Factory: 객체를 생성하는 클래스 또는 메서드.

✔️ 설계코드

• 다양한 전자계약 방식(글로사인, 스마트빌 등)을 지원하는 애플리케이션에서, 계약방식에 따라 다른 객체를 생성해야 한다고 가정합니다.

  /* 각 전자계약의 Product */
  public interface eContract {
    void makeContract(contractModel contract); //전자계약에 필요한 변수들을 총망라한 모델 - ERP데이터를 기반으로 만들어진다.
  }
  /*******************************************************************/
  /* 각 전자계약의 ConcreteProduct 구현체 */
  @Component
  public class Glosign implements eContract { //글로사인
    @Override
    public void makeContract(contractModel contract) {
        //글로사인 api호출 로직
    }
  }
  @Component
  public class Smartbill implements eContract { //스마트빌
    @Override
    public void makeContract(contractModel contract) {
        //스마트빌 api 호출 로직
    }
  }
  /*******************************************************************/
  /* 각 전자계약의 Factory Bean*/
  @Component
  public class ContractFactory {
    private final Map<String, eContract> contractMap = new HashMap<>();
  
    //생성자주입 - 빌드시 스프링컨텍스트에 위의 구현체를 바탕으로 자동으로 주입
    //팩토리에 구현해놓은 전자계약 클래스들을 등록하는 과정(등록기반팩토리)
    public ContractFactory(List<eContract> eContracts) {
        for (eContract econtract : eContracts) {
            contractMap.put(econtract.getClass().getSimpleName().toLowerCase(), econtract);
        }
    }
  
    public eContract getEContract(String type) {
        return contractMap.get(type.toLowerCase());
    }
  }
  /*******************************************************************/
  // 클라이언트 코드
  @RestController
  public class ContractController {
    private final ContractFactory contractFactory;
  
    public ContractController(ContractFactory contractFactory) {
        this.contractFactory = contractFactory;
    }
  
    @GetMapping("/contract")
    public void contract(@RequestParam String type, @RequestParam contractModel contract) {
        eContract econtract = contractFactory.getEContract(type); 
        if (payment != null) {
            econtract.makeContract(amount); //구현해놓은 전자계약 클래스에 따라 다른 api작동
        } else {
            throw new IllegalArgumentException("Unknown payment type: " + type);
        }
    }
  }
  /*******************************************************************/

✔️ 디자인패턴 적용의 효과

• 간단하게 등록방식의 팩토리패턴 설계 뼈대를 만든 것을 바탕으로 각 회사 시스템에 맞게 구현하였다.
• 실제로 다른 전자계약 시스템을 사용한다고 하면 나는 그저, 구현체 클래스를 하나더 만들어주면 끝일 뿐이다.(혹은 interface 수정) 나머지는 팩토리패턴이 알아서 맞춰서 호출해준다.
• 정처기때 배웠던 개방폐쇄원칙(OCP)에도 좋다고 한다. 확장에는 열려있고, 수정에는 닫혀있다는 의미다. 여러 고객사를 상대하는 패키지 서비스를 설계할 때는 이런 부분을 많이 알아두는게 좋을 것 같다.

✔️ 추가고려사항

• 그리고 현재 아쉬운점은 다양한 전자계약시스템에 대한 디자인패턴 적용은 완료하였으나, 하나의 전자계약이라도 회사마다 사용방식이 다르기 때문에 이는 어떻게 효율적으로 관리할 것이냐를 또 생각해봐야겠다.

웹 개발을 하다보면, 서버에서 문자열을 가공하여 넘겨줘야하는 상황들이 발생한다. 예를 들면, 오늘 날짜를 simpleDateFormat을 활용하여 yyyy/MM/dd로 넘겨주거나 DecimalFormat을 이용하여 금액에 천단위 콤마를 찍어주는 일 등이 있다.

이를 사용자가 지정한 문자열 포맷으로 간편하게 변환해주는 공통메서드를 개발했다. 기본적으로 String.format()과 유사한 기능을 제공하지만, 다양한 데이터 유형에 대해 사용자 지정 형식 문자열을 지원하여 더 유연하게 동작한다.

또한, 어떤문자열이든 원하는 대로 형식을 지정하여 변환된 문자열을 리턴받을 수 있기에 개발생산성에도 좋은 영향을 줄 것이다.

코드

public static String Format(String format, Object... params) {
    if (StringUtil.isEmpty(format)) {
        return "";
    }

    // 정규 표현식을 사용하여 {index:format} 형태의 패턴을 찾기
    Pattern pattern = Pattern.compile("\\{(\\d+)(:[^\\}]+)?\\}");
    Matcher matcher = pattern.matcher(format);

    // 인덱스에 따른 값과 기본 포맷을 저장할 맵 초기화
    Map<Integer, Object> paramValueMap = new HashMap<>();
    Map<Integer, java.text.Format> paramFormatMap = new HashMap<>();

    // 파라미터 값과 기본 포맷 지정
    for (int i = 0; i < params.length; i++) {
        Object obj = params[i];
        paramValueMap.put(i, obj);
        paramFormatMap.put(i, obj != null ? getFormatter(obj, null) : null);
    }

    // 패턴을 찾으면서 형식화된 문자열로 대체
    StringBuilder result = new StringBuilder(format);
    while (matcher.find()) {
        String patternString = matcher.group();
        int idx = Convert.toInteger(matcher.group(1));
        String idxFormat = matcher.group(2);

        Object val = paramValueMap.get(idx);
        java.text.Format formatter = (idxFormat != null && StringUtil.isNotEmpty(idxFormat.substring(1)))
                ? getFormatter(val, idxFormat.substring(1))
                : paramFormatMap.get(idx);

        // 대체할 값 설정 및 형식에 맞게 대체
        Object replaceValue = (val == null ? "null" : val);
        String replacement = (replaceValue != null && formatter != null) 
                             ? formatter.format(replaceValue) 
                             : Convert.toString(replaceValue);

        // 패턴을 형식화된 값으로 대체
        int start = result.indexOf(patternString);
        if (start != -1) {
            result.replace(start, start + patternString.length(), replacement);
        }
    }

    return result.toString();
}

private static java.text.Format getFormatter(Object value, String formatExp) {
    if (value == null) return null;
    String className = value.getClass().getName();

    switch (className) {
        case "java.util.Date":
            return StringUtil.isNotEmpty(formatExp) ? new java.text.SimpleDateFormat(formatExp) : new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        case "java.lang.Integer":
            return StringUtil.isNotEmpty(formatExp) ? new DecimalFormat(formatExp) : new DecimalFormat("###,##0");
        case "java.lang.Double":
        case "java.lang.Float":
        case "java.lang.Long":
        case "java.math.BigDecimal":
            return StringUtil.isNotEmpty(formatExp) ? new DecimalFormat(formatExp) : new DecimalFormat("###,##0.##");
        default:
            return null;
    }
}

사용예시

1. 기본 사용 예제

   String formattedString = Format("Hello, {0}!", "World");
   System.out.println(formattedString); 
   // 출력: "Hello, World!"

2. 여러 파라미터와 숫자 포맷

   String formattedString = Format("The price of {0} is {1:###,##0.00} dollars.", "Apple", 1234.5);
   System.out.println(formattedString); 
   // 출력: "The price of Apple is 1,234.50 dollars."

3. 날짜 포맷 사용

   Date now = new Date();
   String formattedString = Format("Today's date is {0:yyyy-MM-dd}.", now);
   System.out.println(formattedString); 
   // 출력: "Today's date is 2024-09-12." (현재 날짜에 따라 달라질 수 있음)

4. 기본 형식 포맷 사용

   String formattedString = Format("Count: {0}, Total: {1}", 100, 1234.567);
   System.out.println(formattedString); 
   // 출력: "Count: 100, Total: 1,234.57"

5. 다양한 데이터 타입의 포맷팅

   String formattedString = Format("Boolean: {0}, String: {1}, Integer: {2}, Double: {3:0.00}", true, "Test", 12345, 3.14159);
   System.out.println(formattedString); 
   // 출력: "Boolean: true, String: Test, Integer: 12,345, Double: 3.14"

6. 값이 null인 경우

   String formattedString = Format("Name: {0}, Age: {1}", null, 30);
   System.out.println(formattedString); 
   // 출력: "Name: null, Age: 30"

7. 사용자 정의 포맷

   String formattedString = Format("Sales: {0:$###,##0.00}", 1234567.89);
   System.out.println(formattedString);
   // 출력: "Sales: $1,234,567.89"

Format, getFormatter 함수 동작 과정

1. 빈 문자열 검사

입력 문자열 Format이 비어 있거나 null인 경우, 이를 빈 문자열로 설정합니다.

if (StringUtil.isEmpty(format)) {
    return "";
}

2. 정규 표현식을 사용한 패턴 매칭

정규 표현식 (\\{(\\d+)(:[^\\}]+)?\\})을 사용하여 형식 문자열에서 자리 표시자를 식별합니다. 이는 {0}, {1:yyyy-MM-dd}와 같은 패턴을 매칭합니다.

• 정규 표현식 설명
  • {(\\d+)(:[^\\}]+)?}: 중괄호 {} 안의 숫자와 선택적인 형식 문자열을 매칭합니다.
  • \\d+: 숫자 (0, 1, 2 등)
  • (:[^\\}]+)?: 선택적인 형식 문자열 (:yyyy-MM-dd 등)

Matcher 객체를 생성하여 입력 Format 문자열에서 이러한 패턴을 찾습니다.

Pattern pattern = Pattern.compile("\\{(\\d+)(:[^\\}]+)?\\}");
Matcher matcher = pattern.matcher(format);

3. 값과 형식 저장을 위한 맵 생성

paramValueMap과 paramFormatMap이라는 두 개의 HashMap 객체를 생성하여 매개변수 값과 해당하는 형식 포맷터를 저장합니다.

Map<Integer, Object> paramValueMap = new HashMap<>();
Map<Integer, java.text.Format> paramFormatMap = new HashMap<>();

4. 매개변수 반복 처리

제공된 매개변수 (params) 각각에 대해 반복하여 다음을 수행합니다:

• 매개변수 값 저장: paramValueMap에 저장합니다.
• 포맷터 결정: getFormatter 메서드를 사용하여 매개변수에 대한 적절한 포맷터를 결정하고, 이를 paramFormatMap에 저장합니다.

  for (int i = 0; i < params.length; i++) {
    Object obj = params[i];
    paramValueMap.put(i, obj);
    paramFormatMap.put(i, obj != null ? getFormatter(obj, null) : null);
  }

  5. 형식 문자열의 자리 표시자 처리

  형식 문자열에서 자리 표시자가 있는 동안 다음을 수행합니다

패턴 문자열 ({index[:format]})을 추출합니다. Convert.toInteger(matcher.group(1))을 통해 자리 표시자의 인덱스를 가져옵니다. 자리 표시자에 해당하는 형식 문자열 (idxFormat)을 가져옵니다. paramValueMap에서 인덱스에 해당하는 값을 가져옵니다. 형식 문자열이 존재하면 이를 기반으로 포맷터를 설정하고, 그렇지 않으면 기존에 설정된 기본 포맷터를 사용합니다.

while (matcher.find()) {
    String patternString = matcher.group();
    int idx = Convert.toInteger(matcher.group(1));
    String idxFormat = matcher.group(2);

    Object val = paramValueMap.get(idx);
    java.text.Format formatter = (idxFormat != null && StringUtil.isNotEmpty(idxFormat.substring(1)))
            ? getFormatter(val, idxFormat.substring(1))
            : paramFormatMap.get(idx);

6. 문자열 대체

자리 표시자에 해당하는 값을 포맷터를 사용하여 형식화한 후, 형식 문자열의 자리 표시자를 실제 값으로 대체합니다. 포맷터가 없으면 기본 toString()을 사용하여 값을 문자열로 변환합니다.

    Object replaceValue = (val == null ? "null" : val);
    String replacement = (replaceValue != null && formatter != null) 
                         ? formatter.format(replaceValue) 
                         : Convert.toString(replaceValue);

    int start = result.indexOf(patternString);
    if (start != -1) {
        result.replace(start, start + patternString.length(), replacement);
    }
}

7. 결과 반환

형식화된 최종 문자열을 반환합니다.

return result.toString();

getFormatter 메서드

목적

getFormatter 메서드는 값의 데이터 유형과 형식 문자열 (formatExp)에 따라 적절한 포맷터 객체를 생성합니다.

동작

• 값의 클래스 이름에 따라 적절한 포맷터를 생성합니다.

• 예를 들어, Date 객체는 SimpleDateFormat을 사용하고, Integer, Double, Float, Long 등의 숫자 타입은 DecimalFormat을 사용합니다.

• 문자열과 boolean의 경우, 추가적인 포맷터는 필요하지 않으므로 기본값으로 처리됩니다.

  private static java.text.Format getFormatter(Object value, String formatExp) {
    if (value == null) return null;
    String className = value.getClass().getName();
  
    switch (className) {
        case "java.util.Date":
            return StringUtil.isNotEmpty(formatExp) ? new java.text.SimpleDateFormat(formatExp) : new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        case "java.lang.Integer":
            return StringUtil.isNotEmpty(formatExp) ? new DecimalFormat(formatExp) : new DecimalFormat("###,##0");
        case "java.lang.Double":
        case "java.lang.Float":
        case "java.lang.Long":
        case "java.math.BigDecimal":
            return StringUtil.isNotEmpty(formatExp) ? new DecimalFormat(formatExp) : new DecimalFormat("###,##0.##");
        default:
            return null;
    }
  }

  결론

  다양한 데이터 유형과 형식화를 지원하기 위해 만들었습니다. 사용자 정의 형식 문자열을 쉽게 처리할 수 있도록 합니다. Java에서 문자열 포맷팅을 보다 유연하게 관리하고 싶다면, 이와 같은 사용자 정의 함수를 활용해 보세요!

이번에 닥친 오류는

invalid comparison: java.util.Arrays$ArrayList and java.lang.String XML 리스트 비교연산자 오류

리스트 형태의 파라미터를 !=, == 연산자로 리스트의 공백여부를 비교하려고 했기 때문이다.

다른 글들에서는 파라미터명.size() != 0 으로 하라고 하는데 파라미터명.isEmpty()도 가능하다. 참고로 .equals('') => 이것도 오류는 안나지만, 옳은 비교가 아니다(의미없는 비교). 이유는 리스트 객체와 '' 값을 비교하기 때문. 늘 false를 반환한다.

<select id="selectItems" parameterType="java.util.List">
  SELECT * FROM items
  WHERE item_id NOT IN
  <if idList != null and !idList.isEmpty()>
    <foreach collection="idList" item="id" index="index"  open="(" separator="," close=")">
      #{id}
    </foreach>
  </if>
</select>
<!--혹은 -->
<select id="selectItems" parameterType="java.util.List">
  SELECT * FROM items
  WHERE item_id NOT IN
  <if idList != null and idList.size != 0>
    <foreach collection="idList" item="id" index="index"  open="(" separator="," close=")">
      #{id}
    </foreach>
  </if>
</select>

요약

SQL에서는 != 연산자가 단일 값과의 비교에 사용되며, 리스트와 같은 컬렉션 형태와 비교할 수 없습니다. 따라서, MyBatis에서 리스트 형태의 파라미터를 사용하여 != 조건을 작성하려고 하면 SQL 문법 오류가 발생합니다.

배열을 조작하고 변환하기 위한 고차 함수(higher-order function)로, 배열의 각 요소에 대해 특정 작업을 수행하는 데 사용됩니다. 이러한 함수들은 JavaScript의 배열 메서드로, 순회(iteration), 필터링(filtering), 변환(transformation) 등의 작업을 쉽게 수행할 수 있도록 도와줍니다. 이들은 함수형 프로그래밍의 개념을 지원하며, 코드를 더 간결하고 읽기 쉽게 만들어줍니다.

1. map 메서드

개념: map은 배열의 각 요소에 대해 제공된 함수를 호출하고, 그 결과를 모아 새로운 배열을 생성합니다. 원래 배열을 변경하지 않고, 항상 원본 배열과 동일한 길이의 새로운 배열을 반환합니다. 사용 목적: 배열의 모든 요소에 동일한 작업을 수행해야 할 때 사용합니다. 예를 들어, 숫자 배열의 모든 요소에 2를 곱하거나, 문자열 배열의 모든 요소를 대문자로 변환할 때 유용합니다.

• 예제

  const numbers = [1, 2, 3, 4, 5];
  const doubledNumbers = numbers.map((number) => number * 2);
  console.log(doubledNumbers); // [2, 4, 6, 8, 10]

  이 예제에서 map은 number * 2라는 함수를 배열의 각 요소에 적용하고, 그 결과를 doubledNumbers라는 새로운 배열에 저장합니다.

2. filter 메서드

개념: filter는 배열의 각 요소에 대해 제공된 함수를 호출하고, 함수가 true를 반환하는 요소들만 모아 새로운 배열을 생성합니다. 원래 배열을 변경하지 않고, 조건에 맞는 요소들로만 구성된 새로운 배열을 반환합니다. 사용 목적: 배열에서 특정 조건을 만족하는 요소들만 추출하고자 할 때 사용합니다. 예를 들어, 짝수만 추출하거나, 특정 문자열을 포함하는 요소만 걸러낼 때 유용합니다. 예제

const numbers = [1, 2, 3, 4, 5];
const evenNumbers = numbers.filter((number) => number % 2 === 0);
console.log(evenNumbers); // [2, 4]

이 예제에서 filter는 number % 2 === 0이라는 함수를 배열의 각 요소에 적용하고, 짝수만 evenNumbers라는 새로운 배열에 저장합니다.

3. 그 외 자주 사용되는 배열 메서드 JavaScript에는 map과 filter 외에도 배열을 다루기 위한 다양한 메서드가 있습니다.

3. reduce 메서드

개념: reduce는 배열의 각 요소를 순회하며 누적 결과를 계산합니다. 누적 결과는 배열의 모든 요소를 함수에 적용한 결과로, 단일 값이 됩니다. 이 메서드는 배열을 단일 값으로 줄이는 데 유용합니다. 사용 목적: 배열의 합계, 곱셈, 평균 등을 계산하거나 객체를 그룹화할 때 사용합니다. 예제

const numbers = [1, 2, 3, 4, 5];
const sum = numbers.reduce((accumulator, currentValue) => accumulator + currentValue, 0);
console.log(sum); // 15

이 예제에서 reduce는 accumulator + currentValue라는 함수를 배열의 각 요소에 적용하여 전체 요소의 합을 계산합니다.

4. forEach 메서드

개념: forEach는 배열의 각 요소에 대해 주어진 함수를 호출하지만, 반환 값이 없으며 새 배열을 생성하지 않습니다. 사용 목적: 배열의 각 요소에 대해 어떤 작업을 수행해야 하지만, 결과가 필요하지 않은 경우 사용합니다. 예를 들어, 배열의 요소를 콘솔에 출력하거나 DOM 조작을 수행할 때 유용합니다. 예제

const numbers = [1, 2, 3, 4, 5];
numbers.forEach((number) => {
  console.log(number);
});

이 예제에서 forEach는 배열의 각 요소를 순회하며 콘솔에 출력합니다.

5. find 메서드

개념: find는 배열에서 주어진 조건을 만족하는 첫 번째 요소를 반환합니다. 조건을 만족하는 요소가 없으면 undefined를 반환합니다. 사용 목적: 배열에서 특정 조건을 만족하는 첫 번째 요소를 찾을 때 사용합니다. 예제

const numbers = [1, 2, 3, 4, 5];
const firstEvenNumber = numbers.find((number) => number % 2 === 0);
console.log(firstEvenNumber); // 2

이 예제에서 find는 조건 number % 2 === 0을 만족하는 첫 번째 요소(짝수)인 2를 반환합니다.

6. some 메서드

개념: some은 배열의 요소 중 하나라도 주어진 조건을 만족하는지 검사하여, 만족하면 true, 만족하지 않으면 false를 반환합니다. 사용 목적: 배열에 특정 조건을 만족하는 요소가 하나라도 있는지 검사할 때 사용합니다. 예제

const numbers = [1, 2, 3, 4, 5];
const hasEvenNumber = numbers.some((number) => number % 2 === 0);
console.log(hasEvenNumber); // true

이 예제에서 some은 배열에 짝수가 하나라도 있는지 검사하고, true를 반환합니다.

7. every 메서드

개념: every는 배열의 모든 요소가 주어진 조건을 만족하는지 검사하여, 모두 만족하면 true, 하나라도 만족하지 않으면 false를 반환합니다. 사용 목적: 배열의 모든 요소가 특정 조건을 만족하는지 확인할 때 사용합니다. 예제

const numbers = [1, 2, 3, 4, 5];
const allEvenNumbers = numbers.every((number) => number % 2 === 0);
console.log(allEvenNumbers); // false

이 예제에서 every는 배열의 모든 요소가 짝수인지 검사하고, 하나라도 짝수가 아니기 때문에 false를 반환합니다.

결론

JavaScript의 배열 메서드(map, filter, reduce, forEach, find, some, every 등)는 배열 요소를 조작하고 변환하는 작업을 간결하고 직관적으로 수행할 수 있도록 도와줍니다.

setTimeout이란?

• 일정 시간이 지난 후에 특정 함수를 실행하도록 예약하는 메서드

  코드

  setTimeout(function, delay, ...args)

• function: 지연 시간 후에 실행될 함수.
• delay: 지연 시간(밀리초 단위, 1000ms = 1초).
• ...args: 실행될 함수에 전달될 선택적 인수.

setTimeout(() => {
    console.log("3초 후에 이 메시지가 출력됩니다.");
}, 3000); 

• 위처럼 콜백함수로 바로 작성하여 개발하는 경우가 많다.

  function sum(a, b) {
    console.log(a + b);
  }
  

setTimeout(sum, 1000, 5, 10); // 1초 후에 "15"가 출력됩니다.

- 또, 스크립트에 이미 개발해놓은 함수에 파라미터를 추가하여 호출 및 전달하여도 된다.

### setTimeout을 동기화처리에 활용
- 비동기처리는 다양한 이유(실시간데이터처리, 병렬작업, api호출, 이벤트리스너)로 사용자경험을 개선하는데 도움을 줍니다.
- api호출 후 코드들을 동기화처리 하기 위해서 간단하게 setTimeout을 활용할 수 있습니다.
- 이 때, 특정 밀리초를 파라미터로 전달하게 되면 api응답 전에 지정한 시간이 지나버려 꼬여버릴 수 있습니다.
- 시간 **파라미터를 0 혹은 생략하게 되면, 비동기 API 호출을 수행한 이후의 작업이 순차적으로 실행됩니다.**
- 예시

function fetchData(url, callback) { console.log("API 호출 시작...");

// 비동기 API 호출
fetch(url)
  .then(response => response.json())
  .then(data => {
    console.log("API 호출 완료. 데이터:", data);
  })
  .catch(error => console.error("API 호출 에러:", error));
//이후 setTimeout호출로 api호출이 끝난 후 callback함수실행
setTimeout(() => {
   callback(data);
}, 0); // 0ms의 지연 시간으로 콜백 호출

}

풀이

1. comparator 만들어서 풀어주면됩니다.
2. 익명클래스이기 때문에 람다식으로 오버라이드 메소드를 간단하게 구현해줬습니다.

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Arrays;


public class Bj11651_AlignCoordinate2 {
    public static void main(String[] args) throws IOException {
        BufferedReader br  = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine());
        int[][] arr = new int[n][2];
        for(int i = 0; i< n; i++) {
            String[] s = br.readLine().split(" ");
            arr[i][0] = Integer.parseInt(s[0]);
            arr[i][1] = Integer.parseInt(s[1]);
        }

        Arrays.sort(arr,(e1,e2) -> {
            if(e1[1] ==e2[1]) {
                return e1[0] - e2[0];
            } else {
                return e1[1] - e2[1];
            }
        });
        for(int i = 0 ; i < n ; i ++){
            System.out.println(arr[i][0] + " " + arr[i][1]);
        }
    }
}

풀이

1. 가운데 있는 게 가장 효율적입니다.
2. 배열의 가운데 값을 제출 해주면 됩니다.

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Arrays;

public class Bj18310_antenna {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine());
        String[] s = br.readLine().split(" ");
        int[] arr = new int[n];
        for (int i = 0; i< n ; i++){
            arr[i] = Integer.parseInt(s[i]);
        }
        Arrays.sort(arr);
        System.out.println(arr[(n-1)/2]);
    }
}

풀이

1. 어떻게 묶어서 차이를 계산할지 보다는 나열해서 일정한 규칙이 나오는지 확인해보면 됩니다.
2. 처음에는 수식을 어떻게 세워야할까 고민했습니다.
3. 최소를 구하는 것이기 때문에 각 숫자간 차이를 정렬합니다.
4. k묶음에서 k가 커질수록 한개 = 한묶음이 많아져서 최소 숫자가 작아집니다.
5. 이규칙을 활용해 k묶음일 때 각 숫자간 차이를 더해서 출력해주면 됩니다.

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.StringTokenizer;

public class Bj13164_happy {


    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st;
        st = new StringTokenizer(br.readLine());
        //입력값 받기
        int n = Integer.parseInt(st.nextToken());
        int k = Integer.parseInt(st.nextToken());
        //원생 초기화
        int[] arr = new int[n];
        st = new StringTokenizer(br.readLine());
        int cnt = 0;
        while(st.hasMoreTokens()) {
            arr[cnt] = Integer.parseInt(st.nextToken());
            cnt++;
        }
        //숫자간 차이 초기화 
        int[] answer = new int[n];
        answer[0]=0;
        for(int i = 1 ; i < n ; i++) {
            answer[i] = arr[i]- arr[i-1];
        }
        Arrays.sort(answer);
        int sum = 0;
        for(int i = 0 ; i < n-k+1 ; i++) {
            sum += answer[i];
        }
        System.out.println(sum);

        //예를들어.. n = 5개임
        //-> 1개로 묶을 시 n, 0 1 2 2 4
        //-> 2개로 묶을 시 n - 1, 0 1 2 2
        //-> 3개로 묶을 시 n - 2, 0 1 2
        //-> 4개로 묶을 시 n - 3, 0 1
        //-> 5개로 묶을 시 n - 4, 0

    }

}