블로그

왜 내 배치는 로컬 JobParameter로 실행됐을까?

신규 배치 잡을 개발하면서, 로컬에서 먼저 실행해 정상 동작을 확인한 뒤 개발 서버에 배포해 실행해보았다.그런데 이상한 문제가 발생했다.배치 실행 시 항상 로컬에서 사용했던 JobParameter로만 실행되는 것.Jenkins에서 jobParameter를 넘겨 실행해도, 스프링 배치는 계속 로컬에서 실행한 JobParameter를 고정해서 사용했다.새로 만든 잡에서는 동일 JobParameter로도 배치를 반복 실행할 수 있도록 RunIdIncrementer를 사용한다.이 incrementer는 run.id를 자동으로 증가시켜 새로운 JobInstance를 만들 수 있게 해주는 기능이다.그런데 RunIdIncrementer로 인해 run.id는 정상적으로 1, 2, 3… 증가하는데,정작 내가 설정한 jobParameter가 아니라 로컬에서 실행한 파라미터만 계속 적용되고 있었다.그래서 원인을 제대로 파악해 보기로 했다.RunIdIncrementer는 정확히 무엇을 할까?스프링 소스코드를 보면 역할은 매우 단순하다.public JobParameters getNext(@Nullable JobParameters parameters) { JobParameters params = (parameters == null) ? new JobParameters() : parameters; JobParameter<?> runIdParameter = params.getParameters().get(this.key); long id = 1; if (runIdParameter != null) { id = Long.parseLong(runIdParameter.getValue().toString()) + 1; } return new JobParametersBuilder(params).addLong(this.key, id).toJobParameters(); } 즉:기존 JobParameter에서 run.id가 있으면 +1없으면 1그 외 나머지 JobParameter는 건드리지 않고 그대로 사용즉, RunIdIncrementer는 오직 run.id만 증가시키고그 외 파라미터는 건드리지 않는다.그럼 “그 외 파라미터”는 어디서 오는 걸까?JobParametersBuilder.getNextJobParameters스프링은 다음과 같은 순서로 JobParameter를 만든다.JobInstance lastInstance = jobExplorer.getLastJobInstance(name); JobExecution previousExecution = jobExplorer.getLastJobExecution(lastInstance); nextParameters = incrementer.getNext(previousExecution.getJobParameters()); ... nextParametersMap.putAll(this.parameterMap); // 현재 실행 파라미터 우선 요약하면:이전에 실행한 동일 Job의 JobParameter를 조회한다.RunIdIncrementer로 run.id를 증가시킨 nextParameters를 만든다.이번 실행에서 전달한 jobParameter를 맨 마지막에 merge한다. (가장 높은 우선순위)즉 스프링 배치의 JobParameter 우선순위는 다음과 같다.Spring Batch JobParameter 우선순위이전 실행의 JobParameterIncrementer(getNext) 결과이번 실행 시 전달된 JobParameter (최우선)그렇다면 이번 실행에서 넘겨준 파라미터가 최우선인데 왜 적용되지 않았던 걸까? 전달되지 않을 것 같아 배치 실행 부분을 살펴봤다.문제의 진짜 원인: Jenkins → Docker 실행 시 파라미터가 전달되지 않음스프링 배치 로직상으로는 “이번 실행 파라미터가 가장 우선순위”가 맞다.그런데 실제로 Jenkins에서 JobParameter를 넘겨줘도 실행 결과에는 반영되지 않았다.조사해보니:Jenkins가 전달한 jobParameter를 Dockerfile 내부에서 배치를 실행할 때 넘겨주지 않고 있었다.즉,Jenkins → Docker run → Spring Boot이 체인을 따라 파라미터가 전달되지 않아서스프링은 “이번 실행 파라미터 없음”그럼 당연히 이전 JobParameter를 그대로 가져다 씀incrementer는 run.id만 증가결과적으로 run.id만 달라지고 나머지는 로컬 실행 때의 파라미터가 계속 유지됨그래서 Dockerfile을 수정해 Jenkins에서 받은 파라미터를 그대로 전달해 실행하도록 수정했고문제는 바로 해결되었다.결론1) RunIdIncrementer는 run.id만 올려주는 단순한 기능이다.다른 파라미터는 절대 건드리지 않는다.2) Spring Batch는 이전 실행의 JobParameter를 기본값으로 사용한다.그리고 incrementer를 적용한 뒤,이번 실행 파라미터를 merge한다.3) 이번 실행의 JobParameter가 적용되지 않은 이유는Dockerfile에서 파라미터를 누락해서 전달되지 않았기 때문.4) 따라서 Jenkins → Docker → Spring Boot 실행 구조를 사용할 때는반드시 jobParameter 전달 경로를 점검해야 한다.

