[개발일지] - 284

오늘은 자바서버를 돌려보려고 했는데

오자마자 아무것도 없는 상태로 톰캣을 설치한 다음

라이브 서버를 작동시켰지만 8080이 점유중이라 에러가 발생했고

8079로 생성 후 정상 작동하는 것을 확인할 수 있었다.

 

해당 index.java 파일을 꾸며서 html이 조금 더 예쁜 페이지로 바꿨는데

사실 이게 리액트랑 무슨 큰 차이가 있는지는 모르겠고

자바서버랑 이게 무슨 관계가 있는지도 잘 모르겠지만

예전에 node.js를 통해서 express로 rest api 서버를 만든 것처럼

이걸로도 rest server를 작동시키는 구조라고 대충 이해했다.

 

다음 단계로 넘어가고 싶었지만 안타깝게도 인터페이스 프로젝트 요청이 들어왔고

프로젝트 요청에 대한 테이블을 확인하는데 이번에는 인터페이스 유지보수가 들어왔다.

 

점심먹을 시간도 없이 인터페이스 요청사항을 처리하고

요청사항 외에 추가 작업을 알아서 했는데 그 부분에도 원래 없던 요청을 추가로 해서

남들보다 30분쯤 늦게 점심을 먹으러 출발할 수 있었다.

 

오후에는 에러가 발생했다는 유지보수가 접수되었기 때문에 에러를 해결했는데

사실상 해결이 뭔가 시원치 않고 원인이 제대로 파악되지 않았다.

 

원인 파악을 하던 도중 추가 업무가 할당되어버렸는데

프로젝트 7개에 엮여있는 상태에서 하나 더 추가로 8개가 되어버리니

당장은 3개지만 사실 마무리 단계에서 문제가 생기면 바로 투입되어야 하는게 2개고

시작하면 다시 달려야 하는 프로젝트가 3개가 대기중이기 때문에

안그래도 계속 바쁜데 더 더 더 바쁠 예정으로 보인다.

 

추가 인터페이스 업무 배정 및 관련 회의에 참석했는데

다행히 해당 인터페이스는 5월 초쯤 시작할 것 같고

프로젝트 자체는 다음주부터 바로 시작되지만 담당자 배정이었던 것 같다.

 

인터페이스 문제만 해결하고 원인은 파악이 되지 않았지만

구조 파악까지 끝내도 우리의 잘못이 없는 것 같았기 때문에

뭔가 석연치 않지만 그냥 유지보수로 인한 배포를 많이 했기 때문에

일시적으로 값이 몇번 빠져서 인터페이스가 진행되어서 그런가보다 하고 넘어갔는데

얼마 후 같은 문제가 또 발생했다고 문의가 들어왔다.

 

이번에는 인터페이스 로그도 없었기 때문에 문제의 원인을 확실히 파악할 수 있었는데

당연히 들어와야 하는 경로가 아닌 개인 계정 경로를 통해서 인터페이스가 들어왔고

그 부분은 발송하는 SAP쪽에서 처리하는 부분이기 때문에 우리 잘못은 아니었다.

 

해당 내용은 서버 접근 가능 시간대가 있기 때문에 오늘 처리가 불가능하다고 했고

그 전화를 6시쯤 받았기 때문에 결국 저녁을 먹게 되었다.

 

저녁도 먹은 겸 계속 업무를 진행하는데

이번에는 프로젝트 인터페이스 관련 맵핑을 파보기로 했다.

 

사실 초반에는 팀장님이 알아서 처리해주시기도 했고

그 외에도 인터페이스가 짱짱한 곳들에서 알아서 정의를 잘 해줬는데

이번에는 그냥 본인들이 쓰고싶은 필드명만 적어서 보냈기 때문에

어떤 객체와 연결되는지도 전혀 알 수 없었는데

다행히 특정 개체와 유사한 점을 찾아서 고객사에 문의한 결과 해당 개체가 맞았고

안타깝게도 인터페이스 하려는 필드와 대상 개체의 필드가 상당히 달랐기 때문에

