2. 구상

춘 몽 2024. 11. 11. 09:12

2024. 11. 11. 09:12

728x90

smp 데이터 입력방식

종합소득세 계산 방법 고민

user에 role 넣었으니 토큰에 role 추가해줘야 할듯 (아직 role로 가드하는 path는 없음)

캐시 사용

2024.11.11

_ 08:56

테스트코드 작성을 끝냈다.

미뤄뒀던 구상에 대해서 생각해보았다.

처음에는 탈퇴하더라도 user데이터를 남겨서 해당 발전데이터를 활용하는 방안을 생각했었다.

하지만 여러 문제가 예상되었었다.

우선 데이터가 남는것에 대하여 사용자가 찝찝함을 느낄 수 있다.

그리고 user에 있는 비지니스넘버가 unique처리 되어있어서 나중에 다시 가입하려고 하면 이게 걸리게된다.

그리고 지금 생각해보면 더이상 업데이트 되지 않는 데이터가 과연 신뢰성이 있는가 싶기도 하다.

그래서 탈퇴시 softDelete가 아니라 그냥 delete 시켜버리는게 더 좋을 것 같다고 생각한다.

하지만 열심히 데이터를 넣었었는데 삭제했다가 변심이 생겨서 재가입하게되면 그 데이터 넣는걸 다시 해야되는 귀찮음이 있을 수 있으니, softDelete 처리하고, 재가입시 기존 아이디 다시 사용가능하게 하고, 7일 뒤에 삭제되도록 cron을 하는게 좋을 것 같다.

2024.11.06

_ ??:??

유닛 테스트 코드 강의 보고 따라서 적용해보기

기본적인 주석들 달아주기

2024.11.01

_ 01:03

커스텀 데코에 짜놓은 코드 기능별로 분리해놓으면 재사용성 더 좋아지고 깔끔해지지 않을까?

2024.10.31

_ 23:30

f~~ront에 여러 기능들을 service와 util로 만들어 두었는데 이것들을 class로 만들었다.~~

일단 CMWorld를 만들 때는 개념이 제대로 잡혀있지 않았고, 그때 썼던 방법을 그대로 사용하다보니 그렇게 된 거라서, 굳이 class로 만들 필요가 없다면 함수로 바꾸는게 낫지 않을까 하고 작업을 하려고 했다.

~~근데 함수로 만들게 되면 불편한점들이 더 많다는걸 알게되어서 작업을 취소하게 되었다.~~

class는 쉽게 묶음 처리가 가능하다. 예를 들어 다른 작업없이 Ex. 으로 안에 있는 기능들을 쉽게 가져올 수 있지만, 함수형으로 만들게 되면 이를 사용하기 위해 하나의 함수로 묶은 경우 return문을 사용해서 다른곳에서 사용할 함수들을 일일이 지정해줘야한다.

무엇보다 class는 static 처리된 것들은 다른곳에서 그냥 가져다 사용할 수 있지만, 함수의 경우 사용하는 곳에서 인스턴스화와 비슷하게 해당 묶음 함수를 정의한 후 사용해야한다. (const ex = Ex)

~~++ 정의를 안하고 사용할수는 있는데, Ex(). 으로 사용해야되서 안이쁘다..~~

Qwer().test1()
const qwer = Qwer()
qwer.test1()

~~정리하자면,~~

~~class는 class 내부에 작성한 기능들을 따로 처리할 필요없음.~~

~~함수는 return 처리를 해줘야함.~~

~~class는 static 들의 경우 인스턴스화없이 다른곳에서 바로 사용가능.~~

~~함수는 사용하는 곳에서 정의를 해준 후 사용해야하거나, 모양이 좀 별로임.~~

~~이러한 이유들 때문에 오히려 쉽게 사용가능한 class를 함수화 하지 않고 놔두기로 결정했다.~~

~~물론 내가 front(react)에 관해여 제대로 배우지 않아서 실사용적인 방법을 알지 못하여 이렇게 진행하는걸수도있다.~~

