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

Devkty·2025년 6월 25일

[목표]
2차 주제 발표를 하고 피드백을 받습니다.
노션 정리하기!!!!(어느정도 했다)
아마존 내용을 정리합니다.
UX/UI 개선.

10:45 ~ 12:00

어제 6시쯤 자서 최대한 일찍왔다. 먼저 기획 초안 설문을 작성하지 못해서 빨리 수정해서 제출했다.
PPT 스크립트 작성과 최종 작업을 완료했습니다.

12:00 ~ 13:00

식사를 하고, PPT 발표를 시뮬레이션 했습니다.

13:00 ~ 18:30

2차 주제 발표회 및 코치님 피드백 2시간 가량

5조: 음악인들의 동아리 커뮤니티

기존의 서비스는 실명이어서 어느정도의 제한이 있다.
자체 숏폼 컨텐츠도 있다. 숏폼으로 같이 합주를 하는 영상을 만들 수 있다.
DM을 통해서 음악인들과 소통 가능하다. 동아리 탭이 있어서 동아리 조직 가능
리엑트, next.js, Posta SQL, Amazon S3, Redis 사용

피드백

어떤 기술적 챌린지가 있는지 설명하지 않아서 잘 모르겠다. PPT에 들어가 있으면 좋겠다.
영상이 업로드를 하면서 업로딩 될때까지 사용자가 뭘 해야하는가? 답변이 부실한 걸보니, 조사를 하지 않은 것 같다. 확실하게 동영상 플랫폼을 조사하고 파이프라인에 대해서 구체적으로 조사를 해볼 것.
기술적 챌린지와 영상 처리 기술에 대해서 더 공부하고 수용일날 발표할 것.

4조: 런닝 메이트를 찾는 사이트

러닝에 게임적 요소를 넣어서 러닝을 재밌게 할 수 있도록 한다.
마치 카트라이더의 고스트 라이더와 같다.

등급제를 통해 경쟁 심리를 자극할 수 있도록 했다.

기능 화면: 메인화면

모드
자유모드: 트랙없이 자유롭게 러닝을 할 수 있다.
트랙모드: 트랙을 선택하여 트랙 이름과 총 길이를 표시하여 정보를 출력한다. 그리고 트랙에 따라 달릴 수 있다.

봇관련 기능
봇의 페이스 설정: 봇의 페이스를 보정을 통해 사용자들마다 동적으로 살짝식 바뀌도록 구현할 예정이다.
봇과의 대결: 봇과 대결 가능하다.

대결 결과 페이지: 최종적인 대결 결과를 확인할 수 있는 페이지 입니다.
대결모드: 다른 사람들과 대결을 통해 경쟁심을 타오를 수 있다.
기록 확인 하기: 자신의 기록을 확인할 수 있게끔 구현
캐릭터 꾸미기: 약간 로블록스처럼 옷과 외형을 바꿀 수 있다.
랭킹 페이지: 시간, 거리를 통해 런닝 순위를 매길 예정이다.

아키텍처: 리엑트 네이티브, 스프링
기술적 챌린지: GPS 기반의 경로 저장과 기록 리플레이

가속도 센서를 이용하여 경로 보정 및 추정(GPT의 세부화 문제 해결)

피드백

똑같은 내용이 많은 것 같다. 시간이 오버된다. 딱 필요한 것만 압축하여 전하고자 하는 정보만 알려주면 좋을 것 같다.

기획이 유효한지 생각해봐야한다. 어떤 아키텍처를 쓸지 고민을 좀 더 해봐야한다고 생각한다. 그래서 어느정도 기술을 해결하기 위해서 구현할 수 있는지 확인을 해봤는가?
라이브러리를 통해서 구현가능.

기술적 챌린지는 틀려도되니까 명확하게 어떠한 정보를 통해서 구현가능한지 설명해야한다.

능숙하게 발표할 수 있도록 해야한다. 시간 오버되는건 절대 안된다.

  • 시연 어떻게 할 것인가? → 달리는건 어떻게 시현 시에 보여줄 것인가?

3조: 게임, 코딩 과외

단어를 중심으로 한 게임

기존의 코딩과외는 음성 통화와 화면 공유가 전부. 선생님이 코드 이해 어려움. 코드 분석을 통해 학생과 상호작용할 수 있게 도와준다.

  • 코딩문제와 테스트 케이스를 제공.
  • 작성한 코드에 대해 분석, 피드백

학생의 학습 분석, 코드 자동 픽스 기능, 문제 가이드 제공(학습 데이터 기반)

기술적 챌린지
안전한 실행을 위한 코드 실행 샌드박스가 있어야할것.
AST 기반 코드 분석 엔진 구현 예정
컨테이너 분석과 시스템 성능 분석 방법
실시간 데이터 동기화 프로토콜 해결
1대 1일때 P2P를 사용하지만, 대다수일때는 어떻게 할것인지?
코드 실행은 nest와 도커, 로직 담당: nest, 코드 분석기 nest

