⏰ 퀵라벨타이머 (QuickLabelTimer)

플랫폼·기술: iOS 앱, SwiftUI 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함 GitHub: https://github.com/data-sy/quick-label-timer

이번 주에 한 일

드디어 앱을 출시했다. 🎉🎉🎉 지난 두 달간의 여정이 이렇게 마무리되었다.

[ 주요 작업 요약 ]

• 앱 심사 리젝 대응 및 재제출
• 출시 이후로 보류해 둔 아이디어들 정리하기

심사를 한 번에 통과한 건 아니었다. 리젝됐을 때 두 가지 피드백을 받았는데,

• 피드백1: 백그라운드 오디오 옵션 오디오 옵션이 켜져 있는데 실제 앱에서는 오디오 세션을 사용하지 않는다는 피드백을 받았다. 사실 예전 정책 때문에 켜둔 걸 그대로 두었던 건데, 정책이 바뀐 뒤에는 옵션도 같이 꺼야 한다는 걸 놓쳤다. 와 이렇게 디테일하게 점검하다니… 개발 과정에서 Suspended*문제(링크 연결 예정)를 다룰 때도 느꼈지만, Apple은 *사용자 기기 리소스 관리**에 진심인 것 같다.

• 피드백2: iPad 미리보기 스크린샷 기본 설정으로 iPad 지원 옵션이 켜져 있었는데, 제출한 미리보기 이미지는 아이폰 화면이라서 불일치 문제가 발생했다. 이 옵션을 끄고 다시 제출했다.

이렇게 수정하고 다시 제출하니 통과!!! 드디어 한국 마켓에 앱이 올라왔다. 내가 필요하다고 생각했던 앱을 직접 만들어 스토어에 내놓으니 신기했다. 다른 아이디어들도 얼른 현실화 시켜보고 싶다.

👉 App Store에서 퀵라벨타이머 확인하기

재제출 후에는, 지금까지 Inbox에 쌓아뒀던 리팩토링·기능 아이디어들을 다시 정리했다. 지난 두 달 개발을 하면서, 개선은 개발자 추측이 아니라 사용자 반응과 데이터를 기반으로 해야 한다는 걸 배웠다. 그 시각으로 보니 지금은 맞지 않는 아이디어도 있었고, 반대로 당시에는 보류했지만 지금 보니 괜찮아 보이는 것도 있었다. 그래서 우선순위를 새로 정리했고, 아이젠하워 매트릭스를 활용해 시급성과 중요도에 따라 분류했다. 앞으로는 그 우선순위에 맞춰 하나씩 개선해 나갈 예정이다.

배운 점

• Apple 심사에서 배운 ‘사용자 중심’ 시각
  리젝 사유가 모두 사용자 리소스 낭비 방지, 경험 최적화와 관련 있었다. Apple은 개발 편의보다 사용자 경험을 최우선으로 한다는 걸 다시 한 번 깨달았다.
• 기록의 가치 Inbox에 그때그때 적어둔 아이디어들이 시간이 지나 다시 보니 의외로 도움이 되었다. 즉흥적인 기록도 결국은 다시 꺼내볼 만한 자원이 된다는 걸 알았다.
• 출시는 끝이 아니라 시작 앱이 올라갔다고 끝난 게 아니라, 이제부터는 사용자 반응과 데이터를 기반으로 개선을 이어가야 한다. 사용자 반응을 어떻게 수집할 수 있을지 고민해봐야겠다.

다음 주에 할 일

• 영어권으로 확장 출시 준비
• 앱 홍보 채널 만들기

⏰ 퀵라벨타이머 (QuickLabelTimer)

플랫폼·기술: iOS 앱, SwiftUI 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함 GitHub: https://github.com/data-sy/quick-label-timer

이번 주에 한 일

이번 주는 남은 버그와 Warning을 해결하고 로그 시스템과 접근성을 붙여 v1.0.0 개발을 마무리했다. 그리고 스토어에 올릴 메타데이터(제목, 설명, 미리보기 등)를 준비해서 해 드디어 심사를 제출했다.

[ 주요 작업 요약 ]

• 버그 개선 및 Warning 정리
• 로그 시스템 Crashlytics 연동
• VoiceOver 접근성 추가
• 스토어 메타데이터 작성 및 심사 제출

이전 프로젝트인 MMT 웹사이트를 개발할 때는 의식하지 못했지만, 앱을 만들면서 새롭게 챙겨야 하는 부분들이 있었다. 웹은 사용자가 내 서버에 “접속”하지만, 앱은 프로그램이 사용자의 기기에 “설치”되기 때문이지 않을까 싶었다. 먼저, 강제 종료 같은 크래시는 서버에 기록이 남지 않기 때문에 따로 수집기가 필요하다. 그래서 Firebase Crashlytics를 연동했다. 또 시각장애인이나 화면을 보지 않고 조작하는 상황을 고려해 VoiceOver 접근성을 지원했다. 기능만 구현하는 걸 넘어서서 접근성을 함께 챙기며 다양한 사용자를 고려해야 함을 알게 되었다.

이렇게 구현을 마무리한 뒤 앱스토어에 제출하기 위해 제목, 소개글, 브랜드네임 등의 메타데이터를 준비했다. 특히 브랜드네임을 정할 때 AI가 많은 도움이 되었다. 저작권 문제가 없으면서, 검색하기 어렵지 않으면서, 적당히 기억에 남는 이름을 찾아야 했는데😵 혼자 만들었다면 정말 오래 걸렸을 것 같다. AI는 내가 원하는 느낌이 나올 때까지 끝없이 이름을 뽑아내 줘서 비교적 빠르게 정할 수 있었다. 그리고 선택한 이름이 혹시 저작권에 문제가 되지는 않는지, 부정적인 밈이나 속어로 쓰이고 있지는 않은지 등을 Gemini의 딥리서치로 검증하였다. 최종적으로 OddMuffin이라는 귀여운 브랜드명을 갖게 되었다. 미리보기 이미지는 Figma로 작업했다. iOS에서 제공하는 공식 컴포넌트를 활용해 보면서 Figma에 대해서도 더 알게 되었고, 개발과는 또 다른 재미가 있었다.

배운 점

• 웹과 앱의 차이 웹 개발에서는 서버 로그로도 충분했지만, 앱은 사용자의 기기에서 발생하는 크래시를 별도로 수집해야 한다는 걸 알았다. 플랫폼이 달라지면 디버깅 방식도 달라지는 걸 배웠다.

• 접근성의 중요성 처음엔 기능 구현만 생각했는데, VoiceOver를 붙이면서 다양한 사용자를 고려해야 한다는 걸 알았다. “작동하는 것”과 “누구나 쓸 수 있는 것”은 다르다. 다음 개발에서도 이런 점을 고려하는 습관을 들여야겠다.

• iOS 업데이트와 유지보수 앱 제출 직후 iOS26 리퀴드 글래스로 디자인 업데이트가 일어나 기존 레이아웃이 깨지는 걸 발견했다. 출시 후에도 꾸준한 유지보수가 필요하다는 걸 실감했다.

다음 주에 할 일

• 심사 결과를 기다리며, 출시 이후로 보류해 둔 아이디어들 정리하기
• 리젝 될 경우, 피드백에 맞춰 수정하고 재제출하기

⏰ 퀵라벨타이머 (QuickLabelTimer)

플랫폼·기술: iOS 앱, SwiftUI 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함 GitHub: https://github.com/data-sy/quick-label-timer

이번 주에 한 일

이번 주는 버그 수정과 리팩토링을 주로 진행했다. 그 과정에서 알림 동작과 관련된 예상치 못한 문제를 발견했고, 정책을 조금 더 안정적인 방향으로 바꾸게 되었다. 출시 전에 발견해서 다행이었다.

[ 주요 작업 요약]

• 주요 버그 해결
• 타이머, 프리셋 정책 재정의 (영속성, 속성, 개수 제한)
• 정책 변경에 따른 사이드 이펙트

버그를 해결하는 과정은 연쇄적인 결정의 흐름으로 이어졌다. 예를 들어,

[예시 1] 앱을 강제 종료하면 실행 중이던 타이머는 사라지는데, 예약된 알림은 그대로 울려버리는 문제 → 이를 개선하기 위해 앱 재실행 후에도 타이머를 유지하기로 했고, → 그러려면 영속성(UserDefaults) 로직을 추가해야 했으며, → 타이머가 남아있게 되니 프리셋을 숨기는 대신 실행 중 상태로 덮는 오버레이 방식으로 UI를 변경했고, → 오버레이 방식에서의 최신순 정렬은 공간적 일관성이 깨져 보여서, 정렬 기준을 최신순에서 생성순으로 바꿔야 했다.

[예시 2] 알림 개수에는 시스템 한계가 있으므로 실행 중인 타이머 개수를 5개로 제한하기로 함 → 타이머는 최대 5개인데, 즐겨찾기를 무제한 저장하는 건 UX적으로 어색하니 즐겨찾기 개수도 20개로 제한을 두기로 했고, → 그러다 보니 기존 모델 구조(Bool isFavorite)로는 다음 버그를 해결하기 복잡했다.

즐겨찾기가 19개 저장된 상태에서 실행중인 타이머 5개를 즐겨찾기 토글(⭐️)로 예약 할 수 있음. 이 때문에 사용자는 20개 이상 프리셋을 저장할 수 있다고 착각하지만, 실제로 저장 버튼을 누를 때 제한에 걸려 실패. 결국 UI와 데이터 상태가 불일치하는 버그 발생

→ 그래서 속성을 Enum endAction으로 바꾸어 상태를 더 명확히 표현했고, → 그 결과 데이터 마이그레이션, 모델 관련 로직 전면 수정이 뒤따랐다.

하나의 버그 수정에서 예상하지 못했던 사이드 이펙트들이 팡팡 터졌다. 마치 100층짜리 탑에서 99층을 고치려다 10층이 흔들리는 느낌이랄까? 앱이 완성에 가까워질수록 작은 수정이 전체 구조에 큰 파장을 미친다는 걸 실감한 한 주였다.

배운 점