~~때문에 일단은 이렇게 마무리하지만, 나중에 react를 배우게 되고 실사용적이거나 더 좋은 방법을 알게된다면 그 방법으로 변경할 계획이다.~~

2024.10.30

_ 01:43

발전 데이터 수집해서 활용하는거 동의를 받아야 하는가?

조금 알아보니 일반적으로 가입시 동의하는 개인정보 수집 동의는 개인정보를 특정할 수 있는 정보를 수집할 때 동의하는거라서, 나는 소셜 로그인도 카카오와 네이버는 사용자의 소셜 이메일 주소를 주지 않기 때문에 해당 소셜에서 주는 id값을 사용하고 있고, 사업자번호는 진짜 사용자인지 구분하기 위한 식별 목적이고, 나머지 중 사용자 특정되는 데이터는 없고, 발전 데이터 역시 개인특정 정보가 아닌데다가 이를 활용해서 통계를 낼 계획이기 때문에 딱히 문제가 되지는 않는다는 1차 결론을 내렸다.

2024.10.29

_ 20:26

REC는 발급할 때 남은 양을 다음 REC에 더하여 발급하는 계산 때문에 처음 REC 발급 데이터부터 필요했으며, 이를 만들기 위한 solar 데이터가 처음부터 필요했다. 즉, 내발전소는 매번 모든 발전량의 데이터가 필요했고, 이를 매번 요청하고 받는건 데이터의 낭비라고 생각했다.

그래서 로컬에 데이터를 저장하고, 서버와 업데이트 날짜를 비교하는 방식으로 데이터의 양을 줄일까 했었다.

하지만 그전에 과연 이게 이득인지 체크해보았다.

데이터를 모두 지우고 유저정보만 넣었을때와 태양광, rec 데이터만 1년 넣은 데이터를 비교했고, 그를 바탕으로 10년 데이터가 쌓였을 때 크기를 예측해보았다.

const response = await sppApiService.fetchSpp();
    const dataSize = new TextEncoder().encode(JSON.stringify(response)).length;
    console.log(response);
    console.log(`dataSize: ${dataSize}Btye`);
    console.log(new Date());

기본: 853 Btye

2023년 12개월: 3,464 Btye

1년: (3,464 - 853) = 2,611 Btye

10년: 26,110 Byte ≒ 25.5 KB

현재 AWS 프리티어 기준 1달에 100GB가 무료이므로 대충 계산했을 때 1달에 10년치 데이터를 4,000,000번은 통신할 수 있다.

이정도의 여유가 있고, 당장 내가 만들 서비스에 이정도의 통신이 발생하지도 않을 것이며, 이를 위해서 서버와 DB의 통신(데이터 업데이트 될때마다 업데이트 날짜 DB에서 변경하는 등)의 부하를 발생시킬 필요가 없다고 판단되었다.

그리고 나중에는 개인적으로 AWS가 아니라 NAS 같은거에 서버를 올리는 것도 생각하고 있으니 더욱 당장 필요한 기능이 아니라고 판단하고, 이건 패스하기로 했다.

2024.10.28

_ 21:50

REC를 판매할 때도 거래 수수료가 발생한다는걸 알게되었다. REC 발급과 마찬가지로 100kWh 미만은 수수료 면제이다.

이를 rec판매에 추가하고, tax에 반영해야한다.

2024.10.22

_ 02:44

강의를 보다보니 cascade라는 기능을 알게 되었다.

현재 SPP의 회원가입은 Auth와 User가 분리되어있고, 회원가입/로그인 시에 User 테이블의 Pk인 userNumber를 반환해줘야해서 회원가입을 하면 Auth에 컬럼을 만들면서 이와 OneToOne 단방향 관계된 User 컬럼을 같이 생성해주는 로직으로 인해 QueryRunner를 사용중이었다. 이걸 cascade로 바꿀 수 있어보인다.

2024.10.18

_ 01:25

강의를 보다보니 10월 12일 생각하고 적용했다 롤백했던 부분 다시 생각해볼 필요 있을듯.