피드백

도커나 샌드박스가 제공된다는게 서버비가 만만치 않다. 실제로 멋쟁이 사자에서 해당 서비스를 제공하다가 망했다.

백준처럼 코드 풀이하는 정도의 서비스 같다.

첫번째 주제가 다른 조랑 겹친다. LMS 시스템을 구축하는게 중요할 것 같다.
두번째 주제는 어떤 장점이 있고, 뭐가 좋은지 잘 모르겠다. 어떤걸 차별화할 수 있는가? 기술적 챌린지를 정리할 것.

선생님이 봤을때 어떤 장점이 있는가? 실제 돌아가고 있는 서비스들을 벤치마킹하여 찾아보는 것이 좋지 않을까.

계속 기획을 틀면서 구체화시키는게 좋을 것 같다.
1번 기획같은 경우 멀티 플레이 같은 경우 어려울 수 있으니, 검토하여서 작성할 것.

우리조: 개발자 맞춤형 코드실수 패턴 교정 서비스

이건 실현 가능성이 없는 서비스. 시점과 범위의 문제가 크다.
시점의 문제, 범위의 문제가 있다.

큰게 두가지가 빠졌다. 어떤 시점에 이걸 확인할지?
내가 건드리고 있는 내용을 어디를 건드리고 있는지 범위 문제가 있는지?
전에 내용에서는 커밋을 할 때라는 명확한 시점이 있었는데, 지금은 언제 확인해야할지에 대해, 코드의 품질을 확인할 수 있었는지에 대해 답이 없어서 좀더 나쁜 방향으로 간 것 같다.
코드 품질 확인 같은 경우 소나큐브와 같은 툴이 있다.

굳이 이걸 해야하나 라는 방향으로 바뀐것 같다.
넣었을때 좋아보여서 라는 기술들은 굳이 넣을 필요성이 없어 보인다.

1조: Try it on (3D를 통해 자신의 옷을 가상으로 입을 수 있음)

다수의 쇼핑몰은 단일 제품에 대한 리뷰 기능은 있으나, 원하는 제품 조합으로 조화를 볼 수 있게 한다.

개인화 추천: 사용자의 개인 데이터를 기반으로 취향을 분석하여 맞춤형 의류를 추천

요구하는 기술
옷의 스타일의 3D 모델링
옷의 질감 표현

Cloth2Tex
2D의류 이미지의 입력으로 3D 렌더링
옷의 질감까지 가능
만들어진 3D 모델을 보여주게끔 한다.

기술적 챌린지
옷에 대한 3D 매쉬의 정확도
개인화 추천을 위한 알고리즘 구현.
3D를 어떻게 구현하게 할 것인지?(시간 문제)

기대효과: 사용자가 직접 입혀보지 않고도 가상으로 입을 수있다.

발표 순서가 뒤죽 박죽이다. 일단 먼저 서비스 내용을 충실하게 설명하고, 3D 에 대한 기술을 설명해야한다.

지금 발표는 너무 3D 구현에 대해서만 설명하는 것 같다.
3D 가상화 서비스외에 추가적인 기술들이 있어야할 것 같다.
메인기능에서 서브로 파생되는 기술들을 생각해되야 할 것같다.

5명이 모두 알고리즘이나 3D에 투입되진 않을터이니 다른 기술적 챌린지를 넣어서 다른 팀원들도 할 일이 있게끔 해야될 것 같다.

피드백후 회의

어제 10시에 아이디어를 생각하면서 13시에 온 인원의 의견이 무시당한 문제가 있었다. 그것은 오늘의 피드백을 통해 알게 되었고, 난 어제 오늘까지 마감해야되는 발표자료로 마음이 급해져 모든 사람의 의견을 수렴하지 못한것 같다.

일단 첫번째 주제를 왜 엎었는지에 대한 질문과 이유를 정리했다.
1. 우리 첫번째 아이디어에 대해서 알고리즘을 어떻게 구현할 것인가? (러프하게 생각한 바로는 자바스크립트에서 유저들이 자주 실수하는 항목에 대해 예를 들어, 자료형 실수 일때 +3, 비교연산자 실수 +2, 비동기 처리 실수 +4 등 을 통해 Ai한테 넘기고 비지니스적 오류만 잡아주고 형식화 한다음에 마크다운 코드로 출력할 수 있게끔 만드는 것이다.) 이게 적합할지 잘 모르겠고, 시연시에는 우리만의 테스트 케이스로 적합한 결과만 나오게 하는게 맞을지?

  1. 마크다운을 정형화하는 과정에서 프롬프트 엔지니어링 VS 알고리즘 (즉, 프롬포트 엔지니어링하여 GPT가 우리가 원하고자 하는 형식으로만 출력을 하게끔 할지, GPT가 넘겨준 자료들을 글자를 분석하여 매핑하여 우리가 정해진 폼으로 출력할 수 있게끔 하는게 좋을지)