• 문제 재정의 iOS 정책은 내가 바꿀 수 없는 부분이 많다. 억지로 뚫으려다 막히기보다는, 문제를 관점 전환으로 풀어내 재정의함으로써, 버그를 기능처럼 녹여내는 방법이 더 효과적이었다. 그렇게 해서 “버그처럼 보였던 걸 버그가 아닌 걸로 만든” 셈인데, 앞으로도 이런 시각이 필요하다고 느꼈다.
• 버그 수정의 연쇄 효과 하나의 버그를 잡으면 끝나는 게 아니라, 그 수정이 또 다른 문제를 불러온다는 걸 뼈저리게 느꼈다. 정책을 고치다 보니, 데이터 구조를 손봐야 했고, 거기에 맞춰 UX까지 바꿔야 했다. 버그 하나를 고칠 때, 뒤따라올 사이드 이펙트까지 고민해보는 습관을 가져야겠다.
• AI를 통해 초급자도 중•고급 단계의 지식을 경험할 수 있음 사실 나는 리팩토링에 패턴 이론이 있다는 것조차 몰랐다. 그런데 AI에게 “모델의 속성을 안전하게 바꾸는 방법이 있을까?”라고 물어봤더니, 마틴 파울러의 리팩토링 패턴 중 하나인 Parallel Change(병렬 변경)를 알려주었다. 그제서야 “아, 디자인 패턴처럼 리팩토링에도 정식으로 이름 붙은 방법론이 있구나”라는 걸 알게 되었다. 이 경험을 통해, 지식을 선형적으로 쌓아가는 게 아니라 필요한 순간 필요한 지식을 경험할 수 있다는 것이 AI의 큰 장점이라는 걸 느꼈다.

다음 주에 할 일

이번 주에 진행하려 했으나 버그 수정 규모가 커서 한 주 미룬 작업들:

• Crashlytics 에러 로깅 추가, 접근성 개선
• 사운드 음원 정책(3초)에 맞춘 편집
• 스토어 메타데이터 준비

⏰ 퀵라벨타이머 (QuickLabelTimer)

플랫폼·기술: iOS 앱, SwiftUI 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함 GitHub: https://github.com/data-sy/quick-label-timer

이번 주에 한 일

이번 주에는 드디어 알람 기능을 마무리했다! 지난주에 정리한 정책대로 '로컬 알림을 짧은 간격으로 연속 울리기'방식을 적용했고, 그 과정에서 파생된 UI 정책 수정까지 함께 진행했다.

**[ 주요 작업 요약 ] **

• 로컬 알림 기반 알람 기능 구현
• 소리·진동 UI 정책 수정 (4가지 → 3가지 선택지로 단순화)

지난주에 단위 테스트와 실기기 동작이 달랐던 경험이 있어서, 이번에는 실기기에서 직접 가설을 검증하는 방식을 썼다. 예를 들어, *"제목·본문 없이 sound만 넣은 알림은 배너가 안 뜨고 소리만 울릴 것이다"* 라는 가설을 세웠지만, 실제 결과는 배너 자체가 뜨지 않았다.

두 케이스는 예약(pending_count) 수치는 동일하지만, 배달(delivered_count)에서 차이를 보인다.

• 제목, 본문 모두 nil 또는 “” 일 때: 예약은 정상적으로 되었지만, 실제 알림은 도착하지 않음 (delivered_count=0)

• 본문을 넣었을 때: 알림이 정상적으로 배달됨 (delivered_count=9)

즉, '알림이 정상적으로 울리려면 제목과 본문 중 최소 하나는 반드시 포함되어야 한다'는 사실을 확인할 수 있었다. 코드 단위테스트만 했다면 “예약이 됐으니 성공이다”라고 착각했을 텐데, 실기기 단위 검증 덕분에 미리 문제를 발견할 수 있었다. 이런 검증 과정을 거쳐 사용 가능한 기능과 불가능한 기능을 정리했고, 그에 따라 백그라운드, 포그라운드, 엣지케이스 각각에 맞는 정책을 마련할 수 있었다.

또 하나 재미있었던 포인트는 소리·진동 조합 문제였다.

원래는 사용자가 소리/진동을 각각 On·Off로 고를 수 있게 하려 했는데, 로컬 알림으로 정책을 바꾸니 “소리 O·진동 X”을 선택하면, 무음 모드일 때 정반대로 “소리 X·진동 O”이 울리는 상황이 벌어졌다. 😂 혼란스러운 UX이므로 최종적으로는 옵션을 소리 / 진동 / 무음 3가지만 제공하는 걸로 단순화했다.

	➔

배운 점

• 실기기 테스트의 중요성 이번 경험은 지난주에 겪었던 Suspended 상태 이슈와도 맞닿아 있다. 코드 단위테스트로 예약 성공 여부까지는 확인할 수 있지만, 실제 기기에서는 iOS 정책과 환경 변수 때문에 코드상으론 정상인데 실제론 동작하지 않는 경우가 발생했다. 알람 기능 구현 과정을 통해, 핵심 기능은 실기기 검증을 병행해야 한다는 걸 확실히 배웠다.
• 문서화의 힘 ADR 문서로 과정과 근거를 남겨두니, 정책을 바꿀 때 훨씬 수월했다. “왜 이 결정을 했는가”를 설명할 필요 없이 기록을 찾아보고 맥락을 바로 파악할 수 있었다. 다음부터도 중요한 변화가 있을 때는 기록을 잘 해두어야겠다.
• 아키텍처의 힘 지난주에 적용한 클린 아키텍처가 이번 구현에 큰 도움이 됐다. 각 클래스 역할이 명확히 분리돼 있어서, 어떤 기능을 어디에 넣어야 할지 고민이 줄었고, 복잡한 문제도 작은 단위로 나눠 해결할 수 있었다.

다음 주에 할 일

• 남은 자잘한 버그들 수정
• 크래시, 접근성 등의 마무리 작업
• 스토어 메타데이터 준비 - 출시 가즈아 🚀

관련 문서

• [ADR-012] Suspended 상태 대응을 위한 백그라운드 알람 정책
• [ADR-013] 백그라운드 알람 정책과의 일관성을 위한 포그라운드 알람 정책

⏰ 퀵라벨타이머 (QuickLabelTimer)

플랫폼·기술: iOS 앱, SwiftUI 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함 GitHub: https://github.com/data-sy/quick-label-timer

이번 주에 한 일

이번 주는 삽질의 주였다.😭 앱의 핵심 기능인 알람 기능 구현에 도전했고, 지난주에 경험한 SRP 원칙을 적용해 보고자 클린 아키텍처 리팩토링을 진행했다.

[ 주요 작업 요약 ]

• 알람 기능 구현 시도
• 클린 아키텍처 적용 (TimerManager → Repository & Service 분리)

1. 알람 기능

알람 기능을 구현할 때 가장 중요한 건 무엇일까?

(간격 주는 용도의 짤. 넣을 예정)

바로 애플워치를 벗는 것이다!! 단위 테스트도 잘 통과하고 시뮬레이터에서도 문제없었는데, 정작 실기기에서 소리가 안 났다. 혹시 iOS 정책 때문인가 싶어 헤맸는데…원인은 단순했다. 내가 워치를 차고 있었던 것 😱 (워치를 착용하면 iPhone 알림은 Apple Watch로 라우팅 된다)

iOS에서 알람 기능을 만드신다면, local notification을 테스트할 때 아래 항목은 꼭 체크해 보시길…

• 애플워치를 벗었는지
• 무음 모드이진 않은지
• 소리 볼륨이 0은 아닌지

이제 실제 구현 과정을 회고하자면, 그야말로 삽질의 연속이었다. 처음엔 정책을 이렇게 정리했다.

• 시각적 신호: 로컬 알림
• 소리·진동: 오디오 세션

화면에는 로컬 알림이 배너로 뜨고, 소리와 진동은 오디오 세션을 통해 사용자가 확실히 인지할 때까지 울리도록 설계했다. (이미지 위치 조절 예정)

단위 테스트도 잘 통과하고, 간단한 실기기 테스트에서도 정상적으로 동작했다. “됐다!” 싶었던 순간…

타이머 시간을 조금 길게 설정하자, 소리·진동이 울리지 않았다.

원인은 바로 iOS의 Suspended 상태였다. iOS는 앱이 사용되지 않으면 자동으로 Suspended 상태로 전환하고 개발자는 임의로 이 진입을 막을 수 없다. 애플이 허용한 일부 백그라운드 모드에서만 제한적으로 실행을 이어갈 수 있는데, 알람 어플은 해당 사항이 없다. 즉, 앱이 한 번 Suspended로 전환되면 실행이 완전히 멈추기 때문에, 오디오 세션을 실행시키는 함수가 호출 자체가 안 된 것이다. 어쩐지 구글링을 해도, 스택 오버플로우를 디깅해도 정보가 없더라니… “시중 앱에서 가능하니까 방법이 있겠지” 생각하고 넘긴 게 안일한 판단이었다. 눈물이 앞을 가리니 더 이상의 자세한 설명은 생략한다... 👉 삽질 기록은 여기... (추가 예정)

최종적으로, 사용자 기기 설정(무음 모드, 소리 볼륨 등)에 영향을 받지 않는 알람 앱을 만들기 위해 피할 수 없는 정책적/기술적 관문은 다음과 같다.

• iOS는 서드파티 알람 앱에 엄격하다. (2024.12)
• 백그라운드 유지 기법 없이는 사실상 구현이 어렵다.
• 실제로, 업계 1위 알람 앱도 백그라운드 유지 기법을 사용하는 것으로 보인다. (Alarmy 대표님이 블로그 글에서 직접 언급한 바 있다.(2018) 현재도 앱을 강제 종료하면 _“앱이 꺼지면 알람이 안 울려요”_라는 로컬 알림이 뜨는 걸 보면, 이 방식은 여전히 유지되고 있는 것으로 추측된다.)

구현 방식 정리

이 제약을 고려해 떠올린 시나리오는 이랬다:

1. 외부 푸시 알림으로 타이머 종료 시간 5분 전 앱을 깨우기
2. 5분간 무음 사운드를 재생해 앱이 Suspended 상태가 되지 않도록 유지
3. 타이머 종료 시점에 오디오 세션으로 알람 울리기

하지만 이 방식은 구현 과정에서 실패할 가능성이 있고, iOS 정책을 우회하는 방법이라 리젝 리스크가 있어 고민이 되었다. 이때, 지난주 회고에서 정리했던 말이 떠올랐다. 좋은 UX는 머릿속 상상이 아니라 실제 피드백으로 검증된다. 기능 구현도 마찬가지일 것이다. 이번에는 ‘완벽 대신 완성’을 모토로, 우선 *로컬 알림 기반 MVP를 * 내기로 결정했다.

• 장점: iOS가 예약·발송하므로 Suspended 상태에서도 알림 가능
• 단점: 기기 설정에 종속 (무음모드, 소리볼륨 등)
• 대안: 무음 모드 시, 소리가 울리지 않는다고 사용자에게 안내

2. 클린 아키텍처 적용

지난주에 SRP의 중요성을 크게 느낀 뒤, 이번 주에는 아키텍처 개선을 시도했다.

• TimerManager의 책임을 Repository와 Service로 분리
• 파일 네이밍도 아키텍처 규칙에 맞는지 점검

완벽하게 원칙을 따르려면 더 작은 단위(엔진 등)까지 쪼갤 수 있었지만, 지난 2주 동안 경험했듯이 과도하게 깊이 파고들면 우선순위가 밀린다는 걸 알았다. 그래서 이번에는 Service/Repository 수준까지만 분리하고 마무리했다. (이전 아키텍처 다이어그램 → 새로운 아키텍처 다이어그램 첨부 예정)