back, front 중복 코드들 어느정도 제거 될 것 같긴한데, 코드에서 매개변수로 넘기는 데이터들 명칭이 다른게 확실히 보기는 좋은듯.

2024.10.14

_ 23:26

코드팩토리 nest 강의 Relationship 강의 듣고보니 구조를 바꿀 필요성이 느껴짐.

ManyToOne은 강의, 공식문서(https://typeorm.io/many-to-one-one-to-many-relations)와 같이 바꿨고 (앞서 적용했던 entity extends 확장법은 삭제),

OneToOne은 JoinColumn을 User에서 Auth로 바꾸거나 양방향으로 바꾸는식으로 코드를 덜어 낼 수 있을 것 같아서 relationship 강의들 다 본 후, 구조 생각해보고 바꿀 계획 => JoinColumn을 User에서 Auth로 변경

2024.10.12

_ 01:40

~~entity extends 사용해서 확장하는법 공부한걸로 교체하기~~

2024.10.10

_ 02:40

tax 부분에 총합을 넣어서 1년 매출, 매입, 부가가치세 총합 표시해주기

2024.09.26

_ 23:22

프론트에서 입력 데이터 0미만 인지 체크

백에서 입력 데이터 빈값인지, 0미만인지 체크

백에서 날짜를 string과 date 혼합으로 쓰다보니 체크하는 부분이나 사용하는 부분에서 복잡도가 올라가서 string으로 통일

2024.09.23

_ 18:08

데이터를 그냥 보여주기만 하니 같은 형식이 계속 반복되어서 가독성이 떨어졌다.

그래서 분기별로 배경색을 입혀 조금더 쉽게 분간이 가능하도록 하는게 좋겠다.

한전 사정으로 발전량 x smp 가격으로 공급가액을 주지 않고, 그보다 적은 가격을 준 적이 한 번 있었다.

때문에 발전량 x smp와 공급가액을 비교하는 장치를 적용해서 다르면 빨간색으로 배경표시를 했는데, 이게 3년차인 지금까지 한 번 있었기 때문에 결과값이 같은 값들을 굳이 2번 보여줄 필요는 없을 듯 싶다.

그래서 발전량 x smp 보여주던건 제거하고, 값 비교해서 다르면 배경을 빨간색으로 표시하는 기능만 유지하는게 보기 좋을듯 싶다.

그냥 데이터 추가하는 공간만 있다 보니 어떤 데이터를 넣어야 되는지 특히 날짜가 어떤 날짜를 말하는지 헷갈릴 수 있기 때문에 입력해주는 데이터가 무엇인지 표시해줄 필요있음. + rec가중치 표시해주기

2024.09.22

_ 22:24

날짜 데이터를 처리하려고 보니, 굳이 년,월,일로 데이터를 나눠서 저장할 필요없이, 그냥 date 데이터로 처리할 수 있다는걸 깨달았다. 내가 왜 그전까지는 몰랐지?? 아마 처음 시작인 태양광은 년과 월만 입력하다보니 자동으로 일이 1일로 처리되서 데이터가 저장되는걸 몰랐기 때문에 이걸 나눠서 저장해야지했고, 나머지도 그렇게 진행했던것 같다.

다시 수정하자..

2024.09.11

_ 17:01

분기별 부가가치세 계산하는거 계산값이 실제와 다르길래 살펴보니, 태양광 발전 데이터가 좀 문제다.

태양광 발전 데이터의 소득이 정확히는 발전한 다음달에 들어오는 소득이다.

무슨말이냐면 예를 들어 1월에 발전을 했다면, 이를 한전에서 구매하고 그에 따른 전자(세금)계산서 발급은 2월에 이루어진다.

때문에 그에 따른 소득 역시 2월에 잡힌다.

이를 앞서 말했듯이 실제 발전 데이터는 한달뒤에 소득으로 잡힌다.

때문에 발전데이터만 본다면 1~12월의 데이터를 보여주는게 맞지만, 부가가치세와 종합소득세 등의 수익에 따른 계산에 맞는 데이터를 보여주기 위해서는 작년12월~올해11월의 데이터를 보여주는게 맞다.

그래서 데이터를 어떻게 보여줄지 고민하다가 내 발전소의 목적은 세금 예측 계산에 좀 더 중점을 두었기 때문에, 작년12월~올해11월의 데이터를 보여주려고 한다. 그렇다면 발전년월과 데이터 입력 년월들 보여줘야할까? 발전년월만 보여줘야할까? 발전년월만 보여준다면 헷갈리지 않게 발전년월로 적어서 페이지에 보여줘야할까? 이러한 생각부터해서, 데이터를 입력받을 때 발전년월의 데이터를 받아야할까? 아니면 소득이 발생하는 년월의 데이터를 받아야할까? 그렇게 한다면 또 데이터 계산 처리 방식은 어떻게 해야할까? 이러한 고민의 생각이 계속되었었다.

이게 좀 복잡했던게, 세금 계산서 발급을 개인이 직접하는 것이기 때문에 발전 다음달 25일까지 발급을 하면 이상이 없는데, 만약 25일 이후 혹은 그 다음달에 발급된건 어떻게 처리해야지 하는 생각에 발전년월과 일자를 따로 입력받아야하는지 등을 생각했었다. 하지만 결과적으로 너무 여러가지 이상 상황에 대한 대처를 하자면 끝도 없고, 너무 난잡해지기 때문에 적당한 표준내에서 처리하는걸 선택했다.

그래서 결론은 발전년월의 데이터를 받고, 페이지에도 년 월 이아니라 발전년 월 이라고 바꾸고, 데이터는 발전년월로 데이터를 받으려고 한다.

2024.09.07

_ 15:08

HTTP API 설계 예시를 보고 나니 restapi 설계를 너무 get과 post로만 해놓은 것 같아서 변경이 필요해보인다.

예를 들어 solar 데이터를 추가하고 삭제하는걸 각각 addSolar, deleteSolar로 명해놓았는데, 이를 주소는 solar 한개로 해놓고 put과 delete로 보내고 받으면 uri가 더 깔끔해질 것 같다.

대신에 react에 만들어 놓은 통신 방법에 put과 delete를 추가하고, uri들을 변경해야한다..

https://www.inflearn.com/course/lecture?courseSlug=http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC&unitId=61369&category=questionDetail&tab=curriculum

학습 페이지

www.inflearn.com

2024.07.11

_ 20:22

rec 판매 부분을 만들었는데, 태양광과 다르게 날짜에 일 까지 들어가다보니 정렬 순서가 년 => 일 => 월 순으로 되었다.

순서가 안맞는 원인을 파악하고 수정하면서, 이것저것 생각하다보니 다른 문제점을 찾게 되었다.

로그인 할 때 유저테이블을 조회하지 않기 위해 auth 테이블의 uid를 그대로 refeshToken에 넣었는데, 때문에 각 spp데이터에 uid 컬럼이 생기고 이를 통해 user 테이블과 연결하게 되었다. (안그러면 user테이블에서 uid를 조회하고 이걸로 다시 데이터를 조회해야하니깐..)

그러다보니 각 데이터에 uid가 계속 들어가게되서 필요없는 데이터가 증가와 uid의 노출 문제가 있는걸 발견했다.

사실 처음 db를 배울때는 일반 쿼리문을 사용하는 방법을 배웠다보니 join 테이블에 FK가 있어야 했지만, TypeORM은 그럴 필요가 없다보니 필요가 없었는데, 아무래도 TypeORM을 제대로 배운게 아니다보니 쓰면서 계속 헷갈리고 그래서 내용이 번복되고 그러는것 같다.

무튼, 결론은 로그인 할 때 user 테이블의 조회를 안하려고 uid로 처리되었던 부분때문에 필요없는 데이터가 증가하고 있기에, 효율을 봤을 때 로그인 할때 user 테이블을 조회하도록 하고, 앞서 uid로 처리되었던 부분들을 전부 수정해서 필요없는 데이터의 양을 줄여야할 듯 싶다.

다시 말해서 부분적으로 좀 갈아 엎어야 한다..ㅎㅎ

2024.07.08

_ 02:03

rec를 발급받을 때 100kWh 미만은 발급 수수료가 면제다. 그리고 가중치에 따라 발급되는 양도 달라진다.

때문에 DB 유저정보 테이블에 발전설비 정보와 가중치 컬럼을 추가하고, 내발전소 접근시 이를 체크하고 없으면 입력하도록 하는 장치가 필요해졌다.

나중에 다른 발전소 데이터를 보려면 사업자번호 등록을 통해 주소도 넣어줘야하는데 이번 기회에 한번에 처리할까 싶다.

무튼, 발전정보와 가중치 정보있나 체크해서 입력받는거랑, 해당 정보 바탕으로 rec 발급 계산하도록 코드 수정 필요하다.

2024.07.06

_ 23:18

rec에 대해서 구상하면서 rec의 발급 계산방법 같은것 좀 알아보고 했더니 발전량(kWh) / 1000 x 가중치 이고, 소숫점 이하는 이월되는식이었다. 그렇다면 rec 발급에 대해서 굳이 직접 입력할 필요없이, 태양광 발전 입력에 따라서 자동 계산되서 나오면 될것같다.

그럼 일단 페이지 구조가 원래 생각했던 것에서 좀 바뀌어야한다..

그리고 세금이나 분기데이터 역시 계속 업데이트 되는 데이터로 계산되어야 하므로, redux로 관리를 해야할것 같다.

그럼 데이터 흐름도 다시 생각해봐야 할것 같다.

너무 시작을 그냥 해봐야지 하고 했던 터라, 중간중간 생각할게 많아져서 구현 속도가 뎌디다.

예전에 인터넷에서 진짜 개발자는 코딩하는 시간보다 생각하는 시간이 더 많다던데 그걸 느끼고 있다..ㅎㅎ

2024.07.05

_ 12:46

와.. 전에거 쓴 날짜를 보니 너무 손놓고 있었나 싶다..

REC를 작업하려고 보니, 실제로는 REC를 발급하는것과 파는것 두가지가 나뉘는데, 발급하는것은 매달 태양광 발전에 따른 발급이 이루어지기 때문에 매달 한번 주기적으로 이루어진다. 반면 REC 판매는 주식같은 개념이라 매주 화, 목에 자신이 원하는 만큼 판매가 가능하다.

나 같은 경우에는 부모님의 일을 대신해주고 있는 상황이고, 부모님께서는 그냥 한번에 다 팔길 원하셔서 매달 한번씩만 판매 거래가 이루어지지만, 이건 내 경우고 실제로는 여러번 거래가 이루어 질 수도 있다.

나 같은 경우는 발급과 판매를 그냥 하나로 묶어서 처리하는게 좋지만, 실제를 생각하면 발급과 판매를 따로 관리하는게 맞다고 생각한다.

따라서 위에 있는 Front 페이지를 변경해야한다... 아마 이것때문에 손이 덜 갔던것 같다..

일단 태양광, REC, 고정지출. 이렇게 3개로 이루어진걸 태양광, REC(발급/판매)로 나누고, 그 밑에 지출(고정/일반) 으로 나눠줄 계획이다.

더불에 이 페이지의 목적 중 하나였던 예상 세금 내역을 어디에 어떻게 보여줄지도 생각해봐야한다.

2024.06.20

_ 18:29

중간 내용 많이 스킵하긴 했지만, 무튼 엑세스토큰, 리프래시토큰 사용하는 소셜 회원가입/로그인, 로그아웃, 회원탈퇴 구현했고, 이제 개인 발전정보 등록하는거 구현하면 된다.

일단 아래 같은 모양으로 만들어볼까 한다.

2024.06.10

_ 13:20

일단 인증방식의 회원가입부터 만들어보자.