코치님 최종 질문 리스트

이동석 코치님의 피드백에 대한 고민

전 주제의 피드백을 받았을때, 현역 개발자들의 개발 프로세스에서는 버그가 발생한 시점(클라이언트가 버그 제보를 한다)에 이미 버그 리포트를 작성하고, 버그가 발생한 중 틈틈히 버그에 대한 해결방법을 적고 이후 그 문서를 종합하기만 하면 바로 트러블 슈팅 문서처럼 만들어지기 때문에 이 과정 중 우리의 트러블 슈팅 문서 자동화 기능이 끼어들 내용이 없다는 피드백이 있었다.
이에 대해 코치님의 의견은 어떤지 아니면 관점을 약간 바꿔 트러블 슈팅 방법을 잘 모르는 초보 개발자들을 대상으로만 우리의 서비스를 타겟팅해도 괜찮을지, 이를 한번 여쭤보고 싶다.
→ 버그 발생 커밋함, 여러 버그들이 모여서 하나의 문서들이 된다. 어느 커밋이 있으면 개발자 테스트를 하고 머지를 한다. 머지를 하고 나서 해당과정에서 코드 리뷰를 한다. 변경된 코드들에 대해서...

피드백

현업에서 트러블슈팅 과제에대해서 문제점들을 파악하고, 잘 활용할 수 있게끔 하도록해야한다. (업무 프로세스에서) 즉, 타깃을 명확히 해야된다.

회사의 프로세스관점
업무프로세스에서 더 편리할 수 있는 부분은 무엇일까? 어떤 회사의 타깃을 가지고 깍아 내는게 좋을것 같다.

두번째 주제: 코드 관점과 로그 관점이 있다. 두 관점이 너무 다르다. 코드와 로그는 완전 다르다고 한다. 로그는 타깃으로 하는 시스템이 뭐였을까? C언어를 로컬에서 실행 테스트하고 로그가 나오면 그걸 분석한다. 학습용 말고 C언어말고 내 로컬에서 테스트 하는 케이스가 얼마나 될까? 일단 임베디드는 안된다. 펌웨어는 기계에 올려서 테스트 해야함. 이것에 대해 교육 한정으로 하려면 더 확장해야한다. 이걸 하려면 대용량 + 노 휴먼 + 리포트 일때 뭔가 찾아 내야한다. 그러나 이러한 서비스가 있다. 예를 들어 서버의 로그를 filebeat를 통해 S3에 모아서 분석하는 툴이 얘가 어떤 툴을 가지고 있는지 분석해준다. 분석해서 문제가 있는 로그에 대해서만 알려준다.

발표를 들었을때는 학습 툴인것 같다. 빌드 테크트리 분류를 해야한다. C언어 + 학습 의 깊이가 높아야한다. 기획 의도가 명확해야한다. 정글에서 핀토스에서

1안은 명분만 찾으면 된다. 이슈트래킹 시스템 안에서 하나의 과정으로 넣는다면 장점이 뭐가 있을까? 가 의미가 있다. 코드를 이슈를 발견코드에 대한 적정 테스트를 추가한다는 것이 좋다.

2안은 명확하게 결과가 나오면 필요 없다.

주제를 바꿀까 고민한 또 다른 이유(알고리즘)

우리 첫번째 아이디어에 대해서 알고리즘을 어떻게 구현할 것인가? (러프하게 생각한 바로는 자바스크립트에서 유저들이 자주 실수하는 항목에 대해 예를 들어, 자료형 실수 일때 +3, 비교연산자 실수 +2, 비동기 처리 실수 +4 등 을 통해 Ai한테 넘기고 비지니스적 오류만 잡아주고 형식화 한다음에 마크다운 코드로 출력할 수 있게끔 만드는 것이다.) 이게 적합할지 잘 모르겠고, 시연시에는 우리만의 테스트 케이스로 적합한 결과만 나오게 하는게 맞을지? AI의 비중이 좀 높아지는게 아닐지 우려된다.
→ 이슈트레킹에 대해서 깊이가 너무 깊다.

자바스크립트가 오브젝트에 대한 문제가 있다. 더 확장적 관점으로 봤을때, 네트워크로 통신으로 넘어 갔을때 기술적으로 어려운 주제이다.

로그에 카테코리에 대한 프로토콜을 새롭게 재창조하던지, 에러가 발생하지 않았지만, 로그에 흐름상 앞으로의 에러의 흐름을 예측하던지가 필요하다.