이번 개선 과정에서 클린 아키텍처를 공부하며 도움이 된 블로그 링크도 함께 남겨본다. [iOS] Clean Architecture + MVVM + Observable 사용해서 날씨앱 리팩토링하기

배운 점

• 핵심 기능은 초반에 직접 검증하자. “시중 앱들이 다 되니까 나도 되겠지”라는 안일한 생각이 큰 삽질로 이어졌다. 이번 일을 통해 핵심 기능은 반드시 초기에 정확히 검증해야 한다는 걸 배웠다. 단순히 코드 로직뿐 아니라 기기나 환경까지(워치 착용, suspended 상태 등) 고려해야 한다는 것도 알게 되었다.
• 디버깅 능력이 좋을수록 AI 활용의 질도 높아진다. 사운드 재생 이슈에서 AI가 처음에는 다소 범용적인 답만 내놓았다. 하지만 직접 함수 호출 시점을 하나씩 디버깅하며 원인을 좁혀가니 “세션 생성 위치를 바꿔야 하지 않을까?”라는 가설에 도달할 수 있었다. 그 가설을 AI에게 제시하자, 그제야 맞는 해결책이 나와 이슈를 풀 수 있었다. 결국 AI는 답을 대신 내주는 도구가 아니라, 내가 문제를 어떻게 정의하느냐에 따라 성과가 달라지는 도구라는 걸 체감했다.

다음 주에 할 일

• 로컬 알림을 사용한 알람 정책 설계 & 구현
• 자잘하게 쌓인 버그들 정리

⏰ 퀵라벨타이머 (Quick Label Timer)

• 플랫폼·기술: iOS 앱, SwiftUI
• 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱
• 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함
• GitHub: https://github.com/data-sy/quick-label-timer

이번 주에 한 일

이번 주는 구조 리팩토링의 주였다. 정책이 변경될 때마다 기존 코드를 수정하는 일이 잦아지면서 구조의 한계가 느껴졌다. 이런 불편함을 느끼는 시점이 딱 리팩토링 할 시기라는 판단이 들었다. 출시가 좀 늦어지더라도, 이번 개발은 학습 목적도 크기 때문에 구조 설계를 고민하고 개선하는 시간을 가졌다.

[ 주요 작업 요약 ]

• 타이머 라이프사이클 정책 변경 (기본값: 보관→삭제)
  • 완료 시 n초 후 자동 삭제
  • 필요시 ‘즐겨찾기’로 보관 가능
• 단일 화면 → 복합 화면 전환
• MVVM 패턴·핸들러를 적용하여 유지보수성 향상

앱의 USP(차별 포인트) — “퀵”, “라벨”— 을 살리기 위해 세워둔 원칙은 이것이었다.

1. 타이머 생성을 첫 화면에 둘 것
2. 타이머 완료 후 확인 버튼 없이 앱 진입만으로 꺼질 것

그중 2번, 앱 진입만으로 타이머를 종료시키려다 보니 완료된 타이머를 어디로 보낼지가 고민이었다. 기존 정책은 '완료된 타이머는 자동으로 보관 목록으로 이동'이었다. 하지만 확인 버튼도 없는데 보관까지 자동으로 되면 사용자가 헷갈릴 것 같았다. 그래서 완료 시 n초 후 ‘자동 삭제’로 바꾸고, 남기고 싶은 타이머만 사용자가 직접 ‘즐겨찾기’로 보관하도록 했다. 이렇게 해서 “즐겨찾기에 추가하지 않으면 사라진다”는 흐름이 자연스럽게 전달되고, UX도 간결해졌다!!

기존의 정책에서는 ‘보관 목록으로 이동’이 보여야 해서 화면 분리가 어려웠지만, 이제는 즐겨찾기를 별도 화면으로 옮길 수 있게 되었다. 덕분에 단일 화면을 복합 화면으로 전환할 수 있었다.

정책 변경에 맞춰 리팩토링을 진행하면서 유지보수성이 왜 중요한지 뼈저리게 느꼈다. 😂😂 View에 섞여 있던 로직을 ViewModel로 분리하고, 타이머와 관련된 모든 기능을 담당하던 TimerManager에서 ‘완료 후 처리’만 따로 분리해서 Handler로 만들었다. 유지보수의 어려움을 직접 경험하고 나니 SRP(단일 책임 원칙)의미와 필요성이 확실히 와닿았다.

배운 점

• 좋은 UX는 사용자의 피드백에서 나온다. 회고를 쓰면서 이번 주를 돌아보니, 혼자 머릿속에서만 ‘완벽한 UX가 뭘까’를 오래 고민했다는 생각이 들었다. 사실 좋은 UX는 사용자의 실제 피드백을 통해 개선해 가는 것인데 말이다. 다음부터는 완벽하게 만들겠다는 생각에 너무 오래 붙잡히지 말고, 적당한 시점에서 구현해보고 검증하는 흐름을 가져가야겠다.

• 하나의 클래스, 모듈은 한 가지 역할만 수행하도록 하자.

• SRP(단일 책임 원칙)*는 하나의 클래스나 모듈이 한 가지 역할만 수행하도록 하는 설계 원칙인데, 이번 리팩토링을 통해 유지보수 과정에서 그 필요성을 몸소 체감했다.

다음 주에 할 일

• 알림 기능 만들기 4주 차 동안 리팩토링에 많은 시간을 들였지만, 그 과정에서 아키텍처 패턴을 적용하는 이유와 SRP를 지키면 좋은 점을 확실히 이해할 수 있었다. 이번 리팩토링 덕분에 다음 주 알림 기능 개발이 한층 수월해지지 않을까 기대된다.

⏰ 퀵라벨타이머 (Quick Label Timer)

• 플랫폼·기술: iOS 앱, SwiftUI
• 앱 컨셉: 시간을 빠르게 설정할 수 있는 퀵 타이머에, ‘왜 맞췄는지’를 기록할 수 있는 라벨 기능을 결합한 타이머 앱
• 개발 목적: AI-Assisted Programming을 실제 서비스 개발에 적용하여 장단점을 살펴보고, 서비스 완성 및 운영 경험을 통해 설계 능력과 문제 해결 능력을 강화하고자 함
• GitHub: https://github.com/data-sy/quick-label-timer

이번 주에 한 일

이번 주에는 타이머 수정 화면과 설정 화면을 구현했다. 그리고 그 과정에서 알림/진동 설정의 책임을 Model로 이관하는 리팩토링도 진행했다.

타이머 수정 화면 구현은 생각보다 금방 끝났다. 이전에 사용자 입력 화면을 컴포넌트 단위로 만들어 둔 덕분에, 그것들을 가져다 조립만 하면 되었다. 컴포넌트화의 효용을 몸소 체감했다. 나중에 디자인을 수정하거나 기능을 추가할 때, 입력 화면과 수정 화면을 각각 손대지 않아도 될 테니 유지보수에도 좋을 것 같다.

반면, 설정 화면 구현은 예상보다 시간이 많이 들었다. 중요도에 비해 신경 써야 할 것이 많았기 때문이다. 또 보태보태병(?)에 걸려 ‘이 기능도, 저 기능도 필요하지 않을까’하는 욕심에 계속 손이 가게 됐다. 지금 생각하면, 오히려 출시 후에 추가해도 됐겠다는 아쉬움이 남는다. 하지만, 설정의 기본 사운드 기능을 만드는 과정에서 설계 리팩토링 지점을 발견했으니 럭키비키자나~🍀

기본 사운드 설정 기능을 구현하는 과정에서, 기존처럼 별도의 UserSettings 모델을 만드는 게 맞는지 의문이 생겼다. 소리/진동의 on·off는 각 타이머가 가지는 속성이기 때문이다. 그래서 설정 관리 책임을 TimerData 모델로 이관하는 리팩토링을 진행했다. 이 과정에서 AI-Assisted Programming의 한계를 체감했다. AI가 짜주는 대로만 따라가면 세부 설계까지 챙겨주지 않기 때문에 내가 직접 설계를 고민하고, 필요한 리팩토링을 주도해야 한다는 점을 확실히 느꼈다.

배운 점

• 컴포넌트화의 힘 초반에 컴포넌트 단위로 만들어둔 덕분에, 새 화면을 추가할 때 빠르게 조립하고, 일관된 디자인을 유지할 수 있었다. 앞으로도 재사용성을 신경 써서 개발해야겠다.

• 설정 화면의 함정(?) 눈에 보이지 않는 기능이라도, 구현에 들어가는 리소스가 의외로 많을 수 있다. 앞으로는 “금방 만들 것 같다”는 이유만으로 우선순위를 올리지 않고, 정말 필요한 기능부터 차근차근 추가하는 습관을 들여야겠다.

• 설계는 내가, 코드는 AI가 AI의 도움으로 코드 작성은 빨라졌지만, 도메인을 이해하고 서비스 구조를 설계하는 일은 개발자의 몫이다. 이 주도권을 놓치지 않아야 한다는 점을 다시 한번 느꼈다.

다음 주에 할 일

• 타이머 상태 변화에 따른 UI/UX/기능의 빈틈을 개선할 예정이다.
  • 예) 타이머 종료 후 언제까지 실행 중 목록에 둘 것인지 등
• ‘실행 중 목록‘과 ’타이머 목록‘을 컨테이너를 사용해 레이아웃을 통일하려 한다.
  • AS-IS : 완료된 타이머에 깜빡임 기능을 주기 위해, 실행중 목록은 Vstack을 사용 (타이머 목록은 List)
  • TO-BE : ‘n초 후 삭제’ UX 도입으로 Vstack을 고집할 필요가 없어짐. 삭제 스와이프를 일관되게 적용하기 위해 모두 List로 변경
  • 이를 통해 유지보수가 더 쉬워질 것이다.

Spring AOP의 런타임 위빙 동작 방식을 다음 이미지 내용을 바탕으로 설명하겠습니다.

Spring AOP의 런타임 위빙 동작 과정

1. 빈 객체 생성:

   • 스프링 컨테이너는 애플리케이션 컨텍스트 초기화 과정에서 A 객체를 생성합니다.

2. 빈 후처리기 전달:

   • 생성된 A 객체는 빈 후처리기 (Bean Post Processor)에게 전달됩니다. 빈 후처리기는 스프링 컨테이너에서 빈이 생성되고 초기화된 후에 특정 작업을 수행하기 위해 사용됩니다.