PostgreSQL alias는 소문자로 나오는데 DTO 매핑은 잘 될까?

TL;DRPostgreSQL은 따옴표 없는 alias를 전부 소문자로 변환하지만,JDBC 드라이버의 findColumn()은 대소문자를 구분하지 않고 컬럼을 탐색하며,SimplePropertyRowMapper는 DTO 필드명 그대로→snake_case 순으로 컬럼을 찾는다.덕분에 AS blogId로 alias를 줘도 DTO의 blogId 필드로 정확히 매핑된다.예를 들어 다음과 같이 Spring의JdbcClient 를 사용해 PostgreSQL 쿼리 결과를 Kotlin data class로 매핑한다고 해봅시다val sql = """ SELECT t.parent_id AS blogId, t.id AS tagId, t.name AS tagName FROM tags t """.trimIndent() jdbcClient.sql(sql) .query(TagByBlogDto::class.java) .list() 그리고 매핑 대상은 아래처럼 단순한 data class입니다data class TagByBlogDto( val blogId: Long, val tagId: Long, val tagName: String, ) PostgreSQL은 AS blogId를 내부적으로 소문자(blogid) 로 변환하지만,JdbcClient는 이 컬럼을 TagByBlogDto.blogId에 정확히 매핑합니다.어떻게 이런 일이 가능한 걸까요?PostgreSQL alias 규칙PostgreSQL 공식 문서에 따르면 👇“Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case.For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL,but "Foo" and "FOO" are different from these three and each other.”— PostgreSQL Docs: Identifiers and Key Words즉,AS blogId → 내부적으로 blogidAS "blogId" → 대소문자 그대로 유지작성 형태 실제 인식되는 이름 AS blogId blogid AS “blogId” blogId AS BLOGID blogidJdbcClient는 어떤 매퍼를 사용할까?JdbcClient는 .query(Class<T>) 호출 시 내부적으로SimplePropertyRowMapper 를 사용합니다 👇public <T> MappedQuerySpec<T> query(Class<T> mappedClass) { RowMapper<?> rowMapper = rowMapperCache.computeIfAbsent(mappedClass, key -> BeanUtils.isSimpleProperty(mappedClass) ? new SingleColumnRowMapper<>(mappedClass) : new SimplePropertyRowMapper<>(mappedClass) ); return query((RowMapper<T>) rowMapper); } 즉, TagByBlogDto처럼 DTO를 넘기면new SimplePropertyRowMapper<>(TagByBlogDto.class)가 생성되어 필드 단위로 매핑됩니다.SimplePropertyRowMapper의 동작 원리SimplePropertyRowMapper는 생성자 파라미터명을 기준으로 ResultSet에서 컬럼을 찾습니다.핵심 부분은 아래와 같습니다 👇for (int i = 0; i < args.length; i++) { String name = this.constructorParameterNames[i]; int index; try { // ① 필드명 그대로 컬럼 탐색 (예: blogId) index = rs.findColumn(name); } catch (SQLException ex) { // ② 실패 시 snake_case 변환 (예: blog_id) index = rs.findColumn(JdbcUtils.convertPropertyNameToUnderscoreName(name)); } Object value = JdbcUtils.getResultSetValue(rs, index, td.getType()); args[i] = this.conversionService.convert(value, td); } 즉, 매퍼는 다음 순서로 필드 매칭을 시도합니다:findColumn("blogId")실패 시 findColumn("blog_id")PostgreSQL JDBC 드라이버(PgResultSet)의 findColumn 로직이제 핵심입니다.PostgreSQL JDBC 드라이버는 ResultSet.findColumn() 호출 시 대소문자를 모두 무시하고 컬럼을 찾습니다.아래는 실제 PgResultSet 코드 일부입니다private int findColumnIndex(String columnName) { Integer index = columnNameIndexMap.get(columnName); if (index != null) return index; // 1️⃣ 소문자 비교 index = columnNameIndexMap.get(columnName.toLowerCase(Locale.US)); if (index != null) { columnNameIndexMap.put(columnName, index); return index; } // 2️⃣ 대문자 비교 index = columnNameIndexMap.get(columnName.toUpperCase(Locale.US)); if (index != null) { columnNameIndexMap.put(columnName, index); return index; } return 0; } 즉, rs.findColumn("blogId")를 호출하면 드라이버가 내부적으로blogId, blogid, BLOGID를 모두 비교하기 때문에 일치하게 됩니다.

[인프런 클론 6주 완성 챌린지] 불안으로 인한 미루기 및 해결 시도

불안이 또 찾아왔다.개인적으로 데드라인에 대한 불안으로 일을 그르친 것이 한두번이 아니었다. 고질병이었던 불안으로 인해 나는 일을 미루는 습관을 가지고 있었고 간단한 일조차도 너무 크게 느껴졌다.(글을 잘 쓰려고 하지 말자. 사실은 지금도 불안하다.)나는 분명 저번에 불안한 일들에 내 자신을 노출시키면서 어느 정도 해결되었다고 생각했는데 웬걸, 이번 주에 챌린지 1주차 과제 마감 때문에 또다시 불안이 찾아왔고 3일 동안 벌벌 떨며 기본 세팅을 미루었다.그러다 어떤 글을 봤는데 나와 비슷하게 불안을 느끼는 사람의 글이었다. 본인이 불안할 때 아무 생각 없이 딱 할 수 있는 부분을 시작한다고 한다.이 글을 보고 목표를 바꿨다. 원래는 챌린지를 통해서 백엔드 프로젝트를 기획하고 기능 구현하고 배포하는 것과 관련된 문제 해결 능력을 기르려고 했는데, 다 필요없고 일단 챌린지를 따라치되 일부 디테일에서 변주를 주는 것을 목표로 하고 있다. 예를 들어 원래는 Configuration을 config server를 따로 구성하면서 삽질해보고 싶었는데, 아니 지금도 그렇게 해보고 싶은데 다 포기하고 강의에 나온 .env 파일로 해결하려고 한다. 변주를 주고 싶은 부분의 예는 db 스키마에서 pk이다. 아무리 불안핑이어도 uuid pk는 쉽지 않기 때문에, 아니 실은 bigint pk, uuid pk를 둘 다 잘 몰라서 bigint row_id (pk) + uuid entity_id (index) 조합으로 실험해보고 싶고 이 정도는 해도 될 것 같아서 이 정도의 변주만 주려고 한다.아래 글은 다른 글인데 나중에 읽으려고 추가합니다. 공감되는 부분도 많고 나중에 시도해볼 부분도 많은 것 같습니다.https://brunch.co.kr/magazine/discipline

테스트

123

[학습일기] HTTP 서비스 인증/인가 관련 이해한 내용 정리

들어가며인증과 인가와 관련해서 공부를 할 때 원리가 이해가 안 되어서 로그인과 CSRF와 같은 개념을 그냥 예시를 통해서 귀납적으로 학습하는 데에 그쳤다. 당연히 뭔가 답답한 느낌이 들었고 CSRF의 경우 외우고 까먹고를 반복했다.그러다가 최근에 갑자기 이 내용이 이해가 되었다. 방금 깨달은 사람의 따끈따끈한 이해를 말아드리고 싶어서 이 블로그글을 작성하게 되었다. (이랬는데 알고 보니 틀린 이해일 수도 있습니다ㅠㅠ 혹시 틀린 부분을 발견하시면 댓글 달아주시면 감사합니다!!)이해한 부분네트워크 서비스의 인증 및 인가와 관련해서 이해하는 데 개인적으로 다음 활동이 굉장히 도움이 많이 되었다.특정 사용자를 인증하기 위한 필요충분조건을 논리식으로 작성하기특정 서비스의 사용을 인가하기 위한 필요충분조건을 논리식으로 작성하기 이 관점에서 인증 및 인가를 다음과 같이 정리하게 되었다.인증(Authentication, Authn)정의위키피디아에서 찾아본 인증의 정의는 다음과 같다.특정 사용자의 본인확인을 증명하는 과정. 다시 말해, 특정 사용자가 본인이라고 주장하는 사람이 맞는지 확인하는 과정인증이라는 개념이 왜 필요하게 되었는지를 웹 서버의 입장이 되어 생각해보자.일반적인 웹 서비스에서 사용하는 웹 서버의 경우 대부분의 ip로부터 요청을 받을 수 있다. 비유하자면 불특정 다수로부터 쪽지를 받는 것과 같다. 다음 쪽지를 받았다고 가정해보자.안녕하세요, 미스터 비스트 유튜브 팀에서 연락드렸습니다.저희가 이번에 만들고 있는 영상에 초대드리고 싶습니다.아래의 주소에 접근해서 설명을 따라 주시면, 다음 영상에 출연하실 수 있습니다.https://example.com?phishing=true문제가 한두개가 아니다. 일단 미스터 비스트가 내게로 연락을 보낼 리가 없고, 글솜씨가 허접하다. (글쓴이의 글쓰기 스킬 이슈입니다.) 하지만 웹서버 입장에서 중요한 문제는 따로 있다. 본인이 알고 있는 주소에서만 접근하는 것도 아니고 불특정 다수의 ip 주소로부터 HTTP 요청을 받기 때문에 요청을 보낸 것이 실제 미스터 비스트인지 미스터 비스트인 척 하는 김 아무개씨인지를 확인할 방법이 없다. 다시 말해 웹 서비스에 가입한 특정 사용자 A가 있을 때, 본인이 사용자 A라고 주장하는 요청이 실제 사용자 A가 보낸 것인지 아닌지 확인하는 과정이 필요하다. 이런 맥락에서 인증이라는 개념이 자연스럽게 필요해진 것 같다.간단한 웹 서비스에서의 사용자 인증비밀번호를 통한 인증소개 및 필요충분조건웹 서비스를 누군가는 처음 만들었을 것이다. 만들면서 인증에 대한 문제를 다음과 같이 풀 생각을 하지 않았을까? (즉, 뇌피셜입니다.)인증의 문제를 다음과 같이 해결하면 어떨까?하나, 사용자 A가 가입하는 시점에 A와 웹 서비스 둘이서만 아는 비밀번호를 공유한다.둘, 앞으로 HTTP 요청을 보낼 때 본인이 A라고 주장하며 동일한 비밀번호를 제시하면, 그 사람은 A라고 유추할 수 있다.현재까지의 사고 과정을 필요충분조건으로 정리하면 다음과 같다.(사용자 A 인증) <=> (HTTP 요청 시 A의 비밀번호가 제시됨)문제점위의 인증 방식은 조금만 생각해보면 사용성 또는 보안에서 엄청난 문제점이 있는 것을 확인할 수 있다. 웹사이트에 요청을 보낼 때마다 비밀번호를 제시해야 하기 때문이다. 사용자가 본인 페이지 내에서 이동할 때마다 비밀번호를 입력하게 하자니 사용성에서 하자가 있다. 또한 매 요청마다 평문으로 비밀번호가 전송되기 때문에 요청 중 하나라도 감청당한다면 비밀번호가 그대로 노출되게 된다.비밀번호 및 세션 토큰을 통한 인증소개사용자가 웹 서비스를 사용할 때 특정 시각부터 특정 시각까지 대화가 오가는 패턴이 자주 등장한다. 대화에서와 마찬가지로 이 대화 내의 나중의 요청은 이전의 요청들에 의해 쌓인 맥락을 가지고 있다. 이렇게 특정 시간 범위 동안 존재하는 고수준 양방향 연결을 세션이라고 한다. 보통 세션은 이전 요청들에서 쌓인 맥락을 가지고 있기에 stateful하다.이렇게 웹 서비스에서 흔하게 존재하는 세션이라는 개념을 활용하면 "매 요청마다 비밀번호가 평문으로 전송된다"는 문제를 다음과 같이 해결할 수 있다.이미 사용자 A에 대한 세션이 있는 경우 A의 세션에 대한 접근 권한을 A의 비밀번호 대신 사용할 수 있다.이 경우 연결이 감청당한 경우에도 세션 접근 권한 정보는 세션이 존재하는 동안만 유효하기 때문에 비밀번호가 유출되는 확률을 낮출 수 있다. (추가: 그러나 세션이 탈취당한 상황에서 이게 얼마나 의미가 있는지는 모르겠습니다.)따라서 매번 비밀번호를 입력받는 과정을 다음의 세 단계 과정으로 대체할 수 있다.하나, 사용자 A에 대한 아이디와 비밀번호를 받아서 서버에서 세션 저장소에 A를 위한 세션의 정보를 저장하고, 세션 정보에 접근할 수 있는 권한을 응답에 반환한다. 이를 보통 "로그인"이라고 칭한다.둘, 로그인 상태에서는 세션 접근 권한을 비밀번호 대신 인증 수단으로 사용한다.셋, 특정 시간이 지나거나 사용자가 직접 요청하는 경우 세션 정보를 파기한다. 이를 "로그아웃"이라고 칭한다.토큰 소개오해를 방지하기 위해 토큰에 대해서 짚고 넘어가보자. 위키피디아에 의하면 토큰의 정의는 다음과 같다.특정 작업에 대한 권한을 표현하는 소프트웨어 혹은 하드웨어 객체따라서 꼭 JWT의 형식이 아니더라도 세션 접근에 대한 권한을 표현하는 데이터를 모두 "세션 토큰"이라고 칭할 수 있는 것으로 보인다. (혹시 아니라면 알려주시면 감사드립니다!)필요충분조건위에서 정리한 내용을 필요충분조건으로 정리하면 다음과 같다.(사용자 A 인증) <=> (A 비밀번호 제시) OR (현재 존재하는 A의 세션에 대한 토큰 제시)여기서 인상적인 점이 토큰이라는 개념은 바로 뒤에 다룰 내용인 인가에 대한 내용이지만, 인증 정책의 일환으로 A의 세션에 대한 권한이 있는 사용자를 A에 대한 인증의 충분조건으로 사용했기에 여기에 등장했다는 사실이다.정리여기까지 인증에 대한 내용을 간단하게나마 살펴보았다. 인증으로 접근 권한도 퉁쳐서 나타내면 안 되는 걸까? 여기서는 CSRF의 사례를 들어 둘을 분리해야 하는 이유 중 하나를 살펴보겠다.인가정의위키피디아에서는 다음과 같이 서술하고 있다.리소스에 접근할 수 있는 권한을 명시하는 것인증과 구별해야 하는 이유여기서 "A로 인증했으면 A가 권한이 있는 작업들을 모두 허용해도 되는 것 아닌가?"라는 의문이 당연하게 들 수 있다. 이 둘을 일치시켰을 때 발생할 수 있는 문제 중 하나로 CSRF 공격을 예로 들어보겠다.CSRFCSRF는 Cross-Site Request Forgery의 약자로, "사이트 간 요청 위조"를 뜻한다. 쉽게 말해 S1 사이트에서 사용자 A에게 본인의 의사와는 무관하게 S2 사이트로 특정 요청을 보내도록 시키는 공격이다. 예를 들어 S1이 해커 사이트이고, S2가 은행 사이트이고, S2가 CSRF에 대한 보호가 안 되어 있는 경우, S1 사이트에서 HTML Form과 자바스크립트를 통해 S1에 접속한 사용자 A로 하여금 해커에게 송금을 하라는 요청을 S2에 보내도록 시킬 수 있다. 자세한 정보는 MDN에서 잘 설명되어 있다.CSRF가 발생할 수 있는 이유는 사용자가 브라우저에서 S1 사이트를 방문했을 때 S2 사이트에 대신 요청을 보내도록 하는 것이 너무 쉽게 가능하기 때문이다. Form 태그의 action attribute를 활용하면 사용자로 하여금 다른 사이트에 요청을 보내도록 할 수 있고, 이 때 cookie에 저장된 인증 정보가 같이 전송되기 때문에 문제가 된다.CSRF 발생 원인 분석 및 해결사이트 S2 입장에서 다음과 같은 정책을 생각할 수 있다.(사용자 A의 송금 서비스 접근 권한) <=> (사용자 A의 인증 정보)이렇게 할 경우 문제가 안 생기는 맥락이 어디엔가 있을지도 모르지만, 안타깝게도 웹 서비스 환경에서는 위에서 기술한 이유로 인해서 요청한 사용자가 정상적으로 웹 서비스를 사용해서 나온 요청인지, CSRF 공격의 피해를 당해서 발생하는 요청인지 구분할 수 없다.이에 대응해서 정상적으로 웹 서비스를 사용하는 사람에게만 발급해주는 토큰을 사용해서 해결할 수 있다. 구체적으로 HTML Form으로 웹 서비스를 제공하는 경우, Form의 hidden field에다가 매번 바뀌는 랜덤 문자열 토큰을 삽입해주고, Form을 제출했을 때 이 토큰을 확인함으로써 해결할 수 있다. 이 경우 토큰은 사이트 외부에서 접근 가능한 정보가 아니지만 요청에 꼭 필요한 정보이기 때문에, CSRF로 요청을 위조하는 것이 불가능하게 된다.이를 논리식으로 나타내면 다음과 같다.(사용자 A의 송금 서비스 접근 권한) <=> (사용자 A의 인증 정보) AND (CSRF 방지 토큰 소유)정리하며생각보다 시간이 많이 걸렸습니다. 잘 이해했는지 모르겠네요...

[인프런 클론 6주 완성 챌린지] 선택 및 집중 과정에서 포기해야 하는 것들에 대한 고민

지난주는 nextjs에 익숙해지는 데 많은 시간을 할애했다.주어진 속도로는 시간을 최대한으로 투자해도 진도를 정해진 일정대로 따라가는 것은 무리라고 판단하였다. 그래서 어차피 챌린지 일정이 밀릴거라면, 1-2주차처럼 무리해서 시간을 배분하지 말고 챌린지 외 일정들을 챙기면서 진도를 천천히 따라가자는 계산을 했다.사실 지난주와 지금을 비교해봤을 때 실력적으로 큰 차이가 있지는 않지만 비슷한 패턴을 여러 번 반복해서 보다 보니 심적으로 익숙해지게 되었다. 그래서 다시 챌린지로 돌아와 프런트엔드 코드를 작성할 때 (할 일 계획) + (nextjs 코드 작성 및 이해)의 두 가지 변수 중에 후자가 해결되어 cursor에게 어떻게 일을 시킬지에 집중할 수 있게 되었고, 문제였던 불안도 어느 정도 해결되었다.각설하고 이제 급한 문제를 해결하고 보니 절대적인 시간이 부족하게 되어, 챌린지 기간 동안 어떤 부분을 챙기고 어떤 부분을 포기할지를 고민해야 하는 상황이다. 사실 이 생각을 하게 된 구체적인 이유가 있다.인프런의 지식공유자 강의 수정 화면은 다음과 같이 구성되어 있다.페이지상단 헤더: 현재 수정중인 강의 제목, 저장 및 제출 버튼 등메인 영역사이드바: 수정 과정의 모든 단계들 및 현재 단계 표시 강의 수정 영역: 강의 수정 정보 입력 폼반면 챌린지의 화면은 다음과 같이 구성되어 있다.페이지 사이드바메인 영역상단 헤더강의 수정 영역개인적으로 느끼기에 챌린지의 화면 구성이 훨씬 고민거리가 적기 때문에 챌린지 설계 과정에서 훌륭한 트레이드오프가 들어간 게 아닌가 생각하고 있다. (아닌가요...? 죄송합니다ㅠㅠ)이 파트를 구현하면서 챌린지 화면 구성에서 끝내도 되는 줄 모르고 이를 인프런 화면 구성으로 리팩터링을 시도하느라 하루를 보냈다. (결국 오늘 더 시간 쓰고 싶지 않아서 revert했습니다.) 이와 관련해서 글의 주제와는 관련 없는 몇 가지 흥미로운 생각이 들었는데 [여담]에서 따로 기술하였다.이 문제를 해결하면서 한 고민들은 nextjs를 이해하는 데 도움은 되었지만, 챌린지의 맥락에서 봤을 때 너무 지엽적인 내용인 것 같았다. 그래서 오늘 챌린지 전체 과정을 한 번 훑어보면서 내가 어떤 부분을 취하고 어떤 부분을 버려야 할지 다시 한 번 생각하게 되었다.개인적으로 챌린지를 하면서 가져가고 싶은 부분은 다음과 같다.백엔드 실 서비스 개발의 전체 흐름을 직접 경험해보기 (상세한 디테일은 챌린지 목차에서 확인 가능)이를 위해서 nextjs에 대한 이해는, 챌린지 코드의 큰 구조 및 데이터 흐름 및 AI 생성 코드를 이해할 수 있는 만큼만 가져가기로 결정했다. 그리고 "인프런 화면 구성 구현하기"는 이 관점에서 살펴봤을 때 욕심이라는 생각이 들었다.이상입니다. 읽어주셔서 감사드립니다.[여담] 여담이지만 위 현상을 경험하면서 몇 가지 생각이 들었다.스스로 무언가를 해보면서 발생하는 문제 상황을 해결할 때 배우는 게 많다. (주관적인 생각입니다.)AI가 이 과정을 방해한다고 생각했는데, 방금 배운 것을 돌아보니 AI를 활용한다고 해도 이 과정이 바뀌지는 않는구나 싶은 생각이 들었다.나는 AI가 작성하는 코드를 이해하고 싶은 마음이 크다. 혹시 관련이 있을지도?Context 왜 쓰는지 백날 고민해봤는데 한 번 리팩터링하면서 와닿는 게 더 많았다. 역시 직접경험이 짱인 것 같다.UI가 응집되는 방향성과 데이터/함수/메소드가 응집되는 방향성이 달라서 발생하는 문제를 해결한다고 생각했었고 이번 리팩터링에서 이를 실감했다. 개인적으로는 현재 리액트 주류 스택이나 MobX 활용 스택이나 주인공을 컴포넌트로 둘 것인지 객체로 둘 것인지의 관점의 차이만 있지 둘 다 이 문제를 훌륭하게 해결한다고 느꼈다. (물론 저는 말하는 감자입니다. 감자가 느낀 것을 그대로 믿으시면 안됩니다.)내가 초기 스타트업에서 일을 하는 상황이었다면 챌린지 화면처럼 구현하자고 기획자와 승부를 봐서 타협을 했을 것 같다.나는 AI가 작성한 코드를 더 쉽게 이해하고 싶어서 스타일링 최소화한 ui 코드 만들기 / 스타일링하기의 2단계로 쪼개서 일을 시키는 것을 좋아한다.또 리팩터링을 설계하고 AI 생성 코드를 이해하는 과정에서 다음과 같은 고민들을 했거나 진행중이다. 내가 생각하기에 괜찮은 고민인 것 같다.nextjs에서 서버 컴포넌트로 ViewModel A에 대한 초기 json 데이터를 얻고, 클라이언트 컴포넌트에서 A를 업데이트하는 패턴이 보이는데, 이 패턴을 공통으로 묶을 수 없을까? (고민중)인프런 화면 구성을 구현하려면 Layout 컴포넌트를 어떻게 설계해야 할까? (마음에 드는 솔루션 하나 확인)

코딩 가독성 최적화 방법

[인프런 클론 6주 완성 챌린지] 배우기와 익히기의 밸런스

개인적으로 이번 챌린지를 신청하는 데 많은 용기가 필요했다.하나는 타인의 문제 해결을 클론코딩하면서 내가 문제를 해결하는 문제해결력이 떨어지는 것이 아닌가 걱정했기 때문이고,다른 하나는 내 자신의 문제해결력에 하자가 있다는 것을 인정해야 했기 때문이다. (주의: 개인적인 맥락 하에서만 맞는 얘기입니다. 일반적으로 클론코딩 수업을 듣는다고 문제해결력에 하자가 있다고는 생각하지 않습니다.)이번 챌린지를 신청했을 때 했던 생각은 약간 자포자기하는 심정으로 '내 문제해결력이 떨어지는 리스크를 감수해서라도 나는 백엔드 개발을 한 바퀴를 돌려봐서 흐름을 파악해야겠다'였다. 또 '지금 못해도 배워서 잘 하면 되지'라는 말로 못하는 내 자신을 용서하는 과정도 필요했다.뚜껑을 열어보니 예상외로 챌린지에 참여하기를 정말 잘한 것 같다는 생각이 들었다. 일단 지금까지는 그렇다. 모방하고 이를 돌아보는 과정에서 내 문제 해결의 어떤 부분에서 하자가 있는지를 파악할 수 있었기 때문이다.실마리는 불안한 상태에서도 퍼포먼스를 내는 방법을 고민하면서 찾아왔다. 문득 '불안한 상태에서도 손이 자동적으로 나가도록 무지성 연습을 하면 불안할 때도 내 실행 능력의 저점은 보장되지 않을까?'라는 생각이 들었다. 그래서 nestjs 첫 프로젝트 수업을 2회, 컨트롤러는 3회 반복해서 구현했다. 반복하면서 다음 생각이 들었다.내가 불안감을 느끼면서 막혔던 이유는 동시에 문제 2-3개를 해결해야 해서 압도당했기 때문이다.예를 들면 nestjs controller 구현 + 클론 코딩 과정에서 현재 단계에 대한 이해작업이 어려워서가 아니라 코드가 손에 안 익어서 막힌다.간단한 게시글에 대한 crud 작업 연습에서 사실 "이해"가 필요한 부분은 거의 없다. 반복하면서 막혔던 이유는 전부 nest가 손에 안 익어서였다.그러면서 이런 생각이 들었다.모든 학습 과정은 배우기('학')와 익히기('습')가 동반된다. 프로그래밍의 경우 과목 특성인지 배움 없이 익히기에 치중한 학습자들이 많아서인지는 모르겠지만 이 중 정확한 이해를 통한 배우기가 특히 강조된다고 개인적으로 느꼈다.배우기와 익히기의 비중은 프로그래밍의 하위 분야에 따라 많이 다른 것 같다. 알고리즘 학습의 경우 (PS만큼 어렵지는 않은 맥락에서는) 배우기를 잘 하면 익히기는 상대적으로 수월하게 되는 것 같고, 웹 개발의 경우 배우기와 익히기 둘 다 의식적인 노력이 필요한 것 같다.나는 지금까지 내가 알고리즘은 못하더라도 "뭔가 잘 맞고" 웹 개발은 "뭔가 잘 안 맞는다"고 생각했는데, 적성의 문제가 아니라 학습 방법의 문제인 것 같다는 생각이 들었다.이제 앞으로 할 일은 막힐 때 어떤 부분으로 인해 병목이 생기는지를 파악해서 그 부분의 문제를 하나씩 해결하면 되지 않을까 싶다.

[인프런 클론 6주 완성 챌린지] 오늘을 기억하고 싶다.

오늘은 처음으로 불안에 직면했을 때 긍정적인 피드백을 받은 날이다.처음 노트북을 꺼내들었을 때는 불안에 떨고 있었는데, 중간에 tailwind 스타일링 할 때 따라해보면서 변주를 주는 과정에서 몰입이 되었고, 시간 가는 줄 모르고 강의 끝까지 따라치게 되었다. 강의가 끝났을 때의 성취감, 효능감이 장난이 아니었다.물론 객관적으로는 한 것은 정말 아무것도 없다. 강의에서의 로그인 플로우를 따라 친 것이 전부이다. 그리고 냉정하게 돌아본다면 내가 몰입할 수 있는 일의 난이도는 tailwind 스타일링 및 강의를 그대로 따라치는 수준에 불과하다.하지만 오늘은 그런 것보다도 일주일동안 불안한 상태로 애쓴 내 자신에게 고생했다는 말을 해주고 싶다.그리고 미래에는 조금씩 더 어려운 일들에도 직면할 수 있을지도 모르니 희망을 잃지 말자는 생각이 들었다.이 순간을 기억하기 위해 조금만 쉬었다 다음 강의로 넘어가야겠다.