전체 맵핑작업을 진행해야 했다.

 

일단 동일 이름이 있어도 전혀 다른 이름과 매칭되는 경우도 있고

리밋이 5글자인데 필드 정의서는 50글자인 경우도 있어서 상당히 당황스러웠는데

이 부분은 SQL 서버에 들어가서 한참 뒤져봐서 테이블을 찾고

해당 테이블의 실제 값들과 SFDC의 레코드 값을 비교해 매칭을 시작했다.

 

처음에는 테이블을 찾는게 너무 어려웠지만

인터페이스에 써있는 개체명을 그냥 쿼리에 얼추 적고 자동완성으로 뜨는 테이블을 잡은 다음

내부 필드들이 얼추 맞는지 확인하는 방식으로 개체를 찾을 수 있었다.

 

여기서 다시 한번 어이가 없었는데

본인들이 인터페이스하겠다고 언급한 필드가

인터페이스를 하기 위한 테이블의 필드와도 매칭되지 않았었다.

인터페이스 테이블, 인터페이스 정의서, SFDC 개체 필드가 모두 다른 대환장 파티에서

일부 필드들을 실제 값 기반으로 매칭시키다가 팀원분이 도움을 요청하셔서 같이 확인했다.

 

문제가 되는 부분은 등록되지 않은 IP로 NICE PAY에 접속을 시도하려고 했던 것인데

일단 유사한 키워드로 검색을 한 결과 고정 IP 또는 공인(공공??) IP가 아닐 경우거나

그냥 IP는 같지만 비행기모드로 껐다 켜야 되는 경우도 있다고 하고

핸드폰 핫스팟을 켜서 해당 주소로 접속했다가 다시 돌아와서 재할당을 받는다는 이야기도 있고

네트워크 설정에 들어가서 도메인 수동할당이 되어있는지 확인하는 것과

컴퓨터를 재시작해서 다시 할당하는 방법 등 여러가지 방법을 모두 시도해도 제대로 되지 않았다.

 

중간에 내자리에서도 테스트를 해보고 싶었기 때문에

해당 postman collection을 받아서 실행했는데 당황스럽게도 바로 작동했기 때문에

더더욱 위 방법으로 뭔가 꼬여있는 IP를 복구하려고 했던 것인데

보던 도중 postman이 웹으로 작동하고 있는 모습을 보고 문득 웹과 앱의 차이인가 싶어졌다.

 

이번에는 내가 앱이 아닌 웹으로 실행하니 동일한 IP 미등록 에러가 발생했고

그걸 보고 드디어 앱을 설치하고 작동시키니 정상적으로 인터페이스가 되는 것을 볼 수 있었다.

 

이걸로 알게 된 점은 일단 IP가 꼬일 수 있고 그걸 해제하는 방법들과

postman을 웹으로 사용할 경우 SFDC에서 SFDC IP 해제를 요청하는 것처럼

postman의 IP에서 해당 리퀘스트가 날아갈 수 있기 때문에 앱으로 해야 한다는 것을 배웠다.

 

추가 맵핑작업을 조금 더 진행하다 8시가 넘어서 페이지, SQL, 메모장, vscode 등을 정리 후 퇴근했다.

 

 

 

(1).백준 27330번 点数 (Score)는 상당히 특이한 문제로

주어진 점수를 계속 더하다가 더한 값이 주어진 4번째 줄에 포함된 숫자인 경우 초기화해야 하며

초기화 여부와 관계없이 덧셈을 계속 진행하며 최종 값을 구해야 하는 문제였다.

 

딱히 한번 제외한 값을 없애는 등의 패널티는 없었기 때문에

includes를 사용해 포함 여부를 체크하며 계속 더해서 문제를 해결했다.

const input = `5
1 4 1 4 2
3
1 3 5`.split('\n').map(el => el.split(' ').map(Number))

let result = 0

for(let i = 0 ; i < input[1].length ; i++){
    result += input[1][i]
    if(input[3].includes(result)){
        result = 0
    }
}

console.log(result)