3. 프록시 객체로 변환 (바꿔치기):

   • 빈 후처리기는 A 객체가 AspectJ 모듈에 정의된 포인트컷(Pointcut)에 해당하는지를 검사합니다.
   • 만약 A 객체가 포인트컷에 해당하면, 빈 후처리기는 A 객체를 프록시 객체(A 프록시)로 바꿔치기합니다. 이 프록시 객체는 AspectJ 모듈에서 정의된 로직을 가로채서 실행할 수 있도록 설계됩니다.
   • 프록시 객체는 실제 A 객체를 감싸고 있으며, A 객체에 대한 메서드 호출을 가로챕니다.

4. 프록시 객체 등록:

   • 변환된 A 프록시는 스프링 컨테이너의 빈 저장소에 beanA라는 이름으로 등록됩니다.
   • 이후 스프링 애플리케이션은 beanA를 참조할 때 A 프록시 객체를 사용하게 됩니다.

5. 프록시 객체의 메서드 호출:

   • 클라이언트가 A 프록시의 메서드를 호출하면, 프록시 객체는 메서드 호출을 가로채고, AspectJ 모듈에서 정의한 로직 (예: 로깅, 트랜잭션 관리 등)을 실행합니다.
   • 그 후 프록시 객체는 실제 A 객체의 메서드를 호출하여 원래의 비즈니스 로직을 실행합니다.
   • 최종적으로 프록시 객체는 결과를 클라이언트에게 반환합니다.

요약

• 프록시 객체 생성: 빈 후처리기에서 AspectJ 모듈의 포인트컷에 해당하는 빈을 프록시 객체로 변환합니다.
• 메서드 호출 가로채기: 클라이언트가 프록시 객체의 메서드를 호출할 때 프록시 객체는 호출을 가로채고, 추가 로직을 실행한 후 실제 메서드를 호출합니다.
• 결과 반환: 프록시 객체는 원래 메서드의 결과를 클라이언트에게 반환합니다.

이 과정을 통해 Spring AOP는 런타임 시점에서 빈에 대해 횡단 관심사를 적용하며, 코드의 모듈화와 재사용성을 높입니다.

• 웹 페이지 접속 과정
  • 심플 버전
  • 디테일 버전
• 로드밸런서
• 웹 페이지 접속 과정 - 스프링

ㅇ 웹 페이지 접속 과정 1 - 심플 버전

• 사용자가 URL(도메인)을 웹 브라우저에 입력
• 웹 브라우저는 입력한 URL을 바탕으로 DNS(Domain Name System)서버에 연결할 IP를 요청
• DNS서버는 IP주소를 웹 브라우저에게 응답으로 제공
• 웹 브라우저는 DNS서버에서 받은 IP를 통해 웹 서버와 TCP/IP 연결을 통해 세션 수립
• HTTP 요청을 보내고, 웹 서버는 받은 HTTP 요청에 응답. 응답은 웹 페이지와 필요한 리소스를 포함
• 웹 브라우저는 받은 응답을 바탕으로 사용자에게 웹 페이지를 보여줌

ㅇ 웹 페이지 접속 과정 2 - 디테일 버전

• 사용자가 URL(도메인)을 웹 브라우저에 입력
  • 브라우저의 URL 파싱 : 주소창에 입력된 문자열이 URL 형식을 띄고 있는지 확인 (아니라면 검색 기능 작동)
  • 브라우저 캐시 확인 : 브라우저 캐시에 저장된 데이터가 있다면, 서버에 접속하지 않고 캐시에서 데이터를 사용
  • HSTS 조회 : HTTP 요청은 HTTPS 요청으로 변환 (HTTP Strict Transport Security)
• 웹 브라우저는 입력한 URL을 바탕으로 DNS(Domain Name System)서버에 연결할 IP를 요청
  • 로컬 DNS 캐시 확인 : DNS 정보가 로컬 DNS 캐시에 이미 존재하고, 캐시의 TTL ( Time To Live (DNS 레코드의 캐시 유효 시간)) 값이 유효하다면, DNS 서버에 요청을 보내지 않고, 로컬 DNS 캐시에서 해당 정보를 가져옴
  • 연쇄적인 DNS 서버 조회 : Root DNS 서버 -> TLD(Top-Level Domain) DNS 서버 -> Authoritative DNS 서버를 순차적으로 조회하여 IP 주소 반환
• DNS서버는 IP주소를 웹 브라우저에게 응답으로 제공
• 웹 브라우저는 DNS서버에서 받은 IP를 통해 웹 서버와 TCP/IP 연결을 하고 세션 수립
  • IP 주소와 라우터를 이용한 웹 서버 추적 :
    • 라우팅 테이블 점검 : DNS 서버에서 획득한 IP주소가 라우팅 테이블에 존재한다면 이를 사용하여 웹 서버를 추적, 존재하지 않는다면 라우팅 알고리즘을 통해 해당 서버의 게이트웨이까지 이동
    • ARP (Address Resolution Protocol)를 통한 MAC 주소 획득 : ARP 를 통해 목적지와 실질적으로 통신을 하기위해 ARP Table 내에서 IP 주소를 MAC 주소와 매칭
  • TCP/IP 연결 : -way handshake 과정(SYN, SYN-ACK, ACK)을 통해 연결을 수립
• HTTP 요청을 보내고, 웹 서버는 받은 HTTP 요청에 응답
  • 응답은 웹 페이지와 필요한 리소스를 포함
  • 웹 서버에서 컨텐츠를 전송할 때는 로드 밸런싱(Elastic Load Balancing, ELB) 기능을 이용해 서버를 분산해 부하를 줄여줌
• 웹 브라우저는 받은 응답을 바탕으로 사용자에게 웹 페이지를 표시
  • 콘텐츠 렌더링 : 응답을 받은 웹 브라우저는 HTML, CSS, JavaScript 등의 웹 자원을 처리하여 웹 페이지를 렌더링하고 사용자에게 표시 (CSR)

ㅇ Load Balancing

• 둘 이상의 중앙처리장치/저장장치와 같은 컴퓨터 자원들에게 작업(Work), 즉, 부하(Load)를 나누는 것
  • 자원 사용 최적화
  • 처리량 극대화
  • 응답 시간 줄이기
  • 고장 허용성 보장
• Scale-out
  • 하나의 Server 보다는 여러 대의 Server가 나눠서 일을 하는 방법
  • (vs) Scale-up : Server가 더 빠르게 동작하기 위해 하드웨어 성능을 올리는 방법
  • 하드웨어 향상하는 비용보다 서버 한대 추가 비용이 더 적음
  • 여러 대의 Server 덕분에 무중단 서비스를 제공 가능
  • 여러 대의 Server에게 균등하게 Traffic을 분산시켜주는 역할을 하는 것이 Load Balancer
• 주요 기능
  • 트래픽 분산 : 트래픽을 분산시켜 각 서버의 부하를 균일하게 관리
  • 오토 스케일링 : 조건에 맞춰 필요시 server에 컴퓨터 수를 늘리거나 줄여서 부하 관리 가능 (Scale out, Scale in)
  • Health Check : 해당 포트에 트래픽을 보내 애플리케이션이 올바르게 작동하는지 여부를 판별
  • 보안 서비스: 웹 애플리케이션 방화벽(WAF)과 네트워크 주소 변환(NAT) 같은 보안 기능을 통해 외부 공격으로부터 내부 네트워크를 보호
• 종류
  • L2 : Mac주소를 바탕으로 Load Balancing
  • L3
    • 네트워크 계층 (OSI 7계층의 제 3계층)
    • IP 주소를 바탕으로 Load Balancing
    • 이 과정에서 NAT(Network Address Translation)가 사용될 수 있음
    • 네트워크 계층의 로드 밸런싱은 라우팅 결정을 기반으로 작동하며, 패킷의 전달 경로를 조정하는 역할을 함
  • L4
    • 전송 계층 (OSI 7계층의 제 4계층)
    • Transport Layer(IP와 TCP/UDP Port) Level에서 Load Balancing
    • TCP 연결 또는 UDP 흐름을 감지하고, 이를 기반으로 서버들 사이에 트래픽을 분산
    • 전송 계층의 로드 밸런싱은 세션 기반의 결정을 포함하며, 클라이언트와 서버 사이의 연결을 유지하는 데 중요한 역할을 함
  • L7 : Application Layer(사용자의 Request) Level에서 Load Balancing (HTTP, HTTPS, FTP)
  • 트래픽 분산이 목적이라면 네트워크 계층에서의 로드 밸런싱이 효과적일 수 있으며, 세션 유지가 중요한 애플리케이션에서는 전송 계층에서의 로드 밸런싱이 더 적합할 수 있음
• 로드밸런싱 알고리즘
  • 라운드 로빈 (Round Robin) : 각 서버에 순차적으로 요청을 분배하는 가장 단순한 형태의 로드 밸런싱 방법
  • 최소 연결 (Least Connections) : 연결 개수가 가장 적은 서버를 선택. 트래픽으로 인해 세션이 길어지는 경우 효과적
  • 소스 (Source) : 사용자의 IP를 Hashing하여 분배. 사용자가 항상 같은 서버로 연결되는 것을 보장

ㅇ 스프링 관점에서의 웹 페이지 접속 과정

(스프링부트, 스프링MVC 사용)

• 사용자가 URL(도메인)을 웹 브라우저에 입력
• 브라우저의 요청
  • 브라우저는 입력한 URL을 DNS를 통해 IP 주소로 변환하고, 웹 서버와 TCP/IP 연결을 수립합
  • HTTP 요청을 서버에 보냄
• 스프링 서버의 요청 처리
  • 요청 수신
    • 스프링 부트 애플리케이션이 HTTP 요청을 수신합니다. 스프링 부트는 내장 서버(예: Tomcat, Jetty, Undertow)를 사용하여 요청을 처리합니다.
  • 디스패처 서블릿(DispatcherServlet)
    • 스프링 부트는 DispatcherServlet이라는 중앙 서블릿을 통해 모든 HTTP 요청을 처리합니다. 이 서블릿은 요청을 적절한 컨트롤러로 전달합니다.
  • 컨트롤러 매핑
    • DispatcherServlet은 요청의 URL 패턴에 맞는 컨트롤러를 찾기 위해 요청 매핑(Handler Mapping)을 사용합니다. 요청 URL과 일치하는 컨트롤러의 메서드를 찾습니다.
  • 컨트롤러 메서드 호출
    • 요청이 일치하는 컨트롤러의 메서드가 호출됩니다. 이 메서드는 비즈니스 로직을 처리하고, 필요한 데이터를 모델에 담아 뷰에 전달합니다.
  • 모델과 뷰 반환
    • 컨트롤러는 데이터(모델)와 뷰 이름을 반환합니다. 뷰 이름은 보통 HTML 템플릿의 파일 이름을 의미합니다.
  • 뷰 리졸버(View Resolver)
    • DispatcherServlet은 뷰 리졸버를 통해 컨트롤러가 반환한 뷰 이름을 실제 뷰(예: Thymeleaf, JSP 파일)로 변환합니다. 이 뷰는 최종 HTML 페이지를 생성하는 역할을 합니다.
  • 뷰 렌더링
    • 선택된 뷰 템플릿 엔진(예: Thymeleaf, JSP)이 모델 데이터를 기반으로 최종 HTML 페이지를 렌더링합니다. 렌더링된 HTML 페이지는 HTTP 응답으로 반환됩니다.
  • 반호
