2024년 11월 22일 - STANL-2/MOTIVE GitHub Wiki
2024-11-22 멘토링
내부 회계 데이터(신뢰성) -> 내부 통제
os/application 이원화
- 권한의 과다한 부여로 비인가된 업무 위험 -> 사용자 계정 권한 자동 회수 설정
- os 계정 및 권한 요청 승인(db master 등..)
- 관리성 화면: otp 혹은 ip 제한
- 비인가된 프로그램 변경으로 인해 재무정보의 무결성 훼손 -> 프로그램 변경 요청 승인
영업은 시작이자 끝이다
ownerShip
excel은 산출물용
jira의 간트차트로 진척관리 -> 담당자와 팔로우업할 거리들이 많아서 관리에 어려움이 있다. -> 난잡하지 않은 툴로 tight하게 confluence를 사용
기획/디자인/퍼블리싱이 한 팀이다
신입사원은 신규툴 경험이 밥값을 하는 것이다
figma(**) or xd
화면설계 -> ao / bo
고객이 많을수록 figma의 표준은 더욱 더 중요해진다.
개발 설계는 죽는 추세, 스웨거에 자세히 적어서 기획자(이해관계자)들도 쓸 수 있는 정도로 만들어야 한다.(백 & 프론트 소통용도)
스웨거 작성 시 기준: qa(외부인)들이 프로젝트 말미에 봐도 스웨거를 봐도 알 수 있을 정도(parameter까지?? 대규모 프로젝트에서 고려..)
- sonar cube(관리 측면**)/ pmd (코드 품질 관리)
- sparrow(보안 솔루션)
결함 처리 -> jira
ga4 -> google merge shop
성능 모니터링 도구(오픈소스 기반이기 때문에 여러가지 알아두기) -> view 포인트들이 잘 갖춰진 도구 -> datadog(서버 모니터링), jennifer(비싸다), scouter(lg), 네이버에서 만든 것도 있음
요즘은 서버 모니터링(무한에 가깝기 때문에) 보단 서비스 모니터링이 중점적으로 본다.
요즘은 db 성능이 was를 못따라온다.(같은 비용이면 백에서 처리한다.) front는 client 환경을 많이 타기 때문에 일단 배제
(transaction 유지하는 동안) log를 통해서 ip, guid, sessionid를 같이 찍어서 사용자를 구별한다.
elasticSearch 통해서 log를 집계해서 ( 여러가지 rds를)
- 서버에는 log를 쌓지 않고 redis에 필요한 정보(log는 아니고 정보만?)들을 담는다. -> redis design도 중요하다(설명가능하게, ttl, trasaction을 유지하는 동안 보관한다.)
transaction이 시작될 때 db에 시작한 log를 db에 넣는다. (시작, 에러, 끝났을 때)
sonarCube -> 로그 레벨 설정 가능(보통 서버에선 error만 찍음)
crawling은 network 단에서 감지해서 모니터링
(excel 내보내기) -> 문서 보안 솔루션을 붙여서 내린다
한화의 경우 로그를 이중화 해서 관리 -> 하나는 단순, 하나는 중요도를 통해서 로그를 자세히
log는 분쟁의 소지를 해결하는 목적으로 많이 찍는다.
front: main에서 일정 주기에 refresh하면 (event listner)
web push를 통해서
화면 접속할 때마다 transaction을 통해서 dom tree 그릴때 알림 보냄(백에서 데이터를 보여줄 수 있음)
일정이 있는 날은 초록색으로 표시(비슷한 사용자 경험을 가지고 있기 때문에)
-> 10분, 15분전 front: main에서 일정 주기에 refresh하면 (event listner)
front(pinia도 디자인이 중요하다) 상태 관리는 aa가 한번에 관리해야한다(dba 개념) -> redux 대신 redis로 많이 관리한다(? 이해 잘 못함)
inMemoryDB도 좋긴 하다
업무를 파악하는 능력(실무)과 쿼리 짜는 능력이 중요하다
메뉴를 나누는게 보이는 것에서 의미가 있을까? 구현이 편한쪽으로 가자
고객의 비즈니스 흐름도를 고려해서 메뉴 단을 고려하면 된다.