이슈트레킹 서비스를 좀 더 쉽게 재창조 하는게 안좋을까?
딥다이브해야한다. 커서 Ai를 뛰어넘는 걸 가져와야된다.
칸반부두라고 지라를 쉽게 만든것이 있고 쉽게 만드는게 의미가 없다.
목적이 있어야한다. 기술 탐구를 위해서라던지.

정형화 과정에 대한 궁금증

마크다운을 정형화하는 과정에서 프롬프트 엔지니어링 VS 알고리즘 (즉, 프롬포트 엔지니어링하여 GPT가 우리가 원하고자 하는 형식으로만 출력을 하게끔 할지, GPT가 넘겨준 자료들을 글자를 분석하여 매핑하여 우리가 정해진 폼으로 출력할 수 있게끔 하는게 좋을지)

2안이 더 좋은 방안이라고 생각한 이유

Commit Log를 분석해서 트러블 슈팅 문서를 자동화해주는 기능은 어쩔 수 없이 문서작성에는 chatgpt같은 모델이 주 기능이 돼버리는 데, 알고리즘이 프롬프트 엔지니어링+LLM에 넘겨주는 토큰 경량화만 해도 되는건가? main기능에서 추가되는 기술적 챌린지, 즉 확장을 어떻게 해야하는지 가늠이 되지 않았습니다.

우리의 바뀐 주제 코드가 바뀌면 (깃허브로그로 추적되는 것처럼)이 코드를 파일 단위 / 모듈 단위 / 함수 단위로 나눠 분석할 수 있다면 분석할 수 있다면 수백만 줄도 가능하다고 생각했다. 일단 C언어에만 한정해서 CPPcheck 같은 정적 분석tool로 할 예정.

그리고 컴파일 시점 -> 런타임 시점이 있는데 컴파일 시점의 컴파일 오류들은 바로 DB에 보냄
RUN을 하면 컴파일->RUN으로 바뀌는 데 Terminal에 동작이 감지되면 보냄.

[피드백]
피드백 같은 경우 정리되어 있지 않아서 일부분만 올리겠습니다.
자바 스크립트에 대해서 자신 있는줄 알았다. 분석해서 리포트를 주는 거는 단순한 서비스이다. 5주동안 빡세게 만드는 건 증명되야한다.

우리가 어떤 주제에 대해서 계속해서 이야기하고 조사를 하는 목적이다. 시간과 투입 인력을 계산을 다음과 같이 말한다.
man month: 한달에 몇명 투입할 것인가?

인력관리와 시간 관리를 효율적으로 해야한다.
이슈트래킹 난이도가 너무 깊다…

문제: 자바스크립트의 코드 관점에서 두가지 문제가 있다.

  • 커서가 LLM을 로컬에서 돌리는 것과 다르다.
  • 어디까지 깊게 해야되는가?

아이디어 별로 핵심 컨셉에 대해서 조사해서 된다면, 그걸 옆으로 넓여 가면된다.
이거 말고도 아이디어를 내보고 정리를 해서
내일 5시 30분에 같이 이야기 해보도록 하겠다.
다시 한번 주제 점검을 해야되겠다.

18:30 ~ 19:40

식사를 했다.

19:40 ~ 20:50

일단 코치님이 말씀하신 것과 개발에 관련된 주 포인트를 위주로 각자 조사를 깊게 해보기로 했다.
나는 일단 크래프톤 정글 8기 나만무 멘토링 매핑 결과가 나와서 멘토님한테 메일로 연락 드렸다.

20:50 ~ 23:00

노션을 정리하고 밀린 TIL들을 올렸다.

Jira를 우리 레포지트리에 도입해보고 있다. 성공적으로 브런치와 PR은 사용가능하다.
git checkout -b develop2 origin/develop2 : 깃브런치 로컬로 가져오기

브런치를 하나 파는 것이 맞다.(실험적인 일을 할때.)
git remote update 를 통해 git 홈페이지에서 만든 브런치를 로컬에 업데이트 할 수 있다.

23:00 ~ 24:00

이슈트래킹에 대해 어떤 기술적 챌린지가 있고, 어떻게 프로젝트 방향이 이슈트래킹으로 바뀌어서 해당 내용을 공부했다.
SQL과 No SQL에 대해서 의문이 생겨서 조사했다.
SQL은 회원과 같은 테이블, NoSQL은 로그와 같이 형식이 정해지지 않은 경우에 유용하다.

24:00 ~ 03:00

이슈트래킹에 대해 지금까지 공부한 내용을 공유하였습니다.

저같은 경우 토스라는 기업의 이슈트래킹 시스템을 이해하기로 했다.

리서치 중에 Jira와 같은 이슈트래킹 웹사이트를 클론 코딩한 곳이 있어서 깃 클론을 받아서, 실행을 해보았다. make, GO, Git 패키지가 필요해서 우분투를 깔고, 패키지를 깐다고 시간이 좀 들었다.

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

0개의 댓글