• HTTP 응답 전송
  • 렌더링된 HTML 페이지가 HTTP 응답으로 웹 브라우저에 전송됩니다.
• 웹 브라우저에서 페이지 표시
  • 웹 브라우저는 HTTP 응답으로 받은 HTML 페이지를 화면에 표시합니다. 브라우저는 추가적인 리소스(예: CSS, JavaScript, 이미지)를 요청할 수 있으며, 이 리소스들도 동일한 방식으로 서버에서 처리됩니다.
• REST API 사용 시 뷰 반환 처리:
  • 컨트롤러는 보통 뷰 대신 데이터만을 포함한 응답을 반환합니다. 이 경우, 뷰 이름이 비어 있으며(null), 반환되는 데이터 객체는 HTTP 응답 본문으로 직접 변환됩니다.
  • 응답 변환 처리: 데이터는 @ResponseBody 어노테이션이 붙은 컨트롤러 메서드에서 반환될 수 있으며, 스프링의 메시지 컨버터(HttpMessageConverter)를 통해 클라이언트가 요청한 형식(JSON, XML 등)으로 자동 변환되어 응답됩니다.
  • @RestController의 역할: @RestController 어노테이션은 클래스 레벨에서 사용되며, 이는 해당 컨트롤러의 모든 메서드가 @ResponseBody를 암묵적으로 가진다는 것을 의미합니다. 따라서, REST API를 제공하는 컨트롤러에서는 별도의 뷰를 관리하지 않고, 데이터를 직접 HTTP 응답으로 매핑합니다.

출처

• https://medium.com/@2kunhee94/브라우저의-주소창에-url을-입력하면-일어나는-일-97a0837b8bf8
• DNS : https://opentutorials.org/course/3276
• 로드밸런싱 : https://nesoy.github.io/articles/2018-06/Load-Balancer
• 스프링 관점에서의 웹 페이지 접속 과정 : ChatGPT

• 인체 자세 인식 딥러닝을 이용한 운동 자세 훈련 시스템 개발

• 기계 학습 기반 목의 기울기 별 앉은 자세 인식을 이용한 거북목 식별 방법 및 장치

• 딥러닝 CNN을 이용한 자세, 동작 피드백이 가능한 운동프로그램 개발 2021.04
• 원문 링크 https://dcollection.skku.edu/public_resource/pdf/000000165345_20211015013412.pdf
• http://www.riss.kr/search/detail/DetailView.do?p_mat_type=be54d9b8bc7cdb09&control_no=f60d79c209a91f08ffe0bdc3ef48d419&outLink=K

• 인공지능 기반 초기 움직임에서의 동작 인식 2020.02 (lstm, gru) 사용한 http://www.riss.kr/search/detail/DetailView.do?p_mat_type=be54d9b8bc7cdb09&control_no=df59e6cbce7b07afffe0bdc3ef48d419&outLink=K

• 낙상탐지: 얘도 lstm, gru 사용하는데 포인트가 결국 행동을 예측해서 낙상을 방지하는 거...

• lstm, gru 얘들은 다 이상행동 감지, 행동 인식 쪽 https://scienceon.kisti.re.kr/srch/selectPORSrchArticle.do?cn=JAKO202116739584326

• 딥러닝 기반 포즈인식을 이용한 체력측정 시스템 2020 얘는 체력 측정 근데 디테일에 자세 교정 부분 있고 우리가 원하는 방향이야 이 파일 더 보자!

• 딥러닝을 활용한 운동 자세 분석 기술 및 인공지능 PT(Personal Training) 시스템 개발 (비공개라 열람 불가) https://scienceon.kisti.re.kr/srch/selectPORSrchReport.do?cn=TRKO201900017823

• 자석 기반 웨어러블 센서와 딥러닝 알고리즘을 이용한 거북목, 굽은 어깨, 비대칭어깨 종합 검사 및 장거리 운전자 피로 분석에의 응용 2020.02 결국 기준은 직접 만들어야 하나..

• 홈트레이닝을 위한 관절 특징점 검출 및 행동 유사도 측정 2020 이게 유튜브 따라하기를 한다면 가장 유사 우리 첫 아이디어랑 완전 똑같아 ㅋㅋㅋㅋ

ㅇ 객체 바인딩 ㅇ Model

ㅇ 객체 바인딩

• 계층 간 데이터 교환 : 컨트롤러와 jsp가 데이터를 어떻게 주고 받는지 (젤 중요한 부분!!)

• 객체 바인딩 : 특정 객체(메모리)에 담아서 서로 다른 계층이 넣고 빼고 할 수 있게 하는 기술

• 아이디어

  • 데이터를 특정 메모리에 셋어트리뷰터 해두고 -> jsp로 포워딩이 될 때 넘겨주면 -> jsp에서 겟어트리뷰트로 꺼내주는
  • 특정 메모리에 객체를 연결시켜두고 다른 쪽에서 객체를 꺼내 가는

• HttpServletRequest 객체를 활용하면

  • Controller에서 메서드 입력인자로 사용하여 셋어트리뷰트
  • jsp에서 꺼내기 : 겟 어트리뷰트그리고 tr부분에서 반복문 돌려서 게터로 뿌려줘

• HttpServletRequest 사실 요청을 위한 객체 (서블릿에서 제공하는) 세션이나 쿠키는 상태유지기법에서 쓰는 애들 => 즉, 객체 바인딩을 위한 애가 따로 있어. (스프링에서 제공하는)

ㅇ Model

• 스프링에서 객체 바인딩을 위해 제공해 주는 메모리
• HttpServletRequest 대신 Model을 사용하자
• call by reference
• 내부적으로 클래스가 연동되는 부분은 관여할 필요 없어. 스프링이 알아서 다 만들어뒀어 => 프레임워크의 장점

ㅇ 포조 ㅇ @ 어노테이션 ㅇ 흐름 ㅇ 메소드 ㅇ WEB-INF ㅇ 뷰 ㅇ DAO, DTO, VO ㅇ lombok (롬복)

(실습1 : 게시판 만들기)

• 실습1은 서비스 레이어 없이
• 샘플들은 지우자 (홈컨트롤러)

ㅇ 포조

• 일단 클라이언트가 요청이 오면 그 요청을 받는 알바생부터 만들자 => 포조!
• 컨트롤러라고 해서 무조건 서블릿 생각하면 안 돼. => 자바 일반 클래스
• 이름 : 게시판이니까 board 포조니까 Controller => boardController

cf. 스프링 프레임워크 나오기 전에는 스트럿츠라는 프레임워크를 많이 썼었나봐 프레임워크의 춘추전국시대 있었어. 개발 할 때마다 프레임워크 바꾸기 엄청 힘들었어 프레임워크의 겨울이 있었어 이걸 다 통합해서 프레임웍을 만든게 스프링이라고 이름 지은거야 그래서 봄!! 프레임워크가 통합이 안돼서 개발자들이 너무 힘들어 했어 스트럿츠에서는 컨트롤러 말고 액션을 많이 썼어. 스프링으로 넘어오면서 컨트롤러를 많이 써

ㅇ @(어노테이션) 기호

• 스프링은 내부적으로 일을 하니까, 이 클래스는 이런 용도입니다, 저 클래스는 저런 용도입니다. 표시를 해줘야 해 => @ 사용
• @ 기호가 붙어있으면 파이선에서 전처리같은 거야
• 포조는 @Controller
• 요청을 받는 건 @RequestMapping
  • 요청이 왔을 때 처리할 메소드를 매핑
  • 핸들러 매핑이 해줘

ㅇ 흐름

① 브라우저에 http:/120.0.0.1:8080/web/boardList.do를 치면 boardList.do를 보여주세요~ 라는 요청이 들어와 ② @Controller를 보고 포조로 들어와서 ③ @RequestMapping 중에 boardList.do를 찾아가 ④ 그 아래 이걸 처리할 메서드가 연결될 거야 ⑤ 그게 디비랑 연동해가지고 게시판 리스트를 가지고 온 다음에 ⑥ 객체 바인딩을 하고 ⑦ JSP한테 포워딩 해서 ⑧ JSP가 게시판 리스트를 만들어서 뿌려줘

• 스프링은 안에 연결하는 연결 고리들을 이해하는 게 중요
  • 이미 만들어진거라 코드를 짤 일이 없어. 연결만 시켜주면 돼

ㅇ 메소드

• 메소드 이름은 URL이름과 같이
• 리턴은 보낼 JSP이름

ㅇ WEB-INF

• src/main/webapp/WEB-INF/views 안에 jsp파일 만들기
• WEB-INF라는 단계가 하나 더 추가 된 이유
  • 클라이언트의 모든 요청을 C가 처리할 수 있게
  • 클라이언트가 View에 접근하지 못하게 하기 위해
  • WEB-INF는 톰캣의 보안 디렉토리라서 브라우저 상에 나오지 않아 => 접근 불가능
• 이제 스프링에서 바로 JSP 실행할 수 없어. 스프링은 MVC를 철저히 지키도록 함

ㅇ 뷰

• 부트스트랩 템플릿 이용하자 https://www.w3schools.com/
• 부트스트랩, 제이쿼리, 자바스크립트 http 링크는 필수 !!

ㅇ DAO, DTO, VO

• DAO(Data Access Object)
  • 데이터베이스의 data에 접근하기 위한 객체입
  • DB접근 로직과 비지니스 로직 분리
• DTO(Data Transfer Object)
  • 계층 간 데이터 교환을 위한 객체
  • 로직 없이 getter & setter 만 가진 클래스
• VO(Value Object)
  • 값 오브젝트
  • read-Only (사용하는 도중에 변경 불가능. 오직 읽기만 가능)
  • DTO와 유사하지만 DTO는 setter를 가지고 있어 값이 변할 수 있음
• 클라이언트가 보낸 데이터 -> DTO(혹은 VO)에 담아서 이동, 처리 -> DAO에서 DB에 보냄

ㅇ lombok (롬복)

• 게터세터 메소드 자동으로 만들어주는 api
• https://projectlombok.org/
• 스프링에서 롬복은 필수적
• 다운받은 뒤 설치(이클립스와 롬복을 연결)도 해야 해
• 이클립스에 api 디펜던시도 해야 해
• 게터세터 어노테이션 : @Data
• 생성자 어노테이션 : @AllArgsConstructor, @NoArgsConstructor, @RequiredArgsConstructor
• 널이 아니다 : @NonNull
• 예) 게시판 데이터 BoardVO에 적용

ㅇ 3 Tier Architecture (3계층 구조) ㅇ 환경 설정 ㅇ API 검색 사이트 ㅇ 단계 요약

ㅇ 3 Tier Architecture (3계층 구조)

• Presentation Layer (Web Layer)

  • 클라이언트가 요청이 오면 응답하는 계층
  • HTML, JSP, POJO
  • 데이터를 표현

• Persistence Layer

  • Model(Repository)
  • 데이터를 읽고 저장
  • 퍼시스턴스(영속성)라는 단어 나오면 DB와 관련된 로직이라 보면 돼

• 위의 두 레이어를 딱 붙이면 힘들어져 그래서 그 사이에 비즈니스 레이어를 집어 넣었어

• Business Layer(Service Layer)

  • 이 레이어를 넣는 게 어려워
  • 이 레이어가 꼭 필요한가 싶을 텐데 대형, 프로젝트 규모가 크면 비즈니스 레이어가 들어가게 되어 있어

• 스프링은 이렇게 3티어 기반으로 틀이 짜여져 있어

  • 1차 플젝 때는 만들다보면 서로 섞이고 했을 거야.
  • 근데 스프링은 믹스 x. 룰이 정해져 있기 때문에

cf. 우리는 모든 코드를 다 알 필요 없어. 그렇게 할 일도, 할 수도 없어 구글링을 잘 해서 내껄로 만드는 게 개발자야 안 해본 것은 구글링 -> 오류나 -> 물어봐 -> 다시 복붙해서 -> 잘 연결만 하면 해결!

이제 실습 시작!

ㅇ 환경 설정

ㅇ maven(메이븐)

• 스프링 프로젝트를 관리하는 툴
• api관리, 버전관리, 패키지압축, 배포 등등 아주 포괄적인 관리
• 프로젝트 아이콘 : s는 spring, m은 maven을 의미 (그만큼 스프링에서 중요!!)
• pom.xml이라는 설정 파일 이용해서 라이브러리를 관리
• 지금 스프링 버전은 3.1.1 (스프링은 5.x까지 나왔고, 전자정부는 보통 4.x 사용)
• 숫자를 바꾸면 자동으로 업데이트가 돼 확인은 Maven Dependency에서 할 수 있어

ㅇ Maven Dependency

• 현재 다운로드 된 API들
• pom.xml에 설정이 되어 있어서 다운로드 됐던 거야

ㅇ pom.xml의 properties

• 스프링 버전 바꾸기 : 숫자만 바꾸면 자동으로 업데이트 된다.
• 4.3.14 숫자 바꾸고 저장하니까 5초 뒤에 자동으로 바껴

ㅇ pom.xml의 dependency

• 디펜던시 = 의존하다 = 개발하다가 이 기능 만들기 위해 api가 필요하다.
• 필요한 api들이 하나 하나 설정되어 있어
• 레파지토리(메이븐 서버)에서 설정 파일을 보고 다운로드 해주는 거야
• 디펜던시를 넣고, 빼고 하는 것에 따라 api가 추가되고 없어지고 하는 것 숫자를 바꾸면 버전이 업데이트 되고
• 스프링은 api관리가 매우 쉽다!! 그 전에는 jar파일 받아다가 이래저래 연결했어야 했잖아.

ㅇ API 검색 사이트

• https://mvnrepository.com/
• 자바 웹을 하면서 이 사이트를 모른다? 하면 간첩!!!

ㅇ GSON

• 이제 GSON이라는 api가 필요해
• json데이터포맷을 핸들링할 때 사용. 구글에서 만듦
• GSON 검색 -> usages 가장 많이 쓰는 버전이 2.8.5 를 클릭하면 디펜던시가 나와 이거 복사해서 붙여넣기 하면 돼
• 위의 주석 : 이 디펜던시를 넣으면 주석에 적힌 레파지토리에서 다운로드 하겠다. 는 의미
• 디펜던시 복붙하고 저장하면 api 생겨나

ㅇ 실제 다운로드된 위치는?

• 기본은 여기가 로컬 레파지토리로 설정되어 있어
• 서버저장소는 mv레파지토리고 (아까 그 사이트), 다운로드 되면 로컬 레파지토리(내 컴퓨터)로

ㅇ Java 버전을 1.6에서 1.8로 바꾸기 (8버전이 보편적이라서)

• 147라인 보면 compiler 있어 => source(152라인), target(153라인)을 1.8로 바꾸자
• 컴파일러버전은 전체 자바 코드에 영향을 미치기 때문에 숫자만 바꾼다고 바로 버전이 바뀌진 않아 => 강제로 업데이터 해야 해
• 프로젝트를 업데이트한다 = pom.xml의 수정사항을 반영한다
• 스프링 프로젝트 -> 마우스 우클릭 -> 메이븐 -> 업데이트 프로젝트 -> 포스에 체크(강제)

ㅇ 단계 요약

1 자바 컴파일러 버전을 바꾼다. & 업데이트 프로젝트 2 스프링 프레임워크 버전을 바꾼다 3 나머지 api는 필요할 때 디펜던시를 넣는다 (4 내일 db연동에 필요한 api들 추가해볼거야)

ㅇ Handler Mapping ㅇ ViewResolver (뷰 리졸버) ㅇ 스프링 웹 MVC ㅇ 스프링의 핵심 기능들은 내부적으로 다 만들어져 있어 ㅇ 최종 경로 ㅇ 데이터 공유는? Model 모델

ㅇ Handler Mapping

• 프론트 컨트롤러가 알바생한테 : 포조야 list.do 해줘, insert.do 해줘, delete.do 해줘, update.do해줘 이렇게 요청하겠지
  • 이런 클라이언트의 요청을 '핸들'이라고 해 (운전사 핸들을 좌/우로 틀면 그대로 가듯)
  • 이 요청도 직접 하는 게 아냐. 중간에 또 다른 사람을 거쳐
• Handler Mapping : 이런 핸들을 연결시켜주는 클래스 요청을 선택해서 = choose handler해서 알바생한테 연결시켜줘
• 핸들러매핑도 파란색이야. 스프링이 제공해 줘

ㅇ 핸들러 매핑 어디 있나

• 톰캣 서버를 실행하면, 콘솔창에 핸들러매핑 검은 글씨(=이 클래스가 동작한다.)
• 핸들러매핑은 내부적으로 일하는 클래스 (은행에서 일을 하지만 고객 눈에는 안 보이는 사람들 있듯이)
• mapped / : 슬러시라는 요청이 오면 (쭉 오른쪽으로 이동) 알바생 홈콘트롤러의 홈이라는 메서드를 실행하라 라고 해석이 돼
• 실제 웹 페이지에서 슬러시가 오면 홈이라는 메서드를 처리하게 되어 있어
• 톰캣 서버가 시~작!하면 이렇게 이미 스탠바이를 하고 있어 : 슬러시가 오면 홈컨트롤러 클래스의 홈이라는 메소드가 동작이 되어야 한다
• 그래서 주소 적고 엔터를 빵 하면, 이 /에 의해 home 메소드가 동작이 되는 거야

ㅇ 핸들러 매핑 실행 과정

• 톰캣 서버 실행 시 스탠바이 중 (핸들러매핑에 의해) -> 엔터 빵 하면 home 메소드 실행 -> 메소드 내부의 것들 실행 되고 (로거로 찍기, 날짜 만들기) -> 모델에 값을 담아서 -> home 이라는 jsp 리턴 -> 뷰에 home.jsp로 넘어가서 -> 헬로월드가 동작하는거야
• 포조에서 이걸 연결하는 부분이 메소드 위의 @RequestMapping 누가 오면 어떤 메소드로 갈지 이미 맵핑을 쫙 해둬지고 있어
• 우리가 프론트컨트롤러랑 핸들러매핑을 직접 만들지는 않지만, 얘들이 뭔지는 알고 있어야 하는 거야

ㅇ 리턴은 어디로? => 프론트 컨트롤러로

• return home;
• 이 문자열 home을 프론트 컨트롤러가 받으면, 프론트컨트롤러는 홈이 뭔지 전혀 몰라
• home은 논리적인 이름
• 접두사(/WEB-INF/views)와 접미사(jsp)를 붙여 물리적인 경로이름으로 바꿔야 해 Q. return에 그냥 경로를 주면 되는 거 아닌가요? A. 나중에 views라는 폴더 이름이 수정되면 유지보수 어려워져
• 그래서 접두사와 접미사를 붙이는 역할을 해 줄 클래스가 하나 더 필요 => ViewResolver

ㅇ ViewResolver (뷰 리졸버)

• 뷰에 경로를 만들어 줌. 논리적 경로를 물리적 경로로 바꿔 줌
• 접두사와 접미사를 붙여서 경로를 만든 뒤(⑥) 다시 프론트 컨트롤러에게 줘 (⑦)
• 프런트 컨트롤러 -> 핸들러 매핑 -> 포조 -> 핸들러매핑 -> 프런트 컨트롤러 -> 뷰 리졸버
• 뷰 리졸버도 스프링이 제공해 줘 (파란색)

ㅇ 뷰 리졸버 위치 : 서블릿-컨텍스트.xml

• 서블릿-컨텍스트.xml에 들어가면 접두사 prefix와 접미사 suffix 설정되어 있음

• 이 클래스가 이미 등록이 되어 있어

• 그래서 소스코드를 수정하는 게 아니라 여기 경로를 바꿔주면 끝나는거야

ㅇ 스프링의 핵심 기능 3가지는 내부적으로 다 만들어져 있어

ㅇ 프론트 컨트롤러, 핸들러 매핑, 뷰 리졸버

• 겉으로 드러나진 않지만 내부에서 스프링 프레임워크를 동작시키고 있는 핵심
• 이 3가지가 스프링 내부에 이미 만들어져 있으니 직접 코딩할 필요 x => 얼마나 효율적이야
• 우리는 포조만 만들면 돼

ㅇ 최종 경로

• 프론트 컨트롤러가 중심
  • 요청이 들어오면
  • 핸들러 매핑에게 보내서 -> 매핑해 둔 곳으로 가서 -> 포조가 일을 하고 -> 돌려 받아
  • 그걸 뷰 리졸버에게 보내서 접두사 , 접미사 붙인 경로로 돌려 받아
  • 그 경로에 해당하는 뷰로 보내서 JSP한테 포워딩 -> 결과를 돌려 받아서
  • 응답해 줘

ㅇ 데이터 공유는? Model 모델

• 기존 Servlet과 JSP
  • 특정 메모리에다가 값을 셋어트리뷰트로 담고 -> RequestDispacher로 포워딩 후 -> JSP에서 다시 겟어트리뷰트로 꺼내서 뷰를 만들었어
  • 리퀘스트 바인딩으로 값을 계속 공유해야 해
• 스프링에서는 모델이 그런 역할을 해
• 스프링에서 모델도 제공해 줘 (파란색)

=> 그래서 우리는 포조와 JSP뷰단만 만들면 끝

• 샘플코드도 포조와 뷰만 있어
• DB 연결할 모델 만들면 MVC 끝이야

ㅇ 컨텍스트 등록 ㅇ FrontController와 POJO ㅇ web.xml의 DispatcherServlet ㅇ 기본 동작 흐름

ㅇ 컨텍스트 등록

ㅇ 컨텍스트 등록 : 웹 서버에 등록하기

• 우리가 만든 이 프로젝트를 톰캣이라는 서버에 등록 해줘야 해 건물이 지어졋으면 등기를 해서 번지를 지어줘야 사람이 살 수 있듯이, 우리 프로젝트를 톰캣 서버가 등록을 해줘야 톰캣 서버가 우리 어플리케이션을 찾아갈 수 있는거야
• 톰캣 - 마우스우클릭 - 애드 - 우리프로젝트를 등록

ㅇ 등록 확인

• 서버 -> 서버.xml -> context 가면 path속성 있어 (152번째 줄)
• 등록을 하게 되면 소스코드에 들어가. 이게 컨텍스트 패스
• 등록 되어 있어야 우리 프로젝트를 톰캣 서버가 찾아갈 수 있어
• 컨텍스트 패스 이름으로 요청을 해야 톰캣 서버가 찾아 가는거야

ㅇ 결론

• 클라이언트가 http://localhost:8081/web 을 요청했을 때, web이라는 이름이 컨택스트 패스에 있어야 톰캣 서버가 찾아갈 수 있어

ㅇ 톰캣 포트번호 바꾸기

• 원래 톰캣 서버의 기본 포트가 8080 인데 오라클이 1521 포트와 8080포트를 쓰고 있어
• 그래서 8081로 바꾸자

ㅇ 동작 과정

• 톰캣은 기다리고 있어
• 톰캣 서버한테 이제 헬로 월드 보여줘~ 요청하면 톰캣 서버가 뭔가를 찾아서 우리한테 헬로 월드를 보여줄거야 = 요청에 맞는 응답을 해줄거야

ㅇ 요청하기

• 클라이언트가 서버의 ip를 요청할 거야
  • https:// ip주소 혹은 도메인주소
• 3가지 방법
  • 1, 2 : 내 컴퓨터에 직접 요청 => 127.0.0.1 또는 localhost
  • 3 : ipconfig로 찾은 ip주소
• 그 뒤에 톰캣 서버에 요청해야 하니까 :8081
• 그 뒤에 이름은 web
• http://127.0.0.1:8081/web/
• http://127.0.0.1:8081/web : web까지만 적으면 기본은 /(루뜨)가 들어가

cf. 루뜨(/)는 뭐냐

• 리퀘스트매핑의 값에 적힌 /

• 주소의 슬러시(/)가 요청이 들어와서 String home 메서드가 처리가 되는 거야

• 만약 /test가 걸려 있으면 /web/test해야 이 메소드가 처리 되는거야

• 요청이 들어오면 c(컨트롤러)로 갔다가 m(모델)으로 갔다가 v(뷰)로 가는 과정이 프레임워크 안에 숨어 있어

ㅇ FrontController와 POJO

ㅇ 은행에 비유

• 은행문을 열기 전 불도 켜고, 컴퓨터도 켜 두고 등등 셋팅을 다 해둬야 9시땡 하면 고객이 들어올 수 있는 것 처럼 = 톰캣 서버를 시~작 한다는 것은 클라이언트의 요청이 들어오기 전에 스탠바이 상태를 만들어 둔다는 것 (메모리, 데이터베이스연결 등의 준비 절차) = xml 파일을 읽어들임
• 고객이 들어옴 = 클라이언트한테 요청이 옴
• 은행문 딱 열고 우리를 반겨주는 경비원 (어떤 업무를 보러 오셨습니까. 하는 사람) = FrontController
  • 경비원(프론트컨트롤러)는 요청에 맞는 영역으로 일을 보내면 돼
• 출입명부, 발열체크 등을 해 줄 알바생 = POJO (Plain Old Java Object)

ㅇ FrontController

• 클라이언트가 요청을 제일 먼저 받는 사람은 컨트롤러
• 컨트롤러 중에서도 클라이언트의 모든 요청을 다~ 받는 컨트롤러가 있어 => FrontController
• 여기를 통과하지 않고 다른데로 갈 수 없어
• 서블릿
• web.xml의 DispatcherServlet

ㅇ POJO

• 구체적인 업무를 프론트컨트롤러가 다 하려면 로드가 길어져
• 프론트컨트롤러가 해야 할 일을 대신해주는 알바생들을 필요로 해
• POJO도 크게 보면 컨트롤러야
• HomeController.java

ㅇ FrontController와 POJO의 차이

• 프론트컨트롤러는 서블릿으로 만드는데 포조는 그냥 자바로 만들어야 해
• 프론트컨트롤러는 일을 시키는 애, 실제 일을 하는 애는 포조
• 프로젝트할 때는 포조를 잘 만들어야 해

ㅇ 퀴즈 : 우리 프로젝트에서 HomeController는 FrontController일까 POJO일까?

• .java 파일이므로 POJO야
• 서블릿 형태면 프론트컨트롤러였겠지?
• 그러면 FrontController는 어디 있나? => 스프링은 알아서 제공 해 줘 (어딘가에 만들어져 있어) => web.xml의 DispatcherServlet

ㅇ web.xml의 DispatcherServlet

• 우리 어플리케이션이 톰캣에 등록되어 있으므로 톰캣 서버를 시~작 하면 우리 어플리케이션에서 해야할 일들을 web.xml부터 처리를 해
• src-> main -> webapp -> WEB-INF -> views -> web.xml

ㅇ xml 파일

• 작업지시서 : 프레임워크한테 이렇게 이렇게 일 좀 해주세요~ 하고 설정하는 것
• 톰캣 서버가 시작되면 이런 xml들을 다 읽어갈 건데 순서가 있어 =>가장 먼저 web.xml
• xml파일 4개가 기본으로 있어 (더 추가적으로 만들게 될 거야)

ㅇ DispatcherServlet

• web.xml 안에 processes application requests(리퀘스트 요청을 받는 프로세스)로 서블릿이 있어
• 이름이 디스패쳐서블릿. 이게 프론트 컨트롤러가 돼
• API로 다운로드 되서 프로젝트 안에 있어
• 스프링은 프론트 컨트롤러가 미리 정해져 있고 우리가 만들 필요가 없어 스프링은 프론트 컨트롤러 이름이 DispatcherServlet 어떤 클래스죠? 하면 "web.xml의 DispatcherServlet에요" 하면 돼

ㅇ 기본 동작 흐름

스프링에서는 이 구조를 이해하는 게 중요해

• ⓐ FrontController ⓑ POJO
• 이 둘 사이에 이걸 핸들링 해주는 핸들러매핑 등등이 있음
  • 결합도를 낮추고, 응집도 높이는 방법이야
  • 둘 사이에 뭔가가 들어가서 그 연결을 끊어버리는 것
• 스프링은 이렇게 계속 결합도를 낮추면서 사이를 벌리다 보니 복잡해져 구조는 복잡해지지만 효율적으로 되는거지
• provided by Spring Source
  • 파란색들은 다 스프링 소스에 의해 제공이 되어진다!
• FrontController는 스프링이 제공하지만, POJO는 우리가 만들어야 해
  • 샘플로 제공되는 POJO : HomeController.java

ㅇ 스프링 프레임워크를 쓰는 이유 ㅇ 전자정부 표준 프레임워크 ㅇ 스프링 웹 MVC ㅇ 기본틀 살펴보기

ㅇ 스프링 프레임워크를 쓰는 이유

ㅇ JDBC 단점

• 1.유지, 보수 어려워 : 자바소스코드에 SQL쿼리를 믹스하니까
• 2.개발 속도가 느려. 즉, 생산성이 떨어진다.
  • 클래스 만들고, 커넥션하고, sql의 인서트, 딜리트 등을 직접 다 코딩해야 하니까
• 해결 : 프레임워크를 사용해서 생산성을 높이자

ㅇ MyBatis

• Database 프레임워크
• 자바코드와 SQL쿼리를 분리해서 코드를 짜
• 연결은 mapping해서 사용
• 유지보수 쉽고, 개발속도 빠르다.

ㅇ 기존의 MVC 패턴

• C 컨트롤러 : servlet
• V 뷰 : jsp (+ html, css, js(제이쿼리))
• M 모델 : 일반 자바 클래스 (dao, dto, 디비와 연동하는 건 모델에서 커버)

ㅇ 스프링 배우게 되면

• jsp & servlet 안 써 (기초부분이긴 하지만 현장에서는 쓰이지 않아. 10년 전 기술)
• 스프링쪽은 취업 문이 많이 열려 있으니까 수업 수강하면서 길을 잃은 친구들은 여기도 생각해 봐

ㅇ 스프링 다 다루려면 시간 많이 걸려 => 핵심만 실습으로 고고

• 배우는 방법이 상당이 어려워. 진입하기도 어렵고, 방대한 이론 다 배울 수 없어
• 쌤이랑 게시판 로직을 스프링 프레임워크로 만들어보면서 실습을 같이 하는 게 가장 빠른 방법
• 프레임워크는 방법론이므로 이론보다는 실습 위주로

ㅇ 전자정부 표준 프레임워크

ㅇ 전자정부 표준 프레임워크

• 기존에 만들어져 있는 이클립스 받아다가 우리나라에 맞게 커스터마이즈 한 것
• 우리나라에서 필요로 하는 모듈을 플러그인 해서 탑재해 둔 것

ㅇ 설치

• 다운로드 한 exe 파일 더블클릭해서 설치 (c:\ (c루트)에 설치하기)
• c 드라이브 들어가면 eGovFrame-3.10.0 폴더가 새로 생성되면서 설치가 될 거야
• 여기에 이클립스, JDK, mysql, 톰캣, 안드로이드 개발 sdk 다 들어있어서 환경설정을 별도로 할 필요 없어
• 이제는 eGovFrame.edu로 작업할 거야

ㅇ workspace.edu에 있는 학습을 위한 샘플 프로젝트들 지우기

• 다른 샘플 파일들은 다 지우자. 서버는 지우면 안돼!!

ㅇ 스프링 웹 MVC

ㅇ 스프링 레거시 프로젝트

• 집을 지을 때 집의 큰 골격이 있듯이, 건물에 전체적인 구조가 있듯이 구조를 제공해 줘
• 스프링 프레임워크는 엄청 광범위 - 우리는 그 중 web MVC를 배워보자. (스프링 시퀴즈, 스프링 aop , 스프링 di, 스프링 jpa 등)

ㅇ 스프링 웹 MVC

• 프로젝트 이름 : SpringMVC
• 템플릿 : Spring MVC Project
• 프로젝트 패키지는 3단계로 :
  • .myapp* : 맨 뒤에 *가 붙어 있는 건 세번째 이름이 context path라는 의미
  • context path : 3레벨(web)이 프로젝트를 접근하는 이름이야.

ㅇ 기본틀 살펴보기

ㅇ 프레임워크 방법론

• 디렉토리 구조가 자동으로 만들어짐 (뼈대) 뼈대는 만질 수 없어. 프로그램은 만질 수 없어. 방법론을 이해해야 해
• 연결 흐름을 머릿속에서 아는 것이 프레임워크를 아는 방법이야

ㅇ 디렉토리 구조 확인

• java Resources -> kr.smhrd.web 패키지에 들어가면 자바 파일 HomeController.java 가 있고
• wepapp -> WEB-INF -> views 에 들어가면 home.jsp 파일 있어 (webapp = 이전 프로젝트에서 webcontent폴더 (jsp, html))

ㅇ 요구사항 정의서 서비스와 기능을 자세히 적은 것

ㅇ유스케이스 다이어그램 이 프로그램을 누가 사용할 건지 결정해야 해 사용자가 누구냐에 따라 제공되는 서비스가 달라지니까 지금 샘플은 통역앱 명소추천서비스

회원 가입이 있으면 사용자와 회사를 연결하는 구조가 나올 수도 있어

ㅇ유스케이스명세 다이어그램을 텍스트로 표현 아이디는 중복되지 않게 결정 요구사항 : 서비스 제공에 필요한 세부 기능들 선행조건은 그냥 n/a로 해버려 관련 액터는 사용자인지 카페 주인인지 이런 거 이벤트 흐름 : 어떤 식으로 요청이 들어오고 내부에서 처리가 되서 사용자에게 돌려주는지 종료 조건 : 회원가입이면 회원가입이 완ㄹ되었습니다~가 종료 조건 사후조건, 기타 요구사항은 - 없음 다이어그램에 나타나있는 모든 서비스를 대상으로 명세서를 작성하면 돼

ㅇ 기능과 비기능 기능 : 서비스 제공에 필요한 세부 단위 프로그램 비기능 : 성능과 관련된 요소

ㅇ 기능 요구사항 가운데 줄 그어진 건 삭제 느낌 설계 때는 필요하다고 생각했는데 개발 과정에서 필요없어진 부분 설계 문서는 변경에 대한 이력관리가 필요하기 때문에 실제로 삭제하는 게 아니라 삭제한다고 표현 실제 보고서 제출할 때는 삭제해서 제출하긴 해야 해

ㅇ 비기능 요구사항 우리가 할 수 있는 부분이 아니야 현업에서도 외부 기관에 인증. 성능 테스트 해주는 하드웨어적이라서 작성 안하는 쪽으로 생각하면 돼 iot - 센서의 활용률, 수집률 빅데이터 인공지능 - 우리가 만든 분석 모델의 적중률

ㅇ 설계

지금 있는 파일들 + 시스템 구조에 대한 설계도 해야 해 근데 시스템 구조는 하드웨어나 네트워크에 대한 내용들이 들어가야 해서 현재 할 수 없는 부분이라서 뺌

ㅇ 화면설계서 사용자 ui 설계 이거 설계하기 엄청 어려울 거야 그러니까 이 부분은 실제로 개발한 것을 역으로 부어주는 형태로 진행해도 좋을 듯 물론 개발 하기 전에 사전에 인터페이스 만들 수 있다면 정말 좋겠지! 할 수 있으면 하면 좋아~ 그게 어려운 팀들은 화면 설계에 관해서만 동시진행

ㅇ 데이터베이스 요구사항 분석서 데이터 수집 저장을 위해 세부적인 부분은 디비설계 수업시간에

1요구사항정의서 어떤 db를 만들기 위해서 사용자의 니즈를 분석하는 단계 향후 테이블이 되어야 할 컬럼, 컬럼들의 관계 2 객체 정의서 이걸 크리에이트 테이블로 구현하면 돼 3 e-r 다이어그램 테이블간의 관계를 다이어그램으로

ㅇ 테이블 명세서 요구사항 정의서에서 나온 것들을 적으면 돼 인덱스는 생략 마지막 큰 칸에는 실제 명령어

ㅇ 구현

구현은 따로 산출문서 없이 그냥 개발하면 돼

42분 40초까지 봄

• 설계 도면의 역할 : 프로젝트 일정, 방법 등
• 결과물 구현을 검증하는 잣대

ㅇ 실제 현업에서 기본적으로 프로젝트를 진행하는 단계야

• 계획
• 분석 : 사용자들의 니즈를 파악하고 그를 위해 어떤 서비스를 제공해야 하는지 분석
• 설계 : 기반을 마련, 데이터베이스 설계, 인터페이스 ui 등
• 구현
• 시험 : 우리가 요구하는대로 잘 구현 됐는지
• 관리

ㅇ 계획

• 프로젝트 방향성 : 기술, 현황 등을 미리 필터링하면 주제 뽑을 때 훨씬 더 도움 받을 수 있을거야. 관련된 주제들 나눠 놓으면 하나 정할 때 도움 돼
• 주제 : 기능 + 서비스
  • 어떤 기술을 기반으로 어떤 서비스를 제공하겠다. 가 어필 되어야 해
  • 주제만 보고도 뭘 하려는지 정확히 알 수 있도록
• 제안 배경 및 필요성
  • 현 시장 상황은 이렇더라
  • 상황 분석을 해봤더니 어떠한 서비스가 필요하고, 그 서비스를 제공하는 현재 상황에 이러이러한 문제점이 보여지더라
  • 문제가 있다면 개선을 해야겠지 -> 서비스 & 기능
  • 즉, 왜 이 프로젝트를 해야하는지 이유를 적는거야!
• 유사 제품 현황 및 비교
  • 유사 제품과 비교분석
  • a사 b사 우리제품 표로 만들면 좋아
  • 어떤 서비스 제공하는지, 어떤 기능이 필요한지, 대상은 누군지, 각각의 장점과 단점
  • 
  • 어떤 기능은 가져다 쓰고, 없는 기술은 집어 넣어야 겠다 분석 할 수 있어
  • 우리 제품이 다른 제품보다 뛰어나다는 우수성, 독창성
• 제안 내용 - 개발 목표
  • 정성적으로 쓰기
  • 시장이 이렇고 문제가 있고 개선하기 위해 우리 프로젝트가 필요하다
  • 예)
  • 누구를 대상으로 / 어떤 서비스를 제공함으로써 / 어떤 결과를 얻어내겠다
• 제안 내용 - 개발 내용
  • 정량적으로 쓰기
  • 목표에서 언급한 서비스를 구현하기 위한 기능들
  • 분석 모듈 / 센서 모듈을 개발하게 된다면 이런 것도 적어주기
  • 인터페이스
  • 
• 수행 방법
  • 데이터를 수집하는 방법 : 예) 크롤링, 공공data, 민간data
  • 데이터 출처, 데이터 수집 건수 . 이런 것들이 데이터 신뢰성
  • 추진 전략 : 계획-분석-설계-구현-시험-관리 이대로 표를 만들어
    • 각 영역마다 수행 내용, 수행 일정, 담당자
    • 각 단계별로 나오는 산출 문서들
    • 동봉된 wbs 문서 : 날마다 진척률 관리를 해
    • 추진 전략에는 대분류 항목들에 대한 내용 - 담당자 - 산출문서를 간단히 요약해서 적으면 돼
  • 팀원 및 역할
  • 제안 내용 안에서 수치로 적어두었던 개발 내용을 여기서 역할 분담
  • 누구는 어떤 서비스 어떤 기능을 하겠다.
  • 여기에 ppt작성, 문서 작성 이런 건 안 넣었으면 좋겠어.
  • 넣을거면 설계 문서 작성 이런 식으로 써야 어필되는 거지 그냥 문서작성은 팀원이 개발 업무에 참여를 안 하는 것 처럼 보여버려
• 기대효과 및 활용방안
  • 기대효과 : 아까 개선하겠다 한 거
  • 활용방안 : a분야에 적용 시켰는데 이 기능들이 다른 분야에도 적용시킬 수 있을 때

우선 계획단계까지만 들음 - 22분 30초

ㅇ 스브스 뉴스 https://www.youtube.com/watch?v=s3CH6gNqFGk

ㅇ 환경부 유투브 https://www.youtube.com/watch?v=5WsOJYkG6cA

ㅇ 다양한 캠페인 ㅇ 볼보 : 헤이 플로깅 이벤트 https://www.asiae.co.kr/article/2021060110173742765 https://www.youtube.com/watch?v=ImIXw9L1T2g

ㅇ 그린피스 : 어스 앤 런 이벤트 21년 6월 https://www.greenpeace.org/korea/update/17631/blog-plastic-earth-and-run-plogging/

ㅇ 투썸 플레이스 https://www.youtube.com/watch?v=hWGRJ9QUbsQ

ㅇ 이시영 https://www.youtube.com/watch?v=LmtSAZhzwKk

• 6월 30일 : 프로젝트 특강 (옆 반과 합동 진행) 앞으로 프로젝트 할 때 아이디어 도출 해야 해 직접 만들어야 하는데 어떻게 만들어야 하고 어떠한 주제를 도출해야 하는지

• 7월 7일 멘토링 진행 프로젝트 전문 지도하시는 분 들어와서 아이디어 주제 나온 걸 봐 드릴 거야 ★ 준비 (7/6까지) : 아이디어 브레인스토밍 ★ 프로젝트 최소 3~4개 준비 => 실현 가능성 정도, 보완 정도 체크

• 7월 8일 ~ 9일 : UI/UX 디자인 강의 카카오 오븐으로 간단히 웹페이지 만들 수 있는 방법 ★ 준비 : 기획한 화면 ★

• 7월 12일 : 기획 발표 내외부 심사위원 초청 기획 발표 ★ 준비 : 기획 문서, 피피티 ★ ★ 7월 11일 거의 확정된다고 생각하면 돼!!!! 이 날 거의 모든 게 결정. 픽스 된다고 생각하면 돼

• 7월 15일 : 깃 강의 깃 : 협업 도구. 수업 2시간 ★ 준비 (7/14) : 깃헙 계정 만들기 ★

• 7월 20일까지 ★ 여러 산출물들 제출 - 예) 요구사항계획서

• 7월 21~22일 : DB 멘토링 ★ 준비 : 데이터베이스 설계서 ★

• 7월 23일 : uiux 점검

• 7/26 ~ 8/4 : 프로젝트 진행 아직 빅데이터 안 배웠으니 웹사이트 만드는 것 위주로